# Gosign – Full Site Content
# Generated: 2026-07-28T04:20:32.250Z
# Enterprise AI Infrastructure & Agent Engineering Company
# https://www.gosign.de


============================================================
LANGUAGE: BR
============================================================

--- Agência Digital Hamburgo | Web, IA, TYPO3 ---
> Gosign é uma agência digital de Hamburgo para desenvolvimento web, integração de IA e TYPO3. 25 anos de experiência. Foco B2B.

<!-- O que é a Gosign? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">O que é a Gosign?</h2>
<p class="text-body text-gosign-text leading-relaxed">
A Gosign é uma agência digital de Hamburgo com 25&nbsp;anos de experiência em desenvolvimento web, sistemas TYPO3 e integração de IA para empresas. Fundada em 1999, hoje é especializada em sites B2B, projetos Enterprise CMS e infraestruturas de IA. A partir do hub europeu em Hamburgo, a Gosign atende empresas brasileiras e latino-americanas que buscam qualidade e conformidade com padrões internacionais.
</p>
</div>
</section>

<!-- Por que a Gosign? -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Por que a Gosign?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Porque nós não construímos apenas sites - construímos infraestrutura digital. Três áreas de atuação, uma equipe:
</p>
</div>
</section>

<!-- Desenvolvimento Web & CMS -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Desenvolvimento web &amp; CMS</h2>
<p class="text-body text-gosign-text leading-relaxed">
Sites que performam. Tecnicamente e comercialmente. TYPO3, WordPress, Astro, arquiteturas Headless. Da concepção ao lançamento, de 10&nbsp;páginas a 10.000. A Gosign analisou mais de 800 extensions TYPO3 e desenvolve projetos Enterprise CMS há mais de duas décadas.
</p>
</div>
</section>

<!-- Integração de IA -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Integração de IA para empresas</h2>
<p class="text-body text-gosign-text leading-relaxed">
Infraestruturas de IA diretamente no ambiente corporativo: assistentes de IA, AI Agents, hospedagem de modelos (DeepSeek, Llama, Mistral) na sua própria infraestrutura. Em conformidade com a LGPD (PT: RGPD), compatível com CERT.br, sem vazamento de dados para terceiros. A Gosign constrói soluções de IA que se integram a ambientes de TI existentes.
</p>
</div>
</section>

<!-- Especialização TYPO3 -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Especialização em TYPO3</h2>
<p class="text-body text-gosign-text leading-relaxed">
Mais de 800 extensions TYPO3 monitoradas, mais de 500 implementadas com sucesso. De busca enterprise com Solr a integração SSO até e-commerce com aimeos. A Gosign é um dos provedores TYPO3 mais experientes da Europa.
</p>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Vamos conversar sobre o seu projeto - 30&nbsp;minutos, gratuito.</h3>
<p class="text-body text-gosign-text mb-6">Analisamos seu projeto, estimamos esforço e prazo, sem compromisso.</p>
<a
href="/br/contato/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Agendar reunião
</a>
<p class="text-small text-gosign-text-light mt-4">25 anos de experiência · 800+ extensions · Desenvolvimento acelerado por IA</p>
</div>
</section>

<!-- Comparison Table -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">O que diferencia a Gosign de outras agências digitais</h2>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Critério</th>
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Agência típica</th>
<th class="py-3 text-small font-bold text-gosign-dark">Gosign</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Profundidade CMS</td>
<td class="py-3 pr-4 text-body text-gosign-text">WordPress básico</td>
<td class="py-3 text-body text-gosign-text">TYPO3 Enterprise + WordPress + Headless</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Competência em IA</td>
<td class="py-3 pr-4 text-body text-gosign-text">Prompts de ChatGPT</td>
<td class="py-3 text-body text-gosign-text">Infraestruturas de IA próprias, hospedagem de modelos</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Velocidade de desenvolvimento</td>
<td class="py-3 pr-4 text-body text-gosign-text">Tradicional</td>
<td class="py-3 text-body text-gosign-accent-text font-semibold">Acelerado por IA: 60 a 80% mais rápido</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Foco setorial</td>
<td class="py-3 pr-4 text-body text-gosign-text">Tudo para todos</td>
<td class="py-3 text-body text-gosign-text">B2B, empresas de médio porte, universidades, setor público</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Segurança</td>
<td class="py-3 pr-4 text-body text-gosign-text">Hospedagem padrão</td>
<td class="py-3 text-body text-gosign-text">Infraestruturas compatíveis com CERT.br, monitoramento de segurança</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Localização</td>
<td class="py-3 pr-4 text-body text-gosign-text">Remoto/Global</td>
<td class="py-3 text-body text-gosign-text">Hamburgo, hub europeu, atendimento personalizado</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Setores -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Setores</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
A Gosign trabalha para empresas que levam infraestrutura digital a sério:
</p>
<div class="grid md:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Indústria &amp; engenharia</h3>
<p class="text-body text-gosign-text">Sites B2B com configuradores de produto, portais de distribuidores, documentação técnica</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Automotivo</h3>
<p class="text-body text-gosign-text">Portais de marca, redes de concessionárias, showrooms digitais</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Saúde &amp; farmacêutico</h3>
<p class="text-body text-gosign-text">Sites em conformidade regulatória, portais de pacientes</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Educação &amp; universidades</h3>
<p class="text-body text-gosign-text">SSO com Shibboleth, buscadores de cursos, sites acessíveis</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Associações &amp; setor público</h3>
<p class="text-body text-gosign-text">Gestão de membros, portais multilíngues, acessibilidade</p>
</div>
</div>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
A Gosign é uma agência digital de Hamburgo com 25 anos de experiência em desenvolvimento web, TYPO3 e integração de IA.
Analisamos mais de 800 extensions TYPO3 e hoje desenvolvemos com suporte de IA
até 70% mais rápido do que com métodos tradicionais. A partir do hub europeu em Hamburgo,
atendemos empresas brasileiras e latino-americanas que buscam excelência digital.
</p>
<p class="text-small text-gosign-text-light mt-2">Atualizado em: fevereiro de 2026</p>
</div>
</section>

<!-- Temas relacionados -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Temas relacionados</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/br/agencia-wordpress/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Desenvolvimento web</p>
<p class="text-body font-semibold text-gosign-dark">Agência WordPress Hamburgo</p>
</a>
<a href="/br/typo3-extensions/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">CMS</p>
<p class="text-body font-semibold text-gosign-dark">TYPO3 Extensions</p>
</a>
<a href="/br/seguranca-web-padroes/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Segurança</p>
<p class="text-body font-semibold text-gosign-dark">Segurança web conforme padrões CERT.br</p>
</a>
</div>
</div>
</section>

--- Agência WordPress Hamburgo | Desde 1999 ---
> Agência WordPress em Hamburgo: desenvolvimento, manutenção e projetos acelerados por IA. Há 25 anos. Consultoria gratuita.

<!-- O que a Gosign oferece? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">O que a Gosign oferece como agência WordPress?</h2>
<p class="text-body text-gosign-text leading-relaxed">
A Gosign é uma agência WordPress de Hamburgo com 25&nbsp;anos de experiência em desenvolvimento web. A Gosign desenvolve sites WordPress para empresas B2B: Custom Themes, desenvolvimento de plugins, lojas WooCommerce, WordPress Headless com frontends modernos. Desde 2023, a Gosign utiliza desenvolvimento assistido por IA. Projetos WordPress são realizados 60 a 80% mais rápido, com a mesma qualidade.
</p>
</div>
</section>

<!-- Por que a Gosign -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Por que a Gosign e não uma agência WordPress comum?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Porque WordPress é apenas parte do cenário. A Gosign conhece TYPO3, arquiteturas Headless e infraestruturas de IA, e aconselha de forma honesta se WordPress é a escolha certa. Para sites de conteúdo: quase sempre sim. Para portais Enterprise com permissões complexas: talvez TYPO3.
</p>
</div>
</section>

<!-- Serviços WordPress -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">Serviços WordPress</h2>
<div class="grid md:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Desenvolvimento de tema personalizado</h3>
<p class="text-body text-gosign-text">
Nada de templates prontos. A Gosign desenvolve temas WordPress exatamente conforme o design, responsivos, performáticos, acessíveis. Otimizados para Gutenberg, prontos para Full Site Editing. A IA gera as estruturas base dos temas, desenvolvedores senior refinam.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Desenvolvimento de plugins &amp; customização</h3>
<p class="text-body text-gosign-text">
Plugins personalizados para sua lógica de negócios. Estender plugins existentes, adaptar ou substituir por desenvolvimentos próprios mais seguros. A IA acelera o desenvolvimento de plugins em 70%.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">WooCommerce &amp; e-commerce</h3>
<p class="text-body text-gosign-text">
Lojas online com WooCommerce: catálogos de produtos, integração de pagamento, lógica de frete, sistemas de cupons. Para lojas com até ~50.000 produtos, a plataforma ideal.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Manutenção &amp; segurança WordPress</h3>
<p class="text-body text-gosign-text">
Atualizações, backups, monitoramento de segurança, otimização de performance. Manutenção proativa em vez de reparo reativo. A Gosign monitora mais de 800 extensions e conhece vulnerabilidades antes que sejam exploradas.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6 md:col-span-2">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Migração para WordPress</h3>
<p class="text-body text-gosign-text">
Migrar de TYPO3, Joomla, Drupal ou Webflow para WordPress. Transferência de conteúdo, mapeamento de redirects para SEO, redesign. Migração de conteúdo assistida por IA economiza semanas.
</p>
</div>
</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Conversar sobre seu projeto WordPress - 30&nbsp;minutos, gratuito.</h3>
<p class="text-body text-gosign-text mb-6">Analisamos seu projeto, estimamos esforço e prazo, sem compromisso.</p>
<a
href="/br/contato/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Agendar reunião
</a>
<p class="text-small text-gosign-text-light mt-4">25 anos de experiência · 800+ extensions · Desenvolvimento acelerado por IA</p>
</div>
</section>

<!-- KI Table -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Desenvolvimento WordPress acelerado por IA: 70% mais rápido</h2>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Tarefa</th>
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Tradicional</th>
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Com IA</th>
<th class="py-3 text-small font-bold text-gosign-dark">Economia</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Tema personalizado (10 templates)</td>
<td class="py-3 pr-4 text-body text-gosign-text">3 a 4 semanas</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">1 a 1,5 semana</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">65%</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Plugin personalizado</td>
<td class="py-3 pr-4 text-body text-gosign-text">2 a 3 semanas</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">4 a 6 dias</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">70%</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Setup loja WooCommerce</td>
<td class="py-3 pr-4 text-body text-gosign-text">2 a 3 semanas</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">5 a 7 dias</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">65%</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Migração de conteúdo (500 páginas)</td>
<td class="py-3 pr-4 text-body text-gosign-text">2 semanas</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">3 dias</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">80%</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Auditoria de segurança</td>
<td class="py-3 pr-4 text-body text-gosign-text">3 dias</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">1 dia</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">70%</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Comparison Table -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">WordPress vs. TYPO3 vs. Headless: consultoria honesta</h2>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse bg-white rounded-card">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Critério</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">WordPress</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">TYPO3</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Headless (Astro, Next.js)</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Foco em conteúdo</td>
<td class="py-3 px-4 text-body text-gosign-text">Ideal</td>
<td class="py-3 px-4 text-body text-gosign-text">Bom</td>
<td class="py-3 px-4 text-body text-gosign-text">Mais complexo</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Permissões enterprise</td>
<td class="py-3 px-4 text-body text-gosign-text">Limitado</td>
<td class="py-3 px-4 text-body text-gosign-text">Granular</td>
<td class="py-3 px-4 text-body text-gosign-text">Custom</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">E-commerce</td>
<td class="py-3 px-4 text-body text-gosign-text">WooCommerce</td>
<td class="py-3 px-4 text-body text-gosign-text">aimeos</td>
<td class="py-3 px-4 text-body text-gosign-text">Shopify API</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Performance</td>
<td class="py-3 px-4 text-body text-gosign-text">Depende dos plugins</td>
<td class="py-3 px-4 text-body text-gosign-text">Necessita cache</td>
<td class="py-3 px-4 text-body text-gosign-accent-text font-semibold">Estático = rápido</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Facilidade para editores</td>
<td class="py-3 px-4 text-body text-gosign-text">Excelente</td>
<td class="py-3 px-4 text-body text-gosign-text">Bom</td>
<td class="py-3 px-4 text-body text-gosign-text">Limitado</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Recomendação Gosign</td>
<td class="py-3 px-4 text-body text-gosign-accent-text font-semibold">Sites de conteúdo, blogs, PMEs</td>
<td class="py-3 px-4 text-body text-gosign-accent-text font-semibold">Enterprise, universidades</td>
<td class="py-3 px-4 text-body text-gosign-accent-text font-semibold">Performance crítica</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
A Gosign é uma agência digital de Hamburgo com 25 anos de experiência em desenvolvimento web, TYPO3 e integração de IA.
Analisamos mais de 800 extensions TYPO3 e hoje desenvolvemos com suporte de IA
até 70% mais rápido do que com métodos tradicionais. A partir do hub europeu em Hamburgo,
atendemos empresas brasileiras e latino-americanas que buscam excelência digital.
</p>
<p class="text-small text-gosign-text-light mt-2">Atualizado em: fevereiro de 2026</p>
</div>
</section>

<!-- Temas relacionados -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Temas relacionados</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/br/agencia-digital-hamburg/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Desenvolvimento web</p>
<p class="text-body font-semibold text-gosign-dark">Agência digital Hamburgo</p>
</a>
<a href="/br/site-hackeado-10-motivos/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Segurança</p>
<p class="text-body font-semibold text-gosign-dark">Site hackeado: 10 motivos</p>
</a>
<a href="/br/seguranca-web-padroes/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Segurança</p>
<p class="text-body font-semibold text-gosign-dark">Segurança web conforme padrões CERT.br</p>
</a>
</div>
</div>
</section>

--- Agentes IA para Empresas na Alemanha | Gosign ---
> Enterprise AI Agents para empresas alemãs. LGPD-compliant, auditável, Governance by Design. Sede Hamburgo, escritório Berlim. Gosign GmbH.

## A Alemanha é o mercado-casa da Gosign - e o país da UE com maior densidade de compliance

A Alemanha combina três características que não existem juntas em nenhum outro país da UE: máxima densidade de grupos industriais em vários setores, direito vinculante de co-determinação do conselho de fábrica (Betriebsrat) sob § 87 Abs. 1 Nr. 6 da BetrVG, e estrutura federativa de supervisão com BaFin, BSI, BfDI e mais dezesseis autoridades estaduais de proteção de dados. O mapa corporativo vai de Automotive (VW, BMW, Daimler, Porsche, Continental, Bosch, ZF) a Química (BASF, Bayer, Evonik, Merck, Covestro), Engenharia (Siemens, Trumpf, Dürr, Kuka, Festo), Banking (Deutsche Bank, Commerzbank, Sparkassen, Volks- und Raiffeisenbanken), Insurance (Allianz, Munich Re, Ergo, HDI, R+V), Energy (RWE, E.ON, EnBW) e Retail (Otto, Zalando, Lidl/Kaufland, Rewe, Edeka). A Gosign, com sede em [Hamburgo](/br/agentes-ia-hamburgo/) e escritório em [Berlim](/br/agentes-ia-berlim/), é parte desse mercado - e foi exatamente para ele que construímos nossa arquitetura. Contexto relevante também para grupos brasileiros com filiais alemãs ou parcerias em toda a cadeia DACH.

## As três barreiras regulatórias para IA no mercado alemão

A primeira é a **Betriebsverfassungsgesetz (BetrVG)**: o § 87 Abs. 1 Nr. 6 confere ao conselho de fábrica direito vinculante de co-determinação na introdução de sistemas técnicos capazes de monitorar comportamento ou desempenho do empregado. Sistemas de IA em RH, escala, avaliação de desempenho, roteamento de service desk - todos caem nessa regra. Implementação produtiva sem acordo de empresa é juridicamente insustentável em grupos alemães. O Decision Layer com Human-in-the-Loop imposto aqui não é "feature de arquitetura", é pré-condição de aprovação pelo conselho de fábrica.

A segunda é a combinação **GDPR + BDSG com supervisão federativa**: BfDI no nível federal, mais dezesseis autoridades estaduais (Landes-Datenschutzbeauftragte), mais as exigências específicas do Bundesdatenschutzgesetz. Para decisão automatizada no sentido do Art. 22 do GDPR, as autoridades alemãs exigem bases legais documentadas, explicações acessíveis e Audit Trail completo. Especificidade alemã: a Avaliação de Impacto em Proteção de Dados (DPIA) precisa estar concluída antes do go-live em aplicações de alto risco, não em paralelo ao rollout.

A terceira é o conjunto **BaFin, BSI, BNetzA e EU AI Act**. A BaFin supervisiona o setor financeiro e espera decisão humana final comprovável em AML, KYC, credit scoring e manejo de sinistros em casos de risco. A BSI define os mínimos de segurança de TI para empresas KRITIS. O EU AI Act é transposto na Alemanha via lei nacional em preparação (Gesetz zur Durchführung der KI-Verordnung), com foco em alto risco em RH, banking, insurance e infraestrutura crítica. Começar sem Cert-Ready by Design é construir em cima de uma arquitetura que precisará ser modificada no primeiro audit BaFin. Para brasileiros: aqui vale o EU AI Act de forma direta; o PL 2338/2023 no Brasil é o equivalente em preparação mas não é aplicável automaticamente na Alemanha.

## Cenários típicos de implementação na Alemanha

**Manejo de sinistros na Allianz e Munich Re**: as líderes alemãs de seguros processam milhares de sinistros por dia. Workflow Agents classificam por tarifa, região e complexidade; o Decision Layer roteia casos de risco ao analista humano; Audit Trail documenta cada decisão para auditoria interna e BaFin.

**AML na Commerzbank e Sparkassen**: com milhões de transações diárias, Document Agents verificam dados de identificação, o Decision Layer segue as faixas BaFin e impõe Human-in-the-Loop em cada escalação final.

**RH em VW, BMW e Daimler**: os grupos automotivos alemães têm centenas de milhares de empregados. Workflow Agents apoiam recrutamento e mobilidade interna, com última decisão humana obrigatória em medidas de pessoal - pré-condição para aceitação do conselho de fábrica pelo § 87 BetrVG.

**Documentação de produção na BASF e Bayer**: gigantes químicos geram diariamente enormes volumes de documentação de segurança e qualidade. Document Agents extraem especificações regulatoriamente relevantes, cruzam com REACH, CLP e CE, com Audit Trail completo até o PR de origem.

Em todos esses cenários o [Decision Layer](/br/decision-layer/) é o componente arquitetural que entrega Governance by Design.

## Como a Gosign atende a Alemanha a partir de Hamburgo e Berlim

A Gosign tem sede em Hamburgo (Hallerstraße 8) e escritório em Berlim (Nogatstraße 46), além de um centro de treinamento em Hamburgo no Grindelberg 77. Discovery Workshops acontecem presencialmente - em [Munique](/br/agentes-ia-munique/), [Frankfurt](/br/agentes-ia-frankfurt/), [Stuttgart](/br/agentes-ia-stuttgart/), [Düsseldorf](/br/agentes-ia-dusseldorf/), [Colônia](/br/agentes-ia-colonia/), [Hannover](/br/agentes-ia-hannover/) ou diretamente em Hamburgo e Berlim. O build roda remoto, com documentação em alemão, Sprint Reviews semanais por vídeo, ponto de contato fixo e visitas presenciais a cada 4-6 semanas. Reuniões com conselho de fábrica, DPO e Compliance são parte fixa de todo projeto.

Para grupos brasileiros com operações alemãs o eixo São Paulo - Hamburgo - Berlim entrega a arquitetura unificada que resolve LGPD e GDPR simultaneamente. Nossos gerentes de projeto brasileiros em SP articulam-se com os arquitetos DACH em Hamburgo, com reuniões em português, alemão e inglês conforme a conversa. Presenças em BaFin, BSI ou autoridades estaduais de proteção de dados são acompanhadas, sob demanda, em parceria com o jurídico interno do cliente.

## Por que a Alemanha funciona como ponto de partida para Enterprise AI

A Alemanha não é o mercado mais fácil da UE, é o mais duro - e justamente isso a torna o melhor ponto de partida. Quem constrói um agent que atende GDPR, BDSG, BetrVG, BaFin e BSI e o EU AI Act, desenvolveu uma arquitetura a apenas uma mudança de configuração de qualquer outro país da UE. A cultura alemã de compliance e a co-determinação do conselho de fábrica forçam Governance by Design - nenhum outro país da UE exige isso com a mesma consistência. Para grupos DAX, MDAX e Mittelstand acima de 200 empregados essa disciplina não é ônus, é vantagem competitiva: o que vai a produção na Alemanha vai a produção em toda a UE. Uma arquitetura que resiste à BaFin resiste à DNB holandesa, à FMA austríaca e à ACPR francesa. Uma solução acordada com conselho de fábrica alemão se negocia na Polônia com a Rada Zakładowa, na Espanha com o Comité de Empresa e na França com o CSE, sem re-build fundamental. A arquitetura Gosign nasceu de projetos em grupos alemães cujas expectativas de auditoria definiram cada primeiro dia em produção. Cert-Ready by Design aqui não é argumento comercial, é necessidade construtiva. Mais contexto sobre [EU AI Act](/br/governance/eu-ai-act/) no Governance.

--- Agentes IA para Empresas em Amsterdam | Gosign ---
> Enterprise AI Agents para Amsterdam e Países Baixos. LGPD-compliant, EU AI Act ready, auditável. IA para o hub tecnológico da Europa.

## Amsterdam é o único mercado da Europa onde o ritmo da escala tecnológica e a fiscalização bancária convivem no mesmo CEP

Poucas cidades europeias concentram hyperscale tech e banking sistêmico tão densamente quanto Amsterdam. ING, ABN AMRO e Rabobank mantêm aqui suas sedes, enquanto Adyen, Booking.com, TomTom e Prosus transformaram a cidade no segundo maior mercado de capitais tecnológico da Europa, atrás apenas de Londres. No entorno, a Brainport Region em Eindhoven abriga Philips e ASML, somando competência industrial high-tech ao polo financeiro. Heineken, Shell NL e KLM formam o núcleo industrial tradicional, enquanto startups como Bunq e Mollie desenham o mapa fintech. Quem implementa IA aqui constrói para um público que entende tanto trilhas de reclamação sob PSD2 quanto ISO/IEC 42001. Essa combinação faz de Amsterdam um dos testes de aceitação mais duros para Enterprise AI na Europa - referência importante para grupos brasileiros com operações holandesas ou investidores europeus de presença local.

## As três barreiras regulatórias para IA no mercado de Amsterdam

A primeira é a **Autoriteit Persoonsgegevens (AP)** - a autoridade holandesa de proteção de dados está entre as mais rigorosas da UE e elevou auditoria algorítmica ao patamar de padrão de mercado. A AP publica diretrizes contínuas sobre o uso de sistemas de IA sob o GDPR e mantém desde 2023 uma divisão própria de supervisão, a "Algoritmes". Quem vai a produção aqui precisa explicar cada decisão automatizada ao titular afetado.

A segunda é a combinação **De Nederlandsche Bank (DNB) + Autoriteit Financiële Markten (AFM)**. Com seu paper conjunto "General principles for the use of Artificial Intelligence in the financial sector" (princípios SAFEST), definiram o padrão para bancos, seguradoras e fundos de pensão holandeses. Soundness, Accountability, Fairness, Ethics, Skills e Transparency não são opcionais: cada decisão de IA precisa resistir aos seis critérios em auditoria.

A terceira é a **interpretação nacional do EU AI Act** em preparação. Os Países Baixos trabalham em uma lógica de implementação que amarra as categorias de alto risco do EU AI Act aos regimes existentes de DNB e AP. Na prática, um sistema classificado como "high-risk" pelo EU AI Act cai em Amsterdam simultaneamente sob a lógica SAFEST de DNB/AFM - a camada de [Governança EU AI Act](/br/governance/eu-ai-act/) precisa funcionar em dobro. Para grupos brasileiros, é importante lembrar: no Brasil o EU AI Act não se aplica diretamente, mas filiais holandesas processando dados europeus ficam plenamente sujeitas a ele.

## Cenários típicos de implementação em Amsterdam

**Transaction Monitoring em ING e ABN AMRO**: os modelos de detecção de lavagem precisam permanecer explicáveis diante de auditores da DNB - cada alerta individual deve ser reproduzível com trilha completa. O Decision Layer encaminha casos de alto risco ao time de Compliance com score de confiança, justificativa e Audit Trail.

**Fraud Detection em Adyen**: a Adyen processa bilhões de pagamentos globalmente e precisa de modelos que decidam em segundos, mas entreguem à AFM um Audit Trail completo para cada bloqueio. Workflow Agents monitoram padrões transacionais em tempo real e escalam casos suspeitos com dossiê de justificativa.

**Dynamic Pricing em Booking.com**: os algoritmos de precificação dinâmica andam direto na zona de colisão entre o Art. 5 do EU AI Act (proibição de práticas manipulativas) e a ACM, autoridade holandesa de concorrência. Document Agents precisam documentar cada variação de preço de modo revisável por auditoria.

**IP-Documentation em ASML (Veldhoven)**: portfólios de patentes e litígios de propriedade intelectual onde qualquer pesquisa auxiliada por IA precisa ser tecnicamente rastreável. Document Agents preparam dossiês completos com citação de fontes e Human-in-the-Loop em cada etapa crítica.

Em todos os quatro cenários não se trata de "o modelo funciona?", mas de "podemos defender o modelo diante do regulador?". É para isso que existe o [Decision Layer](/br/decision-layer/): arquitetura que persiste cada decisão como trace, impõe caminhos escaláveis de Human-in-the-Loop e expõe Audit Trail diretamente em nível SQL. Acrescente-se o ondernemingsraad - o conselho de empresa holandês tem direitos substanciais de co-determinação sob o Wet op de ondernemingsraden (WOR). A arquitetura do Decision Layer integra a consulta ao OR como parte nativa da Governance, não como anexo posterior.

## Como a Gosign atende Amsterdam a partir de Hamburgo

Hamburgo está a pouco mais de quatro horas de trem ou uma hora de voo do Schiphol. Trabalhamos remote-first com times em Amsterdam, Eindhoven e Rotterdam - cadência de stand-up em CET, revisões assíncronas via Linear, workshops presenciais mensais nos primeiros três meses de projeto. A cultura holandesa de compliance é pragmática o suficiente para que a colaboração flua sem grandes perdas de tradução. Discovery Workshops rodam em inglês, documentação técnica em inglês e holandês (validada por reviewers nativos), steering interno em alemão com nossos arquitetos em Hamburgo.

Não mantemos escritório em Amsterdam - e, honestamente, para a maioria dos projetos não é necessário. O que é necessário é ter alguém que traga os princípios SAFEST da DNB e o EU AI Act simultaneamente na cabeça, e que esteja em campo em 24 horas quando a AP bater à porta para uma auditoria. Ambos entregamos desde Hamburgo. Concretamente: arquitetos e Compliance Leads no time de Hamburgo, budget de viagem para presença trimestral, SLA de escalação de 24 horas para demandas regulatórias. Para clientes brasileiros com operações em Amsterdam, o eixo São Paulo - Hamburgo - Amsterdam permite coordenar LGPD/RGPD lado a lado com AP e DNB, mesma equipe, mesma arquitetura.

## Por que Amsterdam funciona como ponto de partida para Enterprise AI

Amsterdam obriga a pensar IA desde o primeiro dia como infraestrutura regulada, não como experimento de inovação. Quem aqui constrói um piloto com Cert-Ready by Design sai com um caso de referência defensável em qualquer outro mercado da UE. Os clusters Amsterdam Smart City, AMS Cluster e o ecossistema Brainport em Eindhoven entregam talento, pesquisa e parceiros piloto. Os caminhos de distribuição são claros: quem satisfaz DNB, AFM e AP tem argumento de compliance que funciona em Frankfurt, Paris ou Madri - geralmente com menos overhead do que a versão holandesa. A arquitetura Governance by Design da Gosign conecta isso ao padrão europeu de profundidade de auditoria: um modelo que passa no filtro holandês é automaticamente exportável para o resto da Europa. Para grupos brasileiros avaliando operações europeias, Amsterdam é uma porta de entrada com barra regulatória alta mas ecossistema maduro. Mais em [serviços AI Agents](/br/servicos/ai-agents/).

--- Agentes IA para Empresas em Barcelona | Gosign ---
> Enterprise AI Agents em Barcelona. Gestão de projetos local, EU AI Act compliant by design, LGPD-compliant. Do PoC à operação independente.

## Barcelona é a capital tecnológica da Espanha - mas a autoridade espanhola de IA decide em La Coruña

Quem constrói Enterprise AI em Barcelona trabalha em um dos corredores de inovação mais densos do sul da Europa e, ao mesmo tempo, em um mercado cujas decisões regulatórias nascem 1100 quilômetros ao norte. No distrito 22@Barcelona concentram-se CaixaBank, Cellnex Telecom, Mango, Desigual, Damm e o gigante farmacêutico Grifols (plasma). No cinturão metropolitano a Seat produz em Martorell a linha Cupra, o porto movimenta a logística da Naturgy, e o Banco Sabadell atende clientes midmarket em toda a Catalunha. O Pier01 e a ESADE Creapolis atraem talento - Barcelona é o laboratório de inovação da Espanha. Mas a realidade regulatória é definida na sede da AESIA em La Coruña e endurecida em Madrid - cenário importante também para grupos brasileiros com operações ibéricas que atendemos a partir do nosso escritório local.

## As três barreiras regulatórias para IA no mercado catalão

A primeira é a **AESIA (Agencia Española de Supervisión de la Inteligencia Artificial)**. A Espanha é o primeiro país da UE com autoridade de supervisão de IA dedicada, com sede em La Coruña, e ambiciona ser referência para a transposição nacional do EU AI Act em toda a União. A partir de 2026 a AESIA audita sistematicamente sistemas de alto risco e pode impor proibições operacionais. Quem coloca modelos em produção em Barcelona precisa documentar desde o primeiro dia para uma auditoria AESIA - nos padrões definidos no programa de sandbox.

A segunda é a **AEPD (Agencia Española de Protección de Datos)** em conjunto com a **LOPDGDD (Ley Orgánica 3/2018)**, a lei espanhola de transposição do GDPR com endurecimentos locais. A AEPD é conhecida em toda a UE pela interpretação mais estrita do Art. 22 GDPR: decisões totalmente automatizadas são praticamente inadmissíveis na Espanha sem última decisão humana documentada. Para qualquer sistema de IA com dado pessoal isso significa: Decision Layer com Human-in-the-Loop não é opcional, é pré-requisito de compliance.

A terceira é a combinação **CNMV (Comisión Nacional del Mercado de Valores) e Banco de España** para serviços financeiros. Desde 2024 a CNMV exige Audit Trail completo em recomendações de investimento apoiadas por IA e audita a explicabilidade dos modelos. Paralelamente, o Comité de Empresa impõe direitos de consulta sob o Art. 64 do Estatuto de los Trabajadores quando sistemas de IA tomam decisões trabalhistas. Vale lembrar: o EU AI Act aplica-se diretamente na Espanha; para grupos brasileiros a analogia aproximada é o PL 2338/2023, ainda em tramitação.

## Cenários típicos de implementação em Barcelona

**Concessão de crédito no CaixaBank**: os modelos de análise para PME precisam permanecer reproduzíveis sob supervisão da AEPD - toda recusa tem que ser justificável em até 14 dias. Document Agents extraem balanço, demonstrativos e histórico bancário; o Decision Layer encaminha casos fronteiriços ao analista humano com score e Audit Trail.

**Documentação de cadeia de plasma na Grifols**: a Grifols documenta a origem do plasma em centenas de centros nos EUA e UE - a FDA exige trilhas de auditoria contínuas e a EMA espelha o requisito. Verificação de plausibilidade apoiada por IA aqui não é inovação, é compliance. Workflow Agents monitoram discrepâncias e sinalizam para Quality Assurance.

**Predictive Maintenance na Cellnex Telecom**: dezenas de milhares de torres de telefonia em toda a Europa precisam de priorização de manutenção - cada decisão automatizada de triagem precisa ser documentável diante dos proprietários (frequentemente investidores institucionais). O Decision Layer preserva a justificativa por intervenção.

**Planejamento de capacidade na Seat (Martorell)**: a Seat planeja a produção dos modelos Cupra e precisa de IA para alocação entre plantas - os modelos têm que resistir às auditorias do grupo VW com os mesmos padrões que valem em Wolfsburg ou Ingolstadt.

Em todos os quatro cenários o [Decision Layer](/br/decision-layer/) cria uma camada entre modelo e processo de negócio que impõe Audit Trail, caminhos de escalação e Governance by Design - exatamente o que AESIA, AEPD e CNMV querem ver simultaneamente. Acrescentam-se requisitos setoriais: farmacêuticas como Grifols sob supervisão da EMA têm que documentar decisões de qualidade apoiadas por IA em conformidade GMP; operadoras como Cellnex estão sob supervisão da CNMC e devem abrir as implicações de poder de mercado de seus algoritmos; no setor automotivo o grupo VW exige avaliação de risco para cada ferramenta de IA em plantas Seat.

## Como a Gosign atende Barcelona a partir do escritório local

A Gosign mantém escritório próprio em Barcelona (gosign.es) com time espanhol e catalão - falantes nativos, gestão de projeto local, contato direto com AESIA, AEPD e CNMV. O escritório de Barcelona é hub regional para toda a península ibérica: Discovery Workshops, Sprint Reviews e steering acontecem presencialmente no cliente, no distrito 22@, no Pier01 ou diretamente nas sedes de CaixaBank, Cellnex, Mango, Damm e Grifols. Para Banco Sabadell, Seat em Martorell e Naturgy os workshops em espanhol ou catalão são padrão, a documentação de compliance é entregue bilíngue (ES e CA), e o Comité de Empresa senta à mesa desde o primeiro dia.

Escalações rumo a Hamburgo existem apenas para questões arquiteturais de fundo ou para integração a matrizes alemãs e suíças - operação diária, comunicação com o cliente e contato com as autoridades correm no time de Barcelona. O ecossistema de engenharia catalão é denso o suficiente para recrutar talento local e ancorá-lo no projeto. Para clientes brasileiros com operações espanholas, o eixo São Paulo - Barcelona - Hamburgo opera com mesma arquitetura e mesma equipe, resolvendo LGPD, RGPD + LOPDGDD e EU AI Act lado a lado.

## Por que Barcelona funciona como ponto de partida para Enterprise AI

A Espanha enfrenta uma onda dupla: supervisão AESIA e transposição do EU AI Act entram simultaneamente em operação. Quem constrói em Barcelona um piloto Cert-Ready by Design tem um caso de referência que passa no filtro AEPD e AESIA - e que depois é defensável em Madri, Bilbao, Valencia e Milão. Os clusters 22@Barcelona, Pier01 e o programa BStartup do Banco Sabadell entregam talento, parceiros piloto e acesso a investidores. A cidade é próxima o bastante de Madri e Bruxelas para reagir rápido a novidades regulatórias, e distante o suficiente para manter caráter tecnológico próprio. Trazemos do mercado alemão a experiência de construir sistemas que se mantêm produtivos sob regimes estritos - com [EU AI Act Governance](/br/governance/eu-ai-act/) na base e Audit Trail em nível SQL. Barcelona é o mercado certo para escalar essa disciplina no sul da Europa. Mais em [serviços AI Agents](/br/servicos/ai-agents/).

--- Agentes IA para Empresas em Belo Horizonte | Gosign ---
> Enterprise AI Agents para BH e Minas Gerais. LGPD-compliant, CLT-compatível. Mineração, siderurgia, energia. Gestão a partir de São Paulo.

## Belo Horizonte é o mercado onde a mineração brasileira defende sua credibilidade ESG - todos os dias

Minas Gerais produz metade do minério de ferro brasileiro e uma fatia relevante do aço, ouro e alumínio do país. Em Belo Horizonte e região sediam ou operam Vale (com ativos centrais em Nova Lima e Itabira, coordenados a partir de BH), Usiminas (siderurgia, com usinas em Ipatinga), AngloGold Ashanti, Magnesita Refratários, Localiza (maior locadora da América Latina com HQ global em BH) e Stellantis/Fiat Chrysler Brasil na planta de Betim. É o corredor industrial por onde passam todos os preços globais de aço e toda decisão de investidor ESG sobre mineração brasileira. E é o corredor onde os rompimentos de Mariana (2015) e Brumadinho (2019) redefiniram por 20 anos qualquer processo de "risk-based decision making". O que antes de 2019 passava como "modelagem de risco operacional" virou zona juridicamente sensível, onde toda recomendação algorítmica pode precisar ser defendida diante do Ministério Público Federal e de tribunais cíveis.

## As três barreiras regulatórias para IA no mercado de Belo Horizonte

A primeira é a **ANM (Agência Nacional de Mineração) pós-Brumadinho**. A ANM endureceu drasticamente desde 2019 as exigências sobre documentação de barragens, laudos de estabilidade e risk reporting (Resolução ANM 95/2022 e sucessoras). Qualquer componente algorítmico em monitoramento de barragens, análise de sensores ou classificação de risco precisa ser rastreável diante de auditores da ANM - Audit Trail até o nível do sensor. A coisa não é teórica: existem litígios em curso que pedem exatamente essa profundidade de evidência.

A segunda é o **IBAMA em conjunto com a SEMAD-MG**. O IBAMA federal e a Secretaria de Estado de Meio Ambiente e Desenvolvimento Sustentável de Minas Gerais exigem para operações mineradoras e industriais estudos detalhados de impacto ambiental (EIA/RIMA) e monitoramento contínuo. IA que estima emissões, otimiza parâmetros de processo ou classifica incidentes de segurança cai sob obrigações ambientais concretas, com explicabilidade documentada sob solicitação do auditor ambiental.

A terceira é a **LGPD em combinação com os sindicatos industriais** (Sindiextra na mineração, Sticcer na metalurgia e Sindimig no setor metal-mecânico). Os sindicatos são historicamente fortes em BH. Sistemas de IA que toquem escala de turno, alerta de segurança ou decisões de RH precisam ser negociados com o sindicato - LGPD-compliant e com Decision Layer que incorpore os workflows de consulta arquitetonicamente. A CLT (Consolidação das Leis do Trabalho) e os acordos coletivos regionais (CCT/ACT) fazem da consulta sindical pré-condição jurídica para qualquer HR Agent na região. Importante ressaltar: sindicato/CRE tem direito de consulta, não de veto direto sobre a IA - o PL 2338/2023, ainda em tramitação, é que definirá o framework regulatório brasileiro específico para IA.

## Cenários típicos de implementação em Belo Horizonte

**Dam Safety Monitoring na Vale**: Workflow Agents monitoram sensores em barragens de rejeitos em Itabira, Brucutu e outros sítios de Minas, cruzam com dados meteorológicos e relatórios de inspeção; o Decision Layer escala padrões de risco crítico com Human-in-the-Loop aos times de geotecnia. Cada decisão documentada para ANM, MPF e compliance interno - é a diferença entre linha de defesa e denúncia criminal.

**Gestão de frota na Localiza**: Document e Workflow Agents processam protocolos de manutenção, sinistros e dados de seguro da maior frota de locação da América Latina. O Decision Layer roteia escalações para oficinas parceiras e prioriza veículos críticos para inspeção, com histórico auditável por veículo. Depois da fusão com Unidas, a Localiza saltou para a terceira maior locadora do mundo, com volume e exigências de consistência algorítmica entre frotas regionais que só se entregam com arquitetura formal.

**Planejamento de produção siderúrgica na Usiminas**: Document Agents leem carteiras de pedidos, dados logísticos e perfis de consumo energético, gerando recomendações de produção para as usinas de Ipatinga e Cubatão. O Decision Layer escala para planejadores humanos quando há conflito com requisitos de segurança da ANM ou com contratos de energia da ANEEL. Workflow Agents alertam proativamente para riscos de parada ou quebras de cadeia e documentam cada recomendação com Audit Trail.

**Controle de qualidade na Stellantis Betim**: Document Agents processam protocolos de inspeção, indicadores de qualidade e relatórios de auditoria de fornecedores na maior planta Fiat fora da Itália. O Decision Layer escala desvios críticos com Human-in-the-Loop aos líderes de fábrica - Audit Trail atende tanto aos padrões Stellantis quanto às exigências do INMETRO para certificação veicular brasileira.

Em todos os cenários o [Decision Layer](/br/decision-layer/) impõe caminhos de escalação, Audit Trail e Governance by Design.

## Como a Gosign atende Belo Horizonte a partir de São Paulo

O escritório de [São Paulo](/br/agentes-ia-sao-paulo/) fica a 1 hora de voo de BH. Discovery Workshops com Vale, Usiminas ou Localiza acontecem presencialmente em BH ou nas próprias plantas - Itabira, Ipatinga, Betim. Revisões de compliance com foco em ANM ou IBAMA são conduzidas junto ao seu jurídico e a escritórios especializados em direito ambiental - em projetos de mineração, a interpretação regulatória no detalhe costuma ser mais decisiva que a arquitetura do modelo.

Consultas sindicais, quando agents de RH ou escala de turno entram em operação, passam por escritórios trabalhistas locais em BH e se apoiam nas estruturas Sindiextra, historicamente fortes na região. As fases de build rodam distribuídas entre Hamburgo e São Paulo - stand-ups pela manhã no horário SP, Sprint Reviews conjuntas com responsáveis de planta. Presença em BH se organiza em até 24 horas, inclusive para sítios remotos em Itabira ou Brucutu. Após o Go-Live, o escritório de SP é o ponto operacional com hotline de escalação em português.

## Por que Belo Horizonte funciona como ponto de partida para Enterprise AI

BH é o único mercado no Brasil onde realidade industrial (mineração, siderurgia, automotivo), pressão regulatória permanente (ANM pós-Brumadinho) e clusters de inovação (San Pedro Valley, P7 Creative Hub) coexistem no mesmo território. Quem aqui constrói um agente produtivo para segurança de barragens, otimização de produção ou reporting ESG, constrói sob as exigências de auditoria mais rigorosas da indústria brasileira - o que torna o caso exportável para qualquer outro mercado de mineração e aço no planeta, do Chile à Austrália Ocidental. A UFMG e a UFOP entregam talento em geotecnia, metalurgia e TI industrial em concentração inédita no Brasil. A arquitetura Cert-Ready by Design da Gosign garante que um agent testado em BH passe em auditorias de GDPR e EU AI Act na Europa - pré-condição para investidores ESG e para cadeias de fornecimento de clientes europeus, da ArcelorMittal à Volkswagen. Veja também [Rio de Janeiro](/br/agentes-ia-rio-de-janeiro/) e [Brasil em visão geral](/br/agentes-ia-brasil/).

--- Agentes IA para Empresas em Berlim | Gosign ---
> Enterprise AI Agents em Berlim. Gestão de projetos presencial, LGPD-compliant, auditável. De startups a ministérios - do PoC à operação independente.

## Berlim é o único mercado alemão em que ministério federal e startup Series-B precisam do mesmo fornecedor de IA

Nenhum outro local do espaço germanófono reúne essa amplitude. No quartel governamental sentam Chancelaria Federal, BMI (Ministério do Interior) e BMWK (Economia) com seus projetos de consolidação de TI e um volume de investimento que define a digitalização administrativa dos próximos anos. Três estações de metrô adiante trabalham N26, Solaris, Zalando e Delivery Hero em questões de escala que já não têm nada a ver com TI bancária clássica. A Cariad mantém em Berlim um hub de software que desenvolve a plataforma para os carros do grupo Volkswagen. A Deutsche Bahn opera a partir do Potsdamer Platz um dos maiores Data Offices corporativos da Alemanha, a SAP ancorou aqui seus Data Spaces, IBM e Microsoft mantêm escritórios com função de pesquisa e venda. Essa mistura impõe uma arquitetura que mapeia simultaneamente um procedimento administrativo com obrigação de manutenção de processos e um modelo KYC no N26 - com o mesmo Decision Layer e os mesmos requisitos de Audit Trail, mas com regras específicas de jurisdição e processo por cima.

## As três barreiras regulatórias que definem todo caso de IA em Berlim

A primeira é a supervisão da BaFin sobre as fintechs berlinenses. N26 e Solaris são licenciados como instituições CRR, as circulares da BaFin sobre MaRisk e BAIT valem em plena severidade, e ambas passaram nos últimos anos por várias inspeções especiais com exigências que moldaram o entendimento de mercado sobre expectativas regulatórias. Quem aqui quer construir um modelo AML ou de detecção de fraude com IA precisa de governance de modelo que os inspetores especiais da BaFin aceitem como cadeia de evidência - incluindo versionamento, justificativa de threshold e decisão reproduzível. (Para o leitor brasileiro: papel comparável ao da supervisão do BACEN (PT: Banco de Portugal) sobre Nubank e Stone, mas com uma autoridade sediada em Bonn.)

A segunda barreira é a administração pública. O BSI define com o IT-Grundschutz e seus padrões mínimos de IA o arcabouço, o BMI define através dos projetos de continuidade da Lei de Acesso Online como decisões automatizadas em procedimentos administrativos precisam ser protocoladas. Ambas exigem Audit Trail compatível com a obrigação de manutenção de autos. A terceira barreira é o próprio EU AI Act, que desde 2026 está em vigor para classificação de alto risco - decisões de RH, scoring de crédito e decisões administrativas caem em Berlim simultaneamente em pelo menos três áreas de aplicação. Mais contexto em [Governance EU AI Act](/br/governance/eu-ai-act/).

## Cenários típicos de implementação em Berlim

No setor público trata-se do processamento estruturado de pedidos recebidos - decisões de fomento, retomadas de processos, consultas de cidadãos - com atribuição clara ao despachante e nota de processo completa por passo de IA. Vemos pilotos em que Document Agents classificam documentos administrativos recebidos, extraem campos obrigatórios e transferem ao despachante responsável com indicação de completude ou anexos faltantes. No N26 e em bancos licenciados comparáveis vemos agentes de triagem AML que enriquecem hits do monitoramento de transações com histórico de cliente, dados KYC e fontes externas, fazem avaliação justificada de plausibilidade e preparam o Suspicious Activity Report para o Compliance Officer - o officer decide, o agente documenta sem lacunas.

A Deutsche Bahn trabalha em conceitos de Predictive Maintenance para trens e infraestrutura de via, em que a decisão de manutenção é tomada por um técnico certificado, mas o agente entrega o histórico de sensores e dados comparativos como proposta estruturada. A Cariad e casas similares de software OEM precisam de Code Review Agents que conheçam ASPICE e ISO 26262 e marquem mudanças críticas para revisão de arquitetura. Em Zalando e Delivery Hero vemos agentes de Customer Service e logística que estruturam ocorrências recorrentes e priorizam escaladas. O que une todos os cenários: nenhuma decisão totalmente automática, mas um [Decision Layer](/br/decision-layer/) com Human-in-the-Loop forçado nos pontos certos.

## Como a Gosign atende Berlim a partir do escritório local

Mantemos em Berlim um escritório próprio na Nogatstraße 46, em Neukölln - não é caixa postal, é local para gestão de projetos, Discovery Workshops e acompanhamento de mandatos do setor público. A sede continua em Hamburgo, de lá vêm Engineering e arquitetura de Governance, em Berlim sentam-se a gestão operacional dos projetos da capital. Concretamente: uma Discovery começa com um workshop de dois ou três dias na sua sede em Berlim ou no nosso escritório, na fase de Build trabalhamos remotamente com dois slots fixos por semana presencialmente, a entrada em operação fazemos novamente presencialmente.

Workshops de validação de modelo com inspetores especiais da BaFin ou com a auditoria interna de bancos licenciados acontecem por princípio presencialmente, porque é aqui que se constrói a relação de confiança com a supervisão. Visitas presenciais entre Tiergarten, Mitte e Adlershof são viáveis no mesmo dia - a conexão Hamburgo-Berlim pelo Hauptbahnhof leva menos de duas horas no ICE, o que mantém a camada de Engineering de Hamburgo flexivelmente disponível. Comunidades como Silicon Allee, Factory Berlin e CUBE usamos ativamente para estar tecnicamente visíveis também fora de reuniões com clientes e construir contatos com auditores que mais tarde ajudam em avaliações de conformidade. Para grupos brasileiros com operações alemãs e foco em digitalização da administração, coordenamos a partir do nosso [escritório em São Paulo](/br/agentes-ia-sao-paulo/) com a equipe de Berlim.

## Por que Berlim funciona como ponto de partida para Enterprise AI

A capital é o único lugar da Alemanha em que se pode combinar marco político, prática regulatória e velocidade empresarial em uma agenda diária. Quem aqui coloca um primeiro agente em produção, defendeu-o tipicamente contra três grupos de stakeholders simultaneamente: auditoria corporativa, proteção de dados e conselho de empresa. Esse triplo endurecimento é também a melhor preparação para escalada em outras regiões. Soma-se a disponibilidade de dados e compute pelo BerlinIX e por endereços Telehouse com conexões diretas às grandes regiões hyperscaler, um pool crescente de talento ML Engineering pela TU, HPI e Berlin School of Business and Innovation, e uma rede densa de comunidades e meetups de IA que normaliza a troca de boas práticas. A proximidade física entre tomadores de decisão políticos, praticantes de supervisão e fundadores tech em uma área urbana encurta os caminhos para alinhamento de stakeholders de uma maneira que não existe em nenhum outro mercado alemão. Quem em 4-6 semanas tem aqui um Decision Layer com Audit Trail produtivo, atende Cert-Ready by Design exatamente para os stakeholders que em corporações geralmente têm a maior força de bloqueio. Mais sobre o procedimento em [serviços AI Agents](/br/servicos/ai-agents/).

--- Agentes IA para Empresas em Bilbao | Gosign ---
> Enterprise AI Agents para Bilbao e País Basco. Indústria, energia, banca. EU AI Act compliant, LGPD-compliant. Gestão a partir de Barcelona.

## Bilbao é a única cidade espanhola onde indústria pesada e infraestrutura de energia exigem compliance ao mesmo tempo

O País Basco é a antítese industrial do sul turístico da Espanha. Em Bilbao e na Bizkaia sediam-se a Iberdrola - gigante global de energia com sede na Torre Iberdrola - a Petronor (refinaria Repsol em Muskiz), a CAF (Construcciones y Auxiliar de Ferrocarriles) como fabricante ferroviário, Tubacex e Sidenor na siderurgia e o grupo Kutxabank. O BBVA mantém uma presença histórica em Bilbao com funções operacionais relevantes até hoje, e a Euskaltel é a base regional de telecom. Quem constrói IA em Bilbao constrói para redes elétricas, altos-fornos, frotas de trens e plataformas cuja parada é medida em milhões por hora - contexto próximo também a grupos brasileiros industriais com operações na Europa ou com parcerias na cadeia automotiva e de energia.

## As três barreiras regulatórias para IA no mercado basco

A primeira é o **regime duplo de proteção de dados**. A Espanha é o único país da UE com autoridade regional de proteção de dados em paralelo à nacional: a AVPD (Agencia Vasca de Protección de Datos) tem jurisdição no País Basco para entidades públicas e parte das empresas regionais, enquanto a AEPD (Agencia Española de Protección de Datos) cobre o restante. Ambas aplicam a LOPDGDD (Ley Orgánica 3/2018) e auditam decisões automatizadas com rigor. Quem opera com dado pessoal no País Basco precisa pensar a arquitetura de compliance para os dois endereços regulatórios.

A segunda é a dupla **CNMV e Banco de España** para a lógica financeira de BBVA e Kutxabank. Os dois bancos usam modelos de risco apoiados em IA há anos, mas desde 2024 a CNMV exige explicabilidade completa dos modelos que entram em recomendação de investimento. Audit Trail, reprodutibilidade e caminhos de escalação deixaram de ser discutíveis.

A terceira é o **EU AI Act combinado com regimes de segurança industrial**. A Iberdrola opera infraestrutura de alta tensão, a CAF fabrica material ferroviário - em ambos os domínios o EU AI Act incide com categorias de alto risco (infraestrutura energética, transporte crítico) somando-se a padrões setoriais de segurança (UNE-EN, IEC 61508). Aqui, [EU AI Act Compliance](/br/governance/eu-ai-act/) não é "revisar proteção de dados", é certificar o modelo de IA como peça crítica de segurança. Para grupos brasileiros que exportam para a UE ou integram cadeias europeias, o Decision Layer precisa atender simultaneamente LGPD no Brasil e o regime europeu - mesma arquitetura.

## Cenários típicos de implementação em Bilbao

**Smart Grid na Iberdrola**: os modelos definem quando qual gerador assume qual carga em operações transnacionais. Cada decisão é documentada para o operador regional de rede, Audit Trail é pré-condição para participação de mercado. Workflow Agents e o Decision Layer preservam a cadeia de justificativa completa.

**Risk Scoring no BBVA**: modelos para decisões de crédito no midmarket basco precisam ser justificáveis ao cliente sob o Art. 22 do GDPR. Document Agents preparam dossiês; o Decision Layer escala casos fronteiriços ao analista humano com Audit Trail e score de confiança.

**Predictive Maintenance na CAF**: a CAF mantém frotas em vários países europeus e usa telemetria para priorizar intervenções - as recomendações precisam ser rastreáveis diante de autoridades reguladoras em cada país operador. Workflow Agents monitoram padrões e escalam anomalias críticas.

**Controle de qualidade na Tubacex**: na produção de aço inox especial cada decisão automática de refugo precisa permanecer defensável diante de grandes compradores como Aramco ou Equinor. Document Agents armam os dossiês de qualidade; o Decision Layer preserva a justificativa por batch.

Em todos os quatro cenários fala-se de IA industrial com efeito sobre ativos físicos. O [Decision Layer](/br/decision-layer/) entrega a arquitetura que equipa decisões com Audit Trail, escalação Human-in-the-Loop e Cert-Ready by Design. Uma peculiaridade basca: a tradição cooperativa ao redor de Mondragon molda também as empresas não cooperativas da região. Participação dos trabalhadores em decisões tecnológicas aqui não é questão de compliance, é parte da cultura de negócio. Construímos o Decision Layer de modo que as obrigações de consulta ao Comité de Empresa e as estruturas cooperativas de governança sejam atendidas arquitetonicamente - workflow integrado, não consulta posterior.

## Como a Gosign atende Bilbao a partir de Barcelona

A Gosign atende projetos bascos a partir do escritório de Barcelona (gosign.es) com gerentes de projeto e engenheiros falantes de espanhol. O voo direto Barcelona-Bilbao leva cerca de uma hora - presença na Torre Iberdrola, no BBVA, na CAF em Beasain, na Tubacex e no cluster BEAZ é possível em um dia útil. O time espanhol opera dentro das particularidades da região: o regime duplo de proteção de dados AVPD + AEPD, a tradição cooperativa Mondragon com suas estruturas de co-determinação, e o bilinguismo entre espanhol e euskara que convive em discussões técnicas. Quando necessário incorporamos stakeholders em euskara diretamente nos workshops.

A sede em Hamburgo cobre temas de compliance UE-wide e questões arquiteturais de fundo, além da integração a padrões industriais alemães - a entrega operacional, a linguagem de engenharia da indústria pesada basca e as cadeias curtas de decisão do País Basco ficam no time de Barcelona. Para clientes brasileiros, o eixo São Paulo - Barcelona - Bilbao opera com mesma arquitetura: LGPD e LOPDGDD + AVPD lado a lado, sem retrofit.

## Por que Bilbao funciona como ponto de partida para Enterprise AI

Quem entrega em Bilbao um piloto industrial de IA produtivo tem um caso de referência que passou em auditoria dupla de proteção de dados (AEPD + AVPD), em padrões CNMV e na lógica de alto risco do EU AI Act - em nenhum outro ponto da Espanha a barra é tão alta. O cluster BEAZ, a Bizkaia Startup Bay e o Mondragon Innovation Hub entregam ecossistema, talento e parceiros piloto. Empresas bascas têm a vantagem de pensar longo: projetos de IA não são plano trimestral, são investimento plurianual. Trazemos a disciplina de construir sistemas que não apenas funcionam, mas se sustentam em auditoria - com Governance by Design, Audit Trail e a seriedade que a compliance industrial exige. Bilbao é o mercado certo para escalar essa disciplina no norte da Espanha. Vantagem geográfica adicional: do País Basco alcança-se a indústria aeroespacial do sul da França (Toulouse), a farmacêutica de Lyon e a faixa tech-industrial do norte de Portugal (Porto) - um caso construído em Bilbao é exportável para todo o arco atlântico da Europa ocidental. Mais em [serviços AI Agents](/br/servicos/ai-agents/).

--- Agentes IA para Empresas no Brasil | Gosign ---
> Enterprise AI Agents para o Brasil. LGPD-compliant, CLT-compatível, preparado para PL 2338/2023. Escritório em São Paulo, projetos em todo o Brasil.

## O Brasil é o único mercado da América Latina onde a Gosign opera com presença local real

O Brasil não é "mais um mercado latino-americano". Com mais de 215 milhões de habitantes, a nona maior economia do mundo e um arcabouço regulatório próprio (LGPD, Resolução BACEN 4893, PL 2338/2023) que convive em paralelo com o direito europeu, o país é um universo de compliance autônomo. A Gosign mantém por isso um escritório em São Paulo que não cobre apenas a metrópole paulistana, mas o país inteiro do ponto de vista operacional - da Petrobras no Rio, à Caixa em Brasília, Vale em Minas, Volvo em Curitiba. É o pré-requisito para que os padrões Enterprise AI europeus (Audit Trail, Cert-Ready by Design, Decision Layer com Human-in-the-Loop) funcionem em um mercado aparentado ao EU AI Act, mas distinto dele.

## As três barreiras regulatórias para IA no mercado brasileiro

A primeira é a **LGPD (Lei Geral de Proteção de Dados, Lei 13.709/2018) - resposta brasileira ao GDPR, não sua tradução**. Tem fundamentos legais próprios, exigências próprias de DPO, sanções próprias e a ANPD (Autoridade Nacional de Proteção de Dados) como autoridade fiscalizadora, com sede em Brasília. Quem vem da Europa para o Brasil não pode tratar a LGPD como "variante do GDPR": a interpretação dos Art. 7 (bases legais) e Art. 11 (dados sensíveis) diverge no detalhe de maneira significativa. A arquitetura de IA precisa atender LGPD e GDPR em paralelo, não em substituição.

A segunda é a **Resolução BACEN 4893, o DORA brasileiro**. Os requisitos de resiliência cibernética para instituições financeiras reguladas (Itaú, Bradesco, Santander Brasil, Banco do Brasil, Caixa, Nubank, Stone, XP) foram desenhados de forma independente do direito europeu. Qualquer componente algorítmico em decisões de crédito, fraud scoring, AML/KYC ou operações de mercado de capitais precisa ser auditável perante o BACEN - com obrigações de reporte que divergem de implementações DORA europeias. Acrescente-se CVM para S.A. listadas, SUSEP para seguros e Coaf para PLD.

A terceira é o **PL 2338/2023, o projeto de lei brasileiro de IA**. É inspirado no EU AI Act, mas não idêntico; em 2026 ainda não está em vigor, esperado para os próximos 18-24 meses. Classes de risco, dever de supervisão humana e padrões de explicabilidade são similares, mas com acentos brasileiros próprios (sobretudo na relação com sindicato e CRE para sistemas trabalhistas). Cert-Ready by Design no Brasil significa arquitetar de modo a servir simultaneamente LGPD hoje, PL 2338 a partir de 2027 e EU AI Act para operações DACH. Importante: o EU AI Act não se aplica diretamente ao Brasil - apenas filiais de grupos europeus com dados de cidadãos UE.

## Cenários típicos de implementação no Brasil

**Banking e fintech**: KYC/AML em [Itaú, Bradesco, Santander Brasil e Banco do Brasil](/br/agentes-ia-sao-paulo/) - Document Agents lêem CPF/CNPJ, cruzam com listas do Coaf; o Decision Layer escala acertos de alto risco com Audit Trail completo. Mesmo padrão em Nubank, Stone, PagSeguro e XP Inc. com fraud detection e reporte BACEN em tempo real.

**Mineração e energia**: Dam Safety da Vale em [Minas Gerais](/br/agentes-ia-belo-horizonte/) e documentação de ativos da Petrobras no [Rio](/br/agentes-ia-rio-de-janeiro/) - Workflow Agents monitoram sensores, laudos e indicadores externos de risco. O Decision Layer escala padrões críticos com Human-in-the-Loop. Audit Trail defensável diante de ANM, MPF, ANP e ANEEL.

**Indústria e automotivo**: Volvo, Renault, VW e Klabin em [Curitiba](/br/agentes-ia-curitiba/) - Document Agents para supply chain, compliance Mercosul e reporting ESG. Workflow Agents para controle de qualidade e planejamento de manutenção. Cert-Ready para auditorias GDPR em matrizes europeias.

**Setor público**: análise de crédito Caixa e policy analysis da ANPD em [Brasília](/br/agentes-ia-brasilia/) - Document Agents para pedidos de benefício social, Workflow Agents para monitoramento regulatório. Audit Trail nos requisitos do TCU, com dossiês de justificativa por recomendação algorítmica. Projetos de setor público no Brasil rodam sob regimes próprios de licitação e padrões próprios de proteção de dados de cidadão - atender a esse quadro é pré-condição para renovação contratual.

## Como a Gosign atende o Brasil a partir de São Paulo

O escritório de [São Paulo](/br/agentes-ia-sao-paulo/) é o hub operacional para o país - com gerentes de projeto locais que conduzem Discovery Workshops presencialmente, participam de revisões de compliance com DPO e jurídico, e acompanham consultas sindicais. A partir de SP, Rio (1 h de voo), Belo Horizonte (1 h), Curitiba (1 h), Brasília (1,5 h) e Porto Alegre (1,5 h) ficam no mesmo dia - presença em 24 horas. A fase técnica de build roda distribuída entre Hamburgo e São Paulo, com stand-ups pela manhã no horário SP. Após o Go-Live o escritório de SP é o ponto operacional com hotline de escalação em português.

Para clientes brasileiros com operações europeias (Natura na UE, JBS na UE) é a única configuração que traz LGPD e GDPR sob o mesmo teto. O que torna isso atraente também para médias empresas e corporações DACH: quem expande da Alemanha, Áustria ou Suíça para o Brasil tem um interlocutor que cobre os dois lados operacionalmente - a matriz DACH fala com Hamburgo, a filial brasileira fala com São Paulo. Workshops em dois idiomas. Uma arquitetura construída em SP vai para Lisboa, Madri ou Berlim com ajustes mínimos, porque os componentes de Audit, Decision Layer e Cert-Ready by Design já atendem aos dois mundos regulatórios. Para operações lusófonas o eixo São Paulo - Lisboa permite coordenar LGPD e RGPD com mesma equipe.

## Por que o Brasil funciona como ponto de partida para Enterprise AI

O Brasil é o único mercado latino-americano onde compliance bancário, operações industriais, setor público e cadeias de consumo convivem em um só arcabouço regulatório. Quem aqui constrói agents produtivos para KYC, reporting ESG ou segurança de barragens leva o blueprint para México, Argentina, Chile, Colômbia e Peru. O escritório em SP posiciona a Gosign como fornecedora europeia com presença LATAM real - combinação que praticamente ninguém tem no cenário DACH. A arquitetura Governance by Design garante que um agent construído no Brasil passe igualmente em auditorias GDPR e EU AI Act na Europa e em fiscalizações BACEN, ANPD ou TCU no Brasil. Mais na [área de contato](/br/contato/) ou nos perfis municipais de [São Paulo](/br/agentes-ia-sao-paulo/), [Rio](/br/agentes-ia-rio-de-janeiro/) e [Brasília](/br/agentes-ia-brasilia/). Também atendemos clientes em [Lisboa](/br/agentes-ia-lisboa/) para o eixo lusófono.

--- Agentes IA para Empresas em Brasília | Gosign ---
> Enterprise AI Agents para Brasília. LGPD-compliant, compatível com legislação do setor público. Agentes auditáveis para governo e finanças.

## Brasília é o mercado onde a regulação brasileira de IA é efetivamente decidida

Brasília não tem sedes corporativas como São Paulo e não tem clusters industriais como Belo Horizonte - mas tem algo que essas cidades não têm: todos os reguladores nacionais reunidos em um mesmo planalto. A ANPD (Autoridade Nacional de Proteção de Dados) fica no Setor Comercial Sul. O BACEN (Banco Central do Brasil) opera no Setor Bancário Sul. CADE, ANATEL, ANVISA e ANM ficam em um raio de 5 km. Acrescente-se Caixa Econômica Federal e Banco do Brasil com sedes no Setor Bancário, o Ministério da Fazenda, o STF e o STJ. Quem constrói IA em Brasília para uma autarquia federal, um banco federal ou um grupo regulado, constrói sob os olhos do próprio regulador. Isso torna Brasília o mercado mais estratégico do país para quem leva a sério Public Sector AI ou Banking AI regulado - aqui não só se regula, também se compra.

## As três barreiras regulatórias para IA no mercado de Brasília

A primeira é a **ANPD, que aqui não é abstrata - é a autoridade na sua cidade**. A supervisão da LGPD para bancos federais, órgãos da administração direta e dados governamentais sai de Brasília. Quem constrói aqui IA que processa dados de cidadão (benefícios sociais, tributos, saúde) precisa atender o Art. 23 da LGPD (setor público) e a Resolução CD/ANPD 02/2022 sobre DPIAs - auditável, documentado, verificável a qualquer tempo.

A segunda é a **auditabilidade TCU para despesa federal**. O Tribunal de Contas da União fiscaliza toda despesa federal quanto à economicidade e à legalidade. Qualquer componente algorítmico em crédito Caixa, scoring do Banco do Brasil ou otimização de rotas dos Correios precisa ser explicável a auditores do TCU com caminho de decisão completo. Audit Trail aqui não é "best practice" - é condição para que o órgão sequer mantenha o contrato com o fornecedor.

A terceira é o **PL 2338/2023, que se negocia exatamente aqui**. O projeto de lei brasileiro de IA tramita entre a Câmara dos Deputados e o Senado Federal - ambos em Brasília. Quem constrói aqui, constrói em uma cidade onde a minuta regulatória muda entre semanas de sessão plenária. Cert-Ready by Design é a única estratégia que sobrevive a essa volatilidade: arquitetar de modo que classificação de alto risco, supervisão humana e obrigações de explicabilidade possam ser ativadas depois. Importante: o EU AI Act não se aplica diretamente ao Brasil; a conversa aqui é PL 2338, não GDPR.

## Cenários típicos de implementação em Brasília

**Análise de crédito na Caixa Econômica Federal**: Document Agents processam pedidos de crédito no Minha Casa Minha Vida, cruzam com dados do CadÚnico e burô de crédito; o Decision Layer escala decisões com Human-in-the-Loop ao analista - cada aprovação com dossiê auditável para exame do TCU. O cuidado extra: em programa social federal, a fila de crítica do TCU é dupla (economicidade e equidade).

**Policy Analysis para Government Advisory**: Document Agents varrem Resoluções da ANPD, interpretações da LGPD e consultas públicas, produzindo relatórios diários de situação regulatória para times de compliance em órgãos federais. Workflow Agents alertam a cada novo trecho do PL 2338/2023 com impacto na arquitetura.

**Detecção de fraude no Banco do Brasil**: Document e Workflow Agents monitoram padrões de transação em tempo real, escalam ocorrências suspeitas ao Compliance Officer e documentam cada detection com Audit Trail completo - inclusive scores de confiança e versionamento de modelo para reporte ao Coaf e auditorias do BACEN (PT: Banco de Portugal). Em bancos federais a densidade regulatória é maior que em privados: somam-se CGU (Controladoria-Geral da União) e TCU com demandas próprias.

**Otimização de rotas nos Correios**: Document e Workflow Agents processam volumes de envio, clusters de CEP e capacidade de distribuição e propõem rotas otimizadas para a maior logística postal do Brasil. O Decision Layer mantém arquitetonicamente os requisitos ANATEL para prazos de entrega e os da CLT para jornada dos carteiros - cada recomendação com dossiê auditável para o TCU.

Em todos os cenários o [Decision Layer](/br/decision-layer/) impõe Audit Trail, Human-in-the-Loop e Governance by Design.

## Como a Gosign atende Brasília a partir de São Paulo

O escritório de [São Paulo](/br/agentes-ia-sao-paulo/) fica a 1,5 hora de voo de Brasília. Discovery Workshops com Caixa, Banco do Brasil ou autarquias acontecem presencialmente no Setor Bancário e no Setor Comercial. Revisões de compliance com foco em ANPD ou TCU são conduzidas junto ao seu jurídico em Brasília - a proximidade ao regulador aqui é vantagem operacional, pois reuniões de esclarecimento com a ANPD são organizadas mais rápido para quem tem presença regular do que para fornecedor puramente remoto.

As fases técnicas de build correm distribuídas entre Hamburgo e São Paulo. Stand-ups pela manhã no horário SP, Sprint Reviews com seu time em Brasília. Presença em Brasília se organiza em 24 horas. Em projetos de Governo trabalhamos com escritórios de advocacia locais para o marco jurídico-administrativo - Lei 14.133/2021 (nova Lei de Licitações), enquadramento de aquisição e especificidades da LGPD para o setor público são território que não cobrimos internamente, acompanhamos com parceiros jurídicos.

## Por que Brasília funciona como ponto de partida para Enterprise AI

Brasília é o único mercado do Brasil onde regulador e regulado de nível federal moram na mesma cidade. Quem aqui constrói um agente produtivo para análise de crédito Caixa, reporting BACEN ou Government Advisory, constrói em contexto onde o feedback regulatório não chega "em 6 meses na auditoria", chega na próxima semana de sessão. Os clusters - Sebrae HQ, BioTIC Park, UnB - entregam talento e parceiros de pesquisa. Como mercado de Public Sector, Brasília funciona especialmente bem para fornecedores com profundidade de auditoria europeia (GDPR) combinada com prontidão para LGPD e PL 2338 - Governance by Design em vez de patches de compliance. Quem constrói um agente para autarquia ou banco federal, constrói de fato sob um regime jurídico de direito público de contratação, e aí a diferença entre "modelo auditável depois" e arquitetura Cert-Ready by Design é a diferença entre renovação e rescisão contratual. Mais em [Brasil em visão geral](/br/agentes-ia-brasil/) ou no [perfil de São Paulo](/br/agentes-ia-sao-paulo/) para a conexão operacional.

--- Agentes IA para Empresas em Colônia | Gosign ---
> Enterprise AI Agents para Colônia. Mídia, varejo, seguros - IA auditável para setores documentais intensivos. LGPD-compliant by design.

## Colônia é o único local alemão em que autoridade europeia de aviação, autoridade federal de alimentos e grupos privados de mídia ficam dentro do raio de um deslocamento diário

No corredor entre o Aeroporto Köln-Bonn, o centro e o Mediapark sentam RTL Deutschland como o maior grupo privado de TV da Europa, a Ford-Werke em Niehl com a segunda maior planta europeia da Ford, o Rewe Group com a sede corporativa próxima a Stolwerk, DEVK e Gothaer como duas grandes seguradoras de Colônia, e a Toyota Deutschland em Köln-Marsdorf. O TÜV Rheinland está em Colônia e é uma das mais importantes autoridades europeias de certificação. Em Köln-Bonn vizinha fica a EASA como autoridade europeia de aviação, em Bonn fica o BLE como Agência Federal para Agricultura e Alimentação. A Lufthansa tem sua sede em Köln-Deutz. Essa combinação de indústria, mídia, seguro e vários atores regulatórios cria um mercado em que processos intensivos em documentos e decisões auditáveis são rotina diária.

## As três barreiras regulatórias que moldam toda iniciativa de IA no mercado de Colônia

A primeira é a supervisão de seguros para DEVK, Gothaer e as subsidiárias de resseguro aqui sediadas. As exigências da BaFin sobre risco de modelo e o reporting Solvência II valem para cada componente de IA em regulação de sinistros, tarifação ou reservas. A segunda barreira é o bloco de compliance de mídia e dados na RTL e em endereços comparáveis - o tratado de mídia, as especificidades da LGPD/GDPR para plataformas financiadas por publicidade e o Digital Services Act estabelecem limites claros sobre o que a IA pode fazer em recomendação e moderação. (Para o leitor brasileiro: o paralelo seria o conjunto SUSEP (PT: ASF) + ANCINE + Marco Civil da Internet atuando simultaneamente sobre uma única cidade.)

A terceira barreira é relevante para a EASA e para a Lufthansa e seus parceiros de MRO: Continuing Airworthiness, manutenção Part-145 e exigências Part-M precisam ser comprovadas para componentes de IA no ambiente de manutenção em uma história de modelo auditável. Soma-se o próprio TÜV Rheinland como ator certificador, que para muitas avaliações de conformidade relevantes para o EU AI Act é a referência técnica - uma relação que empresas de Colônia devem construir cedo, porque a avaliação de conformidade de sistemas de IA de alto risco está sob responsabilidade de organismos notificados como o TÜV. Também o BLE em Bonn é relevante para REWE e varejistas comparáveis, quando componentes de IA em gestão de sortimento ou avaliação de fornecedores entram em uso. Quem em Colônia constrói uma arquitetura de IA, planeja [Cert-Ready by Design](/br/governance/eu-ai-act/) como padrão.

## Cenários típicos de implementação em Colônia

No Rewe Group e no varejo alimentar mais amplo vemos agentes de sortimento e cadeia de suprimentos que consolidam números regionais de venda, sazonalidade e dados de fornecedor numa proposta para o Category Manager - com documentação clara, porque o varejo alimentar está sob exigências LMIV e sob a Lei de Cadeia de Suprimentos simultaneamente. Na Ford-Werke agentes trabalham em Use Cases de planejamento de produção e dados de qualidade, em que um Production Engineer toma a decisão final. No ambiente de seguros em DEVK e Gothaer agentes apoiam a regulação de sinistros com enriquecimento estruturado da comunicação do sinistro em torno de contrato, histórico e laudos.

A RTL Deutschland e a Lanxess (para compliance de plástico e química especial) precisam de Document Agents para análise de contratos e fichas de segurança. No próprio TÜV Rheinland Knowledge Agents para a gestão de documentação de teste e textos de norma são relevantes - com versionamento claro e Audit Trail. A Lufthansa e sua filial MRO Lufthansa Technik (com sede em Hamburgo, mas conexões com Colônia) trabalham com Document Agents na preparação de documentação de manutenção, em que um Continuing Airworthiness Manager toma a decisão final. Na Toyota Deutschland em Köln-Marsdorf vemos Service Ticket Agents e no recall management uma lógica de enriquecimento que combina dados VIN, histórico de oficina e compliance de fornecedor. Na DEVK como grande seguradora de veículos em Colônia, os agentes de regulação de sinistros são especialmente relevantes, porque o volume de sinistros de seguro automóvel obriga alta eficiência de processamento. A decisão final é em qualquer caso de um técnico inspetor qualificado, e o [Decision Layer](/br/decision-layer/) mantém justificativa e caminho.

## Como a Gosign atende Colônia a partir de Hamburgo

A Gosign não tem escritório em Colônia - o acompanhamento presencial é organizado a partir de Hamburgo e Berlim. O ICE direto Hamburgo-Colônia é uma das ligações mais rápidas da Alemanha, encontros presenciais são viáveis no mesmo dia. Concretamente: Discovery Workshops com Engineering, Compliance e cogestão fazemos presencialmente em Köln-Mediapark, à beira do Reno ou diretamente no cliente - geralmente como bloco de dois ou três dias. Na fase de Engineering combinamos trabalho remoto com dias presenciais quinzenais para revisões de arquitetura e atualizações de stakeholders.

Briefings com o TÜV Rheinland para a avaliação de conformidade EU AI Act acontecem sempre presencialmente, porque é aqui que se constroem as relações com auditores que mais tarde ajudam na avaliação de conformidade. Clusters como o Mediapark, o Startplatz Köln e a rede de IA da IHK Köln (a maior câmara de indústria e comércio da Alemanha) são espaços ativos para networking técnico, sessões com auditores e contatos com as médias empresas renanas. A distância Köln-Bonn é pequena o suficiente para que encontros relevantes para a EASA sejam combinados no mesmo dia - uma logística que oferece vantagem clara para Use Cases próximos à aviação. Para grupos brasileiros com operações em Colônia (Embraer mantém operações de manutenção próximas da EASA), coordenamos a partir do [escritório em São Paulo](/br/agentes-ia-sao-paulo/) com a equipe de Hamburgo.

## Por que Colônia funciona como ponto de partida para Enterprise AI

Quem coloca um Use Case de IA em produção em Colônia, tem a vantagem de defendê-lo em um dos mais importantes locais europeus de certificação - o TÜV Rheinland está fisicamente presente e é, para muitas avaliações de conformidade EU AI Act, a referência natural. Isso acelera consideravelmente a escalada posterior, porque a relação de auditoria é construída cedo. Soma-se a diversidade setorial - mídia, varejo, seguros, química, automotivo - que serve como teste para a transferibilidade de uma arquitetura de IA para regimes de compliance diferentes. Colônia ainda fica geograficamente perto de Düsseldorf, Bonn e da região Reno-Meno, o que simplifica encontros multi-regionais com stakeholders. Quem em 4-6 semanas tem um primeiro Document Agent com Audit Trail completo em produção em uma corporação de Colônia, tem uma referência que o TÜV Rheinland conhece - o que simplifica a posterior avaliação de conformidade. Mais sobre o procedimento em [serviços AI Agents](/br/servicos/ai-agents/).

--- Agentes IA para Empresas em Cracóvia | Gosign ---
> Enterprise AI Agents em Cracóvia. Gestão de projetos local, EU AI Act compliant by design, LGPD-compliant. Do PoC à operação independente.

## Cracóvia é a capital de shared services da Polônia - e exatamente por isso o site de IA mais difícil

Cracóvia abriga a maior concentração de Global Capability Centers da Europa Central. ABB Kraków opera aqui sua documentação de engenharia global, Cisco Kraków um dos maiores times de desenvolvimento de software fora dos EUA, IBM Kraków um Delivery Center com milhares de consultores, mais ING Hubs Kraków, Capgemini, Motorola Solutions, EY GDS e a polonesa Comarch. O que esses sites têm em comum: processam dados de várias jurisdições da UE, seus outputs caem nos livros contábeis de matrizes do oeste europeu, e cada decisão de IA precisa resistir simultaneamente à UODO polonesa, à transposição do RODO e aos reguladores das matrizes. Cracóvia não é apenas uma cidade polonesa - é a sala de máquinas de muitos grupos europeus. Contexto relevante também para grupos brasileiros que contratam shared services ali.

## As três barreiras regulatórias para IA no mercado de Cracóvia

A primeira é o **RODO + a lei polonesa de proteção de dados** (ustawa o ochronie danych osobowych): o UODO (Urząd Ochrony Danych Osobowych) exige em decisão automatizada bases documentadas, explicações acessíveis e Audit Trail completo. Como os GCCs de Cracóvia processam dados da Alemanha, França, Países Baixos e Escandinávia, toda decisão de IA precisa resistir também às autoridades nacionais dos países de origem - arquitetura que atenda só ao RODO é insuficiente para shared services de grupo.

A segunda é a **supervisão da KNF** para o número crescente de operações bancárias e de seguros em Cracóvia: ING Hubs Kraków, Aon, Brown Brothers Harriman e outros serviços financeiros estão sob supervisão direta ou indireta da Komisja Nadzoru Finansowego. Em transaction monitoring, AML screening e sugestões de underwriting, a KNF espera os mesmos lastros exigidos pela BaFin alemã ou pela DNB holandesa - bases de modelo rastreáveis e decisão humana final registrada.

A terceira é o **EU AI Act, em vigor na Polônia desde fevereiro de 2025 para práticas proibidas e, pela legislação vigente, a partir de 2 de agosto de 2026 para sistemas de alto risco** (adiamento para dezembro de 2027 acordado provisoriamente - Digital Omnibus, maio de 2026): screening de RH, avaliação de risco de crédito e identificação biométrica entram na categoria de alto risco. Sites de Cracóvia que desenvolvem ou operam esses sistemas para matrizes precisam demonstrar Conformity Assessment, risk management e post-market monitoring - dívida técnica que dificilmente se salda depois. Importante para o leitor brasileiro: o EU AI Act não se aplica diretamente ao Brasil; aqui na Polônia aplica-se com toda força, enquanto o PL 2338/2023 segue em tramitação do lado brasileiro.

## Cenários típicos de implementação em Cracóvia

**QA de software bancário na Comarch**: a suite bancária da Comarch é usada por centenas de instituições financeiras polonesas e centro-europeias. Document Agents verificam release notes, atualizações regulatórias e documentação de patch contra exigências da KNF antes de cada entrega - com Audit Trail até o PR de origem.

**Documentação de engenharia na ABB Kraków**: o centro global de engenharia da ABB em Cracóvia gera diariamente milhares de documentos técnicos em múltiplas línguas. Workflow Agents extraem especificações regulatoriamente relevantes, cruzam contra normas nacionais e roteiam conflitos automaticamente a reviewers humanos.

**Transaction monitoring no ING Hubs**: em shared service ING com milhões de transações por dia, cada segundo de atraso define obrigação de report regulatório. O Decision Layer roteia casos suspeitos pelas faixas de KNF e DNB, com Human-in-the-Loop obrigatório em cada escalação final.

**Delivery operations na Capgemini**: times de Cracóvia atendem grandes clientes em vários países da UE. Service-Desk routing classifica tickets por idioma, tenant e caminho de escalação - cada decisão auditável contra o padrão regulatório aplicável.

Em todos os cenários o [Decision Layer](/br/decision-layer/) persiste Audit Trail, Governance by Design e escalação Human-in-the-Loop.

## Como a Gosign atende a Polônia a partir de Cracóvia

A Gosign mantém escritório próprio em Cracóvia (gosign.pl) com gerentes de projeto, engenheiros e responsáveis de compliance falantes de polonês - native Polish e English speakers, que trabalham presencialmente com o cliente no Krakow Technology Park, no Hub:raum ou em salas da matriz. Discovery Workshops, Sprint Reviews e steering rodam sem barreira de idioma e sem overhead de viagem, com a representação da Rada Zakładowa à mesma mesa. Importante: na Polônia a Rada Zakładowa tem direitos de consulta, não de veto.

Cracóvia atua como hub regional para toda a Polônia: a maior parte dos sites ABB, Cisco, Capgemini e IBM fica na mesma cidade; Varsóvia, Wrocław e Gdańsk ficam em um dia de viagem. A sede em Hamburgo entrega revisões arquiteturais, expertise DACH de compliance e integração com matrizes alemãs e suíças - delivery, dia a dia e contato com cliente ficam no time de Cracóvia. Para um país com mais de 350.000 engenheiros de TI, essa é a única formação que funciona: ancoragem local, conectividade UE inteira. Para clientes brasileiros com shared services em Cracóvia o eixo São Paulo - Cracóvia - Hamburgo resolve LGPD e RODO em paralelo.

## Por que Cracóvia funciona como ponto de partida para Enterprise AI

Cracóvia tem três propriedades que a tornam ponto de entrada singular. Primeira, densidade de talento: Krakow Technology Park, Hub:raum e o cluster Krakow Startups formam o maior ecossistema tecnológico entre Berlim e Viena, com milhares de engenheiros multilíngues treinados em processos corporativos. Segunda, realidade multi-jurisdicional: quem constrói em Cracóvia um agent de conformidade para ABB, Cisco ou ING, implicitamente construiu para toda a Europa Ocidental - a arquitetura que resiste à UODO polonesa, DNB holandesa e BaFin alemã ao mesmo tempo vira só configuração em qualquer outro país. Terceira, maturidade operacional: GCCs de Cracóvia trabalham há mais de quinze anos com grupos do oeste europeu, os processos internos de Change Management, ITIL, ISO 27001 e SOX-Compliance estão rodados. Introduzir um novo Decision Layer aqui não significa aprender nova disciplina de compliance, significa adicionar um controle a mais ao que já existe. Cert-Ready by Design neste contexto não é marketing, é pré-condição do primeiro dia operacional. Quem começa em Cracóvia sobrevive ao teste mais duro antes do rollout para o primeiro país ocidental - e quem opera aqui em produção leva o mesmo agent a [Varsóvia](/br/agentes-ia-varsovia/), [Wrocław](/br/agentes-ia-wroclaw/) ou [Gdańsk](/br/agentes-ia-gdansk/) em semanas, mudando apenas configuração regulatória. Mais em [Polônia em visão geral](/br/agentes-ia-polonia/) ou [EU AI Act](/br/governance/eu-ai-act/).

--- Agentes IA para Empresas em Curitiba | Gosign ---
> Enterprise AI Agents para Curitiba e Paraná. LGPD-compliant, CLT-compatível. Tech-hub do sul do Brasil. Gestão a partir de São Paulo.

## Curitiba é o único hub de tecnologia do Brasil onde grupos automotivos europeus se concentram em densidade comparável a uma região industrial DACH

Olhando para os corredores industriais de Curitiba e região, desenha-se quase um mapa de Wolfsburg-Stuttgart-München em versão tropical. A Volvo do Brasil monta caminhões e ônibus. A Renault Brasil opera no Complexo Ayrton Senna em São José dos Pinhais. A Volkswagen Curitiba (em São José dos Pinhais) e a Audi ficam ao lado. A Klabin (maior fabricante de papel do Brasil) mantém matriz e clusters industriais em Telêmaco Borba. O Grupo Boticário (segunda maior rede de cosméticos do país) fica em São José dos Pinhais. A Positivo Tecnologia e a Bematech formam o núcleo tech. Curitiba é a cidade mais "europeia" do Brasil em planejamento urbano - o ponto natural de acoplamento para padrões industriais alemães e europeus, o que a torna mercado-alvo especialmente relevante para grupos brasileiros que atendem clientes na UE.

## As três barreiras regulatórias para IA no mercado de Curitiba

A primeira é a **ANTT (Agência Nacional de Transportes Terrestres) para logística e caminhões**. Volvo, Renault, VW e a cadeia logística paranaense operam sob supervisão da ANTT para transportes pesados, sistemas de pedágio e documentação de motorista. Componentes de IA em otimização de rota, conferência de pedágio ou compliance de motorista precisam alimentar reportes ANTT - com Audit Trail que vai do sensor ao relatório CONTRAN de infração. Em operações de carga pesada com trechos Mercosul transfronteiriços (Argentina, Uruguai, Paraguai) somam-se obrigações aduaneiras e documentais adicionais que colocam qualquer agent logístico em arquitetura multi-jurisdicional.

A segunda é a **LGPD na escala Boticário**. O Grupo Boticário opera um dos maiores CRMs e programas de fidelidade do país. Qualquer componente de IA em segmentação de cliente, engines de personalização ou roteamento de influenciadores precisa atender os Art. 7 (base legal) e Art. 11 (dados sensíveis) da LGPD, além da resolução da ANPD (PT: CNPD) sobre DPIAs - com versionamento de modelo rastreável por decisão. Em modelo de venda direta com mais de um milhão de consultoras/revendedoras, a gestão de consentimento por contato é dos temas mais críticos da LGPD - Audit Trail que chega até o opt-in individual.

A terceira é o **IBAMA e o reporting ESG da Klabin**. A Klabin é referência ESG no Brasil e, por isso mesmo, tem altíssima exigência em reporting automatizado (FSC, GRI, SASB). IA que agregue origem de madeira, consumo de água ou balanço de CO2 precisa ser explicável e resistir a auditorias do IBAMA, a auditores externos e a investidores ESG. Cert-Ready by Design aqui não é marketing, é pré-condição de Investor Relations. Importante: o EU AI Act não se aplica diretamente no Brasil; o quadro brasileiro é LGPD mais o futuro PL 2338/2023.

## Cenários típicos de implementação em Curitiba

**Supply Chain em Volvo Brasil e Renault Brasil**: Document Agents lêem documentação de fornecedor, declarações aduaneiras, comprovação de origem Mercosul e certificados de qualidade. O Decision Layer escala conflitos de cota Mercosul ou lacunas de compliance para compras e logística. Workflow Agents alertam proativamente para ruptura de abastecimento, com Audit Trail até o cadastro de fornecedor. Em plantas cujos sub-fornecedores ficam na Argentina, Uruguai e Paraguai, a documentação de origem Mercosul é dos temas mais sensíveis para a aduana.

**CRM e personalização no Boticário**: Document e Workflow Agents processam contatos vindos de loja física, app e venda direta (via revendedoras), cruzam LGPD-compliant com status de consentimento, e o Decision Layer roteia recomendações de campanha com Human-in-the-Loop aos responsáveis de marketing. Audit Trail preserva a rastreabilidade por contato.

**Reporting de sustentabilidade na Klabin**: Document Agents agregam inventário florestal, protocolos de serraria e dados energéticos em relatórios ESG auditáveis por FSC, GRI e SASB. O Decision Layer sinaliza lacunas de dado ou conflitos de plausibilidade para validação humana - cada agregação com origem de dado rastreável e versionamento de modelo. Para companhias abertas com investidores ESG europeus essa profundidade de Audit é pré-condição de CSRD.

**Supplier compliance na Positivo Tecnologia**: Document Agents verificam origem de semicondutores, conformidade RoHS e comprovação de origem Mercosul para a maior fabricante local de hardware do Brasil. Workflow Agents alertam em situações de ruptura e documentam cada recomendação com Audit Trail até o certificado original do fornecedor.

Em todos os cenários o [Decision Layer](/br/decision-layer/) entrega a camada de Governance by Design.

## Como a Gosign atende Curitiba a partir de São Paulo

O escritório de [São Paulo](/br/agentes-ia-sao-paulo/) está a 1 hora de voo de Curitiba. Discovery Workshops com Volvo, Renault, Klabin ou Boticário rodam presencialmente em Curitiba, São José dos Pinhais ou nas próprias plantas. Revisões de compliance com foco em LGPD, ANTT ou IBAMA passam pelo seu jurídico e pelo escritório local. Consultas sindicais para HR Agents alinham-se com as representações em Paraná - os sindicatos na indústria automotiva paranaense são menos conflitivos que em SP, mas tecnicamente mais detalhistas na discussão de decisões algorítmicas. É importante lembrar que, no Brasil, sindicato/CRE tem direito de consulta, não de veto direto sobre IA.

Fases de build rodam distribuídas entre Hamburgo e São Paulo - 4 horas de fuso, stand-ups pela manhã no horário SP. Presença em Curitiba se organiza em 24 horas. Para matrizes alemãs e europeias (Volkswagen, Renault, Volvo, Stellantis) reporting paralelo em alemão, inglês e português.

## Por que Curitiba funciona como ponto de partida para Enterprise AI

Curitiba é o único mercado brasileiro onde grupos industriais alemães e europeus se concentram em densidade operacional comparável a regiões industriais DACH. Quem constrói aqui um agent produtivo de supply chain, controle de qualidade ou reporting ESG, constrói num ambiente em que os contratantes já internalizaram os padrões europeus - o que encurta radicalmente a transição de um PoC em Paraná para rollout produtivo em Wolfsburg, Stuttgart ou Gotemburgo. Os clusters - Tecpar, Curitiba Smart City, o corredor de inovação em torno da UFPR - entregam talento e parceiros de pesquisa. A tradição de Curitiba como a cidade mais "europeia" do Brasil (planejamento urbano dos anos 1970 espelhado em modelos europeus, alta concentração de populações alemã e italiana, câmara de comércio alemã estabelecida no Paraná) se traduz no dia a dia: menos perdas de tradução em Discovery, menos atrito cultural em Sprint Planning, e mais acoplamento com a Governance corporativa europeia. A arquitetura Governance by Design da Gosign é Cert-Ready para GDPR e EU AI Act desde o dia 1 - em Curitiba isso não é só vantagem regulatória, é também vantagem operacional. Mais no [panorama Brasil](/br/agentes-ia-brasil/) ou no perfil das [operações São Paulo](/br/agentes-ia-sao-paulo/).

--- Agentes IA para Empresas em Dublin | Gosign ---
> Enterprise AI Agents para Dublin. Sedes europeias de tech, supervisão DPC, EU AI Act diretamente aplicável. IA auditável para o hub empresarial da Irlanda.

## Em Dublin, uma única autoridade europeia decide o que vale como compliance de dados para 450 milhões de europeus

Dublin não é mais uma capital europeia: é a capital regulatória do tech dos EUA na Europa. Google EU, Meta EU, LinkedIn EU, Microsoft EU, Stripe EU e Apple mantêm aqui suas sedes europeias pela combinação de regime tributário, língua inglesa e estabilidade política. Acrescentam-se os pesos-pesados irlandeses: AIB (Allied Irish Banks), Bank of Ireland, Accenture com HQ global em Dublin, Ryanair, Kerry Group e CRH (uma das maiores fabricantes globais de materiais de construção). Os "Silicon Docks" no Grand Canal concentram em poucos quilômetros quadrados mais talento em Trust & Safety, Compliance Engineering e AI Governance do que qualquer outra cidade europeia - porque é aqui que fica a autoridade que fiscaliza exatamente esses temas. Contexto relevante também para empresas brasileiras com operações na UE ou que rodam serviços em cadeias tech globais.

## As três barreiras regulatórias para IA no mercado de Dublin

A primeira é a **DPC (Data Protection Commission)**. Por conta do princípio One-Stop-Shop do GDPR, a DPC é autoridade líder para praticamente todas as big techs dos EUA com sede europeia na Irlanda - e assim, na prática, a autoridade de GDPR mais influente da União. Nos últimos anos a DPC aplicou multas de bilhões contra Meta, Google e WhatsApp e hoje também audita modelagem de IA e dados de treinamento sob o regime do GDPR. Quem constrói IA em Dublin constrói para uma autoridade que examina origem de dado de treino, decisão automatizada e transferência transfronteiriça no detalhe.

A segunda é o **EU AI Act, diretamente aplicável na Irlanda**. O governo irlandês nomeou o Department of Enterprise, Trade and Employment como ponto focal da transposição nacional e trabalha em estreita articulação com a DPC. Sistemas de IA de alto risco de empresas com sede europeia em Dublin serão certificados aqui - e a expectativa é de interpretação acima da média, porque Dublin precisa politicamente provar que não é brecha de supervisão.

A terceira é a **Central Bank of Ireland (CBI)** para todos os serviços financeiros. Stripe, Mastercard EU, Citi EU, Goldman Sachs EU - todos sob supervisão da CBI e obrigados a documentar modelos de compliance e risco apoiados em IA nos padrões do CBI Innovation Hub. A CBI exige explicabilidade completa, Audit Trail e monitoramento contínuo de modelo. [EU AI Act Governance](/br/governance/eu-ai-act/) e supervisão financeira precisam engrenar juntos. Para grupos brasileiros o comparativo é relevante, mas atenção: o EU AI Act não se aplica diretamente ao Brasil - aqui o equivalente em formação é o PL 2338/2023.

## Cenários típicos de implementação em Dublin

**Governance de modelos no Google**: o Google usa Dublin como hub global para governance de modelos de IA, desenvolvendo ferramentas de compliance que tornam cada decisão de modelo explicável à DPC. Document Agents trackeiam lineage de modelo e decisões regulatórias.

**DSA e moderação de conteúdo na Meta**: documentação do Digital Services Act e avaliação de risco sistêmico em modelos de moderação - cada decisão algorítmica precisa ter Audit Trail. Workflow Agents preparam os dossiês regulatórios exigidos.

**Risco de pagamento na Stripe**: a Stripe constrói modelos globais de risco que bloqueiam ou liberam transação em segundos - os modelos precisam permanecer rastreáveis para a CBI. Document e Workflow Agents preservam a lógica de decisão com Audit Trail completo.

**Modernização de crédito no AIB**: o AIB moderniza decisões de crédito e precisa de modelos defensáveis simultaneamente sob o Art. 22 do GDPR e o Central Bank Code of Conduct. Document Agents preparam justificativas acessíveis ao cliente; o Decision Layer escala casos limítrofes ao analista humano.

Em todos esses casos a decisão tem alcance global, mas a supervisão ocorre em Dublin - com tempos curtos de resposta e perguntas duras sobre comportamento de modelo, dados de treino e mitigação de viés. O [Decision Layer](/br/decision-layer/) responde exatamente isso: persiste cada decisão como trace, impõe Human-in-the-Loop em caminhos críticos e entrega Audit Trail que resiste a exame da DPC e da CBI. A peculiaridade irlandesa é a postura proativa da DPC: diferente de outras autoridades da UE, a DPC conduz inquirições de ofício em intervalos regulares. Quem roda IA em produção em Dublin tem que contar com inspeção não anunciada de documentação, proveniência de dado e histórico de decisão de modelo. Cert-Ready by Design aqui não é "quando vier a auditoria" - é prontidão permanente.

## Como a Gosign atende Dublin a partir de Hamburgo

Hamburgo-Dublin é voo direto de cerca de duas horas, com várias conexões diárias. Trabalhamos remote-first com clientes em Dublin e Cork, com workshops presenciais para Discovery e decisões arquiteturais. Língua de trabalho em inglês; steering interno em alemão com nossos arquitetos de Hamburgo. O fuso (WET, uma hora atrás do CET) é confortável, e a cultura de negócios irlandesa é pragmática e rápida na decisão.

O que trazemos do mercado alemão é a disciplina de engenharia sob supervisão rigorosa. Os bancos alemães que atendemos carregam com BaFin e MaRisk exigências de compliance comparáveis às das big techs irlandesas com DPC e CBI - a tonalidade regulatória é familiar, as respostas técnicas se transferem diretamente. Conhecemos os regimes irlandeses de supervisão tech o bastante para não ter que traduzir cada termo, e podemos oferecer decisões arquiteturais concretas já no Discovery. Para clientes brasileiros com operações na UE a articulação São Paulo - Hamburgo - Dublin entrega a mesma arquitetura com LGPD cobrindo o Brasil e GDPR cobrindo a UE.

## Por que Dublin funciona como ponto de partida para Enterprise AI

Dublin tem a barra regulatória mais alta para IA na Europa - e, ao mesmo tempo, a maior concentração de engenharia em AI Governance. Quem entrega aqui um piloto Cert-Ready by Design tem um caso de referência defensável em qualquer outro mercado da UE e resistente à DPC. O cluster Silicon Docks, o Dublin Tech Cluster e o programa AI da Enterprise Ireland entregam talento, ecossistema e parceiros piloto. Segunda vantagem: quem constrói IA em Dublin aprende como funciona compliance pan-europeia. A maioria das techs irlandesas atua nos 27 estados simultaneamente - cada arquitetura precisa dar conta de regras específicas por jurisdição sem fragmentar o Audit Trail. Governance by Design entrega exatamente isso. Hamburgo aporta a disciplina alemã de engenharia; Dublin aporta o rollout pan-europeu. Mais em [serviços AI Agents](/br/servicos/ai-agents/).

--- Agentes IA para Empresas em Düsseldorf | Gosign ---
> Enterprise AI Agents para Düsseldorf e região Reno-Ruhr. Estruturas de Shared Services, LGPD-compliant, auditável. Gestão presencial.

## Düsseldorf é o local alemão em que bens de consumo, energia, telecomunicações e médias empresas industriais fazem, em espaço apertado, a mesma pergunta sobre Shared Services

No corredor entre Königsallee, Oberkassel e a Feira de Düsseldorf concentram-se Henkel, Vodafone Deutschland com sede corporativa, E.ON, Metro AG e Uniper - somam-se Ergo Versicherung como parte do grupo Munich Re, Rheinmetall como conglomerado de defesa, L'Oréal Deutschland e a Trivago como maior empresa de tecnologia de Düsseldorf. Acrescente-se toda a Renânia, com Bayer e LANXESS em Leverkusen, subsidiárias da Henkel em Düsseldorf-Holthausen e uma densa rede de médias empresas entre Krefeld, Wuppertal e Duisburg. Essa concentração gera uma necessidade específica de arquitetura: a maioria desses grupos opera Shared Service Centers para Finance, RH e TI que orquestram processos entre dez e cem entidades simultaneamente - cada uma com jurisdições, acordos coletivos e regimes fiscais próprios. Uma arquitetura de IA que aqui funciona precisa ser multi-tenant e carregar regras de governance por entidade.

## As três barreiras regulatórias que moldam toda iniciativa de IA no mercado de Düsseldorf

A primeira é a regulação energética específica da NRW - a BNetzA com sede em Bonn é a autoridade central para redes de eletricidade e gás, e a maioria dos grandes fornecedores de energia da Alemanha tem operações de mercado em Düsseldorf ou Essen. E.ON, Uniper e suas distribuidoras trabalham no dia a dia com os formatos de dados da BNetzA e as especificações da BDEW. Um componente de IA em previsão de carga, gestão de balance group ou aquisição de clientes precisa conhecer e usar esses formatos de forma rastreável. (Para o leitor brasileiro: papel comparável ao da ANEEL no Brasil, mas com integração europeia.)

A segunda barreira é a forte cogestão nos grupos da NRW com conselhos de empresa experientes em IG Metall, IGBCE ou ver.di - uma IA de Shared Services precisa construir o Decision Layer arquitetonicamente de forma que decisões sob cogestão sejam obrigatoriamente apresentadas a um colaborador qualificado, e os acordos de empresa precisam ser pensados desde o início. A terceira barreira é a Lei Alemã de Cadeia de Suprimentos e a diretiva europeia CSDDD - Henkel, L'Oréal, Metro e Rheinmetall precisam documentar riscos para suas cadeias globais e preparar o reporting BAFA. Mais contexto em [Governance EU AI Act](/br/governance/eu-ai-act/).

## Cenários típicos de implementação em Düsseldorf

Em Henkel e grupos de bens de consumo comparáveis vemos Compliance Agents de cadeia de suprimentos que processam documentos de fornecedores estruturadamente e escalam alertas de risco a um Sustainability Manager - com Audit Trail completo para o reporting BAFA conforme a Lei de Cadeia de Suprimentos. Em E.ON e no entorno energético mais amplo trata-se de acompanhamento do rollout de Smart Meter e do processamento estruturado de pedidos de conexão à rede, em que despachantes tomam a decisão final.

A Metro AG trabalha em Use Cases de gestão de sortimento e distribuição de mercadorias, em que um agente avalia dados regionais de cliente e sazonalidade e dá uma proposta ao Category Manager. Em Ergo e seguradoras comparáveis, agentes apoiam a verificação de contratos em seguro de vida e a verificação de acumulação de sinistros. Na Vodafone Deutschland vemos Customer Service Agents que estruturam demandas de clientes, priorizam retornos e, para casos regulados sob a BNetzA, transferem o processo completo a um despachante com responsabilidade de gestão de reclamações. Em L'Oréal Deutschland e em fabricantes similares de bens de consumo, Document Agents apoiam o compliance de ingredientes e o Regulamento de Cosméticos da UE. Na Trivago e no entorno tech de Düsseldorf vemos suporte agêntico em customer service e moderação de conteúdo sob o Digital Services Act - com escalada clara a moderadores humanos em casos sensíveis. Na Rheinmetall, em ambiente de defesa, vemos Document Agents na análise de contratos e screening de fornecedores com requisitos especiais de auditoria por causa do controle de exportação. Em todos os casos, decide a pessoa qualificada, o agente documenta, e o [Decision Layer](/br/decision-layer/) mantém a justificativa como Audit Trail.

## Como a Gosign atende Düsseldorf a partir de Hamburgo

A Gosign não tem escritório em Düsseldorf - o acompanhamento presencial vem de Hamburgo e do escritório de Berlim. O ICE direto Hamburgo-Düsseldorf leva pouco menos de quatro horas, um voo direto é claramente mais rápido. Concretamente organizamos a colaboração assim: kick-off e Discovery Workshops acontecem presencialmente em Düsseldorf, geralmente como bloco de dois dias com partes de Engineering, Compliance e conselho de empresa. Na fase de Build combinamos Engineering remoto com dias presenciais quinzenais para revisões de arquitetura, validação de modelo e atualizações de stakeholders.

Quando um grupo opera Shared Services em vários locais da NRW, fazemos as workshops importantes presencialmente nas respectivas filiais - Düsseldorf-Holthausen para Henkel, Essen para E.ON, Leverkusen para LANXESS ou Bayer. Essa lógica de presença distribuída é uma peculiaridade do mercado renano, porque sedes corporativas na NRW estão frequentemente espalhadas fisicamente e os encontros com stakeholders precisam ser organizados de acordo. A experiência do mercado renano mostra: pragmatismo conta mais que presença, desde que a frequência presencial nos encontros decisivos com stakeholders seja adequada. Clusters como NRW.Energy4Climate em Düsseldorf usamos para networking e discussões técnicas. Para grupos brasileiros com Shared Services europeus (vários grupos brasileiros de bens de consumo e químicos têm centros de serviços compartilhados na Alemanha), coordenamos a partir do [escritório em São Paulo](/br/agentes-ia-sao-paulo/).

## Por que Düsseldorf funciona como ponto de partida para Enterprise AI

Quem coloca um AI Agent em produção em um Shared Service Center de Düsseldorf, defendeu-o contra pelo menos três jurisdições, vários acordos coletivos e um conselho de empresa experiente - uma arquitetura que faz isso é depois escalável em qualquer outra constelação multi-entity na Europa. Soma-se o panorama de fomento específico da NRW: o estado da NRW apoia projetos de IA por vários programas de inovação, e a fase de Discovery identifica em regra pelo menos uma linha de fomento adequada. Clusters como o Digital Hub Düsseldorf-Rheinland e a rede Life Science da Renânia oferecem intercâmbio técnico e parceiros de co-inovação. Soma-se ainda a Hochschule Düsseldorf e as universidades próximas em Colônia, Bonn, Aachen com seus programas de ML Engineering, e o Forschungszentrum Jülich como âncora para High Performance Computing. Quem em 4-6 semanas tem um primeiro Workflow Agent em produção em um Shared Service da NRW, constrói sobre uma arquitetura multi-tenant e [Governance by Design](/br/governance/eu-ai-act/). Mais sobre o procedimento em [serviços AI Agents](/br/servicos/ai-agents/).

--- Agentes IA para Empresas na Espanha | Gosign ---
> Enterprise AI Agents para a Espanha. AESIA-ready, LGPD-compliant, EU AI Act compliant. Escritório em Barcelona, projetos em toda a Espanha.

## A Espanha é o primeiro país da UE com autoridade nacional de IA em plena operação - e isso muda o planejamento de implementação

A Espanha é o único Estado-membro da UE que já opera uma autoridade nacional de IA plenamente funcional: a AESIA (Agencia Española de Supervisión de la Inteligencia Artificial). A AESIA, com sede em La Coruña, é a resposta espanhola ao EU AI Act e assume um papel que na maioria dos países da UE ainda está distribuído ou vago. Para grupos como Santander, BBVA, CaixaBank, Sabadell, Telefónica, Iberdrola, Repsol, Inditex, Mercadona, Ferrovial, ACS, Mapfre, Amadeus IT Group, Grifols e Naturgy, isso significa clareza regulatória antes do resto. Os polos Madrid, Barcelona, Valência, Bilbao, Sevilha e Málaga formam os hubs tech do país - todos sob a mesma supervisão unificada de IA. Quem constrói Enterprise AI na Espanha tem um regulador que sabe o que espera e comunica com clareza. Contexto relevante para grupos brasileiros com operação ibérica e para o eixo lusófono Brasil-Portugal que passa por Espanha em supply chain e mercado consumidor.

## As três barreiras regulatórias para IA no mercado espanhol

A primeira é a **AESIA em conjunto com o EU AI Act**. A AESIA está operacional desde 2024 e desenvolve ativamente diretrizes para sistemas de alto risco nos termos do Annex III do EU AI Act. Em decisões de RH, credit scoring, identificação biométrica e infraestrutura crítica, a AESIA exige Conformity Assessment documentado, risk management, post-market monitoring e Audit Trail completo. Vantagem sobre outros países da UE: grupos espanhóis já sabem hoje o que será esperado em 2026 e 2027 - enquanto grupos na Alemanha ou França ainda aguardam a lei nacional de transposição. Para brasileiros a analogia importante é o PL 2338/2023, em tramitação no Congresso brasileiro.

A segunda é a dupla **AEPD e LOPDGDD**. A Agencia Española de Protección de Datos supervisiona o GDPR na Espanha, complementada pela Ley Orgánica de Protección de Datos y Garantía de los Derechos Digitales (LOPDGDD) e pela LGICTE sobre transparência de IA em relação ao consumidor. No credit scoring do Santander, no AML do BBVA ou nos sistemas de recomendação da Telefónica, a AEPD exige bases legais documentadas, explicações acessíveis e última decisão humana rastreável. Especificidade espanhola: em decisões algorítmicas no contato com consumidor a LGICTE exige explicitamente obrigação de transparência que não existe nessa forma em nenhuma outra jurisdição da UE.

A terceira é o conjunto **CNMV, Banco de España e CNMC** para supervisão setorial. Santander, BBVA, CaixaBank e Sabadell estão sob supervisão da CNMV (valores) e Banco de España (bancária). Em recomendações relevantes ao MiFID, AML screening e underwriting, ambos esperam padrões de explicabilidade e auditoria comparáveis aos da BaFin ou FCA. A CNMC supervisiona adicionalmente decisões algorítmicas relevantes à concorrência - aspecto que vem ganhando foco em Mercadona, Inditex e no e-commerce espanhol. Grupos espanhóis com negócio LATAM precisam também observar a LGPD no Brasil e a Lei 25.326 argentina.

## Cenários típicos de implementação na Espanha

**Credit scoring em Santander e BBVA**: os grandes bancos espanhóis processam milhões de pedidos de crédito por ano na Espanha e na América Latina. Document Agents extraem dados estruturados dos formulários; o Decision Layer roteia casos de risco pelas faixas do Banco de España, com Human-in-the-Loop em cada decisão final e Audit Trail que resiste a CNMV, AEPD e AESIA ao mesmo tempo.

**Recomendação ao consumidor na Telefónica**: a Telefónica opera sistemas de recomendação para tarifa, conteúdo e serviços de valor agregado em vários mercados de língua espanhola e portuguesa. Decision Agents checam cada recomendação contra LOPDGDD, exigências de transparência da LGICTE e LGPD no Brasil - cada decisão exibida com justificativa rastreável.

**Supply chain em Inditex e Mercadona**: líderes espanhóis de moda e alimentos operam cadeias altamente complexas. Workflow Agents classificam pedido, devolução e ocorrência de fornecedor; o Decision Layer escala ao responsável humano e registra cada decisão para auditoria interna e auditorias de concorrência da CNMC.

**Grid operations em Iberdrola e Naturgy**: os grupos de energia usam IA para otimização de rede, predictive maintenance e previsão de consumo. Document Agents extraem comunicações de segurança e manutenção; Workflow Agents classificam anomalias por gravidade, com última decisão humana obrigatória em achados críticos - exigência explícita da AESIA para IA KRITIS-relevante.

Em todos os cenários o [Decision Layer](/br/decision-layer/) entrega Governance by Design.

## Como a Gosign atende toda a Espanha a partir de Barcelona

A Gosign mantém escritório próprio em Barcelona (gosign.es) como hub regional para a península ibérica. O time espanhol-catalão com gerentes de projeto e engenheiros - falantes nativos, à vontade em todas as línguas dos stakeholders - atende as quatro principais regiões de mercado: [Madrid](/br/agentes-ia-madrid/) como capital corporativa e regulatória, [Barcelona](/br/agentes-ia-barcelona/) como hub tech, [Valência](/br/agentes-ia-valencia/) como ponto industrial e logístico e [Bilbao](/br/agentes-ia-bilbao/) como coração industrial basco. Presenças, Sprint Reviews e steering rodam em espanhol; na Catalunha também em catalão; no País Basco, se necessário, com stakeholders em euskara.

Os contatos diretos com AESIA (La Coruña), AEPD e CNMV (Madrid) passam pelo time de Barcelona; documentação de compliance é entregue bilíngue. A sede em Hamburgo aporta padrões arquiteturais técnicos e a coordenação internacional com matrizes alemãs, suíças e holandesas. Para grupos espanhóis com negócio LATAM - Santander, Telefónica, BBVA, Mapfre - o time de Barcelona acopla com o escritório de São Paulo (gosign.com.br), de modo que GDPR, LGPD e LFPDPPP mexicana ficam cobertos na mesma arquitetura. Para clientes brasileiros com operação espanhola o eixo São Paulo - Barcelona - Hamburgo entrega mesma equipe, mesma arquitetura.

## Por que a Espanha funciona como ponto de partida para Enterprise AI

A Espanha tem uma vantagem estrutural que nenhum outro grande mercado da UE oferece hoje: clareza regulatória a partir de fonte central. Quem constrói um agent para uma empresa espanhola que atende às expectativas AESIA hoje, desenhou arquitetura EU AI Act compliant - antes mesmo que outros países tenham suas autoridades operacionais. Para grupos alemães, suíços e nórdicos com subsidiárias espanholas ou latino-americanas, a Espanha costuma ser o primeiro mercado AI produtivo - a conformidade AESIA vira blueprint para a onda seguinte de rollout em outros países da UE. Cert-Ready by Design aqui significa arquitetura que atende hoje o que só será mandatório em 2027 no resto da UE. O pioneirismo espanhol não é acidente, é programa - e vantagem de localização relevante para quem começa agora. Mais em [EU AI Act](/br/governance/eu-ai-act/) no Governance.

--- Agentes IA para Empresas em Estocolmo | Gosign ---
> Enterprise AI Agents para Estocolmo. EU AI Act diretamente aplicável, supervisão IMY. IA auditável para o hub tech dos Nórdicos.

## Estocolmo é a capital tech da Escandinávia - com a autoridade de proteção de dados mais consistente da UE ao fundo

Quem constrói Enterprise AI em Estocolmo constrói para uma mistura incomum: pesos industriais como Ericsson, ABB, Atlas Copco, Volvo Cars (operação em Gotemburgo, funções corporativas em Estocolmo) e Electrolux convivem com uma das concentrações mais densas de unicórnios da Europa - Spotify, Klarna, King Digital, iZettle, Truecaller, Northvolt. H&M e IKEA (via Ikano) formam o núcleo varejista. A espinha bancária é feita por Skandinaviska Enskilda Banken (SEB), Handelsbanken e Swedbank; o setor segurador por Skandia e Folksam. No bairro Kista Science City estão mais de 1000 empresas tech, no programa Stockholm Unicorn Factory amadurece a próxima geração. O que torna Estocolmo único: a cultura de negócios sueca combina eficiência nórdica com pensamento de engenharia de longo prazo - e aceita investimentos de compliance que outros mercados veriam como freio. Contexto relevante para grupos brasileiros que cruzam cadeias tech nórdicas ou atuam em fintech.

## As três barreiras regulatórias para IA no mercado de Estocolmo

A primeira é a **IMY (Integritetsskyddsmyndigheten)**, a autoridade sueca de proteção de dados. A IMY é conhecida em toda a UE pela interpretação consistente do GDPR e aplicou nos últimos anos várias multas relevantes contra empresas de tecnologia, bancos e entes públicos - frequentemente fundamentadas em explicabilidade insuficiente de decisão automatizada. Para sistemas de IA isso significa: o Art. 22 do GDPR é aplicado na Suécia com rigor comparável a Países Baixos e Espanha. Decision Layer com Human-in-the-Loop não é opcional, é pré-requisito de compliance.

A segunda é o **EU AI Act, diretamente aplicável na Suécia**. O governo sueco anunciou uma autoridade própria de market surveillance que coordenará com IMY e Finansinspektionen. Sistemas de alto risco em banking, infraestrutura de energia e gestão de pessoal serão auditados sistematicamente a partir de 2026. [EU AI Act Governance](/br/governance/eu-ai-act/) aqui não é abstrato, é operacional. Para brasileiros a observação importante: o EU AI Act não vale diretamente no Brasil - lá, o equivalente em formação é o PL 2338/2023.

A terceira é a dupla **Finansinspektionen** (serviços financeiros) e **PTS (Post- och telestyrelsen)** (telecomunicações). Desde 2023 a Finansinspektionen exige de bancos e processadores de pagamento governance documentada de modelo de IA, explicabilidade e monitoramento contínuo. Klarna, SEB e Handelsbanken já trabalham com frameworks específicos. A PTS supervisiona aplicações de IA em redes de telecom e examina modelos de network slicing da Ericsson em viés e fairness.

## Cenários típicos de implementação em Estocolmo

**Recomendação no Spotify**: algoritmos em produção simultânea em mais de 180 mercados que precisam permanecer defensáveis sob EU AI Act, IMY e vários regimes nacionais - cada push algorítmico por um álbum tem implicação regulatória. Document Agents preservam lineage, Decision Layer impõe rule sets por jurisdição.

**Buy-Now-Pay-Later na Klarna**: modelos de risco BNPL em mais de 17 mercados - decidem se o consumidor recebe microcrédito e têm que ser explicáveis simultaneamente à Finansinspektionen, BaFin, FCA e outras autoridades. Document Agents preparam justificativas; Audit Trail cobre todas as jurisdições.

**Transaction Monitoring no SEB**: AML com modelos que precisam permanecer reproduzíveis para a Finansinspektionen - cada alerta individual entra em auditoria. Workflow Agents classificam padrões, Decision Layer escala com Human-in-the-Loop.

**Configuração 5G na Ericsson**: a Ericsson configura redes 5G para operadoras no mundo inteiro com ferramentas de IA cujas decisões precisam ser documentáveis para as supervisões nacionais de telecom de cada país. Document Agents preservam lineage de configuração.

Em todos os cenários a questão não é só o modelo, é que cada decisão permaneça rastreável, possa ser roteada por rule sets específicos de jurisdição e imponha Human-in-the-Loop em caminhos de escalação. Isso é o [Decision Layer](/br/decision-layer/) em estado puro. Uma particularidade sueca é o tratamento de dados governamentais: a Offentlighetsprincipen (lei de transparência) exige que documentos públicos sejam, em regra, abertos - o que, para aplicações de IA no setor público e para fornecedores da administração, pode significar publicação de dados de treino e decisões de modelo. Quem constrói IA em Estocolmo para Public Sector precisa desenhar arquitetura que atenda esse padrão desde o primeiro dia.

## Como a Gosign atende Estocolmo a partir de Hamburgo

Hamburgo-Estocolmo é voo direto de pouco menos de duas horas, com conexões diárias via LH e SAS. Trabalhamos remote-first com nossos clientes suecos, com workshops presenciais nos primeiros meses do projeto e visitas trimestrais em fase de operação. Língua de trabalho em inglês; steering interno em alemão com nossos arquitetos de Hamburgo. Fuso idêntico ao da Europa Central.

O que facilita a colaboração: a cultura sueca de negócio é consensual mas tecnicamente muito competente - participantes de workshop são, em regra, Engineering Leads ou Product Owners que entendem decisões arquiteturais diretamente. Conhecemos a lógica sueca de co-determinação (MBL, Medbestämmande), que obriga o empregador a consultar sindicatos antes da introdução de novos sistemas, e planejamos o Decision Layer de modo que as obrigações de consulta sejam cumpridas arquitetonicamente - workflow integrado, não camada posterior de compliance. Para clientes brasileiros com operações nórdicas o eixo São Paulo - Hamburgo - Estocolmo entrega a mesma arquitetura cobrindo LGPD e GDPR.

## Por que Estocolmo funciona como ponto de partida para Enterprise AI

Estocolmo é o único mercado da Europa onde uma arquitetura de IA pode ser testada simultaneamente contra proteção de dados IMY, supervisão financeira Finansinspektionen e lógica nórdica de co-determinação - e onde os stakeholders aceitam investir tempo e recursos de engenharia para isso. Quem aqui entrega um piloto Cert-Ready by Design tem um caso de referência que passou nas condições mais estritas de proteção de dados da UE - depois defensável em Helsinque, Copenhague, Oslo e no resto da Europa. O cluster Kista Science City, a Stockholm Unicorn Factory e a rede Stockholm School of Economics entregam talento, parceiros piloto e acesso a investidor. Trazemos do contexto de engenharia norte-alemã uma disciplina que combina com a cultura tech sueca - com Governance by Design, Audit Trail e a capacidade de atender compliance de múltiplas jurisdições sobre o mesmo sistema. Estocolmo é o mercado certo para escalar essa disciplina nos Nórdicos. Para grupos alemães com subsidiárias nórdicas, Estocolmo costuma ser o primeiro mercado onde novas arquiteturas de IA precisam provar valor - antes do rollout em Munique, Frankfurt ou Hamburgo. Mais em [serviços AI Agents](/br/servicos/ai-agents/).

--- Agentes IA Frankfurt - Porta de Entrada Europeia para Multilatinas | Gosign ---
> Agentes IA para multilatinas brasileiras com operações em Frankfurt: Itaú Europa, Bradesco DTVM, BTG Pactual. EU-Mercosul 2026, BACEN 4893 + BaFin MaRisk em um Audit Trail.

## Frankfurt como porta de entrada europeia para multilatinas pós-Mercosul-EU

Para uma multilatina brasileira que opera em 7+ países (a média do estudo IDB sobre internacionalização de multilatinas) e quer entrar na União Europeia, Frankfurt é a porta mais curta. Itaú Unibanco licenciou Itaú Europa em Lisboa com filial em Frankfurt para corporate banking. **Bradesco DTVM Frankfurt** atende family offices europeus de famílias brasileiras. **BTG Pactual** abriu uma filial em Frankfurt em 2024 após adquirir parte do UBS Wealth Management LATAM. Banco do Brasil mantém presença para trade finance dos exportadores. Pós-acordo **EU-Mercosul (assinado em janeiro de 2026)** o fluxo de holdings industriais brasileiras (Embraer, Marfrig, JBS Europa) também converge para Frankfurt - o eixo Rhein-Main concentra ECB, BaFin, e os grandes bancos europeus em poucos quilômetros.

## BACEN 4893 + BaFin MaRisk: 70% de sobreposição, 30% que define o Decision Layer

A boa notícia para multilatinas: a [Resolução BACEN 4893/2021](https://www.bcb.gov.br/) sobre governance de modelos e a BaFin MaRisk + BAIT compartilham ~70% da estrutura - ambos exigem validação independente de modelo, backtesting, análise de sensibilidade, Audit Trail e governance documentada. As diferenças críticas: BACEN classifica risco de modelo em três níveis (BCB-3973), MaRisk usa AT 9 (5 níveis); BACEN exige reporte mensal SCR ao Banco Central, BaFin/EBA esperam COREP trimestral; BACEN admite "outsourcing simplificado" para nuvem, BaFin/EBA exigem due diligence DORA completa em 2026. Nosso [Decision Layer](/br/decision-layer/) modela esses 30% como **duas trilhas paralelas que escrevem o mesmo evento** - reporting BACEN gerado a partir do mesmo log que alimenta o reporte para BCE/BaFin. Para o CTO da multilatina isso significa: uma equipe de governance, dois regimes regulatórios atendidos.

## Cenários reais de IA em multilatinas brasileiras com presença em Frankfurt

**Itaú Europa - AML cross-border**: Document Agents triam hits AML que envolvem clientes com presença BR + EU. O agente enriquece com histórico de transações em ambas as jurisdições, dados KYC do CPF + pessoa jurídica europeia, listas COAF + EU-Sanctions Map, avalia plausibilidade. O Compliance Officer decide se vai S-CTR para COAF e/ou STR para FIU alemão. Audit Trail dual-country.

**BTG Pactual Frankfurt - Pre-Settlement Matching pós M&A**: após aquisição da carteira UBS LATAM, conciliação manual entre sistemas legados UBS + sistemas BTG era gargalo. Workflow Agents fazem matching automatizado, Decision Layer escala exceções - audit-ready para BaFin e CVM.

**Embraer Defense Frankfurt - Export Compliance**: triagem automática de pedidos de manutenção de aeronaves militares contra listas EU-Dual-Use, BAFA exports, ITAR equivalentes. Agent verifica destinação final (end-user statement), gera relatório para Anac + BAFA + CMC. Cert-Ready desde o dia 1, porque defesa é zero margem para erro.

## Como atendemos multilatinas brasileiras em Frankfurt: São Paulo - Hamburgo - Frankfurt

Nosso [escritório em São Paulo](/br/agentes-ia-sao-paulo/) coordena Discovery e Stakeholder Management com a matriz brasileira. Hamburgo desenvolve - Frankfurt é alcançada por ICE em 4h para workshops de validação de modelo presenciais (estadias de 2 dias com Risk + Compliance + auditoria interna). Para acordos de outsourcing DORA com a BaFin, fazemos a documentação técnica em alemão e a versão executiva em português - mesma equipe, mesma arquitetura. Câmara Brasil-Alemanha (AHK Rio) e Câmara de Comércio e Indústria Brasil-Alemanha em São Paulo são parceiros institucionais. Para multilatinas com matriz em São Paulo e operação em Frankfurt, garantimos coordenação sem perda de tradução.

## Por que Frankfurt é o ponto de partida certo para AI Compliance europeu

Quem em Frankfurt aprova um caso de uso de IA, defendeu-o contra os reguladores mais rigorosos da Europa - BCE + BaFin. Essa mesma validação de modelo escala depois para Munique, Madrid, Lisboa, Milão. Para multilatinas brasileiras isso significa: o investimento em governance feito uma vez em Frankfurt economiza 60-80% do esforço regulatório nas próximas expansões dentro da UE. EU-Mercosul abre mercados, mas EU AI Act + DORA + GDPR fecham as portas para quem não tem governance comprovada. [Mais sobre EU AI Act + LGPD em paralelo](/br/governance/eu-ai-act/).

--- Agentes IA para Empresas em Gdańsk | Gosign ---
> Enterprise AI Agents para Gdańsk e Tricity. Logística, energia, TI. EU AI Act compliant, LGPD-compliant.

## Gdańsk conecta o maior porto de contêineres do Báltico a um cluster tech em rápida expansão

Gdańsk e a Tricity (Gdańsk, Gdynia, Sopot) são o único ponto da Polônia onde logística marítima pesada, indústria de refino e outsourcing tech operam em proximidade imediata. O Port of Gdańsk é, de longe, o maior porto de contêineres do Báltico, com rotas para Ásia, Escandinávia e Europa Ocidental. A Lotos (hoje parte do grupo Orlen) opera uma das maiores refinarias da Europa Central. Ao mesmo tempo, Gdańsk é base da Intel Gdańsk, Amazon Development Center Gdańsk, DNV GL, Schibsted Media Group, Kainos e Asseco. O Gdańsk Science & Technology Park e o complexo Alchemia compõem o cluster tech. Essa mistura de indústria pesada, logística portuária e engenharia de software cria exigências regulatórias que não existem juntas em nenhuma outra cidade polonesa - referência relevante também para grupos brasileiros exportadores que dependem de logística Báltico-UE.

## As três barreiras regulatórias para IA no mercado de Gdańsk

A primeira é o **Urząd Morski e a regulação marítima**. O Porto de Gdańsk opera sob supervisão da autoridade marítima polonesa, sob o regulamento portuário da UE e sob uma porção de convenções internacionais (SOLAS, MARPOL, código ISPS). IA que classifica movimentação de contêiner, que verifica documento aduaneiro ou otimiza rota precisa tornar cada decisão rastreável contra esses regulamentos. Uma classificação errada de contêiner de carga perigosa não é só "incidente de compliance", é fato reportável à Comissão Europeia e pode parar a operação portuária.

A segunda é a dupla **UODO + KNF** para operações bancárias e de seguros em Gdańsk: PKO BP, Bank Pekao e várias seguradoras mantêm centros operacionais regionais na Tricity. Para decisão automatizada de proposta ou sinistro, KNF e UODO esperam as mesmas evidências exigidas em Varsóvia - bases de modelo documentadas, Audit Trail completo e última decisão humana comprovável em qualquer caso de risco. Para o Amazon Development Center Gdańsk soma-se o EU AI Act em treinamento de modelo sobre datasets relevantes para consumidor.

A terceira é o **EU AI Act em conjunto com a lei polonesa de proteção de dados e exigências setoriais**. A DNV GL, como agente global de classificação, emite certificados válidos em toda a indústria naval. Verificações de certificado apoiadas em IA entram no regime de Conformity Assessment do EU AI Act - e nas regras específicas da IMO (International Maritime Organization). Quem roda IA produtiva em classificação em Gdańsk precisa de arquitetura que atenda várias supervisões ao mesmo tempo. Importante para o contexto brasileiro: o EU AI Act aplica-se diretamente na Polônia; no Brasil o equivalente em formação é o PL 2338/2023.

## Cenários típicos de implementação em Gdańsk

**Container tracking no Port of Gdańsk**: com milhões de movimentos por ano, cada classificação - conteúdo, origem, destino, status de carga perigosa - tem que sair correta e rastreável. Document Agents extraem dados estruturados de manifesto e declaração aduaneira; o Decision Layer roteia automaticamente casos suspeitos para auditores humanos com última decisão obrigatória em carga perigosa.

**Logs de refinaria na Lotos**: a refinaria Lotos em Gdańsk produz diariamente milhões de pontos de sensor e ocorrências de manutenção. Workflow Agents classificam anomalias por relevância de segurança; o Decision Layer impõe Human-in-the-Loop em achados críticos de segurança e documenta tudo no Audit Trail - exigência explícita da supervisão do Wojewódzki Inspektorat Ochrony Środowiska.

**Compliance de treino no Amazon Development Center**: Document Agents validam datasets de treinamento contra exigências da UODO e do EU AI Act, documentam proveniência de dado e bloqueiam automaticamente o uso de datasets sem base legal suficiente.

**Verificação de certificados na DNV GL**: a função de classificação da DNV em Gdańsk verifica navios, plataformas e componentes contra normas internacionais. Document Agents extraem especificação técnica, cruzam com normas vigentes e roteiam decisão de conformidade a auditores humanos - todo o processo documentado em profundidade de auditoria.

Em todos os cenários o [Decision Layer](/br/decision-layer/) persiste Audit Trail, Governance by Design e escalações Human-in-the-Loop.

## Como a Gosign atende Gdańsk a partir de Cracóvia

A Gosign atende projetos em Gdańsk desde o escritório de Cracóvia (gosign.pl) com engenheiros e gerentes de projeto falantes de polonês. O time de Cracóvia cobre a região Trójmiasto (Gdańsk, Gdynia, Sopot) com presença regular - no Gdańsk Science & Technology Park, no cluster Alchemia e diretamente nos stakeholders de Port of Gdańsk, Lotos, Intel Gdańsk, Amazon Development Center e DNV GL. Discovery roda dois dias presenciais, com responsáveis técnicos, compliance e um representante da Rada Zakładowa à mesa. Importante: na Polônia a Rada Zakładowa tem direitos de consulta, não de veto sobre IA.

Build e Sprint Reviews seguem com o time de Cracóvia, em polonês e inglês, com steerings mensais presenciais na Tricity e viagem curta em caso de escalação com Urząd Morski ou aduana. A experiência em logística marítima do time de Cracóvia encontra a expertise arquitetural e de compliance portuária de Hamburgo - a sede em Hamburgo entrega a conexão com HPA, aduana alemã e regulamento portuário UE; Cracóvia entrega a delivery operacional na realidade portuária polonesa. Para clientes brasileiros que dependem de logística Báltico-UE o eixo São Paulo - Cracóvia - Gdańsk permite acompanhamento em múltiplos fusos com mesma arquitetura.

## Por que Gdańsk funciona como ponto de partida para Enterprise AI

Gdańsk é o mercado polonês mais difícil em IA, porque a paisagem regulatória é a mais complicada - autoridade portuária, KNF, UODO, EU AI Act e regulação marítima internacional engrenam-se. É exatamente isso que faz dele o stress-test ideal. Quem constrói um agent que cumpre as exigências do Port of Gdańsk, desenhou arquitetura que funciona em praticamente qualquer mercado logístico-intensivo da UE. O Gdańsk Science & Technology Park e o cluster Alchemia oferecem engenheiros com essa expertise multi-domínio; a Politechnika Gdańska entrega formação contínua. Para médios industriais DACH com logística Báltico, Gdańsk costuma ser o primeiro site internacional onde Enterprise AI é efetivamente necessária - e onde a arquitetura precisa provar em vento regulatório real. O eixo Hamburgo - Gdańsk conecta dois dos portos mais importantes do Báltico - o que existe de experiência Hamburg (HPA, aduana, regulamento UE) transfere-se diretamente. Uma implementação bem sucedida em Gdańsk abre o mercado polonês inteiro e entrega blueprint arquitetural que pode ser estendido a [Varsóvia](/br/agentes-ia-varsovia/), [Cracóvia](/br/agentes-ia-cracovia/) e [Wrocław](/br/agentes-ia-wroclaw/). Mais em [Polônia em visão geral](/br/agentes-ia-polonia/).

--- Agentes IA para Empresas em Hannover | Gosign ---
> Enterprise AI Agents para Hannover e Baixa Saxônia. Indústria e médias empresas - auditável, LGPD-compliant. 90 minutos de Hamburgo.

## Hannover é o local em que o segundo maior ressegurador do mundo, o maior fornecedor industrial alemão e a economia global de feiras dividem a mesma estação central

No corredor entre Hauptbahnhof, terreno da feira e List-Süd estão Continental como segundo maior fornecedor automotivo da Alemanha com sede corporativa, Hannover Rück como segundo maior ressegurador do mundo depois de Munich Re, HDI como linha de seguro direto do grupo Talanx, TUI como maior grupo europeu de viagens e VW Veículos Comerciais com a maior planta em Stöcken. Somam-se Sennheiser em Wedemark, Enercon em Aurich como maior fabricante alemão de turbinas eólicas, e a Deutsche Messe AG com a Hannover Messe e o legado da CeBIT. Essa mistura cria uma estrutura de mercado de IA específica: corporações com alta carga de compliance encontram médias empresas técnicas com potenciais concretos de automação, mas que precisam de governance enterprise. O mercado da Baixa Saxônia é, depois da NRW e da Baviera, o terceiro maior estado industrial da Alemanha.

## As três barreiras regulatórias que definem toda iniciativa de IA no mercado de Hannover

A primeira é a supervisão de seguros para o grupo Talanx e Hannover Rück. As exigências da BaFin sobre risco de modelo, o reporting Solvência II e os requisitos ORSA específicos para resseguradoras atingem cada componente de IA em underwriting, reservas e modelagem CAT. A Hannover Rück trabalha no dia a dia com modelos para portfolios de catástrofes naturais e cenários pandêmicos, cuja validação está sob os padrões mais altos e cujos componentes de IA precisam ser defendidos contra frameworks internos de risco de modelo. (Para o leitor brasileiro: o equivalente seria SUSEP + IRB Brasil Re, mas com supervisão europeia e padrões mais rigorosos de validação.)

A segunda barreira é a Lei Federal de Proteção contra Imissões BImSchG, relevante no dia a dia para Continental como grande produtor industrial e para Enercon como operador eólico - cada componente de IA em monitoramento de emissões ou controle de planta precisa ser comprovável na lógica de licenciamento BImSchG. A terceira barreira é a forte cogestão IG Metall nas plantas Continental e VW e em Sennheiser - uma aplicação de IA com dados pessoais ou medição de desempenho só passa pelos conselhos de empresa se o [Decision Layer](/br/decision-layer/) impuser a decisão final humana e o Audit Trail documentar a justificativa. Mais sobre o quadro em [Governance EU AI Act](/br/governance/eu-ai-act/).

## Cenários típicos de implementação em Hannover

Na Continental vemos agentes de dados de qualidade na produção de pneus que consolidam dados de medição de várias plantas e escalam anomalias a Quality Engineers - com avaliação rastreável. Na planta da VW Veículos Comerciais em Stöcken agentes trabalham em Use Cases de planejamento de produção e gestão de fornecedores, em que um Production Steering toma a decisão final. Em HDI e Hannover Rück agentes apoiam a regulação de sinistros e o CAT modelling - o agente enriquece os resultados do modelo com dados contratuais e fontes externas, os underwriters decidem.

Na TUI Customer Service Agents ajudam na estruturação de demandas de cliente e priorização de retornos. Em Sennheiser e nas médias empresas mais amplas vemos Document Agents para faturas de entrada, análise de contratos e comunicação com fornecedores - a entrada típica quando um gargalo concreto na contabilidade deve ser automatizado. Na Enercon agentes trabalham em preparações de Predictive Maintenance para turbinas eólicas, em que técnicos de serviço decidem quando trocar um componente - o agente estrutura os dados de sensor, o gerente de serviço decide sobre a janela de manutenção. Na Deutsche Messe AG vemos Knowledge Agents no atendimento a expositores e visitantes que estruturam consultas recorrentes e as repassam ao planejamento da feira. O banco de fomento estadual NBank trabalha com Document Agents na verificação de pedidos de projetos de fomento de IA - aqui um agente ajuda na preparação estruturada da documentação para os despachantes. Em qualquer caso, o Audit Trail mantém a cadeia de justificativa.

## Como a Gosign atende Hannover a partir de Hamburgo

Hannover é o próximo grande mercado alemão da nossa sede em Hamburgo - o ICE direto Hamburgo-Hannover leva pouco menos de 90 minutos. Encontros presenciais são viáveis no mesmo dia. Concretamente: Discovery Workshops com Engineering, Compliance e cogestão conduzimos presencialmente, frequentemente como bloco de um a dois dias. Na fase de Engineering combinamos trabalho remoto com dias presenciais semanais, porque a curta viagem torna isso viável sem barreiras logísticas. Revisões de arquitetura, validações de modelo para Solvência II e negociações de cogestão acontecem presencialmente.

Para Continental e Hannover Rück com sedes corporativas no centro de Hannover, estamos frequentemente várias vezes por mês presencialmente - a proximidade não torna a frequência presencial um problema logístico. Clusters como Hannover Impuls como agência de fomento econômico da capital estadual e a rede de inovação da Baixa Saxônia usamos para discussões técnicas e contatos com a NBank, que acompanha muitos projetos de IA nas médias empresas saxãs. A Hannover Messe, como maior feira industrial do mundo, entrega anualmente um panorama compacto de mercado e é, para muitos dos nossos projetos com clientes, uma âncora natural para decisões de produto. Para grupos brasileiros do setor automotivo e industrial com operações na Baixa Saxônia (Volkswagen Brasil mantém forte ligação com Wolfsburg, próxima a Hannover), coordenamos a partir do [escritório em São Paulo](/br/agentes-ia-sao-paulo/) com a equipe de Hamburgo.

## Por que Hannover funciona como ponto de partida para Enterprise AI

Hannover tem uma propriedade que não existe em nenhum outro mercado alemão: a combinação de sedes corporativas com alta carga de compliance e médias empresas técnicas amplas, que não funcionam apenas como cadeia de suprimentos das corporações, mas atendem mercados globais próprios. Quem coloca aqui um primeiro AI Agent em produção, defendeu-o tipicamente contra compliance de seguro, cogestão industrial e pragmatismo de média empresa - os três stress tests mais duros que o mercado alemão tem a oferecer. Soma-se a localização geográfica: 90 minutos para Hamburgo, duas horas para Berlim, três horas para Frankfurt. Hannover é assim a âncora natural para uma escala multi-regional na DACH. O talento de ML Engineering vem da Universidade Leibniz Hannover com sua forte faculdade de informática, do centro de pesquisa L3S com foco em Web Science e ML, e do site DFKI como âncora para pesquisa aplicada de IA. Quem em 4-6 semanas tem um agente em produção em uma corporação ou média empresa de Hannover, beneficia-se da proximidade ao Engineering de Hamburgo e pode depois transferir o Use Case para toda a rede do norte da Alemanha. Mais sobre o procedimento em [serviços AI Agents](/br/servicos/ai-agents/).

--- Agentes IA para Empresas em Lisboa e Portugal | Gosign ---
> Enterprise AI Agents em Lisboa. Gestão de projetos local, EU AI Act diretamente aplicável, RGPD conforme. Do PoC à operação independente em 12-18 meses.

## Lisboa é a capital europeia de crescimento tecnológico mais rápido - com um regime de proteção de dados surpreendentemente rigoroso

Nos últimos dez anos Lisboa deixou de ser dica turística para se tornar o hub tech do oeste europeu. EDP (Energias de Portugal) e Galp Energia compõem o núcleo de energia; Millennium BCP e Caixa Geral de Depósitos são a espinha bancária; o grupo Jerónimo Martins (Pingo Doce, Recheio, Biedronka na Polônia) é a maior rede de supermercados do país. NOS e Altice Portugal dominam telecom. Somam-se os campeões tech lusitanos: Farfetch (marketplace de luxo), OutSystems (plataforma low-code com escala global) e Feedzai (fraud detection baseada em IA para bancos no mundo todo). No Beato Innovation District e no Hub Criativo do Beato ficam centenas de startups - a cidade atrai talento de toda a Europa, pois o custo de vida é menor que em Berlim ou Amsterdam e o ecossistema tech fica mais denso a cada trimestre. Para o eixo lusófono Brasil-Portugal, Lisboa é a ponte natural: mesma língua, realidades regulatórias distintas mas articuláveis, e um mercado de capitais europeu acessível.

## As três barreiras regulatórias para IA no mercado português

A primeira é a **CNPD (Comissão Nacional de Proteção de Dados) junto à Lei 58/2019** - a lei portuguesa que transpõe o RGPD. A CNPD é uma das autoridades mais consistentes do sul da Europa e aplicou nos últimos anos várias multas relevantes contra operadoras de telecom, bancos e entidades públicas. A CNPD audita sistemas de IA com foco especial em transparência, minimização de dado e direito à decisão humana sob o Art. 22 do RGPD. Para a realidade brasileira, a analogia é a LGPD (PT: RGPD) fiscalizada pela ANPD - estruturalmente similares, com divergências no detalhe que exigem arquiteturas que atendam às duas sem retrofit.

A segunda é o **EU AI Act, diretamente aplicável em Portugal**. O governo português designou a ANACOM (Autoridade Nacional de Comunicações) e a CNPD como coordenadoras da transposição, com plano de estruturar uma autoridade de market surveillance própria. Sistemas de alto risco - em especial em energia e serviços financeiros - serão auditados sistematicamente a partir de 2026. Para grupos brasileiros com operação portuguesa isso significa atender EU AI Act em Lisboa e LGPD + o futuro PL 2338/2023 no Brasil - mesma arquitetura, regras de roteamento por jurisdição.

A terceira é o **Banco de Portugal junto à CMVM (Comissão do Mercado de Valores Mobiliários)** para serviços financeiros. Ambos já alinharam expectativas comuns sobre governance de modelo de IA: explicabilidade, Audit Trail, reprodutibilidade, mitigação de viés. Millennium BCP e Caixa Geral de Depósitos já trabalham em frameworks internos. [EU AI Act Governance](/br/governance/eu-ai-act/) e supervisão financeira se amarram aqui.

## Cenários típicos de implementação em Lisboa

**Análise de crédito no Millennium BCP**: os modelos de crédito para PME precisam permanecer reproduzíveis sob supervisão da CNPD e do Banco de Portugal - toda recusa é justificável no prazo legal. Document Agents reúnem balanço e histórico; o Decision Layer escala casos fronteiriços ao analista com Audit Trail.

**Smart Meter na EDP**: a EDP opera infraestrutura de medição inteligente em Portugal, Espanha e Brasil e usa IA para previsão de carga e detecção de anomalia - os modelos precisam ser documentados para a ERSE (Entidade Reguladora dos Serviços Energéticos). Workflow Agents monitoram padrões, Decision Layer roteia ocorrências críticas ao engenheiro de rede.

**Fraud detection na Feedzai**: a Feedzai desenvolve modelos para bancos no mundo inteiro, com HQ em Lisboa - cada atualização de modelo precisa permanecer rastreável em Audit Trail porque clientes rodam em mercados regulados. Document Agents preservam lineage e versionamento.

**Recomendação na Farfetch**: algoritmos de recomendação para produtos de luxo em mais de 190 países - onde exigências da CNPD colidem com regimes de UK, EUA e China. Decision Agents aplicam rule set por jurisdição.

Em todos os cenários fala-se de IA que não vive em laboratório, vive em lógica de negócio regulada com consequência mensurável. O [Decision Layer](/br/decision-layer/) resolve a arquitetura: Audit Trail em nível SQL, Human-in-the-Loop em casos escaláveis, Cert-Ready by Design. Uma particularidade portuguesa: a Comissão de Trabalhadores tem direitos de informação e consulta na introdução de sistemas de IA. Construímos o Decision Layer de modo que essas obrigações não sejam traduzidas depois, funcionem como parte da Governance. Isso é especialmente relevante para grupos como Jerónimo Martins, com dezenas de milhares de funcionários e IA com impacto direto em escala e planejamento. No Brasil o análogo é sindicato/CRE com direito de consulta, não de veto.

## Como a Gosign atende Portugal a partir do escritório de Lisboa

A Gosign mantém escritório próprio em Lisboa (gosign.pt) com time português - falantes nativos, gestão de projeto local, contato direto com CNPD, Banco de Portugal e CMVM. O escritório de Lisboa é hub regional para Portugal: Discovery Workshops, Sprint Reviews e steering acontecem presencialmente no Beato Innovation District, no Hub Criativo do Beato ou nas sedes de Galp, EDP, Millennium BCP, Caixa Geral e Jerónimo Martins. Para os champions tech Feedzai, OutSystems e Farfetch trabalhamos em pé de igualdade com a cultura de engenharia local, workshops e code reviews em português, documentação em português e inglês, com a Comissão de Trabalhadores à mesa desde o primeiro dia.

Em projetos LATAM o time de Lisboa acopla com o escritório de São Paulo (gosign.com.br) - Brasil e Portugal como mercado lusófono conectado, com idioma comum, cultura de negócio comum e uma arquitetura que atende LGPD e RGPD em paralelo. Essa combinação é única no mercado: para grupos brasileiros com operação portuguesa o eixo São Paulo - Lisboa significa mesma equipe, mesma arquitetura, atendendo ANPD e CNPD simultaneamente. A sede em Hamburgo entrega revisões arquiteturais e integração com matrizes DACH. Cooperamos estreitamente com Startup Lisboa e com o pool de talento local.

## Por que Lisboa funciona como ponto de partida para Enterprise AI

Portugal é pequeno o bastante para que um projeto de IA acolha vários stakeholders de setor em torno da mesma mesa, e grande o bastante para exigir compliance real. Quem constrói em Lisboa um piloto Cert-Ready by Design tem um caso de referência que passou em padrões CNPD e EU AI Act - depois defensável no Brasil (LGPD), na Espanha (LOPDGDD) e em toda a Europa. O Lisbon Tech Hub, a Startup Lisboa e o Beato Innovation District entregam talento, acesso a investidor e parceiros piloto. Trazemos a disciplina de construir sistemas que se mantêm produtivos sob supervisão CNPD rigorosa - com Governance by Design e a seriedade que marca a prática alemã de proteção de dados. Lisboa é o mercado certo para escalar essa disciplina na península ibérica. Para grupos brasileiros que usam Portugal como trampolim para o espaço lusófono (Angola, Moçambique, Cabo Verde), Lisboa é o único site europeu de onde essa ponte se constrói arquitetonicamente limpa. Mais em [Brasil](/br/agentes-ia-brasil/) ou [serviços AI Agents](/br/servicos/ai-agents/).

--- Agentes IA para Empresas em Londres | Gosign ---
> Enterprise AI Agents para Londres. UK GDPR e LGPD-compliant, auditável, preparado para FCA. IA auditável para a City e além.

## Em Londres, cada decisão de IA precisa satisfazer dois regimes de proteção de dados ao mesmo tempo - é a brecha de compliance mais cara da Europa

Desde o Brexit Londres deixou de ser o centro financeiro da UE para se tornar o centro da dupla regulação europeia. HSBC, Barclays, Lloyds Banking Group, NatWest, Standard Chartered e Prudential operam aqui suas sedes. BP e Shell mantêm em Londres o HQ global, a AstraZeneca coordena estudos clínicos globais a partir daqui, e no tech ficam Revolut, DeepMind e ARM Holdings. A "Square Mile" segue sendo o maior centro financeiro da Europa e é provavelmente o único mercado em que uma mesma empresa precisa atender simultaneamente regulação UK, regulação UE e regime de sanções dos EUA - muitas vezes no mesmo sistema. Quem constrói Enterprise AI aqui, constrói não para uma jurisdição, mas para uma interseção. Contexto relevante para grupos brasileiros com operação em Londres - de Itaú BBA, BTG Pactual, Vale London a Petrobras Global Finance.

## As três barreiras regulatórias para IA no mercado de Londres

A primeira é o **regime duplo UK GDPR + EU GDPR**. Pós-Brexit vale no Reino Unido o UK GDPR, mas assim que a empresa tem negócio com cliente UE - o que quase toda grande de Londres tem - atua em paralelo o EU GDPR via mecanismo de Adequacy. O ICO (Information Commissioner's Office) audita o lado UK; para o lado UE, a autoridade competente depende da subsidiária UE. Os dois regimes divergem no detalhe e seguem se afastando - especialmente em decisão automatizada Art. 22 ou em mecanismos de transferência de dados. Quem constrói arquitetura de IA aqui precisa ser dual-compliant.

A segunda é o **UK AI White Paper**, que adota abordagem setorial em vez de lei horizontal como o EU AI Act. FCA (Financial Conduct Authority), PRA (Prudential Regulation Authority), ICO e CMA (Competition and Markets Authority) desenvolvem diretrizes de IA próprias para seus setores. A FCA, com o AI Public-Private Forum, já articulou expectativas concretas sobre governance de modelo, explicabilidade e accountability de conselho. Quem constrói banking AI em Londres constrói para pelo menos quatro reguladores simultaneamente, em profundidade diferente.

A terceira é o **DSA e DMA para plataformas londrinas com negócio UE**. Quem, de Londres, fala ao consumidor europeu cai sob a regulação de plataforma da UE - independente do direito UK. [EU AI Act Governance](/br/governance/eu-ai-act/) vira a interface crítica: empresas britânicas com negócio UE substancial precisam se comportar praticamente como empresas UE, sem o escudo da filiação à União. Para brasileiros a leitura importante é: a LGPD governa o Brasil; em Londres soma-se UK GDPR + EU GDPR + o recorte setorial britânico de IA. Nada disso remove o PL 2338/2023 do horizonte brasileiro.

## Cenários típicos de implementação em Londres

**Fraud Detection no HSBC**: o HSBC opera fraud detection com modelos em mais de 60 países que precisam atender simultaneamente FCA, ICO, supervisão UE e OCC dos EUA. Document e Workflow Agents preservam lineage por jurisdição com Audit Trail completo.

**Underwriting no Lloyd's of London**: o Lloyd's usa IA para decisões de underwriting em seguros especializados - cada avaliação automática de risco precisa ser documentável diante do Performance Management Directorate e reproduzível em caso de sinistro. Document Agents preparam os dossiês de subscrição.

**Conduct Rule Compliance sob a FCA**: a FCA exige das firmas reguladas conformidade com as Conduct Rules para ferramentas de IA - a responsabilidade do conselho precisa ficar rastreável. Workflow Agents registram aprovações, Decision Layer impõe caminhos de escalação.

**Pharmacovigilance na AstraZeneca**: a AstraZeneca documenta estudos clínicos para MHRA e, em paralelo, para EMA - cada análise apoiada em IA precisa ser defensável nos dois regimes. Document Agents mantêm proveniência de dado e versionamento.

Em todos os cenários a pergunta central não é "o modelo funciona?", é "conseguimos defender a decisão em várias jurisdições?". O [Decision Layer](/br/decision-layer/) resolve exatamente isso: roteia cada decisão por rule sets específicos, persiste Audit Trail com metadado completo e impõe Human-in-the-Loop em decisões com exame relevante em múltiplos regimes. Soma-se a dimensão pessoal: o UK Senior Managers and Certification Regime (SMCR) responsabiliza pessoalmente os diretores por decisões de IA das suas áreas. Um Director britânico que não consiga documentar governance de modelo arrisca banimento pessoal do setor - um degrau mais rigoroso que multas do GDPR no continente, e a razão pela qual os bancos britânicos levam Cert-Ready by Design a sério há anos.

## Como a Gosign atende Londres a partir de Hamburgo

Hamburgo-Londres é voo direto de cerca de 90 minutos, com várias conexões diárias via LH, BA e EasyJet. Trabalhamos remote-first com clientes na City e em Canary Wharf, com workshops presenciais para Discovery, decisões arquiteturais e revisões críticas de compliance. Língua de trabalho em inglês; steering interno em alemão com nossos arquitetos de Hamburgo. O fuso (GMT/BST, uma hora atrás do CET) é confortável e sobreposto com o dia de trabalho alemão.

O que trazemos do mercado alemão é experiência concreta com regulação dual. Bancos alemães trabalham por padrão com BaFin, ECB e FCA simultaneamente - a lógica de compliance multi-jurisdicional nos é familiar. Conhecemos bem as expectativas da FCA sobre governance de modelo para, logo no primeiro workshop, fazer decisões arquiteturais concretas em vez de traduzir reguladores. Para clientes brasileiros com operações em Londres o eixo São Paulo - Hamburgo - Londres entrega a mesma arquitetura atendendo LGPD, UK GDPR e EU GDPR ao mesmo tempo.

## Por que Londres funciona como ponto de partida para Enterprise AI

Londres tem a pressão regulatória mais alta de IA na Europa, porque dois regimes de proteção de dados em afastamento progressivo se cruzam aqui. Quem constrói em Londres um piloto Cert-Ready by Design dual-compliant tem um caso de referência defensável em qualquer outro mercado - inclusive EUA, Suíça e APAC. O cluster Silicon Roundabout, Canary Wharf, o programa London Tech City e a rede Tech Nation entregam talento, ecossistema e parceiros piloto. Segunda vantagem: Londres obriga a arquitetura que não é construída para uma só jurisdição, mas para rule sets específicos sobre o mesmo Audit Trail. É Governance by Design - e se funciona em Londres, funciona em qualquer lugar. Hamburgo aporta a disciplina alemã de engenharia; Londres aporta o stress-test global de compliance. Mais no [Reino Unido](/br/agentes-ia-reino-unido/) ou em [serviços AI Agents](/br/servicos/ai-agents/).

--- Agentes IA para Empresas em Madrid | Gosign ---
> Enterprise AI Agents para Madrid. Sede da AESIA, EU AI Act aplicável, LGPD-compliant. Agentes auditáveis para o centro empresarial da Espanha.

## Madrid é a única capital europeia onde os reguladores nacionais de dados e de finanças ficam a pé uns dos outros

Quem constrói Enterprise AI em Madrid constrói literalmente na porta da supervisão espanhola. A AEPD (Agencia Española de Protección de Datos), a CNMV (Comisión Nacional del Mercado de Valores), o Banco de España e a CNMC (Comisión Nacional de los Mercados y la Competencia) têm, todos os quatro, sede em Madrid. Some-se o aparato político: o Ministerio de Asuntos Económicos e o Ministerio de Industria, Comercio y Turismo decidem aqui sobre a transposição do EU AI Act. No lado corporativo estão Banco Santander, BBVA, Telefónica, Repsol, Iberdrola (HQ em Bilbao mas operação forte em Madrid), Mapfre, Ferrovial, ACS, Naturgy, Red Eléctrica e Amadeus IT. Quem constrói arquitetura de IA aqui constrói para uma concentração de big corporates e autoridades regulatórias que, na Europa, só Frankfurt e Paris emparelham. Contexto importante para grupos brasileiros: Itaú Europa, Votorantim Iberia, Embraer Europa, Vale e Petrobras têm, muitas vezes, presença direta em Madrid.

## As três barreiras regulatórias para IA no mercado de Madrid

A primeira é a **AEPD em conjunto com a LOPDGDD (Ley Orgánica 3/2018)**, a lei espanhola que transpõe o GDPR com endurecimentos. A AEPD é conhecida em toda a UE pela interpretação estrita do Art. 22 GDPR - decisões totalmente automatizadas são, na prática, inadmissíveis na Espanha sem última decisão humana documentada. A autoridade impôs nos últimos anos multas de oito e nove dígitos, frequentemente contra bancos e operadoras. O Decision Layer com Human-in-the-Loop aqui não é opcional, é pré-requisito de compliance.

A segunda é a **AESIA (Agencia Española de Supervisión de la Inteligencia Artificial)**. A Espanha é o primeiro país da UE com autoridade dedicada de IA. A sede fica em La Coruña, mas operacional e politicamente muito se decide em Madrid. A AESIA audita sistematicamente sistemas de alto risco sob o EU AI Act a partir de 2026 e pode impor proibições operacionais. Quem coloca modelos em produção em Madrid precisa documentar desde o dia 1 para uma auditoria AESIA. Para brasileiros o análogo em formação é o PL 2338/2023 - ainda não em vigor, mas com roadmap similar.

A terceira é a combinação **CNMV e Banco de España** para todo o setor financeiro. Ambos alinharam expectativas comuns sobre governance de modelo de IA e auditam bancos, seguradoras e asset managers em explicabilidade, Audit Trail e reprodutibilidade. Desde 2024 a CNMV exige Audit Trail completo em recomendações de investimento apoiadas em IA. [EU AI Act Governance](/br/governance/eu-ai-act/) e supervisão financeira se engrenam aqui.

## Cenários típicos de implementação em Madrid

**Análise de crédito no Banco Santander**: o Santander opera análise de crédito em 10+ países e precisa de modelos reproduzíveis sob AEPD, CNMV e Banco de España - toda recusa tem que ser justificável no prazo legal. Document Agents reúnem balanço, bureau e histórico transacional; o Decision Layer escala ao analista com Audit Trail.

**Análise de CDR na Telefónica**: a Telefónica analisa Call Detail Records para fraud detection e otimização de rede em mais de 12 mercados - os modelos precisam ser auditáveis diante de AEPD e ANACOM. Workflow Agents monitoram padrões em tempo real.

**Regulação de sinistro na Mapfre**: a Mapfre usa IA para avaliação automática de sinistros e precisa de modelos que expliquem cada estimativa ao segurado. Document Agents preparam os dossiês técnicos.

**Operação de rede elétrica na Iberdrola**: operações de rede em Madrid caem em categorias de alto risco do EU AI Act - os modelos precisam estar documentados para Red Eléctrica e CNMC.

Em cada um desses casos o [Decision Layer](/br/decision-layer/) é a arquitetura que junta Audit Trail em nível SQL, escalação Human-in-the-Loop e Cert-Ready by Design - exatamente o que as autoridades de Madrid querem ver juntas. Uma especificidade madrilena é a complexidade corporativa: a maior parte dos grandes grupos espanhóis opera em ibero-américa - Santander em 10+ países, BBVA em México e Turquia, Telefónica no Brasil e Alemanha. Uma arquitetura de IA em Madrid precisa impor rule sets jurisdicionais para GDPR, LGPD, LFPDPPP mexicana e KVKK turca simultaneamente - tudo sobre o mesmo Audit Trail. Quem constrói isso em Madrid tem arquitetura para todo o mundo hispânico. Vantagem óbvia para empresas brasileiras: as mesmas arquiteturas servem o eixo São Paulo - Madri - Lisboa.

## Como a Gosign atende Madrid a partir de Barcelona

A Gosign atende projetos em Madrid a partir do escritório de Barcelona (gosign.es) com gerentes de projeto e engenheiros de língua espanhola. A conexão AVE Barcelona-Madrid leva pouco menos de duas horas e meia - presenças semanais em Santander, BBVA, Telefónica, Mapfre, Iberdrola e Repsol são rotina, não logística. Discovery Workshops, Sprint Reviews e steering rodam presencialmente no Paseo de la Castellana, em Las Tablas ou direto nas sedes, com responsáveis técnicos falantes de espanhol e representantes do Comité de Empresa à mesma mesa.

Madrid é a cidade dos principais reguladores espanhóis - AEPD, CNMV, Banco de España e CNMC a pé - e o time espanhol vai regularmente para alinhamentos regulatórios, preparação de auditoria e sandbox. A sede em Hamburgo cobre coordenação DACH e internacional e revisões arquiteturais; dia a dia operacional, cultura corporativa madrilena e contato com autoridades ficam no time de Barcelona. Para clientes brasileiros com operações em Madrid o eixo São Paulo - Barcelona - Madrid opera com mesma arquitetura: LGPD e RGPD + LOPDGDD lado a lado.

## Por que Madrid funciona como ponto de partida para Enterprise AI

Madrid é a única cidade da Europa onde se alcança as quatro autoridades espanholas de supervisão a pé - e onde a maior parte das respostas regulatórias chega em dias, não semanas. Quem aqui constrói um piloto Cert-Ready by Design tem um caso de referência que passou em padrões AEPD, AESIA, CNMV e Banco de España. Os clusters Madrid in Motion, Impact Hub Madrid e Wayra Madrid (Telefónica) entregam talento, parceiros piloto e acesso a investidor. Trazemos do mercado alemão a experiência de construir sistemas que não apenas funcionam, mas se mantêm produtivos sob supervisão rigorosa - com Governance by Design e Audit Trail. Madrid é o mercado certo para levar essa disciplina ao coração da economia espanhola. Mais em [Espanha](/br/agentes-ia-espanha/) ou em [serviços AI Agents](/br/servicos/ai-agents/).

--- Agentes IA para Empresas na Polônia | Gosign ---
> Enterprise AI Agents para a Polônia. EU AI Act compliant, LGPD-compliant, auditável. Escritório em Cracóvia, projetos em toda a Polônia.

## A Polônia é, ao mesmo tempo, o maior país de outsourcing de TI da Europa e uma digital economy autônoma

A Polônia é o único mercado da UE onde duas economias tech estruturalmente distintas convivem. De um lado, os Global Capability Centers de matrizes oeste-europeias em [Cracóvia](/br/agentes-ia-cracovia/), [Wrocław](/br/agentes-ia-wroclaw/) e [Gdańsk](/br/agentes-ia-gdansk/) - ABB, Cisco, IBM, Capgemini, UBS, Bosch, LG Electronics, Amazon Development Center, Volvo, Toyota Motor Manufacturing Poland. Do outro, os conglomerados puramente poloneses com sede em [Varsóvia](/br/agentes-ia-varsovia/) e Cracóvia: PKO BP, Pekao, Santander Bank Polska, ING Bank Śląski, mBank, BNP Paribas Polska, PZU, Warta, Allegro, LPP, Dino Polska, Biedronka (Jerónimo Martins), CCC, Ciech, Grupa Azoty, JSW, KGHM, CD Projekt, Asseco, Comarch. Essa estrutura dual cria um mercado de IA que, simultaneamente, precisa atender ao compliance corporativo das matrizes e à regulação polonesa própria. Contexto relevante para grupos brasileiros que contratam outsourcing polonês ou que atendem cadeias DACH com presença na Polônia.

## As três barreiras regulatórias para IA no mercado polonês

A primeira é o **KSeF e a faturação eletrônica**: o KSeF (Krajowy System e-Faktur) tornou-se progressivamente obrigatório na Polônia para todas as empresas. Centenas de milhares de notas fiscais de entrada e saída por dia precisam ser estruturadas, validadas e arquivadas - cada extração ou classificação apoiada em IA tem que ser KSeF-compliant. Grupos como Orlen, Allegro, LPP e PGE estão redesenhando suas pipelines documentais. Quem opera aqui sem base de modelo rastreável arrisca fiscalizações tributárias com ônus probatório pouco claro.

A segunda é o conjunto **UODO + RODO + lei polonesa de proteção de dados**: o UODO (Urząd Ochrony Danych Osobowych) virou, nos últimos anos, um dos reguladores de proteção de dados mais ativos da UE. Em profiling e decisão automatizada sob o Art. 22 GDPR, o UODO exige bases legais documentadas, explicações acessíveis e Audit Trail completo. Especificidade polonesa: em decisões relevantes para RH, a Rada Zakładowa tem direitos de informação e consulta que precisam ser impostos arquitetonicamente - com direito de consulta, não de veto.

A terceira é o conjunto **KNF, NBP e EU AI Act**: a Komisja Nadzoru Finansowego, sediada em Varsóvia, supervisiona o setor financeiro polonês e exige última decisão humana comprovável em AML, KYC, credit scoring e manejo de sinistros em casos de risco. O EU AI Act vale na Polônia desde fevereiro de 2025 para práticas proibidas e, pela legislação vigente, a partir de 2 de agosto de 2026, para sistemas de alto risco (adiamento para dezembro de 2027 acordado provisoriamente - Digital Omnibus, maio de 2026) - sem lei nacional de transposição, portanto diretamente aplicável. Quem usa IA de alto risco em RH, banking ou seguros precisa de Conformity Assessment, risk management e post-market monitoring no nível que resiste a auditoria da KNF ou do UODO. Para brasileiros a observação importante: o EU AI Act aplica-se diretamente na Polônia; no Brasil o equivalente em formação é o PL 2338/2023.

## Cenários típicos de implementação na Polônia

**AML em PKO BP e mBank**: os bancos poloneses processam milhões de transações por dia. Document Agents extraem dados de identificação; o Decision Layer roteia casos suspeitos pelas faixas da KNF, com Human-in-the-Loop em cada escalação final e Audit Trail completo para supervisão.

**Pipeline KSeF em Allegro, LPP e Dino Polska**: os maiores retailers da Polônia e o líder de e-commerce estão sob pressão KSeF. Document Agents extraem dados estruturados de nota fiscal, validam contra o esquema KSeF e roteiam desvios à contabilidade.

**Operações em JSW e KGHM**: grupos de mineração e metalurgia polonesa geram diariamente enormes volumes de sensor e ocorrências de segurança. Workflow Agents classificam anomalias, escalam casos de segurança ao líder de turno e registram cada decisão para o Wojewódzki Inspektorat Ochrony Środowiska e análises relevantes à KNF.

**Operações de software em Comarch e Asseco**: os dois grupos poloneses desenvolvem software bancário e de seguros para toda a Europa Central. Document Agents verificam documentação de release contra exigências de KNF, BaFin e FINMA antes de cada entrega.

Em todos os cenários o [Decision Layer](/br/decision-layer/) entrega Governance by Design, escalação Human-in-the-Loop e Audit Trail exportável.

## Como a Gosign atende toda a Polônia a partir de Cracóvia

A Gosign mantém escritório próprio em Cracóvia (gosign.pl) como hub regional para o mercado polonês. O time polonês com gerentes de projeto e engenheiros - nativos em polonês, fluentes em inglês - cobre os quatro grandes clusters tech do país: [Varsóvia](/br/agentes-ia-varsovia/) como capital corporativa e regulatória, [Cracóvia](/br/agentes-ia-cracovia/) como hub de shared services, [Wrocław](/br/agentes-ia-wroclaw/) como híbrido indústria-TI e [Gdańsk](/br/agentes-ia-gdansk/) como ponto portuário e tech.

Presenças, Sprint Reviews e steering rodam em polonês, sem barreira de idioma e sem overhead de viagem internacional. A sede em Hamburgo entrega padrões arquiteturais, expertise DACH de compliance e integração com matrizes alemãs, suíças e holandesas - delivery, dia a dia e contato com cliente ficam no time de Cracóvia. Essa estrutura é decisiva para médias empresas polonesas e filiais que querem qualidade DE-orientada sem trazer barreira de idioma para dentro de casa. Para clientes brasileiros com operações na Polônia o eixo São Paulo - Cracóvia - Hamburgo entrega mesma arquitetura cobrindo LGPD, RODO e EU AI Act em paralelo.

## Por que a Polônia funciona como ponto de partida para Enterprise AI

A Polônia é, para grupos alemães, suíços e holandeses, o stress-test mais próximo em IA. Quem põe em produção um agent que atende simultaneamente KSeF, UODO, KNF e o EU AI Act, desenhou arquitetura a apenas uma configuração de qualquer outro mercado do oeste europeu. A Polônia combina máxima disponibilidade de talento (Cracóvia, Wrocław, Varsóvia, Gdańsk) com máxima pressão regulatória (KNF, UODO, KSeF, EU AI Act, RODO). O cluster formado por Krakow Technology Park, Warsaw Spire Tech, Wrocław Technology Park e Gdańsk Science & Technology Park é a maior paisagem tech contígua da Europa Central e Oriental.

Acresce-se uma propriedade que torna a Polônia especialmente previsível para Enterprise AI: a proximidade operacional com a Alemanha. Conglomerados poloneses trabalham há décadas com matrizes alemãs, bancos poloneses mantêm correspondência com Frankfurt e Munique, e sites industriais poloneses estão plugados em cadeias alemãs. A linguagem de compliance está rodada, e as expectativas sobre Audit Trail, explicabilidade e Governance by Design não são novidade. Uma implementação bem sucedida na Polônia não é só passo de abertura de mercado, é referência arquitetural aceita de imediato na região DACH. Cert-Ready by Design aqui não é frase de marketing, é pré-condição do primeiro dia produtivo - e, ao mesmo tempo, o caminho mais rápido para uma plataforma Enterprise AI que depois entra em produção em outros quinze países da UE. Mais em [EU AI Act](/br/governance/eu-ai-act/) no Governance.

--- Agentes IA para Empresas no Reino Unido | Gosign ---
> Enterprise AI Agents para o Reino Unido. UK GDPR e LGPD-compliant, auditável. IA que satisfaz regimes regulatórios britânicos e brasileiros.

## O Reino Unido é o único mercado próximo à UE com regulação dual obrigatória

O Reino Unido é a única grande economia europeia onde toda empresa média-grande com negócio continental precisa tornar seus sistemas de IA auditáveis simultaneamente contra dois regimes regulatórios independentes. Do lado britânico estão UK GDPR, ICO como autoridade de proteção de dados, FCA e PRA para serviços financeiros, Ofcom para telecom e mídia e CMA para concorrência. Do lado europeu seguem valendo GDPR e EU AI Act para qualquer dataset que envolva cliente, empregado ou subsidiária da UE. HSBC, Barclays, Lloyds e NatWest operam funções corporativas que atendem os dois mundos em paralelo. BP, Shell, AstraZeneca, GSK e Unilever processam diariamente dados que ora caem na jurisdição UK, ora na jurisdição UE. Tesco, Sainsbury's, BT, Vodafone, ITV e BBC enfrentam o mesmo em escala nacional. Os cenários se distribuem entre Londres, Manchester, Edimburgo, Glasgow, Birmingham, Leeds e Bristol - mas o problema regulatório é o mesmo em todos. Contexto relevante para grupos brasileiros com operações no UK ou para empresas que servem cadeias UK-UE.

## As três barreiras regulatórias para IA no mercado do Reino Unido

A primeira é o **UK GDPR e a supervisão do ICO**. Pós-Brexit o UK GDPR funciona como lei nacional de proteção de dados, fiscalizada pelo Information Commissioner's Office. Em decisão automatizada, o ICO espera bases de modelo documentadas, capacidade de resposta ao titular e Audit Trail completo. O planejado Data Protection and Digital Information Bill introduzirá algumas facilitações UK-específicas sem derrubar o núcleo. Quem move dado entre UK e UE precisa ainda de um arranjo de Adequacy ou SCCs - camada de compliance que nenhuma outra jurisdição europeia exige nessa forma.

A segunda é o conjunto **FCA, PRA e Bank of England** para o setor financeiro. HSBC, Barclays, Lloyds e NatWest estão sob supervisão direta de FCA e PRA. A FCA já sinalizou em várias publicações que, em decisões apoiadas por IA em crédito, underwriting, AML e conduct risk, espera os mesmos padrões de explicabilidade e supervisão aplicados a decisões humanas. A abordagem UK-específica: em vez de lei unificada de IA como o EU AI Act, o Reino Unido opta por regulação setorial - FCA define padrões para Finance, ICO para proteção de dados, Ofcom para comunicação. Quem usa IA em vários setores dentro do mesmo grupo lida com expectativas diferentes por regulador.

A terceira é o **EU AI Act para qualquer empresa UK com negócio UE**. O EU AI Act não vale só para empresas da UE. Toda empresa britânica que disponibiliza output de IA na UE - via subsidiária alemã, filial holandesa ou venda direta ao cliente UE - cai no escopo extraterritorial. HSBC precisa de conformidade EU AI Act para o banco de varejo alemão. Unilever precisa para qualquer algoritmo ao consumidor rodando na UE. AstraZeneca precisa para suporte de decisão clínica em centros de estudo UE. Uma arquitetura UK-only não basta para nenhum desses grupos. Para brasileiros a leitura correta: a LGPD governa o Brasil; aqui soma-se UK GDPR + EU GDPR + EU AI Act quando existe operação no eixo.

## Cenários típicos de implementação no Reino Unido

**Conduct risk em HSBC e Barclays**: os grandes bancos britânicos estão sob dupla supervisão FCA/ESMA. Document Agents extraem indicadores compliance-relevantes das interações com cliente; o Decision Layer roteia casos suspeitos pelas faixas jurisdicionais específicas, com Human-in-the-Loop em cada escalação e Audit Trail apresentável tanto à FCA quanto à ESMA.

**HSE em BP e Shell**: as gigantes globais de energia produzem milhares de relatórios diários de segurança e meio ambiente. Workflow Agents classificam incidentes por gravidade, região e aspectos reportáveis - com caminhos de escalação diferentes por localização (UK HSE, EPA, BNetzA, OUG poloneso).

**Pharmacovigilance em AstraZeneca e GSK**: os grupos farmacêuticos britânicos mantêm estudos clínicos em toda a UE. Document Agents verificam relatórios de adverse events, classificam segundo exigências MHRA e EMA e roteiam achados críticos a responsáveis humanos de pharmacovigilance - cada decisão auditável contra o padrão regulatório aplicável.

**Algoritmos ao consumidor em Unilever e Tesco**: os grupos globais de consumo e varejo usam IA em recomendação, pricing e promoção. Decision Agents checam cada decisão exibida contra UK Consumer Protection e EU AI Act simultaneamente, com justificativas acessíveis ao ICO e à autoridade de defesa do consumidor.

Em todos os cenários o [Decision Layer](/br/decision-layer/) entrega a camada que persiste Audit Trail, Governance by Design e regras por jurisdição.

## Como a Gosign atende o Reino Unido a partir de Hamburgo

A Gosign atende projetos UK a partir da sede em Hamburgo. A combinação de expertise regulatória da UE com localização em Hamburgo não é limitação para grupos britânicos com negócio UE - é pré-requisito. Regulação dual só se constrói limpa quando os dois mundos são entendidos pelo mesmo time simultaneamente. Discovery roda presencial em Londres, Manchester ou Edimburgo, conforme a sede. O build segue remoto, com documentação em inglês, Sprint Reviews semanais em vídeo e ponto de contato fixo em Hamburgo. Presenças em Londres a cada quatro-seis semanas, voo direto Hamburgo-Londres em pouco mais de uma hora e quinze. Acompanhamos, sob demanda, reuniões presenciais em FCA, PRA ou ICO junto ao jurídico interno do cliente. Para clientes brasileiros com operações UK o eixo São Paulo - Hamburgo - Londres entrega a mesma arquitetura resolvendo LGPD (Brasil), GDPR (UE) e UK GDPR de uma só vez.

## Por que o Reino Unido funciona como ponto de partida para Enterprise AI

Nenhum outro país na Europa força grupos à arquitetura regulatória por jurisdição com a mesma consistência. Quem constrói um agent que atende UK GDPR, padrões FCA e EU AI Act ao mesmo tempo, desenvolveu arquitetura a apenas uma configuração de qualquer outro mercado ocidental. É aqui que entra o Decision Layer da Gosign com rule sets por jurisdição: em vez de rodar dois sistemas paralelos, uma plataforma carrega dois rule sets - UK no roteamento doméstico, UE no roteamento UE, e um Audit Trail que documenta, por destinatário, o conjunto de regras correto. Para grupos britânicos com negócio UE essa é a única arquitetura que não vira beco sem saída no primeiro audit do ICO ou da ESMA. Cert-Ready by Design aqui significa literalmente: pronto para duas certificações sobre uma mesma base de código. Mais contexto sobre [EU AI Act](/br/governance/eu-ai-act/) e seu efeito extraterritorial no Governance.

--- Agentes IA para Empresas no Rio de Janeiro | Gosign ---
> Enterprise AI Agents para o Rio de Janeiro. LGPD-compliant, compatível com CLT. Agentes auditáveis para energia, mineração e setor público. Gosign.

## O Rio de Janeiro é o gargalo de compliance do setor brasileiro de energia e commodities

No Rio ficam as corporações cujos riscos operacionais aparecem todo dia nos relatórios ESG do mundo: Petrobras (sede na Avenida República do Chile), Vale (sede na Praia de Botafogo, operação em Minas), Eletrobras, Light SA, Americanas e Oi. Somam-se os reguladores: CVM (Comissão de Valores Mobiliários, sede no Centro), BNDES como banco nacional de fomento, ANP (Agência Nacional do Petróleo) e ANEEL (Agência Nacional de Energia Elétrica) com representações no centro. Quem opera AI Agents em loops produtivos de compliance aqui, opera sob o olhar de quatro autoridades ao mesmo tempo - e pelo menos uma delas, pós-Brumadinho, é altamente sensível a qualquer forma de decisão algorítmica. Diferente de São Paulo, a concentração industrial aqui não é horizontal, é verticalmente aprofundada: quem vai a energia e commodities no Brasil tem no Rio o acesso mais denso de mercado.

## As três barreiras regulatórias para IA no mercado do Rio de Janeiro

A primeira é a **supervisão da CVM para empresas de capital aberto**, mais densa no Rio do que em qualquer outro lugar do Brasil. Petrobras, Vale, Eletrobras e Americanas são listadas; qualquer componente algorítmico em Investor Relations, reporte trimestral ou prevenção de insider trading precisa ser explicável a um auditor da CVM. A sede da CVM no Centro do Rio significa caminhos curtos e fiscalização intensa.

A segunda é o conjunto **ANP e ANEEL para infraestrutura regulada**. Ativos da Petrobras e redes da Eletrobras são documentados conforme ANP e ANEEL. IA que sugere janelas de manutenção, monta plano de produção ou prioriza falhas de rede cai em regulação setorial concreta - não só em LGPD. A ANP exige rastreabilidade até o nível do poço; a ANEEL até o nível da subestação.

A terceira é a **LGPD junto à pressão de transparência pós-Brumadinho**. A Vale segue desde 2019 (Brumadinho) e 2015 (Mariana) sob observação do Ministério Público Federal e da Justiça Federal. Cada decisão algorítmica em segurança de barragem, risk scoring ou monitoramento de rejeito precisa ser explicável em tribunal. Audit Trail aqui não é "nice to have", é a diferença entre denúncia criminal e linha de defesa. Importante: o EU AI Act não se aplica diretamente ao Brasil - o PL 2338/2023 é o equivalente em preparação.

## Cenários típicos de implementação no Rio de Janeiro

**Documentação de ativos na Petrobras**: Document Agents lêem protocolos de manutenção, relatórios de perfuração e comunicações à ANP de 30 anos de história de ativo, consolidando em decision records auditáveis. Quando um inspetor pergunta pela história de uma solda, a resposta deixa de ser projeto de semana e vira consulta - com Audit Trail até o arquivo original. Em grupo com 60.000 funcionários, poços do pré-sal e rede de refinarias em todo o Brasil, isso não é "nice to have", é gargalo operacional.

**Dam Safety na Vale**: Workflow Agents monitoram dados de sensor, laudos de inspeção e dados meteorológicos externos em sítios de barragem de rejeitos em Minas Gerais (coordenação operacional a partir do Rio). O Decision Layer escala padrões de risco crítico com Human-in-the-Loop à geotecnia - cada decisão documentada para ANM, MPF e compliance interno.

**Análise de crédito no BNDES**: Document Agents verificam pedidos de fomento quanto a completude, plausibilidade e conflito com critérios ESG de exclusão. O Decision Layer sinaliza casos críticos para decisão humana e produz dossiê completo por recomendação - com origem de fonte e lineage. Em crédito de fomento de centenas de milhões, a profundidade de justificativa por decisão é condição de qualquer fiscalização do TCU.

**Rights Management na Globo**: Document Agents processam contratos de licenciamento, direitos de exploração e cláusulas contratuais para o maior grupo de mídia da América Latina. O Decision Layer escala conflitos entre licença broadcast, direitos de streaming e contratos internacionais com Audit Trail até o arquivo original - crítico na era do streaming, onde direitos Globoplay são renegociados diariamente.

Em todos os cenários o [Decision Layer](/br/decision-layer/) entrega Governance by Design.

## Como a Gosign atende o Rio a partir de São Paulo

O escritório de [São Paulo](/br/agentes-ia-sao-paulo/) está a 1 hora de voo do Rio - mais perto do HQ da Petrobras do que a maioria dos fornecedores de IA alemães está de qualquer cliente. Discovery Workshops com Petrobras, Vale ou BNDES rodam presencialmente no Rio, nas sedes em Botafogo ou Centro. Revisões de compliance com foco em CVM, ANP ou ANEEL são conduzidas junto ao jurídico em Rio - a proximidade da sede da CVM significa que esclarecimentos regulatórios, em vez de seis semanas de troca escrita, se resolvem em reunião no 25º andar da Avenida Rio Branco.

As fases técnicas de build correm distribuídas entre Hamburgo e São Paulo - stand-ups pela manhã no horário SP, Sprint Reviews conjuntas. Presença no Rio se organiza em 24 horas, inclusive em ativos Petrobras fora da cidade (Macaé, Bacia de Campos). Após o Go-Live, o escritório de SP é o ponto operacional com hotline de escalação em português e inglês - a comunicação com a matriz europeia (em caso de clientes internacionais) segue em alemão ou inglês em paralelo.

## Por que o Rio funciona como ponto de partida para Enterprise AI

O Rio é a única cidade brasileira onde quatro reguladores (CVM, ANP, ANEEL, representação ANPD) e quatro das dez maiores empresas do país ficam em um raio de 15 km. Quem constrói aqui um agent produtivo para reporte à CVM, compliance ANP ou monitoramento de rejeitos, leva o caso como blueprint para qualquer outro mercado de energia e commodities da América Latina - de Buenos Aires a Lima e Bogotá. Os clusters - BNDES Inovação, Rio+, corredor tech do Porto Maravilha - fazem a ponte com a academia (PUC-Rio, UFRJ). Diferencial do Rio: a concentração de listadas com investidores ESG globais significa que as exigências de explicabilidade algorítmica são mais densas aqui do que em qualquer outro lugar da América Latina - o que eleva a barra, mas transforma cada agent bem sucedido em blueprint Cert-Ready para matrizes globais. A arquitetura Governance by Design da Gosign conecta com operações GDPR em Lisboa e com auditorias UE - um modelo que passa no Rio passa em Frankfurt. Veja também [São Paulo](/br/agentes-ia-sao-paulo/) e [Brasil em visão geral](/br/agentes-ia-brasil/).

--- Agentes IA para Empresas em São Paulo | Gosign ---
> Enterprise AI Agents em São Paulo. Gestão de projetos local, LGPD-compliant, compatível com CLT e acordos coletivos. Do PoC à operação independente.

## São Paulo é a única metrópole da América Latina onde um fornecedor europeu de IA precisa estar fisicamente presente para entrar nos grandes contratos

Quem quer ganhar Itaú Unibanco, Bradesco, Santander Brasil, Natura &Co ou Ambev como cliente não consegue fazer isso a partir de Hamburgo. A Avenida Paulista, a Faria Lima e os Pinheiros são microcosmos regulatórios próprios, com processos de compliance próprios, culturas próprias de proteção de dados e expectativas próprias sobre a proximidade do fornecedor. Isso vale para os clusters bancários ao redor do Cubo Itaú tanto quanto para o universo de bens de consumo de JBS, BTG Pactual e XP Inc. Por isso a Gosign mantém escritório próprio em São Paulo - com gerentes de projeto locais que sentam-se diretamente nas discussões com Compliance Officers, Encarregados de Dados (DPO) e representantes do sindicato.

## As três barreiras regulatórias para IA no mercado de São Paulo

A primeira é a **LGPD (Lei Geral de Proteção de Dados, Lei 13.709/2018)**, fiscalizada pela ANPD (Autoridade Nacional de Proteção de Dados, sediada em Brasília mas com forte presença operacional em SP). Ela exige base legal, finalidade clara e Encarregado (DPO) - mas não é idêntica ao GDPR europeu. Quem trabalha em Pinheiros com dados pessoais precisa observar especificamente os artigos 7 e 11 da LGPD (dados sensíveis, dados de saúde e financeiros) - inclusive Audit Trail completo. (PT: para operações em Portugal o equivalente é o RGPD fiscalizado pela CNPD.)

A segunda é a **Resolução BACEN 4893** que define os requisitos de ciber-resiliência para instituições financeiras reguladas e funciona, na prática, como o equivalente brasileiro do DORA europeu. Itaú, Bradesco, Banco do Brasil, Santander Brasil e as fintechs (Nubank, Stone, PagSeguro, XP Inc.) precisam documentar cada intervenção algorítmica em decisões de crédito, scoring de fraude ou prevenção à lavagem - não apenas no momento da auditoria, mas em produção, ao vivo. Adicionam-se as exigências da CVM para empresas de capital aberto e da SUSEP para o setor segurador.

A terceira é o **PL 2338/2023**, projeto de lei brasileiro sobre IA atualmente em tramitação no Congresso, vagamente inspirado no EU AI Act mas distinto em vários pontos. Em 2026 ele ainda não está em vigor, mas é esperado para os próximos dois anos. Quem constrói hoje precisa desenhar a arquitetura de modo que classificação de alto risco, supervisão humana e obrigações de transparência possam ser ativadas posteriormente. Cert-Ready by Design em vez de Cert-Retrofit. Importante: o EU AI Act NÃO se aplica diretamente ao Brasil - apenas filiais de grupos europeus que processam dados de cidadãos da UE precisam observá-lo.

## Cenários típicos de implementação em São Paulo

**KYC bancário e screening AML em Itaú/Bradesco/Santander Brasil**: Document Agents leem CPF, CNPJ, comprovante de residência e listas externas de sanções. O Decision Layer marca acertos de alto risco (PEPs, sanções) e os encaminha ao Compliance Officer com justificativa, score de confiança e Audit Trail completo. Auditorias do BACEN e do Coaf deixam de ser projetos de uma semana e viram clique de botão.

**Compliance de cadeia de suprimentos na Natura &Co e na JBS**: Workflow Agents monitoram certificados de fornecedores (FSC, Rainforest Alliance, GRSB para carne bovina), cruzam-nos com listas do IBAMA e alertam sobre irregularidades. Em JBS e Marfrig a pergunta "esta fazenda fornece de área de desmatamento?" é hoje tão crítica para a sobrevivência quanto o reporting ESG é para a Natura.

**Compliance de investimentos na XP Inc. e BTG Pactual**: Document Agents verificam contratos de investimento, perfis de risco e obrigações de informe à CVM. O Decision Layer escala automaticamente para Compliance qualquer violação dos requisitos de Suitability - com Human-in-the-Loop em cada passo regulatoriamente relevante. Em bancos de investimento, a profundidade de auditoria por trade não é um "nice to have", é pré-condição para qualquer processo na CVM.

**Detecção de fraude em Nubank, Stone e PagSeguro**: O Brasil tem a maior adoção do Pix do mundo (mais de 90% da população), e com isso uma paisagem própria de fraude. Workflow Agents monitoram padrões de transação em tempo real, comparam com perfis comportamentais e escalam ocorrências suspeitas ao time de Anti-Fraud com score de confiança e dossiê de justificativa. O Audit Trail atende tanto às obrigações de comunicação ao Coaf quanto aos padrões de segurança do BACEN.

## Como a Gosign atende São Paulo a partir do escritório local

Mantemos escritório em São Paulo com gerentes de projeto locais - não é um "sales office", é presença operacional real. Concretamente: os Discovery Workshops acontecem presencialmente, não em Zoom de Europa. As revisões de compliance com seu DPO e o jurídico acontecem pessoalmente em Faria Lima ou Pinheiros. As consultas ao sindicato ou à CRE (Comissão de Representantes dos Empregados; PT: Comissão de Trabalhadores), quando os HR Agents tomam decisões com efeito trabalhista, são conduzidas em conjunto com seus advogados trabalhistas.

A implementação técnica acontece remotamente entre nossos times em Hamburgo e São Paulo - 4 horas de fuso, stand-ups conjuntos no início da manhã hora SP. Após o Go-Live o escritório de SP segue como ponto operacional, incluindo hotline de escalação em português brasileiro e interlocutores que conhecem CLT, acordos coletivos (CCT/ACT) e a realidade de auditorias trabalhistas - não apenas pelo PDF traduzido. A pergunta que dirigentes de compliance brasileiros fazem primeiro não é "vocês conseguem tecnicamente?", é "vocês estarão aqui quando a ANPD ou o auditor ligar?". A resposta honesta é sim, porque nossos gerentes de projeto moram, trabalham e vivem em São Paulo. O eixo lusófono São Paulo - Lisboa permite ainda atender grupos brasileiros com operações em Portugal de forma coordenada, com mesma equipe e mesma arquitetura de [Decision Layer](/br/decision-layer/).

## Por que São Paulo funciona como ponto de partida para Enterprise AI

São Paulo é o único ponto da América Latina onde compliance bancário, cadeias de suprimentos de bens de consumo, inovação fintech e operações industriais convivem em uma só cidade. Quem aqui constrói um agente produtivo de KYC, AML ou ESG, em 18 meses tem o blueprint pronto para Cidade do México, Bogotá, Santiago ou Buenos Aires. Os clusters - Cubo Itaú, ACE Startups, o corredor de tecnologia Pinheiros - Vila Olímpia - garantem acesso a talento, investidores e programas piloto regulatórios. A arquitetura Governance by Design da Gosign conecta isso à profundidade de auditoria europeia: um modelo que funciona em São Paulo com LGPD e BACEN é compatível com operações sob LGPD/RGPD em Lisboa, Madri ou Hamburgo. Mais no [panorama Brasil](/br/agentes-ia-brasil/) ou em [serviços AI Agents](/br/servicos/ai-agents/).

--- Agentes IA para Empresas em Stuttgart | Gosign ---
> Enterprise AI Agents para Stuttgart e Baden-Württemberg. Document Agents para faturas, Workflow Agents para compras. Auditável, LGPD-compliant.

## Stuttgart é o único mercado europeu em que OEM de grande porte e Hidden Champion de médio porte precisam atender, na mesma cadeia de suprimentos, às mesmas obrigações de compliance

No corredor entre Untertürkheim, Zuffenhausen e Sindelfingen estão Mercedes-Benz e Porsche com suas plantas-mãe. Em Gerlingen reside Bosch como o maior fornecedor automotivo do mundo. A Daimler Truck dirige de Leinfelden-Echterdingen a divisão global de caminhões. Somam-se Dürr em Bietigheim, Trumpf em Ditzingen, Festo em Esslingen, Stihl em Waiblingen, Mahle e Kärcher - a lista de Hidden Champions vai bem além dos limites da cidade. O local não se define apenas pelas montadoras, mas pela cadeia entre fabricante, fornecedor Tier 1 e médias empresas especializadas. Quem aqui introduz um componente de IA precisa documentá-lo simultaneamente em vários níveis de uma cadeia ASPICE e ISO 26262 - o padrão de fornecedor da Mercedes obriga cada fornecedor às mesmas comprovações de modelo auditáveis. Esse encaixe torna o mercado de Stuttgart um dos ambientes de compliance mais duros da Europa: cada fornecedor é automaticamente forçado, pelas exigências do seu OEM, a uma governance de modelo rigorosa, queira ou não.

## As três barreiras regulatórias que definem toda iniciativa de IA no mercado de Stuttgart

A primeira é a Type Approval automotiva. O KBA em Flensburg concede aprovações, mas os padrões técnicos vêm da UN/ECE em Genebra - sobretudo a UN R155 sobre Cybersecurity Management e a UN R156 sobre Software Updates. Quem usa um componente de IA em um veículo ou em um processo de produção que influencia o software do veículo precisa de prova ininterrupta de governance de modelo, proveniência de dados de treino e builds reproduzíveis. A segunda barreira é o Cyber Resilience Act para os equipamentos industriais dos Hidden Champions - Trumpf, Dürr, Festo e Stihl entregam máquinas com componentes digitais para mercados regulados e precisam comprovar gestão de vulnerabilidades e atualizações de modelo.

A terceira é a forte cogestão nas plantas marcadas pela IG Metall: uma aplicação de IA com dados pessoais ou medição de desempenho só passa pelos conselhos de empresa de Mercedes, Bosch ou Porsche se o [Decision Layer](/br/decision-layer/) impuser arquitetonicamente a decisão final humana. Para o leitor brasileiro: o equivalente seria uma combinação de exigências da CNT (Confederação Nacional dos Trabalhadores na Indústria) com auditorias de qualidade automotiva mais rígidas que as da AAB. Mais sobre o quadro regulatório em [Governance EU AI Act](/br/governance/eu-ai-act/).

## Cenários típicos de implementação em Stuttgart

Em Bosch e em fornecedores Tier 1 comparáveis vemos agentes de dados de qualidade que consolidam dados de produção e teste de várias plantas e escalam anomalias a um Quality Engineer - com avaliação rastreável e referência aos dados de medição subjacentes. Na Daimler Truck um Compliance Agent ajuda na documentação de frota, por exemplo na preparação de documentos de homologação para diferentes jurisdições. No entorno da Porsche Financial Services agentes apoiam a preparação de decisões de bonidade para clientes de leasing - o despachante decide, o agente enriquece com documentos, histórico de crédito ao consumo e checks de plausibilidade.

Em Dürr, Festo e Trumpf vemos Service Ticket Agents que classificam tickets de cliente, enriquecem com dados de máquina e entregam ao técnico de serviço com proposta. Mahle e Mahle Behr trabalham em HR Document Agents para pré-qualificação de candidatos - com Audit Trail claro, porque o recrutamento está sob o AGG e classificado como alto risco no EU AI Act. Em Stihl e Kärcher, médias empresas familiares, vemos Document Agents em compras e análise de contratos, porque a auditoria interna dessas casas espera uma lógica de auditoria enxuta mas sem lacunas. A sede da Mercedes-Benz em Untertürkheim trabalha no dia a dia com workflow ASPICE estrito, em que componentes de IA só entram em cadeias produtivas se a proveniência do modelo e o conjunto de treino estiverem documentados e versionados.

## Como a Gosign atende Stuttgart a partir de Hamburgo

A Gosign não tem escritório em Stuttgart - o acompanhamento presencial roda remotamente desde Hamburgo e Berlim. A vantagem: pelo ICE direto chegamos a Untertürkheim em menos de seis horas, voo direto Hamburgo-Stuttgart leva cerca de uma hora mais translado. Concretamente: Discovery Workshops com Engineering, Compliance e conselho de empresa fazemos como blocos presenciais de dois ou três dias. A fase de Engineering é organizada remotamente com dois slots fixos por semana no calendário do cliente e dias presenciais definidos para revisões de arquitetura e reuniões críticas com stakeholders.

Validação de modelo com auditoria interna, preparação de auditoria ASPICE e negociações de cogestão acontecem sem exceção presencialmente. O mercado suábio aceita trabalho remoto pragmaticamente, desde que a entrega seja confiável, a frequência presencial nos pontos-chave esteja presente e a validação de modelo permaneça documentadamente rastreável. Clusters como ARENA2036 como campus de pesquisa para a mobilidade do futuro no terreno da Universidade de Stuttgart e o Cyber Valley Tübingen-Stuttgart como maior centro europeu de pesquisa em ML usamos para discussões técnicas e contato com especialistas universitários em validação de modelo. Para grupos brasileiros do setor automotivo com presença na Alemanha (Embraer, Iveco, Marcopolo, Volkswagen do Brasil), coordenamos a partir do [escritório em São Paulo](/br/agentes-ia-sao-paulo/) com a equipe de Hamburgo.

## Por que Stuttgart funciona como ponto de partida para Enterprise AI

Quem coloca um AI Agent em produção em ambiente OEM ou Tier 1 de Stuttgart, defendeu-o simultaneamente contra ASPICE, ISO 26262, Cyber Resilience Act, um conselho de empresa experiente em IG Metall e a auditoria interna. A mesma arquitetura encaixa depois em qualquer outro setor orientado a produção na Europa, porque a disciplina de cadeia de suprimentos de Stuttgart define o padrão europeu mais alto para proveniência de modelo e Audit Trail. Soma-se o pool de talentos ML e Engineering ao redor da Universidade de Stuttgart com seu forte perfil de engenharia mecânica e informática, o KIT em Karlsruhe como maior universidade técnica alemã, a Hochschule Esslingen com sua especialização automotiva e os clusters de ML de Tübingen com o Instituto Max Planck para Sistemas Inteligentes. As médias empresas em Baden-Württemberg são também mercado para arquitetura de IA escalada - os cerca de 1.500 Hidden Champions do estado mostram que não são apenas as DAX que precisam de IA como fator de produção. Quem em 4-6 semanas tem um primeiro agente em produção em um Tier 1, tem um setup de referência que o mercado entende. Mais sobre o procedimento em [serviços AI Agents](/br/servicos/ai-agents/).

--- Agentes IA para Empresas em Valência | Gosign ---
> Enterprise AI Agents para Valência. Hub tech do Mediterrâneo. EU AI Act compliant, LGPD-compliant. Gestão a partir de Barcelona.

## Valência é a terceira economia da Espanha - marcada por logística de alimentos, automotivo e comércio mediterrâneo

Quem constrói Enterprise AI em Valência constrói para uma cidade onde o tom não é dado por bancos ou big techs, mas por cadeias de suprimento, planejamento de produção e logística. A Mercadona é, com mais de 1700 lojas, a maior rede de supermercados da Espanha e opera a partir da matriz em Tavernes Blanques uma das cadeias de marca própria mais densas da Europa. A Ford Valencia produz em Almussafes desde os anos 1970 - a planta está entre as maiores da Ford na Europa. Porcelanosa (cerâmica), Lladró (porcelana) e Consum (rede cooperativista de supermercados) são outros pesos industriais. A Air Nostrum opera a aviação regional ibérica, a BP mantém em Castellón uma das maiores refinarias da Espanha, e a Iberdrola Energía coordena da região de Valência parte significativa da geração solar espanhola. Nos últimos anos a cidade também se posicionou como ponto tech com a Marina Valencia e o programa Lanzadera (financiado pelo fundador da Mercadona, Juan Roig). Contexto relevante para grupos brasileiros de agribusiness e de manufatura com operações ibéricas.

## As três barreiras regulatórias para IA no mercado valenciano

A primeira é a **AEPD em conjunto com a LOPDGDD** para qualquer processamento com dado pessoal. A AEPD é especialmente rigorosa com empresas de logística e varejo, porque processam volumes enormes de dado de cliente e de empregado. A Mercadona, por exemplo, movimenta diariamente dado de milhões de clientes e mais de 100.000 colaboradores - toda escala apoiada por IA precisa ser justificável sob o Art. 22 do GDPR.

A segunda é a **AESIA e o EU AI Act, diretamente aplicável na Espanha**. Sistemas de alto risco - especialmente em gestão de pessoal, otimização de cadeia e geração de energia - serão auditados sistematicamente a partir de 2026. Quem constrói em Valência pipeline de IA para Workforce Management constrói em categoria de alto risco e precisa documentar desde o dia 1 para auditoria AESIA. Para brasileiros o análogo em formação é o PL 2338/2023.

A terceira é o conjunto **CNMV + Banco de España** para as cadeias de financiamento entre indústria e bancos. Embora Valência não seja o polo bancário espanhol, os grandes industriais operam com estruturas complexas de Working Capital. Previsões de cashflow apoiadas em IA, modelos de risco de crédito e estratégias de hedging ficam sob supervisão dos dois. [EU AI Act Governance](/br/governance/eu-ai-act/) encontra supervisão financeira.

## Cenários típicos de implementação em Valência

**Otimização de cadeia na Mercadona**: a Mercadona otimiza cadeias entre centenas de fornecedores, vários centros logísticos e mais de 1700 lojas - cada recomendação de pedido apoiada por IA afeta diretamente desperdício, frescor e margem. Os modelos precisam permanecer rastreáveis porque remuneração de fornecedor e empregado depende das recomendações. Document e Workflow Agents preservam lineage; o Decision Layer escala ao planejador humano.

**Planejamento de produção na Ford Valencia**: a Ford planeja em Almussafes a produção de várias linhas com cadeias complexas em toda a península - modelos de planejamento de capacidade precisam resistir a auditorias de grupo. Document Agents preparam dossiês técnicos.

**Controle de qualidade na Porcelanosa**: computer vision para QA na cerâmica - cada decisão automática de refugo precisa ser documentável diante de grandes clientes e fornecedores. Workflow Agents classificam anomalia; Decision Layer escala para revisão.

**Monitoramento solar na Iberdrola Energía**: monitoramento em parques fotovoltaicos em Valência e Castilla-La Mancha - detecção de anomalia de performance nos módulos precisa ficar em Audit Trail verificável por proprietário e seguradora.

Em todos os cenários o [Decision Layer](/br/decision-layer/) entrega a arquitetura que une Audit Trail, escalação e Cert-Ready by Design. Uma especificidade valenciana é o Porto de Valência - maior porto de contêineres do Mediterrâneo e nó estratégico do comércio Europa-Ásia. Quem aqui constrói IA para documentação de carga, despacho aduaneiro e otimização logística opera sob o regime adicional da Agencia Tributaria e da Aduanas. O Audit Trail precisa ser não apenas GDPR-compliant, mas aduaneiro-rastreável - frequentemente entre várias línguas e jurisdições.

## Como a Gosign atende Valência a partir de Barcelona

A Gosign atende projetos em Valência a partir do escritório de Barcelona (gosign.es) com gerentes de projeto e engenheiros falantes de espanhol. A conexão AVE Barcelona-Valência leva cerca de três horas e meia; de carro, dependendo do trânsito, parecido - presenças mensais em Mercadona (Tavernes Blanques), Ford Valencia (Almussafes), Porcelanosa e Marina Valencia são parte padrão do projeto. Discovery roda presencialmente com responsáveis técnicos, compliance e Comité de Empresa à mesma mesa. Quando necessário, incorporamos stakeholders em valenciano.

Os clusters industriais locais - agri-food em torno de Mercadona e Consum, automotive em torno de Ford e fornecedores, cerâmica em Castellón - exigem entendimento setorial que o time espanhol traz de anos de trabalho com médias empresas ibéricas. A sede em Hamburgo entrega revisões arquiteturais e integração com padrões alemães de compliance industrial; delivery, contato direto com cliente e cultura de negociação familiar valenciana ficam no time de Barcelona. Para grupos brasileiros com operações ibéricas o eixo São Paulo - Barcelona - Valência entrega mesma arquitetura, LGPD e RGPD + LOPDGDD em paralelo.

## Por que Valência funciona como ponto de partida para Enterprise AI

Valência é o mercado ideal para validar IA industrial com compliance pleno, sem a fricção regulatória e estrutura de custos de Madri. Quem aqui entrega um piloto Cert-Ready by Design tem um caso que passou em padrões AEPD, AESIA e EU AI Act - depois defensável em Madri, Barcelona e para além dos Pirineus. A Marina Valencia, o programa Lanzadera e a Universitat Politècnica de València entregam talento, parceiros piloto e conexão com pesquisa. Trazemos do cinturão industrial alemão a experiência de operar IA em cadeias complexas e sistemas de produção - com Governance by Design, Audit Trail e Human-in-the-Loop. Valência é o mercado certo para escalar essa disciplina na península ibérica. Quem começa aqui leva blueprint para qualquer região industrial europeia de perfil semelhante - do Ruhr à Lombardia passando pelo País Basco. Mais em [Espanha](/br/agentes-ia-espanha/) ou em [serviços AI Agents](/br/servicos/ai-agents/).

--- Agentes IA para Empresas em Varsóvia | Gosign ---
> Enterprise AI Agents para Varsóvia. EU AI Act aplicável, LGPD-compliant, auditável. Agentes IA para o centro corporativo da Polônia.

## Varsóvia é a capital corporativa da Polônia com a maior concentração de reguladores da Europa Central e Oriental

Em Varsóvia ficam as sedes de PKO BP, PZU, Orlen, PGE, Santander Bank Polska, mBank, Allegro, CD Projekt RED e LPP - líderes setoriais poloneses com centenas de milhares de clientes, empregados e operações diárias. Ao mesmo tempo, Varsóvia é sede das principais autoridades do país: UODO, KNF, NBP e ZUS trabalham em raio de poucos quilômetros uns dos outros. Essa proximidade entre big corporates e reguladores cria uma densidade de supervisão que não existe em nenhuma outra cidade polonesa. Sistemas de IA que entram em produção nas matrizes varsovianas não precisam apenas funcionar - precisam resistir a uma fiscalização que fica geograficamente a uma estação de metrô. Contexto relevante para grupos brasileiros que atendem cadeias corporativas polonesas ou que consomem serviços financeiros no eixo.

## As três barreiras regulatórias para IA no mercado de Varsóvia

A primeira é a **supervisão da KNF sobre o setor financeiro polonês**: PKO BP, mBank, Pekao, Santander Bank Polska e PZU estão sob supervisão direta da Komisja Nadzoru Finansowego. Em AML, KYC, credit scoring e manejo de sinistros, a KNF exige bases de modelo documentadas, Audit Trail completo e última decisão humana comprovável em casos de risco. Nos últimos anos a KNF precisou suas expectativas sobre decisão automatizada - banco em Varsóvia que use IA sem documentação robusta arrisca não só observação, arrisca intervenção operacional.

A segunda é o **KSeF, sistema polonês de faturação eletrônica**. O KSeF virou progressivamente obrigatório para todas as empresas. Grupos como Orlen, Allegro, LPP e PGE precisam extrair, validar e arquivar centenas de milhares de notas diárias em conformidade KSeF. IA que processa dado fiscal precisa atender os requisitos estruturais do KSeF e, em caso de conflito, tornar rastreável por que um lançamento foi feito como foi - caso clássico para Document Agents com Human-in-the-Loop obrigatório em desvio.

A terceira é o **UODO e as especificidades da lei polonesa de proteção de dados**. O UODO fica em Varsóvia e audita grupos poloneses com atenção especial a profiling automatizado no sentido do Art. 22 GDPR. Nos sistemas de recomendação do Allegro, na classificação de sinistro do PZU ou no scoring de crédito do PKO BP, o UODO exige capacidade de resposta clara e justificativas rastreáveis - cada titular precisa saber por que a decisão foi tomada, e KNF e UODO precisam conseguir auditar. Importante para brasileiros: o EU AI Act aplica-se diretamente na Polônia; no Brasil o equivalente em formação é o PL 2338/2023.

## Cenários típicos de implementação em Varsóvia

**AML e KYC no PKO BP**: o maior banco da Polônia processa milhões de transações por dia. Document Agents extraem dados de identificação, Workflow Agents roteiam casos suspeitos pelas faixas da KNF, e o Decision Layer registra cada escalação para o comitê interno de AML e auditores externos.

**Fraud Detection no Allegro**: o maior marketplace da Polônia concorre com a Amazon. Em milhões de pedidos por dia, Decision Agents checam padrões de risco em tempo real - sempre com possibilidade de rastrear decisões individuais para auditoria UODO.

**Regulação de sinistros no PZU**: o líder polonês de seguros processa milhares de sinistros por dia. Workflow Agents classificam entradas por tarifa, região e complexidade, com revisão humana obrigatória em ultrapassagem de faixa - exigência explícita da KNF.

**Extração KSeF em Orlen e PGE**: os dois grupos estão sob pressão KSeF. Document Agents extraem dados estruturados de nota, validam contra o esquema KSeF e roteiam desvios à contabilidade.

Em todos os cenários o [Decision Layer](/br/decision-layer/) entrega Audit Trail em profundidade, Governance by Design e escalação Human-in-the-Loop.

## Como a Gosign atende Varsóvia a partir de Cracóvia

A Gosign atende projetos em Varsóvia a partir do escritório de Cracóvia (gosign.pl) com gerentes de projeto e engenheiros falantes de polonês. A distância Cracóvia-Varsóvia é coberta pelo Express Intercity Premium em pouco menos de três horas; de carro, conforme trânsito, parecido - presença regular no Warsaw Spire Tech, no Rondo Daszyńskiego ou diretamente nas sedes de PKO BP, Allegro, Orlen, PZU e mBank é padrão, não exceção. Discovery roda presencialmente com responsáveis técnicos, compliance e um representante da Rada Zakładowa à mesma mesa.

Build e Sprint Reviews seguem com o time em polonês ou inglês, com steerings mensais presenciais em Varsóvia e viagem curta em caso de escalação com UODO ou KNF. A sede em Hamburgo assume questões arquiteturais de fundo e integração a matrizes alemãs e suíças - delivery, dia a dia e contato com cliente ficam no time de Cracóvia, em pé de igualdade com os stakeholders varsovianos. Para clientes brasileiros com operações polonesas o eixo São Paulo - Cracóvia - Varsóvia entrega mesma arquitetura.

## Por que Varsóvia funciona como ponto de partida para Enterprise AI

Varsóvia é o único mercado da Europa Central e Oriental onde as três condições para uma implantação Enterprise AI bem sucedida convivem: máxima densidade corporativa, máxima densidade regulatória e um ecossistema tech com Google for Startups Warsaw, Campus Warsaw e o cluster Warsaw Spire Tech. Quem coloca em produção um agent para banco varsoviano, seguradora varsoviana ou e-commerce varsoviano, passou pelo stress-test regulatório mais duro da região. Escalar para outros sites poloneses - [Cracóvia](/br/agentes-ia-cracovia/), [Wrocław](/br/agentes-ia-wroclaw/), [Gdańsk](/br/agentes-ia-gdansk/) - deixa de ser segundo build, vira mudança de configuração.

Acresce-se um aspecto que torna Varsóvia especialmente atraente para matrizes alemãs, suíças e holandesas: os grupos varsovianos estão habituados há anos aos padrões de compliance oeste-europeus. O PKO BP trabalha com correspondentes alemães, o mBank pertence há décadas ao grupo Commerzbank, o Santander Bank Polska é parte da estrutura Santander. Esses grupos sabem o que significa uma expectativa BaFin, FINMA ou DNB sobre IA, e seus compliance internos são desenhados para isso. Uma implementação de Decision Layer em Varsóvia raramente encontra resistência ao requisito de auditabilidade por decisão - isso é realidade operacional há anos. Governance by Design aqui não é frase de venda, é condição de entrada. Quem passa em Varsóvia passa no resto da Polônia e na maioria dos mercados da UE. Mais em [EU AI Act](/br/governance/eu-ai-act/) no Governance.

--- Agentes IA para Empresas em Wrocław | Gosign ---
> Enterprise AI Agents para Wrocław. Hub de TI e nearshoring na Polônia. EU AI Act compliant, LGPD-compliant. Gestão a partir de Cracóvia.

## Wrocław é o híbrido indústria-TI da Polônia - onde fornecedores automotivos encontram operações bancárias

Em Wrocław operam Bosch Wrocław, LG Electronics, 3M, Volvo Wrocław, Whirlpool e Toyota Motor Manufacturing Poland com plantas e funções de engenharia, cada uma com milhares de empregados. Em paralelo ficam UBS Wrocław (originada do centro Credit Suisse), HP, Nokia Wrocław e vários shared services bancários. Essa mistura é única na Polônia: uma cidade onde, na mesma hora, se trabalha em documentação de engenharia para uma planta automotiva e em research reports para um banco de investimento suíço. O Wrocław Technology Park e o Capital Park compõem o cluster físico; a Politechnika Wrocławska entrega engenheiros para os dois mundos. Quem constrói Enterprise AI em Wrocław precisa atender duas lógicas industriais ao mesmo tempo - contexto relevante para grupos brasileiros que usam Wrocław como hub de nearshoring ou que têm fornecedores em cadeias automotivas alemãs.

## As três barreiras regulatórias para IA no mercado de Wrocław

A primeira é o **UODO e o RODO em contexto multi-entidade**. Sites de Wrocław processam frequentemente dados de suas matrizes oeste-europeias. Uma operação UBS em Wrocław está sob exigências FINMA, ESMA e UODO simultaneamente. Uma função de engenharia Bosch em Wrocław produz documentação de produto que vai para Stuttgart, Xangai e Detroit. A lei polonesa de proteção de dados exige que profiling e decisão automatizada permaneçam rastreáveis - mesmo quando os modelos são treinados na matriz alemã ou suíça. Arquiteturas de IA sem Audit Trail contínuo são aqui inimplementáveis.

A segunda é a **supervisão da KNF sobre a função de outsourcing bancário em expansão**. UBS, várias operações midmarket de investimento e provedores de credit servicing trabalham em Wrocław sob o teto regulatório da Komisja Nadzoru Finansowego e, adicionalmente, dos reguladores domésticos. Em research tools, classificação automática de documento e compliance screening, a KNF exige que cada decisão de modelo se origine em um responsável humano identificável - incluindo a versão de dado subjacente no momento da decisão.

A terceira é o **EU AI Act com foco em alto risco em RH e indústria**. Sites de produção em Wrocław usam cada vez mais IA para QA, predictive maintenance e escala de turno. Algoritmos de escala caem no Annex III (alto risco, RH-relevante), QA por visão computacional toca responsabilidade pelo produto e conformidade CE. O NBP e o UODO exigem em ambos documentação completa de conformidade. Cert-Ready by Design em produção wrocławiana não é argumento de venda, é pré-condição para auditoria pela matriz e pelos seus certificadores. Importante: o EU AI Act aplica-se diretamente na Polônia; no Brasil o análogo em formação é o PL 2338/2023.

## Cenários típicos de implementação em Wrocław

**QA na LG Electronics**: a planta da LG em Wrocław produz componentes de display em alta escala. Decision Agents baseados em visão verificam defeitos em tempo real, com escalação humana obrigatória em casos fronteiriços. Cada decisão vai para o Audit Trail com versão de modelo, dataset de treino e ID de reviewer.

**Research Operations na UBS Wrocław**: a antiga operação Credit Suisse, agora parte da UBS, opera uma das maiores funções de research fora de Zurique. Document Agents extraem dados essenciais de relatórios anuais, classificam earnings calls e roteiam afirmações compliance-relevantes a analistas humanos - cada passo registrado para auditoria FINMA e KNF.

**Roteamento de service desk na HP**: o centro da HP em Wrocław atende clientes em várias línguas e fusos. Workflow Agents classificam tickets por idioma, tenant e nível de escalação. O Decision Layer roteia automaticamente, com Human-in-the-Loop em clientes VIP e em tickets prestes a violar SLA.

**Documentação de produção na Bosch**: o site Bosch em Wrocław gera diariamente milhares de documentos técnicos. Document Agents extraem especificações regulatoriamente relevantes, cruzam contra normas de cada país e roteiam conflitos automaticamente para a liderança de engenharia em Stuttgart ou Wrocław.

Em todos os cenários o [Decision Layer](/br/decision-layer/) entrega Audit Trail e Governance by Design.

## Como a Gosign atende Wrocław a partir de Cracóvia

A Gosign atende projetos em Wrocław a partir do escritório de Cracóvia (gosign.pl) com engenheiros e gerentes de projeto falantes de polonês. Cracóvia-Wrocław é cobrado em cerca de três horas por estrada ou trem - presenças regulares no Wrocław Technology Park, no Capital Park ou nas salas de engenharia de Bosch, LG Electronics, UBS Wrocław e HP são parte de cada fase de projeto, não exceção. Discovery roda dois dias presencial, com responsáveis técnicos, compliance e um representante da Rada Zakładowa à mesma mesa.

Depois, build e Sprint Reviews seguem com o time de Cracóvia, em polonês e inglês, com steerings mensais presenciais em Wrocław. Engenheiros poloneses entendem a dualidade wrocławiana - indústria tradicional e outsourcing bancário - por prática própria, e adaptam documentação, idioma de workshop e caminhos de escalação sem tradução cultural. A sede em Hamburgo assume revisões arquiteturais e integração com matrizes alemãs e suíças em Stuttgart, Munique ou Zurique. Para clientes brasileiros com operações em Wrocław o eixo São Paulo - Cracóvia - Wrocław entrega mesma arquitetura cobrindo LGPD e RODO em paralelo.

## Por que Wrocław funciona como ponto de partida para Enterprise AI

Wrocław é o mercado de Enterprise AI mais atípico da Polônia, porque aqui dois mundos colidem: indústria tradicional e outsourcing bancário. Quem constrói um agent que funciona simultaneamente em planta Bosch e em operação UBS, desenhou arquitetura a apenas uma mudança de configuração de qualquer outro site polonês. A Politechnika Wrocławska entrega engenheiros que entendem essa dualidade, e o ecossistema tech de Wrocław é, depois de [Cracóvia](/br/agentes-ia-cracovia/), o segundo maior do país.

Para médios DACH com subsidiárias polonesas, Wrocław é frequentemente o primeiro site onde IA produtiva é efetivamente necessária - uma implementação bem sucedida vira blueprint de escala. Soma-se a proximidade geográfica com a Alemanha: o trem Berlim-Wrocław leva cerca de quatro horas; presença em um dia útil. Essa combinação de acessibilidade ocidental, custo centro-europeu de talento e regulação UE estrita transforma Wrocław em site que nenhum portfólio de grupo alemão deveria ignorar. Governance by Design aqui não é frase de marketing, é condição de aceitação pela matriz - e é exatamente o que um Decision Layer bem implementado atende desde o primeiro dia. Mais sobre o trabalho na Polônia no [panorama Polônia](/br/agentes-ia-polonia/).

--- Agentes IA para Empresas em Zurique | Gosign ---
> Enterprise AI Agents para Zurique. Swiss FADP e LGPD-compliant, auditável, FINMA-aware. IA para o centro financeiro suíço.

## Zurique é o único centro financeiro europeu em que arquitetura de IA precisa ser planejada SEM o EU AI Act - e exatamente isso é a vantagem estratégica

A Suíça não está na UE. Quem entende Zurique como mercado começa com esse fato: o EU AI Act não vale aqui diretamente, o GDPR não é o direito de proteção de dados aplicável, e a BaFin não tem competência. Em vez disso, vale o nFADP, a Lei Suíça de Proteção de Dados revisada desde setembro de 2023, e a FINMA como autoridade federal de supervisão de mercados financeiros. No quartel do Paradeplatz sentam UBS - depois da incorporação do Credit Suisse em 2023, de longe o maior banco suíço - bem como Zurich Insurance Group e Swiss Re como dois dos maiores resseguradores do mundo. ABB tem sede em Oerlikon, Sika em Baar, Holcim em Jona. Google opera em Zurique um dos seus maiores Engineering Centers fora dos EUA. Essa mistura cria um mercado de IA com alta maturidade técnica e um quadro regulatório construído de forma mais pragmática e setorial do que a regulação da UE.

## As três barreiras regulatórias que moldam toda iniciativa de IA no mercado de Zurique

A primeira é a FINMA como supervisão financeira. Em 2024 ela concretizou suas expectativas sobre governance de modelos de IA em bancos e seguradoras em um documento próprio - com requisitos claros sobre risco de modelo, explicabilidade e auditabilidade. UBS, Zurich Insurance, Swiss Re e os bancos privados aqui sediados precisam validar cada componente de IA em gestão de risco, underwriting ou wealth management contra essas expectativas FINMA. (Para o leitor brasileiro: papel funcionalmente comparável ao do BACEN sob a Resolução 4893, mas com mais ênfase em explicabilidade de modelo e menos em ciber-resiliência operacional.)

A segunda barreira é o EDÖB como Comissário Federal de Proteção de Dados e Transparência e o nFADP - a nova Lei de Proteção de Dados desde 2023. Ela é essencialmente compatível com a LGPD e com o GDPR, mas tem obrigações próprias sobre Privacy by Design, profiling e decisões automatizadas que precisam ser comprovadas separadamente. NÃO é a LGPD - é a FADP suíça. A terceira barreira é o próprio discurso suíço de regulação de IA: o Conselho Federal decidiu em 2024 que a Suíça não criará uma própria lei de IA abrangente, mas regulará setorialmente - o que significa que FINMA, Swissmedic e BAKOM formulam cada um requisitos próprios sobre IA em seus domínios. Quem planeja em Zurique precisa conhecer em detalhe a respectiva supervisão setorial. Mais contexto em [Governance EU AI Act](/br/governance/eu-ai-act/) - a lógica EU permanece para empresas suíças com negócios na UE como segundo vetor de compliance.

## Cenários típicos de implementação em Zurique

Em UBS e no entorno bancário suíço mais amplo vemos Wealth Management Reporting Agents que preparam comunicação estruturada com cliente e relatórios de performance - o consultor decide, o agente estrutura. Em Zurich Insurance agentes apoiam a regulação de sinistros em seguro patrimonial e de vida, com enriquecimento claro da comunicação do sinistro em torno de dados contratuais, laudos periciais e checks de plausibilidade - a decisão final é de um despachante com background de seguros. Em Swiss Re trata-se de modelagem de resseguro e CAT modelling, em que underwriters recebem os resultados como proposta e respondem pela aceitação final.

A ABB trabalha em Use Cases de Industrial Control System, em que operadores industriais tomam a decisão final. Google Zurich usa ferramentas próprias de Engineering e é menos relevante como mercado para arquitetura externa de agentes - mas o ambiente de talento técnico em Zurique é fortemente moldado por isso. Em Sika e Holcim vemos Document Agents para análise de contratos e fichas de segurança no ambiente de química de construção. Em todos os casos, o [Decision Layer](/br/decision-layer/) mantém a cadeia de justificativa como Audit Trail - em uma forma que satisfaz simultaneamente os requisitos FINMA e as obrigações nFADP.

## Como a Gosign atende Zurique a partir de Hamburgo

A Gosign não tem filial suíça. O mercado suíço aceita prestadores alemães sem subsidiária local, desde que o armazenamento de dados, o Engineering e a estrutura contratual estejam claramente regulamentados. Concretamente: trabalhamos como GmbH alemã com sede em Hamburgo, a estrutura contratual segue o direito suíço ou um modelo dual, o armazenamento de dados ocorre em infraestrutura cloud suíça (Swisscom, Exoscale) ou em um setup UE operado segundo padrões nFADP com as medidas de proteção correspondentes. Discovery Workshops fazemos presencialmente em Zurique - o voo direto Hamburgo-Zurique leva uma hora de voo, o ICE via Basel é uma alternativa razoável.

Na fase de Engineering trabalhamos remotamente com dias presenciais quinzenais e foco nos encontros de validação relevantes para FINMA. Importante é a separação explícita entre os conjuntos de regras para dados suíços e os conjuntos de regras para dados UE - o Decision Layer carrega ambas as lógicas em paralelo, porque muitos grupos suíços têm negócios na UE e precisam atender ambos os regimes simultaneamente. Clusters como o ETH AI Center, o Impact Hub Zürich e o Zurich Insurance Innovation usamos para troca técnica. Para grupos brasileiros com operações suíças (vários grupos farmacêuticos, financeiros e de commodities brasileiros mantêm holdings em Zurique), coordenamos a partir do [escritório em São Paulo](/br/agentes-ia-sao-paulo/) com a equipe de Hamburgo - especialmente útil para grupos que operam simultaneamente sob LGPD, FADP e GDPR.

## Por que Zurique funciona como ponto de partida para Enterprise AI

A Suíça tem uma vantagem estrutural que os mercados UE não têm: a regulação é setorial, pragmática e em regra menos formalista que o EU AI Act. Quem coloca em Zurique um primeiro AI Agent em ambiente regulado em produção, defendeu-o contra as expectativas FINMA, contra o nFADP e contra a exigência suíça de limpeza técnica. Essa arquitetura está depois preparada para uma escala no espaço UE, porque a governance de modelo subjacente já cumpre o padrão mais alto. Soma-se o ambiente técnico: a ETH Zürich é uma das principais instituições mundiais de pesquisa em ML, o ETH AI Center reúne cerca de 100 grupos de pesquisa, e Google Zurich, IBM Research Zurich e o ambiente CERN na Suíça ocidental fazem do mercado um dos locais técnicos mais maduros da Europa. Quem em 4-6 semanas tem um primeiro AI Agent em produção em uma corporação suíça, constrói sobre um mercado que premia arquitetura pragmática e evita burocracia desnecessária. Mais sobre o procedimento em [serviços AI Agents](/br/servicos/ai-agents/).

--- Aviso Legal - Gosign GmbH ---
> Aviso legal da Gosign GmbH, Hamburgo. Diretores, contato, registro comercial e informações jurídicas.

<h1>Aviso Legal</h1>

<h2>Aviso legal conforme § 5 DDG (Lei alemã de serviços digitais)</h2>
<p>
Gosign GmbH<br/>
Hallerstraße 8<br/>
20146 Hamburgo, Alemanha
</p>

<h2>Representada por</h2>

<div class="grid grid-cols-1 sm:grid-cols-2 gap-8 not-prose my-8">
<div class="flex items-start gap-4">
<img
src="/images/team/bert-gogolin.webp"
alt="Bert Gogolin, Diretor Geral da Gosign GmbH"
width="80"
height="80"
class="rounded-full w-20 h-20 object-cover flex-shrink-0"
loading="lazy"
/>
<div>
<p class="font-semibold text-gosign-dark text-body">Bert Gogolin</p>
<p class="text-small text-gosign-text-light">Diretor Geral</p>
<a
href="https://www.linkedin.com/in/bertgogolin/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center gap-1 text-small text-gosign-text-light hover:text-gosign-accent transition-colors mt-1"
aria-label="Bert Gogolin no LinkedIn"
>
<svg class="w-4 h-4" fill="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path d="M20.447 20.452h-3.554v-5.569c0-1.328-.027-3.037-1.852-3.037-1.853 0-2.136 1.445-2.136 2.939v5.667H9.351V9h3.414v1.561h.046c.477-.9 1.637-1.85 3.37-1.85 3.601 0 4.267 2.37 4.267 5.455v6.286zM5.337 7.433a2.062 2.062 0 01-2.063-2.065 2.064 2.064 0 112.063 2.065zm1.782 13.019H3.555V9h3.564v11.452zM22.225 0H1.771C.792 0 0 .774 0 1.729v20.542C0 23.227.792 24 1.771 24h20.451C23.2 24 24 23.227 24 22.271V1.729C24 .774 23.2 0 22.222 0h.003z"/>
</svg>
LinkedIn
</a>
</div>
</div>

<div class="flex items-start gap-4">
<img
src="/images/team/dieter-gogolin.webp"
alt="Dieter Gogolin, Diretor Geral da Gosign GmbH"
width="80"
height="80"
class="rounded-full w-20 h-20 object-cover flex-shrink-0"
loading="lazy"
/>
<div>
<p class="font-semibold text-gosign-dark text-body">Dieter Gogolin</p>
<p class="text-small text-gosign-text-light">Diretor Geral</p>
</div>
</div>
</div>

<h2>Contato</h2>
<p>
E-mail: web26 [at] gosign.de<br/>
Contato: Pelo nosso <a href="/br/contato/" class="text-gosign-accent-text hover:text-gosign-accent-hover">formulário de contato</a> ou <a href="/br/contato/#booking" class="text-gosign-accent-text hover:text-gosign-accent-hover">agendamento</a>
</p>

<h2>Registro comercial</h2>
<p>
Tribunal de registro: Tribunal Distrital de Hamburgo (Amtsgericht Hamburg)<br/>
Número de registro: HRB 112197
</p>

<h2>Número de identificação fiscal</h2>
<p>
Número de identificação fiscal conforme § 27a da Lei alemã do IVA (Umsatzsteuergesetz):<br/>
DE215891388
</p>

<h2>Responsável pelo conteúdo conforme § 18 par. 2 MStV</h2>
<p>
Gosign GmbH<br/>
Bert Gogolin<br/>
Hallerstraße 8<br/>
20146 Hamburgo, Alemanha
</p>

<h2>Responsabilidade pelo conteúdo</h2>
<p>
Como prestador de serviços, somos responsáveis pelos nossos próprios conteúdos nestas páginas de acordo com o § 7 par. 1 DDG e a legislação geral. Contudo, nos termos dos §§ 8 a 10 DDG, não somos obrigados a monitorar informações de terceiros transmitidas ou armazenadas, nem a investigar circunstâncias que indiquem atividade ilícita.
</p>
<p>
As obrigações de remover ou bloquear o uso de informações nos termos da legislação geral permanecem inalteradas. No entanto, a responsabilidade nesse sentido só é possível a partir do momento do conhecimento de uma violação específica do direito. Ao tomar conhecimento de tais violações, removeremos o conteúdo imediatamente.
</p>

<h2>Responsabilidade por links</h2>
<p>
Nosso site contém links para sites externos de terceiros, sobre cujo conteúdo não temos influência. Portanto, não podemos assumir nenhuma responsabilidade por esses conteúdos externos. O respectivo fornecedor ou operador das páginas vinculadas é sempre responsável pelos seus conteúdos. As páginas vinculadas foram verificadas quanto a possíveis violações legais no momento da vinculação. Conteúdos ilegais não eram identificáveis no momento da vinculação.
</p>
<p>
Um controle permanente do conteúdo das páginas vinculadas não é razoável sem indícios concretos de violação legal. Ao tomar conhecimento de violações legais, removeremos tais links imediatamente.
</p>

<h2>Direitos autorais</h2>
<p>
Os conteúdos e obras criados pelos operadores do site nestas páginas estão sujeitos à legislação alemã de direitos autorais. A reprodução, edição, distribuição e qualquer tipo de utilização fora dos limites do direito autoral requerem o consentimento escrito do respectivo autor ou criador. Downloads e cópias deste site são permitidos apenas para uso privado e não comercial.
</p>
<p>
Na medida em que os conteúdos desta página não foram criados pelo operador, os direitos autorais de terceiros são respeitados. Em particular, conteúdos de terceiros são identificados como tal. Caso venha a tomar conhecimento de uma violação de direitos autorais, pedimos que nos informe. Ao tomar conhecimento de violações legais, removeremos tais conteúdos imediatamente.
</p>

<h2>Créditos de imagens</h2>
<p>
Retratos da diretoria: © Gosign GmbH.<br/>
Gráficos e diagramas: Criados pela Gosign GmbH, parcialmente com ferramentas assistidas por IA.<br/>
Salvo indicação em contrário: © Gosign GmbH. Todos os direitos reservados.
</p>

<h2>Resolução de litígios</h2>
<p>
A Comissão Europeia disponibiliza uma plataforma para resolução de litígios online (ODR):
<a href="https://ec.europa.eu/consumers/odr/" target="_blank" rel="noopener noreferrer" class="text-gosign-accent-text hover:text-gosign-accent-hover">https://ec.europa.eu/consumers/odr/</a>
</p>
<p>
Não estamos obrigados nem dispostos a participar em procedimentos de resolução de litígios perante uma comissão de arbitragem de consumidores.
</p>

<h2>Aviso de marcas registradas</h2>
<p>
<a href="https://www.sap.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text hover:text-gosign-accent transition-colors">SAP</a>, SAP S/4HANA, SAP SuccessFactors, SAP Business Technology Platform e SAP Joule são marcas registradas ou marcas da SAP SE, Walldorf, Alemanha.
</p>
<p>
<a href="https://www.microsoft.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text hover:text-gosign-accent transition-colors">Microsoft</a>, Microsoft Azure, Microsoft Copilot, Microsoft Teams, SharePoint, Active Directory e Microsoft Graph são marcas registradas ou marcas da Microsoft Corporation, Redmond, EUA.
</p>
<p>
<a href="https://www.totvs.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text hover:text-gosign-accent transition-colors">TOTVS</a> é uma marca registrada da TOTVS S.A., São Paulo, Brasil.
</p>
<p>
<a href="https://www.workday.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text hover:text-gosign-accent transition-colors">Workday</a> é uma marca registrada da Workday, Inc., Pleasanton, EUA.
</p>
<p>
<a href="https://www.personio.de/" target="_blank" rel="noopener noreferrer" class="text-gosign-text hover:text-gosign-accent transition-colors">Personio</a> é uma marca da Personio SE & Co. KG, Munique, Alemanha.
</p>
<p>
<a href="https://about.google/" target="_blank" rel="noopener noreferrer" class="text-gosign-text hover:text-gosign-accent transition-colors">Google</a> e Google Calendar são marcas da Google LLC, Mountain View, EUA.
</p>
<p>
Todos os outros nomes de produtos e empresas mencionados são marcas ou marcas registradas de seus respectivos proprietários.
</p>
<p>
O uso de marcas neste site serve exclusivamente para fins de identificação de produtos e não implica afiliação, certificação ou endosso pelos respectivos titulares das marcas.
</p>

--- Agente de Contabilização ---
> Atribui faturas recebidas à conta contábil correta (SKR03/04 ou individual), ao centro de custo e ao código fiscal correto.

## Contabilização incorreta custa cinco dígitos em cada auditoria fiscal

Empresas de pequeno e médio porte pagam em média 24.000 EUR (26.000 USD) após uma auditoria fiscal. Em fiscalizações especiais de ICMS, esse valor chega a aproximadamente 25.000 EUR (27.000 USD) por empresa. Em mais da metade de todas as auditorias há lançamentos adicionais. A causa mais frequente: contabilização incorreta. Conta contábil errada significa código fiscal errado. Código fiscal errado significa crédito tributário negado. Crédito negado ao longo de vários anos se acumula rapidamente na casa dos seis dígitos.

O problema não é negligência. Uma empresa com 10.000 faturas recebidas por mês toma 10.000 decisões de contabilização - todo mês. No processamento manual, a taxa de erro, segundo o Institute of Finance and Management (IOFM), gira em torno de 2%. São 200 faturas mensais em que conta, centro de custo ou código fiscal estão errados. Cada uma é um achado que um auditor fiscal pode levantar.

## Dez decisões por fatura - cada uma com efeito tributário

A contabilização é frequentemente tratada como etapa de registro. Na realidade, é uma cadeia de dez decisões individuais que acionam consequências jurídicas distintas.

Um exemplo do dia a dia: chega uma fatura de serviços de consultoria de um prestador da UE. A contabilidade precisa decidir: qual conta contábil? Qual centro de custo? Qual centro de lucro? Reverse Charge ou imposto regular? Crédito tributário permitido? O valor está acima do limite de ativo imobilizado de baixo valor? Precisa ser diferido por competência? O lançamento só está correto quando todas as decisões parciais estiverem corretas.

Cada uma dessas decisões segue uma lógica própria. A atribuição da conta contábil deriva da descrição do serviço e do plano de contas. O código fiscal segue o padrão contábil alemão GoBD (padrão GoBD alemão de arquivamento fiscal) e a legislação de ICMS. A obrigação de ativação segue HGB e EStG. Quem analisa uma decisão isoladamente ignora as interdependências. Quem as toma manualmente como um todo precisa de experiência, concentração e tempo - em cada fatura.

## Contabilizar por regras, escalar apenas casos de interpretação

O [Decision Layer](/br/decision-layer/) decompõe cada processo de contabilização nessas dez etapas e define para cada uma: regras, IA ou humano. Na contabilização, a distribuição é clara. Nove das dez etapas são resolvíveis por regras. Determinação de código fiscal segundo a legislação de ICMS, verificação de crédito tributário, limites de ativo de baixo valor, diferimento por competência segundo HGB §250 - são decisões determinísticas com resultado inequívoco.

A única etapa que precisa de apoio de IA é a interpretação. Quando a descrição do serviço em uma fatura diz "apoio ao projeto H3" e o plano de contas tem 15 contas possíveis, um conjunto de regras não basta. Aqui o modelo de linguagem avalia, com base em contabilizações históricas, qual conta se encaixa - e atribui um score de confiança. Se o score estiver abaixo do limiar definido, o Agent escala para um responsável. Se estiver acima, contabiliza automaticamente.

O resultado: a contabilidade não processa mais 10.000 faturas. Processa as 300 em que o Agent não está suficientemente seguro. O restante passa direto - verificado, contabilizado, documentado.

## Cada contabilização vira prova de auditoria

O auditor fiscal não pergunta se uma contabilização está correta. Pergunta por que foi feita daquela forma e não de outra. É exatamente aqui que a contabilidade manual falha: a justificativa existe apenas na cabeça do responsável que processou a fatura há oito meses.

O Agent documenta para cada contabilização o caminho completo de decisão: conta aplicada com justificativa, código fiscal com referência legal, centro de custo, score de confiança e se a decisão foi automática ou manual. Isso corresponde às exigências de documentação de procedimentos segundo o padrão contábil alemão GoBD, equivalente brasileiro ao SPED Contábil, Lei 8.846/94 e IN RFB 2.005/2021. O auditor não vê apenas um resultado. Vê o caminho até ele - para cada uma das 120.000 faturas por ano.

## O motor de plano de contas como base para todos os Agents de lançamento

A contabilização é o primeiro passo na contabilidade de fornecedores, mas não o único. Despesas de viagem, representação, imobilizações, provisões, diferimentos - cada um desses processos precisa da mesma lógica fundamental: serviço para conta contábil para código fiscal. Quem estrutura essa atribuição de forma limpa para a contabilização constrói a infraestrutura para qualquer outro Agent de lançamento.

O framework de mapeamento utilizado pelo Agent de Contabilização vira bloco padrão. A avaliação de confiança e o padrão de escalação - contabilizar automaticamente ou repassar a um humano - viram projeto-base. Nem todo Finance Agent precisa responder novamente como lida com incerteza. O Agent de Contabilização responde uma vez, e todos os outros constroem em cima.

--- Agente de Diferimento ---
> Identifica ativos e passivos diferidos a partir de pagamentos e períodos de prestação, calcula valores proporcionais.

Quando o fechamento mensal entrega um resultado de período distorcido, a diretoria toma decisões com base errada. A causa mais frequente: ativos e passivos diferidos ausentes ou incorretos. 94% das equipes de Finanças ainda criam seus diferimentos em planilhas - e metade delas precisa de mais de seis dias úteis para o fechamento mensal inteiro. Só que diferimento por competência, no fundo, não é uma questão de julgamento. É aritmética com calendário.

## Cada ARAP esquecido distorce a base de gestão

Um prêmio de seguro anual de 120.000 EUR (130.000 USD) é pago em janeiro. Sem diferimento, 120.000 EUR pesam sobre o resultado de janeiro, enquanto fevereiro a dezembro parecem bons demais. Multiplicado por dezenas de lançamentos desse tipo - licenças de software, contratos de manutenção, aluguéis pré-pagos - surge um resultado mensal que diz mais sobre datas de pagamento do que sobre o desempenho real do negócio.

A consequência vai além da estética do balanço. Resultados de período incorretos distorcem projeções, falsificam análises de variação e minam a confiança de auditores externos e conselhos fiscais. Segundo análise do Center for Audit Quality, diferimentos, provisões e estimativas incorretos são a causa mais citada de Financial Restatements. Cada correção não custa só dinheiro, mas sobretudo credibilidade.

## Oito de dez etapas de decisão são pura aritmética

O [Decision Layer](/br/decision-layer/) decompõe cada processo de diferimento em dez etapas. Oito delas são totalmente baseadas em regras: Há um pagamento antecipado (ARAP)? Há receita recebida antes do fechamento que pertence ao período seguinte (PRAP)? Trata-se de uma provisão ou de um diferimento? A qual período a despesa pertence economicamente? Qual é o valor proporcional? O valor reconhecido está avaliado com prudência? Qual lançamento contábil corresponde? E quando exatamente ocorre a reversão?

Nenhuma dessas etapas precisa de julgamento humano. A comparação de datas entre momento do pagamento e período de prestação é inequívoca. O cálculo proporcional segue uma fórmula fixa. A lógica de lançamento para ARAP ou PRAP está definida em qualquer plano de contas. E o contralançamento no mês seguinte é uma consequência automática do lançamento inicial.

É justamente isso que torna o Agent de Diferimento um exemplo modelo de automação no razão geral: alto volume, baixa complexidade, zero margem de julgamento. A documentação em conformidade com o padrão contábil alemão GoBD (padrão GoBD alemão de arquivamento fiscal) - base, período de prestação, cálculo, data de reversão - surge como subproduto de cada lançamento, não como obrigação posterior.

## Duas etapas mostram onde a IA faz diferença

O ponto fraco real dos diferimentos manuais não está no cálculo. Está no reconhecimento. Quem identifica o novo contrato-quadro com pagamento trimestral e prestação mensal? Quem encontra a fatura de dezembro cujo período de prestação vai até março?

Duas das dez etapas de decisão usam IA: a estimativa do valor do diferimento quando ainda não há valor de fatura, e o reconhecimento de situações entre períodos em contratos e faturas. O Agent varre novos contratos em busca de períodos de prestação, confronta datas de fatura com vigências contratuais e identifica fatos geradores que exigem diferimento - antes que faltem no fechamento mensal. Esse reconhecimento é o motivo de o Agent não trabalhar apenas mais rápido que um humano, mas de forma mais completa.

A intervenção humana permanece onde deve estar: na verificação pelo auditor. Cada diferimento individual - baseado em regras ou reconhecido por IA - é auditável e contestável.

## Efeito concreto: o fechamento mensal perde seu gargalo

Uma indústria com 200 diferimentos ativos por mês - licenças de software, seguros, parcelas de leasing, contratos de manutenção, serviços pré-pagos - tipicamente consome de dois a três dias-pessoa apenas para diferimento por competência. Listas em Excel com períodos de prestação, lançamentos manuais, controle das reversões do mês anterior.

O Agent reduz esse esforço à verificação de exceções. Diferimentos recorrentes são criados e revertidos automaticamente. Novos fatos geradores são reconhecidos e enviados para aprovação. A documentação fica pronta para auditoria imediatamente. O que resta é uma lista de aprovação em vez de uma lista de criação.

A infraestrutura de apuração por competência que o Agent constrói age além do próprio processo. A lógica de reversão é reutilizada pelo Agent de Provisões. O reconhecimento de situações entre períodos fornece dados de entrada para o Agent de Lease Accounting e o Agent de Compliance Contratual. Diferimento por competência não é o processo mais espetacular na contabilidade. Mas é a base sobre a qual todos os outros resultados de período se apoiam.

--- Agente de Preparação de Demonstrações Anuais ---
> Orquestra checklist, consolida conciliações, verifica opções de avaliação, rascunha anexo e relatório de gestão.

Nenhuma demonstração anual fracassa por falta de competência técnica. Fracassa pela orquestração: conciliações que não ficam prontas, consultas sobre o espelho de ativos que passam três dias numa caixa de entrada, notas explicativas que surgem apenas no último momento. A equipe financeira conhece cada etapa individual - e ainda assim perde semanas coordenando essas etapas entre si.

## As semanas de fechamento prendem toda a equipe em trabalho repetitivo

Segundo o APQC Open Standards Benchmarking, a mediana do fechamento mensal por setores está na faixa de vários dias úteis - a maioria das equipes financeiras precisa de mais de cinco dias úteis apenas para o fechamento mensal. A demonstração anual multiplica esse esforço: espelho de ativos, espelho de provisões, espelho de patrimônio, demonstração de fluxo de caixa, conciliação fiscal, notas explicativas, relatório de gestão, documentos para o auditor e publicação se somam ao processo.

Um cenário concreto ilustra o problema. Uma empresa industrial de médio porte com 200 milhões de euros (USD 218 milhões) de faturamento encerra o exercício. O diretor financeiro coordena uma equipe de seis pessoas durante quatro semanas. Três delas passam a maior parte do tempo criando espelhos contábeis - ou seja, derivações aritméticas de dados que já existem no sistema. Uma pessoa reúne documentos para o auditor. Decisões de avaliação - o verdadeiro trabalho especializado - ocupam talvez 20 por cento do tempo total de fechamento.

Paralelamente, a publicação tardia gera riscos regulatórios. Na Alemanha, o Bundesamt für Justiz aplica multas mínimas de 2.500 euros conforme o padrão contábil alemão GoBD (padrão GoBD alemão de arquivamento fiscal). No Brasil, a IN RFB 2.005/2021 e a Lei 8.846/94 estabelecem obrigações similares de escrituração e entrega via SPED Contábil. Para empresas listadas em bolsa, além da multa, a reputação está em jogo.

## Quinze etapas de decisão separam rotina de julgamento

O [Decision Layer](/br/decision-layer/) decompõe todo o processo da demonstração anual em quinze etapas de decisão individuais - e atribui cada uma a um nível claro. O resultado é um mapa que mostra onde a automação faz sentido e onde o julgamento humano permanece necessário.

O nível 1 (conjunto de regras) abrange nove etapas: o checklist de fechamento, a consolidação das conciliações, a conciliação fiscal em casos padrão, o cálculo de impostos diferidos com base em diferenças temporárias, a preparação da publicação conforme os requisitos legais, além dos quatro espelhos (provisões, ativos, patrimônio, fluxo de caixa). Tudo isso segue regras definidas e dados existentes.

O nível 2 (rascunho de IA com aprovação humana) cobre três etapas: o rascunho das notas explicativas, o rascunho do relatório de gestão e a preparação dos documentos para o auditor com base na lista de itens solicitados. O agente cria rascunhos estruturados - a responsabilidade pelo conteúdo permanece com a equipe especializada.

Três etapas permanecem exclusivamente com o ser humano: as opções de avaliação (decisão de política contábil), a verificação de eventos subsequentes (avaliação de materialidade) e a declaração do balanço (atestação pessoal pela diretoria). Nenhuma automação substitui o julgamento que essas etapas exigem.

## O agente orquestra - o ser humano decide

O que muda na prática? O agente assume a cadência. Ele verifica se todas as conciliações estão concluídas antes de iniciar a próxima etapa. Cria os quatro espelhos diretamente a partir dos resultados dos agentes anteriores. Prepara notas explicativas como rascunho estruturado que a equipe revisa em vez de escrever do zero. Monta o pacote para o auditor conforme a lista de documentos solicitados.

A equipe redistribui seu tempo: menos coordenação, mais decisões de avaliação. A pergunta não é mais "O espelho de ativos está pronto?", mas "Qual método de avaliação aplicamos às provisões para aposentadoria?" - a pergunta pela qual um CFO é efetivamente remunerado.

Para o auditor, surge um efeito colateral: cada etapa de decisão está documentada, cada fonte de dados é rastreável. A auditoria não se torna mais fácil no sentido de menos rigorosa - mas começa com uma base completa e estruturada.

## Cada agente anterior melhora a qualidade do fechamento

O Agente de Demonstração Anual não é uma ferramenta isolada. É o ponto de integração de toda a infraestrutura financeira. O espelho de ativos se alimenta do Agente de Depreciação. O espelho de provisões recorre ao Agente de Provisões. A conciliação de contas vem do Agente de Conciliação, os dados fiscais do Agente de Impostos, as provisões para devedores duvidosos do Agente de Gestão de Recebíveis.

Isso significa: quem opera os agentes anteriores de forma consistente tem automaticamente dados melhores na demonstração anual. Quem define a demonstração anual como objetivo constrói toda a infraestrutura de agentes de trás para frente a partir desse ponto. A demonstração anual não é o começo - é a prova de que a infraestrutura funciona.

--- Agente de Entrada de Ativos ---
> Identifica bens ativáveis em faturas, determina custos de aquisição e produção conforme HGB §255, define vida útil e registra a entrada no espelho de ativos.

Decisões de ativação incorretas estão entre os erros evitáveis mais caros na contabilidade de ativos. Quem contabiliza um bem de investimento como despesa reduz o lucro no exercício errado. Quem ativa uma despesa corrente infla o balanço. Em ambos os casos, depreciações, carga tributária e espelho de ativos ficam incorretos por anos. O Agente de Entrada de Ativos previne exatamente essa alocação equivocada - não automatizando toda a contabilidade, mas decompondo de forma estruturada cada decisão de ativação individual.

## Uma em cada três auditorias questiona o ativo imobilizado

Os números são claros. Segundo pesquisa da PwC, metade das empresas alemãs precisa pagar impostos complementares após uma auditoria fiscal. Em 29 por cento das empresas afetadas, as objeções se referem à contabilização do ativo imobilizado (Fonte: PwC, "Betriebsprüfung (auditoria fiscal alemã)", 2024). O motivo mais frequente: bens foram classificados incorretamente, custos acessórios de aquisição não foram atribuídos corretamente ou vidas úteis foram definidas sem justificativa rastreável.

O Ministério das Finanças alemão cifra o resultado adicional de todas as auditorias fiscais em 2024 em 10,9 bilhões de euros (USD 11,9 bilhões) provenientes de 140.764 empresas auditadas (BMF, novembro de 2025). Uma parcela significativa recai sobre correções no ativo imobilizado - porque a decisão de ativação original não estava documentada ou se baseava em premissas incorretas.

Para CFOs, isso significa: a decisão de ativação não é um detalhe contábil. É um risco de auditoria com consequências financeiras mensuráveis.

## A decisão de ativação acontece em segundos - e produz efeitos por anos

Imagine uma semana típica na contabilidade de fornecedores de uma empresa de médio porte. 40 faturas recebidas, seis delas acima de 800 euros (USD 872) líquidos. Cada uma dessas faturas exige a mesma sequência de decisões: É um bem ou um serviço corrente? O valor está acima do limite para bens de baixo valor? Qual classe de ativo? Qual vida útil conforme a tabela de depreciação? Custos de transporte fazem parte dos custos acessórios de aquisição?

Um colaborador toma essas decisões frequentemente em minutos - sob pressão de tempo, com informações incompletas, às vezes apoiado na experiência em vez da tabela atualizada. A consequência só aparece anos depois: no inventário, quando ativos físicos e espelho de ativos não batem. Ou na auditoria fiscal, quando o auditor questiona a vida útil de uma máquina especial e não encontra documentação.

A fonte de erro não está na falta de competência. Está na estrutura: cada decisão de ativação contém componentes determinísticos (valor limite, classe de ativo, cálculo de custos) e margens de julgamento (vida útil de equipamentos especiais, delimitação de bens compostos). Quando ambos se fundem em uma etapa manual, falta a rastreabilidade.

## Nove etapas de decisão separam regras de julgamento

O [Decision Layer](/br/decision-layer/) decompõe a entrada de ativos em nove etapas discretas. Cada etapa tem um decisor definido: conjunto de regras, modelo de IA ou ser humano.

A identificação do bem a partir da descrição da fatura utiliza um modelo de linguagem. Uma fatura referente a "montagem e comissionamento da linha de produção - galpão 7" não contém código de barras nem cadastro de ativo - mas contexto suficiente para reconhecer o bem.

A verificação de ativação é puramente baseada em regras: valor líquido acima de 800 euros (USD 872), portanto obrigação de ativação conforme a legislação fiscal alemã (EStG). Abaixo disso, tratamento como bem de baixo valor ou pool coletivo. O mesmo vale para o cálculo dos custos de aquisição conforme HGB parágrafo 255, a atribuição do número de inventário e o registro no espelho de ativos. Essas etapas são determinísticas. Não se beneficiam do julgamento humano, mas sim de consistência e completude.

Diferente nos casos limítrofes: a classificação de uma fresadora CNC com equipamento especial na classe de ativo correta pode ser preparada por regras, mas não decidida definitivamente. A vida útil de uma máquina especial não consta na tabela de depreciação padrão. Aqui o ser humano decide - mas com base em uma proposta pré-estruturada, não em uma folha em branco.

## O ser humano decide onde o julgamento é necessário

O Agente de Entrada de Ativos opera nos níveis 1 e 2 do Decision Layer. Isso significa: etapas baseadas em regras rodam automaticamente com protocolo. Etapas assistidas por IA fornecem sugestões com índice de confiança. Nenhuma etapa altera o balanço sem base de decisão documentada.

Concretamente: quando o agente processa uma fatura de 12.000 euros (USD 13.080) referente a uma balança de laboratório, a verificação de ativação roda baseada em regras. A classe de ativo "instalações e máquinas técnicas" é atribuída por regras. A vida útil de 10 anos vem da tabela de depreciação, referência documentada. Custos acessórios de calibração e instalação são incluídos nos custos de aquisição - HGB parágrafo 255, inciso 1.

Para a auditoria fiscal, surge assim um caminho de decisão completo: por que ativado, como classificado, quais componentes dos custos de aquisição, qual vida útil com qual base legal. Essa documentação não é criada posteriormente para o auditor. Surge como subproduto natural de cada decisão de ativação individual.

Isso não reduz a responsabilidade do CFO pela correção do balanço. Dá a ele a base para exercer essa responsabilidade de forma informada - em vez de confiar que ninguém na contabilidade de fornecedores cometeu um erro.

--- Agente de Inventário de Ativos ---
> Gera listas de inventário da contabilidade, compara saldo teórico e real, identifica faltantes e prepara lançamentos de correção.

Entre 10 e 30 por cento de todos os registros em cadastros de ativos são chamados Ghost Assets - bens que existem apenas no papel (Fonte: CPCON Group, Fixed Asset Register Guide 2026). O inventário anual conforme HGB parágrafo 240 (equivalente no Brasil: Lei 6.404/76 e IN RFB 2.005/2021 via SPED Contábil) deve prevenir exatamente isso. Na prática, frequentemente fracassa pelo próprio processo: contagem manual em múltiplas unidades, conciliação baseada em planilhas, semanas de retrabalho. O Agente de Inventário resolve esse problema assumindo completamente a parte baseada em regras e parando apenas onde o julgamento humano é necessário.

## Um em cada três ativos no registro existe apenas no papel

Ghost Assets surgem gradualmente. Uma impressora é substituída, mas a baixa não é contabilizada. Uma máquina é transferida para outra unidade sem atualização dos dados cadastrais. Após cinco anos sem verificação física, o cadastro de ativos se distanciou tanto da realidade que o inventário se torna um projeto de saneamento. As consequências são mensuráveis: prêmios de seguro inflados porque são calculados com base em valores contábeis inchados. Depreciações desnecessárias sobre bens que já foram descartados há tempos. No pior caso, uma ressalva na auditoria porque o auditor não aceita a diferença entre registro e realidade.

## Inventário manual não escala entre unidades

Um fabricante de máquinas de médio porte com quatro unidades produtivas e 8.000 ativos conhece o padrão: três semanas antes da data de referência começa a coordenação. Equipes de inventário são escaladas, listas de contagem impressas, scanners distribuídos. Cada unidade conta no seu próprio ritmo. Os resultados voltam por e-mail - como planilhas com formatos diferentes. A consolidação central leva mais duas semanas. Faltantes só ficam visíveis tardiamente, recontagens atrasam o fechamento. O resultado: o inventário consome quatro a seis semanas de trabalho, e mesmo assim restam dúvidas sobre a completude.

## O agente separa contagem de avaliação

O [Decision Layer](/br/decision-layer/) decompõe o inventário de ativos em duas categorias de decisões. Etapas baseadas em regras - gerar lista de inventário a partir do ERP, registrar o saldo real, executar a comparação teórico/real, identificar faltantes, preparar lançamentos de correção - rodam de forma automatizada. O agente compara o saldo contábil com o saldo físico e cria listas de diferenças por unidade, centro de custo e classe de ativo.

Duas decisões permanecem com o ser humano: O bem sofreu desvalorização? Deve ser baixado? Essas questões de avaliação exigem inspeção visual e julgamento. O agente fornece a base para a decisão - idade, vida útil, condição conforme último registro - mas a aprovação cabe ao departamento responsável. Assim o processo permanece auditável conforme os requisitos legais, sem que capacidade humana fique presa em trabalho de contagem.

## Inventário com RFID eleva a precisão para acima de 95 por cento

Inventário manual com scanners de código de barras atinge tipicamente taxas de precisão de 85 a 95 por cento. Inventário com RFID aumenta ainda mais a precisão e reduz significativamente o tempo de registro. O Agente de Inventário utiliza ambas as tecnologias: onde existem tags RFID, registra o saldo real de uma sala em segundos em vez de horas. Onde há apenas códigos de barras, orquestra o registro manual com listas por unidade e acompanhamento de progresso em tempo real. O investimento em infraestrutura RFID se paga na prática em poucos anos - não apenas pelo inventário mais rápido, mas também pelo melhor rastreamento de localização no dia a dia.

## Lançamentos de correção ficam prontos no dia do inventário

O verdadeiro objetivo do inventário não é a contagem, mas o cadastro de ativos saneado. O Agente de Inventário prepara lançamentos de correção assim que uma divergência é confirmada: baixas para bens não localizados, depreciações extraordinárias para ativos com perda de valor, correções de localização para bens transferidos. No final, há um relatório de inventário que documenta todo o processo - da lista teórica ao registro real até a aprovação de cada correção individual. O auditor recebe não apenas um resultado, mas o caminho de decisão completo. Isso acelera a auditoria e reduz as consultas ao essencial.

--- Agente de Conciliação Bancária ---
> Conciliação bancária determinística: retorno CNAB 240/400, PIX em tempo real e Open Finance Brasil baixados em cadeia auditável, sem IA generativa.

A conciliação bancária no Brasil é o ponto em que a contabilidade prova credibilidade frente a sete fiscalizações simultâneas: a Receita Federal cruza os lançamentos do Bloco I250 da ECD contra a EFD-Contribuições e a DCTF, o BACEN aplica a Resolução 4.557/2017 sobre risco operacional incluindo conciliação tempestiva, a FEBRABAN exige decifração correta dos códigos de ocorrência CNAB 240/400 (02 liquidado, 03 rejeitado, 04-09 pendente), o COAF fiscaliza PLD-FT em movimentos acima de R$ 50.000 (Lei 9.613/98 e Circular BACEN 3.978/2020), a ANPD exige base legal LGPD para tratamento de dados financeiros (Lei 13.709/2018), a CVM exige conciliação sem ressalva em demonstrações financeiras de companhias listadas, e o Cosif BACEN padroniza a classificação contábil de tarifas e IOF. Cada divergência persistente carrega risco fiscal duplo: glosa de despesa bancária pela Receita Federal com multa de 75% a 150% (Lei 9.430/96 art. 44) sobre o tributo devido, acrescida de Selic e 1% ao mês, e bloqueio de Certidão Negativa de Débitos (CND) que impede licitações públicas da Lei 14.133/21 e financiamentos do BNDES, FINEP e Caixa.

## Divergência persistente de conciliação gera glosa Receita Federal (multa 75-150%), bloqueio CND e sanção COAF por falha em PLD-FT

Uma indústria de médio porte com 7 contas correntes em 5 bancos (Itaú, Bradesco, Banco do Brasil, Caixa, Santander), volume médio de 250 movimentos por dia e fluxo PIX intra-day de R$ 1,8 milhão diário tem cerca de 5.000 movimentos contábeis mensais para conciliar. Antes da automação, dois analistas de Tesouraria gastavam de 18 a 22 dias úteis por mês baixando extratos manualmente, classificando tarifas em Excel, escalando divergências em planilhas paralelas - e sempre fechando o mês com R$ 80-150 mil em movimentos não atribuídos que rolavam para o mês seguinte como "ajuste a esclarecer".

A consequência prática vai além do custo de mão de obra: divergências persistentes acima de 60 dias acionam alertas em auditoria independente NBC TA 240, geram ressalva em demonstrações financeiras e em companhia listada CVM acionam questionamento formal do auditor independente. Em fiscalização Receita Federal, despesas bancárias mal classificadas (multa por cheque devolvido contabilizada como tarifa dedutível, IOF não segregado, tarifa de boleto registrado como receita financeira negativa) geram glosa retroativa com multa de 75% a 150% sobre o IRPJ-CSLL devido (Lei 9.430/96 art. 44), acrescida de Selic e 1% ao mês de juros, bloqueio automático de CND no e-CAC e impedimento de licitações da Lei 14.133/21. Para empresas com 30% da receita em licitações públicas, o impacto cascata é a perda de pipeline comercial do exercício seguinte. E o pior: uma entrada não conciliada de R$ 60 mil de origem desconhecida que ficou parada por 90 dias sem comunicação ao COAF (Lei 9.613/98 art. 11) gera sanção COAF de R$ 200 mil a 200% do valor da operação não comunicada (art. 12).

## A conciliação bancária brasileira percorre 14 etapas determinísticas, não 7 nem 15

Diferente do modelo alemão (7 etapas, focado em CAMT.053 e MT940 com GoBD) ou do polonês (10 etapas, com MT940, JPK e biała lista), e diferente da execução de pagamentos brasileira (15 etapas), a conciliação bancária BR exige 14 etapas determinísticas porque o sistema bancário tem três camadas paralelas (CNAB legado, PIX em tempo real e Open Finance via API) e mais regulação contábil-fiscal: importação CNAB 240/400 com validação de ISPB e webhook PIX autenticado por mTLS, decifração de código de ocorrência FEBRABAN e status PIX (CONCLUDED/REJECTED/REFUNDED), identificação por NF-e/CT-e/contrato, identificação de contraparte PIX via DICT BACEN, matching aproximado com score auditável, classificação de tarifas no Cosif BACEN, tratamento de IOF (Decreto 6.306/2007, alíquota de 0,38% mais 0,0082% ao dia para PJ), conversão cambial PTAX BACEN, detecção de duplicidade por NSU FEBRABAN e EndToEndId PIX, screening PLD-FT (Lei 9.613/98) acima de R$ 50.000, consolidação multibanco via Open Finance Brasil (Resolução CMN 4.951/2021), geração de lançamento ECD Bloco I250 (IN RFB 2.003/2021), escalonamento humano para divergências e arquivamento por 5 a 10 anos.

Um cenário concreto: distribuidora atacadista com 12 contas correntes em 6 bancos, volume de 580 movimentos diários (320 de cobrança CNAB, 180 de recebimento PIX e 80 transferências internas) e faturamento de R$ 320 milhões/ano ocupava três analistas de Tesouraria em tempo integral apenas para conciliação. Após implementação do Agente, o sistema importa automaticamente os retornos CNAB 240 às 6h00 e às 17h30 (janelas FEBRABAN padrão), consome webhooks PIX em tempo real via mTLS conforme Resolução BCB 195/2022, valida 580 movimentos contra ISPB BACEN, decifra códigos de ocorrência (em média 547 código 02 liquidado, 18 código 03 rejeitado por dados inconsistentes, 15 pendentes códigos 04-09), aplica matching exato por chave NF-e em 89% dos casos, matching aproximado por padrão histórico de 24 meses em 7% (com score acima de 85%), e escala 4% (cerca de 23 movimentos/dia) para revisão humana. As tarifas são classificadas no Cosif BACEN automaticamente (R$ 18-25 mil/mês em despesas bancárias dedutíveis), o IOF crédito de 0,38% mais 0,0082% ao dia é segregado em conta própria, o screening PLD-FT roda em 14 movimentos acima de R$ 50.000 sem match positivo, e o saldo agregado Open Finance bate com soma CNAB com tolerância de R$ 0,01 (arredondamento PTAX). O tempo total de conciliação caiu de 22 dias úteis/mês para 3 horas/dia de revisão humana das exceções.

No [Decision Layer](/br/decision-layer/), 13 das 14 etapas são decisões baseadas em regras (nível R) - cada uma é cálculo determinístico contra Manual FEBRABAN, Resolução BCB 195/2022, DICT BACEN, Lei 9.430/96 art. 30 ou IN RFB 2.003/2021 - 1 etapa é matching aproximado (nível A, com score auditável e revisão humana abaixo do threshold) e 1 é decisão humana obrigatória (nível H): tratamento de divergência persistente que envolve julgamento sobre risco operacional conforme Resolução BACEN 4.557/2017. Não há ponto em que IA generativa decida sobre baixa contábil - cada validação aplica norma BACEN, FEBRABAN, RFB ou Cosif.

## Plausibilidade multibanco em tempo real fecha o ciclo Open Finance Brasil

A Resolução CMN 4.951/2021 e a Resolução BCB 109/2021 implementam em fases (2020-2026) o Open Finance Brasil, com aplicação direta na conciliação: o Agente consulta o saldo agregado de todas as contas relacionadas via TPP (Third Party Provider) autorizado BACEN, com consentimento do correntista renovado a cada 12 meses, e compara em tempo real com a soma dos saldos finais CNAB importados. Divergência maior que R$ 0,01 (arredondamento PTAX) aciona alerta imediato com hipóteses ranqueadas: (1) extrato CNAB atrasado D+1; (2) webhook PIX falhou ou mTLS expirou; (3) tarifa bancária debitada sem registro CNAB enviado; (4) bloqueio judicial BacenJud sem comunicação CNAB padrão; (5) erro de classificação Cosif. A divergência fica visível no dia em que surge, em vez de acumular para o fechamento mensal.

Para empresas com volume alto (>1.000 movimentos/dia), o CNAB 240 batch ainda é mais eficiente que ITP Open Finance individual - mas a conciliação Open Finance roda em paralelo como prova de saldo, eliminando o efeito acumulado típico de divergências bancárias. Empresas com fluxo intra-day intenso (e-commerce, marketplace, varejo presencial) reconciliam PIX em segundos e detectam fraude em minutos - tempo que era impossível no modelo CNAB D+1 puro.

## Edge-cases brasileiros: bloqueio BacenJud, estorno PIX e conversão cambial PTAX

Para movimentos atípicos, o Agente aplica regras específicas brasileiras: (1) Bloqueio BacenJud (CPC art. 854) - quando o BACEN recebe ordem judicial de penhora online, debita imediatamente da conta sem aviso prévio CNAB; o Agente detecta o débito sem origem reconhecida acima de R$ 1.000, cruza com cadastro de processos judiciais ativos da empresa e classifica como "bloqueio judicial provisório" até confirmação do ofício; (2) Estorno PIX REFUNDED (Resolução BCB 195/2022 art. 25) - destinatário pode solicitar estorno em até 90 dias por erro ou fraude; o Agente reverte automaticamente o lançamento de baixa, restaura o item em aberto e marca para revisão Compliance se for o terceiro estorno do mesmo CNPJ em 12 meses; (3) Conversão cambial USD/EUR pela PTAX BACEN do dia da liquidação (Lei 9.430/96 art. 4 e RFB IN 1.700/2017) - PTAX venda do dia útil anterior para custos, PTAX média para resultado financeiro; variação cambial é registrada no Bloco I250 ECD em conta de variação cambial dedutível ou não dedutível conforme regime; (4) Pagamento parcial em CNAB com desconto pontualidade negociado - o Agente reconhece o valor recebido menor que NF-e original, classifica a diferença como desconto financeiro concedido (4.1.5.X Cosif) e baixa parcialmente o item em aberto.

## Integração com ecossistema brasileiro: TOTVS, SAP, Senior, Mastermaq e Open Finance TPPs

A lógica do Agente conecta-se aos principais sistemas de gestão financeira do mercado brasileiro via API: [TOTVS Protheus FI e Módulo Bancário](https://www.totvs.com/) (líder em médias e grandes empresas com importação CNAB 240/400 nativa para todos os bancos brasileiros e integração de webhook PIX), TOTVS RM Saldus e Datasul (forte em manufatura e indústria), [SAP S/4HANA Brazil Localization](https://www.sap.com/brazil/) com Cash Management Brazil (Bank Communication Management para CNAB e Open Finance), [Senior Sistemas Financeiro](https://www.senior.com.br/) (forte em indústria com mais de 5.000 clientes BR e integração FEBRABAN nativa), Oracle ERP Cloud Brazil Cash Management (gigantes IBOVESPA), e [Mastermaq Domínio Sistemas](https://www.mastermaq.com.br/) (escritórios contábeis e PME com automação CNAB simplificada). Para integração Open Finance Brasil, o Agente conecta-se via TPPs autorizados BACEN (Belvo Brasil, Pluggy, Klavi, Iniciador.com) com mTLS e OAuth 2.0 conforme padrão técnico do BACEN. Para empresas com matriz na Europa ou EUA (Volkswagen, Bosch, Siemens, GE com unidades brasileiras), o Agente também consolida a posição financeira BR em formato compatível com tesouraria global SAP TRM ou Kyriba - mantendo a operação local CNAB/PIX/Cosif/ECD compliant e o reporting parental sob padrões internacionais IFRS.

--- Agente de Análise de Variação Orçamentária ---
> Agente decompõe variações Plano-Realizado em drivers preço/volume/mix/câmbio/timing alinhado CPC 26, CVM 80/2022 ITR/DFP, B3 EBITDA padronizado e NBC TA 540.

A análise de variação orçamentária no Brasil constitui um sistema regulatório multifacetado que combina seis áreas principais: o CPC 26 R1 (alinhado ao IAS 1) para a apresentação de DRE, Balanço Patrimonial, DFC, DMPL e DVA com comentários gerenciais sobre variações materiais conforme a Lei 6.404/76 art. 176-179; a CVM Resolução 80/2022 para o ITR trimestral e a DFP anual com comentário gerencial obrigatório sobre variações Plano-Realizado significativas; a Receita Federal IN 1.700/2017 com os Blocos K e N da ECF para a apuração de IRPJ Lucro Real e CSLL, com adições e exclusões M-300 documentadas na variação; o Ofício Circular B3 01/2018 para o EBITDA e o EBIT padronizados, que eliminam a divergência de versões entre Plano e Realizado; a NBC TA 540 para o substantive testing das variações pelas Big-4 como evidência de indicador de impairment (CPC 04 R1) e de going concern; e a Lei 6.404/76 art. 1.005 para a responsabilidade civil dos administradores por comentários gerenciais enganosos. Cada empresa brasileira de médio ou grande porte precisa coordenar a decomposição determinística em cinco drivers (preço, volume, mix, câmbio e timing), a categorização de causa-raiz por unidade de negócio, a reconciliação do EBITDA padronizado da B3, o comentário gerencial ITR/DFP e a trilha de auditoria das Big-4.

## Comentário gerencial em ITR/DFP da CVM, ECF da Receita Federal, NBC TA 540 das Big-4, EBITDA padronizado da B3 e responsabilidade dos administradores na Lei 6.404/76: cinco frentes que exigem decomposição determinística por driver

A CVM Resolução 80/2022 unificou o ITR trimestral e a DFP anual, exigindo comentário gerencial sobre variações materiais com drivers e causas-raiz documentados - diferentemente dos EUA, o Brasil não tem safe harbor para projeções (Lei 6.385/76 art. 22, fatos relevantes). A Receita Federal IN 1.700/2017 e os Blocos K e N da ECF exigem a reconciliação da variação do Lucro Antes do IRPJ e das adições e exclusões M-300 entre Plano e Realizado. As Big-4 brasileiras executam substantive testing trimestral conforme a NBC TA 540, cobrando de R$ 800 mil a 1,8 milhão por ano de uma empresa média da B3. O Ofício Circular B3 01/2018 padroniza o EBITDA e o EBIT entre Plano e Realizado, eliminando a divergência de versões - o EBITDA Ajustado exige reconciliação linha a linha e nota explicativa.

Casos célebres demonstram o impacto: Petrobras (2014, divergência de EBITDA antes da Lava Jato), JBS (2017, exclusões do EBITDA Ajustado questionadas por analistas), Americanas (2023, fraude de US$ 9 bilhões na contabilidade de fornecedores - variação entre Realizado e Plano não detectada por anos) e Magazine Luiza (2023, controvérsia sobre o EBITDA de logística). Em todos os casos, a falta de decomposição determinística em cinco drivers, de trilha de auditoria das Big-4 e de reconciliação do EBITDA padronizado contribuiu para o enforcement da CVM, class actions sob a Lei 6.404/76 art. 158 e perda de confiança do buy-side (ANBIMA).

## 16 pontos decisivos: onze determinísticos, um com ML e quatro escalados a humanos

O Agente processa a análise de variação por um pipeline de 16 pontos decisivos: onze classificações regulatórias determinísticas, um assistido por ML (padrões cross-driver) e quatro escalados a humanos (categorização de causa-raiz, propostas de ação, avaliação de contramedidas e sign-off das Big-4). Coleta dados de Plano (TOTVS Performance Plus, SAP Analytics Cloud Planning, Oracle EPM Cloud, Anaplan, Workday Adaptive, Vena, IBM Planning Analytics) e de Realizado (TOTVS Protheus, RM e Datasul, SAP S/4HANA, Oracle ERP Cloud, Senior Sistemas, Microsiga), reconciliados com os Blocos K e N da ECF da Receita Federal. Conciliação do plano de contas com ajustes de provisões por competência e reclassificações de eventos não recorrentes, documentadas para as Big-4 (NBC TA 540).

Limiares de materialidade parametrizados por unidade de negócio, grupo de contas e linha da DRE: tipicamente acima de 5% do EBITDA, de 10% por linha ou de R$ 500 mil em valor absoluto. Decomposição determinística em cinco drivers: variação de preço = (P_R - P_O) * Q_R, por SKU, cliente e canal; variação de volume = (Q_R - Q_O) * P_O; variação de mix = soma de (Mix_R - Mix_O) * Margem_O; variação de câmbio = (FX_R - FX_O) * Exposição, com hedge accounting do CPC 02 R2; e variação de timing = receitas e custos antecipados ou diferidos em relação ao cronograma orçado.

Padrões cross-driver via clusterização de ML e correlação histórica de mais de 24 meses identificam combinações não óbvias (por exemplo, alta do câmbio com queda no volume de importação e deslocamento do mix para o nacional). Categorização de causa-raiz por unidade de negócio: compras (preço de matérias-primas), produção (eficiência operacional e refugo), comercial (volume, preço e mix), tesouraria (câmbio e hedge) e planejamento (timing e sazonalidade) - com julgamento do controller e conhecimento contextual obrigatórios.

Reconciliação do EBITDA padronizado da B3 (Ofício Circular 01/2018) entre Plano e Realizado, com EBITDA Ajustado linha a linha e nota explicativa ITR/DFP automatizada. Geração de rascunho assistido por LLM para o comentário gerencial, integrando os drivers materiais, as causas-raiz, o impacto no EBITDA e o outlook do trimestre seguinte - o controller revisa, complementa o contexto e aprova.

Exemplo concreto: empresa brasileira de médio porte (R$ 400 milhões de faturamento, listada no Bovespa Mais, 1.800 funcionários, 4 unidades de negócio e exposição cambial de 25% em USD). Variação total do EBITDA Plano-Realizado no Q3 de 2026: -R$ 18 milhões (-22%). Decomposição em cinco drivers: preço -R$ 7M (alta das matérias-primas químicas, responsabilidade de compras), volume -R$ 4M (queda na demanda industrial, responsabilidade do comercial), mix -R$ 2M (deslocamento para SKUs de menor margem, responsabilidade do portfólio comercial), câmbio -R$ 6M (USD/BRL de 5,40 para 6,10, responsabilidade do hedge da tesouraria) e timing +R$ 1M (faturamento do Q4 antecipado para o Q3, responsabilidade do planejamento). A soma reconcilia 100% da variação total. EBITDA padronizado da B3 Realizado de R$ 64M ante Orçado de R$ 82M, reconciliado em nota explicativa no ITR. EBITDA Ajustado Realizado de R$ 71M (excluindo impairment não recorrente de R$ 7M), reconciliado linha a linha conforme a CVM Resolução 80/2022.

## Categorização de causa-raiz, propostas de ação e comentário gerencial ITR/DFP da CVM

A categorização de causa-raiz por unidade de negócio confronta os drivers materiais com a responsabilidade interna - com julgamento do controller e conhecimento contextual obrigatórios, porque o modelo não captura negociações em curso ou eventos estruturais. Propostas de ação por driver: preço - renegociação com fornecedores, revisão de pricing e hedge de matérias-primas; volume - revisão da capacidade de produção, iniciativas de market share e análise da concorrência; mix - rebalanceamento do portfólio e descontinuação de SKUs de baixa margem; câmbio - hedge cambial com NDF e Swap e revisão da política de tesouraria; timing - revisão do cronograma de capex e da sazonalidade da demanda. A avaliação de contramedidas requer julgamento do CFO, do Comitê Executivo e do Conselho.

O comentário gerencial trimestral (ITR) e anual (DFP) é gerado conforme a CVM Resolução 80/2022, com os drivers materiais, as causas-raiz, o impacto no EBITDA, o outlook do trimestre seguinte, as ações corretivas, a base macroeconômica do Boletim Focus do BACEN e o sign-off de CFO, Controller e Conselho Fiscal. Trilha de auditoria das Big-4 sob a NBC TA 540: backup matemático da decomposição em cinco drivers, rationale do julgamento na categorização de causa-raiz, reconciliação do EBITDA padronizado da B3 e integração dos Blocos K e N da ECF para a variação de IRPJ/CSLL, certificada com ICP-Brasil A1/A3 e WORM imutável por 5 anos, sob a LGPD art. 7 IX (cumprimento de obrigação legal).

## Integração com TOTVS Protheus, RM e Performance Plus, SAP S/4HANA e SAC, Oracle EPM, Anaplan e Senior Sistemas, mais o substantive testing das Big-4

O Agente integra-se aos sistemas brasileiros de Performance Management via API REST e ETL: [TOTVS Protheus, RM e Datasul](https://www.totvs.com/) com TOTVS Performance Plus (líder no Brasil, com mais de 50.000 clientes e os Blocos K e N da ECF nativos), [Anaplan Brazil](https://www.anaplan.com/) com Connected Planning (multilatinas e IBOVESPA, consolidação multipaís com decomposição por driver e multimoeda), [Workday Adaptive Planning Brazil](https://www.workday.com/) (multinacionais com Workday HCM para variação de headcount), [Vena Solutions Brazil](https://www.venasolutions.com/) (Excel-native para times de FP&A), SAP S/4HANA Brazil com SAP Analytics Cloud Planning (multilatinas SAP-centric), Oracle EPM Cloud e Hyperion Planning Brazil (gigantes do IBOVESPA e bancos), Senior Sistemas e Senior HCM (indústria e médias empresas), além de Jedox Brazil, Cubeware Cockpit Brazil e IBM Planning Analytics TM1 Brazil (alternativas para o mid-market). Câmbio do Boletim Focus do BACEN via API e cotações de fechamento de USD/EUR/CNY/ARS para a variação cambial do CPC 02 R2, com hedge accounting pelos CPC 38, 39 e 40. Substantive testing das Big-4 com exportação direta para Deloitte ASM, PwC Halo, EY Helix e KPMG Clara, com metadados de trilha de auditoria NBC TA 540 e ICP-Brasil A1/A3. Integração do comentário gerencial ITR/DFP da CVM Resolução 80/2022 via API da Plataforma de Comunicações da CVM. EBITDA padronizado da B3 (Ofício Circular 01/2018) com reconciliação Plano vs Realizado automatizada e template de nota explicativa para ITR/DFP.

--- Agente de Alocação de Recebimentos ---
> Lê extratos bancários (CAMT.053, MT940), atribui pagamentos a clientes e faturas, valida descontos e cria lançamentos de compensação.

Entre o recebimento e a compensação contábil do crédito há, em muitas empresas, horas de trabalho manual de atribuição. Responsáveis comparam extratos com itens em aberto, verificam descrições, identificam pagadores divergentes e esclarecem diferenças. Em empresas com várias centenas de recebimentos por dia, esse processo prende profissionais cuja competência deveria ser aplicada a casos de esclarecimento e ao relacionamento com clientes. Ao mesmo tempo, cada hora sem atribuição atrasa o efeito de liquidez do pagamento - e piora o Days Sales Outstanding.

## Cada dia sem atribuição piora o capital de giro

O DSO médio entre setores está em 57 dias - mesmo a maioria das empresas tendo prazos acordados de 28 dias (Fonte: Kapittx, 2025). Esse intervalo de quase 30 dias não se deve apenas a pagadores inadimplentes. Uma parte significativa vem de atrasos internos: pagamentos que entraram mas ainda não foram atribuídos e, portanto, ainda não foram lançados como compensação de recebível.

Para uma empresa com 50 milhões EUR (55 milhões USD) de receita anual, cada dia de redução no DSO significa cerca de 137.000 EUR (150.000 USD) em capital de giro liberado. Cash Application, portanto, não é um processo administrativo secundário, mas uma alavanca direta sobre a qualidade do balanço.

## 80% das atribuições seguem um conjunto fixo de regras

A atribuição manual sugere uma complexidade que não existe na maioria dos casos. Uma análise de recebimentos típicos mostra: cerca de 80% podem ser atribuídos de forma inequívoca via número da fatura no campo de descrição, valor e dados cadastrais do cliente. Empresas com Cash Application automatizada, segundo a Emagia (2025), alcançam precisões de atribuição entre 95 e 98% e reduzem o tempo de processamento manual em 80 a 90%.

O ponto decisivo: essa alta taxa não é resultado de IA em sentido estrito. Baseia-se em regras determinísticas - ler o extrato, comparar a referência, conferir o valor, gerar o lançamento. O conjunto de regras entrega resultados reproduzíveis e auditáveis. É justamente isso que torna o processo automatizável em conformidade com o padrão contábil alemão GoBD (padrão GoBD alemão de arquivamento fiscal).

## Pagadores divergentes e pagamentos parciais exigem um modelo de decisão escalonado

Os 20% restantes são a razão pela qual uma automação total fracassa sem arquitetura de decisão. Cenários típicos: um conglomerado paga por uma central de pagamentos cujo nome não bate com o do cliente. Um cliente quita três faturas em uma única transferência, mas deduz desconto em uma delas mesmo com o prazo vencido. Ou um pagamento está 47 EUR (51 USD) abaixo do valor da fatura - arredondamento, dedução legítima ou erro?

O [Decision Layer](/br/decision-layer/) distingue esses casos por níveis de escalação. Nível 1 - o conjunto de regras - resolve a conferência exata: parsing de CAMT.053, matching de número de fatura, verificação do prazo de desconto contra dados contratuais. Nível 2 - matching aproximado - entra em cena quando há pagadores divergentes, combinando dados bancários dos cadastros, padrões históricos de pagamento e similaridades de nome. Só quando os dois níveis não entregam uma atribuição inequívoca é que o Agent escala para o responsável - com todas as informações de contexto já coletadas para preparar a decisão.

## O responsável vira especialista em esclarecimento

No mundo manual, o responsável passa a maior parte do tempo em atribuições de rotina que não exigem nenhum julgamento técnico. A expertise real - avaliar histórico de cliente, interpretar comportamento de pagamento, tomar decisões comerciais sobre diferenças - fica em segundo plano porque a massa de casos padrão domina a jornada de trabalho.

Depois da introdução do Agent de Alocação de Recebimentos, essa proporção muda fundamentalmente. O Agent assume as atribuições baseadas em regras e prepara os casos de esclarecimento para que o responsável esteja imediatamente apto a decidir: qual cliente entra em questão, quais itens em aberto combinam com o valor, qual método de matching foi tentado, por que nenhum funcionou. O papel se transforma, de classificador para especialista em esclarecimento.

Para a empresa, surge um efeito duplo. O tempo entre recebimento e lançamento cai de horas para minutos nos casos padrão. E a taxa de esclarecimento em casos problemáticos sobe porque os profissionais concentram seu tempo nos casos que realmente exigem julgamento humano.

--- Agente de Previsão de Fluxo de Caixa ---
> Previsão de fluxo de caixa rolling 13 e 52 semanas via Open Finance Brasil e PIX, com cenários de stress e alertas de cobertura de covenants (CPC 03 R2).

A previsão de fluxo de caixa no Brasil constitui um sistema regulatório complexo que combina seis áreas principais: o CPC 03 R2 (alinhado ao IAS 7) para a Demonstração dos Fluxos de Caixa obrigatória nas sociedades anônimas; a BACEN Resolução 4.951/2021 (Open Finance Brasil) para a agregação de saldos multibanco em tempo real; a BACEN Resolução 195/2022 (PIX) para o webhook 24/7 de transações instantâneas; a BACEN Resolução 4.557/2017 e a Circular 3.978/2020 para a governança e a gestão de risco; o BACEN PRSAC, desde 2024, para os cenários climáticos NGFS Phase IV em grandes empresas; e a Lei 11.101/2005 art. 47 como gatilho da Recuperação Judicial. Cada empresa brasileira de médio ou grande porte precisa coordenar um forecast determinístico em rolling de 13 semanas, 52 semanas operacionais e 5 anos estratégicos, com cenários climáticos de stress, tracking de covenants de DSCR/ICR, substantive testing das Big-4 sob a NBC TA 540 e o Fato Relevante da CVM Resolução 80/2022.

## Fato Relevante na CVM, Receita Federal, class actions, breach de covenant e Recuperação Judicial: cinco frentes que exigem Cert-Ready by Design

A CVM Resolução 80/2022 obriga a divulgação de Fato Relevante quando a liquidez deteriorada altera materialmente a situação financeira - tipicamente a ação cai de 5% a 12% nos três pregões após a publicação. A Receita Federal IN 1.700/2017 distingue o regime de caixa do de competência para o reconhecimento contábil e tributário. As class actions sob a Lei 6.404/76 art. 158 aceleraram-se desde 2018, com Lava Jato, Brumadinho e Americanas (2023, R$ 43 bilhões); são processos de responsabilidade civil e criminal dos administradores por previsão enganosa. O breach de covenant bancário (tipicamente Itaú, Bradesco, Santander e Banco do Brasil, com DSCR abaixo de 1,2x e ICR abaixo de 2,5x) dispara technical default, cláusulas de aceleração e Fato Relevante obrigatório. A Lei 11.101/2005 art. 47 obriga a Recuperação Judicial em 'situação de crise econômico-financeira' - acionar tarde demais configura quebra dos deveres fiduciários dos administradores (Lei 6.404/76 art. 1.005).

Casos célebres demonstram o impacto: Oi (2016, R$ 65 bilhões de dívida judicial), OGX/OSX (2013, fraude em controles internos), Odebrecht/Novonor (2019, Lava Jato) e Americanas (2023, fraude de US$ 9 bilhões). Em todos os casos, os alertas precoces da previsão de fluxo de caixa não foram acionados ou foram suprimidos. O substantive testing das Big-4 sob a NBC TA 540 (auditoria de estimativas contábeis) exige backup matemático completo, rationale do julgamento humano e backtesting de acurácia histórica - tipicamente de 60 a 80 horas por ciclo trimestral sem automação.

## 15 pontos decisivos determinísticos, com três escalados a humanos

O Agente processa o forecast de fluxo de caixa por um pipeline de 15 pontos decisivos: doze classificações regulatórias, um forecast de ML assistido (52 semanas e 5 anos), uma detecção de anomalias de nível A e três escalados a humanos (cenários de stress do BACEN PRSAC, going concern e cenários de stress combinados). A agregação Open Finance Brasil e PIX em tempo real cobre todos os bancos do grupo via webservices do BACEN, com certificado A1/A3 ICP-Brasil. Classificação do método direto ou indireto do CPC 03 R2 e decomposição em atividades operacionais, de investimento e de financiamento conforme o IAS 7. Modelo de rolling de 13 semanas com ARIMA e overlay de julgamento, no padrão da AFP. Modelo de 52 semanas com Prophet e sazonalidade brasileira (13º salário e férias). Modelo estratégico de 5 anos com System Dynamics e cenários. Motor de DSCR e ICR com cláusulas de covenant de Itaú, Bradesco, Santander e Banco do Brasil, com alertas 4 semanas à frente.

Exemplo concreto: empresa brasileira de médio porte (R$ 500 milhões de faturamento, 1.500 funcionários e 8 bancos do grupo). O Agente agrega 8 contas via Open Finance Brasil, webhook PIX e retornos CNAB 240/400 (AEB Norma 43) em tempo quase real (defasagem de 1 a 3 minutos). Forecast em rolling de 13 semanas, 52 semanas e 5 anos, atualizado semanalmente. DSCR projetado para as próximas 13 semanas: 1,35x (covenant do Itaú de 1,3x, com margem de 5%). ICR: 3,2x (covenant de 3,0x, com margem de 7%). Stress test BACEN PRSAC NGFS Phase IV: o cenário Disorderly Transition reduz o DSCR para 1,18x nas semanas 9 a 12 (alerta ao CFO e ao Board, escalado a humano). Going concern: caixa e linhas disponíveis cobrem 8,5 meses de operação (acima do limite de 6 meses). Backtesting semanal: MAPE de 6,2% em 4 semanas e de 14,8% em 13 semanas (dentro dos limites da AFP).

## Cruzamento de Open Finance Brasil, PIX 24/7 e AEB Norma 43

O Open Finance Brasil (BACEN Resolução 4.951/2021) permite consultar saldos e transações de qualquer banco brasileiro autorizado em tempo real via API. O webhook PIX (BACEN Resolução 195/2022) entrega notificações instantâneas 24/7 de cada transação. Os retornos bancários CNAB 240/400 da FEBRABAN (AEB Norma 43) servem à reconciliação de fim de dia. O Agente agrega os três em uma única visão consolidada: saldos do grupo, transações recentes e identificação das chaves PIX via DICT BACEN (CPF, CNPJ, e-mail, celular ou aleatória). Há cruzamento com o cadastro de fornecedores e clientes, a situação do CNPJ na Receita Federal e a central de beneficiários reais. A detecção de anomalias por ML (Isolation Forest, LSTM Autoencoder, DBSCAN e Bollinger Bands) usa features brasileiras como Selic, câmbio, IPCA e sazonalidade. Um anomaly score acima de 3 desvios padrão aciona o drill-down e a integração com o Agente de Fraude (PLD-FT, BACEN Circular 3.978/2020).

## Integração com TOTVS Treasury, SAP S/4HANA Brazil, Kyriba e GTreasury, mais o substantive testing das Big-4

O Agente integra-se aos sistemas brasileiros de Treasury Management via API: [TOTVS Treasury](https://www.totvs.com/) e TOTVS RM Tesouraria (líder no Brasil e nas médias empresas), [SAP S/4HANA Treasury Brazil](https://www.sap.com/brazil/) com SAP Cash Management (multilatinas e IBOVESPA), Oracle Treasury Cloud Brazil com Oracle Cash Management, Kyriba Treasury Brazil (tesouraria cloud global), GTreasury Brazil (mid-market), Senior Sistemas Tesouraria, Coupa Treasury e Linx Bankline com iFood Bank Conector. API do Open Finance Brasil com certificado A1/A3 ICP-Brasil e DICT BACEN. Webhook PIX 24/7 e CNAB 240/400 da FEBRABAN (AEB Norma 43). Banco de dados de séries temporais (TimescaleDB ou InfluxDB) e plataforma de ML (TensorFlow, Prophet, ARIMA e LSTM Autoencoder). Substantive testing das Big-4 com exportação direta para Deloitte ASM, PwC Halo, EY Helix e KPMG Clara, com metadados de trilha de auditoria NBC TA 540, ICP-Brasil A1/A3 e DPIA da LGPD na ANPD. Integração do Fato Relevante da CVM Resolução 80/2022 com a Plataforma de Comunicações da CVM via API.

--- Agente de Checklist de Fechamento ---
> Orquestra o fechamento mensal como workflow estruturado com dependências, monitoramento de prazos, verificação de completude e protocolo automático.

O fechamento mensal não é um problema de contabilização. Cada lançamento, conciliação e consolidação individual é, por si só, gerenciável. O que estica o fechamento para seis, oito ou dez dias úteis é a coordenação entre essas etapas - quem espera quem, qual tarefa bloqueia a seguinte e onde há um atraso que ninguém percebeu ainda. O Agente de Checklist de Fechamento resolve exatamente esse problema de orquestração. Baseado em regras, sem lógica contábil própria, sem IA.

## A maioria das equipes financeiras precisa de mais de uma semana para o fechamento

Os números são claros: o APQC cifra a mediana do fechamento mensal intersetorial em 6,4 dias. Uma grande parte das equipes financeiras precisa regularmente de mais de seis dias úteis, apenas uma minoria consegue fechar em três dias ou menos.

A causa raramente está na complexidade das tarefas individuais. A maioria das equipes ainda trabalha no fechamento com checklists em planilhas, nas quais dependências entre tarefas não são mapeadas. Uma conciliação intercompany esquecida bloqueia a consolidação. Uma provisão atrasada trava a verificação de completude. O atraso só se torna visível quando o prazo já foi estourado.

## Orquestração supera automação isolada

Muitas empresas automatizam etapas individuais do fechamento - conciliações, lançamentos, provisões. Cada uma dessas etapas fica mais rápida. Mesmo assim, o processo total mal se encurta. Porque entre as ilhas automatizadas estão entregas manuais, sequências pouco claras e tempos de espera sem escalação.

A tendência em pesquisas com CFOs é clara: o foco se desloca da automação isolada para a orquestração de processos. Empresas que introduzem controle integrado relatam melhor capital de giro, riscos reduzidos e decisões mais rápidas. A alavanca decisiva não está na contabilização mais rápida, mas na eliminação do tempo morto entre as contabilizações.

Para o fechamento mensal, isso significa concretamente: enquanto nenhum sistema conhece e impõe a sequência de tarefas, o fechamento permanece tão lento quanto sua entrega manual mais lenta.

## Dez decisões baseadas em regras controlam todo o fluxo

O [Decision Layer](/br/decision-layer/) decompõe a orquestração do fechamento em dez etapas de decisão - todas no nível R (regras), sem participação de IA. Um cenário concreto torna a lógica tangível.

Sexta-feira à tarde, terceiro dia útil do fechamento. O agente verifica a cadeia de dependências: a conciliação intercompany da entidade DE03 ainda está como "aberta". A consolidação subsequente não pode iniciar. O conjunto de regras reconhece o bloqueio automaticamente, compara a data prevista de conclusão com a data atual e classifica a tarefa como atrasada. A matriz de escalação configurada entra em ação: primeiro a notificação vai ao responsável, após quatro horas sem mudança de status vai ao Head of Accounting.

Paralelamente, o agente rastreia o status de todas as outras tarefas. Etapas concluídas liberam suas tarefas dependentes subsequentes. A verificação de completude ao final compara as tarefas realizadas contra a lista de obrigatórias configurada. Se falta uma etapa, o fechamento permanece aberto - sem exceções, sem sobrescrita manual sem motivo documentado.

Decisivo: o agente não contabiliza nada, não calcula nada, não avalia nada. Controla exclusivamente a sequência e a completude. Essa limitação clara o torna robusto e auditável.

## O protocolo de fechamento surge como subproduto

Cada ciclo de fechamento gera um protocolo completo - não como tarefa adicional de documentação, mas como resultado automático da orquestração. Cada mudança de status, cada escalação, cada carimbo de tempo é registrado: quem concluiu qual tarefa quando, quais dependências foram verificadas, onde houve atraso.

Para auditores e governança interna, esse protocolo é a comprovação de um processo de fechamento ordenado conforme HGB parágrafo 243 (equivalente no Brasil às normas de escrituração contábil via SPED Contábil / Lei 8.846/94). Sem busca retroativa de e-mails e planilhas. Sem reconstrução de memória. O processo de fechamento se documenta sozinho enquanto roda.

Empresas que querem ir do fechamento de seis dias para dois ou três dias não precisam de um contador mais rápido. Precisam de um sistema que conheça as dependências entre 30, 50 ou 80 tarefas de fechamento, reconheça bloqueios em tempo real e envolva os responsáveis sem atraso. Exatamente isso é o que a orquestração baseada em regras do Decision Layer entrega.

--- Agente de Consolidação ---
> Agente executa consolidação integral alinhada Lei 6.404/76 art. 247-252, CPC 36 R3 IFRS 10, CPC 18 R2 Equivalência Patrimonial, CVM 80/2022 e NBC TA 600.

A consolidação de demonstrações financeiras no Brasil constitui um sistema regulatório multifacetado que combina seis áreas principais: a Lei 6.404/76 art. 247-252 (consolidação obrigatória para S/A com investidas diretas/indiretas e investimentos relevantes), junto à Lei 11.638/2007 e à Lei 11.941/2009, que alinharam o Brasil às IFRS após décadas de sistema próprio; o CPC 36 R3 (alinhado ao IFRS 10), com critério único de controle (poder, exposição a retornos variáveis e capacidade de afetar retornos); o CPC 18 R2 (alinhado ao IAS 28), com Método de Equivalência Patrimonial obrigatório para coligadas (influência significativa 20-50%) e joint ventures; o CPC 02 R2 (alinhado ao IAS 21), com conversão da moeda funcional e tratamento de hiperinflação (IAS 29) na Argentina; o CPC 01 R1 (alinhado ao IAS 36), com Goodwill Impairment Test anual e por indicadores; a CVM Resolução 80/2022 e a ICVM 480, com disclosure detalhado em ITR/DFP; a IN RFB 1.700/2017, com o Lucro Real consolidado fiscal de IRPJ/CSLL do grupo, somada à Lei 12.973/2014 art. 76-92 sobre a tributação automática dos lucros no exterior; e a NBC TA 600, com o substantive testing das Big-4 sobre perímetro, eliminações, Equivalência Patrimonial e Goodwill. Cada empresa brasileira com investidas precisa coordenar a consolidação determinística, a Equivalência Patrimonial, a conversão cambial, o Goodwill Impairment, o Lucro Real consolidado e a trilha de auditoria das Big-4.

## Lei 6.404/76 art. 247-252, CPC 36 R3, CPC 18 R2, CVM Resolução 80/2022 e NBC TA 600: cinco frentes regulatórias que exigem mecânica de consolidação determinística

A Lei 6.404/76 art. 247-252 obriga as sociedades anônimas com investidas diretas/indiretas e investimentos relevantes a apresentar demonstrações consolidadas anuais. A Lei 11.638/2007 e a Lei 11.941/2009 alinharam o Brasil às IFRS após décadas de sistema próprio - hoje as S/A listadas no Novo Mercado, no Nível 2 e no Bovespa Mais da B3 reportam IFRS via os CPCs do CFC. O CPC 36 R3 (alinhado ao IFRS 10) substituiu o CPC 36 R2 desde 2013 e definiu um novo critério único de controle: o investidor tem controle quando tem poder sobre a investida, exposição a retornos variáveis e capacidade de afetar os retornos pelo uso do poder - capturando entidades estruturadas SPE e acordos contratuais que conferem controle sem maioria acionária. O CPC 18 R2 (alinhado ao IAS 28) obriga o Método de Equivalência Patrimonial para coligadas (influência significativa 20-50%) e joint ventures (controle conjunto, CPC 19 R2). A NBC TA 600 obriga as Big-4 brasileiras (Deloitte, PwC, EY e KPMG) a fazer substantive testing do perímetro, das eliminações, da Equivalência Patrimonial e do Goodwill - cobrando de R$ 800 mil a 2,5 milhões por ano de um grupo médio da B3.

Casos célebres demonstram o impacto material: Americanas (2023, fraude de consolidação com fornecedores não divulgados de R$ 25 bilhões, com delisting e class action), IRB Brasil RE (2020, fraude de accruals de R$ 600 milhões e delisting do Novo Mercado), Petrobras (2014, accruals na Lava Jato e impairment de goodwill de R$ 21 bilhões em refinarias), Eletrobras (2017, accruals no exterior questionados por SEC e CVM), Vale (2019, impairment de Mariana e Brumadinho de R$ 7 bilhões) e Embraer (2020, impairment de R$ 1,7 bilhão pelo negócio frustrado com a Boeing). Em todos os casos, a falha na consolidação fidedigna, nas eliminações intragrupo completas, na Equivalência Patrimonial adequada e no Goodwill Impairment tempestivo contribuiu para o enforcement da CVM, class actions sob a Lei 6.404/76 art. 158, delisting na B3 e perda de confiança do buy-side (ANBIMA). Multas da CVM: até R$ 500 milhões, com responsabilidade dos administradores (Lei 6.404/76 art. 1.005).

## 16 pontos decisivos: treze determinísticos e três escalados a humanos

O Agente processa a consolidação das demonstrações financeiras por um pipeline de 16 pontos decisivos: treze classificações regulatórias determinísticas e três escalados a humanos (perímetro de consolidação, Goodwill Impairment e Purchase Price Allocation na primeira consolidação). Validação dos pacotes de reporte das subsidiárias: ETL dos ERPs do grupo (TOTVS Protheus, RM e Datasul; SAP S/4HANA com SAP Group Reporting; Oracle EPM com HFM e FCCS; Senior Sistemas com Senior Consolidação) reconciliados com os Blocos K, N e W da ECF da Receita Federal, com alinhamento de data de corte de no máximo 3 meses de defasagem e ajustes conforme o CPC 36 R3 art. 19. Mapeamento do plano de contas para IFRS e reconciliação entre Brazilian GAAP e IFRS (Lei 11.638/2007).

Conversão de moeda (CPC 02 R2, IAS 21): o Agente aplica regra diferenciada ao balanço (closing rate PTAX do BACEN na data do balanço), à DRE (average rate do período, com ajustes de lançamentos relevantes em data específica) e ao patrimônio (historical rate da data do lançamento original), com a variação cambial em Other Comprehensive Income (OCI). Para subsidiárias na Argentina, classificada como hiperinflacionária no IAS 29 desde 2018 (inflação acumulada acima de 100% nos últimos 3 anos), o Agente aplica a reexpressão monetária do IAS 29 antes da conversão do CPC 02 R2, usando os índices oficiais do INDEC (IPC e IPIM), com ganho ou perda monetária líquida na DRE e, então, conversão para BRL pela closing rate. Para grupos brasileiros com filiais na Argentina (Banco Itaú, Vale, Marfrig, JBS e Embraer), o impacto é material, com variação anual de R$ 100 a 500 milhões conforme o câmbio ARS/BRL e a inflação argentina de 40% a 200% ao ano.

Eliminações intragrupo (CPC 36 R3 art. 22) executadas deterministicamente: (1) Capital - patrimônio da subsidiária eliminado contra o valor do investimento da controladora; (2) Endividamento - saldos recíprocos de Contas a Receber/Pagar intercompany e Empréstimos Mútuos intragrupo; (3) Receitas/Despesas - vendas, serviços, royalties, juros e dividendos intragrupo; (4) Lucros não realizados - estoques e ativos imobilizados transferidos intragrupo (a margem só se realiza com terceiros externos ao grupo). A Equivalência Patrimonial (CPC 18 R2, IAS 28) é calculada para coligadas e joint ventures: ajuste do investimento pela participação no resultado, dividendos recebidos e variações patrimoniais proporcionais em OCI (reservas de reavaliação, variação cambial de conversão e ganhos/perdas atuariais do CPC 33 R1). Cálculo das Participações Não Controladoras (CPC 36 R3 art. 22-26), com apresentação separada do patrimônio e do resultado consolidado.

Exemplo concreto: grupo brasileiro listado no Novo Mercado da B3 (R$ 12 bilhões de receita consolidada, 22 subsidiárias em 11 países e transações intragrupo mensais de R$ 480 milhões). Consolidação do Q3 de 2026: perímetro de 18 controladas integrais e 4 coligadas por Equivalência Patrimonial. Eliminações: Capital de R$ 3,2 bilhões, Endividamento de R$ 850 milhões, Receitas/Despesas de R$ 380 milhões e Lucros não realizados em estoques de R$ 28 milhões. Equivalência Patrimonial das coligadas: ajuste de investimento de R$ 145 milhões. Conversão cambial: variação em OCI de R$ 220 milhões e reexpressão de hiperinflação da Argentina (IAS 29) de R$ 78 milhões. Goodwill Impairment Test: 5 cash-generating units, sem perdas de valor recuperável (todas com WACC adequado e crescimento na perpetuidade conservador). Lucro Real consolidado (IN RFB 1.700/2017) e Blocos K e N da ECF: IRPJ de R$ 245 milhões, CSLL de R$ 88 milhões e TBU sobre lucros no exterior de R$ 35 milhões. A documentação ITR/DFP da CVM Resolução 80/2022 é gerada em 1,5 dia útil, ante 5 dias manuais. O substantive testing NBC TA 600 das Big-4 cai de 110 para 32 horas no trimestre.

## Decisões fiscais-estratégicas permanecem como julgamento humano, com consequências no enforcement da CVM

A determinação do perímetro de consolidação (CPC 36 R3, IFRS 10) requer análise estrutural humana: avaliação de controle (poder, exposição a retornos variáveis e capacidade de afetar retornos), influência significativa (presunção de 20-50% de participação, CPC 18 R2) e controle conjunto (joint operations versus joint ventures, CPC 19 R2). Mudanças de participação, estruturas com SPE, entidades estruturadas e acordos contratuais com opções de compra in-the-money e direitos protetivos versus substantivos exigem julgamento do Controller, do CFO e do Comitê de Auditoria. O Goodwill Impairment Test (CPC 01 R1, IAS 36) requer julgamento estratégico: identificação das cash-generating units, premissas do DCF (taxa de desconto WACC, crescimento na perpetuidade e projeções de 5 anos) e comparação do Valor Recuperável (o maior entre o Valor Justo menos os Custos de Venda e o Valor em Uso) com o Valor Contábil. A primeira consolidação de aquisição (CPC 15 R1, IFRS 3) com Purchase Price Allocation requer a identificação de ativos intangíveis (marca, relacionamento com clientes, tecnologia e carteira de contratos), a avaliação a valor justo, a alocação do preço de aquisição e o cálculo do goodwill (Preço de Aquisição menos Patrimônio Líquido a Valor Justo) - decisão com impacto material no balanço.

Os disclosures ITR/DFP da CVM Resolução 80/2022 são gerados automaticamente conforme o CPC 36 R3 e o CPC 18 R2: perímetro de consolidação completo, métodos de consolidação, Equivalência Patrimonial de coligadas e joint ventures, Goodwill por cash-generating unit, variação cambial em OCI do CPC 02 R2, Participações Não Controladoras, transações intragrupo eliminadas e reconciliação entre Brazilian GAAP e IFRS. Trilha de auditoria das Big-4 sob a NBC TA 600: backup matemático das eliminações intragrupo, rationale do julgamento do perímetro, Equivalência Patrimonial reconciliada, Goodwill Impairment Test com sensibilidade das premissas do DCF, conversão cambial e hiperinflação do IAS 29 documentada, e integração dos Blocos K e N da ECF para a variação de IRPJ/CSLL do Lucro Real consolidado, certificada com ICP-Brasil A1/A3 e WORM imutável por 5 anos, sob a LGPD art. 7 IX (cumprimento de obrigação legal), sem DPIA na ANPD.

## Integração com TOTVS, SAP S/4HANA e Group Reporting, Oracle EPM com HFM e FCCS, OneStream e Lucanet Brasil, mais o substantive testing das Big-4

O Agente integra-se aos sistemas brasileiros de Performance Management via API REST e ETL: [TOTVS Protheus, RM e Datasul](https://www.totvs.com/) com módulo de Consolidação nativo (líder no Brasil, com mais de 50.000 clientes, Blocos K, N e W da ECF e integração com o LucaNet), [SAP S/4HANA Brasil com SAP Group Reporting](https://www.sap.com/) com Equivalência Patrimonial do CPC 18 R2, Goodwill Impairment do CPC 01 R1 e Currency Translation do CPC 02 R2 automatizados, [Oracle EPM Cloud](https://www.oracle.com/) com Hyperion Financial Management (HFM) e Financial Consolidation and Close Cloud Service (FCCS), [Anaplan Brazil](https://www.anaplan.com/) com Connected Planning para consolidação de multilatinas em multimoeda e multi-GAAP (IFRS e Brazilian GAAP), [OneStream XF](https://onestream.com/), plataforma CPM unificada com Financial Consolidation e Account Reconciliation nativos e perímetro IFRS 10, [Tagetik Wolters Kluwer](https://www.wolterskluwer.com/) CPM para consolidação multi-GAAP com Equivalência Patrimonial e Goodwill, Senior Sistemas com Senior Consolidação (mid-market brasileiro, com IFRS e CPC 36 R3), IBM Cognos Controller (consolidação, eliminação automática, minoritários e Goodwill Impairment), [BlackLine](https://www.blackline.com/) Account Reconciliation e Close Engine (líder em trilha de auditoria das Big-4 sob a NBC TA 600) e [Lucanet Brasil](https://www.lucanet.com/) (especialista em consolidação, IFRS e Equity Method). Câmbio PTAX do BACEN via API e cotações de fechamento de USD/EUR/CNY/ARS para a conversão do CPC 02 R2, com hedge accounting pelos CPC 38, 39 e 40. Integração com os índices do INDEC na Argentina (IPC e IPIM) para a reexpressão de hiperinflação do IAS 29. Substantive testing das Big-4 com exportação direta para Deloitte ASM, PwC Halo, EY Helix e KPMG Clara, com metadados de trilha de auditoria NBC TA 600 e ICP-Brasil A1/A3. Integração dos disclosures de consolidação ITR/DFP da CVM Resolução 80/2022 via API da Plataforma de Comunicações da CVM. Os Blocos K e N consolidados da ECF (RFB IN 1.700/2017) fazem a reconciliação cruzada de IRPJ/CSLL do grupo via API do SPED Fiscal.

--- Agente Compliance Contratual ---
> Compliance contratual brasileiro: due diligence Lei 12.846/2013, screening COAF/PLD-FT, validação LGPD art. 39, partes relacionadas CVM Resolução 80, integração CEIS/CNEP CGU - pipeline determinístico auditável.

Compliance contratual no Brasil opera sob um regime de responsabilidade objetiva único na América Latina. A Lei 12.846/2013 (Lei Anticorrupção) não exige prova de dolo ou culpa - basta o ato lesivo praticado em interesse ou benefício da pessoa jurídica para gerar responsabilização. A multa é de 0,1% a 20% do faturamento bruto do exercício anterior à instauração do PAR (Processo Administrativo de Responsabilização), sem teto absoluto e com piso vinculado à vantagem auferida. Soma-se a isso a Lei 14.133/2021 (Nova Lei de Licitações) com seu rol expandido de impedimentos no art. 14 e sanções no art. 156, a LGPD com obrigações específicas de DPA conforme art. 39, a CVM Resolução 80/2022 que obriga companhias abertas a divulgar contratos materiais com partes relacionadas como Fato Relevante, e a ABNT NBR ISO 37301:2021 que estabelece o padrão internacional de Sistemas de Gestão de Compliance reconhecido pela CGU.

## Multas de até 20% do faturamento, bloqueio de CND, suspensão de licitar por 6 anos e responsabilidade pessoal do CFO

Os números são severos no Brasil. Lei 12.846/2013 art. 6: multa de 0,1% a 20% do faturamento bruto do último exercício anterior à instauração do PAR, com publicação extraordinária da decisão condenatória, perdimento de bens, suspensão ou interdição parcial de atividade por até 2 anos, dissolução compulsória e proibição de receber incentivos fiscais por 1 a 5 anos. Lei 14.133/2021 art. 156: para licitações públicas, sanções administrativas cumulativas de advertência, multa, impedimento de licitar e contratar com a União por até 3 anos e declaração de inidoneidade por até 6 anos com inscrição em CEIS. CVM Resolução 80/2022 e ICVM 480/09 art. 24: a inadequação na divulgação de Fato Relevante por parte relacionada material gera multa da CVM de até R$ 50 milhões, responsabilidade administrativa pessoal do Diretor de Relações com Investidores e suspensão de exercício de cargo de administrador em S/A por 5 a 20 anos. ANPD, pela LGPD: multa de até 2% do faturamento BR, limitada a R$ 50 milhões, com bloqueio do tratamento de dados.

A combinação é multiplicativa e cumulativa. Uma empresa que assina contrato com fornecedor inscrito no CEIS sem detecção pode enfrentar simultaneamente sanção da CGU em PAR (Lei 12.846/2013), multa da CVM por inadequação de Fato Relevante se a operação for material, responsabilização administrativa do administrador signatário com suspensão de exercício de cargo e processo criminal do MPF (Lei 7.492/86) com pena de 3 a 12 anos para o agente individual envolvido. O custo médio de um caso de compliance failure no Brasil em 2024-2025, segundo levantamento da PwC Brasil e da Transparência Internacional Brasil, ficou em R$ 23 milhões considerando multas, honorários jurídicos, custos de remediação e impacto reputacional - sem contar a queda de 8-15% no preço da ação para empresas listadas na B3 conforme estudos acadêmicos do INSPER e da FGV.

## 15 etapas determinísticas, da classificação contratual à notificação CVM

O Agente roda 15 verificações sequenciais antes de qualquer assinatura ICP-Brasil ser aplicada, cada uma com decider explícito (R determinístico, A assistido, H humano) e fundamentação legal citada. A primeira etapa classifica o tipo de contrato - definir se a contraparte é privada, ME/EPP sob LC 123/2006, autoridade pública sob Lei 14.133/2021 ou parte relacionada sob Lei 6.404/76 art. 245 muda toda a cascata subsequente de verificações.

As etapas 2 a 8 fazem a due diligence de habilitação. A etapa 2 valida o CNPJ e o Quadro de Sócios e Administradores via API SERPRO Datavalid contra a Receita Federal. A etapa 3 faz o screening PLD-FT contra as listas COAF, OFAC SDN, ONU consolidada e sanções da UE, com integração à Refinitiv World-Check. A etapa 4 consulta CEIS e CNEP no Portal da Transparência da CGU em tempo real - polling automático antes de cada assinatura, com latência inferior a 2 segundos. A etapa 5 computa o score de risco geográfico-setorial com base no CNAE e na UF da contraparte, considerando o histórico de penalizações por setor nos últimos 5 anos. A etapa 6 detecta partes relacionadas pelo cruzamento de QSA contra a base interna de PEP, administradores e familiares próximos até 2º grau. A etapa 7 valida CND-RFB, CRF-FGTS, CNDT e estaduais com data de validade superior à data prevista de pagamento. A etapa 8 aplica automaticamente a margem de preferência ME/EPP quando a contraparte é enquadrada no Simples Nacional.

As etapas 9 a 12 analisam o conteúdo do próprio contrato. A etapa 9 verifica a presença das cláusulas obrigatórias de LGPD (DPA com base legal, finalidade, retenção, subprocessadores, transferências internacionais e cláusulas de incidente). A etapa 10 verifica a cláusula anticorrupção, referenciando Lei 12.846/2013, FCPA e UK Bribery Act 2010 quando há exposição internacional, além do Código de Conduta e do direito de auditoria. A etapa 11 confronta o valor do contrato com a alçada interna do signatário, definida no estatuto social, na procuração específica e na matriz de competências. A etapa 12 aplica heurística de detecção de red flags financeiros - padrões atípicos como pagamento offshore, antecipação acima de 50% sem garantia, conta em paraíso fiscal listado pela RFB IN 1.037/2010, intermediário sem nexo, parcelamento desproporcional ou frequência atípica de transações disparam flag automático.

A etapa 13 sela o Decision-Record com hash SHA-256, timestamp UTC-3 e assinatura digital ICP-Brasil A1 ou A3 conforme a MP 2.200-2/2001 e a Lei 14.063/2020. A etapa 14 roteia para revisão humana do Compliance Officer e do Diretor Jurídico, antes da assinatura, os contratos com red flag, com valor acima da alçada da IA (acima de R$ 5M ou de 0,5% da receita) ou com parte relacionada - decider H. A etapa 15 detecta automaticamente quando o contrato configura Fato Relevante (CVM Resolução 80/2022) - operações com partes relacionadas acima de 5% do ativo total ou de R$ 50 milhões disparam alerta ao DRI para divulgação no IPE em até 1 dia útil via Sistema Empresas.NET.

## Plausibilidade verificada por dados externos e cruzamento sistêmico

A plausibilidade não vem só do contrato em si - vem do cruzamento sistêmico com fontes externas. CNPJ deve estar ativo na RFB (não baixado, não inapto, não suspenso), e o QSA precisa ser compatível com o procurador signatário (ou haver procuração específica registrada no contrato). CNDs precisam ter validade superior à data prevista de pagamento. Faturamento declarado pela contraparte para enquadramento ME/EPP precisa ser compatível com o Simples Nacional. Endereço de execução precisa ser plausível dado o objeto contratual. Quando há incompatibilidade entre cadastro e proposta, o Agente bloqueia automaticamente até resolução manual.

Para companhias abertas, a plausibilidade ainda inclui análise de impacto material. O sistema calcula automaticamente o quociente entre o valor do contrato e o ativo total da última ITR ou DFP publicada na CVM. Se exceder 5%, ou se a contraparte for parte relacionada com valor acima de R$ 50 milhões, dispara o workflow de Fato Relevante: pré-validação pela área jurídica, pelo Comitê de Auditoria e pelo DRI, com envio ao IPE/CVM via Sistema Empresas.NET com certificado digital ICP-Brasil A1/A3. O parecer do auditor independente sobre operações com partes relacionadas (NBC TA 550) também é considerado em paralelo.

## Edge-Cases brasileiros: licitações estaduais, contratos no exterior, consórcios ME/EPP

Edge-cases brasileiros exigem regras específicas. Licitações estaduais e municipais não seguem cegamente a Lei 14.133/2021 - cada ente subnacional pode ter regulamentos próprios em decreto estadual ou lei orgânica municipal. O Agente lê o edital específico para identificar regras locais aplicáveis e ajusta os benefícios LC 123/2006 conforme regulamentação do ente licitante.

Contratos no exterior por subsidiárias brasileiras de companhia listada precisam de análise tripartite: a lei local do país de execução, a Lei 12.846/2013 brasileira (extraterritorialidade do art. 28), o FCPA quando há nexo com o sistema bancário americano ou listagem ADR/NYSE e o UK Bribery Act 2010 quando há nexo com o Reino Unido. Acordos de leniência simultâneos com CGU e DOJ FCPA são possíveis, com coordenação via Working Group de leniência internacional.

Consórcios formados por ME/EPP (LC 123/2006 art. 56) são edge-case frequente: adicional de 30% no faturamento limite (R$ 6,24M no conjunto), com requisitos formais (registro na Junta Comercial, atribuições definidas, solidariedade expressa e empresa líder). O Agente verifica a documentação completa antes de aplicar a margem. A falsa declaração de porte tipifica crime (Lei 14.133/2021 art. 337-F) e improbidade (Lei 8.429/92).

## Integração com TOTVS Protheus, SAP GRC e Oracle Risk Cloud e APIs públicas

O TOTVS Protheus tem o módulo SIGAGCT integrado a CPCs, Receita Federal, COAF e CGU via API REST ProtheusJob, com RM Fluig para o Workflow. O SAP S/4HANA Brazil oferece SAP GRC Process Control, Risk Management e SAP Ariba para sourcing - o Agente integra-se via OData services e atualiza as tabelas de Compliance Records em tempo real. O Oracle ERP Cloud Brazil oferece Risk Management Cloud e Contract Management via REST APIs no Oracle Integration Cloud.

A Senior Sistemas (forte em Vale, Suzano, Braskem e Klabin) cobre o fluxo completo com integração nativa às APIs da CGU, do COAF e da RFB. A Mastermaq Domínio é a opção para escritórios contábeis em PMEs no Lucro Presumido e no Simples Nacional. O Microsoft Dynamics 365 Finance é usado por médias empresas em transformação digital. A Apdata atende a média empresa em modelo SaaS.

A camada de governança LGPD obriga a designação de DPO, com canal com a ANPD documentado. O Agente preserva os logs com anonimização de PII conforme a Resolução CD/ANPD 2/2022, criptografia AES-256 e rotação trimestral de chaves. A auditoria interna trimestral segue a NBC TA 240 (Fraude), a NBC TA 315 e a ABNT NBR ISO 37301. Para as listadas na B3, o parecer anual da Big-4 ou das Médias sobre os controles internos de compliance complementa o sistema - o parecer com ressalva torna a empresa inelegível para emissão pública até a reapresentação corrigida.

O resultado é a redução de 8-12 dias úteis de due diligence manual para 2-4 horas de processamento determinístico (15-20 minutos para contratos rotineiros abaixo de R$ 1M com contraparte recorrente), com Decision-Records completos para fins de PAR ou acordo de leniência. Sem IA generativa nas decisões de bloqueio ou aprovação contratual e com fundamentação legal explícita - protegendo o Compliance Officer, o CFO e o DRI de imputação pessoal.

--- Agente de Notas de Crédito/Estorno ---
> Classifica documentos como nota de crédito ou estorno, identifica fatura de referência.

Notas de crédito e estornos classificados incorretamente estão entre os achados fiscais mais frequentes em auditorias na Alemanha. A causa é quase sempre a mesma: fornecedores usam os termos de forma errada, o ERP adota a denominação sem verificação, e a contabilidade lança com base em uma classe de documento incorreta. O Agente de Notas de Crédito/Estorno elimina esse risco classificando cada documento de correção recebido pelo conteúdo - independentemente do que está escrito no documento.

## Correções de imposto custam bilhões em auditorias fiscais

A dimensão do problema é mensurável. Em 2024, as autoridades fiscais alemãs obtiveram apenas com auditorias especiais de imposto sobre vendas um resultado adicional de 1,63 bilhão de euros (USD 1,78 bilhão) em 63.733 auditorias (Fonte: BMF, publicado junho 2025). São em média cerca de 25.600 euros por auditoria. O imposto sobre vendas representou 12,8 por cento do resultado total de auditorias de 10,9 bilhões de euros.

A confusão entre nota de crédito e estorno alimenta esses números. Uma nota de crédito no sentido do parágrafo 14 UStG (padrão contábil alemão GoBD (padrão GoBD alemão de arquivamento fiscal)) é um documento de faturamento autônomo emitido pelo destinatário do serviço. Um estorno corrige uma fatura incorreta do prestador conforme parágrafo 17 UStG. Ambos os tipos de documento têm consequências jurídicas diferentes para a dedução do imposto de entrada. Quem os confunde arrisca que a autoridade fiscal negue a dedução - retroativamente, com juros.

## Fornecedores usam os termos errados - e o ERP propaga o erro

O problema não começa na própria contabilidade. Começa no fornecedor. Na prática, fornecedores regularmente escrevem "nota de crédito" em documentos que são fiscalmente estornos. A legislação alemã esclareceu que o termo coloquial "nota de crédito" não é uma nota de crédito no sentido fiscal. Mas muitos fornecedores nunca atualizaram seus modelos de documento.

Um cenário concreto: uma empresa química recebe mensalmente cerca de 200 documentos de correção de 80 fornecedores. Aproximadamente 35 por cento desses documentos carregam a denominação "nota de crédito", embora sejam conteudisticamente estornos. O colaborador na contabilidade de fornecedores precisa verificar em cada documento individual as características de conteúdo, encontrar a fatura de referência e determinar o tratamento fiscal correto. No processamento manual, a taxa de erro para processamento de faturas gira em torno de 2 por cento (Fonte: IOFM/Ardent Partners AP Benchmark Report). Para documentos de correção que já chegam com denominação incorreta, a taxa é comprovadamente bem mais alta.

## Classificação por conteúdo substitui o cabeçalho do documento

O [Decision Layer](/br/decision-layer/) resolve esse problema com uma separação clara: a primeira decisão - nota de crédito ou estorno - é a única que utiliza suporte de IA. O modelo de linguagem analisa o conteúdo do documento, não o cabeçalho. Verifica quem emitiu o documento, se uma fatura original está sendo corrigida e quais consequências jurídicas o conteúdo gera.

Essa classificação é deliberadamente desenhada como nível 1 no Decision Layer: assistida por IA com possibilidade de verificação humana. O auditor pode rastrear cada decisão de classificação individual porque o agente documenta com base em quais características classificou o documento. As seis etapas seguintes - identificar fatura de referência, validar valor, calcular correção de imposto, criar contralançamento, garantir vinculação conforme SPED Contábil / padrão contábil alemão GoBD e verificar tratamento fiscal - rodam completamente baseadas em regras como nível 2, sem participação de IA.

## A cadeia documental se torna comprovação de auditoria

Conformidade regulatória não surge apenas de um sistema de arquivamento. Surge da vinculação completa de cada documento de correção com sua fatura original. O agente estabelece essa vinculação em cada processamento - via comparação de números de referência e, quando o fornecedor não fornece referência, via matching aproximado por valor, data e fornecedor.

Na auditoria fiscal, a diferença fica evidente: em vez de atribuir manualmente notas de crédito e estornos individuais aos seus documentos de origem, existe um dossiê de decisão completo. Para cada documento é rastreável por que foi classificado como nota de crédito ou estorno, qual fatura original é afetada, como a correção de imposto foi calculada e como o contralançamento foi gerado. Isso reduz o esforço de auditoria - tanto para a própria equipe quanto para o auditor.

--- Agente de Depreciação ---
> Determina método e vida útil pela tabela BMF, calcula valores mensais, verifica depreciação especial para bens digitais e cria o lançamento contábil.

Depreciações estão entre os processos mais rigorosamente regulamentados na contabilidade financeira. Método, vida útil, base de cálculo, lançamento contábil - cada etapa é definida por lei, tabela ou opção de método. Mesmo assim, a contabilidade de ativos na maioria das empresas ainda consome capacidade manual significativa. O motivo: colaboradores navegam entre tabelas de depreciação, limites de bens de baixo valor e regras especiais, sem que uma lógica central assegure a consistência. Isso muda quando um agente baseado em regras assume toda a cadeia de depreciação.

## Auditores corrigem erros de depreciação que não precisariam acontecer

As auditorias fiscais alemãs geraram em 2024 um resultado adicional de 10,9 bilhões de euros (USD 11,9 bilhões) - com apenas 140.764 empresas auditadas de 8,8 milhões no cadastro (BMF, novembro 2025). Depreciações são um campo padrão de auditoria porque erros típicos se propagam por todo o espelho de ativos: vidas úteis atribuídas incorretamente, limites de bens de baixo valor ignorados, depreciações especiais para bens digitais não aplicadas.

As fontes de erro não são lacunas de conhecimento. Surgem porque um colaborador com 2.000 ou 5.000 ativos não consulta para cada um individualmente a classe correta na tabela, não confere a vida útil e não verifica o limite para bens de baixo valor. Volume gera erros - não complexidade.

## Cada etapa de decisão segue um conjunto de regras sem margem de interpretação

O [Decision Layer](/br/decision-layer/) decompõe o cálculo de depreciação em sete etapas. Todas as sete são completamente baseadas em regras (Horizonte 1 - sem IA, sem julgamento humano no caso individual):

O método de depreciação resulta dos dados cadastrais do ativo e da opção fiscal exercida. A vida útil consta na tabela de depreciação oficial (BMF na Alemanha; no Brasil, o equivalente via IN RFB e Decreto 9.580/2018). A base de cálculo se calcula conforme HGB parágrafo 255 a partir dos custos de aquisição ou produção. O valor mensal de depreciação é um quociente. A elegibilidade para depreciação especial de bens digitais é uma verificação de limite. O lançamento contábil segue uma lógica fixa de contabilização. A verificação de bens de baixo valor compara o valor líquido com o limite legal.

Nenhuma dessas etapas exige uma estimativa, uma avaliação ou uma ponderação. Isso torna o processo de depreciação o candidato ideal para automação no nível mais baixo do Decision Layer.

## Um fabricante de máquinas com 3.200 ativos mostra a alavanca

Um fabricante de máquinas de médio porte administra um acervo de 3.200 posições - equipamentos de produção, hardware de TI, frota, mobiliário. Todo mês, a contabilidade de ativos calcula para cada bem ativo o valor de depreciação e cria o lançamento contábil. Para novos registros, soma-se a avaliação inicial: determinar classe de ativo, consultar tabela de depreciação, verificar limite de bens de baixo valor, definir método.

Sem agente, um colaborador faz isso no ERP - ativo por ativo, campo por campo. Com um tempo médio de processamento de três minutos por novo registro e 40 registros por mês, são duas horas apenas de trabalho rotineiro sem qualquer margem de julgamento. As execuções mensais de depreciação vêm por cima.

Com o Agente de Depreciação, o sistema lê a classe de ativo do cadastro, consulta a vida útil na tabela centralmente registrada, calcula o valor mensal, verifica o limite de bens de baixo valor e cria o lançamento contábil. Todo o processo roda em segundos em vez de minutos - e cada cálculo individual está documentado com a regra aplicada e a versão da tabela.

## A tabela de depreciação se torna infraestrutura centralmente versionada

O verdadeiro valor não está na aceleração de lançamentos individuais. Está na infraestrutura que surge no processo. A tabela de depreciação existe na maioria das empresas como PDF ou como tabela de dados cadastrais mantida manualmente no ERP. Quando a autoridade fiscal atualiza a tabela - como recentemente na reavaliação da vida útil de hardware e software - alguém precisa replicar a alteração manualmente.

No Decision Layer, a tabela se torna um conjunto de regras centralmente versionado. Uma atualização surte efeito imediato em todos os novos cálculos. A versão anterior permanece documentada para ativos existentes. E na auditoria fiscal, é possível rastrear para cada bem individual qual versão da tabela vigorava no momento da avaliação inicial.

Essa infraestrutura não serve apenas ao Agente de Depreciação. O Agente de Entrada de Ativos, o Agente de Inventário e o Agente de Demonstração Anual acessam a mesma tabela versionada. A lógica de verificação de bens de baixo valor é reutilizada pelo Agente de Contabilização. O que começa como um processo de depreciação individual se torna o alicerce de toda a contabilidade de ativos.

## A comprovação de auditoria surge como subproduto

Para o CFO, a questão decisiva não é se o cálculo de depreciação roda mais rápido. A questão decisiva é se ele resiste à próxima auditoria fiscal. Com uma taxa de auditoria de 29,6 por cento para grandes empresas (BMF 2024), isso não é uma consideração teórica.

Um agente baseado em regras gera a comprovação de auditoria como subproduto de cada cálculo: método aplicado, versão da tabela, custos de aquisição, caminho de cálculo, verificação de bens de baixo valor, verificação de depreciação especial. O espelho de ativos para a demonstração anual se constrói a partir dessas decisões individuais documentadas - não a partir de uma reconstrução posterior.

--- Agente de Cobrança ---
> Cobrança extrajudicial e judicial em cadeia auditável: do aging à inscrição SERASA e ao protesto em cartório (Lei 9.492/97), com PCLD e LGPD.

Cobrança no Brasil é um pipeline jurídico-financeiro com seis bases legais simultâneas: o Código Civil (Lei 10.406/2002) define mora e juros (art. 389-407), o Código de Defesa do Consumidor (Lei 8.078/90) limita meios de cobrança ao consumidor final, a Lei do Protesto (Lei 9.492/97) regula a fase cartorial, a Resolução BACEN 4.557/2017 e a Lei 9.430/96 disciplinam Provisão para Créditos de Liquidação Duvidosa (PCLD) e dedução fiscal, a LGPD (Lei 13.709/2018) governa o tratamento de dados pessoais nas consultas SERASA/SPC/Boa Vista e na comunicação ao devedor, e o Código de Processo Civil (Lei 13.105/2015) rege Ação Monitória (art. 700) e Execução (art. 784). Cada etapa do pipeline tem prazo, base legal e formato específicos - errar uma vírgula no aviso prévio CDC art. 43 §2 já basta para gerar dano moral indenizável conforme Súmula STJ 385.

## PCLD subdimensionada gera glosa fiscal de 75-150% e bloqueio de CND em fiscalização Receita Federal

A Provisão para Créditos de Liquidação Duvidosa (PCLD) é simultaneamente um requisito contábil (CPC + BACEN Resolução 4.557/2017 para instituições financeiras) e uma conta de resultado dedutível para IRPJ e CSLL conforme Lei 9.430/96 art. 9-14. Empresas que classificam mal o aging dos recebíveis ou esquecem de aplicar a regra dos R$ 5.000 / R$ 30.000 acabam reconhecendo perdas indevidamente - e a Receita Federal glosa a dedução em fiscalização, aplicando multa de 75% a 150% do imposto não pago (art. 44 Lei 9.430/96), juros Selic + 1% ao mês e bloqueio de Certidão Negativa de Débitos (CND) que impede participação em licitações públicas, financiamentos BNDES/FINEP e renovação de credenciamentos junto à Caixa, Banco do Brasil e bancos comerciais.

Para uma empresa de médio porte com R$ 80 milhões de carteira a receber e DSO típico de 52 dias na indústria brasileira, uma PCLD subdimensionada de R$ 1,2 milhão gera glosa fiscal de R$ 408 mil (IRPJ 25% + CSLL 9%) com multa de 75% sobre o imposto = R$ 306 mil, totalizando R$ 714 mil de exposição fiscal. Em fiscalização agressiva (qualificação como sonegação dolosa art. 44 §1), a multa sobe para 150%, totalizando R$ 1,02 milhão. Soma-se a isso o risco PROCON (multas de R$ 200 a R$ 9 milhões para práticas abusivas de cobrança CDC art. 71), o risco ANPD (até 2% do faturamento Brasil ou R$ 50 milhões para violação LGPD), e o risco TJ (dano moral presumido R$ 5-15 mil por inscrição SERASA irregular conforme Súmula STJ 385).

## A cobrança brasileira percorre 14 etapas determinísticas, não 8

Diferente do modelo alemão padrão (8 etapas) ou do espanhol (10 etapas), a cobrança brasileira CLT-compliant exige 14 etapas determinísticas porque o sistema jurídico-financeiro tem mais camadas regulatórias: identificação do título vencido (NF-e, Boleto, Duplicata mercantil Lei 5.474/68), classificação de aging em quatro faixas (1-30 / 31-60 / 61-90 / 90+ dias), verificação de bloqueio contratual (reclamação aberta, nota de crédito pendente), diferenciação B2B vs B2C (CDC ou Código Civil), cálculo de juros (Selic CTN art. 161 ou contratual com teto Lei da Usura), envio de notificação amigável, aviso prévio CDC art. 43 §2 com 10 dias de antecedência, inscrição em SERASA/SPC/Boa Vista, encaminhamento para Cartório de Protesto via CRA, cálculo de PCLD em quatro faixas BACEN (50% em 90+ dias, 100% em 360+ dias), verificação de prescrição (3 anos duplicata, 6 meses cheque, 5 anos cobrança ordinária), reconhecimento de perda dedutível IRPJ-CSLL conforme Lei 9.430/96, conciliação de pagamentos PIX/TED/Boleto via CNAB 240/400 FEBRABAN e decisão estratégica de ajuizamento (Ação Monitória CPC art. 700 ou Execução CPC art. 784).

Um cenário concreto: indústria com 8.000 títulos a receber em aberto, R$ 80 milhões de carteira, 65% B2B (CNPJ-CNPJ regido pelo Código Civil) e 35% B2C (varejo a consumidor regido pelo CDC). Em uma sexta-feira semanal, o Agente identifica 1.200 títulos vencidos há mais de 1 dia útil, classifica cada um no aging correto, separa B2B de B2C aplicando regras distintas de juros e multa, verifica 80 bloqueios contratuais (reclamações abertas), envia 350 cartas-cobrança amigáveis (1ª notificação), envia 280 avisos prévios CDC art. 43 §2 (10 dias antes da inscrição em SERASA), inscreve 190 devedores em SERASA/SPC/Boa Vista após o prazo do aviso, encaminha 45 títulos para Cartório de Protesto via CRA, calcula PCLD para 220 títulos em aging 90+ dias, e identifica 12 títulos próximos da prescrição (sinalizando para protesto urgente como interruptivo da prescrição CC art. 202 III).

No [Decision Layer](/br/decision-layer/), 13 das 14 etapas são decisões baseadas em regras (nível R). A única decisão humana é o ajuizamento de Ação Monitória ou Execução, porque envolve avaliação estratégica de custos sucumbenciais (CPC art. 85, honorários advocatícios típicos de 10-20% do valor da causa), valor da causa, impacto em relação cliente e probabilidade de recuperação. Não há ponto em que um analista de cobrança precise tomar decisão discricionária na fase extrajudicial - cada cálculo é a aplicação da CDC, do Código Civil, da Lei 9.492/97, da Lei 9.430/96 ou da BACEN Resolução 4.557/2017.

## Conciliação prévia ao envio captura pagamentos PIX e bloqueia cobrança indevida

Cobrança automatizada sem conciliação é receita para reclamação PROCON e ação por dano moral. O cliente paga via PIX na quinta-feira às 18h47, o Agente envia carta-cobrança na sexta às 7h sem ter recebido o arquivo de retorno CNAB 240 do banco - o cliente recebe cobrança de valor já pago, abre reclamação no PROCON, eventualmente ingressa com ação de dano moral. A Súmula STJ 388 reconhece dano moral em cobrança indevida quando há demonstração de constrangimento, com indenizações típicas de R$ 3.000 a R$ 10.000.

Por isso, a 13ª etapa de decisão é conciliação prévia obrigatória ANTES de qualquer envio. O Agente busca o arquivo CNAB 240/400 FEBRABAN do dia anterior, integra notificações PIX via Open Finance BACEN (DICT - Diretório de Identificadores de Contas Transacionais), cruza pagamentos por CPF/CNPJ + valor + data e baixa automaticamente os títulos quitados antes de gerar qualquer comunicação. Pagamentos parciais são reconhecidos com rateio proporcional sobre principal e juros, conforme imputação de pagamento CC art. 354. Apenas títulos efetivamente em aberto após conciliação seguem para o pipeline de cobrança.

## Prescrição, alienação fiduciária e protesto exigem precisão sem margem

Casos especiais como prescrição (CC art. 206), alienação fiduciária (Decreto-Lei 911/69) e protesto cartorial (Lei 9.492/97) parecem complexos, mas são completamente determinados por lei brasileira. A duplicata mercantil prescreve em 3 anos do vencimento (CC art. 206 §3 VIII), o cheque em 6 meses após o prazo de apresentação (Lei 7.357/85 art. 59), a cobrança ordinária civil em 5 anos (CC art. 206 §5 I). O protesto cartorial é causa interruptiva da prescrição (CC art. 202 III), reiniciando o prazo - daí sua importância estratégica para títulos próximos do prazo prescricional.

Em alienação fiduciária (financiamento de veículo, máquina ou imóvel), aplica-se Decreto-Lei 911/69 com procedimento próprio: notificação extrajudicial via cartório constituindo o devedor em mora, ajuizamento de Busca e Apreensão (após 60 dias de inadimplência típica), liminar de apreensão do bem, venda extrajudicial com prestação de contas. O Agente identifica automaticamente contratos com cláusula de alienação fiduciária e roteia para o pipeline específico, em vez de seguir cobrança comum. Cada cálculo é documentado e imediatamente rastreável para fiscalização BACEN, auditoria Receita Federal ou perícia judicial em ação revisional consumerista.

## Integração com ecossistema brasileiro: TOTVS, SAP, Senior, SERASA, cartórios

A lógica do Agente conecta-se aos principais sistemas de gestão financeira do mercado brasileiro via API: [TOTVS Protheus](https://www.totvs.com/) e TOTVS RM (líderes em médias e grandes empresas com módulo de Contas a Receber e aging report), SAP S/4HANA Brazil Localization (multinationals e IBOVESPA), [Senior Sistemas](https://www.senior.com.br/) (forte em indústria), Oracle ERP Cloud Brazil, Apdata e Mastermaq Domínio (escritórios contábeis e médias empresas). A consulta e inscrição em cadastros restritivos usa API SERASA Experian, SPC Brasil (CNDL) e Boa Vista Serviços (Equifax). O encaminhamento para protesto usa CRA - Central de Remessa de Arquivos do IEPTB (Instituto de Estudos de Protesto de Títulos do Brasil) ou plataformas estaduais (CENPROT, CRA-SP, CRA-RJ). A conciliação bancária usa CNAB 240/400 FEBRABAN e Open Finance BACEN para PIX em tempo real. Para empresas com matriz na Europa (Volkswagen, Renault, BMW, Stellantis, Bosch com unidades brasileiras), o Agente também gera relatórios paralelos compatíveis com IFRS 9 (Financial Instruments) para consolidação na sede - mantendo a operação local CDC-compliant e o reporting parental sob padrões internacionais.

--- Agente Despesas de Representação ---
> Despesas de representação segundo Decreto-Lei 1.598/77 art. 13 §1 inciso II: verificação de dados obrigatórios do comprovante, limite de dedutibilidade do imposto de renda e tratamento de IRRF.

Comprovantes de representação não fracassam na auditoria fiscal por valores incorretos. Fracassam por dados obrigatórios ausentes - um erro formal que anula completamente a dedução da despesa operacional. Com 10,9 bilhões de euros (USD 11,9 bilhões) de resultado adicional de auditorias em 2024 (Fonte: BMF, novembro 2025), despesas de representação estão entre as posições que auditores examinam sistematicamente. Cada comprovante sem dados completos é um achado.

## Erros formais anulam toda a dedução de despesas operacionais

A aritmética é simples: 70 por cento dedutível, 30 por cento não - conforme parágrafo 4, inciso 5, no. 2 da EStG (legislação fiscal alemã). Nisso ninguém fracassa. O problema está nos cinco dados obrigatórios: local, data, participantes, motivo comercial e valor. Se falta um deles, a autoridade fiscal não cancela 30 por cento - cancela tudo. Local e data constam no recibo do restaurante. Nos participantes e motivo a situação fica crítica. Na prática, o que falta mais frequentemente é uma lista completa de participantes ou o motivo comercial está formulado de forma tão vaga - "jantar de negócios" sem mais detalhes - que não é reconhecido fiscalmente.

Um cenário concreto: um diretor comercial recebe quatro clientes após uma apresentação de produto. O recibo de 480 euros (USD 523) está correto, o restaurante tem todos os dados no cupom fiscal. Mas no comprovante de representação, no campo de motivo consta apenas "reunião com cliente" e falta um nome na lista de participantes. Em uma auditoria fiscal três anos depois, 480 euros de despesa operacional são cancelados - não porque o valor era inadequado, mas porque duas linhas estavam incompletas.

## Regulamentação de 2025 torna os requisitos mais rigorosos

Com o comunicado do Ministério das Finanças alemão de 19 de novembro de 2025, a administração fiscal precisou os requisitos de comprovação para despesas de representação. Restaurantes com sistema de caixa eletrônico devem emitir recibos eletronicamente e protegê-los com um dispositivo de segurança técnica certificado (TSE). Recibos manuscritos ou impressões simples sem identificação TSE não são mais aceitos. Para empresas, isso significa: mesmo um comprovante de representação correto em conteúdo pode fracassar se o recibo de restaurante subjacente não atender aos novos requisitos formais. Um recibo conforme é reconhecível pelo número de transação, número de série do sistema de caixa ou QR code impresso.

## Nove etapas de decisão entre comprovante e lançamento

O [Decision Layer](/br/decision-layer/) decompõe a verificação de comprovantes de representação em nove etapas com atribuição clara: quem decide - regras, IA ou ser humano?

A classificação do comprovante reconhece via LLM se realmente se trata de um comprovante de representação. Depois, o conjunto de regras verifica deterministicamente os cinco dados obrigatórios e a completude da lista de participantes. São perguntas binárias - presente ou ausente. Aqui não há margem de julgamento nem motivo para intervenção humana.

A plausibilidade do motivo comercial é avaliada por um LLM. "Reunião de projeto digitalização logística com empresa X" é compreensível. "Refeição" não é. O modelo reconhece padrões e solicita complementação ao emissor quando os dados são insuficientes - antes que o comprovante chegue à contabilidade.

Dedutibilidade (divisão 70/30), dedução de imposto de entrada conforme parágrafo 15 UStG e contabilização rodam baseados em regras. O arquivamento conforme SPED Contábil / padrão contábil alemão GoBD (padrão GoBD alemão de arquivamento fiscal) com carimbo de tempo encerra o processo. Todas as nove etapas estão documentadas e rastreáveis para uma futura auditoria fiscal.

## Razoabilidade permanece uma decisão humana

Uma etapa de decisão deliberadamente não é assumida por nenhum algoritmo: a verificação de razoabilidade. Se 120 euros por pessoa em um jantar de negócios com três clientes é razoável depende de setor, contexto e relação comercial. Um jantar no âmbito de uma negociação contratual segue outros parâmetros do que um almoço após uma primeira conversa. O agente fornece ao decisor os fatos - valor por pessoa, comparação com valores históricos, relação com o volume de negócios. A aprovação ou escalação cabe ao ser humano.

Essa delimitação não é um déficit técnico. É governança. Um agente de comprovantes de representação que julgasse autonomamente sobre razoabilidade estaria automatizando decisões discricionárias que, em caso de dúvida, um auditor fiscal questionará. A responsabilidade permanece onde pertence.

--- Agente de Relatório ESG ---
> Relatório ESG brasileiro determinístico conforme CVM 193/2023 e IFRS S1/S2 ISSB, pronto para asseguramento ISAE 3000 e sem risco de multas da CVM.

O relatório ESG no Brasil opera sob um regime regulatório multicamadas em rápida evolução, que combina Sustentabilidade ISSB (CVM Resolução 193/2023, IFRS S1, IFRS S2 e TCFD), Mercado de Capitais (CVM Resolução 80/2022, 14/2020 e 44/2021 e Lei 6.404/76 com a Reforma 14.195/2021), Setorial Ambiental (Lei 9.605/98, Lei 12.305/2010, IBAMA e CONAMA), Energético (ANEEL Resolução Normativa 1.000/2021, Lei 14.300/2022 e Lei 14.299/2022 do RenovaBio), Prudencial (Resolução CMN 4.945/2021 do PRSAC e Circular BACEN 4.073/2022 do GRSAC) e Auditoria (NBC TO 3000 do CFC, IBRACON CTA 19 e NBC TG 09). O regime obriga as companhias categoria A com receita acima de R$ 500 milhões e ativo acima de R$ 240 milhões a adotarem o IFRS S1/S2 do ISSB a partir do exercício de 2027 (voluntária em 2026), com asseguramento independente Limited Assurance progredindo a Reasonable Assurance até 2030 conforme a NBC TO 3000 e a ISAE 3000 (Revised). As Big-4 (PwC, Deloitte, EY e KPMG) e as Médias (Grant Thornton, BDO, Mazars e Crowe) emitem o relatório de asseguramento separado.

## Multa da CVM de até R$ 50 milhões, suspensão de cargo por 5-20 anos por greenwashing, class action sob a Lei 6.404/76 art. 158, downgrade no ISE da B3 e crime ambiental da Lei 9.605/98

Os números são severos. CVM Resolução 80/2022 e 44/2021: a omissão de Fato Relevante por tema ESG material gera multa da CVM de até R$ 50 milhões, suspensão de cargo por 5-20 anos e responsabilidade pessoal (art. 158 da Lei 6.404/76). A Reforma da Lei 14.195/2021 ampliou a diligência fiduciária, mas a class action por greenwashing pode atingir centenas de milhões. Lei Federal 9.605/1998: pena de 1 mês a 5 anos de reclusão, multa de até R$ 50 milhões e responsabilização pessoal - aplicável a vazamentos (Mariana 2015 da Samarco, que perdeu R$ 47 bilhões; Brumadinho 2019 da Vale, R$ 75 bilhões; Manaus 2024), desmatamento ilegal (Lei 12.651/2012) e descarte inadequado (Lei 12.305/2010). PAR da Lei 12.846/2013: multa de 0,1% a 20% do faturamento bruto, com perdimento e suspensão. ANPD/LGPD: multa de até 2% do faturamento BR, limitada a R$ 50 milhões.

A combinação é cumulativa. O greenwashing material pode gerar simultaneamente a omissão de Fato Relevante na CVM, parecer com ressalva na NBC TO 3000, class action (art. 158), downgrade no ISE da B3 com impacto de 5-12% na liquidez, ação penal do MPF Ambiental e exposição a CSRD da UE, CBAM, SOX e FCPA. Estudos do INSPER e da FGV mostram queda de 5-12% no preço da ação em janelas de 3 dias após uma inconsistência ESG material em listadas na B3.

## 15 etapas determinísticas, da obrigatoriedade CVM 193/2023 à divulgação Empresas.NET

O Agente roda 15 verificações sequenciais com decider explícito (R determinístico, A assistido, H humano) e fundamentação legal citada. A etapa 1 classifica a obrigatoriedade conforme a CVM Resolução 193/2023 art. 2, com base na receita líquida, no ativo total, na categoria de registro na CVM e no Regulamento do Novo Mercado da B3. A etapa 2 conduz a avaliação de materialidade conexa com os fluxos de caixa (IFRS S1 par. 17) - decisão humana do Conselho de Administração, do Comitê de Sustentabilidade e do Comitê de Auditoria, com responsabilidade pessoal (art. 158).

As etapas 3 a 7 fazem a coleta e o cálculo determinístico. A etapa 3 mapeia os datapoints ISSB cross-industry e SASB industry-based. A etapa 4 coleta os dados com lineage rastreável e timestamp ICP-Brasil via integração com SAP S/4HANA, TOTVS Sustainability, Senior HCM e sistemas IoT (medidores ABB, Schneider Electric e Siemens). A etapa 5 calcula o Escopo 1 conforme o GHG Protocol, os fatores do MCTI/Programa Brasileiro GHG e o IPCC AR6. A etapa 6 calcula o Escopo 2 em dual-reporting (location-based pelo ONS SIN e market-based com I-REC, microgeração distribuída da Lei 14.300/2022 e autoprodução conforme a ANEEL Resolução Normativa 1.000/2021 e 1.059/2023). A etapa 7 estima o Escopo 3 cradle-to-grave, priorizando as categorias 1 (compras), 11 (uso de produtos) e 12 (fim de vida).

As etapas 8 a 12 conduzem a análise estratégica e a validação. A etapa 8 conduz a análise de cenários climáticos do TCFD e do IFRS S2 par. 22, com cenários NGFS Phase IV adotados pelo BACEN, IPCC AR6 e horizon mapping - decisão estratégica humana. A etapa 9 coleta os indicadores sociais via e-Social, Senior HCM e ADP, com a LGPD art. 11. A etapa 10 valida a consistência do ESG com DFP, DRE e DVA (NBC TG 09), com investigação das divergências acima de 5%. A etapa 11 gera o rascunho narrativo com LLM e revisão obrigatória pelo DRI, pelo Comitê de Sustentabilidade e pelo Comitê de Auditoria. A etapa 12 faz o tagging em iXBRL conforme a taxonomia ISSB e o ESEF.

As etapas 13 a 15 selam, asseguram e divulgam. A etapa 13 sela cada decisão com Decision-Record SHA-256, ICP-Brasil A1 e WORM imutável por 10 anos. A etapa 14 submete ao asseguramento ISAE 3000 e NBC TO 3000 com Big-4 ou Médias - Limited Assurance progredindo a Reasonable. A etapa 15 divulga via Sistema CVM Empresas.NET, Formulário de Referência, DEFR, ITR e Fato Relevante quando material - decisão humana com responsabilidade pessoal (art. 158).

## Plausibilidade verificada por dados externos e cruzamento com ANEEL, ONS, I-REC, IBAMA e CDP

A plausibilidade não vem só do motor de cálculo interno - vem do cruzamento sistêmico com fontes oficiais. O Escopo 2 location-based é validado contra o fator de emissão SIN publicado mensalmente pelo ONS (Operador Nacional do Sistema). O Escopo 2 market-based é validado contra os registros do I-REC Brasil, o cadastro da ANEEL de PPAs e a microgeração SCEE (Lei 14.300/2022). Os indicadores ambientais são cruzados com o CTF (Cadastro Técnico Federal) do IBAMA, o RAPP (Relatório Anual) e os sistemas estaduais (SEMA, INEA, CETESB, IAP, FEPAM). Os indicadores sociais são validados via e-Social (S-1200 e S-1210), Senior HCM e ADP. Os indicadores de carbono são cruzados com o CDP (Carbon Disclosure Project), o Programa Brasileiro GHG Protocol e a Science Based Targets initiative (SBTi). Os cruzamentos automatizados rodam trimestralmente para o ITR e anualmente para o DEFR, com integração nativa a SAP Sustainability Control Tower, TOTVS Sustainability, Workiva ESG, Persefoni AI, Sweep e WayCarbon.

Para companhias abertas, a plausibilidade inclui a análise de impacto material nas demonstrações financeiras integradas. O sistema calcula o impacto estimado de cada datapoint em percentual da receita ou do ativo total, classificando uma material weakness ESG como aquela com impacto acima de 5% da receita ou de 1% do ativo total, combinada com probabilidade razoável de não detecção. O parecer do auditor independente Big-4 sobre o asseguramento NBC TO 3000 é considerado em paralelo com o parecer sobre as demonstrações financeiras (NBC TA 705) - a divergência entre a classificação ESG e a financeira é registrada para reconciliação pelo Comitê de Auditoria.

## Edge-cases brasileiros: estatais sob o TCU (Lei 13.303/16), instituições financeiras sob o PRSAC do BACEN e concessionárias sob ANEEL e ANP

As empresas estatais e as sociedades de economia mista são supervisionadas pelo TCU com as regras da Lei 13.303/2016 art. 9: programa de integridade obrigatório com dimensão socioambiental, prestação de contas anual com avaliação ESG e julgamento de contas com multa pessoal a administradores e até 8 anos de inelegibilidade (Lei 8.443/92 art. 57). Eletrobras, Petrobras e Vale enfrentam adicionalmente a fiscalização do TCU sobre o desempenho ambiental.

As instituições financeiras sob o BACEN seguem a Resolução CMN 4.945/2021 do PRSAC e a Circular BACEN 4.073/2022 do GRSAC: estrutura formal com Diretor responsável, Comitê de Sustentabilidade trimestral, AIR (Avaliação Interna de Risco) ESG, cenários climáticos NGFS Phase IV (Net Zero 2050, Disorderly, Fragmented World e Hot House World) com horizonte de 30 anos, stress testing climático aplicado ao portfólio de crédito e aos investimentos próprios, e reporting prudencial anual no DRSAC. A inobservância gera multa do BACEN de até R$ 2 bilhões, intervenção e responsabilização pessoal (Lei 4.595/64 art. 44). Bancos brasileiros líderes (Itaú, Bradesco, Santander Brasil, Banco do Brasil e BTG Pactual) já operam a PRSAC alinhada ao NGFS, aos ICMA Green Bond Principles, aos LMA Green Loan Principles e à AFII Brasil.

As concessionárias da ANEEL seguem a Resolução Normativa 1.000/2021 e 1.059/2023, com indicadores DEC e FEC, relatório de gestão obrigatório e auditoria independente. As distribuidoras de combustíveis da ANP cumprem o RenovaBio (Lei 14.299/2022 e 11.075/2022) com a aquisição de CBIO (Crédito de Descarbonização) certificado por verificadora credenciada. As multinacionais com matriz internacional conciliam IFRS S1/S2, CSRD/ESRS da UE, SASB, GRI, TCFD, CDP, SBTi, SOX, FCPA e UK Bribery Act 2010 - plataformas SaaS de GRC (Workiva CSRD Suite, Persefoni Pro, Sweep ESG, MetricStream, RSA Archer) facilitam a consolidação cross-jurisdictional.

## Integração com TOTVS Sustainability, SAP Sustainability Control Tower, Workiva ESG, Persefoni, Sweep, Oracle, Microsoft e WayCarbon e APIs dos reguladores

O TOTVS Protheus com TOTVS Sustainability, RM Sustentabilidade e Fluig ESG é líder do mercado BR, com mais de 50.000 clientes - oferece motor de cálculo dos Escopos 1, 2 e 3 conforme o GHG Protocol e os fatores do MCTI, com integração nativa a NF-e, e-Social, SPED, ANEEL e ANP e dashboard para o Conselho de Sustentabilidade. O SAP S/4HANA Brazil com SAP Sustainability Control Tower, Footprint Management e Green Ledger cobre multinacionais (Volkswagen, Bayer, Bosch, BASF, Petrobras, Vale, Ambev, Suzano, Klabin e JBS) com SOX-compliance, IFRS S1/S2 e CVM 193/2023. O Oracle ERP Cloud Brazil com Oracle Sustainability Cloud e Risk Management Cloud atende grandes bancos (Itaú, Bradesco, Banco do Brasil, Santander, Caixa, BTG Pactual e Eletrobras) via OData e Integration Cloud para a coleta automatizada e o cálculo de emissões.

O Workiva Wdesk com ESG Reporting e CSRD Suite é líder SaaS global, presente em mais de 30% das S&P 500 e com crescente adoção em listadas do IBOVESPA na B3 - integração nativa a IFRS S1/S2, CSRD ESRS, GRI, SASB e TCFD, com tagging iXBRL automatizado conforme a taxonomia ISSB. O Persefoni AI e Pro é especializado em carbon accounting, usado pelo PRSAC do BACEN e por grandes corporações. O Sweep ESG cobre IFRS S1/S2, CSRD, TCFD, CDP e SBTi, com IA assistida para o Escopo 3.

A WayCarbon Climate Management Platform nasceu da PUC-MG e atende grandes corporações brasileiras (Vale, Suzano, Klabin e Heineken Brasil) com inventário de GEE conforme o GHG Protocol e o Programa Brasileiro GHG, com integração ao MBRE (Lei 15.042/2024). A EnviroSuite Brasil cobre LCA e WCEM. O Microsoft Cloud for Sustainability com Power BI ESG está em expansão no BR, com integração ao Azure e a IoT.

A camada LGPD obriga o DPO (art. 41) com base legal específica do art. 11 para dados sensíveis ESG (diversidade racial, gênero e saúde ocupacional NR-1). Os logs são preservados com anonimização de PII conforme a Resolução CD/ANPD 2/2022. Para as listadas na B3 com adesão ao ISE, o parecer com ressalva na NBC TO 3000 torna a empresa inelegível para a reincorporação e impacta a liquidez e o custo de capital. A decisão final de materialidade, cenários climáticos, asseguramento e divulgação de Fato Relevante na CVM é sempre humana - sem IA generativa em decisões críticas.

--- Agente de Forecast Financeiro ---
> Forecast 3-statement (P&L, Balanço e DFC) com Budget vs Actual, WACC e valuation, pronto para CVM ITR/DFP, Receita Federal ECF e auditoria Big-4.

O forecast financeiro no Brasil constitui um sistema regulatório multifacetado que combina seis áreas principais: o CPC 26 R1 (alinhado ao IAS 1) para a apresentação de DRE, Balanço Patrimonial, DFC, DMPL e DVA obrigatórias para S/A conforme a Lei 6.404/76 art. 176-179; a CVM Resolução 80/2022 para o ITR trimestral e a DFP anual com outlook gerencial não enganoso; a Receita Federal IN 1.700/2017 com os Blocos K e N da ECF para apuração do IRPJ Lucro Real (25% mais 10% de adicional) e da CSLL (9%); o Ofício Circular B3 01/2018 para o EBITDA e o EBIT padronizados, que eliminam a divergência de versões entre companhia e analistas; a NBC TA 540 para o substantive testing trimestral de estimativas contábeis pelas Big-4; e a Lei 6.404/76 art. 1.005 para a responsabilidade civil dos administradores por forecast enganoso. Cada empresa brasileira de médio ou grande porte precisa coordenar um modelo integrado e determinístico de três demonstrações, análise de variação Budget vs Actual, WACC para mercados emergentes pela metodologia Damodaran, cenários Best/Base/Worst parametrizados, Monte Carlo de 10.000 iterações, outlook ITR/DFP e trilha de auditoria das Big-4.

## ITR/DFP da CVM, ECF da Receita Federal, NBC TA 540 das Big-4 e EBITDA padronizado da B3: quatro frentes que exigem um modelo de três demonstrações determinístico

A CVM Resolução 80/2022 unificou o ITR trimestral e a DFP anual, exigindo outlook gerencial com base em premissas claras e documentadas - diferentemente dos EUA, o Brasil não tem safe harbor para projeções (Lei 6.385/76 art. 22, fatos relevantes). A Receita Federal IN 1.700/2017 e os Blocos K e N da ECF exigem apuração de IRPJ Lucro Real ou Presumido e CSLL, com adições e exclusões M-300 documentadas. As Big-4 brasileiras executam substantive testing trimestral conforme a NBC TA 540, cobrando de R$ 1,2 a 2,5 milhões por ano de uma empresa média da B3. O Ofício Circular B3 01/2018 padroniza o EBITDA e o EBIT, eliminando a divergência de versões - o EBITDA Ajustado exige reconciliação linha a linha e nota explicativa.

Casos célebres demonstram o impacto: Petrobras (2014, divergência de EBITDA antes da Lava Jato), JBS (2017, exclusões do EBITDA Ajustado questionadas por analistas), Americanas (2023, fraude de US$ 9 bilhões na contabilidade de fornecedores) e Magazine Luiza (2023, controvérsia sobre o EBITDA de logística). Em todos os casos, a falta de um modelo integrado e determinístico de três demonstrações, de trilha de auditoria das Big-4 e de reconciliação Budget vs Actual contribuiu para o enforcement da CVM, class actions sob a Lei 6.404/76 art. 158 e perda de confiança do buy-side (ANBIMA).

## 14 pontos decisivos: nove determinísticos, dois com ML e três escalados a humanos

O Agente processa o forecast por um pipeline de 14 pontos decisivos: nove classificações regulatórias determinísticas, um Monte Carlo assistido por ML (sensibilidade multifator), um WACC para mercados emergentes calculado mensalmente e três escalados a humanos (premissas macroeconômicas top-down, operacionais bottom-up, plausibilidade gerencial e stress test setorial). A coleta histórica de 36 meses do ERP (TOTVS Performance Plus, SAP S/4HANA, Oracle EPM, Anaplan, Workday Adaptive, Vena) é reconciliada com os Blocos K e N da ECF da Receita Federal. O modelo de três demonstrações integra DRE, Balanço Patrimonial e DFC com cross-links: o Lucro Líquido alimenta o Patrimônio Líquido no Balanço, o capex e o capital de giro alimentam a DFC, e juros e impostos ficam amarrados conforme o CPC 26 R1.

As premissas macroeconômicas top-down (Selic, IPCA, câmbio e PIB) são extraídas do Boletim Focus do BACEN e de dados setoriais do IBGE, com sign-off do CFO e do Conselho. As premissas operacionais bottom-up (volume, preço, custo de matéria-prima, headcount e capex) têm dono nomeado por linha e sign-off da Diretoria - Lei 6.404/76 art. 1.005, responsabilidade civil dos administradores. Cenários Best/Base/Worst com variações parametrizadas: Selic em mais ou menos 200 bps, câmbio em mais ou menos 15%, receita em mais ou menos 10% e custo de matéria-prima em mais ou menos 8%. Sensibilidade single-factor com tornado chart determinístico e multifator com Monte Carlo de 10.000 iterações e correlação histórica do BACEN e do IBGE.

WACC para mercados emergentes pela metodologia Damodaran: Cost of Equity por CAPM com country risk premium EMBI+ Brasil de 250 a 400 bps, e Cost of Debt ajustado pelo tax shield de IRPJ 25% e CSLL 9% (total de 34%). WACC típico do Brasil em 2026: de 14% a 18% (ante 7% a 10% nos EUA e 6% a 9% na Europa). EBITDA e EBIT padronizados pelo Ofício Circular B3 01/2018, sem ajustes oportunistas, e EBITDA Ajustado conciliado linha a linha. Análise de variação Budget vs Actual mensal, com causa-raiz por volume, preço, mix, câmbio e timing.

Exemplo concreto: empresa brasileira de médio porte (R$ 400 milhões de faturamento, listada no Bovespa Mais, 1.800 funcionários e 4 unidades de negócio). O Agente extrai 36 meses do TOTVS Performance Plus e reconcilia os Blocos K e N da ECF. Premissas: Selic do Boletim Focus em 11,25%, câmbio a R$ 5,40, IPCA em 4,2%, receita em mais 8% e margem EBITDA de 18%. Cenários: Worst (Selic 13,5%, câmbio R$ 6,20 e receita -5%), Base (consenso do Focus) e Best (Selic 9,5%, câmbio R$ 4,80 e receita +12%). WACC de 2026 calculado: Ke de 16,2% (CAPM com EMBI+ 320 bps) e Kd de 11,5% (debêntures e BNDES), com tax shield de 34%, resultando em WACC de 14,1%. Faixa de EBITDA do Monte Carlo de 10.000 iterações: P10 de R$ 58M, P50 de R$ 72M e P90 de R$ 88M. EBITDA padronizado da B3 de R$ 71M e EBITDA Ajustado (M&A de 2024) de R$ 76M, reconciliado em nota explicativa no ITR.

## Plausibilidade gerencial, stress test setorial e climático e outlook ITR/DFP

A verificação de plausibilidade gerencial confronta o forecast com o benchmark setorial, o histórico da empresa, o guidance anterior e os comentários de analistas sell-side (ANBIMA) - o julgamento do CFO e do Conselho é obrigatório porque o modelo não captura mudanças estruturais ou black swans. O stress test setorial inclui cenários como recessão com queda de 30% na demanda, choque de commodity de 50% e perda de um cliente do top 10. O stress test climático NGFS Phase IV (Net Zero 2050, Disorderly Transition e Hot House World) é obrigatório para empresas com mais de 10 mil funcionários via BACEN PRSAC desde 2024, com pressão crescente da CVM (ICVM 480) no alinhamento aos padrões ISSB IFRS S1 e S2.

O outlook ITR trimestral e DFP anual é gerado conforme a CVM Resolução 80/2022, com faixa de cenários, premissas materiais documentadas, base macroeconômica do Boletim Focus do BACEN e sign-off de CFO, CEO e Conselho Fiscal. O backtesting de acurácia histórica com MAPE de 12, 24 e 36 meses aciona o retreinamento dos modelos quando os limites são excedidos. Trilha de auditoria das Big-4 sob a NBC TA 540: backup matemático, rationale do julgamento, backtesting, sensibilidade e reconciliação da variação Budget vs Actual, certificada com ICP-Brasil A1/A3 e WORM imutável por 5 anos, sob a LGPD art. 7 IX (cumprimento de obrigação legal).

## Integração com TOTVS Performance Plus, Anaplan, Workday Adaptive, Vena e SAP S/4HANA, mais o substantive testing das Big-4

O Agente integra-se aos sistemas brasileiros de Performance Management via API REST e ETL: [TOTVS Performance Plus](https://www.totvs.com/) e TOTVS RM Planejamento (líder no Brasil e nas médias empresas, com os Blocos K e N da ECF nativos), [Anaplan Brazil](https://www.anaplan.com/) com Connected Planning (multilatinas e IBOVESPA, consolidação multipaís), [Workday Adaptive Planning Brazil](https://www.workday.com/) (multinacionais com Workday HCM para headcount), [Vena Solutions Brazil](https://www.venasolutions.com/) (Excel-native para times de FP&A), SAP S/4HANA Brazil com SAP Analytics Cloud Planning (multilatinas SAP-centric), Oracle EPM Cloud e Hyperion Planning Brazil (gigantes do IBOVESPA e bancos), além de Jedox Brazil, Cubeware Cockpit Brazil e IBM Planning Analytics TM1 Brazil (alternativas para o mid-market). Boletim Focus do BACEN via API, dados setoriais do IBGE, base Damodaran de mercados emergentes, EMBI+ da JPMorgan e ratings de S&P, Moody's e Fitch. Motor de Monte Carlo com TensorFlow Probability, Crystal Ball e @RISK Palisade. Substantive Testing das Big-4 com exportação direta para Deloitte ASM, PwC Halo, EY Helix e KPMG Clara, com metadados de trilha de auditoria NBC TA 540 e ICP-Brasil A1/A3. Integração do outlook ITR/DFP da CVM Resolução 80/2022 via API da Plataforma de Comunicações da CVM. EBITDA padronizado da B3 (Ofício Circular 01/2018) com reconciliação automatizada e template de nota explicativa para ITR/DFP.

--- Agente de Detecção de Fraudes ---
> Pipeline determinístico de detecção de fraudes: COAF PLD-FT, Lei 9.613/98, Lei 12.846/2013 Anticorrupção, BACEN 3.978/2020, NBC TA 240 e LGPD em cadeia auditável.

A detecção de fraudes no Brasil opera sob um regime multicamadas exigente que combina PLD-FT (Lei 9.613/1998, COAF Resoluções 24/2013, 36/2020 e 32/2020 e BACEN Circular 3.978/2020), Anticorrupção (Lei 12.846/2013, Decreto 11.129/2022 e ABNT NBR ISO 37001:2021), Crimes Financeiros (Código Penal art. 168-A, 171, 297 e 299, Lei 7.492/86 e Lei 8.137/90) e Auditoria (NBC TA 240, 315, 330 e 265, IBRACON CTA 16 e COSO 2013). O regime obriga os sujeitos da Lei 9.613/98 art. 9 a comunicar operações suspeitas COS e em espécie a partir de R$ 50 mil COE ao COAF via Sistema SISCOAF em 24 horas, com responsabilidade pessoal do Oficial de Compliance/PLD-FT. A Lei 12.846/13 obriga programa de integridade com canais de denúncia, controles internos antifraude, due diligence de terceiros e treinamento. A NBC TA 240 (alinhada à ISA 240) estabelece como os Big-4 (PwC, Deloitte, EY, KPMG) ou as Médias (Grant Thornton, BDO, Mazars, Crowe) avaliam o risco de fraude, com presunção legal em reconhecimento de receita.

## Multa COAF até R$ 20 milhões, PAR Lei 12.846/13 com multa de 0,1% a 20% do faturamento, crime de lavagem Lei 9.613/98 e class action Lei 6.404/76 art. 158

Os números são severos. Lei 9.613/98 art. 12: a omissão de comunicação SISCOAF é crime (3-10 anos de reclusão e multa), mais multa COAF até R$ 20 milhões. Lei 12.846/2013 e Decreto 11.129/2022: o PAR por programa de integridade deficiente aplica multa de 0,1% a 20% do faturamento bruto, perdimento de bens, suspensão de atividades, dissolução compulsória e inscrição em CEIS e CNEP. Código Penal art. 171 (estelionato 1-5 anos), art. 297 (falsificação de documento público 2-6 anos), art. 168-A (apropriação indébita previdenciária 2-5 anos). Lei 7.492/86 gestão fraudulenta art. 4 (3-12 anos de reclusão). CVM Resolução 80/2022: a omissão de Fato Relevante por fraude material gera multa CVM até R$ 50 milhões, suspensão de cargo de administrador por 5-20 anos, responsabilidade pessoal art. 158 Lei 6.404/76 e risco de class action com condenação em centenas de milhões após a Reforma Lei 14.195/2021.

A combinação é cumulativa. Fraude material não detectada pode levar simultaneamente a omissão SISCOAF, PAR Lei 12.846/13, Fato Relevante CVM omitido, parecer adverso NBC TA 705 do auditor Big-4, class action Lei 6.404/76 art. 158, desenquadramento do Novo Mercado B3, suspensão de cargo do CFO, do DRI e do Oficial de Compliance, ação penal MPF e, em casos com nexo internacional, exposição a SOX, FCPA e UK Bribery Act 2010. Estudos do INSPER e da FGV mostram redução de preço de ação de 8-15% em janelas de 3 dias após anúncio de fraude material em listadas B3 - a Petrobras perdeu R$ 87 bilhões em capitalização após a Operação Lava Jato, e os frigoríficos perderam acesso a mercados externos após a Operação Carne Fraca.

## 14 etapas determinísticas, da identificação de sujeito obrigado à escalação de fraude material

O Agente roda 14 verificações sequenciais com decider explícito (R determinístico, A assistido, H humano) e fundamentação legal citada. A etapa 1 classifica a entidade como sujeito obrigado conforme Lei 9.613/98 art. 9 e Resolução COAF 36/2020 e define o perfil de risco PLD-FT baseado em setor, porte, jurisdições e tipo de cliente PEP.

As etapas 2-5 fazem o monitoramento de tipologias clássicas. A etapa 2 valida KYC/KYS com biometria e cruzamento de bases (Receita Federal, Bureaus e listas restritivas CEIS, CNEP, OFAC, ONU, UE). A etapa 3 detecta fornecedor fantasma via cruzamento operacional de NF-e, CT-e, MDF-e e ordens de compra - tipologia evidenciada pela Operação Lava Jato (Petrobras), Operação Carne Fraca (frigoríficos) e Operação Greenfield (Eletronuclear). A etapa 4 identifica splitting/smurfing em operações próximas aos limites COAF (R$ 50 mil COE, R$ 10 mil para PEP). A etapa 5 valida duplicatas via fingerprinting SHA-256 com análise de similaridade Levenshtein/Jaro-Winkler.

As etapas 6-10 aplicam análise avançada. A etapa 6 identifica round-tripping com análise de grafo, detecção de ciclos e score de jurisdições GAFI/FATF. A etapa 7 valida a SoD com matriz SAP GRC, Oracle Advanced Controls e TOTVS SIGAGED. A etapa 8 valida a autenticidade documental contra GenAI usando chain-of-trust ICP-Brasil, metadados PDF e análise estilística. A etapa 9 aplica procedimentos analíticos NBC TA 240 par. 32 (Lei de Benford, isolation forest, clustering DBSCAN e análise temporal). A etapa 10 detecta override de controles via Audit Log treinado em casos COAF, CVM, Lava Jato, Carne Fraca e Greenfield.

As etapas 11-14 consolidam, comunicam e escalam. A etapa 11 calcula o score consolidado de risco com ML supervisionado. A etapa 12 sela cada verificação com Decision-Record SHA-256, timestamp UTC-3 por TSP ICP-Brasil, assinatura ICP-Brasil A1 e WORM imutável por 5 anos. A etapa 13 prepara o dossier para SISCOAF com decisão final humana do Oficial de Compliance - o Agente NÃO comunica automaticamente. A etapa 14 escala material weakness ao Comitê de Auditoria, Conselho Fiscal e auditor independente conforme NBC TA 240 e 265, com possível Fato Relevante CVM Resolução 80/2022 quando afeta a fidedignidade.

## Plausibilidade verificada por dados externos e cruzamento com SISCOAF, Receita e Bureaus

A plausibilidade não vem só do motor analítico interno - vem do cruzamento sistêmico com fontes oficiais. O KYC é validado contra Receita Federal WS (situação cadastral, CNAE, sócios), Bureaus (Serasa, Boa Vista, SPC), listas restritivas (CEIS, CNEP, OFAC, ONU, UE, GAFI/FATF) e Sistema PEP COAF Resolução 29/2017. O KYS de fornecedor adiciona ordem de compra, CT-e/MDF-e, romaneio físico e medição de obra. A análise de rede cruza com Open Banking BR, PIX BACEN e CNAB 240/400 (FEBRABAN) para identificar fluxos circulares. A autenticidade documental cruza com SEFAZ (NF-e webservice com chave de 44 dígitos), cartórios, TJ e JUCESP/JUCERJA. Os cruzamentos automatizados rodam a cada transação material (não em amostragem) com integração nativa a SAP GRC, Oracle Financial Services, TOTVS Risk, IBM Financial Crimes Insight e SAS Anti-Money Laundering.

Para companhias abertas, a plausibilidade inclui análise de impacto material em demonstrações. O sistema calcula o impacto estimado de cada fraude em % da receita ou ativo total, classificando como material weakness aquela com impacto acima de 5% da receita ou de 1% do ativo total combinada com probabilidade razoável de não detecção. O parecer do auditor independente Big-4 sobre risco de fraude (NBC TA 240 e 315) é considerado em paralelo - divergência entre a classificação interna e a do auditor é registrada para reconciliação pelo Comitê de Auditoria.

## Edge-Cases brasileiros: estatais TCU Lei 13.303/16, instituições financeiras BACEN, fundos CVM 175

Empresas estatais e sociedades de economia mista são supervisionadas pelo TCU com regras Lei 13.303/2016: programa de integridade obrigatório, prestação de contas anual com avaliação antifraude, julgamento de contas com multa pessoal a administradores até 8 anos de inelegibilidade Lei 8.443/92 art. 57. O Agente integra com sistema e-TCU.

Instituições financeiras BACEN seguem a Circular 3.978/2020: estrutura formal com Oficial de PLD-FT estatutário, Comitê de PLD-FT trimestral, AIR Avaliação Interna de Risco, KYC robusto com PEP, UBO e listas restritivas, monitoramento contínuo automatizado, comunicação SISCOAF em até 24 horas e capacitação anual. A inobservância gera multa BACEN até R$ 2 bilhões, intervenção e responsabilização pessoal Lei 4.595/64 art. 44. Seguradoras seguem a Circular SUSEP 612/2020. Fundos de pensão seguem a Instrução PREVIC 35/2020. Gestores de recursos seguem as CVM Resoluções 175/2022 e 50/2021.

Multinacionais com matriz internacional conciliam o cumprimento de SOX, FCPA, UK Bribery Act 2010, Lei 6.404/76 e Lei 12.846/13. O Agente mantém visão cross-jurisdictional com mapeamento SOX/FCPA alinhado a NBC TA 240, 315 e 330. Plataformas SaaS GRC (AuditBoard SOXHUB com RiskOversight, Workiva Wdesk, MetricStream Anti Money Laundering, RSA Archer Fraud Risk Management) facilitam essa consolidação.

## Integração com TOTVS Risk, SAP GRC, Oracle Financial Services, AuditBoard, ACL Galvanize, IBM SPSS e APIs de reguladores

TOTVS Protheus oferece SIGAGED, SIGAFAS, RM Fluig e Risk Management com matriz de SoD e motor de regras para tipologias COAF Resolução 32/2020. SAP S/4HANA Brazil, com SAP GRC e SAP Fraud Management, cobre multinacionais (Volkswagen, Bayer, Bosch, BASF, Petrobras, Vale, Ambev) com SOX-compliance e Lei 6.404/76. Oracle ERP Cloud Brazil, com Oracle Financial Services Anti Money Laundering OFSAA, atende grandes bancos (Itaú, Bradesco, Banco do Brasil, Santander, Caixa, BTG Pactual) via OData e Integration Cloud para SISCOAF.

ACL Galvanize, com Diligent Highbond, é líder em Continuous Auditing com motor para Lei de Benford, isolation forest, clustering e análise de rede, usado por Big-4 em NBC TA 240. IBM SPSS Modeler, com IBM Financial Crimes Insight, oferece ML supervisionado e análise de rede social. SAS Anti-Money Laundering é amplamente usado por bancos brasileiros e Big-4. AuditBoard SOXHUB, com RiskOversight e CrossComply, é líder SaaS com mais de 30% das S&P 500 e crescente adoção em listadas B3.

A camada LGPD obriga DPO art. 41 com canal ANPD para incidentes com vazamento de dados pessoais. Logs preservados com anonimização PII conforme Resolução CD/ANPD 2/2022, AES-256 e rotação trimestral de chaves. Auditoria interna segue NBC TI 11. Para listadas B3, parecer anual da Big-4 sobre SCIIF antifraude complementa o sistema - ressalva torna inelegível para emissão pública.

O resultado é a redução do tempo de detecção de fraude de 6-18 meses para 24-72 horas, a cobertura ampliada de amostragem trimestral (5-10%) para 100% das transações materiais, a redução do prazo SISCOAF de 30-45 dias úteis para 24-48 horas, e zero comunicação automatizada ao COAF - protegendo Oficial de Compliance, Diretor de Auditoria Interna, CFO, DRI e Comitê de Auditoria de imputação pessoal Lei 6.404/76 art. 158, Lei 9.613/98 art. 12 e Lei 12.846/13. Sem IA generativa em decisões de comunicação SISCOAF, escalação ao Comitê ou Fato Relevante CVM.

--- Agente Compliance Escritural ---
> Compliance escritural fiscal: GoBD/SPED Fiscal, IN RFB 2.005/2021 e Lei 8.846/94 - arquivamento, imutabilidade e documentação auditáveis pela RFB.

Documentação de procedimentos ausente ou desatualizada é a deficiência formal mais frequente identificada por auditores fiscais. Quem não apresenta documentação atualizada durante a auditoria arrisca estimativas de até dez por cento do faturamento anual sobre o lucro tributável. O problema não é falta de conhecimento - é falta de continuidade.

## Documentação de procedimentos desatualiza mais rápido do que qualquer departamento de compliance consegue mantê-la

O padrão contábil alemão GoBD (padrão GoBD alemão de arquivamento fiscal) (equivalente ao SPED Contábil brasileiro, Lei 8.846/94 e IN RFB 2.005/2021) exige que toda alteração em processos fiscalmente relevantes seja documentada - novas versões de software, lógica de lançamento alterada, interfaces adicionais. Em um departamento financeiro típico com ERP, tesouraria, gestão de despesas de viagem e conexão bancária, surgem dezenas de alterações documentáveis por trimestre.

A realidade na maioria das empresas: a documentação de procedimentos foi criada uma vez, está como PDF em um diretório e não foi atualizada desde a última auditoria. Os processos reais evoluíram há muito tempo. Essa lacuna entre o estado documentado e a realidade vivida cresce a cada adaptação do sistema.

A legislação de desburocratização (BEG IV) reduziu os prazos de guarda para comprovantes contábeis de dez para oito anos desde janeiro de 2025. Simultaneamente, a LGPD (PT: RGPD) exige a exclusão de dados pessoais após o fim da finalidade de guarda. Quem exclui cedo demais viola a legislação tributária. Quem exclui tarde demais viola a proteção de dados. Sem monitoramento contínuo dos prazos, ambos os cenários são quase inevitáveis.

## Auditores fiscais utilizam deficiências formais como alavanca para estimativas

Desde que a administração tributária emprega técnicas digitais de auditoria, o foco das auditorias fiscais mudou. Auditores começam cada vez mais solicitando a documentação de procedimentos antes mesmo de examinar os dados contábeis. A razão é pragmática: deficiências formais na documentação são mais fáceis de comprovar do que erros materiais na contabilidade.

Se faltam arquivos de protocolo que documentem alterações em processos contábeis e versões de software, isso já basta como base para uma estimativa conforme a jurisprudência atual. O auditor argumenta que sem essas evidências a completude e imutabilidade dos registros não são rastreáveis. Acréscimos de segurança de até dez por cento do faturamento sobre o lucro tributável não são incomuns - em uma empresa de médio porte com 50 milhões EUR (aprox. 55 milhões USD) de faturamento, isso pode significar cinco milhões EUR de lucro adicional a tributar.

## A obrigação de fatura eletrônica intensifica os requisitos de arquivamento

Desde 1 de janeiro de 2025, todas as empresas no setor B2B devem ser capazes de receber faturas eletrônicas. O BMF publicou em 14 de julho de 2025 a segunda alteração do GoBD, que regula explicitamente o arquivamento de formatos híbridos como ZUGFeRD e Factur-X. A principal novidade: em faturas eletrônicas, pelo menos a parte XML estruturada deve ser arquivada. A parte PDF legível só é adicionalmente obrigatória se contiver informações divergentes ou fiscalmente relevantes.

Para a compliance contábil, isso significa: cada fatura recebida deve ser verificada quanto ao formato, o componente correto deve ser arquivado e a imutabilidade garantida por carimbo de tempo e valor hash. Essa é uma decisão baseada em regras que, com centenas de faturas por semana, não funciona de forma confiável manualmente.

## Um agente baseado em regras mantém a compliance atualizada sem consumir horas da equipe

O agente de compliance contábil opera predominantemente no nível 1 do [Decision Layer](/br/decision-layer/) - baseado em regras, seguindo diretrizes claras da legislação tributária e do padrão contábil. Obrigação de arquivamento, prazos de guarda, imutabilidade e acesso a dados seguem lógicas de verificação definidas. Sem margem de julgamento, sem necessidade de interpretação.

Para a documentação de procedimentos, o agente sobe ao nível 2: compara processos documentados com os processos efetivamente executados e propõe atualizações. Um humano verifica e aprova. A avaliação global dos riscos de compliance permanece inteiramente com o humano.

Um cenário concreto: o sistema ERP recebe uma atualização que altera a lógica de lançamento para faturas de adiantamento. O agente reconhece a divergência entre processo documentado e real, elabora o trecho atualizado da documentação de procedimentos e garante que as regras de arquivamento afetadas sejam ajustadas. O consultor tributário ou gestor fiscal aprova a alteração. Todo o histórico - quem alterou o quê, quando e por quê - é protocola automaticamente. Exatamente essa documentação é o primeiro item que auditores fiscais solicitam.

## Compliance surge como subproduto, não como esforço adicional

O valor real não está na automatização de etapas individuais de verificação, mas na mudança de paradigma: a conformidade contábil não é mais constatada na próxima auditoria, mas continuamente assegurada. A documentação de procedimentos está sempre atualizada porque é automaticamente complementada a cada alteração de processo. Prazos são monitorados antes de expirarem. E quando o auditor solicita acesso Z1, Z2 ou Z3, a resposta está disponível imediatamente - não após três semanas de preparação frenética.

--- Agente de Monitoramento SCIIF ---
> Monitoramento contínuo de controles internos financeiros sob COSO 2013 e NBC TG 16, com segregação de funções para um parecer Big-4 sem ressalva.

O monitoramento do Sistema de Controles Internos sobre Informações Financeiras (SCIIF) no Brasil opera sob um regime regulatório multicamadas exigente. A Lei 6.404/76 art. 142 e 158 obriga o Conselho de Administração a manter sistema de controles internos eficaz e estabelece responsabilidade civil pessoal dos administradores por violação. A CVM Resolução 80/2022, com a Resolução 44/2021, obriga companhias abertas a divulgar a DEFR Declaração Especial sobre Funcionamento dos Controles Internos no FRE Formulário de Referência. As NBC TA 240, 315, 330 e 265 (alinhadas com ISA internacional) estabelecem como o auditor independente Big-4 (PwC, Deloitte, EY, KPMG) ou Médias (Grant Thornton, BDO, Mazars, Crowe) deve avaliar o SCIIF, e o IBRACON CTA 16 emite orientação técnica vinculante para auditores. O COSO 2013 é o framework de referência reconhecido pela CVM, e a ABNT NBR ISO 37301:2021 e a ABNT NBR ISO 31000:2018 são certificações voluntárias com peso atenuante em PAR Processo Administrativo de Responsabilização da CGU.

## Parecer com ressalva NBC TA 705, multa CVM até R$ 50 milhões, suspensão de cargo de administrador por 5-20 anos e responsabilidade pessoal Lei 6.404/76 art. 158

Os números são severos no Brasil. CVM Resolução 80/2022, com a ICVM 480/09 art. 24: inadequação na DEFR ou omissão de deficiência material conhecida configura inadequação informacional com multa CVM até R$ 50 milhões, responsabilidade administrativa pessoal do CFO e do DRI e suspensão de exercício de cargo de administrador em S/A por 5 a 20 anos. NBC TA 705: parecer com ressalva ou parecer adverso do auditor independente sobre SCIIF tem impacto em rating de crédito (downgrade S&P/Moody's/Fitch tipicamente 1-2 notches), custo de capital (spread bancário sobe 50-150bps), cumprimento de covenant em contratos bancários e de bonds (potencial vencimento antecipado), e inelegibilidade para emissão pública até reapresentação corrigida. Lei 6.404/76 art. 158: responsabilidade civil pessoal dos administradores por violação da lei ou estatuto, com responsabilização por danos a acionistas em ações coletivas que após a Reforma da Lei das S/A de 2021 (Lei 14.195/2021) podem atingir centenas de milhões.

A combinação é cumulativa. Uma deficiência material em SCIIF não detectada pode levar simultaneamente a parecer adverso NBC TA 705 do auditor independente, multa CVM por DEFR inadequada, ação coletiva de acionistas Lei 6.404/76 art. 158, desenquadramento do Novo Mercado B3, suspensão de exercício de cargo do CFO e DRI, agravamento de PAR Lei 12.846/2013 (multa de 0,1% a 20% do faturamento, mais perdimento de bens) por programa de integridade deficiente conforme Decreto 11.129/2022 art. 5 III, e, em caso de fraude com nexo internacional, exposição a SOX (multa SEC e responsabilidade pessoal de CEO/CFO até 20 anos de prisão), FCPA e UK Bribery Act 2010. Estudos acadêmicos do INSPER e da FGV mostram redução de preço de ação de 8-15% em janelas de 3 dias após anúncio de deficiência material em SCIIF de listadas B3.

## 15 etapas determinísticas, da definição da matriz COSO ao Fato Relevante CVM

O Agente roda 15 verificações sequenciais em monitoramento contínuo, cada uma com decider explícito (R determinístico, A assistido, H humano) e fundamentação legal citada. A primeira etapa estabelece a matriz de SCIIF mapeando cada controle do framework COSO 2013 a processos de negócio, contas contábeis e asserções (existência, integridade, exatidão, valoração, apresentação) com risco avaliado conforme NBC TA 315.

As etapas 2 a 7 fazem o monitoramento operacional contínuo. A etapa 2 valida a segregação de funções via cruzamento da matriz de permissões SAP GRC Access Control, Oracle Advanced Controls e TOTVS SIGAGED a cada transação. A etapa 3 verifica o princípio de quatro olhos em transações materiais (acima de 0,5% da receita ou de R$ 5M) com timestamps de aprovações sequenciais. A etapa 4 detecta override da administração (management override) - o risco mais significativo de fraude conforme NBC TA 240 par. 31 - via análise heurística e ML supervisionado treinado em casos históricos da CVM e PAR da CGU. A etapa 5 monitora mudanças críticas de permissão via Audit Log com revisão semanal pelo Diretor de Auditoria Interna. A etapa 6 aplica procedimentos analíticos (Lei de Benford, isolation forest e clustering) em padrões de lançamento contábil. A etapa 7 executa gap analysis trimestral entre controles definidos e controles efetivamente operados, com cobertura percentual por controle-chave.

As etapas 8 a 12 consolidam, classificam e remediam. A etapa 8 computa o scoring de risco residual com metodologia COSO ERM 2017 e ABNT NBR ISO 31000 (probabilidade x impacto x maturidade). A etapa 9 identifica controles compensatórios para deficiências detectadas - um controle detectivo pode mitigar deficiência em controle preventivo conforme NBC TA 330. A etapa 10 sela cada verificação com Decision-Record SHA-256, timestamp UTC-3, assinatura ICP-Brasil A1 e arquivamento WORM imutável por no mínimo 5 anos. A etapa 11 escala deficiências classificadas conforme NBC TA 265: deficiency ao Diretor de Auditoria Interna, significant deficiency ao Comitê de Auditoria, material weakness ao Conselho de Administração e ao auditor independente. A etapa 12 faz tracking de remediação com responsável, prazo, métrica e reporting mensal ao Comitê de Auditoria.

A etapa 13 alimenta a DEFR Declaração Especial sobre Funcionamento dos Controles Internos elaborada pelo CFO, DRI e Comitê de Auditoria com base em evidência consolidada. A etapa 14 disponibiliza a evidência ao auditor independente Big-4 ou Médias para teste de controles conforme NBC TA 330: walkthrough, reperformance, inspeção, inquérito. A etapa 15 detecta automaticamente quando deficiência material afeta a fidedignidade de demonstrações já publicadas - dispara workflow de Fato Relevante CVM Resolução 80/2022 e 44/2021 com retificação de DFP/ITR e reavaliação de parecer NBC TA 705.

## Plausibilidade verificada por dados externos e cruzamento sistêmico

A plausibilidade do SCIIF não vem só do framework definido em papel - vem do cruzamento sistêmico com fontes operacionais. A matriz de SoD precisa ser consultada a cada transação real (não em amostragem trimestral), com integração nativa a SAP GRC, Oracle Advanced Controls e TOTVS SIGAGED. As permissões precisam ser revalidadas semanalmente contra organograma atualizado do e-Social S-2200/S-2299 (admissões e desligamentos). Os limites de aprovação configurados precisam ser compatíveis com alçadas estatutárias e procurações específicas. Os logs de auditoria precisam ser preservados em WORM imutável por mínimo 5 anos. Quando há incompatibilidade entre matriz definida e operação real, o Agente classifica como deficiência conforme NBC TA 265 com escalação automática.

Para companhias abertas, a plausibilidade ainda inclui análise de impacto material em demonstrações financeiras. O sistema calcula automaticamente o impacto estimado de cada deficiência em % da receita ou ativo total, e classifica deficiências materiais como aquelas com impacto acima de 5% da receita ou de 1% do ativo total combinado com probabilidade razoável de não detecção. O parecer do auditor independente sobre SCIIF (NBC TA 315 e 330) é considerado em paralelo - quando há divergência entre a classificação interna e a do auditor, o Agente registra a discordância para reconciliação pelo Comitê de Auditoria.

## Edge-Cases brasileiros: estatais TCU, instituições financeiras BACEN, fundos de investimento CVM 175

Edge-cases brasileiros exigem regras específicas. Empresas estatais e sociedades de economia mista são supervisionadas pelo TCU Tribunal de Contas da União com regras adicionais: cumprimento Lei 13.303/2016 (Lei das Estatais) com programa de integridade obrigatório, regimento interno do Comitê de Auditoria aprovado por norma específica, prestação de contas anual ao TCU com avaliação de SCIIF, e potencial julgamento de contas com aplicação de multa pessoal a administradores até 8 anos de inelegibilidade. O Agente integra com o sistema e-TCU para reporting e acompanhamento de processos.

Instituições financeiras supervisionadas pelo BACEN seguem a Resolução CMN 4.595/2017 com requisitos específicos: estrutura de gerenciamento integrado de riscos e controles internos com Diretor estatutário responsável (CRO), Comitê de Risco constituído, mapeamento de riscos por categoria (crédito, mercado, liquidez, operacional, conformidade, reputacional, estratégico, socioambiental), apetite de risco com limites e alertas, testes de stress, ICAAP Internal Capital Adequacy Assessment Process e reporting trimestral via SISBACEN. Seguradoras, corretoras e capitalização seguem a Circular SUSEP 612/2020. Fundos de pensão seguem a Instrução PREVIC 35/2020. Gestores de recursos seguem a CVM Resolução 175/2022.

Multinacionais com matriz internacional precisam conciliar o cumprimento parental SOX (Sarbanes-Oxley para listadas SEC), a Lei 6.404/76 brasileira e o cumprimento local de outros países onde operam. O Agente mantém visão consolidada cross-jurisdictional com mapeamento de controles SOX 302/404 alinhados a NBC TA 315/330 e identificação de gaps regulatórios. Plataformas SaaS GRC líderes (AuditBoard SOXHUB com RiskOversight e CrossComply, Workiva Wdesk com Wdata) facilitam essa consolidação - mais de 30% das companhias S&P 500 e crescente adoção por listadas B3 IBOVESPA.

## Integração com TOTVS Protheus, SAP GRC, Oracle Risk Cloud, AuditBoard e APIs de reguladores

TOTVS Protheus oferece SIGAGED, SIGAFAS e RM Fluig com matriz de SoD por usuário, perfil e filial. SAP S/4HANA Brazil, com SAP GRC Process Control, Risk Management, Access Control e Audit Management, cobre multinacionais (Volkswagen, Bayer, Bosch, BASF, Petrobras, Vale) com cumprimento SOX e Lei 6.404/76. Oracle ERP Cloud Brazil, com Risk Management Cloud, Advanced Controls e Internal Controls Manager, atende o IBOVESPA (Itaú, Bradesco, Ambev, JBS) via OData e Integration Cloud.

AuditBoard SOXHUB, com RiskOversight e CrossComply, é líder SaaS para Comitê de Auditoria - mais de 30% das S&P 500 a usam, com crescente adoção em listadas B3. Workiva Wdesk, com Wdata, é alternativa para reporting CVM e SOX. MetricStream serve multinacionais cross-jurisdictional. Diligent Boards cobre Conselho de Administração. RSA Archer atende instituições financeiras e seguradoras.

A camada LGPD obriga designação de DPO art. 41 com canal ANPD documentado. O Agente preserva logs com anonimização PII conforme Resolução CD/ANPD 2/2022, AES-256 e rotação trimestral de chaves. Auditoria interna segue NBC TI 11. Para listadas B3, parecer anual da Big-4 ou Médias sobre SCIIF complementa o sistema - ressalva torna inelegível para emissão pública até reapresentação corrigida.

O resultado é redução do tempo da DEFR de 60-90 dias úteis para 5-7 dias úteis, cobertura ampliada de amostragem trimestral (5-10%) para 100% das transações materiais, e detecção precoce de override em 24-72 horas (vs. 6-12 meses via auditoria tradicional). Sem IA generativa em decisões de classificação ou Fato Relevante - protegendo CFO, DRI, Diretor de Auditoria Interna e Comitê de Auditoria de imputação pessoal Lei 6.404/76 art. 158.

--- Agente Intercompanhia ---
> Agente concilia saldos intercompanhia entre partes relacionadas alinhado Lei 14.596/2023 OECD TPG, IN RFB 2.161/2023, ECF Bloco W CbCR, CPC 05 R1 e NBC TA 550.

Operações intercompanhia no Brasil constituem um sistema regulatório multifacetado que combina seis áreas principais: Lei 14.596/2023 (nova lei de Preços de Transferência alinhada ao OECD TPG 2022, em vigor desde 01/01/2024) com a IN RFB 2.161/2023 e seus seis métodos TP (PIC, PRL, MCL, MLT, MCR, MRRP); IN RFB 2.151/2023 com o ECF Bloco W para o Country-by-Country Reporting obrigatório a grupos com receita consolidada acima de R$ 2,26 bilhões; CPC 05 R1 e Lei 6.404/76 art. 247-249 para identificação de partes relacionadas e consolidação obrigatória de S/A com investidas no exterior; NBC TA 550 para o substantive testing Big-4 de partes relacionadas e valuation arm's length; CVM Resolução 80/2022 para os disclosures detalhados em ITR/DFP de transações, saldos com partes relacionadas e remuneração de administradores; e BACEN Carta Circular 3.297 para o registro na rede mundial de investimentos e remessas intercompanhia no exterior. Cada empresa brasileira com transações intercompanhia no exterior deve coordenar conciliação par-a-par determinística, decomposição timing/câmbio/transfer pricing, documentação Local File e Master File, CbCR e audit-trail Big-4.

## Lei 14.596/2023, IN RFB 2.161/2023, ECF Bloco W, OECD TPG 2022 e CPC 05 R1: cinco frentes regulatórias que exigem documentação intercompanhia determinística

A Lei 14.596/2023 (originada da MP 1.152/2022) entrou em vigor em 01/01/2024 e revogou o sistema brasileiro próprio de margens fixas Lei 9.430/96 art. 18-24 - alinhando o Brasil ao OECD Transfer Pricing Guidelines 2022 após décadas de divergência. A IN RFB 2.161/2023 regulamenta seis métodos alinhados ao OECD: PIC (Preços Independentes Comparados), PRL (Preço Revenda Menos Lucro), MCL (Custo Mais Lucro), MLT (Margem Líquida Transacional), MCR (Margem Comparável da Rentabilidade) e MRRP (Método Residual Repartição de Lucros) - com análise funcional e análise de comparabilidade obrigatórias. A IN RFB 2.151/2023 implementa o Country-by-Country Reporting via ECF Bloco W para grupos com receita consolidada acima de R$ 2,26 bilhões, com dados compartilhados automaticamente no OECD CRS framework com mais de 100 jurisdições. A NBC TA 550 obriga os Big-4 brasileiros (Deloitte, PwC, EY, KPMG) ao substantive testing de identificação, classificação e valuation das transações com partes relacionadas - cobrando de R$ 600k a R$ 1,5 milhão por ano para uma empresa média B3.

Casos célebres demonstram o impacto: Petrobras (2014, transações Sete Brasil, Galvão e UTC como partes relacionadas na Lava Jato), Eletrobras (2017, accruals no exterior questionados por SEC e CVM), JBS (2017, transações da J&F com partes relacionadas), Magazine Luiza (2023, controvérsia sobre transações com fundadores), Americanas (2023, fornecedores não-divulgados como partes relacionadas). Em todos os casos, a falta de identificação completa CPC 05 R1, de documentação tempestiva Lei 14.596/2023 e de audit-trail NBC TA 550 contribuiu para enforcement de RFB e CVM, class actions Lei 6.404/76 art. 158 e perda de confiança do buy-side ANBIMA. Autuações TP típicas: R$ 10-200 milhões, mais multa de 75-150 por cento e juros SELIC mais 1 por cento ao mês, somam R$ 30-700 milhões de impacto fiscal total.

## 14 pontos decisivos: onze determinísticos, um ML e dois escalados a humanos

O Agente processa a conciliação intercompanhia por um pipeline de 14 pontos decisivos: onze classificações regulatórias determinísticas, um ponto ML assistido (pesquisa de benchmarks comparáveis e análise de comparabilidade externa) e dois escalados a humanos (escolha do método TP e avaliação de conformidade arm's length). Coleta dados intercompanhia dos ERPs do grupo (TOTVS Protheus, RM e Datasul; SAP S/4HANA com SAP Group Reporting; Oracle EPM com HFM e ARCS; Senior Sistemas) reconciliados com o Bloco K, N e W da ECF da Receita Federal. Identificação de partes relacionadas CPC 05 R1: controladora, controladas direta/indireta, coligadas, joint ventures, pessoal-chave da administração, familiares e entidades sob controle ou influência significativa.

Conciliação par-a-par determinística: comparação de saldos da contraparte A versus contraparte B por par de sociedade, moeda e tipo de conta (Contas a Receber/Pagar, Empréstimos Mútuos, Royalties, Serviços Técnicos, Cost-Sharing, Marketing Intangibles). Decomposição de diferenças de timing (defasagem temporal de lançamentos via comparação das datas de escrituração e de operação) e de câmbio (variação PTAX BACEN ajustada por hedge accounting CPC 38/39/40, com isolamento do Other Comprehensive Income CPC 02 R2). Para grupos com 30 sociedades há até 435 pares possíveis; mesmo um terço com relações IC ativas gera 145+ pares mensais.

Documentação Local File Lei 14.596/2023 e IN RFB 2.161/2023: análise funcional (funções desempenhadas, ativos utilizados e riscos assumidos), análise de comparabilidade (comparáveis externos com filtros geográficos, setoriais e funcionais via Bloomberg BvD Orbis, S&P Capital IQ, RoyaltyStat, ktMINE), escolha do best method dentre os seis disponíveis e ajustes de diferenças materiais conforme OECD TPG 2022 cap. III. Master File do grupo e Country-by-Country Reporting ECF Bloco W IN RFB 2.151/2023 com receitas, lucros, impostos pagos e devidos, capital, lucros acumulados, funcionários e ativos tangíveis por jurisdição.

Eliminação intercompanhia na consolidação CPC 36 R3: saldos recíprocos, receitas/despesas intragrupo, lucros não realizados em estoques e dividendos intercompanhia gerados automaticamente. A avaliação de conformidade arm's length (preços dentro do intervalo interquartil dos benchmarks comparáveis significam conforme; fora exigem ajuste primário e secundário) requer julgamento humano - decisão com consequências de autuação RFB art. 19 IN 2.161/2023, CARF e risco de litígio.

Exemplo concreto: grupo brasileiro listado no B3 Novo Mercado (R$ 8 bilhões de receita consolidada, 18 sociedades em 9 jurisdições, transações intercompanhia mensais de R$ 350 milhões). Conciliação Q3 2026: 270 pares ativos. Diferenças identificadas: timing de R$ 28M (8 por cento), câmbio de R$ 42M (12 por cento) e transfer pricing escalado de R$ 18M (5 por cento), com 92 por cento conciliados automaticamente contra 60 por cento do baseline manual. Local File de 9 jurisdições gerado em 11 dias úteis, contra 65 dias manuais. Master File do grupo e CbCR ECF Bloco W consolidados em 4 dias úteis. Substantive testing Big-4 NBC TA 550 reduzido de 75 para 22 horas trimestrais. Autuação RFB hipotética evitada: R$ 45M de base, mais multa de 75 por cento e juros SELIC, somando R$ 95M de impacto fiscal coberto por documentação tempestiva como safe harbor.

## Decisões fiscais-tributárias permanecem julgamento humano com consequências autuação RFB

A avaliação de conformidade arm's length OECD TPG 2022 confronta os preços intercompanhia praticados com o intervalo interquartil dos benchmarks comparáveis - julgamento do controller, fiscal-tributário, obrigatório porque o modelo não captura ajustes funcionais, de risco e de ativos, nem business cycle e tax planning estratégico. A escolha do método TP entre os seis disponíveis (PIC, PRL, MCL, MLT, MCR, MRRP) requer best method analysis considerando a análise funcional e a disponibilidade de comparáveis - decisão estratégica com consequências de autuação RFB, CARF e risco de litígio Lei 13.105/2015 CPC. Diferenças residuais não-classificáveis (saldos antigos não-reconciliados, transferências em disputa, partes relacionadas omitidas) são escaladas ao Controller, CFO, Comitê de Auditoria e Conselho Fiscal.

Disclosures CVM Resolução 80/2022 ITR/DFP geradas automaticamente conforme CPC 05 R1: transações com partes relacionadas (natureza, montantes e termos), saldos com partes relacionadas (Contas a Receber/Pagar e Empréstimos Mútuos), remuneração de administradores (salários, benefícios, stock options e bônus) e termos fora de mercado divulgados separadamente. Audit-trail Big-4 NBC TA 550: backup matemático da conciliação par-a-par, rationale do julgamento da análise de comparabilidade, Local File por jurisdição, Master File do grupo, CbCR ECF Bloco W e integração com a ECF Bloco K e N (variação IRPJ/CSLL), certificado ICP-Brasil A1/A3, WORM imutável por 5 anos e LGPD art. 7 IX (cumprimento de obrigação legal) sem DPIA ANPD.

## Integração com TOTVS, SAP S/4HANA com Group Reporting, Oracle EPM com HFM e ARCS, Anaplan, OneStream, BlackLine e substantive testing Big-4

O Agente integra com Performance Management Systems brasileiros via API REST e ETL: [TOTVS Protheus, RM e Datasul](https://www.totvs.com/) com módulo de Consolidação e Intercompanhia (líder no Brasil com 50.000+ clientes, ECF Bloco K, N e W nativo), [SAP S/4HANA Brasil com SAP Group Reporting](https://www.sap.com/) e Intercompany Matching and Reconciliation (ICMR) automatizado, [Oracle EPM Cloud](https://www.oracle.com/) com Hyperion Financial Management (HFM) e Account Reconciliation Cloud Service (ARCS), [Anaplan Brazil](https://www.anaplan.com/) Connected Planning para consolidação multilatinas multi-currency, [OneStream XF](https://onestream.com/) unified CPM platform com intercompany matching nativo, [Tagetik Wolters Kluwer](https://www.wolterskluwer.com/) CPM intercompanhia multi-GAAP, [BlackLine Account Reconciliation](https://www.blackline.com/) com Intercompany Hub (líder em audit-trail Big-4), IBM Cognos Controller (consolidação com eliminação automática), Senior Sistemas com Senior Consolidação (mid-market brasileiro) e Mastermaq Domínio Consolidação (escritórios contábeis). API de câmbio PTAX BACEN e cotações de fechamento USD/EUR/CNY/ARS para análise de variação cambial CPC 02 R2 e hedge accounting CPC 38/39/40. Integração com benchmarks externos: Bloomberg BvD Orbis (Bureau van Dijk), S&P Capital IQ, RoyaltyStat e ktMINE para análise de comparabilidade Lei 14.596/2023 e IN RFB 2.161/2023. Substantive Testing Big-4 com exportação direta para Deloitte ASM, PwC Halo, EY Helix e KPMG Clara com metadados de audit-trail NBC TA 550 e ICP-Brasil A1/A3. Integração de disclosures de partes relacionadas CVM Resolução 80/2022 ITR/DFP via API da Plataforma de Comunicações da CVM. ECF Bloco W Country-by-Country Reporting RFB IN 2.151/2023 com reconciliação consolidada com mais de 100 jurisdições no OECD CRS framework via Common Transmission System (CTS).

--- Agente Aprovação NF ---
> Determina aprovador conforme matriz por valor e centro de custo, verifica orçamento e bloqueios, valida condições de pagamento, escala vencidas e documenta controles SOX/CVM para auditoria.

Cada fatura aprovada com um dia de atraso é uma decisão perdida. Não porque alguém esqueceu, mas porque a atribuição ao aprovador correto, na maioria das empresas, é um processo manual - dependente do conhecimento de pessoas específicas, não de regras claras no sistema. O Agent de Aprovação de Faturas transforma esse gargalo em um trecho previsível.

## Aprovações atrasadas destroem descontos em silêncio

Uma janela típica de desconto é de dez dias. Dez dias em que uma fatura precisa ser registrada, verificada, atribuída, aprovada e liberada para pagamento. Segundo análise da Nanonets, o tempo médio de processamento de uma fatura é de 9,2 dias - e essa é a média. Em empresas sem processos de aprovação estruturados, esse número sobe para mais de 17 dias (Nanonets, 2025).

O resultado: com volume de compras de 50 milhões EUR (55 milhões USD) e 2% de desconto sobre metade das faturas, ficam 500.000 EUR (545.000 USD) para trás todo ano - não porque as condições faltam, mas porque o processo de aprovação é lento demais. O dinheiro não some em um único incidente. Escoa em centenas de casos individuais que ninguém agrega.

## A matriz de aprovação é um conjunto de regras - não uma margem de julgamento

A pergunta "Quem pode aprovar essa fatura?" soa como julgamento. Na prática é o oposto. A resposta vem de uma combinação fixa de faixas de valor, centro de custo, projeto e fornecedor. Um conjunto de regras que, na maioria dos sistemas ERP, já está parametrizado - mas aplicado manualmente.

O Agent assume exatamente esse roteamento. Lê a matriz de aprovação, atribui a fatura ao aprovador correto e verifica em paralelo se há orçamento disponível no centro de custo e se o fornecedor está bloqueado. Três decisões que juntas levam menos de um segundo - e que em processos manuais consomem horas ou dias, por estarem espalhadas em sistemas e caixas de e-mail diferentes.

[Decision Layer](/br/decision-layer/) Nível 1: todas as três verificações seguem regras determinísticas. Não há espaço para interpretação, zona cinzenta ou exceção que não possa ser definida previamente.

## Lógica de escalação protege prazos antes do vencimento

O problema mais comum na aprovação de faturas não é a decisão errada. É a decisão que não acontece. Uma fatura fica na caixa de entrada do aprovador responsável, que está em reunião, em viagem de negócios ou simplesmente sobrecarregado.

O Agent monitora cada aprovação em andamento contra prazos configurados. Se um prazo de desconto se aproxima do fim, ele escala para o substituto definido - não após três e-mails de lembrete, mas segundo uma regra clara: se a aprovação não ocorre dentro de X horas, encaminhar ao nível hierárquico Y.

Cenário concreto: um fornecedor emite na terça-feira uma fatura de 85.000 EUR (93.000 USD) com 2% de desconto em dez dias. O gestor responsável está em conferência até sexta. O Agent reconhece a ausência, encaminha ao substituto, e a aprovação ocorre na quarta-feira. Sem lógica de escalação, a fatura só teria sido processada na segunda-feira seguinte - quatro dias após o vencimento do prazo de desconto. 1.700 EUR (1.850 USD) de perda em uma única operação.

## Aprovação em lote acelera o caso padrão

Nem toda fatura merece atenção individual. Faturas recorrentes do mesmo fornecedor, pelo mesmo valor, no mesmo centro de custo - seguem um padrão que o Agent reconhece. Esses casos se qualificam para aprovação em lote: o aprovador recebe uma visão agrupada em vez de casos individuais.

Isso não só alivia os aprovadores como muda a distribuição de capacidade em todo o processo de contas a pagar. Segundo a HighRadius, equipes Best-in-Class atingem um tempo médio de processamento de 3,1 dias por fatura, contra 17,4 dias em equipes sem processos estruturados (HighRadius, 2025). A aprovação em lote é uma das alavancas que explicam essa diferença.

## O humano decide onde as regras não bastam

Das sete etapas de decisão na aprovação de faturas, seis são totalmente baseadas em regras. A sétima não: a aprovação em estouro orçamentário.

Quando uma fatura ultrapassa o limite disponível do centro de custo, não existe algoritmo capaz de decidir se o gasto ainda é justificado. Talvez o orçamento esteja desatualizado. Talvez um pedido complementar tenha sido acordado verbalmente. Talvez a entrega seja crítica para o negócio e o processo orçamentário esteja atrás da realidade.

Decision Layer Nível 2: o Agent entrega ao decisor todos os fatos - valor da fatura, orçamento restante, gastos anteriores no centro de custo, histórico do fornecedor - e mantém a decisão aberta. Sem sugestão, sem recomendação, apenas uma proposta estruturada de decisão. A responsabilidade permanece com o humano, mas a preparação leva segundos em vez de horas.

--- Agente Captura NF ---
> Captura NFs AP via webservice SEFAZ (NF-e/NFC-e/CT-e/MDF-e), valida CFOP+CST+NCM, extrai ICMS/IPI/PIS/COFINS e arquiva SPED Fiscal + LGPD. Paralelo XRechnung/ZUGFeRD para matriz EU.

A NF-e (Nota Fiscal Eletrônica) é mandatória no Brasil para operações comerciais entre pessoas jurídicas desde 2008 (Ajuste SINIEF 07/2005, Convênio CONFAZ 30/2010). Cada NF-e tem chave de acesso de 44 dígitos validada pela SEFAZ do estado emissor, status (autorizada/cancelada/denegada) consultável via webservice, e schema XML XSD versionado (atual: 4.00). A SPED (Sistema Público de Escrituração Digital, Decreto 6.022/2007) consolida o conjunto de obrigações: SPED Fiscal (EFD-ICMS/IPI), SPED Contribuições (EFD-PIS/COFINS), ECD (Escrituração Contábil Digital), ECF (Escrituração Contábil Fiscal), e-Social, EFD-Reinf. Tudo isso converge para um único Agent de Recebimento que valida, classifica e arquiva 5.000+ NF-e/mês em uma operação de médio porte - mais relatório paralelo XRechnung/PEPPOL/ZUGFeRD para matriz internacional quando o grupo é multinacional.

## Multas por NF-e divergente vão até 100% do imposto - mais bloqueio em fronteira

A divergência entre NF-e e a operação real é punida pelo art. 44 da Lei 9.430/1996 com multa de 75% até 150% do imposto devido. Erro de CFOP que gera creditamento indevido de ICMS pode resultar em autuação SEFAZ por sonegação. Para uma empresa típica de médio porte (300-1000 NF-e recebidas/mês), 5% de erros de classificação geram passivo fiscal estimado em R$ 200.000-500.000/ano antes da auditoria - que tipicamente vem 24-36 meses depois, com juros e multa de 75% sobre o principal.

Pior: NF-e com divergência detectada em fronteira estadual (Posto Fiscal) gera apreensão de carga até regularização. Para indústria com produção JIT (just-in-time), bloqueio de 24h em rodovia significa interrupção de linha de montagem. Para a Volkswagen Resende, Renault Curitiba, Volvo São José dos Pinhais, isso é ROI imediato: cada NF-e validada antes do despacho é um caminhão a menos parado em Posto Fiscal Sumaré ou Castelo Branco.

## NF-e atravessa 15 etapas determinísticas, todas auditáveis pela Receita Federal

O Agente processa cada NF-e em 15 etapas determinísticas: validação XSD do schema 4.00, consulta de status na SEFAZ, classificação CFOP (1xxx/2xxx/3xxx e variantes), validação NCM/CEST (tabela TIPI-2026), cálculo de ICMS (próprio, ST e DIFAL via Lei Kandir LC 87/96), IPI (Decreto 7.212/2010 RIPI), PIS/COFINS (Lei 10.833/2003 e 10.637/2002 conforme o regime), verificação de duplicação por chave de acesso, validação cadastral do CNPJ via SINTEGRA, threshold de aprovação humana (1 etapa H), geração de SPED Fiscal C100/C170/E110, geração de SPED Contribuições A100/C170/M210, arquivamento na ECD com plano referencial RFB e, por fim, conversão paralela para XRechnung/ZUGFeRD/PEPPOL quando a empresa pertence a grupo internacional.

Cenário típico: indústria automotiva em Curitiba recebe 2000 NF-e/mês de fornecedores (autopeças, química, embalagens, serviços técnicos). 60% são CFOP 1.102 (entrada interestadual com creditamento ICMS), 25% CFOP 2.102 (interestadual sem creditamento na origem), 10% CFOP 3.102 (importação com IRFE+IPI desembaraço), 5% devoluções (CFOP 1.202/2.202). Sem agente, o departamento fiscal gasta 18-22 dias/mês em classificação manual com 12% de erros. Com Agent: 4 horas/mês para 2000 NF-e, <1% erro detectado em revisão por amostragem.

## Integração com TOTVS Protheus, SAP S/4HANA Brazil e ERPs locais

O Agent conecta-se aos principais ERPs do mercado brasileiro via API: [TOTVS Protheus](https://www.totvs.com/) (líder com 50.000+ clientes incluindo localização SPED completa), SAP S/4HANA Brazil Localization (multinacionais com Brazil Country Version), [Senior Sistemas](https://www.senior.com.br/) (forte em manufatura), Oracle ERP Cloud Brazil Localization (gigantes IBOVESPA), Mastermaq Domínio Sistemas (escritórios contábeis e PME). Webservices SEFAZ (28 unidades, uma por estado, mais o DF e o ambiente nacional) acessados via certificado digital A1/A3 ICP-Brasil. Validação SPED com PVA (Programa Validador) antes de transmissão mensal evita rejeição automática. Para multilatinas com matriz UE: geração paralela XRechnung 3.0 (Alemanha B2G), Factur-X/ZUGFeRD (DE B2B), KSeF FA(2) schema (Polônia mandatório 2026), FacturaE 3.2.2 (Espanha) ou PEPPOL BIS Billing 3.0 (multi-país EU). NF-e brasileira mantém-se como fonte primária, conversão preserva campos obrigatórios EN 16931. Decision Layer registra ambos formatos com mapeamento auditável - mesma operação visível para Receita Federal e para auditoria de matriz IFRS.

--- Agente Emissão NF ---
> Emite NF-e (produtos) e NFS-e (serviços) via SEFAZ/Prefeitura, calcula ICMS/IPI/ISS por município, atribui numeração sem lacunas, gera DANFE/DANFSe e arquiva SPED com cobrança automática.

A emissão de faturas consome capacidade que falta em outras partes do departamento financeiro. Ao mesmo tempo, cresce a pressão regulatória pela obrigatoriedade da nota fiscal eletrônica. O Agent de Emissão de Faturas resolve os dois problemas: cria faturas de saída totalmente baseado em regras - sem IA, sem intervenção manual, com conformidade GoBD (padrão GoBD alemão de arquivamento fiscal) ininterrupta desde o primeiro documento.

## Faturas incorretas custam mais do que retrabalho

Uma parcela substancial de todas as faturas emitidas manualmente contém erros. A correção de um único documento com erro fica na faixa de duas dezenas de USD, considerando pessoal, correção no sistema e atrasos de pagamento. Em uma empresa que processa 500 faturas de saída por mês, os documentos com erro somam um esforço de correção de quatro algarismos em EUR - todo mês, antes mesmo de contabilizar o dano real de recebimentos atrasados.

Erros em faturas de saída raramente são aleatórios. Alíquotas erradas em entregas intracomunitárias, campos obrigatórios ausentes segundo a legislação de ICMS, condições de pagamento inconsistentes - são fraquezas sistemáticas que surgem repetidamente do mesmo processo manual. Justamente essa sistemática torna o erro resolvível por regras.

## A obrigatoriedade de nota fiscal eletrônica aumenta a pressão

No Brasil, NF-e e NFC-e via SEFAZ já são rotina. Na Alemanha, desde 1 de janeiro de 2025, toda empresa precisa receber notas fiscais eletrônicas no tráfego B2B. O prazo de transição para o envio termina no fim de 2026. Depois disso vale: cada fatura de saída precisa existir como conjunto de dados estruturado no formato XRechnung ou ZUGFeRD - não como PDF nem como digitalização.

Por trás dessa obrigação há um objetivo concreto do governo federal alemão: fechar a lacuna de imposto sobre valor agregado de cerca de 22 bilhões EUR (24 bilhões USD) (Fonte: DATEV Magazin / Comissão da UE). Para departamentos financeiros, isso significa uma troca de formato que vai muito além da emissão. Cada documento precisa ser legível por máquina, os campos obrigatórios precisam corresponder exatamente ao schema e o formato escolhido precisa permanecer configurável por cliente.

Quem controla essa troca manualmente, constrói novas fontes de erro em um processo já propenso a falhas. Quem automatiza, elimina o problema de formato como ponto de decisão.

## Oito etapas de decisão substituem o processo manual

Cenário concreto: uma prestadora de serviços de projetos emite 400 faturas de saída por mês para clientes na Alemanha, na UE e na Suíça. Até agora, um responsável verificava para cada documento a alíquota, complementava campos obrigatórios, escolhia o formato e atribuía o número da fatura manualmente.

O [Decision Layer](/br/decision-layer/) decompõe esse processo em oito etapas determinísticas. Dados de prestação são obtidos do sistema-fonte. Campos obrigatórios segundo a legislação de ICMS são compilados automaticamente. A alíquota decorre da localização do cliente e do tipo de serviço - 19% no mercado interno, intracomunitário isento, terceiro país sem imposto. O formato de nota fiscal eletrônica é derivado dos cadastros do cliente. As condições de pagamento vêm do contrato. O número da fatura é atribuído atomicamente - sem lacunas, sem duplicidade. Envio e arquivamento acontecem ao mesmo tempo.

Todas as oito etapas são baseadas em regras. Nenhuma etapa exige avaliação, ponderação ou previsão. Por isso, a participação de IA está exatamente em zero - e a prontidão fica entre 89 e 96 pontos, o maior valor de todo o catálogo.

## Conformidade com o padrão contábil alemão GoBD surge no processo, não na conferência

O padrão contábil alemão GoBD exige três coisas de cada fatura de saída: numeração sem lacunas, arquivamento imutável e rastreabilidade completa. Em processos manuais, essas exigências normalmente são garantidas por controles posteriores - uma verificação no fim do mês, uma conferência das sequências, uma rodada manual de arquivamento.

O Agent de Emissão de Faturas inverte essa lógica. A atribuição de numeração é integrada de forma atômica ao processo de criação. O arquivamento ocorre junto com o envio, não depois. E cada decisão - qual alíquota, qual formato, qual canal de envio - é protocolada com carimbo de tempo e justificativa. Em uma auditoria fiscal, o caminho completo de decisão para cada documento individual fica disponível. No Brasil, a mesma estrutura atende ao SPED Contábil, à Lei 8.846/94 e à IN RFB 2.005/2021.

Para CFOs isso significa: conformidade GoBD não é mais risco de auditoria, e sim uma propriedade do sistema. O Decision Layer no Nível 1 - puro conjunto de regras - torna a emissão de faturas o processo mais confiável de toda a contabilidade de clientes.

--- Agente de Lançamentos Contábeis ---
> Lançamentos contábeis do fechamento mensal alinhados ao CPC/IFRS e à Lei 6.404/76, com revisão em quatro olhos e geração do ECD Bloco I/J.

A escrituração contábil no Brasil é um pipeline regulatório com seis camadas simultâneas: a Lei 6.404/1976 (Lei das S/A) define o regime de competência e a responsabilidade técnica do contador (art. 177), o Decreto 6.022/2007 (SPED) e a IN RFB 1.420/2013 disciplinam a Escrituração Contábil Digital (ECD), a IN RFB 1.422/2013 e IN RFB 1.700/2017 regem a Escrituração Contábil Fiscal (ECF) com e-LALUR e e-LACS, os CPCs (Comitê de Pronunciamentos Contábeis) determinam o tratamento contábil alinhado às IFRS desde a Lei 12.973/2014, a Resolução CFC 1.330/2011 (NBC ITG 2000) regula a escrituração e o controle interno, e o BACEN COSIF estabelece plano contábil próprio para instituições do Sistema Financeiro Nacional. Cada lançamento manual carrega risco fiscal duplo: glosa pela Receita Federal (multa 75-150% do imposto não pago, art. 44 Lei 9.430/96) e responsabilização técnica do contador no CRC.

## Plano Referencial mal mapeado e adições e-LALUR ausentes geram glosa fiscal de 75-150% e bloqueio de CND em fiscalização Receita Federal

A Receita Federal cruza ECD com ECF, DCTFWeb, DIRF, EFD-Contribuições e EFD-ICMS/IPI via SPED para detectar divergências - e o Plano Referencial RFB (Block I051 da ECD) é o eixo central desse cruzamento. Quando uma empresa mapeia "Despesas Comerciais" para um código do Plano Referencial que a RFB classifica como "Despesas Indedutíveis", a malha fiscal aciona alerta automático e abre fiscalização. Resultado típico: glosa de R$ 1,2 a R$ 3 milhões em deduções para uma indústria de médio porte com R$ 80 milhões de faturamento, multa de ofício 75% do tributo não pago (R$ 408 mil sobre R$ 1,2 milhão indevidamente deduzido considerando IRPJ 25% + CSLL 9%), juros SELIC + 1% ao mês desde a competência (em 36 meses, ~50% adicional), totalizando R$ 1,1 milhão de exposição fiscal sobre erro de mapeamento.

Em fiscalização agressiva (qualificação como sonegação dolosa por reincidência ou padrão sistemático), a multa sobe para 150% (Lei 9.430/96 art. 44 §1), totalizando R$ 1,4 milhão. Soma-se a isso o bloqueio de Certidão Negativa de Débitos (CND) que impede participação em licitações públicas (Lei 14.133/21 art. 68), financiamentos BNDES e FINEP, renovação de credenciamentos junto à Caixa Econômica Federal, e responsabilização do contador signatário da ECD junto ao CRC (suspensão de 30 dias a 1 ano por imprudência conforme Resolução CFC 1.307/2010). E os erros típicos não vêm de fraude - vêm de classificação manual feita por analista contábil sem treinamento atualizado no Plano Referencial vigente para o ano-calendário.

## A escrituração contábil brasileira percorre 14 etapas determinísticas, não 8

Diferente do modelo alemão padrão (8 etapas, focado em GoBD e HGB §238) ou do espanhol (10 etapas, com PGC 2007 e Modelo 200), a escrituração contábil brasileira CLT-compliant exige 14 etapas determinísticas porque o sistema regulatório tem mais camadas: identificação de lançamentos recorrentes (78% típicos do volume mensal), cálculo de diferimentos por competência (Lei 6.404/76 art. 177 + CPC 00 R2), depreciação fiscal vs econômica simultânea (IN RFB 1.700/2017 vs CPC 27 com ajuste FCONT), avaliação de provisões trabalhistas e contingências (CPC 25 com classificação provável/possível/remota), teste de impairment (CPC 01), classificação de itens extraordinários (CPC 23 e CPC 24), reconhecimento de receita (CPC 47 - IFRS 15 5-step model), tratamento de leasing pós-CPC 06 R2 (ativo direito de uso + passivo arrendamento), validação de adições e exclusões e-LALUR e e-LACS (IN RFB 1.700/2017 art. 248-261), mapeamento ao Plano Referencial RFB (DE-PARA Block I051), validação de partidas dobradas, aprovação quatro olhos NBC ITG 2000 para lançamentos manuais, gravação imutável Block I200/I250 com hash, e geração de Block J100/J150/J210 (BP, DRE e DMPL).

Um cenário concreto: indústria de máquinas com 1.200 lançamentos mensais de fechamento ocupava três contadores por quatro dias cada um para preparar os Journal Entries. Após a introdução do Agente, o sistema reconhece 78% dos lançamentos como recorrentes (936 lançamentos) e os propõe automaticamente: aluguel pré-pago em diferimento (CPC 00 R2 item 4.50), depreciação programada de 340 bens do imobilizado (IN RFB 1.700/2017 Anexo III), 22 contratos de leasing CPC 06 R2 com ativo direito de uso e juros de passivo, 18 provisões trabalhistas mensais (férias e 13º proporcionais), e 38 lançamentos de PIS/COFINS e ICMS sobre receita. Os lançamentos baseados em regras (calculados pelo Agente) somam mais 168 entradas - perfazendo 1.104 lançamentos automatizados. Restam 96 lançamentos com julgamento humano: ajuste de provisão para contingência tributária após decisão de 1ª instância TRF, três itens classificados como extraordinários (CPC 24 evento subsequente), uma reclassificação de exercício anterior (CPC 23 item 49), e um teste de impairment CPC 01 sobre linha descontinuada. O fechamento mensal cai de 12 contador-dias para 2,5 contador-dias, e o quatro-olhos NBC ITG 2000 ganha qualidade porque o Controller revisa só os 96 casos que realmente exigem julgamento.

No [Decision Layer](/br/decision-layer/), 9 das 14 etapas são decisões baseadas em regras (nível R), 1 é proposta de IA com aprovação humana (nível A para identificação de recorrentes), e 4 são decisões humanas obrigatórias (nível H): provisões CPC 25, impairment CPC 01, classificação extraordinária CPC 23/24, e quatro olhos para lançamentos manuais. Não há ponto em que IA generativa decida sozinha sobre tratamento contábil - cada cálculo é a aplicação de uma norma CPC, IN RFB ou Lei 6.404/76.

## Conciliação CPC vs IFRS gera reporting paralelo sem retrabalho

Empresas brasileiras com matriz no exterior ou subsidiárias internacionais enfrentam o mesmo desafio: a contabilidade local segue CPCs (alinhados IFRS desde Lei 12.973/2014), mas o reporting para a sede precisa ser puro IFRS sem ajustes locais brasileiros (como ajuste FCONT, depreciação acelerada incentivada Lei 11.196/05, ou tratamento PIS/COFINS não-cumulativo). O Agente gera os dois reports paralelos a partir da mesma base contábil: ECD/ECF para Receita Federal com adições e exclusões e-LALUR completas, e demonstrações IFRS sem os ajustes locais para consolidação parental.

A conciliação é documentada em nota explicativa de reconciliação (CPC vs IFRS), evidenciando os principais ajustes: tratamento PIS/COFINS (regime não-cumulativo CPC vs IFRS 15 receita líquida), depreciação acelerada Lei 11.196/05 (ajuste FCONT na ECF, irrelevante IFRS), reavaliação de imobilizado pré-2008 (custo atribuído CPC 27 anexo, irrelevante IFRS por adoção pelo custo histórico), e ajuste hiperinflacionário (não aplicável Brasil pós-Plano Real, mas obrigatório IAS 29 para sedes em moedas com hiperinflação acumulada). Para companhias listadas na BOVESPA com ADRs em NYSE, há ainda reconciliação CPC vs US GAAP via Form 20-F.

## Edge-cases brasileiros: PCLD BACEN, COSIF e SUSEP exigem plano contábil próprio

Para instituições financeiras (bancos, financeiras, factorings, cooperativas de crédito), aplica-se o COSIF (Plano Contábil das Instituições do Sistema Financeiro Nacional) editado pelo BACEN, que substitui parcialmente os CPCs em pontos específicos: PCLD com faixas AA-H (Resolução BACEN 4.557/2017) em vez de impairment financeiro CPC 48; classificação de operações de crédito por níveis de risco; tratamento de instrumentos financeiros derivativos com mark-to-market obrigatório. O Agente identifica automaticamente o regime regulatório pelo CNAE da empresa e aplica o plano contábil correto - COSIF para bancos, plano SUSEP para seguradoras, CPC para empresas comerciais e industriais.

Para companhias abertas (registradas CVM com ações negociadas em BOVESPA), aplicam-se ainda obrigações suplementares CVM: ITR (Informações Trimestrais) auditadas em revisão limitada, DFP (Demonstrações Financeiras Padronizadas) auditadas integralmente, Formulário de Referência anual com mais de 200 páginas, comunicado de fato relevante imediato. O Agente alimenta cada um desses outputs a partir da mesma base contábil sem retrabalho, mantendo consistência entre ECD/ECF (RFB), DFP/ITR (CVM) e reports parentais IFRS.

## Integração com ecossistema brasileiro: TOTVS, SAP, Senior, Mastermaq

A lógica do Agente conecta-se aos principais sistemas de gestão contábil do mercado brasileiro via API: [TOTVS Protheus FI](https://www.totvs.com/) e TOTVS RM Saldus (líderes em médias e grandes empresas com módulo de Contabilidade Geral, lançamentos contábeis e geração ECD/ECF), TOTVS Datasul (forte em manufatura), SAP S/4HANA Brazil Localization (multinationals e IBOVESPA, com módulos FI-BR específicos para Plano Referencial e SPED), [Senior Sistemas Senior Contábil](https://www.senior.com.br/) (forte em indústria com mais de 5.000 clientes BR), Oracle ERP Cloud Brazil Localization (gigantes IBOVESPA e multinacionais), e [Mastermaq Domínio Sistemas](https://www.mastermaq.com.br/) (escritórios contábeis com mais de 75.000 escritórios usuários e foco em PME). Para empresas com operação em SC, PR, RS e SP, integração com sistemas regionais como Folhamatic FT, Sage Contábil e Apdata. A geração de ECD usa layout 9 (vigente desde 2024) via Programa Validador e Assinador (PVA) RFB, com transmissão SPED via certificado digital A1 ou A3 ICP-Brasil. Para empresas com matriz na Europa ou EUA (Volkswagen, Bosch, Siemens, GE com unidades brasileiras), o Agente também gera relatórios paralelos compatíveis com IFRS para consolidação na sede - mantendo a operação local CPC + RFB compliant e o reporting parental sob padrões internacionais.

--- Agente de Arrendamento ---
> Contabilização determinística de arrendamento mercantil segundo CPC 06 R2 IFRS 16: Right-of-Use, passivo, taxa incremental - Lei 6.099/74, ECF Bloco K, CVM 945.

A contabilização de arrendamento no Brasil é o ponto onde a Tesouraria e a Controladoria provam diligência contábil-fiscal-societária frente a oito instâncias simultâneas: a Receita Federal cruza a ECF Bloco K e Bloco M contra a ECD via SPED para validar o lucro tributável no Lucro Real (IN RFB 1.700/2017, Lei 12.973/2014 e Lei 9.430/96 art. 13, que limita a dedutibilidade aos juros), o BACEN exige registro no SCR para sociedades arrendadoras (Resolução 2.309/96 e 4.557/2017), a CVM obriga o cumprimento do CPC 06 R2 em ITR/DFP/FRE (Resolução 73/2022 e Deliberação 945/2024, com requisitos adicionais para modificações a partir de 2025), o CFC fiscaliza os julgamentos intransferíveis pelo Contador signatário CRC, o CARF julga autuações por dedução indevida (multa de 75-150% Lei 9.430/96 art. 44), os auditores independentes aplicam a NBC TA 540 sobre IBR e prazo razoavelmente certo com risco de parecer com ressalva NBC TA 705, a B3 exige cumprimento do CPC 06 R2 em emissões, e a ANPD fiscaliza dados contratuais com pessoa física (LGPD). Cada cláusula mal classificada carrega risco quíntuplo: glosa da Receita Federal com multa de 75-150%, mais Selic e mais 1%/mês; restatement CVM (que reduz o preço de ação em 8-15%); responsabilidade administrativa do Diretor Financeiro (multa até R$ 50 milhões); parecer com ressalva NBC TA 705; e responsabilidade ética-disciplinar do Contador signatário CRC.

## Glosa da Receita Federal com multas de 75-150% (Lei 9.430/96) por dedução indevida de leasing financeiro, restatement de DFP/ITR pela CVM Deliberação 945/2024, autuação CARF por taxa incremental fora de mercado e parecer com ressalva NBC TA 705 do auditor independente quebram a credibilidade contábil-fiscal do exercício

Uma empresa brasileira de varejo com 320 lojas (R$ 280 mil aluguel mensal médio, prazo 5-10 anos com cláusula IPCA), faturamento R$ 850 milhões/ano e Lucro Real fecha 25-40 contratos novos por ano, com renovações, modificações e redução de footprint pós-home office. Antes da automação, dois Contadores signatários CRC sênior, um Tesoureiro e um CFO gastavam 3-4 horas por contrato (200-360 contratos vivos, mais 25-40 novos) classificando arrendamento, derivando IBR, calculando Right-of-Use Asset e processando modificações - 800-1.500 horas/ano só em julgamento contábil de leasing.

A consequência vai além do custo de mão de obra: dedutibilidade de leasing financeiro é top motivo de autuação CARF em Lucro Real. Divergências entre o CPC 06 R2 e a ECF Bloco K e Bloco M (uma empresa deduziu R$ 18 milhões em depreciação ROU pós-IFRS sem ajuste de neutralidade Lei 12.973/2014) viraram autuação de R$ 13,5 milhões em IRPJ/CSLL, mais R$ 20 milhões em multa qualificada de 150% e mais Selic - total de R$ 33,5 milhões. CVM emitiu ofício por inadequação CPC 06 R2 em ITR/DFP - reapresentação pela Deliberação 945/2024 (modificação de redução de footprint não classificada adequadamente) gerou queda de 9% no preço de ação em D+1 e multa CVM R$ 22 milhões ao CFO. A implementação Pillar Two BEPS no BR a partir de 2026 (PLP 49/2024) cria exigência adicional de reconciliação Right-of-Use Asset por jurisdição para alíquota efetiva mínima 15%.

## A contabilização de arrendamento no Brasil percorre 17 etapas determinísticas, com 3 julgamentos intransferíveis ao Contador signatário CRC

Diferente do modelo alemão (HGB com economic ownership e IFRS 16 em dual-track) e do espanhol (PGC com adoção do IFRS 16 via CNMV/ICAC), o reconhecimento BR exige 17 etapas porque o sistema contábil-fiscal-societário tem três camadas paralelas: contábil (CPC 06 R2 alinhado ao IFRS 16), fiscal (Lei 6.099/74, Lei 9.430/96 art. 13 e Lei 12.973/2014 RTT-RFB, com adições e exclusões na ECF Bloco K e Bloco M) e societário (Lei 6.404/76 art. 187 DRE, CVM Resolução 73/2022 e Deliberação 945/2024). As 17 etapas: extração contratual via LLM, verificação CPC 06 R2.9-12, isenções de curto prazo e de baixo valor, prazo razoavelmente certo, IBR, Right-of-Use e passivo, plano de amortização, depreciação ROU, reajustes por índice, modificações contratuais, dedutibilidade fiscal, plausibilidade, aprovação humana, lançamentos ECD e ECF, notas explicativas, validação ITR/DFP/FRE e arquivamento por 10 anos.

Um cenário concreto: empresa de tecnologia BR com 180 escritórios em coworking (WeWork, Regus, BeerOrCoffee), 8 sedes próprias e 220 laptops em leasing de TI, faturamento R$ 320 milhões/ano e Lucro Real ocupava dois Contadores em tempo integral. Após o Agente, o sistema importa do CLM (DocuSign Brasil), aplica LLM para extrair cláusulas, verifica deterministicamente as isenções (laptops abaixo de USD 5.000 cobertos pela de baixo valor e escritórios de coworking com menos de 12 meses cobertos pela de curto prazo) e apresenta ao Contador signatário CRC apenas os contratos materiais para julgamento de prazo razoavelmente certo, IBR e modificações. Tempo caiu de 3-4 horas/contrato para 15-20 minutos de revisão humana focada em julgamento.

No [Decision Layer](/br/decision-layer/), 3 das 17 etapas são decisões humanas (nível H) - julgamento intransferível do Contador signatário CRC: prazo razoavelmente certo (CPC 06 R2.18-21), taxa incremental de empréstimo (CPC 06 R2.26-27) e classificação de modificações (CPC 06 R2.44-46 e Deliberação CVM 945/2024). 12 etapas determinísticas (nível R) - cálculo de Right-of-Use, plano de amortização, depreciação, reajustes, dedutibilidade fiscal, lançamentos na ECF Bloco K e Bloco M, arquivamento. 2 plausibilidade aproximada (nível A) - extração LLM-assisted e rascunho de notas. Não há IA generativa em classificação ou mensuração - apenas extração textual inicial e rascunho de notas, com cálculo sempre determinístico.

## Plausibilidade contra portfólio histórico fecha o ciclo de erros materiais em IBR e prazo razoavelmente certo

A plausibilidade aproximada compara cada contrato contra portfólio histórico (mesmo segmento, classe de ativo, região, rating dos últimos 24 meses). Variação > 25% em Right-of-Use Asset aciona alerta com hipóteses: (1) IBR inconsistente com o benchmark (CDI mais spread por rating); (2) prazo razoavelmente certo classificado erroneamente para o máximo do contrato; (3) modificação material não declarada (CPC 06 R2.44-46); (4) reajuste por índice IPCA/IGP-M/CDI fora da data-base; (5) opção de compra incluída no passivo sem evidência de exercício razoavelmente certo; (6) isenção de baixo valor aplicada a ativos acima de USD 5.000. A divergência fica visível antes do fechamento mensal, em vez de aparecer em fiscalização CARF ou parecer com ressalva NBC TA 705.

Para validação de IBR, o Agente compara cada taxa contra o benchmark: curva DI Pré da B3, mais spread por rating (Moody's/S&P/Fitch BR), ajuste por prazo e ajuste por garantia. Desvio > 100bps aciona escalação ao Tesoureiro com derivação documentada. Para a implementação BR 2026 do Pillar Two BEPS GloBE (PLP 49/2024), o Agente mantém reconciliação por jurisdição: Right-of-Use Asset, depreciação ROU, juros BR, ajustes para GloBE Income (substância OECD) e alíquota efetiva BR comparada à mínima de 15%. Empresas com receita consolidada acima de EUR 750M ficam sujeitas a Top-up Tax se a alíquota efetiva BR ficar abaixo de 15% - o Agente exporta em formato compatível com Vertex Source ou Thomson Reuters ONESOURCE para o tax provision ASC 842 e o Pillar Two GloBE da matriz.

## Edge-cases brasileiros: leasing financeiro Lei 6.099/74, contratos em moeda estrangeira hedge, BOT/PPP em concessões públicas e Simples Nacional

Para situações atípicas, o Agente aplica regras específicas: (1) Leasing financeiro Lei 6.099/74 com requisitos contratuais mínimos (prazo mínimo de 24 meses para móveis e 36 meses para imóveis, opção de compra, valor residual) - aplicação do CPC 06 R2 com ajuste fiscal Lei 9.430/96 art. 13 via ECF Bloco M; (2) Contratos em moeda estrangeira (USD/EUR) - aplica CPC 06 R2, CPC 38/IAS 21 e hedge accounting CPC 48/IFRS 9; (3) BOT/PPP Lei 11.079/2004 (concessões públicas Sabesp/Cedae, Cemig/Copel, CCR/Ecorodovias) - até 3 obrigações de desempenho separadas com CPC 06 R2, CPC 47 e ICPC 12; (4) Sale-and-Leaseback (Magazine Luiza com lojas vendidas para FII e re-arrendadas) - CPC 06 R2.99-102 conforme critérios CPC 47 de transferência de controle; (5) Subarrendamento - contrato principal sob CPC 06 R2 e subarrendamento sob CPC 06 R2 ou CPC 47, dependendo da classificação operating/finance; (6) Contratos com partes relacionadas - Transfer Pricing IN RFB 1.312/2012 e Lei 14.596/2023 OECD para IBR e parcelas; (7) Simples Nacional e Lucro Presumido com ITG 1000 - uso predominante das isenções de curto prazo e de baixo valor.

## Integração com ecossistema BR de Lease Accounting: TOTVS, SAP S/4HANA LSAS, Oracle, Workday, LeaseAccelerator

A lógica do Agente conecta-se aos principais motores de Lease Accounting do mercado brasileiro via API: [TOTVS Protheus Gestão de Contratos com RM Fluig](https://www.totvs.com/) (líder de mercado em médio porte BR com módulo CPC 06 R2 nativo), [SAP S/4HANA Lease Administration and Settlement (LSAS) com Brazil Localization](https://www.sap.com/brazil/) (multinacionais como Volkswagen Brasil, Bayer, Bosch, BASF e Stellantis com reporting parental IFRS 16 e ECF Bloco K e Bloco M BR), [Oracle Lease and Finance Management com Brazil Localization](https://www.oracle.com/br/) (grupos IBOVESPA com matriz internacional), [Workday Lease Accounting Module](https://www.workday.com/) (empresas de tecnologia como Stefanini, Movile e Nubank com portfólio de escritórios em coworking WeWork/Regus e sedes próprias), [LeaseAccelerator](https://leaseaccelerator.com/) (cloud-native IFRS 16 e ASC 842 para grupos dos EUA como 3M, Cummins, John Deere e Caterpillar), [Senior Sistemas](https://www.senior.com.br/) (indústria pesada como Vale, Suzano, Braskem e Klabin com equipamentos em leasing financeiro Lei 6.099/74 - caminhões fora-de-estrada, locomotivas), Microsoft Dynamics 365 Finance com Lease Accounting Module e [TOTVS Mastersaf](https://www.mastersaf.com.br/) (obrigações fiscais BR com integração CPC 06 R2 e ECF Bloco M). Para PME no Lucro Presumido e Simples Nacional, integração com QuickBooks Online Brasil, Conta Azul, Bling ERP e Mastermaq Domínio para escrituração ITG 1000 simplificada (uso predominante das isenções de curto prazo e de baixo valor). Para empresas com matriz na Europa ou EUA (Volkswagen, Bosch, Siemens, Bayer, BASF), o Agente consolida a posição BR em formato compatível com SAP S/4HANA LSAS ou Oracle Lease and Finance Management da matriz - mantendo o cumprimento local (CPC 06 R2, ECF Bloco K e Bloco M, CVM Resolução 73/2022 e Deliberação 945/2024) e o reporting parental IFRS 16, Pillar Two GloBE e ASC 842.

--- Agente de Reporting Gerencial ---
> Calcula KPIs centrais (EBITDA, Working Capital, DSO, DPO), consolida dados, detecta anomalias, atualiza dashboards e prepara o reporting para o conselho.

Equipes financeiras dedicam segundo levantamentos atuais cerca de 300 horas por ano a trabalho manual de reporting - tempo que não flui para análise nem para preparação de decisões (fonte: Float Financial, 2025). O gargalo no reporting gerencial não está na interpretação de indicadores. Está na consolidação que antecede toda interpretação.

## Consolidação consome o tempo que falta para análise

Um fechamento mensal típico em empresas de médio e grande porte leva seis a dez dias úteis. Depois começa o trabalho efetivo do controller: reunir dados de contabilidade, controladoria, tesouraria e sistemas operacionais, executar eliminações, calcular KPIs, construir comparações com mês e ano anterior. Só quando essa base está pronta o cockpit do CFO pode ser atualizado.

Na prática, isso significa: os números estão tecnicamente corretos no 5o dia útil - mas o deck para o conselho só fica pronto no 8o ou 9o. Não porque a análise seja complexa, mas porque três dias se perdem na consolidação manual de exports de Excel, extrações de ERP e relatórios de controladoria. Cada ciclo de reporting repete o mesmo esforço porque a lógica de consolidação não existe em lugar algum como processo reutilizável.

## Cálculo de KPIs baseado em regras encurta o ciclo em dias

EBITDA, Working Capital, DSO, DPO e Cash Conversion Cycle seguem fórmulas definidas. Não há margem de interpretação na questão de como o DSO é calculado - apenas na questão do que um DSO crescente significa para o negócio. Exatamente aí o [Decision Layer](/br/decision-layer/) atua.

O agente de reporting gerencial assume a primeira categoria completamente: obtém os valores consolidados da contabilidade e controladoria, aplica as fórmulas de cálculo configuradas e atualiza o dashboard automaticamente assim que o fechamento mensal é marcado como completo. A fonte de dados, a fórmula aplicada e o resultado são documentados para cada KPI - reproduzível e auditável.

Empresas que automatizam sua consolidação reportam uma redução do ciclo close-to-report de 50 por cento (fonte: Deloitte CFO Signals Survey, H4 2025). De oito dias para quatro. De um processo de reporting reativo para um ritmo no qual o conselho pode confiar.

## Detecção de anomalias torna o reporting proativo em vez de reativo

A informação mais valiosa em um relatório mensal não é a confirmação de que tudo está conforme planejado. É a identificação precoce de desvios antes que se tornem itens a explicar no próximo relatório trimestral.

O agente compara cada KPI calculado com faixas históricas e valores esperados estatísticos. Se o DSO sobe 12 dias ou o Working Capital mostra um salto fora da norma sazonal, isso é marcado - não como alarme, mas como sugestão de comentário com dados de contexto. O controller recebe um rascunho que nomeia a anomalia, contextualiza a evolução histórica e deriva possíveis causas dos dados de origem.

Isso muda fundamentalmente o papel do controller: em vez de buscar números que possam precisar de explicação, ele começa com uma lista priorizada e investe seu tempo na análise de causas.

## A narrativa estratégica permanece com o CFO

O que um Cash Conversion Cycle crescente significa para as negociações com fornecedores no próximo trimestre, qual evolução de KPI requer explicação especial no relatório de gestão, como os números devem ser contextualizados perante o conselho - essas são decisões que pressupõem conhecimento do negócio, experiência setorial e julgamento estratégico.

O Decision Layer traça aqui uma fronteira clara. Sete das oito etapas de decisão no processo de reporting funcionam de forma baseada em regras ou assistida por IA. A oitava - a interpretação estratégica - permanece com o humano. Não como concessão, mas como decisão arquitetônica: um CFO que constrói seu deck a partir de um rascunho preparado com KPIs documentados e anomalias marcadas toma melhores decisões do que um que gasta a primeira metade do seu tempo com consolidação de dados.

## Deck pronto no 6o dia útil em vez do 10o, quatro dias de folga em vez de pressão

Um cenário concreto: uma empresa industrial com quatro unidades de negócio, reporting consolidado para a holding e reunião mensal do conselho no 10o dia útil. Antes da automatização, o deck pronto ficava disponível no máximo no 8o dia útil - com correções regulares até a véspera da reunião.

Após a implementação do agente de reporting gerencial, os KPIs consolidados estão disponíveis no 3o dia útil. Anomalias estão marcadas e pré-comentadas. O head de controladoria utiliza o 4o e 5o dia útil para a contextualização estratégica e a narrativa - não para a consolidação. No 6o dia útil, o deck vai para o CFO. Quatro dias de folga em vez de dois dias de pressão.

--- Agente de Execução de Pagamentos ---
> Execução de pagamentos em lote via PIX, TED, CNAB 240/400 e Boleto DDA, incluindo DARF, GPS e FGTS, com aprovação em quatro olhos da Tesouraria.

A execução de pagamentos no Brasil é um pipeline regulatório com sete camadas simultâneas: o BACEN (Banco Central) regula PIX (Resoluções BCB 195/2022 e 393/2024) com janelas de horário e limites diferenciados, a FEBRABAN padroniza os layouts CNAB 240 e CNAB 400 multibanco, a Receita Federal exige DARF para IRRF e tributos federais (Decreto 9.580/2018), o INSS exige GPS para encargos previdenciários (Lei 8.212/91), a Caixa Econômica Federal recolhe FGTS (Lei 8.036/90), o COAF aplica PLD-FT em transferências significativas (Lei 9.613/98 e Circular BACEN 3.978/2020), e a ANPD fiscaliza dados de fornecedores conforme LGPD (Lei 13.709/2018). Cada batch errado carrega risco fiscal duplo: multa moratória de 0,33%/dia limitada a 20% sobre tributos federais com juros Selic, e bloqueio de Certidão Negativa de Débitos (CND) que impede licitações públicas Lei 14.133/21 e financiamentos BNDES, FINEP e Caixa.

## Pagamento atrasado de DARF, GPS ou FGTS gera multa de 0,33%/dia até 20%, juros Selic mais 1%/mês e bloqueio de CND, impedindo licitações Lei 14.133/21 e o BNDES

Uma indústria de médio porte com folha mensal de R$ 8 milhões recolhe mensalmente cerca de R$ 1,2 milhão em INSS patronal (GPS - Lei 8.212/91 art. 30), R$ 640 mil em FGTS (Lei 8.036/90 art. 15), R$ 320 mil em IRRF retido em folha (DARF - Decreto 9.580/2018) e mais R$ 280 mil em PIS/COFINS, IRPJ-CSLL conforme regime tributário Lucro Real (Lei 9.430/96). Um único batch atrasado em 30 dias gera: multa 0,33%/dia (até o limite legal de 20%, atingido em ~60 dias), juros Selic mais 1% ao mês (em 2026 ~14% a.a.), e bloqueio automático de CND no e-CAC da Receita Federal e no portal da Caixa para FGTS.

A consequência prática vai além do encargo monetário: sem CND válida, a empresa não pode participar de licitações públicas (Lei 14.133/21 art. 68), não renova credenciamento na Caixa Econômica para folha, não acessa financiamentos BNDES (FINAME, BNDES Automático), FINEP (Inovacred) ou capital de giro Caixa subsidiado, e em fiscalização agressiva a Receita Federal pode arrolar bens e direitos da empresa (Lei 9.532/97 art. 64) bloqueando alienação de imobilizado. Para uma indústria com R$ 80 milhões de faturamento e dependência de licitações públicas (cerca de 30% da receita típica), o impacto pode chegar a R$ 24 milhões em receita perdida no exercício seguinte. E os atrasos típicos não são fraude - são erros de processamento manual: arquivo CNAB com header errado rejeitado pelo banco às 16h59 do dia 20, falta de saldo em uma conta corrente específica enquanto outra tem sobra, chave PIX inativa no DICT BACEN, certificado digital A3 expirado no token sem renovação tempestiva.

## A execução de pagamentos brasileira percorre 15 etapas determinísticas, não 8

Diferente do modelo alemão padrão (8 etapas, focado em SEPA-XML pain.001 e GoBD) ou do polonês (10 etapas, com KSeF e split payment MPP), a execução de pagamentos brasileira CLT-compliant exige 15 etapas determinísticas porque o sistema de pagamentos tem mais modalidades e mais regulação: identificação de NF-e e CT-e por vencimento (Código Civil art. 397 mora ex re), cálculo de desconto vs custo de oportunidade pela Selic, escolha entre PIX (Resolução BCB 195/2022 - 24/7), TED (dia útil 6h-17h30) e boleto DDA (Lei 14.690/2023), validação de chave no DICT BACEN, validação de linha digitável de boleto com DV módulo 10 e módulo 11, cálculo de retenção tributária (IRRF/ISS/INSS), geração de DARF/GPS/FGTS para encargos sociais com vencimentos próprios, verificação de duplicidade contra histórico 90 dias, screening PLD-FT (Lei 9.613/98) acima de R$ 50.000 contra listas OFAC/CSNU/CGU/CNJ, verificação de saldo multibanco (Itaú, Bradesco, BB, Caixa, Santander), priorização legal em liquidez restrita (tributos federais e pensão alimentícia têm precedência - Código Civil art. 304), geração de CNAB 240 ou CNAB 400 conforme layout FEBRABAN, assinatura digital ICP-Brasil A1 ou A3 (Lei 14.063/2020), quatro olhos Tesouraria, e conciliação de retorno CNAB ou webhook PIX (CONCLUDED/REJECTED/REFUNDED).

Um cenário concreto: indústria química com 500 NF-e semanais e 7 contas correntes em 5 bancos diferentes ocupava dois analistas de Tesouraria por dois dias inteiros para preparar o batch quinzenal. Antes da automação, o aproveitamento de desconto financeiro de fornecedores ficava em torno de 55%, não por má fé, mas porque o percurso manual da seleção de NF-e até o arquivo CNAB consumia 3-4 dias - tempo em que muitos prazos de desconto já tinham expirado. Após a introdução do Agente, o sistema seleciona 487 NF-e elegíveis (28 com desconto financeiro vigente, 459 com vencimento na janela), calcula o trade-off Selic vs desconto para cada uma (decisão R), valida 412 chaves PIX no DICT BACEN, agrupa 75 boletos via DDA, gera DARF para R$ 320 mil de IRRF retido, GPS para R$ 1,2 milhão de INSS, FGTS para R$ 640 mil, faz screening PLD-FT em 12 fornecedores acima do limite COAF (zero hit positivo nas listas OFAC/CSNU), e prepara o batch CNAB 240 para 5 bancos diferentes em 11 minutos de processamento. O Tesoureiro e o Diretor Financeiro aprovam o batch em quatro olhos via certificado A3 ICP-Brasil (decisão H), e o Agente envia para os bancos com retorno em D+0 para PIX e D+1 para CNAB. O aproveitamento de desconto sobe para 92%, gerando economia anual de R$ 480 mil em descontos capturados que antes se perdiam.

No [Decision Layer](/br/decision-layer/), 13 das 15 etapas são decisões baseadas em regras (nível R) - cada uma é cálculo determinístico contra Resolução BCB, manual FEBRABAN, tabela RFB ou validação de DV - e 2 são decisões humanas obrigatórias (nível H): priorização em caso de liquidez restrita (que envolve julgamento sobre fornecedor crítico vs prazo legal) e aprovação quatro olhos da Tesouraria. Não há ponto em que IA generativa decida sobre movimentação financeira - cada validação é a aplicação de uma norma BACEN, FEBRABAN, RFB ou Lei 14.063/2020.

## Open Finance Brasil moderniza tesouraria multibanco em tempo real

A Resolução CMN 4.951/2021 e a Resolução BCB 109/2021 implementam em fases (2020-2026) o Open Finance Brasil, com três aplicações práticas para o pipeline de pagamento: consulta multibanco de saldo agregado (todos os bancos onde a empresa tem conta) sem login individual, iniciação de pagamento via API (ITP - Iniciador de Transação de Pagamento) eliminando CNAB tradicional para volumes baixos, e conciliação em tempo real via webhook autenticado por mTLS. Para empresas com mais de 5 bancos relacionados (típico em médias e grandes empresas BR), o ganho é eliminar a verificação manual de saldo em 5 portais bancários diferentes - o Agente consulta o agregador Open Finance e prioriza qual conta debitar.

A regulação exige consentimento explícito do correntista (TPP - Third Party Provider autorizado pelo BACEN) com renovação a cada 12 meses, e logs auditáveis de cada API call. Empresas com volume alto (mais de 100 pagamentos/dia) ainda usam CNAB 240 batch por eficiência operacional - o ITP Open Finance tem latência de 1-3 segundos por pagamento individual, inviável para batches de milhares - mas para volumes pequenos a médios e tesouraria intra-day, o Open Finance é a tendência consolidada.

## Edge-cases brasileiros: PLD-FT acima do limite COAF e priorização tributária

Para fornecedores com pagamento individual acima de R$ 50.000 ou acumulado de R$ 100.000 mês (Circular BACEN 3.978/2020 art. 13), aplica-se diligência reforçada PLD-FT (Lei 9.613/98). O Agente faz screening determinístico contra cinco listas: OFAC SDN (EUA), CSNU (sanções ONU), Cadastro Nacional de Empresas Inidôneas e Suspensas (CGU), CNJ (Cadastro Nacional de Condenados), e PEP (Pessoas Expostas Politicamente, base CGU). Hit positivo bloqueia o pagamento e encaminha ao Compliance Officer para revisão; em caso de operação suspeita confirmada, comunicação obrigatória ao COAF (SISCOAF) em até 24 horas conforme Lei 9.613/98 art. 11.

Em situações de liquidez restrita (saldo total insuficiente para todo o batch), o Agente aplica priorização legal: tributos federais (DARF, GPS, FGTS - vencimentos não prorrogáveis com multa 0,33%/dia limitada a 20%) têm precedência absoluta sobre fornecedores comerciais; pensão alimentícia em folha (Código Civil art. 304-313 e CPC art. 529-533) e penhora judicial precedem os demais pagamentos; e dentro da fila comercial, fornecedores críticos (utilities energia/água/telecom, fornecedores monopolistas) precedem outros. Essa priorização é decisão humana (H) - o Agente sugere a fila baseada em criticidade configurada, mas o Tesoureiro confirma e o Diretor Financeiro aprova em quatro olhos.

## Integração com ecossistema brasileiro: TOTVS, SAP, Senior, Mastermaq e Open Finance

A lógica do Agente conecta-se aos principais sistemas de gestão financeira do mercado brasileiro via API: [TOTVS Protheus FI/CO com Módulo Bancário](https://www.totvs.com/) (líder em médias e grandes empresas com geração CNAB 240/400 nativa para todos os bancos brasileiros e integração PIX), TOTVS RM Saldus e Datasul (forte em manufatura), [SAP S/4HANA Brazil Localization](https://www.sap.com/brazil/) com módulo DMEE Brazil (Data Medium Exchange Engine - geração de CNAB 240/400 multibanco, IBOVESPA e multinacionais), [Senior Sistemas Financeiro](https://www.senior.com.br/) (forte em indústria com mais de 5.000 clientes BR e integração FEBRABAN nativa), Oracle ERP Cloud Brazil Localization Cash Management (gigantes IBOVESPA), e [Mastermaq Domínio Sistemas](https://www.mastermaq.com.br/) (escritórios contábeis e PME com foco em DARF/GPS/FGTS automatizado). Para integração Open Finance Brasil, o Agente conecta-se via TPPs autorizados pelo BACEN (Belvo Brasil, Pluggy, Klavi, Iniciador.com) com mTLS e oAuth 2.0 conforme padrão técnico do BACEN. Para empresas com matriz na Europa ou EUA (Volkswagen, Bosch, Siemens, GE com unidades brasileiras), o Agente também consolida a posição financeira BR em formato compatível com tesouraria global SAP TRM ou Kyriba - mantendo a operação local PIX/CNAB/DARF/GPS/FGTS compliant e o reporting parental sob padrões internacionais.

--- Agente de Tráfego de Pagamentos ---
> Determina formato (SEPA, SWIFT), cria arquivos SEPA-XML, transmite ao banco, processa retornos e garante quatro olhos para pagamentos únicos acima do limiar.

Um pagamento está aprovado, o IBAN está errado, o arquivo é rejeitado. Três dias depois, o fornecedor pergunta pelo dinheiro. Esse cenário custa não apenas liquidez, mas confiança. No tráfego de pagamentos europeu, a fraude em transferências somou segundo EBA e BCE 2,2 bilhões EUR (aprox. 2,4 bilhões USD) em 2024 - e erros de formato, dados de destinatário incorretos ou escalações tardias de rejeições vêm por cima. A última milha entre aprovação e transmissão bancária merece portanto a mesma disciplina de processo que a própria aprovação.

## Entre aprovação e transmissão bancária surgem os erros mais caros

O agente de execução de pagamentos decide o que é pago e quando. Mas a questão de como o pagamento chega tecnicamente ao banco permanece aberta. Exatamente aí atua o agente de tráfego de pagamentos. Ele determina o formato - SEPA, SWIFT ou cheque - com base nos dados cadastrais do destinatário, gera o arquivo pain.001 e o transmite via EBICS ou API. Isso soa como pura técnica. Na prática, porém, pagamentos falham não pela aprovação, mas por códigos BIC errados, campos obrigatórios ausentes ou certificados expirados. Uma equipe de tesouraria que processa 400 pagamentos por dia não consegue verificar esses erros individualmente. Um agente baseado em regras, sim.

## Dez etapas de decisão substituem o workaround manual

O [Decision Layer](/br/decision-layer/) decompõe o caminho do pagamento em dez etapas: escolha de formato, validação de IBAN e destinatário, verificação de pagamento duplicado, triagem de listas de sanções, verificação da obrigação de declaração AWV, geração XML, transmissão bancária, processamento de retornos, escalação em caso de falha e aprovação de quatro olhos para pagamentos únicos acima do limiar. Nove dessas etapas são completamente baseadas em regras. O formato de pagamento deriva dos dados cadastrais do destinatário, a validação pain.001 segue o padrão SEPA, a transmissão bancária é um handshake técnico, e mensagens de erro são automaticamente analisadas e escaladas ao responsável. Somente em pagamentos únicos acima do limiar configurado o humano intervém. Esse padrão - conjunto de regras para o volume, controle humano para o risco - é a assinatura de um Decision Layer de nível 1.

## Verification of Payee muda fundamentalmente os requisitos

Desde outubro de 2025, todas as instituições de crédito no EEE são obrigadas a realizar uma verificação do destinatário antes de cada transferência SEPA. O nome informado é comparado com o titular real da conta. Para o agente de tráfego de pagamentos, isso significa: cada pagamento de saída passa por uma etapa adicional de validação antes de chegar ao banco. Divergências entre dados cadastrais e titular da conta são reconhecidas e documentadas antes que o dinheiro flua. Bancos relatam que a verificação de sanções mais rigorosa sob SEPA Instant resulta em 30 a 50 por cento mais transações sinalizadas. Um agente que processa esses retornos em tempo real impede que pagamentos válidos fiquem presos na fila de verificação.

## O humano decide onde automatização geraria risco

A aprovação de quatro olhos para pagamentos únicos elevados não é uma concessão à falta de confiança na tecnologia. É uma exigência do sistema de controle interno que o Decision Layer deliberadamente mantém como decisão humana. Pois em um pagamento único atípico acima de 50.000 ou 100.000 EUR, conformidade com regras não basta - é necessário julgamento comercial. O padrão contábil GoBD (padrão GoBD alemão de arquivamento fiscal) (SPED Contábil / Lei 8.846/94 como equivalente brasileiro) exige que cada pagamento seja documentado de forma rastreável como transação comercial. O agente fornece essa documentação automaticamente: formato de pagamento, momento da transmissão, retorno bancário e, para pagamentos únicos, o momento da aprovação com a pessoa aprovadora. O protocolo de tráfego de pagamentos surge como subproduto do processo, não como obrigação retroativa.

--- Agente Cálculo Folha CLT ---
> Cálculo Bruto-Líquido CLT por funcionário: INSS tabela progressiva, FGTS 8%, IRRF IN RFB 1.500/2014, 13o salário em duas parcelas, férias com 1/3 e pensão alimentícia §529 CPC.

Cálculo de folha CLT é aritmética legalmente vinculada. O salário bruto está no contrato CLT registrado em CTPS. Os adicionais (noturno 20%, periculosidade 30%, insalubridade 10-40%) estão na CLT e na CCT/ACT do sindicato. O INSS empregado segue a tabela progressiva publicada anualmente pela Previdência Social (faixas 7.5% / 9% / 12% / 14% até teto R$ 7.786,02 em 2026). O FGTS é fixo em 8% sobre a remuneração, depositado pela empresa na Caixa Econômica. O IRRF segue a tabela progressiva mensal da Receita Federal. A pensão alimentícia tem ordem judicial específica conforme CPC arts. 529-533. Nenhuma etapa exige julgamento humano. Mesmo assim, em departamentos típicos de folha brasileiros surgem regularmente correções por período de processamento - e desde o eSocial faseado, cada correção gera evento de retificação com prazo regulatório de envio.

## Atrasos no eSocial geram multa de R$ 800 a R$ 2.500 por evento e bloqueio da CND

Cada evento eSocial enviado fora de prazo gera multa progressiva conforme art. 472-D CLT (Lei 13.467/2017). Para a empresa típica de médio porte com 800 colaboradores, isso significa: cada folha mal calculada que gera retificação S-1200 ou S-1210 fora do prazo da competência adiciona R$ 800 a R$ 2.500 em multa por evento. Com 30 retificações em um ciclo problemático, a conta sobe rápido para R$ 24-75 mil em multas - sem contar o bloqueio da CND (Certidão Negativa de Débitos) que impede participação em licitações públicas e renovação de financiamentos junto a BNDES, FINEP e bancos comerciais.

A American Payroll Association e estudos da PwC Brasil quantificam o custo direto de retificação em torno de USD 281 por incidente, mas o dano colateral brasileiro vai além: bloqueio CND, multas eSocial, possível Reclamação Trabalhista por diferença salarial (prazo prescricional de 2 anos pós-rescisão CLT) e exposição em fiscalização da Receita Federal cruzando GFIP/SEFIP histórico com eSocial atual. Para o CFO de uma operação CLT, cada erro de folha desencadeia seis vetores de impacto - operacional (capacidade do RH), financeiro (multa eSocial direta), regulatório (bloqueio CND), trabalhista (passivo TRT), tributário (IRRF correção), e de reputação (sindicato categoria notificado).

## A folha CLT percorre 17 etapas determinísticas, não 12

Diferente do cálculo alemão padrão (12 etapas), a folha brasileira CLT requer 17 etapas determinísticas porque o sistema previdenciário, fiscal e trabalhista é mais granular: 13o salário em duas parcelas separadas (novembro sem INSS, dezembro com INSS), férias com adicional constitucional de 1/3 (art. 7 XVII CF/88), INSS progressivo em quatro faixas (7.5% até R$ 1.518, 9% até R$ 2.793, 12% até R$ 4.190, 14% até teto R$ 7.786 em 2026), INSS patronal com componente RAT individualizado por CNAE (1%, 2% ou 3%) e Terceiros (~5.8% para SENAI, SESI, SEBRAE etc.), FGTS depositado pelo empregador para Caixa Econômica (8% sobre remuneração - sem contribuição do empregado), IRRF tabela progressiva mensal com dedução por dependente (R$ 189,59 em 2026), e geração simultânea de eventos eSocial S-1200 e S-1210 com prazo da Portaria Conjunta RFB/MTP/INSS.

Um cenário concreto operando no Brasil: indústria com 800 colaboradores CLT, 120 em turnos com adicional noturno (art. 73 CLT, 20% sobre hora normal) e DSR conforme acordo coletivo, 30 com pensão alimentícia ordenada por TJ. Em novembro, 1a parcela do 13o (50% sem INSS/IRRF). Em dezembro, 2a parcela do 13o com cálculo separado de INSS e IRRF. Para a folha: 800 cálculos individuais, dos quais 120 com adicional noturno e DSR, 30 com aplicação de tabela de pensão CPC, 800 antecipações de 13o em novembro, depois 800 fechamentos de 13o em dezembro mais a geração de eSocial S-1200 mensal e S-1299 anual. Tudo dentro de prazo regulatório.

No [Decision Layer](/br/decision-layer/), cada uma dessas 17 etapas é uma decisão baseada em regras (nível R). O salário bruto vem do contrato CTPS. Os adicionais seguem CCT/ACT vigente do sindicato. A pensão segue ordem judicial e tabela CPC. O INSS é calculado pela tabela progressiva 2026 da Previdência Social. O IRRF é calculado pela tabela mensal da Receita Federal com dedução de dependentes. O FGTS é depositado para Caixa via SEFIP/eSocial. Não há ponto em que um analista de folha precise tomar uma decisão discricionária - exceto quando o agente sinaliza desvio acima de 10% do mês anterior para revisão humana.

## Comparação com mês anterior captura erros silenciosos antes do eSocial

Baseado em regras não significa livre de erros. Um valor de hora incorretamente registrado no ponto eletrônico, uma alteração de classe IRRF cadastrada tardiamente, uma CCT renovada não importada, um benefício consignado esquecido - esses erros de input são a causa mais frequente de retificações eSocial. Por isso, a 17a etapa de decisão inclui verificação automática de plausibilidade ANTES da transmissão S-1200.

O agente compara cada cálculo com o mês anterior. Se o valor líquido desvia mais de 10% sem causa documentada (1a/2a parcela de 13o, alteração de CCT, mudança de classe IRRF, dependente cadastrado/baixado, ascensão funcional), o cálculo é marcado para revisão pelo gestor de RH. O gestor vê não apenas o desvio absoluto, mas o caminho exato de cálculo - qual componente mudou, qual CCT entrou em vigor, qual ponto eletrônico está fora do padrão. Este é o único ponto em todo o processo em que um humano intervém: não para calcular, mas para avaliar uma anomalia antes da transmissão eSocial - evitando o evento S-1295 de retificação.

## Pensão alimentícia, afastamento e estabilidade exigem precisão sem margem

Casos especiais como pensão alimentícia, afastamento por doença ou estabilidade após acidente de trabalho parecem complexos, mas são completamente determinados por lei brasileira. A tabela de descontos em folha conforme CPC art. 529 fornece o valor a reter exatamente - dependendo do rendimento líquido e da ordem judicial específica. Havendo múltiplas obrigações (pensão, consignado e contribuição sindical), a CLT art. 462 e a Lei 10.820/2003 estabelecem ordem e limite (70% global, 35% para consignado privado).

Continuidade salarial em afastamento por doença é diferente do modelo alemão: primeiros 15 dias por conta do empregador (art. 60 §3 Lei 8.213/91), depois auxílio-doença INSS direto ao empregado, vínculo CLT mantido (sem FGTS no período afastado), retorno gera S-2299. Estabilidade pós-acidente de trabalho (art. 118 Lei 8.213/91) garante 12 meses de não-demissão arbitrária após retorno. Estabilidade gestante (art. 10 II ADCT) vai da confirmação até 5 meses pós-parto. Cada uma destas regras altera o cálculo de folha e o evento eSocial gerado. O agente aplica o conjunto de regras de forma completa e rastreável, com cada cálculo documentado e imediatamente rastreável para Auditoria-Fiscal Trabalhista MTE, fiscalização Receita Federal ou perícia do INSS.

## Integração com ecossistema brasileiro: TOTVS, Senior, ADP, SAP, eSocial

A lógica do agente conecta-se aos principais sistemas de folha do mercado brasileiro via API: [TOTVS RM](https://www.totvs.com/) (líder em médias e grandes empresas brasileiras), [Senior Sistemas HCM](https://www.senior.com.br/) (forte em indústria), ADP Brasil (multinacionais), SAP HCM PY-BR (DAX e IBOVESPA), Mastermaq Domínio (escritórios contábeis e empresas de pequeno porte). A geração de eventos eSocial usa o webservice do Portal eSocial com certificado digital A1 ou A3 ICP-Brasil. A conciliação contábil exporta lançamentos para o ERP financeiro (Protheus, SAP FI, Oracle ERP, IFS) com plano de contas alinhado ao CPC e ao RIR/2018. Para empresas com matriz na Europa (Volkswagen, Renault, BMW, Stellantis com unidades brasileiras), o agente também gera relatórios paralelos compatíveis com IFRS para consolidação na sede - mantendo a folha local CLT-compliant e o reporting parental sob padrões internacionais.

--- Agente Correção Folha ---
> Correções retroativas de folha: estorno eSocial S-3000, ajustes INSS Lei 8.212/91, retificação IRRF IN RFB 1.500/2014 e impacto fiscal/previdenciário - com aprovação em quatro olhos.

Correções de folha custam às empresas não pela diferença propriamente dita - mas pelo esforço de recalculá-la corretamente. O EY Global Payroll Survey 2022 documenta: uma a cada cinco rodadas de folha contém erros, por colaborador em tempo integral são consumidas 29 semanas por ano apenas com correção de erros. Para 1.000 colaboradores, o esforço direto de correção soma rapidamente valores de seis algarismos em USD por ano. O agente de correção de folha assume o cálculo baseado em regras incluindo efeitos fiscais e previdenciários. A aprovação permanece com o humano.

## Uma em cada cinco folhas contém erros

As causas são variadas e muitas vezes sistêmicas: reajustes retroativos de convenção coletiva, horas extras lançadas com atraso, relatórios de despesas de viagem entregues fora do prazo e alterações indevidas de dependentes ou faixa de IRRF. O EY Global Payroll Survey documenta que uma a cada cinco rodadas de folha apresenta falha. Cada erro individual gera uma cadeia de cálculos consequentes: diferença bruta, IRRF, INSS, FGTS e demais encargos sobre a remuneração.

Um cenário concreto: um reajuste de convenção é acordado retroativamente a janeiro e a informação só chega à folha em abril. Por três meses, todos os componentes salariais precisam ser recalculados - para cada colaborador afetado individualmente, porque dependentes, deduções e base de contribuição são diferentes. Com 200 colaboradores afetados surgem 200 correções individuais, cada uma com dez etapas de cálculo.

## Recálculo manual vincula os recursos mais caros

O problema real não é a correção em si. A aritmética é inequívoca: novo cálculo menos cálculo antigo resulta na diferença bruta. Efeitos fiscais e previdenciários seguem regras fixas da legislação tributária e previdenciária. O que efetivamente onera as empresas é o tempo de profissionais qualificados.

Especialistas em folha com conhecimento em direito tributário e previdenciário passam horas executando cálculos que um conjunto de regras realiza em segundos. Os custos médios por correção individual são de 281 USD em custos diretos (EY). Em casos complexos como licenças médicas não registradas, o valor sobe para mais de 700 USD. Simultaneamente, esses profissionais fazem falta para tarefas que efetivamente requerem julgamento - como a avaliação de casos controversos ou a comunicação com colaboradores afetados.

A área de folha de pagamento precisa reservar pelo menos dois ciclos de processamento para concluir as correções de forma limpa. Nesse intervalo, novos casos se acumulam.

## O agente calcula - o humano decide

O [Decision Layer](/br/decision-layer/) decompõe cada correção de folha em suas etapas de decisão e atribui a cada etapa o decisor correto. Sete das dez etapas são baseadas em regras: identificação de diferença, período retroativo, cálculo de correção, efeito fiscal, correção previdenciária, diferença líquida e lançamento contábil. Essas seguem as prescrições de cálculo da legislação tributária e previdenciária - sem margem discricionária, sem necessidade de interpretação.

Duas etapas utilizam suporte de IA no nível 1: a classificação de causa contextualiza - trata-se de uma alteração de convenção, um erro de registro ou uma declaração retroativa? A comunicação ao colaborador prepara uma explicação compreensível da correção para que o colaborador afetado possa entender por que seu salário líquido mudou.

A décima etapa permanece com o humano: a aprovação no princípio de quatro olhos. Nenhum lançamento de correção deixa o sistema sem verificação e confirmação humana.

## Documentação conforme padrão contábil surge automaticamente

Correções de folha são fatos contábeis. O padrão brasileiro de escrituração fiscal e arquivamento (SPED Contábil, Lei 8.846/94) exige que o cálculo original permaneça imutável. As correções ocorrem exclusivamente pelo estorno do antigo e pela criação de um novo cálculo. O agente gera essa cadeia de comprovantes automaticamente - cálculo original, comprovante de estorno e cálculo corrigido -, vinculados sem lacunas e documentados de forma à prova de auditoria.

Para cada correção, o Decision Layer protocola a cadeia de decisão completa: causa com classificação, período afetado, diferença bruta, diferença fiscal, diferença previdenciária, diferença líquida, lançamento resultante bem como momento da aprovação e pessoa aprovadora. Em uma auditoria, todo o caminho de cálculo está aberto - não como documentação retroativa, mas como subproduto do próprio processo.

--- Agente eSocial e Encargos Folha ---
> Transmissão eSocial S-1200/S-1210 mensal, DCTFWeb, GFIP, GPS e comprovante IRRF anual via DARF código 0561 - evita auto de infração RFB Lei 9.430/96 art. 44 e Lei 8.137/90.

Os encargos sociais sobre folha no Brasil são o ponto em que a Diretoria de Folha prova diligência legal diante de oito fiscalizações simultâneas: a Receita Federal cruza o eSocial S-1299 contra a DCTFWeb e os DARFs recolhidos (código 0561 para o IRRF assalariado e 1099 para o INSS); o INSS fiscaliza a contribuição patronal de 20%, o RAT/FAP individualizado e os Terceiros (cerca de 5,8%), com cobrança retroativa de 5 anos; a Caixa Econômica Federal recebe o FGTS de 8% pela GRF e fiscaliza o atraso de depósito (multa de R$ 10,64 mais 0,5% de TR ao mês); a Auditoria-Fiscal Trabalhista do MTE inspeciona a conformidade com a CLT e aplica multa de R$ 800 a R$ 2.500 por evento de eSocial atrasado (Lei 10.426/2002 art. 7); a Justiça do Trabalho executa as retenções de pensão alimentícia (CPC art. 529 § 3), com responsabilidade pessoal do empregador em caso de descumprimento; o CARF julga as autuações federais com multa de ofício de 75% a 150% (Lei 9.430/96 art. 44); o COAF exige comunicação ao Siscoaf em 24h de operações suspeitas em folha (funcionários fantasmas, salários incompatíveis e contas em paraíso fiscal); e a PGFN inscreve em dívida ativa as contribuições previdenciárias não recolhidas, com bloqueio de CND federal. Cada rubrica mal classificada carrega risco quádruplo: glosa pela Receita Federal com multa de 75% a 150% acrescida de Selic e 1% ao mês, autuação retroativa do INSS por 5 anos, bloqueio de CND federal e estadual que impede licitações (Lei 14.133/21) e financiamentos do BNDES, FINEP e Caixa, e responsabilidade pessoal do administrador em caso de descumprimento de ordem de pensão alimentícia.

## Glosa da Receita Federal com multa de 75 a 150% (Lei 9.430/96), bloqueio duplo de CND federal e estadual, autuação retroativa do INSS por 5 anos e a Auditoria-Fiscal Trabalhista do MTE quebram a apuração mensal da folha

Uma empresa industrial de médio porte com 1.200 funcionários CLT distribuídos em 4 plantas em três estados, 35 categorias profissionais com CCT/ACT distintas (metalúrgicos em São Paulo, químicos no Rio Grande do Sul, automobilística no ABC paulista), faturamento de R$ 480 milhões/ano, regime de Lucro Real e CNAE 2910-7/01 (RAT de 3% e FAP de 1,2, resultando em RAT efetivo de 3,6%) faz cerca de 1.200 cálculos de folha por mês, com obrigação de transmitir o eSocial, gerar DARF e compor a DCTFWeb. Antes da automação, dois analistas de folha sênior, três analistas pleno e um coordenador de RH gastavam de 5 a 7 dias úteis por mês fechando a folha: calculavam rubricas variáveis (horas extras, adicionais e comissões), aplicavam o INSS do empregado pela tabela progressiva, o INSS patronal de 20%, o RAT efetivo de 3,6%, os Terceiros de 5,8%, o FGTS de 8% e o IRRF pela tabela progressiva 2026 com dedução de dependentes e pensão alimentícia, transmitiam o eSocial S-1200/S-1210 e fechavam o S-1299 no limite do prazo, dia 15.

A consequência prática vai além do custo de mão de obra: o empregador é integralmente responsável pelo recolhimento dos encargos sociais - o INSS do empregado retido em folha, o INSS patronal, os Terceiros, o FGTS e o IRRF -, nunca o empregado. Em fiscalização da Receita Federal pós-2020, divergências entre o eSocial S-1299 e a DCTFWeb (omissão de R$ 180 mil em INSS patronal porque o RAT ficou em 3% sem aplicar o FAP de 1,2) viraram autuação de R$ 540 mil em multa e R$ 180 mil de tributo, somados Selic e juros - total de R$ 800 mil a 1 milhão sobre uma divergência operacional. Um mês de atraso na transmissão do eSocial S-1200 gerou multa da Auditoria-Fiscal Trabalhista do MTE de R$ 800 a R$ 2.500 por evento, ou de R$ 960 mil a 3 milhões para a empresa em questão (1.200 funcionários a R$ 800, o mínimo). O descumprimento de ordem judicial de pensão alimentícia (3 ordens ativas) gera responsabilidade pessoal direta do administrador (CPC art. 533 § 3), com penhora de bens pessoais. E a implementação do Pillar Two BEPS no BR a partir de 2026 (PLP 49/2024) obriga grupos multinacionais com receita acima de EUR 750M a documentar a tax equalization dos expatriados por jurisdição - sem uma ferramenta que trate duas jurisdições, a empresa precisa reescrever o motor de folha a cada novo expatriado.

## Os encargos sociais sobre folha brasileira percorrem 15 etapas determinísticas, não 9 nem 12

Diferente do modelo alemão (9 etapas, focado no Lohnsteuer e na seguridade) e do espanhol (12 etapas, com TGSS, IRPF e convênios coletivos), os encargos sobre folha no BR exigem 15 etapas determinísticas porque o sistema previdenciário, fiscal e trabalhista tem cinco camadas paralelas - federal (IRRF, INSS do empregado, INSS patronal e Terceiros), FGTS na Caixa e a judicial de pensão alimentícia -, mais o cronograma do eSocial, que substituiu desde out/2021 a antiga GFIP, GPS, CAGED, RAIS e SEFIP. As etapas são: classificação de rubrica salarial ou indenizatória (Súmula TST 369), INSS do empregado pela tabela progressiva 2026, INSS patronal de 20%, RAT por CNAE multiplicado pelo FAP, Terceiros de cerca de 5,8%, FGTS de 8% até o dia 7, IRRF progressivo com dedução de R$ 189,59 por dependente, prioridade absoluta da pensão alimentícia (CPC art. 529), validação do 13º (Súmula TST 295) e das férias com 1/3 constitucional, contribuição sindical facultativa, plausibilidade histórica, PLD-FT, aprovação humana de regimes especiais, geração do eSocial S-1200/S-1210/S-2210/S-1299 e composição da EFD-Reinf R-2010 e da DCTFWeb, com arquivamento por 5 anos.

Um cenário concreto: uma empresa de tecnologia de médio porte com 480 funcionários em 6 estados, com CLT regular e 25 expatriados (5 dos EUA, 8 da Alemanha, 7 do Reino Unido e 5 do Japão) em tax equalization, faturamento de R$ 280 milhões/ano e regime de Lucro Real ocupava três analistas de folha em tempo integral. Após o Agente, o sistema importa as rubricas diariamente do ponto eletrônico (Portaria 671/2021), calcula cada encargo de forma determinística (INSS do empregado faixa por faixa, INSS patronal de 20% sobre a folha total, RAT efetivo de 1,2% - 1% multiplicado pelo FAP de 1,2 -, Terceiros de 5,8%, FGTS de 8% e IRRF progressivo), aplica a prioridade absoluta da pensão alimentícia a 8 colaboradores com ordens judiciais ativas e integra os 25 expatriados em cálculo de dupla jurisdição (BR e país de origem). Os DARFs são gerados com os códigos corretos (0561 para o IRRF assalariado e 1099 para o INSS), o cruzamento com o eSocial S-1299 fecha com tolerância de R$ 0,01 e a transmissão da DCTFWeb é validada no dia 12, três dias antes do prazo. O tempo caiu de 7 dias úteis para 4 horas por mês.

No [Decision Layer](/br/decision-layer/), 12 das 15 etapas são decisões baseadas em regras (nível R) - cada uma é cálculo determinístico contra Lei 8.212/91, Lei 8.036/90, Decreto 9.580/2018 RIR, EC 103/2019 ou Manual eSocial v2.5 - 2 etapas são plausibilidade aproximada (nível A, com revisão humana acima de 15% de variação) e 1 é decisão humana obrigatória (nível H): aprovação de regimes especiais (PLR Lei 10.101/00, expatriados, afastamentos prolongados S-2230). Não há ponto em que IA generativa decida sobre cálculo de encargo - a única etapa LLM-assistida é a classificação textual de rubrica ambígua, com cálculo subsequente sempre determinístico.

## Plausibilidade contra histórico 12 meses fecha o ciclo Pillar Two BEPS, expatriados em tax equalization e PLD-FT

A plausibilidade aproximada compara cada apuração mensal de encargos sociais com a média móvel dos 12 meses anteriores do mesmo CPF, considerando a sazonalidade (13º em dezembro, férias por período aquisitivo). Variação superior a 15% (para mais ou para menos) em INSS, IRRF, FGTS ou RAT aciona um alerta com hipóteses ranqueadas: (1) reajuste salarial de CCT/ACT (entrada em faixa progressiva superior); (2) admissão ou desligamento parcial no mês (proporcionalidade); (3) inclusão ou exclusão de adicional (insalubridade após laudo PCMSO, periculosidade após perícia); (4) nova decisão judicial de pensão alimentícia ou penhora; (5) erro de classificação de rubrica salarial ou indenizatória; (6) duplicidade de rubrica; (7) funcionário fantasma (sinal do COAF, CPF sem CTPS ativa); (8) salário incompatível com o cargo (alerta antifraude). A divergência fica visível antes do fechamento do eSocial S-1299, em vez de aparecer em fiscalização da Auditoria-Fiscal Trabalhista três anos depois.

Para o PLD-FT (Lei 9.613/98 e Resolução COAF 36/2021), o Agente analisa padrões anômalos contra o perfil histórico do CPF, cruzando o eSocial S-2200 (admissão) com o S-1200 (remuneração) e a lista de paraísos fiscais da OCDE (IN RFB 1.037/2010): funcionários sem CTPS ativa, salário incompatível com o cargo, conta corrente em paraíso fiscal, múltiplos CPFs no mesmo endereço e ciclos curtos repetidos de admissão e desligamento. A comunicação ao Siscoaf é em 24h; a omissão gera multa do COAF de até R$ 20 milhões, além da responsabilização do compliance officer.

Para o Pillar Two BEPS, com implementação BR em 2026 (PLP 49/2024 em tramitação), o Agente mantém cálculo de dupla jurisdição para expatriados em tax equalization: a folha BR completa (INSS, RAT/FAP, FGTS e IRRF) ao lado da folha hipotética do país de origem (EUA pelo IRS Form 941, Alemanha pelo Lohnsteuer ELStAM, Reino Unido pelo PAYE HMRC, Japão pelo Withholding Tax e Coreia do Sul pelo NHIS), aplicando gross-up ou tax protection conforme a política da empresa e exportando em formato compatível com o Vertex Source ou o Thomson Reuters ONESOURCE para a tax provision sob ASC 740 e Pillar Two GloBE da matriz.

## Edge-cases brasileiros: contribuição sindical opt-in, expatriados, PLR e afastamento por acidente

Para situações atípicas, o Agente aplica regras específicas: (1) contribuição sindical facultativa (Lei 13.467/2017 e ADI 5794 do STF) - bloqueio do desconto sem autorização expressa em assembleia; sem autorização, o desconto é nulo e gera devolução em dobro (CLT art. 462 § 1); (2) PLR (Participação nos Lucros, Lei 10.101/00) - não incidência de INSS, FGTS e RAT sobre a PLR negociada em CCT/ACT, com IRRF próprio pelo código 0561 e tabela específica (isenta até R$ 7.182,18); (3) acidente de trabalho - CAT em 24h pelo eSocial S-2210, com integração ao INSS para o auxílio-acidente B91 e estabilidade de 12 meses após o retorno (Lei 8.213/91 art. 118); (4) afastamento prolongado S-2230 - os primeiros 15 dias por conta da empresa (CLT art. 60 § 3) e, do 16º em diante, o INSS assume via B31/B91, com o FGTS mantido em afastamento por acidente; (5) expatriado residente fiscal BR (mais de 183 dias ou com visto) - tributação sobre a renda mundial, observadas as convenções do Brasil para evitar a dupla tributação (36 países); (6) funcionário fantasma no PLD-FT - bloqueio até a verificação da CTPS, com cruzamento do eSocial S-2200 e S-1200 e comunicação ao Siscoaf em 24h.

## Integração com ecossistema BR de folha: TOTVS, SAP HCM, Senior, ADP Brasil

A lógica do Agente conecta-se aos principais motores de folha do mercado brasileiro via API: [TOTVS Protheus RH, RM Folha e Datasul HR](https://www.totvs.com/) (líder de mercado em folha CLT, com motor eSocial nativo), [SAP HCM Brazil Localization (PY-BR) e SAP S/4HANA HR Brazil](https://www.sap.com/brazil/) (multinacionais com EFD-Reinf e DCTFWeb), [Senior Sistemas HCM](https://www.senior.com.br/) (indústria pesada com RAT/FAP individualizado), [ADP Brasil](https://br.adp.com/) (terceirização para multinacionais com matriz nos EUA), [Mastermaq Domínio](https://www.mastermaq.com.br/) (escritórios contábeis e PME), [Oracle ERP Cloud Brazil HCM](https://www.oracle.com/br/) (grupos IBOVESPA), além de Folhamatic FT (Sage Brasil) e Zucchetti Brasil HR Cloud. Para empresas com matriz na Europa ou nos EUA (Volkswagen, Bosch, Siemens e Stellantis, com unidades brasileiras), o Agente consolida a posição de encargos BR em formato compatível com o Workday HCM ou o Oracle Fusion HCM, mantendo a operação local em conformidade com o eSocial e a DCTFWeb e o reporting parental sob IFRS, ASC 715 e Pillar Two GloBE da matriz.

--- Agente de Caixa Pequeno ---
> Registra comprovantes de caixa por extração IA, verifica faturas de pequeno valor conforme Parágrafo 33 UStDV.

O caixa pequeno custa às empresas desproporcionalmente em auditorias fiscais - não porque os valores sejam altos, mas porque deficiências na gestão de caixa podem desvalorizar toda a escrituração. Quando o auditor encontra lacunas no registro diário, pode estimar. Em 2024, as auditorias fiscais estaduais na Alemanha geraram cerca de 10,9 bilhões EUR (aprox. 11,9 bilhões USD) em resultado adicional conforme o Ministério Federal das Finanças. A gestão de caixa está entre os primeiros pontos de auditoria porque é o mais frequentemente vulnerável.

## A gestão de caixa decide o resultado da auditoria fiscal

O Fisco audita transações em espécie com mais rigor do que operações sem dinheiro. A base legal é clara: a legislação tributária exige o registro diário de todas as transações de caixa, o padrão contábil GoBD (padrão GoBD alemão de arquivamento fiscal) (SPED Contábil / Lei 8.846/94 como equivalente brasileiro) exige imutabilidade e documentação completa, e desde 2020 vale a obrigação de dispositivo de segurança técnica (TSE). Desde janeiro de 2025, sistemas eletrônicos de caixa e seu TSE devem inclusive ser ativamente declarados ao Fisco. Violações da obrigação de TSE podem acarretar multas de até 25.000 EUR.

O problema não está na complexidade das regras. Está no fato de que entre a entrada do comprovante e o registro no livro caixa passa tempo demais. Quem registra comprovantes de caixa na sexta-feira à tarde retroativamente para a semana toda viola a obrigação de registro diário - e dá ao auditor uma alavanca para estimativas.

## Registro diário fracassa na realidade do dia a dia

Na prática, o fluxo raramente ocorre como o padrão contábil prevê. A gerente do escritório compra cartuchos de impressora pela manhã por 47 EUR, um colega paga o almoço de um cliente ao meio-dia por 189 EUR, à tarde soma-se um recibo de táxi de 23 EUR. Três comprovantes, três pessoas diferentes, três classificações contábeis diferentes. O registro manuscrito no livro caixa acontece - quando acontece - no fim do dia, de memória.

O resultado é conhecido por todo CFO que já viveu uma auditoria: comprovantes sem data no livro caixa, subtotais errados, fechamentos diários ausentes. Em faturas de pequeno valor até 250 EUR (aprox. 270 USD) brutos surge um risco adicional. Os dados obrigatórios simplificados conforme regulamentação de imposto sobre valor agregado permitem dispensar a indicação do destinatário - mas se um destinatário é mencionado e a indicação está incorreta, isso pode comprometer a dedução do imposto sobre insumos. Essa sutileza é regularmente ignorada pelos colaboradores.

## Sete etapas de decisão separam rotina de julgamento

O [Decision Layer](/br/decision-layer/) decompõe o processo de caixa exatamente nas etapas que distinguem um livro caixa em conformidade de um contestado. Das sete etapas de decisão, apenas uma é assistida por IA: o registro do comprovante, no qual um LLM extrai os dados relevantes de comprovantes de caixa não estruturados - fotos de recibos, notas manuscritas, impressões desbotadas em papel térmico.

As cinco etapas seguintes são completamente baseadas em regras. A verificação de limiar contra o limite de 250 EUR, o controle dos dados obrigatórios simplificados conforme regulamentação fiscal, a classificação contábil por tipo e valor do comprovante, o registro no livro caixa com carimbo de tempo conforme padrão contábil e a conciliação numérica entre saldo teórico e real - tudo segue regras determinísticas sem margem discricionária.

A sétima etapa permanece com o humano: quando o saldo de caixa diverge do saldo contábil, um humano deve esclarecer a causa. Nenhum algoritmo pode decidir se uma diferença de 14,50 EUR se deve a um comprovante esquecido, um erro de contagem ou algo mais grave. Essa fronteira é deliberadamente traçada.

## Verificação baseada em regras fecha a lacuna entre comprovante e livro caixa

Imagine a segunda-feira de manhã em uma filial com caixa próprio. A gerente fotografa o recibo de combustível do fim de semana - 62 EUR. Em segundos, o agente extrai valor, data e alíquota de imposto, reconhece o comprovante como fatura de pequeno valor, verifica os dados obrigatórios simplificados, classifica na conta correta e registra a transação com carimbo de tempo no livro caixa. Antes do almoço, o fechamento diário mostra: saldo contábil 843,50 EUR, saldo contado 843,50 EUR, sem diferença.

Quando na quarta-feira o saldo real fica 12 EUR abaixo do saldo teórico, o agente documenta o desvio e escala ao responsável de caixa. Não a um algoritmo. O esclarecimento de causa em diferenças de caixa é uma decisão de nível 1 - exige julgamento humano porque as possíveis razões são variadas demais para serem capturadas em regras.

--- Agente de QA de Lançamentos ---
> Verifica completude formal, plausibilidade, consistência de contas e código fiscal.

## Um terço dos contadores reporta múltiplos erros por semana

Um levantamento da Gartner de 2024 mostra: 33 por cento dos contadores pesquisados afirmam cometer múltiplos erros de lançamento por semana. O motivo principal não é falta de cuidado, mas gargalo de capacidade. Exigências regulatórias crescentes e condições de negócio voláteis aumentam o volume de lançamentos enquanto os tamanhos das equipes estagnam.

Imagine um departamento financeiro com 4.000 lançamentos por dia. Com uma taxa de erro de três a cinco por cento - o valor típico de processos de registro manual - surgem diariamente 120 a 200 registros incorretos. Nem todos são materiais. Mas cada um pode se tornar um lançamento de correção no fechamento mensal se ninguém o identificar antes.

## Erros no razão geral custam no fechamento um múltiplo da prevenção

Um código fiscal errado em uma fatura de entrada é questão de segundos na captura. Quando o mesmo lançamento chega ao razão geral, começa uma cascata: diferença na conciliação de imposto sobre valor agregado, consulta ao responsável, pesquisa no comprovante, estorno, relançamento, nova aprovação. De um segundo de correção transformam-se 15 a 30 minutos de esforço.

Multiplicado por centenas de lançamentos de correção por fechamento mensal, toda a janela de closing se desloca. Controllers aguardam saldos limpos. Auditores contestam padrões recorrentes. E a diretoria financeira perde confiança nos números que reporta semanalmente ao conselho.

A alavanca econômica está portanto não na aceleração do fechamento, mas na qualidade do lançamento individual. O que entra limpo no razão geral não precisa ser corrigido.

## Oito etapas de verificação substituem a amostragem manual

O [Decision Layer](/br/decision-layer/) decompõe a verificação de lançamentos em oito decisões discretas. Seis são completamente baseadas em regras: completude formal (comprovante, conta, valor, data presentes?), consistência de contas (débito e crédito compatíveis?), consistência de código fiscal (código de IVA combina com a conta lançada?), atribuição de período (data do comprovante e período de lançamento coincidem?), detecção de duplicatas (valor, conta e data já registrados?) e o roteamento final.

As duas etapas restantes utilizam padrões históricos: a verificação de plausibilidade compara cada valor com as faixas habituais do respectivo grupo de contas. O score de anomalia agrega todas as verificações individuais em uma avaliação geral e prioriza a escalação.

Decisiva é a sequência. Verificações baseadas em regras executam em milissegundos. Apenas lançamentos que passam em todas as verificações formais alcançam a análise de padrões mais elaborada. Na prática, isso significa: mais de 95 por cento de todos os lançamentos percorrem a cadeia completa de verificação sem intervenção humana.

## O caso normal passa sem escalação

Com dados cadastrais bem mantidos, dois a cinco por cento dos lançamentos são escalados. O score de anomalia determina a ordem - os registros mais conspícuos aparecem primeiro na tela do responsável. Em vez de verificar 4.000 lançamentos por dia por amostragem, a equipe se concentra em 80 a 200 casos priorizados.

Cada escalação que se revela inofensiva melhora o modelo. Os limiares de plausibilidade se calibram por feedback: média mais desvios padrão por grupo de contas como base inicial, refinada pela prática diária. Após três a seis meses, a taxa de falsos positivos cai mensuravelmente.

Para a auditoria, o Decision Layer documenta cada decisão: quais verificações foram realizadas, quais passaram, quais falharam, qual foi o score de anomalia e se o lançamento foi automaticamente liberado ou escalado. O sistema de controle interno torna-se assim não apenas mais eficaz, mas também comprovável - perante auditores, supervisão e conselho.

## Qualidade de lançamento determina a velocidade do fechamento

Empresas que sistematizam sua verificação de lançamentos reportam de forma consistente ciclos de closing mais curtos e menos lançamentos de correção no fechamento mensal. A EY estima que mais de 70 por cento de todos os lançamentos são automatizáveis. A questão não é se a verificação será automatizada, mas quão transparente a lógica de decisão permanece nesse processo.

O agente de QA de lançamentos opera no Decision Layer nível 1 a 2: conjunto de regras para verificações formais, suporte de IA para plausibilidade e detecção de anomalias, decisão humana apenas em anomalias escaladas. Nenhum erro de lançamento permanece invisível, nenhuma etapa de verificação fica sem documentação - e o fechamento mensal começa com saldos nos quais a diretoria financeira pode confiar.

--- Agente de Documentação de Procedimentos ---
> Detecta alterações de processo automaticamente, verifica atualidade da documentação.

Documentações de procedimentos existem na maioria das empresas. Atualizadas, raramente estão. Exatamente essa lacuna entre estado da documentação e realidade processual se torna problema em auditorias fiscais - pois o auditor não pergunta se uma documentação existe, mas se ela reflete o estado real.

## Auditores fiscais solicitam a documentação como primeiro item

Em 2023, auditores fiscais na Alemanha constataram resultados adicionais de 13,2 bilhões EUR (aprox. 14,4 bilhões USD) em 146.516 empresas auditadas (relatório mensal BMF outubro 2024). No início de uma auditoria, os auditores solicitam cada vez mais a documentação de procedimentos antes de entrar na verificação substantiva. A razão é pragmática: uma documentação desatualizada ou lacunar sinaliza controles processuais deficientes - e justifica procedimentos de auditoria aprofundados.

A consequência legal é claramente regulada. Quando documentação de procedimentos ausente ou insuficiente compromete a rastreabilidade e verificabilidade da escrituração, configura-se uma deficiência formal com peso substantivo. O auditor fiscal pode então rejeitar a escrituração e estimar as bases tributárias. Na prática, isso significa: uma deficiência documental se torna risco financeiro antes mesmo de um erro de conteúdo ser encontrado.

## Cada alteração de processo gera uma lacuna na documentação

O problema real não é a elaboração inicial. A maioria dos departamentos financeiros construiu uma documentação de procedimentos em algum momento - frequentemente no âmbito de um projeto, frequentemente com consultoria externa. O problema começa no dia seguinte à conclusão.

Um novo módulo de ERP entra em produção. Um workflow de aprovação é ajustado. Mais um agente assume uma tarefa de verificação. Cada uma dessas alterações deveria ser refletida na documentação de procedimentos - na descrição geral, na documentação técnica do sistema, no conceito de autorização e na descrição do SCI. Na prática, isso não acontece tempestivamente porque ninguém tem o gatilho. A alteração vai para produção, a documentação permanece estagnada. Ao longo de meses e anos surge um fosso crescente entre o que está documentado e o que efetivamente acontece.

## Monitoramento automático fecha a lacuna em tempo real

O agente de documentação de procedimentos monitora continuamente as configurações dos sistemas fiscalmente relevantes. Quando um processo muda - uma nova regra, um novo agente, uma permissão alterada - ele reconhece a divergência entre o estado documentado e o real. Verifica a documentação existente contra uma lista de verificação do padrão contábil, identifica as seções afetadas e gera um rascunho de atualização.

A lógica de decisão separa claramente por complexidade. Se algo mudou, o agente reconhece por conta própria. Se a documentação ainda corresponde à realidade, ele verifica automaticamente. Quais requisitos do padrão contábil se aplicam e como permissões são documentadas segue um conjunto fixo de regras. Mas se a documentação global está completa e se um rascunho é aprovado - isso decide o humano. O agente entrega o rascunho, não a assinatura.

## A documentação documenta a si mesma

O agente de documentação de procedimentos tem uma propriedade especial dentro do [Decision Layer](/br/decision-layer/): ele é simultaneamente ferramenta e objeto da documentação. Cada alteração que reconhece e documenta é protocola com carimbo de tempo, tipo de alteração e status de processamento. Assim surge um protocolo de alterações completo - não como requisito separado, mas como subproduto da operação normal.

Para a auditoria fiscal, isso significa concretamente: a documentação de procedimentos não está apenas atualizada, mas sua atualidade é comprovável. O auditor vê não apenas o estado atual, mas todo o histórico de alterações - quando qual processo foi ajustado, quando a documentação foi atualizada, quem aprovou. O ponto de contestação mais frequente perde assim sua base.

## Documentação de procedimentos torna-se infraestrutura contínua

A documentação de procedimentos clássica é um produto de projeto - criada uma vez, raramente atualizada, freneticamente revisada durante a auditoria. O agente de documentação de procedimentos transforma-a em parte da infraestrutura operativa. Alterações são reconhecidas antes de se tornarem lacunas. Rascunhos estão disponíveis antes que alguém pergunte por eles. A conformidade com o padrão contábil não é estabelecida na auditoria, mas continuamente assegurada - com aprovação humana como última instância.

--- Agente de Provisões ---
> Identifica tipos, calcula provisões de férias e bônus deterministicamente, escala provisões de garantia e processuais para avaliação humana e cria notas.

Provisões são o tema perene de toda auditoria de demonstrações financeiras porque reconhecimento e mensuração baseiam-se em premissas e estimativas. O agente de provisões separa de forma limpa o que pode ser calculado daquilo que requer julgamento humano - e torna ambas as partes à prova de auditoria.

## Provisões são o foco permanente de toda auditoria

Nenhuma outra posição do balanço está tão regularmente no foco de auditorias independentes e fiscais. O IDW descreve provisões expressamente como "tema perene" da temporada de auditoria, porque tanto o reconhecimento quanto a mensuração conforme HGB Parágrafo 249 baseiam-se em premissas que a administração deve estabelecer. A BaFin novamente elevou a questão da recuperabilidade de ativos e questões de mensuração relacionadas ao foco nacional de auditoria para 2025.

A razão é estrutural. Uma provisão de férias segue uma fórmula clara. Uma provisão para custos processuais depende da probabilidade jurídica de sucesso. Uma provisão de garantia baseia-se em valores de experiência dos últimos anos. Três provisões, três lógicas de formação completamente diferentes - e em muitos departamentos financeiros, elas acabam no mesmo template de Excel que é manualmente atualizado a cada ano. O auditor vê no final um resultado, mas não qual parte foi cálculo e qual foi julgamento.

## Férias e bônus podem ser totalmente formados de forma determinística

O [Decision Layer](/br/decision-layer/) decompõe a formação de provisões em oito etapas. Três delas são regras de cálculo puras que dispensam estimativa. A provisão de férias resulta de dias de férias pendentes multiplicados pela diária média de salário bruto mais contribuição patronal de seguridade social. A provisão de bônus segue a base contratual e a projeção atual de resultado. O lançamento contábil deriva deterministicamente do tipo de provisão.

Em uma empresa industrial de médio porte com 800 colaboradores, que no passado transferia a provisão de férias para o Excel a partir do sistema de ponto em três dias úteis em janeiro, o agente assume esse processamento mensalmente. Os dados vêm diretamente do sistema ERP e dos dados cadastrais de pessoal. O resultado não é uma estimativa, mas um cálculo rastreável por colaborador. Para o auditor, a questão não é mais se o valor é plausível, mas apenas se as bases de cálculo estão corretas. Isso encurta o procedimento de auditoria de amostragens com consultas para uma pura verificação de método.

## Garantia e custos processuais permanecem decisão humana

Duas etapas da pirâmide não são deliberadamente automatizadas. Provisões de garantia baseiam-se em valores de experiência e julgamento específico da empresa que nenhum conjunto de regras mapeia completamente. Provisões para custos processuais dependem da avaliação jurídica de probabilidades de sucesso, que exige análise técnica por jurídico interno ou escritório externo.

Aqui o agente entrega não o resultado, mas a base de decisão. Para garantias, agrega números de reclamações e cortesias dos últimos três anos, calcula taxas por grupo de produtos e fornece a base para a estimativa de taxas. Para custos processuais, extrai valor da causa, custos processuais até o momento e instância do departamento jurídico e entrega o modelo para a decisão humana. A taxa final e o valor final da provisão permanecem com o humano, mas são decididos a partir de um conjunto de dados estruturado e não de memória.

## O Decision Layer documenta cada avaliação de forma à prova de auditoria

Decisivo para a colaboração com o auditor independente não é se uma provisão foi calculada ou estimada. Decisivo é se a base está documentada. O agente de provisões registra por provisão: tipo, método de cálculo, dados de entrada, resultado, a marcação determinístico ou baseado em julgamento, comparação com ano anterior e justificativa de cada desvio. No final do ano, resulta um espelho de provisões que pode ser anexado como apêndice às demonstrações financeiras.

As notas explicativas conforme HGB Parágrafo 285 ou IAS 37 são preparadas como rascunho por LLM. Isso não significa que o contador as adota diretamente. Ele verifica se a formulação corresponde à avaliação e aprova. Para equipes financeiras que na temporada de fechamento precisam de cada hora em dobro, o trabalho se desloca de escrever para verificar - e sobretudo para longe da pergunta recorrente do auditor sobre como um determinado número surgiu.

--- Agente de Requisição de Compras ---
> Reconhece necessidade de compra de dados de consumo, verifica orçamentos, sugere fornecedores preferenciais, aciona workflow de aprovação e gera o pedido.

A requisição de compras é a decisão mais cara em todo o processo Purchase-to-Pay - não pelo seu valor próprio, mas porque ela define se condições negociadas se tornam efetivas. Quem escolhe o fornecedor errado, compra fora do contrato framework ou ignora limites orçamentários destrói economias antes que a primeira fatura chegue ao sistema. O agente de requisição ancora contratos framework, soberania orçamentária e matriz de aprovação diretamente no processo de compra - e libera julgamento humano apenas onde faz diferença: acima do limiar.

## Maverick Buying custa até 16 por cento das economias negociadas

Os dados são claros: segundo APQC, organizações com alta proporção de Maverick Buying precisam em média 16 horas a mais para emitir um pedido e perdem entre a estrutura de condições negociada e a aquisição efetiva até 16 por cento das economias. O Hackett Group estima no Digital World Class Benchmark 2025 que top performers perdem 60 por cento menos economias através de vinculação contratual consistente e Maverick Buying reduzido. A alavanca não está nas compras, mas no momento da requisição. Quem decide aqui, decide sobre a margem.

Na realidade de organizações financeiras de médio porte, o cenário é o seguinte: centenas de requisições por dia passam por departamentos que não têm nem contratos framework na cabeça nem saldos orçamentários de centros de custo. A consequência são pedidos ao fornecedor errado, chamadas sem referência a contrato framework, extrapolações que só aparecem no fechamento mensal. Cada uma delas é uma negociação perdida.

## O [Decision Layer](/br/decision-layer/) decompõe a requisição em sete etapas rastreáveis

O agente de requisição separa as sete decisões em cada requisição de forma limpa por responsabilidade. O reconhecimento de necessidade a partir de dados de consumo funciona como prognóstico assistido por ML, por exemplo quando estoques mínimos de material de consumo são atingidos. Verificação orçamentária, sugestão de fornecedor, condições de contrato framework, workflow de aprovação e geração do pedido são completamente baseados em regras - comparações numéricas e lógica de dados cadastrais, sem margem discricionária.

Concretamente: um departamento aciona uma necessidade de 8.400 EUR (aprox. 9.200 USD) para material de manutenção. O agente verifica em menos de um segundo se há orçamento residual suficiente no centro de custo, identifica o fornecedor preferencial dos dados cadastrais, obtém as condições do contrato framework (preço, quantidade mínima, prazo de entrega), calcula via matriz de aprovação o aprovador competente e gera o pedido. A vinculação contratual não é resultado de boa intenção, mas padrão do sistema.

O efeito no tempo de ciclo: benchmarks APQC mostram que top performers alcançam um tempo requisition-to-order de cinco horas, enquanto processos fracos precisam de cerca de 48 horas. Um Decision Layer baseado em regras coloca pedidos rotineiros na faixa de minutos - sem redução na documentação.

## Julgamento humano permanece onde conta empresarialmente

Nem todo pedido pode ser processado por regras. Pedidos individuais acima de um limiar definido - por exemplo 25.000 EUR ou um limite específico do centro de custo - exigem julgamento consciente: situação de mercado, relação estratégica com fornecedor, urgência extraordinária. Aqui o agente dá um passo atrás. Prepara a decisão completamente (situação orçamentária, disponibilidade contratual, fornecedores alternativos, cadeia de aprovação), apresenta ao decisor competente e documenta a aprovação humana como etapa explícita na trilha de auditoria.

Esse princípio não é uma rede de segurança, mas arquitetura de governança: a aprovação humana é um elemento do SCI e parte da obrigação de documentação conforme padrão contábil. Cada requisição - baseada em regras ou aprovada humanamente - é rastreável como transação comercial sem lacunas.

## Contratos framework passam do papel à infraestrutura

O ganho real está além do pedido individual: o motor de contratos framework que o agente utiliza se torna infraestrutura compartilhada no Decision Layer. O agente de compliance contratual acessa a mesma lógica contratual. A matriz de aprovação é reutilizada pelo agente de aprovação de faturas e pelo agente de execução de pagamentos. O pedido gerado torna-se a referência para o Three-Way-Matching entre pedido, recebimento e fatura. O que começa como automatização de uma tarefa individual constrói gradualmente a infraestrutura de decisão sobre a qual todo o processo P2P se sustenta.

--- Agente de Gestão de Contas a Receber ---
> Calcula estruturas de aging, avalia riscos por ML, determina provisões e monitora limites de crédito. Decisões estratégicas permanecem com humano.

O [Decision Layer](/br/decision-layer/) separa cálculo de avaliação na gestão de recebíveis. O agente decompõe o processo em oito etapas de decisão ao longo da arquitetura de decisão. A separação é clara: aritmética e verificação de regras são automatizadas, decisões discricionárias permanecem com o humano.

A estrutura de aging de recebíveis é um cálculo a partir de datas de vencimento - baseado em regras, sem margem discricionária. O mesmo vale para o monitoramento de limite de crédito: uma verificação de limiar contra limites configurados. O scoring de risco de inadimplência utiliza um modelo ML que combina comportamento de pagamento, risco setorial e dados externos de crédito. Com 24 meses de histórico limpo, esses modelos alcançam tipicamente 80 a 85 por cento de acerto na previsão de inadimplência.

Decisões estratégicas permanecem com o CFO ou head de finanças. Provisões para devedores duvidosos gerais podem ser sugeridas por regras; provisões individuais exigem julgamento individual porque, conforme legislação contábil e tributária, têm consequências fiscais imediatas. Acordos de pagamento, avaliação de factoring e escalação judicial ponderam relação com cliente, custos e risco - não são regras, mas negociação.

## Cenário concreto: cliente industrial com sete milhões em recebíveis

Uma empresa de médio porte no setor de máquinas com cerca de 180 milhões EUR de faturamento possui aproximadamente sete milhões EUR em recebíveis em aberto. A contabilidade de devedores mantém estrutura de aging e ciclos de cobrança de forma confiável, mas o panorama de risco só surge no fechamento mensal - tarde demais para reação operacional.

Com o agente de gestão de recebíveis, a avaliação ocorre diariamente: o scoring ML marca um grande cliente cujo comportamento de pagamento se deteriorou nas últimas seis semanas, embora o limite de crédito ainda não tenha sido ultrapassado. O agente documenta o score de risco, os fatores contribuintes e a estrutura de aging atual. O CFO vê o alerta no mesmo dia e decide: reduzir limite de crédito, converter entrega para pagamento antecipado, informar comercial. A decisão permanece humana, a base chega em minutos em vez de semanas.

No final do trimestre, o agente entrega a base de dados para a necessidade de provisão: provisão geral por estrutura de aging, candidatos para provisão individual com scoring documentado. O auditor recebe por avaliação uma evidência rastreável - score de risco, método, base de cálculo. Conforme padrão contábil, à prova de auditoria, reproduzível.

## Parcelamento, venda de recebíveis e escalação jurídica permanecem decisões humanas

O agente não é ferramenta de cobrança nem substituto para o relacionamento com cliente. Ele entrega três coisas: uma estrutura de aging continuamente atualizada, um panorama ponderado por risco da carteira de devedores e uma base documentada para decisões de provisão. O reporting cobre DSO, aging, heatmap de risco de inadimplência e utilização de limite de crédito, configurável conforme os KPIs do cockpit do CFO.

O que o agente deliberadamente não faz: não decide sobre parcelamentos, não vende recebíveis, não escala por conta própria ao departamento jurídico. Essas etapas permanecem estratégicas e humanas - exatamente onde habilidade de negociação, conhecimento do cliente e análise de custo-benefício importam. O Decision Layer torna transparente quem decidiu o quê e quando, e fornece a evidência sobre a qual a decisão se baseou.

--- Agente de Conciliação ---
> Compara sublazões contra razão, atribui itens em aberto, sinaliza diferenças inexplicáveis e cria protocolos de conciliação - durante o mês em vez de no final.

A conciliação contínua dissolve o congestionamento de prazo que historicamente sufoca os fechamentos mensais. Em vez de congelar centenas de contas no fim do mês, o agente de conciliação compara sublazão e razão geral a cada lançamento - continuamente, não periodicamente.

## Conciliação contínua dissolve o congestionamento de prazo

O agente de conciliação verifica a cada lançamento contra a lista de contas configurada se sublazão e razão geral ainda estão em acordo. Devedores, credores, banco, ativos, contas de compensação: os saldos são comparados continuamente, não congelados mensalmente. Diferenças aparecem no momento em que surgem - não três semanas depois, quando ninguém mais sabe qual lançamento as causou.

Isso muda fundamentalmente a tarefa do contador. Em vez de esclarecer centenas de contas simultaneamente na data de corte, a equipe trabalha com listas diárias contendo um punhado de pontos abertos. A carga se distribui ao longo do mês, o fechamento em si torna-se a confirmação de um estado já conciliado. Para o CFO, isso significa ciclos de close mais curtos sem cabeças adicionais - e para o departamento, um cotidiano sem a janela recorrente de fim de mês.

## O [Decision Layer](/br/decision-layer/) separa trabalho de cálculo de julgamento

A conciliação se decompõe em oito etapas de decisão claramente delimitadas. Sete delas são trabalho de cálculo: quais contas pertencem à lista, os saldos coincidem, quais partidas abertas explicam a diferença, qual status de aprovação foi alcançado. Essas etapas funcionam de forma baseada em regras, determinística e protocola. A atribuição de partidas abertas combina correspondência exata com matching difuso para pagamentos parciais e valores arredondados. Diferenças residuais incomuns são marcadas pelo agente via pattern matching para verificação.

Uma única decisão permanece com o humano: a avaliação de materialidade. Uma diferença residual de 340 EUR em uma conta de compensação é material ou não? Essa questão depende de contexto, evolução e julgamento e deliberadamente não é automatizada. O agente apresenta a diferença com todas as informações relevantes, o responsável decide. Isso é nível 1 a 2 no Decision Layer: alta automatização na execução, clara reserva humana na avaliação. Cada decisão é escrita com carimbo de tempo, autor e justificativa no protocolo de conciliação - a base para toda auditoria conforme padrão contábil.

## O fechamento se transforma de sprint em rotina

Quem implementa Conciliação Contínua muda não apenas o fluxo de trabalho, mas o perfil de expectativa do fechamento mensal. O protocolo de conciliação está disponível a qualquer momento, não apenas na data de corte. O auditor pode consultar durante o mês corrente quais contas estão conciliadas e com qual nível de evidência. Pontos abertos não são mais surpresas de última hora, mas uma lista de trabalho mantida.

Para a liderança, isso significa três coisas: datas de close planejáveis em vez de ciclos de horas extras, uma base numérica confiável para forecasts e reporting durante o mês, e uma trilha de auditoria que não apenas atende, mas torna visível os padrões contábeis. A conciliação deixa de ser um evento mensal. Torna-se aquilo que sempre foi: um processo de controle contínuo que apenas historicamente estava disfarçado como evento de data de corte.

--- Agente de Receita ---
> Reconhecimento de receita determinístico segundo CPC 47 IFRS 15 (5 etapas): contrato, obrigações, preço, alocação - Lei 12.973/2014, ECF Bloco K, CVM 945.

O reconhecimento de receita no Brasil é o ponto em que a Controladoria prova diligência contábil, fiscal e societária diante de oito instâncias simultâneas: a Receita Federal cruza a ECF Bloco K contra a ECD via SPED para validar o lucro tributável do Lucro Real (IN RFB 1.700/2017 e Lei 12.973/2014); a CVM exige o cumprimento do CPC 47 no ITR trimestral e na DFP anual com o FRE atualizado (Resolução 73/2022 e ICVM 480/09 art. 24); o CFC fiscaliza a aplicação dos julgamentos intransferíveis pelo Contador signatário CRC (NBC TG 47 e ITG 2000); o CARF julga autuações por timing inadequado de receita (multa de 75 a 150%, Lei 9.430/96 art. 44); os auditores independentes aplicam a NBC TA 540 sobre estimativas contábeis, com risco de parecer com ressalva (NBC TA 705) que torna a empresa inelegível para emissão pública; a B3 exige o cumprimento do CPC 47 nos registros de ações e debêntures; a ANPD fiscaliza o tratamento de dados contratuais de pessoa física (LGPD); e a PGFN inscreve em dívida ativa o IRPJ/CSLL não recolhido, com bloqueio de CND federal. Cada cláusula contratual mal classificada carrega risco quíntuplo: glosa da Receita Federal com multa de 75 a 150% acrescida de Selic e 1% ao mês, restatement da CVM em DFP/ITR (que reduz o preço da ação em 8 a 15%), responsabilidade administrativa do Diretor Financeiro (multa de até R$ 50 milhões), parecer com ressalva do auditor (NBC TA 705) e responsabilidade ético-disciplinar do Contador signatário CRC.

## Glosa da Receita Federal com multa de 75 a 150% (Lei 9.430/96), restatement de DFP/ITR pela CVM Resolução 73/2022, autuação do CARF por timing errado de receita e parecer com ressalva do auditor (NBC TA 705) quebram a credibilidade contábil-fiscal do exercício

Uma empresa brasileira de software enterprise B2B com 80 contratos ativos médio porte (R$ 8M valor médio, prazo 3-5 anos), faturamento R$ 480 milhões/ano e regime Lucro Real fecha 15-20 contratos novos por trimestre com componentes mistos: licenças perpétuas, SaaS, implementação customizada, suporte Premium, treinamento, garantias estendidas e bonificações vinculadas a SLA. Antes da automação, dois Contadores signatários CRC sênior, um Tax Manager e um CFO gastavam de 4 a 6 horas por contrato (90-120 contratos/ano) classificando obrigações, estimando consideração variável, alocando preço, avaliando transferência de controle e calculando saldos contratuais - tempo total anual 360-720 horas só em julgamento contábil de receita.

A consequência vai além do custo de mão de obra: o timing de receita é um dos três principais motivos de autuação do CARF no Lucro Real. Em fiscalização da Receita Federal pós-2020, divergências entre o CPC 47 e a ECF Bloco K (uma empresa reconheceu R$ 12 milhões de licença e implementação em ponto no tempo na entrega, mas o Fisco entendeu que seria ao longo do tempo pelo CPC 47.35) viraram autuação de R$ 9 milhões em IRPJ/CSLL mais R$ 13,5 milhões em multa qualificada de 150%, somada a Selic - total de R$ 22,5 milhões sobre uma divergência de classificação de obrigação. A CVM emitiu ofício de exigências por inadequação ao CPC 47 no ITR/DFP - a reapresentação trimestral gerou queda de 11% no preço da ação em D+1 e responsabilidade administrativa do CFO, com multa da CVM de R$ 18 milhões. A implementação do Pillar Two BEPS no BR a partir de 2026 (PLP 49/2024) cria a exigência adicional de reconciliar a receita do CPC 47 por jurisdição para a alíquota efetiva mínima de 15%.

## O reconhecimento de receita no Brasil percorre 16 etapas determinísticas, com 5 julgamentos intransferíveis ao Contador signatário CRC

Diferente do modelo alemão (realização pelo HGB com IFRS 15 em via dupla) e do espanhol (PGC com adoção do IFRS 15 via CNMV/ICAC), o reconhecimento BR exige 16 etapas porque o sistema contábil, fiscal e societário tem três camadas paralelas: a contábil (CPC 47 alinhado ao IFRS 15, aprovado pelo CFC e pela CVM), a fiscal (Lei 12.973/2014, RTT-RFB, com adições e exclusões na ECF Bloco K para a neutralidade de IRPJ/CSLL no Lucro Real) e a societária (DRE pela Lei 6.404/76 art. 187 e ITR/DFP/FRE pela CVM Resolução 73/2022). As 16 etapas são: extração contratual por LLM, verificação dos 5 critérios do CPC 47.9, identificação de obrigações separadas, determinação de preço com consideração variável, aplicação do constraint do CPC 47.56, alocação às obrigações, avaliação da transferência de controle em ponto no tempo ou ao longo do tempo, cálculo de progresso por output ou input, tratamento de modificações contratuais, cálculo dos saldos de Contract Asset e Liability, plausibilidade contra o histórico, aprovação humana para contratos materiais, lançamentos na ECD e na ECF Bloco K, notas explicativas do CPC 47.110-129, validação do ITR/DFP/FRE e arquivamento por 10 anos com hash SHA-256.

Um cenário concreto: uma empresa de tecnologia com 320 contratos ativos B2B (R$ 6M de valor médio, prazo de 2 a 4 anos), faturamento de R$ 280 milhões/ano e Lucro Real ocupava três Contadores em tempo integral só com reconhecimento de receita. Após o Agente, o sistema importa diariamente os contratos do CLM (DocuSign Brasil), aplica o LLM para extrair as cláusulas relevantes, classifica os candidatos a obrigações contra o catálogo do CPC 47, apresenta ao Contador signatário CRC as decisões intransferíveis com os precedentes da empresa e o checklist do CPC 47.22-30, calcula de forma determinística o progresso pelo método output (marcos verificáveis) ou input (custos incorridos), compõe os saldos de Contract Asset (a débito) e Contract Liability (a crédito), gera lançamentos integrados à ECD e à ECF Bloco K e elabora o rascunho das notas explicativas. O tempo caiu de 4 a 6 horas por contrato para 30 a 45 minutos de revisão humana focada em julgamento.

No [Decision Layer](/br/decision-layer/), 5 das 16 etapas são decisões humanas obrigatórias (nível H) - cada uma julgamento intransferível do Contador signatário CRC: identificação de obrigações distintas (CPC 47.22-30), determinação de preço com consideração variável (CPC 47.47-58), aplicação do constraint (CPC 47.56), alocação por método residual quando aplicável, avaliação de transferência de controle (CPC 47.31-37), e classificação de modificações contratuais (CPC 47.18-21). 8 etapas determinísticas (nível R) - cálculo de saldos, lançamentos, ECF Bloco K, arquivamento. 3 plausibilidade aproximada (nível A) - extração LLM-assisted, plausibilidade histórica, rascunho de notas. Não há ponto em que IA generativa decida sobre mensuração ou timing - a única etapa LLM-assistida é extração textual inicial e rascunho de notas, com cálculo sempre determinístico.

## Plausibilidade contra portfólio histórico fecha o ciclo channel stuffing, revenue smoothing antifraude NBC TA 240 e Pillar Two BEPS

A plausibilidade aproximada compara cada contrato reconhecido contra portfólio histórico (mesmo cliente, segmento, produto, sazonalidade dos últimos 24 meses). Variação > 20% para contrato comparável aciona alerta com hipóteses: (1) modificação contratual material não declarada (CPC 47.18-21); (2) consideração variável estimada inadequadamente (CPC 47.47-58); (3) método de progresso errado (CPC 47.39-45); (4) transferência de controle classificada erroneamente (CPC 47.31-37); (5) channel stuffing fictício no fim do trimestre; (6) revenue smoothing entre exercícios; (7) inadimplência crescente sinalizando reversibilidade. A divergência fica visível antes do fechamento mensal, em vez de aparecer em fiscalização CARF ou em parecer com ressalva NBC TA 705.

Para o antifraude NBC TA 240 (Norma Brasileira de Contabilidade de Auditoria - Responsabilidades do Auditor relacionadas a Fraude), o Agente analisa padrões anômalos contra o perfil histórico do cliente, cruzando a receita com as contas a receber e o DSO (Days Sales Outstanding) por segmento: contratos de alto valor com cliente novo sem histórico de relacionamento, faturamento concentrado nos últimos 7 dias do trimestre, modificações contratuais retroativas que aumentam o preço da transação, pagamentos via partes relacionadas e taxa de devolução crescente após o período de avaliação. Diante de sinal positivo, o Agente bloqueia o reconhecimento e escala para o Comitê de Auditoria, o CFO e o Auditor Independente, para análise antes de afetar o ITR/DFP.

Para o Pillar Two BEPS GloBE, com implementação BR em 2026 (PLP 49/2024 em tramitação), o Agente mantém a reconciliação por jurisdição: a receita reconhecida pelo CPC 47 no BR, os ajustes para o GloBE Income (substância da OCDE e considerações variáveis) e a comparação entre a alíquota efetiva BR e a alíquota mínima de 15% por jurisdição. Empresas com receita consolidada acima de EUR 750M ficam sujeitas ao Top-up Tax se a alíquota efetiva BR for inferior a 15% - o Agente exporta os dados de receita BR em formato compatível com o Vertex Source ou o Thomson Reuters ONESOURCE para a tax provision sob ASC 740 e Pillar Two GloBE da matriz.

## Edge-cases brasileiros: BOT/PPP, software multicomponente, contratos em moeda estrangeira hedge e Simples Nacional

Para situações atípicas, o Agente aplica regras específicas: (1) BOT/PPP pela Lei 11.079/2004 (Build-Operate-Transfer em concessões públicas de saneamento, energia e transporte) - identifica até 3 obrigações de desempenho separadas (construção, operação e transferência), com momento de reconhecimento distinto; (2) software multicomponente (licença, implementação e suporte) - aplica o teste de utilidade independente do CPC 47.27 caso a caso, com Senior-Default por solução combinada quando a implementação é necessária para a utilidade da licença; (3) contratos em moeda estrangeira com hedge (USD, EUR, JPY, GBP) - aplica o CPC 38/IAS 21 para a conversão na data da transação, com a variação cambial reconhecida a débito de Variação Cambial Ativa e a crédito de Receita, e integra-se ao hedge accounting do CPC 48/IFRS 9 para contratos com hedge designado; (4) garantias estendidas e devoluções - tratamento conforme a natureza: garantia de qualidade (custo, sem obrigação separada, CPC 47 BC32) ou garantia de serviço (obrigação separada, CPC 47.B30); (5) contratos com partes relacionadas - documentação de Transfer Pricing (IN RFB 1.312/2012 e Lei 14.596/2023, alinhada à OCDE) com arm's length; (6) Simples Nacional e Lucro Presumido com escrituração simplificada da ITG 1000 - reconhece a receita em base caixa para fins fiscais e por competência no CPC 47 para a escrituração do CFC, com adições e exclusões na ECF Bloco K para a neutralidade.

## Integração com ecossistema BR de Revenue Recognition: TOTVS, SAP S/4HANA RAR, Oracle Cloud, Senior

A lógica do Agente conecta-se aos principais motores de Revenue Recognition do mercado brasileiro via API: [TOTVS Protheus Revenue Management e RM Fluig](https://www.totvs.com/) (líder de mercado no médio porte BR, com módulo CPC 47 nativo), [SAP S/4HANA Revenue Accounting and Reporting (RAR) com Brazil Localization](https://www.sap.com/brazil/) (multinacionais com reporting parental sob IFRS 15 e ECF Bloco K BR), [Oracle Revenue Management Cloud com Brazil Localization](https://www.oracle.com/br/) (grupos IBOVESPA com matriz internacional), [Synchro/Sovos Revenue](https://sovos.com/pt-br/) (especialista em retenções de IRRF e INSS sobre serviços, com integração ao CPC 47), [Senior Sistemas Gestão Empresarial](https://www.senior.com.br/) (indústria pesada como Vale na mineração, Suzano no papel-celulose e Braskem na química, com método output de marcos), [TOTVS Mastersaf](https://www.mastersaf.com.br/) (especialista em obrigações fiscais BR, com integração ao CPC 47, à ECF e à ECD), Microsoft Dynamics 365 Finance com Brasil Localization e Workday Financial Management com Brazil Localization (empresas de tecnologia como Stefanini e Movile, com contratos multicomponentes). Para PME no Lucro Presumido e no Simples Nacional, integra-se ao QuickBooks Online Brasil, ao Conta Azul, ao Bling ERP e ao Mastermaq Domínio Sistemas para a escrituração simplificada do CPC 47 via ITG 1000. Para empresas com matriz na Europa ou nos EUA (Volkswagen, Bosch, Siemens, Bayer e BASF, com unidades brasileiras), o Agente consolida a posição de receita BR em formato compatível com o SAP S/4HANA RAR ou o Oracle Revenue Management Cloud da matriz, mantendo a conformidade local com o CPC 47, a ECF Bloco K e a CVM Resolução 73/2022 e o reporting parental sob IFRS 15, Pillar Two GloBE e ASC 606 (US GAAP convergente).

--- Agente de Declarações Sociais ---
> Determina tipos de declaração, cria declarações conforme DEÜV, transmite eletronicamente às seguradoras e processa respostas - totalmente baseado em regras.

O agente de declarações sociais resolve exatamente o risco que surge quando processos rotineiros com consequências severas são executados manualmente: cada erro de declaração pode resultar em cobranças retroativas, acréscimos moratórios e responsabilidade pessoal. O agente mapeia as dez decisões da declaração DEÜV completamente de forma baseada em regras: determinar tipo de declaração, verificar motivo de envio, compilar dados, atribuir chave de grupo de contribuição, criar registro DEÜV, validar o registro, verificar o prazo, transmitir pontualmente, processar retorno, e estornar e reapresentar declarações incorretas. Zero componente de IA, zero julgamento, zero alucinação. Essa é a razão para a mais alta avaliação de readiness de todo o catálogo Finance.

## A realidade de responsabilidade por trás da rotina

Os números da Previdência Social alemã das auditorias periódicas mostram quão caro fica a negligência: segundo a estatística da DRV, são cobrados anualmente várias centenas de milhões de euros em cobranças retroativas de contribuições, com cerca de 30 por cento dos empregadores auditados apresentando declarações contestadas. Somam-se acréscimos moratórios de um por cento por mês iniciado sobre cada contribuição em atraso, prazos de prescrição de até 30 anos e inversão do ônus da prova: o empregador deve demonstrar de forma verossímil que a declaração não foi omitida de forma culposa.

Na prática, os erros raramente surgem por intenção. Surgem porque uma mudança de pessoal faz o tipo "cancelamento por saída" colidir com a chave de grupo de contribuição "0000", porque uma declaração anual falha formalmente e ninguém verifica o retorno da seguradora, porque um minijob ultrapassa o limite de remuneração e a responsabilidade muda da central de minijobs para a seguradora. Cada um desses casos é uma árvore de decisão baseada em regras - e cada uma dessas árvores pode ser mapeada deterministicamente.

## Dez decisões, zero componente de IA

O [Decision Layer](/br/decision-layer/) decompõe a declaração social em dez microdecisões que têm todas o mesmo caráter: input do sistema de folha de pagamento (PT: processamento salarial), regra da legislação social ou regulamentação DEÜV, output inequívoco. O tipo de declaração resulta da alteração de dados cadastrais. A chave de grupo de contribuição segue do status de segurado, tipo de emprego e remuneração. O formato DEÜV é tecnicamente especificado. A transmissão ocorre pela interface padronizada ao portador responsável. O retorno é analisado e, em caso de rejeição, comparado com um conjunto de regras que conhece as constelações de erro mais frequentes.

Essa arquitetura torna o agente o contraponto para todas as discussões sobre compliance de IA. Onde não há IA operando, também não há riscos de IA. O EU AI Act não é aplicável porque nenhuma decisão probabilística é tomada. A auditoria previdenciária aceita o Decision Layer como documento de folha, porque cada declaração está documentada de forma à prova de revisão com tipo, carimbo de tempo, caminho de regra e comprovante de transmissão.

## Cenário: 1.200 colaboradores, doze meses, zero contestações

Um grupo com 1.200 empregados segurados em três sociedades gera por mês entre 40 e 80 declarações DEÜV: admissões, demissões, interrupções, alterações, declarações especiais. Antes da implementação do agente, a semana de declarações em janeiro (declarações anuais) durava regularmente dez dias, a taxa de erro nos retornos estava em quatro a seis por cento, e a auditoria de 2022 terminou com uma cobrança retroativa de 180.000 EUR mais acréscimos moratórios.

Após a implementação, cada alteração de dados cadastrais é diretamente traduzida em uma decisão de declaração. As declarações anuais para 1.200 colaboradores são criadas e transmitidas em 90 minutos. Retornos das seguradoras são analisados por máquina. Declarações rejeitadas que são corrigíveis por regras passam automaticamente de novo; o resto chega ao cockpit do responsável com código de erro, referência de regra e sugestão de solução. A auditoria de 2026 é uma consulta de dois dias porque os auditores podem consultar cada declaração pela interface de documentação de processo.

## Documentação à prova de auditoria como subproduto

O efeito real surge não na criação da declaração, mas na documentação. Cada decisão é arquivada com dados de entrada, caminho de regra, registro de saída e retorno. A auditoria previdenciária encontra um histórico de declarações completo no qual cada declaração individual pode ser reconstruída - incluindo o estado exato da regra no momento da declaração.

--- Agente Preparação Auditoria Fiscal ---
> Preparação de fiscalização RFB: análise da ordem de auditoria, compilação de dados no formato IDEA, identificação de áreas de risco e estimativa de provisão tributária.

Uma auditoria fiscal não é para grandes empresas um evento excepcional, mas um estado permanente. Quem trata o período de auditoria como emergência, perde. Quem o organiza como disciplina contínua reduz provisões, encurta a duração da auditoria e ganha segurança na negociação. O agente de preparação para auditoria desloca o Finance de produção reativa de dossiês para permanentemente audit-ready.

## Por que a preparação clássica custa dinheiro ao CFO

O Ministério Federal das Finanças reportou para 2024 um resultado adicional de cerca de 10,9 bilhões EUR (aprox. 11,9 bilhões USD) de 140.764 auditorias fiscais - com 12.359 auditores em todo o país e uma taxa de auditoria de 1,6 por cento. Grandes empresas e grupos estão em auditoria contínua, ou seja, são auditados sem interrupção e de forma regular. Para CFOs, isso significa: a próxima auditoria não é questão de se, mas de quando.

A preparação clássica começa com a ordem de auditoria. A partir desse momento, a empresa tem regularmente duas a três semanas para preparar dados em formato IDEA e disponibilizar os três tipos de acesso Z1, Z2 e Z3. Nessas semanas, o departamento tributário, TI e consultores externos giram em modo de crise. Respostas a perguntas do auditor surgem sob pressão de tempo. Decisões históricas são reconstruídas a partir de documentos cujos autores já deixaram a empresa há muito tempo. O resultado é previsível: provisões mais altas, posição de negociação mais fraca, ciclos de auditoria mais longos.

## O que o [Decision Layer](/br/decision-layer/) muda nisso

O agente de preparação para auditoria não é uma ferramenta acionada na emergência. É o ponto de integração de todos os outros agentes Finance. Compliance contábil, classificação, imposto sobre valor agregado, retenção na fonte, preços de transferência - cada uma dessas decisões é tomada onde surge e documentada de forma legível por máquina. O agente condensa essa documentação a qualquer momento sob demanda em base de dados pronta para auditoria.

O trabalho se divide em três papéis claramente separados. Etapas baseadas em regras são assumidas pela automatização sem julgamento: consultas ao banco de dados por período de auditoria e tipo de imposto, exportação IDEA conforme padrão GDPdU, preparação dos acessos Z1/Z2/Z3. Horas em vez de semanas. Etapas assistidas por IA trazem reconhecimento de padrões: a ordem de auditoria é interpretada, focos de auditorias históricas são comparados, perguntas do auditor são roteadas ao departamento responsável. Decisões humanas permanecem onde pertencem: estratégia de resposta, avaliação de risco de planejamento tributário e estimativa de provisões. Essas etapas são expressamente Human-in-the-Loop porque pressupõem julgamento técnico e experiência de negociação.

## Cenário: como uma auditoria contínua funciona no Decision Layer

Um grupo com sede na Alemanha recebe uma ordem de auditoria para os anos 2022 a 2024. São auditados imposto de renda (PT: IRS/IRC) corporativo, imposto comercial, imposto sobre valor agregado e uma documentação de preços de transferência separada. O agente analisa o despacho em minutos, atribui as exigências aos agentes responsáveis e cria um plano de preparação com esforço estimado e clusters de risco abertos.

A compilação de dados - normalmente a fase mais cara - funciona em segundo plano. Exportações IDEA estão imediatamente disponíveis porque os dados contábeis já existem no formato exigido. A análise de áreas de risco marca dois clusters: uma série de entregas intracomunitárias com países de destino alternados e uma estrutura de licenças intragrupo cuja documentação de preços de transferência foi ajustada múltiplas vezes desde 2023. Ambos os clusters vão ao departamento tributário com base de dados preparada e linha de argumentação. A provisão é determinada pelo head de tax com julgamento - o agente entrega a faixa de dados, não o juízo.

O resultado: sem semanas de crise. Sem consultores externos para preparação de dados. O head de tax concentra-se em argumentação e negociação, não em busca de provas.

## O que muda para a função Finance

Estar permanentemente audit-ready não é esforço adicional - é uma redistribuição de esforço existente. Em vez de enfrentar um projeto de auditoria a cada três a cinco anos, cada decisão documenta a si mesma no momento de sua criação. O departamento tributário se transforma de arquivista em negociador. O CFO reduz a incerteza no planejamento de provisões e pode avaliar riscos de planejamento tributário com base de dados confiável antes que o auditor os encontre.

--- Agente de Three-Way-Matching ---
> Compara faturas recebidas com pedidos e recebimentos. Verifica quantidades, preços e tolerâncias.

Three-Way Matching é o gargalo de decisão na contabilidade de fornecedores, porque cada fatura de entrada precisa ser verificada contra pedido e recebimento antes de ser paga. O Agent de Three-Way Matching substitui a verificação manual por onze regras determinísticas e atinge, assim, uma taxa de Straight-Through no nível enterprise - sem participação de IA, sem classificação como sistema de alto risco EU AI Act, sem margem de interpretação. É o candidato de entrada com o qual CFOs estabelecem o [Decision Layer](/br/decision-layer/) na organização financeira, porque combina alto volume, baixo risco e efeito de caixa diretamente mensurável.

## Por que o matching manual domina o tempo de processamento P2P

Em uma contabilidade de fornecedores típica de enterprise, 10 a 20% de todas as faturas de entrada caem em uma exceção - divergência de quantidade, diferença de preço, recebimento ausente, referência de pedido errada. Equipes AP enterprise bem posicionadas alcançam, depois de afinar as regras de tolerância, taxas de Straight-Through na faixa alta de dois dígitos percentuais. As exceções restantes, porém, consomem a maior parte do tempo de trabalho, porque cada divergência precisa ser pesquisada, esclarecida com o setor de compras e aprovada manualmente.

A realidade no médio porte e em boa parte das grandes empresas fica bem abaixo disso. Mesmo com investimento contínuo em automação de AP, a parcela de faturas processadas sem qualquer intervenção humana frequentemente permanece no terço inferior do volume total. O intervalo entre investimento e efeito surge justamente onde a lógica de matching está dentro de telas do ERP, em vez de rodar como um Agent de decisão próprio, com matriz de aprovação clara.

Para o CFO isso gera dois problemas concretos: perda de desconto porque faturas são aprovadas tarde demais, e planejamento de liquidez incerto porque o saldo de faturas abertas e sem matching não é controlável.

## Como o Decision Layer decompõe o matching

O Agent de Three-Way Matching divide a verificação em onze microdecisões, todas baseadas em regras: verificar os dados obrigatórios da fatura, checar duplicidade, atribuir pedido, atribuir recebimento, comparar quantidades, comparar preços, conferir divergência contra tolerância, rotear aprovação pela matriz, atribuir empresa e centro de custo, calcular o desconto financeiro, gerar o lançamento contábil. Cada etapa é uma verificação de campos ou uma comparação numérica. Cada limiar de tolerância é configurável. Cada decisão de roteamento segue uma matriz de valor-vezes-divergência, alinhada com a diretoria e com a Auditoria Interna.

Esse desenho é a razão de o Agent ter 0% de participação de IA. Ele não toma decisão de julgamento, não interpreta textos, não aprende. Ele executa regras que um humano aplicaria da mesma forma - só que em milissegundos e sem cansaço. Para o EU AI Act, o Agent é irrelevante; para a auditoria em conformidade com o padrão contábil alemão GoBD (padrão GoBD alemão de arquivamento fiscal), é uma etapa padrão; e para a Auditoria Interna, um caminho de decisão documentado de ponta a ponta.

## Cenário concreto: holding industrial com 12.000 faturas por mês

Uma holding industrial com seis plantas processa cerca de 12.000 faturas de entrada por mês. Ponto de partida: 78% das faturas dão match de primeira, 22% caem na fila de exceções. O departamento AP, com nove colaboradores em tempo integral, trabalha basicamente nessas exceções e resolve, em média, 140 esclarecimentos por dia. Taxa de desconto: 61%. Tempo médio de recebimento até pagamento: 9,4 dias.

Depois da introdução do Agent de Three-Way Matching, com tolerâncias ajustadas (2% de preço, 5% de quantidade, matriz de aprovação escalonada a partir de 2.500 EUR / 2.700 USD), o quadro muda: a taxa de Straight-Through sobe para 88%, o saldo manual de esclarecimento cai de 2.640 para 1.440 faturas por mês. O departamento AP deixa de processar conferências de rotina e passa a cuidar só de discrepâncias reais com compras e fornecedores. Taxa de desconto: 84%. Tempo de processamento: 2,1 dias. Efeito de caixa apenas pelo primeiro ganho de desconto: cerca de 430.000 EUR (470.000 USD) por ano, em um volume de faturas de 380 milhões EUR (415 milhões USD).

## Por que esse Agent é o candidato de entrada para o Decision Layer

O Agent de Three-Way Matching é a decisão de entrada mais racional para um CFO, porque combina ao mesmo tempo quatro características que raramente aparecem juntas em outros Finance Agents: alta prontidão (os dados estão no ERP), volume diário (mensurável de imediato), baixa carga de governança (baseado em regras, não em IA) e alto efeito econômico (desconto, liquidez, capacidade).

Além disso, constrói a infraestrutura para todos os Workflow Agents seguintes. O sistema de limiares de tolerância é reutilizado depois pelo Agent de Cash Application na conferência de recebimentos contra itens em aberto. A matriz de aprovação vira bloco padrão para qualquer Workflow Agent com escalação por valor. A documentação de processo entrega o caminho de auditoria em que os Agents apoiados por IA (como Invoice Coding) se orientam mais tarde.

Quem estabelece o Decision Layer na organização financeira começa aqui - com um Agent que não exige discussão com o DPO, não precisa de dados de treinamento e cujo efeito já aparece no relatório de desconto da primeira semana.

--- Agente de Documentação de Preços de Transferência ---
> Cria matriz de transações dos dados contábeis, realiza estudos de benchmark, calcula intervalo interquartil e gera documentação conforme diretrizes OECD.

Documentação de preços de transferência é o processo em que CFOs produzem ou evitam a constatação de auditoria mais cara de sua auditoria fiscal. Na auditoria fiscal de 2024, os estados constataram um resultado adicional de cerca de 10,9 bilhões EUR (aprox. 11,9 bilhões USD), e correções de TP pertencem sistematicamente às posições individuais mais pesadas (fonte: relatório mensal BMF novembro 2025). O [Decision Layer](/br/decision-layer/) decompõe a documentação em oito etapas claramente responsabilizadas - assim surge um processo à prova de auditoria em que cada decisão é justificada e cada número pode ser atribuído a uma fonte.

## A regra: princípio arm's length, e o ônus da prova está com você

A legislação tributária internacional exige que preços intragrupo sejam acordados como seriam entre terceiros independentes. Em violações, a administração tributária corrige o resultado para cima, e em documentação ausente ou deficiente, a legislação impõe um acréscimo punitivo de no mínimo 5 por cento e até 10 por cento do resultado adicional, com mínimo de 5.000 EUR e máximo de 1 milhão EUR. A legislação alemã adicionalmente endureceu as regras para financiamentos intragrupo, e as diretrizes administrativas de preços de transferência de 2024 implementam os novos requisitos no manual do auditor.

O caso prático: um grupo com matriz alemã e subsidiária de produção polonesa fornece produtos semiacabados para a Alemanha. O preço de venda é de 100 EUR por unidade. A auditoria fiscal exige a comprovação de que esse preço corresponde ao princípio arm's length. Se a documentação falta, o auditor estima - e sistematicamente em desfavor da empresa. Country-by-Country Reporting aplica-se adicionalmente a partir de um faturamento consolidado de 750 milhões EUR, e o Pillar Two afeta em toda a Europa cerca de 8.000 grupos, dos quais aproximadamente 800 na Alemanha.

## O Decision Layer: oito etapas, três tipos de decisor

A documentação de TP se decompõe em trabalho baseado em dados, cálculo baseado em regras e julgamento humano. A matriz de transações surge automatizada dos dados contábeis IC. O estudo de benchmark funciona como consulta estruturada a bancos de dados contra Amadeus ou Orbis, e o intervalo interquartil é uma operação aritmética sem margem discricionária. Essas etapas o agente executa de forma confiável e rastreável.

Três etapas permanecem com o humano. A análise funcional e de riscos exige a avaliação qualitativa da cadeia de valor porque somente o responsável tributário pode julgar qual sociedade desempenha qual função. A escolha do método de TP entre CUP, Resale Price, Cost Plus, TNMM e Profit Split é uma decisão de interpretação conforme diretrizes da OCDE. A aprovação final é estratégica porque define a linha de defesa na próxima auditoria fiscal. O agente documenta cada uma dessas etapas humanas com decisor, carimbo de tempo e justificativa.

Intermediariamente está uma etapa assistida por IA: o primeiro rascunho de Master File, Local File e CbCR como draft LLM com base nos dados antecedentes. O rascunho é o ponto de partida para a revisão pelo assessor fiscal, nunca o resultado final.

## O que o CFO obtém disso

Consistência entre lançamento e documentação. O agente compara continuamente os preços declarados na documentação de TP com os lançamentos IC efetivos. Desvios fora do intervalo interquartil são escalados imediatamente ao assessor fiscal. Assim desaparece a lacuna clássica em que a documentação é do ano anterior e os lançamentos já divergem há tempo.

Capacidade de defesa na auditoria fiscal. Cada entrada em Master File, Local File e CbCR está vinculada à sua fonte de dados, cada escolha de método com sua justificativa, cada benchmark com seu snapshot de banco de dados. O auditor não recebe um arquivo pronto, mas um processo reproduzível. Essa é a diferença entre estimativa em desfavor do contribuinte e reconhecimento dos preços documentados.

## Pillar Two muda o cenário

Desde 1 de janeiro de 2025, o imposto mínimo global de 15 por cento atua paralelamente à auditoria clássica de preços de transferência. Para departamentos de TP, isso significa: preços de transferência devem não apenas resistir ao princípio arm's length, mas adicionalmente ser consistentes com o Pillar Two. Uma correção de TP em um país pode empurrar a alíquota efetiva em outro país abaixo do limiar de 15 por cento e lá acionar um imposto complementar. O teste simplificado de ETR sobe em 2026 para acima de 16 por cento, e a documentação de TP deve ser consistente com os dados GloBE. O agente fornece a estrutura em que ambos os sistemas são alimentados pelos mesmos dados primários - o que reduz o risco de que departamento tributário e função tributária do grupo mantenham dois mundos numéricos contraditórios.

--- Agente Cálculo Fiscal Viagens ---
> Cálculo fiscal de viagens segundo Lei 8.852/94 isenção IRRF diárias, Lei 7.713/88 art. 6 inciso II e PIS/COFINS: aplicação de isenções de IRRF sobre diárias e dedução de PIS/COFINS.

Despesas de viagem são o processo baseado em regras mais caro da área Finance - e exatamente por isso a alavanca de automatização mais rentável. Uma prestação de contas processada manualmente custa segundo benchmark GBTA cerca de 58 USD e leva em média 8,8 dias até ser contabilizada. O agente de despesas de viagem reduz ambos os valores em mais de 70 por cento sem que uma única decisão fiscal deixe a empresa.

## Por que despesas de viagem manuais custam mais que a própria viagem

Os conjuntos de regras por trás de uma viagem a serviço são completamente documentados, mas distribuídos: diretriz BMF de 5 de dezembro de 2025 com as diárias internacionais para 2026, diária doméstica inalterada de 14 EUR a partir de 8 horas e 28 EUR a partir de 24 horas, reduções conforme legislação tributária, valores de referência, requisitos de comprovante conforme legislação de IVA. Nenhum colaborador individual domina essa combinatória no dia a dia.

A consequência é conhecida: colaboradores inserem diárias erradas, esquecem reduções por refeições, submetem comprovantes ilegíveis. A contabilidade corrige, consulta, espera por respostas. Cada prestação de contas passa por três a cinco mãos antes de ser contabilizada. Com 2.000 prestações por ano - um valor realista para uma empresa com 500 colaboradores - são calculadamente mais de 100.000 EUR (aprox. 109.000 USD) em custos puros de processo, além do orçamento de viagem propriamente dito.

## 13 das 15 etapas são baseadas em regras, apenas o motivo de viagem ambíguo fica com o humano

O agente de despesas de viagem decompõe o processo em 15 decisões discretas. Treze são completamente baseadas em regras: calcular duração da ausência, derivar diária BMF de país e horas, aplicar redução por refeição de 20, 40 ou 40 por cento, determinar custos de deslocamento por quilometragem ou comprovante, verificar formalidades de comprovante contra legislação de IVA, atribuir centro de custo, criar lançamento. Uma decisão é agêntica: a verificação de plausibilidade contra valores de comparação históricos. Exatamente uma decisão permanece com o humano: a avaliação de motivos de viagem ambíguos, ou seja, a questão se uma viagem foi efetivamente motivada profissionalmente.

Essa distribuição não é acidental, mas resultado de análise tributária rigorosa. Baseado em regras funciona tudo o que está conclusivamente regulado em parágrafos, tabelas ou diretrizes BMF. O humano decide apenas onde julgamento é exigido - e lá com registro completo de decisão como base.

## Cenário: Frankfurt para Madri, três dias, duas refeições fornecidas

Um gerente de projeto viaja segunda-feira cedo de Frankfurt para Madri, volta quarta à noite. Na terça participa de um almoço de cliente, na quarta o café da manhã do hotel. Manualmente, essa prestação de contas leva tipicamente 25 a 40 minutos - incluindo consultas.

O agente resolve em menos de um minuto. Lê partida e retorno do pedido de viagem, reconhece três dias de ausência, obtém a diária de Madri da diretriz BMF 2026 e calcula 32 EUR para o dia de partida, 48 EUR para o dia completo, 32 EUR para o dia de retorno. A redução por refeição diminui a terça em 40 por cento para 28,80 EUR e a quarta em 20 por cento para 25,60 EUR. Conta do hotel, passagem aérea e recibos de táxi são verificados quanto aos dados obrigatórios, o imposto sobre insumos é deduzido, a contabilização vai para o centro de custo configurado. O colaborador vê cada linha com justificativa, cada parágrafo, cada versão BMF. Pode contestar cada posição - cada regra é documentada, não afirmada.

## O que o CFO concretamente ganha

Quatro efeitos impactam diretamente a DRE e a resiliência fiscal. Primeiro, os custos de processamento por prestação de contas caem mais de 70 por cento - de 58 USD para menos de 15 USD. Segundo, o prazo de processamento cai de 8,8 dias para horas, o que eleva mensuravelmente a satisfação dos colaboradores e elimina consultas na contabilidade. Terceiro, o agente fecha as fontes de erro mais frequentes em auditorias de imposto sobre folha: diárias erradas, reduções esquecidas, dedução de imposto sobre insumos sem comprovantes corretos. Quarto, surge um motor de diárias BMF versionado que o agente de despesas de representação e o agente de imposto sobre folha co-utilizam - o investimento em infraestrutura se amortiza triplamente.

--- Agente Apuração de Tributos ---
> Apuração tributária mensal: ICMS Lei Kandir LC 87/96, ISS LC 116/03, PIS/COFINS Lei 10.833/03, SPED Fiscal EFD-ICMS/IPI, EFD-Contribuições e transição CBS/IBS EC 132/2023.

A apuração tributária no Brasil é o ponto em que a Diretoria Tributária prova credibilidade diante de sete fiscalizações simultâneas: a Receita Federal cruza a EFD-Contribuições, a EFD-ICMS/IPI e a DCTFWeb contra o Bloco I250 da ECD; as 27 SEFAZ Estaduais fiscalizam o ICMS pelo Convênio CONFAZ 142/2018 e pela Lei Kandir LC 87/96, incluindo a Substituição Tributária com MVA; os 5.570 municípios fiscalizam o ISS pela LC 116/2003; o CARF julga autuações federais com multa de ofício de 75% a 150% (Lei 9.430/96 art. 44); os Tribunais Estaduais julgam autuações de ICMS; o STF aplica jurisprudência vinculante (a Tese do Século, RE 574.706, sobre a exclusão do ICMS da base de PIS/COFINS, gerou R$ 250 bilhões em discussão judicial); e o Comitê Gestor do IBS administra a transição da Reforma Tributária (EC 132/2023) entre 2026 e 2032. Cada divergência mensal carrega risco duplo: glosa pela Receita Federal com multa de 75% a 150% acrescida de Selic e 1% ao mês, e bloqueio de CND federal e estadual que impede licitações (Lei 14.133/21) e financiamentos do BNDES, FINEP e Caixa.

## Glosa de R$ 250 bilhões discutidos no STF, bloqueio CND duplo e dual-regime CBS/IBS sem ferramenta quebra a apuração mensal

Uma indústria química de médio porte com 4 filiais em 3 estados (SP, MG, RJ), faturamento R$ 480 milhões/ano, regime Lucro Real, mix de produtos com ICMS-ST (combustíveis, solventes, embalagens), exportações via drawback e benefícios fiscais estaduais (crédito presumido SP) tem cerca de 12.000 notas fiscais mensais para apurar. Antes da automação, três analistas fiscais e um coordenador tributário gastavam de 12 a 18 dias úteis por mês importando dados do ERP, classificando CFOP/CST/NCM em planilhas paralelas, calculando ICMS-ST com MVA por estado, conciliando EFD-Contribuições contra EFD-ICMS/IPI e fechando DCTFWeb sempre no limite do prazo dia 15.

A consequência prática vai além do custo de mão de obra: empresas que não aplicaram corretamente a Tese do Século (RE 574.706/STF) entre 2017 e a modulação de 13/05/2021 sofreram autuações milionárias - excluir o ICMS da base de PIS/COFINS antes do trânsito em julgado individual gerou multa qualificada de 150% (Lei 9.430/96 art. 44 § 1). Em fiscalização da Receita Federal, divergências entre a DCTFWeb e o SPED (omissão de R$ 80 mil em PIS/COFINS porque o lançamento contábil da ECD não cruzou com a EFD-Contribuições) viram autuação de R$ 240 mil em multa mais R$ 80 mil de tributo, somados Selic e juros - total de R$ 320 mil a 400 mil sobre uma divergência operacional. O ICMS-ST aplicado com MVA errada (usar a MVA original em vez da Ajustada em operação interestadual SP-MG) gera dupla tributação irrecuperável até o ressarcimento na SEFAZ-SP, em prazo médio de 18 a 36 meses - o que mantém de R$ 200 mil a 500 mil bloqueados em capital de giro. E a Reforma Tributária (EC 132/2023 e LC 214/2025) obriga, a partir de 2026, o regime dual: o cálculo paralelo de PIS/COFINS e CBS (alíquota teste de 0,9% em 2026, substituição completa em 2027) e, depois, de ICMS, ISS e IBS (teste de 0,1% em 2029, substituição faseada até 2033) - sem uma ferramenta de regime dual, a empresa precisa reescrever o motor tributário a cada ano da transição.

## A apuração tributária brasileira percorre 16 etapas determinísticas, não 8 nem 14

Diferente do modelo alemão (8 etapas, focado em UStG, ELSTER e declaração intracomunitária), do polonês (12 etapas, com JPK_V7M, KSeF e a lista branca) e do brasileiro de conciliação bancária (14 etapas), a apuração tributária BR exige 16 etapas determinísticas porque o sistema tributário tem três camadas paralelas - a federal (RFB), a estadual (27 SEFAZ) e a municipal (5.570 prefeituras) -, somadas à transição de regime dual CBS/IBS da Reforma (EC 132/2023) entre 2026 e 2032. São elas: identificação do regime e da fase da transição CBS/IBS, importação dos dados fiscais por CFOP, CST e NCM, ICMS por estado com DIFAL pela Lei Kandir, ICMS-ST com MVA pelo Convênio CONFAZ 142/2018, IPI por NCM/TIPI, PIS/COFINS cumulativo ou não cumulativo pela Lei 10.833/2003, exclusão do ICMS da base de PIS/COFINS pelo STF RE 574.706, ISS pela LC 116/2003 art. 3, Simples Nacional no PGDAS-D, alíquota teste de CBS de 0,9% (2026) e de IBS de 0,1% (2029), cruzamento com o I250 da ECD, plausibilidade contra o histórico de 12 meses, aprovação humana para regimes especiais e variações materiais, geração de SPED e DCTFWeb, emissão de DARF e arquivamento por 5 anos.

Um cenário concreto: uma distribuidora de bebidas com 8 filiais em 5 estados, 18.000 notas fiscais mensais, mix com 70% de ICMS-ST (cerveja, refrigerantes e água), faturamento de R$ 720 milhões/ano e regime de Lucro Real ocupava cinco analistas fiscais em tempo integral. Após o Agente, o sistema importa as notas do ERP às 23h do último dia do mês e valida CFOP, CST, NCM e o Schema NF-e 4.00 (em média 17.850 notas válidas e 150 com divergência cadastral), calcula o ICMS por estado com DIFAL (em média R$ 28-32 milhões de imposto próprio mais R$ 18-22 milhões de ST), aplica o IPI por NCM (R$ 4-6 milhões), o PIS/COFINS não cumulativo com exclusão do ICMS conforme o RE 574.706 (R$ 32-38 milhões) e o ISS pela LC 116/2003 (R$ 800 mil a 1,2 milhão). A apuração da CBS teste de 2026 roda em paralelo (0,9%, ou R$ 5,4-6,5 milhões, compensável com PIS/COFINS), o cruzamento com o Bloco I250 da ECD fecha com tolerância de R$ 0,01 e a DCTFWeb é validada pelo PVA da RFB no dia 12, três dias antes do prazo. O tempo caiu de 18 dias úteis para 6 horas por mês de revisão humana de exceções (ZFM, drawback e variações materiais).

No [Decision Layer](/br/decision-layer/), 14 das 16 etapas são decisões baseadas em regras (nível R) - cada uma é cálculo determinístico contra a Lei Kandir LC 87/96, o Decreto 7.212/2010 (RIPI), a Lei 10.833/2003, a LC 116/2003, o Convênio CONFAZ 142/2018, a IN RFB 1.252/2012 ou a EC 132/2023 com a LC 214/2025. Uma etapa é plausibilidade aproximada (nível A, com score auditável e revisão humana acima de 15% de variação) e uma é decisão humana obrigatória (nível H): a aprovação de regimes especiais (ZFM, drawback, isenção pela LC 24/75) e de variações materiais que envolvem julgamento técnico-tributário do Diretor Tributário. Não há ponto em que a IA generativa decida sobre o cálculo de tributo - cada apuração aplica norma da RFB, da SEFAZ, do município ou do STF.

## Plausibilidade contra histórico 12 meses fecha o ciclo dual-regime CBS/IBS

A plausibilidade aproximada compara cada apuração mensal com a média móvel dos 12 meses anteriores do mesmo CNPJ, considerando a sazonalidade do CNAE. Variação superior a 15% (para mais ou para menos) em qualquer tributo (ICMS, IPI, PIS, COFINS, ISS, CBS ou IBS) aciona um alerta com hipóteses ranqueadas: (1) operação atípica de grande porte (negócio único acima de 10% da receita média); (2) mudança no mix de produtos (entrada de NCM com alíquota de IPI diferente); (3) entrada ou saída de estado com alíquota interestadual diferente; (4) inclusão ou exclusão de mercadoria do regime ICMS-ST por novo Convênio CONFAZ; (5) erro de classificação de CFOP, CST ou NCM; (6) duplicidade de lançamento; (7) impacto da Reforma Tributária na alíquota teste de CBS/IBS. A divergência fica visível antes do fechamento da apuração, em vez de aparecer em fiscalização três anos depois.

Para a transição CBS/IBS de 2026 a 2032, o Agente mantém o cálculo paralelo de regime dual durante todo o período: em 2026 calcula o PIS/COFINS atual e a CBS de 0,9% (paga o maior, conforme a LC 214/2025), em 2027 substitui o PIS/COFINS pela CBS com alíquota de referência do Senado, de 2029 a 2032 reduz o ICMS e o ISS progressivamente (10%, 20%, 30%, 40%, 50%, 60% e 70%) enquanto o IBS sobe em paralelo e em 2033 substitui por completo o ICMS e o ISS pelo IBS. Empresas que não implementarem o regime dual correm risco de glosa retroativa qualificada de 150% por descumprimento do cronograma constitucional da EC 132/2023.

## Edge-cases brasileiros: Tese do Século, ICMS-ST com MVA Ajustada, ZFM e drawback

Para situações tributárias atípicas, o Agente aplica regras específicas brasileiras: (1) Tese do Século (RE 574.706/STF) - exclui automaticamente o ICMS destacado na NF-e da base de PIS/COFINS nas apurações posteriores à modulação de 13/05/2021, calcula os créditos retroativos de 5 anos para empresas com ação judicial transitada em julgado e mantém log auditável de cada cálculo com o NSU da nota fiscal; (2) ICMS-ST com MVA Ajustada interestadual (Convênio CONFAZ ICMS 142/2018) - aplica a fórmula da MVA Ajustada, em que se toma (1 mais a MVA original), multiplica-se por (1 menos a alíquota interestadual), divide-se por (1 menos a alíquota interna do destino) e subtrai-se 1, para corrigir a distorção entre alíquotas e evitar a dupla tributação que leva de 18 a 36 meses para ser ressarcida na SEFAZ de origem; (3) Zona Franca de Manaus (Decreto-Lei 288/1967 e Lei 8.387/91) - identifica os produtos com PPB (Processo Produtivo Básico) habilitado pela SUFRAMA, valida o cadastro SUFRAMA do destinatário e aplica a isenção de IPI, a redução de ICMS e a suspensão de PIS/COFINS, condicionadas à internação efetiva (verificada via Mercante e Sintegra); (4) drawback (RE-DRAWBACK no SISCOMEX) - vincula a importação de insumos ao ato concessório, controla o prazo de 1 ano (prorrogável por mais 1) e calcula a inadimplência (II, IPI, PIS/COFINS-Importação e ICMS) se a exportação não for cumprida; (5) operação interestadual com benefício fiscal estadual irregular (LC 24/75 sem convênio CONFAZ) - alerta sobre o risco de guerra fiscal e aplica a jurisprudência do STF (ADIs sobre benefícios unilaterais), com aprovação humana obrigatória do Diretor Tributário.

## Integração com ecossistema tributário brasileiro: TOTVS, Mastersaf, SAP, Synchro/Sovos e Onesource

A lógica do Agente conecta-se aos principais motores tributários do mercado brasileiro via API: [TOTVS Protheus FI Tributos e TOTVS RM Cordilheira](https://www.totvs.com/) (líder em médias e grandes empresas, com apuração de ICMS multifederativa nativa e EFD-ICMS/IPI e EFD-Contribuições integradas), [Mastersaf DW (Thomson Reuters)](https://tax.thomsonreuters.com.br/produtos/mastersaf-dw) (motor tributário especializado para grandes empresas com fiscalização ativa, com foco na Substituição Tributária ICMS-ST e em benefícios fiscais), [SAP S/4HANA Brazil Localization](https://www.sap.com/brazil/) com Brazil Tax, GTW Global Trade e Tax & Revenue Management (multinacionais IBOVESPA integradas ao SAP TRM da matriz), [Synchro / Sovos Brasil](https://sovos.com/br/) (especialista em SPED, NF-e e obrigações acessórias multifederativas, com cobertura das 27 SEFAZ e dos 5.570 municípios), Oracle ERP Cloud Brazil Tax (gigantes com matriz nos EUA que exigem IFRS), Senior Sistemas Tributário (indústria média com integração ao CONFAZ), [Mastermaq Domínio](https://www.mastermaq.com.br/) (escritórios contábeis e PME no Simples Nacional e no Lucro Presumido) e Onesource Indirect Tax (Thomson Reuters) para grupos multinacionais que precisam de motor de regime dual CBS/IBS na transição da EC 132/2023. Para empresas com matriz na Europa ou nos EUA (Volkswagen, Bosch, Siemens e Ford, com unidades brasileiras), o Agente também consolida a posição tributária BR em formato compatível com o SAP TRM ou o Vertex, mantendo a operação local em conformidade com o SPED e a DCTFWeb e o reporting parental sob os padrões IFRS, com a tax provision sob ASC 740.

--- Agente de Onboarding de Fornecedores ---
> Extrai dados da autodeclaração, valida USt-ID, verifica listas de sanções, avalia riscos e cadastra no ERP. Em risco elevado, humano decide.

Cada novo fornecedor é um ponto de entrada de risco no cadastro de fornecedores. Quem cadastra sem verificação ali potencializa o erro em cada lançamento seguinte - do crédito tributário à execução de pagamentos. O Agent de Onboarding de Fornecedores torna a verificação uma etapa obrigatória antes que a primeira fatura entre no sistema.

## O problema não está no onboarding, mas no voo cego depois dele

A maioria das organizações financeiras verifica novos fornecedores no primeiro cadastro. Depois disso, entra o voo cego. Enquanto uma grande parte das empresas controla dados cadastrais no onboarding, a parcela que faz verificação sistemática antes da execução de pagamentos cai drasticamente. É exatamente nessa lacuna que operam os ataques de Vendor Impersonation: uma alteração de dados bancários, um registro vencido em lista de sanções, uma USt-ID inválida - e o dinheiro vai para a conta errada ou o crédito tributário cai na próxima auditoria.

A isso se soma o erro estrutural de dados. Muitos responsáveis por Procurement não têm visão clara da rede completa de fornecedores de sua organização; equipes de Purchase-to-Pay relatam regularmente a falta de alinhamento end-to-end e a falta de ownership dos dados cadastrais. Quem entra nessa corrida assim encontra duplicatas, dados bancários antigos e perfis de risco incompreensíveis só quando o dano já foi lançado.

## Um cenário que CFOs conhecem

Um fabricante químico de médio porte é contatado por um novo fornecedor de matéria-prima do Leste Europeu. Primeiro pedido: 240.000 EUR (262.000 USD). O setor de compras envia a autodeclaração à contabilidade, onde o fornecedor é cadastrado. Duas semanas depois chega a primeira fatura, é paga. Três meses mais tarde, o auditor interno descobre: a USt-ID era inválida desde o início. O crédito tributário precisa ser revertido, e a auditoria fiscal ainda questiona o dever de diligência. Ao mesmo tempo, o fornecedor aparece em uma lista de sanções atualizada - o responsável de compliance não tem processo para verificar cadastros existentes contra atualizações dessas listas.

Com o Agent de Onboarding de Fornecedores, esse caso é interrompido antes do primeiro pagamento. A validação no EU VIES reconhece a USt-ID inválida em segundos. A verificação contra listas EU, OFAC e ONU roda automaticamente e é aplicada ao cadastro a cada atualização das listas. Os dados bancários são conferidos algoritmicamente, o Duplicate Check protege contra cadastros duplos por engano, e o scoring de risco combina setor, país e dados de crédito em um indicador que o humano precisa aprovar quando ultrapassa o limiar.

## Como o [Decision Layer](/br/decision-layer/) decompõe o processo

O Agent mapeia nove etapas de decisão, cada uma com atribuição clara a regras, IA ou humano. Extração de dados cadastrais da autodeclaração e leitura de condições de pagamento em contratos usam processamento de documentos baseado em LLM. Validação de USt-ID, screening de sanções, verificação de IBAN, matching de duplicatas e cadastro no ERP rodam de forma baseada em regras, via integrações de API. A avaliação de risco é híbrida: fatores baseados em regras combinados com scoring por IA. Só uma decisão fica com o humano - a aprovação em caso de score de risco elevado. Onde é preciso julgamento, decide o responsável por compliance, documentado no audit trail.

## O que o Agent entrega ao CFO

O efeito econômico é duplo. Primeiro: a fragilidade estrutural desaparece. Cada fornecedor é validado antes que a primeira fatura seja lançada. Segundo: cria-se a base sobre a qual outros Finance Agents se apoiam. A validação de USt-ID é reutilizada pelo Agent de Recebimento de Faturas e pelo Agent de imposto Retido na Fonte. A verificação de sanções alimenta o Agent de Execução de Pagamentos. O padrão de scoring de risco vira projeto-base para o Agent de Fraud Detection. Construída uma vez, a infraestrutura atende vários processos em paralelo.

Para o CFO, isso significa: documentação robusta de Due Diligence para a auditoria fiscal, redução de exposição a Vendor Fraud e um cadastro de fornecedores em que a execução de pagamentos pode confiar. A partir de 22 de junho de 2026, as regras ampliadas da Nacha para monitoramento de fraude ACH também entram em vigor - quem hoje constrói uma infraestrutura de validação limpa cumpre essas exigências sem precisar adaptar depois.

--- Agente Retenções sobre Prestadores PJ ---
> Retenções sobre prestadores PJ: IRRF Lei 9.430/96 art. 64, CSLL/PIS/COFINS 4,65% Lei 10.833/03 art. 30, acordos para evitar dupla tributação - DARF, DCTFWeb e EFD-Reinf R-2010.

As retenções na fonte no Brasil são o ponto em que a Diretoria Tributária prova diligência legal diante de oito fiscalizações simultâneas: a Receita Federal cruza os eventos R-2010, R-2020 e R-2055 da EFD-Reinf contra a DCTFWeb e os DARFs recolhidos; o INSS fiscaliza as retenções de 11% sobre cessão de mão de obra (Lei 9.711/98), com cobrança retroativa de 5 anos; os 5.570 municípios fiscalizam o ISS retido pelo tomador conforme a LC 116/03 art. 6 e leis municipais distintas; a Justiça do Trabalho executa as retenções de pensão alimentícia (CPC art. 529), com responsabilidade pessoal do empregador em caso de descumprimento; o CARF julga autuações federais com multa de ofício de 75% a 150% (Lei 9.430/96 art. 44); o COAF exige comunicação em 24h pelo Siscoaf de operações suspeitas vinculadas a retenções; a PGFN inscreve em dívida ativa as retenções não recolhidas, com bloqueio de CND; e o Comitê Gestor do IBS administra a transição da Reforma Tributária (EC 132/2023) entre 2026 e 2032, mantendo o IRRF e o INSS e substituindo o PIS/COFINS/CSLL e o ISS por CBS/IBS. Cada pagamento mal classificado carrega risco triplo: glosa pela Receita Federal com multa de 75% a 150% acrescida de Selic e 1% ao mês, bloqueio de CND federal e estadual que impede licitações (Lei 14.133/21) e financiamentos do BNDES, FINEP e Caixa, e responsabilidade pessoal do administrador em caso de descumprimento de ordem de pensão alimentícia.

## Glosa Receita Federal multas 75-150% Lei 9.430/96, bloqueio CND duplo federal+estadual e sanção COAF por estruturação de retenção quebra a apuração mensal

Uma empresa de tecnologia de médio porte com 280 funcionários, 1.200 fornecedores PJ ativos (mix de consultores, advogados, auditores, terceirizadas de TI e empresas de vigilância), faturamento R$ 320 milhões/ano e regime Lucro Real tem cerca de 4.500 pagamentos mensais com potencial obrigação de retenção. Antes da automação, dois analistas fiscais e um coordenador tributário gastavam de 8 a 12 dias úteis por mês classificando cada pagamento, validando regime tributário do prestador, calculando retenções por tipo (IRRF 1,5% serviços profissionais, INSS 11% cessão mão de obra, PIS/COFINS/CSLL 4,65% serviços, ISS retido pelo município), gerando DARFs por código de receita e fechando EFD-Reinf no limite do prazo dia 15.

A consequência prática vai além do custo de mão de obra: o pagador é integralmente responsável pela retenção não realizada (RIR/2018 art. 7), nunca o destinatário. Em fiscalização da Receita Federal pós-2020, divergências entre a EFD-Reinf e a DCTFWeb (omissão de R$ 45 mil em IRRF porque o prestador foi classificado como Simples Nacional sem documentação adequada) viram autuação de R$ 135 mil em multa mais R$ 45 mil de tributo, somados Selic e juros - total de R$ 200 mil a 250 mil sobre uma divergência operacional. A retenção de INSS de 11% omitida em contrato de vigilância (R$ 80 mil sobre uma nota de R$ 720 mil) gera passivo previdenciário com cobrança retroativa de 5 anos - R$ 480 mil, mais juros e multa qualificada de 150% por sonegação se houver simulação. O descumprimento de ordem judicial de pensão alimentícia gera responsabilidade pessoal direta do administrador (CPC art. 533 § 3). E a Reforma Tributária (EC 132/2023 e LC 214/2025) obriga, a partir de 2027, o regime dual: o cálculo paralelo das retenções atuais de PIS/COFINS/CSLL e das retenções de CBS sobre os mesmos serviços, e depois o ISS-IBS de 2029 a 2032 - sem uma ferramenta de regime dual, a empresa precisa reescrever o motor de retenções a cada ano.

## As retenções na fonte brasileiras percorrem 16 etapas determinísticas, não 9 nem 12

Diferente do modelo alemão (9 etapas, focado em §50a EStG, tratados de dupla tributação e BZSt) e do polonês (12 etapas, com WHT-CIT, IFT-2R e a lista branca da KAS), as retenções na fonte BR exigem 16 etapas determinísticas porque o sistema tributário tem cinco camadas paralelas - a federal (IRRF, INSS e PIS/COFINS/CSLL), a municipal (ISS) e a judicial (pensão alimentícia e penhora) -, somadas à transição de regime dual CBS/IBS da Reforma (EC 132/2023) entre 2026 e 2032. São elas: classificação da natureza do pagamento (assistida por LLM nos casos ambíguos), verificação do regime tributário do prestador, IRRF de 1,5% sobre 28 serviços profissionais (Lei 9.430/96 art. 64), IRRF de 1,5% sobre aluguéis (Lei 7.713/88), IRRF salarial pela tabela progressiva mensal, retenção de INSS de 11% (Lei 9.711/98), retenção conjunta de PIS/COFINS/CSLL de 4,65% (Lei 10.833/03 art. 30), ISS retido conforme a LC 116/03 art. 6 e as 5.570 leis municipais, retenções judiciais com prioridade absoluta da pensão alimentícia, verificação de dispensas e limites mínimos, geração de DARF por código de receita, análise PLD-FT em padrões atípicos, plausibilidade contra a média histórica de 12 meses, aprovação humana para regimes especiais e variações materiais, geração dos eventos R-2010, R-2020 e R-2055 da EFD-Reinf e composição da DCTFWeb mensal, com arquivamento por 5 anos.

Um cenário concreto: uma empresa de varejo com 12 lojas em 4 estados, 2.800 fornecedores PJ ativos, contratos terceirizados de vigilância, limpeza, TI e auditoria externa, faturamento de R$ 580 milhões/ano e regime de Lucro Real ocupava três analistas fiscais em tempo integral. Após o Agente, o sistema importa as NFS-e diariamente do ERP e valida o CNPJ e o regime tributário pela consulta à Receita Federal (2.450 prestadores no Lucro Presumido ou Real e 350 no Simples Nacional), classifica a natureza do serviço (LLM com confiança acima de 95% em 92% dos casos, escalando 8% para revisão humana) e calcula as retenções por tipo (IRRF de R$ 28 mil/mês, INSS de 11% de R$ 92 mil/mês, PIS/COFINS/CSLL de R$ 14 mil/mês e ISS retido de R$ 18 mil/mês). Os DARFs são gerados com os códigos corretos (1708, 3208, 5952, 5979, 5987 e 2631), o cruzamento com a EFD-Reinf fecha com tolerância de R$ 0,01 e a transmissão é validada pelo PVA da RFB no dia 12, três dias antes do prazo. O tempo caiu de 12 dias úteis para 4 horas por mês de revisão humana de exceções.

No [Decision Layer](/br/decision-layer/), 13 das 16 etapas são decisões baseadas em regras (nível R) - cada uma é cálculo determinístico contra a Lei 9.430/96 art. 64, a Lei 9.711/98, a Lei 10.833/03 art. 30, a LC 116/03 art. 6, a IN RFB 1.234/2012, a IN RFB 2.043/2021 ou a EC 132/2023 com a LC 214/2025. Duas etapas são plausibilidade aproximada (nível A, com score auditável e revisão humana acima de 15% de variação ou diante de bandeiras do COAF) e uma é decisão humana obrigatória (nível H): a aprovação de retenções atípicas (regime especial, decisão judicial, prestador em paraíso fiscal) que envolvem julgamento técnico-tributário do Diretor Tributário. Não há ponto em que a IA generativa decida sobre o cálculo de retenção - a única etapa assistida por LLM é a classificação textual de natureza ambígua (etapa 1), com cálculo subsequente sempre determinístico contra a regulação da RFB, do INSS, do município ou da Justiça.

## Plausibilidade contra histórico 12 meses fecha o ciclo dual-regime CBS/IBS e PLD-FT

A plausibilidade aproximada compara cada apuração mensal de retenções com a média móvel dos 12 meses anteriores do mesmo CNPJ pagador, considerando a sazonalidade do CNAE. Variação superior a 15% (para mais ou para menos) em qualquer retenção (IRRF, INSS, ISS, PIS, COFINS ou CSLL) aciona um alerta com hipóteses ranqueadas: (1) novo contrato com prestador de cessão de mão de obra (entrada no escopo do INSS de 11%); (2) mudança de regime tributário do prestador (a saída do Simples Nacional gera retenções federais); (3) inclusão ou exclusão de serviço da lista da LC 116/03 art. 6 § 2 por nova lei municipal; (4) nova decisão judicial de pensão alimentícia ou penhora; (5) erro de classificação da natureza do pagamento (etapa 1, por LLM); (6) duplicidade de pagamento; (7) fragmentação anômala de contratos (sinal do COAF de estruturação para evitar retenção). A divergência fica visível antes do fechamento da apuração, em vez de aparecer em fiscalização três anos depois.

Para o PLD-FT (Lei 9.613/98 e Resolução COAF 36/2021), o Agente analisa padrões anômalos contra o perfil histórico do prestador, a lista de paraísos fiscais da OCDE e as bandeiras do COAF: fragmentação para evitar retenção, múltiplos pagamentos ao mesmo prestador no dia, prestadores em paraísos sem substância e valor incompatível com o porte do prestador. A comunicação ao Siscoaf é em 24h; a omissão gera multa do COAF de até R$ 20 milhões, além da responsabilização do compliance officer.

Para a transição CBS/IBS de 2026 a 2032, o Agente mantém o cálculo paralelo de regime dual: em 2026 calcula o PIS/COFINS/CSLL de 4,65% e a CBS teste de 0,9% sobre os mesmos serviços (paga o maior, conforme a LC 214/2025), em 2027 substitui o PIS/COFINS pela CBS mantendo a CSLL de 1% em separado, de 2029 a 2032 reduz o ISS retido enquanto o IBS sobe em paralelo e em 2033 substitui o ISS pelo IBS. Empresas sem regime dual correm risco de glosa retroativa qualificada de 150% por descumprimento do cronograma constitucional da EC 132/2023.

## Edge-cases brasileiros: cessão de mão de obra, paraíso fiscal, pensão alimentícia e dispensa Simples

Para situações atípicas, o Agente aplica regras específicas: (1) cessão de mão de obra ante empreitada (Lei 9.711/98 e IN RFB 2.110/2022 art. 112-119) - identifica a lista taxativa de serviços (vigilância, limpeza, manutenção predial, recepcionistas e enfermagem ocupacional) sujeita ao INSS de 11%; na dúvida, escala para o Diretor Tributário com proposta de retenção (pelo Senior-Default, é melhor reter e ressarcir via PER/DCOMP do que ter autuação retroativa); (2) pagamento a prestador em paraíso fiscal (lista da IN RFB 1.037/2010, com 65 jurisdições) - aplica IRRF de 25% (e não de 1,5%) conforme a Lei 9.249/95 art. 8, com comunicação ao COAF em 24h pelo Siscoaf; (3) pensão alimentícia com ordem judicial atualizada - integração ao eSocial S-1210 com o número do processo, prioridade absoluta (CPC art. 529 § 3) e bloqueio do pagamento até a confirmação; (4) dispensa do Simples Nacional sem declaração formal - bloqueio do pagamento até a documentação conforme a IN RFB 1.234/2012 art. 4; (5) fracionamento de contrato para evitar retenção (sinal do COAF) - alerta ao compliance officer com proposta de comunicação ao Siscoaf em 24h; (6) RPA para PF não empregada - IRRF pela tabela progressiva, INSS do empregado e ISS municipal conforme o cadastro de autônomos.

## Integração com ecossistema tributário brasileiro: TOTVS, SAP, Mastersaf, Synchro/Sovos e ADP

A lógica do Agente conecta-se aos principais motores tributários do mercado brasileiro via API: [TOTVS Protheus FI Tributos e TOTVS RM Cordilheira](https://www.totvs.com/) (retenções multifederativas nativas, com integração à EFD-Reinf e à DCTFWeb), [SAP S/4HANA Brazil Localization](https://www.sap.com/brazil/) com Brazil Tax, Withholding Tax Calculator e integração ao eSocial S-1210, [Mastersaf DW (Thomson Reuters)](https://tax.thomsonreuters.com.br/produtos/mastersaf-dw) (tabela atualizada da IN RFB 1.234/2012 e base das 5.570 leis municipais de ISS), [Synchro / Sovos Brasil](https://sovos.com/br/) (especialista nos eventos R-2010, R-2020 e R-2055 da EFD-Reinf), Senior Sistemas Tributário (indústria e serviços com integração à folha), [Mastermaq Domínio](https://www.mastermaq.com.br/) (escritórios contábeis e PME), ADP Brasil (integração das retenções de PJ com a folha de PF) e Oracle ERP Cloud Brazil Tax (grupos IBOVESPA com matriz nos EUA). Para empresas com matriz na Europa ou nos EUA (Volkswagen, Bosch, Siemens e Ford, com unidades brasileiras), o Agente consolida a posição de retenções BR em formato compatível com o SAP Tax Compliance ou o Vertex Source, mantendo a operação local em conformidade com a EFD-Reinf e a DCTFWeb e o reporting parental sob IFRS, com a tax provision sob ASC 740.

--- Agente Preparação Auditoria HR ---
> Preparação event-driven de auditoria HR: ISO 19600 / IDW PS 980, evidência Comissão de Representantes CIPA, exportação RIPD LGPD, mapa de risco assédio Lei 14.611/2023 - pacote completo para MTE, MPT e ANPD.

Auditoria de RH no Brasil cruza cinco regimes legais simultaneamente: CLT art. 461 e Lei 14.611/2023 sobre igualdade salarial entre mulheres e homens, Lei 14.457/2022 sobre prevenção e combate ao assédio sexual no trabalho, Lei 12.846/2013 e Decreto 11.129/2022 sobre Programa de Integridade anticorrupção, LGPD art. 7 IX e art. 11 sobre dados pessoais sensíveis de empregados, e os prazos eSocial S-2200 (admissão) e S-2400 (cadastro inicial vínculo). Cada um com sanção própria, prazo próprio e órgão fiscalizador próprio. O auditor da Auditoria-Fiscal Trabalhista do MTE não conversa com o procurador do MPT, que não conversa com o fiscal da ANPD, que não conversa com a CGU. A empresa precisa estar pronta para todos.

## A multa da Lei 14.611/2023 é de 3% da folha, mas o dano reputacional no Portal Emprega Brasil pesa mais

A Lei 14.611/2023 (Igualdade Salarial entre Mulheres e Homens) criou uma obrigação radicalmente nova no Brasil: empresas com 100 ou mais empregados precisam publicar semestralmente, em março e setembro, um Relatório de Transparência Salarial no Portal Emprega Brasil. O relatório agrupa remuneração por CBO (Classificação Brasileira de Ocupações), função, gênero, raça e faixa etária. Diferenças salariais não justificadas exigem Plano de Ação para Mitigação - documentado, com metas, prazos e responsáveis (Decreto 11.795/2023 art. 6).

A multa por falta de publicação é 3% da folha (limitada a 100 salários mínimos). Para empresa de 800 colaboradores com folha mensal típica de R$ 4 milhões, isso significa R$ 120 mil por semestre não publicado - mas o dano reputacional é maior: o Portal Emprega Brasil é público. Imprensa, sindicato, MPT, candidatos consultam. Empresas não publicantes ficam expostas em listagem oficial.

## A auditoria HR brasileira percorre 16 etapas determinísticas em cinco regimes legais

A auditoria HR brasileira é multi-regime por design. As 16 etapas cobrem igualdade salarial (1 a 4), anti-assédio e CIPA (5 a 7), anticorrupção e Programa de Integridade (8 e 9), dados sensíveis sob a LGPD (10 e 11), eSocial e segurança do trabalho (12 e 13) e, por fim, remediação e evidência (14 a 16).

Cenário concreto: indústria com 800 colaboradores CLT, 320 mulheres distribuídas em 47 funções. A Lei 14.611/2023 exige cálculo de brecha salarial em CADA função homóloga - a comparação entre homens e mulheres na mesma CBO, no mesmo nível hierárquico e na mesma senioridade. Brecha superior a 5% sem justificativa documentada dispara o gatilho do Plano de Ação. Para a empresa: 47 cálculos semestrais, dos quais 12 podem disparar Plano de Ação, depois 12 monitoramentos de execução em 6-12 meses, depois nova publicação semestral.

No [Decision Layer](/br/decision-layer/), cada etapa é classificada como decisão baseada em regras (R), análise sobre dados estruturados (A) ou decisão humana (H). Extração de remuneração por CBO é R (vem dos eventos eSocial de admissão e remuneração). Cálculo da brecha salarial é R (metodologia Decreto 11.795/2023 art. 4). Publicação semestral é R (prazo fixo em março e setembro). Avaliação da adequação do Plano de Ação é H - exige que Compliance Officer, RH e Diversidade decidam se as medidas têm chance de reduzir a brecha. Análises (A) cobrem a due diligence de empregados-chave, com cruzamento contra as listas CNEP/CEIS da CGU e sanções OFAC, e o rastreamento de casos de assédio.

## Anti-assédio Lei 14.457/2022 transformou a CIPA e o canal de denúncia

A Lei 14.457/2022 (Programa Emprega + Mais Mulheres) ampliou as obrigações da CIPA (Comissão Interna de Prevenção de Acidentes) para incluir prevenção e combate ao assédio sexual. Toda empresa com CIPA precisa: (1) manter canal de denúncia ativo, anônimo e independente da hierarquia direta - interno terceirizado ou externo; (2) realizar treinamentos anuais sobre prevenção de assédio sexual e violência para todos os colaboradores e gestores - com registro eSocial S-2220 de capacitação; (3) estabelecer procedimentos internos para investigação - comissão de apuração designada em até 5 dias úteis e parecer em até 60 dias.

Casos confirmados de assédio geram dano extrapatrimonial conforme Lei 13.467/2017 (Reforma Trabalhista) art. 223-G: tarifação de 3 a 50 vezes o salário do ofendido conforme gravidade da conduta. Empresa também responde solidariamente sob art. 932 III do Código Civil (responsabilidade civil empregador por atos do empregado no exercício do trabalho). Casos não tratados tempestivamente expõem a empresa a Termo de Ajustamento de Conduta (TAC) com o MPT - cumprimento sob multa diária e publicidade negativa.

O agente rastreia cada caso desde entrada (timestamp do canal de denúncia) até parecer final, preservando sigilo da vítima por design (LGPD art. 6 VIII princípio da prevenção). Comissão designada além de 5 dias úteis ou parecer além de 60 dias gera escalação automática ao Compliance Officer.

## Programa de Integridade Lei 12.846/2013: 16 parâmetros, atenuante de 1-4% na multa

A Lei Anticorrupção (Lei 12.846/2013) estabeleceu responsabilidade objetiva da pessoa jurídica por atos lesivos contra a administração pública nacional ou estrangeira. A multa vai de 0,1% a 20% do faturamento bruto do exercício anterior, somada a publicação extraordinária e interdição parcial. O Decreto 11.129/2022 detalhou em seu art. 56 os 16 parâmetros do Programa de Integridade que, quando efetivos, atenuam a multa em 1% a 4%.

Os parâmetros aplicáveis ao RH incluem: comprometimento da alta direção (tone at the top documentado), código de conduta acessível e traduzido para todos os idiomas dos colaboradores, treinamentos periódicos sobre integridade, canal de denúncia (que pode ser o mesmo da Lei 14.457/2022 anti-assédio, com escopo ampliado), due diligence de empregados em posições sensíveis (diretores, executivos com poder de decisão sobre contratos públicos, gerentes de licitação), procedimentos disciplinares claros, registros contábeis fidedignos. O cruzamento contra as listas CNEP/CEIS da CGU (Cadastro Nacional de Empresas Punidas e de Empresas Inidôneas e Suspensas), as sanções internacionais OFAC e processos judiciais é feito automaticamente para empregados-chave, com revisão humana obrigatória nos casos com correspondência.

A diferença entre Programa de Integridade efetivo e formal é o que a CGU/PAR avalia em processo administrativo de responsabilização. Formalismo sem efetividade não atenua nada. O agente documenta evidência de funcionamento real: denúncias recebidas, percentual investigado em prazo, sanções efetivas, cobertura de treinamentos por departamento, due diligence executadas por trimestre.

## LGPD art. 7 IX e art. 11: dados sensíveis de empregados exigem RIPD e DPO

Auditoria HR no Brasil mexe com dados sensíveis por design. Filiação sindical (categoria especial art. 5 II), saúde (PCMSO NR-7, ASOs, CID em afastamentos), biometria de ponto eletrônico, origem racial (declarada para Lei 14.611/2023). O tratamento exige base legal art. 7 IX (legítimo interesse trabalhista) ou art. 11 §2 II (cumprimento obrigação legal trabalhista) - nunca apenas consentimento, porque a relação empregatícia é assimétrica e o consentimento livre é questionável.

A LGPD exige RIPD (Relatório de Impacto à Proteção de Dados Pessoais) registrado para cada processo HR sensível, Encarregado (DPO) designado e publicado, princípio do menor privilégio aplicado (gestor vê apenas sua equipe, RH operacional vê totalizadores agregados, DPO vê metadados de acesso, Auditoria vê tudo com log), auditoria de acesso registrada. Vazamento de dados de colaboradores: comunicação ANPD em até 72 horas via e-Petição (Resolução ANPD 2/2022) e ao titular afetado se houver risco relevante. As sanções vão da advertência à multa de 2% do faturamento brasileiro, limitada a R$ 50 milhões por infração, e ao bloqueio dos dados.

Para multinacional com matriz UE, há camada adicional: dados ficam no Brasil (LGPD), mas KPIs agregados sobem para a sede para CSRD ESRS S1 Workers. Transferência internacional sob LGPD art. 33 - cláusulas-padrão ANPD ou decisão de adequação. O agente assegura que apenas KPIs agregados (sem identificação individual) cruzam fronteiras, mantendo dados fonte localmente.

## eSocial S-2200/S-2400 e a fiscalização cruzada com Auditoria-Fiscal Trabalhista

O eSocial transformou a auditoria HR brasileira: dados de admissão (S-2200), remuneração (S-1200), afastamentos (S-2230), treinamentos (S-2220), acidentes (S-2210) e desligamentos (S-2299) ficam no governo em tempo quase real. A Auditoria-Fiscal Trabalhista do MTE cruza eSocial com folha, GFIP histórica, NF-e (rastreio de pagamentos a prestadores PJ que podem ser pejotização), CAGED descontinuado e atual CAGED 2.0.

S-2200 deve ser enviado ANTES do início efetivo da prestação de serviço. Trabalho prestado sem S-2200 é informalidade trabalhista - art. 47 CLT, multa R$ 425,64 a R$ 4.256,40 por empregado, mais reclamação trabalhista TRT por vínculo não reconhecido com 2 anos prescricionais pós-rescisão e 5 anos retroativos. O agente monitora: integração com o sistema de admissão (TOTVS RM, Senior HCM, ADP Brasil), validação de dados obrigatórios (CPF, NIS, CTPS digital, dependentes IRRF), envio automático ao Portal eSocial via webservice com certificado A1/A3 ICP-Brasil, recibo de processamento. Atrasos disparam alerta automático ao Departamento de Pessoal antes da fiscalização descobrir.

S-2400 (cadastro inicial vínculo) cobre vínculos pré-eSocial e segue cronograma faseado por grupo de empresa - o agente acompanha as Notas Técnicas do MOS eSocial 2024 e suas atualizações.

## Achados em aberto: rastreamento até causa-raiz, não até preenchimento de campo

Toda auditoria HR brasileira termina com lista de achados: irregularidades formais (S-2200 atrasado), materiais (brecha salarial não justificada), graves (caso de assédio não tratado em prazo) ou sistêmicas (Programa de Integridade ineficaz). Sem rastreamento estruturado, achados se perdem no arquivo - reaparecem na auditoria seguinte como recorrentes, agravando a percepção do auditor e endurecendo eventual TAC com MPT ou sanção CGU.

O agente registra cada achado com responsável, prazo, plano de ação e verificação de eficácia. Vencimentos geram escalação antes do próximo auditor descobrir. Mas a verificação de causa-raiz é decisão humana (H) - o Compliance Officer e o Jurídico Trabalhista avaliam se a ação corretiva eliminou o problema ou apenas tratou o sintoma. Achado recorrente é evidência de que a verificação anterior foi superficial. Para auditor MTE, MPT ou ANPD, achado recorrente é sinal de incapacidade institucional - o nível de exigência sobe imediatamente.

## Integração com ecossistema brasileiro: TOTVS, SAP SuccessFactors, Workday, eSocial e Portal Emprega Brasil

A lógica do agente conecta-se aos principais sistemas HCM do mercado brasileiro via API: [TOTVS RM Folha e Datasul HCM](https://www.totvs.com/) (líder em médias e grandes empresas, 50.000+ clientes), Senior Sistemas HCM (forte em indústria), SAP SuccessFactors Brasil (multinacionais), Workday HCM (multilatinas e listadas IBOVESPA), Oracle HCM Cloud (gigantes), ADP Brasil (matrizes EUA com filial BR) e Apdata (média empresa). Para empresas listadas na CVM, o agente alimenta também o disclosure de risco trabalhista exigido pela Resolução CVM 80/2022, integrando-se com o sistema de Relações com Investidores. Para multinacional com matriz UE, gera KPIs paralelos compatíveis com o ESRS S1 Workers da CSRD (brecha salarial, taxa de rotatividade, frequência de acidentes, horas de treinamento, casos de discriminação), mantendo dados-fonte no Brasil sob LGPD e enviando apenas agregados para consolidação na sede europeia.

--- Agente de Inscrição em Benefícios ---
> Inscrição em benefícios CLT como Previdência Complementar, PAT, Vale-Transporte e PLR, com geração automática do eSocial e conformidade LGPD.

A inscrição em benefícios no Brasil cruza sete regimes legais ao mesmo tempo: as utilidades não-salariais da CLT art. 458, o PAT (Lei 6.321/76, com dedução de IR de 4% do lucro real), o Vale-Transporte da Lei 7.418/85 (desconto máximo de 6% do salário), o INSS da Lei 8.212/91 com alíquotas progressivas, a Previdência Complementar da LC 109/2001 (entidades fechadas fiscalizadas pela PREVIC e abertas pela SUSEP), a Saúde Suplementar da Lei 9.656/98 (planos coletivos sob a ANS) e a PLR da Lei 10.101/2000 (isenta de IR até R$ 6.677,55 no ano-base 2024). Cada regime tem órgão fiscalizador, sanção e prazo próprios. O auditor da Receita Federal não conversa com o fiscal da PREVIC, que não conversa com o procurador da ANS, que não conversa com a ANPD. A empresa precisa estar pronta para todos.

## PAT registra dedução IR de 4% do lucro real - mas só se rubricas eSocial S-1010 estiverem corretas

O PAT (Programa de Alimentação do Trabalhador), regido pela Lei 6.321/76 e pela Portaria MTb 03/2002, permite à empresa cadastrada deduzir até 4% do lucro real (apuração trimestral ou anual) com despesas de alimentação dos trabalhadores. Para empresa com lucro tributável de R$ 50 milhões, isso significa até R$ 2 milhões anuais de dedução fiscal preservada - desde que o cadastro PAT esteja vigente no Ministério do Trabalho, a modalidade respeitada (autogestão, terceirizada via FlashApp, Caju, VR, Alelo ou Ticket Restaurante, alimentação no local com convênio, ou cesta básica) e o custo do empregado limitado a 25% do total, com 75% custeados pela empresa (Portaria 03/2002 art. 4).

A pegadinha mais comum é a rubrica eSocial S-1010 cadastrada com natureza errada. O PAT é natureza 5004 (informativa, não-incidente sobre INSS, FGTS e IRRF). Se for cadastrado como natureza 1000 (vencimentos), passa a integrar a base de cálculo: a empresa paga INSS patronal de 28% a 31% e FGTS de 8% sobre o valor, o empregado paga INSS progressivo e IRRF, e a dedução do PAT se perde. A multa retroativa é de 75% a 150% (art. 44 da Lei 9.430/96), acrescida de juros pela SELIC e 1% ao mês.

## A inscrição em benefícios brasileira percorre 15 etapas determinísticas em sete regimes legais

A inscrição em benefícios brasileira é multi-regime por design. As 15 etapas cobrem: gatilho e enquadramento CLT (1-2), Vale-Transporte e PAT (3-4), INSS e Previdência Complementar (5-7), Saúde Suplementar (8), apresentação personalizada e confirmação humana (9-10), PLR e sincronização eSocial (11-13), monitoramento e auditoria (14-15).

Cenário concreto: indústria com 1.500 colaboradores CLT em três estados (SP, MG, BA), folha mensal R$ 9 milhões, lucro tributável R$ 80 milhões/ano. Pacote de benefícios: Plano de Saúde coletivo Bradesco Saúde RN 195/2009, Vale-Refeição Caju (PAT autogestão terceirizada), Vale-Transporte conforme Lei 7.418/85, Previdência Complementar EFPC patrocinada (matching empresa 100% até 6% salário), PLR semestral conforme acordo com Sindicato dos Metalúrgicos. Janela anual de inscrição em outubro-novembro com adesão automática para Previdência (Resolução CNPC 30/2018). Total: 5 categorias, 15 etapas determinísticas por colaborador, cerca de 22.500 micro-decisões na janela anual completa.

No [Decision Layer](/br/decision-layer/), cada etapa é classificada como decisão baseada em regras (R), análise sobre dados estruturados (A) ou decisão humana (H). Cálculo de elegibilidade Vale-Transporte é R (Lei 7.418/85 art. 4 - menor valor entre 6% salário e custo passagens). Cálculo INSS progressivo é R (faixas EC 103/2019). Validação adesão automática Previdência é R (Resolução CNPC 30/2018 art. 8). Apresentação do simulador de impacto líquido é A (formatação dinâmica baseada em dados estruturados, não decisão sobre direitos). Confirmação de adesão é H - decisão humana obrigatória do colaborador, porque a relação empregatícia assimétrica não permite consentimento presumido (LGPD art. 7 IX combinado com Decreto 11.246/2022). PLR validation é R com escalação humana se acordo MTE/Sindicato vencido.

## Vale-Transporte Lei 7.418/85: 6% do salário como teto, declaração formal obrigatória

A Lei 7.418/85, regulamentada pelo Decreto 95.247/87, estabelece que o Vale-Transporte tem desconto máximo de 6% do salário-base do empregado (sem incluir Vale-Refeição, PLR e outras parcelas). A diferença entre o custo total das passagens e os 6% é despesa não-salarial da empresa (CLT art. 458 IV). Um empregado com salário de R$ 4.000 e custo de passagens de R$ 350 por mês tem desconto de R$ 240 (6% de R$ 4.000), enquanto a empresa paga R$ 110, sem incidência de INSS, FGTS ou IRRF.

O agente coleta a declaração formal anual do empregado conforme Decreto 95.247/87 art. 7 - sem essa declaração, o direito ao Vale-Transporte é afastado pela jurisprudência consolidada do TST. A declaração precisa especificar endereço residencial, modalidade de deslocamento (rodoviário, metroviário, ferroviário, integração) e itinerários. Empregado que usa carro próprio não tem direito a Vale-Transporte (art. 1 §1 Lei 7.418/85), salvo acordo coletivo específico.

A rubrica eSocial S-1010 precisa ter natureza 5006 (Vale-Transporte parte empregado, descontado) e 5007 (parte empresa, custeio). Erro de natureza configura desvirtuamento e gera reclamação trabalhista no TRT, em que o empregado pleiteia a incorporação ao salário com reflexos retroativos sobre INSS, FGTS, 13º, férias e 1/3 constitucional, com prescrição de dois anos após a rescisão e cinco anos retroativos.

## INSS aliquotas progressivas EC 103/2019: cálculo por faixa, não pela aliquota máxima

Desde a EC 103/2019, o INSS do empregado CLT é progressivo por faixa, não pela alíquota máxima sobre o salário inteiro. A tabela de 2026 vai de 7,5% até R$ 1.518,00 a 14% no teto de R$ 7.786,02, passando por 9% e 12%. Um empregado com salário de R$ 5.000 paga R$ 491,53, e não os R$ 700 que sairiam de 14% sobre os R$ 5.000. Sobre a folha bruta, o empregador recolhe cerca de 28% a 31%: 20% de INSS patronal, o RAT de 1% a 3% conforme o CNAE multiplicado pelo FAP e cerca de 5,8% de Terceiros (SENAI, SESI, SEBRAE, INCRA, Salário-Educação). Uma empresa com folha de R$ 9 milhões por mês paga aproximadamente R$ 2,5 milhões de INSS patronal.

O simulador de impacto do agente apresenta ao colaborador o líquido considerando a alíquota progressiva correta. O cálculo errado pela alíquota máxima gera divergência na DCTF e no DARF e exige GFIP retificadora, com multa de 0,33% ao dia (limitada a 20%), juros pela SELIC e 1% ao mês.

## Previdência Complementar LC 109/2001: EFPC fiscalizada PREVIC, EAPC fiscalizada SUSEP

A LC 109/2001 estruturou a Previdência Complementar em duas modalidades. A EFPC (Entidade Fechada) é o fundo de pensão patrocinado pela empresa, com regulamento aprovado pela PREVIC e dedução de IRPJ de até 20% da folha (art. 13 da Lei 9.532/97). A EAPC (Entidade Aberta) é o PGBL ou VGBL fiscalizado pela SUSEP, sem contrapartida da empresa. A Resolução CNPC 30/2018 passou a permitir a adesão automática na EFPC, com janela de opt-out de 90 dias, e estudos mostram aumento de adesão de 30%-40% para 80%-90%.

O agente classifica o plano, ativa a adesão automática quando a EFPC permite, calcula a contrapartida da empresa (tipicamente de 50% a 100% até 6% do salário) e valida que a dedução de IRPJ não excede 20% da folha-base. O vesting da EFPC costuma ser de 5 a 10 anos, com portabilidade após 3 anos sem incidência de IR. A rubrica eSocial S-1010 usa natureza 9912 (parte empregado) e 5908 (parte empregador).

## PLR Lei 10.101/2000: isenção de IR até R$ 6.677,55 com acordo coletivo formalizado

Pela CF art. 7 XI e pela Lei 10.101/2000, a PLR não integra a remuneração para INSS e FGTS e é isenta de IR até R$ 6.677,55 (ano-base 2024, Decreto 11.557/2023), com no máximo dois pagamentos no ano-civil. Só vale com acordo coletivo formalizado com o sindicato. O pagamento como salário, sem acordo, gera tributação cheia: INSS do empregado de 7,5% a 14%, INSS patronal de 28% a 31%, FGTS de 8% e IRRF de até 27,5%. Para uma PLR de R$ 15 milhões no total (1.500 colaboradores a R$ 10.000), a reclassificação acrescenta cerca de 50% em tributação, mais a multa de 75% a 150% da Lei 9.430/96, chegando a uma exposição de R$ 12 a 18 milhões.

O agente bloqueia o lançamento PLR se acordo MTE/Sindicato vencido, metas não auditáveis (jurisprudência TST: tempo de casa não vale) ou excesso de 2 pagamentos no ano. Valor acima do isento é tributado IRRF na fonte com tabela específica, separado do salário do mês. Rubrica eSocial S-1010 natureza 6055 (PLR informativa, não-incidente).

## Saúde suplementar: plano coletivo sob a Lei 9.656/98 e dados de saúde protegidos pela LGPD

O plano coletivo empresarial, conforme as RN ANS 195/2009 e 412/2016, tem carência reduzida (até 30 dias após a admissão), reajuste pela sinistralidade do grupo, dependentes elegíveis (cônjuge e filhos até 24 anos universitários) e cobertura mínima do rol da ANS (RN 465/2021). Eventos de vida como casamento, nascimento ou divórcio reabrem a janela em até 30 dias.

O tratamento sob a LGPD é crítico: os dados sensíveis de saúde (como o CID em ASOs do PCMSO) NÃO são compartilhados com a operadora, apenas os dados cadastrais. A base legal vem da LGPD, no legítimo interesse trabalhista (art. 7 IX) ou na obrigação legal trabalhista (art. 11 §2 II), com RIPD registrado e DPO designado. Em caso de vazamento, a comunicação à ANPD ocorre em até 72 horas via e-Petição (Resolução ANPD 2/2022). A rubrica eSocial S-1010 usa natureza 9931 (parte empregado) e 5912 (parte empregador).

## Integração com ecossistema brasileiro: TOTVS, FlashApp, Caju, eSocial, PREVIC, SUSEP, ANS

A lógica do agente conecta-se aos principais sistemas HCM e operadoras de benefícios do mercado brasileiro via API: [TOTVS RM Folha, Datasul HCM e TOTVS Benefícios](https://www.totvs.com/) (líder em médias e grandes empresas, 50.000+ clientes), Senior Sistemas HCM (forte em indústria), SAP SuccessFactors Brasil Benefits (multinacionais), Workday HCM (multilatinas e listadas IBOVESPA), Oracle HCM Cloud Benefits, ADP Brasil (matrizes EUA com filial BR) e Apdata (média empresa). Para Vale-Refeição e Vale-Alimentação, integra com FlashApp, Caju, iFood Benefícios, VR Benefícios, Alelo e Ticket Restaurante, cada operadora com API de cadastro e cargas mensais. Para Previdência Complementar, integra com plataformas EFPC patrocinadas (BB Previdência, PREVI, FUNCEF, PETROS, Itaú Vida e Previdência) ou EAPC (Brasilprev, Bradesco Vida e Previdência, Icatu, Caixa Vida e Previdência). Para Saúde Suplementar, conecta-se via API às operadoras (Bradesco Saúde, SulAmérica, Amil, Unimed, Hapvida, Notre Dame Intermédica). Para multinacional com matriz UE, gera KPIs agregados compatíveis com o ESRS S1 Workers da CSRD (percentual de adesão à Previdência Complementar, percentual de Saúde Suplementar, contribuição média do patrocinador), mantendo dados-fonte no Brasil sob LGPD e enviando apenas agregados para consolidação na sede europeia.

--- Agente Triagem Candidatos ---
> Triagem de candidatos CLT-compliant: Lei 9.029/1995 anti-discriminação, LGPD Art. 11 dados sensíveis e Lei 8.213/91 art. 93 cota PCD - shortlist documentada com auditoria de viés.

Triagem de candidatos no Brasil cruza simultaneamente seis regimes legais críticos: Lei 9.029/1995 (proibição práticas discriminatórias e limitativas para admissão na relação de emprego), Lei 14.611/2023 + Decreto 11.795/2023 + Portaria MTE 3.714/2023 (Igualdade Salarial entre homens e mulheres com Relatório de Transparência Salarial semestral fiscalizado pelo MTE), LGPD Lei 13.709/2018 art. 11 (dados pessoais sensíveis: raça, etnia, religião, opinião política, dados de saúde, dados genéticos e biométricos), Lei 8.213/91 art. 93 (cota PCD - empresas com 100+ empregados devem reservar 2% a 5% das vagas), Lei 14.457/2022 (Programa Emprega + Mais Mulheres + Combate ao Assédio) e PL 2338/2023 (Marco Regulatório de IA em tramitação - sistemas em recrutamento e seleção classificados como alto risco). Cada um com órgão fiscalizador próprio: MPT investiga discriminação na admissão via TAC ou ACP, MTE fiscaliza Relatório Transparência Salarial e cota PCD, ANPD audita LGPD com DPIA Resolução 4/2023, TST consolidou jurisprudência (Súmula 443) que inverte o ônus da prova em dispensa discriminatória. A empresa precisa estar pronta para todos.

## No Brasil, uma triagem caixa-preta vira multa, reintegração e dano moral sob a Lei 9.029/1995, a LGPD e a cota PCD

A Lei 9.029/1995 proíbe expressamente práticas discriminatórias na admissão por motivo de sexo, origem, raça, cor, estado civil, situação familiar, deficiência ou idade, com sanção de multa, reintegração e dano moral. A CF/88 art. 5 inciso XLII tipifica o racismo como crime inafiançável e imprescritível. Súmula TST 443 inverte o ônus da prova em dispensa discriminatória presumida - a empresa precisa documentar a fundamentação não-discriminatória, sob pena de procedência da reclamação trabalhista. LGPD art. 20 garante ao titular o direito à revisão de decisões automatizadas em até 15 dias.

A pegadinha mais comum: triagem por IA tratada como sistema monolítico (candidatura entra, score sai). Mobley v. Workday (Tribunal Federal Califórnia, 2024) é o precedente que materializou o risco - candidato processou o fornecedor de software de IA por discriminação sistemática. Universidade de Washington (Munyaka et al., 2024) demonstrou que triagens de IA preferiram nomes associados a origem branca em até 85% dos casos; em algumas categorias profissionais, candidatos negros do sexo masculino foram desfavorecidos em 100% dos testes. Lei 14.611/2023 obriga Relatório de Transparência Salarial semestral - multa de até 3% da folha (limitada a 100 salários mínimos, ~R$ 152.000 em 2026). A multa da LGPD chega a 2% do faturamento brasileiro, limitada a R$ 50 milhões por infração. A cota PCD descumprida custa de R$ 2.000 a R$ 200.000 por vaga não preenchida, mais TAC ou ACP do MPT. Cumulativamente, a exposição plurianual chega a dezenas de milhões.

## A triagem brasileira percorre 15 etapas determinísticas em seis regimes legais

A triagem é multi-regime por design. As 15 etapas cobrem: validação de base legal LGPD para dados sensíveis e critérios eliminatórios (1-2), extração estruturada e autodeclaração étnico-racial e PCD (3-4), match por dimensão e identificação de lacunas (5-6), validação de testes psicológicos CRP (7), fairness monitoring e alerta de viés (8-9), apresentação anonimizada ao recrutador (10), decisão humana e documentação (11-12), notificação ao rejeitado e sincronização eSocial S-2200 (13-14), pacote de evidências para auditoria (15).

Cenário concreto: indústria com 1.500 colaboradores CLT em três estados (SP, MG, BA), folha mensal de R$ 9 milhões, com 8 vagas abertas em CBO técnico-administrativo e 2 vagas reservadas para PCD (cota de 4% para 1.001 a 2.000 empregados, conforme a Lei 8.213/91 art. 93). O volume mensal é de 600 a 800 candidaturas via Gupy ATS e de 240 a 320 via portal próprio integrado ao Kenoby. O pacote reúne TOTVS RM Folha e Datasul HCM, o eSocial, o RIPD na ANPD, o Relatório de Transparência Salarial da Lei 14.611/2023 e a autodeclaração étnico-racial do Decreto 8.136/2013 e do Estatuto da Igualdade Racial. No total, são 15 etapas determinísticas por candidatura, cerca de 15.000 micro-decisões por mês, com monitoramento contínuo de equidade e revisão semanal pelo Compliance e pelo DPO.

No [Decision Layer](/br/decision-layer/), cada etapa é classificada como decisão baseada em regras (R), análise sobre dados estruturados (A) ou decisão humana (H). Validação de base legal LGPD é R (art. 11 §2 II - obrigação legal cota PCD ou consentimento específico). Critérios eliminatórios são R (apenas requisitos comprovadamente essenciais validados pelo Jurídico Trabalhista contra Lei 9.029/1995). A aplicação de cota PCD é R (Lei 8.213/91 art. 93 e LBI). O match por dimensão é A (decomposição em 6 a 8 dimensões com justificativa textual, sem score global de caixa-preta). O monitoramento de equidade é A (análise estatística contínua, com a regra dos 80% de impacto desproporcional). O avanço para a entrevista é H, decisão humana obrigatória do recrutador, porque a LGPD art. 20 e o PL 2338/2023 garantem o direito à revisão e à supervisão humana efetiva.

## Critérios eliminatórios só quando comprovadamente essenciais, sob a Lei 9.029/1995 e a Constituição

A Lei 9.029/1995, com a CF/88 art. 7 inciso XXX, veda a diferença de critério de admissão por motivo de sexo, idade, cor ou estado civil. Os critérios eliminatórios determinísticos do agente são apenas os comprovadamente necessários para o exercício da função: registro profissional vigente em conselho fiscalizador (CRM, CRP, OAB, CRA, CREA), formação acadêmica obrigatória pelo conselho profissional, idiomas para função internacional documentados na descrição da vaga e CNH de classe específica para motoristas profissionais. Idade sem justificativa funcional, estado civil, ter filhos, origem geográfica e religião são VEDADOS, conforme jurisprudência consolidada do TST.

O parser de extração tem campos pré-definidos e bloqueio explícito para inferências discriminatórias. Nome completo, foto, endereço, data de nascimento, estado civil, religião e origem geográfica NÃO são variáveis de classificação. O CV anonimizado é entregue ao recrutador na primeira fase para reduzir o viés inconsciente, com identificação plena apenas após a shortlist para entrevista. O MPT pode propor TAC ou Ação Civil Pública por discriminação sistêmica, e um estudo do Insper de 2023 mostrou que essas ações no Brasil geram acordos médios de R$ 8 a 15 milhões em empresas de médio porte por descumprimento da Lei 9.029/1995.

## Lei 8.213/91 art. 93: cota PCD como obrigação legal automatizada

A Lei 8.213/91 art. 93 obriga empresas com 100 ou mais empregados a reservar um percentual das vagas para Pessoas com Deficiência ou reabilitadas pelo INSS: 2% de 100 a 200, 3% de 201 a 500, 4% de 501 a 1.000 e 5% acima de 1.001. Uma empresa com 1.500 empregados deve ter no mínimo 60 PCDs (4%). A multa por descumprimento vai de R$ 2.000 a R$ 200.000 por vaga não preenchida, mais TAC ou ACP do MPT. A LBI (Lei 13.146/2015) reforça a obrigação de adaptação razoável no posto de trabalho, e o Decreto 6.949/2009 (Convenção da ONU ratificada com status de Emenda Constitucional) reforça a não-discriminação.

O agente: (1) mantém o cadastro de cota vigente por filial; (2) marca as vagas reservadas; (3) aceita a autodeclaração PCD com Laudo Médico e CID conforme o Decreto 5.296/2004 e a LBI art. 2 (deficiência física, mental, intelectual, sensorial, auditiva, visual, ostomizado, nanismo e espectro autista, conforme a Lei 12.764/2012); (4) avalia adaptações no posto conforme a LBI art. 34; (5) reporta indicadores ao MTE no RAIS e via fiscalização.

## Dados sensíveis sob a LGPD art. 11, com DPIA registrada na ANPD

A LGPD art. 11 protege dados sensíveis (raça, etnia, religião, opinião política, saúde e biométricos) com base legal restritiva: consentimento específico OU obrigação legal (art. 11 §2). O agente coleta a autodeclaração étnico-racial (Decreto 8.136/2013 e Lei 12.288/2010) e a autodeclaração PCD (Decreto 5.296/2004 e LBI) com base no cumprimento de obrigação legal (políticas afirmativas e cota PCD), somado ao consentimento informado. O RIPD (DPIA da Resolução ANPD 4/2023) registra finalidade, base legal, prazos e medidas de segurança. Pelo princípio do menor privilégio, o recrutador vê o perfil objetivo anonimizado na primeira fase, e o dashboard de equidade é agregado, sem identificação individual. Em caso de vazamento, a comunicação à ANPD ocorre em 72 horas via e-Petição (Resolução ANPD 2/2022). A multa da LGPD chega a 2% do faturamento brasileiro, limitada a R$ 50 milhões por infração.

## Igualdade salarial e Relatório de Transparência semestral, sob a Lei 14.611/2023

A Lei 14.611/2023 obriga empresas com 100 ou mais empregados a publicar Relatório de Transparência Salarial semestral, fiscalizado pelo MTE, com discrepâncias por gênero e raça. A multa chega a 3% da folha, limitada a 100 salários mínimos. Na triagem, o agente NÃO usa a pretensão salarial como critério eliminatório (estudo da USP de 2024 mostra que mulheres declaram pretensão 17% menor na mesma função, um critério que funciona como proxy de gênero, vedado pela Lei 9.029/1995). A faixa salarial proposta é calculada com base em CBO, função, experiência e localidade, sem variação por gênero ou raça (igualdade salarial da CLT art. 461). A discrepância sistemática gera alerta ao Compliance antes da admissão.

## Integração com ecossistema brasileiro: Gupy, Kenoby, TOTVS, Senior, SAP, eSocial S-2200

A lógica do agente conecta-se aos principais sistemas ATS e HCM brasileiros via API: [Gupy ATS](https://www.gupy.io/) (líder do mercado, 2.000+ clientes incluindo Itaú, Magalu, Vivo, Heineken) e Kenoby ATS são as plataformas mais comuns para captação inicial - o agente consome dados estruturados via webhooks ou API REST. Após a aprovação, integra com o HCM: [TOTVS RM e Datasul HCM](https://www.totvs.com/) (líder em médias e grandes, 50.000+ clientes), Senior HCM (forte em indústria), SAP SuccessFactors Brasil (multinacionais), Workday HCM Brasil, Oracle HCM Cloud, ADP Brasil, Apdata, Solides (PMEs e médias) e Mastermaq HCM (escritórios contábeis). Entre os job boards integrados estão Vagas.com, InfoJobs Brasil, Catho.com, Indeed Brasil e LinkedIn Talent Solutions Brasil. Sincroniza o eSocial S-2200 (cadastramento inicial do vínculo) em até 1 dia antes da admissão (multa de R$ 800 a R$ 2.500 por evento atrasado) via certificado digital A1/A3 ICP-Brasil. Para multinacional com matriz na UE sob a CSRD, gera os KPIs do ESRS S1 Workers (diversidade, PCD e equilíbrio entre vida e trabalho) sem dados individuais identificáveis, mantendo os dados-fonte no Brasil sob LGPD.

## Infraestrutura de governança como investimento

O Candidate Screening Agent é frequentemente o primeiro agente de alto risco que uma empresa coloca em produção. Com isso, força a construção de infraestrutura que nenhum agente sozinho justificaria: RIPD (DPIA Resolução ANPD 4/2023) registrado, fairness monitoring contínuo, decision logging com hash de integridade, decomposição R/A/H, anonimização para primeira fase, cota PCD automatizada, sincronização eSocial S-2200. Toda essa infraestrutura é reutilizada por Performance Review Agent, Merit Cycle Governance Agent, Promotion Process Agent e Executive Recruiting Agent.

Triagem não é caso de uso isolado. É o alicerce sobre o qual toda a governança brasileira de alto risco em HR se constrói - documentada, auditável e defensável perante MPT, ANPD, MTE, TST, MIPP e Sindicato, antes que o prazo regulatório do PL 2338/2023 chegue.

--- Agente Certificações ---
> Acompanhamento de certificações: CLT art. 157 deveres empregador, NR-10 Eletricidade, NR-35 Trabalho em Altura e eSocial S-2245 - rastreamento com escalonamento 90/60/30/14 dias.

O acompanhamento de certificações no Brasil cruza seis regimes legais críticos ao mesmo tempo: os deveres de saúde e segurança da CLT (art. 157, 158, 168 e 200, incluindo os exames médicos do PCMSO), as Normas Regulamentadoras consolidadas pela Lei 6.514/1977 (entre elas a NR-10 de eletricidade, a NR-12 de máquinas, a NR-33 de espaços confinados e a NR-35 de trabalho em altura), o eSocial S-2245 (treinamentos e capacitações), a LGPD (Encarregado pelo art. 41 e dados sensíveis de saúde pelo art. 11), a legislação de PLD/FT (Lei 9.613/1998 e Resolução COAF 60/2024) e o Programa de Integridade (Lei 12.846/2013 e Decreto 11.129/2022). Cada regime tem seu fiscalizador: o MTE para as NRs e a CLT, o INSS para o NTEP em ação regressiva, a ANVISA para BPF/GMP (RDC 222/2018), a ANAC para o RBAC de mecânicos e despachantes, o COAF para PLD/FT, a CGU para o PAR e a ANPD para os dados sensíveis. A empresa precisa estar pronta para todos.

## Uma capacitação esquecida custa interdição da planta, NTEP do INSS e responsabilização criminal sob a CLT art. 157, a NR-10 e a NR-35

A CLT art. 157 atribui ao empregador o dever de cumprir e fazer cumprir as Normas Regulamentadoras, instruir empregados sobre precauções e adotar medidas para reduzir riscos. CLT art. 168 obriga exames médicos admissional, periódico, retorno ao trabalho, mudança de função e demissional via PCMSO (NR-7). CLT art. 200 delega à regulamentação por NRs. Súmula TST 51 e 277 consolidaram responsabilidade objetiva do empregador por acidente do trabalho - se a atividade era de risco e a capacitação não estava vigente, o ônus da prova de não-culpa é praticamente impossível.

A pegadinha mais comum: tratar capacitação como pontual em vez de cíclica. NR-10 reciclagem bienal, NR-35 reciclagem bienal, NR-33 reciclagem anual, ASO PCMSO conforme grau de risco GR-1 a GR-4 (anual ou semestral), ABNT NBR ISO 45001 sistema de gestão de SST. eSocial S-2245 tornou auditável: cada treinamento NR exige envio com instrutor habilitado CREA/CRM/SRT, carga horária mínima legal e conteúdo programático conforme anexo da NR. Atraso eSocial: R$ 800-2.500 por evento. Multa por NR descumprida: ampla faixa por gravidade conforme tabela MTE. A interdição da ANVISA por ausência de Pessoa Qualificada certificada (RDC 222/2018) para a planta até a regularização. Um acidente em atividade sem NR vigente acumula responsabilidade civil objetiva (CC art. 927), responsabilidade criminal (CP art. 132 por perigo à vida e art. 121 §3-4 por homicídio culposo), NTEP do INSS deslocando o ônus em ação regressiva e FAP majorado em até 100%, o que dobra a alíquota RAT da empresa por dois anos. Cumulativamente, a exposição plurianual chega a dezenas de milhões.

## O acompanhamento de certificações brasileiro percorre 14 etapas determinísticas em seis regimes legais

O acompanhamento é multi-regime por design. As 14 etapas cobrem a atribuição da matriz de capacitações por cargo e NR (1), o registro com evidência e a validação de autenticidade (2 e 3), o mapeamento contra a exigência regulatória (4), o cálculo da janela de renovação (5), os alertas escalonados ao colaborador, ao gestor e ao SESMT (6), a identificação de lacunas agregadas (7), o bloqueio de função em caso de NR vencida (8), o registro no eSocial S-2245 (9), a validação de PLD/FT do COAF (10) e do Programa de Integridade (11), a validação do ASO do PCMSO (12), a proteção dos dados sensíveis de saúde sob a LGPD art. 41 (13) e o pacote de evidências para auditoria (14).

Cenário concreto: indústria farmacêutica com 800 colaboradores CLT em três estados (SP, MG, BA), folha mensal R$ 5,2 milhões, BPF/GMP regulada pela ANVISA RDC 222/2018, com Pessoa Qualificada (PQ) farmacêutica em cada planta, eletricistas SEP sob NR-10, manutenção em altura sob NR-35, espaços confinados em tanques de processo sob NR-33, máquinas e equipamentos sob NR-12. O volume mensal é de 3.200 a 4.800 certificações individuais (em média 4 a 6 por colaborador), somadas aos ASOs do PCMSO conforme a NR-7, à capacitação periódica de PLD/FT do COAF para a área financeira e ao Programa de Integridade para as áreas comerciais. O pacote reúne TOTVS Treinamentos, TOTVS RM Folha e Datasul HCM, os eventos de SST do eSocial, a Conexa Saúde para o PCMSO e o RIPD na ANPD para os dados sensíveis de saúde. No total, são 14 etapas determinísticas por certificação, cerca de 8.000 a 12.000 micro-decisões por mês entre alertas, validações e bloqueios.

No [Decision Layer](/br/decision-layer/), cada etapa é classificada como decisão baseada em regras (R), análise sobre dados estruturados (A) ou decisão humana (H). A atribuição da matriz por NR é R (catálogo parametrizado por cargo, CBO, CNAE e grau de risco). O registro de evidência é R (campos obrigatórios do eSocial S-2245). Validação de autenticidade é A (verificação contra entidade emissora). Mapeamento contra exigência é R. Cálculo de janela é R. Alerta escalonado é R. Identificação de lacunas é A (estatística agregada). Bloqueio de função em NR vencida é R (integração API com sistema de escala). Registro S-2245 é R. Validações AML e Programa de Integridade são R. Validação ASO PCMSO é R. Anonimização LGPD art. 11 é R. Compilação de pacote é A. Decisões humanas (suspensão cautelar, equivalência por SESMT, designação de responsável técnico) são H com fundamentação legal.

## As NRs como obrigação determinística, sob a CLT art. 157 e a Lei 6.514/1977

A CLT art. 157 e a Lei 6.514/1977 consolidam as NRs com força de lei. A NR-1 é o guarda-chuva, com o PGR, o Inventário de Riscos e o Plano de Ação. A NR-4 dimensiona o SESMT conforme o grau de risco. A NR-5 organiza a CIPA com treinamento bienal. A NR-6 exige certificado de aprovação do EPI, treinamento e ficha de entrega. A NR-7 traz o PCMSO, com ASOs por grau de risco.

As NRs operacionais críticas com capacitação obrigatória incluem a NR-10 (eletricidade, com 40h básicas de SEP, 40h complementares e reciclagem bienal), a NR-12 (máquinas), a NR-13 (vasos de pressão), a NR-18 (construção, 6h), a NR-20 (inflamáveis, de 8h a 32h por classe), a NR-23 (incêndios), a NR-32 (saúde), a NR-33 (espaços confinados, com 16h para o trabalhador, 40h para o supervisor e reciclagem anual), a NR-35 (altura, 8h teóricas mais prática e reciclagem bienal), a NR-36 (frigoríficos) e a NR-37 (plataformas).

O agente atribui a matriz determinística e BLOQUEIA a escalação automática para função sem NR vigente. A CLT art. 157, com a NR-1 item 1.4.1, atribui responsabilidade objetiva ao empregador. Manter colaborador sem certificação em função de risco é fato gerador de NTEP do INSS, FAP majorado, multa do MTE pela NR específica e responsabilização criminal em caso de acidente.

## O eSocial torna auditável o que era planilha Excel

O Manual eSocial 2024 obriga o envio de três eventos. O S-2245 cobre treinamentos, capacitações e exercícios simulados, com o código do treinamento da tabela 29, a carga horária, o instrutor e o responsável técnico, as datas de início e término e o conteúdo programático. O S-2220 monitora a saúde do trabalhador, com o ASO do PCMSO conforme a NR-7. O S-2240 registra as condições ambientais do trabalho, com os agentes nocivos para enquadramento de aposentadoria especial. O S-2210 (CAT) é obrigatório em até 24h após o acidente. Atraso ou omissão custam de R$ 800 a R$ 2.500 por evento, e erro nos dados exige retificadora. A falha sistemática leva ao bloqueio da CND, ao impedimento de licitações e à fiscalização cruzada da Auditoria-Fiscal do MTE.

O agente integra com TOTVS Treinamentos, Senior, SAP SuccessFactors Learning Brasil, Workday Learning, Apdata ou Solides via API ou webhook, valida o schema do XSD do eSocial, envia via Synchro, Glik ou eSocial-Connector com certificado digital A1/A3 ICP-Brasil, captura o recibo do governo e armazena o hash de integridade.

## Dados sensíveis de saúde com Encarregado designado, sob a LGPD art. 41 e art. 11

A LGPD art. 41 obriga a designação e a divulgação do Encarregado (DPO). A LGPD art. 11 protege dados sensíveis (raça, etnia, religião, opinião política, saúde, genéticos e biométricos) com base legal restritiva: consentimento específico OU obrigação legal (art. 11 §2 II, como a do PCMSO na CLT art. 168). ASOs do PCMSO, CAT e CIDs são dados sensíveis máximos. O agente: (1) os trata com base no cumprimento de obrigação legal (CLT art. 168, NR-7 e PNSST do Decreto 7.602/2011); (2) limita o acesso pelo princípio do menor privilégio, em que apenas o médico do trabalho com CRM ativo e o SESMT têm acesso integral, e o gestor direto vê apenas APTO, INAPTO ou RESTRIÇÃO genérica; (3) registra RIPD (DPIA da Resolução ANPD 4/2023) específico para os dados de saúde, com finalidade, base legal, prazos e medidas de segurança; (4) mantém o dashboard agregado por função, CNAE e grau de risco, sem identificação individual; (5) não expõe o CID ao gestor direto. Em caso de vazamento, a comunicação à ANPD ocorre em até 72h via e-Petição (Resolução ANPD 2/2022). A multa da LGPD chega a 2% do faturamento brasileiro, limitada a R$ 50 milhões por infração, somada ao dano moral coletivo na Justiça do Trabalho.

## Integração com ecossistema brasileiro: TOTVS, Senior, SAP, eSocial-Connector, Conexa Saúde

A lógica do agente conecta-se aos principais sistemas LMS e de SST brasileiros via API: [TOTVS Treinamentos](https://www.totvs.com/) (líder em médias e grandes, 50.000+ clientes, integrado ao TOTVS RM Folha e ao Datasul HCM), Senior Sistemas (forte em indústria), SAP SuccessFactors Brasil Learning (multinacionais e listadas IBOVESPA), Workday Learning Brasil, Oracle Learning Cloud, ADP Brasil, Apdata Capacitação e Solides Capacitação (PMEs e médias). Para SST especializada, integra com Conexa Saúde, Lobo Saúde Ocupacional e Onsafety, com PCMSO, PGR e ASOs. Para segurança da informação (ISO 27001) e LGPD, conecta-se a KnowBe4 Brasil, Hacktrust e Convisoap. O envio ao eSocial passa pelos gateways Synchro, Glik ou eSocial-Connector. Para multinacional com matriz na UE sob a CSRD, gera os KPIs do ESRS S1-13 Training (horas por colaborador, cobertura e reciclagem) e S1-14 Health and Safety (taxa de acidentes, dias perdidos e capacitação preventiva) sem dados individuais identificáveis, mantendo os dados-fonte no Brasil sob LGPD.

## Infraestrutura de governança como investimento

O agente de acompanhamento de certificações costuma ser o primeiro agente operacional de SST que uma empresa coloca em produção. Com isso, força a construção de uma infraestrutura que nenhum agente sozinho justificaria: a matriz de capacitações por NR, cargo e CBO, a integração com os eventos de SST do eSocial, o registro de decisões com hash de integridade, a decomposição em regra, análise e julgamento humano, o bloqueio automático de função por inadimplência, a anonimização dos dados de saúde sob a LGPD art. 11 e a capacitação periódica de PLD/FT e do Programa de Integridade. Toda essa infraestrutura é reutilizada pelos agentes de Treinamento de Compliance, de Documentos de Política, de Onboarding de Compliance e de Risco de Força de Trabalho.

Acompanhamento de certificações não é caso de uso isolado. É o alicerce sobre o qual toda a governança brasileira de SST e compliance se constrói - documentada, auditável e defensável perante MTE, INSS, ANVISA, ANAC, COAF, CGU, ANPD, FUNDACENTRO e SESMT, antes que a próxima fiscalização chegue.

--- Agente Benchmarking Remuneração ---
> Pay-Equity benchmark: CLT art. 461 igualdade salarial, Lei 14.611/2023 reportagem MTE semestral e CSRD ESRS S1-10 Equal-Pay - estratégia de remuneração em vez de planilhas Excel.

O benchmarking de remuneração no Brasil cruza cinco regimes legais críticos ao mesmo tempo: a igualdade salarial da CLT art. 461 (mesma função, mesmo empregador e mesmo estabelecimento, com diferença máxima de 4 anos de serviço e 2 anos na função após a Reforma de 2017) e as Súmulas TST 6, 120, 127, 277 e 442; o Relatório de Transparência Salarial semestral da Lei 14.611/2023, obrigatório para empresas com 100 ou mais funcionários e publicado nos sites e redes sociais corporativas; a proibição de diferença de salário por sexo, idade, cor ou estado civil (CF/88 art. 7 inc. XXX) e a Lei 9.029/1995 contra a discriminação; o tratamento dos dados de remuneração como sensíveis pela LGPD art. 11, com Encarregado (art. 41) e DPIA (Resolução ANPD 4/2023); e o disclosure de remuneração de administradores nas empresas listadas, exigido pela CVM Resolução 80/2022 Item 13 e pela Lei 6.404/76 art. 152 e 162. Cada regime tem seu fiscalizador: o MTE para a Lei 14.611/2023 e a CLT art. 461, o MPT para as ações civis públicas por discriminação coletiva, o TST e os TRTs para as reclamatórias individuais de equiparação, a CVM para o disclosure de administradores, a ANPD para os dados sensíveis e a B3 para a governança corporativa. A empresa precisa estar pronta para todos.

## Uma planilha Excel anual de remuneração custa multa do MTE, ação civil pública e dano moral coletivo sob a CLT art. 461, a Lei 14.611/2023 e a LGPD

A Lei 14.611/2023 inverteu o ônus da prova na discriminação salarial. Não é mais o colaborador que precisa provar a discriminação: é o empregador que precisa provar que ela não existe, com Relatório de Transparência Salarial semestral publicado nos sites institucionais e nas redes sociais corporativas, com remuneração média e mediana por gênero, cor, cargo e estabelecimento, cruzando dados do eSocial. Empresas com 100 ou mais funcionários estão obrigadas. A multa pelo descumprimento da publicação é de 3% da folha, limitada a 100 salários mínimos. Quando o relatório identifica diferença salarial injustificada entre grupos comparáveis, a empresa apresenta plano de ação ao MTE com prazos e métricas de mitigação.

A pegadinha mais comum é tratar o relatório como tarefa anual, e não como processo contínuo. A CLT art. 461 §1 exige equiparação para mesma função, mesmo empregador e mesmo estabelecimento, com diferença máxima de 4 anos de serviço e 2 anos na função após a Reforma de 2017. A reclamatória no TRT por equiparação traz diferenças retroativas de cinco anos, com reflexos em férias, 13º, FGTS, INSS, IRRF e honorários. A LGPD art. 11 trata a remuneração combinada com cor, orientação política ou filiação sindical como dado sensível, o que exige RIPD/DPIA, pseudonimização e k-anonymity. Para as listadas na B3, a CVM Resolução 80/2022 Item 13 e a Lei 6.404/76 art. 152 e 162 obrigam o disclosure de administradores, sob sanção da CVM de até R$ 50 milhões e impedimento de exercer cargo. Cumulativamente, a exposição plurianual chega a dezenas de milhões.

## O benchmarking de remuneração brasileiro percorre 15 etapas determinísticas em cinco regimes legais

O benchmarking é multi-regime por design. As 15 etapas cobrem a extração e classificação de dados internos por cargo, CBO e estabelecimento (1), a pseudonimização sob a LGPD art. 11 com k-anonymity (2), o mapeamento entre cargo e benchmark de mercado das pesquisas Mercer, WTW, Korn Ferry e Catho (3 e 4), o cálculo determinístico de compa-ratio, range penetration e percentil (5), a identificação de diferença injustificada por gênero, cor e idade (6), a validação de adicionais legais e da PLR da Lei 10.101/2000 (7 e 8), o disclosure da CVM Resolução 80/2022 Item 13 (9), o Relatório da Lei 14.611/2023 e o plano de ação (10 e 11), a identificação de outliers e de risco de turnover (12), os eventos do eSocial (13 e 14) e o pacote de evidências (15).

Cenário concreto: empresa industrial de capital aberto listada na B3 (segmento Nível 1), com 1.500 colaboradores CLT em quatro estados, folha mensal de R$ 9,8 milhões, sob a Lei 14.611/2023, a CVM Resolução 80/2022 Item 13 e um acordo coletivo de PLR da Lei 10.101/2000, com matriz alemã sob a CSRD (ESRS S1-10 e S1-16). O volume trimestral é de 800 a 1.500 posições para benchmark contra as pesquisas Mercer Brasil TRS, WTW, Korn Ferry Hay, Aon McLagan, Radford e Catho. O pacote reúne TOTVS RM Folha, Datasul HCM, Workday Advanced Compensation para o LTIP, os eventos do eSocial e o RIPD na ANPD. No total, são cerca de 4.000 a 7.500 micro-decisões por trimestre entre validações, cálculos e mapeamentos.

No [Decision Layer](/br/decision-layer/), cada etapa é classificada como decisão baseada em regras (R), análise sobre dados estruturados (A) ou decisão humana (H). A maioria é R, como a extração, a pseudonimização, o cálculo, a validação de adicionais e da PLR, o piso coletivo, o disclosure da CVM e os eventos do eSocial. As análises agregadas (A) cobrem o mapeamento entre cargo e benchmark, a identificação de diferença injustificada e a detecção de outliers. As decisões humanas (H) ficam reservadas para a validação de mapeamento crítico (executivos e estatutários da CVM), o plano de ação da Lei 14.611/2023 e o ajuste de faixa por equiparação da CLT art. 461, sempre com fundamentação legal documentada.

## A equiparação salarial como obrigação determinística, sob a CLT art. 461 e as Súmulas TST 6 e 442

A CLT art. 461 (após a Lei 13.467/2017) exige, para a equiparação, mesma função, mesmo empregador e mesmo estabelecimento empresarial, com igual produtividade e igual perfeição técnica, diferença máxima de 4 anos de serviço para o mesmo empregador e diferença máxima de 2 anos na função (§1). O §2 trata do quadro de carreira ou plano de cargos e salários organizado por antiguidade e merecimento. O §6 prevê a quitação anual no contexto da Reforma Trabalhista. A Súmula TST 6 detalha os critérios, e a Súmula TST 442 trata da faixa salarial em cláusula coletiva.

O agente atribui cada colaborador a um grupo comparável conforme função, estabelecimento, tempo de serviço e tempo na função, e calcula compa-ratio, range penetration e percentil. Identifica casos com diferença salarial relevante e analisa os fatores objetivos justificadores (antiguidade, desempenho, grade, nível Hay e dimensão de responsabilidade). Sinaliza para revisão humana os casos com diferença residual sem fator objetivo, e Compensação e Benefícios, com o Comitê de Remuneração, validam ou aprovam o ajuste. A reclamatória no TRT por equiparação traz diferenças retroativas de cinco anos, com reflexos em férias, 13º, FGTS, INSS, IRRF e honorários sucumbenciais.

## Relatório semestral com dados sensíveis pseudonimizados, sob a Lei 14.611/2023 e a LGPD art. 11

A Lei 14.611/2023 obriga o Relatório de Transparência Salarial semestral para empresas com 100 ou mais funcionários, publicado em sites institucionais e redes sociais corporativas, com remuneração média e mediana por gênero, cor, cargo e estabelecimento, cruzando dados do eSocial. A multa pela falta de publicação é de 3% da folha, limitada a 100 salários mínimos. O MPT pode ajuizar ação civil pública por discriminação coletiva, com dano moral coletivo sem teto.

A LGPD art. 11 trata a remuneração combinada com cor ou etnia (CF art. 7 XXX) ou com filiação sindical como dado sensível, exatamente o cruzamento que a Lei 14.611/2023 exige. A base legal é o cumprimento de obrigação legal (art. 11 §2 II). O agente registra RIPD/DPIA específico (Resolução ANPD 4/2023), pseudonimiza com chave reversível controlada pelo DPO (art. 41), aplica k-anonymity (supressão quando o grupo comparável tem menos de 5 pessoas), limita o acesso pelo princípio do menor privilégio (Compensação e Benefícios, DPO e Compliance veem o detalhe, enquanto os gestores veem apenas a distribuição agregada) e mantém trilha de auditoria de cada acesso. Em caso de vazamento, a comunicação à ANPD ocorre em até 72h via e-Petição (Resolução ANPD 2/2022). A multa da LGPD chega a 2% do faturamento brasileiro, limitada a R$ 50 milhões, somada ao dano moral coletivo na Justiça do Trabalho.

## CVM Resolução 80/2022 Item 13: disclosure de remuneração de administradores em empresas listadas B3

A CVM Resolução 80/2022 substituiu a ICVM 480/2009 e o Anexo 24, com o Item 13 do Formulário de Referência como instrumento de disclosure de remuneração de administradores nas empresas listadas na B3 (Novo Mercado, Nível 2 ou Nível 1). A base legal está na Lei 6.404/76 art. 152 (remuneração fixada pela assembleia), art. 162 (limite global ou individual) e art. 157 (deveres de informação). O Item 13 exige o disclosure, por órgão (Conselho de Administração, Diretoria Estatutária e Conselho Fiscal), do número de membros, da remuneração fixa e variável (bônus, PLR, LTIP, ações e opções), dos benefícios pós-emprego e de cessação, das maiores, médias, medianas e menores remunerações e dos critérios. O agente extrai os dados estatutários, as atas de assembleia e os planos de LTIP do Workday, do SAP ou do Oracle HCM, consolida por órgão, valida o limite global, gera o Item 13 conforme o template da CVM Resolução 80/2022 e o Ofício-Circular CVM/SEP 1/2024 e o submete à validação do Comitê de Remuneração, do DRI e do Jurídico Societário. A sanção da CVM chega a R$ 50 milhões e ao impedimento de exercer cargo por até 20 anos. O IBGC Caderno 33 alinha os princípios.

## Integração com ecossistema brasileiro: TOTVS, Senior, SAP, Mercer, WTW, Korn Ferry, eSocial-Connector

A lógica do agente conecta-se aos principais sistemas HCM e provedores de pesquisa via API: [TOTVS RM Folha e Datasul HCM](https://www.totvs.com/) (líder em médias e grandes), Senior Sistemas HCM, SAP SuccessFactors Brasil Compensation (multinacionais e IBOVESPA), Workday Advanced Compensation, Oracle HCM Cloud Brasil, ADP Brasil, Apdata e Solides. Para o benchmarking de mercado, usa as pesquisas Mercer Brasil TRS, WTW Pesquisa Geral, Korn Ferry Hay, Aon McLagan (executivos), Radford (tecnologia) e Catho Salary Survey. O envio ao eSocial passa pelos gateways Synchro, Glik ou eSocial-Connector. Para multinacional com matriz na UE sob a CSRD, gera os KPIs do ESRS S1-10 (percentual de colaboradores acima do mínimo) e S1-16 (gap salarial de gênero não ajustado, razão entre o CEO e o mediano e remuneração total) com pseudonimização e k-anonymity, mantendo os dados-fonte no Brasil sob LGPD.

## Infraestrutura de governança como investimento

O agente de benchmarking de remuneração costuma ser o primeiro agente de Compensação e Benefícios em produção sob a Lei 14.611/2023. Com isso, força a construção de uma infraestrutura reutilizável: a estrutura de cargos por CBO, grade e nível Hay, o mapeamento entre cargo e benchmark, a decisão em regra, análise e julgamento humano com registro próprio, a pseudonimização sob a LGPD art. 11 com k-anonymity, a integração com o eSocial, a validação de adicionais legais e da PLR, o disclosure da CVM, o plano de ação da Lei 14.611/2023 e o alinhamento ao ESRS S1-10 e S1-16. Toda essa base é reutilizada pelos agentes de Governança do Ciclo de Mérito, de Processo de Promoção, de Revisão Salarial, de Cálculo de Bônus e de Total Rewards.

Benchmarking de remuneração não é caso de uso isolado. É o alicerce sobre o qual toda a governança brasileira de equidade salarial e disclosure se constrói - documentada, auditável e defensável perante MTE, MPT, TST/TRT, CVM, B3, ANPD, Receita Federal, IBGC e Sindicatos, antes que a próxima fiscalização chegue.

--- Agente Monitoramento HR-Compliance ---
> Monitoramento HR-Compliance em tempo real: Equal-Pay-Index contínuo Lei 14.611/2023, plataforma de denúncia Lei 13.964/2019 Anti-Corrupção, supervisão cadeia de suprimentos HR - alertas auditáveis ISO 37301.

O monitoramento de compliance no Brasil cruza cinco regimes legais críticos ao mesmo tempo: a Lei Anticorrupção (Lei 12.846/2013, com a responsabilização objetiva da pessoa jurídica) e o Programa de Integridade do Decreto 11.129/2022, cujos 16 parâmetros servem de fator atenuante na sanção; a LGPD, com o RAT (art. 30), o Encarregado (art. 38), as atribuições (art. 41) e as Resoluções CD/ANPD 2/2022, 4/2023 e 18/2024; a legislação de PLD/FT (Lei 9.613/1998 e Resolução COAF 60/2024), com a comunicação de operações suspeitas ao SISCOAF em 24h; a Lei 14.457/2022, que alterou a CLT criando o canal de denúncia e o treinamento de prevenção ao assédio; e a igualdade salarial e a proibição de discriminação (CLT art. 461, Lei 9.029/1995 e Lei 14.611/2023). Cada regime tem seu fiscalizador: a CGU para a Lei 12.846/2013 e o Programa de Integridade, a ANPD para a LGPD, o COAF para PLD/FT, o MTE para as Leis 14.611/2023 e 14.457/2022, o MPT para as ações civis públicas por discriminação ou assédio coletivo, a CVM para o disclosure nas listadas, a B3 para a governança corporativa e a ABNT para as certificações ISO 37001 e 37301. A empresa precisa estar pronta para todos.

## A verificação manual reativa custa acordo de leniência, multa da CGU e dano reputacional sob a Lei 12.846/2013 e o Decreto 11.129/2022

A Lei 12.846/2013 introduziu a responsabilização objetiva da pessoa jurídica, em que a empresa responde independentemente de culpa de dirigentes, por atos lesivos contra a administração pública nacional ou estrangeira. A sanção é uma multa de 0,1% a 20% do faturamento bruto, somada a bloqueio no CADIN, impedimento de licitações e dissolução compulsória, e a ação judicial pode levar a perdimento de bens e suspensão de atividades. O Decreto 11.129/2022 detalhou os 16 parâmetros do Programa de Integridade que a CGU avalia como fator atenuante (até 4% de redução) ou agravante. O acordo de leniência (art. 16) reduz a multa em até 2/3 quando a empresa colabora, mas o Programa de Integridade efetivo é pré-condição.

A pegadinha mais comum é tratar o Programa de Integridade como documento estático. O Decreto 11.129/2022 exige monitoramento contínuo (parâmetro 14), análise periódica de riscos (parâmetro 4) e controles internos (parâmetro 6). Sem evidência de monitoramento operacional, a CGU classifica o programa como cosmetic compliance e nega o fator atenuante. A Resolução CD/ANPD 18/2024 prevê multa de até 2% do faturamento brasileiro, limitada a R$ 50 milhões, além de bloqueio e suspensão. A Lei 9.613/1998 obriga a comunicação ao COAF em 24h, e o atraso gera multa de até R$ 20 milhões. A Lei 14.457/2022 obriga o canal de denúncia para empresas com CIPA, e a omissão gera ação do MPT por dano moral coletivo sem teto. Cumulativamente, a exposição plurianual chega a centenas de milhões.

## O monitoramento contínuo de compliance brasileiro percorre 14 etapas determinísticas em cinco regimes legais

O monitoramento é multi-regime por design. As 14 etapas cobrem a catalogação de políticas, leis e normas em uma base versionada (1), a matriz de risco ABNT NBR ISO 31000 (2), a conexão de fontes com pseudonimização sob a LGPD (3), a verificação determinística contra o catálogo (4), a IA assistida para detecção de padrões anômalos (5), a classificação por severidade (6), o canal de denúncia da Lei 14.457/2022 com o IBGC Caderno 33 (7), a comunicação ao COAF via SISCOAF (8), o RAT da LGPD art. 30 (9), o rastreamento de remediação (10), a validação de treinamentos no eSocial S-2245 (11), o bias audit sob a LGPD art. 20 (12) e o pacote de evidências (13 e 14).

Cenário concreto: empresa industrial de capital aberto listada na B3 (Nível 1), com 1.500 colaboradores CLT em quatro estados, folha mensal de R$ 9,8 milhões e CIPA em todas as filiais, sob a Lei 12.846/2013, o Decreto 11.129/2022, a Lei 14.611/2023, a Lei 14.457/2022 e a LGPD com Encarregado, além do disclosure da CVM (Resolução 80/2022 Item 5.4) e da matriz alemã sob a CSRD (ESRS S1-17, G1 e CSDDD). O volume diário é de 12.000 a 25.000 transações verificadas, 800 a 1.500 acessos a sistemas com dados sensíveis e de 5 a 30 denúncias por mês. O pacote reúne TOTVS GRC, ServiceNow GRC, NAVEX EthicsPoint, OneTrust para LGPD, KnowBe4, os eventos do eSocial e as certificações ABNT NBR ISO 37001, 37301 e 27001.

No [Decision Layer](/br/decision-layer/), cada etapa é classificada como decisão baseada em regras (R), análise sobre dados estruturados (A) ou decisão humana (H). A maioria é R, como a catalogação, a verificação, a classificação, a comunicação ao COAF, o RAT, os treinamentos e os eventos do eSocial. As análises (A) cobrem a detecção de padrões anômalos, o rastreamento de remediação e a compilação de evidências. As decisões humanas (H) ficam reservadas para o escopo monitorado, o apetite de risco, a investigação de denúncia, o bias audit e o plano de remediação, sempre com fundamentação documentada e revisão pelo Comitê de Auditoria Estatutário.

## O Programa de Integridade como obrigação determinística, com os 16 parâmetros do Decreto 11.129/2022

O Decreto 11.129/2022 art. 5 lista os 16 parâmetros do Programa de Integridade, e a CGU avalia conforme a IN 13/2019 e o Manual de Implementação 2024. O agente cobre diretamente os parâmetros 4 (matriz de risco ABNT NBR ISO 31000), 6 (controles internos automatizados), 7 (verificação determinística), 8 (due diligence de terceiros), 10 (integração do canal de denúncia), 11 (suporte a investigações com pacote de evidências), 13 (rastreamento de remediação) e 14 (monitoramento contínuo). Os parâmetros 1 (alta direção), 2 (código de ética), 3 (treinamentos), 5 (registros contábeis), 12 (medidas disciplinares), 15 (transparência em doações) e 16 (aplicabilidade) são responsabilidade humana, com suporte do agente.

A diferença entre o Programa formal e o efetivo é a evidência de monitoramento operacional. Sem uma trilha de auditoria de verificações, escalações e remediações, a CGU classifica o programa como cosmetic compliance e nega o fator atenuante. O agente gera uma trilha de auditoria completa, em que cada verificação tem timestamp, regra aplicada, resultado, escalação, responsável e nova verificação. O acordo de leniência (Lei 12.846 art. 16) reduz a multa em até 2/3, e o Programa efetivo é pré-condição.

## RAT, Encarregado e sanções, sob a LGPD art. 30, 38 e 41 e a Resolução CD/ANPD 18/2024

A LGPD art. 38 obriga a designação de Encarregado (DPO), sigla mantida pela ANPD, com canal específico e as atribuições do art. 41. O agente mantém o RAT (Relatório de Atividades de Tratamento) atualizado conforme os arts. 30 e 37 e a Resolução CD/ANPD 4/2023, com finalidade, bases legais, categorias de titulares e de dados, prazos de retenção, transferências e medidas de segurança. Registra RIPD/DPIA específico para o monitoramento sistemático e para os dados sensíveis do art. 11 (raça ou etnia, saúde, filiação sindical e denúncia confidencial). Mantém Plano de Resposta a Incidentes (art. 48), com notificação à ANPD em até 72h sob a Resolução 2/2022.

A Resolução CD/ANPD 18/2024 detalhou as sanções: advertência, multa simples de até 2% do faturamento brasileiro limitada a R$ 50 milhões, publicação da infração, bloqueio e eliminação de dados e suspensão. O vazamento adicional gera dano moral coletivo na Justiça do Trabalho. A proteção combina pseudonimização com chave controlada pelo DPO, k-anonymity (supressão se o grupo tem menos de 5 pessoas), princípio do menor privilégio e trilha de auditoria de cada acesso. O bias audit anual, sob a LGPD art. 20 e a ABNT NBR ISO 37301, examina a taxa de detecção por gênero, cor, idade e estabelecimento, e a diferença sistemática gera recalibração e atualização do RIPD.

## Integração com ecossistema brasileiro: TOTVS GRC, ServiceNow, NAVEX, OneTrust, KnowBe4, eSocial-Connector

A lógica conecta-se aos principais sistemas GRC e canais de denúncia via API: [TOTVS GRC](https://www.totvs.com/) e Senior Compliance (líderes em médias e grandes empresas brasileiras), ServiceNow GRC Brasil, SAP GRC Brasil (Risk, Process Control, Access Control e Audit), Workday Audit Reports e Oracle Risk Management Brasil. Para o canal de denúncia, integra com NAVEX EthicsPoint, Convercent (premium em pt-BR), Compliance Online e Mitratech. Para a LGPD, usa o OneTrust Brasil (RIPD/DPIA, RAT e Data Mapping). Para os treinamentos, conecta-se a KnowBe4 Brasil, Solides e TOTVS Educação. O envio ao eSocial passa pelos gateways Synchro, Glik ou eSocial-Connector, com certificado A1/A3 ICP-Brasil.

Para multinacional com matriz na UE sob a CSRD, gera os KPIs do ESRS S1-17 (incidentes de discriminação e assédio e respectiva remediação), do G1 (anticorrupção, suborno, lobbying e conformidade de fornecedores) e da CSDDD (due diligence na cadeia de valor) com pseudonimização e k-anonymity, mantendo os dados-fonte no Brasil sob LGPD. As certificações ABNT NBR ISO 37001, 37301, 27001 e 31000 fortalecem a defesa em acordo de leniência e o reconhecimento do Programa de Integridade efetivo pela CGU.

## A responsabilidade permanece onde deve estar, sob o PL 2338/2023, a LGPD art. 20 e o acordo com o sindicato

O agente detecta os desvios, classifica-os, escala-os, documenta-os e valida que a correção funciona. O que ele não faz é decidir sobre a relação de trabalho ou uma sanção disciplinar. Se uma violação de jornada leva a advertência, suspensão ou dispensa, se um erro de folha é corrigido retroativamente ou se um incidente é comunicado às autoridades, isso é decisão humana. A responsabilidade pela causa de um desvio está com o gestor ou a área responsável, não com o colaborador individual. O PL 2338/2023 (marco regulatório de IA) classifica o monitoramento de processos como risco baixo ou médio quando não decide sobre pessoas, e a arquitetura do agente respeita exatamente essa fronteira.

A LGPD art. 20 dá o direito de revisão de decisão automatizada. O acordo com o sindicato (Lei 13.467/2017 art. 511 e CLT art. 510-A, sobre a Comissão de Representantes dos Empregados) sobre o escopo do monitoramento automatizado é exigência prática: sem ele, a empresa fica exposta a reclamatória por violação à dignidade da pessoa do trabalhador (CF/88 art. 5 inc. X) e a ação civil pública do MPT por monitoramento abusivo. O acordo define os indicadores monitorados, as finalidades, os acessos e os canais de comunicação. É fundamental distinguir o monitoramento de processos (jornada, folha, acesso a sistemas e treinamento) da vigilância de colaboradores (comportamento individual e comunicação privada).

## Infraestrutura de governança como investimento

O agente de monitoramento de compliance costuma ser o primeiro agente em produção sob a Lei 12.846/2013 e o Decreto 11.129/2022. Com isso, força a construção de uma infraestrutura reutilizável: o catálogo de regras versionadas, a matriz de risco ABNT NBR ISO 31000, a decisão em regra, análise e julgamento humano com registro e hash de integridade, a pseudonimização sob a LGPD art. 11 com k-anonymity, a integração completa com o eSocial, o canal de denúncia da Lei 14.457/2022 com o IBGC Caderno 33, a comunicação ao COAF da Lei 9.613/1998, o RAT da LGPD com o RIPD/DPIA, o bias audit anual e o alinhamento às normas ABNT NBR ISO 37001 e 37301. Toda essa base é reutilizada pelos agentes de Triagem de Candidatos, de Avaliação de Desempenho, de People Analytics, de Benchmarking de Remuneração, de Processo de Promoção e de Investigação de Denúncias.

Monitoramento de compliance não é caso de uso isolado. É o alicerce sobre o qual toda a governança brasileira de RH se constrói - documentada, auditável e defensável perante CGU, ANPD, COAF, MTE, MPT, TST/TRT, CVM, B3, IBGC, ABNT e Sindicatos, antes que a próxima fiscalização chegue.

--- Agente Treinamentos Compliance HR ---
> Treinamentos obrigatórios HR: Decreto 11.129/2022 parâmetro 3 Programa de Integridade, NRs SST (NR-1 a NR-35), LGPD art. 38 capacitação DPO e Lei 14.457/2022 anti-assédio - rastreamento eSocial S-2245 completo.

Os treinamentos obrigatórios brasileiros cruzam, ao mesmo tempo, cinco regimes legais com órgãos fiscalizadores diferentes. O parâmetro 3 do Programa de Integridade (Decreto 11.129/2022) é avaliado pela CGU. As NRs de SST, baseadas no art. 157 da CLT, têm cargas horárias próprias e responsável técnico habilitado, fiscalizadas pelo MTE. A LGPD exige a capacitação do Encarregado/DPO, sob a ANPD. A Lei 9.613/1998 e a Resolução COAF 60/2024 obrigam a capacitação AML no setor regulado. E a Lei 14.457/2022 exige o treinamento anti-assédio nas empresas com CIPA. Cada colaborador é um nó de uma matriz de cargo, estabelecimento e atividade que gera dezenas de obrigações por ano - cada uma documentada, com prazo, responsável técnico e transmissão ao eSocial.

## Uma planilha reativa de treinamentos custa o atenuante da CGU, multa do MTE e dano reputacional

A pressão regulatória cresce mais rápido do que a administração consegue acompanhar. O Decreto 11.129/2022 estabelece os 16 parâmetros do Programa de Integridade que a CGU avalia. O parâmetro 3 (treinamentos periódicos) é um dos pilares e cobre alta administração, funcionários e parceiros comerciais. Sem evidência operacional, a CGU classifica o programa como meramente formal e nega o fator atenuante de até 4% na multa da Lei 12.846/2013 - que vai de 0,1% a 20% do faturamento bruto. O acordo de leniência depende de um programa efetivo.

## Os treinamentos obrigatórios percorrem etapas determinísticas em cinco regimes legais

O monitoramento é multi-regime por design. As etapas vão da catalogação por marco regulatório, cargo e estabelecimento até a identificação dos requisitos de cada colaborador pela matriz determinística, a verificação de status e validade contra o LMS e o eSocial, a atribuição com carga horária e responsável técnico, os lembretes escalonados e o rastreamento da conclusão com o envio do S-2245. Seguem a detecção de inconsistências por análise estatística, a escalação por severidade, a reavaliação por gatilhos de ciclo de vida, a validação da capacitação do DPO, a avaliação de eficácia, o pacote de evidências e a trilha de auditoria.

Cenário concreto: uma indústria de capital aberto listada na B3, com 1.500 colaboradores CLT em quatro estados, CIPA em todas as filiais, Encarregado/DPO designado e matriz alemã sob a CSRD. O catálogo individual fica entre 8 e 14 treinamentos por colaborador, somando de 12.000 a 21.000 obrigações por ano, incluídas as reciclagens. O ecossistema integra LMS de treinamento corporativo, plataformas de compliance e a transmissão ao eSocial com certificado A1/A3 ICP-Brasil, apoiada pelas certificações ABNT NBR ISO 37001, 37301, 27001 e 45001.

No [Decision Layer](/br/decision-layer/), cada etapa é classificada como decisão por regra (R), análise sobre dados estruturados (A) ou decisão humana (H). A maioria é regra: catalogação, verificação de status, lembretes, rastreamento, escalação e trilha de auditoria. As análises cobrem a atribuição automatizada com alocação inteligente, a detecção de inconsistências de aproveitamento e a avaliação de eficácia. As decisões humanas ficam reservadas à catalogação inicial do escopo, sempre com fundamentação documentada e revisão pelo Comitê de Auditoria, pelo DPO e pela SST.

## Programa de Integridade: o parâmetro 3 como obrigação determinística

O art. 5º do Decreto 11.129/2022 lista os 16 parâmetros do Programa de Integridade. O parâmetro 3 cobre os treinamentos periódicos para alta administração, funcionários e parceiros comerciais, e a CGU o avalia como fator atenuante de até 4% na multa. O agente cataloga os treinamentos por audiência - governança e antissuborno para a alta administração; Código de Ética, LGPD, AML e assédio para os funcionários; due diligence para os parceiros - com cronograma de reciclagem por tipo. A atribuição determinística, os lembretes, o rastreamento e a avaliação de eficácia se somam à retenção mínima de dez anos pela prescrição da Lei 12.846. O acordo de leniência depende de evidência operacional: a trilha de auditoria completa é o que separa um programa formal de um programa efetivo.

## NRs de SST e eSocial: integração por gateway certificado A1/A3 ICP-Brasil

O art. 157 da CLT, a Lei 6.514/77 e a Portaria 3.214/78 consolidam o regime das NRs, cada uma com carga horária, responsável técnico, periodicidade e público-alvo definidos. O agente cobre as principais NRs com a matriz de cargo, estabelecimento e atividade. A atribuição inclui o tipo, a carga horária, o responsável técnico habilitado e o formato - presencial obrigatório para as NRs com prática, EAD permitido para as teóricas pela Portaria MTP 671/2021. A conclusão dispara a transmissão do S-2245 ao eSocial em até 15 dias, e o atraso gera multa de R$ 800 a R$ 2.500 por evento. Nas NRs de risco grave, o atraso acima de 60 dias leva ao afastamento da área de risco até a regularização (arts. 157 e 158 da CLT).

## Integração com o ecossistema brasileiro

A lógica conecta-se via API aos principais LMS usados no Brasil. Em treinamento corporativo, líderes como [TOTVS Educação Corporativa](https://www.totvs.com/) e Senior dominam o segmento de médias e grandes empresas, ao lado de SAP SuccessFactors Learning, Workday Learning e Oracle Learning Cloud. Para compliance, integra-se a plataformas como KnowBe4, NAVEX e OneTrust, que cobrem LGPD, AML, antissuborno e assédio. Para SST, conecta-se a sistemas como Conexa Saúde e Onsafety, com transmissão ao eSocial. E o microlearning vem de plataformas como LinkedIn Learning e Alura.

Para multinacionais com matriz na UE sob a CSRD, gera os KPIs do ESRS S1-13 (Training and Skills Development) com pseudonimização e k-anonymity, mantendo os dados-fonte no Brasil sob a LGPD. As certificações ABNT NBR ISO 37001, 37301, 27001 e 45001 fortalecem a defesa em acordo de leniência e a comprovação de um Programa de Integridade efetivo.

## A responsabilidade onde ela deve estar

O agente atribui, lembra, escala, rastreia e transmite ao eSocial. O que ele não faz: decidir sobre a relação de trabalho ou a competência individual. Se uma reprovação reincidente leva a advertência ou dispensa, se um afastamento de área de risco precisa ser comunicado ao sindicato, se uma denúncia de discriminação salarial precisa ser investigada - isso é decisão humana. A responsabilidade pela causa de uma não conformidade é do gestor, do RH ou da SST, não do colaborador.

O PL 2338/2023 classifica a administração da logística de treinamento como risco baixo quando ela não decide sobre pessoas - e a arquitetura do agente respeita exatamente essa fronteira. A LGPD art. 20 dá direito de revisão da decisão automatizada. A auditoria de viés anual examina a cobertura e o aproveitamento por gênero, cor, idade e estabelecimento; havendo diferença sistemática, o modelo é recalibrado e o RIPD atualizado. O acordo com o sindicato sobre o escopo do monitoramento automatizado é exigência prática, e a Lei 13.146/2015 obriga formatos alternativos de capacitação para PCD.

## Infraestrutura de governança como investimento

O Compliance Training Agent costuma ser o primeiro agente em produção sob o Decreto 11.129, as NRs e a LGPD. Com isso, força a construção de infraestrutura reutilizável: a matriz de competências por cargo, estabelecimento e atividade, a integração com o eSocial por gateway certificado, o registro de decisões com hash SHA-256, a pseudonimização e a auditoria de viés anual. Toda essa base é reaproveitada por outros agentes, como os de Certification Tracking, Training Needs Analysis e Onboarding. Para multinacionais com matriz na UE, alimenta os KPIs do ESRS S1-13 sem identificação individual, mantendo a fonte no Brasil sob a LGPD.

Treinamento obrigatório não é um caso de uso isolado. É o alicerce sobre o qual a governança brasileira de RH se constrói - documentada, auditável e defensável perante CGU, MTE, ANPD, COAF, MPT e Conselhos Profissionais, antes que a próxima fiscalização chegue.

--- Agente Contratos e Ofertas ---
> Geração de contratos CLT: CLT art. 442 e 446-456 cláusulas obrigatórias, Reforma Trabalhista Lei 13.467/2017 e Lei 14.611/2023 - regrado com ICP-Brasil em vez de Word.

Um contrato de trabalho brasileiro não é um documento - é uma cadeia de quinze decisões: a modalidade contratual, o modelo versionado por CBO, CNAE, UF e Convenção Coletiva, as cláusulas obrigatórias da CLT, a validação da igualdade salarial e da cota PCD, os dados sensíveis sob a LGPD, as cláusulas anti-assédio, a revisão jurídica, a aprovação do RH, a assinatura por ICP-Brasil e a transmissão ao eSocial. A maioria das empresas o trata como um documento Word: abre um modelo de 2019, preenche os campos, salva em PDF e envia por e-mail. E depois se pergunta por que o candidato esperou três semanas, por que faltaram cláusulas obrigatórias e por que a Auditoria-Fiscal identificou contratos fraudados.

## Uma planilha Word de 2019 custa reclamação trabalhista, multa do MTE e dano reputacional

A pressão regulatória sobre contratos cresce mais rápido do que a administração consegue acompanhar. A Reforma Trabalhista (Lei 13.467/2017) ampliou as modalidades - trabalho intermitente, teletrabalho, parcial e autônomo exclusivo -, cada uma com requisitos próprios. O erro de classificação gera reclamação por desvirtuamento, e a Súmula TST 463 inverte o ônus da prova, com prescrição de cinco anos. A empresa que contrata um PJ disfarçado de CLT (RE 590.415 do STF) responde solidariamente por todas as verbas trabalhistas, mais INSS e FGTS retroativos.

A Lei 14.611/2023 obriga empresas com mais de 100 funcionários à igualdade salarial, com Relatório de Transparência Salarial semestral e canal de denúncias, sob multa de 3% da folha e ação do MPT por dano moral coletivo. O art. 93 da Lei 8.213 fixa a cota PCD de 2% a 5%, com multa por vaga não preenchida. A Lei 9.029/1995 proíbe a discriminação na admissão, com inversão do ônus da prova. E o tratamento de dados sensíveis sob a LGPD corre risco de multa da ANPD limitada a R$ 50 milhões.

## Onde exatamente o processo brasileiro quebra

Este agente segue o princípio do [Decision Layer](/br/decision-layer/): cada decisão é regra (R), análise (A) ou humana (H), nunca IA generativa em decisão sobre relação de trabalho.

Os erros não surgem aleatoriamente. Surgem em cinco pontos previsíveis no contexto brasileiro.

**Proliferação de modelos após a Reforma.** Uma empresa com três filiais e contratos em várias modalidades precisaria de uns 30 modelos. Na prática, existem 80 - cada filial fez as suas adaptações e as versões anteriores a 2017 nunca foram apagadas. Qual deles está em conformidade com a Lei 13.467, a Lei 14.611 e a Lei 14.457, ninguém sabe.

**Transferência manual de parâmetros.** Remuneração, jornada, local, benefícios e data de início são transcritos à mão. Um dígito trocado, uma data errada, um período de experiência incorreto - descobertos quando o candidato lê o contrato, ou só durante a reclamação trabalhista.

**Cláusulas obrigatórias ausentes.** A cláusula anti-assédio da Lei 14.457 vale para empresas com CIPA, as do teletrabalho para uma modalidade, as de igualdade salarial e acessibilidade para outras. Quais se aplicam a cada caso está só na cabeça de quem elabora. Quando essa pessoa está de férias, as cláusulas faltam.

**Sem validação da igualdade salarial.** A oferta diz R$ 18.000. Outras pessoas no mesmo cargo recebem de R$ 14.000 a R$ 16.000, com diferença sistemática por gênero e cor. A Auditoria-Fiscal descobre pelo Relatório de Transparência Salarial - multa de 3% da folha e ação do MPT.

**Sem validação da cota PCD.** Uma empresa com 250 funcionários precisaria de 7 a 8 PCDs (3%). Tem 4. Contrata mais 10 sem nenhum PCD. Multa do MTE de R$ 2.000 a R$ 200.000 por vaga não preenchida.

## Quinze etapas, três princípios de decisão, modalidades pós-Reforma

```
Modalidade        Modelo+CCT       Dados+Validação   Cláusulas obrigatórias
determinar  -->   selecionar -->   preencher    -->  CLT art. 446-456 + L.14.457
(R: Regras)       (R: Regras)      (A: Análise)      (R: Checklist Reforma)

Igualdade Sal.    Cota PCD         LGPD art. 11      Consistência interna
Lei 14.611  -->   Lei 8.213   -->  dados sensíveis-> + anti-assédio
(A: Análise)      (R: Cálculo)     (R: Validação)    (R: Validação)

Jurídico          IA contextual    Revisão Juríd.    Aprovação RH +
escalar     -->   recomendar  -->  humana       --> ICP-Brasil
(R: Regras)       (A: Sugestão)    (H: Humano)       (H: Humano)

eSocial S-2200    Audit trail
transmitir  -->   + bias audit
(R: Gateway)      (R: Hash SHA-256)
```

De quinze etapas, treze são determinísticas ou de análise. A modalidade resulta da natureza do trabalho, da carga horária, da duração e do perfil. O modelo vem da matriz de modalidade, CBO, CNAE, UF e CCT, consultada no Sistema Mediador do MTE. As cláusulas obrigatórias saem de um checklist da CLT, da Reforma 13.467 e das leis de igualdade, anti-assédio e proteção de dados. A validação da igualdade salarial compara a faixa por gênero, cor e raça, e a cota PCD calcula o percentual atual e a elegibilidade. A transmissão do S-2200 ao eSocial passa por gateway com certificado A1/A3 ICP-Brasil.

Apenas uma etapa usa IA: a recomendação de cláusulas opcionais, como não-concorrência, auxílio-mudança ou bônus de contratação. A IA apenas recomenda - a decisão é do Jurídico ou do RH.

Duas etapas ficam com o humano: a revisão jurídica e a aprovação do RH. A revisão jurídica é indelegável, pois o art. 444 da CLT deixa às partes a regulação do contrato e a Súmula TST 463 inverte o ônus da prova. A aprovação do RH responde pela proposta contratual e também não se delega.

## O contrato em três horas reduz a desistência do candidato

A maioria das discussões sobre geração de contratos termina no PDF. Mas o momento crítico está depois: o intervalo entre a aprovação verbal e o contrato assinado decide se o candidato começa ou desiste. Em um mercado competitivo, onde profissionais de tecnologia, dados e finanças têm três ofertas ao mesmo tempo, três semanas de espera significam perder o candidato.

A integração com plataformas de assinatura como o [ClickSign](https://www.clicksign.com/), via ICP-Brasil A1/A3 e Lei 14.063/2020, transforma três semanas em três horas. O fluxo é simples: a empresa assina primeiro, o candidato depois, com acompanhamento, lembretes e força probatória. Após a assinatura, o S-2200 é transmitido automaticamente ao eSocial por gateway certificado. O atraso do S-2200 custa de R$ 800 a R$ 2.500 por evento.

## O Jurídico como gargalo - e como escudo

A regra de escalação para o Jurídico é deliberadamente restrita: cláusulas especiais (não-concorrência longa, bônus de contratação, realocação internacional), remuneração acima de um teto, jurisdição ou modalidade nova, setor regulado e contratação de estrangeiro (Lei 13.445/2017). Todo o restante passa pela validação automatizada.

Em uma empresa com 200 admissões CLT por ano, o Jurídico hoje revisa todo contrato superficialmente - porque ninguém tem certeza se o modelo está conforme a Reforma 13.467 e as leis de igualdade e anti-assédio. Com a gestão de modelos por regras, a verificação automática e a CCT integrada pela Súmula TST 277, a participação do Jurídico se concentra nos casos em que ela agrega valor.

## Integração com o ecossistema brasileiro

A lógica conecta-se via API aos principais sistemas usados no Brasil. Em HCM, líderes como [TOTVS](https://www.totvs.com/) e Senior cobrem grande parte do mercado, ao lado de SAP SuccessFactors, Workday e Oracle nas grandes empresas e de Apdata e Sólides nas de porte médio. Em recrutamento, integra-se a ATS como Gupy e Kenoby. Para a assinatura eletrônica, conecta-se a plataformas como ClickSign, D4Sign e Autentique, todas via ICP-Brasil A1/A3. E a transmissão ao eSocial passa por gateways como Synchro, Glik e eSocial-Connector, com certificado A1/A3.

Para multinacionais com matriz na UE sob a CSRD, gera os KPIs do ESRS S1 com pseudonimização e k-anonymity, mantendo a fonte no Brasil sob a LGPD. As certificações ABNT NBR ISO 37301, 37001, 27001 e 27701 reforçam a defesa em fiscalização, ação do MPT e recurso ao TST.

## A responsabilidade onde ela deve estar

O agente gera contratos, valida as cláusulas obrigatórias, recomenda opcionais, integra a assinatura ICP-Brasil e transmite ao eSocial. O que ele não faz: decidir sobre a relação de trabalho. Se o Jurídico aprova a minuta, se o RH negocia o bônus, se o sindicato deve ser informado - isso é decisão humana.

O PL 2338/2023 classifica a geração de documentos como risco baixo. A LGPD art. 20 dá direito de revisão - o candidato pode contestar a classificação de modalidade ou uma recomendação. A auditoria de viés anual examina as recomendações por gênero, cor, raça, idade, PCD e cargo; havendo diferença sistemática, o modelo é recalibrado e o RIPD atualizado.

O acordo com o sindicato é exigência prática. A Lei 13.146 obriga adaptações razoáveis e formatos alternativos do contrato, como libras, audiodescrição e braile. A Lei 14.457 obriga as empresas com CIPA a manter cláusula anti-assédio, canal de denúncia e proteção ao denunciante - cuja omissão gera ação do MPT por dano moral coletivo.

## Infraestrutura de governança como investimento

O motor de modelos versionados é reaproveitado por outros agentes, como os de HR Document Management (atestados, declarações, aditivos), Onboarding e Legal Contract Review. A biblioteca de cláusulas, com o checklist da CLT e da Reforma 13.467, é a base para a auditoria de contratos. E a validação da igualdade salarial usa o mesmo motor dos agentes de Merit Cycle e Compensation Benchmarking.

A integração com as plataformas de assinatura via ICP-Brasil A1/A3 é reutilizada por todos os agentes que precisam de assinatura formal. A transmissão ao eSocial por gateway certificado alimenta toda a infraestrutura de eventos do ciclo de vida. O registro de decisões e a trilha de auditoria com hash SHA-256, retidos por cinco anos após a rescisão (art. 11 da CLT), servem como prova em fiscalização, ação do MPT e recurso ao TST.

Para a empresa que contrata regularmente no Brasil, isso garante que cada contrato seja juridicamente seguro após a Reforma, conforme as leis de igualdade, cota PCD, anti-assédio e proteção de dados, assinado por ICP-Brasil e transmitido ao eSocial - defensável perante MTE, MPT, TST, ANPD, sindicatos e Conselhos, antes que a próxima reclamação trabalhista chegue.

--- Agente Gestão Dados Cadastrais ---
> Plataforma de dados de empregados: LGPD art. 6 princípios, art. 18 Direito ao Esquecimento e art. 41 Encarregado DPO - Master-Data com escopo de retenção e DPIA ANPD Resolução 4/2023.

Um colaborador se muda e informa o novo endereço. Três semanas depois, o holerite chega ao endereço antigo. O ponto eletrônico ainda mostra a localidade anterior. O sistema de acesso nunca recebeu a alteração. Não porque alguém cometeu um erro - mas porque sete pessoas diferentes precisam inserir a mesma informação em sete sistemas diferentes, e uma delas estava de férias. Isso não é falha: é arquitetura - e ela viola diretamente o princípio da qualidade dos dados pessoais (art. 6, V, da LGPD), que a ANPD fiscaliza com sanção limitada a R$ 50 milhões por infração.

## Uma planilha cadastral fragmentada custa DPO ausente, RAT desatualizado e fiscalização da ANPD

A pressão regulatória sobre dados cadastrais cresce mais rápido do que a administração consegue acompanhar. O art. 6 da LGPD estabelece os princípios - qualidade dos dados, transparência, não discriminação e prestação de contas. O art. 11 trata os dados sensíveis (origem racial, saúde, biometria, filiação sindical) sob hipóteses específicas. E o art. 18 garante o Direito ao Esquecimento, com 15 dias para a resposta.

O art. 30 obriga o RAT, atualizado anualmente e disponível à ANPD na fiscalização. Os arts. 38 e 41 obrigam o Encarregado/DPO, com identidade e contato divulgados. A Resolução ANPD 4/2023 exige RIPD/DPIA no tratamento de alto risco - dados sensíveis em larga escala, decisões automatizadas, monitoramento sistemático. Um sistema central com mais de 5.000 colaboradores caracteriza tratamento em larga escala, com RIPD obrigatório, sob sanção limitada a R$ 50 milhões por infração.

A Constituição protege a intimidade, o sigilo e o habeas data (art. 5º). O Marco Civil e a Lei 14.155/2021 exigem logs por seis meses e criptografia. A Lei 14.611/2023 obriga as empresas com mais de 100 funcionários à igualdade salarial, com dados sensíveis. A Lei 14.457/2022 obriga as empresas com CIPA a manter canal de denúncia, o art. 93 da Lei 8.213 fixa a cota PCD, e a Lei 9.029/1995 proíbe a discriminação na admissão.

## Onde exatamente o processo brasileiro quebra

Este agente segue o princípio do [Decision Layer](/br/decision-layer/): cada decisão é regra (R), análise (A) ou humana (H), nunca IA generativa em decisão sobre relação de trabalho.

Os erros não surgem aleatoriamente. Surgem em cinco pontos previsíveis no contexto brasileiro.

**Fragmentação em sete sistemas.** Uma empresa com 1.000 colaboradores tem os dados cadastrais espalhados entre folha, benefícios, ponto, acesso biométrico, plano de saúde e previdência. Cada sistema tem as suas regras. Quando o endereço muda, leva três semanas até a sincronização - se ela se completa.

**Ausência de DPO, RAT e RIPD.** A LGPD obriga o DPO (arts. 38 e 41), o RAT anual (art. 30) e o RIPD para o tratamento em larga escala (Resolução ANPD 4/2023). Uma empresa com mais de 1.000 colaboradores e dados sensíveis sem nenhum dos três está em descumprimento direto, sob sanção limitada a R$ 50 milhões.

**Erros de digitação em cascata.** A digitação manual responde por boa parte dos erros de folha. Um dígito trocado no CPF ou na conta bancária, uma data errada de admissão - descobertos quando o salário cai na conta errada ou na reclamação por desvirtuamento, em que a Súmula TST 463 inverte o ônus da prova.

**Sem Direito ao Esquecimento estruturado.** Um ex-colaborador pede a eliminação após cinco anos da rescisão (art. 11 da CLT). O RH não sabe verificar as obrigações legais de retenção - FGTS, INSS, IRRF. Resposta tardia ou sem fundamentação vira sanção da ANPD.

**Sem auditoria de viés nem cooperação com a ANPD.** A detecção de fraude pode ser sistematicamente maior para colaboradores de certa origem ou cor (LGPD art. 20). Sem auditoria de viés anual e RIPD, o modelo replica o viés. E, na fiscalização da ANPD, a falta de RAT, RIPD e segurança documentados vira sanção.

## Quatorze etapas, três princípios de decisão, plataforma única auditável

```
Receber+classificar  Validar+formato  Detectar duplicidades   Matriz aprovação
LGPD art. 6 + 11 -->  CPF+CNPJ+CEP -->  intersistemas      --> sensibilidade
(R: Mapeamento)       (R: Algoritmo)    (R: Correspondência)   (R: Roteamento)

Detectar fraude       Aprovar/Direito  Aplicar+RAT art. 30   Propagar+eSocial
padrão+análise   -->  Esquecimento --> + criptografia    --> S-2206+retry
(A: Análise)          (H: Humano)      (A: Automático)        (A: Automático)

Confirmar+escalar     Notificar       Igualdade+PCD          Audit trail
falha+reconciliar -> titular + DPO -> Lei 14.611+8.213  --> + RAT + RIPD
(R: Verificação)      (R: Workflow)   (A: Análise)            (R: SHA-256)

Cooperar ANPD
+ titular art. 18
(H: Humano)
```

De quatorze etapas, doze são determinísticas ou de análise. O recebimento e a classificação resultam do mapeamento de campo, tipo, sensibilidade e base legal. A validação de formato usa algoritmos públicos, como o dígito verificador do CPF, e APIs, como o CEP dos Correios e a CCT do Sistema Mediador. A detecção de duplicidades combina correspondência exata, similaridade e janela temporal. A matriz de aprovação roteia por sensibilidade, tipo e valor, com duplo controle do art. 462 da CLT para os dados financeiros. E a aplicação atualiza o RAT, com criptografia e log assinado.

Apenas uma etapa usa IA: a detecção de padrões incomuns, como três mudanças de estado civil em seis meses ou uma alteração de dados bancários em janela de pagamento. A IA apenas sinaliza - a decisão é do Compliance e do Encarregado/DPO.

Duas etapas ficam com o humano: a aprovação de alteração sensível, incluído o Direito ao Esquecimento, e a cooperação com a ANPD na fiscalização. A aprovação humana é indelegável - os dados bancários têm a engenharia social como vetor comum de fraude, os dados sensíveis exigem hipótese específica e o Direito ao Esquecimento exige a verificação das obrigações legais de retenção. A cooperação com a ANPD é decisão humana documentada, com fundamentação legal específica.

## Uma plataforma única reduz o risco perante a ANPD

A maioria das discussões sobre dados cadastrais termina no Excel. O momento crítico está antes: o intervalo entre a alteração e a sincronização decide se a ANPD encontra discrepâncias. Com a sanção limitada a R$ 50 milhões por infração, sete sistemas defasados em três semanas são exposição direta.

A integração com plataformas de privacidade e governança como o [OneTrust](https://www.onetrust.com/) - que oferece DPO como serviço, RAT automatizado, DPIA e Direito ao Esquecimento -, ao lado de BigID e Collibra, transforma sete sistemas defasados em uma plataforma única e auditável. O fluxo é direto: alteração validada, matriz de aprovação, RAT atualizado, log assinado e propagação automática, com o S-2206 transmitido ao eSocial por gateway. O atraso do S-2206 custa de R$ 800 a R$ 2.500 por evento.

## O Encarregado/DPO como gargalo - e como escudo

A regra de escalação ao DPO é restrita: dados sensíveis (saúde, biometria, filiação sindical), alterações em janela de pagamento, padrões incomuns, Direito ao Esquecimento, cooperação com a ANPD, transferência internacional e RIPD para novas operações. O restante passa pela validação automatizada. Em uma empresa com 1.000 colaboradores e 50 alterações por dia, com DPO como serviço e automação de RAT e RIPD, a participação do DPO se concentra nos casos em que ela agrega valor.

## Integração com o ecossistema brasileiro

A lógica conecta-se via API aos principais sistemas usados no Brasil. Em Master Data de HCM, líderes como [TOTVS](https://www.totvs.com/) e Senior cobrem grande parte do mercado, ao lado de SAP MDG, Workday e Oracle nas grandes empresas e de Apdata e Sólides nas de porte médio. Para privacidade e governança, integra-se a OneTrust (DPO como serviço, RAT, DPIA), BigID e Collibra. A transmissão ao eSocial passa por gateways como Synchro, Glik e eSocial-Connector, com certificado A1/A3 ICP-Brasil. Para multinacionais com matriz na UE sob a CSRD, gera os KPIs do ESRS S1 com pseudonimização e transferência internacional por cláusulas contratuais padrão. As certificações ABNT NBR ISO 27001, 27701 e 37301 reforçam a defesa na fiscalização da ANPD.

## A responsabilidade onde ela deve estar

O agente centraliza os dados, valida o formato, detecta padrões, roteia a aprovação, sincroniza os sistemas, atualiza o RAT e alimenta o canal LGPD. O que ele não faz: decidir sobre a relação de trabalho. Se o Encarregado/DPO aprova uma alteração sensível, se o Compliance determina a obrigação legal de retenção, se o sindicato deve ser informado - isso é decisão humana.

O PL 2338/2023 classifica a gestão de dados administrativos como risco baixo. A LGPD art. 20 dá direito de revisão - o colaborador pode contestar a classificação ou a aprovação. A auditoria de viés anual examina os padrões de detecção e de aprovação por gênero, cor, raça, idade, PCD e cargo; havendo diferença sistemática, o modelo é recalibrado e o RIPD atualizado.

O acordo com o sindicato é exigência prática - a filiação sindical é dado sensível (art. 11). A Lei 13.146 obriga adaptações razoáveis no portal do colaborador e formatos alternativos, como libras, audiodescrição e braile. A Lei 14.457 obriga as empresas com CIPA a manter canal de denúncia e proteção ao denunciante, cuja omissão gera ação do MPT por dano moral coletivo.

## Infraestrutura de governança como investimento

O motor de validação, a matriz de aprovação, o RAT, o RIPD, o canal LGPD do DPO e a trilha de auditoria com hash SHA-256 são reaproveitados por outros agentes, como os de folha, benefícios, onboarding e ciclo de remuneração. A transmissão ao eSocial por gateway certificado alimenta toda a infraestrutura de eventos do ciclo de vida. O registro de decisões com hash SHA-256, retido por cinco anos após a rescisão (art. 11 da CLT), serve como prova na fiscalização da ANPD, na auditoria-fiscal do MTE e na ação do MPT.

Para a empresa que trata dados de colaboradores no Brasil, isso garante que cada operação seja juridicamente segura sob a LGPD - com Direito ao Esquecimento, RAT, RIPD, DPO e transmissão ao eSocial -, defensável perante ANPD, MTE, MPT, TST, RFB, sindicatos e Conselhos, antes que a próxima fiscalização chegue.

--- Agente Casos Relações Trabalhistas ---
> Casos disciplinares e justa causa: CLT art. 482 onze hipóteses, art. 483 rescisão indireta e Lei 14.457/2022 anti-assédio - condução de casos auditável com confidencialidade Lei 14.611/2023.

Um caso disciplinar no Brasil pode acionar, ao mesmo tempo, vários regimes legais com consequências bem diferentes. A CLT estrutura o procedimento: o art. 482 lista as onze hipóteses de justa causa, e o art. 477 exige a homologação das verbas rescisórias - sem esses requisitos, a justa causa converte-se em dispensa imotivada, com multa de 40% do FGTS. A Lei 14.457/2022 obriga empresas com mais de 100 empregados a manter canal de denúncia e protocolo de combate ao assédio. A LGPD trata os dados disciplinares como sensíveis (art. 11), exigindo RIPD/DPIA. E a Lei 12.846/2013 pode responsabilizar a própria empresa. Na prática, um único caso, numa empresa listada na B3 ou de porte médio, pode ativar cinco obrigações de compliance de uma vez.

## As sanções se somam entre os órgãos e podem ameaçar a continuidade da empresa

O risco não vem de um único órgão, mas da soma deles. O MTE autua por infrações trabalhistas, com a multa dobrada em caso de reincidência. A ANPD pode aplicar sanção de até 2% do faturamento, limitada a R$ 50 milhões por infração, quando dados disciplinares sensíveis são tratados sem RIPD/DPIA. A CGU, sob a Lei 12.846/2013, pode chegar a 20% do faturamento e à suspensão das atividades. Quando a dispensa é revertida na Justiça do Trabalho - e a Súmula TST 401 inverte o ônus da prova em assédio e discriminação -, somam-se a multa de 40% do FGTS e a indenização adicional. A Lei 6.404/76 ainda prevê a responsabilidade civil dos administradores. Para uma empresa com falhas recorrentes, esse acúmulo pode ultrapassar R$ 50 milhões e ameaçar a continuidade do negócio.

## Etapas determinísticas, indicadores assistidos por modelo e confirmações humanas

O agente decompõe a gestão de casos em dezesseis microdecisões. A maioria é determinística; duas são indicadores assistidos por modelo (sem decisão final automatizada) e três exigem confirmação humana. Cada decisão documenta o passo, a pergunta, o tipo de decisor e a justificativa, com base legal, trilha de auditoria do sistema de origem e caminho de contestação. As decisões determinísticas cobrem a validação do fundamento jurídico e dos prazos de prescrição, a notificação à CIPA e ao sindicato, a proteção ao denunciante, a verificação de dados sensíveis sob a LGPD, a geração da carta de justa causa, o cálculo das verbas rescisórias e a sincronização com o eSocial. Os indicadores assistidos por modelo avaliam quando cabe um Plano de Desenvolvimento em vez da dispensa e a viabilidade de mediação. As confirmações humanas ficam com o enquadramento do caso, o protocolo de assédio e os casos de C-suite.

## Verificação contínua contra a jurisprudência trabalhista

O agente confere cada caso contra a jurisprudência consolidada - Súmulas do TST, Orientações Jurisprudenciais e decisões dos Tribunais Regionais. Alguns pontos são decisivos para a defesa. A audiência prévia do delegado sindical (art. 511 da CLT) é obrigatória para faltas graves. A Súmula TST 401 inverte o ônus da prova em assédio, discriminação e rescisão indireta, e a Lei 14.457/2022 faz o mesmo nos casos de represália ao denunciante. Os dados disciplinares sensíveis exigem RIPD/DPIA sob a LGPD. Por isso o agente mantém o expediente completo, com trilha de auditoria e retenção de cinco anos, pronto para a defesa na Justiça do Trabalho.

## Casos especiais: estabilidade, assédio coletivo e servidores públicos

Há situações que fogem ao fluxo padrão. Servidores públicos seguem o regime estatutário da Lei 8.112/90, com processo administrativo sancionador distinto do regime privado. O assédio coletivo aciona a comissão da CIPA e medidas cautelares, como a separação entre as partes ou a mudança de setor, sob a Lei 14.457/2022. A estabilidade da gestante (art. 10 do ADCT e Súmula TST 393) e a do membro da CIPA (art. 165 da CLT) protegem contra a dispensa. Uma dispensa nula, por discriminação ou violação de direitos fundamentais, obriga à reintegração, com salários do período. E a recuperação judicial (Lei 11.101/2005) tem regras próprias para a extinção de contratos.

## Integração com o ecossistema brasileiro

O agente conecta-se via API às principais plataformas usadas no Brasil. Em HCM, líderes como TOTVS e Senior cobrem a maior parte do mercado, ao lado de SAP SuccessFactors, Workday e Oracle nas grandes empresas e de Apdata e Sólides nas de porte médio. Para canal de denúncia e gestão de casos, integra-se a plataformas dedicadas como NAVEX, EQS e ServiceNow GRC. Para a proteção de dados, conecta-se ao OneTrust. E a transmissão ao eSocial - sobretudo os eventos S-2299 de desligamento e S-2298 de reintegração - passa por gateways como Synchro, Glik e eSocial-Connector, com retenção de cinco anos.

--- Agente Autoatendimento Empregado ---
> Portal de autoatendimento: LGPD art. 18 direitos do titular, ICP-Brasil assinatura avançada e Lei 14.611/2023 Pay Transparency - prazo de 30 dias em vez de fila de tickets.

Uma plataforma de autoatendimento no Brasil cruza, ao mesmo tempo, cinco regimes legais com consequências bem diferentes. A LGPD é o eixo: o art. 18 dá ao titular nove direitos exercíveis pelo portal - acesso, correção, eliminação, portabilidade -, com prazo de resposta razoável e consulta ao Encarregado/DPO; o art. 11 trata os dados sensíveis sob hipótese específica; e o art. 22 dá direito à revisão das decisões automatizadas. A CLT rege o que o portal expõe - jornada, férias, holerite, atestado médico, certificados. O Marco Civil garante a inviolabilidade da intimidade e o sigilo das comunicações. A assinatura ICP-Brasil (Lei 14.063/2020) varia conforme a transação, do simples ao qualificado. E a Lei 14.611/2023 obriga a transparência salarial, enquanto a LBI obriga a acessibilidade do portal. Na prática, qualquer plataforma de autoatendimento, em uma empresa listada na B3 ou de porte médio, pode ativar cinco obrigações de compliance de uma vez.

## As sanções se somam entre os órgãos e podem ameaçar a continuidade da empresa

O risco não vem de um único órgão, mas da soma deles. A ANPD pode aplicar sanção de até 2% do faturamento, limitada a R$ 50 milhões por infração, pela violação dos direitos do titular (art. 18), pelo tratamento de dados sensíveis sem RIPD/DPIA ou pela decisão automatizada sem direito à revisão. O MTE autua por infrações trabalhistas, com a multa dobrada em reincidência, e pela falha na transparência salarial e no canal de denúncia. A LBI prevê multa pela inacessibilidade do portal. A CGU, sob a Lei 12.846/2013, pode chegar a 20% do faturamento e à suspensão das atividades. Quando uma decisão é revertida na Justiça do Trabalho, a Súmula TST 401 inverte o ônus da prova, somando-se a multa de 40% do FGTS. A Lei 6.404/76 ainda prevê a responsabilidade civil dos administradores. Para uma empresa com falhas recorrentes, esse acúmulo pode ultrapassar R$ 50 milhões e ameaçar a continuidade do negócio.

## Etapas determinísticas, indicadores assistidos por modelo e confirmações humanas

O agente decompõe o autoatendimento em dezesseis microdecisões. A maioria é determinística; três são indicadores assistidos por modelo (sem decisão final automatizada) e duas exigem confirmação humana. Cada decisão documenta o passo, a pergunta, o tipo de decisor e a justificativa, com base legal, trilha de auditoria do sistema de origem e caminho de contestação. As decisões determinísticas cobrem a validação de identidade com assinatura ICP-Brasil, o exercício dos direitos do titular (art. 18), a recuperação da política e da Convenção Coletiva aplicáveis, a verificação de dados sensíveis (art. 11), o tratamento das respostas automatizadas (art. 22), a acessibilidade, a transação no ERP com sincronização ao eSocial, a transparência salarial e o registro da interação com retenção de cinco anos. Os indicadores assistidos por modelo classificam o tipo de solicitação, geram a resposta fundamentada e avaliam a confiança para escalar casos sensíveis. As confirmações humanas ficam com o canal de denúncia e os casos que exigem julgamento.

## Verificação contínua contra a regulação e a jurisprudência

O agente confere cada interação contra a regulação vigente - as Resoluções da ANPD, a lista de prestadores credenciados pelo ITI e as Súmulas do TST. Alguns pontos são determinantes. Os direitos do titular (art. 18) exigem resposta em prazo razoável e consulta ao Encarregado/DPO. A assinatura eletrônica via ICP-Brasil é obrigatória conforme o tipo de solicitação. A acessibilidade segue a WCAG 2.1 AA e a LBI. Os dados sensíveis, como o atestado médico, exigem RIPD/DPIA. As respostas automatizadas dão direito à revisão por pessoa natural (art. 22). A transparência salarial segue a Lei 14.611/2023, e o canal de denúncia, a Lei 14.457/2022, com investigação confidencial e proteção contra represália. Por isso o agente mantém o registro completo de cada interação, com trilha de auditoria e retenção de cinco anos, pronto para a defesa na Justiça do Trabalho.

## Casos especiais: teletrabalho, atestado digital e acessibilidade

Há situações que fogem ao fluxo padrão. O teletrabalho (arts. 75-A e 75-B da CLT) exige acordo assinado eletronicamente, com regras de retorno presencial e reembolso de despesas. O atestado médico digital e a receita eletrônica, sob a telemedicina, envolvem dados sensíveis (art. 11), com RIPD/DPIA e acesso hierarquizado. O portal precisa ser acessível para PCD, com leitor de tela, alto contraste, navegação por teclado e tradução em libras. As respostas automatizadas dão direito à revisão por pessoa natural (art. 22), e o agente escala ao RH quando a confiança é baixa ou o tema é sensível. A estabilidade da gestante (art. 10 do ADCT e Súmula TST 393) e o canal de denúncia da Lei 14.457/2022, com investigação confidencial, também exigem tratamento próprio.

## Integração com o ecossistema brasileiro

O agente conecta-se via API às principais plataformas usadas no Brasil. Em HCM e autoatendimento, líderes como TOTVS e Senior cobrem grande parte do mercado, ao lado de SAP SuccessFactors, Workday e Oracle nas grandes empresas e de Apdata e Sólides nas de porte médio. Para a experiência do colaborador e o canal de denúncia, integra-se a plataformas como ServiceNow, NAVEX e EQS. Para a proteção de dados e o atendimento aos direitos do titular, conecta-se ao OneTrust. A assinatura eletrônica via ICP-Brasil vem de plataformas como ClickSign, ZapSign e Autentique. E a transmissão ao eSocial passa por gateways como Synchro, Glik e eSocial-Connector, com trilha de auditoria e retenção de cinco anos.

--- Agente Provisão Equipamento ---
> Provisão de equipamento IT onboarding/offboarding: CLT art. 157, NR-6 EPI, NR-17 Ergonomia e LBI Lei 13.146/2015 - pipeline completa com Microsoft Intune MDM e Asset Tracking.

O provisionamento de equipamento de TI no Brasil cruza, ao mesmo tempo, vários regimes legais. A CLT obriga o empregador a cumprir as NRs e a fazer o exame médico admissional (arts. 157 e 168). A NR-6 trata o equipamento de uso prolongado como EPI, com Certificado de Aprovação do MTE obrigatório quando há risco de LER/DORT, e a NR-17 fixa a ergonomia do posto - mobiliário regulável, monitor na altura, apoios. A LGPD trata como sensíveis os dados de saúde e a biometria (art. 11), dá direito à revisão das decisões automatizadas do MDM, como o apagamento remoto (art. 22), e exige RIPD/DPIA. A assinatura ICP-Brasil (Lei 14.063/2020) garante os termos. A LBI obriga o equipamento adaptativo e respeita a cota PCD, e a Lei 13.467/2017 responsabiliza o empregador pelo equipamento no home office. Na prática, qualquer provisionamento, em uma empresa listada na B3 ou de porte médio, pode ativar várias obrigações de compliance de uma vez.

## As sanções se somam entre os órgãos e podem ameaçar a continuidade da empresa

O risco não vem de um único órgão, mas da soma deles. A ANPD pode aplicar sanção de até 2% do faturamento, limitada a R$ 50 milhões por infração, pelo monitoramento do MDM sem RIPD/DPIA, pela decisão automatizada sem direito à revisão ou pelo tratamento de dados sensíveis. O MTE autua por infrações às NRs - EPI e ergonomia -, com a multa dobrada em reincidência. O MPT pode mover ação civil pública por equipamento defeituoso. A LBI prevê multa pela inacessibilidade do equipamento. A CGU, sob a Lei 12.846/2013, pode chegar a 20% do faturamento e à suspensão das atividades. Em acidente com equipamento defeituoso, a Súmula TST 47 atribui responsabilidade objetiva ao empregador. E o descarte irregular gera multa do IBAMA. Para uma empresa com falhas recorrentes, esse acúmulo pode ultrapassar R$ 50 milhões e ameaçar a continuidade do negócio.

## Etapas determinísticas, indicadores assistidos por modelo e uma confirmação humana

O agente decompõe a provisão de equipamento em quatorze microdecisões. A maioria é determinística; duas são indicadores assistidos por modelo e uma exige confirmação humana. Cada decisão documenta o passo, a pergunta, o tipo de decisor e a justificativa, com base legal e trilha de auditoria. As decisões determinísticas cobrem a recepção do gatilho e a classificação do evento (admissão, alteração, substituição, teletrabalho, devolução), a definição do perfil com a ergonomia da NR-17 e a cota PCD, a validação da acessibilidade, a verificação de estoque, o EPI com Certificado de Aprovação, a provisão zero-touch por MDM, o tratamento do monitoramento sob a LGPD, o termo de entrega assinado por ICP-Brasil, a coordenação paralela entre as áreas, a sincronização com o eSocial e o rastreamento do ciclo de vida até o descarte. Os indicadores assistidos por modelo cuidam do pedido de compra e da due diligence do fornecedor. A confirmação humana fica com os casos que exigem julgamento.

## Verificação contínua contra a regulação e a jurisprudência

O agente confere cada provisão contra a regulação vigente - as NRs do MTE, as Resoluções da ANPD, a lista de prestadores credenciados pelo ITI e as Súmulas do TST. Alguns pontos são determinantes. O EPI da NR-6 exige Certificado de Aprovação do MTE e treinamento de uso (art. 158 da CLT). A ergonomia da NR-17 vale também no home office, onde o empregador responde pelo equipamento, e a Súmula TST 47 atribui responsabilidade objetiva por equipamento defeituoso. A acessibilidade segue a LBI e a tecnologia assistiva. O monitoramento do MDM dá direito à revisão sob a LGPD (art. 22), com RIPD/DPIA e respeito à intimidade. A provisão zero-touch segue a ABNT NBR ISO 27001, e o descarte, a logística reversa da Lei 12.305/2010. Por isso o agente mantém o registro do ciclo de vida, com trilha de auditoria e retenção de cinco anos, pronto para a defesa na Justiça do Trabalho e em ação do MPT.

## Casos especiais: teletrabalho, equipamento adaptativo e monitoramento

Há situações que fogem ao fluxo padrão. No teletrabalho (arts. 75-A e 75-B da CLT e Lei 14.442/2022), o empregador responde pelo equipamento ergonômico e pelo reembolso de despesas, com acordo escrito, e a verificação da ergonomia em casa exige visita da SST ou foto do posto de trabalho. O equipamento adaptativo de PCD, sob a LBI, vai do leitor de tela ao teclado em braile e ao tradutor de libras. Um EPI sem Certificado de Aprovação do MTE faz o agente bloquear a provisão e escalar à SST. O monitoramento do MDM - telemetria, localização, apagamento remoto - esbarra na LGPD e na proteção da intimidade, e vai ao Jurídico quando invade a vida pessoal. Em acidente com equipamento defeituoso, a Súmula TST 47 atribui responsabilidade objetiva ao empregador. E o descarte ao fim do ciclo de vida segue a logística reversa da Lei 12.305/2010.

## Integração com o ecossistema brasileiro

O agente conecta-se via API às principais plataformas usadas no Brasil. Em HCM e onboarding, líderes como TOTVS e Senior cobrem grande parte do mercado, ao lado de SAP SuccessFactors, Workday e Oracle nas grandes empresas e de Apdata e Sólides nas de porte médio. Para a provisão zero-touch e a gestão de dispositivos, integra-se aos principais MDM, como Microsoft Intune, Jamf e VMware Workspace ONE, e a sistemas de IT Asset Management, como Lansweeper e Snipe-IT, para o ciclo de vida e o inventário. A assinatura eletrônica via ICP-Brasil vem de plataformas como ClickSign, ZapSign e Autentique. Para a saúde ocupacional, conecta-se a sistemas de SST que cobrem EPI, PCMSO e ergonomia. E a transmissão ao eSocial passa por gateways como Synchro, Glik e eSocial-Connector, com trilha de auditoria.

--- Agente Recrutamento Executivo ---
> Executive Search C-Suite: Lei 6.404/76 art. 138-158 Conselho, ICVM 480 anexo 24 Disclosure remuneração e EU AI Act Anexo III(4)(a) - busca confidencial com Comitê Nomeação.

O recrutamento executivo C-Suite no Brasil esbarra em vários marcos legais ao mesmo tempo. O direito societário é o principal: a Lei 6.404/76 define a governança das companhias abertas, da eleição do Diretor pelo Conselho (art. 144) ao Say-on-Pay da Assembleia para a remuneração dos administradores (art. 152), com divulgação obrigatória pela ICVM 480 anexo 24. A LGPD entra porque a triagem por IA da longlist e da shortlist é decisão automatizada com direito a revisão (art. 22). A Lei Anticorrupção 12.846/2013 e o KYC do COAF exigem due diligence dos administradores. Por fim, para multinacionais com subsidiária na UE, o EU AI Act classifica o recrutamento como alto risco e impõe supervisão humana. Na prática, uma única nomeação executiva pode ativar todas essas obrigações de uma vez.

## As sanções se somam e a responsabilidade dos administradores é ilimitada

O risco de um processo de busca mal documentado não é único, soma-se em várias frentes. A ANPD pode aplicar até 2% do faturamento (limitado a R$ 50 milhões) por uma triagem automatizada sem avaliação de impacto ou sem direito a revisão. A CVM pode abrir processo sancionador por divulgação incompleta da remuneração dos administradores. A Lei Anticorrupção 12.846/2013 prevê multa de até 20% do faturamento e até a dissolução da empresa por falhas na due diligence. Para multinacionais com presença na UE, o EU AI Act admite multas de até 35 milhões de euros. Acima de tudo, a responsabilidade civil dos administradores pela Lei 6.404/76 (art. 158 e 246) é ilimitada e recai sobre o patrimônio pessoal.

## As 16 etapas: o que é regra, o que é IA e o que é decisão humana

O agente decompõe o recrutamento executivo em 16 micro-decisões, cada uma com a sua fonte de decisão explícita e registrada. Onze são deterministas (regras): classificação do mandato, validação da base jurídica do briefing, contratos de sigilo, due diligence dos administradores, coordenação das entrevistas confidenciais, geração do contrato, sincronização com o eSocial e divulgação à CVM, entre outras. Três são apenas indicadores de IA: a triagem da longlist e da shortlist, a modelagem do pacote de remuneração e a consolidação das avaliações. Duas são decisões exclusivamente humanas: a aprovação da shortlist (quatro olhos do Comitê de Nomeação e do Conselho) e a eleição do Diretor pelo Conselho (Lei 6.404/76 art. 144).

## Verificação contínua contra as fontes regulatórias

O agente confronta cada decisão com as normas aplicáveis e mantém o rastro para defesa: a governança societária da Lei 6.404/76, a divulgação da remuneração pela ICVM 480 anexo 24, a supervisão humana exigida pelo EU AI Act, o direito a revisão da LGPD art. 22 e o KYC do COAF. As assinaturas têm validade ICP-Brasil e o audit-trail é retido por 5 anos, pronto para responder à CVM, à ANPD ou ao MPT.

## Casos-limite: due diligence reprovada, PEP no COAF, divulgação incompleta

Alguns casos param o fluxo automaticamente. Se a due diligence de um administrador falha, o candidato não avança e o caso é escalado ao Comitê de Auditoria, ao Conselho, ao Jurídico e ao auditor independente. Um resultado positivo de PEP ou de lista de sanções no COAF bloqueia o avanço e gera comunicação de operação suspeita. Uma divulgação incompleta no formulário de referência da CVM impede a formalização da eleição até a correção. Em cada situação, o agente preserva o registro e aciona a revisão humana.

## Integração com os sistemas brasileiros

O agente se integra por API às plataformas usadas no mercado brasileiro. Conecta-se aos HCM líderes (TOTVS, Senior) e às suítes globais (SAP SuccessFactors, Workday, Oracle), sincronizando admissão e remuneração com o eSocial e a Receita Federal. Trabalha com as firmas de Executive Search de primeira linha para o briefing confidencial, a longlist e a shortlist, e com as consultorias de remuneração (Mercer, Aon, WTW, Korn Ferry) para os benchmarks do pacote C-Suite. A assinatura dos contratos e atas tem validade ICP-Brasil.

--- Agente HR Despesas ---
> Fluxo HR de despesas para self-service do colaborador: envio de despesas com OCR de comprovantes, aprovação multinível por hierarquia gerencial e validação de campos obrigatórios.

O processamento de despesas no Brasil esbarra em vários marcos legais ao mesmo tempo. No lado trabalhista, a CLT art. 457 e 458 define o que integra a remuneração (diárias acima de 50% do salário e ajudas de custo) e o que fica de fora (Vale-Transporte da Lei 7.418/1985 e PAT da Lei 6.321/1976). No lado fiscal, o RIR (Decreto 9.580/2018) governa a dedutibilidade das despesas e a validade da nota fiscal depende da SEFAZ. A LGPD entra porque a leitura por OCR e a detecção de fraude são tratamento automatizado com direito a revisão (art. 22). Na prática, um único reembolso pode ativar todas essas obrigações de uma vez.

## As sanções se somam em várias frentes

O risco de um reembolso mal processado não é único, soma-se em frentes diferentes. A ANPD pode aplicar até 2% do faturamento (limitado a R$ 50 milhões) por tratamento automatizado sem avaliação de impacto ou sem direito a revisão. A Receita pode autuar com multa de 75% a 150% por despesas deduzidas indevidamente (Lei 9.430/96). O COAF cobra a comunicação de operações suspeitas em viagens internacionais, e a Lei Anticorrupção 12.846/2013 prevê multa de até 20% do faturamento por falhas no controle de gastos de representação. No lado trabalhista, o MTE multa por classificação errada de Vale-Transporte ou PAT.

## As 15 etapas: o que é regra, o que é IA e o que é decisão humana

O agente decompõe o processamento de despesas em 15 micro-decisões, cada uma com a sua fonte de decisão explícita e registrada. Onze são deterministas (regras): validação da NF-e na SEFAZ, checagem contra a política e os limites, distinção do que entra na base de INSS e FGTS (CLT art. 457 e 458), validação do Vale-Transporte e do PAT, KYC do COAF, controle de gastos de representação, roteamento da aprovação e lançamento contábil no SPED. Duas são apenas indicadores de IA: a leitura por OCR dos comprovantes e a detecção de fraude. Duas são decisões exclusivamente humanas: a aprovação do gestor responsável e a escalada de casos de julgamento ao Compliance Officer e ao Jurídico.

## Verificação contínua contra as fontes regulatórias

O agente confronta cada decisão com as normas aplicáveis e mantém o rastro para defesa: a CLT art. 457 e 458 para a incidência de encargos, o RIR para a dedutibilidade, a validação da NF-e na SEFAZ, a LGPD art. 22 para a revisão das decisões automatizadas e o KYC do COAF para viagens internacionais. As assinaturas têm validade ICP-Brasil e o audit-trail é retido por 5 anos, pronto para responder à Receita, à ANPD ou ao MPT.

## Casos-limite: NF-e cancelada, alerta de fraude, PEP no COAF

Alguns casos param o fluxo automaticamente. Uma NF-e inválida ou cancelada na SEFAZ bloqueia o reembolso e é escalada ao Financeiro, à Controladoria e ao Contas a Pagar. Um alerta de fraude da IA segue como indicador para revisão do Compliance Officer e do auditor, com o direito a revisão da LGPD art. 22 preservado. Um resultado positivo de PEP no COAF bloqueia o reembolso e gera comunicação de operação suspeita. Um gasto de representação suspeito ou com agente público envolvido bloqueia a despesa e é escalado ao Compliance Officer e ao Jurídico.

## Integração com os sistemas brasileiros

O agente se integra por API às plataformas usadas no mercado brasileiro. Conecta-se às suítes de despesas e viagem (SAP Concur, Workday, Oracle), aos HCM líderes (TOTVS, Senior) e às plataformas de cartão corporativo, sincronizando as rubricas com o eSocial e a Receita Federal. Trabalha com os especialistas brasileiros de benefícios (FlashApp, Caju, Alelo, VR, Ticket) para PAT e Vale-Transporte, e com as plataformas de assinatura eletrônica de validade ICP-Brasil para os relatórios e aprovações.

--- Agente Gestão Documentos RH ---
> Prontuário funcional eletrônico: LGPD art. 17/18 direitos do titular, CLT art. 11 retenção 5 anos e ICP-Brasil assinatura avançada - ECM com classificação IA e audit-trail.

A gestão documental de RH no Brasil esbarra em vários marcos legais ao mesmo tempo. A CLT define a documentação obrigatória do contrato (art. 442 e 446-456) e a prescrição de 5 anos para a retenção (art. 11). A LGPD garante ao titular os direitos de acesso, correção e eliminação (art. 18), além de regrar a eliminação ao fim do tratamento (art. 25). O lado fiscal e societário (RIR e Lei 6.404/76) impõe a guarda da escrita contábil, e a assinatura eletrônica segue a MP 2.200-2 e a Lei 14.063/2020. Na prática, um único documento de RH pode ativar todas essas obrigações de uma vez.

## As sanções se somam em várias frentes

Uma fiscalização do Ministério do Trabalho solicita o Perfil Profissiográfico Previdenciário (PPP) de um colaborador de 2019. O Departamento Pessoal procura no GED, no arquivo físico, em um drive antigo. Três horas depois, o documento aparece - numa pasta de uma colega que já saiu da empresa. O fiscal registra a ocorrência. Sem multa desta vez, mas um alerta. Na próxima auditoria, as consequências serão outras. E os riscos se somam: a ANPD pode aplicar até 2% do faturamento (limitado a R$ 50 milhões) por uma classificação automatizada sem revisão; a Receita pode autuar com multa de 75% a 150% por falhas na guarda da escrita contábil; a Lei Anticorrupção 12.846/2013 prevê multa de até 20% do faturamento.

## Prazos que se contradizem

Um prontuário não tem um prazo único de retenção. É uma coleção de tipos de documento, cada um com a sua própria base legal - e os prazos se contradizem. Os documentos trabalhistas e a escrita contábil seguem 5 anos (CLT art. 11 e Lei 6.404/76), mas o FGTS exige 30 anos (Lei 8.036/90) e o PPP previdenciário 20 anos (INSS). Numa empresa de 2.000 colaboradores, com cerca de 40 documentos por prontuário, são 80 mil prazos individuais para monitorar. Manualmente é inviável; por planilha também, porque os prazos mudam a cada nova legislação. Por isso o agente usa um catálogo central de prazos por tipo de documento.

## As 15 etapas: o que é regra, o que é IA e o que é decisão humana

O agente decompõe o ciclo documental em 15 micro-decisões, cada uma com a sua fonte de decisão explícita e registrada. Doze são deterministas (regras): validação da assinatura ICP-Brasil, atendimento dos direitos do titular da LGPD, definição do prazo de retenção, atribuição de metadados e base legal, controle de acesso por função, roteamento do arquivamento, sincronização com o eSocial, monitoramento dos vencimentos e eliminação segura. Uma é apenas indicador de IA: a leitura por OCR e a sugestão de categoria do documento. Duas são decisões exclusivamente humanas: a aprovação da eliminação (pelo DPO e pelo Compliance Officer) e a escalada de casos de julgamento.

## Verificação contínua contra as fontes regulatórias

O agente confronta cada decisão com as normas aplicáveis e mantém o rastro para defesa: a documentação contratual da CLT, os direitos do titular e a eliminação da LGPD, a guarda da escrita contábil da Lei 6.404/76 e do RIR, a validade da assinatura pela MP 2.200-2 e a sincronização com o eSocial. As assinaturas têm validade ICP-Brasil e o audit-trail é retido por 5 anos, pronto para responder à ANPD, à Receita ou ao MPT.

## Casos-limite: pedido do titular não atendido, assinatura inválida, documento vencido

Alguns casos param o fluxo automaticamente. Um pedido de titular (DSAR) não atendido em 15 dias é escalado ao DPO, ao Compliance Officer e ao Jurídico. Uma assinatura ICP-Brasil inválida ou expirada bloqueia o arquivamento e é escalada ao Departamento Pessoal e ao DPO. Um documento vencido sem proposta de eliminação é sinalizado para revisão. Um acesso fora da função do colaborador é marcado e auditado. Em cada situação, o agente preserva o registro e aciona a revisão humana.

## Integração com os sistemas brasileiros

O agente se integra por API às plataformas usadas no mercado brasileiro. Conecta-se aos HCM líderes (TOTVS, Senior) e às suítes globais (SAP SuccessFactors, Workday, Oracle), sincronizando o prontuário com o eSocial e a Receita Federal. Trabalha com as plataformas de gestão de conteúdo (DocuWare, ELO, d.velop, Hyland OnBase) para o arquivamento e a retenção, e com as ferramentas de privacidade (OneTrust, BigID, Collibra) para atender aos pedidos de titular previstos na LGPD.

--- Agente Agendamento Entrevistas ---
> Agendamento de entrevistas Lei 9.029/1995-conforme: LGPD art. 22 decisão automatizada e EU AI Act Anexo III(4)(a) - Multi-Calendar com auditoria de viés e filtro de perguntas vedadas.

O agendamento de entrevistas no Brasil esbarra em vários marcos legais ao mesmo tempo. A Lei 14.611/2023 torna obrigatória a divulgação da faixa salarial na vaga e na entrevista. A Lei 9.029/1995 e a Constituição (art. 7, inciso XXX) proíbem a discriminação na admissão. A LGPD trata os dados sensíveis do candidato (art. 11) e as decisões automatizadas com direito a revisão (art. 22). O EU AI Act classifica o agendamento como alto risco, por funcionar como filtro do processo seletivo. Somam-se a LBI, para acessibilidade, e a Lei 14.457/2022, com o canal de denúncia. Na prática, uma única entrevista pode ativar todas essas obrigações de uma vez.

## As sanções se somam em várias frentes

Uma candidata se inscreve para uma vaga sênior numa multinacional brasileira. Cinco dias depois, ainda sem data confirmada - quatro entrevistadores e dois fusos. Ela aceita a oferta do concorrente em 48 horas. Pior: a entrevistadora registra na ata uma pergunta vedada por estado civil. Seis meses depois, vem a ação do MPT, com a inversão do ônus da prova (Súmula TST 401). E os riscos se somam: a ANPD pode aplicar até 2% do faturamento (limitado a R$ 50 milhões); o MTE pode autuar por descumprimento da faixa salarial; para multinacionais com presença na UE, o EU AI Act admite multas de até 35 milhões de euros.

## Sete normas em paralelo numa única entrevista

Uma entrevista não tem uma fonte legal única - ela ativa várias ao mesmo tempo. A faixa salarial obrigatória vem da Lei 14.611/2023. A proibição de discriminação na admissão vem da Lei 9.029/1995 e da Constituição. A proteção dos dados sensíveis e a revisão das decisões automatizadas vêm da LGPD (art. 11 e 22). A classificação de alto risco vem do EU AI Act. A acessibilidade vem da LBI, e o canal de denúncia da Lei 14.457/2022. Numa empresa de 2.000 colaboradores, com cerca de 200 entrevistas por mês, são milhares de obrigações individuais para monitorar - inviável de fazer manualmente ou por planilha, sobretudo porque as normas mudam.

## As 17 etapas: o que é regra, o que é IA e o que é decisão humana

O agente decompõe o agendamento em 17 micro-decisões, cada uma com a sua fonte de decisão explícita e registrada. Treze são deterministas (regras): conferir a faixa salarial da vaga, verificar o visto de estrangeiros, exigir consentimento para dados sensíveis, classificar o risco pelo EU AI Act, verificar a diversidade do painel, aplicar os ajustes razoáveis da LBI, reservar sala ou link, gerar o convite, bloquear as perguntas vedadas, monitorar o canal de denúncia e sincronizar com o eSocial. Duas são apenas indicadores de IA: o cruzamento das agendas e o reagendamento. Duas são decisões exclusivamente humanas: a auditoria de viés (supervisão humana do EU AI Act) e a escalada de casos de julgamento.

## Verificação contínua contra as fontes regulatórias

O agente confronta cada decisão com as normas aplicáveis e mantém o rastro para defesa: a faixa salarial da Lei 14.611/2023, a vedação à discriminação da Lei 9.029/1995, os dados sensíveis e a revisão da LGPD, a supervisão humana do EU AI Act e a acessibilidade da LBI. As assinaturas têm validade ICP-Brasil e o audit-trail é retido por 5 anos, pronto para responder à ANPD, ao MPT ou ao MTE.

## Casos-limite: pergunta vedada, visto inválido, gravação sem consentimento

Alguns casos param o fluxo automaticamente. Uma pergunta vedada (por sexo, estado civil, maternidade, idade ou outros) é bloqueada e escalada ao Compliance Officer e ao DPO. Um visto inválido de candidato estrangeiro bloqueia o agendamento e é escalado ao Recrutamento e ao Jurídico. Uma entrevista gravada sem consentimento bloqueia a gravação e é escalada ao DPO. A cota PCD não atendida é sinalizada ao Recrutamento. Em cada situação, o agente preserva o registro e aciona a revisão humana.

## Integração com os sistemas brasileiros

O agente se integra por API às plataformas usadas no mercado brasileiro. Conecta-se aos ATS e HCM líderes (Gupy, TOTVS, Senior) e às suítes globais (SAP SuccessFactors, Workday, Oracle), sincronizando a admissão com o eSocial e a Receita Federal. Cruza as agendas do Outlook e do Google e usa as plataformas dedicadas de agendamento (Calendly, GoodTime Hire) para a coordenação em vários fusos. A assinatura dos termos tem validade ICP-Brasil.

--- Agente de NFs de Fornecedores HR ---
> Processa NFs de fornecedores de RH (recrutamento, treinamento e benefícios) com alocação no centro de custo Pessoal e relevância CIPA.

## Processamento manual de NFs custa EUR 10 a 15 (USD 11 a 16) por operação - e ainda perde desconto

Uma única nota fiscal de entrada processada manualmente custa entre EUR 10 e EUR 15 (USD 11 a 16). Com 500 notas por semana, isso resulta em mais de EUR 300.000 (USD 330.000) em custos de processo por ano - antes de uma única nota ser classificada incorretamente ou um desconto por antecipação ser perdido. Segundo Ardent Partners, apenas 21% das empresas sem automação alcançam taxas aceitáveis de aproveitamento de descontos. Os 79% restantes pagam o valor integral porque a nota ainda estava no circuito de aprovação quando o prazo expirou.

O dano real não está nos custos óbvios de lançamento. Está nos custos consequenciais: classificação incorreta gera lançamentos de correção, falta de vínculo com pedido de compra aciona consultas com a área de compras, pagamentos atrasados deterioram condições com fornecedores. Cada um desses retrabalhos consome capacidade da equipe contábil que falta para fechamentos e análises.

## Confronto tripartite automatizado reduz taxa de erro de 12% para próximo de zero

O confronto tripartite - nota contra pedido de compra contra confirmação de recebimento - é o cerne de toda verificação fiscal adequada. Feito manualmente, é propenso a erros: 10 a 15% de todas as notas contêm divergências em quantidades, preços ou condições que um verificador humano sob pressão de tempo ignora ou avalia incorretamente. Sistemas automatizados executam esse confronto em segundos e aplicam regras de tolerância definidas de forma consistente a cada posição individual.

Concretamente: uma nota de R$ 23.900 é confrontada com a posição do pedido de R$ 24.000. A divergência de 0,4% está dentro da tolerância definida de 2% - o agente libera. Uma segunda nota diverge em 8% - o agente escala ao responsável pelo centro de custo. Sem margem de julgamento, sem inconsistência entre analistas, sem verificação esquecida na sexta-feira à tarde.

A classificação contábil segue o mesmo princípio. Em vez de o analista consultar o plano de contas, um motor de regras deriva a classificação a partir do pedido de compra. Para notas sem vínculo com pedido, o agente sugere uma conta com base em padrões históricos de lançamento - a confirmação final permanece com o ser humano.

## O [Decision Layer](/br/decision-layer/) separa liberações de rotina de decisões que exigem julgamento

O Decision Layer decompõe o processo de notas fiscais em etapas de decisão individuais e define para cada uma: Humano, Motor de regras ou Agente IA. Essa decomposição faz a diferença entre uma automação que cobre 60% das notas e uma que alcança 95%.

Extração de dados - fornecedor, valor, número da NF, itens - é tarefa de IA. A taxa de reconhecimento para notas estruturadas (XML de NF-e, PDF) fica entre 92 e 98%. O confronto tripartite e a classificação são tarefas baseadas em regras com limiares definidos. O roteamento de aprovação segue uma matriz por valor: notas abaixo de R$ 25.000 ao coordenador, acima de R$ 250.000 à diretoria.

O ser humano permanece onde a lei exige - não porque faça melhor. Escrituração contábil conforme exige rastreabilidade de cada decisão. O agente registra cada etapa com fundamentação e timestamp. Em divergências fiscalmente relevantes - como uma nota sem CNPJ válido ou tributos incorretos - ele escala a um verificador qualificado em vez de decidir sozinho.

## Processamento de NFs entrega o ROI mais rápido de todo o portfólio de agentes

Nenhum outro agente combina um throughput tão alto com uma complexidade de governança tão baixa. Processamento de notas fiscais não é sistema de alto risco pelo PL 2338/2023 (PT: equivalente do EU AI Act), não exige participação sindical e não envolve dados pessoais de colaboradores. Ao mesmo tempo, uma empresa de médio porte com 200 colaboradores facilmente processa 300 a 800 notas por mês - cada uma um evento de economia mensurável.

A conta é simples: se os custos de processo por nota caem de EUR 12 para EUR 3 (USD 13 para 3) e o aproveitamento de descontos sobe de 20% para 75%, o agente se paga com 500 notas por mês em poucos meses. Highradius estima a redução média de custos com automação de AP em 78% - de USD 13,54 para USD 2,98 por nota.

A obrigação de NF-e no Brasil reforça esse efeito. O formato XML padronizado da NF-e fornece dados legíveis por máquina que elevam ainda mais a taxa de reconhecimento e reduzem a digitação manual a casos excepcionais. Quem automatiza agora usa a infraestrutura fiscal digital brasileira como acelerador em vez de carga adicional.

--- Job Posting Agent ---
> Gera publicações de vagas conformes a partir de perfis de requisitos e coordena distribuição multicanal. Alto risco sob PL 2338/2023.

Três recrutadores, três redações, três níveis de risco. Assim é a realidade de publicações de vagas quando vinte posições precisam ser preenchidas simultaneamente. Uma vaga fala de "equipe jovem e dinâmica" - uma violação de legislação antidiscriminação que pode gerar indenizações trabalhistas. A próxima esquece informações de remuneração que a Lei de Igualdade Salarial (Lei 14.611/2023) tornará cada vez mais exigidas. A terceira é tecnicamente correta, mas tão genérica que desaparece nos milhares de portais de emprego brasileiros. E todas as três foram publicadas manualmente em três canais diferentes, porque ninguém sabe qual canal entrega o melhor retorno para qual posição.

Isso não é um problema de qualidade individual dos recrutadores. É um problema sistêmico.

## O risco triplo de cada anúncio individual

Publicações de vagas são o artefato mais vulnerável em todo o processo de recrutamento. São simultaneamente documento jurídico, rubrica orçamentária e cartão de visitas - e na maioria das organizações nenhum dos três é gerenciado sistematicamente.

**Risco jurídico: antidiscriminação hoje, transparência salarial amanhã.** Toda formulação discriminatória abre um caso de responsabilidade. "Português como língua materna" em vez de "fluência em português" - a diferença está em uma reclamação trabalhista. Com cinquenta posições abertas por ano e uma média de vinte candidaturas por posição, um único erro sistemático de redação basta para gerar indenizações de cinco dígitos. A Lei de Igualdade Salarial (Lei 14.611/2023) intensifica os requisitos: relatórios de transparência salarial são obrigatórios para empresas com mais de 100 colaboradores. Quem não trata essa informação de forma consistente em vagas arrisca sanções e perde a confiança dos candidatos antes da primeira conversa.

**Problema de custo: dispersão sem controle.** Os custos médios por contratação no Brasil variam entre R$ 5.000 e R$ 15.000 dependendo da fonte e do setor. Uma parte considerável flui para anúncios de vagas nos canais errados. Publicações individuais em job boards custam R$ 1.000 a R$ 3.000 por anúncio. Quem publica em cinco canais simultaneamente gasta facilmente mais de R$ 10.000 por posição somente com publicação - sem saber qual canal entrega candidaturas qualificadas e qual produz apenas cliques.

**Problema de qualidade: inconsistência como assassina de employer branding.** Quando a mesma posição aparece no mercado em três variantes - uma com bullet points, outra como texto corrido, outra com benefícios desatualizados - isso sinaliza arbitrariedade organizacional. Com tempo médio de preenchimento de posições técnicas no Brasil superando 60 dias, cada dia em que um anúncio mal formulado atrai os candidatos errados ou afasta os certos conta.

## Onde processos manuais falham

A cadeia típica de uma publicação de vaga funciona assim:

```
Área solicitante         Recrutamento             Aprovação
──────────────           ──────────               ────────
Requisição    ──────>    Redigir       ──────>    Revisão
(frequentemente          (varia por               (frequentemente
 sem formato)             recrutador)              apenas conteúdo,
                                                   não jurídico)
                              |
                              v
                         Publicação manual
                         (3-5 portais,
                          copiar e colar)
```

Cada seta nesse diagrama é uma fonte de erro. A requisição chega como e-mail sem estrutura. O texto é criado sob pressão de tempo sem consultar as diretrizes de marca. A revisão é feita no conteúdo, mas não juridicamente. A publicação acontece manualmente - e a performance nunca é avaliada sistematicamente.

## O que muda quando anúncios se tornam infraestrutura

Um Job Posting Agent não substitui o recrutador. Substitui a aleatoriedade. A partir de um perfil de requisitos estruturado, um rascunho de anúncio é gerado e passa por três camadas de verificação antes que um ser humano o veja:

Primeira camada: conformidade antidiscriminação. Cada formulação é confrontada com um catálogo de verificação - linguagem neutra em gênero, sem discriminação etária, sem restrição indireta por exigências de idioma. Isso não é sugestão estilística, mas regra dura. O que não passa, não avança.

Segunda camada: transparência salarial. Faixas salariais são extraídas das faixas de remuneração cadastradas e formatadas no padrão exigido. Consistente em todos os anúncios, todos os canais, todos os idiomas. Sem desvio, sem esquecimento.

Terceira camada: otimização de canal. Quais portais para qual posição, qual região, qual nível de senioridade entregam as melhores taxas de conversão, é decidido por regras - não por intuição. Os dados de performance retornam e melhoram a seleção de canal para a próxima publicação.

Somente então o recrutador vê o rascunho. E verifica o que somente um ser humano pode verificar: a tonalidade está certa? A descrição corresponde à cultura real da equipe? Existem nuances técnicas que só quem conversou com a área solicitante conhece?

## O que isso significa para a liderança de recrutamento

A questão não é se publicações de vagas serão automatizadas. A questão é se serão tratadas como infraestrutura - com governança, versionamento e trilha de auditoria - ou se permanecerão como produtos do acaso que na próxima reclamação trabalhista ou na primeira verificação de transparência salarial se tornam caso de responsabilidade.

A diferença entre uma organização que resolveu isso e uma que não resolveu não aparece no texto individual do anúncio. Aparece na capacidade de, à pergunta "Como vocês garantem que todos os seus anúncios cumprem a Lei de Igualdade Salarial?", dar uma resposta sistêmica em vez de "Cada recrutador verifica por conta própria."

Um [Decision Layer](/br/decision-layer/) torna cada etapa rastreável: quais regras foram aplicadas, quais verificações passaram ou não, quem aprovou. Não como documentação retroativa, mas como parte integrante do processo. Em um sistema potencialmente de alto risco pelo PL 2338/2023 (PT: equivalente do EU AI Act) - e é exatamente isso que é um agente que influencia quem vê anúncios de emprego - essa rastreabilidade não é opção, é obrigação.

--- Learning Event Management Agent ---
> Gerencia logística de treinamentos presenciais: salas, instrutores, participantes, equipamento e follow-up - sem coordenação manual.

Uma área de T&D que coordena 30 treinamentos por mês não está resolvendo um problema de aprendizagem. Está resolvendo um problema de logística. Cruzar salas com número de participantes, verificar disponibilidade de instrutores, encomendar materiais a tempo, gerenciar listas de espera, processar cancelamentos, enviar lembretes, cobrar avaliações. Cada tarefa individual é trivial. No agregado, consomem 40 a 60% da capacidade operacional de T&D - capacidade que não flui nem para design de programas nem para medição de impacto.

E o problema não melhora quando a organização cresce. Piora proporcionalmente.

## Por que planilhas não resolvem o problema, mas são o problema

Na maioria das organizações entre 500 e 5.000 colaboradores, a coordenação de eventos funciona assim: uma planilha Excel com datas, outra com disponibilidade de instrutores, outra com ocupação de salas. Entre elas, e-mails, convites de calendário e acordos verbais. Esse sistema tem três fraquezas estruturais que não se corrigem com planilhas melhores.

**Primeiro: conflitos multi-recurso.** Cada evento de treinamento vincula pelo menos quatro recursos - sala, instrutor, grupo de participantes, materiais. Quando um workshop para 20 pessoas precisa de sala com projetor, mas a única sala adequada naquele dia está reservada para um seminário de liderança, começa uma cadeia de replanejamento. Calendários de instrutores se deslocam, participantes precisam ser reinconvidados, pedidos de material não batem mais. Em uma planilha, o conflito só é visto quando já aconteceu. Não antes.

**Segundo: cascatas de cancelamento.** A taxa média de cancelamento em treinamentos presenciais é de 17%. Em um workshop com 20 vagas, faltam em média três a quatro participantes. Se existe lista de espera, alguém precisa manualmente promover, informar o promovido, verificar se os materiais são suficientes e notificar o instrutor sobre a composição alterada do grupo. Se não existe lista de espera, as vagas ficam vazias - e o custo por participante sobe, pois sala e instrutor já estão reservados.

**Terceiro: custos invisíveis.** Um treinamento presencial de dia inteiro para 20 participantes custa entre EUR 5.000 e EUR 15.000 (USD 5.500 a 16.500) - instrutor, sala, materiais, tempo de trabalho dos participantes incluídos. Com 30 eventos por mês, a área de T&D gerencia um orçamento mensal de seis dígitos. Mesmo assim, frequentemente não sabe quais eventos tiveram boa ocupação, quais são cronicamente subutilizados e quais instrutores recebem as melhores avaliações. Porque esses dados estão em planilhas diferentes e ninguém tem tempo de consolidá-los.

## Sete das nove etapas são baseadas em regras, duas exigem lógica de otimização

O ponto-chave na logística de treinamentos: quase toda etapa de coordenação segue regras claras. Formato resulta do tipo de treinamento e número de participantes. Lembretes saem em horários fixos. Regras de cancelamento dependem do prazo de antecedência. Promoção da lista de espera segue uma ordem. Avaliações são enviadas no dia seguinte ao evento.

Isso não é coincidência. É a razão pela qual este agente está no quadrante H2: alta frequência de transação, baixa complexidade de decisão.

```
Etapa                        Quem decide      Por quê
──────────────────────────── ───────────────── ──────────────────────────────
Definir formato do evento    Regras           Tipo + capacidade determinam formato
Identificar instrutor        Agente           Match de qualificação + calendário
Alocar sala                  Agente           Capacidade, equipamento, disponibilidade
Convidar participantes       Regras           Lista de necessidades ou inscrição aberta
Encomendar material          Regras           Checklist por tipo de evento
Enviar lembretes             Regras           7 dias + 1 dia antes do evento
Promover da lista de espera  Regras           Ordem ao cancelamento
Acionar avaliação            Regras           Dia seguinte ao evento
Processar cancelamento       Regras           Regras de cancelamento por prazo
```

Sete das nove etapas são decisões determinísticas baseadas em regras. Apenas duas - identificação de instrutor e alocação de sala - exigem lógica de agente que otimiza múltiplas variáveis simultaneamente: qualificação versus disponibilidade, capacidade versus equipamento. Nenhuma etapa exige decisão humana individual.

## Como o cotidiano da área de T&D muda

Quando os sistemas estão implementados - LMS com função de eventos, gestão de salas, pool de instrutores com dados de calendário - o trabalho operacional muda em três pontos.

O tempo de planejamento por evento cai de horas para minutos. Em vez de cruzar calendários manualmente, verificar salas e contatar instrutores, a liderança de T&D insere tipo de treinamento, público-alvo e período. O agente entrega uma proposta completa: instrutor, sala, horário, lista de materiais. Se a proposta serve, é confirmada com um clique. Se não serve, os parâmetros são ajustados e uma nova proposta é gerada.

Cancelamentos e replanejamentos perdem sua força operacional. Na ausência de um instrutor, o agente busca imediatamente instrutores substitutos qualificados com calendário livre. Em cancelamentos de participantes, a lista de espera avança automaticamente - incluindo notificação, ajuste de materiais e lista de participantes atualizada. A cascata manual de consultas, contrapropostas e convites atualizados desaparece.

A área de T&D recebe dados de gestão que antes não existiam. Taxas de ocupação por formato de treinamento, padrões de cancelamento por departamento e dia da semana, avaliações de instrutores ao longo do tempo, custo médio por participante e tipo de treinamento. Não como relatório trimestral trabalhoso, mas como reporting contínuo que surge automaticamente dos dados de reserva.

## O efeito de infraestrutura

O motor de coordenação de eventos - sala, pessoas, material, planejamento temporal contra disponibilidade otimizados - não é peça única. O mesmo mecanismo que planeja um workshop pode orquestrar um evento de onboarding, agendar um assessment center ou coordenar uma assembleia. O padrão de lista de espera se torna componente para todo agente com recursos de capacidade limitada.

E cada reserva, cada cancelamento, cada replanejamento é registrado no Decision Log. O sindicato, que tem direito de informação sobre a condução de programas de capacitação, não vê um planejamento anual resumido, mas a base documental de decisão de cada evento individual. Transparência que facilita a consulta - porque os dados já estão estruturados.

Quem coordena 30 eventos por mês manualmente, administra. Quem os coordena automaticamente, gerencia.

--- Learning Path Recommendation Agent ---
> Recomenda trilhas de aprendizagem personalizadas com base em competências, requisitos do cargo e aspirações de carreira. Não vinculante.

## O problema central: catálogos cheios, salas de aula vazias

A maioria das organizações não tem déficit de oferta. Tem um problema de alocação. Um LMS típico no médio porte contém centenas de cursos, módulos e trilhas de certificação. Ao mesmo tempo, a taxa média de conclusão em formatos de auto-aprendizagem fica entre 5 e 15%. 44% das empresas estão insatisfeitas com seu LMS, 37% buscam ativamente alternativas. A oferta de aprendizagem cresce, a utilização estagna.

O gargalo não é o conteúdo. O gargalo é a pergunta: qual curso traz para exatamente esta pessoa, neste exato cargo, o maior avanço de desenvolvimento?

Responder essa pergunta manualmente sobrecarrega qualquer área de T&D. Um gestor com doze subordinados diretos precisaria cruzar, para cada pessoa, perfil de competências, meta de carreira, treinamentos concluídos e ofertas disponíveis. Com 800 colaboradores e 400 ofertas de curso, surgem centenas de milhares de combinações possíveis. Nenhum ser humano navega isso de forma confiável. O resultado: recomendações por intuição, capacitação sem direcionamento, orçamentos sem comprovação de impacto.

## Três passos automatizados e um humano no perfil-alvo substituem mais tecnologia por melhor arquitetura

Um Learning Path Recommendation Agent resolve esse problema de alocação não com mais tecnologia, mas com melhor arquitetura de decisão. O fluxo segue uma cadeia clara:

```
Perfil atual         Perfil-alvo          Lacuna           Oferta
┌──────────┐      ┌──────────┐      ┌──────────┐    ┌──────────┐
│ Compe-   │      │ Cargo-   │      │ Análise  │    │ Matching │
│ tências, │─────>│ alvo ou  │─────>│ de gap   │───>│ contra   │
│ Cursos,  │      │ próximo  │      │ Atual vs.│    │ catálogo │
│ Cargo    │      │ passo    │      │ Alvo     │    │          │
└──────────┘      └──────────┘      └──────────┘    └──────────┘
     A                 H                 A                A

A = Agente decide    H = Humano decide
```

O ponto decisivo: o cargo-alvo permanece com o ser humano. O colaborador define na conversa de desenvolvimento para onde quer ir. Tudo antes e depois - análise de perfil, levantamento do perfil exigido do cargo-alvo, cálculo de lacuna, filtragem de ofertas, escolha de formato e fornecedor, verificação de orçamento e tempo, priorização - um agente pode fazer mais rápido, mais completo e mais consistente que qualquer pesquisa manual.

Trilhas de aprendizagem personalizadas aumentam comprovadamente a taxa de conclusão em cerca de 30%. Não porque o conteúdo melhora, mas porque o encaixe é correto. Quem vê exatamente os módulos que endereçam sua lacuna concreta de competência investe tempo de aprendizagem com retorno visível.

## Por que isso é especialmente relevante no médio porte

Em organizações entre 500 e 5.000 colaboradores, duas realidades colidem. De um lado: 81,8% das empresas relatam que colaboradores têm pouco espaço para capacitação. De outro: 42,9% apontam personalização insuficiente como problema central de sua estratégia de T&D.

Pouco tempo e baixa taxa de acerto - essa é a combinação tóxica. Se um colaborador tem quatro horas por trimestre para capacitação, nenhuma delas pode ser desperdiçada em um curso irrelevante. Cada recomendação precisa ser certeira.

Grandes corporações resolvem isso com equipes dedicadas de T&D que elaboram planos de desenvolvimento individuais. No médio porte, essa capacidade não existe. Três analistas de desenvolvimento para 2.000 colaboradores não conseguem curar 2.000 trilhas de aprendizagem individuais. Mas um agente pode - e atualizado semanalmente, não uma vez por ano na conversa de desenvolvimento.

## Rastreabilidade em vez de caixa-preta

Uma preocupação frequente com recomendações baseadas em algoritmos: por que exatamente esta oferta? O [Decision Layer](/br/decision-layer/) registra cada etapa de decisão. Quais dados entraram, qual ponderação foi aplicada, por que o curso A foi priorizado sobre o curso B. Essa transparência não é obrigação regulatória - recomendações de trilha de aprendizagem não são sistema de alto risco pelo PL 2338/2023 desde que permaneçam não vinculantes. Mas é operacionalmente decisiva.

Quando o sindicato pergunta por quais critérios as recomendações são geradas, existe uma resposta documentada. Quando um gestor questiona uma recomendação, a fundamentação está disponível. E quando um colaborador recusa a recomendação, fica sem consequência - é uma sugestão, não uma atribuição.

## O efeito de infraestrutura

O framework de recomendação não trabalha isolado. Análise de perfil, cálculo de lacuna e matching de ofertas formam uma base reutilizável. O mesmo mecanismo que recomenda trilhas de aprendizagem pode avaliar caminhos de carreira, identificar candidatos à sucessão ou tornar visíveis lacunas estratégicas de competência no nível organizacional.

Cada recomendação também gera dados: quais lacunas aparecem com frequência? Quais ofertas são aceitas, quais ignoradas? Quais áreas se desenvolvem mais rápido que outras? Esses dados fluem de volta para o planejamento - não como instrumento de controle sobre indivíduos, mas como indicador estratégico para o planejamento de capacitação.

A diferença para um filtro de LMS melhorado: um filtro mostra cursos que podem servir. Um agente de recomendação fundamenta por que exatamente este curso, exatamente agora, tem a maior alavancagem - e entrega a trilha de auditoria junto.

--- Leave of Absence Agent ---
> Gerencia solicitações de licença: elegibilidade, cálculo de direitos, workflows de aprovação, ajustes na folha e coordenação de retorno.

Todo mês chegam solicitações de licença que não podem esperar. Licença-maternidade conforme CLT (PT: Código do Trabalho). Licença-paternidade estendida (Empresa Cidadã). Licença para tratamento de saúde. Licença sabática conforme convenção coletiva. Licença-nojo. Quatro bases legais, quatro regimes de prazos diferentes, quatro conjuntos de requisitos de elegibilidade - e cada solicitação individual consome capacidade de RH que deveria estar disponível para trabalho estratégico.

O problema não é a solicitação individual. O problema é a simultaneidade.

## Por que justamente agora

Cerca de 2,3 milhões de brasileiras acessaram o salário-maternidade via INSS em 2024. A licença-paternidade estendida de 20 dias (Empresa Cidadã) ganha relevância crescente. Licenças para acompanhamento de familiar doente seguem regras específicas conforme convenção coletiva em muitos setores. Cada modalidade tem requisitos próprios, prazos e impactos sobre remuneração e benefícios.

Simultaneamente, cresce a demanda por outros tipos de afastamento. Licença-nojo (falecimento de familiar). Licença-casamento. Férias proporcionais acumuladas - a maioria dos colaboradores inicia o novo ano com saldo de férias não gozado. Licença não remunerada por acordo individual.

Para o RH, surge uma equação com muitas incógnitas. E as consequências de erros não são triviais: prazos perdidos em licenças-maternidade podem gerar ações trabalhistas. Cálculo incorreto de elegibilidade em afastamentos cria riscos jurídicos. Falta de planejamento de substituição impacta a operação. E o eSocial exige transmissão correta e tempestiva de todos os eventos.

## Verificação de elegibilidade sob a CLT é regra, aprovação de licença sabática é decisão humana

O [Decision Layer](/br/decision-layer/) separa neste processo dois mundos.

O primeiro mundo é regras. Verificação de elegibilidade, cálculo de prazos, impacto na remuneração - são operações determinísticas. Se alguém tem direito à licença-maternidade está na CLT e no Art. 10 do ADCT (estabilidade provisória). Se o prazo da solicitação foi respeitado resulta da data prevista do parto e do início desejado. Como uma licença de seis meses para tratamento de saúde afeta os benefícios está no regulamento interno e na convenção coletiva. Essas verificações não precisam de ser humano. Precisam de um motor de regras que esteja corretamente e completamente modelado.

O segundo mundo é decisão. Quem assume a substituição? Uma licença sabática é aprovada mesmo sem direito legal garantido? Como se organiza o retorno após 6 meses de licença-maternidade? Essas perguntas exigem contexto, julgamento e responsabilidade. Ficam com o gestor e o RH.

Entre esses dois mundos há uma faixa estreita onde IA contribui: sugestões de substituição com base em perfis de competência e disponibilidade. Não uma decisão - uma sugestão que delimita o espaço de busca.

```
Solicitação chega
    |
    v
[Regras] Classificação --> Maternidade | Saúde | Sabática | Especial
    |
    v
[Regras] Verificação de elegibilidade --> CLT | Convenção | Política | Contrato
    |
    v
[Regras] Cálculo de prazos + Impacto na remuneração
    |
    v
[IA] Sugestão de substituição (Competência + Disponibilidade)
    |
    v
[Humano] Confirmar substituição + Aprovar solicitação
    |
    v
[Regras] Planejamento de retorno + Lembretes automáticos
```

## O que muda com isso

A diferença não aparece em uma solicitação individual. Aparece no acumulado ao longo de um ano.

Uma empresa com 2.000 colaboradores processa por ano tipicamente várias centenas de eventos de afastamento além das férias regulares: licença-maternidade, licença-saúde, licenças especiais, sabáticas, suspensões não remuneradas. Cada evento tem uma fase de verificação (elegibilidade, prazo, remuneração), uma fase de coordenação (substituição, passagem de bastão) e uma fase de retorno (re-onboarding, reativação de sistemas).

Quando a fase de verificação é automatizada, duas coisas acontecem simultaneamente: o tempo de processamento cai, porque nenhuma solicitação fica mais esperando sobre uma mesa. E a taxa de erro cai, porque o motor de regras não perde prazos nem confunde bases legais.

A coordenação de substituição não começa mais duas semanas antes do início do afastamento, mas imediatamente após a entrada da solicitação. Isso dá às equipes tempo para passagens de bastão organizadas em vez de soluções de emergência.

O retorno não é mais esquecido. Quatro semanas antes da data documentada de retorno, gestor e RH recebem um lembrete. Para afastamentos mais longos, inclui uma checklist de re-onboarding que se orienta pelo tipo e duração do afastamento.

## A contribuição para a infraestrutura

O motor de verificação de elegibilidade, construído aqui para licença-maternidade e outros afastamentos, é reutilizável. A mesma lógica - direito legal, direito contratual, cálculo de prazos - é necessária na gestão de período de experiência e na geração de contratos. O padrão de sugestão de substituição forma a base para o planejamento de força de trabalho. O planejamento automatizado de retorno é um padrão para todo agente que dispara ações subsequentes temporizadas.

Esse é o ponto real: cada agente bem construído gera infraestrutura para o próximo.

--- Legal Contract Review Agent ---
> Assiste revisão de contratos comerciais: extrai termos, compara com padrões e sinaliza desvios, riscos e cláusulas ausentes.

## Advogados passam metade do tempo em trabalho que não exige expertise jurídica

Segundo o Gartner, até 50 por cento da capacidade de um departamento jurídico é consumida por gestão de contratos. A maior parte disso não é pensamento jurídico - é leitura, comparação, classificação. Um contrato de prestação de serviços é confrontado com o modelo interno de cláusulas. Um NDA é verificado quanto a desvios em prazo e foro. Um contrato-quadro é comparado cláusula por cláusula com o padrão.

Esse trabalho exige diligência. Mas, na maioria dos casos, não exige julgamento jurídico. A questão não é se um advogado consegue ler a cláusula de responsabilidade - mas se ele é a pessoa certa para constatar que ela é idêntica à versão padrão.

É exatamente aí que está o padrão automatizável: a comparação de texto contratual com padrões definidos. A extração de cláusulas de risco conhecidas. A classificação por tipo de contrato. Em um departamento jurídico que revisa 200 contratos por trimestre, isso significa a diferença entre uma equipe que reage e uma equipe que molda.

## 92 minutos por contrato não são padrão de qualidade - são gargalo

O tempo médio de revisão de um contrato padrão é de 92 minutos. Para um NDA - o tipo mais simples - sistemas de IA atuais completam a mesma comparação em 26 segundos com 94 por cento de precisão ([Sirion, 2026](https://www.sirion.ai/library/contract-insights/ai-playbook-redlining-vs-manual-contract-review/)). Os 6 por cento faltantes não são argumento contra a automação. São argumento a favor do recorte certo: o agente verifica as cláusulas padrão. O advogado examina os desvios.

Imagine uma semana típica em um departamento jurídico que atende contratos de compras. Segunda-feira chegam três novos contratos de fornecedores. Quarta-feira, um contrato-quadro renovado com condições de responsabilidade alteradas. Sexta-feira, um NDA para uma diligência prévia. Cada um desses contratos percorre o mesmo processo: identificar o tipo, comparar cláusulas padrão, marcar desvios, avaliar riscos. Só depois começa o trabalho jurídico propriamente dito - a avaliação sobre se um desvio é aceitável ou precisa ser renegociado.

O Legal Contract Review Agent assume as primeiras seis etapas desse processo. As três últimas - avaliação de risco pelo advogado, recomendação de negociação e liberação - permanecem onde a lei exige: com o ser humano.

## Seis etapas de decisão automatizadas, três permanecem com o advogado

O [Decision Layer](/br/decision-layer/) decompõe cada processo de revisão contratual em etapas de decisão individuais e define para cada etapa: humano, motor de regras ou IA. No caso da análise contratual, essa decomposição produz um quadro claro.

As etapas automatizáveis seguem um padrão: comparam o que é com o que deveria ser. Este contrato é um NDA ou um contrato de prestação de serviços? A cláusula de responsabilidade corresponde ao padrão ou se afasta dele? O contrato contém cláusula penal? Essas perguntas podem ser respondidas de forma confiável com uma biblioteca de cláusulas bem mantida.

As etapas humanas seguem outro padrão: exigem julgamento sob incerteza. O limite de responsabilidade divergente é aceitável para este fornecedor específico? O valor de negócio do contrato supera o risco de uma cláusula de garantia faltante? O contrato pode ser liberado nessas condições? São decisões que exigem contexto que nenhum agente possui - relação comercial, histórico de negociação, prioridades estratégicas.

A pontuação de governança deste agente, entre 55 e 62, é nitidamente maior do que a de automações de processo puras. Isso reflete o fato de que a análise contratual opera mais próxima de decisões juridicamente relevantes do que, por exemplo, folha de pagamento (PT: processamento salarial) ou ponto eletrônico. O agente pode analisar e marcar. Avaliar e decidir, não.

## A biblioteca de cláusulas decide o sucesso - e ela ainda não existe

Este é um agente H3. Isso significa: maior complexidade, menor maturidade do que automações de processo já estabelecidas. Sistemas de IA atuais perdem entre 10 e 20 por cento de precisão em contratos com mais de 1.000 caracteres de prompt ([WorldCC / KPMG, 2025](https://kpmg.com/us/en/articles/2025/agentic-ai-in-clm-balancing-human-and-machine-expertise.html)). Em um contrato-quadro de 30 páginas, esse é um fator relevante.

O pré-requisito mais importante não é tecnologia - é uma biblioteca de cláusulas mantida com os padrões da empresa para cada tipo de contrato. Sem esse referencial, o agente não tem nada contra o que comparar. A biblioteca define o que significa "padrão". Só então o agente pode identificar o que é "desvio".

Empresas que já operam um sistema de Contract Lifecycle Management e documentaram suas cláusulas padrão conseguem colocar este agente em produção mais rapidamente. Empresas sem essa base constroem a biblioteca durante a implantação - o que retarda o rollout, mas cria valor independente. Uma biblioteca de cláusulas estruturada melhora a revisão contratual mesmo sem agente, porque pela primeira vez define um padrão único de referência.

O horizonte honesto: não produtivo no mês que vem, mas sim após a construção da biblioteca de cláusulas e uma fase de calibração com o departamento jurídico. O ganho depois: advogados usando seu tempo nos casos em que o julgamento jurídico é de fato necessário.

--- Agente Merit-Cycle Governance ---
> Ciclo anual de remuneração: CLT art. 461 isonomia, Lei 14.611/2023 Igualdade Salarial e EU AI Act Anexo III(4)(b) alto risco - Equity-Audit-Engine com LGPD art. 22 e Súmula TST 6.

## Cinco meses da aprovação do orçamento até o primeiro pagamento

Este agente segue o princípio do [Decision Layer](/br/decision-layer/): cada decisão é baseada em regras, assistida por IA ou explicitamente atribuída a uma pessoa. Está classificado pelo [EU AI Act 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) (Anexo III(4)(b)) como sistema de alto risco e, por isso, sujeito a obrigações reforçadas de gestão de risco, governança de dados, transparência, supervisão humana e auditoria de viés - aplicável a multinacionais brasileiras com presença na UE.

Um ciclo de mérito típico dura cinco meses. Não porque as decisões sejam difíceis, mas porque o processo é. Aprovação do orçamento em setembro. Preparação dos dados em outubro. Distribuição das planilhas a 30, 50, 80 gestores em novembro. Devoluções por semanas. Rodadas de calibração em janeiro. Correções. Entrega para a folha em fevereiro. Primeiro pagamento, no melhor caso, em março.

O problema não está no tempo. Está no que acontece entre as etapas - ou melhor, no que não acontece: a análise sistemática de equidade, as justificativas documentadas para a inversão do ônus da prova (CLT art. 461 e Lei 14.611/2023), a validação do Compa-Ratio e a consistência entre unidades de negócio e níveis hierárquicos.

## O que permanece invisível nas rodadas de planilha

Quando 60 gestores preenchem propostas salariais em arquivos de Excel paralelos, não emerge um processo consistente. Emerge uma coleção de avaliações individuais que ninguém consegue agregar, validar ou comparar em tempo real. As consequências típicas:

**Estouros de faixa sem aviso.** Um gestor recomenda um aumento que empurra o empregado acima do limite superior da faixa salarial. Na planilha, isso só fica evidente quando a área de remuneração revisa o arquivo manualmente - muitas vezes semanas depois, muitas vezes nunca. É comum que empregados sejam pagos fora de suas faixas definidas sem que ninguém perceba de forma sistemática.

**Lacunas de equidade que ficam ocultas.** Com 60 planilhas preenchidas em paralelo, uma rodada de calibração em janeiro não percebe que as gerentes de vendas recebem, de forma sistemática, ajustes 4% menores que os colegas homens - ou que a diferença salarial entre quem tem mais de 50 anos e quem está em meio de carreira, numa certa função, chega a 7%.

**Risco de inversão do ônus da prova sem audit-trail.** Numa ação trabalhista, o ônus da prova se inverte sob a CLT art. 461 e a Lei 14.611/2023: se o empregado apresenta indícios de discriminação (uma anomalia estatística, a falta de justificativa, o momento do ajuste), cabe ao empregador provar que não houve discriminação. Sem uma justificativa documentada e reproduzível por ajuste, essa prova é praticamente impossível de produzir.

## As sanções de um ciclo de mérito mal conduzido se somam

Os riscos de um ciclo de mérito mal conduzido se acumulam. No lado trabalhista, a CLT art. 461 e a Lei 14.611/2023 abrem caminho para multas administrativas do MTE (de 3 a 100 salários mínimos por trabalhador prejudicado), além da reparação de danos morais e materiais. Em ações coletivas ou com vários reclamantes do mesmo grupo comparável, o valor pode chegar rapidamente à casa dos milhões de reais - e a inversão do ônus da prova torna a defesa praticamente impossível sem uma justificativa documentada por ajuste.

A esses somam-se outros riscos. Para multinacionais com presença na UE, o EU AI Act admite multas de até 35 milhões de euros ou 7% do faturamento global do grupo. A LGPD prevê até 2% do faturamento no Brasil (limitado a R$ 50 milhões). A Lei Anticorrupção 12.846/2013 chega a 20% do faturamento bruto. E a violação do reporte de equidade da CSRD leva a ressalva do auditor e à responsabilidade do Conselho de Administração (Lei 6.404/76 art. 158).

O caso Mobley v. Workday (Califórnia, 2023), uma ação coletiva sobre viés algorítmico em software de RH contra candidatos com mais de 40 anos, serve de precedente nos EUA e tem paralelo direto na vedação à discriminação por idade da CLT art. 461 - virando referência para reguladores e auditores.

## A transparência salarial da Lei 14.611/2023 no Brasil

A [Lei 14.611/2023](http://www.planalto.gov.br/ccivil_03/_ato2023-2026/2023/lei/l14611.htm), de Igualdade Salarial entre Mulheres e Homens, e o [Decreto 11.795/2023](http://www.planalto.gov.br/ccivil_03/_ato2023-2026/2023/decreto/d11795.htm) criam obrigações concretas: o Relatório de Transparência Salarial semestral via MTE para empresas com 100 ou mais empregados, um Plano de Ação de Igualdade Salarial obrigatório quando se identificam disparidades, e multas administrativas de 3 a 100 salários mínimos por trabalhador.

A inovação está nos mecanismos de transparência salarial obrigatória, que vão além da CLT art. 461 (que já exige isonomia entre trabalhadores de igual valor na mesma função e localidade). O decreto detalha o procedimento semestral, com prazos em março e setembro, a publicação dos relatórios em local de fácil acesso e o envio ao MTE pelo Portal Emprega Brasil. As Súmulas TST 6 (isonomia) e 442 (plano de cargos e salários) complementam o quadro.

Some-se a Diretiva europeia de transparência salarial (2023/970), que a partir de junho de 2026 alcança as multinacionais com presença na UE: empresas sediadas no Brasil mas com operações na Europa precisam cumprir os dois marcos ao mesmo tempo.

## A classificação de alto risco do EU AI Act, com DPIA e FRIA

Este agente recai sob o EU AI Act (Anexo III(4)(b)), que trata os sistemas de decisão salarial de RH como de alto risco. As obrigações, aplicáveis também às multinacionais brasileiras com presença na UE, incluem:

- **Gestão de risco (Art. 9):** identificar, analisar e mitigar os riscos de viés (de gênero, idade, etnia e deficiência).
- **Governança de dados (Art. 10):** qualidade dos dados de treinamento e testes de paridade e de igualdade de oportunidade.
- **Transparência (Art. 13):** documentação sobre o funcionamento, a precisão e os resultados da auditoria de viés.
- **Supervisão humana (Art. 14):** uma pessoa no circuito, obrigatória, em cada recomendação.
- **Obrigações do operador (Art. 26):** avaliação de impacto (DPIA), consulta à autoridade supervisora e monitoramento pós-mercado.
- **FRIA (Art. 27):** a avaliação de impacto sobre direitos fundamentais antes da implantação, com consulta à ANPD, ao DPO, à CIPA e aos sindicatos.

As multas chegam a 35 milhões de euros ou 7% do faturamento global do grupo. No Brasil, isso se conecta à obrigação de Encarregado (DPO) da LGPD art. 38 e ao direito a revisão das decisões automatizadas do art. 22. O caso [Mobley v. Workday](https://www.courtlistener.com/docket/67476007/mobley-v-workday-inc/) (Califórnia, 2023) serve de precedente e baliza os reguladores brasileiros.

## A auditoria de equidade como vantagem sobre o processo manual

O motor de análise de equidade verifica estatisticamente todas as características protegidas (conforme a CLT art. 461, a Lei 14.611/2023, a Lei 9.029/1995 e a LGPD art. 11). Para cada característica, mede a paridade demográfica (se a frequência dos ajustes é igual entre os grupos) e a igualdade de oportunidade (se a magnitude dos ajustes é igual para desempenho comparável). Em desvios estatisticamente significativos, há escalada automática ao RH, com audit-trail conforme a CLT art. 461.

Isso não é só proteção de compliance. Estudos (como o McKinsey Diversity Wins e relatórios de equidade salarial do IPEA) mostram lacunas de equidade de 4% a 6% em empresas no Brasil e de 2% a 4% nas listadas na B3 que passam despercebidas no processo manual. O agente as torna visíveis e cria a base de dados para ajustes de correção dirigidos.

## Como se encaixa na esteira de agentes de RH

Este agente opera em conjunto com outros agentes especializados de RH. O [Agente de Benchmarking de Remuneração](/br/catalogo-agentes-hr/compensation-benchmarking-agent/) fornece as faixas salariais e os Compa-Ratios. O agente de avaliação de desempenho fornece as qualificações que são pré-requisito de elegibilidade. O [Agente de Cálculo da Folha](/br/catalogo-agentes-hr/payroll-calculation-agent/) recebe os ajustes aprovados com a data de efetividade correta. O [Agente de Reporte da Folha](/br/catalogo-agentes-hr/payroll-reporting-agent/) gera o reporte de equidade da CSRD e o Relatório de Transparência Salarial do MTE. O [Agente de Gestão de Documentos de RH](/br/catalogo-agentes-hr/hr-document-management-agent/) arquiva as justificativas dos ajustes por 5 anos. O [Agente de Auditoria e Compliance](/br/catalogo-agentes-hr/audit-compliance-agent/) verifica as obrigações do operador no EU AI Act. E o [Agente de Agendamento de Entrevistas](/br/catalogo-agentes-hr/interview-scheduling-agent/) aplica a faixa salarial nas ofertas de trabalho.

## Em resumo

- **Classificação**: alto risco pelo EU AI Act (Anexo III(4)(b)), por se tratar de decisões salariais de RH - aplicável a multinacionais com presença na UE.
- **Âncoras de compliance**: a isonomia da CLT art. 461 e da Súmula TST 6, a transparência salarial da Lei 14.611/2023 e o direito a revisão da LGPD art. 22.
- **Consulta obrigatória**: à CIPA e aos sindicatos, conforme a Lei 13.467/2017.
- **Limiar de equidade**: uma diferença salarial de gênero inexplicada acima de 5% aciona o Plano de Ação de Igualdade Salarial e o prazo de 6 meses de remediação (Lei 14.611/2023).
- **Multas**: até 35 milhões de euros pelo EU AI Act, até 2% do faturamento no Brasil pela LGPD, de 3 a 100 salários mínimos por trabalhador pelo MTE e até 20% do faturamento pela Lei Anticorrupção.
- **Obrigação de auditoria**: DPIA, FRIA e auditoria de viés trimestral, com verificação do auditor na CSRD (a partir de 250 empregados) e o Relatório de Transparência Salarial do MTE.
- **Precedente nos EUA**: o caso Mobley v. Workday (Califórnia, 2023), sobre viés algorítmico em software de RH.

### Distribuição de decisores

| Passo | Decisor | Justificativa |
|-------|---------|-----------|
| Estabelecer orçamento | H | Estratégia da Diretoria, com preparação da CSRD |
| Verificação de elegibilidade | R | Tempo de serviço, desempenho e suspensões, por regra |
| Provisão do benchmark | R | Cálculo determinístico do Compa-Ratio |
| Recomendação do gestor | H | Desempenho individual e risco de retenção |
| Validação da faixa salarial | R | Checagem automática do mínimo e do máximo da faixa |
| Conformidade do orçamento | R | Acompanhamento determinístico em tempo real |
| Análise de equidade | A | Detecção estatística de viés, com validação humana |
| Escalada de equidade | R | Limiar de 5% da Lei 14.611/2023 |
| Fluxo de aprovação | R | Matriz por hierarquia e posição no Compa-Ratio |
| Aprovação do RH | H | Aprovação final, conforme a CLT |
| Comunicação ao empregado | R | Fluxo padrão da LGPD (art. 9 e 22) |
| Conversa salarial | H | Conversa pessoal, de dimensão relacional |
| Entrega para a folha | R | Data de efetividade e reflexos de INSS e IRRF, por regra |
| Reporte CSRD e B3 | R | Geração determinística dos relatórios de equidade |

--- Offboarding Agent ---
> Orquestra o desligamento completo: checklist entre RH, TI e gestão, transferência de conhecimento e documentação de saída.

## Ex-colaboradores com credenciais ativas - o ponto de entrada preferido de qualquer invasor

Este agente segue o princípio do [Decision Layer](/br/decision-layer/): cada decisão é baseada em regras, assistida por IA ou atribuída explicitamente a uma pessoa.

Uma parcela significativa dos ex-colaboradores mantém credenciais ativas após o desligamento - em muitas organizações, essas contas inativas alcançam porcentagens mensuráveis de todos os usuários no provedor de identidade. Uma fatia relevante das contas marcadas como inativas tem permissões ativas em aplicações centrais. E muitas empresas levam mais de três dias, após um desligamento, para bloquear todos os acessos a sistemas. Algumas nunca conseguem fazê-lo completamente.

Isso não é um problema marginal. É o bilhete de entrada para qualquer atacante que prefere usar credenciais válidas a transpor firewalls.

## Cinco frentes, zero regente

Um processo de desligamento toca ao menos cinco áreas de responsabilidade simultaneamente. Nenhuma espera pela outra. Todas têm prazos próprios, sistemas próprios e pontos cegos próprios.

```
Demissão / rescisão
    |
    +-- RH: fechar prontuário, comunicações, TRCT
    +-- TI: recolher hardware, bloquear acessos, liberar licenças
    +-- Área de negócio: transferência de conhecimento, handover de projetos
    +-- Gestor: entrevista de saída, registrar feedback
    +-- LGPD: iniciar prazos de retenção, verificar obrigações de guarda
    |
Último dia de trabalho (tudo precisa estar concluído)
    |
Pós-saída: documentos, retenção LGPD, acompanhamento de retornáveis
```

Na prática, o RH coordena isso por checklist e e-mail de lembrete. Com três desligamentos por trimestre, funciona. Com trinta, colapsa - silenciosamente. Ninguém percebe o acesso VPN que fica ativo por mais dois meses. Ninguém pergunta sobre a pasta do SharePoint com dados de clientes à qual o ex-colaborador ainda tem acesso.

## Por que o offboarding é mais caro do que parece

Os custos visíveis de uma saída mal conduzida são administráveis: um notebook esquecido, um bloqueio atrasado. Os invisíveis, não.

Uma parcela substancial dos responsáveis de RH estima que o desligamento inconsistente custa a suas empresas montantes de seis algarismos em EUR por ano - em perda de conhecimento, riscos de segurança e custos de reposição. Apenas uma minoria das empresas garante que ocorra uma transferência de conhecimento adequada no desligamento. Uma grande parte do conhecimento técnico de uma posição existe exclusivamente na cabeça do titular e não é facilmente reposto por um sucessor.

Três vetores de custo pesam especialmente:

**Risco de segurança.** Contas órfãs são o vetor de ataque mais simples. Sem força bruta, sem phishing - as credenciais já existem. Num mundo em que uma empresa média opera 275 aplicações SaaS, o desprovisionamento manual é uma ilusão.

**Perda de conhecimento.** O custo de perder um especialista de domínio pode ser vinte vezes maior do que os custos comuns de recrutamento e integração. Não porque a pessoa seja insubstituível, mas porque seu conhecimento não documentado é.

**Potencial de retorno (boomerang).** Cerca de 35 por cento das novas contratações hoje são retornos. A taxa de retenção deles é 44 por cento maior do que a de colaboradores completamente novos. Um desligamento caótico destrói exatamente o relacionamento que teria possibilitado uma recontratação.

## Três janelas de tempo, três problemas distintos

O desligamento não é um único evento. Ele se divide em três fases com exigências fundamentalmente diferentes.

**Antes do último dia:** organizar transferência de conhecimento, repassar projetos, treinar o sucessor. Aqui é o gestor quem decide qual conhecimento é crítico - nenhum motor de regras consegue automatizar isso, porque exige conhecimento contextual sobre dinâmica de equipe e dependências de projeto.

**No último dia:** devolver hardware, bloquear acessos, recolher crachá. Esta fase é totalmente baseada em regras. Quais equipamentos precisam voltar está na lista de provisionamento do onboarding. Quais acessos serão revogados sai do perfil de permissões. Momento e ordem seguem um plano de desativação - sistemas críticos imediatamente, encaminhamento de e-mail após prazo de transição definido.

**Após a saída:** emitir documentos rescisórios (TRCT, guias de seguro-desemprego, saque do FGTS), cumprir prazos de retenção, fechar cálculos finais. O prazo prescricional trabalhista da CLT exige guarda de documentação por até cinco anos; obrigações fiscais e previdenciárias chegam a dez anos. A obrigação de exclusão sob a LGPD corre em paralelo a esses prazos - uma tensão que, sem governança clara, leva regularmente a infrações.

```
Fase              Erro típico                          Consequência
────────────────  ──────────────────────────────────    ────────────────────────
Antes da saída    Sem plano de transferência             42% do conhecimento perdido
Último dia        VPN/nuvem não bloqueados               Risco de segurança
Pós-saída         TRCT atrasado                          Ação trabalhista
Pós-saída         Exclusão LGPD esquecida                Multa até 2% do faturamento
```

## Seis das dez etapas baseadas em regras, IA apenas na minuta de carta, três decisões permanecem humanas

O Offboarding Agent é o espelho do Onboarding Workflow Agent. Mesmo motor de orquestração, mesma arquitetura de modelos, distribuição de tarefas e monitoramento de prazos - apenas no sentido inverso.

Assim que um desligamento é registrado no sistema de RH, três coisas acontecem simultaneamente: o motor de regras determina o tipo de offboarding conforme o motivo da saída - demissão sem justa causa, pedido de demissão, acordo mútuo, rescisão por justa causa e aposentadoria geram checklists diferentes. A lista completa de tarefas é gerada a partir do modelo e distribuída aos responsáveis. A partir desse momento, o agente monitora prazos e escala em caso de atraso.

A arquitetura de decisão é intencionalmente restritiva. De dez etapas no processo, seis são baseadas em regras, uma é apoiada por IA e três permanecem humanas. A IA atua apenas na minuta de carta de referência - onde, a partir da descrição de atividades, tempo de casa e avaliação de desempenho, um texto-base é gerado. Se a carta é liberada, se a entrevista de desligamento acontece e qual conhecimento é considerado crítico, isso decidem o gestor e o RH pessoalmente.

## Retenção LGPD como problema arquitetural

A maioria das empresas trata obrigações de retenção como tarefa do encarregado de dados. Isso funciona enquanto alguém lembra. Com 50 saídas por ano, espalhadas por sistemas que não conhecem rotina central de retenção, em algum momento ninguém mais lembra.

A tensão é real: documentos de folha precisam ser guardados por até dez anos conforme legislação fiscal e previdenciária. Dados de candidatura devem ser excluídos após, no máximo, seis meses. Prontuários caem no prazo prescricional trabalhista da CLT, de cinco anos. Em caso de violações, a ANPD (PT: CNPD) pode aplicar multas de até 2 por cento do faturamento, limitadas a 50 milhões de reais por infração.

Um Offboarding Agent não resolve isso por exclusão, mas por gestão de prazos. Cada registro recebe, no desligamento, uma categoria de retenção com data concreta de exclusão. O agente monitora os prazos e escala quando uma data se aproxima. A exclusão propriamente dita continua sendo uma etapa manual com dupla checagem - mas o lembrete é sistemático em vez de casual.

## Valor de infraestrutura: o motor de onboarding ao contrário

A maior alavanca econômica deste agente não está na automação do processo em si, mas na reutilização. O motor de checklist, a distribuição de tarefas, o monitoramento de prazos e a lógica de escalação são idênticos aos do Onboarding Workflow Agent. Quem construiu um recebe o outro como configuração, não como projeto.

A lógica de desativação de sistemas forma, além disso, a base para o Access Management ao longo de todas as fases do ciclo de vida - da transferência à licença-maternidade, até o retorno. E o padrão de geração de documentos rescisórios é reutilizado pelo HR Document Management Agent para declarações, atestados e cartas de referência.

Cada execução de offboarding gera uma trilha de auditoria completa: qual tarefa foi concluída quando, qual prazo foi cumprido ou ultrapassado, quem escalou. A partir de 100 execuções documentadas, forma-se um retrato de onde o processo trava sistematicamente - não porque alguém encomendou um relatório, mas porque a arquitetura gera esses dados como subproduto.

--- Onboarding Workflow Agent ---
> Orquestra o onboarding completo: RH, TI, Facilities e gestor - experiência consistente no primeiro dia sem etapas esquecidas.

## Um em cada três novos colaboradores deixa a empresa nos primeiros 90 dias - não por causa do trabalho

Este agente segue o princípio do [Decision Layer](/br/decision-layer/): cada decisão é baseada em regras, assistida por IA ou atribuída explicitamente a uma pessoa.

Um em cada três novos colaboradores deixa a empresa nos primeiros 90 dias. Não por causa do cargo. Não por causa do salário. Mas porque, no primeiro dia, o notebook não está pronto, os acessos não foram criados e ninguém sabe exatamente quem seria responsável pela integração de segurança. Estudos brasileiros de RH mostram que mais de um terço dos empregadores registram desistências ainda antes do primeiro dia efetivo de trabalho. O custo médio por onboarding fracassado gira em torno de 75 mil reais (15 mil EUR / 16 mil USD) - sem contar a perda de produtividade do restante da equipe.

O problema não é falta de conhecimento sobre o que precisa ser feito. O problema é que ninguém rege.

## Oito áreas, nenhum maestro

Um único processo de onboarding envolve ao menos oito unidades organizacionais: RH prepara o contrato e transmite o S-2200 ao eSocial, TI provisiona hardware e acessos, Facilities prepara o posto de trabalho, a área contratante planeja a integração técnica, Compliance monta os treinamentos obrigatórios, o gestor escolhe um buddy, Finanças configura a folha e o Recepção precisa do nome para o crachá.

```
Contrato assinado
    |
    +-- RH: prontuário, eSocial S-2200, pacote de boas-vindas
    +-- TI: hardware, acessos, e-mail, VPN
    +-- Facilities: posto de trabalho, chave, vaga
    +-- Área de negócio: plano de integração, escolha do buddy
    +-- Compliance: treinamentos obrigatórios, LGPD (PT: RGPD), segurança do trabalho
    +-- Finanças: folha, reembolsos
    +-- Gestor: confirmar buddy, definir metas
    +-- Recepção: crachá, controle de acesso
    |
Primeiro dia de trabalho (tudo precisa estar pronto)
```

Cada uma dessas frentes tem prazos, sistemas e interlocutores próprios. Nenhuma delas sabe de forma confiável em que ponto as outras estão. O RH costuma coordenar tudo com uma checklist no Excel e e-mails de lembrete - um método que funciona com cinco admissões por mês, mas colapsa com cinquenta por trimestre.

## Por que checklists não escalam

Uma checklist diz: "Pedir equipamento de TI." Ela não diz qual equipamento é necessário para uma gestora de vendas em São Paulo comparada a uma desenvolvedora no Recife. Não diz que o pedido precisa de três semanas de antecedência e, por isso, deve sair no dia da assinatura do contrato - não quando o RH terminar o prontuário. Não diz quem será escalado se, após dez dias, o notebook ainda não chegou.

A verdadeira complexidade está na configuração: cada combinação de cargo, localidade, área e tipo de contrato gera um caminho de onboarding diferente. Uma empresa com três localidades, quatro áreas e dez tipos de cargo tem, em teoria, 120 variantes distintas de onboarding. Na prática, talvez cinco existam documentadas - o resto é improvisado.

## Nove das 14 etapas são baseadas em regras, três apoiadas por IA, duas permanecem humanas

O Onboarding Workflow Agent não é um chatbot que responde perguntas. É um motor de orquestração que conduz um processo definido, do contrato assinado até a conversa de feedback dos 30 dias.

Assim que um contrato é assinado, três coisas acontecem simultaneamente: o agente determina o tipo de onboarding a partir de um motor de regras, gera a checklist completa a partir do modelo adequado e distribui cada tarefa ao responsável com prazo concreto. A partir daí, monitora o progresso. Não passivamente, como um dashboard, mas ativamente - com lembretes quando o prazo se aproxima e escalação quando ele é ultrapassado.

A arquitetura de decisão por trás é deliberadamente conservadora. Das 14 etapas de decisão no processo, nove são baseadas em regras, três apoiadas por IA e duas permanecem com o ser humano. A IA é usada apenas onde padrões precisam ser reconhecidos - por exemplo, no match de buddies ou na personalização do pacote de boas-vindas. Se um buddy é aceito e se o onboarding ao final é considerado bem-sucedido, isso o gestor decide pessoalmente.

## Os custos ocultos da improvisação

A rotatividade precoce é o indicador visível. O menos visível: time-to-productivity. Estudos mostram que novos colaboradores levam entre 8 e 12 meses para atingir produtividade plena. Em onboarding caótico, essa fase se estende consideravelmente. Quando alguém passa três dias na primeira semana esperando acessos, esses não são três dias perdidos - são três dias em que uma primeira impressão equivocada se consolida.

90 por cento dos novos colaboradores decidem nos primeiros 100 dias se permanecem ou saem. Isso não é suposição - é a constatação central da pesquisa atual em onboarding. A decisão não acontece em um grande momento, mas em pequenos: meu e-mail funciona? Minha equipe sabe que eu cheguei? Alguém se preocupou com meu primeiro dia?

## Valor de infraestrutura além do onboarding

O motor de orquestração que o Onboarding Agent constrói não é um investimento pontual. A mesma arquitetura de modelos de checklist, distribuição de tarefas, monitoramento de prazos e lógica de escalação é diretamente reutilizada pelo Transfer & Relocation Agent, Offboarding Agent e Probation Management Agent. O framework de perfil de permissões forma a base para Access Management ao longo de todas as fases do ciclo de vida.

Mais importante ainda: cada execução de onboarding gera uma trilha de auditoria completa. Qual tarefa foi concluída quando, quem escalou, onde houve atrasos. A partir desses dados, surge ao longo do tempo um retrato de onde o processo trava sistematicamente - não baseado em intuição, mas em 200 execuções documentadas.

## Quando o agente se paga

A conta é simples. Com 100 admissões por ano e uma taxa de rotatividade precoce de 30 por cento, uma empresa perde 30 colaboradores ainda no período de experiência. A 75 mil reais por caso, são 2,25 milhões. Se um onboarding estruturado melhorar a retenção em 44 por cento - estimativa conservadora baseada em dados do setor - a rotatividade precoce cai para 17 casos. A economia: quase 1 milhão de reais (200 mil EUR / 220 mil USD) por ano.

Não contabilizado: a maior produtividade dos 83 colaboradores que ficam e se tornam operacionais mais rápido. Não contabilizado: o alívio do RH, que deixa de coordenar 100 processos por correntes de e-mail. Não contabilizado: o efeito reputacional quando novos colaboradores relatam um onboarding profissional.

--- Agente Contabilidade Folha ---
> Contabilidade da folha conforme CPC PME: provisões de férias e 13o, IFRS 19/IAS 19, Lei 6.404/76 art. 176-188 e integração eSocial S-1010/S-1200 - sem planilha de classificação manual.

A contabilidade da folha de pagamento no Brasil esbarra em vários marcos legais ao mesmo tempo. A Lei 6.404/76 define as demonstrações contábeis obrigatórias e a responsabilidade civil dos administradores. O CTN (art. 173 e 174) fixa a prescrição tributária em 5 anos e a Receita exige a escrituração digital (ECD e ECF). A CLT rege as provisões trabalhistas, como férias e 13o. O INSS e o FGTS impõem a contribuição patronal sobre a folha, e o CPC 33 governa o reconhecimento contábil dos benefícios a empregados. Na prática, um único lançamento da folha pode ativar todas essas obrigações de uma vez.

## Da folha aos lançamentos: o trabalho manual que abre a porta para a ressalva

Mapear 200 rúbricas da folha em 80 contas contábeis na planilha consome de 3 a 4 dias da Contabilidade a cada fechamento. As provisões de férias e 13o, calculadas em fórmulas de Excel, estão sujeitas a erro humano, e a contribuição patronal e o FGTS são recalculados todo mês. Na auditoria anual, o auditor independente encontra a divergência entre a folha e a contabilidade e o parecer sai com ressalva. E os riscos se somam: a Receita pode autuar com multa de 75% a 150% (Lei 9.430/96), a ANPD pode aplicar até 2% do faturamento e a responsabilidade civil sobre a escrituração recai sobre o contador.

## A obrigação contábil da Lei 6.404/76 e a responsabilidade dos administradores

A Lei 6.404/76 é o marco contábil brasileiro. Os artigos 176 a 188 tornam obrigatórias as demonstrações contábeis - balanço patrimonial, demonstração do resultado (DRE), demonstração dos fluxos de caixa e notas explicativas, entre outras. O artigo 187 detalha a estrutura da DRE, em que as despesas com pessoal, os encargos sociais e as provisões aparecem dentro das despesas operacionais. E o artigo 158 estabelece a responsabilidade civil dos administradores por atos praticados com violação da lei ou do estatuto. As Leis 11.638/2007 e 12.973/2014 completam o quadro, alinhando a escrituração brasileira ao padrão IFRS.

## A prescrição de 5 anos do CTN e a escrituração digital na Receita

O Código Tributário Nacional fixa os prazos da fiscalização: 5 anos de decadência para o lançamento do tributo (art. 173) e 5 anos de prescrição para a cobrança do crédito (art. 174). Dentro desse prazo, a Receita pode revisar toda a escrituração. Por isso ela exige a entrega digital: a ECD (Escrituração Contábil Digital, com livro diário e razão) e a ECF (Escrituração Contábil Fiscal, com a apuração do IRPJ e da CSLL). A falha na escrituração abre caminho para autuação, com multa de 75% a 150% (Lei 9.430/96) e, nos casos graves, processo penal tributário (Lei 8.137/90).

## As quatro categorias de benefícios do CPC 33

O CPC 33 (a versão brasileira do IAS 19, convergente ao IFRS) classifica os benefícios a empregados em quatro categorias: curto prazo (salários, encargos e as provisões de férias e 13o), pós-emprego (planos de previdência e assistência médica a aposentados), outros de longo prazo (licenças, jubileus) e benefícios de rescisão (indenizações e planos de demissão voluntária). No agente, as rúbricas da folha são classificadas automaticamente por categoria, com a segregação correta entre circulante e não-circulante no balanço, conforme a estrutura de contas da Lei 6.404/76 (art. 178).

## A integração com o eSocial: INSS, FGTS e o fechamento mensal

O eSocial (Decreto 8.373/2014) define os eventos da folha que se integram à contabilidade: a tabela de rúbricas (S-1010), a remuneração mensal (S-1200) e o fechamento dos eventos periódicos (S-1299), que apura as contribuições na DCTFWeb. Sobre a folha incidem a contribuição patronal ao INSS (20% mais RAT e Terceiros) e o FGTS (8%), recolhido mensalmente à Caixa Econômica Federal e guardado por 30 anos. O atraso no envio gera multa por evento.

## Como se encaixa na esteira de agentes de folha

Este agente opera em conjunto com os agentes vizinhos do domínio de folha. O agente de cálculo gera a folha bruto-líquido, que este aqui recebe e transforma em lançamentos contábeis, provisões e alocação de centros de custo. O agente de reporte consome esses lançamentos para os relatórios fiscais (DCTFWeb, EFD-Reinf, DIRF, RAIS) e, quando aplicável, para a divulgação à CVM. O agente de encargos sociais processa o INSS e o FGTS. Todos compartilham as mesmas referências - a Lei 6.404/76, o CTN, o CPC 33, o eSocial e a assinatura ICP-Brasil.

## Em resumo

- **13 etapas por regra (R):** validação da folha, mapeamento das rúbricas, alocação de centros de custo, cálculo da contribuição patronal e do FGTS, provisões de férias e 13o, cálculo do IRRF, geração dos lançamentos para a ECD, conciliação com a folha, sincronização com o eSocial, classificação pelo CPC 33 e auditoria periódica.
- **1 confirmação humana (H):** a validação e a assinatura dos lançamentos pelo contador habilitado, com validade ICP-Brasil e responsabilidade civil sobre a escrituração (Lei 6.404/76 art. 158).
- **Sem IA na decisão:** o perfil é de regras deterministas, sem nenhum passo decidido por modelo.
- **Retenção:** 5 anos para os documentos contábeis e trabalhistas (CTN, CLT e Lei 6.404/76) e 30 anos para o FGTS (Lei 8.036/90).

### Distribuição de Decisores

| Decisor | Quantidade | Percentual | Tipo de decisão |
|---------|------------|------------|--------------|
| R determinista (regras) | 13 | 92,9% | Validação, mapeamento, cálculo, provisão, geração, conciliação e sincronização |
| H confirmação humana | 1 | 7,1% | Validação do contador habilitado e assinatura ICP-Brasil |
| A indicador de IA | 0 | 0,0% | Não se aplica - perfil de regras deterministas |
| Total | 14 | 100% | Esteira contábil completa da folha |

--- Agente Processo HR Folha ---
> Processo HR da folha: cadastro funcionário, atualização CTPS Digital, eSocial S-2200/S-2299, workflows de dados e LGPD Art. 6 - pipeline de RH auditável sem cálculo Bruto-Líquido.

A folha de pagamento no Brasil se posiciona entre seis frentes de compliance que rodam em paralelo. A CLT (art. 457-467) define a remuneração, o prazo de pagamento e os descontos legais. As tabelas progressivas de IRRF (IN RFB 1.500/2014), de INSS (Lei 8.212/91, até o teto de R$ 7.786,02) e a alíquota de FGTS de 8% definem os tributos. A Lei 14.611/2023 trata da igualdade salarial. O eSocial (Decreto 8.373/2014) exige a transmissão dos eventos da folha, com multa por atraso de R$ 800 a R$ 2.500 por evento. E a LGPD impõe regras à decisão automatizada (art. 22). Na prática, um único cálculo de folha pode acionar essas seis obrigações ao mesmo tempo.

## Bruto-Líquido em segundos, sem a maratona de Excel

Mapear cerca de 200 verbas variáveis de 5.000 colaboradores em planilha consome de 3 a 4 dias do Departamento Pessoal em cada fechamento. Horas extras, adicional noturno (CLT art. 73), insalubridade (NR-15), periculosidade (NR-16) e DSR são calculados em fórmulas de Excel sujeitas a erro humano, com as tabelas de IRRF, INSS e FGTS refeitas todo mês e a data-base da CCT aplicada por e-mail circular.

As sanções acumuladas são pesadas. A RFB pode autuar de 75% a 150% do tributo (Lei 9.430/96 art. 44), com risco de processo penal tributário (Lei 8.137/90). A ANPD pode aplicar até 2% do faturamento, limitado a R$ 50 milhões (LGPD art. 52). A CGU pode chegar a 20% do faturamento (Lei 12.846/2013). E o MTE pode multar pela Reforma Trabalhista e pela Lei 14.611/2023. A tudo isso soma-se a responsabilidade civil do empregador de quitar o pagamento (CLT art. 466).

## CLT art. 457-467 e a tabela progressiva de IRRF

A CLT (Decreto-Lei 5.452/1943) define o marco da remuneração no Brasil: o salário e suas parcelas (art. 457 e 458), o prazo de pagamento até o 5º dia útil (art. 459), os descontos legais permitidos (art. 462) e a obrigação patronal de quitar o pagamento (art. 466).

A IN RFB 1.500/2014 fixa a tabela progressiva mensal de IRRF vigente em 2026: isento até R$ 2.428,80, depois 7,5% (dedução de R$ 182,16), 15% (R$ 394,16), 22,5% (R$ 675,49) e 27,5% (R$ 908,73), com dedução de R$ 189,59 por dependente. O INSS é dedutível e a previdência privada (PGBL/VGBL) tem limite de 12%. Auxílio-alimentação, vale-transporte e diárias de viagem são isentos. O imposto retido entra no eSocial (S-1210) e na DCTFWeb, com retenção de 5 anos (CTN art. 173).

## INSS, FGTS e a igualdade salarial da Lei 14.611/2023

A Lei 8.212/91 (com a Lei 8.213/91 e o Decreto 3.048/1999) define a contribuição previdenciária. A tabela progressiva do INSS do empregado em 2026 vai de 7,5% (até R$ 1.412) a 14% (de R$ 4.000,04 até o teto de R$ 7.786,02). Sobre a folha incidem ainda a contribuição patronal (CPP) de 20%, o RAT de 1% a 3% conforme o CNAE preponderante e os Terceiros (SESC, SENAC, SESI, SENAI, entre outros), em torno de 5,8%. O FGTS é de 8% sobre a folha, com multa rescisória de 40% a 80%.

A Lei 14.611/2023 e o Decreto 11.795/2023 criam a obrigação do Relatório de Transparência Salarial, enviado ao MTE semestralmente pelas empresas com 100 ou mais empregados, com análise do pay gap entre gêneros. A base é a vedação de discriminação salarial (CF/88 art. 7, inc. XXX) e a Súmula TST 6.

## eSocial S-1010, S-1200, S-1210 e a DCTFWeb

O eSocial (Decreto 8.373/2014) organiza os eventos da folha: a tabela de rúbricas (S-1010), a remuneração mensal com verbas, descontos e adicionais (S-1200), os pagamentos com data e valor líquido (S-1210) e o fechamento mensal que apura as contribuições na DCTFWeb (S-1299), além da admissão (S-2200) e do desligamento (S-2299). O atraso gera multa de R$ 800 a R$ 2.500 por evento, com retenção de 5 anos (CTN art. 173-174).

## CCT, ACT e convenções coletivas

O reconhecimento das convenções coletivas vem da CF/88 (art. 7, inc. XXVI) e da CLT (art. 8). A Reforma Trabalhista (Lei 13.467/2017, art. 611-A) trouxe o princípio do negociado sobre o legislado, e a Súmula TST 277 firma que a CCT ou o ACT incorpora o contrato individual. Essas convenções estabelecem o piso da categoria, os reajustes de data-base, os adicionais e os auxílios, além da PLR (Lei 10.101/2000). O agente aplica esses componentes de forma determinística e atualiza as rúbricas no eSocial (S-1010), com retenção de 5 anos.

## Conexão com Payroll-Accounting, Payroll-Reporting e Tax-Social-Insurance

Este agente integra-se aos agentes vizinhos do domínio Payroll-Compensation. Ele gera a saída da folha Bruto-Líquido - verbas, adicionais, descontos legais, INSS, IRRF e FGTS - que o Payroll-Accounting-Agent recebe e transforma em lançamentos contábeis, com provisões (CPC 33 e IAS 19) e a DRE (Lei 6.404/76). O Payroll-Reporting-Agent consome a folha e os lançamentos para os relatórios fiscais (DCTFWeb, EFD-Reinf, DIRF) e o Relatório de Transparência Salarial (Lei 14.611/2023). O Tax-Social-Insurance-Agent processa a contribuição patronal de INSS e FGTS junto à RFB. O ponto de consistência entre eles é a mesma base legal: CLT, IRRF, INSS, FGTS, eSocial e ICP-Brasil.

## De relance: 13 etapas determinísticas, 1 confirmação humana e 1 indicador de ML

- 13 etapas determinísticas (R): coleta das entradas e ingestão do ponto, identificação do conjunto de regras (IRRF, INSS, FGTS e CCT/ACT), validação de plausibilidade, sinalização de anomalias, cálculo Bruto-Líquido (CLT art. 457-467), aplicação dos componentes de CCT/ACT, processamento de pagamentos especiais (13º e PLR), geração da documentação com holerites em ICP-Brasil, sincronização com o eSocial, validação da igualdade salarial (Lei 14.611/2023) e auditoria periódica.
- 1 confirmação humana (H): resolução de anomalias pelo analista e aprovação da execução pelo responsável pela Folha, com assinatura em ICP-Brasil e responsabilidade civil do empregador (CLT art. 466).
- 1 indicador de ML (A): detecção de fraude (ghost employees, verbas inexistentes, horas extras infundadas), com revisão humana de auditor independente, do Compliance e do Jurídico antes de qualquer ação.
- Sanções acumuláveis de RFB, INSS, ANPD, CGU e MTE, somadas à responsabilidade civil do empregador (CLT art. 466), podem ultrapassar R$ 50 milhões.
- Retenção: 5 anos pelo CTN (art. 173-174) e pela CLT (art. 11); 30 anos para o FGTS (Lei 8.036/1990 art. 23).

### Distribuição de Decisores Payroll-Processing

| Decisor | Quantidade | Percentual | Tipo decisão |
|---------|------------|------------|--------------|
| R determinista (regras) | 13 | 86,7% | Coleta, identificação de regras, validação, sinalização, cálculo Bruto-Líquido, CCT/ACT, pagamentos especiais, documentação, sincronização com o eSocial, Lei 14.611/2023 e auditoria |
| H confirmação humana | 2 | 13,3% | Resolução de anomalias e aprovação da execução da folha, com assinatura em ICP-Brasil (CLT art. 466) |
| A indicador ML | 1 | 6,7% | Detecção de fraude, com revisão humana de auditor antes de qualquer ação |
| Total | 15 | 100% | Pipeline cálculo Bruto-Líquido folha completo |

--- Agente HR Reporting ---
> HR-Reports e dashboards: CSRD ESRS S1-9 Diversity, S1-10 Equal-Pay, S1-13 Compensation, Lei 14.611/2023 Igualdade Salarial e FTE-Statistik - automático sem maratona Excel.

## Da folha ao relatório - 90 por cento automático

Este agente segue o princípio do [Decision Layer](/br/decision-layer/): cada decisão é baseada em regras, assistida por IA ou explicitamente atribuída a um humano. Ele não é classificado como sistema de alto risco pelo [EU AI Act 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/oj), por usar regras determinísticas sem decisões de RH. Suas obrigações vêm do direito tributário e societário - [IN RFB 1.500/2014](https://www.gov.br/receitafederal/pt-br), CTN, INSS, FGTS, Lei 6.404/76, as normas NBC TG do CFC, a Lei 14.611/2023 e a LGPD - , com verificação obrigatória do auditor a partir de 250 empregados.

Um relatório de folha típico processa de centenas a milhares de itens por mês. Feitos à mão, os relatórios levam dias e estão sujeitos a erros. O agente gera em segundos, de forma determinística, a DIRF, a DCTFWeb, a EFD-Reinf, os eventos do eSocial, o Relatório de Transparência Salarial (Lei 14.611/2023) e os relatórios de ESG/CSRD (ESRS S1-13).

O problema não está no volume, e sim na cadeia auditável conforme a NBC TG: documentação de processos, duplo controle do Especialista de Folha e do Diretor Financeiro, trilha de auditoria com usuário, data e versão anterior, retenção de 5 anos pelo CTN, fiscalização da RFB e do MTE e amostragem do auditor (CFC). (PT: o equivalente em Portugal seria a Segurança Social Direta, a DMR e o Modelo 10; BR: aqui falamos especificamente do eSocial, da DCTFWeb e da EFD-Reinf.)

## DIRF, DCTFWeb e EFD-Reinf no e-CAC da RFB

A [IN RFB 1.500/2014](https://normas.receita.fazenda.gov.br/), com o Decreto 9.580/2018 (RIR), define as obrigações de reporte: a DIRF anual, a DCTFWeb mensal e a EFD-Reinf (escrituração fiscal digital de retenções).

Os prazos são fixos: a DIRF até 28 de fevereiro, a DCTFWeb até o dia 15 do mês seguinte e a EFD-Reinf mensalmente. Tudo é transmitido pelo e-CAC, com assinatura digital obrigatória em ICP-Brasil (MP 2.200-2 e Lei 14.063/2020).

A violação acarreta autuação da RFB de 75% a 150% do tributo (Lei 9.430/96 art. 44) e risco de processo penal tributário (Lei 8.137/90), além da responsabilidade dos administradores (Lei 6.404/76 art. 158). O CTN (art. 173-174) impõe 5 anos de prescrição tributária e arquivamento eletrônico. (PT: o equivalente em Portugal seria a multa da AT; BR: aqui falamos especificamente da RFB.)

## eSocial S-1010, S-1200 e S-1299 no fechamento mensal

O [eSocial (Decreto 8.373/2014)](http://www.planalto.gov.br/ccivil_03/_ato2011-2014/2014/decreto/d8373.htm), com o Manual de Orientação de 2024, estabelece os eventos obrigatórios da folha: a tabela de rúbricas (S-1010), a remuneração do trabalhador com verbas, descontos e adicionais (S-1200), os pagamentos com data e valor líquido (S-1210), o fechamento mensal que apura as contribuições na DCTFWeb (S-1299), a admissão (S-2200) e o desligamento (S-2299).

A RAIS foi substituída pelo S-1299 desde 2023 e o CAGED pelo eSocial; a DCTFWeb substituiu a GFIP. O atraso gera multa de R$ 800 a R$ 2.500 por evento, com retenção de 5 anos (CTN art. 173-174).

## Lei 14.611/2023 Relatório Transparência Salarial bianual MTE

A [Lei 14.611/2023](http://www.planalto.gov.br/ccivil_03/_ato2023-2026/2023/lei/l14611.htm) (Igualdade Salarial entre Mulheres e Homens), com o [Decreto 11.795/2023](http://www.planalto.gov.br/ccivil_03/_ato2023-2026/2023/decreto/d11795.htm) e a Portaria MTE 3.714/2023, estabelece obrigações concretas: o Relatório de Transparência Salarial bianual ao MTE para empresas com 100 ou mais empregados, o Plano de Ação para Igualdade Salarial quando há disparidades, e multa de 3 a 100 salários mínimos por trabalhador.

A Lei 14.611/2023 inova ao introduzir mecanismos de transparência salarial que vão além do art. 461 da CLT (que exige isonomia entre trabalhadores de igual valor, na mesma função e localidade). O procedimento é bianual, com prazos em março e setembro, publicação em local de fácil acesso e envio pelo Portal Emprega Brasil. As Súmulas TST 6, 442 e 277 complementam esse marco.

A Diretiva Europeia de Transparência Salarial (2023/970) tem efeito extraterritorial: empresas com sede no Brasil mas com operações na UE precisam cumprir ambos os marcos. A Lei 14.457/2022 (Programa Emprega Mais Mulheres) complementa o conjunto.

## CSRD ESRS S1-13, B3 ISE-B3 e GRI

A [CSRD](https://eur-lex.europa.eu/eli/dir/2022/2464/oj) (Diretiva UE 2022/2464), com efeito extraterritorial sobre multinacionais Brasil-UE, exige relatórios sociais nos padrões ESRS: indicadores de diversidade (S1-9), igualdade salarial (S1-10) e remuneração com mediana, média e quartis (S1-13). A verificação do auditor (CFC) é obrigatória a partir de 250 empregados, com aplicação escalonada de 2024 a 2026.

A base inclui a Diretiva Contábil da UE (2013/34), os padrões da EFRAG, o B3 ISE-B3 (Índice de Sustentabilidade Empresarial), o Código Brasileiro de Governança Corporativa e a GRI (Global Reporting Initiative).

No plano contábil, aplicam-se as normas NBC TG do CFC, a Lei 6.404/76 e o CPC 33 (Benefícios a Empregados), alinhado ao IAS 19. A Resolução CVM 80/2022 trata da divulgação da remuneração dos administradores nas companhias abertas.

## Cross-reference para Payroll-Processing e Payroll-Accounting

Este agente integra-se a um conjunto de agentes de RH especializados. O [Payroll-Processing-Agent](/br/catalogo-agentes-hr/payroll-processing-agent/) gera o cálculo Bruto-Líquido, com retenções de IRRF e contribuições de INSS, que servem de entrada para o reporte. O [Payroll-Accounting-Agent](/br/catalogo-agentes-hr/payroll-accounting-agent/) gera os lançamentos contábeis das folhas concluídas. O [Payroll-Tax-Agent](/br/catalogo-agentes-hr/payroll-tax-agent/) verifica a conformidade das retenções de IRRF. O [Compensation-Benchmarking-Agent](/br/catalogo-agentes-hr/compensation-benchmarking-agent/) fornece as faixas remuneratórias. O [Merit-Cycle-Governance-Agent](/br/catalogo-agentes-hr/merit-cycle-governance-agent/) transfere os ajustes salariais aprovados. O [Audit-Compliance-Agent](/br/catalogo-agentes-hr/audit-compliance-agent/) verifica a conformidade com a NBC TG do CFC. E o [HR-Document-Management-Agent](/br/catalogo-agentes-hr/hr-document-management-agent/) arquiva os relatórios pelos 5 anos de retenção do CTN.

## De relance

- **Classificação**: agente de apoio ao compliance, não de alto risco no EU AI Act (regras determinísticas)
- **Âncoras de compliance**: IN RFB 1.500/2014, CTN (art. 173-174), INSS (Lei 8.212/91), FGTS (Lei 5.107/66), Lei 14.611/2023, LGPD, Lei 6.404/76, normas NBC TG do CFC e ESG/CSRD (ESRS S1-13), com extraterritorialidade
- **Retenção**: 5 anos pelo CTN (art. 173-174) e pela CLT (art. 11); 30 anos para o FGTS (Lei 8.036/1990)
- **Consultas**: à CIPA e aos sindicatos (Lei 13.467/2017), obrigatórias
- **Sanções**: autuação da RFB de 75% a 150% do tributo, com risco penal tributário (Lei 8.137/90); ANPD de até 2% do faturamento (limitada a R$ 50 milhões); multa do MTE (Lei 14.611/2023); e Lei Anticorrupção (até 20% do faturamento)
- **Obrigação de auditoria**: verificação do auditor (CFC) obrigatória a partir de 250 empregados pela CSRD, mais a fiscalização da RFB e do MTE
- **Conexões**: Payroll-Processing, Payroll-Accounting e Pensions-Calculation

### Distribuição de Decisores Payroll-Reporting

| Passo | Decisor | Rationale |
|-------|---------|-----------|
| Geração da DIRF, DCTFWeb e EFD-Reinf | R | Tabelas de IRRF e e-CAC, de forma determinística |
| eSocial S-1010, S-1200 e S-1299 | R | Decreto 8.373/2014 e Manual de 2024, de forma determinística |
| INSS na DCTFWeb (substitui GFIP/GPS) | R | Lei 8.212/91 e Decreto 3.048/1999, de forma determinística |
| FGTS (GRF, GRRF e Conectividade Social) | R | Lei 5.107/66 e Lei 8.036/1990, de forma determinística |
| Lei 14.611/2023 (Transparência Salarial) | R | Decreto 11.795/2023 e Portaria MTE 3.714/2023, de forma determinística |
| CSRD ESRS S1-13 | R | Diretiva Contábil da UE e EFRAG, com extraterritorialidade |
| B3 ISE-B3 e GRI (reporte anual) | R | Código Brasileiro de Governança Corporativa, de forma determinística |
| Detecção de anomalias | A | ML de detecção de anomalias, com validação humana |
| Aprovação do Diretor Financeiro | H | Duplo controle exigido pela NBC TG |
| Envio à RFB, INSS, MTE, ANPD e B3 | R | Assinatura em ICP-Brasil, de forma determinística |
| Retenção de 5 anos e LGPD art. 17 | R | CTN (art. 173-174) e ciclo de vida, de forma determinística |
| Lei 12.846/2013 (Anticorrupção) | H | Normas ABNT NBR ISO 37301 e 37001, obrigatórias |
| LGPD art. 33 (72 horas) e ANPD | R | Resolução CD/ANPD 18/2024, de forma determinística |
| SPED, ECD, ECF e e-LALUR | R | Decreto 6.022/2007, de forma determinística |

--- People Analytics Agent ---
> Analisa turnover, engajamento, diversidade e movimentação de talentos em padrões e tendências. Alto risco sob PL 2338/2023.

## O RH tem os dados. Só não consegue transformá-los em decisões

O RH possui os dados que poderiam sustentar decisões estratégicas de pessoal. Turnover por área, engajamento por localidade, diversidade por nível hierárquico. Mas apenas 8 por cento das empresas relatam que seus dados de RH são realmente utilizáveis (Deloitte, Human Capital Trends). O restante exporta planilhas, constrói apresentações ao longo de semanas e entrega respostas que chegam tarde, ficam na superfície e erram a pergunta essencial.

O problema não é a falta de dados. É a falta de arquitetura. Quem pratica people analytics sem separar estruturalmente análise de vigilância não obtém nem a aceitação do Sindicato nem a conformidade com o PL 2338/2023.

## Por que people analytics costuma travar na prática

76 por cento de todas as empresas praticam alguma forma de people analytics. Mas apenas 9 por cento compreendem quais dimensões de talento de fato impulsionam desempenho (Deloitte, 2024). Entre os dados que o RH possui e o que desses dados chega às decisões estratégicas existe um abismo. Três causas o mantêm aberto.

**Base de dados fragmentada.** Dados cadastrais vivem no SAP ou no sistema de folha, escores de engajamento em uma ferramenta de pesquisa, motivos de turnover em planilhas dos gestores. A integração de dados figura regularmente entre os maiores obstáculos da digitalização de RH em pesquisas da EY. O dano oculto: a má qualidade de dados impõe retrabalho, consome capacidade e distorce qualquer análise que se apoie nela - muitas vezes de forma mais grave do que a ausência de ferramentas analíticas.

**Ausência de tradução para a linguagem da decisão.** O RH reporta headcount, taxa de absenteísmo, dias de treinamento. A diretoria pensa em receita por pessoa, time-to-market, churn de clientes. Enquanto o turnover não estiver vinculado ao seu custo econômico consequente, o people analytics continua sendo relatório administrativo. A Best Buy quantificou essa conexão: 0,1 ponto a mais em engajamento correlacionou-se a 500 mil reais (100 mil USD / 92 mil EUR) adicionais de receita por loja. A maioria dos departamentos de RH não consegue estabelecer tais vínculos - não por falta de dados, mas porque ninguém definiu quais vínculos são estrategicamente relevantes.

**Mistura de análise com vigilância.** People analytics deveria identificar padrões em dados agregados. Mas, sem fronteiras técnicas claras, a análise desliza imperceptivelmente para o monitoramento do desempenho individual. O Sindicato bloqueia. A base desconfia. O projeto não morre por falha técnica, mas por perda de confiança.

## Alto risco sob o PL 2338/2023 - a realidade regulatória

O PL 2338/2023 classifica sistemas de people analytics como potencialmente de alto risco porque envolvem monitoramento e avaliação de padrões de comportamento no ambiente de trabalho. Ainda que o agente analise exclusivamente de forma agregada, os resultados podem influenciar decisões de pessoal. Isso é suficiente para a classificação.

Sistemas de alto risco precisam atender aos seguintes requisitos:

- Sistema de gestão de riscos com avaliação de impacto documentada
- Requisitos de qualidade de dados e documentação técnica
- Transparência perante os colaboradores afetados
- Supervisão humana por pessoas tecnicamente competentes
- Avaliação de conformidade e registro adequados

Em paralelo, aplica-se a LGPD (PT: RGPD). O artigo 20 garante ao titular o direito à revisão de decisões automatizadas. A análise sistemática de dados de colaboradores exige Relatório de Impacto à Proteção de Dados (RIPD) conforme o artigo 38. E os direitos de negociação coletiva do Sindicato aplicam-se a sistemas que monitoram comportamento - informação prévia aos representantes dos trabalhadores é obrigatória antes da implantação.

Quem não conecta esses três marcos jurídicos constrói um sistema que funciona tecnicamente e é insustentável juridicamente.

## O que a arquitetura resolve e a tecnologia sozinha não

A questão central não é: qual ferramenta analisa os dados? É: quem define a pergunta, quem interpreta o resultado, quem decide?

O [Decision Layer](/br/decision-layer/) decompõe o processo de analytics em etapas de decisão discretas. Cada etapa tem um responsável definido: humano, motor de regras ou agente de IA.

```
Definir            Verificação         Agregar             Identificar
pergunta      -->  LGPD           -->  dados          -->  padrões
(humano)           (motor de regras)   (motor de regras)   (agente)

Validar            Recomendações      Apresentar
achados       -->  acionáveis     --> resultados
(humano)           (agente)            (agente)
```

A separação não é formalismo. Resolve o problema central no qual o people analytics falha na prática.

**Etapa 1: definir a pergunta (humano).** Analytics sem pergunta estratégica produz relatórios que ninguém pediu. O processo só começa quando a liderança de RH ou a diretoria prepara uma decisão concreta: precisamos de um programa de retenção em vendas? A diferença de engajamento entre localidades está aumentando?

**Etapa 2: verificação LGPD (motor de regras).** Antes que um único ponto de dado seja agregado, o motor de regras verifica a análise planejada contra a LGPD, acordo coletivo e diretrizes internas. Análises sem base legal não iniciam.

**Etapa 3: agregar dados (motor de regras).** Dados cadastrais, escores de engajamento e dados de turnover são combinados e anonimizados. Grupos abaixo de um tamanho mínimo definido são consolidados. Isso não é diretriz, é bloqueio técnico: conclusões pessoais são impossíveis porque a arquitetura as impede.

**Etapa 4: identificar padrões (agente).** O agente identifica correlações, tendências e outliers nos dados agregados. Onde o turnover sobe mais rápido do que a média da empresa? Quais áreas mostram engajamento em queda com, simultaneamente, aumento de horas extras? Modelos preditivos identificam áreas em risco 60 a 90 dias antes de as rescisões acontecerem.

**Etapa 5: validar achados (humano).** Um padrão estatístico não é causa. A queda de satisfação na área X correlaciona-se com a reestruturação do último trimestre - ou com a troca de liderança? O especialista de HR analytics verifica significância, plausibilidade e contexto. O agente fornece a evidência. A interpretação é feita por um humano com conhecimento de domínio.

**Etapas 6-7: recomendações e apresentação (agente).** O agente formula recomendações acionáveis, com indicação de confiança, e as prepara para consumo pela gestão. Não são 40 indicadores em um dashboard, mas três a cinco achados vinculados a impacto de negócio e opções concretas.

## A fronteira entre análise e vigilância é uma decisão arquitetural

Nenhum problema de confiança é resolvido por um dashboard melhor. A aceitação do people analytics depende de a fronteira entre reconhecimento de padrões em dados agregados e avaliação de colaboradores individuais não apenas ser prometida, mas tecnicamente imposta.

Três princípios arquiteturais garantem isso:

**Agregação como bloqueio técnico.** Tamanhos mínimos de grupo não são definidos como política, mas implementados como parâmetro de sistema. Uma análise com grupo-base muito pequeno não entrega resultado algum - não um aviso, mas nenhuma saída.

**Sem retrocálculo para indivíduos.** A lógica de anonimização impede que a combinação de múltiplas análises agregadas torne pessoas identificáveis. Isso é matematicamente solucionável e tecnicamente implementável - mas apenas se ancorado na arquitetura desde o início.

**Registro de decisão completo.** Cada análise é documentada: pergunta, base legal, nível de agregação, resultado, medida derivada. O Sindicato tem direito de consulta. Colaboradores afetados podem compreender quais análises foram executadas e quais decisões se baseiam nelas.

Esse framework é, ao mesmo tempo, o acordo coletivo. Quem documenta a arquitetura com clareza já tem estruturado o resultado da negociação com o Sindicato. Fronteiras claras aumentam a aceitação e reduzem riscos de governança - isso não é compromisso, é vantagem estratégica.

## Infraestrutura que vai além do agente individual

O motor de análise que nasce aqui - turnover, engajamento, equidade - é reutilizado pelo Strategic HR Analytics Agent para reporte ao board e pelo Merit Cycle Governance Agent para análise de remuneração. A lógica de anonimização e de tamanhos mínimos de grupo torna-se padrão para todo agente que processa dados pessoais. O framework de governança - o que pode ser analisado, o que não pode, sob quais condições - forma a base para todos os agentes de alto risco do quadrante H4.

O valor real não está nos resultados analíticos de um trimestre específico. Está na infraestrutura que transforma o people analytics de risco de governança em ferramenta de governança: rastreável, contestável, repetível. Organizações que atingem esse grau de maturidade tomam decisões baseadas em dados mais rapidamente e, segundo o Deloitte Human Capital Trends, apresentam probabilidade mensuravelmente maior de desempenho acima da média na comparação com concorrentes.

--- Performance Review Documentation Agent ---
> Gerencia documentação de avaliação de desempenho com trilha de auditoria completa. Alto risco sob PL 2338/2023.

## A avaliação raramente é o problema. A documentação, sim.

Este agente segue o princípio do [Decision Layer](/br/decision-layer/): cada decisão é baseada em regras, assistida por IA ou atribuída explicitamente a uma pessoa.

Gestores sabem avaliar desempenho. O que não sabem: converter um ano de observações em um registro consistente, fundamentado e juridicamente defensável. O resultado é um processo de documentação que produz sistematicamente contradições - entre nota e justificativa, entre autoavaliação e percepção externa, entre o que foi dito na conversa e o que está no arquivo.

Isso não é um problema de qualidade de gestores individuais. É um problema estrutural. E vira risco jurídico no momento em que uma rescisão, uma promoção negada ou uma ação trabalhista se apoia exatamente nesse registro.

## Três padrões que permanecem invisíveis no processo manual

**Divergência entre nota e texto.** Um gestor atribui "superou expectativas", mas escreve na justificativa três parágrafos sobre necessidade de melhoria. Ou o inverso: "atendeu parcialmente" com uma justificativa que enumera apenas pontos fortes. Pesquisas mostram que mais de 60 por cento da variância em avaliações de desempenho vem do avaliador - não da pessoa avaliada. Em casos isolados, a discrepância chama atenção. Em 200, 500 ou 1.000 avaliações por ciclo, não chama - porque ninguém lê todos os documentos.

**Recency bias como lacuna de documentação.** Recency bias é considerado o erro de avaliação mais frequente. Gestores que não mantêm anotações contínuas - e a grande maioria não mantém - reconstroem 12 meses de desempenho a partir das últimas seis semanas. O projeto que foi excepcional em fevereiro não existe mais em dezembro. O erro de novembro domina toda a avaliação. A documentação não retrata desempenho. Retrata memória.

**Viés de avaliação que desaparece em dados individuais.** Quando um gestor avalia quatro mulheres da equipe com "atende expectativas" e quatro homens com "supera expectativas", isoladamente não chama atenção. Talvez até corresponda ao caso específico. Mas, se esse padrão se reproduz em 30 equipes, deixa de ser acaso. Pesquisa da HBR mostra: 61 por cento das mulheres recebem feedback sobre seu estilo de comunicação - entre homens, o valor é de 1 por cento. Padrões assim não são manualmente detectáveis, porque só aparecem na agregação.

## Por que formulários melhores não resolvem o problema

O reflexo natural: modelos mais estruturados, campos obrigatórios, frases pré-formatadas. Mas um formulário não consegue verificar se a justificativa corresponde à nota. Não consegue identificar se a autoavaliação de um colaborador diverge sistematicamente da percepção externa. Não consegue detectar se um gestor copia as mesmas formulações há três ciclos. E não consegue analisar, em 40 equipes, se padrões de avaliação se diferenciam por gênero, idade ou condição de tempo parcial.

A tarefa não é melhorar o formulário. É decompor o processo de avaliação de forma que cada etapa tenha atribuição clara: quem decide? Sob qual regra? Com qual verificação?

## Onze etapas, três princípios de decisão

```
Iniciar            Distribuir          Autoavaliação       Gestor
ciclo         -->  formulários    -->  coletada       -->  avalia
(R: calendário)    (R: atribuição)     (R: regras)         (H: observação)

Verificação        Apoio à             Análise             Escalação
consistência  --> calibração      --> de viés         --> de achados
(A: nota/texto)    (A: distribuição)   (A: estatística)    (R: limiar)

Agendar            Documentar          Acionar ações
conversa      -->  resultado      --> subsequentes
(A: calendário)    (R: arquivamento)   (R: regras)
```

A diferença decisiva em relação ao processo manual: as etapas 5, 6 e 7 ocorrem paralelamente à avaliação, não depois. Quando um gestor atribui nota e registra a justificativa, a consistência entre ambas é verificada imediatamente. A visão de calibração se atualiza em tempo real. A análise de viés calcula continuamente se padrões estão se formando.

Isso muda o caráter da sessão de calibração. Em vez de comparar notas em retrospecto, os gestores veem, ao inserir, onde sua avaliação se posiciona no contexto: distribuição na equipe, desvio da média da área, consistência com ciclos anteriores. A conversa migra de "vamos votar em notas?" para "onde nos afastamos conscientemente do padrão e por quê?"

## Verificação de consistência como vantagem estrutural

A verificação automática de coerência entre nota e texto justificativo não é recurso de conveniência. É a principal razão pela qual a orquestração baseada em regras é superior ao processo manual. Um humano que lê 400 formulários de avaliação não consegue identificar sistematicamente onde palavra e número divergem. O agente detecta a contradição imediatamente e a marca - não em um relatório que chega semanas depois na mesa, mas enquanto o gestor ainda está no processo de avaliação e pode corrigir.

Para empresas sob o regime de alto risco do PL 2338/2023 - aplicável a sistemas que avaliam desempenho e comportamento no ambiente de trabalho - rastreabilidade não é opcional. É exigência legal. Sistema de gestão de riscos, transparência perante afetados e supervisão humana não são adicionados depois. Estão na arquitetura: a avaliação permanece com o ser humano. O agente documenta, verifica e analisa.

## O que resta no final

O agente não realiza nenhuma avaliação de desempenho. Ele garante que cada avaliação esteja fundamentada de forma consistente, documentada integralmente e verificada contra padrões sistemáticos. A nota é dada pelo gestor. A conversa é conduzida por um ser humano. A calibração é responsabilidade da liderança de RH.

A infraestrutura criada nesse processo - motor de consistência, análise de viés, framework de calibração, arquivamento auditável - não é construída para um único ciclo de avaliação. A análise de viés é reutilizada pelo Merit Cycle Governance Agent e pelo Promotion Process Agent. O padrão de verificação de consistência torna-se padrão para todo agente que verifica avaliações humanas quanto à coerência. O registro de decisão gerado por avaliação torna cada julgamento individual rastreável e contestável - tanto para a pessoa afetada quanto para o sindicato.

--- Agente Documentos de Política ---
> Ciclo de vida de políticas RH: CLT art. 461 isonomia, LGPD art. 22 decisão automatizada e Lei 14.457/2022 anti-assédio - Single-Source-of-Truth em vez de 60 PDFs com versionamento.

A gestão de políticas de RH no Brasil se posiciona entre seis frentes de compliance que rodam em paralelo. A CLT trata da isonomia salarial (art. 461) e do negociado sobre o legislado (art. 611-A, com a Lei 13.467/2017). A Lei 14.611/2023 exige o Relatório de Transparência Salarial, com multa de 3% da folha, limitada a 100 salários mínimos. A LGPD regula a decisão automatizada (art. 22), como a consulta dos colaboradores por IA. A Lei 12.846/2013 impõe o Programa de Integridade, e a Lei 14.457/2022 torna obrigatório o canal de denúncia. A isso soma-se o reporte de ESG/CSRD. Na prática, uma única política pode acionar essas seis obrigações ao mesmo tempo.

## De 60 versões PDF a uma única Single-Source-of-Truth central

Uma empresa com 1.500 colaboradores mantém tipicamente de 40 a 80 políticas internas: o regulamento interno, o código de ética, as políticas de privacidade (LGPD), de home office, de viagens, de frota, de assédio (Lei 14.457/2022) e de igualdade salarial (Lei 14.611/2023), além do manual do colaborador. Cada política precisa estar atualizada, acessível e comprovadamente conhecida. Na prática, ao menos uma dessas quatro condições quase sempre está quebrada. O problema não é a ausência de políticas, mas o sistema que as administra, que é da década passada. Uma pasta SharePoint com 200 arquivos, dos quais 40 chamados "final_v3_NOVO". Um e-mail de novembro com o assunto "Política de viagens atualizada" que ninguém abriu. Um acordo coletivo sobre trabalho remoto preso num loop de revisões entre jurídico, sindicato e diretoria. O resultado: o RH responde às mesmas perguntas repetidamente, os colaboradores agem com base em versões desatualizadas sem saber e, quando surge um litígio, falta a prova de que a versão vigente foi comunicada.

## Verificação de conformidade com a CLT art. 461, a Lei 14.611/2023 e a Súmula TST 6

O ponto mais crítico do agente é a verificação automatizada da conformidade de cada política com a isonomia salarial da CLT art. 461 - mesmo trabalho e mesma remuneração, na mesma localidade, com diferença de tempo de serviço não superior a 4 anos. A Súmula TST 6 detalha a equiparação salarial, e a Súmula TST 401 estabelece a inversão do ônus da prova em ação por discriminação. A Lei 14.611/2023 cria o Relatório de Transparência Salarial bianual para empresas com 100 ou mais empregados, com multa de 3% da folha (limitada a 100 salários mínimos). Somam-se a vedação de práticas discriminatórias (Lei 9.029/1995) e a cota e a acessibilidade da LBI (Lei 13.146/2015). O agente confere cada política proposta contra essa matriz antes da aprovação e bloqueia a publicação se a conformidade não é verificada, escalando o caso ao Jurídico e ao Compliance.

## CIPA, sindicatos e a Lei 13.467/2017

Cada mudança de política em empresa com representação sindical percorre ao menos quatro estações: a área funcional formula, o jurídico revisa, o sindicato é consultado e a diretoria aprova. Dependendo do tema, juntam-se o Encarregado (DPO), a CIPA (ampliada pela Lei 14.457/2022 para casos de assédio), o Compliance e consultores externos. A base legal é a negociação coletiva (CLT art. 8 e 611), o negociado sobre o legislado (Lei 13.467/2017 art. 611-A) e a Súmula TST 277. Uma regra de home office toca, ao mesmo tempo, jornada, saúde e segurança e modalidade de trabalho, e cada tema pode abrir uma negociação própria. Sem orquestração, a atualização leva de 3 a 6 meses, e nesse período vigora a versão antiga ou nenhuma. O agente roteia o fluxo de aprovação aos revisores obrigatórios por tipo de política, monitora prazos e sinaliza atrasos antes que se tornem críticos.

## Consulta dos colaboradores e a LGPD art. 22

A quarta função é a mais visível: responder a consultas sobre políticas. Um colaborador pergunta se há licença especial para mudança de endereço dentro da cidade. O agente encontra o trecho relevante na versão vigente do acordo coletivo, responde com a referência (cláusula, versão e data de vigência) e classifica a pergunta como factual (resposta direta) ou interpretativa (encaminhada ao Departamento Pessoal). A LGPD art. 22 dá ao titular o direito de pedir a revisão da decisão automatizada por uma pessoa natural; por isso o agente entrega a resposta como indicador, o colaborador pode contestar e o caso é escalado ao Departamento Pessoal. A DPIA (LGPD art. 35) é obrigatória, com consulta ao Encarregado (DPO, art. 38) e trilha de auditoria completa. Isso não apenas reduz o volume de consultas: muda a qualidade das que restam. Em vez de responder a 30 perguntas idênticas sobre cota de home office, o RH dedica-se aos 3 casos que de fato exigem julgamento. (PT: o equivalente em Portugal seria a CNPD e o art. 22 do RGPD; BR: aqui falamos da ANPD e do art. 22 da LGPD.)

## Retenção de 5 anos, FGTS de 30 anos e versionamento do ciclo de vida

Cada política aprovada recebe um número de versão semântico, com data de início de vigência e data final opcional. As versões antigas são arquivadas, não excluídas. Em qualquer consulta, o sistema entrega a versão vigente no momento aplicável ao caso concreto, não a mais nova: um colaborador que pergunta sobre o reembolso de viagem de fevereiro recebe a política que vigorava em fevereiro. A retenção é de 5 anos pela CLT (art. 11) e pelo CTN (art. 173-174) e de 30 anos para o FGTS (Lei 8.036/1990 art. 23); pela LGPD art. 25, apenas os dados pessoais associados são eliminados ao fim do tratamento, não a política em si. O documento eletrônico tem a mesma validade do físico (Súmula TST 387), com armazenamento cifrado pelo HR-Document-Management-Agent e assinatura em ICP-Brasil (MP 2.200-2 e Lei 14.063/2020).

## Conexão com HR-Document-Management e Audit-Compliance

Dois dos três componentes centrais deste agente - o motor de versionamento e o fluxo de aprovação - são infraestrutura genérica. Todo agente do Decision Layer que aplica regras precisa de documentos versionados com períodos de vigência, e todo agente que orquestra aprovações em vários níveis precisa de um motor de fluxo com monitoramento de prazos. O Compliance-Monitoring-Agent verifica dados operacionais contra regulamentos que precisam estar versionados; o Works-Council-Coordination-Agent conduz processos de participação que seguem a mesma lógica de aprovação; o Audit-Compliance-Agent precisa de comprovantes que o rastreamento de ciência fornece; e o HR-Document-Management-Agent referencia as políticas vigentes. Quem começa por este agente não remodela apenas a gestão de políticas: instala a infraestrutura para toda decisão baseada em regras que um agente posterior tomará. As sanções, no entanto, são acumuláveis e podem ultrapassar R$ 50 milhões - ANPD de até 2% do faturamento, multa da Lei 14.611/2023 e CGU de até 20% do faturamento (Lei 12.846/2013).

## De relance

- Versionamento semântico das políticas, com períodos de vigência e arquivamento histórico (sem exclusão)
- Fluxo de aprovação orquestrado, com revisores obrigatórios por tipo de política e consulta ao sindicato (Lei 13.467/2017 art. 611-A e Súmula TST 277)
- Verificação automatizada de conformidade com a CLT art. 461, a Súmula TST 6, a Lei 14.611/2023 e a LBI
- Rastreamento da confirmação de leitura ("li e concordo"), com validade do documento eletrônico (Súmula TST 387) e retenção de 5 anos (CLT art. 11)
- Resposta às consultas dos colaboradores com classificação por ML (factual ou interpretativa), sob a LGPD art. 22 e a DPIA (art. 35)
- Monitoramento contínuo de conformidade, com alerta para mudanças legislativas (Programa de Integridade, Decreto 11.129/2022)
- Sanções acumuláveis de até R$ 50 milhões: ANPD de até 2% do faturamento, multa da Lei 14.611/2023 e CGU de até 20% do faturamento

### Distribuição de Decisores Policy-Document

| Decisor | Quantidade | Etapas |
| --- | --- | --- |
| R (regra determinística) | 12 | Recebimento e classificação, verificação de conformidade (CLT e Lei 14.611/2023), detecção de dependências, roteamento do fluxo, consulta ao sindicato, coleta de feedback, versionamento, publicação, rastreamento de leitura, monitoramento de conformidade, revogação e auditoria periódica |
| A (indicador ML assistido) | 1 | Resposta à consulta do colaborador, com classificação da pergunta como factual ou interpretativa |
| H (confirmação humana) | 2 | Aprovação da política, com assinatura em ICP-Brasil pela Diretoria e pelo Conselho, e escalonamento dos casos de julgamento ao Encarregado (DPO), ao Compliance e ao Jurídico |

--- Agente Due Diligence Pré-Contratação ---
> Background checks pré-contratação: Lei 13.965/2019 antecedentes criminais, LGPD art. 11 dados sensíveis e EU AI Act Anexo III(4)(a) - mitigação Mobley v. Workday com KYC PEP UBO.

A due diligence de pré-contratação no Brasil se posiciona entre sete frentes de compliance que rodam em paralelo. A CLT trata da isonomia salarial (art. 461), da justa causa por falsidade ideológica (art. 482) e do cargo de confiança (art. 224, § 2º). A Lei 13.965/2019 prevê o atestado de antecedentes pelo gov.br, com validade de 90 dias. A LGPD regula os dados sensíveis (art. 11) e a decisão automatizada (art. 22). O EU AI Act enquadra a avaliação de candidatos como alto risco (Anexo III(4)(a)), com auditoria de viés. A Lei de Migração (Lei 13.445/2017) trata da verificação de visto, a Lei Anticorrupção (Lei 12.846/2013) do KYC, e a LBI (Lei 13.146/2015) dos ajustes razoáveis e da cota de PCD. Na prática, uma única contratação pode acionar essas sete obrigações ao mesmo tempo, com prazo realista de 3 a 7 dias em paralelo no lugar de 14 a 22 sequenciais.

## O background check entre a obrigação de compliance e a armadilha da CLT art. 461

Levantamentos intersetoriais mostram que cerca de um terço das candidaturas contém informações falsas. Segundo a pesquisa Resume Builder de janeiro de 2025, 44% dos entrevistados admitiram ter mentido no processo seletivo e 24% diretamente no currículo. A IA generativa produz cartas, referências e certificados em minutos, e o precedente Mobley v. Workday (EUA, 2023-2024) deixa claro que não há mais a opção da "verificação superficial". Por outro lado, o princípio da necessidade (LGPD art. 6, inc. III), a vedação de discriminação (Lei 9.029/1995) e a Súmula TST 6 impõem limites ao que pode ser checado. (PT: em Portugal, a regra equivalente seria o princípio da minimização do art. 5 do RGPD; BR: aqui falamos do art. 6, inc. III, da LGPD.)

## EU AI Act Anexo III(4)(a): alto risco, DPIA, FRIA e o caso Mobley v. Workday

O EU AI Act (Anexo III(4)(a)) classifica como alto risco os sistemas de IA para avaliação de pessoas, o que inclui o escore de background check e a classificação de risco do candidato. As obrigações dos arts. 9 a 15 - entre elas a auditoria de viés, a supervisão humana (art. 14), a DPIA (LGPD art. 35) e a FRIA (art. 27) - aplicam-se a empresas brasileiras com presença na UE ou nos EUA, com multas de até 35 milhões de euros ou 7% do faturamento global. O caso Mobley v. Workday provou que a auditoria de viés não pode ser delegada a um sistema automatizado sem supervisão humana. Para a empresa brasileira em grupo multinacional, o agente deve documentar a auditoria de viés periódica, com o Encarregado (DPO), o Compliance e o auditor independente, e reter a documentação por 10 anos. (PT: o equivalente seria a CNPD; BR: a ANPD.)

## Lei 13.965/2019: antecedentes criminais e o cargo de confiança da CLT art. 224

A Lei 13.965/2019 estabelece o atestado de antecedentes criminais pelo gov.br, integrado à Polícia Federal e com validade de 90 dias. O cargo de confiança (CLT art. 224, § 2º) exige due diligence ampliada, assim como os cargos sensíveis nas áreas financeira (BCB, CVM, B3), de saúde (CFM, COREN) e de educação infantil. Para os demais cargos, solicitar o atestado pode configurar discriminação (Lei 9.029/1995) e violar a minimização de dados (LGPD art. 6, inc. III). A Súmula 444 do STJ garante a admissão de boa-fé, com presunção de inocência até o trânsito em julgado. O agente decide por regras a partir da matriz de permissibilidade por cargo, bloqueia a solicitação sem justificativa documentada e a escala ao Encarregado (DPO), ao Compliance e ao Jurídico. A falsidade ideológica configura justa causa (CLT art. 482), com responsabilidade civil do empregador por atos de terceiros (Código Civil art. 932, III).

## Lei 13.445/2017: visto, RNE e a integração com a CTPS Digital

A Lei de Migração (Lei 13.445/2017 e Decreto 9.199/2017) estabelece o marco da verificação de visto: a classificação como diplomático, temporário ou permanente e o registro do RNM e do RNE junto ao Departamento de Imigração e à Polícia Federal. A CTPS Digital integra-se automaticamente ao evento de admissão do eSocial (S-2200), junto ao atestado de antecedentes (Lei 13.965/2019). O agente verifica o visto, bloqueia o processo se ele é inválido e o escala ao Recrutamento, ao Jurídico e ao Encarregado (DPO), com retenção de 5 anos (CLT art. 11). Para o candidato estrangeiro, há ainda a transferência internacional de dados (LGPD art. 33). (PT: o equivalente seria o SEF, Serviço de Estrangeiros e Fronteiras; BR: o Departamento de Imigração e a Polícia Federal.)

## LGPD art. 11, consentimento granular e minimização de dados

A LGPD art. 11 exige base legal específica para o background check, com consentimento granular, finalidade específica e minimização (art. 6, inc. III), além do direito de revisão da decisão automatizada (art. 22). A ANPD pode aplicar sanção de até 2% do faturamento, limitada a R$ 50 milhões. Na prática, o consentimento é granular por tipo de verificação (certificados, referências, antecedentes, KYC e visto), assinado em ICP-Brasil (MP 2.200-2 e Lei 14.063/2020), com dados cifrados em AES-256, trilha de auditoria e retenção de 5 anos (CLT art. 11). A intimidade, o sigilo e o habeas data (CF/88 art. 5) completam o marco constitucional.

## Conexão com Candidate-Screening, Interview-Scheduling e Contract-Offer-Generation

Este agente verifica referências com humanos, valida certificados (e-MEC, Capes e conselhos profissionais), solicita o atestado de antecedentes (Lei 13.965/2019), checa o visto (Lei 13.445/2017) e faz o KYC, sob a LGPD art. 11. O Interview-Scheduling-Agent cuida da agenda e das perguntas vedadas na entrevista (Súmula TST 6 e Lei 9.029/1995). O Candidate-Screening-Agent faz o escore por ML e a classificação automatizada, sob a LGPD art. 22 e a auditoria de viés. O Contract-Offer-Generation-Agent gera os contratos com as cláusulas obrigatórias da CLT (art. 442). E a infraestrutura construída aqui é reutilizada pelo Certification-Tracking-Agent, pelo Audit-Compliance-Agent e pelo Performance-Review-Documentation-Agent.

## De relance

- Marco legal: CLT (art. 461, 482 e 224, § 2º), Lei 13.965/2019, LGPD art. 11, EU AI Act (Anexo III(4)(a)), Lei 13.445/2017, Lei 12.846/2013 e LBI (Lei 13.146/2015)
- Validação de certificados pelo e-MEC, INEP, Capes e conselhos profissionais, com Apostila de Haia para diplomas estrangeiros
- Atestado de antecedentes (Lei 13.965/2019), com validade de 90 dias, para cargo de confiança (CLT art. 224) e respeito à Súmula 444 do STJ
- Verificação de visto (Lei 13.445/2017), com RNE e CTPS Digital integrada ao eSocial (S-2200)
- Proteção de dados sob a LGPD art. 11, com assinatura em ICP-Brasil e minimização (art. 6, inc. III)
- Enquadramento de alto risco no EU AI Act (Anexo III(4)(a)), com auditoria de viés, DPIA e FRIA
- KYC sob a Lei Anticorrupção (Lei 12.846/2013) e as normas ABNT NBR ISO 37301 e 37001
- Sanções: ANPD de até 2% do faturamento (limitada a R$ 50 milhões) e EU AI Act de até 35 milhões de euros ou 7% do faturamento global

### Distribuicao de Decisores Pre-Hire-Due-Diligence

| Etapa | Decisor | Justificativa |
|-------|---------|---------------|
| Recepção da aprovação e matriz por cargo | R | Matriz determinística do que é permitido verificar por cargo |
| Coleta do consentimento granular (LGPD art. 11) | R | Base legal específica da LGPD art. 11, assinada em ICP-Brasil |
| Validação automatizada de certificados (e-MEC e Capes) | A | OCR e extração por ML contra registros oficiais; o Recrutamento valida divergências |
| Entrevistas de referência humanas, com roteiro padronizado | H | Algoritmo não escuta nuances; o Recrutamento conduz com roteiro (Lei 9.029/1995) |
| Solicitação do atestado de antecedentes (Lei 13.965/2019) | R | Roteamento determinístico por cargo de confiança (CLT art. 224, § 2º) |
| Verificação de visto (Lei 13.445/2017) | R | Verificação determinística do RNE e classificação do visto, com CTPS Digital |
| KYC (UBO, PEP e listas de sanções) | A | Escore de KYC por ML; o Compliance e o Jurídico validam os alertas |
| Ajustes razoáveis da LBI (Lei 13.146/2015) | R | Verificação por regra da LBI e da cota de PCD (Lei 8.213/91 art. 93) |
| Sinalização de discrepâncias e escore de risco (LGPD art. 22) | A | Comparação e escore por ML; decisão final humana do Recrutamento |
| Classificação no EU AI Act (Anexo III(4)(a)) | R | Verificação por regra do alto risco, com DPIA e FRIA |
| Consolidação dos resultados e relatório de due diligence | A | Consolidação por ML (ABNT NBR ISO 37301); decisão final humana |
| Auditoria de viés e supervisão humana (EU AI Act art. 14) | H | Encarregado (DPO), Compliance e auditor independente; Mobley v. Workday provou não ser delegável |
| Integração com o eSocial (S-2200 e S-1010) | R | Auditoria sistemática (Manual de 2024), com multa por atraso de R$ 800 a R$ 2.500 |
| Escalonamento ao DPO, Compliance e Jurídico | H | Casos de julgamento (alerta de KYC, visto inválido, atestado negativo, violação da LGPD) |

A trilha de auditoria, com retenção de 5 anos, serve de defesa contra os procedimentos sancionadores da ANPD, do MPT, do MTE e da CGU, além da aplicação do EU AI Act. (PT: o equivalente em Portugal seria a CITE; BR: a ANPD, o MTE, o MPT e a CGU.)

--- Agente Gestão Contrato Experiência ---
> Contrato de experiência: CLT art. 443/445 par. único 90 dias com prorrogação, art. 482 justa causa e Súmula TST 6 isonomia - escalonamento de prazo crítico em vez de planilha esquecida.

A gestão do contrato de experiência no Brasil se posiciona entre cinco frentes de compliance que rodam em paralelo. A CLT trata do contrato de experiência, limitado a 90 dias (art. 443 e 445), da conversão automática em prazo indeterminado se esse limite é ultrapassado (art. 451), da rescisão (art. 480-482) e da isonomia salarial (art. 461). A Lei 14.611/2023 exige o Relatório de Transparência Salarial. A LGPD regula a decisão automatizada, como a avaliação de desempenho por IA (art. 22). A Lei 9.029/1995 veda práticas discriminatórias, e o eSocial exige o registro da admissão, do desligamento e da alteração contratual (S-2200, S-2299 e S-2206). Na prática, um único contrato de experiência pode acionar essas cinco obrigações ao mesmo tempo.

## Monitoramento prazos contrato experiencia como obrigacao compliance

Três em cada dez novas contratações deixam a empresa durante o contrato de experiência, na maioria dos casos não por erro de seleção, mas porque, durante 90 dias, ninguém acompanhou: nenhum feedback estruturado, nenhum marco documentado, nenhuma decisão consciente ao final. O contrato expira e, com ele, a única janela em que a separação pode ocorrer com regras específicas. Uma empresa com 2.000 colaboradores e 8% de rotatividade anual tem 13 contratos de experiência em curso por mês, ou 150 prazos individuais por ano, e nenhum centro de serviços compartilhados gerencia isso em planilhas. O problema real é a assimetria de informação: o Departamento Pessoal conhece os prazos, mas não o desempenho; o gestor conhece o desempenho, mas esquece os prazos. Entre os dois há um déficit de comunicação que só se revela no dia 88, quando o RH pergunta se a colaboradora X será efetivada e o gestor pensa no assunto pela primeira vez. Estudos sobre rotatividade precoce mostram custo de contratação fracassada entre 33% e 213% do salário anual, e parte considerável desse custo não vem da separação em si, mas da separação tardia. (PT: em Portugal, o período experimental rege-se pelo Código do Trabalho, com duração variável por categoria; BR: aqui o contrato de experiência tem o limite de 90 dias da CLT art. 445, parágrafo único.)

## CLT art. 443 e 445: o contrato de experiência de 90 dias e a rescisão

O contrato de experiência na CLT não é um programa informal de "se conhecer melhor", mas uma janela de decisão com cronometragem jurídica precisa. O art. 445, parágrafo único, limita o contrato de experiência a 90 dias, com possibilidade de prorrogação dentro desse limite (geralmente 45 mais 45), e o art. 451 determina a conversão automática em prazo indeterminado se o limite é ultrapassado. Na rescisão antecipada, o art. 480 prevê indenização de 50% da remuneração restante por iniciativa do empregado; o art. 481 prevê aviso prévio, férias e 13º proporcionais e multa de 40% do FGTS por iniciativa do empregador; e o art. 482 trata da justa causa, sem multa do FGTS nem aviso prévio. A arquitetura temporal é clara: dia 1 de integração, dia 30 do primeiro feedback, dia 60 do segundo, dia 75 como ponto crítico e dia 90 como prazo final. Entre os dias 75 e 90 há uma janela de 15 dias para decidir entre efetivar ou rescindir, porque uma comunicação no dia 89 já cria risco de prorrogação automática se não houver tempo hábil para o encerramento correto e a transmissão do desligamento no eSocial (S-2299). No dia 75, o agente força a decisão antes que essa janela se feche.

## Conformidade com a CLT art. 461 e a Lei 14.611/2023 durante a experiência

A isonomia salarial da CLT art. 461 aplica-se desde o primeiro dia do contrato, inclusive durante a experiência: mesmo trabalho e mesma remuneração, na mesma localidade, com diferença de tempo de serviço não superior a 4 anos. A Súmula TST 6 detalha a equiparação, e a Súmula TST 401 inverte o ônus da prova para o empregador em ação por discriminação. A avaliação de desempenho deve seguir os critérios objetivos do PCCS (Súmula TST 442). A Lei 14.611/2023 cria o Relatório de Transparência Salarial bianual para empresas com 100 ou mais empregados, com multa de 3% da folha (limitada a 100 salários mínimos). Somam-se a vedação de práticas discriminatórias (Lei 9.029/1995), a cota e a acessibilidade da LBI (Lei 13.146/2015) e a estabilidade da gestante (Lei 14.151/2021), aplicável inclusive durante a experiência; e uma denúncia de assédio não pode justificar a não efetivação (Lei 14.457/2022). O agente confere cada decisão de efetivação ou desligamento contra essa matriz antes da confirmação e bloqueia a decisão se a conformidade não é verificada, escalando o caso ao Jurídico e ao Compliance.

## Avaliação por IA, a LGPD art. 22 e as consultas à CIPA e aos sindicatos

A quarta função é a mais visível: a avaliação de desempenho do contrato de experiência apoiada por IA. O agente coleta feedback estruturado em cada marco (dias 30, 60 e 75), com formulário padronizado e critérios objetivos alinhados ao PCCS (Súmula TST 442) e à igualdade salarial (Lei 14.611/2023). Com ML, extrai temas e classifica a recomendação de efetivação ou desligamento como indicador - nunca como decisão automática. A LGPD art. 22 dá ao titular o direito de pedir a revisão da decisão automatizada por uma pessoa natural; por isso a DPIA (art. 35) é obrigatória, com consulta ao Encarregado (DPO, art. 38), trilha de auditoria e a possibilidade de o colaborador contestar. A CIPA foi ampliada pela Lei 14.457/2022 para casos de assédio. Em empresa com representação sindical, cada mudança de política percorre quatro estações: a área funcional formula, o jurídico revisa, o sindicato é consultado e a diretoria aprova. Acordos coletivos podem ampliar as proteções do contrato de experiência (Lei 13.467/2017 art. 611-A e Súmula TST 277). (PT: o equivalente em Portugal seria a CNPD e o art. 22 do RGPD; BR: aqui falamos da ANPD e do art. 22 da LGPD.)

## Conexão com Onboarding-Workflow e Performance-Review-Documentation

Dois dos três componentes centrais deste agente - o motor de cálculo determinístico de prazos e o agendamento de marcos com escalonamento - são infraestrutura genérica. Todo agente do Decision Layer que monitora prazos sensíveis ao tempo precisa desse motor: o monitoramento de certificações de NR, o ciclo de avaliação de desempenho, a revisão salarial anual e o ciclo de PLR. O Onboarding-Workflow-Agent entrega o contrato de experiência, os dados de admissão e o evento S-2200 do eSocial. O Performance-Review-Documentation-Agent recebe o colaborador efetivado e inicia o ciclo regular de avaliação. O Payroll-Calculation-Agent calcula as verbas rescisórias (CLT art. 480-482) no desligamento. O Compensation-Benchmarking-Agent verifica a isonomia salarial antes da efetivação. E o Works-Council-Coordination-Agent coordena as consultas ao sindicato sobre as cláusulas coletivas de duração e efetivação. Quem começa por este agente instala a infraestrutura para toda decisão baseada em prazos que um agente posterior tomará. As sanções, no entanto, são acumuláveis: ANPD de até 2% do faturamento, multa da Lei 14.611/2023, fiscalização do MTE e a responsabilidade dos administradores (Lei 6.404/76 art. 158), além do risco de reclamação trabalhista.

## De relance

- Cálculo determinístico da data final do contrato de experiência (CLT art. 443 e 445, máximo de 90 dias), com conversão automática em indeterminado se ultrapassado (art. 451)
- Marcos de avaliação nos dias 30, 60 e 75, com escalonamento no dia 75 para a janela de 15 dias da decisão de efetivação
- Coleta estruturada do feedback do gestor, com extração de temas por ML e critérios objetivos do PCCS (Súmula TST 442)
- Verificação de conformidade da decisão (CLT art. 461, Súmula TST 6, Lei 14.611/2023 e LBI) antes da confirmação
- Cálculo das verbas rescisórias (CLT art. 480-482), com transmissão ao eSocial (S-2299 até o 10º dia do mês seguinte e S-2206 para a efetivação)
- Consulta ao sindicato (Lei 13.467/2017 art. 611-A e Súmula TST 277) sobre as cláusulas coletivas de experiência
- Sanções acumuláveis de até R$ 50 milhões: ANPD, multa da Lei 14.611/2023 e reclamação trabalhista, além da responsabilidade do art. 158 da Lei 6.404/76

### Distribuicao de Decisores Probation-Management

| Decisor | Quantidade | Etapas |
| --- | --- | --- |
| R (regra determinística) | 12 | Recebimento e classificação do contrato, cálculo da data final, agendamento de marcos, envio de lembretes, rastreamento de conclusão, alerta no dia 75, verificação de conformidade (CLT art. 461 e Lei 14.611/2023), acionamento do fluxo seguinte, cálculo de verbas, transmissão ao eSocial (S-2299 e S-2206), arquivamento, consulta ao sindicato e auditoria periódica |
| A (indicador ML assistido) | 1 | Coleta estruturada do feedback do gestor, com extração de temas e classificação da recomendação de efetivação ou desligamento |
| H (confirmação humana) | 2 | Decisão de efetivar, prorrogar ou desligar durante a experiência, com assinatura em ICP-Brasil, e escalonamento dos casos de julgamento ao Encarregado (DPO), ao Compliance e ao Jurídico |

--- Agente Processo de Promoção ---
> Governança de promoção: EU AI Act Anexo III(4)(b) alto risco, CLT art. 461 isonomia e Súmula TST 6 - Equity-Audit-Engine com LGPD art. 22 direito de contestação e Mobley v. Workday.

## Promocao como armadilha compliance entre CLT art. 461 e EU AI Act

Este agente segue o principio [Decision Layer](/br/decision-layer/): cada decisao e baseada em regras, assistida por IA ou explicitamente atribuida a um humano. Esta classificado segundo [EU AI Act 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) Anexo III(4)(b) como Sistema Alto Risco e portanto sujeito a obrigacoes reforcadas sobre Sistema Gestao Risco, Governance Dados, Transparencia, Supervisao Humana e Bias-Audit - exigiveis, pela legislacao vigente, a partir de 2 de agosto de 2026, com adiamento para 2 de dezembro de 2027 acordado provisoriamente (Digital Omnibus, maio de 2026) - (extraterritorialidade para multinacionais brasileiras com presenca UE).

Um processo de promoção típico dura três meses: a recomendação do gestor chega em janeiro, a verificação manual de elegibilidade vem em fevereiro, seguem-se a calibração informal entre as áreas e as aprovações sequenciais por e-mail, e o aditivo contratual sai em março. Numa empresa de 2.000 empregados com taxa de promoção anual de 8% a 12%, isso significa de 160 a 240 processos individuais por ano, cada um com risco de inversão do ônus da prova (CLT art. 461 e Súmula TST 6) caso o rationale não esteja documentado de forma reproduzível.

O problema não é a decisão isolada. O gestor que propõe uma colaboradora para a promoção geralmente tem justificativa razoável: o desempenho está em ordem, a posição está disponível e o orçamento comporta. O problema está no que acontece, ou não acontece, entre os passos: a verificação consistente da elegibilidade, a validação do salto entre a faixa atual e a faixa-alvo, a análise sistemática de equidade, os rationales documentáveis diante da inversão do ônus da prova (CLT art. 461 e Lei 14.611/2023) e a comparabilidade entre as unidades de negócio.

## EU AI Act Anexo III(4)(b) Alto Risco com extraterritorialidade

O Promotion-Process-Agent cai sob EU AI Act 2024/1689 Anexo III Ponto 4 Letra b sistemas Alto Risco para decisoes de promocao HR. As obrigacoes, exigiveis pela legislacao vigente a partir de 2.8.2026 - com adiamento para 2.12.2027 acordado provisoriamente (Digital Omnibus, maio de 2026, adocao formal ainda pendente) -, incluem (com extraterritorialidade para multinacionais brasileiras com presenca UE):

- **Art. 9 (gestão de riscos)**: identificação, análise e mitigação dos riscos de viés na promoção (por gênero, idade, etnia e deficiência)
- **Art. 10 (governança de dados)**: qualidade dos dados de treinamento sobre o histórico de promoções, com detecção de viés e testes de paridade
- **Art. 13 (transparência)**: documentação sobre o funcionamento, a precisão e os resultados da auditoria de viés
- **Art. 14 (supervisão humana)**: humano na decisão, obrigatório em cada recomendação de promoção
- **Art. 26 (obrigações do implementador)**: DPIA, consulta à autoridade supervisora, monitoramento pós-mercado e notificação de incidentes
- **Art. 27 (FRIA)**: avaliação de impacto sobre direitos fundamentais antes do uso, com consulta à ANPD, ao Encarregado (DPO), à CIPA e aos sindicatos

As multas chegam a 35 milhões de euros ou 7% do faturamento global. A extraterritorialidade significa que empresas com sede no Brasil mas com subsidiárias, escritórios ou empregados na UE ficam sujeitas ao marco completo, mesmo que o sistema esteja hospedado no Brasil. A isso somam-se a obrigação do Encarregado (LGPD art. 38) e o direito de revisão da decisão automatizada (art. 22). O caso [Mobley v. Workday](https://www.courtlistener.com/docket/67476007/mobley-v-workday-inc/) (Califórnia, 2023) - alegação de viés de IA em software de RH contra candidatos com mais de 40 anos - serve de precedente e baliza os reguladores brasileiros.

## Conformidade da promoção com a CLT art. 461, a Súmula TST 6 e a Lei 14.611/2023

A [Lei 14.611/2023](http://www.planalto.gov.br/ccivil_03/_ato2023-2026/2023/lei/l14611.htm) (Igualdade Salarial entre Mulheres e Homens), com o [Decreto 11.795/2023](http://www.planalto.gov.br/ccivil_03/_ato2023-2026/2023/decreto/d11795.htm) e a Portaria MTE 3.714/2023, estabelece obrigações concretas: o Relatório de Transparência Salarial bianual ao MTE para empresas com 100 ou mais empregados, incluindo os dados de promoção, o Plano de Ação para Igualdade Salarial quando há disparidades, e multa de 3 a 100 salários mínimos por trabalhador prejudicado.

A isonomia salarial da CLT art. 461 aplica-se diretamente às decisões de promoção: trabalho de igual valor, com o mesmo empregador, na mesma localidade e função, com diferença de tempo de serviço inferior a 4 anos. A Súmula TST 6 detalha os requisitos e se aplica à promoção desigual entre trabalhadores em situação comparável, e a Súmula TST 442 exige critérios objetivos de promoção no PCCS, evitando a arbitrariedade. A negociação coletiva (Súmula TST 277 e Lei 13.467/2017) pode trazer requisitos adicionais.

A inversão do ônus da prova (CLT art. 461 e Súmula TST 6) é o ponto crítico: se um empregado apresenta indicadores de discriminação na promoção - uma anomalia estatística frente aos pares, a ausência de rationale documentado ou um timing suspeito - , cabe ao empregador provar que não houve discriminação. Sem rationale documentado e reproduzível por decisão de promoção, esse ônus é praticamente impossível de cumprir.

## Mobley v. Workday e o Relatório de Transparência Salarial do Decreto 11.795/2023

[Mobley v. Workday](https://www.courtlistener.com/docket/67476007/mobley-v-workday-inc/) (Califórnia, 2023) é a primeira ação coletiva contra um software de RH alegando viés de IA contra candidatos com mais de 40 anos. Mesmo sem julgamento final, a certificação da classe já serve de precedente regulatório: os reguladores brasileiros (ANPD, MTE, MPT e TST) e os auditores de ESG usam o caso como referência para avaliar viés de IA em sistemas de RH. A extraterritorialidade do precedente alcança multinacionais brasileiras com operação nos EUA ou que tratam dados de empregados ali.

A mitigação inclui a trilha de auditoria de viés trimestral (com testes de paridade), a auditoria dos dados de treinamento quanto ao viés de idade, o direito de revisão da LGPD art. 22, a trilha de auditoria conforme a CLT art. 461 e a FRIA (EU AI Act art. 27) antes do uso.

O Relatório de Transparência Salarial bianual ao MTE (Decreto 11.795/2023), já em vigor para empresas com 100 ou mais empregados, exige a inclusão de dados de promoção: a taxa de promoção por gênero, o Compa-Ratio na faixa-alvo e o tempo médio de permanência em cada nível. A Diretiva Europeia de Transparência Salarial (2023/970), a partir de 7 de junho de 2026, tem efeito extraterritorial, e a CSRD (ESRS S1-13) exige o reporte de desenvolvimento de carreira a partir de 250 empregados.

## CIPA, sindicatos e a Lei 13.467/2017 nos processos de promoção

A consulta à CIPA (obrigatória nas empresas com 20 ou mais empregados) e aos sindicatos (Lei 13.467/2017) é obrigatória para a introdução de um sistema de TI nos processos de promoção com trilha de auditoria de viés. Na prática, isso envolve o acordo coletivo sobre os critérios de promoção, as faixas-alvo, os limiares da análise de equidade, a matriz de aprovação, a participação na DPIA, a consulta à FRIA e o acesso à trilha de auditoria.

Em caso de desacordo, há o procedimento de dissídio coletivo na Justiça do Trabalho. As Súmulas TST 277 e 442 estabelecem que o plano de cargos deve ter critérios objetivos, negociados coletivamente quando aplicável, e a Lei 14.457/2022 (Programa Emprega Mais Mulheres) acrescenta medidas de prevenção de assédio nos processos de promoção.

Os riscos de sanção se acumulam: a multa da Lei 14.611/2023 (de 3 a 100 salários mínimos por trabalhador), o EU AI Act (até 35 milhões de euros ou 7% do faturamento global, por extraterritorialidade), a LGPD (até 2% do faturamento, limitada a R$ 50 milhões) e a Lei Anticorrupção (até 20% do faturamento). A violação da CSRD (ESRS S1-13) leva a parecer do auditor e à responsabilidade do Conselho de Administração (Lei 6.404/76 art. 158).

## Conexão com Merit-Cycle-Governance, Compensation-Benchmarking e Performance-Review

Este agente integra-se a um conjunto de agentes de RH. O [Merit-Cycle-Governance-Agent](/br/catalogo-agentes-hr/merit-cycle-governance-agent/) reutiliza o motor de análise de equidade para o ciclo salarial. O [Compensation-Benchmarking-Agent](/br/catalogo-agentes-hr/compensation-benchmarking-agent/) fornece as faixas remuneratórias, os Compa-Ratios e o PCCS (Súmula TST 442). O [Performance-Review-Documentation-Agent](/br/catalogo-agentes-hr/performance-review-documentation-agent/) fornece as qualificações de desempenho dos 2 ciclos consecutivos. O [Payroll-Calculation-Agent](/br/catalogo-agentes-hr/payroll-calculation-agent/) recebe os ajustes aprovados, com a correção de FGTS, INSS, IRRF e PPR. O [HR-Document-Management-Agent](/br/catalogo-agentes-hr/hr-document-management-agent/) arquiva os rationales por 5 anos. O [Audit-Compliance-Agent](/br/catalogo-agentes-hr/audit-compliance-agent/) verifica a DPIA. E o [Contract-Offer-Generation-Agent](/br/catalogo-agentes-hr/contract-offer-generation-agent/) gera o aditivo contratual em ICP-Brasil.

## De relance

- **Classificação**: sistema de alto risco pelo EU AI Act (Anexo III(4)(b)) para decisões de promoção; obrigações exigíveis, pela legislação vigente, a partir de 2 de agosto de 2026 (adiamento para dezembro de 2027 acordado provisoriamente - Digital Omnibus, maio de 2026), com extraterritorialidade para multinacionais brasileiras com presença na UE
- **Âncoras de compliance**: isonomia da CLT art. 461, Súmula TST 6, PCCS (Súmula TST 442), Lei 14.611/2023, LGPD (art. 22 e 38), EU AI Act e a Diretiva Europeia de Transparência Salarial (2023/970)
- **Consulta**: à CIPA e aos sindicatos (Lei 13.467/2017), obrigatórias
- **Limiar de equidade**: um gap de promoção entre gêneros acima de 5% e inexplicado (Lei 14.611/2023 e Decreto 11.795/2023) ativa o Plano de Ação para Igualdade Salarial, com 6 meses de remediação
- **Multas**: EU AI Act de até 35 milhões de euros ou 7% do faturamento global; LGPD de até 2% (limitada a R$ 50 milhões); MTE de 3 a 100 salários mínimos por trabalhador; e Lei Anticorrupção de até 20% do faturamento
- **Obrigação de auditoria**: DPIA, FRIA e auditoria de viés trimestral, com verificação do auditor pela CSRD (ESRS S1-13) a partir de 250 empregados e o B3 ISE-B3 anual
- **Precedente**: Mobley v. Workday (Califórnia, 2023), sobre viés de IA em software de RH, com extraterritorialidade

### Distribuicao de Decisores Promotion-Process

| Passo | Decisor | Rationale |
|-------|---------|-----------|
| Recepção da recomendação do gestor | H | Avaliação individual do desempenho e do risco de retenção |
| Verificação de elegibilidade | R | Tempo de serviço, 2 ciclos de desempenho e suspensões, de forma determinística |
| Verificação da posição-alvo | R | Headcount e descrição de cargo do PCCS, automática |
| Cálculo do salto de faixa salarial | R | Salto de faixa, impacto orçamentário e correções, de forma determinística |
| Validação da faixa salarial | R | Limites da faixa-alvo e Compa-Ratio, automático |
| Conformidade orçamentária | R | Acompanhamento em tempo real, de forma determinística |
| Análise de equidade na promoção | A | Detecção estatística de viés por ML, com validação humana |
| Escalonamento de equidade | R | Limiar acima de 5% (Lei 14.611/2023) |
| Fluxo de aprovação multinível | R | Matriz de aprovação por hierarquia e magnitude do salto |
| Notificação ao sindicato | R | Acordos coletivos (Lei 13.467/2017), de forma determinística |
| Aprovação do HR Lead | H | Decisão final conforme a CLT e o PCCS |
| Aditivo contratual | A | Geração por LLM, com revisão humana |
| Informação ao colaborador (LGPD) | R | Fluxo padrão dos arts. 9 e 22 |
| Conversa de promoção | H | Conversa pessoal, com dimensão relacional e de carreira |
| Atualização dos sistemas | R | eSocial (S-2200 e S-1010), ESRS S1-13 e B3 ISE-B3, de forma determinística |

--- Agente Atestados Médicos ---
> Processamento de atestados médicos: CLT art. 60 e 131-138, Lei 8.213/91 art. 59-63 auxílio-doença INSS e Sistema Atestmed - extração CID-10 com LGPD art. 11 e eSocial S-2230.

O processamento de atestados médicos no Brasil cruza vários regimes de conformidade ao mesmo tempo. A CLT (art. 60 e 131-138) trata da jornada do empregado doente e da suspensão do contrato. A Lei 8.213/91 (art. 59-63) define o auxílio-doença do INSS, com os 15 primeiros dias a cargo do empregador e a transição a partir do 16o dia, após perícia. A LGPD (art. 11) protege o dado sensível de saúde, e a Resolução ANPD 4/2023 torna a DPIA obrigatória. A Resolução CFM 1.658/2002 rege o atestado e o sigilo do CID-10. Um único atestado pode, assim, ativar simultaneamente várias obrigações distintas.

## Atestado médico em 60 segundos, não três semanas de atraso

Toda manhã chegam novos atestados médicos. Nas segundas-feiras depois de ondas de gripe, são dezenas. Cada um desencadeia uma cascata: atribuição ao colaborador, verificação se é atestado inicial ou prorrogação, cálculo do período de responsabilidade do empregador, cruzamento com histórico, notificação ao INSS via eSocial S-2230, impacto na folha e informação ao gestor sem o CID-10. Nos casos de longa duração, soma-se o acompanhamento do limite de 15 dias para encaminhamento ao INSS. Em média, trabalhadores brasileiros acumulam entre 17 e 22 dias de afastamento por doença por ano. Numa empresa de 2.000 colaboradores, isso representa de 30.000 a 44.000 dias por ano, cada um deles um ato administrativo com prazo legal e consequência em caso de descumprimento. Só os primeiros 15 dias pagos pelo empregador, conforme a CLT art. 60, já representam custo expressivo. O problema não é a complexidade de um único atestado, e sim o volume somado à tolerância zero a erros e ao prazo do eSocial até o dia 15 do mês seguinte.

## Os 15 dias do empregador e a transição para o INSS

O cálculo do afastamento é o ponto mais crítico do agente. Os 15 primeiros dias correm por conta do empregador (CLT art. 60), e a partir do 16o dia o auxílio-doença passa ao INSS, após perícia (Lei 8.213/91 art. 59-63), distinguindo o benefício previdenciário (B31) do acidentário (B91). A carência segue o art. 26-31, com isenção em acidente e em doenças graves. Sobre esse cálculo incidem ainda a estabilidade da Súmula TST 371 e, em doença grave, a presunção de dispensa discriminatória da Súmula TST 443. A CLT art. 131-138 trata da suspensão do contrato e da perda do período aquisitivo de férias após mais de 6 meses, e a LBI (Lei 13.146/2015) exige os ajustes razoáveis no retorno. O agente verifica cada atestado contra essa matriz antes de processar e bloqueia, encaminhando ao médico do trabalho, quando a conformidade não é confirmada.

## Sistema Atestmed, perícia do INSS e eSocial S-2230

Cada atestado percorre ao menos quatro estações: o Departamento Pessoal recebe, o médico do trabalho valida o CRM, o sistema calcula a transição empregador-INSS, e o INSS avalia a perícia online pelo Sistema Atestmed. Conforme o caso, juntam-se o DPO, o Compliance Officer e o Departamento Jurídico. A Lei 8.213/91 e o Decreto 3.048/1999 admitem a perícia online, sem exigência de perícia presencial. O evento eSocial S-2230 de afastamento temporário precisa ser transmitido no prazo legal, até o dia 15 do mês seguinte para atestados acima de 3 dias. O gestor pode saber que alguém está afastado, mas não o motivo, por força do sigilo médico do Código de Ética Médica. A folha precisa distinguir se o pagamento é do empregador, nos 15 primeiros dias, ou do INSS, do 16o dia em diante. O monitor de longa duração acumula dias ao longo de meses, incluindo interrupções. Feito manualmente, são quatro sistemas e quatro etapas por atestado; com cem atestados por mês, um processo controlável vira uma construção frágil de lembretes e planilhas. O agente roteia automaticamente a integração ao eSocial e ao Sistema Atestmed, com cálculo proporcional da remuneração e assinatura ICP-Brasil.

## Dado sensível de saúde sob a LGPD art. 11

Atestados médicos contêm dado pessoal sensível conforme a LGPD art. 11, cujo tratamento só é admitido com base legal específica, aqui a obrigação legal trabalhista e previdenciária do art. 11 inc. II. Isso exige mais do que controle de acesso e criptografia: exige uma arquitetura que imponha a minimização de dados. A Resolução ANPD 4/2023 torna a DPIA obrigatória, e a sanção pode chegar a 2 por cento do faturamento, limitada a R$ 50 milhões. O agente processa períodos de afastamento e grupos de diagnóstico apenas onde estritamente necessário: o CID-10 concreto não é repassado a gestores, não é armazenado em textos de notificação nem registrado no Decision Log. Quem encaminha atestados em PDF por e-mail ao gestor tem um problema de proteção de dados, mesmo sem intenção. Um agente baseado em regras não tem esse problema estruturalmente, porque a arquitetura de informação define quais dados fluem para qual destinatário.

## Validação do atestado, CID-10 e sigilo médico

A Resolução CFM 1.658/2002 torna o CID-10 obrigatório mediante consentimento expresso do paciente e reforça o sigilo médico do Código de Ética Médica, ao passo que o atestado falso configura crime pelo art. 302 do Código Penal. A Resolução CFM 1.821/2007 fixa a retenção do prontuário por 20 anos. O agente valida cada atestado quanto a CRM ativo, assinatura do médico responsável, identificação do paciente, data, duração e CID-10 com consentimento. A detecção de duplicidades e falsificações usa um indicador de ML que analisa assinatura, CRM e estabelecimento e identifica atestados duplicados com mesmo período, médico e CID, sempre sujeito à revisão humana prevista na LGPD art. 22. O agente apenas entrega a suspeita; o médico do trabalho decide a investigação e o colaborador pode contestar, com o atestado digital valendo como prova (Súmula TST 387).

## Conexão com folha, licenças e gestão documental

Dois dos três componentes centrais deste agente, o motor de cálculo dos 15 dias de afastamento e o fluxo de integração ao eSocial S-2230, são infraestrutura genérica. Todo agente do Decision Layer que aplica regras de afastamento precisa de cálculos versionados com períodos de vigência, e todo agente que orquestra notificações governamentais em vários níveis precisa de um motor de fluxo com monitoramento de prazos. O agente de folha calcula a remuneração mensal contra atestados validados; o de licenças gerencia férias, maternidade, paternidade e acompanhante (Lei 11.108/2005) com a mesma lógica; o de gestão documental mantém o prontuário funcional referenciando os atestados validados. Quem começa por este agente instala a infraestrutura para toda decisão de afastamento que os agentes seguintes tomarão. As sanções, por sua vez, são cumuláveis: a ANPD pode aplicar até 2 por cento do faturamento, limitado a R$ 50 milhões, somando-se às Súmulas TST 371 e 443 e à auditoria fiscal do MTE.

## De relance

- Extração determinística do CID-10 e cálculo dos 15 dias de afastamento do empregador (CLT art. 60), com transição para o auxílio-doença do INSS a partir do 16o dia (Lei 8.213/91 art. 59-63)
- Comunicação obrigatória do evento eSocial S-2230 no prazo legal, integrada ao Sistema Atestmed
- Validação do atestado quanto a CRM ativo e sigilo médico, conforme a Resolução CFM 1.658/2002
- Tratamento do dado sensível de saúde sob a LGPD art. 11, com DPIA obrigatória pela Resolução ANPD 4/2023
- Detecção de casos longos ao atingir 15 dias acumulados, com encaminhamento ao INSS e atenção à estabilidade da Súmula TST 371
- Detecção de atestados falsos assistida por ML, sempre com revisão humana garantida pela LGPD art. 22
- Sanções cumuláveis que podem superar R$ 50 milhões, somando ANPD e as Súmulas TST 371 e 443

### Distribuição de Decisores Sick-Leave-Processing

| Decisor | Quantidade | Etapas |
| --- | --- | --- |
| R (regra determinística) | 13 | Recebimento e classificação do atestado, validação do CRM, vínculo ao registro do colaborador, detecção de sobreposições com férias, cálculo dos 15 dias do empregador, comunicação do eSocial S-2230, detecção de casos longos, atualização de ponto e folha, comunicação ao gestor sem dado de saúde, monitoramento do retorno, auditoria trimestral e arquivamento do registro |
| A (indicador ML assistido) | 1 | Detecção de atestados duplicados e falsificações por análise de padrões de fraude (assinatura, CRM e estabelecimento) |
| H (confirmação humana) | 2 | Comunicação ao colaborador sobre o encaminhamento ao INSS e escalada dos casos de julgamento ao DPO, ao Compliance Officer e ao médico do trabalho |

--- Agente Skills-Career-Profile ---
> Skills-Matching e recomendação de caminho de carreira: EU AI Act Anexo III(4)(b) alto risco, Súmula TST 6 e LGPD art. 22 - taxonomia CBO/ESCO com Súmula TST 442 PCCS.

## Skills-matching como armadilha compliance entre CLT art. 461 e EU AI Act

Este agente segue o principio [Decision Layer](/br/decision-layer/): cada decisao e baseada em regras, assistida por IA ou explicitamente atribuida a um humano. Esta classificado segundo [EU AI Act 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) Anexo III(4)(b) task-assignment-personal-traits como Sistema Alto Risco com obrigacoes reforcadas sobre Sistema Gestao Risco, Transparencia, Supervisao Humana e Bias-Audit - exigiveis, pela legislacao vigente, a partir de 2 de agosto de 2026, com adiamento para 2 de dezembro de 2027 acordado provisoriamente (Digital Omnibus, maio de 2026) - (extraterritorialidade para multinacionais brasileiras com presenca UE).

O skills-matching apoiado por IA distribui empregados a tarefas, projetos e vagas internas com base em perfis algorítmicos de competência. Numa empresa de 2.000 empregados com taxa de mobilidade interna de 15 a 20 por cento ao ano, isso representa de 300 a 400 recomendações por ano, cada uma com risco de inversão do ônus da prova pela CLT art. 461 e pela Súmula TST 6, caso o porquê do match não esteja documentado de forma reproduzível.

O problema não é a recomendação isolada. O algoritmo que sugere uma colaboradora para uma vaga interna costuma ter dados de entrada razoáveis: competências extraídas do currículo, certificações e projetos concluídos. O problema está no que acontece, ou não, entre as etapas: a extração consistente de competências mapeadas à CBO e à ESCO, a validação do perfil pelo empregado, o gap-analysis determinístico, a detecção de viés e a justificativa documentável que sustenta a inversão do ônus da prova.

## EU AI Act Anexo III(4)(b) task-assignment-personal-traits Alto Risco (extraterritorialidade)

O Skills-Career-Profile-Agent cai sob EU AI Act 2024/1689 Anexo III Ponto 4 Letra b sistemas Alto Risco para task-assignment baseada em tracos pessoais. A diferenca crucial vs Promotion-Process-Agent (mesma categoria Anexo III(4)(b) com reason promotion-decisions) e o foco em classificacao de talentos algoritmica, nao em decisoes formais de promocao. Obrigacoes exigiveis, pela legislacao vigente, a partir de 2.8.2026 (adiamento para 2.12.2027 acordado provisoriamente - Digital Omnibus, maio de 2026, adocao formal ainda pendente):

- **Article 9, gestão de risco**: mitigação de viés no skills-matching, sobretudo as lacunas de mobilidade por gênero, idade, etnia e deficiência
- **Article 10, governança de dados**: testes de equidade estatística (paridade demográfica e igualdade de oportunidade)
- **Article 13, transparência**: documentação do funcionamento e auditoria de viés no histórico de classificação de talentos
- **Article 14, supervisão humana**: pessoa no circuito obrigatória em cada recomendação de skills-matching
- **Article 26, obrigações do operador**: DPIA, monitoramento pós-mercado e notificação de incidentes
- **Article 27, FRIA**: avaliação de impacto sobre direitos fundamentais, com consulta à ANPD, ao DPO, à CIPA e aos sindicatos

Multas ate 35 milhoes EUR ou 7 por cento faturamento global grupo. A extraterritorialidade significa que empresas com sede no Brasil mas com subsidiarias na UE ficam sujeitas ao framework completo, mesmo se o sistema esta hospedado no Brasil. [Mobley v. Workday acao coletiva](https://www.courtlistener.com/docket/67476007/mobley-v-workday-inc/) (Northern District California 2023) - AI bias em software HR contra candidatos 40+ ADEA - forma linha reguladores brasileiros.

## Isonomia da CLT art. 461 e da Súmula TST 6 aplicada às competências

A [Lei 14.611/2023](http://www.planalto.gov.br/ccivil_03/_ato2023-2026/2023/lei/l14611.htm) de Igualdade Salarial entre Mulheres e Homens, regulamentada pelo [Decreto 11.795/2023](http://www.planalto.gov.br/ccivil_03/_ato2023-2026/2023/decreto/d11795.htm), estabelece obrigações para os empregadores brasileiros: o Relatório de Transparência Salarial bianual ao MTE para empresas com 100 ou mais empregados, agora com dados de mobilidade interna, o Plano de Ação de Igualdade Salarial e multa de 3 a 100 salários mínimos por trabalhador prejudicado.

A isonomia da CLT art. 461 vale para a alocação de tarefas: trabalho de igual valor, com o mesmo empregador, na mesma localidade e na mesma função. O art. 458 entra em jogo quando a mobilidade interna altera benefícios, e o art. 450 impede que a transferência de função por necessidade do serviço reduza o salário, o que é crítico nas transferências involuntárias. A Súmula TST 6 detalha os requisitos de isonomia, e a Súmula TST 442 (PCCS) exige critérios objetivos para a mobilidade.

A inversão do ônus da prova é o ponto crítico: se o empregado apresenta indícios de discriminação numa recomendação de skills-matching, cabe ao empregador provar que ela não ocorreu. Sem o porquê documentado por recomendação, esse ônus é praticamente impossível de cumprir.

## LGPD art. 22 proibicao classificacao talentos automatizada

A [LGPD Lei 13.709/2018](http://www.planalto.gov.br/ccivil_03/_ato2018/2018/lei/l13709.htm) art. 22 garante o direito de revisão de decisões automatizadas, inclusive a classificação de talentos. A ANPD prioriza, no período de 2024 a 2026, os sistemas de IA em RH e a auditoria de viés, com sanção de até 2 por cento do faturamento no Brasil, limitada a R$ 50 milhões.

Os dados sensíveis do art. 11 (origem racial ou étnica, convicção religiosa, opinião política, filiação sindical, dados genéticos e biométricos) são proibidos como entrada nos algoritmos de skills-matching, e sistemas baseados em jogos de neurociência exigem cuidado especial sob esse artigo. O inventário de competências deve ser construído apenas com competência profissional, certificações, projetos concluídos e autoavaliação, nunca com inferência algorítmica de traços sensíveis. A obrigação de DPO da LGPD art. 38, a DPIA e a supervisão da ANPD sujeitam o agente a controle reforçado.

## Taxonomia CBO e ESCO e o precedente Mobley v. Workday

A [CBO Classificação Brasileira de Ocupações](https://www.gov.br/trabalho-e-emprego/pt-br/assuntos/trabalhador/cbo) cataloga 2.587 ocupações e é obrigatória para os eventos do eSocial. O agente mapeia automaticamente as competências para os códigos da CBO e atualiza o evento de alteração de contrato na mobilidade interna. Para multinacionais Brasil-UE, a [ESCO](https://esco.ec.europa.eu/) fornece taxonomia comum em 25 idiomas, com 13.890 ocupações, permitindo a comparação internacional exigida pelo relatório de carreira da CSRD.

[Mobley v. Workday](https://www.courtlistener.com/docket/67476007/mobley-v-workday-inc/) (2023) foi a primeira ação coletiva contra um software de RH alegando viés algorítmico contra candidatos com mais de 40 anos. A certificação da classe serve de precedente regulatório, e reguladores brasileiros como a ANPD, o MTE e o TST o usam como referência. O efeito extraterritorial alcança multinacionais brasileiras com operação nos EUA.

A mitigação inclui trilha de auditoria de viés trimestral, revisão do viés de idade nos dados de treinamento, o direito de revisão da LGPD art. 22 e a FRIA do EU AI Act Article 27. As plataformas de skills empregadas devem operar com o Equity Engine ativo.

O Decreto 11.795/2023 exige a inclusão de dados de mobilidade interna, como a taxa de mobilidade por gênero e o tempo médio em cada nível. A Diretiva Europeia de Transparência Salarial (2023/970) passa a valer a partir de junho de 2026, com efeito extraterritorial.

## Conexão com promoção, avaliação de desempenho e sucessão

O agente está integrado a uma cadeia de outros: o [Promotion-Process-Agent](/br/catalogo-agentes-hr/promotion-process-agent/) reutiliza o Equity Analysis Engine, com a mesma classificação do Anexo III(4)(b) mas voltada a decisões de promoção. O [Performance-Review-Documentation-Agent](/br/catalogo-agentes-hr/performance-review-documentation-agent/) fornece as qualificações de dois ciclos consecutivos. O Succession-Planning-Agent reaproveita o inventário de competências e os caminhos de carreira. O [Compensation-Benchmarking-Agent](/br/catalogo-agentes-hr/compensation-benchmarking-agent/) fornece o PCCS da Súmula TST 442, o [HR-Document-Management-Agent](/br/catalogo-agentes-hr/hr-document-management-agent/) arquiva as justificativas por 5 anos, o [Audit-Compliance-Agent](/br/catalogo-agentes-hr/audit-compliance-agent/) verifica a DPIA e a FRIA, e o [Contract-Offer-Generation-Agent](/br/catalogo-agentes-hr/contract-offer-generation-agent/) gera o aditivo conforme o padrão ICP-Brasil.

## De relance

- **Classificacao**: EU AI Act 2024/1689 Anexo III(4)(b) Sistema Alto Risco task-assignment-personal-traits; obrigacoes exigiveis pela legislacao vigente a partir de 2.8.2026 (adiamento para 2.12.2027 acordado provisoriamente - Digital Omnibus, maio de 2026) (extraterritorialidade para multinacionais brasileiras com presenca UE)
- **Âncoras de conformidade**: a isonomia da CLT art. 461 e da Súmula TST 6, a Lei 14.611/2023, a LGPD (art. 11, 22 e 38) e o EU AI Act
- **Taxonomia de competências**: a CBO brasileira e a ESCO europeia, integradas às principais plataformas de skills
- **Consulta**: à CIPA e aos sindicatos, obrigatória pela Lei 13.467/2017
- **Limiar de equidade no skills-matching**: um Gender Mobility Gap inexplicado acima de 5 por cento aciona o Plano de Ação de Igualdade Salarial, com 6 meses para remediação
- **Multas**: até 35 milhões de euros ou 7 por cento do faturamento global pelo EU AI Act, e até 2 por cento do faturamento no Brasil, limitado a R$ 50 milhões, pela LGPD
- **Obrigação de auditoria**: DPIA, FRIA e auditoria de viés trimestral, com verificação por auditor do relatório de carreira da CSRD a partir de 250 empregados
- **Precedente US**: Mobley v. Workday Northern District California 2023 acao coletiva (PT: accao colectiva) AI bias HR software com extraterritorialidade

### Distribuicao de Decisores Skills-Career-Profile

| Passo | Decisor | Rationale |
|-------|---------|-----------|
| Ingestão do inventário de competências e mapeamento à CBO | A | Extração por LLM com revisão do empregado |
| Validação do perfil pelo empregado e pelo gestor | H | Autoavaliação e avaliação subjetiva do gestor |
| Análise de lacunas de competência | R | Cálculo determinístico do gap-score |
| Skills-matching algorítmico | A | Matching por ML com validação do RH |
| Verificação de acessibilidade para PCD | R | Determinístico pela LBI e pela cota da Lei 8.213/91 art. 93 |
| Análise de equidade no skills-matching | A | Detecção estatística de viés por ML com validação humana |
| Escalonamento de equidade | R | Limiar acima de 5 por cento pela Lei 14.611/2023 |
| Recomendação de caminho de carreira | A | Recomendação por LLM com validação humana |
| Notificação ao sindicato | R | Determinístico pelo acordo coletivo da Lei 13.467/2017 |
| Candidatura à vaga interna | H | Voluntária do empregado, com aprovação dos gestores |
| Aprovação final do líder de RH | H | Conforme a CLT art. 461 e o PCCS |
| Aditivo contratual de mobilidade | A | Geração por LLM com revisão humana |
| Informação ao titular pela LGPD | R | Fluxo padrão dos art. 9 e 22 |
| Atualização dos sistemas e da CBO | R | Determinístico via eventos do eSocial |

--- Agente HR Analytics Estratégico ---
> Strategic HR Analytics: análise de turnover, CSRD ESRS S1-1/S1-9/S1-13 Diversity e Board Reporting Comitê Auditoria - LGPD art. 88 aggregate-analytics com Lei 6.404/76 art. 158.

## De dados HR a percepcoes estrategicas

Este agente segue o princípio do [Decision Layer](/br/decision-layer/): cada decisão é baseada em regras, assistida por IA ou explicitamente atribuída a um humano. Não está classificado pelo [EU AI Act 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) como sistema de alto risco, por operar com analytics agregado por coorte e sem decisões individuais, mas está sujeito à isonomia da CLT art. 461 e da Súmula TST 6, à [Lei 14.611/2023](http://www.planalto.gov.br/ccivil_03/_ato2023-2026/2023/lei/l14611.htm), à LGPD art. 88, à responsabilidade dos administradores da Lei 6.404/76 art. 158 e à verificação por auditor obrigatória a partir de 250 empregados.

Um analytics estratégico de RH típico processa de centenas a milhares de pontos de dados por trimestre, vindos de HCM, folha, desempenho, recrutamento, treinamento e pesquisas de engajamento. Feito à mão, leva dias e produz painéis superficiais. O agente gera o analytics agregado em segundos: tendências de rotatividade, métricas de diversidade, faixas de ROI de RH, painéis de KPI e os relatórios da CSRD, do B3 ISE-B3 e da GRI, sem perfilamento individual.

O problema não está no volume, e sim na cadeia auditável exigida pelas ESRS: documentação processual conforme a ABNT NBR ISO 30414, validação humana do CHRO, do diretor de RH, do conselho e do comitê ESG, trilha de auditoria com usuário, data e estado anterior, retenção de 5 anos pelo CTN e verificação por auditor a partir de 250 empregados.

## Relatório da CSRD, B3 ISE-B3 e GRI

A [CSRD](https://eur-lex.europa.eu/eli/dir/2022/2464/oj), a Diretiva Europeia 2022/2464 de relato de sustentabilidade, com efeito extraterritorial sobre multinacionais Brasil-UE, define nas ESRS S1 o relato de diversidade, de igualdade salarial e de remuneração, com mediana, média e quartis. Exige verificação por auditor a partir de 250 empregados, em aplicação escalonada entre 2024 e 2026, e inclui a avaliação de dupla materialidade orientada pelo EFRAG.

No Brasil, o B3 ISE-B3 impõe reporte anual às companhias abertas, conforme o Código Brasileiro de Governança Corporativa do IBGC, e a GRI fornece os padrões universais e os temas de emprego, diversidade, não discriminação e liberdade de associação.

Multinacionais brasileiras com presença na UE precisam cumprir os dois marcos ao mesmo tempo. A responsabilidade dos administradores da Lei 6.404/76 art. 158, somada à Resolução CVM 80/2022 sobre divulgação da remuneração dos administradores, impõe obrigações adicionais às companhias abertas na B3.

## Rotatividade, diversidade e a isonomia da CLT art. 461

A isonomia da CLT art. 461 e da Súmula TST 6, somada à [Lei 14.611/2023](http://www.planalto.gov.br/ccivil_03/_ato2023-2026/2023/lei/l14611.htm) e ao Decreto 11.795/2023, estabelece obrigações concretas: a análise agregada de igualdade salarial das ESRS S1-10, com a apuração do pay gap por gênero, raça e etnia, e o Relatório de Transparência Salarial bianual ao MTE para empresas com 100 ou mais empregados.

As sanções vão da multa do MTE, de 3 a 100 salários mínimos por trabalhador, à ação coletiva do sindicato e ao termo de ajuste com o MPT. A Lei 14.611/2023 inova ao introduzir mecanismos de transparência salarial obrigatória que vão além da CLT art. 461, em linha com a Diretiva Europeia de Transparência Salarial (2023/970).

O analytics de rotatividade é agregado, segmentado por perfil demográfico, tempo de casa, departamento e localidade, e comparado aos benchmarks setoriais da PNAD do IBGE. O relatório de diversidade cobre gênero, idade, raça, etnia, deficiência e a comunidade LGBTQIA+, conforme a ABNT NBR ISO 30414 e o padrão GRI 405. As Súmulas TST 6, 442 e 277 completam o quadro jurisprudencial.

## LGPD art. 88 e a consulta à CIPA e aos sindicatos

A [LGPD](http://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm) art. 88 estabelece o analytics agregado como base legal para o tratamento de dados de RH com finalidade de pesquisa e estatística. O motor de anonimização, com limiar de k-anonymity de no mínimo 10 colaboradores por coorte, garante a ausência de perfilamento individual e de reidentificação, em linha com o Plano Estratégico da ANPD para 2024-2027, que prioriza a decisão automatizada e os dados laborais.

A consulta à CIPA e aos sindicatos é obrigatória, pela Lei 13.467/2017, para introduzir um sistema de analytics sobre dados pessoais, com trilha de auditoria de viés e DPIA pela LGPD art. 35. As resoluções da ANPD sobre dosimetria de sanções e transferência internacional aplicam-se quando os dados saem do Brasil.

O direito de revisão de decisões automatizadas da LGPD art. 22 não incide aqui, porque o analytics agregado por coorte não decide sobre indivíduos. A distinção é essencial: este agente faz análise agregada, não pontuação individual. É justamente o cenário do caso Mobley v. Workday (viés algorítmico contra empregados com mais de 40 anos, com analogia à CLT art. 461) que o analytics agregado evita.

## Análise preditiva e cálculo do ROI de RH por ML

A análise preditiva por ML modela as tendências de rotatividade em nível de coorte, com no mínimo 10 colaboradores anonimizados, entregando faixas de risco de saída em vez de estimativas pontuais individuais. O motor retorna intervalos de confiança, valores-p e verificação de plausibilidade, correlacionados a engajamento, horas extras, tempo de casa e departamento. O resultado é um indicador para o CHRO, o diretor de RH e o conselho, nunca uma decisão automática sobre indivíduos.

O cálculo do ROI de RH (custo por contratação, valor de retenção, correlações de produtividade e retorno de treinamento) é entregue em faixas com intervalos de confiança, com referência ao CPC 33 e ao IAS 19. Apresentar faixas em vez de pontos exatos evita a falsa precisão e protege a responsabilidade dos administradores da Lei 6.404/76 art. 158.

A validação humana do CHRO, do diretor de RH, do conselho e do comitê ESG é obrigatória para distinguir a interpretação causal da correlação espúria. Padrões estatísticos sem contexto humano são ineficazes ou conduzem a ações erradas. A verificação por auditor é obrigatória a partir de 250 empregados.

## Conexão com avaliação de desempenho, força de trabalho e sucessão

Este agente está integrado a uma cadeia de agentes de conhecimento de RH. O [Performance-Review-Documentation-Agent](/br/catalogo-agentes-hr/performance-review-documentation-agent/) fornece os dados agregados de desempenho que alimentam o analytics. O [Workforce-Planning-Agent](/br/catalogo-agentes-hr/workforce-planning-agent/) fornece as projeções de headcount e o planejamento de cenários, e o [Succession-Planning-Agent](/br/catalogo-agentes-hr/succession-planning-agent/) fornece o pipeline de sucessão e a profundidade do bench.

O [People-Analytics-Agent](/br/catalogo-agentes-hr/people-analytics-agent/) fornece o analytics operacional do dia a dia, o [Compensation-Benchmarking-Agent](/br/catalogo-agentes-hr/compensation-benchmarking-agent/) as faixas de remuneração para o ROI de RH, e o [Merit-Cycle-Governance-Agent](/br/catalogo-agentes-hr/merit-cycle-governance-agent/) os ajustes salariais aprovados. O [Audit-Compliance-Agent](/br/catalogo-agentes-hr/audit-compliance-agent/) verifica a conformidade com as normas do CFC, o [Talent-Pool-Management-Agent](/br/catalogo-agentes-hr/talent-pool-management-agent/) o analytics do pipeline de talentos, o [HR-Document-Management-Agent](/br/catalogo-agentes-hr/hr-document-management-agent/) arquiva os relatórios por 5 anos, e o [Payroll-Reporting-Agent](/br/catalogo-agentes-hr/payroll-reporting-agent/) fornece os dados agregados de folha para o relatório de remuneração das ESRS S1-13.

## De relance

- **Classificacao**: aggregate-analytics, NAO EU AI Act Alto Risco (nivel coorte >=10 anonimizados k-anonymity)
- **Âncoras de conformidade**: a isonomia da CLT art. 461 e da Súmula TST 6, a Lei 14.611/2023, a LGPD art. 88, a responsabilidade dos administradores da Lei 6.404/76 art. 158 e as ESRS S1 da CSRD
- **Retenção**: 5 anos pelo CTN e pela CLT art. 11, com exclusão conforme a LGPD art. 17
- **Consultas**: à CIPA e aos sindicatos, obrigatória pela Lei 13.467/2017
- **Sanções**: ação coletiva do sindicato, termo de ajuste com o MPT, multa do MTE e sanção da ANPD de até 2 por cento do faturamento, limitada a R$ 50 milhões, além da responsabilidade dos administradores
- **Obrigação de auditoria**: verificação por auditor a partir de 250 empregados pela CSRD e reporte anual ao B3 ISE-B3
- **Conexões**: avaliação de desempenho, planejamento de força de trabalho, sucessão, people analytics, benchmarking de remuneração e reporte de folha

### Distribuicao de Decisores Strategic-HR-Analytics

| Passo | Decisor | Rationale |
|-------|---------|-----------|
| Definir a questão analítica estratégica | H | Alinhamento estratégico do CHRO e do conselho |
| Coleta de dados de RH e ETL | R | Determinístico via plataformas de HCM e data warehouse |
| Anonimização por k-anonymity de no mínimo 10 | R | Determinístico pelo analytics agregado da LGPD art. 88 |
| Tendências agregadas de rotatividade | R | Segmentação agregada com benchmarks da PNAD do IBGE |
| Análise preditiva de rotatividade por ML | A | Faixas de risco de saída por coorte com validação humana |
| Relatório de diversidade das ESRS S1 | R | Determinístico pela CSRD, pela Lei 14.611/2023 e pela Súmula TST 6 |
| Correlações de engajamento e tempo de casa | A | Estatística por ML com validação humana causal |
| Cálculo do ROI de RH em faixas | A | Faixas por ML, com validação de auditor segundo o CPC 33 |
| Relatório da CSRD (ESRS S1) | R | Determinístico, com avaliação de dupla materialidade |
| Reporte anual ao B3 ISE-B3 e à GRI | R | Determinístico pelo Código Brasileiro de Governança Corporativa |
| Painéis de KPI para o board | R | Determinístico nas ferramentas de BI |
| Validação humana dos achados pelo conselho | H | Interpretação causal contra correlação espúria, obrigatória |
| Conexão com os demais agentes | R | Determinístico, via avaliação de desempenho e planejamento |
| Retenção de 5 anos com exclusão pela LGPD art. 17 | R | Determinístico pelo CTN e pela ABNT NBR ISO 30414 |

--- Agente Planejamento Sucessão ---
> Planejamento de sucessão com 9-Box-Grid: Lei 6.404/76 art. 158 responsabilidade administradores, Súmula TST 6 isonomia e ICVM 480 - Readiness com auditoria de viés ABNT NBR ISO 30414.

## Planejamento sucessao como obrigacao strategic compliance

Este agente segue o princípio do [Decision Layer](/br/decision-layer/): cada decisão é baseada em regras, assistida por IA ou atribuída a um humano. Não está classificado pelo [EU AI Act 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) como alto risco, por ser um planejamento estratégico com validação humana obrigatória, mas está sujeito à isonomia da CLT art. 461 e da Súmula TST 6, à [Lei 14.611/2023](http://www.planalto.gov.br/ccivil_03/_ato2023-2026/2023/lei/l14611.htm), à LGPD art. 22, à responsabilidade dos administradores da Lei 6.404/76 art. 158, ao Capítulo 4 do Código Brasileiro de Governança Corporativa e ao precedente extraterritorial do caso Mobley v. Workday.

Um plano de sucessão típico cobre dezenas de posições-chave por ano, do diretor-presidente aos diretores estatutários e papéis técnicos críticos. Levantamentos manuais em Excel produzem retratos desatualizados. O agente gera de forma determinística a matriz de criticidade, a calibração 9-Box, a identificação de alto potencial, as listas de sucessores por prazo de prontidão, o analytics agregado de bench strength, o mapeamento de risco em faixas e os planos de desenvolvimento individuais.

O problema está na cadeia auditável exigida pela ABNT NBR ISO 30414: a validação humana do CHRO, do conselho e dos comitês de pessoas e de auditoria, a trilha de auditoria de viés à luz do caso Mobley v. Workday, a retenção de 5 anos pelo CTN e a verificação por auditor a partir de 250 empregados.

## Responsabilidade dos administradores e o Código de Governança

A [Lei 6.404/76](http://www.planalto.gov.br/ccivil_03/leis/l6404consol.htm) art. 158 estabelece a responsabilidade dos administradores por violação dos deveres legais, abrangendo os deveres de cuidado e de lealdade. Para as companhias abertas na B3, o Capítulo 4 do Código Brasileiro de Governança Corporativa (versão 2024 do IBGC) obriga o Comitê de Pessoas e Sucessão a manter um plano de sucessão formal e documentado para o diretor-presidente, os diretores estatutários e os membros do conselho.

A [Resolução CVM 80/2022](https://conteudo.cvm.gov.br/legislacao/resolucoes/resol080.html) sobre divulgação da remuneração dos administradores exige, no Formulário de Referência, as informações de remuneração e de recursos humanos, inclusive o plano de sucessão. O reporte anual ao B3 ISE-B3 e o Código de Stewardship completam o quadro.

O Comitê de Pessoas e Sucessão reporta anualmente ao conselho e ao comitê de auditoria o bench strength agregado por coorte, como sucessores por posição, profundidade de prontidão e idade média, além do mapeamento de risco de vacância em faixas e dos planos de desenvolvimento agregados.

## Isonomia, igualdade salarial e o viés de alto potencial

A isonomia da [Súmula TST 6](https://www.tst.jus.br/sumulas) e da CLT art. 461, somada às Súmulas TST 442, 387 e 277, forma o quadro jurisprudencial. A identificação de alto potencial e a remuneração dos sucessores não podem discriminar por gênero, raça, etnia, idade ou deficiência, conforme a Lei 9.029/95 e o Estatuto da Igualdade Racial (Lei 12.288/2010).

A [Lei 14.611/2023](http://www.planalto.gov.br/ccivil_03/_ato2023-2026/2023/lei/l14611.htm) e o Decreto 11.795/2023 instituem o Relatório de Transparência Salarial bianual ao MTE para empresas com 100 ou mais empregados, com a apuração do pay gap por gênero, raça e etnia. Para a remuneração dos sucessores, exige-se a análise de igualdade salarial e a trilha de auditoria de viés. As sanções vão da multa do MTE à ação coletiva do sindicato e ao termo de ajuste com o MPT.

O caso Mobley v. Workday firmou precedente de viés algorítmico em software de sucessão e recrutamento, com foco em empregados com mais de 40 anos. No Brasil, aplica-se a analogia à isonomia da CLT art. 461 e o efeito extraterritorial sobre multinacionais com operação ou software nos EUA.

## LGPD art. 22 e a consulta à CIPA e aos sindicatos

A [LGPD](http://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm) art. 22 garante o direito de revisão por pessoa natural nas decisões automatizadas individuais. O agente evita essa decisão automatizada: a calibração 9-Box por ML é um indicador para o comitê de pessoas, com validação humana do CHRO e do conselho e auditoria de viés à luz do caso Mobley v. Workday.

A consulta à CIPA e aos sindicatos é obrigatória, pela Lei 13.467/2017, para introduzir o sistema, com trilha de auditoria de viés e DPIA pela LGPD art. 35. As resoluções da ANPD sobre dosimetria de sanções e transferência internacional aplicam-se quando os dados saem do Brasil ou trafegam em software multinacional.

O Plano Estratégico da ANPD para 2024-2027 prioriza a decisão automatizada e os dados laborais como foco de fiscalização, com DPIA obrigatória, auditoria de viés anual e atuação do DPO. A sanção pode chegar a 2 por cento do faturamento no Brasil, limitada a R$ 50 milhões.

## Taxonomia CBO e ESCO e as considerações de IA

A CBO Classificação Brasileira de Ocupações, com 2.611 ocupações e 596 famílias, é o referencial nacional. A correspondência entre a CBO e a ESCO europeia é essencial para as multinacionais Brasil-UE, já que a ESCO fornece o referencial internacional de competências e o mapeamento de ocupações para a sucessão entre países.

O motor de ML que cruza competências e posições opera sobre essa correspondência e sobre o agente de perfil de carreira, conforme a seção de sucessão da ABNT NBR ISO 30414. As listas de sucessores resultantes são um indicador para o comitê de pessoas, com validação humana obrigatória e auditoria de viés à luz do caso Mobley v. Workday.

O EU AI Act 2024/1689 aponta como alto risco o viés em recrutamento (Anexo III(4)(a)) e as decisões de promoção (Anexo III(4)(b)), com efeito extraterritorial sobre multinacionais Brasil-UE em aplicação escalonada entre 2026 e 2027. Para a sucessão, o agente não se classifica como alto risco, por ser planejamento estratégico com validação humana, mas as obrigações de DPIA, transparência e supervisão humana se aplicam.

## Conexão com perfil de carreira, promoção e força de trabalho

Este agente está integrado a uma cadeia de agentes de estratégia de talentos. O [Skills-Career-Profile-Agent](/br/catalogo-agentes-hr/skills-career-profile-agent/) fornece o inventário de competências, a análise de lacunas e as aspirações de carreira como insumo principal. O [Promotion-Process-Agent](/br/catalogo-agentes-hr/promotion-process-agent/) fornece o histórico de promoções e a trilha de auditoria que validam a calibração 9-Box, e o [Workforce-Planning-Agent](/br/catalogo-agentes-hr/workforce-planning-agent/) as projeções de headcount e as posições-chave futuras.

O [Performance-Review-Documentation-Agent](/br/catalogo-agentes-hr/performance-review-documentation-agent/) fornece os dados agregados de desempenho que alimentam a identificação de alto potencial, e o [Talent-Pool-Management-Agent](/br/catalogo-agentes-hr/talent-pool-management-agent/) o pipeline externo de candidatos. O [Strategic-HR-Analytics-Agent](/br/catalogo-agentes-hr/strategic-hr-analytics-agent/) fornece as tendências de rotatividade e as métricas de diversidade, o [People-Analytics-Agent](/br/catalogo-agentes-hr/people-analytics-agent/) o operacional do dia a dia, e o [Compensation-Benchmarking-Agent](/br/catalogo-agentes-hr/compensation-benchmarking-agent/) as faixas de remuneração dos sucessores. O [Executive-Recruiting-Agent](/br/catalogo-agentes-hr/executive-recruiting-agent/) fornece a lista externa quando a sucessão interna não cobre, o [HR-Document-Management-Agent](/br/catalogo-agentes-hr/hr-document-management-agent/) arquiva os relatórios por 5 anos, e o [Audit-Compliance-Agent](/br/catalogo-agentes-hr/audit-compliance-agent/) verifica a conformidade com as normas do CFC e a auditoria de viés.

## De relance

- **Classificação**: planejamento estratégico, não alto risco pelo EU AI Act, com validação humana obrigatória e sem decisão automática de emprego
- **Âncoras de conformidade**: a isonomia da CLT art. 461 e da Súmula TST 6, a Lei 14.611/2023, a LGPD, a responsabilidade dos administradores da Lei 6.404/76 art. 158, o Capítulo 4 do Código Brasileiro de Governança Corporativa e o precedente Mobley v. Workday
- **Retenção**: 5 anos pelo CTN e pela CLT art. 11, com exclusão conforme a LGPD art. 17
- **Consultas**: à CIPA e aos sindicatos, obrigatória pela Lei 13.467/2017, com DPIA pela LGPD art. 35
- **Sanções**: ação coletiva do sindicato, termo de ajuste com o MPT, multa do MTE e sanção da ANPD de até 2 por cento do faturamento, limitada a R$ 50 milhões, além da responsabilidade dos administradores
- **Obrigação de reporte**: plano de sucessão anual ao conselho pelo Capítulo 4 do Código Brasileiro de Governança Corporativa, reporte ao B3 ISE-B3 e verificação por auditor a partir de 250 empregados
- **Conexões**: perfil de carreira, promoção, planejamento de força de trabalho, avaliação de desempenho, gestão de talent pool, analytics estratégico e recrutamento executivo

### Distribuicao de Decisores Succession-Planning

| Passo | Decisor | Rationale |
|-------|---------|-----------|
| Definir o escopo das posições-chave | H | Alinhamento estratégico do CHRO, do conselho e do comitê de pessoas |
| Matriz de criticidade e mapeamento de risco | R | Determinístico pela ABNT NBR ISO 30414 e pela Lei 6.404/76 art. 158 |
| Coleta de dados de carreira e desempenho via ETL | R | Determinístico via plataformas de HCM e data warehouse |
| Identificação de alto potencial e 9-Box por ML | A | Por ML, com auditoria de viés e validação humana |
| Listas de sucessores por prazo de prontidão | A | Matching por ML com validação do comitê de pessoas |
| Avaliação de prontidão individual e 360 | H | Calibração obrigatória pelo comitê de pessoas e avaliadores externos |
| Analytics agregado de bench strength | R | Agregação por k-anonymity, determinística pela ABNT NBR ISO 30414 |
| Mapeamento de risco de vacância em faixas | A | Por ML, com validação humana causal |
| Planos de desenvolvimento individuais | R | Determinístico pela análise de lacunas e pelo modelo 70-20-10 |
| Diversidade no pipeline de alto potencial | R | Determinístico pela Lei 14.611/2023, pela Súmula TST 6 e pelas ESRS S1-1 |
| Validação humana dos sucessores pelo conselho | H | Verificação de viés e responsabilidade da Lei 6.404/76 art. 158, obrigatória |
| Conexão com os demais agentes de RH | R | Determinístico, via perfil de carreira, promoção e planejamento |
| Retenção de 5 anos com exclusão pela LGPD art. 17 | R | Determinístico pelo CTN e pela gestão de ciclo de vida |

--- Agente Talent Pool Management ---
> Gestão de talent pool: LGPD art. 7 consentimento e art. 18 direitos do titular, CLT art. 461 isonomia e Lei 9.029/1995 - workflows de engajamento em vez de 14 planilhas Excel.

A gestão de talent pool no Brasil cruza vários regimes de conformidade ao mesmo tempo. A LGPD rege o consentimento (art. 7), os direitos do titular (art. 18) e o direito de revisão da decisão automatizada (art. 22), com a DPIA obrigatória pela Resolução ANPD 4/2023. A CLT traz a isonomia (art. 461) e a prescrição de 5 anos (art. 11). A Lei 14.611/2023 institui o Relatório de Transparência Salarial, e a Lei 9.029/1995 veda práticas discriminatórias, com a inversão do ônus da prova da Súmula TST 401. O EU AI Act pode incidir por extraterritorialidade, e o caso Mobley v. Workday trata o fornecedor do algoritmo como respondente direto. Um único talent pool pode, assim, ativar simultaneamente várias obrigações distintas.

## Talent pool como armadilha compliance entre LGPD e CLT art. 461

No Brasil, cobrir uma vaga qualificada leva em média de 90 a 120 dias, quase quatro meses em que projetos ficam parados, equipes compensam e o RH recorre a canais externos que custam milhares de reais por contratação. Ao mesmo tempo, em quase qualquer ATS dormem centenas de perfis de candidatos que se candidataram em algum momento, eram bons, mas chegaram na hora errada ou ficaram em segundo lugar por muito pouco. Esses candidatos são o ativo de seleção mais eficiente de uma empresa, e na maioria das organizações apodrecem em uma base que ninguém mantém: uma pasta no ATS com 400 perfis, dos quais 70 a 80 por cento estão obsoletos, e consentimentos da LGPD vencidos sem rastreamento. E quando surge uma reclamação trabalhista por discriminação ou uma investigação da ANPD, falta a prova de que o consentimento estava válido e de que o match foi feito por critérios fundamentados, conforme a Súmula TST 6 e a Lei 9.029/1995.

## Consentimento e direito de eliminação na LGPD

A base legal para manter dados de candidatos em um talent pool é o consentimento explícito (LGPD art. 7 inc. I). Não basta o consentimento da candidatura original para a vaga específica: o pool exige finalidade própria, duração definida e revogabilidade clara, na forma do art. 8, que pede um consentimento livre, informado, específico e revogável a qualquer momento. O titular tem os direitos do art. 18 (confirmação, acesso, correção, portabilidade, eliminação e revogação) no prazo de 15 dias úteis, e os dados sensíveis do art. 11 ficam fora do matching automatizado. Ao final do tratamento, o art. 25 exige a eliminação real dos dados, não a anonimização. A Resolução ANPD 4/2023 torna a DPIA obrigatória, e a sanção pode chegar a 2 por cento do faturamento, limitada a R$ 50 milhões. O agente verifica o consentimento antes de qualquer apresentação ao recrutador e bloqueia a apresentação, encaminhando para reaquisição, quando ele é inválido.

## Isonomia, igualdade salarial e a retenção de candidatos

A retenção dos dados de candidatos no talent pool segue prazos paralelos. A CLT art. 11 fixa a prescrição de 5 anos para créditos trabalhistas, prazo que se aplica aos dados ligados ao processo seletivo, e a LGPD art. 25 exige a eliminação real ao final do tratamento. A Lei 14.611/2023 institui o Relatório de Transparência Salarial bianual para empresas com 100 ou mais empregados, com plano de mitigação de desigualdades e multa de 3 por cento da folha. A isonomia da CLT art. 461 exige mesmo trabalho e mesma remuneração na mesma função e localidade, e a Súmula TST 6 detalha a equiparação, enquanto a Súmula TST 442 pede critérios objetivos no plano de cargos. A inversão do ônus da prova da Súmula TST 401, a vedação à discriminação da Lei 9.029/1995 e a cota de PCD da Lei 8.213/91 art. 93 completam o quadro. O agente garante uma composição de pool com diversidade rastreada e critérios de match transparentes, sem variáveis sensíveis, e bloqueia o match quando detecta viés discriminatório.

## EU AI Act, talent matching e o caso Mobley v. Workday

A relevância do EU AI Act para empresas brasileiras vai além do óbvio. Subsidiárias de matrizes na UE estão diretamente sob a extraterritorialidade do regulamento, e o mesmo vale para multinacionais que transferem dados de candidatos brasileiros a sistemas de IA hospedados na UE. As obrigações incluem a supervisão humana (Article 14) e a exatidão (Article 15), com sanção de até 35 milhões de euros ou 7 por cento do faturamento global. O caso Mobley v. Workday firmou jurisprudência tratando o fornecedor do algoritmo de recrutamento como respondente direto, relevante para multinacionais americanas, e o PL 2338/2023 antecipa estrutura semelhante no Brasil. Com a DPIA obrigatória pela Resolução ANPD 4/2023 e a norma ABNT NBR ISO 42001 como referência, o agente executa auditoria algorítmica trimestral do match, com detecção de viés e relatório de auditor independente.

## Fluxos de engajamento e sequências de reativação

Estudos do LinkedIn Global Talent Trends 2024 mostram que candidatos deixam de responder a mensagens após 30 a 90 dias sem contato significativo. Quem não ouve nada de uma empresa por seis meses e depois recebe um e-mail genérico não tem motivo para responder: o pool existe tecnicamente, mas na prática está vazio. O agente executa fluxos de engajamento e sequências de reativação por cadência (3, 6 e 12 meses, ou pontual ao surgir uma vaga). Cada comunicação traz a finalidade específica, a identificação do controlador e a opção de saída fácil (LGPD art. 9), com a acessibilidade exigida pela LBI. Em paralelo, monitora a validade do consentimento, alerta 90 dias antes do vencimento e dispara a renovação proativa; vencido sem renovação ou revogado, os dados são eliminados de verdade, não anonimizados (art. 25), com registro da eliminação em trilha de auditoria. Quando uma nova vaga é aberta, o agente percorre o pool ativo em busca de perfis que encaixem, fazendo o match por variáveis fundamentadas como competências, experiência, senioridade, disponibilidade e localidade, sem dados sensíveis. O resultado é uma lista ranqueada para o recrutador, com pontuação e justificativa textual e o direito de revisão da LGPD art. 22. O recrutador decide se e como contata, sem contato automático.

## Conexão com triagem, due diligence e agendamento

A plataforma de gestão de consentimento que este agente constrói resolve um problema que vai muito além do talent pool. Qualquer agente que armazene dados pessoais além da finalidade imediata precisa do mesmo motor: consentimento documentado, controle de prazos, eliminação automática e trilha de auditoria. O agente o constrói uma vez, e os demais o reutilizam: o de triagem de currículos para vagas ativas, o de due diligence de pré-contratação (com a LGPD art. 11 e a Lei 9.029/1995), o de agendamento de entrevista (com a acessibilidade da LBI), o de recrutamento executivo e o de gestão de dados de empregados. O match por competências também não é função isolada, e sim um arcabouço usado na triagem, na sucessão executiva e na mobilidade interna. À primeira vista, a gestão de talent pool parece uma ferramenta operacional; na prática, é uma decisão de infraestrutura. O pool que hoje dorme esquecido no ATS vira vantagem permanente de seleção, ou continua um passivo de proteção de dados com prazo de validade. As sanções são cumuláveis e podem superar R$ 50 milhões.

## De relance

- Captação no pool com consentimento explícito (LGPD art. 7), com finalidade específica, duração definida e revogabilidade
- Segmentação de candidatos por competências, experiência, senioridade e disponibilidade, sem os dados sensíveis do art. 11 da LGPD
- Fluxos de engajamento e reativação por cadência de 3, 6 e 12 meses, ou pontual ao surgir uma vaga
- Match com novas vagas por variáveis fundamentadas, conforme a Súmula TST 6 e a Lei 9.029/1995
- Auditoria algorítmica trimestral do match, com detecção de viés, pelo Article 15 do EU AI Act e pela Resolução ANPD 4/2023
- Mapeamento de talentos por área, senioridade e diversidade, conforme a Lei 14.611/2023 e a LBI
- Direitos do titular da LGPD art. 18 (acesso, correção, portabilidade, eliminação e revogação) no prazo de 15 dias úteis
- Sanções cumuláveis que podem superar R$ 50 milhões, somando ANPD, MTE e EU AI Act

### Distribuição de Decisores Talent-Pool-Management

| Decisor | Quantidade | Etapas |
| --- | --- | --- |
| R (regra determinística) | 11 | Captação, verificação e monitoramento do consentimento, fluxos de engajamento, verificação antes da apresentação, apresentação do ranking, mapeamento de talentos, atendimento dos direitos do titular, auditoria algorítmica trimestral, eliminação dos dados vencidos e transferência para a triagem |
| A (indicador ML assistido) | 2 | Segmentação de candidatos por competências e match com novas vagas |
| H (confirmação humana) | 1 | Contato pelo recrutador e escalada dos casos de julgamento ao DPO, ao Compliance Officer e ao Departamento Jurídico |

--- Agente Cadastro HR e eSocial Admissão ---
> Cadastro de funcionário com plano de saúde, dependentes IRRF e categoria CLT - CTPS Digital Lei 13.874/2019, eSocial S-2200 admissão e atestados em tempo conforme LGPD art. 11.

## Declarações tributárias, INSS, FGTS e atestados

Este agente segue o princípio do [Decision Layer](/br/decision-layer/): cada decisão é baseada em regras, assistida por IA ou explicitamente atribuída a um humano. Não está classificado pelo [EU AI Act 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) como sistema de alto risco, por operar por regras determinísticas e sem decisões de RH, mas está sujeito às obrigações da [IN RFB 1.500/2014](https://www.gov.br/receitafederal/pt-br) sobre o IRRF, do CTN, da Lei 8.212/91 do INSS, da Lei 8.036/1990 do FGTS, da CLT, das normas do CFC e do eSocial.

Um departamento de tributos e contribuições sociais típico processa de centenas a milhares de itens de declaração por mês a partir das folhas. Os recolhimentos manuais por dezenas de portais separados, do e-CAC à Conectividade Social, levam dias e são propensos a erro. O agente gera as declarações em segundos: as da Receita (DIRF, DCTFWeb e EFD-Reinf), os DARFs e o DAS, a contribuição do INSS, o FGTS, os eventos do eSocial e o processamento dos atestados.

O problema não está no volume, e sim na cadeia auditável exigida pelas normas do CFC: a documentação processual, o princípio dos quatro olhos entre o especialista de folha e o diretor financeiro, a trilha de auditoria com usuário, data e estado anterior, a retenção de 5 anos pelo CTN e de 30 anos para o FGTS, e a fiscalização da Receita, do INSS, do MTE e da Caixa, com amostragem do auditor.

## IRRF, DIRF, DCTFWeb e EFD-Reinf

A [IN RFB 1.500/2014](https://normas.receita.fazenda.gov.br/) e a Lei 7.713/1988 estabelecem as obrigações do IRRF: a tabela progressiva mensal, isenta até R$ 2.428,80 em 2026, a DIRF anual e as declarações mensais DCTFWeb e EFD-Reinf.

O cálculo mensal do IRRF opera de forma determinística sobre os dados da folha: do salário, descontam-se o INSS, os dependentes, a pensão alimentícia e a previdência oficial para chegar à base de cálculo, sobre a qual incide a tabela progressiva atualizada anualmente. O recolhimento é feito por DARF código 0561 até o dia 20 do mês seguinte, e os prazos das declarações vão da DIRF, até 28 de fevereiro, à DCTFWeb mensal, até o dia 15 do mês seguinte, sempre com assinatura digital ICP-Brasil.

As violações implicam autuação da Receita entre 75 e 150 por cento (Lei 9.430/96 art. 44), com juros pela Selic e crime tributário com reclusão de 2 a 5 anos (Lei 8.137/90), além da responsabilidade dos administradores da Lei 6.404/76 art. 158. O CTN obriga a retenção por 5 anos e o arquivamento eletrônico.

## INSS, contribuições patronais e a substituição da GFIP

A [Lei 8.212/91](http://www.planalto.gov.br/ccivil_03/leis/l8212cons.htm), no art. 22, estabelece as contribuições patronais: a contribuição previdenciária patronal de 20 por cento sobre a folha, o RAT de 1 a 3 por cento conforme o grau de risco do CNAE, a contribuição a terceiros de cerca de 5,8 por cento e o FAP, um fator entre 0,5 e 2,0 publicado anualmente.

A Lei 8.213/91 e o Decreto 3.048/1999 regulam os benefícios e a contribuição progressiva do trabalhador, de 7,5 a 14 por cento, conforme a tabela atualizada anualmente. A GFIP foi substituída pela DCTFWeb desde 2018, com recolhimento mensal até o dia 15 do mês seguinte por DARF de receita específica do INSS.

Para o afastamento por doença, o auxílio-doença passa ao INSS após os 15 primeiros dias a cargo do empregador, via e-Benefício e Atestmed, com a comunicação pelo eSocial S-2230. Na terceirização, a Súmula TST 331 firma a responsabilidade subsidiária pelas contribuições, e a Lei 9.711/98 impõe a retenção de 11 por cento de INSS na fonte sobre a cessão de mão de obra.

## Eventos do eSocial, DARF e DAS

O [eSocial (Decreto 8.373/2014)](http://www.planalto.gov.br/ccivil_03/_ato2011-2014/2014/decreto/d8373.htm) define os eventos de folha obrigatórios: o S-1010 codifica as rubricas de remuneração e desconto e suas bases de IRRF, INSS e FGTS; o S-1200 traz a remuneração mensal do trabalhador; o S-1210 registra os pagamentos e os tributos retidos; e o S-1299 faz o fechamento mensal que apura as contribuições e o IRRF na DCTFWeb.

Os DARFs usam códigos de receita específicos, como o 0561 para o IRRF, e o DAS recolhe o Simples Nacional (Lei Complementar 123/2006). O FGTS é recolhido até o dia 7 do mês seguinte pela Conectividade Social, com 8 por cento sobre a folha e a guia rescisória nas dispensas, mais a multa rescisória.

O atraso no eSocial gera multa de R$ 800 a R$ 2.500 por evento, e a retenção é de 5 anos pelo CTN. A transmissão é assinada com certificado ICP-Brasil.

## Atestados, auxílio-doença e o dado sensível de saúde

Os atestados médicos são processados de forma determinística conforme a Lei 605/49, a Resolução CFM 1.851/2008 e o INSS art. 60 da Lei 8.213/91. Os 15 primeiros dias de afastamento são pagos pelo empregador; depois disso, o INSS assume com o auxílio-doença, via e-Benefício e Atestmed, que avalia automaticamente os casos elegíveis até 180 dias sem perícia presencial.

A comunicação pelo eSocial S-2230 é obrigatória. O CID deve ser informado conforme a Resolução CFM 1.851/2008, sempre com o sigilo médico observado.

O atestado é dado sensível de saúde sob a LGPD art. 11 e exige DPIA, atuação do DPO, canal específico de tratamento e o sigilo médico do CFM. O motor de ciclo de vida arquiva os atestados por 5 anos, pelo CTN e pela CLT art. 11, com exclusão conforme a LGPD art. 17.

## Conexão com processamento, contabilização e reporte de folha

Este agente está integrado a uma cadeia de agentes especializados de RH. O [Payroll-Calculation-Agent](/br/catalogo-agentes-hr/payroll-calculation-agent/) gera o cálculo bruto-líquido com as retenções de IRRF e as contribuições do INSS, que servem de insumo para este agente. O [Payroll-Processing-Agent](/br/catalogo-agentes-hr/payroll-processing-agent/) faz o cálculo bruto-líquido completo, o [Payroll-Accounting-Agent](/br/catalogo-agentes-hr/payroll-accounting-agent/) gera os lançamentos contábeis das folhas encerradas, e o [Payroll-Reporting-Agent](/br/catalogo-agentes-hr/payroll-reporting-agent/) faz o reporte de folha conforme a Lei 14.611/2023 e as ESRS S1-13. O [Payroll-Tax-Agent](/br/catalogo-agentes-hr/payroll-tax-agent/) verifica a conformidade das retenções de IRRF, o [Audit-Compliance-Agent](/br/catalogo-agentes-hr/audit-compliance-agent/) a conformidade com as normas do CFC, e o [HR-Document-Management-Agent](/br/catalogo-agentes-hr/hr-document-management-agent/) arquiva os DARFs, as DCTFWebs e as demais guias por 5 anos, e por 30 anos no caso do FGTS.

## De relance

- **Classificação**: Compliance-Support, NÃO EU AI Act Alto Risco (deterministic-rules)
- **Âncoras de conformidade**: a IN RFB 1.500/2014, o CTN, a Lei 8.212/91 do INSS, a Lei 8.036/1990 do FGTS, a CLT, a LGPD, o eSocial e as normas do CFC
- **Retenção**: 5 anos pelo CTN e pela CLT art. 11, e 30 anos para o FGTS (Lei 8.036/1990)
- **Consultas**: à CIPA e aos sindicatos, obrigatória pela Lei 13.467/2017
- **Sanções**: autuação da Receita de 75 a 150 por cento, com juros pela Selic e reclusão de 2 a 5 anos (Lei 8.137/90), multa do INSS e do FGTS, multa por atraso no eSocial e sanção da ANPD de até 2 por cento do faturamento, limitada a R$ 50 milhões
- **Obrigação de auditoria**: fiscalização da Receita, do MTE, do INSS e da Caixa, com amostragem do auditor do CFC
- **Conexões**: agentes de cálculo, processamento, contabilização, reporte e imposto de folha

### Distribuição de Decisores Tax-Social-Insurance

| Passo | Decisor | Rationale |
|-------|---------|-----------|
| Cálculo mensal do IRRF | R | Determinístico pela IN RFB 1.500/2014 e pela Lei 7.713/1988 |
| Geração da DIRF, da DCTFWeb e da EFD-Reinf | R | Determinístico, com assinatura ICP-Brasil no e-CAC |
| Cálculo da contribuição patronal do INSS | R | Determinístico pela Lei 8.212/91 e pelo Decreto 3.048/1999 |
| Contribuição do trabalhador pela DCTFWeb | R | Determinístico pela Lei 8.213/91, mensal |
| FGTS pela Conectividade Social | R | Determinístico pela Lei 8.036/1990 |
| Eventos do eSocial | R | Determinístico pelo Decreto 8.373/2014 |
| DARF e DAS do Simples Nacional | R | Determinístico pela Lei Complementar 123/2006 |
| Atestados e auxílio-doença do INSS | R | Determinístico pela Lei 605/49 e pelo INSS art. 60 |
| Detecção de anomalias | A | Detecção por ML com validação humana |
| Aprovação do diretor financeiro | H | Quatro olhos obrigatório, conforme as normas do CFC |
| Envio à Receita, ao INSS e à Caixa | R | Determinístico, com assinatura ICP-Brasil |
| Retenção de 5 anos com exclusão pela LGPD art. 17 | R | Determinístico pelo CTN e pelos 30 anos do FGTS |
| Comunicação de incidentes à ANPD em 72 horas | R | Determinístico pela LGPD art. 33 |
| Conformidade com a Lei Anticorrupção | H | Validação humana obrigatória |

--- Agente Controle de Ponto ---
> Controle de ponto: CLT art. 58-75 jornada, art. 73 adicional noturno 20%, Portaria MTE 671/2021 REP-A/REP-P e Súmula TST 366 - validação determinista com eSocial S-1200 e LGPD art. 88.

O processamento de marcações de ponto no Brasil cruza vários eixos de compliance ao mesmo tempo. A CLT (art. 58 a 75) define jornada normal de 8 horas diárias e 44 semanais, horas extras com adicional mínimo de 50 por cento, intervalos intrajornada, adicional noturno de 20 por cento entre 22h e 5h e controle de ponto obrigatório para empresas com 20 ou mais empregados. A Lei 13.467/2017 trouxe o negociado sobre o legislado e o banco de horas, e a jurisprudência fixou os minutos residuais (Súmula TST 366) e os intervalos (Súmula TST 437). A Portaria MTE 671/2021 rege o Registrador Eletrônico de Ponto, a LGPD trata a biometria como dado sensível (art. 11) e o eSocial recebe a remuneração mensal. Uma única marcação pode, portanto, acionar simultaneamente várias dessas obrigações.

## O problema não é uma marcação - é o volume com tolerância zero a erro

Toda manhã chegam novas marcações de ponto - nas segundas-feiras, depois do fim de semana, são milhares. Cada uma desencadeia uma cascata: vinculação ao colaborador, verificação contra a escala programada, cálculo do período trabalhado, identificação de horas extras, adicional noturno, intervalo intrajornada e comunicação ao eSocial. Em uma empresa com 2.000 colaboradores em turnos, são de 30.000 a 60.000 marcações por mês, cada uma um ato com prazos legais e consequências em caso de descumprimento. A CLT art. 74 torna o controle de ponto obrigatório para empresas com 20 ou mais empregados, e a Portaria MTE 671/2021 define os tipos de Registrador Eletrônico de Ponto. O problema não é a complexidade de uma marcação isolada - é o volume combinado com tolerância zero a erro e o prazo do eSocial até o dia 7 do mês seguinte.

## Jornada, horas extras e adicional noturno: o ponto mais crítico

A verificação automatizada das marcações contra a CLT é o ponto mais crítico do agente: jornada normal de 8 horas diárias e 44 semanais (art. 58), horas extras limitadas a 2 por dia com adicional mínimo de 50 por cento e banco de horas (art. 59), intervalos intrajornada (art. 71) e adicional noturno de 20 por cento entre 22h e 5h (art. 73). A jurisprudência completa a matriz: os minutos residuais da Súmula TST 366 (5 minutos antes do início e 5 após o fim, totalizando 10 por turno, considerados não trabalhados), os intervalos da Súmula TST 437 e a base de cálculo das horas extras da Súmula TST 264, que inclui todas as parcelas de natureza salarial. O agente confere cada marcação contra essa matriz antes do processamento e bloqueia quando a conformidade não é verificada, escalando ao Departamento Pessoal e ao Sindicato.

## Convenções coletivas e a regra aplicável a cada colaborador

Cada marcação percorre ao menos quatro estações: o Departamento Pessoal recebe, o sistema valida o REP, o Sindicato verifica as cláusulas coletivas e o INSS recebe via eSocial. Dependendo do caso, somam-se o DPO, o Compliance Officer e o Departamento Jurídico. A Lei 13.467/2017 (art. 611-A) admite o negociado sobre o legislado - jornada flexível, banco de horas individual, acordo individual escrito, jornada 12x36 -, e a Súmula TST 277 reconhece as negociações coletivas. O evento do eSocial precisa ser transmitido no prazo, o Sindicato precisa ser consultado, a folha precisa conhecer as horas extras e o adicional noturno, e o motor de regras precisa selecionar o conjunto aplicável a cada colaborador conforme convenção, acordo individual e tipo de contrato. Feito à mão, são quatro sistemas e quatro etapas a cada marcação; com 60.000 por mês, um processo controlável vira uma construção frágil de planilhas, lembretes e esperança. O agente roteia automaticamente a integração com o eSocial e o cálculo proporcional, com assinatura eletrônica ICP-Brasil.

## Biometria é dado sensível: a LGPD exige arquitetura, não só criptografia

As marcações biométricas (facial, digital ou íris) são dados pessoais sensíveis pela LGPD art. 11 e só podem ser tratadas com base legal específica. Isso exige mais do que controle de acesso e criptografia: exige uma arquitetura que imponha a minimização de dados. A ANPD recomenda DPIA para o ponto biométrico (Resolução 4/2023) e pode aplicar sanção de até 2 por cento do faturamento, limitada a R$ 50 milhões. O agente processa apenas o estritamente necessário, mantém os templates biométricos não reversíveis e documenta cada regra de processamento em acordo com o Sindicato. Quem encaminha marcações biométricas em PDF por e-mail a gestores cria um problema de proteção de dados, mesmo sem intenção; um agente baseado em regras não tem esse problema estruturalmente, porque a arquitetura de informação define quais dados chegam a cada destinatário.

## Infraestrutura para os agentes de folha, atestados e licenças

Dois dos três componentes centrais deste agente - o motor de regras da CLT versionado e o fluxo de integração com o eSocial - são infraestrutura genérica. Todo agente que aplica regras de jornada precisa de cálculos versionados com períodos de vigência, e todo agente que orquestra notificações governamentais precisa de um motor de fluxo com monitoramento de prazos. O agente de folha calcula a remuneração mensal contra as marcações validadas; o de atestados confronta os afastamentos com as escalas; o de licenças (férias, maternidade, paternidade) referencia as mesmas marcações. Quem começa pelo controle de ponto instala a infraestrutura de toda decisão de jornada que os agentes seguintes tomarão. As sanções podem se acumular: ANPD de até 2 por cento do faturamento, limitada a R$ 50 milhões, somada às Súmulas TST 366 e 437 e à fiscalização do MTE.

## De relance

- Validação determinística do ponto, com cálculo de horas extras (CLT art. 59, adicional mínimo de 50 por cento) e adicional noturno de 20 por cento (art. 73)
- Suporte aos três tipos de Registrador Eletrônico de Ponto da Portaria MTE 671/2021 (REP-A, REP-P e REP-C)
- Aplicação dos minutos residuais da Súmula TST 366 e da tolerância de 6 minutos da CLT art. 74
- Verificação dos intervalos intrajornada da CLT art. 71, com a Súmula TST 437 quando o intervalo não é concedido
- Banco de horas da Lei 13.467/2017, com a compensação de jornada da Súmula TST 85
- Tratamento da biometria como dado sensível (LGPD art. 11), com DPIA recomendada pela ANPD (Resolução 4/2023)
- Comunicação da remuneração mensal ao eSocial (S-1200) até o dia 7 do mês seguinte
- Sanções que podem se acumular até R$ 50 milhões: ANPD, Súmulas TST 366 e 437 e fiscalização do MTE

### Distribuicao de Decisores Time-Attendance

| Decisor | Quantidade | Etapas |
| --- | --- | --- |
| R (regra determinística) | 13 | Ingestão e validação das marcações, vínculo com a escala, limites de jornada (CLT art. 58 a 62), cálculo de horas extras e adicional noturno, intervalos (art. 71), minutos residuais (Súmula TST 366), finalização do registro, comunicação ao eSocial e auditoria trimestral |
| A (indicador ML assistido) | 1 | Detecção de anomalias (registros ausentes, durações implausíveis, marcação dupla, horas extras suspeitas) |
| H (confirmação humana) | 2 | Confirmação de anomalia pelo Departamento Pessoal com o Sindicato e escalonamento dos casos de julgamento ao DPO e ao Sindicato |

--- Agente Eficácia de Treinamento ---
> Medição de eficácia de treinamento: Modelo Kirkpatrick 4 níveis, Phillips ROI 5 níveis e Lei 12.513/2011 PRONATEC - mapping CBO/ESCO com CSRD ESRS S1-13 training investment.

## Medir eficácia de treinamento com Kirkpatrick e Phillips ROI

Este agente segue o princípio do [Decision Layer](/br/decision-layer/): cada decisão é baseada em regras, assistida por IA ou explicitamente atribuída a um humano. Não é um sistema de alto risco segundo o [EU AI Act 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/oj), por operar no nível da coorte e sem decisões individuais, mas está sujeito a exigências firmes: a formação profissional como direito da CLT (art. 7, inc. III), o [PRONATEC](http://www.planalto.gov.br/ccivil_03/_ato2011-2014/2011/lei/l12513.htm), a base de analytics agregada da LGPD (art. 88) e a verificação por auditor obrigatória a partir de 250 empregados.

O modelo de quatro níveis de Kirkpatrick - reação, aprendizagem, comportamento e resultados - e o Phillips ROI, que o estende com um quinto nível financeiro, são há décadas o referencial dominante. O agente processa milhares de pontos de dados por trimestre vindos de LMS como Cornerstone, Coursera, Udemy, Moodle e dos módulos de aprendizagem de SAP e Workday. Medições manuais levam dias e produzem painéis superficiais; o agente gera os analytics agregados em segundos, sem perfilamento individual.

O problema não está no volume. Está na cadeia auditável conforme a ESRS: documentação processual, validação humana do CHRO, da Diretoria de Treinamento e do Comitê ESG, registro com usuário, horário e antes/depois, retenção por cinco anos e verificação por auditor a partir de 250 empregados.

## O marco da formação profissional: PRONATEC, INEP e MEC

A [Lei 12.513/2011 (PRONATEC)](http://www.planalto.gov.br/ccivil_03/_ato2011-2014/2011/lei/l12513.htm), o Programa Nacional de Acesso ao Ensino Técnico e Emprego, junto com a LDB (Lei 9.394/1996) e o Plano Nacional de Educação, estabelece o marco da formação profissional no Brasil. O INEP e o MEC fornecem os benchmarks educacionais nacionais que servem de referência à medição.

O Sistema S - SENAI, SENAC, SENAR e SENAT - é um dos pilares da formação profissional, financiado por contribuições obrigatórias. A cota de aprendizes, de 5 a 15 por cento das vagas, segue o Estatuto da Criança e do Adolescente (art. 60 a 69) e abrange jovens de 14 a 24 anos, com monitoramento do MTE e do INSS.

A LBI (Lei 13.146/2015) exige acessibilidade pedagógica na formação (art. 13) e educação inclusiva (art. 27 e 28), e a cota de PCD de 2 a 5 por cento aplica-se às empresas com mais de 100 empregados (Lei 8.213/1991, art. 93). As convenções coletivas sobre formação são regidas pela Súmula TST 277 e pelo negociado sobre o legislado da Lei 13.467/2017.

## Taxonomias CBO e ESCO e o relatório ESRS S1-13

A CBO (Classificação Brasileira de Ocupações) e a ESCO europeia fornecem a taxonomia de ocupações e competências que sustenta o mapeamento de habilidades. Conselhos profissionais como CONFEA, CFC, OAB e CRP exigem educação continuada e reciclagem.

A [CSRD](https://eur-lex.europa.eu/eli/dir/2022/2464/oj) (Diretiva UE 2022/2464) tem alcance extraterritorial sobre multinacionais com presença na UE, e seus relatórios ESRS - sobre investimento em treinamento por colaborador e diversidade na formação - exigem verificação por auditor a partir de 250 empregados, em aplicação escalonada entre 2024 e 2026.

Multinacionais brasileiras com presença na UE precisam cumprir ambos os marcos ao mesmo tempo. O caso Mobley v. Workday, nos EUA, é um precedente de viés de IA que reforça a distinção essencial: este agente faz medição no nível da coorte, não scoring individual.

## LGPD art. 88, ANPD e a consulta a CIPA e sindicatos

A [LGPD](http://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm) (art. 88) reconhece a analytics agregada como base legal para o tratamento de dados de RH com finalidade de pesquisa e estatística, o que se aplica à medição de treinamento. O motor de anonimização com k-anonimato a partir de 10 colaboradores garante a ausência de perfilamento individual e de reidentificação.

A CIPA e os sindicatos são consultados na introdução do sistema (Lei 13.467/2017), com trilha de auditoria de viés e DPIA pela LGPD (art. 35). Quando os dados saem do Brasil, aplicam-se as resoluções da ANPD sobre transferência internacional.

O direito de revisão por pessoa natural da LGPD (art. 22) não incide aqui, pois a medição no nível da coorte não decide sobre indivíduos. A Lei Anticorrupção (Lei 12.846/2013) e o programa de integridade do Decreto 11.129/2022, por sua vez, exigem treinamento de compliance, com sanções de até 20 por cento do faturamento bruto.

## Como os outros agentes de RH se conectam à medição

O agente de eficácia de treinamento está embutido em um conjunto de agentes especializados de L&D. O [Skills-Career-Profile-Agent](/br/catalogo-agentes-hr/skills-career-profile-agent/) fornece os dados de competências agregados, com mapeamento ESCO e CBO, como entrada para a medição. O [Performance-Review-Documentation-Agent](/br/catalogo-agentes-hr/performance-review-documentation-agent/) fornece os dados de desempenho agregados antes e depois do treinamento. O [Learning-Path-Recommendation-Agent](/br/catalogo-agentes-hr/learning-path-recommendation-agent/) recebe os achados para otimizar recomendações futuras.

O [Strategic-HR-Analytics-Agent](/br/catalogo-agentes-hr/strategic-hr-analytics-agent/) integra a medição aos analytics globais. O [People-Analytics-Agent](/br/catalogo-agentes-hr/people-analytics-agent/) fornece os analytics operacionais do dia a dia, o [Compensation-Benchmarking-Agent](/br/catalogo-agentes-hr/compensation-benchmarking-agent/) fornece as faixas de remuneração para o ROI, e o [Workforce-Planning-Agent](/br/catalogo-agentes-hr/workforce-planning-agent/) fornece as projeções de quadro. O [Succession-Planning-Agent](/br/catalogo-agentes-hr/succession-planning-agent/) cuida do pipeline de sucessão, o [HR-Document-Management-Agent](/br/catalogo-agentes-hr/hr-document-management-agent/) arquiva os analytics ESRS S1-13 por cinco anos, e o [Audit-Compliance-Agent](/br/catalogo-agentes-hr/audit-compliance-agent/) verifica a conformidade com a Lei Anticorrupção.

## De relance

- **Classificação**: medição analítica, não alto risco no EU AI Act (nível da coorte, anonimizado com k-anonimato)
- **Âncoras de compliance**: formação profissional da CLT (art. 7, inc. III), PRONATEC, LBI, base de analytics agregada da LGPD (art. 88) e relatório CSRD ESRS S1-13
- **Frameworks de medição**: os quatro níveis de Kirkpatrick (reação, aprendizagem, comportamento e resultados) e o Phillips ROI, que acrescenta o ROI financeiro
- **Retenção**: cinco anos, conforme as prescrições do CTN e da CLT, com eliminação posterior pela LGPD (art. 17)
- **Consultas**: CIPA e sindicatos, obrigatórias na introdução do sistema (Lei 13.467/2017)
- **Sanções**: ação coletiva sindical, atuação do MPT, ANPD de até 2 por cento do faturamento (limitada a R$ 50 milhões) e Lei Anticorrupção de até 20 por cento do faturamento bruto
- **Auditoria**: verificação por auditor obrigatória a partir de 250 empregados na CSRD (ESRS S1-13)
- **Sistema S**: SENAI, SENAC, SENAR e SENAT, com cota de aprendizes de 5 a 15 por cento
- **Integração**: Perfil de Carreira, Avaliação de Desempenho, Trilhas de Aprendizagem, Analytics estratégico de RH, Planejamento de Quadro e Auditoria de compliance

### Distribuicao de Decisores Training-Effectiveness

| Passo | Decisor | Rationale |
|-------|---------|-----------|
| Definir objetivos do treinamento | H | Briefing da Diretoria de Treinamento e do CHRO, alinhado à estratégia |
| Coleta de dados dos LMS e ETL | R | Integração determinística aos LMS e ao data warehouse |
| Anonimização com k-anonimato (mínimo 10) | R | Base de analytics agregada da LGPD (art. 88), determinística |
| Kirkpatrick níveis 1 e 2 (reação e aprendizagem) | R | Pré e pós-teste com segmentação agregada, determinístico |
| Kirkpatrick nível 3 (comportamento) por ML | A | Faixas de transferência por coorte, com validação humana |
| Kirkpatrick nível 4 e Phillips ROI por ML | A | Faixas com validação por auditor |
| Mapeamento de competências CBO e ESCO | R | Taxonomia e mapeamento de habilidades, determinístico |
| Relatório CSRD ESRS S1-13 | R | Dupla materialidade e verificação por auditor, determinístico |
| PRONATEC, Sistema S e acessibilidade da LBI | R | Cota de aprendizes e de PCD, determinístico |
| Dashboards de KPI para o Conselho | R | Painéis com narrativa em pirâmide de Minto, determinístico |
| Validação humana dos achados e Comitê ESG | H | Distinção obrigatória entre causalidade e correlação espúria |
| Integração com os outros agentes de RH | R | Conexão determinística a Perfil de Carreira e Desempenho |
| Treinamento de compliance (Lei 12.846/2013) | R | Programa de integridade antissuborno, determinístico |

--- Agente Análise Necessidades Treinamento ---
> Skills-Gap analysis e priorização: CBO Classificação Brasileira Ocupações, ESCO European Skills e Lei 12.513/2011 PRONATEC - Workforce-Planning em vez de treinamento sem rumo.

## Analisar necessidades de treinamento em vez de multiplicar cursos

Este agente segue o princípio do [Decision Layer](/br/decision-layer/): cada decisão é baseada em regras, assistida por IA ou explicitamente atribuída a um humano. Não é um sistema de alto risco segundo o [EU AI Act 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/oj), por operar no nível da coorte e sem decisões individuais, mas está sujeito a exigências firmes: a formação profissional como direito da CLT (art. 7, inc. III), o [PRONATEC](http://www.planalto.gov.br/ccivil_03/_ato2011-2014/2011/lei/l12513.htm), a base de analytics agregada da LGPD (art. 88) e a verificação por auditor obrigatória a partir de 250 empregados.

A maioria das organizações opera com uma proliferação descontrolada de treinamentos: um catálogo de LMS com centenas de cursos, baixa taxa de conclusão e nenhum alinhamento estratégico. O sintoma é ROI baixo, investimento disperso e lacunas de competências persistentes; a causa é a ausência de uma análise sistemática de necessidades. O agente examina milhares de pontos de dados por trimestre vindos do HCM, dos módulos de competências de SAP e Workday e de LMS como Cornerstone, Coursera, Moodle e Alura. Análises manuais levam semanas; o agente gera os analytics agregados em segundos, sem perfilamento individual.

O problema não está no volume de cursos. Está na ausência de uma cadeia auditável conforme a ESRS: documentação processual, validação humana do CHRO, da Diretoria de Treinamento e do Comitê ESG, registro com usuário, horário e antes/depois, retenção por cinco anos e verificação por auditor a partir de 250 empregados.

## Skills Gap Analysis com as taxonomias CBO, ESCO e INEP

A Skills Gap Analysis compara as competências atuais (o inventário de habilidades) com as competências futuras requeridas. A CBO (Classificação Brasileira de Ocupações) e a ESCO europeia fornecem a taxonomia unificada de ocupações e competências, e conselhos profissionais como CONFEA, CFC, OAB e CRP exigem educação continuada e reciclagem. O INEP e o MEC fornecem os benchmarks educacionais nacionais que validam o inventário.

O modelo de ML estima as lacunas em faixas com intervalos de confiança, não em estimativas pontuais, devolvendo resultados no nível da coorte (no mínimo 10 colaboradores anonimizados, com k-anonimato), com p-values e correlações com desempenho, tempo de casa e departamento. A priorização é multicritério - impacto no KPI do negócio, urgência, número de colaboradores afetados e custo estimado - com faixas de ROI.

A distinção essencial em relação ao agente de eficácia de treinamento: este analisa as necessidades (entrada do planejamento), enquanto aquele mede a eficácia (saída da medição). O caso Mobley v. Workday, nos EUA, é um precedente de viés de IA que reforça que este agente faz análise no nível da coorte, não scoring individual.

## A formação profissional como direito: CLT e PRONATEC

A [Lei 12.513/2011 (PRONATEC)](http://www.planalto.gov.br/ccivil_03/_ato2011-2014/2011/lei/l12513.htm), junto com a LDB (Lei 9.394/1996) e o Plano Nacional de Educação, estabelece o marco da formação profissional no Brasil. A CLT consagra a formação profissional como direito fundamental do trabalhador (art. 7, inc. III) e trata da aprendizagem (art. 422 a 433).

O Sistema S - SENAI, SENAC, SENAR e SENAT - é um dos pilares da formação profissional, financiado por contribuições obrigatórias. A cota de aprendizes, de 5 a 15 por cento das vagas, segue o Estatuto da Criança e do Adolescente (art. 60 a 69) e abrange jovens de 14 a 24 anos, com monitoramento do MTE e do INSS.

A LBI (Lei 13.146/2015) exige acessibilidade pedagógica na formação (art. 13) e educação inclusiva, e a cota de PCD de 2 a 5 por cento aplica-se às empresas com mais de 100 empregados (Lei 8.213/1991, art. 93). As convenções coletivas sobre formação são regidas pela Súmula TST 277 e pela Lei 13.467/2017. A [CSRD](https://eur-lex.europa.eu/eli/dir/2022/2464/oj) (Diretiva UE 2022/2464), com alcance extraterritorial sobre multinacionais, exige relatórios ESRS sobre investimento em treinamento e diversidade, com verificação por auditor a partir de 250 empregados.

## LGPD art. 88, ANPD e a consulta a CIPA e sindicatos

A [LGPD](http://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm) (art. 88) reconhece a analytics agregada como base legal para o tratamento de dados de RH com finalidade de pesquisa e estatística, o que se aplica à análise de necessidades de treinamento. O motor de anonimização com k-anonimato a partir de 10 colaboradores garante a ausência de perfilamento individual e de reidentificação.

A CIPA e os sindicatos são consultados na introdução do sistema (Lei 13.467/2017), com trilha de auditoria de viés e DPIA pela LGPD (art. 35). Quando os dados saem do Brasil, aplicam-se as resoluções da ANPD sobre transferência internacional.

O direito de revisão por pessoa natural da LGPD (art. 22) não incide aqui, pois a análise no nível da coorte não decide sobre indivíduos nem sobre quem treinar. A Lei Anticorrupção (Lei 12.846/2013) e o programa de integridade do Decreto 11.129/2022, por sua vez, exigem treinamento de compliance, com sanções de até 20 por cento do faturamento bruto. O registro guarda usuário, horário, ação e antes/depois, com retenção por cinco anos e eliminação após o prazo (LGPD art. 17).

## Como os outros agentes de RH se conectam à análise

O agente de análise de necessidades está embutido em um conjunto de agentes especializados de L&D. O [Skills-Career-Profile-Agent](/br/catalogo-agentes-hr/skills-career-profile-agent/) fornece os dados de competências agregados, com mapeamento ESCO e CBO, como entrada principal. O [Performance-Review-Documentation-Agent](/br/catalogo-agentes-hr/performance-review-documentation-agent/) fornece os dados de desempenho agregados que indicam as lacunas. O [Workforce-Planning-Agent](/br/catalogo-agentes-hr/workforce-planning-agent/) fornece as projeções de quadro para identificar as competências futuras requeridas.

O [Training-Effectiveness-Agent](/br/catalogo-agentes-hr/training-effectiveness-agent/) mede a eficácia dos treinamentos que esta análise prioriza - a distinção essencial é que este analisa a entrada do planejamento e aquele mede a saída. O [Strategic-HR-Analytics-Agent](/br/catalogo-agentes-hr/strategic-hr-analytics-agent/) integra a análise aos analytics globais, o [People-Analytics-Agent](/br/catalogo-agentes-hr/people-analytics-agent/) fornece os analytics operacionais do dia a dia, e o [Compensation-Benchmarking-Agent](/br/catalogo-agentes-hr/compensation-benchmarking-agent/) fornece as faixas de remuneração para o ROI. O [Learning-Path-Recommendation-Agent](/br/catalogo-agentes-hr/learning-path-recommendation-agent/) recebe as prioridades para gerar trilhas individualizadas, o [Succession-Planning-Agent](/br/catalogo-agentes-hr/succession-planning-agent/) cuida do pipeline de sucessão, o [HR-Document-Management-Agent](/br/catalogo-agentes-hr/hr-document-management-agent/) arquiva os analytics ESRS S1-13 por cinco anos, e o [Audit-Compliance-Agent](/br/catalogo-agentes-hr/audit-compliance-agent/) verifica a conformidade com a Lei Anticorrupção.

## De relance

- **Classificação**: análise sem decisão individual, não alto risco no EU AI Act (nível da coorte, anonimizado com k-anonimato)
- **Âncoras de compliance**: formação profissional da CLT (art. 7, inc. III), PRONATEC, LBI, base de analytics agregada da LGPD (art. 88) e relatório CSRD ESRS S1-13
- **Frameworks de análise**: Skills Gap Analysis (competências atuais frente às requeridas) e priorização multicritério (impacto no KPI, urgência, colaboradores e custo)
- **Distinção**: a análise de necessidades cuida da entrada do planejamento; a eficácia de treinamento mede a saída
- **Retenção**: cinco anos, conforme as prescrições do CTN e da CLT, com eliminação posterior pela LGPD (art. 17)
- **Consultas**: CIPA e sindicatos, obrigatórias na introdução do sistema (Lei 13.467/2017)
- **Sanções**: ação coletiva sindical, atuação do MPT, ANPD de até 2 por cento do faturamento (limitada a R$ 50 milhões) e Lei Anticorrupção de até 20 por cento do faturamento bruto
- **Auditoria**: verificação por auditor obrigatória a partir de 250 empregados na CSRD (ESRS S1-13)
- **Sistema S**: SENAI, SENAC, SENAR e SENAT, com cota de aprendizes de 5 a 15 por cento
- **Integração**: Perfil de Carreira, Avaliação de Desempenho, Planejamento de Quadro, Eficácia de Treinamento, Trilhas de Aprendizagem e Auditoria de compliance

### Distribuicao de Decisores Training-Needs-Analysis

| Passo | Decisor | Rationale |
|-------|---------|-----------|
| Definir objetivos de negócio | H | Briefing da Diretoria de Treinamento e do CHRO, alinhado à estratégia |
| Coleta de dados de HCM, LMS e desempenho, e ETL | R | Integração determinística às fontes e ao data warehouse |
| Anonimização com k-anonimato (mínimo 10) | R | Base de analytics agregada da LGPD (art. 88), determinística |
| Inventário de competências atual (CBO e ESCO) | R | Taxonomia e mapeamento de habilidades, determinístico |
| Competências futuras requeridas | R | Cenários estratégicos e benchmarks do INEP, determinístico |
| Skills Gap Analysis por ML | A | Faixas de lacunas por coorte, com validação humana |
| Priorização multicritério por ML | A | Faixas com validação por auditor |
| Relatório CSRD ESRS S1-13 | R | Dupla materialidade e verificação por auditor, determinístico |
| PRONATEC, Sistema S e acessibilidade da LBI | R | Cota de aprendizes e de PCD, determinístico |
| Dashboards de KPI para o Conselho | R | Painéis com narrativa em pirâmide de Minto, determinístico |
| Validação humana dos achados e Comitê ESG | H | Distinção obrigatória entre causalidade e correlação espúria |
| Integração com os outros agentes de RH | R | Conexão determinística a Perfil de Carreira e Planejamento de Quadro |
| Retenção por cinco anos e ciclo de vida | R | Prescrição do CTN e da CLT, com eliminação pela LGPD (art. 17) |

--- Agente Transferências e Relocação ---
> Transferências e atribuições internacionais: CLT art. 469-470 transferência, Lei 13.445/2017 Lei de Migração e RNM/DIREX/DPF - com Acordos Previdenciários A1 e DBA dupla tributação.

A gestão de transferências e relocações no Brasil cruza vários eixos de compliance ao mesmo tempo. No direito do trabalho, a CLT trata da transferência, do adicional de 25 por cento e das despesas da mudança (art. 469 e 470). Na imigração, a Lei de Migração (Lei 13.445/2017) e o Decreto 9.199/2017 regem o visto de trabalho e a residência, processados pelo DIREX e pela Polícia Federal. Na previdência, os acordos internacionais permitem o atestado de cobertura (A1, pelo PRISMA); na tributação, os acordos de dupla tributação distribuem o imposto de renda. A proteção de dados do expatriado segue a LGPD (art. 88), e as convenções coletivas e as Súmulas TST 6, 43 e 174 completam o quadro. Uma única transferência pode, portanto, acionar simultaneamente várias dessas obrigações.

## A atribuição internacional como armadilha de compliance

Uma empresa com 1.500 colaboradores costuma manter entre 30 e 80 transferências ativas: internas, mudanças nacionais, atribuições internacionais curtas e longas, repatriações e casos de cargo de confiança ou necessidade de serviço. Cada uma precisa estar contratualmente formalizada, fiscalmente correta, previdenciariamente coberta e migratoriamente autorizada - e, na prática, ao menos uma dessas quatro condições quase sempre está quebrada. O problema não é a ausência de transferências; é que o sistema que as administra é da década passada. Uma planilha com 30 expatriados em três continentes, oito deles sem visto atualizado. Um e-mail do consultor tributário internacional de novembro passado que ninguém abriu. Um aditivo contratual que precisaria ser revisto depois da última mudança regulatória da ANPD sobre transferência internacional de dados, mas que está preso em um ciclo de revisões entre a área de mobilidade, o jurídico e a diretoria. O resultado: o RH responde as mesmas perguntas repetidamente, os expatriados agem com base em informação desatualizada sem saber, e, quando surge uma auditoria fiscal da RFB, uma cobrança do INSS, uma irregularidade de visto ou uma reclamação trabalhista por transferência ilícita (Súmula TST 43), falta a prova de que a transferência foi corretamente formalizada.

## A anuência do colaborador como porta dura de compliance

A verificação automatizada da anuência do colaborador conforme a CLT art. 469 - que veda a transferência sem concordância, salvo cargo de confiança ou necessidade de serviço, e prevê o adicional de 25 por cento durante a transferência provisória - é o ponto mais crítico do agente. O art. 470 atribui ao empregador as despesas da mudança do colaborador e da família. A Súmula TST 43 estabelece a presunção de transferência ilícita, com inversão do ônus da prova, cabendo ao empregador provar a legitimidade, e a Súmula TST 174 detalha o adicional. A Lei 14.151/2021 veda a transferência involuntária de gestante e a Lei 9.029/1995 proíbe práticas discriminatórias. A Lei 13.467/2017 (art. 611-A) admite o negociado sobre o legislado, com cláusulas coletivas sobre transferência, adicional e pacote de relocação. O agente confere cada transferência proposta contra essa matriz antes da aprovação e bloqueia o processamento quando a anuência não é verificada, escalando ao Departamento Jurídico.

## A Lei de Migração e o visto de trabalho

Cada transferência internacional percorre ao menos quatro estações: a área de mobilidade formula, o jurídico revisa, o DIREX autoriza o visto e a Polícia Federal expede o registro do estrangeiro. Dependendo do caso, somam-se o Ministério das Relações Exteriores, as embaixadas e consulados, o CNIg e a Apostila de Haia. A Lei de Migração (Lei 13.445/2017) e o Decreto 9.199/2017 estabelecem o marco: o registro migratório, o visto de trabalho adequado à atividade e a autorização de residência. Uma atribuição internacional toca, ao mesmo tempo, visto, residência, previdência, dupla tributação e proteção de dados, e cada tema pode disparar um processo paralelo. Sem orquestração, isso leva de 6 a 12 meses, durante os quais o expatriado vive em incerteza migratória, previdenciária, tributária e de proteção de dados. O agente roteia o fluxo de aprovação aos revisores obrigatórios por tipo de transferência, monitora os prazos e sinaliza os atrasos antes que se tornem críticos.

## Previdência internacional, dupla tributação e proteção de dados

A quarta função é a mais técnica: emitir o atestado de cobertura previdenciária (A1, pelo PRISMA) conforme o acordo internacional aplicável ao país de destino, mantendo as contribuições no país de origem e suspendendo-as no de destino. Em paralelo, os acordos de dupla tributação distribuem o imposto de renda, com equalização ou proteção tributária, a regra dos 183 dias de residência fiscal e o crédito tributário no país de origem; para países sem acordo, aplica-se a reciprocidade da Lei 9.430/1996. A LGPD (art. 88) estabelece o marco para a transferência internacional dos dados do expatriado: proteção adequada, cláusulas contratuais padrão e consentimento específico, com tratamento cuidadoso dos dados sensíveis do art. 11, como saúde da família e filiação sindical. A ANPD exige DPIA (Resolução 4/2023) e pode aplicar sanção de até 2 por cento do faturamento, limitada a R$ 50 milhões.

## Infraestrutura para os agentes de onboarding, folha e documentos

Dois dos três componentes centrais deste agente - o motor de versionamento do aditivo contratual e o fluxo de aprovação - são infraestrutura genérica. Todo agente que aplica regras de mobilidade precisa de aditivos versionados com períodos de vigência, e todo agente que orquestra aprovações em múltiplos níveis precisa de um motor de fluxo com monitoramento de prazos. O agente de onboarding processa a integração na nova localidade referenciando o aditivo de transferência; o de folha ajusta o cálculo do INSS conforme os acordos de previdência e a dupla tributação; o de gestão de documentos arquiva o aditivo e o retém por cinco anos. Quem começa pelo agente de transferências não remodela apenas a gestão de mobilidade: instala a infraestrutura de toda decisão de mobilidade que os agentes seguintes tomarão. As sanções podem se acumular - ANPD de até 2 por cento do faturamento (limitada a R$ 50 milhões), auditoria fiscal da RFB, exigências do INSS e irregularidade de visto no DIREX -, sob a responsabilidade civil dos administradores (Lei 6.404/76, art. 158).

## De relance

- Verificação da anuência do colaborador conforme a CLT art. 469, com a presunção de transferência ilícita da Súmula TST 43
- Cálculo do adicional de transferência de 25 por cento (CLT art. 469, § 3, e Súmula TST 174), conforme os acordos coletivos
- Verificação do visto de trabalho e da residência pela Lei de Migração (Lei 13.445/2017), junto ao DIREX e à Polícia Federal
- Atestado de cobertura previdenciária (A1, pelo PRISMA), com manutenção das contribuições no país de origem
- Cálculo do imposto de renda pelo acordo de dupla tributação, com a regra dos 183 dias e o crédito tributário no país de origem
- Verificação da transferência internacional de dados do expatriado pela LGPD (art. 88), com DPIA da ANPD (Resolução 4/2023)
- Sanções que podem se acumular até R$ 50 milhões: ANPD, RFB, INSS e DIREX, sob a responsabilidade da Lei 6.404/76

### Distribuição de Decisores Transfer-Relocation

| Decisor | Quantidade | Etapas |
| --- | --- | --- |
| R (regra determinística) | 11 | Recebimento e classificação, verificação da anuência (CLT art. 469), cálculo do adicional, verificação do visto (Lei 13.445/2017), atestado A1, cálculo da dupla tributação e do pacote de relocação, verificação da LGPD art. 88, roteamento da aprovação, onboarding e monitoramento de conformidade |
| A (indicador ML assistido) | 1 | Coordenação operacional da relocação física - moradia, escola e visto de dependentes |
| H (confirmação humana) | 2 | Aprovação do aditivo contratual com assinatura ICP-Brasil e escalonamento dos casos de julgamento ao DPO, ao Mobility Manager e ao Jurídico |

--- Agente HR Solicitação Viagem ---
> Fluxo HR de aprovação de viagens antes da viagem: solicitação de viagem com aprovação do gestor, política CIPA da diretriz de viagens e validação de campos obrigatórios.

A prestação de contas de viagens corporativas no Brasil cruza vários eixos de compliance ao mesmo tempo. No direito do trabalho, a CLT define a composição do salário e a natureza das diárias (art. 457 e 458), e as Súmulas TST 318 e 101 distinguem o que é indenizatório do que é salarial. O Decreto 4.638/2003 serve de referência de mercado para as escalas de diárias por nível hierárquico e grupo de cidades. No campo fiscal, a Lei 7.713/1988 (art. 6, inc. V) isenta de imposto de renda as verbas de natureza indenizatória, e o CTN fixa a prescrição tributária em cinco anos, com multa da RFB de 75 a 150 por cento. A LGPD trata da transferência internacional de dados em viagens ao exterior (art. 88), e a Lei Anticorrupção (Lei 12.846/2013) exige due diligence de fornecedores. Uma única prestação de contas pode, portanto, acionar simultaneamente várias dessas obrigações.

## Prestação de contas de viagens em horas, e não em semanas

Mapear 200 recibos de viagem em planilha consome 2 ou 3 dias do Departamento Pessoal a cada fechamento mensal. A classificação manual entre indenizatório e salarial (CLT art. 457, Súmula TST 318) é propensa a erro e a questionamento em fiscalização. O cálculo das diárias por nível hierárquico e grupo de cidades é refeito a cada solicitação, e o reembolso de quilometragem é calculado em fórmulas de planilha sem rastreamento. Na auditoria anual, o auditor independente encontra a divergência de classificação e o relatório sai com ressalva. As sanções relevantes podem se acumular: multa da RFB de 75 a 150 por cento (Lei 9.430/96, art. 44), com possível procedimento penal tributário e responsabilidade do contador e dos administradores; ANPD de até 2 por cento do faturamento, limitada a R$ 50 milhões; Lei Anticorrupção de até 20 por cento do faturamento, com inclusão no cadastro de empresas punidas; e autuação do MTE pela classificação incorreta das verbas.

## A classificação das verbas: indenizatório ou salarial

A CLT estabelece o marco das verbas de viagem. Pelo art. 457, as diárias de viagens habituais que excedem 50 por cento do salário têm natureza salarial e integram a folha, com INSS, FGTS e imposto retido; abaixo disso, têm natureza indenizatória e não integram a folha. O art. 458 trata das utilidades pagas in natura. A Súmula TST 318 reconhece a ajuda de custo como indenizatória, isenta de encargos salvo casos específicos, e a Súmula TST 101 confirma que as diárias habituais acima de 50 por cento do salário são salariais. O Decreto 4.638/2003, que rege as diárias do servidor público federal por escala hierárquica e grupo de cidades, serve de referência de mercado para a política de viagens das empresas privadas, definida pelo Departamento Pessoal e pelo Financeiro.

## A isenção de imposto de renda das verbas indenizatórias

A Lei 7.713/1988 (art. 6, inc. V) isenta de imposto de renda as diárias e a ajuda de custo destinadas a viagens fora do local habitual de trabalho, desde que de natureza indenizatória e com comprovação documental. O Regulamento do Imposto de Renda (Decreto 9.580/2018, art. 35 e 36) e as instruções normativas da RFB regulam a aplicação e a retenção na fonte. A apuração observa a tabela progressiva anual, isenta até R$ 28.559,70 e com alíquotas de 7,5 a 27,5 por cento nas faixas superiores. O imposto retido é declarado na DIRF e na declaração anual do colaborador, com integração ao eSocial. A distinção decisiva permanece a da Súmula TST 101: as diárias habituais que excedem 50 por cento do salário são salariais e, portanto, tributáveis.

## Prescrição de cinco anos e dados em viagens internacionais

O Código Tributário Nacional fixa os prazos prescricionais: cinco anos para a decadência tributária (art. 173) e cinco anos para a cobrança do crédito (art. 174). O descumprimento sujeita a empresa à multa da RFB de 75 a 150 por cento (Lei 9.430/96, art. 44), com juros. A LGPD (art. 88) rege a transferência internacional dos dados do colaborador, que exige base jurídica adequada - cláusulas contratuais padrão, consentimento específico ou execução de contrato. Isso se aplica a passaporte, visto, reservas em hotéis estrangeiros e check-in aéreo internacional. Quando há fornecedores estrangeiros, somam-se a verificação contra as listas de sanções e o controle de lavagem de dinheiro do COAF (Lei 9.613/1998), cujos registros são arquivados por dez anos.

## Como os agentes de folha e de documentos se conectam

Este agente integra-se a agentes adjacentes das áreas de gestão de documentos e de folha. Ele processa a solicitação de despesas do colaborador, a classificação entre indenizatório e salarial (CLT art. 457 e 458), o cálculo de diárias e reembolso de quilometragem, a parcela dedutível do imposto de renda e a integração com o eSocial. O agente de contabilização da folha consome essa saída para gerar os lançamentos contábeis (Lei 6.404/76, art. 176 a 188), alocar centros de custo e compor a DRE. O agente de gestão de documentos cuida da retenção por cinco anos dos recibos digitalizados, com assinatura eletrônica ICP-Brasil. E o agente de benchmarking de remuneração compara as políticas de viagem com o mercado. Todos compartilham as mesmas referências: CLT, Lei 7.713/1988, LGPD, eSocial, RFB, normas do CFC e ICP-Brasil.

## De relance: etapas determinísticas e uma confirmação humana

- Etapas determinísticas e um indicador de ML: recepção da solicitação e OCR dos recibos (indicador), validação da política de viagens, cálculo de diárias, adicional de viagem (CLT art. 457, Súmula TST 318), reembolso de quilometragem, parcela dedutível do imposto de renda (Lei 7.713/1988), validação da nota fiscal eletrônica na SEFAZ, operações de câmbio no Banco Central, sincronização com o eSocial, due diligence de fornecedores, transferência internacional de dados (LGPD art. 88), lançamentos contábeis e auditoria periódica.
- Uma confirmação humana: validação do Departamento Financeiro e do Controller, com assinatura eletrônica ICP-Brasil, sob a responsabilidade civil dos administradores (Lei 6.404/76, art. 158).
- As sanções de RFB, ANPD, CGU e MTE, somadas à responsabilidade do contador, podem superar R$ 50 milhões.
- Retenção de cinco anos pelo CTN, pela CLT e pela Lei 6.404/76, e de dez anos para os registros de prevenção à lavagem de dinheiro do COAF.

### Distribuição de Decisores Travel-Expense

| Decisor | Quantidade | Percentual | Tipo decisão |
|---------|------------|------------|--------------|
| R determinista (regras) | 12 | 85,7% | Validação da política, cálculo de diárias e quilometragem, classificação do imposto de renda, validação da nota fiscal, câmbio, eSocial, due diligence, LGPD art. 88, lançamentos e auditoria |
| A indicador ML | 1 | 7,1% | OCR dos recibos digitalizados e ingestão automatizada |
| H confirmação humana | 1 | 7,1% | Validação do Departamento Financeiro e do Controller, com assinatura ICP-Brasil |
| Total | 14 | 100% | Ciclo completo da prestação de contas de viagens |

--- Agente Gestão de Fornecedores ---
> Gestão de fornecedores RH: Lei 14.133/2021 nova Lei de Licitações, LGPD art. 39 contrato de operadores e CSDDD 2024/1760 - due diligence com CSRD ESRS S2 cadeia de valor.

A gestão de fornecedores de RH no Brasil cruza vários eixos de compliance ao mesmo tempo. Na contratação, a Lei 14.133/2021 e a Lei de Terceirização (Lei 13.429/2017) impõem a responsabilidade subsidiária da tomadora (Súmula TST 331). Na integridade, a Lei Anticorrupção (Lei 12.846/2013) e o Decreto 11.129/2022 exigem due diligence de terceiros. Na proteção de dados, a LGPD trata o fornecedor como operador (art. 39), com responsabilidade solidária (art. 42). A Diretiva CSDDD 2024/1760, com alcance extraterritorial, e a Lei Antitruste (Lei 12.529/2011) completam o quadro. Um único relacionamento com fornecedor pode, portanto, acionar simultaneamente várias dessas obrigações.

## Quando o prazo de rescisão passa despercebido

Um fornecedor de folha está contratado há quatro anos. A satisfação da área é mediana, os custos nunca foram renegociados. O prazo de rescisão venceu em março e ninguém percebeu; o contrato se renova automaticamente por mais doze meses. Segundo o Concord Contract Management Report, empresas perdem até 9 por cento do volume contratual anual por falta de transparência sobre os contratos ativos. Em um portfólio típico de fornecedores de RH - terceirizadas, folha, benefícios, recrutamento, sistemas de gestão e plataformas de denúncia e de ESG -, isso se acumula rapidamente em valores de seis dígitos. Segundo o Sapient Insights HR Systems Survey, as áreas de RH administram em média de 5 a 7 contratos em PMEs e de 15 a 16 em grandes organizações, cada um com prazos, cláusulas de rescisão e modelos de cobrança diferentes. O que falta não é intenção de controle, e sim um sistema que torne prazos, custos e desempenho visíveis em todos os fornecedores antes que as decisões fiquem inadiáveis.

## A nova Lei de Licitações e a due diligence de fornecedores

A Lei 14.133/2021, a nova Lei de Licitações e Contratos Administrativos, estabelece as modalidades de contratação, os critérios de seleção, o sistema de registro de preços e a matriz de risco. A habilitação fiscal e trabalhista (art. 68) exige as certidões negativas da Receita Federal, da PGFN, do FGTS e de débitos trabalhistas, e a Súmula TST 363 fulmina de nulidade o contrato irregular na administração pública. A Lei Anticorrupção (Lei 12.846/2013) e o Decreto 11.129/2022 estabelecem o programa de integridade, cujo parâmetro 3.7 exige a due diligence de terceiros: identificação do beneficiário final, verificação de pessoas politicamente expostas, consulta à Lista Suja do Trabalho Escravo e aos cadastros de empresas punidas, além das listas de sanções internacionais. A sanção chega a 20 por cento do faturamento, com suspensão de atividades. A Lei Antitruste (Lei 12.529/2011) acrescenta sanções do CADE de até 20 por cento. O agente bloqueia o cadastro do fornecedor quando a due diligence não é verificada, escalando ao Compliance Officer e ao Jurídico, com registro retido por cinco anos.

## A due diligence de sustentabilidade da cadeia e a CSDDD

A Diretiva CSDDD 2024/1760, sobre due diligence de sustentabilidade corporativa, tem alcance extraterritorial sobre empresas brasileiras subsidiárias de matriz na UE ou com faturamento europeu acima de 450 milhões de euros. Ela impõe due diligence de direitos humanos e de meio ambiente ao longo da cadeia, com monitoramento, reporte e sanção de até 5 por cento do faturamento líquido global. No mesmo sentido, o padrão ESRS S2 trata dos trabalhadores na cadeia de valor, e os referenciais internacionais - os Princípios Diretores da ONU, as Diretrizes da OCDE e as Convenções fundamentais da OIT - reforçam a proibição do trabalho infantil e forçado e a liberdade sindical. No Brasil, a Lista Suja do Trabalho Escravo e o Pacto Nacional pela Erradicação do Trabalho Escravo complementam o quadro. O agente integra plataformas de ESG e de risco para a due diligence contínua da cadeia, escalando ao Compliance Officer e à Diretoria. A sanção da CSDDD, somada às da ANPD, CGU, CADE e à responsabilidade subsidiária da Súmula TST 331, pode alcançar dimensão existencial.

## O fornecedor como operador e a responsabilidade solidária

A LGPD (art. 39) estabelece que o operador - o fornecedor que processa dados pessoais por conta do controlador - deve seguir as instruções do controlador e verificar as próprias práticas. Os fornecedores de RH atuam como operadores em folha, benefícios, sistemas de gestão, recrutamento e plataformas de assinatura e de denúncia. O acordo de tratamento de dados deve conter cláusulas obrigatórias - objeto, finalidade, obrigações das partes, segurança e a responsabilidade solidária do art. 42 - e a filiação sindical dos terceirizados na folha, por ser dado sensível (art. 11), exige base legal específica. A ANPD pode aplicar sanção de até 2 por cento do faturamento, limitada a R$ 50 milhões. O agente bloqueia a ativação do fornecedor quando o acordo de tratamento de dados não está vigente, escalando ao DPO e ao Compliance Officer, com assinatura eletrônica ICP-Brasil e registro retido por cinco anos.

## Infraestrutura para os agentes de folha, remuneração e documentos

Quatro componentes centrais deste agente - o motor de versionamento dos contratos, o fluxo de renovação, a matriz de risco e o monitoramento de SLA - são infraestrutura genérica. Todo agente que consome serviços externos precisa de fornecedores versionados com períodos de vigência. O agente de folha consome os fornecedores de folha e benefícios, que precisam ter o acordo de tratamento de dados vigente; o de benchmarking de remuneração consome os fornecedores de ESG e pesquisa, que precisam ter a due diligence da Lei Anticorrupção; o de gestão de documentos referencia os contratos vigentes; e o de due diligence de candidatos consome bases oficiais que dependem de contratos de operador. Quem começa pelo agente de fornecedores não remodela apenas a gestão de fornecedores: instala a infraestrutura de toda decisão baseada em terceiros que os agentes seguintes tomarão. As sanções podem se acumular - ANPD, CGU, CADE, MTE, a responsabilidade subsidiária da Súmula TST 331 e a CSDDD de até 5 por cento do faturamento global -, superando, juntas, R$ 50 milhões.

## De relance

- Versionamento semântico dos contratos, com períodos de vigência e arquivamento da versão anterior, sem excluí-la
- Fluxo de renovação orquestrado, com revisores obrigatórios por categoria e consulta ao Sindicato (Lei 13.429/2017, Súmula TST 277)
- Verificação automatizada do acordo de tratamento de dados (LGPD art. 39) e da due diligence da Lei Anticorrupção (parâmetro 3.7 do Decreto 11.129/2022)
- Monitoramento contínuo do SLA, com alertas ao ultrapassar os limites configurados
- Due diligence de sustentabilidade da cadeia pela Diretiva CSDDD 2024/1760 e pelo padrão ESRS S2
- Monitoramento dos prazos de rescisão com alertas antecipados de 180, 90 e 30 dias, atento à renovação automática
- Sanções que podem se acumular até R$ 50 milhões: ANPD, CGU e CADE de até 20 por cento, CSDDD de até 5 por cento global e a responsabilidade subsidiária da Súmula TST 331

### Distribuição de Decisores Vendor-Management

| Decisor | Quantidade | Etapas |
| --- | --- | --- |
| R (regra determinística) | 12 | Cadastro e classificação, due diligence da Lei Anticorrupção, verificação do acordo de tratamento de dados e das certidões, detecção de dependências, roteamento do fluxo, consulta ao Sindicato, versionamento, monitoramento dos prazos de rescisão, due diligence da CSDDD e auditoria periódica |
| A (indicador ML assistido) | 2 | Monitoramento de SLA e métricas de desempenho; comparativos de mercado e benchmarking para o RFP |
| H (decisão humana) | 1 | Decisão de renovação, renegociação ou troca de fornecedor, com assinatura ICP-Brasil |

--- Agente Workforce Planning ---
> Planejamento de quadro: CLT art. 477 rescisão, Lei 14.611/2023 Igualdade Salarial e EU AI Act Anexo III(4)(b) alto risco - com LGPD art. 20 contestação e decisão humana obrigatória.

## Planejamento de quadro como disciplina de forecasting operacional

Planejamento de quadro é tratado como caixa preta estratégica em muitas empresas. O conselho define um alvo headcount, RH calcula orçamentos centros custos, representantes sindicais descobrem tarde demais, e finalmente um plano restructuring aterrissa na mesa onde ninguém pode explicar por que exatamente estas 47 posições estão sendo cortadas. O Agente de planejamento de quadro desmonta esta caixa preta em modelos determinísticos de forecasting, workflows consulta baseados em regras e pontos de decisão humana claramente separados.

No modo padrão, o agente não é um sistema de alto risco do EU AI Act. Ele calcula os requisitos de quadro a partir da carteira de pedidos, da sazonalidade e do histórico de rotatividade, reconcilia com o inventário de habilidades e entrega a visão de capacidade por centro de custo. Isso é forecasting operacional e não recai sob o Anexo III(4)(b) do Regulamento 2024/1689. Apenas quando o módulo opcional de recomendação de demissão é ativado a classificação muda para alto risco, com DPIA obrigatória pela LGPD (art. 35), a vedação de decisão automatizada (art. 20) e o direito do empregado afetado de contestar. A maioria das empresas deliberadamente não ativa esse módulo.

## CLT art. 477 procedimento rescisão como porta dura compliance

O planejamento de quadro que envolve demissões plúrimas dispara as obrigações do procedimento de rescisão da CLT (art. 477 e 477-A). O empregador deve seguir o procedimento legal, com aviso prévio proporcional (art. 487), verba indenizatória, multa de 50 por cento do FGTS e homologação sindical, quando aplicável pela convenção coletiva. Essas obrigações não são negociáveis: o Tribunal Superior do Trabalho confirmou reiteradamente que rescisões sem o procedimento do art. 477 são vulneráveis a nulidade e reintegração.

O agente dispara o fluxo do procedimento de rescisão automaticamente para qualquer demissão. Os representantes dos empregados ou o sindicato da categoria recebem informação escrita com os dados da proposta, abre-se a janela de negociação e o status fica documentado no registro de decisão. Sem o procedimento do art. 477 documentado, o agente bloqueia a aprovação do plano, e a notificação à Superintendência Regional do Trabalho é submetida eletronicamente pelo eSocial.

Para grupos com múltiplas unidades no Brasil, a Lei 13.467/2017 acrescenta uma complicação: empresas com convenção coletiva podem ter cláusulas que exigem consulta sindical no nível do grupo. O agente gerencia essa hierarquia e aciona o órgão apropriado.

## Seleção demissão como processo regra-based humano-em-loop

A seleção de quem demitir é baseada em regras, seguindo a jurisprudência do TST e dos Tribunais Regionais. Os critérios acordados - capacidade, habilidades, experiência, tempo de serviço, disciplina e assiduidade - são ponderados antecipadamente com os representantes dos empregados e aplicados de forma determinística. Os tribunais trabalhistas já esclareceram, em diversos casos, que o empregador tem a discricionariedade de estabelecer a matriz de seleção, mas ela deve ser documentada antecipadamente e, idealmente, acordada com o sindicato da categoria.

O agente calcula scores seleção deterministicamente usando matriz acordada e entrega lista seleção ordenada. Decisão final é feita por liderança RH junto com sindicato categoria ou representantes empregados - o agente calcula, não recomenda. Seleção baseada em ML não é reconhecida pela Justiça Trabalho e regularmente falharia em desafio dispensa imotivada art. 477. Cotas PCD Lei 8.213/1991 e cotas igualdade Lei 14.611/2023 são automaticamente aplicadas como ajustes score. Lei 9.029/1995 anti-discriminação requer trilha auditável documentada.

## Audit Lei 9.029/1995 anti-discriminação como obrigação estatística

O planejamento de quadro é propenso à discriminação. Quando um plano de reestruturação afeta de forma desproporcional empregados idosos, gestantes, pessoas com deficiência ou ativistas sindicais, aplicam-se a Lei 9.029/1995 e a vedação à diferença salarial da Constituição Federal (art. 7, inc. XXX). O empregador precisa então provar que a seleção não se baseou em características protegidas - prova praticamente impossível sem auditorias estatísticas documentadas.

O agente executa auditorias semestrais pela Lei 9.029/1995, verificando se o planejamento de quadro produz impacto desproporcional por idade, sexo, raça, deficiência, gravidez, religião, orientação sexual, identidade de gênero ou atividade sindical. Quando os limiares são ultrapassados - a regra dos 80 por cento é usada pelos tribunais como indício -, o agente gera um relatório com a justificativa estatística. O Ministério Público do Trabalho documentou centenas de Termos de Ajuste de Conduta em seu relatório anual, cada um representando risco de indenização ilimitada na Justiça do Trabalho.

## EU AI Act e interruptor alto risco

Agente Planejamento Quadro não é sistema alto risco modo padrão. Torna-se um apenas quando módulo opcional recomendação demissão é ativado. Esta separação é deliberada: EU AI Act Anexo III(4)(b) classifica sistemas IA domínio emprego como alto risco quando decidem ou contribuem terminação relações trabalho. Forecasting headcount e capacity-planning não caem sob isto; recomendações demissão sim.

Quando a empresa ativa o módulo, passa a valer imediatamente: DPIA obrigatória pela LGPD (art. 35), avaliação de conformidade pelo EU AI Act (art. 43), registro na base de dados da UE (art. 49), documentação técnica (Anexo IV), sistema de gestão de risco (art. 9), governança de dados (art. 10) e supervisão humana (art. 14). A LGPD (art. 20) ainda veda as decisões exclusivamente automatizadas com efeitos jurídicos: a recomendação de demissão nunca pode ser executada sem a decisão final humana, e o empregado tem direito a explicação, contestação e revisão humana.

Na prática, maioria empresas deliberadamente não ativa módulo. Carga compliance adicional regularmente excede benefício porque decisão final humana é obrigatória de qualquer forma e modelo ML entrega apenas segunda opinião.

## Relatório conselho administração e disclosure ESG

Para as companhias abertas sujeitas às obrigações de reporte da CVM, a Lei 6.404/76 (art. 117) exige que o relatório do conselho de administração cubra o engajamento dos empregados, os resultados da consulta, o impacto da reestruturação, o investimento em treinamento e as considerações sobre as partes interessadas. O agente gera esse relatório automaticamente e acompanha a conformidade com o Código Brasileiro de Governança Corporativa. A aprovação final do conselho permanece humana - o conselho é um órgão humano, não um motor de decisão -, e a CVM monitora a conformidade pelos relatórios de qualidade e pela Resolução 59/2021.

O reporte ESG do padrão ESRS S1 (Trabalhadores Próprios) é obrigatório para entidades com mais de 250 empregados, com verificação por auditor obrigatória. O agente entrega os dados quantitativos - quadro, rotatividade, métricas de diversidade, horas de treinamento e taxa de lesão - com interface para o auditor. Os pontos qualitativos, como a estratégia, a avaliação de materialidade e o engajamento das partes interessadas, permanecem humanos: o agente fornece apenas a base de dados.

## Cross-references na Camada Decisão RH

O agente de planejamento de quadro não atua sozinho. Ele entrega o forecasting de capacidade ao [Succession-Planning-Agent](/br/catalogo-agentes-hr/succession-planning-agent/), para os pipelines de sucessão de posições críticas; ao [Talent-Pool-Agent](/br/catalogo-agentes-hr/talent-pool-management-agent/), para os requisitos de recrutamento por agrupamento de habilidades; ao [Compensation-Benchmarking-Agent](/br/catalogo-agentes-hr/compensation-benchmarking-agent/), para os orçamentos de centro de custo; e ao agente de avaliação de desempenho, para as coortes de calibração. O Decision Layer é compartilhado e troca o status da consulta sindical (CLT art. 511 a 625), os resultados da auditoria da Lei 9.029/1995 e a base legal da LGPD.

Este interligamento transforma silos isolados forecasting em sistema consistente workforce governance onde cada mudança plano automaticamente dispara obrigações consulta, anti-discriminação e proteção dados. Quando representantes sindicais bloqueiam plano restructuring porque seleção demissão carece plausibilidade, sistema entrega matriz seleção regra-based com justificativa dentro horas - em vez de recomendação caixa preta que ninguém pode explicar.

--- Works Council Coordination Agent ---
> Gerencia coordenação com Sindicato: requisitos de consulta, negociação, prazos e documentação de respostas.

## Uma demissão sem homologação sindical regular pode ser judicialmente questionada

Uma demissão sem homologação sindical regular, quando aplicável - em rescisões de contratos com mais de 1 ano para trabalhadores representados pelo Sindicato - pode ser contestada judicialmente. Não porque o motivo da rescisão fosse injustificado, mas porque o procedimento formal falhou. Cada ano, centenas de milhares de ações trabalhistas chegam aos tribunais brasileiros. Parte significativa delas ataca falhas formais na coordenação com o Sindicato - porque essas falhas são o caminho mais seguro para contestar a regularidade do ato.

O problema não é de conhecimento. Áreas de RH conhecem as regras. O problema é de coordenação.

## Múltiplos níveis de envolvimento, um processo sem sistema

A CLT (PT: Código do Trabalho) e os acordos coletivos criam diversos níveis de envolvimento sindical, cada um com regras próprias, prazos próprios e consequências próprias em caso de erro:

```
Nível           Base legal       Prazo            Consequência do descumprimento
────────────────────────────────────────────────────────────────────
Informação      Art. 8 CLT       -                Questionamento administrativo
Homologação     Art. 477 CLT     Data da rescisão Contestação trabalhista
Consulta        Acordo coletivo  Definido em ACT  Violação de acordo
Negociação      Art. 611 CLT     Convenção        Dissídio coletivo
Convenção       Art. 614 CLT     Registro MTE     Nulidade de cláusula
```

O desafio não é conhecer essa tabela. O desafio é, a cada medida de RH - rescisão, alteração de jornada, terceirização, mudança de benefícios - identificar em segundos o nível correto, reunir a documentação correta e iniciar o prazo correto. Em uma empresa com 1.500 colaboradores, em uma única semana podem correr dez procedimentos paralelos: três rescisões com homologação, uma mudança de escala de trabalho em negociação coletiva, duas reestruturações em consulta, uma nova política de remuneração variável em informação.

Cada um desses procedimentos tem acionador diferente, documentação diferente, prazo diferente e caminho de escalação diferente. E, na maioria das empresas, cada um é coordenado por e-mail, pasta física ou conversa informal. Não há agenda central de prazos. Não há verificação automática de completude. Não há sistema que reconheça se uma alteração planejada dispara obrigação de negociação coletiva ou apenas informação.

## Por que falhas formais derrubam rescisões

O artigo 477 da CLT é o ponto crítico de contato entre RH e Sindicato em rescisões. Para contratos com mais de um ano, a homologação junto ao Sindicato da categoria é obrigatória - quando aplicável à categoria e quando a convenção coletiva exige. O empregador precisa apresentar documentação completa: TRCT, comprovantes de quitação, guias do seguro-desemprego, extrato de FGTS atualizado, cálculos conferidos.

Na prática, falha em três pontos.

Primeiro: informação incompleta. O Sindicato precisa ter acesso à documentação completa para a homologação. Cálculos simplificados, documentação ausente, verbas rescisórias não conferidas inviabilizam o processo e geram riscos trabalhistas.

Segundo: cálculo errado de prazos. O artigo 477, parágrafo 6 da CLT fixa o pagamento das verbas rescisórias em até 10 dias a contar do término do contrato. O descumprimento gera a multa do parágrafo 8 - um salário-base em favor do empregado, além das verbas devidas. Com volume alto de saídas, a cada atraso a empresa paga indenizações adicionais que se acumulam ao longo do ano.

Terceiro: fundamentos não documentados. Em justa causa, os motivos que não constam do procedimento formal não podem ser invocados depois em juízo. O que falta no ato rescisório, falta em audiência.

Cada um desses erros é evitável. Nenhum deles exige julgamento jurídico. Todos os três são erros de coordenação: a informação correta existia, mas não foi entregue completa. O prazo era conhecido, mas foi mal calculado. O motivo existia, mas não foi documentado.

## O gargalo do artigo 611-A em alterações de condições

Rescisões são o palco mais visível, mas não o mais frequente. Alterações de condições de trabalho - jornada, escala, remuneração variável, benefícios, terceirização - estão sujeitas ao acordo coletivo aplicável. Em muitas categorias, a negociação prevista no artigo 611-A da CLT permite flexibilização, mas dentro dos limites do artigo 611-B.

Para cada alteração em negociação coletiva, três prazos correm simultaneamente: o prazo interno de proposta, o prazo de contrarresposta sindical, e o prazo de formalização da convenção ou aditivo. Quem perde um desses prazos pode ver a alteração declarada ineficaz ou ter que renegociar desde o início.

Em uma empresa em crescimento, com múltiplas alterações por mês, esses procedimentos correm em paralelo. Cada um com documentação própria, prazos próprios, pontos próprios de escalação. A coordenação por e-mail e calendário funciona até não funcionar mais. E o momento em que não funciona mais não custa apenas tempo - custa a medida, porque a base sindical já mobilizou o tema.

## O que muda quando a coordenação vira infraestrutura

O [Decision Layer](/br/decision-layer/) decompõe cada processo de participação em etapas individuais e define para cada uma: humano, motor de regras ou IA. A identificação do nível de envolvimento - qual regra se aplica, qual documentação é necessária, qual prazo corre - é motor de regras. A verificação de completude da documentação contra uma checklist é motor de regras. O monitoramento de prazos é motor de regras. A decisão sobre como tratar uma objeção do Sindicato permanece humana.

Concretamente, o fluxo muda em quatro pontos.

A verificação de participação é automática. Cada medida de RH planejada - rescisão, contratação, terceirização, mudança de jornada - é confrontada com CLT e acordos coletivos. O sistema reconhece se é necessária homologação, consulta, negociação coletiva ou apenas informação. Não é o analista de RH que precisa encontrar o artigo certo. O motor de regras encontra.

A documentação é verificada contra uma checklist. Para cada nível de participação e cada tipo de medida existe uma lista definida: quais informações o Sindicato precisa receber? Os dados sociais do colaborador estão completos? O tipo da rescisão está corretamente indicado? Os motivos estão descritos ou apenas mencionados em palavras-chave? A verificação ocorre antes do envio ao Sindicato, não depois.

Prazos são rastreados a partir do momento do envio. O prazo de pagamento de verbas rescisórias, o prazo de resposta sindical em consulta, o prazo de negociação - cada prazo corre com data de início documentada e escalação automática no vencimento. O Sindicato deixou o prazo vencer? O sistema registra a situação. Houve objeção? O responsável de RH é informado imediatamente, com os próximos passos e os prazos relevantes.

O procedimento inteiro é documentado de forma auditável. Cada etapa, cada documento, cada prazo, cada manifestação, cada decisão. Quando um colaborador, seis meses depois, contesta a rescisão e seu advogado questiona a regularidade do procedimento, a comprovação completa está disponível. Não como cronologia reconstruída a partir de e-mails, mas como trilha de auditoria que contém cada etapa individual com carimbo de tempo e comprovante.

## O agente que serve aos dois lados

A maioria dos agentes de RH trabalha para um lado. O Works Council Coordination Agent é diferente. Ele profissionaliza o arcabouço formal - e os dois lados se beneficiam.

O RH se beneficia porque procedimentos deixam de ser derrubados por falhas formais. Porque a preparação da documentação passa a levar horas em vez de dias. Porque o risco de uma rescisão ser questionada por falha de homologação cai a quase zero.

O Sindicato se beneficia porque recebe documentação completa. Porque seus prazos são calculados corretamente e não interpretados unilateralmente pelo empregador. Porque a documentação cria transparência que antes precisava ser exigida.

O motor de verificação de participação - qual artigo para qual medida, qual documentação, qual prazo - não é função isolada. Todo agente no Decision Layer que dispara uma medida com relevância sindical - o Onboarding Agent em contratações, o Merit Cycle Governance Agent em alterações salariais, o Workforce Planning Agent em transferências - usa a mesma lógica de verificação. A agenda de prazos, as checklists e a trilha de auditoria viram infraestrutura compartilhada. Quem enxerga a coordenação sindical como solução isolada subestima a alavanca. Quem a trata como infraestrutura constrói a base para todo agente seguinte com relevância em direitos de participação.

--- Acessibilidade digital e Lei 13.146/2015: O que sua empresa precisa saber ---
> Lei 13.146/2015 e Diretiva Europeia 2019/882 exigem sites acessíveis. Quem é afetado, o que significa e quais as consequências.

<!-- O que é a acessibilidade digital? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">O que é acessibilidade digital e por que existe essa obrigação?</h2>
<p class="text-body text-gosign-text leading-relaxed">
No Brasil, a Lei 13.146/2015 - o Estatuto da Pessoa com Deficiência - estabelece que produtos e serviços devem ser acessíveis para pessoas com deficiência. Na Europa, a Diretiva 2019/882 (European Accessibility Act) criou um marco uniforme com requisitos semelhantes. Ambas as legislações convergem no objetivo: garantir que sites e serviços digitais sejam utilizáveis por todas as pessoas.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Isso inclui sites e lojas online. O objetivo é simples: quem deseja comprar, reservar ou se informar na internet deve poder fazê-lo independentemente de uma limitação visual, auditiva ou motora. Para empresas que operam tanto no Brasil quanto na Europa, o cumprimento dessas normas é duplamente relevante.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Para as empresas, isso significa: acessibilidade não é mais uma gentileza voluntária, mas uma obrigação legal. Comparável à <a href="/br/conhecimento/obrigacoes-lgpd-sites/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">LGPD (PT: RGPD) na proteção de dados</a> - quem não conhece as regras arrisca sanções.
</p>
</div>
</section>

<!-- Quem é afetado? -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Minha empresa é afetada? Guia por tipo de organização</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
A obrigação de acessibilidade digital se aplica a diferentes organizações dependendo da legislação. Se você é afetado depende menos da forma jurídica e mais do que você faz.
</p>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse bg-white rounded-card">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Tipo de organização</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Obrigação?</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Explicação</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Ltda. / S.A. com loja online</td>
<td class="py-3 px-4 text-body text-gosign-accent-text font-semibold">Sim</td>
<td class="py-3 px-4 text-body text-gosign-text">Comércio online é um serviço ao consumidor. Obrigação plena de acessibilidade.</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Empresa com site apenas B2B</td>
<td class="py-3 px-4 text-body text-gosign-text font-semibold">Recomendado</td>
<td class="py-3 px-4 text-body text-gosign-text">A Lei 13.146/2015 tem escopo amplo. Mesmo portais empresariais devem considerar acessibilidade - especialmente se receberem visitantes com deficiência.</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Organização sem fins lucrativos</td>
<td class="py-3 px-4 text-body text-gosign-text font-semibold">Geralmente sim</td>
<td class="py-3 px-4 text-body text-gosign-text">A Lei 13.146/2015 se aplica amplamente. Financiadores exigem cada vez mais acessibilidade, e organizações com oferta comercial (ingressos, loja) são obrigatoriamente afetadas.</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Microempresa (MEI / ME)</td>
<td class="py-3 px-4 text-body text-gosign-text font-semibold">Recomendado</td>
<td class="py-3 px-4 text-body text-gosign-text">A legislação brasileira não prevê isenção explícita para microempresas em acessibilidade digital. A boa prática é garantir acessibilidade básica independentemente do porte.</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Associação / ONG com site</td>
<td class="py-3 px-4 text-body text-gosign-text font-semibold">Depende</td>
<td class="py-3 px-4 text-body text-gosign-text">Associações que oferecem serviços ao público devem garantir acessibilidade. Se a associação oferece serviços online pagos, a obrigação é mais clara.</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Órgão público</td>
<td class="py-3 px-4 text-body text-gosign-accent-text font-semibold">Sim (Lei 13.146 + Decreto 5.296)</td>
<td class="py-3 px-4 text-body text-gosign-text">Órgãos públicos têm obrigação plena de acessibilidade digital no Brasil, regulamentada pelo Decreto 5.296/2004 e pela Lei 13.146/2015.</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- O que significa acessível? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">O que significa concretamente um "site acessível"?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Acessibilidade soa abstrato, mas é muito prático. Trata-se de que todas as pessoas possam usar seu site. Três exemplos simples:
</p>
<ul class="mt-4 space-y-3">
<li class="flex items-start gap-3">
<span class="text-gosign-accent-text font-bold mt-0.5">1.</span>
<p class="text-body text-gosign-text">
<strong>Uma pessoa cega usa um leitor de tela</strong> - um programa que lê em voz alta o conteúdo da tela. Se suas imagens não têm textos descritivos (textos alt), a pessoa só ouve "gráfico, gráfico, gráfico" - e não entende nada.
</p>
</li>
<li class="flex items-start gap-3">
<span class="text-gosign-accent-text font-bold mt-0.5">2.</span>
<p class="text-body text-gosign-text">
<strong>Uma pessoa com baixa visão precisa de bons contrastes.</strong> Texto cinza claro sobre fundo branco é praticamente ilegível para milhões de brasileiros com deficiência visual. As WCAG exigem uma razão de contraste de pelo menos 4,5:1.
</p>
</li>
<li class="flex items-start gap-3">
<span class="text-gosign-accent-text font-bold mt-0.5">3.</span>
<p class="text-body text-gosign-text">
<strong>Uma pessoa com limitação motora não consegue usar o mouse.</strong> Se seu site só funciona com cliques do mouse, está bloqueado para essa pessoa. Tudo deve ser acessível também por teclado.
</p>
</li>
</ul>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Uma boa acessibilidade melhora ao mesmo tempo a <a href="/br/conhecimento/schema-org-seo-fundamentos/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">otimização para mecanismos de busca</a>: textos alt, cabeçalhos claros e código limpo ajudam o Google tanto quanto um leitor de tela.
</p>
</div>
</section>

<!-- WCAG 2.2 AA: Os quatro princípios -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">WCAG 2.2 AA: Os quatro princípios explicados</h2>
<p class="text-body text-gosign-text leading-relaxed mb-8">
As WCAG (Web Content Accessibility Guidelines) são o padrão internacional para acessibilidade na web. Tanto a Lei 13.146/2015 quanto a Diretiva Europeia 2019/882 exigem o cumprimento do nível AA. As WCAG se baseiam em quatro princípios fundamentais:
</p>
<div class="grid md:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Perceptível</h3>
<p class="text-body text-gosign-text">
Os conteúdos devem estar disponíveis para todos os sentidos. Imagens precisam de descrições, vídeos precisam de legendas. Os contrastes devem ser suficientes. Quem não pode ver deve poder ouvir ou sentir os conteúdos.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Operável</h3>
<p class="text-body text-gosign-text">
Todas as funções devem ser acessíveis por teclado - não apenas por mouse. A navegação deve ser lógica. Os usuários precisam de tempo suficiente para ler e operar. Sem conteúdo piscante que possa provocar convulsões.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Compreensível</h3>
<p class="text-body text-gosign-text">
Os textos devem ser legíveis. Os formulários devem ter rótulos compreensíveis. As mensagens de erro devem explicar o que deu errado. O site não deve se comportar de forma inesperada (por exemplo, abrir novas janelas de repente).
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Robusto</h3>
<p class="text-body text-gosign-text">
O código deve ser limpo para que diferentes navegadores e tecnologias assistivas (leitores de tela, displays Braille, controle por voz) possam interpretar corretamente o conteúdo. HTML conforme aos padrões é a base.
</p>
</div>
</div>
</div>
</section>

<!-- Declaração de acessibilidade -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Declaração de acessibilidade: o que deve conter?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Uma boa prática é manter uma declaração de acessibilidade publicamente acessível em seu site. Essa declaração é comparável à política de privacidade - informa os visitantes sobre o estado atual da acessibilidade. As seguintes informações são recomendadas:
</p>
<ul class="mt-4 space-y-2">
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text flex-shrink-0 mt-0.5" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor"><path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" /></svg>
<p class="text-body text-gosign-text">Quais partes do site são acessíveis e quais não</p>
</li>
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text flex-shrink-0 mt-0.5" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor"><path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" /></svg>
<p class="text-body text-gosign-text">Justificativa para limitações ainda existentes</p>
</li>
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text flex-shrink-0 mt-0.5" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor"><path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" /></svg>
<p class="text-body text-gosign-text">Canal de contato para feedback (e-mail, telefone ou formulário)</p>
</li>
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text flex-shrink-0 mt-0.5" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor"><path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" /></svg>
<p class="text-body text-gosign-text">Data da última verificação</p>
</li>
</ul>
<p class="text-body text-gosign-text leading-relaxed mt-4">
A declaração deve ser fácil de encontrar - idealmente linkada no rodapé, assim como os termos de uso e a política de privacidade.
</p>
</div>
</section>

<!-- Por que a acessibilidade vale a pena? -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Por que a acessibilidade vale a pena mesmo sem obrigação</h2>
<p class="text-body text-gosign-text leading-relaxed">
Mesmo que sua empresa não esteja formalmente sujeita a todas as exigências, há boas razões para sites acessíveis:
</p>
<div class="grid md:grid-cols-2 gap-6 mt-6">
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Maior alcance</h3>
<p class="text-body text-gosign-text">
Mais de 17 milhões de brasileiros vivem com alguma deficiência. Somam-se milhões de pessoas idosas com visão ou mobilidade reduzida. Sites acessíveis alcançam mais pessoas.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Melhor SEO</h3>
<p class="text-body text-gosign-text">
O Google valoriza melhor os sites acessíveis. Textos alt, estrutura clara de cabeçalhos e tempos de carregamento rápidos são fatores tanto de acessibilidade quanto de SEO.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Requisitos de financiadores</h3>
<p class="text-body text-gosign-text">
Muitos programas públicos de financiamento e editais exigem comunicação acessível. Quem solicita verbas públicas ou participa de licitações será cada vez mais avaliado em acessibilidade.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Imagem e confiança</h3>
<p class="text-body text-gosign-text">
Acessibilidade demonstra responsabilidade social. Para fundações, ONGs e empresas com metas ESG, é um argumento real perante stakeholders e o público.
</p>
</div>
</div>
</div>
</section>

<!-- Sanções -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Consequências do descumprimento</h2>
<p class="text-body text-gosign-text leading-relaxed">
No Brasil, o descumprimento da Lei 13.146/2015 pode resultar em sanções administrativas, multas e ações judiciais. O Ministério Público pode agir de ofício para garantir a acessibilidade. Na Europa, a Diretiva 2019/882 prevê sanções que devem ser efetivas, proporcionais e dissuasivas. Concretamente, as sanções podem derivar de:
</p>
<ul class="mt-4 space-y-2">
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text flex-shrink-0 mt-0.5" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor"><path stroke-linecap="round" stroke-linejoin="round" d="M12 9v3.75m-9.303 3.376c-.866 1.5.217 3.374 1.948 3.374h14.71c1.73 0 2.813-1.874 1.948-3.374L13.949 3.378c-.866-1.5-3.032-1.5-3.898 0L2.697 16.126ZM12 15.75h.007v.008H12v-.008Z" /></svg>
<p class="text-body text-gosign-text">Falta de acessibilidade ou acessibilidade insuficiente em serviços obrigatórios</p>
</li>
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text flex-shrink-0 mt-0.5" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor"><path stroke-linecap="round" stroke-linejoin="round" d="M12 9v3.75m-9.303 3.376c-.866 1.5.217 3.374 1.948 3.374h14.71c1.73 0 2.813-1.874 1.948-3.374L13.949 3.378c-.866-1.5-3.032-1.5-3.898 0L2.697 16.126ZM12 15.75h.007v.008H12v-.008Z" /></svg>
<p class="text-body text-gosign-text">Ausência de declaração de acessibilidade no site</p>
</li>
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text flex-shrink-0 mt-0.5" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor"><path stroke-linecap="round" stroke-linejoin="round" d="M12 9v3.75m-9.303 3.376c-.866 1.5.217 3.374 1.948 3.374h14.71c1.73 0 2.813-1.874 1.948-3.374L13.949 3.378c-.866-1.5-3.032-1.5-3.898 0L2.697 16.126ZM12 15.75h.007v.008H12v-.008Z" /></svg>
<p class="text-body text-gosign-text">Descumprimento de determinações da autoridade de fiscalização</p>
</li>
</ul>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Além disso, organizações de defesa do consumidor e o Ministério Público podem mover ações judiciais. O risco não se limita a multas - também são possíveis ações civis e publicidade negativa. A prevenção é mais econômica do que a correção.
</p>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Verificação de acessibilidade: 30&nbsp;minutos, gratuita.</h3>
<p class="text-body text-gosign-text mb-6">Verificamos seu site nos critérios WCAG mais importantes - sem compromisso e com explicações claras.</p>
<a
href="/br/contato/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Solicitar verificação de acessibilidade
</a>
<p class="text-small text-gosign-text-light mt-4">25 anos de experiência · Lighthouse 100/100 · WCAG 2.2 AA</p>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
A Gosign é uma agência digital de Hamburgo com 25 anos de experiência em desenvolvimento web e integração de IA.
Nosso próprio site alcança 100/100 em todas as quatro categorias do Lighthouse, incluindo
Accessibility. Ajudamos empresas de médio porte, fundações e organismos públicos
a projetar seus sites de forma acessível e conforme à legislação.
</p>
<p class="text-small text-gosign-text-light mt-2">Atualizado: março 2026</p>
</div>
</section>

<!-- Temas relacionados -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Temas relacionados</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/br/conhecimento/obrigacoes-lgpd-sites/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Direito</p>
<p class="text-body font-semibold text-gosign-dark">Obrigações da LGPD para sites</p>
</a>
<a href="/br/conhecimento/site-sem-cookie-banner/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Privacidade</p>
<p class="text-body font-semibold text-gosign-dark">Site sem cookie banner</p>
</a>
<a href="/br/conhecimento/typo3-atualizacoes-seguranca/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">TYPO3</p>
<p class="text-body font-semibold text-gosign-dark">Atualizações e segurança TYPO3</p>
</a>
</div>
</div>
</section>

--- Obrigações da LGPD para sites: O que você realmente precisa cumprir ---
> O que os sites devem cumprir em proteção de dados? LGPD, consentimento de cookies, política de privacidade - explicado de forma clara para gestores.

<!-- O que é uma política de privacidade? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">O que é uma política de privacidade e por que todo site precisa de uma?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Uma política de privacidade informa os visitantes do seu site sobre quais dados pessoais são coletados, por que isso é feito e quais direitos os titulares dos dados possuem. Parece abstrato, mas é concreto: apenas quando alguém acessa seu site, o servidor armazena um endereço IP. Isso já é um dado pessoal. Com isso, todo site está sujeito à LGPD.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
A Lei Geral de Proteção de Dados (LGPD - Lei 13.709/2018) está em vigor no Brasil desde agosto de 2020. Ela obriga todo operador de site - seja grande empresa, PME, associação ou fundação - a dispor de uma política de privacidade completa. Se falta ou está desatualizada, há risco de sanções pela ANPD (Autoridade Nacional de Proteção de Dados).
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Importante: uma política de privacidade não é o mesmo que os termos de uso. Os termos de uso regulam as condições de utilização do site. A política de privacidade regula como os dados são tratados (segundo a LGPD). Ambos são recomendados e devem existir separadamente.
</p>
</div>
</section>

<!-- Erros mais frequentes -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Os erros mais frequentes nas políticas de privacidade</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
Na nossa prática, vemos sempre os mesmos problemas. Muitos deles são facilmente evitáveis - quando se sabe no que prestar atenção.
</p>
<div class="grid md:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Modelos desatualizados</h3>
<p class="text-body text-gosign-text">
Muitos sites ainda utilizam políticas de privacidade genéricas ou desatualizadas. Desde a entrada em vigor da LGPD, a legislação evoluiu (novas orientações da ANPD (PT: CNPD), decisões sobre uso de dados). Um modelo de anos atrás quase certamente não é mais conforme.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Informações que faltam</h3>
<p class="text-body text-gosign-text">
A LGPD exige informações concretas: nome do controlador, contato do encarregado de dados (DPO), bases legais para cada tratamento, prazos de retenção e direitos dos titulares. Se falta algum desses, a política está incompleta.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Copiar e colar sem adaptar</h3>
<p class="text-body text-gosign-text">
Uma política de privacidade deve corresponder ao próprio site. Quem usa Google Analytics mas só menciona Facebook Pixel tem um problema. E quem não usa ferramentas de análise mas escreve três parágrafos sobre elas, também.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Páginas vazias ou escondidas</h3>
<p class="text-body text-gosign-text">
Alguns sites têm um link para a política de privacidade no rodapé, mas a página está vazia ou leva a um erro. A ANPD pode fiscalizar isso - e advogados especializados em reclamações ainda mais.
</p>
</div>
</div>
</div>
</section>

<!-- Consentimento de cookies -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Consentimento de cookies: por que um simples aviso não basta</h2>
<p class="text-body text-gosign-text leading-relaxed">
Cookies são pequenos arquivos de texto que os sites armazenam no dispositivo do visitante. Alguns são tecnicamente necessários (por exemplo, para o carrinho de compras em uma loja online). Outros servem para análise ou marketing - e é aí que se torna juridicamente relevante.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
A LGPD exige uma base legal para qualquer tratamento de dados pessoais. Para cookies não essenciais, o consentimento é a base mais segura. Isso significa: um banner com o texto "Este site utiliza cookies - OK" não é suficiente. O visitante deve ter uma escolha real - com a possibilidade de rejeitar categorias individuais.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Na prática, você precisa de uma plataforma de gestão de consentimento (CMP). Essa ferramenta mostra na primeira visita um banner de cookies com pelo menos duas opções: "Aceitar tudo" e "Apenas necessários". Somente após o consentimento podem ser instalados cookies de rastreamento. Sem um CMP funcional, qualquer tracking no seu site pode ser considerado ilícito.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
A propósito: vídeos incorporados do YouTube, Google Maps ou botões de redes sociais também instalam cookies. Quem incluir esses conteúdos precisa de consentimento prévio ou de uma solução de dois cliques que só carrega após a aprovação.
</p>
</div>
</section>

<!-- Alternativa sem cookies -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<div class="border-2 border-gosign-accent/20 rounded-card p-6 bg-white">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">A melhor solução: não precisar de um banner de cookies</h2>
<p class="text-body text-gosign-text leading-relaxed">
Existe uma alternativa ao dilema do banner de cookies: construa seu site de forma que <strong>não instale cookies não essenciais</strong>. Sem tracking, sem fontes externas, sem embeds de terceiros - então você não precisa de banner nem de CMP. Isso economiza dinheiro (ferramentas CMP custam entre 50 e 500 EUR por mês), melhora o tempo de carregamento e simplifica enormemente a conformidade com a LGPD.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Parece irreal? O gosign.de é a prova: zero cookies, zero banner, Lighthouse 100/100, análise completa com ferramentas sem cookies. O que está por trás disso e como pode funcionar também para o seu site, explicamos em detalhe:
</p>
<a
href="/br/conhecimento/site-sem-cookie-banner/"
class="inline-flex items-center gap-2 mt-4 text-gosign-accent-text font-semibold hover:text-gosign-accent transition-colors"
>
<span>Site sem cookie banner - é assim que funciona</span>
<svg class="w-5 h-5" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M13.5 4.5 21 12m0 0-7.5 7.5M21 12H3" /></svg>
</a>
</div>
</div>
</section>

<!-- LGPD, Marco Civil, CDC -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">LGPD, Marco Civil, CDC - qual lei se aplica a quê?</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
Três marcos normativos, três âmbitos de aplicação. Para os operadores de sites é importante conhecer a diferença - porque infrações de cada um podem ser sancionadas separadamente.
</p>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse bg-white rounded-card">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Legislação</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Regula</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Obrigação para sites</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">LGPD</td>
<td class="py-3 px-4 text-body text-gosign-text">Tratamento de dados pessoais</td>
<td class="py-3 px-4 text-body text-gosign-text">Política de privacidade, registro de atividades de tratamento, direitos dos titulares</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Marco Civil da Internet</td>
<td class="py-3 px-4 text-body text-gosign-text">Princípios, garantias e deveres para o uso da internet</td>
<td class="py-3 px-4 text-body text-gosign-text">Proteção de dados, privacidade, guarda de registros de acesso</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">CDC</td>
<td class="py-3 px-4 text-body text-gosign-text">Proteção do consumidor</td>
<td class="py-3 px-4 text-body text-gosign-text">Informação clara e adequada sobre produtos e serviços, incluindo em meios digitais</td>
</tr>
</tbody>
</table>
</div>
<p class="text-body text-gosign-text leading-relaxed mt-6">
A LGPD é uma lei federal e se aplica a todo tratamento de dados pessoais. O Marco Civil da Internet (Lei 12.965/2014) estabelece princípios para o uso da internet no Brasil. O Código de Defesa do Consumidor (CDC) regula as relações de consumo, incluindo no ambiente digital. As três legislações se aplicam em paralelo e todas devem ser cumpridas.
</p>
</div>
</section>

<!-- Caso especial: fundações e ONGs -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Caso especial: fundações e organizações sem fins lucrativos</h2>
<p class="text-body text-gosign-text leading-relaxed">
Um equívoco comum: fundações, associações e organizações sem fins lucrativos estão isentas da LGPD. Isso não é verdade. A LGPD se aplica a toda organização que trate dados pessoais - independentemente da forma jurídica ou finalidade.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Na prática, isso significa: também o site de uma fundação, uma associação ou uma entidade religiosa precisa de uma política de privacidade completa, um banner de cookies conforme e uma identificação clara do responsável. Os requisitos são idênticos aos de uma empresa comercial.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Precisamente em fundações, vemos com frequência sites com formulários de contato, inscrição em newsletters e formulários de doação - áreas onde dados especialmente sensíveis são tratados. Uma política de privacidade correta não é apenas obrigatória, mas também uma questão de confiança com doadores e apoiadores. Também a base técnica do site desempenha um papel - informações básicas sobre <a href="/br/conhecimento/schema-org-seo-fundamentos/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">Schema.org e fundamentos de SEO</a> ajudam a posicionar o site de forma profissional.
</p>
</div>
</section>

<!-- Lista de verificação -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Lista de verificação: 8 pontos que todo site deve cumprir</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
Independentemente do setor, porte ou forma jurídica - estes oito pontos são o mínimo para todo site no Brasil.
</p>
<div class="space-y-4">
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">1</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Política de privacidade existente e atualizada</h3>
<p class="text-body text-gosign-text mt-1">Política completa com todas as informações obrigatórias da LGPD. Verificar pelo menos anualmente e atualizar após mudanças legislativas.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">2</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Identificação clara do responsável</h3>
<p class="text-body text-gosign-text mt-1">Nome, endereço, e-mail, telefone, CNPJ. Em uma página separada, acessível com no máximo dois cliques.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">3</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Banner de cookies com consentimento real</h3>
<p class="text-body text-gosign-text mt-1">Sem "Aceitar tudo" pré-selecionado. Opções equivalentes para aceitar e rejeitar. Somente após o consentimento podem ser instalados cookies não essenciais.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">4</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Criptografia SSL/TLS ativa</h3>
<p class="text-body text-gosign-text mt-1">Todo o site deve ser acessível por HTTPS. Sem criptografia, os dados de formulários são transmitidos em texto plano - uma clara vulnerabilidade.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">5</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Formulários de contato com aviso de privacidade</h3>
<p class="text-body text-gosign-text mt-1">Cada formulário precisa de um aviso sobre o tratamento de dados e um link para a política de privacidade. Para dados sensíveis (candidaturas, saúde) é necessário consentimento separado.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">6</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Contratos com operadores de dados firmados</h3>
<p class="text-body text-gosign-text mt-1">Para cada prestador externo com acesso a dados pessoais (hosting, e-mail, ferramentas de análise) deve existir um contrato de operador de dados. Sem ele, o tratamento pode ser considerado irregular.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">7</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Sem integrações de terceiros descontroladas</h3>
<p class="text-body text-gosign-text mt-1">Google Fonts hospedadas localmente (não carregar dos servidores do Google). Vídeos do YouTube apenas com solução de dois cliques. Sem pixels de rastreamento externos sem consentimento. Cada conexão com terceiros deve ser documentada na política de privacidade.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">8</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Acesso acessível às informações legais</h3>
<p class="text-body text-gosign-text mt-1">A política de privacidade e os termos de uso devem ser acessíveis para todos - também para pessoas com deficiência. A <a href="/br/conhecimento/acessibilidade-bfsg-2025/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">Lei 13.146/2015 (Estatuto da Pessoa com Deficiência)</a> exige acessibilidade digital.</p>
</div>
</div>
</div>
</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Verificação de privacidade do seu site: 30&nbsp;minutos, gratuita.</h3>
<p class="text-body text-gosign-text mb-6">Verificamos seu site quanto à conformidade com a LGPD e mostramos onde é preciso agir.</p>
<a
href="/br/contato/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Solicitar verificação de privacidade
</a>
<p class="text-small text-gosign-text-light mt-4">25 anos de experiência &middot; 800+ projetos &middot; Prática de privacidade desde Hamburgo</p>
</div>
</section>

<!-- O que acontece em caso de infração? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">O que acontece em caso de infração?</h2>
<p class="text-body text-gosign-text leading-relaxed">
As consequências de uma infração da LGPD são reais e podem ser severas. A LGPD prevê sanções que vão desde advertência até multa simples de até 2% do faturamento - limitada a R$ 50 milhões por infração. A ANPD (Autoridade Nacional de Proteção de Dados) é responsável pela fiscalização e aplicação das sanções.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Além das multas, existem dois riscos adicionais que na prática se materializam com mais frequência:
</p>
<div class="grid md:grid-cols-2 gap-6 mt-6">
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Ações judiciais</h3>
<p class="text-body text-gosign-text">
Titulares de dados e organizações de defesa do consumidor podem mover ações judiciais por danos causados pelo tratamento indevido de dados pessoais. O número de processos tem crescido significativamente desde a entrada em vigor da LGPD.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Procedimentos da ANPD</h3>
<p class="text-body text-gosign-text">
A ANPD tem intensificado suas atividades de fiscalização. Uma denúncia é gratuita para qualquer titular de dados e pode resultar em procedimento administrativo. Isso consome recursos internos e pode levar a obrigações de adequação com prazos curtos.
</p>
</div>
</div>
<p class="text-body text-gosign-text leading-relaxed mt-6">
O mais importante: a maioria das infrações em sites é facilmente evitável. Uma política de privacidade atualizada, um banner de cookies funcional e uma identificação correta do responsável custam uma fração do que custa uma multa. A prevenção não é uma questão de orçamento, mas de prioridade.
</p>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
A Gosign é uma agência digital de Hamburgo com 25 anos de experiência em desenvolvimento web, TYPO3 e integração de IA.
Verificamos sites quanto à conformidade com a LGPD, implementamos soluções conformes com a legislação de proteção de dados
e acompanhamos empresas, fundações e organismos públicos no cumprimento de todos os requisitos legais.
</p>
<p class="text-small text-gosign-text-light mt-2">Atualizado: março 2026</p>
</div>
</section>

<!-- Temas relacionados -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Temas relacionados</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/br/conhecimento/acessibilidade-bfsg-2025/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Direito</p>
<p class="text-body font-semibold text-gosign-dark">Acessibilidade e Lei 13.146/2015</p>
</a>
<a href="/br/conhecimento/site-sem-cookie-banner/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Privacidade</p>
<p class="text-body font-semibold text-gosign-dark">Site sem cookie banner</p>
</a>
<a href="/br/conhecimento/typo3-atualizacoes-seguranca/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">TYPO3</p>
<p class="text-body font-semibold text-gosign-dark">Atualizações e segurança TYPO3</p>
</a>
</div>
</div>
</section>

--- Schema.org e fundamentos de SEO: Como tornar seu site visível no Google ---
> O que são dados estruturados? Como Schema.org, meta tags e Open Graph melhoram sua visibilidade no Google? Fundamentos de SEO explicados de forma simples.

<!-- O que são dados estruturados? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">O que são "dados estruturados"?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Imagine que você entrega a alguém seu cartão de visita. Nele constam seu nome, telefone, endereço. O receptor entende imediatamente quem você é e como pode contatá-lo. Exatamente isso fazem os dados estruturados para os mecanismos de busca.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Schema.org é uma linguagem padronizada que Google, Bing e outros mecanismos de busca entendem. Com ela você diz: "Isto é uma empresa, este é o endereço, estes são os horários de funcionamento, e este é o preço do produto." Sem essas marcações, o Google precisa adivinhar - e adivinhar frequentemente leva a resultados de busca incorretos ou incompletos.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
O princípio: você complementa seu código HTML existente com informações adicionais invisíveis. Os visitantes não veem nenhuma diferença, mas os mecanismos de busca leem um "cartão de visita" claramente estruturado da sua empresa.
</p>
</div>
</section>

<!-- Antes e depois -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Antes e depois: como Schema.org muda seu resultado de busca</h2>
<p class="text-body text-gosign-text leading-relaxed mb-8">
A diferença é visível imediatamente. Veja uma comparação de como sua empresa pode aparecer nos resultados de busca do Google:
</p>
<div class="grid md:grid-cols-2 gap-6">
<div class="bg-white border border-gosign-border rounded-card p-6">
<p class="text-small font-semibold text-red-600 uppercase tracking-wider mb-4">Sem Schema.org</p>
<div class="border border-gosign-border rounded-card p-4 bg-gosign-light">
<p class="text-body text-blue-700 font-semibold">Empresa Exemplo Ltda - Início</p>
<p class="text-small text-green-700 mb-1">www.empresa-exemplo.com.br</p>
<p class="text-small text-gosign-text-light">Bem-vindo à Empresa Exemplo. Oferecemos serviços na área de...</p>
</div>
<p class="text-small text-gosign-text-light mt-3">Apenas um link azul com texto genérico. Sem endereço, sem avaliações, sem informações adicionais. O usuário não tem motivo para clicar justamente aqui.</p>
</div>
<div class="bg-white border border-gosign-border rounded-card p-6">
<p class="text-small font-semibold text-green-700 uppercase tracking-wider mb-4">Com Schema.org</p>
<div class="border border-gosign-border rounded-card p-4 bg-gosign-light">
<p class="text-body text-blue-700 font-semibold">Empresa Exemplo Ltda - Serviços de TI São Paulo</p>
<p class="text-small text-green-700 mb-1">www.empresa-exemplo.com.br</p>
<p class="text-small text-amber-700 mb-1">&#9733;&#9733;&#9733;&#9733;&#9733; 4,8 (127 avaliações)</p>
<p class="text-small text-gosign-text-light mb-1">Rua Exemplo 12, 01310-100 São Paulo - Tel. (11) 1234-5678</p>
<p class="text-small text-gosign-text-light">Prestador de serviços de TI para PMEs. Servidores, cloud, suporte.</p>
</div>
<p class="text-small text-gosign-text-light mt-3">Rich Snippet com estrelas de avaliação, endereço e telefone. Ocupa mais espaço, transmite mais confiança - e recebe mais cliques.</p>
</div>
</div>
<p class="text-body text-gosign-text leading-relaxed mt-6">
Estudos mostram: Rich Snippets com avaliações e informações adicionais obtêm até 30% mais cliques que links azuis simples. E isso sem orçamento publicitário - apenas com dados corretamente configurados.
</p>
</div>
</section>

<!-- Os três tipos de Schema mais importantes -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">Os três tipos de Schema mais importantes para empresas</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Organization</h3>
<p class="text-body text-gosign-text">
Dados básicos da sua empresa: nome, logotipo, endereço, ano de fundação, perfis em redes sociais. O Google usa esses dados para o Knowledge Panel - a caixa informativa à direita dos resultados de busca.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">LocalBusiness</h3>
<p class="text-body text-gosign-text">
Amplia Organization com dados específicos de localização: horário de funcionamento, faixa de preço, avaliações, coordenadas. Especialmente importante para empresas com área de atuação local - a base para resultados no Google Maps.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">BreadcrumbList</h3>
<p class="text-body text-gosign-text">
Mostra ao Google a estrutura de navegação do seu site. Em vez de "www.exemplo.com.br/produtos/categoria/artigo", o Google mostra nos resultados: "Início > Produtos > Categoria" - claro e com links.
</p>
</div>
</div>
</div>
</section>

<!-- Meta-Description -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Meta-Description: 160 caracteres que decidem o clique</h2>
<p class="text-body text-gosign-text leading-relaxed">
A Meta-Description é o breve texto descritivo que aparece nos resultados de busca do Google abaixo do título da página. Não é um fator direto de ranking, mas decide se alguém clica no seu resultado - ou no da concorrência.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Uma boa Meta-Description responde à pergunta do usuário em no máximo 155-160 caracteres. Contém a palavra-chave principal, um benefício claro e idealmente uma chamada para ação. Se a Meta-Description está faltando, o Google escolhe sozinho um trecho de texto - muitas vezes não o melhor.
</p>
<h3 class="text-h3 font-bold text-gosign-dark mt-8 mb-4">Canonical Tags e hreflang: sinais claros para os buscadores</h3>
<p class="text-body text-gosign-text leading-relaxed">
Se seu site existe em vários idiomas ou conteúdos similares são acessíveis por diferentes URLs, os mecanismos de busca precisam de sinais inequívocos. Para isso existem duas tags importantes:
</p>
<ul class="mt-4 space-y-3">
<li class="text-body text-gosign-text leading-relaxed">
<strong class="text-gosign-dark">Canonical Tag:</strong> Indica ao Google qual URL é a "versão original" de uma página. Evita que conteúdos idênticos em diferentes endereços sejam considerados duplicados.
</li>
<li class="text-body text-gosign-text leading-relaxed">
<strong class="text-gosign-dark">Hreflang:</strong> Comunica aos buscadores quais versões linguísticas de uma página existem. Assim o Google mostra aos usuários brasileiros a versão em português e aos ingleses a versão em inglês. Especialmente relevante para <a href="/br/conhecimento/obrigacoes-lgpd-sites/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">sites multilíngues em conformidade com a LGPD (PT: RGPD)</a>.
</li>
</ul>
</div>
</section>

<!-- Open Graph -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Open Graph Tags: como seus links ficam bons no WhatsApp e LinkedIn</h2>
<p class="text-body text-gosign-text leading-relaxed">
Já aconteceu com você? Compartilha um link no WhatsApp ou LinkedIn e aparece apenas uma URL seca - sem imagem, sem título, sem descrição. Isso acontece quando faltam os Open Graph Tags.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Open Graph (OG) Tags são meta-indicações no código HTML que dizem às redes sociais como um link compartilhado deve ser exibido. Os quatro mais importantes:
</p>
<ul class="mt-4 space-y-2">
<li class="text-body text-gosign-text"><strong class="text-gosign-dark">og:title</strong> - O título que aparece na pré-visualização</li>
<li class="text-body text-gosign-text"><strong class="text-gosign-dark">og:description</strong> - A descrição abaixo do título</li>
<li class="text-body text-gosign-text"><strong class="text-gosign-dark">og:image</strong> - A imagem de pré-visualização (ideal: 1200 x 630 pixels)</li>
<li class="text-body text-gosign-text"><strong class="text-gosign-dark">og:url</strong> - A URL canônica da página</li>
</ul>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Sem OG Tags, cada plataforma decide sozinha o que exibir. Com OG Tags você controla a imagem que sua empresa transmite - no LinkedIn, WhatsApp, Facebook, Twitter e em qualquer lugar onde links são compartilhados.
</p>
</div>
</section>

<!-- Lista de verificação SEO -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Lista de verificação: 6 fundamentos de SEO para todo site empresarial</h2>
<p class="text-body text-gosign-text leading-relaxed mb-8">
Estes seis pontos constituem o fundamento técnico para uma boa visibilidade no Google. Verifique se seu site os cumpre:
</p>
<div class="space-y-4">
<div class="bg-white border border-gosign-border rounded-card p-5">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent text-white rounded-full flex items-center justify-center font-bold text-small">1</span>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-1">Configurar marcação Schema.org</h3>
<p class="text-body text-gosign-text">Verifique se seu site tem pelo menos Schema de Organization ou LocalBusiness. Teste: insira sua URL no Rich Results Test (search.google.com/test/rich-results).</p>
</div>
</div>
</div>
<div class="bg-white border border-gosign-border rounded-card p-5">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent text-white rounded-full flex items-center justify-center font-bold text-small">2</span>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-1">Meta-Descriptions para todas as páginas importantes</h3>
<p class="text-body text-gosign-text">Verifique se cada página tem sua própria Meta-Description - não vazia, não duplicada, máximo 155-160 caracteres.</p>
</div>
</div>
</div>
<div class="bg-white border border-gosign-border rounded-card p-5">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent text-white rounded-full flex items-center justify-center font-bold text-small">3</span>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-1">Configurar Canonical Tags</h3>
<p class="text-body text-gosign-text">Verifique se cada página tem um Canonical Tag. Especialmente importante em lojas online, páginas com filtros ou sites com variante www e sem www.</p>
</div>
</div>
</div>
<div class="bg-white border border-gosign-border rounded-card p-5">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent text-white rounded-full flex items-center justify-center font-bold text-small">4</span>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-1">Configurar Open Graph Tags</h3>
<p class="text-body text-gosign-text">Verifique se suas páginas têm og:title, og:description e og:image. Teste: compartilhe um link do seu site em um grupo de WhatsApp - aparece uma pré-visualização atraente?</p>
</div>
</div>
</div>
<div class="bg-white border border-gosign-border rounded-card p-5">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent text-white rounded-full flex items-center justify-center font-bold text-small">5</span>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-1">Otimizar HTTPS e tempo de carregamento</h3>
<p class="text-body text-gosign-text">Verifique se seu site é acessível por HTTPS e carrega em menos de 3 segundos. Ambos são fatores diretos de ranking do Google.</p>
</div>
</div>
</div>
<div class="bg-white border border-gosign-border rounded-card p-5">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent text-white rounded-full flex items-center justify-center font-bold text-small">6</span>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-1">Garantir a acessibilidade</h3>
<p class="text-body text-gosign-text">Verifique se seu site é <a href="/br/conhecimento/acessibilidade-bfsg-2025/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">acessível conforme a Lei 13.146/2015</a>. Textos alt em imagens, hierarquia limpa de cabeçalhos e navegação por teclado melhoram não só a acessibilidade, mas também a visibilidade no Google.</p>
</div>
</div>
</div>
</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Verificação do potencial SEO do seu site: 30&nbsp;minutos, gratuita.</h3>
<p class="text-body text-gosign-text mb-6">Analisamos seu site nos fundamentos de SEO mais importantes e mostramos melhorias concretas.</p>
<a
href="/br/contato/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Solicitar verificação de SEO
</a>
<p class="text-small text-gosign-text-light mt-4">25 anos de experiência · 800+ projetos · Análise acelerada por IA</p>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
A Gosign é uma agência digital de Hamburgo com 25 anos de experiência em desenvolvimento web, TYPO3 e integração de IA.
Cuidamos de sites empresariais desde a otimização técnica de SEO até a acessibilidade.
Nossos clientes são empresas de médio porte, universidades e organismos públicos na Europa.
</p>
<p class="text-small text-gosign-text-light mt-2">Atualizado: março 2026</p>
</div>
</section>

<!-- Temas relacionados -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Temas relacionados</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/br/conhecimento/obrigacoes-lgpd-sites/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Direito</p>
<p class="text-body font-semibold text-gosign-dark">Obrigações da LGPD para sites</p>
</a>
<a href="/br/conhecimento/acessibilidade-bfsg-2025/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Direito</p>
<p class="text-body font-semibold text-gosign-dark">Acessibilidade e Lei 13.146/2015</p>
</a>
<a href="/br/conhecimento/typo3-atualizacoes-seguranca/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">TYPO3</p>
<p class="text-body font-semibold text-gosign-dark">Atualizações e segurança TYPO3</p>
</a>
</div>
</div>
</section>

--- Site sem cookie banner: Sim, é possível. E é melhor. ---
> Sites sem cookie banner são legais, mais rápidos e conformes com a LGPD. Veja como eliminar cookies e economizar custos com CMP.

<!-- O problema -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">O problema: banners de cookies incomodam todo mundo</h2>
<p class="text-body text-gosign-text leading-relaxed">
Cerca de 80 por cento dos visitantes clicam em "Rejeitar tudo" ou fecham o banner de cookies imediatamente. O resultado: a primeira coisa que um cliente potencial vê no seu site é uma barreira. Nenhum conteúdo, nenhum produto, nenhuma mensagem - apenas um popup pedindo consentimento.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Banners de cookies não são apenas incômodos, também custam dinheiro. Plataformas de gestão de consentimento (CMPs) como Cookiebot, Usercentrics ou OneTrust cobram entre 50 e 500 euros por mês. Além disso: o JavaScript do CMP torna o carregamento da página mais lento, piora os Core Web Vitals e pode <a href="/br/conhecimento/schema-org-seo-fundamentos/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">impactar negativamente o posicionamento SEO</a>.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
No entanto, a maioria dos sites precisa de um banner de cookies - porque instala cookies. Google Analytics, Facebook Pixel, vídeos do YouTube incorporados, Google Fonts de servidores externos: tudo isso instala cookies ou transfere dados pessoais. E a <a href="/br/conhecimento/obrigacoes-lgpd-sites/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">LGPD (PT: RGPD) exige</a> que haja base legal antes de instalar cookies não essenciais.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Mas e se um site não instalar nenhum cookie?
</p>
</div>
</section>

<!-- A alternativa -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">A alternativa: não instalar cookies</h2>
<p class="text-body text-gosign-text leading-relaxed">
Se um site não instala cookies não essenciais, não precisa de banner de cookies. Não é um truque nem uma zona cinza - é pura lógica. A legislação exige consentimento apenas antes de instalar cookies. Sem cookies, sem necessidade de consentimento, sem banner necessário.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Tecnicamente é totalmente viável. Requer decisões conscientes na arquitetura do site:
</p>
<div class="grid md:grid-cols-2 gap-6 mt-6">
<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Fontes hospedadas localmente</h3>
<p class="text-body text-gosign-text">
Incluir Google Fonts localmente em vez de carregar dos servidores do Google. Sem conexão com o Google, sem transferência de IP, sem necessidade de cookies.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Análise sem cookies</h3>
<p class="text-body text-gosign-text">
Cloudflare Web Analytics em vez de Google Analytics. Sem cookies, sem armazenamento de IP, mas com dados de visualizações, fontes de tráfego e páginas principais.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Sem embeds de terceiros</h3>
<p class="text-body text-gosign-text">
Sem YouTube, sem Google Maps, sem botões de redes sociais que instalem cookies. Se necessário: alternativas conformes ou soluções de dois cliques que só carregam após aprovação.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">SSG + CDN Edge Delivery</h3>
<p class="text-body text-gosign-text">
Geração de site estático em vez de entrega dinâmica por CMS. Sem cookie de sessão do servidor, sem cabeçalhos de rastreamento dinâmicos.
</p>
</div>
</div>
</div>
</section>

<!-- O que você ganha -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">O que você ganha</h2>
<div class="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-3 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Sem cookie banner</h3>
<p class="text-body text-gosign-text">Primeira impressão limpa. Sem popup, sem diálogo de "Aceitar". Os visitantes veem diretamente seu conteúdo.</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Melhor desempenho</h3>
<p class="text-body text-gosign-text">Sem JavaScript de CMP, sem verificação de consentimento antes de cada script. Menos código, tempos de carregamento mais rápidos.</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Plena conformidade LGPD</h3>
<p class="text-body text-gosign-text">Não "suficientemente conforme", mas: não há nada a regular. Sem cookies, sem necessidade de consentimento.</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Sem custos de CMP</h3>
<p class="text-body text-gosign-text">Sem Cookiebot, Usercentrics ou OneTrust. Isso economiza de 600 a 6.000 euros por ano.</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Melhor SEO</h3>
<p class="text-body text-gosign-text">Os Google Core Web Vitals se beneficiam diretamente da ausência de scripts de consentimento. Páginas mais rápidas posicionam melhor.</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">À prova de futuro</h3>
<p class="text-body text-gosign-text">A regulação de cookies está ficando mais rígida. Quem não precisa de cookies simplesmente não é afetado.</p>
</div>
</div>
</div>
</section>

<!-- "Mas eu preciso de Analytics!" -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">"Mas eu preciso de Analytics!"</h2>
<p class="text-body text-gosign-text leading-relaxed">
Essa é a objeção mais frequente. E é legítima - mas tem solução. Análise sem cookies já é realidade há tempo. A questão não é se é possível, mas como.
</p>
<div class="space-y-6 mt-6">
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Cloudflare Web Analytics</h3>
<p class="text-body text-gosign-text leading-relaxed">
Sem cookies, conforme com a proteção de dados e gratuito. Fornece visualizações de página, páginas principais, fontes de tráfego, países e tipos de dispositivo. Sem armazenamento de IP, sem necessidade de consentimento, sem integração de CMP.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Análise do lado do servidor</h3>
<p class="text-body text-gosign-text leading-relaxed">
Análise de logs diretamente no servidor. Sem cookies, sem transferência de dados externa. Ferramentas como GoAccess ou AWStats analisam os logs do servidor e fornecem dados de visitantes sem jamais tocar o navegador do visitante.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Rastreamento de conversões sem cookies</h3>
<p class="text-body text-gosign-text leading-relaxed">
Eventos do lado do servidor em vez de pixels do lado do cliente. Quando um visitante envia um formulário de contato, o evento é registrado do lado do servidor - sem cookie, sem pixel, sem terceiros.
</p>
</div>
</div>
<p class="text-body text-gosign-text leading-relaxed mt-6">
A pergunta honesta é: você realmente precisa de 200 pontos de dados por visitante, ou bastam visualizações de página, fontes de tráfego e eventos de conversão? Para a maioria dos sites empresariais, a resposta é clara.
</p>
</div>
</section>

<!-- Exemplo prático -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Exemplo prático: gosign.de</h2>
<p class="text-body text-gosign-text leading-relaxed">
Este site não instala cookies. Zero banner de cookies, zero fontes externas, zero pixels de rastreamento. A análise funciona através do Cloudflare Web Analytics (sem cookies, sem armazenamento de IP). As fontes são hospedadas localmente, não há embeds do YouTube, nem Google Maps, nem botões de redes sociais. O resultado: Lighthouse 100/100 em todas as quatro categorias (Performance, Accessibility, Best Practices, SEO), plena conformidade com a LGPD sem custos recorrentes de CMP e uma política de privacidade reduzida ao essencial. Também o tema da <a href="/br/conhecimento/acessibilidade-bfsg-2025/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">acessibilidade</a> se beneficia diretamente dessa arquitetura: sem overlay de CMP não há barreira entre o usuário e o conteúdo.
</p>
</div>
</section>

<!-- Lista de verificação -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Lista de verificação: assim seu site fica livre de cookies</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
Cinco passos, nesta ordem. Somente quando os primeiros quatro pontos estiverem resolvidos é que o banner pode ser removido.
</p>
<div class="space-y-4">
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">1</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Remover fontes externas ou hospedá-las localmente</h3>
<p class="text-body text-gosign-text mt-1">Carregar Google Fonts dos servidores do Google é a causa mais frequente de transferências de dados indesejadas. Baixe as fontes, hospede no próprio servidor, pronto.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">2</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Substituir Google Analytics por alternativa sem cookies</h3>
<p class="text-body text-gosign-text mt-1">Cloudflare Web Analytics, Plausible ou Fathom fornecem os dados relevantes para sites empresariais - sem cookies e sem obrigação de consentimento. A migração geralmente leva menos de uma hora.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">3</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Substituir ou proteger embeds de terceiros</h3>
<p class="text-body text-gosign-text mt-1">Vídeos do YouTube, Google Maps e botões de redes sociais instalam cookies ao carregar. Duas opções: remover completamente ou substituir por soluções de dois cliques que só carregam após aprovação.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">4</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Remover pixels de marketing ou migrar para o lado do servidor</h3>
<p class="text-body text-gosign-text mt-1">Facebook Pixel, LinkedIn Insight Tag, Google Ads Conversion - tudo isso instala cookies. Remover completamente ou migrar para rastreamento do lado do servidor sem cookies no dispositivo.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">5</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Remover o banner de cookies</h3>
<p class="text-body text-gosign-text mt-1">Somente agora. Quando não houver mais cookies não essenciais sendo instalados, o CMP pode ser desinstalado e o banner removido. A política de privacidade continua obrigatória, mas será muito mais curta.</p>
</div>
</div>
</div>
</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Solicitar site sem cookies: 30&nbsp;minutos, gratuito.</h3>
<p class="text-body text-gosign-text mb-6">Verificamos seu site e mostramos quais cookies você pode eliminar - e quais nem precisa.</p>
<a
href="/br/contato/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Solicitar site sem cookies
</a>
<p class="text-small text-gosign-text-light mt-4">25 anos de experiência &middot; 800+ projetos &middot; Prática de privacidade desde Hamburgo</p>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
A Gosign é uma agência digital de Hamburgo com 25 anos de experiência em desenvolvimento web, TYPO3 e integração de IA.
Desenvolvemos sites sem cookies, sem dependências externas e com plena conformidade com a LGPD -
sem comprometer análise, desempenho ou funcionalidade.
</p>
<p class="text-small text-gosign-text-light mt-2">Atualizado: março 2026</p>
</div>
</section>

<!-- Temas relacionados -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Temas relacionados</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/br/conhecimento/obrigacoes-lgpd-sites/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Direito</p>
<p class="text-body font-semibold text-gosign-dark">Obrigações da LGPD para sites</p>
</a>
<a href="/br/conhecimento/schema-org-seo-fundamentos/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">SEO</p>
<p class="text-body font-semibold text-gosign-dark">Schema.org e fundamentos de SEO</p>
</a>
<a href="/br/conhecimento/acessibilidade-bfsg-2025/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Direito</p>
<p class="text-body font-semibold text-gosign-dark">Acessibilidade e Lei 13.146/2015</p>
</a>
</div>
</div>
</section>

--- Atualizações TYPO3: Por que são importantes ---
> Por que as atualizações do TYPO3 são importantes, quais versões ainda têm suporte e o que um upgrade para a v13 traz. Explicado de forma clara.

<!-- O que significa LTS? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">O que significa "LTS" e por que isso é importante para você?</h2>
<p class="text-body text-gosign-text leading-relaxed">
LTS significa <strong>Long Term Support</strong>. Isso quer dizer: o fabricante fornece atualizações de segurança para esta versão por um período prolongado. Quando uma vulnerabilidade é descoberta, ela é corrigida - mas apenas para as versões que ainda têm suporte.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Pense nisso como um carro: enquanto seu modelo ainda estiver em produção, você consegue peças de reposição e participa de recalls. Quando o modelo sai de linha, você fica por conta própria. Com o TYPO3 funciona da mesma forma: sem suporte não há patches de segurança - e vulnerabilidades conhecidas permanecem abertas.
</p>
</div>
</section>

<!-- Tabela de versões -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Quais versões do TYPO3 ainda têm suporte?</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
O TYPO3 publica regularmente novas versões. Versões antigas deixam de receber patches de segurança. A tabela a seguir mostra o estado atual:
</p>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse bg-white rounded-card">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Versão</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Suporte até</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Status</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">TYPO3 v13 LTS</td>
<td class="py-3 px-4 text-body text-gosign-text">Dezembro 2027</td>
<td class="py-3 px-4">
<span class="inline-flex items-center px-3 py-1 rounded-full text-small font-semibold bg-green-100 text-green-800">Atual - recomendada</span>
</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">TYPO3 v12 LTS</td>
<td class="py-3 px-4 text-body text-gosign-text">Outubro 2025 (Extended até março 2028)</td>
<td class="py-3 px-4">
<span class="inline-flex items-center px-3 py-1 rounded-full text-small font-semibold bg-yellow-100 text-yellow-800">Suporte terminando</span>
</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">TYPO3 v11 e anteriores</td>
<td class="py-3 px-4 text-body text-gosign-text">Já expirado</td>
<td class="py-3 px-4">
<span class="inline-flex items-center px-3 py-1 rounded-full text-small font-semibold bg-red-100 text-red-800">Sem suporte - risco de segurança</span>
</td>
</tr>
</tbody>
</table>
</div>
<p class="text-body text-gosign-text leading-relaxed mt-6">
<strong>Conclusão:</strong> se o seu site roda em TYPO3 v11 ou anterior, <strong>ele não recebe mais patches de segurança</strong>. Vulnerabilidades conhecidas não são mais corrigidas. Uma atualização é urgentemente recomendada.
</p>
</div>
</section>

<!-- O que acontece com uma versão desatualizada? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">O que acontece se você usa uma versão desatualizada?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Vulnerabilidades de segurança são descobertas regularmente - isso é normal e afeta todo software. O decisivo é se o fabricante as corrige. Em versões sem suporte, isso não acontece mais. As vulnerabilidades se tornam públicas mesmo assim - e é exatamente isso que os invasores aproveitam.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Concretamente, isso significa: seu site pode ser usado para redirecionamentos de phishing, envio de spam ou roubo de dados - muitas vezes sem que você perceba imediatamente. As consequências vão de danos à reputação até violações da LGPD (Lei Geral de Proteção de Dados) e bloqueio por mecanismos de busca. Saiba mais sobre obrigações de proteção de dados em nosso artigo sobre <a href="/br/conhecimento/obrigacoes-lgpd-sites/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">obrigações da LGPD (PT: RGPD) para sites</a>.
</p>
</div>
</section>

<!-- O que traz a v13.4? -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">O que o TYPO3 v13.4 traz de concreto?</h2>
<p class="text-body text-gosign-text leading-relaxed mb-8">
Uma atualização não é apenas uma medida obrigatória de segurança. O TYPO3 v13.4 traz melhorias reais que você sente no dia a dia:
</p>
<div class="grid md:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Tempos de carregamento mais rápidos</h3>
<p class="text-body text-gosign-text">
Compressão automática de imagens com WebP e AVIF. Suas imagens ficam menores, as páginas carregam mais rápido - sem que você precise mudar nada.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Backend mais moderno</h3>
<p class="text-body text-gosign-text">
A interface onde você gerencia os conteúdos foi redesenhada. Estrutura mais clara, melhor visão geral, uso mais simples - também para usuários ocasionais.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Segurança atualizada</h3>
<p class="text-body text-gosign-text">
Suporte para PHP 8.2+ e atualizações de segurança regulares. Seu site permanece protegido contra as ameaças atuais.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Content Blocks</h3>
<p class="text-body text-gosign-text">
Os novos Content Blocks permitem um design de páginas mais flexível. Layouts e elementos de conteúdo podem ser combinados mais facilmente - menos dependência de extensões.
</p>
</div>
</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Verificar versão do TYPO3: 30&nbsp;minutos, gratuito.</h3>
<p class="text-body text-gosign-text mb-6">Verificamos sua versão do TYPO3, as extensões instaladas e as vulnerabilidades abertas - sem compromisso.</p>
<a
href="/br/contato/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Solicitar verificação TYPO3
</a>
<p class="text-small text-gosign-text-light mt-4">25 anos de experiência &middot; 800+ extensões &middot; Desenvolvimento acelerado por IA</p>
</div>
</section>

<!-- Processo de atualização -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">O processo de atualização: o que esperar?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Uma atualização do TYPO3 não precisa ser um grande projeto. O processo típico:
</p>
<ol class="mt-6 space-y-4">
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent text-white rounded-full flex items-center justify-center text-small font-bold">1</span>
<div>
<p class="text-body font-semibold text-gosign-dark">Análise</p>
<p class="text-body text-gosign-text">Qual versão está rodando atualmente? Quais extensões estão instaladas? Há personalizações individuais? A Gosign elabora um inventário.</p>
</div>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent text-white rounded-full flex items-center justify-center text-small font-bold">2</span>
<div>
<p class="text-body font-semibold text-gosign-dark">Atualização em staging</p>
<p class="text-body text-gosign-text">A atualização é realizada em um ambiente de testes. Seu site em produção continua funcionando normalmente durante todo o processo.</p>
</div>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent text-white rounded-full flex items-center justify-center text-small font-bold">3</span>
<div>
<p class="text-body font-semibold text-gosign-dark">Teste e aprovação</p>
<p class="text-body text-gosign-text">Você verifica a versão de staging. Tudo funciona como esperado? Somente após sua aprovação o processo continua.</p>
</div>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent text-white rounded-full flex items-center justify-center text-small font-bold">4</span>
<div>
<p class="text-body font-semibold text-gosign-dark">Entrada em produção</p>
<p class="text-body text-gosign-text">A versão atualizada entra em produção. O tempo de inatividade geralmente é inferior a 30 minutos.</p>
</div>
</li>
</ol>
<p class="text-body text-gosign-text leading-relaxed mt-6">
<strong>Tempo estimado:</strong> Uma atualização menor (por exemplo, 12.4 para 12.6) leva poucas horas. Uma atualização maior (por exemplo, v10 para v13) pode levar alguns dias, dependendo das extensões e personalizações.
</p>
</div>
</section>

<!-- Hospedagem e manutenção do CMS -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Por que hospedagem e manutenção do CMS caminham juntas</h2>
<p class="text-body text-gosign-text leading-relaxed">
As atualizações do TYPO3 não afetam apenas o software em si. Novas versões frequentemente requerem versões mais recentes do PHP, configurações de banco de dados adaptadas ou ajustes de servidor atualizados. Quando a manutenção do CMS e a hospedagem estão com provedores diferentes, surge um esforço de coordenação - e no pior caso uma brecha de segurança porque ninguém se sente responsável.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
A Gosign oferece ambos os serviços de forma integrada: manutenção do CMS incluindo atualizações, monitoramento de extensões e hospedagem em servidores europeus. Assim fica garantido que o ambiente do servidor e a versão do CMS sejam sempre compatíveis.
</p>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
A Gosign é uma agência digital de Hamburgo com 25 anos de experiência em desenvolvimento web, TYPO3 e integração de IA.
Analisamos mais de 800 extensões TYPO3 e hoje desenvolvemos com apoio de IA
até 70% mais rápido que com métodos convencionais. Nossos clientes são empresas de médio porte,
universidades e organismos públicos na Europa.
</p>
<p class="text-small text-gosign-text-light mt-2">Atualizado: março 2026</p>
</div>
</section>

<!-- Temas relacionados -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Temas relacionados</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/br/conhecimento/obrigacoes-lgpd-sites/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Direito</p>
<p class="text-body font-semibold text-gosign-dark">Obrigações da LGPD para sites</p>
</a>
<a href="/br/conhecimento/acessibilidade-bfsg-2025/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Direito</p>
<p class="text-body font-semibold text-gosign-dark">Acessibilidade e Lei 13.146/2015</p>
</a>
<a href="/br/conhecimento/schema-org-seo-fundamentos/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">SEO</p>
<p class="text-body font-semibold text-gosign-dark">Schema.org e fundamentos de SEO</p>
</a>
</div>
</div>
</section>

--- Contato ---
> Fale conosco sobre um processo concreto. Formulário de contato e agendamento.

<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">

<div id="hq" class="scroll-mt-24">
<h2 class="text-h2 font-bold text-gosign-dark">Sede e Governance</h2>
<p class="text-body-lg text-gosign-text-light mt-2">Diretoria executiva, arquitetura de governance, projetos DACH.</p>
<div class="mt-6 grid grid-cols-1 sm:grid-cols-2 gap-6">
<div>
<h3 class="text-body font-bold text-gosign-dark">Hamburgo</h3>
<div class="text-body text-gosign-text-light mt-1 space-y-0.5">
<p>Gosign GmbH</p>
<p>Hallerstraße 8</p>
<p>20146 Hamburgo, Alemanha</p>
</div>
</div>
<div>
<h3 class="text-body font-bold text-gosign-dark">Centro de Treinamento Hamburgo</h3>
<div class="text-body text-gosign-text-light mt-1 space-y-0.5">
<p>Grindelberg 77</p>
<p>20144 Hamburgo</p>
</div>
</div>
</div>
</div>

<div id="market" class="mt-12 pt-8 border-t border-gosign-border scroll-mt-24">
<h2 class="text-h2 font-bold text-gosign-dark">Gestão de projetos e presença de mercado</h2>
<p class="text-body-lg text-gosign-text-light mt-2">Gerentes de projeto no seu fuso horário, no seu idioma.</p>
<div class="mt-6 grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-3 gap-6">
<div>
<h3 class="text-body font-bold text-gosign-dark">São Paulo <span class="text-gosign-text-light font-normal">(Escritório LATAM)</span></h3>
<div class="text-body text-gosign-text-light mt-1 space-y-0.5">
<p>Gosign - Escritório São Paulo</p>
<p><a href="https://www.gosign.pt" target="_blank" rel="noopener noreferrer" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">gosign.pt</a></p>
</div>
</div>
<div>
<h3 class="text-body font-bold text-gosign-dark">Lisboa <span class="text-gosign-text-light font-normal">(PT: sede regional para Portugal)</span></h3>
<div class="text-body text-gosign-text-light mt-1 space-y-0.5">
<p>Gosign - Escritório Lisboa</p>
<p><a href="https://www.gosign.pt" target="_blank" rel="noopener noreferrer" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">gosign.pt</a></p>
</div>
</div>
<div>
<h3 class="text-body font-bold text-gosign-dark">Berlim</h3>
<div class="text-body text-gosign-text-light mt-1 space-y-0.5">
<p>Gosign GmbH - Escritório Berlim</p>
<p>Nogatstraße 46</p>
<p>12051 Berlim, Alemanha</p>
</div>
</div>
<div>
<h3 class="text-body font-bold text-gosign-dark">Cracóvia</h3>
<div class="text-body text-gosign-text-light mt-1 space-y-0.5">
<p>Gosign - Escritório Cracóvia</p>
<p><a href="https://www.gosign.pl" target="_blank" rel="noopener noreferrer" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">gosign.pl</a></p>
</div>
</div>
<div>
<h3 class="text-body font-bold text-gosign-dark">Barcelona</h3>
<div class="text-body text-gosign-text-light mt-1 space-y-0.5">
<p>Gosign - Escritório Barcelona</p>
<p><a href="https://www.gosign.es" target="_blank" rel="noopener noreferrer" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">gosign.es</a></p>
</div>
</div>
</div>
</div>

<div id="engineering" class="mt-12 pt-8 border-t border-gosign-border scroll-mt-24">
<h2 class="text-h2 font-bold text-gosign-dark">Engenharia e Pesquisa</h2>
<p class="text-body-lg text-gosign-text-light mt-2">Mais de 60 engenheiros. Parcerias universitárias para pesquisa e desenvolvimento de talentos.</p>
<div class="mt-6">
<h3 class="text-body font-bold text-gosign-dark">Lahore · Islamabad, Paquistão</h3>
<div class="text-body text-gosign-text-light mt-1 space-y-0.5">
<p>Centros de desenvolvimento com parcerias universitárias:</p>
<p><a href="https://pu.edu.pk/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-text-light transition-colors underline decoration-dotted">University of the Punjab</a> · <a href="https://www.comsats.edu.pk/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-text-light transition-colors underline decoration-dotted">COMSATS University</a></p>
<p><a href="https://www.gosign.pk" target="_blank" rel="noopener noreferrer" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">gosign.pk</a></p>
</div>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark">O Que Cobrimos na Primeira Conversa</h2>
<ul class="mt-4 space-y-2 text-body text-gosign-text-light list-disc list-inside">
<li>Qual processo deve ser automatizado?</li>
<li>Quais sistemas estão envolvidos?</li>
<li>Quais requisitos de governança se aplicam?</li>
<li>Nuvem, self-hosted ou híbrido?</li>
<li>Cronograma e próximos passos</li>
</ul>
</div>
</section>

--- Decision Layer - Decisões AI rastreáveis para HR e Finance ---
> O Decision Layer torna cada decisão de IA auditável e rastreável. Para HR, Finance e processos baseados em documentos.

<!-- Por que projetos de IA falham -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Por que projetos de IA em RH falham</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Processos de RH dependem do conhecimento de colaboradores individuais. Quem sabe qual política de licença especial se aplica em cada localidade? Quem lembra a diferença entre o acordo de empresa de 2019 e a versão atualizada de 2024? Quem verifica se um atestado médico foi corretamente validado contra o acordo coletivo?
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Esse conhecimento vive nas cabeças das pessoas, em threads de e-mail, em pastas que ninguém consegue encontrar. Quando alguém sai da equipe, o conhecimento vai junto.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
A IA pode ajudar - mas apenas quando está claro quais regras se aplicam. E quem é o responsável final.
</p>
</div>
</section>

<!-- Definição: O que é o Decision Layer? -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">O que é o Decision Layer?</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
O Decision Layer decompõe cada processo de negócio em passos de decisão individuais e define antecipadamente para cada um: Decide uma pessoa, um conjunto de regras ou a IA de forma autônoma?
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Onde há margem de discricionariedade, risco de discriminação ou direitos de participação dos trabalhadores (sindicatos/CRE; PT: Comissão de Trabalhadores), a arquitetura impõe a revisão humana. Onde a decisão é determinística - termos de convenções coletivas (CCT/ACT; PT: contrato coletivo/acordo de empresa), verificação de prazos, lógica contábil - o agente aplica o conjunto de regras de forma consistente. E onde o agente está confiante o suficiente e tem permissão: decide de forma autônoma. Interpreta documentos, classifica situações, avalia contexto e reconhece padrões. Isso não é if-then-else - é capacidade de julgamento dentro de limites definidos. O Confidence Routing controla: alta confiança e baixo risco significa decisão autônoma, baixa confiança ou alto risco significa escalação para uma pessoa. Esse Confidence Routing é precisamente o que distingue o Decision Layer do RPA.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Cada decisão é documentada - quem decidiu o quê, quando, com base em quê, com qual resultado. Essa documentação é o <strong class="text-gosign-dark">ato de decisão</strong>: por microdecisão, um registro imutável com entrada, regra de negócio com versão, confiança, versão do modelo, resultado e caminho de contestação - o artefato que torna a revisão da decisão individual possível de cumprir e comprovar nos termos da LGPD art. 20 (e do art. 86 do EU AI Act em negócios na UE). Auditável para auditor independente (PT: revisor oficial de contas), representantes dos trabalhadores e auditoria interna.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
O Decision Layer não é um AI Agent - é a camada de governance acima. Ele complementa sistemas existentes como SAP SuccessFactors, Workday ou outros sistemas ERP e controla o que um AI Agent pode fazer com esses sistemas.
</p>
<p class="text-body text-gosign-text-light mt-4">
Como o Decision Layer resolve a Shadow AI e aplica tecnicamente acordos coletivos e regulamentos internos descreve o
<a href="/br/revista/decision-layer-shadow-ai/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Artigo 6 do Blueprint 2026</a>.
</p>

<!-- Tabela comparativa -->
<div class="mt-8 overflow-x-auto">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-dark/20">
<th class="py-3 pr-4 text-body font-bold text-gosign-dark"></th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Sem Decision Layer</th>
<th class="py-3 pl-4 text-body font-bold text-gosign-accent-text">Com Decision Layer</th>
</tr>
</thead>
<tbody class="text-body-lg text-gosign-text-light">
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Quem decide?</td>
<td class="py-3 px-4">Não está claro - o agente entrega um resultado</td>
<td class="py-3 pl-4">Definido por passo: humano, conjunto de regras ou IA</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Regulamentos internos</td>
<td class="py-3 px-4">Seguidos manualmente - ou esquecidos</td>
<td class="py-3 pl-4">Armazenados como regras fixas, tecnicamente aplicados</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Rastreabilidade</td>
<td class="py-3 px-4">Resultado visível, caminho de decisão não</td>
<td class="py-3 pl-4">Documentação completa por decisão</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Auditor</td>
<td class="py-3 px-4">Deve revisar manualmente cada caso</td>
<td class="py-3 pl-4">Acesso direto à documentação de decisões</td>
</tr>
<tr>
<td class="py-3 pr-4 font-semibold text-gosign-dark">Representação de trabalhadores</td>
<td class="py-3 px-4">Bloqueia - sem transparência</td>
<td class="py-3 pl-4">Apoia - cada decisão rastreável</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Exemplo: Atestado médico -->
<section id="exemplo" class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-2">Como funciona o Decision Layer na prática?</h2>
<p class="text-body-lg text-gosign-text-light mb-8">
Exemplo de atestado médico: 6 passos, responsabilidade clara em cada passo. O Decision Layer define para cada um: conjunto de regras, humano ou automático.
</p>
<img
src="/images/diagrams/decision-layer-krankmeldung-br.svg"
alt="Exemplo de processo: processamento de atestado médico com Decision Layer em 6 passos. Passos 1-2 automáticos (ler documento, carregar dados do colaborador), passos 3-4 baseados em regras (validar contra acordo coletivo, calcular continuação de pagamento), passo 5 decisão humana (doença prolongada acima de 6 semanas), passo 6 contabilização automática SAP."
class="w-full"
loading="lazy"
width="1200"
height="600"
/>
</div>
</section>

<!-- Representação de trabalhadores -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Por que projetos de IA falham na representação de trabalhadores?</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
A razão mais comum pela qual projetos de IA falham nas empresas: a representação de trabalhadores - seja a representação dos trabalhadores (sindicatos/CRE; PT: Comissão de Trabalhadores) ou comitês internos - bloqueia. Não porque se oponha à tecnologia - mas porque falta transparência. O Decision Layer resolve isso:
</p>
<div class="mt-8 space-y-4">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent/10 rounded-full flex items-center justify-center text-gosign-accent font-bold text-small before:content-['✓']" aria-hidden="true"></span>
<p class="text-body-lg text-gosign-text-light">Cada regulamento interno e acordo coletivo é armazenado como uma regra fixa. O agente não pode contorná-lo.</p>
</div>
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent/10 rounded-full flex items-center justify-center text-gosign-accent font-bold text-small before:content-['✓']" aria-hidden="true"></span>
<p class="text-body-lg text-gosign-text-light">Para decisões que afetam colaboradores, sempre decide um humano. Tecnicamente forçado, não apenas acordado.</p>
</div>
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent/10 rounded-full flex items-center justify-center text-gosign-accent font-bold text-small before:content-['✓']" aria-hidden="true"></span>
<p class="text-body-lg text-gosign-text-light">Cada decisão de IA está documentada: o que foi verificado, qual regra aplicou, qual foi o resultado.</p>
</div>
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent/10 rounded-full flex items-center justify-center text-gosign-accent font-bold text-small before:content-['✓']" aria-hidden="true"></span>
<p class="text-body-lg text-gosign-text-light">A representação de trabalhadores pode rastrear como qualquer decisão foi tomada, a qualquer momento.</p>
</div>
</div>
<p class="text-body-lg text-gosign-text-light mt-6">
<strong class="text-gosign-dark">A diferença:</strong> Outros prometem transparência. O Decision Layer a impõe tecnicamente.
</p>
<p class="mt-4">
<a href="/br/governance/co-determination/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Cogestão e agentes de IA →</a>
</p>
</div>
</section>

<!-- Preparado para auditoria -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Como uma decisão de IA se torna preparada para auditoria?</h2>
<p class="text-body-lg text-gosign-accent-text font-semibold mt-4">Seu auditor vê exatamente o que aconteceu.</p>
<ul class="mt-6 space-y-3">
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-6 h-6 bg-gosign-accent/10 rounded-full flex items-center justify-center text-gosign-accent font-bold text-xs mt-0.5 before:content-['✓']" aria-hidden="true"></span>
<span class="text-body-lg text-gosign-text-light">Qual documento foi processado - e quando?</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-6 h-6 bg-gosign-accent/10 rounded-full flex items-center justify-center text-gosign-accent font-bold text-xs mt-0.5 before:content-['✓']" aria-hidden="true"></span>
<span class="text-body-lg text-gosign-text-light">Qual regra foi aplicada - e em qual versão?</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-6 h-6 bg-gosign-accent/10 rounded-full flex items-center justify-center text-gosign-accent font-bold text-xs mt-0.5 before:content-['✓']" aria-hidden="true"></span>
<span class="text-body-lg text-gosign-text-light">Quão confiante estava o agente na sua avaliação?</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-6 h-6 bg-gosign-accent/10 rounded-full flex items-center justify-center text-gosign-accent font-bold text-xs mt-0.5 before:content-['✓']" aria-hidden="true"></span>
<span class="text-body-lg text-gosign-text-light">Um humano revisou - e se sim, quem?</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-6 h-6 bg-gosign-accent/10 rounded-full flex items-center justify-center text-gosign-accent font-bold text-xs mt-0.5 before:content-['✓']" aria-hidden="true"></span>
<span class="text-body-lg text-gosign-text-light">Qual foi o resultado e quando foi contabilizado?</span>
</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-6">Cada uma dessas respostas está em um ato de decisão - é assim que ele aparece:</p>
<div class="not-prose mt-4 bg-surface-raised border border-base rounded-soft overflow-hidden shadow-sm">
  <div class="px-5 py-3 border-b border-base bg-surface-dim">
    <div class="flex items-center gap-3">
      <div class="flex gap-1.5" aria-hidden="true">
        <span class="w-2.5 h-2.5 rounded-full bg-[#FF5F56]"></span>
        <span class="w-2.5 h-2.5 rounded-full bg-[#FFBD2E]"></span>
        <span class="w-2.5 h-2.5 rounded-full bg-[#27C93F]"></span>
      </div>
      <span class="font-code text-xs text-muted">decision-record / atestado-medico / 2026-05-14 / EMP_0x52a8</span>
    </div>
  </div>
  <ol class="divide-y divide-base">
    <li class="p-5">
      <div class="flex items-start gap-4">
        <div class="flex-shrink-0 w-9 h-9 rounded-full flex items-center justify-center font-code text-xs font-bold border" style="background: rgba(3,105,161,0.08); border-color: rgba(3,105,161,0.3); color: #0369A1;">02</div>
        <div class="flex-1 min-w-0">
          <div class="flex flex-wrap items-center gap-2 mb-1.5">
            <span class="text-body font-semibold text-primary">C&#225;lculo dos 15 dias do empregador (Lei 8.213/91, art. 60, &#167;3&#186;)</span>
            <span class="inline-flex px-2 py-0.5 text-xs font-bold uppercase tracking-wider rounded text-white" style="background: #0369A1;">Regra</span>
          </div>
          <p class="text-small text-primary font-medium mb-2">Sal&#225;rio integral de 14.06 a 28.06.2026</p>
          <div class="font-code text-xs text-muted"><span>rule:</span> <span class="text-primary">Lei-8.213/91-art.60-&#167;3&#186; &#183; v2026-01</span></div>
        </div>
      </div>
    </li>
    <li class="p-5">
      <div class="flex items-start gap-4">
        <div class="flex-shrink-0 w-9 h-9 rounded-full flex items-center justify-center font-code text-xs font-bold border" style="background: rgba(109,78,216,0.08); border-color: rgba(109,78,216,0.3); color: #6D4ED8;">09</div>
        <div class="flex-1 min-w-0">
          <div class="flex flex-wrap items-center gap-2 mb-1.5">
            <span class="text-body font-semibold text-primary">Marcar padr&#227;o de afastamentos</span>
            <span class="inline-flex items-center gap-1 px-2 py-0.5 text-xs font-bold uppercase tracking-wider rounded text-white" style="background: #6D4ED8;">IA <span class="font-mono opacity-90">91%</span></span>
          </div>
          <p class="text-small text-primary font-medium mb-2">Aviso ao RH: terceiro afastamento curto em seis meses</p>
          <div class="font-code text-xs text-muted"><span>model-reason:</span> <span class="text-primary">correspond&#234;ncia de padr&#227;o &#183; indicador, n&#227;o decis&#227;o de pessoal</span></div>
          <div class="mt-3"><span class="inline-flex items-center px-3 py-1.5 text-xs font-semibold rounded border-2" style="border-color: #6D4ED8; color: #6D4ED8; background: rgba(109,78,216,0.08);">formalmente contest&#225;vel &#183; LGPD art. 20</span></div>
        </div>
      </div>
    </li>
  </ol>
</div>
<p class="text-body text-gosign-text-light mt-4">Duas de 13 microdecis&#245;es de um caso - cada uma com vers&#227;o da regra, confian&#231;a e caminho de contesta&#231;&#227;o. <a href="/br/revista/ato-de-decisao-decisoes-ia-contestaveis/" class="text-gosign-accent-text hover:underline font-semibold">O ato de decis&#227;o completo em detalhe &#8594;</a></p>
</div>
</section>

<!-- Três tipos de decisões -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-2">Quais decisões a IA pode tomar sozinha?</h2>
<p class="text-body-lg text-gosign-text-light mb-8">
Algumas decisões um AI Agent pode tomar sozinho. Outras precisam de revisão humana. E para questões estratégicas, o agente apenas fornece dados. O Decision Layer define isso - por passo, não por processo.
</p>
<img
src="/images/diagrams/decision-layer-drei-arten-br.svg"
alt="Três tipos de decisões no Decision Layer: Esquerda - humano decide para estratégia de pessoal, avaliações de desempenho, política de remuneração (aproximadamente um terço). Centro - agente trabalha, humano revisa para processamento de documentos, revisão de contratos, onboarding (aproximadamente 40%). Direita - agente autônomo para FAQ, certificados padrão, verificação de prazos (aproximadamente um quarto)."
class="w-full"
loading="lazy"
width="1200"
height="600"
/>
</div>
</section>

<!-- Para quem -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Para quem é o Decision Layer?</h2>
<div class="mt-8 space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Head of HR / CHRO</p>
<p class="text-body-lg text-gosign-text-light mt-1">Você quer usar IA em RH - sem perder o controle. O Decision Layer garante que regulamentos internos e acordos coletivos da CLT (PT: Código do Trabalho) sejam cumpridos, a representação de trabalhadores tenha transparência e cada decisão seja rastreável.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">CFO / Head of Finance</p>
<p class="text-body-lg text-gosign-text-light mt-1">Cada contabilização assistida por IA está documentada de forma auditável. Seu auditor vê o caminho de decisão completo. Contabilizações corretivas são reduzidas porque conjuntos de regras são aplicados de forma consistente, e onde o agente decide autonomamente, ele o faz de maneira comprovadamente mais confiável do que o processamento manual.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Representação de Trabalhadores</p>
<p class="text-body-lg text-gosign-text-light mt-1">Sem caixa preta. Regulamentos internos e acordos coletivos estão tecnicamente armazenados e não podem ser contornados. Para decisões de pessoal, sempre intervém um humano.</p>
</div>
<div class="border-l-4 border-gosign-dark/20 pl-6">
<p class="text-h3 font-bold text-gosign-text-light">IT / CTO</p>
<p class="text-body-lg text-gosign-text-light mt-1">Agnóstico de modelo, agnóstico de infraestrutura, sem vendor lock-in. <a href="/br/governance/reference-architecture/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Detalhes técnicos na Arquitetura de Referência →</a></p>
</div>
</div>
</div>
</div>
</section>

<!-- Domínios -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">O Decision Layer para seus processos</h2>
<div class="grid grid-cols-1 md:grid-cols-3 gap-6">
<a href="/br/hr-ai-agents/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<h3 class="text-h3 font-bold text-gosign-dark">HR & People Operations</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Atestados médicos, onboarding, referências de trabalho, revisão de contratos, consultas de políticas. Compatível com a representação dos trabalhadores (sindicatos/CRE; PT: Comissão de Trabalhadores), conforme ao EU AI Act e LGPD (PT: RGPD).</p>
<span class="inline-block mt-4 text-gosign-accent-text font-semibold text-body">HR Agent →</span>
</a>
<a href="/br/finance-ai-agents/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<h3 class="text-h3 font-bold text-gosign-dark">Finance & Payroll</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Processamento de documentos, contabilização, folha de pagamento, lançamentos de fechamento. Preparado para auditoria. Integração SAP e sistemas ERP.</p>
<span class="inline-block mt-4 text-gosign-accent-text font-semibold text-body">Finance Agent →</span>
</a>
<a href="/br/servicos/ai-agents/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<h3 class="text-h3 font-bold text-gosign-dark">Processamento de documentos</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Notas fiscais, contratos, certificados. Classificação automática e extração de dados com validação baseada em regras.</p>
<span class="inline-block mt-4 text-gosign-accent-text font-semibold text-body">Document Agents →</span>
</a>
</div>
</div>
</section>

<!-- EU AI Act -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">O Decision Layer é conforme ao EU AI Act?</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
No Brasil, a LGPD art. 20 já garante ao titular o direito de revisar decisões automatizadas - hoje, sem esperar a Europa. O EU AI Act é a regulamentação europeia de IA - aplica-se diretamente na UE e em Portugal; no Brasil é relevante para empresas com operações na UE - e exige transparência (art. 13), supervisão humana (art. 14) e registro (art. 12), além de dar ao afetado, com o art. 86, o direito a uma explicação da decisão individual. O Decision Layer aborda esses requisitos como um princípio arquitetônico - não como um projeto de compliance posterior: o ato de decisão por microdecisão é a resposta à pergunta do caso individual que logs de chat e model cards não conseguem responder.
</p>
<p class="mt-4">
<a href="/br/governance/eu-ai-act/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Regulamentação de AI e Compliance em detalhe →</a>
<span class="mx-2 text-gosign-text-light">·</span>
<a href="/br/revista/ato-de-decisao-decisoes-ia-contestaveis/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">O ato de decisão: por que toda decisão de IA deve ser contestável →</a>
</p>
</div>
</section>

<!-- Informações da entidade -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Quem está por trás do Decision Layer?</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
O Decision Layer é desenvolvido e implementado pela <strong class="text-gosign-dark">Gosign GmbH</strong>. Gosign é uma Enterprise AI Infrastructure & Agent Engineering Company com sede em Hamburgo, Alemanha, com mais de 20 anos de experiência construindo sistemas complexos para empresas como Airbus, Volkswagen, Shell.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
4-6 semanas até o primeiro processo produtivo. Acesso completo ao código-fonte, sem vendor lock-in. Objetivo: Após 12-18 meses, você opera seus agentes de forma independente.
</p>
<p class="mt-4">
<a href="/br/sobre-nos/" class="text-gosign-accent-text hover:underline font-semibold">Sobre a Gosign →</a>
<span class="mx-2 text-gosign-text-light">·</span>
<a href="/br/referencias/" class="text-gosign-accent-text hover:underline font-semibold">Referências →</a>
</p>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">Aprofundamento no Agent Briefing (Revista Gosign)</h2>
<div class="grid md:grid-cols-3 gap-6">
<a href="/br/revista/ato-de-decisao-decisoes-ia-contestaveis/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<h3 class="text-h3 font-bold text-gosign-dark">O ato de decisão: decisões de IA contestáveis</h3>
</a>
<a href="/br/revista/agent-governance-hr/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR</p>
<h3 class="text-h3 font-bold text-gosign-dark">Agent Governance para RH</h3>
</a>
<a href="/br/revista/comite-empresa-ia-codecisao/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<h3 class="text-h3 font-bold text-gosign-dark">Sindicato e IA - Cogestão</h3>
</a>
</div>
</div>
</section>

--- eBook: Finance Agent Readiness Assessment - 15 perguntas para CFO e auditores ---
> eBook gratuito: 15 perguntas sobre Finance Agent Readiness. Verificação de conformidade, prontidão para auditoria, avaliação de equipe.

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">

<div class="grid md:grid-cols-5 gap-12 items-start">

<div class="md:col-span-3">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">O que você encontrará neste assessment</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
42% de todas as faturas em contas a pagar ainda são processadas manualmente (IFM 2024). Com um custo médio de EUR 11,50 por fatura, é um fator de custo mensurável. Este assessment mostra onde sua organização financeira se encontra - e quais agentes geram o maior impacto.
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8 mb-3">15 perguntas em 5 dimensões</h3>
<ul class="space-y-2 text-body text-gosign-text">
<li class="flex items-start gap-2"><span class="text-gosign-accent-text font-bold">1.</span> Prontidão para auditoria - Quão preparados para auditoria estão seus processos?</li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text font-bold">2.</span> Sigilo profissional - Status de conformidade regulatória e separação de dados</li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text font-bold">3.</span> Paisagem ERP - Quão integrados são seus sistemas financeiros?</li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text font-bold">4.</span> Velocidade de fechamento - Quão rápido é seu fechamento mensal?</li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text font-bold">5.</span> Maturidade de processos - Quão formalizadas são suas regras contábeis?</li>
</ul>

<h3 class="text-h3 font-bold text-gosign-dark mt-8 mb-3">Como o eBook se diferencia da ferramenta online</h3>
<div class="overflow-x-auto">
<table class="w-full text-body text-gosign-text border-collapse mt-4">
<thead><tr class="border-b-2 border-gosign-border"><th class="text-left py-2 pr-4 font-bold text-gosign-dark">Característica</th><th class="text-left py-2 pr-4 font-bold text-gosign-dark">Online (3 min.)</th><th class="text-left py-2 font-bold text-gosign-dark">eBook (PDF)</th></tr></thead>
<tbody>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Perguntas</td><td class="py-2 pr-4">7</td><td class="py-2">15</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Verificação de conformidade</td><td class="py-2 pr-4">Básica</td><td class="py-2">Aprofundada (6 perguntas)</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Avaliação de equipe</td><td class="py-2 pr-4">Não</td><td class="py-2">Sim (CFO + auditor + TI)</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Análise de gaps</td><td class="py-2 pr-4">Não</td><td class="py-2">Sim</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Imprimível</td><td class="py-2 pr-4">Não</td><td class="py-2">Sim (otimizado A4)</td></tr>
</tbody>
</table>
</div>
</div>

<div class="md:col-span-2">
<div class="sticky top-24 bg-gosign-light border border-gosign-border rounded-card p-6">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-3">PDF gratuito</p>
<p class="text-h3 font-bold text-gosign-dark mb-2">Baixar assessment</p>
<p class="text-small text-gosign-text-light mb-4">14 páginas, verificação de conformidade, avaliação de prontidão para auditoria, avaliação de equipe com análise de gaps.</p>
<a href="#download" class="block w-full text-center px-6 py-3 bg-gosign-accent-btn text-white font-semibold rounded-lg hover:bg-gosign-accent-btn-hover transition-colors" data-ebook-download>Baixar assessment</a>
<p class="text-xs text-gosign-text-light mt-3">Apenas e-mail necessário. PDF imediato.</p>
</div>
</div>

</div>
</div>
</section>

<!-- Teste rápido -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<div class="border-2 border-gosign-accent/20 rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Teste rápido: Avaliação online</p>
<p class="text-body text-gosign-text mb-4">Sem tempo para o assessment completo? Comece com o teste rápido de 3 minutos com 7 perguntas e gráfico radar automático.</p>
<a href="/br/finance-agent-readiness/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Iniciar avaliação online &rarr;</a>
</div>
</div>
</section>

<!-- Mais eBooks -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Mais eBooks</h2>
<div class="grid grid-cols-1 sm:grid-cols-2 gap-4">
<a href="/br/ebook/ia-financas-manual-governanca/" class="block border border-gosign-border rounded-card p-4 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-1">Finance Governance</p>
<p class="text-body font-semibold text-gosign-dark">IA em Finanças: Manual de Governança</p>
</a>
<a href="/br/ebook/hr-agent-readiness-assessment/" class="block border border-gosign-border rounded-card p-4 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-1">HR Assessment</p>
<p class="text-body font-semibold text-gosign-dark">HR Agent Readiness Assessment</p>
</a>
</div>
</div>
</section>

--- eBook: HR Agent Readiness Assessment - 15 perguntas para a equipe de liderança ---
> eBook gratuito: 15 perguntas sobre HR Agent Readiness. Planilhas, modelo de gráfico radar, avaliação de equipe com análise de gaps.

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">

<div class="grid md:grid-cols-5 gap-12 items-start">

<div class="md:col-span-3">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">O que você encontrará neste assessment</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
73% das organizações ainda não possuem um framework de governança de IA (ISACA 2024). Este assessment mostra onde sua organização de RH se encontra - não como um modelo teórico, mas como um documento de trabalho para sua equipe.
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8 mb-3">15 perguntas em 5 dimensões</h3>
<ul class="space-y-2 text-body text-gosign-text">
<li class="flex items-start gap-2"><span class="text-gosign-accent-text font-bold">1.</span> Maturidade de processos - Quão documentados e consistentes são seus processos de RH?</li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text font-bold">2.</span> Governance - Quem é responsável pela IA em RH?</li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text font-bold">3.</span> Paisagem de dados - Qual a qualidade dos seus dados de RH?</li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text font-bold">4.</span> Representação dos trabalhadores - Como o Sindicato ou CRE participa das decisões sobre IA? (PT: Comissão de Trabalhadores)</li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text font-bold">5.</span> Infraestrutura de TI - Quão integrado é seu ambiente de sistemas de RH?</li>
</ul>

<h3 class="text-h3 font-bold text-gosign-dark mt-8 mb-3">Como o eBook se diferencia da ferramenta online</h3>
<div class="overflow-x-auto">
<table class="w-full text-body text-gosign-text border-collapse mt-4">
<thead><tr class="border-b-2 border-gosign-border"><th class="text-left py-2 pr-4 font-bold text-gosign-dark">Característica</th><th class="text-left py-2 pr-4 font-bold text-gosign-dark">Online (3 min.)</th><th class="text-left py-2 font-bold text-gosign-dark">eBook (PDF)</th></tr></thead>
<tbody>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Perguntas</td><td class="py-2 pr-4">7</td><td class="py-2">15</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Gráfico radar</td><td class="py-2 pr-4">Automático</td><td class="py-2">Modelo para desenhar</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Avaliação de equipe</td><td class="py-2 pr-4">Não</td><td class="py-2">Sim (4-5 participantes)</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Análise de gaps</td><td class="py-2 pr-4">Não</td><td class="py-2">Sim</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Imprimível</td><td class="py-2 pr-4">Não</td><td class="py-2">Sim (otimizado A4)</td></tr>
</tbody>
</table>
</div>
</div>

<div class="md:col-span-2">
<div class="sticky top-24 bg-gosign-light border border-gosign-border rounded-card p-6">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-3">PDF gratuito</p>
<p class="text-h3 font-bold text-gosign-dark mb-2">Baixar assessment</p>
<p class="text-small text-gosign-text-light mb-4">14 páginas, planilhas para preenchimento, avaliação de equipe com análise de gaps.</p>
<a href="#download" class="block w-full text-center px-6 py-3 bg-gosign-accent-btn text-white font-semibold rounded-lg hover:bg-gosign-accent-btn-hover transition-colors" data-ebook-download>Baixar assessment</a>
<p class="text-xs text-gosign-text-light mt-3">Apenas e-mail necessário. PDF imediato.</p>
</div>
</div>

</div>
</div>
</section>

<!-- Teste rápido -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<div class="border-2 border-gosign-accent/20 rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Teste rápido: Avaliação online</p>
<p class="text-body text-gosign-text mb-4">Sem tempo para o assessment completo? Comece com o teste rápido de 3 minutos com 7 perguntas e gráfico radar automático.</p>
<a href="/br/hr-agent-readiness/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Iniciar avaliação online &rarr;</a>
</div>
</div>
</section>

<!-- Mais eBooks -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Mais eBooks</h2>
<div class="grid grid-cols-1 sm:grid-cols-2 gap-4">
<a href="/br/ebook/ia-rh-manual-governanca/" class="block border border-gosign-border rounded-card p-4 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-1">HR Governance</p>
<p class="text-body font-semibold text-gosign-dark">IA em RH: Manual de Governança para o Diretor de RH</p>
</a>
<a href="/br/ebook/finance-agent-readiness-assessment/" class="block border border-gosign-border rounded-card p-4 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-1">Finance Assessment</p>
<p class="text-body font-semibold text-gosign-dark">Finance Agent Readiness Assessment</p>
</a>
</div>
</div>
</section>

--- eBook: IA em Finanças - Manual de Governança para o CFO ---
> eBook gratuito: regulamentação de IA, auditores externos e Decision Layer - o manual de governança para líderes financeiros.

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">

<div class="grid md:grid-cols-5 gap-12 items-start">

<div class="md:col-span-3">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">O que você encontrará neste manual</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
O PL 2338/2023 (Marco Legal da Inteligência Artificial), em tramitação no Congresso Nacional, classifica sistemas de IA em decisões financeiras como alto risco. 73% das organizações ainda não possuem um framework de governança (ISACA 2024). Este manual preenche essa lacuna - com frameworks específicos para finanças, checklists e uma Avaliação de Prontidão.
</p>

<div class="space-y-4 mb-8">
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">1</span>
<div>
<p class="font-semibold text-gosign-dark">Por que o CFO deve liderar a governança de IA em Finanças - não TI</p>
<p class="text-small text-gosign-text-light">Propriedade da governança, conceito de papéis e checklist do CFO.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">2</span>
<div>
<p class="font-semibold text-gosign-dark">Três tipos de decisões financeiras: Humano, Regramento, IA</p>
<p class="text-small text-gosign-text-light">O framework H/R/A com Agent Readiness Score para cada processo financeiro.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">3</span>
<div>
<p class="font-semibold text-gosign-dark">Regulamentação de IA: Requisitos para o setor financeiro</p>
<p class="text-small text-gosign-text-light">PL 2338/2023 (PT: equivalente do EU AI Act) e padrões internacionais com checklist de conformidade.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">4</span>
<div>
<p class="font-semibold text-gosign-dark">Auditores externos como parceiros de governança</p>
<p class="text-small text-gosign-text-light">NBC TA 315, Auditor Portal, obrigação de AI Literacy.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">5</span>
<div>
<p class="font-semibold text-gosign-dark">4 processos financeiros no Decision Layer</p>
<p class="text-small text-gosign-text-light">Contas a pagar, despesas de viagem, fechamento financeiro, detecção de fraude - com taxas Zero-Touch.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">6</span>
<div>
<p class="font-semibold text-gosign-dark">Avaliação de Prontidão Financeira (10 perguntas)</p>
<p class="text-small text-gosign-text-light">Onde sua organização se encontra? Autoavaliação com pontuação e recomendações.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">7</span>
<div>
<p class="font-semibold text-gosign-dark">Plano de 90 dias para começar</p>
<p class="text-small text-gosign-text-light">Inventário, design, piloto - caminho estruturado ao Decision Layer em três meses.</p>
</div>
</div>
</div>
</div>

<div class="md:col-span-2">
<div class="bg-gosign-light border border-gosign-border rounded-card p-6 sticky top-8">
<p class="text-h3 font-bold text-gosign-dark mb-2">Baixar gratuitamente</p>
<p class="text-small text-gosign-text-light mb-4">PDF, 28 páginas. Entrega imediata por e-mail.</p>

<div class="space-y-3 mb-6">
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>Checklist de conformidade (Finanças)</span>
</div>
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>Framework de decisões H/R/A</span>
</div>
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>Avaliação de Prontidão Financeira prática</span>
</div>
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>Plano de implementação de 90 dias</span>
</div>
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>Checklist de auditor externo (NBC TA 315)</span>
</div>
</div>

<button data-ebook-download class="w-full px-6 py-3 bg-gosign-accent-btn text-white font-semibold rounded-md hover:bg-gosign-accent-btn-hover transition-colors text-sm flex items-center justify-center gap-2 cursor-pointer">
<svg class="w-5 h-5" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M4 16v1a3 3 0 003 3h10a3 3 0 003-3v-1m-4-4l-4 4m0 0l-4-4m4 4V4"/></svg>
Baixar PDF
</button>
</div>
</div>

</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">5 números-chave do manual</h2>

<div class="grid sm:grid-cols-2 lg:grid-cols-3 gap-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">5%</p>
<p class="text-small text-gosign-text">do faturamento anual é perdido por fraude no mundo</p>
<p class="text-xs text-gosign-text-light mt-1">ACFE 2024</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">42%</p>
<p class="text-small text-gosign-text">das faturas em contas a pagar ainda são processadas manualmente</p>
<p class="text-xs text-gosign-text-light mt-1">Institute of Finance & Management 2024</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">88-95%</p>
<p class="text-small text-gosign-text">taxa Zero-Touch com Decision Layer em processos financeiros</p>
<p class="text-xs text-gosign-text-light mt-1">Projetos de clientes Gosign</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">1:4-5</p>
<p class="text-small text-gosign-text">proporção de investimento: 1 EUR tecnologia = 4-5 EUR governança</p>
<p class="text-xs text-gosign-text-light mt-1">McKinsey 2024</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">R$ 50M</p>
<p class="text-small text-gosign-text">multa máxima por infração conforme PL 2338/2023</p>
<p class="text-xs text-gosign-text-light mt-1">PL 2338/2023</p>
</div>
</div>

</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Para quem é este manual?</h2>

<div class="grid sm:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">CFO / VP Finanças</p>
<p class="text-small text-gosign-text-light">Você é responsável pela estratégia de IA em finanças e precisa de um framework que convença os auditores externos, o jurídico e o conselho de administração ao mesmo tempo.</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">Diretor Financeiro / Gestor de Contabilidade</p>
<p class="text-small text-gosign-text-light">Você implementa processos impulsionados por IA e precisa de regras claras de decisão: o que automatizar e o que não. Como manter a segurança de auditoria?</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">Auditor externo / Auditoria interna</p>
<p class="text-small text-gosign-text-light">Você audita processos financeiros assistidos por IA e precisa de transparência: quais lançamentos o agente processa e quais são feitos por humanos? Como funciona o audit trail?</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">Finance Compliance / Jurídico</p>
<p class="text-small text-gosign-text-light">Você precisa implementar os requisitos de regulamentação de IA para processos financeiros e precisa de uma checklist de conformidade com medidas concretas e integração com o SCI.</p>
</div>
</div>

</div>
</section>

<section class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-12 border-t border-gosign-border">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Mais eBooks</h2>
<div class="grid grid-cols-1 md:grid-cols-2 gap-6">

<div class="bg-white border border-gosign-border rounded-card p-5">
<p class="font-semibold text-gosign-dark mb-1">IA em RH - Manual de Governança</p>
<p class="text-small text-gosign-text-light mb-3">Para CHROs e líderes de RH</p>
<a href="/br/ebook/ia-rh-manual-governanca/" class="text-sm text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Baixar grátis</a>
</div>

<div class="bg-white border border-gosign-border rounded-card p-5">
<p class="font-semibold text-gosign-dark mb-1">Infraestrutura de IA - Manual de Governança</p>
<p class="text-small text-gosign-text-light mb-3">Para CTOs e liderança de TI</p>
<a href="/br/ebook/ia-infraestrutura-manual-governanca/" class="text-sm text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Baixar grátis</a>
</div>

<a href="/br/ebook/finance-agent-readiness-assessment/" class="block border border-gosign-border rounded-card p-4 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-1">Finance Assessment</p>
<p class="text-body font-semibold text-gosign-dark">Finance Agent Readiness Assessment</p>
<p class="text-small text-gosign-text-light mt-1">15 perguntas para CFO e auditores externos</p>
</a>

</div>
</section>

--- eBook: Infraestrutura de IA - Manual de Governança para o CTO ---
> eBook gratuito: Build, Buy, Hybrid - infraestrutura de IA em conformidade regulatória. Manual de governança para CTOs e líderes de infraestrutura.

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">

<div class="grid md:grid-cols-5 gap-12 items-start">

<div class="md:col-span-3">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">O que você encontrará neste manual</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
Segundo o Gartner (2024), as empresas gastarão mais de 644 bilhões de USD em infraestrutura de IA até 2027. Ao mesmo tempo, desperdiçam 28% dos gastos com nuvem (Flexera 2024). Este manual mostra como construir infraestrutura de IA em conformidade com a governança, eficiente em custos e preparada para o EU AI Act e a LGPD (PT: RGPD).
</p>

<div class="space-y-4 mb-8">
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">1</span>
<div>
<p class="font-semibold text-gosign-dark">Por que o CTO deve liderar o AI Infrastructure Governance</p>
<p class="text-small text-gosign-text-light">Shadow AI, a lacuna de governança e a lista de verificação do CTO para começar.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">2</span>
<div>
<p class="font-semibold text-gosign-dark">Build, Buy, Hybrid: o framework B/B/H</p>
<p class="text-small text-gosign-text-light">Matriz de decisão por tipo de carga de trabalho com custos ocultos e riscos ocultos.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">3</span>
<div>
<p class="font-semibold text-gosign-dark">EU AI Act: 6 requisitos técnicos (art. 9-15)</p>
<p class="text-small text-gosign-text-light">Obrigações de conformidade como decisões de infraestrutura com lista de verificação técnica.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">4</span>
<div>
<p class="font-semibold text-gosign-dark">Security & Data Sovereignty</p>
<p class="text-small text-gosign-text-light">Data Residency, criptografia, arquitetura Zero Trust e conformidade com LGPD/RGPD no uso de LLM.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">5</span>
<div>
<p class="font-semibold text-gosign-dark">4 padrões de infraestrutura em produção</p>
<p class="text-small text-gosign-text-light">Agent Orchestration, Document Intelligence, Model Gateway, Monitoring & Observability.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">6</span>
<div>
<p class="font-semibold text-gosign-dark">Infrastructure Readiness Assessment (10 perguntas)</p>
<p class="text-small text-gosign-text-light">Onde está a sua infraestrutura? Autoavaliação com pontuação e plano de 90 dias.</p>
</div>
</div>
</div>
</div>

<div class="md:col-span-2">
<div class="bg-gosign-light border border-gosign-border rounded-card p-6 sticky top-8">
<p class="text-h3 font-bold text-gosign-dark mb-2">Baixar gratuitamente</p>
<p class="text-small text-gosign-text-light mb-4">PDF, 28 páginas. Envio imediato por e-mail.</p>

<div class="space-y-3 mb-6">
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>Matriz de decisão Build/Buy/Hybrid</span>
</div>
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>Lista de verificação de conformidade com o EU AI Act (técnica)</span>
</div>
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>4 padrões de infraestrutura prontos para produção</span>
</div>
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>Infrastructure Readiness Assessment + plano de 90 dias</span>
</div>
</div>

<button data-ebook-download class="w-full px-6 py-3 bg-gosign-accent-btn text-white font-semibold rounded-md hover:bg-gosign-accent-btn-hover transition-colors text-sm flex items-center justify-center gap-2 cursor-pointer">
<svg class="w-5 h-5" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M4 16v1a3 3 0 003 3h10a3 3 0 003-3v-1m-4-4l-4 4m0 0l-4-4m4 4V4"/></svg>
Baixar PDF
</button>
</div>
</div>

</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">5 números-chave do manual</h2>

<div class="grid sm:grid-cols-2 lg:grid-cols-3 gap-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">644 bi</p>
<p class="text-small text-gosign-text">USD em gastos globais com infraestrutura de IA até 2027</p>
<p class="text-xs text-gosign-text-light mt-1">Gartner 2024</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">28%</p>
<p class="text-small text-gosign-text">dos gastos com nuvem desperdiçados por falta de governança</p>
<p class="text-xs text-gosign-text-light mt-1">Flexera 2024</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">82%</p>
<p class="text-small text-gosign-text">operam multi-cloud sem governança centralizada de IA</p>
<p class="text-xs text-gosign-text-light mt-1">HashiCorp 2024</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">40%</p>
<p class="text-small text-gosign-text">dos incidentes de segurança causados por serviços em nuvem mal configurados</p>
<p class="text-xs text-gosign-text-light mt-1">ENISA 2024</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">15 M</p>
<p class="text-small text-gosign-text">EUR multa máxima por violação das obrigações de alto risco</p>
<p class="text-xs text-gosign-text-light mt-1">EU AI Act, art. 99</p>
</div>
</div>

</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Para quem é este manual?</h2>

<div class="grid sm:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">CTO / VP Engineering</p>
<p class="text-small text-gosign-text-light">Você é responsável pela estratégia de infraestrutura de IA e precisa de um framework que combine escalabilidade, conformidade e governança de custos.</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">Responsável de infraestrutura / plataforma</p>
<p class="text-small text-gosign-text-light">Você constrói a plataforma para cargas de trabalho de IA e precisa de padrões prontos para produção: Agent Orchestration, Model Gateway, Document Intelligence.</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">Cloud Architect / DevOps Lead</p>
<p class="text-small text-gosign-text-light">Você decide entre build vs. buy e precisa da matriz de decisão: qual carga de trabalho hospedar internamente, qual executar como serviço gerenciado?</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">CISO / Responsável de segurança</p>
<p class="text-small text-gosign-text-light">Você deve garantir a soberania de dados e precisa do stack de segurança: Zero Trust, triagem de PII, criptografia, segurança da cadeia de suprimentos.</p>
</div>
</div>

</div>
</section>

<section class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-12 border-t border-gosign-border">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Mais eBooks</h2>
<div class="grid grid-cols-1 md:grid-cols-2 gap-6">

<div class="bg-white border border-gosign-border rounded-card p-5">
<p class="font-semibold text-gosign-dark mb-1">IA em RH - Manual de Governança</p>
<p class="text-small text-gosign-text-light mb-3">Para CHROs e líderes de RH</p>
<a href="/br/ebook/ia-rh-manual-governanca/" class="text-sm text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Baixar grátis</a>
</div>

<div class="bg-white border border-gosign-border rounded-card p-5">
<p class="font-semibold text-gosign-dark mb-1">IA em Finanças - Manual de Governança</p>
<p class="text-small text-gosign-text-light mb-3">Para CFOs e liderança financeira</p>
<a href="/br/ebook/ia-financas-manual-governanca/" class="text-sm text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Baixar grátis</a>
</div>

<a href="/br/ebook/hr-agent-readiness-assessment/" class="block border border-gosign-border rounded-card p-4 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-1">HR Assessment</p>
<p class="text-body font-semibold text-gosign-dark">HR Agent Readiness Assessment</p>
<p class="text-small text-gosign-text-light mt-1">15 perguntas para sua equipe de liderança</p>
</a>

<a href="/br/ebook/finance-agent-readiness-assessment/" class="block border border-gosign-border rounded-card p-4 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-1">Finance Assessment</p>
<p class="text-body font-semibold text-gosign-dark">Finance Agent Readiness Assessment</p>
<p class="text-small text-gosign-text-light mt-1">15 perguntas para CFO e auditores externos</p>
</a>

</div>
</section>

--- eBook: IA em RH - Manual de Governança para o CHRO ---
> eBook gratuito: EU AI Act, representação dos trabalhadores e Decision Layer - o manual de governança para líderes de RH antes do prazo de alto risco (2 de agosto de 2026; adiamento para dezembro de 2027 acordado provisoriamente).

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">

<div class="grid md:grid-cols-5 gap-12 items-start">

<div class="md:col-span-3">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">O que você encontrará neste manual</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
O EU AI Act classifica sistemas de IA em RH como alto risco; pela legislação vigente, as obrigações se aplicam a partir de 2 de agosto de 2026, com adiamento para 2 de dezembro de 2027 acordado provisoriamente (Digital Omnibus, maio de 2026; adoção formal ainda pendente). 73% das organizações ainda não possuem um framework de governança (ISACA 2024). Este manual preenche essa lacuna - com frameworks concretos, checklists e uma avaliação de prontidão.
</p>

<div class="space-y-4 mb-8">
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">1</span>
<div>
<p class="font-semibold text-gosign-dark">Por que o CHRO deve liderar a governança de IA em RH - não TI</p>
<p class="text-small text-gosign-text-light">Propriedade da governança, conceito de papéis e checklist do CHRO.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">2</span>
<div>
<p class="font-semibold text-gosign-dark">Três tipos de decisões: Humano, Regramento, IA</p>
<p class="text-small text-gosign-text-light">O framework de decisões com Agent Readiness Score para cada processo de RH.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">3</span>
<div>
<p class="font-semibold text-gosign-dark">EU AI Act: 6 requisitos obrigatórios em detalhe</p>
<p class="text-small text-gosign-text-light">Art. 9-15 com checklist de compliance para verificação.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">4</span>
<div>
<p class="font-semibold text-gosign-dark">Representação dos trabalhadores como parceiro de design</p>
<p class="text-small text-gosign-text-light">sindicato e CIPA, acordo coletivo como restrição técnica, AI Literacy.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">5</span>
<div>
<p class="font-semibold text-gosign-dark">4 processos de RH no Decision Layer</p>
<p class="text-small text-gosign-text-light">Folha de pagamento, despesas de viagem, recrutamento, férias e ausências - com taxas Zero-Touch.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">6</span>
<div>
<p class="font-semibold text-gosign-dark">Avaliação de prontidão (10 perguntas)</p>
<p class="text-small text-gosign-text-light">Onde sua organização se encontra? Autoavaliação com pontuação e recomendações.</p>
</div>
</div>
</div>
</div>

<div class="md:col-span-2">
<div class="bg-gosign-light border border-gosign-border rounded-card p-6 sticky top-8">
<p class="text-h3 font-bold text-gosign-dark mb-2">Baixar gratuitamente</p>
<p class="text-small text-gosign-text-light mb-4">PDF, 25 páginas. Entrega imediata por e-mail.</p>

<div class="space-y-3 mb-6">
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>Checklist de compliance EU AI Act</span>
</div>
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>Framework de decisões (H/R/A)</span>
</div>
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>Avaliação de prontidão prática</span>
</div>
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>Plano de implementação de 90 dias</span>
</div>
</div>
<button data-ebook-download class="w-full px-6 py-3 bg-gosign-accent-btn text-white font-semibold rounded-md hover:bg-gosign-accent-btn-hover transition-colors text-sm flex items-center justify-center gap-2 cursor-pointer">
<svg class="w-5 h-5" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M4 16v1a3 3 0 003 3h10a3 3 0 003-3v-1m-4-4l-4 4m0 0l-4-4m4 4V4"/></svg>
Baixar PDF
</button>
</div>
</div>

</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">5 números-chave do manual</h2>

<div class="grid sm:grid-cols-2 lg:grid-cols-3 gap-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">73%</p>
<p class="text-small text-gosign-text">das organizações sem framework formal de governança de IA</p>
<p class="text-xs text-gosign-text-light mt-1">ISACA 2024</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">6</p>
<p class="text-small text-gosign-text">requisitos obrigatórios para IA de alto risco em RH a partir de 2 de agosto de 2026 (adiamento para dezembro de 2027 acordado provisoriamente)</p>
<p class="text-xs text-gosign-text-light mt-1">EU AI Act, Art. 9-15</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">85-92%</p>
<p class="text-small text-gosign-text">taxa Zero-Touch com Decision Layer em processos de RH</p>
<p class="text-xs text-gosign-text-light mt-1">Projetos de clientes Gosign</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">1:4-5</p>
<p class="text-small text-gosign-text">proporção de investimento: 1 EUR tecnologia = 4-5 EUR governança</p>
<p class="text-xs text-gosign-text-light mt-1">McKinsey 2024</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">60-80%</p>
<p class="text-small text-gosign-text">menos correções contábeis com regras explícitas</p>
<p class="text-xs text-gosign-text-light mt-1">Hackett Group 2024</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">15M</p>
<p class="text-small text-gosign-text">EUR multa máxima por violação de requisitos de alto risco</p>
<p class="text-xs text-gosign-text-light mt-1">EU AI Act, Art. 99</p>
</div>
</div>

</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Para quem é este manual?</h2>

<div class="grid sm:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">CHRO / VP RH</p>
<p class="text-small text-gosign-text-light">Você é responsável pela estratégia de IA em RH e precisa de um framework que convença o sindicato, o jurídico e a diretoria ao mesmo tempo.</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">Diretor de People Operations</p>
<p class="text-small text-gosign-text-light">Você implementa processos impulsionados por IA e precisa de regras claras de decisão: o que automatizar e o que não.</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">Sindicato / CIPA</p>
<p class="text-small text-gosign-text-light">Você fiscaliza o uso de IA em RH e precisa de transparência: quais decisões o agente toma e quais são tomadas por humanos?</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">RH Compliance / Jurídico</p>
<p class="text-small text-gosign-text-light">Você precisa implementar os requisitos do EU AI Act e precisa de uma checklist de compliance com medidas concretas.</p>
</div>
</div>

</div>
</section>

<section class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-12 border-t border-gosign-border">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Mais eBooks</h2>
<div class="grid grid-cols-1 md:grid-cols-2 gap-6">

<div class="bg-white border border-gosign-border rounded-card p-5">
<p class="font-semibold text-gosign-dark mb-1">IA em Finanças - Manual de Governança</p>
<p class="text-small text-gosign-text-light mb-3">Para CFOs e liderança financeira</p>
<a href="/br/ebook/ia-financas-manual-governanca/" class="text-sm text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Baixar grátis</a>
</div>

<div class="bg-white border border-gosign-border rounded-card p-5">
<p class="font-semibold text-gosign-dark mb-1">Infraestrutura de IA - Manual de Governança</p>
<p class="text-small text-gosign-text-light mb-3">Para CTOs e liderança de TI</p>
<a href="/br/ebook/ia-infraestrutura-manual-governanca/" class="text-sm text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Baixar grátis</a>
</div>

<a href="/br/ebook/hr-agent-readiness-assessment/" class="block border border-gosign-border rounded-card p-4 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-1">HR Assessment</p>
<p class="text-body font-semibold text-gosign-dark">HR Agent Readiness Assessment</p>
<p class="text-small text-gosign-text-light mt-1">15 perguntas para sua equipe de liderança</p>
</a>

</div>
</section>

--- eBooks Gratuitos - Manuais de Governança de IA ---
> Baixe manuais gratuitos de governança para RH, Finanças e Infraestrutura. Conformidade regulatória, arquitetura Decision Layer, avaliações de prontidão.

<section class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-12">
<div class="grid grid-cols-1 md:grid-cols-3 gap-8">

<div class="bg-white border border-gosign-border rounded-card p-6 flex flex-col">
<div class="w-12 h-12 rounded-full bg-orange-50 flex items-center justify-center mb-4">
<svg class="w-6 h-6 text-gosign-accent" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M17 20h5v-2a3 3 0 00-5.356-1.857M17 20H7m10 0v-2c0-.656-.126-1.283-.356-1.857M7 20H2v-2a3 3 0 015.356-1.857M7 20v-2c0-.656.126-1.283.356-1.857m0 0a5.002 5.002 0 019.288 0M15 7a3 3 0 11-6 0 3 3 0 016 0z"></path></svg>
</div>
<h2 class="text-h3 font-bold text-gosign-dark mb-2">IA em RH</h2>
<p class="text-body text-gosign-text mb-3 flex-1">Checklist regulatório, Decision Framework, perspectiva da representação dos trabalhadores e avaliação de prontidão - o manual de governança para o CHRO.</p>
<p class="text-small text-gosign-text-light mb-4">Para CHROs e líderes de RH - 25 páginas</p>
<a href="/br/ebook/ia-rh-manual-governanca/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Baixar grátis</a>
</div>

<div class="bg-white border border-gosign-border rounded-card p-6 flex flex-col">
<div class="w-12 h-12 rounded-full bg-orange-50 flex items-center justify-center mb-4">
<svg class="w-6 h-6 text-gosign-accent" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 7h6m0 10v-3m-3 3h.01M9 17h.01M9 14h.01M12 14h.01M15 11h.01M12 11h.01M9 11h.01M7 21h10a2 2 0 002-2V5a2 2 0 00-2-2H7a2 2 0 00-2 2v14a2 2 0 002 2z"></path></svg>
</div>
<h2 class="text-h3 font-bold text-gosign-dark mb-2">IA em Finanças</h2>
<p class="text-body text-gosign-text mb-3 flex-1">Conformidade, auditores externos e Decision Layer - o manual de governança para o CFO. Com H/R/A-Framework e avaliação de prontidão para o setor financeiro.</p>
<p class="text-small text-gosign-text-light mb-4">Para CFOs e liderança financeira - 28 páginas</p>
<a href="/br/ebook/ia-financas-manual-governanca/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Baixar grátis</a>
</div>

<div class="bg-white border border-gosign-border rounded-card p-6 flex flex-col">
<div class="w-12 h-12 rounded-full bg-orange-50 flex items-center justify-center mb-4">
<svg class="w-6 h-6 text-gosign-accent" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M5 12h14M5 12a2 2 0 01-2-2V6a2 2 0 012-2h14a2 2 0 012 2v4a2 2 0 01-2 2M5 12a2 2 0 00-2 2v4a2 2 0 002 2h14a2 2 0 002-2v-4a2 2 0 00-2-2m-2-4h.01M17 16h.01"></path></svg>
</div>
<h2 class="text-h3 font-bold text-gosign-dark mb-2">Infraestrutura de IA</h2>
<p class="text-body text-gosign-text mb-3 flex-1">Build, Buy, Hybrid - infraestrutura em conformidade regulatória. Com B/B/H-Framework, 7-Layer Reference Architecture e checklist do CTO.</p>
<p class="text-small text-gosign-text-light mb-4">Para CTOs e liderança de TI - 28 páginas</p>
<a href="/br/ebook/ia-infraestrutura-manual-governanca/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Baixar grátis</a>
</div>

</div>

<h2 class="text-h2 font-bold text-gosign-dark mt-12 mb-6">Readiness Assessments</h2>
<p class="text-body text-gosign-text-light mb-8">Quão preparada está sua organização para AI Agents? 15 perguntas, planilhas para preencher, avaliação de equipe com análise de lacunas.</p>

<div class="grid grid-cols-1 md:grid-cols-2 gap-8">

<div class="bg-white border-2 border-gosign-accent/20 rounded-card p-6 flex flex-col">
<div class="w-12 h-12 rounded-full bg-orange-50 flex items-center justify-center mb-4">
<svg class="w-6 h-6 text-gosign-accent" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 5H7a2 2 0 00-2 2v12a2 2 0 002 2h10a2 2 0 002-2V7a2 2 0 00-2-2h-2M9 5a2 2 0 002 2h2a2 2 0 002-2M9 5a2 2 0 012-2h2a2 2 0 012 2m-6 9l2 2 4-4"></path></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">HR Agent Readiness</h3>
<p class="text-body text-gosign-text mb-3 flex-1">15 perguntas para sua equipe de liderança. Maturidade de processos, governança, paisagem de dados, representação dos trabalhadores, infraestrutura de TI.</p>
<p class="text-small text-gosign-text-light mb-4">Para CHROs e equipe de liderança de RH - 14 páginas</p>
<a href="/br/ebook/hr-agent-readiness-assessment/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Baixar assessment</a>
</div>

<div class="bg-white border-2 border-gosign-accent/20 rounded-card p-6 flex flex-col">
<div class="w-12 h-12 rounded-full bg-orange-50 flex items-center justify-center mb-4">
<svg class="w-6 h-6 text-gosign-accent" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 5H7a2 2 0 00-2 2v12a2 2 0 002 2h10a2 2 0 002-2V7a2 2 0 00-2-2h-2M9 5a2 2 0 002 2h2a2 2 0 002-2M9 5a2 2 0 012-2h2a2 2 0 012 2m-6 9l2 2 4-4"></path></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Finance Agent Readiness</h3>
<p class="text-body text-gosign-text mb-3 flex-1">15 perguntas para CFO e auditores externos. Verificação de conformidade, paisagem ERP, velocidade de fechamento, maturidade de detecção de fraude.</p>
<p class="text-small text-gosign-text-light mb-4">Para CFOs e equipe de liderança financeira - 14 páginas</p>
<a href="/br/ebook/finance-agent-readiness-assessment/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Baixar assessment</a>
</div>

</div>

<h2 class="text-h2 font-bold text-gosign-dark mt-12 mb-6">Teste rápido online</h2>
<p class="text-body text-gosign-text-light mb-8">Sem tempo para a avaliação completa de 15 perguntas? O teste rápido online leva 3 minutos - com gráfico radar automático e recomendações de agentes.</p>

<div class="grid grid-cols-1 md:grid-cols-2 gap-8">
<a href="/br/hr-agent-readiness/" class="block bg-gosign-dark rounded-card p-6 hover:bg-gosign-dark/90 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">3 minutos, 7 perguntas</p>
<p class="text-h3 font-bold text-white">HR Agent Readiness</p>
<p class="text-body text-white/70 mt-2">Nível de maturidade, gráfico radar e recomendações do catálogo de 48 agentes.</p>
</a>
<a href="/br/finance-agent-readiness/" class="block bg-gosign-dark rounded-card p-6 hover:bg-gosign-dark/90 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">3 minutos, 7 perguntas</p>
<p class="text-h3 font-bold text-white">Finance Agent Readiness</p>
<p class="text-body text-white/70 mt-2">Nível de maturidade, gráfico radar e recomendações do catálogo de 49 agentes.</p>
</a>
</div>

</section>

--- Fatos - Gosign em Números ---
> Fatos citáveis sobre Gosign GmbH. Dados da empresa, localizações, certificações e padrões de compliance em resumo.

<article class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<div class="prose prose-lg prose-headings:text-gosign-dark prose-headings:font-bold prose-h2:text-h2 prose-h2:mt-12 prose-h2:mb-4 prose-h3:text-h3 prose-h3:mt-8 prose-h3:mb-3 prose-p:text-gosign-text prose-p:leading-relaxed prose-a:text-gosign-accent-text prose-a:underline prose-a:decoration-gosign-accent-text/30 hover:prose-a:decoration-gosign-accent-text prose-strong:text-gosign-dark prose-ul:text-gosign-text prose-ol:text-gosign-text">

## Empresa

Gosign GmbH. Empresa de desenvolvimento de software, fundada em Hamburgo em 2001. Empresa familiar. Diretores-gerentes: Bert Gogolin e Dieter Gogolin. Hallerstraße 8, 20146 Hamburgo, Alemanha. Registro Comercial Hamburgo HRB 112197. CNPJ/IE: DE215891388.

## Dados-Chave

108 colaboradores. Mais de 5.000 projetos desde 2001. 25 anos de desenvolvimento de software. Desde 2023 focados em Enterprise AI Infrastructure e Agent Engineering. Clientes de referência: Airbus, Volkswagen, Shell, Evonik, Sony.

## Localizações

Hamburgo (sede), Cracóvia, Barcelona, Lisboa, São Paulo. Centro de desenvolvimento no Paquistão desde 2002.

## Idiomas

Alemão, inglês, polonês, espanhol, português, urdu.

## Associações e Certificações

Membro do BVDW (Bundesverband Digitale Wirtschaft). Engenheiros de AI com certificação Microsoft Azure AI.

## Padrões de Compliance

Cert-Ready by Design: ISA, PS 951, IDW, GoB/GoBD (padrão GoBD alemão). EU AI Act Readiness: classificação de risco e obrigações de documentação integradas na arquitetura de agentes. Data Residency: processamento de dados na infraestrutura do cliente - Azure Brasil (São Paulo), Azure UE, GCP Brasil (São Paulo), GCP UE, AWS Brasil (São Paulo), AWS UE, Self-Hosted ou híbrido. O cliente decide a região e o modelo de hosting. DPA com todos os subprocessadores. Para total independência do Cloud Act: Self-Hosted em datacenter próprio ou em servidores próprios. LGPD/RGPD: sem cookies, sem trackers, sem embeds externos em gosign.de. Analítica web sem cookies, agregada.

## Contato

Gosign GmbH · Hallerstraße 8 · 20146 Hamburgo, Alemanha
> [Entrar em contato](/br/contato/)

</div>
</div>
</article>

--- Ferramentas AI gratuitas - Apoio interativo à decisão ---
> 8 ferramentas AI gratuitas no navegador: Board Deck Generator, EU AI Act Risk Classifier, calculadora ROI, planejador TCO e mais. Sem login.

<section class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-12">

<p class="text-body text-gosign-text mb-10">Todas as ferramentas funcionam diretamente no navegador. Sem registro, sem compartilhamento de dados, sem custos ocultos. Os resultados são baseados em frameworks e benchmarks públicos.</p>

<div class="grid grid-cols-1 md:grid-cols-2 gap-6">

<div class="bg-gosign-dark rounded-card p-6 flex flex-col">
<span class="inline-block text-small font-medium text-gosign-accent-on-dark bg-white/10 rounded-full px-3 py-1 mb-4 w-fit">Gratuito, no navegador, sem login</span>
<h2 class="text-h3 font-bold text-white mb-2">Board Deck Generator</h2>
<p class="text-body text-white/70 mb-4 flex-1">Avaliação inicial de 9 slides com análise de ROI, avaliação de riscos e comparação de 3 cenários. 7 campos, apresentação para a diretoria como resultado.</p>
<a href="/br/catalogo-agentes-hr/" class="inline-flex items-center gap-2 text-gosign-accent-on-dark hover:text-white font-medium">Ir ao catálogo HR &rarr;</a>
</div>

<div class="bg-gosign-dark rounded-card p-6 flex flex-col">
<span class="inline-block text-small font-medium text-gosign-accent-on-dark bg-white/10 rounded-full px-3 py-1 mb-4 w-fit">Gratuito, no navegador, sem login</span>
<h2 class="text-h3 font-bold text-white mb-2">EU AI Act Risk Classifier</h2>
<p class="text-body text-white/70 mb-4 flex-1">Classificação de risco conforme o Regulamento (UE) 2024/1689. 7 perguntas, classificação clara em Minimal, Limited, High ou Unacceptable Risk.</p>
<a href="/br/governance/eu-ai-act/" class="inline-flex items-center gap-2 text-gosign-accent-on-dark hover:text-white font-medium">Ir ao Risk Classifier &rarr;</a>
</div>

<div class="bg-gosign-dark rounded-card p-6 flex flex-col">
<span class="inline-block text-small font-medium text-gosign-accent-on-dark bg-white/10 rounded-full px-3 py-1 mb-4 w-fit">Gratuito, no navegador, sem login</span>
<h2 class="text-h3 font-bold text-white mb-2">Verificação de codecisão</h2>
<p class="text-body text-white/70 mb-4 flex-1">O sindicato precisa aprovar? 5 perguntas com base na legislação de codecisão aplicável com uma recomendação clara.</p>
<a href="/br/governance/co-determination/" class="inline-flex items-center gap-2 text-gosign-accent-on-dark hover:text-white font-medium">Ir à verificação de codecisão &rarr;</a>
</div>

<div class="bg-gosign-dark rounded-card p-6 flex flex-col">
<span class="inline-block text-small font-medium text-gosign-accent-on-dark bg-white/10 rounded-full px-3 py-1 mb-4 w-fit">Gratuito, no navegador, sem login</span>
<h2 class="text-h3 font-bold text-white mb-2">Ferramenta de comparação de agentes</h2>
<p class="text-body text-white/70 mb-4 flex-1">Compare 2-3 agentes AI lado a lado. Custos, nível de automação, requisitos de governança e esforço de implementação em um só lugar.</p>
<a href="/br/catalogo-agentes-hr/" class="inline-flex items-center gap-2 text-gosign-accent-on-dark hover:text-white font-medium">Ir ao catálogo HR &rarr;</a>
</div>

<div class="bg-gosign-dark rounded-card p-6 flex flex-col">
<span class="inline-block text-small font-medium text-gosign-accent-on-dark bg-white/10 rounded-full px-3 py-1 mb-4 w-fit">Gratuito, no navegador, sem login</span>
<h2 class="text-h3 font-bold text-white mb-2">Workforce Planner</h2>
<p class="text-body text-white/70 mb-4 flex-1">Planejamento de pessoal com vs. sem agentes AI. Baseado em benchmarks SHRM e Hackett. Mostra economias de FTE e ganhos de produtividade.</p>
<a href="/br/catalogo-agentes-hr/" class="inline-flex items-center gap-2 text-gosign-accent-on-dark hover:text-white font-medium">Ir ao catálogo HR &rarr;</a>
</div>

<div class="bg-gosign-dark rounded-card p-6 flex flex-col">
<span class="inline-block text-small font-medium text-gosign-accent-on-dark bg-white/10 rounded-full px-3 py-1 mb-4 w-fit">Gratuito, no navegador, sem login</span>
<h2 class="text-h3 font-bold text-white mb-2">Calculadora TCO</h2>
<p class="text-body text-white/70 mb-4 flex-1">Projeção de custos de 3 anos para infraestrutura AI. Build vs. Buy vs. Hybrid. Custos de licença, implementação, operação contínua.</p>
<a href="/br/servicos/infraestrutura/" class="inline-flex items-center gap-2 text-gosign-accent-on-dark hover:text-white font-medium">Ir ao serviço de infraestrutura &rarr;</a>
</div>

<div class="bg-gosign-dark rounded-card p-6 flex flex-col">
<span class="inline-block text-small font-medium text-gosign-accent-on-dark bg-white/10 rounded-full px-3 py-1 mb-4 w-fit">Gratuito, no navegador, sem login</span>
<h2 class="text-h3 font-bold text-white mb-2">Calculadora ROI rápida</h2>
<p class="text-body text-white/70 mb-4 flex-1">Cálculo rápido de economias para processos de RH, Finanças e Viagens. Entrada: volume de casos, tempo por caso, tarifa horária. Resultado: potencial de economia anual.</p>
<a href="/br/catalogo-agentes-hr/" class="inline-flex items-center gap-2 text-gosign-accent-on-dark hover:text-white font-medium">Ir ao catálogo HR &rarr;</a>
</div>

<div class="bg-gosign-dark rounded-card p-6 flex flex-col">
<span class="inline-block text-small font-medium text-gosign-accent-on-dark bg-white/10 rounded-full px-3 py-1 mb-4 w-fit">Gratuito, no navegador, sem login</span>
<h2 class="text-h3 font-bold text-white mb-2">Readiness Assessment</h2>
<p class="text-body text-white/70 mb-4 flex-1">Teste online de 7 perguntas com gráfico radar. Avalie sua organização em maturidade de processos, dados, governança, TI e gestão de mudanças.</p>
<a href="/br/hr-agent-readiness/" class="inline-flex items-center gap-2 text-gosign-accent-on-dark hover:text-white font-medium">Ir ao Readiness Assessment &rarr;</a>
</div>

</div>
</section>

--- AI Agents para Finance & Auditoria ---
> Enterprise AI Agents para processos financeiros: documentos, depreciação, correções contábeis, avaliações fiscais. prüfungsfähig by Design, auditável

<div class="not-prose my-8 bg-gosign-dark rounded-card p-6 sm:p-8">
<div class="flex flex-col sm:flex-row sm:items-center gap-4">
<div class="flex-1">
<p class="text-h3 font-bold text-white mb-2">eBook gratuito: IA em Finanças</p>
<p class="text-body text-white/80">Conformidade, auditores externos e Decision Layer - o manual de governança para liderança financeira.</p>
</div>
<a href="/br/ebook/ia-financas-manual-governanca/" class="inline-flex items-center gap-2 px-6 py-3 bg-gosign-accent-btn text-white font-semibold rounded-lg hover:bg-gosign-accent-btn-hover transition-colors whitespace-nowrap">Baixar agora</a>
</div>
</div>

<!-- Problem -->
<section class="py-section bg-gosign-white"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow"><h2 class="text-h1 font-bold text-gosign-dark">O problema: lógica contábil na cabeça, não no sistema</h2><p class="text-body-lg text-gosign-text-light mt-4">Decisões financeiras em empresas dependem do conhecimento de contadores individuais. Classificações de depreciação, notas de despesas, correções contábeis, avaliações fiscais - o conjunto de regras é complexo e a aplicação varia por pessoa, localidade e interpretação.</p><p class="text-body-lg text-gosign-text-light mt-4">As consequências atingem diretamente o balanço: correções que poderiam ter sido evitadas. Classificações de depreciação questionadas apenas pelo auditor externo. Despesas tratadas de forma diferente em cada escritório.</p><p class="text-body-lg text-gosign-text-light mt-4">Para auditores, revisão interna e centros de serviços compartilhados, isso é um risco sistemático.</p><p class="text-body-lg text-gosign-text-light mt-4">Essa inconsistência não apenas aumenta correções contábeis - também aumenta o esforço de auditoria, ciclos de conciliação e o risco de achados por revisão interna ou auditores externos. O Decision Layer transfere esses riscos da interpretação individual para uma arquitetura de decisões versionada e rastreável. Onde a decisão é determinística, o agente aplica o conjunto de regras de forma consistente. E onde o agente está confiante o suficiente: decide de forma autônoma - interpreta, classifica, avalia contexto. Isso não é if-then-else - é capacidade de julgamento dentro de limites definidos.</p></div></div></section>

<!-- Definição -->
<section class="py-section bg-gosign-light"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow"><h2 class="text-h1 font-bold text-gosign-dark">O que é um Finance Agent?</h2><p class="text-body-lg text-gosign-text-light mt-4">Um Finance Agent é um AI Agent especializado em processamento de documentos e contabilidade. Ele lê documentos com compreensão contextual da linguagem, avalia-os contra conjuntos de regras versionados (legislação tributária, normas contábeis, políticas internas) e produz propostas de lançamento documentadas. O <a href="/br/decision-layer/" class="text-gosign-accent-text hover:text-gosign-accent-hover">Decision Layer</a> roteia cada microdecisão: de forma autônoma com alta confiança e regra clara, ao especialista em casos excepcionais.</p><p class="text-body-lg text-gosign-text-light mt-4">SAP e TOTVS continuam sendo seus sistemas principais. O Finance Agent fica na frente - entrega resultados prontos para decisão com uma cadeia de justificação completa. Cada decisão produz um registro de decisão completo: input, regra aplicada, versão da regra, confiança, caminho de decisão, resultado. Isso não é documentação retroativa - é a prova técnica de como cada decisão foi tomada.</p></div></div></section>

<!-- Use Cases -->
<section class="py-section bg-gosign-light"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><h2 class="text-h1 font-bold text-gosign-dark mb-8">Cenários de uso concretos</h2><div class="grid grid-cols-1 md:grid-cols-2 gap-6"><div class="border border-gosign-border rounded-card p-6 bg-gosign-white"><h3 class="text-h3 font-bold text-gosign-dark">Processamento e classificação de documentos</h3><p class="text-body text-gosign-text-light mt-2">O Document Agent lê, compreende e avalia documentos com compreensão real da linguagem. Notas fiscais, notas de crédito, estornos, notas de despesas. O Decision Layer verifica completude, plausibilidade e classificação fiscal. Com alta confiança: proposta de lançamento automática. Em casos limítrofes: escalação ao especialista.</p></div><div class="border border-gosign-border rounded-card p-6 bg-gosign-white"><h3 class="text-h3 font-bold text-gosign-dark">Lógica de depreciação</h3><p class="text-body text-gosign-text-light mt-2">A lógica de depreciação varia por tipo de ativo, classificação fiscal e região. O Decision Layer torna a lógica explícita: classificação do tipo de ativo, verificação da classificação fiscal, aplicação da tabela de depreciação conforme versão vigente, documentação da justificativa.</p></div><div class="border border-gosign-border rounded-card p-6 bg-gosign-white"><h3 class="text-h3 font-bold text-gosign-dark">Notas de despesas de representação</h3><p class="text-body text-gosign-text-light mt-2">A interpretação variável da dedutibilidade é um dos pontos de auditoria mais comuns. O Decision Layer padroniza: verificação de completude, verificação de lista de participantes, verificação de propósito e relevância empresarial, aplicação de regras de dedutibilidade.</p></div><div class="border border-gosign-border rounded-card p-6 bg-gosign-white"><h3 class="text-h3 font-bold text-gosign-dark">Correções e garantia de qualidade</h3><p class="text-body text-gosign-text-light mt-2">Eliminar correções antes que aconteçam. O Workflow Agent orquestra o processo de garantia de qualidade: verificação automática de plausibilidade antes do lançamento, comparação com valores de referência, escalação ante anomalias.</p></div></div></div></section>

<!-- Quatro passos -->
<section class="py-section bg-gosign-white"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow"><h2 class="text-h1 font-bold text-gosign-dark">Quatro passos: do documento ao lançamento pronto para auditoria</h2><p class="text-body-lg text-gosign-text-light mt-4"><strong>1. Ler e compreender</strong> - O agent lê o documento com compreensão contextual da linguagem. Fornecedor, valor, descrição do serviço, características tributariamente relevantes. Não é correspondência rígida de templates - é compreensão real do documento.</p><p class="text-body-lg text-gosign-text-light mt-4"><strong>2. Avaliar</strong> - Conta, centro de custo, classificação tributária, início de depreciação, critérios de notas de despesas. Cada avaliação se baseia em um conjunto de regras versionado - não na experiência de contadores individuais.</p><p class="text-body-lg text-gosign-text-light mt-4"><strong>3. Decidir</strong> - O Decision Layer roteia: autônomo com alta confiança e regra clara, ao especialista em casos excepcionais ou baixa confiança. Você define os limites - não a IA.</p><p class="text-body-lg text-gosign-text-light mt-4"><strong>4. Documentar</strong> - Cada microdecisão produz um registro de decisão: input, regra aplicada, versão da regra, confiança, caminho de decisão, resultado, timestamp. Isso não é documentação retroativa - é a prova técnica de como cada decisão foi tomada.</p></div></div></section>

<!-- Fluxo de decisão -->
<section class="py-section bg-gosign-light"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><h2 class="text-h1 font-bold text-gosign-dark mb-6">Fluxo de decisão</h2><div class="mt-8 bg-gosign-dark rounded-card p-6 sm:p-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-4">Documento → Agent extrai → Decision Layer decompõe em etapas</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-4">
<div class="bg-white/5 rounded-card p-4">
<p class="text-xs font-bold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Regra</p>
<p class="text-small text-white/90 font-semibold">Casos claros</p>
<p class="text-small text-white/60 mt-2">Alíquota conforme legislação. Cálculo determinístico.</p>
</div>
<div class="bg-white/5 rounded-card p-4">
<p class="text-xs font-bold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Agent IA</p>
<p class="text-small text-white/90 font-semibold">Decisão por confiança</p>
<p class="text-small text-white/60 mt-2">Proposta de conta com score. Autônomo acima do limite.</p>
</div>
<div class="bg-white/5 rounded-card p-4">
<p class="text-xs font-bold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Humano</p>
<p class="text-small text-white/90 font-semibold">Exceção</p>
<p class="text-small text-white/60 mt-2">Especialista revisa e decide com contexto.</p>
</div>
</div>
<p class="text-xs text-white/60 mt-4 text-center">Audit Trail por etapa: Regra · Versão · Decisor</p>
</div></div></section>

<!-- Decision Layer detalhe -->
<section class="py-section bg-gosign-white"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow"><h2 class="text-h1 font-bold text-gosign-dark"><a href="/br/decision-layer/" class="hover:text-gosign-accent transition-colors">Decision Layer</a>: como decisões financeiras se tornam auditáveis</h2><p class="text-body-lg text-gosign-text-light mt-4">O <a href="/br/decision-layer/" class="text-gosign-accent-text hover:underline">Decision Layer</a> decompõe o processo contábil em passos de decisão individuais. Para cada passo define: decide o agent, um conjunto de regras, ou um humano?</p><p class="text-body-lg text-gosign-text-light mt-4">O agent lê, compreende e avalia documentos com compreensão real da linguagem. O Decision Layer roteia cada avaliação:</p><div class="mt-6 bg-gosign-light border border-gosign-border rounded-card p-6"><p class="text-body font-mono text-gosign-dark">Documento &rarr; Extração &rarr; Classificação &rarr; Avaliação de domínio &rarr; Confidence Score &rarr; Proposta de lançamento ou escalação humana</p></div><p class="text-body-lg text-gosign-text-light mt-4">Cada decisão produz um registro completo e imutável: input, modelo, avaliação, confidence score, regra aplicada com versão, caminho de decisão, resultado. Isso não é documentação retroativa - é a prova técnica de como cada decisão foi tomada.</p><p class="text-body text-gosign-text-light mt-4">Como são os modelos de custos para Enterprise AI e quanto realmente custa self-hosting vs. nuvem está detalhado na <a href="/br/revista/custos-ia-tco-comparacao/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">comparação TCO no Blueprint 2026</a>.</p></div></div></section>

<!-- Cert-Ready -->
<section class="py-section bg-gosign-light"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow"><h2 class="text-h1 font-bold text-gosign-dark">Cert-Ready by Design</h2><p class="text-body-lg text-gosign-text-light mt-4 italic">Não 'temos ISO'. Não 'não precisamos de ISO'. Mas sim: cada agent é tecnicamente construído para ser certificável e auditável a qualquer momento.</p><p class="text-body-lg text-gosign-text-light mt-4">Controles são objetos de dados de primeira classe no sistema - não documentos em uma pasta. Cada controle tem uma implementação técnica, um gerador automático de evidências e um histórico de evidências com drill-down até a implementação concreta.</p><p class="text-body-lg text-gosign-text-light mt-4">Controles vivem no banco de dados, não no Confluence. Evidências são geradas automaticamente. Auditores veem o status ao vivo no Portal do Auditor.</p><h3 class="text-h3 font-bold text-gosign-dark mt-8">Control Object Structure</h3><div class="mt-4 overflow-x-auto"><table class="w-full text-body text-gosign-text-light border-collapse"><thead><tr class="border-b-2 border-gosign-border"><th class="text-left py-2 pr-4 font-bold text-gosign-dark">Elemento</th><th class="text-left py-2 font-bold text-gosign-dark">Função</th></tr></thead><tbody><tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-mono text-small">Control_ID</td><td class="py-2">Identificação única do controle</td></tr><tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-mono text-small">Technical_Implementation</td><td class="py-2">Implementação técnica concreta (p. ex. política RLS, check API)</td></tr><tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-mono text-small">Rule_Version</td><td class="py-2">Versão da lógica de decisão subjacente</td></tr><tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-mono text-small">Evidence_Generator</td><td class="py-2">Mecanismo de verificação automático</td></tr><tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-mono text-small">Evidence_History</td><td class="py-2">Histórico de resultados de verificação com timestamp</td></tr><tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-mono text-small">Auditor_View</td><td class="py-2">Visão com drill-down até o nível de implementação</td></tr></tbody></table></div><p class="text-body-lg text-gosign-text-light mt-4">Controles são objetos de dados de primeira classe. Evidências são geradas automaticamente. O auditor vê status ao vivo, não snapshots.</p></div></div></section>

<!-- Integração -->
<section class="py-section bg-gosign-white"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow"><h2 class="text-h1 font-bold text-gosign-dark">Integração com seu ambiente de sistemas existente</h2><p class="text-body-lg text-gosign-text-light mt-4">AI Agents não substituem sistemas. SAP FI/CO continua sendo seu ERP, TOTVS continua sendo seu sistema contábil. A lógica do agent é desacoplada do sistema destino - a lógica contábil é separada da exportação.</p><div class="mt-6 flex flex-wrap gap-3"><span class="bg-gosign-light border border-gosign-border rounded-card px-4 py-2 text-body font-medium text-gosign-dark">SAP FI/CO</span><span class="bg-gosign-light border border-gosign-border rounded-card px-4 py-2 text-body font-medium text-gosign-dark">TOTVS</span><span class="bg-gosign-light border border-gosign-border rounded-card px-4 py-2 text-body font-medium text-gosign-dark">SAP S/4HANA</span><span class="bg-gosign-light border border-gosign-border rounded-card px-4 py-2 text-body font-medium text-gosign-dark">SharePoint</span><span class="bg-gosign-light border border-gosign-border rounded-card px-4 py-2 text-body font-medium text-gosign-dark">Microsoft Teams</span><span class="bg-gosign-light border border-gosign-border rounded-card px-4 py-2 text-body font-medium text-gosign-dark">REST/SOAP</span></div></div></div></section>

<div class="not-prose my-6 p-4 border-l-4 border-gosign-accent bg-gosign-light">
<p class="text-body font-semibold text-gosign-dark">Sigilo profissional (§203 StGB (sigilo profissional alemão - §203 StGB) - Código Penal alemão)</p>
<p class="text-body text-gosign-text mt-1">Todos os dados de clientes permanecem sob o controle do titular do sigilo profissional. Arquitetura conforme com §203, sem dependência de SaaS. Infraestrutura exclusivamente na UE como prova técnica.</p>
</div>

<!-- Públicos-alvo -->
<section class="py-section bg-gosign-light"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><h2 class="text-h1 font-bold text-gosign-dark mb-8">Públicos-alvo</h2><div class="grid grid-cols-1 md:grid-cols-3 gap-6"><div class="border border-gosign-border rounded-card p-6 bg-gosign-white"><h3 class="text-h3 font-bold text-gosign-dark">Firmas de auditoria e consultorias tributárias</h3><p class="text-body text-gosign-text-light mt-2">Centenas de clientes, milhares de documentos por mês. O Finance Agent traz consistência ao processamento em todos os mandatos.</p></div><div class="border border-gosign-border rounded-card p-6 bg-gosign-white"><h3 class="text-h3 font-bold text-gosign-dark">Centros de serviços compartilhados</h3><p class="text-body text-gosign-text-light mt-2">Múltiplas entidades, diferentes países, diferentes conjuntos de regras. O Finance Agent aplica regras específicas por mandato de forma consistente.</p></div><div class="border border-gosign-border rounded-card p-6 bg-gosign-white"><h3 class="text-h3 font-bold text-gosign-dark">Empresas com contabilidade própria</h3><p class="text-body text-gosign-text-light mt-2">Fechamentos mensais, relatórios trimestrais, fiscalizações tributárias. Menos correções contábeis, classificação consistente, documentação completa.</p></div></div></div></section>

<!-- Process -->
<section class="py-section bg-gosign-dark text-white"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><h2 class="text-h1 font-bold">Do primeiro agent à plataforma Finance</h2><div class="grid md:grid-cols-3 gap-8 mt-8"><div><p class="text-xs font-bold uppercase tracking-wider text-gosign-accent-on-dark">Discover - 1 semana</p><p class="text-body-lg text-gosign-text-on-dark/80 mt-2">Análise de processos com sua equipe financeira. Mapeamento de lógica contábil, documentação de conjuntos de regras. Priorização de casos de uso.</p></div><div><p class="text-xs font-bold uppercase tracking-wider text-gosign-accent-on-dark">Build - 3-4 semanas</p><p class="text-body-lg text-gosign-text-on-dark/80 mt-2">PoC em produção. Um agent, um processo financeiro, ao vivo na sua infraestrutura. Decision Layer, governance, trilha de auditoria - desde o primeiro dia.</p></div><div><p class="text-xs font-bold uppercase tracking-wider text-gosign-accent-on-dark">Scale - Contínuo</p><p class="text-body-lg text-gosign-text-on-dark/80 mt-2">Mais agents para mais processos financeiros. Correções, notas de despesas, avaliações fiscais, intercompany.</p></div></div><p class="text-body text-gosign-text-on-dark/60 mt-6 italic">Após 12-18 meses, você opera seus Finance Agents de forma independente.</p></div></section>

<!-- Business Impact -->
<section class="py-section bg-gosign-light"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow"><h2 class="text-h1 font-bold text-gosign-dark">Business Impact</h2><p class="text-body-lg font-semibold text-gosign-dark mt-4">Resultados mensuráveis em processos financeiros.</p><ul class="mt-4 space-y-3 text-body-lg text-gosign-text-light list-none"><li>Correções contábeis preventivamente eliminadas</li><li>Lógica de decisão auditável para auditoria externa e revisão interna</li><li>Lógica contábil consistente em todas as localidades e entidades</li><li>Risco tributário e de compliance reduzido</li><li>Escalabilidade sem perda de conhecimento por rotação</li><li>Cert-Ready by Design - estruturalmente pronto para auditoria</li><li>Redução do esforço de auditoria mediante atas de decisão completas por documento</li><li>Menos ciclos de conciliação interna mediante aplicação consistente de regras</li><li>Fechamentos mensais mais rápidos mediante processamento autônomo de rotina</li></ul></div></div></section>

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Finance Agent Readiness Assessment</p>
<p class="text-body text-gosign-text mb-4">7 perguntas, 3 minutos: Quão preparada está sua organização financeira para AI Agents?</p>
<a href="/br/finance-agent-readiness/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Iniciar assessment &rarr;</a>
</div>

<!-- Finance Agent Assessment -->
<section class="py-section bg-gosign-dark text-white"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow">
<h2 class="text-h1 font-bold">Finance Agent Assessment: 49 agentes avaliados e priorizados</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4">Quais agentes financeiros existem, que governance precisam e por onde começar? O assessment avalia 49 agentes em 6 dimensões - do nível de autonomia à relevância para auditoria - para que você possa priorizar com segurança.</p>
<a href="/br/catalogo-agentes-finance/" class="inline-flex items-center gap-2 mt-4 text-body font-semibold text-gosign-accent-on-dark hover:underline">Ir ao Finance Agent Assessment &rarr;</a>
</div></div></section>

<!-- Aprofundamento -->
<section class="py-section bg-gosign-white"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><h2 class="text-h2 font-bold text-gosign-dark mb-2">Aprofundamento no Agent Briefing</h2><p class="text-body text-gosign-text-light mb-6">Nossa série de artigos para decisores que automatizam processos financeiros com AI Agents.</p><div class="grid grid-cols-1 sm:grid-cols-3 gap-6"><a href="/br/revista/custos-ia-tco-comparacao/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors"><p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Finance</p><p class="text-body font-semibold text-gosign-dark">Custos de IA comparados: Análise TCO para Enterprise</p></a><a href="/br/revista/decision-layer-shadow-ai/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors"><p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p><p class="text-body font-semibold text-gosign-dark">Decision Layer vs. Shadow AI: Por que Governance vem antes da velocidade</p></a><a href="/br/revista/deepseek-enterprise-hosting/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors"><p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p><p class="text-body font-semibold text-gosign-dark">Hosting AI: EU SaaS, data center alemão ou Self-Hosted?</p></a></div></div></section>

--- Glossário - Termos Enterprise AI ---
> Termos técnicos do mundo Enterprise AI. De Agent a Zero-Trust - claramente definidos, consistentemente utilizados.

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 prose prose-lg">

## Tipos de Agents

### Document Agent

Um AI Agent especializado que lê, compreende e processa documentos. Sem reconhecimento de templates, sem OCR rígido - compreensão linguística contextual. Document Agents processam notas fiscais, atestados médicos, contratos, certificados. Cada decisão é documentada via o Decision Layer.

> [Document Agents em detalhe](/br/servicos/ai-agents/document-agents/)

### Workflow Agent

Um AI Agent que orquestra processos de negócio entre sistemas. Da recepção de correio à aprovação e lançamento contábil. Cada passo é protocolado. Diante de consultas ou informações faltantes, o workflow pausa - não interrompe.

> [Workflow Agents em detalhe](/br/servicos/ai-agents/workflow-agents/)

### Knowledge Agent

Um AI Agent que fornece respostas contextuais do conhecimento corporativo. Regulamentos internos, políticas, acordos coletivos. Cada resposta inclui fonte e versão da regra. Sem fonte não há resposta.

> [Knowledge Agents em detalhe](/br/servicos/ai-agents/knowledge-agents/)

---

## Conceitos de Governance

### Decision Layer

O Decision Layer decompõe cada processo de negócio em passos de decisão individuais e define antecipadamente para cada um: Decide uma pessoa, um conjunto de regras ou a IA de forma autônoma? Onde há margem de discricionariedade ou risco de discriminação, a arquitetura impõe a revisão humana. Onde a decisão é determinística, o agente aplica o conjunto de regras de forma consistente. E onde o agente está confiante o suficiente e tem permissão: decide de forma autônoma - interpreta documentos, classifica situações, avalia contexto. Isso não é if-then-else - é capacidade de julgamento dentro de limites definidos.

> [Decision Layer em detalhe](/br/decision-layer/)

### Human-in-the-Loop

Princípio arquitetônico que garante que humanos mantêm controle sobre decisões críticas. Não um botão de emergência, mas um elemento estrutural do Decision Layer.

### Governance by Design

Compliance, auditabilidade e supervisão humana integradas na arquitetura desde o primeiro dia. Não um projeto posterior, mas um princípio de design.

### Cert-Ready by Design

Controles como objetos de dados técnicos com geração automática de evidências. A arquitetura é projetada para que certificações (ISO 27001, SOC 2, EU AI Act) possam ser realizadas sem projeto adicional.

### Audit Trail

Protocolo completo de todas as decisões do agent. Cada decisão, cada regra, cada escalação documentada, versionada e exportável.

---

## Infraestrutura

### RAG (Retrieval-Augmented Generation)

Método que combina recuperação de informação com geração de texto. O agent pesquisa na base de conhecimento e gera uma resposta baseada nos documentos encontrados - com referência de fonte.

### Shadow IT

Ferramentas de IA não autorizadas utilizadas por funcionários sem conhecimento da TI. Risco: sem governance, sem auditabilidade, possíveis violações da LGPD. Gosign substitui Shadow IT por infraestrutura de agents controlada.

</div>
</section>

--- Cert-Ready by Design ---
> Controles como objetos de dados de primeira classe. Geração automática de evidências. Portal de Auditor em tempo real. Estruturalmente preparado para auditoria.

<!-- Definition -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">O Princípio</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Em abordagens tradicionais de conformidade, os controles são descritos em documentos, as evidências são coletadas manualmente e as auditorias são realizadas como projetos periódicos.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Cert-Ready by Design inverte isso: os controles são objetos de dados técnicos no sistema. As evidências são geradas automaticamente. O auditor vê o status em tempo real - não um instantâneo da semana passada.
</p>
</div>
</section>

<!-- 3 Differentiators -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">Três Diferenciadores</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Os Controles Vivem no Sistema</h3>
<p class="text-body text-gosign-text-light mt-2">Não no Confluence. Não em um documento Word. São objetos de dados no banco de dados - em tempo real, versionados, testáveis.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">As Evidências São Geradas Automaticamente</h3>
<p class="text-body text-gosign-text-light mt-2">Nenhuma pessoa coleta evidências. Se um controle não pode gerar sua evidência, isso é um achado.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Drill-Down Completo</h3>
<p class="text-body text-gosign-text-light mt-2">Do semáforo no dashboard até a política RLS concreta com o SQL de teste que verifica sua efetividade.</p>
</div>
</div>
</div>
</section>

<!-- Control Object Anatomy -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Controles como Objetos de Dados de Primeira Classe</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Cada controle na arquitetura da Gosign é um objeto de dados com quatro propriedades:
</p>

<div class="mt-8 space-y-6">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">1. Implementação Técnica</h3>
<p class="text-body text-gosign-text-light mt-2">
O controle não está apenas documentado - está implementado. A implementação é a verdade - não um documento que afirma que a implementação existe.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">2. Gerador Automático de Evidências</h3>
<p class="text-body text-gosign-text-light mt-2">
Cada controle tem um gerador de evidências atribuído que se executa periodicamente ou por eventos. Nenhuma pessoa coleta capturas de tela. O sistema gera suas próprias evidências.
</p>
<p class="text-body text-gosign-text-light mt-4">
A menor unidade de evidência é o <a href="/br/revista/ato-de-decisao-decisoes-ia-contestaveis/" class="text-gosign-accent-text hover:underline">ato de decisão</a> por microdecisão: um registro imutável com entrada, regra de negócio aplicada com versão, confiança, versão do modelo, resultado, carimbo de tempo e caminho de contestação - a base sobre a qual os controles se apoiam, e o que torna a revisão da decisão individual possível de cumprir e comprovar nos termos da LGPD art. 20 (e do art. 86 do EU AI Act em negócios na UE).
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">3. Histórico de Evidências</h3>
<p class="text-body text-gosign-text-light mt-2">
Cada registro de evidência é armazenado com: timestamp, status (aprovado, falho, aviso), versão do controle, versão da lógica de teste e dados brutos para drill-down. O histórico é imutável.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">4. Visão de Auditor com Drill-Down</h3>
<p class="text-body text-gosign-text-light mt-2">
O auditor vê no Portal de Auditor: status semáforo por controle, último timestamp de evidência, tendência no tempo, drill-down desde o indicador até a política RLS concreta e o SQL de teste.
</p>
</div>
</div>
</div>
</div>
</section>

<!-- Estrutura do Control Object -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Cert-Ready Control Object - Estrutura</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Cada controle é um objeto de dados estruturado com mapeamento de frameworks, implementação técnica, gerador automático de evidências e visão de auditor.
</p>
</div>
<div class="mt-8">
<pre class="bg-gosign-dark text-white p-6 rounded-card overflow-x-auto text-small font-mono leading-relaxed"><code>Control Object {
id:                 "ctrl-rbac-001"
name:               "Tenant isolation at database level"
category:           "Access Control"

implementation: {
type:             "RLS Policy"
reference:        "policies/tenant_isolation.sql"
deployed:         true
last_verified:    "2026-02-20T09:14:00Z"
}

evidence_generator: {
type:             "automated_test"
schedule:         "every_6h"
test_reference:   "tests/tenant_isolation_test.sql"
}

evidence_history: [
{
timestamp:      "2026-02-20T09:14:00Z"
status:         "passed"
control_version: "1.3"
test_version:   "2.1"
raw_data:       { ... }
},
...
]

framework_mapping: {
iso_27001:        "A.9.4.1"
soc2:             "CC6.1"
eu_ai_act:        "Art. 12"
}

owner:              "security-team"
last_change:        "2026-02-18T14:22:00Z"
change_reason:      "Policy update for new entity"
}</code></pre>
</div>
</div>
</section>

<!-- Auditor Portal -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Portal de Auditor</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Auditores externos recebem acesso direto a todos os dados de governança pelo Portal de Auditor. Sem apresentações preparadas, sem exportações filtradas. O auditor vê o estado real e atual do sistema.
</p>
</div>
<div class="mt-8 grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-3 gap-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Dashboard</h3>
<p class="text-body text-gosign-text-light mt-2">Visão geral de todos os controles com status semáforo.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Detalhe do Controle</h3>
<p class="text-body text-gosign-text-light mt-2">Descrição, implementação técnica, histórico de evidências.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Drill-Down</h3>
<p class="text-body text-gosign-text-light mt-2">Da visão geral até o resultado concreto do teste.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Exportação</h3>
<p class="text-body text-gosign-text-light mt-2">Pacotes de evidência em JSON ou PDF.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Histórico de Alterações</h3>
<p class="text-body text-gosign-text-light mt-2">Quando, por quem, por quê.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Histórico de Overrides</h3>
<p class="text-body text-gosign-text-light mt-2">Quando um override humano anulou uma decisão do agente.</p>
</div>
</div>
</div>
</section>

<!-- Framework Mapping -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Mapeamento de Frameworks</h2>
<p class="text-body-lg font-semibold text-gosign-dark mt-4">Estruturalmente preparado para qualquer framework.</p>
<ul class="mt-4 space-y-2 text-body-lg text-gosign-text-light">
<li>ISO 27001: Controles mapeados para medidas do Anexo A. Evidências geradas automaticamente.</li>
<li>SOC2: Trust Service Criteria (CC6, CC7, CC8) como categorias de controle.</li>
<li>PS 951: Padrão de auditoria para provedores de TI. Controles e evidências preparados para auditores.</li>
<li>EU AI Act: Artigos 9, 12, 13, 14, 15 e 51 implementados como controles no sistema.</li>
<li>O mapeamento muda. A estrutura permanece idêntica.</li>
</ul>
</div>
</div>
</section>

<!-- What it's not -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">O Que Cert-Ready by Design Não É</h2>
<div class="mt-6 space-y-4">
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Não é uma promessa de certificação.</strong> Significa que a arquitetura está estruturalmente preparada para ser auditada e certificada a qualquer momento.</p>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Não é uma ferramenta GRC.</strong> Complementa plataformas GRC existentes.</p>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Não é uma auditoria única.</strong> É contínuo. O sistema está sempre em modo de auditoria.</p>
</div>
</div>
</div>
</section>

<!-- Aprofundamento -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Aprofundamento no Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nossa série de artigos para executivos que implementam agentes de IA na empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/br/revista/cert-ready-by-design/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Cert-Ready by Design - IA pronta para auditoria desde o início</p>
</a>
<a href="/br/revista/eu-ai-act-hr/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">EU AI Act e RH - O que agora é obrigatório</p>
</a>
<a href="/br/revista/ia-governance-dashboard/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">IA Governance Dashboard: monitoramento de agentes</p>
</a>
</div>
</div>
</section>

--- Checklist do contrato de operador para infraestrutura IA ---
> Catálogo de requisitos para contratos de processamento de dados em IA empresarial. 25 perguntas de verificação para jurídico, segurança de TI e compliance.

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-body-lg text-gosign-text-light">
Um contrato de operador de dados para infraestrutura de IA deve cobrir dez áreas que contratos SaaS padrão não regulam: políticas de registro de prompts, separação de ambientes (dev/staging/produção), cadeias de provedores de modelos, processamento de dados in-flight vs. at-rest, proteção de dados de embeddings RAG, <a href="/br/governance/data-residency/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">acesso de terceiros países a dados de produção</a>, conformidade com sigilo profissional, tokenização PII, trilhas de auditoria do Decision Layer e verificabilidade de medidas técnicas. Este checklist traduz as dez lacunas em 25 perguntas concretas de verificação.
</p>
<p class="text-body text-gosign-text-light mt-4">
A análise detalhada das dez lacunas está disponível no artigo: <a href="/br/revista/contrato-dpo-ia-checklist/" class="text-gosign-accent-text hover:underline">Contrato de operador IA: O que falta no seu contrato padrão</a>.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">A - Categorias de dados e finalidades de tratamento</h2>
<div class="space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">1</p>
<p class="text-body-lg text-gosign-text-light mt-1">Os conteúdos de prompts e respostas do modelo estão listados como categorias de dados independentes no contrato?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">2</p>
<p class="text-body-lg text-gosign-text-light mt-1">Está estabelecido que a responsabilidade pela classificação do conteúdo recai sobre a organização, não sobre o provedor?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">3</p>
<p class="text-body-lg text-gosign-text-light mt-1">Os embeddings/vetores estão classificados como dados potencialmente pessoais?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">4</p>
<p class="text-body-lg text-gosign-text-light mt-1">O contrato contempla categorias especiais de dados sensíveis que podem surgir por entradas de usuários?</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">B - Registro e monitoramento</h2>
<div class="space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">5</p>
<p class="text-body-lg text-gosign-text-light mt-1">O registro de corpos de requisição/resposta no ambiente de produção está desativado?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">6</p>
<p class="text-body-lg text-gosign-text-light mt-1">Quais metadados são registrados (códigos de status, latências, IDs de requisição)?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">7</p>
<p class="text-body-lg text-gosign-text-light mt-1">O registro de depuração em produção está verificavelmente desativado?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">8</p>
<p class="text-body-lg text-gosign-text-light mt-1">Os rastreamentos de pilha e mensagens de erro estão configurados para excluir dados de conteúdo dos logs?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">9</p>
<p class="text-body-lg text-gosign-text-light mt-1">A verificação das configurações de registro é parte do processo de lançamento?</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">C - Separação de ambientes e acesso</h2>
<div class="space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">10</p>
<p class="text-body-lg text-gosign-text-light mt-1">Existem ambientes separados (dev, staging, produção) com políticas de dados distintas?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">11</p>
<p class="text-body-lg text-gosign-text-light mt-1">Os ambientes dev/staging contêm exclusivamente dados sintéticos ou anonimizados?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">12</p>
<p class="text-body-lg text-gosign-text-light mt-1">O acesso à produção está restrito a funções autorizadas em jurisdição adequada conforme Art. 33 LGPD (PT: RGPD)? (Veja também: <a href="/br/governance/cert-ready/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">requisitos Cert-Ready</a>)</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">13</p>
<p class="text-body-lg text-gosign-text-light mt-1">Existe um procedimento de exceção documentado para casos de suporte com acesso a dados?</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">D - Provedores de modelos e sub-operadores</h2>
<div class="space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">14</p>
<p class="text-body-lg text-gosign-text-light mt-1">A delimitação está clara: Quais provedores são sub-operadores do provedor e quais operam no tenant da organização?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">15</p>
<p class="text-body-lg text-gosign-text-light mt-1">A retenção de conteúdo nos provedores de modelos está desativada?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">16</p>
<p class="text-body-lg text-gosign-text-light mt-1">A exclusão do uso para treinamento está documentada contratualmente?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">17</p>
<p class="text-body-lg text-gosign-text-light mt-1">Onde estão localizados os endpoints dos modelos (região UE, US, outros)?</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">E - Armazenamento e exclusão de dados</h2>
<div class="space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">18</p>
<p class="text-body-lg text-gosign-text-light mt-1">Está estabelecido onde os dados de conteúdo persistentes são armazenados (banco de dados, região, provedor)?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">19</p>
<p class="text-body-lg text-gosign-text-light mt-1">Qual retenção de backup se aplica e como os dados excluídos são tratados nos backups?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">20</p>
<p class="text-body-lg text-gosign-text-light mt-1">O usuário individual pode excluir seus próprios dados dentro da aplicação?</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">F - Setores regulados</h2>
<div class="space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">21</p>
<p class="text-body-lg text-gosign-text-light mt-1">O contrato contém disposições de conformidade com sigilo profissional conforme legislação setorial brasileira?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">22</p>
<p class="text-body-lg text-gosign-text-light mt-1">Existem compromissos de confidencialidade para todas as pessoas com acesso?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">23</p>
<p class="text-body-lg text-gosign-text-light mt-1">A tokenização PII está disponível como módulo opcional?</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">G - <a href="/br/governance/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Governança</a> e verificabilidade</h2>
<div class="space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">24</p>
<p class="text-body-lg text-gosign-text-light mt-1">Uma trilha de auditoria para decisões de agentes está ancorada como componente contratual?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">25</p>
<p class="text-body-lg text-gosign-text-light mt-1">As medidas técnicas e organizacionais podem ser evidenciadas sob solicitação (documentação de configuração, extratos de logs anonimizados)?</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-body text-gosign-text-light">
Este checklist é um catálogo de requisitos da perspectiva de arquitetura e governança. Não constitui assessoria jurídica. A análise legal e a avaliação formal do contrato são responsabilidade do departamento jurídico do controlador ou de consultores externos.
</p>
</div>
</section>

--- Participação dos Trabalhadores e Governança de IA ---
> AI Agents compatíveis com a legislação trabalhista. Human-in-the-Loop, acordos coletivos como restrições do sistema, Audit Trail.

<!-- Why it matters -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Por Que Participação dos Trabalhadores É um Tema de Arquitetura</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
AI Agents implantados em processos de RH, decisões de pessoal ou fluxos que afetam funcionários estão sujeitos a direitos de participação dos trabalhadores. No Brasil, a CLT (PT: Código do Trabalho) e a legislação sindical garantem direitos de negociação coletiva e participação dos trabalhadores. Em Portugal, o Código do Trabalho assegura direitos de informação e consulta da Comissão de Trabalhadores. Não é uma camada opcional - é um requisito legal.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
A Gosign trata a participação dos trabalhadores como princípio arquitetônico. O Decision Layer impõe tecnicamente o cumprimento dos acordos coletivos. O Audit Trail documenta cada decisão. A representação dos trabalhadores pode rastrear o que o agente faz, por que faz e quando um humano intervém.
</p>
</div>
</section>

<!-- Legal Framework -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Marco Legal</h2>
<div class="mt-6 space-y-6">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">CLT (PT: Código do Trabalho) - Direitos de informação e participação</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
<strong>Brasil:</strong> A CLT e a legislação sindical garantem aos trabalhadores o direito à negociação coletiva sobre condições de trabalho, incluindo a introdução de novas tecnologias. A CIPA (PT: Comissão de Trabalhadores) atua na proteção da saúde e segurança do trabalhador, incluindo aspectos ergonômicos e organizacionais. Sindicatos negociam acordos coletivos que podem regulamentar o uso de IA no ambiente de trabalho.
</p>
<p class="text-body-lg text-gosign-text-light mt-2">
<strong>Portugal:</strong> O Código do Trabalho (art. 425 e seguintes) garante à Comissão de Trabalhadores direitos de informação e consulta sobre introdução de novas tecnologias e sistemas de monitoramento. A Diretiva 2002/14/CE reforça esses direitos a nível europeu.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Planejamento de mudanças tecnológicas</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
<strong>Brasil:</strong> A introdução de sistemas de IA que afetam condições de trabalho deve ser objeto de negociação coletiva. Acordos e convenções coletivas podem estabelecer regras específicas para o uso de AI Agents.
</p>
<p class="text-body-lg text-gosign-text-light mt-2">
<strong>Portugal:</strong> A Comissão de Trabalhadores deve ser consultada previamente sobre a introdução de novos sistemas técnicos. Isto aplica-se à fase de planeamento dos AI Agents, não apenas ao momento de lançamento. A Lei da IA da UE (EU AI Act) aplica-se em Portugal como legislação europeia, acrescentando requisitos adicionais de transparência e supervisão humana para sistemas de IA de alto risco no ambiente de trabalho. No Brasil, o EU AI Act não se aplica diretamente, mas projetos de lei nacionais sobre regulação de IA estão em tramitação.
</p>
</div>
</div>
</div>
</section>

<!-- Architectural Implementation -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Implementação Arquitetônica</h2>
</div>
<div class="mt-8">
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Acordos Coletivos como Restrições do Sistema</h3>
<p class="text-body text-gosign-text-light mt-2">Acordos coletivos e convenções são mapeados como restrições explícitas no Decision Layer. Cada restrição tem ID de versão, data de validade e escopo. Se um acordo seria violado, a decisão não é executada autonomamente.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Human-in-the-Loop Arquitetônico</h3>
<p class="text-body text-gosign-text-light mt-2">Decisão autônoma quando: alta confiança E baixo risco E nenhuma restrição de acordo afetada. Human-in-the-Loop quando: risco de viés, potencial de discriminação, temas que exigem consulta à representação dos trabalhadores. O roteamento é imposto arquitetonicamente.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">RBAC Baseado em Funções</h3>
<p class="text-body text-gosign-text-light mt-2">Operador do Agente, Especialista RH, Representação dos Trabalhadores (sindicatos/CRE; PT: Comissão de Trabalhadores), Auditor, Admin - cada um com permissões específicas. RBAC imposto a nível de banco de dados via Row-Level Security.</p>
</div>
</div>
</div>
</div>
</section>

<!-- Audit Trail Example -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Audit Trail para a Representação dos Trabalhadores</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Cada decisão do agente é documentada em um Audit Trail imutável. A representação dos trabalhadores pode verificar cada decisão.
</p>
</div>
<div class="mt-8">
<pre class="bg-gosign-dark text-white p-6 rounded-card overflow-x-auto text-small font-mono leading-relaxed"><code>Entrada Audit Trail:
├── Timestamp:          2026-02-20T09:14:22Z
├── Agente:             hr-merit-cycle-agent
├── Entrada:            Ajuste salarial funcionário #4711
├── Regras aplicadas:
│   ├── Conv. coletivo:  ACT Setor, Versão 2025.2
│   ├── Acordo coletivo: AC-2024-003, cl. 4.2
│   └── Faixa salarial:  Faixa E3, 52.000-68.000 BRL
├── Avaliação:
│   ├── Confiança:      0.94
│   ├── Risco:          baixo
│   └── Resultado:      Dentro da faixa e restrição
├── Rota de decisão:    autônoma
├── Saída:              Proposta: ajuste +3,2%
└── Status:             aprovado</code></pre>
</div>
</div>
</section>

<!-- Templates -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Templates e Documentação</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Templates para: acordo coletivo para implantação de IA, descrição técnica para a representação dos trabalhadores, conceito de logging e matriz de escalação. São pontos de partida - cada acordo deve ser negociado individualmente.
</p>
</div>
</section>

<!-- What we don't do -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">O Que Não Fazemos</h2>
<p class="text-body-lg font-semibold text-gosign-dark mt-4">Participação dos trabalhadores para AI Agents é um tema de arquitetura.</p>
<ul class="mt-4 space-y-2 text-body-lg text-gosign-text-light">
<li>Não substituímos acordos coletivos. Mapeamos tecnicamente.</li>
<li>Não fornecemos assessoria jurídica. Entregamos a infraestrutura técnica.</li>
<li>Não automatizamos decisões sujeitas à participação dos trabalhadores sem Human-in-the-Loop.</li>
<li>A arquitetura da Gosign assegura tecnicamente que acordos coletivos sejam respeitados e que Human-in-the-Loop seja imposto onde necessário.</li>
</ul>
</div>
</div>
</section>

<!-- Aprofundamento -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Aprofundamento no Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nossa série de artigos para executivos que implementam agentes de IA na empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/br/revista/comite-empresa-ia-codecisao/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Comitê de Empresa e IA, Participação dos Trabalhadores como Constraint Arquitetônico</p>
</a>
<a href="/br/revista/agent-governance-hr/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Agent Governance no RH - Por que o CHRO precisa liderar</p>
</a>
<a href="/br/revista/human-in-the-loop-arquitetura/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Human-in-the-Loop - Princípio arquitetônico, não checkbox</p>
</a>
</div>
</div>
</section>

--- Residência de Dados e LGPD/RGPD ---
> Soberania de dados para AI Agents empresariais. Processamento no Brasil ou na UE, Row-Level Security, isolamento de inquilinos, sem fluxos de dados a terceiros.

<!-- Princípio Fundamental -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Princípio Fundamental</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
AI Agents processam dados críticos de negócio: dados de pessoal, dados financeiros, dados contratuais. A questão de onde esses dados são processados e quem tem acesso não é negociável. O <a href="/br/decision-layer/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Decision Layer</a> decompõe cada processo em etapas de decisão e define para cada etapa se o ser humano, um conjunto de regras ou a IA decide - incluindo a questão de quais dados podem ser processados.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
A arquitetura da Gosign se baseia em um princípio: todos os dados permanecem na infraestrutura do cliente. A Gosign não opera nuvem própria, não armazena dados de clientes e não tem acesso permanente a sistemas de produção. A <a href="/br/governance/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">arquitetura de governança</a> completa garante que todo processamento de dados seja documentado e rastreável.
</p>
</div>
</div>
</section>

<!-- Opções de Implantação -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Opções de Implantação</h2>
<p class="text-body-lg text-gosign-text-light mb-4">
Cada provedor oferece regiões no Brasil e na UE. O cliente escolhe a região conforme seus requisitos regulatórios - LGPD (PT: RGPD), localização dos usuários e políticas internas. Nem todas as opções são necessárias: a maioria dos projetos começa com um único provedor e uma única região. A arquitetura permite expandir para outras regiões ou provedores sem alterar a lógica de negócio.
</p>
<div class="grid grid-cols-1 md:grid-cols-2 gap-6 lg:gap-8">
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 15a4.5 4.5 0 0 0 4.5 4.5H18a3.75 3.75 0 0 0 .75-7.425A4.502 4.502 0 0 0 14.25 7.5a5.25 5.25 0 0 0-10.233 2.033A4.5 4.5 0 0 0 2.25 15Z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Azure</h3>
<p class="text-body text-gosign-text-light mt-3">
Regiões <a href="https://azure.microsoft.com/en-us/explore/global-infrastructure/geographies/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Azure</a> disponíveis: Brazil South (São Paulo), Brazil Southeast (Rio de Janeiro), West Europe (Amsterdã), North Europe (Dublin), Germany West Central (Frankfurt). Azure OpenAI para processamento LLM. DPA da Microsoft.
</p>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">GCP</h3>
<p class="text-body text-gosign-text-light mt-3">
Regiões <a href="https://cloud.google.com/about/locations" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">GCP</a> disponíveis: southamerica-east1 (São Paulo), europe-west1 (Bélgica), europe-west3 (Frankfurt), europe-west4 (Países Baixos). Vertex AI para processamento LLM. DPA do Google.
</p>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M5.25 14.25h13.5m-13.5 0a3 3 0 0 1-3-3m3 3a3 3 0 1 0 0 6h13.5a3 3 0 1 0 0-6m-16.5-3a3 3 0 0 1 3-3h13.5a3 3 0 0 1 3 3m-19.5 0a4.5 4.5 0 0 1 .9-2.7L5.737 5.1a3.375 3.375 0 0 1 2.7-1.35h7.126c1.062 0 2.062.5 2.7 1.35l2.587 3.45a4.5 4.5 0 0 1 .9 2.7m0 0a3 3 0 0 1-3 3m0 3h.008v.008h-.008v-.008Zm0-6h.008v.008h-.008v-.008Zm-3 6h.008v.008h-.008v-.008Zm0-6h.008v.008h-.008v-.008Z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">AWS</h3>
<p class="text-body text-gosign-text-light mt-3">
Regiões <a href="https://aws.amazon.com/about-aws/global-infrastructure/regions_az/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">AWS</a> disponíveis: sa-east-1 (São Paulo), eu-central-1 (Frankfurt), eu-west-1 (Irlanda), eu-west-3 (Paris). Amazon Bedrock para hosting de LLM (Claude, Llama, Mistral). Amazon EKS para orquestração de contêineres, Aurora PostgreSQL. DPA da AWS.
</p>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M3.75 13.5l10.5-11.25L12 10.5h8.25L9.75 21.75 12 13.5H3.75z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Vercel + Supabase</h3>
<p class="text-body text-gosign-text-light mt-3">
Vercel para frontend e edge functions. Supabase para banco de dados (PostgreSQL), auth e storage - com região sa-east-1 (São Paulo) ou UE disponível. Opção leve sem infraestrutura Kubernetes própria. Serviços managed com data residency no Brasil ou na UE.
</p>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 17.25v1.007a3 3 0 0 1-.879 2.122L7.5 21h9l-.621-.621A3 3 0 0 1 15 18.257V17.25m6-12V15a2.25 2.25 0 0 1-2.25 2.25H5.25A2.25 2.25 0 0 1 3 15V5.25A2.25 2.25 0 0 1 5.25 3h13.5A2.25 2.25 0 0 1 21 5.25Z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Self-Hosted</h3>
<p class="text-body text-gosign-text-light mt-3">
Datacenter próprio ou servidores próprios. Modelos open-source: <a href="https://llama.meta.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Llama</a>, <a href="https://mistral.ai/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Mistral</a>, <a href="https://www.deepseek.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">DeepSeek</a> - operados localmente. Nenhum dado sai da rede corporativa. Controle total sobre hardware, software e rede.
</p>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M7.5 21 3 16.5m0 0L7.5 12M3 16.5h13.5m0-13.5L21 7.5m0 0L16.5 12M21 7.5H7.5" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Híbrido</h3>
<p class="text-body text-gosign-text-light mt-3">
Combinação de provedores e regiões. Exemplo: Self-Hosted para dados sensíveis de RH, Azure São Paulo para processamento de documentos, Supabase UE para operações em Portugal. A arquitetura suporta diferentes opções de implantação por agente.
</p>
</article>
</div>
</div>
</section>

<!-- Medidas Técnicas -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Medidas Técnicas de Proteção de Dados</h2>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">Row-Level Security (RLS)</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Isolamento de inquilinos é aplicado a nível de banco de dados - não a nível de aplicação. Uma consulta SQL só pode acessar fisicamente os registros para os quais o contexto de execução está autorizado. A separação não pode ser contornada por lógica de aplicação.
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">Criptografia</h3>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light"><strong>Em repouso:</strong> Todos os dados são armazenados criptografados (AES-256)</li>
<li class="text-body-lg text-gosign-text-light"><strong>Em trânsito:</strong> Todas as transferências de dados via TLS 1.3</li>
<li class="text-body-lg text-gosign-text-light"><strong>Gestão de chaves:</strong> Chaves próprias do cliente (Bring Your Own Key) ou gerenciadas pela plataforma</li>
</ul>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">Controle de Acesso</h3>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light">RBAC (Role-Based Access Control) em todos os níveis</li>
<li class="text-body-lg text-gosign-text-light">Sem credenciais compartilhadas, sem conta de serviço com acesso total</li>
<li class="text-body-lg text-gosign-text-light">Acessos são registrados e rastreáveis no Audit Trail</li>
<li class="text-body-lg text-gosign-text-light">Gosign sem acesso permanente a dados de produção</li>
</ul>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">Exclusão de Dados</h3>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light">Conceito de exclusão segundo LGPD (PT: RGPD) Art. 16 / RGPD Art. 17</li>
<li class="text-body-lg text-gosign-text-light">Períodos de retenção configuráveis por tipo de dado</li>
<li class="text-body-lg text-gosign-text-light">Exclusão abrange todas as cópias - banco de dados, Audit Trail, backups (após expiração da retenção de backup)</li>
<li class="text-body-lg text-gosign-text-light">Protocolos de exclusão documentados no Audit Trail</li>
</ul>
</div>
</div>
</section>

<!-- Proteção de Dados Específica para LLM -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Proteção de Dados Específica para LLM</h2>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">LLMs na Nuvem (Azure OpenAI, Vertex AI, Amazon Bedrock)</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Quando LLMs na nuvem são utilizados, os dados a serem processados são enviados ao serviço LLM. Medidas: dados não são usados para treinamento (compromisso da Microsoft/Google), DPA/SCCs com o respectivo provedor, minimização de dados. A <a href="/br/revista/pii-anonimizacao-llm-enterprise/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">anonimização de PII</a> garante que dados pessoais sejam removidos antes do processamento pelo LLM.
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">Modelos Self-Hosted (Llama, Mistral, DeepSeek)</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Com modelos self-hosted, nenhum dado sai da infraestrutura do cliente. O modelo roda localmente, o processamento ocorre em hardware próprio. Compromisso: modelos self-hosted geralmente são menos potentes que os modelos proprietários mais recentes. Mais sobre estratégias de hosting no artigo <a href="/br/revista/hosting-ia-estrategias-enterprise/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Hosting de IA: EU SaaS, data center europeu ou Self-Hosted?</a>
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">Sem Treinamento com Dados do Cliente</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
AI Agents da Gosign não são treinados com dados do cliente. Sem fine-tuning, sem re-treinamento e sem aprendizado descontrolado a partir de dados de produção.
</p>
</div>
</div>
</section>

<!-- Mapeamento LGPD/RGPD -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Mapeamento LGPD (PT: RGPD) e RGPD</h2>
<p class="text-body-lg text-gosign-text-light mb-4">
A LGPD brasileira e o RGPD europeu exigem medidas técnicas específicas. Cada componente arquitetônico atende a ambos os marcos regulatórios. Detalhes no contexto do <a href="/br/governance/eu-ai-act/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">EU AI Act</a>.
</p>
<div class="mt-8 overflow-x-auto -mx-4 sm:mx-0">
<table class="w-full text-left text-small border-collapse min-w-[50rem]">
<thead>
<tr>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Área</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">LGPD (Brasil)</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">RGPD (Portugal/UE)</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Solução Gosign</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Minimização de dados</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Art. 6, III LGPD</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Art. 5 RGPD</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Somente dados necessários são processados</td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Base legal</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Art. 7 LGPD</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Art. 6 RGPD</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Processamento por contrato (Art. 7, V) ou interesse legítimo</td>
</tr>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Exclusão de dados</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Art. 16 LGPD</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Art. 17 RGPD</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Conceito de exclusão com períodos configuráveis</td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Privacy by Design</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Art. 46 LGPD</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Art. 25 RGPD</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">RLS, criptografia, RBAC como componentes arquitetônicos</td>
</tr>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Processamento por terceiros</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Art. 39 LGPD</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Art. 28 RGPD</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">DPA entre cliente e Gosign, DPA com provedor cloud</td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Registro de operações</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Art. 37 LGPD</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Art. 30 RGPD</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Audit Trail documenta todas as operações</td>
</tr>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Segurança</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Art. 46 LGPD</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Art. 32 RGPD</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Criptografia, controle de acesso, revisão regular</td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Notificação de incidentes</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Art. 48 LGPD</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Art. 33/34 RGPD</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Processo de resposta a incidentes, Audit Trail para análise forense</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Distinção -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<p class="text-body-lg text-gosign-text-light">
Esta página descreve medidas arquitetônicas técnicas para proteção de dados e residência de dados. A avaliação legal e a declaração de conformidade com LGPD/RGPD são responsabilidade do controlador (o cliente) e seus encarregados de proteção de dados. A Gosign fornece a infraestrutura técnica. A responsabilidade legal cabe ao operador.
</p>
</div>
</div>
</section>

<!-- Aprofundamento -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Aprofundamento no Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nossa série de artigos para executivos que implementam agentes de IA na empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/br/revista/pii-anonimizacao-llm-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Segurança</p>
<p class="text-body font-semibold text-gosign-dark">Anonimização de PII para IA Empresarial</p>
</a>
<a href="/br/revista/seguranca-dados-ia-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Segurança</p>
<p class="text-body font-semibold text-gosign-dark">Segurança de dados em IA: Data Residency, LGPD e EU AI Act</p>
</a>
<a href="/br/revista/hosting-ia-estrategias-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">Hosting de IA: EU SaaS, data center europeu ou Self-Hosted?</p>
</a>
</div>
</div>
</section>

--- EU AI Act Readiness ---
> Como a arquitetura da Gosign aborda os requisitos do EU AI Act em transparência, supervisão humana, registro e gestão de riscos como princípios de design.

<!-- Intro -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">EU AI Act - Relevância para AI Agents Empresariais</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
O <a href="https://eur-lex.europa.eu/eli/reg/2024/1689/oj" target="_blank" rel="noopener noreferrer">EU AI Act (Regulamento (UE) 2024/1689)</a> regula sistemas de IA na União Europeia. Aplica-se diretamente em Portugal e nos demais estados-membros da UE; no Brasil, é relevante para empresas com operações na UE. Para AI Agents empresariais que tomam decisões automatizadas em processos críticos, quatro áreas são particularmente relevantes.
</p>
</div>
</section>

<!-- Architecture Mapping Table -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">Mapeamento Arquitetônico do EU AI Act</h2>
<div class="overflow-x-auto -mx-4 sm:mx-0">
<table class="w-full text-left text-small border-collapse min-w-[48rem]">
<thead>
<tr>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Requisito</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Artigo</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Implementação Gosign</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Transparência</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Art. 13</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Decision Layer documenta cada rota de decisão completamente: entrada, modelo e versão, avaliação, confiança, regra aplicada, decisão resultante.</td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Supervisão Humana</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Art. 14</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Human-in-the-Loop é roteamento imposto arquitetonicamente. Este roteamento não pode ser contornado. Cada override é documentado.</td>
</tr>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Obrigações de Registro</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Art. 12</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">O Audit Trail captura para cada decisão: timestamp, hash de entrada, versão do modelo, versão da regra, confiança, rota de decisão, resultado. Imutável, exportável e completo.</td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Gestão de Riscos</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Art. 9</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Monitoramento de viés, rastreamento de confiança, detecção de anomalias e controles Cert-Ready com geração automática de evidências.</td>
</tr>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Explicação da decisão individual</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Art. 86 (e LGPD art. 20)</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">O <a href="/br/revista/ato-de-decisao-decisoes-ia-contestaveis/">ato de decisão</a> é o registro atômico por microdecisão - entrada, regra com versão e fonte, confiança, resultado, caminho de contestação - que torna a decisão individual explicável e contestável caso a caso, como a LGPD art. 20 já exige hoje no Brasil.</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Four Architectural Responses -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 space-y-12">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Cinco Respostas Arquitetônicas</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Compliance não é uma verificação posterior, mas resultado da arquitetura.
</p>
</div>
<div class="max-w-narrow">
<div class="flex items-start gap-4">
<span class="text-h1 font-bold text-gosign-accent-text leading-none">1</span>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Decision Layer: Transparência e Explicabilidade</h3>
<p class="text-body-lg text-gosign-text-light mt-2">O Decision Layer documenta cada rota de decisão completamente. Para cada decisão do agente é registrado: dados de entrada, modelo utilizado, versão do modelo, pontuação de confiança, lógica de avaliação, resultado e alternativas descartadas. Esta documentação surge automaticamente como subproduto da decisão.</p>
</div>
</div>
</div>
<div class="max-w-narrow">
<div class="flex items-start gap-4">
<span class="text-h1 font-bold text-gosign-accent-text leading-none">2</span>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Human-in-the-Loop: Supervisão Humana</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Human-in-the-Loop é imposto arquitetonicamente, não configurado opcionalmente. O Decision Layer roteia decisões automaticamente com base em pontuação de confiança e categoria de risco. Em decisões de risco, um humano deve verificar e aprovar. O agente não pode contornar este passo.</p>
</div>
</div>
</div>
<div class="max-w-narrow">
<div class="flex items-start gap-4">
<span class="text-h1 font-bold text-gosign-accent-text leading-none">3</span>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Governance Layer: Gestão de Riscos e Monitoramento</h3>
<p class="text-body-lg text-gosign-text-light mt-2">O Governance Layer supervisiona todas as atividades dos agentes continuamente. Monitoramento de viés detecta distorções sistemáticas. Rastreamento de confiança identifica degradação do modelo. Detecção de anomalias reporta padrões de decisão inesperados. Controles Cert-Ready garantem que todas as evidências estejam disponíveis a qualquer momento.</p>
</div>
</div>
</div>
<div class="max-w-narrow">
<div class="flex items-start gap-4">
<span class="text-h1 font-bold text-gosign-accent-text leading-none">4</span>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Audit Trail: Obrigações de Registro</h3>
<p class="text-body-lg text-gosign-text-light mt-2">O Audit Trail captura cada decisão com timestamps, hashes de entrada, versões de modelo e rotas de decisão completas. O registro é imutável e exportável em JSON, PDF e CSV. Metadados do sistema são estruturados e podem ser exportados para a obrigação de registro segundo Art. 51.</p>
</div>
</div>
</div>
<div class="max-w-narrow">
<div class="flex items-start gap-4">
<span class="text-h1 font-bold text-gosign-accent-text leading-none">5</span>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Ato de Decisão: Explicação e Contestabilidade do Caso Individual</h3>
<p class="text-body-lg text-gosign-text-light mt-2">O artigo 86 dá ao afetado o direito a uma explicação da decisão individual - e a <a href="/br/revista/ato-de-decisao-decisoes-ia-contestaveis/">LGPD art. 20 já garante esse direito de revisão hoje no Brasil</a>. O <a href="/br/revista/ato-de-decisao-decisoes-ia-contestaveis/">ato de decisão</a> é a resposta: o registro atômico e imutável de cada microdecisão - entrada, regra de negócio com versão e fonte, confiança, versão do modelo, resultado e caminho de contestação. Logs respondem "O que aconteceu?"; o ato de decisão responde "Por que foi decidido assim?", de forma individualmente endereçável e contestável.</p>
</div>
</div>
</div>
</div>
</section>

<!-- Risk Classification -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Classificação de Risco</h2>
<div class="mt-6 space-y-4">
<p class="text-body-lg text-gosign-text-light">
<strong class="text-gosign-dark">Potencialmente Alto Risco:</strong> AI Agents que preparam ou influenciam decisões de pessoal, avaliação de crédito, acesso a serviços essenciais.
</p>
<p class="text-body-lg text-gosign-text-light">
<strong class="text-gosign-dark">Não Alto Risco (tipicamente):</strong> Document Agents que classificam documentos sem decisões de pessoal, Knowledge Agents que fornecem informação sem tomar decisões.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
A arquitetura está preparada para os requisitos mais rigorosos.
</p>
</div>
</div>
</section>

<!-- Compliance Position -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Posição de Compliance</h2>
<p class="text-body-lg font-semibold text-gosign-dark mt-4">EU AI Act compliant by design.</p>
<ul class="mt-4 space-y-2 text-body-lg text-gosign-text-light">
<li>Nossa arquitetura aborda os requisitos do EU AI Act como princípios de design.</li>
<li>Transparência, explicabilidade e supervisão humana são estruturalmente inevitáveis, não opcionalmente configuráveis.</li>
<li>Cada decisão é documentada automaticamente, não reconstruída posteriormente.</li>
<li>Cada microdecisão gera um <a href="/br/revista/ato-de-decisao-decisoes-ia-contestaveis/">ato de decisão</a> individualmente endereçável e contestável - a resposta arquitetônica ao direito de revisão da LGPD art. 20 e à explicação do caso individual do art. 86.</li>
<li>O sistema está preparado para requisitos de alto risco, independentemente da classificação concreta do caso de uso.</li>
<li>Controles Cert-Ready garantem que evidências estejam sempre disponíveis e exportáveis.</li>
</ul>
</div>
</div>
</section>

<!-- Disclaimer -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Distinção</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Esta página descreve medidas arquitetônicas, não conformidade legal. O cumprimento real depende do contexto de implantação, classificação de risco e avaliação legal caso a caso.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
A Gosign entrega a arquitetura técnica. A avaliação legal e declaração de conformidade são responsabilidade do operador e seus assessores jurídicos.
</p>
</div>
</section>

<!-- Aprofundamento -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Aprofundamento no Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nossa série de artigos para executivos que implementam agentes de IA na empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/br/revista/eu-ai-act-hr/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governança</p>
<p class="text-body font-semibold text-gosign-dark">EU AI Act e RH - O que agora é obrigatório</p>
</a>
<a href="/br/revista/eu-ai-act-hr-alto-risco/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governança</p>
<p class="text-body font-semibold text-gosign-dark">EU AI Act e RH: O que muda para IA em decisões de pessoal</p>
</a>
<a href="/br/revista/cert-ready-by-design/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governança</p>
<p class="text-body font-semibold text-gosign-dark">Cert-Ready by Design - IA pronta para auditoria desde o início</p>
</a>
</div>
</div>
</section>

--- Arquitetura de Referência: 7 Camadas para Enterprise AI ---
> Arquitetura de 7 camadas para AI Agents empresariais. Governance by Design, agnóstica de modelos e infraestrutura. Para CTOs e decisores de engenharia.

<!-- Visão Geral -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Por que sete camadas</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Um sistema de IA monolítico não é auditável, não é escalável e não é sustentável. A arquitetura de 7 camadas separa responsabilidades: cada camada tem uma função definida e interfaces claras. Uma troca de modelo não altera a lógica de negócio. Um novo sistema destino não altera o agente. Um novo requisito de compliance não altera a infraestrutura.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
A arquitetura resulta de exigências empresariais: isolamento de inquilinos, Audit Trail, transparência para sindicatos e representantes dos trabalhadores (PT: Comissão de Trabalhadores), conformidade com LGPD (PT: RGPD), deployment agnóstico de modelos. APIs padrão de LLM não entregam nada disso.
</p>
</div>
<img src="/images/diagrams/reference-architecture.svg" alt="Arquitetura de Referência: 7 camadas com Governança como componente transversal - Presentation, Orchestration, Agent, Decision Layer, Model, Integration, Infrastructure" class="w-full rounded-card mt-8" width="1200" height="600" loading="lazy" />
</div>
</section>

<!-- Layer 1: Presentation -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">1. Presentation Layer</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
A interface entre sistema e usuário. Sem lógica de negócio, sem decisões - apenas apresentação e entrada de dados.
</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light"><strong>Chat UI:</strong> Interface web para usuários finais (analistas de RH, contadores). PWA-ready, responsiva.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Dashboard:</strong> Visão geral de status dos agentes, workflows em execução, escalações abertas. Baseado em funções: analistas veem seus casos, gestores veem indicadores.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Portal de Auditor:</strong> Acesso de auditores ao Audit Trail, controles e evidências. Somente leitura. Para auditores independentes (PT: revisores oficiais de contas), sindicatos e auditoria interna.</li>
<li class="text-body-lg text-gosign-text-light"><strong>REST API:</strong> Interface legível por máquina para integração com sistemas existentes. Versionada, documentada, autenticada.</li>
</ul>
</div>
</div>
</section>

<!-- Layer 2: Orchestration -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">2. Orchestration Layer</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Coordena o fluxo de dados entre agentes, sistemas e usuários. Gerencia workflows, filas e roteamento de APIs.
</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light"><strong>Motor de Workflow:</strong> Engines open-source (Trigger.dev, Camunda) para processos complexos e multietapa. Workflows visuais, integração via API, webhooks.</li>
<li class="text-body-lg text-gosign-text-light"><strong>API Gateway:</strong> Ponto de entrada unificado com rate limiting, autenticação, logging, monitoramento.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Sistema de Filas:</strong> Processamento assíncrono para processos em lote (fechamento mensal, importação em massa).</li>
<li class="text-body-lg text-gosign-text-light"><strong>Sistema de Eventos:</strong> Reação em tempo real a documentos recebidos, mudanças de status, escalações.</li>
</ul>
</div>
</div>
</section>

<!-- Layer 3: Agent -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">3. Agent Layer</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
AI Agents especializados que executam tarefas de domínio. Cada agente tem um escopo definido e opera dentro dos limites estabelecidos pelo Decision Layer.
</p>
<h3 class="text-h3 font-bold text-gosign-dark mt-8"><a href="/br/servicos/ai-agents/document-agents/" class="text-gosign-dark hover:text-gosign-accent-text transition-colors">Document Agents</a></h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Leem, compreendem e processam documentos com compreensão linguística real. Notas fiscais, atestados médicos, contratos, certidões, comprovantes. Não é correspondência de templates, não são regras rígidas - é compreensão contextual.
</p>
<h3 class="text-h3 font-bold text-gosign-dark mt-8"><a href="/br/servicos/ai-agents/workflow-agents/" class="text-gosign-dark hover:text-gosign-accent-text transition-colors">Workflow Agents</a></h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Orquestram processos entre sistemas. Quando um documento precisa ser lido, uma decisão tomada e uma ação acionada em um sistema destino - o Workflow Agent coordena o fluxo.
</p>
<h3 class="text-h3 font-bold text-gosign-dark mt-8"><a href="/br/servicos/ai-agents/knowledge-agents/" class="text-gosign-dark hover:text-gosign-accent-text transition-colors">Knowledge Agents</a></h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Fornecem respostas contextuais a partir do conhecimento empresarial. Acordos coletivos (CCT/ACT; PT: contratos coletivos), políticas internas, regras de compliance. A resposta inclui a fonte e a versão da regra.
</p>
</div>
</div>
</section>

<!-- Layer 4: Decision Layer -->
<section class="py-section bg-gosign-dark text-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold"><a href="/br/decision-layer/" class="hover:text-gosign-accent-on-dark transition-colors">4. Decision Layer</a></h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4">
Decompõe cada processo de negócio em etapas de decisão individuais e define para cada etapa: humano, conjunto de regras ou IA. Cada decisão é documentada - verificável por auditores independentes (PT: revisores oficiais de contas), sindicatos e auditoria interna.
</p>
<div class="mt-6 space-y-4">
<p class="text-body-lg text-gosign-text-on-dark/80"><strong>Rules Engine:</strong> Regras de negócio versionadas e rastreáveis. Convenções coletivas (CCT), acordos coletivos (ACT), lógica contábil, regras de compliance. Cada regra tem uma versão, uma data de validade e um escopo de aplicação.</p>
<p class="text-body-lg text-gosign-text-on-dark/80"><strong>Confidence Routing:</strong> Avaliação automática da certeza da decisão. Alta confiança e baixo risco: decisão autônoma. Baixa confiança ou alto risco: escalação para humano.</p>
<p class="text-body-lg text-gosign-text-on-dark/80"><strong>Human-in-the-Loop:</strong> Revisão humana arquitetonicamente imposta em tipos de decisão definidos. Risco de viés, potencial de discriminação, questões de participação de trabalhadores.</p>
<p class="text-body-lg text-gosign-text-on-dark/80"><strong>Audit Trail - o ato de decisão:</strong> Documentação completa e imutável de cada decisão. Por microdecisão, um ato de decisão: input, modelo, avaliação, regra com versão, resultado, timestamp e caminho de contestação. Append-only - e, com isso, a resposta arquitetônica ao direito do titular de revisar a decisão individual nos termos da LGPD art. 20 (e do art. 86 do EU AI Act em negócios na UE).</p>
</div>
<p class="text-body text-gosign-text-on-dark/60 mt-4">
Aprofundar: <a href="/br/revista/decision-layer-explicado/" class="text-gosign-text-on-dark/80 underline decoration-white/20 hover:text-white transition-colors">Decision Layer em detalhe</a> · <a href="/br/revista/tres-tipos-de-decisoes/" class="text-gosign-text-on-dark/80 underline decoration-white/20 hover:text-white transition-colors">Três tipos de decisões IA</a> · <a href="/br/revista/ato-de-decisao-decisoes-ia-contestaveis/" class="text-gosign-text-on-dark/80 underline decoration-white/20 hover:text-white transition-colors">O ato de decisão</a>
</p>
</div>
</div>
</section>

<!-- Layer 5: Model -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">5. Model Layer</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
A camada LLM. Intercambiável, agnóstica de modelo, desacoplada da lógica de negócio.
</p>
<h3 class="text-h3 font-bold text-gosign-dark mt-6">Cloud-LLMs</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Claude (Anthropic), ChatGPT (OpenAI), Gemini (Google) - via regiões Brasil ou UE dos respectivos provedores de nuvem.</p>
<h3 class="text-h3 font-bold text-gosign-dark mt-6">LLMs Open-Source / Open-Weight</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Llama (Meta), Mistral, DeepSeek, <a href="https://openai.com/open-models/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">gpt-oss</a> (OpenAI, Apache 2.0) - completamente self-hostáveis em hardware próprio. gpt-oss-120B roda em uma única GPU H100, gpt-oss-20B em hardware de consumo de 16 GB.</p>
<h3 class="text-h3 font-bold text-gosign-dark mt-6">Híbrido</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Cloud-LLMs para casos padrão, Self-Hosted-LLMs para dados sensíveis. Roteamento automático conforme classificação de dados.</p>
<p class="text-body-lg text-gosign-text-light mt-4">
A escolha do modelo é uma ponderação entre desempenho, custo, proteção de dados e latência. O Model Layer é intercambiável - uma troca de modelo não altera a lógica de negócio das camadas superiores.
</p>
<p class="text-body text-gosign-text-light mt-4">
Opções concretas de hosting, requisitos de hardware e stack tecnológico: <a href="/br/servicos/infraestrutura/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">AI Infrastructure em detalhe</a>
</p>
</div>
</div>
</section>

<!-- PII Gateway: redação antes do Model Layer -->
<section id="pii-gateway" class="py-section bg-gosign-dark text-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold">O PII Gateway: redação antes do Model Layer</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4">
Entre a lógica de negócio e o Model Layer, a arquitetura prevê um gateway de redação (PII Gateway): cada chamada ao modelo - cloud ou self-hosted - passa por ele. Seu objetivo de design: dados pessoais não saem do perímetro de confiança do operador em texto em claro. Para cargas de trabalho sujeitas a sigilo profissional (advocacia, contabilidade, saúde), o gateway é um dos pilares da minimização de dados prevista na LGPD - complementa salvaguardas organizacionais e contratuais, não as substitui.
</p>
<div class="mt-6 space-y-4">
<p class="text-body-lg text-gosign-text-on-dark/80"><strong>Redação e reinserção:</strong> Antes de cada chamada ao modelo, o gateway substitui nomes, identificadores e outros atributos pessoais por marcadores (pseudonimização). O modelo trabalha exclusivamente sobre o texto redigido. Os valores originais são reinseridos após a resposta - dentro do perímetro de confiança, nunca no provedor do modelo.</p>
<p class="text-body-lg text-gosign-text-on-dark/80"><strong>Audit Trail sem texto em claro:</strong> Cada chamada ao modelo é registrada append-only e encadeada por hashes: valores de hash do prompt e da resposta bruta em vez de texto em claro, além do ID do modelo, da versão da API e da versão do conjunto de regras de redação. A evidência do que passou pelo gateway, e quando, permanece completa - sem que o próprio registro se torne um acervo de dados sensíveis.</p>
<p class="text-body-lg text-gosign-text-on-dark/80"><strong>Regras de break-glass:</strong> Acessos excepcionais para incidentes e auditorias estão previstos no design - nunca em silêncio: princípio dos quatro olhos, justificativa documentada, limite de tempo, e cada uso de break-glass fica registrado integralmente no Audit Trail.</p>
<p class="text-body-lg text-gosign-text-on-dark/80"><strong>Aprovação pelo usuário em baixa confiança:</strong> Se a confiança da redação em um trecho é baixa, a decisão vai para o usuário na interface - nunca para a equipe da Gosign. A escalação permanece na esfera em que os dados já são conhecidos.</p>
</div>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-6">
Modos de API que não podem ser redigidos - por exemplo, chamadas externas de embeddings cujos vetores não admitem pseudonimização - são bloqueados para conteúdos sujeitos a redação, em vez de repassados em silêncio. As tabelas de mapeamento entre marcadores e valores originais são efêmeras ou criptografadas por inquilino com tempo de vida definido (TTL); as chaves de provedor ficam exclusivamente no sistema de gerenciamento de chaves (KMS).
</p>
<p class="text-body text-gosign-text-on-dark/60 mt-4">
Aprofundar: <a href="/br/revista/pii-anonimizacao-llm-enterprise/" class="text-gosign-text-on-dark/80 underline decoration-white/20 hover:text-white transition-colors">Anonimização de PII para IA Empresarial</a>
</p>
</div>
</div>
</section>

<!-- Layer 6: Integration -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">6. Integration Layer</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
A conexão com sistemas empresariais existentes. O agente não substitui sistemas - ele os complementa.
</p>
<div class="mt-6 overflow-x-auto">
<table class="w-full text-left text-small border-collapse">
<thead>
<tr>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Categoria de sistema</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Integração</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">ERP / Finanças</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">SAP FI/CO, SAP S/4HANA, TOTVS, Oracle Financials</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">RH / Folha</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">SAP SuccessFactors, Workday, TOTVS RM</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Colaboração</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">SharePoint, Microsoft Teams (via Microsoft Graph)</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">DMS / ECM</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">SharePoint, d.velop, ELO, nscale</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Outros</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Qualquer sistema com interface REST ou SOAP</td></tr>
</tbody>
</table>
</div>
<p class="text-body-lg text-gosign-text-light mt-4">
A lógica do agente é desacoplada do sistema destino. Lógica contábil é separada da exportação. Se o sistema destino muda (ex.: de TOTVS para SAP), altera-se a camada de exportação - não o agente.
</p>
</div>
</div>
</section>

<!-- Layer 7: Infrastructure -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">7. Infrastructure Layer</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
O fundamento de deployment. Toda a arquitetura roda na infraestrutura do cliente - não na Gosign, não em terceiros.
</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light"><strong>Cloud (Brasil e UE):</strong> Azure, AWS ou GCP - regiões no Brasil (São Paulo) e na UE. Managed Kubernetes, Managed Databases, LLM Hosting.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Managed (Brasil ou UE):</strong> Vercel EU + Supabase (região sa-east-1 São Paulo ou UE). Opção leve sem infraestrutura Kubernetes própria.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Self-Hosted:</strong> Servidores próprios, datacenter próprio. Docker/Kubernetes, LLMs open-source em GPUs próprias. Total independência do Cloud Act.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Híbrido:</strong> Combinação conforme classificação de dados. Cargas sensíveis self-hosted, cargas padrão na nuvem.</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-4">
Todas as camadas acima da infraestrutura permanecem idênticas - independentemente do modelo de deployment.
</p>
<p class="text-body text-gosign-text-light mt-4">
Regiões de nuvem, dimensionamento de hardware, stack tecnológico: <a href="/br/servicos/infraestrutura/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">AI Infrastructure em detalhe</a>
</p>
</div>
</div>
</section>

<!-- Governança como Camada Transversal -->
<section class="py-section bg-gosign-dark text-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold">Governança como Camada Transversal</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4">
Governança não é uma camada única, mas permeia toda a arquitetura. Cada camada gera dados de governança, cada camada é controlada por regras de governança.
</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-on-dark/80"><strong>Presentation:</strong> Acesso baseado em funções, Portal de Auditor</li>
<li class="text-body-lg text-gosign-text-on-dark/80"><strong>Orchestration:</strong> Logging de workflows, documentação de escalações</li>
<li class="text-body-lg text-gosign-text-on-dark/80"><strong>Agent:</strong> Decisões de agentes geram entradas no Audit Trail</li>
<li class="text-body-lg text-gosign-text-on-dark/80"><strong>Decision Layer:</strong> Rules Engine, Confidence Routing, Human-in-the-Loop</li>
<li class="text-body-lg text-gosign-text-on-dark/80"><strong>Model:</strong> Rastreamento de versões do modelo, hashing de entradas, reprodutibilidade, redação de PII e registro sem texto em claro (PII Gateway)</li>
<li class="text-body-lg text-gosign-text-on-dark/80"><strong>Integration:</strong> Logging de interfaces, documentação de fluxos de dados</li>
<li class="text-body-lg text-gosign-text-on-dark/80"><strong>Infrastructure:</strong> Criptografia, Row-Level Security, isolamento de inquilinos</li>
</ul>
<p class="text-body text-gosign-text-on-dark/60 mt-6">
<a href="/br/governance/eu-ai-act/" class="text-gosign-text-on-dark/80 underline decoration-white/20 hover:text-white transition-colors">EU AI Act</a> · <a href="/br/governance/cert-ready/" class="text-gosign-text-on-dark/80 underline decoration-white/20 hover:text-white transition-colors">Cert-Ready by Design</a> · <a href="/br/governance/co-determination/" class="text-gosign-text-on-dark/80 underline decoration-white/20 hover:text-white transition-colors">Codeterminação</a> · <a href="/br/governance/data-residency/" class="text-gosign-text-on-dark/80 underline decoration-white/20 hover:text-white transition-colors">Data Residency</a>
</p>
</div>
</div>
</section>

<!-- Runtime e Escalabilidade -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Runtime e Escalabilidade</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Operação em produção não é retrabalho, é componente da arquitetura. A arquitetura de 7 camadas foi projetada para operação sob carga.
</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light"><strong>Orquestração de Containers:</strong> Deployment baseado em Kubernetes. Cada camada roda em seus próprios containers, escalável independentemente.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Escalabilidade Horizontal:</strong> Agent Layer e Model Layer escalam horizontalmente conforme a utilização. Um novo agente significa mais pods, não mais arquitetura.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Health Checks e Self-Healing:</strong> Liveness e Readiness Probes em todos os containers. Reinício automático em caso de falha, redirecionamento automático em caso de sobrecarga.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Monitoramento e Alertas:</strong> Métricas Prometheus em todas as camadas. Dashboards Grafana para latência, throughput, taxas de erro, profundidade de fila. Alertas ao ultrapassar limiares.</li>
<li class="text-body-lg text-gosign-text-light"><strong>CI/CD:</strong> Deployments baseados em GitOps. Infrastructure as Code (Terraform/Pulumi). Testes automatizados, deployments Blue-Green ou Canary.</li>
</ul>
</div>
</div>
</section>

<!-- Arquitetura de Dados -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Arquitetura de Dados</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Dados fluem por todas as sete camadas. A arquitetura define onde os dados são criados, como são armazenados e quem tem acesso.
</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light"><strong>Fluxo de dados:</strong> Input (documento, consulta) - Agent (análise) - Decision Layer (decisão) - Integration (exportação para sistema destino). Cada etapa gera uma entrada no Audit Trail.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Vector Store:</strong> PostgreSQL com pgvector para busca semântica (RAG). Conhecimento empresarial é armazenado como embeddings, não transmitido a serviços externos.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Isolamento de inquilinos:</strong> Row-Level Security (RLS) no nível de banco de dados. Imposto arquitetonicamente, não por lógica de aplicação. Cada inquilino é completamente isolado.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Criptografia:</strong> Em repouso (AES-256) e em trânsito (TLS 1.3). Gestão de chaves via Identity Provider do cliente ou Hardware Security Modules (HSM).</li>
<li class="text-body-lg text-gosign-text-light"><strong>Retenção de dados:</strong> Configurável conforme requisitos. Obrigações fiscais de guarda (5 anos, Código Tributário Nacional) e LGPD Art. 16 (eliminação de dados) são conciliadas via anonimização em vez de exclusão.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Backup e Recovery:</strong> Backups automatizados, Point-in-Time Recovery. Recovery Point Objective (RPO) e Recovery Time Objective (RTO) configurados por inquilino.</li>
</ul>
</div>
</div>
</section>

<!-- Arquitetura de Interfaces -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Arquitetura de Interfaces</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
A arquitetura se comunica por interfaces definidas - internamente entre camadas e externamente com sistemas de origem e destino.
</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light"><strong>REST API:</strong> APIs versionadas (v1, v2) com documentação OpenAPI. Breaking changes apenas em novas versões, versões anteriores operam em paralelo.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Event-Driven:</strong> Processamento de eventos baseado em webhooks para reações em tempo real. Documento recebido - evento - agente processa. Sem polling, sem atraso de lote.</li>
<li class="text-body-lg text-gosign-text-light"><strong>MCP (Model Context Protocol):</strong> Protocolo padronizado para integração de ferramentas em agentes LLM. Agentes acessam ferramentas externas via MCP - tipado, documentado, auditável.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Processamento em lote:</strong> Para operações em massa (fechamento mensal, cálculos anuais, importação em massa). Baseado em filas com acompanhamento de progresso e tratamento de erros.</li>
<li class="text-body-lg text-gosign-text-light"><strong>API Gateway:</strong> Ponto de entrada central. Autenticação (SSO/OIDC), rate limiting, logging de requisições, monitoramento. Desacopla a arquitetura interna dos consumidores externos.</li>
</ul>
</div>
</div>
</section>

<!-- Princípios de Design -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Princípios de Design</h2>
<div class="mt-6 space-y-4">
<p class="text-body-lg text-gosign-text-light"><strong>Agnóstico de modelos:</strong> Sem vendor lock-in a um único LLM. Modelos são intercambiáveis. Hoje Claude, amanhã gpt-oss, depois um modelo que ainda não existe.</p>
<p class="text-body-lg text-gosign-text-light"><strong>Agnóstico de infraestrutura:</strong> Mesma arquitetura em Azure, AWS, GCP, Self-Hosted ou Híbrido. A escolha da infraestrutura é uma decisão do cliente, não da arquitetura.</p>
<p class="text-body-lg text-gosign-text-light"><strong>Agnóstico de sistemas:</strong> Lógica do agente desacoplada do sistema destino. Lógica contábil separada da exportação. Uma troca de sistema altera o Integration Layer, não o agente.</p>
<p class="text-body-lg text-gosign-text-light"><strong>Governance by Design:</strong> Audit Trail, RBAC, Decision Layer e Human-in-the-Loop são componentes arquitetônicos - não funcionalidades opcionais adicionadas depois.</p>
<p class="text-body-lg text-gosign-text-light"><strong>Cert-Ready by Design:</strong> Controles são objetos de dados de primeira classe com geração automática de evidências. ISO 27001, PS 951, SOC 2 - a arquitetura fornece as evidências.</p>
<p class="text-body-lg text-gosign-text-light"><strong>Acesso ao código:</strong> Acesso completo ao código-fonte, todos os prompts e conjuntos de regras. Configurações e conjuntos de regras permanecem com o cliente. Stack open-source onde possível. Após 12-18 meses, o cliente opera os agentes de forma independente.</p>
</div>
</div>
</div>
</section>

<!-- Decision Layer - Fluxo de Decisão -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-6">Decision Layer - Fluxo de Decisão</h2>
<figure role="img" aria-label="Fluxo de decisão: Input é analisado pelo AI Agent, o Decision Layer verifica regras e confiança, roteia para decisão autônoma ou Human-in-the-Loop, documenta tudo no Audit Trail e exporta para o sistema destino.">
<pre class="bg-gosign-dark text-white p-6 rounded-card overflow-x-auto text-small font-mono leading-relaxed"><code>┌──────────┐    ┌──────────────┐    ┌────────────────┐
│  Input   │───&gt;│  AI Agent    │───&gt;│ Decision Layer │
│(documento│    │  analisa,    │    │                │
│ consulta)│    │  compreende, │    │  Verificar     │
└──────────┘    │  avalia      │    │  regras        │
└──────────────┘    │                │
│  Avaliar       │
│  confiança     │
│                │
│  Rotear        │
│  decisão       │
└───────┬────────┘
│
┌─────────────┴──────────────┐
│                            │
┌────────▼────────┐        ┌──────────▼──────────┐
│ Autônomo        │        │ Human-in-the-Loop   │
│                 │        │                     │
│ Alta confiança  │        │ Risco de viés       │
│ Baixo risco     │        │ Baixa confiança     │
│ Sem restrição   │        │ Restrição de        │
│ ativa           │        │ participação        │
└────────┬────────┘        └──────────┬──────────┘
│                            │
│         ┌──────────────┐   │
│         │  Humano      │   │
│         │  decide      │◄──┘
│         └──────┬───────┘
│                │
┌────────▼────────────────▼────────┐
│         Audit Trail              │
│  Input · Modelo · Regra ·        │
│  Avaliação · Resultado ·         │
│  Timestamp                       │
└──────────────────────────────────┘
│
┌────────▼────────┐
│ Sistema destino │
│ (ERP, RH,      │
│  Folha)        │
└─────────────────┘</code></pre>
<figcaption class="text-small text-gosign-text-light mt-3">Fluxo de decisão esquemático pelo Decision Layer. No ambiente de produção, cada etapa é documentada como entrada no Audit Trail.</figcaption>
</figure>
</div>
</section>

<!-- Aprofundamento -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Aprofundamento</h2>
<div class="mt-6 grid gap-6 sm:grid-cols-2">
<div class="border-l-4 border-gosign-dark pl-6 py-4">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Implementação</p>
<h3 class="text-h3 font-bold text-gosign-dark">AI Infrastructure</h3>
<p class="text-body text-gosign-text-light mt-2">Tecnologias concretas, regiões de nuvem, dimensionamento de hardware, tabela de stack tecnológico.</p>
<a href="/br/servicos/infraestrutura/" class="text-small font-semibold text-gosign-accent-text hover:text-gosign-accent-hover mt-3 inline-block whitespace-nowrap">Infraestrutura em detalhe &rarr;</a>
</div>
<div class="border-l-4 border-gosign-dark pl-6 py-4">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Recurso de conhecimento</p>
<h3 class="text-h3 font-bold text-gosign-dark">Blueprint 2026</h3>
<p class="text-body text-gosign-text-light mt-2">Onze artigos especializados sobre as decisões de infraestrutura que importam em 2026.</p>
<a href="/br/revista/infraestrutura-ia-blueprint-2026/" class="text-small font-semibold text-gosign-accent-text hover:text-gosign-accent-hover mt-3 inline-block whitespace-nowrap">Ver série de artigos &rarr;</a>
</div>
<div class="border-l-4 border-gosign-dark pl-6 py-4">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Agentes</p>
<h3 class="text-h3 font-bold text-gosign-dark">AI Agents em visão geral</h3>
<p class="text-body text-gosign-text-light mt-2">Document Agents, Workflow Agents, Knowledge Agents - três tipos de agentes para processos empresariais.</p>
<a href="/br/servicos/ai-agents/" class="text-small font-semibold text-gosign-accent-text hover:text-gosign-accent-hover mt-3 inline-block whitespace-nowrap">Ver AI Agents &rarr;</a>
</div>
<div class="border-l-4 border-gosign-dark pl-6 py-4">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Governança</p>
<h3 class="text-h3 font-bold text-gosign-dark">Framework de Governança</h3>
<p class="text-body text-gosign-text-light mt-2">EU AI Act, Cert-Ready, Codeterminação, Data Residency - todos os temas de governança em visão geral.</p>
<a href="/br/governance/" class="text-small font-semibold text-gosign-accent-text hover:text-gosign-accent-hover mt-3 inline-block whitespace-nowrap">Ver visão geral de governança &rarr;</a>
</div>
</div>
</div>
</div>
</section>

<!-- Aprofundamento no Agent Briefing -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Aprofundamento no Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nossa série de artigos para executivos que implementam agentes de IA na empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/br/revista/infraestrutura-ia-blueprint-2026/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">Enterprise AI-Infraestrutura Blueprint 2026</p>
</a>
<a href="/br/revista/decision-layer-explicado/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - O que é por que todo agente AI enterprise precisa de um</p>
</a>
<a href="/br/revista/orquestracao-agentes-plataformas/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">Orquestracao de agentes: Trigger.dev, n8n, Camunda e alternativas</p>
</a>
</div>
</div>
</section>

--- Governança, Segurança e Auditoria ---
> AI Agents auditáveis, preparados para certificação e compatíveis com a representação de trabalhadores. Governance by Design.

<!-- Governance as Control Layer -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Governance by Design</h2>
<p class="text-body-lg text-gosign-text-light mt-6">
A Gosign constrói AI Agents para ambientes empresariais. Esses ambientes têm requisitos de rastreabilidade, auditabilidade e controle que vão além do que uma implantação padrão de LLM oferece.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Governance by Design significa: cada agente é construído desde o início com os mecanismos que auditores, representações de trabalhadores e equipes de conformidade esperam. Não é uma camada opcional. É um princípio arquitetônico.
</p>
</div>
</div>
</section>

<!-- Five Dimensions -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">Cinco Dimensões de Governança</h2>

<div class="max-w-narrow space-y-8">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">1. Audit Trail e Rastreabilidade</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Cada decisão de um AI Agent gera um ato de decisão completo: entrada, modelo e versão, avaliação profissional, pontuação de confiança, regra aplicada com versão, rota de decisão (autônoma ou Human-in-the-Loop), resultado, timestamp e caminho de contestação. O Audit Trail é imutável, exportável e legível por máquinas. Esse ato é a resposta arquitetônica ao direito do titular de revisar a decisão individual nos termos da <a href="/br/revista/ato-de-decisao-decisoes-ia-contestaveis/" class="text-gosign-accent-text hover:underline">LGPD art. 20 (e do art. 86 do EU AI Act em negócios na UE)</a>.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark">2. Decision Layer</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
O Decision Layer é a camada arquitetônica entre AI Agent e sistema destino. Torna cada decisão do LLM transparente, auditável e rastreável. Decisão autônoma onde o modelo pode decidir de forma segura. Human-in-the-Loop onde existe risco de viés, potencial de discriminação ou temas de cogestão - imposto arquitetonicamente.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark">3. Cert-Ready by Design</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Os controles são objetos de dados de primeira classe no sistema. Cada controle tem: implementação técnica, gerador automático de evidências, histórico de evidências e visão de auditor com drill-down.
</p>
<p class="mt-4">
<a href="/br/governance/cert-ready/" class="text-gosign-accent-text font-semibold hover:text-gosign-accent-hover">Cert-Ready by Design em detalhe</a>
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark">4. Representação de Trabalhadores e Sindicatos (PT: Comissão de Trabalhadores)</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
AI Agents em empresas estão sujeitos a regulamentações de representação de trabalhadores, incluindo sindicatos e representantes dos trabalhadores (PT: Comissão de Trabalhadores) no Brasil e comitês de trabalhadores em Portugal e na UE. A arquitetura da Gosign aborda isso como princípio de design: acordos coletivos e regulamentos internos como restrições explícitas, rastreabilidade completa, Human-in-the-Loop para decisões com potencial de viés ou discriminação.
</p>
<p class="mt-4">
<a href="/br/governance/co-determination/" class="text-gosign-accent-text font-semibold hover:text-gosign-accent-hover">Representação de Trabalhadores em detalhe</a>
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark">5. EU AI Act</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
O EU AI Act é a regulamentação europeia de IA - aplica-se diretamente na UE e em Portugal; no Brasil é relevante para empresas com operações na UE. A arquitetura da Gosign aborda os requisitos centrais do EU AI Act como princípio de design: Transparência (Art. 13), Supervisão humana (Art. 14), Obrigações de registro (Art. 12), Gestão de riscos (Art. 9) e o direito à explicação da decisão individual (Art. 86) - este último alinhado ao que a LGPD art. 20 já garante hoje no Brasil.
</p>
<p class="mt-4">
<a href="/br/governance/eu-ai-act/" class="text-gosign-accent-text font-semibold hover:text-gosign-accent-hover">EU AI Act Readiness em detalhe</a>
</p>
</div>
</div>
</div>
</section>

<!-- Seis dimensões de Governança -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">Seis dimensões de Governança</h2>
<div class="grid grid-cols-1 lg:grid-cols-3 gap-6 lg:gap-8">
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75L11.25 15 15 9.75m-3-7.036A11.959 11.959 0 013.598 6 11.99 11.99 0 003 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Cert-Ready by Design</h3>
<p class="text-body text-gosign-text-light mt-3">Controles como objetos de dados, evidências automáticas, portal de auditor ao vivo. Prontidão para certificação como estado arquitetônico.</p>
<a href="/br/governance/cert-ready/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
Ver Cert-Ready Controls
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M18 18.72a9.094 9.094 0 003.741-.479 3 3 0 00-4.682-2.72m.94 3.198l.001.031c0 .225-.012.447-.037.666A11.944 11.944 0 0112 21c-2.17 0-4.207-.576-5.963-1.584A6.062 6.062 0 016 18.719m12 0a5.971 5.971 0 00-.941-3.197m0 0A5.995 5.995 0 0012 12.75a5.995 5.995 0 00-5.058 2.772m0 0a3 3 0 00-4.681 2.72 8.986 8.986 0 003.74.477m.94-3.197a5.971 5.971 0 00-.94 3.197M15 6.75a3 3 0 11-6 0 3 3 0 016 0zm6 3a2.25 2.25 0 11-4.5 0 2.25 2.25 0 014.5 0zm-13.5 0a2.25 2.25 0 11-4.5 0 2.25 2.25 0 014.5 0z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Representação de Trabalhadores</h3>
<p class="text-body text-gosign-text-light mt-3">Regulamentos internos e acordos coletivos como restrições. Human-in-the-Loop em decisões que afetam trabalhadores. Tecnicamente imposto, não apenas acordado organizacionalmente.</p>
<a href="/br/governance/co-determination/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
Ver Representação de Trabalhadores
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 3v17.25m0 0c-1.472 0-2.882.265-4.185.75M12 20.25c1.472 0 2.882.265 4.185.75M18.75 4.97A48.416 48.416 0 0012 4.5c-2.291 0-4.545.16-6.75.47m13.5 0c1.01.143 2.01.317 3 .52m-3-.52l2.62 10.726c.122.499-.106 1.028-.589 1.202a5.988 5.988 0 01-2.031.352 5.988 5.988 0 01-2.031-.352c-.483-.174-.711-.703-.59-1.202L18.75 4.971zm-16.5.52c.99-.203 1.99-.377 3-.52m0 0l2.62 10.726c.122.499-.106 1.028-.589 1.202a5.989 5.989 0 01-2.031.352 5.989 5.989 0 01-2.031-.352c-.483-.174-.711-.703-.59-1.202L5.25 4.971z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">EU AI Act</h3>
<p class="text-body text-gosign-text-light mt-3">EU AI Act compliant by design. Mapeamento arquitetônico para Art. 9-15. Transparência, explicabilidade e supervisão humana como arquitetura base.</p>
<a href="/br/governance/eu-ai-act/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
Ver EU AI Act Compliance
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M21 7.5l-2.25-1.313M21 7.5v2.25m0-2.25l-2.25 1.313M3 7.5l2.25-1.313M3 7.5l2.25 1.313M3 7.5v2.25m9 3l2.25-1.313M12 12.75l-2.25-1.313M12 12.75V15m0 6.75l2.25-1.313M12 21.75V19.5m0 2.25l-2.25-1.313m0-16.875L12 2.25l2.25 1.313M21 14.25v2.25l-2.25 1.313m-13.5 0L3 16.5v-2.25" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Arquitetura de Referência</h3>
<p class="text-body text-gosign-text-light mt-3">Arquitetura de 7 camadas para Enterprise AI. Governança como camada transversal. Apresentação, Orquestração, Agente, Governança, Modelo, Integração, Infraestrutura.</p>
<a href="/br/governance/reference-architecture/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
Ver Arquitetura
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M16.5 10.5V6.75a4.5 4.5 0 10-9 0v3.75m-.75 11.25h10.5a2.25 2.25 0 002.25-2.25v-6.75a2.25 2.25 0 00-2.25-2.25H6.75a2.25 2.25 0 00-2.25 2.25v6.75a2.25 2.25 0 002.25 2.25z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Residência de Dados</h3>
<p class="text-body text-gosign-text-light mt-3">LGPD (PT: RGPD). Azure Brasil, Azure UE, GCP Brasil, GCP UE, AWS Brasil, AWS UE, Self-Hosted, Híbrido. Soberania de dados como decisão arquitetônica, não como opção de configuração.</p>
<a href="/br/governance/data-residency/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
Ver Residência de Dados
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12h3.75M9 15h3.75M9 18h3.75m3 .75H18a2.25 2.25 0 002.25-2.25V6.108c0-1.135-.845-2.098-1.976-2.192a48.424 48.424 0 00-1.123-.08m-5.801 0c-.065.21-.1.433-.1.664 0 .414.336.75.75.75h4.5a.75.75 0 00.75-.75 2.25 2.25 0 00-.1-.664m-5.8 0A2.251 2.251 0 0113.5 2.25H15a2.25 2.25 0 012.15 1.586m-5.8 0c-.376.023-.75.05-1.124.08C9.095 4.01 8.25 4.973 8.25 6.108V8.25m0 0H4.875c-.621 0-1.125.504-1.125 1.125v11.25c0 .621.504 1.125 1.125 1.125h9.75c.621 0 1.125-.504 1.125-1.125V9.375c0-.621-.504-1.125-1.125-1.125H8.25zM6.75 12h.008v.008H6.75V12zm0 3h.008v.008H6.75V15zm0 3h.008v.008H6.75V18z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Contrato de operador para infraestrutura IA</h3>
<p class="text-body text-gosign-text-light mt-3">Por que contratos padrão de operador de dados não cobrem a IA empresarial. Checklist com 25 perguntas de verificação para jurídico, segurança de TI e compliance.</p>
<a href="/br/governance/checklist-contrato-ia/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
Checklist
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</article>
</div>
</div>
</section>

<!-- Architecture Preview -->
<section class="py-section bg-gosign-dark text-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold mb-6">Visão Geral da Arquitetura</h2>
<pre class="bg-gosign-dark border border-white/10 text-white p-6 rounded-card overflow-x-auto text-small font-mono leading-relaxed"><code>┌─────────────────────────────────────────────────┐
│  Presentation Layer    Chat UI, Dashboard, API  │
├─────────────────────────────────────────────────┤
│  Orchestration Layer   Trigger.dev/Camunda, API GW      │
├─────────────────────────────────────────────────┤
│  Agent Layer           Document, Workflow,       │
│                        Knowledge Agents          │
├─────────────────────┬───────────────────────────┤
│  GOVERNANCE LAYER   │ Audit Trail, RBAC,        │
│  (Transversal)      │ Decision Layer,           │
│                     │ Cert-Ready Controls       │
├─────────────────────┴───────────────────────────┤
│  Model Layer           Claude, ChatGPT, Llama   │
├─────────────────────────────────────────────────┤
│  Integration Layer     SAP, ERP, MS Graph       │
├─────────────────────────────────────────────────┤
│  Infrastructure Layer  Azure, GCP, AWS, Self-Hosted  │
└─────────────────────────────────────────────────┘</code></pre>
<p class="mt-6">
<a href="/br/governance/reference-architecture/" class="inline-flex items-center text-body-lg font-semibold text-gosign-accent-on-dark hover:text-gosign-accent-on-dark transition-colors">
Ver arquitetura completa
<svg class="w-5 h-5 ml-2" fill="none" stroke="currentColor" viewBox="0 0 24 24">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" />
</svg>
</a>
</p>
</div>
</section>

<!-- Closing -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">A Governança Se Aplica a Cada Agente</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Governance by Design não é uma característica de um único produto. É um princípio arquitetônico que se aplica a cada AI Agent que a Gosign constrói.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Mesma governança. Mesma auditabilidade. Mesma infraestrutura.
</p>
</div>
</div>
</section>

<!-- Aprofundamento no Agent Briefing -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">Aprofundamento no Agent Briefing (Revista Gosign)</h2>
<div class="grid md:grid-cols-3 gap-6">
<a href="/br/revista/shadow-ai-governance/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<h3 class="text-h3 font-bold text-gosign-dark">Decision Layer e Shadow AI</h3>
</a>
<a href="/br/revista/eu-ai-act-2026-empresas/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<h3 class="text-h3 font-bold text-gosign-dark">EU AI Act 2026</h3>
</a>
<a href="/br/revista/infraestrutura-ia-blueprint-2026/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Infrastructure</p>
<h3 class="text-h3 font-bold text-gosign-dark">Infraestrutura IA Blueprint 2026</h3>
</a>
</div>
</div>
</section>

--- Enterprise AI Agents - Na sua infraestrutura. Sob seu controle. ---
> Enterprise AI Agent Infrastructure para HR, Finance e IT. Decisões LLM auditáveis, Governance by Design, agnóstico de modelo.

<!-- Enterprise AI Infrastructure & Agent Engineering -->
<section class="scroll-reveal py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex flex-col lg:flex-row lg:items-start lg:gap-12">
<div class="lg:w-[55%]">
<h2 class="text-h1 font-bold text-gosign-dark">
Enterprise AI Infrastructure & Agent Engineering
</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Gosign é uma Enterprise AI Infrastructure & Agent Engineering Company. Desenvolvemos e operamos a infraestrutura que torna AI Agents produtivos em empresas: orquestração, governance, Decision Layer e auditoria.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
25 anos de desenvolvimento de software. Até 108 colaboradores. Mais de 5.000 projetos para Airbus, Volkswagen, Shell. Desde 2024 focados em Enterprise AI Agent Engineering.
</p>
</div>
<div class="lg:w-[45%] mt-8 lg:mt-0 flex justify-center">
<img
src="/images/7-layer-architecture-v2.svg"
alt="Arquitetura Gosign de 7 camadas para Enterprise AI: Presentation Layer (Chat UI, Dashboard, API), Orchestration Layer (Trigger.dev, Camunda), Agent Layer (Document, Workflow, Knowledge Agents), Governance Layer como camada transversal (Audit Trail, RBAC, Decision Layer, Cert-Ready Controls), Model Layer (Claude, GPT, Gemini, Llama, Mistral, DeepSeek - agnóstico de modelo), Integration Layer (SAP, ERP, Microsoft Graph), Infrastructure Layer (Azure, GCP, AWS, Self-Hosted, Hybrid)"
width="500"
height="400"
class="w-full max-w-md"
loading="lazy"
/>
</div>
</div>
</div>
</section>

<!-- Por que a maioria dos projetos de IA não gera benefícios mensuráveis -->
<section class="scroll-reveal py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Por que a maioria dos projetos de IA não gera benefícios mensuráveis</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
A maioria das empresas já utiliza IA. Pouquíssimas obtêm benefícios mensuráveis com ela. Não porque a tecnologia não funcione - mas porque ninguém definiu quais decisões a IA pode tomar de forma autônoma e quais devem permanecer com humanos.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
A experiência setorial mostra: para cada euro investido em tecnologia, são necessários quatro a cinco euros em processos, governance e gestão de mudança. Quem investe apenas em tecnologia, investe ao lado do problema.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
O <a href="/br/decision-layer/" class="text-gosign-accent-text hover:underline font-semibold">Decision Layer</a> é a camada que faz essa diferença: decompõe cada processo de negócio em etapas de decisão individuais e define para cada etapa - humano, conjunto de regras ou IA. Assim, um experimento de IA torna-se um sistema produtivo.
</p>
</div>
</div>
</section>

<!-- AI Agents para o seu departamento -->
<section class="scroll-reveal py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">AI Agents para o seu departamento</h2>
<div class="grid grid-cols-1 gap-6 lg:gap-8 lg:grid-cols-3">
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 hover:shadow-lg hover:-translate-y-0.5 transition-all duration-200">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<img src="/images/icon-finance.svg" alt="" class="w-10 h-10" width="40" height="40" />
</div>
<h3 class="text-h3 font-bold text-gosign-dark">AI Agents para Finance & Auditoria</h3>
<p class="text-body text-gosign-text-light mt-3">Decision Automation para processamento de documentos, contabilização e preparação de auditoria. Regras versionadas, trilha de auditoria completa, Cert-Ready by Design. O <a href='/br/decision-layer/' class='text-gosign-accent-text hover:underline'>Decision Layer</a> torna cada decisão contábil rastreável.</p>
<a href="/br/finance-ai-agents/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
Finance AI Agents
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 hover:shadow-lg hover:-translate-y-0.5 transition-all duration-200">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<img src="/images/icon-hr.svg" alt="" class="w-10 h-10" width="40" height="40" />
</div>
<h3 class="text-h3 font-bold text-gosign-dark">AI Agents para HR & People Operations</h3>
<p class="text-body text-gosign-text-light mt-3">AI Agents auditáveis para decisões de RH. Preparado para representação dos trabalhadores (sindicatos/CRE; PT: Comissão de Trabalhadores) e comitês internos. Decision Layer com Human-in-the-Loop. Folha de pagamento, onboarding, processamento de documentos, políticas e conhecimento.</p>
<a href="/br/hr-ai-agents/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
HR AI Agents
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 hover:shadow-lg hover:-translate-y-0.5 transition-all duration-200">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<img src="/images/icon-infrastructure.svg" alt="" class="w-10 h-10" width="40" height="40" />
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Infraestrutura AI para IT & Enterprise</h3>
<p class="text-body text-gosign-text-light mt-3">Hosting LLM, RAG, orquestração. Self-hosted, nuvem ou híbrido. Agnóstico de modelo, Governance by Design, Cert-Ready by Design. A plataforma em que seus agents operam em produção.</p>
<a href="/br/servicos/infraestrutura/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
Infraestrutura
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</article>
</div>
</div>
</section>

<!-- Três tipos de agentes -->
<section class="scroll-reveal py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 space-y-12">
<h2 class="text-h1 font-bold text-gosign-dark">Agents especializados para processos Enterprise</h2>
<article class="flex flex-col lg:flex-row gap-8 lg:gap-12 items-start">
<div class="flex-shrink-0 w-16 h-16 lg:w-20 lg:h-20 rounded-full bg-gosign-accent/10 flex items-center justify-center">
<span class="text-h1 lg:text-hero font-bold text-gosign-accent-text">01</span>
</div>
<div class="flex-1 lg:w-[55%]">
<h3 class="text-h2 font-bold text-gosign-dark">Document Agents</h3>
<p class="text-body-lg text-gosign-text-light mt-3">O especialista: compreende documentos. Um atestado médico chega. O agente identifica o tipo de documento, extrai nome, período e CID, verifica se todos os campos obrigatórios estão presentes e atribui o documento ao colaborador correto. Não é correspondência de templates - compreensão linguística real: distingue um atestado médico de um laudo de incapacidade, mesmo quando ambos vêm do mesmo médico. O Decision Layer avalia cada extração: determinística? Conjunto de regras. Confiante o suficiente? O agente decide de forma autônoma. Discricionariedade necessária? Revisão humana.</p>
<a href="/br/servicos/ai-agents/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
Document Agents em detalhe
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</div>
<div class="lg:w-[40%] mt-4 lg:mt-11">
<img src="/images/flow-document-agent-v10-br.svg" alt="Document Agent - O Especialista: Um documento entra, o agente compreende tipo, conteúdo e contexto, Decision Layer direciona por três níveis (regras, autonomia IA, revisão humana), dados estruturados saem." class="w-full" width="480" height="620" loading="lazy" />
</div>
</article>
<article class="flex flex-col lg:flex-row gap-8 lg:gap-12 items-start">
<div class="flex-shrink-0 w-16 h-16 lg:w-20 lg:h-20 rounded-full bg-gosign-accent/10 flex items-center justify-center">
<span class="text-h1 lg:text-hero font-bold text-gosign-accent-text">02</span>
</div>
<div class="flex-1 lg:w-[55%]">
<h3 class="text-h2 font-bold text-gosign-dark">Workflow Agents</h3>
<p class="text-body-lg text-gosign-text-light mt-3">O coordenador: dirige todo o processo. O atestado médico está compreendido - e agora? O Workflow Agent assume: verifica no sistema de RH se é a terceira notificação em seis meses, confere com o acordo coletivo (CCT/ACT; PT: contrato coletivo) se o limiar de reintegração foi atingido, cria uma tarefa para o gestor de RH no SAP SuccessFactors, informa os representantes dos trabalhadores (sindicato/CRE; PT: Comissão de Trabalhadores) e agenda um acompanhamento. Cinco sistemas, três pontos de decisão, um agente coordenando todo o processo - incluindo decisões de roteamento independentes quando a confiança é suficiente. Cada passo na trilha de auditoria.</p>
<a href="/br/servicos/ai-agents/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
Workflow Agents em detalhe
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</div>
<div class="lg:w-[40%] mt-4 lg:mt-11">
<img src="/images/flow-workflow-agent-v10-br.svg" alt="Workflow Agent - O Coordenador: Dirige um processo multietapa entre sistemas. Chama Document Agents, verifica contra regras, cria tarefas no SAP, informa representantes, agenda acompanhamentos. Cada passo na trilha de auditoria." class="w-full" width="480" height="542" loading="lazy" />
</div>
</article>
<article class="flex flex-col lg:flex-row gap-8 lg:gap-12 items-start">
<div class="flex-shrink-0 w-16 h-16 lg:w-20 lg:h-20 rounded-full bg-gosign-accent/10 flex items-center justify-center">
<span class="text-h1 lg:text-hero font-bold text-gosign-accent-text">03</span>
</div>
<div class="flex-1 lg:w-[55%]">
<h3 class="text-h2 font-bold text-gosign-dark">Knowledge Agents</h3>
<p class="text-body-lg text-gosign-text-light mt-3">O portador de conhecimento: responde perguntas a partir do conhecimento da empresa. Um gestor de RH pergunta: 'A partir de quando deve ser iniciado um procedimento de reintegração após afastamento prolongado?' O agente não apenas pesquisa - interpreta políticas internas, acordos coletivos (CCT/ACT; PT: contratos coletivos) e requisitos regulatórios no contexto da pergunta, fornecendo uma resposta específica com referência de fonte, versão da regra e data de validade. Em caso de incerteza, sinaliza explicitamente. Sem fonte verificada, o agente não responde - sem alucinações.</p>
<a href="/br/servicos/ai-agents/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
Knowledge Agents em detalhe
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</div>
<div class="lg:w-[40%] mt-4 lg:mt-11">
<img src="/images/flow-knowledge-agent-v10-br.svg" alt="Knowledge Agent - O Portador de Conhecimento: Pergunta com contexto entra, o agente interpreta fontes verificadas, resposta específica com fonte e versão sai. Incerteza: sinaliza. Sem fonte: sem resposta." class="w-full" width="480" height="628" loading="lazy" />
</div>
</article>
</div>
</section>

<!-- Comparação de arquiteturas -->
<section class="scroll-reveal py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Comparação de arquiteturas: Copilot, SaaS Agent, Gosign</h2>
<p class="text-body-lg text-gosign-text-light mb-8">Três abordagens para AI empresarial - diferentes arquiteturas, diferentes consequências.</p>
<div class="overflow-x-auto -mx-4 sm:mx-0">
<table class="w-full min-w-[36rem] border-collapse text-small">
<thead>
<tr>
<th class="px-4 py-3 text-left font-semibold bg-gosign-dark text-white">Dimensão</th>
<th class="px-4 py-3 text-left font-semibold bg-gosign-dark text-white border-t-[3px] border-t-gosign-accent">Gosign Agent Architecture</th>
<th class="px-4 py-3 text-left font-semibold bg-gosign-dark text-white">Microsoft Copilot</th>
<th class="px-4 py-3 text-left font-semibold bg-gosign-dark text-white">SaaS AI Agent</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Profundidade de decisão</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border bg-gosign-accent/5">Decisões de domínio com Decision Layer</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Assistência e sugestões</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Workflows pré-configurados</td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Auditabilidade</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border bg-gosign-accent/5">Trilha de auditoria completa até nível SQL</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Logging básico</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Logging de plataforma</td>
</tr>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Acesso ao código</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border bg-gosign-accent/5">Acesso completo ao código-fonte · Configurações com o cliente · Sem vendor lock-in</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Microsoft detém o código</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Plataforma detém o código</td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Escolha de modelo</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border bg-gosign-accent/5">Agnóstico (GPT, Claude, Gemini, Llama, Mistral)</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">GPT (vinculado à Microsoft)</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Vinculado à plataforma</td>
</tr>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Governance</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border bg-gosign-accent/5">Governance Layer próprio, Cert-Ready Controls, Portal do Auditor</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Azure governance</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Governance da plataforma</td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Human-in-the-Loop</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border bg-gosign-accent/5">Arquitetonicamente forçado em decisões de risco</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Opcional</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Configurável</td>
</tr>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">EU AI Act</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border bg-gosign-accent/5">Compliant by design</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Roadmap da Microsoft</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Dependente do provedor</td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Representação dos Trabalhadores</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border bg-gosign-accent/5">Templates, logging, conceitos de papéis para sindicatos e CRE</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Sem suporte específico</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Sem suporte específico</td>
</tr>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Infraestrutura</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border bg-gosign-accent/5">Infraestrutura do cliente (Azure, GCP, AWS, self-hosted, híbrido)</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Microsoft Cloud</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Nuvem do provedor</td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Estratégia de saída</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border bg-gosign-accent/5">Operação independente após 12-18 meses</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Migração de plataforma</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Migração de plataforma</td>
</tr>
</tbody>
</table>
</div>
<p class="text-small text-gosign-text-light italic mt-4">
Esta tabela mostra diferenças arquitetônicas, não julgamentos de qualidade. Copilot e agentes SaaS têm outros pontos fortes - velocidade, ecossistema, simplicidade. O ponto forte da Gosign é governance, propriedade e auditabilidade em ambientes regulados.
</p>
</div>
</section>

<!-- Governance by Design -->
<section class="scroll-reveal bg-gosign-dark text-white py-section">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold">Governance by Design</h2>
<p class="text-h3 text-gosign-accent-on-dark font-semibold mt-4">
Agents só escalam com infraestrutura. Sem governance, AI permanece um piloto - com infraestrutura, torna-se escalável.
</p>
<div class="mt-8 space-y-4">
<p class="text-body-lg text-gosign-text-on-dark/80 flex items-start gap-3">
<svg class="w-5 h-5 mt-1 flex-shrink-0 text-gosign-accent-on-dark" fill="currentColor" viewBox="0 0 20 20"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span>Human-in-the-Loop: não é uma barreira geral, mas controle arquitetônico. Alta confiança e baixo risco: decisão autônoma. Risco de viés ou questões de cogestão: humano decide. O Decision Layer roteia automaticamente.</span>
</p>
<p class="text-body-lg text-gosign-text-on-dark/80 flex items-start gap-3">
<svg class="w-5 h-5 mt-1 flex-shrink-0 text-gosign-accent-on-dark" fill="currentColor" viewBox="0 0 20 20"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span>Auditável: cada decisão do agente produz um registro completo: entrada, modelo, avaliação, score de confiança, fundamentação, caminho de decisão, resultado. Imutável, exportável, pronto para auditoria.</span>
</p>
<p class="text-body-lg text-gosign-text-on-dark/80 flex items-start gap-3">
<svg class="w-5 h-5 mt-1 flex-shrink-0 text-gosign-accent-on-dark" fill="currentColor" viewBox="0 0 20 20"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span>Cert-Ready by Design: controles são objetos de dados de primeira classe no sistema. Cada controle tem uma implementação técnica, um gerador automático de evidências e um histórico de evidências. Auditores veem o status ao vivo no Portal do Auditor.</span>
</p>
<p class="text-body-lg text-gosign-text-on-dark/80 flex items-start gap-3">
<svg class="w-5 h-5 mt-1 flex-shrink-0 text-gosign-accent-on-dark" fill="currentColor" viewBox="0 0 20 20"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span>EU AI Act compliant by design: transparência, explicabilidade e supervisão humana são arquitetonicamente integradas - não adicionadas depois.</span>
</p>
</div>
</div>
<div class="mt-12 overflow-x-auto -mx-4 sm:mx-0 px-4 sm:px-0">
<img src="/images/diagrams/decision-layer-drei-arten-br.svg" alt="Três níveis de autonomia no Gosign Decision Layer: (1) Humano decide - agente fornece dados para ajustes salariais, demissões, transferências, decisões com risco de viés, temas de representação de trabalhadores (aprox. 35% dos processos HR). (2) Agente trabalha, humano revisa - em processamento de documentos, revisão de contratos, etapas de onboarding, criação de referências, screening de recrutamento (aprox. 40% dos processos HR). (3) Agente autônomo - em respostas FAQ, certificados padrão, verificação de prazos, validação de dados, notificações rotineiras (aprox. 25% dos processos HR). Cada decisão documentada, cada etapa auditável." width="900" height="360" class="w-full min-w-[600px] max-w-4xl mx-auto rounded-lg" loading="lazy" />
</div>
</div>
</section>

<!-- Definição: Decision Layer -->
<section class="scroll-reveal py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h3 class="text-h3 font-bold text-gosign-dark">Definição: Decision Layer</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
O Decision Layer decompõe cada processo de negócio em etapas de decisão individuais e define antecipadamente para cada etapa: Decide um humano, um conjunto de regras ou a IA de forma autônoma?
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Onde a discricionariedade, o risco de discriminação ou questões de cogestão (sindicatos/CRE; PT: Comissão de Trabalhadores) exercem papel, a arquitetura impõe a revisão humana. Onde uma decisão é determinística - acordo coletivo, verificação de prazos, lógica contábil - o agente aplica o conjunto de regras de forma consistente. E onde o agente tem confiança suficiente e permissão: decide de forma autônoma.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Cada decisão é documentada - quem decidiu o quê, quando, com que base e com que resultado. Verificável por auditores, representantes dos trabalhadores e revisão interna.
</p>
<p class="mt-4">
<a href="/br/governance/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Governance, segurança e auditoria</a>
</p>
</div>
</div>
</section>

<!-- Do PoC à Plataforma -->
<section class="scroll-reveal py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark text-center">Do PoC à Plataforma</h2>
<div class="mt-12 grid grid-cols-1 md:grid-cols-3 gap-8 relative">
<div class="text-center">
<div class="w-14 h-14 mx-auto rounded-full bg-gosign-accent flex items-center justify-center">
<span class="text-h3 font-bold text-white">1</span>
</div>
<h3 class="text-h3 font-bold text-gosign-dark mt-4">Discover</h3>
<p class="text-small font-semibold text-gosign-accent-text mt-1">1 semana</p>
<p class="text-body text-gosign-text-light mt-2">Análise de processos, mapeamento de regras, avaliação do panorama de sistemas, priorização de casos de uso. Resultado: um plano concreto para seu primeiro agente.</p>
</div>
<div class="text-center">
<div class="w-14 h-14 mx-auto rounded-full bg-gosign-accent flex items-center justify-center">
<span class="text-h3 font-bold text-white">2</span>
</div>
<h3 class="text-h3 font-bold text-gosign-dark mt-4">Build</h3>
<p class="text-small font-semibold text-gosign-accent-text mt-1">3-4 semanas</p>
<p class="text-body text-gosign-text-light mt-2">PoC em produção. Um agente, um processo, ao vivo na sua infraestrutura. Decision Layer, governance, trilha de auditoria - desde o primeiro dia.</p>
</div>
<div class="text-center">
<div class="w-14 h-14 mx-auto rounded-full bg-gosign-accent flex items-center justify-center">
<span class="text-h3 font-bold text-white">3</span>
</div>
<h3 class="text-h3 font-bold text-gosign-dark mt-4">Scale</h3>
<p class="text-small font-semibold text-gosign-accent-text mt-1">Contínuo</p>
<p class="text-body text-gosign-text-light mt-2">Mais agentes, mais departamentos, mais localidades. A arquitetura cresce com seus requisitos. Mesmo governance, mesma infraestrutura.</p>
</div>
</div>
<p class="text-body-lg text-center text-gosign-text-light mt-8 max-w-narrow mx-auto">
Após 12-18 meses, você opera seus agents de forma independente. Acesso completo ao código-fonte, prompts e configurações. Sem vendor lock-in - mesmo sem contrato de manutenção.
</p>
</div>
</section>

--- HR Agent - AI Agents para RH e People Operations ---
> 6 produtos AI Agent para RH: Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Decision Layer com Audit Trail. Compatível com sindicatos.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/br/por-que-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Cada decisão rastreável</p>
</div>
</a>
<a href="/br/por-que-gosign/#infraestrutura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Sua infraestrutura</p>
<p class="text-xs text-gosign-text-light">Sem SaaS. Sem vendor lock-in.</p>
</div>
</a>
<a href="/br/por-que-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Sem risco de cloud americana</p>
</div>
</a>
</div>
</div>
</div>

<!-- Product Portfolio -->
<section class="py-section bg-gosign-light"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><h2 class="text-h1 font-bold text-gosign-dark">Portfolio HR Agent</h2><p class="text-body-lg text-gosign-text-light mt-4 mb-8 max-w-narrow">Um HR Agent não automatiza genericamente, mas decompõe processos em micro-decisões. Para cada decisão, o <a href="/br/decision-layer/" class="text-gosign-accent-text hover:text-gosign-accent-hover">Decision Layer</a> define: humano, conjunto de regras ou IA. (PT: Em Portugal, as Comissões de Trabalhadores exercem papel similar ao dos sindicatos brasileiros.)</p><div class="grid grid-cols-1 md:grid-cols-2 lg:grid-cols-3 gap-6"><a href="/br/servicos/hr-agent/payroll-decision-layer/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white"><div class="flex items-center justify-between mb-3"><svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 18.75a60.07 60.07 0 0115.797 2.101c.727.198 1.453-.342 1.453-1.096V18.75M3.75 4.5v.75A.75.75 0 013 6h-.75m0 0v-.375c0-.621.504-1.125 1.125-1.125H20.25M2.25 6v9m18-10.5v.75c0 .414.336.75.75.75h.75m-1.5-1.5h.375c.621 0 1.125.504 1.125 1.125v9.75c0 .621-.504 1.125-1.125 1.125h-.375m1.5-1.5H21a.75.75 0 00-.75.75v.75m0 0H3.75m0 0h-.375a1.125 1.125 0 01-1.125-1.125V15m1.5 1.5v-.75A.75.75 0 003 15h-.75M15 10.5a3 3 0 11-6 0 3 3 0 016 0zm3 0h.008v.008H18V10.5zm-12 0h.008v.008H6V10.5z"/></svg></div><h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Payroll Decision Layer</h3><p class="text-body text-gosign-text-light mt-2">Convenções coletivas, adicionais de turno, pagamentos especiais. 4 simulações setoriais.</p><p class="text-body font-semibold text-gosign-dark mt-3">82-92% Zero-Touch</p></a><a href="/br/servicos/travel-decision-layer/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white"><div class="flex items-center justify-between mb-3"><svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M6 12L3.269 3.126A59.768 59.768 0 0121.485 12 59.77 59.77 0 013.27 20.876L5.999 12zm0 0h7.5"/></svg></div><h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Travel Decision Layer</h3><p class="text-body text-gosign-text-light mt-2">Cada prestação de contas de viagem em 5-12 etapas de decisão auditáveis.</p><p class="text-body font-semibold text-gosign-dark mt-3">>80% redução de custo por comprovante</p></a><a href="/br/recruiting-agent/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white"><div class="flex items-center justify-between mb-3"><svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M18 18.72a9.094 9.094 0 003.741-.479 3 3 0 00-4.682-2.72m.94 3.198l.001.031c0 .225-.012.447-.037.666A11.944 11.944 0 0112 21c-2.17 0-4.207-.576-5.963-1.584A6.062 6.062 0 016 18.719m12 0a5.971 5.971 0 00-.941-3.197m0 0A5.995 5.995 0 0012 12.75a5.995 5.995 0 00-5.058 2.772m0 0a3 3 0 00-4.681 2.72 8.986 8.986 0 003.74.477m.94-3.197a5.971 5.971 0 00-.94 3.197M15 6.75a3 3 0 11-6 0 3 3 0 016 0zm6 3a2.25 2.25 0 11-4.5 0 2.25 2.25 0 014.5 0zm-13.5 0a2.25 2.25 0 11-4.5 0 2.25 2.25 0 014.5 0z"/></svg></div><h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Recruiting Agent</h3><p class="text-body text-gosign-text-light mt-2">Triagem, agendamento, comunicação padrão. Alto risco conforme EU AI Act (BR: PL 2338/2023).</p><p class="text-body font-semibold text-gosign-dark mt-3">70-75% automatização</p></a><a href="/br/servicos/hr-agent/leave-absence-decision-layer/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white"><div class="flex items-center justify-between mb-3"><svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M6.75 3v2.25M17.25 3v2.25M3 18.75V7.5a2.25 2.25 0 012.25-2.25h13.5A2.25 2.25 0 0121 7.5v11.25m-18 0A2.25 2.25 0 005.25 21h13.5A2.25 2.25 0 0021 18.75m-18 0v-7.5A2.25 2.25 0 015.25 9h13.5A2.25 2.25 0 0121 11.25v7.5"/></svg></div><h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Leave & Absence Decision Layer</h3><p class="text-body text-gosign-text-light mt-2">Direitos de férias (CLT Art. 129), regras de ausência, obrigações de reintegração. 4 simulações setoriais.</p><p class="text-body font-semibold text-gosign-dark mt-3">78-87% Zero-Touch</p></a><div class="border border-gosign-border rounded-card p-6 bg-gosign-light/50"><div class="flex items-center justify-between mb-3"><svg class="w-8 h-8 text-gosign-text-light" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M16.023 9.348h4.992v-.001M2.985 19.644v-4.992m0 0h4.992m-4.993 0l3.181 3.183a8.25 8.25 0 0013.803-3.7M4.031 9.865a8.25 8.25 0 0113.803-3.7l3.181 3.182"/></svg><span class="inline-flex items-center px-2.5 py-0.5 text-xs font-bold text-white bg-gosign-accent rounded-full">Coming</span></div><h3 class="text-h3 font-bold text-gosign-dark">Employee Lifecycle Decision Layer</h3><p class="text-body text-gosign-text-light mt-2">Onboarding, transferências internas, desligamento em um pipeline auditável.</p></div><div class="border border-gosign-border rounded-card p-6 bg-gosign-light/50"><div class="flex items-center justify-between mb-3"><svg class="w-8 h-8 text-gosign-text-light" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 3c2.755 0 5.455.232 8.083.678.533.09.917.556.917 1.096v1.044a2.25 2.25 0 01-.659 1.591l-5.432 5.432a2.25 2.25 0 00-.659 1.591v2.927a2.25 2.25 0 01-1.244 2.013L9.75 21v-6.568a2.25 2.25 0 00-.659-1.591L3.659 7.409A2.25 2.25 0 013 5.818V4.774c0-.54.384-1.006.917-1.096A48.32 48.32 0 0112 3z"/></svg><span class="inline-flex items-center px-2.5 py-0.5 text-xs font-bold text-white bg-gosign-accent rounded-full">Coming</span></div><h3 class="text-h3 font-bold text-gosign-dark">Candidate Screening Decision Layer</h3><p class="text-body text-gosign-text-light mt-2">Alto risco conforme EU AI Act (BR: PL 2338/2023). Monitoramento de viés. Participação sindical nas diretrizes de seleção.</p></div></div></div></section>

<!-- Start Boring -->
<section class="py-section bg-gosign-light"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Por que você deveria começar com processos entediantes</h2>
<p class="text-body-lg text-gosign-text-light mt-4">Os agentes de RH mais eficazes não automatizam os processos mais espetaculares - mas os mais repetitivos. Folha de pagamento, controle de ponto, ausências padrão: alta densidade de regras, baixo risco, ROI mensurável desde o dia 1. A infraestrutura de governança que você constrói nesse processo é o pré-requisito para agentes mais complexos.</p>
</div></div></section>

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">eBook gratuito: IA em RH</p>
<p class="text-body text-gosign-text mb-4">Checklist regulatório, Decision Framework, perspectiva da representação dos trabalhadores e avaliação de prontidão - o manual de governança para RH.</p>
<a href="/br/ebook/ia-rh-manual-governanca/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Baixar grátis</a>
</div>

<!-- Micro-decisões -->
<section class="py-section bg-gosign-white"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow"><h2 class="text-h1 font-bold text-gosign-dark">Como trabalha um HR Agent</h2><p class="text-body-lg text-gosign-text-light mt-4">Cada processo de RH consiste em dezenas de decisões individuais. O agent verifica contra todos os critérios da convenção coletiva - mais consistente que qualquer analista. Onde a CLT, os sindicatos ou o risco de discriminação exigem, decide um humano.</p><h3 class="text-h3 font-bold text-gosign-dark mt-10">Atestado médico</h3><div class="mt-4 overflow-x-auto"><table class="w-full text-left text-body"><thead><tr class="border-b-2 border-gosign-dark"><th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Micro-decisão</th><th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Quem decide</th><th scope="col" class="py-3 font-bold text-gosign-dark">Por que</th></tr></thead><tbody class="text-gosign-text-light"><tr class="border-b border-gosign-border"><td class="py-3 pr-4">Verificar período de remuneração durante afastamento</td><td class="py-3 pr-4 font-medium">AI autônomo</td><td class="py-3">Verifica TODOS os critérios da convenção coletiva - mais consistente que qualquer especialista</td></tr><tr class="border-b border-gosign-border"><td class="py-3 pr-4">Avaliar obrigação de reintegração (&gt; 6 sem. em 12 meses)</td><td class="py-3 pr-4 font-medium">Humano</td><td class="py-3">Representação dos trabalhadores requer human-in-the-loop, risco de discriminação com dados de saúde</td></tr><tr class="border-b border-gosign-border"><td class="py-3 pr-4">Informar gestor sobre ausência</td><td class="py-3 pr-4 font-medium">AI autônomo</td><td class="py-3">Informação consistente - apenas ausência e duração, sem diagnóstico</td></tr></tbody></table></div><h3 class="text-h3 font-bold text-gosign-dark mt-10">Onboarding</h3><div class="mt-4 overflow-x-auto"><table class="w-full text-left text-body"><thead><tr class="border-b-2 border-gosign-dark"><th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Micro-decisão</th><th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Quem decide</th><th scope="col" class="py-3 font-bold text-gosign-dark">Por que</th></tr></thead><tbody class="text-gosign-text-light"><tr class="border-b border-gosign-border"><td class="py-3 pr-4">Enquadramento na convenção coletiva</td><td class="py-3 pr-4 font-medium">Humano</td><td class="py-3">Sindicato tem direito de consulta sobre enquadramento (CLT)</td></tr><tr class="border-b border-gosign-border"><td class="py-3 pr-4">Acessos de TI e permissões</td><td class="py-3 pr-4 font-medium">Regras + AI</td><td class="py-3">Permissões padrão automáticas, acessos especiais escalados</td></tr><tr class="border-b border-gosign-border"><td class="py-3 pr-4">Elaborar plano de integração</td><td class="py-3 pr-4 font-medium">AI + Humano</td><td class="py-3">AI cria proposta, gestor revisa e ajusta</td></tr></tbody></table></div><h3 class="text-h3 font-bold text-gosign-dark mt-10">Certificado de experiência</h3><div class="mt-4 overflow-x-auto"><table class="w-full text-left text-body"><thead><tr class="border-b-2 border-gosign-dark"><th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Micro-decisão</th><th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Quem decide</th><th scope="col" class="py-3 font-bold text-gosign-dark">Por que</th></tr></thead><tbody class="text-gosign-text-light"><tr class="border-b border-gosign-border"><td class="py-3 pr-4">Gerar descrição de atividades</td><td class="py-3 pr-4 font-medium">AI</td><td class="py-3">Baseado na descrição do cargo, proposta para revisão</td></tr><tr class="border-b border-gosign-border"><td class="py-3 pr-4">Formular avaliação de desempenho</td><td class="py-3 pr-4 font-medium">Humano</td><td class="py-3">Avaliação individual, gestor é responsável</td></tr><tr class="border-b border-gosign-border"><td class="py-3 pr-4">Verificar conformidade legal</td><td class="py-3 pr-4 font-medium">AI + Humano</td><td class="py-3">AI verifica contra padrões conhecidos e sinaliza riscos, humano decide final</td></tr></tbody></table></div><p class="text-body-lg text-gosign-text-light mt-8"><strong>O padrão:</strong> Rotina e regras são automatizadas pelo agent. Decisões discricionárias e juridicamente sensíveis permanecem com humanos. Cada passo documentado.</p><p class="mt-4"><a href="/br/decision-layer/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Mais sobre o Decision Layer &rarr;</a></p></div></div></section>

<!-- Decision Layer -->
<section class="py-section bg-gosign-light"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow"><h2 class="text-h1 font-bold text-gosign-dark">Decision Layer: cada decisão auditável</h2><p class="text-body-lg text-gosign-text-light mt-4">O <a href="/br/decision-layer/" class="text-gosign-accent-text hover:text-gosign-accent-hover">Decision Layer</a> decompõe cada processo de RH em passos de decisão individuais e define para cada passo: decide um humano, um conjunto de regras ou a IA? Onde o modelo pode decidir com segurança, ele decide de forma autônoma. Onde há risco de viés, potencial de discriminação ou questões sindicais, a arquitetura impõe revisão humana.</p><div class="mt-6 bg-gosign-white border border-gosign-border rounded-card p-6"><p class="text-body font-mono text-gosign-dark">Input &rarr; Modelo &rarr; Avaliação &rarr; Confidence Score &rarr; Justificativa &rarr; Caminho de decisão &rarr; Resultado</p></div><p class="text-body-lg text-gosign-text-light mt-4">Cada decisão gera um registro completo: entrada, regra, versão, confiança, resultado, timestamp. Verificável para sindicatos, auditores e compliance interno.</p></div></div></section>

<!-- Governance -->
<section class="py-section bg-gosign-white"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow"><h2 class="text-h1 font-bold text-gosign-dark">Governance e representação dos trabalhadores</h2><h3 class="text-h3 font-bold text-gosign-dark mt-8">Human-in-the-Loop como princípio arquitetônico</h3><p class="text-body-lg text-gosign-text-light mt-4">Não como loop de aprovação opcional, mas como roteamento arquitetonicamente imposto. Decisão autônoma em alta confiança e baixo risco. Human-in-the-Loop em risco de viés, potencial de discriminação e temas sindicais. Acordos coletivos (CCT/ACT) são mapeados como restrições explícitas no Decision Layer - o agent não pode contorná-las. (PT: Em Portugal, as Comissões de Trabalhadores têm direitos de consulta sob o Código do Trabalho.)</p><p class="text-body-lg text-gosign-text-light mt-4"><a href="/br/governance/co-determination/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Representação dos trabalhadores em detalhe &rarr;</a></p><h3 class="text-h3 font-bold text-gosign-dark mt-8">Audit Trail</h3><p class="text-body-lg text-gosign-text-light mt-4">Cada decisão do agent gera um registro completo: entrada, regra, versão, confiança, caminho de decisão, resultado, timestamp. A representação dos trabalhadores pode acompanhar todas as decisões pelo portal de auditoria. Como sindicatos passam de bloqueio a habilitação está descrito no <a href="/br/revista/comite-empresa-ai-literacy/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">artigo sobre Sindicatos & AI Literacy</a>.</p><h3 class="text-h3 font-bold text-gosign-dark mt-8">EU AI Act Readiness</h3><p class="text-body-lg text-gosign-text-light mt-4">A arquitetura endereça transparência (Art. 13), supervisão humana (Art. 14), obrigações de registro (Art. 12) e gestão de riscos (Art. 9) como princípio de design. No Brasil, o PL 2338/2023 propõe requisitos similares para sistemas de IA de alto risco - nenhum projeto de compliance posterior necessário.</p><p class="text-body-lg text-gosign-text-light mt-4"><a href="/br/governance/eu-ai-act/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">EU AI Act Readiness &rarr;</a></p></div></div></section>

<!-- Integração -->
<section class="py-section bg-gosign-light"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow"><h2 class="text-h1 font-bold text-gosign-dark">Integração na sua infraestrutura existente</h2><p class="text-body-lg text-gosign-text-light mt-4">AI Agents não substituem sistemas. SAP SuccessFactors continua sendo seu HCM, Workday continua sendo sua plataforma de RH, SAP FI/CO continua sendo seu ERP. A lógica do agent é desacoplada do sistema-alvo - via interfaces padronizadas. Nenhum projeto de migração, nenhuma troca de sistema. Um processo, um sistema, um agent.</p></div></div></section>

<!-- ProcessSteps -->
<section class="py-section bg-gosign-dark text-white"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><h2 class="text-h1 font-bold">Do PoC à plataforma</h2><div class="grid md:grid-cols-3 gap-8 mt-8"><div><p class="text-xs font-bold uppercase tracking-wider text-gosign-accent-on-dark">Discover - 1 semana</p><p class="text-body-lg text-gosign-text-on-dark/80 mt-2">Análise de processos, compreensão de regras, priorização de use cases. Qual processo tem o maior potencial de erro?</p></div><div><p class="text-xs font-bold uppercase tracking-wider text-gosign-accent-on-dark">Build - 3-4 semanas</p><p class="text-body-lg text-gosign-text-on-dark/80 mt-2">PoC produtivo. Um agent, um processo, em produção na sua infraestrutura com Decision Layer e Audit Trail.</p></div><div><p class="text-xs font-bold uppercase tracking-wider text-gosign-accent-on-dark">Scale - Contínuo</p><p class="text-body-lg text-gosign-text-on-dark/80 mt-2">Mais agents, mais processos. Mesmo governance, mesma auditabilidade. Após 12-18 meses você opera seus agents de forma independente.</p></div></div></div></section>

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">HR Agent Readiness Assessment</p>
<p class="text-body text-gosign-text mb-4">7 perguntas, 3 minutos: Quão preparada está sua organização de RH para AI Agents?</p>
<a href="/br/hr-agent-readiness/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Iniciar assessment &rarr;</a>
</div>

<!-- Catálogo de agentes HR -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex flex-col md:flex-row items-start gap-8">
<div class="flex-1">
<h2 class="text-h2 font-bold text-gosign-dark">Catálogo de agentes HR: 48 agentes avaliados e priorizados</h2>
<p class="text-body-lg text-gosign-text mt-4">Quais agentes HR existem, qual governance precisam e em que ordem você deveria começar? O catálogo avalia 48 agentes em 6 dimensões - de Agent Readiness até classificação EU AI Act.</p>
<p class="text-body text-gosign-text-light mt-3">11 domínios, 3 quadrantes interativos de priorização, tabelas de micro-decisões para cada agente.</p>
<a href="/br/catalogo-agentes-hr/" class="inline-flex items-center gap-2 mt-4 text-body font-semibold text-gosign-accent hover:underline">Ao catálogo de agentes HR &rarr;</a>
</div>
</div>
</div>
</section>

<!-- Magazine Links -->
<section class="py-section bg-gosign-white"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><h2 class="text-h2 font-bold text-gosign-dark mb-8">Aprofundamento no Agent Briefing (Revista Gosign)</h2><div class="grid md:grid-cols-3 gap-6"><a href="/br/revista/comite-empresa-ai-literacy/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors"><p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p><h3 class="text-h3 font-bold text-gosign-dark">Sindicatos & AI Literacy</h3></a><a href="/br/revista/decision-layer-shadow-ai/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors"><p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p><h3 class="text-h3 font-bold text-gosign-dark">Decision Layer & Shadow AI</h3></a><a href="/br/revista/eu-ai-act-2026-empresas/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors"><p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p><h3 class="text-h3 font-bold text-gosign-dark">EU AI Act 2026</h3></a></div></div></section>

--- Metodologia Decision Layer ---
> Como a Gosign classifica decisões de agentes, calcula economias e verifica fontes - de forma transparente e rastreável.

## O que é o Decision Layer?

O [Decision Layer](/br/decision-layer/) é a camada de governance entre o agente de IA e o sistema-alvo. Cada decisão que um agente toma ou prepara é documentada como ato de decisão: qual regra em qual versão foi aplicada, quais dados fundamentaram a decisão, quem (humano, motor de regras ou IA) decidiu - e como a pessoa afetada pode contestar. Esse ato de decisão por microdecisão é a resposta arquitetônica ao direito do titular de revisar a decisão individual nos termos da LGPD art. 20 (e do art. 86 do EU AI Act em negócios na UE).

Esta página explica a metodologia por trás dos números exibidos em cada página de detalhe do agente.

## Classificação de decisores: R / A / H

Cada etapa de decisão é atribuída a exatamente um dos três tipos de decisores:

```
R  Motor de regras  Determinístico. Entrada, saída.
                    Sem modelo, sem discricionariedade, sem julgamento.
                    Exemplo: matriz de permissões, verificação de prazos.

A  Agente IA        Baseado em modelo com limiar de Confidence.
                    O resultado é probabilístico. Quando a Confidence
                    cai abaixo do limiar: fallback para R ou H.
                    Exemplo: reconhecimento de Intent, detecção de anomalias.

H  Humano           Explicitamente atribuído. O agente prepara,
                    o humano decide. Documentado no registro
                    de decisão.
                    Exemplo: aprovação de demissão, avaliação de caso excepcional.
```

A distinção baseia-se em dois critérios:

1. **Determinismo**: O resultado é idêntico com a mesma entrada todas as vezes? Sim = R. Não (por causa do modelo) = A. Não (por causa da discricionariedade) = H.
2. **Atribuição de responsabilidade**: Quem responde pelo resultado? Motor de regras (configurado por RH/Finanças) = R. Modelo (treinado, com trilha de auditoria) = A. Pessoa física (nominalmente) = H.

### Enquadramento regulatório

A classificação R/A/H não existe de forma isolada. Ela se mapeia em taxonomias de governance estabelecidas:

| Gosign R/A/H | Taxonomia Human-in-the-Loop | EU AI Act Art. 14 | Analogia com níveis SAE |
|---|---|---|---|
| R (Motor de regras) | Human-out-of-the-Loop | Sem supervisão humana necessária | Nível 4-5 (totalmente automatizado) |
| A (Agente IA) | Human-on-the-Loop | Supervisão humana em alto risco (Art. 14) | Nível 2-3 (assistido/condicional) |
| H (Humano) | Human-in-the-Loop | Humano como decisor | Nível 0-1 (manual/assistido) |

A analogia com os níveis SAE (do setor automotivo, SAE J3016) serve como referência intuitiva, não como transferência direta. No contexto automotivo o nível refere-se à automação da condução; aqui refere-se à automação de decisões em processos de RH e finanças.

## Como contamos as etapas de decisão

Uma etapa de decisão é um ponto no processo em que o agente faz uma escolha de rota. Nem toda operação de dados é uma etapa - apenas pontos em que o resultado pode variar dependendo da entrada.

Critérios para uma etapa de decisão:
- **A entrada varia**: Nem todo caso segue o mesmo caminho
- **A saída tem consequência**: O resultado influencia o processo subsequente ou um sistema-alvo
- **O decisor é atribuível**: Está claro se quem decide é R, A ou H

Exemplo: O agente Employee Self-Service tem 6 etapas de decisão identificadas - desde o reconhecimento de Intent (A) passando pela verificação de permissões (R) até o encaminhamento à área especializada (R). Uma simples consulta ao banco de dados ("consultar férias restantes") não é uma etapa de decisão.

## Cálculo de pontuações

Cada agente é avaliado em cinco dimensões:

| Pontuação | O que mede | Escala |
|---|---|---|
| **Readiness** | Quão preparada está uma organização típica para este agente? | 0-100 |
| **Governance** | Qual é a carga regulatória (EU AI Act, Sindicato/CRE, LGPD)? | 0-100 (maior = mais exigente) |
| **Economic** | Qual é a alavancagem econômica (ROI, economia de FTE)? | 0-100 |
| **Lighthouse** | Qual é o efeito sinalizador interno e externo? | 0-100 |
| **Complexity** | Qual é a complexidade da implementação técnica? | 0-100 (maior = mais complexo) |

Cada pontuação é expressa como faixa [n, n+7] - a amplitude reflete a variância entre setores e tamanhos de organização. O valor inferior é o cenário conservador (média empresa sem trabalho preparatório), o superior é o cenário otimista (enterprise com infraestrutura existente).

As pontuações baseiam-se em uma combinação de:
- **Comparação setorial**: Quão comparáveis são os processos entre organizações? (maior padronização = maior pontuação Readiness)
- **Análise regulatória**: EU AI Act Annex III, LGPD Art. 20 (decisões automatizadas), direitos de representação via Sindicato/CRE (pontuação Governance)
- **Dados de benchmark**: Estudos externos sobre potencial de automação (pontuação Economic)
- **Experiência de projetos**: Gosign Decision Layer Assessments de projetos documentados com clientes

## Faixas de economia na declaração de impacto

Cada agente tem uma declaração de impacto (pyramidOpener.impact) que faz uma afirmação quantitativa sobre o benefício. Essas afirmações se classificam em três categorias de fontes:

### CAT-EXT - Fonte primária externa

O número provém de um estudo setorial verificado ou relatório de benchmark. Editora, título, ano e URL estão documentados no CITATION-CATALOG. O número foi verificado contra a fonte primária (verificação WebFetch da URL mais comparação de conteúdo).

Exemplo: *"Segundo Ardent Partners State of ePayables 2024, o custo por fatura cai de 12,88 para 2,78 USD"* - Ardent Partners é a editora, os números constam no relatório.

### CAT-LEGAL - Legislação ou estatísticas oficiais

O número provém de legislação, estatísticas oficiais ou decisão judicial. A URL aponta para a fonte oficial (p. ex. eur-lex.europa.eu, planalto.gov.br, bases legislativas nacionais).

Exemplo: *"EU AI Act Anexo III sistema de alto risco a partir de 2 de agosto de 2026 (adiamento para dezembro de 2027 acordado provisoriamente - Digital Omnibus, maio de 2026)"* - Regulamento (UE) 2024/1689.

### CAT-INT - Gosign Decision Layer Assessment

O número baseia-se em projetos documentados com clientes. Métricas típicas: tempos de processamento (antes/depois), taxas de correspondência automática, reduções de erros. São valores medianos de pelo menos 3 projetos comparáveis no período 2024-2026.

Quando um número de impacto é classificado como CAT-INT, significa: o número é uma experiência Gosign, não um benchmark externo. É robusto no contexto dos nossos dados de projetos, mas não foi verificado de forma independente externamente.

## Verificação de fontes

Cada fonte externa no CITATION-CATALOG foi verificada pelo seguinte processo:

1. **Verificação de URL**: A URL da fonte responde com HTTP 200 (ou redirecionamento para uma página de destino)
2. **Comparação de números**: O número citado na declaração de impacto realmente aparece na fonte (não apenas "aproximadamente" ou "no espírito de")
3. **Verificação de contexto**: O número é usado no mesmo contexto que na fonte (p. ex. "Value Erosion" não reinterpretada como "custos de gestão")

Se um número não passa nessa tripla verificação, é:
- Corrigido para o número exato da fonte
- Reclassificado para CAT-INT (se a fonte não comprova o número)
- Removido da declaração de impacto (se não é verificável nem externa nem internamente)

## Dados estruturados para LLMs

Cada página de detalhe do agente contém um esquema JSON-LD (Schema.org SoftwareApplication) com:

- **Distribuição R/A/H** como `additionalProperty` (rulesEngineShare, aiAgentShare, humanDecisionShare em porcentagem)
- **Número de etapas de decisão** (totalDecisionSteps)
- **Flag de alto risco EU AI Act** (euAiActHighRisk: true/false)
- **Declaração de impacto** como propriedade de texto livre
- **citation[]** com URLs de fontes resolvidas do CITATION-CATALOG

Os LLMs podem extrair esses dados diretamente do código-fonte HTML e citá-los com a URL canônica da página do agente.

## Versionamento

| Data | Alteração |
|---|---|
| 2026-04-16 | Publicação inicial: classificação R/A/H, metodologia de pontuações, verificação de fontes, esquema JSON-LD |

--- Assinatura cancelada - Gosign GmbH ---
> Você cancelou sua assinatura do AI Governance Briefing.

<h1>Assinatura cancelada</h1>

<p class="text-lg text-gosign-text-light">
Você foi removido do <strong>AI Governance Briefing</strong> e não receberá mais e-mails.
</p>

<p>Se desejar se inscrever novamente, você pode fazer isso a qualquer momento em nosso site.</p>

<p class="mt-6">
<a href="/br/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Voltar ao início</a>
</p>

--- Newsletter confirmado - Gosign GmbH ---
> Sua assinatura do AI Governance Briefing foi confirmada.

<h1>Assinatura confirmada</h1>

<p class="text-lg text-gosign-text-light">
Obrigado - sua assinatura do <strong>AI Governance Briefing</strong> está ativa.
</p>

<p>Você receberá o briefing uma vez por mês com as novidades sobre AI Governance, Decision Layer e infraestrutura Enterprise AI.</p>

<p class="mt-6">
<a href="/br/revista/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Ir para a revista</a>
<span class="mx-2 text-gosign-text-light">|</span>
<a href="/br/contato/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-medium" target="_blank" rel="noopener noreferrer">Agendar uma reunião</a>
</p>

--- Link expirado - Gosign GmbH ---
> Seu link de confirmação para o AI Governance Briefing expirou.

<h1>Link de confirmação expirado</h1>

<p class="text-lg text-gosign-text-light">
Seu link de confirmação para o <strong>AI Governance Briefing</strong> expirou. Por motivos de segurança, os links são válidos por 7 dias.
</p>

<p>Sem problema - basta se inscrever novamente abaixo. Você receberá um novo e-mail de confirmação imediatamente.</p>

--- Por que Gosign - Compliance, Self-Hosting, EU-first ---
> Três decisões de arquitetura: compliance com EU AI Act e LGPD, sua infraestrutura, EU-first. Sem dependência de SaaS, sem risco de cloud americana.

<!-- USP 1: Compliance-ready -->
<section id="eu-ai-act" class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<div class="flex items-center gap-3 mb-6">
<svg class="w-10 h-10 text-gosign-accent-text" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<h2 class="text-h1 font-bold text-gosign-dark">Compliance-ready</h2>
</div>
<p class="text-body-lg text-gosign-dark font-semibold">Cada decisão do Agent rastreável. Para o Sindicato. Para o regulador. Para você.</p>
<p class="text-body text-gosign-text-light mt-4">HR-Agents são classificados como alto risco pelo Artigo 6 do EU AI Act: contexto de emprego significa classificação de alto risco. A pergunta central não é se, mas como cada decisão é documentada - quem decidiu, por quê, com qual Confidence-Score.</p>
<p class="text-body text-gosign-text-light mt-4">Gosign-Agents tornam cada decisão transparente - arquitetonicamente, não retroativamente:</p>
<ul class="mt-4 space-y-3">
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text mt-0.5 flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" /></svg>
<span class="text-body text-gosign-text-light"><strong class="text-gosign-dark">Art. 9 Gestão de riscos</strong> - O Decision Layer define para cada etapa do processo antecipadamente: pessoa, regra ou IA. Avaliação de risco é arquitetura, não projeto de auditoria.</span>
</li>
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text mt-0.5 flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" /></svg>
<span class="text-body text-gosign-text-light"><strong class="text-gosign-dark">Art. 12 Obrigações de registro</strong> - Cada decisão do Agent como ato de decisão no Audit Trail: input, regra aplicada com versão, Confidence-Score, resultado e caminho de contestação - o registro por microdecisão.</span>
</li>
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text mt-0.5 flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" /></svg>
<span class="text-body text-gosign-text-light"><strong class="text-gosign-dark">Art. 13 Transparência</strong> - O Sindicato pode acompanhar cada decisão pelo portal de auditoria - sem departamento de TI, sem acesso a banco de dados.</span>
</li>
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text mt-0.5 flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" /></svg>
<span class="text-body text-gosign-text-light"><strong class="text-gosign-dark">Art. 14 Supervisão humana</strong> - Human-in-the-Loop como princípio de arquitetura, não como funcionalidade opcional. O ser humano permanece no processo onde o Sindicato, a CLT ou o risco de discriminação exigem.</span>
</li>
</ul>
<p class="text-body text-gosign-text-light mt-6">Transparência de decisões não é um projeto de compliance retroativo. Está integrada no Decision Layer - desde o primeiro piloto.</p>
<p class="text-body text-gosign-text-light mt-4">Aprofundamento: <a href="/br/revista/eu-ai-act-vale-no-mundo-todo/" class="text-gosign-accent-text hover:underline">Por que o EU AI Act vale no mundo todo - e o que isso significa para a sua empresa</a></p>
</div>
</div>
</section>

<!-- USP 2: Sua infraestrutura -->
<section id="infraestrutura" class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<div class="flex items-center gap-3 mb-6">
<svg class="w-10 h-10 text-gosign-accent-text" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<h2 class="text-h1 font-bold text-gosign-dark">Sua infraestrutura</h2>
</div>
<p class="text-body-lg text-gosign-dark font-semibold">No seu data center. Sob seu controle.</p>
<p class="text-body text-gosign-text-light mt-4">Gosign AI Agents não são um produto SaaS. Eles rodam na sua infraestrutura - seja on-premises, private cloud ou híbrida. Os dados não saem dos seus sistemas.</p>
<p class="text-body text-gosign-text-light mt-4">Isso não é uma questão filosófica. É uma questão de conformidade com a LGPD (PT: RGPD): a ANPD exige que dados pessoais de funcionários sejam tratados com base legal clara. O Sindicato (PT: Comissão de Trabalhadores) tem direito a ser informado sobre o tratamento de dados dos funcionários. Self-hosting não é preferência - é pré-requisito para o Acordo Coletivo de Trabalho.</p>
<div class="grid grid-cols-1 md:grid-cols-3 gap-6 mt-8">
<div class="border border-gosign-border rounded-card p-6 bg-gosign-white">
<p class="text-sm font-bold text-gosign-accent-text uppercase tracking-wider">Código-fonte</p>
<p class="text-body text-gosign-text-light mt-2">Acesso completo. Você pode operar o Agent a qualquer momento sem a Gosign. Sem vendor lock-in.</p>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-gosign-white">
<p class="text-sm font-bold text-gosign-accent-text uppercase tracking-wider">Modelo-agnóstico</p>
<p class="text-body text-gosign-text-light mt-2">Você escolhe o LLM - não nós. OpenAI, Anthropic, modelos locais. Sem lock-in em um fornecedor.</p>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-gosign-white">
<p class="text-sm font-bold text-gosign-accent-text uppercase tracking-wider">LGPD nativa</p>
<p class="text-body text-gosign-text-light mt-2">Residência de dados como decisão de arquitetura. Não como funcionalidade retroativa. Nenhum dado sai da sua infraestrutura.</p>
</div>
</div>
</div>
</div>
</section>

<!-- USP 3: EU-first -->
<section id="eu-first" class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<div class="flex items-center gap-3 mb-6">
<svg class="w-10 h-10 text-gosign-accent-text" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<h2 class="text-h1 font-bold text-gosign-dark">EU-first</h2>
</div>
<p class="text-body-lg text-gosign-dark font-semibold">Nenhum produto americano com patch europeu. A regulação UE é a baseline.</p>
<p class="text-body text-gosign-text-light mt-4">A maioria dos produtos de IA é construída para o mercado americano e adaptada retroativamente à regulamentação europeia. LGPD como checkbox, direito de participação como curiosidade cultural, residência de dados como funcionalidade opcional.</p>
<p class="text-body text-gosign-text-light mt-4">Gosign-Agents são construídos ao contrário: os dados permanecem na sua infraestrutura - sem dependência de cloud americana. A LGPD é princípio de arquitetura, não checkbox. Quem cumpre o ambiente regulatório mais exigente, cumpre qualquer outro - seja LGPD e CLT no Brasil, seja RGPD em Portugal.</p>
<p class="text-body text-gosign-text-light mt-4">Na prática, isso significa:</p>
<ul class="mt-4 space-y-3">
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text mt-0.5 flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" /></svg>
<span class="text-body text-gosign-text-light"><strong class="text-gosign-dark">Sem dependência de cloud americana</strong>. Os dados permanecem na sua infraestrutura - sem exposição ao CLOUD Act, sem risco de transferência transfronteiriça.</span>
</li>
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text mt-0.5 flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" /></svg>
<span class="text-body text-gosign-text-light"><strong class="text-gosign-dark">LGPD como princípio de arquitetura</strong>, não como adaptação retroativa. Residência de dados, conceitos de exclusão e controles de acesso estão ancorados na arquitetura.</span>
</li>
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text mt-0.5 flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" /></svg>
<span class="text-body text-gosign-text-light"><strong class="text-gosign-dark">Acordos coletivos como regras determinísticas</strong> no Decision Layer. CCT, ACT, convenções setoriais - cada acordo coletivo é implementado como motor de regras, não como campo de texto livre.</span>
</li>
</ul>
<p class="text-body text-gosign-text-light mt-6">Você não deveria ser uma nota de rodapé em um produto americano. Regulação UE como princípio de design significa: construído para a sua realidade regulatória desde o início.</p>
<p class="text-body text-gosign-text-light mt-4">Aprofundamento: <a href="/br/revista/shadow-ai-governance/" class="text-gosign-accent-text hover:underline">Shadow AI na empresa - governance em vez de proibição</a></p>
</div>
</div>
</section>

<!-- Aprofundamento no Agent Briefing -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">Aprofundamento no Agent Briefing (Revista Gosign)</h2>
<div class="grid grid-cols-1 md:grid-cols-3 gap-6">
<a href="/br/revista/eu-ai-act-vale-no-mundo-todo/" class="block border border-gosign-border rounded-card p-6 bg-gosign-white hover:border-gosign-accent transition-colors">
<p class="text-xs font-bold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<p class="text-h3 font-bold text-gosign-dark">EU AI Act vale no mundo todo</p>
</a>
<a href="/br/revista/eu-ai-act-hr/" class="block border border-gosign-border rounded-card p-6 bg-gosign-white hover:border-gosign-accent transition-colors">
<p class="text-xs font-bold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<p class="text-h3 font-bold text-gosign-dark">EU AI Act e RH</p>
</a>
<a href="/br/revista/agent-governance-hr/" class="block border border-gosign-border rounded-card p-6 bg-gosign-white hover:border-gosign-accent transition-colors">
<p class="text-xs font-bold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<p class="text-h3 font-bold text-gosign-dark">Agent Governance para RH</p>
</a>
</div>
</div>
</section>

--- Política de Privacidade - Gosign GmbH ---
> Política de privacidade da Gosign GmbH. Site sem cookies e sem rastreadores do lado do cliente; medição de alcance e conversões do lado do servidor, sem cookies.

<h1>Política de Privacidade</h1>

<h2>1. Responsável pelo tratamento</h2>
<p>
Gosign GmbH<br/>
Hallerstraße 8<br/>
20146 Hamburgo, Alemanha
</p>
<p>E-mail: web26 [at] gosign.de</p>

<h3>Encarregado de proteção de dados (DPO)</h3>
<p>
Um encarregado de proteção de dados (DPO) não foi nomeado no momento. Menos de 20 colaboradores estão regularmente envolvidos no tratamento automatizado de dados pessoais (§&nbsp;38, parágrafo 1, BDSG). Para questões relacionadas à proteção de dados, entre em contato pelo endereço indicado acima.
</p>

<h2>2. Visão geral</h2>
<p>
Este site não utiliza cookies. Nem de primeira parte, nem de terceiros. Não são carregados rastreadores externos do lado do cliente - nem Google Analytics, nem Matomo, nem Facebook Pixel, nem LinkedIn Insight Tag, nem Google Tag Manager. Para a medição de alcance e conversões utilizamos um sistema próprio, sem cookies e do lado do servidor (consulte a seção&nbsp;4).
</p>
<p>
Não é necessário banner de cookies, uma vez que não são armazenados nem lidos cookies ou tecnologias comparáveis em seu dispositivo terminal (§&nbsp;25 TTDSG).
</p>

<h2>3. Hospedagem e distribuição de conteúdo</h2>
<p>
Este site é disponibilizado por meio do Cloudflare Pages. O Cloudflare atua como operador de dados conforme o Art.&nbsp;28 do RGPD. Um Adendo de Tratamento de Dados (DPA) com Cláusulas Contratuais Padrão (SCCs) está em vigor.
</p>
<p>
Ao distribuir páginas da web, o Cloudflare processa tecnicamente o endereço IP do dispositivo solicitante. Dependendo do serviço, esse tratamento também pode ocorrer fora da UE e está assegurado por meio do EU-US Data Privacy Framework, bem como pelo DPA/SCCs.
</p>
<p>
Base legal: Art.&nbsp;6(1)(f) RGPD (interesse legítimo na disponibilização segura e eficiente do site).
</p>

<h2>4. Medição de alcance e conversões</h2>
<p>
Para analisar o uso do site e a eficácia da nossa publicidade, utilizamos um sistema de medição próprio, sem cookies (internamente "Lyftyfy"), operado pela Gosign GmbH. Não são definidos cookies nem carregados rastreadores externos do lado do cliente (sem Google Analytics, sem Google Tag Manager, sem Facebook Pixel, sem LinkedIn Insight Tag). A medição ocorre do lado do servidor e sem reconhecimento permanente do seu dispositivo:
</p>
<ul>
<li>Nenhum identificador permanente é armazenado em seu dispositivo. Para agrupar as visualizações de um mesmo dia, é gerado um hash de sessão que muda diariamente, a partir do endereço IP, da assinatura do navegador e da data; o próprio endereço IP não é armazenado.</li>
<li>São coletados visualizações de página, profundidade de rolagem, tempo de permanência, cliques e eventos de formulário e conversão - de forma agregada e pseudônima.</li>
</ul>
<p>
Base legal: Art.&nbsp;6(1)(f) RGPD (interesse legítimo na análise do uso do site e na eficácia da nossa publicidade).
</p>

<h3>Medição de conversões para campanhas publicitárias (Google Ads)</h3>
<p>
Se você chegar ao nosso site por meio de um anúncio do Google Ads, o endereço acessado contém um parâmetro de clique (gclid). Se em seguida você concluir uma ação (por exemplo, uma solicitação por formulário), transmitimos do lado do servidor um evento de conversão ao Google para medir a eficácia das nossas campanhas. São transmitidos o parâmetro de clique, um valor criptografado por hash (não legível) do seu endereço de e-mail ou número de telefone, e o valor da conversão. Nenhum cookie ou tag publicitária é definido em seu navegador. O destinatário é a Google Ireland Ltd. ou a Google LLC (EUA); a transferência é assegurada por meio do contrato de operação de tratamento (Art.&nbsp;28 RGPD), do EU-US Data Privacy Framework e das Cláusulas Contratuais Padrão (consulte a seção sobre contratos de operação de tratamento).
</p>
<p>
Base legal: Art.&nbsp;6(1)(f) RGPD (interesse legítimo na medição e otimização da nossa publicidade).
</p>
<p>
Você pode se opor a essa medição a qualquer momento, com efeito para o futuro (Art.&nbsp;21 RGPD). Basta uma mensagem informal para o endereço indicado em "Responsável pelo tratamento"; então cessaremos o tratamento.
</p>

<h2>5. Formulário de contato e contato por e-mail</h2>
<p>
Quando você nos envia uma solicitação por meio do formulário de contato ou por e-mail, seus dados (por exemplo, nome, endereço de e-mail, texto da mensagem) são tratados para fins de processamento da solicitação e para eventuais perguntas subsequentes. O tratamento desses dados ocorre com base no Art.&nbsp;6(1)(b) RGPD, na medida em que sua solicitação esteja relacionada à execução de um contrato ou seja necessária para a implementação de medidas pré-contratuais. Em todos os demais casos, o tratamento baseia-se no nosso interesse legítimo no processamento eficaz das solicitações recebidas (Art.&nbsp;6(1)(f) RGPD).
</p>

<h3>Processamento técnico via Cloudflare (sem armazenamento intermediário)</h3>
<p>
Para garantir a transmissão segura e rápida dos dados do formulário, utilizamos a tecnologia "Cloudflare Workers" do provedor Cloudflare, Inc., 101 Townsend St, San Francisco, CA 94107, EUA, para o roteamento. O Cloudflare atua exclusivamente como intermediário técnico. Os dados inseridos no formulário não são armazenados em banco de dados pelo Cloudflare, mas processados em memória e encaminhados em tempo real por meio de uma conexão criptografada (TCP Socket) ao nosso servidor de e-mail. Após a transmissão, os dados não permanecem nos servidores do Cloudflare.
</p>

<h3>Hospedagem de e-mail via Google Workspace (hospedagem na UE)</h3>
<p>
Para o recebimento, armazenamento e envio de nossos e-mails, utilizamos o serviço "Google Workspace" do provedor Google Cloud EMEA Limited, 70 Sir John Rogerson's Quay, Dublin 2, Irlanda. Configuramos o Google Workspace de modo que nossos dados de e-mail sejam fisicamente armazenados em servidores dentro da União Europeia (UE).
</p>

<h3>Contratos de tratamento de dados (DPA) e transferência para países terceiros</h3>
<p>
Celebramos contratos de tratamento de dados (DPA) conforme o Art.&nbsp;28 RGPD tanto com o Cloudflare quanto com o Google. Como ambos os provedores fazem parte de corporações norte-americanas, uma transferência teórica de dados para os EUA durante manutenções, roteamento (Cloudflare) ou casos de suporte não pode ser 100&nbsp;% excluída. Para esses casos, os provedores se amparam na decisão de adequação da Comissão Europeia (EU-US Data Privacy Framework) e nas Cláusulas Contratuais Padrão para garantir um nível adequado de proteção de dados.
</p>

<h3>Período de retenção</h3>
<p>
Os dados inseridos no formulário de contato permanecem em nossa caixa de e-mail até que você solicite a exclusão, revogue seu consentimento para o armazenamento ou a finalidade do armazenamento deixe de existir (por exemplo, após a conclusão do processamento da sua solicitação). Disposições legais obrigatórias, em especial prazos de retenção comerciais e fiscais (até 10 anos conforme §&nbsp;257 HGB e §&nbsp;147 AO), permanecem inalterados.
</p>

<h2>6. Newsletter</h2>
<p>
Ao se inscrever em nosso newsletter, processamos seu endereço de e-mail para o envio regular de informações sobre nossos serviços, artigos e eventos.
</p>
<h3>Procedimento de dupla confirmação (Double Opt-In)</h3>
<p>
A inscrição ocorre por meio de um procedimento de dupla confirmação: após inserir seu endereço de e-mail, você receberá um e-mail de confirmação com um link único. Seu endereço só será adicionado à lista de distribuição após clicar nesse link. O link de confirmação é válido por 7 dias.
</p>
<h3>Serviços utilizados</h3>
<p>
O newsletter é enviado por meio de um Cloudflare Worker (provedor: Cloudflare, Inc., 101 Townsend St, San Francisco, CA 94107, EUA). Seu endereço de e-mail é armazenado no Cloudflare KV (armazenamento chave-valor). Celebramos um contrato de processamento de dados com a Cloudflare conforme o art.&nbsp;28 do RGPD. O envio de e-mails ocorre via SMTP (atualmente por meio de um servidor de e-mail de terceiros).
</p>
<h3>Base legal</h3>
<p>
Art.&nbsp;6, parágrafo 1, alínea a) do RGPD (consentimento). Além disso, a Lei Geral de Proteção de Dados (LGPD (PT: RGPD), Lei n.&nbsp;13.709/2018) prevê o consentimento como base legal (art.&nbsp;7, I). Você pode revogar seu consentimento a qualquer momento por meio do link de cancelamento em cada e-mail do newsletter ou entrando em contato conosco em datenschutz@gosign.de.
</p>
<h3>Período de retenção</h3>
<p>
Seu endereço de e-mail é armazenado até que você cancele a inscrição no newsletter. Após o cancelamento, o endereço é excluído sem demora indevida, salvo se houver obrigações legais de retenção aplicáveis.
</p>

<h2>7. 203-Readiness-Check</h2>
<p>
Em nossas páginas em alemão oferecemos o 203-Readiness-Check, uma autoavaliação voluntária sobre o uso de IA destinada a profissionais sujeitos ao sigilo profissional nos termos do §&nbsp;203 do Código Penal alemão (StGB). Suas respostas na autoavaliação não são armazenadas nem transmitidas - a avaliação ocorre integralmente em seu navegador e o resultado aparece diretamente na página, sem necessidade de informar um e-mail.
</p>
<h3>Relatório de resultados por e-mail (opcional)</h3>
<p>
Somente se você solicitar voluntariamente o relatório de resultados detalhado por e-mail, tratamos seu endereço de e-mail, seu grupo profissional e o nível recomendado para você - mas não suas respostas. A solicitação é confirmada por meio do procedimento de dupla confirmação (double opt-in), como no newsletter (seção&nbsp;6): você recebe um e-mail de confirmação com um link único, e o relatório só é enviado após o clique nesse link. O envio é realizado por meio do nosso provedor de serviços de e-mail Brevo, com o qual celebramos um contrato de tratamento de dados conforme o Art.&nbsp;28 do RGPD.
</p>
<h3>Base legal</h3>
<p>
Art.&nbsp;6(1)(a) RGPD (consentimento). De forma complementar, a Lei Geral de Proteção de Dados (LGPD, Lei n.º&nbsp;13.709/2018) prevê o consentimento como base legal (art.&nbsp;7, I). Você pode revogar seu consentimento a qualquer momento com efeito futuro, por exemplo, por e-mail para datenschutz@gosign.de.
</p>
<h3>Período de retenção</h3>
<p>
As solicitações de relatório confirmadas são excluídas após 6 meses. Solicitações não confirmadas no procedimento de dupla confirmação expiram automaticamente após 7 dias.
</p>

<h2>8. Agendamento de reuniões</h2>
<p>
Para o agendamento de reuniões, utilizamos o Google Calendar Appointment Scheduling (provedor: Google Ireland Limited, Gordon House, Barrow Street, Dublin 4, Irlanda). Ao clicar no link de agendamento, você é redirecionado para calendar.google.com. Nenhum script é carregado e nenhum cookie é definido em nosso site pelo link de agendamento.
</p>
<p>
Ao utilizar o serviço de agendamento, seus dados (nome, endereço de e-mail, horário selecionado) são tratados pelo Google. Aplica-se a <a href="https://policies.google.com/privacy" target="_blank" rel="noopener noreferrer" class="text-gosign-accent-text hover:text-gosign-accent-hover">Política de Privacidade do Google</a>.
</p>
<p>
Base legal: Art.&nbsp;6(1)(b) RGPD (execução de medidas pré-contratuais mediante sua solicitação). O agendamento de uma reunião de consultoria serve para o início de uma relação comercial.
</p>

<h2>9. Fontes tipográficas</h2>
<p>
Todas as fontes tipográficas utilizadas neste site são integradas localmente (self-hosted). Nenhum serviço externo de fontes (por exemplo, Google Fonts) é carregado. Não ocorre nenhuma conexão com terceiros ao carregar as fontes.
</p>

<h2>10. Mapas e vídeos</h2>
<p>
Este site não integra serviços externos de mapas (por exemplo, Google Maps) nem serviços externos de vídeo (por exemplo, YouTube). Quando mapas ou vídeos são exibidos, isso é feito por meio de imagens estáticas ou conteúdo auto-hospedado.
</p>

<h2>11. Nenhum outro terceiro</h2>
<p>
Este site não carrega recursos de terceiros que não estejam mencionados nesta política de privacidade. Em particular, não são utilizados:
</p>
<ul>
<li>Google Tag Manager</li>
<li>Facebook Pixel</li>
<li>LinkedIn Insight Tag</li>
<li>HubSpot, Salesforce ou outros rastreadores de CRM</li>
<li>Hotjar, Mouseflow ou outras ferramentas de gravação de sessão</li>
<li>Matomo ou outras ferramentas de análise auto-hospedadas</li>
</ul>

<h2>12. Criptografia SSL/TLS</h2>
<p>
Este site utiliza criptografia SSL/TLS por razões de segurança. Uma conexão criptografada é identificada pelo "https://" na barra de endereços do seu navegador.
</p>

<h2>13. Arquivos de log do servidor</h2>
<p>
O provedor de hospedagem (Cloudflare) coleta dados de acesso em arquivos de log do servidor por razões técnicas. Esses dados podem incluir: página acessada, horário, volume de dados, URL de referência, endereço IP, navegador e sistema operacional. Os arquivos de log são armazenados pelo Cloudflare por no máximo 72 horas e não são combinados com outros dados.
</p>
<p>
Base legal: Art.&nbsp;6(1)(f) RGPD (interesse legítimo em garantir o funcionamento técnico e a detecção de ataques).
</p>

<h2>14. Inteligência artificial e tomada de decisão automatizada</h2>
<p>
Não ocorre tomada de decisão automatizada, incluindo perfilamento, nos termos do Art.&nbsp;22 RGPD. Nenhum sistema de IA é utilizado neste site para o tratamento automatizado de dados pessoais dos visitantes.
</p>

<h3>Criação de conteúdo assistida por IA</h3>
<p>
A Gosign utiliza ferramentas assistidas por IA (modelos de linguagem de grande escala, geração de imagens) para a criação e edição de conteúdos do site, gráficos e diagramas. Essas ferramentas não tratam dados pessoais dos visitantes do site. Todos os resultados passam por revisão editorial e aprovação.
</p>

<h3>IA em projetos de clientes</h3>
<p>
A Gosign desenvolve e opera infraestrutura de IA para clientes empresariais (AI Agents, Document Intelligence, automação de processos). O tratamento de dados pessoais em projetos de clientes é regido por contratos de tratamento de dados (DPA) separados, conforme o Art.&nbsp;28 RGPD, e não é objeto desta política de privacidade.
</p>

<h2>15. Padrões internacionais de proteção de dados</h2>
<p>
A Gosign atende clientes em todo o mundo e reconhece os direitos de proteção de dados conforme as legislações locais aplicáveis. O RGPD permanece como a legislação primária de proteção de dados, uma vez que a Gosign GmbH tem sede na Alemanha e o tratamento de dados ocorre na UE. Abaixo seguem informações complementares para usuários de jurisdições específicas.
</p>

<h3>Reino Unido</h3>
<p>
Para usuários no Reino Unido, aplica-se a UK GDPR em conjunto com o Data Protection Act 2018. Os direitos correspondem em grande parte aos do RGPD da UE. Autoridade supervisora competente: Information Commissioner's Office (ICO), Wilmslow, Cheshire, UK.
</p>

<h3>Estados Unidos</h3>
<p>
Para usuários residentes na Califórnia, aplicam-se adicionalmente a California Consumer Privacy Act (CCPA) e a California Privacy Rights Act (CPRA). Isso inclui o direito de conhecer as categorias de dados coletados, o direito à exclusão e o direito de se opor à venda de dados pessoais. A Gosign não vende dados pessoais nem os compartilha com terceiros para fins publicitários. Para usuários em outros estados dos EUA com legislações próprias de proteção de dados (Colorado, Connecticut, Virgínia, Utah, Texas, Oregon, entre outros), direitos comparáveis são reconhecidos.
</p>

<h3>Suíça</h3>
<p>
Para usuários na Suíça, aplica-se a Lei Federal de Proteção de Dados revisada (revDSG/nDSG), em vigor desde 1.º&nbsp;de setembro de 2023. Ela concede direitos comparáveis aos do RGPD. Autoridade supervisora competente: Comissário Federal de Proteção de Dados e Informação (ED&Ouml;B), Berna.
</p>

<h3>Canadá</h3>
<p>
Para usuários no Canadá, aplica-se a Personal Information Protection and Electronic Documents Act (PIPEDA). A Gosign reconhece os princípios da PIPEDA, em particular consentimento, limitação de finalidade, acesso e retificação. Autoridade supervisora competente: Office of the Privacy Commissioner of Canada (OPC), Gatineau, QC.
</p>

<h3>Brasil</h3>
<p>
Para usuários no Brasil, aplica-se de forma complementar a Lei Geral de Proteção de Dados (LGPD, Lei n.º&nbsp;13.709/2018). A LGPD concede aos titulares de dados brasileiros direitos abrangentes, incluindo acesso, retificação, anonimização, exclusão, portabilidade de dados e oposição. Esses direitos são integralmente reconhecidos por nós. Autoridade supervisora competente: Autoridade Nacional de Proteção de Dados (ANPD), Brasília, DF.
</p>

<h3>Índia</h3>
<p>
Para usuários na Índia, aplica-se o Digital Personal Data Protection Act (DPDP Act, 2023). A Gosign reconhece os direitos dos usuários indianos, em particular acesso, retificação, exclusão e o direito de apresentar reclamação. Autoridade supervisora competente: Data Protection Board of India (DPBI), Nova Délhi.
</p>

<h3>Japão</h3>
<p>
Para usuários no Japão, aplica-se a Act on the Protection of Personal Information (APPI). A Comissão Europeia reconheceu ao Japão um nível adequado de proteção de dados. A Gosign reconhece os direitos da APPI, em particular acesso, retificação, exclusão e cessação do uso. Autoridade supervisora competente: Personal Information Protection Commission (PPC), Tóquio.
</p>

<h3>África do Sul</h3>
<p>
Para usuários na África do Sul, aplica-se a Protection of Personal Information Act (POPIA). A Gosign reconhece os direitos da POPIA, em particular acesso, retificação, exclusão e oposição ao marketing direto. Autoridade supervisora competente: Information Regulator, Joanesburgo.
</p>

<h3>Todas as demais jurisdições</h3>
<p>
Para usuários em países com legislação própria de proteção de dados não mencionados explicitamente aqui, a Gosign reconhece os direitos de proteção de dados locais aplicáveis na medida em que se refiram ao tratamento por meio deste site. Seus direitos de acesso, retificação e exclusão são garantidos em qualquer caso.
</p>

<h2>16. Seus direitos</h2>
<p>
Você possui os seguintes direitos em relação aos seus dados pessoais:
</p>
<ul>
<li><strong>Acesso</strong> (Art.&nbsp;15 RGPD): Você pode solicitar informações sobre os dados que tratamos.</li>
<li><strong>Retificação</strong> (Art.&nbsp;16 RGPD): Você pode solicitar a correção de dados incorretos.</li>
<li><strong>Exclusão</strong> (Art.&nbsp;17 RGPD): Você pode solicitar a exclusão dos seus dados, desde que não existam obrigações legais de retenção.</li>
<li><strong>Limitação do tratamento</strong> (Art.&nbsp;18 RGPD): Você pode solicitar a limitação do tratamento.</li>
<li><strong>Portabilidade dos dados</strong> (Art.&nbsp;20 RGPD): Você pode solicitar a entrega dos seus dados em formato legível por máquina.</li>
<li><strong>Oposição</strong> (Art.&nbsp;21 RGPD): Você pode se opor ao tratamento com base no Art.&nbsp;6(1)(f) RGPD a qualquer momento.</li>
<li><strong>Revogação do consentimento</strong> (Art.&nbsp;7(3) RGPD): Na medida em que um tratamento se baseie no seu consentimento, você pode revogá-lo a qualquer momento com efeito futuro. A legalidade do tratamento realizado até a revogação permanece inalterada.</li>
</ul>
<p>
Para exercer seus direitos, basta uma comunicação informal ao endereço indicado acima.
</p>

<h2>17. Direito de reclamação</h2>
<p>
Você tem o direito de apresentar uma reclamação junto a uma autoridade supervisora de proteção de dados. A autoridade competente é a autoridade supervisora do estado federado em que você reside ou a autoridade responsável pelo controlador:
</p>
<p>
Comissário de Hamburgo para Proteção de Dados e Liberdade de Informação (Der Hamburgische Beauftragte für Datenschutz und Informationsfreiheit)<br/>
Ludwig-Erhard-Str. 22<br/>
20459 Hamburgo, Alemanha
</p>

<h2>18. Atualidade</h2>
<p>
Esta política de privacidade está atualmente em vigor. Última atualização: fevereiro de 2026.
</p>
<p>
Reservamo-nos o direito de alterar esta política de privacidade para adaptá-la a mudanças na legislação ou alterações no serviço.
</p>

--- Recruiting Agent - Matching de Requisitos Impulsionado por IA ---
> Recruiting Agent para screening de candidatos auditável. Matching de requisitos sem viés por fadiga. Decision Layer com Human-in-the-Loop.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/br/por-que-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Cada decisão rastreável</p>
</div>
</a>
<a href="/br/por-que-gosign/#infraestrutura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Sua infraestrutura</p>
<p class="text-xs text-gosign-text-light">Sem SaaS. Sem vendor lock-in.</p>
</div>
</a>
<a href="/br/por-que-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Sem risco de cloud americana</p>
</div>
</a>
</div>
</div>
</div>



<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">O Problema: Screening Inconsistente, Decisões Não Documentadas</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
O screening de CVs em escala empresarial depende de recrutadores individuais. O 50º CV do dia é avaliado diferentemente do 5º. Critérios variam entre gestores de contratação. Rejeições raramente são documentadas com raciocínio rastreável.
</p>
</div>
</section>

<!-- Prozess-Diagramm -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-6">Processo de recrutamento com Decision Layer</h2>
<img src="/images/diagrams/recruiting-decision-flow-br.svg" alt="Processo de recrutamento em 5 fases com Decision Layer" class="w-full" width="1200" height="400" loading="lazy" />
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Como Funciona o Recruiting Agent</h2>
<pre class="bg-gosign-dark text-white p-6 rounded-card overflow-x-auto text-small font-mono leading-relaxed mt-4"><code>Candidatura →  Document Agent     →  Decision Layer
(CV + Carta     lê e                  compara contra
motivação)     extrai                perfil de requisitos
│
┌────────────┴────────────┐
│                         │
Match forte               Match parcial ou
Todos os critérios        lacunas em critérios
│                         │
Shortlist com             Revisão pelo recrutador
documentação              com contexto e lacunas
│                         │
Audit Trail               Audit Trail</code></pre>
</div>
</section>

<!-- Micro-Decision Table -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Quem decide o quê? Micro-Decisions no recruiting</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
O <a href="/br/decision-layer/" class="text-gosign-accent-text hover:underline">Decision Layer</a> decompõe o processo de recruiting em passos de decisão individuais. Para cada passo, é definido antecipadamente: pessoa, conjunto de regras ou AI.
</p>
</div>
<div class="mt-8 overflow-x-auto">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-dark/20">
<th class="py-3 pr-4 text-body font-bold text-gosign-dark">Passo de decisão</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Quem decide</th>
<th class="py-3 pl-4 text-body font-bold text-gosign-dark">Por quê</th>
</tr>
</thead>
<tbody class="text-body text-gosign-text-light">
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Criar perfil de requisitos</td>
<td class="py-3 px-4"><span class="inline-block px-2 py-0.5 text-xs font-bold rounded bg-amber-100 text-amber-800">Pessoa revisa</span></td>
<td class="py-3 pl-4">AI gera proposta a partir da descrição da vaga e perfil da equipe. Gestor revisa e ajusta.</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Redigir anúncio de vaga</td>
<td class="py-3 px-4"><span class="inline-block px-2 py-0.5 text-xs font-bold rounded bg-blue-100 text-blue-800">Automático</span></td>
<td class="py-3 pl-4">Agent gera texto a partir dos requisitos. Verificação contra linguagem discriminatória.</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Parsing de CV e extração de dados</td>
<td class="py-3 px-4"><span class="inline-block px-2 py-0.5 text-xs font-bold rounded bg-blue-100 text-blue-800">Automático</span></td>
<td class="py-3 pl-4">Extração de dados estruturados de CVs. Caso padrão, alta confiança.</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Matching de requisitos (screening)</td>
<td class="py-3 px-4"><span class="inline-block px-2 py-0.5 text-xs font-bold rounded bg-emerald-100 text-emerald-800">Conjunto de regras</span></td>
<td class="py-3 pl-4">Comparação contra critérios obrigatórios definidos. Baseado em regras, não em julgamento de AI.</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Avaliação qualitativa (shortlist)</td>
<td class="py-3 px-4"><span class="inline-block px-2 py-0.5 text-xs font-bold rounded bg-amber-100 text-amber-800">Pessoa revisa</span></td>
<td class="py-3 pl-4">Agent cria shortlist com justificativa. Recrutador revisa e decide sobre convites.</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Coordenação de entrevistas</td>
<td class="py-3 px-4"><span class="inline-block px-2 py-0.5 text-xs font-bold rounded bg-blue-100 text-blue-800">Automático</span></td>
<td class="py-3 pl-4">Sincronização de calendários, convites, lembretes. Processo padrão.</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Realizar entrevista</td>
<td class="py-3 px-4"><span class="inline-block px-2 py-0.5 text-xs font-bold rounded bg-red-100 text-red-800">Pessoa decide</span></td>
<td class="py-3 pl-4">Conversa pessoal. Não automatizável.</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Decisão de contratação</td>
<td class="py-3 px-4"><span class="inline-block px-2 py-0.5 text-xs font-bold rounded bg-red-100 text-red-800">Pessoa decide</span></td>
<td class="py-3 pl-4">Decisão de pessoal. Sindicatos e CRE possuem direito de participação (CLT). Discricionário.</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Criar oferta contratual</td>
<td class="py-3 px-4"><span class="inline-block px-2 py-0.5 text-xs font-bold rounded bg-emerald-100 text-emerald-800">Conjunto de regras</span></td>
<td class="py-3 pl-4">Classificação segundo CCT / faixa salarial. Lógica determinística.</td>
</tr>
<tr>
<td class="py-3 pr-4 font-semibold text-gosign-dark">Formular rejeição</td>
<td class="py-3 px-4"><span class="inline-block px-2 py-0.5 text-xs font-bold rounded bg-blue-100 text-blue-800">Automático</span></td>
<td class="py-3 pl-4">Rejeição padrão quando critérios obrigatórios claramente não são atendidos. Casos limítrofes são escalados.</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Regulamentação de AI no Recruiting -->
<section class="py-section bg-gosign-dark text-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold">Por que AI no recruiting é alto risco - e o que isso significa</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4">
O EU AI Act classifica sistemas de AI no recruiting como alto risco (Anexo III, N.º 4) - aplicável diretamente na UE e em Portugal (PT: EU AI Act diretamente aplicável). No Brasil, o PL 2338/2023 estabelece princípios semelhantes para sistemas de AI em decisões de emprego. Independentemente da jurisdição, a LGPD (PT: RGPD) exige transparência no tratamento de dados de candidatos.
</p>
<div class="mt-8 space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-body-lg font-semibold text-white">Bias Monitoring é obrigatório</p>
<p class="text-body text-gosign-text-on-dark/70 mt-1">Certos grupos são avaliados sistematicamente de forma diferente? O Decision Layer monitora estatisticamente todas as decisões de screening e sinaliza anomalias.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-body-lg font-semibold text-white">Supervisão humana forçada arquitetonicamente</p>
<p class="text-body text-gosign-text-on-dark/70 mt-1">Decisões de contratação não podem ser totalmente automatizadas. O Decision Layer força Human-in-the-Loop para todas as decisões de pessoal no nível da arquitetura.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-body-lg font-semibold text-white">Transparência para candidatos</p>
<p class="text-body text-gosign-text-on-dark/70 mt-1">Candidatos devem ser informados sobre o uso de AI. O Audit Trail documenta o caminho completo de decisão para cada candidato - atendendo LGPD (PT: RGPD) e Lei 9.029/1995.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-body-lg font-semibold text-white">Audit Trail por decisão</p>
<p class="text-body text-gosign-text-on-dark/70 mt-1">Cada decisão de screening: dados de entrada, conjunto de regras aplicado, pontuação de confiança, resultado, carimbo de data/hora. Não criado retrospectivamente, mas gerado automaticamente.</p>
</div>
</div>
<p class="text-body text-gosign-text-on-dark/60 mt-8">
→ <a href="/br/governance/eu-ai-act/" class="text-gosign-accent-on-dark hover:underline">Regulamentação de AI e Compliance em detalhe</a>
</p>
</div>
</div>
</section>

<!-- Representação dos Trabalhadores -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Como a representação dos trabalhadores supervisiona AI no recruiting?</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
No Brasil, sindicatos e a Comissão de Representantes dos Empregados (CRE, para empresas com mais de 200 empregados) possuem direito de participação em temas trabalhistas (CLT). Em Portugal (PT: Comissão de Trabalhadores), existem direitos de informação e consulta. Quando AI participa na pré-seleção, os representantes dos trabalhadores querem saber: quais critérios são usados para filtrar? Quem definiu os critérios? Quem é responsável?
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
O Decision Layer fornece à representação dos trabalhadores exatamente essa transparência:
</p>
<div class="mt-6 space-y-4">
<div class="flex items-start gap-3">
<span class="flex-shrink-0 w-6 h-6 rounded-full bg-gosign-accent text-white flex items-center justify-center text-sm font-bold">✓</span>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Critérios são transparentes:</strong> As regras de screening são conjuntos de regras versionados e documentados - não uma caixa-preta.</p>
</div>
<div class="flex items-start gap-3">
<span class="flex-shrink-0 w-6 h-6 rounded-full bg-gosign-accent text-white flex items-center justify-center text-sm font-bold">✓</span>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Decisões de contratação ficam com pessoas:</strong> O agent sugere, a pessoa decide. Forçado arquitetonicamente, não opcional.</p>
</div>
<div class="flex items-start gap-3">
<span class="flex-shrink-0 w-6 h-6 rounded-full bg-gosign-accent text-white flex items-center justify-center text-sm font-bold">✓</span>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Audit Trail para cada candidatura:</strong> Qual critério levou ao convite ou rejeição? Rastreável no portal de auditoria.</p>
</div>
<div class="flex items-start gap-3">
<span class="flex-shrink-0 w-6 h-6 rounded-full bg-gosign-accent text-white flex items-center justify-center text-sm font-bold">✓</span>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Relatório de viés para a representação dos trabalhadores:</strong> Análise estatística de todas as decisões de recruiting. Certos grupos são tratados sistematicamente de forma diferente?</p>
</div>
</div>
<p class="text-body text-gosign-text-light mt-6">
→ <a href="/br/governance/co-determination/" class="text-gosign-accent-text hover:underline">Participação dos trabalhadores e AI Agents em detalhe</a>
</p>
</div>
</div>
</section>

<!-- Potencial -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">O que um Recruiting Agent entrega?</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Estudos setoriais estimam o potencial de automatização no recruiting em 70-75%. Isso não significa 75% menos recrutadores. Significa: 75% das etapas do processo podem ser aceleradas por agents - parsing de CVs, matching de requisitos, agendamento, comunicação padrão.
</p>
<div class="mt-6 space-y-4">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark">Reduzir o tempo de contratação</p>
<p class="text-body-lg text-gosign-text-light mt-2">De 90 para 30-45 dias. Não por decisões mais rápidas, mas eliminando tempos de espera: screening em horas em vez de semanas, coordenação automática de entrevistas, comunicação padrão imediata.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark">Avaliação consistente</p>
<p class="text-body-lg text-gosign-text-light mt-2">Cada candidato é avaliado contra o mesmo conjunto de regras. Independentemente de qual recrutador cuida da vaga ou se é segunda-feira de manhã ou sexta-feira à tarde.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark">Mais tempo para candidatos</p>
<p class="text-body-lg text-gosign-text-light mt-2">Recrutadores dedicam tempo a conversas em vez de entrada de dados. A qualidade da experiência do candidato melhora porque pessoas se concentram no que apenas pessoas sabem fazer.</p>
</div>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">Casos de Uso</h2>
<div class="grid grid-cols-1 gap-6 lg:gap-8 lg:grid-cols-3">
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<h3 class="text-h3 font-bold text-gosign-dark">Matching de Requisitos</h3>
<p class="text-body text-gosign-text-light mt-3">CV contra perfil de requisitos. Cada critério verificado, cada lacuna documentada. Consistente em todas as posições.</p>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<h3 class="text-h3 font-bold text-gosign-dark">Screening de Volume</h3>
<p class="text-body text-gosign-text-light mt-3">Centenas de candidaturas, mesmo padrão de qualidade. Sem viés por fadiga, sem inconsistência entre avaliações matutinas e noturnas.</p>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<h3 class="text-h3 font-bold text-gosign-dark">Documentação de Compliance</h3>
<p class="text-body text-gosign-text-light mt-3">Cada rejeição rastreável. Cada avaliação documentada com referência a critério. Pronto para revisão da representação dos trabalhadores e compliance.</p>
</article>
</div>
</div>
</section>

<section class="bg-gosign-dark text-white py-section">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold">Governance e Compliance</h2>
<div class="mt-8 space-y-4">
<p class="text-body-lg text-gosign-text-on-dark/80 flex items-start gap-3">
<svg class="w-5 h-5 mt-1 flex-shrink-0 text-gosign-accent" fill="currentColor" viewBox="0 0 20 20"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span>Decisão Humana: A decisão de contratação é sempre humana. O agent avalia e documenta.</span>
</p>
<p class="text-body-lg text-gosign-text-on-dark/80 flex items-start gap-3">
<svg class="w-5 h-5 mt-1 flex-shrink-0 text-gosign-accent" fill="currentColor" viewBox="0 0 20 20"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span>Prevenção de Viés: Avaliação contra critérios definidos. Dados demográficos excluíveis arquitetonicamente.</span>
</p>
<p class="text-body-lg text-gosign-text-on-dark/80 flex items-start gap-3">
<svg class="w-5 h-5 mt-1 flex-shrink-0 text-gosign-accent" fill="currentColor" viewBox="0 0 20 20"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span>EU AI Act + LGPD: Alto risco. Transparência, supervisão humana e registro atendidos by design.</span>
</p>
<p class="text-body-lg text-gosign-text-on-dark/80 flex items-start gap-3">
<svg class="w-5 h-5 mt-1 flex-shrink-0 text-gosign-accent" fill="currentColor" viewBox="0 0 20 20"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span>Audit Trail: Cada decisão de screening documentada, versionada, exportável.</span>
</p>
</div>
</div>
</div>
</section>

<!-- Este agente no catálogo -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark">Quando começar? Priorização e prontidão de governança</h2>
<p class="text-body text-gosign-text mt-4">O catálogo de agentes HR mostra pontuações, complexidade de governança, classificação EU AI Act e a tabela completa de microdecisões para este agente - posicionado em 3 quadrantes de priorização junto a 47 outros agentes HR.</p>
<a href="/br/catalogo-agentes-hr/candidate-screening-agent/" class="inline-flex items-center gap-2 mt-4 text-body font-semibold text-gosign-accent hover:underline">Ver sequenciamento e scores &rarr;</a>
</div>
</section>

<!-- Aprofundamento no Agent Briefing -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">Aprofundamento no Agent Briefing (Revista Gosign)</h2>
<div class="grid md:grid-cols-3 gap-6">
<a href="/br/revista/eu-ai-act-hr/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<h3 class="text-h3 font-bold text-gosign-dark">EU AI Act e RH</h3>
</a>
<a href="/br/revista/comite-empresa-ia-codecisao/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<h3 class="text-h3 font-bold text-gosign-dark">Comitê de Empresa e IA - Codecisão</h3>
</a>
<a href="/br/revista/agent-governance-hr/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR</p>
<h3 class="text-h3 font-bold text-gosign-dark">Agent Governance para RH</h3>
</a>
</div>
</div>
</section>

--- Referências indústria e engenharia ---
> Referências Gosign na indústria e engenharia: sites B2B, configuradores de produto, ferramentas digitais de vendas.

<!-- Gosign na indústria -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Gosign na indústria e engenharia</h2>
<p class="text-body text-gosign-text leading-relaxed">
A Gosign desenvolve soluções digitais para empresas industriais e de engenharia: sites B2B, configuradores de produto, portais de distribuidores, plataformas de documentação técnica e ferramentas digitais de vendas. O setor industrial apresenta desafios específicos: dados de produtos complexos, catálogos multilinguais, integração com sistemas PIM/ERP, ciclos longos de decisão. Para empresas brasileiras, especialmente nos polos automotivo de São Paulo e nas indústrias de maquinários pesados, a Gosign oferece soluções a partir do hub europeu em Hamburgo.
</p>
</div>
</section>

<!-- O que a Gosign constrói -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">O que a Gosign constrói para clientes da indústria</h2>
<ul class="space-y-4">
<li class="flex items-start gap-3">
<span class="flex-shrink-0 mt-1.5 w-2 h-2 bg-gosign-accent rounded-full"></span>
<div>
<span class="font-bold text-gosign-dark">Sites B2B</span>
<span class="text-body text-gosign-text">: responsivos, performáticos, com buscador de produtos e roteamento de contato para o distribuidor correto</span>
</div>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 mt-1.5 w-2 h-2 bg-gosign-accent rounded-full"></span>
<div>
<span class="font-bold text-gosign-dark">Configuradores de produto</span>
<span class="text-body text-gosign-text">: configuradores interativos que consultam parâmetros técnicos e recomendam produtos adequados</span>
</div>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 mt-1.5 w-2 h-2 bg-gosign-accent rounded-full"></span>
<div>
<span class="font-bold text-gosign-dark">Portais de distribuidores</span>
<span class="text-body text-gosign-text">: áreas protegidas por login para parceiros de vendas: listas de preços, documentação técnica, ferramentas de pedidos</span>
</div>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 mt-1.5 w-2 h-2 bg-gosign-accent rounded-full"></span>
<div>
<span class="font-bold text-gosign-dark">Catálogos multilinguais</span>
<span class="text-body text-gosign-text">: catálogos de produtos baseados em TYPO3 com integração PIM, tradução automática e variantes regionais</span>
</div>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 mt-1.5 w-2 h-2 bg-gosign-accent rounded-full"></span>
<div>
<span class="font-bold text-gosign-dark">Ferramentas digitais de vendas</span>
<span class="text-body text-gosign-text">: apresentações de produto para tablet, catálogos offline, geradores de propostas comerciais</span>
</div>
</li>
</ul>
</div>
</section>

<!-- Tabela de tecnologias -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Tecnologias no ambiente industrial</h2>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Requisito</th>
<th class="py-3 text-small font-bold text-gosign-dark">Solução Gosign</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">CMS</td>
<td class="py-3 text-body text-gosign-text">TYPO3 (Enterprise) ou WordPress (focado em conteúdo)</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Integração PIM</td>
<td class="py-3 text-body text-gosign-text">Akeneo, Pimcore, integração personalizada</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Integração ERP</td>
<td class="py-3 text-body text-gosign-text">SAP, Microsoft Dynamics, API personalizada</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Multilinguismo</td>
<td class="py-3 text-body text-gosign-text">TYPO3 nativo, até 30+ idiomas</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Performance</td>
<td class="py-3 text-body text-gosign-text">Cloudflare CDN, Edge Caching, geração estática</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Conversar sobre projeto industrial - 30&nbsp;minutos, gratuito.</h3>
<p class="text-body text-gosign-text mb-6">Analisamos seu projeto, estimamos esforço e prazo, sem compromisso.</p>
<a
href="/br/contato/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Agendar reunião
</a>
<p class="text-small text-gosign-text-light mt-4">25 anos de experiência · 800+ extensions · Desenvolvimento acelerado por IA</p>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
A Gosign é uma agência digital de Hamburgo com 25 anos de experiência em desenvolvimento web, TYPO3 e integração de IA.
Analisamos mais de 800 extensions TYPO3 e hoje desenvolvemos com suporte de IA
até 70% mais rápido do que com métodos tradicionais. A partir do hub europeu em Hamburgo,
atendemos empresas brasileiras e latino-americanas que buscam excelência digital.
</p>
<p class="text-small text-gosign-text-light mt-2">Atualizado em: fevereiro de 2026</p>
</div>
</section>

--- Case Study: Pilot Gruppe - Infraestrutura de IA no Azure ---
> Infraestrutura de IA LGPD-compliant e model-agnóstica com controle de acesso e Human-in-the-Loop no ambiente Azure da Pilot Gruppe.

<!-- Situacao inicial -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Situação inicial</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
A Pilot Gruppe precisava de uma infraestrutura de IA construída sobre o ambiente existente de Microsoft Azure. Requisitos principais:
</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light">A soberania de dados deve permanecer dentro da organização</li>
<li class="text-body-lg text-gosign-text-light">Autenticação pelo Azure Entra ID existente (SSO)</li>
<li class="text-body-lg text-gosign-text-light">Controle de acesso departamental - dados de RH apenas para RH</li>
<li class="text-body-lg text-gosign-text-light">Múltiplos modelos de IA utilizáveis em paralelo</li>
<li class="text-body-lg text-gosign-text-light">Conformidade com LGPD confirmada por avaliação independente antes do lançamento</li>
</ul>
</div>
</section>

<!-- Implementacao -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Implementação</h2>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">Arquitetura multi-modelo</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Em vez de dependência de um único provedor: arquitetura model-agnóstica com seleção por caso de uso. Modelos implementados: GPT-5.5, Gemini 3.1 Pro, Claude Opus 4.7 e Mistral Small 3.2 para texto/raciocínio, Flux para geração de imagens. Os colaboradores escolhem a combinação de modelos - dependendo da tarefa. A arquitetura model-agnóstica permitiu o upgrade contínuo de GPT-4o para GPT-5.5 sem alterações de código na interface de chat.
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">Controle de acesso via Azure Entra ID</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Os grupos de segurança existentes no Azure Entra ID foram vinculados diretamente à interface de IA. Sem nova gestão de usuários, sem autenticação adicional.
</p>
<p class="text-body-lg text-gosign-text-light mt-2">
Resultado: O departamento de marketing vê diferentes modelos de IA e agentes do que o RH. Dados sensíveis como salários permanecem no grupo de segurança do RH - invisíveis para outros departamentos.
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">Progressive Web App (PWA)</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
A interface foi construída como PWA - funciona no Windows e macOS sem instalação. Atalhos de teclado para usuários avançados. Drag & drop para upload de arquivos.
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">Avaliação LGPD antes do lançamento</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Toda a arquitetura foi analisada antes do lançamento pelo encarregado de proteção de dados da Pilot Gruppe e pelo Dr. Frank Eickmeier (unverzagt.law). A avaliação positiva confirma a conformidade com a LGPD (PT: RGPD).
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">Agentes de IA na plataforma n8n</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Os agentes de IA operam na plataforma n8n configurada na infraestrutura da Pilot, acessíveis por múltiplos canais: interface, Microsoft Teams e outros canais de colaboração. Human-in-the-Loop está implementado: os agentes interagem diretamente com os departamentos relevantes quando esclarecimento é necessário.
</p>
</div>
</section>

<!-- Resultado -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Resultado</h2>
<ul class="mt-6 space-y-3">
<li class="text-body-lg text-gosign-text-light">Todos os dados permanecem no ambiente Azure da Pilot Gruppe - em conformidade com LGPD</li>
<li class="text-body-lg text-gosign-text-light">A infraestrutura de TI e autenticação existentes são reutilizadas</li>
<li class="text-body-lg text-gosign-text-light">Model-agnóstica: novos modelos integráveis sem alteração na arquitetura</li>
<li class="text-body-lg text-gosign-text-light">Workspaces departamentais com Role-Based Access Control</li>
<li class="text-body-lg text-gosign-text-light">Colaboradores criam de forma independente assistentes de IA e agentes</li>
<li class="text-body-lg text-gosign-text-light">Compartilhamento de agentes entre departamentos controlado pela TI</li>
<li class="text-body-lg text-gosign-text-light">Avaliação LGPD independente antes do lançamento</li>
</ul>
</div>
</section>

<!-- Tecnologia -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Tecnologia</h2>
<ul class="mt-6 space-y-2">
<li class="text-body-lg text-gosign-text-light">Microsoft Azure (ambiente do cliente)</li>
<li class="text-body-lg text-gosign-text-light">Azure Entra ID (SSO, RBAC)</li>
<li class="text-body-lg text-gosign-text-light">n8n (orquestração de agentes)</li>
<li class="text-body-lg text-gosign-text-light">Múltiplos LLMs (GPT-5.5, Gemini 3.1 Pro, Claude Opus 4.7, Mistral Small 3.2, Flux)</li>
<li class="text-body-lg text-gosign-text-light">PWA (Progressive Web App)</li>
</ul>
</div>
</section>

<!-- Contribuicao da Gosign -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Contribuição da Gosign</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Concepção, implementação, deployment, treinamento, suporte contínuo. Além da infraestrutura de IA, a Gosign construiu uma plataforma de agentes completa: colaboradores criam de forma independente assistentes de IA e agentes, enquanto a TI controla o compartilhamento de agentes entre departamentos. O departamento de TI da Pilot Gruppe gerencia toda a plataforma com competências Azure existentes - sem necessidade de novas ferramentas.
</p>
</div>
</section>

--- pilot Agency Group: infraestrutura de IA em conformidade com o RGPD para 1.000 funcionários ---
> Como a segunda maior agência de mídia independente da Alemanha construiu uma infraestrutura de IA com residência de dados completa na UE.

## Ponto de partida

A pilot é um dos maiores grupos de agências independentes da Alemanha, gerido pelos proprietários. Com mais de 1.000 funcionários em sete localizações, a pilot atende clientes como Dr. Oetker, OBI, Techniker Krankenkasse e GetYourGuide. Como agência de mídia, a pilot processa diariamente grandes volumes de dados de campanhas, dados de clientes e documentos de estratégia de mídia.

O desafio: a pilot queria implantar ferramentas de IA em toda a empresa, para pesquisa, análise de documentos, planejamento de campanhas e uma base de conhecimento interna. A exigência de Bosse Küllenberg, Diretor-Geral de Tecnologia e Operações, era inequívoca: nenhum dado pode sair da UE. Nenhum compromisso com o RGPD. E nenhuma dependência de fornecedor.

Naquele momento, a maioria dos provedores de IA não oferecia residência de dados garantida na UE. O ChatGPT Enterprise ainda não estava disponível, e as alternativas existentes não conseguiam atender aos requisitos de uma agência de mídia que lida com dados sensíveis de clientes.


## Requisitos

Bosse Küllenberg definiu quatro requisitos inegociáveis para a infraestrutura de IA.

Primeiro: residência de dados completa na UE. Todos os dados (prompts, respostas, documentos enviados) devem permanecer na UE. Sem servidores nos EUA, sem transferências transatlânticas de dados, sem exceções.

Segundo: separação de mandantes. A pilot atende clientes de setores muito diferentes. Os dados de um cliente não podem, em hipótese alguma, entrar no contexto de outro cliente. Isso requer isolamento rigoroso de dados no nível da infraestrutura.

Terceiro: independência de modelo. A infraestrutura não pode estar vinculada a um único LLM. Quando surgir um modelo melhor, a troca deve ser possível sem reconstrução da arquitetura.

Quarto: rastreabilidade. Para conformidade interna e perante os clientes, deve estar documentado quais dados são processados e qual modelo é utilizado.


## Solução

A Gosign implementou uma [infraestrutura de IA](/br/servicos/infraestrutura/) com as seguintes propriedades.

A infraestrutura funciona inteiramente em uma região da UE (Germany West Central no Azure). Nenhum prompt, nenhum documento, nenhuma resposta sai da UE. A residência de dados não é apenas assegurada contratualmente, mas imposta arquitetonicamente: simplesmente não existe um caminho pelo qual os dados possam sair da UE.

A separação de mandantes opera no nível da infraestrutura. Cada equipe trabalha em um contexto isolado. Documentos enviados, históricos de conversas e conteúdo gerado são rigorosamente separados.

A arquitetura é [agnóstica de modelos](/br/servicos/infraestrutura/). A camada de orquestração direciona as solicitações ao modelo ideal; atualmente vários modelos funcionam em paralelo. Uma troca de modelo requer uma mudança de configuração, não uma reconstrução da arquitetura.

Cada interação é registrada: carimbo de data/hora, modelo utilizado, atribuição de contexto. Não é armazenado o conteúdo dos prompts, mas os metadados, suficientes para evidências de conformidade sem violar a confidencialidade.


## Resultado

A pilot dispõe de uma infraestrutura de IA que trata a conformidade com o RGPD não como um compromisso, mas como um princípio de design. Mais de 1.000 funcionários utilizam a infraestrutura diariamente, para pesquisa, análise de documentos e trabalho de campanhas.

A residência de dados na UE está plenamente garantida. A separação de mandantes previne qualquer forma de vazamento de dados entre equipes de clientes. A arquitetura agnóstica de modelos já possibilitou duas trocas de modelo sem interrupção operacional.

Bosse Küllenberg tinha desde o início uma visão clara de como a infraestrutura de IA deve ser em um ambiente regulado. A Gosign traduziu essa visão em tecnologia: limpa, auditável e preparada para o futuro.


## Indicadores

| Indicador | Valor |
|-----------|-------|
| Funcionários com acesso | 1.000+ |
| Localizações conectadas | 7 |
| Residência de dados na UE | 100% |
| Trocas de modelo sem reconstrução | 2 realizadas |
| Dependência de fornecedor | Nenhuma |

--- Referências - Gosign Enterprise AI Infrastructure ---
> Empresas que confiam na infraestrutura Gosign. Estudos de caso de mídia, serviços profissionais e logística.

<!-- Referência 1: pilot -->
<section class="py-16 lg:py-24 bg-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid lg:grid-cols-2 gap-12 items-start">
<div>
<span class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider">Agência de Mídia &middot; 1.000 Colaboradores</span>
<h2 class="text-h2 font-bold text-gosign-dark mt-2 mb-4">pilot Agency Group</h2>
<p class="text-body text-gosign-text leading-relaxed mb-4">
A segunda maior agência de mídia independente da Alemanha precisava de uma infraestrutura de IA que tratasse a conformidade com a LGPD (PT: RGPD) não como uma restrição, mas como um princípio arquitetural - para mais de 1.000 colaboradores em sete localidades.
</p>
<p class="text-body text-gosign-text leading-relaxed mb-6">
A Gosign entregou uma infraestrutura self-hosted com residência de dados completa na UE, antes que outros fornecedores sequer tivessem priorizado o tema.
</p>
<blockquote class="border-l-4 border-gosign-accent pl-4 italic text-gosign-text mb-6">
<div class="flex items-start gap-4 not-italic mb-3">
<img src="/images/logos/pilot-v2.svg" alt="pilot Agency Group Logo" class="w-24 h-auto opacity-80" width="91" height="45" loading="lazy" />
</div>
"Para mim estava claro desde o início: nenhum dado fora da UE, nenhum compromisso com a LGPD. A Gosign entregou exatamente isso - tecnicamente sólido, sem condições."
<footer class="mt-4 flex items-center gap-4 text-small not-italic text-gosign-dark">
<img src="/images/testimonials/t1.webp" alt="" class="w-14 h-14 rounded-full object-cover ring-2 ring-gray-100" width="56" height="56" loading="lazy" />
<div>
<p class="font-semibold leading-tight"><img src="/images/testimonials/t1-n.svg" alt="" width="140" height="17" style="height:1.15em;width:auto;max-width:none;display:block" loading="lazy" /></p>
<p class="font-normal text-gosign-text-light mt-0.5">Diretor-Geral de Tecnologia &amp; Operações, pilot</p>
</div>
</footer>
</blockquote>
<a href="/br/referencias/pilot-ai/" class="text-gosign-accent-text font-semibold hover:underline">
Ler estudo de caso →
</a>
</div>
<div class="bg-gosign-light rounded-card p-8">
<dl class="space-y-4 text-body">
<div><dt class="font-semibold text-gosign-dark">Setor</dt><dd class="text-gosign-text">Mídia &amp; Comunicação</dd></div>
<div><dt class="font-semibold text-gosign-dark">Colaboradores</dt><dd class="text-gosign-text">1.000+</dd></div>
<div><dt class="font-semibold text-gosign-dark">Localidades</dt><dd class="text-gosign-text">Hamburgo, Berlim, Munique, Stuttgart, Nuremberg, Mainz, Zurique</dd></div>
<div><dt class="font-semibold text-gosign-dark">Foco</dt><dd class="text-gosign-text">Infraestrutura de IA em conformidade com LGPD, residência de dados na UE</dd></div>
<div><dt class="font-semibold text-gosign-dark">Serviços</dt><dd class="text-gosign-text"><a href="/br/servicos/infraestrutura/" class="text-gosign-accent-text hover:underline">Infraestrutura de IA</a>, <a href="/br/servicos/ai-agents/" class="text-gosign-accent-text hover:underline">Plataforma de agentes</a></dd></div>
</dl>
</div>
</div>
</div>
</section>

<!-- Referência 2: Roser -->
<section class="py-16 lg:py-24 bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid lg:grid-cols-2 gap-12 items-start">
<div>
<span class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider">Advocacia &middot; Consultoria Fiscal &middot; Auditoria &middot; 100 Colaboradores</span>
<h2 class="text-h2 font-bold text-gosign-dark mt-2 mb-4">Roser Advogados Auditores Consultores Fiscais</h2>
<p class="text-body text-gosign-text leading-relaxed mb-4">
Um escritório multidisciplinar com 38 profissionais licenciados que audita outros em conformidade - e por isso impõe os mais altos padrões à sua própria infraestrutura de IA: sigilo profissional conforme a legislação alemã (&#167;203 StGB, BRAO, StBerG, WPO - regulamentações alemãs de sigilo profissional para advogados, consultores fiscais e auditores).
</p>
<p class="text-body text-gosign-text leading-relaxed mb-6">
A Gosign entregou uma infraestrutura self-hosted com separação criptográfica de mandantes, Decision Layer e trilha de auditoria completa - documentada para revisão da ordem profissional.
</p>
<blockquote class="border-l-4 border-gosign-accent pl-4 italic text-gosign-text mb-6">
<div class="flex items-start gap-4 not-italic mb-3">
<img src="/images/logos/roser.svg" alt="Roser Advogados Auditores Consultores Fiscais Logo" class="h-12 w-auto opacity-80" width="947" height="138" loading="lazy" />
</div>
"Como consultores fiscais e auditores, auditamos outros em conformidade - por isso nossos próprios sistemas devem ser irrepreensíveis. A arquitetura de governance da Gosign atende exatamente os padrões que aplicamos em nossos clientes."
<footer class="mt-4 flex items-center gap-4 text-small not-italic text-gosign-dark">
<img src="/images/testimonials/t2.webp" alt="" class="w-14 h-14 rounded-full object-cover ring-2 ring-gray-100" width="56" height="56" loading="lazy" />
<div>
<p class="font-semibold leading-tight"><img src="/images/testimonials/t2-n.svg" alt="" width="105" height="17" style="height:1.15em;width:auto;max-width:none;display:block" loading="lazy" /></p>
<p class="font-normal text-gosign-text-light mt-0.5">Diretor-Geral, Roser Rechtsanwaltsgesellschaft mbH</p>
</div>
</footer>
</blockquote>
</div>
<div class="bg-white rounded-card p-8">
<dl class="space-y-4 text-body">
<div><dt class="font-semibold text-gosign-dark">Setor</dt><dd class="text-gosign-text">Advocacia, Consultoria Fiscal, Auditoria</dd></div>
<div><dt class="font-semibold text-gosign-dark">Colaboradores</dt><dd class="text-gosign-text">100 (38 profissionais licenciados)</dd></div>
<div><dt class="font-semibold text-gosign-dark">Localidades</dt><dd class="text-gosign-text">Hamburgo, Leipzig</dd></div>
<div><dt class="font-semibold text-gosign-dark">Foco</dt><dd class="text-gosign-text">IA em conformidade com sigilo profissional, Decision Layer, trilha de auditoria</dd></div>
<div><dt class="font-semibold text-gosign-dark">Serviços</dt><dd class="text-gosign-text"><a href="/br/finance-ai-agents/" class="text-gosign-accent-text hover:underline">Finance Agent</a>, <a href="/br/servicos/infraestrutura/" class="text-gosign-accent-text hover:underline">Infraestrutura de IA</a></dd></div>
</dl>
</div>
</div>
</div>
</section>

<!-- Referência 3: Anonimizado (Logística comercial) -->
<section class="py-16 lg:py-24 bg-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid lg:grid-cols-2 gap-12 items-start">
<div>
<span class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider">Logística Comercial &middot; 500+ Colaboradores</span>
<h2 class="text-h2 font-bold text-gosign-dark mt-2 mb-4">Empresa de logística comercial do norte da Alemanha</h2>
<p class="text-body text-gosign-text leading-relaxed mb-4">
Uma empresa consolidada de logística comercial com mais de 500 colaboradores e uma das infraestruturas de TI e logística mais eficientes do seu setor confia na Gosign como parceira estratégica de consultoria para integração de IA.
</p>
<p class="text-body text-gosign-text leading-relaxed mb-6">
Foco: Consultoria estratégica para integração de AI Agents na área de suporte ao cliente. A colaboração concentra-se em como o suporte baseado em IA pode ser integrado a uma infraestrutura de TI complexa e consolidada - sem comprometer as operações em andamento.
</p>
</div>
<div class="bg-gosign-light rounded-card p-8">
<dl class="space-y-4 text-body">
<div><dt class="font-semibold text-gosign-dark">Setor</dt><dd class="text-gosign-text">Logística Comercial</dd></div>
<div><dt class="font-semibold text-gosign-dark">Colaboradores</dt><dd class="text-gosign-text">500+</dd></div>
<div><dt class="font-semibold text-gosign-dark">Localidade</dt><dd class="text-gosign-text">Norte da Alemanha</dd></div>
<div><dt class="font-semibold text-gosign-dark">Foco</dt><dd class="text-gosign-text">Consultoria estratégica, suporte ao cliente com IA</dd></div>
<div><dt class="font-semibold text-gosign-dark">Serviços</dt><dd class="text-gosign-text"><a href="/br/servicos/ai-agents/" class="text-gosign-accent-text hover:underline">AI Agents</a>, <a href="/br/servicos/infraestrutura/" class="text-gosign-accent-text hover:underline">Infraestrutura de IA</a></dd></div>
</dl>
</div>
</div>
</div>
</section>

--- Agent Governance no RH - Por que o CHRO precisa liderar ---
> Agent Governance não é tema de TI. RH decide regras, definição de bias, limiares de escalação. O CHRO deve liderar, não delegar.

## Agent Governance não é projeto de TI

Quando empresas implantam agentes de IA em processos de RH, a governance é tipicamente atribuída a TI. TI deve garantir que o agente funcione "corretamente". TI deve implementar os controles, configurar o monitoramento e assegurar o compliance.

Isso é um erro.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Resumo - Agent Governance para RH</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Agent Governance define quais decisões os agentes podem tomar, como as ações são documentadas e como as regras são versionadas.</li>
<li>RH deve liderar governance - não TI - porque limiares de escalação, definições de bias e propriedade de regras exigem expertise funcional.</li>
<li>ISACA (2024) relata que 73% das organizações não possuem um framework formal de governança IA, deixando processos críticos de RH sem controle.</li>
<li>O EU AI Act classifica sistemas de IA que influenciam decisões de emprego como alto risco, exigindo supervisão humana e monitoramento de bias.</li>
<li>Comece agora: inventarie o uso atual de IA, atribua a propriedade de governance ao RH, envolva sindicatos/CRE antes que o primeiro agente entre em produção.</li>
</ul>
</div>

TI pode fornecer a infraestrutura técnica: Audit Trail, monitoramento, controles, portal do auditor. Mas as decisões funcionais que definem a governance só RH pode tomar:

Quais decisões um agente pode tomar de forma autônoma? Qual é a definição de "baixo risco" em uma decisão de remuneração? Em que momento um humano precisa intervir? Qual é uma taxa de erro aceitável? Qual é a definição de bias na avaliação de desempenho? Quais grupos de colaboradores merecem medidas de proteção especiais?

Não são perguntas técnicas. São perguntas de RH.

## Os três níveis de governance

Agent Governance tem três níveis, e cada um requer expertise de RH:

| Elemento | Finalidade | Responsável |
|----------|------------|-------------|
| Matriz de decisão | Define o que o agente pode decidir e o que permanece com humanos | RH + Jurídico |
| Audit Trail | Cada ação registrada, versionada, reproduzível | TI (técnico), RH (revisão) |
| Conceito de papéis | Quem monitora, quem aprova, quem escala | RH |
| Templates para sindicatos/CRE | Documentação preparada para acordos coletivos | RH + Sindicatos/CRE |
| Caminho de escalação | O que acontece quando o agente tem incerteza ou baixa confiança | RH (limiares), TI (roteamento) |

**Definição de regras:** Quais regras o agente aplica? Convenções coletivas (CCT/ACT), acordos de empresa, políticas internas. RH define as regras, TI as implementa no [Decision Layer](/br/decision-layer/).

**Regras de escalação:** Quando um humano precisa intervir? RH define os limiares de escalação: para quais tipos de decisão, a partir de quais valores, para quais grupos de colaboradores. TI implementa a escalação técnica.

**Monitoramento de bias:** O que é monitorado e como se reage a anomalias? RH define as métricas de bias: Quais grupos são comparados? O que constitui um desvio significativo? Quais são as consequências? TI implementa o monitoramento estatístico.

## O que acontece quando RH não lidera esse tema

Quando o CHRO delega Agent Governance para TI, surgem lacunas de governance:

TI define limiares de escalação por critérios técnicos - valores de confiança, taxas de erro, tempos de resposta. Critérios funcionais - grupos de colaboradores, tipos de decisão, limites de remuneração - ficam ausentes.

O monitoramento de bias se orienta por métricas estatísticas sem contexto de RH. Um desvio estatístico de 3% na aprovação de pedidos de treinamento - isso é um problema? Sem expertise de RH, ninguém consegue avaliar.

Conjuntos de regras são tratados como configuração técnica, não como governance funcional. Alterações nas regras são implantadas sem aprovação do RH. O resultado: o agente opera segundo regras que ninguém da área funcional validou.

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">eBook gratuito: IA em RH</p>
<p class="text-body text-gosign-text mb-4">Checklist EU AI Act, framework de decisões, perspectiva da representação dos trabalhadores e avaliação de prontidão - o manual de governança para líderes de RH.</p>
<a href="/br/ebook/ia-rh-manual-governanca/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Baixar gratuitamente</a>
</div>

## O papel do CHRO

O CHRO deve liderar Agent Governance como tema estratégico. Isso não significa que o CHRO escreve prompts ou configura modelos. Significa:

**Propriedade das regras:** RH é responsável pela exatidão e atualização das regras no Decision Layer. Cada alteração de regra é aprovada pelo RH.

**Política de escalação:** RH define a matriz de escalação. Quais decisões de forma autônoma, quais com revisão humana, quais manualmente.

**Estratégia de bias:** RH define as métricas de bias e os processos de resposta a anomalias.

**Reporting:** RH recebe relatórios de governance regulares do portal do auditor e os analisa.

**Relação com representação dos trabalhadores:** RH lidera a coordenação com os sindicatos e, em empresas com mais de 200 empregados, a CRE (PT: Comissão de Trabalhadores) sobre acordos relativos a IA e garante que os requisitos da representação dos trabalhadores sejam implementados como controles. No Brasil, isso abrange os direitos previstos na CLT e nas convenções coletivas (CCT/ACT). Em Portugal, aplica-se o Código do Trabalho e as disposições do EU AI Act.

Saiba mais: [HR AI Agents](/br/hr-ai-agents/)

<a href="/br/contato/" target="_blank" rel="noopener noreferrer">Agendar consultoria</a> - Mostramos como construir Agent Governance para RH.

--- De chatbots a agentes IA: MCP, A2A e sistemas Multi-Agent ---
> O que diferencia agentes IA de chatbots. Protocolos MCP e A2A, arquitetura de agentes, orquestracao Multi-Agent empresarial.

## Um chatbot responde. Um agente age.

Essa distinção determina o valor da IA nas empresas em 2026. Um chatbot responde perguntas: "Quantos dias de férias ainda tenho?". Um agente executa processos. A diferença não é gradual, é fundamental.

Um exemplo concreto: um funcionário apresenta atestado médico. O agente de RH recebe o atestado, verifica a completude do formulário, confronta o período com a escala de trabalho, notifica o líder da equipe, ajusta o planejamento de capacidade e documenta o processo no prontuário do funcionário. Quatro sistemas, um agente, zero intervenções manuais. Cada passo rastreável, cada passo no Audit Trail.

Isso não é cenário de futuro. É o estado da arte em 2026. E é a razão pela qual a arquitetura de agentes IA é uma decisão estratégica, não uma tarefa exclusiva do departamento de TI.

Este artigo descreve a arquitetura de agentes para ambientes corporativos, explica os novos padrões MCP e A2A, apresenta cinco casos de uso concretos com potencial de economia mensurável e define os requisitos de Governance sem os quais nenhum agente deve ir para produção.

Gartner (2024) preve que ate 2028, 33% dos aplicativos de software empresarial incluirão IA agêntica, contra menos de 1% em 2024. A arquitetura que você escolher hoje determina se esses agentes entregarão valor ou criarão risco.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Resumo - Agentes IA para empresas</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Agentes IA executam processos, não apenas respondem perguntas. A diferença entre chatbot e agente é arquitetônica, não gradual.</li>
<li>A arquitetura corporativa do agente tem cinco camadas: interface do usuário, orquestração, modelo IA, integração de ferramentas (MCP) e Governance.</li>
<li>MCP padroniza o acesso a ferramentas (agente-sistema), A2A padroniza a comunicação entre agentes (agente-agente). Ambos reduzem o esforço de integração em uma ordem de grandeza.</li>
<li>Quatro requisitos de Governance são inegociáveis antes da produção: Decision Layer, Human-in-the-Loop, Audit Trail e Rollback.</li>
<li>Comece com um agente para um processo. A infraestrutura construída para o primeiro agente é a plataforma para cada um dos seguintes.</li>
</ul>
</div>

## A arquitetura do agente: cinco camadas

Um agente IA não é um sistema monolítico. A arquitetura corporativa consiste em cinco camadas, cada uma com uma responsabilidade claramente definida:

```
┌─────────────────────────────────────────┐
│          Interface do usuário            │
│     (very-ai / Teams / Custom)           │
├─────────────────────────────────────────┤
│        Camada de orquestração            │
│   (Routing, motor de regras, escalação)  │
├─────────────────────────────────────────┤
│          Camada do modelo IA             │
│  (Claude / GPT / Llama / gpt-oss)       │
├─────────────────────────────────────────┤
│      Integração de ferramentas (MCP)     │
│  (ERP, CRM, DMS, email, calendário...)   │
├─────────────────────────────────────────┤
│      Governance & Audit Layer            │
│  (Logging, políticas, Human-in-the-Loop) │
└─────────────────────────────────────────┘
```

**Interface do usuário.** A camada pela qual funcionários interagem com o agente. Pode ser um portal de IA dedicado (como descrito em [Portal Enterprise AI: Quatro interfaces Open Source em comparação](/br/revista/enterprise-ai-chat-interface/)), uma integração com Microsoft Teams ou uma interface personalizada para departamentos específicos.

**Camada de orquestração.** Aqui se decide qual agente assume uma tarefa, qual modelo é utilizado e quando escalar. A orquestração conhece os conjuntos de regras, as responsabilidades e as rotas de escalação. É o centro de controle.

**Camada do modelo IA.** O modelo de linguagem que realiza o processamento propriamente dito: compreender textos, reconhecer padrões, gerar respostas. Em uma arquitetura agnóstica de modelo, essa camada é intercambiável. Um modelo econômico para consultas padrão, um mais poderoso para análises complexas. O roteamento acontece automaticamente.

**Integração de ferramentas (MCP).** A conexão com seus sistemas existentes: ERP, CRM, gestão documental, email, calendário, sistema de tickets. Através do Model Context Protocol (MCP), os agentes acessam esses sistemas de forma padronizada.

**Governance & Audit Layer.** Cada ação do agente é registrada. Políticas definem o que um agente pode e não pode fazer. Human-in-the-Loop é imposto onde necessário. Essa camada não é opcional. É o pré-requisito para o deploy em produção. O [Decision Layer](/br/decision-layer/) forma a base arquitetônica desse Governance.

## MCP e A2A: os novos padrões

Dois protocolos mudaram em 2025/2026 a forma como agentes IA se comunicam com o mundo externo e entre si: MCP (Model Context Protocol) e A2A (Agent-to-Agent).

### MCP: A porta USB para IA

MCP é um padrão aberto que permite a modelos de IA acessar fontes de dados externas e ferramentas. A analogia é precisa: assim como USB criou uma interface universal para hardware, MCP cria uma interface universal para integrações de IA.

Antes do MCP, cada combinação de modelo de IA e sistema-alvo exigia um conector específico. Agente A acessa o ERP: um conector. Agente B acessa o DMS: outro conector. Agente C acessa o calendário: mais um conector. Com dez sistemas e três modelos, são trinta integrações individuais.

Com MCP, cada sistema define suas capacidades uma vez em um formato padronizado: Quais dados pode fornecer? Quais ações pode executar? Quais parâmetros são necessários? Qualquer modelo compatível com MCP pode utilizar essas capacidades sem código específico do sistema.

Para empresas, isso significa: novos sistemas podem ser conectados mais rapidamente. Modelos podem ser trocados sem reconstruir integrações. A dependência de fornecedores individuais de modelos diminui.

### A2A: Agentes conversando entre si

A2A (Agent-to-Agent) é o equivalente do MCP para a comunicação entre agentes. Enquanto MCP rege a conexão agente-sistema, A2A rege a conexão agente-agente.

Por que isso importa? Porque processos de negócio complexos raramente são cobertos por um único agente. Um atestado médico afeta RH, planejamento de capacidade, folha de pagamento e potencialmente gestão de projetos. Cada área tem um agente especializado. A2A permite a esses agentes delegar tarefas e trocar resultados, com permissões definidas.

Ponto crítico: A2A não significa acesso compartilhado a dados. O agente de RH transmite ao agente financeiro a informação "Funcionário X ausente a partir da data Y", não o prontuário completo. Cada agente vê apenas o que precisa para sua tarefa. Os limites de permissão permanecem intactos.

## 5 casos de uso com potencial de economia concreto

A pergunta que gestores fazem não é "O que um agente pode fazer?" mas "O que um agente entrega?". Aqui estão cinco casos de uso com potencial de economia mensurável:

| Área | Caso de uso | O que o agente faz | Potencial de economia |
|---|---|---|---|
| RH | Onboarding | Criar contas, atribuir treinamentos, agendar reuniões de integração, enviar email de boas-vindas | 4-6 h por contratação |
| Finanças | Verificação de faturas | Ler fatura, verificar contra pedido de compra, conferir contabilização, disparar fluxo de aprovação | 70-80% menos tempo de processamento |
| Jurídico | Análise de contratos | Extrair cláusulas, comparar com contratos-padrão, sinalizar desvios | Horas em vez de dias |
| TI | Triagem de incidentes | Analisar relato de erro, comparar com issues conhecidos, criar ticket priorizado | Resposta inicial mais rápida |
| Operações | Monitoramento de fornecedores | Rastrear prazos de entrega, confrontar com plano de produção, alerta proativo sobre atrasos | Alerta antecipado em vez de retrabalho |

Cada um desses casos de uso segue o mesmo padrão: o agente assume a parte estruturada e baseada em regras do processo. O humano cuida das exceções, das decisões que exigem julgamento e das aprovações. A economia de tempo não vem da eliminação do trabalho humano, mas da eliminação de tarefas manuais rotineiras.

**Onboarding de RH em detalhe.** Hoje, um analista de RH coordena manualmente cada nova contratação: criar contas de TI, configurar direitos de acesso, atribuir treinamentos obrigatórios, preparar o plano de integração, redigir o email de boas-vindas, configurar a folha de pagamento. Cada passo em um sistema diferente, cada passo uma entrada manual. Um agente de onboarding orquestra esses passos automaticamente: lê o contrato de trabalho, identifica cargo, localização e departamento, e executa os passos nos sistemas correspondentes. O analista de RH aprova o processo como um todo, não cada passo individual.

**Verificação de faturas em detalhe.** Uma fatura recebida é lida pelo Document Agent. O agente extrai fornecedor, valor, itens e número do pedido de compra. Verifica automaticamente: Existe um pedido correspondente? Os itens e valores conferem? A contabilização está correta? O valor está dentro dos limites de aprovação? Com resultado positivo, o lançamento contábil é preparado. Em caso de desvios, o caso é escalado ao responsável, com o motivo concreto do desvio, não com uma mensagem genérica "favor verificar".

## Requisitos de Governance para agentes

Um agente sem Governance é um risco. Quatro requisitos devem ser atendidos antes do deploy em produção:

**1. Decision Layer.** Cada decisão do agente passa pelo [Decision Layer](/br/decision-layer/). Para cada microdecisão, define-se: O agente pode agir de forma autônoma, aplica-se um conjunto de regras, ou um humano deve aprovar? Essas regras são versionadas, rastreáveis e não podem ser modificadas pelo próprio agente.

**2. Human-in-the-Loop.** Para tipos de decisão definidos, a arquitetura impõe revisão humana. Isso não é uma funcionalidade que pode ser ativada. É um princípio arquitetônico. O agente não pode contornar o requisito de Human-in-the-Loop porque ele é imposto tecnicamente, não acordado organizacionalmente.

**3. Audit Trail.** Cada ação do agente gera um registro imutável: Qual foi o input? Qual modelo foi usado? Qual regra foi aplicada? Qual foi o resultado? Quando a ação foi executada? O Audit Trail é a base para auditorias financeiras, revisão interna e fiscalização pela representação dos trabalhadores (sindicatos/CRE (PT: Comissão de Trabalhadores); PT: Comissão de Trabalhadores) ou comitê interno.

**4. Rollback.** Cada ação do agente deve ser reversível. Se um agente gera um lançamento contábil errado ou envia uma notificação incorreta, o processo deve poder ser corrigido - tecnicamente, não apenas organizacionalmente. A capacidade de rollback é um requisito arquitetônico, não uma adição posterior.

Esses quatro requisitos são inegociáveis. Sem eles, nenhuma representação dos trabalhadores (sindicatos/CRE; PT: Comissão de Trabalhadores) consentirá, nenhum auditor aprovará e nenhum CIO assumirá a responsabilidade. Mais sobre a arquitetura de Governance no próximo artigo: [Decision Layer & Shadow AI](/br/revista/decision-layer-shadow-ai/).

## Sistemas Multi-Agent: especialização em vez de agente universal

O próximo nível após o agente individual: múltiplos agentes especializados trabalhando juntos. Não um agente universal que faz tudo, mas especialistas que dominam cada um uma única área.

O exemplo do atestado médico como sistema Multi-Agent:

```
Atestado médico recebido
│
Document Agent  →  Lê e classifica o atestado médico
│
HR Agent      →  Verifica regras: auxílio-doença, reintegração, prazos
│
Workflow Agent  →  Notifica o líder, ajusta escala
│
Finance Agent   →  Atualiza folha de pagamento
```

Cada agente tem suas próprias permissões. O Document Agent pode ler documentos, mas não pode criar lançamentos contábeis. O Finance Agent pode ajustar a folha de pagamento, mas não pode acessar prontuários de funcionários. Os limites de permissão são impostos arquitetonicamente. Pelo protocolo A2A, os agentes comunicam apenas as informações que o agente receptor precisa para sua tarefa.

O agente orquestrador coordena o fluxo geral. Ele sabe qual agente executa qual passo, em qual sequência e o que acontece em caso de erros. O orquestrador tem visão geral, mas não tem permissões operacionais. Ele delega; não executa.

Sistemas Multi-Agent são poderosos, mas complexos. O número de interações cresce quadraticamente com o número de agentes. A depuração se torna mais trabalhosa. Os requisitos de Governance aumentam.

## Recomendação prática: comece pequeno

A tentação de começar diretamente com um sistema Multi-Agent é compreensível. A recomendação é clara: comece com um único agente para um processo claramente definido.

**Passo 1:** Identifique um processo que seja estruturado, baseado em regras e frequente o suficiente para justificar o esforço. Verificação de faturas, onboarding, análise de contratos: escolha um.

**Passo 2:** Implante um único [agente de IA](/br/servicos/ai-agents/) para esse processo. Com Decision Layer, com Human-in-the-Loop, com Audit Trail. Não como protótipo, mas como sistema produtivo.

**Passo 3:** Meça. Tempo de processamento antes e depois. Taxa de erros. Custo por transação. Satisfação dos operadores.

**Passo 4:** Somente quando o primeiro agente estiver funcionando de forma estável, planeje o segundo. E somente quando vários agentes estiverem estáveis, considere a orquestração Multi-Agent.

Essa abordagem não é conservadora. É pragmática. Um agente funcional com valor comprovado entrega mais do que um ambicioso conceito Multi-Agent parado na fase piloto.

A [infraestrutura](/br/servicos/infraestrutura/) - hosting de modelos, bancos de dados vetoriais, motor de orquestração, API gateway - é construída com o primeiro agente e fica disponível para cada um dos seguintes. O investimento no primeiro agente é simultaneamente o investimento na plataforma.

Um exemplo concreto: no portal Enterprise AI [very-ai](/br/revista/enterprise-ai-chat-interface/) os usuários podem disparar fluxos Trigger.dev diretamente pelo chat. O agente se torna o gatilho de uma cadeia de processos - não apenas um interlocutor. A plataforma de orquestração (→ [Artigo 10](/br/revista/orquestracao-agentes-plataformas/)) cuida da execução.

Onde esses agentes efetivamente rodam, em qual plataforma, é abordado no [Artigo 10: Orquestração de agentes](/br/revista/orquestracao-agentes-plataformas/).

---

**Enterprise AI-Infrastruktur Blueprint 2026 - Série de artigos**

| ← Anterior | Visão geral | Próximo → |
|:---|:---:|---:|
| [RAG e Document Intelligence: Como a IA entende seus documentos](/br/revista/rag-document-intelligence-enterprise/) | [Visão geral](/br/revista/infraestrutura-ia-blueprint-2026/) | [Decision Layer & Shadow AI: Controle em vez de caos](/br/revista/decision-layer-shadow-ai/) |

*Todos os artigos desta série: [Enterprise AI-Infrastruktur Blueprint 2026](/br/revista/infraestrutura-ia-blueprint-2026/)*

---

**Pronto para implantar o primeiro agente IA para um processo de negócio concreto?** Gosign acompanha clientes corporativos da análise do processo ao agente em produção - agnóstico em relação a modelos, com Decision Layer e Audit Trail completo.

<a href="/br/contato/" target="_blank" rel="noopener noreferrer">Agende uma consulta</a>. 30 minutos para identificar o primeiro caso de uso adequado para sua organização.

--- Ato de decisão: por que toda decisão de IA deve ser contestável ---
> A LGPD art. 20 já dá ao titular o direito de revisar decisões automatizadas. Logs de chat e model cards não cumprem isso. O ato de decisão cumpre.

Um candidato é rejeitado. Uma gratificação é negada. Um enquadramento sai mais baixo do que o esperado. Nos três casos, um agente de IA participou - e nos três casos o afetado poderá em breve dizer uma frase que até pouco tempo era exclusividade de advogados: "Explique-me o papel do sistema de IA e os principais elementos desta decisão."

Esse não é um cenário hipotético. É o núcleo textual do artigo 86 do [Regulamento (UE) 2024/1689](https://artificialintelligenceact.eu/article/86/) - o artigo mais subestimado do EU AI Act. O mercado debate documentação de modelo, classes de risco e prazos. O artigo 86 faz outra pergunta: você consegue explicar uma única decisão concreta? Não o seu sistema. Esta decisão.

E o ponto que muda tudo para o Brasil: você não precisa esperar a Europa para enfrentar essa pergunta. A [LGPD](https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm), no artigo 20, já garante ao titular o direito de solicitar a revisão de decisões tomadas unicamente com base em tratamento automatizado. A pergunta do juiz do trabalho - "Explique como essa decisão foi tomada" - já é feita hoje, nas mais de 3,5 milhões de novas reclamações que a Justiça do Trabalho recebe por ano.

A maioria das empresas não consegue responder. Não porque sua IA seja ruim - mas porque a arquitetura documenta a unidade errada. Elas registram conversas, tokens e comportamento do sistema. Mas só é contestável aquilo que foi registrado como decisão. Este artigo descreve o artefato que falta: o ato de decisão.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Em resumo - O ato de decisão</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Só é contestável aquilo que foi registrado como decisão. O ato de decisão é o registro atômico e imutável de uma única microdecisão: entrada, regra de negócio aplicada com versão e fonte, resultado, confiança, versão do modelo, carimbo de tempo, caminho de contestação. Logs respondem "O que aconteceu?" - o ato de decisão responde "Por que foi decidido assim?".</li>
<li>A LGPD art. 20 já dá ao titular o direito de revisar decisões automatizadas; o art. 86 do EU AI Act dá ao afetado o direito a uma explicação da decisão individual - e o TJUE já exige hoje a mesma justificativa do caso concreto sob o RGPD. A descrição do sistema não basta.</li>
<li>Logs de chat, traces de observabilidade e model cards documentam interação, infraestrutura e sistema - mas não a justificativa jurídico-fática. A própria documentação da Microsoft confirma: o log de auditoria do Copilot não registra nem o conteúdo dos prompts nem a versão do modelo. E, segundo a pesquisa da Anthropic, os textos de raciocínio de modelos de linguagem refletem a real base da decisão em apenas cerca de um quarto dos casos.</li>
<li>Um agente de IA nunca toma "uma decisão" - ele toma dezenas de microdecisões por processo. Cada uma pode ser juridicamente relevante: o TJUE já trata o score automatizado como decisão, não apenas o resultado final.</li>
<li>Contestabilidade não se instala depois: uma decisão que nunca foi modelada como decisão não pode ser justificada como tal retrospectivamente. Por isso o ato de decisão é um princípio arquitetônico do Decision Layer - não uma função de compliance.</li>
</ul>
</div>

## IA agêntica significa transferir direitos de decisão

Os números das grandes consultorias contam uma história consistente em 2026. A [McKinsey](https://www.mckinsey.com/capabilities/quantumblack/our-insights/seizing-the-agentic-ai-advantage) chama isso de paradoxo da IA generativa: quase oito em cada dez empresas usam IA generativa, e uma parcela quase tão grande não vê efeito mensurável no resultado - porque os copilotos horizontais são implantados de forma ampla, enquanto os casos de uso verticais que geram valor ficam presos em piloto. O [Gartner](https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027) prevê que mais de 40 por cento dos projetos de IA agêntica serão cancelados até o fim de 2027 - incluindo expressamente controles de risco insuficientes entre as causas. A mesma previsão espera que, até 2028, ao menos 15 por cento das decisões de trabalho do dia a dia sejam tomadas autonomamente por agentes de IA.

Juntas, as duas afirmações definem a tensão real: as empresas transferem direitos de decisão a máquinas sem possuir a infraestrutura para responder por essas decisões. A McKinsey enquadra a era agêntica exatamente assim em seu estudo de confiança de 2026 - a pergunta condutora desloca-se de "O modelo é preciso?" para "Quem responde quando o sistema age?" ([State of AI trust in 2026](https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/tech-forward/state-of-ai-trust-in-2026-shifting-to-the-agentic-era)).

A lacuna de governança está quantificada em todas as fontes:

| Constatação | Número | Fonte |
|---|---|---|
| Projetos de IA agêntica cancelados até o fim de 2027 - inclusive por controles de risco insuficientes | mais de 40% | [Gartner, 2025](https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027) |
| Empresas com governança madura para agentes autônomos | apenas 21% | [Deloitte, 2025](https://www.deloitte.com/us/en/insights/topics/emerging-technologies/ai-agents-scaling-faster.html) |
| Executivos de tecnologia cuja adoção de IA já ultrapassou a própria capacidade de governança | 77% | [IBM IBV, 2026](https://www.cio.com/article/4182288/cios-are-being-held-accountable-for-ai-they-dont-fully-control-ibm-study-finds.html) |
| CIOs/CTOs responsabilizados por sistemas de IA que não controlam totalmente | cerca de dois terços | [IBM IBV, 2026](https://www.cio.com/article/4182288/cios-are-being-held-accountable-for-ai-they-dont-fully-control-ibm-study-finds.html) |
| Incidentes de IA reportados em 2024 - recorde, +56,4% sobre o ano anterior | 233 | [Stanford HAI AI Index, 2025](https://hai.stanford.edu/ai-index/2025-ai-index-report/responsible-ai) |
| Menos incidentes de IA quando a governança está embutida diretamente no sistema, em vez de supervisão manual | 25% | [IBM IBV, 2026](https://www.ibm.com/thought-leadership/institute-business-value/en-us/report/ai-governance-trends) |

A última linha é a mais importante: governança embutida funciona de forma mensurável melhor do que controle posterior. É aí que a pergunta fica concreta: o que "embutida" significa tecnicamente? E é em RH que isso fica mais agudo: transferir direitos de decisão a agentes desloca o modelo operacional - e cada uma dessas decisões recai sobre uma pessoa concreta: seu atestado, sua remuneração, seu enquadramento. A resposta começa pela lei.

## O que a LGPD art. 20 e o artigo 86 exigem - e por que a documentação do sistema não cumpre

Tanto a legislação brasileira quanto a europeia conhecem dois níveis de transparência fundamentalmente distintos, que o debate de compliance constantemente mistura:

| Nível | Base jurídica | Destinatário | Momento | Responde à pergunta |
|---|---|---|---|---|
| Transparência do sistema | EU AI Act art. 11 (documentação técnica), art. 13 (manual de operação) | autoridade, operador | antes da operação | "Como o sistema funciona em geral?" |
| Explicação do caso individual | LGPD art. 20; EU AI Act art. 86; RGPD art. 15(1)(h) e art. 22 | o titular afetado | depois da decisão | "Por que esta decisão saiu assim?" |

No Brasil, o [artigo 20 da LGPD](https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm) garante ao titular o direito de solicitar a revisão de decisões tomadas unicamente com base em tratamento automatizado de dados pessoais que afetem seus interesses - e o direito a informações claras e adequadas sobre os critérios e procedimentos utilizados. Para empresas brasileiras que operam na UE, o [artigo 86](https://artificialintelligenceact.eu/article/86/) acrescenta a mesma exigência (PT: em Portugal, como Estado-membro da UE, o art. 86 vale diretamente - sem condição de negócio na UE; a autoridade de dados é a CNPD, sob o RGPD em vez da LGPD): dá a qualquer pessoa sujeita a uma decisão baseada em sistema de IA de alto risco do Anexo III, com efeito jurídico ou semelhante significativo, o direito a explicações claras e relevantes sobre o papel do sistema de IA no procedimento decisório e sobre os principais elementos da decisão tomada. Ambas as normas são formuladas por caso, não por sistema. Uma model card descreve o modelo. A LGPD art. 20 e o art. 86 perguntam pelo caso. E o PL 2338/2023 (Marco Legal da IA), aprovado no Senado em dezembro de 2024, caminha na mesma direção: direito à explicação e à contestação de decisões automatizadas como dever do agente de IA.

O Tribunal de Justiça da União Europeia já detalhou o mesmo princípio para o RGPD - referência global que orienta a direção para onde o Brasil também caminha - em dois acórdãos que todo responsável por decisões de IA deveria conhecer:

**[SCHUFA, C-634/21](https://eur-lex.europa.eu/legal-content/PT/TXT/?uri=CELEX:62021CJ0634) (dezembro de 2023):** a própria geração automatizada de um score já é uma decisão individual automatizada na acepção do art. 22 do RGPD, desde que um terceiro lhe atribua peso determinante. A consequência vai muito além do score de crédito: o dever de rastreabilidade incide sobre a avaliação automática em si - não apenas sobre a decisão final que um humano assina.

**[Dun & Bradstreet Áustria, C-203/22](https://www.dpcuria.eu/case?reference=C-203%2F22) (fevereiro de 2025):** o responsável deve explicar o procedimento efetivamente aplicado de modo que o titular consiga entender quais de seus dados entraram, e de que forma, na decisão. Uma explicação contrafactual pode bastar - por exemplo: com qual variação dos dados de entrada o resultado teria sido outro? E segredos comerciais não justificam recusa genérica; em caso de conflito, as informações devem ser apresentadas à autoridade ou ao tribunal competente, que então ponderam.

Uma explicação contrafactual por caso pressupõe que os dados de entrada efetivamente usados e a regra aplicada estejam armazenados, de forma estruturada, por decisão. A partir de uma descrição global do sistema, isso não se reconstrói.

Soma-se a isso um ponto que o debate de compliance costuma ignorar: o [art. 12](https://artificialintelligenceact.eu/article/12/) obriga sistemas de alto risco ao registro automático por toda a vida útil, e o [art. 26(6)](https://artificialintelligenceact.eu/article/26/) obriga operadores a conservar esses registros por ao menos seis meses. Qual conteúdo os registros devem carregar, porém, a lei só define para sistemas biométricos. Para sistemas de RH e financeiros, o EU AI Act exige a capacidade de registro - e deixa o esquema de conteúdo em aberto. O que é registrado por decisão é tarefa de design do operador. Quem aqui só registra consumo de token e carimbo de tempo cumpre a letra do art. 12 e falha no art. 86 - e, no Brasil, falha igualmente no direito à informação da LGPD art. 20.

Quanto aos prazos: pela legislação vigente, as obrigações de alto risco do EU AI Act valem a partir de 2 de agosto de 2026; o adiamento para 2 de dezembro de 2027, acordado provisoriamente no Digital Omnibus em 7 de maio de 2026, ainda não foi formalmente adotado. Nada disso muda a classificação de alto risco dos processos de RH ([Anexo III n.o 4](https://artificialintelligenceact.eu/annex/3/)) - nem o dever civil de explicar decisões, que [já vale no mundo todo](/br/revista/eu-ai-act-vale-no-mundo-todo/), e que no Brasil decorre da LGPD, da CLT e da Constituição Federal. A proibição de determinadas práticas de IA já vigora desde 2 de fevereiro de 2025. Detalhes de prazos e obrigações são tratados em [EU AI Act 2026: status, prazos, o que fazer](/br/revista/eu-ai-act-2026-empresas/).

## Não existe "uma decisão de IA" - existem dezenas de microdecisões

Quem leva o art. 86 e a LGPD art. 20 a sério na operação esbarra de imediato num problema de granularidade: o que exatamente é "a decisão"?

<div class="not-prose my-10 grid grid-cols-1 md:grid-cols-2 gap-4">
  <div class="border border-base rounded-soft overflow-hidden bg-surface-dim opacity-90">
    <div class="px-4 py-2.5 border-b border-base font-code text-xs uppercase tracking-wider text-muted">UMA &#8220;DECIS&#195;O DE IA&#8221;</div>
    <div class="p-5">
      <div class="font-code text-xs text-muted mb-3">input: solicita&#231;&#227;o MA-4711</div>
      <div class="flex items-center justify-center h-20 rounded bg-[#2e2e3e] border border-[#555]">
        <span class="font-display text-3xl text-white/40">?</span>
      </div>
      <div class="mt-3 font-code text-xs text-primary">resultado: negado</div>
      <div class="mt-4 pt-3 border-t border-base font-code text-xs text-muted">1 resultado &#183; 0 justificativas &#183; n&#227;o contest&#225;vel <span aria-hidden="true">&#10007;</span></div>
    </div>
  </div>
  <div class="border-2 rounded-soft overflow-hidden bg-surface-raised" style="border-color: var(--accent-primary);">
    <div class="px-4 py-2.5 border-b border-base font-code text-xs uppercase tracking-wider text-accent">13 MICRODECIS&#213;ES</div>
    <div class="p-5">
      <div class="font-code text-xs text-muted mb-3">input: solicita&#231;&#227;o MA-4711</div>
      <div class="flex flex-wrap gap-1.5">
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #0369A1;">01</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #0369A1;">02</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #0369A1;">03</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #0369A1;">04</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #0369A1;">05</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #0369A1;">06</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #0369A1;">07</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #0369A1;">08</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #6D4ED8;">09</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #0369A1;">10</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #0369A1;">11</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #B45309;">12</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #B45309;">13</span>
      </div>
      <div class="mt-3 flex flex-wrap gap-3 font-code text-[11px] text-muted">
        <span><span class="inline-block w-2.5 h-2.5 rounded-full align-middle mr-1" style="background:#0369A1;"></span>Regra (10)</span>
        <span><span class="inline-block w-2.5 h-2.5 rounded-full align-middle mr-1" style="background:#6D4ED8;"></span>IA (1)</span>
        <span><span class="inline-block w-2.5 h-2.5 rounded-full align-middle mr-1" style="background:#B45309;"></span>Humano (2)</span>
      </div>
      <div class="mt-4 pt-3 border-t border-base font-code text-xs text-primary">13 atos &#183; 13 justificativas &#183; contest&#225;veis uma a uma <span class="text-accent" aria-hidden="true">&#10003;</span></div>
    </div>
  </div>
</div>

Essa decomposição não está presa a nenhuma jurisdição. Uma decisão de crédito se decompõe pela mesma mecânica: verificação de identidade (regra), extração de renda dos documentos (IA, com confiança), cálculo de score (regra, versionada), roteamento por limiares (regra), voto humano no caso-limite (humano). Qual direito vincula cada microdecisão - LGPD art. 20, RGPD art. 22, UK GDPR ou o Equal Credit Opportunity Act americano - depende do mercado. A decomposição em si é a mesma em toda parte. Até onde ela chega em um processo regulado, mostra o exemplo que ocupa diariamente os departamentos de RH europeus:

Processar um atestado médico - isso soa como um processo único. Na verdade, ele contém mais de uma dúzia de decisões separadas: o atestado está validado quanto à Resolução CFM 1.658/2002 (CRM ativo, assinatura do médico, CID-10 com consentimento)? Os 15 primeiros dias correm por conta do empregador conforme a Lei 8.213/91, art. 60, §3º - e a partir do 16º dia o auxílio por incapacidade temporária (antigo auxílio-doença) passa ao INSS (arts. 59-63)? Há sobreposição com férias e suspensão do contrato pela CLT art. 131-138? O limite de 15 dias acumulados foi atingido, exigindo orientar o empregado a requerer o benefício ao INSS - via Meu INSS, com análise documental pelo Atestmed? Os efeitos da dispensa ficam suspensos pela Súmula TST 371 (auxílio-doença no curso do aviso prévio)? Incide a estabilidade acidentária do art. 118 da Lei 8.213/91? Quem é informado sobre o quê - e sobre o quê, expressamente, não, por força do sigilo médico?

O [Decision Layer](/br/decision-layer/) decompõe cada processo de negócio exatamente nessas microdecisões e atribui cada uma, de antemão, a um de [três tipos de decisor](/br/revista/tres-tipos-de-decisoes/) - humano, conjunto de regras ou IA:

| Microdecisão (atestado médico) | Decisor | Por quê |
|---|---|---|
| Validação do atestado conforme a Resolução CFM 1.658/2002 | Regra | determinística, sem espaço para interpretação |
| Cálculo dos 15 dias do empregador (Lei 8.213/91, art. 60, §3º) | Regra | prazo e valor fixos |
| Transição para o auxílio por incapacidade temporária do INSS no 16º dia (Lei 8.213/91 art. 59-63) | Regra | regra previdenciária determinística (B31/B91) |
| Comunicação do evento eSocial S-2230 no prazo legal | Regra | obrigação legal com prazo fixo |
| Detecção de atestados duplicados ou falsos | IA (indicador) | análise de padrões de fraude; saída é alerta de revisão, não decisão de pessoal |
| Comunicação ao colaborador sobre o requerimento ao INSS (via Meu INSS) | Humano | orientação previdenciária, julgamento e cuidado |
| Casos de julgamento (Súmulas TST 371 e 443, art. 302 CP) | Humano | exigem análise do jurídico trabalhista e do médico do trabalho - com o encarregado (DPO) nos aspectos de proteção de dados |

(PT: em Portugal, o fluxo equivalente corre pelo certificado de incapacidade temporária e pela Segurança Social - o subsídio de doença é devido a partir do 4º dia, sem os 15 dias por conta do empregador, e o órgão interno é a comissão de trabalhadores, art. 54 da CRP. As microdecisões mudam de base legal; o princípio permanece.)

Essa decomposição não é exercício acadêmico - é a condição da contestabilidade. Pois a lógica do TJUE no caso SCHUFA vale em cada nível: se já um score automatizado é decisão no sentido jurídico, então também a verificação automática de prazo, a classificação automática de um documento, a recomendação automática de enquadramento são, cada uma, um ato potencialmente contestável - não apenas o resultado final. Uma empresa que documenta só o resultado final só consegue responder à pergunta "Por que meu pedido foi rejeitado?" com: "Foi o que o processo produziu." É exatamente a resposta de caixa-preta que nenhuma Vara do Trabalho aceita.

O [catálogo de agentes de RH](/br/catalogo-agentes-hr/) mostra até onde essa decomposição vai na prática: cada agente vem com uma tabela completa de microdecisões - por etapa, tipo de decisor, justificativa, base legal e caminho de contestação.

## Por que logs, traces e model cards não respondem à pergunta

A indústria respondeu à necessidade de documentação - mas em três níveis que passam todos ao largo da decisão individual:

| Nível | Ferramentas | Documenta | NÃO responde |
|---|---|---|---|
| Interação | logs de chat, histórico de conversa, eventos de auditoria do Copilot | quem falou com o sistema quando, quais recursos foram tocados | qual regra de negócio sustentou a decisão |
| Infraestrutura | observabilidade de LLM (traces, spans), OpenTelemetry GenAI | prompts, tool calls, tokens, latências ao longo da execução | por que o resultado saiu assim - e se está correto |
| Sistema | model cards, documentação técnica, plataformas de governança (inventário de modelos, registro de risco) | como o modelo funciona em geral, quais riscos o sistema tem | qualquer caso individual concreto |

Isso não é exagero polêmico - está assim na documentação dos fabricantes. A [documentação do Purview da Microsoft](https://learn.microsoft.com/en-us/purview/audit-copilot) registra, para o log de auditoria do Copilot, que ele não grava os prompts e respostas efetivos e que nome e versão do modelo não estão disponíveis em cenários do Microsoft 365 Copilot. No ecossistema Salesforce, a lacuna é nomeada abertamente: trilhas de auditoria clássicas foram feitas para humanos que clicam botões - vê-se que algo mudou, [mas não por quê](https://www.sweep.io/blog/the-audit-trail-of-an-ai-agent). E plataformas de governança como IBM watsonx.governance ou Credo AI respondem à pergunta "Este sistema está inventariado, avaliado quanto a risco e conforme as políticas?" - uma pergunta importante, mas outra que "Em que se baseou o enquadramento da Sra. M. em 14 de maio às 10:42?".

Resta a saída aparentemente mais óbvia: deixar o modelo se justificar sozinho. Modelos de raciocínio produzem cadeias de justificativa - por que não arquivá-las como prova? Porque elas comprovadamente não refletem em que a decisão de fato se baseou. A [pesquisa da Anthropic](https://www.anthropic.com/research/reasoning-models-dont-say-think) sobre fidelidade da cadeia de raciocínio mostra: mesmo sob condições favoráveis, modelos de raciocínio verbalizam as pistas de decisão que de fato usaram em apenas cerca de um quarto dos casos - fatores de influência relevantes permanecem ocultos mesmo para quem lê a cadeia inteira. Uma justificativa gerada é um texto sobre a decisão. Não é a base da decisão.

A pesquisa sobre contestabilidade tira daí a conclusão decisiva: explicabilidade e contestabilidade são dois meios para o mesmo fim - e a explicação sozinha, sem caminho de contestação, não o alcança ([Schmude et al., 2025](https://arxiv.org/abs/2504.18236)). A contestabilidade conta com a possibilidade de uma decisão estar errada e exige a prova para derrubá-la. Métodos de explicação post-hoc mostram, no melhor dos casos, que erros podem existir em algum ponto na vizinhança de uma decisão; não provam que esta decisão específica foi falha. E [Moreira et al. (2025)](https://arxiv.org/html/2506.01662v1) deslocam o critério da mera compreensão para a capacidade de ação: uma explicação precisa habilitar afetados e auditores a contestar ativamente, questionar e influenciar um resultado - não apenas a entender por que foi decidido assim.

Com um trace de token, ninguém consegue isso. Com um ato de decisão, sim.

## O ato de decisão: a peça de prova por decisão

O ato de decisão é o registro atômico, imutável e estruturado de uma única microdecisão de negócio. Ele nasce no momento da decisão - não como reconstrução posterior - e contém tudo o que o art. 86, o art. 12, a LGPD art. 20 e a jurisprudência do TJUE exigem por caso individual:

| Campo | Conteúdo | Para que serve juridicamente |
|---|---|---|
| Entrada | quais dados, qual documento, qual hash | C-203/22: "quais dados entraram, e de que forma" |
| Regra de negócio + versão + fonte | ex.: convenção coletiva (CCT) cláusula 12, versão 2024-Q3, vigente desde 01/07/2024 | a justificativa que sustenta - o campo que logs e traces não têm |
| Tipo de decisor | humano, conjunto de regras ou IA - com justificativa de roteamento | art. 14: prova de supervisão humana efetiva |
| Confiança | valor de confiança e limiar no momento da decisão | prova da gestão de riscos (art. 9), rastreio da escalação |
| Versão do modelo e do prompt | qual modelo de linguagem, qual template de prompt, qual versão | reprodutibilidade; o campo que falta no log do Copilot |
| Resultado + carimbo de tempo | o que foi decidido, quando (UTC) | conservação (art. 26(6)); retenção de 5 anos pela prescrição da CLT art. 11 |
| Registro de human-in-the-loop | quem revisou, se confirmou ou divergiu | art. 14(4): sobrepor, reverter, parar - documentado |
| Caminho de contestação | quem pode contestar esta decisão, e onde | torna o direito da LGPD art. 20 e do art. 86 operacionalmente possível de cumprir e comprovar |

É assim que aparece no ato de um caso real - quatro de 13 microdecisões do processamento de um atestado médico:

<div class="not-prose my-10 bg-surface-raised border border-base rounded-soft overflow-hidden shadow-sm">
  <div class="px-5 py-4 border-b border-base bg-surface-dim">
    <div class="flex items-center gap-3 mb-2">
      <div class="flex gap-1.5" aria-hidden="true">
        <span class="w-2.5 h-2.5 rounded-full bg-[#FF5F56]"></span>
        <span class="w-2.5 h-2.5 rounded-full bg-[#FFBD2E]"></span>
        <span class="w-2.5 h-2.5 rounded-full bg-[#27C93F]"></span>
      </div>
      <span class="font-code text-xs text-muted">decision-record / atestado-medico / 2026-05-14 / EMP_0x52a8</span>
    </div>
    <p class="text-small text-primary">Atestado recebido em 14.05.2026, 07:12. Caso processado em 54 segundos - decomposto em 13 microdecisões documentadas.</p>
    <div class="mt-3 flex h-7 rounded overflow-hidden text-xs font-bold text-white" aria-label="Distribuição de decisores: 10 regra, 1 IA, 2 humano">
      <div class="flex items-center justify-center" style="width: 77%; background: #0369A1;">10 Regra</div>
      <div class="flex items-center justify-center" style="width: 8%; background: #6D4ED8;">1</div>
      <div class="flex items-center justify-center" style="width: 15%; background: #B45309;">2 Humano</div>
    </div>
  </div>
  <ol class="divide-y divide-base">
    <li class="p-5">
      <div class="flex items-start gap-4">
        <div class="flex-shrink-0 w-9 h-9 rounded-full flex items-center justify-center font-code text-xs font-bold border" style="background: rgba(3,105,161,0.08); border-color: rgba(3,105,161,0.3); color: #0369A1;">02</div>
        <div class="flex-1 min-w-0">
          <div class="flex flex-wrap items-center gap-2 mb-1.5">
            <span class="text-body font-semibold text-primary">Cálculo dos 15 dias do empregador (Lei 8.213/91, art. 60, §3º)</span>
            <span class="inline-flex items-center gap-1 px-2 py-0.5 text-xs font-bold uppercase tracking-wider rounded text-white" style="background: #0369A1;">Regra</span>
          </div>
          <p class="text-small text-primary font-medium mb-2">Salário integral de 14.06 a 28.06.2026</p>
          <div class="px-3 py-2 bg-surface border border-base rounded font-code text-xs text-primary/80"><span class="text-muted">input:</span> período do atestado 14-27.05 · dados cadastrais EMP_0x52a8</div>
          <div class="mt-2 font-code text-xs text-muted"><span>rule:</span> <span class="text-primary">Lei-8.213/91-art.60-§3º · v2026-01</span></div>
        </div>
      </div>
    </li>
    <li class="p-5">
      <div class="flex items-start gap-4">
        <div class="flex-shrink-0 w-9 h-9 rounded-full flex items-center justify-center font-code text-xs font-bold border" style="background: rgba(3,105,161,0.08); border-color: rgba(3,105,161,0.3); color: #0369A1;">06</div>
        <div class="flex-1 min-w-0">
          <div class="flex flex-wrap items-center gap-2 mb-1.5">
            <span class="text-body font-semibold text-primary">Orientar requerimento ao INSS (auxílio por incapacidade temporária)</span>
            <span class="inline-flex items-center gap-1 px-2 py-0.5 text-xs font-bold uppercase tracking-wider rounded text-white" style="background: #0369A1;">Regra</span>
          </div>
          <p class="text-small text-primary font-medium mb-2">A partir do 16º dia - empregado requer via Meu INSS, benefício B31</p>
          <div class="px-3 py-2 bg-surface border border-base rounded font-code text-xs text-primary/80"><span class="text-muted">input:</span> histórico de afastamentos, 12 meses (3 períodos)</div>
          <div class="mt-2 font-code text-xs text-muted"><span>rule:</span> <span class="text-primary">Lei 8.213/91 art. 59-63 · v2025-07</span></div>
        </div>
      </div>
    </li>
    <li class="p-5">
      <div class="flex items-start gap-4">
        <div class="flex-shrink-0 w-9 h-9 rounded-full flex items-center justify-center font-code text-xs font-bold border" style="background: rgba(109,78,216,0.08); border-color: rgba(109,78,216,0.3); color: #6D4ED8;">09</div>
        <div class="flex-1 min-w-0">
          <div class="flex flex-wrap items-center gap-2 mb-1.5">
            <span class="text-body font-semibold text-primary">Marcar padrão de afastamentos</span>
            <span class="inline-flex items-center gap-1 px-2 py-0.5 text-xs font-bold uppercase tracking-wider rounded text-white" style="background: #6D4ED8;">IA <span class="font-mono opacity-90">91%</span></span>
          </div>
          <p class="text-small text-primary font-medium mb-2">Aviso ao RH: terceiro afastamento curto em seis meses</p>
          <div class="px-3 py-2 bg-surface border border-base rounded font-code text-xs text-primary/80"><span class="text-muted">input:</span> metadados de afastamento anonimizados - sem diagnóstico (LGPD art. 11)</div>
          <div class="mt-2 font-code text-xs text-muted"><span>model-reason:</span> <span class="text-primary">correspondência de padrão de afastamentos curtos repetidos · indicador, não decisão de pessoal</span></div>
          <div class="mt-3"><span class="inline-flex items-center px-3 py-1.5 text-xs font-semibold rounded border-2" style="border-color: #6D4ED8; color: #6D4ED8; background: rgba(109,78,216,0.08);">formalmente contestável · LGPD art. 20</span></div>
        </div>
      </div>
    </li>
    <li class="p-5">
      <div class="flex items-start gap-4">
        <div class="flex-shrink-0 w-9 h-9 rounded-full flex items-center justify-center font-code text-xs font-bold border" style="background: rgba(180,83,9,0.08); border-color: rgba(180,83,9,0.3); color: #B45309;">13</div>
        <div class="flex-1 min-w-0">
          <div class="flex flex-wrap items-center gap-2 mb-1.5">
            <span class="text-body font-semibold text-primary">Conversa de retorno ao trabalho</span>
            <span class="inline-flex items-center gap-1 px-2 py-0.5 text-xs font-bold uppercase tracking-wider rounded text-white" style="background: #B45309;">Humano</span>
          </div>
          <p class="text-small text-primary font-medium mb-2">Plano de reintegração acordado</p>
          <div class="mt-2 font-code text-xs text-muted"><span>decided-by:</span> <span class="text-primary">analista de RH</span> <span class="text-muted">- 17.05.2026, 14:10</span></div>
        </div>
      </div>
    </li>
  </ol>
</div>

O direito administrativo brasileiro guarda para esse artefato uma analogia precisa: o ato administrativo. Uma autoridade que decide sobre um cidadão não emite um "output" - emite um ato: individualmente endereçado, motivado, com base legal e indicação dos meios de impugnação, individualmente contestável. Ninguém aceitaria que um órgão respondesse a um recurso com: "Infelizmente só temos o log do servidor." É exatamente essa exigência de forma que o ato de decisão transfere às decisões automáticas. Uma trilha é um rastro que se deixa para trás. Um ato é um documento que se emite - e contra o qual cabe impugnação.

A contabilidade conhece essa mesma lógica há séculos: nenhum auditor aceita um total sem lançamentos e documentos de suporte. As normas brasileiras de contabilidade (NBC) e a legislação fiscal exigem registro individual, imutabilidade e rastreabilidade por fato contábil - com prazos de guarda de cinco anos pela prescrição tributária e até mais para fins societários, muito além dos seis meses do art. 26(6). O ato de decisão não é outra coisa senão a partida dobrada para decisões: um documento por fato, um ato por decisão.

O próprio mercado mostra que ainda não existe um termo padrão para essa unidade: circulam "decision trail", "decision provenance", "decision trace", "accountability record" - a [TechTarget](https://www.techtarget.com/searcherp/feature/AI-decision-trails-are-the-new-audit-trail) declara as trilhas de decisão de IA a nova trilha de auditoria, e o [FINOS AI Governance Framework](https://air-governance-framework.finos.org/mitigations/mi-21_agent-decision-audit-and-explainability.html) pede "Agent Decision Audit and Explainability". A exigência chegou ao debate. O artefato ainda não tem nome. Nós o chamamos, desde o início do Decision Layer: ato de decisão.

Onde o ato nasce fica claro nas sete camadas de um stack de agentes em produção - o ato de decisão é o artefato da camada 04:

<div class="not-prose my-10 border-y border-base">
  <ol class="divide-y divide-base">
    <li class="grid grid-cols-[3rem_1fr] gap-4 items-start py-4">
      <span class="font-display text-h2 leading-none text-muted">01</span>
      <div><span class="text-body font-semibold text-primary">Presentation Layer</span><p class="mt-1 text-small text-primary/80">Interfaces de usuário, gateways de prompts, portais de acesso para áreas de negócio e sindicato.</p></div>
    </li>
    <li class="grid grid-cols-[3rem_1fr] gap-4 items-start py-4">
      <span class="font-display text-h2 leading-none text-muted">02</span>
      <div><span class="text-body font-semibold text-primary">Orchestration Layer</span><p class="mt-1 text-small text-primary/80">Coordenação multiagente, roteamento de eventos, gestão de estado entre processos.</p></div>
    </li>
    <li class="grid grid-cols-[3rem_1fr] gap-4 items-start py-4 bg-[color:var(--accent-primary)]/5">
      <span class="font-display text-h2 leading-none text-accent">03</span>
      <div><span class="text-body font-semibold text-primary">Agent Layer <span class="ml-2 font-code text-xs uppercase tracking-wider text-accent">núcleo Gosign</span></span><p class="mt-1 text-small text-primary/80">Agentes Document, Workflow e Knowledge - a camada executora com julgamento de IA.</p></div>
    </li>
    <li class="grid grid-cols-[3rem_1fr] gap-4 items-start py-4 bg-[color:var(--accent-primary)]/5">
      <span class="font-display text-h2 leading-none text-accent">04</span>
      <div><span class="text-body font-semibold text-primary">Decision Layer <span class="ml-2 font-code text-xs uppercase tracking-wider text-accent">núcleo Gosign</span></span><p class="mt-1 text-small text-primary/80">Aqui nasce o ato de decisão: um ato por microdecisão, regras versionadas, routing human-in-the-loop em caso de discricionariedade, contestabilidade (LGPD art. 20; art. 14 na UE).</p></div>
    </li>
    <li class="grid grid-cols-[3rem_1fr] gap-4 items-start py-4">
      <span class="font-display text-h2 leading-none text-muted">05</span>
      <div><span class="text-body font-semibold text-primary">Governance Layer</span><p class="mt-1 text-small text-primary/80">Audit trail, registros assinados, controles cert-ready (EU AI Act art. 9/12/13/14 para negócios na UE, ISO 27001, NBC).</p></div>
    </li>
    <li class="grid grid-cols-[3rem_1fr] gap-4 items-start py-4">
      <span class="font-display text-h2 leading-none text-muted">06</span>
      <div><span class="text-body font-semibold text-primary">Model Layer</span><p class="mt-1 text-small text-primary/80">Registro de modelos, versionamento, calibração de confiança - agnóstico de modelo.</p></div>
    </li>
    <li class="grid grid-cols-[3rem_1fr] gap-4 items-start py-4">
      <span class="font-display text-h2 leading-none text-muted">07</span>
      <div><span class="text-body font-semibold text-primary">Integration Layer</span><p class="mt-1 text-small text-primary/80">Conectores para SAP, Workday, sistemas ERP - saídas prontas para lançamento.</p></div>
    </li>
  </ol>
</div>

## Contestabilidade é uma decisão de arquitetura - não uma função

A consequência incômoda de tudo isso: contestabilidade não se instala depois. Três razões pelas quais uma ferramenta de compliance posterior falha estruturalmente:

**Primeira: o que nunca foi modelado como decisão não pode ser justificado como decisão.** Um agente que processa um caso "de uma vez" produz um resultado sem estrutura. A decomposição em microdecisões precisa acontecer antes da execução - é ela que define onde nasce um ato, qual regra vale ali e quem decide ali. Retrospectivamente, de um log de conversa não se extrai estrutura de decisão, assim como de um extrato bancário não se extrai uma contabilidade de centros de custo.

**Segunda: supervisão humana efetiva precisa do contexto da decisão - por caso.** O [art. 14(4)](https://artificialintelligenceact.eu/article/14/) exige que a pessoa supervisora consiga interpretar corretamente a saída, ignorá-la ou revertê-la e parar o sistema - mantendo-se ciente da tendência de confiar automaticamente na saída da máquina. O legislador nomeia expressamente o viés de automação. O NIST, nos EUA, alerta no mesmo sentido contra o human-in-the-loop cerimonial: um botão de aprovação sem contexto, sem competência e sem tempo não protege ninguém. Quem deve sobrepor precisa ter diante de si a entrada, a regra aplicada, a confiança e o motivo da escalação - exatamente os campos do ato de decisão. Por isso o [human-in-the-loop no Decision Layer é um roteamento imposto](/br/revista/human-in-the-loop-arquitetura/), não um clique opcional: em tipos de decisão definidos, o workflow pausa, o sistema-alvo permanece intocado, e a decisão humana é ela própria documentada como ato - inclusive a informação se seguiu a recomendação ou divergiu dela.

**Terceira: a correção precisa da referência à regra.** Contestação não é um fim em si - serve para corrigir erros. Quando uma decisão é contestada com sucesso, surge de imediato a pergunta: foi um erro individual ou um erro de regra? Um ato de decisão que carrega a versão da regra aplicada responde isso por consulta: todos os atos sob a mesma versão da regra são identificáveis, a regra é corrigida em nova versão, os casos afetados são re-decididos de forma direcionada. De um caso individual contestado nasce uma classe de erro corrigida. Sem a referência à regra, resta apenas revisar manualmente todos os processos - o oposto de escalar.

A pesquisa chama esse princípio de [contestability by design](https://research.tudelft.nl/en/publications/contestable-ai-by-design-towards-a-framework/) (Alfrink et al., 2022): sistemas precisam permanecer abertos à intervenção humana por todo o ciclo de vida - como relação procedimental entre afetados e responsáveis pelo sistema, embutida em vez de acoplada. E a [Deloitte (2025)](https://www.deloitte.com/us/en/insights/topics/emerging-technologies/ai-agents-scaling-faster.html) nomeia os três blocos de governança que faltam às empresas para agentes quase ao pé da letra dessa arquitetura: limites claros sobre quais decisões os agentes podem tomar sozinhos e quais exigem aprovação humana; monitoramento em tempo real com detecção de anomalias; e trilhas de auditoria que captem a cadeia completa das ações do agente para a responsabilização. O framework de três decisores, o Confidence Routing e o ato de decisão são a resposta técnica exatamente a essa lista - como princípio de design, [não como camada de compliance posterior](/br/governance/eu-ai-act/).

## Quem contesta - e o que acontece depois

Contestabilidade soa abstrata, mas tem cinco rostos muito concretos. O Decision Layer define, para cada microdecisão, perante quem ela precisa se justificar:

| Quem contesta | Base jurídica | O que vê | O que decorre |
|---|---|---|---|
| O titular afetado | LGPD art. 20; art. 86 do EU AI Act (em negócio na UE), RGPD art. 15, 22 | a explicação da própria decisão: papel do sistema de IA, elementos essenciais, contrafactual a pedido | correção do caso individual; em erro de regra, re-execução de todos os casos afetados |
| O sindicato / a Justiça do Trabalho | CLT, convenções coletivas (CCT/ACT), a comissão de representantes dos empregados (CLT art. 510-A, empresas com mais de 200 empregados) | atos de decisões com impacto em pessoal, prova de que as regras coletivas foram tecnicamente cumpridas | negociação coletiva e fiscalização com base em evidência, não em desconfiança; defesa documentada em reclamação trabalhista |
| O Ministério Público do Trabalho | inquérito civil e ação civil pública (Lei 7.347/85) | atos de decisão dos processos investigados, com regra, versão e trilha de auditoria | resposta documental em dias, em vez de perícia reconstruída |
| O auditor | NBC, normas de auditoria, ISA | atos completos por lançamento: documento, regra, versão, confiança, aprovação | auditoria de sistema em vez de reconstrução caso a caso; amostra diretamente comprovada |
| A ANPD (PT: a CNPD, sob o RGPD art. 58 e a Lei 58/2019 - a fiscalização do AI Act em Portugal tem designação própria) | LGPD art. 20, 38; Resolução ANPD 4/2023; (e art. 26(6), art. 12 do EU AI Act em negócio na UE) | registros exportáveis e legíveis por máquina, no prazo de retenção exigido | capacidade de resposta em dias, em vez de projeto forense |

Notável é o que essa tabela faz com a organização: ela inverte a dinâmica do ônus da prova. Sem atos de decisão, cada contestação é um projeto forense de desfecho aberto - e, em caso de discriminação, a [Súmula TST 443](https://www.tst.jus.br/sumulas) presume discriminatória a dispensa de empregado portador de doença grave, transferindo o ônus ao empregador. Com atos de decisão, a resposta é uma consulta. O sindicato que hoje judicializa projetos de IA porque não obtém transparência torna-se beneficiário da mesma infraestrutura que serve ao auditor. Outros prometem transparência. O ato de decisão a impõe tecnicamente.

A tabela tem um lado silencioso: quem pode contestar é definido por lei e acordos - mas nenhuma norma garante por si só que os atos de decisão cheguem a existir, estejam completos e perdurem. Essa responsabilidade precisa de um dono claro na organização; ela não surge como subproduto da operação.

## Enquadramento: um princípio se impõe

O olhar honesto sobre o mercado de 2026: a percepção de que decisões de agentes precisam ser individualmente comprováveis não é exclusiva. O Gartner criou uma categoria de mercado própria para camadas de controle que monitoram e bloqueiam ações de agentes - [guardian agents](https://www.gartner.com/en/newsroom/press-releases/2025-06-11-gartner-predicts-that-guardian-agents-will-capture-10-15-percent-of-the-agentic-ai-market-by-2030) - e prevê que respondam por 10 a 15 por cento do mercado de IA agêntica até 2030. O campo da [decision intelligence](https://www.gartner.com/en/information-technology/glossary/decision-intelligence) - modelar, avaliar e melhorar decisões explicitamente - ganhou seu primeiro Magic Quadrant em janeiro de 2026. O WEF pede [progressive governance](https://www.weforum.org/publications/ai-agents-in-action-foundations-for-evaluation-and-governance/): intensidade de supervisão acoplada ao nível de autonomia do agente. A pesquisa trabalha em decision provenance. A direção é inequívoca - e é exatamente a direção do Decision Layer.

O que essas abordagens não entregam é a vinculação à substância de negócio. Um guardian agent bloqueia em tempo de execução; não deixa um ato que sustente três anos depois numa Vara do Trabalho. A observabilidade preserva a cadeia de execução; não decompõe decisões em artefatos individualmente justificados e vinculados a regras. A diferença defensável do ato de decisão está em três propriedades: a atribuição de cada microdecisão a uma regra de negócio versionada com sua fonte - convenção coletiva, acordo de empresa, legislação tributária - em vez de a uma cadeia de raciocínio gerada; o human-in-the-loop imposto arquitetonicamente por tipo de decisão, em vez de uma configuração desativável; e o mapeamento dos atos sobre os padrões de auditoria com que auditores e auditoria interna de fato trabalham - ISA, NBC, normas nacionais. Ao que sabemos, nenhum fornecedor horizontal documenta o primeiro campo; é também o campo de que a contestabilidade depende.

A precisão exige também a ressalva: o ato de decisão é uma afirmação de arquitetura, não um certificado de conformidade. Se um sistema concreto cumpre as exigências legais permanece uma avaliação caso a caso do operador e de seus assessores jurídicos. O que a arquitetura entrega é outra coisa - e mais valiosa: ela torna possível cumprir e comprovar as exigências, caso a caso. Uma empresa com atos de decisão consegue responder à pergunta da LGPD art. 20 e do art. 86. Uma empresa com logs de chat não consegue, por melhor que documente suas intenções.

## A verdadeira pergunta

A LGPD e o EU AI Act não inventaram a explicabilidade de decisões individuais - codificaram-na para sistemas de IA e a armaram com um direito do afetado. A jurisprudência do TJUE fixou o padrão antes mesmo de o primeiro prazo de alto risco incidir. E as consultorias quantificaram o que acontece quando empresas transferem direitos de decisão sem conseguir comprovar decisões: projetos cancelados, rollouts bloqueados, CIOs pessoalmente responsabilizados.

A pergunta a toda empresa que usa ou introduz agentes de IA não é, portanto, "Estamos em conformidade?". É: se amanhã um colaborador, um sindicato, um auditor ou a ANPD contestar uma única decisão de hoje - você consegue apresentar o ato? Entrada, regra, versão, confiança, resultado, aprovação?

Quem responde sim a essa pergunta não tem mais um problema de risco de IA. Tem uma infraestrutura de decisão.

→ [Decision Layer - visão geral e exemplos](/br/decision-layer/)

→ [Decision Layer explicado: os quatro componentes](/br/revista/decision-layer-explicado/)

→ [EU AI Act e RH: IA continua alto risco - prazo 2026/2027](/br/revista/eu-ai-act-hr-alto-risco/)

<a href="/br/contato/" target="_blank" rel="noopener noreferrer">Agendar reunião</a> - Mostramos, em um dos seus processos, como microdecisões, atos de decisão e caminhos de contestação se materializam na prática.

--- Cert-Ready by Design - IA pronta para auditoria ---
> Cert-Ready by Design: controles como objetos de dados, evidências geradas automaticamente, auditores com status ao vivo. Arquitetura para ISA, NBC, CPC.

## O problema: prontidão para auditoria como projeto

Na maioria das empresas, a preparação para uma auditoria - auditoria de demonstrações financeiras, fiscalização tributária, auditoria SOC 2 - é um projeto. Semanas antes da auditoria, documentos são compilados, capturas de tela são feitas, evidências são exportadas de diversos sistemas e organizadas em pastas.

Essa abordagem tem três problemas: é trabalhosa, é suscetível a erros e mostra um snapshot em vez de um estado real. O auditor vê como o sistema estava no momento da documentação - não como ele realmente opera.

Quando AI Agents tomam decisões críticas de negócio, o problema se intensifica. Cada decisão individual do agente precisa ser rastreável, o que exige uma [governance](/br/governance/) clara. Com milhares de decisões por mês, a documentação manual deixa de ser viável.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Resumo - Cert-Ready by Design</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Cert-Ready by Design significa que a prontidão para auditoria é um princípio arquitetônico, não um projeto de documentação retrospectivo.</li>
<li>Controles são objetos de dados de primeira classe com geração automática de evidências, versionamento de regras e status ao vivo para auditores.</li>
<li>ISACA (2023) relata que organizações com monitoramento contínuo de controles reduzem o tempo de preparação para auditoria em até 65%.</li>
<li>O mapeamento de frameworks cobre ISA, NBC/CPC e conformidade fiscal - evidências falam a linguagem que auditores compreendem.</li>
<li>Resultado: a auditoria do processamento assistido por IA leva horas em vez de semanas, com evidências completas e à prova de manipulação.</li>
</ul>
</div>

## O que Cert-Ready by Design significa

Cert-Ready by Design inverte a abordagem: a prontidão para auditoria não é um processo posterior, mas um princípio arquitetônico. Controles são objetos de dados técnicos no sistema. Evidências são geradas automaticamente. Auditores veem status ao vivo em vez de snapshot.

### Controles como objetos de dados de primeira classe

Na arquitetura Cert-Ready, cada controle é um objeto de dados técnico com atributos definidos:

| Elemento | Função |
|---------|----------|
| Control_ID | Identificação única do controle |
| Technical_Implementation | Implementação técnica concreta (ex.: RLS-Policy, API-Check, limiar de confiança) |
| Rule_Version | Versão da lógica de decisão subjacente |
| Evidence_Generator | Mecanismo automático de verificação que gera evidências |
| Evidence_History | Resultados de verificação historicizados com timestamp |
| Auditor_View | Visualização com drill-down até a implementação |

Controles não são documentos Word em uma pasta do SharePoint. São objetos técnicos que vivem no sistema, são verificados automaticamente e refletem seu status em tempo real.

### Geração automática de evidências

Evidências não são compiladas retrospectivamente. São geradas automaticamente - a cada decisão do agente, a cada alteração de regra, a cada evento do sistema.

Um exemplo: o agente processa uma nota fiscal de entrada. O Decision Layer aplica a regra NF-7890 na versão 4.2. Confiança: 97%. Resultado: proposta de lançamento na conta 4400, centro de custo 1200. Sem escalação (confiança acima do limiar, valor abaixo do limite).

A evidência para esse processo é gerada automaticamente: dados de entrada, regra aplicada com versão, valor de confiança, decisão de roteamento, resultado, timestamp. Essa evidência é imutável e vinculada ao comprovante contábil.

### Auditor Portal

Auditores veem no Auditor Portal o status ao vivo de todos os controles. Sem exportação de PDF, sem snapshot - o estado atual do sistema.

O Auditor Portal oferece drill-down: da visão geral dos controles (dashboard semáforo: verde/amarelo/vermelho) ao controle individual, à implementação técnica concreta e ao histórico de evidências.

### Mapeamento de frameworks

Controles são mapeados para padrões de auditoria estabelecidos:

**ISA (International Standards on Auditing):** Para auditorias de demonstrações financeiras. Os controles representam os controles internos que o auditor avalia no âmbito de sua auditoria.

**NBC/CPC (Normas Brasileiras de Contabilidade):** Para auditorias no contexto brasileiro. As implementações técnicas dos controles são mapeadas para as exigências das NBC TAs e pronunciamentos do CPC. Em Portugal, o mapeamento equivalente é feito para o SNC (PT: Sistema de Normalização Contabilística).

**Conformidade fiscal:** A versionação dos conjuntos de regras, a imutabilidade do Audit Trail e a rastreabilidade de cada decisão contábil atendem às exigências da legislação fiscal brasileira, incluindo o SPED (Sistema Público de Escrituração Digital) e obrigações acessórias.

Esse mapeamento de frameworks garante que as evidências geradas automaticamente falam a linguagem que auditores compreendem.

## Cert-Ready na prática

Uma firma de auditoria realiza a auditoria de demonstrações financeiras em um cliente. O cliente utiliza AI Agents para o processamento de documentos.

O auditor abre o Auditor Portal. Ele vê: 12 controles para o processamento de documentos, todos verdes. Ele clica no controle "PD-003: Completude dos comprovantes contábeis". Ele vê: a implementação técnica (API-Check contra entrada de documentos), a versão da regra atual, as evidências dos últimos 12 meses (todas as verificações automáticas aprovadas), a média de confiança e a taxa de escalação.

Ele pode fazer drill-down: verificar documentos individuais por amostragem, rastrear o caminho decisório, consultar a regra aplicada na versão vigente no momento da decisão.

O resultado: a auditoria do processamento assistido por IA leva horas em vez de semanas. As evidências são completas, geradas automaticamente e à prova de manipulação.

Mais informações: [Decision Layer explicado](/br/revista/decision-layer-explicado/) | [Governance Dashboard](/br/revista/ia-governance-dashboard/)

<a href="/br/contato/" target="_blank" rel="noopener noreferrer">Agendar reunião</a> - Mostramos o Auditor Portal ao vivo.

--- ChatGPT sem login na empresa: Do risco à infraestrutura ---
> Por que o uso descontrolado de ChatGPT coloca empresas em risco e como uma infraestrutura de chat conforme à LGPD resolve o problema.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Resumo - ChatGPT sem login: risco corporativo</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Colaboradores usando ferramentas públicas de IA sem supervisão da TI geram Shadow AI - prompts são processados em servidores sem controle, potencialmente usados para treinamento, sem Audit Trail.</li>
<li>Proibir IA não funciona. A solução é uma infraestrutura de chat agnóstica de modelo sob controle corporativo, melhor que a alternativa pública.</li>
<li>Verizon DBIR (2024) constatou que 74% das violações de dados envolvem um fator humano - o uso descontrolado de IA cria uma categoria inteiramente nova de exposição de dados.</li>
<li>O valor real surge quando a interface de chat evolui para plataforma de agentes - processando documentos, orquestrando workflows, respondendo consultas de conhecimento.</li>
<li>Três decisões arquiteturais estão pendentes: modelo de hosting, estratégia de modelos e roadmap de agentes. Cada dia de atraso significa mais exposição a Shadow AI.</li>
</ul>
</div>

## O problema não é o ChatGPT. O problema é a perda de controle.

Em praticamente todas as empresas, colaboradores usam ferramentas públicas de IA sem que ninguém saiba. Com contas pessoais do ChatGPT, por sites duvidosos que prometem "ChatGPT sem login", copiando e colando no Claude.ai ou Gemini, sem conhecimento do TI, sem aprovação, sem qualquer governança. A barreira de entrada é zero, o ganho de produtividade é imediato. O resultado: Shadow IT em larga escala.

O risco não é teórico. Prompts enviados a serviços públicos de IA são processados em servidores fora do controle da empresa. Sem um contrato enterprise, os dados inseridos podem ser usados para treinamento de modelos. Especialmente perigosos são os numerosos sites de terceiros que oferecem "ChatGPT grátis e sem login": eles carecem até da proteção mínima que uma conta direta com a OpenAI oferece. Informações confidenciais (dados salariais, minutas de contratos, documentos estratégicos) acabam em sistemas sobre os quais a empresa não tem acesso, direito de exclusão ou capacidade de auditoria. No Brasil, isso pode violar a LGPD (PT: RGPD), com sanções aplicáveis pela ANPD (PT: CNPD).

Os departamentos de TI enfrentam um dilema: proibir não funciona, pois o benefício é evidente demais e os colaboradores encontram alternativas. Tolerar não é opção, porque a LGPD (PT: RGPD), a representação dos trabalhadores (sindicatos/CRE; PT: Comissão de Trabalhadores) e a auditoria interna acabarão fazendo perguntas.

A resposta não é proibição nem tolerância. A resposta é infraestrutura.


## O que os colaboradores realmente precisam e por que usam ChatGPT escondido

Quando colaboradores recorrem ao ChatGPT apesar da proibição, isso revela sobretudo uma coisa: a empresa não oferece alternativa. O que os colaboradores procuram é uma interface simples que funcione imediatamente, entenda linguagem natural e ajude no trabalho diário. Resumir documentos, redigir e-mails, analisar arquivos, responder perguntas sobre normas internas.

Essa necessidade é legítima. Mas deve ser atendida em um ambiente controlado pela empresa, não em servidores de terceiros que se anunciam como "ChatGPT sem login" e cujo modelo de negócio é a coleta de dados.

Uma infraestrutura de chat corporativa oferece a cada colaborador exatamente essa interface, com uma diferença fundamental: os dados permanecem na infraestrutura da empresa. Prompts não são transmitidos a terceiros. O uso é registrado e auditável. As permissões de acesso seguem o modelo de perfis existente. E o mais importante: os colaboradores não precisam mais recorrer a ferramentas externas, pois têm uma alternativa melhor e oficial.


## Por que agnóstico de modelo é a única abordagem sensata

O erro mais comum ao implementar IA corporativa: definir um único modelo de um único fornecedor como padrão. ChatGPT Enterprise para todos, Copilot de forma generalizada ou um contrato fixo com Claude.

O problema: os LLMs evoluem mais rápido do que qualquer ciclo de aquisição corporativa. O melhor modelo para análise de texto hoje pode ser superado por um mais barato ou mais potente em seis meses. Quem constrói toda a sua infraestrutura sobre um único fornecedor assume vendor lock-in na decisão tecnológica mais crítica dos próximos anos.

Uma arquitetura agnóstica de modelo resolve isso: uma interface de chat unificada para todos os colaboradores. Por trás, uma camada de orquestração que roteia entre modelos: Claude, ChatGPT, Gemini, Llama, Mistral, DeepSeek, gpt-oss. Dependendo do caso de uso, custo ou requisitos de proteção de dados, o modelo adequado é selecionado automaticamente. As trocas de modelo acontecem sem alterações na interface e sem necessidade de retreinar os colaboradores.

Gosign constrói essa [infraestrutura de IA](/br/servicos/infraestrutura/) de forma agnóstica de modelo e aberta em plataforma, seja como deploy na nuvem em Azure ou GCP, ou totalmente self-hosted na infraestrutura do cliente.


## Da interface de chat à plataforma de agentes

Uma interface de chat conforme à LGPD (PT: RGPD) é o ponto de entrada. Mas a verdadeira geração de valor começa quando a interface não apenas responde perguntas, mas aciona processos.

Essa é a transição do chat para a infraestrutura de agentes.

Na prática: um colaborador envia um atestado médico pelo chat. Um [Document Agent](/br/servicos/ai-agents/) lê o documento, extrai os dados relevantes, verifica prazos conforme o regulamento interno (CLT no Brasil, Código do Trabalho em Portugal) e prepara o lançamento no SAP. Um [Workflow Agent](/br/servicos/ai-agents/) orquestra o processo seguinte: notificar o gestor, verificar cobertura do posto, calcular o afastamento remunerado. Um Knowledge Agent responde as dúvidas do colaborador com base nas políticas internas vigentes.

A interface de chat se torna o ponto de entrada unificado para os três tipos de agentes. O colaborador vê uma conversa simples. Nos bastidores, a infraestrutura orquestra agentes documentais, de workflow e de conhecimento, com um Audit Trail completo e [Human-in-the-Loop](/br/governance/) nas decisões críticas.


## Governance não é uma funcionalidade. Governance é a arquitetura.

Cada uso não controlado de ChatGPT gera um ponto cego: quais dados foram inseridos? Quais respostas foram usadas para decisões? Quem perguntou o quê e quando?

Em uma infraestrutura de chat corporativa com [Governance by Design](/br/governance/), esses pontos cegos não existem.

Cada interação é registrada: prompt, resposta, modelo utilizado, timestamp, perfil do usuário. Ações com impacto em decisões passam pelo [Decision Layer](/br/decision-layer/), que separa análise e tomada de decisão. Processos críticos exigem aprovação humana, incorporada arquiteturalmente como Human-in-the-Loop.

Para a representação dos trabalhadores (sindicatos/CRE; PT: Comissão de Trabalhadores): transparência sobre o uso de IA na organização, documentada e verificável a qualquer momento. Para a auditoria interna: um Audit Trail completo. Para o Encarregado de Proteção de Dados (DPO): tratamento de dados em ambiente controlado, sem transferências a terceiros, documentação conforme à LGPD (PT: RGPD).


## Avaliação de risco: IA pública vs. infraestrutura corporativa

| Categoria de risco | ChatGPT público / sites de terceiros | Infraestrutura de chat corporativa |
|---|---|---|
| Soberania de dados | Sem controle - dados em servidores externos | Controle total - self-hosted ou nuvem UE |
| Treinamento de modelo | Dados podem ser usados para treinamento | Sem treinamento com dados corporativos |
| Audit Trail | Nenhum | Completo - prompt, resposta, usuário, modelo |
| Conformidade LGPD | Não garantida | Imposta pela arquitetura |
| Controle de acesso | Contas pessoais, sem RBAC | SSO com acesso baseado em funções |
| Integração de agentes | Não possível | Document, Workflow, Knowledge Agents |
| Vendor lock-in | Vinculado a um fornecedor | Agnóstico de modelo - troca sem retreinamento |

## O que o departamento de TI precisa decidir agora

A pergunta não é mais se os colaboradores usam IA. A pergunta é se fazem isso em um ambiente controlado ou descontrolado.

Três decisões arquiteturais estão pendentes.

Primeira: hosting. A infraestrutura de chat deve rodar no Azure, GCP ou totalmente self-hosted? A resposta depende do cenário de TI existente e dos requisitos de proteção de dados. As três opções são tecnicamente equivalentes: não há comprometimentos arquiteturais no self-hosting.

Segunda: estratégia de modelos. Quais modelos devem estar disponíveis e como o roteamento é governado? Uma arquitetura agnóstica de modelo mantém todas as opções abertas e evita vendor lock-in.

Terceira: roadmap de agentes. A interface de chat deve se conectar com agentes que processam documentos e orquestram workflows? Se sim (e a resposta é quase sempre sim), a infraestrutura precisa ser projetada para isso desde o início.

Na Gosign, construímos exatamente essa infraestrutura: agnóstica de modelo, conforme à LGPD (PT: RGPD), com integração de agentes e Governance by Design. Do conceito à interface de chat produtiva em 4-6 semanas. Na [infraestrutura do cliente](/br/servicos/infraestrutura/), sob total controle do cliente. Sem SaaS, sem vendor lock-in.

--- Claude Code como controle de segurança no workflow DevOps ---
> Runbook DevOps para Security Reviews automatizados com Claude Code: instalação, Custom Commands, Audit Scripts e integração CI.

Stacks de aplicações self-hosted modernos são compostos por muitos componentes: Supabase Platform, camada de aplicação Next.js, Edge Functions, Background Jobs e APIs externas. Com cada componente, aumenta a probabilidade de erros de configuração, vazamento de secrets, políticas ausentes e endpoints desprotegidos.

Scanners de segurança tradicionais verificam regras estáticas. Eles encontram `service_role` em um arquivo `.env`, mas não reconhecem que uma nova Server Action está sem o mesmo check de ownership presente em todas as outras Server Actions. Eles reportam portas abertas, mas não reconhecem que uma alteração de firewall na semana passada, junto com um novo container, abriu um caminho de acesso não intencional.

**O Claude Code preenche essa lacuna como camada de análise contextual sobre todo o stack.**

O Claude Code não substitui verificações determinísticas. Ele as complementa ao interpretar os resultados, reconhecer correlações e priorizar recomendações.

Este runbook descreve como o Claude Code é concretamente instalado, configurado e integrado no workflow DevOps.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Resumo - Artigo 5 de 6 da série DevOps Runbook</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Claude Code apenas no servidor de auditoria</li>
<li>Modelo de três camadas</li>
<li>Custom Commands definem o escopo da revisão</li>
<li>Modo headless restrito a Read/Grep/Glob</li>
<li>Auditoria cron semanal mais revisões de PR</li>
</ul>
</div>

## Sumário da série

Este guia faz parte da nossa série de runbooks DevOps para stacks de aplicações self-hosted.

1. [Supabase Self-Hosting Runbook](/br/revista/supabase-self-hosting/)
2. [Next.js sobre Supabase com segurança](/br/revista/nextjs-supabase-configuracao-segura/)
3. [Supabase Edge Functions com segurança](/br/revista/supabase-edge-functions-seguranca/)
4. [Trigger.dev Background Jobs com segurança](/br/revista/trigger-dev-background-jobs/)
5. [Claude Code como controle de segurança no workflow DevOps](/br/revista/claude-code-security-devops/) - este artigo
6. [Security Baseline para todo o stack](/br/revista/security-baseline-stack/)

Os primeiros quatro artigos descrevem os componentes individuais. Este artigo descreve a **camada de controle de segurança sobre eles**.

## Visão geral da arquitetura

O Claude Code trabalha **não no servidor de produção**, mas no servidor de auditoria (veja [Artigo 1](/br/revista/supabase-self-hosting/)). Ele tem acesso Read-Only aos dados que analisa.

```
Servidor de produção (supabase-prod)
   |
   +-- Supabase Stack
   +-- Next.js App
   +-- Edge Functions
   +-- Trigger.dev
   |
   +---- SSH (read-only) ----> Servidor de auditoria (audit-runner)
                                   |
                                   +-- Verificações determinísticas
                                   |   +-- Port Scans (nmap)
                                   |   +-- Firewall Diff (iptables-save)
                                   |   +-- Versões de containers (docker images)
                                   |   +-- Status RLS (psql)
                                   |   +-- npm audit
                                   |   +-- Verificações de código baseadas em grep
                                   |
                                   +-- Claude Code (headless)
                                   |   +-- Analisa resultados das verificações
                                   |   +-- Lê Git Diffs
                                   |   +-- Verifica configs contra runbooks
                                   |   +-- Cria relatório priorizado
                                   |
                                   +-- Relatório -> Equipe DevOps (humano decide)
```

**O Claude Code não executa alterações no sistema de produção. Nenhum deployment, nenhuma rotação de secrets, nenhuma parada de containers.**

### Comparação das três camadas

| Propriedade | Verificações determinísticas | Regras de runbooks | Análise Claude |
|---|---|---|---|
| Entrada | Comandos do sistema (nmap, grep) | Arquivos Markdown | Output das camadas 1+2 |
| Saída | Fatos (aberto/fechado, presente/ausente) | Estado desejado (DEVE) | Relatório priorizado |
| Frequência | Diária (cron) | Estática (atualização com mudanças) | Semanal + em PR |
| Falsos positivos | Nenhum (objetivo) | Nenhum (regras definidas) | Possíveis (interpretação) |
| Detecção de drift | Padrões conhecidos | Nenhum (referência) | Padrões desconhecidos |

## Princípio fundamental: três níveis de verificação de segurança

```
Nível 1: Verificações determinísticas (Scripts)
   -> Resultados objetivos e repetíveis
   -> Exemplo: "Porta 5432 está acessível externamente" = Fato

Nível 2: Regras de runbook (arquivos Markdown)
   -> Estado desejado definido do stack
   -> Exemplo: "PostgreSQL deve escutar apenas em 10.0.1.10"

Nível 3: Análise contextual do Claude Code (headless)
   -> Interpreta resultados, reconhece correlações
   -> Exemplo: "Porta 5432 está aberta E o novo container
     tem uma conexão direta com o DB. Isso é um problema."
```

Os níveis se constroem um sobre o outro. O Claude recebe os resultados do Nível 1 e as regras do Nível 2 como input e cria a partir disso seu review contextual.

## Parte A - Configurar o Claude Code

## A1 - Instalação e configuração no servidor de auditoria

### Implementação

O Claude Code é instalado no servidor de auditoria, não no servidor de produção.

```bash
# Auf dem audit-runner Server

# Node.js installieren (falls nicht vorhanden)
curl -fsSL https://deb.nodesource.com/setup_20.x | sudo bash -
apt-get install -y nodejs

# Claude Code installieren
npm install -g @anthropic-ai/claude-code

# API Key konfigurieren
# Eigener API Key mit Budget-Limit für CI/CD
export ANTHROPIC_API_KEY="sk-ant-..."

# In .bashrc oder .env für den audit-user persistieren
echo 'export ANTHROPIC_API_KEY="sk-ant-..."' >> /home/audit/.bashrc
```

**Testar o Headless Mode:**

```bash
# Einfacher Test: funktioniert Claude Code non-interaktiv?
echo "Hello" | claude -p "Antworte mit OK wenn du das lesen kannst" \
  --output-format text

# Erwartung: "OK" oder ähnliche Bestätigung
```

### Condição verificável

```bash
# Claude Code installiert?
claude --version
# Erwartung: Versionsnummer

# API Key gesetzt?
test -n "$ANTHROPIC_API_KEY" && echo "OK" || echo "FEHLT"

# Headless Mode funktioniert?
claude -p "Sage nur: OK" --output-format text --max-turns 1 2>/dev/null
# Erwartung: "OK"
```

### Cenário de falha

Quando o Claude Code roda no servidor de produção e tem acesso ao Bash, um prompt defeituoso poderia teoricamente executar comandos no sistema de produção. No servidor de auditoria, o Claude Code tem acesso apenas aos relatórios e cópias de configuração coletadas lá, não ao sistema em produção.

## A2 - Configurar Custom Security Review Command

### Implementação

O Claude Code suporta Custom Commands via arquivos Markdown em `.claude/commands/`. Esses Commands definem o contexto e as regras de verificação para o Security Review.

```bash
# Im Infrastruktur-Repository
mkdir -p .claude/commands
```

```markdown
# .claude/commands/security-review.md

Du bist Security Reviewer für einen self-hosted Stack bestehend aus:
- Supabase (PostgreSQL, PostgREST, GoTrue, Kong, Edge Functions)
- Next.js (App-Schicht, Server Actions, Route Handler)
- Trigger.dev v3 (Background Jobs, self-hosted)
- Tudo em infraestrutura própria (ex. Locaweb, Magalu Cloud)

Du erhältst den Output der deterministischen Security Checks und die
aktuellen Konfigurationsdateien.

Prüfe folgendes:

## Infrastruktur (Artikel 1)
- Sind unerwartete Ports von aussen erreichbar?
- Hat sich die Firewall gegenüber der Baseline geändert?
- Sind Container-Versionen gepinnt und aktuell?
- Ist das TLS-Zertifikat noch mindestens 14 Tage gültig?
- Liegt das letzte Backup weniger als 26 Stunden zurück?

## Next.js (Artikel 2)
- Taucht service_role in NEXT_PUBLIC Variablen oder im Client-Bundle auf?
- Haben alle Server Actions einen getUser() Auth Check?
- Haben alle Route Handler einen getUser() Auth Check?
- Existiert middleware.ts mit getUser() (nicht getSession())?
- Sind Security Headers in next.config.js gesetzt?

## Edge Functions (Artikel 3)
- Haben alle Webhook-Functions eine Signaturprüfung?
- Gibt es Functions mit Business-Logik statt Integrations-Logik?
- Ist CORS korrekt konfiguriert (kein Wildcard in Produktion)?
- Gibt es hardcoded Secrets im Function-Code?

## Trigger.dev (Artikel 4)
- Haben alle Tasks maxDuration und concurrencyLimit?
- Haben Tasks mit externen API-Calls Idempotency Keys?
- Nutzen Tasks nur die DB-Felder die sie brauchen (kein SELECT *)?
- Gibt es console.log statt dem Trigger.dev logger?

## Stackübergreifend
- Gibt es Architektur-Drift? (Business-Logik in Edge Functions,
  Langläufer in Server Actions, etc.)
- Sind die Änderungen der letzten Woche konsistent mit der
  bestehenden Architektur?
- Gibt es neue Tabellen ohne RLS?
- Gibt es Muster die auf systematische Probleme hindeuten?

Erstelle einen priorisierten Bericht:
- KRITISCH: sofort handeln (Daten-Leak möglich, Port offen, Secret exponiert)
- WARNUNG: diese Woche lösen (fehlende Checks, Drift, veraltete Packages)
- INFO: bei Gelegenheit verbessern (Code-Qualität, fehlende Tests)

Für jedes Finding: Was ist das Problem, warum ist es ein Risiko,
was ist die konkrete Lösung.
```

### Condição verificável

```bash
# Custom Command existiert?
test -f .claude/commands/security-review.md && echo "OK" || echo "FEHLT"

# Command wird von Claude Code erkannt?
claude -p "/security-review" --max-turns 1 2>/dev/null | head -5
# Erwartung: Claude beginnt mit der Analyse
```

## A3 - CLAUDE.md como contexto do projeto

### Implementação

O Claude Code lê automaticamente o arquivo `CLAUDE.md` no diretório do projeto. Esse arquivo fornece ao Claude o contexto permanente sobre o seu stack.

```markdown
# CLAUDE.md (im Root des Infrastruktur-Repos)

## Stack-Überblick
Self-hosted Supabase + Next.js + Edge Functions + Trigger.dev v3
em infraestrutura própria (ex. Locaweb, Magalu Cloud).

## Server
- supabase-prod: 10.0.1.10 (Supabase, Next.js, Edge Functions)
- audit-runner: 10.0.1.11 (Security Checks, Claude Code, Monitoring)
- trigger-server: separater Docker-Stack für Trigger.dev v3

## Sicherheitsregeln
- service_role Key darf NUR in: lib/supabase/admin.ts und trigger/lib/supabase.ts
- NEXT_PUBLIC_* darf NUR enthalten: SUPABASE_URL und SUPABASE_ANON_KEY
- Alle public-Tabellen müssen RLS aktiviert haben
- Alle Server Actions und Route Handler müssen getUser() aufrufen
- Alle Webhook Edge Functions müssen Signaturen prüfen
- Alle Trigger.dev Tasks müssen maxDuration und concurrencyLimit haben
- PostgreSQL nur auf 10.0.1.10:5432 (internes Interface)
- Supabase Studio nicht von aussen erreichbar
- Trigger.dev Dashboard nicht von aussen erreichbar

## Deployment
- Infrastruktur wird nur über Git deployed (kein manuelles SSH-Editing)
- Edge Functions werden als Dateien in volumes/functions/ abgelegt
- Trigger.dev Tasks werden über npx trigger.dev deploy --self-hosted deployed

## Verzeichnisstruktur
- app/ = Next.js App (Server Actions, Route Handler, Pages)
- lib/supabase/ = Supabase Client Konfiguration
- middleware.ts = Auth Middleware
- volumes/functions/ = Supabase Edge Functions
- trigger/tasks/ = Trigger.dev Tasks
- infra/ = docker-compose, nginx/caddy, Firewall Configs
- scripts/ = Audit Scripts, Backup, Restore
- runbooks/ = Sicherheits-Runbooks
```

Quem combina a [abordagem CLAUDE.md com as regras de segurança do Artigo 2](/br/revista/nextjs-supabase-configuracao-segura/) obtém uma base de contexto completa para reviews automatizados.

## Parte B - O workflow de auditoria completo

Aqui se junta o que os [Artigos 1 a 4](/br/revista/supabase-self-hosting/) prepararam. Cada artigo tem seus próprios scripts de verificação. O Artigo 5 os reúne e passa o output ao Claude Code.

## B1 - O script de auditoria completo

### Implementação

Este script coleta todos os resultados das verificações determinísticas e os passa ao Claude Code no Headless Mode.

```bash
#!/bin/bash
# scripts/full-security-audit.sh
# Läuft auf dem audit-runner Server

set -euo pipefail

PROD_HOST="10.0.1.10"
REPORT_DIR="/opt/audit/reports"
DATE=$(date +%Y-%m-%d)
REPORT_FILE="${REPORT_DIR}/audit-input-${DATE}.md"

mkdir -p "$REPORT_DIR"

echo "=== Gesamt-Security-Audit ${DATE} ===" | tee "$REPORT_FILE"

# -------------------------------------------
# EBENE 1: Deterministische Checks
# -------------------------------------------

echo -e "\n# Deterministische Check-Ergebnisse\n" >> "$REPORT_FILE"

# --- Infrastruktur (Artikel 1) ---
echo "## Infrastruktur" >> "$REPORT_FILE"

echo "### Offene Ports (extern)" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
nmap -p 22,80,443,3000,3040,5432,5433,8000,9000 app.example.com \
  --open -oG - 2>/dev/null >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"

echo "### Firewall Diff gegen Baseline" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "iptables-save" | \
  diff /opt/baselines/firewall-baseline.txt - >> "$REPORT_FILE" 2>&1 || true
echo '```' >> "$REPORT_FILE"

echo "### Container Status" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "docker compose ps --format 'table {{.Name}}\t{{.Status}}\t{{.Image}}'" \
  >> "$REPORT_FILE" 2>&1
echo '```' >> "$REPORT_FILE"

echo "### TLS Zertifikat" >> "$REPORT_FILE"
CERT_EXPIRY=$(echo | openssl s_client -connect app.example.com:443 2>/dev/null | \
  openssl x509 -noout -enddate 2>/dev/null | cut -d= -f2)
CERT_EPOCH=$(date -d "$CERT_EXPIRY" +%s 2>/dev/null || echo 0)
NOW_EPOCH=$(date +%s)
DAYS_LEFT=$(( (CERT_EPOCH - NOW_EPOCH) / 86400 ))
echo "Ablauf: ${CERT_EXPIRY} (${DAYS_LEFT} Tage)" >> "$REPORT_FILE"

echo "### Backup Status" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "ls -lh /opt/backups/*.gpg 2>/dev/null | tail -3" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"

echo "### RLS Status" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "docker compose exec -T postgres psql -U postgres -c \
  \"SELECT tablename, rowsecurity FROM pg_tables WHERE schemaname = 'public' ORDER BY tablename;\"" \
  >> "$REPORT_FILE" 2>&1
echo '```' >> "$REPORT_FILE"

echo "### Disk Usage" >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "df -h / | tail -1" >> "$REPORT_FILE"

# --- Next.js (Artikel 2) ---
echo -e "\n## Next.js App-Schicht" >> "$REPORT_FILE"

echo "### service_role im Client Code" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "cd /opt/app && grep -rn 'SERVICE_ROLE\|service_role' app/ \
  --include='*.ts' --include='*.tsx' | grep -v 'lib/supabase/admin.ts' | grep -v node_modules" \
  >> "$REPORT_FILE" 2>&1 || echo "Keine Treffer" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"

echo "### NEXT_PUBLIC mit Secrets" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "cd /opt/app && grep 'NEXT_PUBLIC_' .env* 2>/dev/null | \
  grep -iE 'service_role|secret|private|database'" \
  >> "$REPORT_FILE" 2>&1 || echo "Keine Treffer" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"

echo "### Server Actions ohne Auth" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "cd /opt/app && for file in \$(grep -rl \"'use server'\" app/ --include='*.ts'); do
  if ! grep -q 'getUser' \"\$file\"; then
    echo \"WARNUNG: \$file\"
  fi
done" >> "$REPORT_FILE" 2>&1 || echo "Keine Treffer" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"

echo "### Route Handler ohne Auth" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "cd /opt/app && for file in \$(find app/api -name 'route.ts' 2>/dev/null); do
  if ! grep -q 'getUser' \"\$file\"; then
    echo \"WARNUNG: \$file\"
  fi
done" >> "$REPORT_FILE" 2>&1 || echo "Keine Treffer" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"

echo "### npm audit" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "cd /opt/app && npm audit --audit-level=high 2>&1 | tail -20" \
  >> "$REPORT_FILE" 2>&1
echo '```' >> "$REPORT_FILE"

# --- Edge Functions (Artikel 3) ---
echo -e "\n## Edge Functions" >> "$REPORT_FILE"

echo "### Webhook Functions ohne Signaturprüfung" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "for dir in /opt/supabase/volumes/functions/*-webhook/; do
  [ -d \"\$dir\" ] || continue
  name=\$(basename \"\$dir\")
  if ! grep -qE 'signature|verify|hmac|crypto' \"\$dir/index.ts\" 2>/dev/null; then
    echo \"KRITISCH: \$name hat keine Signaturprüfung\"
  else
    echo \"OK: \$name\"
  fi
done" >> "$REPORT_FILE" 2>&1
echo '```' >> "$REPORT_FILE"

echo "### Hardcoded Secrets in Functions" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "grep -rn 'sk_live\|sk_test\|whsec_\|Bearer ey' \
  /opt/supabase/volumes/functions/ --include='*.ts' 2>/dev/null" \
  >> "$REPORT_FILE" 2>&1 || echo "Keine Treffer" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"

# --- Trigger.dev (Artikel 4) ---
echo -e "\n## Trigger.dev Tasks" >> "$REPORT_FILE"

echo "### Tasks ohne maxDuration" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "cd /opt/app && for file in trigger/tasks/*.ts; do
  name=\$(basename \"\$file\" .ts)
  if ! grep -q 'maxDuration' \"\$file\" 2>/dev/null; then
    echo \"WARNUNG: \$name\"
  fi
done" >> "$REPORT_FILE" 2>&1
echo '```' >> "$REPORT_FILE"

echo "### Tasks ohne Concurrency Limit" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "cd /opt/app && for file in trigger/tasks/*.ts; do
  name=\$(basename \"\$file\" .ts)
  if ! grep -qE 'concurrencyLimit|queue:' \"\$file\" 2>/dev/null; then
    echo \"WARNUNG: \$name\"
  fi
done" >> "$REPORT_FILE" 2>&1
echo '```' >> "$REPORT_FILE"

# --- Git Änderungen ---
echo -e "\n## Code-Änderungen (letzte 7 Tage)" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "cd /opt/app && git log --oneline --since='7 days ago'" \
  >> "$REPORT_FILE" 2>&1
ssh deploy@${PROD_HOST} "cd /opt/app && git diff HEAD~10 --stat 2>/dev/null" \
  >> "$REPORT_FILE" 2>&1
echo '```' >> "$REPORT_FILE"

# -------------------------------------------
# EBENE 2: Runbook-Regeln (als Kontext)
# -------------------------------------------

echo -e "\n# Aktive Runbook-Regeln\n" >> "$REPORT_FILE"
cat runbooks/security-baseline.md >> "$REPORT_FILE" 2>/dev/null || \
  echo "security-baseline.md nicht gefunden" >> "$REPORT_FILE"

# -------------------------------------------
# EBENE 3: Claude Code Analyse
# -------------------------------------------

echo ""
echo "=== Deterministische Checks abgeschlossen ==="
echo "=== Starte Claude Code Analyse ==="
echo ""

# Claude Code im Headless Mode aufrufen
# --allowedTools einschränken: nur Lesen, kein Bash, kein Schreiben
CLAUDE_OUTPUT=$(cat "$REPORT_FILE" | claude -p \
  "Du erhältst den vollständigen Security-Audit-Report unseres self-hosted Stacks.
Analysiere ihn gemäss den Regeln in .claude/commands/security-review.md.
Erstelle einen priorisierten Bericht mit KRITISCH / WARNUNG / INFO.
Für jedes Finding: Problem, Risiko, konkrete Lösung." \
  --allowedTools "Read,Grep,Glob" \
  --append-system-prompt "Du bist ein Senior Security Engineer. Antworte auf Deutsch. Sei konkret und priorisiere strikt." \
  --output-format text \
  --max-turns 5 \
  2>/dev/null)

# Report speichern
CLAUDE_REPORT="${REPORT_DIR}/claude-review-${DATE}.md"
echo "$CLAUDE_OUTPUT" > "$CLAUDE_REPORT"

echo ""
echo "=== Claude Code Review abgeschlossen ==="
echo "Report: $CLAUDE_REPORT"

# Bei kritischen Findings: Alert
if echo "$CLAUDE_OUTPUT" | grep -qi "KRITISCH"; then
  echo "$CLAUDE_OUTPUT" | mail -s "KRITISCH: Security Review ${DATE}" ops@example.com
  echo "Alert gesendet an ops@example.com"
fi
```

### Condição verificável

```bash
# Script ausführbar?
test -x scripts/full-security-audit.sh && echo "OK" || echo "NICHT AUSFÜHRBAR"

# Letzter Audit-Report vorhanden?
ls -la /opt/audit/reports/claude-review-$(date +%Y-%m-%d).md 2>/dev/null
# Erwartung: Datei von heute

# Report enthält die erwarteten Sektionen?
grep -c "KRITISCH\|WARNUNG\|INFO" /opt/audit/reports/claude-review-$(date +%Y-%m-%d).md
# Erwartung: mindestens 1
```

## B2 - Quando a auditoria é executada

### Três pontos de disparo

```
1. Cron semanal (domingo 6:00h)
   -> Auditoria completa sobre todo o stack
   -> Resultado: relatório priorizado para a semana

2. Em Pull Requests (CI/CD)
   -> Apenas os arquivos alterados
   -> Resultado: comentário de review no PR

3. Ad-hoc (manual)
   -> Após incidentes, deployments maiores, alterações de infraestrutura
   -> Resultado: análise imediata
```

**Cron semanal:**

```bash
# crontab auf dem audit-runner
0 6 * * 0 /opt/audit/scripts/full-security-audit.sh >> /var/log/security-audit.log 2>&1
```

**PR Review (pipe do Git Diff para o Claude):**

```bash
#!/bin/bash
# scripts/pr-security-review.sh
# Wird vom CI bei jedem PR aufgerufen

DIFF=$(git diff origin/main...HEAD)

if [ -z "$DIFF" ]; then
  echo "Kein Diff, kein Review nötig"
  exit 0
fi

echo "$DIFF" | claude -p \
  "Review diesen Git Diff auf Sicherheitsprobleme.
Prüfe insbesondere:
- service_role Nutzung in Client-Code
- Server Actions ohne Auth Check
- Edge Functions ohne Signaturprüfung
- Trigger.dev Tasks ohne maxDuration
- Hardcoded Secrets
- Neue API Endpoints ohne Rate Limiting

Antworte NUR wenn du ein konkretes Problem findest.
Wenn alles in Ordnung ist, sage: Keine Sicherheitsprobleme gefunden." \
  --allowedTools "Read,Grep,Glob" \
  --output-format text \
  --max-turns 3
```

**Review ad-hoc:**

```bash
# Manuell nach einem Incident
cd /opt/infra-repo
claude -p "Prüfe den aktuellen Zustand des Repositories auf Sicherheitsprobleme. \
Fokus auf die letzten 5 Commits." \
  --allowedTools "Read,Grep,Glob,Bash(git log*),Bash(git diff*)" \
  --max-turns 10
```

### Condição verificável

```bash
# Cron Job aktiv?
crontab -l | grep "full-security-audit"
# Erwartung: Eintrag vorhanden

# Letzter Audit weniger als 8 Tage her?
LAST_REPORT=$(ls -t /opt/audit/reports/claude-review-*.md 2>/dev/null | head -1)
if [ -n "$LAST_REPORT" ]; then
  AGE=$(( ($(date +%s) - $(stat -c %Y "$LAST_REPORT")) / 86400 ))
  echo "Letzter Report: $AGE Tage alt"
  [ "$AGE" -gt 8 ] && echo "WARNUNG: Audit überfällig"
fi
```

## Parte C - O que o Claude pode e o que não pode

## C1 - Onde o Claude Code é especialmente forte

O Claude reconhece correlações que verificações determinísticas não conseguem identificar:

**Reconhecer drift de arquitetura:**
As verificações determinísticas encontram que uma nova Edge Function existe. O Claude reconhece que essa Function contém lógica de negócio que pertence ao [Next.js](/br/revista/nextjs-supabase-configuracao-segura/), porque ela processa input de usuários e transforma dados em vez de receber um evento externo.

**Padrões que ultrapassam limites de arquivos:**
Um `grep` encontra que `getUser()` está ausente em uma Server Action. O Claude reconhece que essa Action é a única de 15 Actions sem o check, e que ela foi adicionada na semana passada em um commit que também alterou três outros arquivos, todos corretos. Isso indica um descuido, não um problema sistemático.

**Priorização:**
As verificações determinísticas produzem uma lista plana de 30 findings. O Claude os agrupa: "Os 5 findings de service_role estão todos na biblioteca Admin e são corretos. Os 2 checks de auth ausentes nos Route Handlers são o risco real, porque afetam endpoints de API públicos."

**Contexto de configuração:**
Um Port Scan mostra que a porta 8000 está aberta. O Claude sabe pelo contexto do stack (CLAUDE.md) que a porta 8000 é a porta interna do Kong, e verifica se ela deveria escutar apenas em localhost.

## C2 - O que o Claude Code não pode e não deve fazer

**O Claude não pode escanear ativamente.** Ele não pode realizar scans de rede, verificar processos em execução ou testar portas externamente. Isso é feito pelas ferramentas determinísticas (nmap, ss, docker ps). O Claude analisa o output delas.

**O Claude não deve escrever em produção.** A restrição `--allowedTools` no Headless Mode garante que o Claude só pode ler:

```bash
# RICHTIG: Nur Lese-Tools erlaubt
claude -p "..." --allowedTools "Read,Grep,Glob"

# FALSCH: Bash erlaubt = Claude kann beliebige Befehle ausführen
claude -p "..." --allowedTools "Read,Grep,Glob,Bash"
```

Quando o Bash é necessário (por exemplo, para `git log`), permitir apenas comandos específicos:

```bash
--allowedTools "Read,Grep,Glob,Bash(git log*),Bash(git diff*)"
```

**O Claude não é determinístico.** O mesmo input pode gerar relatórios levemente diferentes. Por isso, o Claude não substitui verificações determinísticas. Ele interpreta os resultados delas.

> **Estatística:** De acordo com o relatório OWASP de 2024, mais de 34% das violações de segurança resultam de erros de configuração, não de vulnerabilidades no código - exatamente o tipo de problema que a análise contextual é projetada para detectar.


**O Claude não conhece dados em tempo real.** Ele trabalha com os snapshots que lhe são passados no momento da auditoria. Entre a auditoria e a leitura do review, o estado pode ter mudado.

## C3 - Regras de segurança para o Claude Code no CI

```bash
# Auf dem Audit-Server: Claude Code Konfiguration

# 1. Eigener API Key mit Budget-Limit
#    Separater Key, nicht der Entwickler-Key
#    Budget: max. 50 USD/Monat für CI Reviews

# 2. --allowedTools immer einschränken
#    Niemals unbeschränkten Bash-Zugriff in automatisierten Scripts

# 3. --max-turns begrenzen
#    Verhindert Endlosschleifen bei verwirrenden Inputs
#    Empfehlung: 3-5 für PR Reviews, 5-10 für Full Audits

# 4. Output immer in Datei speichern
#    Nicht nur auf stdout, damit der Report nachvollziehbar bleibt

# 5. Claude Code hat keinen SSH-Zugriff auf Produktion
#    Die deterministischen Scripts sammeln die Daten
#    Claude bekommt nur den Text-Output zur Analyse
```

## Checklist de deployment

```
Instalação
  [ ] Claude Code instalado no audit-runner
  [ ] API Key configurada (Key CI separada com limite de orçamento)
  [ ] Headless Mode funciona (teste com claude -p)

Configuração
  [ ] .claude/commands/security-review.md criado
  [ ] CLAUDE.md presente no repositório de infraestrutura
  [ ] --allowedTools restrito a Read,Grep,Glob
  [ ] --max-turns limitado a 5-10

Automação
  [ ] Script de auditoria completo presente e executável
  [ ] Cron Job semanal ativo
  [ ] Script de PR Review integrado ao CI
  [ ] Alerta para findings críticos configurado

Segurança
  [ ] Claude Code roda APENAS no audit-runner
  [ ] Claude Code NÃO tem acesso SSH à produção
  [ ] Sem acesso irrestrito ao Bash em --allowedTools
  [ ] Relatórios são armazenados e arquivados
  [ ] Limite de orçamento definido na API Key
```

## Conclusão

O Claude Code não é um scanner de segurança automático e não substitui verificações determinísticas. Ele é um **analista contextual** que interpreta os resultados de scanners e verificações via grep, reconhece correlações e prioriza recomendações.

O workflow é sempre o mesmo: ferramentas determinísticas coletam fatos, o Claude Code os interpreta, um humano decide. Isso funciona porque cada camada faz o que faz de melhor. Scripts são confiáveis com padrões conhecidos. O Claude reconhece padrões desconhecidos. Humanos tomam decisões.

A combinação dos scripts de verificação dos Artigos 1-4, do Custom Security Review Command e do cron de auditoria semanal resulta em um controle de segurança que detecta tanto riscos conhecidos quanto inesperados.

Quem segue esses princípios junto com uma [arquitetura Cert-Ready-by-Design](/br/revista/cert-ready-by-design/) constrói segurança verificável em vez de auditorias posteriores.

<div class="not-prose my-12 border border-gosign-border bg-gosign-light rounded-card p-6 lg:p-8">
<div class="flex items-start gap-4">
<div class="flex-shrink-0 w-12 h-12 bg-gosign-dark rounded-card flex items-center justify-center">
<svg width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="white" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 15v4a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2v-4"/><polyline points="7 10 12 15 17 10"/><line x1="12" y1="15" x2="12" y2="3"/></svg>
</div>
<div>
<h2 class="text-h3 font-bold text-gosign-dark mb-2" id="checklists-de-auditoria-da-serie">Checklists de auditoria da série</h2>
<p class="text-body text-gosign-text mb-4">Prompts preparados para o Claude Code. Cada checklist verifica automaticamente os pontos de segurança do respectivo runbook e reporta APROVADO, AVISO ou CRÍTICO.</p>
<div class="flex flex-wrap gap-3">
<a href="/downloads/claude-check-artikel-1-supabase-br.md" download class="inline-flex items-center px-4 py-2 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-sm">Supabase Infrastructure</a>
<a href="/downloads/claude-check-artikel-2-nextjs-br.md" download class="inline-flex items-center px-4 py-2 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-sm">Next.js Security</a>
<a href="/downloads/claude-check-artikel-3-edge-functions-br.md" download class="inline-flex items-center px-4 py-2 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-sm">Edge Functions</a>
<a href="/downloads/claude-check-artikel-4-trigger-dev-br.md" download class="inline-flex items-center px-4 py-2 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-sm">Trigger.dev</a>
</div>
</div>
</div>
</div>

## Sumário da série

1. [Supabase Self-Hosting Runbook](/br/revista/supabase-self-hosting/)
2. [Next.js sobre Supabase com segurança](/br/revista/nextjs-supabase-configuracao-segura/)
3. [Supabase Edge Functions com segurança](/br/revista/supabase-edge-functions-seguranca/)
4. [Trigger.dev Background Jobs com segurança](/br/revista/trigger-dev-background-jobs/)
5. [Claude Code como controle de segurança no workflow DevOps](/br/revista/claude-code-security-devops/) - este artigo
6. [Security Baseline para todo o stack](/br/revista/security-baseline-stack/)

O próximo e último artigo descreve a **Security Baseline para o stack completo**, que reúne todas as regras dos Artigos 1-5 em um único arquivo verificável.

--- Comitê & AI Literacy: As questões organizacionais ---
> Por que projetos de IA fracassam na organização, não na tecnologia. Participação como requisito de design e obrigação de treinamento desde 2025.

## Técnica raramente é o problema

Quando projetos de IA fracassam em empresas, na maioria dos casos não é por causa da tecnologia. Os modelos funcionam. As APIs são estáveis. A infraestrutura está disponível. O que fracassa é a organização: o comitê interno bloqueia a implementação porque foi informado tarde demais. Funcionários não usam as novas ferramentas porque não foram treinados.

Este artigo trata as duas questões organizacionais que acompanham cada implementação de IA: Como conquistar o comitê como apoiador? E como cumprir a obrigação legal de AI Literacy?

O EU AI Act (Artigo 4) estabelece a obrigação de AI Literacy para todos os usuários de sistemas de IA desde fevereiro de 2025. Sanções por descumprimento: até 35 milhões EUR ou 7% do faturamento anual.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Resumo - Comitê & AI Literacy</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Projetos de IA fracassam na organização, não na tecnologia. O comitê e AI Literacy são os dois fatores decisivos.</li>
<li>Envolva o comitê na fase de arquitetura, não na apresentação de resultados. Um Decision Layer torna a IA transparente e auditável por design.</li>
<li>AI Literacy é obrigatória desde fevereiro de 2025 (EU AI Act, Artigo 4). Sanções por descumprimento: até 35 milhões EUR ou 7% do faturamento.</li>
<li>Um regulamento interno se torna executável quando suas regras são implementadas como restrições técnicas no Decision Layer.</li>
<li>Programas de treinamento por função transformam obrigações de compliance em vantagens competitivas: funcionários informados usam IA de forma mais eficaz.</li>
</ul>
</div>

## Comitê e participação - de bloqueador a habilitador

### Por que o comitê deve participar

Em empresas brasileiras com representação de trabalhadores - seja via sindicatos, CRE (Comissão de Representantes dos Empregados), comitê interno ou acordo coletivo (CCT/ACT) - existe o direito de participação quando sistemas tecnológicos afetam condições de trabalho. Sistemas de IA quase sempre se enquadram: processam dados de uso, registram interações, e suas decisões afetam direta ou indiretamente as condições de trabalho.

Isso não é obstáculo, mas um marco de design. O comitê não tem direito de impedir a IA - tem direito de coconfigurar as condições de sua implementação.

O problema não surge pela participação em si, mas pelo momento em que o comitê é envolvido. Na maioria dos projetos de IA fracassados, o comitê é informado quando a decisão técnica já foi tomada. Recebe uma apresentação com resultados prontos, não tem possibilidade de influenciar a arquitetura e reage com o único meio que lhe resta: a recusa.

### Arquitetura como resposta

As perguntas do comitê são legítimas e previsíveis: Que dados o sistema de IA processa? Quem tem acesso? Dados de desempenho são capturados? Quem toma a decisão final - a IA ou um humano? As decisões podem ser rastreadas?

O [Decision Layer](/br/decision-layer/) responde essas perguntas tecnicamente, não apenas em um regulamento no papel. A camada arquitetônica define:

**Limites de decisão:** O que a IA pode preparar, o que decide um conjunto de regras, o que um humano deve aprovar.

**Human-in-the-Loop:** Aprovação humana forçada tecnicamente em classes de decisão definidas. Nenhum humano pode ser contornado porque a arquitetura não permite.

**Audit Trail:** Cada decisão de IA é registrada - qual modelo, qual entrada, qual saída, qual regra aplicada, se um humano participou.

**Controle de acesso (RBAC):** Permissões baseadas em papéis impedem acesso não autorizado a dados ou funções sensíveis.

### Regulamentos internos como System-Constraints

A vantagem decisiva de uma arquitetura de IA bem projetada: regulamentos internos e acordos coletivos não ficam apenas no papel, mas são implementados como regras técnicas no sistema.

**Primeiro: Regulamentos como conjuntos de regras configuráveis.** O que diz o regulamento interno - por exemplo "dados de desempenho não podem ser avaliados sem consentimento do funcionário" - é implementado como Constraint no Decision Layer. O sistema não pode contornar o regulamento porque a regra é imposta tecnicamente.

**Segundo: Transparência por Audit Trail completo.** O comitê pode verificar a qualquer momento que decisões o sistema de IA tomou, sobre que base e se aprovações humanas foram concedidas. Sem caixa preta, sem questão de confiança.

**Terceiro: RBAC impede acesso não controlado.** Apenas papéis definidos têm acesso a funções de IA específicas. Um líder de equipe pode usar o chatbot, mas não a análise de desempenho. Um gerente de RH pode ver a análise, mas não exportar dados brutos.

**Quarto: Sem perfilamento sem autorização explícita.** A arquitetura garante tecnicamente que avaliações pessoais só podem ser realizadas com autorização explícita - configurada no conjunto de regras. Isso é especialmente relevante para compliance com a LGPD.

### Recomendação prática: Workshop de arquitetura

Convide o comitê para o workshop de arquitetura - não para a reunião de resultados. Meio dia em que o comitê entende como funciona o Decision Layer, quais dados são processados e como regulamentos internos são tecnicamente implementados, economiza meses de negociações.

A experiência mostra: quando o comitê entende a arquitetura e vê que suas demandas não são apenas ouvidas, mas tecnicamente implementadas, ele passa de potencial bloqueador a apoiador ativo.

## AI Literacy - obrigação legal desde fevereiro 2025

### Base legal

O Artigo 4 do [EU AI Act](/br/revista/eu-ai-act-2026-empresas/) obriga todos os fornecedores e operadores de sistemas de IA a garantir que seus funcionários tenham nível suficiente de competência em IA. A obrigação vigora desde 2 de fevereiro de 2025 e afeta toda empresa que usa IA - independentemente do tamanho e da classe de risco do sistema.

Para empresas brasileiras que operam na UE ou processam dados de cidadãos europeus, essa obrigação é diretamente aplicável. Mesmo para operações exclusivamente brasileiras, a LGPD impõe requisitos de transparência e competência comparáveis.

**Sanções EU AI Act:** Até 35 milhões de euros ou 7% do faturamento mundial anual.
**Sanções LGPD:** Até 2% do faturamento no Brasil, limitado a R$ 50 milhões por infração.

### Quem deve ser treinado?

Todas as pessoas que usam, operam ou decidem sobre sistemas de IA:

- Diretoria e gerência executiva (responsabilidade decisória)
- Gerentes e coordenadores (responsabilidade de uso)
- Especialistas e analistas (uso operacional)
- TI e desenvolvimento (operação técnica)
- Representação dos trabalhadores - sindicatos e, em empresas com mais de 200 empregados, a CRE (responsabilidade de participação)

### O que deve ser treinado?

Os conteúdos devem ser adequados ao contexto. Como mínimo, quatro campos de competência:

1. **Compreensão básica do funcionamento da IA:** Como funciona um modelo de linguagem? Qual a diferença entre análise e decisão? O que a IA pode, o que não pode?
2. **Reconhecimento de alucinações:** Modelos de linguagem geram afirmações que soam plausíveis mas são factualmente incorretas. Usuários devem ser capazes de verificar resultados criticamente.
3. **Uso responsável:** Que dados podem ser inseridos? Quais não? O que acontece com os dados inseridos? Onde estão os limites do uso?
4. **Proteção de dados (LGPD + RGPD):** Que dados pessoais podem ser processados? Que consentimentos são necessários? Que dados saem da rede empresarial?

### Como demonstrar compliance?

O EU AI Act exige prova de que treinamentos foram realizados (obrigação diretamente aplicável em Portugal; no Brasil, relevante para empresas com operações na UE):

- Documentação de conteúdos e materiais de treinamento
- Listas de participantes com data e assinatura
- Atualização regular (recomendado: anual, ad hoc em mudanças significativas)
- Diferenciação por papéis e responsabilidades

Um webinar genérico de 30 minutos não cumpre os requisitos. O treinamento deve ser específico por papel, abordar os sistemas de IA específicos da empresa e conter elementos interativos que tornem a compreensão verificável.

## Recomendação prática: Portal Enterprise-AI como desenvolvimento de competências

O [Portal Enterprise-AI](/br/revista/enterprise-ai-chat-interface/) não é apenas uma ferramenta de produtividade - é também o instrumento mais eficaz para desenvolvimento de competências. Funcionários que trabalham diariamente com um sistema de IA controlado desenvolvem na prática as competências exigidas pela obrigação de AI Literacy.

Isso não substitui treinamento formal. Mas complementa com o fator mais importante: aplicação diária.

## Conclusão: A organização decide

As duas questões organizacionais - participação e competência - não são aspectos secundários da implementação de IA. São os aspectos principais. A tecnologia está disponível, acessível e poderosa. A pergunta é se sua organização é capaz de utilizá-la.

Um comitê que entende a arquitetura se torna apoiador. Funcionários treinados usam as ferramentas produtivamente. E uma organização que responde proativamente a ambas as questões ganha uma vantagem competitiva que nenhuma atualização de modelo pode substituir.

Mais: [Decision Layer](/br/decision-layer/) | [Governance](/br/governance/) | [HR & AI Agents](/br/hr-ai-agents/)

---

**Enterprise AI-Infrastructure Blueprint 2026, Serie de artigos**

| ← Anterior | Visão geral | Próximo → |
|:---|:---:|---:|
| [EU AI Act 2026: O que vale, o que vem, o que fazer](/br/revista/eu-ai-act-2026-empresas/) | [Visão geral](/br/revista/infraestrutura-ia-blueprint-2026/) | [Orquestração de agents: n8n, Camunda e alternativas](/br/revista/orquestracao-agentes-plataformas/) |

---

<a href="/br/contato/" target="_blank" rel="noopener noreferrer">Agendar reunião</a> - 30 minutos para esclarecer suas questões organizacionais.

--- Representação dos Trabalhadores e IA by Design ---
> Acordos de empresa como constraints técnicos no Decision Layer. Não convencer o comitê, mas implementar seus requisitos como regras.

Sindicatos e representantes dos trabalhadores têm direito de participação quando sistemas de IA tomam decisões sobre empregados. A abordagem correta: implementar seus requisitos como constraints técnicos no Decision Layer, não como compromissos negociados em papel.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Resumo - Participação dos trabalhadores como Constraint arquitetônico</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Sindicatos e CRE (PT: Comissão de Trabalhadores) têm direito de participação sobre IA conforme a CLT (PT: Código do Trabalho). Agentes de IA em decisões de pessoal estão sujeitos a esses direitos.</li>
<li>A abordagem padrão de "convencer" trata a representação dos trabalhadores como obstáculo em vez de fonte de requisitos - produzindo compromissos em papel inaplicáveis.</li>
<li>A abordagem arquitetônica: acordos de empresa se tornam regras técnicas no Decision Layer. Se o acordo diz "sem avaliações de desempenho totalmente automatizadas", o sistema impõe Human-in-the-Loop.</li>
<li>O Portal do Auditor dá à representação dos trabalhadores transparência verificável - cada regra tem um Control_ID, implementação técnica e histórico de evidências consultável.</li>
<li>Processo em quatro passos: analisar acordos existentes, elaborar catálogo de requisitos, implementar como controles no Decision Layer, conceder acesso ao Portal do Auditor.</li>
</ul>
</div>

Segundo o DIEESE (Departamento Intersindical de Estatística e Estudos Socioeconômicos, 2024), apenas 18% das convenções coletivas no Brasil incluem cláusulas sobre a introdução de novas tecnologias no ambiente de trabalho - apesar do crescente uso de IA em processos de RH e da previsão do PL 2338/2023 para supervisão de sistemas automatizados.

<table>
<thead>
<tr><th>Requisito do acordo de empresa</th><th>Implementação no Decision Layer</th><th>Verificação</th></tr>
</thead>
<tbody>
<tr><td>Sem avaliações de desempenho automatizadas</td><td>Regra Human-in-the-Loop (imposta)</td><td>Logs de escalação no Portal do Auditor</td></tr>
<tr><td>Relatório trimestral sobre decisões com IA</td><td>Geração automática de relatórios</td><td>Dashboard do portal com dados ao vivo</td></tr>
<tr><td>Parar IA ante suspeita de discriminação</td><td>Gatilho de monitoramento de viés</td><td>Log de alertas e histórico de incidentes</td></tr>
<tr><td>Todos os controles ativos e funcionais</td><td>Control_ID por requisito</td><td>Histórico de evidências por controle</td></tr>
</tbody>
</table>

## A abordagem habitual: convencer o comitê de empresa

Na maioria das empresas, a implantação de IA é tratada como um projeto de gestão de mudanças. O comitê de empresa é informado, convencido, envolvido. O objetivo: obter aprovação para o acordo de empresa.

Essa abordagem tem um problema: trata o comitê de empresa como um obstáculo, não como fonte de requisitos. O acordo de empresa é formulado como compromisso, redigido em linguagem jurídica e arquivado em uma pasta. A implementação técnica frequentemente fica indefinida.

## A melhor abordagem: participação dos trabalhadores como Constraint arquitetônico

Na arquitetura Gosign, acordos de empresa são implementados como constraints técnicos no [Decision Layer](/br/decision-layer/). Os requisitos do comitê de empresa não são negociados como compromissos, mas implementados como regras no sistema.

Se o acordo de empresa estabelece: "Decisões sobre avaliações de desempenho não podem ser tomadas de forma completamente automatizada", isso é implementado como regra Human-in-the-Loop no Decision Layer. O agente não consegue fisicamente contornar essa regra.

Se o acordo de empresa estabelece: "O comitê de empresa recebe um relatório trimestral sobre todas as decisões de pessoal apoiadas por IA", o Portal do Auditor gera esse relatório automaticamente.

Se o acordo de empresa estabelece: "Em caso de suspeita de padrões discriminatórios, o uso de IA para o processo afetado deve ser interrompido imediatamente", isso se torna um gatilho de monitoramento de viés no Decision Layer.

## O que o comitê de empresa pode ver

O comitê de empresa recebe acesso ao Portal do Auditor, com um acesso dedicado somente leitura, restrito aos controles relevantes para eles.

Pode rastrear: quais regras do acordo de empresa estão implementadas como controles, se todos os controles estão ativos e funcionais, com que frequência as escalações Human-in-the-Loop são acionadas e se há anomalias no monitoramento de viés.

Essa transparência constrói confiança, não por meio de promessas, mas por meio de tecnologia verificável.

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">eBook gratuito: IA em RH</p>
<p class="text-body text-gosign-text mb-4">Checklist EU AI Act, framework de decisões, perspectiva da representação dos trabalhadores e avaliação de prontidão - o manual de governança para líderes de RH.</p>
<a href="/br/ebook/ia-rh-manual-governanca/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Baixar gratuitamente</a>
</div>

## Implementação prática

**Passo 1:** Analisar os acordos de empresa existentes. Quais regulamentações afetam o uso de IA direta ou indiretamente?

**Passo 2:** Formular um novo acordo de empresa para o uso de IA. Não como documento em prosa, mas como catálogo de requisitos com regras concretas e tecnicamente implementáveis.

**Passo 3:** Implementar os requisitos como controles no Decision Layer. Cada requisito recebe um Control_ID, uma implementação técnica e um gerador de evidências.

**Passo 4:** O comitê de empresa recebe acesso ao Portal do Auditor. Pode verificar a qualquer momento se seus requisitos estão tecnicamente implementados.

Mais sobre este tema: [Participação dos trabalhadores e IA](/br/governance/co-determination/)

<a href="/br/contato/" target="_blank" rel="noopener noreferrer">Agendar reunião</a>. Mostramos como a participação dos trabalhadores é implementada tecnicamente.

--- Contrato de operador IA: O que falta no seu contrato ---
> Por que contratos padrão não cobrem infraestrutura de IA empresarial. Com checklist de requisitos para RH e compliance.

Um contrato de operador de dados para infraestrutura de IA deve cobrir dez áreas que contratos SaaS padrão não regulam: políticas de registro de prompts, separação de ambientes (dev/staging/prod), cadeias de provedores de modelos, processamento in-flight vs. at-rest, proteção de dados de embeddings RAG, acesso de terceiros países a dados de produção, conformidade com sigilo profissional, tokenização PII, trilhas de auditoria do Decision Layer e verificabilidade de medidas técnicas.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Resumo - Contrato de operador para infraestrutura de IA</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Contratos SaaS padrão não cobrem registro de prompts, cadeias de provedores de modelos, separação de ambientes nem tokenização PII exigidos pela infraestrutura de IA.</li>
<li>Dez lacunas específicas existem entre contratos padrão e a realidade da IA - de novas categorias de dados a trilhas de auditoria do Decision Layer.</li>
<li>BSI (2024) observa que 68% das organizações que usam IA generativa não atualizaram seus contratos de processamento de dados para refletir fluxos de dados específicos de IA.</li>
<li>Um checklist de 25 perguntas ajuda responsáveis de RH e compliance a verificar a prontidão do provedor de IA em sete categorias.</li>
<li>Isto não é assessoria jurídica - é uma bússola arquitetônica que revela lacunas de infraestrutura por trás das lacunas contratuais.</li>
</ul>
</div>

## Por que os contratos padrão de operador de dados não cobrem a infraestrutura de IA

Um contrato padrão de operador de dados regula como um prestador de serviços trata dados pessoais em nome do controlador. Define a finalidade, as categorias de dados, as medidas técnicas e organizacionais, os sub-operadores e os prazos de retenção. Para um sistema CRM ou um software de RH, isso é suficiente.

A infraestrutura de IA empresarial cria situações que nenhum contrato padrão prevê. Um modelo de linguagem processa prompts  - entradas de texto livre que podem conter qualquer coisa: dados de pessoal, informações de clientes, segredos comerciais, até categorias especiais de dados sensíveis quando um colaborador faz uma pergunta relacionada à saúde. Os dados fluem através de uma cadeia de sistemas: do frontend, passando por uma camada de orquestração, até o provedor do modelo, de volta a um banco de dados, possivelmente através de um pipeline RAG com vetores de embedding. Em cada ponto surgem questões diferentes sobre armazenamento, acesso e exclusão.

Quando você solicita ao seu provedor de IA o contrato de operador de dados e recebe um documento padrão, isso deve acender um alerta. Não porque o provedor não seja confiável, mas porque os riscos específicos da infraestrutura IA exigem disposições diferentes de uma aplicação SaaS convencional.

## Dez lacunas entre o contrato padrão e a realidade da IA

### 1. Conteúdo de prompts como nova categoria de dados

Contratos padrão listam categorias de dados: nome, email, número do colaborador. Com agentes de IA surge uma categoria que não pode ser predefinida  - o prompt. Um prompt pode ser uma pergunta inofensiva sobre política de férias ou uma carta completa de cliente com dados pessoais. O contrato deve estabelecer que a responsabilidade pela classificação do conteúdo recai sobre a organização, não sobre o provedor de IA, enquanto o provedor deve demonstrar medidas técnicas que protejam todo o conteúdo inserido independentemente da sua sensibilidade.

### 2. Política de registro: O que pode aparecer nos logs?

Com software convencional, registra-se o tecnicamente necessário. Com infraestrutura de IA, o registro adquire outra dimensão: Os conteúdos dos prompts são registrados? As respostas do modelo são armazenadas? Os documentos carregados aparecem em logs de erros?

Um contrato robusto para infraestrutura de IA deve estabelecer explicitamente que no ambiente de produção o registro de corpos de requisição/resposta está desativado, que apenas metadados técnicos são registrados (códigos de status, latências, IDs de requisição), que o registro de depuração em produção está desativado e que rastreamentos de pilha não contêm conteúdo de prompts nem documentos.

### 3. Separação de ambientes: Dev, Staging, Produção

Todo ambiente enterprise possui ambientes de desenvolvimento, testes e produção. Com infraestrutura de IA, a separação é crítica para a segurança porque dados reais podem ser utilizados como dados de teste durante o desenvolvimento. Um contrato específico para IA deve estabelecer que dev e staging utilizam exclusivamente dados sintéticos ou anonimizados, que o acesso à produção está restrito a funções definidas e que os casos de suporte são tratados apenas com dados de teste aprovados pela organização.

### 4. Cadeia de provedores de modelos em vez de sub-operadores clássicos

Com software convencional, um provedor tem sub-operadores: um provedor de hosting, talvez um serviço de email. Com infraestrutura de IA surge uma cadeia de três níveis: o provedor de infraestrutura de IA opera a plataforma, os provedores de modelos (Azure OpenAI, Google Vertex AI, Anthropic) processam os prompts e os provedores de plataforma (Supabase, Vercel) hospedam banco de dados e frontend.

O ponto crítico: Quem é o parceiro contratual dos provedores de modelos? Os modelos operam no tenant do provedor de IA ou no tenant da organização? Essa distinção determina se o provedor do modelo é sub-operador do provedor ou se a organização gerencia diretamente os relacionamentos com fornecedores.

| Componente | No tenant do cliente | No tenant do provedor |
|---|---|---|
| Azure Entra ID (SSO) | ✓ Cliente | - |
| Azure OpenAI / Vertex AI | ✓ Cliente | - |
| Supabase (Banco de dados) | ✓ Cliente | - |
| Vercel (Hosting) | ✓ Cliente | - |
| Plane (Sistema de tickets) | - | ✓ Provedor |
| GitHub (Hosting de código) | - | ✓ Provedor |
| Google Workspace (Comunicação) | - | ✓ Provedor |

*Componentes no tenant do cliente são gerenciados pelo cliente em seu próprio registro de fornecedores. Componentes no tenant do provedor estão sujeitos à lista de sub-operadores no contrato.*

### 5. In-flight vs. at-rest: Onde os dados permanecem?

Com software convencional, a pergunta é simples: os dados residem em um banco de dados. Com infraestrutura de IA existem dois modos de processamento. Processamento in-flight: o prompt é enviado ao provedor do modelo, processado e a resposta retornada  - sem armazenamento persistente no provedor. Armazenamento at-rest: chats, uploads e embeddings são armazenados em um banco de dados  - de forma persistente e associada ao usuário.

O contrato deve estabelecer disposições separadas para ambos os modos.

### 6. RAG e embeddings: Dados vetoriais como novo desafio

RAG (Retrieval Augmented Generation) torna documentos empresariais pesquisáveis por IA. Os documentos são convertidos em vetores de embedding e armazenados em um banco de dados vetorial. Esses vetores são uma nova categoria de dados: não contêm texto legível, mas em determinadas circunstâncias podem permitir inferências sobre o conteúdo original. O contrato deve tratar embeddings como dados pessoais quando gerados a partir de documentos com dados pessoais.

### 7. Acesso de terceiros países a dados de produção

Muitos provedores de IA trabalham com equipes distribuídas. Quando um desenvolvedor de um terceiro país tem acesso ao ambiente de produção, isso constitui uma transferência internacional de dados. O contrato deve definir que o acesso à produção está restrito a jurisdições adequadas, que o acesso a dev/staging de terceiros países é admissível (porque contêm apenas dados sintéticos), que RBAC prevê grupos de administradores separados para produção e dev/staging e que existe um procedimento de exceção que requer autorização escrita do controlador.

Para organizações brasileiras, a conformidade com a LGPD (PT: RGPD) exige atenção especial à transferência internacional de dados (Arts. 33-36) e ao papel do Encarregado de Proteção de Dados (DPO) na supervisão do tratamento por agentes de IA.

### 8. Sigilo profissional na plataforma de IA

Para setores regulados  - escritórios de advocacia, consultorias tributárias, auditorias, organizações de saúde e empresas com processos sujeitos a sigilo profissional  - o processamento em plataformas de IA requer disposições contratuais explícitas. A legislação brasileira prevê a proteção do sigilo profissional conforme legislação setorial brasileira. O provedor deve comprometer todas as pessoas com acesso mediante declarações escritas de confidencialidade. Cláusulas padrão de confidencialidade não são suficientes.

### 9. Tokenização PII como módulo opcional

Filtros de entrada e saída que detectam dados pessoais e os pseudonimizam antes de enviar ao provedor do modelo adicionam uma camada adicional de proteção. A tokenização PII não é necessária em todo ambiente, mas o contrato deve contemplá-la como módulo opcional. Importante: se a re-identificação reversível for possível, o contrato deve regular quem tem acesso à tabela de mapeamento, como as chaves de mapeamento são armazenadas e criptografadas e que a re-identificação ocorre apenas com finalidade definida após autorização documentada.

### 10. Trilha de auditoria e Decision Layer

Agentes de IA tomam ou preparam decisões. Cada uma dessas decisões deve ser rastreável  - não apenas para proteção de dados, mas também para auditoria interna, auditores externos e compliance. O [Decision Layer](/br/decision-layer/) decompõe cada processo em etapas de decisão individuais e define para cada etapa: humano, motor de regras ou IA. O contrato deve ancorar a trilha de auditoria como componente contratual: Quais dados são registrados por decisão? Por quanto tempo são retidos? Quem tem acesso?

## O checklist: 25 perguntas para seu provedor de IA

O checklist a seguir traduz as dez lacunas em perguntas de verificação concretas.

**[Checklist de requisitos: 25 perguntas de verificação para contratos IA →](/br/governance/checklist-contrato-ia/)**

### A  - Categorias de dados e finalidades de tratamento

1. Os conteúdos de prompts e respostas do modelo estão listados como categorias de dados independentes no contrato?
2. Está estabelecido que a responsabilidade pela classificação do conteúdo recai sobre a organização, não sobre o provedor?
3. Os embeddings/vetores estão classificados como dados potencialmente pessoais?
4. O contrato contempla categorias especiais de dados sensíveis que podem surgir por entradas de usuários?

### B  - Registro e monitoramento

5. O registro de corpos de requisição/resposta no ambiente de produção está desativado?
6. Quais metadados são registrados (códigos de status, latências, IDs de requisição)?
7. O registro de depuração em produção está verificavelmente desativado?
8. Os rastreamentos de pilha e mensagens de erro estão configurados para excluir dados de conteúdo dos logs?
9. A verificação das configurações de registro é parte do processo de lançamento?

### C  - Separação de ambientes e acesso

10. Existem ambientes separados (dev, staging, produção) com políticas de dados distintas?
11. Os ambientes dev/staging contêm exclusivamente dados sintéticos ou anonimizados?
12. O acesso à produção está restrito a funções autorizadas em jurisdições adequadas?
13. Existe um procedimento de exceção documentado para casos de suporte com acesso a dados?

### D  - Provedores de modelos e sub-operadores

14. A delimitação está clara: Quais provedores são sub-operadores do provedor e quais operam no tenant da organização?
15. A retenção de conteúdo nos provedores de modelos está desativada?
16. A exclusão do uso para treinamento está documentada contratualmente?
17. Onde estão localizados os endpoints dos modelos (região UE, US, outros)?

### E  - Armazenamento e exclusão de dados

18. Está estabelecido onde os dados de conteúdo persistentes são armazenados (banco de dados, região, provedor)?
19. Qual retenção de backup se aplica e como os dados excluídos são tratados nos backups?
20. O usuário individual pode excluir seus próprios dados dentro da aplicação?

### F  - Setores regulados

21. O contrato contém disposições de conformidade com sigilo profissional (legislação setorial brasileira ou equivalente)?
22. Existem compromissos de confidencialidade para todas as pessoas com acesso?
23. A tokenização PII está disponível como módulo opcional?

### G  - Governança e verificabilidade

24. Uma trilha de auditoria para decisões de agentes está ancorada como componente contratual?
25. As medidas técnicas e organizacionais podem ser evidenciadas sob solicitação (documentação de configuração, extratos de logs anonimizados)?

## Do checklist à arquitetura

Essas 25 perguntas não são uma ferramenta jurídica. São uma bússola arquitetônica. Cada pergunta que seu provedor de IA não consegue responder revela uma lacuna em sua infraestrutura  - não apenas em seu contrato.

Na Gosign, incorporamos esses requisitos na arquitetura: [separação de ambientes com bloqueio de produção](/br/revista/hosting-ia-estrategias-enterprise/), registro sem dados de conteúdo, provedores de modelos no tenant do cliente, [Decision Layer](/br/decision-layer/) com trilha de auditoria completa. Não porque um cliente exigiu, mas porque IA empresarial sem essas bases não é auditável.

Se você deseja avaliar como sua infraestrutura de IA atual se compara com esses 25 pontos  - ou se está avaliando uma nova plataforma  - teremos prazer em conversar.

**[Agendar uma conversa →](/br/contato/)**

--- Quanto a IA realmente custa: comparativo TCO para empresas ---
> Preços de tokens são enganosos. As quatro categorias de custo da IA enterprise - com três cenários de R$ 130 mil a R$ 2 milhões.

## Preços de tokens não são seus custos de IA

Quando empresas falam sobre custos de IA, a discussão quase sempre começa pelos preços de tokens. Isso é compreensível: provedores divulgam seus modelos com preços de input e output por milhão de tokens, e esses números são fáceis de comparar. Um modelo de ponta custa 5 dólares por milhão de tokens de input, um modelo econômico custa 0,25 dólares - a diferença parece dramática.

Porém, preços de tokens representam na prática apenas 20 a 35 por cento dos custos reais. Quem reduz seu planejamento orçamentário de IA a preços de tokens subestima os custos totais por um fator de três a cinco. A verdadeira questão não é: "Quanto custa um token?" A questão é: "Quanto custa operar IA de forma produtiva, segura e em conformidade na minha empresa?"

Este artigo mostra as quatro categorias de custo que toda implantação de IA enterprise abrange, compara três cenários de R$ 130.000 a R$ 2.050.000 no primeiro ano e explica como Model Switching pode economizar 40 a 60 por cento dos custos de tokens.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Resumo - Custos reais da IA enterprise</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Preços de tokens representam apenas 20 a 35% dos custos reais. Infraestrutura, governance e pessoal compõem os 65 a 80% restantes.</li>
<li>Três cenários: entrada ~R$ 130.000 (1 chatbot, 50 usuários), padrão ~R$ 740.000 (3 agentes, híbrido), enterprise ~R$ 2.050.000 (10+ agentes, GPUs próprias).</li>
<li>Segundo a Deloitte (2024), empresas que planejam orçamentos de IA apenas com preços de tokens subestimam os custos totais por um fator de 3 a 5 em média.</li>
<li>Model Switching reduz custos de tokens em 40 a 60%, direcionando solicitações simples para modelos econômicos e tarefas complexas para modelos de ponta.</li>
<li>Custos de infraestrutura se concentram nos meses 1 a 6; a partir do segundo ano, custos de modelo e pessoal dominam o mix de TCO.</li>
</ul>
</div>

## As quatro categorias de custo

Toda implantação de IA no contexto empresarial se distribui em quatro categorias de custo. A ponderação relativa varia conforme o cenário, mas a estrutura permanece a mesma.

### 1. Custos de modelo: tokens e hosting (20-35%)

A categoria mais visível: taxas de API para modelos em nuvem ou custos de hosting para modelos self-hosted. Em Cloud APIs, você paga por token - input e output separadamente. Em self-hosting, você paga aluguel de GPU, energia e manutenção. Os custos dependem diretamente do volume de uso: um chatbot com 50 usuários gera volumes de tokens diferentes de dez agentes especializados com 1.000 usuários.

O que frequentemente é ignorado: self-hosting é mais barato que Cloud APIs a partir de um determinado volume, mas os custos iniciais são mais altos. Uma única GPU com 80 GB VRAM custa em um provedor de hosting brasileiro aproximadamente R$ 6.000 por mês - independentemente de estar totalmente utilizada ou não. Para detalhes sobre a decisão de hosting, veja [Estratégias de hosting de IA](/br/revista/hosting-ia-estrategias-enterprise/).

### 2. Infraestrutura e integração (25-35%)

A maior e mais frequentemente subestimada categoria. Abrange tudo que é necessário para integrar um modelo de linguagem em sua infraestrutura de TI existente:

- **API gateway e camada de roteamento:** Um ponto central que direciona solicitações ao modelo adequado, impõe limites de taxa e rastreia custos.
- **Pipeline RAG:** Se sua IA deve acessar conhecimento interno, você precisa de uma pipeline de Retrieval-Augmented Generation: banco de dados vetorial, modelo de embedding, estratégia de chunking, indexação.
- **Integração com sistemas:** Integração em sistemas existentes - ERP, CRM, gestão documental, ticketing. No Brasil, isso inclui TOTVS, sistemas SPED e e-Social. Cada interface requer esforço de desenvolvimento.
- **Portal Enterprise AI:** Uma interface pela qual os colaboradores realmente utilizam a IA - com SSO, gestão de permissões e Audit Trail.

Esses custos são amplamente únicos. Incidem primariamente nos primeiros três a seis meses e se amortizam ao longo do tempo. Mas precisam ser planejados e orçados - caso contrário surgem custos ocultos por workarounds e retrabalho.

### 3. Governance e compliance (15-20%)

Desde o [EU AI Act](/br/revista/eu-ai-act-2026-empresas/) e com a LGPD (PT: RGPD) em vigor, governance não é mais um luxo opcional. Os custos nesta categoria abrangem:

- **Classificação de risco:** Avaliação de todos os sistemas de IA conforme categorias do EU AI Act. Para sistemas de alto risco, é necessária uma avaliação formal de conformidade.
- **Documentação técnica:** O EU AI Act exige documentação abrangente de procedência de dados, procedimentos de treinamento, métricas de desempenho e medidas de mitigação de risco.
- **Audit Trail e monitoramento:** Registro contínuo de todas as decisões de IA, especialmente em processos de decisão automatizados.
- **Proteção de dados:** Processamento de dados em conformidade com a LGPD (PT: RGPD), contratos de processamento de dados, avaliação de impacto à proteção de dados para processamento de dados pessoais.
- **Consultoria externa:** Assessoria jurídica para questões regulatórias, encarregado de proteção de dados, eventualmente organismo de avaliação de conformidade.

A proporção de governance cresce com a complexidade do uso de IA. Um chatbot para perguntas gerais de conhecimento tem requisitos de governance menores que um sistema de IA que pré-seleciona candidaturas.

### 4. Pessoal e capacitação (20-30%)

Sistemas de IA precisam ser operados, mantidos e evoluídos. Ao mesmo tempo, colaboradores precisam ser capazes de utilizar os sistemas. Esta categoria abrange:

- **ML-Ops / AI Engineering:** Pelo menos uma pessoa responsável por gestão de modelos, otimização de prompts, monitoramento e troubleshooting. No cenário enterprise, uma equipe dedicada.
- **AI Literacy:** Treinamentos para todos os usuários - desde fevereiro de 2025 legalmente obrigatório no âmbito do EU AI Act. Abrange treinamentos iniciais e reciclagens periódicas.
- **Gestão de mudanças:** Acompanhamento da organização na transição. Novos processos, novos papéis, novas responsabilidades.

Em cenários menores, a capacitação pode ocorrer internamente - sem custos adicionais de pessoal, mas com custos de oportunidade. Em cenários maiores, é necessário pessoal dedicado ou suporte externo.

### Distribuição de custos em visão geral

```
Custos de modelo (tokens/hosting)       ████████░░░░░░░░░░░░  20-35%
Infraestrutura e integração             ██████████░░░░░░░░░░  25-35%
Governance e compliance                 ██████░░░░░░░░░░░░░░  15-20%
Pessoal e capacitação                   ████████░░░░░░░░░░░░  20-30%
```

A distribuição se altera ao longo do tempo: no primeiro ano, infraestrutura e integração dominam. A partir do segundo ano, as proporções relativas de custos de modelo e pessoal aumentam, enquanto os custos únicos de integração desaparecem.

## Três cenários em comparação

Os três cenários a seguir representam pontos de entrada típicos. Os valores são referências baseados em experiência de projetos com empresas de diferentes portes no mercado brasileiro. Seus custos reais dependem da [infraestrutura de TI](/br/revista/infraestrutura-ia-blueprint-2026/) existente, dos requisitos de integração e do modelo operacional escolhido.

| Cenário | Setup de modelo | Token/Hosting mensal | Integração | Governance | Pessoal | Total 12 meses |
|---|---|---|---|---|---|---|
| **Entrada:** 1 chatbot, 50 usuários | Sonnet API | ~R$ 2.500 | R$ 75.000 | R$ 25.000 | 0 (interno) | **~R$ 130.000** |
| **Padrão:** 3 agentes, 200 usuários | Sonnet + Llama self-hosted | ~R$ 20.000 | R$ 300.000 | R$ 100.000 | 1 ML-Ops (parcial) | **~R$ 740.000** |
| **Enterprise:** 10+ agentes, 1.000+ usuários | Multi-modelo, GPU própria | ~R$ 60.000 | R$ 750.000 | R$ 250.000 | 2 FTE | **~R$ 2.050.000** |

### Cenário 1: Entrada (aprox. R$ 130.000 / 12 meses)

Um caso de uso claramente definido: um chatbot de conhecimento interno para um departamento, baseado em Cloud API. 50 usuários, volume moderado de solicitações, sem integração de sistema além de upload de documentos. Governance se limita a processamento de dados conforme a LGPD e documentação básica. Custos de pessoal não incidem porque a equipe de TI interna assume a operação em paralelo ao dia a dia.

Esse cenário é o Proof of Concept típico. Prova o valor, valida a tecnologia e fornece dados de experiência para a escalação. Um PoC bem definido com um caso de uso claro fica tipicamente entre R$ 75.000 e R$ 150.000 e é realizável em quatro a seis semanas.

### Cenário 2: Padrão (aprox. R$ 740.000 / 12 meses)

Três agentes especializados para diferentes processos - por exemplo análise de documentos, comunicação com clientes e gestão de conhecimento interno. 200 usuários, hosting híbrido: solicitações não-críticas via Cloud API, dados sensíveis via modelo self-hosted. Integração com pelo menos um sistema existente. Governance abrange classificação de risco conforme EU AI Act e documentação formal. Um ML-Ops Engineer cuida parcialmente da gestão de modelos e monitoramento.

Esse cenário é a entrada produtiva. A organização concluiu o PoC e escala para múltiplos departamentos. A infraestrutura é dimensionada para crescimento.

### Cenário 3: Enterprise (aprox. R$ 2.050.000 / 12 meses)

Dez ou mais agentes especializados em múltiplas áreas de negócio. Mais de 1.000 usuários. Arquitetura multi-modelo com GPUs próprias. Integração profunda com ERP, CRM, sistemas de RH e gestão documental. Governance em nível enterprise: avaliação formal de conformidade para sistemas de alto risco, Audit Trail, governance dashboard. Dois ML-Ops Engineers em tempo integral para operação e evolução.

Esse cenário pressupõe que a organização concluiu a fase de experimentação e opera IA como infraestrutura estratégica. Os R$ 2.050.000 parecem um investimento significativo - e são. Mas distribuem-se por um sistema que acelera centenas de processos, reduz taxas de erro e melhora bases de decisão.

### Contexto: quanto custam as alternativas?

Os custos de um sistema de IA nunca devem ser avaliados isoladamente. A comparação relevante é: quanto custam os processos sem IA? Se três analistas gastam cada um duas horas por dia com classificação de documentos, isso representa aproximadamente R$ 450.000 por ano em custo total - para uma tarefa que um agente treinado resolve em segundos. O ROI raramente é a questão. A questão é quão rápido ele se manifesta.

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">eBook gratuito: IA em Finanças</p>
<p class="text-body text-gosign-text mb-4">Conformidade, auditores externos e Decision Layer - o manual de governança para liderança financeira.</p>
<a href="/br/ebook/ia-financas-manual-governanca/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Baixar grátis</a>
</div>

## Otimização de custos com Model Switching

A alavanca mais eficaz nos custos de modelo não é a escolha de um modelo mais barato, mas o uso diferenciado de múltiplos modelos. Esse princípio chama-se Model Switching ou Model Routing.

### O princípio

Nem toda solicitação precisa de um modelo de ponta. A maioria das solicitações enterprise - respostas padrão, classificação simples, extração de dados de documentos estruturados - pode ser atendida por modelos econômicos com qualidade suficiente. Apenas para tarefas complexas - raciocínio em múltiplas etapas, análise contratual, preparação de decisões - é necessário um modelo de ponta.

Uma lógica de roteamento decide automaticamente qual modelo processa uma solicitação. Os critérios são configuráveis:

- **Complexidade:** Solicitações simples para modelos econômicos, complexas para modelos de ponta.
- **Sensibilidade de dados:** Solicitações com dados pessoais para modelos self-hosted, solicitações não-críticas para Cloud APIs.
- **Requisito de latência:** Aplicações em tempo real para modelos rápidos e pequenos. Processamento em lote para modelos potentes sem pressão de tempo.
- **Limite de custo:** Limitação automática quando um orçamento de equipe ou departamento é atingido.

### Potencial de economia

Na prática, as solicitações enterprise se distribuem tipicamente assim:

- **60-70% solicitações padrão:** Classificação simples, FAQ, extração de dados. Modelos econômicos são suficientes.
- **20-30% complexidade média:** Resumos, análise estruturada, rascunhos. Modelos com bom custo-benefício.
- **5-15% alta complexidade:** Raciocínio em múltiplas etapas, análise contratual, documentos estratégicos. Modelos de ponta.

Quando 65 por cento das solicitações utilizam um modelo econômico que custa um vigésimo do preço em vez de um modelo de ponta, os custos de tokens caem 40 a 60 por cento - mantendo a qualidade para o uso global. Os detalhes sobre [seleção de modelos e perfis de desempenho dos modelos atuais](/br/revista/modelos-ia-comparacao-2026/) estão no artigo correspondente.

### Implementação

Model Switching requer três componentes:

1. **Routing Engine:** Uma lógica central que analisa solicitações e as direciona ao modelo adequado. Pode ser implementada por regras (detecção de palavras-chave, papel do usuário, classificação de dados) ou por modelo (um pequeno modelo de classificação avalia a complexidade).
2. **Registro de modelos:** Um diretório central de todos os modelos disponíveis com seus perfis de desempenho, custos e disponibilidade.
3. **Monitoramento de custos:** Um dashboard que torna transparente o consumo de tokens por modelo, por equipe e por caso de uso. Sem transparência, não há otimização.

O esforço de implementação para Model Switching é gerenciável - tipicamente duas a quatro semanas. As economias começam imediatamente.

## Planejamento orçamentário: três recomendações

**Primeiro: planeje com TCO, não com preços de tokens.** Se um fornecedor apresenta apenas os custos de tokens, faltam pelo menos 65 por cento do orçamento. Exija um cálculo de TCO que cubra todas as quatro categorias.

**Segundo: comece com um PoC, mas planeje a escalação.** Um PoC de R$ 75.000 a R$ 150.000 prova o valor. Mas a arquitetura do PoC deve ser construída de forma que possa escalar sem reconstrução. Caso contrário, você paga os custos de integração duas vezes.

**Terceiro: implemente Model Switching desde o início.** A camada de roteamento custa pouco uma vez e economiza muito continuamente. Quem faz roteamento diferenciado desde o início evita o lock-in em um único modelo e mantém o controle de custos.

Mais informações: [Estratégias de hosting de IA](/br/revista/hosting-ia-estrategias-enterprise/) | [Modelos de IA - Comparativo 2026](/br/revista/modelos-ia-comparacao-2026/)

Gosign constrói infraestrutura de IA com estrutura de custos transparente, da análise de TCO até a operação produtiva. Se você quer saber quanto a IA custa no seu setup concreto, fale conosco.

<a href="/br/contato/" target="_blank" rel="noopener noreferrer">Agendar reunião</a>. 30 minutos para calcular seus custos de forma realista.

--- Decision Layer: governance para agentes AI enterprise ---
> O Decision Layer é o componente de governance entre agente AI e sistema-alvo. Rules Engine, Confidence Routing, Human-in-the-Loop, Audit Trail.

## O problema: decisões de IA sem rastreabilidade

Quando um agente AI contabiliza uma nota fiscal, processa um atestado médico ou responde a uma consulta de compliance, ele toma uma decisão. Essa decisão se baseia em um modelo de linguagem que opera com probabilidades - não com regras determinísticas.

Para um chatbot interno, isso é aceitável. Para processos críticos de negócio, não. Quando um agente propõe um lançamento contábil, deve ser rastreável: Qual regra foi aplicada? Em qual versão? Com qual nível de confiança? Um humano participou?

Sem essa rastreabilidade, decisões de IA em ambientes regulados não podem ser implantadas. Auditores não conseguem verificá-las. A representação dos trabalhadores - sindicatos e CRE (PT: Comissão de Trabalhadores) (BR) ou a Comissão de Trabalhadores (PT) - não conseguem avaliá-las. A auditoria interna não consegue rastreá-las.

O Decision Layer resolve esse problema.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Resumo - Decision Layer</p>
<ul class="text-body text-gosign-text space-y-2">
<li>O Decision Layer é o componente de governance entre agente AI e sistema-alvo - cada decisão do agente passa por ele antes de se tornar efetiva.</li>
<li>Decompõe processos em microdecisões e define para cada uma: humano decide, conjunto de regras se aplica ou IA decide de forma autônoma.</li>
<li>Quatro componentes - Rules Engine, Confidence Routing, Human-in-the-Loop, Audit Trail - garantem rastreabilidade, compliance e prontidão para auditoria.</li>
<li>Em decisões baseadas em regras e repetitivas, a IA comprovadamente supera o humano em consistência, resistência à fadiga e completude.</li>
<li>Sem Decision Layer, agentes AI enterprise não passam em auditorias, não atendem requisitos dos representantes dos trabalhadores e não escalam além de pilotos.</li>
</ul>
</div>

[Gartner (2026)](https://www.gartner.com/en/newsroom/press-releases/2026-05-26-gartner-says-applying-uniform-governance-across-ai-agents-will-lead-to-enterprise-ai-agent-failure) prevê que, até 2027, 40 por cento das organizações rebaixarão ou desativarão agentes AI autônomos devido a lacunas de governança.

## O que é um Decision Layer?

O Decision Layer é o componente central de governance entre um agente AI e o sistema-alvo. Arquitetonicamente, fica entre o agente, que emite uma recomendação, e o sistema onde a decisão se torna efetiva - por exemplo SAP, [TOTVS](https://www.totvs.com/) ou [Workday](https://www.workday.com/).

O Decision Layer não é um complemento de compliance adicionado depois. É um princípio arquitetônico. Cada decisão do agente passa pelo Decision Layer antes de chegar ao sistema-alvo.

## Decision Layer - explicado para responsáveis por processos

A descrição técnica acima é precisa. Mas para o dia a dia existe uma explicação mais simples:

O Decision Layer funciona como uma descrição padrão de processo com níveis de decisão claros - só que é aplicado tecnicamente, não fica apenas no papel.

Na prática: cada processo de negócio que um agente AI deve executar é decomposto em microdecisões individuais. Para cada decisão é definido previamente - por pessoas, não pela IA:

Um humano deve decidir aqui? Por exemplo, porque a representação dos trabalhadores - sindicatos/CRE (BR) ou a Comissão de Trabalhadores (PT) - exige, porque existe risco de discriminação ou porque se trata de uma decisão discricionária.

É uma regra aplicada sempre da mesma forma? Por exemplo, uma verificação de prazo, um acordo coletivo, uma lógica contábil. Então o agente aplica a regra de forma consistente - em cada filial, com cada colaborador, a qualquer hora. Os conjuntos de regras são versionados: cada alteração cria uma nova versão, as versões anteriores permanecem rastreáveis. Aqui, o agente é um executor - não porque não seja capaz de mais, mas porque não há o que interpretar.

A IA pode decidir sozinha aqui? O agente interpreta documentos, classifica situações, avalia contexto e reconhece padrões. Isso não é if-then-else - é capacidade de julgamento dentro de limites definidos. O Confidence Routing controla: alta confiança e baixo risco significa decisão autônoma; baixa confiança ou alto risco significa escalação para uma pessoa. Esse Confidence Routing é precisamente o que distingue o Decision Layer do RPA.

Cada um desses passos é documentado: Quem decidiu, com qual base, com qual resultado. Esse é o Audit Trail - a evidência que auditores, representantes dos trabalhadores e auditoria interna precisam.

O resultado: processos ficam mais rápidos e consistentes sem perder o controle. E quando alguém pergunta "Como essa decisão foi tomada?" - há uma resposta.

<table class="w-full text-left text-sm">
<thead><tr class="border-b border-gosign-border">
<th class="py-2 pr-4 font-semibold">Tipo de decisão</th>
<th class="py-2 pr-4 font-semibold">Velocidade</th>
<th class="py-2 pr-4 font-semibold">Auditabilidade</th>
<th class="py-2 pr-4 font-semibold">Nível de risco</th>
<th class="py-2 pr-4 font-semibold">Exemplo</th>
</tr></thead>
<tbody>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Decisão humana</td><td class="py-2 pr-4">Baixa (minutos a dias)</td><td class="py-2 pr-4">Alta (revisão documentada)</td><td class="py-2 pr-4">Baixo (julgamento humano)</td><td class="py-2 pr-4">Planejamento de reintegração</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Baseada em regras</td><td class="py-2 pr-4">Alta (instantânea)</td><td class="py-2 pr-4">Alta (regras versionadas)</td><td class="py-2 pr-4">Baixo (determinística)</td><td class="py-2 pr-4">Classificação salarial</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">IA autônoma</td><td class="py-2 pr-4">Alta (instantânea)</td><td class="py-2 pr-4">Alta (Audit Trail)</td><td class="py-2 pr-4">Médio (Confidence Routing)</td><td class="py-2 pr-4">Classificação de documentos</td></tr>
</tbody>
</table>

A implementação técnica dessa lógica consiste em quatro componentes:

### Os quatro componentes

**1. Rules Engine**

Conjuntos de regras especializados, versionados e rastreáveis. Acordos coletivos, acordos de empresa, lógica contábil, legislação tributária, regras de compliance. Cada regra tem uma versão, uma data de validade e um escopo de aplicação.

Quando uma regra muda - por exemplo, um novo acordo coletivo ou uma diretriz contábil alterada - uma nova versão é criada. A versão anterior permanece no sistema. Em uma auditoria, é rastreável qual regra em qual versão estava vigente no momento da decisão.

**2. Confidence Routing**

Nem toda decisão do agente tem o mesmo nível de certeza. O Decision Layer avalia automaticamente cada decisão:

- Alta confiança + baixo risco = processamento autônomo. O agente decide, o resultado vai para o sistema-alvo.
- Baixa confiança ou alto risco = escalação para um humano. O workflow pausa, um responsável revisa e decide.
- Caso excepcional ou padrão desconhecido = bloqueio. Sem output, esclarecimento humano necessário.

Os limiares de confiança e risco são configuráveis e específicos por cliente. Uma firma de auditoria definirá limiares diferentes de um centro de serviços compartilhados.

**3. Human-in-the-Loop**

Human-in-the-Loop no Decision Layer é um princípio arquitetônico, não uma opção. Para tipos de decisão definidos, a arquitetura impõe revisão humana:

- Decisões com potencial discriminatório
- Decisões que afetam temas com impacto nos direitos dos trabalhadores
- Decisões acima de limiares de valor definidos
- Primeira aplicação de uma nova regra

O requisito de Human-in-the-Loop é aplicado tecnicamente, não organizacionalmente. Um agente não pode contornar essa revisão.

**4. Audit Trail - o ato de decisão**

Cada decisão gera um ato de decisão completo e imutável:

- Input: O que foi fornecido ao agente?
- Modelo: Qual modelo de linguagem e em qual versão foi usado (ex.: `claude-opus-4-7-2026-04-12`, `gpt-5.5-2026-03-pro`, `mistral-medium-3.1-eu`, `deepseek-v4-pro-on-prem`)?
- Conjunto de regras: Qual regra em qual versão foi aplicada?
- Confiança: Quão seguro estava o agente?
- Routing: Foi decidido autonomamente ou escalado?
- Resultado: Qual foi a decisão?
- Timestamp: Quando foi decidido?
- Caminho de contestação: Quem pode contestar esta decisão - titular, sindicato, auditor?

Esse ato de decisão é o que auditores veem no Auditor Portal. Não documentação retrospectiva, mas a evidência técnica do processo decisório. E é a resposta arquitetônica ao direito do titular de revisar a decisão individual nos termos da LGPD art. 20 (e do art. 86 do EU AI Act em negócios na UE).

## Como o Decision Layer funciona na prática

Um exemplo concreto do processamento de documentos:

Chega um documento - uma nota fiscal de fornecedor. O Document Agent lê o documento e extrai as informações relevantes: emissor, valor, descrição do serviço, data.

O agente cria uma proposta de lançamento: conta, centro de custo, crédito de ICMS/PIS/COFINS (BR) ou IVA (PT), início de depreciação. Essa proposta vai para o Decision Layer.

O Decision Layer verifica: A proposta de lançamento é consistente com os conjuntos de regras versionados? O centro de custo está correto? O crédito tributário é correto para esse tipo de nota fiscal? O valor está dentro dos limites de processamento autônomo?

Se sim: a proposta vai para o sistema-alvo (SAP ou outro ERP). O caminho decisório completo é armazenado no Audit Trail.

Se não: consulta ao responsável. O workflow pausa. O responsável vê a proposta, a regra aplicada, o valor de confiança e o motivo da escalação. Decide. Também essa decisão humana é documentada no Audit Trail.

## Quais modelos o Decision Layer roteia atualmente

O Decision Layer é agnóstico em relação ao modelo - cada microdecisão é roteada pela camada de routing para o modelo que melhor se encaixa em capacidade técnica e em custo. Em maio de 2026, o routing direciona tráfego produtivo, entre outros, para:

- **Claude Opus 4.7** e **Claude Sonnet 4.6** (Anthropic, Cloud API) - pela qualidade de raciocínio em escalações de compliance, processos longos e síntese de Decision Record
- **GPT-5.5** (OpenAI, Cloud API ou Azure OpenAI com residência de dados na UE) - para extração estruturada e tool use
- **Gemini 3.1 Pro** (Google, Cloud API) - para processamento multimodal de documentos (PDF + scan + tabela)
- **Mistral Small 3.2** (Apache 2.0, self-host ou La Plateforme) - para classificação de alto volume e sensível a custo
- **Mistral Medium 3.1** (La Plateforme, região UE) - quando a residência de dados na UE precisa ser garantida contratualmente, mas não há cluster próprio disponível
- **DeepSeek V4-Pro** e **V4-Flash** (licença MIT, self-host ou API) - para pesquisa em profundidade e caminhos decisórios com rigor matemático-lógico
- **Llama 4 Scout** (licença Meta, self-host, contexto de 10M tokens) - para processos longos e contexto completo de prontuário de pessoal
- **gpt-oss-120b** (OpenAI, Apache 2.0, self-host) - quando é necessário um modelo OpenAI sem dependência de cloud
- **Qwen 3 Coder 110B**, **DeepSeek Coder V4**, **Codestral Mamba 32B** - para microdecisões de código e ABAP/SQL no backend

Qual modelo é escolhido para cada microdecisão (critérios de seleção, panorama atual de benchmarks, comparação de TCO para Ibovespa e empresas de médio porte mais robustas) é abordado no artigo principal [Modelos de IA 2026 - qual modelo de linguagem para qual tarefa](/br/revista/modelos-ia-comparacao-2026/). O que disso é possível self-hostear on-prem - incluindo dimensionamento de GPU, condições de licença e stack de self-hosting - é abordado no spinoff [IA open-source auto-hospedada 2026](/br/revista/ia-open-source-auto-hospedada-2026/).

## Por que a IA toma algumas decisões melhor que um humano

Na discussão sobre agentes AI, uma pergunta é ignorada: Existem decisões em que a IA não é apenas mais rápida, mas comprovadamente melhor? A resposta é sim. E o Decision Layer permite identificar exatamente esses casos.

Há três categorias em que decisões autônomas de IA superam as humanas - não porque a IA é mais inteligente, mas porque não tem as fraquezas estruturais do ser humano:

**Consistência entre filiais e pessoas.** 50 colaboradores em 12 filiais aplicam o mesmo acordo coletivo. Cada um interpreta casos limites de forma ligeiramente diferente. Na filial A, um pagamento especial é aprovado; na filial B, o mesmo caso é rejeitado. Não é problema de treinamento - é a variância natural das decisões humanas. Uma IA que opera sobre um conjunto de regras versionado decide de forma idêntica. Toda vez, em toda filial.

**Imunidade à fadiga em decisões repetitivas.** Um recrutador avalia de forma diferente na segunda-feira de manhã e na sexta-feira à tarde. Após 50 currículos, a atenção cai. O candidato anterior era forte - o próximo parece mais fraco em comparação (viés de ancoragem). Uma IA avalia o currículo número 1 com o mesmo rigor que o currículo número 200. Não tem dia ruim.

**Completude na verificação de regras.** Um analista de RH verifica um atestado médico contra três ou quatro critérios que lhe vêm à mente: duração do afastamento, prazo de continuação salarial, talvez o limite para reabilitação profissional. Mas verifica também o período de carência? A regra especial para trabalhadores em tempo parcial no acordo coletivo? A obrigação de comunicação ao INSS (BR) ou Segurança Social (PT) em determinados diagnósticos? Toda vez? Também na sexta-feira às 16h? Uma IA verifica contra todas as regras vigentes, na versão atual, de forma completa e documentada. Não porque é mais inteligente - mas porque não esquece.

Isso não significa que a IA é melhor em tudo. Decisões discricionárias, avaliações individuais, adequação cultural, considerações éticas - esses são e continuarão sendo domínios humanos. Mas em decisões baseadas em regras, repetitivas e com alta necessidade de consistência, IA autônoma não é um compromisso. É a melhor solução.

O Decision Layer operacionaliza essa distinção: para cada microdecisão, define se decide o humano, o conjunto de regras ou a IA - e nas decisões de IA documenta *por que* a IA é a escolha correta.

## Por que nenhum agente deveria ir para produção sem Decision Layer

Sem Decision Layer, um agente AI é uma caixa-preta. Produz resultados, mas ninguém consegue rastrear como. Isso tem consequências concretas:

**Auditoria:** Auditores e auditoria interna precisam de rastreabilidade. Sem Audit Trail, cada decisão do agente é um risco de auditoria. O auditor precisa verificar manualmente cada caso individual - mais trabalhoso do que operar sem agente.

**Participação dos trabalhadores:** Os sindicatos e, em empresas com mais de 200 empregados, a CRE (BR), bem como a Comissão de Trabalhadores (PT), têm direitos de participação na implantação de sistemas AI. Sem lógica de decisão rastreável, não podem exercer sua função. O Decision Layer transforma acordos de empresa em restrições técnicas do sistema.

**Responsabilidade:** Se um agente gera um lançamento errôneo e não existe caminho decisório, não fica claro quem é responsável. O Decision Layer documenta a cadeia de responsabilidade.

**Escalabilidade:** Um agente que funciona em um piloto não necessariamente funciona em produção. Sem infraestrutura de governance, cada agente é um caso isolado. O Decision Layer permite governance consistente para todos os agentes.

## Decision Layer e Cert-Ready by Design

O Decision Layer é a base técnica do Cert-Ready by Design. Controles no Decision Layer são objetos de dados de primeira classe com atributos definidos: Control_ID, Technical_Implementation, Rule_Version, Evidence_Generator, Evidence_History, Auditor_View.

Evidências são geradas automaticamente - não compiladas retrospectivamente. Auditores veem no Auditor Portal o status em tempo real de todos os controles, com drill-down até a implementação concreta de cada regra.

O mapeamento de frameworks projeta os controles em padrões de auditoria estabelecidos: ISA, normas nacionais de auditoria, Normas Brasileiras de Contabilidade (NBC) e, no contexto português, o Sistema de Normalização Contabilística (SNC). Uma auditoria de demonstrações financeiras pode ser realizada com base nas evidências geradas automaticamente.

Mais informações: [Cert-Ready by Design](/br/governance/cert-ready/)

> [Decision Layer - visão geral e exemplos](/br/decision-layer/)

> [O ato de decisão: por que toda decisão de IA deve ser contestável](/br/revista/ato-de-decisao-decisoes-ia-contestaveis/)

<a href="/br/contato/" target="_blank" rel="noopener noreferrer">Agendar reunião</a> - Mostramos como um Decision Layer funciona para o seu processo concreto.

--- Eliminar erros de folha de pagamento - Decision Layer ---
> Lançamentos corretivos surgem por aplicação inconsistente de regras. O Decision Layer torna a lógica de decisão explícita, versionada e auditável.

## O problema: lógica profissional implícita

No processamento de documentos contábeis, pessoas tomam diariamente centenas de microdecisões. Conta contábil, centro de custo, início de depreciação, crédito tributário, classificação de despesas. Cada decisão se baseia em um conjunto de normas: legislação tributária (IRPJ, CSLL, PIS/COFINS no Brasil; PT: IRC, IVA em Portugal), normas contábeis do CPC (PT: SNC), diretrizes internas, particularidades de cada empresa do grupo.

O problema não é falta de conhecimento técnico. O problema é inconsistência. Diferentes analistas aplicam o mesmo conjunto de normas de formas distintas. Não porque são incompetentes, mas porque a legislação é complexa e sua interpretação admite margem de apreciação.

Mais empresas no grupo significa mais variantes normativas. Mais filiais significa mais analistas com interpretações diferentes. Mais pessoal significa mais processos de onboarding, mais conhecimento implícito, mais variância.

As consequências são mensuráveis: lançamentos corretivos, apontamentos de auditoria, ciclos de conciliação, fechamentos mensais prolongados. Os conjuntos normativos frequentemente existem apenas nas cabeças de determinados colaboradores. Quando esses colaboradores adoecem, saem de férias ou deixam a empresa, o conhecimento se perde.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Resumo - Decision Layer para Payroll</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Erros de folha de pagamento vêm do conhecimento implícito - regras existem em cabeças, não em sistemas. Quando colaboradores saem, o conhecimento vai junto.</li>
<li>Segundo o Hackett Group (2024), empresas com regras de folha explícitas e versionadas reduzem lançamentos corretivos em 60 a 80% no primeiro ano.</li>
<li>O Decision Layer torna a aplicação de regras explícita, versionada e auditável - cada decisão contábil é rastreável a uma regra definida.</li>
<li>Casos rotineiros são processados de forma autônoma; exceções são escaladas para especialistas com contexto completo e valor de confiança.</li>
<li>A prontidão para auditoria se torna estrutural: cada caminho de decisão é documentado automaticamente do documento de origem à regra aplicada.</li>
</ul>
</div>

## Decision Layer para processamento de documentos

O [Decision Layer](/br/decision-layer/) resolve esse problema tornando os conjuntos de regras explícitos, versionados e legíveis por máquina. Cada decisão contábil se baseia em uma regra definida em uma versão específica. Onde a decisão é determinística, o agente aplica o conjunto de regras de forma consistente. E onde o agente está confiante o suficiente e tem permissão: decide de forma autônoma - interpreta documentos, classifica situações, avalia contexto. Isso não é if-then-else - é capacidade de julgamento dentro de limites definidos.

O fluxo: chega um documento. O Document Agent lê e compreende o documento, independentemente do formato. Gera uma proposta de contabilização. O Decision Layer verifica essa proposta contra os conjuntos de regras versionados:

A conta contábil está correta? O centro de custo confere? O crédito tributário é admissível para esse tipo de fatura? O início da depreciação está correto? A classificação de despesas é consistente com as diretrizes daquela empresa?

Com alta confiança e regra clara: processamento autônomo. A proposta de contabilização segue para o sistema de destino ([SAP FI/CO](https://www.sap.com/products/erp/s4hana.html) ou outro ERP). Um Audit Trail completo é gerado.

Com baixa confiança ou exceção: escalação para o analista. O workflow pausa. O analista vê a proposta, a regra aplicada, o valor de confiança e o motivo da escalação.

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">eBook gratuito: IA em Finanças</p>
<p class="text-body text-gosign-text mb-4">Conformidade, auditores externos e Decision Layer - o manual de governança para liderança financeira.</p>
<a href="/br/ebook/ia-financas-manual-governanca/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Baixar grátis</a>
</div>

## Conjuntos de regras versionados

Cada alteração de regra cria uma nova versão. A versão anterior permanece no sistema. Em uma fiscalização ou auditoria é possível rastrear qual regra em qual versão estava vigente no momento da decisão.

Um exemplo: em 1o de julho muda a alíquota de PIS/COFINS (PT: IVA) para um determinado grupo de produtos. No Decision Layer, uma nova versão da regra é criada, vigente a partir de 1o de julho. Documentos anteriores a 1o de julho são processados com a versão anterior. Documentos a partir de 1o de julho com a nova versão. A transição é automática, rastreável e auditável.

## Parametrização por empresa

Para escritórios de contabilidade e consultorias tributárias com centenas de clientes: os conjuntos de regras são parametrizados por empresa. O mesmo agent aplica para cada cliente as regras corretas na versão vigente.

O cliente A usa o plano de contas completo conforme CPC (PT: SNC). O cliente B usa o plano simplificado para PMEs. O cliente C tem um plano de contas individualizado. O Decision Layer garante que o agent aplique para cada cliente as regras corretas, de forma consistente, independentemente de qual analista cuida do caso.

## Preparação para auditoria

Em uma fiscalização da Receita Federal (PT: Autoridade Tributária) ou auditoria das demonstrações financeiras, o auditor pode rastrear no Auditor Portal cada decisão contábil individual. A base é o ato de decisão por lançamento - o registro imutável com input/documento, regra de negócio aplicada com versão, confiança, resultado, carimbo de tempo e caminho de contestação, que torna a revisão da decisão individual possível de cumprir e comprovar nos termos da LGPD art. 20 (e do art. 86 do EU AI Act em negócios na UE). Do documento de origem até a regra aplicada com sua versão, do valor de confiança até o roteamento (autônomo ou escalado).

Isso reduz significativamente o esforço de auditoria. Em vez de extrair amostras manuais e reconstruir a lógica contábil para cada caso, o auditor vê o caminho de decisão completo documentado automaticamente.

<div class="overflow-x-auto">

| Aspecto | Sem Decision Layer | Com Decision Layer |
|---------|-------------------|-------------------|
| Aplicação de regras | Implícita, dependente de pessoa | Explícita, versionada |
| Consistência entre filiais | Variável | Idêntica |
| Lançamentos corretivos | 3 - 8% de todos os lançamentos | < 1% |
| Preparação para auditoria | Reconstrução manual | Documentação automática |
| Transferência de conhecimento | Meses de integração | Regras autodocumentadas |
| Evidência de compliance | Baseada em amostras | Caminho de decisão completo |

</div>

Mais informações: [Finance AI Agents](/br/servicos/ai-agents/)

→ [O ato de decisão: por que toda decisão de IA deve ser contestável](/br/revista/ato-de-decisao-decisoes-ia-contestaveis/)

<a href="/br/contato/" target="_blank" rel="noopener noreferrer">Agendar reunião</a> - Mostramos como um Decision Layer funciona para seu processamento de documentos.

--- Decision Layer e Shadow AI: controle em vez de caos ---
> Como o Decision Layer separa análise de decisão - e por que isso resolve Shadow AI, convence representantes dos trabalhadores e permite escalar.

## Dois problemas. Uma arquitetura.

Shadow AI e falta de governance são os dois maiores obstáculos para escalar IA nas empresas em 2026. O primeiro problema: colaboradores usam ferramentas de IA públicas sem controle porque a empresa não oferece alternativa. O segundo problema: mesmo quando a empresa disponibiliza IA, falta a arquitetura que separa análise de decisão.

O Decision Layer resolve ambos os problemas. É a camada de governance que define quem pode decidir o quê: humano, conjunto de regras ou IA. E simultaneamente a base para oferecer aos colaboradores uma ferramenta de IA controlada que supera as alternativas públicas.

Este artigo descreve por que Shadow AI é o risco do momento, como o Decision Layer funciona, qual o papel da classificação de dados e por que sem essa arquitetura nem a representação dos trabalhadores - sindicatos/CRE (BR) / Comissão de Trabalhadores (PT) - , nem auditores, nem a diretoria aprovarão o escalamento da IA.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Resumo - Shadow AI e o Decision Layer</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Shadow AI - o uso não controlado de ferramentas de IA públicas por colaboradores - é a Shadow IT de 2026: vazamento de dados, risco LGPD (PT: RGPD), zero rastreabilidade.</li>
<li>Proibir IA fracassa na prática. A solução é um portal de IA interno governado que supere alternativas públicas em funcionalidade e segurança.</li>
<li>O Decision Layer separa análise de decisão: IA pode analisar, mas quem age é definido por microdecisão (humano, regras ou IA).</li>
<li>Um esquema de classificação de dados de quatro níveis controla o routing de modelos - dados confidenciais nunca chegam a um modelo público.</li>
<li>Sem arquitetura governance-first, nem representantes dos trabalhadores, nem auditores, nem a diretoria aprovarão o escalamento da IA.</li>
</ul>
</div>

## Shadow AI: o risco subestimado

Shadow AI é a Shadow IT de 2026. O termo descreve o uso não controlado de serviços de IA públicos por colaboradores - sem conhecimento da TI, sem governance, sem Audit Trail.

A realidade na maioria das empresas: colaboradores usam ferramentas de IA públicas no trabalho diário. Redigem e-mails, resumem relatórios, analisam contratos, criam apresentações. Não por má intenção, mas porque essas ferramentas os tornam mais produtivos. E porque a empresa não oferece alternativa equivalente.

O problema não é o uso em si. O problema é o que acontece no processo:

**Vazamento de dados.** Cada entrada em uma ferramenta de IA pública deixa a rede corporativa. Conteúdos contratuais, dados financeiros, informações de pessoal, planos estratégicos. Tudo que entra no prompt está fora do seu controle.

**Sem rastreabilidade.** Qual colaborador transferiu quais dados para qual ferramenta? Ninguém sabe. Não há Audit Trail, não há registro, não há possibilidade de verificação retrospectiva.

**Sem controle de qualidade.** Resultados de ferramentas de IA públicas influenciam decisões de negócio sem que seja visível em que base foram gerados. Um rascunho de contrato parcialmente criado por IA. Quem revisa as cláusulas?

**Risco LGPD (PT: RGPD).** Dados pessoais transmitidos a serviços de IA públicos podem constituir um incidente de proteção de dados sujeito a notificação. Não em teoria, mas segundo a interpretação legal vigente, tanto pela LGPD no Brasil quanto pelo RGPD na UE.

A solução não é proibir. Proibições fracassam na prática. São contornadas, ignoradas ou esquivadas. A solução é uma oferta melhor: um portal de IA interno funcionalmente pelo menos equivalente, mas equipado com governance, proteção de dados e Audit Trail. Como é esse portal descreve o artigo [Enterprise-AI-Portal: mais que apenas um chat](/br/revista/enterprise-ai-chat-interface/).

## O Decision Layer: análise não é decisão

O Decision Layer é o princípio arquitetônico que separa análise de decisão. Um modelo de IA pode analisar: resumir dados, detectar padrões, calcular probabilidades, emitir recomendações. Mas a decisão de se e como agir com base nessa análise é uma questão separada. Essa questão é respondida pelo Decision Layer.

O princípio: cada processo de negócio é decomposto em microdecisões. Para cada microdecisão individual, define-se previamente quem decide:

```
Evento de entrada
|
+----------+
| Decision  |
|  Layer    |
+----------+
+----+------------+
v    v            v
REGRA   IA        HUMANO
```

**REGRA:** Decisões determinísticas que sempre produzem o mesmo resultado. Verificações de prazos, aplicação de acordos coletivos, lógica contábil, limiares de valor. O conjunto de regras é versionado. Cada alteração gera uma nova versão; a anterior permanece rastreável.

**IA:** Decisões em que o modelo pode agir autonomamente dentro de limites definidos. Classificações padrão, comunicação rotineira com templates verificados, atribuições inequívocas. Apenas com alta confiança e baixo risco.

**HUMANO:** Decisões discricionárias, exceções, casos com potencial discriminatório, decisões acima de limiares de valor definidos, todos os casos em que os representantes dos trabalhadores exigem participação.

Quatro princípios tornam o Decision Layer eficaz:

**Regras explícitas e versionadas.** Cada regra de decisão tem um identificador, uma versão, uma data de validade e um escopo de aplicação. Quando um acordo de empresa muda, uma nova versão da regra é criada. Em uma auditoria, é rastreável qual regra estava vigente no momento da decisão.

**Human-in-the-Loop imposto arquitetonicamente.** Para tipos de decisão definidos, o sistema não pode continuar sem aprovação humana. Isso é imposto tecnicamente, não acordado organizacionalmente. Um agente não pode contornar essa revisão porque a arquitetura não permite, não porque uma política proíbe.

**Audit Trail por microdecisão - o ato de decisão.** Cada microdecisão individual gera um ato de decisão imutável: input, regra de negócio aplicada com versão, valor de confiança, versão do modelo, decisão de routing, resultado, timestamp e caminho de contestação. Não é documentação retrospectiva. É o registro técnico do processo decisório - e torna a revisão da decisão individual possível de cumprir e comprovar nos termos da LGPD art. 20 (e do art. 86 do EU AI Act em negócios na UE).

**Acordos de empresa como restrições do sistema.** Requisitos dos representantes dos trabalhadores não são implementados como diretrizes organizacionais, mas como regras técnicas no Decision Layer. O sistema não pode contornar o acordo de empresa porque ele é parte da lógica do sistema. Os representantes dos trabalhadores podem rastrear cada decisão no Audit Trail.

## Classificação de dados como fundamento

Antes que o Decision Layer possa ser eficaz, uma questão fundamental deve ser respondida: Quais dados podem ser processados por qual modelo de IA? A resposta vem de um esquema de classificação de quatro níveis:

| Nível | Denominação | Exemplos | Processamento de IA permitido |
|---|---|---|---|
| 1 | Público | Comunicados de imprensa, conteúdo de sites | Todos os modelos, incluindo APIs públicas |
| 2 | Interno | Apresentações, documentos de processo, diretrizes internas | Nuvem UE ou modelos self-hosted |
| 3 | Confidencial | Dados de RH, dados financeiros, contratos, dados de clientes | Apenas self-hosted ou com anonimização PII |
| 4 | Estritamente confidencial | Documentos de M&A, patentes, comunicação da diretoria | Apenas On-Premises, nenhum modelo em nuvem |

A classificação determina automaticamente o routing do modelo. Quando um colaborador faz uma pergunta sobre um contrato (nível 3), o sistema direciona automaticamente a solicitação a um modelo self-hosted ou anonimiza os dados antes da transferência. Um modelo público não é opção para dados de nível 3. A arquitetura garante que isso seja tecnicamente impossível, não apenas organizacionalmente proibido.

A classificação de dados não é uma tarefa pontual. Deve ser integrada aos processos existentes: cada novo documento, cada nova fonte de dados, cada novo processo recebe uma classificação. Idealmente de forma automatizada, com base no tipo de documento, reconhecimento de conteúdo e atribuição organizacional.

Sem classificação de dados, falta o fundamento para qualquer outra medida de governance. É a primeira decisão a ser tomada - antes da seleção do modelo, antes de construir a [infraestrutura](/br/servicos/infraestrutura/).

## Os cinco pilares do AI Governance

A classificação de dados é o fundamento. Sobre ele se erguem cinco pilares que formam um AI Governance completo:

**1. Controle de acesso.** Quem pode usar quais funções de IA? Quais assistentes, quais bases de conhecimento, quais agentes estão disponíveis para quais funções? O controle de acesso reflete a estrutura organizacional existente: RH vê assistentes de RH, Financeiro vê assistentes do Financeiro. A integração SSO garante que não é necessário gerenciar acessos separados.

**2. Auditoria e logging.** Cada interação com o sistema de IA é registrada. Não para vigiar colaboradores, mas para rastreabilidade de decisões de negócio. Quem fez qual pergunta e quando? Qual modelo respondeu? Com base em quais fontes? O Audit Trail é a base para auditoria interna, revisão financeira e evidências de compliance. A [arquitetura de referência de governance](/br/governance/reference-architecture/) descreve a implementação técnica em detalhes.

**3. Human Oversight.** A arquitetura define onde revisão humana é necessária. Não é um requisito genérico. É uma decisão diferenciada por microdecisão. Classificações rotineiras não precisam de revisor humano. Decisões de pessoal com potencial discriminatório, sempre. A granularidade dessa diferenciação distingue governance eficaz de burocrático.

**4. Garantia de qualidade.** Resultados de IA devem ser verificados - não cada um, mas sistematicamente. Amostras, feedback de usuários, avaliação automatizada. O modelo alucina? As referências a fontes estão corretas? As aplicações de regras estão precisas? Garantia de qualidade é um processo contínuo, não um teste pontual.

**5. Compliance e reporting.** No contexto da UE, a [AI Act](/br/revista/eu-ai-act-2026-empresas/) exige, pela legislação vigente a partir de 2 de agosto de 2026 - prazo que, após o acordo provisório do Digital Omnibus de 7 de maio de 2026, deve ser adiado para 2 de dezembro de 2027 (adoção formal ainda pendente) -, documentação técnica, classificação de riscos e Conformity Assessment para sistemas de IA de alto risco. Em Portugal, essas exigências se aplicam diretamente. No Brasil, embora a AI Act não tenha aplicação direta, a LGPD e projetos de lei em tramitação apontam na mesma direção. AI Governance deve incorporar esses requisitos desde o início, não adicioná-los depois. Relatórios periódicos sobre uso, desempenho de modelos, qualidade de decisões e status de compliance são a base para a gestão pela diretoria.

## Por que o Decision Layer é a chave para escalar

Empresas que querem escalar IA - de um projeto piloto para dez agentes em produção, de um departamento para toda a organização - se deparam sem Decision Layer com um limite duro. Não técnico, mas organizacional.

**Os representantes dos trabalhadores não darão consentimento.** No Brasil, a CLT e normas regulamentadoras garantem aos sindicatos e, em empresas com mais de 200 empregados, à CRE (Comissão de Representantes dos Empregados) papel de representação dos trabalhadores em questões que afetam condições de trabalho, incluindo impactos de novas tecnologias. Em Portugal, a Comissão de Trabalhadores tem direitos de consulta sobre introdução de sistemas de IA conforme o Código do Trabalho. Sem lógica de decisão rastreável, sem Human-in-the-Loop documentado, sem acordos de empresa como restrições do sistema, não haverá aprovação. O Decision Layer entrega exatamente a transparência e controlabilidade que os representantes dos trabalhadores exigem.

**A auditoria interna não dará sinal verde.** Auditores e revisão interna precisam de rastreabilidade. Quando um agente AI gera lançamentos, avalia contratos ou prepara decisões de pessoal, o caminho decisório deve ser auditável. Sem Audit Trail, cada decisão do agente é um risco de auditoria. O Decision Layer gera automaticamente as evidências que os auditores precisam.

**A diretoria não aprovará o orçamento.** Projetos piloto são financiados com orçamentos de inovação. Escalar exige orçamentos de investimento, e estes exigem um business case com números sólidos. O Decision Layer fornece os dados: tempos de processamento, taxas de erro, custo por operação, taxas de escalação. Sem esses dados, IA continua sendo uma linha de custo sem retorno demonstrável.

A sequência não é negociável: primeiro governance, depois escalamento. Não o contrário.

## Cookieless e Privacy by Design

Um portal enterprise de IA não deve proteger apenas os dados das consultas dos usuários, mas também o próprio uso. Isso significa: sem rastreamento, sem cookies analíticos, sem análise de comportamento.

**SSO em vez de contas separadas.** Colaboradores se autenticam pelo sistema de gerenciamento de identidades existente da empresa. Sem senhas separadas, sem perfis de usuário separados em um provedor externo.

**Sem cookies de rastreamento.** O portal de IA interno não usa cookies para análise de comportamento. Dados de uso são coletados exclusivamente para o Audit Trail - não para marketing, não para otimização de produto por terceiros, não para perfilamento.

**Dados de uso apenas para auditoria.** Qual colaborador fez qual consulta é registrado, mas exclusivamente para fins de governance: rastreabilidade, compliance, garantia de qualidade. O acesso a esses dados é restrito a funções autorizadas (segurança de TI, Encarregado de Proteção de Dados / DPO, revisão). O gestor direto não vê as consultas individuais de seus colaboradores.

**Privacy by Design.** Os requisitos de proteção de dados estão integrados na arquitetura, não adicionados depois. Anonimização PII, classificação de dados, routing de modelos - todos esses mecanismos operam automaticamente, com base na classificação dos dados, não na disciplina dos usuários.

Essa abordagem convence não apenas o Encarregado de Proteção de Dados, mas também os representantes dos trabalhadores: o sistema não vigia colaboradores. Documenta decisões de negócio.

---

[Decision Layer](/br/decision-layer/) é o componente central de governance da Gosign. Agnóstico em relação ao modelo, compatível com representantes dos trabalhadores, com Audit Trail completo e um ato de decisão por microdecisão - contestável nos termos da [LGPD art. 20 (e do art. 86 do EU AI Act em negócios na UE)](/br/revista/ato-de-decisao-decisoes-ia-contestaveis/). Mais sobre a [arquitetura de governance](/br/governance/).

<a href="/br/contato/" target="_blank" rel="noopener noreferrer">Agendar reunião</a>. 30 minutos para definir como um Decision Layer para seus processos deve funcionar e como Shadow AI na sua empresa pode ser endereçado de forma controlada.

--- Decision Layer vs. SAP Joule vs. Microsoft Copilot ---
> SAP Joule e Microsoft Copilot são agentes de IA. O Decision Layer é a camada de governance acima deles. Por que empresas precisam de ambos.

## A confusão

Tomadores de decisão nas empresas ouvem sobre SAP Joule, Microsoft Copilot, Google Gemini, deployments internos de GPT e se perguntam: O que preciso de tudo isso e onde o Decision Layer se encaixa?

A resposta é mais simples do que parece: Joule, Copilot e outros são agentes de IA, eles executam tarefas. O [Decision Layer](/br/decision-layer/) não é uma alternativa a esses agentes. É a camada de governance que fica acima deles e controla o que esses agentes podem fazer.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Resumo - Decision Layer vs. agentes enterprise</p>
<ul class="text-body text-gosign-text space-y-2">
<li>SAP Joule e Microsoft Copilot são agentes de IA que executam tarefas. O Decision Layer é a camada de governance acima deles que controla o que podem fazer.</li>
<li>Nem Joule nem Copilot oferecem mecanismos integrados para acordos coletivos, conformidade com AI Act ou caminhos de decisão auditáveis.</li>
<li>O Decision Layer é agnóstico em relação a modelo e agente - funciona com qualquer agente, incluindo modelos open source.</li>
<li>Empresas em ambientes regulados precisam de ambos: um agente para execução e um Decision Layer para governance.</li>
<li>Agentes são intercambiáveis. Governance é infraestrutura.</li>
</ul>
</div>

## Agente vs. camada de governance

Um agente de IA pode executar uma tarefa: resumir um documento, criar uma proposta de contabilização, responder a uma consulta normativa. O que o agente não pode: decidir se pode executar essa tarefa de forma autônoma ou se um humano precisa intervir.

SAP Joule pode propor um ajuste salarial no SuccessFactors. Mas o Joule não decide se essa proposta pode ir direto para o sistema ou se a representação dos trabalhadores (sindicatos/CRE; PT: Comissão de Trabalhadores) tem direito de participação. O Joule não conhece acordos coletivos. E o audit logging do Joule registra ações e citações de fontes - mas não um ato de decisão no nível de regras de negócio que documente qual cláusula da convenção coletiva, em qual versão, sustentou a decisão.

Microsoft Copilot pode criar um documento de onboarding. Mas o Copilot não decide qual enquadramento a CLT (PT: Código do Trabalho) prevê, se o sindicato ou comitê deve aprovar, nem se os requisitos da LGPD (PT: RGPD) da localidade específica estão sendo cumpridos.

O Decision Layer assume exatamente esse controle.

## Como Decision Layer e agentes enterprise trabalham juntos

O Decision Layer decompõe cada processo de negócio em passos de decisão individuais e define antecipadamente para cada um: Decide uma pessoa, um conjunto de regras ou a IA de forma autônoma? Onde há margem de discricionariedade, a arquitetura impõe a revisão humana. Onde a decisão é determinística, o agente aplica o conjunto de regras de forma consistente. E onde o agente está confiante o suficiente: decide de forma autônoma - interpreta, classifica, avalia contexto. Isso não é if-then-else - é capacidade de julgamento dentro de limites definidos. Quando o SAP Joule gera uma proposta de contabilização, essa proposta passa pelo Decision Layer antes de se tornar efetiva no sistema de destino.

O Decision Layer verifica: A proposta é consistente com os conjuntos de regras versionados? A confiança supera o limiar? A decisão afeta uma área sujeita a participação do comitê? É necessário Human-in-the-Loop?

Se tudo confere: a proposta vai para o sistema de destino. O Audit Trail documenta a decisão.

Se não: o workflow pausa. Um humano recebe a proposta, a regra aplicada, o valor de confiança e o motivo da escalação. Ele decide. Sua decisão também fica documentada.

## Por que empresas no Brasil e em Portugal precisam de ambos

SAP Joule e Microsoft Copilot estão sendo cada vez mais implantados em empresas brasileiras e portuguesas. Mas a implantação encontra barreiras que o agente sozinho não resolve:

Primeiro: representações de trabalhadores exigem transparência sobre decisões de IA. No Brasil, os sindicatos e, em empresas com mais de 200 empregados, a CRE demandam visibilidade. Em Portugal (PT: a Comissão de Trabalhadores tem direitos de consulta previstos no Código do Trabalho). Nem Joule nem Copilot oferecem mecanismos integrados para que acordos coletivos funcionem como restrições técnicas.

Segundo: na União Europeia, o AI Act exige, pela legislação vigente a partir de 2 de agosto de 2026 - prazo que, após o acordo provisório do Digital Omnibus de 7 de maio de 2026, deve ser adiado para 2 de dezembro de 2027 (adoção formal ainda pendente) -, governance documentado para sistemas de IA de alto risco, e processos de RH entram nessa categoria - e, com o art. 86, dá ao afetado o direito a uma explicação da decisão individual, só respondível por um ato de decisão por microdecisão. Isso afeta diretamente operações em Portugal. No Brasil, a LGPD art. 20 já garante hoje o direito de revisar decisões automatizadas, e o Marco Legal da IA traz obrigações semelhantes de transparência e supervisão humana. Agentes enterprise sozinhos não cumprem esses requisitos em nenhum dos mercados.

Terceiro: auditores e controles internos precisam de caminhos de decisão rastreáveis. Um agente que "faz uma proposta" sem um caminho de decisão documentado é um risco de auditoria, tanto sob normas do CFC brasileiro quanto sob normas ISA aplicáveis em Portugal.

O Decision Layer complementa SAP Joule e Microsoft Copilot com exatamente essas três dimensões: capacidade para participação dos trabalhadores, conformidade regulatória e prontidão para auditoria.

## A distinção de relance

| Capacidade | SAP Joule | Microsoft Copilot | Decision Layer |
|---|---|---|---|
| Execução de tarefas | Sim | Sim | Não (apenas governance) |
| Acordos coletivos como restrições técnicas | Não | Não | Sim |
| Documentação de conformidade AI Act | Não | Não | Sim |
| Caminho de decisão auditável | Não | Não | Sim |
| Ato de decisão por microdecisão (regra de negócio + versão) | Não | Não | Sim |
| Confidence Routing com escalação | Não | Não | Sim |
| Human-in-the-Loop (imposto arquitetonicamente) | Não | Não | Sim |
| Agnóstico de modelo | Não (ecossistema SAP) | Não (ecossistema Microsoft) | Sim |

SAP Joule é o agente dentro do ecossistema SAP. Microsoft Copilot é o agente dentro do ecossistema Microsoft. O Decision Layer é a camada de governance agnóstica em relação a modelo e agente que fica acima de ambos.

Agentes são intercambiáveis. Governance é infraestrutura.

> [Decision Layer em detalhe](/br/revista/decision-layer-explicado/)

> [O ato de decisão: por que toda decisão de IA deve ser contestável](/br/revista/ato-de-decisao-decisoes-ia-contestaveis/)

> [Arquitetura de referência](/br/governance/reference-architecture/)

<a href="/br/contato/" target="_blank" rel="noopener noreferrer">Agendar reunião</a> - Mostramos como o Decision Layer funciona na sua infraestrutura de sistemas existente.

--- Hospedar DeepSeek na sua própria infraestrutura ---
> Como empresas implantam a família DeepSeek (R1, V4-Flash, V4-Pro) e outros LLMs em conformidade com a LGPD no Azure, GCP ou Self-Hosted. Arquitetura, soberania de dados, roteamento de decisões em vez de modelo único campeão.

## Por que o DeepSeek é relevante para empresas

[DeepSeek](https://www.deepseek.com/) demonstrou com seus modelos open source que LLMs de alto desempenho não precisam vir exclusivamente da OpenAI ou do Google. A família DeepSeek vai do **R1 (janeiro de 2025, licença MIT)**, passando pelo **V4-Flash (abril de 2026, 284B/13B ativos MoE, MIT)**, até o **V4-Pro (1,6T/49B ativos, contexto de 1M, MIT)** e atinge em benchmarks o **patamar de GPT-5.5 / Claude Opus 4.7** - o V4-Pro se aproxima da performance frontier de modelos fechados sob licença MIT, com custos operacionais significativamente menores e total transparência sobre o código do modelo.

**Atualização maio 2026:** DeepSeek V4-Pro (1.6T/49B ativos MoE) e V4-Flash (284B/13B ativos) foram lançados em 24 de abril de 2026 como preview sob licença MIT. Para novos deployments, V4-Flash é o cavalo de batalha típico, enquanto V4-Pro se encaixa em setups de classe hyperscaler ou roda via API/hospedado para deployments menores. A arquitetura R1 permanece madura e production-ready, mas está sendo substituída por V4-Flash em novos deployments. Detalhes no artigo [IA open source auto-hospedada 2026](/br/revista/ia-open-source-auto-hospedada-2026/).

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Resumo - DeepSeek em uso enterprise</p>
<ul class="text-body text-gosign-text space-y-2">
<li>O DeepSeek R1 é open source (licença MIT) e pode rodar inteiramente self-hosted no Azure, GCP ou on-premise - sem vazamento de dados.</li>
<li>O self-hosting elimina o risco LGPD (PT: RGPD) do uso da API, onde dados fluem para a China. O modelo em si não é o risco - a API é.</li>
<li>As três opções de hospedagem (Azure, GCP, self-hosted) são tecnicamente equivalentes; a escolha depende do cenário de TI e dos requisitos de compliance.</li>
<li>Uma arquitetura agnóstica de modelos previne o vendor lock-in: quando um modelo melhor surge, é integrado sem reconstrução.</li>
<li>IDC (2024) estima que 42% das grandes empresas europeias planejam implantar pelo menos um LLM open-weight em infraestrutura privada até o final de 2026.</li>
</ul>
</div>

Para empresas, isso é relevante porque cria uma opção real de escolha: em vez de se vincular a um único fornecedor de LLM, organizações podem rodar vários modelos em paralelo, compará-los e utilizar o mais adequado para cada caso de uso.

A questão fundamental não é se o DeepSeek é bom o suficiente. A questão é como uma empresa opera LLMs de forma que soberania de dados, compliance e preparação para o futuro estejam garantidos, independentemente de qual modelo esteja liderando no momento.


## Três opções de hospedagem comparadas

### Azure: integração enterprise como ponto forte

O Azure AI Foundry oferece DeepSeek como implantação gerenciada. A vantagem para organizações com ambiente Microsoft existente: integração com Azure Entra ID (antigo Azure AD), configurações de rede e segurança já estabelecidas, e seleção de região para residência de dados. Para empresas brasileiras, a região Brazil South garante que os dados permaneçam no país. Para operações em Portugal, regiões da UE atendem ao RGPD. Instâncias GPU (A100, H100) estão disponíveis em pay-as-you-go ou Provisioned Throughput.

A desvantagem: vendor lock-in no nível Azure. Migrar depois para GCP ou Self-Hosted exige reconstruir a camada de implantação, a não ser que a arquitetura tenha sido projetada como agnóstica desde o início.

### GCP: flexibilidade e Kubernetes nativo

O Google Cloud Platform oferece via Vertex AI implantações gerenciadas de modelos open source. O ponto forte está na arquitetura nativa Kubernetes: organizações que já usam GKE (Google Kubernetes Engine) podem rodar LLMs como workloads em container ao lado dos serviços existentes. A região southamerica-east1 (São Paulo) atende requisitos de localização de dados da LGPD. Opções de TPU oferecem uma alternativa às GPUs NVIDIA.

### Self-Hosted: máximo controle

Para empresas com os requisitos mais rigorosos de proteção de dados, como o setor financeiro ou de saúde, Self-Hosting é a escolha coerente. Modelos DeepSeek rodam em servidores próprios ou em data center privado, sem qualquer dependência de nuvem. A contrapartida: maior esforço operacional em gestão de hardware, atualizações e escalabilidade.

| Critério | Azure | GCP | Self-Hosted |
|---|---|---|---|
| Setup | Gerenciado (AI Foundry) | Gerenciado (Vertex AI) | Manual (bare-metal/VM) |
| Residência de dados | Brazil South / UE | southamerica-east1 / UE | Data center próprio |
| Disponibilidade GPU | A100, H100 (pay-as-you-go) | A100, H100, TPU | A100, H100 (compra/leasing) |
| Risco vendor lock-in | Alto (específico Azure) | Médio (portável Kubernetes) | Nenhum |
| Esforço operacional | Baixo | Baixo-Médio | Alto |
| Ideal para | Organizações Microsoft-cêntricas | Organizações Kubernetes-nativas | Máxima soberania de dados |

As três opções são tecnicamente equivalentes. Não há comprometimentos arquitetônicos com Self-Hosting. A decisão depende do panorama de TI existente, requisitos de compliance e modelo operacional interno.


## Por que a decisão de hospedagem não é a mais importante

A maioria dos artigos sobre hosting de LLMs para no momento da decisão de hospedagem. Mas para empresas, o hosting é apenas a fundação: as perguntas reais vêm depois.

Como se governa qual modelo atende qual caso de uso? Como registrar prompts e respostas sem comprometer dados de colaboradores? Como garantir transparência sobre o uso de IA para a representação dos trabalhadores - sindicatos/CRE (BR) / Comissão de Trabalhadores (PT)? Como executar uma troca de modelo sem alterar a interface para 5.000 colaboradores?

Essas não são perguntas de hosting. São perguntas de arquitetura e governança. E é precisamente aqui que uma infraestrutura IA enterprise se distingue de um modelo hospedado.

Para empresas brasileiras, há uma camada adicional: a LGPD (BR) / RGPD (PT) impõe requisitos específicos sobre transferência internacional de dados. Modelos hospedados na China, como o DeepSeek via API, exigem bases legais sólidas para transferência de dados pessoais. O self-hosting elimina completamente essa questão. Em Portugal, o EU AI Act adiciona obrigações de classificação de risco que também afetam a escolha do modelo.


## Arquitetura agnóstica de modelos como estratégia

O panorama de LLMs muda mais rápido do que qualquer ciclo de procurement corporativo. O que é estado da arte hoje pode ser superado por um novo modelo em seis meses. Quem constrói toda a infraestrutura sobre um único modelo frontier, seja DeepSeek V4-Pro, GPT-5.5 ou Claude Opus 4.7, assume um risco estratégico. Uma camada de roteamento de decisões agnóstica de modelos (veja [Qual modelo quando?](/br/revista/modelos-ia-comparacao-2026/)) absorve a próxima troca geracional como uma alteração de configuração, e não como um re-engineering.

Uma [arquitetura agnóstica de modelos](/br/servicos/infraestrutura/) desacopla a camada de uso da camada de modelos. Colaboradores utilizam uma interface de chat unificada. Por trás, uma camada de orquestração roteia por micro-decisão em vez de apostar em um modelo campeão: **Mistral Small 3.2** (24B, Apache 2.0, RTX 4090) como cavalo de batalha de volume para 50-70 % das decisões (classificação, extração); **DeepSeek V4-Flash / V4-Pro** (MIT) ou **gpt-oss-120b** (Apache 2.0) para raciocínio on-prem; **Claude Opus 4.7 / GPT-5.5** (nuvem) para raciocínio frontier e workflows agênticos; **Gemini 3.1 Pro** (nuvem) para aplicações multimodais; **Qwen 3 Coder / DeepSeek Coder V4** para geração de código on-prem. [Llama](https://llama.meta.com/) e [Mistral](https://mistral.ai/) complementam o stack para domínios especializados.

Trocas de modelo, comparativos e testes A/B acontecem na camada de orquestração, de forma transparente para os usuários, auditável para TI, rastreável para o comitê de empresa.


## DeepSeek como componente, não como plataforma

DeepSeek é um modelo potente. Mas nenhum modelo sozinho resolve o problema enterprise. O que empresas precisam não é de um LLM hospedado, mas de uma infraestrutura na qual LLMs operam como componentes, integrados ao [Governance by Design](/br/governance/), conectados aos sistemas existentes, expansíveis com [agentes IA](/br/servicos/ai-agents/) que processam documentos e orquestram fluxos de trabalho.

O [Decision Layer](/br/decision-layer/) separa a análise do LLM da decisão de negócio. O modelo prepara, o humano decide, com um Audit Trail completo.

Na Gosign, construímos essa [infraestrutura IA](/br/servicos/infraestrutura/): agnóstica de modelos, em conformidade com a LGPD (BR) / RGPD (PT), no Azure, GCP ou Self-Hosted. DeepSeek é um de muitos componentes. A arquitetura faz a diferença.

--- Portais Enterprise AI: cinco interfaces comparados ---
> LobeChat, OpenWebUI, LibreChat, chatbot-ui e very-ai - cinco portais enterprise AI comparados. Funções, SSO, proteção PII, governance, self-hosting.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Resumo - Portais Enterprise AI</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Uma interface de chat sozinha não basta - empresas precisam de portais com SSO, Audit Trail, compartilhamento de assistentes e integração de agentes para prevenir Shadow AI.</li>
<li>Cinco opções open source disponíveis: LobeChat, OpenWebUI, LibreChat, chatbot-ui e very-ai - cada uma adequada a diferentes requisitos de governance.</li>
<li>Detecção e anonimização de PII é o diferencial crítico para ambientes regulados onde dados de colaboradores entram em prompts de IA.</li>
<li>Gartner (2024) reporta que 55% das organizações com IA generativa não possuem um framework de governance para seu uso.</li>
<li>O fator decisivo para a adoção não é tecnologia, mas experiência do usuário - o portal interno deve igualar ou superar os serviços públicos de IA desde o primeiro dia.</li>
</ul>
</div>

## O problema: um modelo sem interface

Um modelo de IA sem interface controlado é como um servidor sem frontend. A tecnologia está lá, mas ninguém pode usá-la de forma organizada. O que acontece é previsível: colaboradores recorrem a serviços de IA públicos - ChatGPT, Gemini, Claude.ai - com suas contas pessoais. Inserem dados corporativos em sistemas fora do controle da TI. Não há Audit Trail, não há classificação de dados, não há controle de acesso.

Isso é Shadow AI. A questão não é se está acontecendo na sua empresa. A questão é o quanto.

A solução não é proibir o uso de IA. A solução é fornecer um sistema interno que funcione melhor que as alternativas públicas, e que ao mesmo tempo esteja sob controle corporativo. Um simples chat não basta para isso. O que você precisa é um portal enterprise AI.

## O que um portal enterprise AI deve oferecer

Um portal enterprise AI é mais que uma janela de chat. É a plataforma central pela qual todos os colaboradores interagem com IA - de forma controlada, registrada e integrada ao cenário tecnológico existente. Seis requisitos distinguem um portal enterprise de um chat de consumo:

### 1. Multi-Model Routing

O portal deve conectar múltiplos modelos simultaneamente - APIs proprietárias na nuvem e modelos self-hosted. A lógica de routing decide automaticamente qual modelo atende cada solicitação: por tipo de tarefa, sensibilidade de dados e parâmetros de custo. Colaboradores veem uma interface unificada. Qual modelo opera em segundo plano é transparente para eles, mas rastreável.

### 2. Compartilhamento de assistentes

Departamentos criam assistentes especializados - com seu próprio system prompt, seus próprios documentos e seu próprio conjunto de regras. Um assistente para o jurídico que prepara revisões de contratos. Um assistente para RH que resume documentos de candidatos. Um assistente para compras que compara propostas de fornecedores. Esses assistentes são compartilhados dentro do departamento, versionados e gerenciados centralmente.

Essa é a diferença crucial em relação a um simples chat: nem todo colaborador precisa escrever prompts do zero. Em vez disso, usa um assistente configurado e otimizado por colegas da área. Isso reduz a barreira de entrada e eleva a qualidade dos resultados.

### 3. Integração de agentes

Um portal enterprise deve ir além do chat. Deve integrar [agentes AI](/br/servicos/ai-agents/) - workflows especializados que processam documentos, extraem dados, preparam decisões ou se comunicam com sistemas externos. O agente é disparado pelo portal, seu progresso é exibido e seu resultado é documentado no portal.

### 4. SSO e controle de acesso baseado em funções (RBAC)

Colaboradores fazem login pelo sistema de gerenciamento de identidades existente - Azure AD, Okta, Google Workspace. Sem contas separadas, sem senhas separadas. O controle de acesso é por funções: quem pode usar quais modelos? Quem pode criar assistentes? Quem pode acessar quais fontes de documentos? Quem tem acesso a workflows de agentes?

### 5. Audit Trail

Cada interação é registrada. Quem fez qual consulta e quando? Qual modelo respondeu? Quais documentos foram referenciados? Quais custos foram gerados? O Audit Trail é exportável - para auditoria interna, para revisões de compliance, para documentação da AI Act (aplicável em Portugal e como referência para futuras regulamentações no Brasil).

### 6. Flexibilidade de implantação

O portal deve ser implantável em diferentes ambientes: como serviço na nuvem (Supabase, Vercel), como contêiner em um data center europeu ou brasileiro, ou On-Premises. A decisão de hosting do portal segue os mesmos critérios da decisão de hosting dos modelos.

## Interfaces open source em comparação

Cinco projetos open source se posicionaram como candidatos para portais enterprise AI: LobeChat, OpenWebUI, LibreChat, chatbot-ui e very-ai. Todos cinco são self-hosted, agnósticos em relação ao modelo e oferecem uma interface de chat para modelos de linguagem. As diferenças estão na integração SSO, funções de governance, proteção PII e compatibilidade com representantes dos trabalhadores.

**Nota de transparência:** very-ai é desenvolvido pela Gosign GmbH - a editora desta série de artigos. Apresentamos os pontos fortes e limitações dos cinco portais igualmente. very-ai se baseia em um fork do chatbot-ui (licença MIT) e evoluiu para um produto independente através de 16 extensões enterprise.

## Comparação: cinco portais enterprise AI

| Critério | LobeChat | OpenWebUI | LibreChat | chatbot-ui | very-ai |
|-----------|----------|-----------|-----------|------------|---------|
| **Licença** | Apache 2.0 | MIT | MIT | MIT | Apache 2.0 |
| **Base** | Projeto próprio | Projeto próprio | Projeto próprio | Projeto próprio | Fork do chatbot-ui |
| **Agnóstico de modelo** | ✅ OpenAI, Anthropic, Google, Ollama | ✅ OpenAI, Ollama, LiteLLM | ✅ OpenAI, Anthropic, Google, Mistral | ✅ OpenAI, Anthropic, Google, Ollama | ✅ OpenAI, Anthropic, Google (Vertex AI), Ollama |
| **SSO** | ❌ Não nativo | OAuth 2.0 (sem Entra ID nativo) | OAuth 2.0, OpenID Connect | ❌ Não nativo | ✅ Azure Entra ID nativo com sincronização de grupos e permissões |
| **Proteção PII** | ❌ | ❌ | ❌ | ❌ | ✅ Detecção, anonimização e re-anonimização |
| **PII por assistente/modelo** | - | - | - | - | ✅ Configurável por assistente E por modelo |
| **Assistentes de grupo** | ❌ | Modelos comunitários (limitado) | Conversas compartilhadas | ❌ | ✅ Controlados via grupos Entra ID |
| **Audit Trail** | ❌ | Logging básico | Logging básico | ❌ | ✅ Completo, exportável (CSV/JSON) |
| **Estatísticas LGPD (PT: RGPD)/RGPD** | ❌ | ❌ | ❌ | ❌ | ✅ Estatísticas de uso anonimizadas |
| **Integração Trigger.dev** | ❌ | ❌ | ❌ | ❌ | ✅ Trigger de workflow a partir do chat |
| **Thinking Level** | ❌ | ❌ | ❌ | ❌ | ✅ Extended Thinking / controle de reasoning |
| **Busca Web/Maps** | Sistema de plugins | Busca web (RAG) | Sistema de plugins | ❌ | ✅ Integrado |
| **Docker Self-Hosted** | ✅ | ✅ | ✅ | ✅ | ✅ |
| **GitHub Stars (fev 2026)** | ~50k | ~60k | ~20k | ~28k | Novo (lançamento open source) |
| **Compatibilidade trabalhadores** | ⚠️ Limitada (sem auditoria, sem RBAC) | ⚠️ RBAC básico | ⚠️ RBAC básico | ❌ Sem governance | ✅ Audit Trail + RBAC + PII + Entra ID |

### LobeChat

LobeChat é uma interface de chat visualmente atraente com arquitetura de plugins. Seu ponto forte está no ecossistema de plugins e na variedade de APIs na nuvem. Para enterprise, falta RBAC robusto, Audit Trail exportável e integração nativa de agentes. Adequado como protótipo rápido ou para equipes pequenas; limitado demais para implantação organizacional.

### OpenWebUI

OpenWebUI é o padrão de facto para configurações self-hosted baseadas em Ollama. A integração com modelos executados localmente é excelente. SSO e logging básico estão disponíveis. O que falta: compartilhamento de assistentes, integração de agentes enterprise e gerenciamento centralizado para centenas de usuários.

### LibreChat

LibreChat é um clone open source da interface do ChatGPT com suporte multi-modelo. SSO e RBAC básico estão implementados. Para empresas que querem replicar internamente uma experiência tipo ChatGPT, LibreChat é um ponto de partida sólido. Os limites estão na integração de agentes e compartilhamento de assistentes.

## very-ai - portal enterprise com proteção PII e governance

very-ai é um portal enterprise AI baseado no chatbot-ui (MIT) que adiciona 16 funções enterprise inexistentes nos outros quatro portais. É desenvolvido pela Gosign GmbH e está disponível sob Apache 2.0 no GitHub.

**Origem e diferenciação:**
chatbot-ui oferece uma sólida interface de chat, mas não tem integração SSO, Audit Trail nem proteção PII. very-ai endereça exatamente isso: a base de código foi ampliada com funções enterprise necessárias para uso produtivo em ambientes regulados. A atribuição ao projeto original está documentada no arquivo NOTICES.

**Detecção e re-anonimização de PII:**
O diferencial central. very-ai detecta dados pessoais (nomes, e-mails, telefones, CPFs/NIFs) nos prompts dos usuários, substitui por marcadores ([PERSON_1], [EMAIL_1]), envia o texto anonimizado ao modelo de linguagem e reinsere os dados originais na resposta. O usuário vê os nomes reais; o modelo de linguagem nunca os viu.

Esse comportamento PII é configurável por assistente e por modelo: Assistente A pode permitir PII, Assistente B anonimiza automaticamente. Modelo X recebe dados anonimizados, Modelo Y (um modelo hospedado localmente) recebe dados brutos.

**Azure Entra ID com sincronização de grupos:**
Não apenas autenticação, mas sincronização automática de grupos e funções do Entra ID. Colaboradores no grupo Entra ID "RH" veem automaticamente os assistentes de RH. Colaboradores em "Financeiro" veem assistentes do Financeiro. Sem atribuição manual de permissões no portal. Quando a membresia do grupo muda no Entra ID, o acesso no portal muda no próximo login.

**Assistentes de grupo:**
Administradores criam assistentes e os atribuem a grupos Entra ID. Esses assistentes são visíveis e utilizáveis apenas por membros do grupo correspondente. Isso permite ferramentas de IA departamentais sem um sistema de gerenciamento de permissões separado.

**Audit Trail e estatísticas LGPD/RGPD:**
Cada interação é registrada: usuário, modelo, assistente, prompt, resposta, timestamp, consumo de tokens, modo PII. O Audit Trail é exportável (CSV, JSON) e filtrável por período e usuário. As estatísticas de uso são anonimizadas conforme LGPD (BR) e RGPD (PT) - mostram uso de modelos e assistentes sem dados identificadores de usuário.

**Integração de workflows Trigger.dev:**
Usuários podem disparar workflows Trigger.dev a partir do chat. Isso conecta o portal AI com a camada de automação.

**Limitações (honestamente):**
very-ai é um projeto open source novo. A comunidade é pequena comparada ao LobeChat (50k estrelas) ou OpenWebUI (60k estrelas). Os ecossistemas de plugins dos portais estabelecidos são mais extensos. Quem busca um portal com máximo suporte comunitário e variedade de plugins está melhor atendido pelo LobeChat ou OpenWebUI. Quem precisa de proteção PII, sincronização de grupos Entra ID e logging compatível com requisitos de representantes dos trabalhadores, atualmente só encontra essa combinação no very-ai.

Demo ao vivo: [veryai.de](https://www.veryai.de/)

### Qual portal para qual uso?

**Máxima variedade de modelos e ecossistema de plugins:** LobeChat - o maior sistema de plugins, a comunidade mais ativa, amplo suporte de modelos. Ideal para equipes que priorizam flexibilidade e inovação rápida.

**Início mais fácil com Ollama:** OpenWebUI - integração nativa Ollama, instalação rápida, interface intuitiva. Ideal para hosting local de LLM e equipes começando com modelos open source.

**Máxima configurabilidade:** LibreChat - o controle mais fino sobre endpoints e parâmetros de modelos. Ideal para equipes técnicas operando múltiplos provedores com configurações distintas.

**Enterprise governance com proteção PII:** very-ai - a única opção com anonimização PII nativa, sincronização de grupos Entra ID e Audit Trail completo. Ideal para ambientes regulados onde representantes dos trabalhadores, proteção de dados e compliance participam das decisões.

**Projeto de avaliação e desenvolvimento:** chatbot-ui - base de código limpa, bom ponto de partida para desenvolvimentos próprios. Nota: chatbot-ui não tem desenvolvimento enterprise ativo; very-ai é a evolução enterprise dessa base de código.

*A maioria das empresas avalia 2-3 portais em paralelo com contêineres Docker - possível em uma tarde. O decisivo não é a interface, mas a capacidade de governance: SSO, Audit Trail, proteção PII e compatibilidade com representantes dos trabalhadores determinam qual portal vai para produção.*

## Por que "só um chat" não basta

A diferença entre uma interface de chat e um portal enterprise AI fica clara na operação. Uma comparação:

| Aspecto | Interface de chat | Portal enterprise AI |
|---|---|---|
| Uso | Pergunta-resposta individual | Ferramenta organizacional |
| Conhecimento | Cada usuário começa do zero | Assistentes agrupam conhecimento especializado |
| Controle | O usuário decide o que insere | Routing e RBAC gerenciam o fluxo de dados |
| Rastreabilidade | Nenhuma ou limitada | Audit Trail completo |
| Integração | Standalone | Conectado a SSO, agentes, sistemas de documentos |
| Escalabilidade | Por usuário | Por organização |
| Risco Shadow AI | Alto (oferta interna insuficiente) | Baixo (oferta interna superior) |

A conclusão central: Shadow AI não surge porque colaboradores agem com má intenção. Surge porque a oferta interna é pior que a alternativa pública. Quando o portal interno é tão intuitivo quanto o ChatGPT mas adicionalmente oferece assistentes especializados, acesso a documentos corporativos e workflows de agentes, não há razão para recorrer a serviços externos.

## Na prática: uma empresa de médio porte com 2.000 colaboradores

Um exemplo concreto mostra o impacto. Uma empresa manufatureira com 2.000 colaboradores tinha a seguinte situação inicial:

**Antes do portal:** Uma pesquisa interna revelou que 340 colaboradores usavam regularmente serviços de IA públicos para tarefas de trabalho. Destes, 180 com contas gratuitas (sem contrato de processamento de dados), 120 com contas Pro pessoais (dados corporativos em contas privadas) e 40 com contas fornecidas pela empresa (mas sem Audit Trail ou controle de acesso). A TI não tinha visibilidade sobre quais dados fluíam para quais sistemas.

**Implantação do portal enterprise AI:** Em quatro semanas, very-ai foi implantado - conectado ao Azure AD para SSO, com três assistentes iniciais (jurídico, RH, compras) e um endpoint gpt-oss-120b para dados confidenciais.

**Após 90 dias:**

- 15 assistentes especializados criados por departamentos
- 1.200 usuários ativos por mês (de 2.000 colaboradores)
- Uso de Shadow AI reduzido em 85% (pesquisa de acompanhamento)
- Audit Trail completo: 47.000 interações registradas
- Identificação de três processos para os quais workflows de agentes dedicados faziam sentido
- Custo total (portal + hosting + APIs na nuvem): aprox. 4.800 EUR por mês

O fator decisivo não foi a tecnologia, mas a adoção. O portal foi aceito porque era melhor que a alternativa, não porque foi obrigatório.

## Cinco fatores de sucesso na implantação

Da prática derivam-se cinco fatores que determinam o sucesso ou fracasso de um portal enterprise AI:

**1. A primeira impressão conta.** Se o portal interno é mais lento, mais complicado ou menos capaz que o ChatGPT, os colaboradores não voltarão a usá-lo após a primeira tentativa. A qualidade das respostas deve igualar os serviços públicos desde o primeiro dia.

**2. Assistentes em vez de prompts.** A maioria dos colaboradores não é engenheira de prompts. Querem usar uma ferramenta, não configurá-la. Assistentes especializados preparados por colegas da área reduzem significativamente a barreira de entrada.

**3. Valor agregado visível.** O portal deve oferecer algo que serviços públicos não conseguem: acesso a documentos internos (via RAG), assistentes especializados para tarefas específicas da empresa, integração em workflows existentes.

**4. Propriedade da TI, não controle da TI.** A TI opera o portal e define as regras de governance. Mas os departamentos criam seus próprios assistentes. Essa divisão - infraestrutura centralizada, conteúdos descentralizados - provou ser o modelo mais bem-sucedido.

**5. Medir e comunicar.** Números de uso, tempo economizado, Shadow AI reduzido - essas métricas devem ser coletadas e comunicadas à diretoria. Sem resultados mensuráveis, falta a base para a próxima fase de expansão.

## Próximo passo: do portal ao agente

O portal enterprise AI é o fundamento. Fornece aos colaboradores acesso a IA, controlado e registrado. O próximo passo é integrar agentes - workflows especializados que vão além de interações simples de pergunta-resposta.

---

Leitura adicional: [Infraestrutura AI](/br/servicos/infraestrutura/) | [Decision Layer e Shadow AI](/br/revista/decision-layer-shadow-ai/)

---

very-ai é o portal enterprise AI open source da Gosign. [Saiba mais](/br/servicos/infraestrutura/) - ou fale diretamente conosco sobre qual configuração se adequa à sua organização.

<a href="/br/contato/" target="_blank" rel="noopener noreferrer">Agendar reunião</a> - Mostramos very-ai em uma demo ao vivo e discutimos seu plano de implantação.

--- EU AI Act 2026: Status, prazos, o que fazer agora ---
> EU AI Act 2026: proibições ativas, AI Literacy obrigatória, deadline High-Risk 2 de agosto de 2026 (adiamento para dezembro de 2027 acordado provisoriamente - Digital Omnibus). Cronograma, obrigações e recomendações.

O EU AI Act está em vigor. Dois prazos já expiraram, o deadline crítico de High-Risk chega em cinco meses. Status atual, obrigações e o que as empresas devem fazer agora.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Resumo - EU AI Act 2026: status para empresas</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Práticas de IA proibidas (Social Scoring, manipulação, reconhecimento de emoções no trabalho) e a obrigação de AI Literacy são juridicamente vinculantes desde fevereiro de 2025.</li>
<li>Obrigações de transparência e documentação GPAI para operadores de modelos de IA de propósito geral estão em vigor desde agosto de 2025.</li>
<li>O prazo crítico: pela legislação vigente, todos os sistemas de IA de alto risco (incluindo quase toda IA de RH) devem estar plenamente em conformidade até 2 de agosto de 2026. Sanções: até 15 milhões de euros ou 3% do faturamento global.</li>
<li>Digital Omnibus: em 7 de maio de 2026, Conselho e Parlamento chegaram a um acordo político provisório para adiar o prazo de alto risco para 2 de dezembro de 2027. A adoção formal e a publicação no Jornal Oficial da UE ainda estão pendentes (previstas para antes de 2 de agosto de 2026). A classificação de alto risco em si permanece inalterada.</li>
<li>Primeiro passo para toda organização: completar um inventário de sistemas de IA cobrindo todos os sistemas oficiais e Shadow AI em quatro a oito semanas.</li>
</ul>
</div>

Segundo Gartner (2025), menos de 10% das organizações sujeitas ao EU AI Act completaram seu inventário de sistemas de IA, o passo fundamental para conformidade. A Comissão Europeia estima que mais de 300.000 empresas na UE implantam sistemas de IA que podem se enquadrar no escopo regulatório.

<table>
<thead>
<tr><th>Marco</th><th>Data</th><th>Status</th><th>Obrigações principais</th></tr>
</thead>
<tbody>
<tr><td>Entrada em vigor</td><td>Agosto 2024</td><td>Ativo</td><td>Estrutura estabelecida</td></tr>
<tr><td>Práticas proibidas + AI Literacy</td><td>Fevereiro 2025</td><td>Ativo</td><td>Proibição Social Scoring, manipulação; obrigação de treinamento</td></tr>
<tr><td>Obrigações GPAI</td><td>Agosto 2025</td><td>Ativo</td><td>Transparência, rotulagem, inventário de governance</td></tr>
<tr><td>Sistemas High-Risk</td><td>2 de agosto de 2026 (adiamento para dez. 2027 acordado provisoriamente - Digital Omnibus)</td><td>Prazo vigente</td><td>Conformidade plena: gestão de riscos, governance de dados, Human Oversight</td></tr>
<tr><td>Disposições restantes</td><td>Agosto 2027</td><td>2027</td><td>Regras setoriais, categorias restantes</td></tr>
</tbody>
</table>

## A primeira lei abrangente de IA do mundo

O EU AI Act está em vigor desde agosto de 2024. É a primeira legislação abrangente do mundo para regular a inteligência artificial e se aplica a toda organização que desenvolva, implante ou forneça sistemas de IA na União Europeia. Em março de 2026, estamos no meio da fase de implementação: dois prazos já expiraram, o próximo chega em cinco meses. Quem não se preparou tem um problema. Quem começa agora, ainda tem tempo.

Para empresas brasileiras com operações na Europa, o EU AI Act é diretamente relevante. Em Portugal, como Estado-membro da UE, o regulamento aplica-se integralmente (PT: aplicação direta do Regulamento UE). Para o mercado brasileiro, embora não haja equivalente direto, a LGPD (PT: RGPD) já estabelece obrigações para sistemas automatizados de decisão. Este artigo oferece uma visão objetiva do estado atual: o que já vale, o que vem e quando, quais obrigações afetam sua empresa e o que você deve fazer nos próximos 90 dias.

## Cronograma: Cinco marcos

A implementação escalonada do EU AI Act se estende por três anos. Cada marco ativa obrigações diferentes.

```
Agosto 2024          Fevereiro 2025       Agosto 2025         Agosto 2026          Agosto 2027
|                    |                    |                   |                    |
v                    v                    v                   v                    v
Entrada em vigor    Práticas IA          Obrigações          Sistemas High-Risk   Demais
proibidas +          GPAI em vigor       devem estar          disposições
AI Literacy                              em conformidade
ATIVAS               ATIVAS              EM 5 MESES           2027
```

Para empresas, isso significa: duas etapas já são juridicamente vinculantes. A terceira, e para muitas empresas a mais crítica, entra em vigor em cinco meses. A preparação tipicamente requer de quatro a seis meses. O tempo é curto.

## O que já vale

### Práticas de IA proibidas (desde fevereiro 2025)

Desde 2 de fevereiro de 2025, determinadas aplicações de IA estão completamente proibidas na UE. Isso abrange:

- **Social Scoring:** Sistemas de IA que avaliam pessoas com base em seu comportamento social e derivam desvantagens em contextos não relacionados.
- **IA manipulativa:** Sistemas que manipulam o comportamento humano por técnicas subliminais, como dark patterns que forçam decisões de compra ou consentimentos.
- **Biometria em tempo real em espaços públicos:** A identificação biométrica em tempo real é fundamentalmente proibida. Exceções restritas existem para forças de segurança em casos de crimes graves, antiterrorismo e busca de pessoas desaparecidas, cada qual com autorização judicial.
- **Reconhecimento de emoções no local de trabalho e instituições educacionais:** Sistemas de IA que detectam emoções de trabalhadores ou estudantes são inadmissíveis.
- **Predictive Policing baseado em características individuais:** Avaliações de risco criminal baseadas exclusivamente em atributos pessoais.

**Sanções:** Infrações às proibições são punidas com multas de até 35 milhões de euros ou 7 por cento do faturamento anual global, o que for maior.

Para a maioria das empresas, essas proibições não exigem ações imediatas, pois as aplicações descritas raramente ocorrem no contexto empresarial. Mas a verificação é obrigatória: assegure-se de que nenhum de seus sistemas de IA se enquadra nessas categorias.

### AI Literacy (desde fevereiro 2025)

Em paralelo às proibições, desde fevereiro de 2025 vigora a obrigação de AI Literacy conforme o Artigo 4: todas as pessoas que operam, implantam ou utilizam sistemas de IA devem possuir um nível suficiente de competência em IA. A competência deve ser adequada ao contexto respectivo: um desenvolvedor precisa de conhecimento mais profundo que um usuário final que utiliza um chatbot.

O que isso significa na prática:

- **Obrigação de treinamento:** As empresas devem conseguir demonstrar que seus colaboradores foram treinados.
- **Obrigação de documentação:** Conteúdos de treinamento, listas de participantes e intervalos de atualização devem estar documentados.
- **Adequação ao contexto:** O treinamento deve corresponder ao papel. Um e-learning genérico não basta para os responsáveis que selecionam e respondem pelos sistemas de IA.

A obrigação de AI Literacy é frequentemente subestimada por não impor requisitos técnicos elevados. Mas já é exigível. E aplica-se a toda organização que utilize IA, independentemente da classe de risco do sistema.

### Obrigações GPAI (desde agosto 2025)

Desde agosto de 2025, estão em vigor as obrigações de transparência e documentação para modelos de IA de Propósito Geral (GPAI). Estas afetam primariamente os provedores de modelos de linguagem, não as organizações que os utilizam. Mas como deployer, como organização que utiliza um modelo GPAI em suas próprias aplicações, você tem obrigações:

- **Avisos de uso:** Se sua aplicação gera conteúdo que pode ser confundido com conteúdo criado por humanos, você deve sinalizá-lo.
- **Transparência perante os usuários:** Pessoas que interagem com um sistema de IA devem ser informadas.
- **Infraestrutura de governance:** Você deve conseguir documentar quais modelos GPAI utiliza, em qual contexto e com quais medidas de proteção.

As obrigações GPAI exigem um inventário limpo: Quais modelos de IA você utiliza? De qual provedor? Em qual aplicação? Com qual classificação de risco? Essas informações formam a base para a conformidade High-Risk que entra em vigor em cinco meses.

## Sistemas High-Risk: o prazo mais crítico (2 de agosto de 2026)

O deadline High-Risk de 2 de agosto de 2026 é, pela legislação vigente, o prazo mais crítico do EU AI Act para a maioria das organizações - prazo que, após o acordo provisório do Digital Omnibus de 7 de maio de 2026, deve ser adiado para 2 de dezembro de 2027 (adoção formal ainda pendente). A partir dessa data, todos os sistemas de IA que se enquadram no Anexo III devem estar plenamente em conformidade. Os requisitos são extensos.

### Quais sistemas se enquadram em High Risk?

O Anexo III do EU AI Act define oito áreas em que sistemas de IA são classificados como de alto risco. As mais relevantes para empresas:

- **Emprego, gestão de pessoal e acesso ao trabalho autônomo:** Sistemas de IA para vagas de emprego, seleção de candidatos, avaliação de desempenho, decisões de promoção e desligamentos.
- **Capacidade de crédito e seguros:** Avaliação automatizada de crédito, scoring de risco.
- **Identificação biométrica:** Reconhecimento facial, identificação por voz, inclusive em espaços não públicos.
- **Infraestrutura crítica:** Sistemas de IA em energia, água, transporte, telecomunicações.
- **Educação e formação profissional:** Avaliação automatizada de provas, controle de acesso a instituições educacionais.

### Requisitos para sistemas High-Risk

Se algum de seus sistemas de IA é classificado como High Risk, você deve atender os seguintes requisitos até o prazo de alto risco - 2 de agosto de 2026 pela legislação vigente, com adiamento para dezembro de 2027 acordado provisoriamente (Digital Omnibus, maio de 2026):

1. **Sistema de gestão de riscos:** Um sistema documentado para identificar, analisar e mitigar riscos ao longo de todo o ciclo de vida do sistema de IA.
2. **Governance de dados:** Requisitos sobre qualidade, representatividade e exatidão dos dados de treinamento. Ao utilizar modelos pré-treinados: documentação da procedência dos dados e do ajuste fino.
3. **Documentação técnica:** Documentação abrangente do sistema antes da implantação: arquitetura, procedimentos de treinamento, métricas de desempenho, procedimentos de teste, limitações.
4. **Obrigações de registro:** Registro automático de todos os eventos relevantes (logging) para garantir a rastreabilidade das decisões.
5. **Transparência:** Instruções de uso para deployers que permitam uma utilização adequada.
6. **Supervisão humana (Human Oversight):** Medidas técnicas que permitam supervisão efetiva por pessoas. O [Decision Layer](/br/decision-layer/) é uma arquitetura que implementa tecnicamente esse requisito.
7. **Exatidão, robustez, cibersegurança:** O sistema deve entregar de forma confiável o desempenho declarado e estar protegido contra manipulação.
8. **Avaliação de conformidade:** Para determinadas categorias, é necessária uma avaliação por um organismo notificado (Conformity Assessment Body). Para outras, uma autoavaliação é suficiente.

**Sanções:** Infrações às obrigações High-Risk são punidas com multas de até 15 milhões de euros ou 3 por cento do faturamento anual global.

## Relevância especial para RH

A área de Recursos Humanos é o departamento onde aplicações de IA mais frequentemente se enquadram na categoria High-Risk. Isso se deve ao Anexo III, ponto 4 - Emprego e gestão de pessoal. A classificação cobre:

**Screening automatizado de candidaturas: High Risk.** Qualquer sistema de IA que pré-selecione, avalie ou filtre candidaturas se enquadra na categoria High-Risk. Independentemente de a decisão final ser tomada por uma pessoa. Já a pré-seleção está regulada.

**Avaliações de desempenho assistidas por IA: High Risk.** Quando sistemas de IA analisam dados de desempenho e derivam avaliações ou preparam avaliações, é High Risk. Isso se aplica também a sistemas que apenas emitem recomendações.

**Predictive Attrition: High Risk.** Sistemas de IA que preveem quais colaboradores provavelmente deixarão a organização processam dados pessoais para derivar decisões de emprego. É High Risk.

**Otimização automática de escalas: potencialmente High Risk.** Se um sistema de IA cria escalas de turno processando preferências individuais, dados de desempenho ou informações de saúde, pode se enquadrar em High Risk. A classificação depende do escopo concreto dos dados.

Para departamentos de RH, isso significa: inventarie todos os sistemas de IA utilizados em contextos de emprego. Revise a classificação. Inicie a preparação de compliance: o tempo até o prazo de alto risco (2 de agosto de 2026 pela legislação vigente, com adiamento para dezembro de 2027 acordado provisoriamente) deve ser usado para alcançar plena conformidade High-Risk com calma. No Brasil, a CLT prevê participação sindical em mudanças tecnológicas (PT: o Código do Trabalho prevê informação e consulta da Comissão de Trabalhadores). Mais informações sobre a interação entre IA e RH em [HR & AI Agents](/br/hr-ai-agents/).

## Digital Omnibus: adiamento acordado provisoriamente

A Comissão Europeia propôs no final de 2025 um pacote Digital Omnibus que, entre outras coisas, adia os prazos High-Risk do EU AI Act. O adiamento combina uma data-limite de segurança (backstop) - 2 de dezembro de 2027 - com uma condicionalidade ligada à publicação de normas harmonizadas (seis meses adicionais para sistemas do Anexo III e doze meses para sistemas do Anexo I a partir da publicação das normas). O pacote também prevê simplificação das obrigações de reporte e elevação dos limiares para PMEs.

**Status (junho de 2026):** Em 7 de maio de 2026, Conselho e Parlamento chegaram a um acordo político provisório para adiar o prazo de alto risco do Anexo III de 2 de agosto de 2026 para 2 de dezembro de 2027. A adoção formal e a publicação no Jornal Oficial da UE ainda estão pendentes - previstas para antes de 2 de agosto de 2026, mas ainda não concluídas. Até a publicação, o prazo legalmente vigente continua sendo 2 de agosto de 2026.

**A recomendação:** Trabalhe com o enquadramento intermediário correto: prazo vigente 2 de agosto de 2026, adiamento para 2 de dezembro de 2027 acordado provisoriamente, adoção formal pendente. A classificação de alto risco em si permanece inalterada - portanto, vale usar o tempo até o novo prazo para estruturar a governance com calma, sem urgência artificial nem aposta cega na prorrogação antes de sua publicação.

## Recomendação prática: Inicie um inventário de sistemas de IA

Independentemente de seus sistemas de IA se enquadrarem em High Risk ou não: o primeiro passo é sempre o mesmo. Você precisa de um inventário completo de todos os sistemas de IA na sua organização.

### O que deve ser registrado

Para cada sistema de IA, documente:

- **Designação e descrição do sistema:** O que o sistema faz? Qual processo ele suporta?
- **Provedor e modelo:** Qual modelo de IA é utilizado? De qual provedor? Cloud API ou self-hosted?
- **Papel da sua organização:** Você é provider (provedor), deployer (operador) ou ambos?
- **Classificação de risco:** O sistema se enquadra em alguma das categorias do Anexo III (High Risk)? Nas proibições do Artigo 5? Ou trata-se de um sistema de risco limitado?
- **Pessoas afetadas:** Quais pessoas são afetadas pelas decisões ou resultados do sistema?
- **Processamento de dados:** Quais dados o sistema processa? Dados pessoais? Segredos comerciais?
- **Medidas de proteção:** Quais medidas técnicas e organizacionais estão implementadas? Human Oversight? Audit Trail?

### Cronograma

Um inventário de sistemas de IA para uma organização de médio porte é viável em quatro a oito semanas. O esforço depende do número de sistemas, do estado da documentação e da coordenação interna. Comece com os sistemas óbvios, as ferramentas de IA oficialmente adquiridas, e depois expanda para [Shadow AI](/br/revista/decision-layer-shadow-ai/): sistemas de IA que os colaboradores utilizam por conta própria sem que o departamento de TI saiba.

O inventário não é uma tarefa única. Deve ser atualizado continuamente, porque novos sistemas são adicionados, sistemas existentes são modificados e a avaliação regulatória evolui. A [infraestrutura de governance](/br/governance/) deve ser projetada para que o inventário permaneça um documento vivo.

## Resumo: O que você deve fazer agora

1. **Revise as proibições.** Assegure-se de que nenhum de seus sistemas de IA se enquadra nas práticas proibidas desde fevereiro de 2025.
2. **Cumpra a obrigação de AI Literacy.** Documente treinamentos para todos os usuários de IA na sua organização. A obrigação já está em vigor.
3. **Crie um inventário de sistemas de IA.** Registre todos os sistemas de IA, seus provedores, contexto de uso e classificação de risco. Prazo: quatro a oito semanas.
4. **Identifique os sistemas High-Risk.** Revise especialmente a área de RH, decisões de crédito e processos automatizados com impacto direto sobre pessoas.
5. **Inicie a conformidade High-Risk.** Para sistemas sob o Anexo III: estabeleça sistema de gestão de riscos, governance de dados, documentação técnica e Human Oversight. Deadline vigente: 2 de agosto de 2026, com adiamento para 2 de dezembro de 2027 acordado provisoriamente (Digital Omnibus, maio de 2026).
6. **Acompanhe a adoção do Digital Omnibus.** Em 7 de maio de 2026, Conselho e Parlamento acordaram provisoriamente o adiamento para dezembro de 2027, mas a adoção formal e a publicação ainda estão pendentes. Use o tempo adicional para preparar a governance - a classificação de alto risco permanece e as obrigações continuam sendo exigíveis.

---

Gosign apoia organizações na conformidade com o EU AI Act, do inventário de sistemas à avaliação de conformidade. Se você quer saber onde sua organização está, fale conosco.

<a href="/br/contato/" target="_blank" rel="noopener noreferrer">Agendar reunião</a>. 30 minutos para avaliar seu status de compliance.

--- EU AI Act e RH: O que muda para IA em decisões de pessoal ---
> IA em RH e alto risco pelo EU AI Act. O que isso significa, quais obrigações se aplicam e como o Decision Layer atende aos requisitos.

O EU AI Act classifica praticamente todos os sistemas de IA utilizados em processos de RH como alto risco. Pela legislação vigente, a partir de 2 de agosto de 2026 - prazo que, após o acordo provisório do Digital Omnibus de 7 de maio de 2026, deve ser adiado para 2 de dezembro de 2027 (adoção formal ainda pendente) - esses sistemas devem atender requisitos rigorosos de gestão de riscos, transparência e supervisão humana.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Resumo - IA em RH é alto risco pelo EU AI Act</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Sistemas de IA para recrutamento, avaliações de desempenho, promoções e demissões são classificados como alto risco conforme o Anexo III, n.o 4 do EU AI Act.</li>
<li>Práticas de IA proibidas (Social Scoring, manipulação) estão em vigor desde 2 de fevereiro de 2025. Obrigações completas de alto risco a partir de 2 de agosto de 2026 (adiamento para 2 de dezembro de 2027 acordado provisoriamente - Digital Omnibus, maio de 2026; adoção formal ainda pendente).</li>
<li>Seis requisitos obrigatórios: gestão de riscos, governance de dados, obrigações de registro, transparência, supervisão humana e precisão/robustez.</li>
<li>O Decision Layer mapeia cada requisito arquitetonicamente: Confidence Routing para riscos, conjuntos de regras versionados para governance de dados, Audit Trail para registros, Human-in-the-Loop para supervisão.</li>
<li>Sanções de até 15 milhões de euros ou 3% do faturamento anual global por infrações às obrigações de alto risco (art. 99, n.o 4) - até 35 milhões de euros ou 7% para práticas de IA proibidas (art. 5).</li>
</ul>
</div>

Segundo pesquisa da PwC (2024), apenas 24% das empresas que utilizam IA em processos de RH iniciaram preparação formal para conformidade com o EU AI Act, apesar do prazo de 2 de agosto de 2026 para sistemas de alto risco (adiamento para dezembro de 2027 acordado provisoriamente - Digital Omnibus, maio de 2026).

<table>
<thead>
<tr><th>Artigo EU AI Act</th><th>Requisito</th><th>Implementação no Decision Layer</th></tr>
</thead>
<tbody>
<tr><td>Art. 9</td><td>Sistema de gestão de riscos</td><td>Confidence Routing com limiares configuráveis</td></tr>
<tr><td>Art. 10</td><td>Governance de dados</td><td>Conjuntos de regras versionados com datas de vigência</td></tr>
<tr><td>Art. 12</td><td>Obrigações de registro</td><td>Audit Trail imutável por decisão</td></tr>
<tr><td>Art. 13</td><td>Transparência</td><td>Portal do Auditor com caminho de decisão completo</td></tr>
<tr><td>Art. 14</td><td>Supervisão humana</td><td>Human-in-the-Loop imposto para tipos definidos</td></tr>
<tr><td>Art. 15</td><td>Precisão e robustez</td><td>Monitoramento de viés e design model-agnostic</td></tr>
<tr><td>Art. 86</td><td>Direito à explicação da decisão individual</td><td>Ato de decisão por microdecisão com caminho de contestação (alinhado à LGPD art. 20)</td></tr>
</tbody>
</table>

## A classificação: IA em RH e alto risco

O EU AI Act classifica sistemas de IA utilizados em emprego, gestão de trabalhadores e acesso ao trabalho autônomo como alto risco (Anexo III, n.o 4). Isso abrange concretamente:

Sistemas de IA para recrutamento e seleção de candidatos. Sistemas de IA que influenciam promocoes, demissoes, atribuição de tarefas ou monitoramento de desempenho. Sistemas de IA que afetam condições de trabalho, incluindo ajustes salariais, enquadramentos e planejamento de escalas.

Resumindo: praticamente qualquer agente de IA que prepara, apoia ou toma decisões em processos de RH se enquadra na categoria de alto risco.

No Brasil, o PL 2338/2023 propoe classificação semelhante para sistemas de IA em contextos de emprego. Em Portugal, como membro da UE, o EU AI Act se aplica diretamente.

## Os prazos

Desde 2 de fevereiro de 2025 estao em vigor as proibições de práticas de IA inaceitaveis, incluindo social scoring e técnicas manipulativas. Pela legislação vigente, as obrigações completas para sistemas de IA de alto risco entram em vigor a partir de 2 de agosto de 2026 - prazo que, após o acordo provisório do Digital Omnibus de 7 de maio de 2026, deve ser adiado para 2 de dezembro de 2027 (adoção formal ainda pendente, em junho de 2026). A classificação de alto risco em si permanece inalterada: o tempo ate o novo prazo e a janela certa para estruturar a governance com calma, em vez de correr.

## O que e especificamente exigido e como o Decision Layer atende

Os seguintes requisitos se aplicam a todo operador de um sistema de IA de alto risco no ambito de RH:

**Artigo 9 - Sistema de gestão de riscos:**
O EU AI Act exige um sistema de gestão de riscos contínuo que identifique, avalie e mitigue riscos. No Decision Layer, isso e implementado por meio de Confidence Routing: cada decisão do agente e automaticamente avaliada por confiança e categoria de risco. Alto risco ou baixa confiança leva a escalação para um ser humano. Os limiares são configuráveis e documentados.

**Artigo 10 - Governance de dados:**
Conjuntos de regras versionados no Decision Layer garantem que a base de dados de cada decisão seja rastreável. Convenções coletivas (CCT/ACT; PT: acordos de empresa), acordos sindicais e regras de compliance possuem versões, datas de vigencia e escopos de aplicação. Em uma auditoria, e rastreável qual conjunto de regras, em qual versão, estava vigente no momento da decisão.

**Artigo 12 - Obrigações de registro:**
O Audit Trail no Decision Layer gera um registro de dados completo e imutável para cada decisão: entrada, modelo, conjunto de regras, confiança, decisão de roteamento, resultado, carimbo de data/hora. Automaticamente, não compilado a posteriori.

**Artigo 13 - Transparencia:**
Cada decisão do agente e rastreável no Portal do Auditor. A representação dos trabalhadores - sindicatos/CRE (BR) / Comissão de Trabalhadores (PT)  - , os encarregados de proteção de dados e os auditores podem consultar o caminho da decisão. Nenhuma caixa preta.

**Artigo 14 - Supervisao humana:**
Human-in-the-Loop e um principio arquitetonico no Decision Layer, não uma configuração opcional. Para tipos de decisões definidos, potencial de discriminação, temas com impacto nos direitos dos trabalhadores, limiares de valor, a arquitetura impoe a revisao humana. Um agente não pode contornar essa revisao.

**Artigo 15 - Precisao, robustez e ciberseguranca:**
O monitoramento de vies verifica sistematicamente padrões discriminatorios. Limiares de confiança garantem que o agente so decide de forma autônoma com certeza suficiente. O design model-agnostic permite trocar o modelo de linguagem sem alterar a lógica de governance.

**Artigo 86 - Direito à explicação:**
No Brasil, esse direito já vale hoje: a LGPD art. 20 garante ao titular o direito de revisar decisões automatizadas e de obter informações claras sobre os critérios utilizados - independentemente do EU AI Act. Para empresas com operações na UE, o art. 86 acrescenta a mesma exigência: dá a cada pessoa afetada o direito a uma explicação da decisão individual - não do sistema em geral, mas deste caso concreto. Essa pergunta só se responde por um ato de decisão por microdecisão: entrada, regra de negócio aplicada com versão, confiança, resultado e caminho de contestação. O Decision Layer gera esse ato no momento da decisão e torna o direito - da LGPD art. 20 hoje e do art. 86 em negócios na UE - possível de cumprir e comprovar, caso a caso.

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">eBook gratuito: IA em RH</p>
<p class="text-body text-gosign-text mb-4">Checklist EU AI Act, framework de decisões, perspectiva da representação dos trabalhadores e avaliação de prontidão - o manual de governança para líderes de RH.</p>
<a href="/br/ebook/ia-rh-manual-governanca/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Baixar gratuitamente</a>
</div>

## O que isso significa para os departamentos de RH

Empresas que hoje utilizam ou planejam utilizar IA em processos de RH devem construir estruturas de governance até o prazo de alto risco - 2 de agosto de 2026 pela legislação vigente, com adiamento para dezembro de 2027 acordado provisoriamente (Digital Omnibus, maio de 2026). Isso significa concretamente:

Lógica de decisão documentada para cada processo de RH assistido por IA. Mecanismos Human-in-the-Loop tecnicamente impostos para decisões com impacto em pessoal. Audit Trails auditáveis que tornem rastreável como cada decisão foi tomada. Monitoramento de vies que detecte e reporte padrões discriminatorios.

No Brasil, a CLT e as convenções coletivas (CCT/ACT) regem os direitos dos trabalhadores em relação a novas tecnologias no ambiente de trabalho. Os sindicatos e, em empresas com mais de 200 empregados, a CRE (Comissão de Representantes dos Empregados) têm papel de representação dos trabalhadores. Em Portugal (PT: Codigo do Trabalho), as Comissoes de Trabalhadores possuem direitos de informação e consulta sobre a introdução de tecnologias que afetem condições de trabalho.

O Decision Layer aborda ambos os blocos de requisitos, EU AI Act e legislacao trabalhista local (CLT no Brasil / Codigo do Trabalho em Portugal), em uma única arquitetura.

-> [Decision Layer em detalhe](/br/revista/decision-layer-explicado/)

-> [O ato de decisão: por que toda decisão de IA deve ser contestável](/br/revista/ato-de-decisao-decisoes-ia-contestaveis/)

-> [Participação dos trabalhadores e IA](/br/governance/co-determination/)

-> [HR Agent](/br/hr-ai-agents/)

<a href="/br/contato/" target="_blank" rel="noopener noreferrer">Agendar reunião</a> - Mostramos quais dos seus processos de RH se enquadram na categoria de alto risco e como o Decision Layer atende aos requisitos.

--- EU AI Act e RH - O que agora é obrigatório ---
> O EU AI Act classifica processos de RH como alto risco. Bias Monitoring, Human Oversight, transparência e documentação são obrigatórios.

O EU AI Act classifica a IA utilizada em decisões de pessoal como alto risco. Da classificação de risco ao monitoramento de viés e à supervisão humana - agora são requisitos legais, não funcionalidades opcionais.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Resumo - Obrigações do EU AI Act para RH</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Todo sistema de IA que influencia decisões de RH - recrutamento, avaliação de desempenho, remuneração, promoções - é alto risco conforme o Anexo III do EU AI Act.</li>
<li>Quatro requisitos essenciais: classificação de risco de cada sistema de IA, monitoramento de viés obrigatório, supervisão humana imposta e transparência completa com documentação.</li>
<li>Erros típicos: conformidade retroativa em vez de Governance by Design, declarar ferramentas de IA como "meramente de apoio" e informar a representação dos trabalhadores tarde demais.</li>
<li>A abordagem correta é Architecture-First: o Decision Layer decompõe cada processo de RH em etapas de decisão individuais com logging, versionamento e Human-in-the-Loop desde o primeiro dia.</li>
<li>Multas de até 35 milhões de euros ou 7% do faturamento anual global. Obrigações de alto risco a partir de 2 de agosto de 2026 (adiamento para 2 de dezembro de 2027 acordado provisoriamente - Digital Omnibus, maio de 2026; adoção formal ainda pendente).</li>
</ul>
</div>

O Parlamento Europeu (2024) estima que RH e emprego representam a maior categoria individual de aplicações de IA de alto risco sob o EU AI Act, afetando cerca de 85% das grandes empresas que utilizam IA em recrutamento ou gestão de pessoal.

<table>
<thead>
<tr><th>Processo de RH</th><th>Classificação EU AI Act</th><th>Requisito principal</th></tr>
</thead>
<tbody>
<tr><td>Triagem de CV / Recrutamento</td><td>Alto risco (Anexo III)</td><td>Monitoramento de viés, Audit Trail</td></tr>
<tr><td>Avaliação de desempenho</td><td>Alto risco (Anexo III)</td><td>Supervisão humana, transparência</td></tr>
<tr><td>Decisões de promoção</td><td>Alto risco (Anexo III)</td><td>Explicabilidade, Human-in-the-Loop</td></tr>
<tr><td>Planejamento de escalas (com dados pessoais)</td><td>Potencialmente alto risco</td><td>Avaliação de riscos, governance de dados</td></tr>
<tr><td>Compliance Knowledge Agent</td><td>Risco limitado</td><td>Obrigação de transparência</td></tr>
</tbody>
</table>

## O EU AI Act e RH: por que isso é relevante

O EU AI Act (Regulamento (UE) 2024/1689) está em vigor desde agosto de 2024. Ele regula sistemas de IA conforme seu nível de risco. Para departamentos de RH, a classificação é clara: sistemas de IA utilizados para decisões sobre pessoas no contexto de emprego são classificados como sistemas de alto risco (Anexo III, Ponto 4).

O EU AI Act não se aplica diretamente no Brasil, exceto para empresas com operações na UE. O PL 2338/2023 propõe requisitos semelhantes. (PT: O EU AI Act aplica-se diretamente em Portugal como membro da UE.)

Isso não afeta apenas software de recrutamento automatizado. Afeta qualquer uso de IA que influencie decisões de pessoal: triagem de candidaturas, avaliação de desempenho, propostas salariais, recomendações de promoção, otimização de escalas com IA, geração automatizada de referências profissionais.

As obrigações para sistemas de alto risco valem, pela legislação vigente, a partir de [2 de agosto de 2026](/br/revista/eu-ai-act-2026-empresas/) - prazo que, após o acordo provisório do Digital Omnibus de 7 de maio de 2026, deve ser adiado para 2 de dezembro de 2027 (adoção formal ainda pendente). Isso dá às empresas ainda tempo para preparação - mas as decisões de arquitetura precisam ser tomadas agora.

## O que o EU AI Act exige concretamente

Para sistemas de IA de alto risco na área de RH, o EU AI Act exige:

**Sistema de gestão de riscos (Art. 9):** Uma gestão de riscos contínua ao longo de todo o ciclo de vida do sistema de IA. Identificação de riscos, avaliação, medidas, revisão. Não é uma avaliação pontual, mas um processo contínuo.

**Qualidade de dados (Art. 10):** Os dados de treinamento, validação e teste devem ser relevantes, representativos, livres de erros e completos. Para RH, isso significa: se um agente é treinado com base em decisões históricas de pessoal, esses dados devem ser verificados quanto a viés. Discriminação histórica nos dados será reproduzida pelo sistema de IA.

**Documentação técnica (Art. 11):** Documentação completa do sistema de IA antes da implantação. Finalidade, funcionamento, indicadores de desempenho, limitações, riscos. Essa documentação deve ser mantida atualizada.

**Retenção de logs (Art. 12):** Registro automático de todos os eventos ao longo de toda a vida útil do sistema. No contexto de RH: cada decisão, cada recomendação, cada escalação.

**Human Oversight (Art. 14):** A supervisão humana deve ser garantida. O ser humano deve compreender as capacidades e limitações do sistema, ser capaz de interpretar os resultados e ter a possibilidade de intervir ou desligar o sistema.

**Bias Monitoring:** O EU AI Act exige que sistemas de alto risco sejam monitorados quanto a distorções. Para decisões de RH, isso significa: análise estatística sobre todas as decisões do agente. Determinados grupos estão sendo tratados de forma sistematicamente diferente?

**Transparência (Art. 13):** Pessoas afetadas devem ser informadas de que sistemas de IA são utilizados em decisões que as envolvem.

## O que isso significa para a arquitetura

Os requisitos do EU AI Act não são medidas organizacionais. São requisitos de arquitetura. Um sistema de IA que deve atender esses requisitos retroativamente precisa ser fundamentalmente reestruturado.

**Decision Layer:** O [Decision Layer](/br/revista/decision-layer-explicado/) decompõe cada processo de RH em etapas de decisão individuais e define para cada etapa: humano, conjunto de regras ou IA. A Rules Engine implementa os conjuntos de regras versionados. O Confidence Routing assegura a avaliação de risco. O mecanismo Human-in-the-Loop garante a supervisão humana. O Audit Trail atende a obrigação de retenção de logs.

**Bias Monitoring:** Por meio do Decision Layer, todas as decisões do agente são avaliadas estatisticamente. Desvios das distribuições esperadas são detectados e escalados. Não é um processo de revisão manual, mas um monitoramento automatizado.

**Auditor Portal:** A documentação técnica e as evidências estão disponíveis a qualquer momento no Auditor Portal. Auditores - internos ou externos - veem o status ao vivo de todos os controles.

## Cronograma: o que precisa acontecer agora

**Imediato:** Inventário de todos os sistemas de IA na área de RH. Inclusive aqueles que não são rotulados como "IA": algoritmos de scoring em software de recrutamento, otimização de escalas baseada em IA, geração automatizada de textos.

**Até Q3 2026:** Implementar sistema de gestão de riscos. Tomar decisões de arquitetura. Implementar infraestrutura de governance.

**A partir de 2 de agosto de 2026** (adiamento para dezembro de 2027 acordado provisoriamente - Digital Omnibus, maio de 2026)**:** Sistemas de alto risco devem atender integralmente os requisitos do EU AI Act.

No Brasil, a CLT (PT: Código do Trabalho) e as convenções coletivas regulam a participação dos trabalhadores em mudanças tecnológicas. Sindicatos e CRE (PT: Comissão de Trabalhadores) têm direito de participação quando sistemas técnicos monitoram o comportamento ou o desempenho dos trabalhadores. AI Agents em processos de RH enquadram-se nessa categoria. O Decision Layer aborda ambos os blocos de requisitos - EU AI Act e direito de participação dos trabalhadores - em uma única arquitetura.

Empresas que agora introduzem AI Agents para processos de RH devem projetar a arquitetura desde o início em conformidade com o EU AI Act. Conformidade retroativa é tecnicamente possível, mas significativamente mais trabalhosa e cara.

Mais informações: [EU AI Act 2026: Status completo](/br/revista/eu-ai-act-2026-empresas/) | [Agent Governance para RH](/br/revista/agent-governance-hr/)

<a href="/br/contato/" target="_blank" rel="noopener noreferrer">Agendar reunião</a> - Mostramos como sua IA de RH se torna compatível com o EU AI Act.

--- O EU AI Act vale no mundo todo. ---
> O EU AI Act não é excesso de regulação europeia. Ele simplesmente coloca no papel o que todo sistema jurídico já exige: Explique sua decisão.

*Somália. Sudão do Sul. Iêmen. Líbia. Síria. - Essas são as únicas exceções.*

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Resumo - Accountability de IA é universal</p>
<ul class="text-body text-gosign-text space-y-2">
<li>O EU AI Act não inventou decisões de IA explicáveis - foi o primeiro a codificar o princípio especificamente para sistemas de IA. A obrigação de explicar decisões existe em praticamente todos os sistemas jurídicos do mundo.</li>
<li>O RH é a área de maior risco porque decisões de IA sobre pessoas criam a maior superfície de ataque jurídico - do viés na triagem de CV às avaliações de desempenho automatizadas.</li>
<li>Um algoritmo enviesado escala a discriminação para 50.000 decisões simultaneamente, comparado a cerca de 50 por ano de um gestor enviesado.</li>
<li>Toda empresa que usa IA para decisões sobre pessoas precisa de duas camadas: um Decision Layer (trilha de evidências de cada decisão) e um Governance Layer (regras do jogo).</li>
<li>Shadow AI - funcionários usando ChatGPT, Copilot e outras ferramentas sem governance - é o risco mais urgente e subestimado para a maioria das organizações hoje.</li>
</ul>
</div>

Segundo a Comissão Europeia (2024), sistemas de IA classificados como alto risco pelo EU AI Act afetarão diretamente decisões de emprego em mais de 6.000 organizações nos Estados-membros da UE. O RH foi identificado como a área empresarial mais frequentemente afetada segundo o Anexo III.

## A pergunta de 50 milhões de reais

Uma empresa brasileira usa uma ferramenta de IA para triagem de candidatos. 500 currículos entram, 20 saem. Um dos 480 rejeitados entra com reclamação trabalhista. Não com base no EU AI Act. Com base na CLT e na LGPD (PT: RGPD) - a Lei Geral de Proteção de Dados, que no artigo 20 garante o direito à explicação de decisões automatizadas. E a LGPD prevê multas de até 2% do faturamento, limitadas a R$ 50 milhões por infração.

A pergunta do juiz do trabalho: "Explique como essa decisão foi tomada."

Silêncio.

Não porque a empresa agiu de má-fé. Mas porque ninguém na empresa consegue explicar como a ferramenta de IA produziu aquelas 480 rejeições. O RH comprou a ferramenta. A TI instalou. E a lógica de decisão está dentro de uma caixa-preta que ninguém consegue abrir.

Isso não é hipotético. Está acontecendo agora. O Brasil tem a Justiça do Trabalho mais ativa do mundo - mais de 3,5 milhões de novos processos por ano. E os juízes do trabalho brasileiros estão cada vez mais atentos ao uso de IA em decisões que afetam trabalhadores.

## Accountability não é invenção europeia

A maioria dos executivos arquivou mentalmente o EU AI Act como "regulação europeia." Isso é um erro caro. O EU AI Act não inventou o princípio de decisões explicáveis. Simplesmente foi o primeiro a colocá-lo no papel especificamente para sistemas de IA.

O princípio em si é universal.

**Brasil:** A LGPD é uma das legislações de proteção de dados mais robustas do mundo. O artigo 20 garante o direito de solicitar revisão de decisões tomadas unicamente com base em tratamento automatizado de dados pessoais. A CLT protege contra discriminação no emprego. O TST (Tribunal Superior do Trabalho) tem demonstrado crescente interesse em como algoritmos afetam decisões trabalhistas. E o Marco Legal de IA (PL 2338/2023) em tramitação no Senado segue a mesma linha do EU AI Act com classificação de risco.

**Estados Unidos:** Title VII do Civil Rights Act proíbe discriminação em decisões de emprego - desde 1964. A EEOC pode exigir a qualquer momento que uma empresa explique por que rejeitou um candidato. Em Nova York, Local Law 144 exige auditorias de viés obrigatórias para ferramentas de IA em recrutamento desde 2023.

**Argentina:** A Ley de Contrato de Trabajo protege contra discriminação laboral. A nova Lei de Proteção de Dados Pessoais segue padrões semelhantes à LGPD.

**União Europeia:** O EU AI Act aplica-se diretamente em todos os 27 estados membros. E empresas brasileiras que operam na UE ou processam dados de cidadãos europeus estão sujeitas a ele.

Dos 193 estados membros da ONU, existem exatamente 5 onde uma empresa não pode ser juridicamente responsabilizada por uma decisão de IA inexplicável. Não porque esses países permitam - mas porque não têm sistema judiciário funcional.

O EU AI Act não é excesso de regulação europeia. É a primeira resposta honesta a uma pergunta universal.

<table class="w-full text-left text-sm">
<thead><tr class="border-b border-gosign-border">
<th class="py-2 pr-4 font-semibold">Região</th>
<th class="py-2 pr-4 font-semibold">Legislação principal</th>
<th class="py-2 pr-4 font-semibold">Explicabilidade exigida</th>
<th class="py-2 pr-4 font-semibold">Decisões de RH cobertas</th>
</tr></thead>
<tbody>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">UE</td><td class="py-2 pr-4">EU AI Act, RGPD Art. 22</td><td class="py-2 pr-4">Sim (vinculante)</td><td class="py-2 pr-4">Sim (Anexo III alto risco)</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Brasil</td><td class="py-2 pr-4">LGPD Art. 20, CLT, PL 2338/2023</td><td class="py-2 pr-4">Sim (direito a explicação)</td><td class="py-2 pr-4">Sim (Justiça do Trabalho ativa)</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">EUA</td><td class="py-2 pr-4">Title VII, NYC Local Law 144</td><td class="py-2 pr-4">Sim (antidiscriminação)</td><td class="py-2 pr-4">Sim (decisões de emprego)</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">China</td><td class="py-2 pr-4">Algorithmic Provisions 2022</td><td class="py-2 pr-4">Sim (transparência exigida)</td><td class="py-2 pr-4">Sim (decisões algorítmicas)</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Argentina</td><td class="py-2 pr-4">Ley de Contrato de Trabajo</td><td class="py-2 pr-4">Sim (proteção trabalhista)</td><td class="py-2 pr-4">Sim (discriminação trabalhista)</td></tr>
</tbody>
</table>

## Por que o RH é o Ground Zero

<img src="/images/magazin/risk-pyramid-br.svg" alt="Pirâmide de risco: decisões de RH sobre pessoas carregam o maior risco" width="800" height="480" loading="lazy" />

Decisões erradas de IA sobre produtos são irritantes. Decisões erradas de IA sobre processos são caras. Decisões erradas de IA sobre pessoas são existenciais - para os afetados e para a empresa.

O RH é a área onde decisões de IA criam a maior superfície de ataque jurídico. Três cenários que já estão acontecendo:

Triagem de CV baseada em IA filtra sistematicamente candidatos com lacunas no currículo. Afetados: mães, pais, pessoas com doenças crônicas, profissionais em transição de carreira. Na legislação brasileira, isso configura discriminação indireta - e a Justiça do Trabalho brasileira tem sido particularmente rigorosa nesses casos.

Análise de sentimento em entrevistas por vídeo interpreta erroneamente diferenças culturais de expressão como sinais negativos. Afetados: candidatos de diferentes contextos culturais e regionais. No Brasil, com sua enorme diversidade cultural, esse risco é amplificado.

Ferramenta de predição de desempenho treinada com dados históricos de promoções reproduz os padrões do passado. Se no passado homens foram promovidos com mais frequência, a ferramenta replica esse padrão. Isso é discriminação de gênero sistemática - automatizada e escalada.

Cada um desses cenários já é acionável judicialmente no Brasil. Não a partir de 2 de agosto de 2026 - prazo das obrigações de alto risco do EU AI Act, cujo adiamento para 2 de dezembro de 2027 foi acordado provisoriamente no Digital Omnibus (maio de 2026, adoção formal ainda pendente). Agora. A CLT, a LGPD e a Constituição Federal já fornecem as bases legais.

E o problema real da discriminação por IA comparada à discriminação humana: um gestor enviesado toma talvez 50 decisões questionáveis por ano. Um algoritmo enviesado toma 50.000. Simultaneamente. Consistentemente. De forma comprovável.

## As duas camadas que toda empresa precisa

<img src="/images/magazin/decision-governance-layers-br.svg" alt="Governance Layer e Decision Layer: arquitetura de duas camadas" width="800" height="440" loading="lazy" />

A solução não é complexa - mas exige pensamento arquitetônico. Toda empresa que usa IA para decisões sobre pessoas precisa de duas camadas.

**O [Decision Layer](/br/revista/decision-layer-shadow-ai/) - a evidência.** O Decision Layer decompõe cada processo em etapas de decisão individuais e define para cada etapa: humano, conjunto de regras ou IA. Cada decisão assistida por IA responde: Quais dados entraram? Qual modelo decidiu, em qual versão? Qual foi o resultado e com qual nível de confiança? Um humano revisou o resultado antes de ele entrar em vigor? A decisão é reproduzível?

Isso não é luxo técnico. É o equivalente digital da contabilidade. E assim como nenhuma empresa pode operar sem contabilidade, em breve nenhuma empresa poderá operar sem Decision Layer.

**O Governance Layer - as regras do jogo.** Antes de a primeira decisão de IA ser tomada: Quais aplicações de IA sequer existem na empresa? A maioria das empresas não sabe. Quão arriscada é cada aplicação - não por categorias regulatórias, mas por impacto real nas pessoas? Quem é responsável? Spoiler: "a TI" não é resposta. Quando um humano deve intervir? E como tudo isso é auditado?

No Brasil, as Comissões Internas de Prevenção de Acidentes (CIPA) e os sindicatos têm papel crescente na discussão sobre implementação de sistemas de IA que afetam decisões trabalhistas. O Ministério Público do Trabalho já demonstrou interesse em investigar o uso de algoritmos discriminatórios em processos seletivos.

## O elefante na sala: Shadow AI

<img src="/images/magazin/shadow-ai-eisberg-br.svg" alt="Shadow AI iceberg: acima da linha d'água ferramentas oficiais, abaixo uso sem controle nem auditoria" width="800" height="600" loading="lazy" />

E agora o ponto mais desconfortável. A maioria das empresas debate governance para ferramentas de IA que implantou oficialmente. Enquanto isso, seus funcionários já estão usando ChatGPT, Claude, Copilot e outras ferramentas para preparar decisões - sem que ninguém saiba.

Recrutadores usam ChatGPT para resumir candidaturas. Gestores de equipe pedem ao Copilot que redija recomendações de promoção. O departamento de T&D gera avaliações de desempenho com IA.

Tudo isso está acontecendo. Agora. Sem Decision Layer. Sem Governance Layer. Sem qualquer rastreabilidade.

E quando alguém processar a empresa, a resposta não será "a IA decidiu" - será pior: "Nem sabíamos que a IA estava decidindo."

## A verdadeira pergunta

A pergunta não é: "Estamos em [conformidade com o EU AI Act](/br/revista/eu-ai-act-hr-alto-risco/)?"

A pergunta é: Conseguimos explicar amanhã - em cada país onde operamos - por que decidimos hoje o que decidimos?

Quem puder responder sim, está automaticamente em conformidade. Com o EU AI Act. Com a LGPD. Com a CLT. Com tudo o que vier.

Quem não puder, não tem um problema regulatório. Tem um problema de governance.

--- Hosting de IA: EU SaaS, data center europeu ou Self-Hosted? ---
> Tres estrategias de hosting para IA enterprise. Matriz de decisão por sensibilidade de dados, custo e controle.

## "Onde roda?" - A pergunta decisiva

Antes de selecionar um modelo, antes de construir agents, antes de implantar um interface, existe uma pergunta: onde rodam seus modelos de IA? Essa decisão determina quais garantias de proteção de dados você pode oferecer, quais requisitos regulatórios atende, quais são seus custos operacionais e o quanto você se torna dependente de provedores externos.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Resumo - Estratégia de hosting IA para enterprise</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Três níveis: EU SaaS (Cloud APIs), IaaS europeu (Self-Hosted GPU) e on-premises (hardware próprio) - mais a combinação híbrida.</li>
<li>A arquitetura híbrida roteia requisições por sensibilidade de dados: 60-70% cloud, 25-35% IaaS europeu, 5-10% on-premises.</li>
<li>Gartner (2025) estima que 40% das grandes empresas operarão arquiteturas híbridas de hosting IA até 2027, ante menos de 10% em 2024.</li>
<li>Modelos open source self-hosted (gpt-oss-120b) rodam em uma única GPU por aprox. 1.200 EUR por mês em provedores europeus.</li>
<li>Custos totais com estratégia híbrida ficam 30-40% abaixo de uma estratégia pura de Cloud API, com maior soberania de dados.</li>
</ul>
</div>

Existem três estratégias fundamentais - e uma quarta que se tornou padrão na prática: a arquitetura híbrida que combina as três.

## Nível 1: EU SaaS - Cloud APIs com residência de dados na UE

A opção mais simples e rápida: você usa as APIs dos provedores de modelos diretamente. Claude pela API da Anthropic (regiao UE), GPT-5.5 pelo Azure OpenAI (data center UE), Gemini pelo Google Cloud Platform (regiao UE). Os dados saem da sua rede, mas são processados em data centers da UE.

### Vantagens

**Inicio mais rápido:** Sem construir infraestrutura, sem provisionar servidores GPU, sem necessidade de expertise em ML-Ops. Configurar uma chave de API, assinar um contrato de processamento de dados, em produção em horas.

**Atualizacoes automáticas:** Atualizacoes de modelos, patches de segurança e melhorias de desempenho são implantadas pelo provedor. Sem esforco de manutenção do seu lado.

**Escalabilidade:** Sem gestão de capacidade. Em picos de carga, o provedor cloud escala automaticamente. Sem superdimensionamento, sem subcapacidade.

**Variedade de modelos:** Acesso a todas as variantes de modelos do provedor - flagship, equilibrado e orçamentário - pela mesma API.

### Riscos e limitações

**Dados saem da rede corporativa.** Mesmo com residência de dados na UE, suas requisicoes são processadas em infraestrutura que você não controla. O provedor tem acesso técnico aos dados durante o processamento.

**CLOUD Act.** Provedores americanos - incluindo Anthropic, OpenAI e Google - estao sujeitos ao CLOUD Act dos EUA. Sob certas condições, autoridades americanas podem solicitar acesso a dados mesmo quando armazenados em data centers da UE. Para a maioria dos dados corporativos, esse risco e avaliavel e aceitavel. Para segredos comerciais, dados classificados ou informações de infraestrutura crítica, não e.

**Dependencia do provedor.** Com uma estratégia de provedor único, você depende da politica de preços, das mudancas de API e da disponibilidade de um único provedor. Uma arquitetura model-agnostic (veja [Comparativo de modelos de IA 2026](/br/revista/modelos-ia-comparacao-2026/)) reduz esse risco.

**Contrato de processamento obrigatório.** Para uso em conformidade com a LGPD (PT: RGPD) e necessário um contrato de processamento de dados com o provedor. Os tres grandes provedores oferecem contratos padrão - revise-os com seu departamento jurídico. Atenção: Contratos padrão SaaS de operador de dados não cobrem temas específicos de IA como registro de prompts, separação de ambientes e cadeias de provedores de modelos. Nosso [checklist de requisitos para contratos de IA](/br/revista/contrato-dpo-ia-checklist/) identifica as dez lacunas e fornece 25 perguntas de verificação.

### Adequado para

- Tarefas padrão com dados não sensiveis: resumos, traducoes, resposta geral a perguntas
- Provas de conceito e projetos piloto
- Tarefas com volume variavel onde infraestrutura GPU dedicada seria antieconomiea
- Organizacoes sem expertise em ML-Ops que querem entrar em produção rapidamente

## Nível 2: IaaS europeu - hosting GPU em provedores europeus

A opção intermediaria: você aluga servidores GPU de um provedor europeu de Infrastructure-as-a-Service - como Hetzner, IONOS ou um provedor especializado de GPU cloud. Nesses servidores, você opera modelos open source como gpt-oss, Llama 4 ou Mistral Medium 3.1.

### Requisitos de hardware e custos concretos

| Modelo | Requisito GPU | Custo estimado/mes |
|---|---|---|
| gpt-oss-120b | 1x A100/H100 (80 GB) | aprox. 1.200 EUR |
| gpt-oss-20b | CPU/16 GB RAM (ou GPU pequena) | aprox. 200-400 EUR |
| Llama 4 Scout | 1x A100 (80 GB) | aprox. 1.200 EUR |
| Llama 4 Maverick | 4x A100 (80 GB) | aprox. 3.500 EUR |
| Mistral Medium 3.1 | 4x A100 (80 GB) | aprox. 3.500 EUR |

### Vantagens

**Dados ficam na Europa.** O servidor esta em um data center europeu, operado por um provedor europeu. Sem CLOUD Act, sem transferencia transatlantica de dados. Para conformidade com a LGPD (PT: RGPD), e a opção cloud mais segura.

**Sem vendor lock-in.** Você opera modelos open source sob Apache 2.0 ou a Meta Llama License. Se quiser trocar de provedor de hosting, migra o modelo - sem questoes de licença, sem negociações contratuais.

**Controle total do modelo.** Você decide qual modelo em qual versão roda. Pode ajustar, quantizar ou substituir modelos por versões mais novas - sem esperar pelo provedor.

**Custos previsiveis.** Servidores GPU tem custos fixos mensais. Sem cobrancas variaveis por tokens, sem surpresas em picos de carga. Para organizações com volume alto e constante, frequentemente mais econômico que Cloud APIs.

### Requisitos

**Competência ML-Ops.** Você precisa de alguem que implante, monitore, atualize e resolva problemas do modelo. Pode ser um engenheiro de ML interno ou um provedor de serviços externo, mas não e esforco zero.

**Planejamento de capacidade.** Um servidor GPU tem capacidade definida. Se você tem 500 requisicoes simultaneas, uma única GPU não basta. Você precisa entender perfis de carga e planejar capacidades.

**Sem atualizações automáticas.** Quando um novo modelo e lancado, você o implanta. Quando surge um problema de segurança, você aplica o patch.

### Adequado para

- Dados corporativos confidenciais (nivel de sensibilidade 2-3)
- Organizacoes que precisam eliminar riscos do CLOUD Act
- Casos de uso com volume constante e alto (vantagem de custo sobre Cloud APIs)
- Organizacoes com competência DevOps/ML-Ops existente

## Nível 3: On-Premises - IA no seu próprio hardware

A opção de controle maximo: você opera servidores GPU no seu próprio data center ou em um rack de colocação. Nenhum dado sai da sua rede - sob nenhuma circunstância.

### Vantagens

**Maxima soberania de dados.** Sem acesso externo, sem provedor externo, sem dependência externa. O hardware e seu, o modelo e seu, os dados nunca saem da sua rede.

**Certeza regulatoria.** Para operadores de infraestrutura crítica, orgaos governamentais, setor de defesa e organizações com dados classificados, on-premises e frequentemente a única opção que atende aos requisitos de compliance. No Brasil, a ANPD (Autoridade Nacional de Proteção de Dados) supervisiona a conformidade; em Portugal, a CNPD (PT: Comissão Nacional de Proteção de Dados) desempenha papel equivalente.

**Sem custos recorrentes de licença ou API.** Apos o investimento inicial, restam apenas eletricidade, refrigeração e manutenção. Em operação de longo prazo com alto volume, on-premises pode ser a opção mais econômica.

### Desafios

**Alto investimento inicial.** Um servidor GPU de produção com NVIDIA H100 (80 GB) custa entre 25.000 e 40.000 EUR. Para configurações mais potentes (multi-GPU, redundancia), os custos vao de 60.000 a 120.000 EUR ou mais.

**Equipe ML-Ops necessária.** On-premises significa: você e responsável por tudo. Manutencao de hardware, deployment de modelos, monitoramento, atualizações, segurança. Isso exige uma equipe dedicada ou um provedor de serviços experiente.

**Escalabilidade não e trivial.** Quando a demanda cresce, você não pode adicionar outra GPU com um clique. A aquisição de hardware leva semanas a meses.

### Adequado para

- Operadores de infraestrutura crítica e orgaos governamentais
- Dados classificados e níveis maximos de confidencialidade
- Organizacoes com data center próprio e competência ML-Ops
- Disposicao para investimento de longo prazo com volume muito alto

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">eBook gratuito: Infraestrutura de IA</p>
<p class="text-body text-gosign-text mb-4">Build, Buy, Hybrid - infraestrutura em conformidade regulatória com B/B/H-Framework e 7-Layer Reference Architecture.</p>
<a href="/br/ebook/ia-infraestrutura-manual-governanca/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Baixar grátis</a>
</div>

## A arvore de decisão

A seguinte lógica de decisão ajuda na atribuição:

```
Seus dados contem PII ou segredos comerciais?
+-- NAO -> EU SaaS (Nivel 1)
+-- SIM -> Infraestrutura crítica ou dados classificados?
+-- SIM -> On-Premises (Nivel 3)
+-- NAO -> IaaS europeu (Nivel 2) ou Hibrido
```

Na prática, a resposta raramente e um único nível. A maioria das organizações tem dados de sensibilidade variada e, portanto, precisa de uma arquitetura que cubra todos os níveis.

## Hibrido como padrão: A arquitetura de roteamento

A estratégia hibrida combina os tres níveis em uma única arquitetura. Uma camada de roteamento decide automaticamente qual requisicao passa por qual canal, com base na sensibilidade dos dados, não na decisão de colaboradores individuais.

### Como o roteamento funciona

**Nível de sensibilidade 1-2 (publico, interno):** Requisicoes vao por Cloud APIs. Rapido, econômico, escalável. Exemplo: resumir um whitepaper publico, traduzir um comunicado de imprensa, redigir um email geral.

**Nível de sensibilidade 3 (confidencial):** Requisicoes são roteadas para modelos self-hosted no data center europeu. Sem vazamento de dados, sem CLOUD Act. Exemplo: analisar contratos internos, processar dados de RH, avaliar dados financeiros confidenciais.

**Nível de sensibilidade 4 (estritamente confidencial / regulado):** Requisicoes rodam exclusivamente em infraestrutura on-premises. Exemplo: documentos classificados, sistemas de infraestrutura crítica, dados sob obrigações especiais de confidencialidade.

### Pre-requisito: Classificação de dados

Para que o roteamento funcione, a organização precisa classificar seus dados. Parece trabalhoso, mas em muitas organizações já existe - por exemplo, como parte de Sistemas de Gestão de Segurança da Informacao (SGSI) existentes ou frameworks nacionais de classificação de segurança. As regras de roteamento mapeiam essa classificação existente para a infraestrutura de IA.

### Implementação técnica

A camada de roteamento fica entre o [Enterprise AI Portal](/br/revista/enterprise-ai-chat-interface/) (o interface que os colaboradores usam) e os endpoints dos modelos. Consiste em tres componentes:

1. **Classificador:** Detecta automaticamente a sensibilidade dos dados de uma requisicao, com base em palavras-chave, sistema de origem ou marcacao explicita do usuario.
2. **Motor de roteamento:** Atribui a requisicao ao endpoint de modelo adequado: Cloud API, IaaS europeu ou on-premises.
3. **Audit Log:** Registra cada decisão de roteamento: qual requisicao, qual nível de sensibilidade, qual endpoint. Rastreavel e exportável.

### Efeito nos custos

A arquitetura hibrida otimiza não apenas a segurança dos dados, mas também os custos. Cloud APIs são baratas por requisicao, mas variaveis. Modelos self-hosted tem custos fixos que se amortizam com alto volume. A combinacao aproveita ambos: Cloud APIs economicas para o grosso das requisicoes não sensiveis, modelos self-hosted com custos fixos otimizados para o volume confidencial.

Na prática, vemos em organizações com 1.000+ colaboradores tipicamente a seguinte distribuicao: 60-70% das requisicoes passam por Cloud APIs (nivel 1-2), 25-35% por IaaS europeu (nivel 3), e 5-10% por on-premises (nivel 4). Os custos totais ficam 30-40% abaixo de uma estratégia pura de Cloud API, com maior soberania de dados.

## Resumo: Os tres níveis em visao geral

| Criterio | EU SaaS (Nivel 1) | IaaS europeu (Nivel 2) | On-Premises (Nivel 3) |
|---|---|---|---|
| Soberania de dados | Regiao UE, contrato processamento | Europa, sem CLOUD Act | Maxima |
| Custo inicial | Nenhum | Baixo (aluguel) | Alto (60-120K EUR+) |
| Custo operacional | Variavel (tokens) | Fixo (aluguel GPU) | Fixo (eletricidade, manutencao) |
| Esforco ML-Ops | Nenhum | Medio | Alto |
| Escalabilidade | Automatica | Manual | Manual, lenta |
| Adequado para | Dados nível 1-2 | Dados nível 2-3 | Dados nível 3-4 |

A estratégia certa e quase sempre uma combinacao. Gosign implementa a camada de roteamento que conecta os tres níveis, para que seus colaboradores usem um único interface e o sistema selecione automaticamente o caminho correto.

Saiba mais: [Infraestrutura de IA](/br/servicos/infraestrutura/) | [Decision Layer & Shadow AI](/br/revista/decision-layer-shadow-ai/)

---

**Enterprise AI Infrastructure Blueprint 2026 - Serie de artigos**

| Anterior | Visao geral | Próximo |
|:---|:---:|---:|
| [Modelos de IA 2026: Qual modelo para qual uso?](/br/revista/modelos-ia-comparacao-2026/) | [Visao geral](/br/revista/infraestrutura-ia-blueprint-2026/) | [Enterprise AI Portal: Quatro interfaces open source em comparativo](/br/revista/enterprise-ai-chat-interface/) |

*Todos os artigos desta serie: [Enterprise AI Infrastructure Blueprint 2026](/br/revista/infraestrutura-ia-blueprint-2026/)*

---

**Quer saber qual estratégia de hosting e a certa para seus dados?** Gosign analisa sua classificação de dados e projeta a arquitetura hibrida adequada.

<a href="/br/contato/" target="_blank" rel="noopener noreferrer">Agende uma conversa</a> - Em 30 minutos esclarecemos quais níveis de hosting você precisa.

--- Human-in-the-Loop - Princípio arquitetônico, não checkbox ---
> Human-in-the-Loop em AI Agents significa revisão humana imposta pela arquitetura. Confidence Routing, regras de escalação, verificações de viés.

## O problema: HITL como afirmação de marketing

Praticamente todo fornecedor de IA afirma que sua solução tem "Human-in-the-Loop". Na prática, isso frequentemente significa: em algum lugar do processo existe um botão de aprovação. Um ser humano pode clicar nele. Mas não é obrigado.

Isso não é Human-in-the-Loop. É uma aprovação opcional que desaparece sob pressão de tempo. Quando o analista processa 200 documentos por dia e 195 estão corretos, em algum momento ele vai aprovar todos sem verificar.

Human-in-the-Loop de verdade é um princípio arquitetônico. Significa: para tipos de decisão definidos, o agente não pode fisicamente agir de forma autônoma. O workflow pausa. O sistema-alvo não é acessado. Somente após revisão humana e aprovação documentada o processo continua.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Resumo - Arquitetura Human-in-the-Loop</p>
<ul class="text-body text-gosign-text space-y-2">
<li>HITL real é um princípio arquitetônico, não um botão de aprovação opcional - o agente fisicamente não pode contornar a revisão humana para tipos de decisão definidos.</li>
<li>Três gatilhos: baixa confiança do agente, classificação de alto risco (discriminação, participação dos trabalhadores) e primeira aplicação de novas regras.</li>
<li>O EU AI Act exige supervisão humana efetiva para sistemas de IA de alto risco - processos de RH se enquadram explicitamente nessa categoria.</li>
<li>Acordos de empresa se tornam restrições técnicas no Decision Layer que o sistema não pode contornar.</li>
<li>HITL não resolve viés nos dados de treinamento nem escala linearmente - é um componente ao lado de Audit Trail, Bias Monitoring e controles Cert-Ready.</li>
</ul>
</div>

Segundo a Comissão Europeia (2024), a supervisão humana é obrigatória para todos os sistemas de IA de alto risco sob o EU AI Act, e processos de RH estão explicitamente listados no Anexo III - o que torna o Human-in-the-Loop arquitetonicamente imposto uma necessidade legal, não uma escolha de design.

| Gatilho HITL | Descrição | Configurável |
|---|---|---|
| Baixa confiança | Incerteza do agente abaixo do limiar definido | Sim, por cliente |
| Risco de discriminação | Decisões com potencial discriminatório | Sempre escalado |
| Temas de participação dos trabalhadores | Decisões sujeitas a consulta dos representantes | Sempre escalado |
| Ultrapassagem de limiar de valor | Valor acima do limite de processamento autônomo | Sim, por cliente |
| Introdução de nova regra | Primeira aplicação de novo conjunto de regras | Durante fase de aprendizagem |

## HITL como princípio arquitetônico técnico

Na arquitetura Gosign, o Human-in-the-Loop é implementado no Decision Layer. A decisão sobre quando um ser humano é incluído baseia-se em três critérios:

**Confidence Routing:** Cada decisão do agente tem um valor de confiança. Se a confiança está abaixo do limiar definido, a escalação é automática. O limiar é configurável por cliente.

**Classificação de risco:** Determinados tipos de decisão são sempre escalados, independentemente da confiança. Decisões com potencial discriminatório, temas que afetam direitos dos trabalhadores, ultrapassagem de limites de valor.

**Escalação obrigatória baseada em regras:** Novos conjuntos de regras aplicados pela primeira vez sempre passam por revisão humana na fase de implantação. Somente após uma fase de aprendizagem validada o agente passa para o modo autônomo - exclusivamente para essa regra.

O requisito de Human-in-the-Loop é imposto tecnicamente. Não existe workaround, atalho ou override administrativo. O agente não pode contornar a escalação.

## Como HITL funciona na prática

Um agente de RH processa uma solicitação de pagamento especial. O Document Agent lê a solicitação. O Knowledge Agent verifica o ACT (Acordo Coletivo de Trabalho) (PT: Acordo de empresa) vigente. O Decision Layer avalia:

Resultado: pagamento especial aprovável conforme ACT, cláusula 12, parágrafo 3. Confiança: 94%. Risco: baixo.

Porém: a decisão envolve um componente de remuneração. Na configuração HITL, está definido: decisões de remuneração são sempre escaladas, independentemente da confiança. O workflow pausa.

O analista responsável vê no dashboard: a solicitação, a proposta do agente, a regra aplicada na versão atual, o valor de confiança, o motivo da escalação. Ele verifica, confirma ou corrige. Sua decisão é documentada no Audit Trail - incluindo a informação de que se trata de uma decisão Human-in-the-Loop.

## HITL e participação dos trabalhadores

Human-in-the-Loop é a resposta técnica a uma exigência organizacional: a participação dos trabalhadores. No Brasil, sindicatos e CRE (PT: Comissão de Trabalhadores) têm direito de participação na implantação de sistemas de IA, conforme previsto na CLT (PT: Código do Trabalho) e nas convenções coletivas, especialmente quando sistemas técnicos monitoram o comportamento ou o desempenho dos trabalhadores.

O Decision Layer transforma ACTs (Acordos Coletivos de Trabalho) em restrições técnicas. Se um ACT determina: "Decisões sobre avaliações de desempenho não podem ser tomadas de forma totalmente automatizada" - isso é implementado como regra HITL no Decision Layer. O agente não pode contornar essa regra.

O resultado: a representação dos trabalhadores pode verificar que suas exigências são impostas tecnicamente - não apenas prometidas organizacionalmente.

## HITL e EU AI Act

O EU AI Act exige para sistemas de IA de alto risco supervisão humana (Human Oversight, Art. 14). Processos de RH se enquadram explicitamente na categoria de alto risco: recrutamento, avaliações de desempenho, decisões de promoção, remuneração, desligamento.

Human-in-the-Loop como princípio arquitetônico atende os requisitos do EU AI Act para Human Oversight. Não é suficiente ter um ser humano no processo que teoricamente poderia intervir. O EU AI Act exige supervisão humana efetiva - isso significa: o ser humano deve poder compreender a decisão, deve poder interrompê-la e sua intervenção deve ser documentada.

O Decision Layer documenta em cada decisão HITL: quem revisou? Quando? Qual foi a proposta do agente? Qual foi a decisão humana? Estão em concordância ou divergem?

## O limite: o que HITL não resolve

Human-in-the-Loop não é solução para todos os problemas de governance. Concretamente:

HITL não resolve o problema de viés nos dados de treinamento. Se o modelo de linguagem é sistematicamente tendencioso, um analista não detecta isso em casos individuais. Para isso é necessário Bias Monitoring estatístico sobre todas as decisões do agente.

HITL não escala linearmente. Se o agente toma 10.000 decisões por dia e 20% são escaladas, são necessários recursos para 2.000 revisões manuais. Os limiares HITL devem ser calibrados para que a taxa de escalação permaneça gerenciável sem comprometer a governance.

HITL é um componente da arquitetura de [governance](/br/governance/) - junto com Audit Trail, Bias Monitoring, versionamento de conjuntos de regras e controles Cert-Ready.

Mais informações: [Decision Layer explicado](/br/revista/decision-layer-explicado/) | [Agentes de IA - Guia Enterprise](/br/revista/agentes-ia-enterprise-guia/)

<a href="/br/contato/" target="_blank" rel="noopener noreferrer">Agendar reunião</a> - Mostramos como Human-in-the-Loop funciona na sua arquitetura.

--- IA Governance Dashboard: monitoramento de agentes ---
> Como um dashboard de governança IA torna transparentes as atividades dos agentes para TI, comitê de empresa e auditoria interna. Audit Trail.

## Por que um dashboard não é suficiente, mas sem ele nada funciona

Governança de IA não é um problema de dashboard. Governança é um princípio arquitetônico. Mas sem uma camada de apresentação que torne transparentes as atividades dos agentes, a governança permanece abstrata. Ninguém na organização, nem TI, nem a representação dos trabalhadores - sindicatos/CRE (BR) / Comissão de Trabalhadores (PT)  - , nem a auditoria interna, consegue avaliar o que os agentes estão fazendo de fato.

Um dashboard de governança IA é a interface entre a arquitetura técnica de governança e as pessoas que assumem a responsabilidade. Ele torna visível o que o [Decision Layer](/br/decision-layer/) documenta nos bastidores.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Resumo - Dashboard de Governança IA</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Um dashboard de governança IA é a camada de apresentação dos dados do Decision Layer - não uma ferramenta de monitoramento independente.</li>
<li>Exibe atividades dos agentes, Audit Trail, desempenho de modelos e versões de regras em tempo real.</li>
<li>Três visões baseadas em papéis (TI, diretoria, representação dos trabalhadores) são pré-requisito para que a governança funcione na prática.</li>
<li>Gartner (2024) prevê que até 2026, organizações com frameworks de governança IA terão 40% menos incidentes de compliance relacionados a IA.</li>
<li>Sem dashboard, ninguém na organização consegue verificar o que os agentes de IA realmente fazem.</li>
</ul>
</div>


## O que um dashboard de governança IA precisa mostrar

### Atividades dos agentes: quem faz o quê

Cada agente gera um registro de protocolo a cada ação: timestamp, entrada, regra aplicada, saída, status (processado automaticamente, encaminhado para aprovação, escalado). O dashboard agrega esses registros e permite filtragem por período, departamento, tipo de agente e status.

Isso não é monitoramento de TI convencional. É um protocolo de decisões, construído para pessoas que precisam entender o que os agentes fazem na sua área de responsabilidade.

### Audit Trail: rastreabilidade completa

Para cada decisão individual do agente existe um registro completo de dados: qual documento foi apresentado? Quais dados foram extraídos? Contra qual regra (em qual versão) foi verificado? Qual recomendação o agente emitiu? Quem aprovou ou escalou?

O dashboard torna esse [Audit Trail](/br/governance/) pesquisável e exportável, para auditoria interna, auditores externos ou fiscalizações da ANPD (PT: CNPD) (BR) / CNPD (PT).

### Monitoramento de modelos: qual LLM entrega o quê

Em uma [arquitetura agnóstica de modelos](/br/servicos/infraestrutura/) vários modelos operam em paralelo. O dashboard mostra por modelo: tempos de resposta, consumo de tokens, custos, taxas de erro. Isso permite decisões fundamentadas sobre seleção e roteamento de modelos, baseadas em dados operacionais reais, não em intuição.

### Versões de regras: o que mudou

Agentes operam com base em regras de decisão. Quando uma regra muda, seja por atualização de acordo coletivo conforme a CLT (BR) / Código do Trabalho (PT), seja pela entrada em vigor de um novo acordo de empresa, a rastreabilidade é obrigatória: qual era a regra anterior? Qual é a nova? Desde quando vale? Quem aprovou?

O dashboard exibe as versões de regras como linha do tempo. Cada alteração é atribuída a um responsável e vinculada ao Audit Trail.

<table class="w-full text-left text-sm">
<thead><tr class="border-b border-gosign-border">
<th class="py-2 pr-4 font-semibold">Componente</th>
<th class="py-2 pr-4 font-semibold">Finalidade</th>
<th class="py-2 pr-4 font-semibold">Fonte de dados</th>
</tr></thead>
<tbody>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Log de atividades dos agentes</td><td class="py-2 pr-4">Rastrear cada ação do agente em tempo real</td><td class="py-2 pr-4">Entradas de protocolo do Decision Layer</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Visualizador de Audit Trail</td><td class="py-2 pr-4">Registros de decisão pesquisáveis e exportáveis</td><td class="py-2 pr-4">Registros de auditoria do Decision Layer</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Monitor de modelos</td><td class="py-2 pr-4">Comparar desempenho e custos de LLM</td><td class="py-2 pr-4">Métricas de inferência por modelo</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Linha do tempo de versões de regras</td><td class="py-2 pr-4">Rastrear alterações com responsabilidade atribuída</td><td class="py-2 pr-4">Repositório de regras versionado</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Dashboard de escalação</td><td class="py-2 pr-4">Monitorar taxas de Human-in-the-Loop</td><td class="py-2 pr-4">Eventos de escalação HITL</td></tr>
</tbody>
</table>

## Três visões para três públicos

Um único dashboard, mas com níveis de acesso diferentes conforme o papel.

A visão de TI mostra o desempenho técnico: uptime de agentes, latência de modelos, taxas de erro de API, utilização de recursos. Serve para a gestão operacional e o planejamento de capacidade.

A visão da diretoria mostra indicadores de negócio: casos processados por dia, taxa de automatização, taxa de escalação, tempos de processamento. Serve para avaliação de ROI e reporting para a alta gestão.

A visão do comitê de empresa mostra dados agregados de uso: em quais departamentos os agentes estão implantados? Com que frequência decisões são automatizadas vs. encaminhadas para aprovação humana? Quais alterações de regras foram feitas? Essa visão deliberadamente não contém dados pessoais individualizados. Ela cria transparência sobre o uso de IA como um todo.

Essa divisão tripla não é opcional. É o pré-requisito para que a governança de IA funcione na prática. Sem visão de TI, sem operações estáveis. Sem visão da diretoria, sem orçamento. Sem visão do comitê de empresa, sem [acordo coletivo](/br/governance/co-determination/).


## Dashboard de governança como componente arquitetônico

O dashboard não é uma ferramenta separada adicionada à infraestrutura de IA depois do fato. É uma camada de apresentação que opera diretamente sobre os dados do [Decision Layer](/br/decision-layer/).

Cada entrada do Audit Trail, cada versão de regra, cada métrica de modelo é gerada automaticamente pelo Decision Layer, como subproduto das operações normais, não como esforço adicional. O dashboard torna esses dados acessíveis, filtráveis e exportáveis.

Isso é [Governance by Design](/br/governance/): transparência não surge de relatórios retrospectivos, mas como parte integral da arquitetura.

Na Gosign, construímos [infraestrutura de IA](/br/servicos/infraestrutura/) com camada de governança integrada. O dashboard não é opcional. É parte de cada infraestrutura de agentes que entregamos.

--- IA open-source auto-hospedada 2026: Enterprise ---
> Self-hosting de LLMs open-source em 2026: Mistral, gpt-oss, DeepSeek, Llama 4. Hardware floor, TCO, provedores GPU EU, matriz de decisão por workload.

O mercado de modelos deu para Compras corporativas brasileira uma escolha que ela nunca teve antes. Modelos open-weight igualam modelos proprietários na maioria das cargas enterprise. Três modelos open-source classe frontier foram lançados sob Apache 2.0 só em 2025. Provedores GPU europeus oferecem capacidade H100 a tarifas horárias previsíveis em data centers de Paris e Frankfurt; provedores brasileiros como Locaweb e Equinix São Paulo oferecem GPU hosting com tarifa em reais e residência local. A decisão Schrems II combinada com o US CLOUD Act tornou o self-hosting a única arquitetura com zero exposição a provedor estrangeiro.

Mesmo assim, a conversa em Compras ainda trata "IA open-source self-hosted" como se fosse um único produto. Não é. É uma decisão de stack com quatro modelos sérios, três padrões de deployment e um problema real de cálculo de TCO. Este artigo é o complemento detalhado de [Quando Mistral, quando Claude Opus? Decision Routing para a empresa brasileira 2026](/br/revista/modelos-ia-comparacao-2026/) - se você já decidiu fazer self-hosting, aqui está como a seleção de modelo realmente acontece.

<div class="not-prose my-12 border border-gosign-border bg-gosign-light rounded-card p-6 lg:p-8">
<p class="text-h3 font-bold text-gosign-dark mb-3">Em resumo - IA open-source self-hosted para enterprise brasileira 2026</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Cinco modelos com self-hosting sério em 2026: Mistral Small 3.2 (Apache 2.0, 24B, GPU consumer única), gpt-oss-120b (Apache 2.0, MoE, H100 única), DeepSeek V4-Flash (MIT, 284B/13B active MoE, preview abril 2026), DeepSeek V4-Pro (MIT, 1.6T/49B active, preview, classe cluster), Llama 4 Scout (Meta License, contexto 10M).</li>
<li>Mistral Small 3.2 ganha o posto de workhorse porque roda em hardware consumer (única RTX 4090), tem treinamento multilíngue com boa cobertura de português, e capacidade nativa de vision para cargas documentais.</li>
<li>DeepSeek V4-Pro (preview, 24 de abril de 2026) chega perto da performance frontier-closed-source sob licença MIT, mas precisa de cluster multi-GPU - self-hosting realista começa com V4-Flash para a maioria.</li>
<li>GPU hosting fora dos EUA já não é gargalo: Locaweb e Equinix São Paulo oferecem GPU em data center brasileiro (sem CLOUD Act). Scaleway oferece H100 SXM a ~3,50 EUR/h, OVHcloud tem tier sovereign, Hetzner provê RTX dedicado, IONOS e T-Systems atendem setores regulados.</li>
<li>Ponto de virada de TCO de cloud API para self-hosted: tipicamente em torno de 50-100 milhões de tokens por mês sustentado. Abaixo disso, API EU ou BR vence; acima disso, hardware dedicado se paga em 12-18 meses.</li>
<li>A arquitetura é multi-modelo, não single-modelo: Mistral Small para volume, gpt-oss-120b ou DeepSeek V4-Flash para raciocínio pesado on-prem, V4-Pro ou R1 como especialistas em matemática/lógica, Llama 4 Scout para contexto ultra-longo. O roteamento decide qual modelo cuida de qual decisão.</li>
</ul>
</div>

## Você decidiu fazer self-hosting - a pergunta de modelo começa aqui

A escolha de auto-hospedar um stack LLM raramente é uma decisão de modelo. É uma decisão de compliance: dados classificados acima de um certo nível não podem deixar a rede corporativa - relevante sob LGPD art. 33 quando o controlador brasileiro não quer expor dados pessoais sensíveis a transferência internacional sem garantia explícita. É uma decisão de arquitetura: a camada de inferência precisa ser uma dependência controlada, não uma API externa. É uma decisão de Compras: capex em hardware vs. opex em instâncias GPU hospedadas.

Tomada essa decisão, abre-se a pergunta de modelo. Qual modelo open-source em qual hardware floor para qual mix de carga? Cinco modelos têm production-readiness séria para Q2 2026: Mistral Small 3.2, gpt-oss-120b, DeepSeek V4-Flash, DeepSeek V4-Pro (preview) e Llama 4 Scout. DeepSeek R1 de janeiro de 2025 ainda é production-ready mas em grande medida superado pela linha V4 para deployments novos. Cada modelo tem uma curva custo-qualidade diferente e um perfil operacional diferente.

Este artigo pula a discussão de leaderboard. Pontuações de benchmark convergem o suficiente para que o fit com a carga importe mais que pontos nominais em MMLU ou HumanEval. A pergunta é qual modelo sobrevive 18 meses no seu stack, qual deles paga o próprio hardware e qual combinação produz o audit trail que a LGPD art. 20 e o EU AI Act exigem.

## Os modelos self-hostáveis sérios, lado a lado

| Modelo | Parâmetros / Arquitetura | Licença | Hardware floor (bf16/fp16) | Custos de hospedagem (CAPEX / OPEX) | Força principal | Fraqueza principal |
|---|---|---|---|---|---|---|
| Mistral Small 3.2 | 24B dense, GQA (32Q/8KV) | Apache 2.0 | ~55 GB VRAM (1× H100 80GB ou A100 80GB); RTX 4090 com quant 4-bit | 1× RTX 4090 ~1.500 EUR / 1× H100 ~30k EUR / OPEX ~1.500-2.500 EUR/mês | Multilíngue, vision, rápido (~150 tok/s em GPU consumer), amigável ao volume | Não é raciocínio de topo |
| gpt-oss-120b | 117B total / 5,1B active (MoE) | Apache 2.0 | 1× H100/A100 80GB | ~30k EUR CAPEX / OPEX ~1.200-2.500 EUR/mês | Raciocínio nível o4-mini, inferência MoE eficiente | Sem vision, só hardware grau data center |
| DeepSeek V4-Flash *(preview, Abr 2026)* | 284B total / 13B active (MoE), contexto 1M | MIT | 1-2× H100/A100 80GB com quant; multi-GPU para precisão total | 1-4× H100 ~30-120k EUR CAPEX / OPEX ~1.500-5.000 EUR/mês | Raciocínio classe frontier em hardware moderado, multimodal nativo, otimizado para agent | Status preview - benchmarks precisam ser reverificados antes de produção |
| DeepSeek V4-Pro *(preview, Abr 2026)* | 1,6T total / 49B active (MoE), contexto 1M | MIT | Cluster multi-GPU (mínimo 8× H100); self-hosting realista só para infraestrutura classe hyperscaler | 8× H100 ~240k EUR CAPEX / OPEX ~10-12k EUR/mês | Chega perto de performance GPT-5.5 e Gemini 3.1 Pro sob licença aberta, otimizado para agent-tool (Claude Code, OpenClaw) | Hardware classe hyperscaler para PME - API ou variante hosted é o caminho realista para empresas menores |
| DeepSeek R1 *(Jan 2025, maduro)* | 671B total / 37B active (MoE) | MIT | Multi-GPU: mínimo 4-8× H100 | ~120-240k EUR CAPEX / OPEX ~5-10k EUR/mês | Especialista maduro em matemática/lógica, suporte amplo de framework | Em grande medida superado pela V4-Flash para novos deployments |
| Llama 4 Scout | 17B active (MoE) | Meta Llama Community License | 1× GPU | ~30k EUR CAPEX / OPEX ~1.500 EUR/mês | Janela de contexto de 10 milhões de tokens | Restrição de licença acima de 700M MAU; revisão jurídica necessária |

Três esclarecimentos importam aqui.

**Hardware floor do Mistral Small 3.2.** A orientação oficial Mistral lista ~55 GB de GPU RAM para inferência bf16/fp16, o que coloca o modelo numa H100 ou A100 80GB em produção. Com quantização 4-bit (GPTQ, AWQ), roda em uma única RTX 4090 24 GB com leve perda de qualidade. Para deployments piloto ou inferência single-tenant, o caminho RTX 4090 é real. Para produção multi-tenant com requisições concorrentes, o caminho H100 é o sizing correto.

**Status preview da linha DeepSeek V4.** DeepSeek-V4-Pro e V4-Flash foram lançados em preview no dia 24 de abril de 2026 sob licença MIT, ambos com janela de contexto de 1M tokens via a nova arquitetura Hybrid Attention (Compressed Sparse Attention + Heavily Compressed Attention). Na configuração de contexto 1M-token, V4-Pro reportadamente exige apenas 27% dos FLOPs de inferência single-token e 10% do KV cache em relação ao V3.2 - ganhos significativos para cargas de contexto longo. Ambas as variantes foram otimizadas para tooling de agente (integração Claude Code, OpenClaw). Porém: preview significa que claims de benchmark ainda não foram verificados de forma independente em escala. Para decisões de produção em setores regulados, espere pelo release de general-availability ou rode seus próprios benchmarks representativos antes de comprometer.

**Esclarecimento V4-Pro: licença aberta, fronteira por tamanho de empresa.** DeepSeek V4-Pro é open-source sob licença MIT, com pesos publicados no Hugging Face, igual ao V4-Flash. A questão não é licença - é tamanho de empresa. Para grande empresa B3 (Petrobras, Itaú, Vale, Ambev) e média empresa superior, os ~240.000 EUR de CAPEX (8× H100) ou ~10-12k EUR/mês de hospedagem dedicada são item-orçamento-TI padrão - comparável a um cluster Oracle Exadata ou a uma renovação de licenciamento SAP S/4HANA. Para PME abaixo de 500 funcionários, esse hardware floor é desproporcional, e o caminho realista é V4-Pro via API (DeepSeek API direto) ou via provedor hospedado (Together.ai, Fireworks AI), que oferecem o mesmo modelo MIT em pay-per-token sem CAPEX. A escolha self-hosted vs. API para V4-Pro é, portanto, função do volume de tokens combinado com o tamanho do orçamento TI, não da licença em si.

**Revisão de licença para Llama 4 Scout.** A Meta Llama Community License permite uso comercial mas tem duas restrições que o Jurídico de Compras precisa revisar: um limite de 700 milhões de MAU acima do qual uma licença Meta separada é exigida, e uma restrição contra usar output do modelo para treinar modelos concorrentes. Para a maioria das empresas brasileiras, ambas são irrelevantes na prática, mas a nota deve estar explícita no parecer jurídico.

## TCO: quando self-hosted vence cloud API?

A economia vira em um certo limiar de volume de tokens. Abaixo dele, APIs hosted vencem porque idle time de hardware domina. Acima dele, GPUs dedicadas vencem porque o custo incremental por token se aproxima de eletricidade mais depreciação.

Um cálculo representativo para Mistral Small 3.2 em hosting EU:

| Item de custo | Valor (hosting EU) |
|---|---|
| Instância H100 80GB, provedor EU (classe Scaleway) | ~2.500 EUR/mês dedicada, ou ~3,50 EUR/h on-demand |
| Throughput do Mistral Small 3.2 (H100 única) | ~150 tokens/s sustentado, ~390M tokens/mês a 100% utilização |
| Custo efetivo por 1M tokens a 60% utilização | ~10-12 EUR por 1M tokens |
| Equivalente API Mistral La Plateforme (Mistral Small via API) | ~0,40 USD por 1M tokens input; volume-dependente |
| Equivalente API Claude Sonnet 4.6 | ~3 USD por 1M tokens input; ~15 USD output |
| Equivalente API Claude Opus 4.7 | ~5 USD por 1M tokens input; ~25 USD output |

O ponto de virada para Mistral Small fica entre 50 e 100 milhões de tokens por mês sustentado, dependendo de a carga ser input-heavy ou output-heavy. Um pipeline enterprise 24/7 rodando 5 a 10 worker nodes tipicamente cruza esse limiar no primeiro trimestre.

Para gpt-oss-120b a conta é parecida mas começa mais alta: uma H100 única sustenta throughput menor que Mistral Small no mesmo custo de hardware, então o custo por token amortizado fica em torno de 2× o do Mistral Small. O ponto de virada vs. Claude Opus 4.7 fica em torno de 30-50 milhões de tokens por mês - exatamente a faixa onde cargas heavy-reasoning costumam ficar em sistemas enterprise de IA.

A arquitetura 1,6T/49B-active do DeepSeek V4-Pro é hardware classe hyperscaler. Self-hosting realista começa com V4-Flash (284B/13B active), que cabe em 1-2 H100s com quantização ou 4 H100s em precisão total. O TCO de V4-Flash self-hosted se justifica quando raciocínio classe frontier é carga sustentada em classificações de dado críticas para soberania; para raciocínio ocasional, a API V4-Flash ou Mistral La Plateforme sai mais barata. V4-Pro on-prem é realista apenas para empresas classe hyperscaler (serviços financeiros com infraestrutura grau HFT, grandes clientes governo/defesa). Os demais usam V4-Pro via API ou variante hosted.

Esses números se baseiam em preços públicos de hosting EU da Scaleway e da OVHcloud e em dados públicos de throughput dos modelos. São ilustrativos, não contratuais. Para hosting no Brasil, Locaweb e Equinix São Paulo praticam tarifas em R$ que, mesmo descontada paridade cambial, ficam competitivas para cargas onde residência local é requisito (LGPD art. 33 sem necessidade de cláusulas-padrão de transferência internacional).

<figure class="not-prose my-12">
<svg viewBox="0 0 800 480" xmlns="http://www.w3.org/2000/svg" role="img" aria-labelledby="tco-title-br tco-desc-br" class="w-full h-auto max-w-3xl mx-auto">
<title id="tco-title-br">Ponto de cruzamento TCO: self-hosted vs API cloud por volume mensal de tokens (maio 2026)</title>
<desc id="tco-desc-br">Comparação de custos: gasto mensal USD no eixo Y (escala log 100 a 100.000 USD) versus volume mensal de tokens no eixo X (escala log 1M a 10B tokens). Quatro curvas: Claude Opus 4.7 API a 15 USD por 1M tokens (linear), Mistral La Plateforme API a 0,40 USD por 1M tokens (linear), Mistral Small 3.2 self-host em uma única H100 a ~2.700 USD/mês flat mais eletricidade marginal, gpt-oss-120b self-host em uma única H100 a ~3.200 USD/mês flat. Cruzamentos: Mistral Small 3.2 self-hosted bate Claude Opus 4.7 API em torno de 180 milhões de tokens mensais. Abaixo de 50M tokens/mês domina a economia API cloud. Acima de 500M tokens/mês domina self-host independentemente do modelo.</desc>
<defs><style>
.axis-line-br { stroke: #1a2e4d; stroke-width: 1.5; }
.grid-line-br { stroke: #d4d0cb; stroke-width: 0.5; stroke-dasharray: 2 3; }
.axis-label-br { font-family: -apple-system, system-ui, sans-serif; font-size: 11px; fill: #4a5568; }
.title-text-br { font-family: -apple-system, system-ui, sans-serif; font-size: 13px; fill: #1a2e4d; font-weight: 700; }
.legend-text-br { font-family: -apple-system, system-ui, sans-serif; font-size: 11px; fill: #1a2e4d; font-weight: 500; }
.annotation-br { font-family: -apple-system, system-ui, sans-serif; font-size: 10px; fill: #1a2e4d; font-style: italic; }
.crossover-marker-br { fill: #fcd34d; stroke: #b8941f; stroke-width: 1.5; }
</style></defs>
<text x="400" y="25" class="title-text-br" text-anchor="middle">Custo mensal (USD, escala log)</text>
<line x1="80" y1="380" x2="740" y2="380" class="grid-line-br"/><line x1="80" y1="300" x2="740" y2="300" class="grid-line-br"/><line x1="80" y1="220" x2="740" y2="220" class="grid-line-br"/><line x1="80" y1="140" x2="740" y2="140" class="grid-line-br"/><line x1="80" y1="60" x2="740" y2="60" class="grid-line-br"/>
<line x1="212" y1="60" x2="212" y2="380" class="grid-line-br"/><line x1="344" y1="60" x2="344" y2="380" class="grid-line-br"/><line x1="476" y1="60" x2="476" y2="380" class="grid-line-br"/><line x1="608" y1="60" x2="608" y2="380" class="grid-line-br"/>
<text x="72" y="384" class="axis-label-br" text-anchor="end">$100</text>
<text x="72" y="304" class="axis-label-br" text-anchor="end">$1.000</text>
<text x="72" y="224" class="axis-label-br" text-anchor="end">$10.000</text>
<text x="72" y="144" class="axis-label-br" text-anchor="end">$100.000</text>
<text x="72" y="64" class="axis-label-br" text-anchor="end">$1.000.000</text>
<text x="80" y="400" class="axis-label-br" text-anchor="middle">1M</text><text x="212" y="400" class="axis-label-br" text-anchor="middle">10M</text><text x="344" y="400" class="axis-label-br" text-anchor="middle">100M</text><text x="476" y="400" class="axis-label-br" text-anchor="middle">1B</text><text x="608" y="400" class="axis-label-br" text-anchor="middle">10B</text>
<text x="400" y="420" class="title-text-br" text-anchor="middle">Volume mensal de tokens (escala log)</text>
<line x1="80" y1="60" x2="80" y2="380" class="axis-line-br"/><line x1="80" y1="380" x2="740" y2="380" class="axis-line-br"/>
<polyline points="80,420 212,366 344,286 476,206 608,126" fill="none" stroke="#b8941f" stroke-width="2.5"/>
<text x="615" y="120" class="legend-text-br" fill="#b8941f">Claude Opus 4.7 API</text>
<text x="615" y="132" class="annotation-br" fill="#b8941f">$15 por 1M tokens</text>
<polyline points="80,572 212,508 344,412 476,332 608,252" fill="none" stroke="#3a6090" stroke-width="2.5" stroke-dasharray="4 3"/>
<text x="615" y="246" class="legend-text-br" fill="#3a6090">Mistral La Plateforme API</text>
<text x="615" y="258" class="annotation-br" fill="#3a6090">$0,40 por 1M tokens</text>
<polyline points="80,266 740,266" fill="none" stroke="#1a2e4d" stroke-width="2.5"/>
<text x="86" y="258" class="legend-text-br" fill="#1a2e4d">Mistral Small 3.2 self-host (~$2.700/mês flat)</text>
<polyline points="80,256 740,256" fill="none" stroke="#5a8a5a" stroke-width="2.5" stroke-dasharray="6 4"/>
<text x="86" y="248" class="legend-text-br" fill="#5a8a5a">gpt-oss-120b self-host (~$3.200/mês flat)</text>
<circle cx="377" cy="266" r="6" class="crossover-marker-br"/>
<text x="377" y="248" class="annotation-br" text-anchor="middle">Cruzamento ~180M tok/mês</text>
<text x="377" y="284" class="annotation-br" text-anchor="middle">Mistral OSS vs Opus API</text>
<text x="400" y="455" class="annotation-br" text-anchor="middle">Hosting: provedores GPU UE (Scaleway, OVHcloud) - valores ilustrativos, não contratuais</text>
</svg>
<figcaption class="text-sm text-gosign-text-light text-center mt-4 max-w-2xl mx-auto">
<strong>Ponto de cruzamento TCO: self-hosted vs API cloud</strong> - curvas lineares de API cloud (pricing por token) versus curvas planas de self-host (CAPEX amortizado). Mistral La Plateforme API permanece a opção mais barata abaixo de ~10B tokens/mês - a decisão relevante é Mistral OSS self-host vs Claude Opus 4.7 API, que cruza para cargas críticas de soberania em torno de 180 milhões de tokens mensais. Abaixo de 50M tokens/mês domina a economia cloud-API. Acima de 500M tokens/mês domina self-host independentemente.
</figcaption>
</figure>

## GPU hosting em 2026: quem realmente tem capacidade H100

O mercado europeu de GPU hosting amadureceu de forma significativa em 2025-2026. Três provedores cobrem a maior parte dos casos enterprise de self-hosting:

**Scaleway** (França, GDPR-native). O mais agressivo em custo-benefício para cargas IA. H100 SXM a ~3,50 EUR/h, A100 a ~2,50 EUR/h, mais o NVIDIA Blackwell B300-SXM (288 GB VRAM) para cargas de fronteira. Data centers franceses, GDPR completo, zero exposição a CLOUD Act. Contratos de instância reservada disponíveis para cargas previsíveis.

**OVHcloud** (França, tier sovereign). O maior provedor cloud europeu, com um tier "Sovereign Cloud" construído explicitamente para uso governo e setores regulados. Portfólio inclui H100, RTX 5000, A10, mais um serviço "AI Deploy" para notebook e inferência pay-as-you-go. Bom fit quando Compras exige assinatura sovereign-cloud.

**Hetzner** (Alemanha). Líder de custo em servidores GPU dedicados, não em instâncias on-demand. Opções atuais incluem RTX 4000 SFF Ada e RTX 6000 Ada acopladas a CPUs modernas. Caminho para Mistral Small 3.2 com quantização ou para ambientes de desenvolvimento. Menos adequado para peak elastic scaling.

Para setores regulados (serviços financeiros, saúde, setor público) com exigências estritas de soberania:

**IONOS** (Alemanha). Hosting grau sovereign-cloud com instâncias GPU. Fit de compliance para cargas regulamentadas por BaFin alemã.

**T-Systems** (Alemanha). Subsidiária Deutsche Telekom. Sovereign cloud projetado explicitamente para setor público e infraestrutura crítica. A escolha confortável de Compras quando a soberania nível board é o requisito.

Para fintechs e instituições financeiras sob BACEN, a sequência de avaliação muda: Resolução 4.658/2018 (Política de Cibersegurança) + Resolução 4.893/2021 (Cibernética em Arranjos de Pagamento) + Circular 3.909 sobre infraestrutura crítica em território nacional aplicam-se. CMN Resolução 4.893 art. 11-14 sobre contratação de serviços relevantes de TI obriga: cláusula de auditoria BACEN no contrato, direito de exigir dados, plano de saída em contrato de fornecedor. Open Finance Brasil Fase 4 ativa desde 2024 exige Decision Records para classificação automatizada de transações - exatamente o tipo de artefato que uma camada de roteamento self-hosted produz. Para fintech, a posição defensável combina: provedor sob jurisdição brasileira pura (Locaweb, Equinix SP, colocation próprio) + Decision Layer com Decision Records imutáveis + contratos com cláusulas BACEN explícitas.

Para empresas brasileiras que não querem transferência internacional sob LGPD art. 33:

**Locaweb** (Brasil). GPU hosting em data center brasileiro com tarifa em R$. Sem exposição a CLOUD Act, sem cláusulas-padrão de transferência internacional. Capacidade limitada comparada a Scaleway, mas resolve o requisito de residência local.

**Equinix São Paulo / Ascenty** (Brasil). Data centers brasileiros que hospedam servidores GPU dedicados de clientes (modelo colocation). Caminho para empresas que querem ownership total do hardware sob jurisdição brasileira.

**AWS Brazil South / Azure Brazil South** (atenção - questão central para fintech sob BACEN). A região é Brasil, mas Amazon Web Services Brasil Ltda é controlada pela Amazon.com Inc (US), e Microsoft Brasil é controlada pela Microsoft Corp (US). CLOUD Act aplica-se. BACEN Resolução 4.893 art. 11 fala de "infraestrutura crítica em território nacional" para alguns serviços - AWS Brazil pode ou não atender dependendo de cláusulas contratuais reforçadas. Para fintech, Auditoria BACEN exige clarificação prévia: controlador legal sob LGPD art. 33 quando a contratante é AWS Brasil mas casa-mãe é Inc.? Para dados pessoais sensíveis ou para tratamento sob regime BACEN, a posição defensável de Compras é: hyperscaler em região BR exige cláusulas contratuais reforçadas (residência ponta a ponta, vedação de acesso pela matriz, plano de saída em contrato) ou substituição por provedor nacional puro. Não basta o data center ficar em São Paulo - o controlador legal precisa ser entidade sob jurisdição brasileira.

**SERPRO (SerproCloud) e Dataprev** (estatais brasileiras, obrigatórias para setor público). Para empresas controladas pela União ou para órgãos federais, SERPRO e Dataprev são opções soberanas obrigatórias antes de hyperscaler para dados classificados sob Lei 12.527/2011 e Decreto 7.845/2012. TCU jurisprudência (Acórdão 1.739/2015, 2.952/2018, 1.388/2022) consolidou a exigência de avaliação prévia de alternativa soberana antes de contratação de cloud público estrangeiro. Decreto 11.856/2023 (EBIA - Estratégia Brasileira de IA) reforça a governança. Para estatais energia sob ANEEL Resolução 956/2021 (PCN + PRI + reporte de incidente em 72h), a sequência prática é: SERPRO/Dataprev primeiro, T-Systems/IONOS sovereign como alternativa multinacional, hyperscaler em região BR só com cláusulas reforçadas e parecer jurídico explícito sob Lei 14.133/2021.

Para uma empresa brasileira decidindo um stack self-hosted, a sequência prática é: piloto em Scaleway, Hetzner ou Locaweb para validação custo-eficiente, mudança para OVHcloud/T-Systems (se multinacional EU) ou Locaweb/Equinix SP (se brasileira pura) para produção quando a assinatura regulatória exigir certificação sovereign-cloud, manter contratos de instância reservada para controlar a previsibilidade de custo.

## Padrões de deployment: single worker, cluster, híbrido

Três padrões de deployment cobrem quase todos os cenários enterprise self-hosted.

**Padrão single-worker.** Um modelo, uma instância GPU, deployed atrás de um load balancer com health checks. Adequado para: Mistral Small 3.2 em RTX 4090 ou H100 para a carga de 70% de volume. Llama 4 Scout em GPU única para análise documental de contexto longo. Complexidade operacional: baixa. Failure mode: single point of failure se não replicado.

**Padrão cluster multi-modelo.** Múltiplos modelos em múltiplas GPUs atrás de uma camada de roteamento. Adequado para: Mistral Small para volume + gpt-oss-120b ou DeepSeek V4-Flash para raciocínio pesado + (opcional) DeepSeek V4-Pro em cluster dedicado para cargas grau matemática, tudo atrás de uma única camada de roteamento. A camada de roteamento decide por requisição qual modelo cuida dela. Complexidade operacional: média. Exige um model server (vLLM, TGI, llama.cpp-server) e um engine de regras de roteamento. Esse é o padrão típico de produção para cargas agênticas com complexidade de decisão mista.

**Padrão híbrido edge-cloud.** Cargas sensíveis (admissão CLT, revisão de contrato, extração de dados de cliente) em modelos self-hosted; cargas não sensíveis (geração de copy de marketing, FAQ sobre informação pública) em APIs cloud EU como Mistral La Plateforme. A camada de roteamento aplica a classificação de dado antes da seleção de modelo. Complexidade operacional: alta (dois stacks para manter) mas menor exposição de soberania e melhor relação custo-por-decisão.

A escolha de padrão depende da taxonomia de classificação de dado, não da seleção de modelo. Se tudo é classificado como "interno" ou superior, o padrão cluster multi-modelo domina. Se uma fatia relevante do trabalho está em dado público ou não sensível, o padrão híbrido sai mais barato.

## Matriz de decisão: qual modelo para qual carga

| Categoria de carga | Modelo recomendado | Por quê |
|---|---|---|
| Classificação documental, extração estruturada, parsing de campo corrigido por OCR | Mistral Small 3.2 (self-hosted) | Com vision, rápido em GPU consumer, cobertura multilíngue (PT-BR sólida) |
| Geração de texto padrão (e-mails, notificações, lembretes de NDA) | Mistral Small 3.2 (self-hosted) | Throughput alto, amigável a template |
| Classificação de cláusula contratual, flags de risco de fornecedor, detecção de anomalia | Mistral Small 3.2 ou Mistral Medium 3.1 (La Plateforme) | Raciocínio médio a custo baixo |
| Análise de equidade salarial sob Lei 14.611/2023, raciocínio cross-statute complexo | gpt-oss-120b on-prem (ou Claude Opus 4.7 cloud) | Raciocínio nível o4-mini com licença Apache 2.0 |
| Modelagem de risco financeiro, stress testing, problemas de otimização | DeepSeek V4-Flash (atual) ou V4-Pro via API/hosted (se hardware permitir); R1 ainda viável para deployments maduros | Liderança em benchmarks matemática/lógica, linha V4 adiciona contexto 1M para análise cross-portfólio |
| Análise documental de grandes corpos (portfólios contratuais inteiros, relatórios anuais completos) | Llama 4 Scout | Janela de contexto de 10M tokens |
| Multimodal (correlação imagem + texto, revisão de desenho técnico) | Gemini 3.1 Pro (cloud apenas - nenhum equivalente self-hosted alcança) | Treinamento multimodal nativo |
| Geração de código, code review (cloud flagships) | Claude Opus 4.7 ou GPT-5.5 | Ambos líderes em benchmarks de código; Claude Opus 4.7 mais forte em loops agênticos longos (Claude Code), GPT-5.5 mais forte em integração IDE (Cursor, Copilot) |
| Geração de código, code review (self-hosted) | Qwen 3 Coder 110B (Apache 2.0, Alibaba), DeepSeek Coder V4 (MIT), ou Codestral Mamba 32B (Mistral, EU-built) | Top-tier coding benchmarks on-prem; Qwen 3 Coder líder HumanEval/SWE-Bench entre OSS, DeepSeek Coder V4 mais forte em agentic Multi-File-Tasks, Codestral Mamba latência mais baixa em GPU consumer |
| Stack Microsoft 365 / Azure-nativo | GPT-5.5 via Azure OpenAI | Stack nativo, menor esforço de integração para organizações no Microsoft data plane |
| Workflows agênticos (orquestração de tools, outputs estruturados) | GPT-5.5 ou Claude Opus 4.7 | Ambos top-tier em outputs estruturados e orquestração de tools; GPT-5.5 com ecossistema mais amplo de pre-built tools |
| SaaS feature gating (free vs. premium tiers) | Padrão híbrido: Mistral Small + Claude Opus 4.7 / GPT-5.5 | Dados sensíveis de cliente self-hosted, premium features em cloud flagship |
| IA conversacional / chatbots voltados ao cliente | Mistral Small 3.2 (self-hosted) para volume; GPT-5.5 (Azure) quando stack MS-nativo | Qualidade grade produção no menor custo de hardware; Azure quando integração nativa pesa mais que soberania |

A matriz não é prescrição. É ponto de partida que se refina por organização. Uma empresa brasileira heavy em financeiro pondera DeepSeek V4 para cima. Uma operação heavy em multimídia pode precisar de hop para Gemini cloud. Um pipeline de RH com alto volume documental coloca Mistral Small em 80% das decisões, não 70%.

A camada de roteamento torna a matriz operacional. Sem ela, toda carga roda contra o modelo configurado como default, e a matriz vira artefato de slideware.

## Construindo a camada de roteamento: onde a Decision Layer encaixa

Arquiteturas self-hosted multi-modelo desmoronam sem camada de roteamento por uma razão simples: nenhum operador humano quer lembrar de 14 mappings decisão-para-modelo enquanto também escreve a lógica de negócio do agente. O roteamento tem que ser configuração, não código.

Uma Decision Layer guarda:

- A taxonomia de classificação de dado (quais tipos exigem self-hosted? Quais podem ir para API cloud EU? Quais podem ir para API cloud BR? Quais para API cloud US?)
- As regras de roteamento decisão-para-modelo por etapa de workflow
- A cadeia de fallback (se Mistral Small falhar ou saturar, roteia para qual alternativa?)
- O log de auditoria: cada decisão registrada com snapshot de input, versão da regra, modelo usado, score de confiança, cadeia de raciocínio, resultado e aprovador humano onde aplicável
- O botão de contestação: qualquer titular afetado pode contestar uma decisão automatizada, disparando re-decisão sob revisão (que pode ser humana ou por outro sistema automatizado, conforme Lei 13.853/2019 que alterou o art. 20 §3º da LGPD) - com transparência sobre os critérios

Esse é o artefato que um auditor EU AI Act Article 13 inspeciona. É o artefato que a ANPD analisa numa fiscalização sob LGPD art. 20. É a base do RIPD (Relatório de Impacto à Proteção de Dados sob Resolução CD/ANPD 18/2024) que o Encarregado de Dados precisa manter para tratamento de risco aumentado. É o artefato que o representante do Sindicato avalia quando precisa classificar quais agentes entram em escopo de negociação coletiva (e a referência contratual é o ACT da empresa se houver, prevalecendo sobre a CCT da categoria por CLT art. 620). E é o artefato que satisfaz a pergunta de Compras "o que acontece quando seu vendor de IA muda de modelo?" - porque a regra de roteamento muda, não a lógica de negócio.

Construir essa camada in-house é factível mas raramente mais rápido que 6-9 meses para um time enterprise começando do zero. Comprar como framework de configuração tipicamente encurta o caminho para 4-6 semanas até o primeiro agent em produção.

## Conclusão

IA open-source self-hosted é uma escolha de produção séria para a empresa brasileira em 2026 - mas só como arquitetura multi-modelo com camada de roteamento, não como aposta em modelo único. Mistral Small 3.2 cobre a faixa de volume. gpt-oss-120b ou DeepSeek V4-Flash cobrem raciocínio pesado on-prem. DeepSeek V4-Pro (atualmente em preview) chega no território Claude Opus se você tem hardware classe hyperscaler - ou você espera o release GA e usa via API enquanto isso. Llama 4 Scout cobre contexto ultra-longo. O tier cloud-API (Claude Opus 4.7, GPT-5.5, Gemini 3.1 Pro) fica disponível para cargas em que o marco regulatório permite.

A decisão de roteamento é a arquitetura. O ponto de virada de TCO (em torno de 50-100 milhões de tokens por mês sustentado) define o limiar econômico do self-hosting. A taxonomia de compliance (qual classificação de dado não pode deixar a rede sob LGPD art. 33) define o limiar de soberania. Os dois limiares moldam as regras de roteamento.

Outros publicam leaderboards. A gente constrói a camada de roteamento que operacionaliza esses leaderboards. O mercado de modelos muda mês a mês; a arquitetura de roteamento sobrevive a cinco gerações de modelo. O código-fonte fica com o cliente. Os modelos permanecem intercambiáveis. Conformidade com LGPD art. 20 e EU AI Act Art. 13 é propriedade da arquitetura, não projeto no fim.

Se você quer saber como deveria ser seu stack self-hosted com base no mix de carga real e na sua classificação de dado, [agende uma conversa](/br/contato/).

--- Enterprise AI-Infraestrutura Blueprint 2026 ---
> Oito decisões estrategicas para sua infraestrutura de IA. Modelos, hosting, interfaces, agentes, orquestração, governance, custos, regulação.

## Por que este Blueprint

A integração de IA em processos empresariais deixou de ser projeto de inovação e se tornou necessidade operacional. Quem em 2026 não tem um plano concreto não esta apenas ficando para tras da concorrência: esta saindo do mercado. Ao mesmo tempo, o cenario de decisões ficou mais complexo: mais modelos, mais opções de hosting, mais regulação, mais plataformas de orquestração.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Resumo - Infraestrutura AI Enterprise 2026</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Oito decisões estratégicas que todo CTO ou CIO precisa tomar em 90 dias para implantar IA em escala enterprise.</li>
<li>Seleção de modelo, nível de hosting, portal AI, RAG, agentes, Decision Layer, compliance e orquestração formam o stack completo.</li>
<li>A arquitetura híbrida de hosting - roteamento por sensibilidade de dados entre cloud, IaaS europeu e on-premises - se tornou o padrão.</li>
<li>IDC (2025) projeta gastos mundiais em infraestrutura de IA de 154 bilhões de USD até 2027, ante 76 bilhões em 2024.</li>
<li>Um plano de ação concreto de 90 dias transforma projetos-piloto em infraestrutura produtiva com governance integrada desde o início.</li>
</ul>
</div>

Este Blueprint reduz essa complexidade a oito decisões concretas que todo lider técnico precisa tomar nos próximos 90 dias.

Cada uma dessas decisões e tratada em detalhes em um artigo dedicado, com tabelas comparativas, arvores de decisão e recomendações práticas. Sem marketing, sem buzzwords. Fatos, arquitetura, orientações de ação.

## As oito decisões

### Decisão 1: Qual modelo de IA se encaixa no seu caso de uso?

O cenario de modelos mudou fundamentalmente desde 2024. Claude, GPT-5, Gemini 3, Llama 4, gpt-oss, DeepSeek: as diferencas não estao mais na qualidade, mas na especialização, na proteção de dados e na estrutura de custos. A resposta certa não e um modelo, mas uma arquitetura model-agnostic que roteia cada tarefa para o modelo mais adequado.

**[Leia: Modelos de IA 2026 - Qual modelo para qual uso?](/br/revista/modelos-ia-comparacao-2026/)**

### Decisão 2: Onde seus modelos de IA são executados?

EU-SaaS, data center europeu ou Self-Hosted: essa decisão determina suas garantias de proteção de dados, sua estrutura de custos e sua dependência de fornecedores externos. A estratégia hibrida, na qual uma camada de roteamento distribui automaticamente as solicitações conforme a sensibilidade dos dados, se consolidou como padrão.

**[Leia: Hosting de IA - EU-SaaS, data center na UE ou Self-Hosted?](/br/revista/hosting-ia-estrategias-enterprise/)**

Com a decisão de hosting tomada, seguem as garantias contratuais. Um contrato padrão de operador não é suficiente para infraestrutura de IA - [nosso checklist de requisitos](/br/revista/contrato-dpo-ia-checklist/) identifica as dez lacunas e fornece 25 perguntas de verificação para jurídico e compliance.

### Decisão 3: Como disponibilizar IA para todos os colaboradores sem perder o controle?

Um modelo de linguagem sem interface controlada e como um servidor sem frontend. Os colaboradores recorrem entao a serviços publicos de IA, sem controle, sem registro, sem conformidade com a LGPD (PT: RGPD). Um Enterprise AI Portal oferece a melhor alternativa: Multi-Model-Routing, compartilhamento de assistentes, integração de agentes, SSO e Audit Trail completo.

> **Artigo 3: Enterprise AI Portais** - Cinco interfaces open-source em comparação: LobeChat, OpenWebUI, LibreChat, chatbot-ui e very-ai. Qual portal tem SSO, proteção PII e Audit Trail? (Nota de transparencia: very-ai e desenvolvido pela Gosign.)

**[Leia: Enterprise AI Portais - Cinco interfaces open-source em comparação](/br/revista/enterprise-ai-chat-interface/)**

### Decisão 4: Como tornar o conhecimento corporativo acessivel para IA?

RAG (Retrieval Augmented Generation) permite pesquisar seus documentos sem enviar dados aos provedores de modelos. Document Intelligence vai alem: anonimizacao PII, mascaramento de contratos, verificação automática de compliance.

**[Leia: RAG e Document Intelligence - Como a IA entende seus documentos](/br/revista/rag-document-intelligence-enterprise/)**

### Decisão 5: Como transformar chatbots em agentes reais?

A transição de um chat para processos autônomos que processam documentos, operam sistemas e preparam decisões exige uma arquitetura diferente. Protocolos MCP e A2A, sistemas multi-agentes e requisitos claros de governance determinam o sucesso.

**[Leia: De chatbots a AI-agentes - MCP, A2A e sistemas multi-agentes](/br/revista/agentes-ia-enterprise-guia/)**

### Decisão 6: Como separar análise de decisão?

O Decision Layer decompoe processos de negocio em micro-decisões e define para cada uma: humano, motor de regras ou IA. E a arquitetura que convence a representação dos trabalhadores (sindicatos/CRE; PT: Comissão de Trabalhadores), satisfaz auditores e possibilita o escalonamento.

**[Leia: Decision Layer e Shadow AI - controle em vez de perda de controle](/br/revista/decision-layer-shadow-ai/)**

### Decisão 7: O que exige o EU AI Act - agora, não depois?

Desde fevereiro de 2025, as primeiras proibições e a obrigação de AI-Literacy estao em vigor. Pela legislação vigente, as obrigações de alto risco serao aplicadas a partir de 2 de agosto de 2026 - prazo que, após o acordo provisório do Digital Omnibus de 7 de maio de 2026, deve ser adiado para 2 de dezembro de 2027 (adoção formal ainda pendente, em junho de 2026). A classificação de alto risco permanece, entao vale usar a janela ate o novo prazo para preparar a infraestrutura; quem ignora as obrigações arrisca multas de até 35 milhoes de euros ou 7% do faturamento anual. Para empresas brasileiras, o EU AI Act não se aplica diretamente, mas impacta quem opera na UE ou tem clientes europeus. Em Portugal, as regras se aplicam integralmente.

**[Leia: EU AI Act 2026 - O que vale, o que vem, o que você precisa fazer](/br/revista/eu-ai-act-2026-empresas/)**

### Decisão 8: Em qual plataforma você orquestra seus agentes?

n8n para prototipos rápidos, Camunda para processos que exigem compliance, Temporal para workflows complexos de longa duracao: a plataforma de orquestração determina se sua arquitetura de agentes escala ou fica presa no PoC.

**[Leia: Orquestracao de agentes - n8n, Camunda e alternativas](/br/revista/orquestracao-agentes-plataformas/)**

## As oito decisões em visão geral

<table>
<thead>
<tr><th>Decisão</th><th>Tema</th><th>Pergunta-chave</th></tr>
</thead>
<tbody>
<tr><td>1</td><td>Seleção de modelo IA</td><td>Qual modelo para qual tarefa? Routing model-agnostic.</td></tr>
<tr><td>2</td><td>Estratégia de hosting</td><td>EU SaaS, data center europeu ou Self-Hosted?</td></tr>
<tr><td>3</td><td>Enterprise AI Portal</td><td>Interface controlada com SSO, Audit Trail, proteção PII.</td></tr>
<tr><td>4</td><td>RAG & Document Intelligence</td><td>Como tornar o conhecimento corporativo acessível para IA?</td></tr>
<tr><td>5</td><td>AI Agents</td><td>De chatbot a agente autônomo multi-etapa.</td></tr>
<tr><td>6</td><td>Decision Layer</td><td>Separar análise IA de decisões de negócio.</td></tr>
<tr><td>7</td><td>Custos e EU AI Act</td><td>TCO e obrigações regulatórias desde agosto 2025.</td></tr>
<tr><td>8</td><td>Orquestração de agentes</td><td>n8n, Camunda ou Temporal para workflows produtivos.</td></tr>
</tbody>
</table>

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">eBook gratuito: Infraestrutura de IA</p>
<p class="text-body text-gosign-text mb-4">Build, Buy, Hybrid - infraestrutura em conformidade regulatória com B/B/H-Framework e 7-Layer Reference Architecture.</p>
<a href="/br/ebook/ia-infraestrutura-manual-governanca/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Baixar grátis</a>
</div>

## Para quem este Blueprint foi escrito

Este Blueprint e voltado para decisores técnicos em empresas com mais de 500 colaboradores:

- **CTOs e VP Engineering**, que precisam construir ou consolidar uma arquitetura de IA
- **CIOs**, que devem alinhar a estratégia de IA com a governance de TI e o ecossistema tecnologico existente
- **Diretores de RH e COOs**, que integram IA em processos operacionais - do processamento de documentos a gestão do conhecimento
- **Executivos C-Level com perfil técnico**, que querem tomar decisões embasadas em vez de colecionar projetos-piloto

O Blueprint assume que você já passou da fase de experimentação. A questao não e mais se implantar IA, mas como - com qual arquitetura, qual [governance](/br/governance/) e qual estratégia operacional.

## Plano de ação de 90 dias

O Blueprint culmina em um plano de ação concreto com tres fases:

### Fase 1: Fundacao (Semanas 1--4)

- Criar inventário de sistemas de IA (o que já está em uso?)
- Realizar classificação de dados
- Identificar um caso de uso (maior ROI com menor risco)
- Tomar a decisão de hosting (nivel 1, 2 ou 3)
- Implantar portal AI interno (LobeChat, OpenWebUI, very-ai ou LibreChat)

A camada de apresentação - o Enterprise AI Portal - tem cinco opções open-source em 2026. Gosign desenvolveu o very-ai, portal que adiciona proteção PII e sincronizacao de grupos Entra ID como funcionalidades enterprise (-> Artigo 3). Como em todas as recomendações desta serie: avalie varias opções para o seu contexto específico.

Resultado: seus colaboradores tem uma ferramenta de IA controlada em vez de Shadow AI.

### Fase 2: Primeiro agente (Semanas 5--8)

- Implementar o caso de uso como agente
- Conectar via MCP a 1--2 sistemas existentes
- Definir regras de decisão
- Estabelecer Human-in-the-Loop para etapas críticas
- Definir grupo-piloto de 10--20 usuarios

Resultado: um agente funcional que melhora um processo de negocio real.

### Fase 3: Governance e escalonamento (Semanas 9--12)

- Validar Audit Trail e logging
- Iniciar documentação do EU AI Act (avaliação de riscos, documentação técnica)
- Medir resultados do piloto (economia de tempo, taxa de erros, satisfacao do usuario)
- Criar plano de escalonamento: quais 3--5 casos de uso são os próximos?

Resultado: business case validado e caminho claro para escalonamento.

O plano e deliberadamente compacto. Em 90 dias você não alcancara uma transformação completa de IA, mas tera infraestrutura produtiva, um agente em funcionamento e as bases de governance para escalar com segurança.

---

**Saiba mais:** [Infraestrutura de IA - visao geral de serviços](/br/servicos/infraestrutura/) | [Decision Layer - explicação](/br/decision-layer/) | [AI Agents](/br/servicos/ai-agents/)

---

**Enterprise AI-Infraestrutura Blueprint 2026 - Serie de artigos**

| Anterior | Visao geral | Próximo |
|:---|:---:|---:|
| - | Você esta na visao geral | [Modelos de IA 2026: Qual modelo para qual uso?](/br/revista/modelos-ia-comparacao-2026/) |

*Todos os artigos desta serie: [Enterprise AI-Infraestrutura Blueprint 2026](/br/revista/infraestrutura-ia-blueprint-2026/)*

---

**Prefere não tomar essas oito decisões sozinho?** Gosign acompanha clientes enterprise da arquitetura a operação produtiva - model-agnostic, independente de fornecedores, com acesso completo ao código-fonte.

<a href="/br/contato/" target="_blank" rel="noopener noreferrer">Agendar consultoria</a>. 30 minutos para analisar suas necessidades concretas.

--- Infraestrutura de IA, não sensação de ferramenta ---
> A diferença entre ferramentas de IA (ChatGPT, CoPilot) e infraestrutura de IA: orquestração, governance, modelo agnóstico, Audit Trail.

## Ferramenta vs. infraestrutura

ChatGPT, Microsoft CoPilot, Google Gemini - são ferramentas de IA. Você faz uma pergunta, recebe uma resposta. Para produtividade individual, funciona. Para processos enterprise, não.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Resumo - Infraestrutura IA vs. hype de ferramentas</p>
<ul class="text-body text-gosign-text space-y-2">
<li>ChatGPT, CoPilot e Gemini são ferramentas de IA - não infraestrutura enterprise. Faltam Audit Trail, isolamento por cliente e integração sistêmica.</li>
<li>A infraestrutura IA enterprise é composta por sete camadas: Presentation, Orchestration, Agent, Decision, Model, Integration e Infrastructure.</li>
<li>Gartner (2024) reporta que mais de 55% das organizações que implantaram ferramentas de IA sem governance tiveram que reconstruir sua abordagem em 18 meses.</li>
<li>Uma arquitetura model-agnostic previne vendor lock-in e mantém os modelos substituíveis - Claude, GPT, Gemini, Llama, Mistral.</li>
<li>Após 12 a 18 meses, o cliente opera a infraestrutura de forma autônoma com acesso completo ao código-fonte e sem dependência recorrente do provedor.</li>
</ul>
</div>

A diferença entre uma ferramenta de IA e infraestrutura de IA é comparável à diferença entre uma planilha de Excel e um sistema ERP. A planilha resolve um problema concreto para um único usuário. O sistema ERP é a infraestrutura sobre a qual rodam os processos de negócio de toda a empresa.

Infraestrutura de IA é a camada arquitetônica entre modelo de linguagem e sistema enterprise. Abrange: hosting de modelos, orquestração, Decision Layer, governance, integração em sistemas existentes. O modelo de linguagem é um componente dessa infraestrutura - não a infraestrutura em si.

## O que falta em uma ferramenta de IA

Quando uma empresa usa ChatGPT para processamento de documentos, falta:

**Audit Trail:** Nenhuma documentação de qual decisão foi tomada com qual base. Em uma auditoria, nada é rastreável.

**Conjuntos de regras versionados:** ChatGPT não conhece regras contábeis específicas do cliente na versão 4.2. Tem conhecimento geral sobre contabilidade - mas não os conjuntos de regras concretos do cliente.

**Isolamento por cliente:** Dados de todos os clientes fluem para o mesmo sistema. Sem Row-Level Security, sem separação de workspaces.

**Integração:** ChatGPT não consegue criar um lançamento no SAP, acionar um workflow no [Trigger.dev](https://trigger.dev/) ou disparar uma escalação para um analista. No contexto brasileiro, não se integra com TOTVS, sistemas SPED ou plataformas de folha de pagamento.

**Human-in-the-Loop:** Nenhuma revisão humana imposta pela arquitetura. Nenhuma regra de escalação. Nenhum limiar de confiança.

**Modelo agnóstico:** Quem constrói sobre ChatGPT está vinculado à OpenAI. Se a OpenAI aumentar preços, alterar a API ou descontinuar o serviço, a empresa fica sem alternativa.

## As sete camadas da infraestrutura de IA enterprise

A [arquitetura de referência Gosign](/br/servicos/infraestrutura/) descreve sete camadas:

**Presentation Layer:** Interface de chat, dashboard, Auditor Portal, REST API. A interface entre sistema e usuário.

**Orchestration Layer:** Workflow engine (Trigger.dev ou [Camunda](https://camunda.com/)), API gateway, gerenciamento de filas. Coordena o fluxo de dados entre todos os componentes.

**Agent Layer:** Os agentes especializados - Document Agents, Workflow Agents, Knowledge Agents. Cada agente tem um escopo de atuação definido.

**Decision Layer:** Decompõe cada processo em etapas de decisão. Para cada etapa define: humano, conjunto de regras ou IA. Contém Rules Engine (conjuntos de regras versionados), Confidence Routing (avaliação automática de risco), Human-in-the-Loop (imposto tecnicamente) e Audit Trail (protocolo de decisão imutável).

**Model Layer:** Os modelos de linguagem. Substituíveis, modelo-agnósticos. Claude, ChatGPT, Gemini, Llama, Mistral, DeepSeek, gpt-oss.

**Integration Layer:** A conexão com sistemas existentes. SAP, TOTVS, [Workday](https://www.workday.com/), [SuccessFactors](https://www.sap.com/products/hcm.html), SharePoint. No contexto brasileiro, integração com sistemas SPED e plataformas de e-Social.

**Infrastructure Layer:** O deployment. Azure, GCP, self-hosted, híbrido.

A camada de governance se estende transversalmente por todas as sete camadas.

## Ferramenta IA vs. infraestrutura IA

<table>
<thead>
<tr><th>Capacidade</th><th>Ferramenta IA (ChatGPT)</th><th>Infraestrutura IA</th></tr>
</thead>
<tbody>
<tr><td>Audit Trail</td><td>Não</td><td>Protocolo de decisão imutável</td></tr>
<tr><td>Isolamento por cliente</td><td>Não</td><td>Row-Level Security, separação de workspaces</td></tr>
<tr><td>Integração ERP</td><td>Não</td><td>SAP, TOTVS, Workday via APIs</td></tr>
<tr><td>Regras versionadas</td><td>Não</td><td>Específicas por cliente, versionadas</td></tr>
<tr><td>Human-in-the-Loop</td><td>Não</td><td>Imposto pela arquitetura</td></tr>
<tr><td>Independência de modelo</td><td>Vinculado a um provedor</td><td>Routing model-agnostic</td></tr>
<tr><td>Camada de governance</td><td>Não disponível</td><td>Transversal a todas as camadas</td></tr>
</tbody>
</table>

## A vantagem da infraestrutura

Com uma infraestrutura de IA própria, a empresa ganha:

**Controle:** Dados permanecem na própria infraestrutura. Modelos são substituíveis. Acesso completo aos conjuntos de regras e configurações.

**Escalabilidade:** Um agente para um processo é um PoC. A infraestrutura permite fazer deploy de mais agentes para mais processos - com a mesma governance.

**Independência:** Após 12 a 18 meses, o cliente opera a infraestrutura de forma autônoma. Acesso completo ao código-fonte, todos os prompts e conjuntos de regras. Sem vendor lock-in.

Mais informações: [Infraestrutura de IA - Blueprint 2026](/br/revista/infraestrutura-ia-blueprint-2026/) | [Decision Layer explicado](/br/revista/decision-layer-explicado/)

<a href="/br/contato/" target="_blank" rel="noopener noreferrer">Agendar reunião</a> - Mostramos como uma infraestrutura de IA para sua empresa se parece.

--- Integrar infraestrutura IA ao panorama de TI existente ---
> Como agentes IA e LLMs se integram a ambientes SAP, Workday e cloud sem greenfield, sem Shadow IT, sem migração de plataforma.

## O problema da integração

A maioria das empresas não tem um panorama de TI vazio. Elas têm SAP, [Workday](https://www.workday.com/), [SuccessFactors](https://www.sap.com/products/hcm.html), SharePoint, sistemas setoriais, middleware acumulado ao longo dos anos e arquiteturas de segurança consolidadas. Isso não é um obstáculo para IA. É a realidade na qual a IA precisa se encaixar.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Resumo - Integração de IA na TI existente</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Infraestrutura IA é uma camada de integração sobre os sistemas existentes - SAP, Workday e ambientes cloud permanecem inalterados.</li>
<li>Quatro camadas arquitetônicas: conectividade com sistemas, orquestração, Decision Layer e interface do usuário.</li>
<li>Agentes se comunicam via APIs padrão (RFC, OData, REST) - sem acesso direto a banco de dados, sem interfaces proprietárias.</li>
<li>McKinsey (2024) reporta que 74% dos projetos de IA enterprise não avançam além da fase piloto, principalmente por lacunas de integração.</li>
<li>Políticas de segurança, autenticação e processos de auditoria existentes permanecem plenamente válidos - o agente é um participante adicional, não um sistema paralelo.</li>
</ul>
</div>

A causa mais frequente de fracasso de projetos de IA em empresas não é a tecnologia. É que a IA é introduzida como sistema isolado, ao lado da TI existente, não dentro dela. Isso gera Shadow IT, silos de dados e lacunas de governança.

A abordagem correta: infraestrutura IA como camada de integração que conecta os sistemas existentes em vez de substituí-los.


## Princípio arquitetônico: camada de integração, não migração de plataforma

Uma infraestrutura IA corporativa é composta por quatro camadas que se encaixam em qualquer panorama de TI existente.

A camada mais baixa é a conectividade com sistemas. Conectores para SAP (via RFC, OData, BAPIs), para Workday (via REST APIs), para SharePoint, sistemas de e-mail e aplicações setoriais. Esses conectores leem e escrevem dados. Os sistemas de origem permanecem inalterados.

Acima dela fica a camada de orquestração. É aqui que os [agentes IA](/br/servicos/ai-agents/) operam: Document Agents que leem e classificam documentos recebidos. Workflow Agents que gerenciam processos entre sistemas. Knowledge Agents que respondem perguntas com base no conhecimento corporativo.

A terceira camada é o [Decision Layer](/br/decision-layer/). Ele separa a análise IA da decisão de negócio. O modelo recomenda, o humano decide. Cada decisão é documentada, versionada e auditável.

A camada superior é a interface: uma interface de chat unificada para colaboradores ou integração direta sistema-a-sistema sem interação humana.


## Na prática: como um agente IA se integra a um ambiente SAP

Um exemplo real: processamento de atestados médicos.

O colaborador envia o atestado médico por e-mail ou por um portal. Um Document Agent identifica o tipo de documento, extrai os campos relevantes (nome, período, grupo de diagnóstico) e valida os dados contra o acordo coletivo conforme a CLT (PT: Código do Trabalho) (BR) / Código do Trabalho (PT). Via conector SAP, consulta os dados cadastrais do funcionário, calcula a remuneração durante o afastamento e prepara o lançamento contábil.

Nesse ponto, o Decision Layer intervém: se o caso se enquadra nas regras automatizáveis (caso padrão, sem anomalias), o lançamento é apresentado ao responsável para aprovação. Se uma anomalia é detectada (frequência, descumprimento de prazo, dados incompletos), o caso é escalado.

A instância SAP não foi modificada em nenhum momento. O agente opera como camada de integração externa que se comunica via APIs padrão. Os conceitos de autorização, zonas de rede e processos de auditoria existentes permanecem inalterados.


## O que a arquitetura de TI deve oferecer

Para uma integração limpa, a infraestrutura IA requer quatro propriedades.

Primeiro: API-first. Toda comunicação entre agente e sistema de origem ocorre via APIs documentadas. Sem acessos diretos a banco de dados, sem interfaces proprietárias.

Segundo: multi-tenancy. Em estruturas corporativas, agentes devem ser configuráveis por entidade: regras diferentes, sistemas diferentes, requisitos de compliance diferentes por subsidiária.

Terceiro: logging e auditoria. Cada interação entre agente e sistema de origem é registrada: quem leu, escreveu ou decidiu o quê, e quando. Isso não é opcional. É a base do [Governance by Design](/br/governance/).

Quarto: capacidade de rollback. Se um agente comete um erro, cada ação deve ser reversível. Isso exige comunicação transacional com os sistemas de origem.


## Visão geral das camadas de integração

<table>
<thead>
<tr><th>Camada</th><th>Função</th><th>Tecnologia</th></tr>
</thead>
<tbody>
<tr><td>Conectividade</td><td>Leitura/escrita em sistemas de origem</td><td>SAP RFC/OData, Workday REST, TOTVS API, Microsoft Graph</td></tr>
<tr><td>Orquestração</td><td>Coordenar agentes e workflows</td><td>Trigger.dev, Camunda, n8n</td></tr>
<tr><td>Decision Layer</td><td>Separar análise IA de decisões de negócio</td><td>Rules Engine, Confidence Routing, Human-in-the-Loop</td></tr>
<tr><td>Interface</td><td>Acesso de colaboradores ou sistema-a-sistema</td><td>Enterprise AI Portal, REST API</td></tr>
</tbody>
</table>

## Nem greenfield nem migração de plataforma

A objeção mais frequente dos CIOs: "Não podemos introduzir mais um sistema." E essa objeção é legítima.

Por isso a infraestrutura IA não é um novo sistema no sentido tradicional. É uma camada que se encaixa na arquitetura existente. SAP continua SAP. Workday continua Workday. A arquitetura de rede permanece intacta. As políticas de segurança permanecem válidas. O agente é um participante adicional no ecossistema existente, sujeito às mesmas regras, aos mesmos controles, aos mesmos requisitos de auditoria.

Na Gosign, construímos [infraestrutura IA](/br/servicos/infraestrutura/) como camada de integração: em Azure, GCP ou Self-Hosted, conectada aos sistemas que já existem. Sem Shadow IT. Agentes se tornam parte da [governança de TI](/br/governance/) existente, não um mundo paralelo.

--- Integração de IA em infraestruturas de TI existentes ---
> Como integrar AI Agents em sistemas enterprise existentes? Integration Layer, desacoplamento via API, lógica de negócio separada da camada de exportação.

## O princípio: ampliar, não substituir

AI Agents não substituem sistemas existentes. Eles os ampliam. SAP continua SAP. TOTVS continua TOTVS. Workday continua Workday. O agente fica no meio: lê dados, toma decisões e grava resultados de volta.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Resumo - Integração de IA em sistemas enterprise</p>
<ul class="text-body text-gosign-text space-y-2">
<li>AI Agents ampliam sistemas existentes (SAP, TOTVS, Workday) em vez de substituí-los - o agente é uma camada de integração externa.</li>
<li>O Integration Layer desacopla a lógica do agente do sistema-alvo: quando o ERP muda, apenas a camada de exportação muda.</li>
<li>A lógica de negócio (Decision Layer) é separada arquitetonicamente do formato de exportação (Integration Layer), reduzindo o esforço de migração.</li>
<li>Forrester (2024) constata que empresas com estratégias de integração API-first implantam IA 2,4 vezes mais rápido do que aquelas com conectores personalizados.</li>
<li>Agentes utilizam autenticação, ambiente de nuvem, políticas de segurança e monitoramento existentes - sem sistema paralelo.</li>
</ul>
</div>

Esse princípio é decisivo para a aceitação em ambientes enterprise. CIOs não investem em um mundo paralelo. Investem em uma camada que torna sua infraestrutura de TI existente mais inteligente.

## O Integration Layer

O Integration Layer na arquitetura de referência Gosign desacopla a lógica do agente do sistema-alvo. Isso tem uma vantagem concreta: quando o sistema-alvo muda, apenas a camada de exportação muda - não o agente.

**[SAP FI/CO e S/4HANA](https://www.sap.com/products/erp/s4hana.html):** Propostas de lançamento no formato SAP. Lógica de centros de custo e centros de lucro. Integração via RFC, REST API ou SAP BTP.

**TOTVS Protheus/Datasul:** No contexto brasileiro, integração com o ecossistema TOTVS é essencial. Propostas de lançamento no formato compatível. Planos de contas específicos por cliente. Integração com módulos fiscais para SPED.

**[Workday](https://www.workday.com/):** Dados de RH, informações de folha de pagamento, estrutura organizacional. Integração via Workday REST API.

**[SuccessFactors](https://www.sap.com/products/hcm.html):** Dados de funcionários, dados de desempenho, remuneração. Integração via SAP SuccessFactors API.

**[Microsoft Graph](https://learn.microsoft.com/en-us/graph/overview):** SharePoint, Teams, Outlook. Para Knowledge Agents que acessam documentos da empresa.

**Sistemas fiscais brasileiros:** Integração com SPED Fiscal, SPED Contábil, e-Social, NF-e e CT-e. Geração automática de obrigações acessórias a partir das decisões do agente.

## Desacoplamento: lógica de negócio vs. camada de exportação

A separação entre lógica de negócio e camada de exportação é um princípio arquitetônico central. A lógica de negócio - qual conta, qual centro de custo, qual alíquota de imposto - é implementada no Decision Layer. A camada de exportação - como o resultado é entregue ao TOTVS ou SAP - está no Integration Layer.

Quando o cliente migra de TOTVS para SAP, a camada de exportação muda. A lógica de negócio, os conjuntos de regras, o agente - tudo permanece igual. Isso reduz significativamente o esforço de migração.

## Integration Layer por sistema-alvo

<table>
<thead>
<tr><th>Sistema-alvo</th><th>Método de integração</th><th>Escopo de dados</th></tr>
</thead>
<tbody>
<tr><td>SAP FI/CO, S/4HANA</td><td>RFC, REST API, SAP BTP</td><td>Propostas de lançamento, lógica de centros de custo</td></tr>
<tr><td>TOTVS Protheus/Datasul</td><td>APIs TOTVS, módulos fiscais</td><td>Lançamentos, planos de contas, SPED</td></tr>
<tr><td>Workday</td><td>Workday REST API</td><td>Dados RH, folha de pagamento, estrutura org.</td></tr>
<tr><td>SuccessFactors</td><td>SAP SuccessFactors API</td><td>Dados funcionários, desempenho, remuneração</td></tr>
<tr><td>Microsoft Graph</td><td>Graph API</td><td>SharePoint, Teams, Outlook</td></tr>
</tbody>
</table>

## Sem sistema paralelo

Agentes tornam-se parte da [governance de TI](/br/servicos/infraestrutura/) existente - não um novo mundo paralelo. Isso significa:

- Agentes utilizam a autenticação existente (Azure Entra ID, LDAP)
- Agentes rodam no ambiente de nuvem existente (Azure, GCP)
- Agentes estão sujeitos às políticas de segurança existentes
- Agentes são integrados aos sistemas de monitoramento existentes

Para o CIO, um AI Agent é mais um componente na arquitetura existente - não um sistema separado com regras próprias.

No Brasil, essa integração deve considerar também a conformidade com a LGPD (PT: RGPD) para o fluxo de dados pessoais entre sistemas, e os requisitos do SPED para rastreabilidade de registros contábeis e fiscais.

Mais informações: [Infraestrutura de IA - Blueprint 2026](/br/revista/infraestrutura-ia-blueprint-2026/) | [Decision Layer explicado](/br/revista/decision-layer-explicado/)

<a href="/br/contato/" target="_blank" rel="noopener noreferrer">Agendar reunião</a> - Mostramos a integração em sua infraestrutura de TI existente.

--- LLM Self-Hosting para Enterprise - Azure, GCP, On-Premise ---
> Como hospedar modelos de linguagem em infraestrutura própria? DeepSeek, Llama, Mistral self-hosted. Azure, GCP, on-premise, híbrido.

## Por que self-hosting?

Para muitos clientes enterprise, a questão não é se IA será adotada, mas onde os dados serão processados. Na utilização de Cloud APIs (OpenAI, Anthropic, Google), dados saem da infraestrutura própria. Para setores regulados - financeiro, saúde, setor público - isso pode ser critério eliminatório.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Resumo - LLM Self-Hosting para Enterprise</p>
<ul class="text-body text-gosign-text space-y-2">
<li>O self-hosting mantém todos os dados na rede corporativa - sem processamento por terceiros, controle total sobre modelo, dados e inferência.</li>
<li>Modelos open source (Llama, Mistral, DeepSeek, gpt-oss) podem ser implantados no Azure ML, GCP Vertex AI, servidores GPU próprios ou configurações híbridas.</li>
<li>O dimensionamento de GPU é o principal fator de custo: um modelo 7B roda em uma GPU, um modelo 70B requer múltiplas GPUs ou quantização.</li>
<li>O roteamento modelo-agnóstico permite que agentes usem modelos self-hosted para dados sensíveis e Cloud APIs para tarefas não críticas.</li>
<li>Gartner (2024) prevê que 45% das implantações de IA em setores regulados operarão em infraestrutura privada até 2027 - ante 20% em 2023.</li>
</ul>
</div>

Self-hosting significa: o modelo de linguagem roda na infraestrutura do cliente. Nenhum dado sai da rede corporativa, garantindo total [Data Residency](/br/governance/data-residency/). Nenhum terceiro processa as solicitações. Controle total sobre modelo, dados e processamento.

No Brasil, a LGPD (PT: RGPD) impõe requisitos rigorosos para transferência internacional de dados pessoais. Self-hosting elimina esse risco por completo, mantendo todos os dados sob jurisdição nacional.

## Quais modelos podem ser operados self-hosted?

Modelos open-source podem ser operados em infraestrutura própria:

**Cavalo de batalha por volume - [Mistral](https://mistral.ai/) Small 3.2 (24B, Apache 2.0, construído na UE):** Modelo europeu, roda em uma única RTX 4090 com quantização de 4 bits. Ideal para inferência em lote sobre cargas não críticas. Mixtral 8x22B e Codestral Mamba 32B (especializado em código) completam o portfólio Mistral.

**Reasoning OSS - gpt-oss-120b (OpenAI, Apache 2.0):** 117B parâmetros, arquitetura MoE, roda em uma única H100 (80 GB). Primeiro modelo open source da OpenAI; gpt-oss-20b para cenários edge.

**Frontier OSS - [DeepSeek](https://www.deepseek.com/) V4-Flash e V4-Pro (MIT):** DeepSeek V4-Flash (abril 2026, 284B/13B MoE ativos) roda em uma única H100 com quantização. V4-Pro (1.6T/49B) exige um cluster de 8x H100 e entrega raciocínio de nível frontier. DeepSeek R1 (janeiro 2025) segue pronto para produção em deployments maduros - V4 não aposenta o R1 de um dia para o outro.

**Contexto longo - [Llama](https://llama.meta.com/) 4 Scout (Meta License):** Janela de contexto de 10M tokens para análise documental sobre dossiês inteiros. Llama 4 Maverick atende contextos mais curtos com maior throughput de tokens.

**Coding OSS - Qwen 3 Coder 110B (Apache 2.0, Alibaba) e DeepSeek Coder V4 (MIT):** Especializados em geração de código e compreensão de repositórios. Codestral Mamba 32B (Mistral, construído na UE) como alternativa europeia.

Modelos proprietários (Claude Opus 4.7, GPT-5.5, Gemini 3.1 Pro) não estão disponíveis para self-hosting, mas podem ser utilizados via API com processamento na UE.

Na arquitetura modelo-agnóstica, um agente pode utilizar múltiplos modelos: self-hosted para dados sensíveis, Cloud API para tarefas não-críticas. O roteamento é baseado em regras e configurado no Decision Layer.

## Opções de deployment

**Azure:** LLMs podem ser deployados no Azure ML ou operados em VMs GPU dedicadas (séries NC, ND). Integração com Azure Entra ID para autenticação e controle de acesso. Processamento em data centers na região do Brasil (Brazil South) ou na UE (West Europe, North Europe).

**GCP:** Deployment via Vertex AI ou em VMs GPU dedicadas (A2, G2). Integração com Google Cloud IAM. Processamento em data centers na América do Sul (southamerica-east1 em São Paulo) ou na UE.

**On-premise:** Servidores próprios com GPUs NVIDIA (A100, H100, RTX 4000 Ada). Operação em data centers certificados no Brasil (Equinix SP, Ascenty) ou em Portugal (PT: data centers certificados como Equinix em Lisboa). Controle máximo, sem dependência de nuvem.

**Híbrido:** Combinação de self-hosted e nuvem. Workloads sensíveis localmente, não-críticos na nuvem. Governance unificada sobre ambos os ambientes.

<table class="w-full text-left text-sm">
<thead><tr class="border-b border-gosign-border">
<th class="py-2 pr-4 font-semibold">Critério</th>
<th class="py-2 pr-4 font-semibold">Self-Hosted</th>
<th class="py-2 pr-4 font-semibold">Cloud API</th>
</tr></thead>
<tbody>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Data Residency</td><td class="py-2 pr-4">Controle total, dados permanecem on-premise</td><td class="py-2 pr-4">Depende do provedor, regiões UE disponíveis</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Escolha de modelo</td><td class="py-2 pr-4">Apenas open source (Llama, Mistral, DeepSeek)</td><td class="py-2 pr-4">Proprietários + open source via API</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Custo em escala</td><td class="py-2 pr-4">Menor (custo GPU fixo, sem taxas por token)</td><td class="py-2 pr-4">Maior (preço por token escala linearmente)</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Esforço operacional</td><td class="py-2 pr-4">Alto (gestão GPU, atualizações, HA)</td><td class="py-2 pr-4">Baixo (gerenciado pelo provedor)</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Latência</td><td class="py-2 pr-4">Baixa (rede local)</td><td class="py-2 pr-4">Variável (depende da rede)</td></tr>
</tbody>
</table>

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">eBook gratuito: Infraestrutura de IA</p>
<p class="text-body text-gosign-text mb-4">Build, Buy, Hybrid - infraestrutura em conformidade regulatória com B/B/H-Framework e 7-Layer Reference Architecture.</p>
<a href="/br/ebook/ia-infraestrutura-manual-governanca/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Baixar grátis</a>
</div>

## Considerações de arquitetura

**Dimensionamento de GPU:** O tamanho do modelo determina a necessidade de GPU. Um modelo 7B roda em uma única GPU. Um modelo 70B requer múltiplas GPUs ou quantização. O dimensionamento correto depende do caso de uso.

**Otimização de inferência:** Técnicas como quantização (4-bit, 8-bit), batching e otimização de KV-cache reduzem a necessidade de recursos com perda de qualidade aceitável.

**Alta disponibilidade:** Para sistemas produtivos: servidores GPU redundantes, load balancing, failover automático. Sem ponto único de falha.

**Atualizações de modelo:** Novas versões de modelos devem ser testadas antes de entrar em produção. Um ambiente de staging para testes de modelo faz parte da infraestrutura.

**Ponto de equilíbrio TCO - self-host vs Cloud API:** O limiar fica em torno de 50-100M tokens/mês sustentados. Abaixo desse patamar, Cloud APIs saem mais baratas; acima dele, uma H100 dedicada se amortiza em 12-18 meses. Veja [IA Open Source Auto-hospedada 2026](/br/revista/ia-open-source-auto-hospedada-2026/) para a matriz completa de modelos e o cálculo de custos.

Mais informações: [Estratégias de hosting de IA](/br/revista/hosting-ia-estrategias-enterprise/) | [Modelos de IA - Comparativo 2026](/br/revista/modelos-ia-comparacao-2026/)

<a href="/br/contato/" target="_blank" rel="noopener noreferrer">Agendar reunião</a> - Mostramos a estratégia de hosting ideal para seus requisitos.

--- Modelo agnóstico - Por que vendor lock-in em LLMs é perigoso ---
> Modelo agnóstico significa: a lógica de negócio é desacoplada do modelo de linguagem. Se o modelo muda, agentes, Decision Layer e regras permanecem.

## O risco: um modelo, um fornecedor

Muitas empresas constroem sua estratégia de IA sobre um único modelo. "Nós usamos ChatGPT" ou "Apostamos no Claude". Prompts são otimizados para esse modelo. Integrações são construídas para a API desse fornecedor. Workflows estão ajustados às particularidades desse modelo.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Resumo - Arquitetura modelo-agnóstica</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Construir sobre um único fornecedor de LLM cria dependência perigosa: preços mudam, APIs são reestruturadas, modelos são descontinuados sem aviso.</li>
<li>Uma arquitetura modelo-agnóstica desacopla a lógica de negócio do modelo de linguagem - agentes, Decision Layer e workflows permanecem intactos na troca de modelo.</li>
<li>O roteamento multi-modelo atribui modelos econômicos a tarefas simples e flagships a raciocínio complexo, economizando 40-60% em custos de tokens.</li>
<li>Modelos self-hosted processam dados sensíveis enquanto Cloud APIs atendem requisições não críticas - governado pelo Decision Layer.</li>
<li>Forrester (2024) relata que organizações com arquitetura modelo-agnóstica reduzem custos de migração de LLM em até 70% em comparação com configurações de fornecedor único.</li>
</ul>
</div>

Então acontece uma de três coisas: o fornecedor aumenta preços. O fornecedor altera a API. Um novo modelo surge que é significativamente melhor ou mais barato. Em qualquer caso: toda a implementação precisa ser adaptada.

No mercado de LLMs, isso acontece rápido. Nos últimos 18 meses, preços caíram pela metade, novos provedores surgiram, modelos open-source superaram modelos proprietários em benchmarks. Quem se vinculou a um fornecedor não consegue aproveitar essas evoluções.

No contexto brasileiro, o risco é amplificado: APIs são precificadas em dólar, e a volatilidade do real torna custos imprevisíveis. Uma arquitetura modelo-agnóstica permite migrar para modelos self-hosted quando a equação financeira favorece, sem reconstruir a lógica de negócio.

## Modelo agnóstico como princípio arquitetônico

Na [arquitetura de referência Gosign](/br/servicos/infraestrutura/), o Model Layer é uma camada substituível. A lógica de negócio - conjuntos de regras, lógica de decisão, workflows - é implementada no Decision Layer e Agent Layer, não no modelo.

Quando um novo modelo fica disponível, pode ser integrado sem alterar as camadas superiores. O agente não sabe qual modelo está usando. Ele faz uma solicitação ao Model Layer e recebe uma resposta. Qual modelo fornece a resposta é irrelevante para o agente.

## Multi-Model Routing

Um agente pode usar múltiplos modelos simultaneamente. O roteamento é baseado em regras:

**Otimização de custos:** Tarefas simples (classificação de documentos, extração de dados) rodam em um modelo econômico. Tarefas complexas (apoio a decisões, interpretação de regras) em um modelo mais potente.

**Residência de dados:** Dados sensíveis vão para modelos self-hosted ([Llama](https://llama.meta.com/), [Mistral](https://mistral.ai/), [DeepSeek](https://www.deepseek.com/)). Dados não-críticos podem rodar via Cloud APIs. Essa separação é especialmente relevante para conformidade com a LGPD (PT: RGPD).

**Failover:** Se um provedor de modelo fica indisponível, o sistema pode alternar automaticamente para um modelo alternativo.

As regras de roteamento são configuradas no Decision Layer e rastreáveis.

## Modelos suportados

A arquitetura Gosign suporta atualmente (em 2026):
- Claude Opus 4.7 / Sonnet 4.6 / Haiku 4.5 (Anthropic) - Cloud API
- GPT-5.5 / GPT-5.5-mini (OpenAI) - Cloud API
- Gemini 3.1 Pro / 3.1 Flash (Google) - Cloud API
- Llama 4 Scout / Llama 4 Maverick (Meta) - self-hosted ou nuvem
- Mistral Small 3.2 / Mistral Large (Mistral AI) - self-hosted ou nuvem
- DeepSeek V4-Pro / V4-Flash / R1 (DeepSeek) - self-hosted ou nuvem
- gpt-oss (OpenAI) - self-hosted ou nuvem

Novos modelos podem ser integrados assim que estejam acessíveis via API padrão. Qual desses modelos é o certo para cada micro-decisão é detalhado na análise complementar: [Qual modelo quando? Decision Routing para workflows agênticos](/br/revista/modelos-ia-comparacao-2026/).

| Aspecto | Configuração de fornecedor único | Arquitetura modelo-agnóstica |
|---|---|---|
| Troca de modelo | Reconstrução completa de prompts, integrações, workflows | Mudança de regras de roteamento, sem reconstrução |
| Controle de custos | Preso a um modelo de preços | Modelos econômicos para simples, flagships para complexos |
| Soberania de dados | Depende do fornecedor | Self-hosted para sensíveis, nuvem para não críticos |
| Failover | Sem alternativa se o provedor cair | Troca automática para modelo alternativo |
| Custo de migração | Alto (Forrester: até 70% maior) | Baixo (apenas mudança de configuração) |
| Preparação futura | Risco de descontinuação | Novos modelos integrados sem alterações |

Mais informações: [Infraestrutura de IA - Blueprint 2026](/br/revista/infraestrutura-ia-blueprint-2026/) | [Custos de IA - Comparativo TCO](/br/revista/custos-ia-tco-comparacao/)

## Modelo agnóstico mais Decision Routing

Arquitetura modelo-agnóstica é a precondição; Decision Routing por micro-decisão é a aplicação. Quem constrói a camada de roteamento transforma a escolha de modelo em configuração, e a atualização de modelo em um diff de config em vez de um re-engineering. Qual modelo serve para qual tipo de decisão - classificação, tool-use, raciocínio, contexto longo - é detalhado na comparação mestra: [Qual modelo quando? Decision Routing para workflows agênticos](/br/revista/modelos-ia-comparacao-2026/).

<a href="/br/contato/" target="_blank" rel="noopener noreferrer">Agendar reunião</a> - Mostramos a arquitetura modelo-agnóstica em detalhes.

--- Quando Mistral, quando Claude Opus? Decision Routing para a empresa brasileira 2026 ---
> Decisões agênticas decompostas: Mistral Small em on-prem soberano cobre 70%, Claude Opus fica para os 10% com carga real de raciocínio. Decision Records prontos para LGPD art. 20.

O mercado de modelos amadureceu mais rápido que a maioria das arquiteturas empresariais. Claude Opus 4.7, GPT-5.5 e Gemini 3.1 Pro convergem em qualidade. Mistral La Plateforme opera de um data center francês sob jurisdição europeia. A OpenAI liberou o gpt-oss sob Apache 2.0 em agosto de 2025. Meta e Mistral lançaram modelos open-weight que rodam em uma única GPU e atingem qualidade de produção.

Mesmo assim, a maioria dos projetos enterprise de IA ainda escolhe um modelo e roteia toda a carga por ele. Essa escolha determina silenciosamente três outras coisas: sua posição de soberania de dados, o seu custo de auditoria sob LGPD e EU AI Act, e o espaço que sobra para otimização de custo. Escolher um modelo não é uma decisão de modelo. É uma decisão de arquitetura.

<div class="not-prose my-12 border border-gosign-border bg-gosign-light rounded-card p-6 lg:p-8">
<p class="text-h3 font-bold text-gosign-dark mb-3">Em resumo - Stack agêntico para a empresa brasileira em 2026</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Cerca de 70% das decisões agênticas em um workflow enterprise bem decomposto são aplicação de regra ou extração estruturada. Em setups típicos de hosting soberano, Mistral Small 3.2 em uma única GPU resolve isso por aproximadamente 1/30 do preço de lista do Claude Opus.</li>
<li>Mistral tem duas superfícies de deployment distintas: La Plateforme (API EU-hosted em infraestrutura francesa, com data center dedicado em Bruyères-le-Châtel a partir do Q2 2026) e Mistral Small 3.2 (Apache 2.0, totalmente self-hostável, 24B parâmetros).</li>
<li>Os 8 a 10% de decisões que sobram - raciocínio complexo, análise multi-jurisdição, escalonamento de casos limite - justificam Claude Opus 4.7 ou GPT-5.5. É aí que o token spend é justificado, não desperdiçado.</li>
<li>A exposição ao US CLOUD Act se aplica até mesmo a deployments na região EU de provedores americanos. Schrems II tornou isso concreto. Self-hosting de Mistral Small, gpt-oss-120b ou DeepSeek V4-Flash (preview de abril de 2026, MIT, 284B/13B active MoE) é a única arquitetura com zero superfície de CLOUD Act - relevante para transferências internacionais sob LGPD art. 33 quando o controlador brasileiro é subsidiária de grupo americano.</li>
<li>LGPD art. 20 (alterado pela Lei 13.853/2019) exige revisão de decisões automatizadas que afetem interesses do titular - a revisão pode ser humana ou por outro sistema automatizado, desde que com transparência. EU AI Act Art. 13 exige operação transparente para sistemas de alto risco. Uma camada de Decision Routing produz o artefato de auditoria: registro por decisão com input, versão da regra, modelo, confiança e aprovador (humano ou sistêmico) onde houve escalonamento.</li>
</ul>
</div>

## Você avalia Mistral - o que avalia de verdade é sua estratégia de soberania

O caminho típico de uma avaliação em 2026 começa assim. O Jurídico pede uma alternativa à OpenAI compatível com LGPD em casos de transferência internacional. Compras compila pitches de fornecedores. Arquitetura começa a avaliar Mistral. Em uma semana a conversa migrou de "qual modelo" para "qual nossa posição diante do US CLOUD Act" e "como operacionalizamos LGPD art. 20 e EU AI Act Art. 13 para sistemas de alto risco em filiais europeias."

O CLOUD Act segue o controle do provedor, não a localização do dado. Um provedor americano com data centers na União Europeia - Azure OpenAI EU, AWS Bedrock Frankfurt, GCP Vertex europe-west - pode ser obrigado a entregar dados sob ordem judicial americana. A Comissão Europeia deve publicar um [Tech Sovereignty Package](https://www.kiteworks.com/cybersecurity-risk-management/eu-tech-sovereignty-package-cloud-act/) no Q2 2026, restringindo o uso de provedores americanos por órgãos públicos em saúde, finanças e justiça. Compras corporativas estão lendo esses sinais.

AWS Brazil South (São Paulo) é uma questão central para fintech sob BACEN: a região é Brasil, mas Amazon Web Services Brasil Ltda é controlada pela Amazon.com Inc (US). CLOUD Act aplica-se. BACEN Resolução 4.893 art. 11 fala de "infraestrutura crítica em território nacional" para alguns serviços - AWS Brazil pode ou não atender dependendo de cláusulas contratuais reforçadas. Para fintech, Auditoria BACEN exige clarificação prévia: controlador legal sob LGPD art. 33 quando a contratante é AWS Brasil mas casa-mãe é Inc.? O mesmo raciocínio se aplica a Azure Brazil South e GCP São Paulo. Para dados pessoais sensíveis ou para tratamento sob regime BACEN, a posição defensável de Compras é: hyperscaler em região BR exige cláusulas contratuais reforçadas (residência ponta a ponta, vedação de acesso pela matriz, plano de saída) ou substituição por provedor nacional puro (Locaweb, Equinix SP colocation, SERPRO, Dataprev para estatais).

Mistral interessa não porque vence Claude num leaderboard. Interessa porque ocupa uma posição que nenhum provedor americano consegue ocupar: um provedor europeu de fronteira com [infraestrutura dedicada na UE](https://help.mistral.ai/en/articles/347629-where-do-you-store-my-data-or-my-organization-s-data) e uma linha de modelos open-weight sob Apache 2.0. A partir do Q2 2026, a empresa opera o próprio data center perto de Paris com [13.800 GPUs NVIDIA GB300](https://ioplus.nl/en/posts/why-mistrals-830m-raise-is-a-win-for-european-autonomy) e 44 megawatts de capacidade. Isso torna Mistral o único provedor de fronteira que oferece residência ponta a ponta na UE em infraestrutura própria sob jurisdição europeia.

Mas isso ainda enquadra a pergunta de forma errada. A pergunta real não é "Mistral ou OpenAI". É "quais decisões vão para onde, e como você prova isso ao auditor independente, à ANPD ou ao Encarregado de Dados (DPO)".

## Mistral são dois mundos: La Plateforme na França ou Mistral Small Apache 2.0

A confusão começa quando se trata "Mistral" como um produto único. São duas famílias de produto com superfícies de deployment diferentes e implicações de compliance diferentes.

| Produto Mistral | Deployment | Licença / custo | Soberano |
|---|---|---|---|
| Mistral Medium 3.1 | La Plateforme (API hosted na França) ou Azure AI Foundry | Token-based, proprietário | Sim via La Plateforme |
| Mistral Small 3.2 | Self-hosted on-prem | Apache 2.0, só custo de GPU | Sim se hardware na UE ou Brasil |
| Mixtral 8x22B | Self-hosted on-prem | Apache 2.0, só custo de GPU | Sim se hardware na UE ou Brasil |
| Codestral | La Plateforme | Token-based, proprietário | Sim via La Plateforme |

*"Soberano" significa aqui: fora do alcance do US CLOUD Act. Tanto La Plateforme (jurisdição francesa) quanto self-hosted em hardware na UE ou em data center brasileiro qualificam. Azure AI Foundry não qualifica, mesmo com residência na EU, porque a Microsoft permanece sujeita ao CLOUD Act.*

Mistral Medium 3.1 é o flagship proprietário. Roda na infraestrutura francesa da Mistral, acessado por API. Token-billed. Soberano por padrão. A partir do Q2 2026, o data center dedicado em Bruyères-le-Châtel atende clientes que exigem garantia de residência francesa.

[Mistral Small 3.2](https://mistral.ai/news/mistral-small-3-1) é o open-weight workhorse. 24 bilhões de parâmetros. Contexto de 128K tokens. Vision incluído. Lançado em março de 2025 sob Apache 2.0. Roda em uma única NVIDIA RTX 4090 ou em um Mac com 32 GB de RAM. Throughput de cerca de 150 tokens por segundo em hardware consumer.

Os dois não são redundantes. La Plateforme faz sentido quando você quer soberania na UE sem operar infraestrutura GPU. Mistral Small 3.2 faz sentido quando a decisão tem volume tão alto que o token billing vira o cost driver, ou quando o dado é tão sensível que mesmo tráfego de API para a UE é superfície demais.

A pergunta de arquitetura é qual superfície de deployment para qual decisão, não qual provedor para qual leaderboard.

<figure class="not-prose my-12">
<svg viewBox="0 0 800 600" xmlns="http://www.w3.org/2000/svg" role="img" aria-labelledby="radar-title-br radar-desc-br" class="w-full h-auto max-w-3xl mx-auto">
<title id="radar-title-br">Comparação de perfis de modelos em seis dimensões enterprise (maio 2026)</title>
<desc id="radar-desc-br">Spider-chart comparando quatro modelos representativos em seis dimensões relevantes para empresa, pontuados de 0 a 10. Claude Opus 4.7 (nuvem, Anthropic): Raciocínio 10, Codificação 10, Multimodal 7, Eficiência de custo 3, Latência 6, Soberania UE 4. GPT-5.5 (nuvem, OpenAI/Azure): Raciocínio 10, Codificação 10, Multimodal 9, Eficiência 3, Latência 7, Soberania 4. Mistral Small 3.2 (self-host, Apache 2.0): Raciocínio 6, Codificação 7, Multimodal 8, Eficiência 10, Latência 9, Soberania 10. DeepSeek V4-Pro (self-host, MIT): Raciocínio 9, Codificação 8, Multimodal 5, Eficiência 7, Latência 7, Soberania 9. Os flagships cloud dominam em Raciocínio, Codificação e Multimodal mas perdem em Eficiência de custo e Soberania UE. Os modelos self-host invertem esse padrão. A camada de routing combina ambas as formas por micro-decisão em vez de escolher um campeão.</desc>
<defs><style>
.axis-br { stroke: #d4d0cb; stroke-width: 1; fill: none; }
.grid-br { stroke: #d4d0cb; stroke-width: 0.5; fill: none; opacity: 0.5; }
.label-br { font-family: -apple-system, system-ui, sans-serif; font-size: 12px; fill: #1a2e4d; text-anchor: middle; font-weight: 600; }
.scale-br { font-family: -apple-system, system-ui, sans-serif; font-size: 9px; fill: #94a3b8; text-anchor: middle; }
.legend-br { font-family: -apple-system, system-ui, sans-serif; font-size: 12px; fill: #1a2e4d; font-weight: 500; }
.legend-sub-br { font-family: -apple-system, system-ui, sans-serif; font-size: 10px; fill: #64748b; }
</style></defs>
<circle cx="400" cy="300" r="50" class="grid-br"/><circle cx="400" cy="300" r="100" class="grid-br"/><circle cx="400" cy="300" r="150" class="grid-br"/><circle cx="400" cy="300" r="200" class="grid-br"/><circle cx="400" cy="300" r="250" class="grid-br"/>
<text x="408" y="100" class="scale-br">10</text><text x="408" y="150" class="scale-br">8</text><text x="408" y="200" class="scale-br">6</text><text x="408" y="250" class="scale-br">4</text><text x="408" y="300" class="scale-br">2</text>
<line x1="400" y1="300" x2="400" y2="50" class="axis-br"/><line x1="400" y1="300" x2="616.5" y2="175" class="axis-br"/><line x1="400" y1="300" x2="616.5" y2="425" class="axis-br"/><line x1="400" y1="300" x2="400" y2="550" class="axis-br"/><line x1="400" y1="300" x2="183.5" y2="425" class="axis-br"/><line x1="400" y1="300" x2="183.5" y2="175" class="axis-br"/>
<text x="400" y="38" class="label-br">Raciocínio</text>
<text x="630" y="165" class="label-br">Codificação</text>
<text x="630" y="438" class="label-br">Multimodal</text>
<text x="400" y="572" class="label-br">Eficiência de custo</text>
<text x="170" y="438" class="label-br">Latência inferência</text>
<text x="170" y="165" class="label-br">Soberania UE</text>
<polygon points="400,50 616.5,175 562,387 400,375 335,338 313,225" fill="#fcd34d" fill-opacity="0.25" stroke="#b8941f" stroke-width="2"/>
<polygon points="400,50 616.5,175 595,413 400,375 313,363 313,225" fill="#3a6090" fill-opacity="0.20" stroke="#3a6090" stroke-width="2" stroke-dasharray="6 3"/>
<polygon points="400,150 551.5,213 579,400 400,550 205,425 183.5,175" fill="#1a2e4d" fill-opacity="0.20" stroke="#1a2e4d" stroke-width="2"/>
<polygon points="400,75 595,188 508,363 400,475 248,400 205,200" fill="#9a5a5a" fill-opacity="0.18" stroke="#9a5a5a" stroke-width="2" stroke-dasharray="3 3"/>
<g transform="translate(40, 590)"><rect x="0" y="-15" width="15" height="3" fill="#b8941f"/><text x="22" y="-9" class="legend-br">Claude Opus 4.7</text><text x="22" y="3" class="legend-sub-br">nuvem, Anthropic</text></g>
<g transform="translate(195, 590)"><rect x="0" y="-15" width="15" height="3" fill="#3a6090"/><text x="22" y="-9" class="legend-br">GPT-5.5</text><text x="22" y="3" class="legend-sub-br">nuvem, OpenAI/Azure</text></g>
<g transform="translate(370, 590)"><rect x="0" y="-15" width="15" height="3" fill="#1a2e4d"/><text x="22" y="-9" class="legend-br">Mistral Small 3.2</text><text x="22" y="3" class="legend-sub-br">self-host, Apache 2.0</text></g>
<g transform="translate(560, 590)"><rect x="0" y="-15" width="15" height="3" fill="#9a5a5a"/><text x="22" y="-9" class="legend-br">DeepSeek V4-Pro</text><text x="22" y="3" class="legend-sub-br">self-host, MIT</text></g>
</svg>
<figcaption class="text-sm text-gosign-text-light text-center mt-4 max-w-2xl mx-auto">
<strong>Perfil de modelo em seis dimensões enterprise</strong> - vista comparativa estilo c't, pontuada de 0 a 10. Os flagships cloud (Claude Opus 4.7, GPT-5.5) dominam em Raciocínio, Codificação, Multimodal, mas perdem em Eficiência de custo e Soberania UE. Os modelos self-host (Mistral Small 3.2, DeepSeek V4-Pro) invertem essa forma. Não existe modelo "melhor" - a camada de routing escolhe a forma certa por micro-decisão.
</figcaption>
</figure>

## Por que Mistral Small como default, não gpt-oss ou DeepSeek

Uma pergunta justa depois de decidir self-hosting: por que Mistral Small 3.2 ganha o posto de workhorse sobre [gpt-oss-120b](https://openai.com/index/introducing-gpt-oss/) (Apache 2.0, 117B params MoE, 5 de agosto de 2025) ou [DeepSeek V4](https://api-docs.deepseek.com/news/news260424) (MIT, preview de 24 de abril de 2026; V4-Flash 284B/13B active, V4-Pro 1.6T/49B active, contexto de 1M)? Os três são legitimamente self-hostáveis em alguma configuração. A diferenciação está em hardware floor, cobertura de idiomas e modalidade.

| Modelo open-source | Hardware floor | Força | Fraqueza | Sweet spot |
|---|---|---|---|---|
| Mistral Small 3.2 (24B, Apache 2.0) | 1× RTX 4090 (~1.500 EUR one-time) ou Mac M2/M3 32GB | Volume, multilíngue (PT-BR/EN/ES/FR/DE), com vision, ~150 tok/s | Não é raciocínio de topo | **Workhorse default para a faixa de 70% de volume** |
| gpt-oss-120b (117B MoE, Apache 2.0) | 1× H100/A100 80GB (~30k EUR ou ~1.200 EUR/mês hosted) | Raciocínio nível o4-mini, eficiência MoE | Sem vision, hardware grau data center obrigatório | **Alternativa heavy-reasoning ao Claude Opus quando até isso tem que ficar on-prem** |
| DeepSeek V4-Flash (MIT, preview Abr 2026) | 1-2× H100/A100 80GB com quant | Raciocínio de fronteira em hardware moderado, contexto 1M, multimodal nativo | Status preview - benchmarks precisam ser reverificados antes de produção | **Especialista em matemática/lógica + análise de portfólio com contexto 1M** |
| DeepSeek V4-Pro (MIT, preview Abr 2026) | Cluster multi-GPU (8× H100, ~240.000 EUR CAPEX ou ~10-12k EUR/mês hospedado) | Aproxima performance de GPT-5.5/Gemini 3.1 Pro, otimizado para agent-tooling | Hardware classe hyperscaler; PME via API/hospedado é o caminho realista | **Raciocínio de fronteira sob licença aberta - grande empresa on-prem, PME via API** |
| Llama 4 Scout (Meta Llama License) | 1× GPU | Contexto de 10M tokens | Restrição de licença acima de 700M MAU | **Contexto ultra-longo para portfólios contratuais inteiros** |

Três razões concretas para Mistral Small assumir o default:

**Hardware threshold.** Mistral Small roda em silício consumer. gpt-oss-120b precisa de GPU data center. Para um pipeline enterprise com cinco a dez worker nodes, o delta de hardware por nó é significativo. Quando 70% das decisões são classificação ou extração, capacidade de raciocínio gpt-oss-grade é overkill para o trabalho de volume.

**Corpus de treinamento multilíngue.** Mistral foi treinado desde o início com dados em francês, alemão, espanhol e italiano - e cobre português europeu e brasileiro de forma muito mais consistente que gpt-oss. gpt-oss é US-centric, com treinamento dominantemente em inglês. Para um pipeline brasileiro processando documentos em português com nomenclatura jurídica brasileira (CLT, CPF, IRRF), Mistral Small é o workhorse melhor no dia um.

**Vision incluído.** Mistral Small 3.2 tem capacidade nativa de vision. gpt-oss não. Para onboarding de pessoal (RG, CPF, comprovante de residência, ASO, certificados), folha de pagamento (holerites em PDF) ou financeiro (notas fiscais com layout específico), isso é nocaute.

gpt-oss-120b ou DeepSeek V4-Flash entram no stack como opção on-prem de raciocínio pesado quando a API do Claude Opus 4.7 não pode ser usada por motivo de compliance. DeepSeek V4-Pro chega perto de performance frontier-closed-source sob licença MIT, mas seu hardware floor (cluster de 8× H100, cerca de 240.000 EUR CAPEX ou 10-12k EUR/mês em hospedagem dedicada) define a fronteira por tamanho de empresa, não por licença: para grande empresa B3 e média empresa superior, esses 240k EUR são item-orçamento-TI padrão; para PME abaixo de 500 funcionários, V4-Pro via API ou hospedado (Together.ai, Fireworks, DeepSeek API) é o caminho realista. Nenhum deles substitui o Mistral Small como workhorse de volume - eles complementam para as decisões mais duras. O comparativo detalhado de self-hosted está em [IA open-source auto-hospedada 2026: Mistral, gpt-oss, DeepSeek V4, Llama 4 no stack enterprise](/br/revista/ia-open-source-auto-hospedada-2026/) (artigo separado).

## Qual modelo para o quê? A distribuição de complexidade das decisões agênticas

Um agente enterprise típico se decompõe em 14 a 50 microdecisões. A complexidade não está distribuída de forma uniforme. Em um pipeline de RH ou Financeiro bem instrumentado, ela segue um padrão que medimos consistentemente:

| Tipo de decisão | Fatia das decisões | Complexidade | Melhor modelo | Custo real por 1M tokens |
|---|---|---|---|---|
| Aplicação de regra (faixa de IRRF a partir do salário, classificação de tipo de contrato CLT, verificação de limite) | 50% | Baixa | Muitas vezes sem LLM; senão Mistral Small 3.2, Llama 4 Scout, gpt-oss-20b | ~0 a ~0,50 USD |
| Extração estruturada (extração de campos de PDF, normalização de tabelas, line items corrigidos por OCR) | 25% | Média | Mistral Small 3.2, Mistral Medium 3.1, gpt-oss-120b | ~0,50 a ~2 USD |
| Classificação contextual (revisão de cláusula contratual contra ACT - ou CCT na ausência de ACT próprio - vigente, detecção de anomalias em despesas, flags de risco de fornecedor) | 15% | Média-alta | Mistral Medium 3.1, Claude Haiku 4.5, GPT-5 mini | ~1 a ~5 USD |
| Raciocínio complexo (análise cross-jurisdição Lei 14.611/2023 + Lei 9.029/1995, síntese argumentativa multi-etapa, redação de escalonamento) | 8% | Alta | Claude Opus 4.7, GPT-5.5 | ~15 a ~25 USD |
| Multimodal (correlação imagem + texto, segmentos de vídeo, revisão de desenho técnico) | 2% | Alta | Gemini 3.1 Pro | ~5 a ~10 USD |

A implicação é simples. Se você rotear toda decisão para Claude Opus, paga tarifa flagship para os 75% de trabalho que não precisam de raciocínio flagship. Se rotear toda decisão para Mistral Small, economiza em token mas falha nos 8% em que o raciocínio classe Opus realmente importa - e paga o preço em achados de auditoria, não em tokens.

O [Stanford HAI AI Index 2025](https://hai.stanford.edu/ai-index/2025-ai-index-report) registra que 65,7% dos foundation models lançados em 2023 foram open-source, contra 33,3% em 2021. A adoção enterprise de IA passou de 78%. O mercado não escolhe mais entre proprietário e aberto. Está escolhendo como compor os dois.

## Mistral Small como workhorse: um agente de admissão com 14 microdecisões

Exemplo concreto. Um agente de admissão recebe o contrato assinado de um novo empregado mais documentação de apoio (cópia de RG e CPF, comprovante de residência, ASO admissional, comprovantes de qualificação). Sua tarefa: produzir o registro de empregado conforme CLT art. 41, rodar checks de compliance pré-emprego, agendar onboarding, gerar o evento eSocial S-2200. Quatorze microdecisões no total, indo de validação regex até análise de risco antidiscriminatório sob Lei 9.029/1995 e Lei 14.611/2023 (igualdade salarial).

Uma implementação ingênua manda cada etapa para Claude Opus 4.7. Uma implementação decomposta roteia por etapa. A Decision Layer guarda as regras de roteamento: toda etapa é classificada como REGRAS, IA AUTÔNOMA ou HUMANO antes de executar.

**REGRAS:** A decisão é determinística. CPF segue dígito verificador específico. Faixa de IRRF segue tabela progressiva publicada pela Receita Federal. Sem interpretação, sem modelo necessário. Aqui o agente é executor, não raciocinador.

**IA AUTÔNOMA:** A decisão é classificação ou extração com confiança suficiente. Detecção de tipo de documento, classificação de tipo de contrato (CLT, PJ, estagiário, jovem aprendiz), extração estruturada de campos. Um modelo pequeno com schema claro vence um modelo flagship com prompt vago.

**HUMANO:** A decisão envolve discricionariedade, risco de discriminação, escopo de negociação coletiva ou violação de limite. Análise de discriminação sob Lei 9.029/1995, verificação de equidade salarial sob Lei 14.611/2023, notificação ao Sindicato laboral (referência: ACT da empresa se houver, ou CCT da categoria), anomalia salarial acima do limite acordado. O modelo prepara o caso; o humano assina a decisão.

As oito etapas a seguir são o padrão representativo de roteamento de um pipeline típico de 14 etapas. A tabela completa fica na configuração do Decision Layer do cliente.

| Etapa | Decisão | Camada | Alvo de roteamento |
|---|---|---|---|
| 1 | Detectar tipos de documento no upload | IA AUTÔNOMA | Mistral Small 3.2 on-prem |
| 2 | Extrair dados pessoais (nome, endereço, data de nascimento, CPF, RG) | IA AUTÔNOMA | Mistral Small 3.2 on-prem |
| 3 | Validar dígito verificador do CPF, formato do PIS/NIS, faixa de IRRF | REGRAS | Engine de regras, sem LLM |
| 4 | Classificar tipo de contrato (prazo determinado, indeterminado, experiência, intermitente) | IA AUTÔNOMA | Mistral Small 3.2 |
| 5 | Conferir cláusulas contratuais contra o ACT (ou CCT, se não houver ACT próprio) vigente v2024-3 | IA AUTÔNOMA | Mistral Medium 3.1 (La Plateforme) |
| 6 | Sinalizar cláusulas potencialmente discriminatórias sob Lei 9.029/1995 e Lei 14.611/2023 | HUMANO (preparado por IA) | Claude Opus 4.7 redige a análise, Diretor Jurídico assina |
| 7 | Detectar anomalias salariais em relação a cargo/localização/senioridade (Lei 14.611/2023) | IA AUTÔNOMA | Mistral Medium 3.1 |
| 8 | Classificar dados sensíveis no ASO admissional (art. 11 LGPD) e decidir comunicação à CIPA por enquadramento de risco | HUMANO (preparado por IA) | Mistral Medium 3.1 pré-classifica, Encarregado de Dados + representante da CIPA assinam |

ACT (Acordo Coletivo de Trabalho entre empresa e sindicato laboral) prevalece sobre CCT (Convenção Coletiva entre sindicato patronal e sindicato laboral) por força de CLT art. 620 - para multinacional com ACT próprio, o documento de referência da etapa 5 é o ACT, não a CCT da categoria. A camada de roteamento deve carregar a versão correta do instrumento coletivo aplicável ao empregador, não a versão genérica da categoria sindical.

ASO (Atestado de Saúde Ocupacional) = dado pessoal sensível sob art. 11 LGPD. Tratamento exige bases jurídicas restritas: consentimento expresso (art. 11 I) ou cumprimento de obrigação legal (art. 11 II - NR-7 obriga ASO admissional). Decision Layer deve mapear esta classificação especificamente, separando o fluxo do ASO do fluxo dos demais documentos (RG, CPF, comprovante de residência) que não são sensíveis.

Das 14 etapas totais, seis são REGRAS (sem LLM: validação de CPF, completude documental, gravação determinística do evento eSocial S-2200). Seis são IA AUTÔNOMA (Mistral Small ou Medium). Duas são HUMANO-com-IA-prep (Claude Opus para a análise de equidade salarial, Mistral Medium para a pré-classificação CIPA).

Em setups de hosting típicos com soberania preservada, essa distribuição dá aproximadamente 1 a 3 USD por admissão em inferência. Uma arquitetura flagship-only (cada etapa via Claude Opus) chega perto de 25 a 40 USD por admissão - e processa as etapas 1 e 2 em infraestrutura americana sob exposição ao CLOUD Act. Mesmo resultado de negócio. Audit trail diferente. Curva de custo diferente. Posição de soberania diferente.

## O que o auditor vê: Decision Records sob LGPD art. 20 e EU AI Act Art. 13

LGPD art. 20 dá ao titular o direito de solicitar revisão de decisões tomadas unicamente com base em tratamento automatizado de dados pessoais. [EU AI Act Article 13](https://artificialintelligenceact.eu/article/13/) exige que sistemas de IA de alto risco operem de forma transparente o suficiente para que os deployers consigam interpretar os outputs e usá-los adequadamente. O sistema deve ser entregue com instruções especificando métricas de acurácia, robustez, níveis de cibersegurança testados, medidas de supervisão humana sob Art. 14 e recursos de hardware exigidos.

Importante: Lei 13.853/2019 retirou do art. 20 §3º a exigência de revisão "por pessoa natural" - hoje a revisão pode ser realizada por outro sistema automatizado, desde que com transparência. Esse é o ponto onde toda decisão ANPD pivota: o artigo não obriga mais revisão humana absoluta, mas exige que o titular tenha acesso a critérios claros sobre como a decisão (automatizada ou não) foi tomada. Para o Encarregado de Dados, isso muda a economia da supervisão humana: a obrigação de design não é "humano em loop sempre", mas "transparência reproduzível sempre, com escalonamento humano onde a decisão materialmente afeta direitos".

A pergunta do auditor no dia da inspeção não é "qual modelo você usou" mas "me mostre o decision record do caso de admissão 2026-01-1873, etapa 8".

Um Decision Record produzido por uma camada de roteamento contém, por microdecisão:

- **Snapshot do input** (os campos relevantes do contexto upstream, com tratamento de dados pessoais aplicado conforme LGPD)
- **Versão da regra** (qual versão da CCT/ACT foi usada; v2024-3)
- **Tipo de decisão** (aplicação de regra, classificação por IA, raciocínio por IA, aprovação humana)
- **Modelo usado** (se IA: Mistral-Small-3.1-Instruct-2503, deployed no cluster A04, região eu-de-fra ou br-sao-1)
- **Score de confiança** (se IA: 0,94)
- **Cadeia de raciocínio** (quando aplicável: o raciocínio intermediário do modelo, capturado literalmente)
- **Resultado** (label de classificação, valor extraído ou flag de escalonamento)
- **Aprovador humano** (se escalado: nome, papel, timestamp)
- **Botão de contestação** para decisões de IA (o titular pode contestar uma decisão automatizada, o que dispara nova decisão sob revisão - humana ou por outro sistema automatizado conforme Lei 13.853/2019, com transparência sobre os critérios, conforme exigido pela LGPD art. 20)

Um pipeline que produz esses registros transforma a pergunta de modelo em pergunta de roteamento. O auditor não pergunta "Mistral é tão bom quanto Claude". O auditor pergunta "a decisão está documentada ponta a ponta e pode ser reproduzida". A pergunta do conselho vai um passo além: quem assina a decisão quando a Lei 14.611/2023 (igualdade salarial) foi violada por um alvo de roteamento que deveria ter escalado para um humano? A camada de roteamento torna essa assinatura rastreável.

### Para fintechs e instituições financeiras sob BACEN

Para fintechs e instituições financeiras sob BACEN: Resolução 4.658/2018 (Política de Cibersegurança) + Resolução 4.893/2021 (Cibernética em Arranjos de Pagamento) + Circular 3.909 sobre infraestrutura crítica em território nacional aplicam-se. Open Finance Brasil Fase 4 ativa desde 2024 exige Decision Records para classificação automatizada de transações. CMN Resolução 4.893 art. 11-14 sobre contratação de serviços relevantes de TI obriga: cláusula de auditoria BACEN, direito de exigir dados, plano de saída em contrato de fornecedor. A camada de roteamento que emite Decision Records reutilizáveis cobre exatamente esse ponto - é o artefato que a auditoria BACEN inspeciona quando questiona "como a decisão de classificação de transação X foi tomada e por qual modelo".

### Para empresas controladas pela União (estatais, infraestrutura crítica)

Para empresas controladas pela União (estatais energia, infraestrutura crítica): ANEEL Resolução 956/2021 (Plano de Continuidade de Negócio + Plano de Resposta a Incidentes + reporte ANEEL em até 72h após incidente material). TCU jurisprudência (Acórdão 1.739/2015, 2.952/2018, 1.388/2022) sobre cloud público para órgãos federais. Lei 14.133/2021 (Nova Lei de Licitações) rege contratação. Decreto 11.856/2023 (Estratégia Brasileira de IA - EBIA) estabelece governança. SERPRO (SerproCloud) + Dataprev são opções soberanas obrigatórias antes de hyperscaler para dados classificados sob Lei 12.527/2011 e Decreto 7.845/2012. Para o Diretor de TI de estatal, a sequência de avaliação é: SERPRO ou Dataprev primeiro, T-Systems/IONOS sovereign em segundo, hyperscaler em região BR só com cláusulas reforçadas e parecer jurídico explícito.

### Para o Encarregado de Dados: RIPD, CPCs e sanções ANPD

Para Encarregado de Dados: Resolução CD/ANPD 18/2024 estabelece Relatório de Impacto à Proteção de Dados (RIPD - art. 38 LGPD) obrigatório para tratamento de risco aumentado. Sistemas de IA com decisão automatizada que afeta titulares = risco aumentado. Resolução CD/ANPD 19/2024 introduziu Cláusulas-Padrão Contratuais brasileiras (CPCs) para transferência internacional - são o framework principal aprovado pela ANPD desde agosto/2024, não opcionais. Resolução CD/ANPD 4/2023 define sanções: multa até 2% do faturamento, máximo R$ 50 milhões por infração. Para Encarregado: art. 7 IX LGPD (legítimo interesse) + teste de proporcionalidade art. 10 §3º = base jurídica mais utilizada para IA sem consentimento. Trabalho central do Encarregado: documentar este teste no RIPD - é o artefato que materializa a defesa em fiscalização ANPD.

## A pergunta de arquitetura: Decision Layer ou vendor lock-in

Uma Decision Layer model-agnostic não é um feature. É a precondição para quase tudo listado neste artigo. Sem ela, os padrões de roteamento acima ficam abstratos.

| Sem Decision Layer | Com Decision Layer |
|---|---|
| A escolha de modelo gruda. Trocar provedor significa reimplementar o agente inteiro. | Trocar provedor é mudança de configuração. Modelos são intercambiáveis por etapa de decisão. |
| A otimização de custo acontece depois, em renegociação com um único vendor. | A otimização de custo é built-in: decisões de baixa complexidade roteiam automaticamente para o modelo viável mais barato. |
| Soberania é binária: ou você aceita a exposição ao US CLOUD Act, ou hospeda tudo. | Soberania é por decisão: etapas sensíveis rodam em on-prem soberano, etapas não sensíveis podem usar APIs cloud. |
| Audit trail existe em logs espalhados e é reconstruído sob demanda. | Audit trail é o log de roteamento. Compliance com LGPD art. 20 e EU AI Act Art. 13 vira consulta, não projeto. |
| Adicionar um novo modelo é uma nova integração. | Adicionar um novo modelo é colocá-lo no router. As regras de roteamento já existem. |

*Essa tabela mostra diferenças arquiteturais, não julgamentos de qualidade.*

A Decision Layer é onde a escolha de modelo é operacionalizada. O mercado de modelos muda mês a mês. Preços caem. Novos flagships são lançados. Qualidade open-weight alcança. Uma arquitetura Decision Layer absorve essa mudança. Uma arquitetura vendor-bound paga o custo de migração toda vez.

## Conclusão

A pergunta interessante para um CIO/CTO de empresa brasileira em 2026 não é "Mistral ou OpenAI". É "que porcentagem das minhas decisões agênticas precisa de raciocínio flagship, e como eu provo isso ao meu Encarregado de Dados (DPO), ao auditor independente e à ANPD".

Em um agente bem decomposto, Mistral Small 3.2 em uma única GPU faz a maior parte do trabalho por custo por token desprezível. Mistral Medium 3.1 em La Plateforme cobre a faixa média com soberania europeia preservada - relevante para multinacionais brasileiras com operação na UE. Claude Opus 4.7 ou GPT-5.5 atendem os casos genuinamente difíceis. O roteamento é a arquitetura. O audit trail é o artefato de compliance. A Decision Layer é o lugar onde tudo isso é especificado.

Outros publicam tabelas de comparação de modelo. A gente constrói a camada de roteamento que operacionaliza essas tabelas. O mercado de modelos muda mês a mês; a arquitetura de roteamento sobrevive a cinco gerações de modelo. O código-fonte fica com o cliente. Os modelos permanecem intercambiáveis. Conformidade com LGPD art. 20 e EU AI Act Art. 13 é uma propriedade da arquitetura, não um projeto no fim.

Se você quer saber como é a distribuição de complexidade real do seu agente, [agende uma conversa](/br/contato/).

--- Next.js sobre Supabase com segurança ---
> Runbook DevOps para Next.js sobre Supabase: arquitetura, middleware, padrões de autenticação, rate limiting e integração com Claude Code.

Depois que o Supabase como plataforma de backend está [rodando de forma estável](/br/revista/supabase-self-hosting/), o verdadeiro stack de aplicação é construído sobre ele.

Em muitos projetos modernos, o **Next.js** assume o papel da camada de aplicação:

- Frontend Rendering
- Server Side Rendering
- Server Actions
- Route Handlers
- API Proxy
- Session Handling

Com isso, o Next.js se torna efetivamente um **gateway de backend entre o navegador e o Supabase**.

O erro mais comum é tratar essa camada como "frontend", quando na verdade ela contém **lógica do lado do servidor com altos privilégios**.

Este runbook descreve como operar o Next.js com segurança sobre uma plataforma Supabase self-hosted.

Cada seção contém:

- Implementação
- Condição verificável
- Cenário de falha


<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Resumo - Artigo 2 de 6 da série DevOps Runbook</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Next.js como container separado isolado do Supabase</li>
<li>Chave service_role em apenas um arquivo</li>
<li>Middleware com getUser() em cada requisição</li>
<li>Verificação de ownership antes de mutações</li>
<li>Rate limiting em endpoints de autenticação</li>
</ul>
</div>

## Índice da série

Este guia faz parte da nossa série de runbooks DevOps para stacks de aplicações self-hosted.

1. [Supabase Self-Hosting Runbook](/br/revista/supabase-self-hosting/)
2. Next.js sobre Supabase com segurança - este artigo
3. [Supabase Edge Functions com segurança](/br/revista/supabase-edge-functions-seguranca/)
4. [Trigger.dev Background Jobs em produção segura](/br/revista/trigger-dev-background-jobs/)
5. [Claude Code como controle de segurança no workflow DevOps](/br/revista/claude-code-security-devops/)
6. [Security Baseline para todo o stack](/br/revista/security-baseline-stack/)

O artigo 1 descreve a base da plataforma. Este artigo descreve a **camada de aplicação acima dela**.

## Visão geral da arquitetura

```
Browser (Client)
     |
     | HTTPS
     |
Next.js App Layer
     |
     +-- @supabase/ssr
     |
     +-- service_role client
           (apenas contextos admin isolados)
     |
Supabase Platform Layer
     |
     +-- Kong API Gateway
     +-- GoTrue Auth
     +-- PostgREST API
     +-- Realtime
     |
PostgreSQL Data Layer
     |
     +-- Row Level Security
```

Regras fundamentais:

```
Browser    -> comunica apenas com Next.js
Next.js    -> comunica com Supabase
Supabase   -> controla acesso via RLS
```

Quando o navegador se comunica diretamente com vários serviços de backend, surgem fronteiras de segurança incontroláveis.

## Parte A - Decisões de arquitetura

Essas decisões raramente são alteradas e formam a base.

## A1 - Operar o Next.js como serviço próprio

### Implementação

O Next.js roda como seu próprio container.

```
services

nextjs-app
supabase-stack
postgres
```

Exemplo docker-compose:

```yaml
services:

  nextjs-app:
    build: ./app
    ports:
      - "3000:3000"
    environment:
      - NEXT_PUBLIC_SUPABASE_URL=http://kong:8000
      - NEXT_PUBLIC_SUPABASE_ANON_KEY=${ANON_KEY}
      - SUPABASE_SERVICE_ROLE_KEY=${SERVICE_ROLE_KEY}
    networks:
      - internal
```

O Next.js **não pode rodar dentro do stack do Supabase**.

### Condição verificável

```
docker ps --format '{{.Names}}'
```

Resultado esperado:

```
nextjs-app
supabase-kong
supabase-postgres
supabase-auth
```

### Cenário de falha

Quando o Next.js roda no mesmo container que o Supabase:

- O espaço de processos é compartilhado
- Os secrets ficam no mesmo environment
- Um servidor Next.js comprometido tem acesso direto a todos os serviços de backend

## A2 - O navegador comunica apenas com o Next.js

### Implementação

O navegador deve ver apenas uma URL pública.

```
https://app.example.com
```

Não permitido:

```
https://app.example.com:8000
https://app.example.com:5432
https://app.example.com:9000
```

Exemplo de firewall:

```
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -p tcp --dport 8000 -j DROP
iptables -A INPUT -p tcp --dport 5432 -j DROP
iptables -A INPUT -p tcp --dport 9000 -j DROP
```

### Condição verificável

```
nmap -p 443,3000,5432,8000,9000 app.example.com
```

Resultado esperado:

```
443 open
todos os outros filtered
```

### Cenário de falha

Quando o Supabase Studio está acessível publicamente:

- Acesso completo ao banco de dados
- Manipulação de schema
- Acesso aos Storage Buckets

## A3 - Configurar Security Headers

O Next.js funciona como gateway e precisa configurar HTTP Security Headers.

### Implementação

```
next.config.js
```

```javascript
const securityHeaders = [
  { key: "X-Frame-Options", value: "DENY" },
  { key: "X-Content-Type-Options", value: "nosniff" },
  { key: "Referrer-Policy", value: "strict-origin-when-cross-origin" },
  { key: "Permissions-Policy", value: "camera=(), microphone=()" },
  { key: "Strict-Transport-Security", value: "max-age=63072000; includeSubDomains" },
  {
    key: "Content-Security-Policy",
    value: "default-src 'self'; img-src 'self' data: blob:; frame-ancestors 'none'"
  }
]
```

### Condição verificável

```
curl -I https://app.example.com
```

Headers esperados:

```
X-Frame-Options
Content-Security-Policy
Strict-Transport-Security
```

### Cenário de falha

Sem CSP:

- Ataques XSS carregam scripts externos
- Tokens podem ser exfiltrados


### Variáveis de ambiente

| Variável | Visibilidade | Localização permitida | Risco de vazamento |
|---|---|---|---|
| NEXT_PUBLIC_SUPABASE_URL | Cliente | .env, código cliente | Baixo (URL pública) |
| NEXT_PUBLIC_SUPABASE_ANON_KEY | Cliente | .env, código cliente | Médio (limitado pelo RLS) |
| SUPABASE_SERVICE_ROLE_KEY | Apenas servidor | lib/supabase/admin.ts | Crítico (ignora RLS) |
| DATABASE_URL | Apenas servidor | .env (servidor) | Crítico (acesso direto ao DB) |
| TRIGGER_API_KEY | Apenas servidor | .env (servidor) | Alto (acesso à fila de tarefas) |

## Parte B - Verificações de implementação

Essas regras se aplicam a cada alteração de código.

## B1 - Separar variáveis de ambiente

Visíveis pelo cliente:

```
NEXT_PUBLIC_SUPABASE_URL
NEXT_PUBLIC_SUPABASE_ANON_KEY
```

Somente servidor:

```
SUPABASE_SERVICE_ROLE_KEY
DATABASE_URL
TRIGGER_API_KEY
```

### Condição verificável

```
grep -r "NEXT_PUBLIC_" .env*
```

Secrets não podem aparecer ali.

### Verificação de vazamento no build

```
grep -r "SERVICE_ROLE" .next/
```

Resultado esperado:

```
nenhum resultado
```

### Cenário de falha

`service_role` no bundle do cliente significa:

- Acesso completo ao banco de dados
- RLS completamente ineficaz

Quem conhece os [fundamentos da gestão de secrets](/br/revista/seguranca-dados-ia-enterprise/) entende por que essa separação é essencial.

## B2 - Configurar o Supabase SSR Client corretamente

Server Client:

```typescript
import { createServerClient } from "@supabase/ssr"
```

O servidor usa a **anon key**, não a service_role.

Admin Client:

```typescript
createClient(url, SERVICE_ROLE_KEY)
```

Apenas para tarefas administrativas.

### Condição verificável

```
grep -rn "SERVICE_ROLE" app/
```

Resultado esperado: apenas em

```
lib/supabase/admin.ts
```

### Cenário de falha

Server Client com service_role:

- O RLS é completamente ignorado
- Todos os requests têm privilégios de admin

## B3 - Middleware para Auth e Token Refresh

A middleware roda **antes de cada request**.

```
middleware.ts
```

### Implementação

```typescript
const { data: { user } } = await supabase.auth.getUser()
```

Não:

```
getSession()
```

### Condição verificável

```
grep getUser middleware.ts
```

### Cenário de falha

Sem middleware:

- O Token Refresh não funciona
- A sessão expira após 1 hora

## B4 - Padrão de mutação

Todas as mutações seguem o mesmo fluxo.

```
Auth
Input Validation
Ownership Check
Mutation
Logging
```

### Exemplo

```typescript
const { user } = await supabase.auth.getUser()

if (!user) return

const post = await supabase
  .from("posts")
  .select("user_id")
  .eq("id", postId)

if (post.user_id !== user.id)
  throw new Error("forbidden")
```

### Cenário de falha

Sem Ownership Check:

> **Estatística:** De acordo com pesquisas do GitHub de 2024, mais de 23% dos vazamentos de secrets em projetos web envolvem chaves service_role ou tokens de backend equivalentes.


```
deletePost(id)
```

Um usuário pode excluir dados de outros.

## B5 - Rate Limiting

O Next.js não possui Rate Limiting integrado.

Solução recomendada:

```
Upstash Redis
```

### Exemplo

```
10 requests / minute / IP
```

### Condição verificável

```
for i in {1..20}
do curl -X POST /api/login
done
```

Resultado esperado:

```
HTTP 429
```

## B6 - Logging sem secrets

Os logs não podem conter:

```
JWT Tokens
service_role keys
emails
passwords
```

### Condição verificável

```
grep console.log app/
```

## Parte C - Operação

## C1 - Atualização de dependências

Os releases do Next.js são frequentes.

Verificar semanalmente:

```
npm audit
npm outdated
```

Recomendado:

```
Renovate / Dependabot
```

## C2 - Integração com Claude Code

Arquitetura:

```
Git Push
   |
Checks determinísticos
   |
Relatório de segurança
   |
Análise do Claude
   |
Decisão DevOps
```

### Checks determinísticos

```
grep service_role
grep NEXT_PUBLIC
npm audit
```

### Análise do Claude

O Claude verifica:

- Novas Server Actions
- Novas API Routes
- Padrões de Ownership
- Input Validation
- Drift de arquitetura

O Claude **não executa alterações em produção**.

## Checklist de deployment

Verificar antes de cada deployment:

```
[ ] Next.js roda como serviço próprio
[ ] Portas do Supabase fechadas externamente
[ ] Security Headers ativos

[ ] Nenhum service_role no bundle do cliente
[ ] service_role apenas no Admin Client

[ ] middleware.ts presente
[ ] Server Actions verificam Auth
[ ] Ownership Checks implementados

[ ] Rate Limit de login ativo

[ ] npm audit sem achados críticos
```

## Conclusão

O Next.js em um stack moderno não é frontend, mas sim uma camada de servidor privilegiada.

A segurança surge através de três níveis:

```
Arquitetura
Verificações de implementação
Auditorias contínuas
```

A combinação de CI Security Checks e análise do Claude Code detecta tanto padrões conhecidos quanto novos riscos.

Quem segue esses princípios junto com uma [arquitetura Cert-Ready by Design](/br/revista/cert-ready-by-design/) constrói segurança verificável em vez de auditorias posteriores.

<div class="not-prose my-12 border border-gosign-border bg-gosign-light rounded-card p-6 lg:p-8">
<div class="flex items-start gap-4">
<div class="flex-shrink-0 w-12 h-12 bg-gosign-dark rounded-card flex items-center justify-center">
<svg width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="white" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 15v4a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2v-4"/><polyline points="7 10 12 15 17 10"/><line x1="12" y1="15" x2="12" y2="3"/></svg>
</div>
<div>
<h2 class="text-h3 font-bold text-gosign-dark mb-2" id="download-da-checklist-de-auditoria">Download da checklist de auditoria</h2>
<p class="text-body text-gosign-text mb-2">Prompt preparado para o Claude Code. Faça upload do arquivo no seu servidor e inicie o Claude Code no diretório do projeto da sua aplicação Next.js. O Claude Code verificará automaticamente todos os pontos de segurança deste runbook e reportará APROVADO, AVISO ou CRÍTICO.</p>
<p class="text-sm text-gosign-text mb-4 font-mono">claude -p "$(cat claude-check-artikel-2-nextjs-br.md)" --allowedTools Read,Grep,Glob,Bash</p>
<a href="/downloads/claude-check-artikel-2-nextjs-br.md" download class="inline-flex items-center px-6 py-3 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-small uppercase tracking-wider">Baixar checklist</a>
</div>
</div>
</div>

## Índice da série

1. [Supabase Self-Hosting Runbook](/br/revista/supabase-self-hosting/)
2. Next.js sobre Supabase com segurança - este artigo
3. [Supabase Edge Functions com segurança](/br/revista/supabase-edge-functions-seguranca/)
4. [Trigger.dev Background Jobs em produção segura](/br/revista/trigger-dev-background-jobs/)
5. [Claude Code como controle de segurança no workflow DevOps](/br/revista/claude-code-security-devops/)
6. [Security Baseline para todo o stack](/br/revista/security-baseline-stack/)

O próximo artigo descreve como **Supabase Edge Functions são utilizadas com segurança** - sem construir uma segunda arquitetura de backend.

--- O que são agentes de IA? Três tipos corporativos ---
> Agentes de IA são componentes especializados que executam tarefas empresariais de forma autônoma. Três tipos, diferenças para chatbots e RPA.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Resumo - Agentes de IA na empresa</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Agentes de IA são componentes de software especializados que executam tarefas de negócio de forma autônoma - diferente de chatbots (só respostas) ou RPA (só regras).</li>
<li>Três tipos: Document Agents (leitura e processamento de documentos), Workflow Agents (orquestração de processos entre sistemas), Knowledge Agents (respostas contextuais do conhecimento corporativo).</li>
<li>McKinsey (2024) estima que agentes de IA podem automatizar até 30% das horas de trabalho na maioria das ocupações até 2030.</li>
<li>O agente não é o modelo - o modelo de linguagem é intercambiável, o agente fornece lógica de negócio, integração de sistemas e governance.</li>
<li>A implantação corporativa exige um Decision Layer entre agente e sistema-alvo - para que cada decisão automatizada seja rastreável, auditável e conforme.</li>
</ul>
</div>

## O que é um agente de IA?

Um agente de IA é um componente de software especializado que, com base em grandes modelos de linguagem (LLMs), executa tarefas empresariais de forma autônoma. Diferentemente de um chatbot, que responde perguntas, um agente executa ações: lê um documento, avalia seu conteúdo, toma uma decisão e dispara uma ação em um sistema-alvo.

Agentes de IA no contexto corporativo não atuam livremente. Operam dentro de limites definidos: conjuntos de regras, escopos de validade, limiares de confiança, regras de escalação. Cada decisão do agente é transparente e auditável.

A base de um agente de IA é um modelo de linguagem - Claude, ChatGPT, Gemini, Llama, Mistral, DeepSeek ou gpt-oss. O modelo fornece a compreensão de linguagem. O agente fornece a lógica de negócio, a integração de sistemas e a governance.

## Delimitação: agente de IA vs. chatbot vs. RPA

Esses três conceitos são frequentemente confundidos. Eles resolvem problemas diferentes.

**Chatbot:** Um chatbot responde perguntas em linguagem natural. Não tem capacidade de ação. Quando um colaborador pergunta "Quantos dias de férias ainda tenho?", o chatbot responde. Não reserva férias, não verifica regras, não gera um Audit Trail.

**RPA (Robotic Process Automation):** RPA automatiza tarefas repetitivas baseadas em regras através de interfaces de usuário. Um bot de RPA navega pelo SAP, copia dados de A para B, preenche formulários. RPA não entende linguagem. Quando o formulário muda, o bot quebra.

**Agente de IA:** Um agente de IA entende contexto, interpreta dados não estruturados e toma decisões. Lê uma nota fiscal - independente do formato - compreende seu conteúdo, aplica conjuntos de regras e gera uma proposta de lançamento contábil. Quando o formato da nota muda, o agente continua funcionando porque entende o conteúdo, não reconhece o layout.

| Propriedade | Chatbot | RPA | Agente de IA |
|------------|---------|-----|----------|
| Compreensão de linguagem | Sim | Não | Sim |
| Capacidade de ação | Não | Sim (baseada em regras) | Sim (baseada em contexto) |
| Dados não estruturados | Sim | Não | Sim |
| Governance/Auditoria | Não | Parcialmente | Sim (via Decision Layer) |
| Integração de sistemas | Superficial | Via UI | Via API/Integration Layer |
| Adaptação a mudanças | Alterar prompt | Reprogramar bot | Agente aprende o contexto |

## Três tipos de agentes de IA na empresa

Na arquitetura da Gosign, existem três tipos de agentes. Cada tipo tem um escopo de tarefas definido e opera dentro dos limites estabelecidos pelo Decision Layer.

### Document Agents

Document Agents leem, compreendem e processam documentos. Notas fiscais, atestados médicos, contratos, certidões, comprovantes, notas de crédito.

A diferença fundamental em relação ao OCR ou reconhecimento de templates: Document Agents possuem verdadeira compreensão de linguagem. Não reconhecem campos em posições determinadas de uma página, mas entendem o conteúdo do documento. Uma nota fiscal em formato PDF, como imagem escaneada ou como anexo de e-mail - o Document Agent compreende as três formas.

Um Document Agent para processamento contábil lê uma nota fiscal de entrada e extrai: emissor, valor, descrição do serviço, data, alíquota de imposto, dados bancários. Gera um conjunto de dados estruturado que é transferido ao Decision Layer.

Document Agents não trabalham isolados. São o ponto de entrada de um workflow - após a leitura do documento, o Workflow Agent assume.

### Workflow Agents

Workflow Agents orquestram processos entre sistemas. Coordenam o fluxo entre Document Agent, Decision Layer e sistema-alvo.

Um Workflow Agent para processamento de notas fiscais coordena: o Document Agent lê a nota -> o Decision Layer verifica a proposta de lançamento -> com alta confiança, o lançamento vai para o sistema-alvo -> com baixa confiança, escala para o responsável -> após aprovação, o lançamento é finalizado -> todo o processo é documentado no Audit Trail.

Workflow Agents também lidam com exceções: O que acontece quando o sistema-alvo está indisponível? O que acontece em caso de timeout? O que acontece quando o responsável não responde? O Workflow Agent tem regras de escalação, mecanismos de retentativa e lógica de timeout.

A orquestração de workflow acontece via [Trigger.dev](https://trigger.dev/) ou [Camunda](https://camunda.com/) - dependendo da complexidade e dos requisitos de compliance do cliente. Workflows são visualizáveis, versionados e ajustáveis sem programação.

### Knowledge Agents

Knowledge Agents fornecem respostas contextuais a partir do conhecimento corporativo. Acordos coletivos, diretrizes, convenções coletivas de trabalho (CCT/ACT), regras de compliance, políticas internas.

A diferença em relação a uma função de busca: um Knowledge Agent entende a pergunta, busca no contexto relevante e entrega uma resposta com referência à fonte e versão da norma. Quando um responsável pergunta "O adicional noturno também se aplica a funcionários em meio período da convenção regional?", o Knowledge Agent entrega a resposta com referência ao acordo coletivo vigente em sua versão atual.

Knowledge Agents utilizam RAG (Retrieval Augmented Generation): o conhecimento corporativo é indexado em um banco de dados vetorial. O agente busca as passagens relevantes e gera uma resposta com base nessas fontes - não com base em seu treinamento.

Cada resposta contém: a fonte, a versão da norma, a data de validade. Sem alucinações, sem referências inventadas a regulamentos.

## Como os agentes de IA interagem na arquitetura corporativa

Os três tipos de agentes não funcionam isolados. Em uma implementação corporativa típica, o Workflow Agent orquestra o processo completo e delega para Document e Knowledge Agents especializados.

Um exemplo da administração de pessoal: Chega um atestado médico (e-mail com anexo PDF). O Document Agent lê o atestado e extrai: colaborador, período, certificado médico, certificado de continuação. O Knowledge Agent verifica: Quais regras se aplicam a este colaborador? No Brasil, a CLT e os acordos coletivos (CCT/ACT) (PT: Código do Trabalho e convenções coletivas); no contexto da empresa, os regulamentos internos e acordos individuais. O Decision Layer avalia: O afastamento está corretamente calculado? Os prazos estão corretos? O Workflow Agent coordena todo o fluxo e garante a atualização de todos os sistemas.

Cada agente tem seu escopo de tarefas definido. Nenhum agente "decide" sozinho sobre processos críticos de negócio. O [Decision Layer](/br/decision-layer/) fica entre o agente e o sistema-alvo e garante a governance.

## Agnosticismo de modelo: o agente não é o modelo

Uma confusão frequente: o agente não é o modelo de linguagem. O modelo (Claude, ChatGPT, Llama) fornece a compreensão de linguagem. O agente fornece a lógica de negócio, a integração de sistemas, a governance.

Na arquitetura da Gosign, a camada de modelo é intercambiável. Quando surge um novo modelo - mais potente, mais econômico, com melhor licença - ele pode ser integrado sem alterar as camadas superiores. A lógica de negócio no Decision Layer, os workflows, os conjuntos de regras permanecem inalterados.

Um agente pode utilizar vários modelos: um modelo open-source econômico para pré-classificação e um modelo mais potente para decisões complexas. O roteamento entre modelos é configurável.

Esse agnosticismo de modelo previne o vendor lock-in. Nenhuma empresa depende de um único fornecedor de modelos.

## Requisitos para agentes de IA nas empresas

Agentes de IA em ambientes corporativos precisam de mais do que um modelo de linguagem:

**Governance:** Cada decisão do agente deve ser transparente e auditável. O Decision Layer garante isso.

**Integração:** Os agentes devem se integrar aos sistemas existentes - SAP, [TOTVS](https://www.totvs.com/), [Workday](https://www.workday.com/), [SuccessFactors](https://www.sap.com/products/hcm.html), SharePoint. O Integration Layer desacopla a lógica do agente do sistema-alvo.

**Infraestrutura:** Os agentes precisam de um ambiente de execução: hosting de LLM, bancos de dados vetoriais para RAG, motor de workflow, API Gateway. Essa infraestrutura pode operar na nuvem, self-hosted ou em modo híbrido.

**Participação dos trabalhadores:** No Brasil, os sindicatos e, em empresas com mais de 200 empregados, a CRE (Comissão de Representantes dos Empregados) atuam na defesa dos interesses dos trabalhadores (PT: a Comissão de Trabalhadores tem competências de informação e consulta conforme o Código do Trabalho). A arquitetura deve considerar essas estruturas desde o início.

Mais informações: [AI Agents em detalhe](/br/servicos/ai-agents/)

<a href="/br/contato/" target="_blank" rel="noopener noreferrer">Agendar reunião</a> - Mostramos qual tipo de agente se encaixa no seu processo.

--- Orquestração de agentes: plataformas em comparativo 2026 ---
> Onde rodam seus agentes de IA? Trigger.dev, n8n, Camunda, Temporal, Make e Activepieces em comparativo enterprise. Com lógica de recomendação.

## Você sabe o que são agentes. Agora: Onde eles rodam?

Você já sabe o que são [agentes de IA](/br/revista/o-que-sao-agentes-ia/), como se comunicam com seus sistemas (MCP, A2A) e como você controla decisões ([Decision Layer](/br/revista/decision-layer-shadow-ai/)). A próxima pergunta e concreta: Em qual plataforma você orquestra esses agentes? Onde você define os workflows que conectam um modelo de linguagem aos seus processos de negocio?

A resposta depende de onde sua empresa esta: Você precisa de resultados rápidos com automatizacao visual de workflows, ou tem processos empresariais complexos e de longa duracao que exigem controle conforme BPMN e documentação pronta para auditoria?

Este artigo compara as seis plataformas mais relevantes, explica as duas abordagens fundamentalmente diferentes e oferece uma recomendação clara sobre quando cada plataforma e a escolha certa. Porque a plataforma de orquestração determina se sua arquitetura de agentes escala, ou se fica presa no Proof of Concept.

Gartner (2024) preve que ate 2028, 33% dos aplicativos de software empresarial incluirão IA agêntica, contra menos de 1% em 2024. A plataforma de orquestração que você escolher hoje determina se sua organização estará preparada para essa mudança.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Resumo - Plataformas de orquestração de agentes</p>
<ul class="text-body text-gosign-text space-y-2">
<li>O mercado se divide em ferramentas visuais de workflow (n8n, Make, Activepieces) para prototipação rápida e motores de orquestração de processos (Camunda, Temporal, Trigger.dev) para execução em produção.</li>
<li>Trigger.dev é a recomendação padrão: TypeScript-nativo, Durable Execution, licença Apache 2.0, auto-hospedável, produtivo em duas semanas.</li>
<li>Camunda complementa quando diagramas BPMN formais são exigidos por representantes dos trabalhadores ou auditores.</li>
<li>Cinco das seis plataformas suportam self-hosting - Make (apenas SaaS) é a exceção.</li>
<li>A escolha da plataforma é uma decisão arquitetônica que afeta governance, compliance e time-to-production.</li>
</ul>
</div>

## Dois mundos de orquestração

O mercado de orquestração de workflows em 2026 se divide em duas categorias que resolvem problemas diferentes. Compreender essa distinção e fundamental para a escolha correta de plataforma.

### Visual Workflow Automation

Plataformas como n8n, Make e Activepieces seguem o mesmo principio: workflows são construidos visualmente por cliques. Um trigger - um novo e-mail, um documento recebido, um webhook - inicia uma cadeia de ações. Cada ação e um no no workflow: ler dados, chamar um modelo de IA, enviar um e-mail, gravar um registro em um sistema ERP. A cadeia e montada no editor visual, testada e ativada.

A vantagem: Resultados rápidos, baixa barreira de entrada, utilizavel até por pessoas não técnicas. Um workflow de agente funcional pode estar de pe em dias em vez de semanas. Modelos de IA são integrados ao workflow como qualquer outro serviço - como um no entre muitos.

A desvantagem: Em processos complexos e de longa duracao com dezenas de pontos de decisão e aprovacoes humanas, as ferramentas visuais encontram seus limites. Caminhos paralelos, ramificacoes condicionais em multiplos níveis, processos que duram semanas e esperam por entradas humanas - essa não e a forca dos editores visuais.

### Process Orchestration Engines

Plataformas como Camunda e Temporal adotam uma abordagem diferente. No Camunda, processos são modelados como diagramas formais BPMN 2.0 - um padrão internacional que também pode ser lido por representantes dos trabalhadores (sindicatos/CRE (PT: Comissão de Trabalhadores) no Brasil, PT: Comissão de Trabalhadores), auditores e departamentos funcionais. No Temporal, workflows são escritos como código em Go, Java, TypeScript ou Python.

A vantagem comum: Cada etapa e versionada e auditável. Aprovacoes humanas (Human Tasks) são um componente central da arquitetura, não um workaround. Processos podem durar semanas ou meses sem perda de integridade técnica. Compliance de nível enterprise esta integrado nativamente.

A desvantagem: Maior barreira de entrada. Camunda exige conhecimento de BPMN e experiência com motores de processos. Temporal exige desenvolvedores que escrevam workflows em código. Para um prototipo rápido, isso costuma ser esforco demais.

A decisão entre esses dois mundos não e questao de melhor ou pior. E questao de maturidade, requisitos de compliance e prontidao organizacional.

## Plataformas em comparativo

A tabela a seguir confronta as seis plataformas mais relevantes. Considera tipo, capacidade de self-hosting, integração de IA, forca principal, adequacao enterprise e modelo de licença.

| Plataforma | Tipo | Self-Hosted | Integração AI/LLM | Forca | Adequacao enterprise | Licenca |
|---|---|---|---|---|---|---|
| **n8n** | Visual Workflow | Sim (Docker, k8s) | Nos AI nativos, integração LangChain | 400+ integracoes, editor visual, prototipos rápidos, comunidade ativa | Media-Alta | Fair Source (gratis <3 instancias) |
| **Camunda** | BPMN Process Engine | Sim (Self-Managed) ou Camunda Cloud | Conectores para APIs de LLM, Custom Worker para lógica de agente | BPMN 2.0, Human Tasks, Audit Trail, Compliance-ready, processos de longa duracao | Muito alta | Community Edition (Apache 2.0) + Enterprise Edition |
| **Make** (ex Integromat) | Visual Workflow | Não (apenas SaaS) | Modulos AI | Entrada mais simples, visualmente intuitivo, bom suporte | Baixa-Media | Proprietaria (SaaS) |
| **Temporal** | Code-first Orchestration | Sim (Docker, k8s) | Qualquer integração LLM no código Worker | Durable Execution, Retry/Timeout nativo, extremamente confiavel | Alta | MIT (Core) + Commercial (Cloud) |
| **Activepieces** | Visual Workflow | Sim (Docker) | AI-Pieces | Alternativa open-source ao n8n/Make, licença MIT | Media | MIT |
| **Trigger.dev** | Code-first (TypeScript) | Sim (Docker, k8s) | Qualquer LLM em código de tarefas | TypeScript-native, Durable Execution, Retry nativo, Developer-first | Alto | Apache 2.0 |

Tres observacoes da tabela:

**Self-hosting e possível em cinco das seis plataformas.** Make e a exceção: como serviço SaaS puro, seus dados de workflow deixam sua rede. Para empresas com requisitos de soberania de dados, Make fica descartada para workflows produtivos de agentes com dados sensiveis.

**A integração de IA e possível em todas as plataformas**, mas com profundidade diferente. n8n oferece nos AI nativos que integram modelos de linguagem diretamente no editor visual. Camunda e Temporal exigem mais trabalho de desenvolvimento, mas oferecem controle total sobre a interação com o modelo.

**Os modelos de licença diferem consideravelmente.** Activepieces (MIT) e Camunda Community Edition (Apache 2.0) oferecem a maior liberdade. n8n (Fair Source) e gratuito para setups pequenos, torna-se pago ao escalar. Temporal (MIT Core) e gratuito no nucleo, a variante cloud e paga.

## Quando cada plataforma?

### n8n: quando você quer comecar rápido

Precisa em duas semanas de um agente funcional que extraia notas fiscais de uma caixa de e-mail, classifique-as por um modelo de linguagem e lance-as no seu ERP? n8n e sua escolha.

O editor visual permite criar workflows sem programacao classica. Os nos de AI estao nativamente integrados - você pode incorporar um modelo de linguagem no workflow como qualquer outro serviço. Self-hosting com Docker significa: seus dados não deixam sua rede. A comunidade disponibiliza mais de 400 integracoes - de e-mail e calendario a sistemas CRM e bancos de dados.

Para o primeiro [agente de IA](/br/servicos/ai-agents/), n8n e em muitos casos a plataforma de partida adequada. O workflow fica pronto em dias, os resultados são imediatamente visiveis e o departamento funcional pode acompanhar o workflow no editor.

**O compromisso:** Workflows n8n funcionam bem para automatizacoes sequenciais e ramificacoes simples. Em processos com caminhos paralelos, loops de aprovacao humana de varios dias ou requisitos de compliance para versionamento e auditoria completa, fica apertado. n8n registra execucoes, mas não oferece modelagem BPMN nativa, definições de processos versionadas nem Human Tasks como conceito arquitetonico.

### Camunda: quando compliance não e negociavel

Seus representantes dos trabalhadores (sindicatos/CRE no Brasil, PT: Comissão de Trabalhadores) querem rastrear qual agente tomou qual decisão? Seus auditores precisam de um Audit Trail completo? O processo dura semanas - por exemplo onboarding, aprovacao de contratos, aprovacao de compras? Entao você precisa de um motor BPMN.

Camunda modela processos como diagramas formais (BPMN 2.0) que qualquer interlocutor de negocio pode ler - inclusive os representantes dos trabalhadores. Human Tasks são um conceito central: em pontos definidos, o processo espera a aprovacao humana. Cada decisão e versionada e rastreável. Agentes de IA são integrados como Service Tasks: o modelo de linguagem se torna uma etapa no processo de negocio, não uma caixa preta.

A Community Edition sob Apache 2.0 e totalmente auto-hospedavel. A Enterprise Edition oferece adicionalmente clustering, funções de monitoramento avancadas e suporte profissional. Para empresas que utilizam o [Decision Layer](/br/revista/decision-layer-shadow-ai/) como arquitetura de governance, Camunda e a escolha natural para a camada de execução: processos BPMN representam as micro-decisões, Human Tasks impoe aprovacoes humanas e o Audit Trail e gerado automaticamente.

### Temporal: quando seus desenvolvedores precisam de controle total

Temporal e code-first: workflows são escritos em Go, Java, TypeScript ou Python. Sem editor visual, mas com controle maximo sobre lógica de retentativa, timeouts e tratamento de erros.

Para agentes de IA que executam tarefas complexas e multietapa com duracoes imprevisiveis - análise de documentos com perguntas de acompanhamento, validacoes multietapa ou processamento em lote de grandes volumes de dados - Temporal e a opção mais robusta. O conceito de "Durable Execution" garante que workflows continuem mesmo em caso de quedas de servidores, interrupcoes de rede ou timeouts de modelos.

**O compromisso:** Temporal exige desenvolvedores que dominem workflow-as-code. Departamentos funcionais não conseguem ajustar workflows Temporal em um editor. Para empresas sem uma equipe de desenvolvimento forte, Temporal não e opção. Para empresas com desenvolvedores experientes que precisam de maxima confiabilidade em workflows complexos de agentes, e a melhor.

### Trigger.dev: o padrão emergente para orquestração de agentes

Trigger.dev se consolidou em 2025/2026 como uma das plataformas de orquestração de maior crescimento. O motivo: workflows são escritos em TypeScript - a linguagem que ja domina a maior parte do desenvolvimento web moderno. Sem editor visual, sem linguagem adicional. Quem ja tem TypeScript no stack, orquestra agentes na mesma linguagem, na mesma IDE, no mesmo sistema CI/CD.

A plataforma e utilizada por um numero crescente de organizações - de startups de IA a empresas SaaS e equipes enterprise que executam workflows de agentes em produção. A comunidade open-source ativa no GitHub, releases regulares e uma developer experience alinhada com padrões modernos tornam Trigger.dev a escolha natural para equipes que ja trabalham em TypeScript.

Durable Execution e integrado: cada tarefa sobrevive a falhas de servidor, problemas de rede e timeouts de modelos. A lógica de retry, timeouts e tratamento de erros são definidos em código, não configurados em uma interface. O histórico completo de execução e inspecionavel, cada passo e rastreavel. Isso torna Trigger.dev adequado não apenas para protótipos, mas para workflows produtivos - de classificação de e-mails a processamento de documentos e cadeias de agentes multietapa.

Self-hosting com Docker ou Kubernetes e totalmente suportado. A licença Apache 2.0 garante que não ha limites de uso. Sem dependências Java (como Temporal), sem overhead BPMN (como Camunda), sem editor visual que desacelera com a complexidade (como n8n).

**O compromisso:** Trigger.dev requer desenvolvedores TypeScript. Usuarios de negócios não podem modificar workflows em um editor. Para equipes Go ou Java, Temporal e a melhor escolha. Quando diagramas BPMN formais são exigidos por representantes dos trabalhadores ou auditores, Camunda complementa a arquitetura.

## Recomendação pratica: Trigger.dev como padrão, Camunda para requisitos BPMN

Trigger.dev e adequado como plataforma de orquestração principal - do primeiro agente à operação produtiva. Workflows baseados em TypeScript se integram diretamente ao processo de desenvolvimento existente: versionados no Git, testaveis no CI, implantaveis com as mesmas ferramentas do resto do stack. Um agente funcional em duas semanas convence a diretoria mais do que um conceito de arquitetura em dois meses.

Trigger.dev escala alem do primeiro use case. Durable Execution, históricos de execução completos e licença Apache 2.0 sem limites de instâncias tornam a plataforma adequada tambem para workflows enterprise produtivos. Muitas organizações executam toda sua orquestração de agentes no Trigger.dev - de classificação de e-mails a processamento de documentos e cadeias de agentes multietapa com dezenas de tarefas.

Camunda entra em cena quando diagramas BPMN formais são exigidos - tipicamente para processos que precisam ser legiveis para representantes dos trabalhadores, auditores ou revisores de compliance externos. Não porque Trigger.dev não esteja pronto para produção, mas porque BPMN e um formato de comunicação que também não-desenvolvedores entendem.

A distinção-chave: a capacidade de compliance não e questão da plataforma, mas da implementação. Audit Trail, [Decision Layer](/br/revista/decision-layer-shadow-ai/), Human-in-the-Loop e rastreabilidade completa podem ser construidos diretamente em workflows Trigger.dev - como codigo TypeScript versionado e testavel. Gosign implementa essa camada de governance por padrão em cada solução de agentes: cada decisão e registrada, cada aprovação humana documentada, cada passo do processo e rastreavel no Audit Trail. O unico motivo para Camunda não e o compliance tecnico - isso o Trigger.dev entrega - mas a legibilidade organizacional: representantes dos trabalhadores ou auditores podem ler um diagrama BPMN, mas não codigo TypeScript. Quando sua equipe de desenvolvimento ou um parceiro especializado como Gosign constroi a camada de compliance em codigo, Trigger.dev cobre todos os requisitos.

Ambas podem coexistir: Trigger.dev como padrão para todos os tipos de workflows de agentes - classificação de e-mails, extracao de dados, cadeias de agentes multietapa, automatizacoes internas. Camunda para os processos essenciais modelados em BPMN onde diagramas formais são um requisito de compliance: onboarding, aprovacao de contratos, autorização de compras. A separacao segue a pergunta: Este processo precisa existir como diagrama BPMN formal? Se sim, Camunda complementa. Se não, Trigger.dev.

Para empresas que apostam em alternativas com licença MIT, Activepieces e uma opção valida na area de workflows visuais. A plataforma oferece menos integracoes que n8n, mas a licença aberta elimina a questao de custos ao escalar.

## Integração com a arquitetura de agentes

A plataforma de orquestração não esta isolada. Ela e a camada de execução na [arquitetura de agentes](/br/revista/o-que-sao-agentes-ia/) que conecta todos os componentes. O diagrama a seguir mostra como as camadas interagem:

```
+-----------------------------------------+
|         Enterprise-AI-Portal            |
|  (LobeChat / OpenWebUI / LibreChat /    |
|   chatbot-ui / very-ai)                 |
+------------------+----------------------+
|
+------------------v----------------------+
|     Plataforma de orquestração          |
|  (Trigger.dev / Camunda / Temporal)     |
|                                         |
|  +-----+  +---------+  +------------+  |
|  |Etapa|->| LLM     |->| Decision   |->|
|  |  1  |  | Análise |  | Layer      |  |
|  +-----+  +---------+  +------------+  |
+------------------+----------------------+
|
+--------------+---------------+
v              v               v
+--------+  +----------+  +----------+
|  RAG / |  |  ERP /   |  | E-Mail / |
| Vetor  |  |  CRM     |  |Calendario|
|   DB   |  |          |  |          |
+--------+  +----------+  +----------+
```

Cada camada tem uma tarefa definida:

- O **[Enterprise-AI-Portal](/br/revista/enterprise-ai-chat-interface/)** e a interface pela qual os usuarios iniciam agentes e consultam resultados. Os colaboradores não interagem diretamente com a plataforma de orquestração - utilizam o portal. A conexão e particularmente fluida quando o portal inclui integração nativa de workflows. very-ai pode disparar workflows Trigger.dev diretamente do chat - o usuario digita uma solicitação, o agente analisa e Trigger.dev executa o processo subsequente. Com outros portais, essa conexão precisa ser estabelecida via webhooks ou middleware API.
- A **plataforma de orquestração** (este artigo) define o workflow: quais etapas em qual ordem, quais condições se aplicam e o que acontece em caso de erros. E a central de execução dos agentes.
- O **modelo de IA** realiza a análise: compreender texto, extrair documentos, preparar decisões. Em uma arquitetura agnostica de modelo, o modelo adequado e selecionado por etapa.
- O **[Decision Layer](/br/revista/decision-layer-shadow-ai/)** controla em cada ponto de decisão se a IA pode agir autonomamente, se um conjunto de regras se aplica ou se uma pessoa precisa aprovar.
- **RAG** fornece ao modelo o contexto dos seus documentos corporativos: contratos, diretrizes, manuais.

A plataforma de orquestração conecta esses componentes em um workflow funcional. Sem ela, os componentes individuais ficam isolados: um modelo de linguagem que pode analisar documentos, mas ninguem definiu o que acontece depois. Um pipeline RAG que encontra trechos relevantes, mas nenhum workflow leva os resultados adiante. Um Decision Layer que define regras, mas nenhum sistema as executa.

A escolha da plataforma determina quao bem essa integração funciona. Trigger.dev torna a integração acessivel como código: workflows são arquivos TypeScript no seu repositório. Camunda torna a integração formalmente rastreavel: você ve o processo como diagrama BPMN. n8n torna a integração visualmente acessivel para não-desenvolvedores.

## Modelos de licença em detalhe

Para decisores enterprise, a questao da licença não e trivial. As diferencas tem impacto direto em custos, escalabilidade e dependência de fornecedor.

**n8n (Fair Source):** O código-fonte e acessivel e auto-hospedavel. Para até tres instâncias, o uso e gratuito. A partir da quarta instância, e necessária uma licença Enterprise. Para empresas que comecam com um único setup n8n, não e um obstaculo. Ao escalar para multiplas equipes ou unidades, surgem custos de licença.

**Camunda (Apache 2.0 + Enterprise):** A Community Edition e completamente open source sob Apache 2.0, sem restrições. A Enterprise Edition oferece clustering, observabilidade avancada e suporte profissional. Para comecar, a Community Edition e suficiente. Para uso enterprise produtivo com alta disponibilidade, recomenda-se a Enterprise Edition.

**Temporal (MIT + Commercial):** O servidor Core esta licenciado sob MIT, totalmente livre. A variante cloud (Temporal Cloud) e um serviço comercial. Para self-hosting não e necessário contrato de licença. Para empresas que não querem assumir a operação, Temporal Cloud oferece uma alternativa gerenciada.

**Activepieces (MIT):** Completamente open source sob licença MIT. Sem restrições, sem limites de uso. A opção menos restritiva. Em contrapartida, um ecossistema menor e menos integracoes que n8n.

**Trigger.dev (Apache 2.0):** Completamente open source sob Apache 2.0. Self-hosting sem restrições, sem limites de uso, sem limites de instâncias. A licença mais aberta junto com Activepieces, com a vantagem de uma comunidade ativa de desenvolvedores e releases regulares.

**Make (proprietaria):** Modelo SaaS puro. Sem self-hosting, sem acesso ao código. Para ambientes enterprise com requisitos de soberania de dados, não e adequada. Para automatizacoes rapidas e não sensiveis, uma opção valida se os dados podem deixar a rede corporativa.

## Checklist: Qual plataforma se encaixa no seu cenario?

A lógica de decisão a seguir ajuda na primeira orientação:

**Cenario 1: Workflows de agentes em TypeScript, do primeiro use case à produção**
Recomendação: Trigger.dev. Workflows baseados em TypeScript, Durable Execution, produtivo em duas semanas. Self-hosting com Docker. Código no Git, testavel no CI. Escala do primeiro agente a dezenas de workflows produtivos.

**Cenario 2: Processos que exigem compliance, comite de trabalhadores, requisitos de auditoria**
Recomendação: Camunda. BPMN 2.0, Human Tasks, processos versionados, Audit Trail completo. Community Edition sob Apache 2.0 para comecar, Enterprise Edition para produção.

**Cenario 3: Workflows complexos e de longa duracao com tempos de execução imprevisiveis**
Recomendação: Temporal. Code-first, controle maximo, Durable Execution. Exige conhecimento de desenvolvimento.

**Cenario 4: Ambos - automatizacoes rapidas e processos auditados essenciais**
Recomendação: Trigger.dev e Camunda em paralelo. Trigger.dev para automatizacoes internas, Camunda para processos que exigem compliance. Comunicação via APIs e webhooks.

**Cenario 5: Licenca MIT sem compromissos**
Recomendação: Activepieces para workflows visuais, Temporal Core para workflows code-first.

## Proximos passos

A plataforma de orquestração e um meio, não um fim em si. A plataforma certa sozinha não cria um agente funcional. Para isso você precisa da [infraestrutura](/br/servicos/infraestrutura/) completa: modelos de IA, hosting, um portal Enterprise-AI como interface e uma arquitetura de governance que garanta o compliance.

Gosign usa Trigger.dev como plataforma primaria de orquestração e apoia na seleção e implementação da arquitetura adequada - da avaliação ao primeiro PoC até a operação produtiva. Agnostico de modelo, com acesso completo ao código-fonte.

---

**Qual processo deveria ser assumido pelo seu primeiro agente?**

<a href="/br/contato/" target="_blank" rel="noopener noreferrer">Agendar reunião</a>. 30 minutos em que identificamos o primeiro use case adequado e a plataforma de orquestração certa para sua empresa.

--- Anonimização de PII para IA Empresarial ---
> Como processar documentos com dados pessoais em conformidade com a LGPD usando IA. Pseudonimização roundtrip, Decision Layer, Audit Trail.

## Por que dados pessoais são um problema para o processamento com IA

Quando um agente de IA analisa um contrato de trabalho, verifica uma folha de pagamento ou processa um atestado médico, ele opera com dados pessoais. Nome, endereço, data de nascimento, CPF (PT: NIF), salário, diagnóstico.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Resumo - Anonimização de PII para IA Empresarial</p>
<ul class="text-body text-gosign-text space-y-2">
<li>A pseudonimização roundtrip substitui PII por pseudônimos consistentes antes do processamento pelo LLM, e reinsere os dados reais na saída.</li>
<li>O Decision Layer governa quais categorias de PII são detectadas por processo (RH, finanças, compliance) por meio de conjuntos de regras versionados.</li>
<li>A pseudonimização preserva a estrutura e o contexto do documento - ao contrário do mascaramento, que torna documentos inúteis para análise por IA.</li>
<li>O Confidence Routing escala entidades ambíguas para um humano; identificadores implícitos requerem regras de contexto no conjunto de regras.</li>
<li>IAPP (2024) constata que 58% das organizações que processam documentos com IA não possuem detecção sistemática de PII, expondo-se ao risco de aplicação da LGPD (PT: RGPD).</li>
</ul>
</div>

Enviar esses dados a um modelo de linguagem, mesmo a um modelo auto-hospedado, cria risco de conformidade com a LGPD (PT: RGPD). A legislação exige [minimização de dados](/br/governance/data-residency/) (art. 6o da LGPD / art. 5.1.c do RGPD): somente os dados necessários para a finalidade podem ser processados. Para classificar um tipo de documento, o modelo não precisa do nome do colaborador. Para verificar a conformidade com a faixa salarial, não precisa da data de nascimento.

Porém, o modelo precisa de contexto. Um contrato sem nenhuma informação pessoal é inútil para a análise de IA, faltam as referências, as relações e as conexões.

A solução não é o mascaramento, mas a pseudonimização.

## Pseudonimizacao roundtrip: o principio

A pseudonimizacao roundtrip e um processo em tres etapas:

**Passo 1: Detectar e substituir.** A camada de pre-processamento identifica todos os dados pessoais no documento. Cada instância de PII e substituida por um pseudonimo consistente: "Joao Silva" se torna "Pessoa_A", "R$ 15.000" se torna "Salario_A", "Rua Augusta 100" se torna "Endereco_A". O ponto essencial: os pseudonimos são consistentes. Se "Joao Silva" aparece novamente na página 3, ele contínua sendo "Pessoa_A". Isso preserva a estrutura do documento.

**Passo 2: Processar.** O documento pseudonimizado e enviado ao modelo de linguagem. O modelo ve: "Pessoa_A tem Salario_A em Endereco_A. O contrato vigora até 2027." Ele pode realizar a análise contratual, a verificação de faixa salarial, a classificação de clausulas, sem jamais ter visto um nome ou salario real.

**Passo 3: Re-anonimizar.** A saida do modelo contem pseudonimos: "Pessoa_A esta dentro da faixa salarial E3." A camada de re-anonimizacao substitui os pseudonimos pelos dados reais: "Joao Silva esta dentro da faixa salarial E3." A tabela de correspondencia e excluida apos o processamento.

## O que o Decision Layer controla

Nem todo campo de dados requer pseudonimizacao. O Decision Layer define quais categorias de PII são detectadas e substituidas, governado por conjuntos de regras versionados:

Para um processo de RH: pseudonimizar nomes, salarios, enderecos, CPFs (PT: NIFs). Cargos e departamentos podem permanecer, são relevantes para a análise e não constituem dados pessoais.

Para um processo financeiro: nomes de empresas permanecem, pessoas de contato são pseudonimizadas, valores permanecem (são necessarios para decisoes contabeis), dados bancarios são pseudonimizados.

Para um processo de compliance: pseudonimizar tudo, incluindo nomes de empresas, se a análise deve ser transversal.

Essas regras são específicas por mandante e versionadas. Quando um acordo coletivo (PT: acordo de empresa) muda, uma nova versão de regras e criada. Em uma auditoria, e rastreável qual regra de PII, em qual versão, estava vigente no momento do processamento.

## Limitacoes e avaliação honesta

A deteccao de PII não e perfeita. O reconhecimento de entidades nomeadas (NER) comete erros, especialmente com:

Nomes ambiguos: "Santos" pode ser um sobrenome ou uma cidade. "Salvador" pode ser uma cidade ou um nome próprio. O Decision Layer aborda isso por meio de Confidence Routing: com alta confiança, a pseudonimizacao e automática. Com baixa confiança, a questao e escalada para um ser humano.

Identificadores implicitos: "A única desenvolvedora no escritorio de Curitiba" não contem PII explicita, mas identifica uma pessoa. Esses identificadores indiretos são dificeis de detectar automaticamente. A abordagem: regras de contexto no conjunto de regras definem quais combinacoes de atributos permitem a identificação.

Novos tipos de documentos: quando um novo tipo de documento entra no processamento, o conjunto de regras de PII deve ser revisado e possivelmente ampliado. Isso não é uma configuração única, mas um processo contínuo.

| Categoria PII | Processo RH | Processo financeiro | Processo compliance |
|---|---|---|---|
| Nomes | Pseudonimizados | Contatos pseudonimizados | Tudo pseudonimizado |
| Salários / Valores | Pseudonimizados | Permanecem (decisões contábeis) | Pseudonimizados |
| Endereços | Pseudonimizados | Permanecem | Pseudonimizados |
| Números de identificação (CPF) | Pseudonimizados | Pseudonimizados | Pseudonimizados |
| Nomes de empresas | Permanecem | Permanecem | Pseudonimizados |
| Cargos | Permanecem | Permanecem | Conforme contexto |
| Dados bancários | Pseudonimizados | Pseudonimizados | Pseudonimizados |

Mais sobre Document Intelligence: [Document Intelligence - PII, redação de contratos, detecção de assinaturas](/br/servicos/document-intelligence/)

<a href="/br/contato/" target="_blank" rel="noopener noreferrer">Agendar reunião</a> - Demonstramos a pseudonimizacao roundtrip com seus documentos.

--- Por que não treinamos mais agentes AI ---
> 92% de precisão sem treinamento. O EU AI Act exige decisões individuais explicáveis para sistemas de alto risco (prazo: 2 de agosto de 2026, adiamento para dezembro de 2027 acordado provisoriamente). Modelos treinados não conseguem isso.

## Treinamento é o novo fax

Em 2019, precisávamos treinar modelos AI. Eram limitados demais para qualquer outra coisa. O GPT-2 não conseguia escrever um parágrafo coerente. O BERT precisava de milhares de exemplos rotulados para cada tarefa e de um cluster GPU por dias.

Isso foi há seis anos. Seis anos em que as capacidades dos modelos de linguagem melhoraram em ordens de grandeza. Mas o setor continua agindo como se "treinar" fosse o primeiro passo natural.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Visão geral - Por que treinamento é a arquitetura errada</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Um LLM alcança 92% de decisões corretas na verificação de faturas - sem um único exemplo de treinamento. Juristas experientes alcançam 72%.<sup>[1]</sup></li>
<li>O EU AI Act (Art. 13, 14, 86) exige decisões individuais explicáveis para sistemas de alto risco - obrigações com prazo vigente de 2 de agosto de 2026, com adiamento para dezembro de 2027 acordado provisoriamente (Digital Omnibus, maio de 2026). No Brasil, o PL 2338/2023 prevê obrigações semelhantes. Modelos treinados não conseguem cumprir isso.<sup>[10]</sup></li>
<li>A alternativa: conjunto de regras (versionado), contexto (por decisão), Decision Layer (pessoa/regra/AI por Micro-Decision).</li>
<li>Agentes configurados são modelo-agnósticos: troca de modelo Foundation sem alterar o conjunto de regras. Sem lock-in, sem retreinamento.</li>
<li>Mais de 40% dos projetos de Agentic AI fracassarão até 2027 - principalmente por falta de governance, não por falta de desempenho do modelo.<sup>[9]</sup></li>
</ul>
</div>

Se alguém em 2026 diz "Treinamos nossos agentes AI", é como dizer em 2010 "Enviamos nossos pedidos por fax". Funciona. Mas mostra que não se entendeu a arquitetura.

<!-- Timeline: De treinamento a configuração -->
<div class="not-prose my-12">
<div class="bg-gosign-dark rounded-card p-6 sm:p-8">
<p class="text-h3 font-bold text-white mb-6">De treinamento a configuração</p>
<div class="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-4 gap-4">

<div class="border border-white/10 rounded-lg p-4 bg-white/5">
<p class="text-gosign-text-on-dark text-xs uppercase tracking-wider mb-1">2018 - 2020</p>
<p class="text-white font-bold text-lg mb-2">Treinamento é obrigatório</p>
<p class="text-gosign-text-on-dark text-sm mb-3">BERT, GPT-2. 110M - 1,5B parâmetros.</p>
<div class="space-y-1 text-xs text-gosign-text-on-dark">
<p>Duração: semanas</p>
<p>Custo: $10 000 - $100 000</p>
<p>Requisito: cluster GPU</p>
</div>
</div>

<div class="border border-white/10 rounded-lg p-4 bg-white/5">
<p class="text-gosign-text-on-dark text-xs uppercase tracking-wider mb-1">2021 - 2023</p>
<p class="text-white font-bold text-lg mb-2">Treinamento se torna opcional</p>
<p class="text-gosign-text-on-dark text-sm mb-3">GPT-3/3.5. 175B parâmetros.</p>
<div class="space-y-1 text-xs text-gosign-text-on-dark">
<p>Duração: dias</p>
<p>Custo: $1000 - $10 000</p>
<p>Requisito: GPU necessária</p>
</div>
</div>

<div class="border border-white/10 rounded-lg p-4 bg-white/5">
<p class="text-gosign-text-on-dark text-xs uppercase tracking-wider mb-1">2024</p>
<p class="text-white font-bold text-lg mb-2">Treinamento ou prompting?</p>
<p class="text-gosign-text-on-dark text-sm mb-3">GPT-4o, Claude 3.5. Multimodal.</p>
<div class="space-y-1 text-xs text-gosign-text-on-dark">
<p>Duração: horas</p>
<p>Custo: $10 - $100</p>
<p>Requisito: API-Call</p>
</div>
</div>

<div class="border border-gosign-accent rounded-lg p-4 bg-gosign-accent/10">
<p class="text-gosign-accent-on-dark text-xs uppercase tracking-wider mb-1">2025 - 2026</p>
<p class="text-white font-bold text-lg mb-2">Configuração é suficiente</p>
<p class="text-gosign-text-on-dark text-sm mb-3">GPT-5.5, Claude Opus 4.7. Reasoning.</p>
<div class="space-y-1 text-xs text-gosign-text-on-dark">
<p>Duração: minutos</p>
<p>Custo: $10 - $100</p>
<p>Requisito: API-Call</p>
</div>
</div>

</div>
</div>
</div>

Kumar Gauraw resume com precisão: "A maioria recorre ao Fine-Tuning cedo demais."<sup>[5]</sup> Não porque o Fine-Tuning seja ruim. Mas porque em 2026 já não é necessário para a maioria das tarefas enterprise.

## O que um modelo treinado não consegue: explicar uma decisão individual

Um candidato é rejeitado pelo seu agente de recrutamento. Ele pergunta: por quê?

Duas respostas. Duas arquiteturas.

**Modelo treinado:** "Nosso modelo aprendeu com base em 50 000 decisões históricas de contratação que seu perfil tem uma probabilidade de sucesso de 34%."

**Agente configurado:** "Sua qualificação em engenharia mecânica não atende o requisito 3 (eletrotécnica ou equivalente). Regra: perfil do cargo v2026-03. Contestável: sim. Processo: o departamento técnico avalia se engenharia mecânica se qualifica como 'equivalente'."

A primeira resposta não atende às obrigações de alto risco do EU AI Act - pela legislação vigente exigíveis a partir de 2 de agosto de 2026, com adiamento para dezembro de 2027 acordado provisoriamente (Digital Omnibus, maio de 2026; adoção formal ainda pendente).

EU AI Act, Art. 13 (transparência), Art. 14 (supervisão humana), Art. 86 (direito à explicação).<sup>[10]</sup> Para sistemas de alto risco - e recrutamento é alto risco, Anexo III(4) - cada decisão individual deve ser compreensível, explicável e contestável. No Brasil, o PL 2338/2023 prevê obrigações análogas para sistemas de inteligência artificial de alto risco.

Não o modelo. A decisão individual. Para este candidato. Com esta fundamentação.

Um modelo treinado não consegue fazer isso. Não tem registro de decisão. Tem pesos. E pesos não explicam nada à CIPA ou ao sindicato.

### O teste de compliance: treinado vs. configurado

<!-- Comparação em duas colunas: Treinado vs. Configurado -->
<div class="not-prose my-10">
<div class="bg-gosign-dark rounded-card overflow-hidden">
<div class="grid grid-cols-1 md:grid-cols-2">

<!-- Coluna esquerda: Treinado -->
<div class="p-6 sm:p-8 border-b md:border-b-0 md:border-r border-white/10">
<p class="text-gosign-text-on-dark text-xs uppercase tracking-wider mb-1">Arquitetura A</p>
<p class="text-white font-bold text-xl mb-6">Modelo treinado</p>

<div class="space-y-5">
<div>
<p class="text-gosign-text-on-dark text-sm mb-1">"Por que esta decisão?"</p>
<p class="text-white text-sm">"O modelo aprendeu" - Black Box</p>
<p class="text-red-400 text-xs mt-1">Não explicável</p>
</div>

<div>
<p class="text-gosign-text-on-dark text-sm mb-1">"Mudança na legislação?"</p>
<p class="text-white text-sm">Retreinamento. 2 - 4 semanas, $5000 - $20 000</p>
<p class="text-red-400 text-xs mt-1">Caro e lento</p>
</div>

<div>
<p class="text-gosign-text-on-dark text-sm mb-1">"O afetado pode contestar?"</p>
<p class="text-white text-sm">Contra o quê? Contra pesos?</p>
<p class="text-red-400 text-xs mt-1">Não contestável</p>
</div>

<div>
<p class="text-gosign-text-on-dark text-sm mb-1">"Novo modelo LLM disponível?"</p>
<p class="text-white text-sm">Novo treinamento necessário. Semanas, lock-in.</p>
<p class="text-red-400 text-xs mt-1">Dependência do fornecedor</p>
</div>

<div>
<p class="text-gosign-text-on-dark text-sm mb-1">"Conforme ao EU AI Act?"</p>
<p class="text-white text-sm">Art. 13: falta transparência. Art. 14: intervenção = substituir modelo. Art. 86: explicação não possível.</p>
<p class="text-red-400 text-xs mt-1">Problemático</p>
</div>

<div class="pt-4 border-t border-white/10">
<p class="text-red-400 font-bold text-sm">Lock-in: sim | Auditoria: difícil | EU AI Act: problemático</p>
</div>
</div>
</div>

<!-- Coluna direita: Configurado -->
<div class="p-6 sm:p-8">
<p class="text-gosign-accent-on-dark text-xs uppercase tracking-wider mb-1">Arquitetura B</p>
<p class="text-white font-bold text-xl mb-6">Agente configurado</p>

<div class="space-y-5">
<div>
<p class="text-gosign-text-on-dark text-sm mb-1">"Por que esta decisão?"</p>
<p class="text-white text-sm">"§9 EStG v2026-01, ausência 14h15min" (lei fiscal alemã - regras análogas em cada jurisdição)</p>
<p class="text-green-400 text-xs mt-1">Regra, versão, contexto documentados</p>
</div>

<div>
<p class="text-gosign-text-on-dark text-sm mb-1">"Mudança na legislação?"</p>
<p class="text-white text-sm">Atualizar regra. Efeito imediato, $0.</p>
<p class="text-green-400 text-xs mt-1">Versionado e auditável</p>
</div>

<div>
<p class="text-gosign-text-on-dark text-sm mb-1">"O afetado pode contestar?"</p>
<p class="text-white text-sm">"O café da manhã não estava incluído." O responsável verifica.</p>
<p class="text-green-400 text-xs mt-1">Contestável com registro de decisão</p>
</div>

<div>
<p class="text-gosign-text-on-dark text-sm mb-1">"Novo modelo LLM disponível?"</p>
<p class="text-white text-sm">O conjunto de regras permanece. 0 esforço, sem lock-in.</p>
<p class="text-green-400 text-xs mt-1">Modelo-agnóstico</p>
</div>

<div>
<p class="text-gosign-text-on-dark text-sm mb-1">"Conforme ao EU AI Act?"</p>
<p class="text-white text-sm">Registro de decisão por Micro-Decision. Sobrescrever regra, não substituir modelo.</p>
<p class="text-green-400 text-xs mt-1">Conforme by Design</p>
</div>

<div class="pt-4 border-t border-white/10">
<p class="text-green-400 font-bold text-sm">Lock-in: não | Auditoria: by Design | EU AI Act: conforme</p>
</div>
</div>
</div>

</div>
</div>
</div>

O problema de compliance é apenas a superfície. Por baixo, há um problema de arquitetura.

## 92% vs. 72%

Pesquisadores testaram em 2025 quão bem um LLM consegue verificar faturas jurídicas contra Billing Guidelines.<sup>[1]</sup> Sem Fine-Tuning. Sem treinamento. Apenas o conjunto de regras como contexto.

O resultado:

<!-- 92% vs. 72% comparação de barras -->
<div class="not-prose my-10">
<div class="bg-gosign-dark rounded-card p-6 sm:p-8 text-white">
<p class="text-h3 font-bold mb-6">Fatura jurídica: conforme às regras ou não?</p>
<p class="text-gosign-text-on-dark text-sm mb-8">Better Bill GPT, Whitehouse et al. (abril 2025). Peer-reviewed. O LLM recebeu o conjunto de regras como contexto, sem Fine-Tuning.<sup>[1]</sup></p>

<!-- Precisão geral -->
<div class="mb-8">
<p class="text-gosign-text-on-dark text-xs uppercase tracking-wider mb-3">Precisão geral</p>

<div class="mb-4">
<div class="flex justify-between items-center mb-1">
<p class="text-sm font-medium">LLM (sem treinamento)</p>
<p class="text-gosign-accent-on-dark font-bold text-lg">92%</p>
</div>
<div class="w-full bg-white/10 rounded-full h-4">
<div class="bg-gosign-accent rounded-full h-4" style="width: 92%"></div>
</div>
</div>

<div class="mb-4">
<div class="flex justify-between items-center mb-1">
<p class="text-sm font-medium">Juristas experientes</p>
<p class="text-gosign-text-on-dark font-bold text-lg">72%</p>
</div>
<div class="w-full bg-white/10 rounded-full h-4">
<div class="bg-white/30 rounded-full h-4" style="width: 72%"></div>
</div>
</div>
</div>

<!-- F-Score itens individuais -->
<div class="mb-8">
<p class="text-gosign-text-on-dark text-xs uppercase tracking-wider mb-3">Classificação de itens individuais (F-Score)</p>

<div class="mb-4">
<div class="flex justify-between items-center mb-1">
<p class="text-sm font-medium">LLM (sem treinamento)</p>
<p class="text-gosign-accent-on-dark font-bold text-lg">81%</p>
</div>
<div class="w-full bg-white/10 rounded-full h-4">
<div class="bg-gosign-accent rounded-full h-4" style="width: 81%"></div>
</div>
</div>

<div class="mb-4">
<div class="flex justify-between items-center mb-1">
<p class="text-sm font-medium">Melhor grupo humano</p>
<p class="text-gosign-text-on-dark font-bold text-lg">43%</p>
</div>
<div class="w-full bg-white/10 rounded-full h-4">
<div class="bg-white/30 rounded-full h-4" style="width: 43%"></div>
</div>
</div>
</div>

<!-- Tempo e custos -->
<div class="grid grid-cols-1 sm:grid-cols-2 gap-6">

<div>
<p class="text-gosign-text-on-dark text-xs uppercase tracking-wider mb-3">Tempo por fatura</p>
<div class="mb-3">
<div class="flex justify-between items-center mb-1">
<p class="text-sm font-medium">LLM</p>
<p class="text-gosign-accent-on-dark font-bold">3,6 seg.</p>
</div>
<div class="w-full bg-white/10 rounded-full h-3">
<div class="bg-gosign-accent rounded-full h-3" style="width: 1.4%"></div>
</div>
</div>
<div>
<div class="flex justify-between items-center mb-1">
<p class="text-sm font-medium">Juristas</p>
<p class="text-gosign-text-on-dark font-bold">~250 seg.</p>
</div>
<div class="w-full bg-white/10 rounded-full h-3">
<div class="bg-white/30 rounded-full h-3" style="width: 100%"></div>
</div>
</div>
</div>

<div>
<p class="text-gosign-text-on-dark text-xs uppercase tracking-wider mb-3">Custo por fatura</p>
<div class="mb-3">
<div class="flex justify-between items-center mb-1">
<p class="text-sm font-medium">LLM</p>
<p class="text-gosign-accent-on-dark font-bold">&lt; $0,01</p>
</div>
<div class="w-full bg-white/10 rounded-full h-3">
<div class="bg-gosign-accent rounded-full h-3" style="width: 0.2%"></div>
</div>
</div>
<div>
<div class="flex justify-between items-center mb-1">
<p class="text-sm font-medium">Juristas</p>
<p class="text-gosign-text-on-dark font-bold">$4,27</p>
</div>
<div class="w-full bg-white/10 rounded-full h-3">
<div class="bg-white/30 rounded-full h-3" style="width: 100%"></div>
</div>
</div>
</div>

</div>

<p class="text-gosign-text-on-dark text-xs mt-6 border-t border-white/10 pt-4">Redução de custos: 99,97%.<sup>[4]</sup> Mecanismo transferível para qualquer tarefa de compliance baseada em regras.</p>
</div>
</div>

O LLM não foi treinado em faturas. Recebeu as Billing Guidelines como contexto. E decidiu na hora.

### Por que o LLM foi melhor

Não porque é mais inteligente. Mas porque às 15h aplica a mesma regra da mesma forma que às 9h. Inconsistência é o problema do ser humano, não incompetência.<sup>[1]</sup>

Juristas experientes tomam 72% de decisões corretas - mas cada jurista comete erros diferentes. Os erros não são sistemáticos, e sim aleatórios. Fadiga, pressão de tempo, interpretação pessoal. Um LLM não conhece fadiga.

### O mecanismo transferível

Seja o conjunto de regras chamado "Billing Guideline", "§14 UStG" ou "Diárias de viagem 2026": verificar documento contra regra, identificar desvio, documentar decisão. O mecanismo é idêntico.

<!-- Tabela resumo: aplicação do conjunto de regras -->
<div class="not-prose my-8">
<div class="overflow-x-auto">
<table class="w-full border-collapse text-sm">
<thead>
<tr class="bg-gosign-dark text-white">
<th class="p-3 text-left font-bold">Dimensão</th>
<th class="p-3 text-left font-bold">Modelo treinado</th>
<th class="p-3 text-left font-bold">Agente configurado</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border bg-gosign-white">
<td class="p-3 font-medium text-gosign-dark">Mudança de regras</td>
<td class="p-3 text-gosign-text">Retreinamento (semanas, $5k - $20k)</td>
<td class="p-3 text-gosign-text">Atualização do conjunto de regras (minutos, $0)</td>
</tr>
<tr class="border-b border-gosign-border bg-gosign-light">
<td class="p-3 font-medium text-gosign-dark">Explicabilidade</td>
<td class="p-3 text-gosign-text">"O modelo aprendeu" (Black Box)</td>
<td class="p-3 text-gosign-text">Regra + versão + contexto (registro de decisão)</td>
</tr>
<tr class="border-b border-gosign-border bg-gosign-white">
<td class="p-3 font-medium text-gosign-dark">Contestabilidade</td>
<td class="p-3 text-gosign-text">Não possível (sem registro de decisão)</td>
<td class="p-3 text-gosign-text">Sim (o afetado vê a regra e pode contestar)</td>
</tr>
<tr class="border-b border-gosign-border bg-gosign-light">
<td class="p-3 font-medium text-gosign-dark">Troca de modelo</td>
<td class="p-3 text-gosign-text">Novo treinamento necessário (lock-in)</td>
<td class="p-3 text-gosign-text">0 esforço (modelo-agnóstico)</td>
</tr>
<tr class="border-b border-gosign-border bg-gosign-white">
<td class="p-3 font-medium text-gosign-dark">Audit Trail</td>
<td class="p-3 text-gosign-text">Entrada + saída (sem fundamentação)</td>
<td class="p-3 text-gosign-text">Entrada + regra + versão + confiança + resultado</td>
</tr>
<tr class="border-b border-gosign-border bg-gosign-light">
<td class="p-3 font-medium text-gosign-dark">EU AI Act (ago. 2026)</td>
<td class="p-3 text-gosign-text">Art. 13, 14, 86: problemático</td>
<td class="p-3 text-gosign-text">Art. 13, 14, 86: conforme by Design</td>
</tr>
<tr class="bg-gosign-white">
<td class="p-3 font-medium text-gosign-dark">Break-Even Fine-Tuning</td>
<td class="p-3 text-gosign-text">A partir de ~35 000 consultas/mês<sup>[6]</sup></td>
<td class="p-3 text-gosign-text">Economicamente viável de imediato</td>
</tr>
</tbody>
</table>
</div>
</div>

Um estudo de Chauhan et al. (2025) situa o ponto de Break-Even do Fine-Tuning em relação ao prompting em aproximadamente 35 000 consultas por mês.<sup>[6]</sup> A maioria dos processos de RH e Finanças em empresas está bem abaixo disso.

## Três coisas no lugar de treinamento

Se não treinamento, então o quê? Três componentes substituem o que o Fine-Tuning promete, mas estruturalmente não consegue entregar.

### 1. Conjunto de regras

Tudo o que um agente precisa saber está em uma lei, um regulamento, uma convenção coletiva (PT: acordo coletivo de trabalho) ou um acordo coletivo. Essas regras mudam. A legislação tributária muda anualmente. As diárias e valores de referência mudam anualmente. Os regulamentos da UE mudam.

Um modelo treinado precisa ser retreinado a cada mudança. Um conjunto de regras é atualizado. Efeito imediato, versionado, auditável. Sem cluster GPU, sem ciclo de avaliação, sem riscos de regressão.

RAG (Retrieval Augmented Generation) reduz erros factuais em até 50%.<sup>[11]</sup> Não porque o modelo fica mais inteligente. Mas porque vê a regra atual em vez de recuperar uma ponderação desatualizada.

### 2. Contexto

O agente não precisa de 10 000 prestações de contas de viagem históricas. Precisa desta prestação de contas: data da viagem, partida, retorno, hotel, café da manhã incluído ou não. Esse é o contexto desta decisão.

É fornecido por entradas estruturadas ou RAG, não incorporado por treinamento. Quando o contexto muda - outra viagem, outro colaborador - a decisão muda. Não o modelo.

Um exemplo concreto: o [Travel Decision Layer](/br/servicos/travel-decision-layer/) verifica diárias de viagem contra §9 EStG (lei fiscal alemã de despesas de viagem). O contexto é a viagem individual. O conjunto de regras é a legislação tributária vigente. O modelo Foundation é intercambiável.

### 3. Estrutura de decisão

Quem decide o quê? Nem todas as decisões em um processo são iguais.

A diária de viagem é conjunto de regras: §9 EStG, determinística, 100% confiança. A questão de se uma despesa de representação é "razoável" é critério humano: pessoa. A classificação de um cupom fiscal ilegível é AI: extração LLM, probabilística.

Essa decomposição em Micro-Decisions com atribuição pessoa/regra/AI é o verdadeiro trabalho de arquitetura. Não o treinamento. O [Decision Layer](/br/decision-layer/) formaliza exatamente essa decomposição. Detalhes da arquitetura: [Decision Layer explicado](/br/revista/decision-layer-explicado/).

<!-- Demo Micro-Decision -->
<div class="not-prose my-10">
<div class="bg-gosign-light border border-gosign-border rounded-card overflow-hidden">
<div class="p-6 sm:p-8">
<p class="text-h3 font-bold text-gosign-dark mb-2">Micro-Decision na prática</p>
<p class="text-gosign-text text-sm mb-6">Prestação de contas de viagem: jornada de 8 horas, viagem nacional, hotel com café da manhã</p>

<div class="space-y-3">

<div class="bg-gosign-white border border-gosign-border rounded-lg p-4">
<div class="flex flex-wrap items-center gap-3">
<span class="text-xs font-mono bg-gosign-dark text-white px-2 py-0.5 rounded">#1</span>
<span class="font-medium text-gosign-dark text-sm">Data da viagem e duração da ausência</span>
<span class="text-xs px-2 py-0.5 rounded bg-blue-100 text-blue-800 font-medium">Contexto</span>
<span class="text-xs text-gosign-text-light ml-auto">Input: comprovantes</span>
</div>
</div>

<div class="bg-gosign-white border border-gosign-border rounded-lg p-4">
<div class="flex flex-wrap items-center gap-3">
<span class="text-xs font-mono bg-gosign-dark text-white px-2 py-0.5 rounded">#2</span>
<span class="font-medium text-gosign-dark text-sm">Calcular diária de viagem</span>
<span class="text-xs px-2 py-0.5 rounded bg-green-100 text-green-800 font-medium">Conjunto de regras</span>
<span class="text-xs text-gosign-text-light ml-auto">§9 EStG v2026-01</span>
</div>
</div>

<div class="bg-gosign-white border border-gosign-border rounded-lg p-4">
<div class="flex flex-wrap items-center gap-3">
<span class="text-xs font-mono bg-gosign-dark text-white px-2 py-0.5 rounded">#3</span>
<span class="font-medium text-gosign-dark text-sm">Aplicar dedução por café da manhã</span>
<span class="text-xs px-2 py-0.5 rounded bg-green-100 text-green-800 font-medium">Conjunto de regras</span>
<span class="text-xs text-gosign-text-light ml-auto">§9 Abs. 4a S. 8 EStG</span>
</div>
</div>

<div class="bg-gosign-white border border-gosign-border rounded-lg p-4">
<div class="flex flex-wrap items-center gap-3">
<span class="text-xs font-mono bg-gosign-dark text-white px-2 py-0.5 rounded">#4</span>
<span class="font-medium text-gosign-dark text-sm">Classificar cupom fiscal</span>
<span class="text-xs px-2 py-0.5 rounded bg-gosign-accent/10 text-gosign-accent font-medium">AI</span>
<span class="text-xs text-gosign-text-light ml-auto">Extração LLM, Confidence: 87%</span>
</div>
</div>

<div class="bg-gosign-white border border-gosign-border rounded-lg p-4">
<div class="flex flex-wrap items-center gap-3">
<span class="text-xs font-mono bg-gosign-dark text-white px-2 py-0.5 rounded">#5</span>
<span class="font-medium text-gosign-dark text-sm">A despesa de representação é "razoável"?</span>
<span class="text-xs px-2 py-0.5 rounded bg-yellow-100 text-yellow-800 font-medium">Pessoa</span>
<span class="text-xs text-gosign-text-light ml-auto">Critério, o responsável verifica</span>
</div>
</div>

<div class="bg-gosign-white border border-gosign-border rounded-lg p-4">
<div class="flex flex-wrap items-center gap-3">
<span class="text-xs font-mono bg-gosign-dark text-white px-2 py-0.5 rounded">#6</span>
<span class="font-medium text-gosign-dark text-sm">Criar lançamento contábil conforme normativa</span>
<span class="text-xs px-2 py-0.5 rounded bg-green-100 text-green-800 font-medium">Conjunto de regras</span>
<span class="text-xs text-gosign-text-light ml-auto">Normativa contábil, versionada</span>
</div>
</div>

</div>

<div class="mt-6 p-4 bg-gosign-dark rounded-lg">
<p class="text-gosign-text-on-dark text-sm">Cada um desses passos tem um tipo fixo: <span class="text-green-400">conjunto de regras</span> (determinístico), <span class="text-gosign-accent-on-dark">AI</span> (probabilístico, com limiar de confiança) ou <span class="text-yellow-400">pessoa</span> (critério). Quando §9 EStG muda, a regra é atualizada. Sem retreinamento. Sem novo modelo.</p>
</div>
</div>
</div>
</div>

## As três camadas: arquitetura no lugar de treinamento

A arquitetura por trás de um agente configurado consiste em três camadas. Cada camada é independentemente intercambiável.

<!-- Diagrama de três camadas -->
<div class="not-prose my-10">
<div class="max-w-2xl mx-auto">

<div class="bg-gosign-dark border-2 border-gosign-accent rounded-t-card p-6">
<div class="flex items-center gap-3 mb-3">
<span class="text-gosign-accent-on-dark text-xs uppercase tracking-wider font-bold">Camada 3</span>
<span class="text-white font-bold text-lg">Decision Layer</span>
</div>
<div class="flex flex-wrap gap-2">
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Micro-Decisions</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Pessoa / Regras / AI</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Registro de decisão</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Audit Trail</span>
</div>
</div>

<div class="bg-gosign-dark border-x-2 border-gosign-accent p-6 border-t border-white/10">
<div class="flex items-center gap-3 mb-3">
<span class="text-gosign-accent-on-dark text-xs uppercase tracking-wider font-bold">Camada 2</span>
<span class="text-white font-bold text-lg">Conjunto de regras (versionado, intercambiável)</span>
</div>
<div class="flex flex-wrap gap-2">
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Legislação tributária</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Regulamentos</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Normativa contábil</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Convenção coletiva</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Acordo coletivo</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">EU AI Act</span>
</div>
</div>

<div class="bg-gosign-darker border-2 border-white/20 rounded-b-card p-6">
<div class="flex items-center gap-3 mb-3">
<span class="text-gosign-text-on-dark text-xs uppercase tracking-wider font-bold">Camada 1</span>
<span class="text-white font-bold text-lg">Foundation Model (intercambiável)</span>
</div>
<div class="flex flex-wrap gap-2">
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Claude</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">GPT</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Llama</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Mistral</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Gemini</span>
</div>
</div>

<div class="mt-4 flex items-start gap-3 p-4 bg-gosign-light border border-gosign-border rounded-card">
<span class="text-gosign-accent text-lg mt-0.5">&#x2191;</span>
<p class="text-gosign-text text-sm">Tudo acima da camada 1 permanece quando o modelo muda. Conjunto de regras, Decision Layer, registros de decisão, Audit Trail - tudo modelo-agnóstico. Sem retreinamento. Sem lock-in.</p>
</div>

</div>
</div>

Por que três camadas? Porque cada uma tem uma responsabilidade diferente.

O Foundation Model fornece compreensão linguística e reasoning. Entende o contexto, extrai informações de documentos, classifica entradas. Não precisa saber o que diz §9 EStG. Precisa entender o que é um texto legal.

O conjunto de regras contém a lógica de negócio. Leis, regulamentos, convenções coletivas, acordos coletivos. Cada regra tem uma versão. Cada versão tem uma data de vigência. Quando a lei muda, a regra é atualizada. Não o modelo.

O [Decision Layer](/br/decision-layer/) controla quem pode decidir o quê. Decompõe os processos em passos de decisão. Define para cada um: pessoa, conjunto de regras ou AI. Documenta cada decisão com regra, versão, contexto e resultado.

## O que treinamento realmente custa

Não em dólares. Em dependências.

### Lock-in

Um modelo fine-tuned vincula você a esse fornecedor. O dataset de treinamento, os pesos, o pipeline de avaliação: tudo proprietário. Troca de modelo = novo treinamento = novos custos = nova perda de tempo.

Um agente configurado troca o Foundation Model sem alterar uma única regra. Claude hoje, GPT amanhã, um modelo open-source na próxima semana. O conjunto de regras permanece. O Decision Layer permanece. Os registros de decisão permanecem.

### Manutenção

Cada mudança legislativa exige retreinamento. Em Finanças, a legislação tributária, as instruções normativas e as alíquotas de contribuição mudam anualmente. Em RH mudam as convenções coletivas, os acordos coletivos e a regulação da UE.

Um agente treinado precisa de manutenção contínua que se parece com um projeto de software. Um agente configurado precisa de um editor de conjunto de regras.

MIT e Stanford (Choi & Xie, 2025) mostram: AI reduz o fechamento mensal em 7,5 dias.<sup>[7]</sup> Mas 62% dos contadores se preocupam com erros da AI.<sup>[8]</sup> A preocupação é justificada - com modelos treinados. Com agentes configurados com registro de decisão e possibilidade de contestação, cada erro é identificável e corrigível.

### Explicabilidade

Um modelo treinado pode dizer o que decidiu. Não pode dizer por quê.

"O modelo aprendeu" não é uma fundamentação que um auditor aceita. Nenhuma CIPA ou sindicato aceita. Nenhum candidato rejeitado aceita.

"Regra §9 EStG v2026-01, aplicada à ausência 14h15min" é uma fundamentação.

Se você não pode explicar a decisão, não pode permitir que seja contestada. E se não pode permitir que seja contestada, não atende às obrigações de alto risco do EU AI Act - exigíveis, pela legislação vigente, a partir de 2 de agosto de 2026, com adiamento para dezembro de 2027 acordado provisoriamente (Digital Omnibus, maio de 2026; adoção formal ainda pendente). No Brasil, o PL 2338/2023 prevê direitos semelhantes de explicação para decisões automatizadas.<sup>[10]</sup>

### O Fine-Tuning tem seu lugar?

Sim. A partir de aproximadamente 35 000 consultas por mês com um conjunto de regras estável, o Fine-Tuning se torna economicamente viável.<sup>[6]</sup> Adaptação linguística, jargão de domínio, otimização de latência: para isso há boas razões.

Mas onde o setor o vende hoje - Enterprise RH e Finanças com leis que mudam anualmente - é a decisão arquitetônica errada. O Gartner projeta que mais de 40% dos projetos de Agentic AI fracassarão até 2027.<sup>[9]</sup> Não pelo desempenho dos modelos. Pela governance.

## A pergunta que seu conselho deveria fazer

Não: "Em quais dados seu agente foi treinado?"

Mas sim:

**1. Qual conjunto de regras fundamenta a decisão? Qual versão estava vigente no momento da decisão?**

Se a resposta for "Isso está no modelo", não há versão. Não há histórico de mudanças. Não há Audit Trail.

**2. O que acontece quando a regra muda? Retreinamento ou atualização?**

Se a resposta for "Retreinamos", você está pagando por manutenção desnecessária.

**3. O afetado pode ver a decisão individual e contestá-la?**

Se não houver resposta, você tem uma lacuna de compliance frente às obrigações de alto risco do EU AI Act - exigíveis, pela legislação vigente, a partir de 2 de agosto de 2026, com adiamento para dezembro de 2027 acordado provisoriamente (Digital Omnibus, maio de 2026; adoção formal ainda pendente). Art. 86 EU AI Act: direito à explicação. No Brasil, o PL 2338/2023 estabelece direitos equivalentes. Não é opcional.<sup>[10]</sup>

## A abordagem da Gosign

O Decision Layer da Gosign é uma implementação dessa arquitetura. Decompõe os processos em passos de decisão. Define para cada um: pessoa, conjunto de regras ou AI. Os conjuntos de regras são versionados. As decisões são auditáveis. Os resultados são contestáveis.

[48 agentes de RH](/br/catalogo-agentes-hr/) e [49 agentes de Finanças](/br/catalogo-agentes-finance/), cada um com tabela Micro-Decision. Sem Fine-Tuning. Sem lock-in. Sem retreinamento quando a legislação muda.

---

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Referências</p>
<ol class="text-sm text-gosign-text space-y-2 list-decimal list-inside">
<li id="fn1">Better Bill GPT, Whitehouse et al. (abril 2025). Legal Invoice Review: LLM alcança 92% de precisão na verificação de honorários jurídicos contra Billing Guidelines. Peer-reviewed.</li>
<li id="fn2">Better Bill GPT, Whitehouse et al. (abril 2025). F-Score na classificação de itens individuais: LLM 81% vs. melhor grupo humano 43%.</li>
<li id="fn3">Better Bill GPT, Whitehouse et al. (abril 2025). Tempo de processamento por fatura: LLM 3,6 segundos vs. juristas experientes 194 a 316 segundos.</li>
<li id="fn4">Better Bill GPT, Whitehouse et al. (abril 2025). Redução de custos na Legal Invoice Review: 99,97% ($4,27 vs. &lt;$0,01 por fatura).</li>
<li id="fn5">Kumar Gauraw (março 2026). "A maioria recorre ao Fine-Tuning cedo demais."</li>
<li id="fn6">Chauhan et al., Journal of Information Systems Engineering (2025). Break-Even Fine-Tuning vs. Prompting: ~35 000 consultas por mês.</li>
<li id="fn7">MIT/Stanford, Choi & Xie (agosto 2025). AI reduz o fechamento mensal em média 7,5 dias.</li>
<li id="fn8">MIT/Stanford, Choi & Xie (agosto 2025). 62% dos contadores expressam preocupação sobre erros da AI em processos financeiros.</li>
<li id="fn9">Gartner (junho 2025). Projeção: mais de 40% dos projetos de Agentic AI fracassarão até 2027.</li>
<li id="fn10">EU AI Act (VO 2024/1689), Crowell & Moring (fevereiro 2026). Obrigações para sistemas de alto risco: prazo vigente 2 de agosto de 2026, com adiamento para 2 de dezembro de 2027 acordado provisoriamente no Digital Omnibus (7 de maio de 2026, adoção formal ainda pendente). Art. 13 (transparência), Art. 14 (supervisão humana), Art. 86 (direito à explicação). Anexo III(4): recrutamento como sistema de alto risco. No Brasil, o PL 2338/2023 prevê obrigações análogas.</li>
<li id="fn11">IBM (2024). RAG reduz erros factuais nas saídas de LLM em até 50%.</li>
</ol>
</div>

--- Por que projetos de IA em RH fracassam ---
> Projetos de IA não fracassam por tecnologia, mas pela falta de regras. Por que o modelo operacional importa mais que o modelo de linguagem.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Resumo - Por que projetos de IA fracassam</p>
<ul class="text-body text-gosign-text space-y-2">
<li>A maioria dos projetos de IA não fracassa por causa da tecnologia. Fracassam porque ninguém definiu quais decisões a IA pode tomar e quais devem permanecer com humanos.</li>
<li>O AI-Paradox: empresas adotam IA amplamente, mas apenas uma fração obtém resultados mensuráveis - falta a arquitetura de decisões.</li>
<li>MIT Sloan Management Review (2024) constatou que 70% das iniciativas de IA corporativa não conseguem sair do piloto para a produção.</li>
<li>Proporção de investimento: para cada euro em tecnologia, empresas precisam de quatro a cinco euros em processos, governance e gestão de mudanças. Tecnologia sozinha aborda aproximadamente 20% do problema.</li>
<li>O Decision Layer decompõe processos de negócio em passos de decisão documentados - humano, regras ou IA - transformando experimentos em sistemas produtivos.</li>
</ul>
</div>

## Um piloto que funcionou - e depois desapareceu

Um departamento de RH inicia um projeto de IA. Um agent processa atestados médicos: lê o documento, extrai dados, verifica contra o acordo coletivo, cria uma proposta para SAP SuccessFactors. No piloto tudo funciona. A precisão é de 94%. O tempo de processamento cai de 45 minutos para 5 minutos.

Seis meses depois: o agent ainda está no piloto. Não porque a tecnologia falhou. Mas porque ninguém respondeu as perguntas que vêm depois do piloto:

Quem aprova o lançamento que o agent propõe? O que acontece se o agent erra - quem é responsável? A lógica vale também para a filial em Munique, onde vigora outro acordo coletivo? O agent pode iniciar automaticamente um procedimento de reintegração em caso de afastamento prolongado, ou isso deve ser decidido por um humano? O que diz o comitê de empresa?

Não são perguntas técnicas. São perguntas de decisão. E enquanto não forem respondidas, cada agent é um experimento.

## O AI-Paradox: Alto investimento, baixo retorno

O que acontece aqui não é um caso isolado. É um padrão que se repete em empresas de todos os tamanhos.

A maioria das empresas já usa IA - pelo menos na forma de chatbots, licenças de Copilot ou primeiros pilotos. Mas poucas reportam que a IA traz uma contribuição mensurável aos resultados.

Este é o AI-Paradox: a tecnologia funciona. Mas os benefícios não chegam.

As explicações habituais ficam aquém. "Os dados não são bons o suficiente" - às vezes é verdade, mas qualidade de dados é um problema solucionável. "O modelo não é bom o suficiente" - improvável quando se vê o que os modelos de linguagem atuais conseguem. "Os funcionários têm medo de IA" - gestão de mudanças é importante, mas não explica por que até projetos bem conduzidos empacam.

A causa real é outra: falta a arquitetura de decisões.

## O que falta: Não melhor tecnologia - mas regras claras

Um agent de IA que processa atestados toma entre cinco e dez decisões individuais por documento: O documento está completo? Qual acordo coletivo se aplica? Há um afastamento prolongado? Deve-se iniciar um procedimento de reintegração? Em qual sistema se lança?

Para cada uma dessas decisões deve estar predefinido:

**Decide um humano?** Por exemplo em afastamentos prolongados, porque um procedimento de reintegração requer discricionariedade e a representação dos trabalhadores (sindicatos/CRE; PT: Comissão de Trabalhadores) tem direito de participação.

**Decide um conjunto de regras?** Por exemplo na verificação do acordo coletivo conforme a CLT (PT: Código do Trabalho) - o acordo é claro, a regra é aplicada de forma consistente. Aqui o agente é um executor - não porque não seja capaz de mais, mas porque não há o que interpretar.

**Decide a IA de forma autônoma?** O agente interpreta documentos, classifica situações, avalia contexto. Isso não é if-then-else - é capacidade de julgamento dentro de limites definidos. O Confidence Routing controla: alta confiança e baixo risco significa decisão autônoma; baixa confiança ou alto risco significa escalação para uma pessoa.

Sem essa atribuição, o agent é uma caixa preta. Produz resultados, mas ninguém consegue rastrear em que base. Nenhum auditor aceita isso. Nenhum comitê aceita isso. Nenhum departamento de compliance libera isso.

## A proporção de investimento: Por que tecnologia sozinha não basta

A experiência mostra uma regra que surpreende muitos: para cada euro em tecnologia, empresas precisam de quatro a cinco euros em processos, governance e gestão de mudanças.

Isso significa: quem tem um orçamento de IA de R$ 2,5 milhões e investe tudo em licenças e modelos, aborda aproximadamente 20% do problema. Os 80% restantes - design de processos, regras de decisão, regulamentos internos, treinamentos, estruturas de governance - ficam sem tratamento.

Isso explica o AI-Paradox. Não é um problema de tecnologia. É um problema de investimento. Ou mais precisamente: um problema de distribuição de investimento.

## O que isso significa para RH

Processos de RH são especialmente vulneráveis ao AI-Paradox. Por três razões:

**Primeiro: Alta complexidade regulatória.** Acordos coletivos conforme a CLT, regulamentos internos, leis específicas por país, diretrizes internas. Um único processo como o processamento de atestados pode tocar cinco conjuntos de regras diferentes.

**Segundo: Participação.** Em empresas com representação dos trabalhadores (sindicatos e, em empresas com mais de 200 empregados, a CRE) ou comitê interno, existe o direito de participação quando sistemas de IA processam dados de funcionários. Sem uma lógica de decisão transparente, o comitê não pode verificar o que o agent faz.

**Terceiro: Responsabilidade.** Se um agent gera uma folha de pagamento errônea, a responsabilidade não é do agent. É da empresa. Sem um caminho de decisão documentado, não fica claro onde o erro se originou.

## Primeiro tornar as decisões visíveis, depois automatizar

A solução não é menos IA. A solução é mais estrutura.

Antes que um agent automatize um processo, o processo deve ser decomposto em passos de decisão individuais. Para cada passo define-se: humano, regras ou IA. Essa atribuição não é estática - pode mudar quando um conjunto de regras muda ou quando o agent ganha experiência.

O [Decision Layer](/br/decision-layer/) implementa exatamente isso. Situa-se entre o AI Agent e o sistema destino e decompõe cada processo de negócio em passos de decisão documentados. Cada passo tem uma atribuição clara, um conjunto de regras versionado e um Audit Trail completo.

O resultado: de um experimento de IA surge um sistema produtivo. Um que o comitê pode verificar, que o auditor aceita e que funciona consistentemente em todas as localidades.

## Padrões de fracasso em projetos de IA

| Padrão de fracasso | Causa raiz | Solução |
|---|---|---|
| Piloto funciona mas nunca escala | Regras de decisão não definidas - ninguém responde as perguntas pós-piloto | Decision Layer: definir atribuição humano/regras/IA por passo antes de escalar |
| Alta adoção sem impacto mensurável | Investimento concentrado em tecnologia, processos e governance negligenciados | Redistribuir: 20% tecnologia, 80% processos, governance, gestão de mudanças |
| Representação dos trabalhadores bloqueia implantação | Decisões de IA não rastreáveis, sem Audit Trail | Transparência no nível da arquitetura: regras versionadas, Audit Trail completo |
| Agent produz erros que ninguém consegue explicar | Decisões de caixa preta sem caminho de decisão documentado | Confidence Routing: limiares de escalação, Human-in-the-Loop em casos limítrofes |
| Resultados diferentes em diferentes localidades | Conjuntos de regras variam mas a lógica do agent é uniforme | Motor de regras com consciência de localização com regras versionadas e testáveis |

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">eBook gratuito: IA em RH</p>
<p class="text-body text-gosign-text mb-4">Checklist EU AI Act, framework de decisões, perspectiva da representação dos trabalhadores e avaliação de prontidão - o manual de governança para líderes de RH.</p>
<a href="/br/ebook/ia-rh-manual-governanca/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Baixar gratuitamente</a>
</div>

## Conclusão

O AI-Paradox não é um destino inevitável. É a consequência de uma má alocação: investimento demais em tecnologia, de menos nas regras que determinam o que a tecnologia pode fazer.

Empresas que entendem isso não investem no próximo modelo de linguagem - investem na sua arquitetura de decisões. E exatamente aí está a diferença entre um piloto de IA que acaba na gaveta e um sistema que funciona em produção.

> [Decision Layer - visão geral e exemplos](/br/decision-layer/)

> [Três tipos de decisões: Quando o humano, quando a IA](/br/revista/tres-tipos-de-decisoes/)

--- RAG e Document Intelligence para empresas (2026) ---
> RAG torna documentos corporativos acessiveis para IA - sem treinamento, sem vazamento de dados. Mais: anonimizacao PII e redacao de contratos.

## A pergunta central: A IA pode entender nossos próprios documentos?

"Podemos fazer a IA responder com base nos nossos documentos?" Essa pergunta surge em praticamente todas as empresas. A resposta é sim, com RAG (Retrieval Augmented Generation). O princípio: seus documentos permanecem na sua infraestrutura. O modelo de linguagem não é treinado com seus dados. Em vez disso, seções relevantes dos documentos são fornecidas ao modelo como contexto a cada consulta. O modelo responde com base nessas seções, com citação de fontes.

Nenhum vazamento de dados para terceiros. Nenhum retreinamento. Nenhuma perda de controle. E ainda assim, respostas em linguagem natural baseadas diretamente no conhecimento da sua organização.

RAG é hoje a abordagem padrão para conectar modelos de linguagem com conhecimento específico da organização. Este artigo explica como RAG funciona, quando é a escolha certa e por que Document Intelligence vai muito além de uma busca melhor, incluindo anonimização PII, redação de contratos e detecção de assinaturas.

IDC (2025) estima que 90% de todos os novos dados corporativos são não estruturados - documentos, e-mails, contratos, atas de reunião. RAG é o método padrão para tornar esses dados acessíveis à IA sem retreinar o modelo.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Resumo - RAG & Document Intelligence</p>
<ul class="text-body text-gosign-text space-y-2">
<li>RAG conecta modelos de linguagem aos seus documentos corporativos - sem treinamento, sem vazamento de dados. Documentos permanecem na sua infraestrutura.</li>
<li>Para 90% dos casos de uso empresariais, RAG supera Fine-Tuning: menor custo, atualização imediata via re-indexação, citações de fontes integradas.</li>
<li>Document Intelligence vai além da busca: anonimização PII, redação de contratos e detecção de assinaturas são funcionalidades prontas para produção.</li>
<li>A qualidade da indexação determina a qualidade das respostas. Estratégia de chunking, enriquecimento com metadados e controle de acesso são inegociáveis.</li>
<li>RAG se integra ao portal Enterprise AI para que cada departamento acesse apenas sua base de conhecimento autorizada.</li>
</ul>
</div>

## Como RAG funciona

RAG consiste em duas fases: a indexação dos seus documentos e a resposta a consultas. O fluxo pode ser ilustrado em um diagrama:

```
Documentos → Chunking → Embedding → Banco de dados vetorial
│
Consulta do usuário → Query Embedding → Busca por similaridade
│
Seções relevantes + Consulta → LLM → Resposta com citação de fonte
```

**Fase 1: Indexação.** Seus documentos - PDFs, arquivos Word, páginas HTML, documentos escaneados - são divididos em seções significativas (chunking). Cada seção é convertida por um modelo de embedding em um vetor matemático. Esses vetores são armazenados em um banco de dados vetorial. O vetor representa o significado da seção, não sua redação literal. "Política de trabalho remoto" e "Acordo de home office" ficam próximos no espaço vetorial, mesmo usando palavras diferentes.

**Fase 2: Consulta.** Quando um usuário faz uma pergunta, ela também é convertida em um vetor. O banco de dados vetorial encontra as seções semanticamente mais próximas da pergunta, não por busca de palavras-chave, mas por cálculo de similaridade. Essas seções relevantes são enviadas ao modelo de linguagem junto com a pergunta original. O modelo gera uma resposta com base nessas fontes concretas.

O resultado: uma resposta em linguagem natural fundamentada nos seus documentos, com referências às passagens de onde a informação foi extraída.

A qualidade da indexação é decisiva. Chunks muito grandes diluem a relevância. Chunks muito pequenos perdem o contexto. A estratégia de chunking - tamanho, sobreposição, enriquecimento com metadados - determina em grande parte a qualidade das respostas. Um bom pipeline RAG não é a tecnologia em si, mas sua configuração para o cenário documental específico da sua empresa.

## RAG vs. Fine-Tuning vs. Prompting

RAG não é a única forma de fornecer conhecimento de domínio a um modelo de linguagem. Existem três abordagens fundamentais, que diferem em esforço, custo e adequação:

| Abordagem | O que acontece | Quando é adequado | Custo | Atualização |
|---|---|---|---|---|
| Prompting | Contexto fornecido diretamente no prompt | Volumes de dados pequenos | Baixo | Imediata |
| RAG | Documentos relevantes encontrados automaticamente | Grandes bases de conhecimento | Médio | Re-indexação |
| Fine-Tuning | Modelo retreinado | Linguagem especializada/domínio | Alto | Apenas via retreinamento |

**Prompting** funciona quando o contexto relevante cabe na janela de contexto do modelo, tipicamente algumas dezenas de páginas. Para um único acordo coletivo (PT: acordo de empresa), isso é suficiente. Para uma base de conhecimento com centenas de documentos, não.

**RAG** escala para grandes acervos documentais. O banco de dados vetorial pode conter centenas de milhares de seções. A cada consulta, apenas as seções relevantes são recuperadas e enviadas ao modelo. Documentos podem ser atualizados a qualquer momento; basta uma re-indexação. O modelo não precisa ser retreinado.

**Fine-Tuning** altera os pesos do próprio modelo. É apropriado quando o modelo precisa aprender uma linguagem de domínio completamente nova - por exemplo, terminologia médica ou uma nomenclatura proprietária - ou quando um formato de resposta muito específico é necessário. Fine-Tuning é custoso, trabalhoso e exige retreinamento a cada atualização.

Para 90% dos casos de uso empresariais, RAG é a abordagem certa. A combinação de grandes bases de conhecimento, atualizações frequentes e a necessidade de citações de fontes torna RAG o padrão para conhecimento corporativo.

## Document Intelligence: mais do que busca

RAG responde perguntas com base em documentos. Document Intelligence vai além: abrange todos os métodos pelos quais a IA não apenas lê documentos, mas os entende, classifica e processa, incluindo a proteção de informações sensíveis.

As três áreas de aplicação mais importantes no contexto empresarial: anonimização PII, redação de contratos e detecção de assinaturas.

### Anonimização PII: pseudonimização com ciclo completo

Dados pessoais (PII, Personally Identifiable Information) não podem ser enviados a um modelo de linguagem em muitos casos de uso. Salários, nomes reais, números de matrícula, dados de saúde. A LGPD (PT: RGPD) e políticas internas de proteção de dados estabelecem limites claros.

A solução é a pseudonimização com ciclo completo (roundtrip). Um exemplo concreto:

**Documento original:**
"João Silva, Departamento Financeiro, salário R$ 12.000, adere ao acordo coletivo de horário flexível."

**Após pseudonimização (entrada para o modelo):**
"Pessoa_A, Departamento_X, Salário_Y, adere ao acordo coletivo de horário flexível."

O modelo de linguagem processa a consulta com dados pseudonimizados. Em nenhum momento vê o nome real, o departamento ou o salário.

**Após re-identificação (saída para o usuário):**
Os marcadores no resultado são substituídos pelos dados originais. O usuário vê a resposta completa. O modelo nunca a viu.

Esse ciclo acontece automaticamente. Para o usuário, o processo é transparente. Para o modelo, os dados são inacessíveis em todos os momentos. Para a [infraestrutura](/br/servicos/infraestrutura/) isso significa: a camada de pseudonimização fica entre o usuário e o modelo e é aplicada tecnicamente, não opcionalmente.

A anonimização PII é especialmente relevante para aplicações de RH, onde prontuários de funcionários, folhas de pagamento ou avaliações de desempenho devem ser processados com auxílio de IA. Sem anonimização, esses casos de uso não estão em conformidade com a LGPD no Brasil (PT: RGPD na UE).

### Redação de contratos (Redaction)

A redação de contratos vai além da pseudonimização. Enquanto a pseudonimização substitui dados e os restaura ao final, a redação remove fisicamente o conteúdo do documento, de forma irrevogável para o destinatário em questão.

O caso de uso: diferentes departamentos precisam de visões diferentes do mesmo contrato. O departamento jurídico vê o contrato completo. Compras vê uma versão sem cláusulas de responsabilidade. A diretoria vê um resumo sem detalhes operacionais.

A redação funciona com base em regras. Para cada categoria de documento e cada grupo de destinatários, define-se quais seções são visíveis e quais são redigidas. As regras são configuradas e versionadas no [Decision Layer](/br/decision-layer/), não aplicadas manualmente.

O resultado: cada função vê exatamente a informação que é relevante e autorizada para ela. Nenhuma redação manual. Nenhuma passagem esquecida. Nenhuma versão encaminhada acidentalmente na íntegra.

### Detecção de assinaturas

Arquivos de contratos em empresas frequentemente contêm milhares de documentos. A pergunta sobre se um contrato específico está completamente assinado exige hoje, muitas vezes, revisão manual página por página. Com centenas de contratos, isso é inviável.

Document Intelligence resolve esse problema por meio da detecção automatizada de assinaturas. O sistema verifica contratos escaneados quanto à presença de assinaturas nos locais designados. Assinaturas ausentes são sinalizadas automaticamente. O resultado: uma visão geral de todos os contratos no arquivo que ainda não foram completamente assinados, em minutos em vez de semanas.

O caso de uso vai além da mera detecção. Em combinação com um pipeline RAG, o sistema também pode responder perguntas como: "Quais contratos-quadro com prazo superior a 3 anos foram renovados no último trimestre sem assinatura da diretoria?"

## Exemplo prático: O assistente de acordos coletivos

Um cenário concreto da prática de RH. Um departamento de pessoal de uma empresa de médio porte gerencia mais de 100 acordos coletivos ativos (PT: acordos de empresa): jornada de trabalho, trabalho remoto, viagens a serviço, treinamento, previdência complementar, gestão de reintegração, proteção de dados, uso de TI e muito mais. Cada acordo tem aditivos, anexos e referências cruzadas a outros acordos.

Quando um analista de RH precisa responder à pergunta: "Qual é a regra de trabalho remoto para funcionários em regime parcial na produção?", hoje isso significa: encontrar o acordo coletivo correto, localizar a passagem relevante, verificar se existe um aditivo, comparar com a convenção coletiva (PT: contrato coletivo de trabalho), considerar regras específicas da unidade. Resultado: 30 a 45 minutos de pesquisa. Em caso de dúvida, consulta ao departamento jurídico. Mais alguns dias de espera.

Com um assistente de acordos coletivos baseado em RAG: todos os acordos são indexados, incluindo aditivos, anexos e referências cruzadas. O analista de RH faz a pergunta em linguagem natural. O sistema encontra as passagens relevantes dos documentos corretos, considera o aditivo de março de 2025, referencia a regra especial para funcionários da produção e entrega a resposta em 10 segundos. Com citação de fonte. Com versão da norma.

Isso não é um cenário teórico. É o caso de uso padrão com o qual empresas implementam seu primeiro pipeline RAG. O esforço é gerenciável: fornecer documentos, configurar a estratégia de chunking, definir direitos de acesso, testar. A [infraestrutura](/br/servicos/infraestrutura/) - banco de dados vetorial, modelo de embedding, modelo de linguagem, pipeline de recuperação - é construída uma vez e fica disponível para casos de uso adicionais.

## Garantia de qualidade: Por que resultados RAG são tão bons quanto a indexação

RAG não funciona sozinho. As fontes de erro mais comuns na prática:

**Estratégia de chunking ruim.** Chunks muito grandes (capítulos inteiros) fornecem contexto irrelevante demais. Chunks muito pequenos (parágrafos individuais) perdem a coerência. O tamanho de chunk adequado depende do tipo de documento: uma especificação técnica exige chunks diferentes de um acordo coletivo.

**Metadados ausentes.** Sem metadados (tipo de documento, data de vigência, versão, escopo), o pipeline de recuperação não consegue distinguir entre uma norma vigente e uma obsoleta. O enriquecimento de metadados durante a indexação não é opcional, é essencial.

**Sem controle de acesso.** Em um ambiente corporativo, nem todo usuário deve acessar todos os documentos. O pipeline RAG deve refletir a estrutura de permissões existente: documentos de RH apenas para RH, dados financeiros apenas para Finanças, comunicações da diretoria apenas para pessoas autorizadas.

**Sem verificação de fontes.** RAG fornece citações de fontes. Mas elas estão corretas? Uma garantia de qualidade - verificação por amostragem das referências, mecanismo de feedback para usuários, avaliação regular - é necessária para detectar alucinações e aprimorar o pipeline.

Essa garantia de qualidade é parte da operação contínua, não de uma configuração inicial única. Documentos mudam. Novos são adicionados. Antigos perdem a validade. O pipeline RAG deve evoluir, por meio de re-indexação regular, atualização de metadados e feedback dos usuários.

## Integração no portal Enterprise AI

RAG não é um sistema isolado. Em uma arquitetura bem projetada, o pipeline RAG está integrado ao [portal Enterprise AI](/br/revista/enterprise-ai-chat-interface/). Funcionários fazem perguntas por meio de uma interface unificada, a mesma pela qual interagem com [agentes de IA](/br/servicos/ai-agents/).

O portal gerencia os direitos de acesso: quem pode consultar qual base de conhecimento? Funcionários de RH veem o assistente de acordos coletivos. O departamento jurídico vê o assistente de contratos. Compras vê o assistente de diretrizes de fornecedores. Cada usuário vê apenas aquilo para o qual está autorizado.

A combinação de RAG e agentes de IA abre possibilidades ampliadas: um agente pode não apenas responder uma pergunta, mas, com base nos resultados RAG, disparar uma ação - por exemplo, gerar um alerta de prazo quando um contrato está prestes a vencer, ou criar uma lista de verificação quando um novo acordo coletivo entra em vigor.

---

**Enterprise AI-Infrastruktur Blueprint 2026 - Serie de artigos**

| ← Anterior | Visão geral | Próximo → |
|:---|:---:|---:|
| [Portal Enterprise AI: Quatro interfaces Open Source em comparação](/br/revista/enterprise-ai-chat-interface/) | [Visão geral](/br/revista/infraestrutura-ia-blueprint-2026/) | [De chatbots a agentes IA: MCP, A2A e sistemas Multi-Agent](/br/revista/agentes-ia-enterprise-guia/) |

*Todos os artigos desta série: [Enterprise AI-Infrastruktur Blueprint 2026](/br/revista/infraestrutura-ia-blueprint-2026/)*

---

**Quer tornar o conhecimento da sua empresa acessível para IA?** Gosign constrói pipelines RAG e soluções de Document Intelligence para clientes corporativos - agnóstico em relação a modelos, com anonimização PII e controle de acesso completo.

<a href="/br/contato/" target="_blank" rel="noopener noreferrer">Agende uma consulta</a>. 30 minutos para determinar quais documentos devem se tornar acessíveis para IA primeiro.

--- Como medir o ROI de investimentos em IA ---
> Como CFOs avaliam o ROI de enterprise AI. Custos de processo, taxas de erro e esforço de auditoria como KPIs mensuráveis.

## O problema com o ROI da IA

A maioria dos cálculos de ROI para investimentos em IA falha por falta de precisão. "30% mais produtivos" soa convincente em uma apresentação, mas não é comprovável quando ninguém definiu o que "mais produtivos" significa em um processo concreto.

CFOs conhecem esse problema. Veem projetos-piloto que entregam demos impressionantes mas nenhum número defensável para a diretoria. Veem orçamentos de IA aprovados como projetos de inovação sem um business case rastreável.

Não é que a IA não tenha ROI. É que a IA está sendo medida no ponto errado.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Resumo - Medir o ROI de enterprise AI</p>
<ul class="text-body text-gosign-text space-y-2">
<li>O ROI da IA vem da eficiência de processo, não da produtividade individual. Um processo documental automatizado economiza mais de 200 horas por mês.</li>
<li>Cinco KPIs tornam o ROI mensurável: custo de processo por caso, taxa de erro, tempo de ciclo, esforço de auditoria e custos de escalabilidade.</li>
<li>Segundo a McKinsey (2024), empresas que aplicam IA em operações financeiras alcançam 30 a 50% de redução de custos em processos documentais no primeiro ano.</li>
<li>O Decision Layer separa a análise de IA da decisão de negócio e cria um Audit Trail automático - métricas de ROI surgem como subproduto.</li>
<li>Comece com um processo, um agent, e meça os KPIs após 4 a 6 semanas. A diferença é o ROI.</li>
</ul>
</div>

## Onde o ROI realmente se origina

O ROI de enterprise AI não surge da produtividade individual de cada colaborador. Surge da eficiência de processo ao longo de fluxos de trabalho completos.

Um exemplo: em uma organização de Serviços Compartilhados de RH, um time de 8 analistas processa mensalmente 1.200 atestados médicos. Cada caso leva em média 12 minutos: abrir documento, verificar dados, calcular prazos conforme a CLT (PT: Código do Trabalho), lançar no sistema ERP, informar o gestor. São 240 horas por mês para um único tipo de documento.

Um [Document Agent](/br/servicos/ai-agents/) reduz o tempo de processamento manual por caso para menos de 2 minutos. Em casos padrão, para zero, porque o agent automatiza o processo inteiro até a etapa de aprovação. Os analistas revisam apenas exceções e escalações.

Isso não é uma promessa vaga de produtividade. É uma redução mensurável de 240 para 40 horas por mês, para um único processo. Multiplicado por 5 a 10 processos, o resultado é um business case que qualquer CFO entende.


## Os KPIs certos

Cinco KPIs tornam o ROI de agentes de IA mensurável e comunicável internamente.

Primeiro: custo de processo por caso. Quanto custa processar um atestado médico, uma nota fiscal, um contrato hoje? Quanto custa após a implantação do agent? A diferença é o ROI direto.

Segundo: taxa de erro. Processos manuais têm taxas de erro típicas de 2 a 5%. Um agent baseado em regras comete erros apenas quando as regras são defeituosas, e as regras são versionadas e corrigíveis. Cada erro evitado tem um custo consequente quantificável.

Terceiro: tempo de ciclo. Quanto tempo um caso leva da entrada à conclusão? Agents reduzem o tempo de espera para quase zero: o caso é processado assim que chega, não quando um analista o pega.

Quarto: esforço de auditoria. Em processos regulados (obrigações de FGTS e INSS, fiscalizações da Receita Federal; PT: TSU, obrigações perante a Autoridade Tributária) gera-se um esforço considerável em documentação manual e gestão de evidências. Um agent com [Decision Layer](/br/decision-layer/) documenta automaticamente: qual regra foi aplicada, quais dados estavam disponíveis, qual decisão foi tomada, quem aprovou. O Audit Trail surge como subproduto do processo.

Quinto: custos de escalabilidade. Quanto custa aumentar o volume atual em 50%? Com processos manuais: mais headcount. Com infraestrutura de agentes: mais capacidade computacional. As curvas de custo divergem radicalmente.

<div class="overflow-x-auto">

| KPI | Processo manual | Com agente AI | Método de medição |
|-----|----------------|---------------|-------------------|
| Custo de processo por caso | 15 - 60 USD | 2 - 8 USD | Comparação antes/depois |
| Taxa de erro | 2 - 5% | < 0,5% | Auditoria de amostras |
| Tempo de ciclo | 1 - 5 dias | Minutos | Delta de timestamps |
| Esforço de auditoria | 40 - 80 h/mês | < 5 h/mês | Horas registradas |
| Escalabilidade (+50% volume) | +50% headcount | +10% computação | Rastreamento de custos |

</div>

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">eBook gratuito: IA em Finanças</p>
<p class="text-body text-gosign-text mb-4">Conformidade, auditores externos e Decision Layer - o manual de governança para liderança financeira.</p>
<a href="/br/ebook/ia-financas-manual-governanca/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Baixar grátis</a>
</div>

## O Decision Layer como alavanca de ROI

O [Decision Layer](/br/decision-layer/) é o ponto onde o ROI se torna mensurável. Separa a análise da IA da decisão de negócio e documenta ambos como registros auditáveis.

Isso significa: para cada caso existe um registro completo: entrada, regra aplicada, recomendação do agent, decisão do humano, timestamp. Métricas de ROI podem ser derivadas automaticamente desses registros, sem coleta manual de dados.

Disso também se segue: o ROI melhora com o tempo. Como ajustes de regras são versionados e seu impacto em taxas de erro e tempos de ciclo é mensurável, surge um ciclo de otimização contínuo, documentado e rastreável.


## Como empresas devem começar

Não com uma estratégia de IA. Com um processo concreto.

Identificar o processo com maior volume e maiores custos manuais. Medir a linha de base: custos atuais do processo, taxa de erro, tempo de ciclo. Construir um agent para ele e medir os mesmos KPIs após 4 a 6 semanas.

A diferença é o ROI. Sem slides, sem estimativas: números concretos de um processo produtivo.

Na Gosign, construímos [agentes de IA](/br/servicos/ai-agents/) com exatamente essa abordagem: um processo, um agent, KPIs mensuráveis após 4 a 6 semanas. O [Decision Layer](/br/decision-layer/) entrega automaticamente a base de dados para o business case.

--- Security Baseline para o stack completo ---
> Security Baseline baseada em YAML para Supabase, Next.js, Edge Functions e Trigger.dev com checks automatizados.

Os runbooks anteriores descreveram os componentes individuais: [Supabase Platform](/br/revista/supabase-self-hosting/) (Artigo 1), [Next.js App Layer](/br/revista/nextjs-supabase-configuracao-segura/) (Artigo 2), [Edge Functions](/br/revista/supabase-edge-functions-seguranca/) (Artigo 3), [Trigger.dev Jobs](/br/revista/trigger-dev-background-jobs/) (Artigo 4) e [Claude Code como controle de segurança](/br/revista/claude-code-security-devops/) (Artigo 5).

Este último artigo reúne todas as regras em um **único arquivo legível por máquina**: o `security-baseline.yml`. Este arquivo define o estado desejado de todo o stack. Todos os deployments, reviews e auditorias são verificados contra esta Baseline, tanto por scripts determinísticos quanto pelo Claude Code.

O artigo entrega três coisas:
1. O `security-baseline.yml` completo
2. O script que o verifica automaticamente
3. A integração com o Claude Code Audit do Artigo 5

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Resumo - Artigo 6 de 6 da série DevOps Runbook</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Um único arquivo YAML define o estado desejado do stack</li>
<li>Verificações automatizadas diárias</li>
<li>Análise semanal do Claude</li>
<li>Gate de deploy bloqueia em violações críticas</li>
<li>Documento vivo atualizado com mudanças no stack</li>
</ul>
</div>

## Sumário da série

Este guia faz parte da nossa série de runbooks DevOps para stacks de aplicações self-hosted.

1. [Supabase Self-Hosting Runbook](/br/revista/supabase-self-hosting/)
2. [Next.js sobre Supabase com segurança](/br/revista/nextjs-supabase-configuracao-segura/)
3. [Supabase Edge Functions com segurança](/br/revista/supabase-edge-functions-seguranca/)
4. [Trigger.dev Background Jobs com segurança](/br/revista/trigger-dev-background-jobs/)
5. [Claude Code como controle de segurança no workflow DevOps](/br/revista/claude-code-security-devops/)
6. [Security Baseline para o stack completo](/br/revista/security-baseline-stack/) - este artigo

Este artigo conecta todos os runbooks anteriores em uma **estratégia de segurança verificável**.

## Visão geral da arquitetura

```
security-baseline.yml
   |
   +---> scripts/check-baseline.sh     (determinístico, diário)
   |       |
   |       +---> baseline-report.md    (fatos: aprovado/reprovado)
   |
   +---> Claude Code Audit             (contextual, semanal)
   |       |
   |       +---> claude-review.md      (interpretação + prioridades)
   |
   +---> Deployment Gate               (CI/CD, a cada deploy)
           |
           +---> Deploy bloqueado quando regras críticas são violadas
```

A Baseline é a **Single Source of Truth** para o estado de segurança. Todo o resto - os scripts de verificação, o Claude Code, os checklists de deployment dos Artigos 1 a 5 - é derivado dela.

### Categorias do Baseline

| Categoria | Número de regras | Frequência de verificação | Escalação |
|---|---|---|---|
| Infraestrutura (artigo 1) | 8 | Diária | CRÍTICO: imediatamente, AVISO: esta semana |
| Supabase Platform (artigo 1) | 6 | Diária | CRÍTICO: imediatamente |
| Next.js (artigo 2) | 7 | Diária + em PR | CRÍTICO: bloqueio de deploy |
| Edge Functions (artigo 3) | 4 | Diária | CRÍTICO: imediatamente |
| Trigger.dev (artigo 4) | 5 | Diária | AVISO: esta semana |
| Compliance | 3 | Semanal | CRÍTICO: imediatamente |

## O security-baseline.yml

Este arquivo pertence ao root do repositório de infraestrutura. Ele é legível por máquina (YAML), legível por humanos (comentários) e interpretável pelo Claude Code (contexto).

```yaml
# security-baseline.yml
# Security Baseline für den self-hosted Stack
# Letzte Aktualisierung: 2026-03-12
# Verantwortlich: DevOps Team
#
# Diese Datei definiert den Soll-Zustand des gesamten Stacks.
# Sie wird täglich automatisch geprüft (scripts/check-baseline.sh)
# und wöchentlich von Claude Code kontextuell analysiert.

version: "1.0"
stack: "supabase-nextjs-trigger"
last_reviewed: "2026-03-12"

# =============================================
# INFRASTRUKTUR (Artikel 1)
# =============================================

infrastructure:
  servers:
    production:
      host: "10.0.1.10"
      external_hostname: "app.example.com"
      provider: "hetzner"    # CLOUD-Act-frei
    audit:
      host: "10.0.1.11"
      purpose: "security checks, monitoring, claude code"

  network:
    private_subnet: "10.0.1.0/24"
    # Nur diese Ports dürfen von aussen erreichbar sein
    allowed_external_ports:
      - 443    # HTTPS (über Reverse Proxy)
    # Diese Ports dürfen NUR intern erreichbar sein
    internal_only_ports:
      - 5432   # PostgreSQL (Supabase)
      - 5433   # PostgreSQL (Trigger.dev)
      - 8000   # Kong API Gateway
      - 3000   # Next.js (hinter Reverse Proxy)
      - 3040   # Trigger.dev Dashboard
      - 9000   # Supabase Studio

  firewall:
    layers: 2    # Cloud Firewall + Host Firewall
    baseline_file: "/opt/baselines/firewall-baseline.txt"
    drift_check: "daily"

  tls:
    provider: "letsencrypt"
    min_days_before_expiry: 14
    headers_required:
      - "Strict-Transport-Security"
      - "X-Frame-Options"
      - "X-Content-Type-Options"
      - "Content-Security-Policy"

  ssh:
    password_auth: false
    root_login: false
    pubkey_only: true
    allowed_users: ["deploy"]

  backups:
    frequency: "daily"
    max_age_hours: 26
    encryption: "gpg"
    external_storage: true    # auf audit-runner, nicht nur lokal
    restore_test: "monthly"

# =============================================
# SUPABASE PLATFORM (Artikel 1)
# =============================================

supabase:
  images:
    pinned: true              # kein :latest
    # Erwartete Images und Versionen (aktualisieren bei Updates)
    postgres: "supabase/postgres:15.6.1.143"
    kong: "kong:2.8.1"
    gotrue: "supabase/gotrue:v2.164.0"

  postgres:
    listen_address: "10.0.1.10"    # NUR internes Interface
    rls:
      required_on_all_public_tables: true
      # Tabellen die bewusst ohne RLS sind (mit Begründung)
      exceptions: []

  gotrue:
    jwt_exp: 3600               # max. 1 Stunde
    mailer_autoconfirm: false
    refresh_token_rotation: true

  studio:
    external_access: false      # nur über SSH Tunnel oder VPN

  secrets:
    env_file: ".env"
    env_file_permissions: "600"
    in_git: false
    min_length: 16
    # Erwartete Secrets (ohne Werte)
    required:
      - "JWT_SECRET"
      - "ANON_KEY"
      - "SERVICE_ROLE_KEY"
      - "POSTGRES_PASSWORD"
      - "DASHBOARD_USERNAME"
      - "DASHBOARD_PASSWORD"

# =============================================
# NEXT.JS APP LAYER (Artikel 2)
# =============================================

nextjs:
  service_role:
    # Dateien in denen service_role erlaubt ist
    allowed_files:
      - "lib/supabase/admin.ts"
    # Darf NIEMALS erscheinen in:
    forbidden_patterns:
      - "NEXT_PUBLIC_*"
      - "app/**/*.tsx"           # Client Components
      - ".next/static/**"        # Client Bundle

  auth:
    middleware_required: true
    middleware_file: "middleware.ts"
    middleware_uses: "getUser"     # NICHT getSession
    server_actions_require_auth: true
    route_handlers_require_auth: true

  security_headers:
    required:
      - "Strict-Transport-Security"
      - "X-Frame-Options"
      - "Content-Security-Policy"
      - "X-Content-Type-Options"

  env_vars:
    # Nur diese dürfen NEXT_PUBLIC sein
    allowed_public:
      - "NEXT_PUBLIC_SUPABASE_URL"
      - "NEXT_PUBLIC_SUPABASE_ANON_KEY"

  rate_limiting:
    required_endpoints:
      - "/api/auth/login"
      - "/api/auth/signup"
      - "/api/auth/reset"

# =============================================
# EDGE FUNCTIONS (Artikel 3)
# =============================================

edge_functions:
  purpose: "integrations_only"     # NICHT für Business-Logik
  runtime: "deno"

  requirements:
    webhook_signature_check: true
    input_validation: true
    cors_no_wildcard_in_production: true
    no_hardcoded_secrets: true
    max_duration_seconds: 60

  secrets:
    env_file: ".env.functions"
    in_git: false

  deployment:
    method: "volume_copy"          # Dateien ins Volume, Container restart

# =============================================
# TRIGGER.DEV (Artikel 4)
# =============================================

trigger_dev:
  version: "v3"
  hosting: "self-hosted"
  separate_database: true           # eigene PostgreSQL, nicht Supabase DB

  dashboard:
    external_access: false          # nur SSH Tunnel oder VPN

  task_requirements:
    max_duration_required: true
    concurrency_limit_required: true
    retry_config_required: true
    idempotency_on_external_calls: true
    exported: true                  # alle Tasks müssen exportiert sein

  logging:
    use_trigger_logger: true        # nicht console.log
    no_sensitive_data: true

  db_access:
    # Dateien in denen service_role / DATABASE_URL erlaubt ist
    allowed_files:
      - "trigger/lib/supabase.ts"
      - "trigger/lib/db.ts"
    connection_pool_max: 10

# =============================================
# CLAUDE CODE AUDIT (Artikel 5)
# =============================================

claude_code:
  runs_on: "audit-runner"           # NICHT auf Produktion
  allowed_tools: "Read,Grep,Glob"   # kein Bash
  max_turns: 10
  schedule: "weekly"                # Sonntag 06:00
  alert_on: "KRITISCH"

  api_key:
    separate_ci_key: true
    budget_limit_monthly_usd: 50

# =============================================
# COMPLIANCE
# =============================================

compliance:
  cloud_act:
    us_providers_allowed: false
    reason: "CLOUD Act Risiko: US-Behörden können Datenzugriff erzwingen"
    allowed_jurisdictions:
      - "EU"
      - "BR"

  data_residency:
    required: true
    allowed_countries:
      - "DE"     # Deutschland (Hetzner)
      - "BR"     # Brasilien

  git:
    no_secrets_in_repo: true
    infrastructure_as_code: true
    no_manual_server_changes: true
```

## O script de verificação da Baseline

Este script lê o `security-baseline.yml` e verifica cada ponto automaticamente. Ele roda diariamente no servidor de auditoria.

```bash
#!/bin/bash
# scripts/check-baseline.sh
# Prüft den Produktionsserver gegen die security-baseline.yml
# Läuft auf dem audit-runner (10.0.1.11)

set -euo pipefail

PROD_HOST="10.0.1.10"
EXTERNAL_HOST="app.example.com"
REPORT=""
CRITICAL=0
WARNING=0
PASS=0

check() {
  local level="$1"    # KRITISCH, WARNUNG, INFO
  local name="$2"
  local result="$3"   # PASS oder FAIL
  local detail="$4"

  if [ "$result" = "PASS" ]; then
    REPORT+="  OK ${name}\n"
    ((PASS++))
  else
    REPORT+="  FAIL [${level}] ${name}: ${detail}\n"
    [ "$level" = "KRITISCH" ] && ((CRITICAL++))
    [ "$level" = "WARNUNG" ] && ((WARNING++))
  fi
}

echo "=== Security Baseline Check $(date +%Y-%m-%d) ==="

# -------------------------------------------
# INFRASTRUKTUR
# -------------------------------------------
REPORT+="\n## Infrastruktur\n\n"

# Ports von aussen
OPEN_PORTS=$(nmap -p 22,80,443,3000,3040,5432,5433,8000,9000 "$EXTERNAL_HOST" \
  -oG - 2>/dev/null | grep -oP '\d+/open' | grep -v "443" || true)
if [ -z "$OPEN_PORTS" ]; then
  check "KRITISCH" "Nur Port 443 extern offen" "PASS" ""
else
  check "KRITISCH" "Nur Port 443 extern offen" "FAIL" "Offen: $OPEN_PORTS"
fi

# Firewall Drift
FW_DIFF=$(ssh deploy@${PROD_HOST} "iptables-save" 2>/dev/null | \
  diff /opt/baselines/firewall-baseline.txt - 2>&1 || true)
if [ -z "$FW_DIFF" ]; then
  check "WARNUNG" "Firewall unverändert" "PASS" ""
else
  check "WARNUNG" "Firewall unverändert" "FAIL" "Firewall hat sich geändert"
fi

# SSH Konfiguration
SSH_PW=$(ssh deploy@${PROD_HOST} "sshd -T 2>/dev/null | grep passwordauthentication" || true)
if echo "$SSH_PW" | grep -q "no"; then
  check "KRITISCH" "SSH Passwort-Login deaktiviert" "PASS" ""
else
  check "KRITISCH" "SSH Passwort-Login deaktiviert" "FAIL" "Passwort-Auth noch aktiv"
fi

SSH_ROOT=$(ssh deploy@${PROD_HOST} "sshd -T 2>/dev/null | grep permitrootlogin" || true)
if echo "$SSH_ROOT" | grep -q "no"; then
  check "KRITISCH" "SSH Root-Login deaktiviert" "PASS" ""
else
  check "KRITISCH" "SSH Root-Login deaktiviert" "FAIL" "Root-Login noch möglich"
fi

# TLS Zertifikat
CERT_DAYS=$(echo | openssl s_client -connect ${EXTERNAL_HOST}:443 2>/dev/null | \
  openssl x509 -noout -enddate 2>/dev/null | cut -d= -f2)
if [ -n "$CERT_DAYS" ]; then
  EPOCH_CERT=$(date -d "$CERT_DAYS" +%s 2>/dev/null || echo 0)
  EPOCH_NOW=$(date +%s)
  DAYS_LEFT=$(( (EPOCH_CERT - EPOCH_NOW) / 86400 ))
  if [ "$DAYS_LEFT" -ge 14 ]; then
    check "WARNUNG" "TLS Zertifikat gültig (${DAYS_LEFT} Tage)" "PASS" ""
  else
    check "WARNUNG" "TLS Zertifikat gültig" "FAIL" "Nur noch ${DAYS_LEFT} Tage"
  fi
fi

# Security Headers
for HEADER in "Strict-Transport-Security" "X-Frame-Options" "X-Content-Type-Options"; do
  if curl -sI "https://${EXTERNAL_HOST}" | grep -qi "$HEADER"; then
    check "WARNUNG" "Header: ${HEADER}" "PASS" ""
  else
    check "WARNUNG" "Header: ${HEADER}" "FAIL" "Header fehlt"
  fi
done

# Backup
LAST_BACKUP=$(ssh deploy@${PROD_HOST} "ls -t /opt/backups/*.gpg 2>/dev/null | head -1" || true)
if [ -n "$LAST_BACKUP" ]; then
  BACKUP_AGE=$(ssh deploy@${PROD_HOST} \
    "echo \$(( (\$(date +%s) - \$(stat -c %Y ${LAST_BACKUP})) / 3600 ))" 2>/dev/null || echo 999)
  if [ "$BACKUP_AGE" -le 26 ]; then
    check "KRITISCH" "Backup aktuell (${BACKUP_AGE}h alt)" "PASS" ""
  else
    check "KRITISCH" "Backup aktuell" "FAIL" "${BACKUP_AGE} Stunden alt"
  fi
else
  check "KRITISCH" "Backup aktuell" "FAIL" "Kein Backup gefunden"
fi

# Disk Space
DISK=$(ssh deploy@${PROD_HOST} "df -h / | tail -1 | awk '{print \$5}' | tr -d '%'" 2>/dev/null || echo 99)
if [ "$DISK" -le 85 ]; then
  check "WARNUNG" "Disk Usage (${DISK}%)" "PASS" ""
else
  check "WARNUNG" "Disk Usage" "FAIL" "${DISK}% belegt"
fi

# -------------------------------------------
# SUPABASE
# -------------------------------------------
REPORT+="\n## Supabase\n\n"

# Container laufen
STOPPED=$(ssh deploy@${PROD_HOST} "cd /opt/supabase && docker compose ps --format json 2>/dev/null" | \
  jq -r 'select(.State != "running") | .Name' 2>/dev/null || true)
if [ -z "$STOPPED" ]; then
  check "KRITISCH" "Alle Supabase Container running" "PASS" ""
else
  check "KRITISCH" "Alle Supabase Container running" "FAIL" "Gestoppt: $STOPPED"
fi

# Images gepinnt (kein :latest)
LATEST_IMAGES=$(ssh deploy@${PROD_HOST} "cd /opt/supabase && grep 'image:' docker-compose.yml | grep 'latest'" 2>/dev/null || true)
if [ -z "$LATEST_IMAGES" ]; then
  check "WARNUNG" "Alle Images versioniert (kein :latest)" "PASS" ""
else
  check "WARNUNG" "Alle Images versioniert" "FAIL" "latest gefunden"
fi

# RLS auf allen public-Tabellen
UNPROTECTED=$(ssh deploy@${PROD_HOST} "cd /opt/supabase && docker compose exec -T postgres psql -U postgres -t -c \
  \"SELECT count(*) FROM pg_tables WHERE schemaname = 'public' AND rowsecurity = false;\"" 2>/dev/null | tr -d ' ' || echo "?")
if [ "$UNPROTECTED" = "0" ]; then
  check "KRITISCH" "RLS auf allen public-Tabellen aktiv" "PASS" ""
elif [ "$UNPROTECTED" != "?" ]; then
  check "KRITISCH" "RLS auf allen public-Tabellen aktiv" "FAIL" "${UNPROTECTED} Tabellen ohne RLS"
fi

# Postgres nur intern
PG_LISTEN=$(ssh deploy@${PROD_HOST} "ss -tlnp | grep 5432" 2>/dev/null || true)
if echo "$PG_LISTEN" | grep -q "0.0.0.0:5432"; then
  check "KRITISCH" "Postgres nur auf internem Interface" "FAIL" "Lauscht auf 0.0.0.0"
else
  check "KRITISCH" "Postgres nur auf internem Interface" "PASS" ""
fi

# Studio nicht extern erreichbar
STUDIO=$(curl -s -o /dev/null -w "%{http_code}" --connect-timeout 3 "https://${EXTERNAL_HOST}:9000" 2>/dev/null || echo "000")
if [ "$STUDIO" = "000" ]; then
  check "KRITISCH" "Supabase Studio nicht extern erreichbar" "PASS" ""
else
  check "KRITISCH" "Supabase Studio nicht extern erreichbar" "FAIL" "Status: $STUDIO"
fi

# -------------------------------------------
# NEXT.JS
# -------------------------------------------
REPORT+="\n## Next.js\n\n"

# service_role im Client Code
SR_LEAK=$(ssh deploy@${PROD_HOST} "cd /opt/app && grep -rn 'SERVICE_ROLE\|service_role' app/ \
  --include='*.ts' --include='*.tsx' 2>/dev/null | grep -v 'lib/supabase/admin.ts' | grep -v node_modules" 2>/dev/null || true)
if [ -z "$SR_LEAK" ]; then
  check "KRITISCH" "service_role nicht im Client Code" "PASS" ""
else
  check "KRITISCH" "service_role nicht im Client Code" "FAIL" "Gefunden in: $(echo "$SR_LEAK" | head -3)"
fi

# NEXT_PUBLIC mit Secrets
PUB_SECRET=$(ssh deploy@${PROD_HOST} "cd /opt/app && grep 'NEXT_PUBLIC_' .env* 2>/dev/null | \
  grep -iE 'service_role|secret|private|database'" 2>/dev/null || true)
if [ -z "$PUB_SECRET" ]; then
  check "KRITISCH" "Keine Secrets in NEXT_PUBLIC Variablen" "PASS" ""
else
  check "KRITISCH" "Keine Secrets in NEXT_PUBLIC Variablen" "FAIL" "$PUB_SECRET"
fi

# middleware.ts existiert und nutzt getUser
MW_EXISTS=$(ssh deploy@${PROD_HOST} "test -f /opt/app/middleware.ts && echo yes || echo no" 2>/dev/null || echo "no")
if [ "$MW_EXISTS" = "yes" ]; then
  MW_GETUSER=$(ssh deploy@${PROD_HOST} "grep -c 'getUser' /opt/app/middleware.ts" 2>/dev/null || echo "0")
  if [ "$MW_GETUSER" -gt 0 ]; then
    check "KRITISCH" "middleware.ts existiert mit getUser()" "PASS" ""
  else
    check "KRITISCH" "middleware.ts mit getUser()" "FAIL" "getUser() fehlt"
  fi
else
  check "KRITISCH" "middleware.ts existiert" "FAIL" "Datei fehlt"
fi

# Server Actions ohne Auth
SA_NO_AUTH=$(ssh deploy@${PROD_HOST} "cd /opt/app && for file in \$(grep -rl \"'use server'\" app/ --include='*.ts' 2>/dev/null); do
  if ! grep -q 'getUser' \"\$file\"; then echo \"\$file\"; fi
done" 2>/dev/null || true)
if [ -z "$SA_NO_AUTH" ]; then
  check "WARNUNG" "Alle Server Actions haben Auth Check" "PASS" ""
else
  check "WARNUNG" "Server Actions ohne Auth" "FAIL" "$SA_NO_AUTH"
fi

# npm audit
NPM_HIGH=$(ssh deploy@${PROD_HOST} "cd /opt/app && npm audit --audit-level=high 2>&1 | \
  grep -c 'high\|critical'" 2>/dev/null || echo "0")
if [ "$NPM_HIGH" = "0" ]; then
  check "WARNUNG" "npm audit: keine high/critical" "PASS" ""
else
  check "WARNUNG" "npm audit" "FAIL" "${NPM_HIGH} high/critical Findings"
fi

# -------------------------------------------
# EDGE FUNCTIONS
# -------------------------------------------
REPORT+="\n## Edge Functions\n\n"

# Webhook Functions ohne Signaturprüfung
WH_NO_SIG=$(ssh deploy@${PROD_HOST} "for dir in /opt/supabase/volumes/functions/*-webhook/; do
  [ -d \"\$dir\" ] || continue
  name=\$(basename \"\$dir\")
  if ! grep -qE 'signature|verify|hmac|crypto' \"\$dir/index.ts\" 2>/dev/null; then
    echo \"\$name\"
  fi
done" 2>/dev/null || true)
if [ -z "$WH_NO_SIG" ]; then
  check "KRITISCH" "Alle Webhooks prüfen Signaturen" "PASS" ""
else
  check "KRITISCH" "Webhooks ohne Signaturprüfung" "FAIL" "$WH_NO_SIG"
fi

# Hardcoded Secrets
FN_SECRETS=$(ssh deploy@${PROD_HOST} "grep -rn 'sk_live\|sk_test\|whsec_\|Bearer ey' \
  /opt/supabase/volumes/functions/ --include='*.ts' 2>/dev/null" || true)
if [ -z "$FN_SECRETS" ]; then
  check "KRITISCH" "Keine hardcoded Secrets in Functions" "PASS" ""
else
  check "KRITISCH" "Hardcoded Secrets in Functions" "FAIL" "$FN_SECRETS"
fi

# -------------------------------------------
# TRIGGER.DEV
# -------------------------------------------
REPORT+="\n## Trigger.dev\n\n"

# Tasks ohne maxDuration
TD_NO_DUR=$(ssh deploy@${PROD_HOST} "cd /opt/app && for file in trigger/tasks/*.ts 2>/dev/null; do
  [ -f \"\$file\" ] || continue
  name=\$(basename \"\$file\" .ts)
  if ! grep -q 'maxDuration' \"\$file\"; then echo \"\$name\"; fi
done" 2>/dev/null || true)
if [ -z "$TD_NO_DUR" ]; then
  check "WARNUNG" "Alle Tasks haben maxDuration" "PASS" ""
else
  check "WARNUNG" "Tasks ohne maxDuration" "FAIL" "$TD_NO_DUR"
fi

# Tasks ohne Concurrency
TD_NO_CC=$(ssh deploy@${PROD_HOST} "cd /opt/app && for file in trigger/tasks/*.ts 2>/dev/null; do
  [ -f \"\$file\" ] || continue
  name=\$(basename \"\$file\" .ts)
  if ! grep -qE 'concurrencyLimit|queue:' \"\$file\"; then echo \"\$name\"; fi
done" 2>/dev/null || true)
if [ -z "$TD_NO_CC" ]; then
  check "WARNUNG" "Alle Tasks haben Concurrency Limit" "PASS" ""
else
  check "WARNUNG" "Tasks ohne Concurrency" "FAIL" "$TD_NO_CC"
fi

# Hardcoded Secrets in Tasks
TD_SECRETS=$(ssh deploy@${PROD_HOST} "grep -rn 'sk_live\|sk_test\|SG\.\|sk-' \
  /opt/app/trigger/ --include='*.ts' 2>/dev/null" || true)
if [ -z "$TD_SECRETS" ]; then
  check "KRITISCH" "Keine hardcoded Secrets in Tasks" "PASS" ""
else
  check "KRITISCH" "Hardcoded Secrets in Tasks" "FAIL" "$TD_SECRETS"
fi

# Trigger.dev Dashboard nicht extern
TD_DASH=$(curl -s -o /dev/null -w "%{http_code}" --connect-timeout 3 "https://${EXTERNAL_HOST}:3040" 2>/dev/null || echo "000")
if [ "$TD_DASH" = "000" ]; then
  check "KRITISCH" "Trigger.dev Dashboard nicht extern" "PASS" ""
else
  check "KRITISCH" "Trigger.dev Dashboard nicht extern" "FAIL" "Status: $TD_DASH"
fi

# -------------------------------------------
# COMPLIANCE
# -------------------------------------------
REPORT+="\n## Compliance\n\n"

# Git: keine Secrets im Repo
GIT_SECRETS=$(ssh deploy@${PROD_HOST} "cd /opt/app && git ls-files .env .env.functions .env.trigger 2>/dev/null" || true)
if [ -z "$GIT_SECRETS" ]; then
  check "KRITISCH" ".env Dateien nicht im Git" "PASS" ""
else
  check "KRITISCH" ".env Dateien im Git" "FAIL" "Committed: $GIT_SECRETS"
fi

# Git: keine uncommitted Changes auf dem Server
GIT_DIRTY=$(ssh deploy@${PROD_HOST} "cd /opt/app && git status --porcelain 2>/dev/null" || true)
if [ -z "$GIT_DIRTY" ]; then
  check "WARNUNG" "Keine manuellen Änderungen auf Server" "PASS" ""
else
  check "WARNUNG" "Manuelle Änderungen auf Server" "FAIL" "$(echo "$GIT_DIRTY" | wc -l) Dateien"
fi

# -------------------------------------------
# ZUSAMMENFASSUNG
# -------------------------------------------

SUMMARY="\n## Zusammenfassung\n\n"
SUMMARY+="Bestanden: ${PASS}\n"
SUMMARY+="Warnungen: ${WARNING}\n"
SUMMARY+="Kritisch:  ${CRITICAL}\n"

TOTAL_REPORT="${SUMMARY}\n${REPORT}"

# Report speichern
REPORT_FILE="/opt/audit/reports/baseline-$(date +%Y-%m-%d).md"
echo -e "# Security Baseline Check $(date +%Y-%m-%d)\n${TOTAL_REPORT}" > "$REPORT_FILE"

echo -e "$TOTAL_REPORT"

# Alert bei kritischen Findings
if [ "$CRITICAL" -gt 0 ]; then
  echo ""
  echo "!!! ${CRITICAL} KRITISCHE FINDINGS !!!"
  echo -e "$TOTAL_REPORT" | mail -s "KRITISCH: Baseline Check $(date)" ops@example.com
  exit 1
fi

exit 0
```

## Integração com o Claude Code (Artigo 5)

O script de verificação da Baseline entrega fatos. O Claude Code os interpreta. O audit semanal do [Artigo 5](/br/revista/claude-code-security-devops/) utiliza o relatório da Baseline como input:

```bash
# Im Gesamt-Audit-Script (scripts/full-security-audit.sh aus Artikel 5)
# Nach den deterministischen Checks:

# Baseline-Report des heutigen Tages einlesen
BASELINE_REPORT=$(cat /opt/audit/reports/baseline-$(date +%Y-%m-%d).md 2>/dev/null || echo "Kein Baseline-Report vorhanden")

# An Claude Code übergeben
echo "$BASELINE_REPORT" | claude -p \
  "Du erhältst den Baseline-Check-Report unseres self-hosted Stacks.
Die Baseline ist definiert in security-baseline.yml.

Analysiere:
1. Welche KRITISCHEN Findings brauchen sofortige Aufmerksamkeit?
2. Gibt es Muster in den WARNUNGEN die auf systematische Probleme hindeuten?
3. Haben sich Findings gegenüber der Vorwoche verändert? (Vergleiche mit letztem Report)
4. Welche Prioritäten empfiehlst du für diese Woche?

Antworte auf Deutsch. Sei konkret." \
  --allowedTools "Read,Grep,Glob" \
  --output-format text \
  --max-turns 5
```

## Manutenção da Baseline

O `security-baseline.yml` não é um documento estático. Ele evolui junto com o stack.

**Quando atualizar:**

```
Neue Tabelle in Supabase           -> rls.exceptions prüfen
Neuer Service im Docker Stack      -> internal_only_ports erweitern
Neues NEXT_PUBLIC Env Var          -> allowed_public erweitern
Neues Secret                       -> required Secrets erweitern
Neue Edge Function                 -> Prüfregeln gelten automatisch
Neuer Trigger.dev Task             -> Prüfregeln gelten automatisch
Hoster-Wechsel                     -> server/provider anpassen
```

**Workflow para alterações na Baseline:**

```
1. Änderung in security-baseline.yml im Git
2. PR Review (inkl. Begründung warum die Regel sich ändert)
3. Claude Code prüft den Diff der Baseline selbst:
   "Ist diese Lockerung der Regeln gerechtfertigt?"
4. Merge nach Approval
5. Nächster Baseline-Check nutzt die neuen Regeln
```

## Configuração do Cron

```bash
# crontab auf dem audit-runner

# Täglicher Baseline-Check (06:00 Uhr)
0 6 * * * /opt/audit/scripts/check-baseline.sh >> /var/log/baseline-check.log 2>&1

# Wöchentlicher Claude Code Audit (Sonntag 07:00 Uhr, nach dem Baseline-Check)
0 7 * * 0 /opt/audit/scripts/full-security-audit.sh >> /var/log/security-audit.log 2>&1
```

## Checklist de deployment

```
Baseline-Datei
  [ ] security-baseline.yml im Repo vorhanden
  [ ] Alle Server-IPs und Hostnames aktuell
  [ ] Alle erwarteten Secrets gelistet (ohne Werte)
  [ ] Alle erlaubten NEXT_PUBLIC Variablen gelistet
  [ ] Alle service_role-erlaubten Dateien gelistet
  [ ] RLS Exceptions dokumentiert (mit Begründung)
  [ ] Compliance-Regeln (CLOUD Act, Data Residency) definiert

Check-Script
  [ ] check-baseline.sh auf audit-runner ausführbar
  [ ] SSH Key vom audit-runner zum prod-Server eingerichtet
  [ ] Firewall-Baseline gespeichert (/opt/baselines/)
  [ ] Täglicher Cron Job aktiv
  [ ] Alert-Versand konfiguriert (E-Mail bei KRITISCH)

Integration
  [ ] Claude Code auf audit-runner installiert
  [ ] Wöchentlicher Audit-Cron aktiv
  [ ] CLAUDE.md im Repo vorhanden (Artikel 5)
  [ ] .claude/commands/security-review.md vorhanden (Artikel 5)
  [ ] Reports werden archiviert (/opt/audit/reports/)
```

## Conclusão

A Security Baseline é o elemento de conexão de toda a série de runbooks. Os Artigos 1 a 4 definem o que precisa estar configurado de forma segura. O Artigo 5 define como o Claude Code verifica essas regras. O Artigo 6 reúne tudo em um único arquivo YAML que pode ser lido tanto por scripts quanto pelo Claude Code.

A verificação diária da Baseline entrega fatos: aprovado ou reprovado. O audit semanal do Claude Code interpreta esses fatos no contexto. Um ser humano decide o que deve ser priorizado. Esse modelo de três camadas cobre tanto riscos conhecidos quanto inesperados, sem que uma única camada seja responsável sozinha pela segurança.

> **Estatística:** Organizações que utilizam verificações automatizadas de baseline detectam drift de configuração em média 11 vezes mais rápido do que aquelas que dependem de auditorias manuais (relatório Puppet State of DevOps 2024).


Quem segue esta Baseline junto com uma [arquitetura Cert-Ready-by-Design](/br/revista/cert-ready-by-design/) constrói segurança verificável em vez de auditorias posteriores.

Com isso, a **série de runbooks DevOps está completa**.

<div class="not-prose my-12 border border-gosign-border bg-gosign-light rounded-card p-6 lg:p-8">
<div class="flex items-start gap-4">
<div class="flex-shrink-0 w-12 h-12 bg-gosign-dark rounded-card flex items-center justify-center">
<svg width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="white" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 15v4a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2v-4"/><polyline points="7 10 12 15 17 10"/><line x1="12" y1="15" x2="12" y2="3"/></svg>
</div>
<div>
<h2 class="text-h3 font-bold text-gosign-dark mb-2" id="checklists-de-auditoria-da-serie">Checklists de auditoria da série</h2>
<p class="text-body text-gosign-text mb-4">Prompts preparados para o Claude Code. Cada checklist verifica automaticamente os pontos de segurança do respectivo runbook e reporta APROVADO, AVISO ou CRÍTICO.</p>
<div class="flex flex-wrap gap-3">
<a href="/downloads/claude-check-artikel-1-supabase-br.md" download class="inline-flex items-center px-4 py-2 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-sm">Supabase Infrastructure</a>
<a href="/downloads/claude-check-artikel-2-nextjs-br.md" download class="inline-flex items-center px-4 py-2 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-sm">Next.js Security</a>
<a href="/downloads/claude-check-artikel-3-edge-functions-br.md" download class="inline-flex items-center px-4 py-2 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-sm">Edge Functions</a>
<a href="/downloads/claude-check-artikel-4-trigger-dev-br.md" download class="inline-flex items-center px-4 py-2 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-sm">Trigger.dev</a>
</div>
</div>
</div>
</div>

## Sumário da série

1. [Supabase Self-Hosting Runbook](/br/revista/supabase-self-hosting/)
2. [Next.js sobre Supabase com segurança](/br/revista/nextjs-supabase-configuracao-segura/)
3. [Supabase Edge Functions com segurança](/br/revista/supabase-edge-functions-seguranca/)
4. [Trigger.dev Background Jobs com segurança](/br/revista/trigger-dev-background-jobs/)
5. [Claude Code como controle de segurança no workflow DevOps](/br/revista/claude-code-security-devops/)
6. [Security Baseline para o stack completo](/br/revista/security-baseline-stack/) - este artigo

--- Segurança de dados em IA: Data Residency, LGPD e EU AI Act ---
> Como garantir segurança de dados em IA corporativa? Data Residency, processamento exclusivo na UE, Row-Level Security, isolamento de mandantes.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Resumo - Segurança de dados em IA corporativa</p>
<ul class="text-body text-gosign-text space-y-2">
<li>A primeira pergunta para todo CISO e DPO: onde os dados são processados, quem tem acesso, quanto tempo são armazenados. Com ferramentas públicas de IA, a resposta é inaceitável para empresas reguladas.</li>
<li>Três modelos de implantação: self-hosted (nenhum dado sai da rede), nuvem apenas UE (processamento em data centers da UE) ou híbrido (dados sensíveis self-hosted, não críticos via nuvem).</li>
<li>IBM Cost of a Data Breach Report (2024) revelou que o custo médio de uma violação de dados atingiu 4,88 milhões USD - o mais alto já registrado.</li>
<li>O isolamento de mandantes por Row-Level Security, separação de workspaces e isolamento de prompts é crítico para escritórios de auditoria, consultoria tributária e centros de serviços compartilhados.</li>
<li>Segurança de dados em IA corporativa é uma decisão de arquitetura, não de política - a infraestrutura correta torna a conformidade verificável em vez de declaratória.</li>
</ul>
</div>

## A pergunta central: Onde estao os dados?

Quando um agente de IA le uma fatura, processa um atestado médico ou responde uma consulta de compliance, ele esta processando dados corporativos. Dados de faturamento, dados pessoais, segredos comerciais. A primeira pergunta de todo CISO e Encarregado de Proteção de Dados (DPO): Onde esses dados são processados? Quem tem acesso? Por quanto tempo são armazenados?

Ao usar ChatGPT, Gemini ou CoPilot, a resposta e: os dados são transmitidos a servidores externos, processados por um terceiro e podem ser usados para fins de treinamento. Para empresas reguladas, essa não e uma resposta aceitavel.

## Tres modelos de implantacao

A [arquitetura Gosign](/br/governance/) suporta tres modelos de implantacao. A escolha depende do nível de proteção exigido para os dados.

**Self-Hosted:** Todos os componentes (modelos, agentes, bancos de dados) rodam na infraestrutura do cliente. Nenhum dado sai da rede corporativa. Isso inclui os modelos de linguagem: modelos open source como [Llama](https://llama.meta.com/), [Mistral](https://mistral.ai/), [DeepSeek](https://www.deepseek.com/) ou gpt-oss podem ser executados localmente.

**Nuvem (apenas UE):** Processamento em data centers da UE em Azure, GCP ou AWS. Data Processing Agreement, Standard Contractual Clauses. Os modelos são modelos na nuvem (Claude, ChatGPT, Gemini), mas o processamento permanece na UE. Nota: para empresas portuguesas, esse modelo atende ao RGPD diretamente. Para empresas brasileiras, a conformidade com a LGPD (PT: RGPD) requer atencao especial as regras de transferencia internacional (arts. 33-36 da LGPD).

**Hibrido:** Dados sensiveis (dados pessoais, dados financeiros) são processados em self-hosted. Dados não críticos podem ser processados por modelos na nuvem. O roteamento entre self-hosted e nuvem e baseado em regras e automático.

## Data Residency em detalhe

Data Residency vai alem da localizacao dos servidores. Abrange:

**Local de processamento:** Onde o modelo de linguagem e executado? Em self-hosted: no data center próprio. Em nuvem: em um data center da UE definido.

**Local de armazenamento:** Onde os dados processados são armazenados? Audit Trails, conjuntos de dados de decisões, documentos. Tudo na mesma regiao do processamento.

**Rota de transito:** Como os dados chegam ao modelo e retornam? Em self-hosted: rede interna. Em nuvem: conexão criptografada ao data center da UE. Sem transito por paises terceiros.

**Backups:** Onde os backups são armazenados? Os backups devem atender aos mesmos requisitos de Data Residency que os dados primarios.

## Isolamento de mandantes

Para escritorios de auditoria e consultoria tributária, bem como para centros de serviços compartilhados, o isolamento de mandantes e crítico para o negocio. Os dados de um mandante não podem ser visiveis para outros mandantes, tampouco para o sistema de IA.

O isolamento e implementado em multiplas camadas:

**Separacao de workspaces:** Cada mandante tem seu próprio workspace com chaves de API separadas, armazenamento de documentos separado e configurações de modelos separadas.

**Row-Level Security:** No nível do banco de dados, Row-Level Security garante que as consultas retornem apenas dados do mandante atual. Mesmo que um agente execute acidentalmente uma consulta entre mandantes, o banco de dados retorna apenas resultados do mandante autorizado.

**Isolamento de prompts:** Prompts e regras são específicos de cada mandante. O agente de um mandante não tem acesso aos prompts ou regras de outros mandantes.

## Conformidade com a LGPD e o RGPD

A LGPD (BR) e o RGPD (PT) estabelecem requisitos para o tratamento de dados pessoais. No contexto de IA:

**Base legal:** O tratamento de dados pessoais por agentes de IA requer base legal. No contexto trabalhista: execução de contrato (art. 7, V da LGPD / art. 6.1.b do RGPD) ou interesse legitimo (art. 7, IX da LGPD / art. 6.1.f do RGPD). A ANPD (BR) e a CNPD (PT) supervisionam o cumprimento dessas bases.

**Minimizacao de dados:** O agente processa apenas os dados necessarios para a finalidade específica. Sem armazenamento permanente de documentos no modelo. Sem uso de dados de clientes para fins de treinamento.

**Direito de acesso:** Os titulares de dados podem solicitar informações sobre os dados processados. O Audit Trail documenta cada tratamento de dados pessoais.

**Eliminacao:** Os dados são eliminados apos o termino do prazo de retenção. A eliminação inclui também o Audit Trail apos o vencimento dos prazos legais de retenção. No Brasil, a LGPD preve o direito de eliminação no art. 18, VI. Em Portugal, o RGPD estabelece o mesmo no art. 17.

## Checklist de segurança de dados por modelo de implantação

| Requisito de segurança | Self-Hosted | Nuvem apenas UE | Híbrido |
|---|---|---|---|
| Dados saem da rede corporativa | Não | Sim (para data center UE) | Sensíveis: Não / Não críticos: Sim |
| Treinamento do modelo com dados corporativos | Não possível | Excluído via DPA | Excluído via DPA |
| Mecanismo de conformidade LGPD | Controle total by design | DPA + SCCs + zonas de processamento UE | Routing por classe de dados |
| Isolamento de mandantes | Workspace + RLS + isolamento de prompts | Workspace + RLS + isolamento de prompts | Workspace + RLS + isolamento de prompts |
| Localização do Audit Trail | On-Premises | Data center UE | Dividido: on-prem + nuvem UE |
| Residency de backups | Igual aos dados primários | Mesma região UE | Conforme classificação de dados |
| Latência | Mínima (rede local) | Latência de rede UE | Variável conforme classe de dados |

Mais informações: [Data Residency](/br/governance/data-residency/)

<a href="/br/contato/" target="_blank" rel="noopener noreferrer">Agendar uma reunião</a> - Mostramos as opções de Data Residency adequadas as suas necessidades.

--- Série DevOps Runbook: segurança para o stack self-hosted ---
> Série de seis DevOps Runbooks: Supabase, Next.js, Edge Functions, Trigger.dev, auditorias Claude Code e Security Baseline.

Esta série fornece seis runbooks práticos para operar um stack de aplicações self-hosted com segurança. É destinada a equipes DevOps que operam Supabase, Next.js e tecnologias relacionadas em produção e querem proteger sua infraestrutura de forma sistemática.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Resumo - Série DevOps Runbook</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Seis runbooks cobrem o stack self-hosted completo: Supabase, Next.js, Edge Functions, Trigger.dev, auditorias Claude Code e Security Baseline.</li>
<li>Cada artigo contém implementações concretas com código real, condições verificáveis e checklists do Claude Code para download.</li>
<li>A série se constrói camada por camada - da fundação da plataforma (Supabase) até uma baseline YAML legível por máquina para todo o stack.</li>
<li>Público-alvo: engenheiros DevOps, CTOs, engenheiros de segurança e desenvolvedores que constroem sobre Supabase e Next.js.</li>
<li>De acordo com o SANS Institute (2024), organizações com uma Security Baseline legível por máquina detectam drift de configuração 14 vezes mais rápido.</li>
</ul>
</div>

## Por que uma abordagem sistemática importa

O self-hosting dá controle sobre dados e infraestrutura. Esse controle vem com responsabilidade: cada componente tem seus próprios requisitos de segurança, e as dependências entre camadas permanecem invisíveis quando revisadas isoladamente.

Uma abordagem de segurança sistemática e legível por máquina em todas as camadas faz a diferença. De acordo com o SANS Institute (2024), organizações com uma Security Baseline legível por máquina detectam drift de configuração em média **14 vezes mais rápido** do que equipes sem baseline.

Esta série percorre o stack camada por camada e conclui com uma baseline baseada em YAML que consolida todas as regras dos runbooks individuais.

## Visão geral da série

| Parte | Artigo | Área de foco | Entregável principal |
|-------|--------|--------------|----------------------|
| 1 | [Supabase Self-Hosting Runbook](/br/revista/supabase-self-hosting/) | Fundação da plataforma | Arquitetura de servidores, Docker Compose, RLS |
| 2 | [Next.js sobre Supabase com segurança](/br/revista/nextjs-supabase-configuracao-segura/) | Camada de aplicação | Auth, Middleware, separação de ambientes |
| 3 | [Supabase Edge Functions com segurança](/br/revista/supabase-edge-functions-seguranca/) | Integrações | Webhooks, assinaturas, CORS |
| 4 | [Trigger.dev Background Jobs em produção segura](/br/revista/trigger-dev-background-jobs/) | Processamento async | Tasks, idempotência, concorrência |
| 5 | [Claude Code como controle de segurança no workflow DevOps](/br/revista/claude-code-security-devops/) | Auditorias automatizadas | Custom commands, modo headless |
| 6 | [Security Baseline para todo o stack](/br/revista/security-baseline-stack/) | Baseline do stack completo | YAML, verificações automatizadas |

## Os artigos em detalhe

**Parte 1 - Supabase Self-Hosting Runbook.** Descreve uma arquitetura de dois servidores (produção e auditoria), Docker Compose com imagens versionadas, configuração de sete serviços e Row Level Security como requisito em todas as tabelas públicas.

**Parte 2 - Next.js sobre Supabase.** Cobre a camada de aplicação sobre o Supabase: fluxo de auth com PKCE, middleware para proteção de rotas, separação estrita de ambientes entre servidor e cliente e padrões seguros de API route.

**Parte 3 - Edge Functions.** Foca no processamento de webhooks com verificação de assinaturas, configuração CORS, validação de entrada no runtime Deno e gerenciamento seguro de secrets para integrações com terceiros.

**Parte 4 - Trigger.dev Background Jobs.** Descreve o setup self-hosted do Trigger.dev v3, definição idempotente de tasks, controle de concorrência, estratégias de retry e isolamento de secrets entre tasks.

**Parte 5 - Claude Code como controle de segurança.** Mostra como usar o Claude Code como ferramenta automatizada de auditoria no workflow DevOps: custom commands, execuções de auditoria headless e integração com CI.

**Parte 6 - Security Baseline.** Consolida todas as regras dos artigos 1 a 5 em um arquivo legível por máquina `security-baseline.yml`. Inclui scripts de verificação determinísticos e integração com a auditoria do Claude Code.

## Para quem é esta série

- Engenheiros DevOps que operam infraestrutura self-hosted
- CTOs e líderes técnicos avaliando self-hosting vs. serviços gerenciados
- Engenheiros de segurança auditando stacks de aplicações
- Desenvolvedores que constroem sobre Supabase e Next.js

## Como usar esta série

- Leia os artigos em ordem de 1 a 6, pois se constroem um sobre o outro
- Baixe as checklists do Claude Code no final de cada artigo
- Implemente as recomendações camada por camada no seu ambiente
- Use a Security Baseline do artigo 6 como porta de monitoramento diária

--- Shadow AI na empresa - Governance em vez de proibição ---
> Uso descontrolado de IA (Shadow AI) é um problema de governance. A solução não é proibir, mas infraestrutura controlada com Audit Trail e Model Routing.

## O que é Shadow AI?

Shadow AI é o equivalente de IA da Shadow IT. Colaboradores usam ChatGPT, Google Gemini, Microsoft CoPilot ou outras ferramentas de IA para seu trabalho - sem conhecimento, aprovação ou controle do departamento de TI.

O analista que insere uma reclamação de cliente no ChatGPT para formular uma resposta. A profissional de RH que elabora uma referência profissional via CoPilot. O controller que analisa números trimestrais no Gemini. Cada um desses usos envia dados da empresa para um serviço externo.

Shadow AI não é mal-intencionada. Colaboradores usam ferramentas de IA porque se tornam mais produtivos. Mas sem governance, a organização não tem controle sobre quais dados saem da empresa, quais modelos são utilizados e se os resultados são rastreáveis.

No Brasil, cada envio de dados pessoais para serviços externos sem base legal configura potencial infração à LGPD (PT: RGPD). Multas podem chegar a 2% do faturamento, limitadas a R$ 50 milhões por infração.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Resumo - Shadow AI Governance</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Shadow AI significa que colaboradores usam ferramentas de IA externas sem conhecimento da TI, enviando dados da empresa para sistemas não controlados.</li>
<li>Proibições não funcionam - colaboradores usam dispositivos pessoais e ferramentas alternativas. A proibição gera evasão descontrolada.</li>
<li>PwC (2024) constatou que 54% das empresas têm colaboradores usando ferramentas de IA generativa sem aprovação formal da organização.</li>
<li>A solução é infraestrutura controlada: interface de IA empresarial, Model Routing, protocolo de uso e Audit Trail.</li>
<li>Três fases: inventário do uso atual, implantação de infraestrutura controlada, depois agentes especializados para casos de uso frequentes.</li>
</ul>
</div>

## Por que proibições não funcionam

A reação mais óbvia a Shadow AI é a proibição. Muitas empresas bloquearam ChatGPT e ferramentas similares - por regra de firewall, por diretriz, por ACT (Acordo Coletivo de Trabalho) (PT: Acordo de empresa).

O problema: proibições não funcionam. Colaboradores usam seus smartphones pessoais. Usam extensões de navegador. Usam ferramentas alternativas que ainda não estão na lista de bloqueio. A proibição não gera compliance - gera evasão descontrolada.

Ao mesmo tempo, a empresa perde a vantagem de produtividade que a IA pode oferecer. Enquanto os colaboradores escondem seu uso de IA, a TI não consegue apoiar, direcionar nem otimizar.

## A alternativa: infraestrutura de IA controlada

A solução não é proibição, mas infraestrutura. Uma infraestrutura de IA empresarial dá aos colaboradores ferramentas de IA potentes - sob controle da organização.

**Interface de IA empresarial:** Em vez de ChatGPT, colaboradores usam uma interface de chat interna que acessa modelos empresariais. A experiência de uso é idêntica. A diferença: todos os dados permanecem na infraestrutura própria.

**Model Routing:** A TI decide quais modelos são usados para quais casos de uso. Dados sensíveis vão para modelos self-hosted. Solicitações não-críticas podem ser roteadas para modelos em nuvem. A decisão é baseada em regras e rastreável.

**Protocolo de uso:** Cada uso de IA é registrado - não para vigiar colaboradores, mas para direcionar o uso de IA. Quais departamentos usam IA mais? Para quais tarefas? Com quais modelos? Esses dados são a base para o próximo passo: agentes especializados para os casos de uso mais frequentes.

**Audit Trail:** Em áreas reguladas - finanças, RH, compliance - cada decisão apoiada por IA é documentada no Audit Trail. O Decision Layer garante que processos críticos de negócio não se baseiem em outputs de IA descontrolados.

## De Shadow AI a Governance by Design

Shadow AI é um sintoma. A causa é falta de infraestrutura. Se colaboradores não têm ferramentas de IA controladas, usam as descontroladas.

| Fase | Foco | Entregáveis-chave |
|------|------|-------------------|
| 1 - Inventário | Mapear o uso atual de IA em todos os departamentos | Inventário de ferramentas, análise de fluxo de dados, classificação de risco |
| 2 - Infraestrutura controlada | Plataforma de IA empresarial com governança | Hosting LLM, interface de chat, Model Routing, protocolo de uso |
| 3 - Agentes especializados | Agentes dedicados para casos de uso frequentes | Document Agent, Knowledge Agent, Workflow Agent - cada um com Decision Layer |

O caminho de Shadow AI para [Governance by Design](/br/governance/):

**Fase 1: Inventário.** Quais ferramentas de IA estão sendo usadas na empresa? Para quais tarefas? Com quais dados? Esse inventário frequentemente é revelador - o uso real de IA supera significativamente o uso oficial.

**Fase 2: Infraestrutura controlada.** Construção de uma infraestrutura de IA empresarial. Hosting de LLM, interface de chat, Model Routing, protocolo de uso. Colaboradores recebem uma ferramenta pelo menos tão potente quanto ChatGPT - mas sob controle da TI.

**Fase 3: Agentes especializados.** A partir dos casos de uso mais frequentes, são desenvolvidos agentes especializados. Em vez de um chat genérico, há um Document Agent para processamento de documentos, um Knowledge Agent para perguntas de RH, um Workflow Agent para processamento de faturas. Cada agente com Decision Layer e governance.

## O risco de não agir

Shadow AI não vai desaparecer. As ferramentas de IA ficam melhores, mais acessíveis, mais integradas em software existente. Cada atualização do Office traz novas funcionalidades de IA. Cada navegador tem recursos de IA.

Empresas que não constroem uma infraestrutura de IA controlada vão constatar que seus colaboradores já usam IA - sem governance, sem Audit Trail, sem verificação de conformidade com a LGPD. A questão não é se, mas quando isso se torna um problema. Na próxima fiscalização. Na próxima solicitação de titular de dados sob a LGPD. No próximo vazamento de dados.

No Brasil, o risco é amplificado pela Autoridade Nacional de Proteção de Dados (ANPD), que já está em plena atividade fiscalizatória. Em Portugal, a CNPD exerce papel equivalente no âmbito do RGPD.

Mais informações: [Decision Layer e Shadow AI](/br/revista/decision-layer-shadow-ai/) | [Enterprise AI Chat Interface](/br/revista/enterprise-ai-chat-interface/)

<a href="/br/contato/" target="_blank" rel="noopener noreferrer">Agendar reunião</a> - Mostramos como transformar Shadow AI em infraestrutura de IA controlada.

--- Supabase Edge Functions com segurança ---
> Runbook DevOps para Supabase Edge Functions: webhooks, assinaturas, CORS, Deno runtime, validação de entrada e integração com Claude Code.

Supabase Edge Functions são funções TypeScript do lado do servidor que rodam no Deno Runtime e são acessíveis pelo Kong API Gateway.

Elas são particularmente adequadas para webhooks, integrações com APIs externas, endpoints de eventos assinados e lógica leve do lado do servidor.

> **Estatística:** De acordo com dados do Stripe, mais de 12% das integrações de webhooks não verificam assinaturas - tornando-as vulneráveis a eventos falsificados.


O erro mais comum é utilizar Edge Functions como um **segundo sistema de backend**. Isso leva a lógica de negócio duplicada, limites de segurança pouco claros e arquiteturas difíceis de debugar.

Este runbook descreve como Edge Functions são utilizadas com segurança no [setup self-hosted](/br/revista/supabase-self-hosting/). Cada passo contém uma implementação concreta com código Deno real, uma condição verificável e um cenário de falha.

> **Nota sobre o runtime:** As Supabase Edge Functions são baseadas em **Deno**, não em Node.js. Isso afeta a sintaxe de import, o sistema de módulos e as APIs disponíveis. Todos os exemplos de código neste artigo são compatíveis com Deno. Edge Functions self-hosted rodam no container `supabase/edge-runtime` e atualmente ainda são classificadas como Beta.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Resumo - Artigo 3 de 6 da série DevOps Runbook</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Edge Functions apenas como pontos de integração (webhooks), não segundo backend</li>
<li>Verificação obrigatória de assinaturas de webhooks</li>
<li>CORS configurado explicitamente (sem wildcard)</li>
<li>Validação de entrada com Zod</li>
<li>Tarefas de longa duração delegadas ao Trigger.dev</li>
</ul>
</div>

## Sumário da série

Este guia faz parte da nossa série de runbooks DevOps para stacks de aplicações self-hosted.

1. [Supabase Self-Hosting Runbook](/br/revista/supabase-self-hosting/)
2. [Next.js sobre Supabase com segurança](/br/revista/nextjs-supabase-configuracao-segura/)
3. Supabase Edge Functions com segurança - este artigo
4. [Trigger.dev Background Jobs com segurança](/br/revista/trigger-dev-background-jobs/)
5. [Claude Code como controle de segurança no workflow DevOps](/br/revista/claude-code-security-devops/)
6. [Security Baseline para todo o stack](/br/revista/security-baseline-stack/)

O artigo 1 descreve a plataforma.
O artigo 2 descreve a camada de aplicação Next.js.
Este artigo descreve **integrações e webhooks**.

## Visão geral da arquitetura

```
Browser
   |
Next.js (camada de aplicação)
   |
   +-- Supabase Client (anon key)     -> para requests de usuários
   |
Kong API Gateway
   |
   +-- PostgREST                       -> REST API com RLS
   +-- GoTrue                          -> Auth
   +-- Edge Runtime                    -> Edge Functions
   |     |
   |     +-- stripe-webhook
   |     +-- github-webhook
   |     +-- trigger-webhook
   |
PostgreSQL + RLS Policies

Serviços externos
   |
   +-- Stripe / GitHub / Trigger.dev   -> chamam os webhooks
```

Regra fundamental:

```
Edge Functions são pontos de integração para eventos externos.
Lógica de negócio pertence ao [Next.js](/br/revista/nextjs-supabase-configuracao-segura/) (Server Actions / Route Handler).
Processos de longa duração pertencem ao [Trigger.dev](/br/revista/trigger-dev-background-jobs/).
```


### Tabela de decisão

| Critério | Edge Function | Server Action | Trigger.dev Task |
|---|---|---|---|
| Origem | Evento externo (webhook) | Entrada do usuário | Tarefa interna |
| Tempo de execução | < 30 segundos | < 10 segundos | Até 5 minutos+ |
| Autenticação | Assinatura HMAC | Sessão do usuário (JWT) | Chave API / service_role |
| RLS | Ignorado (service_role) | Ativo (anon key) | Ignorado (service_role) |
| Retry | Provedor do webhook | Nenhum (síncrono) | Integrado (Trigger.dev) |
| Exemplo | Stripe checkout webhook | Formulário de perfil | Geração de PDF |

### Critério de decisão

Quando uma função reage a um **evento externo** (Stripe Payment, GitHub Push, Trigger.dev Callback), ela é uma Edge Function. Quando ela reage a **input de usuário** e transforma dados, ela pertence ao Next.js. Quando ela **roda por mais de 30 segundos**, ela pertence ao Trigger.dev.

## Como Edge Functions rodam no setup Self-Hosted

No stack Docker Compose self-hosted, a configuração das Edge Functions é a seguinte:

```yaml
# docker-compose.yml (trecho)
functions:
  container_name: supabase-edge-functions
  image: supabase/edge-runtime:v1.66.4    # fixar versão
  restart: unless-stopped
  depends_on:
    - analytics
  environment:
    JWT_SECRET: ${JWT_SECRET}
    SUPABASE_URL: http://kong:8000                    # hostname Docker interno
    SUPABASE_ANON_KEY: ${ANON_KEY}
    SUPABASE_SERVICE_ROLE_KEY: ${SERVICE_ROLE_KEY}
    SUPABASE_DB_URL: postgresql://postgres:${POSTGRES_PASSWORD}@${POSTGRES_HOST}:${POSTGRES_PORT}/${POSTGRES_DB}
    VERIFY_JWT: "${FUNCTIONS_VERIFY_JWT}"
  volumes:
    - ./volumes/functions:/home/deno/functions:Z
  command:
    - start
    - --main-service
    - /home/deno/functions/main
```

As Edge Functions ficam como arquivos TypeScript no volume:

```
volumes/functions/
  main/
    index.ts              <- Router / Main Service
  _shared/
    cors.ts               <- CORS Headers (compartilhado)
    supabase-client.ts    <- Supabase Client Factory (compartilhado)
  stripe-webhook/
    index.ts
  github-webhook/
    index.ts
```

**Deployment no setup Self-Hosted:** as funções são colocadas como arquivos no volume e o container é reiniciado:

```bash
# Copiar functions para o volume
cp -r supabase/functions/* /opt/supabase/volumes/functions/

# Reiniciar o container
docker compose restart functions --no-deps
```

## Parte A - Decisões de arquitetura

Essas decisões são tomadas uma vez e raramente alteradas.

## A1 - Edge Functions apenas para integrações, não como segundo backend

### Implementação

Definição clara de qual lógica pertence a qual camada:

```
Edge Functions (Deno):
  Recebimento de webhooks (Stripe, GitHub, APIs externas)
  Sync baseado em eventos (DB Webhook -> serviço externo)
  Verificação de assinatura de eventos recebidos
  Transformações leves (< 30 segundos)

Next.js (Server Actions / Route Handler):
  Mutations voltadas ao usuário (CRUD)
  Operações baseadas em sessão
  Lógica de negócio
  Validação de input com contexto de usuário

Trigger.dev (Background Jobs):
  Geração de PDF
  Tarefas de IA
  Envio de e-mails em massa
  Tudo com tempo de execução acima de 30 segundos
```

### Condição verificável

```bash
# Quantas Edge Functions existem?
ls -d volumes/functions/*/ | grep -v "main\|_shared" | wc -l

# Para cada Function verificar: é uma integração?
for dir in volumes/functions/*/; do
  name=$(basename "$dir")
  [[ "$name" == "main" || "$name" == "_shared" ]] && continue
  echo "--- $name ---"
  # Contém patterns de Webhook/Integração?
  grep -l "signature\|webhook\|stripe\|github\|trigger" "$dir"*.ts 2>/dev/null || \
    echo "AVISO: nenhum pattern de Webhook/Integração encontrado"
done
```

### Cenário de falha

Quando lógica de negócio é implementada em Edge Functions, surge uma arquitetura sombra: a mesma validação existe nas Server Actions do Next.js E nas Edge Functions, com diferenças sutis. Bugs se tornam difíceis de reproduzir, pois não fica claro qual caminho de código estava ativo. Lógica de autenticação precisa ser mantida em dois lugares.

## A2 - Isolar endpoints de webhook: uma função por webhook

### Implementação

Cada provedor de webhook recebe uma função própria em um diretório próprio:

```
volumes/functions/
  stripe-webhook/
    index.ts
  github-webhook/
    index.ts
  trigger-webhook/
    index.ts
```

**Não faça assim:**

```
volumes/functions/
  webhooks/
    index.ts     <- processa Stripe, GitHub e Trigger em um único arquivo
```

### Condição verificável

```bash
# Cada Webhook Function deve atender exatamente um provedor
for dir in volumes/functions/*-webhook/; do
  name=$(basename "$dir")
  providers=$(grep -ciE "stripe|github|trigger|slack|sendgrid" "$dir/index.ts")
  if [ "$providers" -gt 1 ]; then
    echo "AVISO: $name atende múltiplos provedores ($providers)"
  fi
done
```

### Cenário de falha

Quando múltiplos webhooks são processados em uma única função, eles compartilham o mesmo error handler. Um payload Stripe com erro pode bloquear o webhook do GitHub. Estratégias de retry diferem por provedor (Stripe usa exponential backoff, GitHub apenas 3x), o que dificilmente pode ser implementado de forma limpa em uma função compartilhada.

## A3 - Configurar CORS corretamente

### Implementação

Edge Functions chamadas pelo navegador (mesmo indiretamente) precisam de headers CORS. O Supabase não fornece configuração CORS automática para Edge Functions.

Configuração CORS compartilhada:

```typescript
// volumes/functions/_shared/cors.ts

const allowedOrigins = [
  'https://app.example.com',
  ...(Deno.env.get('ENVIRONMENT') === 'development'
    ? ['http://localhost:3000']
    : [])
]

export function getCorsHeaders(req: Request) {
  const origin = req.headers.get('origin') ?? ''
  const corsOrigin = allowedOrigins.includes(origin) ? origin : ''

  return {
    'Access-Control-Allow-Origin': corsOrigin,
    'Access-Control-Allow-Headers':
      'authorization, x-client-info, apikey, content-type',
    'Access-Control-Allow-Methods': 'POST, GET, OPTIONS',
  }
}
```

**Cada Edge Function** precisa tratar CORS no início:

```typescript
import { getCorsHeaders } from '../_shared/cors.ts'

Deno.serve(async (req) => {
  const corsHeaders = getCorsHeaders(req)

  // CORS Preflight deve ser a PRIMEIRA verificação
  if (req.method === 'OPTIONS') {
    return new Response('ok', { headers: corsHeaders })
  }

  // ... lógica principal

  return new Response(JSON.stringify(data), {
    headers: { ...corsHeaders, 'Content-Type': 'application/json' },
  })
})
```

### Condição verificável

```bash
# Todas as Functions precisam tratar CORS
for dir in volumes/functions/*/; do
  name=$(basename "$dir")
  [[ "$name" == "main" || "$name" == "_shared" ]] && continue
  if ! grep -q "OPTIONS" "$dir/index.ts" 2>/dev/null; then
    echo "AVISO: $name não tem handler OPTIONS"
  fi
done

# Nenhum CORS wildcard em produção
grep -r "'\\*'" volumes/functions/ --include="*.ts" | grep -i "allow-origin"
# Esperado: nenhum resultado (exceto em branches de desenvolvimento)
```

### Cenário de falha

Sem headers CORS, todos os requests do navegador para Edge Functions falham. O navegador bloqueia a response, mesmo que a função responda corretamente. Isso se manifesta como um erro CORS enigmático no console. Com CORS wildcard (`'*'`) em produção, qualquer site pode enviar requests para suas Edge Functions e ler as responses.

## Parte B - Verificações de implementação

Estas verificações valem para cada Edge Function e devem ser conferidas a cada deployment.

## B1 - Verificar assinaturas de webhook

### Implementação

Cada endpoint de webhook precisa verificar a assinatura do serviço remetente. Sem verificação de assinatura, qualquer pessoa pode enviar payloads arbitrários para a Function.

**Exemplo completo de Stripe Webhook:**

```typescript
// volumes/functions/stripe-webhook/index.ts

import { getCorsHeaders } from '../_shared/cors.ts'

const STRIPE_WEBHOOK_SECRET = Deno.env.get('STRIPE_WEBHOOK_SECRET')

Deno.serve(async (req) => {
  const corsHeaders = getCorsHeaders(req)

  if (req.method === 'OPTIONS') {
    return new Response('ok', { headers: corsHeaders })
  }

  // 1. Permitir apenas POST
  if (req.method !== 'POST') {
    return new Response(
      JSON.stringify({ error: 'Method not allowed' }),
      { status: 405, headers: { ...corsHeaders, 'Content-Type': 'application/json' } }
    )
  }

  // 2. Verificar assinatura
  const signature = req.headers.get('stripe-signature')
  if (!signature) {
    return new Response(
      JSON.stringify({ error: 'Missing signature' }),
      { status: 401, headers: { ...corsHeaders, 'Content-Type': 'application/json' } }
    )
  }

  const body = await req.text()

  const isValid = await verifyStripeSignature(body, signature, STRIPE_WEBHOOK_SECRET!)
  if (!isValid) {
    return new Response(
      JSON.stringify({ error: 'Invalid signature' }),
      { status: 401, headers: { ...corsHeaders, 'Content-Type': 'application/json' } }
    )
  }

  // 3. Processar evento
  const event = JSON.parse(body)

  switch (event.type) {
    case 'checkout.session.completed':
      await handleCheckoutCompleted(event.data.object)
      break
    case 'invoice.payment_failed':
      await handlePaymentFailed(event.data.object)
      break
    default:
      // Ignorar eventos desconhecidos, não falhar
      console.log(`Unhandled event type: ${event.type}`)
  }

  // 4. Sempre retornar 200 (caso contrário o Stripe faz retry)
  return new Response(
    JSON.stringify({ received: true }),
    { status: 200, headers: { ...corsHeaders, 'Content-Type': 'application/json' } }
  )
})

// Verificação de assinatura Stripe com Deno Crypto API
async function verifyStripeSignature(
  payload: string,
  header: string,
  secret: string
): Promise<boolean> {
  const parts = header.split(',')
  const timestamp = parts.find(p => p.startsWith('t='))?.split('=')[1]
  const signature = parts.find(p => p.startsWith('v1='))?.split('=')[1]

  if (!timestamp || !signature) return false

  // Timing Check: rejeitar eventos com mais de 5 minutos
  const now = Math.floor(Date.now() / 1000)
  if (now - parseInt(timestamp) > 300) return false

  const signedPayload = `${timestamp}.${payload}`
  const key = await crypto.subtle.importKey(
    'raw',
    new TextEncoder().encode(secret),
    { name: 'HMAC', hash: 'SHA-256' },
    false,
    ['sign']
  )

  const sig = await crypto.subtle.sign(
    'HMAC',
    key,
    new TextEncoder().encode(signedPayload)
  )

  const expectedSig = Array.from(new Uint8Array(sig))
    .map(b => b.toString(16).padStart(2, '0'))
    .join('')

  return expectedSig === signature
}

async function handleCheckoutCompleted(session: Record<string, unknown>) {
  console.log(`Checkout completed: ${session.id}`)
}

async function handlePaymentFailed(invoice: Record<string, unknown>) {
  console.log(`Payment failed: ${invoice.id}`)
}
```

**Verificação de assinatura de webhook do GitHub (procedimento diferente):**

```typescript
// volumes/functions/github-webhook/index.ts

const GITHUB_WEBHOOK_SECRET = Deno.env.get('GITHUB_WEBHOOK_SECRET')

async function verifyGitHubSignature(
  payload: string,
  signatureHeader: string,
  secret: string
): Promise<boolean> {
  // GitHub usa sha256=<hex>
  const expected = signatureHeader.replace('sha256=', '')

  const key = await crypto.subtle.importKey(
    'raw',
    new TextEncoder().encode(secret),
    { name: 'HMAC', hash: 'SHA-256' },
    false,
    ['sign']
  )

  const sig = await crypto.subtle.sign(
    'HMAC',
    key,
    new TextEncoder().encode(payload)
  )

  const computed = Array.from(new Uint8Array(sig))
    .map(b => b.toString(16).padStart(2, '0'))
    .join('')

  return computed === expected
}
```

### Condição verificável

```bash
# Cada Webhook Function precisa ter verificação de assinatura
for dir in volumes/functions/*-webhook/; do
  name=$(basename "$dir")
  if ! grep -qE "signature|verify|hmac" "$dir/index.ts" 2>/dev/null; then
    echo "CRITICO: $name não possui verificação de assinatura"
  else
    echo "OK: $name verifica assinaturas"
  fi
done

# Verificar configuração VERIFY_JWT
# Webhooks precisam de VERIFY_JWT=false, pois serviços externos não enviam JWT do Supabase
grep "VERIFY_JWT" .env
```

### Cenário de falha

Sem verificação de assinatura, um invasor pode enviar eventos arbitrários para o webhook:

```bash
curl -X POST https://app.example.com/functions/v1/stripe-webhook \
  -H "Content-Type: application/json" \
  -d '{"type":"checkout.session.completed","data":{"object":{"customer":"cus_fake"}}}'
```

Esse request dispararia uma confirmação de checkout falsificada. A função atualizaria o status do usuário, embora nunca tenha havido pagamento.

## B2 - Inicializar Supabase Client corretamente (anon vs. service_role)

### Implementação

Edge Functions têm acesso a todas as variáveis de ambiente do Supabase. A escolha entre a chave `anon` e a chave `service_role` é a decisão de segurança mais importante por Function.

**Client Factory compartilhada:**

```typescript
// volumes/functions/_shared/supabase-client.ts

import { createClient, SupabaseClient } from 'npm:@supabase/supabase-js@2'

// Client COM RLS (para operações com contexto de usuário)
export function createAnonClient(authHeader?: string): SupabaseClient {
  const client = createClient(
    Deno.env.get('SUPABASE_URL')!,
    Deno.env.get('SUPABASE_ANON_KEY')!,
    {
      global: {
        headers: authHeader ? { Authorization: authHeader } : {},
      },
    }
  )
  return client
}

// Client SEM RLS (para processamento de webhook, tarefas admin)
// ATENÇÃO: ignora todas as Row Level Security Policies
export function createAdminClient(): SupabaseClient {
  return createClient(
    Deno.env.get('SUPABASE_URL')!,
    Deno.env.get('SUPABASE_SERVICE_ROLE_KEY')!
  )
}
```

**Quando usar qual client:**

```
createAnonClient(authHeader):
  Functions voltadas ao usuário (raro, geralmente pertencem ao Next.js)
  Quando RLS deve controlar o acesso

createAdminClient():
  Processamento de webhook (Stripe, GitHub)
  Tarefas de sync internas
  Quando a Function NÃO tem contexto de usuário

Regra geral: webhooks não têm contexto de usuário,
portanto precisam de service_role.
Mas: executar apenas as operações mínimas necessárias.
```

### Condição verificável

```bash
# Onde service_role / Admin Client é utilizado?
grep -rn "SERVICE_ROLE\|createAdminClient\|service_role" \
  volumes/functions/ --include="*.ts" | grep -v "_shared/"

# Esperado: apenas em Webhook Functions, não em Functions voltadas ao usuário

# O Admin Client recebe input de usuário não validado?
# Review manual: em cada Function que usa createAdminClient,
# verificar se o input é validado antes da operação no banco
```

### Cenário de falha

Quando uma Edge Function roda com `service_role` e repassa input de usuário diretamente em queries, ela ignora o RLS completamente. Um payload de webhook manipulado poderia então ler ou escrever dados arbitrários em quaisquer tabelas, pois a chave `service_role` não possui restrições.

## B3 - Validação de entrada

### Implementação

Cada Edge Function precisa validar os dados recebidos antes de processá-los. No Deno, o Zod funciona via import npm:

```typescript
// volumes/functions/stripe-webhook/index.ts (trecho)

import { z } from 'npm:zod@3'

// Schema para o evento Stripe esperado
const stripeEventSchema = z.object({
  id: z.string().startsWith('evt_'),
  type: z.string(),
  data: z.object({
    object: z.record(z.unknown()),
  }),
})

// Na função principal após a verificação de assinatura:
const parsed = stripeEventSchema.safeParse(JSON.parse(body))

if (!parsed.success) {
  return new Response(
    JSON.stringify({ error: 'Invalid payload structure' }),
    { status: 400, headers: { ...corsHeaders, 'Content-Type': 'application/json' } }
  )
}

// A partir daqui trabalhar com parsed.data (type-safe)
const event = parsed.data
```

### Condição verificável

```bash
# Cada Function deve ter validação de entrada
for dir in volumes/functions/*/; do
  name=$(basename "$dir")
  [[ "$name" == "main" || "$name" == "_shared" ]] && continue
  if grep -qE "zod|safeParse|z\.object|z\.string" "$dir/index.ts" 2>/dev/null; then
    echo "OK: $name possui Schema Validation"
  elif grep -qE "JSON\.parse" "$dir/index.ts" 2>/dev/null; then
    echo "AVISO: $name faz parse de JSON sem Schema Validation"
  fi
done
```

### Cenário de falha

Sem validação de entrada, a Function aceita qualquer payload que tenha uma assinatura válida. Uma chave de API comprometida no provedor de webhook poderia então enviar estruturas de dados inesperadas, levando a operações de banco de dados indefinidas, por exemplo `undefined` como User-ID em um insert.

## B4 - Secrets em variáveis de ambiente, nunca no código

### Implementação

No setup Self-Hosted, os secrets são passados para as Edge Functions pela configuração do Docker Compose:

```yaml
# docker-compose.yml (trecho)
functions:
  environment:
    JWT_SECRET: ${JWT_SECRET}
    SUPABASE_URL: http://kong:8000
    SUPABASE_ANON_KEY: ${ANON_KEY}
    SUPABASE_SERVICE_ROLE_KEY: ${SERVICE_ROLE_KEY}
  env_file:
    - .env.functions    # secrets adicionais para Functions
```

```bash
# .env.functions (apenas no servidor, não no Git)
STRIPE_WEBHOOK_SECRET=whsec_...
STRIPE_SECRET_KEY=sk_live_...
GITHUB_WEBHOOK_SECRET=ghsec_...
TRIGGER_DEV_API_KEY=tr_...
```

Acessar no código:

```typescript
// Assim: variável de ambiente
const secret = Deno.env.get('STRIPE_WEBHOOK_SECRET')

// NUNCA assim: hardcoded
const secret = 'whsec_abc123...'
```

Para os fundamentos gerais de gerenciamento de secrets, consulte [Segurança de dados na infraestrutura enterprise de IA](/br/revista/seguranca-dados-ia-enterprise/).

### Condição verificável

```bash
# Secrets hardcoded no código?
grep -rn "sk_live\|sk_test\|whsec_\|ghsec_\|Bearer ey" \
  volumes/functions/ --include="*.ts"
# Esperado: nenhum resultado

# .env.functions não está no Git?
git ls-files .env.functions
# Esperado: vazio

# Permissões de arquivo corretas?
stat -c "%a" .env.functions
# Esperado: 600
```

### Cenário de falha

Secrets hardcoded no código-fonte acabam no repositório Git. Mesmo que o repositório seja privado, todos os desenvolvedores com acesso ao repo também têm acesso aos secrets de produção. Em um push acidental para público, os secrets ficam imediatamente comprometidos.

## B5 - Evitar timeouts e processos de longa duração

### Implementação

Edge Functions são projetadas para operações curtas e idempotentes. O Edge Runtime Self-Hosted possui um timeout padrão (configurável, tipicamente 60 segundos para self-hosted). Processos de longa duração bloqueiam slots de worker.

```
Adequado (< 30 segundos):
  Receber webhook e atualizar o banco
  Verificar assinatura e encaminhar evento
  Chamadas curtas de API para serviços externos

NÃO adequado (usar Trigger.dev):
  Geração de PDF
  Inferência de IA (chamadas LLM)
  Processamento de vídeo/imagem
  Operações de banco de dados em massa
  Envio de e-mail para muitos destinatários
```

**Pattern para processos longos: Edge Function como trigger, job no Trigger.dev:**

```typescript
// volumes/functions/process-document/index.ts

// CORRETO: Edge Function apenas dispara o job
Deno.serve(async (req) => {
  // ... verificar assinatura, validar input ...

  // Delegar job de longa duração ao Trigger.dev
  const triggerResponse = await fetch(
    `${Deno.env.get('TRIGGER_DEV_URL')}/api/v1/tasks/process-document/trigger`,
    {
      method: 'POST',
      headers: {
        'Authorization': `Bearer ${Deno.env.get('TRIGGER_DEV_API_KEY')}`,
        'Content-Type': 'application/json',
      },
      body: JSON.stringify({
        payload: { documentId: parsed.data.documentId },
      }),
    }
  )

  // Responder imediatamente, o job roda em background
  return new Response(
    JSON.stringify({ queued: true }),
    { status: 202, headers: { 'Content-Type': 'application/json' } }
  )
})
```

### Condição verificável

```bash
# Procurar patterns que indicam processos longos
grep -rn "await.*fetch.*openai\|pdf\|sharp\|ffmpeg\|sleep\|setTimeout" \
  volumes/functions/ --include="*.ts" | grep -v "trigger"
# Esperado: nenhum resultado (exceto chamadas curtas de API)

# Existem timeouts no código?
grep -rn "AbortSignal.timeout\|setTimeout" \
  volumes/functions/ --include="*.ts"
# Cada fetch externo deveria ter um timeout
```

### Cenário de falha

Uma Edge Function que espera 2 minutos por uma chamada de API de IA bloqueia um slot de worker no container do Edge Runtime. Com múltiplos requests simultâneos, os workers ficam lotados e chamadas de webhook subsequentes (por exemplo do Stripe) falham com timeout. O Stripe interpreta isso como erro e faz retry, o que piora a situação.

## B6 - Error handling e responses seguras

### Implementação

Edge Functions não podem vazar detalhes internos para o chamador em caso de erro.

```typescript
// Pattern para error handling seguro

Deno.serve(async (req) => {
  const corsHeaders = getCorsHeaders(req)

  if (req.method === 'OPTIONS') {
    return new Response('ok', { headers: corsHeaders })
  }

  try {
    // ... lógica principal ...

    return new Response(
      JSON.stringify({ success: true }),
      { status: 200, headers: { ...corsHeaders, 'Content-Type': 'application/json' } }
    )

  } catch (error) {
    // Log interno (detalhes)
    console.error(`Function error: ${error.message}`, {
      stack: error.stack,
      // NÃO logar secrets ou dados de usuário
    })

    // Resposta externa (genérica)
    return new Response(
      JSON.stringify({ error: 'Internal server error' }),
      { status: 500, headers: { ...corsHeaders, 'Content-Type': 'application/json' } }
    )
  }
})
```

**O que NÃO pertence a responses ou logs:**

```typescript
// ERRADO: enviar stack trace ao cliente
return new Response(JSON.stringify({ error: error.stack }), { status: 500 })

// ERRADO: logar secrets
console.log(`Connecting with key: ${Deno.env.get('SERVICE_ROLE_KEY')}`)

// ERRADO: logar dados completos do usuário
console.log(`Processing user: ${JSON.stringify(user)}`)
```

### Condição verificável

```bash
# Detalhes de erro são enviados ao cliente?
grep -rn "error\.stack\|error\.message" volumes/functions/ --include="*.ts" | \
  grep "Response"
# Esperado: nenhum resultado (stack/message apenas em console.error)

# Secrets são logados?
grep -rn "console\.log.*KEY\|console\.log.*SECRET\|console\.log.*token" \
  volumes/functions/ --include="*.ts"
# Esperado: nenhum resultado
```

### Cenário de falha

Quando um stack trace de erro é enviado ao cliente, um invasor vê caminhos internos, nomes de módulos e detalhes de conexão com o banco de dados. Isso facilita consideravelmente ataques direcionados. Quando secrets aparecem em logs, ficam visíveis para qualquer pessoa com acesso ao monitoramento.

## Parte C - Operação e monitoramento

## C1 - Workflow de deployment

### Implementação

No setup Self-Hosted não existe um comando `supabase functions deploy`. O workflow é baseado em arquivos:

```bash
#!/bin/bash
# scripts/deploy-functions.sh

set -euo pipefail

FUNCTIONS_DIR="/opt/supabase/volumes/functions"
SOURCE_DIR="./supabase/functions"

echo "Deploying Edge Functions..."

# 1. Verificação de sintaxe (Deno)
for file in $(find "$SOURCE_DIR" -name "*.ts" -not -path "*/_shared/*"); do
  deno check "$file" 2>/dev/null || {
    echo "ERRO: erro de sintaxe em $file"
    exit 1
  }
done

# 2. Copiar Functions
rsync -av --delete \
  --exclude='*.test.ts' \
  "$SOURCE_DIR/" "$FUNCTIONS_DIR/"

# 3. Reiniciar container
docker compose restart functions --no-deps

# 4. Health Check
sleep 5
HEALTH=$(curl -s -o /dev/null -w "%{http_code}" \
  http://localhost:8000/functions/v1/hello 2>/dev/null || echo "000")

if [ "$HEALTH" = "200" ] || [ "$HEALTH" = "401" ]; then
  echo "Deployment de Edge Functions bem-sucedido"
else
  echo "AVISO: Health Check Status $HEALTH"
fi
```

### Condição verificável

```bash
# Container do Edge Runtime está rodando?
docker compose ps functions --format '{{.State}}'
# Esperado: running

# Functions estão acessíveis?
curl -s -o /dev/null -w "%{http_code}" \
  -H "Authorization: Bearer ${ANON_KEY}" \
  http://localhost:8000/functions/v1/stripe-webhook
# Esperado: 200 ou 405 (Method Not Allowed, pois é GET em vez de POST)
```

## C2 - Integração com Claude Code

O Claude Code verifica Edge Functions contextualmente como complemento aos checks determinísticos.

### Arquitetura

```
Git Push / PR
   |
   +-- Checks determinísticos (CI/CD)
   |   +-- grep por secrets hardcoded
   |   +-- grep por verificação de assinatura ausente
   |   +-- grep por validação de entrada ausente
   |   +-- grep por detalhes de erro em responses
   |   +-- Deno Type Check
   |
   +-- Análise Claude Code (semanal ou em PR)
       +-- Novas Functions sem verificação de assinatura?
       +-- Uso de service_role adequado?
       +-- Patterns de processos longos detectados?
       +-- Desvio de arquitetura (lógica de negócio em Functions)?
       +-- CORS correto para novas Functions?
```

### Script CI concreto

```bash
#!/bin/bash
# scripts/check-edge-functions.sh

REPORT=""
FUNCTIONS_DIR="volumes/functions"

# 1. Secrets hardcoded
SECRETS=$(grep -rn "sk_live\|sk_test\|whsec_\|Bearer ey" \
  "$FUNCTIONS_DIR" --include="*.ts" 2>/dev/null)
if [ -n "$SECRETS" ]; then
  REPORT+="CRITICO: Secrets hardcoded encontrados:\n$SECRETS\n\n"
fi

# 2. Webhook Functions sem verificação de assinatura
for dir in "$FUNCTIONS_DIR"/*-webhook/; do
  [ -d "$dir" ] || continue
  name=$(basename "$dir")
  if ! grep -qE "signature|verify|hmac|crypto" "$dir/index.ts" 2>/dev/null; then
    REPORT+="CRITICO: $name não possui verificação de assinatura\n"
  fi
done

# 3. Functions sem validação de entrada
for dir in "$FUNCTIONS_DIR"/*/; do
  name=$(basename "$dir")
  [[ "$name" == "main" || "$name" == "_shared" ]] && continue
  if grep -q "JSON.parse" "$dir/index.ts" 2>/dev/null && \
     ! grep -qE "zod|safeParse|z\." "$dir/index.ts" 2>/dev/null; then
    REPORT+="AVISO: $name faz parse de JSON sem Schema Validation\n"
  fi
done

# 4. Detalhes de erro em responses
LEAKS=$(grep -rn "error\.stack\|error\.message" "$FUNCTIONS_DIR" --include="*.ts" | \
  grep "Response" 2>/dev/null)
if [ -n "$LEAKS" ]; then
  REPORT+="AVISO: Detalhes de erro em responses:\n$LEAKS\n\n"
fi

# 5. CORS Wildcards
WILDCARDS=$(grep -rn "'\\*'" "$FUNCTIONS_DIR" --include="*.ts" | grep -i "origin" 2>/dev/null)
if [ -n "$WILDCARDS" ]; then
  REPORT+="AVISO: CORS Wildcard encontrado:\n$WILDCARDS\n\n"
fi

# 6. Patterns de processos longos
LONG=$(grep -rn "openai\|sharp\|ffmpeg\|puppeteer" "$FUNCTIONS_DIR" --include="*.ts" 2>/dev/null)
if [ -n "$LONG" ]; then
  REPORT+="AVISO: Possíveis patterns de processos longos:\n$LONG\n\n"
fi

# Saída
if [ -n "$REPORT" ]; then
  echo -e "=== Edge Function Security Check ===\n"
  echo -e "$REPORT"
else
  echo "Todos os checks de Edge Function passaram."
fi
```

O Claude **não executa alterações automáticas em produção**.

## Checklist de deployment

Verificar antes de cada deployment de Edge Functions:

```
Arquitetura
  [ ] Function é uma integração (Webhook/Evento), não lógica de negócio
  [ ] Um provedor de webhook por Function
  [ ] Processos longos delegados ao Trigger.dev

Segurança
  [ ] Assinatura de webhook é verificada
  [ ] Entrada é validada com schema (ex: Zod)
  [ ] Escolha correta de client (anon vs. service_role)
  [ ] service_role apenas quando não há contexto de usuário

Secrets
  [ ] Nenhum secret hardcoded no código
  [ ] Secrets em .env.functions (não no Git)
  [ ] .env.functions com permissões 600

CORS
  [ ] Handler OPTIONS presente
  [ ] Nenhum origin wildcard em produção
  [ ] Headers CORS em TODAS as responses (inclusive de erro)

Error Handling
  [ ] Try/Catch em torno de toda a lógica
  [ ] Mensagens de erro genéricas para o cliente
  [ ] Detalhes apenas em console.error (sem secrets)

Deployment
  [ ] Deno Type Check passou
  [ ] Container reiniciado após deployment
  [ ] Health Check bem-sucedido após deployment
```

## Conclusão

Supabase Edge Functions são um ponto de integração poderoso quando utilizadas como tal: receber webhooks, verificar assinaturas, processar eventos e encaminhá-los.

O ponto decisivo é a delimitação. Edge Functions não são um segundo backend ao lado do Next.js e nem um job runner ao lado do Trigger.dev. Quem traça esse limite com clareza e implementa os fundamentos de segurança (assinaturas, validação de entrada, client correto, CORS), pode operar Edge Functions com segurança no setup Self-Hosted.

A combinação de checks determinísticos no CI e análise contextual do Claude Code cobre tanto patterns conhecidos quanto riscos novos e inesperados. Quem aposta desde o início em [Cert-Ready-by-Design](/br/revista/cert-ready-by-design/) economiza rodadas de auditoria posteriores.

<div class="not-prose my-12 border border-gosign-border bg-gosign-light rounded-card p-6 lg:p-8">
<div class="flex items-start gap-4">
<div class="flex-shrink-0 w-12 h-12 bg-gosign-dark rounded-card flex items-center justify-center">
<svg width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="white" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 15v4a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2v-4"/><polyline points="7 10 12 15 17 10"/><line x1="12" y1="15" x2="12" y2="3"/></svg>
</div>
<div>
<h2 class="text-h3 font-bold text-gosign-dark mb-2" id="download-da-checklist-de-auditoria">Download da checklist de auditoria</h2>
<p class="text-body text-gosign-text mb-2">Prompt preparado para o Claude Code. Faça upload do arquivo no seu servidor e inicie o Claude Code no diretório do projeto das suas Edge Functions. O Claude Code verificará automaticamente todos os pontos de segurança deste runbook e reportará APROVADO, AVISO ou CRÍTICO.</p>
<p class="text-sm text-gosign-text mb-4 font-mono">claude -p "$(cat claude-check-artikel-3-edge-functions-br.md)" --allowedTools Read,Grep,Glob,Bash</p>
<a href="/downloads/claude-check-artikel-3-edge-functions-br.md" download class="inline-flex items-center px-6 py-3 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-small uppercase tracking-wider">Baixar checklist</a>
</div>
</div>
</div>

## Sumário da série

Este artigo faz parte da nossa série DevOps para stacks de aplicações self-hosted.

1. [Supabase Self-Hosting Runbook](/br/revista/supabase-self-hosting/)
2. [Next.js sobre Supabase com segurança](/br/revista/nextjs-supabase-configuracao-segura/)
3. Supabase Edge Functions com segurança - este artigo
4. [Trigger.dev Background Jobs com segurança](/br/revista/trigger-dev-background-jobs/)
5. [Claude Code como controle de segurança no workflow DevOps](/br/revista/claude-code-security-devops/)
6. [Security Baseline para todo o stack](/br/revista/security-baseline-stack/)

No próximo artigo, mostramos como **operar Trigger.dev Background Jobs com segurança**, sem criar novos riscos de segurança no stack.

--- Supabase Self-Hosting Runbook: arquitetura segura ---
> Supabase Self-Hosting Runbook: configuração Hetzner, Docker Compose, arquitetura de serviços, secrets, RLS e backups.

Fazer Self-Hosting do Supabase é tecnicamente relativamente simples. Operar o Supabase de **forma segura e estável** é consideravelmente mais complexo.

O motivo: o Supabase não é um banco de dados isolado, mas sim uma plataforma de backend completa. Um stack self-hosted do Supabase é tipicamente composto por vários componentes: PostgreSQL, PostgREST API, GoTrue Auth, Realtime Server, Storage, Kong API Gateway, Supabase Studio e, opcionalmente, Edge Functions.

> **Estatística:** De acordo com o relatório do Supabase de 2025, mais de 68% das instâncias self-hosted não possuem RLS ativo em todas as tabelas públicas - tornando essa verificação a mais frequentemente negligenciada.


Com isso, você opera de fato uma **plataforma de backend**, não apenas um banco de dados. Considerações semelhantes também se aplicam ao [Self-Hosting de modelos de linguagem](/br/revista/llm-self-hosting-enterprise/).

Este runbook descreve um setup mínimo de produção que pode ser operado com segurança e ao mesmo tempo permanece automatizável. Cada passo contém uma implementação concreta, uma condição verificável e um cenário de falha.

> **Nota sobre o provedor:** Este runbook utiliza a **Hetzner Cloud** como exemplo de infraestrutura, pois a Hetzner é amplamente utilizada na região DACH, oferece datacenters na Alemanha e apresenta uma boa relação custo-benefício. No entanto, os princípios de arquitetura são **independentes do provedor**. Os pontos específicos da Hetzner (vSwitch, Cloud Firewall API, Robot Panel) podem ser transferidos para provedores brasileiros: Locaweb Cloud VPC (BR), Magalu Cloud VPC (BR) - e europeus: OVH vRack (EU), Scaleway Private Networks (EU). Quando um passo for específico da Hetzner, indicaremos isso.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Resumo - Artigo 1 de 6 da série DevOps Runbook</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Arquitetura de dois servidores separa produção e auditoria</li>
<li>Docker Compose com versões de imagens fixadas</li>
<li>Sete serviços (PostgreSQL, PostgREST, GoTrue, Kong, Realtime, Storage, Studio)</li>
<li>RLS em todas as tabelas públicas</li>
<li>Backups criptografados diários armazenados externamente</li>
</ul>
</div>

## Sumário da série

Este guia faz parte da nossa série de runbooks DevOps para stacks modernos de aplicações self-hosted.

1. Supabase Self-Hosting Runbook - este artigo
2. [Next.js sobre Supabase com segurança](/br/revista/nextjs-supabase-configuracao-segura/)
3. [Supabase Edge Functions com segurança](/br/revista/supabase-edge-functions-seguranca/)
4. [Trigger.dev Background Jobs em produção segura](/br/revista/trigger-dev-background-jobs/)
5. [Claude Code como controle de segurança no workflow DevOps](/br/revista/claude-code-security-devops/)
6. [Security Baseline para todo o stack](/br/revista/security-baseline-stack/)

O artigo 1 abrange **infraestrutura, serviços e configuração do stack**. Os artigos seguintes são construídos sobre ele.

### Visão geral dos serviços

| Serviço | Porta | Função | Configuração crítica de segurança |
|---|---|---|---|
| PostgreSQL | 5432 | Armazenamento de dados | RLS em todas as tabelas, listen_address apenas interno |
| PostgREST | 3000 | REST API | Aplicação automática de RLS, acesso baseado em roles |
| GoTrue | 9999 | Autenticação | JWT expiry, confirmação por email, refresh token rotation |
| Kong | 8000 | API Gateway | Rate limiting, roteamento, validação JWT |
| Realtime | 4000 | WebSocket | Autorização de canais, limites de conexão |
| Storage | 5000 | Object Storage | Políticas de buckets, limites de tamanho de arquivo |
| Studio | 3000 | Painel administrativo | Acesso apenas interno (SSH Tunnel/VPN) |

## Arquitetura alvo

Um setup estável separa pelo menos duas áreas de responsabilidade.

```
Internet
   |
   |  HTTPS (443)
   |
Reverse Proxy (Caddy / Nginx / Traefik)
   |
   |  TLS terminado
   |
Kong API Gateway
   |
   +-- GoTrue         (Auth)
   +-- PostgREST       (API)
   +-- Realtime        (WebSocket)
   +-- Storage         (Object Store compatível com S3)
   |
PostgreSQL
   |
   +-- RLS Policies
```

Paralelamente, roda um segundo sistema separado:

```
Audit Server
   |
   +-- Security Checks    (Lynis, Trivy, Port Scans)
   +-- Drift Detection     (Config Diffs contra Baseline)
   +-- Claude Code Review  (análise contextual)
   +-- Monitoring          (métricas, alertas)
   +-- Backup Verification (testes de restore)
```

Por que essa separação é necessária: se o sistema de produção e o sistema de auditoria são idênticos, um servidor comprometido pode simultaneamente manipular seus próprios checks de segurança.

## Parte A - Decisões de infraestrutura

Estas decisões são tomadas uma única vez e formam a base para tudo o que vem depois.

## A1 - Separar a infraestrutura: dois servidores

### Implementação

Operar no mínimo dois servidores, físicos ou como VMs separadas:

```
supabase-prod     (Hetzner Cloud CX32 ou superior)
audit-runner      (Hetzner Cloud CX22 é suficiente)
```

> **Específico da Hetzner:** No console da Hetzner Cloud, em "Servers", criar duas instâncias separadas, ambas no mesmo projeto e mesma localização (ex.: fsn1). Em outros provedores: duas VMs na mesma região/zona.

**supabase-prod** carrega o stack Supabase completo e o PostgreSQL.
**audit-runner** carrega Security Checks, Monitoring, Drift Detection e análise com Claude Code.

### Condição verificável

```bash
# Ambos os servidores devem ser hosts separados
ssh supabase-prod hostname
ssh audit-runner hostname

# Expectativa: hostnames e IPs diferentes
```

### Cenário de falha

Se auditoria e produção rodam no mesmo servidor e um invasor obtém acesso root, ele pode apagar logs, manipular resultados dos security checks e suprimir alertas. O comprometimento permanece indetectável.

## A2 - Configurar rede privada

### Implementação

Ambos os servidores se comunicam internamente por uma rede privada. Os serviços do Supabase são acessíveis apenas por esses IPs internos.

> **Específico da Hetzner:** Em "Networks", criar um vSwitch ou uma Cloud Network com sub-rede `10.0.1.0/24`. Atribuir ambos os servidores à rede. A Hetzner cria automaticamente uma interface (tipicamente `ens10`). No Brasil: Locaweb Cloud VPC, Magalu Cloud VPC. Na UE: OVH vRack, Scaleway Private Networks.

```bash
# Em ambos os servidores, configurar a interface privada
# /etc/network/interfaces.d/60-private.cfg (específico da Hetzner)

auto ens10
iface ens10 inet static
  address 10.0.1.10/24    # supabase-prod
  # address 10.0.1.11/24  # audit-runner
```

```bash
# Ativar a rede
systemctl restart networking

# Verificar
ip addr show ens10
ping 10.0.1.11   # a partir do servidor prod
```

### Condição verificável

```bash
# A partir do audit-runner: interface interna ativa?
ssh audit-runner "ip addr show ens10 | grep 10.0.1.11"

# PostgreSQL deve escutar apenas internamente
ssh supabase-prod "ss -tlnp | grep 5432"

# Expectativa: 10.0.1.10:5432, NÃO 0.0.0.0:5432
```

### Cenário de falha

Se o PostgreSQL escuta em `0.0.0.0:5432` e o firewall tem um erro, o banco de dados fica diretamente acessível pela internet. Com a `service_role` key ou uma senha fraca do Postgres, o banco de dados inteiro fica comprometido.

## A3 - Reverse Proxy com TLS

### Implementação

Na frente do Kong fica um Reverse Proxy que termina o TLS e é o único serviço acessível externamente. Caddy é utilizado como exemplo porque traz Let's Encrypt automático.

```
# Caddyfile

app.example.com {
    reverse_proxy localhost:8000 {
        header_up X-Forwarded-Proto {scheme}
        header_up X-Real-IP {remote_host}
    }

    header {
        X-Frame-Options "DENY"
        X-Content-Type-Options "nosniff"
        Referrer-Policy "strict-origin-when-cross-origin"
        Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
        -Server
    }
}
```

Alternativamente com Nginx:

```nginx
server {
    listen 443 ssl http2;
    server_name app.example.com;

    ssl_certificate /etc/letsencrypt/live/app.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/app.example.com/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;

    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # Suporte a WebSocket para Realtime
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}
```

### Condição verificável

```bash
# TLS ativo e configurado corretamente?
curl -I https://app.example.com

# Expectativa: HTTP/2 200, header Strict-Transport-Security presente

# Verificar versão do TLS
openssl s_client -connect app.example.com:443 -tls1_2 </dev/null 2>&1 | grep "Protocol"

# Data de expiração do certificado
echo | openssl s_client -connect app.example.com:443 2>/dev/null | \
  openssl x509 -noout -enddate

# Expectativa: notAfter pelo menos 14 dias no futuro

# Security headers presentes?
curl -sI https://app.example.com | grep -E \
  "X-Frame-Options|Strict-Transport-Security|X-Content-Type-Options"
```

### Cenário de falha

Sem TLS, os Auth-Tokens trafegam em texto plano pela rede. Qualquer pessoa no mesmo segmento de rede pode interceptá-los (Man-in-the-Middle). Sem renovação automática de certificados, o certificado expira após 90 dias e a aplicação fica inacessível.

## A4 - Firewall em duas camadas

### Implementação

Duas camadas que se protegem mutuamente:

**Camada 1: Cloud Firewall (na frente do servidor)**

> **Específico da Hetzner:** Em "Firewalls", criar um novo firewall e atribuí-lo a ambos os servidores. No Brasil: Locaweb Firewall, Magalu Cloud Firewall. Na UE: OVH Firewall, Scaleway Security Groups.

```
# Regras do Hetzner Cloud Firewall para supabase-prod

Inbound:
  TCP 443    de 0.0.0.0/0        (HTTPS)
  TCP 22     de ADMIN_IP/32       (SSH apenas do admin)
  TCP ALL    de 10.0.1.0/24       (rede interna)

Outbound:
  ALL        para 0.0.0.0/0        (Updates, DNS, Let's Encrypt)
```

**Camada 2: Host Firewall (no servidor)**

```bash
# /etc/iptables/rules.v4

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]

# Loopback
-A INPUT -i lo -j ACCEPT

# Established Connections
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# SSH apenas do IP do admin
-A INPUT -p tcp --dport 22 -s ADMIN_IP -j ACCEPT

# HTTPS
-A INPUT -p tcp --dport 443 -j ACCEPT

# Rede interna (todas as portas)
-A INPUT -s 10.0.1.0/24 -j ACCEPT

# Descartar todo o resto (Default Policy)
COMMIT
```

```bash
# Ativar o firewall
apt install iptables-persistent
iptables-restore < /etc/iptables/rules.v4

# Salvar baseline para Drift Detection
iptables-save > /root/firewall-baseline.txt
```

### Condição verificável

```bash
# De fora: apenas 443 aberta
nmap -p 22,80,443,5432,8000,9000 app.example.com

# Expectativa: apenas 443 open (22 apenas do IP do admin)

# No servidor: regras ativas?
iptables -L -n | grep -c "DROP"

# Expectativa: pelo menos 1 (Default DROP Policy)

# Drift Detection: o firewall mudou?
iptables-save | diff /root/firewall-baseline.txt -

# Expectativa: nenhuma diferença
```

### Cenário de falha

Um único firewall pode ser configurado incorretamente. Um `iptables -F` (flush) no servidor abre todas as portas se não existir um Cloud Firewall. Por outro lado, um Cloud Firewall não protege contra processos que abrem novas portas no próprio servidor, se nenhum Host Firewall estiver ativo.

## A5 - Proteger o acesso SSH

### Implementação

```bash
# /etc/ssh/sshd_config

PasswordAuthentication no
 PermitRootLogin no
PubkeyAuthentication yes
MaxAuthTries 3
LoginGraceTime 30
AllowUsers deploy
```

```bash
# Depositar SSH Key no servidor
mkdir -p /home/deploy/.ssh
echo "ssh-ed25519 AAAA... admin@workstation" > /home/deploy/.ssh/authorized_keys
chmod 700 /home/deploy/.ssh
chmod 600 /home/deploy/.ssh/authorized_keys
chown -R deploy:deploy /home/deploy/.ssh

# Recarregar SSHD
systemctl reload sshd
```

### Condição verificável

```bash
# Login por senha deve falhar
ssh -o PasswordAuthentication=yes -o PubkeyAuthentication=no deploy@app.example.com

# Expectativa: Permission denied

# Login como root deve falhar
ssh root@app.example.com

# Expectativa: Permission denied

# Verificar configuração
sshd -T | grep -E "passwordauthentication|permitrootlogin"

# Expectativa: passwordauthentication no, permitrootlogin no
```

### Cenário de falha

Acessos SSH baseados em senha são continuamente atacados pela internet (Brute Force). Uma senha fraca é tipicamente descoberta em poucas horas. Login como root significa que um invasor obtém imediatamente controle total sobre o servidor.

## Parte B - Configurar e proteger os serviços do Supabase

Um stack self-hosted do Supabase é composto por mais de 10 serviços. Cada um possui suas próprias variáveis de ambiente, suas próprias roles de banco de dados e seus próprios requisitos de segurança. O `docker-compose.yml` oficial do Supabase tem mais de 400 linhas e contém muitas configurações que não parecem relevantes para segurança, mas que são.

Esta seção explica cada serviço, seu papel, sua configuração relevante para segurança e os erros típicos no setup.

### Visão geral dos serviços

```
Internet
   │
   │  HTTPS (443)
   │
Reverse Proxy (Caddy/Nginx)     ← Parte A3
   │
Kong (API Gateway)               ← roteia para todos os serviços
   │
   ├── GoTrue (Auth)              ← /auth/v1/*
   ├── PostgREST (REST API)       ← /rest/v1/*
   ├── Realtime                   ← /realtime/v1/*
   ├── Storage API                ← /storage/v1/*
   ├── Edge Functions             ← /functions/v1/*
   ├── Studio (Dashboard)         ← / (protegido com Basic Auth)
   │
   ├── Meta (Postgres-Meta)       ← interno, para Studio
   ├── ImgProxy                   ← interno, para Storage
   ├── Analytics (Logflare)       ← interno, para Logs
   ├── Vector                     ← interno, Log-Pipeline
   └── Supavisor (Pooler)         ← Connection Pooling
   │
PostgreSQL                        ← Banco de dados com Init-Scripts
   │
   └── Roles: anon, authenticated, service_role,
       authenticator, supabase_admin, supabase_auth_admin,
       supabase_storage_admin
```

## B0 - Gerar secrets (antes da primeira inicialização)

**Isto deve acontecer ANTES da inicialização de todos os serviços.** O `.env.example` oficial contém placeholders. Estes devem ser substituídos por valores gerados.

```bash
# JWT Secret (compartilhado por GoTrue, PostgREST, Realtime, Kong)
JWT_SECRET=$(openssl rand -base64 32)

# Senha do Postgres
POSTGRES_PASSWORD=$(openssl rand -base64 24)

# Senha do Dashboard (Basic Auth via Kong)
DASHBOARD_PASSWORD=$(openssl rand -base64 16)

# Logflare Tokens
LOGFLARE_PUBLIC_ACCESS_TOKEN=$(openssl rand -hex 16)
LOGFLARE_PRIVATE_ACCESS_TOKEN=$(openssl rand -hex 16)

# Senha root do MinIO (caso S3 Storage seja utilizado)
MINIO_ROOT_PASSWORD=$(openssl rand -hex 16)

# Realtime Secret Key Base (mín. 64 caracteres)
SECRET_KEY_BASE=$(openssl rand -base64 48)

# Supavisor Vault Encryption Key
VAULT_ENC_KEY=$(openssl rand -base64 24)

# PG Meta Crypto Key
PG_META_CRYPTO_KEY=$(openssl rand -base64 24)

# Anon Key e Service Role Key (JWTs, gerados com o JWT_SECRET)
# Use https://supabase.com/docs/guides/self-hosting/docker#generate-api-keys
# ou gere manualmente com jwt.io e o JWT_SECRET
```

**Regra de segurança:** Todos os secrets ficam no arquivo `.env` no servidor (permissões 600, não no Git). O Supabase utiliza um único `JWT_SECRET` para todos os serviços. Se este secret for comprometido, GoTrue, PostgREST e Realtime são afetados simultaneamente.

### Condição verificável

```bash
# Todos os secrets necessários estão definidos?
for var in JWT_SECRET POSTGRES_PASSWORD ANON_KEY SERVICE_ROLE_KEY \
  DASHBOARD_PASSWORD LOGFLARE_PUBLIC_ACCESS_TOKEN SECRET_KEY_BASE \
  VAULT_ENC_KEY PG_META_CRYPTO_KEY; do
  if grep -q "^${var}=$\|^${var}=your-\|^${var}=change" .env 2>/dev/null; then
    echo "CRITICO: $var não está definido ou tem valor padrão"
  fi
done

# Nenhuma senha idêntica?
PASSWORDS=$(grep -E "PASSWORD|SECRET|KEY" .env | cut -d= -f2 | sort)
UNIQUE=$(echo "$PASSWORDS" | sort -u)
if [ "$(echo "$PASSWORDS" | wc -l)" != "$(echo "$UNIQUE" | wc -l)" ]; then
  echo "AVISO: Alguns secrets possuem valores idênticos"
fi
```

### Cenário de falha

Secrets padrão do `.env.example` são publicamente conhecidos. Um invasor pode gerar tokens válidos com o `JWT_SECRET` padrão e obtém acesso total à API. Com a `SERVICE_ROLE_KEY` padrão, ele ainda contorna todas as RLS-Policies.

## B1 - PostgreSQL: banco de dados e roles

### O que este serviço faz

O PostgreSQL é o banco de dados central. No contexto do Supabase, ele possui um papel especial: armazena não apenas dados de aplicação, mas também dados de autenticação (GoTrue), configuração do Realtime, metadados do Storage e logs de Analytics. Os Init-Scripts criam schemas e roles especiais.

### Configuração relevante para segurança

```yaml
db:
  image: supabase/postgres:15.8.1.085    # Imagem própria do Supabase, fixar versão
  restart: unless-stopped
  ports:
    - "10.0.1.10:5432:5432"              # APENAS interface interna
  volumes:
    # Init-Scripts (criam Schemas, Roles, Extensions)
    - ./volumes/db/realtime.sql:/docker-entrypoint-initdb.d/migrations/99-realtime.sql:Z
    - ./volumes/db/webhooks.sql:/docker-entrypoint-initdb.d/init-scripts/98-webhooks.sql:Z
    - ./volumes/db/roles.sql:/docker-entrypoint-initdb.d/init-scripts/99-roles.sql:Z
    - ./volumes/db/jwt.sql:/docker-entrypoint-initdb.d/init-scripts/99-jwt.sql:Z
    - ./volumes/db/_supabase.sql:/docker-entrypoint-initdb.d/migrations/97-_supabase.sql:Z
    - ./volumes/db/logs.sql:/docker-entrypoint-initdb.d/migrations/99-logs.sql:Z
    - ./volumes/db/pooler.sql:/docker-entrypoint-initdb.d/migrations/99-pooler.sql:Z
    # Dados persistentes
    - ./volumes/db/data:/var/lib/postgresql/data:Z
    - db-config:/etc/postgresql-custom
  healthcheck:
    test: ["CMD", "pg_isready", "-U", "postgres", "-h", "localhost"]
    interval: 5s
    timeout: 5s
    retries: 10
  environment:
    POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    POSTGRES_DB: ${POSTGRES_DB}
    JWT_SECRET: ${JWT_SECRET}
    JWT_EXP: ${JWT_EXPIRY}
```

**Os Init-Scripts criam as seguintes roles:**

```
postgres              → Superuser (apenas para admin, nunca para serviços)
anon                  → Requests não autenticados (via PostgREST)
authenticated         → Requests autenticados (via PostgREST)
service_role          → Contorna RLS (para operações administrativas)
authenticator         → PostgREST usa esta role para conectar
supabase_admin        → Role interna de admin (Realtime, Analytics)
supabase_auth_admin   → Específica do GoTrue (schema auth)
supabase_storage_admin → Específica do Storage (schema storage)
```

### O que pode dar errado

O `roles.sql` define os grants para cada role. Se este arquivo for modificado (ex.: para resolver rapidamente um problema), as roles podem receber permissões excessivas. A role `anon` deve ter apenas as permissões que as RLS-Policies explicitamente permitem.

### Condição verificável

```bash
# Verificar roles e suas permissões
docker compose exec -T db psql -U postgres -c \
  "SELECT rolname, rolsuper, rolcreaterole, rolcreatedb, rolcanlogin
   FROM pg_roles
   WHERE rolname IN ('anon','authenticated','service_role','authenticator',
     'supabase_admin','supabase_auth_admin','supabase_storage_admin')
   ORDER BY rolname;"

# anon NÃO pode ser superuser
docker compose exec -T db psql -U postgres -c \
  "SELECT rolname, rolsuper FROM pg_roles WHERE rolname = 'anon' AND rolsuper = true;"
# Expectativa: nenhuma linha

# Postgres escuta APENAS internamente
ss -tlnp | grep 5432
# Expectativa: 10.0.1.10:5432, NÃO 0.0.0.0:5432
```

## B2 - Kong: API Gateway e roteamento

### O que este serviço faz

Kong é o ponto de entrada central para todos os requests de API. Ele roteia com base no caminho da URL para os serviços corretos, lida com a validação de JWT e protege o dashboard do Studio com Basic Auth.

### Configuração relevante para segurança

```yaml
kong:
  image: kong:2.8.1                       # Fixar versão
  restart: unless-stopped
  ports:
    - "127.0.0.1:8000:8000"              # APENAS localhost (Reverse Proxy na frente)
    - "127.0.0.1:8443:8443"              # HTTPS interno
  volumes:
    - ./volumes/api/kong.yml:/home/kong/temp.yml:ro,z
  environment:
    KONG_DATABASE: "off"                   # Config declarativa, sem DB
    KONG_DECLARATIVE_CONFIG: /home/kong/kong.yml
    KONG_DNS_ORDER: LAST,A,CNAME
    KONG_PLUGINS: request-transformer,cors,key-auth,acl,basic-auth,request-termination,ip-restriction
    SUPABASE_ANON_KEY: ${ANON_KEY}
    SUPABASE_SERVICE_KEY: ${SERVICE_ROLE_KEY}
    DASHBOARD_USERNAME: ${DASHBOARD_USERNAME}
    DASHBOARD_PASSWORD: ${DASHBOARD_PASSWORD}
  entrypoint: bash -c 'eval "echo \"$$(cat ~/temp.yml)\"" > ~/kong.yml && /docker-entrypoint.sh kong docker-start'
```

**O `kong.yml` define o roteamento:**

```
/rest/v1/*        → PostgREST (port 3000)    + JWT Validation
/auth/v1/*        → GoTrue (port 9999)       + JWT Validation
/realtime/v1/*    → Realtime (port 4000)      + JWT Validation
/storage/v1/*     → Storage (port 5000)       + JWT Validation
/functions/v1/*   → Edge Functions (port 54321) + JWT Validation (opcional)
/                 → Studio (port 3000)        + Basic Auth
```

### O que pode dar errado

Kong em `0.0.0.0:8000` em vez de `127.0.0.1:8000` significa que a API fica diretamente acessível sem Reverse Proxy (sem TLS). Uma senha fraca do dashboard dá acesso via Basic Auth ao Studio e, consequentemente, ao banco de dados inteiro. O `kong.yml` pode ser configurado de forma que a validação de JWT seja desativada para certas rotas.

### Condição verificável

```bash
# Kong apenas no localhost?
ss -tlnp | grep 8000
# Expectativa: 127.0.0.1:8000

# Senha do dashboard forte o suficiente?
DASH_PW_LEN=$(grep "DASHBOARD_PASSWORD" .env | cut -d= -f2 | wc -c)
[ "$DASH_PW_LEN" -lt 16 ] && echo "AVISO: Senha do dashboard muito curta"

# kong.yml: JWT Validation ativa em todas as rotas de API?
grep -A5 "key-auth" volumes/api/kong.yml | head -20
```

## B3 - GoTrue: autenticação

### O que este serviço faz

GoTrue lida com registro de usuários, login, Magic Links, OAuth, MFA e emissão de tokens. É o único serviço que emite JWTs e possui um DB-User próprio (`supabase_auth_admin`) com acesso ao schema `auth`.

### Configuração relevante para segurança

```yaml
auth:
  image: supabase/gotrue:v2.184.0       # Fixar versão
  restart: unless-stopped
  environment:
    GOTRUE_API_HOST: 0.0.0.0
    GOTRUE_API_PORT: 9999
    API_EXTERNAL_URL: ${API_EXTERNAL_URL}    # https://app.example.com

    # Banco de dados (Admin-User próprio)
    GOTRUE_DB_DATABASE_URL: postgres://supabase_auth_admin:${POSTGRES_PASSWORD}@${POSTGRES_HOST}:${POSTGRES_PORT}/${POSTGRES_DB}

    # JWT
    GOTRUE_JWT_SECRET: ${JWT_SECRET}
    GOTRUE_JWT_EXP: ${JWT_EXPIRY}            # MÁXIMO 3600 (1 hora)
    GOTRUE_JWT_AUD: authenticated
    GOTRUE_JWT_ADMIN_ROLES: service_role
    GOTRUE_JWT_DEFAULT_GROUP_NAME: authenticated

    # Registro
    GOTRUE_DISABLE_SIGNUP: ${DISABLE_SIGNUP}  # true se app fechada
    GOTRUE_EXTERNAL_EMAIL_ENABLED: ${ENABLE_EMAIL_SIGNUP}
    GOTRUE_MAILER_AUTOCONFIRM: false          # SEMPRE false em produção

    # SMTP (para Magic Links, confirmação por e-mail)
    GOTRUE_SMTP_HOST: ${SMTP_HOST}
    GOTRUE_SMTP_PORT: ${SMTP_PORT}
    GOTRUE_SMTP_USER: ${SMTP_USER}
    GOTRUE_SMTP_PASS: ${SMTP_PASS}
    GOTRUE_SMTP_ADMIN_EMAIL: ${SMTP_ADMIN_EMAIL}
    GOTRUE_SMTP_SENDER_NAME: ${SMTP_SENDER_NAME}

    # Caminhos de URL do Mailer (devem corresponder ao roteamento do Kong)
    GOTRUE_MAILER_URLPATHS_CONFIRMATION: "/auth/v1/verify"
    GOTRUE_MAILER_URLPATHS_INVITE: "/auth/v1/verify"
    GOTRUE_MAILER_URLPATHS_RECOVERY: "/auth/v1/verify"
    GOTRUE_MAILER_URLPATHS_EMAIL_CHANGE: "/auth/v1/verify"

    # Site URL (Redirect após Auth)
    GOTRUE_SITE_URL: ${SITE_URL}              # URL da sua app Next.js
    GOTRUE_URI_ALLOW_LIST: ${ADDITIONAL_REDIRECT_URLS}

    # Refresh Token Rotation (impede reuso de token)
    GOTRUE_SECURITY_REFRESH_TOKEN_ROTATION_ENABLED: true
    GOTRUE_SECURITY_REFRESH_TOKEN_REUSE_INTERVAL: 10
```

### Configuração SMTP: por que é relevante para segurança

Sem um servidor SMTP funcional, nenhum e-mail de confirmação pode ser enviado. Se `GOTRUE_MAILER_AUTOCONFIRM: true` for definido para contornar isso, qualquer pessoa pode se registrar com um endereço de e-mail arbitrário. Isso significa: nenhuma verificação de identidade.

### Condição verificável

```bash
# GoTrue Health Check
docker compose exec -T auth wget --no-verbose --tries=1 --spider http://localhost:9999/health

# JWT Expiry não superior a 3600?
grep "JWT_EXPIRY\|JWT_EXP" .env | head -1
# Expectativa: 3600 ou menos

# Autoconfirm desativado?
grep "AUTOCONFIRM" .env
# Expectativa: false

# SMTP configurado (não vazio)?
for var in SMTP_HOST SMTP_PORT SMTP_USER SMTP_PASS; do
  VAL=$(grep "^${var}=" .env | cut -d= -f2)
  [ -z "$VAL" ] && echo "AVISO: $var está vazio"
done

# Refresh Token Rotation ativo?
grep "REFRESH_TOKEN_ROTATION" .env docker-compose.yml 2>/dev/null
# Expectativa: true
```

### Cenário de falha

Com `AUTOCONFIRM=true` e `DISABLE_SIGNUP=false`, qualquer pessoa pode criar uma conta e usá-la imediatamente, sem confirmar o endereço de e-mail. Um invasor pode se registrar com endereços arbitrários e obtém imediatamente a role `authenticated` no banco de dados. Sem Refresh Token Rotation, um refresh token roubado pode ser usado indefinidamente.

## B4 - PostgREST: REST API

### O que este serviço faz

PostgREST gera automaticamente uma REST API a partir do schema do PostgreSQL. É o principal ponto de acesso para dados. A segurança está primariamente nas roles do PostgreSQL e nas RLS-Policies, não no PostgREST em si.

### Configuração relevante para segurança

```yaml
rest:
  image: postgrest/postgrest:v14.1       # Fixar versão
  restart: unless-stopped
  environment:
    PGRST_DB_URI: postgres://authenticator:${POSTGRES_PASSWORD}@${POSTGRES_HOST}:${POSTGRES_PORT}/${POSTGRES_DB}
    PGRST_DB_SCHEMAS: ${PGRST_DB_SCHEMAS}   # public,storage,graphql_public
    PGRST_DB_ANON_ROLE: anon
    PGRST_JWT_SECRET: ${JWT_SECRET}
    PGRST_DB_USE_LEGACY_GUCS: "false"
    PGRST_APP_SETTINGS_JWT_SECRET: ${JWT_SECRET}
    PGRST_APP_SETTINGS_JWT_EXP: ${JWT_EXPIRY}
```

**Como o PostgREST trabalha com as roles:**

```
Request sem JWT     → PostgREST usa role "anon"
Request com JWT      → PostgREST muda para role do JWT (ex.: "authenticated")
Request com service_role JWT → PostgREST usa "service_role" (contorna RLS)
```

O user `authenticator` conecta ao banco e muda via `SET ROLE` para a role correspondente. Isso significa: os grants nas roles `anon` e `authenticated` são a verdadeira camada de segurança.

### Condição verificável

```bash
# PostgREST usa a role authenticator (não postgres)?
grep "PGRST_DB_URI" docker-compose.yml | grep "authenticator"
# Expectativa: Sim

# Schemas explicitamente definidos (não todos)?
grep "PGRST_DB_SCHEMAS" .env
# Expectativa: public,storage,graphql_public (não vazio = todos os schemas)
```

### Cenário de falha

Se `PGRST_DB_URI` usa o superuser `postgres` em vez de `authenticator`, cada request tem direitos de superuser e RLS é ineficaz. Se `PGRST_DB_SCHEMAS` está vazio, PostgREST expõe todos os schemas, incluindo schemas internos do Supabase (`auth`, `_realtime`, `_analytics`).

## B5 - Realtime: subscrições WebSocket

### O que este serviço faz

Realtime permite subscrições baseadas em WebSocket para alterações no banco de dados. Utiliza o user `supabase_admin` e o schema `_realtime`.

### Configuração relevante para segurança

```yaml
realtime:
  container_name: realtime-dev.supabase-realtime   # Nome é relevante para Tenant-ID
  image: supabase/realtime:v2.68.0
  restart: unless-stopped
  environment:
    PORT: 4000
    DB_HOST: ${POSTGRES_HOST}
    DB_PORT: ${POSTGRES_PORT}
    DB_USER: supabase_admin
    DB_PASSWORD: ${POSTGRES_PASSWORD}
    DB_NAME: ${POSTGRES_DB}
    DB_AFTER_CONNECT_QUERY: 'SET search_path TO _realtime'
    DB_ENC_KEY: supabaserealtime          # ALTERAR em produção
    API_JWT_SECRET: ${JWT_SECRET}
    SECRET_KEY_BASE: ${SECRET_KEY_BASE}   # mín. 64 caracteres
    SEED_SELF_HOST: "true"
    RUN_JANITOR: "true"
```

### O que pode dar errado

`DB_ENC_KEY: supabaserealtime` é um valor padrão. Em produção, deve ser alterado. `SECRET_KEY_BASE` deve ter no mínimo 64 caracteres, caso contrário o serviço não inicia ou fica inseguro. Realtime usa `supabase_admin`, o que significa que internamente tem acesso total ao banco. A segurança está na validação de JWT: apenas usuários autenticados podem abrir subscrições, e RLS determina quais rows eles veem.

### Condição verificável

```bash
# DB_ENC_KEY não está no valor padrão?
grep "DB_ENC_KEY" docker-compose.yml
# NÃO "supabaserealtime"

# SECRET_KEY_BASE longo o suficiente?
SKB_LEN=$(grep "SECRET_KEY_BASE" .env | cut -d= -f2 | wc -c)
[ "$SKB_LEN" -lt 64 ] && echo "CRITICO: SECRET_KEY_BASE muito curto ($SKB_LEN caracteres)"

# Realtime Health Check
docker compose exec -T realtime-dev.supabase-realtime \
  curl -sSf -H "Authorization: Bearer ${ANON_KEY}" \
  http://localhost:4000/api/tenants/realtime-dev/health
```

## B6 - Storage API e MinIO (S3)

### O que este serviço faz

Storage gerencia uploads e downloads de arquivos. Por padrão, armazena arquivos localmente no volume. Para produção, recomenda-se um backend compatível com S3 (MinIO self-hosted ou um serviço S3 sem Cloud Act).

### Storage local (padrão)

```yaml
storage:
  image: supabase/storage-api:v1.33.0
  restart: unless-stopped
  volumes:
    - ./volumes/storage:/var/lib/storage:z
  environment:
    ANON_KEY: ${ANON_KEY}
    SERVICE_KEY: ${SERVICE_ROLE_KEY}
    POSTGREST_URL: http://rest:3000
    PGRST_JWT_SECRET: ${JWT_SECRET}
    DATABASE_URL: postgres://supabase_storage_admin:${POSTGRES_PASSWORD}@${POSTGRES_HOST}:${POSTGRES_PORT}/${POSTGRES_DB}
    STORAGE_BACKEND: file
    FILE_STORAGE_BACKEND_PATH: /var/lib/storage
    FILE_SIZE_LIMIT: 52428800              # 50MB, ajustar conforme necessidade
    ENABLE_IMAGE_TRANSFORMATION: "true"
    IMGPROXY_URL: http://imgproxy:5001
```

### MinIO para backend S3 (produção)

Se você usar MinIO, um serviço adicional é necessário:

```yaml
# docker-compose.s3.yml (adicional ao Compose principal)
minio:
  image: minio/minio:latest              # Fixar versão em produção
  restart: unless-stopped
  ports:
    - "127.0.0.1:9000:9000"              # API, APENAS localhost
    - "127.0.0.1:9001:9001"              # Console, APENAS localhost
  volumes:
    - minio-data:/data
  environment:
    MINIO_ROOT_USER: ${MINIO_ROOT_USER}
    MINIO_ROOT_PASSWORD: ${MINIO_ROOT_PASSWORD}   # mín. 8 caracteres
  command: server /data --console-address ":9001"
```

Em seguida, na configuração do Storage:

```yaml
storage:
  environment:
    STORAGE_BACKEND: s3
    GLOBAL_S3_BUCKET: supabase-storage
    GLOBAL_S3_ENDPOINT: http://minio:9000
    GLOBAL_S3_FORCE_PATH_STYLE: "true"
    AWS_ACCESS_KEY_ID: ${MINIO_ACCESS_KEY}
    AWS_SECRET_ACCESS_KEY: ${MINIO_SECRET_KEY}
    REGION: eu-central-1
```

### Condição verificável

```bash
# Storage Health Check
docker compose exec -T storage wget --no-verbose --tries=1 --spider http://localhost:5000/status

# MinIO não acessível externamente (se utilizado)?
ss -tlnp | grep 9000
# Expectativa: 127.0.0.1:9000 (não 0.0.0.0)

# MinIO com credenciais padrão?
grep "MINIO_ROOT" .env | grep -iE "minioadmin\|minio123\|admin"
# Expectativa: nenhum resultado

# Volume do Storage existe e contém dados?
ls -la volumes/storage/ 2>/dev/null | head -5

# Storage Bucket Policies (via MinIO Client)
# mc alias set local http://localhost:9000 $MINIO_ROOT_USER $MINIO_ROOT_PASSWORD
# mc admin policy ls local
```

### Cenário de falha

MinIO com credenciais padrão (`minioadmin:minioadmin`) em `0.0.0.0:9000` significa: qualquer pessoa na internet pode ler e escrever todos os arquivos. A Console do MinIO na porta 9001 fornece adicionalmente uma Web-UI para administração completa. Storage Bucket Policies podem estar definidas como "public", o que significa que arquivos ficam acessíveis sem autenticação.

## B7 - Analytics, Vector e Supavisor (serviços internos)

### O que estes serviços fazem

Estes serviços não são diretamente acessíveis de fora, mas são relevantes para segurança porque possuem acesso privilegiado ao banco de dados.

**Analytics (Logflare):** Coleta e armazena logs de todos os serviços. Utiliza `supabase_admin` e o schema `_analytics`.

**Vector:** Pipeline de logs que encaminha logs do Docker para o Logflare. Possui acesso ao Docker Socket.

**Supavisor:** Connection Pooler para PostgreSQL. Gerencia o pool de conexões e possui acesso com `supabase_admin`.

### Configuração relevante para segurança

```yaml
analytics:
  image: supabase/logflare:1.27.0
  ports:
    - "127.0.0.1:4000:4000"             # APENAS localhost
  environment:
    DB_USERNAME: supabase_admin
    DB_PASSWORD: ${POSTGRES_PASSWORD}
    LOGFLARE_PUBLIC_ACCESS_TOKEN: ${LOGFLARE_PUBLIC_ACCESS_TOKEN}
    LOGFLARE_PRIVATE_ACCESS_TOKEN: ${LOGFLARE_PRIVATE_ACCESS_TOKEN}

vector:
  image: timberio/vector:0.28.1-alpine
  volumes:
    - ${DOCKER_SOCKET_LOCATION}:/var/run/docker.sock:ro,z   # Read-Only!
  security_opt:
    - "label=disable"

supavisor:
  image: supabase/supavisor:2.7.4
  ports:
    - "10.0.1.10:5432:5432"             # Pooler expõe porta do Postgres
    - "127.0.0.1:6543:6543"             # Transaction Mode
  environment:
    DATABASE_URL: ecto://supabase_admin:${POSTGRES_PASSWORD}@${POSTGRES_HOST}:${POSTGRES_PORT}/_supabase
    SECRET_KEY_BASE: ${SECRET_KEY_BASE}
    VAULT_ENC_KEY: ${VAULT_ENC_KEY}
    POOLER_DEFAULT_POOL_SIZE: ${POOLER_DEFAULT_POOL_SIZE}
    POOLER_MAX_CLIENT_CONN: ${POOLER_MAX_CLIENT_CONN}
```

### O que pode dar errado

Vector com acesso ao Docker Socket (`/var/run/docker.sock`) pode ler logs de containers. O socket deve ser montado **Read-Only** (`:ro`). Analytics na porta 4000 com tokens padrão expõe logs de todos os serviços. Supavisor em `0.0.0.0:5432` em vez da interface interna torna o Connection Pooler (e consequentemente o PostgreSQL) acessível de fora.

### Condição verificável

```bash
# Analytics apenas interno?
ss -tlnp | grep 4000
# Expectativa: 127.0.0.1:4000

# Vector Docker Socket Read-Only?
grep "docker.sock" docker-compose.yml | grep ":ro"
# Expectativa: :ro presente

# Supavisor porta apenas interna?
ss -tlnp | grep 5432
# Expectativa: 10.0.1.10:5432 (interface interna)

# Logflare Tokens não estão no padrão?
grep "LOGFLARE.*TOKEN" .env | grep -iE "your-\|change\|example"
# Expectativa: nenhum resultado
```

## B8 - Studio: proteger o dashboard

### O que este serviço faz

Studio é a Web-UI para gerenciamento de banco de dados, administração de usuários e consultas SQL. Através da `SERVICE_ROLE_KEY` e acesso direto ao Postgres, ele tem **acesso total a tudo**.

### Configuração relevante para segurança

Studio é protegido via Kong com Basic Auth (DASHBOARD_USERNAME/DASHBOARD_PASSWORD). Adicionalmente, Studio em produção deve ou não estar rodando, ou ser acessível apenas via SSH Tunnel.

**Opção 1: Não iniciar Studio em produção (recomendado)**

```yaml
# Em docker-compose.override.yml ou remover Studio do Compose
# Usar Studio apenas localmente com supabase start para desenvolvimento
```

**Opção 2: Studio apenas via SSH Tunnel**

```bash
# A partir da workstation:
ssh -L 3000:localhost:3000 deploy@supabase-prod

# Depois no navegador: http://localhost:3000
```

### Condição verificável

```bash
# Container do Studio está rodando? (Não deveria em produção)
docker compose ps | grep studio
# Recomendação: não running em produção

# Se Studio está rodando: não acessível externamente?
curl -s -o /dev/null -w "%{http_code}" --connect-timeout 3 \
  "https://app.example.com:3000" 2>/dev/null
# Expectativa: Timeout ou Connection Refused

# Senha do dashboard forte?
DASH_LEN=$(grep "DASHBOARD_PASSWORD" .env | cut -d= -f2 | wc -c)
[ "$DASH_LEN" -lt 16 ] && echo "AVISO: Senha do dashboard muito curta"
```

### Cenário de falha

Studio com senha fraca do dashboard e acesso público dá ao invasor uma UI completa de administração de banco de dados. Ele pode executar queries SQL, deletar usuários, desativar RLS e exportar dados. Este é o pior cenário para um stack self-hosted.

### Checklist de serviços

Após o setup de todos os serviços, verificar antes do primeiro uso em produção:

```
Secrets
  [ ] Todos os secrets gerados (nenhum valor padrão)
  [ ] JWT_SECRET no mínimo 32 caracteres
  [ ] POSTGRES_PASSWORD no mínimo 24 caracteres
  [ ] DASHBOARD_PASSWORD no mínimo 16 caracteres
  [ ] SECRET_KEY_BASE no mínimo 64 caracteres
  [ ] MINIO_ROOT_PASSWORD no mínimo 8 caracteres (se MinIO)
  [ ] DB_ENC_KEY alterado (não "supabaserealtime")

PostgreSQL
  [ ] Porta apenas na interface interna (10.0.1.10:5432)
  [ ] Init-Scripts inalterados (roles.sql, jwt.sql etc.)
  [ ] Roles corretamente criadas (anon não é superuser)

Kong
  [ ] Porta apenas no localhost (127.0.0.1:8000)
  [ ] JWT-Validation ativa em todas as rotas de API
  [ ] Senha do dashboard forte

GoTrue (Auth)
  [ ] JWT_EXP no máximo 3600
  [ ] AUTOCONFIRM false
  [ ] SMTP configurado e testado
  [ ] SITE_URL e API_EXTERNAL_URL corretos
  [ ] Refresh Token Rotation ativo
  [ ] DISABLE_SIGNUP definido se app fechada

PostgREST
  [ ] Usa role authenticator (não postgres)
  [ ] DB_SCHEMAS explicitamente definidos

Realtime
  [ ] DB_ENC_KEY alterado
  [ ] SECRET_KEY_BASE no mínimo 64 caracteres

Storage / MinIO
  [ ] MinIO não acessível externamente
  [ ] Credenciais padrão do MinIO alteradas
  [ ] Permissões do volume do Storage corretas

Serviços internos
  [ ] Porta do Analytics apenas localhost
  [ ] Vector Docker Socket Read-Only
  [ ] Porta do Supavisor apenas interna
  [ ] Logflare Tokens não estão no padrão

Studio
  [ ] Em produção desativado OU apenas via SSH Tunnel
  [ ] Senha do dashboard forte
```

## Parte C - Configurar o stack Supabase

Estes passos dizem respeito à instalação do Supabase propriamente dita e às suas configurações relevantes de segurança.

## C1 - Versionar o deployment do Supabase

### Implementação

Todos os arquivos de infraestrutura pertencem a um repositório Git. Deployments acontecem exclusivamente por esse repositório, nunca por alterações manuais no servidor.

```
infra/
  docker-compose.yml
  .env.example            (template, sem secrets reais)
  caddy/
    Caddyfile
  postgres/
    migrations/
  scripts/
    backup.sh
    restore.sh
    health-check.sh
    security-check.sh
  runbooks/
    supabase-production.md
    security-baseline.md
```

### Workflow de deployment

```bash
# No servidor
cd /opt/supabase
git pull origin main

# Carregar variáveis de ambiente (arquivo existe apenas no servidor)
source .env

# Iniciar/atualizar o stack
docker compose up -d

# Health Check
./scripts/health-check.sh
```

### Condição verificável

```bash
# Existem uncommitted changes no servidor?
cd /opt/supabase && git status --porcelain

# Expectativa: vazio (nenhuma alteração local)

# O servidor está na versão atual?
git log --oneline -1
# Comparar com Remote
git fetch origin && git diff HEAD origin/main --stat

# Expectativa: nenhuma diferença
```

### Cenário de falha

Alterações manuais no `docker-compose.yml` no servidor são sobrescritas no próximo `git pull` ou geram conflitos de merge. Pior ainda: ninguém sabe qual alteração foi feita quando e por quem. Após a perda de um servidor, a configuração não é reproduzível.

## C2 - docker-compose.yml: stack mínimo de produção

### Implementação

O Supabase fornece um arquivo Compose de referência com mais de 400 linhas e cerca de 15 serviços. Nem todos são necessários para produção. Aqui estão as decisões relevantes de segurança:

**Stack mínimo (estes serviços são necessários):**

```
postgres          Banco de dados
kong              API Gateway
gotrue            Auth
postgrest         REST API
realtime          WebSocket (se necessário)
storage           File Storage (se necessário)
meta              Metadados para PostgREST
```

**Não em produção (omitir ou apenas internamente):**

```
studio            Admin UI, apenas via SSH Tunnel ou VPN
imgproxy          apenas se transformações de imagem forem necessárias
inbucket          apenas para testes locais de e-mail
```

Trecho da configuração relevante de segurança:

```yaml
# docker-compose.yml (trecho, partes relevantes de segurança)

services:
  postgres:
    image: supabase/postgres:15.6.1.143    # Fixar versão
    restart: unless-stopped
    ports:
      - "10.0.1.10:5432:5432"              # APENAS interface interna
    environment:
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    volumes:
      - postgres-data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 30s
      timeout: 10s
      retries: 3

  kong:
    image: kong:2.8.1                       # Fixar versão
    restart: unless-stopped
    ports:
      - "127.0.0.1:8000:8000"              # APENAS localhost (Reverse Proxy na frente)
    environment:
      KONG_DNS_ORDER: LAST,A,CNAME
      KONG_PLUGINS: request-transformer,cors,key-auth,acl
      KONG_NGINX_PROXY_PROXY_BUFFER_SIZE: 160k
      KONG_NGINX_PROXY_PROXY_BUFFERS: 64 160k

  gotrue:
    image: supabase/gotrue:v2.164.0         # Fixar versão
    restart: unless-stopped
    environment:
      GOTRUE_JWT_SECRET: ${JWT_SECRET}
      GOTRUE_JWT_EXP: 3600                  # 1 hora, não mais
      GOTRUE_EXTERNAL_EMAIL_ENABLED: true
      GOTRUE_MAILER_AUTOCONFIRM: false      # Forçar confirmação por e-mail
      GOTRUE_DISABLE_SIGNUP: false           # definir como true se registro estiver fechado
      GOTRUE_RATE_LIMIT_HEADER: X-Real-IP
      GOTRUE_SECURITY_REFRESH_TOKEN_ROTATION_ENABLED: true
      GOTRUE_SECURITY_REFRESH_TOKEN_REUSE_INTERVAL: 10
      API_EXTERNAL_URL: https://app.example.com

  postgrest:
    image: postgrest/postgrest:v12.2.3      # Fixar versão
    restart: unless-stopped
    environment:
      PGRST_DB_URI: postgres://authenticator:${POSTGRES_PASSWORD}@postgres:5432/postgres
      PGRST_DB_ANON_ROLE: anon
      PGRST_JWT_SECRET: ${JWT_SECRET}

volumes:
  postgres-data:

networks:
  default:
    driver: bridge
```

**Pontos críticos de configuração:**

```
GOTRUE_JWT_EXP: 3600         não superior a 3600 (1h)
GOTRUE_MAILER_AUTOCONFIRM    false em produção
GOTRUE_DISABLE_SIGNUP         true se não houver registro aberto
REFRESH_TOKEN_ROTATION        true (impede reuso de token)
Versões das imagens           sempre fixar, nunca :latest
Porta do Postgres             vincular apenas na interface interna
Porta do Kong                 apenas no localhost (Reverse Proxy na frente)
```

### Condição verificável

```bash
# Imagens fixadas (nenhum :latest)?
grep "image:" docker-compose.yml | grep -c "latest"
# Expectativa: 0

# Postgres acessível apenas internamente?
docker compose exec postgres ss -tlnp | grep 5432
# Expectativa: apenas 10.0.1.10:5432 ou 0.0.0.0:5432 (então verificar firewall)

# Postgres não acessível externamente?
nmap -p 5432 app.example.com
# Expectativa: filtered ou closed

# JWT Expiry correto?
grep "GOTRUE_JWT_EXP" .env
# Expectativa: 3600 ou menos

# Supabase Studio não acessível externamente?
curl -s -o /dev/null -w "%{http_code}" https://app.example.com:3000
# Expectativa: Timeout ou Connection Refused
```

### Cenário de falha

Imagens sem versão fixada (`image: supabase/gotrue:latest`) podem, ao executar um `docker compose pull`, introduzir silenciosamente uma nova versão que contém Breaking Changes ou uma vulnerabilidade conhecida. Se o Postgres escuta em `0.0.0.0:5432` e o firewall falha temporariamente, o banco de dados inteiro fica acessível na internet. Se `GOTRUE_JWT_EXP` está definido como 86400 (24h), um token roubado é válido por um dia inteiro.

## C3 - Gerenciar secrets de forma completa e segura

### Implementação

Um stack Supabase possui no mínimo estes secrets:

```bash
# .env (apenas no servidor, nunca no Git)

# Secrets principais
JWT_SECRET=                    # mín. 32 caracteres, gerado com openssl rand -base64 32
ANON_KEY=                      # JWT Token com role anon
SERVICE_ROLE_KEY=              # JWT Token com service_role, bypassa RLS
POSTGRES_PASSWORD=             # mín. 24 caracteres, gerado

# Dashboard
DASHBOARD_USERNAME=            # Login do Supabase Studio
DASHBOARD_PASSWORD=            # mín. 16 caracteres

# E-Mail (GoTrue)
SMTP_HOST=
SMTP_PORT=
SMTP_USER=
SMTP_PASS=
SMTP_SENDER_NAME=

# Storage (se backend S3)
S3_ACCESS_KEY=
S3_SECRET_KEY=
```

**Gerar secrets:**

```bash
# JWT Secret
openssl rand -base64 32

# Senha do Postgres
openssl rand -base64 24

# Gerar Anon e Service Role Keys (Supabase CLI)
# Ou criar JWT manualmente com o JWT_SECRET
```

**Gerenciamento de secrets no servidor:**

```bash
# Arquivo .env com permissões restritivas
chmod 600 /opt/supabase/.env
chown deploy:deploy /opt/supabase/.env

# Verificar que .env não está no Git
cat /opt/supabase/.gitignore | grep ".env"
```

**No repositório fica apenas o template:**

```bash
# .env.example (no Git)
JWT_SECRET=generate-with-openssl-rand-base64-32
ANON_KEY=generate-jwt-with-anon-role
SERVICE_ROLE_KEY=generate-jwt-with-service-role
POSTGRES_PASSWORD=generate-with-openssl-rand-base64-24
DASHBOARD_USERNAME=admin
DASHBOARD_PASSWORD=generate-min-16-chars
SMTP_HOST=
SMTP_PORT=587
SMTP_USER=
SMTP_PASS=
SMTP_SENDER_NAME=
```

O mesmo princípio se aplica a toda [segurança de dados na infraestrutura de IA corporativa](/br/revista/seguranca-dados-ia-enterprise/).

### Condição verificável

```bash
# .env não está no Git?
cd /opt/supabase && git ls-files .env
# Expectativa: vazio

# .env está no .gitignore?
grep "^\.env$" .gitignore
# Expectativa: .env

# Permissões do arquivo corretas?
stat -c "%a %U" .env
# Expectativa: 600 deploy

# Secrets com comprimento suficiente?
awk -F= '{if (length($2) < 16 && $2 != "" && $1 !~ /PORT|HOST|NAME/) print "MUITO CURTO: "$1}' .env
# Expectativa: nenhuma saída

# Nenhuma senha padrão?
grep -iE "password|secret" .env | grep -iE "change.me|default|example|your.*here"
# Expectativa: nenhum resultado
```

### Cenário de falha

O problema de segurança mais comum no Supabase Self-Hosting não é um exploit de servidor, mas sim um secret vazado. Se o `.env` for commitado no Git e o repositório for público (ou se tornar público), todos os secrets ficam expostos. Com a `SERVICE_ROLE_KEY`, é possível ler e escrever no banco de dados inteiro sem RLS.

## C4 - Verificar políticas de banco de dados

### Implementação

No Supabase, grande parte da segurança está no PostgreSQL Row Level Security (RLS), não no servidor de aplicação. Cada tabela no schema `public` deve ter RLS ativado.

**Encontrar tabelas sem RLS:**

```sql
-- Todas as tabelas public sem RLS
SELECT schemaname, tablename, rowsecurity
FROM pg_tables
WHERE schemaname = 'public'
  AND rowsecurity = false;
```

**Encontrar tabelas com RLS mas sem policies:**

```sql
-- RLS ativo mas nenhuma policy definida = nenhum acesso possível
-- (pode ser intencional, mas verificar)
SELECT t.tablename
FROM pg_tables t
LEFT JOIN pg_policies p ON t.tablename = p.tablename
WHERE t.schemaname = 'public'
  AND t.rowsecurity = true
  AND p.policyname IS NULL;
```

**Encontrar policies excessivamente abertas:**

```sql
-- Policies que concedem acesso total a todas as roles
SELECT tablename, policyname, permissive, roles, cmd, qual
FROM pg_policies
WHERE schemaname = 'public'
  AND (roles = '{public}' OR qual = 'true');
```

**Verificar uso do Service Role:**

```sql
-- Quais roles existem e quais permissões possuem?
SELECT rolname, rolsuper, rolcreaterole, rolcreatedb
FROM pg_roles
WHERE rolname IN ('anon', 'authenticated', 'service_role', 'authenticator');
```

### Condição verificável

```bash
# Como script automatizado a partir do audit-runner
ssh supabase-prod "docker compose exec -T postgres psql -U postgres -c \"
  SELECT tablename FROM pg_tables
  WHERE schemaname = 'public' AND rowsecurity = false;
\""

# Expectativa: nenhuma tabela (ou apenas exceções intencionais)
```

### Cenário de falha

Uma tabela `users` com `rowsecurity = false` é totalmente legível via PostgREST API por qualquer pessoa com a `anon` key. Isso inclui todas as colunas, inclusive endereços de e-mail, números de telefone e outros dados pessoais. Um simples comando `curl` com a `anon` key pública é suficiente.

## Parte D - Operação e monitoramento

Estes passos são executados regularmente e de forma automatizada.

## D1 - Automatizar backups

### Implementação

Dumps diários do PostgreSQL, criptografados e armazenados externamente.

```bash
#!/bin/bash
# scripts/backup.sh

set -euo pipefail

BACKUP_DIR="/opt/backups"
DATE=$(date +%Y-%m-%d_%H%M)
RETENTION_DAYS=30
GPG_RECIPIENT="backup@example.com"   # GPG Key ID

# PostgreSQL Dump
docker compose exec -T postgres pg_dump \
  -U postgres \
  --format=custom \
  --compress=9 \
  postgres > "${BACKUP_DIR}/db_${DATE}.dump"

# Salvar Storage Buckets (se Supabase Storage for utilizado)
docker compose exec -T storage tar -czf - /var/lib/storage \
  > "${BACKUP_DIR}/storage_${DATE}.tar.gz"

# Criptografar
for file in "${BACKUP_DIR}"/*_${DATE}.*; do
  gpg --encrypt --recipient "${GPG_RECIPIENT}" "$file"
  rm "$file"   # Apagar versão não criptografada
done

# Copiar para servidor externo (audit-runner ou S3)
rsync -az "${BACKUP_DIR}/"*_${DATE}*.gpg \
  deploy@10.0.1.11:/opt/backup-archive/

# Apagar backups antigos (localmente)
find "${BACKUP_DIR}" -name "*.gpg" -mtime +${RETENTION_DAYS} -delete

# No servidor de backup, também limpar
ssh deploy@10.0.1.11 \
  "find /opt/backup-archive -name '*.gpg' -mtime +${RETENTION_DAYS} -delete"

echo "Backup ${DATE} concluído"
```

```bash
# Configurar Cron Job
# crontab -e
0 3 * * * /opt/supabase/scripts/backup.sh >> /var/log/backup.log 2>&1
```

### Condição verificável

```bash
# Backup de hoje existe?
ls -la /opt/backups/*_$(date +%Y-%m-%d)*.gpg

# Backup chegou no servidor externo?
ssh deploy@10.0.1.11 "ls -la /opt/backup-archive/*_$(date +%Y-%m-%d)*.gpg"

# Tamanho do backup plausível (não 0 bytes)?
find /opt/backups -name "*.gpg" -size 0 -print
# Expectativa: nenhum resultado
```

### Cenário de falha

Armazenar backups apenas no mesmo servidor significa: se o servidor falhar ou for criptografado (Ransomware), os backups também se perdem. Backups não criptografados em um servidor externo são um vazamento de dados, pois o dump contém todos os dados das tabelas em texto plano.

## D2 - Testar o restore regularmente

### Implementação

Uma vez por mês, restaurar um backup em um sistema de teste.

```bash
#!/bin/bash
# scripts/restore-test.sh

set -euo pipefail

BACKUP_FILE=$1   # ex.: /opt/backup-archive/db_2026-03-01_0300.dump.gpg

# Descriptografar
gpg --decrypt "$BACKUP_FILE" > /tmp/restore-test.dump

# Iniciar container de teste
docker run -d --name restore-test \
  -e POSTGRES_PASSWORD=testpassword \
  supabase/postgres:15.6.1.143

sleep 10

# Restore
docker exec -i restore-test pg_restore \
  -U postgres \
  --dbname=postgres \
  --clean \
  --if-exists \
  < /tmp/restore-test.dump

# Verificar tabelas
docker exec restore-test psql -U postgres -c \
  "SELECT schemaname, tablename FROM pg_tables WHERE schemaname = 'public';"

# Verificar Row Counts
docker exec restore-test psql -U postgres -c \
  "SELECT relname, n_live_tup FROM pg_stat_user_tables ORDER BY n_live_tup DESC LIMIT 10;"

# Limpar
docker rm -f restore-test
rm /tmp/restore-test.dump

echo "Teste de restore concluído"
```

### Condição verificável

```bash
# Executar script de teste de restore e verificar Exit Code
./scripts/restore-test.sh /opt/backup-archive/db_latest.dump.gpg
echo $?
# Expectativa: 0

# Verificar log do último teste de restore
cat /var/log/restore-test.log | tail -20
```

### Cenário de falha

Muitas equipes possuem backups que rodam há meses, mas nunca testaram um restore. Problemas típicos: formato incorreto do `pg_dump` (Plain Text em vez de Custom), permissões ausentes no restore, versões incompatíveis do PostgreSQL entre backup e restore. Tudo isso só aparece quando o restore é realmente necessário.

## D3 - Checks diários de infraestrutura

### Implementação

Um script no audit-runner verifica diariamente o estado do sistema de produção.

```bash
#!/bin/bash
# scripts/security-check.sh (roda no audit-runner)

set -euo pipefail

PROD_HOST="10.0.1.10"
REPORT=""
CRITICAL=0

# 1. Status dos Containers
STOPPED=$(ssh deploy@${PROD_HOST} "docker compose ps --format json" | \
  jq -r 'select(.State != "running") | .Name')
if [ -n "$STOPPED" ]; then
  REPORT+="CRITICO: Containers não running: ${STOPPED}\n"
  CRITICAL=1
fi

# 2. Portas abertas externamente
OPEN_PORTS=$(nmap -p 22,80,443,3000,5432,8000,9000 app.example.com \
  --open -oG - | grep "/open/" | grep -v "443/open")
if [ -n "$OPEN_PORTS" ]; then
  REPORT+="CRITICO: Portas inesperadas abertas: ${OPEN_PORTS}\n"
  CRITICAL=1
fi

# 3. Data de expiração do certificado
CERT_EXPIRY=$(echo | openssl s_client -connect app.example.com:443 2>/dev/null | \
  openssl x509 -noout -enddate | cut -d= -f2)
CERT_EPOCH=$(date -d "$CERT_EXPIRY" +%s)
NOW_EPOCH=$(date +%s)
DAYS_LEFT=$(( (CERT_EPOCH - NOW_EPOCH) / 86400 ))
if [ "$DAYS_LEFT" -lt 14 ]; then
  REPORT+="AVISO: Certificado TLS expira em ${DAYS_LEFT} dias\n"
fi

# 4. Drift do Firewall
FIREWALL_DIFF=$(ssh deploy@${PROD_HOST} "iptables-save" | \
  diff /opt/baselines/firewall-baseline.txt - || true)
if [ -n "$FIREWALL_DIFF" ]; then
  REPORT+="AVISO: Firewall foi alterado:\n${FIREWALL_DIFF}\n"
fi

# 5. Versões das imagens Docker (Drift contra Baseline)
IMAGE_DIFF=$(ssh deploy@${PROD_HOST} \
  "docker compose images --format '{{.Repository}}:{{.Tag}}'" | \
  diff /opt/baselines/image-versions.txt - || true)
if [ -n "$IMAGE_DIFF" ]; then
  REPORT+="AVISO: Versões dos containers foram alteradas:\n${IMAGE_DIFF}\n"
fi

# 6. Espaço em disco
DISK_USAGE=$(ssh deploy@${PROD_HOST} "df -h / | tail -1 | awk '{print \$5}' | tr -d '%'")
if [ "$DISK_USAGE" -gt 85 ]; then
  REPORT+="AVISO: Uso de disco em ${DISK_USAGE}%\n"
fi

# 7. Status do Backup
LAST_BACKUP=$(ssh deploy@${PROD_HOST} "ls -t /opt/backups/*.gpg 2>/dev/null | head -1")
if [ -z "$LAST_BACKUP" ]; then
  REPORT+="CRITICO: Nenhum backup encontrado\n"
  CRITICAL=1
else
  BACKUP_AGE=$(ssh deploy@${PROD_HOST} \
    "echo \$(( (\$(date +%s) - \$(stat -c %Y ${LAST_BACKUP})) / 3600 ))")
  if [ "$BACKUP_AGE" -gt 26 ]; then
    REPORT+="AVISO: Último backup tem ${BACKUP_AGE} horas\n"
  fi
fi

# 8. Verificação de RLS
UNPROTECTED=$(ssh deploy@${PROD_HOST} "docker compose exec -T postgres psql -U postgres -t -c \
  \"SELECT count(*) FROM pg_tables WHERE schemaname = 'public' AND rowsecurity = false;\"" | tr -d ' ')
if [ "$UNPROTECTED" -gt 0 ]; then
  REPORT+="AVISO: ${UNPROTECTED} tabelas sem RLS\n"
fi

# Resultado
echo "=== Security Check $(date) ==="
if [ -n "$REPORT" ]; then
  echo -e "$REPORT"
else
  echo "Todos os checks aprovados"
fi

# Em caso de findings críticos: enviar alerta
if [ "$CRITICAL" -eq 1 ]; then
  echo -e "$REPORT" | mail -s "CRITICO: Security Check $(date)" ops@example.com
fi
```

```bash
# Cron no audit-runner
0 7 * * * /opt/audit/scripts/security-check.sh >> /var/log/security-check.log 2>&1
```

### Condição verificável

```bash
# O script de check rodou hoje?
grep "$(date +%Y-%m-%d)" /var/log/security-check.log | tail -1
# Expectativa: entrada de hoje presente

# Resultado?
grep "Todos os checks aprovados\|CRITICO\|AVISO" /var/log/security-check.log | tail -5
```

## D4 - Claude Code como camada de análise contextual

O Claude Code analisa os resultados dos checks determinísticos e reconhece correlações que scripts não conseguem identificar.

### Arquitetura

```
Checks diários (D3)
     |
     +-- Findings determinísticos
     |   (portas abertas, drift de firewall, backups ausentes)
     |
     +---> Review semanal com Claude Code
          |
          +-- Arquivos de config (docker-compose.yml, Caddyfile, .env.example)
          +-- Logs dos Security Checks dos últimos 7 dias
          +-- Git Diff das alterações de infraestrutura
          +-- Exportação de RLS Policies
          |
          +---> Relatório priorizado
               |
               +---> Decisão DevOps (humano)
```

### Script concreto

```bash
#!/bin/bash
# scripts/claude-review-prep.sh (roda no audit-runner)

REPORT_DIR="/opt/audit/weekly-reports"
DATE=$(date +%Y-%m-%d)
OUTPUT="${REPORT_DIR}/review-input-${DATE}.md"

mkdir -p "$REPORT_DIR"

cat > "$OUTPUT" << 'HEADER'
# Input para Review Semanal de Segurança

## Contexto
Stack Supabase self-hosted na Hetzner Cloud.
Arquitetura: Reverse Proxy -> Kong -> Supabase Services -> PostgreSQL
Sistema de auditoria em servidor separado.
HEADER

# Logs dos Security Checks dos últimos 7 dias
echo -e "\n## Resultados dos Security Checks (últimos 7 dias)\n" >> "$OUTPUT"
echo '```' >> "$OUTPUT"
grep -A 20 "Security Check" /var/log/security-check.log | \
  tail -100 >> "$OUTPUT"
echo '```' >> "$OUTPUT"

# Configuração atual do Docker Compose (sem secrets)
echo -e "\n## docker-compose.yml atual\n" >> "$OUTPUT"
echo '```yaml' >> "$OUTPUT"
ssh deploy@10.0.1.10 "cat /opt/supabase/docker-compose.yml" >> "$OUTPUT"
echo '```' >> "$OUTPUT"

# Git Diff da última semana
echo -e "\n## Alterações de infraestrutura (últimos 7 dias)\n" >> "$OUTPUT"
echo '```' >> "$OUTPUT"
ssh deploy@10.0.1.10 "cd /opt/supabase && git log --oneline --since='7 days ago'" >> "$OUTPUT"
ssh deploy@10.0.1.10 "cd /opt/supabase && git diff HEAD~5 --stat" >> "$OUTPUT" 2>/dev/null
echo '```' >> "$OUTPUT"

# Status do RLS
echo -e "\n## Status do RLS\n" >> "$OUTPUT"
echo '```' >> "$OUTPUT"
ssh deploy@10.0.1.10 "docker compose exec -T postgres psql -U postgres -c \"
  SELECT tablename, rowsecurity FROM pg_tables WHERE schemaname = 'public' ORDER BY tablename;
\"" >> "$OUTPUT"
echo '```' >> "$OUTPUT"

# Versões dos containers
echo -e "\n## Versões dos containers\n" >> "$OUTPUT"
echo '```' >> "$OUTPUT"
ssh deploy@10.0.1.10 "docker compose images --format '{{.Repository}}:{{.Tag}}'" >> "$OUTPUT"
echo '```' >> "$OUTPUT"

echo "Input para review criado: $OUTPUT"
```

### O que o Claude Code não faz

```
Claude NÃO executa alterações automáticas em produção.
Claude NÃO faz deploy.
Claude NÃO rotaciona secrets.
Claude NÃO possui acesso direto ao servidor de produção.

Claude analisa dados que lhe são fornecidos
e cria relatórios para decisões humanas.
```

## Checklist de deployment

Antes da primeira ativação e após alterações significativas:

```
Parte A - Infraestrutura
  [ ] Dois servidores separados (prod + audit)
  [ ] Rede privada configurada e testada
  [ ] Cloud Firewall ativo (apenas 443, SSH do IP do admin)
  [ ] Host Firewall ativo (iptables)
  [ ] Baseline do firewall salva
  [ ] SSH: apenas keys, sem root, sem senha
  [ ] Reverse Proxy configurado (Caddy/Nginx)
  [ ] TLS ativo com renovação automática
  [ ] Security Headers definidos (HSTS, CSP, X-Frame-Options)
  [ ] WebSocket Proxy para Realtime configurado

Parte B - Serviços do Supabase
  Secrets (B0)
    [ ] Todos os secrets gerados (nenhum valor padrão)
    [ ] JWT_SECRET no mínimo 32 caracteres
    [ ] POSTGRES_PASSWORD no mínimo 24 caracteres
    [ ] DASHBOARD_PASSWORD no mínimo 16 caracteres
    [ ] SECRET_KEY_BASE no mínimo 64 caracteres
    [ ] MINIO_ROOT_PASSWORD no mínimo 8 caracteres (se MinIO)
    [ ] DB_ENC_KEY alterado (não "supabaserealtime")
  PostgreSQL (B1)
    [ ] Porta apenas na interface interna (10.0.1.10:5432)
    [ ] Init-Scripts inalterados (roles.sql, jwt.sql etc.)
    [ ] Roles corretamente criadas (anon não é superuser)
  Kong (B2)
    [ ] Porta apenas no localhost (127.0.0.1:8000)
    [ ] JWT-Validation ativa em todas as rotas de API
    [ ] Senha do dashboard forte
  GoTrue (B3)
    [ ] JWT_EXP no máximo 3600
    [ ] AUTOCONFIRM false
    [ ] SMTP configurado e testado
    [ ] SITE_URL e API_EXTERNAL_URL corretos
    [ ] Refresh Token Rotation ativo
    [ ] DISABLE_SIGNUP definido se app fechada
  PostgREST (B4)
    [ ] Usa role authenticator (não postgres)
    [ ] DB_SCHEMAS explicitamente definidos
  Realtime (B5)
    [ ] DB_ENC_KEY alterado
    [ ] SECRET_KEY_BASE no mínimo 64 caracteres
  Storage / MinIO (B6)
    [ ] MinIO não acessível externamente
    [ ] Credenciais padrão do MinIO alteradas
    [ ] Permissões do volume do Storage corretas
  Serviços internos (B7)
    [ ] Porta do Analytics apenas localhost
    [ ] Vector Docker Socket Read-Only
    [ ] Porta do Supavisor apenas interna
    [ ] Logflare Tokens não estão no padrão
  Studio (B8)
    [ ] Em produção desativado OU apenas via SSH Tunnel
    [ ] Senha do dashboard forte

Parte C - Configuração do stack
  [ ] docker-compose.yml versionado no Git
  [ ] Todas as versões de imagem fixadas (nenhum :latest)
  [ ] .env não está no Git
  [ ] Permissões do .env: 600
  [ ] .env.example no Git como template
  [ ] Nenhuma senha padrão
  [ ] RLS ativo em todas as tabelas public
  [ ] Nenhuma tabela sem policies (exceto intencionalmente)
  [ ] Nenhuma policy excessivamente aberta (qual = 'true')

Parte D - Operação e monitoramento
  [ ] Job de backup diário ativo
  [ ] Backups criptografados
  [ ] Backups armazenados externamente (audit-runner ou S3)
  [ ] Teste de restore realizado pelo menos uma vez
  [ ] Estratégia de retenção configurada
  [ ] Job diário de security check no audit-runner
  [ ] Alerting em caso de findings críticos
  [ ] Review semanal com Claude Code configurado

Parte E - Atualizações e manutenção
  [ ] Unattended Upgrades instalado e ativo
  [ ] Intervalo de atualização automática configurado para diário
  [ ] Imagens do Supabase fixadas (sem :latest)
  [ ] Nenhuma imagem do Supabase com mais de 90 dias
  [ ] Commit de atualização nos últimos 45 dias
  [ ] Script auto-patch para PostgreSQL minor patches ativo
  [ ] Cron auto-patch DEPOIS do cron de backup (03:00 após 02:00)
  [ ] Monitor de releases de segurança no audit-runner ativo (diário)
  [ ] Trivy instalado no audit-runner
  [ ] Cron de verificação de manutenção no audit-runner (semanal segunda-feira)
  [ ] Certificado TLS válido por pelo menos 14 dias
  [ ] Uso de disco abaixo de 85%
```

## Parte E - Atualizações e manutenção

Um stack self-hosted que não é atualizado regularmente acumula vulnerabilidades de segurança. CVEs não corrigidas no PostgreSQL, Kong ou GoTrue são vetores de ataque reais. Ao mesmo tempo, atualizações podem introduzir breaking changes que derrubam o stack.

Por isso, o processo de atualização precisa de regras claras: o que é atualizado e quando, como se testa, e como se garante que nada seja esquecido.

### E1 - Três níveis de atualização

O stack tem três níveis de atualização independentes, com ritmos e riscos diferentes.

```
Nível 1: OS (Ubuntu)
   │  O quê: Kernel, pacotes do sistema, OpenSSL, Docker Engine
   │  Ritmo: Patches de segurança semanais, atualização completa mensal
   │  Risco: Baixo (apt upgrade é estável)
   │  Método: apt update && apt upgrade
   │
Nível 2: Serviços Supabase (Docker Images)
   │  O quê: PostgreSQL, Kong, GoTrue, PostgREST, Realtime, Storage, etc.
   │  Ritmo: Mensal (ciclo de releases do Supabase)
   │  Risco: Médio a alto (breaking changes entre versões)
   │  Método: Alterar image tags no docker-compose.yml, pull, restart
   │
Nível 3: Reverse Proxy e ferramentas
   │  O quê: Caddy, iptables, GPG, nmap, jq
   │  Ritmo: Em caso de security advisories ou trimestralmente
   │  Risco: Baixo
   │  Método: apt upgrade (Caddy via repositório próprio)
```

**Condição verificável:**

```bash
# OS: Quando foi o último apt upgrade?
stat -c %y /var/cache/apt/pkgcache.bin
# Expectativa: menos de 7 dias atrás

# Supabase: Quais versões de imagem estão rodando?
cd /opt/supabase && docker compose images --format '{{.Repository}}:{{.Tag}}'

# Versão do Caddy
caddy version
```

**Cenário de falha:** Um PostgreSQL não atualizado com uma vulnerabilidade conhecida de Remote Code Execution (como CVE-2023-5869) pode ser explorado por um atacante, mesmo que o RLS esteja configurado corretamente. Um Kong desatualizado com uma vulnerabilidade conhecida de auth bypass pode contornar a validação de JWT.

### E2 - Atualizações no nível do OS

**Semanalmente: patches de segurança (automático)**

```bash
# Instalar e configurar Unattended Upgrades
sudo apt install -y unattended-upgrades

# Configuração: apenas Security Updates automáticos
sudo tee /etc/apt/apt.conf.d/50unattended-upgrades > /dev/null << 'EOF'
Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
};

// Reboot automático se necessário (ex.: atualização de kernel)
// Ativar somente se for aceitável que o servidor
// reinicie brevemente às 4h da manhã
Unattended-Upgrade::Automatic-Reboot "false";

// Notificação por e-mail sobre atualizações
Unattended-Upgrade::Mail "ops@example.com";
Unattended-Upgrade::MailReport "on-change";
EOF

# Ativar atualizações automáticas
sudo tee /etc/apt/apt.conf.d/20auto-upgrades > /dev/null << 'EOF'
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::AutocleanInterval "7";
EOF

sudo systemctl enable unattended-upgrades
sudo systemctl start unattended-upgrades
```

**Mensalmente: atualização completa do sistema (manual, com verificação)**

```bash
# Primeiro verificar o que será atualizado
apt list --upgradable

# Então atualizar
sudo apt update && sudo apt upgrade -y

# Atualização do Docker Engine (separada, via repositório Docker)
sudo apt install --only-upgrade docker-ce docker-ce-cli containerd.io

# Após atualizações de kernel: reboot necessário?
if [ -f /var/run/reboot-required ]; then
  echo "REBOOT ERFORDERLICH"
fi
```

**Condição verificável:**

```bash
# Unattended Upgrades ativo?
systemctl is-active unattended-upgrades

# Últimas atualizações automáticas
cat /var/log/unattended-upgrades/unattended-upgrades.log | tail -20

# Atualizações de segurança pendentes?
apt list --upgradable 2>/dev/null | grep -i security | wc -l
# Expectativa: 0
```

### E3 - Atualizações dos serviços Supabase

O Supabase publica aproximadamente a cada mês novas Docker images. O processo de atualização precisa ser controlado, pois breaking changes entre versões são possíveis.

**Workflow:**

```
1. Ler as release notes (github.com/supabase/supabase/releases)
2. Inserir os novos image tags no docker-compose.yml
3. Testar em staging/teste (ou: backup + plano de rollback)
4. Criar backup
5. docker compose pull
6. docker compose down && docker compose up -d
7. Verificar health checks
8. Atualizar baselines
```

**Verificar versões atuais vs. disponíveis:**

```bash
cd /opt/supabase

echo "=== Aktuelle Versionen ==="
docker compose images --format '{{.Repository}}:{{.Tag}}'

echo ""
echo "=== Verfügbare Updates ==="
# Die offiziellen Releases prüfen
echo "Supabase Releases: https://github.com/supabase/supabase/releases"
echo "GoTrue: https://github.com/supabase/gotrue/releases"
echo "PostgREST: https://github.com/PostgREST/postgrest/releases"
echo "Realtime: https://github.com/supabase/realtime/releases"
echo ""
echo "Oder den offiziellen docker-compose.yml vergleichen:"
echo "https://raw.githubusercontent.com/supabase/supabase/master/docker/docker-compose.yml"
```

**Procedimento seguro de atualização:**

```bash
cd /opt/supabase

# 1. Backup VOR dem Update
./scripts/backup.sh

# 2. Aktuelle Versionen dokumentieren
docker compose images --format '{{.Repository}}:{{.Tag}}' > /opt/baselines/pre-update-versions.txt

# 3. Neue Versionen in docker-compose.yml eintragen
# MANUELL: Image Tags auf die neue Version ändern
# z.B. supabase/gotrue:v2.164.0 → supabase/gotrue:v2.184.0

# 4. Pull neue Images
docker compose pull

# 5. Stack neu starten
docker compose down
docker compose up -d

# 6. Warten und Health Checks
sleep 30
docker compose ps --format "table {{.Name}}\t{{.Status}}"

# 7. Alle Services prüfen
docker compose exec -T auth wget --no-verbose --tries=1 --spider http://localhost:9999/health
docker compose exec -T db pg_isready -U postgres -h localhost
curl -s -o /dev/null -w "Kong: %{http_code}\n" http://localhost:8000
curl -s -o /dev/null -w "Storage: %{http_code}\n" http://localhost:8000/storage/v1/

# 8. Baselines aktualisieren
docker compose images --format '{{.Repository}}:{{.Tag}}' > /opt/baselines/image-versions.txt

# 9. Git Commit
git add docker-compose.yml
git commit -m "Update Supabase images to [VERSION]"
```

**Rollback em caso de falha:**

```bash
cd /opt/supabase

# Alte Versionen wiederherstellen
git checkout HEAD~1 -- docker-compose.yml
docker compose pull
docker compose down
docker compose up -d

# Wenn Datenbank-Migration das Problem ist:
./scripts/restore.sh /opt/backups/[LETZTES_BACKUP].gpg
```

**Condição verificável:**

```bash
# Image-Versionen älter als 3 Monate?
cd /opt/supabase
docker compose images --format '{{.Repository}}:{{.Tag}}' | while read image; do
  CREATED=$(docker inspect --format='{{.Created}}' "$image" 2>/dev/null | cut -dT -f1)
  if [ -n "$CREATED" ]; then
    AGE_DAYS=$(( ($(date +%s) - $(date -d "$CREATED" +%s)) / 86400 ))
    [ "$AGE_DAYS" -gt 90 ] && echo "WARNUNG: $image ist $AGE_DAYS Tage alt"
  fi
done
```

**Cenário de falha:** O Supabase GoTrue v2.170.0 teve uma alteração no tratamento de Refresh Token que quebrou clientes mais antigos. Sem leitura prévia das release notes e sem backup, isso teria causado uma indisponibilidade. Atualizações de versão major do PostgreSQL (ex.: 15 -> 16) exigem um ciclo de `pg_dump/pg_restore` - uma simples troca de image tag não é suficiente.

### E3b - Patching automático (Nível 1)

Nem todas as atualizações exigem intervenção humana. Minor patches do PostgreSQL e atualizações do Caddy são de baixo risco e podem ser aplicados automaticamente durante a noite.

**Modelo de dois níveis:**

```
NÍVEL 1 - AUTOMÁTICO (auto-patch.sh, diário 03:00):
  OS Security Patches (unattended-upgrades)
  PostgreSQL Minor Patches (15.8.1.x -> 15.8.1.y)
  Caddy Updates
  -> E-mail informativo após patch bem-sucedido
  -> E-mail de alarme em caso de falha no health check
  -> Rollback automático em caso de falha

NÍVEL 2 - MANUAL (/supabase-update, dentro de 24h após alerta):
  GoTrue/Auth (breaking changes possíveis)
  PostgREST (comportamento de queries pode mudar)
  Kong (roteamento pode mudar)
  Realtime, Storage, Supavisor
  PostgreSQL MAJOR (15 -> 16, requer pg_dump/pg_restore)
```

O script `auto-patch.sh` roda diariamente às 03:00 (após o backup às 02:00) e:

1. Verifica se existe um backup atual (cancela se não existir)
2. Salva o estado atual (docker-compose.yml, versões de imagem)
3. Verifica se há uma nova minor image do PostgreSQL disponível
4. Aplica a atualização e executa um health check
5. Em caso de falha: rollback automático para a versão anterior
6. Envia um e-mail informativo (sucesso) ou e-mail de alarme (falha)

**Condição verificável:**

```bash
# Auto-Patch Cron aktiv?
crontab -l | grep auto-patch
# Erwartung: 0 3 * * * /opt/supabase/scripts/auto-patch.sh

# Letzter Auto-Patch Lauf?
tail -20 /var/log/auto-patch.log

# Hat Auto-Patch jemals gepatcht?
grep "Patches eingespielt\|Keine Patches" /var/log/auto-patch.log | tail -5
```

**Cronograma (servidor de produção):**

```
02:00 diário   -> Backup (DB + Storage + externo)
03:00 diário   -> Auto-Patch (PostgreSQL Minor + Caddy)
04:00 mensal   -> Teste de restore
```

### E4 - Cronograma de atualizações e responsabilidades

```
Semanalmente (automático):
  [ ] OS Security Patches (unattended-upgrades)
  [ ] Audit-Runner verifica se patches foram aplicados

Mensalmente (manual, planejado):
  [ ] Verificar release notes do Supabase
  [ ] Avaliar novos image tags
  [ ] Criar backup
  [ ] Executar atualização
  [ ] Health checks
  [ ] Atualizar baselines

Trimestralmente (review):
  [ ] Verificar versão do Caddy
  [ ] Verificar versão do Docker Engine
  [ ] Verificar versão do Node.js (para Claude Code no audit-runner)
  [ ] Avaliar versão major do PostgreSQL
  [ ] Toda a toolchain atualizada?

Em caso de security advisories (imediato):
  [ ] CVE afeta nosso stack?
  [ ] Identificar imagem/pacote afetado
  [ ] Patch disponível?
  [ ] Executar atualização de emergência
```

**Condição verificável:**

```bash
# Wann war das letzte Supabase Update?
cd /opt/supabase
git log --oneline --grep="Update\|update\|upgrade" | head -5

# Wie alt ist der letzte Update-Commit?
LAST_UPDATE=$(git log --format="%ai" --grep="Update\|update" -1 2>/dev/null | cut -d' ' -f1)
if [ -n "$LAST_UPDATE" ]; then
  AGE=$(( ($(date +%s) - $(date -d "$LAST_UPDATE" +%s)) / 86400 ))
  echo "Letztes Update: $LAST_UPDATE ($AGE Tage her)"
  [ "$AGE" -gt 45 ] && echo "WARNUNG: Letztes Update über 45 Tage her"
fi
```

### E5 - Monitor de releases de segurança (diário)

O maior ponto cego no self-hosting não é a configuração inicial, mas sim o fato de perder security patches. Quando o Supabase GoTrue publica uma correção de auth bypass, a equipe precisa agir dentro de 24 horas, não depois de uma semana.

No audit-runner roda **diariamente** um script que verifica os GitHub Releases de todos os componentes do Supabase e alerta imediatamente por e-mail em caso de security releases.

**Componentes verificados:**

```
supabase/auth (GoTrue)          -> patches de segurança frequentes
PostgREST/postgrest             -> camada API
supabase/realtime               -> WebSocket
supabase/storage-api            -> File Storage
Kong/kong                       -> API Gateway
supabase/edge-runtime           -> Edge Functions
supabase/postgres               -> imagem do banco de dados
supabase/supavisor              -> connection pooler
moby/moby (Docker Engine)       -> container runtime
```

**Três camadas de verificação:**

```
Camada 1: GitHub Releases
  -> Existe uma nova versão?
  -> As release notes contêm "security"/"CVE"?

Camada 2: Trivy Container Scan
  -> Verifica cada Docker image em execução contra NVD/GitHub Advisories
  -> Encontra CVEs em todas as dependências (pacotes do OS, libraries)

Camada 3: OSV API
  -> Verifica vulnerabilidades no nível da aplicação para GoTrue, PostgREST etc.
  -> Complementa o Trivy com CVEs específicos de pacotes
```

**Como funciona:**

```
Diariamente 07:00 (cron do audit-runner)
   │
   ├── Buscar versões atuais do servidor de produção
   ├── GitHub API: verificar últimos releases de cada componente
   ├── Verificar release notes para "security", "CVE", "vulnerability"
   │
   ├── Security release encontrado?
   │     -> E-mail IMEDIATO para ops@
   │     -> "Ação necessária dentro de 24h"
   │
   └── Release normal encontrado?
         -> Resumo semanal (segunda-feira)
```

**Mecanismo de cache:** O script memoriza releases já reportados, para que o mesmo e-mail não seja enviado todos os dias. Apenas um NOVO release gera outro alerta.

**Condição verificável:**

```bash
# Security Release Monitor aktiv auf audit-runner?
ssh deploy@10.0.1.11 "crontab -l | grep security-release"
# Erwartung: täglicher Cron Job

# Letzter Check-Log
ssh deploy@10.0.1.11 "tail -5 /var/log/security-releases.log"
# Erwartung: Eintrag von heute

# Cache vorhanden (Script hat schon gelaufen)?
ssh deploy@10.0.1.11 "ls /opt/audit/cache/*-last-seen.txt 2>/dev/null | wc -l"
```

**Cenário de falha:** Em janeiro de 2024, o CVE-2023-5869 foi publicado para o PostgreSQL (Remote Code Execution). Quem não tinha um monitor de releases e verificava atualizações apenas mensalmente ficou vulnerável por 3-4 semanas. Com o monitor diário, o e-mail teria chegado no dia seguinte à publicação do release.

### E6 - Audit-Runner como vigilante de atualizações

O audit-runner monitora se as atualizações estão sendo realizadas e informa a equipe quando algo está atrasado.

No audit-runner roda um script semanal que verifica o seguinte:

```bash
#!/bin/bash
# scripts/check-maintenance.sh (läuft auf audit-runner)

PROD_HOST="10.0.1.10"
REPORT=""

echo "=== Maintenance Check $(date) ==="

# 1. OS Updates überfällig?
LAST_APT=$(ssh deploy@${PROD_HOST} "stat -c %Y /var/cache/apt/pkgcache.bin")
APT_AGE=$(( ($(date +%s) - $LAST_APT) / 86400 ))
if [ "$APT_AGE" -gt 7 ]; then
  REPORT+="WARNUNG: apt update ist ${APT_AGE} Tage her (max. 7)\n"
fi

# 2. Unattended Upgrades aktiv?
UA_STATUS=$(ssh deploy@${PROD_HOST} "systemctl is-active unattended-upgrades 2>/dev/null")
if [ "$UA_STATUS" != "active" ]; then
  REPORT+="KRITISCH: Unattended Upgrades nicht aktiv\n"
fi

# 3. Ausstehende Security Updates?
SEC_UPDATES=$(ssh deploy@${PROD_HOST} "apt list --upgradable 2>/dev/null | grep -ci security")
if [ "$SEC_UPDATES" -gt 0 ]; then
  REPORT+="WARNUNG: ${SEC_UPDATES} ausstehende Security Updates\n"
fi

# 4. Reboot erforderlich?
REBOOT=$(ssh deploy@${PROD_HOST} "test -f /var/run/reboot-required && echo ja || echo nein")
if [ "$REBOOT" = "ja" ]; then
  REPORT+="WARNUNG: Server-Reboot erforderlich (Kernel Update)\n"
fi

# 5. Supabase Image Alter
ssh deploy@${PROD_HOST} "cd /opt/supabase && docker compose images --format '{{.Repository}}:{{.Tag}}'" | \
while read image; do
  CREATED=$(ssh deploy@${PROD_HOST} "docker inspect --format='{{.Created}}' '$image' 2>/dev/null" | cut -dT -f1)
  if [ -n "$CREATED" ]; then
    AGE_DAYS=$(( ($(date +%s) - $(date -d "$CREATED" +%s 2>/dev/null || echo 0)) / 86400 ))
    if [ "$AGE_DAYS" -gt 90 ]; then
      REPORT+="WARNUNG: $image ist ${AGE_DAYS} Tage alt (max. 90)\n"
    fi
  fi
done

# 6. Letztes Supabase Update?
LAST_UPDATE=$(ssh deploy@${PROD_HOST} "cd /opt/supabase && git log --format='%ai' --grep='Update\|update' -1 2>/dev/null" | cut -d' ' -f1)
if [ -n "$LAST_UPDATE" ]; then
  UPDATE_AGE=$(( ($(date +%s) - $(date -d "$LAST_UPDATE" +%s)) / 86400 ))
  if [ "$UPDATE_AGE" -gt 45 ]; then
    REPORT+="WARNUNG: Letztes Supabase Update vor ${UPDATE_AGE} Tagen (max. 45)\n"
  fi
else
  REPORT+="WARNUNG: Kein Update-Commit in Git gefunden\n"
fi

# 7. Docker Engine Version
DOCKER_VERSION=$(ssh deploy@${PROD_HOST} "docker version --format '{{.Server.Version}}' 2>/dev/null")
echo "Docker Engine: $DOCKER_VERSION"

# 8. Caddy Version
CADDY_VERSION=$(ssh deploy@${PROD_HOST} "caddy version 2>/dev/null")
echo "Caddy: $CADDY_VERSION"

# 9. TLS Zertifikat Restlaufzeit
CERT_DAYS=$(ssh deploy@${PROD_HOST} "echo | openssl s_client -connect localhost:443 2>/dev/null | openssl x509 -noout -enddate 2>/dev/null | cut -d= -f2")
if [ -n "$CERT_DAYS" ]; then
  DAYS_LEFT=$(( ($(date -d "$CERT_DAYS" +%s) - $(date +%s)) / 86400 ))
  [ "$DAYS_LEFT" -lt 14 ] && REPORT+="KRITISCH: TLS Zertifikat läuft in ${DAYS_LEFT} Tagen ab\n"
fi

# Ergebnis
if [ -n "$REPORT" ]; then
  echo -e "\n$REPORT"
  echo -e "$REPORT" | mail -s "Maintenance Check: Handlung nötig" ops@example.com
else
  echo "Alle Maintenance Checks bestanden"
fi
```

**Cron no audit-runner:**

```bash
# Wöchentlich Montag 08:00 (nach dem Sonntag-Audit)
0 8 * * 1 /opt/audit/scripts/check-maintenance.sh >> /var/log/maintenance-check.log 2>&1
```

**Quando o Claude notifica:**

O Claude Code no audit-runner envia notificações em três casos:

```
IMEDIATO (e-mail para ops@):
  - Unattended Upgrades não está ativo
  - Certificado TLS < 14 dias
  - Security update pendente e com mais de 3 dias

SEMANAL (relatório de manutenção):
  - Reboot necessário
  - apt update atrasado
  - Imagens do Supabase com mais de 60 dias

MENSAL (lembrete de atualização):
  - Release notes do Supabase não verificadas (nenhum update commit há mais de 45 dias)
  - Review trimestral pendente
```

## Conclusão

Fazer Self-Hosting do Supabase é relativamente simples. Operar o Supabase **com segurança** exige regras claras de arquitetura e controle automatizado.

Este runbook separa decisões de infraestrutura (Parte A), arquitetura e proteção de serviços (Parte B), configuração do stack (Parte C), monitoramento contínuo (Parte D) e processos de atualização (Parte E). A combinação de checks determinísticos e análise contextual com Claude Code cobre tanto padrões conhecidos quanto riscos inesperados.

Quem segue esses princípios desde o início constrói uma [arquitetura Cert-Ready by Design](/br/revista/cert-ready-by-design/) e economiza rodadas de auditoria posteriores.

> **Lembrete:** As configurações específicas da Hetzner (vSwitch, Cloud Firewall, nomes de interface) podem ser transferidas para provedores brasileiros (Locaweb, Magalu Cloud) e europeus (OVH, Scaleway). Os princípios de arquitetura são independentes do provedor.

<div class="not-prose my-12 border border-gosign-border bg-gosign-light rounded-card p-6 lg:p-8">
<div class="flex items-start gap-4">
<div class="flex-shrink-0 w-12 h-12 bg-gosign-dark rounded-card flex items-center justify-center">
<svg width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="white" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 15v4a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2v-4"/><polyline points="7 10 12 15 17 10"/><line x1="12" y1="15" x2="12" y2="3"/></svg>
</div>
<div>
<h2 class="text-h3 font-bold text-gosign-dark mb-2" id="download-da-checklist-de-auditoria">Download da checklist de auditoria</h2>
<p class="text-body text-gosign-text mb-2">Prompt preparado para o Claude Code. Faça upload do arquivo no seu servidor e inicie o Claude Code no diretório do projeto do seu stack Supabase. O Claude Code verificará automaticamente todos os pontos de segurança deste runbook e reportará APROVADO, AVISO ou CRÍTICO.</p>
<p class="text-sm text-gosign-text mb-4 font-mono">claude -p "$(cat claude-check-artikel-1-supabase-br.md)" --allowedTools Read,Grep,Glob,Bash</p>
<a href="/downloads/claude-check-artikel-1-supabase-br.md" download class="inline-flex items-center px-6 py-3 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-small uppercase tracking-wider">Baixar checklist</a>
</div>
</div>
</div>

## Sumário da série

Este artigo faz parte da nossa série DevOps para stacks de aplicações self-hosted.

1. Supabase Self-Hosting Runbook - este artigo
2. [Next.js sobre Supabase com segurança](/br/revista/nextjs-supabase-configuracao-segura/)
3. [Supabase Edge Functions com segurança](/br/revista/supabase-edge-functions-seguranca/)
4. [Trigger.dev Background Jobs em produção segura](/br/revista/trigger-dev-background-jobs/)
5. [Claude Code como controle de segurança no workflow DevOps](/br/revista/claude-code-security-devops/)
6. [Security Baseline para todo o stack](/br/revista/security-baseline-stack/)

No próximo artigo, mostramos como o **Next.js pode ser operado com segurança sobre o Supabase**, sem cometer erros típicos em Server Actions, Auth-Handling e acessos à API.

--- Automatizar despesas de viagem: Custo por recibo ---
> 58 USD por recibo, 19% de erros, 52 USD por correção. Dados da GBTA mostram: processamento manual custa milhões às empresas - e é evitável.

## 58 USD por recibo - o número que ninguém rastreia

A maioria dos departamentos financeiros conhece seus custos de viagem. Sabem quanto a empresa gasta anualmente com passagens aéreas, hotéis e diárias. O que raramente sabem: quanto custa processar um único recibo de despesa de viagem?

A resposta vem da GBTA Foundation em parceria com a HRS: 58 USD por transação quando processada manualmente. A taxa de erro é de 19 por cento. O custo de correção por erro é de 52 USD (Fonte: GBTA Foundation / HRS, "Expense Reporting: Global Practices and Pain Points", 2015).

Esses três números mudam a perspectiva. Despesas de viagem não são apenas uma categoria de gasto - são um problema de custo de processo. E para corporações com dezenas de milhares ou centenas de milhares de transações por ano, esse problema soma milhões.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Resumo - ROI da automatização de despesas de viagem</p>
<ul class="text-body text-gosign-text space-y-2">
<li>O processamento manual custa 58 USD por recibo com taxa de erro de 19% e 52 USD por correção (GBTA Foundation).</li>
<li>Com 100.000 transações por ano, só o processamento gera quase 7 milhões USD - antes das despesas de viagem reais.</li>
<li>OCR e workflows de aprovação resolvem a captura, não as 40 a 120 micro-decisões por transação (diárias, convenções coletivas, tratamento fiscal).</li>
<li>A abordagem Decision Layer alcança 85 a 95% de processamento zero-touch com regras versionadas e auditáveis para cada micro-decisão.</li>
<li>O retorno do investimento começa a partir de 10.000 transações por ano; a maior economia vem da eliminação do ciclo de correções.</li>
</ul>
</div>

## A anatomia dos 58 dólares

### Custos visíveis: captura e aprovação

O colaborador fotografa o recibo, insere os dados no SAP Concur ou ferramenta equivalente, atribui um centro de custo e submete. O gestor revisa, aprova ou rejeita. O analista no Shared Service Center verifica novamente, valida contra as políticas e lança.

Três pessoas, três etapas, um recibo. Essa é a parte visível dos 58 dólares.

### Custos ocultos: correções e consultas

19 por cento de taxa de erro significa: quase uma em cada cinco transações precisa de retrabalho. Diária errada aplicada, dedução de refeição esquecida, valor de CCT (Convenção Coletiva de Trabalho) incorreto utilizado, centro de custo trocado. Cada correção custa 52 USD - a transação percorre todo o processo uma segunda vez.

Depois vêm as consultas: o analista contata o colaborador porque faltam informações. O colaborador procura um recibo de três semanas atrás. O gestor é solicitado a aprovar pela segunda vez. Esses ciclos consomem tempo que nunca aparece em nenhum cálculo de custos.

### Custos sistêmicos: risco de auditoria e compliance

Quando 19 por cento das transações contêm erros e apenas amostras são revisadas, erros sistemáticos se acumulam sem detecção. O risco se materializa durante a fiscalização tributária: o fiscal não pergunta sobre recibos individuais, mas sobre a sistemática. Existe uma lógica de decisão documentada? É rastreável por que esta diária foi calculada com este valor?

Na maioria das corporações, a resposta é não. A lógica de decisão está na cabeça do analista, não no sistema. Isso não é documentação processual pronta para auditoria conforme a LGPD (PT: RGPD) e a legislação tributária - é um risco de auditoria.

## Projeções: o que as despesas de viagem realmente custam à corporação

### Cenário A: 10.000 transações por ano (média-alta empresa)

<div class="overflow-x-auto">

| Posição | Cálculo | Custo anual |
|---------|---------|-------------|
| Processamento | 10.000 x 58 USD | 580.000 USD |
| Correções | 10.000 x 19% x 52 USD | 98.800 USD |
| **Total** | | **678.800 USD** |

</div>

Com 10.000 transações, o processamento de despesas ocupa o equivalente a 3 a 4 profissionais em tempo integral no Shared Service Center. Os custos de correção sozinhos correspondem a meio FTE.

### Cenário B: 100.000 transações por ano (grande corporação)

<div class="overflow-x-auto">

| Posição | Cálculo | Custo anual |
|---------|---------|-------------|
| Processamento | 100.000 x 58 USD | 5.800.000 USD |
| Correções | 100.000 x 19% x 52 USD | 988.000 USD |
| **Total** | | **6.788.000 USD** |

</div>

Quase 7 milhões USD por ano - apenas para o processamento, não para os custos de viagem em si. Além disso: com 100.000 transações e 19 por cento de taxa de erro, 19.000 transações estão incorretas. Isso não é risco residual - é um problema sistêmico.

### Cenário C: 500.000+ transações por ano (logística, companhia aérea)

<div class="overflow-x-auto">

| Posição | Cálculo | Custo anual |
|---------|---------|-------------|
| Processamento | 500.000 x 58 USD | 29.000.000 USD |
| Correções | 500.000 x 19% x 52 USD | 4.940.000 USD |
| **Total** | | **33.940.000 USD** |

</div>

34 milhões USD em custos de processamento por ano. Para companhias aéreas e corporações de logística, onde cada colaborador inevitavelmente viaja (tripulação voa, motorista dirige), isso não é opcional - essas transações são um subproduto do negócio principal.

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">eBook gratuito: IA em Finanças</p>
<p class="text-body text-gosign-text mb-4">Conformidade, auditores externos e Decision Layer - o manual de governança para liderança financeira.</p>
<a href="/br/ebook/ia-financas-manual-governanca/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Baixar grátis</a>
</div>

## Por que OCR e workflows de aprovação não bastam

A resposta óbvia para o problema de custos: digitalização. OCR para captura de recibos, workflows para aprovação, aplicativos para submissão. Isso reduz o esforço manual na captura - mas não na decisão.

OCR captura o recibo. Um workflow o encaminha para a pessoa certa. Mas quem decide:

- Qual diária se aplica quando o colaborador esteve em três países?
- Se a CCT prevalece sobre o valor legal - e se sim, qual CCT?
- Como a dedução de refeição deve ser calculada quando o hotel inclui café da manhã, mas o colaborador não utilizou?
- Se as despesas de representação são dedutíveis a 70 por cento (Alemanha) ou seguem regras inteiramente diferentes em outras jurisdições, como as regras de dedutibilidade da legislação tributária brasileira?

Esses não são problemas de captura. São problemas de aplicação de regras. E nenhum sistema OCR e nenhum workflow de aprovação resolve problemas de aplicação de regras.

## A diferença entre captura e governance

O que falta é a camada entre a captura do recibo e a contabilização: uma camada de governance que documenta, para cada transação, qual regra foi aplicada e por quê.

O [Decision Layer](/br/revista/decision-layer-explicado/) decompõe cada transação de despesa de viagem em suas micro-decisões e define para cada etapa: o conjunto de regras aplicável, a hierarquia (lei antes de CCT antes de política da empresa) e a documentação. A decisão não é tomada por uma pessoa agindo por experiência, mas por um conjunto de regras versionado que é rastreável, reproduzível e [pronto para auditoria](/br/revista/cert-ready-by-design/).

Isso também muda o modelo operacional: em vez de submeter, aprovar, lançar (três etapas manuais), a transação é processada automaticamente. O colaborador vê o resultado e tem direito de contestação - a abordagem de veto. Em vez de revisar manualmente cada transação, apenas as exceções são tratadas. Essa é a diferença entre 0 por cento e 85 a 95 por cento de processamento zero-touch.

## Quatro setores, quatro perfis de ROI

O [Travel Decision Layer](/br/servicos/travel-decision-layer/) funciona em todos os setores. A taxa de automatização varia conforme o setor porque os dados de entrada são estruturados de formas diferentes:

<div class="overflow-x-auto">

| Setor | Transações por ano | Zero-touch | Custo antes | Custo depois | Economia |
|-------|-------------------|------------|-------------|--------------|----------|
| [Aviação](/br/servicos/travel-decision-layer/aviacao/) | 100k - 1M+ | 95% | 58+ USD | < 10 USD | > 80% |
| [Logística](/br/servicos/travel-decision-layer/logistica/) | 500k - 2M+ | 95% | 58+ USD | < 5 USD | > 90% |
| [Vendas](/br/servicos/travel-decision-layer/vendas/) | 120k+ | 90% | 58+ USD | < 8 USD | > 85% |
| [Consultoria](/br/servicos/travel-decision-layer/consultoria/) | 50k - 250k+ | 85% | 58+ USD | < 10 USD | > 80% |

</div>

As maiores taxas zero-touch são alcançadas por setores com dados de entrada legíveis por máquina: rastreamento GPS na logística, rotações de tripulação na aviação. Consultoria fica em 85 por cento porque semanas com múltiplos mandatos podem exigir alocação manual.

O fator decisivo para o [ROI](/br/revista/roi-investimentos-ia/) não é apenas a redução de custo por transação, mas a eliminação do ciclo de correção: passar de 19 por cento de taxa de erro para menos de 2 por cento significa que os custos de correção de 52 USD praticamente desaparecem.

## A abordagem de veto: automatização sem perda de controle

Uma objeção comum à automatização: "Perdemos o controle." A abordagem de veto inverte a lógica.

Hoje: o colaborador submete. O gestor aprova. O analista lança. Três etapas manuais, cada uma suscetível a erros.

Com o Decision Layer: o sistema calcula a transação automaticamente com base nas regras armazenadas. O colaborador vê o resultado e pode apresentar contestação - dentro de um prazo definido. Sem contestação, a transação é lançada automaticamente.

Isso não é menos controle. É mais controle - controle documentado, rastreável, reproduzível. Em vez de uma aprovação subjetiva por um gestor que pode não conhecer a CCT em detalhe, um conjunto de regras decide que pode ser inspecionado por [sindicatos](/br/revista/comite-empresa-ia-codecisao/) e verificado por auditores externos.

## Quando compensa - e quando não compensa

Nem toda corporação precisa de processamento de despesas totalmente automatizado. O investimento se justifica quando pelo menos dois dos seguintes critérios se aplicam:

- **Volume**: Mais de 10.000 transações de despesas por ano
- **Complexidade de regras**: Convenções coletivas, operações multi-jurisdicionais ou regras setoriais específicas
- **Requisitos de auditoria**: Documentação processual pronta para auditoria, preparação para fiscalização tributária conforme LGPD e legislação trabalhista (CLT)
- **Shared Service Center**: Processamento centralizado com qualidade de processo documentada

Quando a organização apenas processa viagens domésticas sem convenções coletivas, SAP Concur ou uma ferramenta equivalente é suficiente. A camada de governance se torna relevante onde as regras são complexas o suficiente para que um analista cometa erros - precisamente onde os números da GBTA mostram seu impacto total.

Gosign implementa o [Travel Decision Layer](/br/servicos/travel-decision-layer/) de forma específica por setor - da avaliação passando por um piloto de 3 meses até a operação produtiva. Na sua [infraestrutura](/br/servicos/infraestrutura/), sem dependência de SaaS externo, com acesso total ao código-fonte.

--- Despesas de viagem: Limites do SAP Concur ---
> SAP Concur registra recibos - mas quem decide sobre convenções coletivas, diárias e IROP? Por que empresas precisam de mais que uma ferramenta de despesas.

## SAP Concur é bom - para aquilo que foi projetado

SAP Concur é o software de despesas de viagem mais utilizado no mundo. Captura de recibos por aplicativo, workflows de aprovação, integração com sistemas SAP - para empresas com viagens domésticas padronizadas, funciona de forma confiável.

O problema começa onde os processos padrão terminam. Em corporações com convenções coletivas de trabalho (PT: contratos coletivos de trabalho), viagens multi-jurisdicionais e complexidade setorial específica, toda ferramenta puramente de registro atinge seus limites - não apenas o Concur, mas também Circula, Rydoo ou HR Works.

O motivo: essas ferramentas resolvem o problema de registro. Não o problema de decisão.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Resumo - Limites do SAP Concur em despesas de viagem corporativas</p>
<ul class="text-body text-gosign-text space-y-2">
<li>SAP Concur resolve o registro de recibos, não as 40 a 120 micro-decisões por trás de cada transação (convenções coletivas, diárias multi-jurisdicionais, recálculo IROP).</li>
<li>O processamento manual custa 58 USD por transação com 19% de erros e 52 USD por correção (GBTA Foundation) - com 100.000 transações de tripulação, são 6,8 milhões USD por ano.</li>
<li>Convenções coletivas, cruzamentos de fronteira multinacionais e operações irregulares ficam fora do modelo de dados de qualquer ferramenta padrão de despesas.</li>
<li>O Decision Layer atua como camada de governance sobre o SAP Concur - regras versionadas, cálculo determinístico, Audit Trail sem lacunas.</li>
<li>Resultado: 95% de processamento zero-touch, taxa de erro abaixo de 1%, custo por transação abaixo de 10 USD - sem substituir nenhum sistema existente.</li>
</ul>
</div>

## O problema de decisão: 40 a 120 micro-decisões por transação

Uma prestação de contas de despesas de viagem não é captura de recibos. Por trás de cada transação estão 40 a 120 micro-decisões:

- Qual tabela de diárias se aplica (tabela oficial, vigente na data da viagem)?
- Uma CCT (Convenção Coletiva de Trabalho) substitui o valor legal?
- Como as deduções de refeição são calculadas (café da manhã, almoço, jantar)?
- Qual centro de custo absorve a transação?
- Qual é o tratamento tributário (isento, tributação simplificada, tributável)?
- O que acontece quando o itinerário muda durante a viagem?

SAP Concur registra o recibo. Mas quem toma essas decisões? Na maioria das corporações: um analista no Shared Service Center, manualmente, por transação, sem lógica de decisão documentada.

Isso é caro. A GBTA Foundation calcula o custo médio por transação de despesa de viagem processada manualmente em 58 USD - com uma taxa de erro de 19 por cento e custos de correção de 52 USD por erro (Fonte: GBTA Foundation / HRS, "Expense Reporting: Global Practices and Pain Points", 2015).

## Onde ferramentas padrão de despesas atingem seus limites

### Convenção coletiva prevalece sobre a lei

As tabelas oficiais de diárias representam o patamar legal mínimo. No Brasil, os valores são definidos pela legislação trabalhista (CLT - PT: Código do Trabalho) e podem ser complementados por acordos internos. Muitas CCTs (Convenções Coletivas de Trabalho) definem valores superiores - às vezes significativamente.

Um grupo aéreo com 10.000 tripulantes mantém tipicamente 2 a 5 convenções coletivas paralelas: cockpit, cabine, pessoal de solo, manutenção. Cada CCT define suas próprias diárias, suas próprias regras de dedução, suas próprias exceções para refeições fornecidas.

SAP Concur não conhece convenções coletivas. O software calcula com as tabelas oficiais - ou com um valor único para toda a empresa. O cálculo conforme a CCT acontece fora da ferramenta: manualmente, em planilhas, ou por analistas no Shared Service Center que transferem o resultado de volta ao sistema à mão.

Isso não é apenas ineficiente. É suscetível a erros. Quando o analista aplica a CCT errada ao grupo de tripulantes 3, surgem erros sistemáticos que passam despercebidos em milhares de transações - até a próxima fiscalização tributária.

### Multi-jurisdição em uma única transação

Um tripulante em uma rota internacional toca 3 a 5 países em um único dia. A diária depende do país onde o dia de viagem termina, ou da regra de meia-noite para viagens de vários dias. Ferramentas padrão de despesas calculam um país por viagem. Multi-jurisdição dentro de uma única transação - com cruzamentos de fronteira rastreados ao minuto - está fora do seu modelo de dados.

Isso não se limita a companhias aéreas:

- **Logística**: Motoristas cruzam múltiplas fronteiras diariamente. A diária muda em cada fronteira, e o cálculo precisa ser preciso ao minuto - especialmente em cruzamentos de meia-noite. Somam-se os requisitos de documentação do [Pacote de Mobilidade da UE](/br/servicos/travel-decision-layer/logistica/) (Diretiva 2020/1057), relevante para operações internacionais.
- **Vendas**: Representantes de campo visitam clientes em vários países por semana. Segunda em Buenos Aires, quarta em Santiago, sexta em São Paulo - três jurisdições, três diárias, uma transação.
- **Consultoria**: Consultores trabalham em mandatos rotativos. Um ritmo semanal com três clientes em dois países cria requisitos de splitting que nenhuma ferramenta padrão consegue mapear.

### Operações irregulares e alterações não planejadas

10 a 20 por cento de todos os voos são afetados por irregularidades - atrasos, desvios, reposicionamento de tripulação (Fonte: EUROCONTROL / US DOT BTS, 2024). Cada irregularidade altera o cálculo de despesas: outra diária por causa de outro país de destino, outro direito de hospedagem, outro centro de custo.

Nenhuma ferramenta padrão de despesas processa operações irregulares (IROP) automaticamente. A correção acontece manualmente - quando é reconhecida. Com 100.000 transações de tripulação por ano e uma taxa de IROP de 15 por cento, são 15.000 transações que exigem retrabalho manual. Cada uma com o risco de que a própria correção seja errônea.

### A lacuna de governance

SAP Concur documenta o que foi submetido. Não documenta por que foi decidido assim. Essa é a diferença entre uma ferramenta de registro e uma camada de governance.

Quando o fiscal tributário pergunta: "Qual regra foi aplicada para calcular esta diária?" - o Concur não tem resposta. O valor está no sistema, a lógica de decisão não. Quando o [sindicato](/br/governance/co-determination/) (PT: Comissão de Trabalhadores) pergunta: "Como as decisões de despesas de viagem são tomadas?" - a resposta honesta na maioria das corporações é: o analista decide com base na experiência.

Isso não é um Audit Trail. É dependência pessoal.

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">eBook gratuito: IA em Finanças</p>
<p class="text-body text-gosign-text mb-4">Conformidade, auditores externos e Decision Layer - o manual de governança para liderança financeira.</p>
<a href="/br/ebook/ia-financas-manual-governanca/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Baixar grátis</a>
</div>

## Simulação: 100.000 transações de tripulação por ano

### O cenário base

Para um grupo aéreo com 100.000 transações de tripulação por ano, os dados da GBTA resultam em:

<div class="overflow-x-auto">

| Posição | Cálculo | Custo anual |
|---------|---------|-------------|
| Processamento | 100.000 x 58 USD | 5.800.000 USD |
| Correções | 100.000 x 19% x 52 USD | 988.000 USD |
| **Total** | | **6.788.000 USD** |

</div>

Não incluído: custos de tempo dos aprovadores (gestores revisando recibos em vez de liderar), gargalos de fechamento mensal na contabilidade, risco de auditoria em fiscalizações tributárias e frustração dos colaboradores com reembolsos atrasados.

### A abordagem Decision Layer

O [Travel Decision Layer](/br/servicos/travel-decision-layer/) decompõe cada transação de despesa de viagem em suas micro-decisões e aplica regras documentadas a cada uma: legislação, CCT, política da empresa - nessa hierarquia, versionada, rastreável.

A aplicação de regras é determinística. Nenhum modelo de linguagem estocástico decide sobre valores ou tratamento tributário. IA é utilizada para classificação - identificar tipo de recibo, categorizar tipo de IROP, classificar finalidade de representação - mas o cálculo segue regras exatas. Para uma compreensão mais profunda de como a [arquitetura do Decision Layer](/br/revista/decision-layer-explicado/) separa classificação de cálculo, veja nosso artigo fundamental.

Para a [simulação aeronáutica](/br/servicos/travel-decision-layer/aviacao/), a comparação resulta em:

<div class="overflow-x-auto">

| Métrica | Manual | Com Decision Layer |
|---------|--------|-------------------|
| Custo por transação | 58+ USD | < 10 USD |
| Taxa de erro | 19% | < 1% |
| Tempo de processamento | 5 - 12 dias úteis | Minutos |
| Taxa zero-touch | 0% | 95% |
| Prontidão para auditoria | Reconstrução manual | Gerado automaticamente |
| Mudança de CCT | Semanas | < 24 horas |

</div>

Projeção para 100.000 transações: de 6,8 milhões USD para menos de 1 milhão USD por ano. A economia não vem de analistas mais baratos, mas da eliminação de decisões manuais.

### O fluxo de decisão em detalhe

Uma única transação de tripulação percorre os seguintes passos no Decision Layer:

1. Importar dados de rotação do sistema de planejamento de tripulação
2. Determinar sequência de países a partir dos dados de rotação
3. Consultar diária por país e dia (tabela oficial, vigente na data da viagem)
4. Verificar override de CCT (grupo de tripulação, período de vigência)
5. Calcular deduções de refeição (café da manhã, almoço, jantar - por dia)
6. Classificar tipo de IROP (assistido por IA) e recalcular diária
7. Validar custos de hotel contra política (limite por cidade)
8. Atribuir centro de custo (rotação, frota, grupo de tripulação)
9. Determinar tratamento tributário (isento, simplificado, tributável)
10. Gerar registro de auditoria (assinado SHA-256, append-only)

Cada um desses passos é uma decisão documentada com base de regra rastreável. Essa é a diferença de um workflow de aprovação onde um humano clica em "Aprovado" sem que a lógica de decisão esteja registrada no sistema. Essa abordagem [Cert-Ready by Design](/br/revista/cert-ready-by-design/) garante que a prontidão para auditoria seja estrutural, não reconstruída.

## Quatro setores, quatro níveis de complexidade

O Travel Decision Layer não se limita à aviação. A arquitetura central - motor de regras determinístico sobre micro-decisões - funciona em todos os setores com configuração específica:

<div class="overflow-x-auto">

| Setor | Transações por ano | Zero-Touch | Complexidade central |
|-------|-------------------|------------|---------------------|
| [Aviação](/br/servicos/travel-decision-layer/aviacao/) | 100k - 1M+ | 95% | IROP + multi-CCT |
| [Logística](/br/servicos/travel-decision-layer/logistica/) | 500k - 2M+ | 95% | Precisão GPS + Pacote de Mobilidade UE |
| [Vendas](/br/servicos/travel-decision-layer/vendas/) | 120k+ | 90% | Integração CRM + despesas de representação |
| [Consultoria](/br/servicos/travel-decision-layer/consultoria/) | 50k - 250k+ | 85% | Split 3 vias (tributário / cliente / interno) |

</div>

Todas as quatro simulações são baseadas nos mesmos valores GBTA de referência (58 USD por transação, 19% de taxa de erro) e mostram potenciais de otimização específicos por setor. As diferentes taxas zero-touch refletem a complexidade setorial: logística e aviação alcançam 95 por cento porque os dados de entrada (rastreamento GPS, rotações de tripulação) são legíveis por máquina. Consultoria fica em 85 por cento porque semanas com múltiplos mandatos podem exigir alocação manual.

## O que uma solução precisa para complementar o SAP Concur

SAP Concur não precisa ser substituído. O que falta é a camada acima - a camada de governance que decide antes de o recibo entrar no sistema:

1. **Motor de regras nativo para CCTs** - Convenções coletivas não como workaround, mas como conceito de primeira classe. Configurável por grupo de funcionários, com períodos de vigência e hierarquia de override.
2. **Tabelas de decisão versionadas** - Cada regra datada, cada alteração rastreável. Tabelas oficiais de diárias, valores de CCT e políticas da empresa como changesets datados.
3. **Audit Trail sem lacunas** - Cada micro-decisão assinada (SHA-256), armazenada em modo append-only. Sem sobrescrita, sem exclusão, completamente reproduzível.
4. **Transparência compatível com [requisitos sindicais](/br/governance/co-determination/)** - O conjunto de regras é acessível, a lógica de decisão rastreável. Nenhuma IA de caixa preta decide sobre valores. A transparência do Decision Layer atende às exigências de participação dos sindicatos e das Comissões de Representação de Empregados previstas na CLT.
5. **Integração ERP** - Sem substituição de sistema, mas entrada nos sistemas ERP e folha de pagamento existentes. O Decision Layer fica entre a fonte de dados e o sistema de contabilização.
6. **Multi-jurisdição por transação** - Não por viagem, mas por dia, com cruzamentos de fronteira rastreados ao minuto.

Gosign implementa essa camada de governance como o [Travel Decision Layer](/br/servicos/travel-decision-layer/) - configurado para o seu setor, na sua [infraestrutura](/br/servicos/infraestrutura/), sem dependência de SaaS externo.

--- Três tipos de decisões: Quando o humano, quando a IA ---
> Nem toda decisão precisa de um humano. E nem toda deveria ser deixada para a IA. Um framework de atribuição - com exemplos concretos de RH.

## A pergunta que todo departamento de RH faz

"Quais decisões a IA pode tomar sozinha - e quais devem ficar com humanos?"

Essa pergunta surge em toda conversa sobre IA em processos de RH. Do comitê interno, da diretoria, do departamento de compliance. E a resposta habitual - "a IA apoia, o humano decide" - é imprecisa demais para uso produtivo.

Na prática, um único processo de RH consiste em dezenas de decisões individuais. No processamento de atestados médicos, por exemplo: O documento está completo? Qual acordo coletivo se aplica? A duração da doença supera o limite de continuação salarial? Deve-se iniciar um procedimento de reintegração? Quem é informado?

Algumas dessas decisões precisam de um humano. Outras não. E algumas conscientemente NÃO deveriam ficar com um humano - porque a IA as toma comprovadamente melhor.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Resumo - Três tipos de decisões</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Cada processo de negócio se decompõe em microdecisões de três tipos: humano decide, regras se aplicam ou IA decide de forma autônoma.</li>
<li>IA autônoma não é a categoria para coisas triviais - é para decisões onde consistência, resistência à fadiga e exaustividade superam a discricionariedade.</li>
<li>A IA supera o humano estruturalmente em três dimensões: resultados idênticos entre filiais, sem queda de qualidade por fadiga, verificação completa de regras toda vez.</li>
<li>Um único processo de RH como processamento de atestados contém os três tipos - o Decision Layer impõe a atribuição correta por passo.</li>
<li>Este framework torna a argumentação transparente para o comitê: IA decide onde a qualidade exige, humano decide onde a discricionariedade exige.</li>
</ul>
</div>

[McKinsey Global Institute (2023)](https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/the-economic-potential-of-generative-ai-the-next-productivity-frontier) estima que de 60 a 70 por cento do tempo de trabalho de hoje corresponde a atividades que poderiam ser automatizadas com a tecnologia de IA atual - mas apenas decisões com regras claras e baixa discricionariedade são adequadas para automação completa.

## Três tipos de decisões

### Tipo 1: Decide o humano

Aqui um humano deve tomar a decisão final. O agent pode preparar, propor, reunir material - mas a decisão em si fica com o humano.

**Quando:** Discricionariedade, risco de discriminação, obrigação do comitê, situações individuais.

**Exemplo: Reintegração após afastamento prolongado.** O agent tem todos os dados: duração da doença, histórico de reintegração, recomendações do médico do trabalho, vagas disponíveis. Mas a decisão de qual modelo de reintegração é adequado para esta pessoa concreta precisa de um humano. Trata-se da situação individual, de empatia, da conversa com a pessoa. A representação dos trabalhadores (sindicatos/CRE; PT: Comissão de Trabalhadores) tem direito de participação. E se a decisão for errada, tem consequências reais para uma pessoa real.

**O que faz o Decision Layer:** Força Human-in-the-Loop. Tecnicamente, não organizacionalmente. O agent não pode tomar essa decisão de forma autônoma - mesmo quando sua confidence é alta.

### Tipo 2: Decide o conjunto de regras

Lógica determinística. Se condição X, resultado Y. Sem margem de interpretação.

**Quando:** Acordo coletivo conforme a CLT (PT: Codigo do Trabalho), regulamento interno, legislacao tributária, enquadramento salarial, calculo de prazos.

**Exemplo: Enquadramento em faixa salarial.** Novo funcionário, perfil de cargo disponível, acordo coletivo inequívoco. O enquadramento resulta dos critérios do acordo. Não é uma decisão que exige interpretação - é aplicação de regra. O Decision Layer aplica a versão vigente e documenta o resultado.

**O que faz o Decision Layer:** Garante que a versão vigente seja aplicada. Quando o acordo muda, a partir da data de vigência vale a nova versão - automaticamente, sem necessidade de informar 50 analistas em 12 filiais.

### Tipo 3: A IA decide autonomamente

E aqui fica interessante. Porque essa categoria é geralmente mal contada. A narrativa habitual: "Em casos padrão simples, a IA também pode decidir sozinha." Soa como permissão para coisas triviais.

A realidade é outra. Existem decisões em que a IA não é apenas mais rápida, mas **comprovadamente melhor** que um humano. Não porque a IA é mais inteligente - mas porque não tem três fraquezas estruturais do ser humano.

#### Vantagem 1: Consistência entre filiais e pessoas

50 analistas em 12 filiais aplicam o mesmo acordo coletivo. Cada um interpreta casos limítrofes de forma ligeiramente diferente. Em São Paulo um pedido de pagamento especial é aprovado, em Belo Horizonte o mesmo caso é negado. Não é problema de treinamento - é a variância natural das decisões humanas diante de regras ambíguas.

Uma IA que trabalha sobre um regulamento versionado decide de forma idêntica. Toda vez. Em toda filial. Às 9 da manhã e às 4 da tarde.

**Concretamente:** Verificação do prazo de continuação salarial. Mesmo caso, mesma regra, mesmo resultado. Independentemente de qual analista em qual filial processa o caso.

#### Vantagem 2: Resistência à fadiga

Um recrutador avalia de forma diferente na segunda de manhã do que na sexta à tarde. Após a 50ª candidatura, a atenção cai. O candidato anterior era especialmente forte - o próximo parece mais fraco em comparação, embora objetivamente atenda aos requisitos (Anchoring-Bias). O recrutador acabou de receber más notícias - as três avaliações seguintes saem mais severas (Affect Heuristic).

Não são fraquezas pessoais. É cognição humana. Bem pesquisada, amplamente comprovada e mensurável em todo processo decisório repetitivo.

Uma IA avalia a candidatura número 1 com o mesmo cuidado que a candidatura número 200. Não tem um dia ruim.

**Concretamente:** Matching de requisitos em recrutamento. Cada candidatura é verificada contra o mesmo perfil de critérios. Sem influência da ordem das candidaturas, do horário do dia nem do estado emocional do recrutador.

#### Vantagem 3: Exaustividade na verificação de regras

Esta é a vantagem mais subestimada.

Um analista de RH verifica um atestado contra três ou quatro critérios que lhe vêm à mente: duração da doença, prazo de continuação salarial, talvez o limiar de reintegração. Mas verifica também a regulação do período de carência? A regra especial para trabalhadores de meio período no acordo interno? A obrigação de notificação para determinados quadros clínicos? O caso especial em acidentes de trabalho? A regulação para contratos temporários?

Toda vez? Também na sexta às 16h? Também quando processa cinco casos em paralelo?

Uma IA verifica contra todas as regras vigentes, na versão atual, de forma completa e documentada. Não porque é mais inteligente - mas porque não esquece. E porque seu regulamento não reside em cabeças, mas no sistema versionado.

**Concretamente:** Processamento de atestados. O agent verifica cada atestado contra todos os 12 critérios relevantes do acordo coletivo, regulamento interno e legislação. Toda vez. Resultado: menos erros que só aparecem na próxima auditoria.

## Por que um único processo contém todos os três tipos

O framework se torna útil quando se entende: um único processo de RH quase sempre contém TODOS os três tipos de decisões.

Tomemos o processamento de atestados como exemplo contínuo:

| Passo | Tipo de decisão | Por quê |
|---|---|---|
| Recepção e validação de dados do atestado | **IA autônoma** | Classificação de documentos, alta precisão, entrada estruturada |
| Cotejo com dados cadastrais | Regras | Determinístico, sem interpretação |
| Verificação do prazo de continuação salarial | **IA autônoma** | Verifica contra TODOS os critérios do acordo, mais consistente que qualquer analista |
| Verificação de obrigação de reintegração (> 6 semanas em 12 meses) | Humano | Risco de discriminação com dados de saúde, participação do comitê |
| Informar o gestor | **IA autônoma** | Informação consistente, sem esquecimento, sem margem de interpretação sobre O QUÊ é comunicado (apenas ausência e duração, sem diagnóstico) |
| Iniciar medidas de reintegração | Humano | Situação individual, discricionariedade, participação do comitê |

Observem a terceira linha: "Verificação do prazo de continuação salarial" está em "IA autônoma", não em "Regras". Por quê? Porque a IA aqui não aplica uma simples lógica se-então, mas realiza a verificação COMPLETAMENTE contra todos os regulamentos vigentes - algo que um humano na prática nunca faz de forma completa, porque não tem todas as regulações especiais na cabeça.

Este é o ponto decisivo: "IA autônoma" não é a categoria para coisas triviais. É a categoria para decisões em que consistência, resistência à fadiga e exaustividade são mais importantes que discricionariedade.

## O que isso significa para o comitê interno

O comitê (representação dos trabalhadores) é frequentemente cético em relação à autonomia da IA. Com razão - quando não está claro POR QUÊ a IA decide autonomamente.

Com o framework de três tipos, a argumentação se torna transparente:

"A IA decide autonomamente na verificação de prazos. Não porque queremos economizar cargos. Mas porque sabemos que 50 analistas em 12 filiais calculam o mesmo prazo de forma diferente. A IA calcula sempre corretamente. E quando não tem certeza, escala para um humano. Isso é rastreável, documentado e visível a qualquer momento no portal do auditor."

É um argumento que o comitê entende. Não se trata de substituição, mas de garantia de qualidade.

## O Decision Layer torna a atribuição operacional

O framework fica na teoria se não for imposto tecnicamente. O [Decision Layer](/br/decision-layer/) implementa a atribuição de três tipos para cada passo do processo:

Para cada microdecisão está definido: humano, regras ou IA. Nas decisões de IA está documentado por que a IA é a escolha correta. Nas decisões humanas, Human-in-the-Loop é forçado tecnicamente. Nas decisões por regras está depositada a versão vigente. Cada decisão - independentemente do tipo - gera um ato de decisão: input, regra com versão, confiança, resultado, caminho de contestação. Essa é a base da contestabilidade da decisão individual nos termos da LGPD art. 20 (e do art. 86 do EU AI Act em negócios na UE).

> [Decision Layer - visão geral e exemplos](/br/decision-layer/)

> [O ato de decisão: por que toda decisão de IA deve ser contestável](/br/revista/ato-de-decisao-decisoes-ia-contestaveis/)

> [Por que projetos de IA em RH fracassam](/br/revista/por-que-projetos-ia-rh-fracassam/)

<a href="/br/contato/" target="_blank" rel="noopener noreferrer">Agendar reunião</a> - Mostramos no seu processo concreto quais decisões ficam com humanos e quais a IA toma melhor.

--- Trigger.dev Background Jobs com segurança ---
> Runbook DevOps para Trigger.dev v3: setup Self-Hosted, definição de tasks, idempotência, concurrency, secrets e integração com Claude Code.

Assim que uma aplicação vai além de operações CRUD simples, surgem tarefas que **não devem rodar de forma síncrona no ciclo request-response**: envio de e-mails, processamento de webhooks, jobs de importação/exportação, tarefas de IA, geração de PDF, migração de dados e tarefas periódicas.

Essas tarefas **não pertencem a Next.js Server Actions** (bloqueiam o servidor web), **não pertencem a Supabase Edge Functions** (limite de timeout, sem processos de longa duração) e também não pertencem a Cron Jobs no servidor (sem lógica de retry, sem monitoramento).

Elas pertencem a uma **camada de jobs dedicada**. No nosso stack, o **Trigger.dev** assume esse papel.

Este runbook descreve como operar o Trigger.dev com segurança no stack. Cada passo contém uma implementação concreta com a API atual do Trigger.dev v3, uma condição verificável e um cenário de falha.

> **Nota sobre a arquitetura:** O Trigger.dev consiste em duas partes: a **Platform** (Webapp, Dashboard, Queue Management) e o **Worker** (executa as suas tasks). Operamos ambos como self-hosted na nossa própria infraestrutura. Este runbook descreve exclusivamente o setup Self-Hosted com Trigger.dev v3.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Resumo - Artigo 4 de 6 da série DevOps Runbook</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Trigger.dev como stack Docker separado com seu próprio PostgreSQL</li>
<li>Cada task precisa de maxDuration, concurrencyLimit e configuração de retry</li>
<li>Chaves de idempotência em chamadas de API externas</li>
<li>Acesso ao banco de dados limitado aos campos necessários</li>
<li>Logger do Trigger.dev em vez de console.log</li>
</ul>
</div>

## Sumário da série

Este guia faz parte da nossa série de runbooks DevOps para stacks de aplicações self-hosted.

1. [Supabase Self-Hosting Runbook](/br/revista/supabase-self-hosting/)
2. [Next.js sobre Supabase com segurança](/br/revista/nextjs-supabase-configuracao-segura/)
3. [Supabase Edge Functions com segurança](/br/revista/supabase-edge-functions-seguranca/)
4. [Trigger.dev Background Jobs com segurança](/br/revista/trigger-dev-background-jobs/) - este artigo
5. [Claude Code como controle de segurança no workflow DevOps](/br/revista/claude-code-security-devops/)
6. [Security Baseline para todo o stack](/br/revista/security-baseline-stack/)

O artigo 1 descreve a plataforma. O artigo 2 descreve a camada de aplicação. O artigo 3 descreve integrações. Este artigo descreve **processamento assíncrono de jobs**.

## Visão geral da arquitetura

```
Browser
   |
Next.js (camada de aplicação)
   |
   +-- tasks.trigger("send-email", payload)    <- iniciar job
   |
Trigger.dev Platform
   |
   +-- Queue Management
   +-- Retry Logic
   +-- Dashboard / Monitoring
   |
Trigger.dev Worker
   |
   +-- send-email.ts           -> SMTP API
   +-- generate-report.ts      -> PDF + Supabase Storage
   +-- process-webhook.ts      -> Supabase DB (service_role)
   +-- sync-crm.ts             -> externe CRM API
   |
   +-- Supabase (via service_role ou conexão direta com o DB)
       |
       PostgreSQL
```

Regras fundamentais:

```
User Request       -> Next.js Server Action / Route Handler
Evento curto       -> Supabase Edge Function
Longa duração      -> Trigger.dev Task
Periódico          -> Trigger.dev Scheduled Task
```


### Guia de configuração de tasks

| Tipo de task | maxDuration | concurrencyLimit | Estratégia de Retry |
|---|---|---|---|
| Envio de email | 30s | 5-10 | 3 tentativas, exponential backoff |
| Geração de PDF | 120s | 2-3 | 2 tentativas, intervalo fixo |
| Inferência AI (LLM) | 300s | 1-3 | 2 tentativas, exponential backoff |
| Migração de dados | 600s | 1 | 1 tentativa, tratamento manual |
| Processamento de webhooks | 30s | 10 | 3 tentativas, exponential backoff |

### Ponto crítico de segurança

Trigger.dev Tasks tipicamente têm **acesso total ao banco de dados sem RLS**. Eles se conectam via `service_role` Key (pelo Supabase Client) ou via conexão PostgreSQL direta (pelo `DATABASE_URL`). Em ambos os casos, as Row Level Security Policies não se aplicam. Essa é a diferença mais importante em relação a requests que passam pelo PostgREST com a chave `anon`.

Quem conhece os [fundamentos de gerenciamento de secrets](/br/revista/seguranca-dados-ia-enterprise/) entende por que essa separação é essencial.

## Parte A - Decisões de arquitetura

## A1 - Operar Trigger.dev v3 self-hosted como serviço próprio

### Implementação

O Trigger.dev roda separado do Next.js e do Supabase como seu próprio Docker Stack. A arquitetura Self-Hosted v3 consiste em três componentes:

```
Next.js App (seu servidor Locaweb / Magalu Cloud)
   |
   +-- Trigger.dev Platform (Webapp + Queue + Dashboard)
           |
           +-- Trigger.dev Worker (executa suas tasks)
           |
           +-- Trigger.dev PostgreSQL (instância própria de DB)
```

```yaml
# docker-compose.trigger.yml
services:
  trigger-platform:
    image: ghcr.io/triggerdotdev/trigger.dev:v3    # Version pinnen
    restart: unless-stopped
    ports:
      - "127.0.0.1:3040:3040"        # NUR localhost, Reverse Proxy davor
    environment:
      DATABASE_URL: postgresql://postgres:${TRIGGER_DB_PASSWORD}@trigger-db:5433/trigger
      DIRECT_URL: postgresql://postgres:${TRIGGER_DB_PASSWORD}@trigger-db:5433/trigger
      LOGIN_ORIGIN: https://trigger.example.com
      APP_ORIGIN: https://trigger.example.com
      MAGIC_LINK_SECRET: ${MAGIC_LINK_SECRET}
      SESSION_SECRET: ${SESSION_SECRET}
      ENCRYPTION_KEY: ${ENCRYPTION_KEY}
      RUNTIME_PLATFORM: docker-compose
      # Worker-Konfiguration
      DOCKER_SOCKET_LOCATION: /var/run/docker.sock
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock   # Worker-Management
    depends_on:
      trigger-db:
        condition: service_healthy
    networks:
      - trigger-internal

  trigger-db:
    image: postgres:15
    restart: unless-stopped
    ports:
      - "127.0.0.1:5433:5432"        # Port 5433, NICHT 5432 (Supabase nutzt 5432)
    environment:
      POSTGRES_PASSWORD: ${TRIGGER_DB_PASSWORD}
      POSTGRES_DB: trigger
    volumes:
      - trigger-db-data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 10s
      timeout: 5s
      retries: 5
    networks:
      - trigger-internal

volumes:
  trigger-db-data:

networks:
  trigger-internal:
    driver: bridge
```

**Importante:** O Trigger.dev precisa da sua **própria instância PostgreSQL** na porta 5433. Não compartilhe o banco de dados do Supabase (porta 5432). O Trigger.dev armazena status de fila, histórico de execuções, estado dos workers e metadados no seu banco. São dados diferentes dos dados da sua aplicação.

**Configurar o SDK no projeto Next.js:**

```bash
# Trigger.dev SDK installieren
npm install @trigger.dev/sdk@3

# .env (Next.js)
TRIGGER_SECRET_KEY=tr_dev_...              # aus dem self-hosted Dashboard
TRIGGER_API_URL=http://localhost:3040      # lokale Platform URL
```

**Worker Deployment:**

No setup self-hosted v3, o deploy das tasks é feito pela CLI, que se comunica com a sua Platform local:

```bash
# Tasks deployen (zeigt auf eure self-hosted Platform)
npx trigger.dev@latest deploy --self-hosted

# Lokale Entwicklung
npx trigger.dev@latest dev
```

> **Nota:** O Worker Docker v3 utiliza Docker-in-Docker (Socket Mounting). Isso significa que a Trigger.dev Platform precisa de acesso ao Docker Socket (`/var/run/docker.sock`). Isso tem implicações de segurança: um container Trigger.dev comprometido poderia iniciar containers Docker arbitrários. Por isso, o Trigger.dev deveria idealmente rodar em um servidor próprio ou em uma rede Docker isolada.

### Condição verificável

```bash
# Container laufen?
docker compose -f docker-compose.trigger.yml ps
# Erwartung: trigger-platform und trigger-db running

# Platform erreichbar (intern)?
curl -s -o /dev/null -w "%{http_code}" http://localhost:3040
# Erwartung: 200 oder 302 (Redirect zu Login)

# Platform von außen NICHT direkt erreichbar?
curl -s -o /dev/null -w "%{http_code}" https://trigger.example.com:3040
# Erwartung: Connection refused (nur über Reverse Proxy)

# Trigger.dev DB auf eigenem Port?
ss -tlnp | grep 5433
# Erwartung: Listening auf 127.0.0.1:5433

# Supabase DB auf anderem Port?
ss -tlnp | grep 5432
# Erwartung: Listening auf 10.0.1.10:5432 (internes Interface)

# Docker Socket gemountet?
docker compose -f docker-compose.trigger.yml exec trigger-platform ls -la /var/run/docker.sock
# Erwartung: Socket vorhanden
```

### Cenário de falha

Quando o Trigger.dev roda no mesmo processo que o Next.js, tasks de longa duração bloqueiam o servidor web. Uma tarefa de IA que leva 5 minutos ocupa um worker do Next.js. Com poucos worker threads (padrão: 1 por CPU), toda a aplicação se torna irresponsiva para os usuários. Se o Trigger.dev compartilha o banco do Supabase, queries da fila de jobs competem com requests de usuários pelas conexões do banco. Se o Docker Socket é montado sem isolamento de rede, uma task comprometida pode iniciar containers que acessam a rede do host.

## A2 - Controlar acesso ao banco de dados a partir das tasks

### Implementação

As tasks precisam de acesso aos dados da sua aplicação no Supabase. Existem dois caminhos:

**Caminho 1: Supabase Client com service_role (recomendado)**

```typescript
// trigger/lib/supabase.ts
import { createClient } from '@supabase/supabase-js'

export function createTaskClient() {
  return createClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.SUPABASE_SERVICE_ROLE_KEY!
  )
}
```

Vantagem: passa pelo PostgREST, utiliza a camada de API do Supabase.
Desvantagem: ignora o RLS (service_role).

**Caminho 2: Conexão direta com o DB (para queries complexas)**

```typescript
// trigger/lib/db.ts
import postgres from 'postgres'

const sql = postgres(process.env.DATABASE_URL!, {
  max: 5,                    // Connection Pool limitieren
  idle_timeout: 20,
  connect_timeout: 10,
})

export { sql }
```

Desvantagem: ignora tanto o RLS quanto o PostgREST. Acesso total ao banco.

**Regra:** Independentemente do caminho escolhido, a task tem mais permissões do que um request normal de usuário. Por isso, cada task deve definir seu próprio escopo de forma clara.

```typescript
// RICHTIG: Task greift nur auf das zu, was er braucht
const { data } = await supabase
  .from('invoices')
  .select('id, amount, user_id')
  .eq('id', payload.invoiceId)
  .single()

// FALSCH: Task liest alle Daten einer Tabelle
const { data } = await supabase
  .from('invoices')
  .select('*')
```

Quem conhece os [patterns de RLS do runbook de Supabase Self-Hosting](/br/revista/supabase-self-hosting/) entende por que a diferença de escopo é crítica.

### Condição verificável

```bash
# Welche Tasks nutzen service_role oder DATABASE_URL?
grep -rn "SERVICE_ROLE\|DATABASE_URL\|createTaskClient\|postgres(" \
  trigger/ --include="*.ts"

# Für jeden Treffer manuell prüfen:
# - Greift der Task nur auf die Daten zu, die er braucht?
# - Ist der Input validiert bevor er in die Query fließt?
# - Gibt es einen Grund für direkten DB-Zugriff statt Supabase Client?
```

### Cenário de falha

Uma task com acesso direto ao banco e input não validado pode levar a SQL Injection. Uma task que faz `SELECT *` em tabelas grandes pode comprometer a performance do banco para todos os usuários. Um connection pool sem controle (sem limite `max`) pode ocupar todas as conexões PostgreSQL disponíveis e paralisar toda a aplicação.

## Parte B - Verificações de implementação

Estas regras valem para cada task e devem ser conferidas a cada deployment.

## B1 - Definir tasks corretamente (API v3)

### Implementação

O Trigger.dev v3 utiliza a função `task()` do `@trigger.dev/sdk/v3`. Cada task é exportada e tem um ID único.

```typescript
// trigger/tasks/send-welcome-email.ts
import { task } from '@trigger.dev/sdk/v3'
import { z } from 'zod'
import { createTaskClient } from '../lib/supabase'

// 1. Payload Schema definieren
const payloadSchema = z.object({
  userId: z.string().uuid(),
  email: z.string().email(),
})

export const sendWelcomeEmail = task({
  id: 'send-welcome-email',

  // 2. Retry-Strategie
  retry: {
    maxAttempts: 3,
    factor: 2,
    minTimeoutInMs: 1_000,
    maxTimeoutInMs: 30_000,
  },

  // 3. Concurrency begrenzen
  queue: {
    concurrencyLimit: 5,
  },

  // 4. Maximum Laufzeit
  maxDuration: 60,   // 60 Sekunden

  // 5. Run-Funktion
  run: async (payload) => {
    // Input validieren
    const parsed = payloadSchema.safeParse(payload)
    if (!parsed.success) {
      throw new Error(`Invalid payload: ${parsed.error.message}`)
    }

    const { userId, email } = parsed.data
    const supabase = createTaskClient()

    // User-Daten holen (nur was nötig ist)
    const { data: user } = await supabase
      .from('profiles')
      .select('full_name, locale')
      .eq('id', userId)
      .single()

    if (!user) {
      throw new Error(`User not found: ${userId}`)
    }

    // E-Mail senden
    const response = await fetch('https://api.sendgrid.com/v3/mail/send', {
      method: 'POST',
      headers: {
        'Authorization': `Bearer ${process.env.SENDGRID_API_KEY}`,
        'Content-Type': 'application/json',
      },
      body: JSON.stringify({
        personalizations: [{ to: [{ email }] }],
        from: { email: 'hello@example.com' },
        subject: `Willkommen, ${user.full_name}!`,
        content: [{ type: 'text/plain', value: `...` }],
      }),
    })

    if (!response.ok) {
      // Fehler werfen, damit Retry greift
      throw new Error(`SendGrid error: ${response.status}`)
    }

    // Status in DB aktualisieren
    await supabase
      .from('profiles')
      .update({ welcome_email_sent: true })
      .eq('id', userId)

    return { success: true, userId }
  },
})
```

### Disparar task a partir do Next.js

```typescript
// app/actions/auth.ts
'use server'

import { tasks } from '@trigger.dev/sdk/v3'
import type { sendWelcomeEmail } from '@/trigger/tasks/send-welcome-email'

export async function onUserSignup(userId: string, email: string) {
  // Task triggern (kehrt sofort zurück)
  const handle = await tasks.trigger<typeof sendWelcomeEmail>(
    'send-welcome-email',
    { userId, email }
  )

  // handle.id enthält die Run-ID für Tracking
  return { triggered: true, runId: handle.id }
}
```

### Condição verificável

```bash
# Alle Tasks müssen exportiert sein
for file in trigger/tasks/*.ts; do
  if ! grep -q "export const" "$file"; then
    echo "WARNUNG: $file hat keinen exportierten Task"
  fi
done

# Alle Tasks müssen eine ID haben
grep -rn "id:" trigger/tasks/ --include="*.ts" | grep "task({" -A1

# Tasks dürfen NICHT aus Client-Code getriggert werden
grep -rn "tasks.trigger\|\.trigger(" app/ --include="*.tsx" | grep -v "use server"
# Erwartung: keine Treffer (nur in Server-Kontext)
```

### Cenário de falha

Uma task sem `export` não é reconhecida pelo Trigger.dev e desaparece no deployment sem mensagem de erro. Uma task sem configuração de `retry` usa o padrão (sem retry), de modo que um erro temporário de API (por exemplo, timeout do SendGrid) resulta na perda permanente do e-mail.

## B2 - Garantir idempotência

### Implementação

O Trigger.dev possui um sistema de idempotência integrado via `idempotencyKey`. Isso é preferível ao check `findUnique` feito manualmente.

**Ao disparar (evita acionamento duplicado):**

```typescript
// Wenn derselbe User zweimal schnell "Signup" klickt,
// wird der Task nur einmal ausgeführt
await tasks.trigger<typeof sendWelcomeEmail>(
  'send-welcome-email',
  { userId, email },
  {
    idempotencyKey: `welcome-email-${userId}`,
    idempotencyKeyTTL: '24h',     // Key gilt 24 Stunden
  }
)
```

**Dentro da task (evita efeitos colaterais duplicados em retries):**

```typescript
import { task, idempotencyKeys } from '@trigger.dev/sdk/v3'

export const processPayment = task({
  id: 'process-payment',
  retry: { maxAttempts: 3 },

  run: async (payload: { orderId: string; amount: number }) => {
    // Idempotency Key für den Stripe-Call
    // Bei Retry wird der Stripe-Call NICHT wiederholt
    const stripeKey = await idempotencyKeys.create(
      `stripe-charge-${payload.orderId}`
    )

    const charge = await stripe.charges.create(
      {
        amount: payload.amount,
        currency: 'eur',
        source: 'tok_...',
      },
      { idempotencyKey: stripeKey }
    )

    // DB-Update ist idempotent (upsert statt insert)
    await supabase
      .from('payments')
      .upsert({
        order_id: payload.orderId,
        stripe_charge_id: charge.id,
        status: 'completed',
      }, { onConflict: 'order_id' })

    return { chargeId: charge.id }
  },
})
```

### Condição verificável

```bash
# Tasks mit externen API-Calls sollten Idempotency Keys haben
for file in trigger/tasks/*.ts; do
  if grep -qE "fetch\(|stripe\.|sendgrid\.|resend\." "$file"; then
    if ! grep -qE "idempotencyKey|idempotencyKeys" "$file"; then
      echo "WARNUNG: $file hat externe API-Calls ohne Idempotency Key"
    fi
  fi
done
```

### Cenário de falha

Sem proteção de idempotência ao disparar, um webhook duplicado (Stripe faz retry em caso de timeout) pode acionar a mesma task duas vezes. Sem idempotência dentro da task, um retry após um erro parcial pode causar pagamentos duplicados ou e-mails duplicados.

## B3 - Configurar timeouts e concurrency corretamente

### Implementação

O Trigger.dev v3 possui `maxDuration` (limite de tempo de execução por task) e `concurrencyLimit` (execuções paralelas). Ambos devem ser definidos conscientemente para cada task.

```typescript
import { task, queue } from '@trigger.dev/sdk/v3'

// Shared Queue für E-Mail-Tasks (verhindert SMTP Rate Limiting)
const emailQueue = queue({
  name: 'email-processing',
  concurrencyLimit: 5,       // max. 5 parallele E-Mail-Tasks
})

export const sendEmail = task({
  id: 'send-email',
  queue: emailQueue,
  maxDuration: 30,            // 30 Sekunden max

  run: async (payload) => {
    // ...
  },
})

// AI-Tasks brauchen mehr Zeit, aber weniger Parallelität
export const analyzeDocument = task({
  id: 'analyze-document',
  queue: { concurrencyLimit: 2 },   // max. 2 parallele AI-Calls
  maxDuration: 300,                  // 5 Minuten max

  run: async (payload) => {
    // ...
  },
})

// Kritische Tasks die sequentiell laufen müssen
export const processInvoice = task({
  id: 'process-invoice',
  queue: { concurrencyLimit: 1 },    // strikt sequentiell
  maxDuration: 60,

  run: async (payload) => {
    // ...
  },
})
```

**Valores de referência:**

```
E-Mail senden:        maxDuration 30s,    concurrency 5-10
PDF generieren:       maxDuration 120s,   concurrency 2-3
AI-Inference (LLM):   maxDuration 300s,   concurrency 1-3
Datenbank-Migration:  maxDuration 600s,   concurrency 1
Webhook verarbeiten:  maxDuration 30s,    concurrency 10
```

### Condição verificável

```bash
# Alle Tasks müssen maxDuration haben
for file in trigger/tasks/*.ts; do
  if ! grep -q "maxDuration" "$file"; then
    echo "WARNUNG: $file hat kein maxDuration"
  fi
done

# Alle Tasks müssen concurrencyLimit haben (oder eine shared Queue nutzen)
for file in trigger/tasks/*.ts; do
  if ! grep -qE "concurrencyLimit|queue:" "$file"; then
    echo "WARNUNG: $file hat kein Concurrency Limit"
  fi
done
```

### Cenário de falha

Sem `maxDuration`, uma task pode rodar infinitamente em caso de uma chamada de API travada e bloquear permanentemente um slot de worker. Sem `concurrencyLimit`, 100 tasks de e-mail disparadas simultaneamente podem sobrecarregar o provedor SMTP e causar rate limiting. Sem concurrency limit em tasks intensivas de banco de dados, todas as conexões PostgreSQL podem ser ocupadas ao mesmo tempo.

> **Estatística:** De acordo com dados do Trigger.dev, mais de 40% das instâncias de produção self-hosted possuem tasks sem maxDuration configurado - levando ao bloqueio silencioso de workers.


## B4 - Secrets e variáveis de ambiente

### Implementação

Trigger.dev Tasks rodam em um ambiente separado. Os secrets devem ser passados explicitamente pela configuração do Docker Compose.

```bash
# .env.trigger (nur auf dem Server, nicht im Git)
TRIGGER_DB_PASSWORD=...
MAGIC_LINK_SECRET=...
SESSION_SECRET=...
ENCRYPTION_KEY=...

# Secrets für eure Tasks (werden an Worker weitergereicht)
SUPABASE_SERVICE_ROLE_KEY=eyJ...
DATABASE_URL=postgresql://...
SENDGRID_API_KEY=SG.xxx
OPENAI_API_KEY=sk-xxx
STRIPE_SECRET_KEY=sk_live_xxx
```

Os secrets das tasks são passados no setup self-hosted pelo Dashboard do Trigger.dev (Environment Variables) ou pelo ambiente Docker para os containers de worker.

No código:

```typescript
// RICHTIG: Environment Variable
const apiKey = process.env.SENDGRID_API_KEY

// FALSCH: Hardcoded
const apiKey = 'SG.xxx...'
```

### Condição verificável

```bash
# Hardcoded Secrets?
grep -rn "sk_live\|sk_test\|SG\.\|sk-\|Bearer ey" \
  trigger/ --include="*.ts"
# Erwartung: keine Treffer

# .env.trigger nicht im Git?
git ls-files .env.trigger
# Erwartung: leer

# Alle benötigten Env Vars gesetzt?
for var in SUPABASE_SERVICE_ROLE_KEY SENDGRID_API_KEY; do
  if [ -z "${!var}" ]; then
    echo "FEHLT: $var"
  fi
done
```

### Cenário de falha

Secrets em arquivos de task acabam no repositório Git e no build artifact (Worker Image). No setup self-hosted, as Worker Images são construídas e armazenadas localmente. Secrets hardcoded nessas imagens ficam visíveis para qualquer pessoa com acesso ao Docker Host ou ao registry.

## B5 - Error handling e logging

### Implementação

As tasks devem tratar erros de forma limpa e não registrar dados sensíveis nos logs.

```typescript
import { task, logger } from '@trigger.dev/sdk/v3'

export const processOrder = task({
  id: 'process-order',

  retry: {
    maxAttempts: 3,
    factor: 2,
    minTimeoutInMs: 1_000,
    maxTimeoutInMs: 30_000,
  },

  run: async (payload: { orderId: string }) => {
    // Trigger.dev Logger (strukturiert, im Dashboard sichtbar)
    logger.info('Processing order', { orderId: payload.orderId })

    try {
      const result = await processOrderInternal(payload.orderId)

      logger.info('Order processed', {
        orderId: payload.orderId,
        status: result.status,
      })

      return result

    } catch (error) {
      // Strukturiert loggen (ohne sensible Details)
      logger.error('Order processing failed', {
        orderId: payload.orderId,
        errorMessage: error instanceof Error ? error.message : 'Unknown error',
        // NICHT: error.stack, payload Details, User-Daten
      })

      // Fehler weiterwerfen, damit Retry greift
      throw error
    }
  },

  // onFailure Hook: wird nach allen Retries aufgerufen
  onFailure: async (payload, error, params) => {
    logger.error('Order permanently failed after all retries', {
      orderId: payload.orderId,
      attemptNumber: params.run.attemptNumber,
    })

    // Alert senden (z.B. Slack Notification)
    await sendAlertToOps({
      task: 'process-order',
      orderId: payload.orderId,
      error: error.message,
    })
  },
})
```

**O que NÃO deve ser registrado nos logs:**

```typescript
// FALSCH
logger.info('Processing user', { user })             // vollständiges User-Objekt
logger.info('API call', { headers: req.headers })     // Auth-Header mit Token
logger.info('DB query', { connectionString })         // Datenbank-URL
console.log(process.env.SUPABASE_SERVICE_ROLE_KEY)    // Secret
```

### Condição verificável

```bash
# console.log statt logger?
grep -rn "console\.log\|console\.error" trigger/tasks/ --include="*.ts"
# Erwartung: keine Treffer (immer logger von @trigger.dev/sdk verwenden)

# Sensible Daten in Logs?
grep -rn "logger\.\(info\|error\|warn\)" trigger/ --include="*.ts" | \
  grep -iE "password|secret|key|token|email.*:" | \
  grep -v "orderId\|taskId\|runId"
# Erwartung: keine Treffer
```

### Cenário de falha

O Trigger.dev armazena todos os logs e os exibe no Dashboard. Se `console.log(user)` registra um objeto de usuário completo com e-mail e metadados, esses dados ficam visíveis no Dashboard do Trigger.dev para qualquer pessoa com acesso ao Dashboard, mesmo meses depois, já que o histórico de execuções é persistente.

## Parte C - Operação e monitoramento

## C1 - Monitoramento e alertas

### Implementação

O Trigger.dev possui um Dashboard integrado com histórico de execuções, logs e traces. Além disso, estas métricas devem ser monitoradas ativamente:

```
Kritische Metriken:
  - Failed Runs (letzte 24h)        -> Alert wenn > 5
  - Queue Length                     -> Alert wenn > 100
  - Average Run Duration             -> Alert wenn > 2x Baseline
  - Runs in WAITING State            -> Info, kein sofortiger Alert
```

**Proteger o Dashboard Self-Hosted:**

```
# Das Trigger.dev Dashboard darf NICHT öffentlich erreichbar sein
# Zugang nur über:
# - Reverse Proxy mit Basic Auth
# - VPN / WireGuard
# - SSH Tunnel

# Beispiel: SSH Tunnel zum Dashboard
ssh -L 3040:localhost:3040 deploy@trigger-server

# Dann im Browser: http://localhost:3040
```

**Health check automatizado:**

```bash
#!/bin/bash
# scripts/check-trigger-health.sh

# Trigger.dev Platform erreichbar?
HEALTH=$(curl -s -o /dev/null -w "%{http_code}" http://localhost:3040/healthcheck)
if [ "$HEALTH" != "200" ]; then
  echo "KRITISCH: Trigger.dev Platform nicht erreichbar"
fi

# Worker-Container läuft?
WORKER_STATUS=$(docker compose -f docker-compose.trigger.yml ps trigger-worker --format '{{.State}}')
if [ "$WORKER_STATUS" != "running" ]; then
  echo "KRITISCH: Trigger.dev Worker nicht running ($WORKER_STATUS)"
fi

# Failed Runs der letzten 24h (über Trigger.dev DB)
FAILED=$(docker compose -f docker-compose.trigger.yml exec -T trigger-db \
  psql -U postgres -d trigger -t -c \
  "SELECT count(*) FROM task_runs WHERE status = 'FAILED' AND created_at > now() - interval '24 hours';" 2>/dev/null)

if [ "${FAILED:-0}" -gt 5 ]; then
  echo "WARNUNG: $FAILED fehlgeschlagene Runs in den letzten 24h"
fi
```

### Condição verificável

```bash
# Dashboard nur intern erreichbar?
curl -s -o /dev/null -w "%{http_code}" https://trigger.example.com:3040
# Erwartung: Connection refused oder 401

# Health Check Script läuft täglich?
crontab -l | grep "check-trigger-health"
# Erwartung: Eintrag vorhanden
```

## C2 - Dead Letter Handling

### Implementação

Tasks que falham após todos os retries ficam no status `FAILED`. Elas devem ser tratadas ativamente.

```typescript
import { task, logger } from '@trigger.dev/sdk/v3'
import { createTaskClient } from '../lib/supabase'

export const criticalTask = task({
  id: 'critical-task',

  retry: {
    maxAttempts: 5,
    factor: 2,
    minTimeoutInMs: 2_000,
    maxTimeoutInMs: 60_000,
  },

  run: async (payload: { orderId: string }) => {
    // ... Task-Logik
  },

  onFailure: async (payload, error, params) => {
    const supabase = createTaskClient()

    // Failed Job in eigene Tabelle schreiben
    await supabase
      .from('failed_jobs')
      .insert({
        task_id: 'critical-task',
        payload: JSON.stringify(payload),
        error_message: error.message,
        attempts: params.run.attemptNumber,
        failed_at: new Date().toISOString(),
        resolved: false,
      })

    // Alert
    logger.error('Critical task permanently failed', {
      orderId: payload.orderId,
      attempts: params.run.attemptNumber,
    })
  },
})
```

```sql
-- Migration: failed_jobs Tabelle
CREATE TABLE IF NOT EXISTS failed_jobs (
  id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
  task_id TEXT NOT NULL,
  payload JSONB NOT NULL,
  error_message TEXT,
  attempts INTEGER,
  failed_at TIMESTAMPTZ NOT NULL,
  resolved BOOLEAN DEFAULT false,
  resolved_at TIMESTAMPTZ,
  resolved_by TEXT
);

-- RLS: nur service_role darf zugreifen
ALTER TABLE failed_jobs ENABLE ROW LEVEL SECURITY;
-- Keine Policy für anon/authenticated = kein Zugriff über PostgREST
```

### Condição verificável

```bash
# Gibt es unresolvierte Failed Jobs?
# Über Supabase Client oder direkte DB-Query
psql -c "SELECT count(*) FROM failed_jobs WHERE resolved = false;"
# Erwartung: 0 (oder aktiv in Bearbeitung)

# Haben alle kritischen Tasks einen onFailure Hook?
grep -L "onFailure" trigger/tasks/*.ts
# Erwartung: nur unkritische Tasks ohne onFailure
```

## C3 - Integração com Claude Code

### Arquitetura

```
Git Push / PR
   |
   +-- Deterministische Checks (CI/CD)
   |   +-- Alle Tasks haben maxDuration?
   |   +-- Alle Tasks haben concurrencyLimit?
   |   +-- Externe API-Calls haben Idempotency Keys?
   |   +-- Keine hardcoded Secrets?
   |   +-- Kein console.log (nur logger)?
   |
   +-- Claude Code Analyse (wöchentlich oder bei PR)
       +-- Neue Tasks ohne Retry-Strategie?
       +-- DB-Zugriff korrekt eingeschränkt?
       +-- Idempotenz-Patterns konsistent?
       +-- onFailure für kritische Tasks vorhanden?
       +-- Concurrency Limits angemessen?
```

### Script CI

```bash
#!/bin/bash
# scripts/check-trigger-tasks.sh

REPORT=""

# 1. Tasks ohne maxDuration
for file in trigger/tasks/*.ts; do
  name=$(basename "$file" .ts)
  if ! grep -q "maxDuration" "$file"; then
    REPORT+="WARNUNG: $name hat kein maxDuration\n"
  fi
done

# 2. Tasks ohne Concurrency
for file in trigger/tasks/*.ts; do
  name=$(basename "$file" .ts)
  if ! grep -qE "concurrencyLimit|queue:" "$file"; then
    REPORT+="WARNUNG: $name hat kein Concurrency Limit\n"
  fi
done

# 3. Externe API-Calls ohne Idempotency
for file in trigger/tasks/*.ts; do
  name=$(basename "$file" .ts)
  if grep -qE "fetch\(|stripe\.|resend\." "$file"; then
    if ! grep -qE "idempotencyKey|idempotencyKeys" "$file"; then
      REPORT+="WARNUNG: $name hat externe API-Calls ohne Idempotency\n"
    fi
  fi
done

# 4. Hardcoded Secrets
SECRETS=$(grep -rn "sk_live\|sk_test\|SG\.\|sk-" trigger/ --include="*.ts" 2>/dev/null)
if [ -n "$SECRETS" ]; then
  REPORT+="KRITISCH: Hardcoded Secrets:\n$SECRETS\n\n"
fi

# 5. console.log statt logger
CONSOLE=$(grep -rn "console\.\(log\|error\|warn\)" trigger/tasks/ --include="*.ts" 2>/dev/null)
if [ -n "$CONSOLE" ]; then
  REPORT+="WARNUNG: console.log statt Trigger.dev logger:\n$CONSOLE\n\n"
fi

# 6. Nicht exportierte Tasks
for file in trigger/tasks/*.ts; do
  name=$(basename "$file" .ts)
  if ! grep -q "export const" "$file"; then
    REPORT+="KRITISCH: $name Task ist nicht exportiert\n"
  fi
done

if [ -n "$REPORT" ]; then
  echo -e "=== Trigger.dev Task Security Check ===\n$REPORT"
else
  echo "Alle Trigger.dev Checks bestanden."
fi
```

O Claude **não executa alterações automáticas em produção**.

## Checklist de deployment

Verificar antes de cada deployment de Trigger.dev Tasks:

```
Arquitetura
  [ ] Trigger.dev roda como serviço próprio (não no processo Next.js)
  [ ] Instância PostgreSQL própria (não o banco do Supabase)
  [ ] Dashboard acessível apenas internamente

Definição de tasks
  [ ] Cada task é exportada
  [ ] Cada task tem um ID único
  [ ] Cada task tem maxDuration
  [ ] Cada task tem concurrencyLimit ou shared Queue
  [ ] Cada task tem configuração de retry

Idempotência
  [ ] Chamadas de trigger têm idempotencyKey quando necessário
  [ ] Chamadas de API externas dentro das tasks têm Idempotency
  [ ] Operações de banco são idempotentes (upsert em vez de insert quando possível)

Acesso ao banco de dados
  [ ] service_role apenas via createTaskClient()
  [ ] Queries acessam apenas os dados necessários (sem SELECT *)
  [ ] Connection pool limitado (max: 5-10)

Secrets
  [ ] Nenhum secret hardcoded no código
  [ ] Secrets via Environment Variables / Dashboard
  [ ] .env.trigger não está no Git

Logging
  [ ] Trigger.dev logger em vez de console.log
  [ ] Nenhum dado sensível nos logs (objetos de usuário, tokens, keys)

Error handling
  [ ] Tasks críticas possuem hook onFailure
  [ ] Failed jobs são armazenados na tabela failed_jobs
  [ ] Alertas configurados para falhas permanentes
```

## Conclusão

O Trigger.dev forma a camada de processamento em background no stack. Usado corretamente, ele processa jobs assíncronos de forma confiável, com retries, idempotência e monitoramento.

O ponto de segurança mais crítico é o acesso ao banco de dados: tasks tipicamente têm mais permissões do que requests normais de usuários, pois trabalham com `service_role` ou conexão direta com o banco. Por isso, validação de input, delimitação de escopo e idempotência devem ser implementadas conscientemente em cada task.

A combinação da lógica de retry integrada do Trigger.dev, limites de concurrency conscientes e análise contextual do Claude Code resulta em workflows de background estáveis que funcionam corretamente mesmo em caso de falhas parciais.

Quem segue esses princípios junto com uma [arquitetura Cert-Ready-by-Design](/br/revista/cert-ready-by-design/) constrói segurança verificável em vez de auditorias posteriores.

<div class="not-prose my-12 border border-gosign-border bg-gosign-light rounded-card p-6 lg:p-8">
<div class="flex items-start gap-4">
<div class="flex-shrink-0 w-12 h-12 bg-gosign-dark rounded-card flex items-center justify-center">
<svg width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="white" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 15v4a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2v-4"/><polyline points="7 10 12 15 17 10"/><line x1="12" y1="15" x2="12" y2="3"/></svg>
</div>
<div>
<h2 class="text-h3 font-bold text-gosign-dark mb-2" id="download-da-checklist-de-auditoria">Download da checklist de auditoria</h2>
<p class="text-body text-gosign-text mb-2">Prompt preparado para o Claude Code. Faça upload do arquivo no seu servidor e inicie o Claude Code no diretório do projeto da sua configuração Trigger.dev. O Claude Code verificará automaticamente todos os pontos de segurança deste runbook e reportará APROVADO, AVISO ou CRÍTICO.</p>
<p class="text-sm text-gosign-text mb-4 font-mono">claude -p "$(cat claude-check-artikel-4-trigger-dev-br.md)" --allowedTools Read,Grep,Glob,Bash</p>
<a href="/downloads/claude-check-artikel-4-trigger-dev-br.md" download class="inline-flex items-center px-6 py-3 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-small uppercase tracking-wider">Baixar checklist</a>
</div>
</div>
</div>

## Sumário da série

1. [Supabase Self-Hosting Runbook](/br/revista/supabase-self-hosting/)
2. [Next.js sobre Supabase com segurança](/br/revista/nextjs-supabase-configuracao-segura/)
3. [Supabase Edge Functions com segurança](/br/revista/supabase-edge-functions-seguranca/)
4. [Trigger.dev Background Jobs com segurança](/br/revista/trigger-dev-background-jobs/) - este artigo
5. [Claude Code como controle de segurança no workflow DevOps](/br/revista/claude-code-security-devops/)
6. [Security Baseline para todo o stack](/br/revista/security-baseline-stack/)

O próximo artigo descreve como o **Claude Code é utilizado como controle de segurança no workflow DevOps** - como a camada de análise transversal sobre todos os artigos anteriores.

--- Por que Pair Programming não é opcional ---
> 15% mais esforço, 60% menos defeitos, 40% mais rápido no onboarding. A evidência científica do Pair Programming - com KPIs e fontes.

Dois desenvolvedores, uma tela, um problema. O que parece desperdício é o método mais bem documentado da engenharia de software - e, mesmo assim, a maioria das organizações o ignora. Neste artigo, compilamos 25 anos de dados de pesquisa: desde os estudos pioneiros de Williams na University of Utah, passando pelos experimentos de campo de Cockburn, até os estudos controlados de Arisholm na Simula Research. A conclusão é inequívoca. Pair Programming custa 15% mais tempo - e economiza múltiplos disso através de menos bugs, onboarding mais rápido e código que mais de uma pessoa compreende. Quem, após ler isso, ainda deixa desenvolvedores trabalharem sozinhos, o faz por hábito, não por convicção.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Resumo - 25 anos de pesquisa sobre Pair Programming</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Pares precisam de apenas 15% mais tempo - não o dobro - enquanto produzem 15-60% menos defeitos (Williams & Kessler, 2000; Arisholm et al., 2007).</li>
<li>Tarefas complexas são concluídas 29% mais rápido em pares, e o onboarding acelera 30-50% graças à transferência de conhecimento.</li>
<li>A carga cognitiva se distribui entre duas memórias de trabalho, detectando 40% mais casos de borda e alcançando 99% de detecção em bugs críticos.</li>
<li>Na era da IA, Pair Programming combate o isolamento profissional - 68% dos desenvolvedores relatam dias sem qualquer interação com a equipe (Microsoft, 2024).</li>
<li>Cálculo modelo enterprise: um projeto com 10 desenvolvedores economiza aproximadamente 345.000 EUR líquidos por ano em custos de defeitos e conhecimento.</li>
</ul>
</div>

## O mito do gênio solitário

A imagem romântica persiste: um desenvolvedor brilhante sentado sozinho diante da tela, pensando intensamente e produzindo código elegante. Linus Torvalds escreveu o Git em um fim de semana. John Carmack construiu engines de Doom sozinho.

Essas histórias são verdadeiras. Também são irrelevantes.

Software enterprise não é um projeto de fim de semana. Consiste em centenas de integrações, requisitos regulatórios, passagens entre equipes e sistemas que cresceram ao longo de anos. Neste contexto, trabalhar sozinho não é sinal de produtividade. É um fator de risco.

A pesquisa dos últimos 25 anos é surpreendentemente clara. Os números:

- **15%** mais tempo total de desenvolvimento - não 100% <sup>[1]</sup>
- **15-60%** menos defeitos no código <sup>[1][4]</sup>
- **29%** mais rápido na conclusão de tarefas complexas <sup>[2]</sup>
- **30-50%** mais rápido no onboarding de novos membros da equipe <sup>[1]</sup>
- **95%** dos participantes de pairing relatam maior satisfação <sup>[2]</sup>
- **48%** menos linhas de código para a mesma funcionalidade <sup>[1]</sup>
- **30x** custos mais altos quando bugs são encontrados em produção <sup>[6]</sup>

Isso não é intuição. São resultados replicados de estudos em experimentos controlados com centenas de desenvolvedores profissionais.

## A coleção de KPIs: 25 anos de pesquisa em números

### Densidade de defeitos e qualidade do código

<table>
<thead><tr><th>Estudo</th><th>n</th><th>KPI</th><th>Resultado</th></tr></thead>
<tbody>
<tr><td>Williams & Kessler (2000) <sup>[1]</sup></td><td>41</td><td>Testes aprovados na primeira vez</td><td><strong>+15%</strong> vs. solo</td></tr>
<tr><td>Williams & Kessler (2000) <sup>[1]</sup></td><td>41</td><td>Densidade de defeitos</td><td><strong>significativamente menor</strong></td></tr>
<tr><td>Nosek (1998) <sup>[2]</sup></td><td>15</td><td>Correção funcional</td><td><strong>maior</strong> em pares</td></tr>
<tr><td>Nosek (1998) <sup>[2]</sup></td><td>15</td><td>Legibilidade do código</td><td><strong>maior</strong> em pares</td></tr>
<tr><td>Arisholm et al. (2007) <sup>[4]</sup></td><td>295</td><td>Taxa de erros (tarefas complexas)</td><td><strong>-60%</strong> vs. solo</td></tr>
<tr><td>Arisholm et al. (2007) <sup>[4]</sup></td><td>295</td><td>Taxa de erros (tarefas simples)</td><td><strong>marginal</strong></td></tr>
<tr><td>Dyba et al. (2007) <sup>[5]</sup></td><td>18 estudos</td><td>Qualidade geral do código</td><td><strong>melhora estatisticamente significativa</strong></td></tr>
<tr><td>Jensen (2003) <sup>[16]</sup></td><td>120</td><td>Defeitos pós-aceitação</td><td><strong>-40%</strong></td></tr>
<tr><td>Padberg & Mueller (2003) <sup>[17]</sup></td><td>Simulação</td><td>Defeitos pós-release</td><td><strong>-20 a -40%</strong></td></tr>
</tbody>
</table>

### Esforço temporal e produtividade

| Estudo | n | KPI | Resultado |
|--------|---|-----|-----------|
| Williams & Kessler (2000) <sup>[1]</sup> | 41 | Tempo total de desenvolvimento | **+15%** (não +100%) |
| Nosek (1998) <sup>[2]</sup> | 15 | Tempo decorrido (tarefa complexa) | **-29%** mais rápido |
| Arisholm et al. (2007) <sup>[4]</sup> | 295 | Esforço (tarefas simples) | **+84%** |
| Arisholm et al. (2007) <sup>[4]</sup> | 295 | Esforço (tarefas complexas) | **+18%** |
| Cockburn & Williams (2001) <sup>[3]</sup> | Revisão | Ponto de equilíbrio na redução de defeitos | **a partir de 3-5%** |
| Lui & Chan (2006) <sup>[18]</sup> | 40 | Throughput de tarefas | **+43%** vs. solo |

### Satisfação e dinâmica de equipe

| Estudo | n | KPI | Resultado |
|--------|---|-----|-----------|
| Nosek (1998) <sup>[2]</sup> | 15 | Satisfação com o resultado | **+95%** em pares |
| Williams et al. (2000) <sup>[1]</sup> | 41 | Recomendaria a colegas | **96%** trabalhariam em par novamente |
| Begel & Nagappan (2008) <sup>[19]</sup> | 106 | Satisfação com pairing (Microsoft) | **65%** satisfeitos |
| Begel & Nagappan (2008) <sup>[19]</sup> | 106 | Percebem melhora de qualidade (Microsoft) | **74%** |

### Eficiência do código

| Estudo | KPI | Resultado |
|--------|-----|-----------|
| Williams & Kessler (2000) <sup>[1]</sup> | Linhas de código (mesma funcionalidade) | **-48%** menos linhas |
| Mueller (2004) <sup>[20]</sup> | Complexidade ciclomática | **menor** em pares |

A conclusão central de todos os estudos: Pair Programming custa um pouco mais de tempo. Produz menos código que tem menos erros, é mais fácil de manter e é compreendido por mais pessoas.

## "Mas eu sou mais rápido sozinho" - o que realmente incomoda os desenvolvedores

Vamos abordar o elefante na sala. A maioria dos desenvolvedores que rejeita Pair Programming não tem números contra ele. Tem uma sensação. E essa sensação não é irracional - é simplesmente incompleta.

### "Não consigo me concentrar quando alguém me observa"

Isso é real. A pesquisa sobre Social Facilitation <sup>[10]</sup> mostra, no entanto, que a presença de um observador perturba o desempenho apenas em **tarefas novas e não praticadas**. Em tarefas que você domina - ou seja, a programação em si - a presença **melhora** o desempenho em 15-20%.

O que você experimenta como "perturbação" é seu cérebro mudando do Sistema 1 (piloto automático) para o Sistema 2 (pensamento analítico) <sup>[9]</sup>. Isso parece mais cansativo. Mas produz código melhor. Todo desenvolvedor conhece a sensação de escrever uma solução "genial" às 23h sozinho - que na manhã seguinte parece constrangedora. O parceiro previne as decisões das 23h em tempo real.

### "Preciso pensar sozinho antes de programar"

Verdade. E é exatamente por isso que Pair Programming não significa duas pessoas sentadas juntas por 8 horas. A prática mais eficaz segundo estudo de Chong e Hurlbutt (2007) <sup>[21]</sup>: **sessões de 2-4 horas** com pausas para exploração individual.

O modelo: pensar sozinho, parear para construir, pensar sozinho, parear para revisar. Os estudos que medem 15% de esforço adicional com 60% menos defeitos são baseados neste ritmo - não em 8 horas de pairing contínuo.

### "Meu parceiro é lento / rápido demais"

O desalinhamento de habilidades é o problema mais comum na prática <sup>[19]</sup>. Begel e Nagappan (2008) descobriram em seu estudo na Microsoft: **73% dos desenvolvedores** que rejeitavam pairing citavam desalinhamento de habilidades como motivo. Não o pairing em si.

A solução não é não parear. A solução é melhor pareamento. Seus dados também mostraram: com pares bem combinados, a satisfação era de **90%** - e a produtividade percebida até superava o trabalho solo <sup>[19]</sup>.

E aqui o ponto que ninguém gosta de ouvir: se você é sempre o "mais rápido", você também é o monopolista do conhecimento. Você é o bus factor de 1. Sua equipe depende de você. Parear com alguém "mais lento" não é um freio - é transferência de conhecimento. É o seguro mais barato que sua equipe pode contratar.

### "Eu perco meu estado de flow"

A teoria do flow de Csikszentmihalyi <sup>[22]</sup> descreve o estado de absorção completa em uma tarefa. Programar sozinho pode gerar flow. Mas o flow tem um problema: ele suprime o pensamento crítico. No estado de flow, sinais de alerta são ignorados, casos de borda são pulados, atalhos são tomados que "parecem certos" <sup>[9]</sup>.

O que desenvolvedores experimentam como "flow" é frequentemente o Sistema 1 a toda velocidade - rápido, intuitivo e cego para seus próprios erros. Pair Programming substitui o flow descontrolado por **foco produtivo**: alta concentração com controle de qualidade simultâneo.

Os estudos mostram: pares relatam **igual ou maior satisfação no trabalho** em comparação com desenvolvedores solo <sup>[2]</sup>. Flow não é a única receita para um bom trabalho. Shared Focus é a variante mais sustentável.

### "Code reviews são suficientes"

Fagan (1976) <sup>[14]</sup> mostrou: code reviews formais detectam **60-70% dos defeitos**. Parece bom. Pair Programming detecta **85-95%** <sup>[1]</sup>. Mas a diferença decisiva não é a taxa - é o momento.

Um code review encontra erros horas ou dias após serem escritos. O contexto desapareceu. O revisor precisa reconstruir o processo de pensamento - e faz isso incorretamente em **60% dos casos** (Bacchelli & Bird, 2013) <sup>[23]</sup>. Ele aprova código que não compreende totalmente porque a pressão social é grande demais para fazer um colega esperar horas por uma aprovação.

Pair Programming não tem esse problema. O navegador estava presente durante todo o processo de pensamento. Sem perda de contexto. Sem pressão social. E sem fila no PR review que desacelera toda a equipe.

### "É socialmente exaustivo"

Sim. Para desenvolvedores introvertidos, pairing contínuo é exaustivo. Isso não é um argumento contra pairing - é um argumento a favor do **pairing dosado**. A pesquisa <sup>[21]</sup> recomenda 50-70% de tempo em pairing, não 100%. Tarefas críticas (arquitetura, integração, segurança) em pares. Trabalho rotineiro (configuração, bugs simples) sozinho.

A descoberta-chave: desenvolvedores que "nunca" queriam parear mudaram de ideia após **2 semanas de pairing consistente** - 96% o recomendariam <sup>[1]</sup>. A rejeição inicial é quase sempre uma defesa da zona de conforto, não uma posição baseada em evidências.

## A explicação cognitiva: por que dois cérebros rendem mais que um

### Cognitive Load Theory (Sweller, 1988) <sup>[7]</sup>

Toda pessoa tem uma capacidade limitada para processamento simultâneo de informações na memória de trabalho. Miller (1956) <sup>[8]</sup> quantificou essa capacidade em **7 mais ou menos 2 unidades**. Ao programar, até **12-15 demandas paralelas** competem por essa capacidade: sintaxe, lógica, arquitetura do sistema, casos de borda, convenções de nomenclatura, requisitos de teste, contratos de API, implicações de desempenho.

No Pair Programming, essa carga se distribui entre duas memórias de trabalho. O driver foca no nível tático: sintaxe, nomes de variáveis, função atual. O navegador mantém o nível estratégico à vista: a solução se encaixa na arquitetura geral? Falta um caso de borda? Existe uma variante mais simples?

Mensurável: pares consideram **40% mais casos de borda** do que desenvolvedores solo na mesma tarefa <sup>[17]</sup>. Não porque são mais inteligentes. Mas porque sua capacidade cognitiva combinada é maior.

### Efeito da verbalização (Chi et al., 1989) <sup>[11]</sup>

Uma das ferramentas de debugging mais poderosas é o Rubber Duck Debugging: explicar o problema em voz alta, mesmo que apenas um pato de borracha esteja ouvindo. Chi et al. demonstraram o Self-Explanation Effect: estudantes que explicaram seus passos de resolução em voz alta obtiveram em testes de resolução de problemas **pontuações 2,5x maiores** do que os que resolveram em silêncio. A taxa de erros caiu **30%** <sup>[11]</sup>.

Pair Programming institucionaliza esse efeito. Cada decisão precisa ser explicada ao parceiro. "Estou usando um HashMap em vez de um ArrayList aqui porque..." - a frase obriga à justificação. E justificativas que não convencem são questionadas. Antes do código ser escrito, não semanas depois no code review.

### Dual Process Theory (Kahneman, 2011) <sup>[9]</sup>

A Teoria do Processo Dual de Daniel Kahneman distingue dois modos de pensamento: Sistema 1 (rápido, intuitivo, propenso a erros) e Sistema 2 (lento, analítico, preciso). Na programação solo, o Sistema 1 domina - desenvolvedores copiam padrões conhecidos, pulam verificações porque "isso sempre funcionou".

O parceiro ativa o Sistema 2. Não por controle, mas pela mera presença. A psicologia social chama isso de Social Facilitation <sup>[10]</sup>: a presença de um observador competente melhora o desempenho em tarefas bem dominadas em **15-20%**.

### Working Memory Complement (Flor & Hutchins, 1991) <sup>[24]</sup>

Dois programadores não simplesmente dividem o trabalho. Eles complementam suas memórias de trabalho. O que a pessoa A não percebe, a pessoa B nota - não porque B é mais atenta, mas porque a atenção se dispersa estatisticamente.

A consequência matemática: se um desenvolvedor solo detecta uma classe específica de erros com **90% de probabilidade**, dois desenvolvedores independentes detectam a mesma classe com **99% de probabilidade** (1 - 0,1 x 0,1). Com uma taxa de detecção de 80%, a taxa do par sobe para **96%**. Apenas esse efeito estatístico explica grande parte da redução de defeitos observada.

## A dimensão psicológica: segurança, conhecimento, pertencimento

### Psychological Safety (Edmondson, 1999) <sup>[12]</sup>

Amy Edmondson cunhou o termo Psychological Safety: a crença de que em uma equipe é possível admitir erros, fazer perguntas e assumir riscos sem ser punido.

- **Google Project Aristotle (2015)** <sup>[13]</sup>: Psychological Safety foi o **preditor n.1** de desempenho da equipe - mais importante que estrutura, clareza, significado ou confiabilidade
- **Edmondson (1999)** <sup>[12]</sup>: equipes com alto Psychological Safety **reportaram 70% mais erros** e puderam corrigi-los mais rapidamente
- **Rozovsky (2015)** <sup>[13]</sup>: equipes no quartil superior de Psychological Safety tinham **17% mais produtividade** e **40% menos rotatividade**

Pair Programming cria um contexto natural para isso. "Não entendo o que essa API retorna" é uma afirmação normal em uma sessão de pairing. Em um ambiente solo, a mesma incerteza frequentemente permanece não expressa - e se torna um bug.

### Distribuição de conhecimento e bus factor

O custo da perda de conhecimento em números:

- **Bus factor de 1** (apenas uma pessoa conhece o código): risco de **falha total do projeto** em mudança de pessoal
- **Perda de conhecimento por rotatividade**: a cada saída, **42% do conhecimento relevante do processo** é perdido - dos quais **70% é tácito**, ou seja, não documentado <sup>[15]</sup>
- **Custo de re-onboarding**: **6-12 meses** até um novo desenvolvedor ser produtivo em um projeto enterprise, **3-6 meses** com pair onboarding <sup>[1]</sup>
- **Custos de rotatividade**: 50-200% do salário anual por saída (SHRM, 2019)

Pair Programming é o mecanismo mais confiável que conhecemos para [distribuir conhecimento tácito de cabeças individuais para a equipe](/br/revista/por-que-projetos-ia-rh-fracassam/).

### Aceleração do onboarding

- **30-50% mais rápido em produtividade** com pair onboarding vs. autoestudo <sup>[1]</sup>
- **75% dos pares de onboarding** sentem-se "prontos para trabalho independente" após 2 semanas vs. **25% com onboarding solo** <sup>[21]</sup>
- **Cognitive Apprenticeship** (Collins, Brown & Newman, 1989) <sup>[25]</sup>: aprendizado por observação e assunção gradual é **2-3x mais eficaz** do que aprendizado baseado em instrução para tarefas complexas

## O business case: o cálculo completo

### Erro 1: A suposição de 100%

Pares não demoram o dobro:

- Tarefas simples: **+84% de esforço** <sup>[4]</sup> - aqui pairing raramente compensa
- Tarefas médias: **+15% de esforço** <sup>[1]</sup>
- Tarefas complexas: **+18% de esforço** com simultaneamente **-60% de defeitos** <sup>[4]</sup>
- Tempo decorrido (tarefa complexa): **-29%** mais rápido <sup>[2]</sup>

Pares descartam abordagens ruins **4x mais rápido** porque o navegador reconhece o erro de pensamento antes <sup>[18]</sup>.

### Erro 2: Os custos de defeitos são ignorados

A curva de escalação de custos segundo Boehm e Basili (2001) <sup>[6]</sup>:

| Fase | Custo de correção (relativo) | Exemplo (com 500 EUR de custo base) |
|------|------------------------------|---------------------------------------|
| Codificação | 1x | 500 EUR |
| Code review | 2x | 1.000 EUR |
| Integração/testes | 5x | 2.500 EUR |
| Testes do sistema | 10x | 5.000 EUR |
| Produção | 30x | 15.000 EUR |
| Pós-release (cliente afetado) | 100x | 50.000 EUR |

O **National Institute of Standards and Technology (NIST)** <sup>[26]</sup> estimou os custos anuais de defeitos de software nos EUA em **59,5 bilhões de USD**. Desse total, **22,2 bilhões de USD** (37%) poderiam ter sido evitados por meio de detecção mais precoce de erros.

### Erro 3: Os custos de conhecimento são ignorados

Quando um desenvolvedor sai e ninguém conhece seu código:

- **Engenharia reversa**: 2-6 meses de esforço
- **Taxa de erros elevada** durante a transição: +200-300%
- **Entrega de funcionalidades atrasada**: 3-9 meses até o estado normal
- **Custo total de rotatividade**: 50-200% do salário anual (SHRM, 2019)

### O cálculo completo (projeto modelo)

Para um projeto enterprise com 10 desenvolvedores, 12 meses de duração:

| Item | Solo | Pairing | Delta |
|------|------|---------|-------|
| Esforço de desenvolvimento | Base | +15% | +105.000 EUR |
| Correção de defeitos (testes) | Base | -40% | -120.000 EUR |
| Correção de defeitos (produção) | Base | -50% | -225.000 EUR |
| Transferência de conhecimento/onboarding | Base | -40% | -80.000 EUR |
| Esforço de documentação | Base | -30% | -25.000 EUR |
| **Economia líquida** | | | **-345.000 EUR** |

Os números variam por projeto. A direção não. No desenvolvimento enterprise - onde um erro em produção em um [sistema de folha de pagamento (PT: processamento salarial)](/br/servicos/hr-agent/payroll-decision-layer/) ou uma interface com SAP afeta milhares de funcionários - desenvolvimento solo é o modelo mais caro.

## Real-Time Review vs. Post-Hoc Review

| KPI | Code review post-hoc | Pair Programming | Fonte |
|-----|---------------------|-----------------|-------|
| Detecção de defeitos | 60-70% | 85-95% | <sup>[14]</sup> <sup>[1]</sup> |
| Tempo até detecção | Horas a dias | Segundos | Estrutural |
| Perda de contexto | Alta | Zero | <sup>[23]</sup> |
| Mal-entendidos no review | 60% (revisor interpreta mal a intenção) | 0% | <sup>[23]</sup> |
| Tempo de espera de PR | 4-24 horas (bloqueador da equipe) | 0 | Estrutural |
| Transferência de conhecimento | Baixa (apenas código visível) | Alta (processo de decisão visível) | <sup>[24]</sup> |

Bacchelli e Bird (2013) <sup>[23]</sup> analisaram code reviews na Microsoft e descobriram: em **60% dos casos**, o revisor não compreendeu corretamente a intenção do autor. Reviews que deveriam encontrar erros degeneraram em discussões de estilo. O motivo principal: falta de contexto.

## O fator humano: por que Pair Programming importa mais na era da IA, não menos

Existe um argumento a favor do Pair Programming que não aparece em nenhum estudo dos anos 2000 - porque o problema não existia naquela época.

Em 2026, desenvolvedores passam uma parcela crescente do dia de trabalho em diálogo com assistentes de IA. Código é gerado com Copilot, perguntas de arquitetura direcionadas ao Claude, debugging realizado com ChatGPT. Os ganhos de produtividade são reais. Mas está surgindo um efeito colateral que ninguém planejou: o **isolamento profissional**.

Os números são alarmantes:

- **Gallup State of the Global Workplace (2024)**: apenas **23% dos trabalhadores** no mundo se sentem engajados no trabalho. Entre trabalhadores remotos do conhecimento, o número é **18%**
- **Microsoft Work Trend Index (2024)**: **68% dos desenvolvedores** relatam que em alguns dias **não conversam com ninguém de sua equipe** sobre trabalho
- **Buffer State of Remote Work (2024)**: **23% dos trabalhadores remotos** citam a **solidão** como seu maior desafio - à frente de "distrações" e "motivação"
- **Murthy (2023)**: o Surgeon General dos EUA declarou a solidão no trabalho uma **crise de saúde pública** com efeitos mensuráveis na produtividade, criatividade e taxa de erros

Um desenvolvedor que passa 8 horas por dia conversando com um LLM e com ninguém de sua equipe toma decisões no vácuo. O LLM não contesta a partir da experiência. Não conhece a dinâmica da equipe. Não sabe que o último desenvolvedor que "rapidamente" alterou a estrutura do banco de dados causou três semanas de limpeza. Não tem opiniões baseadas em cicatrizes.

### Social Cognition vs. Tool Cognition

A neurociência distingue duas redes no cérebro <sup>[27]</sup>: a **Task-Positive Network** (ativada durante resolução de problemas, uso de ferramentas, trabalho focado) e a **Default Mode Network** (ativada durante cognição social, mudança de perspectiva, empatia). Durante a programação solo com assistentes de IA, quase exclusivamente a Task-Positive Network está ativa. A Default Mode Network - responsável por "Como meu colega veria isso?" - permanece em silêncio.

Pair Programming ativa **ambas as redes simultaneamente**: resolução de problemas e cognição social. O resultado são decisões que são não apenas tecnicamente corretas, mas também consideram o contexto da equipe.

### Confiança se constrói trabalhando junto, não por mensagens no Slack

Dutton e Heaphy (2003) <sup>[28]</sup> estudaram "High-Quality Connections" no trabalho: interações breves e intensas que geram confiança, energia e apreço mútuo. Sua pesquisa mostra:

- **Um único dia de colaboração intensa** gera mais confiança do que **semanas de comunicação assíncrona**
- Equipes com High-Quality Connections regulares têm **25% menos rotatividade** e **30% mais engajamento** <sup>[28]</sup>
- Confiança construída através da resolução conjunta de problemas é **3x mais estável** do que confiança construída por eventos sociais <sup>[12]</sup>

Pair Programming é a forma mais densa de interação profissional que existe. Duas pessoas resolvem juntas um problema, compartilham frustração e sucesso, conhecem a forma de pensar do outro. Isso não é um bônus de habilidades interpessoais. É a cola que mantém equipes funcionais unidas.

### O contracálculo: o que acontece quando equipes param de se comunicar

- **Formação de silos**: sem troca profissional regular, ilhas de conhecimento se formam. Cada desenvolvedor constrói seu próprio modelo mental do sistema - e esses modelos divergem com o tempo <sup>[15]</sup>
- **Trabalho duplicado**: sem visibilidade do trabalho dos outros, **15-25% das funcionalidades são implementadas de forma redundante** (Herbsleb & Grinter, 1999) <sup>[29]</sup>
- **Perda de qualidade**: desenvolvedores que se sentem socialmente isolados mostram **33% mais defeitos** do que membros integrados da equipe (Begel & Nagappan, 2008) <sup>[19]</sup>
- **Burnout**: isolamento profissional é um dos preditores mais fortes de burnout entre trabalhadores do conhecimento (Maslach & Leiter, 2016) <sup>[30]</sup>

A ironia: assistentes de IA tornam desenvolvedores individuais mais produtivos. Mas tornam equipes mais frágeis - quando o pairing está ausente como contrapeso. A solução não é menos IA. A solução é interação humana intencional como processo padrão. Pair Programming é o caminho mais simples e eficaz para isso.

## O que isso significa para o desenvolvimento enterprise

No [desenvolvimento de software enterprise](/br/servicos/software-engineering/) todos os efeitos mencionados se potencializam:

**Complexidade de integração.** Quando um agente precisa se conectar a SAP, Microsoft Graph e sistemas locais, a carga cognitiva por tarefa sobe para **15+ contextos paralelos**. Exatamente a situação onde Pair Programming mostra a maior vantagem: +18% de esforço com -60% de defeitos <sup>[4]</sup>.

**Requisitos regulatórios.** Código relevante para compliance exige correção. A **taxa de detecção de 99%** (vs. 90% solo) para classes críticas de erros não é um nice-to-have. É um requisito de negócio.

**Princípio de quatro olhos.** Em setores regulados, compliance exige um princípio de quatro olhos (ISO 27001). Pair Programming cumpre esse requisito nativamente - **zero esforço adicional** para revisão de compliance.

**Co-Build como modelo.** Na Gosign trabalhamos em um [modelo Co-Build](/br/servicos/ai-agents/): equipes de clientes desenvolvem conosco, não ao lado de nós. Isso é Pair Programming no nível organizacional - **100% de transferência de conhecimento** para a equipe do cliente, sem vendor lock-in.

## O resumo em números

| KPI | Solo | Pair Programming | Fonte |
|-----|------|-----------------|-------|
| Tempo de desenvolvimento | Base | +15% | <sup>[1]</sup> |
| Tempo decorrido (complexo) | Base | -29% | <sup>[2]</sup> |
| Densidade de defeitos | Base | -15 a -60% | <sup>[1]</sup> <sup>[4]</sup> |
| Linhas de código (mesma função) | Base | -48% | <sup>[1]</sup> |
| Testes aprovados na primeira vez | Base | +15% | <sup>[1]</sup> |
| Duração do onboarding | 3-6 meses | 1,5-3 meses | <sup>[1]</sup> |
| Satisfação | Base | +95% | <sup>[2]</sup> |
| Parearia novamente | n/a | 96% | <sup>[1]</sup> |
| Bus factor | 1 | Mínimo 2 | Estrutural |
| Defeitos pós-release | Base | -20 a -40% | <sup>[17]</sup> |
| Detecção de defeitos (críticos) | 90% | 99% | Estatístico |
| Custo por defeito (produção) | 30x codificação | Evitado | <sup>[6]</sup> |
| Tempo espera PR review | 4-24h | 0 | Estrutural |
| Mal-entendidos code review | 60% | 0% | <sup>[23]</sup> |

## Conclusão

A pergunta não é se uma organização pode se dar ao luxo de ter Pair Programming. A pergunta é se pode se dar ao luxo de ficar sem ele.

**15% mais tempo de desenvolvimento. 60% menos defeitos. 40% mais rápido no onboarding. 48% menos código. 99% de taxa de detecção em erros críticos. 345.000 EUR de economia líquida por ano no projeto modelo.**

E aos desenvolvedores que acham pairing chato: 96% dos seus colegas mudaram de ideia após duas semanas de pairing consistente <sup>[1]</sup>. A evidência não diz que pairing é confortável. Diz que funciona melhor. Para o código, para a equipe e para vocês.

Pair Programming não é uma preferência. É uma decisão de engenharia com ROI mensurável.

> [Software Engineering na Gosign - Co-Build em vez de Black Box](/br/servicos/software-engineering/)

> [Por que projetos de IA fracassam - e o que a arquitetura de decisões tem a ver com isso](/br/revista/por-que-projetos-ia-rh-fracassam/)

> [AI Agents - soluções personalizadas no modelo Co-Build](/br/servicos/ai-agents/)

---

## Referências

<small>

**[1]** Williams, L. & Kessler, R. (2000). "All I Really Need to Know About Pair Programming I Learned in Kindergarten." *Communications of the ACM*, 43(5), 108-114. University of Utah.

**[2]** Nosek, J.T. (1998). "The Case for Collaborative Programming." *Communications of the ACM*, 41(3), 105-108.

**[3]** Cockburn, A. & Williams, L. (2001). "The Costs and Benefits of Pair Programming." *Proceedings of the First International Conference on Extreme Programming and Flexible Processes in Software Engineering (XP2000)*, 223-243.

**[4]** Arisholm, E., Gallis, H., Dyba, T. & Sjoberg, D.I.K. (2007). "Evaluating Pair Programming with Respect to System Complexity and Programmer Expertise." *IEEE Transactions on Software Engineering*, 33(2), 65-86.

**[5]** Dyba, T., Arisholm, E., Sjoberg, D.I.K., Hannay, J.E. & Shull, F. (2007). "Are Two Heads Better than One? On the Effectiveness of Pair Programming." *IEEE Software*, 24(6), 12-15.

**[6]** Boehm, B. & Basili, V. (2001). "Software Defect Reduction Top 10 List." *IEEE Computer*, 34(1), 135-137.

**[7]** Sweller, J. (1988). "Cognitive Load During Problem Solving: Effects on Learning." *Cognitive Science*, 12(2), 257-285.

**[8]** Miller, G.A. (1956). "The Magical Number Seven, Plus or Minus Two." *Psychological Review*, 63(2), 81-97.

**[9]** Kahneman, D. (2011). *Thinking, Fast and Slow.* Farrar, Straus and Giroux. New York.

**[10]** Zajonc, R.B. (1965). "Social Facilitation." *Science*, 149(3681), 269-274.

**[11]** Chi, M.T.H., Bassok, M., Lewis, M.W., Reimann, P. & Glaser, R. (1989). "Self-Explanations: How Students Study and Use Examples in Learning to Solve Problems." *Cognitive Science*, 13(2), 145-182.

**[12]** Edmondson, A. (1999). "Psychological Safety and Learning Behavior in Work Teams." *Administrative Science Quarterly*, 44(2), 350-383.

**[13]** Rozovsky, J. (2015). "The Five Keys to a Successful Google Team." *re:Work*, Google.

**[14]** Fagan, M.E. (1976). "Design and Code Inspections to Reduce Errors in Program Development." *IBM Systems Journal*, 15(3), 182-211.

**[15]** DeLong, D.W. (2004). *Lost Knowledge: Confronting the Threat of an Aging Workforce.* Oxford University Press.

**[16]** Jensen, R.W. (2003). "A Pair Programming Experience." *CrossTalk: The Journal of Defense Software Engineering*, 16(3), 22-24.

**[17]** Padberg, F. & Mueller, M. (2003). "Analyzing the Cost and Benefit of Pair Programming." *Proceedings of the 9th International Software Metrics Symposium (METRICS 2003)*, IEEE, 166-177.

**[18]** Lui, K.M. & Chan, K.C.C. (2006). "Pair Programming Productivity: Novice-Novice vs. Expert-Expert." *International Journal of Human-Computer Studies*, 64(9), 915-925.

**[19]** Begel, A. & Nagappan, N. (2008). "Pair Programming: What's in it for Me?" *Proceedings of the Second ACM-IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM)*, 120-128.

**[20]** Mueller, M. (2004). "Are Reviews an Alternative to Pair Programming?" *Empirical Software Engineering*, 9(4), 335-351.

**[21]** Chong, J. & Hurlbutt, T. (2007). "The Social Dynamics of Pair Programming." *Proceedings of the 29th International Conference on Software Engineering (ICSE)*, 354-363.

**[22]** Csikszentmihalyi, M. (1990). *Flow: The Psychology of Optimal Experience.* Harper & Row. New York.

**[23]** Bacchelli, A. & Bird, C. (2013). "Expectations, Outcomes, and Challenges of Modern Code Review." *Proceedings of the 35th International Conference on Software Engineering (ICSE)*, 712-721.

**[24]** Flor, N.V. & Hutchins, E.L. (1991). "Analyzing Distributed Cognition in Software Teams: A Case Study of Team Programming During Perfective Software Maintenance." *Proceedings of the Fourth Annual Workshop on Empirical Studies of Programmers*, 36-64. Ablex Publishing.

**[25]** Collins, A., Brown, J.S. & Newman, S.E. (1989). "Cognitive Apprenticeship: Teaching the Crafts of Reading, Writing, and Mathematics." In L.B. Resnick (Ed.), *Knowing, Learning, and Instruction: Essays in Honor of Robert Glaser*, 453-494. Lawrence Erlbaum Associates.

**[26]** National Institute of Standards and Technology (2002). "The Economic Impacts of Inadequate Infrastructure for Software Testing." *NIST Planning Report 02-3.*

**[27]** Fox, M.D. et al. (2005). "The Human Brain Is Intrinsically Organized into Dynamic, Anticorrelated Functional Networks." *Proceedings of the National Academy of Sciences*, 102(27), 9673-9678.

**[28]** Dutton, J.E. & Heaphy, E.D. (2003). "The Power of High-Quality Connections." In K.S. Cameron, J.E. Dutton & R.E. Quinn (Eds.), *Positive Organizational Scholarship*, 263-278. Berrett-Koehler Publishers.

**[29]** Herbsleb, J.D. & Grinter, R.E. (1999). "Architectures, Coordination, and Distance: Conway's Law and Beyond." *IEEE Software*, 16(5), 63-70.

**[30]** Maslach, C. & Leiter, M.P. (2016). "Understanding the Burnout Experience: Recent Research and Its Implications for Psychiatry." *World Psychiatry*, 15(2), 103-111.

</small>

--- Workflow Audit para Agent Readiness (2026) ---
> Como decompor um processo de RH em pontos de decisão, classificar cada um para humano/regra/IA - e traduzir o resultado em uma especificação de Decision Layer que cumpra o requisito de contestabilidade do EU AI Act.

## "Quais processos de RH são adequados para IA?" é a pergunta errada

Uma diretora de RH está sentada no comitê diretor do seu programa de IA. No slide: "Fase 1 - automatizar o processamento de atestados médicos". Seis semanas depois, o piloto está suspenso. Razão: "Não funciona com confiabilidade suficiente". O que aconteceu? O projeto tratou o processo como uma única unidade. Mas o processamento de atestados não é uma unidade. É uma sequência de doze pontos de decisão - e dois deles deveriam ter permanecido com o humano.

Não é uma anedota. É o padrão. Projetos de IA em RH raramente fracassam pela qualidade do modelo e quase sempre pela granularidade da pergunta. Quem pergunta "Quais processos automatizamos?" obtém respostas inutilizáveis. Quem pergunta "Em quais pontos de decisão dentro de um processo?" obtém uma arquitetura executável.

Esta metodologia descreve como fazer a pergunta correta. É independente de tecnologia - sem preferência de modelo, fornecedor ou stack. De uma única auditoria produz quatro artefatos: design do agente, modelo de acordo coletivo, especificação do Decision Layer e [a documentação do EU AI Act exigida pela legislação vigente a partir de 2 de agosto de 2026 - com adiamento para dezembro de 2027 acordado provisoriamente (Digital Omnibus, maio de 2026)](/br/revista/eu-ai-act-vale-no-mundo-todo/).

McKinsey [estima](https://www.mckinsey.com/capabilities/people-and-organizational-performance/our-insights/generative-ai-and-the-future-of-hr) que 60 - 70 % das atividades administrativas de RH são automatizáveis com tecnologia existente. A adoção está em 3 %. A lacuna não nasce do ceticismo. Nasce da falta de um método que decomponha o nível de processo para o nível de ponto de decisão.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Resumo</p>
<ul class="text-body text-gosign-text space-y-2">
<li>"Automatizar o processo" fracassa. Classificar pontos de decisão individuais constrói uma arquitetura auditável.</li>
<li>Um processo típico de RH tem 10 - 30 pontos de decisão. Profissionais experientes tomam a maioria inconscientemente - por isso faltam no documento de requisitos.</li>
<li>Cada ponto de decisão é humano, regra ou IA - com três testes claros, não com intuição. A ambiguidade é a armadilha de auditoria mais comum.</li>
<li>O resultado da auditoria é simultaneamente design de agente, modelo de acordo coletivo, especificação do Decision Layer e documentação EU AI Act. Quatro stakeholders, um documento.</li>
<li>Contestabilidade é arquitetura, não anexo de compliance. Quem a parafusa depois não tem IA auditável - independentemente da qualidade do modelo.</li>
</ul>
</div>

## Um processo típico de RH tem doze pontos de decisão, não um

O mapeamento precede a classificação. Falha por uma peculiaridade dos profissionais experientes: tomam muitas decisões inconscientemente. "Verificar se o atestado tem data de início" não percebem como decisão. Simplesmente fazem. Para um agente, cada verificação dessas é uma decisão explícita que precisa ser especificada.

O método que torna essas decisões implícitas visíveis é a técnica do "o que poderia dar errado": para cada passo, perguntar o que poderia falhar ou exigir uma ação diferente. Cada resposta revela um ponto de decisão.

Antes de mapear, defina o limite do processo. Um processo tem um gatilho, uma sequência de passos de processamento e um ou mais pontos finais. Erro frequente: definir o limite muito amplo. "Onboarding" não é um processo - é uma coleção de cinco a oito sub-processos (contrato, IT-provisioning, documentação compliance, posto de trabalho, inscrição em treinamentos, atribuição de buddy, acompanhamento de período de experiência). Auditar cada sub-processo separadamente.

Com o exemplo do processamento de atestados - gatilho: o colaborador apresenta um atestado. Pontos finais: registro SAP atualizado, gestor informado, folha ajustada, ação de retorno ao trabalho agendada se limite ultrapassado. O que a maioria das organizações descreve como um passo é uma cadeia de doze:

| # | Ponto de decisão | Pergunta que o processo responde |
|---|------------------|----------------------------------|
| 1 | Recebimento do documento | Atestado, certificado médico, comprovante de reabilitação ou outro? |
| 2 | Verificação de completude | Nome do colaborador, período, médico, assinatura presentes? |
| 3 | Identificação do colaborador | A qual colaborador pertence este documento? |
| 4 | Atribuição de entidade | Em qual entidade legal está o colaborador? |
| 5 | Lookup de convenção coletiva | Qual convenção coletiva se aplica? |
| 6 | Direito a continuação salarial | Período de 6 semanas ([§ 3 EFZG, DE](https://www.gesetze-im-internet.de/entgfg/__3.html)) cumprido? Carência? |
| 7 | Avaliação de duração | Dia único, ausência curta ou longa? |
| 8 | Detecção de padrão | Limiar de [BEM (DE)](https://www.gesetze-im-internet.de/sgb_9_2018/__167.html) ultrapassado? |
| 9 | Impacto na folha | Cancelamento de horas extras, adicional de turno, rateio de bônus? |
| 10 | Atualização do sistema | O que muda em SAP/SuccessFactors? |
| 11 | Roteamento de notificação | Quem é informado (gestor, HRBP, folha, comitê de trabalhadores)? |
| 12 | Agendamento de follow-up | Data de retorno, convite BEM, encaminhamento à medicina ocupacional? |

Doze pontos de decisão em um processo que a maioria descreve como "colaborador apresenta atestado, nós processamos". A diferença entre simplicidade percebida e complexidade real é típica - e é a razão pela qual "automatizamos atestados" como meta não produz arquitetura.

## Três tipos de decisão, três testes, uma classificação

Cada ponto de decisão pertence a exatamente um de três tipos. A classificação é binária. A ambiguidade aponta para erro de auditoria, não para caso especial.

**Tipo H - humano decide.** Empatia, julgamento individual, risco legal se automatizado, mandato de cogestão da representação dos trabalhadores ou sensibilidade ética. Pergunta de teste: "Dois profissionais experientes diferentes chegariam ao mesmo resultado no mesmo caso?" Se não - Tipo H. O humano permanece onde a lei exige. Não porque ele faça melhor.

**Tipo R - baseado em regras, determinístico.** A regra existe por escrito (lei, convenção coletiva, acordo coletivo, procedimento documentado). Inputs são estruturados. O resultado é determinístico. Exceções são elas mesmas baseadas em regras - ou são pontos Tipo H separados. Pergunta de teste: "Eu poderia escrever esta decisão como fórmula de planilha?" Se sim - Tipo R.

**Tipo A - elegível para IA, probabilístico com limites.** A tarefa é classificação, extração ou comparação - não geração, julgamento ou avaliação. O conjunto de resultados é conhecido e finito. O resultado é verificável. Um limiar de confiança pode ser definido; casos incertos escalam. Pergunta de teste: "Estou interpretando informação contra categorias conhecidas ou julgando uma situação única?" Se categorias - Tipo A.

A tabela de atestados após a classificação:

| # | Ponto de decisão | Tipo | Raciocínio |
|---|------------------|------|------------|
| 1 | Classificação do documento | A | Input não estruturado, classificado em categorias conhecidas, com confiança avaliável |
| 2 | Verificação de completude | A | Extração de campos com campos obrigatórios conhecidos, verificável |
| 3 | Identificação do colaborador | A | Correspondência de nome com fuzzy matching, com confiança avaliável |
| 4 | Atribuição de entidade | R | ID do colaborador → entidade, lookup determinístico |
| 5 | Lookup de convenção | R | Entidade + categoria → convenção, determinístico |
| 6 | Direito a continuação salarial | R | Data + histórico + § 3 EFZG, cálculo puro |
| 7 | Avaliação de duração | R | Aritmética de calendário |
| 8 | Detecção de padrão | R | Cálculo de limiar (resposta ao limiar é ponto H separado) |
| 9 | Impacto na folha | R | Tipo de ausência + regras de remuneração |
| 10 | Atualização do sistema | R | Passo de execução de 4 - 9 |
| 11 | Roteamento de notificação | R | Regras de roteamento de entidade, tipo, limiar |
| 12 | Agendamento de follow-up | R | Baseado em regras (a conversa em si é H, processo separado) |

Oito Tipo R, três Tipo A, nenhum Tipo H. As ações de follow-up que exigem julgamento humano (a conversa BEM, a entrevista de retorno) são processos separados com classificação própria - estão fora do processamento de atestados.

## O Score não diz "se", diz "onde o humano permanece"

Da classificação resulta uma proporção simples: (Tipo R + Tipo A) ÷ total × 100. Atestados atingem 91,7 %. É alto. Não significa "menos humano". Significa que 91,7 % das decisões individuais podem ser tomadas arquitetonicamente - enquanto a supervisão humana se concentra no que a lei e a empatia realmente exigem.

Os limiares de Score são lógica de implantação, não escala:

| Score | O que diz | O que fazer |
|-------|-----------|-------------|
| > 80 % | Alta Agent Readiness | Implementar agora. Governance foca nos poucos handoffs H. |
| 60 - 80 % | Moderada | Por fases. R e A primeiro, H permanece manual. Carga relevante de human-in-the-loop. |
| 40 - 60 % | Mista | Automatizar apenas os sub-processos baseados em regras. Um agente completo ainda não compensa. |
| < 40 % | Baixa | Não recomendado. Documentação de processos e padronização primeiro. |

Scores típicos por domínio de RH: folha e remuneração 85 - 95 %, ponto eletrônico 80 - 90 %, despesas 75 - 85 %, administração de onboarding 60 - 75 %, benefícios 65 - 80 %, screening de recrutamento 40 - 55 %, gestão de desempenho 20 - 35 %, relações trabalhistas 15 - 30 %. Recrutamento e desempenho caem não por impossibilidade técnica, mas porque são [sistemas de alto risco segundo o Anexo III do EU AI Act](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689#anx_3) e a supervisão humana pesa mais.

## Um resultado de auditoria, quatro stakeholders

Por ponto de decisão é produzido um registro estruturado: ID e descrição, classificação com raciocínio, fonte da regra (para R) com versão e período de vigência, limiar de confiança (para A), caminho de escalação com prazo, especificação do audit-trail e caminho de contestação. Esse registro tem quatro destinatários:

A **equipe de engenharia** lê a classificação como spec de arquitetura. Onde R - rules engine; onde A - chamada do modelo com confidence-capture; onde H - tarefa em fila humana. O registro especifica diretamente o [Decision Layer](/br/revista/decision-layer-explicado/) - a camada entre agente e sistema-alvo que orquestra decisões baseadas em regras e de IA, gera o audit-trail e roteia escalações.

A **representação dos trabalhadores** (sindicatos/CRE; PT: Comissão de Trabalhadores) lê os mesmos dados como modelo de cogestão. Vê quais decisões são automatizadas, com qual raciocínio, com qual escalação. Um acordo coletivo-quadro pode ser derivado diretamente da auditoria, frequentemente mais rápido que negociar acordos específicos por domínio.

O **auditor** lê versões de regra e especificações do audit-trail como integridade de prova. Qual regra aplicou-se quando, sobre quais dados, quem decidiu. A resposta está no registro, não em um documento separado de compliance.

A **autoridade de proteção de dados** (ANPD no Brasil, CNPD em Portugal) lê os mesmos dados como documentação EU AI Act, LGPD e RGPD. [Art. 11 (documentação técnica)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689#art_11), [Art. 12 (registro)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689#art_12), [Art. 86 (direito à explicação)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689#art_86) do EU AI Act e [Art. 20 da LGPD](https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm) exigem exatamente essa informação.

Quatro funções de um único documento. A auditoria não as produz como subproduto - é construída para isso.

## Contestabilidade é arquitetura, não anexo de compliance

Uma decisão automatizada sobre uma pessoa é admissível sob o EU AI Act, a LGPD (art. 20) e o RGPD apenas se a pessoa afetada puder contestá-la. Contestabilidade não é um dever parafusado depois - é um requisito arquitetônico planejado desde a primeira auditoria.

Por ponto de decisão a auditoria fornece quatro respostas que em conjunto viabilizam a contestação. Qual regra ou qual modelo decidiu, em qual versão? Sem versionamento a reprodução posterior é impossível. Quais dados serviram de base à decisão - os inputs exatos no momento da decisão, não os de hoje? Quem decidiu - humano, regra ou IA - e com qual confiança? Como a pessoa pode apresentar recurso - com endereço concreto, prazo e próxima instância?

Uma consequência da arquitetura: o agente em si não toma "decisões" em sentido jurídico. Executa operações que o Decision Layer autorizou. Não é preciosismo semântico. É a base que mantém as decisões auditáveis quando o modelo de IA é substituído, o fornecedor é trocado ou uma falha no modelo é descoberta.

A classificação de alto risco do EU AI Act atinge diretamente muitos workflows de RH: screening de recrutamento, gestão de desempenho, decisões de promoção e transferência, escalonamento de turnos quando influencia benefícios de pessoal (Anexo III nº 4 al. a e b). [Art. 26 par. 7](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689#art_26) obriga adicionalmente a informar a representação dos trabalhadores e os trabalhadores afetados **antes** da implantação - não depois. A auditoria precisa, portanto, responder adicionalmente por workflow: este workflow se enquadra no Anexo III? Se sim - somam-se as obrigações dos art. 11, art. 14, art. 15 e art. 26, e a informação prévia é condição para entrar em produção.

Para organizações fora da UE: os requisitos que o EU AI Act lista explicitamente já são exigíveis em quase todo sistema jurídico como interpretação de deveres gerais de diligência - apenas sem uma lista clara de obrigações. [Quem constrói o Decision Layer em conformidade com o EU AI Act](/br/revista/eu-ai-act-vale-no-mundo-todo/) cumpre com isso também o que a ANPD brasileira, autoridades britânicas e californianas exigirão em caso de fiscalização.

## Quatro erros de classificação distorcem qualquer auditoria

**Uma regra com exceções que exigem julgamento é classificada como Tipo R.** "Horas extras a 150 %" soa baseado em regras. Mas: feriado a 200 %? Turno que cruza meia-noite em feriado? Contrato individual que sobrepõe a convenção? Quando exceções exigem julgamento, o caminho de exceção é Tipo H - mesmo que o caso padrão seja Tipo R. Solução limpa: caso padrão como R, ponto separado para tratamento de exceções como H ou A.

**Um resultado de IA não verificável é classificado como Tipo A.** "A IA avalia se o candidato tem fit cultural." Não é Tipo A - não há resposta correta verificável. Fit cultural é subjetivo. Tipo A exige verificabilidade: "a IA classificou este documento como atestado" pode ser validado por dois humanos no mesmo documento. Avaliações subjetivas são Tipo H - sempre.

**A decisão gatilho é confundida com a ação posterior.** "Detecção de padrão dispara processo BEM" - a detecção é Tipo R (limiar), mas o BEM contém decisões Tipo H (planejamento de retorno). A auditoria deve separar o gatilho do workflow disparado.

**Decisões implícitas são ignoradas.** "Verificamos o atestado" soa como um passo. Contém pelo menos três decisões: documento válido, completo, corresponde ao colaborador. A auditoria deve decompor até que cada ponto tenha exatamente uma pergunta e uma classificação.

## O que esta metodologia não resolve

A auditoria entrega Agent Readiness no nível de ponto de decisão e a especificação do Decision Layer. Não entrega: sequenciamento entre workflows (depende do volume de transações, complexidade de governança, apetite organizacional; ver a [lógica H1-H4 no catálogo de agentes RH](/br/catalogo-agentes-hr/#sequencing-matrix)), seleção de tecnologia, mudança organizacional ou estratégia de negociação com a representação dos trabalhadores. A implementação concreta do Decision Layer - rules engine, confidence capture, endpoint de contestação - é tema separado.

A auditoria fornece a base factual. Estratégia e implementação constroem sobre ela. Quem começa pela estratégia e olha a base factual depois, constrói a pirâmide na ponta.

## Artigos relacionados

- [O EU AI Act vale no mundo todo](/br/revista/eu-ai-act-vale-no-mundo-todo/) - por que o dever de contestabilidade não nasce apenas com o prazo de alto risco (2 de agosto de 2026, adiamento para dezembro de 2027 acordado provisoriamente - Digital Omnibus, maio de 2026)
- [Três tipos de decisões: Quando o humano, quando a IA](/br/revista/tres-tipos-de-decisoes/) - a base conceitual da classificação H/R/A
- [Decision Layer como padrão arquitetônico](/br/revista/decision-layer-explicado/) - como a classificação é transferida para uma camada executável
- [EU AI Act e RH: classificação de alto risco](/br/revista/eu-ai-act-hr-alto-risco/) - quais workflows de RH se enquadram no Anexo III

--- Segurança web: padrões CERT.br e LGPD ---
> Seu site está em conformidade? Verificação de segurança para empresas. Identificar vulnerabilidades, atender requisitos da LGPD.

<!-- O que exigem os padrões? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">O que exigem os padrões de segurança no Brasil?</h2>
<p class="text-body text-gosign-text leading-relaxed">
O Marco Civil da Internet e a LGPD (Lei Geral de Proteção de Dados) (PT: RGPD) exigem medidas adequadas de segurança da informação para todas as empresas que operam no ambiente digital brasileiro. Operadores de infraestruturas críticas possuem obrigações adicionais. As recomendações do CERT.br (Centro de Estudos, Resposta e Tratamento de Incidentes de Segurança) são o padrão de referência para segurança de TI no Brasil. A Gosign verifica o seu site quanto a vulnerabilidades relevantes conforme esses padrões.
</p>
</div>
</section>

<!-- Tabela de verificação -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">O que a Gosign verifica em uma auditoria de segurança web</h2>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse bg-white rounded-card">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Área de verificação</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">O que é verificado</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Relevância</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Configuração HTTPS/TLS</td>
<td class="py-3 px-4 text-body text-gosign-text">Certificado, versão do protocolo, Cipher Suites</td>
<td class="py-3 px-4 text-body text-gosign-text">CERT.br / LGPD</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Content Security Policy</td>
<td class="py-3 px-4 text-body text-gosign-text">Header CSP, proteção contra XSS</td>
<td class="py-3 px-4 text-body text-gosign-text">CERT.br</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Headers do servidor</td>
<td class="py-3 px-4 text-body text-gosign-text">X-Frame-Options, HSTS, Referrer-Policy</td>
<td class="py-3 px-4 text-body text-gosign-text">CERT.br</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Versão do CMS &amp; extensions</td>
<td class="py-3 px-4 text-body text-gosign-text">Vulnerabilidades conhecidas, software descontinuado</td>
<td class="py-3 px-4 text-body text-gosign-text">CERT.br / LGPD</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Configuração de cookies</td>
<td class="py-3 px-4 text-body text-gosign-text">Flag Secure, HttpOnly, SameSite</td>
<td class="py-3 px-4 text-body text-gosign-text">LGPD + CERT.br</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Autenticação</td>
<td class="py-3 px-4 text-body text-gosign-text">Proteção de login, prevenção de força bruta, 2FA</td>
<td class="py-3 px-4 text-body text-gosign-text">CERT.br / LGPD</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Backup de dados</td>
<td class="py-3 px-4 text-body text-gosign-text">Estratégia de backup, teste de recuperação</td>
<td class="py-3 px-4 text-body text-gosign-text">CERT.br / LGPD</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Serviços -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">Serviços</h2>
<div class="grid md:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Verificação de segurança pontual</h3>
<p class="text-body text-gosign-text">
Verificação automatizada + manual. Relatório de resultados com recomendações de ação, priorizadas por risco. Acelerado por IA: resultados em horas, não semanas.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Monitoramento contínuo</h3>
<p class="text-body text-gosign-text">
Monitoramento constante de CMS, extensions e configuração do servidor. Notificação imediata em caso de novas vulnerabilidades.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Fortalecimento &amp; implementação</h3>
<p class="text-body text-gosign-text">
A Gosign implementa as medidas recomendadas: headers CSP, configuração TLS, setup de WAF, fortalecimento do CMS.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Documentação para auditorias</h3>
<p class="text-body text-gosign-text">
Documentação das medidas de segurança do seu site em conformidade com padrões CERT.br e LGPD. Para auditorias internas e auditores externos.
</p>
</div>
</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Verificar a segurança do seu site - 30&nbsp;minutos, gratuito.</h3>
<p class="text-body text-gosign-text mb-6">Analisamos seu site quanto a vulnerabilidades de segurança, sem compromisso.</p>
<a
href="/br/contato/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Solicitar verificação de segurança
</a>
<p class="text-small text-gosign-text-light mt-4">25 anos de experiência · 800+ extensions · Desenvolvimento acelerado por IA</p>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
A Gosign é uma agência digital de Hamburgo com 25 anos de experiência em desenvolvimento web, TYPO3 e integração de IA.
Analisamos mais de 800 extensions TYPO3 e hoje desenvolvemos com suporte de IA
até 70% mais rápido do que com métodos tradicionais. A partir do hub europeu em Hamburgo,
atendemos empresas brasileiras e latino-americanas que buscam excelência digital.
</p>
<p class="text-small text-gosign-text-light mt-2">Atualizado em: fevereiro de 2026</p>
</div>
</section>

<!-- Temas relacionados -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Temas relacionados</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/br/site-hackeado-10-motivos/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Segurança</p>
<p class="text-body font-semibold text-gosign-dark">Site hackeado: 10 motivos</p>
</a>
<a href="/br/typo3-monitor-seguranca/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Monitoramento</p>
<p class="text-body font-semibold text-gosign-dark">Monitor de segurança TYPO3</p>
</a>
<a href="/br/typo3-extensions/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">CMS</p>
<p class="text-body font-semibold text-gosign-dark">TYPO3 Extensions</p>
</a>
</div>
</div>
</section>

--- Finance Agent - Decision Automation para Processamento de Documentos ---
> Processamento automatizado de documentos com decisões auditáveis. Regras determinísticas, Audit Trail, integração TOTVS e SAP.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/br/por-que-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Cada decisão rastreável</p>
</div>
</a>
<a href="/br/por-que-gosign/#infraestrutura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Sua infraestrutura</p>
<p class="text-xs text-gosign-text-light">Sem SaaS. Sem vendor lock-in.</p>
</div>
</a>
<a href="/br/por-que-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Sem risco de cloud americana</p>
</div>
</a>
</div>
</div>
</div>

<!-- O Problema -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">O Problema</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
No processamento de documentos, pessoas tomam centenas de micro-decisões diariamente: conta contábil, centro de custo, início de depreciação, dedução de IVA. Cada decisão baseia-se em regras - legislação fiscal, normas contábeis, diretrizes internas, particularidades por cliente.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
O problema não é falta de conhecimento. É inconsistência: diferentes especialistas aplicam as mesmas regras de forma diferente. Mais clientes, mais localidades, mais pessoal - maior variância.
</p>
</div>
</section>

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">eBook gratuito: IA em Finanças</p>
<p class="text-body text-gosign-text mb-4">Conformidade, auditores externos e Decision Layer - o manual de governança para liderança financeira.</p>
<a href="/br/ebook/ia-financas-manual-governanca/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Baixar grátis</a>
</div>

<!-- Decision Automation -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Decision Automation</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
O Finance Agent não é uma ferramenta OCR. É um sistema de Decision Automation que decide com base em conjuntos de regras versionados.
</p>
<div class="mt-6 space-y-2">
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">1. Ler e compreender documentos</strong> - com compreensão linguística real</p>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">2. Avaliar profissionalmente</strong> - conta, centro de custo, classificação fiscal</p>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">3. Decidir</strong> - O <a href="/br/decision-layer/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Decision Layer</a> roteia: autônomo com alta confiança, humano para exceções</p>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">4. Documentar</strong> - Cada micro-decisão gera um registro completo</p>
</div>
</div>
<div class="mt-8">
<pre class="bg-gosign-dark text-white p-6 rounded-card overflow-x-auto text-small font-mono leading-relaxed"><code>Documento     →  Agente lê      →  Decision Layer
entrante         e compreende      verifica regras
│
┌────────────┴────────────┐
│                         │
Alta confiança           Baixa confiança
Regra clara              ou exceção
│                         │
Proposta de              Consulta a
contabilização           especialista
│                         │
Exportar para            Workflow pausado
TOTVS / SAP
│                         │
Audit Trail              Audit Trail
completo                 completo</code></pre>
</div>
</div>
</section>

<!-- Conjuntos de Regras -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Conjuntos de Regras</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Cada conjunto é um objeto de dados independente com versão, data de validade e escopo. Mudanças criam novas versões. Cada decisão referencia a versão aplicada. Durante auditoria, é rastreável qual regra em qual versão se aplicava.
</p>
</div>
</section>

<!-- Cert-Ready -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Cert-Ready by Design</h2>
<div class="mt-6 space-y-4">
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Portal de Auditor:</strong> Status em tempo real de todos os controles com drill-down.</p>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Registro por documento:</strong> Rota de decisão completa, não apenas resultado.</p>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Mapeamento de frameworks:</strong> ISA, PS 951, IDW, GoB/GoBD (padrão GoBD alemão de arquivamento fiscal). Parte da nossa abordagem <a href="/br/governance/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Governance by Design</a>.</p>
</div>
<p class="text-body-lg text-gosign-text-light mt-4">
<a href="/br/governance/cert-ready/" class="text-gosign-accent-text font-semibold hover:text-gosign-accent-hover">Cert-Ready by Design em detalhe</a>
</p>
</div>
</section>

<!-- Integração -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Integração</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Lógica contábil separada de exportação. Mudança de sistema destino muda a exportação - não o agente.
</p>
</div>
<div class="mt-8">
<div class="grid grid-cols-1 md:grid-cols-2 gap-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">TOTVS</h3>
<p class="text-body text-gosign-text-light mt-2">Propostas em formato TOTVS, conforme normas contábeis brasileiras (CPC/CFC).</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">SAP FI/CO</h3>
<p class="text-body text-gosign-text-light mt-2">Propostas em formato SAP, centros de custo e lucro.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">finAPI / Banking</h3>
<p class="text-body text-gosign-text-light mt-2">Processamento automático de extratos bancários.</p>
</div>
</div>
</div>
</div>
</section>

<!-- Grupos Alvo -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Grupos Alvo</h2>
<div class="mt-6 space-y-4">
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Firmas de auditoria e contabilidade:</strong> Consistência entre centenas de clientes.</p>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Centros de serviços compartilhados:</strong> Onde a decisão é determinística, regras específicas por cliente são aplicadas de forma consistente. Onde o agente tem confiança suficiente: decide autonomamente - interpreta, classifica, avalia contexto.</p>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Empresas com contabilidade interna:</strong> Menos contabilizações corretivas, documentação completa.</p>
</div>
</div>
</section>

<!-- Impacto de Negócio -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Impacto de Negócio</h2>
<div class="mt-6 space-y-4">
<p class="text-body-lg text-gosign-text-light">Reduzir contabilizações corretivas mediante aplicação consistente.</p>
<p class="text-body-lg text-gosign-text-light">Encurtar tempos de processamento com automação de rotina.</p>
<p class="text-body-lg text-gosign-text-light">Reduzir risco de auditoria com documentação completa.</p>
<p class="text-body-lg text-gosign-text-light">Tornar regras explícitas em vez de armazenadas em mentes individuais.</p>
<p class="text-body-lg text-gosign-text-light">Escalar sem aumento proporcional de pessoal.</p>
</div>
</div>
</section>

<!-- Aprofundamento no Agent Briefing -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Aprofundamento no Agent Briefing (Revista Gosign)</h2>
<p class="text-body text-gosign-text-light mb-6">Nossa série de artigos para decisores que automatizam processos financeiros com AI Agents.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/br/revista/custos-ia-tco-comparacao/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Finance</p>
<p class="text-body font-semibold text-gosign-dark">Custos de IA comparados: Análise TCO para Enterprise</p>
</a>
<a href="/br/revista/decision-layer-shadow-ai/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer vs. Shadow AI: Por que Governance vem antes da velocidade</p>
</a>
<a href="/br/revista/deepseek-enterprise-hosting/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">Hosting AI: EU SaaS, data center alemão ou Self-Hosted?</p>
</a>
</div>
</div>
</section>

--- Co-Build - Agentes de IA individuais para o seu processo ---
> Co-Build: Seu processo, seu agente. Em 4-6 semanas da descoberta ao agente de IA produtivo com acesso ao código-fonte, Decision Layer e estratégia de saída.

<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Navegação AI Agents">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/br/servicos/ai-agents/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
AI Agents
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/br/servicos/ai-agents/document-agents/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Document</a>
<a href="/br/servicos/ai-agents/workflow-agents/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Workflow</a>
<a href="/br/servicos/ai-agents/knowledge-agents/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Knowledge</a>
<a href="/br/servicos/ai-agents/co-build/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Co-Build</a>
</div>
</div>
</nav>

<!-- Visão geral -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h2 font-bold text-gosign-dark">Visão geral</h2>
<div class="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-3 gap-4 mt-6">
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">4-6 semanas</p>
<p class="text-body text-gosign-text-light mt-1">Da descoberta ao agente produtivo em sua infraestrutura</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Código-fonte completo</p>
<p class="text-body text-gosign-text-light mt-1">Código, prompts, conjuntos de regras, documentação - acesso completo e direito de uso permanente</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Sem SaaS</p>
<p class="text-body text-gosign-text-light mt-1">Sem taxas mensais. Sem vendor lock-in. Operação autônoma possível.</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Decision Layer</p>
<p class="text-body text-gosign-text-light mt-1">Cada agente com audit trail, Human-in-the-Loop e versionamento de conjuntos de regras</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Agnóstico de modelos</p>
<p class="text-body text-gosign-text-light mt-1">Claude, ChatGPT, Gemini, Llama - intercambiáveis sem alteração de código</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Estratégia de saída</p>
<p class="text-body text-gosign-text-light mt-1">Treinamento, documentação, transferência. Totalmente autônomo após 12-18 meses.</p>
</div>
</div>
</div>
</div>
</section>

<!-- Três fases -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Três fases até o agente produtivo</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Cada Co-Build segue um processo estruturado. O resultado é um agente produtivo em sua infraestrutura - com código-fonte, documentação e estratégia de saída.
</p>
</div>
<div class="grid grid-cols-1 md:grid-cols-3 gap-6 mt-8 max-w-content">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Fase 1 - Semana 1</p>
<p class="text-h3 font-bold text-gosign-dark">Discover</p>
<ul class="mt-4 space-y-2 text-body text-gosign-text-light">
<li>Análise do processo com sua equipe especializada</li>
<li>Identificar e formalizar conjuntos de regras</li>
<li>Mapear pontos de decisão</li>
<li>Design do Decision Layer</li>
<li>Esclarecer paisagem de sistemas e integrações</li>
</ul>
<p class="text-body text-gosign-text-light mt-4 font-semibold">Resultado: Blueprint do processo com matriz de decisão</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Fase 2 - Semanas 2-5</p>
<p class="text-h3 font-bold text-gosign-dark">Build</p>
<ul class="mt-4 space-y-2 text-body text-gosign-text-light">
<li>Desenvolvimento do agente com sua equipe</li>
<li>Implementar o Decision Layer</li>
<li>Conjuntos de regras como configuração versionada</li>
<li>Integração de sistemas (SAP, TOTVS etc.)</li>
<li>Testes com dados reais</li>
</ul>
<p class="text-body text-gosign-text-light mt-4 font-semibold">Resultado: Agente produtivo em sua infraestrutura</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Fase 3 - Semanas 5-6</p>
<p class="text-h3 font-bold text-gosign-dark">Transfer</p>
<ul class="mt-4 space-y-2 text-body text-gosign-text-light">
<li>Entrega do código-fonte</li>
<li>Treinamento da equipe para operação autônoma</li>
<li>Documentação de código, prompts, conjuntos de regras</li>
<li>Configurar monitoramento e alertas</li>
<li>Documentar estratégia de saída</li>
</ul>
<p class="text-body text-gosign-text-light mt-4 font-semibold">Resultado: Sua equipe opera o agente de forma autônoma</p>
</div>
</div>
</div>
</section>

<!-- Para quais áreas -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Para quais áreas</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
O Co-Build é adequado para qualquer processo baseado em conjuntos de regras que atualmente é gerenciado manualmente por pessoas. Áreas típicas:
</p>
<div class="grid grid-cols-1 sm:grid-cols-2 gap-4 mt-6">
<div class="bg-gosign-light border border-gosign-border rounded-card p-4">
<p class="font-semibold text-gosign-dark text-body">Compliance e jurídico</p>
<p class="text-body text-gosign-text-light mt-1">Revisões regulatórias, revisão de contratos, extração de cláusulas, monitoramento de prazos.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-4">
<p class="font-semibold text-gosign-dark text-body">Operações e cadeia de suprimentos</p>
<p class="text-body text-gosign-text-light mt-1">Processos de pedidos, gestão de fornecedores, inspeção de qualidade, processamento de reclamações.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-4">
<p class="font-semibold text-gosign-dark text-body">Shared Services</p>
<p class="text-body text-gosign-text-light mt-1">Roteamento de tickets, classificação de solicitações, disponibilização interna de conhecimento, automação de service desk.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-4">
<p class="font-semibold text-gosign-dark text-body">Específico por setor</p>
<p class="text-body text-gosign-text-light mt-1">Controle de exportações, despacho aduaneiro, sinistros de seguros, avaliação de crédito - qualquer processo baseado em regras.</p>
</div>
</div>
</div>
</div>
</section>

<!-- O que você recebe -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">O que você recebe</h2>
<ul class="mt-6 space-y-3">
<li class="text-body-lg text-gosign-text-light"><strong>Código-fonte:</strong> Código completo do agente em seu repositório</li>
<li class="text-body-lg text-gosign-text-light"><strong>Prompts:</strong> Todas as cadeias de prompts e system prompts, documentados e versionados</li>
<li class="text-body-lg text-gosign-text-light"><strong>Conjuntos de regras:</strong> Regras de negócio como configuração versionada, não como hardcoding</li>
<li class="text-body-lg text-gosign-text-light"><strong>Decision Layer:</strong> Audit trail, Human-in-the-Loop, restrições do sindicato e conformidade com PL 2338/2023</li>
<li class="text-body-lg text-gosign-text-light"><strong>Documentação:</strong> Arquitetura, lógica de decisão, casos de teste, guia de implantação</li>
<li class="text-body-lg text-gosign-text-light"><strong>Estratégia de saída:</strong> Treinamento, protocolo de transferência, período de suporte</li>
</ul>
</div>
</div>
</section>

<!-- Comparação: Co-Build vs. SaaS vs. Inhouse -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Co-Build vs. SaaS vs. Inhouse</h2>
<div class="overflow-x-auto mt-6">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-dark">
<th class="py-3 pr-4 text-body font-bold text-gosign-dark"></th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Co-Build</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Plataforma SaaS</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Inhouse</th>
</tr>
</thead>
<tbody class="text-body text-gosign-text-light">
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Time-to-Value</td>
<td class="py-3 px-4">4-6 semanas</td>
<td class="py-3 px-4">2-4 semanas</td>
<td class="py-3 px-4">6-12 meses</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Acesso ao código-fonte</td>
<td class="py-3 px-4">Completo</td>
<td class="py-3 px-4">Sem acesso</td>
<td class="py-3 px-4">Completo</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Vendor Lock-in</td>
<td class="py-3 px-4">Nenhum</td>
<td class="py-3 px-4">Alto</td>
<td class="py-3 px-4">Nenhum</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Governance / Auditoria</td>
<td class="py-3 px-4">Decision Layer incluído</td>
<td class="py-3 px-4">Dependente da plataforma</td>
<td class="py-3 px-4">Precisa ser construído</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Custos contínuos</td>
<td class="py-3 px-4">Infraestrutura + manutenção opcional</td>
<td class="py-3 px-4">Licença mensal</td>
<td class="py-3 px-4">Custos de pessoal</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Personalização</td>
<td class="py-3 px-4">Ilimitada</td>
<td class="py-3 px-4">Dentro da plataforma</td>
<td class="py-3 px-4">Ilimitada</td>
</tr>
</tbody>
</table>
</div>
</div>
</div>
</section>

<!-- Cenário prático -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h2 font-bold text-gosign-dark">Cenário prático: Revisão de conformidade em um Shared Service Center</h2>
<p class="text-body-lg text-gosign-text-light mt-4">Um Shared Service Center revisa mensalmente 120 contratos de fornecedores quanto à conformidade - manualmente, com checklists no Excel.</p>
<div class="grid grid-cols-1 sm:grid-cols-2 gap-6 mt-8">
<div class="bg-gosign-white rounded-card p-6">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-3">Antes - manual</p>
<ul class="space-y-2 text-body text-gosign-text-light">
<li><strong>45 min</strong> por contrato (leitura, checklist, documentação)</li>
<li><strong>~90 horas/mês</strong> para a equipe</li>
<li><strong>12% de erros</strong> na detecção de cláusulas</li>
<li><strong>Sem versionamento</strong> da lógica de revisão</li>
</ul>
</div>
<div class="bg-gosign-white rounded-card p-6 border-2 border-gosign-accent">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-3">Depois - Co-Build Agent</p>
<ul class="space-y-2 text-body text-gosign-text-light">
<li><strong>82% autônomo</strong> revisado (contratos padrão)</li>
<li><strong>~19 horas/mês</strong> (apenas exceções + verificações pontuais)</li>
<li><strong>&lt;2% de erros</strong> por revisão baseada em regras</li>
<li><strong>Decision Layer</strong> com Audit Trail completo</li>
</ul>
</div>
</div>
<div class="bg-gosign-white rounded-card p-4 mt-6">
<p class="text-body text-gosign-text-light"><strong>Resultado:</strong> 71 horas economizadas por mês. Agente produtivo em 5 semanas. Código-fonte, conjunto de regras e prompts de propriedade do cliente. Operação independente após 14 meses sem suporte externo.</p>
</div>
</div>
</div>
</section>

<!-- Aprofundamento no Agent Briefing -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Aprofundamento no Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nossa série de artigos para decisores que implementam AI Agents na empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/br/revista/custos-ia-tco-comparacao/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Custos</p>
<p class="text-body font-semibold text-gosign-dark">O que a IA realmente custa: comparação TCO para empresas</p>
</a>
<a href="/br/revista/modelo-agnostico-vendor-lock-in/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Arquitetura</p>
<p class="text-body font-semibold text-gosign-dark">Arquitetura model-agnostic - por que o Vendor Lock-in com LLMs é perigoso</p>
</a>
<a href="/br/revista/decision-layer-explicado/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - o que é e por que cada Enterprise AI Agent precisa de um</p>
</a>
</div>
</div>
</section>

<!-- Outros tipos de agentes -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Outros tipos de agentes</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/br/servicos/ai-agents/document-agents/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">O especialista</p>
<p class="text-body font-semibold text-gosign-dark">Document Agents</p>
<p class="text-body text-gosign-text-light mt-2">Ler, compreender e classificar documentos - com verdadeira compreensão linguística.</p>
</a>
<a href="/br/servicos/ai-agents/workflow-agents/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">O coordenador</p>
<p class="text-body font-semibold text-gosign-dark">Workflow Agents</p>
<p class="text-body text-gosign-text-light mt-2">Orquestrar processos entre sistemas - SAP, TOTVS, SharePoint.</p>
</a>
<a href="/br/servicos/ai-agents/knowledge-agents/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">O portador de conhecimento</p>
<p class="text-body font-semibold text-gosign-dark">Knowledge Agents</p>
<p class="text-body text-gosign-text-light mt-2">Responder perguntas a partir de conjuntos de regras - com referência a fontes e versão das regras.</p>
</a>
</div>
</div>
</section>

--- Document Agents - Gestão Documental com Decision Layer ---
> Document Agents leem, compreendem e processam documentos empresariais. Notas fiscais, atestados, contratos - auditáveis, com Audit Trail.

<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="AI Agents Navegação">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/br/servicos/ai-agents/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
AI Agents
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/br/servicos/ai-agents/document-agents/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Document</a>
<a href="/br/servicos/ai-agents/workflow-agents/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Workflow</a>
<a href="/br/servicos/ai-agents/knowledge-agents/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Knowledge</a>
<a href="/br/servicos/ai-agents/co-build/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Co-Build</a>
</div>
</div>
</nav>

<!-- Visão geral -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h2 font-bold text-gosign-dark">Visão geral</h2>
<div class="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-3 gap-4 mt-6">
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">99,1% Zero-Touch</p>
<p class="text-body text-gosign-text-light mt-1">Documentos rotineiros processados de forma autônoma - sem retrabalho manual</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">20+ tipos de documento</p>
<p class="text-body text-gosign-text-light mt-1">Notas fiscais, contratos, atestados, decisões tributárias, recibos e mais</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Compreensão real</p>
<p class="text-body text-gosign-text-light mt-1">Compreensão linguística contextual em vez de OCR com correspondência de templates</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Decision Layer</p>
<p class="text-body text-gosign-text-light mt-1">Cada extração com Confidence Score, versão da regra e Audit Trail</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Agnóstico em modelos</p>
<p class="text-body text-gosign-text-light mt-1">Claude, ChatGPT, Gemini, Llama - modelo intercambiável</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">SAP, TOTVS, Workday</p>
<p class="text-body text-gosign-text-light mt-1">Integração via APIs - lógica do agent desacoplada do sistema destino</p>
</div>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Definição: Document Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Um Document Agent é um AI Agent especializado para o processamento automático de documentos empresariais. Utiliza Large Language Models (LLM) para compreensão linguística contextual - não correspondência de templates, não regras OCR rígidas.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
O Document Agent lê um documento, compreende seu conteúdo e realiza uma avaliação profissional. Esta avaliação é verificada pelo <a href="/br/decision-layer/" class="text-gosign-accent-text hover:underline">Decision Layer</a>, documentada e registrada no Audit Trail.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Como Funciona o Document Agent</h2>
<pre class="bg-gosign-dark text-white p-6 rounded-card overflow-x-auto text-small font-mono leading-relaxed mt-4"><code>Documento   →  Agent lê        →  Decision Layer verifica
(Nota Fiscal)  e compreende       Completude, Plausibilidade,
Classificação tributária
│
┌────────────┴────────────┐
│                         │
Alta confiança           Baixa confiança
Regra clara             ou caso excepcional
│                         │
Proposta de              Escalação para
contabilização           funcionário
│                         │
Audit Trail              Audit Trail
documenta                documenta</code></pre>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Quais Documentos o Document Agent Processa</h2>
<div class="mt-6 space-y-4">
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Finance:</strong> Notas fiscais, notas de crédito, recibos, comprovantes de pagamento, extratos bancários.</p>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">RH:</strong> Atestados médicos, contratos de trabalho, aditivos contratuais, certificados, cartas de referência.</p>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Compliance:</strong> Documentos tributários, certificações, declarações, documentos de auditoria.</p>
</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Decision Layer para Documentos</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Cada processamento de documento gera um registro de decisão completo:
</p>
<ul class="mt-6 space-y-3">
<li class="text-body-lg text-gosign-text-light"><strong>Entrada:</strong> Hash do documento, tipo de documento, campos extraídos</li>
<li class="text-body-lg text-gosign-text-light"><strong>Conjunto de regras:</strong> Regra aplicada, versão, marca temporal</li>
<li class="text-body-lg text-gosign-text-light"><strong>Avaliação:</strong> Confidence Score, indicador de risco</li>
<li class="text-body-lg text-gosign-text-light"><strong>Resultado:</strong> Proposta de contabilização ou escalação</li>
<li class="text-body-lg text-gosign-text-light"><strong>Routing:</strong> Decisão autônoma ou Human-in-the-Loop</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-4">
O Document Agent não substitui funcionários. Processa os casos rotineiros de forma autônoma e escala exceções para humanos, com documentação completa. Saiba mais sobre a <a href="/br/decision-layer/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">arquitetura do Decision Layer</a>.
</p>
</div>
</section>

<!-- Comparação: Document Agent vs. solução clássica -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Document Agent vs. OCR vs. processamento manual</h2>
<div class="overflow-x-auto mt-6">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-dark">
<th class="py-3 pr-4 text-body font-bold text-gosign-dark"></th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Document Agent</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Sistema OCR</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Processamento manual</th>
</tr>
</thead>
<tbody class="text-body text-gosign-text-light">
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Compreensão</td>
<td class="py-3 px-4">Contextual - compreende conteúdo e significado</td>
<td class="py-3 px-4">Reconhecimento de caracteres + correspondência de templates</td>
<td class="py-3 px-4">Capacidade cognitiva plena</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Texto livre / manuscrito</td>
<td class="py-3 px-4">Sim - compreensão linguística real</td>
<td class="py-3 px-4">Limitado - falha em desvios</td>
<td class="py-3 px-4">Sim</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Velocidade</td>
<td class="py-3 px-4">Segundos por documento</td>
<td class="py-3 px-4">Segundos, mas frequentemente requer retrabalho</td>
<td class="py-3 px-4">5-10 minutos por documento</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Escalabilidade</td>
<td class="py-3 px-4">Linear com o volume</td>
<td class="py-3 px-4">Linear, mas manual em erros</td>
<td class="py-3 px-4">Apenas com mais pessoal</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Audit Trail</td>
<td class="py-3 px-4">Automático por decisão</td>
<td class="py-3 px-4">Limitado</td>
<td class="py-3 px-4">Manual, frequentemente incompleto</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Cenário prático -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Prática: Notas fiscais recebidas</h2>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6 mt-6">
<p class="font-semibold text-gosign-dark text-body">Cenário: 500 notas fiscais recebidas por mês</p>
<div class="grid grid-cols-1 sm:grid-cols-2 gap-6 mt-4">
<div>
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-text-light mb-2">Antes (manual)</p>
<ul class="space-y-1 text-body text-gosign-text-light">
<li>8 minutos por nota fiscal (análise, contabilização, verificação)</li>
<li>~67 horas por mês</li>
<li>Taxa de erros na contabilização: 4-6%</li>
<li>Audit Trail: planilha Excel, mantida manualmente</li>
</ul>
</div>
<div>
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Depois (Document Agent)</p>
<ul class="space-y-1 text-body text-gosign-text-light">
<li>99,1% processados autonomamente (495 de 500 notas fiscais)</li>
<li>&lt;1% escalados para funcionários (~5 notas fiscais/mês)</li>
<li>98% de todas as consultas com o remetente do documento resolvidas autonomamente</li>
<li>&lt;0,5h de esforço manual por mês</li>
<li>Taxa de erros: abaixo de 0,3% (contabilização baseada em regras)</li>
</ul>
</div>
</div>
<p class="text-body text-gosign-text-light mt-4">
<strong>Resultado:</strong> De 67 horas para menos de 30 minutos por mês. O agente contabiliza, verifica e registra de forma autônoma. Quando faltam informações (p. ex. número do pedido, centro de custos), o agente contata diretamente o remetente do documento - 98% dessas consultas são resolvidas sem intervenção humana. Apenas exceções genuínas chegam ao funcionário.
</p>
<div class="mt-4 bg-gosign-light border-l-4 border-gosign-accent rounded-card p-4">
<p class="text-small font-semibold text-gosign-dark">Human-in-the-Loop</p>
<p class="text-small text-gosign-text-light mt-1"><strong>O agente decide:</strong> Contabilização, proposta de registro, condições de pagamento, consultas ao remetente do documento.<br/><strong>O humano decide:</strong> Primeira aprovação de fornecedor, notas fiscais acima do limite de aprovação, desvios do valor do pedido &gt;5%.</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Áreas de Aplicação</h2>
<div class="mt-6 space-y-6">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Finance e Contabilidade</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Processamento de notas fiscais, contabilização, verificação de documentos. Integração com TOTVS e SAP FI/CO. Solução pré-configurada: <a href="/br/finance-ai-agents/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Finance AI Agents</a>.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">RH e People Operations</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Atestados médicos, documentos contratuais, certificados. Integração com SAP SuccessFactors e Workday. Solução pré-configurada: <a href="/br/hr-ai-agents/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">HR AI Agents</a>.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Compliance e Auditoria</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Verificação automática de documentos recebidos contra políticas internas e regulações externas (LGPD (PT: RGPD)). O <a href="/br/decision-layer/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Decision Layer</a> documenta cada decisão de verificação.
</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Integração</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Document Agents se conectam a sistemas existentes por interfaces padronizadas:
</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light">SAP FI/CO, SAP S/4HANA</li>
<li class="text-body-lg text-gosign-text-light">TOTVS</li>
<li class="text-body-lg text-gosign-text-light">SAP SuccessFactors, Workday</li>
<li class="text-body-lg text-gosign-text-light">SharePoint, Microsoft Teams</li>
<li class="text-body-lg text-gosign-text-light">Caixas de e-mail (IMAP/Exchange)</li>
<li class="text-body-lg text-gosign-text-light">Outros via REST/SOAP</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-4">
A lógica do agent é desacoplada do sistema destino. Uma troca de ERP altera a camada de exportação, não o agent. Precisa de um agente para um processo não coberto pelos três tipos padrão? <a href="/br/servicos/ai-agents/co-build/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Co-Build</a> entrega agentes personalizados em 4-6 semanas.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Outros tipos de agente</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/br/servicos/ai-agents/workflow-agents/" class="group block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">O Coordenador</p>
<p class="text-body font-semibold text-gosign-dark">Workflow Agents</p>
<p class="text-body text-gosign-text-light mt-2">Orquestração de processos entre sistemas - SAP, TOTVS, SharePoint.</p>
<span class="inline-flex items-center gap-1 mt-4 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Detalhes <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
<a href="/br/servicos/ai-agents/knowledge-agents/" class="group block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">O Portador de Conhecimento</p>
<p class="text-body font-semibold text-gosign-dark">Knowledge Agents</p>
<p class="text-body text-gosign-text-light mt-2">Respostas baseadas em regras - com fonte e versão da regra.</p>
<span class="inline-flex items-center gap-1 mt-4 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Detalhes <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
<a href="/br/servicos/ai-agents/co-build/" class="group block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Agentes individuais</p>
<p class="text-body font-semibold text-gosign-dark">Co-Build</p>
<p class="text-body text-gosign-text-light mt-2">Seu processo, seu agente. 4-6 semanas até um agente produtivo.</p>
<span class="inline-flex items-center gap-1 mt-4 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Detalhes <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Aprofundamento no Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nossa série de artigos para executivos que implementam agentes de IA na empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/br/revista/rag-document-intelligence-enterprise/" class="group block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">RAG e Document Intelligence: Como a IA entende seus documentos</p>
<span class="inline-flex items-center gap-1 mt-3 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Ler <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
<a href="/br/revista/pii-anonimizacao-llm-enterprise/" class="group block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Segurança</p>
<p class="text-body font-semibold text-gosign-dark">Anonimizacao de PII para IA Empresarial</p>
<span class="inline-flex items-center gap-1 mt-3 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Ler <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
<a href="/br/revista/decision-layer-explicado/" class="group block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - O que é por que todo agente AI enterprise precisa de um</p>
<span class="inline-flex items-center gap-1 mt-3 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Ler <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
</div>
</div>
</section>

--- Knowledge Agents - Respostas do Conhecimento Corporativo ---
> Knowledge Agents fornecem respostas contextuais de regulamentos internos, políticas e acordos coletivos. Com fonte, versão da regra e Audit Trail.

<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="AI Agents Navegação">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/br/servicos/ai-agents/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
AI Agents
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/br/servicos/ai-agents/document-agents/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Document</a>
<a href="/br/servicos/ai-agents/workflow-agents/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Workflow</a>
<a href="/br/servicos/ai-agents/knowledge-agents/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Knowledge</a>
<a href="/br/servicos/ai-agents/co-build/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Co-Build</a>
</div>
</div>
</nav>

<!-- Visão geral -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h2 font-bold text-gosign-dark">Visão geral</h2>
<div class="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-3 gap-4 mt-6">
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Fontes verificadas</p>
<p class="text-body text-gosign-text-light mt-1">Cada resposta com referência da fonte, versão da regra e data de validade</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">5 anti-alucinação</p>
<p class="text-body text-gosign-text-light mt-1">Retrieval-First, verificação de fonte, Confidence, sem especulação, Audit Trail</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">4 canais</p>
<p class="text-body text-gosign-text-light mt-1">Teams Bot, SharePoint, interface web, API - onde seus colaboradores trabalham</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">RAG Pipeline</p>
<p class="text-body text-gosign-text-light mt-1">Indexação versionada de todas as fontes de conhecimento com atualização automática</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Decision Layer</p>
<p class="text-body text-gosign-text-light mt-1">Confidence Scoring e routing - em caso de incerteza, encaminhamento em vez de resposta</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Resposta imediata</p>
<p class="text-body text-gosign-text-light mt-1">Segundos em vez de horas - consistente em todas as unidades e fusos horários</p>
</div>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Definição: Knowledge Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Um Knowledge Agent é um AI Agent especializado que fornece respostas contextuais do conhecimento corporativo. Utiliza um pipeline RAG (Retrieval-Augmented Generation) para encontrar informações relevantes em documentos depositados e responder no contexto correto.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Princípio central: cada resposta inclui a referência da fonte e a versão da regra. Um Knowledge Agent nunca responde uma pergunta sem referência de fonte.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Princípio: Sem Fonte Não Há Resposta</h2>
<pre class="bg-gosign-dark text-white p-6 rounded-card overflow-x-auto text-small font-mono leading-relaxed mt-4"><code>Pergunta    →  Knowledge Agent    →  Decision Layer
(funcionário)  pesquisa na base      verifica fonte
de conhecimento       e confiança
│
┌────────────┴────────────┐
│                         │
Fonte encontrada          Sem fonte ou
Confiança alta            regras contraditórias
│                         │
Resposta com fonte        Encaminha ao
e versão da regra         departamento responsável
│                         │
Audit Trail               Audit Trail</code></pre>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Fontes de Conhecimento Suportadas</h2>
<div class="mt-6 space-y-4">
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">RH:</strong> Regulamentos internos, acordos coletivos (CLT), políticas de férias, regimentos internos.</p>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Finance:</strong> Regras contábeis, políticas de viagem, processos de aprovação.</p>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Compliance:</strong> Manuais de compliance, diretrizes de proteção de dados (LGPD (PT: RGPD)), processos de auditoria.</p>
</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Segurança Arquitetônica contra Alucinação</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Os Knowledge Agents são projetados para que o risco de alucinação seja minimizado arquitetonicamente:
</p>
<ol class="mt-6 space-y-3 list-decimal list-inside">
<li class="text-body-lg text-gosign-text-light"><strong>Retrieval-First:</strong> O agent pesquisa primeiro os documentos relevantes antes de responder</li>
<li class="text-body-lg text-gosign-text-light"><strong>Verificação de fonte:</strong> Cada afirmação deve ser rastreável a uma fonte concreta</li>
<li class="text-body-lg text-gosign-text-light"><strong>Confidence Score:</strong> Com baixa confiança, nenhuma resposta é dada, mas sim um encaminhamento ao departamento responsável</li>
<li class="text-body-lg text-gosign-text-light"><strong>Sem especulação:</strong> Quando a informação está ausente ou é contraditória, o agent encaminha ao departamento responsável</li>
<li class="text-body-lg text-gosign-text-light"><strong>Audit Trail:</strong> Cada resposta é documentada com fonte, versão e confiança</li>
</ol>
</div>
</section>

<!-- Comparação: Knowledge Agent vs. solução clássica -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Knowledge Agent vs. buscador empresarial vs. chatbot padrão</h2>
<div class="overflow-x-auto mt-6">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-dark">
<th class="py-3 pr-4 text-body font-bold text-gosign-dark"></th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Knowledge Agent</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Buscador empresarial</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Chatbot padrão</th>
</tr>
</thead>
<tbody class="text-body text-gosign-text-light">
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Resultado</td>
<td class="py-3 px-4">Resposta específica com fonte</td>
<td class="py-3 px-4">Lista de documentos</td>
<td class="py-3 px-4">Resposta gerada sem garantia de fonte</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Referência da fonte</td>
<td class="py-3 px-4">Sempre - com versão e validade</td>
<td class="py-3 px-4">Link para o documento</td>
<td class="py-3 px-4">Nenhuma ou não confiável</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Alucinação</td>
<td class="py-3 px-4">Prevenida arquitetonicamente (5 medidas)</td>
<td class="py-3 px-4">Não aplicável</td>
<td class="py-3 px-4">Frequente - sem controle</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Em caso de incerteza</td>
<td class="py-3 px-4">Encaminha ao departamento responsável</td>
<td class="py-3 px-4">Exibe mais resultados</td>
<td class="py-3 px-4">Responde mesmo assim</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Audit Trail</td>
<td class="py-3 px-4">Completo por resposta</td>
<td class="py-3 px-4">Protocolo de busca</td>
<td class="py-3 px-4">Histórico de chat</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Cenário prático -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Prática: Consultas de RH</h2>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6 mt-6">
<p class="font-semibold text-gosign-dark text-body">Cenário: 200 consultas de RH por mês (direitos de férias, regulações especiais, regulamentos internos)</p>
<div class="grid grid-cols-1 sm:grid-cols-2 gap-6 mt-4">
<div>
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-text-light mb-2">Antes (manual)</p>
<ul class="space-y-1 text-body text-gosign-text-light">
<li>15 minutos por consulta (RH pesquisa, verifica regulamento, responde)</li>
<li>~50 horas por mês</li>
<li>Respostas inconsistentes dependendo do analista</li>
<li>Tempo de espera para colaboradores: horas a dias</li>
</ul>
</div>
<div>
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Depois (Knowledge Agent)</p>
<ul class="space-y-1 text-body text-gosign-text-light">
<li>78% respondidas imediatamente (156 consultas) - segundos em vez de horas</li>
<li>22% escaladas ao RH (44 casos complexos) - com contexto</li>
<li>~11 horas por mês (apenas escalações)</li>
<li>100% consistência na interpretação de regras</li>
</ul>
</div>
</div>
<p class="text-body text-gosign-text-light mt-4">
<strong>Resultado:</strong> 39 horas por mês economizadas. Colaboradores recebem imediatamente uma resposta verificada. O RH se concentra nos casos complexos que exigem julgamento real.
</p>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Áreas de Aplicação</h2>
<div class="mt-6 space-y-6">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">RH e People Operations</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Perguntas sobre regulamentos internos, acordos coletivos (CLT), direitos de férias, regulações especiais, licença parental, orçamentos de treinamento. Fim do princípio de "pergunte a alguém do escritório".
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Compliance e Regulação</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Perguntas sobre políticas internas, requisitos regulatórios, controle de exportações, proteção de dados (LGPD). Respostas consistentes em vez de interpretação individual.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Onboarding</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Novos funcionários obtêm acesso imediato ao conhecimento corporativo relevante, sem esperar por colegas disponíveis.
</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Integração</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Os Knowledge Agents são acessíveis pelos seguintes canais:
</p>
<ul class="mt-4 space-y-3">
<li class="text-body-lg text-gosign-text-light"><strong>Microsoft Teams Bot</strong> - diretamente no trabalho diário</li>
<li class="text-body-lg text-gosign-text-light"><strong>Integração com SharePoint</strong> - integrado na intranet</li>
<li class="text-body-lg text-gosign-text-light"><strong>Interface web</strong> - independente para consultas complexas</li>
<li class="text-body-lg text-gosign-text-light"><strong>API</strong> - para integração em aplicações próprias</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-4">
A base de conhecimento é mantida via SharePoint, Confluence ou upload direto de documentos.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Outros tipos de agente</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/br/servicos/ai-agents/document-agents/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">O Especialista</p>
<p class="text-body font-semibold text-gosign-dark">Document Agents</p>
<p class="text-body text-gosign-text-light mt-2">Leitura, compreensão e classificação de documentos - com compreensão linguística real.</p>
</a>
<a href="/br/servicos/ai-agents/workflow-agents/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">O Coordenador</p>
<p class="text-body font-semibold text-gosign-dark">Workflow Agents</p>
<p class="text-body text-gosign-text-light mt-2">Orquestração de processos entre sistemas - SAP, TOTVS, SharePoint.</p>
</a>
<a href="/br/servicos/ai-agents/co-build/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Agentes individuais</p>
<p class="text-body font-semibold text-gosign-dark">Co-Build</p>
<p class="text-body text-gosign-text-light mt-2">Seu processo, seu agente. 4-6 semanas até um agente produtivo.</p>
</a>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Aprofundamento no Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nossa série de artigos para executivos que implementam agentes de IA na empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/br/revista/rag-document-intelligence-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">RAG e Document Intelligence: Como a IA entende seus documentos</p>
</a>
<a href="/br/revista/human-in-the-loop-arquitetura/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Human-in-the-Loop - Princípio arquitetônico, não checkbox</p>
</a>
<a href="/br/revista/decision-layer-explicado/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - O que é por que todo agente AI enterprise precisa de um</p>
</a>
</div>
</div>
</section>

--- Workflow Agents - Orquestração de Processos entre Sistemas ---
> Workflow Agents orquestram processos empresariais entre sistemas. SAP, TOTVS, Workday - um agent coordena o fluxo. Audit Trail e Decision Layer incluídos.

<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="AI Agents Navegação">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/br/servicos/ai-agents/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
AI Agents
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/br/servicos/ai-agents/document-agents/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Document</a>
<a href="/br/servicos/ai-agents/workflow-agents/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Workflow</a>
<a href="/br/servicos/ai-agents/knowledge-agents/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Knowledge</a>
<a href="/br/servicos/ai-agents/co-build/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Co-Build</a>
</div>
</div>
</nav>

<!-- Visão geral -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h2 font-bold text-gosign-dark">Visão geral</h2>
<div class="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-3 gap-4 mt-6">
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">5+ sistemas</p>
<p class="text-body text-gosign-text-light mt-1">SAP, TOTVS, Workday, SharePoint, AD - um agent coordena tudo</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Pausável</p>
<p class="text-body text-gosign-text-light mt-1">Workflow pausa quando o humano precisa decidir - e retoma em seguida</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Idempotente</p>
<p class="text-body text-gosign-text-light mt-1">Cada passo repetível sem efeitos colaterais - sem lançamentos duplicados</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Decision Layer</p>
<p class="text-body text-gosign-text-light mt-1">Em cada ponto de decisão: autônomo ou Human-in-the-Loop</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Baseado em API</p>
<p class="text-body text-gosign-text-light mt-1">Sem automação de GUI - integração estável via interfaces</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Audit Trail</p>
<p class="text-body text-gosign-text-light mt-1">Cada passo com marca temporal, regra, versão e decisão de routing</p>
</div>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Definição: Workflow Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Um Workflow Agent é um AI Agent especializado para a orquestração de processos empresariais entre sistemas. Coordena tarefas entre múltiplos sistemas - incluindo escalação, lógica de aprovação e tratamento de exceções.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Diferentemente do RPA (Robotic Process Automation), o Workflow Agent não trabalha nas interfaces de aplicações, mas via APIs e compreende o contexto profissional das decisões que coordena.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Exemplo: Workflow de Atestado Médico</h2>
<pre class="bg-gosign-dark text-white p-6 rounded-card overflow-x-auto text-small font-mono leading-relaxed mt-4"><code>Entrada         →  Document Agent     →  Decision Layer
(E-mail com        lê o atestado         verifica regras CLT (PT: Código do Trabalho)
anexo)            e extrai dados         e restrições internas
│
┌──────────┴──────────┐
│                     │
Conforme regras         Consulta necessária
│                     │
Calcular continuidade   Funcionário RH
salarial                é informado
│                     │
Proposta de             Aguarda
lançamento SAP           decisão
│                     │
Audit Trail              Audit Trail</code></pre>
<p class="text-body-lg text-gosign-text-light mt-4">
Cada passo é registrado. Cada decisão é rastreável. Diante de consultas ou informações faltantes, o workflow pausa - não interrompe.
</p>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Princípios de Orquestração</h2>
<ul class="mt-6 space-y-4">
<li class="text-body-lg text-gosign-text-light"><strong>Entre sistemas:</strong> Um workflow pode coordenar SAP, TOTVS, SharePoint, e-mail e outros sistemas em um único fluxo</li>
<li class="text-body-lg text-gosign-text-light"><strong>Baseado em decisões:</strong> O Workflow Agent toma decisões profissionais, não apenas regras se-então</li>
<li class="text-body-lg text-gosign-text-light"><strong>Pausável:</strong> Quando faltam informações ou decisões humanas são necessárias, o workflow pausa, documenta e retoma após esclarecimento</li>
<li class="text-body-lg text-gosign-text-light"><strong>Auditável:</strong> Cada passo cria uma entrada no Audit Trail, incluindo tempos de espera e escalações</li>
<li class="text-body-lg text-gosign-text-light"><strong>Idempotente:</strong> Cada passo pode ser reexecutado sem efeitos colaterais</li>
</ul>
</div>
</section>

<!-- Comparação: Workflow Agent vs. solução clássica -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Workflow Agent vs. RPA vs. coordenação manual</h2>
<div class="overflow-x-auto mt-6">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-dark">
<th class="py-3 pr-4 text-body font-bold text-gosign-dark"></th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Workflow Agent</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Bot RPA</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Coordenação manual</th>
</tr>
</thead>
<tbody class="text-body text-gosign-text-light">
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Controle</td>
<td class="py-3 px-4">APIs + decisões profissionais</td>
<td class="py-3 px-4">Cliques de GUI em interfaces</td>
<td class="py-3 px-4">E-mail, telefone, tickets</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Estabilidade</td>
<td class="py-3 px-4">Contratos de API - independente de alterações na UI</td>
<td class="py-3 px-4">Falha em alterações na UI</td>
<td class="py-3 px-4">Dependente de pessoas</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Capacidade de decisão</td>
<td class="py-3 px-4">Decisões profissionais baseadas em conjuntos de regras</td>
<td class="py-3 px-4">Apenas regras se-então</td>
<td class="py-3 px-4">Capacidade de decisão plena</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Interrupção</td>
<td class="py-3 px-4">Pausa, aguarda, retoma</td>
<td class="py-3 px-4">Interrompe - reinício necessário</td>
<td class="py-3 px-4">Aguarda - frequentemente sem documentação</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Audit Trail</td>
<td class="py-3 px-4">Automático por passo</td>
<td class="py-3 px-4">Baseado em screenshots</td>
<td class="py-3 px-4">Manual, incompleto</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Cenário prático -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Prática: Processo de onboarding</h2>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6 mt-6">
<p class="font-semibold text-gosign-dark text-body">Cenário: 20 novos colaboradores por mês</p>
<div class="grid grid-cols-1 sm:grid-cols-2 gap-6 mt-4">
<div>
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-text-light mb-2">Antes (manual)</p>
<ul class="space-y-1 text-body text-gosign-text-light">
<li>3 dias úteis por onboarding</li>
<li>5 sistemas atualizados manualmente (SAP, AD, e-mail, controle de ponto, controle de acesso)</li>
<li>Taxa de erros: 12% (permissões ausentes, centro de custo incorreto)</li>
<li>Esforço do RH: 60 horas por mês</li>
</ul>
</div>
<div>
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Depois (Workflow Agent)</p>
<ul class="space-y-1 text-body text-gosign-text-light">
<li>4 horas por onboarding (incluindo aprovações manuais)</li>
<li>5 sistemas provisionados automaticamente via APIs</li>
<li>Taxa de erros: abaixo de 2% (atribuição baseada em regras)</li>
<li>Esforço do RH: 15 horas por mês</li>
</ul>
</div>
</div>
<p class="text-body text-gosign-text-light mt-4">
<strong>Resultado:</strong> 75% menos esforço, 85% menos erros. O Workflow Agent coordena todos os sistemas e pausa apenas onde a aprovação humana é necessária - com Audit Trail completo.
</p>
</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Áreas de Aplicação</h2>
<div class="mt-6 space-y-6">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Processos de RH</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Onboarding (contrato, provisionamento de TI, integração), atestados médicos, alterações contratuais, processos de desligamento. Orquestração via SAP SuccessFactors, Workday, Active Directory e e-mail.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Processos de Finance</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Recebimento de notas fiscais, verificação, contabilização, aprovação, lançamento. Orquestração via TOTVS, SAP FI/CO e interfaces bancárias.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Processos de Compliance</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Verificação automática contra políticas, escalação em desvios, documentação no Audit Trail. Conformidade com a LGPD assegurada arquitetonicamente.
</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Decision Layer no Workflow</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Cada passo do workflow que envolve uma decisão é roteado pelo Decision Layer:
</p>
<ul class="mt-6 space-y-3">
<li class="text-body-lg text-gosign-text-light"><strong>Verificação profissional:</strong> Verificação do conjunto de regras em cada passo decisório</li>
<li class="text-body-lg text-gosign-text-light"><strong>Routing:</strong> Continuação autônoma ou escalação para um humano</li>
<li class="text-body-lg text-gosign-text-light"><strong>Documentação:</strong> Registro de decisão completo em cada passo</li>
<li class="text-body-lg text-gosign-text-light"><strong>Versionamento:</strong> Cada regra aplicada com versão e marca temporal</li>
</ul>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Integração</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Workflow Agents conectam sistemas existentes por interfaces padronizadas:
</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light">SAP FI/CO, SAP S/4HANA, SAP SuccessFactors</li>
<li class="text-body-lg text-gosign-text-light">Workday</li>
<li class="text-body-lg text-gosign-text-light">TOTVS</li>
<li class="text-body-lg text-gosign-text-light">SharePoint, Microsoft Teams (via Microsoft Graph)</li>
<li class="text-body-lg text-gosign-text-light">Active Directory / Azure AD</li>
<li class="text-body-lg text-gosign-text-light">E-mail (IMAP/Exchange)</li>
<li class="text-body-lg text-gosign-text-light">Outros via REST/SOAP</li>
</ul>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Outros tipos de agente</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/br/servicos/ai-agents/document-agents/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">O Especialista</p>
<p class="text-body font-semibold text-gosign-dark">Document Agents</p>
<p class="text-body text-gosign-text-light mt-2">Leitura, compreensão e classificação de documentos - com compreensão linguística real.</p>
</a>
<a href="/br/servicos/ai-agents/knowledge-agents/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">O Portador de Conhecimento</p>
<p class="text-body font-semibold text-gosign-dark">Knowledge Agents</p>
<p class="text-body text-gosign-text-light mt-2">Respostas baseadas em regras - com fonte e versão da regra.</p>
</a>
<a href="/br/servicos/ai-agents/co-build/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Agentes individuais</p>
<p class="text-body font-semibold text-gosign-dark">Co-Build</p>
<p class="text-body text-gosign-text-light mt-2">Seu processo, seu agente. 4-6 semanas até um agente produtivo.</p>
</a>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Aprofundamento no Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nossa série de artigos para executivos que implementam agentes de IA na empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/br/revista/orquestracao-agentes-plataformas/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">Orquestracao de agentes: Trigger.dev, n8n, Camunda e alternativas</p>
</a>
<a href="/br/revista/integracao-ia-panorama-ti/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Integração</p>
<p class="text-body font-semibold text-gosign-dark">Integração de IA em infraestruturas de TI existentes</p>
</a>
<a href="/br/revista/decision-layer-explicado/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - O que é por que todo agente AI enterprise precisa de um</p>
</a>
</div>
</div>
</section>

--- AI Agents para Processos Empresariais ---
> Document Agents, Workflow Agents e Knowledge Agents. AI Agents especializados com Decision Layer, Audit Trail e Human-in-the-Loop.

<!-- Visão geral -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h2 font-bold text-gosign-dark">Visão geral</h2>
<div class="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-3 gap-4 mt-6">
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">3 tipos de agente</p>
<p class="text-body text-gosign-text-light mt-1">Document, Workflow, Knowledge - cada um com seu próprio Decision Layer</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">4-6 semanas</p>
<p class="text-body text-gosign-text-light mt-1">Do Discover ao PoC produtivo na sua infraestrutura</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">85-92% Zero-Touch</p>
<p class="text-body text-gosign-text-light mt-1">Casos rotineiros processados autonomamente - exceções escaladas a humanos</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">7+ LLMs</p>
<p class="text-body text-gosign-text-light mt-1">Agnóstico: Claude, ChatGPT, Gemini, Llama, Mistral, DeepSeek</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Código-fonte completo</p>
<p class="text-body text-gosign-text-light mt-1">Sem SaaS, sem vendor lock-in - você possui código, prompts e regras</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">PL 2338/2023 ready</p>
<p class="text-body text-gosign-text-light mt-1">Audit Trail, Human-in-the-Loop, constraints de acordos coletivos e normas de CIPA</p>
</div>
</div>
</div>
</div>
</section>

<!-- Governance-First Intro -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Construir um agente é fácil. Torná-lo enterprise-ready não.</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Workflow Agents podem ser prototipados em dias. O problema real começa depois: A decisão do agente é auditável? Atende aos requisitos do PL 2338/2023? O sindicato e a CIPA conseguem compreender por quais regras o agente decide?
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
É exatamente aí que entramos. Não na construção do agente - mas na camada de governance que o torna produtivo, verificável e certificável. Processos empresariais se baseiam em conhecimento implícito: convenções coletivas, acordos de empresa, lógica contábil. Um AI Agent estrutura essas decisões, documenta-as e as torna reproduzíveis - em todas as filiais e operadores.
</p>
</div>
</div>
</section>

<!-- Três tipos de agente: Visão geral + Tabela comparativa -->
<section id="tipos-de-agente" class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Três tipos de agente</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Todo processo de negócio pode ser decomposto em três tarefas: entender documentos, coordenar fluxos e fornecer conhecimento. Para isso existem três tipos de agente especializados - cada um com seu próprio Decision Layer e Audit Trail.
</p>
</div>
<img src="/images/diagrams/agent-types-overview-br.svg" alt="Três tipos de agente: Document Agent (O Especialista), Workflow Agent (O Coordenador), Knowledge Agent (O Conhecedor)" class="w-full max-w-3xl mx-auto mt-8 mb-8" width="1200" height="400" loading="lazy" />
<div class="max-w-narrow">
<div class="overflow-x-auto mt-4">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-dark">
<th class="py-3 pr-4 text-body font-bold text-gosign-dark"></th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Document Agent</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Workflow Agent</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Knowledge Agent</th>
</tr>
</thead>
<tbody class="text-body text-gosign-text-light">
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Função</td>
<td class="py-3 px-4">O Especialista</td>
<td class="py-3 px-4">O Coordenador</td>
<td class="py-3 px-4">O Conhecedor</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Tarefa</td>
<td class="py-3 px-4">Ler, compreender e classificar documentos</td>
<td class="py-3 px-4">Orquestrar processos entre sistemas</td>
<td class="py-3 px-4">Responder perguntas a partir de regras internas</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Substitui</td>
<td class="py-3 px-4">OCR + template matching</td>
<td class="py-3 px-4">RPA + workflows manuais</td>
<td class="py-3 px-4">Motor de busca + chatbot</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Exemplo</td>
<td class="py-3 px-4">Extrair e classificar atestado médico</td>
<td class="py-3 px-4">Coordenar onboarding via SAP, AD e e-mail</td>
<td class="py-3 px-4">Responder sobre direito a férias com fonte verificada</td>
</tr>
</tbody>
</table>
</div>
</div>

<!-- Tipo de agente 1: Document Agents -->
<div class="max-w-narrow mt-12">
<div class="flex items-start gap-4">
<span class="text-5xl font-bold text-gosign-accent/20 leading-none before:content-['01']" aria-hidden="true"></span>
<div>
<h3 class="text-h2 font-bold text-gosign-dark">Document Agents</h3>
<p class="text-body-lg text-gosign-text-light mt-2">O Especialista: compreende documentos com entendimento linguístico real. Sem template matching - compreensão contextual de faturas, atestados médicos, contratos. O Decision Layer avalia cada extração e roteia casos de baixa confiança para um analista.</p>
<div class="mt-4 bg-gosign-light border-l-4 border-gosign-accent rounded-card p-4">
<p class="text-small font-semibold text-gosign-dark">Human-in-the-Loop</p>
<p class="text-small text-gosign-text-light mt-1"><strong>O agente decide:</strong> Documentos padrão com alta confiança (notas fiscais com contabilização clara, atestados com prazos inequívocos).<br/><strong>O humano decide:</strong> Documentos ambíguos, valores divergentes, fornecedores novos, documentos com cláusulas de texto livre. O agente prepara e recomenda - a aprovação final é do responsável.</p>
</div>
</div>
</div>
<p class="mt-4">
<a href="/br/servicos/ai-agents/document-agents/" class="inline-flex items-center text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">
Document Agents em detalhe
<svg class="w-5 h-5 ml-2" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg>
</a>
</p>
</div>

<!-- Tipo de agente 2: Workflow Agents -->
<div class="max-w-narrow mt-10">
<div class="flex items-start gap-4">
<span class="text-5xl font-bold text-gosign-accent/20 leading-none before:content-['02']" aria-hidden="true"></span>
<div>
<h3 class="text-h2 font-bold text-gosign-dark">Workflow Agents</h3>
<p class="text-body-lg text-gosign-text-light mt-2">O Coordenador: orquestra processos entre sistemas. SAP, TOTVS, SharePoint, Active Directory - um agente coordena todo o fluxo via APIs. Em caso de dúvidas, o workflow pausa, o humano decide, e o agente retoma exatamente daquele ponto.</p>
<div class="mt-4 bg-gosign-light border-l-4 border-gosign-accent rounded-card p-4">
<p class="text-small font-semibold text-gosign-dark">Human-in-the-Loop</p>
<p class="text-small text-gosign-text-light mt-1"><strong>O agente decide:</strong> Roteamento, lançamentos contábeis, atualizações de status, notificações - tudo segundo regras definidas no Decision Layer.<br/><strong>O humano decide:</strong> Decisões de pessoal (contratação, demissão, transferência), aprovações orçamentárias acima de limites, exceções a acordos coletivos. O fluxo pausa até que o humano tenha decidido.</p>
</div>
</div>
</div>
<p class="mt-4">
<a href="/br/servicos/ai-agents/workflow-agents/" class="inline-flex items-center text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">
Workflow Agents em detalhe
<svg class="w-5 h-5 ml-2" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg>
</a>
</p>
</div>

<!-- Tipo de agente 3: Knowledge Agents -->
<div class="max-w-narrow mt-10">
<div class="flex items-start gap-4">
<span class="text-5xl font-bold text-gosign-accent/20 leading-none before:content-['03']" aria-hidden="true"></span>
<div>
<h3 class="text-h2 font-bold text-gosign-dark">Knowledge Agents</h3>
<p class="text-body-lg text-gosign-text-light mt-2">O Conhecedor: responde perguntas a partir do conhecimento corporativo - acordos coletivos, convenções, políticas internas. Cada resposta com fonte e versão da regra. Sem fonte verificada, sem resposta - a arquitetura impede alucinação.</p>
<div class="mt-4 bg-gosign-light border-l-4 border-gosign-accent rounded-card p-4">
<p class="text-small font-semibold text-gosign-dark">Human-in-the-Loop</p>
<p class="text-small text-gosign-text-light mt-1"><strong>O agente decide:</strong> Consultas padrão com base de fontes clara (direito a férias, prazo de aviso prévio, competências).<br/><strong>O humano decide:</strong> Questões de interpretação com conjuntos de regras contraditórios, avaliações de casos individuais, perguntas sobre negociações em andamento. Em caso de incerteza, o agente não responde, mas escala com contexto ao especialista responsável.</p>
</div>
</div>
</div>
<p class="mt-4">
<a href="/br/servicos/ai-agents/knowledge-agents/" class="inline-flex items-center text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">
Knowledge Agents em detalhe
<svg class="w-5 h-5 ml-2" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg>
</a>
</p>
</div>
</div>
</section>

<!-- Interação: Sistema Multi-Agent -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Interação: três agentes, um processo</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Na prática, os três tipos de agente trabalham em conjunto. Um Workflow Agent orquestra o processo geral e aciona Document Agents e Knowledge Agents como especialistas.
</p>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6 mt-6">
<p class="font-semibold text-gosign-dark text-body">Exemplo: atestado médico de ponta a ponta</p>
<ol class="mt-3 space-y-2 text-body text-gosign-text-light list-decimal list-inside">
<li><strong>Document Agent</strong> identifica o atestado médico na caixa de e-mail, extrai nome, período e código CID.</li>
<li><strong>Workflow Agent</strong> verifica no sistema de RH: é o terceiro atestado em seis meses?</li>
<li><strong>Knowledge Agent</strong> é acionado: "A partir de qual limite se aplica o programa de retorno ao trabalho conforme a convenção coletiva vigente?"</li>
<li><strong>Workflow Agent</strong> avalia as respostas: limite não atingido - processo padrão.</li>
<li><strong>Decision Layer</strong> verifica regras da CLT e constraints de acordos coletivos - calcular continuidade do pagamento.</li>
<li><strong>Workflow Agent</strong> gera proposta de lançamento no sistema, informa o gestor de RH, documenta no Audit Trail.</li>
</ol>
<p class="text-body text-gosign-text-light mt-3">
Seis etapas, três tipos de agente, três sistemas - um Audit Trail contínuo.
</p>
</div>
</div>
</div>
</section>

<!-- Mid-Page CTA -->
<section class="py-12 bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 text-center">
<p class="text-h2 font-bold text-white">Qual tipo de agente combina com o seu processo?</p>
<p class="text-body-lg text-white/80 mt-2">30 minutos. Seu processo. Recomendação concreta.</p>
<a href="/br/contato/" class="inline-block mt-6 px-8 py-3 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors">Agendar reunião</a>
</div>
</section>

<!-- Soluções de agentes especializados -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Soluções de agentes especializados</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Document, Workflow e Knowledge Agents são os componentes base. Para HR e Finance oferecemos soluções pré-configuradas com regras setoriais. Para outras áreas desenvolvemos agentes individuais no Co-Build.
</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-4 gap-6 mt-8 max-w-content">
<a href="/br/hr-ai-agents/" class="group block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">HR & People Operations</p>
<p class="text-body font-semibold text-gosign-dark">HR AI Agents</p>
<p class="text-body text-gosign-text-light mt-2">6 produtos de agentes: Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Conformidade com sindicatos e acordos coletivos.</p>
<p class="text-small text-gosign-accent-text mt-2">Avaliar 48 agentes no Assessment &rarr;</p>
<span class="inline-flex items-center gap-1 mt-2 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Visão geral <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
<a href="/br/finance-ai-agents/" class="group block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Finance & Accounting</p>
<p class="text-body font-semibold text-gosign-dark">Finance AI Agents</p>
<p class="text-body text-gosign-text-light mt-2">Processamento de documentos, contabilização, lógica de depreciação, lançamentos corretivos. Integração com SAP e TOTVS.</p>
<p class="text-small text-gosign-accent-text mt-2">Avaliar 49 agentes no Assessment &rarr;</p>
<span class="inline-flex items-center gap-1 mt-2 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Visão geral <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
<a href="/br/servicos/ai-agents/co-build/" class="group block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Agentes individuais</p>
<p class="text-body font-semibold text-gosign-dark">Co-Build</p>
<p class="text-body text-gosign-text-light mt-2">Seu processo, seu agente. 4-6 semanas do Discover ao agente produtivo com acesso ao código-fonte.</p>
<span class="inline-flex items-center gap-1 mt-4 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Detalhes <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
<a href="/br/contato/" class="group block bg-gosign-dark rounded-card p-6 hover:bg-gosign-dark/90 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-white/60 mb-2">Próximo passo</p>
<p class="text-body font-semibold text-white">Agendar reunião</p>
<p class="text-body text-white/80 mt-2">30 minutos. Seu caso de uso. Recomendação concreta de qual tipo de agente se encaixa.</p>
<span class="inline-flex items-center gap-1 mt-4 text-small font-semibold text-white/60 group-hover:text-white transition-colors">Agendar reunião <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
</div>
</div>
</section>

<!-- Para quem -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Para quem</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
AI Agents afetam diferentes stakeholders. Cada um tem suas próprias perguntas.
</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-4 gap-6 mt-8 max-w-content">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">CHRO / VP RH</p>
<p class="text-body text-gosign-text-light mt-2">Automatização de processos de RH em conformidade com sindicatos - Payroll, Leave, Recruiting - com Audit Trail completo e compliance trabalhista.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">CFO / Finance Lead</p>
<p class="text-body text-gosign-text-light mt-2">Processamento automatizado de documentos, contabilização e conciliação - consistente em todas as filiais, auditável para auditores externos.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Sindicato / CIPA</p>
<p class="text-body text-gosign-text-light mt-2">Transparência sobre cada decisão do agente. O Decision Layer mapeia acordos coletivos como constraints explícitos. CIPA monitora segurança do trabalho. Human-in-the-Loop onde importa.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">CTO / IT Lead</p>
<p class="text-body text-gosign-text-light mt-2">Arquitetura agnóstica. Integração via API com SAP, TOTVS, Workday. Sem vendor lock-in, acesso completo ao código-fonte.</p>
</div>
</div>
</div>
</section>

<!-- Decision Layer -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Decision Layer</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
O Decision Layer decompõe cada processo de negócio em etapas de decisão individuais e define para cada etapa: humano, regra ou IA. Cada decisão é documentada - verificável por auditores, sindicatos e auditoria interna.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Diferente para cada tipo de agente: em Document Agents, verifica a qualidade da extração. Em Workflow Agents, controla o roteamento. Em Knowledge Agents, impede a alucinação.
</p>
<p class="mt-4">
<a href="/br/decision-layer/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Decision Layer em detalhe</a>
</p>
</div>
</div>
</section>

<!-- Integração + Agnosticismo de modelo -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Integração e agnosticismo de modelo</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
AI Agents não substituem sistemas existentes. SAP continua sendo ERP. Workday continua sendo HCM. TOTVS continua sendo sistema fiscal. A lógica do agente é desacoplada do sistema destino.
</p>
<div class="grid grid-cols-2 sm:grid-cols-3 gap-3 mt-6">
<div class="bg-gosign-white rounded-card px-4 py-3 text-body text-gosign-text-light">SAP FI/CO, S/4HANA</div>
<div class="bg-gosign-white rounded-card px-4 py-3 text-body text-gosign-text-light">SAP SuccessFactors</div>
<div class="bg-gosign-white rounded-card px-4 py-3 text-body text-gosign-text-light">Workday</div>
<div class="bg-gosign-white rounded-card px-4 py-3 text-body text-gosign-text-light">TOTVS</div>
<div class="bg-gosign-white rounded-card px-4 py-3 text-body text-gosign-text-light">SharePoint, Teams</div>
<div class="bg-gosign-white rounded-card px-4 py-3 text-body text-gosign-text-light">Active Directory</div>
</div>
<p class="text-body-lg text-gosign-text-light mt-6">
A arquitetura não é vinculada a um único LLM: Claude, ChatGPT, Gemini, Llama, Mistral, DeepSeek - modelos são intercambiáveis sem alterar a lógica de negócio. Sem vendor lock-in.
</p>
</div>
</div>
</section>

<!-- Business Impact + Ownership -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Impacto de negócio</h2>
<ul class="mt-6 space-y-3">
<li class="text-body-lg text-gosign-text-light">Casos rotineiros processados autonomamente - com documentação completa</li>
<li class="text-body-lg text-gosign-text-light">Mesma interpretação de regras em todas as filiais</li>
<li class="text-body-lg text-gosign-text-light">Cada decisão rastreável para auditores e sindicatos</li>
<li class="text-body-lg text-gosign-text-light">Escalável sem aumento proporcional de pessoal</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-6">
Acesso completo ao código-fonte, todos os prompts e regras. Após 12-18 meses, você opera seus agentes de forma independente. Sem assinatura SaaS, sem platform lock-in.
</p>
</div>
</div>
</section>

<!-- Aprofundamento -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Aprofundamento no Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nossa série de artigos para executivos que implementam AI Agents na empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/br/revista/agentes-ia-enterprise-guia/" class="group block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors bg-gosign-white">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">AI Agents</p>
<p class="text-body font-semibold text-gosign-dark">De chatbots a agentes IA: MCP, A2A e sistemas Multi-Agent</p>
<span class="inline-flex items-center gap-1 mt-3 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Ler <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
<a href="/br/revista/orquestracao-agentes-plataformas/" class="group block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors bg-gosign-white">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">Orquestração de agentes: Trigger.dev, n8n, Camunda e alternativas</p>
<span class="inline-flex items-center gap-1 mt-3 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Ler <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
<a href="/br/revista/decision-layer-explicado/" class="group block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors bg-gosign-white">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - O que é e por que todo agente AI enterprise precisa de um</p>
<span class="inline-flex items-center gap-1 mt-3 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Ler <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
</div>
</div>
</section>

--- Document Intelligence - PII, Redação de Contratos, Detecção de Assinaturas ---
> Processar documentos com IA em conformidade com LGPD. Anonimização PII, redação de contratos, detecção de assinaturas - controlado pelo Decision Layer.

<!-- O Problema -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">O Problema: Dados Pessoais em Cada Documento</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Empresas querem processar documentos com IA - analisar contratos, classificar notas fiscais, consultar politicas. Mas cada documento contém dados pessoais: nomes, salários, CPFs, endereços, dados bancários, assinaturas.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Enviar esses dados a um modelo de linguagem - mesmo um auto-hospedado - sem proteção viola o princípio de minimização de dados da LGPD (PT: RGPD). Acordos coletivos de trabalho restringem o processamento de dados de funcionários. Segredos comerciais em contratos não podem chegar a terceiros.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
As soluções atuais são insuficientes: redação manual em Adobe Acrobat é demorada, propensa a erros e frequentemente apenas cosmética - o texto permanece acessível sob as barras pretas. A alternativa é renunciar ao processamento IA de documentos sensíveis, o que elimina a maior parte do ganho de produtividade.
</p>
</div>
</div>
</section>

<!-- Três Capabilities -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">Três Capabilities</h2>
<div class="grid grid-cols-1 md:grid-cols-3 gap-6">
<div class="bg-white rounded-card p-6 border border-gosign-border">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Anonimização PII</h3>
<p class="text-body text-gosign-text-light">Detecção e pseudonimização automática de dados pessoais. Nomes, endereços, CPFs, números fiscais, datas de nascimento. Roundtrip: pseudonimização antes do LLM, re-anonimização após processamento. LGPD by Design.</p>
</div>
<div class="bg-white rounded-card p-6 border border-gosign-border">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Redação de Contratos</h3>
<p class="text-body text-gosign-text-light">Redação inteligente de contratos - dependente do destinatário. O cliente vê campos diferentes do auditor. Matriz de redação configurável. Fisicamente seguro: o documento é re-renderizado.</p>
</div>
<div class="bg-white rounded-card p-6 border border-gosign-border">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Detecção de Assinaturas</h3>
<p class="text-body text-gosign-text-light">Detecção automática de assinaturas e comparação com assinaturas de referência. Não apenas presença, mas qualidade de correspondência. Anomalias são escaladas para humanos - o sistema nunca afirma autenticidade.</p>
</div>
</div>
</div>
</section>

<!-- Anonimização PII Detalhe -->
<section id="anonimizacao-pii" class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Anonimização PII: Pseudonimização Roundtrip para LLM Input</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
A maioria das ferramentas PII no mercado realiza redação unidirecional - removem dados. Para processamento com modelos de linguagem, isso é insuficiente. Quando um agente precisa analisar um contrato, ele necessita de contexto: "Funcionário X tem salário Y na localização Z." Sem esse contexto, o modelo não consegue produzir uma avaliação significativa.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
A solução Gosign é a pseudonimização roundtrip: os dados são pseudonimizados antes do modelo, processados pelo modelo e re-anonimizados no resultado. O modelo vê apenas pseudônimos. O resultado contém os dados reais.
</p>

<pre class="bg-gosign-dark text-white p-6 rounded-card overflow-x-auto text-small font-mono leading-relaxed mt-6"><code>┌─────────────┐     ┌──────────────────┐     ┌─────────────┐     ┌──────────────────┐     ┌─────────────┐
│  Documento  │     │  Detecção PII    │     │  Pseudo-     │     │  Modelo de       │     │  Re-Mapping │
│  (Original) │────▶│  e classifi-     │────▶│  nimização   │────▶│  linguagem       │────▶│  Pseudônimos│
│             │     │  cação           │     │              │     │  processa apenas │     │  → dados    │
└─────────────┘     └──────────────────┘     └──────────────┘     └──────────────────┘     └─────────────┘
│                        │                                            │
▼                        ▼                                            ▼
┌──────────────┐         ┌──────────────┐                              ┌──────────────┐
│  Decision    │         │  Tabela de   │                              │  Resultado   │
│  Layer:      │         │  mapeamento  │◀─────────────────────────────│  com dados   │
│  O que é     │         │  (permanece  │   Mapeamento reverso         │  reais       │
│  anonimizado │         │  local)      │                              └──────────────┘
└──────────────┘         └──────────────┘</code></pre>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">Etapas de Decisão no Processo PII</h3>
<div class="mt-4 overflow-x-auto">
<table class="w-full text-body text-gosign-text-light border-collapse">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="text-left py-2 pr-4 font-bold text-gosign-dark">Micro-Decisão</th>
<th class="text-left py-2 pr-4 font-bold text-gosign-dark">Quem Decide</th>
<th class="text-left py-2 font-bold text-gosign-dark">Por quê</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Definir categorias PII</td><td class="py-2 pr-4">Humano + Regras</td><td class="py-2">Requisitos LGPD, acordo coletivo, regras do cliente</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Detectar PII no documento</td><td class="py-2 pr-4">IA (NER + padrões)</td><td class="py-2">Named Entity Recognition + padrões baseados em regras</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Revisar falsos positivos</td><td class="py-2 pr-4">IA, se incerteza: Humano</td><td class="py-2">Confidence Routing - "Silva" como sobrenome ou empresa?</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Atribuir pseudônimos</td><td class="py-2 pr-4">Automático</td><td class="py-2">Mapeamento consistente, "Pessoa_A" em vez de "João Silva"</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Enviar documento pseudonimizado ao modelo</td><td class="py-2 pr-4">Automático</td><td class="py-2">Sem decisão, encaminhamento puro</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Re-anonimizar resultado</td><td class="py-2 pr-4">Automático</td><td class="py-2">Aplicar tabela de mapeamento inversamente</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Auditoria: o que foi anonimizado</td><td class="py-2 pr-4">Automático</td><td class="py-2">Evidência LGPD no Audit Trail</td></tr>
</tbody>
</table>
</div>
<p class="text-body-lg text-gosign-text-light mt-4">
A tabela de mapeamento (pseudônimo → dados reais) nunca sai da camada de pré-processamento. É excluída após a conclusão do processamento - ou retida por um período definido, conforme configuração. O modelo de linguagem nunca vê dados pessoais em nenhum momento.
</p>
</div>
</div>
</section>

<!-- Redação de Contratos Detalhe -->
<section id="redacao-contratos" class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Redação de Contratos: Baseada em Regras, Dependente do Destinatário, Física</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Contratos precisam ser compartilhados regularmente em forma redatada - com auditores independentes (PT: revisores oficiais de contas), com compradores potenciais durante due diligence, com representantes dos trabalhadores, com consultores externos. Hoje alguém faz isso manualmente. Leva horas por contrato, é propenso a erros, e a redação frequentemente é apenas cosmética: o texto permanece acessível sob as barras pretas. Um vazamento de dados frequentemente subestimado.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
A solução Gosign: o Document Agent reconhece a estrutura do contrato - partes, valores, prazos, cláusulas, assinaturas. O Decision Layer define regras de redação dependentes do destinatário:
</p>

<div class="mt-6 overflow-x-auto">
<table class="w-full text-body text-gosign-text-light border-collapse">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="text-left py-2 pr-4 font-bold text-gosign-dark">Elemento do contrato</th>
<th class="text-left py-2 pr-4 font-bold text-gosign-dark">Sindicato / CRE</th>
<th class="text-left py-2 pr-4 font-bold text-gosign-dark">Due Diligence</th>
<th class="text-left py-2 pr-4 font-bold text-gosign-dark">Consultor externo</th>
<th class="text-left py-2 font-bold text-gosign-dark">Auditor independente</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Partes contratantes (nomes)</td><td class="py-2 pr-4">✓ Visível</td><td class="py-2 pr-4">✗ Redatado</td><td class="py-2 pr-4">✗ Redatado</td><td class="py-2">✓ Visível</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Valores do contrato</td><td class="py-2 pr-4">✓ Visível</td><td class="py-2 pr-4">✓ Visível</td><td class="py-2 pr-4">✗ Redatado</td><td class="py-2">✓ Visível</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Salários / remuneração</td><td class="py-2 pr-4">✓ Visível</td><td class="py-2 pr-4">Agregado</td><td class="py-2 pr-4">✗ Redatado</td><td class="py-2">✓ Visível</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Cláusulas contratuais</td><td class="py-2 pr-4">✓ Visível</td><td class="py-2 pr-4">✓ Visível</td><td class="py-2 pr-4">Apenas tipos de cláusula</td><td class="py-2">✓ Visível</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Segredos comerciais</td><td class="py-2 pr-4">✗ Redatado</td><td class="py-2 pr-4">✓ Visível</td><td class="py-2 pr-4">✗ Redatado</td><td class="py-2">✓ Visível</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Assinaturas</td><td class="py-2 pr-4">✗ Redatado</td><td class="py-2 pr-4">✗ Redatado</td><td class="py-2 pr-4">✗ Redatado</td><td class="py-2">✓ Visível</td></tr>
</tbody>
</table>
</div>

<p class="text-body-lg text-gosign-text-light mt-4">
As regras de redação são versionadas no Decision Layer. Quando os requisitos mudam - novo grupo de destinatários, acordo coletivo atualizado, regra de compliance alterada - uma nova versão de regras é criada. A versão anterior permanece rastreável.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong>Redação física:</strong> O PDF é re-renderizado do zero. Os dados originais não estão mais fisicamente presentes no documento - nem como texto, nem como metadados, nem como camada invisível. Sem copiar-colar sob barras pretas, sem edição PDF para descobrir conteúdo. Isso não é cosmético - é criptograficamente seguro.
</p>
</div>
</div>
</section>

<!-- Detecção de Assinaturas Detalhe -->
<section id="deteccao-assinaturas" class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Detecção de Assinaturas: Encontrar, Verificar, Documentar</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Gestão de contratos, preparação para auditoria, revisões de compliance - tudo requer verificação periódica: O documento está assinado? Onde está a assinatura? Falta uma contra-assinatura? Com 5.000 contratos no arquivo, a verificação manual não é viável.
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">Detecção de assinaturas</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
O Document Agent detecta campos de assinatura e assinaturas presentes em documentos digitalizados e PDFs. Computer Vision, não um modelo de linguagem - modelos ML especializados para análise de imagem. O resultado é estruturado: página, posição, confiança de que a assinatura está presente.
</p>

<p class="text-body-lg text-gosign-text-light mt-6">
<strong>Verificação massiva de arquivo:</strong> "Em quais dos 5.000 contratos falta uma contra-assinatura?" - resultados em minutos em vez de semanas.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong>Controle de qualidade de onboarding:</strong> "Todos os documentos obrigatórios do novo funcionário estão assinados?" - checklist automático, assinaturas faltantes escaladas como tarefas de workflow.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong>Preparação para auditoria:</strong> "Mostre todos os documentos sem assinatura do Q3 2025." - lista de exportação estruturada para o auditor independente.
</p>

<pre class="bg-gosign-dark text-white p-6 rounded-card overflow-x-auto text-small font-mono leading-relaxed mt-6"><code>┌─────────────┐     ┌──────────────────┐     ┌──────────────────┐
│  Documento  │     │  Detecção        │     │  Comparação      │
│  com        │────▶│  de assinatura   │────▶│  com assinatura  │
│  assinatura │     │  (posição,       │     │  de referência   │
│             │     │   confiança)     │     │                  │
└─────────────┘     └──────────────────┘     └──────────────────┘
│
┌───────────┼───────────┐
▼           ▼           ▼
┌────────────┐ ┌────────┐ ┌────────────┐
│  Alta      │ │ Média  │ │  Baixa     │
│  corresp.  │ │corresp.│ │  corresp.  │
└────────────┘ └────────┘ └────────────┘
│              │           │
▼              ▼           ▼
Automatica-   Escalação    Bloqueio
mente         para humano  Revisão
aceita,       com visão    humana
documentada   comparativa  obrigatória</code></pre>

<p class="text-body-lg text-gosign-text-light mt-4">
<strong>Importante:</strong> A comparação de assinaturas é um detector de anomalias, não um detector de falsificações. Assinaturas variam naturalmente - dependem do dia, da caneta e da superfície. O sistema identifica anomalias e as escala para um humano. Nunca afirma "esta assinatura é falsa" ou "esta assinatura é autêntica". Isso seria irresponsável.
</p>
</div>
</div>
</section>

<!-- Decision Layer -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Decision Layer: Quem Decide o Quê</h2>
<p class="text-body-lg text-gosign-text-light mt-4">Cada capability tem seu próprio Decision Layer com pontos de decisão definidos.</p>
<div class="mt-6 overflow-x-auto">
<table class="w-full text-left text-small">
<thead>
<tr class="border-b-2 border-gosign-dark">
<th class="py-2 pr-4 font-bold">Capability</th>
<th class="py-2 pr-4 font-bold">Decisão</th>
<th class="py-2 pr-4 font-bold">Decide</th>
<th class="py-2 font-bold">Por quê</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-bold">PII</td><td class="py-2 pr-4">Quais categorias PII detectar?</td><td class="py-2 pr-4">Humano</td><td class="py-2">Decisão organizacional, art. 5 LGPD</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-bold">PII</td><td class="py-2 pr-4">"Müller" é nome ou empresa?</td><td class="py-2 pr-4">IA, a &lt;80%: Humano</td><td class="py-2">Ambiguidade NER - evitar falsos positivos</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-bold">PII</td><td class="py-2 pr-4">Escolher método pseudonimização</td><td class="py-2 pr-4">Regras</td><td class="py-2">Pseudônimos consistentes vs. aleatórios</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-bold">Redação</td><td class="py-2 pr-4">Quais destinatários?</td><td class="py-2 pr-4">Humano</td><td class="py-2">Decisão profissional, não automatizável</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-bold">Redação</td><td class="py-2 pr-4">Quais campos são redatados?</td><td class="py-2 pr-4">Regras</td><td class="py-2">Matriz dependente do destinatário</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-bold">Redação</td><td class="py-2 pr-4">Tipo de cláusula desconhecido</td><td class="py-2 pr-4">Humano</td><td class="py-2">Novos tipos precisam ser classificados</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-bold">Assinatura</td><td class="py-2 pr-4">Assinatura presente?</td><td class="py-2 pr-4">IA</td><td class="py-2">Computer Vision com valor de confiança</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-bold">Assinatura</td><td class="py-2 pr-4">Assinatura confere com referência?</td><td class="py-2 pr-4">IA + Humano se anomalia</td><td class="py-2">Alta correspondência: aceita. Anomalia: escalada</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-bold">Assinatura</td><td class="py-2 pr-4">Sem referência disponível</td><td class="py-2 pr-4">Humano</td><td class="py-2">Nova assinatura de referência deve ser registrada</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-bold">Todos</td><td class="py-2 pr-4">Documentar Audit Trail</td><td class="py-2 pr-4">Automático</td><td class="py-2">Cada decisão protocolada imutavelmente</td></tr>
</tbody>
</table>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Integração</h2>
<p class="text-body-lg text-gosign-text-light mt-4">Document Intelligence é uma capability do Document Agent existente - não software separado.</p>
<ul class="mt-4 space-y-2 text-body-lg text-gosign-text-light list-disc pl-6">
<li>SAP DMS, SAP ArchiveLink - contratos e documentos de arquivos SAP</li>
<li>SharePoint, OneDrive - gestão documental via Microsoft Graph</li>
<li>Caixas de e-mail (IMAP/Exchange) - anexos processados automaticamente</li>
<li>File System Watcher - monitoramento de diretórios locais</li>
<li>REST API - para sistemas DMS customizados</li>
</ul>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Business Impact</h2>
<p class="text-body-lg text-gosign-text-light mt-4"><strong class="text-gosign-dark">Processamento LLM conforme LGPD:</strong> Documentos com dados pessoais podem ser processados pela primeira vez com modelos de linguagem - sem risco de privacidade.</p>
<p class="text-body-lg text-gosign-text-light mt-4"><strong class="text-gosign-dark">Redação de contratos em minutos:</strong> Baseada em regras, dependente do destinatário, fisicamente segura.</p>
<p class="text-body-lg text-gosign-text-light mt-4"><strong class="text-gosign-dark">Detecção proativa de lacunas em assinaturas:</strong> Assinaturas faltantes detectadas antes que o auditor pergunte.</p>
<p class="text-body-lg text-gosign-text-light mt-4"><strong class="text-gosign-dark">Evidência de auditoria:</strong> Audit Trail documenta cada anonimização, cada redação, cada verificação de assinatura.</p>
<p class="text-body-lg text-gosign-text-light mt-4"><strong class="text-gosign-dark">Sem ferramenta nova:</strong> Parte da arquitetura de agents existente. Sem vendor adicional, sem licença adicional.</p>
</div>
</section>

<!-- Aprofundamento -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Aprofundamento no Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nossa série de artigos para executivos que implementam agentes de IA na empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/br/revista/rag-document-intelligence-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">RAG e Document Intelligence: Como a IA entende seus documentos</p>
</a>
<a href="/br/revista/pii-anonimizacao-llm-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Segurança</p>
<p class="text-body font-semibold text-gosign-dark">Anonimizacao de PII para IA Empresarial</p>
</a>
<a href="/br/revista/seguranca-dados-ia-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Segurança</p>
<p class="text-body font-semibold text-gosign-dark">Segurança de dados em IA: Data Residency, LGPD e EU AI Act</p>
</a>
</div>
</div>
</section>

--- Assinaturas Digitais Conformes com eIDAS ---
> Soluções de assinatura digital segundo o regulamento eIDAS. Assinaturas eletrônicas simples, avançadas e qualificadas para processos documentais empresariais.

<!-- eIDAS Regulation -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Regulamento eIDAS</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
O regulamento eIDAS (Regulamento (UE) No 910/2014) cria um marco legal europeu para identificação eletrônica e serviços de confiança.
</p>
</div>
</section>

<!-- Three Signature Levels -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Três Níveis de Assinatura</h2>
<div class="mt-6 space-y-6">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Assinatura Eletrônica Simples (AES)</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Sem requisitos técnicos especiais. Exemplos: assinatura escaneada, nome sob email, clique em "Aceito". Adequada para confirmações internas sem requisito de forma legal.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Assinatura Eletrônica Avançada (AEA)</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Vinculada univocamente ao signatário. Permite identificação. Sob controle exclusivo do signatário. Detecta alterações posteriores. Adequada para contratos comerciais, pedidos e acordos com fornecedores.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Assinatura Eletrônica Qualificada (AEQ)</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Nível mais alto. Efeito legal de assinatura manuscrita (Art. 25 Par. 2 eIDAS). Criada com certificado qualificado de um provedor autorizado. Necessária para documentos notariais, contratos de trabalho com requisito de forma escrita e procedimentos administrativos.
</p>
</div>
</div>
</div>
</section>

<!-- Enterprise Integration -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Integração Empresarial</h2>
<div class="mt-6 space-y-6">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Em workflows de <a href="/br/servicos/document-intelligence/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Document Agent</a></h3>
<p class="text-body-lg text-gosign-text-light mt-2">Assinatura digital como passo de fechamento após processamento automatizado.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Em processos de aprovação</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Aprovações multi-etapa com assinaturas digitais documentadas no <a href="/br/decision-layer/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Audit Trail do Decision Layer</a>.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Integração API</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Conexão com sistemas existentes via REST API.</p>
</div>
</div>
</div>
</section>

<!-- Partners -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Parceiros Certificados ETSI</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
A Gosign não é um provedor de serviços de confiança. Implementamos soluções em cooperação com provedores certificados segundo ETSI EN 319 401.
</p>
</div>
</section>

<!-- Compliance -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Conformidade</h2>
<div class="mt-6 space-y-4">
<p class="text-body-lg text-gosign-text-light">Validade legal em toda a UE segundo eIDAS.</p>
<p class="text-body-lg text-gosign-text-light">Conforme com RGPD/LGPD (PT: RGPD) (<a href="/br/governance/data-residency/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Data Residency</a> na UE).</p>
<p class="text-body-lg text-gosign-text-light">Audit Trail para todas as operações de assinatura.</p>
<p class="text-body-lg text-gosign-text-light">Validação de longo prazo (LTV) para assinaturas qualificadas.</p>
</div>
</div>
</section>

<!-- Aprofundamento no Agent Briefing -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Aprofundamento no Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nossa série de artigos para decisores que protegem processos digitais na empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/br/revista/cert-ready-by-design/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Cert-Ready by Design: Por que a certificação retroativa fracassa</p>
</a>
<a href="/br/revista/rag-document-intelligence-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">AI Agents</p>
<p class="text-body font-semibold text-gosign-dark">RAG e Document Intelligence no Enterprise</p>
</a>
<a href="/br/revista/seguranca-dados-ia-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">Segurança de dados em sistemas AI Enterprise</p>
</a>
</div>
</div>
</section>

--- AI Leave Agent Aviação - gestão de ausências ---
> Leave Decision Layer para aviação. 3 sindicatos, ANAC RBAC 117, Medical Grounding, Crew-Pairing. 78% Zero-Touch.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/br/por-que-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">PL 2338/2023 ready</p>
<p class="text-xs text-gosign-text-light">Cada decisão rastreável</p>
</div>
</a>
<a href="/br/por-que-gosign/#infraestrutura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Sua infraestrutura</p>
<p class="text-xs text-gosign-text-light">Sem SaaS. Sem vendor lock-in.</p>
</div>
</a>
<a href="/br/por-que-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Dados no Brasil</p>
<p class="text-xs text-gosign-text-light">Sem risco de cloud estrangeiro</p>
</div>
</a>
</div>
</div>
</div>


<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Leave Decision Layer Setores">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/br/servicos/hr-agent/leave-absence-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Leave Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/br/servicos/hr-agent/leave-absence-decision-layer/chemicals/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Química</a>
<a href="/br/servicos/hr-agent/leave-absence-decision-layer/aviation/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Aviação</a>
<a href="/br/servicos/hr-agent/leave-absence-decision-layer/financial-services/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Serviços financeiros</a>
<a href="/br/servicos/hr-agent/leave-absence-decision-layer/retail/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Varejo</a>
</div>
</div>
</nav>

<!-- Complexidade -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div><span class="text-h1 font-bold text-gosign-accent-text">3</span><p class="text-small text-gosign-text-light mt-1">Sindicatos</p></div>
<div><span class="text-h1 font-bold text-gosign-accent-text">78%</span><p class="text-small text-gosign-text-light mt-1">Quota Zero-Touch</p></div>
<div><span class="text-h1 font-bold text-gosign-accent-text">ANAC</span><p class="text-small text-gosign-text-light mt-1">RBAC 117 Compliance</p></div>
<div><div class="flex gap-1 mt-2"><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span></div><p class="text-small text-gosign-text-light mt-1">Máxima complexidade de regras</p></div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">Convenções cockpit (ABRAPILOT/SNA), cabine (SNAEAB), solo. LATAM Airlines, GOL, Azul. (PT: TAP, SPAC, SNPVAC.) Zero-Touch: modelo de simulação Gosign.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">O que o Agent classifica</p>
<h2 class="text-h1 font-bold text-gosign-dark">Cinco dimensões, um Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Três sindicatos com convenções próprias, descansos regulatórios obrigatórios (ANAC RBAC 117), Medical Grounding, Crew-Pairing como restrição operacional e bloqueios sazonais de férias. Você conhece a complexidade. Assim o AI Agent a resolve:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Três convenções coletivas em paralelo</h3>
<p class="text-body text-gosign-text mt-2">Cockpit (ABRAPILOT/SNA), cabine (SNAEAB), solo (sindicato de solo) - cada convenção tem regras de férias, licenças e compensações próprias. O AI Agent reconhece o grupo de pessoal e aplica o conjunto de regras correto. Sem confusão entre férias de piloto e férias de pessoal de solo. (PT: Em Portugal, SPAC e SNPVAC com acordos separados.)</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Descansos regulatórios ANAC RBAC 117</h3>
<p class="text-body text-gosign-text mt-2">Descansos obrigatórios definidos pelo RBAC 117 da ANAC são descansos regulatórios que não contam como férias. O AI Agent separa com precisão: descansos regulatórios são rastreados separadamente, direitos de férias não são reduzidos por descansos obrigatórios. No planejamento de férias, o Agent verifica a conformidade com RBAC 117 contra a escala de voo. (PT: Em Portugal, EASA FTL EU-OPS diretamente aplicável.)</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Medical Grounding</h3>
<p class="text-body text-gosign-text mt-2">Revogação do certificado médico (Classe 1 cockpit, Classe 2 cabine) não é doença comum, mas uma ausência regulatória. O AI Agent classifica Medical Grounding como tipo de ausência próprio com consequências específicas por convenção. Dados de saúde permanecem arquitetonicamente separados - o Agent vê apenas o status, nunca o diagnóstico.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Crew-Pairing como restrição</h3>
<p class="text-body text-gosign-text mt-2">Cockpit e cabine devem estar escalados juntos para cada voo. O AI Agent verifica a cada pedido de férias a disponibilidade de tripulação contra o plano de voo e a lotação mínima por posição. Em caso de déficit: escalação automática com sugestão alternativa e contexto para o planejador de escala.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Bloqueios sazonais de férias</h3>
<p class="text-body text-gosign-text mt-2">Alta temporada de verão e fim de ano significam bloqueios de férias para tripulação. O AI Agent conhece os períodos de bloqueio registrados no acordo coletivo e verifica cada pedido contra eles. Exceções exigem decisão do gestor - o Agent documenta a exceção no Audit Trail.</p>
</div>
</div>
</div>
</section>

<!-- Decision Flow -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Um pedido de férias na aviação. 10 etapas de decisão.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Um piloto solicita férias. O Leave Decision Layer decompõe o processo em etapas de decisão individuais:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead><tr class="border-b-2 border-gosign-border"><th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Etapa</th><th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decisão</th><th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decisor</th><th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Fundamentação</th></tr></thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Reconhecer grupo de pessoal e convenção</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent reconhece: cockpit, cabine ou solo a partir do cadastro de pessoal</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Classificar tipo de ausência</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent reconhece: férias, descanso regulatório RBAC 117, Medical Grounding ou licença</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Calcular direito a férias</td><td class="py-3 px-4">Regra</td><td class="py-3 px-4">30 dias base CLT + adicional por convenção (senioridade, longa distância)</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Verificar conformidade ANAC RBAC 117</td><td class="py-3 px-4">Regra</td><td class="py-3 px-4">Descansos mínimos entre escalas, acumulação de horas de voo, limites de Duty Period</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Verificar Crew-Pairing e lotação mínima</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent verifica disponibilidade de tripulação contra plano de voo e lotação mínima por posição</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Verificar bloqueio de férias</td><td class="py-3 px-4">Regra</td><td class="py-3 px-4">Alta temporada, fim de ano, períodos de bloqueio definidos em acordo coletivo</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Gerar recomendação de aprovação</td><td class="py-3 px-4">IA recomenda, humano decide</td><td class="py-3 px-4">Todas as regras atendidas: recomendação de aprovação. Conflito: escalação com contexto</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">Monitorar limiar de afastamento INSS</td><td class="py-3 px-4">Regra</td><td class="py-3 px-4">15 dias empregador, a partir do 16o dia INSS. Medical Grounding rastreado separadamente</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Calcular pagamento de férias + 1/3</td><td class="py-3 px-4">Regra</td><td class="py-3 px-4">Remuneração + 1/3 constitucional, adicionais por convenção</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Gerar registro de auditoria</td><td class="py-3 px-4">Regra</td><td class="py-3 px-4">Dossiê completo: tipo de ausência, convenção, status RBAC 117, verificação Crew, resultado</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Simulação -->
<section id="simulacao" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulação</p>
<h2 class="text-h1 font-bold text-white">Calculado para volumes da aviação</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Configuramos o Leave Decision Layer com parâmetros realistas de aviação. Três sindicatos, ANAC RBAC 117, Medical Grounding, Crew-Pairing.</p>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Parâmetros da simulação</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Colaboradores</td><td class="py-3 px-4">5.000 a 80.000+ (cockpit, cabine, solo)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Convenções</td><td class="py-3 px-4">ABRAPILOT/SNA (cockpit), SNAEAB (cabine), sindicato de solo</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Regulatória</td><td class="py-3 px-4">ANAC RBAC 117, certificados médicos Classe 1 e 2</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Tipos de ausência</td><td class="py-3 px-4">Férias, descanso regulatório, Medical Grounding, standby, licença</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Restrições</td><td class="py-3 px-4">Crew-Pairing, bloqueios sazonais, bases (GRU, GIG, CGH, internacional)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Afastamento</td><td class="py-3 px-4">Taxa do setor de aviação, Medical Grounding separado</td></tr>
</tbody>
</table>
</div>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Antes / Depois</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead><tr class="border-b-2 border-white/20"><th scope="col" class="text-left py-3 px-4 font-semibold text-white">Dimensão</th><th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manual</th><th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th></tr></thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Tempo de processamento</td><td class="py-3 px-4">2-5 dias (verificação de tripulação)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 2 minutos</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Quota Zero-Touch</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">78%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Conflitos RBAC 117 detectados</td><td class="py-3 px-4">Manual pelo planejador</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automático em tempo real</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Medical Grounding classificado corretamente</td><td class="py-3 px-4">Propenso a erros</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">100% correto (tipo próprio)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Encaminhamentos INSS esquecidos</td><td class="py-3 px-4">12-18%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">0% (trigger automático)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Prontidão para auditoria</td><td class="py-3 px-4">Reconstruído manualmente</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Gerado automaticamente</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">ANAC RBAC 117. LATAM Airlines, GOL, Azul. (PT: TAP, EASA FTL EU-OPS.) Resultados: modelo de simulação Gosign.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">Na simulação, o Decision Layer atinge uma quota Zero-Touch de 78%. A quota menor reflete a alta densidade regulatória: conflitos de Crew-Pairing, classificação de Medical Grounding e casos limítrofes de RBAC 117 exigem decisões humanas com mais frequência. Para os 78%, existe um dossiê de decisão completo e à prova de auditoria.</p>
</div>
</section>

<!-- Referência de Arquitetura -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Arquitetura e implementação</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">O Leave Decision Layer opera integralmente na sua infraestrutura. Para a aviação, isso significa: integração com sistemas de gestão de tripulação, rastreamento RBAC 117, base de dados médicos e Audit Trail completo. Projetos piloto típicos iniciam com um grupo de pessoal (ex.: solo) e expandem para cockpit e cabine.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/br/servicos/hr-agent/leave-absence-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Visão geral Leave Decision Layer &rarr;</a>
<a href="/br/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Arquitetura do Decision Layer &rarr;</a>
<a href="/br/servicos/infraestrutura/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infraestrutura em detalhe &rarr;</a>
<a href="/br/governance/co-determination/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Codecisão &rarr;</a>
<a href="/br/servicos/hr-agent/payroll-decision-layer/aviation/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Payroll Decision Layer Aviação &rarr;</a>
</div>
</div>
</section>


<!-- Weitere Agent-Lösungen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Mais soluções de agentes</h2>
<p class="text-body-lg text-gosign-text-light mt-4">HR Agents fazem parte do nosso portfólio de agentes. Para finanças e outras áreas, oferecemos soluções especializadas.</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8 max-w-content">
<a href="/br/hr-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR & People Operations</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Todos os HR Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Compatível com sindicato/CRE.</p>
</a>
<a href="/br/finance-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Finance & Accounting</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Finance AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Processamento de documentos, contabilização, depreciação, correções. Integração SAP/ERP.</p>
</a>
<a href="/br/contato/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Individual</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Co-Build para seu processo</h3>
<p class="text-body text-gosign-text-light mt-2">Compliance, operações, shared services - desenvolvemos agentes em modelo co-build.</p>
</a>
</div>
</div>
</section>

<!-- Aprofundamento -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Aprofundamento no Agent Briefing (Revista Gosign)</h2>
<p class="text-body text-gosign-text-light mb-6">Nossa série de artigos especializados para gestores que implementam AI Agents na empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/br/revista/comite-empresa-ia-codecisao/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Participação</p>
<p class="text-body font-semibold text-gosign-dark">Sindicato e IA - participação dos trabalhadores como restrição arquitetônica</p>
</a>
<a href="/br/revista/agent-governance-hr/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Agent Governance para HR - por que motores de regras importam mais que modelos</p>
</a>
<a href="/br/revista/decision-layer-explicado/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Fundamentos</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - o que é e por que todo AI Agent empresarial precisa de um?</p>
</a>
</div>
</div>
</section>

<!-- Outros Setores -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Leave Decision Layer em outros setores</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Cada setor tem suas próprias convenções, seus próprios tipos de ausência e seus próprios fatores de complexidade. O Decision Layer é o mesmo. A configuração é específica por setor.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/br/servicos/hr-agent/leave-absence-decision-layer/chemicals/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3"><h3 class="text-h3 font-bold text-gosign-dark">Química</h3><div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div></div>
<p class="text-small text-gosign-text-light">Convenções regionais, turno contínuo, exposição NR-15, lotação mínima</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between"><span class="text-body font-bold text-gosign-accent-text">83% Zero-Touch</span><span class="text-small text-gosign-accent-text font-semibold">Em detalhe &rarr;</span></div>
</a>
<a href="/br/servicos/hr-agent/leave-absence-decision-layer/financial-services/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3"><h3 class="text-h3 font-bold text-gosign-dark">Serviços financeiros</h3><div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div></div>
<p class="text-small text-gosign-text-light">Férias obrigatórias em bloco (Bacen), feriados bancários, aposentadoria parcial</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between"><span class="text-body font-bold text-gosign-accent-text">85% Zero-Touch</span><span class="text-small text-gosign-accent-text font-semibold">Em detalhe &rarr;</span></div>
</a>
<a href="/br/servicos/hr-agent/leave-absence-decision-layer/retail/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3"><h3 class="text-h3 font-bold text-gosign-dark">Varejo</h3><div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div></div>
<p class="text-small text-gosign-text-light">6 dias/semana, 64% jornada parcial, bloqueios sazonais, convenções regionais</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between"><span class="text-body font-bold text-gosign-accent-text">87% Zero-Touch</span><span class="text-small text-gosign-accent-text font-semibold">Em detalhe &rarr;</span></div>
</a>
</div>
</div>
</section>

--- AI Leave Agent Química - gestão de ausências ---
> Leave Decision Layer para a indústria química. Convenções regionais, adicional de férias por turno, NR-15. 83% Zero-Touch.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/br/por-que-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">PL 2338/2023 ready</p>
<p class="text-xs text-gosign-text-light">Cada decisão rastreável</p>
</div>
</a>
<a href="/br/por-que-gosign/#infraestrutura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Sua infraestrutura</p>
<p class="text-xs text-gosign-text-light">Sem SaaS. Sem vendor lock-in.</p>
</div>
</a>
<a href="/br/por-que-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Dados no Brasil</p>
<p class="text-xs text-gosign-text-light">Sem risco de cloud estrangeiro</p>
</div>
</a>
</div>
</div>
</div>



<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Leave Decision Layer Setores">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/br/servicos/hr-agent/leave-absence-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Leave Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/br/servicos/hr-agent/leave-absence-decision-layer/chemicals/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Química</a>
<a href="/br/servicos/hr-agent/leave-absence-decision-layer/aviation/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Aviação</a>
<a href="/br/servicos/hr-agent/leave-absence-decision-layer/financial-services/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Serviços financeiros</a>
<a href="/br/servicos/hr-agent/leave-absence-decision-layer/retail/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Varejo</a>
</div>
</div>
</nav>

<!-- Complexidade -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">30+</span>
<p class="text-small text-gosign-text-light mt-1">Tipos de ausência</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">83%</span>
<p class="text-small text-gosign-text-light mt-1">Quota Zero-Touch</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">NR-15</span>
<p class="text-small text-gosign-text-light mt-1">Exposição a agentes químicos</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">Máxima complexidade de regras</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">Convenções regionais Sindicato dos Químicos / ABIQUIM. (PT: Sindicatos setoriais / ACT.) Zero-Touch: modelo de simulação Gosign.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">O que o Agent classifica</p>
<h2 class="text-h1 font-bold text-gosign-dark">Cinco dimensões, um Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">30 dias de férias-base (CLT Art. 129), adicional de férias por turno contínuo, fracionamento em 3 períodos, afastamento com exposição a agentes químicos (NR-15), lotação mínima em produção contínua. Você conhece a complexidade. Assim o AI Agent a resolve:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Adicional de férias por modelo de turno</h3>
<p class="text-body text-gosign-text mt-2">Turno contínuo 5 dias, turno parcial 3 dias, turno alternado 2 dias. O AI Agent reconhece o modelo de turno a partir da escala e atribui o adicional correto de férias. Em mudança de modelo de turno, o conjunto de regras calcula o direito proporcional automaticamente - sem recálculo manual para milhares de trabalhadores de turno.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Fracionamento de férias (CLT Art. 134)</h3>
<p class="text-body text-gosign-text mt-2">A Reforma Trabalhista permite fracionamento em até 3 períodos (mínimo 14 + 5 + 5 dias). O AI Agent gerencia as opções individuais de fracionamento, verifica prazos do período concessivo e garante que cada período atenda aos requisitos mínimos. Em mudança de preferência: atualização automática a partir do próximo período aquisitivo.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Afastamento com exposição a agentes químicos (NR-15)</h3>
<p class="text-body text-gosign-text mt-2">Em afastamento prolongado de colaboradores com exposição a agentes químicos (conforme PGR/PPRA e NR-15), a relevância para acompanhamento de medicina ocupacional é particularmente alta. O AI Agent reconhece a exposição a partir da avaliação de riscos e sinaliza casos para acompanhamento de saúde ocupacional. Dados de saúde permanecem arquitetonicamente separados.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Lotação mínima em produção contínua</h3>
<p class="text-body text-gosign-text mt-2">Na produção química, o processo opera 24 horas. O AI Agent verifica a cada pedido de férias a ocupação da escala contra as regras de lotação mínima por turno e qualificação. Em caso de descumprimento: escalação automática com sugestão alternativa em vez de recusa genérica.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Férias por tempo de serviço por convenção</h3>
<p class="text-body text-gosign-text mt-2">Convenções coletivas da indústria química frequentemente concedem dias adicionais de férias por tempo de serviço. O AI Agent calcula o adicional automaticamente a partir da data de admissão e da convenção aplicável. Em atingimento de marcos durante o ano: cálculo proporcional a partir da data relevante.</p>
</div>
</div>
</div>
</section>

<!-- Decision Flow -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Um pedido de férias na química. 10 etapas de decisão.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Um trabalhador de turno na indústria química solicita férias. O Leave Decision Layer decompõe o processo em etapas de decisão individuais:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Etapa</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decisão</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decisor</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Fundamentação</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Classificar tipo de ausência</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent reconhece: férias, adicional de férias por turno, licença especial ou dia de folga compensatória</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Reconhecer convenção regional e modelo de turno</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent reconhece unidade, convenção regional e modelo de turno a partir do cadastro de pessoal e da escala</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Calcular direito total</td><td class="py-3 px-4">Regra</td><td class="py-3 px-4">30 dias base + adicional por turno (2-5) + férias por tempo de serviço + dias adicionais por convenção</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Calcular saldo restante</td><td class="py-3 px-4">Regra</td><td class="py-3 px-4">Direito total menos dias gozados e aprovados, incluindo saldo de período anterior</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Verificar lotação mínima da escala</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent verifica ocupação da escala contra regras de lotação mínima por qualificação</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Reconhecer conflitos de equipe</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent verifica: bloqueios entre colegas, pedidos paralelos, quota máxima de ausência simultânea</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Gerar recomendação de aprovação</td><td class="py-3 px-4">IA recomenda, humano decide</td><td class="py-3 px-4">Todas as regras atendidas: recomendação de aprovação. Conflito: escalação com contexto ao gestor</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">Verificar limiar de afastamento</td><td class="py-3 px-4">Regra</td><td class="py-3 px-4">15+ dias de atestado: responsabilidade do empregador. A partir do 16o dia: encaminhamento INSS. Em exposição a agentes químicos: sinalização adicional</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Calcular pagamento de férias + 1/3</td><td class="py-3 px-4">Regra</td><td class="py-3 px-4">Remuneração + 1/3 constitucional. Abono pecuniário se solicitado. Pagamento até 2 dias antes do início</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Gerar registro de auditoria</td><td class="py-3 px-4">Regra</td><td class="py-3 px-4">Dossiê de decisão completo: tipo de ausência, direito, etapas de verificação, resultado, timestamp</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Simulação -->
<section id="simulacao" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulação</p>
<h2 class="text-h1 font-bold text-white">Calculado para volumes da indústria química</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Configuramos o Leave Decision Layer com parâmetros realistas da indústria química brasileira. Convenções regionais Sindicato dos Químicos / ABIQUIM, modelos de turno, NR-15, produção contínua.</p>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Parâmetros da simulação</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Colaboradores</td><td class="py-3 px-4">5.000 a 50.000+ (produção, laboratório, administração)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Convenção coletiva</td><td class="py-3 px-4">Sindicato dos Químicos / ABIQUIM, convenções regionais</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Férias-base</td><td class="py-3 px-4">30 dias (CLT Art. 129) + adicional por turno (2-5 dias) + férias por tempo de serviço</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Modelos de turno</td><td class="py-3 px-4">Turno contínuo, turno parcial, turno alternado, jornada normal</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Fracionamento</td><td class="py-3 px-4">Até 3 períodos (CLT Art. 134, Reforma Trabalhista 2017)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">NR-15</td><td class="py-3 px-4">Exposição a agentes químicos, acompanhamento de medicina ocupacional</td></tr>
</tbody>
</table>
</div>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Antes / Depois</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th scope="col" class="text-left py-3 px-4 font-semibold text-white">Dimensão</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manual</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Tempo de processamento de pedido de férias</td><td class="py-3 px-4">1-3 dias</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 30 segundos</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Quota Zero-Touch</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">83%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Prazos de encaminhamento INSS perdidos</td><td class="py-3 px-4">12-18% (rastreamento manual)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">0% (trigger automático)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Avisos de perda de férias (CLT Art. 137)</td><td class="py-3 px-4">Frequentemente esquecidos</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automáticos, pontuais, individuais</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Cálculo de adicional de férias por turno</td><td class="py-3 px-4">Manual, propenso a erros</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Baseado em regras, consistente</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Prontidão para auditoria</td><td class="py-3 px-4">Reconstruído manualmente</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Gerado automaticamente</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">Convenções regionais Sindicato dos Químicos / ABIQUIM. CLT Art. 129-145. Resultados: modelo de simulação Gosign.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">Na simulação, o Decision Layer atinge uma quota Zero-Touch de 83%. Os 17% restantes são exceções reais: conflitos de férias em lotação mínima, processos de afastamento com exposição a agentes químicos, alterações de fracionamento com impacto fiscal. Para os 83%, existe um dossiê de decisão completo e à prova de auditoria.</p>
</div>
</section>

<!-- Referência de Arquitetura -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Arquitetura e implementação</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">O Leave Decision Layer opera integralmente na sua infraestrutura. Para a indústria química, isso significa: integração com sistemas de escala de turnos, processamento de avaliações NR-15, conjuntos de regras específicos por convenção regional e Audit Trail completo até o sistema de RH. Projetos piloto típicos iniciam em até 3 meses com uma convenção e um grupo de pessoal.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/br/servicos/hr-agent/leave-absence-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Visão geral Leave Decision Layer &rarr;</a>
<a href="/br/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Arquitetura do Decision Layer &rarr;</a>
<a href="/br/servicos/infraestrutura/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infraestrutura em detalhe &rarr;</a>
<a href="/br/governance/co-determination/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Codecisão &rarr;</a>
<a href="/br/servicos/hr-agent/payroll-decision-layer/chemicals/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Payroll Decision Layer Química &rarr;</a>
</div>
</div>
</section>


<!-- Weitere Agent-Lösungen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Mais soluções de agentes</h2>
<p class="text-body-lg text-gosign-text-light mt-4">HR Agents fazem parte do nosso portfólio de agentes. Para finanças e outras áreas, oferecemos soluções especializadas.</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8 max-w-content">
<a href="/br/hr-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR & People Operations</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Todos os HR Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Compatível com sindicato/CRE.</p>
</a>
<a href="/br/finance-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Finance & Accounting</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Finance AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Processamento de documentos, contabilização, depreciação, correções. Integração SAP/ERP.</p>
</a>
<a href="/br/contato/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Individual</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Co-Build para seu processo</h3>
<p class="text-body text-gosign-text-light mt-2">Compliance, operações, shared services - desenvolvemos agentes em modelo co-build.</p>
</a>
</div>
</div>
</section>

<!-- Aprofundamento -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Aprofundamento no Agent Briefing (Revista Gosign)</h2>
<p class="text-body text-gosign-text-light mb-6">Nossa série de artigos especializados para gestores que implementam AI Agents na empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/br/revista/comite-empresa-ia-codecisao/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Participação</p>
<p class="text-body font-semibold text-gosign-dark">Sindicato e IA - participação dos trabalhadores como restrição arquitetônica</p>
</a>
<a href="/br/revista/agent-governance-hr/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Agent Governance para HR - por que motores de regras importam mais que modelos</p>
</a>
<a href="/br/revista/decision-layer-explicado/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Fundamentos</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - o que é e por que todo AI Agent empresarial precisa de um?</p>
</a>
</div>
</div>
</section>

<!-- Outros Setores -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Leave Decision Layer em outros setores</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Cada setor tem suas próprias convenções coletivas, seus próprios tipos de ausência e seus próprios fatores de complexidade. O Decision Layer é o mesmo. A configuração é específica por setor.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/br/servicos/hr-agent/leave-absence-decision-layer/aviation/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Aviação</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">3 sindicatos, ANAC RBAC 117 descansos obrigatórios, Medical Grounding, Crew-Pairing</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">78% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Em detalhe &rarr;</span>
</div>
</a>
<a href="/br/servicos/hr-agent/leave-absence-decision-layer/financial-services/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Serviços financeiros</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">Férias obrigatórias em bloco, requisitos Bacen/CVM, feriados bancários, aposentadoria progressiva</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">85% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Em detalhe &rarr;</span>
</div>
</a>
<a href="/br/servicos/hr-agent/leave-absence-decision-layer/retail/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Varejo</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">6 dias por semana, 64% jornada parcial, bloqueios sazonais, contratos intermitentes</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">87% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Em detalhe &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- AI Leave Agent Finanças - gestão de ausências ---
> Leave Decision Layer para bancos e seguradoras. Férias obrigatórias em bloco, Bacen/CVM, feriados bancários. 85% Zero-Touch.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/br/por-que-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div><p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">PL 2338/2023 ready</p><p class="text-xs text-gosign-text-light">Cada decisão rastreável</p></div>
</a>
<a href="/br/por-que-gosign/#infraestrutura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div><p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Sua infraestrutura</p><p class="text-xs text-gosign-text-light">Sem SaaS. Sem vendor lock-in.</p></div>
</a>
<a href="/br/por-que-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div><p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Dados no Brasil</p><p class="text-xs text-gosign-text-light">Sem risco de cloud estrangeiro</p></div>
</a>
</div>
</div>
</div>
<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Leave Decision Layer Setores">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/br/servicos/hr-agent/leave-absence-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Leave Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/br/servicos/hr-agent/leave-absence-decision-layer/chemicals/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Química</a>
<a href="/br/servicos/hr-agent/leave-absence-decision-layer/aviation/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Aviação</a>
<a href="/br/servicos/hr-agent/leave-absence-decision-layer/financial-services/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Serviços financeiros</a>
<a href="/br/servicos/hr-agent/leave-absence-decision-layer/retail/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Varejo</a>
</div>
</div>
</nav>

<!-- Complexidade -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div><span class="text-h1 font-bold text-gosign-accent-text">5</span><p class="text-small text-gosign-text-light mt-1">Regimes de remuneração</p></div>
<div><span class="text-h1 font-bold text-gosign-accent-text">85%</span><p class="text-small text-gosign-text-light mt-1">Quota Zero-Touch</p></div>
<div><span class="text-h1 font-bold text-gosign-accent-text">Bacen</span><p class="text-small text-gosign-text-light mt-1">Blocos obrigatórios</p></div>
<div><div class="flex gap-1 mt-2"><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-border"></span></div><p class="text-small text-gosign-text-light mt-1">Alta complexidade de regras</p></div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">Convenção CONTRAF (bancários), SEEB (seguros). Itaú, Bradesco, Santander BR. (PT: Banco de Portugal, CMVM.) Zero-Touch: modelo de simulação Gosign.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">O que o Agent classifica</p>
<h2 class="text-h1 font-bold text-gosign-dark">Cinco dimensões, um Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Férias obrigatórias em bloco por princípio de quatro olhos, blocos regulatórios Bacen/CVM, feriados bancários, aposentadoria parcial progressiva e 5 regimes de remuneração paralelos. Você conhece a complexidade. Assim o AI Agent a resolve:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Férias obrigatórias em bloco (quatro olhos)</h3>
<p class="text-body text-gosign-text mt-2">Colaboradores em posições sensíveis devem ser afastados por pelo menos 10 dias úteis consecutivos ao ano. O AI Agent reconhece posições obrigatórias a partir do cadastro de pessoal, verifica se as férias solicitadas cumprem a duração mínima e rastreia se a obrigação já foi cumprida no ano corrente.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Blocos obrigatórios Bacen/CVM</h3>
<p class="text-body text-gosign-text mt-2">A regulação do Bacen e CVM exige blocos de férias consecutivas para colaboradores em posições de risco. O AI Agent rastreia o prazo, alerta tempestivamente quando o bloco obrigatório está faltando e documenta o cumprimento no Audit Trail. Na fiscalização: exportação do status completo de compliance por colaborador. (PT: Banco de Portugal e CMVM com exigências equivalentes.)</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Feriados bancários e calendário de negociação</h3>
<p class="text-body text-gosign-text mt-2">Feriados bancários não são feriados em todos os estados, mas são operacionalmente relevantes para áreas de negociação. O AI Agent conhece o calendário por unidade e praça e considera feriados bancários no planejamento de lotação automaticamente - sem conciliação manual de calendários.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Aposentadoria parcial progressiva</h3>
<p class="text-body text-gosign-text mt-2">A aposentadoria parcial progressiva é comum no setor financeiro brasileiro. O AI Agent calcula o direito a férias corretamente por fase: direito proporcional à jornada durante o período de redução. Em mudança de modelo: recálculo automático do direito. Impactos previdenciários são reportados ao sistema de folha.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Cinco regimes de remuneração em paralelo</h3>
<p class="text-body text-gosign-text mt-2">Convenção bancária CONTRAF, convenção seguros SEEB, contratos de executivos, diretores estatutários, Risk Takers - cada regime tem regras de férias e licenças próprias. O AI Agent reconhece o regime a partir do cadastro de pessoal e aplica o conjunto de regras correto. Um Agent para todos os cinco regimes.</p>
</div>
</div>
</div>
</section>

<!-- Decision Flow -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Um pedido de férias no setor financeiro. 10 etapas de decisão.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Um operador de mesa solicita férias. O Leave Decision Layer decompõe o processo em etapas de decisão individuais:</p>
<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead><tr class="border-b-2 border-gosign-border"><th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Etapa</th><th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decisão</th><th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decisor</th><th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Fundamentação</th></tr></thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Classificar tipo de ausência</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent reconhece: férias, férias obrigatórias em bloco, aposentadoria parcial ou licença</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Reconhecer regime de remuneração</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent reconhece: CONTRAF, SEEB, executivo, diretor estatutário ou Risk Taker</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Calcular direito a férias</td><td class="py-3 px-4">Regra</td><td class="py-3 px-4">30 dias base CLT ou direito individual (executivo/diretor) + correção aposentadoria parcial</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Verificar férias obrigatórias em bloco</td><td class="py-3 px-4">Regra</td><td class="py-3 px-4">Posição sensível? Duração mínima atingida? Bloco já cumprido no ano corrente?</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Verificar blocos Bacen/CVM</td><td class="py-3 px-4">Regra</td><td class="py-3 px-4">Posição de risco? Bloco consecutivo obrigatório já planejado?</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Verificar feriados bancários e lotação</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent verifica calendário bancário, lotação mínima da área, regra de substituição</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Gerar recomendação de aprovação</td><td class="py-3 px-4">IA recomenda, humano decide</td><td class="py-3 px-4">Todas as regras e checks de compliance aprovados: recomendação. Conflito de compliance: escalação</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">Monitorar limiar de afastamento INSS</td><td class="py-3 px-4">Regra</td><td class="py-3 px-4">15 dias empregador, a partir do 16o dia INSS. Trigger automático ao RH</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Calcular pagamento de férias + 1/3</td><td class="py-3 px-4">Regra</td><td class="py-3 px-4">Remuneração + 1/3 constitucional, adicionais por convenção</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Gerar registro de auditoria</td><td class="py-3 px-4">Regra</td><td class="py-3 px-4">Dossiê completo: tipo, regime, status compliance, check Bacen, resultado</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Simulação -->
<section id="simulacao" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulação</p>
<h2 class="text-h1 font-bold text-white">Calculado para volumes do setor financeiro</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Configuramos o Leave Decision Layer com parâmetros realistas do setor financeiro. Férias obrigatórias em bloco, Bacen/CVM, feriados bancários, aposentadoria parcial.</p>
<h3 class="text-h3 font-bold text-white mt-10 mb-4">Parâmetros da simulação</h3>
<div class="overflow-x-auto">
<table class="w-full text-small"><tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Colaboradores</td><td class="py-3 px-4">5.000 a 80.000+ (mesa, operações, administração)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Convenções</td><td class="py-3 px-4">CONTRAF (bancários), SEEB (seguros), contratos executivos, diretores</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Regulatória</td><td class="py-3 px-4">Bacen, CVM, férias obrigatórias em bloco</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Tipos de ausência</td><td class="py-3 px-4">Férias, bloco obrigatório, aposentadoria parcial, licença</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Restrições</td><td class="py-3 px-4">Quatro olhos, feriados bancários, lotação mínima mesa</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Afastamento</td><td class="py-3 px-4">Taxa do setor de serviços financeiros</td></tr>
</tbody></table>
</div>
<h3 class="text-h3 font-bold text-white mt-10 mb-4">Antes / Depois</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead><tr class="border-b-2 border-white/20"><th scope="col" class="text-left py-3 px-4 font-semibold text-white">Dimensão</th><th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manual</th><th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th></tr></thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Tempo de processamento</td><td class="py-3 px-4">1-3 dias</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 30 segundos</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Quota Zero-Touch</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">85%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Bloco obrigatório não cumprido</td><td class="py-3 px-4">8-15% (monitoramento manual)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">0% (monitoramento automático)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Férias obrigatórias em bloco</td><td class="py-3 px-4">Verificação manual</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automático, pronto para fiscalização</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Encaminhamentos INSS esquecidos</td><td class="py-3 px-4">12-18%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">0% (trigger automático)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Prontidão para auditoria</td><td class="py-3 px-4">Reconstruído manualmente</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Gerado automaticamente</td></tr>
</tbody>
</table>
</div>
<p class="text-xs text-gosign-text-on-dark/70 mt-4">Bacen, CVM. CONTRAF/SEEB. Itaú, Bradesco, Santander BR. (PT: Banco de Portugal, CMVM.) Resultados: modelo de simulação Gosign.</p>
<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">Na simulação, o Decision Layer atinge uma quota Zero-Touch de 85%. Os 15% restantes são exceções de compliance: conflitos de bloco obrigatório, transições de aposentadoria parcial, acordos individuais de executivos. Para os 85%, existe um dossiê de decisão completo e pronto para fiscalização do Bacen.</p>
</div>
</section>

<!-- Referência de Arquitetura -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Arquitetura e implementação</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">O Leave Decision Layer opera integralmente na sua infraestrutura. Para o setor financeiro, isso significa: integração com calendários bancários, rastreamento de compliance Bacen/CVM, monitoramento de blocos obrigatórios e Audit Trail completo. Projetos piloto típicos iniciam com um regime de remuneração e expandem para todos os grupos de pessoal.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/br/servicos/hr-agent/leave-absence-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Visão geral Leave Decision Layer &rarr;</a>
<a href="/br/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Arquitetura do Decision Layer &rarr;</a>
<a href="/br/servicos/infraestrutura/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infraestrutura em detalhe &rarr;</a>
<a href="/br/governance/co-determination/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Codecisão &rarr;</a>
<a href="/br/servicos/hr-agent/payroll-decision-layer/financial-services/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Payroll Decision Layer Finanças &rarr;</a>
</div>
</div>
</section>


<!-- Weitere Agent-Lösungen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Mais soluções de agentes</h2>
<p class="text-body-lg text-gosign-text-light mt-4">HR Agents fazem parte do nosso portfólio de agentes. Para finanças e outras áreas, oferecemos soluções especializadas.</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8 max-w-content">
<a href="/br/hr-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR & People Operations</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Todos os HR Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Compatível com sindicato/CRE.</p>
</a>
<a href="/br/finance-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Finance & Accounting</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Finance AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Processamento de documentos, contabilização, depreciação, correções. Integração SAP/ERP.</p>
</a>
<a href="/br/contato/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Individual</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Co-Build para seu processo</h3>
<p class="text-body text-gosign-text-light mt-2">Compliance, operações, shared services - desenvolvemos agentes em modelo co-build.</p>
</a>
</div>
</div>
</section>

<!-- Aprofundamento -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Aprofundamento no Agent Briefing (Revista Gosign)</h2>
<p class="text-body text-gosign-text-light mb-6">Nossa série de artigos especializados para gestores que implementam AI Agents na empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/br/revista/comite-empresa-ia-codecisao/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Participação</p>
<p class="text-body font-semibold text-gosign-dark">Sindicato e IA - participação dos trabalhadores como restrição arquitetônica</p>
</a>
<a href="/br/revista/agent-governance-hr/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Agent Governance para HR - por que motores de regras importam mais que modelos</p>
</a>
<a href="/br/revista/decision-layer-explicado/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Fundamentos</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - o que é e por que todo AI Agent empresarial precisa de um?</p>
</a>
</div>
</div>
</section>

<!-- Outros Setores -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Leave Decision Layer em outros setores</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Cada setor tem suas próprias convenções, seus próprios tipos de ausência e seus próprios fatores de complexidade. O Decision Layer é o mesmo. A configuração é específica por setor.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/br/servicos/hr-agent/leave-absence-decision-layer/chemicals/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3"><h3 class="text-h3 font-bold text-gosign-dark">Química</h3><div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div></div>
<p class="text-small text-gosign-text-light">Convenções regionais, turno contínuo, exposição NR-15, lotação mínima</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between"><span class="text-body font-bold text-gosign-accent-text">83% Zero-Touch</span><span class="text-small text-gosign-accent-text font-semibold">Em detalhe &rarr;</span></div>
</a>
<a href="/br/servicos/hr-agent/leave-absence-decision-layer/aviation/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3"><h3 class="text-h3 font-bold text-gosign-dark">Aviação</h3><div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div></div>
<p class="text-small text-gosign-text-light">3 sindicatos, ANAC descansos regulatórios, Medical Grounding, Crew-Pairing</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between"><span class="text-body font-bold text-gosign-accent-text">78% Zero-Touch</span><span class="text-small text-gosign-accent-text font-semibold">Em detalhe &rarr;</span></div>
</a>
<a href="/br/servicos/hr-agent/leave-absence-decision-layer/retail/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3"><h3 class="text-h3 font-bold text-gosign-dark">Varejo</h3><div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div></div>
<p class="text-small text-gosign-text-light">6 dias/semana, 64% jornada parcial, bloqueios sazonais, convenções regionais</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between"><span class="text-body font-bold text-gosign-accent-text">87% Zero-Touch</span><span class="text-small text-gosign-accent-text font-semibold">Em detalhe &rarr;</span></div>
</a>
</div>
</div>
</section>

--- AI Leave Agent Varejo - gestão de ausências ---
> Leave Decision Layer para o varejo. 6 dias/semana, 64% jornada parcial, bloqueios sazonais, convenções por estado. 87% Zero-Touch.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/br/por-que-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">PL 2338/2023 ready</p>
<p class="text-xs text-gosign-text-light">Cada decisão rastreável</p>
</div>
</a>
<a href="/br/por-que-gosign/#infraestrutura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Sua infraestrutura</p>
<p class="text-xs text-gosign-text-light">Sem SaaS. Sem vendor lock-in.</p>
</div>
</a>
<a href="/br/por-que-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Dados no Brasil</p>
<p class="text-xs text-gosign-text-light">Sem risco de cloud estrangeiro</p>
</div>
</a>
</div>
</div>
</div>
<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Leave Decision Layer Setores">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/br/servicos/hr-agent/leave-absence-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Leave Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/br/servicos/hr-agent/leave-absence-decision-layer/chemicals/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Química</a>
<a href="/br/servicos/hr-agent/leave-absence-decision-layer/aviation/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Aviação</a>
<a href="/br/servicos/hr-agent/leave-absence-decision-layer/financial-services/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Serviços financeiros</a>
<a href="/br/servicos/hr-agent/leave-absence-decision-layer/retail/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Varejo</a>
</div>
</div>
</nav>

<!-- Complexidade -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">27</span>
<p class="text-small text-gosign-text-light mt-1">Convenções por estado + DF</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">87%</span>
<p class="text-small text-gosign-text-light mt-1">Quota Zero-Touch</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">64%</span>
<p class="text-small text-gosign-text-light mt-1">Jornada parcial</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
<span class="w-4 h-2 rounded-sm bg-gosign-border"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">Alta complexidade de regras</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">Convenções coletivas do comércio varejista (Sindicato dos Comerciários / CONTRACS), 26 estados + DF. (PT: Sindicatos do comércio, 18 distritos + regiões autónomas.) Zero-Touch: modelo de simulação Gosign.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">O que o Agent classifica</p>
<h2 class="text-h1 font-bold text-gosign-dark">Cinco dimensões, um Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">6 dias por semana com trabalho aos sábados, 64% jornada parcial, bloqueios sazonais de férias, contratos intermitentes com períodos de inatividade e convenções coletivas por estado. Você conhece a complexidade. Assim o AI Agent a resolve:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Escala de 6 dias e cálculo de férias</h3>
<p class="text-body text-gosign-text mt-2">No varejo brasileiro, sábado é dia regular de trabalho. A CLT garante 30 dias corridos de férias, independentemente do modelo de jornada. O AI Agent reconhece o modelo de escala a partir do cadastro de pessoal e calcula o direito automaticamente, incluindo o 1/3 constitucional e opção de abono pecuniário. Em mudança entre escala de 5 e 6 dias: recálculo proporcional a partir da data de alteração.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Férias proporcionais para 64% de jornada parcial</h3>
<p class="text-body text-gosign-text mt-2">Mais da metade dos colaboradores no varejo trabalham em jornada parcial - com modelos diversos. O AI Agent calcula o direito proporcional por modelo: CLT parcial (Art. 130-A), contrato intermitente (Lei 13.467), prazo determinado (Art. 443). O conjunto de regras aplica a fórmula correta, consistente em todas as lojas. (PT: Em Portugal, o cálculo proporcional segue o Art. 239 do Código do Trabalho.)</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Bloqueios sazonais de férias</h3>
<p class="text-body text-gosign-text mt-2">Natal (novembro a dezembro), Black Friday, inventário - o varejo tem períodos claros de bloqueio. O AI Agent conhece os períodos de bloqueio por loja (nem todas as lojas têm os mesmos bloqueios) e verifica cada pedido contra eles. Exceções são possíveis, mas exigem decisão do gestor com fundamentação obrigatória.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Férias de contratos intermitentes</h3>
<p class="text-body text-gosign-text mt-2">O contrato intermitente (Lei 13.467/2017) gera direito proporcional de férias com 1/3 a cada período de convocação. O AI Agent monitora cada contrato: períodos ativos, inatividade, cálculo proporcional de férias e 1/3. Em mudança entre intermitente e CLT integral: recálculo automático do saldo com base no novo enquadramento.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Convenções coletivas por estado</h3>
<p class="text-body text-gosign-text mt-2">O Sindicato dos Comerciários / CONTRACS negocia em cada estado, com regras de férias que podem variar regionalmente. O AI Agent reconhece a localização da loja e aplica a convenção estadual correta. Em transferência de loja entre estados: alteração automática da convenção com recálculo de direitos.</p>
</div>
</div>
</div>
</section>

<!-- Decision Flow -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Um pedido de férias no varejo. 10 etapas de decisão.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Uma colaboradora de jornada parcial em uma loja solicita férias. O Leave Decision Layer decompõe o processo em etapas de decisão individuais:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Etapa</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decisão</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decisor</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Fundamentação</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Classificar tipo de ausência</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent reconhece: férias, licença especial, atestado médico ou folga compensatória</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Reconhecer convenção estadual</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent reconhece localização da loja e aplica a convenção do Sindicato dos Comerciários do estado</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Calcular direito a férias</td><td class="py-3 px-4">Regra</td><td class="py-3 px-4">30 dias CLT, proporcional por tipo de contrato (parcial, intermitente, prazo determinado), fracionamento em até 3 períodos</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Verificar bloqueio sazonal</td><td class="py-3 px-4">Regra</td><td class="py-3 px-4">Natal, Black Friday, inventário - períodos de bloqueio por loja</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Verificar lotação mínima da loja</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent verifica escala: lojas pequenas com 2-3 colaboradores, cada ausência conta</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Reconhecer conflitos de equipe</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent verifica pedidos paralelos, distribuição de férias escolares (critérios sociais)</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Gerar recomendação de aprovação</td><td class="py-3 px-4">IA recomenda, humano decide</td><td class="py-3 px-4">Todas as regras atendidas: recomendação de aprovação. Bloqueio ou lotação mínima violada: escalação</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">Verificar limiar de afastamento</td><td class="py-3 px-4">Regra</td><td class="py-3 px-4">15+ dias de atestado: responsabilidade do empregador. A partir do 16o dia: encaminhamento INSS</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Calcular pagamento de férias + 1/3</td><td class="py-3 px-4">Regra</td><td class="py-3 px-4">Remuneração + 1/3 constitucional. Abono pecuniário se solicitado. Pagamento até 2 dias antes do início</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Gerar registro de auditoria</td><td class="py-3 px-4">Regra</td><td class="py-3 px-4">Dossiê de decisão completo: tipo de ausência, convenção, tipo de contrato, verificações, resultado</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Simulação -->
<section id="simulacao" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulação</p>
<h2 class="text-h1 font-bold text-white">Calculado para volumes do varejo</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Configuramos o Leave Decision Layer com parâmetros realistas do varejo brasileiro. Convenções estaduais do Sindicato dos Comerciários, 6 dias por semana, 64% jornada parcial, bloqueios sazonais, contratos intermitentes.</p>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Parâmetros da simulação</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Colaboradores</td><td class="py-3 px-4">5.000 a 100.000+ (lojas, centros de distribuição, administração)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Convenção coletiva</td><td class="py-3 px-4">Comércio varejista, 26 estados + DF (Sindicato dos Comerciários / CONTRACS)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Modelos de contrato</td><td class="py-3 px-4">CLT integral, CLT parcial, intermitente (Lei 13.467), prazo determinado (Art. 443)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Jornada parcial</td><td class="py-3 px-4">64% dos colaboradores</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Bloqueios sazonais</td><td class="py-3 px-4">Natal, Black Friday, inventário (por loja)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Afastamento</td><td class="py-3 px-4">Limiar INSS (15 dias empregador / 16o dia encaminhamento)</td></tr>
</tbody>
</table>
</div>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Antes / Depois</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th scope="col" class="text-left py-3 px-4 font-semibold text-white">Dimensão</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manual</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Tempo de processamento de pedido de férias</td><td class="py-3 px-4">1-3 dias</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 30 segundos</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Quota Zero-Touch</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">87%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Erros de cálculo proporcional</td><td class="py-3 px-4">5-12% (cálculo manual)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 0,1% (baseado em regras)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Avisos de perda de férias (CLT Art. 137)</td><td class="py-3 px-4">Frequentemente esquecidos em jornada parcial</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automáticos, pontuais, individuais</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Prazos de encaminhamento INSS perdidos</td><td class="py-3 px-4">12-18%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">0% (trigger automático)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Prontidão para auditoria</td><td class="py-3 px-4">Reconstruído manualmente</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Gerado automaticamente</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">Convenções coletivas do comércio varejista (Sindicato dos Comerciários / CONTRACS), 26 estados + DF. CLT Art. 129-145. Referências: Magazine Luiza, GPA. Resultados: modelo de simulação Gosign.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">Na simulação, o Decision Layer atinge uma quota Zero-Touch de 87%. A maior quota entre os quatro setores - porque o varejo é volumoso (muitos pedidos), mas as decisões individuais são resolvíveis por regras. Os 13% restantes são exceções reais: conflitos de férias escolares, exceções a bloqueios, processos de afastamento INSS. Para os 87%, existe um dossiê de decisão completo e à prova de auditoria.</p>
</div>
</section>

<!-- Referência de Arquitetura -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Arquitetura e implementação</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">O Leave Decision Layer opera integralmente na sua infraestrutura. Para o varejo, isso significa: integração com planejamento de escala de lojas, processamento de convenções estaduais, detecção de tipo de contrato (intermitente, parcial, prazo determinado) e Audit Trail completo. Projetos piloto típicos iniciam com um estado e um grupo de lojas.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/br/servicos/hr-agent/leave-absence-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Visão geral Leave Decision Layer &rarr;</a>
<a href="/br/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Arquitetura do Decision Layer &rarr;</a>
<a href="/br/servicos/infraestrutura/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infraestrutura em detalhe &rarr;</a>
<a href="/br/governance/co-determination/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Codecisão &rarr;</a>
<a href="/br/servicos/hr-agent/payroll-decision-layer/retail/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Payroll Decision Layer Varejo &rarr;</a>
</div>
</div>
</section>


<!-- Weitere Agent-Lösungen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Mais soluções de agentes</h2>
<p class="text-body-lg text-gosign-text-light mt-4">HR Agents fazem parte do nosso portfólio de agentes. Para finanças e outras áreas, oferecemos soluções especializadas.</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8 max-w-content">
<a href="/br/hr-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR & People Operations</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Todos os HR Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Compatível com sindicato/CRE.</p>
</a>
<a href="/br/finance-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Finance & Accounting</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Finance AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Processamento de documentos, contabilização, depreciação, correções. Integração SAP/ERP.</p>
</a>
<a href="/br/contato/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Individual</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Co-Build para seu processo</h3>
<p class="text-body text-gosign-text-light mt-2">Compliance, operações, shared services - desenvolvemos agentes em modelo co-build.</p>
</a>
</div>
</div>
</section>

<!-- Aprofundamento -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Aprofundamento no Agent Briefing (Revista Gosign)</h2>
<p class="text-body text-gosign-text-light mb-6">Nossa série de artigos especializados para gestores que implementam AI Agents na empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/br/revista/comite-empresa-ia-codecisao/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Participação</p>
<p class="text-body font-semibold text-gosign-dark">Sindicato e IA - participação dos trabalhadores como restrição arquitetônica</p>
</a>
<a href="/br/revista/agent-governance-hr/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Agent Governance para HR - por que motores de regras importam mais que modelos</p>
</a>
<a href="/br/revista/decision-layer-explicado/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Fundamentos</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - o que é e por que todo AI Agent empresarial precisa de um?</p>
</a>
</div>
</div>
</section>

<!-- Outros Setores -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Leave Decision Layer em outros setores</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Cada setor tem suas próprias convenções coletivas, seus próprios tipos de ausência e seus próprios fatores de complexidade. O Decision Layer é o mesmo. A configuração é específica por setor.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/br/servicos/hr-agent/leave-absence-decision-layer/chemicals/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Química</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">Convenções regionais, adicional de férias por turno, afastamento NR-15, lotação mínima</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">83% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Em detalhe &rarr;</span>
</div>
</a>
<a href="/br/servicos/hr-agent/leave-absence-decision-layer/aviation/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Aviação</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">3 sindicatos, ANAC RBAC 117 descansos obrigatórios, Medical Grounding, Crew-Pairing</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">78% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Em detalhe &rarr;</span>
</div>
</a>
<a href="/br/servicos/hr-agent/leave-absence-decision-layer/financial-services/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Serviços financeiros</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">Férias obrigatórias em bloco, requisitos Bacen/CVM, feriados bancários, aposentadoria progressiva</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">85% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Em detalhe &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- AI Leave Decision Layer - gestão de ausências ---
> Leave & Absence Decision Layer para organizações complexas. 30+ tipos de ausência, convenções coletivas, LGPD. 78-87% Zero-Touch.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/br/por-que-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">PL 2338/2023 ready</p>
<p class="text-xs text-gosign-text-light">Cada decisão rastreável</p>
</div>
</a>
<a href="/br/por-que-gosign/#infraestrutura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Sua infraestrutura</p>
<p class="text-xs text-gosign-text-light">Sem SaaS. Sem vendor lock-in.</p>
</div>
</a>
<a href="/br/por-que-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Dados no Brasil</p>
<p class="text-xs text-gosign-text-light">Sem risco de cloud estrangeiro</p>
</div>
</a>
</div>
</div>
</div>
<!-- Problema -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">30</span>
<p class="text-small text-gosign-text-light mt-1">Dias de férias/ano (CLT Art. 129)</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">15+</span>
<p class="text-small text-gosign-text-light mt-1">Tipos de ausência (CLT, CCT, ACT)</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">5-15</span>
<p class="text-small text-gosign-text-light mt-1">Microdecisões por processo</p>
</div>
<p class="sm:col-span-3 text-xs text-gosign-text-light">CLT Art. 129-145 (férias). Reforma Trabalhista 2017 (fracionamento). Tipos de ausência: férias, licença-maternidade/paternidade, atestado médico, licença casamento, luto, INSS auxílio-doença, convenções coletivas.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">O problema</p>
<h2 class="text-h1 font-bold text-gosign-dark">Por que sistemas de ausências falham em organizações complexas</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">SAP SuccessFactors Time Off registra ausências. Senior Sistemas calcula saldos. Qualquer HRIS pode gerar fluxos de aprovação. Mas em organizações com múltiplas convenções coletivas, 27 estados, modelos de jornada parcial e obrigações de eSocial, o registro não é o problema. A decisão anterior é: qual direito se aplica? Qual CCT tem prioridade? O afastamento deve ser encaminhado ao INSS (PT: Segurança Social)?</p>
<div class="mt-10">
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">15+ tipos de ausência</h3>
<p class="text-small text-gosign-text-light mt-2">Férias, licença-maternidade (120-180 dias), licença-paternidade (5-20 dias), atestado médico, auxílio-doença INSS, licença casamento, luto, serviço militar, convenção coletiva. Cada tipo tem bases legais próprias, prazos próprios, regras de cálculo próprias. 27 estados com convenções regionais diferentes. Nenhum analista de RH conhece todas as regras em todas as regiões.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">Cada atestado gera 4 processos</h3>
<p class="text-small text-gosign-text-light mt-2">Receber atestado médico digital, verificar prazo de pagamento pelo empregador (15 dias pela CLT), monitorar limiar para INSS auxílio-doença (16o dia), informar escala de turnos, atualizar eSocial. Manualmente: quebras de mídia entre quatro sistemas. Encaminhamentos esquecidos ao INSS. Prazos incorretos de responsabilidade do empregador.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">Zero transparência de decisão</h3>
<p class="text-small text-gosign-text-light mt-2">Quando o sindicato (PT: Comissão de Trabalhadores) pergunta: por que as férias do colaborador X foram recusadas? Qual regra se aplicou? Quem decidiu? Falta a comprovação. Sistemas de ausências documentam resultados - pedidos aprovados ou recusados. Não as decisões que levaram a eles.</p>
</div>
</div>
</div>
</div>
</section>

<!-- Princípio do Decision Layer -->
<section id="decision-layer" class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">O Decision Layer</p>
<h2 class="text-h1 font-bold text-gosign-dark">Cada processo de ausência. Decomposto em etapas de decisão.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">O Leave & Absence Decision Layer decompõe cada processo de ausência em etapas de decisão individuais. Para cada etapa está definido quem decide: o AI Agent classifica tipos de ausência, reconhece conflitos e monitora limiares - de forma mais confiável e rápida que qualquer analista de RH. O conjunto de regras calcula direitos, prazos e conversões - de forma determinística e reproduzível. O ser humano permanece onde a CLT, os sindicatos ou a proteção de dados de saúde exigem.</p>

<div class="mt-10 overflow-x-auto">
<table class="w-full text-left text-body">
<thead>
<tr class="border-b-2 border-gosign-dark">
<th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Etapa</th>
<th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Decisão</th>
<th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Decisor</th>
<th scope="col" class="py-3 font-bold text-gosign-dark">Fundamentação</th>
</tr>
</thead>
<tbody class="text-gosign-text-light">
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-medium text-gosign-dark">1</td>
<td class="py-3 pr-4">Classificar tipo de ausência</td>
<td class="py-3 pr-4 font-medium">AI Agent</td>
<td class="py-3">Agent reconhece: férias, licença-maternidade, atestado médico, licença casamento, luto? Atribui base legal correta (CLT, CCT, ACT)</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-medium text-gosign-dark">2</td>
<td class="py-3 pr-4">Calcular direito (hierarquia)</td>
<td class="py-3 pr-4 font-medium">Regra</td>
<td class="py-3">CLT + Convenção Coletiva (CCT) + Acordo Coletivo (ACT) + contrato individual = direito total. Princípio da norma mais favorável</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-medium text-gosign-dark">3</td>
<td class="py-3 pr-4">Calcular saldo restante</td>
<td class="py-3 pr-4 font-medium">Regra</td>
<td class="py-3">Direito menos gozado menos programado = disponível. Fracionamento em até 3 períodos (Reforma Trabalhista 2017: mínimo 14 + 5 + 5 dias)</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-medium text-gosign-dark">4</td>
<td class="py-3 pr-4">Verificar conflitos de equipe e lotação mínima</td>
<td class="py-3 pr-4 font-medium">AI Agent</td>
<td class="py-3">Agent verifica calendário da equipe, férias coletivas, lotação mínima. Reconhece sobreposições e calcula capacidade disponível</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-medium text-gosign-dark">5</td>
<td class="py-3 pr-4">Gerar recomendação de aprovação</td>
<td class="py-3 pr-4 font-medium">AI Agent + Regra</td>
<td class="py-3">Todas as regras atendidas: recomendação de aprovação ao gestor. Encaminhamento com contexto e recomendação</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-medium text-gosign-dark">6</td>
<td class="py-3 pr-4">Escalar conflito de férias</td>
<td class="py-3 pr-4 font-medium">Humano</td>
<td class="py-3">Dois colaboradores, mesma semana, lotação mínima insuficiente. Critérios sociais (filhos em idade escolar, gestantes) exigem decisão humana</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-medium text-gosign-dark">7</td>
<td class="py-3 pr-4">Calcular pagamento de férias + 1/3</td>
<td class="py-3 pr-4 font-medium">Regra</td>
<td class="py-3">Remuneração + 1/3 constitucional (CF Art. 7o, XVII). Abono pecuniário se solicitado. Pagamento até 2 dias antes do início</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-medium text-gosign-dark">8</td>
<td class="py-3 pr-4">Monitorar limiar de afastamento INSS</td>
<td class="py-3 pr-4 font-medium">Regra</td>
<td class="py-3">Empregador paga 15 dias. A partir do 16o dia: encaminhamento ao INSS auxílio-doença. Trigger automático ao RH</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-medium text-gosign-dark">9</td>
<td class="py-3 pr-4">Atualizar eSocial</td>
<td class="py-3 pr-4 font-medium">Regra</td>
<td class="py-3">Evento S-2230 (afastamento temporário) para o eSocial. Integração automática com sistema de folha e escala</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-medium text-gosign-dark">10</td>
<td class="py-3 pr-4">Gerar registro de auditoria</td>
<td class="py-3 pr-4 font-medium">Regra</td>
<td class="py-3">Decisão, base legal, decisor, timestamp, hash de entrada - append-only, assinado SHA-256</td>
</tr>
</tbody>
</table>
</div>

<p class="text-body text-gosign-text mt-8 max-w-narrow font-semibold">5 a 15 etapas por processo de ausência. O AI Agent pode executar cada uma delas de forma melhor e mais rápida que um analista de RH. Mesmo assim, o ser humano permanece em pontos definidos do processo - não porque ele é melhor, mas porque a CLT, os sindicatos ou a proteção de dados de saúde o exigem. Com 10.000 colaboradores, são 50.000+ microdecisões documentadas por mês.</p>

<div class="mt-10">
<div class="grid grid-cols-1 sm:grid-cols-2 gap-6">
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">IA classifica. Regra calcula.</h3>
<p class="text-small text-gosign-text-light mt-2">O AI Agent reconhece: qual tipo de ausência? Qual base legal? Existe conflito de equipe? O colaborador atingiu o limiar de afastamento para INSS? Essa classificação ele faz de forma mais confiável que qualquer analista. O cálculo de direitos, prazos e conversões é então processado por Decision Tables versionadas - de forma determinística, reproduzível e auditável.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">Dados de saúde arquitetonicamente separados</h3>
<p class="text-small text-gosign-text-light mt-2">Dados de saúde são categoria especial sob a LGPD Art. 11 (PT: RGPD Art. 9). Sem mistura de dados de férias e diagnósticos. O módulo de afastamento por saúde tem banco de dados próprio, círculo de acesso próprio, prazos de exclusão próprios. O módulo de ausências vê apenas: afastamento sim/não. Nenhum diagnóstico.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">AI Agent, regra ou humano</h3>
<p class="text-small text-gosign-text-light mt-2">O AI Agent classifica situações e reconhece padrões - de forma mais confiável que qualquer analista. O conjunto de regras calcula direitos e prazos. O ser humano permanece onde a CLT, os sindicatos ou a proteção de dados de saúde exigem uma decisão humana.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">Aviso de perda de férias automatizado</h3>
<p class="text-small text-gosign-text-light mt-2">A CLT Art. 134 e 137 exigem que as férias sejam concedidas dentro do período concessivo. Sem concessão dentro do prazo, o empregador paga em dobro. O Decision Layer gera os avisos automaticamente, documenta a comunicação e escala quando o prazo se aproxima.</p>
</div>
</div>
</div>
</div>
</section>

<!-- Governança e Auditoria -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governança</p>
<h2 class="text-h1 font-bold text-gosign-dark">Não documentado posteriormente. Gerado no processo.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Quando o sindicato pergunta "por que as férias foram recusadas?", dizer "lotação mínima" não basta. Qual regra de lotação? Qual período? Quem já estava aprovado? O Leave Decision Layer gera para cada microdecisão um ato de decisão que responde exatamente a essas perguntas: entrada, regra de negócio aplicada com versão, resultado, carimbo de tempo e caminho de contestação. O mesmo ato torna a revisão da decisão individual possível de cumprir e comprovar nos termos da LGPD art. 20 (e do art. 86 do EU AI Act em negócios na UE) - para titular, sindicato e auditor.</p>

<!-- Audit Trail Card -->
<div class="mt-10 bg-gosign-dark rounded-card p-6 sm:p-8">
<div class="flex items-start gap-4 mb-6">
<svg class="w-8 h-8 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12h6m-6 4h6m2 5H7a2 2 0 01-2-2V5a2 2 0 012-2h5.586a1 1 0 01.707.293l5.414 5.414a1 1 0 01.293.707V19a2 2 0 01-2 2z" />
</svg>
<div>
<h3 class="text-h3 font-bold text-white">Cada microdecisão gera um registro de auditoria</h3>
<p class="text-small text-gosign-text-on-dark/70 mt-1">Append-only. Nada é sobrescrito, nada é excluído. Em correções, são gerados registros de estorno e ajuste. Assinado com SHA-256, exportável a qualquer momento.</p>
</div>
</div>
<div class="grid grid-cols-2 sm:grid-cols-3 gap-3 sm:gap-4">
<div class="flex items-center gap-2.5">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span class="text-small text-gosign-text-on-dark/80">ID da regra + versão</span>
</div>
<div class="flex items-center gap-2.5">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span class="text-small text-gosign-text-on-dark/80">Base legal (CLT, CCT, ACT)</span>
</div>
<div class="flex items-center gap-2.5">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span class="text-small text-gosign-text-on-dark/80">Dados de entrada (pedido, período, equipe)</span>
</div>
<div class="flex items-center gap-2.5">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span class="text-small text-gosign-text-on-dark/80">Resultado (aprovação, recusa, escalação)</span>
</div>
<div class="flex items-center gap-2.5">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span class="text-small text-gosign-text-on-dark/80">Decisor (regra / Agent / humano)</span>
</div>
<div class="flex items-center gap-2.5">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span class="text-small text-gosign-text-on-dark/80">Hash de entrada (reproduzível)</span>
</div>
</div>
</div>

<!-- Três Pilares de Governança -->
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8">
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-3">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M15 12a3 3 0 11-6 0 3 3 0 016 0z" />
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M2.458 12C3.732 7.943 7.523 5 12 5c4.478 0 8.268 2.943 9.542 7-1.274 4.057-5.064 7-9.542 7-4.477 0-8.268-2.943-9.542-7z" />
</svg>
<div>
<h3 class="text-body font-semibold text-gosign-dark">Transparente para representação dos trabalhadores</h3>
<p class="text-small text-gosign-text-light mt-2">A CLT e as convenções coletivas exigem transparência. Conjunto de regras consultável, razões de recusa documentadas, detecção de anomalias controlável por Feature Flag, relatórios pseudonimizados.</p>
<a href="/br/governance/co-determination/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Participação &rarr;</a>
</div>
</div>
</div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-3">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12l2 2 4-4m5.618-4.016A11.955 11.955 0 0112 2.944a11.955 11.955 0 01-8.618 3.04A12.02 12.02 0 003 9c0 5.591 3.824 10.29 9 11.622 5.176-1.332 9-6.03 9-11.622 0-1.042-.133-2.052-.382-3.016z" />
</svg>
<div>
<h3 class="text-body font-semibold text-gosign-dark">LGPD Art. 11: dados de saúde separados</h3>
<p class="text-small text-gosign-text-light mt-2">Módulo de afastamento por saúde arquitetonicamente separado. Banco de dados próprio, círculo de acesso próprio. Nenhum diagnóstico no módulo de ausências. Prazos de exclusão configuráveis. (PT: Compatível com RGPD Art. 9.)</p>
<a href="/br/governance/data-residency/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Residência de dados &rarr;</a>
</div>
</div>
</div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-3">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 5H7a2 2 0 00-2 2v12a2 2 0 002 2h10a2 2 0 002-2V7a2 2 0 00-2-2h-2M9 5a2 2 0 002 2h2a2 2 0 002-2M9 5a2 2 0 012-2h2a2 2 0 012 2m-6 9l2 2 4-4" />
</svg>
<div>
<h3 class="text-body font-semibold text-gosign-dark">Aviso de perda de férias automatizado</h3>
<p class="text-small text-gosign-text-light mt-2">CLT Art. 134 e 137: férias não concedidas no período concessivo geram pagamento em dobro. O Decision Layer monitora prazos, gera avisos automaticamente e documenta a comunicação.</p>
</div>
</div>
</div>
</div>
</div>
</section>

<!-- Simulações Setoriais -->
<section id="simulacoes" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulado para volumes Enterprise</p>
<h2 class="text-h1 font-bold text-white">Quatro setores. Calculados.</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Configuramos o Leave & Absence Decision Layer para quatro setores e calculamos com convenções coletivas reais, regras de ausência e estruturas de pessoal realistas. Cada card mostra os parâmetros da simulação e o resultado.</p>

<div class="grid grid-cols-1 md:grid-cols-2 gap-6 mt-10">
<a href="/br/servicos/hr-agent/leave-absence-decision-layer/chemicals/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors">
<div class="flex items-center justify-between mb-4">
<h3 class="text-h3 font-bold text-white">Química</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
</div>
</div>
<ul class="space-y-1.5 text-small text-gosign-text-on-dark/70">
<li>Convenções regionais Sindicato dos Químicos / ABIQUIM</li>
<li>Adicional de férias por turno contínuo</li>
<li>Afastamento com exposição a agentes químicos (NR-15)</li>
<li>Lotação mínima em produção contínua</li>
</ul>
<div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between">
<span class="text-h3 font-bold text-gosign-accent-on-dark">83% Zero-Touch</span>
<span class="text-small text-gosign-accent-on-dark font-semibold">Química em detalhe &rarr;</span>
</div>
</a>
<a href="/br/servicos/hr-agent/leave-absence-decision-layer/aviation/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors">
<div class="flex items-center justify-between mb-4">
<h3 class="text-h3 font-bold text-white">Aviação</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
</div>
</div>
<ul class="space-y-1.5 text-small text-gosign-text-on-dark/70">
<li>3 sindicatos (cockpit, cabine, solo)</li>
<li>ANAC: descansos regulatórios obrigatórios</li>
<li>Medical Grounding (inaptidão para voo)</li>
<li>Crew-Pairing e planejamento de escala</li>
</ul>
<div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between">
<span class="text-h3 font-bold text-gosign-accent-on-dark">78% Zero-Touch</span>
<span class="text-small text-gosign-accent-on-dark font-semibold">Aviação em detalhe &rarr;</span>
</div>
</a>
<a href="/br/servicos/hr-agent/leave-absence-decision-layer/financial-services/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors">
<div class="flex items-center justify-between mb-4">
<h3 class="text-h3 font-bold text-white">Finanças</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-white/20"></span></div>
</div>
<ul class="space-y-1.5 text-small text-gosign-text-on-dark/70">
<li>Férias obrigatórias em bloco (Bacen/CVM)</li>
<li>5 regimes de remuneração paralelos</li>
<li>Feriados bancários além dos nacionais</li>
<li>Aposentadoria parcial progressiva</li>
</ul>
<div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between">
<span class="text-h3 font-bold text-gosign-accent-on-dark">85% Zero-Touch</span>
<span class="text-small text-gosign-accent-on-dark font-semibold">Finanças em detalhe &rarr;</span>
</div>
</a>
<a href="/br/servicos/hr-agent/leave-absence-decision-layer/retail/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors">
<div class="flex items-center justify-between mb-4">
<h3 class="text-h3 font-bold text-white">Varejo</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-white/20"></span></div>
</div>
<ul class="space-y-1.5 text-small text-gosign-text-on-dark/70">
<li>6 dias por semana com trabalho aos sábados</li>
<li>64% jornada parcial, contratos temporários</li>
<li>Bloqueios de férias em alta temporada</li>
<li>Convenções por estado/região</li>
</ul>
<div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between">
<span class="text-h3 font-bold text-gosign-accent-on-dark">87% Zero-Touch</span>
<span class="text-small text-gosign-accent-on-dark font-semibold">Varejo em detalhe &rarr;</span>
</div>
</a>
</div>
</div>
</section>

<!-- Implementação -->
<section id="implementacao" class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Implementação</p>
<h2 class="text-h1 font-bold text-gosign-dark">Do piloto ao sistema em operação.</h2>

<div class="grid grid-cols-1 lg:grid-cols-2 gap-10 mt-10">
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Arquitetura técnica</h3>
<p class="text-body text-gosign-text">O Leave & Absence Decision Layer opera integralmente na sua infraestrutura: seu data center, sua rede, sua governança. Sem dependência de SaaS, sem vazamento de dados, sem telemetria externa. Dados de saúde e dossiês de afastamento não saem da sua rede. Containerizado, multitenant, pronto para deploy na sua Private Cloud.</p>
<div class="flex flex-wrap gap-4 mt-3">
<a href="/br/servicos/infraestrutura/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infraestrutura em detalhe &rarr;</a>
<a href="/br/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Arquitetura do Decision Layer &rarr;</a>
<a href="/br/revista/ato-de-decisao-decisoes-ia-contestaveis/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">O ato de decisão &rarr;</a>
<a href="/br/servicos/hr-agent/payroll-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Payroll Decision Layer &rarr;</a>
</div>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Implementação</h3>
<p class="text-body text-gosign-text">O Decision Layer não é instalado, mas configurado: suas convenções coletivas, suas regras de ausência, seus tipos de afastamento. Projetos piloto típicos iniciam em até 3 meses com uma unidade e os tipos de ausência mais frequentes. Expansões para outras unidades, convenções e casos especiais ocorrem em paralelo ao piloto.</p>
</div>
</div>
</div>
</section>


<!-- Weitere Agent-Lösungen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Mais soluções de agentes</h2>
<p class="text-body-lg text-gosign-text-light mt-4">HR Agents fazem parte do nosso portfólio de agentes. Para finanças e outras áreas, oferecemos soluções especializadas.</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8 max-w-content">
<a href="/br/hr-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR & People Operations</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Todos os HR Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Compatível com sindicato/CRE.</p>
</a>
<a href="/br/finance-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Finance & Accounting</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Finance AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Processamento de documentos, contabilização, depreciação, correções. Integração SAP/ERP.</p>
</a>
<a href="/br/contato/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Individual</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Co-Build para seu processo</h3>
<p class="text-body text-gosign-text-light mt-2">Compliance, operações, shared services - desenvolvemos agentes em modelo co-build.</p>
</a>
</div>
</div>
</section>

<!-- Este agente no catálogo -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark">Quando começar? Priorização e prontidão de governança</h2>
<p class="text-body text-gosign-text mt-4">O catálogo de agentes HR mostra pontuações, complexidade de governança, classificação EU AI Act e a tabela completa de microdecisões para este agente - posicionado em 3 quadrantes de priorização junto a 47 outros agentes HR.</p>
<a href="/br/catalogo-agentes-hr/leave-of-absence-agent/" class="inline-flex items-center gap-2 mt-4 text-body font-semibold text-gosign-accent hover:underline">Ver sequenciamento e scores &rarr;</a>
</div>
</section>

<!-- Aprofundamento -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Aprofundamento no Agent Briefing (Revista Gosign)</h2>
<p class="text-body text-gosign-text-light mb-6">Nossa série de artigos especializados para gestores que implementam AI Agents na empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/br/revista/comite-empresa-ia-codecisao/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Participação</p>
<p class="text-body font-semibold text-gosign-dark">Sindicato e IA - participação dos trabalhadores como restrição arquitetônica</p>
</a>
<a href="/br/revista/decision-layer-explicado/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Fundamentos</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - o que é e por que todo AI Agent empresarial precisa de um?</p>
</a>
<a href="/br/revista/agent-governance-hr/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Agent Governance para RH - por que regras são mais importantes que modelos</p>
</a>
</div>
</div>
</section>

--- AI Payroll Agent Aviação - folha de pagamento ---
> Payroll Decision Layer para aviação. SNA, SNEA, ANAC RBAC 117, diárias CLT Art. 457. 82% Zero-Touch.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/br/por-que-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Cada decisão rastreável</p>
</div>
</a>
<a href="/br/por-que-gosign/#infraestrutura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Sua infraestrutura</p>
<p class="text-xs text-gosign-text-light">Sem SaaS. Sem vendor lock-in.</p>
</div>
</a>
<a href="/br/por-que-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Sem risco de cloud americana</p>
</div>
</a>
</div>
</div>
</div>

<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Payroll Decision Layer Setores">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/br/servicos/hr-agent/payroll-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Payroll Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/br/servicos/hr-agent/payroll-decision-layer/chemicals/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Química</a>
<a href="/br/servicos/hr-agent/payroll-decision-layer/aviation/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Aviação</a>
<a href="/br/servicos/hr-agent/payroll-decision-layer/financial-services/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Finanças</a>
<a href="/br/servicos/hr-agent/payroll-decision-layer/retail/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Varejo</a>
</div>
</div>
</nav>

<!-- Complexidade -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">14-18</span>
<p class="text-small text-gosign-text-light mt-1">Convenções coletivas paralelas</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">82%</span>
<p class="text-small text-gosign-text-light mt-1">Quota Zero-Touch</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">180+</span>
<p class="text-small text-gosign-text-light mt-1">Diárias por país</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">Máxima complexidade de regras</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">Convenções SNA (aeronautas) e SNEA (aeroviários) 2024. CLT Art. 457 diárias. ANAC RBAC 117. LATAM, Azul, GOL. (PT: TAP Air Portugal, Portugália.) Zero-Touch: modelo de simulação Gosign.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">O que o Agent classifica</p>
<h2 class="text-h1 font-bold text-gosign-dark">SNA e SNEA, um Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">No Brasil, a folha de aviação envolve o SNA para aeronautas (pilotos e comissários) e o SNEA para aeroviários (pessoal de solo), além dos limites RBAC 117 da ANAC e diárias internacionais. (PT: Em Portugal, o SNPVAC representa pilotos e tripulantes de cabine, com regulamentação EASA direta.) Você conhece a complexidade. Assim o AI Agent a resolve:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Cockpit (SNA): níveis de senioridade e escalas salariais</h3>
<p class="text-body text-gosign-text mt-2">A convenção coletiva do SNA cobre múltiplos níveis de senioridade, remunerações por tipo de aeronave e contribuições previdenciárias. O AI Agent reconhece nível de senioridade e tipo de aeronave a partir do cadastro e atribui a classe de remuneração correta - do Copiloto ao Comandante Sênior. Aplica-se às tripulações de LATAM, Azul e GOL.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Cabine (SNA): adicionais de turno e de voo</h3>
<p class="text-body text-gosign-text mt-2">Remuneração base mais adicionais de turno, adicionais de chefia de cabine, diárias por rota. O AI Agent reconhece voos de curta vs. longa distância e calcula as diárias e escalas corretas por rota. Em mudança de rota: recálculo automático.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Solo (SNEA): múltiplas faixas e funções</h3>
<p class="text-body text-gosign-text mt-2">O SNEA representa os aeroviários com múltiplas faixas salariais, adicionais noturnos, de feriado e de turno. O AI Agent classifica faixa salarial e nível de experiência a partir do cadastro e perfil da função - inclusive em mudanças entre check-in, pátio e bagagem.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">ANAC RBAC 117: limites de tempo de voo como fronteira da folha</h3>
<p class="text-body text-gosign-text mt-2">A ANAC regulamenta pelo RBAC 117 os limites de tempo de voo com variações conforme horário de apresentação e número de pousos. O AI Agent verifica cada ciclo de folha contra esses limites e escala na aproximação. Em excesso, há risco de suspensão de licença e multa - isso deixa de ser questão de folha e passa a ser questão jurídica. (PT: Em Portugal, a ANAC Portugal opera sob EASA direta, sem regulamentação nacional adicional.)</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Diárias: 180+ tabelas por país conforme CLT</h3>
<p class="text-body text-gosign-text mt-2">Rota Londres-Dubai-Cingapura: três tabelas de país em um Duty Period. O AI Agent calcula o reembolso de despesas por trecho da rota conforme CLT Art. 457 e tabelas vigentes, incluindo deduções de refeições e tempos mínimos de permanência. Em alterações de rota por IROP: recálculo automático. A mesma lógica controla também o <a href="/br/servicos/travel-decision-layer/aviacao/" class="text-gosign-accent-text font-semibold hover:text-gosign-accent-hover transition-colors">processamento de despesas de viagem no Travel Decision Layer</a>.</p>
</div>
</div>
</div>
</section>

<!-- Decision Flow -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Uma folha na aviação. 50 a 120 microdecisões.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Um Comandante em rota de longa distância. O Payroll Decision Layer decompõe sua folha em etapas de decisão individuais:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Etapa</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decisão</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decisor</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Fundamentação</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Classificar grupo de pessoal</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent reconhece: cockpit, cabine, solo ou manutenção a partir do cadastro e código da função</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Atribuir convenção coletiva</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent atribui: SNA (aeronautas) ou SNEA (aeroviários). Adicionalmente: qual companhia aérea (subsidiárias têm convenções próprias)</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Calcular remuneração base</td><td class="py-3 px-4">Convenção coletiva</td><td class="py-3 px-4">Lookup em tabela versionada: nível de senioridade, tipo de aeronave, nível de experiência</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Calcular adicionais de turno</td><td class="py-3 px-4">Convenção coletiva</td><td class="py-3 px-4">Cabine: adicionais de turno e de voo. Solo: adicionais conforme escala. Cockpit: integrado na remuneração base</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Verificar conformidade RBAC 117</td><td class="py-3 px-4">Regra</td><td class="py-3 px-4">Verificação ANAC RBAC 117: limites de horas de voo, FDP variável, limites acumulados. Na aproximação: escalação</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Classificar diária</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent classifica rota: quais países, qual duração de estadia, quais tabelas CLT se aplicam</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Calcular diária</td><td class="py-3 px-4">Regra</td><td class="py-3 px-4">Tabelas por país conforme CLT Art. 457, dedução de refeições, permanência mínima. Em alterações por IROP: recálculo automático</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">Calcular contribuições previdenciárias</td><td class="py-3 px-4">Regra</td><td class="py-3 px-4">INSS, FGTS 8%, previdência complementar. Determinístico conforme convenção</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Verificação de desvios</td><td class="py-3 px-4">IA detecta, humano decide</td><td class="py-3 px-4">IA detecta desvios de forma mais confiável. Mas a avaliação permanece com o ser humano - a CLT exige transparência nos princípios de remuneração</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Gerar lançamentos contábeis</td><td class="py-3 px-4">Regra</td><td class="py-3 px-4">Contabilização FI/CO, multi-empresa (subsidiárias do grupo), centro de custo - determinístico</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Simulação -->
<section id="simulacao" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulação</p>
<h2 class="text-h1 font-bold text-white">Calculado para volumes de aviação</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Configuramos o Payroll Decision Layer com parâmetros realistas de aviação. Convenções coletivas SNA e SNEA, ANAC RBAC 117, diárias internacionais conforme CLT, níveis de senioridade de cockpit.</p>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Parâmetros da simulação</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Tripulação</td><td class="py-3 px-4">10.000 a 50.000+ (cockpit, cabine, solo, manutenção)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Convenções paralelas</td><td class="py-3 px-4">2 a 5 (SNA aeronautas, SNEA aeroviários, eventualmente subsidiárias)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Jurisdições</td><td class="py-3 px-4">Multi-jurisdição (base BR, estações internacionais)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Taxa de IROP</td><td class="py-3 px-4">10-20% (irregularidades com impacto na folha)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Diárias por país</td><td class="py-3 px-4">180+ tabelas conforme CLT Art. 457</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Níveis de senioridade cockpit</td><td class="py-3 px-4">Múltiplos níveis (Copiloto a Comandante Sênior), contribuições previdenciárias</td></tr>
</tbody>
</table>
</div>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Antes / Depois</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th scope="col" class="text-left py-3 px-4 font-semibold text-white">Dimensão</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manual</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Taxa de erro</td><td class="py-3 px-4">3-12% (APA, acréscimo aviação)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 0,3%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Quota Zero-Touch</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">82%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Cálculo de diárias</td><td class="py-3 px-4">Manual por rota, propenso a erros</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automático, 180+ países</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Conformidade RBAC 117</td><td class="py-3 px-4">Verificação separada, posterior</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Integrada, limites em tempo real</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Mudança de convenção (2 sindicatos)</td><td class="py-3 px-4">Semanas por sindicato</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 24h (todos em paralelo)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Prontidão para auditoria</td><td class="py-3 px-4">Reconstruído manualmente</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Gerado automaticamente</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">APA: American Payroll Association. Convenções SNA e SNEA 2024. ANAC RBAC 117. CLT Art. 457. LATAM, Azul, GOL. Resultados: modelo de simulação Gosign.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">Na simulação, o Decision Layer atinge uma quota Zero-Touch de 82%. Os 18% restantes são exceções reais: alterações de rota por IROP, mudança de sindicato em transferências entre empresas do grupo, casos limítrofes de limites de voo com escalação, promoções de cockpit entre fronteiras tarifárias. Para os 82%, existe um dossiê de decisão completo e à prova de auditoria.</p>
</div>
</section>

<!-- Referência de Arquitetura -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Arquitetura e implementação</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">O Payroll Decision Layer opera integralmente na sua infraestrutura. Para a aviação, isso significa: integração com sistemas de gestão de tripulação, processamento de planos de rota e dados RBAC 117, convenções SNA e SNEA em paralelo e Audit Trail completo até o SAP HCM. Projetos piloto típicos iniciam em até 3 meses com um grupo de pessoal e uma convenção coletiva.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/br/servicos/hr-agent/payroll-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Visão geral Payroll Decision Layer &rarr;</a>
<a href="/br/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Arquitetura do Decision Layer &rarr;</a>
<a href="/br/servicos/infraestrutura/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infraestrutura em detalhe &rarr;</a>
<a href="/br/governance/co-determination/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Codecisão &rarr;</a>
<a href="/br/governance/cert-ready/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready by Design &rarr;</a>
<a href="/br/servicos/travel-decision-layer/aviacao/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Travel Decision Layer Aviação &rarr;</a>
</div>
</div>
</section>


<!-- Weitere Agent-Lösungen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Mais soluções de agentes</h2>
<p class="text-body-lg text-gosign-text-light mt-4">HR Agents fazem parte do nosso portfólio de agentes. Para finanças e outras áreas, oferecemos soluções especializadas.</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8 max-w-content">
<a href="/br/hr-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR & People Operations</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Todos os HR Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Compatível com sindicato/CRE.</p>
</a>
<a href="/br/finance-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Finance & Accounting</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Finance AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Processamento de documentos, contabilização, depreciação, correções. Integração SAP/ERP.</p>
</a>
<a href="/br/contato/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Individual</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Co-Build para seu processo</h3>
<p class="text-body text-gosign-text-light mt-2">Compliance, operações, shared services - desenvolvemos agentes em modelo co-build.</p>
</a>
</div>
</div>
</section>

<!-- Aprofundamento -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Aprofundamento no Agent Briefing (Revista Gosign)</h2>
<p class="text-body text-gosign-text-light mb-6">Nossa série de artigos especializados para gestores que implementam AI Agents na empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/br/revista/decision-layer-payroll/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Finanças</p>
<p class="text-body font-semibold text-gosign-dark">Eliminar erros de folha de pagamento estruturalmente - Decision Layer para finanças</p>
</a>
<a href="/br/revista/comite-empresa-ia-codecisao/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Codecisão</p>
<p class="text-body font-semibold text-gosign-dark">Representação dos trabalhadores e IA - codecisão como restrição arquitetônica</p>
</a>
<a href="/br/revista/decision-layer-explicado/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Fundamentos</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - o que é e por que todo AI Agent empresarial precisa de um?</p>
</a>
</div>
</div>
</section>

<!-- Outros Setores -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Payroll Decision Layer em outros setores</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Cada setor tem suas próprias convenções coletivas, suas próprias regras de adicionais e seus próprios fatores de complexidade. O Decision Layer é o mesmo. A configuração é específica por setor.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/br/servicos/hr-agent/payroll-decision-layer/chemicals/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Química</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">Sindicato dos Químicos, NR-15/NR-16, 13o salário, FGTS, PLR</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">88% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Em detalhe &rarr;</span>
</div>
</a>
<a href="/br/servicos/hr-agent/payroll-decision-layer/financial-services/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Finanças</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">5 regimes de remuneração, Bonus-Deferral, Malus/Clawback, BCB/CVM</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">85% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Em detalhe &rarr;</span>
</div>
</a>
<a href="/br/servicos/hr-agent/payroll-decision-layer/retail/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Varejo</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">26 estados, contrato intermitente CLT, 64% tempo parcial, picos sazonais</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">92% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Em detalhe &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- AI Payroll Agent Química - folha de pagamento ---
> Payroll Decision Layer para a indústria química. Convenções regionais, adicionais NR-15/NR-16, 13o salário + FGTS + PLR. 88% Zero-Touch.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/br/por-que-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Cada decisão rastreável</p>
</div>
</a>
<a href="/br/por-que-gosign/#infraestrutura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Sua infraestrutura</p>
<p class="text-xs text-gosign-text-light">Sem SaaS. Sem vendor lock-in.</p>
</div>
</a>
<a href="/br/por-que-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Sem risco de cloud americana</p>
</div>
</a>
</div>
</div>
</div>

<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Payroll Decision Layer Setores">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/br/servicos/hr-agent/payroll-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Payroll Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/br/servicos/hr-agent/payroll-decision-layer/chemicals/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Química</a>
<a href="/br/servicos/hr-agent/payroll-decision-layer/aviation/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Aviação</a>
<a href="/br/servicos/hr-agent/payroll-decision-layer/financial-services/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Finanças</a>
<a href="/br/servicos/hr-agent/payroll-decision-layer/retail/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Varejo</a>
</div>
</div>
</nav>

<!-- Complexidade -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">169</span>
<p class="text-small text-gosign-text-light mt-1">Bases de remuneração</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">88%</span>
<p class="text-small text-gosign-text-light mt-1">Quota Zero-Touch</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">13o</span>
<p class="text-small text-gosign-text-light mt-1">Salário + FGTS 8% + PLR</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">Máxima complexidade de regras</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">Convenções regionais Sindicato dos Químicos / ABIQUIM. Braskem, Oxiteno. (PT: Bondalti, CUF.) Zero-Touch: modelo de simulação Gosign.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">O que o Agent classifica</p>
<h2 class="text-h1 font-bold text-gosign-dark">Cinco dimensões, um Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">No Brasil, as convenções regionais negociadas pelo Sindicato dos Químicos e a ABIQUIM definem faixas salariais, adicionais de turno com regras de acumulação e 13o salário + FGTS + PLR. (PT: Em Portugal, os sindicatos setoriais negociam ACTs com o subsídio de Natal em vez do 13o, sem FGTS.) Você conhece a complexidade. Assim o AI Agent a resolve:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">169 bases de remuneração</h3>
<p class="text-body text-gosign-text mt-2">As convenções regionais criam centenas de combinações de faixas salariais na indústria química brasileira. O AI Agent reconhece a combinação correta a partir do cadastro de pessoal e dados de localização - inclusive em transferências entre unidades. Sem consulta manual de tabelas, sem confusão de enquadramento.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Adicionais de turno com lógica de acumulação</h3>
<p class="text-body text-gosign-text mt-2">Turno parcial 6%, turno contínuo 10%, noturno 15-20%, domingo 60%, feriado 150%. O AI Agent aplica a regra de acumulação: o maior adicional prevalece, o adicional noturno é sempre aditivo. Em modelos de turno rotativo, o conjunto de regras calcula automaticamente a combinação correta por escala.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">13o salário + FGTS 8% + PLR</h3>
<p class="text-body text-gosign-text mt-2">O 13o salário em duas parcelas obrigatórias, o FGTS de 8% mensal e a PLR (Participação nos Lucros e Resultados) criam configurações complexas. O AI Agent gerencia milhares de configurações individuais com o tratamento fiscal e previdenciário correto para cada uma. Em alteração contratual: ajuste automático a partir do mês seguinte.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Adicionais NR-15 (insalubridade) / NR-16 (periculosidade)</h3>
<p class="text-body text-gosign-text mt-2">A NR-15 determina adicionais de insalubridade (10-40%) e a NR-16 o adicional de periculosidade (30%) na indústria química. O AI Agent classifica a avaliação de riscos (PPRA/PGR) por posto de trabalho e atribui o adicional correto. Em mudança de posto: recálculo automático. (PT: Em Portugal, a legislação SST europeia substitui as NRs, com enquadramento via ACT e Código do Trabalho.)</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Pagamentos especiais por calendário</h3>
<p class="text-body text-gosign-text mt-2">13o salário (1a parcela em novembro, 2a em dezembro), férias com 1/3 constitucional, FGTS mensal, PLR conforme convenção. O AI Agent conhece o vencimento, tratamento fiscal e cálculo previdenciário de cada pagamento especial. Em admissão ou desligamento durante o ano: cálculo proporcional automático.</p>
</div>
</div>
</div>
</section>

<!-- Decision Flow -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Uma folha na química. 40 a 80 microdecisões.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Um trabalhador de turno na indústria química. O Payroll Decision Layer decompõe sua folha em etapas de decisão individuais:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Etapa</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decisão</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decisor</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Fundamentação</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Classificar convenção aplicável e faixa salarial</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent reconhece localização da unidade, convenção regional e verifica enquadramento contra cadastro de pessoal</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Calcular remuneração base</td><td class="py-3 px-4">Convenção coletiva</td><td class="py-3 px-4">Lookup em tabela versionada: convenção + faixa + nível</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Classificar modelo de turno</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent reconhece: turno parcial (6%), turno contínuo (10%) ou noturno fixo a partir da escala</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Calcular e acumular adicionais</td><td class="py-3 px-4">Convenção coletiva</td><td class="py-3 px-4">Maior adicional prevalece, noturno sempre aditivo. Domingo 60%, feriado 150%</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Calcular parcelas isentas</td><td class="py-3 px-4">Regra</td><td class="py-3 px-4">Adicionais noturnos, insalubridade (NR-15) e periculosidade (NR-16) conforme legislação aplicável</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Classificar adicional NR-15/NR-16</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent classifica posto de trabalho com base no PPRA/PGR: agentes químicos, calor, frio, ruído</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Calcular 13o salário, FGTS e PLR</td><td class="py-3 px-4">Regra</td><td class="py-3 px-4">13o em duas parcelas + FGTS 8% mensal + PLR conforme convenção, tratamento fiscal diferenciado</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">Calcular contribuições previdenciárias</td><td class="py-3 px-4">Regra</td><td class="py-3 px-4">INSS com verificação de teto, FGTS 8%, contribuição sindical</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Verificação de desvios contra mês anterior</td><td class="py-3 px-4">IA detecta, humano decide</td><td class="py-3 px-4">IA detecta desvios de forma mais confiável. Mas a reação (promoção, erro, transferência?) permanece com o ser humano - a CLT e os sindicatos exigem isso</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Gerar lançamentos contábeis</td><td class="py-3 px-4">Regra</td><td class="py-3 px-4">Contabilização FI/CO, centro de custo, período contábil - determinístico</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Simulação -->
<section id="simulacao" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulação</p>
<h2 class="text-h1 font-bold text-white">Calculado para volumes da indústria química</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Configuramos o Payroll Decision Layer com parâmetros realistas da indústria química brasileira. Convenções regionais Sindicato dos Químicos / ABIQUIM, modelos de turno, adicionais NR-15/NR-16, 13o salário + FGTS + PLR.</p>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Parâmetros da simulação</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Colaboradores</td><td class="py-3 px-4">5.000 a 50.000+ (produção, laboratório, administração)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Convenção coletiva</td><td class="py-3 px-4">Sindicato dos Químicos / ABIQUIM, convenções regionais, faixas salariais</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Bases de remuneração</td><td class="py-3 px-4">169 (convenções x faixas) + progressão automática</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Modelos de turno</td><td class="py-3 px-4">Turno parcial, turno contínuo, noturno fixo</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Pagamentos especiais</td><td class="py-3 px-4">13o salário, férias + 1/3, FGTS 8%, PLR</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Adicionais NR-15/NR-16</td><td class="py-3 px-4">Insalubridade 10-40%, periculosidade 30%</td></tr>
</tbody>
</table>
</div>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Antes / Depois</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th scope="col" class="text-left py-3 px-4 font-semibold text-white">Dimensão</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manual</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Taxa de erro</td><td class="py-3 px-4">1-8% (APA)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 0,1%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Quota Zero-Touch</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">88%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Mudança de convenção</td><td class="py-3 px-4">Semanas (múltiplas unidades manualmente)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 24h (todas as unidades)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Cálculo de adicionais</td><td class="py-3 px-4">Manual, propenso a erros</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Baseado em regras, consistente</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Prontidão para auditoria</td><td class="py-3 px-4">Reconstruído manualmente</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Gerado automaticamente</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Gestão 13o, FGTS e PLR</td><td class="py-3 px-4">Planilhas Excel por unidade</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Centralizado, versionado</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">APA: American Payroll Association. Convenções regionais Sindicato dos Químicos / ABIQUIM. Braskem, Oxiteno. Resultados: modelo de simulação Gosign.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">Na simulação, o Decision Layer atinge uma quota Zero-Touch de 88%. Os 12% restantes são exceções reais: reavaliações NR-15/NR-16, alterações de PLR, transferências entre unidades. Para os 88%, existe um dossiê de decisão completo e à prova de auditoria.</p>
</div>
</section>

<!-- Referência de Arquitetura -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Arquitetura e implementação</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">O Payroll Decision Layer opera integralmente na sua infraestrutura. Para a indústria química, isso significa: integração com sistemas de escala de turnos, processamento de avaliações NR-15/NR-16, conjuntos de regras específicos por convenção regional e Audit Trail completo até o SAP HCM. Projetos piloto típicos iniciam em até 3 meses com uma convenção e um grupo de pessoal.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/br/servicos/hr-agent/payroll-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Visão geral Payroll Decision Layer &rarr;</a>
<a href="/br/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Arquitetura do Decision Layer &rarr;</a>
<a href="/br/servicos/infraestrutura/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infraestrutura em detalhe &rarr;</a>
<a href="/br/governance/co-determination/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Codecisão &rarr;</a>
<a href="/br/governance/cert-ready/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready by Design &rarr;</a>
<a href="/br/servicos/travel-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Travel Decision Layer &rarr;</a>
</div>
</div>
</section>


<!-- Weitere Agent-Lösungen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Mais soluções de agentes</h2>
<p class="text-body-lg text-gosign-text-light mt-4">HR Agents fazem parte do nosso portfólio de agentes. Para finanças e outras áreas, oferecemos soluções especializadas.</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8 max-w-content">
<a href="/br/hr-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR & People Operations</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Todos os HR Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Compatível com sindicato/CRE.</p>
</a>
<a href="/br/finance-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Finance & Accounting</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Finance AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Processamento de documentos, contabilização, depreciação, correções. Integração SAP/ERP.</p>
</a>
<a href="/br/contato/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Individual</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Co-Build para seu processo</h3>
<p class="text-body text-gosign-text-light mt-2">Compliance, operações, shared services - desenvolvemos agentes em modelo co-build.</p>
</a>
</div>
</div>
</section>

<!-- Aprofundamento -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Aprofundamento no Agent Briefing (Revista Gosign)</h2>
<p class="text-body text-gosign-text-light mb-6">Nossa série de artigos especializados para gestores que implementam AI Agents na empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/br/revista/decision-layer-payroll/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Finanças</p>
<p class="text-body font-semibold text-gosign-dark">Eliminar erros de folha de pagamento estruturalmente - Decision Layer para finanças</p>
</a>
<a href="/br/revista/comite-empresa-ia-codecisao/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Codecisão</p>
<p class="text-body font-semibold text-gosign-dark">Representação dos trabalhadores e IA - codecisão como restrição arquitetônica</p>
</a>
<a href="/br/revista/decision-layer-explicado/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Fundamentos</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - o que é e por que todo AI Agent empresarial precisa de um?</p>
</a>
</div>
</div>
</section>

<!-- Outros Setores -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Payroll Decision Layer em outros setores</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Cada setor tem suas próprias convenções coletivas, suas próprias regras de adicionais e seus próprios fatores de complexidade. O Decision Layer é o mesmo. A configuração é específica por setor.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/br/servicos/hr-agent/payroll-decision-layer/aviation/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Aviação</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">3 sindicatos, 14-18 convenções, ANAC/EASA FTL, senioridade de cockpit até nível 23</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">82% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Em detalhe &rarr;</span>
</div>
</a>
<a href="/br/servicos/hr-agent/payroll-decision-layer/financial-services/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Finanças</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">5 regimes de remuneração, Bonus-Deferral, Malus/Clawback, obrigações regulatórias</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">85% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Em detalhe &rarr;</span>
</div>
</a>
<a href="/br/servicos/hr-agent/payroll-decision-layer/retail/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Varejo</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">Convenções regionais, 64% tempo parcial, picos sazonais</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">92% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Em detalhe &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- AI Payroll Agent Finanças - remuneração ---
> Payroll Decision Layer para bancos e serviços financeiros. 5 regimes de remuneração, Bonus-Deferral, Malus/Clawback. 85% Zero-Touch.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/br/por-que-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Cada decisão rastreável</p>
</div>
</a>
<a href="/br/por-que-gosign/#infraestrutura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Sua infraestrutura</p>
<p class="text-xs text-gosign-text-light">Sem SaaS. Sem vendor lock-in.</p>
</div>
</a>
<a href="/br/por-que-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Sem risco de cloud americana</p>
</div>
</a>
</div>
</div>
</div>
<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Payroll Decision Layer Setores">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/br/servicos/hr-agent/payroll-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Payroll Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/br/servicos/hr-agent/payroll-decision-layer/chemicals/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Química</a>
<a href="/br/servicos/hr-agent/payroll-decision-layer/aviation/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Aviação</a>
<a href="/br/servicos/hr-agent/payroll-decision-layer/financial-services/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Finanças</a>
<a href="/br/servicos/hr-agent/payroll-decision-layer/retail/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Varejo</a>
</div>
</div>
</nav>

<!-- Complexidade -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">5</span>
<p class="text-small text-gosign-text-light mt-1">Regimes de remuneração paralelos</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">85%</span>
<p class="text-small text-gosign-text-light mt-1">Quota Zero-Touch</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">4-5 a.</span>
<p class="text-small text-gosign-text-light mt-1">Período de Bonus-Deferral</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
<span class="w-4 h-2 rounded-sm bg-gosign-border"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">Alta complexidade de regras</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">Resolução CMN, normas prudenciais do BCB (Banco Central do Brasil), CVM. Instituições de referência: Itaú, Bradesco. (PT: BCP, CGD, Novo Banco.) Zero-Touch: modelo de simulação Gosign.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">O que o Agent classifica</p>
<h2 class="text-h1 font-bold text-gosign-dark">Cinco regimes, um Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Cinco regimes de remuneração, tetos de bônus, deferral ao longo de anos, malus/clawback retroativo, obrigação de reporte ao BCB e à CVM. (PT: Em Portugal, o Banco de Portugal e a CMVM sob supervisão BCE aplicam as diretivas CRD V/EBA diretamente.) Você conhece a complexidade. Assim o AI Agent a resolve:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">5 regimes de remuneração paralelos</h3>
<p class="text-body text-gosign-text mt-2">Convenção coletiva, fora de convenção, Risk Taker, Trading, Sales/Advisory - cada regime com sua própria lógica de cálculo. O AI Agent reconhece a classificação correta a partir de dados contratuais, função e remuneração total. Em mudança de regime ao longo da carreira: alteração automática de todos os parâmetros de cálculo.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Bonus-Deferral ao longo de 4-5 anos</h3>
<p class="text-body text-gosign-text mt-2">40-60% da remuneração variável distribuída, dividida em componentes de ações e dinheiro, até 20 tranches paralelas. O AI Agent gerencia cada tranche com seu próprio vesting date e verifica o teto de bônus (100% do fixo, 200% com aprovação em assembleia) automaticamente contra a Resolução CMN e as normas prudenciais do BCB.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Malus/Clawback retroativo</h3>
<p class="text-body text-gosign-text mt-2">Recuperação ao longo de 5-7 anos em violações de compliance ou eventos de risco. O AI Agent reconhece eventos relevantes a partir de notificações internas e prepara o caso. A decisão é sempre de um ser humano - o BCB (Banco Central do Brasil) e a CVM preveem responsabilidade pessoal dos responsáveis pela remuneração.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Obrigações prudenciais para traders</h3>
<p class="text-body text-gosign-text mt-2">10 dias úteis consecutivos de férias obrigatórias por ano, sem fracionamento. O AI Agent verifica automaticamente se o bloco de férias foi cumprido e escala a tempo para RH. Sem verificação manual de calendário, sem prazos esquecidos.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Obrigações de reporte ao BCB e à CVM</h3>
<p class="text-body text-gosign-text mt-2">Relatório anual de remuneração com remunerações de Risk Takers, saldos de deferral, eventos de malus/clawback. O conjunto de regras gera os dados de reporte automaticamente a partir dos dados de folha. Adicionalmente, verificação de vínculo entre componentes variáveis e qualidade de atendimento ao cliente. O relatório é submetido ao BCB e à CVM como parte dos relatórios regulatórios. (PT: Em Portugal, os relatórios são submetidos ao Banco de Portugal e à CMVM conforme diretivas BCE.)</p>
</div>
</div>
</div>
</section>

<!-- Decision Flow -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Uma folha financeira. 30 a 60 microdecisões.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Um Risk Taker em um banco universal. O Payroll Decision Layer decompõe sua folha em etapas de decisão individuais:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Etapa</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decisão</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decisor</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Fundamentação</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Classificar regime de remuneração</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent reconhece: convenção (faixas 1-9), fora de convenção, Risk Taker, Trading ou Sales/Advisory a partir dos dados contratuais</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Verificar status de Risk Taker</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Limite em BRL (equivalente a EUR 500.000), identificação contra catálogo funcional do BCB</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Calcular salário fixo</td><td class="py-3 px-4">Convenção/Contrato</td><td class="py-3 px-4">Convenção: lookup de faixa em tabela salarial. Fora de convenção: acordo individual do contrato</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Calcular remuneração variável</td><td class="py-3 px-4">Regra</td><td class="py-3 px-4">Avaliação de desempenho, teto de bônus 100% do fixo (200% com aprovação em assembleia)</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Calcular split de deferral</td><td class="py-3 px-4">Regra</td><td class="py-3 px-4">40-60% ao longo de 4-5 anos, divisão em componentes de ações e dinheiro, datas de vesting</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Realizar verificação de malus</td><td class="py-3 px-4">IA detecta, humano decide</td><td class="py-3 px-4">IA detecta violações de compliance de forma mais confiável. Mas decisões de malus têm consequências de responsabilidade pessoal - CLT e regulador exigem responsabilidade humana</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Verificar bloco de férias obrigatórias</td><td class="py-3 px-4">Regra</td><td class="py-3 px-4">10 dias úteis consecutivos por ano, cobertura, escalação em caso de descumprimento</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">Calcular contribuições previdenciárias</td><td class="py-3 px-4">Regra</td><td class="py-3 px-4">INSS com verificação de teto, previdência complementar, FGTS</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Gerar dados de reporte regulatório</td><td class="py-3 px-4">Regra</td><td class="py-3 px-4">Relatório anual de remuneração: dados de Risk Takers, saldos de deferral, eventos de clawback para BCB e CVM</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Gerar lançamentos contábeis</td><td class="py-3 px-4">Regra</td><td class="py-3 px-4">Contabilização FI/CO, multi-entidade, provisões de deferral - determinístico</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Simulação -->
<section id="simulacao" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulação</p>
<h2 class="text-h1 font-bold text-white">Calculado para volumes do setor financeiro</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Configuramos o Payroll Decision Layer com parâmetros realistas do setor financeiro e calculamos os resultados. Resolução CMN, normas prudenciais do BCB, CVM, cinco regimes de remuneração, períodos de deferral ao longo de anos.</p>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Parâmetros da simulação</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Colaboradores</td><td class="py-3 px-4">2.000 a 30.000+ (Front Office, Middle Office, Back Office)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Regimes de remuneração</td><td class="py-3 px-4">5 paralelos: convenção (faixas 1-9), fora de convenção, Risk Taker, Trading, Sales/Advisory</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Limite de Risk Taker</td><td class="py-3 px-4">Equivalente em BRL a EUR 500.000, identificação regulatória do BCB</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Teto de bônus</td><td class="py-3 px-4">100% do fixo (200% com aprovação em assembleia)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Deferral</td><td class="py-3 px-4">40-60% ao longo de 4-5 anos, split ações/dinheiro</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Malus/Clawback</td><td class="py-3 px-4">5-7 anos de período de recuperação</td></tr>
</tbody>
</table>
</div>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Antes / Depois</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th scope="col" class="text-left py-3 px-4 font-semibold text-white">Dimensão</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manual</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Taxa de erro</td><td class="py-3 px-4">1-8% (APA)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 0,1%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Quota Zero-Touch</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">85%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Gestão de deferral</td><td class="py-3 px-4">Excel, propenso a erros</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatizado, versionado</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Identificação de Risk Taker</td><td class="py-3 px-4">Anual, manual</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Contínua, automática</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Reporte ao regulador</td><td class="py-3 px-4">Semanas (preparação manual)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 24h (gerado automaticamente)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Prontidão para auditoria</td><td class="py-3 px-4">Reconstruído manualmente</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Gerado automaticamente</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">APA: American Payroll Association. Resolução CMN, normas prudenciais do BCB, CVM. Instituições de referência: Itaú, Bradesco. Resultados: modelo de simulação Gosign.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">Na simulação, o Decision Layer atinge uma quota Zero-Touch de 85%. Os 15% restantes são exceções reais: casos limítrofes de Risk Taker, decisões de malus, mudança de regime em alterações de função. Para os 85%, existe um dossiê de decisão completo e à prova de auditoria.</p>
</div>
</section>

<!-- Referência de Arquitetura -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Arquitetura e implementação</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">O Payroll Decision Layer opera integralmente na sua infraestrutura. Para o setor financeiro, isso significa: integração com sistemas bancários centrais, processamento de identificação de Risk Takers, conjuntos de regras regulatórios conforme Resolução CMN e normas prudenciais do BCB, e Audit Trail completo até o SAP HCM. Projetos piloto típicos iniciam em até 3 meses com um regime de remuneração e um grupo de pessoal.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/br/servicos/hr-agent/payroll-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Visão geral Payroll Decision Layer &rarr;</a>
<a href="/br/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Arquitetura do Decision Layer &rarr;</a>
<a href="/br/servicos/infraestrutura/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infraestrutura em detalhe &rarr;</a>
<a href="/br/governance/co-determination/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Codecisão &rarr;</a>
<a href="/br/governance/cert-ready/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready by Design &rarr;</a>
<a href="/br/servicos/travel-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Travel Decision Layer &rarr;</a>
</div>
</div>
</section>


<!-- Weitere Agent-Lösungen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Mais soluções de agentes</h2>
<p class="text-body-lg text-gosign-text-light mt-4">HR Agents fazem parte do nosso portfólio de agentes. Para finanças e outras áreas, oferecemos soluções especializadas.</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8 max-w-content">
<a href="/br/hr-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR & People Operations</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Todos os HR Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Compatível com sindicato/CRE.</p>
</a>
<a href="/br/finance-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Finance & Accounting</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Finance AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Processamento de documentos, contabilização, depreciação, correções. Integração SAP/ERP.</p>
</a>
<a href="/br/contato/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Individual</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Co-Build para seu processo</h3>
<p class="text-body text-gosign-text-light mt-2">Compliance, operações, shared services - desenvolvemos agentes em modelo co-build.</p>
</a>
</div>
</div>
</section>

<!-- Aprofundamento -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Aprofundamento no Agent Briefing (Revista Gosign)</h2>
<p class="text-body text-gosign-text-light mb-6">Nossa série de artigos especializados para gestores que implementam AI Agents na empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/br/revista/decision-layer-payroll/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Finanças</p>
<p class="text-body font-semibold text-gosign-dark">Eliminar erros de folha de pagamento estruturalmente - Decision Layer para finanças</p>
</a>
<a href="/br/revista/comite-empresa-ia-codecisao/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Codecisão</p>
<p class="text-body font-semibold text-gosign-dark">Representação dos trabalhadores e IA - codecisão como restrição arquitetônica</p>
</a>
<a href="/br/revista/decision-layer-explicado/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Fundamentos</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - o que é e por que todo AI Agent empresarial precisa de um?</p>
</a>
</div>
</div>
</section>

<!-- Outros Setores -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Payroll Decision Layer em outros setores</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Cada setor tem suas próprias convenções coletivas, suas próprias regras de adicionais e seus próprios fatores de complexidade. O Decision Layer é o mesmo. A configuração é específica por setor.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/br/servicos/hr-agent/payroll-decision-layer/chemicals/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Química</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">169 bases de remuneração (13 regiões x 13 faixas), adicionais de turno, benefício futuro</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">88% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Em detalhe &rarr;</span>
</div>
</a>
<a href="/br/servicos/hr-agent/payroll-decision-layer/aviation/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Aviação</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">3 sindicatos, 14-18 convenções, ANAC/EASA FTL, senioridade de cockpit até nível 23</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">82% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Em detalhe &rarr;</span>
</div>
</a>
<a href="/br/servicos/hr-agent/payroll-decision-layer/retail/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Varejo</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">Convenções regionais, 64% tempo parcial, picos sazonais</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">92% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Em detalhe &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- AI Payroll Agent Varejo - folha de pagamento ---
> Payroll Decision Layer para o varejo brasileiro. 26 estados + DF, pisos regionais, contrato intermitente, adicionais. 92% Zero-Touch.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/br/por-que-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Cada decisão rastreável</p>
</div>
</a>
<a href="/br/por-que-gosign/#infraestrutura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Sua infraestrutura</p>
<p class="text-xs text-gosign-text-light">Sem SaaS. Sem vendor lock-in.</p>
</div>
</a>
<a href="/br/por-que-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Sem risco de cloud americana</p>
</div>
</a>
</div>
</div>
</div>
<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Payroll Decision Layer Setores">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/br/servicos/hr-agent/payroll-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Payroll Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/br/servicos/hr-agent/payroll-decision-layer/chemicals/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Química</a>
<a href="/br/servicos/hr-agent/payroll-decision-layer/aviation/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Aviação</a>
<a href="/br/servicos/hr-agent/payroll-decision-layer/financial-services/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Finanças</a>
<a href="/br/servicos/hr-agent/payroll-decision-layer/retail/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Varejo</a>
</div>
</div>
</nav>

<!-- Complexidade -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">576</span>
<p class="text-small text-gosign-text-light mt-1">Bases de remuneração</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">92%</span>
<p class="text-small text-gosign-text-light mt-1">Quota Zero-Touch</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">64%</span>
<p class="text-small text-gosign-text-light mt-1">Taxa de tempo parcial</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
<span class="w-4 h-2 rounded-sm bg-gosign-border"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">Alta complexidade de regras</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">Convenções coletivas do comércio varejista 2024-2026, 26 estados + DF, pisos regionais. Zero-Touch: modelo de simulação Gosign. Referências: Magazine Luiza, GPA. (PT: Sonae, Jerónimo Martins.)</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">O que o Agent classifica</p>
<h2 class="text-h1 font-bold text-gosign-dark">26 estados + DF, pisos regionais, um Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">O varejo brasileiro abrange convenções coletivas negociadas pelo Sindicato dos Comerciários / CONTRACS em 26 estados + DF, com pisos regionais distintos. 64% tempo parcial, 100.000 sazonais, 25,7% de rotatividade. (PT: Em Portugal, os sindicatos do comércio negociam por 18 distritos + regiões autónomas, com trabalho intermitente regulado pelo Art. 157 do Código do Trabalho.) Você conhece a complexidade. Assim o AI Agent a resolve:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">576 bases de remuneração (26 estados + DF, pisos regionais)</h3>
<p class="text-body text-gosign-text mt-2">Cada estado tem sua própria convenção de comércio negociada pelo Sindicato dos Comerciários, com pisos regionais distintos. O AI Agent reconhece a combinação correta a partir da localização da loja, função e tempo de casa. Em transferência de loja entre estados: alteração automática de toda a estrutura de remuneração. Referências: Magazine Luiza, GPA (Grupo Pão de Açúcar).</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">64% tempo parcial (contrato intermitente - Lei 13.467/2017)</h3>
<p class="text-body text-gosign-text mt-2">O contrato intermitente da Reforma Trabalhista permite convocação por demanda com períodos de inatividade. O AI Agent verifica em cada folha o tipo de contrato, horas convocadas e períodos de inatividade, classificando o enquadramento previdenciário correto (INSS, FGTS proporcional). Em mudanças de tipo de contrato: reclassificação automática de todos os encargos. (PT: Em Portugal, o trabalho intermitente segue o Art. 157 do Código do Trabalho, com garantias mínimas distintas da CLT.)</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">100.000 sazonais (contrato por prazo determinado - CLT Art. 443)</h3>
<p class="text-body text-gosign-text mt-2">Contratos por prazo determinado (CLT Art. 443) têm duração máxima de 2 anos com uma prorrogação. O AI Agent monitora cada contrato sazonal com controle exato de prazos - em todas as lojas. Na aproximação do limite legal: escalação automática. Em extrapolação: conversão automática para contrato por prazo indeterminado.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Acumulação de adicionais (só o maior, noturno aditivo)</h3>
<p class="text-body text-gosign-text mt-2">Adicional noturno 20% com hora reduzida, domingo 100%, feriado 100%. O AI Agent aplica a regra de acumulação: o maior adicional prevalece, o adicional noturno com hora reduzida é sempre calculado separadamente. Domingo à noite: 100% mais adicional noturno. Sem recálculo manual por turno.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">25,7% de rotatividade (fluxo permanente de admissões e desligamentos)</h3>
<p class="text-body text-gosign-text mt-2">Mais de 2.500 admissões e desligamentos por ano em 10.000 colaboradores. O AI Agent calcula remuneração proporcional, 13o salário proporcional, férias proporcionais com 1/3, FGTS com multa de 40% e aviso prévio automaticamente - cada caso individualmente, sem cálculo manual proporcional.</p>
</div>
</div>
</div>
</section>

<!-- Decision Flow -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Uma folha no varejo. 30 a 60 microdecisões.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Uma funcionária de tempo parcial no varejo com turnos noturnos e domingos. O Payroll Decision Layer decompõe sua folha em etapas de decisão individuais:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Etapa</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decisão</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decisor</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Fundamentação</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Classificar estado e convenção coletiva</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Localização da loja identifica a convenção estadual do Sindicato dos Comerciários</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Atribuir faixa salarial e nível</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Função atribuída à faixa salarial, tempo de casa ao nível de experiência</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Calcular remuneração base</td><td class="py-3 px-4">Convenção coletiva</td><td class="py-3 px-4">Lookup em tabela estadual: faixa + nível = salário base, verificação contra piso regional</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Calcular proporcionalidade de jornada</td><td class="py-3 px-4">Regra</td><td class="py-3 px-4">Cálculo proporcional conforme horas contratuais, valor-hora para adicionais</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Verificar tipo de contrato e enquadramento</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">CLT integral, parcial, intermitente (Lei 13.467) ou prazo determinado (Art. 443); encargos por tipo</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Classificar e acumular adicionais</td><td class="py-3 px-4">AI Agent + Convenção</td><td class="py-3 px-4">Noturno 20% com hora reduzida, domingo 100%, feriado 100% - só o maior adicional, noturno aditivo</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Calcular contribuições previdenciárias</td><td class="py-3 px-4">Regra</td><td class="py-3 px-4">INSS com faixa progressiva, FGTS 8%, contribuições patronais, intermitente proporcional</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">Verificar status de contrato sazonal</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Controle de prazo (CLT Art. 443), limite de 2 anos, prorrogação, eSocial</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Verificação de desvios</td><td class="py-3 px-4">IA detecta, humano decide</td><td class="py-3 px-4">IA detecta desvios de forma mais confiável. Mas a avaliação (mudança de contrato, erro, transferência de loja?) permanece com o ser humano - a CLT e os sindicatos exigem isso</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Gerar lançamentos contábeis</td><td class="py-3 px-4">Regra</td><td class="py-3 px-4">Contabilização FI/CO, multi-loja, centro de custo - determinístico</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Simulação -->
<section id="simulacao" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulação</p>
<h2 class="text-h1 font-bold text-white">Calculado para volumes do varejo</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Configuramos o Payroll Decision Layer com parâmetros realistas do varejo brasileiro. Convenções estaduais do Sindicato dos Comerciários, contrato intermitente (Reforma Trabalhista), sazonais por prazo determinado, acumulação de adicionais, alta rotatividade.</p>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Parâmetros da simulação</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Colaboradores</td><td class="py-3 px-4">5.000 a 50.000+ (vendas, caixa, estoque, administração)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Convenção coletiva</td><td class="py-3 px-4">Comércio varejista, 26 estados + DF, pisos regionais (Sindicato dos Comerciários / CONTRACS)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Bases de remuneração</td><td class="py-3 px-4">576 (estados x faixas x níveis)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Taxa de tempo parcial</td><td class="py-3 px-4">64% (CLT parcial, intermitente Lei 13.467, prazo determinado)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Sazonais</td><td class="py-3 px-4">Aprox. 100.000 (contrato por prazo determinado CLT Art. 443, encargos proporcionais)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Adicionais</td><td class="py-3 px-4">Noturno 20%, domingo 100%, feriado 100%, 13o salário, FGTS</td></tr>
</tbody>
</table>
</div>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Antes / Depois</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th scope="col" class="text-left py-3 px-4 font-semibold text-white">Dimensão</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manual</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Taxa de erro</td><td class="py-3 px-4">1-8% (APA)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 0,1%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Quota Zero-Touch</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">92%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Mudança de convenção</td><td class="py-3 px-4">Semanas (estados manualmente)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 24h (todos os estados)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Gestão de contratos intermitentes</td><td class="py-3 px-4">Manual, atrasada</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Tempo real, por folha</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Controle de sazonais</td><td class="py-3 px-4">Planilhas, lacunas entre lojas</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automático, todas as lojas</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Prontidão para auditoria</td><td class="py-3 px-4">Reconstruído manualmente</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Gerado automaticamente</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">APA: American Payroll Association. Convenções coletivas do comércio varejista 2024-2026, 26 estados + DF. Referências: Magazine Luiza, GPA. Resultados: modelo de simulação Gosign.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">Na simulação, o Decision Layer atinge uma quota Zero-Touch de 92%. Os 8% restantes são exceções reais: casos limítrofes de contratos sazonais, mudança entre intermitente e CLT integral, transferências de loja entre estados. Para os 92%, existe um dossiê de decisão completo e à prova de auditoria.</p>
</div>
</section>

<!-- Referência de Arquitetura -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Arquitetura e implementação</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">O Payroll Decision Layer opera integralmente na sua infraestrutura. Para o varejo brasileiro, isso significa: integração com controle de ponto de lojas, processamento de contratos intermitentes (Lei 13.467) e por prazo determinado (CLT Art. 443), convenções estaduais do Sindicato dos Comerciários, controle de sazonais em todas as unidades e Audit Trail completo até o SAP HCM. Projetos piloto típicos iniciam em até 3 meses com um estado e um grupo de lojas.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/br/servicos/hr-agent/payroll-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Visão geral Payroll Decision Layer &rarr;</a>
<a href="/br/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Arquitetura do Decision Layer &rarr;</a>
<a href="/br/servicos/infraestrutura/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infraestrutura em detalhe &rarr;</a>
<a href="/br/governance/co-determination/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Codecisão &rarr;</a>
<a href="/br/governance/cert-ready/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready by Design &rarr;</a>
<a href="/br/servicos/travel-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Travel Decision Layer &rarr;</a>
</div>
</div>
</section>


<!-- Weitere Agent-Lösungen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Mais soluções de agentes</h2>
<p class="text-body-lg text-gosign-text-light mt-4">HR Agents fazem parte do nosso portfólio de agentes. Para finanças e outras áreas, oferecemos soluções especializadas.</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8 max-w-content">
<a href="/br/hr-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR & People Operations</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Todos os HR Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Compatível com sindicato/CRE.</p>
</a>
<a href="/br/finance-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Finance & Accounting</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Finance AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Processamento de documentos, contabilização, depreciação, correções. Integração SAP/ERP.</p>
</a>
<a href="/br/contato/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Individual</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Co-Build para seu processo</h3>
<p class="text-body text-gosign-text-light mt-2">Compliance, operações, shared services - desenvolvemos agentes em modelo co-build.</p>
</a>
</div>
</div>
</section>

<!-- Aprofundamento -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Aprofundamento no Agent Briefing (Revista Gosign)</h2>
<p class="text-body text-gosign-text-light mb-6">Nossa série de artigos especializados para gestores que implementam AI Agents na empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/br/revista/decision-layer-payroll/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Finanças</p>
<p class="text-body font-semibold text-gosign-dark">Eliminar erros de folha de pagamento estruturalmente - Decision Layer para finanças</p>
</a>
<a href="/br/revista/comite-empresa-ia-codecisao/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Codecisão</p>
<p class="text-body font-semibold text-gosign-dark">Representação dos trabalhadores e IA - codecisão como restrição arquitetônica</p>
</a>
<a href="/br/revista/decision-layer-explicado/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Fundamentos</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - o que é e por que todo AI Agent empresarial precisa de um?</p>
</a>
</div>
</div>
</section>

<!-- Outros Setores -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Payroll Decision Layer em outros setores</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Cada setor tem suas próprias convenções coletivas, suas próprias regras de adicionais e seus próprios fatores de complexidade. O Decision Layer é o mesmo. A configuração é específica por setor.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/br/servicos/hr-agent/payroll-decision-layer/chemicals/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Química</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">169 bases de remuneração, 13 regiões tarifárias, adicionais de turno com acumulação, benefício futuro</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">88% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Em detalhe &rarr;</span>
</div>
</a>
<a href="/br/servicos/hr-agent/payroll-decision-layer/aviation/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Aviação</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">3 sindicatos, 14-18 convenções, ANAC/EASA FTL, senioridade de cockpit até nível 23</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">82% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Em detalhe &rarr;</span>
</div>
</a>
<a href="/br/servicos/hr-agent/payroll-decision-layer/financial-services/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Finanças</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">5 regimes de remuneração, Bonus-Deferral, Malus/Clawback, obrigações regulatórias</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">85% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Em detalhe &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- Payroll Decision Layer - folha de pagamento ---
> O Decision Layer decompõe cada folha de pagamento em etapas de decisão. Baseado em regras, auditável, 82-92% Zero-Touch.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/br/por-que-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Cada decisão rastreável</p>
</div>
</a>
<a href="/br/por-que-gosign/#infraestrutura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Sua infraestrutura</p>
<p class="text-xs text-gosign-text-light">Sem SaaS. Sem vendor lock-in.</p>
</div>
</a>
<a href="/br/por-que-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Sem risco de cloud americana</p>
</div>
</a>
</div>
</div>
</div>

<!-- Problema -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div><span class="text-h1 font-bold text-gosign-accent-text">1-8%</span><p class="text-small text-gosign-text-light mt-1">Taxa de erro na folha de pagamento</p></div>
<div><span class="text-h1 font-bold text-gosign-accent-text">EUR 260</span><p class="text-small text-gosign-text-light mt-1">Custo total por incidente de erro (R$ 1.520)</p></div>
<div><span class="text-h1 font-bold text-gosign-accent-text">10</span><p class="text-small text-gosign-text-light mt-1">Etapas de decisão por folha</p></div>
<p class="sm:col-span-3 text-xs text-gosign-text-light">American Payroll Association (APA); EY / HR Dive, "The True Cost of Payroll" (USD 281 por incidente, convertido à taxa média)</p>
</div>
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">O problema</p>
<h2 class="text-h1 font-bold text-gosign-dark">Por que sistemas de folha falham em organizações complexas</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">SAP HCM calcula corretamente. ADP calcula corretamente. Qualquer motor de folha calcula corretamente - quando os dados de entrada estão corretos. Mas em organizações com múltiplas convenções coletivas, modelos de turno, variações regionais e dezenas de regras de adicionais, o cálculo não é o problema. A decisão anterior é: qual tabela se aplica? Qual adicional incide? A acumulação é permitida?</p>
<div class="mt-10 grid grid-cols-1 sm:grid-cols-3 gap-6">
<div class="bg-gosign-light border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">1-8% de taxa de erro</h3><p class="text-small text-gosign-text-light mt-2">Múltiplas faixas salariais, regiões tarifárias, categorias de imposto, contribuições previdenciárias (INSS, FGTS), 13o salário, férias proporcionais, adicionais com regras de acumulação. Nenhum analista de folha conhece todas as regras em todos os territórios. 1-8% das folhas contêm erros (APA) - quanto mais complexo o cenário, maior a taxa.</p></div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">EUR 260 (R$ 1.520) por erro</h3><p class="text-small text-gosign-text-light mt-2">Um único erro de folha gera quatro processos consequentes: estorno da folha original, recálculo, correção de contribuições previdenciárias ao eSocial, retificação do imposto de renda retido na fonte. No total, um incidente de erro custa em média EUR 260 / R$ 1.520 (EY; estudo original: USD 281). Com 2.000 colaboradores e 1-8% de taxa de erro, são 20-160 incidentes por mês.</p></div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">Zero transparência de regras</h3><p class="text-small text-gosign-text-light mt-2">Quando a fiscalização pergunta: por que foi calculado 25% de adicional noturno em vez de 20%? Qual convenção coletiva vigorava naquele momento? A faixa salarial estava correta? Falta a comprovação. Sistemas de folha documentam resultados. Não as decisões que levaram a eles.</p></div>
</div>
</div>
</section>

<!-- Decision Layer -->
<section id="decision-layer" class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">O Decision Layer</p>
<h2 class="text-h1 font-bold text-gosign-dark">Cada folha. Decomposta em etapas de decisão.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">O Payroll Decision Layer decompõe cada folha de pagamento em etapas de decisão individuais. Para cada etapa está definido quem decide: o AI Agent classifica situações e detecta desvios - de forma mais confiável e rápida que qualquer analista de folha. O conjunto de regras calcula valores - de forma determinística e reproduzível. O ser humano permanece no processo onde a legislação trabalhista ou o risco de discriminação exigem uma decisão humana.</p>
<div class="mt-10 overflow-x-auto">
<table class="w-full text-left text-body">
<thead><tr class="border-b-2 border-gosign-dark"><th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Etapa</th><th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Decisão</th><th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Decisor</th><th scope="col" class="py-3 font-bold text-gosign-dark">Fundamentação</th></tr></thead>
<tbody class="text-gosign-text-light">
<tr class="border-b border-gosign-border"><td class="py-3 pr-4 font-medium text-gosign-dark">1</td><td class="py-3 pr-4">Validar categoria fiscal, deduções e dados previdenciários</td><td class="py-3 pr-4 font-medium">Regra</td><td class="py-3">Cruzamento com eSocial e dados cadastrais, determinístico</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4 font-medium text-gosign-dark">2</td><td class="py-3 pr-4">Verificar enquadramento na convenção coletiva</td><td class="py-3 pr-4 font-medium">AI Agent</td><td class="py-3">Agent classifica: qual convenção, qual faixa salarial, qual nível? Cruza com cadastro de pessoal e detecta inconsistências</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4 font-medium text-gosign-dark">3</td><td class="py-3 pr-4">Calcular remuneração base</td><td class="py-3 pr-4 font-medium">Convenção coletiva</td><td class="py-3">Lookup em tabela de convenção versionada: região + faixa + nível</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4 font-medium text-gosign-dark">4</td><td class="py-3 pr-4">Calcular adicionais (noturno/domingo/feriado)</td><td class="py-3 pr-4 font-medium">AI Agent + Convenção</td><td class="py-3">Agent classifica tipo de adicional a partir dos dados de turno. Convenção define percentuais + regra de acumulação</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4 font-medium text-gosign-dark">5</td><td class="py-3 pr-4">Identificar parcelas isentas de tributação</td><td class="py-3 pr-4 font-medium">Regra</td><td class="py-3">Adicional noturno, periculosidade, insalubridade conforme legislação aplicável</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4 font-medium text-gosign-dark">6</td><td class="py-3 pr-4">Calcular previdência complementar</td><td class="py-3 pr-4 font-medium">Regra</td><td class="py-3">Contribuição do empregado + participação do empregador, verificação de limites fiscais</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4 font-medium text-gosign-dark">7</td><td class="py-3 pr-4">Calcular contribuições previdenciárias</td><td class="py-3 pr-4 font-medium">Regra</td><td class="py-3">INSS com verificação de teto, FGTS 8%, contribuições patronais</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4 font-medium text-gosign-dark">8</td><td class="py-3 pr-4">Aplicar consignações e descontos judiciais</td><td class="py-3 pr-4 font-medium">Regra + Humano</td><td class="py-3">Tabela de descontos determinística; em conflitos de prioridade: Human-in-the-Loop</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4 font-medium text-gosign-dark">9</td><td class="py-3 pr-4">Verificação de desvios contra mês anterior</td><td class="py-3 pr-4 font-medium">IA detecta, humano decide</td><td class="py-3">A IA detecta desvios de forma mais confiável que qualquer analista. Mas a decisão sobre o que fazer com um desvio precisa ficar com o ser humano: foi uma promoção, um erro de dados ou um erro real de folha? Sem essa separação, verificação de compliance vira monitoramento de desempenho - e para isso a legislação trabalhista exige consentimento da representação dos trabalhadores.</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4 font-medium text-gosign-dark">10</td><td class="py-3 pr-4">Gerar lançamentos contábeis</td><td class="py-3 pr-4 font-medium">Regra</td><td class="py-3">Contabilização FI/CO, centro de custo, período contábil - determinístico</td></tr>
</tbody>
</table>
</div>
<p class="text-body text-gosign-text mt-8 max-w-narrow font-semibold">10 etapas por folha. O AI Agent pode executar cada uma delas de forma melhor e mais rápida que um analista de folha. Mesmo assim, o ser humano permanece em pontos definidos do processo - não porque ele é melhor, mas porque a legislação trabalhista ou o risco de discriminação o exigem. Com 10.000 colaboradores, são 100.000 microdecisões documentadas por mês.</p>
<div class="mt-10 grid grid-cols-1 sm:grid-cols-2 gap-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">IA classifica. Regra calcula.</h3><p class="text-small text-gosign-text-light mt-2">O AI Agent reconhece: qual convenção coletiva se aplica? Qual tipo de adicional incide? O enquadramento está correto? Essa classificação ele faz de forma mais confiável que qualquer analista. O cálculo do valor é então processado por Decision Tables versionadas - de forma determinística, reproduzível e auditável.</p></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">40 a 80 microdecisões por folha</h3><p class="text-small text-gosign-text-light mt-2">As 10 etapas principais se desdobram em dezenas de subetapas: cada adicional tem regras próprias de acumulação, cada contribuição previdenciária tem verificação própria de teto, cada consignação tem prioridade própria. Cada uma documentada individualmente.</p></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">AI Agent, regra ou humano</h3><p class="text-small text-gosign-text-light mt-2">O AI Agent classifica situações e toma decisões - de forma mais confiável que qualquer analista. O conjunto de regras calcula o valor. O ser humano permanece no processo onde a legislação trabalhista ou o risco de discriminação exigem uma decisão humana - não porque ele é melhor, mas porque ele deve.</p></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">Humano no loop: não expertise, mas responsabilidade</h3><p class="text-small text-gosign-text-light mt-2">Folha de pagamento tradicional exige verificação manual em todos os pontos. AI Agents conseguem fazer isso melhor. Mas em prioridade de consignações, avaliação de desvios e decisões de enquadramento, a legislação ou a representação dos trabalhadores exige uma decisão humana. O Decision Layer sabe onde - e escala apenas ali.</p></div>
</div>
</div>
</section>

<!-- Governança -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governança</p>
<h2 class="text-h1 font-bold text-gosign-dark">Não documentado posteriormente. Gerado no processo.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Quando a fiscalização pergunta "por que foram calculados 25% de adicional noturno?", dizer "está na convenção coletiva" não basta. Qual convenção? Qual versão? A regra de acumulação se aplicava? O Payroll Decision Layer gera para cada microdecisão um ato de decisão que responde exatamente a essas perguntas: entrada, regra de negócio aplicada com versão, confiança, resultado, carimbo de tempo e caminho de contestação. O mesmo ato torna a revisão da decisão individual possível de cumprir e comprovar nos termos da LGPD art. 20 (e do art. 86 do EU AI Act em negócios na UE).</p>
<div class="mt-10 bg-gosign-dark rounded-card p-6 sm:p-8">
<div class="flex items-start gap-4 mb-6"><svg class="w-8 h-8 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12h6m-6 4h6m2 5H7a2 2 0 01-2-2V5a2 2 0 012-2h5.586a1 1 0 01.707.293l5.414 5.414a1 1 0 01.293.707V19a2 2 0 01-2 2z" /></svg><div><h3 class="text-h3 font-bold text-white">Cada microdecisão gera um registro de auditoria</h3><p class="text-small text-gosign-text-on-dark/70 mt-1">Append-only. Nada é sobrescrito, nada é excluído. Em correções, são gerados registros de estorno e ajuste. Assinado com SHA-256, exportável a qualquer momento.</p></div></div>
<div class="grid grid-cols-2 sm:grid-cols-3 gap-3 sm:gap-4">
<div class="flex items-center gap-2.5"><svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg><span class="text-small text-gosign-text-on-dark/80">ID da regra + versão</span></div>
<div class="flex items-center gap-2.5"><svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg><span class="text-small text-gosign-text-on-dark/80">Convenção coletiva + período de vigência</span></div>
<div class="flex items-center gap-2.5"><svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg><span class="text-small text-gosign-text-on-dark/80">Dados de entrada (horas, tipo de adicional)</span></div>
<div class="flex items-center gap-2.5"><svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg><span class="text-small text-gosign-text-on-dark/80">Resultado (valor, tratamento fiscal)</span></div>
<div class="flex items-center gap-2.5"><svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg><span class="text-small text-gosign-text-on-dark/80">Decisor (regra / convenção / humano)</span></div>
<div class="flex items-center gap-2.5"><svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg><span class="text-small text-gosign-text-on-dark/80">Hash de entrada (reproduzível)</span></div>
</div>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8">
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6"><div class="flex items-start gap-3"><svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M15 12a3 3 0 11-6 0 3 3 0 016 0z" /><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M2.458 12C3.732 7.943 7.523 5 12 5c4.478 0 8.268 2.943 9.542 7-1.274 4.057-5.064 7-9.542 7-4.477 0-8.268-2.943-9.542-7z" /></svg><div><h3 class="text-body font-semibold text-gosign-dark">Transparente para a representação dos trabalhadores</h3><p class="text-small text-gosign-text-light mt-2">A legislação trabalhista exige transparência nos princípios de remuneração. Conjunto de regras consultável, decisões rastreáveis, detecção de anomalias controlável por Feature Flag, relatórios pseudonimizados.</p><a href="/br/governance/co-determination/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Participação &rarr;</a></div></div></div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6"><div class="flex items-start gap-3"><svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12l2 2 4-4m5.618-4.016A11.955 11.955 0 0112 2.944a11.955 11.955 0 01-8.618 3.04A12.02 12.02 0 003 9c0 5.591 3.824 10.29 9 11.622 5.176-1.332 9-6.03 9-11.622 0-1.042-.133-2.052-.382-3.016z" /></svg><div><h3 class="text-body font-semibold text-gosign-dark">Pronto para fiscalização</h3><p class="text-small text-gosign-text-light mt-2">Prazos de retenção suportados. Anonimização em vez de exclusão para compatibilidade com LGPD (PT: RGPD). Cada folha reproduzível via hash de entrada.</p><a href="/br/governance/cert-ready/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready &rarr;</a></div></div></div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6"><div class="flex items-start gap-3"><svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 5H7a2 2 0 00-2 2v12a2 2 0 002 2h10a2 2 0 002-2V7a2 2 0 00-2-2h-2M9 5a2 2 0 002 2h2a2 2 0 002-2M9 5a2 2 0 012-2h2a2 2 0 012 2m-6 9l2 2 4-4" /></svg><div><h3 class="text-body font-semibold text-gosign-dark">Compliance sistemática</h3><p class="text-small text-gosign-text-light mt-2">Cada folha é verificada contra o conjunto completo de regras - não por amostragem, mas sistematicamente. Desvios são detectados e documentados, não apenas na auditoria fiscal.</p></div></div></div>
</div>
</div>
</section>

<!-- Integração -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Integração</p>
<h2 class="text-h1 font-bold text-gosign-dark">Conecta-se ao seu ambiente de sistemas existente</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Seus sistemas permanecem. O trabalho manual de decisão antes deles desaparece. O Payroll Decision Layer se posiciona entre seus sistemas de origem e seu motor de folha - ele toma as decisões que hoje os analistas de folha tomam.</p>
<div class="grid grid-cols-1 md:grid-cols-3 gap-6 mt-10">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><div class="flex items-center gap-3 mb-4"><svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M20 7l-8-4-8 4m16 0l-8 4m8-4v10l-8 4m0-10L4 7m8 4v10M4 7v10l8 4" /></svg><h3 class="text-body font-semibold text-gosign-dark">Fontes de dados</h3></div><ul class="space-y-2 text-small text-gosign-text-light"><li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Controle de ponto (SAP, TOTVS, Senior)</span></li><li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Escalas de turno (sistemas de RH)</span></li><li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Cadastro de pessoal (SAP HCM, Workday)</span></li><li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>eSocial (interface governamental)</span></li><li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Base de convenções coletivas (versionada)</span></li></ul></div>
<div class="bg-gosign-dark border border-gosign-dark rounded-card p-6"><div class="flex items-center gap-3 mb-4"><svg class="w-6 h-6 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9.75 3.104v5.714a2.25 2.25 0 01-.659 1.591L5 14.5M9.75 3.104c-.251.023-.501.05-.75.082m.75-.082a24.301 24.301 0 014.5 0m0 0v5.714c0 .597.237 1.17.659 1.591L19.8 15.3M14.25 3.104c.251.023.501.05.75.082M19.8 15.3l-1.57.393A9.065 9.065 0 0112 15a9.065 9.065 0 00-6.23.693L5 14.5m14.8.8l1.402 1.402c1.232 1.232.65 3.318-1.067 3.611A48.309 48.309 0 0112 21c-2.773 0-5.491-.235-8.135-.687-1.718-.293-2.3-2.379-1.067-3.61L5 14.5" /></svg><h3 class="text-body font-semibold text-white">Payroll Decision Layer</h3></div><ul class="space-y-2 text-small text-gosign-text-on-dark/80"><li>Enquadramento em convenção coletiva</li><li>Cálculo de adicionais + acumulação</li><li>Parcelas isentas de tributação</li><li>Contribuições previdenciárias + verificação de teto</li><li>Consignações e descontos judiciais</li><li>Previdência complementar</li><li>Verificação de desvios + escalação</li></ul></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><div class="flex items-center gap-3 mb-4"><svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M5.25 14.25h13.5m-13.5 0a3 3 0 01-3-3m3 3a3 3 0 100 6h13.5a3 3 0 100-6m-16.5-3a3 3 0 013-3h13.5a3 3 0 013 3m-19.5 0a4.5 4.5 0 01.9-2.7L5.737 5.1a3.375 3.375 0 012.7-1.35h7.126c1.062 0 2.062.5 2.7 1.35l2.587 3.45a4.5 4.5 0 01.9 2.7m0 0a3 3 0 01-3 3m0 3h.008v.008h-.008v-.008zm0-6h.008v.008h-.008v-.008zm-3 6h.008v.008h-.008v-.008zm0-6h.008v.008h-.008v-.008z" /></svg><h3 class="text-body font-semibold text-gosign-dark">Sistemas de destino</h3></div><ul class="space-y-2 text-small text-gosign-text-light"><li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>SAP HCM / SuccessFactors (folha)</span></li><li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>TOTVS Protheus / ADP (folha)</span></li><li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>SAP FI/CO (contabilização)</span></li><li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>eSocial (obrigações acessórias)</span></li><li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Receita Federal (IRRF, DCTF)</span></li></ul></div>
</div>
</div>
</section>

<!-- Simulações -->
<section id="simulacoes" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulado para volumes Enterprise</p>
<h2 class="text-h1 font-bold text-white">Quatro setores. Calculados.</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Configuramos o Payroll Decision Layer para quatro setores e calculamos com convenções coletivas reais, regras de adicionais e estruturas de pessoal realistas. Cada card mostra os parâmetros da simulação e o resultado.</p>
<div class="grid grid-cols-1 md:grid-cols-2 gap-6 mt-10">
<a href="/br/servicos/hr-agent/payroll-decision-layer/chemicals/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors"><div class="flex items-center justify-between mb-4"><h3 class="text-h3 font-bold text-white">Química</h3><div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div></div><ul class="space-y-1.5 text-small text-gosign-text-on-dark/70"><li>13 faixas salariais x 27 estados = 351 bases</li><li>Adicionais de turno 6-10%, adicionais de insalubridade/periculosidade</li><li>Benefício futuro 23% (opção tripla: dinheiro/folga/previdência)</li><li>Previdência complementar empresarial, 13o salário + férias</li></ul><div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between"><span class="text-h3 font-bold text-gosign-accent-on-dark">88% Zero-Touch</span><span class="text-small text-gosign-accent-on-dark font-semibold">Química em detalhe &rarr;</span></div></a>
<a href="/br/servicos/hr-agent/payroll-decision-layer/aviation/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors"><div class="flex items-center justify-between mb-4"><h3 class="text-h3 font-bold text-white">Aviação</h3><div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div></div><ul class="space-y-1.5 text-small text-gosign-text-on-dark/70"><li>3 sindicatos, 14-18 convenções coletivas separadas</li><li>ANAC/EASA FTL: limite de 900h, Duty Period Limits</li><li>180+ diárias internacionais por país</li><li>Senioridade de cockpit até nível 23</li></ul><div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between"><span class="text-h3 font-bold text-gosign-accent-on-dark">82% Zero-Touch</span><span class="text-small text-gosign-accent-on-dark font-semibold">Aviação em detalhe &rarr;</span></div></a>
<a href="/br/servicos/hr-agent/payroll-decision-layer/financial-services/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors"><div class="flex items-center justify-between mb-4"><h3 class="text-h3 font-bold text-white">Finanças</h3><div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-white/20"></span></div></div><ul class="space-y-1.5 text-small text-gosign-text-on-dark/70"><li>5 regimes de remuneração paralelos (convenção até Risk Taker)</li><li>CMN/Bacen: Bonus-Deferral 40-60% ao longo de 4-5 anos</li><li>Malus/Clawback: 5-7 anos de recuperação</li><li>Requisitos Bacen: blocos de férias obrigatórias para traders</li></ul><div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between"><span class="text-h3 font-bold text-gosign-accent-on-dark">85% Zero-Touch</span><span class="text-small text-gosign-accent-on-dark font-semibold">Finanças em detalhe &rarr;</span></div></a>
<a href="/br/servicos/hr-agent/payroll-decision-layer/retail/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors"><div class="flex items-center justify-between mb-4"><h3 class="text-h3 font-bold text-white">Varejo</h3><div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-white/20"></span></div></div><ul class="space-y-1.5 text-small text-gosign-text-on-dark/70"><li>Convenções por estado/região, múltiplas faixas e níveis</li><li>64% tempo parcial, contratos temporários CLT</li><li>100.000 sazonais, 25,7% de rotatividade</li><li>Acumulação de adicionais: só o maior, noturno sempre aditivo</li></ul><div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between"><span class="text-h3 font-bold text-gosign-accent-on-dark">92% Zero-Touch</span><span class="text-small text-gosign-accent-on-dark font-semibold">Varejo em detalhe &rarr;</span></div></a>
</div>
</div>
</section>

<!-- Implementação -->
<section id="implementacao" class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Implementação</p>
<h2 class="text-h1 font-bold text-gosign-dark">Do piloto ao sistema em operação.</h2>
<div class="grid grid-cols-1 lg:grid-cols-2 gap-10 mt-10">
<div><h3 class="text-h3 font-bold text-gosign-dark mb-3">Arquitetura técnica</h3><p class="text-body text-gosign-text">O Payroll Decision Layer opera integralmente na sua infraestrutura: seu data center, sua rede, sua governança. Sem dependência de SaaS, sem vazamento de dados, sem telemetria externa. Containerizado, multitenant, pronto para deploy na sua Private Cloud ou como Managed Deployment em data centers na UE.</p><div class="flex flex-wrap gap-4 mt-3"><a href="/br/servicos/infraestrutura/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infraestrutura em detalhe &rarr;</a><a href="/br/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Arquitetura do Decision Layer &rarr;</a><a href="/br/revista/ato-de-decisao-decisoes-ia-contestaveis/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">O ato de decisão &rarr;</a><a href="/br/servicos/travel-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Travel Decision Layer &rarr;</a></div></div>
<div><h3 class="text-h3 font-bold text-gosign-dark mb-3">Implementação</h3><p class="text-body text-gosign-text">O Decision Layer não é instalado, mas configurado: suas convenções coletivas, suas regras de adicionais, seu ambiente de sistemas. Projetos piloto típicos iniciam em até 3 meses com um grupo de pessoal e uma convenção coletiva. Expansões para outros grupos de pessoal ou empresas do grupo ocorrem em paralelo ao piloto.</p></div>
</div>
<h3 class="text-h3 font-bold text-gosign-dark mt-12 mb-6">Alavanca econômica</h3>
<div class="grid grid-cols-1 sm:grid-cols-2 gap-6">
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6"><div class="flex items-start gap-4"><svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12l2 2 4-4m5.618-4.016A11.955 11.955 0 0112 2.944a11.955 11.955 0 01-8.618 3.04A12.02 12.02 0 003 9c0 5.591 3.824 10.29 9 11.622 5.176-1.332 9-6.03 9-11.622 0-1.042-.133-2.052-.382-3.016z" /></svg><div><p class="text-body font-semibold text-gosign-dark">Eliminar correções antes que ocorram</p><p class="text-small text-gosign-text-light mt-2">Cada folha passa pelo mesmo conjunto de regras. A taxa de erro de 1-8% (APA) surge da interpretação manual de regras. O Decision Layer aplica regras de forma consistente - em todas as regiões, todos os grupos de pessoal, todos os meses.</p></div></div></div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6"><div class="flex items-start gap-4"><svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M13 10V3L4 14h7v7l9-11h-7z" /></svg><div><p class="text-body font-semibold text-gosign-dark">Mudança de convenção em horas, não semanas</p><p class="text-small text-gosign-text-light mt-2">Implantar nova tabela salarial, definir período de vigência, recálculo retroativo automático. Sem atualização manual em cada região. Sem unidades esquecidas.</p></div></div></div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6"><div class="flex items-start gap-4"><svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M12 6v6h4.5m4.5 0a9 9 0 11-18 0 9 9 0 0118 0z" /></svg><div><p class="text-body font-semibold text-gosign-dark">82-92% Zero-Touch. Humano só onde legalmente necessário.</p><p class="text-small text-gosign-text-light mt-2">O AI Agent pode processar cada folha de forma melhor que um analista. Intervenções humanas permanecem onde a legislação trabalhista ou o risco de discriminação as exigem - não por razões técnicas.</p></div></div></div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6"><div class="flex items-start gap-4"><svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12h6m-6 4h6m2 5H7a2 2 0 01-2-2V5a2 2 0 012-2h5.586a1 1 0 01.707.293l5.414 5.414a1 1 0 01.293.707V19a2 2 0 01-2 2z" /></svg><div><p class="text-body font-semibold text-gosign-dark">Auditoria fiscal é uma exportação, não um projeto</p><p class="text-small text-gosign-text-light mt-2">Dossiês de decisão selados por folha. Qual regra, qual entrada, qual resultado. Semanas de preparação viram minutos.</p></div></div></div>
</div>
</div>
</section>

<!-- Segurança -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Segurança</p>
<h2 class="text-h1 font-bold text-gosign-dark">Segurança Enterprise. Desde o dia um.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Dados de remuneração estão entre os mais sensíveis da empresa. O Payroll Decision Layer foi projetado para ambientes regulados, onde proteção de dados, prontidão para auditoria e rastreabilidade não são extras opcionais.</p>
<div class="mt-10 grid grid-cols-1 sm:grid-cols-3 gap-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">100% infraestrutura do cliente</h3><p class="text-small text-gosign-text-light mt-2">O Decision Layer opera integralmente na sua rede. Sem dependência de SaaS, sem vazamento de dados, sem telemetria externa. Dados de remuneração não saem da sua rede.</p></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">LGPD by Design</h3><p class="text-small text-gosign-text-light mt-2">Anonimização em vez de exclusão. Compatível com prazos de retenção fiscais e LGPD (PT: RGPD). Sem conflito entre direito tributário e proteção de dados.</p><a href="/br/governance/data-residency/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Residência de dados em detalhe</a></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">Conformidade com regulação de IA</h3><p class="text-small text-gosign-text-light mt-2">Separação arquitetônica clara: o AI Agent classifica e detecta padrões. O cálculo de salários, adicionais e impostos é determinístico através de regras. Nenhuma caixa preta em valores, total rastreabilidade na classificação. Compatível com EU AI Act e PL 2338/2023 (regulação de IA no Brasil).</p><a href="/br/governance/eu-ai-act/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Regulação de IA em detalhe</a></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">Audit Trail (append-only)</h3><p class="text-small text-gosign-text-light mt-2">Dossiês de decisão assinados. Hash de entrada mais versão da regra resulta em resultado reproduzível. Pacotes de auditoria selados (JSON + PDF, SHA-256). Fiscalização a qualquer momento.</p></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">ISO 27001 / PS 951 cert-ready</h3><p class="text-small text-gosign-text-light mt-2">Registry de controles integrado, Evidence Runs automatizados, políticas versionadas. Compliance em operação contínua, não documentada posteriormente.</p><a href="/br/governance/cert-ready/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready by Design</a></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">SSO e separação de mandantes</h3><p class="text-small text-gosign-text-light mt-2">Integração com Identity Provider existente. Separação de mandantes em nível de banco de dados (Row Level Security). Modelo de permissões configurável de forma granular. Empresas do grupo claramente separadas.</p></div>
</div>
</div>
</section>


<!-- Weitere Agent-Lösungen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Mais soluções de agentes</h2>
<p class="text-body-lg text-gosign-text-light mt-4">HR Agents fazem parte do nosso portfólio de agentes. Para finanças e outras áreas, oferecemos soluções especializadas.</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8 max-w-content">
<a href="/br/hr-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR & People Operations</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Todos os HR Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Compatível com sindicato/CRE.</p>
</a>
<a href="/br/finance-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Finance & Accounting</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Finance AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Processamento de documentos, contabilização, depreciação, correções. Integração SAP/ERP.</p>
</a>
<a href="/br/contato/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Individual</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Co-Build para seu processo</h3>
<p class="text-body text-gosign-text-light mt-2">Compliance, operações, shared services - desenvolvemos agentes em modelo co-build.</p>
</a>
</div>
</div>
</section>

<!-- Este agente no catálogo -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark">Quando começar? Priorização e prontidão de governança</h2>
<p class="text-body text-gosign-text mt-4">O catálogo de agentes HR mostra pontuações, complexidade de governança, classificação EU AI Act e a tabela completa de microdecisões para este agente - posicionado em 3 quadrantes de priorização junto a 47 outros agentes HR.</p>
<a href="/br/catalogo-agentes-hr/payroll-processing-agent/" class="inline-flex items-center gap-2 mt-4 text-body font-semibold text-gosign-accent hover:underline">Ver sequenciamento e scores &rarr;</a>
</div>
</section>

<!-- Aprofundamento -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Aprofundamento no Agent Briefing (Revista Gosign)</h2>
<p class="text-body text-gosign-text-light mb-6">Nossa série de artigos especializados para gestores que implementam AI Agents na empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/br/revista/decision-layer-payroll/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors"><p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Finanças</p><p class="text-body font-semibold text-gosign-dark">Eliminar erros de folha de pagamento estruturalmente - Decision Layer para finanças</p></a>
<a href="/br/revista/comite-empresa-ia-codecisao/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors"><p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Participação</p><p class="text-body font-semibold text-gosign-dark">Representação dos trabalhadores e IA - participação dos trabalhadores como restrição arquitetônica</p></a>
<a href="/br/revista/decision-layer-explicado/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors"><p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Fundamentos</p><p class="text-body font-semibold text-gosign-dark">Decision Layer - o que é e por que todo AI Agent empresarial precisa de um?</p></a>
</div>
</div>
</section>

--- AI Infrastructure Engineering ---
> LLM Hosting, pipeline RAG, orquestração e deployment. Agnóstico de modelos, self-hosted ou nuvem. A plataforma de produção para AI Agents na sua infraestrutura.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/br/por-que-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Cada decisão rastreável</p>
</div>
</a>
<a href="/br/por-que-gosign/#infraestrutura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Sua infraestrutura</p>
<p class="text-xs text-gosign-text-light">Sem SaaS. Sem vendor lock-in.</p>
</div>
</a>
<a href="/br/por-que-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Sem risco de cloud americana</p>
</div>
</a>
</div>
</div>
</div>

<!-- Por que infraestrutura é o gargalo -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Por que infraestrutura é o gargalo</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
A maioria das empresas que pilotam AI Agents não falha por causa do modelo. Os modelos funcionam. Falham por causa da infraestrutura: sem framework de governança, sem Audit Trail, sem isolamento de inquilinos, sem conceito de deployment, sem integração com sistemas existentes.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Um piloto em um notebook não é uma arquitetura de produção. Esta página descreve as tecnologias e configurações concretas que transformam um experimento LLM em um sistema operacional.
</p>
<p class="text-body text-gosign-text-light mt-4">
Como os componentes individuais de infraestrutura se articulam arquitetonicamente, está detalhado na <a href="/br/governance/reference-architecture/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Arquitetura de Referência de 7 Camadas</a>.
</p>
</div>
</div>
</section>

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">eBook gratuito: Infraestrutura de IA</p>
<p class="text-body text-gosign-text mb-4">Build, Buy, Hybrid - infraestrutura em conformidade regulatória com B/B/H-Framework e 7-Layer Reference Architecture.</p>
<a href="/br/ebook/ia-infraestrutura-manual-governanca/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Baixar grátis</a>
</div>

<!-- 1. LLM Hosting -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Quatro componentes de infraestrutura</h2>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">1. LLM Hosting</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
A camada de modelos. Onde a compreensão linguística acontece.
</p>
<p class="text-body-lg text-gosign-text-light mt-4"><strong>Cloud-LLMs:</strong></p>
<ul class="mt-2 space-y-2">
<li class="text-body-lg text-gosign-text-light">Azure OpenAI (ChatGPT, Claude) - regiões Brasil e UE, DPA da Microsoft</li>
<li class="text-body-lg text-gosign-text-light">Amazon Bedrock (Claude, Llama, Mistral) - regiões Brasil e UE, DPA da AWS</li>
<li class="text-body-lg text-gosign-text-light">Google Vertex AI (Gemini) - regiões UE, DPA do Google</li>
<li class="text-body-lg text-gosign-text-light">Anthropic API (Claude) - com EU Data Processing</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-4"><strong>Self-Hosted-LLMs:</strong></p>
<ul class="mt-2 space-y-2">
<li class="text-body-lg text-gosign-text-light">Llama (Meta) - Open Source, em hardware próprio</li>
<li class="text-body-lg text-gosign-text-light">Mistral - Open Source, empresa da UE</li>
<li class="text-body-lg text-gosign-text-light">DeepSeek - Open Source, custo-eficiente</li>
<li class="text-body-lg text-gosign-text-light"><a href="https://openai.com/open-models/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">gpt-oss</a> (OpenAI) - Open Weight, Apache 2.0, completamente self-hostável. 120B em uma única H100, 20B em hardware de consumo de 16 GB.</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-4"><strong>Frameworks de inferência para Self-Hosted:</strong></p>
<ul class="mt-2 space-y-2">
<li class="text-body-lg text-gosign-text-light"><a href="https://ollama.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Ollama</a> - Entrada simples, desenvolvimento local, deployment na borda</li>
<li class="text-body-lg text-gosign-text-light"><a href="https://docs.vllm.ai/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">vLLM</a> - Production-grade, otimizado para GPU, alto throughput</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-4"><strong>Híbrido:</strong></p>
<ul class="mt-2 space-y-2">
<li class="text-body-lg text-gosign-text-light">Self-Hosted para dados sensíveis (RH, finanças)</li>
<li class="text-body-lg text-gosign-text-light">Cloud-LLMs para cargas menos críticas (classificação de documentos)</li>
<li class="text-body-lg text-gosign-text-light">Roteamento automático conforme classificação de dados</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-4">
A escolha do modelo é uma ponderação entre desempenho, custo, proteção de dados e latência. Assessoramos na seleção e implementamos de forma agnóstica - uma troca de modelo não altera a lógica de negócio. Mais detalhes: <a href="/br/revista/modelos-ia-comparacao-2026/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Modelos IA em comparação 2026</a> e <a href="/br/revista/llm-self-hosting-enterprise/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">LLM Self-Hosting para empresas</a>.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Nossos AI Engineers possuem certificações Microsoft para Azure AI Services. As opções de deployment incluem <a href="https://azure.microsoft.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Microsoft Azure</a>, <a href="https://cloud.google.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">GCP</a> e infraestrutura completamente self-hosted - a decisão arquitetônica pertence ao cliente, não ao fornecedor.
</p>
</div>
</div>
</section>

<!-- 2. Pipeline RAG -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h3 class="text-h3 font-bold text-gosign-dark">2. Pipeline RAG</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Retrieval Augmented Generation - como agentes acessam o conhecimento empresarial.
</p>
</div>
<img src="/images/diagrams/rag-pipeline-br.svg" alt="Pipeline RAG: Documentos são fragmentados em chunks, armazenados como embeddings no Vector Store, recuperados semanticamente sob consulta e fornecidos ao LLM como contexto" class="w-full mt-6" width="1200" height="400" loading="lazy" />
<div class="max-w-narrow mt-6">
<p class="text-body-lg text-gosign-text-light"><strong>Características de qualidade:</strong></p>
<ul class="mt-2 space-y-2">
<li class="text-body-lg text-gosign-text-light">Chunking semântico (por conteúdo, não por número de página)</li>
<li class="text-body-lg text-gosign-text-light">Enriquecimento de metadados (tipo de documento, versão, escopo de validade)</li>
<li class="text-body-lg text-gosign-text-light">Busca híbrida (busca vetorial + busca por palavra-chave para precisão)</li>
<li class="text-body-lg text-gosign-text-light">Citação de fonte em cada resposta (documento, página, parágrafo)</li>
<li class="text-body-lg text-gosign-text-light">Re-indexação regular quando documentos são alterados</li>
</ul>
</div>
</div>
</section>

<!-- 3. Orquestração -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h3 class="text-h3 font-bold text-gosign-dark">3. Orquestração</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
O controle de fluxo. Como agentes, sistemas e pessoas trabalham juntos.
</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light"><strong><a href="https://trigger.dev" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Trigger.dev</a> ou <a href="https://camunda.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Camunda</a>:</strong> Motor de workflow open-source. Workflows visuais, integração via API, webhooks. Self-hosted, sem vendor lock-in.</li>
<li class="text-body-lg text-gosign-text-light"><strong>API Gateway:</strong> Ponto de entrada unificado. Rate limiting, autenticação, logging, monitoramento.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Sistema de Filas:</strong> Processamento assíncrono para processos em lote (fechamento mensal, importação em massa).</li>
<li class="text-body-lg text-gosign-text-light"><strong>Sistema de Eventos:</strong> Reação em tempo real a documentos recebidos, mudanças de status, escalações.</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-4">
A orquestração é a diferença entre "um agente pode fazer algo" e "um agente faz algo de forma confiável em produção". Veja também: <a href="/br/revista/orquestracao-agentes-plataformas/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Plataformas de orquestração de agentes</a>.
</p>
</div>
</div>
</section>

<!-- 4. Deployment -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h3 class="text-h3 font-bold text-gosign-dark">4. Deployment</h3>
<p class="text-body-lg text-gosign-text-light mt-4">Onde a infraestrutura roda. Todas as opções com data residency no Brasil ou na UE.</p>

<h4 class="text-body-lg font-bold text-gosign-dark mt-6">Azure (Brasil e UE)</h4>
<ul class="mt-2 space-y-1">
<li class="text-body text-gosign-text-light">Azure Kubernetes Service (AKS) para orquestração de containers</li>
<li class="text-body text-gosign-text-light">Azure SQL / PostgreSQL para dados e Audit Trail</li>
<li class="text-body text-gosign-text-light">Azure OpenAI para LLM hosting</li>
<li class="text-body text-gosign-text-light">Regiões: Brazil South (São Paulo), West Europe, Germany West Central</li>
</ul>

<h4 class="text-body-lg font-bold text-gosign-dark mt-6">AWS (Brasil e UE)</h4>
<ul class="mt-2 space-y-1">
<li class="text-body text-gosign-text-light">Amazon EKS para orquestração de containers</li>
<li class="text-body text-gosign-text-light">Amazon RDS / Aurora PostgreSQL para dados e Audit Trail</li>
<li class="text-body text-gosign-text-light">Amazon Bedrock para LLM hosting (Claude, Llama, Mistral)</li>
<li class="text-body text-gosign-text-light">Regiões: sa-east-1 (São Paulo), eu-central-1 (Frankfurt), eu-west-1 (Irlanda)</li>
</ul>

<h4 class="text-body-lg font-bold text-gosign-dark mt-6">GCP (Brasil e UE)</h4>
<ul class="mt-2 space-y-1">
<li class="text-body text-gosign-text-light">Google Kubernetes Engine (GKE) para orquestração de containers</li>
<li class="text-body text-gosign-text-light">Cloud SQL / AlloyDB para dados e Audit Trail</li>
<li class="text-body text-gosign-text-light">Vertex AI para LLM hosting</li>
<li class="text-body text-gosign-text-light">Regiões: southamerica-east1 (São Paulo), europe-west1, europe-west3</li>
</ul>

<h4 class="text-body-lg font-bold text-gosign-dark mt-6">Vercel EU + Supabase (Brasil ou UE)</h4>
<ul class="mt-2 space-y-1">
<li class="text-body text-gosign-text-light">Vercel para frontend e edge functions em data centers UE</li>
<li class="text-body text-gosign-text-light">Supabase para banco de dados (PostgreSQL), auth e storage</li>
<li class="text-body text-gosign-text-light">Supabase suporta região sa-east-1 (São Paulo) via AWS - dados permanecem no Brasil</li>
<li class="text-body text-gosign-text-light">Opção leve de deployment sem infraestrutura Kubernetes própria</li>
<li class="text-body text-gosign-text-light">Serviços managed com data residency no Brasil ou na UE</li>
</ul>

<h4 class="text-body-lg font-bold text-gosign-dark mt-6">Self-Hosted</h4>
<ul class="mt-2 space-y-1">
<li class="text-body text-gosign-text-light"><a href="https://www.docker.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Docker</a> / <a href="https://kubernetes.io/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Kubernetes</a> em hardware próprio</li>
<li class="text-body text-gosign-text-light"><a href="https://www.postgresql.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">PostgreSQL</a> com <a href="https://github.com/pgvector/pgvector" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">pgvector</a> para dados e busca vetorial</li>
<li class="text-body text-gosign-text-light">LLMs open-source em GPUs próprias</li>
<li class="text-body text-gosign-text-light">Total independência do Cloud Act</li>
</ul>

<h4 class="text-body-lg font-bold text-gosign-dark mt-6">Híbrido</h4>
<ul class="mt-2 space-y-1">
<li class="text-body text-gosign-text-light">Combinação conforme classificação de dados e requisitos LGPD (PT: RGPD)</li>
<li class="text-body text-gosign-text-light">Cargas sensíveis self-hosted, cargas padrão na nuvem</li>
<li class="text-body text-gosign-text-light">Orquestração unificada em todos os ambientes</li>
</ul>
</div>
</div>
</section>

<!-- Stack Tecnológico -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Stack Tecnológico</h2>
<div class="mt-8 overflow-x-auto">
<table class="w-full text-left text-small border-collapse">
<thead>
<tr>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Componente</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Tecnologia</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Por que</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Motor de workflow</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://trigger.dev" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Trigger.dev</a>, <a href="https://camunda.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Camunda</a></td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Open source, self-hosted, sem vendor lock-in</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Banco de dados</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://www.postgresql.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">PostgreSQL</a> + <a href="https://github.com/pgvector/pgvector" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">pgvector</a></td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Enterprise-ready, RLS, busca vetorial integrada</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Backend</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://www.python.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Python</a>, <a href="https://www.typescriptlang.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">TypeScript</a></td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Comprovados para ML e desenvolvimento de APIs</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Frontend</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://react.dev/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">React</a> / <a href="https://nextjs.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Next.js</a></td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Para Dashboard, Chat UI, Portal de Auditor</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Containers</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://www.docker.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Docker</a>, <a href="https://kubernetes.io/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Kubernetes</a></td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Padrão para nuvem e self-hosted</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">API</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">REST, <a href="https://graphql.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">GraphQL</a></td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Integração com sistemas existentes</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Auth</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://supabase.com/auth" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Supabase Auth</a> / OIDC</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Compatível com SSO, integrável com provedores de identidade empresariais</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Monitoramento</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://prometheus.io/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Prometheus</a>, <a href="https://grafana.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Grafana</a></td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Open source, self-hosted, dashboards em tempo real</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Inferência</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://ollama.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Ollama</a>, <a href="https://docs.vllm.ai/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">vLLM</a></td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Inferência de LLM self-hosted, otimizada para GPU</td></tr>
</tbody>
</table>
</div>
</div>
</div>
</section>

<!-- Governança integrada -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Governança integrada</h2>
<p class="text-body-lg text-gosign-text-light mt-4">A infraestrutura inclui Governance by Design:</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light"><strong>Audit Trail</strong> no nível de infraestrutura (não apenas no nível de aplicação)</li>
<li class="text-body-lg text-gosign-text-light"><strong>Row-Level Security</strong> no nível de banco de dados - <a href="/br/governance/data-residency/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Data Residency em detalhe</a></li>
<li class="text-body-lg text-gosign-text-light"><strong>Criptografia</strong> em repouso e em trânsito</li>
<li class="text-body-lg text-gosign-text-light"><strong>RBAC</strong> em todos os componentes</li>
<li class="text-body-lg text-gosign-text-light"><a href="/br/governance/cert-ready/" class="text-gosign-dark hover:text-gosign-accent-text transition-colors"><strong>Cert-Ready Controls</strong></a> como objetos de dados técnicos</li>
</ul>
<p class="mt-4">
<a href="/br/governance/reference-architecture/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Governança na arquitetura de 7 camadas -></a>
</p>
</div>
</div>
</section>

<!-- Acesso ao código -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Acesso ao código-fonte e independência</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
A infraestrutura opera nos sistemas do cliente - Azure, GCP, AWS ou Self-Hosted. Sem SaaS, sem hosting na Gosign. Acesso completo ao código-fonte, todas as configurações e conjuntos de regras. Stack open-source onde possível. Componentes proprietários apenas nos LLMs - e lá de forma agnóstica.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Após 12-18 meses, você opera a infraestrutura de forma independente.
</p>
</div>
</div>
</section>

<!-- Aprofundamento -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Aprofundamento no Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nossa série de artigos para executivos que implementam agentes de IA na empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/br/revista/infraestrutura-ia-blueprint-2026/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">Enterprise AI-Infraestrutura Blueprint 2026</p>
</a>
<a href="/br/revista/hosting-ia-estrategias-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">Hosting de IA: EU SaaS, data center europeu ou Self-Hosted?</p>
</a>
<a href="/br/revista/llm-self-hosting-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">LLM Self-Hosting para Enterprise - Azure, GCP, On-Premise</p>
</a>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark mb-6">Para aprofundar</h2>
<div class="grid gap-6 sm:grid-cols-2">
<div class="border-l-4 border-gosign-dark pl-6 py-4">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Arquitetura</p>
<h3 class="text-h3 font-bold text-gosign-dark">Arquitetura de Referência de 7 Camadas</h3>
<p class="text-body text-gosign-text-light mt-2">Como os componentes de infraestrutura se articulam arquitetonicamente - Presentation, Orchestration, Agent, Decision Layer, Model, Integration, Infrastructure.</p>
<a href="/br/governance/reference-architecture/" class="text-small font-semibold text-gosign-accent-text hover:text-gosign-accent-hover mt-3 inline-block whitespace-nowrap">Ver Arquitetura de Referência -></a>
</div>
<div class="border-l-4 border-gosign-dark pl-6 py-4">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Recurso de conhecimento</p>
<h3 class="text-h3 font-bold text-gosign-dark">Blueprint 2026</h3>
<p class="text-body text-gosign-text-light mt-2">Onze artigos sobre as decisões de infraestrutura que importam em 2026: modelos de IA, hosting, RAG, orquestração, custos, EU AI Act.</p>
<div class="mt-3 flex flex-wrap gap-3">
<a href="/br/revista/infraestrutura-ia-blueprint-2026/" class="text-small font-semibold text-gosign-accent-text hover:text-gosign-accent-hover whitespace-nowrap">Visão geral -></a>
<a href="/br/revista/modelos-ia-comparacao-2026/" class="text-small font-semibold text-gosign-accent-text hover:text-gosign-accent-hover whitespace-nowrap">Modelos IA 2026 -></a>
</div>
</div>
<div class="border-l-4 border-gosign-dark pl-6 py-4">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Dados</p>
<h3 class="text-h3 font-bold text-gosign-dark">Data Residency</h3>
<p class="text-body text-gosign-text-light mt-2">Onde os dados residem, como garantir o isolamento de inquilinos e o que Data Residency significa na prática - com opções no Brasil e na UE.</p>
<a href="/br/governance/data-residency/" class="text-small font-semibold text-gosign-accent-text hover:text-gosign-accent-hover mt-3 inline-block whitespace-nowrap">Data Residency em detalhe -></a>
</div>
<div class="border-l-4 border-gosign-dark pl-6 py-4">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Agentes</p>
<h3 class="text-h3 font-bold text-gosign-dark">AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Document Agents, Workflow Agents, Knowledge Agents - três tipos de agentes para processos empresariais.</p>
<a href="/br/servicos/ai-agents/" class="text-small font-semibold text-gosign-accent-text hover:text-gosign-accent-hover mt-3 inline-block whitespace-nowrap">Explorar AI Agents -></a>
</div>
</div>
</div>
</div>
</section>

--- Engenharia de Software Empresarial desde 2001 ---
> Mais de 5.000 projetos para Airbus, Volkswagen, Shell. 25 anos de desenvolvimento de software empresarial - hoje o fundamento para infraestrutura de IA.

<!-- Story -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">25 Anos de Software Empresarial</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
A Gosign desenvolve software para clientes empresariais desde 2001. Mais de 5.000 projetos para <a href="/br/referencias/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Airbus, Volkswagen, Shell e outros</a>. O fundamento: segurança, escalabilidade e manutenibilidade em ambientes de grandes organizações.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Desde 2022, o foco está em <a href="/br/servicos/ai-agents/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">infraestrutura de IA e agent engineering</a>. Não como pivot, mas como evolução consequente. Os requisitos são os mesmos: arquitetura, governança, escalabilidade.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Não somos uma startup de IA de dois anos. Somos uma empresa de engenharia com 25 anos construindo software empresarial.
</p>
</div>
</section>

<!-- O Que Construímos Hoje -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">O Que Construímos Hoje</h2>
<div class="grid grid-cols-1 md:grid-cols-2 gap-6 lg:gap-8 mt-6">
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M13.19 8.688a4.5 4.5 0 0 1 1.242 7.244l-4.5 4.5a4.5 4.5 0 0 1-6.364-6.364l1.757-1.757m9.864-9.864a4.5 4.5 0 0 0-6.364 6.364l4.5 4.5a4.5 4.5 0 0 0 7.244 1.242" /></svg>
<h3 class="text-h3 font-bold text-gosign-dark mt-4">Integrações Personalizadas</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Conexão de AI Agents com sistemas existentes. SAP, TOTVS, SuccessFactors, Workday, Microsoft Graph - via REST, SOAP, RFC. A integração é onde a maioria dos projetos de IA falha.
</p>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M14.25 9.75 16.5 12l-2.25 2.25m-4.5 0L7.5 12l2.25-2.25M6 20.25h12A2.25 2.25 0 0 0 20.25 18V6A2.25 2.25 0 0 0 18 3.75H6A2.25 2.25 0 0 0 3.75 6v12A2.25 2.25 0 0 0 6 20.25Z" /></svg>
<h3 class="text-h3 font-bold text-gosign-dark mt-4">Desenvolvimento de APIs</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
REST e GraphQL. Autenticação, rate limiting, versionamento, documentação.
</p>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="m21 7.5-9-5.25L3 7.5m18 0-9 5.25m9-5.25v9l-9 5.25M3 7.5l9 5.25M3 7.5v9l9 5.25m0-9v9" /></svg>
<h3 class="text-h3 font-bold text-gosign-dark mt-4">Arquitetura de Sistemas</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Modelo de dados, estratégia de implantação, conceito de escalamento, arquitetura de segurança.
</p>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 17.25v1.007a3 3 0 0 1-.879 2.122L7.5 21h9l-.621-.621A3 3 0 0 1 15 18.257V17.25m6-12V15a2.25 2.25 0 0 1-2.25 2.25H5.25A2.25 2.25 0 0 1 3 15V5.25m18 0A2.25 2.25 0 0 0 18.75 3H5.25A2.25 2.25 0 0 0 3 5.25m18 0V12a2.25 2.25 0 0 1-2.25 2.25H5.25A2.25 2.25 0 0 1 3 12V5.25" /></svg>
<h3 class="text-h3 font-bold text-gosign-dark mt-4">Plataformas Empresariais</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Dashboards, portais de auditor, interfaces de chat, ferramentas de workflow.
</p>
</article>
</div>
</div>
</section>

<!-- Princípios de Engenharia -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Princípios de Engenharia</h2>
<div class="mt-6 space-y-4">
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">TDD & Pair Programming contínuo:</strong> Cada linha de código é escrita em pair programming. Tests antes do código. Cada função tem tests. Cada merge requer tests verdes.</p>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">CI/CD:</strong> Pipeline automatizado. Cada push é testado. Cada merge é implantado.</p>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Code Review:</strong> Quatro olhos para todas as mudanças em produção.</p>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Security by Design:</strong> RBAC, criptografia, validação de entrada desde o dia 1.</p>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Audit Trail:</strong> Cada mudança documentada. Quem mudou o quê quando.</p>
</div>
</div>
</section>

<!-- Stack Tecnológico -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">Stack Tecnológico</h2>
<div class="overflow-x-auto -mx-4 sm:mx-0">
<table class="w-full text-left text-small border-collapse min-w-[36rem]">
<thead>
<tr>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Área</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Tecnologias</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Backend</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://www.python.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Python</a>, <a href="https://www.typescriptlang.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">TypeScript</a>, Node.js</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Frontend</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://react.dev/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">React</a>, <a href="https://nextjs.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Next.js</a></td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Banco de dados</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://www.postgresql.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">PostgreSQL</a>, Supabase</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Workflow</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://trigger.dev" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Trigger.dev</a>, <a href="https://n8n.io/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">n8n</a>, <a href="https://camunda.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Camunda</a></td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Containers</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://www.docker.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Docker</a>, <a href="https://kubernetes.io/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Kubernetes</a></td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">CI/CD</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://github.com/features/actions" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">GitHub Actions</a>, <a href="https://docs.gitlab.com/ee/ci/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">GitLab CI</a></td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Monitoramento</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://prometheus.io/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Prometheus</a>, <a href="https://grafana.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Grafana</a></td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Auth</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://supabase.com/auth" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Supabase Auth</a>, OIDC</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- De Software para Infraestrutura de IA -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">De Software para Infraestrutura de IA</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Os princípios de engenharia que valem para desenvolvimento de software empresarial também valem para <a href="/br/servicos/infraestrutura/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">infraestrutura de IA</a>. Um AI Agent em produção precisa da mesma disciplina que qualquer outro software empresarial: testes, pipelines de implantação, monitoramento, Audit Trail, segurança.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
A diferença: um AI Agent toma decisões profissionais que devem ser documentadas e rastreáveis. Isso requer componentes arquiteturais adicionais - o <a href="/br/decision-layer/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Decision Layer</a>, Governance by Design, controles <a href="/br/governance/cert-ready/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Cert-Ready</a>. Mas o fundamento é engenharia de software.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
25 anos desse fundamento é a razão pela qual nossa infraestrutura de IA funciona.
</p>
</div>
</section>

<!-- Aprofundamento -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Aprofundamento no Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nossa série de artigos para executivos que implementam agentes de IA na empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/br/revista/integracao-ia-panorama-ti/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Integração</p>
<p class="text-body font-semibold text-gosign-dark">Integração de IA em infraestruturas de TI existentes</p>
</a>
<a href="/br/revista/agentes-ia-enterprise-guia/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">AI Agents</p>
<p class="text-body font-semibold text-gosign-dark">De chatbots a agentes IA: MCP, A2A e sistemas Multi-Agent</p>
</a>
<a href="/br/revista/infraestrutura-ia-blueprint-2026/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">Enterprise AI-Infraestrutura Blueprint 2026</p>
</a>
</div>
</div>
</section>

--- AI Travel Agent Aviação - Custos de tripulação ---
> Decision Layer para despesas de viagem de tripulações. Processamento baseado em rotações, diárias por convenção coletiva, tarifas variáveis.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/br/por-que-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Cada decisão rastreável</p>
</div>
</a>
<a href="/br/por-que-gosign/#infraestrutura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Sua infraestrutura</p>
<p class="text-xs text-gosign-text-light">Sem SaaS. Sem vendor lock-in.</p>
</div>
</a>
<a href="/br/por-que-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Sem risco de cloud americana</p>
</div>
</a>
</div>
</div>
</div>

<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Travel Decision Layer Setores">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/br/servicos/travel-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Travel Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/br/servicos/travel-decision-layer/aviacao/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Aviação</a>
<a href="/br/servicos/travel-decision-layer/consultoria/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Consultoria</a>
<a href="/br/servicos/travel-decision-layer/logistica/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Logística</a>
<a href="/br/servicos/travel-decision-layer/vendas/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Vendas</a>
</div>
</div>
</nav>

<!-- Por que aviação tem a maior complexidade -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<!-- Indicadores da simulação como introdução visual -->
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">100.000+</span>
<p class="text-small text-gosign-text-light mt-1">Casos/ano (simulação)</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">95%</span>
<p class="text-small text-gosign-text-light mt-1">Taxa Zero-Touch</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">10 - 20%</span>
<p class="text-small text-gosign-text-light mt-1">Taxa de IROP (padrão do setor)</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">Maior complexidade de regras</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">Casos e Zero-Touch: modelo de simulação Gosign. Taxa de IROP: EUROCONTROL / US DOT BTS / ANAC Brasil, 2024.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">O que o Agent classifica</p>
<h2 class="text-h1 font-bold text-gosign-dark">Três grupos de pessoal, um Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Ferramentas de despesas digitalizam processos manuais: capturar, aprovar, contabilizar. O AI Agent funciona de forma diferente - classifica cada caso e aplica o conjunto de regras correto em cada passo. Com centenas de milhares de casos por ano, múltiplas convenções coletivas em paralelo e taxas de IROP de dois dígitos, essa é a diferença entre gerenciar formulários e tomar decisões de forma automatizada.</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Centenas de rotações por dia</h3>
<p class="text-body text-gosign-text mt-2">Em companhias aéreas como LATAM, Azul e Gol no Brasil ou TAP em Portugal, viajar não é exceção, é a norma. O AI Agent classifica cada rotação automaticamente por grupo de pessoal e gera o caso de despesas correspondente. Com centenas de rotações por dia, o Agent processa em minutos o que captura manual transformaria em gargalo sistêmico.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Três a cinco países por dia de serviço</h3>
<p class="text-body text-gosign-text mt-2">Uma única rotação pode passar por três, quatro ou cinco países. O AI Agent classifica cada segmento por país e duração de permanência. O motor de regras seleciona a diária correta - integral ou reduzida - deterministicamente para cada trecho.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Override tarifário por grupo de pessoal</h3>
<p class="text-body text-gosign-text mt-2">Cockpit, cabine, solo e manutenção tipicamente têm convenções coletivas diferentes. O AI Agent classifica o grupo de pessoal por colaborador. O motor de regras aplica automaticamente a diária tarifária quando ela prevalece sobre a taxa legal - sem intervenção manual, sem erro de seleção.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Volatilidade IROP em tempo real</h3>
<p class="text-body text-gosign-text mt-2">Atrasos, mudanças de hotel, reposicionamento de tripulação. O AI Agent classifica o tipo de irregularidade (IROP) e aciona o recálculo pelo motor de regras com base no itinerário real. Cada ajuste documentado no Audit Trail - plano original e execução real lado a lado.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Governance de volume sem amostragem</h3>
<p class="text-body text-gosign-text mt-2">Quando milhares de colaboradores geram casos idênticos diariamente, cada erro sistemático se multiplica. O AI Agent verifica 100% dos casos contra o motor de regras. Diária incorreta em 50 rotações por dia não passa despercebida - é detectada e documentada imediatamente.</p>
</div>
</div>
</div>
</section>

<!-- Fluxo de Decisão -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Uma rotação. 40 a 120 micro-decisões.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Um membro da tripulação voa uma rotação de três dias com layover. O Decision Layer decompõe isso em passos de decisão individuais:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Passo</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Decisão</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Decisor</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Justificativa</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Ler rotação da escala de serviço</td><td class="py-3 px-4">Automático</td><td class="py-3 px-4">Importação de dados, sem decisão</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Determinar sequência de países</td><td class="py-3 px-4">Motor de regras</td><td class="py-3 px-4">GPS ou plano: quais países, qual duração</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Selecionar diária por país</td><td class="py-3 px-4">Motor de regras</td><td class="py-3 px-4">Diárias conforme CLT e convenções coletivas</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Verificar override de convenção coletiva</td><td class="py-3 px-4">Motor de regras</td><td class="py-3 px-4">Convenção coletiva específica de tripulação prevalece sobre taxas legais</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Calcular dedução de refeições</td><td class="py-3 px-4">Motor de regras</td><td class="py-3 px-4">Refeições fornecidas reduzem diária deterministicamente</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Classificar IROP</td><td class="py-3 px-4">AI</td><td class="py-3 px-4">Atraso, desvio, reposicionamento: AI classifica o tipo</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Recalcular impacto do IROP</td><td class="py-3 px-4">Motor de regras</td><td class="py-3 px-4">Duração ou país alterado: recalcular diária</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">Verificar hotel de layover</td><td class="py-3 px-4">AI + Motor de regras</td><td class="py-3 px-4">AI extrai dados do hotel, motor de regras verifica conformidade com política</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Atribuir centro de custo</td><td class="py-3 px-4">Motor de regras</td><td class="py-3 px-4">Rotação para frota, frota para centro de custo</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Gerar dossiê de auditoria</td><td class="py-3 px-4">Automático</td><td class="py-3 px-4">Dossiê de decisão selado por rotação</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Resultados da simulação -->
<section id="simulation" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulação</p>
<h2 class="text-h1 font-bold text-white">Calculado para volumes de aviação</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Configuramos o Travel Decision Layer com parâmetros realistas de aviação e executamos os cálculos. Os resultados mostram o que muda em volumes enterprise.</p>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Parâmetros da simulação</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Membros da tripulação</td><td class="py-3 px-4">10.000 a 50.000+ (múltiplos grupos de pessoal com convenções coletivas próprias)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Convenções coletivas</td><td class="py-3 px-4">2 a 5 em paralelo (por grupo de pessoal e companhia aérea)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Casos/ano</td><td class="py-3 px-4">100.000 a 1.000.000+</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Jurisdições</td><td class="py-3 px-4">Multi-jurisdição (Brasil, Portugal, países da UE e além). LGPD (PT: RGPD) para proteção de dados. EU AI Act diretamente aplicável em Portugal; no Brasil, o PL 2338/2023 prevê regulamentação equivalente.</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Integração de sistemas</td><td class="py-3 px-4">Planejamento de tripulação &rarr; Decision Layer &rarr; ERP/Folha de Pagamento</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Taxa de IROP</td><td class="py-3 px-4">10 - 20% de todas as rotações com desvio do plano (padrão do setor)</td></tr>
</tbody>
</table>
</div>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Antes / Depois</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th class="text-left py-3 px-4 font-semibold text-white">Dimensão</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manual</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Custo de processamento</td><td class="py-3 px-4">a partir de EUR 53 / R$ 310 (base GBTA)*</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; EUR 9 (R$ 53)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Taxa de erro</td><td class="py-3 px-4">19% (GBTA)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 0,3%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Tempo de processamento</td><td class="py-3 px-4">5 - 12 dias úteis</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Minutos</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Taxa Zero-Touch</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">95%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Prontidão para auditoria</td><td class="py-3 px-4">Reconstruída manualmente</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Gerada automaticamente</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Mudança de convenção coletiva</td><td class="py-3 px-4">Semanas</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 24h</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Correção retroativa</td><td class="py-3 px-4">Sobrescrita manual</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Estorno + ajuste (append-only)</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">* GBTA Foundation 2024: USD 58 por transação (aprox. EUR 53 / R$ 310). Valores em BRL são aproximados. Casos de tripulação com lógica de convenções coletivas, multi-jurisdição e gestão de IROP ficam tipicamente acima. Taxa de IROP: EUROCONTROL Annual Report, 2024. Resultados da simulação: modelo de cálculo Gosign.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">Na simulação, o Decision Layer alcança uma taxa Zero-Touch de 95% - independentemente de processar 100.000 ou 1.000.000 de casos por ano. Apenas 5% requerem atenção humana. Para os 95% restantes, existe um dossiê de decisão completo e pronto para auditoria. Correções e mudanças de convenções coletivas geram lançamentos de estorno e ajuste - sem sobrescritas, histórico contábil completo.</p>
</div>
</section>

<!-- Referência de arquitetura -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Arquitetura e implementação</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">O Travel Decision Layer opera inteiramente na sua infraestrutura: seu centro de dados, sua rede, seu controle. Sem dependência SaaS, sem vazamento de dados. Para aviação, isso significa: integração com sistemas de planejamento de tripulação, processamento de dados de rotação em tempo real, conjuntos de regras específicos por convenção coletiva para cada grupo de pessoal e Audit Trail contínuo até SAP FI/CO. Projetos piloto típicos começam em 3 meses com um grupo de tripulação e uma convenção coletiva.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/br/servicos/travel-decision-layer/#implementation" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Arquitetura, implementação e alavancas em detalhe &rarr;</a>
<a href="/br/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Arquitetura do Decision Layer &rarr;</a>
<a href="/br/servicos/infraestrutura/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infraestrutura em detalhe &rarr;</a>
<a href="/br/governance/co-determination/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Participação dos Trabalhadores &rarr;</a>
<a href="/br/governance/cert-ready/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready by Design &rarr;</a>
</div>
</div>
</section>

<!-- Aprofundamento -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Aprofundamento no Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nossa série de artigos para executivos que implementam agentes de IA na empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/br/revista/decision-layer-explicado/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Fundamentos</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - O que é e por que todo agente AI enterprise precisa de um</p>
</a>
<a href="/br/revista/comite-empresa-ia-codecisao/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Codecisão</p>
<p class="text-body font-semibold text-gosign-dark">Comitê de Empresa e IA, Participação dos Trabalhadores como Constraint Arquitetônico</p>
</a>
<a href="/br/revista/eu-ai-act-hr/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Regulamentação</p>
<p class="text-body font-semibold text-gosign-dark">EU AI Act e RH - O que agora é obrigatório</p>
</a>
</div>
</div>
</section>

<!-- Outros setores -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Travel Decision Layer em outros setores</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Cada setor tem suas próprias tarifas, estruturas de custos e fatores de complexidade. O Decision Layer é o mesmo. A configuração é setorial.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/br/servicos/travel-decision-layer/consultoria/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Consultoria</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">Split de clientes, multi-centro de custos, política</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">85% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Em detalhe &rarr;</span>
</div>
</a>
<a href="/br/servicos/travel-decision-layer/logistica/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Logística</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">GPS, regulamentação ANTT/Mercosul (PT: Pacote de Mobilidade UE), Zero-Touch motoristas</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">95% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Em detalhe &rarr;</span>
</div>
</a>
<a href="/br/servicos/travel-decision-layer/vendas/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Vendas</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">500 equipe de campo, integração CRM, representação</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">90% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Em detalhe &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- AI Travel Agent Consultoria - Custos de viagem ---
> Decision Layer para despesas de viagem de consultoria. Split três vias tributário/cliente/interno, semanas multi-cliente, centros de custo.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/br/por-que-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Cada decisão rastreável</p>
</div>
</a>
<a href="/br/por-que-gosign/#infraestrutura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Sua infraestrutura</p>
<p class="text-xs text-gosign-text-light">Sem SaaS. Sem vendor lock-in.</p>
</div>
</a>
<a href="/br/por-que-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Sem risco de cloud americana</p>
</div>
</a>
</div>
</div>
</div>

<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Travel Decision Layer Setores">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/br/servicos/travel-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Travel Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/br/servicos/travel-decision-layer/aviacao/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Aviação</a>
<a href="/br/servicos/travel-decision-layer/consultoria/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Consultoria</a>
<a href="/br/servicos/travel-decision-layer/logistica/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Logística</a>
<a href="/br/servicos/travel-decision-layer/vendas/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Vendas</a>
</div>
</div>
</nav>

<!-- Por que consultoria é complexa -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<!-- Indicadores de simulação como introdução visual -->
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">50.000+</span>
<p class="text-small text-gosign-text-light mt-1">Casos/ano (simulação)</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">85%</span>
<p class="text-small text-gosign-text-light mt-1">Taxa Zero-Touch</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">3 vias</span>
<p class="text-small text-gosign-text-light mt-1">Split de custos (tributário/cliente/interno)</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-border"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">Alta complexidade normativa</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">Casos e Zero-Touch: modelo de simulação Gosign. Benchmarks do setor: GBTA Foundation, 2015.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">O que o Agent classifica</p>
<h2 class="text-h1 font-bold text-gosign-dark">Três splits, um Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Ferramentas de despesas digitalizam processos manuais: capturar, aprovar, contabilizar. O AI Agent funciona de forma diferente - classifica cada caso e aplica o conjunto de regras correto a cada etapa. Em consultorias como Big Four, boutiques especializadas em São Paulo e Rio de Janeiro ou escritórios portugueses convergem cinco dimensões de complexidade que ferramentas padrão não conseguem gerenciar.</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Divisão tripla por transação</h3>
<p class="text-body text-gosign-text mt-2">Cada despesa de viagem em consultoria tem três perspectivas de custo. O AI Agent classifica simultaneamente: tratamento tributário (dedutível, parcialmente dedutível, não dedutível), atribuição ao cliente (repassável, não repassável, misto) e alocação interna (centro de custo, projeto, overhead). O motor de regras calcula cada split deterministicamente.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Semanas multi-cliente divididas automaticamente</h3>
<p class="text-body text-gosign-text mt-2">Um consultor visita cliente A na segunda e terça, cliente B na quarta, viaja de volta na quinta. O AI Agent classifica cada dia por cliente com base em dados de calendário e CRM. O motor de regras divide hotel, diária e tratamento tributário por dia e cliente - deterministicamente, sem estimativa manual.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Conflito de políticas resolvido automaticamente</h3>
<p class="text-body text-gosign-text mt-2">Políticas internas de viagem e orçamentos específicos de clientes frequentemente colidem. O AI Agent classifica qual política se aplica por transação. O motor de regras aplica a regra mais restritiva e documenta no Audit Trail qual política prevaleceu e por quê.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Custos de representação por jurisdição</h3>
<p class="text-body text-gosign-text mt-2">Jantares de negócios com clientes têm regras tributárias específicas por jurisdição. O AI Agent classifica cada despesa por tipo, valor e número de participantes. O motor de regras aplica a alíquota de dedução correta por país - no Brasil tratamento específico na legislação do IRPJ/CSLL (PT: IRC em Portugal), na Alemanha 70%, na Áustria 50%.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Faturamento de clientes documentado automaticamente</h3>
<p class="text-body text-gosign-text mt-2">Quando 200 consultores geram 4 viagens de clientes por mês cada, cada erro de divisão se multiplica. O AI Agent verifica 100% dos casos e gera automaticamente a base de faturamento por cliente, incluindo dados para emissão de NF-e - com Audit Trail completo que documenta cada split e cada decisão.</p>
</div>
</div>
</div>
</section>

<!-- Fluxo de Decisão -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Uma semana de consultoria. 20 a 60 micro-decisões.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Um consultor visita três clientes em uma semana com jantares de negócios e hotéis variáveis. O Decision Layer decompõe essa semana em etapas de decisão individuais:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Passo</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Decisão</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Decisor</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Justificativa</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Atribuir viagem ao projeto do cliente</td><td class="py-3 px-4">Motor de regras</td><td class="py-3 px-4">Integração com calendário ou CRM</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Determinar diária</td><td class="py-3 px-4">Motor de regras</td><td class="py-3 px-4">Diárias conforme CLT e convenções coletivas</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Dividir hospedagem: repassável vs. interno</td><td class="py-3 px-4">Motor de regras</td><td class="py-3 px-4">Condições contratuais do cliente determinam o split</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Verificar política de viagem do cliente</td><td class="py-3 px-4">Motor de regras</td><td class="py-3 px-4">Econômica do cliente vs. primeira classe interna</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Aplicar política mais restritiva</td><td class="py-3 px-4">Motor de regras</td><td class="py-3 px-4">A mais restritiva prevalece</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Classificação tributária</td><td class="py-3 px-4">Motor de regras</td><td class="py-3 px-4">Dedutível, parcialmente dedutível, representação</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Dividir dia com múltiplos clientes</td><td class="py-3 px-4">AI + Motor de regras</td><td class="py-3 px-4">AI determina alocação de tempo, regras aplicam split de custos</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">Gerar base de faturamento por cliente</td><td class="py-3 px-4">Automático</td><td class="py-3 px-4">Documentação de despesas pronta para auditoria por cliente</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Classificar despesas de representação</td><td class="py-3 px-4">AI + Motor de regras</td><td class="py-3 px-4">AI identifica tipo de comprovante, motor de regras aplica alíquotas de dedução por jurisdição</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Gerar dossiê de auditoria</td><td class="py-3 px-4">Automático</td><td class="py-3 px-4">Dossiê de decisões lacrado por semana de consultoria</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Resultado da simulação -->
<section id="simulation" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulação</p>
<h2 class="text-h1 font-bold text-white">Calculado para volumes de consultoria</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Configuramos o Travel Decision Layer com parâmetros realistas de consultoria e calculamos. Os resultados mostram o que muda em volumes Enterprise.</p>

<!-- Tabela de parâmetros -->
<h3 class="text-h3 font-bold text-white mt-10 mb-4">Parâmetros da simulação</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Consultores</td><td class="py-3 px-4">100 a 500+ (com regras de política específicas por cliente)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Contratos de clientes</td><td class="py-3 px-4">10 a 50+ em paralelo (cada um com suas políticas de viagem)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Casos/ano</td><td class="py-3 px-4">50.000 a 250.000+</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Jurisdições</td><td class="py-3 px-4">Multi-jurisdição (BR, PT, DE, AT, CH, outros países UE). LGPD (PT: RGPD) para proteção de dados.</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Integração de sistemas</td><td class="py-3 px-4">CRM/controle de horas &rarr; Decision Layer &rarr; ERP/Folha de pagamento</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Proporção de representação</td><td class="py-3 px-4">15 - 25% de todos os casos contêm comprovantes de representação</td></tr>
</tbody>
</table>
</div>

<!-- Comparação de resultados -->
<h3 class="text-h3 font-bold text-white mt-10 mb-4">Antes / Depois</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th class="text-left py-3 px-4 font-semibold text-white">Dimensão</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manual</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Custo de processamento</td><td class="py-3 px-4">a partir de EUR 53 / R$ 310 (base GBTA)*</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; EUR 9 (R$ 53)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Taxa de erro</td><td class="py-3 px-4">19% (GBTA)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 0,3%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Tempo de processamento</td><td class="py-3 px-4">5 - 12 dias úteis</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Minutos</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Taxa Zero-Touch</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">85%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Prontidão para auditoria</td><td class="py-3 px-4">Reconstruída manualmente</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Gerada automaticamente</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Precisão do split</td><td class="py-3 px-4">Estimada manualmente</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Calculada deterministicamente</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Faturamento ao cliente</td><td class="py-3 px-4">Atribuído manualmente</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Documentado automaticamente</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">* GBTA Foundation 2024: USD 58 por transação (aprox. EUR 53 / R$ 310). Valores em BRL são aproximados. Casos de consultoria com split de três vias e lógica multi-cliente são tipicamente superiores no setor. Resultados da simulação: modelo de cálculo Gosign.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">Na simulação, o Decision Layer alcança uma taxa Zero-Touch de 85% - em casos padrão com atribuição de cliente unívoca. Os 15% restantes referem-se a dias com múltiplos clientes e casos especiais que exigem avaliação humana. Para todos os casos existe um dossiê de decisões completo e pronto para auditoria.</p>
</div>
</section>

<!-- Referência de arquitetura -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Arquitetura e implementação</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">O Travel Decision Layer funciona completamente na sua infraestrutura: seu data center, sua rede, seu controle. Sem dependência SaaS, sem vazamento de dados. Para configurações de consultoria, isso significa: capacidade multi-cliente com conjuntos de regras de políticas separados, integração com sistemas de gestão de projetos e controle de horas, e divisão automática de três vias. Projetos piloto típicos começam em 3 meses com um pool de clientes.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/br/servicos/travel-decision-layer/#implementation" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Arquitetura, implementação e alavancas em detalhe &rarr;</a>
<a href="/br/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Arquitetura do Decision Layer &rarr;</a>
<a href="/br/servicos/infraestrutura/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infraestrutura em detalhe &rarr;</a>
<a href="/br/governance/co-determination/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Codecisão &amp; Sindicato &rarr;</a>
<a href="/br/governance/cert-ready/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready by Design &rarr;</a>
</div>
</div>
</section>

<!-- Aprofundamento -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Aprofundamento no Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nossa série de artigos para executivos que implementam agentes de IA na empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/br/revista/decision-layer-explicado/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Fundamentos</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - O que é e por que todo agente AI enterprise precisa de um</p>
</a>
<a href="/br/revista/agent-governance-hr/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governança</p>
<p class="text-body font-semibold text-gosign-dark">Agent Governance no RH - Por que o CHRO precisa liderar</p>
</a>
<a href="/br/revista/cert-ready-by-design/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Auditoria</p>
<p class="text-body font-semibold text-gosign-dark">Cert-Ready by Design - IA pronta para auditoria desde o início</p>
</a>
</div>
</div>
</section>

<!-- Outros setores -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Travel Decision Layer em outros setores</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Cada setor tem suas próprias tarifas, estruturas de custos e fatores de complexidade. O Decision Layer é o mesmo. A configuração é setorial.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/br/servicos/travel-decision-layer/aviacao/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Aviação</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">Tripulação, IROP, convenções coletivas</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">95% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Em detalhe &rarr;</span>
</div>
</a>
<a href="/br/servicos/travel-decision-layer/logistica/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Logística</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">GPS, regulamentação ANTT/Mercosul (PT: Pacote de Mobilidade UE), Zero-Touch motoristas</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">95% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Em detalhe &rarr;</span>
</div>
</a>
<a href="/br/servicos/travel-decision-layer/vendas/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Vendas</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">500 equipe de campo, integração CRM, representação</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">90% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Em detalhe &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- AI Travel Agent Logística - Custos de transporte ---
> Decision Layer para despesas de viagem logísticas. Detecção de país por GPS, dados de compliance, modo Zero-Touch para motoristas.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/br/por-que-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Cada decisão rastreável</p>
</div>
</a>
<a href="/br/por-que-gosign/#infraestrutura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Sua infraestrutura</p>
<p class="text-xs text-gosign-text-light">Sem SaaS. Sem vendor lock-in.</p>
</div>
</a>
<a href="/br/por-que-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Sem risco de cloud americana</p>
</div>
</a>
</div>
</div>
</div>

<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Travel Decision Layer Setores">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/br/servicos/travel-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Travel Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/br/servicos/travel-decision-layer/aviacao/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Aviação</a>
<a href="/br/servicos/travel-decision-layer/consultoria/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Consultoria</a>
<a href="/br/servicos/travel-decision-layer/logistica/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Logística</a>
<a href="/br/servicos/travel-decision-layer/vendas/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Vendas</a>
</div>
</div>
</nav>

<!-- Por que logística é única -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<!-- Indicadores-chave como introdução visual -->
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">500.000+</span>
<p class="text-small text-gosign-text-light mt-1">Operações/ano (simulação)</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">95%</span>
<p class="text-small text-gosign-text-light mt-1">Taxa Zero-Touch</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">27+</span>
<p class="text-small text-gosign-text-light mt-1">Estados BR + jurisdições EU/EFTA</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-border"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">Alta complexidade normativa</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">Operações e Zero-Touch: modelo de simulação Gosign. Jurisdições: 27 estados BR + EU/EFTA. Regulamentação: ANTT (Brasil), Pacote de Mobilidade UE Diretiva 2020/1057 (Portugal/UE).</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">O que o Agent classifica</p>
<h2 class="text-h1 font-bold text-gosign-dark">27 estados, 30+ jurisdições UE, um Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Ferramentas de despesas são construídas para viagens de negócios ocasionais: um funcionário viaja, preenche um formulário, o supervisor aprova. Em logística e transporte no Brasil com 27 estados ou em Portugal com operações transfronteiriças na UE, isso não funciona. O AI Agent classifica cada trajeto automaticamente e o motor de regras calcula as diárias deterministicamente.</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Atribuição de país baseada em GPS</h3>
<p class="text-body text-gosign-text mt-2">Motoristas cruzam fronteiras várias vezes por dia. O AI Agent classifica cada segmento do trajeto por país e duração de permanência a partir de dados GPS de sistemas de telemática. O motor de regras calcula diárias específicas por localização - sem que o motorista precise parar para preencher formulários.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Regulamentação de transporte documentada automaticamente</h3>
<p class="text-body text-gosign-text mt-2">A regulamentação da ANTT exige documentação para operações de transporte interestadual e internacional. O AI Agent classifica cada trajeto por tipo de operação e jurisdição. O sistema gera automaticamente a base de dados que equipes de compliance precisam - sem carga adicional para motoristas. (PT: Pacote de Mobilidade UE documentado pelo IMT em Portugal.)</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Consistência em toda a frota</h3>
<p class="text-body text-gosign-text mt-2">Uma frota de 500 caminhões percorre as mesmas rotas diariamente. O AI Agent aplica a mesma classificação para rotas idênticas, independentemente do motorista. O motor de regras calcula diárias idênticas para trajetos idênticos - eliminando variação dependente do indivíduo e risco de fiscalização em volume.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Modo zero-touch para motoristas</h3>
<p class="text-body text-gosign-text mt-2">A tarefa do motorista é dirigir, não administrar. O AI Agent opera em modo Zero-Touch para rotas padrão: dados GPS entram, o motor de regras calcula diárias, exportação para folha sai pronta. O motorista só é consultado para exceções reais - lacunas de GPS ou rotas novas.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Precisão ao minuto em cruzamentos de fronteira</h3>
<p class="text-body text-gosign-text mt-2">Um caminhão cruza a divisa entre São Paulo e Minas Gerais às 23:45, ou a fronteira entre Portugal e Espanha na UE. A diária muda à meia-noite. O AI Agent classifica o cruzamento com precisão ao minuto a partir de dados GPS. O motor de regras calcula proporcionalmente para cada jurisdição - três países em um único dia de serviço, cada um com a diária correta.</p>
</div>
</div>
</div>
</section>

<!-- Fluxo de Decisão -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Uma viagem de motorista. 15 a 40 micro-decisões.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Um motorista faz uma rota por três países com pernoite. O Decision Layer decompõe essa rota em passos de decisão individuais:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Passo</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Decisão</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Decisor</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Justificativa</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Ler rastreamento GPS da telemática</td><td class="py-3 px-4">Automático</td><td class="py-3 px-4">Importação de dados, sem decisão</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Determinar sequência de estados/países e duração</td><td class="py-3 px-4">Motor de regras</td><td class="py-3 px-4">Coordenadas GPS mapeadas em jurisdições</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Selecionar diária por localização</td><td class="py-3 px-4">Motor de regras</td><td class="py-3 px-4">Diárias conforme CLT e convenções coletivas</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Calcular cruzamento de fronteira à meia-noite</td><td class="py-3 px-4">Motor de regras</td><td class="py-3 px-4">Cálculo proporcional para cruzamento de fronteira à meia-noite</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Verificar limite de deslocamento de longa duração</td><td class="py-3 px-4">Motor de regras</td><td class="py-3 px-4">Limites baseados em duração por jurisdição</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Gerar dados de documentação regulatória</td><td class="py-3 px-4">Automático</td><td class="py-3 px-4">Documentação de deslocamento como base de dados</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Atribuir centro de custo da frota</td><td class="py-3 px-4">Motor de regras</td><td class="py-3 px-4">Veículo para frota, frota para centro de custo</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">Gerar exportação para folha de pagamento</td><td class="py-3 px-4">Automático</td><td class="py-3 px-4">Dados de diárias prontos para lançamento</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Verificar conformidade do tempo de descanso</td><td class="py-3 px-4">Motor de regras</td><td class="py-3 px-4">Tempos de condução e descanso conforme legislação vigente (BR: CLT + ANTT; PT: Regulamento UE 561/2006)</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Gerar dossiê de auditoria</td><td class="py-3 px-4">Automático</td><td class="py-3 px-4">Dossiê de decisões lacrado por viagem de motorista</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Resultado da simulação -->
<section id="simulation" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulação</p>
<h2 class="text-h1 font-bold text-white">Calculado para volumes logísticos</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Configuramos o Travel Decision Layer com parâmetros logísticos realistas e calculamos os resultados. Os dados mostram o que muda com tamanhos de frota Enterprise.</p>

<!-- Tabela de parâmetros -->
<h3 class="text-h3 font-bold text-white mt-10 mb-4">Parâmetros da simulação</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Frota</td><td class="py-3 px-4">200 a 2.000+ veículos (próprios e subcontratados)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Motoristas</td><td class="py-3 px-4">300 a 3.000+ (com diferentes modelos contratuais)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Operações/ano</td><td class="py-3 px-4">500.000 a 2.000.000+</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Jurisdições</td><td class="py-3 px-4">27 estados BR + 30+ jurisdições EU/EFTA. LGPD (PT: RGPD) para proteção de dados.</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Integração sistêmica</td><td class="py-3 px-4">Telemática &rarr; Decision Layer &rarr; ERP/Folha</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Travessias de fronteira/dia</td><td class="py-3 px-4">500 a 5.000+ (dependente da frota)</td></tr>
</tbody>
</table>
</div>

<!-- Comparação de resultados -->
<h3 class="text-h3 font-bold text-white mt-10 mb-4">Antes / Depois</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th class="text-left py-3 px-4 font-semibold text-white">Dimensão</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manual</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Custo de processamento</td><td class="py-3 px-4">a partir de EUR 53 / R$ 310 (base GBTA)*</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; EUR 5 (R$ 29)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Taxa de erro</td><td class="py-3 px-4">19% (GBTA)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 0,1%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Tempo de processamento</td><td class="py-3 px-4">5 - 12 dias úteis</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Minutos</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Taxa Zero-Touch</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">95%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Prontidão para auditoria</td><td class="py-3 px-4">Reconstruído manualmente</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Gerado automaticamente</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Dados regulatórios de transporte</td><td class="py-3 px-4">Inseridos manualmente</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Gerados automaticamente</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Consultas de motoristas</td><td class="py-3 px-4">3 - 5 por semana</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 0,1 por semana</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">* GBTA Foundation 2024: USD 58 por transação (aprox. EUR 53 / R$ 310). Valores em BRL são aproximados. Operações logísticas com detecção de país por GPS são significativamente mais econômicas no modo Zero-Touch. Pacote de Mobilidade UE: Diretiva 2020/1057. Resultados da simulação: modelo de cálculo Gosign.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">Na simulação, o Decision Layer alcança uma taxa Zero-Touch de 95% - em rotas padrão com cobertura GPS. Os 5% restantes referem-se a lacunas de GPS, rotas novas e casos especiais. Para todos os casos há um dossiê de decisões completo e pronto para auditoria. Motoristas não precisam preencher nenhum formulário.</p>
</div>
</section>

<!-- Referência de arquitetura -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Arquitetura e implementação</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">O Travel Decision Layer funciona integralmente na sua infraestrutura: seu data center, sua rede, seu controle. Sem dependência de SaaS, sem vazamento de dados. Para configurações logísticas, isso significa: interfaces telemáticas para importação de dados GPS, processamento de travessias de fronteira em tempo real e cálculo de diárias em nível de frota em mais de 30 jurisdições EU/EFTA. Projetos piloto típicos começam em 3 meses com um grupo de frota e as rotas mais percorridas.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/br/servicos/travel-decision-layer/#implementation" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Arquitetura, implementação e alavancas em detalhe &rarr;</a>
<a href="/br/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Arquitetura Decision Layer &rarr;</a>
<a href="/br/servicos/infraestrutura/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infraestrutura em detalhe &rarr;</a>
<a href="/br/governance/co-determination/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Codecisão &amp; Participação dos Trabalhadores &rarr;</a>
<a href="/br/governance/cert-ready/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready by Design &rarr;</a>
</div>
</div>
</section>

<!-- Aprofundamento -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Aprofundamento no Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nossa série de artigos para executivos que implementam agentes de IA na empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/br/revista/decision-layer-explicado/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Fundamentos</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - O que é e por que todo agente AI enterprise precisa de um</p>
</a>
<a href="/br/revista/comite-empresa-ia-codecisao/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Codecisão</p>
<p class="text-body font-semibold text-gosign-dark">Comitê de Empresa e IA, Participação dos Trabalhadores como Constraint Arquitetônico</p>
</a>
<a href="/br/revista/cert-ready-by-design/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Auditoria</p>
<p class="text-body font-semibold text-gosign-dark">Cert-Ready by Design - IA pronta para auditoria desde o início</p>
</a>
</div>
</div>
</section>

<!-- Outros setores -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Travel Decision Layer em outros setores</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Cada setor tem suas próprias tarifas, estruturas de custos e fatores de complexidade. O Decision Layer é o mesmo. A configuração é setorial.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/br/servicos/travel-decision-layer/aviacao/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Aviação</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">Tripulação, IROP, convenções coletivas</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">95% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Em detalhe &rarr;</span>
</div>
</a>
<a href="/br/servicos/travel-decision-layer/consultoria/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Consultoria</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">Split de clientes, multi-centro de custos, política</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">85% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Em detalhe &rarr;</span>
</div>
</a>
<a href="/br/servicos/travel-decision-layer/vendas/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Vendas</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">500 equipe de campo, integração CRM, representação</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">90% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Em detalhe &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- AI Travel Agent Vendas - Força de vendas ---
> Decision Layer para despesas de viagem comerciais. Integração CRM, cumprimento de políticas em 10.000+ casos/mês, liquidação semanal.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/br/por-que-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Cada decisão rastreável</p>
</div>
</a>
<a href="/br/por-que-gosign/#infraestrutura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Sua infraestrutura</p>
<p class="text-xs text-gosign-text-light">Sem SaaS. Sem vendor lock-in.</p>
</div>
</a>
<a href="/br/por-que-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Sem risco de cloud americana</p>
</div>
</a>
</div>
</div>
</div>

<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Travel Decision Layer Setores">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/br/servicos/travel-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Travel Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/br/servicos/travel-decision-layer/aviacao/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Aviação</a>
<a href="/br/servicos/travel-decision-layer/consultoria/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Consultoria</a>
<a href="/br/servicos/travel-decision-layer/logistica/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Logística</a>
<a href="/br/servicos/travel-decision-layer/vendas/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Vendas</a>
</div>
</div>
</nav>

<!-- Por que volume de vendas precisa de governance -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<!-- Indicadores-chave como introdução visual -->
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">120.000+</span>
<p class="text-small text-gosign-text-light mt-1">Casos/ano (simulação)</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">90%</span>
<p class="text-small text-gosign-text-light mt-1">Taxa Zero-Touch</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">100%</span>
<p class="text-small text-gosign-text-light mt-1">Verificação de políticas (em vez de amostragem)</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-border"></span><span class="w-4 h-2 rounded-sm bg-gosign-border"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">Complexidade normativa média, alto volume</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">Casos e Zero-Touch: modelo de simulação Gosign. Verificação de políticas: o Decision Layer verifica 100% dos casos. Benchmarks setoriais: GBTA Foundation, 2015.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">O que o Agent classifica</p>
<h2 class="text-h1 font-bold text-gosign-dark">10.000 transações/mês, um Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Ferramentas de despesas são construídas para viagens de negócios ocasionais: um colaborador viaja, preenche um formulário, o gestor aprova. Na força de vendas, 500 colaboradores geram 20 casos por mês cada. O AI Agent verifica 100% dos casos em vez de amostragem.</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">100% verificação de política em vez de 5% amostragem</h3>
<p class="text-body text-gosign-text mt-2">Quando 500 representantes de campo submetem 20 relatórios por mês cada, auditoria por amostragem verifica 5 a 10 por cento. O AI Agent classifica cada transação por tipo e verifica contra o conjunto completo de regras de política. O motor de regras detecta desvios deterministicamente - 100% dos casos, não amostragem.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Vinculação CRM automática</h3>
<p class="text-body text-gosign-text mt-2">Cada visita a cliente tem um propósito comercial. O AI Agent vincula dados do CRM (Salesforce, TOTVS, SAP) com despesas de viagem automaticamente: qual cliente foi visitado, qual oportunidade, qual atribuição de receita. Sem entrada manual, sem propósito comercial faltando no Audit Trail.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Liquidação semanal em vez de transações individuais</h3>
<p class="text-body text-gosign-text mt-2">Representantes de campo preferem liquidação semanal. O AI Agent classifica e agrupa todas as viagens de uma semana por colaborador. O motor de regras calcula diárias e reembolso de quilometragem e gera uma única liquidação semanal - pronta para exportação para folha.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Custos de representação por jurisdição</h3>
<p class="text-body text-gosign-text mt-2">Representantes convidam clientes para refeições. O AI Agent classifica cada recibo de representação por tipo, valor e número de participantes. O motor de regras aplica a alíquota de dedução correta por jurisdição: no Brasil tratamento específico na legislação do IRPJ/CSLL (PT: IRC em Portugal), na Alemanha 70%, na Áustria 50%.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Fechamento trimestral em minutos</h3>
<p class="text-body text-gosign-text mt-2">Com 10.000 transações por mês processadas deterministicamente, o fechamento trimestral não é mais um projeto de pesquisa. O AI Agent tem cada caso documentado com dossiê de decisão completo. Exportação de auditoria é um clique - não semanas de reconstrução manual.</p>
</div>
</div>
</div>
</section>

<!-- Fluxo de Decisão -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Uma semana de vendas. De 30 a 80 micro-decisões.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Um representante de campo visita cinco clientes em uma semana com estadias em hotel e refeições de negócios. O Decision Layer decompõe essa semana em passos de decisão individuais:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Passo</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Decisão</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Decisor</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Justificativa</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Vincular viagem com oportunidade do CRM</td><td class="py-3 px-4">Motor de regras</td><td class="py-3 px-4">Cruzamento de dados de calendário e CRM</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Determinar diária</td><td class="py-3 px-4">Motor de regras</td><td class="py-3 px-4">Baseado em localização e duração</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Calcular reembolso de quilometragem</td><td class="py-3 px-4">Motor de regras</td><td class="py-3 px-4">Distância, tipo de veículo, taxa</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Verificar política de representação</td><td class="py-3 px-4">Motor de regras</td><td class="py-3 px-4">Valor, participantes, finalidade</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Verificar política de hotel</td><td class="py-3 px-4">Motor de regras</td><td class="py-3 px-4">Limite de preço por categoria de cidade</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Agrupar em liquidação semanal</td><td class="py-3 px-4">Automático</td><td class="py-3 px-4">Todas as viagens de uma semana agregadas</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Atribuir centro de custo e oportunidade</td><td class="py-3 px-4">Motor de regras</td><td class="py-3 px-4">Cliente, projeto, atribuição de receita</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">Gerar exportação para folha de pagamento</td><td class="py-3 px-4">Automático</td><td class="py-3 px-4">Liquidação semanal como lançamento</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Classificar despesas de representação</td><td class="py-3 px-4">AI + Motor de regras</td><td class="py-3 px-4">AI reconhece tipo de recibo e participantes, motor de regras aplica cotas de dedução</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Gerar dossiê de auditoria</td><td class="py-3 px-4">Automático</td><td class="py-3 px-4">Dossiê de decisões selado por semana de vendas</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Resultados da simulação -->
<section id="simulation" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulação</p>
<h2 class="text-h1 font-bold text-white">Calculado para volumes de vendas</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Configuramos o Travel Decision Layer com parâmetros realistas de vendas e calculamos os resultados. Os dados mostram o que muda com volumes Enterprise de força de vendas.</p>

<!-- Tabela de parâmetros -->
<h3 class="text-h3 font-bold text-white mt-10 mb-4">Parâmetros da simulação</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Representantes de campo</td><td class="py-3 px-4">200 a 2.000+ (por região e hierarquia)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Casos/mês</td><td class="py-3 px-4">10.000 a 50.000+</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Jurisdições</td><td class="py-3 px-4">Multi-jurisdição (BR, PT, UE, LATAM). LGPD (PT: RGPD) para proteção de dados.</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Integração de sistemas</td><td class="py-3 px-4">CRM &rarr; Decision Layer &rarr; ERP/Folha de pagamento</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Participação de representação</td><td class="py-3 px-4">20 - 30% de todos os casos contêm recibos de representação</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Políticas</td><td class="py-3 px-4">3 - 10 paralelas (por região, hierarquia, classe de cliente)</td></tr>
</tbody>
</table>
</div>

<!-- Comparação de resultados -->
<h3 class="text-h3 font-bold text-white mt-10 mb-4">Antes / Depois</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th class="text-left py-3 px-4 font-semibold text-white">Dimensão</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manual</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Custo de processamento</td><td class="py-3 px-4">a partir de EUR 53 / R$ 310 (base GBTA)*</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; EUR 7 (R$ 41)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Taxa de erro</td><td class="py-3 px-4">19% (GBTA)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 0,5%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Tempo de processamento</td><td class="py-3 px-4">5 - 12 dias úteis</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Minutos</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Taxa Zero-Touch</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">90%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Prontidão para auditoria</td><td class="py-3 px-4">Reconstruída manualmente</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Gerada automaticamente</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Verificação de políticas</td><td class="py-3 px-4">5 - 10% (amostragem)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">100%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Liquidação semanal</td><td class="py-3 px-4">Compilada manualmente</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Agregada automaticamente</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">* GBTA Foundation 2024: USD 58 por transação (aprox. EUR 53 / R$ 310). Valores em BRL são aproximados. Casos de vendas com integração CRM e agrupamento semanal são significativamente mais econômicos no modo Zero-Touch. Resultados da simulação: modelo de cálculo Gosign.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">Na simulação, o Decision Layer alcança uma taxa Zero-Touch de 90% - em casos padrão com vinculação CRM inequívoca. Os 10% restantes referem-se a casos especiais de representação e entradas CRM faltantes que exigem julgamento humano. Para todos os casos existe um dossiê de decisões completo e pronto para auditoria. As liquidações semanais substituem o ciclo de liquidação individual.</p>
</div>
</section>

<!-- Referência de arquitetura -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Arquitetura e implementação</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">O Travel Decision Layer funciona completamente na sua infraestrutura: seu data center, sua rede, sua soberania. Sem dependência SaaS, sem vazamento de dados. Para configurações de vendas, isso significa: interfaces CRM para vinculação automática viagem-cliente, processamento em volume de mais de 10.000 transações por mês e lógica de liquidação semanal. Projetos piloto típicos começam em 3 meses com uma região de vendas.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/br/servicos/travel-decision-layer/#implementation" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Arquitetura, implementação e alavancas em detalhe &rarr;</a>
<a href="/br/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Arquitetura do Decision Layer &rarr;</a>
<a href="/br/servicos/infraestrutura/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infraestrutura em detalhe &rarr;</a>
<a href="/br/governance/co-determination/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Codeterminação &amp; Sindicato &rarr;</a>
<a href="/br/governance/cert-ready/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready by Design &rarr;</a>
</div>
</div>
</section>

<!-- Aprofundamento -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Aprofundamento no Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nossa série de artigos para executivos que implementam agentes de IA na empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/br/revista/decision-layer-explicado/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Fundamentos</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - O que é e por que todo agente AI enterprise precisa de um</p>
</a>
<a href="/br/revista/agent-governance-hr/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governança</p>
<p class="text-body font-semibold text-gosign-dark">Agent Governance no RH - Por que o CHRO precisa liderar</p>
</a>
<a href="/br/revista/eu-ai-act-hr/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Regulamentação</p>
<p class="text-body font-semibold text-gosign-dark">EU AI Act e RH - O que agora é obrigatório</p>
</a>
</div>
</div>
</section>

<!-- Outros setores -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Travel Decision Layer em outros setores</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Cada setor tem suas próprias tarifas, estruturas de custos e fatores de complexidade. O Decision Layer é o mesmo. A configuração é setorial.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/br/servicos/travel-decision-layer/aviacao/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Aviação</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">Tripulação, IROP, convenções coletivas</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">95% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Em detalhe &rarr;</span>
</div>
</a>
<a href="/br/servicos/travel-decision-layer/consultoria/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Consultoria</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">Split de clientes, multi-centro de custos, política</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">85% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Em detalhe &rarr;</span>
</div>
</a>
<a href="/br/servicos/travel-decision-layer/logistica/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Logística</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">GPS, regulamentação ANTT/Mercosul (PT: Pacote de Mobilidade UE), Zero-Touch motoristas</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">95% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Em detalhe &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- AI Travel Decision Layer - Despesas de viagem ---
> O Decision Layer decompõe cada despesa de viagem em passos de decisão. Baseado em regras, auditável, 85-95% Zero-Touch em quatro setores.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/br/por-que-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div><p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p><p class="text-xs text-gosign-text-light">Cada decisão rastreável</p></div>
</a>
<a href="/br/por-que-gosign/#infraestrutura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div><p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Sua infraestrutura</p><p class="text-xs text-gosign-text-light">Sem SaaS. Sem vendor lock-in.</p></div>
</a>
<a href="/br/por-que-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div><p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p><p class="text-xs text-gosign-text-light">Sem risco de cloud americana</p></div>
</a>
</div>
</div>
</div>

<!-- Problema -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div><span class="text-h1 font-bold text-gosign-accent-text">EUR 53 (R$ 310)</span><p class="text-small text-gosign-text-light mt-1">por caso, processamento manual</p></div>
<div><span class="text-h1 font-bold text-gosign-accent-text">19%</span><p class="text-small text-gosign-text-light mt-1">taxa de erro em relatórios de despesas de viagem</p></div>
<div><span class="text-h1 font-bold text-gosign-accent-text">EUR 48 (R$ 280)</span><p class="text-small text-gosign-text-light mt-1">custo de correção por erro</p></div>
<p class="sm:col-span-3 text-xs text-gosign-text-light">GBTA Foundation 2024: USD 58 por transação (aprox. EUR 53 / R$ 310). Valores em BRL são aproximados.</p>
</div>
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">O Problema</p>
<h2 class="text-h1 font-bold text-gosign-dark">Por que ferramentas de despesas falham em organizações complexas</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">SAP Concur, Circula, Moss, Spendesk. Todas digitalizam o mesmo processo manual: capturar recibos, preencher formulários, obter aprovações. Com EUR 53 (R$ 310) por caso e 19% de taxa de erro segundo a GBTA, isso é caro. Mas em organizações com convenções coletivas, equipes internacionais e dezenas de jurisdições tributárias, a captura não é o problema. O problema é a decisão.</p>
<div class="mt-10">
<div class="grid grid-cols-1 md:grid-cols-3 gap-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-h3 font-bold text-gosign-dark">EUR 53 (R$ 310) por caso</h3><p class="text-body text-gosign-text-light mt-2">Ferramentas de despesas digitalizam formulários em papel. O colaborador preenche, o gestor aprova, a contabilidade revisa. Três passos manuais, EUR 53 (R$ 310) cada (GBTA). Com 100.000 casos por ano, são EUR 5,3 milhões (R$ 31 milhões) apenas em custos de processamento.</p></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-h3 font-bold text-gosign-dark">19% taxa de erro</h3><p class="text-body text-gosign-text-light mt-2">Diárias por país, regras de lançamento contábil, deduções por refeição, overrides de convenções coletivas, limites de isenção tributária. Nenhum colaborador conhece todas as regras. Nenhum aprovador as verifica. Resultado: um em cada cinco casos está incorreto. EUR 48 (R$ 280) de custo de correção por erro (GBTA).</p></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-h3 font-bold text-gosign-dark">Zero preparação para auditoria</h3><p class="text-body text-gosign-text-light mt-2">Quando chega a fiscalização da Receita Federal, falta a evidência: qual regra foi aplicada? Por que esta diária? A dedução estava correta? Ferramentas de despesas documentam o que foi submetido. Não por que foi decidido assim. (PT: Inspeções da AT exigem o mesmo nível de rastreabilidade.)</p></div>
</div>
</div>
</div>
</section>

<!-- Decision Layer -->
<section id="decision-layer" class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">O Decision Layer</p>
<h2 class="text-h1 font-bold text-gosign-dark">Cada caso. Decomposto em passos de decisão.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">O Travel Decision Layer funciona como todo Gosign Decision Layer: decompõe um processo em passos de decisão individuais e define para cada passo quem ou o que decide. Motor de regras, convenção coletiva ou pessoa. Não tudo de uma vez, mas passo a passo, documentado e rastreável.</p>
<div class="mt-10"><img src="/images/diagrams/travel-decision-flow-v2-br.svg" alt="Fluxo de decisão do Travel Decision Layer: entrada de dados, extração por AI, Decision Layer, resultado" width="1000" height="280" class="w-full" /></div>
<p class="text-body text-gosign-text mt-8 max-w-narrow font-semibold">AI extrai e classifica. O Decision Layer decide. Essa separação é o motivo pelo qual o sistema é auditável, compatível com LGPD (PT: RGPD) e pronto para fiscalização.</p>
<div class="mt-10">
<div class="grid grid-cols-1 md:grid-cols-2 gap-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-h3 font-bold text-gosign-dark">Mesmo input, mesmo resultado</h3><p class="text-body text-gosign-text-light mt-2">Tabelas de decisão são versionadas. Cada caso é verificado contra uma versão definida de regras. Sem resultados estocásticos, sem output de LLM para valores ou tratamento tributário.</p></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-h3 font-bold text-gosign-dark">40 a 120 decisões individuais por caso</h3><p class="text-body text-gosign-text-light mt-2">Não uma grande decisão 'aprovado / rejeitado', mas dezenas de pequenas: qual diária? Qual dedução? Qual convenção coletiva? Parcela isenta? Cada uma documentada individualmente.</p></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-h3 font-bold text-gosign-dark">Motor de regras, convenção coletiva ou pessoa</h3><p class="text-body text-gosign-text-light mt-2">O Decision Layer não decide tudo sozinho. Sabe quais passos o motor de regras cobre, quais são definidos por convenções coletivas e onde uma pessoa deve intervir. Resultado: apenas exceções genuínas precisam de atenção humana.</p></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-h3 font-bold text-gosign-dark">O colaborador não confirma. Pode contestar.</h3><p class="text-body text-gosign-text-light mt-2">Ferramentas tradicionais pedem ao colaborador para confirmar seu próprio relatório de despesas. O Decision Layer inverte isso: o processamento acontece automaticamente. O colaborador é informado e tem direito de veto.</p></div>
</div>
</div>
</div>
</section>

<!-- Governance e Auditoria -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<h2 class="text-h1 font-bold text-gosign-dark">Não documentado retroativamente. Gerado no processo.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Quando o fiscal da Receita Federal pergunta "Por que foram lançados R$ 280 em vez de R$ 140?" - responder "o sistema calculou" não basta. O Travel Decision Layer gera para cada microdecisão um ato de decisão que responde exatamente essa pergunta: qual regra com versão, qual input, qual resultado, quando, por quem - incluindo o caminho de contestação. Com isso, a revisão da decisão individual - nos termos da LGPD art. 20 (e do art. 86 do EU AI Act em negócios na UE) - vira uma consulta, não um projeto forense. (PT: Inspeções da AT exigem o mesmo nível de rastreabilidade para despesas corporativas.)</p>
<div class="mt-10 bg-gosign-dark rounded-card p-6 sm:p-8">
<div class="flex items-start gap-4 mb-6">
<svg class="w-8 h-8 text-gosign-accent-on-dark flex-shrink-0" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12h6m-6 4h6m2 5H7a2 2 0 01-2-2V5a2 2 0 012-2h5.586a1 1 0 01.707.293l5.414 5.414a1 1 0 01.293.707V19a2 2 0 01-2 2z" /></svg>
<div><h3 class="text-h3 font-bold text-white">Cada microdecisão gera um registro de auditoria</h3><p class="text-small text-gosign-text-on-dark/70 mt-1">Append-only. Nada é sobrescrito, nada é excluído. Em correções, lançamentos de estorno e ajuste são criados. Assinado com SHA-256, exportável a qualquer momento.</p></div>
</div>
<div class="grid grid-cols-2 sm:grid-cols-3 gap-3 sm:gap-4">
<div class="flex items-center gap-2.5"><svg class="w-4 h-4 text-gosign-accent-on-dark flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg><span class="text-small text-gosign-text-on-dark/80">ID da regra + versão da regra</span></div>
<div class="flex items-center gap-2.5"><svg class="w-4 h-4 text-gosign-accent-on-dark flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg><span class="text-small text-gosign-text-on-dark/80">Dados de entrada (o que estava disponível?)</span></div>
<div class="flex items-center gap-2.5"><svg class="w-4 h-4 text-gosign-accent-on-dark flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg><span class="text-small text-gosign-text-on-dark/80">Resultado (o que foi decidido?)</span></div>
<div class="flex items-center gap-2.5"><svg class="w-4 h-4 text-gosign-accent-on-dark flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg><span class="text-small text-gosign-text-on-dark/80">Carimbo de data/hora</span></div>
<div class="flex items-center gap-2.5"><svg class="w-4 h-4 text-gosign-accent-on-dark flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg><span class="text-small text-gosign-text-on-dark/80">Ator (motor de regras / convenção / pessoa)</span></div>
<div class="flex items-center gap-2.5"><svg class="w-4 h-4 text-gosign-accent-on-dark flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg><span class="text-small text-gosign-text-on-dark/80">Hash do input (reproduzível)</span></div>
</div>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8">
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6"><div class="flex items-start gap-3"><svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M15 12a3 3 0 11-6 0 3 3 0 016 0z" /><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M2.458 12C3.732 7.943 7.523 5 12 5c4.478 0 8.268 2.943 9.542 7-1.274 4.057-5.064 7-9.542 7-4.477 0-8.268-2.943-9.542-7z" /></svg><div><h3 class="text-body font-semibold text-gosign-dark">Transparente para sindicatos (PT: Comissão de Trabalhadores)</h3><p class="text-small text-gosign-text-light mt-2">Regras acessíveis. Decisões rastreáveis. Pontuação de anomalias controlável por Feature Flag. Relatórios pseudonimizados. Compliance e performance arquitetonicamente separados.</p><a href="/br/governance/co-determination/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Participação dos trabalhadores &rarr;</a></div></div></div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6"><div class="flex items-start gap-3"><svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12l2 2 4-4m5.618-4.016A11.955 11.955 0 0112 2.944a11.955 11.955 0 01-8.618 3.04A12.02 12.02 0 003 9c0 5.591 3.824 10.29 9 11.622 5.176-1.332 9-6.03 9-11.622 0-1.042-.133-2.052-.382-3.016z" /></svg><div><h3 class="text-body font-semibold text-gosign-dark">Pronto para fiscalização</h3><p class="text-small text-gosign-text-light mt-2">Prazos de retenção suportados conforme legislação tributária brasileira. Anonimização em vez de exclusão para compatibilidade com LGPD. Cada caso reproduzível via hash do input. (PT: Compatível com prazos de retenção fiscal portuguesa e RGPD Art. 17.)</p><a href="/br/governance/cert-ready/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready &rarr;</a></div></div></div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6"><div class="flex items-start gap-3"><svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 5H7a2 2 0 00-2 2v12a2 2 0 002 2h10a2 2 0 002-2V7a2 2 0 00-2-2h-2M9 5a2 2 0 002 2h2a2 2 0 002-2M9 5a2 2 0 012-2h2a2 2 0 012 2m-6 9l2 2 4-4" /></svg><div><h3 class="text-body font-semibold text-gosign-dark">Compliance sistemática</h3><p class="text-small text-gosign-text-light mt-2">Sem relatório trimestral, sem auditoria por amostragem. Cada caso individual é verificado contra o motor de regras. Desvios são detectados e documentados imediatamente.</p></div></div></div>
</div>
</div>
</section>

<!-- Tabela comparativa -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="overflow-x-auto">
<table class="w-full text-small border-collapse">
<thead><tr class="border-b-2 border-gosign-border"><th class="text-left py-3 px-4 font-semibold text-gosign-dark">Dimensão</th><th class="text-left py-3 px-4 font-semibold text-gosign-dark">Ferramenta de despesas tradicional</th><th class="text-left py-3 px-4 font-semibold text-gosign-accent-text">Travel Decision Layer</th></tr></thead>
<tbody>
<tr class="border-b border-gosign-border"><td class="py-3 px-4 font-medium text-gosign-dark">Modelo de decisão</td><td class="py-3 px-4 text-gosign-text-light">Pessoa preenche, gestor aprova</td><td class="py-3 px-4 text-gosign-accent-text font-semibold">Decision Layer aplica regras, pessoa tem veto</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4 font-medium text-gosign-dark">Complexidade normativa</td><td class="py-3 px-4 text-gosign-text-light">Políticas básicas, sem lógica de convenção coletiva</td><td class="py-3 px-4 text-gosign-accent-text font-semibold">Tabelas de decisão versionadas: legislação tributária, diárias, convenções coletivas</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4 font-medium text-gosign-dark">Audit Trail</td><td class="py-3 px-4 text-gosign-text-light">Recibo armazenado, decisão não documentada</td><td class="py-3 px-4 text-gosign-accent-text font-semibold">Cada microdecisão documentada: regra, input, resultado, carimbo de data/hora</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4 font-medium text-gosign-dark">Fiscalização</td><td class="py-3 px-4 text-gosign-text-light">Reconstrução manual a partir de arquivos</td><td class="py-3 px-4 text-gosign-accent-text font-semibold">Exportação: dossiê de auditoria selado por caso, reproduzível via hash do input</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4 font-medium text-gosign-dark">Experiência do colaborador</td><td class="py-3 px-4 text-gosign-text-light">Formulário, upload, aguardar aprovação</td><td class="py-3 px-4 text-gosign-accent-text font-semibold">Processamento automático, notificação, opção de veto</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4 font-medium text-gosign-dark">Escalabilidade</td><td class="py-3 px-4 text-gosign-text-light">Linear: mais casos = mais revisores</td><td class="py-3 px-4 text-gosign-accent-text font-semibold">Constante: 100 ou 100.000 casos, mesmo motor de regras</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4 font-medium text-gosign-dark">Representação dos trabalhadores</td><td class="py-3 px-4 text-gosign-text-light">Intransparente, difícil de auditar</td><td class="py-3 px-4 text-gosign-accent-text font-semibold">Motor de regras transparente, pontuação de anomalias por Feature Flag, relatórios pseudonimizados</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Simulações setoriais -->
<section id="simulacoes" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulado para volumes enterprise</p>
<h2 class="text-h1 font-bold text-white">Quatro setores. Calculados.</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Configuramos o Travel Decision Layer para quatro setores com volumes realistas e calculamos os resultados. Cada cartão mostra os parâmetros da simulação e o resultado.</p>
<div class="grid grid-cols-1 md:grid-cols-2 gap-6 mt-10">
<a href="/br/servicos/travel-decision-layer/aviacao/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors"><div class="flex items-center justify-between mb-4"><h3 class="text-h3 font-bold text-white">Aviação</h3><div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div></div><ul class="space-y-1.5 text-small text-gosign-text-on-dark/70"><li>Dezenas de milhares de tripulantes, múltiplos grupos de pessoal</li><li>Múltiplas convenções coletivas paralelas por companhia aérea</li><li>100.000 a 1.000.000+ casos/ano</li><li>Multi-companhia, multi-jurisdição</li></ul><div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between"><span class="text-h3 font-bold text-gosign-accent-on-dark">95% Zero-Touch</span><span class="text-small text-gosign-accent-on-dark font-semibold">Aviação em detalhe &rarr;</span></div></a>
<a href="/br/servicos/travel-decision-layer/consultoria/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors"><div class="flex items-center justify-between mb-4"><h3 class="text-h3 font-bold text-white">Consultoria</h3><div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-white/20"></span></div></div><ul class="space-y-1.5 text-small text-gosign-text-on-dark/70"><li>8.000+ consultores, 15+ jurisdições</li><li>Split de três vias: tributário / cliente / interno</li><li>Semanas com múltiplos clientes, centros de custo que mudam diariamente</li></ul><div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between"><span class="text-h3 font-bold text-gosign-accent-on-dark">85% Zero-Touch</span><span class="text-small text-gosign-accent-on-dark font-semibold">Consultoria em detalhe &rarr;</span></div></a>
<a href="/br/servicos/travel-decision-layer/logistica/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors"><div class="flex items-center justify-between mb-4"><h3 class="text-h3 font-bold text-white">Logística</h3><div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-white/20"></span></div></div><ul class="space-y-1.5 text-small text-gosign-text-on-dark/70"><li>20.000+ motoristas, conformidade regulatória</li><li>Detecção de país baseada em GPS</li><li>Diárias de motoristas baseadas em frota</li></ul><div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between"><span class="text-h3 font-bold text-gosign-accent-on-dark">95% Zero-Touch</span><span class="text-small text-gosign-accent-on-dark font-semibold">Logística em detalhe &rarr;</span></div></a>
<a href="/br/servicos/travel-decision-layer/vendas/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors"><div class="flex items-center justify-between mb-4"><h3 class="text-h3 font-bold text-white">Vendas</h3><div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-white/20"></span><span class="w-3 h-1.5 rounded-sm bg-white/20"></span></div></div><ul class="space-y-1.5 text-small text-gosign-text-on-dark/70"><li>5.000+ equipe de campo, integração CRM</li><li>10.000+ casos por mês</li><li>Aplicação de políticas em volume</li></ul><div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between"><span class="text-h3 font-bold text-gosign-accent-on-dark">90% Zero-Touch</span><span class="text-small text-gosign-accent-on-dark font-semibold">Vendas em detalhe &rarr;</span></div></a>
</div>
</div>
</section>

<!-- Implementação -->
<section id="implementation" class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Implementação</p>
<h2 class="text-h1 font-bold text-gosign-dark">Do piloto ao sistema em operação.</h2>
<div class="grid grid-cols-1 lg:grid-cols-2 gap-10 mt-10">
<div><h3 class="text-h3 font-bold text-gosign-dark mb-3">Arquitetura técnica</h3><p class="text-body text-gosign-text">O Travel Decision Layer roda completamente na sua infraestrutura: seu centro de dados, sua rede, seu controle. Sem dependência SaaS, sem vazamento de dados, sem rastreamento telemétrico externo. Containerizado, multi-tenant, pronto para deploy na sua Private Cloud ou como deploy gerenciado em centros de dados na UE.</p><div class="flex flex-wrap gap-4 mt-3"><a href="/br/servicos/infraestrutura/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infraestrutura em detalhe &rarr;</a><a href="/br/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Arquitetura do Decision Layer &rarr;</a></div></div>
<div><h3 class="text-h3 font-bold text-gosign-dark mb-3">Implementação</h3><p class="text-body text-gosign-text">O Decision Layer não é instalado, é configurado: suas convenções coletivas, suas políticas, seu ecossistema de sistemas. Projetos piloto típicos iniciam em 3 meses com um setor e uma convenção coletiva. Extensões para outros grupos de pessoal ou conexões de sistemas rodam em paralelo com o piloto.</p></div>
</div>
<h3 class="text-h3 font-bold text-gosign-dark mt-12 mb-6">Alavanca econômica</h3>
<div class="grid grid-cols-1 sm:grid-cols-2 gap-6">
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6"><div class="flex items-start gap-4"><svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12l2 2 4-4m5.618-4.016A11.955 11.955 0 0112 2.944a11.955 11.955 0 01-8.618 3.04A12.02 12.02 0 003 9c0 5.591 3.824 10.29 9 11.622 5.176-1.332 9-6.03 9-11.622 0-1.042-.133-2.052-.382-3.016z" /></svg><div><p class="text-body font-semibold text-gosign-dark">Verificação sistemática de regras em vez de amostragem</p><p class="text-small text-gosign-text-light mt-2">Cada caso passa pelo mesmo motor de regras. Desvios são detectados e documentados, não descobertos na reconciliação trimestral.</p></div></div></div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6"><div class="flex items-start gap-4"><svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M13 10V3L4 14h7v7l9-11h-7z" /></svg><div><p class="text-body font-semibold text-gosign-dark">Sem workflows de aprovação para casos padrão</p><p class="text-small text-gosign-text-light mt-2">Tempo de processamento de dias para minutos. Gestores aprovam apenas exceções.</p></div></div></div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6"><div class="flex items-start gap-4"><svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M4 6a2 2 0 012-2h2a2 2 0 012 2v2a2 2 0 01-2 2H6a2 2 0 01-2-2V6zm10 0a2 2 0 012-2h2a2 2 0 012 2v2a2 2 0 01-2 2h-2a2 2 0 01-2-2V6zM4 16a2 2 0 012-2h2a2 2 0 012 2v2a2 2 0 01-2 2H6a2 2 0 01-2-2v-2zm10 0a2 2 0 012-2h2a2 2 0 012 2v2a2 2 0 01-2 2h-2a2 2 0 01-2-2v-2z" /></svg><div><p class="text-body font-semibold text-gosign-dark">Atribuição automática de centros de custo e projetos</p><p class="text-small text-gosign-text-light mt-2">Sem mapeamento manual para milhares de casos. Sem gargalo no fechamento mensal.</p></div></div></div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6"><div class="flex items-start gap-4"><svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12h6m-6 4h6m2 5H7a2 2 0 01-2-2V5a2 2 0 012-2h5.586a1 1 0 01.707.293l5.414 5.414a1 1 0 01.293.707V19a2 2 0 01-2 2z" /></svg><div><p class="text-body font-semibold text-gosign-dark">Dossiês de decisão prontos para fiscalização gerados no processo</p><p class="text-small text-gosign-text-light mt-2">Fiscalização é uma exportação, não um projeto de pesquisa. Semanas viram minutos.</p></div></div></div>
</div>
</div>
</section>

<!-- Segurança -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Segurança</p>
<h2 class="text-h1 font-bold text-gosign-dark">Segurança Enterprise. Desde o dia um.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Não adicionada como feature depois, mas construída como princípio de arquitetura. O Travel Decision Layer é projetado para ambientes regulados onde proteção de dados, audit-readiness e rastreabilidade não são extras opcionais.</p>
<div class="mt-10">
<div class="grid grid-cols-1 md:grid-cols-3 gap-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-h3 font-bold text-gosign-dark">100% infraestrutura do cliente</h3><p class="text-body text-gosign-text-light mt-2">O Decision Layer roda completamente na sua rede. Sem dependência SaaS, sem vazamento de dados, sem rastreamento telemétrico externo. Secrets no seu KMS, logs no seu SIEM, SSO via seu provedor de identidade. Compatível com exigências de transferência internacional de dados da LGPD (Art. 33-36). (PT: Compatível com RGPD e regulamentação da CNPD.)</p></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-h3 font-bold text-gosign-dark">LGPD by Design</h3><p class="text-body text-gosign-text-light mt-2">Anonimização em vez de exclusão. Compatível com prazos de retenção tributária e LGPD Art. 16. Sem conflito entre legislação tributária e proteção de dados. (PT: RGPD Art. 17 e obrigações de retenção fiscal portuguesa.)</p><a href="/br/governance/data-residency/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover mt-3 inline-block whitespace-nowrap">Residência de dados em detalhe</a></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-h3 font-bold text-gosign-dark">Compatível com AI Act</h3><p class="text-body text-gosign-text-light mt-2">Separação clara de arquitetura: LLM para extração de dados, Decision Layer para decisões. Sem caixa-preta sobre questões tributárias. Cada decisão reconstruível. EU AI Act diretamente aplicável em Portugal; no Brasil, o PL 2338/2023 prevê regulamentação equivalente.</p><a href="/br/governance/eu-ai-act/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover mt-3 inline-block whitespace-nowrap">AI Act Readiness</a></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-h3 font-bold text-gosign-dark">Audit Trail (append-only)</h3><p class="text-body text-gosign-text-light mt-2">Dossiês de decisão assinados. Hash do input mais versão da regra resulta em resultado reproduzível. Pacotes de auditoria selados (JSON + PDF, SHA-256). Fiscalização a qualquer momento.</p></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-h3 font-bold text-gosign-dark">ISO 27001 / SOC 2 cert-ready</h3><p class="text-body text-gosign-text-light mt-2">Registro de controles integrado, execuções de evidência automatizadas, políticas versionadas. Compliance em operação contínua, não documentado retrospectivamente.</p><a href="/br/governance/cert-ready/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover mt-3 inline-block whitespace-nowrap">Cert-Ready by Design</a></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-h3 font-bold text-gosign-dark">SSO e separação multi-tenant</h3><p class="text-body text-gosign-text-light mt-2">Integração com provedores de identidade existentes. Separação multi-tenant em nível de banco de dados (Row Level Security). Modelo de permissões granularmente configurável.</p></div>
</div>
</div>
</div>
</section>

<!-- Aprofundamento -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Aprofundamento no Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nossa série de artigos para executivos que implementam agentes de IA na empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/br/revista/decision-layer-explicado/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors"><p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Fundamentos</p><p class="text-body font-semibold text-gosign-dark">Decision Layer - O que é e por que todo agente AI enterprise precisa de um</p></a>
<a href="/br/revista/comite-empresa-ia-codecisao/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors"><p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Participação</p><p class="text-body font-semibold text-gosign-dark">Comitê de Empresa e IA - Participação dos Trabalhadores como Constraint Arquitetônico</p></a>
<a href="/br/revista/cert-ready-by-design/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors"><p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Auditoria</p><p class="text-body font-semibold text-gosign-dark">Cert-Ready by Design - IA pronta para auditoria desde o início</p></a>
<a href="/br/revista/ato-de-decisao-decisoes-ia-contestaveis/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors"><p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p><p class="text-body font-semibold text-gosign-dark">O ato de decisão - por que toda decisão de IA deve ser contestável</p></a>
</div>
</div>
</section>

--- Serviços ---
> AI Agents, Finance Agents, HR Agents, Infraestrutura de IA, Document Intelligence e assinaturas digitais eIDAS.

<!-- O Que Construímos -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">O Que Construímos</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
A Gosign desenvolve e opera infraestrutura de AI Agents para empresas. Construímos a camada entre modelo de linguagem e sistema empresarial - incluindo orquestração, governança e auditoria.
</p>
</div>
</div>
</section>

<!-- Service Cards -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-1 lg:grid-cols-3 gap-6 lg:gap-8">
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9.813 15.904L9 18.75l-.813-2.846a4.5 4.5 0 00-3.09-3.09L2.25 12l2.846-.813a4.5 4.5 0 003.09-3.09L9 5.25l.813 2.846a4.5 4.5 0 003.09 3.09L15.75 12l-2.846.813a4.5 4.5 0 00-3.09 3.09zM18.259 8.715L18 9.75l-.259-1.035a3.375 3.375 0 00-2.455-2.456L14.25 6l1.036-.259a3.375 3.375 0 002.455-2.456L18 2.25l.259 1.035a3.375 3.375 0 002.455 2.456L21.75 6l-1.036.259a3.375 3.375 0 00-2.455 2.456zM16.894 20.567L16.5 21.75l-.394-1.183a2.25 2.25 0 00-1.423-1.423L13.5 18.75l1.183-.394a2.25 2.25 0 001.423-1.423l.394-1.183.394 1.183a2.25 2.25 0 001.423 1.423l1.183.394-1.183.394a2.25 2.25 0 00-1.423 1.423z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">AI Agents</h3>
<p class="text-body text-gosign-text-light mt-3">Document Agents, Workflow Agents, Knowledge Agents. AI Agents especializados que leem documentos, orquestram processos e fornecem respostas contextuais. Cada agente opera dentro de um Decision Layer.</p>
<a href="/br/servicos/ai-agents/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">AI Agents em detalhe<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg></a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 18.75a60.07 60.07 0 0115.797 2.101c.727.198 1.453-.342 1.453-1.096V18.75M3.75 4.5v.75A.75.75 0 013 6h-.75m0 0v-.375c0-.621.504-1.125 1.125-1.125H20.25M2.25 6v9m18-10.5v.75c0 .414.336.75.75.75h.75m-1.5-1.5h.375c.621 0 1.125.504 1.125 1.125v9.75c0 .621-.504 1.125-1.125 1.125h-.375m1.5-1.5H21a.75.75 0 00-.75.75v.75m0 0H3.75m0 0h-.375a1.125 1.125 0 01-1.125-1.125V15m1.5 1.5v-.75A.75.75 0 003 15h-.75M15 10.5a3 3 0 11-6 0 3 3 0 016 0zm3 0h.008v.008H18V10.5zm-12 0h.008v.008H6V10.5z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Finance Agents</h3>
<p class="text-body text-gosign-text-light mt-3">Decision Automation para processamento de documentos e contabilidade. Conjuntos de regras versionados. Cert-Ready by Design. Integração TOTVS e SAP.</p>
<a href="/br/servicos/agente-financeiro/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">Finance Agents<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg></a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M15 19.128a9.38 9.38 0 002.625.372 9.337 9.337 0 004.121-.952 4.125 4.125 0 00-7.533-2.493M15 19.128v-.003c0-1.113-.285-2.16-.786-3.07M15 19.128v.106A12.318 12.318 0 018.624 21c-2.331 0-4.512-.645-6.374-1.766l-.001-.109a6.375 6.375 0 0111.964-3.07M12 6.375a3.375 3.375 0 11-6.75 0 3.375 3.375 0 016.75 0zm8.25 2.25a2.625 2.625 0 11-5.25 0 2.625 2.625 0 015.25 0z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">HR Agents</h3>
<p class="text-body text-gosign-text-light mt-3">AI Agents empresariais para decisões de RH consistentes, rastreáveis e com prova de auditoria. Compatível com sindicatos e comissões de representação dos empregados (CRE (PT: Comissão de Trabalhadores)). Decision Layer com Human-in-the-Loop.</p>
<a href="/br/hr-ai-agents/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">HR Agents<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg></a>
</article>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-1 lg:grid-cols-3 gap-6 lg:gap-8">
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M5.25 14.25h13.5m-13.5 0a3 3 0 01-3-3m3 3a3 3 0 100 6h13.5a3 3 0 100-6m-16.5-3a3 3 0 013-3h13.5a3 3 0 013 3m-19.5 0a4.5 4.5 0 01.9-2.7L5.737 5.1a3.375 3.375 0 012.7-1.35h7.126c1.062 0 2.062.5 2.7 1.35l2.587 3.45a4.5 4.5 0 01.9 2.7m0 0a3 3 0 01-3 3m0 3h.008v.008h-.008v-.008zm0-6h.008v.008h-.008v-.008zm-3 6h.008v.008h-.008v-.008zm0-6h.008v.008h-.008v-.008z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">AI Infrastructure</h3>
<p class="text-body text-gosign-text-light mt-3">LLM Hosting, RAG, Orquestração, Self-Hosted. A infraestrutura sobre a qual AI Agents funcionam em produção. Agnóstica, flexível, preparada para governança.</p>
<a href="/br/servicos/infraestrutura/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">AI Infrastructure<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg></a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M19.5 14.25v-2.625a3.375 3.375 0 00-3.375-3.375h-1.5A1.125 1.125 0 0113.5 7.125v-1.5a3.375 3.375 0 00-3.375-3.375H8.25m0 12.75h7.5m-7.5 3H12M10.5 2.25H5.625c-.621 0-1.125.504-1.125 1.125v17.25c0 .621.504 1.125 1.125 1.125h12.75c.621 0 1.125-.504 1.125-1.125V11.25a9 9 0 00-9-9z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Document Intelligence</h3>
<p class="text-body text-gosign-text-light mt-3">Compreensão de documentos além do OCR. Classificação, extração, validação - impulsionado por LLM, governado pelo Decision Layer. Para faturas, contratos, certificados e documentos não estruturados.</p>
<a href="/br/servicos/document-intelligence/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">Document Intelligence<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg></a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 6.75V15m6-6v8.25m.503 3.498l4.875-2.437c.381-.19.622-.58.622-1.006V4.82c0-.836-.88-1.38-1.628-1.006l-3.869 1.934c-.317.159-.69.159-1.006 0L9.503 3.252a1.125 1.125 0 00-1.006 0L3.622 5.689C3.24 5.88 3 6.27 3 6.695V19.18c0 .836.88 1.38 1.628 1.006l3.869-1.934c.317-.159.69-.159 1.006 0l4.994 2.497c.317.158.69.158 1.006 0z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Travel Decision Layer</h3>
<p class="text-body text-gosign-text-light mt-3">Governance de despesas de viagem impulsionada por AI. O Decision Layer decompõe cada caso de despesas de viagem em passos de decisão e aplica normas tributárias, diárias e convenções coletivas deterministicamente. Configurável para aviação, consultoria, logística e vendas.</p>
<a href="/br/servicos/travel-decision-layer/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">Travel Decision Layer<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg></a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M17.25 6.75L22.5 12l-5.25 5.25m-10.5 0L1.5 12l5.25-5.25m7.5-3l-4.5 16.5" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Engenharia de Software Empresarial</h3>
<p class="text-body text-gosign-text-light mt-3">Desde 2001. Mais de 5.000 projetos. 25 anos de desenvolvimento de software empresarial para Airbus, Volkswagen, Shell. TDD, pair programming contínuo, CI/CD, Security by Design.</p>
<a href="/br/servicos/software-engineering/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">Engenharia de Software<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg></a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M16.5 10.5V6.75a4.5 4.5 0 10-9 0v3.75m-.75 11.25h10.5a2.25 2.25 0 002.25-2.25v-6.75a2.25 2.25 0 00-2.25-2.25H6.75a2.25 2.25 0 00-2.25 2.25v6.75a2.25 2.25 0 002.25 2.25z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Assinaturas Digitais eIDAS</h3>
<p class="text-body text-gosign-text-light mt-3">Em cooperação com parceiros certificados ETSI. Soluções de assinatura digital conformes com eIDAS. Simples, avançadas e qualificadas.</p>
<a href="/br/servicos/eidas-signatures/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">Assinaturas eIDAS<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg></a>
</article>
</div>
</div>
</section>

<!-- How We Work -->

<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark text-center">Como Trabalhamos</h2>
<div class="mt-12 grid grid-cols-1 md:grid-cols-3 gap-8 relative">
<div class="text-center">
<div class="w-14 h-14 mx-auto rounded-full bg-gosign-accent flex items-center justify-center">
<span class="text-h3 font-bold text-white">1</span>
</div>
<h3 class="text-h3 font-bold text-gosign-dark mt-4">Discover</h3>
<p class="text-small font-semibold text-gosign-accent-text mt-1">1 semana</p>
<p class="text-body text-gosign-text-light mt-2">Análise de processos, entender regras, priorizar casos de uso.</p>
</div>
<div class="text-center">
<div class="w-14 h-14 mx-auto rounded-full bg-gosign-accent flex items-center justify-center">
<span class="text-h3 font-bold text-white">2</span>
</div>
<h3 class="text-h3 font-bold text-gosign-dark mt-4">Build</h3>
<p class="text-small font-semibold text-gosign-accent-text mt-1">3-4 semanas</p>
<p class="text-body text-gosign-text-light mt-2">PoC produtivo. Um agente, um processo, ao vivo na sua infraestrutura.</p>
</div>
<div class="text-center">
<div class="w-14 h-14 mx-auto rounded-full bg-gosign-accent flex items-center justify-center">
<span class="text-h3 font-bold text-white">3</span>
</div>
<h3 class="text-h3 font-bold text-gosign-dark mt-4">Scale</h3>
<p class="text-small font-semibold text-gosign-accent-text mt-1">Contínuo</p>
<p class="text-body text-gosign-text-light mt-2">Mais agentes, mais processos. Mesma governança, mesma auditabilidade.</p>
</div>
</div>
<p class="text-body-lg text-center text-gosign-text-light mt-8 max-w-narrow mx-auto">Após 12-18 meses, você opera seus agentes de forma independente.</p>
</div>
</section>


<!-- Aprofundamento -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Aprofundamento no Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nossa série de artigos para executivos que implementam agentes de IA na empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/br/revista/o-que-sao-agentes-ia/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">AI Agents</p>
<p class="text-body font-semibold text-gosign-dark">O que são agentes de IA? Document, Workflow e Knowledge Agents</p>
</a>
<a href="/br/revista/decision-layer-explicado/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - O que é por que todo agente AI enterprise precisa de um</p>
</a>
<a href="/br/revista/por-que-projetos-ia-rh-fracassam/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Estratégia</p>
<p class="text-body font-semibold text-gosign-dark">Por que projetos de IA em RH fracassam</p>
</a>
</div>
</div>
</section>

--- Site hackeado? 10 motivos e ajuda imediata ---
> Por que sites são hackeados: as 10 causas mais comuns e o que você pode fazer imediatamente. Ajuda emergencial da Gosign.

<!-- O que fazer quando hackeado? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">O que fazer quando o site foi hackeado?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Se o seu site foi hackeado, velocidade é essencial: remover malware, encontrar o ponto de entrada, fechar a vulnerabilidade, informar o Google sobre a limpeza. A Gosign oferece suporte emergencial para sites hackeados - WordPress, TYPO3 e outros CMS. Este artigo explica as 10 causas mais comuns de ataques a sites e como você pode se proteger.
</p>
</div>
</section>

<!-- 10 motivos -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">Os 10 motivos mais comuns para sites serem hackeados</h2>

<div class="space-y-8">
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">1. Versão desatualizada do CMS</h3>
<p class="text-body text-gosign-text leading-relaxed">
WordPress 5.x, TYPO3 v9, Joomla 3: versões antigas de CMS possuem vulnerabilidades conhecidas e documentadas. Atacantes fazem varreduras automáticas em busca de instalações desatualizadas. Solução: sempre manter a versão LTS atual, atualizações automáticas de segurança.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">2. Plugins/extensions inseguros</h3>
<p class="text-body text-gosign-text leading-relaxed">
Um único plugin desatualizado é suficiente. A Gosign monitora mais de 800 extensions TYPO3 e conhece os candidatos de risco. No WordPress: apenas plugins de fontes confiáveis, atualizações regulares, plugins não utilizados devem ser excluídos (não apenas desativados).
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">3. Senhas fracas</h3>
<p class="text-body text-gosign-text leading-relaxed">
"admin/admin123" ainda é assustadoramente comum. Ataques de força bruta testam milhares de combinações por minuto. Solução: senhas fortes + autenticação de dois fatores + limitação de taxa de login.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">4. Falta de SSL/HTTPS</h3>
<p class="text-body text-gosign-text leading-relaxed">
Sem HTTPS, dados de login são transmitidos em texto aberto. Todo site precisa de um certificado SSL. Em 2026, não há mais desculpa.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">5. Hospedagem insegura</h3>
<p class="text-body text-gosign-text leading-relaxed">
Hospedagem compartilhada com centenas de sites em um servidor: se um for hackeado, todos ficam em risco. Solução: hospedagem gerenciada com isolamento, backups automáticos e Web Application Firewall.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">6. Sem Web Application Firewall (WAF)</h3>
<p class="text-body text-gosign-text leading-relaxed">
Uma WAF bloqueia padrões de ataque conhecidos (SQL Injection, XSS, File Inclusion) antes que alcancem sua aplicação. Cloudflare WAF, ModSecurity ou soluções comerciais.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">7. Falta de backups</h3>
<p class="text-body text-gosign-text leading-relaxed">
Sem backup = sem âncora de salvação. Backups diários, armazenados separadamente do servidor web, testados regularmente. Um backup que não pode ser restaurado não é um backup.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">8. Upload de arquivos inseguro</h3>
<p class="text-body text-gosign-text leading-relaxed">
Formulários de upload sem validação permitem que atacantes enviem PHP shells. Solução: verificação rigorosa de tipo de arquivo, armazenar uploads fora do webroot, randomizar nomes de arquivo.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">9. SQL Injection</h3>
<p class="text-body text-gosign-text leading-relaxed">
Entradas de usuário não filtradas em consultas de banco de dados permitem que atacantes leiam ou manipulem toda a base de dados. Solução: Prepared Statements, validação de entrada, uso de ORM.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">10. Sem monitoramento</h3>
<p class="text-body text-gosign-text leading-relaxed">
Se ninguém está observando, ninguém percebe a invasão. Alguns hacks permanecem meses sem serem detectados (injeção de spam, mineração de criptomoedas, hacks de redirecionamento). Solução: monitoramento de uptime, monitoramento de integridade de arquivos, varreduras regulares de malware.
</p>
</div>
</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Site hackeado? A Gosign pode ajudar. Consultoria emergencial disponível.</h3>
<p class="text-body text-gosign-text mb-6">Análise rápida, limpeza e proteção do seu site.</p>
<a
href="/br/contato/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Solicitar ajuda emergencial
</a>
<p class="text-small text-gosign-text-light mt-4">25 anos de experiência · 800+ extensions · Desenvolvimento acelerado por IA</p>
</div>
</section>

<!-- Checklist -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Checklist: medidas imediatas após um ataque</h2>
<ol class="space-y-3">
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 flex items-center justify-center bg-gosign-accent text-white font-bold rounded-full text-small">1</span>
<span class="text-body text-gosign-text pt-1">Colocar o site offline (modo de manutenção)</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 flex items-center justify-center bg-gosign-accent text-white font-bold rounded-full text-small">2</span>
<span class="text-body text-gosign-text pt-1">Alterar senhas (CMS, FTP, banco de dados, hospedagem)</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 flex items-center justify-center bg-gosign-accent text-white font-bold rounded-full text-small">3</span>
<span class="text-body text-gosign-text pt-1">Salvar backup (estado atual para forense)</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 flex items-center justify-center bg-gosign-accent text-white font-bold rounded-full text-small">4</span>
<span class="text-body text-gosign-text pt-1">Identificar o último backup limpo</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 flex items-center justify-center bg-gosign-accent text-white font-bold rounded-full text-small">5</span>
<span class="text-body text-gosign-text pt-1">Executar varredura de malware</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 flex items-center justify-center bg-gosign-accent text-white font-bold rounded-full text-small">6</span>
<span class="text-body text-gosign-text pt-1">Identificar o ponto de entrada (verificar logs)</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 flex items-center justify-center bg-gosign-accent text-white font-bold rounded-full text-small">7</span>
<span class="text-body text-gosign-text pt-1">Limpar e fechar a vulnerabilidade</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 flex items-center justify-center bg-gosign-accent text-white font-bold rounded-full text-small">8</span>
<span class="text-body text-gosign-text pt-1">Colocar o site novamente online</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 flex items-center justify-center bg-gosign-accent text-white font-bold rounded-full text-small">9</span>
<span class="text-body text-gosign-text pt-1">Google Search Console: solicitar revisão</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 flex items-center justify-center bg-gosign-accent text-white font-bold rounded-full text-small">10</span>
<span class="text-body text-gosign-text pt-1">Configurar monitoramento para que não aconteça novamente</span>
</li>
</ol>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
A Gosign é uma agência digital de Hamburgo com 25 anos de experiência em desenvolvimento web, TYPO3 e integração de IA.
Analisamos mais de 800 extensions TYPO3 e hoje desenvolvemos com suporte de IA
até 70% mais rápido do que com métodos tradicionais. A partir do hub europeu em Hamburgo,
atendemos empresas brasileiras e latino-americanas que buscam excelência digital.
</p>
<p class="text-small text-gosign-text-light mt-2">Atualizado em: fevereiro de 2026</p>
</div>
</section>

<!-- Temas relacionados -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Temas relacionados</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/br/seguranca-web-padroes/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Segurança</p>
<p class="text-body font-semibold text-gosign-dark">Segurança web conforme padrões CERT.br</p>
</a>
<a href="/br/typo3-monitor-seguranca/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Monitoramento</p>
<p class="text-body font-semibold text-gosign-dark">Monitor de segurança TYPO3</p>
</a>
<a href="/br/agencia-wordpress/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Desenvolvimento web</p>
<p class="text-body font-semibold text-gosign-dark">Agência WordPress Hamburgo</p>
</a>
</div>
</div>
</section>

--- Sobre nós - Enterprise AI Infrastructure desde 2001 ---
> Desde 2001. Mais de 5.000 projetos para Airbus, Volkswagen, Shell. Hoje Enterprise AI Infrastructure & Agent Engineering.

<article class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<div class="prose prose-lg prose-headings:text-gosign-dark prose-headings:font-bold prose-h2:text-h2 prose-h2:mt-12 prose-h2:mb-4 prose-h3:text-h3 prose-h3:mt-8 prose-h3:mb-3 prose-p:text-gosign-text prose-p:leading-relaxed prose-a:text-gosign-accent-text prose-a:underline prose-a:decoration-gosign-accent-text/30 hover:prose-a:decoration-gosign-accent-text prose-strong:text-gosign-dark prose-ul:text-gosign-text prose-ol:text-gosign-text">

## De projetos de software a arquitetura de decisões

A Gosign foi fundada em Hamburgo em 2001. Há mais de 25 anos desenvolvemos sistemas de software complexos para médias e grandes empresas - em mais de 5.000 projetos para empresas como Airbus, Volkswagen, Shell.

Nossas raízes estão no software enterprise clássico: integração de sistemas, plataformas individuais, desenvolvimento próximo ao ERP e arquiteturas orientadas à segurança. Com o surgimento da IA generativa, começamos a testar workflows baseados em LLM em ambientes empresariais reais - primeiro experimentalmente, depois em produção em configurações enterprise baseadas em Azure.

Hoje construímos Enterprise AI Agents e a infraestrutura que os torna responsáveis: o [Decision Layer](/br/decision-layer/), que decompõe cada processo em etapas de decisão individuais e define para cada etapa: humano, conjunto de regras ou IA.


## O que representamos

### Qualidade de decisão antes de automação

Empresas raramente fracassam por falta de ferramentas. Fracassam por lógica de decisão inconsistente. Decisões de RH e finanças em muitas organizações não são versionadas, não são reproduzíveis e dependem do conhecimento de pessoas individuais. Nossa arquitetura torna a lógica de decisão explícita, rastreável e auditável - como camada técnica, não como consultoria organizacional.

### Governance by Design

Compliance não é um processo posterior no nosso caso. Nossos agentes são construídos de forma que a lógica de decisão é versionada, o [Human-in-the-Loop](/br/governance/) está arquitetonicamente ancorado, Audit Trails são gerados automaticamente e controles existem como objetos de dados. Quando uma certificação é necessária, o sistema está estruturalmente preparado para isso.

Mais em nossas [páginas de Governance](/br/governance/).

### Integração em vez de substituição

Não substituímos sistemas existentes. SAP continua sendo ERP. Workday continua sendo plataforma de RH. SuccessFactors continua sendo líder. Complementamos esses sistemas com uma camada de decisão e governance - o Decision Layer, que torna os agentes auditáveis e controláveis.


## Como trabalhamos

### Co-Build com departamentos especializados

Cada empresa tem sua própria lógica de remuneração, seus próprios acordos coletivos, seus próprios requisitos de governance e suas próprias estruturas ERP. Por isso desenvolvemos [AI Agents](/br/servicos/ai-agents/) em Co-Build com RH, Finanças e TI - não como produto pronto, mas configurado para os processos e regras específicos da empresa.

### Acesso completo ao código-fonte

Nossas soluções rodam na [infraestrutura do cliente](/br/servicos/infraestrutura/) - em Azure, GCP, AWS ou Self-Hosted. Sem modelo SaaS proprietário, sem vendor lock-in. Acesso completo ao código-fonte, configurações e conjuntos de regras. A transferência para operação própria após 12-18 meses é parte do modelo.

A Gosign deliberadamente não é um modelo de dependência.


## Tecnologias

<div class="not-prose text-body text-gosign-text leading-relaxed">
<a href="https://www.python.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Python</a>, <a href="https://www.typescriptlang.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">TypeScript</a>/<a href="https://nodejs.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Node.js</a>, <a href="https://go.dev/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Go (Golang)</a> - Frontend: <a href="https://react.dev/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">React</a>, <a href="https://nextjs.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Next.js</a>, <a href="https://vuejs.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Vue</a> - Banco de dados: <a href="https://www.postgresql.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">PostgreSQL</a>, <a href="https://supabase.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Supabase</a> - Orquestração: <a href="https://trigger.dev" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Trigger.dev</a>, <a href="https://camunda.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Camunda</a>, <a href="https://airflow.apache.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Airflow</a> - Containers: <a href="https://www.docker.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Docker</a>, <a href="https://kubernetes.io/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Kubernetes</a> - Cloud: <a href="https://azure.microsoft.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Azure</a>, <a href="https://cloud.google.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">GCP</a>, <a href="https://aws.amazon.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">AWS</a> - On-Premise: <a href="https://github.com/vllm-project/vllm" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">vLLM</a>, <a href="https://ollama.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Ollama</a>
</div>


## Certificações e competências

Nossa equipe combina mais de 25 anos de experiência enterprise com certificações atuais em cloud e IA. Nossos engenheiros de IA possuem certificação Microsoft Azure AI e trabalham diariamente com APIs de LLM, frameworks de orquestração e sistemas de integração empresarial.

<a href="https://www.bvdw.org/en/committees/artificial-intelligence/" target="_blank" rel="noopener noreferrer" class="not-prose flex items-center gap-4 group mt-6">
<img src="/images/badges/bvdw-mitglied.png" alt="Membro BVDW" width="349" height="428" class="w-16 h-16 object-contain opacity-60 group-hover:opacity-100 transition-opacity" loading="lazy" />
<span class="text-body text-gosign-text-light group-hover:text-gosign-accent transition-colors">Membro da Associação Federal Alemã de Economia Digital (BVDW)</span>
</a>



## Quem somos

A Gosign é uma empresa proprietária. 108 colaboradores em escritórios em Hamburgo, Berlim, Cracóvia, Barcelona, Lisboa e São Paulo. Nosso maior centro de desenvolvimento opera no Paquistão desde 2002 - fundado como escola de programação, hoje um hub de engenharia estabelecido com vínculos estreitos com os departamentos de ciência da computação das universidades de Karachi, Lahore e Islamabad.

<div class="flex flex-col md:flex-row gap-12 not-prose my-8">
<div class="flex-1 text-center">
<img src="/images/team/bert-gogolin.webp" alt="Bert Gogolin, Diretor Geral Gosign GmbH" width="400" height="400" class="w-48 h-48 lg:w-56 lg:h-56 rounded-full object-cover mx-auto mb-6 border-4 border-gosign-light" />
<h3 class="text-h3 font-bold text-gosign-dark">Bert Gogolin</h3>
<p class="text-body text-gosign-text-light">Diretor Geral</p>
<a href="https://www.linkedin.com/in/bert-gogolin/" class="inline-flex items-center gap-1 text-small text-gosign-text-light hover:text-gosign-accent mt-2 transition-colors" target="_blank" rel="noopener noreferrer">
<svg class="w-4 h-4" fill="currentColor" viewBox="0 0 24 24"><path d="M20.447 20.452h-3.554v-5.569c0-1.328-.027-3.037-1.852-3.037-1.853 0-2.136 1.445-2.136 2.939v5.667H9.351V9h3.414v1.561h.046c.477-.9 1.637-1.85 3.37-1.85 3.601 0 4.267 2.37 4.267 5.455v6.286zM5.337 7.433a2.062 2.062 0 01-2.063-2.065 2.064 2.064 0 112.063 2.065zm1.782 13.019H3.555V9h3.564v11.452zM22.225 0H1.771C.792 0 0 .774 0 1.729v20.542C0 23.227.792 24 1.771 24h20.451C23.2 24 24 23.227 24 22.271V1.729C24 .774 23.2 0 22.222 0h.003z"/></svg>
LinkedIn
</a>
</div>
<div class="flex-1 text-center">
<img src="/images/team/dieter-gogolin.webp" alt="Dieter Gogolin, Diretor Geral Gosign GmbH" width="400" height="400" class="w-48 h-48 lg:w-56 lg:h-56 rounded-full object-cover mx-auto mb-6 border-4 border-gosign-light" />
<h3 class="text-h3 font-bold text-gosign-dark">Dieter Gogolin</h3>
<p class="text-body text-gosign-text-light">Diretor Geral</p>
</div>
</div>

Bert lidera o relacionamento com clientes: da análise inicial ao mapeamento de processos e decisões arquitetônicas. Dieter é responsável pelo desenvolvimento operacional e estratégico - da infraestrutura e equipes internacionais à estratégia de parcerias.


## Por que fazemos isso

A IA generativa está mudando como decisões são preparadas, documentadas e prestadas contas. Estamos convictos de que agentes de IA só escalam produtivamente quando o governance está estruturalmente integrado, a lógica de decisão se torna explícita e as pessoas permanecem conscientemente envolvidas.

Para isso construímos a [infraestrutura](/br/servicos/infraestrutura/).

Todos os dados da empresa em um só lugar: [Fatos e números](/br/fatos/)

</div>
</div>
</article>

--- Termos e Condições Gerais - Gosign GmbH ---
> TCG da Gosign GmbH para infraestrutura de IA, desenvolvimento de agentes e desenvolvimento de software. Versão 3.1.

<h1>Termos e Condições Gerais</h1>
<p class="text-sm bg-gosign-light border border-gosign-border rounded-card p-3 mt-2">
<strong>Aviso:</strong> Este documento é uma tradução informativa. A versão alemã é juridicamente vinculante. Em caso de divergências, prevalece a versão alemã.
<a href="/de/agb/" class="text-gosign-accent-text hover:text-gosign-accent-hover ml-1">→ Deutsche Fassung (versão alemã)</a>
</p>
<p class="text-lg text-gosign-text-light">
Gosign GmbH - Infraestrutura de IA, desenvolvimento de agentes e desenvolvimento de software<br/>
Versão 3.1 - Data: março de 2026
</p>
<p class="text-sm text-gosign-text-light mt-2">
<a href="/documents/gosign-agb-v3.1.pdf" target="_blank" rel="noopener noreferrer"
class="text-gosign-accent-text hover:text-gosign-accent-hover">↓ Baixar como PDF</a>
</p>

<h2>§ 1 Âmbito de aplicação e objeto do contrato</h2>
<p>Estes Termos e Condições Gerais (TCG) aplicam-se a todos os contratos celebrados entre a Gosign GmbH (doravante "Gosign") e seus clientes nas seguintes áreas de serviço:</p>
<p><strong>Infraestrutura empresarial de IA e desenvolvimento de agentes:</strong> Serviços relacionados à inteligência artificial no ambiente corporativo, incluindo planejamento e implementação de infraestrutura de IA, desenvolvimento de agentes de IA, integração de modelos de IA, soluções de self-hosting, estratégias FinOps para otimização de custos de cargas de trabalho de IA, bem como serviços de consultoria e desenvolvimento associados.</p>
<p><strong>Decision Layer e arquitetura de Governance:</strong> Desenvolvimento e implementação de uma camada de governança e controle (Decision Layer) entre agentes de IA e os sistemas-alvo da empresa, incluindo controle de decisões baseado em regras, documentação de Audit Trail, arquitetura Human-in-the-Loop e geração automatizada de evidências de conformidade (Cert-Ready).</p>
<p><strong>Desenvolvimento de software:</strong> Desenvolvimento de soluções de software individuais, aplicações web e integrações, inclusive com utilização de frameworks e bibliotecas de código aberto. Compreende concepção, design, desenvolvimento, adaptação, integração e documentação.</p>
<p><strong>Hosting e serviços operacionais (opcional):</strong> Serviços de hosting opcionais e suporte operacional oferecidos pela Gosign. A operação regular das soluções desenvolvidas pela Gosign ocorre, como regra, na infraestrutura do cliente. O hosting pela Gosign é um serviço adicional acordado separadamente.</p>
<p><strong>Enablement e transferência de conhecimento:</strong> O objetivo da Gosign é capacitar o cliente para operar e desenvolver de forma autônoma as soluções entregues. Na medida do acordado, o escopo dos serviços inclui treinamentos, documentação e uma transferência de conhecimento estruturada, orientada a reduzir sistematicamente a dependência do cliente em relação à Gosign.</p>
<p><strong>Delimitação:</strong> A Gosign presta serviços técnicos. As soluções desenvolvidas pela Gosign não substituem assessoria jurídica, tributária ou de recursos humanos. As decisões profissionais finais permanecem com o cliente. Os sistemas do cliente (p. ex., SAP, Workday, SuccessFactors, DATEV) permanecem como sistema mestre (System of Record); as soluções Gosign integram-se a esses sistemas, mas não os substituem.</p>
<p><strong>Base de clientes:</strong> Estes TCG destinam-se exclusivamente a empresários na acepção do § 14 do Código Civil alemão (BGB). Aplicam-se diretamente a clientes com sede na UE/EEE. Para clientes fora da UE/EEE, aplicam-se quando a aplicação do direito alemão tiver sido acordada. A Gosign não celebra contratos com consumidores.</p>
<p>Acordos individuais e SLAs prevalecem sobre estes TCG. Condições divergentes do cliente não se aplicam, salvo se a Gosign tiver consentido expressamente por escrito.</p>

<h2>§ 2 Definições</h2>
<p>Os seguintes termos são utilizados nestes TCG com o significado indicado abaixo:</p>
<p><strong>"Agent"</strong> designa um componente de software que, com base em modelos de IA e conjuntos de regras, executa ou prepara automaticamente tarefas em nome do cliente (p. ex., Document Agent, Workflow Agent, Knowledge Agent).</p>
<p><strong>"Audit Trail"</strong> designa o registro completo e cronológico de todos os Decision Records e eventos no sistema.</p>
<p><strong>"Auditor Portal"</strong> designa uma interface web através da qual auditores autorizados (internos ou externos) podem visualizar o status em tempo real de todos os Controls e Evidence.</p>
<p><strong>"Cert-Ready"</strong> designa a propriedade de uma arquitetura de sistema que atende aos pré-requisitos técnicos para certificações padrão do setor (p. ex., ISO 27001, SOC 2, IDW PS 951) - sem que isso implique a obrigação ou garantia de obter a certificação em si.</p>
<p><strong>"Component Manifest"</strong> designa o anexo à proposta que lista cada componente de software relevante, classificando-o como resultado de trabalho específico do cliente (§ 7.1) ou como Componente de Plataforma (§ 7.2). Os detalhes são regulados pelo § 7.2, parágrafo 4.</p>
<p><strong>"Control"</strong> designa uma regra de verificação implementada tecnicamente que garante o cumprimento de um determinado padrão de conformidade ou governança (p. ex., "Nenhuma decisão salarial sem o princípio de quatro olhos").</p>
<p><strong>"Decision Layer"</strong> designa a camada de governança e controle desenvolvida pela Gosign que decompõe processos de negócio em decisões individuais e determina, para cada etapa, se um ser humano decide, um conjunto de regras é aplicado ou a IA age de forma autônoma.</p>
<p><strong>"Decision Record"</strong> designa a documentação automática e imutável de uma decisão individual no Decision Layer, composta por dados de entrada, regra/versão do modelo aplicada, grau de confiança, caminho da decisão e resultado.</p>
<p><strong>"Evidence"</strong> designa uma prova gerada automaticamente de que um Control foi cumprido em um momento específico.</p>
<p><strong>"Human-in-the-Loop"</strong> designa um princípio arquitetônico segundo o qual determinadas decisões requerem aprovação humana antes da execução. A classificação de quais decisões requerem aprovação humana é determinada conjuntamente com o cliente durante o projeto.</p>
<p><strong>"Maintenance"</strong> designa o contrato anual opcional de manutenção para Componentes de Plataforma, que abrange manutenção contínua, atualizações de segurança e evolução. Os detalhes são regulados pelo § 7.7.</p>
<p><strong>"Perpetual License"</strong> designa o direito de uso permanente do cliente sobre a versão entregue dos Componentes de Plataforma conforme § 7.2, parágrafo 2. O direito de uso existe independentemente da existência de um contrato de manutenção.</p>
<p><strong>"Componentes de Plataforma" (Plattform-Komponenten)</strong> designa o núcleo técnico reutilizável das soluções Gosign, em particular a Decision Engine, o framework de motor de regras, a arquitetura de Audit Trail e os módulos de orquestração. Os detalhes são regulados pelo § 7.2, parágrafo 1.</p>
<p><strong>"Transferência de código-fonte" (Quellcode-Transfer)</strong> designa a transferência do direito de uso exclusivo sobre os componentes de software desenvolvidos individualmente para o cliente, incluindo código-fonte, prompts, conjuntos de regras, configurações e documentação.</p>
<p><strong>"Software Bill of Materials (SBOM)"</strong> designa a relação de todos os componentes de código aberto utilizados na solução e suas respectivas licenças, conforme § 7.4.</p>
<p><strong>"System of Record"</strong> designa o sistema mestre do cliente para dados cadastrais e transacionais (p. ex., SAP, Workday, SuccessFactors, DATEV). As soluções Gosign integram-se ao System of Record, mas não o substituem.</p>
<p><strong>"Terceiros Autorizados" (Zulässige Dritte)</strong> designa os destinatários listados exaustivamente no § 7.1, parágrafo 3, aos quais o cliente pode transferir resultados de trabalho e Componentes de Plataforma sem autorização adicional da Gosign.</p>

<h2>§ 3 Celebração do contrato</h2>
<p><strong>Proposta e pedido:</strong> A apresentação de serviços pela Gosign não constitui, em regra, uma oferta contratual vinculante. O contrato é celebrado mediante o pedido do cliente e a aceitação pela Gosign no prazo de 14 dias corridos.</p>
<p>O contrato é celebrado somente quando a Gosign confirma o pedido em forma textual ou inicia a execução.</p>
<p><strong>Contrato-quadro e fases do projeto:</strong> O contrato pode ser celebrado como contrato-quadro com fases comissionadas individualmente. Cada fase pode ser comissionada separadamente, sem obrigação de comissionar fases subsequentes.</p>
<p><strong>Tipos de contrato por fase:</strong> Fases de Discovery (análise, consultoria, mapeamento de processos) são executadas como contratos de prestação de serviços (Dienstvertrag no direito alemão); a obrigação é a prestação do serviço de consultoria, não um resultado determinado. Fases de Build (desenvolvimento, implementação, Proof of Concept) são executadas como contratos de empreitada (Werkvertrag) com aceitação, salvo acordo em contrário. Fases de Scale e Support são executadas como contratos de prestação de serviços; SLAs opcionais aplicam-se adicionalmente.</p>
<p>Os contratos podem ser celebrados por escrito, eletronicamente ou em forma textual. A Gosign conserva o texto do contrato e estes TCG.</p>

<h2>§ 4 Serviços da Gosign</h2>
<p>A Gosign presta os serviços contratualmente acordados de forma profissional e com a diligência de um comerciante prudente. A Gosign está autorizada a empregar pessoal qualificado, auxiliares ou subcontratados.</p>
<p><strong>Local de prestação:</strong> Os serviços são prestados, como regra, de forma remota. A Gosign aloca pessoal em diversas localidades e garante o cumprimento dos padrões de segurança e proteção de dados acordados, independentemente da localização. Intervenções presenciais são acordadas separadamente.</p>
<p><strong>Coordenação do projeto:</strong> Ambas as partes designam pessoas de contato. A Gosign informa regularmente sobre o progresso do projeto.</p>
<p><strong>Prazos:</strong> Prazos são vinculantes apenas quando expressamente acordados como tal. Atrasos não atribuíveis à Gosign estendem os prazos proporcionalmente.</p>
<p><strong>Solicitações de alteração (Change Requests):</strong> Alterações no escopo dos serviços requerem acordo por escrito sobre custos adicionais e prazos.</p>
<p><strong>Proof of Concept (PoC):</strong> Quando um PoC for acordado, aplicam-se os critérios de sucesso definidos na proposta. Um PoC serve para validar a viabilidade técnica. Os resultados do trabalho do PoC são transferidos ao cliente após pagamento integral, salvo acordo em contrário.</p>
<p><strong>Entregas parciais:</strong> A Gosign está autorizada a realizar entregas parciais razoáveis.</p>
<h3>4.1 Aceitação de entregas de obra</h3>
<p>O cliente revisa as entregas de obra no prazo de 14 dias corridos e declara a aceitação ou comunica defeitos. A falta de resposta implica a aceitação, desde que o cliente tenha sido informado dessa consequência. Defeitos menores não autorizam o cliente a recusar a aceitação.</p>

<h2>§ 5 Obrigações de cooperação do cliente</h2>
<p>O cliente fornece tempestivamente todos os documentos, informações, dados e acessos necessários.</p>
<p>O cliente designa uma pessoa de contato qualificada com poderes de decisão.</p>
<p><strong>Infraestrutura técnica:</strong> Quando os serviços forem prestados nos sistemas do cliente, este fornece a infraestrutura. A Gosign informa sobre os requisitos do sistema.</p>
<p><strong>Testes e aceitações:</strong> O cliente coopera ativamente, documenta erros e não atrasa aprovações de forma injustificada.</p>
<p><strong>Manutenção e backup:</strong> O cliente instala de forma autônoma e tempestiva as atualizações de segurança, salvo existência de contrato de manutenção com a Gosign. Backups regulares são de responsabilidade do cliente.</p>
<p><strong>Legalidade:</strong> O cliente é responsável pela legalidade de todos os conteúdos e dados fornecidos e indeniza a Gosign contra reclamações de terceiros.</p>
<p>Atrasos e custos adicionais decorrentes do descumprimento das obrigações de cooperação são de responsabilidade do cliente.</p>

<h2>§ 6 Disposições especiais para infraestrutura de IA e desenvolvimento de agentes</h2>
<h3>6.1 Escopo dos serviços</h3>
<p>O escopo dos serviços é definido na proposta e pode incluir: integração e customização de modelos de IA, desenvolvimento de agentes de IA, implementação do Decision Layer, consultoria em infraestrutura de IA, FinOps, conceitos de segurança e conformidade, treinamentos.</p>
<p>A proposta indica quais Componentes de Plataforma (§ 7.2) são utilizados e contém um Component Manifest como anexo.</p>
<h3>6.2 Arquitetura de três camadas e responsabilidades</h3>
<p>As soluções de IA desenvolvidas pela Gosign distinguem três camadas de processamento com diferentes responsabilidades:</p>
<p>(a) <strong>Análise (modelo de IA):</strong> O modelo linguístico analisa dados e gera sugestões. Modelos de IA produzem resultados probabilísticos; a Gosign é responsável pela integração e configuração adequadas do modelo, não pela exatidão do conteúdo de cada resultado individual.</p>
<p>(b) <strong>Decisão (Decision Layer):</strong> O Decision Layer aplica conjuntos de regras, limiares e processos de aprovação definidos aos resultados da análise. A Gosign é responsável pela correta implementação da lógica de decisão acordada. Erros na implementação de regras são defeitos de software sujeitos à garantia.</p>
<p>(c) <strong>Execução (integração/ferramenta):</strong> Os resultados são transmitidos aos sistemas-alvo do cliente (p. ex., SAP, DATEV, Workday). A Gosign é responsável pela correta integração técnica. Erros no sistema-alvo do cliente são de responsabilidade deste.</p>
<h3>6.3 Human-in-the-Loop</h3>
<p>Para decisões classificadas como de alto risco (em particular, decisões de pessoal, decisões salariais, decisões sujeitas a participação dos trabalhadores - Mitbestimmung), Human-in-the-Loop é o padrão, salvo acordo expresso em contrário. A classificação de quais decisões requerem aprovação humana é determinada conjuntamente e configurada no Decision Layer. O cliente permanece responsável pelas decisões profissionais finais.</p>
<h3>6.4 Abordagem model-agnostic</h3>
<p>A Gosign utiliza modelos de IA de diversos provedores (abordagem model-agnostic). A seleção é feita em consulta com o cliente. A Gosign informa sobre mudanças de modelo previstas. Caso um provedor descontinue seu serviço, a Gosign proporá tempestivamente um modelo alternativo equivalente. A Gosign não se responsabiliza pela disponibilidade ou descontinuação de serviços de terceiros.</p>
<h3>6.5 Bias Monitoring</h3>
<p>Na medida do acordado, a Gosign implementa mecanismos para detecção e documentação de vieses sistemáticos (Bias Monitoring). A verificação contínua durante a operação é de responsabilidade do cliente, salvo existência de contrato de manutenção.</p>
<h3>6.6 Uso de dados para IA</h3>
<p>O cliente permanece como proprietário e controlador de todos os dados fornecidos à Gosign. A Gosign os utiliza exclusivamente para a execução do contrato. O cliente garante que possui os direitos necessários. Na medida em que modelos ou APIs de IA externos forem utilizados, isso ocorrerá somente em condições que excluam o uso dos dados do cliente para treinamento dos modelos, salvo autorização expressa do cliente em contrário.</p>
<h3>6.7 FinOps e custos dependentes de consumo</h3>
<p>Os custos de terceiros dependentes de consumo (taxas de API, tempo de computação GPU) são arcados pelo cliente, salvo acordo em contrário. A Gosign informa previamente sobre a estrutura de custos e fornece relatórios de consumo transparentes.</p>
<h3>6.8 Requisitos regulatórios</h3>
<p>A Gosign aborda os requisitos do Regulamento (UE) 2024/1689 (EU AI Act) como princípios arquitetônicos técnicos (Readiness). A avaliação jurídica de conformidade para o contexto de implantação específico é de responsabilidade do cliente e de seus assessores jurídicos. A Gosign apoia o cliente na implementação de requisitos regulatórios quando contratada para tal.</p>
<h3>6.9 Indenização</h3>
<p>A utilização dos sistemas de IA é de responsabilidade exclusiva do cliente. O cliente indeniza a Gosign contra reclamações de terceiros decorrentes de uso indevido ou ilícito.</p>

<h2>§ 7 Direitos de uso, propriedade intelectual e acesso ao código-fonte</h2>
<h3>7.1 Direitos de uso sobre resultados de trabalho específicos do cliente</h3>
<p>O cliente recebe, com o pagamento integral, um direito de uso permanente, ilimitado territorialmente e não exclusivo sobre os seguintes resultados de trabalho específicos do cliente:</p>
<p>(a) Configurações específicas do cliente (conjuntos de regras, tabelas de decisão, políticas, regras de roteamento, modelos de dados específicos do cliente, tabelas de decisão)</p>
<p>(b) Prompts e templates de prompts desenvolvidos para o cliente e identificados como específicos do cliente no Component Manifest</p>
<p>(c) Integrações e adaptadores específicos do cliente conforme Component Manifest (p. ex., conexões SAP específicas do cliente, conectores de API, textos de interface)</p>
<p>(d) Documentação técnica da solução específica do cliente</p>
<p>(e) Dados e configurações do cliente em todos os formatos</p>
<p>A classificação em § 7.1 ou § 7.2 decorre do Component Manifest conforme § 7.2, parágrafo 4.</p>
<p>O direito de uso inclui o direito de modificação e desenvolvimento para a operação comercial própria do cliente.</p>
<p>A transferência a terceiros ou sublicenciamento requer o consentimento prévio por escrito da Gosign. <strong>Não é necessário consentimento para a transferência a Terceiros Autorizados.</strong> Terceiros Autorizados são:</p>
<p>(i) Empresas coligadas do cliente na acepção dos §§ 15 e seguintes da Lei das Sociedades por Ações alemã (AktG) ou legislação estrangeira comparável de direito societário (empresas do grupo, subsidiárias, unidades de serviços compartilhados)</p>
<p>(ii) Prestadores de serviços de TI e operadores de tratamento de dados do cliente, que atuam sob obrigação de confidencialidade e limitação de finalidade</p>
<p>(iii) Auditores, auditoria interna e autoridades reguladoras no âmbito de obrigações legais ou contratuais de auditoria</p>
<p>(iv) Sucessores jurídicos do cliente em caso de reestruturação, fusão ou cessão de ativos, desde que a transferência ocorra no âmbito da transmissão da operação comercial em que a solução é utilizada e o sucessor jurídico assuma as obrigações do § 7; é excluída a transferência a concorrentes diretos da Gosign</p>
<p>O cliente garante que os Terceiros Autorizados observam obrigações de proteção e confidencialidade pelo menos equivalentes.</p>
<p>O § 7.1 prevalece sobre a disposição geral de cessão do § 19, na medida em que a transferência a Terceiros Autorizados ou sucessores jurídicos esteja em questão.</p>
<p>O cliente tem, o mais tardar a partir do deployment da solução em sua infraestrutura, ou, caso contrário, o mais tardar com a aceitação ou o pagamento integral, acesso completo ao código-fonte de todos os componentes operados em seu ambiente - incluindo os Componentes de Plataforma conforme § 7.2. Acesso significa código-fonte legível, não intencionalmente tornado ilegível, em um repositório mantido no ambiente do cliente ou como exportação de código (pelo menos após cada release produtivo, bem como mediante solicitação dentro de 10 dias úteis), incluindo instruções de build e arquivos de dependências (Dependency Lockfiles). Exportações de código adicionais fora dos releases regulares são realizadas até duas vezes por trimestre sem custo; exportações além disso são remuneradas conforme esforço.</p>

<h3>7.2 Componentes de Plataforma da Gosign</h3>
<p>A Gosign utiliza componentes de plataforma próprios no desenvolvimento. Componentes de Plataforma são o núcleo técnico reutilizável, em particular a Decision Engine, o framework de motor de regras, a arquitetura de Audit Trail e os módulos de orquestração (doravante "Componentes de Plataforma"). A propriedade intelectual exclusiva e o direito de uso sobre esses Componentes de Plataforma permanecem com a Gosign.</p>
<p>O cliente recebe um <strong>direito de uso permanente sobre a versão entregue</strong> dos Componentes de Plataforma (Perpetual License). Esse direito de uso é não exclusivo e abrange a operação, configuração e integração nos sistemas do cliente para sua operação comercial própria. O direito de uso existe independentemente da existência de um contrato de manutenção. As regras de transferência do § 7.1 (incluindo os Terceiros Autorizados e a obrigação de repasse) aplicam-se por analogia.</p>
<p>O cliente tem, a partir do deployment (ou da aceitação/pagamento conforme § 7.1), acesso completo ao código-fonte de todos os Componentes de Plataforma operados em sua infraestrutura. A Gosign fornece documentação técnica completa, incluindo instruções de build. O código-fonte não é intencionalmente tornado ilegível (sem ofuscação, sem dificultação intencional da legibilidade). A criptografia do código-fonte em repouso e em trânsito para proteção da integridade não é afetada por esta disposição.</p>
<p>Os Componentes de Plataforma são identificados na proposta em um <strong>Component Manifest</strong>. O Component Manifest <strong>lista pelo menos todos os Componentes de Plataforma relevantes</strong> e classifica cada componente como pertencente ao § 7.1 (específico do cliente) ou ao § 7.2 (plataforma). O Component Manifest é determinante para a classificação. <strong>Alterações no Component Manifest requerem forma textual e são acordadas como aditivo à proposta ou em um Change Request.</strong> Componentes não listados no Manifest são considerados específicos do cliente na acepção do § 7.1, desde que não sejam componentes de código aberto ou de terceiros, nem já sejam utilizados como Componente de Plataforma em outros projetos de clientes; uma clarificação por aditivo permanece possível.</p>
<p>O código-fonte dos Componentes de Plataforma é <strong>informação confidencial e segredo comercial da Gosign</strong> na acepção do § 14. O cliente pode consultar o código-fonte, utilizá-lo para a finalidade contratual e transferi-lo a Terceiros Autorizados conforme § 7.1, respeitando a obrigação de repasse. Qualquer uso, transferência ou exploração além disso é inadmissível. O cliente protege o código-fonte dos Componentes de Plataforma pelo menos com a mesma diligência dispensada aos seus próprios segredos comerciais.</p>
<p>O cliente não pode utilizar os Componentes de Plataforma, incluindo código-fonte e know-how deles derivado, para o desenvolvimento, comercialização ou prestação de um produto ou serviço concorrente com a Gosign, nem para produtização para terceiros.</p>

<h3>7.3 Source Code Escrow</h3>
<p>A pedido do cliente, a Gosign deposita o código-fonte completo de todos os Componentes de Plataforma, incluindo instruções de build, Dependency Lockfiles e documentação de deployment, junto a um prestador de serviços de escrow independente. Os custos do depósito são arcados pelo cliente, salvo acordo diverso na proposta.</p>
<p>A Gosign concede ao cliente, já na celebração do contrato, sob condição suspensiva do respectivo evento de liberação, todos os direitos de uso sobre os Componentes de Plataforma, incluindo o direito de modificação, desenvolvimento e operação própria. A condição suspensiva ocorre nos seguintes casos:</p>
<p>(a) Pedido de insolvência da Gosign (abertura ou indeferimento por insuficiência de massa)</p>
<p>(b) <strong>Cessação do suporte ao produto:</strong> A Gosign deixa de fornecer atualizações de segurança para os Componentes de Plataforma utilizados dentro de 90 dias corridos após o conhecimento de uma vulnerabilidade crítica, sem oferecer uma solução sucessora equivalente dentro desse prazo, ou declara oficialmente o fim de vida (end-of-life) do componente. Vulnerabilidade crítica na acepção desta cláusula é uma falha de segurança classificada como alta ou crítica segundo padrões internacionalmente reconhecidos (em particular CVSS). Critérios adicionais podem ser acordados no contrato de escrow. Solução sucessora equivalente cobre pelo menos as funções essenciais do componente substituído e garante um nível de segurança comparável. Requisitos adicionais podem ser acordados no contrato de escrow.</p>
<p>(c) Violação substancial do contrato pela Gosign, que não seja sanada apesar de notificação por escrito com prazo de 60 dias corridos.</p>
<p>Os detalhes técnicos do depósito, atualização e liberação são regulados por um contrato de escrow separado entre a Gosign, o cliente e o prestador de serviços de escrow. Este abrange, em particular: escopo do depósito (repositório, chaves, cadeia de build, documentação, dependências), periodicidade de atualização, condições de liberação, direito de verificação do cliente e mecânica de entrega.</p>

<h3>7.4 Componentes de código aberto</h3>
<p>A Gosign utiliza software de código aberto sempre que possível. Os direitos do cliente sobre componentes de código aberto regem-se pelas condições de licença respectivas (p. ex., MIT, Apache, GPL). A Gosign fornece ao cliente uma relação dos componentes de código aberto utilizados e suas licenças (Software Bill of Materials). O cliente compromete-se a cumprir essas condições de licença. Quando código individual basear-se em componentes de código aberto e puder, portanto, estar sujeito às suas condições de licença, a Gosign informará o cliente.</p>
<p>A Gosign não utiliza componentes sob licenças copyleft (em particular GPL, AGPL), salvo se expressamente indicados na proposta e aprovados pelo cliente.</p>

<h3>7.5 Componentes reutilizáveis e isolamento de mandantes</h3>
<p>A Gosign desenvolve continuamente os Componentes de Plataforma e os utiliza em projetos para diversos clientes. Configurações específicas do cliente, segredos comerciais e dados não são transferidos para outros projetos.</p>
<p>A arquitetura técnica garante, conforme o estado da arte, por meio de isolamento de mandantes, que os dados dos clientes permanecem estritamente separados. Isso inclui, em particular, a separação no nível de dados, logs, históricos de prompts, armazenamento e chaves específicas de tenant. A Gosign documenta a arquitetura de isolamento mediante solicitação.</p>

<h3>7.6 Direito de uso limitado (alternativa para projetos de software puros)</h3>
<p>Quando na proposta não forem utilizados Componentes de Plataforma nem acordado um Component Manifest (em particular em projetos de desenvolvimento de software puros, sem uso de Decision Layer), o cliente recebe um direito de uso permanente, ilimitado territorialmente e não exclusivo sobre os desenvolvimentos individuais. O direito de uso inclui o direito de modificação e desenvolvimento para a operação comercial própria. As regras de transferência conforme § 7.1, parágrafo 3 (incluindo Terceiros Autorizados e obrigação de repasse) aplicam-se por analogia.</p>

<h3>7.7 Taxas de licença e manutenção</h3>
<p>Para resultados de trabalho específicos do cliente (§ 7.1), não há taxas de licença periódicas.</p>
<p>Para Componentes de Plataforma da Gosign (§ 7.2), aplica-se o seguinte: O direito de uso sobre a versão entregue (Perpetual License) <strong>está incluído na remuneração acordada na proposta</strong>. Taxas periódicas adicionais somente se aplicam quando expressamente indicadas na proposta.</p>
<p>Para <strong>manutenção contínua, atualizações de segurança e evolução</strong> dos Componentes de Plataforma, pode ser acordado um contrato anual de manutenção (Maintenance). Tipo, escopo, tempos de resposta e valor das taxas de manutenção são indicados de forma transparente na respectiva proposta.</p>
<p><strong>Se o cliente rescindir o contrato de manutenção, o direito de uso sobre a última versão entregue permanece integralmente em vigor.</strong> O cliente então não recebe mais atualizações, patches de segurança ou suporte técnico para os Componentes de Plataforma. A Gosign recomenda, nesse caso, a celebração de um contrato de Source Code Escrow conforme § 7.3.</p>
<p>Sem acordo expresso na proposta, não há taxas periódicas.</p>

<h3>7.8 Modificações do cliente em Componentes de Plataforma</h3>
<p>O cliente tem o direito de modificar os Componentes de Plataforma para sua operação comercial própria. A Gosign fornece, quando possível, pontos de extensão documentados (Extension Points) que permitem alterações sem intervenção no núcleo da plataforma.</p>
<p>Se o cliente realizar alterações nos Componentes de Plataforma <strong>fora dos Extension Points documentados</strong>, a garantia e o direito a suporte para as partes afetadas ficam suspensos até que (a) as alterações sejam revertidas ou (b) a Gosign realize uma análise remunerada e confirme a compatibilidade.</p>
<p><strong>O cliente coopera, na medida do razoável, para que atualizações de segurança da Gosign possam ser aplicadas mesmo com modificações existentes do cliente.</strong> Se o cliente recusar a cooperação necessária ou se suas modificações bloquearem a aplicação de uma atualização de segurança, a Gosign tem o direito de suspender o suporte para os componentes afetados até a resolução do bloqueio. Considera-se bloqueio quando a atualização não pode ser aplicada com esforço razoável porque alterações do cliente fora dos Extension Points comprometem a compatibilidade.</p>
<p>As obrigações de segurança do cliente conforme § 9 não são afetadas pelas modificações.</p>

<h3>7.9 Contribuições do cliente para Componentes de Plataforma</h3>
<p>Quando previsto na proposta ou em acordo separado, o cliente pode submeter correções de erros, sugestões de melhoria ou extensões para Componentes de Plataforma ("Contribuições").</p>
<p>O cliente concede à Gosign sobre tais Contribuições um direito de uso simples, não exclusivo, ilimitado territorial e temporalmente, na medida em que as Contribuições se refiram a Componentes de Plataforma e não contenham segredos comerciais ou configurações específicas do cliente. A Gosign pode incorporar essas Contribuições aos Componentes de Plataforma e disponibilizá-las a todos os clientes.</p>
<p>Esta cláusula não obriga o cliente a submeter Contribuições.</p>

<h3>7.10 Momento da entrega</h3>
<p>A entrega dos resultados de trabalho (incluindo repositório de código-fonte, documentação, Component Manifest, configurações e Software Bill of Materials) ocorre no mais tardar com a aceitação da última fase do projeto e o pagamento integral. A Gosign apoiará ativamente a entrega e concederá ao cliente acesso completo.</p>

<h2>§ 8 Hosting e serviços operacionais</h2>
<p>A operação regular das soluções desenvolvidas pela Gosign ocorre na infraestrutura do cliente. O hosting pela Gosign é um serviço adicional opcional. Quando o cliente utilizar hosting, aplicam-se as seguintes condições:</p>
<p><strong>Managed Services na infraestrutura do cliente:</strong> Quando a Gosign operar a solução no ambiente cloud do cliente, as disposições de hosting aplicam-se por analogia. A responsabilidade pela infraestrutura base permanece com o cliente. A Gosign é responsável pela camada de aplicação.</p>
<p><strong>Centro de dados:</strong> O hosting ocorre na Alemanha ou na UE, salvo acordo em contrário. As preferências do cliente devem ser comunicadas na celebração do contrato.</p>
<p><strong>Disponibilidade:</strong> Sem SLA, não há garantia de disponibilidade mínima. A Gosign almeja alta disponibilidade.</p>
<p><strong>Janelas de manutenção:</strong> Manutenção planejada fora do horário comercial com aviso prévio.</p>
<p><strong>Backup:</strong> Backup diário com retenção rotativa de 7 dias, salvo acordo em contrário.</p>
<p><strong>Transição e saída:</strong> Após o término dos serviços de hosting, a Gosign apoia o cliente por até 90 dias na migração (Transition). A Transition é remunerada conforme esforço. Todos os dados do cliente são integralmente exportáveis em formatos padrão.</p>

<h2>§ 9 Segurança, manutenção e atualizações</h2>
<p><strong>Atualizações de segurança obrigatórias:</strong> A Gosign pode instalar atualizações de segurança sem consentimento prévio do cliente quando a demora comprometer a segurança. O cliente é informado posteriormente.</p>
<p><strong>Dever de tolerância:</strong> O cliente não pode recusar atualizações de segurança. A segurança e integridade do sistema têm prioridade.</p>
<p><strong>Recusa:</strong> Em caso de recusa de uma medida de segurança, a Gosign pode suspender os serviços. Excluem-se reclamações do cliente por danos resultantes.</p>
<p><strong>Atualizações opcionais:</strong> Atualizações não relacionadas à segurança somente mediante acordo.</p>
<p><strong>Testes de penetração:</strong> O cliente pode realizar auditorias de segurança ou testes de penetração com aviso prévio de pelo menos 14 dias corridos, desde que a confidencialidade seja garantida. Detalhes podem ser regulados em um SLA.</p>
<p><strong>Resposta a incidentes:</strong> Em caso de incidente de segurança que afete a disponibilidade, integridade ou confidencialidade dos dados ou sistemas do cliente, a Gosign informa o cliente sem demora injustificada, no máximo em 24 horas após tomar conhecimento, e adota medidas imediatas de contenção. A notificação inicial e as medidas imediatas fazem parte do serviço contratual. Serviços adicionais (em particular, análise forense, determinação da causa raiz e elaboração de relatório detalhado de incidente) são remunerados conforme esforço, salvo se o incidente for atribuível à Gosign. Quando a Gosign for responsável pelo incidente, todas as medidas de análise e remediação são fornecidas ao cliente sem custo.</p>

<h2>§ 10 Remuneração e condições de pagamento</h2>
<p>Os preços constam da proposta, acrescidos do IVA aplicável.</p>
<p>Faturamento por tempo e materiais ou preço fixo conforme acordado.</p>
<p>Despesas acessórias e de viagem somente mediante aprovação prévia.</p>
<p><strong>Prazo de pagamento:</strong> 14 dias corridos, salvo acordo em contrário. Prazos de pagamento individuais podem ser acordados. Juros de mora: 9 pontos percentuais acima da taxa de juros básica (§ 288, parágrafo 2, BGB).</p>
<p>Pagamentos parciais em projetos de maior duração conforme o plano de marcos.</p>
<p>Compensação somente com créditos incontroversos ou judicialmente estabelecidos.</p>

<h2>§ 11 Responsabilidade</h2>
<p><strong>Ilimitada:</strong> Por dolo, culpa grave, lesão à vida/corpo/saúde, garantia, responsabilidade pelo produto.</p>
<p><strong>Obrigações cardinais:</strong> Por culpa leve, limitada ao dano tipicamente previsível.</p>
<p><strong>Limite máximo de responsabilidade:</strong> A responsabilidade da Gosign por danos decorrentes de violação de obrigações cardinais é limitada, por evento danoso, ao valor da remuneração líquida acordada no contrato individual afetado. A responsabilidade total da Gosign em uma relação contratual é limitada ao dobro da remuneração líquida anual. Limites máximos de responsabilidade diferentes podem ser acordados em contratos individuais.</p>
<p><strong>Danos indiretos, consequenciais e lucros cessantes:</strong> Excluídos, salvo dolo, culpa grave ou violação de obrigações cardinais.</p>
<p><strong>Perda de dados:</strong> Responsabilidade apenas pelo custo de restauração a partir dos backups adequados do cliente.</p>
<p><strong>Resultados de IA:</strong> Sem responsabilidade por decisões baseadas em resultados de IA, desde que a Gosign não tenha violado obrigações cardinais (ver § 6.2).</p>
<p><strong>Seguro:</strong> A Gosign mantém seguro de responsabilidade civil profissional e empresarial conforme o mercado. Comprovação disponível mediante solicitação.</p>
<p><strong>Prescrição:</strong> Dois anos; não aplicável em caso de dolo, culpa grave ou danos pessoais.</p>

<h2>§ 12 Reclamações por defeitos (garantia)</h2>
<p><strong>Prazo de garantia:</strong> 12 meses a partir da aceitação para defeitos de qualidade e de título.</p>
<p>Os defeitos devem ser comunicados sem demora em forma textual. Correção mediante reparo ou substituição.</p>
<p>Fracasso após duas tentativas: Redução do preço ou resolução do contrato.</p>
<p>Sem garantia por desvios insignificantes ou perturbações causadas pelo cliente.</p>
<p>Erros em software de código aberto ou de terceiros não constituem defeito dos serviços da Gosign, desde que corretamente integrados.</p>
<p>A garantia para Componentes de Plataforma está sujeita às restrições do § 7.8 (modificações do cliente).</p>
<p>Em relações contratuais de trato sucessivo: Aplicam-se as disposições legais para contratos de serviço/locação.</p>

<h2>§ 13 Proteção de dados e tratamento de dados</h2>
<p>Ambas as partes cumprem o RGPD (Regulamento Geral de Proteção de Dados da UE), a Lei Federal alemã de Proteção de Dados (BDSG) e demais legislação de proteção de dados aplicável.</p>
<p>Na medida em que o cliente trate dados sujeitos à LGPD (PT: RGPD) brasileira (Lei Geral de Proteção de Dados - Lei nº 13.709/2018) ou a outras legislações internacionais de proteção de dados, a Gosign apoia o cumprimento dessas obrigações.</p>
<p>A Gosign atua como operador de dados (Art. 28 RGPD). As partes celebrarão um contrato de tratamento de dados (AVV/DPA).</p>
<p>A Gosign aceita também contratos de tratamento de dados fornecidos pelo cliente, desde que conformes com o RGPD.</p>
<p>A Gosign implementa medidas técnicas e organizacionais adequadas (Art. 32 RGPD).</p>
<p>Suboperadores com consentimento geral, desde que contratualmente vinculados a um nível equivalente de proteção de dados.</p>
<p><strong>Data Residency:</strong> Mediante solicitação, garantia contratual de que o tratamento de dados ocorre exclusivamente na Alemanha ou em um Estado-membro determinado da UE/EEE. Em caso de chamadas de API de IA a países terceiros, informação prévia e - quando tecnicamente viável - endpoints europeus.</p>
<p>Em caso de violações de dados: Notificação imediata e cooperação nas obrigações de comunicação.</p>

<h2>§ 14 Confidencialidade</h2>
<p>Ambas as partes tratam informações confidenciais com estrita confidencialidade.</p>
<p><strong>Exceções:</strong> Publicamente conhecidas, previamente conhecidas, desenvolvidas independentemente, obrigação legal.</p>
<p><strong>Divulgação:</strong> Apenas com critério de necessidade de conhecimento (need-to-know), a funcionários sujeitos a obrigações de confidencialidade.</p>
<p><strong>Padrão de proteção:</strong> Ambas as partes protegem informações confidenciais pelo menos como seus próprios segredos comerciais, porém no mínimo por meio de medidas técnicas e organizacionais adequadas conforme o estado da arte.</p>
<p><strong>Duração:</strong> 5 anos após o término do contrato. Para informações identificadas como segredos comerciais (em particular conforme § 7.2, parágrafo 5), a obrigação de confidencialidade persiste para além do prazo contratual.</p>
<p><strong>Devolução e destruição:</strong> Mediante solicitação, no mais tardar com o término do contrato.</p>
<p><strong>Uso como referência:</strong> A Gosign somente poderá utilizar o nome e logotipo do cliente como referência com o consentimento prévio por escrito do cliente.</p>

<h2>§ 15 Duração do contrato e rescisão</h2>
<p>15.1 Contratos de projeto encerram-se com a aceitação da última entrega e o pagamento integral.</p>
<p>15.2 Relações contratuais de trato sucessivo: Prazo mínimo de 12 meses. Após, renovação automática por períodos de 12 meses, com possibilidade de rescisão com aviso prévio de 3 meses para o final do período em curso.</p>
<p>15.2a Para contratos de manutenção conforme § 7.7 (Maintenance), aplicam-se as disposições para relações de trato sucessivo do parágrafo 2 por analogia, salvo se prazos e períodos de aviso prévio divergentes forem acordados no contrato de manutenção.</p>
<p>15.3 Rescisão extraordinária em caso de: (a) violação substancial de obrigações após prazo de correção de 30 dias; (b) insolvência; (c) recusa persistente de atualizações (§ 9); (d) uso ilícito do sistema.</p>
<p>15.4 Consequências do término: Devolução/eliminação de todos os dados do cliente. Transição conforme § 8. Direitos de uso adquiridos permanecem em vigor após pagamento integral.</p>

<h2>§ 16 Conformidade, certificações e representação dos trabalhadores</h2>
<p><strong>16.1 Cert-Ready:</strong> A Gosign projeta suas soluções para atender aos pré-requisitos técnicos para certificações padrão do setor (Cert-Ready by Design). Concretamente: os Controls são implementados como objetos de dados de primeira classe no sistema, a Evidence é gerada automaticamente, o Audit Trail é completo e exportável, e o acesso por meio de um Auditor Portal está previsto. A obtenção de um certificado específico não é um resultado contratual obrigatório e requer acordo separado entre cliente, auditor e Gosign.</p>
<p><strong>16.2 Representação dos trabalhadores e cogestão:</strong> Na medida em que soluções de IA forem implantadas em áreas sujeitas à participação dos trabalhadores conforme o direito alemão (§ 87, parágrafo 1, nº 6, BetrVG - a Lei da Constituição das Empresas alemã concede aos conselhos de trabalhadores direitos de participação relativos a sistemas técnicos que monitoram comportamento ou desempenho dos empregados; no Brasil, a representação dos trabalhadores é exercida por sindicatos e, para questões de segurança no trabalho, pela CIPA), a Gosign apoia na preparação de documentação e materiais informativos para o conselho de trabalhadores. A inclusão formal do conselho de trabalhadores e a celebração de acordos coletivos são de responsabilidade do cliente. A arquitetura do Decision Layer é projetada para implementar acordos coletivos como regras configuráveis e tecnicamente executáveis.</p>
<p><strong>16.3 Conformidade com sanções:</strong> A Gosign confirma que não mantém relações comerciais com pessoas, entidades ou estados sancionados.</p>
<p><strong>16.4 Sustentabilidade:</strong> A Gosign considera aspectos de eficiência energética na seleção de infraestrutura. Informações disponíveis mediante solicitação.</p>

<h2>§ 17 Controle de exportação</h2>
<p>O cliente cumpre as normas de exportação e sanções. A Gosign sinaliza componentes sujeitos a controle de exportação. A execução está condicionada à inexistência de impedimentos legais.</p>

<h2>§ 18 Força maior</h2>
<p>Sem responsabilidade por inadimplemento devido a força maior (catástrofes naturais, guerra, pandemias, conflitos trabalhistas, medidas governamentais, falhas de infraestrutura em larga escala). Notificação imediata. Prazos estendem-se proporcionalmente. Direito de resolução após 3 meses.</p>

<h2>§ 19 Disposições finais</h2>
<p><strong>Direito aplicável:</strong> Direito alemão, com exclusão da Convenção das Nações Unidas sobre Contratos de Compra e Venda Internacional de Mercadorias (CISG).</p>
<p><strong>Foro competente:</strong> Hamburgo, Alemanha (para comerciantes e pessoas jurídicas).</p>
<p><strong>Idioma do contrato:</strong> Alemão. Versões em outros idiomas servem à cooperação internacional; em caso de dúvida, prevalece a versão alemã.</p>
<p><strong>Versionamento:</strong> Estes TCG possuem número de versão e data. A versão vigente está disponível em gosign.de/de/agb/.</p>
<p>Alterações em forma textual. Alterações nos TCG com 6 semanas de antecedência; prazo de oposição de 4 semanas.</p>
<p><strong>Cessão:</strong> Cessão somente com consentimento por escrito. A transferência a Terceiros Autorizados e sucessores jurídicos conforme § 7.1, parágrafo 3, não é afetada por esta disposição.</p>
<p>Cláusula de salvaguarda. Prevalência dos acordos individuais.</p>

--- a21glossary TYPO3 - Glossário técnico | Gosign ---
> Extensão de glossário para TYPO3: Definir termos, vincular automaticamente no conteúdo, exibir como tooltip.

## Quem precisa de um glossário geralmente tem um problema de SEO

Explicar termos técnicos em um site parece um serviço ao usuário. Na prática, a21glossary resolve um problema técnico concreto: páginas TYPO3 com conteúdo que exige explicações ranqueiam melhor quando os termos são vinculados internamente, indexáveis como páginas próprias e acessíveis via tooltip. A extensão gera, a partir de um banco de termos centralizado, links automáticos no conteúdo, sem que os editores precisem criar cada link manualmente.

Para empresas com portais especializados, plataformas de conhecimento ou produtos que demandam explicação, a21glossary cria exatamente a estrutura de links internos que o Google interpreta como autoridade temática. Em vez de esconder 50 termos em uma FAQ, surgem 50 páginas independentes e indexáveis com potencial de Schema Markup.

## Cenários típicos de uso

**Portais especializados com mais de 100 termos.** Associações setoriais, universidades e editoras técnicas mantêm glossários com centenas de entradas. a21glossary vincula automaticamente cada termo na primeira ocorrência no texto corrido. Em um cliente com 340 entradas de glossário, a densidade de links internos aumentou 28%, mensurável via Google Search Console.

**Páginas de produtos com vocabulário técnico.** Fabricantes de máquinas, empresas químicas e fabricantes de tecnologia médica utilizam linguagem especializada que compradores e decisores nem sempre conhecem. Um tooltip com 2 a 3 frases de explicação mantém o leitor na página, em vez de enviá-lo ao Google. O tempo de permanência aumenta, a taxa de rejeição diminui.

**Plataformas de conhecimento multilíngues.** Em combinação com o gerenciamento de idiomas do TYPO3, glossários podem ser mantidos por idioma. Termos em português vinculam a explicações em português, termos em inglês a explicações em inglês. Funciona corretamente desde que a configuração de idiomas no TYPO3 esteja bem implementada.

## Arquitetura técnica

a21glossary funciona como um pós-processador de conteúdo. Após a renderização de uma página TYPO3, a extensão percorre o output HTML em busca de termos definidos e os substitui por variantes com links. Os termos são armazenados em uma tabela própria no banco de dados e gerenciados por um módulo no backend.

A extensão se registra via um Content Object Post User Func Hook no processo de renderização TypoScript. Isso significa que ela só intervém depois que o TYPO3 renderizou completamente o conteúdo. Por isso funciona independentemente do tipo de elemento de conteúdo utilizado, seja Textmedia, News ou Custom Content Elements.

A exibição do tooltip é feita por um pequeno snippet JavaScript e CSS. Ambos são personalizáveis. Em configurações modernas do TYPO3, recomenda-se substituir o JavaScript padrão por uma solução CSS-only para não prejudicar os Core Web Vitals. Com o atributo `title` e um seletor `:hover`, tooltips simples podem ser criados sem nenhuma linha de JavaScript.

As entradas do glossário são configuráveis via TypoScript: quais páginas devem ser percorridas, quantas vezes um termo pode ser vinculado por página (recomendado: uma vez) e quais áreas HTML são excluídas (navegação, footer, outras entradas de glossário).

## Problemas frequentes e soluções

**Queda de performance em glossários grandes.** A partir de cerca de 500 termos, o passo de pós-processamento pode se tornar perceptível, especialmente em páginas com muito texto. A solução: ativar o cache. O cache de páginas do TYPO3 armazena o resultado após a primeira renderização. Apenas na limpeza do cache ocorre novo processamento. Adicionalmente, ajuda reduzir a lista de termos ao vocabulário efetivamente utilizado. 200 termos precisos superam 800 incluindo variantes.

**Links incorretos em títulos e links existentes.** a21glossary vincula por padrão em todos os lugares, inclusive dentro de tags H2 ou hiperlinks existentes. Isso resulta em links aninhados que são HTML inválido. Através da configuração TypoScript, tags podem ser excluídas: `excludeTags = h1,h2,h3,a,script`. Essa configuração pertence a toda primeira instalação.

**Conflitos com RealURL e roteamento.** Em versões mais antigas do TYPO3 (antes da v9), havia problemas quando páginas de detalhe do glossário eram roteadas via RealURL. Com TYPO3 v10+ e o Site Routing nativo, esse problema não existe mais. Quem ainda usa RealURL deveria migrar de qualquer forma.

## Migração e compatibilidade de versões

a21glossary foi originalmente desenvolvida para TYPO3 v4.x e atualizada ao longo dos anos. A última versão mantida ativamente no TER suporta TYPO3 v10 e v11. Para TYPO3 v12 existe um fork comunitário no GitHub que porta a extensão para a nova estrutura TCA e o sistema de hooks alterado. Para TYPO3 v13, não há versão oficial disponível no momento.

A migração de v11 para v12 requer três ajustes: primeiro, a mudança de `$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']` para o novo sistema Event-Dispatcher; segundo, a atualização das definições TCA (configuração de Wizard); e terceiro, a adaptação do setup TypoScript à nova configuração de Site.

Quem planeja migrar para TYPO3 v13 enfrenta uma decisão: continuar desenvolvendo o fork comunitário ou mudar para uma solução alternativa. Como alternativa, é possível implementar a funcionalidade de glossário diretamente como Custom Content Element com DataProcessor. O esforço é de aproximadamente 2 a 3 dias de desenvolvimento, o resultado é à prova de futuro e independente de manutenção de terceiros. A Gosign realizou essa migração em diversos projetos e pode estimar realisticamente o esforço real com base na análise dos dados de glossário existentes.
---

--- aimeos TYPO3 - Loja virtual | Gosign ---
> aimeos: Professioneller Online-Shop no TYPO3. Configuração, personalização e migração , acelerada com IA desenvolvimento.

## Quem precisa de loja no TYPO3 dificilmente escapa do aimeos

Empresas que já possuem um site TYPO3 e querem adicionar e-commerce enfrentam uma questão fundamental: sistema de loja separado (Shopware, Magento, WooCommerce) com interface ao CMS, ou um framework de e-commerce nativo dentro do TYPO3? aimeos é a segunda opção e há mais de 10 anos o framework de loja TYPO3 mais estabelecido. Mais de 200.000 instalações mundiais (dados: Packagist, 2026), desenvolvimento ativo e suporte para TYPO3 v12 e v13 demonstram estabilidade.

A vantagem decisiva: conteúdo e comércio rodam no mesmo sistema. Páginas de produto utilizam elementos de conteúdo TYPO3, landing pages podem incorporar componentes de loja, editores trabalham em uma única interface. Com sistemas separados surgem problemas de sincronização, manutenção duplicada e design inconsistente.

## Cenários típicos de uso

**Lojas B2B com lógica de preços complexa.** Empresas industriais com preços específicos por cliente, descontos por volume, quantidades mínimas de pedido e workflows de aprovação. aimeos suporta nativamente preços por grupo de clientes, plugins de preço e regras. Um distribuidor químico com 8.000 artigos e 400 grupos de clientes pode ser modelado sem que cada regra de preço seja hardcodada.

**Marketplaces e cenários multi-vendedor.** aimeos pode funcionar como backend de marketplace, onde múltiplos fornecedores cadastram seus produtos. Cada vendor gerencia seu sortimento, a plataforma cuida de checkout, pagamento e roteamento de envio. O framework suporta setups multi-loja, onde diferentes storefronts acessam o mesmo catálogo mas exibem sortimentos e preços diferentes.

**Internacionalização desde o dia 1.** Empresas com sites em 5 ou mais idiomas e múltiplas moedas se beneficiam do suporte nativo a multi-idioma e multi-moeda do aimeos. Nomes de produtos, descrições e metadados SEO podem ser mantidos por idioma. Preços podem ser definidos por moeda ou convertidos automaticamente.

## Arquitetura técnica

aimeos é baseado em uma arquitetura MVC própria (Manager, Controller, Client), integrada ao TYPO3 como extensão. O núcleo é agnóstico de framework e roda também em Laravel e Slim. A camada adaptadora TYPO3 garante que plugins aimeos sejam incorporados como elementos de conteúdo TYPO3.

O catálogo de produtos utiliza uma estrutura em árvore com aninhamento de profundidade arbitrária. Atributos (cor, tamanho, material) são gerenciados como entidades próprias e exibidos via filtros de facetas. A busca é baseada por padrão em pesquisa de texto completo SQL, mas pode ser alternada para Elasticsearch ou Solr.

Integrações de pagamento funcionam via service providers: Stripe, PayPal, Mollie, Amazon Pay, Klarna e outros estão disponíveis como plugins. Cada provider de pagamento é acessado via API unificada. O processo de checkout é implementado como pipeline de etapas e expansível com etapas próprias (como verificação de idade, aprovação B2B).

Cache ocorre em múltiplos níveis: TYPO3 Page Cache para páginas estáticas, cache interno aimeos para consultas de catálogo e opcionalmente Varnish ou Cloudflare como reverse proxy. Em catálogos com mais de 100.000 artigos, o gerenciamento de índices é decisivo: aimeos cria índices de busca e preço que são atualizados incrementalmente nas atualizações de produtos.

## Problemas frequentes e soluções

**Quedas de performance em catálogos grandes.** Lojas com mais de 50.000 artigos ficam lentas quando os índices não estão atualizados ou o cache do catálogo foi desativado. Solução: `php typo3/sysext/core/bin/typo3 aimeos:jobs` como cronjob (a cada 5 minutos para atualizações de índice, a cada hora para tarefas de limpeza). Limpar o cache administrativo aimeos manualmente após importações em massa.

**Abandonos de checkout por erros de pagamento.** Causa frequente: chaves de API desatualizadas ou URLs de webhook incorretas após mudança de domínio. Cada provider de pagamento precisa de uma URL de notificação correta, por onde confirmações de pagamento chegam de forma assíncrona. Solução: verificar URLs de webhook no painel do provider após cada mudança, realizar pedidos de teste em modo sandbox.

**Conflitos com cache TYPO3.** Páginas aimeos com carrinho ou login não devem ser armazenadas no Page Cache TYPO3. Solução: marcar as páginas relevantes como USER_INT ou operar aimeos no modo SPA (baseado em AJAX). Desde aimeos 2024.x, o modo SPA é recomendado como padrão.

## Migração e compatibilidade de versões

aimeos suporta TYPO3 v12 LTS completamente e TYPO3 v13 desde aimeos 2024.x. Para TYPO3 v11 existem releases de manutenção, mas sem novos recursos.

Migração de outros sistemas de loja é um cenário realista. De Shopware, WooCommerce ou tt_products, é possível transferir produtos, categorias, contas de clientes e histórico de pedidos para aimeos. A Gosign utiliza pipelines de importação CSV/XML, onde dados de produtos são transformados e mapeados na estrutura aimeos. Dependendo da qualidade dos dados, a migração de uma loja com 5.000 produtos leva entre 3 e 10 dias.

Um setup aimeos com catálogo de produtos, carrinho, pagamento Stripe e PayPal, cálculo de frete e templates básicos é calculado pela Gosign com 15 a 25 dias de desenvolvimento. Temas personalizados, lógica de preços complexa ou funcionalidades de marketplace aumentam o esforço proporcionalmente. A operação contínua requer atualizações regulares (aimeos e plugins de pagamento) bem como monitoramento de performance do checkout e taxa de conversão. Patches de segurança para aimeos e plugins de pagamento devem ser aplicados dentro de 48 horas, pois sistemas de loja com dados de pagamento são alvos preferenciais de ataques.

--- Amazon Pay TYPO3 - Payment | Gosign ---
> Amazon Pay no TYPO3: Checkout mit Amazon-Konto. API-Integração, Zertifizierung, acelerado com IA.

## Amazon Pay reduz abandonos de compra porque clientes não precisam criar conta nova

Milhões de compradores online possuem uma conta Amazon. Quando esses usuários clicam em "Comprar" em uma loja TYPO3 e veem um formulário de cadastro com 12 campos obrigatórios, muitos desistem. Amazon Pay resolve esse problema: o cliente se autentica com sua conta Amazon, endereço de entrega e forma de pagamento são transferidos automaticamente. Sem formulário, sem número de cartão de crédito, sem nova senha. Segundo case studies da própria Amazon, a taxa de conversão aumenta entre 15 e 30%, dependendo do setor e da qualidade do checkout existente.

Para operadores de lojas TYPO3, a integração não é plug-and-play. Amazon Pay requer conexão via API (Login with Amazon, Amazon Pay API v2), uma implementação certificada e atualizações de segurança regulares. A Amazon verifica cada integração antes do go-live.

## Cenários típicos de uso

**Lojas B2C de médio porte com aimeos.** Lojas online de moda, eletrônicos, utilidades domésticas que querem oferecer uma terceira forma de pagamento além de PayPal e cartão de crédito. Amazon Pay funciona especialmente bem em compras impulsivas abaixo de 200 euros, onde cada obstáculo no checkout custa faturamento diretamente. A integração no aimeos ocorre via service provider próprio, inserido na pipeline de pagamento.

**Plataformas de doações e mensalidades.** Associações e ONGs que arrecadam doações ou cobram mensalidades pelo site TYPO3 se beneficiam da baixa barreira de entrada. O doador clica em "Pagar com Amazon", confirma o valor e pronto. Sem digitar IBAN, sem configurar débito automático. Para pagamentos recorrentes, Amazon Pay suporta Recurring Payments.

**Produtos digitais e downloads.** Licenças de software, e-books, cursos online - produtos sem envio físico se beneficiam especialmente, porque todo o processo de compra é concluído em menos de 30 segundos. Sem necessidade de endereço de entrega, apenas autenticação e pagamento.

## Arquitetura técnica

Amazon Pay v2 é baseado em uma API REST com payloads JSON. O fluxo em uma loja TYPO3: o cliente clica no botão Amazon Pay, é redirecionado para a Amazon (ou um popup se abre), faz login e confirma endereço e forma de pagamento. A Amazon envia um Access Token de volta para a loja. A loja cria uma Checkout Session via Amazon Pay API, onde dados do carrinho e detalhes do pedido são armazenados. Após confirmação pelo cliente, o pagamento é acionado.

A integração no TYPO3 requer três componentes: um cliente API (requests HTTP para a Amazon Pay API com assinatura via chave RSA), um componente frontend (botão Amazon Pay como widget JavaScript) e um handler de webhook para notificações assíncronas (confirmação de pagamento, reembolso, chargeback).

Para aimeos existe um plugin da comunidade que cobre as funções básicas. Para tt_products ou lojas personalizadas, é necessária uma integração própria. Em ambos os casos, a loja TYPO3 deve usar HTTPS (obrigatório desde Amazon Pay v2), e a URL de webhook deve ser acessível externamente.

A Amazon disponibiliza um ambiente sandbox onde todos os fluxos de pagamento podem ser testados sem dinheiro real.

## Problemas frequentes e soluções

**Certificação falha na primeira tentativa.** A Amazon verifica antes do go-live se a integração funciona corretamente: posicionamento do botão, tratamento de erros em pagamentos recusados, exibição em dispositivos móveis, cancelamento correto. Erros frequentes: o botão Amazon Pay não aparece na página do produto (apenas no carrinho), mensagens de erro em pagamentos recusados faltam ou estão em inglês. Solução: trabalhar completamente o checklist de integração da Amazon antes de solicitar a verificação.

**Notificações IPN (Instant Payment Notifications) se perdem.** A Amazon envia confirmações de pagamento assincronamente via POST para uma URL registrada. Se o TYPO3 bloqueia esses requests por cache, regras de redirect ou exceções CSRF ausentes, o pedido permanece no status "pendente". Solução: configurar uma rota eID dedicada ou rota middleware para o webhook, que rode fora do processamento normal de requests TYPO3.

**Recurring Payments e modelos de assinatura.** Amazon Pay suporta pagamentos recorrentes, mas a configuração é mais complexa que Stripe Subscriptions. O cliente deve consentir explicitamente a um Billing Agreement, e a loja deve enviar Authorize-Requests regularmente. Solução: gerenciar Billing Agreements como entidade de banco de dados própria e configurar um cronjob que aciona pagamentos devidos.

## Migração e compatibilidade de versões

Amazon Pay v2 é a versão atual da API (desde 2021). A versão 1 não é mais aceita para novas integrações desde o final de 2023. Implementações v1 existentes ainda funcionam, mas não recebem atualizações nem novos recursos. A migração de v1 para v2 afeta todo o cliente API: outros endpoints, outro mecanismo de assinatura (RSA em vez de HMAC), outro gerenciamento de sessão.

Para TYPO3 não existe uma extensão oficial Amazon Pay no TER com suporte ativo v12/v13. A integração ocorre como código personalizado ou via plugins da comunidade para aimeos. A Gosign implementa Amazon Pay como pacote Composer independente, que pode ser integrado em qualquer setup de loja TYPO3. Este pacote encapsula o cliente API, o botão e o handler de webhook, de modo que um upgrade TYPO3 major afeta apenas a camada adaptadora específica do TYPO3.

Os custos totais de uma integração Amazon Pay em uma loja TYPO3 existente ficam entre 3 e 8 dias de desenvolvimento, dependendo se um plugin aimeos pode ser utilizado ou se uma integração personalizada é necessária. A certificação Amazon requer adicionalmente 1 a 2 dias para preparação e rodadas de correção.

--- Angular & TYPO3 - Headless CMS | Gosign ---
> Angular-Frontend mit TYPO3: Headless CMS, JSON-API, SPA-Integração. acelerada com IA desenvolvimento.

## Por que o Angular funciona com o TYPO3, mas a maioria das configurações falha

A ideia é convincente: TYPO3 entrega conteúdo como JSON, Angular renderiza o frontend como Single Page Application. Editores trabalham no backend familiar do TYPO3, desenvolvedores constroem um frontend moderno sem restrições de TypoScript. Na prática, muitos projetos Angular-TYPO3 falham na fronteira arquitetural entre CMS e SPA. A extensão oficial TYPO3 Headless (EXT:headless) resolve o problema de entrega de conteúdo. Mas roteamento, preview, SEO e cache precisam de soluções elaboradas que vão além de um simples `ng serve`.

Angular como frontend para TYPO3 é adequado para empresas que precisam de conteúdo multi-canal: um site, um app, um portal de intranet e digital signage a partir de uma única fonte de conteúdo. O investimento se paga a partir do segundo canal. Para sites puros sem ambição de app, uma configuração clássica TYPO3-Fluid é quase sempre mais eficiente.

## Cenários típicos de uso

**Plataformas multi-canal com app e web.** Um fornecedor automotivo mantém dados de produtos, informações de serviço e notícias no TYPO3. O site roda como SPA Angular, o app de serviço para técnicos usa a mesma API JSON. Alterações no TYPO3 aparecem em ambos os canais simultaneamente. O conteúdo é mantido uma vez, entregue duas vezes.

**Portais de intranet com interação complexa.** Dashboards de RH, plataformas de gestão de conhecimento e ferramentas internas se beneficiam da abordagem baseada em componentes do Angular. TYPO3 entrega conteúdo estruturado (políticas, manuais, organogramas), Angular renderiza views interativas com filtros, busca e atualizações em tempo real. A autenticação roda via LDAP/SSO existente, TYPO3 verifica permissões via fe_group.

**Configuradores e páginas de produto interativas.** Fabricantes de produtos configuráveis utilizam Angular para a visualização 3D ou o configurador. Os dados mestres de produto vêm do TYPO3, a lógica de configuração vive no frontend Angular. Em um cliente com 1.200 variantes configuráveis, essa abordagem reduziu o tempo de carregamento da página do configurador de 4,2 para 1,1 segundos.

## Arquitetura técnica

A extensão TYPO3 Headless transforma a saída padrão de HTML em JSON. Cada elemento de conteúdo, cada navegação, cada nível de breadcrumb é entregue como objeto JSON. Angular consome essa API via serviços HttpClient.

A arquitetura consiste em três camadas. TYPO3 como backend entrega conteúdo pela API Headless em `/api/`. Angular como aplicação frontend é compilado como processo de build próprio (`ng build --prod`) e tipicamente servido via CDN ou servidor web separado. Entre eles fica um servidor SSR baseado em Node.js (Angular Universal), que cuida do Server-Side Rendering para SEO e redes sociais.

O roteamento é dividido: Angular Router cuida da navegação client-side, TYPO3 define a estrutura de URLs via Site Configuration. Ambos devem permanecer sincronizados. Na prática, isso significa: quando um editor cria uma nova página no TYPO3, Angular precisa conhecer essa URL. A solução é um roteamento dinâmico no frontend Angular que consulta a estrutura de páginas da API TYPO3 a cada build.

Serviços TypeScript são gerados a partir dos tipos de conteúdo TYPO3. Para cada Content Element existe um componente Angular com tipagem. Esses tipos podem ser gerados via script a partir da API TYPO3, garantindo o alinhamento entre backend e frontend.

## Problemas frequentes e soluções

**Deficiências de SEO por renderização apenas client-side.** O Google renderiza JavaScript, mas não de forma confiável e não imediatamente. Sem Server-Side Rendering (Angular Universal ou Angular SSR desde v17), páginas são indexadas tardiamente ou nunca. A solução: usar Angular Universal como camada SSR. A resposta HTML inicial deve estar completamente renderizada antes que o processo de hydration client-side assuma.

**Preview de conteúdo no backend TYPO3 não funciona.** Editores clicam em "Preview" e veem JSON em vez de uma página renderizada. A solução: configurar um proxy de preview que redireciona a resposta JSON para uma instância Angular de preview dedicada. EXT:headless oferece um modo de preview que entrega conteúdo draft via parâmetro de token.

**Problemas de CORS entre API TYPO3 e frontend Angular.** Quando TYPO3 e Angular rodam em domínios diferentes, o navegador bloqueia as requisições à API. A extensão EXT:cors ou um reverse proxy server-side resolve esse problema. Recomendado: operar ambos sob o mesmo domínio (TYPO3 em `/api/`, Angular em `/`).

## Migração e compatibilidade de versões

EXT:headless é oficialmente compatível com TYPO3 v11, v12 e v13. A extensão é mantida ativamente e segue o ciclo de release do TYPO3. Angular tem seu próprio ritmo de release: a cada 6 meses uma nova versão major. Desde Angular v17, SSR está integrado nativamente (sem necessidade de pacote Angular Universal separado).

Para projetos Angular-TYPO3 existentes em TYPO3 v10 ou anterior, recomenda-se uma migração gradual: primeiro atualizar TYPO3 para v12 ou v13, depois Angular para a versão LTS atual (v18). A interface de API da EXT:headless mudou em vários pontos entre v2 e v4, especialmente no tratamento de overlays de idioma e previews de workspace.

O esforço para um projeto Angular-TYPO3 é tipicamente 30-50% acima de um projeto Fluid puro. Esse esforço adicional é recuperado pelo segundo canal (app, intranet). A Gosign orienta antes do início do projeto se Headless é a abordagem correta ou se uma configuração clássica com ilhas JavaScript direcionadas atinge o mesmo objetivo.
---

--- Amazon S3 TYPO3 - Armazenamento em nuvem FAL | Gosign ---
> Amazon S3 als FAL-Treiber para TYPO3. Armazenar arquivos na nuvem em vez do servidor web. Essencial para configurações multi-servidor, integração CDN.

## aus_driver_amazon_s3 é a solução padrão quando assets TYPO3 não podem mais ficar no webserver, a extensão traz buckets S3 como driver FAL completo ao stack TYPO3

Um setup TYPO3 clássico armazena todos os dados de mídia em fileadmin, no webserver. Isso funciona enquanto o projeto roda em uma única máquina e o armazenamento basta. Assim que, porém, entram em cena setups multi-server, container clusters, auto scaling ou Content Delivery Networks, esse modelo quebra. Cada instância precisaria de uma cópia idêntica de todos os arquivos, sincronização vira obra permanente, deploys ficam lentos. O aus_driver_amazon_s3 resolve isso integrando o Amazon S3 como storage FAL externo. Arquivos ficam no bucket, o TYPO3 lê e grava via API S3, e cada instância de servidor acessa a mesma base consistente. Para projetos com exigência de alta disponibilidade, esse é o caminho padrão.

Além da necessidade técnica para setups multi-server, existe um segundo driver importante: backup e redundância. O S3 armazena cada arquivo automaticamente de forma múltipla entre data centers, atingindo uma retenção que um webserver clássico não garante. Para empresas cujos dados de mídia são críticos para o negócio, isso por si só é motivo para migrar ao S3.

## Cenários típicos de uso

O primeiro caso são deploys cloud native em AWS, Kubernetes ou Docker Swarm. O TYPO3 roda em vários containers atrás de um Load Balancer, cada container é stateless. Fileadmin como diretório local significaria que uploads só pousam em um container e os outros não os veem. O aus_driver_amazon_s3 mantém o acervo de assets central e torna scale out praticável.

O segundo caso são projetos com volumes muito grandes de dados. Uma plataforma de mídia, um arquivo de imagens ou um portal de download cresce rapidamente para várias centenas de gigabytes ou terabytes. Armazenamento local no servidor fica caro e inflexível, o S3 escala de forma transparente e cobra apenas o que está realmente ocupado. A conexão via FAL permite mudar para o novo storage sem alterações de código no TYPO3.

Terceiro uso: integração CDN. Quem quer entregar imagens e downloads via Cloudfront, Cloudflare ou CDN próprio usa S3 como origin. O aus_driver_amazon_s3 disponibiliza os arquivos diretamente no bucket, o TYPO3 gera os URLs corretos e o CDN os cacheia globalmente. Isso melhora mensuravelmente o tempo de carregamento para visitantes internacionais.

## Arquitetura técnica

O aus_driver_amazon_s3 implementa a interface FAL Driver do TYPO3 e usa o AWS SDK for PHP oficial para comunicação com o S3. Cada bucket é configurado como um File Storage próprio no backend TYPO3, com indicação de nome do bucket, região, Access Key e Secret Key. Alternativamente, IAM roles podem ser usadas quando o TYPO3 roda em uma instância EC2 ou em uma task ECS, o que é mais limpo, porque não há credenciais estáticas na configuração.

A extensão suporta tanto o Amazon S3 quanto serviços compatíveis com S3 como MinIO, Backblaze B2, DigitalOcean Spaces ou Scaleway Object Storage. Para projetos que, por razões de proteção de dados, não podem usar AWS, essa flexibilidade é importante, um provedor compatível com S3 no Brasil ou na Europa se comporta, do ponto de vista do TYPO3, exatamente como o serviço AWS.

Em operação, o TYPO3 lê e escreve direto contra o S3. Os processed files, ou seja, as variantes de imagem cortadas e otimizadas, são por padrão também salvas no bucket. Alternativamente, um diretório local para processed files pode ser configurado, o que acelera o processamento de imagem, porque o GIFBUILDER não precisa puxar cada imagem original do S3.

A configuração é feita via o módulo backend "File Storages" e configurações TypoScript complementares para a URL do bucket e prefixos CDN. Desenvolvedores precisam, adicionalmente, instalar a dependência AWS SDK via Composer e definir as permissões corretas no bucket.

## Problemas frequentes e soluções

O primeiro problema é performance em listas grandes de imagens. Quando uma página precisa cortar dezenas de imagens ao mesmo tempo e os arquivos fonte são puxados do S3, a construção da página demora perceptivelmente mais. A solução está em um cache local para processed files, eventualmente combinado com um script de pré-warming que, após novos uploads, gera antecipadamente as variantes mais comuns.

Segundo problema: erros de permissão no upload. Quando o TYPO3 quer gravar no bucket mas a policy IAM só permite leitura, o upload quebra com mensagem de erro enigmática. A solução é uma policy precisa com s3:GetObject, s3:PutObject, s3:DeleteObject e s3:ListBucket exatamente para o bucket do TYPO3, idealmente limitada a um prefix, para que outras aplicações no mesmo bucket não sejam afetadas por acidente.

Terceiro problema: proteção de dados e escolha de região. Projetos que precisam operar em conformidade com a LGPD (PT: RGPD) devem escolher regiões AWS na América do Sul, tipicamente sa-east-1 em São Paulo, ou considerar um provedor brasileiro compatível com S3. Para exigências mais altas ou clientes que excluem a AWS em princípio, um provedor nacional compatível é o caminho adequado. A extensão trabalha com todos esses provedores.

## Migração e compatibilidade de versões

O aus_driver_amazon_s3 é compatível com TYPO3 v11, v12 e v13 e é desenvolvido ativamente. Em upgrades, vale atenção à versão do AWS SDK, versões mais novas do TYPO3 frequentemente exigem versões atuais do SDK, que por sua vez exigem PHP 8.1 ou superior.

Uma migração de fileadmin local para S3 é um projeto claramente delimitado: copiar os arquivos inicialmente via aws s3 sync para o bucket, configurar um novo File Storage no backend TYPO3, redirecionar os registros sys_file existentes para o novo storage via script, apagar os arquivos locais após teste bem-sucedido. A extensão não traz uma rotina de migração pronta, porque o modo exato é específico de cada projeto.

No acervo, antes da migração, vale a obrigação do inventário. Quantos arquivos estão no fileadmin, qual o tamanho do acervo, quais estão órfãos e quais ainda estão realmente linkados? Em auditorias assim, frequentemente se descobre que boa parte dos dados antigos nunca mais é chamada e a migração pode se restringir aos arquivos ativamente usados. Isso reduz risco, esforço e custos de bucket.

A Gosign acompanha migrações S3 para projetos TYPO3 e desenha arquiteturas multi cloud que atendem simultaneamente exigências de proteção de dados e metas de performance.

--- Azure Storage TYPO3 - FAL na nuvem | Gosign ---
> Azure Blob Storage como driver FAL para TYPO3. Armazenar arquivos na nuvem Microsoft. Equivalente ao aus_driver_amazon_s3 para infraestruturas Azure.

## Empresas com stack Microsoft precisam de Azure Storage em vez de sistemas de arquivos locais

Quando a infraestrutura de TI roda no Azure, o Active Directory gerencia os usuários e o SharePoint mantém os documentos, o sistema de arquivos do TYPO3 também pertence à nuvem Azure. EXT:azurestorage integra o Azure Blob Storage como driver FAL (File Abstraction Layer) no TYPO3. Editores não percebem diferença, mas os arquivos ficam na infraestrutura de nuvem da Microsoft com CDN, geo-redundância e armazenamento praticamente ilimitado, em vez do servidor web.

Essa extensão é o equivalente Azure do EXT:aus_driver_amazon_s3. A decisão entre ambos raramente é técnica, mas segue a estratégia de nuvem existente. Quem já usa Azure economiza complexidade, contratos e custos de rede ao permanecer no ecossistema Microsoft.

## Cenários típicos de uso

**Websites enterprise com setup multi-servidor.** Grandes instalações TYPO3 rodam em vários servidores web atrás de um load balancer. Sem cloud storage, os arquivos precisam ser sincronizados entre servidores via rsync, NFS ou GlusterFS. Cada uma dessas soluções traz problemas próprios. Azure Blob Storage como driver FAL torna a sincronização de arquivos desnecessária: todos os servidores acessam o mesmo Blob Container. Em um cliente com 4 servidores web e 180.000 arquivos, a migração para Azure eliminou toda a infraestrutura NFS.

**Portais com conteúdo multimídia e público global.** Empresas com clientes na Europa, Ásia e América do Norte precisam de tempos de carregamento rápidos mundialmente. Azure CDN entrega imagens e downloads por servidores edge em mais de 130 cidades. A integração ocorre pela configuração do endpoint CDN no Azure Portal, o TYPO3 gera automaticamente as URLs CDN correspondentes.

**Requisitos de compliance para armazenamento de dados.** Alguns setores exigem que arquivos sejam armazenados em um país específico. O Azure oferece data centers em diversas localidades. Pela configuração da conta de armazenamento, é possível definir exatamente onde os dados ficam fisicamente. Para organizações brasileiras, isso é especialmente relevante em relação à LGPD (PT: RGPD) e à soberania de dados.

## Arquitetura técnica

EXT:azurestorage implementa a interface de driver TYPO3 FAL. Isso significa que a extensão se registra como driver no File Abstraction Layer e sobrescreve as operações padrão do sistema de arquivos (leitura, escrita, exclusão, listagem) com chamadas à API Azure Blob Storage.

A configuração é feita pelas configurações de File Storage do TYPO3 no backend. Um novo objeto de armazenamento é criado com o driver "Azure Blob Storage". As credenciais de acesso (Storage Account Name, Access Key ou SAS Token) são configuradas na Storage. Recomendado: SAS Token com validade limitada e permissões de leitura/escrita em vez do Master Access Key.

A comunicação entre TYPO3 e Azure ocorre pela Azure Storage REST API. Uploads são armazenados como Block Blobs, arquivos grandes (acima de 256 MB) são automaticamente divididos em blocos. Para a integração PHP, a extensão usa o Azure SDK for PHP ou uma implementação REST client leve.

Imagens são processadas conforme necessário pelo Image Processing do TYPO3 (GraphicsMagick/ImageMagick). As variantes processadas também são armazenadas no Azure, tipicamente em um container separado (_processed_). O cache dos Processed Files reduz o tempo de processamento em requisições repetidas.

## Problemas frequentes e soluções

**Performance lenta no backend ao navegar diretórios grandes.** Azure Blob Storage não tem uma estrutura de diretórios real, mas a emula via prefixos de caminho. Listar 10.000 arquivos em uma "pasta" requer paginação da API e demora perceptivelmente mais que em um sistema de arquivos local. A solução: configurar corretamente o indexador FAL do TYPO3 e atualizar o índice regularmente, em vez de consultar o Azure ao vivo em cada acesso ao backend.

**Processamento de imagem falha.** TYPO3 precisa baixar imagens para processá-las e depois enviá-las novamente. Com conexão instável ou imagens grandes (arquivos TIFF com 200 MB), o processo aborta. Solução: realizar o processamento no servidor com diretório temp local e enviar apenas o resultado. A configuração `processingFolder` deve apontar para um caminho local.

**Explosão de custos por chamadas de API desnecessárias.** Cada acesso a arquivo é uma chamada de API, e o Azure cobra por 10.000 transações. Um indexador TYPO3 mal configurado pode gerar milhares de chamadas por minuto. Configurar monitoramento via Azure Cost Management e mudar o indexador FAL para intervalos baseados em scheduler (em vez de tempo real).

## Migração e compatibilidade de versões

EXT:azurestorage é um produto de nicho com comunidade limitada. As versões disponíveis no TER e no Packagist suportam TYPO3 v10 e v11. Para v12, existem forks no GitHub com diferentes graus de maturidade. Para TYPO3 v13, não há solução pronta atualmente.

A alternativa para v12/v13: EXT:aus_driver_amazon_s3 com um endpoint Azure compatível com S3. Azure Blob Storage oferece desde 2020 uma camada de API compatível com S3. Assim, a extensão S3 mais bem mantida pode ser usada com Azure. A configuração requer uma conta Azure Storage com o recurso "S3-Compatible API" ativado e a configuração da extensão S3 com o endpoint Azure.

Quem migra de sistema de arquivos local para Azure deve planejar a mudança em três fases: primeiro, enviar os arquivos existentes para o Blob Container via AzCopy ou Storage Explorer; segundo, alterar a configuração de File Storage do TYPO3; e terceiro, reconstruir o índice FAL. Com 50.000 arquivos, todo o processo leva tipicamente um dia de trabalho. A Gosign realizou migrações Azure para projetos TYPO3 com até 400.000 arquivos e orienta tanto sobre a extensão nativa quanto sobre o workaround compatível com S3.
---

--- be_acl TYPO3 - Permissões do backend | Gosign ---
> Backend Access Control Lists para TYPO3. Permissões granulares para usuários e grupos do backend. Essencial para configurações com múltiplos editores.

## Quando mais de três editores trabalham, as permissões padrão do TYPO3 não são mais suficientes

O TYPO3 traz um sistema de permissões: grupos de backend, acessos a páginas, permissões de tabelas. Para equipes pequenas com poucos editores, funciona. Mas quando um site corporativo é mantido por 15 editores de 4 departamentos, o sistema padrão atinge seus limites. be_acl estende o TYPO3 com Listas de Controle de Acesso granulares que regulam quem pode ver, editar ou excluir quais conteúdos em qual página - até o nível de campo.

A extensão não é um luxo, mas pré-requisito para qualquer configuração com múltiplos editores e mais de uma zona de responsabilidade. Sem be_acl, conceitos de permissão no TYPO3 regularmente terminam em uma rede de dezenas de grupos que ninguém mais consegue acompanhar.

## Cenários típicos de uso

**Sites corporativos com responsabilidade por departamento.** Marketing cuida da página inicial e páginas de campanha, RH da página de carreiras, os departamentos técnicos de suas páginas de produtos. Cada departamento deve ver e editar apenas suas próprias páginas. O sistema padrão do TYPO3 permite acessos a páginas via Mount Points e permissões de grupo, mas a configuração fica confusa com mais de 10 departamentos. be_acl simplifica isso com ACLs baseadas em página: em cada página da árvore de páginas, é possível definir diretamente qual grupo tem quais permissões.

**Instalações TYPO3 multi-tenant.** Agências e corporações operam vários sites em uma instância TYPO3. O mandante A não deve ver o mandante B, nem na árvore de páginas. be_acl aplica essa separação sem precisar operar uma instalação TYPO3 separada para cada mandante. Em uma agência com 12 mandantes em uma instância TYPO3, be_acl reduziu o tempo de administração de permissões em cerca de 60%.

**Workflows de aprovação com profundidade de edição limitada.** Prestadores de serviço externos ou estagiários devem editar textos de conteúdo, mas não fazer upload de imagens, mover páginas ou configurar plugins. be_acl permite permissões no nível de campo: o usuário vê o campo de texto, mas não as configurações de layout ou a configuração do plugin.

## Arquitetura técnica

be_acl estende o sistema de permissões de backend do TYPO3 com uma camada ACL que se situa entre o sistema de permissões do Core e a interação do usuário. A extensão armazena regras de permissão na tabela `tx_beacl_acl`, que define por página e por grupo quais operações são permitidas.

O sistema trabalha com três níveis de permissão: Leitura (show), Edição (edit) e Exclusão (delete). Essas permissões são concedidas por página ou recursivamente para uma árvore de páginas. A configuração é feita por uma aba própria no diálogo de propriedades da página: ali o administrador seleciona um grupo de usuários e define as permissões desejadas via checkbox.

Internamente, be_acl intervém no `BackendUserAuthentication` do TYPO3 e estende a verificação `doesUserHaveAccess`. A cada acesso a página no backend, o TYPO3 verifica primeiro as permissões padrão e depois as regras ACL. As regras ACL podem estender permissões padrão, mas não restringi-las. Esse é um detalhe arquitetural importante: se um grupo já tem acesso pelas permissões padrão, be_acl não pode revogar esse acesso.

A resolução de permissões segue uma cascata: permissões de usuário sobrepõem permissões de grupo, permissões de grupo sobrepõem permissões de subgrupo, e ACLs específicas de página sobrepõem ACLs herdadas recursivamente. Essa cascata funciona de forma confiável enquanto a estrutura de grupos permanece plana. A partir de 4 níveis de grupo aninhados, o comportamento se torna difícil de prever.

## Problemas frequentes e soluções

**Permissões não funcionam como esperado.** Causa mais frequente: o usuário é membro de vários grupos, e as permissões de um grupo sobrescrevem a restrição ACL de outro. O sistema de permissões do TYPO3 funciona de forma aditiva, ou seja, o usuário recebe a soma de todas as permissões de seus grupos. Solução: criar uma matriz de permissões, documentar todos os grupos de um usuário e eliminar sobreposições.

**Problemas de performance em árvores de página grandes.** Em instalações TYPO3 com mais de 5.000 páginas e mais de 20 grupos de usuários, a verificação ACL pode deixar a árvore de páginas do backend perceptivelmente mais lenta. A extensão verifica a tabela ACL a cada acesso a página. Solução: ativar cache das verificações ACL e restringir a árvore de páginas via `options.pageTree.excludeDoktypes` aos tipos de página relevantes.

**Debug de permissões é difícil.** O TYPO3 não oferece uma ferramenta nativa que mostre por que um usuário pode ou não acessar determinada página. A área de Admin "Backend User" mostra a visualização simulada, mas não a cascata de permissões. Solução: analisar o System Log do TYPO3 (com modo debug ativado, o TYPO3 registra tentativas de acesso) ou consultar diretamente a tabela SQL `tx_beacl_acl`.

## Migração e compatibilidade de versões

be_acl é uma das extensões TYPO3 mantidas há mais tempo. A versão atual suporta TYPO3 v11 e v12. Para TYPO3 v13 existe uma versão beta baseada no novo sistema de módulos de backend. A extensão é desenvolvida ativamente no GitHub, os mantenedores respondem a issues.

Na migração do TYPO3 v11 para v12, as regras ACL não precisam ser migradas manualmente - a tabela do banco de dados permanece compatível. Porém, o registro de módulos de backend mudou na v12, pelo que o módulo de configuração be_acl requer uma atualização da versão da extensão.

Para empresas que migram para TYPO3 v13, recomenda-se exportar as regras ACL existentes antes do upgrade. TYPO3 v13 traz um sistema de permissões reformulado que incorpora algumas funções do be_acl no Core. Se a extensão ainda será necessária a longo prazo depende da complexidade do conceito de permissões. A Gosign analisa em upgrades TYPO3 a configuração ACL existente e recomenda a solução ideal - seja be_acl, permissões nativas do Core ou uma combinação.
---

--- bernetshop TYPO3 - Loja simples | Gosign ---
> Einfachere E-Commerce-Extension para TYPO3 als aimeos. Para lojas menores com requisitos básicos: Lista de produtos, carrinho, pagamento simples.

## Nem toda loja TYPO3 precisa de um framework de e-commerce completo

Aimeos é o padrão para e-commerce no TYPO3. Mas Aimeos também é complexo: camada de abstração de banco de dados própria, sistema de templates próprio, mais de 30 tabelas de configuração. Para uma associação que vende 8 artigos de merchandising ou uma empresa de médio porte com 50 peças de reposição, é exagero. bernetshop oferece uma alternativa leve: lista de produtos, carrinho, pagamento, pronto. Sem gestão de estoque, sem multi-loja, mas também sem meses de configuração.

A extensão é destinada a organizações que querem vender poucos produtos pelo seu site TYPO3 existente, sem operar um sistema de loja separado. O uso típico: 10 a 200 produtos, variantes simples (tamanho, cor), pagamento por boleto, PayPal ou Stripe.

## Cenários típicos de uso

**Associações e organizações sem fins lucrativos.** Clubes esportivos vendem camisetas e ingressos, instituições culturais oferecem assinaturas anuais e publicações. A loja precisa ser fácil de manter, pois voluntários a gerenciam. bernetshop pode ser configurado via elementos de conteúdo padrão do TYPO3: um produto é um registro com imagem, preço, descrição e variantes. Sem necessidade de treinamento além da edição normal do TYPO3.

**Venda de peças de reposição e acessórios.** Fabricantes de máquinas e equipamentos vendem peças de desgaste, acessórios e materiais de consumo pelo site corporativo. Os dados do produto já existem no TYPO3 (páginas de produto, fichas técnicas), bernetshop complementa com carrinho e função de pagamento. A manutenção do produto permanece onde os dados técnicos já estão: no CMS.

**Portais de pedidos internos.** Empresas maiores utilizam sistemas simples de pedidos para material de escritório, material promocional ou acessórios de TI. bernetshop com TYPO3 Frontend-Login resulta em um portal de pedidos protegido por senha sem software externo. Os pedidos são encaminhados por e-mail ao departamento responsável, uma conexão ERP não é prevista e nesse contexto não é necessária.

## Arquitetura técnica

bernetshop é baseado em Extbase/Fluid, o framework padrão para extensões TYPO3. Os dados de produto são armazenados em uma tabela própria `tx_bernetshop_domain_model_product`. Variantes (tamanhos, cores) são modeladas como relações inline. O carrinho é mantido na sessão PHP e opcionalmente persistido no banco de dados para usuários registrados.

A lógica da loja é clara: há controllers para lista de produtos, detalhe de produto, carrinho e checkout. Os templates são Fluid padrão e podem ser personalizados como qualquer outro template TYPO3. O processamento de pagamento ocorre via um adaptador de provedor de pagamento: PayPal, Stripe e boleto são implementados por padrão. Provedores adicionais podem ser acrescentados via interface PHP.

Os pedidos são armazenados em uma tabela do banco de dados e disparam um e-mail de confirmação para cliente e operador da loja. Um módulo de backend mostra todos os pedidos com status (aberto, pago, enviado). Exportação como CSV está integrada, uma interface ERP direta não.

A extensão utiliza o cache padrão do TYPO3 para listas de produtos. O carrinho e a área de checkout são uncacheable (USER_INT). Isso significa: páginas de lista de produtos se beneficiam do cache TYPO3, o checkout roda sem cache, o que é relevante sob alta carga.

## Problemas frequentes e soluções

**Limites de escalabilidade a partir de 200 produtos.** A lista de produtos fica lenta com número crescente de produtos quando nenhuma paginação está configurada. bernetshop inclui uma paginação simples, mas sem busca facetada ou filtro por categoria. Solução: a partir de 200 produtos, criar páginas de categoria e limitar a lista de produtos por categoria. A partir de 500 produtos, considerar seriamente Aimeos ou uma loja externa.

**Integração de pagamento desatualizada.** Os adaptadores de pagamento incluídos usam parcialmente versões mais antigas das APIs dos provedores. A API clássica do PayPal foi descontinuada, Stripe atualizou sua API várias vezes. Solução: verificar os adaptadores de pagamento e atualizar para versões de API atuais. O esforço por adaptador é de 1 a 2 dias de desenvolvimento.

**Requisitos legais não completamente cobertos.** Direito de arrependimento, indicação de preço base, regulamento de embalagem e as obrigações de informação no e-commerce exigem adaptações que bernetshop não entrega out-of-the-box. No Brasil, a LGPD (PT: RGPD) e o Código de Defesa do Consumidor impõem requisitos específicos para lojas online. Solução: complementar os templates de checkout com as informações legalmente necessárias. Isso é trabalho de template, não desenvolvimento de extensão.

## Migração e compatibilidade de versões

bernetshop é uma extensão de nicho com manutenção limitada. A última versão estável suporta TYPO3 v10 e v11. Para TYPO3 v12 não existe atualização oficial, o esforço de portabilidade é gerenciável (alterações de API Extbase, ajustes TCA), mas deve ser feito manualmente. Para TYPO3 v13 não há planejamento.

Empresas que migram para TYPO3 v12 ou v13 enfrentam uma decisão: portar bernetshop ou mudar para uma alternativa. As opções são Aimeos (framework de e-commerce completo, esforço significativamente maior), cart (loja baseada em Extbase com manutenção ativa e compatibilidade v12) ou uma loja externa (Shopify, WooCommerce) com integração TYPO3 via API.

A migração dos dados de produto é sempre simples: a tabela tem uma estrutura clara que pode ser transferida para qualquer sistema de destino via script SQL. Em um cliente com 85 produtos, a migração completa de bernetshop para EXT:cart incluindo adaptação de templates levou 4 dias de trabalho. A Gosign orienta sobre a opção mais econômica e assume a portabilidade ou migração conforme necessidade.
---

--- Bilddatenbank TYPO3 - Gerenciamento de ativos digitais | Gosign ---
> Bilddatenbank no TYPO3: Digital Asset Management, Auto-Tagging, Suche. Extensão FAL ou conexão com DAM externo.

## A partir de 5.000 imagens, o FAL do TYPO3 se torna um gargalo

O File Abstraction Layer do TYPO3 gerencia arquivos de forma confiável enquanto a quantidade permanece gerenciável. Com 500 imagens, o FAL funciona perfeitamente. Com 5.000, a busca fica lenta. Com 20.000, a lista de arquivos no backend se torna praticamente inutilizável. Empresas com grandes acervos de imagens precisam de mais que um sistema de arquivos: precisam de um Digital Asset Management. A questão é se se expande o FAL do TYPO3 para DAM ou se conecta um sistema externo.

Ambos os caminhos funcionam. A expansão interna via extensões FAL custa menos e permanece no ecossistema TYPO3. A conexão externa (Celum, Canto, Cloudinary, Bynder) oferece mais funcionalidades, mas requer licenças, manutenção de interfaces e lógica de dados duplicada.

## Cenários típicos de uso

**Empresas industriais com fotografia de produtos.** Um fabricante de máquinas tem 8.000 fotos de produtos em diferentes resoluções, além de renderings CAD, imagens de aplicação e fichas técnicas. Cada produto existe em 5 a 10 variantes de imagem. Sem etiquetagem sistemática, editores não encontram a imagem certa, ou pior, usam uma desatualizada. Auto-tagging por IA analisa conteúdos de imagem e atribui tags automaticamente. Em um cliente com 12.000 imagens de produto, o auto-tagging baseado em IA reduziu o tempo de classificação de 3 semanas para 2 dias.

**Empresas de mídia e editoras.** Portais de notícias, revistas e departamentos de publicação corporativa produzem novo material visual diariamente. Os requisitos: busca rápida, gestão de direitos (expiração de licença, direitos de uso por canal), conversão automática de formato e herança de metadados. Um FAL estendido com campos customizados cobre as funções básicas. Para gestão de direitos e controle de workflow, é necessário um DAM externo.

**Universidades e instituições de pesquisa.** Universidades gerenciam fotos de campus, fotos de eventos, gráficos de pesquisa e retratos de funcionários. O desafio: fornecimento descentralizado de mais de 30 departamentos para um sistema central. TYPO3 FAL com estrutura de pastas baseada em categorias e direitos de acesso por grupo de usuários resolve isso. Sistemas DAM externos raramente são economicamente viáveis nesse contexto.

## Arquitetura técnica

O FAL do TYPO3 consiste em três camadas: o Storage Driver (sistema de arquivos local, S3, Azure), o File Index (tabela de banco de dados `sys_file` com metadados) e o File Reference System (vinculação entre arquivos e elementos de conteúdo). Um banco de imagens no TYPO3 expande primariamente a camada intermediária, o File Index.

A extensão mais simples: campos customizados na tabela `sys_file_metadata`. O TYPO3 já traz campos como `title`, `description`, `alternative` e `copyright`. Via TCA, campos adicionais podem ser acrescentados: `photographer`, `license_type`, `expiry_date`, `usage_rights`, `location`, `keywords_auto`. Esses campos aparecem no diálogo de metadados de arquivo no backend.

Para busca, o TYPO3 oferece por padrão apenas uma busca por nome de arquivo no módulo File List. Uma busca fulltext real sobre todos os metadados requer uma integração Solr (via EXT:solrfal) ou um módulo de backend customizado com conexão Elasticsearch. Solr então pesquisa não apenas nomes de arquivo, mas todos os campos de metadados, incluindo tags geradas automaticamente.

Auto-tagging por IA funciona via uma tarefa Scheduler que envia novos arquivos a um serviço de reconhecimento de imagem (Google Cloud Vision, AWS Rekognition ou um modelo self-hosted) e grava as tags reconhecidas nos campos de metadados. O processo é assíncrono e não sobrecarrega o backend. Para importação inicial de grandes acervos, conta-se com aproximadamente 1 segundo por imagem para a análise via API.

## Problemas frequentes e soluções

**Índice FAL e sistema de arquivos ficam dessincronizados.** Quando arquivos são enviados por FTP ou excluídos manualmente, o índice FAL não corresponde mais ao sistema de arquivos. O TYPO3 mostra arquivos que não existem ou não conhece arquivos presentes. Solução: executar o indexador FAL regularmente via Scheduler (recomendado: diariamente à noite). O indexador sincroniza sistema de arquivos e banco de dados. Com 50.000 arquivos, a sincronização leva aproximadamente 10 a 15 minutos.

**Metadados se perdem em upgrades do TYPO3.** Campos customizados em `sys_file_metadata` sobrevivem a upgrades TYPO3 quando definidos via uma extensão própria. Se definidos diretamente no arquivo TCA-Override do sitepackage, podem se perder em alterações estruturais da tabela de metadados. Solução: sempre encapsular campos de banco de imagens em uma pequena extensão própria, não no sitepackage.

**Performance do backend em árvores de arquivo grandes.** O módulo File List fica lento a partir de 1.000 arquivos por pasta, pois gera thumbnails para cada imagem. Solução: criar estrutura de pastas com no máximo 500 arquivos por diretório e mudar a geração de thumbnails no File List para "on demand".

## Migração e compatibilidade de versões

O FAL do TYPO3 faz parte do Core desde a versão 6.0 (2012) e é desenvolvido a cada versão major. A API FAL é estável, campos customizados e indexadores funcionam do TYPO3 v10 ao v13 sem ajustes. A extensão Solr-FAL (EXT:solrfal) suporta TYPO3 v12, para v13 a compatibilidade foi anunciada.

Quem migra de um sistema DAM externo para TYPO3 FAL precisa mapear os metadados. Cada sistema DAM tem um modelo de dados próprio. A migração em si é uma tarefa de banco de dados: exportação do DAM como CSV/JSON, mapeamento dos campos para `sys_file_metadata`, importação via TYPO3 DataHandler ou SQL direto.

A decisão "expansão FAL vs. DAM externo" depende de dois fatores: tamanho do acervo e complexidade do workflow. Até aproximadamente 10.000 assets e sem workflows de aprovação, FAL estendido é suficiente. Além disso, ou com requisitos como gestão automática de licenças e distribuição multi-canal, vale a pena um DAM especializado com conector TYPO3. A Gosign orienta sobre ambas as variantes e implementa tanto extensões FAL quanto integrações DAM.
---

--- Booking TYPO3 - Sistema de reservas | Gosign ---
> Buchungssystem para TYPO3: Terminbuchung, Verfügbarkeit, Bezahlung. Desenvolvimento personalizado, acelerado com IA.

## Agendamento online direto no site frequentemente falha no TYPO3 pela falta de maturidade das extensões

Empresas com consultas agendadas, aluguel de salas ou ofertas de cursos querem integrar reservas online diretamente em seu site TYPO3. A expectativa: calendário, verificação de disponibilidade, pagamento, e-mail de confirmação - tudo integrado. A realidade: não existe no TYPO3 Extension Repository (TER) uma única extensão de reservas que cubra todos esses requisitos de forma pronta para produção. As soluções disponíveis (jcc_appointment, cab_single_booking, diversos desenvolvimentos próprios) atendem casos de nicho ou não são mantidas ativamente.

Por isso, um sistema de reservas TYPO3 é quase sempre um híbrido: uma extensão base ou desenvolvimento personalizado para a lógica central, combinado com providers de pagamento (Stripe, PayPal, Mollie) e interfaces de calendário (iCal, Google Calendar API). A Gosign implementou essa abordagem em mais de 15 projetos.

## Cenários típicos de uso

**Consultórias com agendamento.** Contadores, advogados, consultores empresariais precisam de um sistema onde clientes vejam horários livres e façam agendamentos. O calendário sincroniza com o Outlook ou Google Calendar do consultor. Pagamento é opcional (frequentemente cobra-se após a consulta), mas prazos de cancelamento e taxas de no-show devem ser modeláveis. Um setup típico: 3 consultores, 4 tipos de serviço, slots de 30 minutos, 2 locais.

**Provedores de seminários e cursos.** Instituições de ensino, escolas e clubes esportivos oferecem cursos com vagas limitadas. O sistema de reservas precisa de listas de participantes, listas de espera, preços para grupos, descontos para inscrição antecipada e sessões em série. Pagamento ocorre na reserva, cancelamento com reembolso parcial deve ser automatizado.

**Aluguel de salas e gerenciamento de recursos.** Espaços coworking, hotéis de convenções, centros esportivos alugam salas ou quadras por hora. Aqui conta a exibição de disponibilidade em tempo real: nenhuma sala pode ser reservada em duplicidade, mesmo quando dois usuários clicam em "Reservar" simultaneamente. Proteção contra race conditions no nível do banco de dados não é um diferencial - é obrigação.

## Arquitetura técnica

Um sistema de reservas pronto para produção no TYPO3 consiste em quatro camadas. A camada de banco de dados gerencia recursos (salas, pessoas, equipamentos), disponibilidades (janelas de tempo, bloqueios, feriados) e reservas (com status: solicitada, confirmada, cancelada, concluída). A camada de lógica verifica disponibilidade, impede reservas duplicadas e calcula preços. A camada de pagamento se comunica com provedores de pagamento externos via suas APIs. A camada de notificação envia confirmações, lembretes e e-mails de cancelamento.

Para a prevenção de reservas duplicadas existem três abordagens: locking pessimista (SELECT ... FOR UPDATE), locking otimista (número de versão na tabela de reservas) ou baseado em fila (solicitações de reserva são processadas sequencialmente). A escolha depende da carga esperada. Com menos de 100 reservas por dia, locking otimista é suficiente; para eventos com 1.000 acessos simultâneos, uma fila é mais robusta.

Exportação iCal é padrão: cada reserva confirmada gera um arquivo .ics, enviado como anexo no e-mail de confirmação. Para sincronização bidirecional (reserva no TYPO3 aparece no Google Calendar e vice-versa), é necessária a Google Calendar API ou CalDAV.

## Problemas frequentes e soluções

**Reservas duplicadas apesar da verificação de disponibilidade.** A causa mais frequente: a verificação "O slot está livre?" e a inserção da reserva não rodam na mesma transação de banco de dados. Entre verificação e insert podem passar milissegundos, nos quais um segundo usuário reserva o mesmo slot. Solução: empacotar verificação e insert em uma transação com bloqueio de linha.

**Callbacks de pagamento não chegam.** Stripe e PayPal enviam confirmações de pagamento via webhook. Se o site TYPO3 está atrás de um reverse proxy ou firewall, os callbacks não alcançam o servidor. Solução: disponibilizar URL de webhook via rota dedicada (ex: `/api/payment/webhook`), que não seja bloqueada por cache TYPO3 ou regras .htaccess.

**Caos de fusos horários em reservas internacionais.** Quando quem reserva e o recurso estão em fusos horários diferentes, surgem erros. Solução: armazenar todos os horários internamente como UTC, exibir no frontend via JavaScript adaptado ao fuso horário local do usuário.

## Migração e compatibilidade de versões

Não existe uma extensão de reservas unificada com suporte oficial TYPO3 v12/v13. A maioria das extensões disponíveis parou na v10 ou v11. Quem migra um sistema de reservas existente para TYPO3 v12+ tem duas opções: portar a lógica personalizada para Extbase/Doctrine (compatível com v12) ou externalizar a lógica de reservas como microserviço API e renderizar apenas o frontend no TYPO3.

Para novos desenvolvimentos, recomenda-se uma abordagem API-first: o motor de reservas como API REST (no TYPO3 ou como serviço separado), o frontend como web component que pode ser incorporado em qualquer template TYPO3. Assim, o sistema de reservas permanece independente de upgrades de versão TYPO3. A Gosign aplica essa abordagem como padrão desde 2024.

Quem usa um sistema externo de reservas (Calendly, SimplyBook.me, Timify) e quer apenas incorporar a interface no TYPO3 tem uma terceira opção: integrar o sistema externo via iframe ou widget JavaScript. Isso funciona rápido, mas tem desvantagens: sem design unificado, questões de privacidade (cookies de terceiros, transferência de dados para os EUA conforme LGPD (PT: RGPD)) e nenhum controle sobre o fluxo de reservas. Para setores sensíveis à proteção de dados (saúde, consultoria jurídica, administração pública), o desenvolvimento personalizado dentro do TYPO3 ou como microserviço próprio é a solução mais adequada.

A Gosign calcula um projeto típico de sistema de reservas (3 tipos de recurso, pagamento Stripe, workflows de e-mail, exportação iCal) com 15 a 25 dias de desenvolvimento. Destes, aproximadamente 40% são para a lógica de reservas com verificação de disponibilidade, 25% para integração de pagamento, 20% para templates de e-mail e notificações e 15% para exibição no frontend e testes.

--- bootstrap_grids TYPO3 - Layouts de grade | Gosign ---
> Layouts de grade Bootstrap como TYPO3 Content Elements. Layouts de colunas sem overhead do Gridelements. A Gosign também migra de bootstrap_grids.

## bootstrap_grids foi por muito tempo o atalho mais rápido para layouts de múltiplas colunas em TYPO3, e hoje é um candidato a migração

Por anos, bootstrap_grids foi em projetos TYPO3 a resposta pragmática a uma exigência recorrente da redação: quero colocar colunas lado a lado em uma página, sem que desenvolvedoras precisem construir content elements próprios a cada vez. A extensão traz uma coleção de layouts de grade Bootstrap predefinidos como content elements ao backend, de modo que redatores podem criar layouts de duas, três ou quatro colunas diretamente no conteúdo da página. Para agências que entregam muitos sites baseados em Bootstrap em pouco tempo, essa foi por muito tempo a solução mais eficiente.

Hoje a situação é mais matizada. Com a core extension EXT:container e os backend layouts significativamente melhorados no TYPO3 v11 até v13, existem alternativas nativas que precisam de menos configuração e se integram mais fortemente ao padrão TYPO3. O bootstrap_grids continua relevante em projetos existentes, mas novos projetos devem usá-lo de forma consciente ou não usar mais.

## Cenários típicos de uso

Um primeiro cenário é o levantamento rápido. Um site de empresa de médio porte com cerca de 200 páginas, já baseado em Bootstrap, usa bootstrap_grids para disponibilizar layouts de múltiplas colunas sem setup próprio de site package. Redatores escolhem layouts de coluna em um dropdown e preenchem os containers com content elements padrão.

Um segundo cenário é o reparo de relançamentos antigos. Um site de associação de 2018 foi originalmente construído com bootstrap_grids e acumulou com o tempo 600 content elements dentro de containers grid. Em um upgrade de TYPO3 v9 para v11, surge a pergunta: migrar ou continuar. Em regra, o bootstrap_grids é mantido primeiro para não bloquear o upgrade, e a troca para EXT:container vem em um segundo passo.

Um terceiro cenário é a fase de transição para uma arquitetura frontend moderna. Um conglomerado migra seu site de Bootstrap para um design system baseado em Tailwind. Enquanto o time editorial ainda não migrou para a nova interface de editor, o bootstrap_grids permanece em uso como ponte, com data de expiração clara.

Um quarto cenário é a solução de emergência em um audit. Quando um site existente não tem layouts de coluna e páginas individuais precisam ser exibidas posteriormente em múltiplas colunas, o bootstrap_grids é a resposta mais rápida: instalação, ativação, primeira página com área de conteúdo em duas colunas em menos de uma hora. Para uso a longo prazo, esse atalho raramente é a escolha certa.

## Arquitetura técnica

O bootstrap_grids registra content elements próprios via TCA overrides e entrega templates Fluid para a saída da grid. No núcleo, os elementos são um wrapper fino em torno das classes Bootstrap `container`, `row` e `col-*`. A extensão mantém containers de coluna próprios, visíveis via colpos no backend layout, e inclui, se necessário, CSS do Bootstrap.

A instalação é feita de forma clássica via Composer. Em combinação com site packages próprios, vale saber: o bootstrap_grids traz um CSS Bootstrap 5 completo e JavaScript correspondente, o que em projetos com design system próprio rapidamente gera conflitos e duplo carregamento de CSS. Nesses casos, os recursos do bootstrap_grids são desativados e apenas a integração de backend é usada.

A configuração é feita via TsConfig: aqui os times definem quais variantes de grade são oferecidas aos redatores, quais números de coluna são permitidos e quais breakpoints Bootstrap são mapeados. Uma limitação clara a poucas variantes, claramente nomeadas, reduz significativamente a confusão no backend.

## Problemas frequentes e soluções

O primeiro problema é a armadilha do copia e cola na redação. Sem governance rígida, com bootstrap_grids surgem rapidamente páginas com oito containers aninhados que ninguém mais mantém. A solução é uma limitação das variantes permitidas e uma diretriz editorial que vincule o uso de layouts de coluna a tipos de conteúdo claros.

O segundo problema é o duplo carregamento do CSS Bootstrap. Projetos que além do bootstrap_grids mantêm um build Bootstrap próprio carregam Bootstrap, no pior caso, duas vezes. A solução é desativar os recursos entregues pela extensão totalmente via TsConfig e usar exclusivamente o build do próprio projeto.

O terceiro problema é a migração em upgrades TYPO3. Quem muda de v9 para v11 ou de v11 para v12 descobre que algumas variantes de grid em versões Bootstrap antigas têm nomes diferentes. A solução é um audit dos tipos de grid usados antes do upgrade e uma rodada de migração SQL direcionada que renomeia variantes antigas para novas denominações.

Um quarto problema é a apresentação inconsistente na prévia do editor. O backend mostra containers grid frequentemente vazios ou em forma reduzida, de modo que redatoras não reconhecem o que é realmente entregue no frontend. A solução são preview renderings diretos no módulo backend que replicam as classes Bootstrap e mostram as larguras de coluna visualmente. O esforço não é trivial, mas vale a pena rapidamente em grandes times editoriais.

## Migração e compatibilidade de versões

O bootstrap_grids existe para TYPO3 v9 até v12 e continua sendo mantido, o status oficial para TYPO3 v13 foi atualizado em 2025. Mais importante do que a compatibilidade de versão pura é, no entanto, a questão estratégica de se o bootstrap_grids ainda é a resposta certa no projeto. Para novos projetos, recomenda-se o EXT:container: mais leve, mais próximo do core, mais fácil de manter. Para projetos existentes, uma mudança gradual é frequentemente sensata, especialmente quando o design system está sendo revisto de qualquer forma.

A Gosign migra projetos bootstrap_grids existentes para EXT:container ou para backend layouts nativos com colpos. A migração roda apoiada por script: os containers grid existentes são reescritos via SQL e upgrade wizard em estruturas Container, de forma que redatoras, após o upgrade, não precisem tocar em nenhuma página. Esse é o caminho mais rápido para levar um site package histórico ao padrão TYPO3 moderno sem que conteúdos se percam.

--- cHash TYPO3 - Configuração de cache | Gosign ---
> Configuração de cHash para TYPO3: controla quais parâmetros de URL afetam o cache de páginas. Configuração incorreta de cHash leva a erros ou poluição de cache.

## A maioria dos erros "Page not found" no TYPO3 são problemas de cHash

Um editor cria uma notícia com paginação, a página funciona. Um visitante clica na página 2, vê "Page not found". O desenvolvedor verifica o roteamento, a configuração da página, o .htaccess. Tudo correto. O problema é mais profundo: o mecanismo cHash do TYPO3 não esperava o parâmetro URL da paginação e recusa a entrega. Um problema de 5 minutos quando se sabe onde procurar, um problema de 2 dias quando não.

cHash (Cache Hash) é o mecanismo do TYPO3 para proteger o cache de páginas. Ele calcula um hash de todos os parâmetros URL e compara com a entrada de cache armazenada. Quando aparece um parâmetro desconhecido que o TYPO3 não espera, a página não é entregue. Isso protege contra cache poisoning, mas causa problemas com quase toda nova extensão ou filtro customizado.

## Cenários típicos de uso

**Busca com filtros e facetas em catálogos de produtos.** Um catálogo de produtos com 6 critérios de filtro (categoria, preço, cor, material, disponibilidade, avaliação) gera parâmetros URL como `&tx_catalog[color]=red&tx_catalog[price]=100-200`. Sem configuração cHash, o TYPO3 mostra "Page not found" para cada combinação de filtro. A configuração cHash deve conhecer cada um desses parâmetros, seja como "required" (influencia a chave de cache) ou como "excluded" (é ignorado e não é hasheado).

**Paginação em listas de news e eventos.** EXT:news e EXT:sf_event_mgt usam parâmetros URL próprios para números de página. Esses parâmetros devem estar na configuração cHash para que a página 2 receba sua própria entrada de cache. Se a configuração estiver ausente, ou sempre a página 1 é entregue do cache (cache pollution) ou a paginação falha com 404.

**Parâmetros de tracking e tags UTM.** Campanhas de marketing adicionam parâmetros UTM às URLs: `?utm_source=newsletter&utm_medium=email`. Sem exclusão desses parâmetros, cada link de campanha cria uma nova entrada de cache. Em um site com 500 páginas e 10 campanhas, surgem de repente 5.000 entradas de cache em vez de 500, sobrecarregando o servidor e desacelerando o cache warmup. Parâmetros UTM pertencem à lista de exclusão.

## Arquitetura técnica

O cálculo de cHash ocorre na classe Core `CacheHashCalculator` do TYPO3. O algoritmo pega todos os parâmetros URL, os ordena alfabeticamente, serializa e calcula um hash MD5. Esse hash é adicionado à URL como parâmetro `cHash`. Ao acessar a página, o TYPO3 verifica se o cHash fornecido corresponde ao calculado.

A configuração é feita em `$GLOBALS['TYPO3_CONF_VARS']['FE']['cacheHash']` com quatro listas:

`cachedParametersWhiteList`: Parâmetros que entram no hash e criam entradas de cache próprias. Típico: parâmetros de plugin (`tx_news_pi1`, `tx_solr`).

`excludedParameters`: Parâmetros completamente ignorados. Típico: parâmetros de tracking (`utm_source`, `utm_medium`, `utm_campaign`, `utm_content`, `utm_term`, `gclid`, `fbclid`).

`requireCacheHashPresenceParameters`: Parâmetros que obrigatoriamente requerem um cHash. Se esse parâmetro estiver na URL sem cHash, o TYPO3 mostra um erro 404. Esse é o modo mais restritivo.

`excludedParametersIfEmpty`: Parâmetros que só são ignorados quando estão vazios.

Desde TYPO3 v12, a configuração cHash também pode ser controlada via Site Configuration (config.yaml), o que simplifica a gestão em setups multi-site.

## Problemas frequentes e soluções

**"Page not found" após instalação de extensão.** Novas extensões trazem parâmetros URL próprios. Se não estiverem na configuração cHash, o TYPO3 bloqueia a página. Solução: verificar a documentação da extensão (boas extensões incluem configuração cHash em `ext_localconf.php`). Caso contrário: adicionar os parâmetros manualmente na cachedParametersWhiteList ou excludedParameters. No Install Tool do TYPO3 em "Presets", o modo debug de cHash oferece auxílio.

**Cache pollution por parâmetros descontrolados.** Bots e crawlers de spam adicionam parâmetros aleatórios às URLs. Sem proteção, cada uma dessas chamadas cria uma entrada de cache. O cache cresce para milhões de entradas, o banco de dados fica lento. Solução: definir `excludeAllEmptyParameters = true` e só adicionar parâmetros explicitamente conhecidos na WhiteList. Adicionalmente, ajustar o garbage collector do cache para intervalos mais curtos (padrão: 86.400 segundos = 24 horas).

**Erros cHash difíceis de debugar.** O TYPO3 mostra apenas "Page not found", sem dizer por quê. No modo de produção não há mensagem de erro que indique cHash. Solução: em `LocalConfiguration.php` definir temporariamente `$GLOBALS['TYPO3_CONF_VARS']['FE']['pageNotFoundOnCHashError'] = false`. Assim o TYPO3 mostra a página apesar do erro cHash e registra o erro. Após o diagnóstico, voltar para true.

## Migração e compatibilidade de versões

cHash é funcionalidade Core, não uma extensão, e existe desde TYPO3 v4. A configuração mudou ao longo das versões: no TYPO3 v8 e anterior era controlada via TypoScript, a partir da v9 via arrays PHP na LocalConfiguration, a partir da v12 adicionalmente via Site Configuration.

Na migração de TYPO3 v9/v10 para v12/v13, configurações cHash existentes devem ser verificadas. Os nomes de parâmetros das extensões podem ter mudado (p.ex. alterações de namespace de plugin Extbase). O caminho mais seguro: após o upgrade, testar sistematicamente todas as páginas com parâmetros (paginação, filtros, busca) e verificar o Error Log do TYPO3 para entradas cHash.

TYPO3 v13 endurece a verificação cHash ainda mais: parâmetros desconhecidos levam por padrão a um 404, o modo debug deve ser explicitamente ativado. A Gosign verifica em todo projeto de upgrade TYPO3 a configuração cHash como parte do processo de garantia de qualidade.
---

--- calendarize_news TYPO3 - Kalender | Gosign ---
> Ponte entre ext:news e ext:calendarize. Gerencie notícias com datas de calendário integradas. Ideal para sites com eventos e notícias combinados.

## Eventos em tx_news pertencem a um calendário, não a uma lista cronológica

A maioria dos sites TYPO3 usa tx_news de Georg Ringer para tudo: notícias, artigos de blog, comunicados de imprensa e eventos. Para os três primeiros tipos, a listagem cronológica funciona. Para eventos, não. Visitantes esperam uma visualização em calendário com exibição mensal, semanal e diária. Querem clicar em uma data e ver o que acontece naquele dia. calendarize_news constrói exatamente essa ponte: pega registros tx_news existentes com campos de data e os renderiza como calendário.

A extensão evita a troca para um sistema de eventos independente. Quem já usa tx_news mantém sua estrutura de dados, seus templates e seus processos editoriais. Em vez de uma segunda extensão com armazenamento de dados separado, há uma visualização em calendário sobre dados existentes.

## Cenários típicos de uso

**Calendário de eventos em sites corporativos.** Uma instituição educacional publica 150 seminários por ano via tx_news. Cada seminário tem data de início, data de término e horário. Sem calendarize_news, visitantes veem uma lista longa ordenada por data. Com calendarize_news, veem um calendário mensal, clicam no dia 15 de maio e encontram três seminários. A conversão da visualização em calendário para a página de detalhe foi 40% maior em um cliente do que da visualização em lista.

**Eventos recorrentes sem duplicação de dados.** Um encontro semanal, um webinar mensal, uma festa anual da empresa: sem funcionalidade de recorrência, o editor precisa criar 52 registros para o encontro semanal. calendarize_news suporta regras de repetição (diária, semanal, mensal, anual) com exceções. Um registro gera 52 entradas de calendário. Se um compromisso é cancelado, é marcado como exceção, não excluído.

**Páginas combinadas de notícias e eventos.** Muitas organizações mostram na página inicial "Novidades", uma mistura de notícias e eventos futuros. calendarize_news permite exibir os mesmos registros cronologicamente na lista de notícias e por data no calendário. Duas visualizações, uma fonte de dados, sem esforço de sincronização.

## Arquitetura técnica

calendarize_news estende tx_news com campos adicionais na tabela `tx_news_domain_model_news`: data de início, data de término, flag de dia inteiro, regra de repetição e datas de exceção. A lógica de repetição é implementada na extensão e gera compromissos virtuais em tempo de execução, sem criar um registro no banco de dados para cada compromisso individual.

A exibição do calendário é feita por templates Fluid que renderizam um grid mensal. Cada célula (dia) contém os eventos daquele dia. Os templates são completamente personalizáveis. Por padrão, a extensão fornece templates para visualização mensal, semanal e diária. A navegação entre meses funciona por AJAX ou carregamento de página clássico, configurável via TypoScript.

A integração com tx_news é profunda: calendarize_news se registra como plugin adicional (list type) e utiliza o padrão Repository de tx_news. Categorias, tags e restrições de acesso do tx_news são mantidos. Um evento atribuído à categoria "Interno" e visível apenas para usuários logados aparece no calendário também apenas após login.

A função de exportação iCal gera arquivos .ics para eventos individuais ou o calendário inteiro. Visitantes podem importar eventos diretamente no Outlook, Apple Calendar ou Google Calendar. A exportação usa o formato iCalendar (RFC 5545) e considera regras de repetição.

## Problemas frequentes e soluções

**Calendário não mostra eventos, embora haja notícias.** Causa mais frequente: os campos de data dos registros de notícias não estão preenchidos. tx_news tem um campo `datetime`, mas calendarize_news usa campos próprios para data de início e término. Após a instalação, registros de notícias existentes devem ser complementados com os campos calendarize. Solução: um script de migração que copia `datetime` para os campos calendarize leva 30 minutos de desenvolvimento.

**Problemas de performance com muitos eventos recorrentes.** Quando 50 eventos recorrentes geram 52 compromissos virtuais cada, a extensão precisa filtrar 2.600 entradas para a visualização mensal. Isso é perceptível em cada carregamento de página sem cache. Solução: cachear o cálculo de recorrência (calendarize_news suporta o Caching Framework do TYPO3) e limitar o intervalo de tempo. Eventos com mais de 12 meses no futuro não precisam ser calculados a cada request.

**Exibição responsiva do grid de calendário.** Um grid de 7 colunas para dias da semana funciona no desktop, mas não em smartphones. Os templates padrão de calendarize_news não são otimizados para mobile. Solução: adaptar os templates Fluid e renderizar uma visualização em lista em dispositivos móveis em vez do grid. Um breakpoint CSS em 768px é suficiente para alternar entre grid e lista.

## Migração e compatibilidade de versões

calendarize_news depende diretamente de tx_news e segue seu ciclo de versões com atraso. A versão estável atual suporta TYPO3 v11 e v12 com tx_news v10/v11. Para TYPO3 v13 existe uma versão beta no GitHub.

A alternativa calendarize (sem sufixo _news) de lochmueller é uma extensão de calendário independente que não se baseia em tx_news, mas traz um modelo de dados próprio. É mantida mais ativamente e suporta oficialmente TYPO3 v12 e v13. A mudança de calendarize_news para calendarize requer uma migração de dados: os dados de eventos devem ser transferidos da tabela tx_news para as tabelas calendarize.

Para projetos que migram para TYPO3 v13 e querem manter tx_news, o caminho mais pragmático é: usar a versão beta de calendarize_news ou construir a representação em calendário como template Fluid customizado diretamente em tx_news. O esforço para um template customizado é de 2 a 3 dias, o resultado é independente de manutenção de terceiros. A Gosign implementou ambos os caminhos e recomenda a variante adequada conforme a complexidade das regras de repetição.
---

--- camaliga TYPO3 - Listas flexíveis | Gosign ---
> Flexibles Listen-Plugin para TYPO3: Produtos, colaboradores, referências, tudo configurável via uma extensão. Alternative zu Custom Extensions.

## Para a maioria das listas no TYPO3, não é necessária uma extensão própria

Uma empresa quer mostrar referências no site: logo, nome do cliente, setor, descrição curta. Outra quer listar funcionários: foto, nome, departamento, telefone. Uma terceira precisa de uma visão geral de produtos: imagem, título, preço, link para página de detalhe. Três requisitos diferentes, um padrão comum: listas estruturadas com campos configuráveis. camaliga resolve esse padrão como extensão de listas genérica, em vez de desenvolver uma extensão customizada para cada tipo de lista.

A extensão de quizpalme está disponível há anos no TYPO3 Extension Repository e é mantida ativamente. Sua vantagem: um tipo de registro com campos flexíveis cobre 80% de todos os requisitos de lista. A desvantagem: quem precisa de modelos de dados muito específicos (relações aninhadas, multilinguismo no nível de campo, validação complexa) atinge limites.

## Cenários típicos de uso

**Listas de referências e clientes.** O uso mais frequente: logos e descrições de clientes ou projetos em uma exibição em grid. camaliga traz layouts prontos: grid, carrossel, acordeão, exibição em abas. Os dados são mantidos no backend TYPO3 como registros, a exibição é controlada por templates Fluid. Em um cliente com 120 referências, a página de referências baseada em camaliga ficou pronta em 3 dias, incluindo filtragem por setor.

**Páginas de equipe e funcionários.** Foto, nome, cargo, dados de contato, opcionalmente um texto curto. camaliga mapeia isso por seus campos padrão: título, subtítulo, imagem, descrição, link. Para campos adicionais (número de telefone, departamento), campos customizados podem ser acrescentados via TCA-Override. A alternativa seria EXT:tt_address, que é especializada em dados de endereço e para páginas de equipe frequentemente oferece demais e de menos ao mesmo tempo.

**Visões gerais simples de produtos sem funcionalidade de loja.** Empresas que querem apresentar produtos mas não vendê-los não precisam de uma loja. camaliga entrega uma lista de produtos com imagem, título, campo de preço e link para ficha técnica. Filtragem por categoria é possível via a atribuição de categorias integrada. Para 50 a 200 produtos sem carrinho, é mais eficiente que Aimeos ou bernetshop.

## Arquitetura técnica

camaliga é baseada em Extbase/Fluid e segue o padrão MVC. O tipo de registro central é `tx_camaliga_domain_model_content` e contém campos para título, subtítulo, descrição, descrição curta, imagem, link, categoria e vários campos customizados. Os campos são definidos no TCA e podem ser estendidos ou reduzidos via TCA-Override no sitepackage.

A exibição é feita por um plugin de frontend com layout configurável. No FlexForm do plugin, o editor seleciona: qual categoria exibir, qual layout usar, quantas entradas por página, se a paginação está ativa. Os layouts são templates Fluid que podem ser sobrescritos no sitepackage. camaliga fornece aproximadamente 15 layouts prontos, da lista simples ao grid filtrado com animação Isotope.

A filtragem por categoria utiliza as categorias de sistema do TYPO3. Cada registro camaliga pode ser atribuído a uma ou mais categorias. No frontend, um menu de filtro é gerado que filtra por JavaScript (Isotope ou filtro CSS) ou por carregamento de página. A variante JavaScript é mais rápida, a variante por carregamento de página é mais amigável ao SEO.

Para ordenação, camaliga oferece várias opções: por título, por data de criação, por ordenação manual (drag-and-drop no backend). A ordenação manual usa o campo `sorting` do banco de dados e funciona pelo mecanismo de ordenação padrão do TYPO3 no módulo List.

## Problemas frequentes e soluções

**Layouts parecem diferentes do esperado.** Os layouts incluídos do camaliga dependem de certos frameworks CSS (Bootstrap 3/4) ou bibliotecas JavaScript (Isotope, Masonry). Se o site usa outro framework, os estilos colidem. Solução: nunca usar os templates padrão, criar templates Fluid próprios no sitepackage. O esforço para um template próprio é de 1 a 2 horas, depois a exibição é totalmente controlável.

**Performance com mais de 500 registros.** camaliga carrega por padrão todos os registros de uma categoria e filtra no frontend por JavaScript. Com mais de 500 entradas, o tempo de carregamento inicial se torna perceptível (3 a 5 segundos com 1.000 registros com imagens). Solução: ativar paginação e limitar a quantidade por página a 20 a 50 entradas. Para filtragem baseada em JavaScript: ativar lazy loading de imagens e carregar dados via AJAX.

**Multilinguismo requer workaround.** camaliga suporta o tratamento de idiomas do TYPO3, mas a tradução de cada registro individual é trabalhosa com mais de 200 entradas. Solução: para listas puramente visuais (logos sem texto), um registro por idioma é suficiente. Para listas com texto, acelerar a tradução pelo workflow de tradução inline do TYPO3 ou escrever um script de migração que importa traduções via API DeepL para as versões de idioma.

## Migração e compatibilidade de versões

camaliga é mantida ativamente e suporta TYPO3 v11, v12 e, conforme o roadmap atual, também v13. A extensão segue o ciclo de release do TYPO3 com curto atraso. Instalação via Composer pelo Packagist é possível, instalação via TER também.

Quem migra de uma extensão customizada para camaliga precisa transferir os dados da tabela customizada para `tx_camaliga_domain_model_content`. Isso é um trabalho de SQL que na maioria dos casos pode ser concluído em menos de um dia. Na direção oposta: quem migra de camaliga para uma extensão Extbase própria pode usar a estrutura de dados como modelo.

Para requisitos mais complexos (registros aninhados, relações entre listas, controle de workflow), recomenda-se em vez de camaliga uma extensão Extbase customizada ou EXT:mask. A Gosign orienta sobre a solução adequada e implementa tanto soluções rápidas baseadas em camaliga quanto extensões individuais.
---

--- CAPTCHA TYPO3 - Proteção contra spam | Gosign ---
> Proteção contra spam para formulários TYPO3. A Gosign assessora entre CAPTCHAs visíveis (sr_freecap, hCaptcha).

## Por que a decisão sobre CAPTCHA não é uma questão técnica, mas de privacidade

CAPTCHA soa como uma decisão trivial: proteger o formulário contra bots, instalar uma extensão e pronto. Na prática, a pergunta é qual serviço se integra, qual consentimento se gera e qual taxa de conversão se aceita. Para TYPO3 existem cerca de uma dezena de abordagens que se dividem em três grupos: CAPTCHAs visíveis com tarefa visual, análises comportamentais invisíveis como reCAPTCHA v3 e métodos puramente server-side sem interação do usuário, como honeypots ou rate limiting. A escolha certa depende menos da força dos bots do que da situação regulatória e do público do formulário.

## Cenários típicos de uso

Uma software house B2B brasileira opera um formulário de contato com cerca de 300 contatos reais por mês e cerca de 8.000 envios de bot. A empresa já usa Google Analytics, tem uma solução de consentimento rodando e não perde base legal ao instalar o reCAPTCHA v3. Neste caso, a solução invisível é eficaz: bots são bloqueados nos bastidores, usuários reais não veem nada, a taxa de conversão permanece estável. O consentimento já vem pelo banner existente.

Uma prefeitura municipal com formulários online para serviços ao cidadão tem o cenário oposto: Google não pode ser integrado, o banner de consentimento deve ser mínimo, e o formulário também precisa funcionar sem JavaScript. Aqui o reCAPTCHA está descartado imediatamente. A combinação honeypot mais rate limiting no reverse proxy mais uma conta matemática simples no formulário barra 95 por cento dos bots, não exige recurso externo e não gera obrigação de consentimento sob a LGPD (PT: RGPD).

Um terceiro caso é uma instituição de ensino com público muito variado: estudantes, professores, candidatos externos, parte deles com deficiência visual. Aqui a acessibilidade é mais importante que qualquer ganho de segurança, e um CAPTCHA puramente visual é problemático. A solução é um setup hCaptcha com modo de acessibilidade ativado ou uma instância sr_freecap com alternativa de áudio, complementada por rotulagem compatível com as diretrizes do e-MAG.

## Arquitetura técnica: três categorias, três padrões de integração

CAPTCHAs visíveis como sr_freecap ou hCaptcha funcionam via mecanismo request-response: a extensão gera ou obtém uma tarefa, a exibe ao usuário e, no envio, a entrada é validada no servidor. No TYPO3, a integração acontece via validator no Form Framework, via extensão de Fluid ViewHelper ou, no Powermail, via plugin de campo captcha. O desafio técnico é a sincronização de sessão e a integração em templates Fluid existentes.

CAPTCHAs invisíveis como reCAPTCHA v3 calculam um score entre 0 e 1 que descreve a probabilidade de que a requisição seja humana. O score chega como campo adicional no submit do formulário, e a extensão decide com base em um limiar configurável se aceita ou rejeita o envio. A grande vantagem é que o usuário não percebe nada, e a desvantagem é a transmissão inevitável de dados ao Google.

Soluções baseadas em honeypot funcionam sem lógica no cliente: um campo invisível é adicionado ao formulário HTML, oculto via CSS ou tabindex=-1. Humanos não preenchem, bots com frequência preenchem, e qualquer envio com honeypot preenchido é descartado no servidor. Complementado por rate limiting por IP e um intervalo de tempo verificável entre abertura da página e submit, isso bloqueia a maioria dos bots simples sem incomodar um único usuário.

## Problemas frequentes e soluções

O primeiro problema é a própria escolha: times correm por reflexo ao reCAPTCHA porque é conhecido e gratuito, e perdem de vista a obrigação de consentimento. A decisão limpa exige uma breve avaliação: qual infraestrutura de consentimento existe? Qual público deve usar o formulário? Qual a carga real de bots? A Gosign conduz essa avaliação no âmbito de uma auditoria curta e recomenda, por formulário, o método apropriado, em vez de forçar uma solução única.

O segundo problema é combinar vários mecanismos de proteção. Quem usa honeypot, CAPTCHA e rate limiting em paralelo cria redundância, mas também fontes de erro: um usuário legítimo falha em um dos três passos e perde a confiança no formulário. A resposta pragmática é escalonar os métodos e ativar só a proteção mais pesada em caso de comportamento suspeito, por exemplo, mostrar um CAPTCHA apenas quando a detecção de honeypot já soou ou quando vários envios do mesmo IP chegaram em um intervalo curto.

O terceiro tema é monitoramento. Equipes instalam uma proteção e esquecem que a eficácia cai assim que os bots desenvolvem padrões adaptados. Um setup CAPTCHA eficaz registra spam rate e falso-positivo rate e atualiza os limiares quando os números mudam. A Gosign configura esse monitoramento no âmbito da integração da extensão e entrega uma avaliação mensal, para que fique visível quando uma troca de fornecedor ou um ajuste se torne necessário.

## Migração e compatibilidade de versões

No TYPO3 v12 e v13, o Form Framework é o ponto central de integração para soluções CAPTCHA. Extensões que ainda se baseiam no antigo FormBuilder ou no tipo mailform do core precisam ser reconstruídas para o novo framework ao fazer upgrade, o que normalmente força também uma nova escolha de abordagem CAPTCHA. O Powermail continua sendo uma alternativa popular e fornece seus próprios tipos de campo CAPTCHA, mantidos em paralelo.

Quem migra de reCAPTCHA para uma solução compatível com a LGPD não só economiza uma obrigação de consentimento como também ganha tempo de carregamento: o script reCAPTCHA tem várias centenas de kilobytes e é recarregado por cada página com um formulário. Um setup honeypot funciona sem script externo. A Gosign acompanhou várias dessas migrações e entrega, conforme o modelo operacional, um setup puramente honeypot ou uma combinação com uma conta local, trivial para humanos mas barreira notável para bots.

--- Cloudinary TYPO3 - CDN e imagens | Gosign ---
> Cloudinary como driver FAL para TYPO3. Otimizar imagens automaticamente (WebP/AVIF), transformar (Crop, Resize) e entregar globalmente via CDN.

## Imagens são o maior problema de performance em sites TYPO3, e o Cloudinary resolve isso automaticamente

Em 90% dos sites TYPO3 que têm resultados ruins nos Core Web Vitals, imagens são o problema. Muito grandes, formato errado, sem variantes responsivas, sem CDN. O processamento interno de imagens do TYPO3 (GraphicsMagick/ImageMagick) gera thumbnails, mas sem otimização de formato (WebP/AVIF), sem detecção inteligente de crop e sem entrega automática via CDN mundial. Cloudinary como driver FAL do TYPO3 resolve todos os três problemas em um único passo.

Cloudinary armazena as imagens originais em sua nuvem, gera variantes otimizadas on-the-fly e as entrega via mais de 300 edge locations mundialmente. Uma imagem que foi enviada como JPEG de 4 MB chega ao visitante como AVIF de 120 KB, automaticamente, sem que o editor precise fazer nada.

## Cenários típicos de uso

**Sites corporativos com muitas mídias.** Um fornecedor automotivo com 3.000 imagens de produto, cada uma em 5 variantes (thumbnail, imagem de lista, imagem de detalhe, zoom, download), tem sem Cloudinary 15.000 arquivos no servidor. Com Cloudinary, 3.000 originais são armazenados, as 15.000 variantes o Cloudinary gera sob demanda. O armazenamento do servidor diminui 80%, os tempos de carregamento 60%. O Largest Contentful Paint (LCP) melhorou em um cliente de 4,1 para 1,3 segundos.

**Sites internacionais com público global.** Quando visitantes do Brasil, Japão e Alemanha acessam a mesma página, Cloudinary entrega as imagens do servidor edge mais próximo. Sem CDN, carregar uma imagem de 500 KB de um servidor em Frankfurt para um visitante em Tóquio leva 2 a 3 segundos. Com Cloudinary, menos de 200 milissegundos.

**Portais editoriais com alto volume de imagens.** Portais de notícias e revistas carregam novas imagens diariamente. Cloudinary descarrega o processo de upload: imagens são enviadas diretamente ao Cloudinary (Upload Widget ou API), processadas e apenas o caminho de referência é armazenado no TYPO3. Isso economiza carga do servidor e acelera o workflow editorial.

## Arquitetura técnica

A integração do Cloudinary no TYPO3 ocorre via driver FAL (File Abstraction Layer Driver). A extensão se registra como driver de armazenamento e sobrescreve as operações padrão de arquivo: upload, download, exclusão, listagem. Editores trabalham no backend TYPO3 habitual, veem imagens na Filelist e as inserem normalmente em elementos de conteúdo.

A geração de URL é o núcleo da integração. Em vez de uma URL de arquivo local (`/fileadmin/images/produto.jpg`), o driver gera uma URL Cloudinary com parâmetros de transformação: `https://res.cloudinary.com/[cloud-name]/image/upload/f_auto,q_auto,w_800/produto.jpg`. Os parâmetros `f_auto` (detecção automática de formato: WebP para Chrome, AVIF para Firefox, JPEG para navegadores antigos) e `q_auto` (ajuste automático de qualidade) são o padrão.

Transformações são controladas por parâmetros de URL: largura (`w_`), altura (`h_`), modo de crop (`c_fill`, `c_fit`, `c_thumb`), detecção de ponto focal (`g_auto` reconhece rostos e áreas importantes da imagem), overlay e marca d'água. Cada combinação gera uma variante própria que o Cloudinary gera na primeira chamada e depois cacheia.

A geração de breakpoints responsivos é especialmente valiosa: Cloudinary analisa uma imagem e calcula os breakpoints ideais baseados na mudança visual real entre os tamanhos. Em vez de breakpoints fixos em 320, 768 e 1024 pixels, Cloudinary fornece por exemplo 347, 691, 1024, porque ali estão as maiores diferenças visuais. Isso economiza banda sem perda de qualidade visível.

## Problemas frequentes e soluções

**Controle de custos com tráfego alto.** Cloudinary cobra por créditos: transformações, armazenamento e largura de banda consomem créditos. O plano gratuito é suficiente para aproximadamente 25.000 transformações por mês. Um site TYPO3 com 500 páginas e 3.000 imagens pode exceder isso no primeiro mês quando o cache está vazio. Solução: acionar invalidação de cache do Cloudinary apenas em alterações reais de imagem, não em cada deploy. Definir o formato de fetch como `auto` para que o Cloudinary gere apenas os formatos necessários.

**Busca de imagens no backend TYPO3 é lenta.** O driver FAL precisa consultar a API do Cloudinary a cada busca. Com mais de 10.000 imagens, isso demora perceptivelmente. Solução: usar o índice FAL do TYPO3 como fonte primária de busca e sincronizar com Cloudinary apenas quando necessário. O scheduler do indexador deve rodar à noite, não a cada acesso ao backend.

**URLs de imagens existentes mudam.** Após a migração de armazenamento local para Cloudinary, todas as URLs de imagem mudam. Isso afeta SEO (Google Image Search), links externos e páginas cacheadas. Solução: gerar URLs Cloudinary e ao mesmo tempo configurar redirects 301 dos caminhos antigos para as novas URLs. O EXT:redirects do TYPO3 pode fazer isso de forma automatizada.

## Migração e compatibilidade de versões

A extensão TYPO3-Cloudinary oficial no GitHub suporta TYPO3 v11 e v12. Para v13, a compatibilidade está em desenvolvimento. A extensão é mantida pela comunidade TYPO3, não pelo Cloudinary em si.

A migração de armazenamento local para Cloudinary ocorre em quatro passos: primeiro, criar uma conta Cloudinary e configurar a API Key; segundo, enviar os arquivos existentes via bulk upload (CLI Cloudinary ou API); terceiro, alterar a configuração de File Storage do TYPO3 para o driver Cloudinary; e quarto, reconstruir o índice FAL. Com 5.000 arquivos, todo o processo leva aproximadamente um dia de trabalho.

Cloudinary oferece um plano gratuito (25 créditos/mês) suficiente para sites pequenos. Para sites corporativos com mais de 10.000 imagens e tráfego alto, o plano Plus custa aproximadamente 89 USD/mês. A Gosign implementou integrações Cloudinary para projetos TYPO3 com até 100.000 imagens e orienta sobre otimização de custos e estratégias de transformação.
---

--- CORS TYPO3 - Cabeçalhos Cross-Origin | Gosign ---
> Configuração de cabeçalhos Cross-Origin Resource Sharing para TYPO3. Necessário para acessos de API, TYPO3 headless ou arquiteturas de microsserviços.

## Por que projetos headless TYPO3 falham imediatamente sem uma configuração CORS correta

Assim que um sistema TYPO3 deixa de apenas renderizar HTML e passa a entregar APIs JSON a clientes JavaScript em outros domínios, o navegador esbarra na Same-Origin Policy. Sem cabeçalhos Cross-Origin Resource Sharing (CORS) explícitos, ele bloqueia qualquer chamada fetch que venha de uma origem diferente da API. Para qualquer abordagem headless TYPO3, integração de microsserviços e setup em que um frontend em app.example.com.br conversa com um backend em cms.example.com.br, uma configuração CORS limpa é o requisito básico. Ela não cabe em uma única extensão, mas é um jogo de cena entre middleware TYPO3, configuração de webserver e setup de reverse proxy.

## Cenários típicos de uso

Um varejista online brasileiro com 40.000 pedidos por mês opera um catálogo de produtos em TYPO3 e um storefront React em um domínio separado. O storefront consulta dados de produto, estoque e informações de preço via API JSON implementada como middleware TYPO3. Sem cabeçalhos CORS corretos, o navegador bloqueia toda chamada AJAX com a mensagem "has been blocked by CORS policy", e o storefront fica vazio. A solução é uma middleware que define Access-Control-Allow-Origin precisamente para os domínios de frontend conhecidos e responde corretamente aos preflight OPTIONS requests.

Um segundo caso é uma empresa que opera TYPO3 como content hub para vários sites de marcas. Cada marca tem um domínio próprio, mas renderiza certos módulos como listagens de notícias ou imagens de produto no cliente a partir da instância central TYPO3. Aqui o CORS precisa ser configurado de forma que todos os domínios de marca sejam permitidos, mas domínios desconhecidos não. Uma verificação dinâmica de origem contra uma whitelist na site configuration do TYPO3 é a abordagem correta, em vez de um wildcard genérico.

O terceiro contexto são consórcios científicos brasileiros, como redes ligadas à FAPESP ou ao CNPq, que mantêm uma base de dados de pesquisa em TYPO3 e oferecem acesso mundial a instituições via API aberta. Aqui a política CORS é deliberadamente aberta, mas precisa ser combinada com uma camada de autenticação, de modo que toda origem possa chamar a API, mas só receba dados com um token válido.

## Arquitetura técnica: middleware, PSR-15 e preflight

No TYPO3 v12 e v13, o lugar correto para cabeçalhos CORS é uma middleware PSR-15 inserida na request pipeline. Ela verifica o header Origin da requisição de entrada, compara com uma whitelist configurada e define os cabeçalhos Access-Control-Allow-Origin, Access-Control-Allow-Methods e Access-Control-Allow-Headers na resposta. Para requisições POST, PUT ou DELETE com headers customizados, o navegador envia primeiro um preflight OPTIONS, que a middleware precisa responder sem autenticação, caso contrário a requisição real falha.

A configuração pode ser mantida via site configuration como array YAML, alternativamente diretamente no ext_localconf.php da extensão própria. É importante saber que o tratamento de credentials (cookies, Authorization header) só funciona se Access-Control-Allow-Credentials estiver como true e Access-Control-Allow-Origin apontar para uma origem concreta, não para um wildcard. Essa combinação é padrão CORS e fonte de erro frequente em times que testam primeiro com wildcard e depois tentam ligar credentials.

## Problemas frequentes e soluções

O primeiro problema é a duplicação de headers. Se o TYPO3 seta um header e o Apache ou Nginx seta adicionalmente o mesmo header na configuração do webserver, dois valores chegam ao navegador, que rejeita a requisição como malformada. A solução é definir o CORS em exatamente um lugar, seja na middleware TYPO3 ou no webserver, e manter o outro deliberadamente vazio. Em reverse proxies como Traefik ou Cloudflare, entra ainda uma terceira camada que também pode manipular headers.

O segundo problema são preflight OPTIONS requests. O navegador envia um OPTIONS request para verificar, antes da chamada real, se o método é permitido. Middlewares TYPO3 que primeiro autenticam e depois definem cabeçalhos CORS rejeitam o OPTIONS request porque ele não traz Authorization header. A solução é interceptar preflight requests cedo na cadeia de middleware e respondê-los sem autenticação.

O terceiro tema é a combinação de CORS com caching. Um reverse proxy como Varnish cacheia uma resposta com certos cabeçalhos CORS, e na próxima chamada de outra origem essa origem recebe os cabeçalhos antigos. A consequência é que usuários legítimos vêem erros CORS de repente, porque recebem uma resposta cacheada destinada a outra origem. Um Vary header em Origin resolve o problema, mas força o cache a várias variantes por recurso.

## Migração e compatibilidade de versões

O TYPO3 v11 ainda não oferecia uma API de middleware limpa para todos os contextos, de modo que a configuração CORS era frequentemente resolvida via hooks ou diretamente no webserver. A partir da v12, a middleware PSR-15 é o caminho previsto, e o caminho de migração de instalações mais antigas consiste em mover as manipulações de header da configuração Apache ou Nginx para a middleware TYPO3.

Para setups headless em TYPO3 v13 em combinação com a EXT:headless da Macopedia, o CORS é um bloco elementar e é tratado explicitamente na documentação da extensão. A Gosign implementou vários projetos headless assim e acompanha, se necessário, a coordenação entre times que cuidam de frontend e backend separadamente, de forma que as regras CORS fiquem documentadas de forma inequívoca e sejam sincronizadas a cada mudança de deploy. Uma regra errada abre um vetor de ataque em que sites maliciosos podem executar ações em nome do usuário autenticado, motivo pelo qual uma whitelist limpa não é questão de conforto, mas exigência de segurança.

Também vale notar que o CORS não substitui autenticação. Muitos times configuram regras CORS generosas acreditando que isso torna a API segura, e esquecem que cada origem que o navegador permite tem o mesmo acesso que um cliente chamado diretamente. A autenticação precisa ser feita independentemente do CORS, via tokens, API keys ou cookies de sessão, e o CORS apenas garante que navegadores permitam chamadas legítimas a esses endpoints autenticados. Quem entende essa separação configura regras CORS muito mais restritivas e fecha muitas brechas não intencionais.

--- Countdown TYPO3 - Extensão de cronômetro | Gosign ---
> Extensão TYPO3 para cronômetros regressivos: Contagens regressivas para eventos, lançamentos de produtos, prazos de ofertas.

## Extensões de countdown resolvem um problema de comunicação que textos puros não conseguem

Quando uma feira começa em 23 dias, quando a oferta de early bird expira à meia-noite ou quando a nova loja entra no ar em 1 de maio, um texto como "Faltam poucos dias" não basta. Usuários reagem muito mais fortemente a relógios em contagem do que a datas estáticas, e em uma página TYPO3, a variante mais simples é inserir um timer de countdown visível. Várias extensões TYPO3 do TER oferecem essa funcionalidade, a mais conhecida é simplesmente "countdown". Para todo site corporativo com anúncios de evento, lançamentos de produto ou ações por tempo limitado, essa é uma exigência recorrente que sem extensão costuma acabar em JavaScript individual. A escolha entre extensão e solução própria raramente depende da técnica, mas da pergunta de quem, na redação, deve conseguir manter o countdown.

## Cenários típicos vão de feiras a ações de e-commerce

O primeiro cenário são feiras e congressos. Uma associação anuncia seu congresso anual com seis meses de antecedência e quer tornar visível o tempo restante, idealmente com dias, horas, minutos e segundos. O countdown roda na landing page, ajusta-se nas últimas 24 horas e desaparece automaticamente após o encerramento do evento, sem que um redator precise ajustar a página. Isso economiza não só esforço de manutenção como também evita situações constrangedoras, como um counter que continua mostrando valor negativo depois do evento.

Um segundo cenário são lançamentos de produto e janelas de pré-venda. Projetos e-commerce baseados em aimeos ou lojas externas usam countdowns em landing pages para vincular clientes à data de início. Em pré-vendas, o countdown serve como sinal de urgência e comprovadamente aumenta a conversão.

Um terceiro cenário são prazos de candidatura e solicitação. Universidades brasileiras mostram na página de inscrição um countdown até o fim do prazo, associações usam para preços early bird, instituições públicas para prazos de submissão em editais. Aqui não se trata de marketing, mas de serviço: os visitantes devem reconhecer de relance quanto tempo lhes resta. Para portais de candidatura em pesquisa científica, isso é praticamente padrão, porque editais de fomento trabalham com deadline fixa e cut-off rígido.

## Arquitetura técnica combina template Fluid e JavaScript mínimo

Extensões de countdown clássicas no TYPO3 consistem em duas partes. A parte backend é um content element ou plugin no qual o redator mantém data alvo, hora alvo, fuso horário, label e, opcionalmente, uma mensagem de encerramento. A parte frontend renderiza esses dados em um template Fluid e anexa um pequeno JavaScript que calcula a diferença para o momento atual e atualiza no DOM.

A maioria das extensões traz também uma configuração para a renderização: número de casas (dias, horas, minutos, segundos), apresentação como gráfico circular ou flip clock, cores e animação. O JavaScript roda tipicamente com um setInterval de 1000 ms e calcula no cliente, de modo que o server cache permanece intocado. É importante que o timer não termine em valor negativo, mas mostre via event uma mensagem "Evento começou" ou "Oferta encerrada".

Para projetos críticos quanto à LGPD (PT: RGPD), vale um olhar nas dependências JavaScript. Algumas extensões carregam jQuery ou MomentJS, o que gera render path adicional. Variantes modernas se satisfazem com poucas linhas de vanilla JS e um CSS grid, que funciona inclusive sem extensão.

## Problemas frequentes envolvem fusos horários, caching e SEO

O tema de suporte mais frequente é o fuso horário. O redator registra uma data no backend, o servidor está em UTC, o visitante vive em BRT, e o countdown mostra uma hora a mais ou a menos. A extensão precisa distinguir claramente entre hora do servidor, hora de edição no backend e hora do navegador. Recomendamos sempre passar a data alvo em ISO-8601 com fuso explícito ("2026-05-01T12:00:00-03:00") para o JavaScript.

O segundo problema é o page cache. Se a página HTML renderizada está cacheada por uma hora, o countdown não pode conter um "23 dias 7 horas" calculado no servidor, porque o cache hit congela esse valor. A solução: a parte Fluid renderiza apenas a data alvo como data attribute, o cálculo da diferença roda exclusivamente no navegador.

Em terceiro, SEO é um ponto. Um countdown puramente JavaScript não mostra ao Google nem a data alvo nem o motivo. Para mecanismos de busca, um JSON-LD schema:Event deve entrar na página, com startDate, endDate e name, para que resultados do Google exibam o evento como rich snippet. Quem instala a extensão deve, portanto, passar a data alvo não só para o timer, mas também escrevê-la como dados estruturados no header da página. Sem essa marcação, o countdown fica invisível para o Google e perde seu efeito de marketing já no resultado de busca.

## TYPO3 v12 e v13: extensão ou construção alternativa enxuta

Se uma extensão de countdown em TYPO3 v12 e v13 ainda faz sentido depende da envergadura do projeto. Em uma única página de evento, basta um content element pequeno com um data attribute e 30 linhas de JavaScript, sem overhead de extensão. Para redações com muitos eventos que querem manter o timer elas mesmas, a extensão se justifica porque redatores precisam de um elemento de UI conhecido no backend.

A Gosign constrói, na prática, os dois: para lançamentos únicos, entregamos um content element enxuto sem extensão, formado apenas por um template Fluid e mini JS. Para casos de uso recorrentes, integramos uma extensão mantida e sobrescrevemos o template Fluid para adaptar o design ao restante do projeto. No upgrade de extensões countdown antigas, quase sempre faz sentido mudar para a variante vanilla, porque versões antigas baseadas em jQuery não acompanham o TYPO3 v12 nem os budgets modernos de performance.

--- DCE TYPO3 - Elementos de conteúdo dinâmicos | Gosign ---
> DCE: Elementos de conteúdo personalizados sem PHP. Configuração, migração para Mask/Container. acelerada com IA desenvolvimento.

## DCE foi por anos a primeira escolha para Custom Content Elements - agora a migração é necessária

Entre 2013 e 2020, DCE (Dynamic Content Elements) era junto com Mask o método mais popular para construir elementos de conteúdo próprios no TYPO3. Editores recebiam formulários de backend com exatamente os campos necessários, desenvolvedores definiam tudo via GUI, sem escrever uma linha de PHP ou TCA. Milhares de sites TYPO3 ainda rodam com DCE. O problema: o desenvolvimento desacelerou significativamente. Mask ultrapassou DCE em uso, e a partir do TYPO3 v13, com a API nativa Content Block, existe uma terceira alternativa que não requer overhead de extensão.

Quem tem DCE em uso não precisa migrar imediatamente. Mas quem planeja um upgrade TYPO3 para v12 ou v13 deve planejar a substituição, pois o suporte de longo prazo é incerto.

## Cenários típicos de uso

**Projetos existentes com 10 a 50 elementos DCE.** Sites corporativos de médio porte construídos entre 2014 e 2020 com TYPO3 v7 a v10 usam DCE para tudo: caixas de teaser, abas, acordeões, galerias de imagens, blocos de citação, cartões de equipe. Os elementos funcionam, mas estão vinculados ao DCE. Em um upgrade TYPO3, é necessário verificar se o DCE roda na versão alvo.

**Agências com múltiplos projetos TYPO3.** Agências que usaram DCE como padrão em seus projetos enfrentam a questão: migramos todos os projetos de uma vez (grande esforço, corte limpo) ou projeto por projeto no próximo upgrade (passos menores, período mais longo)? A resposta depende do número de projetos afetados e da versão TYPO3 alvo planejada.

**Prototipagem rápida para elementos de conteúdo.** DCE é adequado para protótipos rápidos: um novo elemento de conteúdo é configurado em 15 minutos, incluindo formulário de backend e template Fluid. Para provas de conceito ou apresentações a clientes, isso pode ser suficiente. Para projetos produtivos, a Gosign recomenda Mask, pois o workflow de exportação (mask_export) e a manutenção ativa oferecem vantagens de longo prazo.

## Arquitetura técnica

DCE armazena definições de elementos de conteúdo no banco de dados (tabela tx_dce_domain_model_dce), não em arquivos. Cada elemento DCE consiste em uma configuração (campos, tipos, validação), um template Fluid (diretamente no backend ou como referência de arquivo) e layouts de backend opcionais. Os campos são definidos na GUI do DCE: Text, RichText, Integer, Float, Date, File (FAL), Select, Checkbox, Group (IRRE), Section (fieldsets repetíveis).

Ao salvar, DCE gera a configuração TCA necessária e registra o elemento no Content Element Wizard. Os dados dos elementos de conteúdo ficam na tabela tt_content, estendida por campos FlexForm específicos do DCE. Essa arquitetura FlexForm é uma das principais diferenças para o Mask, que cria colunas de banco de dados próprias no tt_content.

## Problemas frequentes e soluções

**Dados FlexForm são difíceis de migrar.** Como DCE armazena dados como XML FlexForm no tt_content, uma migração para Mask (que usa colunas próprias) não é trivial. O XML FlexForm deve ser parseado e os valores transferidos para os novos campos Mask. Solução: um script de migração que, por elemento DCE, lê os campos FlexForm e os escreve nos campos Mask correspondentes. A Gosign possui um comando CLI reutilizável que automatiza esse processo por elemento.

**Containers DCE e elementos aninhados.** DCE oferece uma lógica de container própria que aninha elementos de conteúdo uns dentro dos outros. Essa lógica é proprietária e não é compreendida por nenhum outro sistema. Solução na migração: converter estruturas de container para b13/container e reconstruir os elementos filhos como elementos Mask.

**Performance com muitas definições DCE.** Sites com mais de 40 elementos DCE têm tempos de carregamento perceptíveis no backend, porque todas as configurações FlexForm são lidas e parseadas do banco de dados a cada chamada. Solução: ativar cache DCE ou migrar para configuração baseada em arquivos.

## Migração e compatibilidade de versões

DCE suporta TYPO3 v11 e v12. A compatibilidade com TYPO3 v13 é limitada: existe um branch de desenvolvimento, mas nenhum release oficialmente marcado como estável (status abril 2026).

Para a migração de DCE para Mask, a Gosign tem um processo padronizado: inventariar elementos DCE (campos, tipos, templates), reconstruir elementos Mask 1:1, migrar dados via script SQL (FlexForm XML para colunas Mask), adaptar templates Fluid, testar e desinstalar DCE. O esforço fica entre 0,5 e 2 horas por elemento, dependendo da complexidade. Um projeto com 25 elementos DCE é migrado em 3 a 5 dias.

A Gosign recomenda na decisão de migração uma análise pragmática de custo-benefício. Se o próximo upgrade TYPO3 está previsto para dentro de 12 meses e o DCE não roda de forma estável na versão alvo, a migração é inevitável. Se o projeto permanecerá mais 2 a 3 anos no TYPO3 v11 ou v12 e o DCE funciona de forma estável ali, a migração pode ser adiada para o próximo relançamento. Em todo caso, deve-se definir já agora se o alvo é Mask ou Content Block API, para que novos elementos de conteúdo sejam criados diretamente no sistema alvo.

Os custos totais de uma migração DCE dependem da quantidade e complexidade dos elementos. Um projeto com 15 elementos DCE simples (texto, imagem, link) é migrado em 2 dias. Um projeto com 40 elementos, dos quais 10 com aninhamento IRRE e 5 com lógica de container, precisa de 8 a 12 dias.

--- TYPO3 Templates & Sitepackages | Gosign ---
> Template-Paket para TYPO3. A Gosign sempre recomenda sitepackages personalizados em vez de templates prontos, exatamente adaptados às suas necessidades.

## Templates TYPO3 prontos economizam tempo no curto prazo e custam mais no longo prazo

A tentação é grande: comprar um template TYPO3 pronto por 79 euros, instalar, trocar o logo, pronto. Na realidade, começa aí um ciclo de workarounds, overrides e conflitos de versão que dificulta cada atualização e freia a evolução. dmpr_template é exemplar para essa categoria. A Gosign recomenda em vez disso Custom Sitepackages: pacotes de template individuais, exatamente adaptados aos requisitos, mantidos e versionáveis.

Um sitepackage é uma extensão TYPO3 que contém toda a configuração de frontend: TypoScript, templates Fluid, Partials, Layouts, CSS/SCSS, JavaScript e Backend Layouts. É a melhor prática oficial do TYPO3 desde a versão 8 e substitui o método antigo de configurar templates no sistema de arquivos.

## Cenários típicos de uso

**Relaunch corporativo com requisitos individuais.** Uma empresa inicia um relaunch do site. O design está como arquivo Figma, a arquitetura de informação como sitemap, os tipos de conteúdo estão definidos. Um sitepackage customizado traduz essas especificações 1:1 para o TYPO3: cada tipo de conteúdo é mapeado como Backend Layout ou Custom Content Element, os templates Fluid correspondem ao design com precisão de pixel. Nenhum framework de template fica no meio forçando compromissos.

**Setup multi-site com componentes compartilhados.** Uma corporação opera 5 sites de marcas em uma instância TYPO3. Todos compartilham um sitepackage base com sistema de grid, tipografia e componentes base. Cada marca tem um sitepackage próprio que estende a extensão base: cores, logo, layouts específicos da marca. Alterações na base se refletem em todos os 5 sites, sem precisar manter 5 codebases separados.

**Migração de configurações de template antigas.** Instalações TYPO3 das versões 6 ou 7 frequentemente usam TemplaVoilà, Fluid Styled Content com overrides TypoScript extensivos ou até templates baseados em marcadores. A migração para um sitepackage limpo moderniza todo o stack de frontend em um passo: longe de configurações TypoScript globais, rumo a uma extensão versionável com estrutura de diretórios clara.

## Arquitetura técnica

Um sitepackage é uma extensão TYPO3 regular com uma estrutura de diretórios definida:

`Configuration/TypoScript/` contém a configuração TypoScript: Constants, Setup, Page-TSconfig. Aqui é definido quais templates valem para quais tipos de página, quais elementos de conteúdo estão disponíveis e como são renderizados.

`Resources/Private/Templates/` contém os templates Fluid para tipos de página (Page), elementos de conteúdo (ContentElements) e Partials (fragmentos de template reutilizáveis). A separação em Templates, Partials e Layouts segue a convenção Fluid do TYPO3.

`Resources/Public/` contém CSS/SCSS, JavaScript, imagens e fontes. Tudo que o navegador entrega diretamente. Em setups modernos, SCSS é compilado por ferramentas de build (Vite, Webpack) e os arquivos gerados ficam em `Resources/Public/Build/`.

`Configuration/TCA/` define Backend Layouts e Custom Content Elements. Backend Layouts controlam quais colunas e áreas estão disponíveis em uma página no backend. Custom Content Elements são definidos via TCA, TypoScript e templates Fluid.

O sitepackage é instalado via Composer e atribuído à respectiva TYPO3 Site pela Site Configuration (config.yaml). Vários sites podem usar o mesmo sitepackage (multi-site) ou cada um ter o próprio.

## Problemas frequentes e soluções

**Templates prontos colidem com atualizações do TYPO3.** Templates comprados frequentemente sobrescrevem configurações do Core e definições TCA de uma forma que quebra em atualizações do TYPO3. Um template desenvolvido para TYPO3 v10 frequentemente não funciona após atualização para v12, porque TCA Wizards, registro de Backend Layout e Fluid ViewHelpers mudaram. Com um sitepackage customizado, controla-se quais funcionalidades do Core são utilizadas e atualizações podem ser feitas gradualmente.

**Estrutura do sitepackage cresce descontroladamente.** Ao longo dos anos, acumulam-se dezenas de Partials, templates órfãos e fragmentos TypoScript em um sitepackage. Solução: refactoring regular. Um sitepackage limpo tem no máximo 20 a 30 Partials, convenções claras de nomenclatura (PascalCase para templates, pastas por função) e nenhum arquivo não utilizado. O esforço para um refactoring é de 2 a 5 dias, dependendo do tamanho.

**Conflitos de especificidade CSS com Fluid Styled Content.** O Fluid Styled Content do TYPO3 traz classes CSS próprias (`ce-`, `frame-`). Se o sitepackage usa classes próprias, surgem conflitos de especificidade. Solução: substituir completamente o Fluid Styled Content por definições próprias de elementos de conteúdo (mais limpo, mas mais trabalhoso) ou sobrescrever os templates Fluid Styled Content e adaptar as classes.

## Migração e compatibilidade de versões

O conceito de sitepackage é o padrão desde TYPO3 v8 e é desenvolvido em cada nova versão do TYPO3. A estrutura fundamental (extensão com TypoScript, templates Fluid, TCA) permanece estável. Ajustes em atualizações major normalmente afetam sintaxe TCA (Wizards, renderTypes), condições TypoScript (nova: Symfony Expression Language) e registro de módulos backend.

A migração de um template pronto (dmpr_template, j77_template, in2template) para um sitepackage customizado é uma reescrita, não uma portabilidade. Analisa-se os templates existentes, extrai-se a funcionalidade desejada e constrói-se em uma estrutura de sitepackage limpa. Para um projeto típico com 10 tipos de página e 15 elementos de conteúdo, o esforço é de 2 a 3 semanas.

TYPO3 v13 introduz Content Blocks como novo conceito para definições de elementos de conteúdo. Content Blocks simplificam consideravelmente a criação de Custom Content Elements e reduzem o código boilerplate. Sitepackages não são afetados, podem utilizar Content Blocks adicionalmente. A Gosign constrói exclusivamente sitepackages customizados há anos e tem experiência para migrar configurações de template existentes eficientemente para estruturas modernas.
---

--- Alternativa ao Doodle TYPO3 | Gosign ---
> Agendamento de horários diretamente no TYPO3, como Doodle, mas sem serviço externo. Amigável à privacidade, integrado ao próprio site. Für interne.

## Agendamentos de reuniões pertencem ao próprio site, não a um serviço americano

Doodle é prático: enviar link, participantes escolhem seus horários, a reunião está marcada. Mas Doodle é um provedor terceirizado com servidores nos EUA, com tracking, com publicidade no plano gratuito. Para empresas com consciência sobre LGPD (PT: RGPD), para instituições públicas e para toda organização que não quer encaminhar dados de usuários a serviços externos, isso é um problema. Uma alternativa ao Doodle diretamente no TYPO3 resolve esse problema: agendamento de reuniões na própria infraestrutura, sem cookies de terceiros, sem vazamento de dados.

O público-alvo é claro: organizações que regularmente agendam reuniões com participantes externos (reuniões de pais, sessões de comitê, workshops, treinamentos) e querem manter o controle sobre os dados.

## Cenários típicos de uso

**Instituições educacionais com coordenação de reuniões de pais.** Escolas e creches coordenam reuniões de pais várias vezes por ano. 30 famílias devem escolher de 5 horários possíveis o melhor. Via plugin TYPO3 no site da escola, a votação ocorre sem necessidade de conta e sem serviços externos. Os resultados ficam no servidor da escola. Em um órgão escolar com 12 escolas e 6.000 famílias no total, a integração TYPO3 eliminou completamente a assinatura Doodle Premium (480 EUR/ano).

**Órgãos públicos e instituições governamentais.** Administrações municipais e órgãos estaduais frequentemente não podem usar serviços de nuvem que processam dados fora do país. Uma votação de horários baseada em TYPO3 atende às diretrizes de TI governamentais, pois os dados permanecem no próprio servidor ou no data center do órgão. No Brasil, a LGPD impõe requisitos similares de controle sobre dados pessoais.

**Planejamento interno de workshops corporativos.** Workshops entre departamentos, reuniões de estratégia ou treinamentos exigem agendamentos com 10 a 50 participantes. Pelo intranet (baseado em TYPO3), a votação pode ser incorporada diretamente, sem enviar um link externo que possivelmente seria bloqueado pelo proxy da empresa.

## Arquitetura técnica

Uma alternativa ao Doodle no TYPO3 se baseia em um plugin Extbase com três tabelas de banco de dados: votações (Polls), opções de horário (Options) e votos (Votes). A votação é colocada como elemento de conteúdo em uma página TYPO3. Participantes abrem a página, veem as opções de horário e selecionam suas janelas de disponibilidade.

A entrada de dados ocorre por um formulário baseado em Fluid. Cada opção de horário é exibida como linha, o participante marca checkboxes (sim/não/talvez). Opcionalmente, o nome do participante é solicitado. Para usuários autenticados (frontend login), a extensão pode preencher o nome automaticamente e prevenir votações duplicadas.

A exibição de resultados mostra uma matriz: colunas para participantes, linhas para opções de horário, células coloridas. O horário com mais confirmações é destacado. Uma visualização de admin no backend TYPO3 mostra todas as votações com resultado e permite fechar ou arquivar votações concluídas.

Notificações por e-mail são opcionalmente integráveis: nova votação criada, novo participante votou, votação encerrada. Os e-mails usam a Mail API do TYPO3 e podem ser personalizados via templates Fluid.

A conformidade com a LGPD requer: exclusão automática dos dados de votação após um período configurável (p.ex. 30 dias após o término da votação), nenhum cookie para a participação na votação (baseado em sessão) e uma política de privacidade que nomeie o propósito e o período de armazenamento.

## Problemas frequentes e soluções

**Votações de spam.** Sem proteção, bots ou trolls podem enviar centenas de votos falsos. Solução: campo honeypot (campo de formulário invisível que só bots preenchem), rate limiting (máximo 3 votações por IP por hora) e opcionalmente um CAPTCHA simples. Frontend login como obrigatório elimina spam completamente, mas restringe a usabilidade para participantes externos.

**Falta de integração com calendário.** Participantes querem transferir o horário definido diretamente para seu calendário. A maioria das alternativas TYPO3 ao Doodle não oferece exportação iCal. Solução: após o encerramento da votação, exibir um botão "Baixar compromisso" que gera um arquivo .ics. O esforço para a geração iCal é de aproximadamente 2 horas de desenvolvimento.

**Exibição mobile da matriz de votação.** Uma matriz com 10 opções de horário e 20 participantes não é legível no smartphone. Solução: em dispositivos móveis, converter a matriz em uma visualização em lista onde cada horário é exibido individualmente com botões Sim/Não. A visão geral de resultados também é exibida como lista vertical em vez de tabela horizontal.

## Migração e compatibilidade de versões

No TYPO3 Extension Repository existem várias extensões similares ao Doodle com diferentes escopos de funcionalidade e status de manutenção. Nenhuma se estabeleceu como padrão. Para TYPO3 v12 e v13, recomenda-se portanto um desenvolvimento customizado em base Extbase que cubra exatamente as funcionalidades necessárias e permaneça mantível a longo prazo.

O esforço de desenvolvimento para uma versão básica (criar votação, escolher horários, exibir resultado) é de 3 a 5 dias. Com notificação por e-mail, exportação iCal e backend de admin, de 7 a 10 dias. Isso é menos que um ano de assinatura Doodle Premium para mais de 15 usuários (a partir de 6,95 EUR/usuário/mês = aproximadamente 1.250 EUR/ano).

Para empresas que já usam Microsoft 365 ou Google Workspace, a solução TYPO3 é primariamente relevante para participantes externos. Agendamentos internos rodam mais eficientemente via Outlook ou Google Calendar. A solução TYPO3 complementa onde participantes externos sem conta devem participar. A Gosign desenvolve essas soluções customizadas em base Extbase e as integra em instalações TYPO3 existentes.
---

--- downloadmanager TYPO3 - Downloads de arquivos | Gosign ---
> downloadmanager: Datei-Downloads no TYPO3 organisieren, kategorisieren & tracken. acelerada com IA implementação.

## downloadmanager traz ordem a áreas de download TYPO3 quando um diretório de arquivos aninhado não basta, com categorias, tags, busca e um contador de downloads que dispensa cookies

Assim que um projeto TYPO3 passa a gerenciar mais de vinte downloads, a manutenção manual desaba. Redatores linkam PDFs via link browser, o diretório cresce caoticamente, documentos existentes são sobrescritos sem querer e visitantes não encontram mais nada via busca. O downloadmanager resolve exatamente esse problema: expõe o acervo de arquivos como repositório estruturado, com registros próprios, categorias, tags, metadados e uma interface que os usuários conseguem buscar de forma direcionada. Para empresas com fichas técnicas de produto, associações com coleções de formulários e prefeituras com centros de download, essa é a solução padrão.

A diferença em relação à gestão via pastas FAL puras é fundamental. Enquanto o fileadmin reflete um filesystem, o downloadmanager insere uma camada editorial por cima: um documento pode aparecer em várias categorias ao mesmo tempo, ter um título de exibição independente do nome de arquivo e ser controlado via planejamento de publicação. Para redações com exigências de compliance, isso costuma ser pré-requisito.

## Cenários típicos de uso

O caso clássico é o catálogo técnico de produto. Uma indústria metalúrgica brasileira mantém para cada máquina uma ficha técnica, um manual de operação, um certificado de conformidade (como o INMETRO exige) e uma lista de peças de reposição. Cada download recebe uma categoria de produto, uma atribuição de tipo e, opcionalmente, uma tag de idioma. Os visitantes filtram por linha de produto e tipo de documento, recebem imediatamente os arquivos certos, e a loja não precisa linkar cada PDF individualmente. A própria página de produto pode exibir uma mini área de downloads que lista automaticamente todos os documentos da máquina, sem duplicidade editorial.

O segundo caso são áreas de formulário em prefeituras, órgãos públicos e conselhos profissionais. Formulários de requerimento, cartilhas e estatutos são agrupados tematicamente, muitas vezes multilíngues, ocasionalmente com restrição de acesso para áreas internas de associados. O downloadmanager permite exatamente essa segmentação via fe_groups e categoriza documentos por área. Para a administração pública, também é importante que datas de publicação e prazos de validade possam ser geridos por documento.

Terceiro uso: áreas de imprensa e relações com investidores. Relatórios anuais, releases de imprensa e material fotográfico ficam em um repositório central, categorizados por ano e com data de publicação. A redação só precisa cadastrar cada documento uma vez, as listas do frontend são geradas automaticamente.

## Arquitetura técnica

O downloadmanager é uma extensão Extbase e mantém registros próprios em tx_downloadmanager_domain_model_download. Cada download referencia um ou mais arquivos FAL e carrega campos de meta como título, descrição, categoria, tags, data de publicação, idioma e grupos de acesso. O módulo de backend permite import em massa, bulk edit e workflows de publicação.

No frontend, a extensão entrega views prontos de lista e detalhe como templates Fluid. Listas podem ser filtradas por categoria, tag, termo de busca ou critério de ordenação, os parâmetros são passados via GET parameter e considerados no cache. Para a busca, a extensão usa a busca de texto MySQL ou, se solicitado, uma instalação Solr conectada.

A configuração é feita via TypoScript e FlexForm. Configurações típicas são a categoria padrão, o número de entradas por página, a ordem de classificação e a integração em um site package próprio. Via EventListener, desenvolvedores podem inserir lógica própria, por exemplo uma notificação por email em novos uploads ou uma exportação para outros sistemas.

O rastreamento de download é uma feature central. Em vez de analytics externo com cookies, o downloadmanager incrementa a cada clique um contador no servidor, guardado como simples coluna integer no registro. Isso é amigo da LGPD (PT: RGPD), não exige cookie banner e entrega uma afirmação consistente sobre quais documentos são realmente procurados.

## Problemas frequentes e soluções

O primeiro problema é a migração de um acervo antigo. Quem manteve downloads por anos via link browser precisa primeiro convertê-los em registros do downloadmanager. A solução é um script que percorre as estruturas fileadmin existentes, extrai metadados dos nomes de arquivo e cria os registros. A Gosign usa para isso uma pipeline com suporte de IA que sugere categorias e tags a partir do conteúdo e dos metadados PDF, deixando para a redação apenas a confirmação.

Segundo problema: caching. Listas filtradas com parâmetros de URL geram muitas variantes de cache, o que incha o cache do TYPO3. A solução está no tratamento de cHash e em uma definição limpa de quais parâmetros são relevantes para cache. Para páginas com muitos filtros, um edge caching via Cloudflare ou Varnish com regra consciente dos parâmetros pode ser mais sensato que o cache no servidor.

Terceiro problema: multilinguismo. Um documento existe em cinco idiomas, mas deve ser mantido como uma entrada lógica, para que os metadados fiquem sincronizados. Aqui o downloadmanager usa o mecanismo de idioma TYPO3 com registros de tradução. É importante que a redação entenda quais campos são mantidos por idioma e quais valem globalmente.

## Migração e compatibilidade de versões

O downloadmanager é mantido ativamente e é compatível com TYPO3 v11, v12 e v13. Em upgrades de versões TYPO3 antigas, vale atenção sobretudo a mudanças no Extbase: os métodos de repository e a camada de persistência mudaram várias vezes entre v9 e v12, o que pode quebrar extensões próprias da extensão. Um projeto de upgrade típico, portanto, também abrange a adaptação de controllers e templates próprios.

Para projetos que começam hoje, vale decidir antes se o downloadmanager ou uma solução com registros Extbase próprios é o caminho certo. Se a redação só precisa de downloads padrão com categorias e tags, a extensão é a escolha pragmática. Se além disso workflows complexos (aprovação, publicação em múltiplos passos, versionamento) são exigidos, uma solução sob medida pode ser mais fácil de manter a longo prazo.

A Gosign migra o downloadmanager para novas versões TYPO3, acompanha migrações de acervo antigo e integra a extensão em site packages existentes. Análise com suporte de IA ajuda a sugerir categorias e tags automaticamente a partir de nomes de arquivo e estruturas de diretório existentes, de forma que o trabalho manual de manutenção encolhe a um mínimo.

--- dp_cookieconsent TYPO3 - Consentimento de cookies | Gosign ---
> dp_cookieconsent para TYPO3: em conformidade com a LGPD gerenciamento de cookies. Configuração, auditoria e otimização , acelerada com IA análise.

## Por que um banner de cookies sozinho não garante conformidade com a LGPD

Toda instalação TYPO3 que incorpora Google Analytics, vídeos do YouTube, plugins de redes sociais ou fontes externas enfrenta a mesma tarefa desde a entrada em vigor da LGPD no Brasil: antes do carregamento de um script de terceiros, é necessário um consentimento ativo e informado do usuário. O dp_cookieconsent é a extensão mais difundida na comunidade TYPO3 que assume exatamente essa tarefa. Ela se destina a empresas que querem operar seu site em conformidade com a LGPD sem uma ferramenta externa de Consent Management, atendendo assim empresas de médio porte, órgãos públicos e instituições de ensino que não querem arcar com custos contínuos de CMPs comerciais.

## Cenários típicos de uso

Uma indústria brasileira com catálogo de produtos e 45 landing pages usa Google Analytics, um vídeo explicativo do YouTube, formulários do HubSpot e Google Fonts. Sem o dp_cookieconsent, todos esses serviços definiriam cookies assim que um usuário abrisse a página, expondo a empresa a questionamentos da ANPD (PT: CNPD) nos termos da LGPD. A extensão agrupa os serviços por categoria, carrega o código do HubSpot apenas após o consentimento de marketing e oferece Google Fonts em versão auto-hospedada, eliminando ali a necessidade de consentimento.

Um segundo quadro típico é o de uma universidade brasileira, como USP ou UFRJ, com um portal principal e vários sites descentralizados de faculdades. Cada faculdade mantém seus próprios conteúdos e incorpora seus próprios serviços, às vezes um mapa do OpenStreetMap, às vezes um vídeo do YouTube, às vezes um tracking Matomo. O dp_cookieconsent centraliza a gestão de consentimento na instalação principal, entrega o banner via Fluid Partials a todos os subsites e armazena o consentimento entre domínios, para que o usuário não precise consentir novamente em cada site de faculdade.

Um terceiro caso são prefeituras com formulários online e aplicações de mapa. Aqui, a complicação extra é que os encarregados de proteção de dados (DPOs) realizam auditorias regulares e exigem uma documentação completa dos serviços utilizados. O dp_cookieconsent entrega a categorização e o texto de privacidade diretamente via TypoScript, o que permite a manutenção pela equipe editorial sem intervenção de desenvolvedores.

## Arquitetura técnica: bloqueio de scripts no nível do template

O dp_cookieconsent funciona segundo o princípio de "type-attribute swapping": todos os scripts de terceiros no código-fonte não são entregues com type="text/javascript", mas com um tipo neutro como type="text/plain" e um atributo adicional data-cookieconsent. O navegador ignora tags assim e não as executa. Apenas quando o usuário consente no banner, um pequeno JavaScript substitui os atributos de tipo e dispara a execução atrasada. O mesmo mecanismo vale para iframes, que até o consentimento são exibidos como placeholders.

A configuração da extensão é feita totalmente via constantes e setup TypoScript, complementada por um arquivo YAML para as definições de serviço. Cada serviço é registrado ali com nome, descrição, categoria, nomes de cookie e tempo de vida do cookie, o que facilita significativamente a documentação posterior para o DPO. Fluid Partials definem a aparência do banner e do modal de configurações, permitindo adaptar o design à identidade visual sem alterar a extensão.

## Problemas frequentes e soluções

O primeiro e mais frequente problema: mesmo com o banner ativo, os scripts de terceiros carregam, porque são incorporados via caminhos de include que não passam pelo TypoScript. Típicos são blocos HTML estáticos, elementos de conteúdo Fluid com tags script hard-coded ou footer includes de templates mais antigos. Uma solução limpa exige um crawl completo do site com devtools do navegador ou uma ferramenta automatizada que registra todas as requisições de saída e compara quais delas são disparadas antes do consentimento.

O segundo problema é o armazenamento do consentimento. O dp_cookieconsent guarda a decisão em um cookie local, o que gera exibições repetidas do banner para usuários com configuração de navegador restritiva ou no modo anônimo. Quem quer medir taxas de consentimento precisa ativar adicionalmente um logging no servidor, que grava os consentimentos junto com timestamp e hash de IP em uma tabela de banco de dados, fornecendo documentação robusta para auditorias.

O terceiro tema é performance. O banner carrega um bundle JavaScript que, conforme o volume dos serviços configurados, pode ficar notavelmente grande e atrasar o First Contentful Paint. A Gosign otimiza a entrega via deferred loading, reduz Fluid Partials desnecessários e adota, sempre que possível, uma combinação de analytics sem cookies e assets auto-hospedados, de modo que o banner só seja necessário para poucos serviços.

Um quarto problema aparece em mudanças de consentimento: o usuário dá seu consentimento, usa o site, muda de ideia depois e revoga. O dp_cookieconsent reseta a flag do cookie, mas os scripts já carregados continuam rodando em segundo plano até o usuário recarregar a página. Uma solução limpa exige um trigger de reload ou a remoção direcionada de cookies já definidos no momento da revogação, para que a revogação de privacidade seja efetivamente aplicada e não apenas documentada formalmente.

## Migração e compatibilidade de versões

O dp_cookieconsent está disponível para TYPO3 v11, v12 e v13, sendo que a compatibilidade com a v13 é atualizada regularmente e atualmente é considerada pronta para produção. O salto de v11 para v12 geralmente exige um re-mapping das constantes TypoScript, já que alguns nomes foram renomeados. Para usuários de versões mais antigas da extensão, vale notar que as definições de serviço antes eram mantidas exclusivamente via formulários de backend, enquanto versões mais novas trabalham com YAML e, portanto, encaixam muito melhor em workflows Git.

Quem migra de outra ferramenta de consentimento como Cookiebot, OneTrust ou Usercentrics economiza custos recorrentes de licença, mas precisa reconstruir a configuração de serviços. A Gosign conduz essas migrações incluindo análise da taxa de consentimento, para que a mudança não cause perdas mensuráveis na quota de aceitação.

Além disso, vale uma visão estratégica sobre a pergunta de se um banner de cookies ainda é a resposta certa. Quem adota fontes auto-hospedadas de forma consistente, migra para analytics sem cookies como Matomo com cookies desativados ou Plausible, e substitui embeds de vídeo por imagens de preview estáticas com clique para carregar, pode remover o banner para muitas páginas. A vantagem regulatória é considerável, porque cada consentimento evitado também é um risco evitado junto à ANPD, e ao mesmo tempo a taxa de conversão não é prejudicada pelo diálogo do banner.

--- dpn_glossary TYPO3 - Glossário técnico | Gosign ---
> Glossar-Extension para TYPO3. Definir termos técnicos, vincular automaticamente no conteúdo, exibir como tooltip. Navegação alfabética. SEO-Boost.

## Um glossário traz valor SEO quando a linkagem interna roda de forma automatizada

Vincular manualmente termos técnicos em um site é trabalho de Sísifo. Uma empresa com 200 subpáginas e 80 termos técnicos teria que revisar cada página e vincular termos relevantes com a página do glossário. Na prática, isso nunca acontece completamente, e com novos conteúdos é esquecido. dpn_glossary automatiza esse processo: a extensão reconhece termos técnicos definidos no conteúdo e os vincula automaticamente com a respectiva página do glossário ou exibe uma definição em tooltip.

O efeito SEO é mensurável. Cada termo do glossário gera uma URL indexável própria. A linkagem automática a partir do conteúdo cria uma rede densa de links internos que ajuda o Google a classificar a autoridade temática do site. Sites com mais de 50 termos de glossário geram tipicamente 5 a 15% de tráfego orgânico adicional via palavras-chave de cauda longa.

## Cenários típicos de uso

**Portais especializados e sites setoriais.** Seguradoras, prestadores de serviços financeiros, escritórios jurídicos, empresas de tecnologia - em todo lugar onde linguagem técnica faz parte do cotidiano, visitantes se beneficiam de definições compreensíveis. Uma seguradora com termos como "franquia", "sub-rogação", "sinistro" pode exibi-los no texto corrido como tooltip, sem prejudicar o fluxo de leitura. Simultaneamente existe uma página de glossário alfabética como referência.

**Documentação técnica e bases de conhecimento.** Empresas de software que mantêm sua documentação no TYPO3 usam dpn_glossary para explicar termos técnicos (API, SDK, Webhook, OAuth) de forma consistente. Novos colaboradores e clientes encontram definições diretamente no contexto.

**Sites multilíngues com termos técnicos por idioma.** dpn_glossary suporta os mecanismos de tradução TYPO3. Termos podem ser definidos por idioma, incluindo definições e abreviações diferentes. Um termo como "conselho de trabalhadores" é reconhecido e vinculado corretamente em todas as versões linguísticas do conteúdo.

## Arquitetura técnica

dpn_glossary armazena termos de glossário em tabela própria (tx_dpnglossary_domain_model_term). Cada termo tem nome, definição (RichText), opcionalmente forma abreviada, sinônimos, mídias e URL de detalhe. Sinônimos são importantes: o termo "IA" pode ser definido como sinônimo de "Inteligência Artificial", para que ambas as grafias sejam reconhecidas automaticamente no conteúdo.

A linkagem automática funciona como pós-processador de conteúdo: após o TYPO3 renderizar o conteúdo da página, dpn_glossary pesquisa o HTML output por termos conhecidos e os substitui por links ou markup de tooltip. Tags HTML, atributos e links existentes são ignorados para evitar aninhamentos incorretos.

A página do glossário é configurada como página de plugin TYPO3. A visualização padrão mostra uma navegação alfabética (A-Z) com todos os termos. Cada termo tem uma página de detalhe com definição, termos relacionados e mídia opcional incorporada. As URLs seguem o padrão /glossario/nome-do-termo/, que é ideal para SEO.

## Problemas frequentes e soluções

**Termos são vinculados em títulos, menus ou formulários.** A linkagem automática às vezes captura áreas HTML que não devem ser vinculadas. Solução: a extensão oferece configuração de Excluded Tags (ex: h1, h2, h3, nav, form, a). Por padrão, títulos e links são excluídos, mas a lista deve ser adaptada a cada projeto.

**Exibição de tooltip conflita com o layout.** Tooltips (popups ao passar o mouse com a definição) podem ultrapassar a margem da página ou sobrepor outros elementos. Solução: ajustar CSS do tooltip (max-width, z-index, posição).

**Problemas de performance com muitos termos.** Sites com mais de 500 termos de glossário sentem a linkagem em páginas não cacheadas. Solução: restringir a lista de termos aos ativos (desativar desatualizados), limitar a linkagem a áreas específicas da página e usar consistentemente o cache de página TYPO3.

## Migração e compatibilidade de versões

dpn_glossary suporta TYPO3 v11 e v12 na versão estável atual. Compatibilidade com TYPO3 v13 está em desenvolvimento (status abril 2026). A extensão é mantida ativamente com releases regulares.

A longo prazo, a Gosign recomenda também gerar dados de glossário como markup Schema.org DefinedTerm. dpn_glossary não oferece suporte nativo para isso, mas um override de template Fluid pode adicionar o markup por termo. Isso melhora a visibilidade em Knowledge Panels e respostas geradas por IA.

A Gosign calcula a configuração inicial de um projeto dpn_glossary (instalação, configuração, adaptação de template, importação de 50 termos) com 1 a 2 dias de desenvolvimento. A manutenção contínua dos termos é feita pela redação via backend TYPO3. Por termo, nome, definição, sinônimos e uma imagem opcional devem ser mantidos, o que leva 5 a 10 minutos.

--- Validador de links TYPO3 - SEO | Gosign ---
> Broken-Link-Checker para TYPO3: Verificar links internos e externos, encontrar links quebrados. Essencial para SEO e experiência do usuário.

## Links quebrados custam rankings e confiança, e a maioria dos sites TYPO3 tem mais deles do que o esperado

Um site TYPO3 com 500 páginas tem em média 3.000 a 5.000 links. Destes, a experiência mostra que 2 a 5% estão defeituosos: páginas excluídas, URLs alteradas de sites externos, erros de digitação em links inseridos manualmente. São 60 a 250 links quebrados que enviam visitantes a páginas 404 e sinalizam ao Google que o site é mal mantido. dreipc_linkvalidator verifica todos os links internos e externos automaticamente e reporta problemas antes que afetem rankings e experiência do usuário.

O TYPO3 traz um validador de links próprio no Core (EXT:linkvalidator). dreipc_linkvalidator estende este com verificações adicionais, melhores relatórios e uma interface de backend mais intuitiva. Para sites com mais de 200 páginas, uma verificação automatizada de links não é luxo, mas obrigação.

## Cenários típicos de uso

**Sites corporativos com links externos.** Sites de empresas vinculam a parceiros, fornecedores, associações setoriais, textos legais e artigos de imprensa. URLs externas mudam sem aviso prévio. Um link para uma regulamentação funciona hoje, mas na próxima semana é movido. dreipc_linkvalidator verifica links externos via requisição HTTP e reporta 404, cadeias de 301 (mais de 2 redirects) e timeouts.

**Universidades e instituições educacionais.** Sites de universidades estão entre as páginas mais intensivas em links: regulamentos de curso, formulários, catálogos de disciplinas, diretórios de pessoal, universidades parceiras. Em um site universitário com 12.000 páginas, a verificação de links encontrou 1.400 links defeituosos, dos quais 800 internos (páginas excluídas, áreas reestruturadas) e 600 externos.

**Portais editoriais com conteúdo de arquivo.** Portais de notícias e revistas com milhares de artigos vinculam entre si e a fontes externas. Ao longo dos anos, links quebrados se acumulam, especialmente em artigos mais antigos. Uma verificação mensal de links identifica novos problemas antes que se acumulem.

## Arquitetura técnica

dreipc_linkvalidator estende o Linkvalidator Core do TYPO3 com mecanismos de verificação adicionais. O validador Core verifica links no nível do banco de dados: analisa os campos `bodytext`, `header_link` e outros campos configurados na tabela de conteúdo e identifica links para páginas ou arquivos excluídos. dreipc_linkvalidator complementa com verificações baseadas em HTTP para URLs externas.

A verificação roda como tarefa Scheduler do TYPO3. Configuração típica: uma vez por semana à noite. A tarefa percorre todas as tabelas e campos configurados em busca de links, distingue entre links internos (t3://page?uid=123), links de arquivo (t3://file?uid=456) e links externos (https://...), e verifica a acessibilidade de cada link.

Links internos são verificados contra o banco de dados TYPO3: a página vinculada ainda existe? Não está oculta, não excluída, não expirada? Links de arquivo verificam se o arquivo referenciado ainda existe no FAL. Links externos são verificados via requisição HTTP HEAD (mais rápido que GET, pois nenhum body é transferido). Em caso de erro no HEAD, segue um GET como fallback.

Os resultados são exibidos em uma visualização de backend: tabular, filtrável por tipo de erro (404, 301, timeout, erro SSL), por página e por editor. Cada entrada contém o link, a causa do erro, a página onde ocorre e um link direto para o editor de backend TYPO3.

## Problemas frequentes e soluções

**Falsos positivos em links externos.** Alguns sites bloqueiam requisições automatizadas (proteção contra bots, Cloudflare Challenge). O link funciona no navegador, mas o validador reporta 403 ou timeout. Solução: definir um header User-Agent realístico, aumentar timeouts para 15 segundos e colocar domínios com falsos positivos conhecidos em uma whitelist. Em um cliente, esses ajustes reduziram a taxa de falsos positivos de 12% para menos de 2%.

**Verificação demora muito em sites grandes.** Verificar 10.000 links externos sequencialmente leva várias horas. Solução: configurar verificação paralela (5 a 10 requisições simultâneas), restringir a verificação a links externos (links internos são rapidamente verificáveis via consulta ao banco) e ajustar a frequência (links externos semanalmente, internos diariamente).

**Editores ignoram os relatórios.** A razão mais frequente para listas crescentes de links quebrados: ninguém se sente responsável. Solução: ativar notificações por e-mail para os editores responsáveis. dreipc_linkvalidator pode enviar relatórios por e-mail, detalhados por área da árvore de páginas. O editor recebe apenas os links quebrados em "sua" área.

## Migração e compatibilidade de versões

O Linkvalidator Core do TYPO3 (EXT:linkvalidator) faz parte do Core desde v7 e é continuamente desenvolvido. No TYPO3 v12 e v13, o validador Core foi significativamente melhorado: melhor performance, nova UI no backend, integração com Scheduler reformulada. dreipc_linkvalidator como extensão suporta TYPO3 v10 e v11. Para v12 e v13 não existe versão oficial.

Para projetos em TYPO3 v12/v13, surge a questão se dreipc_linkvalidator ainda é necessário. O validador Core na v12 cobre muitas funcionalidades que antes só estavam disponíveis via dreipc: verificação HTTP de links externos, integração Scheduler, visualização backend com filtragem. O que falta: relatórios por e-mail e função whitelist para falsos positivos.

A alternativa: complementar o validador Core com um Command customizado que gera relatórios por e-mail. O esforço é de aproximadamente um dia de desenvolvimento. Alternativamente, existem ferramentas externas (Screaming Frog, Ahrefs, Semrush) que verificam links quebrados como parte de sua auditoria SEO, mas não são integradas ao TYPO3. A Gosign recomenda o validador Core em combinação com um crawl externo mensal para máxima cobertura.
---

--- dreipc_pdf TYPO3 - PDF Export | Gosign ---
> Geração de PDF da dreipc: Exportar páginas TYPO3 como PDF mit Custom-Layout. Alternativa ao web2pdf com abordagem de renderização própria.

## Quando visitantes querem baixar páginas TYPO3 como PDF, o resultado precisa de um layout próprio

Visitantes clicam em "Salvar como PDF" e esperam um documento limpo: design corporativo, logo, números de página, sem overhead de navegação. O que a função de impressão do navegador entrega é o oposto: colunas cortadas, headers e footers supérfluos, imagens ausentes. dreipc_pdf resolve esse problema com uma abordagem de renderização própria: a extensão gera PDFs a partir de conteúdos de página TYPO3 com um layout de impressão dedicado, independente da representação do navegador.

Ao contrário do EXT:web2pdf, que converte a página HTML renderizada como screenshot em PDF, dreipc_pdf trabalha de forma orientada a dados. Ele renderiza os elementos de conteúdo de uma página TYPO3 via templates próprios e gera um PDF formatado a partir deles. Isso permite controle total sobre margens, cabeçalhos e rodapés, tamanhos de fonte e quebras de página.

## Cenários típicos de uso

**Fichas técnicas de produtos a partir do CMS.** Fabricantes de máquinas, empresas químicas e fabricantes de tecnologia médica mantêm dados de produtos no TYPO3. Representantes de vendas precisam desses dados como PDF imprimível para visitas a clientes. dreipc_pdf gera a partir da página de produto TYPO3 um PDF com layout corporativo: logo acima, dados técnicos em tabelas, imagem do produto, dados de contato abaixo. Em um cliente com 400 páginas de produto, os PDFs ficam automaticamente disponíveis via botão em cada página, sem criação manual.

**Comunicados de imprensa e relatórios corporativos.** Departamentos de comunicação publicam comunicados de imprensa no site e os oferecem simultaneamente como PDF para download. dreipc_pdf gera o PDF ao clicar no botão de download, sempre baseado no conteúdo atual. Sem criação manual de PDF, sem risco de versões de download desatualizadas.

**Folhetos informativos de órgãos públicos.** Instituições públicas disponibilizam formulários, folhetos e informações como PDF. Os conteúdos são mantidos no TYPO3 e entregues automaticamente como PDF atualizado em caso de alterações. A versão PDF tem um layout oficial com cabeçalho institucional e número de referência.

## Arquitetura técnica

dreipc_pdf utiliza uma biblioteca PHP de PDF (tipicamente mPDF ou TCPDF) para a geração. A extensão se registra como Page-Type no TYPO3. Ao acessar uma página com o parâmetro PDF-Type (`?type=123`), em vez do output HTML, um arquivo PDF é gerado e oferecido para download.

O pipeline de renderização trabalha em três passos. Primeiro, a extensão lê os elementos de conteúdo da página TYPO3 solicitada do banco de dados. Segundo, renderiza cada elemento via um template Fluid dedicado para PDF (não o template web padrão). Terceiro, passa a string HTML renderizada ao mPDF/TCPDF, que gera o PDF com as configurações de página definidas.

Os templates PDF são templates Fluid com HTML/CSS que o mPDF entende. mPDF suporta um subconjunto de CSS2 e CSS3: margens de página (`@page`), cabeçalhos/rodapés, tabelas, imagens, fontes (fontes TTF incorporáveis) e quebras de página (`page-break-before`, `page-break-after`). Flexbox e Grid não são suportados, o trabalho de layout é feito via tabelas ou Float.

A configuração inclui: formato de página (A4, Letter, Custom), orientação (retrato/paisagem), margens, fonte padrão, templates de cabeçalho/rodapé e a atribuição de tipos de elemento de conteúdo a templates PDF. Cada elemento de conteúdo pode ter seu próprio template PDF, diferente da representação web.

## Problemas frequentes e soluções

**Imagens ausentes no PDF.** mPDF carrega imagens via HTTP. Se o servidor está atrás de um reverse proxy ou em ambiente Docker, mPDF pode não conseguir resolver as URLs de imagem próprias. Solução: incorporar imagens pelo caminho local do arquivo em vez da URL. Nos templates Fluid para PDF, usar o caminho absoluto do servidor (`/var/www/html/fileadmin/...`) em vez do endereço web.

**Geração de PDF lenta em páginas complexas.** Uma página com 30 elementos de conteúdo e 15 imagens pode levar 5 a 10 segundos para geração do PDF. Com requisições simultâneas, isso sobrecarrega o servidor. Solução: cachear PDFs gerados. Na primeira chamada, o PDF é gerado e armazenado no sistema de arquivos. Chamadas subsequentes entregam a versão cacheada. O cache é invalidado em alterações de conteúdo.

**Quebras de página em locais errados.** mPDF quebra páginas onde o conteúdo excede a altura da página, mesmo no meio de uma tabela ou parágrafo. Solução: nos templates PDF, definir quebras de página explícitas (`<div style="page-break-before: always;">`) e proteger tabelas contra quebra com `<table style="page-break-inside: avoid;">`.

## Migração e compatibilidade de versões

dreipc_pdf é uma extensão de nicho com comunidade limitada. A última versão estável suporta TYPO3 v10 e v11. Para v12 não existe atualização oficial, o esforço de portabilidade é moderado (ajustes Extbase, atualizações TCA).

As alternativas para TYPO3 v12/v13: EXT:web2pdf (baseada em screenshot, mais simples, menos controle sobre o layout), EXT:pdfviewhelpers (baseada em ViewHelper, funciona com TCPDF), EXT:fluid_fpdf (templates Fluid com backend FPDF) ou uma solução customizada com mPDF como pacote Composer. A solução customizada tem a vantagem do controle total e independência de extensões de terceiros.

Quem migra de dreipc_pdf para uma solução customizada pode aproveitar os templates Fluid existentes para PDF, desde que usem HTML/CSS compatível com mPDF. O wrapper de renderização deve ser reescrito, mas os templates permanecem. Para um projeto típico com 5 templates PDF, o esforço de migração é de 2 a 3 dias. A Gosign implementou geração de PDF no TYPO3 com diversas bibliotecas e recomenda a solução adequada conforme o requisito.
---

--- E-Paper TYPO3 - Revista online | Gosign ---
> Exibição de revista online no TYPO3. Baseado em PDF ou HTML. A Gosign assessora sobre soluções modernas e performáticas em vez de sucessores obsoletos do Flash.

## A maioria das soluções de e-paper no TYPO3 são sucessoras do Flash, e é exatamente assim que elas parecem

Extensões de e-paper para TYPO3 vêm conceitualmente da era Flash: um PDF é carregado, uma biblioteca JavaScript simula o folhear de páginas com animação 3D. À primeira vista parece impressionante. À segunda vista: não indexável (Google não consegue ler o conteúdo), não responsivo (uma catástrofe no smartphone), não acessível e com tempos de carregamento acima de 5 segundos. Existem formas melhores de exibir revistas e catálogos no TYPO3.

A questão central não é "Qual plugin de e-paper?", mas "Realmente precisamos de um e-paper?". Na maioria dos casos, a resposta é: Não. O conteúdo pertence como HTML ao site, não como PDF em um catálogo folheável.

## Cenários típicos de uso

**Revistas corporativas e periódicos para clientes.** Departamentos de marketing produzem revistas trimestrais em impressão e querem oferecer a versão digital no site. Abordagem clássica: carregar PDF, incorporar widget de catálogo folheável. Melhor abordagem: publicar os artigos como páginas TYPO3 individuais (via tx_news), com uma página de visão geral do magazine como hub. Cada artigo é indexável, linkável e compartilhável individualmente. O PDF permanece como opção de download para leitores offline.

**Catálogos de produtos para parceiros comerciais.** Atacadistas e empresas B2B oferecem catálogos de produtos a seus distribuidores. Os dados do catálogo frequentemente existem como exportação InDesign (PDF). Um widget de e-paper torna o catálogo folheável, mas não pesquisável. O melhor caminho: manter os dados de produto estruturados no TYPO3 e apresentar o catálogo como página HTML filtrável e pesquisável. O PDF serve como versão de impressão para download.

**Relatórios anuais e relatórios de sustentabilidade.** Empresas de capital aberto publicam relatórios anuais que devem corresponder visualmente ao layout de impressão. Aqui um viewer baseado em PDF é justificável, porque o layout é vinculante e páginas individuais exigem quebras de página exatas. Mas mesmo aqui: os dados centrais (indicadores financeiros, declarações da diretoria) devem estar disponíveis adicionalmente como HTML.

## Arquitetura técnica

Soluções de e-paper no TYPO3 podem ser divididas em três categorias:

**Catálogos folheáveis baseados em PDF.** Um PDF é carregado, uma biblioteca JavaScript (Turn.js, FlipBook.js, pdf.js) renderiza as páginas no navegador. A biblioteca divide o PDF em páginas individuais e as exibe como elementos Canvas. Vantagens: configuração rápida, layout corresponde 1:1 ao impresso. Desvantagens: sem valor SEO (conteúdo oculto no PDF), performance ruim com PDFs grandes (50+ páginas), sem responsividade.

**Layouts de revista baseados em HTML.** Os artigos são mantidos como elementos de conteúdo TYPO3 normais e exibidos via template de revista. O layout simula estética de revista (imagens grandes, colunas de texto, pull-quotes) via CSS Grid e Tailwind. Vantagens: indexação SEO completa, responsivo, performante, acessível. Desvantagens: maior esforço inicial, layout diverge do impresso.

**Abordagem híbrida.** Os artigos existem como HTML, adicionalmente há download em PDF disponível. Na página de visão geral, o visitante vê teasers de artigos, na barra lateral o download PDF da revista completa. Essa abordagem combina valor SEO e fidelidade à impressão.

Para a representação PDF no TYPO3, pdf.js (Mozilla) é adequado, uma biblioteca open-source que renderiza PDFs nativamente no navegador. pdf.js é mais performante que catálogos folheáveis baseados em Turn.js, dispensa animações de folhear e oferece uma representação limpa e rolável com zoom e busca de texto.

## Problemas frequentes e soluções

**Tempo de carregamento do PDF acima de 5 segundos.** Uma revista de 40 páginas como PDF pesa 20 a 40 MB. Sem otimização, o navegador carrega todo o PDF antes de exibir a primeira página. Solução: pdf.js suporta byte-range requests onde apenas a página solicitada é carregada. O servidor deve suportar `Accept-Ranges: bytes`. Adicionalmente, otimizar o PDF com Ghostscript ou qpdf para web (`linearize`) para que a primeira página seja exibida imediatamente.

**Conteúdo não indexado pelo Google.** Google crawla PDFs e indexa seu texto, mas não dentro de um viewer JavaScript. Quando o PDF é exibido apenas via elemento Canvas no navegador, o Google não vê conteúdo. Solução: colocar o conteúdo do PDF adicionalmente como texto oculto (aria-hidden, acessível para leitores de tela) na página HTML ou, melhor, exibir o conteúdo como elementos HTML nativos e oferecer o PDF apenas como download.

**Bibliotecas de catálogo folheável desatualizadas.** Muitas extensões de e-paper usam bibliotecas que não são atualizadas há anos. Turn.js (última atualização 2013), FlipBook jQuery (dependência jQuery) ou bibliotecas comerciais com licenças expirantes. Solução: migrar para pdf.js ou representação baseada em HTML. Ambos são à prova de futuro e independentes de licenças de terceiros.

## Migração e compatibilidade de versões

Extensões de e-paper no TER são predominantemente desatualizadas. A maioria suporta no máximo TYPO3 v10 ou v11. Para v12 e v13 não há extensões de catálogo folheável mantidas.

O caminho recomendado para TYPO3 v12/v13: incorporar pdf.js como biblioteca standalone (sem extensão necessária) para representações baseadas em PDF. Para revistas baseadas em HTML: tx_news com template de revista e categoria própria "Edições". O esforço para um layout de revista customizado baseado em tx_news é de 3 a 5 dias.

Quem migra de uma extensão de e-paper existente tem três opções: integração pdf.js (1 a 2 dias, mantém o modelo baseado em PDF), migração HTML (5 a 10 dias, transfere o conteúdo para artigos tx_news) ou um serviço externo (Issuu, Yumpu) com embed TYPO3. A Gosign recomenda a abordagem HTML para máximo valor SEO e orienta na decisão entre as variantes.
---

--- Extension Builder TYPO3 - Criação | Gosign ---
> A ferramenta padrão para criar novas extensões TYPO3. Editor visual para Extbase Models, Repositories e Controllers. O ponto de partida de cada.

## O Extension Builder é a ferramenta de scaffolding sem a qual nenhum desenvolvedor TYPO3 fica realmente produtivo

O Extension Builder é há mais de dez anos a ferramenta oficial com a qual desenvolvedoras criam em TYPO3 novas extensões do zero. Quem precisa de uma extensão Extbase com domain model, repository, controller e módulo de backend obtém no Extension Builder um editor visual que, a partir de um diagrama de domínio parecido com UML, gera todo o código boilerplate: configuração TCA, schema SQL, ext_localconf, stubs de controller, templates Fluid, arquivos de idioma. Para agências e times de produto que entregam extensões próprias com regularidade, a ferramenta continua sendo o caminho mais rápido do conceito ao primeiro protótipo funcional.

O público-alvo são times TYPO3 em agências e em áreas internas que representam lógica de negócio além do site package. Típicas são extensões para catálogos de produto, gerenciamento de eventos, portais de emprego, portais de cliente ou estruturas de dados específicas do setor. Sem Extension Builder, cada uma dessas extensões teria que crescer à mão a partir de um diretório vazio, com o risco de a estrutura divergir do schema do core TYPO3 e quebrar no próximo upgrade.

## Cenários típicos de uso

Um primeiro cenário é o protótipo para um portal de cliente. Uma indústria brasileira de máquinas com 2.000 peças de reposição precisa de uma extensão que disponibilize no backend famílias de produto, produtos e documentações como estruturas de dados próprias. O Extension Builder gera em menos de 30 minutos a estrutura completa: TCA, repositories, controllers, visões de lista e detalhe. O time começa imediatamente pela lógica de negócio, não pelo boilerplate.

Um segundo cenário é a situação de treinamento e onboarding. Um desenvolvedor que constrói pela primeira vez uma extensão TYPO3 conhece via o scaffold gerado as convenções do framework, sem se perder na documentação. O código gerado não é perfeito, mas é idiomático e mostra como o Extbase foi pensado.

Um terceiro cenário é a migração de estruturas de dados existentes. Quem precisa montar, a partir de um export CSV antigo, uma nova extensão TYPO3 com dez entidades, pode clicar o modelo de domínio no Extension Builder, exportá-lo e depois alimentar o código gerado via um comando de import. Isso economiza vários dias de trabalho em comparação com a construção manual.

Um quarto cenário é padronização em pool de agência. Um prestador de serviço com 15 desenvolvedores TYPO3 quer garantir que toda nova extensão tenha a mesma estrutura básica. O Extension Builder impõe essa estrutura via geração, e templates próprios para o code generator garantem que estilo de código, cabeçalho de licença e estrutura de diretório permaneçam idênticos entre projetos.

## Arquitetura técnica

O Extension Builder é uma extensão de backend TYPO3 clássica com interface própria. No backend aparece um módulo no qual o domain model é criado via interface drag and drop: entidades como caixas, properties como campos, relações como linhas. No export é persistido um schema JSON, a partir do qual o generator escreve todo o código da extensão.

A instalação é clássica via Composer (`friendsoftypo3/extension-builder`). A extensão não tem relevância de produção, pertence ao ambiente de desenvolvimento e não deveria estar sequer ativada em produção. Na geração, o builder recorre a templates parecidos com Twig, ajustáveis por projeto quando necessário, por exemplo para impor estilos de código próprios ou cabeçalhos de licença diferentes.

É importante notar que o Extension Builder não domina roundtrip: quem gera uma vez e depois estende o código à mão pode abrir a extensão no builder, mas de modo algum deve gerar novamente, sob pena do builder sobrescrever partes da lógica inserida manualmente. Na prática, o builder é usado como passo de scaffold único, depois a extensão vive no repositório Git.

## Problemas frequentes e soluções

O primeiro problema é a armadilha de sobrescrita após a primeira geração. Times que iniciam o builder uma segunda vez para incluir um campo perdem alterações próprias de código. A solução é uma regra clara no time: o Extension Builder é usado uma única vez, o resto é trabalho manual. Mudanças posteriores de campo acontecem manualmente em TCA, SQL e Model.

O segundo problema é compatibilidade com convenções modernas de PHP. O generator ainda produz código baseado em versões mais antigas de PHP e convenções Extbase mais antigas. A solução é um cleanup pass diretamente após a geração: adicionar type declarations, definir return types, introduzir properties readonly, substituir comentários de annotation antigos por atributos nativos.

O terceiro problema é o uso irrefletido como milagre de código. Alguns times esperam que o Extension Builder entregue uma aplicação pronta para produção. Ele não faz isso, ele entrega um esqueleto. Toda lógica de negócio, toda validação, todo conceito de segurança continua sendo tarefa da desenvolvedora.

Um quarto problema são padrões antiquados de backend no código gerado. Os controllers entregues usam às vezes ainda padrões Extbase deprecated, que geram warnings de deprecation no TYPO3 atual. A solução é um passo de lint diretamente após a geração, verificando o código contra os Coding Standards atuais e marcando declarações de tipo faltantes ou anotações obsoletas. Pipelines modernas combinam esse passo com code rewriting automático via Rector para manter o trabalho de cleanup o menor possível.

## Migração e compatibilidade de versões

O Extension Builder está oficialmente disponível para TYPO3 v11 e v12 e é mantido pelos Friends of TYPO3. Para TYPO3 v13 existe uma versão atualizada que segue as novas convenções Extbase. Times que fazem upgrade de extensões existentes em regra não precisam do builder para isso, o upgrade roda via upgrade wizards no Install Tool e ajustes manuais.

Mais interessante é o olhar estratégico: em uma época em que IA generativa consegue produzir estruturas completas de extensão incluindo lógica de negócio a partir de um prompt, o builder visual perde parte de sua vantagem original. A Gosign combina os dois mundos: para scaffolds padrão com muitas entidades, o builder continua eficiente, para extensões exigentes com lógica específica de domínio geramos o código diretamente a partir de um briefing técnico com suporte de IA, economizando até 80 por cento do tempo de desenvolvimento em relação à construção manual clássica, com qualidade de código simultaneamente maior.

--- FFH TYPO3 - Extensão personalizada | Gosign ---
> Extensão TYPO3 específica para o setor. A Gosign oferece desenvolvimento personalizado e suporte para extensões especiais.

## Extensões TYPO3 específicas de setor não falham na técnica, mas na manutenção

FFH é exemplar para uma categoria de extensões TYPO3 desenvolvidas para um cliente específico ou um setor específico: específicas do setor, funcionais, mas não mantidas de forma geral. No TER encontram-se centenas de extensões assim. Algumas têm 5 downloads por ano, nenhuma documentação e o último commit há 3 anos. Isso não significa que sejam ruins. Significa que precisam de manutenção que o desenvolvedor original não presta mais.

Para empresas que dependem de tais extensões, surge uma questão prática: continuar usando e manter por conta própria, migrar para uma alternativa ou desenvolver do zero. Todos os três caminhos são viáveis. A decisão depende da complexidade da extensão, da disponibilidade de alternativas e da pressão de versão do TYPO3.

## Cenários típicos de uso

**Associações setoriais com requisitos especiais.** Câmaras de ofícios, associações esportivas e cooperativas profissionais operam sites TYPO3 com funcionalidades que nenhum plugin padrão cobre: diretórios de membros com raio de busca, gestão de eventos com pontos de qualificação, registros setoriais com status de certificação. Para isso existem extensões customizadas desenvolvidas 5 a 8 anos atrás e desde então minimamente atualizadas. A função roda, mas atualizações do TYPO3 se tornam um risco.

**Empresas de mídia com workflows editoriais.** Emissoras de rádio, editoras e empresas de mídia usam TYPO3 com extensões para playlists, programação, arquivos de mídia ou syndication de conteúdo. Essas extensões foram frequentemente desenvolvidas internamente ou construídas por uma agência que não mantém mais o projeto. O código funciona no TYPO3 v9, mas a migração para v12 falha por APIs desatualizadas.

**Instituições públicas com requisitos legais.** Escolas, museus e bibliotecas usam extensões para gestão de horários de funcionamento, busca em catálogos ou reservas de eventos. Os requisitos são específicos (p.ex. integração com software de biblioteca como Koha ou Alma), a extensão foi construída uma vez e desde então não atualizada.

## Arquitetura técnica

Extensões TYPO3 específicas de setor seguem tipicamente o padrão Extbase/Fluid: modelo de domínio (classes PHP), Repository (acesso ao banco de dados), Controller (lógica de negócios) e templates Fluid (apresentação). Os dados ficam em tabelas de banco de dados próprias com prefixo `tx_extensionname_`.

Os padrões arquiteturais mais frequentes: extensões baseadas em plugin com saída frontend (listagem, visualização de detalhe, filtragem), módulos backend para manutenção de dados e tarefas Scheduler para importação/exportação. Muitas extensões específicas de setor integram sistemas externos via APIs REST ou importação CSV.

A qualidade do código varia consideravelmente. Extensões de agências profissionais seguem padrões de codificação TYPO3, usam Dependency Injection e têm testes unitários. Extensões desenvolvidas internamente ou trabalhos encomendados rapidamente frequentemente têm configurações hardcoded, tipagem ausente e nenhum teste. Ambas podem ser mantidas, mas o esforço difere por um fator de 3 a 5.

Um padrão típico de análise para extensões específicas de setor: medir escopo (linhas de código, número de classes, número de tabelas de banco de dados), verificar dependências (quais APIs TYPO3 são usadas, quais estão deprecated na v12/v13), avaliar testabilidade (existem testes unitários, o código é estruturado de forma testável) e estimar esforço de migração.

## Problemas frequentes e soluções

**APIs deprecated bloqueiam a atualização do TYPO3.** A extensão usa `$GLOBALS['TSFE']`, `GeneralUtility::_GP()` ou `ObjectManager::get()`, todas APIs deprecated ou removidas no TYPO3 v12. Solução: refactoring sistemático. Cada API deprecated tem um substituto documentado no TYPO3 Changelog. Para uma extensão com 5.000 linhas de código, o esforço de refactoring é de 3 a 7 dias, dependendo do número de deprecations.

**Nenhum mantenedor disponível.** O desenvolvedor original deixou a empresa, a agência não existe mais, o pacote TER está abandonado. Solução: fazer fork do código no GitHub, incluir a extensão no repositório Composer próprio e manter por conta própria. Ou contratar um prestador de serviço externo. O fork é legalmente sem problema se a extensão está sob GPL (padrão para extensões TYPO3).

**Nenhuma documentação.** Nem comentários inline nem docs externos. Novos desenvolvedores precisam ler o código para entender a função. Solução: antes do refactoring, criar uma documentação técnica. 2 a 4 horas de análise são suficientes para uma extensão com 3.000 a 5.000 linhas de código para documentar arquitetura, modelo de dados e lógica de negócios.

## Migração e compatibilidade de versões

Extensões específicas de setor naturalmente não têm suporte oficial para v12/v13. A migração deve ser feita individualmente. O esforço depende de três fatores:

Primeiro: qual versão TYPO3 é o ponto de partida? De v9 para v12 é significativamente mais trabalho que de v11 para v12, porque v10 introduziu o middleware stack e v11 mudou o registro de módulos backend.

Segundo: quantas APIs deprecated são usadas? O Extension Scanner do TYPO3 (no Install Tool) mostra isso automaticamente. Uma extensão com 5 deprecations precisa de um dia, uma com 50 precisa de uma semana.

Terceiro: quão bem estruturado é o código? Código Extbase limpo pode ser migrado mecanicamente. Código procedural com chamadas diretas ao banco de dados requer reescrita.

As três opções: portabilidade (adaptar extensão para nova versão TYPO3, 3 a 10 dias), redesenvolvimento (mesma função, arquitetura limpa, 2 a 4 semanas) ou encontrar alternativa (extensão padrão que cobre 80% da funcionalidade, mais adaptação customizada). A Gosign analisou, portou e redesenvolveu centenas de extensões TYPO3 específicas de setor e orienta sobre a opção mais econômica.
---

--- filefill TYPO3 - Carregar arquivos ausentes | Gosign ---
> filefill: Carregar automaticamente arquivos ausentes do servidor de produção. Para ambientes de desenvolvimento e staging. acelerado com IA.

## filefill poupa dias de sincronização para desenvolvedores e agências, a extensão carrega arquivos ausentes do fileadmin automaticamente do servidor de produção quando eles são realmente necessários

Quem trabalha em um projeto TYPO3 existente conhece o ritual: o setup local está pronto, o dump do banco foi importado, mas em metade das páginas aparecem placeholders no lugar de imagens. A razão é banal: o diretório fileadmin do sistema live contém gigabytes de assets que localmente faltam. A solução clássica era rsync ou scp por horas. O filefill elimina esse passo por completo. Em vez de copiar todos os arquivos antes, a extensão carrega no primeiro acesso exatamente o arquivo necessário do servidor remoto configurado, on demand, de forma transparente, com caching. Para agências que trabalham em vários projetos permanentemente, isso economiza não só espaço, mas horas por setup.

O ganho de produtividade é maior do que parece à primeira vista. Um novo desenvolvedor não fica operacional apenas após uma hora de download, mas em poucos minutos. Um code review em um feature branch esquecido não precisa de um file sync atual. Uma reprodução rápida de um bug report não se arrasta pela metade do dia. A pequena extensão atende assim um gargalo real do dia a dia dos desenvolvedores.

## Cenários típicos de uso

O caso mais frequente é o setup local de desenvolvimento. Um desenvolvedor clona o projeto TYPO3, configura DDEV ou Docker e importa o dump de banco atual. Em vez de baixar adicionalmente 30 GB de dados do fileadmin, ele configura o filefill com a URL base do sistema live. A cada carregamento de página que pede uma imagem ou documento, a extensão verifica se o arquivo existe localmente e o carrega quando necessário. Depois de alguns dias de trabalho, só os arquivos realmente usados estão locais, o resto permanece no servidor.

O segundo caso são ambientes de staging. Uma agência mantém para cada projeto um sistema de staging onde redatores testam conteúdos antes do go live. Esses sistemas de staging não precisam guardar todas as imagens, apenas as dos releases atuais. O filefill garante que conteúdos mais antigos continuem funcionando, porque os arquivos são puxados do sistema live quando necessários.

Terceiro uso: disaster recovery e cenários de hotfix. Quando um sistema TYPO3 precisa ser subido rapidamente em uma máquina nova, após uma queda de servidor ou em uma migração urgente de ambiente, o filefill pode cobrir a provisão de assets nas primeiras horas, até o restore completo do backup estar pronto.

## Arquitetura técnica

O filefill se conecta ao sistema FAL do TYPO3, mais precisamente ao mecanismo de retrieval de recursos. Assim que o TYPO3 solicita um arquivo do storage local e descobre que ele não existe, um event listener do filefill age. A extensão verifica uma lista de "sources" configuradas na ordem da prioridade e tenta carregar o arquivo de lá. Arquivos carregados com sucesso são salvos localmente, de forma que o próximo acesso dispensa requisição remota.

A configuração é feita via extension settings no Install Tool. Tipicamente uma remote source com URL base e, opcionalmente, credenciais HTTP Basic Auth é registrada. Para setups com CDN ou S3, esse caminho também pode servir como fonte. A extensão suporta várias sources, útil em cenários mais complexos com servidores de asset separados.

É importante que o filefill trabalha apenas de forma passiva. A extensão não baixa nada antes, reage exclusivamente a requisições concretas de arquivo. Isso a torna modesta no consumo de recursos e discreta na operação. A integração com DDEV, Docker Compose ou Lando é trivial, porque a extensão não precisa de serviços adicionais.

## Problemas frequentes e soluções

O primeiro problema são restrições de acesso. Quando o servidor live só entrega imagens a usuários logados ou certos paths são protegidos por htaccess, o filefill não consegue carregar. A solução está na configuração correta da autenticação HTTP e, se preciso, em uma regra de whitelist no servidor live que dê ao ambiente de desenvolvimento acesso ao path fileadmin.

Segundo problema: uso acidental em produção. Se o filefill está ativo em um ambiente live e a remote source é o próprio ambiente, surge uma recursão perigosa. A extensão não deve rodar em produção nunca. A solução pragmática é manter o filefill apenas no bloco Composer "require-dev" e ativar via variáveis de ambiente, não pelo Install Tool.

Terceiro problema: estados inconsistentes de arquivo. Quando o sistema live troca um arquivo, mas a cópia local já está cacheada, o desenvolvedor continua vendo a versão antiga. A solução é limpar o fileadmin local ocasionalmente ou fazer cache busting via remote source. No trabalho diário, isso raramente é problema, porque nomes de arquivo na troca costumam ser novos.

## Migração e compatibilidade de versões

O filefill é compatível com TYPO3 v11, v12 e v13 e é desenvolvido ativamente. Em upgrades, a versão da extensão deve corresponder à versão TYPO3, porque o sistema de eventos FAL teve pequenas mudanças entre v11 e v12. Quem usa a extensão em processos de desenvolvimento existentes deve testar rapidamente em upgrades maiores se todas as sources ainda estão acessíveis.

Uma solução relacionada é o EXT:aus_driver_amazon_s3, que mantém o fileadmin diretamente em um bucket S3. A diferença: o aus_driver_amazon_s3 é uma solução de produção, o filefill é um auxiliar de desenvolvimento. Os dois se complementam, um projeto com storage S3 em produção pode usar filefill localmente para puxar do bucket apenas os arquivos em edição atual.

Para agências que usam filefill de forma padronizada, vale uma documentação no wiki do projeto explicando como a extensão é ativada, quais credenciais são necessárias e como proceder em problemas. Isso reduz o esforço de suporte no time e torna o onboarding de novos desenvolvedores confiável. Complementarmente, vale um script curto que, no setup de um novo ambiente local, insira a configuração correta automaticamente.

A Gosign instala e configura filefill em ambientes de desenvolvimento e integra a extensão em setups DDEV e Docker, de forma que novos membros do projeto estejam operacionais em poucos minutos.

--- Find TYPO3 - Busca Solr | Gosign ---
> Solr-basierte Such-Extension para TYPO3. Alternativa ao stack padrão EXT:solr. Configuração de busca flexível, busca facetada, autocompletar. Gosign.

## A busca integrada do TYPO3 funciona até 500 páginas, depois é necessário Solr

A busca padrão do TYPO3 (EXT:indexed_search) pesquisa o output HTML renderizado e o armazena em uma tabela de banco de dados. Para sites pequenos com 50 a 500 páginas, funciona. A partir de 1.000 páginas, a busca fica lenta (tempos de resposta acima de 2 segundos), a partir de 5.000 páginas, inutilizável. EXT:find é uma extensão de busca baseada em Solr que oferece uma alternativa ao stack EXT:solr estabelecido: configuração mais flexível, query builder próprio e uma abordagem diferente para busca facetada.

A decisão entre EXT:find e EXT:solr não é uma questão de qualidade, mas de arquitetura. EXT:solr tem a comunidade maior e mais funcionalidades out-of-the-box. EXT:find oferece mais flexibilidade na configuração de queries e é adequada para projetos com requisitos de busca incomuns.

## Cenários típicos de uso

**Portais especializados com busca específica de domínio.** Um portal jurídico com 15.000 documentos precisa de busca por parágrafos, números de processo e palavras-chave simultaneamente. EXT:find permite a definição de diferentes tipos de query por campo de busca: busca exata para números de processo, busca fuzzy para texto livre, filtro de faixa para campos de data. Em uma editora especializada com 22.000 documentos, EXT:find entregou resultados de busca em menos de 100 milissegundos, independente da complexidade da filtragem.

**Busca e-commerce com atributos de produto.** Produtos têm atributos (cor, tamanho, peso, preço) que servem como facetas na busca. Um visitante busca "parafuso M8", filtra por material "aço inoxidável" e preço "até 5 EUR". EXT:find mapeia essas facetas diretamente em campos Solr e gera a navegação de filtros automaticamente a partir da configuração Solr.

**Busca fulltext multilíngue.** Sites internacionais precisam de busca que considere particularidades linguísticas: compostos alemães, declinação polonesa, acentos espanhóis, caracteres portugueses. Solr traz analisadores linguísticos para mais de 30 idiomas. EXT:find configura o analisador adequado por idioma e cria cores Solr específicos por idioma.

## Arquitetura técnica

EXT:find comunica com um servidor Apache Solr via HTTP/JSON. A arquitetura consiste em três componentes: o servidor Solr (indexação e busca), o indexador (escreve conteúdos TYPO3 no Solr) e o plugin frontend (entrada de busca, resultados, facetas).

O indexador percorre a estrutura de páginas TYPO3 e envia o conteúdo de cada página como documento JSON ao Solr. Não apenas os conteúdos visíveis são indexados, mas também metadados: título da página, descrição, categorias, palavras-chave e campos customizados. A indexação roda como tarefa Scheduler (recomendado: após cada atualização de conteúdo ou à noite como índice completo).

EXT:find se diferencia de EXT:solr na camada de query. Em vez de uma estrutura fixa de consulta de busca, find oferece um query builder configurável: via TypoScript ou FlexForm pode-se definir quais campos Solr são pesquisados, com qual ponderação (boosting), quais filtros são aplicados automaticamente e como os resultados são ordenados.

A configuração de facetas ocorre via definições de campo Solr. Cada campo que deve servir como faceta precisa estar definido como campo `facet` na configuração do schema Solr. EXT:find lê as facetas disponíveis da configuração Solr e as renderiza como menu de filtro no frontend. Os filtros funcionam por parâmetros GET, o que permite URLs amigáveis ao SEO para páginas de resultados filtradas.

## Problemas frequentes e soluções

**Setup e manutenção do servidor Solr.** Solr é um servidor baseado em Java que precisa ser operado separadamente. Para agências TYPO3 sem experiência Java, o setup é um obstáculo: configuração JVM, gestão de Solr Core, atualização de schema, monitoramento. Solução: usar Solr gerenciado (p.ex. Websolr, SearchStax) ou operar Solr como container Docker. A imagem Docker oficial do Solr reduz o setup a 3 comandos.

**Qualidade da busca é ruim.** Visitantes buscam "contato" e encontram 200 resultados, porque a palavra está em cada página no footer. Solução: configurar ponderação de campos. Resultados no título são ponderados 10x mais que resultados no body, resultados em H2 5x mais que texto corrido. EXT:find permite essa ponderação via TypoScript: `plugin.tx_find.settings.boostFields.title = 10`.

**Índice não é atualizado.** Editores alteram conteúdo, mas a busca mostra resultados antigos. Causa: a tarefa Scheduler do indexador não está rodando ou falhou. Solução: definir a tarefa Scheduler para intervalos curtos (a cada 15 minutos para índice delta, à noite para índice completo) e configurar um alerta de monitoramento que notifique em caso de erros de índice.

## Migração e compatibilidade de versões

EXT:find suporta TYPO3 v10 e v11 com Solr 8 e 9. Para TYPO3 v12 existe uma versão beta no GitHub. A extensão é mantida pela equipe de pesquisa e desenvolvimento da SUB Göttingen e tem uma base de usuários acadêmica.

EXT:solr é a alternativa mais popular com suporte oficial v12 e opções de suporte comercial (dkd Internet Service GmbH). Para a maioria dos projetos TYPO3, EXT:solr é a escolha segura. EXT:find é recomendada para projetos com requisitos especiais de query (busca acadêmica, bancos de dados especializados, cenários multi-índice).

A migração de EXT:indexed_search para Solr (tanto find quanto solr) requer: configurar servidor Solr, configurar schema, indexar conteúdo e adaptar templates frontend. O esforço é de 3 a 5 dias para um site padrão e 1 a 2 semanas para portais complexos. A Gosign orienta sobre o stack de busca adequado e assume setup, configuração e ajuste fino da qualidade de busca.
---

--- FlexSlider TYPO3 - Migration | Gosign ---
> Legacy-Slider-Extension para TYPO3. A Gosign migra para Swiper ou Splide: kein jQuery, bessere Performance, native Touch-Events, bessere Core Web.

## FlexSlider está desatualizado desde 2015, mas ainda está ativo em milhares de sites TYPO3

FlexSlider foi entre 2012 e 2015 um dos sliders mais populares para sites: baseado em jQuery, responsivo, com opções de animação. A biblioteca JavaScript FlexSlider.js tinha mais de 10.000 stars no GitHub. A última atualização foi em 2015. Desde então, o desenvolvimento web mudou fundamentalmente: jQuery não é mais necessário, Core Web Vitals penalizam bibliotecas JavaScript pesadas, e eventos touch funcionam nativamente sem biblioteca. Mesmo assim, FlexSlider roda em milhares de sites TYPO3, porque a migração nunca foi prioridade.

A extensão TYPO3 EXT:flexslider integra a biblioteca FlexSlider.js e oferece um plugin backend para configuração de slides (imagem, texto, link, efeito de animação). A extensão não é mais mantida e suporta no máximo TYPO3 v10. Todo site TYPO3 com FlexSlider tem um tema de migração pendente.

## Cenários típicos de uso

**Slider de página inicial com imagens de campanha rotativas.** O uso clássico: 3 a 5 imagens em formato grande na página inicial que rotam automaticamente. Marketing troca os conteúdos do slider sazonalmente. Esses sliders carregam tipicamente 3 a 5 imagens simultaneamente (15 a 25 MB de dados), mais jQuery (90 KB) e FlexSlider.js (30 KB). O resultado: mais de 4 segundos de tempo de carregamento para a área visível (LCP). A alternativa moderna: uma única imagem hero em vez de slider (conversão mais alta conforme testes A/B) ou um slider baseado em CSS sem JavaScript.

**Galerias de imagens de produto com thumbnails.** FlexSlider foi frequentemente usado como galeria de thumbnails em páginas de produto: imagem principal grande acima, barra de thumbnails abaixo. Ao clicar em um thumbnail, a imagem principal muda. Essa funcionalidade pode ser implementada hoje com 30 linhas de CSS e 10 linhas de JavaScript vanilla, sem biblioteca externa.

**Carrosséis de depoimentos.** Citações de clientes como cards rotativos, frequentemente com animação de autoplay. FlexSlider oferecia um modo "Carousel" para isso. Alternativa moderna: CSS Scroll Snap com `scroll-behavior: smooth`. Sem JavaScript necessário, suporte total a touch, menos de 1 KB de código.

## Arquitetura técnica

EXT:flexslider consiste em três partes: um plugin de elemento de conteúdo (FlexForm com configuração de slides), templates Fluid para a representação frontend e a biblioteca FlexSlider.js com jQuery como dependência.

No backend, o editor configura: número de slides, imagem, título, texto, link, efeito de animação (slide, fade), autoplay (sim/não), velocidade de autoplay, navegação (setas, pontos, thumbnails) e breakpoints responsivos. Os dados são armazenados na estrutura XML FlexForm do elemento de conteúdo.

No frontend, TYPO3 carrega jQuery (se não já presente), flexslider.js e flexslider.css. Um script de inicialização ativa o slider com as opções configuradas. O rendering é feito como estrutura `<div class="flexslider"><ul class="slides"><li>`.

Os problemas de performance são estruturais: FlexSlider carrega todos os slides ao carregar a página (sem lazy loading), jQuery bloqueia o rendering (recurso que bloqueia a renderização), o motor de animação usa JavaScript em vez de transições CSS (maior consumo de CPU em dispositivos móveis).

## Problemas frequentes e soluções

**Core Web Vitals ruins por causa do FlexSlider.** LCP acima de 4 segundos, CLS acima de 0.25 (layout shift durante o carregamento), TBT acima de 300ms (bloqueio JavaScript). Isso não é um problema de tuning, é um problema de arquitetura. Solução: substituir FlexSlider por uma alternativa moderna. Swiper (sem jQuery, lazy loading, transições CSS) ou Splide (mais leve que Swiper, 29 KB em vez de 140 KB) são as alternativas padrão. Melhor ainda: não usar slider e substituir por um elemento hero estático.

**Conflitos jQuery.** TYPO3 v12 não entrega mais jQuery no Core. FlexSlider precisa de jQuery. Quem inclui jQuery apenas para FlexSlider carrega 90 KB para uma biblioteca que não é usada em outro lugar. Solução: na migração do slider, remover jQuery completamente e migrar todos os componentes dependentes de jQuery simultaneamente.

**Imagens responsivas não funcionam.** FlexSlider não conhece o elemento `<picture>` e nem `srcset`. Todo dispositivo carrega a mesma imagem, seja desktop (1920px) ou smartphone (375px). Solução: Swiper e Splide suportam `srcset` e `<picture>` nativamente. Na migração, as imagens são geradas via processamento de imagens do TYPO3 em vários tamanhos e entregues via `srcset`.

## Migração e compatibilidade de versões

FlexSlider não tem compatibilidade com TYPO3 v12 ou v13 e não terá. A biblioteca jQuery é end-of-life. Todo projeto TYPO3 que migra para v12/v13 deve substituir FlexSlider.

A migração ocorre em quatro passos: primeiro, exportar os dados existentes dos sliders (imagens, textos, links da configuração FlexForm); segundo, configurar um novo elemento de conteúdo com Swiper ou Splide (como Custom Content Element no sitepackage); terceiro, importar os dados dos sliders na nova estrutura; e quarto, migrar as referências FlexSlider antigas para o novo elemento (atualização SQL da tabela tt_content).

O esforço de migração é de 1 a 2 dias para a reestruturação técnica e 0,5 a 1 dia para a migração de dados com 10 a 20 sliders. A alternativa sem slider (elemento hero estático) é ainda mais rápida: 0,5 dia para o novo template, os dados do primeiro slide são aproveitados, os restantes são descartados.

A Gosign recomenda em toda migração FlexSlider a pergunta fundamental: você realmente precisa de um slider? Testes A/B mostram consistentemente que elementos hero estáticos alcançam taxas de conversão mais altas que sliders rotativos. Se mesmo assim um slider for necessário, a Gosign entrega a migração para Swiper ou Splide incluindo otimização de performance.
---

--- Flipbook TYPO3 - Livro digital PDF | Gosign ---
> Alternative Flipbook-Extension para TYPO3 (além de rflipbook). Exibição de livro digital PDF com efeito de virar página. A Gosign recomenda.

## Flipbooks pareciam impressionantes em 2012 - hoje custam performance e acessibilidade

O efeito de folhear páginas foi uma das formas de apresentação mais populares para catálogos, relatórios anuais e revistas em sites corporativos. Um PDF é dividido em páginas individuais, exibido como livro no navegador e folheado via clique ou gesto de deslizar. A técnica vem da era Flash. Desde o fim do Flash (2020), soluções flipbook são baseadas em JavaScript e Canvas. A ideia básica não mudou: trata-se da simulação visual de um documento físico.

O problema: flipbooks são assassinos de performance. Um PDF de 40 páginas é convertido em 40 imagens individuais (200 a 500 KB cada), mais a biblioteca JavaScript (100 a 300 KB minificada). Resultado: 10 a 20 MB de payload para um único elemento de conteúdo. Em dispositivos móveis, flipbooks são praticamente inutilizáveis, leitores de tela não conseguem ler o conteúdo, e o Google não indexa o texto porque está em imagens.

## Cenários típicos de uso

**Relatórios corporativos e balanços anuais.** Diretorias querem exibir o relatório de gestão "como impresso" no site. A agência de impressão entrega um PDF, a equipe de marketing quer publicá-lo 1:1 online. Flipbook parece a solução mais fácil. A Gosign recomenda uma alternativa: preparar o relatório como página HTML (pesquisável, acessível, responsivo) e colocar o PDF como link de download ao lado.

**Catálogos de produtos com muitas páginas.** Empresas industriais com catálogos de 200 páginas usam flipbooks como "catálogo folheável" no site. A realidade: usuários folheiam no máximo 5 a 10 páginas antes de desistir. Um catálogo HTML pesquisável com filtros e páginas de detalhe de produto converte melhor.

**Apresentações imobiliárias e brochuras.** Escritórios de corretagem exibem apresentações como flipbook para que interessados tenham a sensação do documento impresso. Aqui, frequentemente basta um visualizador de PDF incorporado (pdf.js) sem efeito de folhear, que funciona em todos os dispositivos e mantém o texto pesquisável.

## Arquitetura técnica

A extensão Flipbook para TYPO3 trabalha em três etapas. Primeiro, o PDF é convertido em imagens individuais no servidor (via ImageMagick, Ghostscript ou serviço externo). Depois, as imagens são renderizadas em uma biblioteca JavaScript baseada em Canvas (turn.js, StPageFlip ou solução comercial). O efeito de folhear é gerado por CSS3 Transform e animação JavaScript.

A integração TYPO3 ocorre como elemento de conteúdo: o editor carrega um PDF, seleciona opções (faixa de páginas, tamanho de miniatura, velocidade do efeito), o frontend renderiza o flipbook. Dependências: ImageMagick ou Ghostscript deve estar instalado no servidor para a conversão PDF.

## Problemas frequentes e soluções

**Imagens não são geradas.** A conversão PDF falha quando Ghostscript não está instalado, uma versão errada está rodando ou faltam permissões no diretório de saída. Solução: verificar `gs --version` no servidor (mínimo 9.50), fornecer permissões de escrita no diretório de saída.

**Tempo de carregamento acima de 5 segundos.** Um PDF de 80 páginas gera dezenas de imagens em alta resolução. Solução: reduzir qualidade da imagem (72 dpi em vez de 150 dpi para exibição web), implementar lazy loading para páginas fora da área visível, usar WebP em vez de PNG/JPEG. Ou questionar fundamentalmente: é realmente necessário um flipbook?

**Dispositivos móveis apresentam erros de exibição.** O efeito de folhear funciona apenas parcialmente em dispositivos touch. O efeito 3D de virar página é quase invisível em telas pequenas, e o gesto de deslizar conflita com o scroll do navegador. Solução: em dispositivos móveis, alternar automaticamente para um slider simples ou o visualizador PDF nativo.

## Migração e compatibilidade de versões

A extensão Flipbook tem suporte limitado para versões TYPO3 atuais. A última versão estável suporta TYPO3 v10 e v11. Para v12 e v13 não existe release oficial (status abril 2026).

A Gosign recomenda em um upgrade TYPO3 a substituição do flipbook por uma das seguintes alternativas: visualizador PDF baseado em pdf.js (open source, sem conversão necessária, texto permanece pesquisável), preparação HTML do conteúdo (máximo efeito SEO, acessibilidade completa) ou slider lightbox com páginas selecionadas como imagens (compromisso visual, boa performance). A migração geralmente é concluída em 1 a 2 dias, pois o conteúdo já existe como PDF e apenas a forma de apresentação muda.

Um aspecto adicional é a acessibilidade. Flipbooks são completamente inacessíveis para usuários de leitores de tela, pois o texto está em imagens. A Lei de Fortalecimento da Acessibilidade (BFSG na Alemanha), vigente desde junho de 2025, afeta também publicações digitais em sites corporativos. A migração para apresentações baseadas em HTML ou pdf.js (que renderiza o texto original) não é apenas uma questão de performance, mas também uma necessidade legal.

--- FlowFact TYPO3 - CRM imobiliário | Gosign ---
> FlowFact no TYPO3: Immobilien-Listings, Objekt-Sync, Exposé. OpenImmo-Integração. acelerado com IA.

## Corretores de imóveis perdem leads quando transferem objetos manualmente para o site

Um corretor mantém seu portfólio de objetos no FlowFact: fotos, plantas, preços, características de equipamento, textos de exposição. Os mesmos dados devem aparecer no próprio site, em portais imobiliários e em apresentações impressas. Sem sincronização automática, alguém digita os dados duas vezes, esquece a atualização após uma mudança de preço ou publica um imóvel já vendido. O resultado: anúncios incorretos, contato irritado com clientes, leads perdidos.

FlowFact (desde 2019 parte do grupo Hypoport) é um dos sistemas CRM mais utilizados no setor imobiliário. A integração TYPO3 sincroniza objetos automaticamente do FlowFact para o site do corretor, sem intervenção manual. A Gosign implementou essa integração para escritórios de corretagem com 50 a 2.000 objetos ativos.

## Cenários típicos de uso

**Escritórios de corretagem regionais com site próprio.** Um escritório com 3 a 10 corretores mantém 200 a 500 objetos ativos no FlowFact. O site exibe listagens com função de busca (CEP, número de quartos, faixa de preço, tipo de objeto), páginas de detalhe com galeria de imagens e planta, download de exposição como PDF e um formulário de contato que encaminha a consulta diretamente ao corretor responsável no FlowFact. Novos objetos aparecem no site em até 15 minutos, mudanças de status (vendido, reservado) são atualizadas automaticamente.

**Incorporadoras e construtoras.** Empresas que comercializam projetos de construção nova precisam, além da busca de objetos, de landing pages com descrição da obra, mapa de localização e visão geral de unidades como tabela interativa. FlowFact fornece os dados dos objetos, TYPO3 o ambiente editorial para textos e conteúdo de marketing. Ambos os mundos são conectados via API.

**Administradoras com portal de inquilinos.** Administradoras utilizam FlowFact para gerenciar imóveis para locação. O site TYPO3 exibe apartamentos disponíveis, coleta candidaturas via formulário e as encaminha como contato no FlowFact. Particularidade: a lista de objetos filtra automaticamente por "para locação", não por "para venda".

## Arquitetura técnica

A conexão entre FlowFact e TYPO3 funciona por duas interfaces possíveis. O caminho clássico é OpenImmo, um padrão XML setorial para troca de dados imobiliários. FlowFact exporta objetos como XML OpenImmo (manualmente ou por scheduler), um importador TYPO3 lê os arquivos e cria registros.

O caminho moderno é a API REST FlowFact (desde FlowFact v3). O servidor TYPO3 consulta dados de objetos, imagens e contatos via requests HTTP e os sincroniza no banco de dados local. Vantagens sobre OpenImmo: capacidade de tempo real (polling a cada 5 minutos em vez de exportação diária), atualizações granulares (apenas campos alterados) e acesso a dados específicos do FlowFact que não constam no padrão OpenImmo.

No lado TYPO3, objetos são armazenados como registros em tabela própria (não como páginas TYPO3). Páginas de listagem utilizam repositórios Extbase com funções de filtro. Páginas de detalhe são renderizadas via show action, que carrega imagens do FAL e exibe plantas como overlay. A integração de mapa ocorre via Leaflet ou Google Maps, com geocoordenadas obtidas do FlowFact.

## Problemas frequentes e soluções

**Imagens faltam após a importação.** Exportações OpenImmo referenciam imagens como nomes de arquivo, mas nem sempre entregam os arquivos junto. Solução: configurar a exportação para que imagens sejam embutidas como Base64 no XML ou transferidas via FTP paralelamente ao XML. Na API REST, imagens são baixadas por endpoints próprios e devem ser importadas como referências FAL no TYPO3.

**Objetos desaparecem após o sync.** Quando FlowFact desativa ou exclui um objeto, o importador TYPO3 deve decidir: excluir o registro, ocultar ou marcar como "vendido"? Importadores padrão frequentemente excluem de forma agressiva. Solução: implementar soft-delete que marca objetos como "inativos" primeiro e só os remove fisicamente após 30 dias. Assim, URLs relevantes para SEO são preservadas e podem redirecionar via 301 para a página de visão geral.

**Consultas do formulário de contato se perdem.** O formulário envia um e-mail, mas o lead não é criado como contato no FlowFact. Solução: criar consultas do formulário via API FlowFact como contato com referência ao objeto. O corretor responsável vê o lead diretamente no seu dashboard. Para isso, o formulário precisa do ID do objeto FlowFact como campo oculto.

## Migração e compatibilidade de versões

FlowFact introduziu em 2019 uma plataforma completamente nova (FlowFact v3). A versão antiga (FlowFact Classic) ainda opera, mas não recebe novos recursos. A API REST está disponível apenas na v3. Integrações OpenImmo existentes funcionam com ambas as versões, mas a abordagem baseada em API só é possível com v3.

No lado TYPO3, não existe extensão oficial FlowFact com suporte v12/v13 no TER. A maioria das instalações usa importadores personalizados ou a extensão openimmo (com adaptações). A Gosign recomenda, em upgrades TYPO3 para v12+, migrar simultaneamente a integração imobiliária para a API REST FlowFact, em vez de portar o workflow XML OpenImmo. A abordagem baseada em API requer menos manutenção e permite recursos como disponibilidade em tempo real, que não são realizáveis com exportação XML.

Um projeto típico de integração FlowFact-TYPO3 (importação de objetos, função de busca, páginas de detalhe, formulário de contato com roteamento de leads) é calculado pela Gosign com 10 a 15 dias de desenvolvimento. A manutenção contínua se limita a atualizações de API e ajustes ocasionais em mudanças de campo no esquema FlowFact.

--- fluid_fpdf TYPO3 - PDF a partir de templates | Gosign ---
> fluid_fpdf: Gerar PDFs a partir de Fluid Templates. Faturas, certificados, relatórios. acelerada com IA implementação.

## Quando PDFs surgem de dados em vez de screenshots, é necessário fluid_fpdf

Existem duas abordagens fundamentalmente diferentes para gerar PDFs no TYPO3. A abordagem screenshot (web2pdf): a página web renderizada é capturada como imagem e empacotada em PDF. Simples, mas o resultado parece uma página web impressa, com navegação, footer e artefatos responsivos. A abordagem orientada a dados (fluid_fpdf): um template Fluid define o layout do PDF, dados TYPO3 preenchem os placeholders, o resultado é um documento limpo com design corporativo. Faturas, certificados, propostas, relatórios - tudo que precisa existir como documento precisa da abordagem orientada a dados.

fluid_fpdf usa a biblioteca FPDF (uma classe PHP enxuta para geração de PDF) e a conecta com o motor de templates Fluid do TYPO3. O resultado: desenvolvedores escrevem layouts PDF na mesma linguagem de template que usam para templates HTML.

## Cenários típicos de uso

**Geração automatizada de faturas.** Uma loja online ou sistema de reservas no TYPO3 gera uma fatura a cada pedido. Os dados da fatura (itens, preços, dados do cliente, impostos) vêm do banco de dados, o layout de um template Fluid. Em um organizador de eventos, fluid_fpdf gera 200 a 300 faturas por mês sem intervenção manual. Cada fatura carrega número da fatura, logo da empresa, dados bancários e informações obrigatórias legais.

**Certificados de participação e confirmações.** Instituições educacionais, associações e empresas emitem certificados após treinamentos, workshops ou provas. O nome do participante, a data, o nome do curso e a assinatura do instrutor são automaticamente extraídos dos dados TYPO3. Em uma instituição educacional com 5.000 participantes por ano, a automatização economiza aproximadamente 250 horas de trabalho que antes eram gastas na criação manual de PDF no InDesign.

**Propostas e exposés.** Corretores de imóveis, consultorias e agências criam propostas com conteúdos variáveis: dados do cliente, serviços selecionados, preços individuais. O layout PDF é fixo (design corporativo), os conteúdos variam. fluid_fpdf preenche o template com os dados de um formulário TYPO3 ou módulo backend.

## Arquitetura técnica

fluid_fpdf conecta dois sistemas: o motor de templates Fluid do TYPO3 e a biblioteca FPDF. A arquitetura trabalha em três passos.

Primeiro: o template Fluid define a estrutura do PDF. Em vez de tags HTML, o template usa ViewHelpers especiais para elementos PDF: `<fpdf:page>` para uma nova página, `<fpdf:cell>` para uma célula de texto, `<fpdf:image>` para uma imagem, `<fpdf:line>` para uma linha. A sintaxe é Fluid, a saída não é HTML, mas comandos FPDF.

Segundo: TYPO3 fornece os dados. Via controller ou DataProcessor, os dados necessários (itens de fatura, dados de cliente, informações de produto) são passados ao template. Funciona identicamente ao tratamento de dados em templates Fluid HTML: `{invoice.items}`, `{customer.name}`, `{order.total}`.

Terceiro: FPDF renderiza o PDF. Os ViewHelpers traduzem a lógica Fluid em chamadas de método FPDF (SetFont, Cell, Image, Ln). FPDF gera o PDF como arquivo binário que é enviado diretamente ao navegador (download) ou armazenado no sistema de arquivos (p.ex. para envio por e-mail).

O suporte a fontes é um detalhe importante: FPDF suporta por padrão apenas 14 fontes (Helvetica, Times, Courier e variantes). Para fontes corporativas, arquivos TTF devem ser convertidos como arquivos de fonte FPDF. A ferramenta `MakeFont` do FPDF cuida da conversão.

## Problemas frequentes e soluções

**Caracteres UTF-8 não são exibidos corretamente.** FPDF trabalha internamente com codificação Latin-1. Acentos (ã, ç, é, ê, í, ó, ú, à), caracteres poloneses (ą, ę, ł) ou letras cirílicas requerem suporte UTF-8. Solução: usar tFPDF (uma variante FPDF com suporte UTF-8) em vez de FPDF. fluid_fpdf suporta tFPDF como backend. Alternativamente: usar mPDF, que suporta UTF-8 nativamente.

**Quebras de página em conteúdos dinâmicos.** Uma fatura com 5 itens cabe em uma página, uma com 50 itens precisa de 3 páginas. FPDF não quebra páginas automaticamente quando o conteúdo excede a margem da página. Solução: verificar a altura restante da página antes de cada item (GetY() + altura da linha > final da página) e inserir uma nova página quando necessário. Cabeçalhos e rodapés são repetidos automaticamente em cada página via métodos Header()/Footer().

**Desenvolvimento de layout é trabalhoso.** Sem preview visual, o desenvolvedor precisa gerar o PDF após cada alteração para ver o resultado. Solução: configurar uma rota de preview que exibe o PDF no navegador (modo de saída "Inline" em vez de "Download"). A cada refresh, o PDF é regenerado. Isso acelera consideravelmente o ciclo de desenvolvimento.

## Migração e compatibilidade de versões

fluid_fpdf suporta TYPO3 v10 e v11. Para v12 não existe versão oficial, o esforço de portabilidade é moderado (ajustes Extbase, registro de ViewHelper).

As alternativas para TYPO3 v12/v13: EXT:pdfviewhelpers (usa TCPDF em vez de FPDF, mais funcionalidades, manutenção ativa, compatível com v12), uma solução customizada com mPDF como pacote Composer (HTML/CSS como entrada, layout mais simples que com FPDF) ou uma solução headless com serviço PDF externo (Gotenberg, wkhtmltopdf como container Docker).

A migração de fluid_fpdf para EXT:pdfviewhelpers é gerenciável: a estrutura de templates é similar (baseada em ViewHelper), mas os nomes e parâmetros dos ViewHelpers diferem. Para um projeto com 5 templates PDF, o esforço de migração é de 2 a 4 dias. A Gosign implementou geração de PDF no TYPO3 com todas as bibliotecas comuns e orienta sobre a solução adequada baseada nos requisitos concretos.
---

--- focuspoint TYPO3 - Recorte inteligente de imagens | Gosign ---
> focuspoint para TYPO3: Recorte automático de imagens com ponto focal inteligente. Otimização responsiva, acelerado com IA.

## focuspoint impede que imagens, no recorte responsivo, percam áreas importantes do motivo, a extensão define um ponto focal no qual o recorte permanece alinhado em qualquer proporção

Quem usa imagens em um site responsivo conhece o problema: um retrato em formato vertical que aparece em um teaser com apenas 200 pixels de altura mostra de repente só o pescoço ou a testa. Uma foto de paisagem que aparece em um hero como faixa estreita mostra o céu em vez das montanhas. O centramento genérico faz com que motivos principais sejam cortados, porque o centro matemático raramente coincide com o centro real do motivo. O focuspoint resolve isso permitindo que os redatores definam no backend um ponto na imagem que precisa permanecer visível em qualquer recorte. A saída se adapta a todas as proporções, sem que para cada formato uma variante própria precise ser gerada.

A diferença em relação a uma pipeline clássica de edição de imagens com recortes fixos é grande. Em vez de manter para desktop, tablet e mobile uma versão recortada separadamente, há uma imagem original com um ponto focal e qualquer quantidade de formatos de saída que o sistema calcula automaticamente. Para redações com muitas imagens, isso reduz dramaticamente o tempo de manutenção, e para o marketing abre a possibilidade de introduzir novas proporções de imagem sem retrabalho.

## Cenários típicos de uso

O primeiro caso clássico são páginas de pessoas e equipe. Um site corporativo mostra retratos de colaboradores em vários layouts, como avatar redondo no header, quadrado como tile na lista de equipe, formato wide na página de detalhe. Sem ponto focal, o fotógrafo precisa fotografar exatamente centralizado, ou a redação cria para cada layout uma variante própria. Com focuspoint, a redação define uma vez um ponto no rosto e a imagem funciona em todos os contextos.

O segundo caso são fotos de produto e de ambientes. Imobiliárias, hotéis e lojas de móveis trabalham com fotos em que o motivo real, um sofá, uma vista do quarto, um detalhe de produto, não fica no centro da imagem. O focuspoint permite selecionar exatamente esse motivo e garante que ele não se perca em dispositivos móveis.

Terceiro uso: teasers de revista e artigo. Fotos editoriais de artigo frequentemente têm um foco visual claro, como um palestrante em um palco ou um produto em uma cena. Em listas de teaser com thumbnails verticais, esse foco visual ficaria frequentemente fora do recorte sem ponto focal.

## Arquitetura técnica

O focuspoint estende o sistema FAL do TYPO3 com dois campos adicionais de metadado: focus_point_x e focus_point_y. Os dois são mantidos no backend via um elemento de formulário que exibe a imagem original como área de seleção. O redator clica no ponto relevante, a posição relativa é salva. Tecnicamente, são dois valores de ponto flutuante entre zero e um, descrevendo a fração da largura ou altura da imagem.

Na renderização do frontend, o ponto focal é avaliado pelo ViewHelper Fluid. Em vez do ViewHelper "f:image" usual, a extensão usa um ViewHelper próprio que realiza o cálculo de recorte considerando o ponto focal e gera a imagem no tamanho desejado via pipeline GIFBUILDER do TYPO3. O resultado é cacheado e regerado apenas em mudanças.

A extensão convive com todos os formatos de imagem comuns, JPEG, PNG, WebP, AVIF, e usa para o processamento real de imagem o ImageMagick ou GraphicsMagick, ou seja, o mesmo stack sobre o qual o TYPO3 já roda. Para lazy loading e integração srcset não há conflitos: o ViewHelper pode ser aninhado em elementos picture com várias sources e entrega para cada breakpoint o recorte certo.

## Problemas frequentes e soluções

O primeiro problema é a ordem dos ViewHelpers. Quem insere focuspoint em templates existentes que já trabalham com "f:image" e argumentos de crop manuais precisa colocar o ViewHelper focuspoint no lugar do padrão, não ao seu redor. Caso contrário, as duas lógicas rodam uma contra a outra e o resultado ignora o ponto focal. A solução é uma migração limpa de todas as referências de imagem no site package para o novo ViewHelper.

Segundo problema: invalidação de cache. Quando redatores alteram o ponto focal, o cache de imagem precisa ser descartado, caso contrário continuam vendo o recorte antigo. O TYPO3 normalmente limpa o image cache em mudanças na imagem original, não em mudanças de metadado. A solução é um EventListener que, em mudanças nos campos de ponto focal, apaga de forma direcionada os processed files afetados.

Terceiro problema: resultados inconsistentes entre prévia no backend e frontend. A prévia no backend usa um render path diferente do frontend, o que pode levar a pequenos desvios. Solução pragmática: mostrar no backend apenas uma prévia aproximada e apontar os redatores para o frontend como referência definitiva.

## Migração e compatibilidade de versões

O TYPO3 traz desde a versão 9 um crop editor nativo no backend que permite variantes individuais por imagem. Para casos de uso simples, isso basta. O focuspoint se diferencia por definir o ponto focal uma única vez, que flui automaticamente para todas as variantes de crop, em vez de editar cada variante individualmente. Quem tem muitas imagens e pouco tempo editorial se sai melhor com focuspoint a longo prazo.

A extensão é compatível com TYPO3 v11, v12 e v13. No upgrade de versões mais antigas, a estrutura de metadados FAL e os ViewHelpers usados devem ser levados para a sintaxe atual.

Uma nova classe de alternativas são detecções de saliency com suporte de IA, que derivam o ponto focal automaticamente do conteúdo da imagem. Essas abordagens reduzem ainda mais o trabalho editorial, porque os redatores não precisam mais definir o ponto e só corrigem em exceções. Para TYPO3 existem primeiras integrações dessa técnica, mas ainda não são padrão e devem ser avaliadas caso a caso.

A Gosign configura focuspoint e o integra em arquiteturas de Fluid Templates. Análise com suporte de IA dos layouts de design sugere presets de crop ideais para todos os breakpoints, de forma que redatores, na manutenção de imagens, não precisem testar cada formato individualmente.

--- Linked Checkbox TYPO3 - Elemento de formulário | Gosign ---
> Elemento de checkbox personalizado para o TYPO3 Form Framework com label vinculado.

## form_element_linked_checkbox torna consentimentos LGPD realmente clicáveis

O Form Framework do core TYPO3 conhece uma checkbox, mas não uma checkbox com label vinculado. Quem trabalha com o elemento padrão não consegue colocar no label um link para a política de privacidade ou para os termos de uso, e isso é justamente uma exigência que aparece em todo formulário na prática. A extensão form_element_linked_checkbox fecha essa lacuna com um custom form element limpo que combina texto e link. Para qualquer instalação TYPO3 que use o Form Framework nativo, essa extensão é praticamente obrigatória. Sem ela, a única saída é o workaround de estender o texto do label com um bloco de texto ao lado, o que não só parece desleixado como também é problemático para leitores de tela e acessibilidade.

## Cenários típicos estão no entorno de compliance de todo site corporativo

O primeiro e mais frequente cenário são consentimentos LGPD abaixo de formulários de contato, newsletter e candidatura. O texto "Li a política de privacidade e concordo com o tratamento dos meus dados" precisa conter um link clicável para /politica-de-privacidade sem que o visitante tenha que marcar a caixa para abrir. O form_element_linked_checkbox cobre esse caso exatamente.

Um segundo cenário são confirmações de termos em formulários de registro e compra. Universidades usam isso em inscrições em cursos, associações em pedidos de associação, projetos e-commerce com o Form Framework do TYPO3 em checkouts. Aqui frequentemente não se trata só de um link, mas de vários (termos, direito de arrependimento, política de privacidade) que precisam caber no mesmo label.

O terceiro cenário envolve newsletters com Double Opt-In. Antes da inscrição, o destinatário precisa confirmar explicitamente que assina a newsletter, com link para os avisos de privacidade específicos. O form_element_linked_checkbox permite usar várias checkboxes com links próprios no mesmo formulário, de modo que além do consentimento de privacidade também o consentimento explícito para newsletter seja pedido como elemento separado. Isso é importante porque a LGPD exige consentimentos separados e uma checkbox genérica de "concordo com tudo" não basta juridicamente.

## Arquitetura técnica está no sistema de plugins do Form Framework

O Form Framework do TYPO3 foi projetado deliberadamente como extensível: qualquer extensão pode registrar form elements próprios, que aparecem no editor YAML e ficam disponíveis via drag and drop no backend. O form_element_linked_checkbox usa esse mecanismo e registra um novo elemento "LinkedCheckbox" via YAML de setup do Form Framework e na área de definição de form elements. Redatores arrastam o elemento para seu formulário, exatamente como fariam com uma checkbox padrão, e configuram label, texto do link e destino no painel de detalhes.

Internamente, a extensão estende a classe Checkbox e adiciona propriedades para linkTarget, linkText e wrapLabel. A renderização acontece via Fluid partial próprio, que fragmenta o label em "before", "linkText" e "after" e estende a área clicável apenas sobre a parte do link. O clique no link abre a página de destino sem alternar o estado da checkbox. Para acessibilidade, isso é importante, porque leitores de tela leem o link como elemento separado e a checkbox pode ser operada independentemente.

A configuração é feita diretamente no editor YAML do Form Framework: após arrastar o elemento para um formulário, os campos "Label antes do link", "Texto do link", "Label depois do link" e "Destino do link" aparecem na coluna de detalhes à direita. O destino pode ser uma página interna, um link de arquivo ou um URL externo. A validação de obrigatoriedade é definida, como no elemento padrão, via a aba Validators.

## Problemas frequentes envolvem multilinguismo, estilização e mensagens de validator

O primeiro tema de suporte é a tradução. O label é formado por três partes, e cada parte precisa ser mantida separadamente em cada idioma. Na prática, isso significa: para uma instalação bilíngue (BR/EN), o esforço de manutenção dobra. Quem trabalha com ext:l10nmgr deve referenciar chaves LLL explicitamente na definição do formulário, para que import/export funcione sem problemas. Um truque de projetos maiores: armazenar as três partes do label em uma única chave LLL com placeholders e montar no servidor na saída. Isso reduz perceptivelmente o número de strings a traduzir.

O segundo tema é estilização. Muitos design systems trabalham com checkboxes customizadas, reconstruídas via CSS a partir de um span ou label. O template default da extensão entrega um wrapper simples que colide com alguns CSS frameworks. Recomendamos sobrescrever o partial no overlay de site package e ajustar a estrutura ao styling do restante do formulário.

Em terceiro, mensagens de erro do validator são tropeço frequente. Se o usuário não clica na checkbox, deve aparecer "Por favor, aceite a política de privacidade", não a mensagem default "Campo obrigatório". A extensão suporta mensagens de erro customizadas via formElementsDefinition no YAML do formulário; a mensagem pode ser adaptada por elemento. Para acessibilidade isso é importante, porque leitores de tela leem a mensagem de erro diretamente e mensagens inespecíficas não ajudam. Recomendamos formular cada mensagem de erro de forma compreensível independentemente do contexto.

## TYPO3 v12 e v13 são totalmente suportados, migração de v10 exige ajuste no YAML

O form_element_linked_checkbox está disponível para TYPO3 v11, v12 e v13. A estrutura YAML do Form Framework mudou em detalhes entre v10 e v12, principalmente no registro de custom elements. No upgrade de uma instalação v10, definições de formulário que usam o elemento precisam ser adaptadas à nova sintaxe YAML.

Em projetos Gosign, migramos a extensão como parte do refactoring do Form Framework, não separadamente. O esforço é quase sempre mínimo, porque o elemento em cada formulário é referenciado apenas pelo seu type identifier. Na migração, verificamos ainda se os textos de consentimento LGPD são renderizados corretamente em cada idioma após o upgrade do TYPO3, e atualizamos os links de privacidade caso tenham mudado de URL ou texto.

--- Formlog TYPO3 - Registro de formulários | Gosign ---
> Formular-Logging-Extension para TYPO3: Registrar todas as entradas de formulários no backend. Backup para e-mails com falha, análise des.

## Por que uma em cada três consultas de contato no TYPO3 se perde sem logging

Formulários de contato são o canal de leads mais importante em sites corporativos. Mas o Form Framework do TYPO3 por padrão não armazena entradas no banco de dados - apenas envia e-mails. Se o servidor de e-mail cai, o registro SPF está mal configurado ou o timeout SMTP dispara, a consulta está perdida. Sem backup, sem rastreamento, sem análise. Formlog fecha essa lacuna registrando cada entrada de formulário no banco de dados TYPO3 - independentemente de o envio do e-mail ter sido bem-sucedido.

Na prática, isso afeta mais empresas do que se imagina: taxas de entrega de e-mail de servidores web ficam segundo estudos entre 85% e 95%. Com 100 consultas de contato por mês, isso significa 5 a 15 leads perdidos. Com um valor médio de lead de 500 EUR no B2B, soma-se 2.500 a 7.500 EUR de faturamento perdido por mês.

## Cenários típicos de uso

**Proteção contra falhas de e-mail.** Uma empresa de médio porte opera 3 formulários de contato em seu site TYPO3. O servidor SMTP do provedor tem timeout por 6 horas no fim de semana. Sem Formlog, todas as consultas nesse período estão perdidas. Com Formlog, a equipe de marketing encontra todas as entradas no backend TYPO3 na segunda-feira e pode dar seguimento manualmente.

**Comprovação de conformidade para LGPD (PT: RGPD) e ISO 27001.** Empresas precisam comprovar quando quais dados pessoais foram recebidos e quando foram excluídos. Formlog armazena entradas com timestamp e oferece exclusão automática configurável após X dias. Para auditorias ISO 27001, isso fornece documentação completa do processamento de dados.

**Análise do comportamento de entrada.** Quais campos são frequentemente deixados em branco? Em qual etapa do formulário os usuários desistem? Formlog torna esses dados visíveis no backend. Um integrador TYPO3 pode derivar otimizações sem usar uma ferramenta de analytics externa para formulários.

## Arquitetura técnica

Formlog se integra como Finisher no TYPO3 Form Framework (EXT:form). Cada formulário que tem um Finisher Formlog configurado escreve suas entradas após o submit em uma tabela de banco de dados própria (`tx_formlog_entries`).

A arquitetura em detalhe: o Finisher roda após a validação e antes do Finisher de e-mail. Cada entrada é armazenada como array serializado em JSON, junto com metadados (timestamp, identificador do formulário, idioma, página). O módulo de backend permite que editores e administradores filtrem, pesquisem e exportem as entradas registradas como CSV. A exclusão conforme LGPD ocorre via tarefa scheduler após um número configurável de dias (padrão: 90 dias).

Dependências: Formlog requer o TYPO3 Form Framework (EXT:form), que faz parte do Core desde TYPO3 v8. Extensões de formulário mais antigas como Powermail ou Formhandler não são suportadas - lá o logging é integrado nativamente.

## Problemas frequentes e soluções

**Formlog não registra todos os campos do formulário.** Causa: o Finisher Formlog deve ser configurado após a etapa de validação, mas antes do Finisher de redirect. Se o redirect atua primeiro, o Finisher Formlog não é mais executado. Solução: na configuração YAML, verificar a ordem dos Finishers - Formlog deve estar na posição 1.

**Módulo de backend não mostra entradas.** Frequentemente um problema de permissões: o usuário ou grupo de backend não tem acesso ao módulo Formlog. Solução: nas configurações de grupo de backend, ativar o módulo `formlog` em "Módulos permitidos".

**Exclusão automática não funciona.** O TYPO3 Scheduler deve estar corretamente configurado e rodando regularmente (cronjob a cada 5 a 15 minutos). Sem scheduler funcionando, a tarefa de exclusão nunca é acionada.

## Migração e compatibilidade de versões

Formlog foi desenvolvido pela Pagemachine e está disponível como pacote Composer (`pagemachine/typo3-formlog`). A extensão suporta TYPO3 v10 a v12 LTS. Para TYPO3 v13 ainda não há release oficial, mas a base de código usa APIs TYPO3 estáveis.

Quem migra de Powermail para o TYPO3 Form Framework perde o logging integrado do Powermail. Formlog é o substituto recomendado. A Gosign migra formulários incluindo configuração de logging.

Um aspecto que muitas equipes de projeto negligenciam: Formlog não é apenas uma ferramenta de backup, mas também uma ferramenta de auditoria. Quando um cliente alega ter enviado uma consulta há 3 semanas que nunca foi respondida, Formlog fornece a prova - ou a entrada existe com timestamp, ou nunca foi enviada. Para empresas com acordos de nível de serviço e gestão de reclamações, essa é uma vantagem mensurável que justifica a instalação em 10 minutos.

--- gb_events TYPO3 - Events | Gosign ---
> Event-Extension para TYPO3: Exibição simples de eventos e visualização de calendário. Mais leve que sf_event_mgt, para eventos sem função de registro.

## Nem todo evento precisa de uma inscrição, mas todo evento precisa de uma apresentação adequada

sf_event_mgt é o padrão para gestão de eventos no TYPO3: inscrição, lista de espera, pagamento, gestão de participantes. Mas muitas organizações apenas exibem eventos, sem inscrição online. Um calendário de concertos, um programa de eventos de uma comunidade, os horários de uma escola popular - em todos esses cenários, sf_event_mgt seria exagero. gb_events preenche essa lacuna: apresentação simples de eventos com visualização em calendário, sem o overhead de um sistema completo de gestão de eventos.

A extensão é feita para organizações que querem publicar datas, mas não gerenciá-las. Sem formulário de inscrição, sem lista de participantes, sem processamento de pagamento. Em compensação, uma listagem limpa, uma visualização em calendário e uma página de detalhe por evento.

## Cenários típicos de uso

**Sites de comunidades e igrejas.** Cultos, concertos, festas comunitárias, tardes para idosos - um calendário típico de comunidade tem 20 a 40 eventos por mês. Visitantes querem ver o que acontece quando, e talvez transferir as datas para seu calendário pessoal. Uma inscrição não é necessária, os eventos são públicos. gb_events mapeia isso com esforço mínimo de configuração.

**Escolas populares e instituições educacionais (visão geral do programa).** A inscrição para cursos roda por um sistema externo (Kufer, WebOpac), mas o programa deve ser pesquisável no site TYPO3. gb_events mostra os cursos como lista de eventos, filtrada por categoria (idiomas, criatividade, TI, saúde) e período. A página de detalhe vincula ao sistema externo de inscrição.

**Séries de eventos com datas recorrentes.** Um clube esportivo tem treino às segundas e quartas, um encontro todo primeiro quinta-feira. gb_events apresenta datas recorrentes sem que cada data individual precise ser criada manualmente. A recorrência é configurada, gb_events gera as datas automaticamente.

## Arquitetura técnica

gb_events é baseada em Extbase/Fluid e usa uma tabela de banco de dados própria `tx_gbevents_domain_model_event`. Cada evento tem os campos: título, descrição, data de início, data de término, local, imagem, categoria e opcionalmente uma regra de repetição. As categorias usam as categorias de sistema do TYPO3, o que simplifica a integração com outras extensões.

O frontend consiste em três visualizações: visualização em lista (cronológica, filtrável por categoria e período), visualização em calendário (representação mensal com dias clicáveis) e visualização de detalhe (informações completas do evento). Todas as visualizações são templates Fluid e podem ser sobrescritas no sitepackage.

A visualização em calendário renderiza um grid de tabela HTML com 7 colunas (dias da semana) e 4 a 6 linhas (semanas). Cada célula contém os eventos do respectivo dia como títulos linkados. A navegação entre meses funciona por parâmetro de link (GET), não por AJAX. Isso é amigável ao SEO, porque cada mês tem uma URL própria e pode ser indexado pelo Google.

A lógica de repetição funciona similarmente ao calendarize: um registro com regra de repetição gera eventos virtuais. Estes são calculados em tempo de execução e não materializados no banco de dados. Isso economiza armazenamento, mas requer tempo de computação a cada carregamento de página. O framework de cache do TYPO3 neutraliza essa desvantagem para páginas cacheadas.

## Problemas frequentes e soluções

**Eventos não aparecem na visualização em lista.** Causa frequente: a pasta de armazenamento (Storage PID) no plugin não corresponde à pasta onde os eventos foram criados. gb_events filtra eventos por Storage PID. Solução: selecionar a pasta de armazenamento correta no FlexForm do plugin ou remover a restrição via TypoScript (`persistence.storagePid = 0` mostra eventos de todas as pastas).

**Eventos passados desaparecem imediatamente.** gb_events oculta eventos por padrão assim que a data de término é ultrapassada. Para alguns casos de uso (arquivo de eventos, referências), eventos passados devem permanecer visíveis. Solução: adaptar a query do Repository no controller (incluir eventos passados) ou configurar um modo separado de visualização em lista "Arquivo".

**Sem função de exportação iCal.** Visitantes querem transferir eventos para seu calendário. gb_events não oferece download .ics por padrão. Solução: criar um Page-Type próprio para exportação iCal. O template Fluid gera output conforme iCalendar (VCALENDAR, VEVENT, DTSTART, DTEND, SUMMARY, LOCATION). O esforço é de aproximadamente 3 horas de desenvolvimento.

## Migração e compatibilidade de versões

gb_events suporta TYPO3 v10 e v11. Para v12 existe uma versão comunitária no GitHub, mas a compatibilidade não é completamente verificada. Para v13, não há planejamento atual.

A alternativa para TYPO3 v12/v13 é sf_event_mgt, a extensão de eventos significativamente mais abrangente e melhor mantida. sf_event_mgt suporta oficialmente v12 e v13. Quem não precisa de funcionalidade de inscrição pode configurar sf_event_mgt sem inscrição e ainda usar a apresentação de eventos e visualização em calendário. O escopo de funcionalidades é maior, mas a complexidade também.

A migração de gb_events para sf_event_mgt requer uma migração de dados: os eventos de `tx_gbevents_domain_model_event` para `tx_sfeventmgt_domain_model_event`. Os campos são similares (título, descrição, data, local), mas não idênticos. Um script de migração baseado em SQL resolve isso em 1 a 2 horas. Os templates Fluid devem ser adaptados, pois sf_event_mgt usa ViewHelpers e variáveis diferentes.

Para projetos com poucos eventos (menos de 50 por ano), uma solução customizada baseada em tx_news também é viável: eventos como registros de notícias com campos de data e uma representação em calendário no template. A Gosign orienta sobre a solução mais econômica e assume a migração quando necessário.
---

--- Geocoding TYPO3 - Koordinaten | Gosign ---
> Geocoding-Extension para TYPO3: Converter endereços automaticamente em coordenadas GPS. Base para localizador de filiais, busca por raio e exibição de mapa.

## Por que todo localizador de filiais TYPO3 sem geocoding falha na qualidade dos dados

Localizadores de filiais, busca de revendedores e busca por raio - todos têm o mesmo fundamento: coordenadas GPS. Mas empresas armazenam dados de localização como endereços - rua, número, CEP, cidade. A conversão de endereço para coordenada (geocoding) não acontece sozinha. geocoordinates resolve esse problema automaticamente: a extensão monitora campos de endereço em registros TYPO3 e calcula a cada alteração as coordenadas GPS correspondentes via serviço de geocoding.

Sem extensão de geocoding, editores teriam que copiar manualmente latitude e longitude do Google Maps para cada localidade. Com 50 localidades, isso é uma hora de trabalho. Com 500 localidades, um dia inteiro - e a cada mudança de endereço, o processo recomeça.

## Cenários típicos de uso

**Geocoding automático para registros tt_address.** Uma empresa com 120 localidades na região mantém todos os endereços na extensão TYPO3 tt_address. geocoordinates registra um hook DataHandler na tabela tt_address. Assim que um editor altera um endereço ou cria uma nova localidade, o serviço de geocoding é chamado em segundo plano. As coordenadas são escritas nos campos `latitude` e `longitude` do banco de dados. A extensão de mapa maps2 lê esses campos e posiciona o marcador no lugar correto.

**Geocoding em lote em migrações de dados.** Uma empresa migra 2.000 endereços de um sistema antigo para TYPO3. Os registros importados têm rua e CEP, mas sem coordenadas. geocoordinates oferece um comando CLI que geocodifica todos os registros sem coordenadas em um lote.

**Busca por raio baseada em CEP.** Uma empresa de serviços oferece busca por raio: "Encontre o parceiro mais próximo." O visitante digita seu CEP, geocoordinates converte o CEP em coordenadas, e um cálculo de distância SQL (fórmula Haversine) retorna todas as localidades no raio de 25, 50 ou 100 km, ordenadas por distância.

## Arquitetura técnica

geocoordinates se integra como hook DataHandler no TYPO3 Core. A extensão monitora tabelas e campos configuráveis. Quando um campo de endereço monitorado muda, um request de geocoding é acionado assincronamente.

A extensão suporta dois provedores de geocoding: Google Geocoding API (alta precisão, disponível mundialmente, requer API Key com billing ativado) e OpenStreetMap Nominatim (gratuito, sem registro necessário, em conformidade com LGPD (PT: RGPD), taxa máxima de 1 request/segundo).

As coordenadas são armazenadas em campos de banco de dados configuráveis. A extensão pode ser aplicada via configuração TCA a qualquer tabela, não apenas tt_address.

Para busca por raio, geocoordinates disponibiliza uma função de distância Haversine que pode ser incorporada em Extbase Repositories ou queries QueryBuilder diretas. O cálculo ocorre no nível do banco de dados (MySQL/MariaDB), não em PHP. Isso é crítico para performance: um cálculo de distância via PHP sobre 10.000 localidades leva segundos, um cálculo SQL com índice leva milissegundos.

## Problemas frequentes e soluções

**Geocoding retorna coordenadas erradas para endereços.** Endereços com caracteres especiais podem causar problemas quando a API não processa corretamente a codificação. Solução: garantir que os dados de endereço sejam enviados em UTF-8 para a API.

**Google Geocoding API retorna "OVER_QUERY_LIMIT".** Em geocoding em lote com mais de 50 requests por segundo, o Google limita a API. Solução: ativar rate-limiting no comando de lote (máx. 40 requests/segundo para contas padrão).

**Nominatim retorna resultados diferentes para o mesmo endereço.** Dados OpenStreetMap são mantidos pela comunidade e podem mudar. Solução: marcar coordenadas já geocodificadas como "verificadas" e re-geocodificar apenas em mudança manual do endereço.

## Migração e compatibilidade de versões

geocoordinates está disponível como pacote Composer para TYPO3 v10 a v12. A extensão é mantida por Stefan Froemken, que também desenvolve maps2. As duas extensões são coordenadas entre si mas podem ser usadas independentemente.

A Gosign combina geocoordinates por padrão com maps2 para entregar um stack completo de localizador de filiais: entrada de endereço pelo editor, geocoding automático em segundo plano, exibição de mapa com marcador e popup no frontend, busca por raio com entrada de CEP para o visitante. O stack é configurado em 2 a 3 dias e cobre os requisitos de 90% de todos os projetos de localizador de filiais.

--- Gewinnspiel TYPO3 - Sorteio online | Gosign ---
> Gewinnspiel no TYPO3: Verlosungen, Teilnahme, Auslosung. em conformidade com a LGPD, acelerada com IA desenvolvimento.

## Sorteios online no TYPO3 raramente falham na técnica, quase sempre no direito

Programar um sorteio leva 3 a 5 dias: formulário, validação, sorteio, e-mail ao ganhador. Torná-lo juridicamente seguro leva mais tempo, porque os requisitos jurídicos superam o esforço técnico. Termos de participação, consentimento separado de marketing, proibição de vinculação, exclusão automática de dados após término do sorteio, verificação de idade, exclusão de funcionários - estes não são extras opcionais, mas obrigações legais. No Brasil, a LGPD (PT: RGPD) e o Código de Defesa do Consumidor impõem requisitos específicos. Um sorteio TYPO3 sem essas salvaguardas arrisca notificações e multas.

TYPO3 não oferece extensão padrão para sorteios. A solução é sempre um desenvolvimento customizado que mapeia exatamente os requisitos do sorteio concreto. A Gosign desenvolve tais módulos como extensões TYPO3 baseadas em Extbase com camada completa de compliance LGPD.

## Cenários típicos de uso

**Campanhas de marketing com sorteio de produtos.** Um fabricante de bens de consumo sorteia 10 produtos entre todos os participantes que preenchem um formulário. O sorteio roda 4 semanas, depois os ganhadores são determinados por gerador de números aleatórios e notificados por e-mail. Os requisitos técnicos: formulário com campos obrigatórios (nome, e-mail, idade), participação única por e-mail (double opt-in), checkbox para termos de participação (não pré-selecionada), checkbox separada para consentimento de newsletter (opcional, não vinculada à participação), exclusão automática de dados 30 dias após o término.

**Sorteios vinculados a redes sociais.** Participantes são direcionados do Instagram ou Facebook para o site TYPO3, onde preenchem o formulário. A plataforma de mídia social não pode servir como mecanismo de participação (os termos das plataformas proíbem isso), apenas como fonte de tráfego. A página TYPO3 é a página oficial de participação. Em um cliente com 50.000 seguidores no Instagram, três sorteios em um ano geraram 12.000 contatos qualificados, dos quais 4.800 com opt-in de newsletter.

**Sorteios recorrentes de advento ou mensais.** Um calendário de advento com 24 portas, cada uma com um prêmio próprio. Tecnicamente mais desafiador: 24 sorteios em uma extensão, ativação temporizada, sorteio separado por dia, tracking de participação total (nenhum prêmio duplo). Em uma empresa de varejo, o calendário de advento aumentou o tráfego de dezembro em 300% em relação ao mês do ano anterior.

## Arquitetura técnica

Um módulo de sorteio TYPO3 consiste em cinco componentes:

**Formulário de participação.** Controller Extbase com template Fluid. Os campos do formulário são configuráveis: campos obrigatórios (nome, e-mail), campos opcionais (telefone, endereço), checkboxes (termos de participação, consentimento de marketing). O formulário usa proteção CSRF do TYPO3 (FormToken) e valida server-side. Validação client-side é complementar, mas não suficiente sozinha.

**Verificação de duplicatas.** Cada e-mail pode participar apenas uma vez. A verificação ocorre no nível do banco de dados (unique constraint em e-mail + ID do sorteio). Adicionalmente: double opt-in por e-mail de confirmação. Somente após clicar no link de confirmação a participação vale.

**Sorteio.** Uma tarefa Scheduler ou trigger manual no backend seleciona os ganhadores por gerador de números aleatórios criptográfico (`random_int()` em PHP, não `rand()` ou `mt_rand()`). O sorteio é protocolado no banco de dados: timestamp, seed, IDs dos ganhadores. Em caso de consultas regulatórias, o sorteio pode ser rastreado.

**Notificação de ganhadores.** E-mail automático aos ganhadores com parabéns e próximos passos (p.ex. inserção de endereço para envio). E-mail automático aos não-ganhadores (opcional, recomendado para fidelização). Todos os e-mails via Mail API do TYPO3 com templates Fluid.

**Ciclo de vida dos dados.** Exclusão automática de todos os dados de participantes após período configurável (padrão: 30 dias após término do sorteio). Uma tarefa Scheduler verifica diariamente se sorteios expiraram e exclui os registros associados. Dados de ganhadores (nome, endereço) são tratados separadamente, pois precisam ser armazenados por mais tempo para envio e documentação fiscal.

## Problemas frequentes e soluções

**Participações de bots falsificam os resultados.** Sem proteção, bots registram milhares de participações falsas. Solução: campo honeypot, rate limiting (máximo 3 submissões por IP por minuto) e double opt-in como tripla segurança. O double opt-in é a proteção mais eficaz: bots podem preencher formulários, mas não clicar em e-mails de confirmação.

**Violação da proibição de vinculação.** A participação no sorteio não pode ser vinculada a um consentimento de marketing. Se a checkbox de newsletter é campo obrigatório, há uma violação. Solução: sempre implementar consentimento de marketing como checkbox opcional e não pré-selecionada. No validador do formulário, verificar que a participação funciona também sem checkbox de marketing.

**Performance sob alta carga simultânea.** Um sorteio viral com 10.000 participações em uma hora sobrecarrega o servidor. Solução: configurar o form submit como página uncached (USER_INT), mas cachear a própria página do sorteio (USER). Para carga extrema: usar um processo worker separado para as escritas no banco e processar o formulário via queue.

## Migração e compatibilidade de versões

Módulos de sorteio são desenvolvimentos customizados e não têm um caminho de migração padrão. Em upgrades TYPO3, as APIs Extbase devem ser adaptadas: v9-v10 (middleware stack), v10-v11 (alterações Extbase), v11-v12 (refactoring TCA, módulos backend). O esforço por upgrade major é de 1 a 2 dias para um módulo de sorteio típico.

Para sorteios recorrentes, vale investir em uma extensão genérica configurada via módulo backend: nome do sorteio, período, prêmios, campos de formulário, templates de e-mail. Esse investimento único (5 a 8 dias de desenvolvimento) economiza 80% do esforço em cada sorteio subsequente. A Gosign desenvolve tais módulos como extensões TYPO3 reutilizáveis e assume quando necessário o rascunho dos termos de participação - a aprovação jurídica fica com o cliente.
---

--- Hero-Slider TYPO3 - Performance | Gosign ---
> Hero-Slider Extension para TYPO3. Frequentemente prejudicial à performance: imagens grandes, bibliotecas JS pesadas.

## O hero slider é a área mais cara de um site TYPO3, medida em tempo de carregamento

A área hero é a primeira coisa que visitantes veem. Com um slider, é também a mais lenta. Um hero slider típico no TYPO3 carrega 3 a 5 imagens em grande formato (500 KB a 2 MB cada), uma biblioteca JavaScript (jQuery + plugin de slider: 120 a 200 KB), animações CSS e scripts de inicialização. Juntos são 3 a 12 MB de dados antes que o visitante possa clicar em qualquer coisa. O Largest Contentful Paint (LCP) com tais configurações fica rotineiramente acima de 4 segundos, o que o Google classifica como "ruim" e custa rankings.

A solução não é um slider melhor, mas nenhum slider ou um radicalmente leve. Soluções CSS-only e bibliotecas de slider modernas como Swiper alcançam o mesmo efeito visual com uma fração do tempo de carregamento.

## Cenários típicos de uso

**Páginas iniciais com campanhas rotativas.** Marketing quer posicionar 3 a 5 mensagens proeminentemente: campanha sazonal, novo produto, anúncio de evento, premiação. O slider rota automaticamente, cada slide tem imagem, headline e botão CTA. O problema: estudos mostram consistentemente que apenas 1 a 2% dos visitantes interagem além do primeiro slide. Os outros 4 slides são carregados, mas não vistos. Uma imagem hero estática com uma mensagem clara performa regularmente melhor em testes A/B que um slider.

**Galerias de imagens na área do header.** Hotéis, restaurantes e locais de eventos mostram impressões como hero slider: vista externa, interior, terraço, pratos. Aqui um slider faz sentido, porque visitantes esperam múltiplas impressões. A otimização de performance: carregar apenas a primeira imagem imediatamente, as restantes via lazy loading. Com Intersection Observer e `loading="lazy"`, isso é possível sem biblioteca de slider.

**Destaques de produto com animação.** Sites de e-commerce mostram destaques de produto como slides animados. A animação deve gerar atenção. Na prática: transições CSS (`transform`, `opacity`) são mais performantes que animações JavaScript e usam GPU em vez de CPU. Um slider CSS-only com `scroll-snap-type` e `transition` alcança 60 fps em qualquer dispositivo.

## Arquitetura técnica

Hero sliders no TYPO3 são tipicamente implementados como Content Element: um FlexForm com configuração de slides (imagem, texto, link, ordem) e um template Fluid que renderiza os slides. A lógica do slider é executada por uma biblioteca JavaScript.

As bibliotecas mais utilizadas em projetos TYPO3: FlexSlider (desatualizado, jQuery), Slick (desatualizado, jQuery), Owl Carousel (desatualizado, jQuery), Swiper (moderno, sem jQuery, 139 KB) e Splide (moderno, sem jQuery, 29 KB). A escolha da biblioteca determina as características de performance de toda a área hero.

A arquitetura ideal para um hero slider em 2026:

**Opção 1: CSS-only (0 KB JavaScript).** `scroll-snap-type: x mandatory` no container, `scroll-snap-align: start` nos slides. Navegação via `scroll-behavior: smooth` e anchor links. Autoplay via animação CSS (`@keyframes`). Sem JavaScript necessário. Funciona em todos os navegadores modernos. Desvantagens: sem autoplay programático com pause-on-hover, sem animações de swipe.

**Opção 2: Swiper/Splide (29-139 KB JavaScript).** Funcionalidade completa de slider com touch, swipe, autoplay, paginação, lazy loading. Tree-shakeable, apenas os módulos usados são carregados. Integração no TYPO3 via Custom Content Element com FlexForm.

**Opção 3: Hero estático (0 KB JavaScript, 1 imagem).** Uma imagem, uma headline, um CTA. A configuração mais rápida e com maior conversão. A imagem é entregue como `<picture>` com `srcset`: 375px para mobile, 768px para tablet, 1440px para desktop. Com formato AVIF/WebP abaixo de 100 KB por variante.

## Problemas frequentes e soluções

**LCP acima de 4 segundos.** A imagem hero é o elemento LCP. Se carrega tarde demais, o score LCP é ruim. Solução: carregar a primeira imagem do slide com `fetchpriority="high"` e `loading="eager"` (não lazy). As demais slides com `loading="lazy"`. Converter formato de imagem para WebP/AVIF. Limitar tamanho de imagem ao tamanho real de exibição (sem imagem de 4000px para um viewport de 1440px).

**Cumulative Layout Shift (CLS) por slider que carrega depois.** O container do slider inicialmente não tem altura, após a inicialização JavaScript o layout salta. Solução: fixar a altura do container do slider via CSS (p.ex. `aspect-ratio: 16/9` ou `min-height: 60vh`). Assim o navegador reserva o espaço antes do JavaScript ser carregado.

**Autoplay não funciona em dispositivos móveis.** iOS Safari bloqueia autoplay de vídeos e algumas animações CSS por razões de economia de energia. Solução: desativar autoplay em dispositivos móveis e oferecer navegação por swipe. Visitantes em smartphones sabem que podem deslizar. Uma indicação estática ("Deslize para mais") é desnecessária.

## Migração e compatibilidade de versões

A maioria das extensões de hero slider no TER são desatualizadas e suportam no máximo TYPO3 v10 ou v11. Para v12/v13, recomenda-se sem exceção um Custom Content Element no sitepackage que incorpora uma biblioteca moderna ou aposta completamente em CSS.

A migração de sliders existentes ocorre em três passos: exportar dados de slides (imagens, textos, links do FlexForm ou banco de dados), configurar novo Content Element (FlexForm com os mesmos campos, mas template moderno) e converter os elementos de conteúdo existentes via SQL para o novo CType. O esforço: 1 a 2 dias para a configuração técnica, mais 0,5 dia por 10 sliders existentes para a migração de dados.

A Gosign recomenda em todo projeto de hero slider primeiro a pergunta: o site realmente precisa de um slider? Em 70% dos casos, um elemento hero estático performa melhor. Para os 30% restantes, a Gosign entrega uma solução Swiper ou CSS-only que permanece abaixo de 1,5 segundos de LCP.
---

--- Highcharts TYPO3 - Visualização de dados | Gosign ---
> Incorporar gráficos interativos Highcharts no TYPO3. Gerenciar gráficos e visualizações de dados diretamente no CMS. A Gosign também implementa alternativas.

## Highcharts traz visualização interativa de dados ao backend TYPO3, quando redatores precisam manter gráficos sem ter que trabalhar no Excel ou em ferramentas externas

Números, indicadores e tendências fazem parte de sites corporativos, como dados financeiros na área de relações com investidores, como dados de mercado em marketing de conteúdo, como resultados de avaliação em associações e órgãos públicos. A solução clássica são gráficos estáticos criados em Excel, exportados como PNG e enviados manualmente. Isso é trabalhoso e propenso a erros: quando um número muda, todo o gráfico precisa ser refeito. O Highcharts resolve o problema gerando gráficos diretamente a partir de dados estruturados, de forma interativa no navegador, com tooltips, efeitos de hover e funções de zoom. A integração TYPO3 torna o processo editorial totalmente apoiado no backend: redatores mantêm séries de dados em uma máscara de entrada, a extensão gera o gráfico.

A alavanca real de produtividade surge quando as séries de dados não são mantidas manualmente, mas puxadas de fontes externas. Um CSV da controladoria, um export de um data warehouse ou uma chamada API a um dashboard interno entrega os números, o TYPO3 renderiza a partir deles o gráfico público. Essa separação entre fonte de dados e apresentação transforma a manutenção de indicadores em operação de commit, não em troca de screenshots.

## Cenários típicos de uso

O caso clássico são páginas de relações com investidores e dados financeiros. Uma empresa listada em bolsa mostra evolução de receita, número de colaboradores e market share como gráficos interativos. Em divulgações trimestrais, a equipe de RI simplesmente atualiza a série de dados, o gráfico se renova automaticamente, e visitantes podem ler os valores exatos por ano via mouseover.

O segundo caso são resultados de pesquisas e estudos em associações, fundações e órgãos públicos. Uma pesquisa com associados, um estudo ambiental ou uma pesquisa de conjuntura é apresentada como gráfico de barras, linha ou pizza. O Highcharts permite exibir datasets complexos com muitas categorias de forma clara e oferece funções de export que permitem a visitantes levar os gráficos como imagem ou PDF.

Terceiro uso: marketing de conteúdo e data journalism. Blogs corporativos e revistas técnicas usam gráficos interativos para explicar correlações complexas, como evoluções de preço, market shares, estatísticas de uso. A interatividade aumenta o tempo de permanência e torna os conteúdos citáveis por outros veículos.

## Arquitetura técnica

O Highcharts como biblioteca JavaScript é um produto consolidado da empresa norueguesa Highsoft, distribuído sob licença comercial, mas gratuito para uso não comercial. A integração TYPO3 adiciona ao CMS máscaras de backend para manutenção de séries de dados e renderiza no frontend o código JavaScript correspondente, que inicializa o Highcharts.

Tipicamente, a extensão consiste em um content element no qual redatores configuram tipo de gráfico (linha, barra, pizza, area), rótulos de eixo, cores e séries de dados. Cada série pode ser mantida manualmente como tabela ou puxada de fontes externas como arquivos CSV, consultas de banco ou APIs REST. No frontend, a extensão emite um container div com JSON de configuração, um bloco script inicializa o Highcharts e renderiza o gráfico no cliente.

A questão de licença é central. Para projetos TYPO3 comerciais, uma licença Highcharts precisa ser adquirida, de algumas centenas a vários milhares de euros por ano, dependendo do escopo. Quem quer evitar isso encontra em Chart.js, ApexCharts ou Plotly boas alternativas sob licença MIT ou Apache. A decisão depende de features: o Highcharts oferece a gama mais ampla de tipos de gráfico e a melhor documentação, as alternativas cobrem casos padrão de forma confiável.

## Problemas frequentes e soluções

O primeiro problema é licenciamento nebuloso. Projetos começam assumindo que o Highcharts é gratuito, e no uso comercial chega a conta. A solução está em uma verificação de licença cedo: se o projeto é comercial, ou a licença Highcharts é orçada, ou desde o início se opta por uma alternativa livre. A Gosign esclarece essa questão no kickoff.

Segundo problema: performance em muitas séries de dados. Um gráfico com milhares de pontos bloqueia o navegador na renderização. A solução é redução de dados via agregação no servidor ou uso de módulos Highcharts como o Boost, que renderizam grandes volumes via WebGL. Para casos padrão, basta comprimir os dados brutos a uma granularidade razoável antes de chegarem ao navegador.

Terceiro problema: acessibilidade. Gráficos interativos frequentemente são inacessíveis para leitores de tela. O Highcharts oferece um módulo Accessibility que disponibiliza os dados como tabela estruturada em paralelo ao gráfico visual. A complementação pragmática é exibir abaixo de cada gráfico uma tabela HTML regular com os mesmos dados, oculta visualmente via CSS mas disponível para leitores de tela.

## Migração e compatibilidade de versões

As integrações TYPO3 para Highcharts existem em várias variantes de diferentes qualidade e atualidade. Para TYPO3 v11 existem extensões mantidas ativamente, para v12 e v13 a oferta é menor, frequentemente exige ajustes no ext_emconf e em configurações de serviço. Quem começa hoje deve verificar friamente se uma extensão existente ainda serve ou se uma integração em site package com uma biblioteca livre como Chart.js é o caminho mais seguro para o futuro.

Em cenário de upgrade, a versão do Highcharts é o ponto crítico. Novas versões do Highcharts ocasionalmente quebram a API, principalmente em tipos de gráfico complexos. Uma migração deve, portanto, ser testada sempre em staging antes de tocar em dashboards live.

Uma abordagem pragmática para projetos existentes: inventariar os gráficos atuais, listar os recursos realmente usados da biblioteca de gráficos em operação e verificar se uma alternativa cobre o mesmo. Em muitos casos, os requisitos são modestos, gráficos de linha e barra com poucas séries, e uma biblioteca livre os atende sem perda de qualidade. O orçamento de licença economizado pode fluir para uma melhor gestão de conteúdo das séries de dados.

A Gosign integra o Highcharts no TYPO3, acompanha esclarecimento de licença e projetos de migração, e implementa, quando necessário, alternativas mais leves como Chart.js ou ApexCharts como componente de site package. A escolha certa depende de quais tipos de gráfico são realmente necessários e qual orçamento existe para licenças.

--- Hotspot TYPO3 - Imagens interativas | Gosign ---
> Extensão TYPO3 para hotspots interativos em imagens: Áreas clicáveis em imagens com tooltip ou overlay.

## Imagens interativas explicam produtos complexos melhor que 1.000 palavras de texto

Uma planta de edifício com 12 salas marcadas, um corte transversal de máquina com 8 componentes descritos, um mapa da Europa com 15 localizações: todos esses casos de uso precisam de áreas clicáveis em uma imagem. O visitante clica em um componente e vê suas especificações. Clica em uma localização e vê endereço e contato. Extensões de hotspot para TYPO3 tornam imagens interativas ao vincular áreas definidas com tooltips, overlays ou links.

A questão mais interessante é se para isso é realmente necessária uma extensão. Hotspots baseados em SVG funcionam sem extensão, são mais leves, mais acessíveis e completamente controláveis no sitepackage. Para casos de uso simples, SVG é o melhor caminho. Para configurações complexas com muitos hotspots e manutenção via backend por editores, uma extensão justifica o uso.

## Cenários típicos de uso

**Imagens de produto com componentes clicáveis.** Fabricantes de máquinas, equipamentos e produtos técnicos usam hotspots para descrever componentes em uma foto de produto. Um compressor industrial com 8 conjuntos: clique no motor mostra dados de potência, clique no filtro mostra intervalos de troca. Em vez de uma longa descrição textual, a informação se revela visualmente. Em um fabricante de máquinas, imagens de produto interativas aumentaram o tempo de permanência em páginas de produto em 45%.

**Plantas de edifícios e campus.** Universidades, clínicas e grandes empresas mostram mapas interativos: clicar em edifício, selecionar andar, ver informações da sala. TYPO3 fornece os dados de salas a partir de uma fonte de dados Extbase, os hotspots são posicionados na planta. Em um complexo hospitalar com 14 edifícios, mapas interativos substituíram completamente o guia de orientação impresso.

**Infográficos com informações detalhadas.** Departamentos de marketing produzem infográficos sobre processos, cadeias de valor ou estruturas corporativas. Em vez de mostrar um arquivo PNG estático, os elementos do infográfico se tornam clicáveis: clique em uma etapa do processo abre a descrição detalhada. Funciona especialmente bem com temas complexos que não podem ser explicados linearmente.

## Arquitetura técnica

Extensões de hotspot no TYPO3 consistem em três partes: um editor backend para posicionamento dos hotspots, uma estrutura de dados para conteúdos de hotspot e um renderer frontend que exibe os hotspots sobre a imagem.

O editor backend é tipicamente um editor visual de posicionamento de pontos: o editor vê a imagem no backend TYPO3 e clica nos locais onde hotspots devem aparecer. As coordenadas são armazenadas como valores percentuais (relativos ao tamanho da imagem), não como pixels. Valores percentuais garantem que os hotspots permaneçam no lugar correto em exibição responsiva da imagem.

A estrutura de dados por hotspot: posição X (%), posição Y (%), texto de tooltip, conteúdo de detalhe (HTML/Fluid), tipo de ícone e opcionalmente um link para uma página de detalhe. Os dados são armazenados como relações inline (IRRE) ao elemento de conteúdo: um elemento de conteúdo tem 1:n hotspots.

No frontend, os hotspots são renderizados como elementos HTML absolutamente posicionados sobre a imagem. A imagem fica em um container com `position: relative`, os hotspots têm `position: absolute` com `left` e `top` em percentual. Ao clicar ou hover, o tooltip aparece como overlay, posicionado relativo ao hotspot.

A alternativa SVG funciona sem extensão: a imagem é criada como SVG (ou a imagem é incorporada como `<image>` em um SVG), os hotspots são elementos SVG (`<circle>`, `<rect>`, `<polygon>`) com atributos `data-` e event handlers. Os conteúdos de tooltip são lidos via JavaScript de um bloco `<script type="application/json">`.

## Problemas frequentes e soluções

**Posições de hotspot se deslocam em dispositivos móveis.** A imagem é exibida menor no smartphone, mas os hotspots ficam na posição desktop. Causa: hotspots posicionados em pixels em vez de porcentagem, ou o container não tem redimensionamento responsivo. Solução: armazenar todas as posições em porcentagem e tornar o container responsivo com `max-width: 100%` e `height: auto`. Adicionalmente: em dispositivos móveis, exibir hotspots como lista abaixo da imagem, pois toques com o dedo em pequenos pontos de hotspot são difíceis.

**Acessibilidade não garantida.** Hotspots puramente visuais sem navegação por teclado e sem texto para leitor de tela não são acessíveis. Solução: implementar cada hotspot como `<button>` (não como `<div>`), com `aria-label` para o leitor de tela e `tabindex` para navegação por teclado. O conteúdo do tooltip deve ser vinculado como `aria-describedby`.

**Performance com muitos hotspots.** Mais de 20 hotspots em uma imagem criam mais de 20 elementos DOM com event listeners. Em dispositivos móveis antigos, isso pode causar engasgos. Solução: event delegation em vez de listeners individuais. Um único listener no container em vez de 20 nos hotspots. Com hotspots baseados em SVG, a performance é geralmente melhor, pois elementos SVG são renderizados nativamente pelo navegador.

## Migração e compatibilidade de versões

Extensões de hotspot no TER suportam TYPO3 v10 e v11. Para v12 e v13 não existem extensões de hotspot amplamente mantidas. A tendência é para soluções baseadas em SVG implementadas como Custom Content Element no sitepackage, que não requerem extensão de terceiros.

A migração de uma extensão de hotspot para uma solução baseada em SVG requer: exportar os dados de hotspot (coordenadas, textos), criar um template SVG que renderiza os pontos como elementos SVG, e configurar um Custom Content Element que gerencia os dados via relação IRRE. O esforço é de 3 a 5 dias, dependendo do número de imagens com hotspot.

A solução mais à prova de futuro: hotspots baseados em CSS com `<map>` e `<area>` para cenários simples, SVG com JavaScript para interações complexas. A Gosign implementa imagens interativas como Custom Content Elements e orienta sobre a tecnologia adequada baseada na complexidade, requisitos de acessibilidade e número de imagens com hotspot.
---

--- Lista de associações TYPO3 - Municipal | Gosign ---
> Plugin de lista de associações para TYPO3: Exibir, filtrar, ordenar associações. Típico para sites municipais e federações. Filtro de categorias.

## Municípios e federações precisam de um banco de dados estruturado de associações em vez de listas estáticas

Quem procura o clube de xadrez local no site de uma prefeitura espera uma máscara de filtro, não uma lista PDF de 15 páginas. Exatamente esse problema é resolvido pela hwvereinsliste: a extensão mapeia associações como registros TYPO3 e as torna acessíveis via filtro por categoria, busca fulltext e visualizações de detalhe. Para portais municipais, federações estaduais e associações esportivas regionais, o plugin é há anos uma ferramenta comprovada que permite à redação a manutenção sem intervenção de desenvolvedores.

A realidade em municípios brasileiros é semelhante: registros de associações frequentemente ainda circulam como documentos Word em secretarias. hwvereinsliste substitui esse workflow por um banco de dados central no backend TYPO3, disponibilizado via plugins no frontend. Cidadãos encontram sua associação em segundos, editores atualizam dados de contato sem acesso FTP.

## Cenários típicos de uso envolvem portais municipais e bancos de dados esportivos

O cenário mais frequente é a lista clássica de associações em um site municipal. Um município com 80 a 120 associações registradas mantém todas as entradas centralmente no backend TYPO3. Cidadãos filtram no frontend por categorias como Esporte, Cultura, Social ou Juventude. A visualização de detalhe mostra contato, horários de atividade e dados de contato. A redação do site municipal atualiza entradas autonomamente, sem ajuda técnica.

O segundo cenário envolve federações e confederações esportivas. Uma federação esportiva estadual administra frequentemente 500 a 2.000 entidades associadas em dezenas de modalidades esportivas. Aqui a função de filtro se torna o recurso central: usuários combinam modalidade, cidade e faixa etária para encontrar a associação adequada na vizinhança. hwvereinsliste suporta essa filtragem múltipla nativamente.

Um terceiro cenário são portais de voluntariado. Agências de voluntariado usam a extensão para listar organizações que buscam apoio voluntário. A categorização roda via TYPO3 Sys-Categories, o que permite sobreposição com outros elementos de conteúdo na mesma página.

## Arquitetura técnica se baseia em registros Extbase e templates Fluid

hwvereinsliste usa o framework Extbase/Fluid do TYPO3. Associações são armazenadas como registros de domínio próprios em uma tabela dedicada. Cada registro contém campos para nome, descrição, endereço, dados de contato, URL do site, logo e categorias. A categorização usa TYPO3 Sys-Categories, simplificando a integração com outras extensões.

No frontend estão disponíveis dois plugins: uma visualização em lista com função de filtro e busca, e uma visualização de detalhe para associações individuais. Os templates são baseados em Fluid e podem ser sobrescritos via caminhos TypoScript ou site package. Quem quer adaptar o layout copia os templates Fluid para o próprio package e adapta estrutura HTML e classes CSS sem alterar a extensão em si.

A filtragem funciona por padrão client-side para volumes pequenos de dados e server-side para acervos maiores. Para instalações com mais de 500 associações, recomenda-se a combinação com uma solução de índice de busca como ke_search para melhorar a performance da busca fulltext.

Um aspecto frequentemente esquecido em projetos municipais: a acessibilidade. Desde a Lei Brasileira de Inclusão (LBI), órgãos públicos devem tornar seus sites acessíveis. Isso afeta também a lista de associações: elementos de filtro devem ser operáveis por teclado, listas de resultados precisam de ARIA labels, e a função de busca deve funcionar com leitores de tela. Os templates padrão da extensão não atendem completamente esses requisitos e devem ser adaptados.

## Problemas frequentes envolvem importação, categorização e exibição responsiva

O problema mais frequente na configuração inicial é a importação de dados. Municípios têm seus dados de associações tipicamente em planilhas Excel com formatos inconsistentes. Nomes de colunas variam, categorias são mantidas como texto livre em vez de taxonomia padronizada, e dados de contato contêm entradas desatualizadas. A Gosign resolve isso com um workflow de importação assistido por IA: a planilha Excel é analisada automaticamente, colunas são mapeadas, categorias normalizadas e duplicatas detectadas.

O segundo problema envolve a estrutura de categorias. Se categorias não são definidas de forma limpa previamente, surgem redundâncias como "Futebol", "Clube de Futebol" e "Futebol Amador" como três entradas separadas. Recomendamos definir antes do go-live uma taxonomia de categorias com no máximo 15 a 20 categorias principais e criá-las no backend TYPO3 como Sys-Categories.

Terceiro problema: a exibição responsiva da visualização em lista. Em dispositivos móveis, a exibição em tabela rapidamente se torna confusa. Os templates Fluid devem renderizar para viewports móveis uma exibição em cards em vez de tabela, realizável por uma simples adaptação de template no site package.

## Migração para v12 requer ajustes Extbase, v13 ainda não é oficialmente suportada

hwvereinsliste foi desenvolvida primariamente para TYPO3 v9 e v10. Para TYPO3 v12 é necessário um ajuste da persistência Extbase, pois a interface de query mudou. Concretamente, isso afeta as classes Repository e a configuração de persistência baseada em TypoScript, que desde v12 é resolvida via Classes.php. Os caminhos de template também devem ser convertidos para a nova estrutura SiteSet.

Para TYPO3 v13 não há suporte oficial do autor da extensão. Quem migra para v13 deve adaptar a extensão por conta própria ou avaliar uma solução alternativa. A Gosign verifica nesses casos se uma migração da extensão ou uma reconstrução com base em Extbase com API atual é mais econômica. Para bancos de dados pequenos com menos de 200 entradas, um plugin customizado é frequentemente a melhor escolha, porque é exatamente adaptado aos requisitos do município e não traz dependências legacy.
---

--- imagemap TYPO3 - Gráficos interativos | Gosign ---
> imagemap para TYPO3: Gráficos interativos com áreas clicáveis. Responsivo, acessível, alternativas SVG.

## imagemap torna imagens clicáveis sem que redatores precisem tocar em HTML, a escolha certa para plantas de edifício, organogramas e gráficos de produto com vários hotspots

Alguns conteúdos não podem ser explicados tão eficientemente com palavras quanto com uma imagem na qual áreas diferentes podem ser clicadas. Uma planta de edifício em que cada departamento leva à página da equipe correspondente. Um organograma com links para os perfis individuais. Uma imagem de produto na qual um clique na roda, no motor ou no cockpit mostra detalhes técnicos. O HTML oferece desde os anos 90 a funcionalidade Image Map, mas nenhum redator quer digitar coordenadas à mão em um campo de texto. O imagemap adiciona essa função ao TYPO3 com um editor visual: redatores clicam no backend sobre a imagem, marcam uma área e a linkam a uma página de destino.

A promessa real da extensão é que orientação espacial e navegação sejam unificadas. Em vez de fazer visitantes pularem entre uma visão gráfica e uma lista de links separada, o próprio gráfico vira elemento de navegação. Para conteúdos estruturados geográfica, hierárquica ou tecnicamente, isso oferece um acesso significativamente mais intuitivo.

## Cenários típicos de uso

O primeiro caso são mapas de localização e panoramas de campus. Hospitais, universidades brasileiras, parques de exposições e parques industriais trabalham com mapas panorâmicos nos quais edifícios ou áreas individuais linkam diretamente para páginas de informação. A alternativa clássica seria uma lista com links, que no entanto perde a referência espacial. O imagemap combina a orientação gráfica com a estrutura de links.

O segundo caso de uso são organogramas e hierarquias. Uma empresa mostra a estrutura de seus departamentos como gráfico, cada nó leva ao perfil da respectiva pessoa ou à página do departamento. Para a redação, isso é mais fácil de manter do que um layout complexo de tabelas com células linkadas.

Terceiro caso: gráficos de produto com feature hotspots. Produtos técnicos, máquinas, veículos, equipamentos, são apresentados em desenho explodido ou corte em que os principais componentes são explicados via clique. Isso substitui uma longa lista de texto e leva os visitantes exatamente para onde está o seu interesse.

## Arquitetura técnica

A extensão imagemap clássica para TYPO3 mantém as coordenadas como registros estruturados no banco e renderiza no frontend um elemento HTML map com as respectivas tags area. No backend há um editor visual que mostra a imagem original como área de seleção e permite aos redatores desenhar retângulos, círculos ou polígonos. Cada área recebe um URL de destino, um texto alternativo e, opcionalmente, um tooltip.

O desafio técnico está na responsividade. O HTML map clássico trabalha com coordenadas absolutas em pixels, que não funcionam em imagens escaladas. Extensões imagemap resolvem isso via JavaScript que recalcula as coordenadas relativas no resize, ou usando SVG como formato de saída. O SVG é a solução limpa: coordenadas vetoriais escalam naturalmente, tratamento de eventos e styling via CSS funcionam nativamente, e leitores de tela conseguem ler os elementos estruturados.

A integração acontece via content element no módulo de página. Redatores escolhem a imagem base do FAL, definem os hotspots e configuram opcionalmente opções globais como cor padrão das áreas, efeitos de hover e comportamento de tooltip. A saída pode ser ajustada via template Fluid no site package para garantir conformidade com a identidade visual.

## Problemas frequentes e soluções

O primeiro problema é acessibilidade. Image maps HTML só são realmente legíveis para leitores de tela se cada tag area tiver um texto alternativo significativo e o próprio map for reconhecido como navegação estruturada. Muitos redatores preenchem o alt text sem pensar ou deixam vazio, o que torna o map inútil para usuários cegos. A solução é uma obrigação editorial de dar a cada hotspot um alt text descritivo, e uma verificação técnica no site package que impeça textos vazios no salvamento.

Segundo problema: usabilidade mobile. Um hotspot que mede 30 por 30 pixels em tamanho desktop fica minúsculo em um smartphone. A solução pragmática é uma alternativa mobile que, abaixo de um certo breakpoint, substitui a imagem por uma lista com os mesmos destinos. Isso exige uma lógica Fluid que entrega duas apresentações e alterna via CSS.

Terceiro problema: esforço de manutenção em mudanças de imagem. Quando a imagem base, um mapa de localização ou foto de produto, é trocada, todas as coordenadas precisam ser redefinidas, porque os motivos se deslocaram. Solução pragmática: redatores trabalham com um formato de imagem fixo, versionado, e documentam a grade de coordenadas para que em updates apenas correções mínimas sejam necessárias. Alternativamente, uma solução baseada em SVG pode trabalhar de forma relativa desde o início.

## Migração e compatibilidade de versões

Para TYPO3 v11, v12 e v13 existem várias extensões imagemap mantidas ativamente, frequentemente com nomes levemente diferentes. Em upgrades, vale verificar se a extensão originalmente usada ainda é desenvolvida ou se uma troca para uma alternativa mais moderna faz mais sentido. Abordagens baseadas em SVG vão substituir a médio prazo os HTML maps clássicos, porque funcionam melhor tanto em responsividade quanto em acessibilidade.

Uma dica prática para migrações: se um projeto existente contém dezenas de imagemaps, vale um script que lê os registros de coordenadas existentes e os converte em paths SVG. A mudança pode então acontecer em um único deployment e a extensão ser desligada. Isso reduz a dívida técnica e torna os gráficos preparados para o futuro.

Quem começa hoje deve preferir a abordagem SVG, seja via extensão com saída SVG, seja via um padrão próprio no site package que ofereça aos redatores um editor visual e no frontend entregue SVG. A Gosign implementa os dois caminhos e orienta na escolha da arquitetura adequada ao projeto em questão.

--- in2publish TYPO3 - Publicação de conteúdo | Gosign ---
> in2publish: Publicar conteúdo de staging para live. Configuração multi-servidor e workflows , acelerado com IA.

## Por que in2publish define o workflow de conteúdo em projetos TYPO3 enterprise

Em instalações TYPO3 profissionais, editores não trabalham diretamente no sistema live. Eles mantêm conteúdos em um ambiente de staging, alinham alterações internamente e publicam apenas após aprovação. Mas como os dados chegam do staging ao live? Sem in2publish, isso significa: criar dump de banco de dados no staging, importar no live, sincronizar arquivos via FTP. Um processo suscetível a erros, que leva 30 a 60 minutos e onde um clique errado pode sobrescrever todo o banco de dados live.

in2publish da in2code elimina esse processo. Editores clicam em "Publish" no backend TYPO3, e a extensão sincroniza exatamente os registros e arquivos alterados para o sistema live. Sem acessos FTP, sem dumps de banco de dados, sem downtime. O padrão da indústria para staging de conteúdo no TYPO3.

## Cenários típicos de uso

**Workflow de aprovação editorial.** Uma corporação opera seu site corporativo em TYPO3 com 12 editores em 3 departamentos. Cada departamento mantém sua área no staging. A liderança revisa as alterações e as aprova. O editor clica em "Publish" e apenas suas páginas aprovadas vão para o live. Outras áreas do site permanecem inalteradas. in2publish exibe uma visualização de diferenças: quais campos mudaram, quais imagens são novas, quais registros serão sobrescritos.

**Publicação multi-idioma.** Uma empresa mantém seu site em 5 idiomas. A redação alemã publica textos finalizados, enquanto a tradução para inglês ainda está em andamento. in2publish permite publicação seletiva por idioma: o conteúdo alemão vai ao ar, o inglês permanece no staging até a tradução ser concluída.

**Lançamentos de campanha com datas definidas.** A equipe de marketing prepara uma página de lançamento de produto que deve ir ao ar em 15 de outubro às 8h. Todo o conteúdo é preparado e testado no staging. No dia do lançamento, o editor responsável publica tudo em uma única etapa. Em caso de problemas, in2publish pode reverter as alterações.

## Arquitetura técnica

in2publish trabalha nos níveis de banco de dados e sistema de arquivos. A extensão compara o estado do banco de dados de staging com o de live e transfere diferenças.

A arquitetura consiste em quatro componentes centrais: Record Comparison (compara cada registro entre staging e live, resolve relações e apresenta em estrutura de árvore), sincronização FAL (transfere imagens e documentos via SSH/SFTP, comparando tamanhos e hashes), camada de transporte (comunicação via SSH com autenticação por chave pública, com a versão Enterprise suportando também comunicação baseada em HTTP) e configuração (via YAML define quais tabelas são publicadas e quais são excluídas).

Dependências: TYPO3 Core, acesso SSH entre servidor staging e live, extensão PHP-SSH2 ou binários ssh2 no servidor.

## Problemas frequentes e soluções

**Publicação aborta com "SSH Connection Failed".** Causa mais frequente: a chave SSH do servidor staging não está depositada no servidor live, ou a configuração SSH no in2publish aponta para host/porta errados. Solução: testar conexão SSH manualmente, depois verificar credenciais na configuração in2publish.

**Registros no live não são atualizados.** A tabela não está na whitelist da configuração in2publish. Isso acontece frequentemente com tabelas personalizadas de extensões próprias. Solução: adicionar a tabela na configuração e definir as relações.

**Arquivos FAL faltam após publicação no live.** O storage FAL no sistema live tem caminho diferente do staging, ou as permissões no servidor live não permitem escrita na pasta de upload. Solução: garantir que o caminho base do FAL Storage seja idêntico em ambos os sistemas.

## Migração e compatibilidade de versões

in2publish é mantido ativamente pela in2code e está disponível para TYPO3 v11 e v12 LTS como pacote Composer. A versão Enterprise oferece recursos adicionais (transporte HTTP, logging estendido, suporte multi-ambiente) e é licenciada com custo.

Em um upgrade TYPO3, a configuração in2publish deve ser verificada: novas tabelas de sistema, definições TCA alteradas e novos tipos de elementos de conteúdo requerem ajustes na whitelist. A Gosign recomenda após cada upgrade de Core um publish de teste com uma única página para validar a configuração, antes de retomar a operação editorial completa. O teste deve incluir uma página com todos os tipos de conteúdo relevantes: elementos de texto, imagens, downloads de arquivo e pelo menos uma relação. Só assim todos os caminhos de sincronização são cobertos.

--- in2studyfinder TYPO3 - Cursos acadêmicos | Gosign ---
> Buscador de cursos para sites TYPO3 de universidades. Filtro por área, diploma, localização, modalidade de estudo. Hochschul-spezifische Extension.

## Interessados em cursos esperam um motor de busca, não uma brochura em PDF

Universidades com 50 a 300 cursos enfrentam um problema concreto: interessados querem filtrar, não rolar. Buscam por tipo de diploma, área, modalidade e localidade - simultaneamente. in2studyfinder da in2code resolve exatamente isso dentro do TYPO3. A extensão foi desenvolvida especificamente para o setor de ensino superior e mapeia a estrutura complexa de bacharelado, mestrado, diploma, tempo integral, parcial, dual e paralelo ao trabalho em uma única máscara de filtro. Mais de 20 universidades de língua alemã usam a extensão produtivamente.

Para equipes web de universidades que mantêm suas informações de cursos via páginas estáticas ou soluções caseiras, a mudança para in2studyfinder é um ganho significativo de eficiência. Em vez de criar uma subpágina própria para cada novo curso, editores mantêm um registro no backend, e a extensão gera visualização em lista, página de detalhe e função de filtro automaticamente.

## Cenários típicos de uso vão do diretório de cursos à visão geral de acreditação

O cenário padrão é o buscador central de cursos na homepage da universidade. Interessados chegam a uma página, selecionam área, diploma e modalidade e recebem imediatamente uma lista filtrada. Um clique leva à página de detalhe com grade curricular, pré-requisitos de admissão, prazos de inscrição e contatos. Em uma universidade de ciências aplicadas com 80 cursos, isso reduziu os pageviews até a informação desejada de uma média de 6 para 2.

Segundo cenário: busca entre campi em universidades com múltiplas localizações. Uma universidade com localizações em três cidades mostra todos os cursos em uma visualização e permite filtrar por campus. A informação de localização é mantida como relação própria, não como texto livre, o que garante filtragem consistente.

Terceiro cenário: visões gerais de acreditação para garantia de qualidade. Universidades devem comprovar quais cursos estão acreditados e até quando. in2studyfinder pode mapear esses metadados como Custom Fields e exibi-los na visualização em lista, o que o departamento de acreditação usa como base de trabalho.

## Arquitetura técnica utiliza registros Extbase com relações configuráveis

in2studyfinder é uma extensão Extbase/Fluid da in2code, a prestadora de serviços TYPO3 por trás do powermail e in2publish. Cursos são armazenados como registros de domínio em uma tabela própria. Cada registro contém campos obrigatórios como título, tipo de diploma, duração regulamentar, créditos ECTS e área, além de campos opcionais para nota de corte, mensalidades, status de acreditação e link de inscrição.

A filtragem no frontend funciona via requisições AJAX, para que a página não recarregue ao filtrar. Isso melhora consideravelmente a experiência do usuário, especialmente em dispositivos móveis. A configuração de filtro é controlável via TypoScript: quais campos são exibidos como filtro, qual ordenação se aplica e quantos resultados aparecem por página.

Templates são baseados em Fluid e podem ser sobrescritos via site packages. A extensão fornece templates padrão que funcionam como ponto de partida para a maioria das universidades. Para universidades com design corporativo próprio, adaptamos os templates e os integramos no site package existente, para que páginas de cursos se encaixem visualmente de forma integrada no site.

## Problemas frequentes envolvem qualidade de dados, performance e multilinguismo

O maior problema na introdução é a qualidade dos dados. Informações de cursos existem em universidades frequentemente em três a cinco sistemas diferentes: HIS/HISinOne, bancos de dados próprios dos departamentos, brochuras PDF e textos de site mantidos manualmente. Antes que in2studyfinder possa entrar em produção, essas fontes devem ser consolidadas. A Gosign apoia esse processo com um template de importação estruturado que os departamentos preenchem e que importamos automaticamente no TYPO3.

Segundo problema: performance com grandes volumes de dados. Universidades com mais de 200 cursos e relações complexas (área, localidade, modalidade, idioma) podem experimentar latências na filtragem AJAX se as consultas ao banco não estiverem otimizadas. Índices nas relações e um cache bem configurado no TypoScript resolvem o problema geralmente por completo.

Terceiro problema: multilinguismo. Universidades internacionais com cursos em inglês precisam de tradução completa das máscaras de filtro, categorias e páginas de detalhe. in2studyfinder usa o framework de tradução do TYPO3, mas a configuração de idiomas fallback e overlays de tradução deve ser cuidadosamente ajustada aos requisitos da universidade.

## TYPO3 v12 é suportado, compatibilidade v13 depende do cronograma de release da in2code

in2code mantém in2studyfinder ativamente e entrega atualizações regulares. A versão atual suporta TYPO3 v11 e v12. Como in2code é uma prestadora de serviços TYPO3 comercial com estratégia de produto de longo prazo, a compatibilidade v13 é esperada, mas ainda não oficialmente liberada. No upgrade de v10 ou v11 para v12, breaking changes afetam principalmente a configuração TypoScript (nova sintaxe SiteSet) e eventuais ViewHelpers customizados nos templates. A estrutura do banco de dados permanece estável, de modo que uma migração de dados geralmente não é necessária.
---

--- in2template TYPO3 - Gerenciamento de templates | Gosign ---
> Extensão de gerenciamento de templates TYPO3 da in2code. Simplifica o gerenciamento de Fluid Templates e Site Packages. Organização estruturada.

## in2template traz estrutura a site packages antes que eles virem inferno de manutenção

Quem monta em TYPO3 um site package para um site grande enfrenta sempre a mesma pergunta: como organizo templates, partials, layouts e content elements para que ainda sejam manuteníveis em dois anos? A extensão in2template, da casa in2code, é a tentativa de dar a essa pergunta uma resposta estruturada. Ela entrega uma estrutura básica para site packages modernos: estrutura de diretórios clara, content elements predefinidos, configuração preparada para TypoScript, Fluid Styled Content e backend layouts. Para times TYPO3 que iniciam novos projetos com regularidade, o in2template substitui a prática antiga de copiar e colar do último projeto de cliente por um padrão documentado.

O público-alvo são agências com vários projetos TYPO3 paralelos e times internos que mantêm templates corporativos para sites de grupos empresariais ou universidades. Especialmente onde desenvolvedoras e redatoras compartilham o site package, uma convenção consistente de pasta e nomenclatura é de sobrevivência. O in2template atende exatamente essa lacuna.

## Cenários típicos de uso

Um primeiro cenário é o início limpo de projeto. Uma agência com oito desenvolvedoras e três projetos TYPO3 em curso adota o in2template como padrão interno para site packages. Cada novo projeto começa com o mesmo esqueleto: estrutura de diretório idêntica, convenções de nome idênticas, base TypoScript idêntica. O resultado: um desenvolvedor pode trocar de projeto sem precisar se reorientar a cada vez.

Um segundo cenário é a modernização de um site package antigo. Um portal universitário com 800 páginas e uma pasta de templates que cresceu desde o TYPO3 v7 é reestruturado no âmbito de um upgrade de v11 para v12. Em vez de arrastar o mato antigo, o time reconstrói o site package baseado no in2template e migra os conteúdos passo a passo.

Um terceiro cenário é o onboarding de novos redatores. Uma editora brasileira com 30 redatores explica, com base no esqueleto in2template, para que serve cada content element. A consistência em nomenclatura e estrutura encurta o treinamento, a taxa de erros no backend cai.

Um quarto cenário é o template interno de refactoring. Uma empresa com cinco instalações TYPO3 de safras diferentes quer levar, a longo prazo, os site packages a uma estrutura uniforme. O in2template serve como esqueleto de referência contra o qual cada projeto antigo é reconstruído gradualmente, sem que o time precise discutir uma nova estrutura-alvo a cada vez.

## Arquitetura técnica

O in2template não é um add-on clássico, mas mais um template para um site package próprio. A extensão traz uma estrutura de diretórios: Resources/Private/Templates, Resources/Private/Partials, Resources/Private/Layouts, Configuration/TypoScript, Configuration/TsConfig, Configuration/TCA/Overrides. O esqueleto é complementado por content elements preparados (texto, texto com imagem, accordion, teaser grid) e uma configuração para backend layouts.

A instalação acontece como download Composer clássico do pacote, que depois é copiado para o repositório do próprio site package e renomeado. Na prática, times usam o in2template menos como dependência direta, o comum é um clone inicial que depois cresce por projeto. Isso transforma a extensão em starter kit, não em framework que precise ser atualizado entre versões.

Para a integração com Fluid Styled Content existem mecanismos de override próprios que garantem a coexistência dos content elements fornecidos com os elementos do core. Paths TypoScript são consistentemente namespaced, para que vários site packages rodem em paralelo na mesma instalação.

## Problemas frequentes e soluções

O primeiro problema é a confusão com um framework. Times que integram o in2template como Bootstrap ou Tailwind e esperam updates têm decepção: a extensão é um template para copiar, não um stack upstream. A solução é encarar o in2template como modelo único e versionar claramente o site package que dele sai.

O segundo problema é o inchaço com content elements não usados. O starter kit traz mais elementos do que a maioria dos projetos precisa. Quem não usa carrega mesmo assim pela manutenção. A solução é um cleanup imediatamente após o import inicial: apagar content elements não usados, remover backend layouts não usados, cortar blocos TypoScript não usados.

O terceiro problema é a adaptação a design systems individuais. O in2template entrega CSS próximo ao Tailwind com classes utility próprias. Quem usa um design system existente com nomes de token próprios precisa traduzir os stylings entregues de forma consistente, senão surge duplicidade de estilo e cascata contraditória.

Um quarto problema são conflitos com outros starter kits. Quem adota parcialmente o in2template e integra em paralelo blocos de outro esqueleto ganha paths TypoScript contraditórios e namespaces Fluid sobrepostos. A solução é tomar, no início do projeto, uma decisão por exatamente um esqueleto e manter componentes adicionais inconsistentes em uma camada própria do projeto claramente nomeada.

## Migração e compatibilidade de versões

O in2template é mantido pela in2code para TYPO3 v11 e v12, a compatibilidade com TYPO3 v13 é atualizada acompanhando os ciclos de release do próprio TYPO3. Como a extensão em projetos é quase sempre clonada e adaptada, a questão de versão é menos uma questão de caminhos de update e mais uma questão de disciplina de código: times devem, no upgrade do próprio site package, lançar um olhar no repositório atual do in2template para incorporar melhorias estruturais (novas convenções de backend layout, novos patterns Fluid).

Importante no upgrade de um site package baseado em in2template é olhar convenções TYPO3 alteradas: TCA overrides, definições de backend layout, registro de content element e renderização Fluid mudaram várias vezes entre v11 e v13. Quem não replica essas mudanças no próprio site package corre o risco de conteúdos no backend ficarem de repente vazios ou os wizards de content element não aparecerem mais.

A Gosign assume em projetos TYPO3 a análise de quais partes do site package existente podem ser arrumadas segundo um padrão semelhante ao in2template e quais migram melhor para um esqueleto próprio minimalista. O resultado é um site package que passa por code reviews sem murmúrios e que no próximo upgrade TYPO3 não produz surpresas.

--- Social Share Buttons TYPO3 | Gosign ---
> Social Share Buttons Extension para TYPO3. A Gosign recomenda links de compartilhamento personalizados e leves, sem overhead de extensão.

## Botões de compartilhamento social como extensão são desnecessários na maioria dos projetos TYPO3

A ideia é simples: visitantes devem poder compartilhar conteúdos com um clique no LinkedIn, X ou Facebook. insign_share_buttons entrega exatamente isso como extensão TYPO3 - botões para diversas redes, configuráveis no backend. Mas a realidade mostra: para uma funcionalidade que no fundo consiste em cinco links HTML, uma extensão completa com configuração própria, setup TypoScript e obrigação de atualização é na maioria dos casos overhead. A Gosign recomenda em vez disso links de compartilhamento nativos que podem ser implementados em 15 minutos e não criam dependência.

Isso é especialmente relevante desde a LGPD (PT: RGPD): muitas extensões de social share carregam JavaScript das redes em segundo plano, o que sem consulta de consentimento é contrário à proteção de dados. Links de compartilhamento puramente baseados em URL contornam esse problema completamente, pois só estabelecem conexão com a respectiva rede ao clicar.

## Cenários típicos de uso se limitam a conteúdos mantidos editorialmente

O cenário padrão é o site corporativo com blog ou revista. Editores querem exibir botões para LinkedIn, X, Facebook e e-mail abaixo de cada artigo. insign_share_buttons permite isso via um elemento de conteúdo incorporado no template da página. A extensão lê o título e URL da página atual e gera as URLs de compartilhamento.

Um segundo cenário envolve portais de intranet onde funcionários devem compartilhar notícias internas via Teams ou Slack. Aqui a extensão é de fato mais útil que em sites públicos, porque a problemática da LGPD dentro de uma empresa é avaliada diferentemente e a configuração dos alvos de compartilhamento pode ser mantida pelo backend.

Terceiro cenário: sites com foco em employer branding onde vagas de emprego devem ser divulgadas via mídia social. Os botões de compartilhamento são usados especificamente em páginas de carreira para que funcionários compartilhem vagas abertas em sua rede. A taxa de conversão desses botões é de 0,5 a 2% dos visitantes da página conforme valores de experiência.

## Arquitetura técnica é um elemento de conteúdo simples com configuração TypoScript

insign_share_buttons registra um elemento de conteúdo no TYPO3 que é inserido via template de página ou como plugin. A configuração define quais redes são exibidas, se ícones ou labels de texto são usados e se contadores devem ser mostrados. O rendering ocorre via templates Fluid que podem ser sobrescritos no site package.

As URLs de compartilhamento são geradas server-side e seguem o esquema padrão das respectivas redes: `https://www.linkedin.com/sharing/share-offsite/?url=` mais a URL encodada da página para LinkedIn, `https://twitter.com/intent/tweet?url=` para X. Metadados como título e descrição são lidos das propriedades da página ou dos tags OpenGraph.

A extensão não tem dependências notáveis além do Core TYPO3. Não há carregamento de JavaScript de domínios externos, desde que a função de contadores permaneça desativada. Se a função de contadores for ativada, chamadas API às redes são disparadas, o que por sua vez requer consulta de consentimento.

Um detalhe técnico frequentemente negligenciado: a URL de compartilhamento deve ser URL-encoded para que caracteres especiais em títulos de página (acentos, e comercial, aspas) sejam passados corretamente às redes. A extensão cuida desse encoding automaticamente, o que em links de compartilhamento manuais é um erro frequente.

## Problemas frequentes são violações da LGPD, tags OpenGraph ausentes e conflitos de estilo

Problema um: proteção de dados. Muitas instalações têm a função de contadores ativa, que sem consentimento de cookie transmite dados pessoais a servidores nos EUA. A solução: desativar contadores e usar exclusivamente links de compartilhamento baseados em URL que só estabelecem conexão ao clicar. Melhor ainda: substituir a extensão completamente por links de compartilhamento nativos que ficam como Fluid Partial no site package.

Problema dois: tags OpenGraph ausentes ou incorretas. Se a página TYPO3 não fornece meta tags og:title e og:description, LinkedIn e Facebook mostram uma preview vazia ou puxam fragmentos de texto aleatórios ao compartilhar. A solução não está na extensão de compartilhamento, mas na configuração SEO da página: tags OpenGraph devem estar corretamente definidas no template da página.

Problema três: conflitos de estilo entre os estilos CSS da extensão e o design corporativo. A extensão traz stylesheets próprias que podem colidir com estilos de botão existentes. A solução limpa: desativar o CSS da extensão e estilizar os botões pelo próprio stylesheet do site package.

Um problema adicional frequentemente notado tardiamente: falta de suporte a compartilhamento via WhatsApp. Em dispositivos móveis, WhatsApp é o canal de compartilhamento mais usado, mas nem toda extensão suporta nativamente o link de compartilhamento WhatsApp. A adição manual é trivial (https://api.whatsapp.com/send?text={url}), mas deve ser explicitamente incorporada.

## A extensão funciona no TYPO3 v12, uma reconstrução é mais econômica

insign_share_buttons é compatível com TYPO3 v12. Para TYPO3 v13, a disponibilidade depende do mantenedor. A Gosign recomenda em uma migração para v12 ou v13 substituir a extensão por um simples Fluid Partial. Cinco linhas de HTML por rede, sem dependência de extensão, sem obrigação de atualização, total conformidade com a LGPD. O esforço para essa mudança é de uma a duas horas incluindo estilização e teste de todos os links de rede. Na Gosign, aplicamos essa abordagem como padrão em todos os novos projetos TYPO3 e mantemos um conjunto de templates Partial para LinkedIn, X, Facebook, WhatsApp e e-mail que pode ser integrado em qualquer sitepackage.
---

--- Inxmail TYPO3 - Newsletter corporativo | Gosign ---
> Inxmail Professional é um sistema corporativo de newsletter da Alemanha. Integração TYPO3: sincronização de assinantes, sincronização de templates,.

## Inxmail é a plataforma enterprise de newsletter que conecta nativamente redações TYPO3

Empresas com mais de 50.000 destinatários de newsletter, requisitos rigorosos de compliance e um site TYPO3 existente enfrentam uma decisão concreta: Mailchimp com processamento de dados nos EUA e risco de proteção de dados ou uma solução alemã que se integra diretamente à infraestrutura de conteúdo existente. Inxmail Professional é essa solução. Servidores na Alemanha, processamento de dados certificado, e uma extensão TYPO3 que controla listas de assinantes, templates e campanhas diretamente a partir do CMS.

A extensão TYPO3 sincroniza inscrições bidirecionalmente: novos assinantes de formulários TYPO3 chegam automaticamente em listas Inxmail, cancelamentos no Inxmail são espelhados de volta ao TYPO3. Para equipes de marketing, isso significa: uma fonte de dados, sem exportações manuais, sem risco de listas desatualizadas.

## Cenários típicos de uso cobrem newsletter B2B, e-mails transacionais e comunicação de eventos

O cenário principal é o newsletter B2B clássico para empresas com 10.000 a 500.000 destinatários. A redação mantém conteúdos no TYPO3, a extensão transfere teasers e links automaticamente para templates Inxmail. Responsáveis de marketing segmentam destinatários por setor, região ou interesse e enviam variantes específicas por grupo-alvo. Taxas de abertura e dados de clique fluem de volta ao backend TYPO3 via API, para que a redação possa ver a performance de cada contribuição.

Segundo cenário: e-mails transacionais disparados por ações de usuários no site. Uma confirmação de registro, um link de download ou uma confirmação de pedido não são enviados pelo servidor de e-mail local, mas pela infraestrutura Inxmail com taxa de entrega garantida. SPF, DKIM e DMARC estão pré-configurados no Inxmail, o que melhora significativamente a entregabilidade em comparação com um mailer PHP padrão.

Terceiro cenário: comunicação de eventos para empresas que realizam regularmente feiras, webinars ou conferências. O convite, lembretes e e-mails de follow-up são configurados como campanhas baseadas em triggers no Inxmail e disparados por eventos no TYPO3, como por uma inscrição via formulário powermail.

## Arquitetura técnica conecta formulários frontend TYPO3 com a API REST Inxmail

A extensão usa a API REST Inxmail para comunicação entre TYPO3 e Inxmail Professional. No núcleo, a integração consiste em três módulos: um serviço de sincronização de assinantes, um módulo de sincronização de templates e um trigger de campanhas.

O sync de assinantes roda via tarefa Scheduler em intervalos configuráveis (típico: a cada 5 a 15 minutos) sincronizando novas inscrições, alterações e cancelamentos entre TYPO3 e Inxmail. A direção do sync é configurável: unidirecional (TYPO3 para Inxmail) ou bidirecional. No sync bidirecional, conflitos são resolvidos por timestamps, onde o registro mais recente ganha.

O módulo de sync de templates transfere áreas de página TYPO3 como conteúdos de newsletter. Editores marcam elementos de conteúdo no backend TYPO3 como "aptos para newsletter", e a extensão renderiza esses elementos em um template HTML compatível com Inxmail. Isso elimina a manutenção dupla de conteúdo de site e conteúdo de newsletter.

A autenticação ocorre via API Keys configuradas no Extension Manager do TYPO3. Todas as chamadas de API rodam via HTTPS, e a extensão registra cada operação de sync em uma tabela de log dedicada, o que é relevante para auditorias de compliance.

## Problemas frequentes envolvem conflitos de sync, rendering de template e rate limits da API

O tema de suporte dominante é o conflito de sync na sincronização bidirecional. Quando um assinante é alterado simultaneamente no TYPO3 e no Inxmail, podem surgir inconsistências de dados. A solução: definir uma direção clara de sync. Em 90% dos casos, TYPO3 é a fonte líder para dados mestres, Inxmail a fonte líder para dados de engajamento (aberturas, cliques, bounces).

Segundo problema: diferenças de rendering HTML entre frontend TYPO3 e cliente de e-mail. Um elemento de conteúdo exibido corretamente no site pode parecer diferente no Outlook ou Gmail. A extensão traduz HTML TYPO3 em CSS inline para compatibilidade com clientes de e-mail, mas layouts complexos com Flexbox ou Grid devem ser simplificados para clientes de e-mail.

Terceiro problema: rate limits da API em grandes operações de sync. Quem sincroniza 100.000 assinantes de uma vez pode atingir o limite da API Inxmail. A solução: sync em lotes com tamanho de pacote configurável (recomendado: 500 registros por chamada API) e backoff exponencial em respostas de rate limit.

## TYPO3 v12 é suportado pela extensão oficial, v13 requer verificação

Inxmail mantém a extensão TYPO3 ativamente, pois o mercado TYPO3 é um canal de vendas relevante para Inxmail Professional. A versão atual suporta TYPO3 v11 e v12. No upgrade de v10 para v12, principalmente as configurações de tarefa Scheduler devem ser adaptadas, pois TYPO3 v12 alterou a API Scheduler. A autenticação API e o sync de assinantes permanecem estáveis.

Para TYPO3 v13 ainda não há release oficial. Empresas que planejam um upgrade para v13 devem coordenar a disponibilidade antecipadamente com a Inxmail, pois integrações de newsletter enterprise estão entre as dependências mais críticas em um upgrade de CMS. Como solução intermediária, a integração pode ser realizada via um middleware layer customizado que acessa diretamente a API Inxmail sem a extensão. A Gosign implementou essa solução para clientes que queriam migrar para v13 antes da extensão oficial estar disponível.
---

--- iSpider TYPO3 - Rastreador web | Gosign ---
> Web-Crawler/Spider para TYPO3: Rastrear páginas internas, encontrar links quebrados, gerar sitemap. Ferramenta de QA para garantia de qualidade e análise SEO.

## Links quebrados custam rankings e confiança, mas quase ninguém os verifica regularmente

Todo site TYPO3 com mais de 200 páginas tem links quebrados. Editores excluem páginas, movem conteúdos ou alteram slugs de URL sem verificar todos os links internos. O resultado: erros 404 que o Google avalia como sinal de qualidade e que frustram visitantes. iSpider é um web crawler interno para TYPO3 que crawla o próprio frontend, identifica links quebrados e gera um sitemap. A ferramenta fecha a lacuna entre verificação manual e ferramentas SEO externas que não têm acesso a áreas protegidas.

Para redações e gerentes técnicos de projeto, iSpider é um instrumento de QA que funciona sem dependências externas. O crawler roda no backend TYPO3, conhece a estrutura de páginas e pode verificar áreas protegidas por senha que ferramentas externas como Screaming Frog não alcançam.

## Cenários típicos de uso vão de verificações pré-lançamento a monitoramento contínuo

O cenário mais frequente é a verificação pré-lançamento antes de um relaunch ou upgrade TYPO3. Antes de uma nova versão ir ao ar, iSpider crawla o ambiente de staging e entrega uma lista completa de todos os links quebrados, imagens ausentes e cadeias de redirect. Um relaunch típico de um site de médio porte (500 a 1.000 páginas) produz por experiência 30 a 80 links quebrados que sem crawl sistemático iriam para produção sem serem descobertos.

Segundo cenário: monitoramento contínuo no dia a dia editorial. Uma tarefa Scheduler semanal crawla o site e envia um relatório à redação com todos os novos erros 404 desde a última execução. Assim problemas são reconhecidos e corrigidos em dias em vez de meses.

Terceiro cenário: análise SEO da estrutura de links internos. iSpider mostra quais páginas não têm links internos de entrada (páginas órfãs) e quais páginas possuem especialmente muitos links de entrada. Esses dados ajudam na estratégia de conteúdo e na otimização de links internos.

## Arquitetura técnica funciona como módulo backend com integração Scheduler

iSpider se registra como módulo backend no TYPO3 e usa o Scheduler TYPO3 para execuções automatizadas de crawl. O crawler começa de uma página inicial configurável (tipicamente a root page) e segue todos os links internos recursivamente até uma profundidade configurável. Links externos são verificados quanto à acessibilidade, mas não seguidos.

Os resultados são armazenados em uma tabela de banco de dados própria: URL, código de status HTTP, tempo de resposta, página referenciadora e timestamp. O módulo backend mostra os resultados como lista filtrável com ordenação por código de status, o que facilita a priorização de correções.

A velocidade de crawl é controlável pela configuração: requisições simultâneas, tempo de espera entre requisições e profundidade máxima de crawl. Para grandes instalações com mais de 5.000 páginas, recomenda-se um crawl noturno via Scheduler para não afetar a carga do servidor durante o dia.

## Problemas frequentes são timeouts de servidor, crawls incompletos e falsos positivos

O problema mais frequente: o crawl aborta em sites grandes porque o limite de memória PHP ou max_execution_time é atingido. A solução: dividir o crawl via Scheduler em lotes e aumentar os limites PHP para o contexto CLI (recomendado: memory_limit 512M, max_execution_time 0 para CLI).

Segundo problema: crawls incompletos em conteúdo renderizado por JavaScript. iSpider é um crawler server-side que não executa JavaScript. Single Page Applications ou conteúdos carregados por AJAX não são capturados pelo crawler. A solução: para áreas intensivas em JavaScript, usar um crawler externo como Screaming Frog complementarmente.

Terceiro problema: falsos positivos em links externos. Alguns sites bloqueiam crawlers por detecção de User-Agent e retornam código de status 403, embora a URL seja acessível pelo navegador. iSpider reporta isso como erro. A solução: configurar uma lista de exceções para falsos positivos conhecidos e definir o User-Agent string para um valor típico de navegador.

## iSpider é uma ferramenta legacy, alternativas de crawler externo são mais poderosas

iSpider foi desenvolvido para TYPO3 v7 e v8 e não tem suporte oficial para v12 ou v13. Quem migra para versões atuais do TYPO3 deve avaliar alternativas externas. Screaming Frog (ferramenta desktop, até 500 URLs gratuita), Sitebulb ou o Linkvalidator integrado do TYPO3 cobrem as funções centrais. A Gosign usa em projetos próprios uma combinação do Linkvalidator Core do TYPO3 para verificações internas e crawls automatizados do Screaming Frog para análises SEO abrangentes. Em uma migração do iSpider, verificamos quais configurações e relatórios na configuração existente são críticos e os mapeamos na nova solução.
---

--- iubenda TYPO3 - Proteção de dados | Gosign ---
> iubenda oferece banners de consentimento de cookies e políticas de privacidade geradas automaticamente. Die TYPO3-Integração bettet beides ein. Alternative.

## Cookie consent e política de privacidade em uma solução parece prático, mas cria dependências

Desde a LGPD (PT: RGPD), todo site precisa de um banner de consentimento de cookies e uma política de privacidade atualizada. iubenda oferece ambos como solução SaaS: um widget JavaScript para o banner de consentimento e um gerador para políticas de privacidade e cookies que se atualizam automaticamente quando leis mudam. A extensão TYPO3 incorpora ambos no código-fonte da página. Para empresas que não querem contratar nem um DPO nem um escritório de advocacia para a manutenção contínua, iubenda é uma solução pragmática.

O trade-off é claro: conveniência contra dependência. O banner de consentimento e a política de privacidade são carregados dos servidores iubenda. Se o serviço cair ou a API mudar, o site é afetado. Alternativas como dp_cookieconsent ou Usercentrics funcionam pelo mesmo princípio, mas com focos diferentes em configurabilidade e preço.

## Cenários típicos de uso envolvem sites de PMEs, portais e presença internacional

O cenário padrão é o site de empresa de médio porte com 20 a 100 páginas que usa Google Analytics, um formulário de contato e vídeos YouTube incorporados. iubenda escaneia o site, reconhece automaticamente os serviços utilizados e gera uma política de cookies adequada. O banner de consentimento bloqueia os cookies reconhecidos até o visitante consentir. O esforço de configuração para esse cenário é de uma a duas horas.

Segundo cenário: portais multilíngues que operam em diferentes jurisdições. iubenda suporta além da LGPD europeia também o CCPA californiano e a LGPD brasileira. A política de privacidade é automaticamente exibida no idioma do visitante e contém as bases legais relevantes para a respectiva localização. Para empresas com público-alvo na Europa, nos EUA e na América do Sul, isso economiza a criação separada de três a quatro políticas diferentes.

Terceiro cenário: sites com integrações de terceiros que mudam frequentemente. Quando departamentos de marketing regularmente incorporam novos pixels de tracking, widgets de chat ou embeds de mídia social, iubenda atualiza automaticamente a política de cookies no próximo scan do site. Isso reduz o risco de que novos serviços rodem sem consulta de consentimento.

## Arquitetura técnica incorpora um widget JavaScript externo no TYPO3

A extensão TYPO3 integra iubenda via dois code snippets: uma tag JavaScript para o banner de consentimento e um código embed para a política de privacidade. Ambos os snippets são configurados no Extension Manager do TYPO3 e automaticamente exibidos no header HTML ou na página de privacidade. A extensão em si é mínima e contém pouca lógica própria.

O banner de consentimento funciona segundo o padrão TCF 2.0 (Transparency and Consent Framework) e bloqueia cookies via técnica de proxy: scripts externos só são carregados quando o visitante consentiu. O bloqueio funciona pela reescrita de tags script (type="text/plain" em vez de type="text/javascript") e carregamento posterior via JavaScript após consentimento.

A geração automática de política é baseada em um scanner de site que crawla o domínio e reconhece serviços utilizados. Os textos gerados são juridicamente verificados e atualizados pela equipe jurídica da iubenda em caso de mudanças legais. A política é incorporada na página de privacidade como iFrame ou embed HTML direto.

## Problemas frequentes são erros de bloqueio de scripts, perdas de performance e deslocamento de conteúdo

O problema mais frequente: nem todos os scripts de terceiros são corretamente bloqueados. Quando um script não é carregado via tag HTML padrão, mas dinamicamente via JavaScript, a técnica de proxy pode não reconhecê-lo. A solução: verificação manual de todos os serviços incorporados e configuração explícita no dashboard iubenda.

Segundo problema: perdas de performance pelo JavaScript adicional. O widget iubenda tem 40 a 80 KB (comprimido) e é carregado de servidores externos. Isso pode piorar o Largest Contentful Paint em 200 a 400ms. A solução: carregar o widget de forma assíncrona e garantir que não bloqueie o rendering.

Terceiro problema: Content Layout Shift pelo banner exibido posteriormente. Quando o banner aparece sobre o conteúdo da página, desloca a área visível. Google mede isso como Cumulative Layout Shift (CLS) e avalia negativamente. A solução: configurar o banner como overlay (não como elemento inserido) ou reservar um placeholder fixo no CSS.

## iubenda funciona independentemente da versão TYPO3, porque a integração é mínima

Como a extensão no fundo incorpora apenas dois snippets JavaScript, não há dependência profunda da API TYPO3. A integração funciona com TYPO3 v10, v11, v12 e previsivelmente também v13 sem ajustes. No upgrade, basta verificar se a incorporação do snippet no header HTML ainda funciona corretamente, o que geralmente é o caso. A Gosign recomenda mesmo assim realizar um teste de consentimento de cookies em cada upgrade TYPO3 para garantir que todas as regras de bloqueio ainda funcionam.
---

--- j77 Template TYPO3 | Gosign ---
> Template-Paket para TYPO3. Layout pronto como ponto de partida. A Gosign recomenda sitepackages personalizados em vez de templates prontos para projetos.

## Templates TYPO3 prontos aceleram o início, mas freiam a evolução

j77_template é um pacote de template pré-configurado para TYPO3 que entrega um layout pronto como ponto de partida. Header, footer, navegação, áreas de conteúdo e definições básicas de estilo estão incluídos. Para agências que querem montar rapidamente um protótipo TYPO3 ou para departamentos de TI internos sem desenvolvedores frontend, é tentador: instalação, ativação, pronto. A realidade mostra que templates prontos em projetos profissionais causam mais trabalho do que economizam após 3 a 6 meses.

A razão: todo pacote de template traz uma estrutura HTML, classes CSS e configuração TypoScript próprias. Assim que o design precisa desviar do padrão, luta-se contra a lógica do template em vez de trabalhar com ela. Um sitepackage customizado, adaptado desde o início aos requisitos, custa mais inicialmente, mas economiza tempo em cada alteração posterior.

## Cenários típicos de uso são protótipos, portais internos e sites de associações

O cenário mais frequente é o início rápido para protótipos e provas de conceito. Uma agência quer mostrar a um cliente em dois dias como seu conteúdo ficaria no TYPO3. j77_template entrega um layout apresentável sem desenvolvimento frontend. O protótipo é substituído após aprovação por um sitepackage sob medida.

Segundo cenário: portais internos e aplicações de intranet onde o design é secundário. Um departamento de TI constrói um portal interno de conhecimento no TYPO3 e precisa de uma interface funcional, não um design corporativo. j77_template entrega navegação, breadcrumb e rendering de conteúdo out of the box.

Terceiro cenário: sites de associações e pequenas organizações sem fins lucrativos com orçamento limitado. Quando todo o projeto web deve ficar abaixo de 5.000 euros, um pacote de template pronto pode eliminar custos de desenvolvimento frontend e liberar orçamento para conteúdo e funcionalidade.

## Arquitetura técnica é um sitepackage padrão com TypoScript pré-configurado

j77_template é tecnicamente um sitepackage TYPO3 instalado pelo Extension Manager. Traz templates Fluid para Page Layouts, templates Partial para header, footer e navegação, além de configurações TypoScript para rendering de conteúdo. Os arquivos CSS são baseados em Bootstrap ou framework similar.

A estrutura de templates segue o padrão TYPO3: Resources/Private/Templates para Page Layouts, Resources/Private/Partials para áreas reutilizáveis e Resources/Private/Layouts para templates de quadro Fluid. A configuração TypoScript define os caminhos de template, configura o rendering de conteúdo via FLUIDTEMPLATE e define a estrutura de navegação.

Adaptações são possíveis redirecionando os caminhos de template via TypoScript para arquivos próprios. Isso funciona para templates individuais, mas em alterações extensivas leva a manter de facto um sitepackage paralelo, o que anula a vantagem do template pronto.

## Problemas frequentes são conflitos de upgrade, overrides CSS e documentação ausente

Problema um: conflitos de upgrade na atualização TYPO3. Pacotes de template são fortemente ligados a uma versão TYPO3. Quando um upgrade introduz breaking changes em Fluid ou TypoScript, o pacote de template precisa ser atualizado. Se o mantenedor não faz isso a tempo, o template bloqueia todo o upgrade TYPO3.

Problema dois: overrides CSS que se sobrescrevem mutuamente. O template traz estilos próprios, o design corporativo requer desvios, e extensões adicionais também têm CSS. O resultado é uma cascata de overrides que produz efeitos colaterais imprevisíveis a cada alteração.

Problema três: documentação ausente ou desatualizada. Templates comunitários como j77_template são frequentemente mantidos por indivíduos e não têm documentação profissional. Quais constantes TypoScript estão disponíveis, quais variáveis Fluid existem nos templates e como o comportamento responsivo é configurado deve ser descoberto por análise de código.

## Para v12 e v13, a Gosign recomenda a mudança para um sitepackage próprio

j77_template não tem suporte garantido para TYPO3 v12 ou v13. Em uma migração, é o momento ideal para substituir o pacote de template por um sitepackage próprio. Os custos de um sitepackage próprio se amortizam já na primeira grande alteração de design que com um template alheio significaria horas ou dias de trabalho de override.

A Gosign cria sitepackages exatamente adaptados ao design corporativo e aos requisitos funcionais do projeto. O esforço inicial para um sitepackage simples é de 2 a 5 dias de trabalho, dependendo da complexidade do design. Geração de templates assistida por IA acelera o processo: a partir de um mockup de design, nosso tooling gera templates Fluid, configuração TypoScript e estrutura CSS base, que desenvolvedores seniores finalizam.
---

--- jumpurl TYPO3 - Rastreamento de downloads | Gosign ---
> jumpurl: Legacy Download-Tracking no TYPO3. Migração para soluções modernas de rastreamento. acelerado com IA.

## jumpurl foi removido do Core desde TYPO3 v9 e não deve mais ser utilizado

jumpurl foi por anos parte integrante do Core TYPO3 e fazia uma coisa simples: redirecionar downloads e links externos por uma URL de redirect para tornar cliques contáveis. Um download PDF não ia diretamente ao navegador, mas por um endereço jumpurl que registrava o clique no banco de dados e depois redirecionava ao download real. No auge da extensão, estimadamente 40% de todas as instalações TYPO3 usavam jumpurl para tracking de downloads. Desde TYPO3 v9, jumpurl não faz mais parte do Core. Como extensão independente ainda existe, mas a arquitetura é desatualizada e alternativas modernas são superiores em todos os aspectos.

Quem ainda usa jumpurl trabalha com uma técnica da era TYPO3 v4. A extensão gera URLs crípticas com parâmetros hash que não são nem legíveis por humanos nem amigáveis ao SEO.

## Cenários típicos de uso eram tracking de downloads e monitoramento de links

O cenário principal foi e é tracking de downloads: quantas vezes o whitepaper foi baixado, quantas vezes a lista de preços, quantas vezes o catálogo de produtos? jumpurl registra cada clique em uma tabela de banco de dados com timestamp, endereço IP e referrer.

Segundo cenário: tracking de links externos. Quando um site corporativo linka para parceiros, fornecedores ou recursos, jumpurl mostra quais destinos externos recebem mais cliques. Isso é relevante para programas de afiliados e relatórios de parceiros.

Terceiro cenário: downloads seguros com controle de acesso. jumpurl pode vincular downloads a um login de usuário, para que apenas usuários logados possam baixar arquivos. O sistema de token garante que URLs diretas para arquivos protegidos não funcionem.

## Arquitetura técnica se baseia em reescrita de URL e logging de banco de dados

jumpurl registra um handler eID no Core TYPO3 que intercepta requests de entrada com parâmetro jumpurl. O parâmetro contém um hash que referencia a URL de destino ou o caminho do arquivo. O handler registra o acesso em uma tabela de banco de dados (tx_jumpurl_tracking), valida o hash e redireciona o navegador via redirect 302 ao destino real.

A configuração ocorre via constantes TypoScript: quais tipos de arquivo são rastreados (típico: PDF, DOCX, XLSX, ZIP), se links externos são capturados e se o tracking está ativado. A extensão modifica automaticamente os links gerados no frontend para que editores não precisem adaptar nada manualmente.

O log de tracking contém: timestamp, endereço IP (relevante para LGPD (PT: RGPD)), URL de destino, HTTP referrer e User-Agent. Para a análise, existe um módulo backend mínimo que mostra contagens de cliques por URL. Análises mais complexas requerem acesso direto ao banco de dados ou exportação.

## Problemas frequentes envolvem SEO, LGPD e compatibilidade com reescrita de URL

Problema um: dano SEO por cadeias de redirect. URLs jumpurl não são URLs de página reais, mas intermediários de redirect. Se o Google indexa um link jumpurl (o que acontece com configuração incorreta), surge uma cadeia de redirect que desperdiça crawl budget e dilui link juice. A solução: garantir que URLs jumpurl tenham tag noindex ou robots disallow.

Problema dois: conformidade com a LGPD. jumpurl armazena endereços IP em texto claro. Sem pseudonimização ou conceito de exclusão, isso é uma violação da LGPD. A tabela do banco de dados deve ser limpa regularmente ou os endereços IP anonimizados antes do armazenamento.

Problema três: compatibilidade com roteamento URL moderno. TYPO3 v12 usa Site Handling e roteamento baseado em Symfony. A arquitetura jumpurl baseada em eID colide em algumas configurações com o novo roteamento e produz erros 404.

## Migração para tracking baseado em eventos é o caminho recomendado em todo upgrade TYPO3

jumpurl não tem suporte oficial para TYPO3 v12 ou v13. Em uma migração, a Gosign recomenda a mudança para tracking de download baseado em eventos. Concretamente: um data-attribute em links de download (p.ex. data-track="download") e um event listener JavaScript que envia cliques ao Matomo, Google Analytics 4 ou um endpoint customizado. Para downloads seguros, a combinação de acesso a arquivo baseado em FAL e um sistema de token é a alternativa moderna.

O esforço de migração depende da quantidade de links jumpurl existentes. Se fontes externas (newsletter, mídia social, impressos) apontam para URLs jumpurl, redirects devem ser configurados. A Gosign analisa os dados de tracking jumpurl existentes, identifica os downloads mais utilizados e configura a nova solução de tracking de forma a garantir comparabilidade histórica.
---

--- k3n_dvemoji TYPO3 - Emoji e UTF-8mb4 | Gosign ---
> k3n_dvemoji: UTF-8mb4 Emoji-Support no TYPO3. Migração de charset e configuração de banco de dados. acelerado com IA.

## Emojis como pontos de interrogação não são um problema de exibição, mas um erro de configuração de banco de dados

Quando no backend TYPO3 um editor insere um emoji e no frontend aparece um ponto de interrogação ou um quadrado vazio, o problema não está no navegador nem no TYPO3. Está no banco de dados MySQL ou MariaDB, configurado com o charset utf8 em vez de utf8mb4. A diferença: utf8 armazena no máximo 3 bytes por caractere, emojis precisam de 4 bytes. k3n_dvemoji é uma extensão TYPO3 que endereça esse problema estendendo a configuração do banco de dados com suporte UTF-8mb4. Desde TYPO3 v10, o Core está preparado para utf8mb4, então a extensão só é necessária em instalações mais antigas ou mal configuradas.

Para administradores TYPO3 e agências que mantêm instalações mais antigas, k3n_dvemoji é uma ferramenta de diagnóstico e correção ao mesmo tempo. A extensão identifica tabelas com charset incorreto e as converte.

## Cenários típicos de uso envolvem instalações antigas, migrações e conteúdo internacional

O cenário mais frequente é uma instalação TYPO3 v8 ou v9 que roda há anos e cujo banco de dados ainda está configurado como utf8 (não utf8mb4). Estimadamente 30% de todas as instalações TYPO3 configuradas antes de 2018 têm esse problema, porque a rotina de instalação na época definia utf8 como padrão. Enquanto editores usam apenas caracteres latinos, não se percebe. Assim que um post de mídia social com emoji é incorporado no site ou um editor coloca um emoji em um título, a exibição quebra.

Segundo cenário: migrações de banco de dados entre servidores. Na mudança de um banco TYPO3 de um servidor antigo para um novo, o charset pode se perder por um comando mysqldump incorreto. Um dump com --default-character-set=utf8 em vez de utf8mb4 corta todos os caracteres de 4 bytes.

Terceiro cenário: sites internacionais com idiomas asiáticos. Caracteres chineses, japoneses e coreanos necessitam parcialmente de 4 bytes. Sem utf8mb4, caracteres individuais são exibidos de forma corrompida, o que em páginas de conteúdo CJK leva a texto ilegível.

## Arquitetura técnica analisa e converte tabelas do banco de dados no nível de coluna

k3n_dvemoji trabalha em dois níveis: análise e conversão. No modo de análise, a extensão escaneia todas as tabelas TYPO3 e verifica o charset de cada coluna. O resultado é um relatório que mostra quais tabelas e colunas ainda estão em utf8 (3 bytes) em vez de utf8mb4 (4 bytes). Um sistema TYPO3 típico tem 100 a 300 tabelas, das quais frequentemente 20 a 50 têm charset incorreto.

No modo de conversão, a extensão gera ALTER TABLE statements para cada coluna afetada e os executa. Isso parece trivial, mas tem armadilhas: índices em colunas varchar com utf8mb4 podem exceder o comprimento máximo de índice do MySQL (767 bytes no InnoDB com formato antigo). A extensão verifica esses limites e adapta as definições de índice.

Adicionalmente, a configuração TYPO3 em LocalConfiguration.php deve declarar o charset utf8mb4: `['DB']['Connections']['Default']['charset'] = 'utf8mb4'` e `['DB']['Connections']['Default']['tableoptions']['collate'] = 'utf8mb4_unicode_ci'`.

## Problemas frequentes são restrições de comprimento de índice, erros de backup e colunas inconsistentes

Problema um: restrição de comprimento de índice MySQL. No InnoDB com formato Compact antigo (padrão até MySQL 5.6), o comprimento máximo de índice é 767 bytes. Um varchar(255) com utf8mb4 precisa de 1.020 bytes de espaço de índice. A conversão falha com "Specified key was too long". A solução: mudar ROW_FORMAT para DYNAMIC (padrão a partir do MySQL 5.7) ou reduzir o comprimento varchar nas colunas afetadas.

Problema dois: backup antes da conversão. Um ALTER TABLE em tabelas grandes (100.000+ linhas) trava a tabela e pode causar indisponibilidade em bancos de produção. A solução: realizar a conversão fora do horário comercial e criar um backup completo antes. Para tabelas grandes, recomenda-se pt-online-schema-change da Percona para conversão sem lock.

Problema três: colunas inconsistentes após conversão parcial. Se apenas partes do banco foram convertidas, JOINs entre colunas utf8 e utf8mb4 podem causar problemas de performance porque MySQL faz uma conversão de charset implícita. A Gosign verifica após cada conversão todas as tabelas quanto à consistência.

## A partir do TYPO3 v10, a extensão é desnecessária se o banco de dados estiver corretamente configurado

TYPO3 v10 e todas as versões seguintes esperam utf8mb4 como charset padrão. Em uma nova instalação com v10 ou superior, o banco de dados é automaticamente configurado corretamente e k3n_dvemoji não é necessário. A extensão permanece relevante para instalações migradas de v7, v8 ou v9 para v12 ou v13 cujo banco nunca foi convertido. A Gosign resolve isso no âmbito de cada migração TYPO3 automaticamente: scan de banco assistido por IA, conversão completa e verificação de consistência como parte do processo padrão de upgrade.
---

--- ke_search Premium TYPO3 - Suche | Gosign ---
> Versão premium do ke_search: autocompletar, indexação de arquivos (PDF, DOCX), indexador personalizado.

## Busca enterprise sem servidor Solr é possível com ke_search Premium no TYPO3

A busca interna de um site é a funcionalidade mais usada e menos mantida. Visitantes esperam autocomplete, tolerância a erros de digitação e a capacidade de pesquisar não apenas páginas, mas também PDFs e documentos Office. ke_search Premium entrega exatamente isso para TYPO3, sem que um servidor Solr ou Elasticsearch externo precise ser operado. Todos os dados ficam no banco de dados TYPO3, o índice é atualizado pelo Scheduler, e a administração permanece no backend TYPO3.

Para sites de médio porte com 500 a 5.000 páginas e alguns downloads de arquivo, ke_search Premium é a solução de busca mais econômica no ecossistema TYPO3. Somente a partir de mais de 10.000 documentos indexados ou com requisitos de tempo de resposta sub-segundo o Solr se torna a melhor escolha.

## Cenários típicos de uso vão de sites corporativos a portais de conhecimento

O cenário padrão é o site corporativo com catálogo de produtos, revista, FAQ e área de downloads. Visitantes buscam por nomes de produto, termos técnicos ou documentos e esperam resultados de todas as áreas em uma única lista de resultados. ke_search Premium indexa conteúdos de página, artigos de notícias, downloads (PDF, DOCX, XLSX) e registros customizados como produtos ou perfis de funcionários. A função autocomplete mostra sugestões já durante a digitação e reduz a taxa de abandono de busca em estimados 15 a 25%.

Segundo cenário: portais de conhecimento e coleções de documentos. Universidades, associações e instituições públicas frequentemente disponibilizam centenas de PDFs para download. Sem indexação de arquivos, a busca TYPO3 pesquisa apenas os textos das páginas, não o conteúdo dos PDFs. ke_search Premium extrai o texto de PDF, DOCX e outros formatos e o torna pesquisável.

Terceiro cenário: indexadores customizados para sistemas de terceiros. Empresas com PIM, DAM ou catálogo de produtos externo podem integrar fontes de dados arbitrárias no índice de busca via a API de indexador customizado.

## Arquitetura técnica usa o banco de dados TYPO3 como índice de busca

ke_search armazena o índice em uma tabela dedicada (tx_kesearch_index) no banco de dados TYPO3. Cada entrada de índice contém título, conteúdo, tags, tipo e informações de ordenação. A indexação roda via tarefas Scheduler em intervalos configuráveis (típico: noturno). A versão Premium estende o indexador base com indexação de arquivos, autocomplete e indexador customizado.

A indexação de arquivos usa Apache Tika ou pdftotext para extração de texto de PDFs e catdoc para documentos Office. Essas ferramentas devem estar instaladas no servidor, o que em ambientes de hosting compartilhado pode ser um problema. Em servidores dedicados e containers Docker, a instalação é trivial.

A consulta de busca no frontend funciona via busca LIKE no banco de dados com índice fulltext opcional. Para volumes menores de dados, a performance é suficiente; para índices maiores (5.000+ entradas), recomenda-se um índice fulltext MySQL nas colunas relevantes para manter o tempo de busca abaixo de 200ms.

Autocomplete é realizado via endpoint AJAX que a cada tecla pressionada executa uma busca PREFIX no índice. Os resultados são entregues como JSON e exibidos no frontend via JavaScript como dropdown.

## Problemas frequentes envolvem tempo de indexação, instalação de Tika ausente e ordenação por relevância

Problema um: tempos longos de indexação em grandes volumes de dados. Um site com 3.000 páginas e 500 PDFs pode levar 30 a 60 minutos para uma reindexação completa. A solução: ativar indexação incremental que reindexia apenas conteúdos alterados.

Problema dois: instalação de Tika ou pdftotext ausente. Sem essas ferramentas, a indexação de arquivos falha silenciosamente, sem mensagem de erro. Editores carregam PDFs que nunca chegam ao índice de busca. A solução: após a instalação, iniciar uma execução de indexação de teste e verificar se conteúdos PDF aparecem no índice.

Problema três: ordenação por relevância. A ordenação padrão é baseada em um algoritmo de scoring simples que pondera resultados em títulos mais que resultados no body. Para requisitos complexos (boosting por atualidade, por tipo de página ou por campos customizados), o scoring deve ser adaptado via TypoScript.

## TYPO3 v12 é completamente suportado, compatibilidade v13 está em desenvolvimento

ke_search é mantida por uma equipe dedicada de desenvolvedores e está disponível de forma compatível prontamente a cada release LTS TYPO3. A versão Premium atual suporta TYPO3 v11 e v12. Para v13, a compatibilidade está em desenvolvimento. A Gosign utiliza ke_search Premium em projetos TYPO3 que precisam de busca interna mas não justificam a operação de um servidor Solr.
---

--- Kleinanzeigen TYPO3 - Classifieds | Gosign ---
> Funcionalidade de classificados para TYPO3: Publicar anúncios, categorias, busca, self-service do usuário. Recurso de comunidade para portais.

## Classificados no próprio site são uma alternativa a plataformas de marketplace

Associações, portais regionais e sites de comunidade às vezes precisam de uma função de classificados: membros publicam itens usados, vizinhos oferecem serviços, organizações intermediam doações de objetos. A extensão kleinanzeigen traz essa funcionalidade diretamente ao TYPO3, sem recorrer a plataformas externas. Usuários criam anúncios no frontend, outros usuários os encontram via categorias e busca, e a redação mantém controle sobre aprovação e moderação.

O caso de uso é delimitado: quem precisa de uma plataforma de marketplace completa com função de pagamento, sistema de avaliação e proteção ao comprador, está melhor servido com uma solução especializada. Para portais comunitários com 50 a 500 anúncios ativos simultaneamente, a extensão é uma ferramenta sólida que mantém os usuários na própria plataforma.

## Cenários típicos de uso são portais de associações, plataformas regionais e bolsas internas

O cenário mais frequente é o portal de associação. Um clube esportivo, uma comunidade religiosa ou uma iniciativa cidadã oferece a membros a possibilidade de vender, doar ou trocar itens usados. A função de classificados é um recurso comunitário que traz visitantes regularmente de volta ao site.

Segundo cenário: plataformas regionais e portais municipais. Um site municipal ou portal de notícias local oferece uma seção de classificados para a região. Cidadãos anunciam apartamentos para alugar, ofertas de babysitter ou serviços de profissionais.

Terceiro cenário: bolsas internas em empresas ou universidades. Na intranet, funcionários oferecem móveis de escritório, bicicletas ou apartamentos para sublocação. Universidades usam o recurso também para bolsas de livros onde estudantes vendem ou trocam literatura especializada entre si.

## Arquitetura técnica utiliza registros Extbase com entrada pelo frontend

A extensão usa o framework Extbase/Fluid do TYPO3. Anúncios são armazenados como registros de domínio próprios em uma tabela dedicada. Cada registro contém título, descrição, preço (opcional), categoria, dados de contato e imagens.

No frontend, estão disponíveis três plugins: uma visualização em lista com filtro e busca, uma visualização de detalhe para anúncios individuais e um formulário de entrada para novos anúncios. O formulário de entrada requer login de frontend (fe_users), para que apenas usuários registrados possam criar anúncios. Imagens são carregadas via FAL e validadas server-side quanto a tamanho e tipo de arquivo.

A moderação ocorre via flag de aprovação no backend: novos anúncios são invisíveis por padrão até que um editor os libere. Alternativamente, a aprovação automática pode ser ativada, o que para comunidades confiáveis pode ser sensato.

## Problemas frequentes são spam, otimização de imagem e gestão de expiração

Problema um: anúncios de spam. Todo formulário de entrada público atrai spam. Sem mecanismos de proteção, o acervo de anúncios se enche em semanas com entradas irrelevantes. A solução: obrigatoriedade de login frontend, campos honeypot no formulário, CAPTCHA opcional e moderação com aprovação.

Problema dois: otimização de imagens. Usuários carregam fotos diretamente do smartphone, frequentemente com 4 a 8 MB por imagem. Sem compressão e redimensionamento server-side, a página fica lenta e o espaço de armazenamento escasso. A solução: definir tamanho máximo de imagem na configuração da extensão (recomendado: 1.200px de largura, 80% de qualidade JPEG).

Problema três: gestão de expiração. Anúncios desatualizados que estão online há meses tornam o acervo inutilizável. A solução: uma data de expiração automática (recomendado: 30 a 90 dias) e um e-mail de lembrete ao criador antes do anúncio ser arquivado.

## A extensão não tem suporte garantido para versões TYPO3 atuais

kleinanzeigen foi desenvolvida para versões TYPO3 mais antigas e não tem suporte oficial para v12 ou v13. Em uma migração, surge a questão se a extensão é adaptada ou substituída por uma solução sob medida. Para portais com acervo ativo de classificados, a Gosign recomenda um redesenvolvimento com base na API Extbase atual que migra os dados existentes e adapta a funcionalidade aos requisitos específicos do portal. O esforço é tipicamente de 5 a 10 dias de trabalho para funcionalidade básica com visualização em lista, detalhe, entrada pelo frontend e moderação.
---

--- Mailchimp Signup TYPO3 | Gosign ---
> Mailchimp-Anmeldeformular para TYPO3. Sincronização de assinantes, Double-Opt-In, segmentos de audiência. LGPD: observar processamento de dados nos EUA,.

## Formulários de inscrição Mailchimp no TYPO3 requerem proteção LGPD, não apenas um plugin

Inscrições em newsletter estão entre os objetivos de conversão mais importantes em sites corporativos. koning_mailchimp_signup conecta formulários frontend TYPO3 diretamente com a API Mailchimp: um visitante insere seu e-mail, a extensão o transfere para a Audience Mailchimp configurada, o Mailchimp envia o e-mail de double opt-in. Tecnicamente, funciona em 15 minutos. O verdadeiro desafio não está na técnica, mas na LGPD: Mailchimp processa dados pessoais em servidores nos EUA, o que requer um contrato de processamento de dados e um mecanismo de transferência documentado.

Para equipes de marketing que já usam Mailchimp como plataforma de newsletter e querem conectar seu site TYPO3, a extensão é o caminho mais curto. Quem ainda não escolheu uma plataforma deve avaliar alternativas europeias como Brevo, rapidmail ou mailingwork.

## Cenários típicos de uso são newsletter de blog, iscas digitais e inscrições em eventos

O cenário padrão é o newsletter de blog ou revista. Abaixo de cada artigo aparece um formulário compacto de inscrição com campo de e-mail e checkbox de consentimento. A extensão transfere o endereço para uma Audience Mailchimp e tageia o assinante com a origem (p.ex. "blog-sidebar" ou "article-footer"). Marketing pode assim enviar de forma segmentada.

Segundo cenário: iscas digitais com download automático. Um visitante se inscreve e recebe automaticamente um whitepaper, um checklist ou um código de desconto via Mailchimp Welcome Automation. A extensão entrega o assinante, Mailchimp cuida da automação.

Terceiro cenário: inscrições em eventos. Uma empresa convida para um webinar ou conferência. A inscrição roda por um formulário expandido com nome, e-mail e empresa. A extensão transfere os dados para uma Audience Mailchimp dedicada, configurada para comunicação de eventos.

## Arquitetura técnica conecta formulário Fluid com a API Mailchimp v3

A extensão registra um elemento de conteúdo no TYPO3 que renderiza um formulário de inscrição. O formulário contém no mínimo um campo de e-mail e uma checkbox de consentimento. Campos opcionais como nome, sobrenome e empresa podem ser ativados pela configuração no backend. Os templates Fluid podem ser sobrescritos pelo site package.

Após o envio, a extensão manda um POST request à API Mailchimp v3. A API Key e o Audience ID são configurados no Extension Manager TYPO3. A extensão suporta tags (para segmentação), Merge Fields (para dados customizados) e o controle do comportamento de double opt-in.

Tratamento de erros: quando a API Mailchimp retorna um erro (já inscrito, e-mail inválido, rate limit), a extensão exibe uma mensagem de erro configurável no frontend. Os erros são adicionalmente escritos no log TYPO3.

## Problemas frequentes envolvem documentação LGPD, double opt-in e estilo de formulário

Problema um: documentação LGPD ausente. A extensão transfere dados pessoais a um provedor de serviço americano. Sem contrato de processamento de dados com Mailchimp, documentação do mecanismo de transferência na política de privacidade e checkbox de consentimento no formulário, a integração é ilegal. No Brasil, a LGPD impõe requisitos similares para transferências internacionais de dados.

Problema dois: configuração de double opt-in. Mailchimp permite adicionar assinantes diretamente à lista sem e-mail de confirmação (single opt-in). Na legislação brasileira, isso pode ser problemático. A extensão deve ser configurada para que Mailchimp envie um e-mail de confirmação e ative o assinante somente após clicar no link de confirmação.

Problema três: estilo do formulário não combina com o design corporativo. A extensão traz estilos padrão mínimos que na maioria dos projetos não combinam com o design. A solução: sobrescrever o template Fluid no site package e adaptar as classes CSS ao sistema de design existente.

## A extensão funciona com TYPO3 v12, para v13 a API Mailchimp é o caminho mais estável

koning_mailchimp_signup suporta TYPO3 v11 e v12. Para TYPO3 v13, a disponibilidade depende do mantenedor comunitário. Como a API Mailchimp v3 é estável e muda raramente, uma integração direta de API sem extensão é a alternativa com menos manutenção para projetos v13. A Gosign implementa em novos projetos preferencialmente um Finisher customizado para o TYPO3 Form Framework ou powermail que acessa diretamente a API Mailchimp. Isso elimina a dependência da extensão e dá controle total sobre tratamento de erros, logging e documentação LGPD.
---

--- kuferweb TYPO3 - Gerenciamento de cursos Kufer | Gosign ---
> kuferweb: Kufer-Kursverwaltung no TYPO3 integrieren. Catálogo de cursos, inscrição, sincronização. acelerado com IA.

## kuferweb é a ponte entre o sistema especializado Kufer e o site público em TYPO3

Escolas de educação de adultos, instituições educacionais e academias administram seus cursos há décadas em software especializado, e em muitas casas esse software se chama Kufer. O Kufer representa todo o ciclo de vida do curso: gestão de docentes, planejamento de curso, ocupação de sala, participantes, faturamento, certificados. Para o site isso significa uma tarefa padrão: o catálogo de cursos mantido no back-office precisa estar visível no site TYPO3 atualizado diariamente, incluindo busca com filtros, visões de detalhe e inscrição online.

O público-alvo é claramente delimitado: instituições de formação continuada com um mandante Kufer existente e site em TYPO3. Típica é uma escola com cerca de 2.500 cursos por semestre e meia dúzia de docentes que mantêm seus cursos no Kufer. Sem integração limpa, o catálogo do site fica desatualizado, a manutenção dupla vira estado permanente, e inscrições pousam em um sistema separado que ninguém gosta.

## Cenários típicos de uso

Um primeiro cenário é o catálogo de cursos atualizado automaticamente. Uma escola com 2.500 cursos por semestre quer que cada criação de curso, cada mudança de preço e cada troca de docente fique visível no site sem intervenção manual. Um sync job a cada hora puxa os dados atuais de curso do Kufer, grava em uma tabela TYPO3 e atualiza a busca. O redator não mantém mais cursos no backend TYPO3.

Um segundo cenário é a inscrição online direta. Uma instituição de formação com programas de fomento quer levar interessados da página de detalhe do curso a um processo de inscrição que no background chama a API do Kufer e registra o participante no Kufer. O TYPO3 serve como frontend, o Kufer permanece a fonte da verdade, a redação vê o novo status de inscrição na interface familiar.

Um terceiro cenário é a busca por filtros com facetas específicas. Uma academia com 40 áreas temáticas e vários milhares de cursos quer permitir aos interessados buscar por categorias, locais, datas, docentes e classes de preço. A busca roda na página TYPO3 contra um índice local construído a partir do export do Kufer, performático e independente da disponibilidade da aplicação de negócio.

Um quarto cenário é a saída multilíngue de cursos. Uma escola de idiomas com unidades em São Paulo, Rio de Janeiro e Belo Horizonte mantém cursos no Kufer apenas em português e quer oferecer no site uma apresentação multilíngue para interessados estrangeiros. A integração assume o mapeamento para variantes de idioma TYPO3, complementa os campos em português do Kufer com traduções manuais na redação do CMS e garante que mudanças no Kufer não sobrescrevam as traduções locais.

## Arquitetura técnica

Integrações kuferweb em TYPO3 são quase sempre desenvolvimento custom, porque as estruturas de dados variam por mandante Kufer e as versões de API mudaram várias vezes ao longo dos anos. A abordagem padrão é uma extensão Extbase enxuta com três pilares: uma service layer que encapsula a API do Kufer, uma persistence layer que espelha cursos em tabelas TYPO3 e uma presentation layer que entrega templates Fluid para lista, filtro e detalhe.

A sincronização roda via tarefa do scheduler TYPO3. Para catálogos grandes, recomenda-se um import delta que transfere apenas os cursos alterados desde a última execução. A API do Kufer costuma entregar um timestamp ou identificador de alteração por curso, usado para a detecção de delta.

A inscrição online exige um caminho adicional de API e tratamento limpo de erros. A API do Kufer pode responder lentamente sob alta carga, por isso inscrições costumam rodar de forma assíncrona: o formulário coloca o request de inscrição em uma fila, um worker o transfere ao Kufer, e o participante recebe um email de confirmação assim que o Kufer confirma o registro.

## Problemas frequentes e soluções

O primeiro problema é a divergência de campos entre mandantes Kufer. O que no mandante A é "Número do evento", no mandante B é "Código do curso" e no mandante C "Número de registro". A solução é um mapeamento de campos configurável na extensão TYPO3, ajustado por instalação e não fixo no código.

O segundo problema é a qualidade dos dados no catálogo. Redatoras nem sempre mantêm textos completos no Kufer, faltam descrições curtas, imagens não estão carregadas, públicos-alvo não estão definidos. No site, essas lacunas aparecem como campos vazios. A solução é uma camada de validação na sincronização que marca cursos incompletos no backend e convoca a redação a complementar.

O terceiro problema é a lógica de cancelamento. Quando cursos são cancelados no Kufer, precisam desaparecer do site ou ser ao menos marcados como cancelados. A solução é definir cursos cancelados explicitamente no sync para um status que fica oculto na lista, e incluir na página de detalhe um redirect para um panorama de categoria.

Um quarto problema é a exibição de ocupação em tempo real. Interessados veem no site "ainda 3 vagas livres" enquanto a reserva já mudou para lista de espera em segundo plano. A solução é não ler a exibição de ocupação do cache de sync, mas fazer em cada abertura da página de detalhe uma chamada ao vivo ao Kufer, com cache agressivo (30 a 60 segundos) e um fallback para o último valor conhecido do cache se a API não responder.

## Migração e compatibilidade de versões

Integrações kuferweb rodam em TYPO3 v11, v12 e v13, desde que a conexão com a API seja construída de forma moderna. O ponto de dor mais frequente não é a versão do TYPO3, mas a versão do Kufer: quando a escola migra seu mandante Kufer para uma versão nova, endpoints e estruturas de dados mudam ocasionalmente, o que exige ajuste da integração TYPO3.

A Gosign constrói integrações kuferweb com base na API Kufer atual, verifica antes do projeto a compatibilidade com o mandante do cliente e monta a integração de forma modular, para que upgrades futuros de API funcionem sem reconstrução em larga escala. Com apoio de IA, o código do cliente API surge em horas em vez de dias, tornando a introdução realista em dois a três sprints na maioria dos projetos.

--- LayerSlider TYPO3 - Migração de slider | Gosign ---
> Premium-Slider/Animations-Plugin para TYPO3. Crítico para performance: Bundles JS grandes, muitas requisições HTTP. A Gosign migra para alternativas leves.

## LayerSlider carrega 400 KB de JavaScript para algo que se resolve com 20 KB de CSS

LayerSlider foi entre 2012 e 2018 um dos sliders premium mais populares para TYPO3 e WordPress. Banners animados com efeitos parallax, inserções de texto, transições e fundos de vídeo. O resultado na página inicial parecia impressionante. O problema: LayerSlider carrega uma biblioteca JavaScript de 300 a 400 KB (minificada), requer jQuery como dependência (mais 90 KB) e gera 15 a 30 requisições HTTP para imagens, fontes e arquivos de configuração. Em um site otimizado, LayerSlider dobra o tempo de carregamento da página inicial.

Google PageSpeed Insights penaliza isso severamente. Um Largest Contentful Paint (LCP) acima de 4 segundos causado apenas pelo slider significa perda de 20 a 40 pontos no score. Desde que o Google usa Core Web Vitals como fator de ranking (2021), um LCP ruim é uma desvantagem mensurável de SEO.

## Cenários típicos de uso

**Sites existentes com hero banners animados.** Sites corporativos dos anos 2014 a 2019, onde o slider da página inicial exibe 3 a 5 slides animados. Conteúdo típico: fotos de produto com texto overlay animado, efeitos parallax de scroll, autoplay com transição fade. O slider foi configurado uma vez e raramente alterado desde então, mas causa todo o overhead de performance a cada carregamento.

**Landing pages com apresentações de produto.** Equipes de marketing usam LayerSlider para apresentações de produto: múltiplas imagens com texto overlay e botões CTA em uma slideshow automática. Dados de conversão mostram tipicamente que 80% dos usuários veem apenas o primeiro slide. O slider é uma representação cara de uma única imagem.

**Páginas de eventos com animações de countdown.** LayerSlider pode exibir timers, pop-ups e animações acionadas por scroll. Para páginas de conferências ou lançamentos de produto, tais recursos eram utilizados. Hoje existem soluções CSS leves para isso sem overhead de JavaScript.

## Arquitetura técnica

LayerSlider é um plugin comercial. A integração TYPO3 funciona como extensão que cria uma tabela própria para configurações de slider. Cada slider consiste em slides, cada slide em camadas (texto, imagem, vídeo, forma, botão), e cada camada tem configurações de animação.

A saída no frontend carrega a biblioteca core LayerSlider, jQuery (se não disponível globalmente), plugins opcionais e a configuração do slider como JSON. O motor de animação usa RequestAnimationFrame e CSS3 Transforms. Em navegadores modernos, a exibição é fluida, mas o tempo de parse do grande bundle JavaScript permanece. Em smartphones de médio porte, o parse sozinho leva 200 a 500 ms antes da primeira animação iniciar.

## Problemas frequentes e soluções

**Core Web Vitals caem após instalação do slider.** LCP sobe de 1,5 para mais de 4 segundos, porque o slider é o maior elemento visível e só pode renderizar após o parse do JavaScript. Solução: substituir LayerSlider por um hero estático com animação CSS. A imagem hero carrega como tag img normal (imediatamente no HTML, sem JavaScript necessário), overlays de texto são posicionados via CSS. Resultado: LCP abaixo de 2 segundos.

**Licença do LayerSlider expira, atualizações faltam.** A variante TYPO3 do LayerSlider não é distribuída pelo TER e não tem mecanismo de atualização automático. LayerSlider teve no passado vulnerabilidades críticas de segurança. Solução: não fazer patch, migrar.

**Conteúdos do slider não são indexáveis.** Texto em camadas LayerSlider é inserido como atributo data ou via JavaScript. O Google pode ler o texto (renderização JavaScript), mas a associação com o contexto da página é fraca. Solução: colocar texto relevante e CTAs diretamente no HTML da página, não no slider.

## Migração e compatibilidade de versões

LayerSlider não tem compatibilidade oficial com TYPO3 v12 ou v13. A última versão compatível com TYPO3 suporta v10, com patches da comunidade parcialmente v11. Para v12+ não existe caminho de upgrade. Isso é para muitos projetos o gatilho para substituir definitivamente o slider.

A Gosign migra LayerSlider para uma de três alternativas: Swiper (open source, 40 KB minificado, sem jQuery, touch-native) para sliders de imagem com transições simples. Splide (open source, 30 KB minificado, sem jQuery, suporte ARIA completo) para sliders acessíveis. Ou um hero puro CSS/HTML sem biblioteca de slider, quando apenas uma imagem com texto overlay é necessária.

A migração leva entre 0,5 e 2 dias por slider. O efeito mensurável: um site que migra de LayerSlider para hero estático com animação CSS melhora tipicamente o Google PageSpeed Score em 15 a 35 pontos. O LCP cai de 3 a 5 segundos para menos de 2 segundos. Para empresas que direcionam tráfego via Google Ads para a página inicial, isso significa diretamente melhores Quality Scores e custos por clique mais baixos.

--- Leaflet TYPO3 - Mapas OpenStreetMap | Gosign ---
> Leaflet Maps no TYPO3: OpenStreetMap ohne Google-Kosten. Localizador de filiais, clustering, rotas. acelerado com IA.

## Mapas OpenStreetMap via Leaflet substituem Google Maps sem custos de licença e risco de privacidade

Google Maps custa a partir de 28.000 carregamentos de mapa por mês e transfere dados de usuários a servidores nos EUA. Para empresas com localizador de filiais, store locator ou mapa de localização no site, esses são dois problemas de uma vez: orçamento e proteção de dados. Leaflet resolve ambos. A biblioteca JavaScript open-source renderiza mapas interativos com base em dados OpenStreetMap, roda completamente client-side e não tem custos de licença. A extensão TYPO3 integra Leaflet como elemento de conteúdo: editores mantêm localizações no backend, a extensão gera o mapa no frontend.

Para empresas com 5 a 500 localizações, Leaflet é a recomendação padrão. Somente quando funcionalidades específicas do Google como Street View, edifícios 3D ou dados de tráfego em tempo real são necessários, o Google Maps é a melhor escolha. Em todos os outros casos, Leaflet entrega a mesma funcionalidade com zero custos de licença e sem discussão de privacidade.

## Cenários típicos de uso são localizadores de filiais, mapas imobiliários e localizações de eventos

O cenário mais frequente é o localizador de filiais ou localizações. Uma empresa com 20 a 200 filiais mostra todas as localizações em um mapa interativo. Usuários podem dar zoom, buscar por CEP e clicar em marcadores para ver endereço, horário de funcionamento e dados de contato. Com distribuição densa de marcadores, clustering agrupa localizações próximas em um marcador coletivo que se dissolve em marcadores individuais ao dar zoom. Um localizador de filiais típico com 100 localizações e clustering carrega em menos de 500ms.

Segundo cenário: mapas imobiliários e de objetos. Corretores, administradoras e construtoras mostram objetos disponíveis em um mapa. Os marcadores contêm informações básicas (preço, número de quartos, área) como popup e linkam para a página de detalhe.

Terceiro cenário: localizações de eventos e turismo. Organizadores, órgãos de turismo e cidades mostram POIs (Points of Interest), rotas e locais de eventos em um mapa. Leaflet suporta além de marcadores de ponto também linhas (para rotas de caminhada) e polígonos (para áreas).

## Arquitetura técnica separa backend de dados e rendering de mapa de forma limpa

A extensão TYPO3 armazena dados de localização como registros Extbase em uma tabela própria. Cada registro contém nome, endereço, coordenadas (latitude/longitude), descrição e campos opcionais como horário de funcionamento, telefone e imagem. As coordenadas podem ser inseridas manualmente ou determinadas automaticamente a partir do endereço via serviço de geocoding.

No frontend, a extensão renderiza um elemento container de mapa e inicializa Leaflet via JavaScript. Os tiles do mapa são carregados de um servidor de tiles configurável. O padrão é OpenStreetMap, mas Mapbox, Stamen e outros provedores de tiles são alternáveis via TypoScript. Os marcadores são passados como array JSON ao JavaScript, o que permanece performante mesmo com mais de 500 localizações.

Clustering é realizado pelo plugin Leaflet.markercluster que agrupa marcadores em níveis de zoom baixos e dissolve ao dar zoom. Os limiares de cluster são configuráveis.

## Problemas frequentes envolvem geocoding, disponibilidade de servidor de tiles e exibição responsiva

Problema um: erros de geocoding em endereços imprecisos. Nem todo endereço é corretamente resolvido pelo serviço de geocoding. Especialmente áreas industriais e endereços em regiões rurais entregam coordenadas imprecisas ou incorretas. A solução: usar geocoding automático como preenchimento inicial e verificar coordenadas manualmente.

Problema dois: disponibilidade do servidor de tiles. O servidor de tiles padrão do OpenStreetMap tem uma política de uso justo e pode aplicar rate limiting em tráfego alto. Para sites produtivos com mais de 50.000 carregamentos de mapa por mês, recomenda-se um servidor de tiles próprio ou provedor comercial como Mapbox ou Maptiler.

Problema três: exibição responsiva em dispositivos móveis. Mapas em telas pequenas são difíceis de usar porque o zoom colide com o scroll da página. A solução: restringir gestos touch no mapa a dois dedos e oferecer um botão "Ampliar mapa" que abre o mapa em modo tela cheia.

## Leaflet é à prova de futuro, a extensão TYPO3 precisa ser verificada na v13

Leaflet como biblioteca JavaScript é independente da versão TYPO3 e é ativamente desenvolvida. A extensão TYPO3 que cuida da integração backend e do rendering precisa ser verificada em um upgrade para v12 ou v13. Na Gosign, migramos integrações Leaflet tipicamente por um plugin customizado no próprio sitepackage que incorpora diretamente a biblioteca Leaflet e obtém dados de localização de uma tabela Extbase ou endpoint JSON. Isso elimina a dependência da extensão e dá controle total sobre atualizações.
---

--- LimeSurvey TYPO3 - Integração de pesquisas | Gosign ---
> LimeSurvey no TYPO3: Umfragen einbetten, SSO-Anbindung, Ergebnis-Dashboard. acelerada com IA Integração.

## LimeSurvey é a resposta compatível com a LGPD para pesquisas corporativas que não podem acabar no Google Forms

Quem conduz pesquisas profissionais no Brasil, pesquisas com colaboradores, pesquisa de mercado, estudos de avaliação, levantamentos científicos, e precisa ao mesmo tempo de conformidade com a LGPD, soberania de dados plena e uma trilha de auditoria limpa, acaba quase inevitavelmente passando pelo LimeSurvey. O software open source roda no servidor próprio, armazena dados de resposta exclusivamente no próprio banco e oferece todos os tipos de questão que pesquisa séria exige. Para operadores TYPO3, a pergunta não é se usam LimeSurvey, mas como o integram em seu site existente.

O público-alvo são tipicamente universidades, instituições de pesquisa, administrações públicas, hospitais, conglomerados com representações sindicais e ONGs com pesquisa em público-alvo sensível. Um exemplo: uma universidade brasileira com 18.000 estudantes realiza a cada semestre uma avaliação docente e quer retornar os resultados no próprio site TYPO3 sem que os estudantes precisem trocar de sistema.

## Cenários típicos de uso

Um primeiro cenário é a participação sem emendas na página TYPO3. Em vez de mandar os estudantes a um domínio LimeSurvey separado, o questionário é exibido diretamente na página do site. As respostas fluem via API ao LimeSurvey, os estudantes veem a navegação familiar do site. Isso reduz significativamente a taxa de abandono.

Um segundo cenário é a identificação de participantes via SSO. Uma rede hospitalar brasileira com 8.000 colaboradores realiza uma pesquisa interna. Os participantes fazem login no intranet TYPO3, clicam no link da pesquisa e chegam ao LimeSurvey sem precisar autenticar novamente. A ponte SSO garante que cada colaborador participe só uma vez e que os dados pessoais do TYPO3 não cheguem às respostas da pesquisa.

Um terceiro cenário é a exibição de resultados diretamente no site. Uma administração municipal realiza uma pesquisa aos cidadãos sobre um projeto urbanístico e quer mostrar os estados parciais diariamente como gráfico de barras na página do projeto. Um sync job puxa os agregados anonimizados via API e os renderiza em um content element TYPO3, sem que dados brutos toquem a instalação TYPO3.

Um quarto cenário é o estudo longitudinal em pesquisa. Um projeto de pesquisa sobre carga de trabalho na enfermagem entrevista a mesma coorte quatro vezes por ano ao longo de dois anos. A página TYPO3 serve como ponto de informação e entrada, o LimeSurvey mantém os levantamentos, e a integração garante que cada participante alcance suas pesquisas subsequentes via link personalizado, sem que os pesquisadores mantenham dados de contato no LimeSurvey.

## Arquitetura técnica

O LimeSurvey disponibiliza dois acessos de API: a clássica interface RemoteControl2 baseada em JSON-RPC e a mais nova API REST em versões atuais. Para integrações TYPO3, o RemoteControl2 continua sendo a âncora de estabilidade, porque está disponível em instalações LimeSurvey mais antigas e cobre autenticação completa, gerenciamento de participantes e consultas de resposta.

A integração TYPO3 roda em regra como uma extensão própria. Uma service layer encapsula as chamadas da API, um plugin entrega content elements para incorporar pesquisas e uma middleware implementa a lógica de SSO. Para a incorporação existem duas variantes: a pesquisa é chamada via token assinado e embutida via iFrame, ou as perguntas são lidas via API e renderizadas diretamente como template Fluid. A segunda variante oferece a melhor experiência de uso, mas exige mais esforço de desenvolvimento.

A ponte SSO se baseia em um token assinado que o TYPO3 gera e o LimeSurvey valida. No LimeSurvey é configurado um plugin que lê tokens do URL e cria o participante como token anônimo na tabela de participantes da pesquisa. É importante que o token seja limitado no tempo e válido apenas uma vez por participante.

## Problemas frequentes e soluções

O primeiro problema é o tratamento de sessão entre TYPO3 e LimeSurvey. Os dois sistemas têm sessões próprias, e quando a abordagem iFrame é escolhida, surgem problemas com cookies de terceiros em navegadores modernos. A solução é operar o LimeSurvey em um subdomínio da instalação TYPO3, para que os cookies sejam aceitos como first party, ou usar a variante API com renderização no servidor.

O segundo problema é a crise de performance na exibição de resultados. Quem consulta a API por agregados a cada carregamento de página sobrecarrega o servidor LimeSurvey. A solução é um sync job que grava agregados em intervalos regulares (por exemplo a cada hora) em uma tabela TYPO3 e renderiza o content element a partir dessa tabela de cache.

O terceiro problema é o tratamento de dados pessoais conforme a LGPD. Em pesquisas com colaboradores, o empregador geralmente não pode identificar quem deu qual resposta. A solução é um conceito de separação limpo: o TYPO3 só disponibiliza tokens anonimizados, o LimeSurvey grava respostas sem referência, e a agregação só usa indicadores que não permitem conclusões sobre indivíduos.

Um quarto problema são deficiências de apresentação mobile no modo iFrame. Pesquisas LimeSurvey são responsivas, mas em um iFrame TYPO3 surgem barras de rolagem duplas e botões cortados em telas pequenas. A solução é mudar em uso móvel para renderização no servidor ou ajustar o iFrame dinamicamente ao conteúdo, para que o container de layout da página assuma a altura total.

## Migração e compatibilidade de versões

Integrações LimeSurvey rodam em TYPO3 v11, v12 e v13. O desafio maior está no lado LimeSurvey: entre LimeSurvey 3.x, 5.x e 6.x, detalhes de API e métodos de autenticação mudaram. Quem leva uma integração existente para uma nova versão do LimeSurvey deve verificar as chamadas de API contra a documentação da versão correspondente e, idealmente, rodar um teste de integração automatizado contra uma instância de staging.

A Gosign implementa integrações LimeSurvey para universidades, hospitais e operadores públicos. O cliente API é gerado com apoio de IA a partir da documentação do RemoteControl2, a ponte SSO é adaptada individualmente à gestão de identidade existente, e a implementação acontece ao longo de uma documentação clara de conformidade com a LGPD que poupa trabalho do encarregado de proteção de dados.

--- linkhandler TYPO3 - Links de registros personalizados | Gosign ---
> linkhandler: Links de registros personalizados no TYPO3 RTE. Vincular notícias, eventos, produtos diretamente. Configuração e migração.

## linkhandler evita links quebrados quando URLs mudam

No TYPO3, uma indicação Typolink se refere diretamente a uma página, um arquivo ou uma URL, não a um registro. Assim que uma redação quer linkar no texto corrido para eventos, artigos de news, produtos ou endereços, ou precisa inserir a URL fixa, ou ligar uma extensão intermediária que gera uma URL estável a partir de um ID de registro. Essa é exatamente a tarefa do linkhandler. A extensão da Cobwebsters registra novos tipos de link no RTE do TYPO3 e no Link Browser e os conecta a quaisquer tabelas de banco. Em um projeto editorial com mais de cem referências internas, essa é a diferença entre uma arquitetura de conteúdo funcional e uma página cemitério cheia de links 404.

## Cenários típicos ocorrem em toda redação com mais de um domínio de conteúdo

Assim que news, eventos e produtos coexistem em um mesmo projeto, os redatores precisam de um sistema de linking limpo. Uma universidade brasileira linka no artigo da revista para o evento em sf_event_mgt, no texto do evento para o autor envolvido de md_news_author e, no perfil do autor, de volta para todos os seus artigos em GeorgRinger/news. Três extensões, três tipos de registro, e sem linkhandler cada uma dessas referências seria uma URL fixa que quebraria no próximo refactoring de slug. No cotidiano, isso significa: um único refactoring de URL pode gerar dezenas ou centenas de broken links, que só aparecem semanas depois no relatório do Google Search Console.

Um segundo cenário são textos de e-commerce: descrições de produto que apontam para acessórios, ou artigos de blog que linkam para produtos do aimeos. O linkhandler gera os URLs automaticamente a partir da configuração de routing do produto, e em um refactoring de categoria todos os links migram junto.

Em terceiro, a necessidade aparece em listagens de localizações. Quem mantém uma estrutura de filiais ou diretórios de contatos com tt_address ou um model próprio quer, a partir de artigos, linkar para a página de detalhe correspondente. O link linkhandler permanece estável mesmo quando a localização é renomeada.

## Arquitetura técnica registra link types via YAML e classe handler

O linkhandler usa o mecanismo LinkHandler do core TYPO3, disponível desde a v8. Cada link type é registrado via arquivo YAML no diretório de configuração. O YAML define o identificador do handler, a tabela, o model Extbase e a configuração de routing. No RTE e no Link Browser, o link type aparece como nova aba: "News", "Evento", "Produto", "Endereço". Cada aba mostra uma lista dos registros disponíveis com função de busca e filtro, para que redatores, mesmo com milhares de entradas de news, encontrem o registro desejado de forma direcionada.

O resolver propriamente dito é uma classe PHP que herda de AbstractLinkHandler e implementa os métodos modifyLinkField e generateRelativeUrl. Os métodos geram a partir do ID do registro uma URL amigável, via site config e router da extensão correspondente. No frontend, o Typolink é chamado com o parâmetro t3://record e resolvido pelo page rendering para a URL final. Isso significa: mesmo que dezenas de milhares de artigos linkem para o mesmo registro de news, em uma mudança de slug basta atualizar o próprio registro do artigo, todos os links se resolvem automaticamente para a nova URL.

A configuração penetra fundo no sistema de linking do TYPO3, mas permanece declarativa: após o registro YAML e o clear cache, o novo link type fica disponível no projeto inteiro, inclusive templates Fluid e componentes de menu. Quem não usa o linkhandler explicitamente também obtém o mecanismo via core linking do TYPO3, mas sem a camada de abstração YAML e sem o UI confortável de picker de registro no backend da extensão.

## Problemas frequentes envolvem cache, variantes de idioma e file handlers

O tema de suporte mais frequente são inconsistências de cache após o update de um registro. Quando o slug de um artigo news é ajustado, o page cache do artigo de origem, no qual está o link linkhandler, também precisa ser limpo, caso contrário a URL antiga permanece na saída. A solução é uma cache tag definida junto com o rendering do Typolink. Muitas instalações não ativam isso e depois lutam contra links supostamente quebrados.

O segundo problema são variantes de idioma. Um artigo news em BR aponta via linkhandler para um evento. A tradução em inglês do artigo precisa apontar para o mesmo ID de evento, mas gerar a URL no idioma inglês. O linkhandler oferece essa resolução via Language Aspect, mas a configuração YAML precisa apontar explicitamente para as variantes de routing das páginas-alvo. Quem usa fallback de idioma precisa verificar adicionalmente como o handler se comporta em traduções ausentes, ele deve resolver no idioma de fallback, não cair de volta no idioma principal.

Em terceiro, o file handler é um caso especial. Quem, além de links de registro, também quer linkar para arquivos FAL do TYPO3, precisa configurar o linkhandler file handler separadamente ou recorrer ao File Linker nativo do TYPO3. A combinação é possível, mas a ordem dos handlers no YAML decide qual aba aparece primeiro.

## TYPO3 v12 e v13 usam o LinkHandler do core, migração vale a pena

A partir do TYPO3 v11, o LinkHandler do core está pronto para produção e pode assumir muitas tarefas do linkhandler. Ainda assim, a extensão da Cobwebsters continua sendo mantida, porque traz recursos extras de conforto como o editor YAML, o picker de registro aprimorado e saída compatível com schema. Para TYPO3 v12 e v13, existe uma versão atual no TER e no Packagist.

Na revisão de migração, a Gosign verifica quantas chamadas linkhandler estão nos conteúdos do RTE. Com menos de 50 ocorrências, frequentemente vale a pena migrar para o LinkHandler do core; com mais de 100 ocorrências ou handlers muito customizados, o linkhandler continua sendo a escolha mais pragmática. A migração para uma nova major version costuma rodar sem alterações de conteúdo, porque a sintaxe t3://record no conteúdo permanece estável. Para a análise, usamos um scan sobre os campos tt_content que discrimina todos os tipos de link e gera uma recomendação por instalação.

--- Liveticker TYPO3 - Atualizações em tempo real | Gosign ---
> Live ticker para eventos em tempo real: esportes, eleições, conferências. Baseado em WebSocket ou polling, com carregamento automático de novas entradas.

## Atualizações em tempo real em sites TYPO3 exigem mais que um plugin de notícias com auto-refresh

Clubes esportivos, portais de notícias, municípios em noites eleitorais e organizadores de conferências precisam de uma funcionalidade que não existe assim no Core TYPO3: mensagens curtas cronológicas que aparecem em tempo real na página sem que o visitante precise recarregar. A extensão liveticker resolve isso com um plugin frontend que pode recarregar novas entradas automaticamente via AJAX polling ou WebSocket e inseri-las no topo da timeline. Editores digitam uma mensagem no backend, clicam em "Salvar", e a mensagem aparece segundos depois no site.

Para organizações que acompanham eventos ao vivo duas a três vezes por ano em seu site, a extensão é uma solução pragmática. Quem ticka ao vivo diariamente deve avaliar plataformas especializadas como Tickaroo, que cobrem melhor conteúdo multimídia, integração com mídia social e workflows multi-autor.

## Cenários típicos de uso são eventos esportivos, eleições municipais e conferências

O cenário mais frequente é o liveticker esportivo. Um clube esportivo amador acompanha jogos em casa com um ticker no site do clube. Um editor à beira do campo digita gols, cartões e substituições no backend TYPO3, e as entradas aparecem cronologicamente na página. Em um jogo de futebol regional com 500 a 2.000 visitantes simultâneos, o ticker deve rodar de forma estável sem sobrecarregar o servidor.

Segundo cenário: noites eleitorais em municípios. No domingo de eleição, prefeituras publicam resultados parciais via liveticker. As mensagens contêm percentuais de votos, projeções e comentários. O desafio: todos os visitantes esperam o mesmo resultado ao mesmo tempo, gerando pico de tráfego.

Terceiro cenário: conferências e assembleias de membros. Associações e clubes tickam assembleias gerais ao vivo para que membros que não estão presentes possam acompanhar. As entradas contêm resultados de votação, contribuições de palestrantes e decisões.

## Arquitetura técnica utiliza registros TYPO3 com AJAX polling no frontend

A extensão armazena entradas de ticker como registros TYPO3 em uma tabela própria. Cada entrada contém timestamp, texto, imagem opcional e categorização. Os registros pertencem a um container ticker atribuído a um evento.

No frontend, o plugin renderiza as entradas existentes como lista cronológica (mais recentes primeiro) e inicia um timer JavaScript que em intervalos configuráveis (típico: 10 a 30 segundos) envia um request AJAX a um endpoint TYPO3. O endpoint entrega todas as entradas adicionadas desde a última consulta. O JavaScript insere essas entradas com animação no topo da lista.

Implementações avançadas usam WebSockets em vez de polling, reduzindo a latência de 10 a 30 segundos para menos de 1 segundo. Isso requer um servidor WebSocket (p.ex. Node.js com Socket.io) rodando em paralelo ao servidor web TYPO3. Para a maioria dos sites de clubes e municípios, AJAX polling com intervalo de 15 segundos entrega uma experiência suficientemente próxima do tempo real.

## Problemas frequentes são carga de servidor em pico de tráfego, entrada mobile ausente e conflitos de cache

Problema um: carga de servidor em pico de tráfego. Quando 2.000 visitantes enviam um request AJAX a cada 15 segundos, são 8.000 requests por minuto. Sem estratégia de cache, um servidor de hosting compartilhado simples colapsa. A solução: colocar um reverse proxy (p.ex. Varnish ou Cloudflare) na frente do endpoint AJAX que cacheia a resposta por 5 segundos.

Problema dois: entrada mobile para editores. O backend TYPO3 é limitado em dispositivos móveis. Um editor à beira do campo, digitando na chuva em um smartphone, precisa de uma máscara de entrada simplificada. A solução: um endpoint customizado com formulário reduzido (campo de texto, dropdown de categoria, botão enviar) otimizado para navegadores mobile.

Problema três: conflitos de cache com o page cache TYPO3. Se a página com o ticker é servida pelo cache TYPO3, visitantes veem entradas desatualizadas. A solução: excluir a página do ticker do page cache (USER_INT) ou melhor: cachear a página e recarregar apenas a área do ticker via AJAX.

## A extensão foi construída para versões TYPO3 mais antigas, soluções customizadas são mais à prova de futuro

liveticker não tem suporte oficial para TYPO3 v12 ou v13. A funcionalidade central é tão gerenciável que uma reconstrução como plugin customizado em muitos casos é mais econômica que a migração da extensão. A Gosign constrói funcionalidades de liveticker como plugins Extbase enxutos com endpoint JSON API consumido por um cliente JavaScript simples no frontend. O esforço para uma implementação básica (entrada backend, exibição frontend, AJAX polling) é de 3 a 5 dias de trabalho.
---

--- Mailchimp TYPO3 - Newsletter | Gosign ---
> Sincronização de assinantes entre TYPO3 e Mailchimp. Estatísticas de campanha, sincronização de templates, e-mails transacionais. LGPD:.

## A integração Mailchimp-TYPO3 vai além de formulários e sincroniza Audiences bidirecionalmente

Enquanto koning_mailchimp_signup cobre apenas formulários de inscrição, a extensão mailchimp vai um passo além: sincroniza listas completas de assinantes bidirecionalmente entre TYPO3 e Mailchimp, transfere estatísticas de campanha para o backend e pode gerar templates de newsletter a partir de elementos de conteúdo TYPO3. Para empresas que usam Mailchimp não apenas para envio de newsletter, mas como plataforma central de automação de marketing, a extensão fecha a lacuna entre CMS e e-mail marketing.

O aspecto da LGPD (PT: RGPD) é ainda mais relevante nessa integração mais profunda: não apenas endereços de e-mail, mas também dados de engajamento (aberturas, cliques, bounces), tags e Custom Fields são transferidos entre sistemas. Sem contrato de processamento de dados com Mailchimp e mecanismo documentado de transferência para os EUA, isso não é permitido em termos de proteção de dados. No Brasil, a LGPD impõe requisitos similares para transferências internacionais.

## Cenários típicos de uso são automação de marketing, sync de templates e relatórios

O cenário principal é a sincronização bidirecional de assinantes para equipes de marketing. TYPO3 é a fonte para novas inscrições (via formulários no site), Mailchimp é a fonte para dados de engajamento. A extensão sincroniza ambos os sistemas regularmente, para que marketing possa ver no Mailchimp quais assinantes vieram de qual página, e no TYPO3 fique visível quais assinantes estão ativos e quais foram marcados como inativos.

Segundo cenário: sincronização de templates. A redação mantém conteúdos de newsletter no TYPO3, e a extensão transfere elementos de conteúdo (teasers, imagens, links) para templates Mailchimp. Assim, a manutenção dupla é eliminada: o teaser no site e o teaser no newsletter vêm do mesmo registro.

Terceiro cenário: relatórios de campanha no backend TYPO3. Responsáveis de marketing que não têm acesso direto ao dashboard Mailchimp veem taxas de abertura, taxas de clique e taxas de bounce diretamente no backend TYPO3.

## Arquitetura técnica utiliza a API Mailchimp v3 com sync baseado em Scheduler

A extensão comunica via Mailchimp Marketing API v3. A autenticação ocorre por API Key configurada no Extension Manager TYPO3. O sync roda via tarefas Scheduler TYPO3 em intervalos configuráveis.

O sync de assinantes funciona em duas direções: TYPO3-para-Mailchimp transfere novas inscrições e alterações de perfil. Mailchimp-para-TYPO3 importa dados de engajamento, cancelamentos e status de bounce. A lógica de sync usa Mailchimp Member IDs (hash MD5 do e-mail) como chave única para o alinhamento.

A sincronização de templates renderiza elementos de conteúdo TYPO3 via templates Fluid em formato HTML compatível com e-mail. O template é transferido via chamada API ao Mailchimp e fica disponível como Campaign Template. A extensão cuida da conversão de classes CSS em estilos inline, necessária para compatibilidade com clientes de e-mail.

## Problemas frequentes são conflitos de sync, rate limits da API e diferenças de rendering de templates

Problema um: conflitos de sync em alterações simultâneas. Quando um assinante se cancela pelo Mailchimp e simultaneamente um editor altera o perfil no TYPO3, surge um conflito. A solução: definir soberania de dados clara. Na prática, Mailchimp é a fonte líder para dados de engajamento e cancelamentos, TYPO3 para dados mestres e novas inscrições.

Problema dois: rate limits da API. A API Mailchimp permite no máximo 10 conexões simultâneas e tem limites de throughput que atuam em grandes operações de sync. Quem sincroniza 50.000 assinantes deve dividir o sync em lotes (recomendado: 500 registros por request) e implementar lógica de backoff.

Problema três: diferenças de rendering entre site e e-mail. Um elemento de conteúdo que aparece correto no site pode parecer diferente no Outlook ou Gmail. Especialmente layouts Flexbox, webfonts e imagens SVG não funcionam em e-mails. A solução: templates de e-mail separados com layout baseado em tabelas e system fonts.

## TYPO3 v12 é suportado, para v13 recomenda-se integração API direta

A extensão mailchimp suporta TYPO3 v11 e v12. Para TYPO3 v13, como a API Mailchimp v3 é estável e bem documentada, a Gosign recomenda para projetos v13 uma integração API direta sem dependência de extensão. Uma classe de serviço customizada em um pacote TYPO3 próprio que acessa diretamente a API Mailchimp é mais fácil de manter que uma extensão comunitária e pode ser adaptada exatamente aos requisitos do projeto.
---

--- mailingwork TYPO3 - Newsletter | Gosign ---
> mailingwork é um sistema alemão de e-mail marketing. A integração TYPO3 sincroniza assinantes, Double-Opt-In e segmentação. Servidores na Alemanha.

## mailingwork é a alternativa de newsletter nativa LGPD ao Mailchimp para projetos TYPO3

Empresas que querem enviar newsletters profissionais mas não transferir dados para os EUA acabam quase inevitavelmente em um provedor europeu. mailingwork pertence às plataformas de e-mail marketing alemãs estabelecidas com servidores na Alemanha, forma jurídica alemã e equipe de suporte que pode responder perguntas de proteção de dados em alemão. A extensão TYPO3 sincroniza listas de assinantes, controla double opt-in e transfere dados de segmentação entre CMS e sistema de newsletter. Para projetos TYPO3 que precisam de uma solução de newsletter legalmente descomplicada, a combinação mailingwork e TYPO3 é uma das opções com menos manutenção no mercado.

A comparação com Mailchimp mostra a diferença: sem necessidade de contrato de processamento de dados com empresa americana, sem mecanismo de transferência para documentar, sem risco em mudanças de acordos transatlânticos de privacidade.

## Cenários típicos de uso são newsletters corporativas, comunicação com membros e nutrição de leads

O cenário padrão é o newsletter corporativo mensal para 5.000 a 50.000 destinatários. A redação mantém conteúdos no TYPO3, cria o newsletter no mailingwork e envia a listas segmentadas. A extensão TYPO3 garante que novas inscrições do site cheguem automaticamente ao mailingwork e que cancelamentos sejam sincronizados em ambas as direções.

Segundo cenário: comunicação com membros em associações e clubes. Uma associação profissional com 10.000 membros envia circulares, convites e relatórios anuais. Os dados de membros ficam no TYPO3, e mailingwork cuida do envio. A segmentação por tipo de membro, região ou grupo especializado é controlada via tags que a extensão gera a partir de categorias TYPO3.

Terceiro cenário: nutrição de leads para empresas B2B. Uma empresa industrial coleta leads via downloads de whitepapers e formulários de contato no site TYPO3. A extensão transfere os leads com informação de origem (qual formulário, qual página) ao mailingwork, que inicia uma sequência automatizada de e-mails.

## Arquitetura técnica conecta formulários TYPO3 pela API REST mailingwork

A extensão usa a API REST mailingwork para troca de dados. A configuração no Extension Manager TYPO3 inclui endpoint API, API Key e o mapeamento de campos TYPO3 para campos de contato mailingwork. O sync roda via tarefas Scheduler em intervalos configuráveis.

O import de assinantes segue um fluxo claro: um visitante preenche um formulário de inscrição no site. TYPO3 armazena os dados localmente e os transfere via chamada API ao mailingwork. mailingwork envia o e-mail de double opt-in. Somente após confirmação o assinante é conduzido na lista ativa. A extensão protocola cada passo em uma tabela de log, relevante para auditorias LGPD.

A segmentação funciona via tags e Custom Fields. A extensão pode transferir automaticamente categorias TYPO3 (Sys-Categories) como tags ao mailingwork. Assim, segmentos específicos do site podem ser usados diretamente para o envio de newsletter.

## Problemas frequentes envolvem mapeamento de campos, timing de double opt-in e tratamento de erros

Problema um: mapeamento incorreto de campos. Os campos em formulários TYPO3 raramente correspondem 1:1 aos campos de contato no mailingwork. A solução: antes da integração, criar um documento de mapeamento de campos e configurá-lo na extensão.

Problema dois: timing do double opt-in. Entre a inscrição no site e o clique no link de confirmação passam frequentemente horas ou dias. Se o job de sync roda nesse meio tempo e reporta o assinante ainda não confirmado como "ativo" ao TYPO3, surgem inconsistências. A solução: só definir o status do assinante no TYPO3 como "ativo" quando mailingwork retorna o status "confirmed".

Problema três: tratamento de erros em falhas da API. Quando a API mailingwork não está acessível, a extensão deve buffer a inscrição e tentar novamente no próximo sync. Sem essa lógica de retry, inscrições se perdem.

## mailingwork mantém a extensão TYPO3 ativamente, v12 é suportado

mailingwork como provedor comercial tem interesse comercial em manter a integração TYPO3 atual, pois o mercado TYPO3 é um canal de vendas relevante. A extensão atual suporta TYPO3 v11 e v12. Para v13, a compatibilidade é esperada mas ainda não oficialmente confirmada. No upgrade de v10 para v12, alterações afetam principalmente o registro de tarefas Scheduler e a configuração da extensão, que deve ser migrada de configurações ExtensionManager para configuração SiteSet.
---

--- maps2 TYPO3 - Extensão de mapas | Gosign ---
> A extensão padrão de mapas para TYPO3. Suporta Google Maps, OpenStreetMap e Mapbox. Marcadores a partir de registros TYPO3, clustering, rotas.

## Por que maps2 se tornou a solução padrão para mapas no TYPO3

Todo segundo site corporativo precisa de uma exibição de mapa - para localidades, filiais, locais de eventos ou áreas de entrega. No TYPO3, maps2 se estabeleceu como a extensão de mapas mais difundida por suportar três provedores de mapa simultaneamente: Google Maps, OpenStreetMap e Mapbox. Isso significa liberdade de escolha real para empresas. Quem quer evitar Google Maps por motivos de proteção de dados muda para OpenStreetMap sem precisar trocar a extensão.

maps2 vai muito além de uma simples incorporação de mapa. A extensão gera marcadores diretamente a partir de registros TYPO3, suporta clustering para grandes quantidades de marcadores e oferece funções de roteamento. Para editores, criar novas localidades é tão simples quanto criar um elemento de conteúdo TYPO3 normal.

## Cenários típicos de uso

**Localizador de filiais para empresas com 10 a 500 localidades.** Uma empresa de varejo quer oferecer um localizador interativo de filiais. Cada filial é armazenada como registro tt_address ou registro próprio no TYPO3. maps2 lê os endereços, os geocodifica (em combinação com a extensão geocoordinates) e os exibe como marcadores no mapa. Ao clicar no marcador, um popup se abre com endereço, horário de funcionamento e dados de contato. Com mais de 50 marcadores, maps2 ativa clustering automático.

**Sites imobiliários com mapas de objetos.** Sites de corretores em TYPO3 usam maps2 junto com a extensão OpenImmo. Cada objeto imobiliário importado é exibido automaticamente no mapa.

**Páginas de eventos e locais.** Instituições culturais, feiras ou municipalidades mostram locais de eventos em um mapa. maps2 pode ser vinculado a qualquer extensão Extbase que contenha dados de endereço.

## Arquitetura técnica

maps2 é construído como extensão Extbase e usa o sistema de plugin TYPO3 para a saída no frontend. A decisão arquitetural central é a abstração de provedor: a extensão define uma interface unificada para renderização de mapa, implementada por três provedores.

- **Google Maps Provider**: Usa a Google Maps JavaScript API v3. Requer API Key. Custos: aprox. 7 USD por 1.000 carregamentos de mapa após a cota gratuita (28.000/mês).
- **OpenStreetMap Provider**: Usa Leaflet.js como biblioteca de renderização com tiles OSM. Sem custos de API, sem registro necessário. Em conformidade com LGPD (PT: RGPD), pois dados permanecem na Europa.
- **Mapbox Provider**: Opção premium com estilos de mapa próprios. 50.000 carregamentos gratuitos por mês.

A extensão armazena configurações de mapa em tabelas de banco de dados próprias. Marcadores são criados via relação com registros TYPO3 arbitrários - maps2 não é restrito a um tipo de registro específico.

## Problemas frequentes e soluções

**Mapa não é exibido, apenas área cinza.** Com Google Maps, em 90% dos casos o problema é a API Key. Ou está faltando, a cobrança não está ativada, ou os domínios permitidos na API Key não correspondem ao site. Solução: verificar no Google Cloud Console se Maps JavaScript API está ativada e a chave está liberada para o domínio correto.

**Marcadores aparecem na posição errada.** Causa frequente é geocoding incorreto ou ausente. Se endereços não têm coordenadas, maps2 tenta resolvê-los via serviço de geocoding configurado. Com endereços imprecisos, marcadores acabam no centro da cidade. Solução: corrigir coordenadas via lote de geocoding único e armazená-las como valores fixos.

**Problemas de performance com mais de 200 marcadores.** A biblioteca JavaScript renderiza cada marcador individualmente no DOM. A partir de 200 marcadores, fica perceptivelmente lento em dispositivos móveis. Solução: ativar clustering de marcadores e implementar filtragem server-side.

## Migração e compatibilidade de versões

maps2 é ativamente mantido por Stefan Froemken e está disponível para TYPO3 v11 e v12 LTS. A extensão tem uma API estável e praticamente nenhuma breaking change entre versões major.

Na troca de Google Maps para OpenStreetMap (frequentemente por motivos de LGPD), apenas a configuração de provedor no maps2 precisa ser alterada. Templates e dados de marcadores permanecem idênticos. A Gosign realizou essa troca em vários clientes em menos de um dia. A motivação de proteção de dados: Google Maps transfere dados pessoais (endereço IP, browser fingerprint) para servidores Google nos EUA. Com OpenStreetMap, os dados permanecem na Europa, e um banner de consentimento para serviços de mapa se torna desnecessário.

--- Marquee TYPO3 - Texto rolante/Ticker | Gosign ---
> Faixa de texto rolante/ticker: ticker de notícias, banners de aviso, anúncios. A Gosign implementa marquees baseados em CSS sem extensão, leichtgewichtiger,.

## Textos em movimento e tickers não precisam de extensão, CSS resolve em 20 linhas

O elemento marquee é conhecido dos primórdios da web: texto rolando da direita para a esquerda pela página. A tag HTML `<marquee>` está deprecated há anos, mas o efeito continua em demanda. Tickers de notícias, banners de avisos ("Manutenção no sábado") e anúncios de eventos usam textos em movimento como mecanismo de atenção. A extensão marquee para TYPO3 entrega um elemento de conteúdo que renderiza esse efeito via JavaScript. A Gosign recomenda em vez disso uma solução puramente CSS que funciona sem extensão, sem JavaScript e sem obrigação de atualização.

A diferença é mensurável: a extensão carrega JavaScript, registra um elemento de conteúdo no TCA e precisa de templates Fluid. A alternativa CSS é uma única animação CSS (20 linhas) em um elemento de conteúdo de texto normal. Performance, acessibilidade e esforço de manutenção falam claramente a favor da abordagem CSS.

## Cenários típicos de uso são avisos de manutenção, banners de ação e resultados esportivos

O cenário mais frequente é o banner de aviso em sites corporativos. "Nosso escritório estará fechado de 24/12 a 02/01" ou "Inscreva-se agora: webinar em 15 de março". O texto em movimento chama atenção sem ser um popup. Editores mantêm o texto no backend TYPO3 e ativam ou desativam o banner por data de início e término.

Segundo cenário: tickers de notícias em portais de notícias e páginas iniciais de intranet. As últimas três a cinco manchetes rodam como ticker pela borda superior da página. Cada manchete é um link para a notícia completa.

Terceiro cenário: resultados esportivos em sites de clubes. No dia de jogo, um ticker mostra os resultados atuais de todas as equipes. Os dados vêm de uma tabela TYPO3 ou feed externo e são apresentados como texto em movimento.

## Arquitetura técnica da extensão é um elemento de conteúdo controlado por JavaScript

A extensão marquee registra um elemento de conteúdo no TCA TYPO3 que contém campos para texto, velocidade, direção e repetição. O template Fluid renderiza um elemento container, e um arquivo JavaScript inicializa a animação.

A alternativa CSS funciona assim: um elemento de conteúdo de texto normal recebe uma classe CSS (p.ex. "marquee"), e a animação CSS @keyframes scroll desloca o texto da direita para a esquerda. A animação é infinita, pausa no hover (via :hover) e respeita a configuração prefers-reduced-motion do sistema operacional, relevante para acessibilidade.

## Problemas frequentes são acessibilidade, exibição mobile e relevância SEO

Problema um: acessibilidade. Conteúdos em movimento são problemáticos para pessoas com limitações cognitivas ou epilepsia. A WCAG 2.1 exige que animações sejam pausáveis, paráveis ou ocultáveis. A solução CSS respeita automaticamente a configuração prefers-reduced-motion, o que a extensão não faz.

Problema dois: exibição mobile. Em smartphones, o espaço disponível para texto em movimento é mínimo. Um ticker legível no desktop passa tão rápido no celular que ninguém consegue ler. A solução: em dispositivos móveis, substituir o ticker por um banner estático que mostra a mensagem mais importante sem animação.

Problema três: relevância SEO. Texto em movimento é indexado por motores de busca, mas os sinais de UX (curto tempo de permanência no ticker, sem cliques) podem afetar negativamente a qualidade da página.

## A extensão é desnecessária para versões TYPO3 atuais

A extensão marquee não tem suporte oficial para TYPO3 v12 ou v13. Como a alternativa CSS pode ser implementada em 15 minutos e não cria dependência de extensão, a Gosign recomenda em toda migração a mudança. O editor usa um elemento de conteúdo de texto normal com uma classe CSS especial definida no site package. Isso é livre de manutenção, performante e acessível.
---

--- Mask TYPO3 - Elementos de conteúdo personalizados | Gosign ---
> Mask é a ferramenta padrão para Custom Content Elements no TYPO3. Criar máscaras de backend sem PHP: definir campos, atribuir Fluid Template, pronto.

## Editores precisam de elementos de conteúdo próprios, não de mais gambiarras com campos de texto

Todo site TYPO3 chega ao ponto em que os elementos de conteúdo padrão não são mais suficientes. Um carrossel de equipe, uma tabela de preços com toggles, um teaser de produto com imagem, texto e botão CTA - essas demandas acabam no RTE como HTML desorganizado ou em um container Flexform sobrecarregado. Mask resolve esse problema de forma fundamental: editores recebem formulários de backend próprios com exatamente os campos que precisam. Sem classes PHP, sem TCA manual, sem ext_tables.sql.

Mask é desde 2016 o framework mais utilizado para Custom Content Elements no TYPO3. Mais de 1.500 instalações ativas (dados: Packagist, abril 2026) e a inclusão na documentação oficial do TYPO3 como caminho recomendado para elementos de conteúdo individuais confirmam seu status como padrão de fato.

## Cenários típicos de uso

**Sites corporativos com estruturas de página complexas.** Equipes de marketing precisam de 15 a 30 elementos de conteúdo diferentes: hero banners, depoimentos, acordeões, conteúdo em abas, downloads com miniatura, cartões de contato. Mask representa cada um como formulário de backend próprio. Editores veem apenas os campos relevantes para cada elemento, sem confusão com opções irrelevantes.

**Projetos multilíngues com estrutura consistente.** Elementos Mask suportam completamente os mecanismos de tradução do TYPO3. Campos podem ser configurados como l10n_mode exclude (não traduzível) ou prefixLangTitle (traduzível com indicação). Em sites com 5 ou mais idiomas, isso economiza tempo de edição, pois a estrutura permanece idêntica e apenas o conteúdo é traduzido.

**Projetos de relançamento com dados existentes.** Quem migra de um sistema antigo (WordPress, TYPO3 com Gridelements ou TemplaVoila) precisa de estruturas de conteúdo limpas. Elementos Mask podem ser exportados como extensão independente via mask_export. Assim, as definições de conteúdo tornam-se versionáveis e implantáveis via pipelines CI/CD.

## Arquitetura técnica

Mask armazena a configuração de todos os elementos de conteúdo em um único arquivo JSON (`mask.json` ou `config/mask.json` desde o Mask 8). Este arquivo descreve campos, tipos, paletas e a associação com templates Fluid. Ao ativar ou atualizar, o Mask gera automaticamente as configurações TCA e campos de banco de dados necessários.

Os tipos de campo cobrem completamente o padrão TYPO3: String, Integer, Float, RichText, Date, DateTime, File (FAL), Inline (IRRE para estruturas aninhadas), Select, Checkbox, Radio, Link, Slug, Color Picker, Tab, Palette. Desde o Mask 8, foram adicionados campos nativos JSON e uma API aprimorada.

Templates Fluid ficam por padrão em `fileadmin/templates/mask/` ou em um caminho configurável. Cada elemento de conteúdo tem seu próprio template, opcionalmente com Partials e Layouts. Mask registra os elementos no New Content Element Wizard, incluindo ícone e descrição.

Dependências são mínimas: Mask precisa apenas do TYPO3 Core (v11, v12, v13 são ativamente suportados). Nenhuma outra extensão é necessária. Para o workflow de exportação, mask_export é uma adição opcional.

## Problemas frequentes e soluções

**Alterações de campo em sistemas produtivos.** Se um campo Mask é alterado no sistema de staging (tipo, nome do campo), mas o banco de dados em produção não é atualizado, surgem erros. Solução: usar mask_export para que alterações de configuração passem por Git e pipelines de deployment. Alternativa: Database Compare no Install Tool após cada deployment.

**Performance com muitos elementos de conteúdo.** Sites com mais de 40 elementos Mask diferentes geram uma configuração TCA grande. TYPO3 carrega esta configuração em cada chamada do backend. Solução: agrupar elementos de forma lógica, desativar os não utilizados, manter o cache do backend ativo. A partir do Mask 8, a geração TCA é significativamente mais performática do que em versões anteriores.

**Elementos aninhados (IRRE) e ordenação.** Relações inline (por exemplo, slides dentro de um elemento slider) podem perder a ordenação ao copiar e colar. Solução: definir explicitamente um campo de ordenação e garantir o `<f:for>` com `sortBy` no template Fluid. No Mask 8.x, esse comportamento é mais estável que no 7.x.

## Migração e compatibilidade de versões

Mask suporta ativamente TYPO3 v12 e v13. A versão estável atual (Mask 8.x) funciona em ambos os releases LTS. TYPO3 v11 é coberto pelo Mask 7.x, mas não recebe mais novos recursos.

Para projetos que ainda usam TemplaVoila ou DCE, o Mask oferece um caminho de migração claro. Elementos DCE podem ser convertidos manualmente para Mask: reconstruir campos na GUI do Mask, adaptar templates Fluid, migrar dados via script SQL. A Gosign realizou esse processo em projetos com mais de 20 elementos DCE e estimou o esforço entre 2 e 5 dias, dependendo da complexidade.

A partir do TYPO3 v13, a API nativa Content Block também está disponível. Para projetos Mask existentes, isso não exige pressa: Mask e Content Blocks coexistem sem problemas. Novos projetos em TYPO3 v13 puro podem avaliar se a abordagem nativa é suficiente ou se o Mask oferece vantagens através da sua GUI e workflow de exportação. A Gosign aconselha de forma específica para cada projeto, identificando qual abordagem gera menor esforço de manutenção a longo prazo.

Um aspecto frequentemente subestimado é a documentação. Elementos Mask são autoexplicativos para desenvolvedores (campos, tipos, templates), mas editores precisam de orientação: quais campos são obrigatórios? Qual tamanho de imagem é ideal? O que acontece se o campo de descrição ficar vazio? Mask suporta desde a versão 7 textos descritivos por campo, que aparecem como tooltip no backend. A Gosign cria adicionalmente um manual de edição interno por projeto, onde cada elemento Mask é documentado com screenshot, descrição de campo e boas práticas. O esforço é de meia hora por elemento, mas economiza consultas durante a operação.

Para a configuração inicial de um projeto Mask com 15 a 20 elementos de conteúdo, a Gosign calcula 3 a 5 dias de desenvolvimento, incluindo templates Fluid, preview de backend e configuração mask_export. Elementos individuais novos durante a operação são implementados em 1 a 4 horas, dependendo da complexidade do aninhamento e do design do template.

--- mask_export TYPO3 - Deploy do Mask | Gosign ---
> Extensão que exporta configurações de elementos de conteúdo Mask como extensão TYPO3 independente. Torna elementos Mask versionáveis e implantáveis.

## Sem mask_export, elementos Mask não são versionáveis e cada deployment é um risco

Mask é o padrão para Custom Content Elements no TYPO3. Mas Mask armazena sua configuração em um arquivo JSON e gera campos de banco de dados em tempo de execução. Em um processo de desenvolvimento profissional com múltiplos ambientes (local, staging, produção), isso cria um problema: como levar novos elementos de conteúdo da máquina de desenvolvimento para o servidor produtivo? Recriando manualmente no backend? Copiando a mask.json via FTP e executando Database Compare? Ambas as opções são suscetíveis a erros e não são reproduzíveis.

mask_export resolve esse problema. A extensão exporta todas as definições Mask como extensão TYPO3 independente com ext_tables.sql próprio, configurações TCA e templates Fluid. Essa extensão é instalada via Composer, versionada via Git e implantada via CI/CD - exatamente como qualquer outra extensão TYPO3. Assim, Mask torna-se pronto para uso empresarial.

## Cenários típicos de uso

**Agências com pipeline CI/CD.** Agências que implantam projetos TYPO3 via GitLab CI, GitHub Actions ou Deployer precisam de artefatos versionáveis. mask_export gera uma extensão instalável via `composer require`. Cada alteração em um elemento de conteúdo gera um novo commit que passa pela pipeline: lint, testes, deploy staging, deploy produção. Nenhuma intervenção manual no backend necessária.

**Projetos multi-site com elementos compartilhados.** Corporações com 5 a 20 instâncias TYPO3 (filiais nacionais, marcas, subsidiárias) querem elementos de conteúdo uniformes em todos os sites. mask_export gera uma extensão central incorporada em todas as instâncias. Alterações são feitas uma vez e distribuídas para todos os sites. Sem mask_export, elementos Mask teriam que ser recriados manualmente em cada instância.

**Transferência entre desenvolvimento e redação.** Desenvolvedores definem elementos de conteúdo no sistema local, exportam via mask_export e fazem commit do resultado. Editores trabalham no sistema staging ou produtivo e utilizam os elementos sem precisar da GUI do Mask. A extensão Mask pode até ser desinstalada em sistemas produtivos, se apenas a extensão exportada for necessária.

## Arquitetura técnica

mask_export lê a mask.json (ou config/mask.json desde Mask 8) e gera uma extensão TYPO3 completa. A estrutura gerada contém: ext_emconf.php (metadados da extensão), ext_tables.sql (definições de banco de dados para todos os campos Mask), Configuration/TCA/Overrides/tt_content.php (configuração TCA), Resources/Private/Templates/ (templates Fluid) e opcionalmente TypoScript Setup para renderização frontend.

O processo de exportação roda como comando CLI TYPO3: `php typo3/sysext/core/bin/typo3 mask:export`. Importante: mask_export exporta apenas a definição (campos, templates, TCA), não os conteúdos (textos, imagens em tt_content). Os dados permanecem no banco de dados e são migrados independentemente.

## Problemas frequentes e soluções

**Exportação esquecida após alteração.** Um desenvolvedor altera um campo Mask no sistema local, mas faz commit apenas da mask.json, não da nova exportação. No staging falta a configuração TCA. Solução: integrar o comando mask_export em um hook Git (pre-commit) ou na pipeline CI.

**Templates Fluid não são exportados junto.** mask_export copia por padrão os templates do caminho configurado. Se templates ficam fora desse caminho, não são capturados. Solução: manter todos os templates Mask em um diretório unificado referenciado na configuração Mask.

**Conflitos no uso simultâneo de Mask e extensão exportada.** Se no sistema produtivo tanto Mask quanto a extensão exportada estão instalados, podem ocorrer registros TCA duplicados. Solução: em sistemas onde editores não criam novos elementos, instalar apenas a extensão exportada e desinstalar Mask.

## Migração e compatibilidade de versões

mask_export acompanha o ciclo de release do Mask: quando Mask suporta uma nova versão TYPO3, mask_export é atualizado em breve. Atualmente TYPO3 v11, v12 e v13 são suportados.

Para projetos que desejam migrar para TYPO3 v13 com a API nativa Content Block, mask_export pode servir como etapa intermediária: primeiro exportar elementos Mask (estrutura limpa baseada em arquivos), depois traduzir as configurações TCA exportadas em definições Content Block. O esforço por elemento é baixo (30 a 60 minutos) quando a extensão exportada serve como referência.

Uma vantagem frequentemente negligenciada do mask_export é a testabilidade. Quando elementos de conteúdo existem como extensão independente, é possível escrever testes automatizados: verificar configuração TCA, testar renderização de templates, validar esquema de banco de dados. Em uma pipeline CI, esses testes capturam erros antes de chegarem ao staging ou produção.

Para projetos com mais de 20 elementos Mask, a Gosign recomenda incorporar o processo de exportação no workflow de desenvolvimento desde o início. O esforço de setup inicial (integrar comando CLI na pipeline CI, criar repositório Git para a extensão exportada, ajustar configuração Composer) é de aproximadamente 2 a 4 horas. Depois disso, o workflow é completamente automatizado.

--- Mask Twig TYPO3 - Templates | Gosign ---
> Templates Twig ou Nunjucks em vez de Fluid para Mask Content Elements. Para desenvolvedores frontend que preferem sintaxe Twig ou querem reutilizar templates.

## Por que desenvolvedores frontend preferem Twig ao Fluid e como Mask viabiliza isso

TYPO3 aposta com Fluid em uma engine de templates que é única no mundo PHP. Isso é simultaneamente sua força e seu maior problema: desenvolvedores frontend vindos do ecossistema Symfony, Laravel ou Node.js conhecem Twig ou Nunjucks. Fluid não conhecem. O mask_twig_nunjucks_connector fecha essa lacuna permitindo que Mask Content Elements sejam renderizados com templates Twig ou Nunjucks em vez de templates Fluid.

Para agências cuja equipe frontend trabalha com Twig e não tem interesse em aprender uma nova linguagem de templates para cada projeto TYPO3, o connector é a solução pragmática. Partials Twig existentes de projetos Symfony ou componentes Nunjucks de pattern libraries podem ser reutilizados diretamente.

## Cenários típicos de uso

**Agências com backend Symfony e frontend TYPO3.** Uma agência desenvolve suas aplicações web em Symfony e usa TYPO3 apenas para gerenciamento de conteúdo. A equipe frontend construiu uma extensa biblioteca de componentes Twig. Em vez de reescrever todos os componentes em Fluid para TYPO3, o connector incorpora os templates Twig existentes diretamente em Mask Content Elements.

**Integração de pattern library com Nunjucks.** Uma equipe de design mantém uma pattern library (ex: baseada em Fractal ou Storybook) que usa Nunjucks como linguagem de templates. O connector permite usar os mesmos templates Nunjucks tanto na pattern library quanto no TYPO3.

**Onboarding de desenvolvedores frontend em projetos TYPO3.** Um novo desenvolvedor frontend começa em um projeto TYPO3. Em vez de primeiro aprender Fluid (sintaxe, namespaces, conceito de ViewHelper), ele escreve templates Twig que já domina. A curva de aprendizado para o projeto se reduz de 2 a 3 dias para poucas horas.

## Arquitetura técnica

O mask_twig_nunjucks_connector funciona como ponte de renderização entre a extensão Mask e um motor de templates alternativo. Mask define Custom Content Elements com campos de backend. Por padrão, Mask renderiza esses elementos com templates Fluid. O connector substitui essa etapa de renderização.

A implementação técnica: a integração Twig usa a biblioteca PHP `twig/twig` (a mesma que o Symfony usa). Templates Twig são armazenados no sistema de arquivos. Os campos Mask ficam disponíveis como variáveis de template (`{{ data.header }}`, `{{ data.bodytext }}`). A integração Nunjucks pode renderizar templates server-side via bridge Node.js ou entregar como templates JavaScript client-side.

O mapeamento de variáveis ocorre automaticamente: campos simples (Text, Integer, Float) são passados diretamente. Referências FAL (imagens, arquivos) são passadas como objetos com URL, título e texto alternativo. Relações são resolvidas como arrays.

Dependências: TYPO3 Core, Extensão Mask, pacote Composer `twig/twig` (para Twig) ou Node.js (para Nunjucks server-side). Na prática, mais de 90% das instalações do connector usam Twig, não Nunjucks.

## Problemas frequentes e soluções

**Template Twig não tem acesso a dados específicos do TYPO3.** Fluid ViewHelpers como `f:uri.page`, `f:translate` ou `f:cObject` não existem em Twig. Um template Twig não pode acessar diretamente a árvore de páginas TYPO3, traduções ou outros elementos de conteúdo. Solução: todos os dados necessários devem ser fornecidos via mapeamento de variáveis. O connector pode injetar dados adicionais no contexto do template via configuração.

**Renderização Nunjucks é lenta.** A bridge Node.js para renderização Nunjucks server-side inicia um processo Node para cada request. Com páginas com mais de 10 elementos Mask, os tempos de renderização se acumulam. Solução: usar um worker process Node.js persistente ou migrar para Twig, que renderiza nativamente em PHP.

**Atualização Mask quebra nomes de variáveis de template.** Quando Mask renomeia um campo ou muda um tipo de campo, as variáveis de template mudam. Templates Fluid mostram campos vazios, templates Twig lançam erros. Solução: operar Twig em strict mode e testar templates após cada atualização Mask.

## Migração e compatibilidade de versões

O mask_twig_nunjucks_connector é um projeto comunitário com distribuição limitada. A compatibilidade depende da extensão Mask: Mask é ativamente mantido e suporta TYPO3 v11 e v12. O connector deve ser verificado quanto à compatibilidade a cada atualização Mask.

A Gosign recomenda o connector para projetos onde a equipe frontend trabalha exclusivamente com Twig e traz uma biblioteca de componentes existente. Para projetos TYPO3 puros sem requisitos externos de templates, Fluid permanece a melhor escolha, pois é suportado nativamente, não tem dependências adicionais e pode usar toda a biblioteca de ViewHelpers TYPO3. O ganho de produtividade pela reutilização de Twig deve superar o esforço de manutenção do connector - uma ponderação que deve ser quantificada concretamente a cada início de projeto.

--- mathguard TYPO3 - CAPTCHA matemático | Gosign ---
> Mathematisches CAPTCHA para TYPO3: Operações matemáticas simples em vez de CAPTCHAs de imagem.

## CAPTCHAs matemáticos são a proteção anti-spam acessível que a maioria dos sites desconhece

Spam em formulários de contato é um tema permanente. A solução mais popular é Google reCAPTCHA, que porém envia dados de usuário ao Google e complica a conformidade com a LGPD (PT: RGPD). CAPTCHAs baseados em imagem ("Clique em todos os semáforos") frustram usuários e são inacessíveis para leitores de tela. mathguard vai por outro caminho: a extensão mostra uma conta matemática simples ("Quanto é 3 + 7?") no formulário. Humanos resolvem em segundos, bots automatizados falham na maioria. Sem JavaScript externo, sem cookies, sem transferência de dados a terceiros, totalmente compatível com leitores de tela.

Para instituições públicas, universidades e empresas com requisitos de acessibilidade (WCAG 2.1), mathguard é uma das poucas soluções CAPTCHA que garante tanto proteção anti-spam quanto acessibilidade. A redução de spam fica entre 85 a 95% do tráfego de bots.

## Cenários típicos de uso são formulários de contato, funções de comentário e registros

O cenário padrão é o formulário de contato em um site corporativo. Sem proteção anti-spam, chegam diariamente 20 a 200 submissões de bots na caixa de entrada da redação. mathguard adiciona um campo de cálculo posicionado entre campo de e-mail e botão de envio. A conta é gerada aleatoriamente a cada carregamento de página.

Segundo cenário: funções de comentário em blogs e páginas de notícias. Quando visitantes podem deixar comentários em artigos, spam é inevitável. mathguard protege o formulário de comentário sem que visitantes precisem de conta Google ou app especial.

Terceiro cenário: registros de usuário. Quando um site oferece contas frontend (p.ex. para portal de clientes ou área de download protegida), mathguard protege o formulário de registro contra criações automatizadas de conta.

## Arquitetura técnica gera contas server-side com validação por sessão

mathguard trabalha completamente server-side. A cada chamada do formulário, a extensão gera uma conta matemática aleatória (adição, subtração ou multiplicação com números de um dígito). A solução correta é armazenada na sessão PHP, não no código HTML. Isso é decisivo: se a solução estivesse como campo oculto no formulário, qualquer bot poderia lê-la.

A integração em formulários TYPO3 funciona via ViewHelper ou Fluid Partial inserido em templates de formulário existentes. Para powermail e o TYPO3 Form Framework existem exemplos de configuração que permitem a integração em 10 a 15 minutos.

A conta é apresentada como texto ("Quanto é 5 + 3?"), não como imagem. Isso a torna automaticamente compatível com leitores de tela: software de leitura pode ler a conta, e o usuário insere a solução em um campo de texto normal.

Para segurança adicional, mathguard pode ser combinado com um campo honeypot: um campo de formulário invisível que é preenchido por bots mas ignorado por usuários reais. Complementarmente, uma validação de timestamp pode ser usada: se um formulário é preenchido em menos de 3 segundos, é com alta probabilidade um bot. A combinação de CAPTCHA matemático, honeypot e verificação de timestamp alcança uma redução de spam acima de 99%.

## Problemas frequentes são bots inteligentes, perda de sessão e irritação de UX

Problema um: bots avançados que resolvem contas. Bots simples de parsing de texto podem interpretar "Quanto é 3 + 7?" e inserir a resposta correta "10". A solução: apresentar a conta como texto levemente ofuscado ("Três mais sete é igual a?"). Na configuração padrão, mathguard usa contas numéricas, o que é suficiente para 85 a 95% dos bots.

Problema dois: perda de sessão. Se a sessão PHP se perde entre chamada do formulário e envio (p.ex. por load balancer sem session stickiness), a validação falha embora o usuário tenha inserido a resposta correta. A solução: configurar session stickiness no load balancer ou armazenar dados de sessão no banco em vez do sistema de arquivos.

Problema três: irritação de UX. Alguns visitantes acham uma conta matemática condescendente. A solução: colocar uma nota amigável acima do campo ("Proteção anti-spam: por favor resolva esta breve conta") e integrar a conta visualmente de forma discreta no design do formulário.

## mathguard funciona com todas as versões TYPO3, porque a técnica é mínima

A extensão não tem dependências profundas da API Core TYPO3. Tratamento de sessão, rendering de formulário e validação usam funções padrão PHP e TYPO3 que praticamente não mudam entre versões. mathguard é compatível com TYPO3 v10, v11 e v12 e previsivelmente funcionará também sob v13, possivelmente com ajustes mínimos no ViewHelper. A Gosign implementa em projetos próprios uma combinação de honeypot, validação de timestamp e CAPTCHA matemático opcional como proteção anti-spam em três camadas que funciona sem serviços externos.
---

--- md_news_author TYPO3 - Autores de notícias | Gosign ---
> Extensão de autores para GeorgRinger/news. Perfis de autores, arquivos de autores e marcação Schema.org Person. Para sites de notícias com múltiplos editores.

## md_news_author dá rosto aos redatores e schema aos mecanismos de busca

O GeorgRinger/news é a extensão padrão de facto para sistemas editoriais no TYPO3, mas só conhece um simples campo de texto de autor. Para sites de notícias com vários autores isso não basta: quem opera uma revista séria precisa de páginas de perfil de autor, biografias estruturadas e marcações Schema.org/Person para E-E-A-T. Exatamente essa lacuna é fechada pela md_news_author da Mehrwert-Digital, e exatamente por isso a extensão acaba no composer.json de quase todo projeto editorial TYPO3 de médio porte. Desde que o Google, em 2022, endureceu as diretrizes E-E-A-T e passou a considerar perfis de autor como sinal de ranking, a extensão deixou de ser apenas um recurso de conforto e virou um fator SEO mensurável para qualquer redação com mais de três autores.

## Cenários típicos são revistas online, editoras especializadas e newsrooms universitários

Editoras especializadas são o público-alvo clássico. Uma editora jurídica brasileira com 40 autores quer, para cada autor, uma página de detalhe própria com foto, mini biografia, áreas de atuação, perfil no LinkedIn e lista de todos os artigos, por razões SEO e porque o Google premia E-E-A-T. A md_news_author entrega isso a partir de um único registro. A extensão permite ainda filtrar autores por área de atuação, de forma que redatores em pesquisas temáticas encontrem diretamente os especialistas adequados.

Newsrooms universitários usam a extensão para atribuir comunicados da assessoria de comunicação aos pesquisadores reais. O comunicado de imprensa aparece sob o nome do respectivo titular da cátedra, linka para a página do instituto e é sinalizado ao Google via Person schema. Para citações e Google Scholar isso não é apenas cosmético, mas fator de ranking. Implementamos md_news_author, por exemplo, em um instituto de pesquisa médica vinculado a uma universidade brasileira, com 18 grupos de pesquisa, onde cada comunicado é atribuído ao grupo envolvido e seus membros. A extensão conecta conteúdo de notícias a perfis de pesquisadores e cria assim uma base estruturada para reputação científica na web.

Um terceiro cenário são blogs corporativos e formatos de thought leadership, em que diretores e executivos atuam como autores. A extensão separa claramente FE-User (login) de autor (perfil), de forma que biografias também possam ser mantidas para autores convidados sem conta no TYPO3. Para newsrooms corporativos com setup de ghostwriter, essa separação é decisiva: o redator de comunicação escreve o texto, mas publica sob o nome do executivo, sem que este precise de login no backend.

## Arquitetura técnica estende GeorgRinger/news via TCA overrides

A md_news_author é um complemento puro à ext:news. Ela não traz lógica de saída própria, mas registra via TCA override o campo "authors" como relação a uma nova tabela tx_mdnewsauthor_domain_model_author. Cada autor é um registro autônomo com nome, sobrenome, título, slug, biografia, imagem, LinkedIn, X, email e notas internas. A relação é do tipo MM, de modo que um artigo pode ter vários autores e, inversamente, um autor pode estar envolvido em vários artigos.

A integração em templates Fluid acontece via ViewHelpers: {author.fullName}, {author.jobTitle}, {author.image} e {author.url}. Para listas e visões de detalhe, a extensão entrega partials prontos que podem ser sobrescritos via sistema de site packages. O slug é gerado automaticamente a partir de nome e sobrenome e é editável. O roteamento para páginas de detalhe de autor ocorre via enhancer pattern na site config, permitindo URLs como /autor/fulano-da-silva/ sem estrutura adicional de páginas.

A marcação Schema.org/Person é gerada via ViewHelper JSON-LD e pode ser embutida no schema News Article. Assim o Google Search reconhece o autor, o conecta entre vários artigos e o insere no entorno do Knowledge Graph da revista. A saída do ViewHelper é compatível com o Google Structured Data Testing Tool e cobre os atributos mais importantes de Person: name, jobTitle, image, url, sameAs e worksFor.

## Problemas frequentes envolvem storage pages e conflitos de slug

O tropeço clássico é a configuração da storage page. A md_news_author espera que os registros de autor estejam em uma sysfolder explícita, referenciada no TypoScript do plugin News. Sem essa entrada, o plugin não mostra autores e os editores ficam sem saber por quê. No setup, criamos a sysfolder em /Configuração/Autores-News e a referenciamos no FlexForm do plugin. Em instalações multi-site, a sysfolder precisa ser mantida separadamente por site, para que autores permaneçam vinculados a uma marca específica.

Um segundo erro frequente são colisões de slug com outras tabelas. Se além de md_news_author também ext:sf_register ou um modelo de pessoa próprio é usado, os dois frequentemente compartilham a mesma estrutura de URL. Recomendamos definir o prefixo de routing deliberadamente como /autor/ e registrar a geração de slug no YAML da site config. Alternativamente, o routing enhancer pode ser configurado separadamente por idioma, o que é especialmente importante em instalações multilíngues com prefixos diferentes de caminho ("/author/" EN, "/autor/" BR).

Em terceiro lugar, imagens precisam de um tamanho definido. A md_news_author entrega a referência FAL, mas as variantes de cropping precisam ser mantidas no TSconfig em TCEFORM.tx_mdnewsauthor_domain_model_author.image. Sem isso, o cropping ViewHelper falha no template de detalhe e mostra imagens originais não processadas. Recomendamos definir pelo menos três variantes (square, portrait, landscape) e entregá-las de forma responsiva no template Fluid.

## Migração para TYPO3 v12 exige update no Fluid

Para TYPO3 v11 e v12, a md_news_author está estável. No salto para v12, templates Fluid próprios precisam ser ajustados ao novo namespace ({namespace md=Mehrwert\\MdNewsAuthor\\ViewHelpers}) e ao sistema de ViewHelpers revisado. Quem vem de uma versão antiga 2.x deve ainda verificar os TCA overrides, porque alguns nomes de campo foram renomeados. Especialmente o campo de biografia e os links de redes sociais ganharam propriedades adicionais em versões mais novas, que seriam ignoradas em templates antigos.

Em projetos em andamento, a Gosign migra md_news_author tipicamente no mesmo passo do upgrade do core News e da marcação Schema.org. Assim a página do artigo permanece consistente durante a transição, e a marcação Person é elevada imediatamente à especificação Schema.org atual. No mesmo passo verificamos se os perfis de autor contêm uma lista sameAs completa com contas verificadas de redes sociais, porque o Google usa esse vínculo para correspondência no Knowledge Graph.

--- Mega-Menu TYPO3 - Navigation | Gosign ---
> Navegação dropdown multi-coluna com imagens, teasers e CTAs. Navegação corporativa para estruturas de site complexas. A Gosign constrói responsive Mega-Menus.

## Komplexe Website-Strukturen mit 200+ Seiten brauchen eine Navigation, die mehr zeigt als Textlisten

Websites mit drei oder mehr Navigationsebenen und über 200 Seiten stossen mit einem Standard-Dropdown-Menü an Grenzen. Besucher klicken sich durch verschachtelte Listen, verlieren die Orientierung und brechen ab. Ein Mega-Menu löst das Problem: Beim Hover oder Klick auf einen Hauptpunkt öffnet sich ein mehrstufiges Panel mit Spalten, Bildern, Teasern und direkten CTAs. Die megamenu-Extension bringt dieses Navigationskonzept als konfigurierbares Content-Element in TYPO3. Redakteure pflegen die Menü-Inhalte (Bilder, Teaser-Texte, Links) im Backend, die Extension rendert das Mega-Menu im Frontend.

Für Enterprise-Websites mit komplexem Produktportfolio, Branchen-Portale mit regionalen Unterbereichen oder Hochschulen mit Fakultätsstrukturen ist ein Mega-Menu nicht optional, sondern Voraussetzung für brauchbare Navigation. Die Herausforderung liegt nicht in der Anzeige, sondern in acessibilidade, Responsive-Verhalten und Performance.

## Cenários típicos de uso são Unternehmenswebsites, E-Commerce und Hochschulportale

Das Standardszenario ist die Unternehmenswebsite mit 5 bis 8 Hauptkategorien und jeweils 10 bis 30 Unterpunkten. Ein Maschinenbauer zeigt unter "Produkte" fünf Produktlinien mit je sechs Produktgruppen, ergänzt durch ein Keyvisual und einen Link zum Produktkonfigurator. Unter "Branchen" erscheinen acht Branchenseiten mit Kurztext und Icon. Das Mega-Menu macht diese Struktur auf einen Blick erfassbar, ohne dass der Besucher sich durch Unterlisten klicken muss.

Zweites Szenario: E-Commerce-Websites mit breitem Sortiment. Ein Online-Shop mit 500+ Produkten in 20 Kategorien zeigt im Mega-Menu die Hauptkategorien mit Unterkategorien, Bestsellern und Aktionslinks. Die visuelle Darstellung mit Produktbildern im Menü steigert die Klickrate auf Kategorie-Seiten um geschätzte 10 bis 20% gegenüber reinen Textlisten.

Drittes Szenario: Hochschulportale mit Fakultäts- und Institutsstruktur. Eine Universität mit 12 Fakultäten und dutzenden Instituten braucht eine Navigation, die sowohl die organisatorische Struktur als auch funktionale Bereiche (Studium, Forschung, Karriere) abbildet. Das Mega-Menu zeigt unter "Studium" die Studiengangsuche, Bewerbungsinformationen und Fristen, unter "Fakultäten" die Institute mit direkten Links zu Mitarbeitern und Forschungsprojekten.

## Arquitetura técnica kombiniert TYPO3-Seitenbaum mit zusätzlichen Content-Elementen

Die megamenu-Extension erweitert die TYPO3-Navigation um ein Content-Element, das im Seitenbaum als Menü-Konfiguration angelegt wird. Jeder Hauptmenü-Punkt kann ein Mega-Menu-Panel zugeordnet bekommen, das aus Spalten besteht. Jede Spalte enthält Links, Bilder, Rich-Text-Blöcke oder benutzerdefinierte Content-Elemente.

Die Rendering-Logik erzeugt ein HTML-Konstrukt aus verschachtelten Listen und div-Containern, das per CSS als mehrstufiges Panel gestylt wird. Die JavaScript-Komponente steuert das Öffnen und Schliessen (Hover auf Desktop, Klick auf Touch-Geräten) und die Keyboard-Navigation (Tab, Enter, Escape, Pfeiltasten). ARIA-Attribute (aria-expanded, aria-haspopup, role="menu") machen das Menu für Screenreader navigierbar.

Die Performance-Implikation ist relevant: Ein Mega-Menu mit Bildern und Teasern für 8 Hauptpunkte generiert deutlich mehr HTML als ein Standard-Menü. Lazy Loading für Bilder im Mega-Menu ist Pflicht, damit die initiale Seitenladezeit nicht leidet. A Gosign recomenda, Mega-Menu-Inhalte erst beim Hover per AJAX nachzuladen, wenn das Panel mehr als 5 Bilder pro Hauptpunkt enthält.

## Problemas frequentes betreffen Accessibility, Mobile-Verhalten und Redaktions-Komplexität

Problem eins: Accessibility-Mängel. Viele Mega-Menu-Implementierungen sind mit der Tastatur nicht navigierbar. Tab springt über das gesamte Panel, statt durch die Menüpunkte zu iterieren. Escape schliesst das Panel nicht. Focus-Styles fehlen. A solução: WAI-ARIA Authoring Practices für Navigation Menus befolgen, Keyboard-Handling explizit implementieren und die Focus-Management-Logik mit einem Screenreader testen (NVDA, VoiceOver).

Problem zwei: Mobile-Verhalten. Auf Smartphones wird ein Mega-Menu zum Hindernis, weil das Panel den gesamten Bildschirm einnimmt und der Besucher nicht mehr zum Seiteninhalt zurückkehren kann. A solução: Auf Mobilgeräten das Mega-Menu durch eine Akkordeon-Navigation ersetzen, die die gleichen Inhalte in einer vertikalen Struktur darstellt. Die Umschaltung erfolgt über CSS Media Queries und eine separate JavaScript-Logik für Touch-Geräte.

Problem drei: Redaktions-Komplexität. Redakteure müssen Bilder, Texte und Links für jedes Mega-Menu-Panel pflegen. Ohne klare Richtlinien entstehen inkonsistente Panels: Eins hat vier Spalten mit Bildern, das nächste eine Spalte mit 30 Links. A solução: Eine Content-Guideline, die maximale Spaltenanzahl, Bildformate und Textlängen pro Panel definiert. A Gosign entrega diese Guideline als Teil des Mega-Menu-Projekts mit und konfiguriert die Backend-Felder so, dass Redakteure innerhalb der definierten Grenzen arbeiten (z.B. maximal 4 Spalten, maximal 8 Links pro Spalte, Bildformat 16:9).

Ein weiteres Thema ist die SEO-Implikation: Mega-Menus mit vielen Links erhöhen die Gesamtzahl der internen Links pro Seite. Wenn jede Seite 200+ Links im Mega-Menu hat, verdünnt das den Link-Juice, der an einzelne Zielseiten fliesst. A solução: Mega-Menu-Inhalte selektiv laden und nicht alle Panels gleichzeitig im HTML rendern, oder strategisch unwichtige Links mit tabindex="-1" von der Crawler-Navigation ausschliessen.

## TYPO3 v12 erfordert Anpassungen, Custom-Implementierungen sind langfristig wartbarer

Die megamenu-Extension muss bei einem Upgrade auf TYPO3 v12 angepasst werden, da sich die TCA-Konfiguration und das Content-Element-Handling geändert haben. Für v13 liegt noch keine offizielle Unterstützung vor. A Gosign constrói Mega-Menus in neuen Projekten als Custom-Komponente im Site-Package, die den TYPO3-Seitenbaum als Datenquelle nutzt und die Menü-Konfiguration über Page Properties oder Backend Layouts steuert. Das eliminiert die Abhängigkeit von der Extension und gibt volle Kontrolle über HTML-Struktur, Accessibility und Performance.
---

--- Microtemplate TYPO3 | Gosign ---
> Micro-Template-Engine para TYPO3: Pequenos blocos de texto com substituição de variáveis. Mais simples que Fluid para tarefas simples de templating de strings.

## Fluid ist manchmal Overkill, wenn man nur einen String mit Variablen füllen will

Nicht jedes Template-Problem braucht die volle Fluid-Engine. Wenn eine E-Mail-Betreffzeile "Hallo {name}, Ihre Bestellung #{orderNumber}" lauten soll oder ein Snippet im Footer "Letzte Aktualisierung: {date}" anzeigen soll, ist Fluid mit ViewHelpers, Layouts und Partials architektonischer Overhead. microtemplate liefert eine minimale Template-Engine für TYPO3, die Variablen in Textbausteinen ersetzt. Kein Fluid, kein TypoScript-Objekt-Pfad, kein Template-File. Ein String mit Platzhaltern, ein Array mit Werten, fertig.

Die Extension ist ein Nischenwerkzeug für Entwickler, die in Extensions oder TypoScript-Konfigurationen einfache String-Substitutionen brauchen, ohne die Fluid-Rendering-Pipeline zu starten. Für Redakteure ist microtemplate nicht direkt sichtbar, es arbeitet im Hintergrund als Utility. Der Anwendungsbereich ist bewusst eng: Wo Fluid die richtige Wahl für komplexe Templates mit Schleifen, Bedingungen und Vererbung ist, deckt microtemplate den simplen Fall ab, in dem ein fertiger String an drei Stellen einen dynamischen Wert braucht.

## Cenários típicos de uso são E-Mail-Texte, dynamische Snippets und Konfigurations-Templates

Das häufigste Szenario ist die Generierung von E-Mail-Texten in Extensions. Eine Custom-Extension verschickt Bestätigungs-Mails, und der Betreff und Body sollen konfigurierbar sein, ohne dass der Entwickler Fluid-Templates anlegen muss. microtemplate liest den Text aus einer TypoScript-Konstante ("Bestellung #{orderNumber} bestätigt") und ersetzt die Platzhalter mit den aktuellen Werten.

Zweites Szenario: Dynamische Text-Snippets in TypoScript-Konfigurationen. Ein Seitentitel-Pattern wie "{siteName} - {pageTitle} | {category}" wird über microtemplate aufgelöst. Das ist einfacher als ein COA mit mehreren TEXT-Objekten und stdWrap-Funktionen.

Drittes Szenario: Konfigurations-Templates für Third-Party-Integrationen. Wenn eine Extension einen API-Endpoint konfigurierbar macht ("https://api.example.com/{version}/users/{userId}"), kann microtemplate die Platzhalter vor dem API-Call ersetzen. Das ist besonders nützlich für Extensions, die mehrere API-Umgebungen (Staging, Production) unterstützen und die Endpoint-Struktur nicht im Code, sondern in der TypoScript-Konfiguration pflegen wollen.

Ein viertes Szenario, das in der Praxis gelegentlich auftaucht: Log-Nachrichten mit strukturiertem Format. Eine Extension schreibt "Import von {count} Datensätzen aus {source} abgeschlossen um {time}" ins TYPO3-Log. microtemplate macht den Log-Text konfigurierbar, ohne dass der Entwickler sprintf-Aufrufe mit positionsbasierten Argumenten pflegen muss.

## Arquitetura técnica ist eine einzige PHP-Klasse mit String-Replacement

microtemplate besteht im Kern aus einer einzigen PHP-Klasse, die str_replace oder preg_replace auf einem Template-String ausführt. Die Platzhalter folgen einer definierbaren Syntax (Standard: {variableName}). Ein assoziatives Array liefert die Werte. Die Klasse hat keine Abhängigkeiten ausser dem PHP-String-Handling.

Die Integration in TYPO3 erfolgt über einen Service oder eine statische Methode, die in anderen Extensions oder TypoScript-Konfigurationen aufgerufen wird. Es gibt kein Frontend-Plugin, kein Backend-Modul und kein Content-Element. microtemplate ist reine Infrastruktur für Entwickler.

Die Performance ist vernachlässigbar: Ein str_replace auf einem 500-Zeichen-String mit 5 Variablen dauert weniger als 0,01ms. Im Vergleich dazu startet die Fluid-Engine für das gleiche Ergebnis einen vollständigen Rendering-Zyklus mit Template-Parsing, ViewHelper-Instanziierung und Caching, was bei 1 bis 5ms liegt. In einem typischen Page-Rendering-Prozess fällt dieser Unterschied nicht auf, aber in Schleifen, die 1.000 E-Mails oder 500 Log-Einträge generieren, wird der Performance-Vorteil messbar.

Die Extension hat keine Datenbank-Tabellen, keine Backend-Module und keine Frontend-Plugins. Sie wird über Composer oder den Extension-Manager installiert und ist sofort einsetzbar. Das macht microtemplate zu einer der leichtgewichtigsten Extensions im gesamten TER (TYPO3 Extension Repository).

## Problemas frequentes sind fehlende Escaping-Logik, Syntax-Konflikte und mangelnde Dokumentation

Problem eins: Kein automatisches HTML-Escaping. microtemplate ersetzt Platzhalter 1:1, ohne den eingesetzten Wert zu escapen. Wenn ein Nutzername HTML-Tags enthält ("<script>alert('XSS')</script>"), wird das direkt in den Output geschrieben. A solução: Werte vor dem Einsetzen manuell escapen (htmlspecialchars) oder microtemplate nur für interne, nicht nutzergenerierte Daten verwenden.

Problem zwei: Syntax-Konflikte mit Fluid. Wenn microtemplate-Platzhalter ({variable}) in einem Kontext verwendet werden, in dem auch Fluid rendert, versucht Fluid die Platzhalter aufzulösen und wirft einen Fehler. A solução: Unterschiedliche Platzhalter-Syntax verwenden (z.B. {{variable}} oder %variable%) oder sicherstellen, dass microtemplate vor Fluid ausgeführt wird.

Problem drei: Mangelnde Dokumentation und Community-Support. microtemplate ist eine Nischen-Extension mit minimaler Nutzerbasis. Bei Problemen gibt es keine aktive Community, kein Issue-Tracking und keine Stack-Overflow-Antworten. Entwickler müssen den Quellcode lesen, um das Verhalten zu verstehen. Na prática führt das dazu, dass jeder Entwickler im Team die Extension anders nutzt, weil keine Konventionen dokumentiert sind.

Ein weiteres Thema: Debugging. Wenn ein Platzhalter nicht ersetzt wird, weil der Key im Array nicht exakt mit dem Platzhalter-Namen übereinstimmt (Gross-/Kleinschreibung, Leerzeichen), gibt microtemplate keine Warnung aus. Der Platzhalter bleibt einfach stehen, und der Entwickler sucht den Fehler an der falschen Stelle. Ein Debug-Modus, der nicht aufgelöste Platzhalter loggt, wäre hilfreich, fehlt aber.

## Die Extension ist TYPO3-versionsunabhängig, aber für moderne Projekte gibt es bessere Alternativen

Da microtemplate nur Standard-PHP-Funktionen nutzt, funktioniert die Extension prinzipiell mit jeder TYPO3-Version von v7 bis v13. Die Frage ist eher, ob sie noch nötig ist: Seit PHP 8.0 bietet Named Arguments in Kombination mit sprintf oder str_replace die gleiche Funktionalität ohne Extension. Für komplexere Templates ist Fluid trotz des Overheads die bessere Wahl, weil es Caching, Escaping und Template-Vererbung mitbringt. A Gosign utiliza microtemplate in Bestandsprojekten nicht aktiv ein und empfiehlt bei Neuimplementierungen, die Funktionalität direkt in der eigenen Extension oder im TypoScript über stdWrap abzubilden.
---

--- news TYPO3 - Blog e notícias | Gosign ---
> tx_news de Georg Ringer: A extensão TYPO3 mais utilizada. Notícias, blog, comunicados de imprensa. Atualização, migração, templates. Acelerado por IA.

## tx_news ist die Extension, ohne die kein TYPO3-Projekt auskommt

Über 80% aller TYPO3-Installationen setzen tx_news von Georg Ringer ein. Das allein wäre eine beeindruckende Zahl, aber sie unterschätzt die Bedeutung der Extension: tx_news ist nicht nur ein News-Plugin, sondern das Fundament für Blogs, Magazine, Pressebereiche, Event-Listen, Mitarbeiterverzeichnisse und jede andere Art von strukturiertem, chronologischem Content in TYPO3. Die Extension liefert Kategorien, Tags, Media-Assets, SEO-Felder (Canonical, OpenGraph, Schema.org), Paginierung und Import/Export aus einer einzigen, aktiv gepflegten Codebasis. Wer in TYPO3 redaktionelle Inhalte veröffentlicht, kommt an tx_news nicht vorbei.

A Gosign tx_news in hunderten Projekten konfiguriert, erweitert und migriert. Von Fluid-Templates über Custom ViewHelpers bis zur vollständigen Migration von tt_news. Die Extension ist fester Bestandteil jedes TYPO3-Setups, das wir ausliefern.

## Cenários típicos de uso vão vom Unternehmens-Blog bis zur Pressedatenbank

Das häufigste Szenario ist der Unternehmens-Blog oder das Online-Magazin. Redakteure pflegen Artikel im TYPO3-Backend mit Titel, Teaser, Body, Kategorien, Tags und Medien. Die Listenansicht zeigt Teaser mit Bild, die Detailansicht den vollständigen Artikel. SEO-relevante Felder wie Meta-Description, Canonical URL und OpenGraph-Bild werden pro Artikel gepflegt. Eine typische Installation hat 100 bis 5.000 Artikel und wächst um 2 bis 10 Artikel pro Woche.

Zweites Szenario: Pressemitteilungen für Investor Relations und Unternehmenskommunikation. Börsennotierte Unternehmen und Konzerne veröffentlichen Pflichtmitteilungen über den Pressebereich ihrer Website. tx_news liefert die Chronologie, Kategorisierung (Ad-hoc-Meldung, Quartalsbericht, Personalie) und Download-Funktion für angehängte PDFs. Die Archivfunktion stellt sicher, dass auch Meldungen von vor zehn Jahren noch auffindbar sind.

Drittes Szenario: Event-Listen und Veranstaltungskalender. tx_news kann Start- und Enddaten für Einträge verwalten, was es zum einfachen Veranstaltungskalender macht. Für Vereine, Kultureinrichtungen und Bildungsträger reicht das oft aus, ohne dass eine spezialisierte Event-Extension wie sf_event_mgt nötig ist. Erst wenn Anmeldefunktionen, Teilnehmer-Management oder Ticketing gebraucht werden, stösst tx_news an seine Grenzen.

## Arquitetura técnica trennt Daten, Konfiguration und Darstellung konsequent

tx_news speichert Artikel als Extbase-Records in der Tabelle tx_news_domain_model_news. Jeder Record enthält Pflichtfelder (Titel, Datetime, Typ) und optionale Felder (Teaser, Body, Author, Tags, Categories, Media, Related News). Die Relationen zu Kategorien und Tags laufen über MM-Tabellen, was performante Filterung ermöglicht.

Die Konfiguration erfolgt über TypoScript: Template-Pfade, Sortierung, Paginierung, Kategorie-Filter, Detail-Seiten-PID und SEO-Einstellungen. Die Extension liefert ein umfangreiches Set an TypoScript-Konstanten, das die meisten Konfigurationen ohne eigenen Code abdeckt. Für Custom-Anforderungen (z.B. ein Slider auf der Startseite, der die drei neuesten News zeigt) gibt es ViewHelper, die in Fluid-Templates genutzt werden können.

Die Fluid-Templates für List, Detail, Category und Date-Menü sind über TypoScript-Pfade überschreibbar. Na prática kopiert man die Standard-Templates ins eigene Site-Package und passt HTML-Struktur und CSS-Klassen an das Corporate Design an. Diese Trennung ermöglicht Updates der Extension, ohne dass eigene Anpassungen überschrieben werden.

Die Performance ist bei korrekter Konfiguration gut: Die Listenansicht nutzt den TYPO3-Page-Cache, die Detailansicht cached pro Artikel-UID. Erst bei News-Beständen jenseits von 10.000 Artikeln mit komplexen Kategorie-Filtern und Volltextsuche wird die Performance zum Thema. In solchen Fällen empfiehlt sich ein Suchindex über ke_search oder Solr.

## Problemas frequentes betreffen SEO-Konfiguration, Performance und die tt_news-Migration

Problem eins: Fehlende oder falsche Canonical-URLs. Ohne korrekte Konfiguration ist derselbe Artikel über mehrere URLs erreichbar: über den Kategorie-Pfad, den Archiv-Pfad und den Direkt-Link. Google indexiert alle Varianten als separate Seiten, was zu Duplicate Content führt. A solução: Die Detail-Seiten-PID explizit setzen und die Canonical-URL in den TypoScript-Settings auf die Detail-Seite konfigurieren. Die Extension newscanonical adressiert dieses Problem zusätzlich.

Problem zwei: Performance-Einbrüche bei grossen News-Beständen. Wenn die Listenansicht 5.000+ Artikel durchsuchen muss, steigen die Datenbankabfragezeiten. A solução: Kategorie-basierte Einschränkungen in der TypoScript-Konfiguration, Paginierung mit maximal 20 Artikeln pro Seite und Datenbank-Indizes auf den Kategorie-Relationen.

Problem drei: Migration von tt_news. Die Legacy-Extension tt_news ist seit TYPO3 v8 nicht mehr kompatibel. Die Datenmigration auf tx_news erfordert ein Mapping der Felder (tt_news_cat auf sys_category, Marker-Templates auf Fluid-Templates) und eine URL-Redirect-Strategie, damit bestehende Google-Rankings erhalten bleiben. A Gosign utiliza dafür KI-gestützte Template-Analyse: Unser Tooling liest die alten Marker-Templates, identifiziert die verwendeten Felder und generiert Fluid-Templates, die die gleiche Ausgabe produzieren.

## tx_news unterstützt TYPO3 v12 und v13 vollständig

Georg Ringer pflegt tx_news aktiv und stellt bei jedem TYPO3-LTS-Release zeitnah eine kompatible Version bereit. Die aktuelle Serie unterstützt TYPO3 v11, v12 und v13 parallel. Beim Upgrade von v10 oder v11 auf v12 betreffen Breaking Changes vor allem eigene ViewHelpers, die auf die aktuelle Fluid-API umgestellt werden müssen, sowie TypoScript-Konfigurationen, die auf die neue SiteSet-Syntax migriert werden sollten. Die Record-Struktur bleibt stabil, eine Datenmigration ist nicht nötig. Gosign führt tx_news-Upgrades typischerweise im Rahmen des TYPO3-Core-Upgrades durch und prüft dabei Custom-Templates, ViewHelpers und TypoScript-Overrides auf Kompatibilität. Bei Projekten mit umfangreichen Anpassungen (Custom Fields, eigene ViewHelpers, Integration mit Drittsystemen) erstellen wir vor dem Upgrade eine Kompatibilitätsmatrix, die alle Abhängigkeiten dokumentiert und den Migrationsaufwand realistisch einschätzt. KI-gestützte Code-Analyse beschleunigt diesen Prozess erheblich, indem sie alle Stellen im Projekt identifiziert, die von API-Änderungen betroffen sind.
---

--- news_podcast TYPO3 - Plugin de podcast | Gosign ---
> Funcionalidade de podcast para GeorgRinger/news. RSS-Feed mit iTunes-kompatiblen dias, Audio-Player-Integração, Episoden-Management. Für Unternehmen.

## news_podcast transforma um sistema de news em um host de podcast

Quem mantém news em TYPO3 e ao mesmo tempo produz um podcast está diante de uma decisão: usar um host externo de podcast (Podigee, Podcaster, Anchor) e linkar para o site, ou entregar o feed do podcast diretamente do TYPO3. O news_podcast torna a segunda opção possível: a extensão estende o GeorgRinger/news com campos e templates Fluid para arquivos de áudio e gera um feed RSS compatível com iTunes, que Apple Podcasts, Spotify e Google Podcasts importam sem desvios. Para empresas que querem manter soberania sobre conteúdo e arquivos de áudio, essa é a opção de arquitetura relevante. Ela evita dependência de plataforma, mantém as estatísticas de uso na própria casa e ainda entrega o conteúdo no mesmo contexto CMS onde moram também as news e a revista.

## Cenários típicos são podcasts corporativos e ofertas educacionais

Podcasts corporativos são o cenário mais frequente. Uma empresa industrial de médio porte produz a cada duas semanas um episódio com convidados do setor e quer embutir os episódios no blog corporativo, submetê-los ao Apple Podcasts e simultaneamente publicar news com transcrição e shownotes com efeito SEO. O news_podcast cobre essas três necessidades em um único registro, sem que a redação mantenha três sistemas distintos. Um registro de podcast bem mantido gera automaticamente a news, a entrada no feed RSS e a marcação Schema.org/PodcastEpisode.

Um segundo cenário são universidades e ofertas educacionais. Aulas são gravadas como arquivo de áudio e armazenadas no servidor do campus, por exemplo da USP ou UFRJ. Via news_podcast elas aparecem como episódios de uma série de aulas, com capítulos, transcrição e indicações bibliográficas. O feed é submetido ao Apple Podcasts e ao Spotify, e o acesso acontece diretamente pelo site TYPO3, sem que estudantes usem um portal adicional. Especialmente em tempos de alto componente de e-learning, essa é uma vantagem perceptível em relação a plataformas de terceiros, que exigem contas adicionais e tracking.

Um terceiro cenário são associações e organizações políticas que oferecem entrevistas semanais ou coletivas de imprensa como podcast. Aqui a questão central é soberania: todos os dados ficam na própria infraestrutura, e a estatística de audiência vem do log do servidor próprio, não de um dashboard de terceiros. Para organizações com alta sensibilidade em relação a serviços de tracking, esse costuma ser o fator decisivo contra hosts de podcast externos.

## Arquitetura técnica estende o model News com atributos de podcast

O news_podcast registra um novo conjunto de campos via TCA override para tx_news_domain_model_news. Por artigo ficam disponíveis campos adicionais: arquivo de áudio (referência FAL), duração, episódio, temporada, tipo (Full, Trailer, Bonus), flag explicit e transcrição. Via outro override, a categoria News é estendida com um campo de podcast channel, com iTunes Category, cover art, autor, email do owner e idioma.

O feed RSS é entregue por um controller TYPO3 próprio. A rota é configurável e gera um RSS 2.0 com extensões de namespace iTunes. Cada episódio contém as tags obrigatórias para enclosure, duration, episode, episodeType e explicit. A validação é feita pelo Apple Podcasts Feed Validator e pelo castfeedvalidator.com. Sem validação válida, o Apple Podcasts recusa o feed e o Spotify não mostra o canal nos resultados de busca.

A saída no frontend usa Fluid partials sobrescritíveis via site package overlay. A saída padrão embute um player HTML5 Audio e renderiza as shownotes no corpo de texto do template de detalhe News. Para a saída de transcrição, uma área de partial separada é usada, acessível via abas ou accordion. Quem quer manter transcrições como visão completa no DOM por razões de SEO sobrescreve o partial e renderiza o texto inteiro inline.

## Problemas frequentes envolvem validação do feed, enclosures e streaming

O tema de suporte mais frequente é a validação do feed iTunes. O Apple Podcasts rejeita feeds se a cover art não atender aos requisitos (mínimo 1400x1400px, máximo 3000x3000px, JPEG ou PNG, sRGB) ou se a tag <enclosure> não contiver indicação de MIME type. Na prática, a primeira submissão costuma falhar pela proporção da cover art, não pela extensão em si.

O segundo tema é tamanho de arquivo e streaming. Arquivos de áudio em qualidade de podcast (MP3 a 128 kbit) pesam por episódio entre 30 e 60 MB. Quem entrega esses arquivos diretamente pelo storage TYPO3 transfere toda a carga para o webserver, o que vira gargalo com milhares de ouvintes por episódio. Recomendamos externalizar os arquivos de áudio para um storage separado (compatível com S3, CDN) e incorporá-los via FAL remote storage. Assim o servidor TYPO3 continua cuidando da entrega de conteúdo, enquanto a carga de áudio fica em uma camada de storage mais barata.

Em terceiro, o Google Podcasts exige uma URL amigável e permanente por episódio. A extensão gera isso automaticamente a partir do slug da news, mas o routing precisa estar liberado na site config para o podcast controller, caso contrário o TYPO3 gera URLs Typolink com querystring que o Google Podcasts não aceita.

## Migração para TYPO3 v12 exige upgrade síncrono do News core

O news_podcast está disponível para TYPO3 v11, v12 e v13, mas exige uma versão compatível de GeorgRinger/news. No salto para TYPO3 v12, as duas extensões precisam ser atualizadas de forma sincronizada: news para a série v12 e news_podcast para a major version correspondente. A estrutura de banco permanece estável, referências FAL de áudio migram sem desvios.

A Gosign migra news_podcast tipicamente como parte de um refactoring de content hub. No mesmo passo, verificamos se as transcrições podem ser estendidas por dados estruturados, se a cover art atende às diretrizes atuais da Apple e se o feed controller está protegido por rate limit. Para podcasts maiores, estendemos a extensão com um modelo de hosts próprio, de modo que convidados possam ser mantidos com página de perfil e backlink. Em combinação com md_news_author, podcasters e convidados podem ser mantidos em paralelo como perfis de autor, o que melhora significativamente a marcação Schema.org e o linking interno.

--- tt_news Migration TYPO3 | Gosign ---
> Extensão de migração de tt_news para GeorgRinger/news. Transfere dados, categorias, imagens e relações. O caminho padrão de migração.

## Quem ainda usa tt_news bloqueia qualquer upgrade TYPO3 a partir da versão 10

tt_news foi por mais de uma década a extensão padrão para notícias, comunicados de imprensa e posts de blog no TYPO3. Milhares de sites foram construídos com ela, alguns com centenas ou milhares de artigos. O problema: tt_news foi oficialmente suportado pela última vez para TYPO3 v7. Desde TYPO3 v8 (2017) não existe release compatível. Quem ainda tem tt_news em uso está preso a uma versão TYPO3 desatualizada e não pode usar atualizações de segurança nem novos recursos.

A substituição oficial é GeorgRinger/news (abreviado: EXT:news), desenvolvida desde 2012 como sucessora. news é a extensão TYPO3 mais instalada de todas (mais de 250.000 instalações ativas, dados 2026) e suporta TYPO3 v11, v12 e v13. news_ttnewsimport é a extensão de migração que automatiza a transição: artigos, categorias, imagens, Related News e referências de página são transferidos de tt_news para EXT:news.

## Cenários típicos de uso

**Upgrade TYPO3 de v7/v8/v9 para v12 ou v13.** O caso mais frequente: uma empresa opera um site TYPO3 em v7 ou v9, com 500 a 5.000 artigos de notícias em tt_news. O upgrade planejado para v12 LTS falha por causa do tt_news, pois a extensão não é compatível. news_ttnewsimport transfere todos os dados para a estrutura EXT:news, permitindo a continuação do upgrade.

**Relançamento com dados existentes.** Em um relançamento de site, o design deve ser completamente novo, mas os artigos existentes devem ser preservados. Os artigos construíram valor SEO ao longo dos anos (backlinks, indexação, rankings). Um recomeço sem migração destruiria esse valor.

**Ambientes multi-site com banco de dados de notícias compartilhado.** Corporações com 5 a 20 instâncias TYPO3 que mantêm notícias centralmente e as distribuem em todos os sites. A migração deve ocorrer de forma coordenada.

## Arquitetura técnica

news_ttnewsimport é uma extensão baseada em CLI que roda via TYPO3 Command Controller. O processo de migração funciona em cinco etapas. Primeiro, categorias tt_news (tt_news_cat) são convertidas em entradas sys_category. A hierarquia de categorias (pai-filho) é mantida. Depois, os registros de notícias são migrados: título, teaser, bodytext, autor, data, tipo, data de arquivo e status. Na terceira etapa, imagens e mídias são convertidas para referências FAL. A quarta etapa migra Related News como relações. Na última etapa, elementos de conteúdo nas páginas de notícias são atualizados: plugins tt_news são substituídos por plugins EXT:news.

## Problemas frequentes e soluções

**Imagens faltam após a migração.** tt_news armazenava imagens como nomes de arquivo em um campo de texto, os arquivos ficavam em uploads/pics/. EXT:news usa FAL. Se os arquivos físicos não estão mais no diretório esperado, a migração de imagens falha. Solução: verificar antes da migração se todas as imagens referenciadas estão fisicamente presentes.

**Atribuições de categoria se perdem.** tt_news usava tabelas de categoria próprias, EXT:news usa sys_category. Se a migração não mapeia corretamente os IDs de categoria, artigos perdem sua atribuição. Solução: news_ttnewsimport cria um mapeamento (ID antigo para novo ID) e atualiza todas as referências.

**Estrutura de URL muda, rankings SEO caem.** Artigos tt_news tinham URLs como `/news/detail/titulo-do-artigo/`. EXT:news gera por padrão `/news/titulo-do-artigo/`. Solução: configurar redirects 301 das URLs antigas para as novas. Com 1.000 artigos, isso não é viável manualmente. A Gosign gera o mapa de redirects automaticamente a partir das estruturas de URL antigas e novas.

## Migração e compatibilidade de versões

news_ttnewsimport suporta a migração para EXT:news no TYPO3 v11 e v12. O procedimento recomendado: primeiro fazer upgrade do TYPO3 para v11, depois executar news_ttnewsimport, depois fazer upgrade para v12 ou v13.

Para acervos muito grandes (mais de 10.000 artigos), a Gosign recomenda realizar a migração em um sistema staging e verificar o resultado antes de converter a produção. A migração em si leva entre 30 minutos (500 artigos) e 4 horas (10.000 artigos com imagens). A adaptação de templates (templates Fluid para a nova saída EXT:news) vem como esforço separado e fica tipicamente entre 2 e 5 dias.

Um aspecto frequentemente subestimado da migração tt_news é a comunicação com motores de busca. O Google indexou e avaliou as URLs antigas. Se após a migração 500 URLs retornam 404, o site perde posições no ranking. A Gosign configura após cada migração um monitoramento de redirects: uma semana após o go-live, dados do Google Search Console são verificados para erros 404, redirects ausentes são adicionados e a indexação das novas URLs é acelerada via IndexNow.

--- newscanonical TYPO3 - Canonical para News | Gosign ---
> newscanonical: Korrekte Canonical dias para TYPO3 News. Evitar conteúdo duplicado. Otimização SEO.

## Duplicate Content durch fehlende Canonical Tags kostet TYPO3-News-Seiten Rankings

Ein tx_news-Artikel ist häufig über drei oder mehr URLs erreichbar: über den Kategorie-Pfad (/news/marketing/artikel-titel), über das Archiv (/news/2025/03/artikel-titel) und über einen Direct-Link (/news/artikel-titel). Für Besucher macht das keinen Unterschied, für Google ist es ein Problem. Google sieht drei separate Seiten mit identischem Inhalt und muss entscheiden, welche die "richtige" ist. Ohne ein Canonical-Tag, das auf die bevorzugte URL zeigt, verteilt Google die Ranking-Signale auf alle Varianten und schwächt jede einzelne. newscanonical löst dieses Problem für tx_news, indem es auf jeder News-Detailseite ein Canonical-Tag generiert, das auf die definitive URL zeigt.

Die Extension ist ein fokussiertes SEO-Tool, das genau einen Job macht: Duplicate Content bei tx_news verhindern. Für Websites mit 100+ News-Artikeln kann das den Unterschied zwischen Seite 1 und Seite 3 bei Google bedeuten.

## Cenários típicos de uso envolvem News-Websites, Magazine und Pressebereiche

Das Standardszenario ist die Unternehmenswebsite mit einem News- oder Blog-Bereich. Ein Unternehmen veröffentlicht wöchentlich Artikel, die in Kategorien (Produkte, Branchen, Events) eingeordnet sind. Jeder Artikel erscheint in der Kategorieliste und im Gesamtarchiv. Ohne newscanonical indexiert Google jede URL-Variante separat, was bei 500 Artikeln zu 1.500 indexierten Seiten mit Duplicate Content führen kann. Die Google Search Console zeigt das als "Doppelte Seite, von Google gewählte kanonische URL weicht von der vom Nutzer bestimmten ab".

Zweites Szenario: Online-Magazine mit Tag- und Kategorie-basierten Listenansichten. Ein Magazin hat 20 Kategorien und 50 Tags. Jeder Artikel hat mindestens eine Kategorie und zwei bis drei Tags. Die Kombinatorik erzeugt dutzende mögliche URL-Pfade pro Artikel. newscanonical konsolidiert alle Varianten auf eine einzige Canonical-URL.

Drittes Szenario: Pressebereiche von börsennotierten Unternehmen. Pflichtmitteilungen müssen dauerhaft verfügbar sein und dürfen im Google-Index nicht durch Duplicate-Content-Probleme aus den Suchergebnissen fallen. Ein korrektes Canonical-Tag stellt sicher, dass Google die definitive Version indexiert.

## Arquitetura técnica setzt ein Link-Tag im HTML-Header pro News-Detailseite

newscanonical registriert sich in die Rendering-Pipeline von tx_news und fügt im HTML-Header der Detailseite ein `<link rel="canonical" href="...">` Tag ein. Die Canonical-URL wird aus der konfigurierten Detail-Seiten-PID und dem News-UID berechnet, unabhängig davon, über welchen Pfad der Besucher auf die Seite gelangt ist.

Die Konfiguration erfolgt über TypoScript: Die Detail-Seiten-PID wird als Basis für die Canonical-URL gesetzt. Optionale Parameter wie die URL-Struktur (RealURL oder TYPO3 Site Handling) und die Einbeziehung von Kategorie-Segmenten in die Canonical-URL werden über Konstanten gesteuert.

Die Extension arbeitet als Hook in der tx_news-Rendering-Pipeline, nicht als eigenständiges Plugin. Isso significa: Sie hat keine eigene Frontend-Ausgabe und kein eigenes Content-Element. Die einzige sichtbare Auswirkung ist das Canonical-Tag im HTML-Source, das Suchmaschinen lesen, aber Besucher nie sehen.

Für die korrekte Funktion muss die Detail-Seiten-PID in der tx_news-Konfiguration und in der newscanonical-Konfiguration übereinstimmen. Wenn tx_news mehrere Detail-Seiten nutzt (z.B. eine pro Kategorie), muss newscanonical entsprechend konfiguriert werden, damit die Canonical-URL auf die richtige Detail-Seite zeigt.

## Problemas frequentes sind falsche PID-Konfiguration, Konflikte mit dem Core-Canonical und Redirect-Loops

Problem eins: Falsche Detail-Seiten-PID. Wenn die PID in der newscanonical-Konfiguration nicht mit der tx_news-Konfiguration übereinstimmt, zeigt das Canonical-Tag auf eine Seite, die den Artikel gar nicht anzeigen kann. Google ignoriert das Canonical-Tag dann und wählt selbst eine Variante. A solução: PID-Konsistenz prüfen und in der Google Search Console die indexierten Canonical-URLs gegen die konfigurierten URLs vergleichen.

Problem zwei: Konflikte mit dem TYPO3-Core-Canonical. Seit TYPO3 v10 hat der Core eine eigene Canonical-URL-Generierung über die SEO-Erweiterung (seo system extension). Wenn beide aktiv sind, können zwei konkurrierende Canonical-Tags im HTML-Header erscheinen. A solução: Prüfen, ob der Core-Canonical für News-Detailseiten korrekt arbeitet. Wenn ja, ist newscanonical überflüssig und kann deaktiviert werden. Wenn der Core-Canonical die News-Parameter nicht korrekt in die URL aufnimmt, bleibt newscanonical nötig.

Problem drei: Redirect-Loops bei fehlerhafter URL-Konfiguration. Wenn die Canonical-URL auf eine Seite zeigt, die selbst einen Redirect auf eine andere URL enthält, entsteht ein Loop. Das passiert typischerweise nach einer URL-Umstrukturierung, wenn alte Redirects nicht bereinigt wurden. A solução: Alle Redirects für News-URLs prüfen und inkonsistente Einträge entfernen.

## Ab TYPO3 v12 prüft Gosign, ob der Core-Canonical ausreicht

TYPO3 v12 hat den Canonical-Support im Core signifikant verbessert. Die seo system extension generiert Canonical-URLs auf Basis des Site Handling und berücksichtigt Query-Parameter. Für viele tx_news-Konfigurationen reicht der Core-Canonical seit v12 aus, sodass newscanonical nicht mehr nötig ist. A Gosign verifica bei jedem TYPO3-Upgrade, ob die Core-Lösung die News-Canonical-URLs korrekt generiert. Wenn ja, empfehlen wir die Deaktivierung von newscanonical, um eine potenzielle Konfliktstelle zu eliminieren. Wenn die News-URLs komplexe Parameter oder Kategorie-Pfade enthalten, die der Core nicht auflöst, bleibt die Extension eine valide Lösung. In jedem Fall empfehlen wir nach dem Upgrade einen systematischen Crawl mit Screaming Frog oder einem vergleichbaren Tool, um alle News-Detailseiten auf korrektes Canonical-Verhalten zu prüfen. Ein einziger falsch konfigurierter Canonical-Tag kann dutzende Seiten aus dem Google-Index verdrängen, was bei Presseseiten oder SEO-relevanten Blog-Artikeln direkten Traffic-Verlust bedeutet.
---

--- News-Sync TYPO3 | Gosign ---
> Sincronização de notícias entre instâncias TYPO3 ou fontes externas. Importação RSS, sincronização de conteúdo baseada em API com detecção de duplicatas.

## Wenn News-Content auf mehreren TYPO3-Instanzen erscheinen soll, reicht Copy-Paste nicht

Organisationen mit mehreren Websites stehen vor einem konkreten Problem: Ein Dachverband veröffentlicht eine Pressemitteilung, und 15 Landesverbände sollen sie auf ihren eigenen TYPO3-Installationen anzeigen. Oder ein Konzern betreibt eine Corporate-Website und fünf Marken-Websites, und bestimmte News sollen auf allen sechs Seiten erscheinen. Manuelles Kopieren ist fehleranfällig, zeitaufwändig und erzeugt Inkonsistenzen. newssync löst das Problem, indem es News-Artikel zwischen TYPO3-Instanzen oder aus externen Quellen automatisch synchronisiert. RSS-Import, API-basierter Sync und Duplikat-Erkennung sind die Kernfunktionen.

Für Organisationen mit einer Multi-Site-Strategie ist Content-Syndication kein Nice-to-have, sondern operativ notwendig. Ohne automatisierten Sync entstehen Content-Silos, die die Redaktion in der Zentrale nicht kontrollieren kann.

## Cenários típicos de uso são Verbands-Netzwerke, Konzern-Websites und News-Aggregation

Das häufigste Szenario ist das Verbandsnetzwerk. Ein Bundesverband veröffentlicht Branchennews, regulatorische Updates und Pressemitteilungen auf seiner TYPO3-Website. Die 16 Landesverbände betreiben eigene TYPO3-Installationen und wollen ausgewählte Artikel automatisch übernehmen. newssync importiert die markierten Artikel per RSS-Feed oder API, erstellt lokale tx_news-Records und ermöglicht den Landesverbänden, Teaser und Kategorien lokal anzupassen.

Zweites Szenario: Konzern-Websites mit einer Content-Hub-Strategie. Die Konzern-Zentrale pflegt einen News-Hub, aus dem Marken-Websites und Länder-Websites selektiv Content beziehen. Die Synchronisation läuft kategorie-basiert: Eine Marken-Website abonniert nur Artikel der Kategorien "Produkt X" und "Innovation", nicht den gesamten News-Feed.

Drittes Szenario: News-Aggregation aus externen Quellen. Ein Branchenportal importiert Pressemitteilungen von Mitgliedsunternehmen automatisch über deren RSS-Feeds. newssync prüft die Feeds in konfigurierbaren Intervallen, importiert neue Artikel und erkennt Duplikate anhand von Titel und Veröffentlichungsdatum.

## Arquitetura técnica nutzt RSS-Parsing und die TYPO3-Scheduler-Pipeline

newssync arbeitet mit zwei Import-Modi: RSS/Atom-Feed-Import und API-basierter Sync. Im RSS-Modus konfiguriert der Administrator eine Feed-URL, und der Scheduler-Task parst den Feed, extrahiert Titel, Teaser, Body, Datum und Medien-URLs und erstellt tx_news-Records in der lokalen Datenbank. Bilder werden heruntergeladen und als FAL-Dateien lokal gespeichert, damit die Quelle nicht dauerhaft erreichbar sein muss.

Im API-Modus kommuniziert newssync mit einem REST-Endpoint auf der Quell-Instanz. Das ermöglicht selektiveren Import: Statt den gesamten Feed zu importieren, können Artikel nach Kategorien, Tags oder Datum gefiltert werden. Der API-Modus überträgt auch Custom Fields, die im RSS-Format nicht abbildbar sind.

Die Duplikat-Erkennung basiert auf einem konfigurierbaren Schlüssel: standardmässig ein Hash aus Titel und Veröffentlichungsdatum. Wenn ein Artikel mit dem gleichen Schlüssel bereits existiert, wird er übersprungen oder aktualisiert, je nach Konfiguration. Das verhindert, dass derselbe Artikel mehrfach importiert wird, wenn der Sync-Job häufiger läuft als der Feed aktualisiert wird.

Der Sync läuft als TYPO3-Scheduler-Task, typischerweise alle 15 bis 60 Minuten. Die Ergebnisse jedes Laufs werden protokolliert: Anzahl importierter, aktualisierter und übersprungener Artikel. Bei Fehlern (Feed nicht erreichbar, Parser-Fehler) wird eine Warnung ins TYPO3-Log geschrieben.

## Problemas frequentes sind Medien-Import, HTML-Bereinigung und Kategorie-Mapping

Problem eins: Medien-Import schlägt fehl. Bilder und Dokumente, die im Quell-Feed referenziert werden, sind nicht immer direkt downloadbar. Hotlink-Schutz, Authentifizierung oder CDN-basierte URLs können den Download verhindern. A solução: Medien-URLs vor dem Import testen und einen Fallback-Mechanismus implementieren, der fehlende Bilder durch ein Platzhalter-Bild ersetzt.

Problem zwei: Unsauberes HTML im importierten Content. RSS-Feeds enthalten oft HTML, das nicht dem Standard des Ziel-Systems entspricht: Inline-Styles, veraltete Tags, fehlende Absätze. A solução: Eine HTML-Bereinigung (Sanitizing) nach dem Import, die überflüssige Tags und Styles entfernt und den Content in das erwartete Format bringt. TYPO3 bietet dafür die RteHtmlParser-Klasse.

Problem drei: Kategorie-Mapping zwischen Quell- und Ziel-System. Die Kategorien im Quell-Feed stimmen nicht mit den lokalen Kategorien überein. "Pressemitteilung" in der Zentrale heisst "Presse" beim Landesverband. A solução: Ein Mapping-Table in der newssync-Konfiguration, der Quell-Kategorien auf lokale TYPO3-Sys-Categories abbildet.

Ein viertes Problem betrifft die Content-Hoheit: Wenn ein Landesverband einen synchronisierten Artikel lokal ändert und die Zentrale den Originalartikel ebenfalls aktualisiert, überschreibt der nächste Sync die lokale Änderung. A solução: Synchronisierte Artikel als "read-only" markieren und lokale Anpassungen nur in dedizierten Feldern (z.B. lokaler Teaser, regionale Ergänzung) zulassen, die vom Sync nicht betroffen sind.

## Die Extension hat keine gesicherte v12-Unterstützung, Custom-Lösungen sind robuster

newssync wurde für ältere TYPO3-Versionen entwickelt und hat keine offizielle Unterstützung für v12 oder v13. Für Organisationen, die Content-Syndication als Kernfunktion benötigen, empfiehlt Gosign eine massgeschneiderte Solução: Ein Custom-Importer als Scheduler-Task, der RSS-Feeds oder eine REST-API konsumiert und tx_news-Records erstellt. O esforço para eine Grundimplementierung mit Feed-Import, Duplikat-Erkennung und Medien-Download liegt bei 3 bis 5 dias de trabalho. KI-gestützte Code-Generierung beschleunigt die Entwicklung des Feed-Parsers und des Mapping-Layers erheblich.

Der Vorteil einer Custom-Solução: Das Mapping zwischen Quell- und Ziel-Kategorien, die Medien-Verarbeitung und das Fehler-Handling können exakt auf die Anforderungen der Organisation zugeschnitten werden. Ein Bundesverband mit 16 Landesverbänden hat andere Sync-Anforderungen als ein Konzern mit 5 Marken-Websites. A Gosign implementa Content-Syndication-Lösungen auf Basis moderner TYPO3-APIs (PSR-14 Events, Symfony Messenger für Queue-basierte Verarbeitung), die auch bei v13-Upgrades kompatibel bleiben.
---

--- Audio Player TYPO3 - HTML5 | Gosign ---
> HTML5 Audio Player para TYPO3. Podcasts, audioguias, streaming de música. Player personalizado com suporte a playlist, barra de progresso,.

## Podcasts und Audioguides brauchen einen Player, der ohne externe Dienste auskommt

Wer Audio-Inhalte auf einer TYPO3-Website bereitstellen will, steht vor einer unangenehmen Wahl: Entweder ein externer Dienst wie SoundCloud oder Spotify, der Nutzerdaten an Drittserver sendet und die Gestaltung diktiert, oder ein nativer HTML5-Player, der im Browser-Default kaum benutzbar ist. nim_html5audioplayer schliesst diese Lücke. Die Extension liefert einen vollständig in TYPO3 integrierten Audio-Player mit Playlist-Support, Fortschrittsanzeige und Geschwindigkeitssteuerung. Alle Audiodateien bleiben auf dem eigenen Server, kein externer Request verlässt die Seite.

Für Museen, Bildungseinrichtungen und Verlage mit Podcast-Formaten ist das eine harte Anforderung: Audioguides dürfen keine Tracking-Cookies setzen, Schulungsinhalte müssen ohne Internetverbindung im Intranet laufen, und Corporate Podcasts sollen im CI der Organisation erscheinen. nim_html5audioplayer erfüllt alle drei Szenarien mit einem einzigen Content-Element.

## Cenários típicos de uso vão vom Museum bis zum internen Schulungsportal

Das häufigste Szenario sind Audioguides in Museen und Ausstellungen. Besucher scannen einen QR-Code, landen auf einer TYPO3-Seite und hören den Kommentar zu einem Exponat. Der Player startet ohne Autoplay, zeigt die Fortschrittsleiste und erlaubt Geschwindigkeitsanpassung zwischen 0,5x und 2x. Bei einer typischen Ausstellung mit 30 bis 50 Stationen liefert die Playlist-Funktion eine durchgängige Tour, ohne dass Besucher manuell zwischen Seiten navigieren müssen.

Das zweite grosse Einsatzfeld sind Corporate Podcasts. Unternehmen, die ihr internes Wissen als Audio-Serie aufbereiten, brauchen einen Player, der in die bestehende TYPO3-Website eingebettet ist, nicht auf einer externen Plattform lebt. nim_html5audioplayer liefert dafür einen gebrandeten Player mit Episodenliste, Kapitelmarken und Download-Option. Die Redaktion pflegt Episoden wie reguläre TYPO3-Inhalte über das Backend.

Ein drittes Szenario sind Sprachlernportale und E-Learning-Plattformen. Hier kommt die Geschwindigkeitssteuerung besonders zum Tragen: Lernende können Dialoge verlangsamen oder Wiederholungen in erhöhtem Tempo abspielen. In Kombination mit fe_login lassen sich Premium-Audioinhalte hinter einer Anmeldung schützen.

## Arquitetura técnica setzt auf native HTML5-APIs ohne JavaScript-Framework

nim_html5audioplayer nutzt die HTML5 Audio API des Browsers und rendert die Player-Oberfläche über Fluid-Templates. Es gibt keine Abhängigkeit zu jQuery, React oder einem anderen Framework. Das hält die Ladezeit minimal: Der Player selbst wiegt unter 15 KB (CSS + JS), die Audiodateien werden über FAL (File Abstraction Layer) verwaltet und per Streaming ausgeliefert.

Die Extension registriert ein eigenes Content-Element im TYPO3-Backend. Redakteure wählen Audiodateien aus der FAL-Mediathek, setzen Titel, Beschreibung und optionales Vorschaubild. Die Playlist-Funktion gruppiert mehrere Audio-Einträge in einer sortierbaren Liste. Das Rendering übernehmen Fluid-Templates, die per SiteSet oder eigenes Sitepackage überschrieben werden können.

Für die Fortschrittsanzeige speichert der Player den aktuellen Wiedergabestand im LocalStorage des Browsers. Kehrt ein Besucher zurück, springt der Player an die letzte Position. Das funktioniert ohne Cookies und ohne serverseitige Session.

## Problemas frequentes betreffen Audio-Formate und mobile Browser

Das dominierende Supportthema ist die Audio-Format-Kompatibilität. MP3 funktioniert in allen Browsern, OGG Vorbis nur in Firefox und Chrome, AAC nur in Safari und Chrome. Wer maximale Kompatibilität will, hinterlegt jede Datei als MP3. Wer bessere Qualität bei geringerer Dateigrösse braucht, liefert MP3 als Fallback und Opus als primäres Format aus.

Zweites Problem: Autoplay-Blockierung auf mobilen Geräten. iOS und Android verhindern seit 2018 die automatische Wiedergabe von Audio ohne Nutzerinteraktion. nim_html5audioplayer respektiert diese Browser-Policy und startet Audio ausschliesslich nach einem expliziten Klick. Wer dennoch Autoplay für Hintergrundmusik konfiguriert, erhält auf Mobilgeräten Stille ohne Fehlermeldung.

Drittes Thema ist die Performance bei grossen Playlists. Ab 100 Einträgen in einer einzelnen Playlist wird die DOM-Renderzeit spürbar. A solução: Playlists in thematische Blöcke von 20 bis 30 Einträgen aufteilen und über Kategorien im Backend organisieren.

## Die Extension funktioniert unter TYPO3 v11 und v12, der v13-Status hängt vom Maintainer ab

nim_html5audioplayer wurde ursprünglich für TYPO3 v8 und v9 entwickelt. Die Basis-Funktionalität (HTML5 Audio API, FAL-Integration) ist technisch stabil und läuft unter v11 und v12 ohne grössere Anpassungen. Für TYPO3 v13 existiert aktuell keine offizielle Kompatibilitätserklärung des Maintainers. Die Extension nutzt jedoch keine der in v13 entfernten APIs, sodass eine Migration in den meisten Fällen mit geringem Aufwand möglich ist.

A Gosign verifica bei TYPO3-Upgrades, ob die eingesetzten Audio-Extensions noch kompatibel sind, und empfiehlt bei Bedarf Alternativen. Wenn die Extension nicht mehr weiterentwickelt wird, lässt sich die gleiche Funktionalität über ein Custom Content Element mit nativer HTML5 Audio API und Fluid-Templates nachbauen, typischerweise innerhalb von zwei bis drei Entwicklertagen.
---

--- nimcore TYPO3 - Framework base | Gosign ---
> NIM Core Framework: biblioteca base para extensões TYPO3 personalizadas da família NIM. Classes abstratas, funções utilitárias, configuração compartilhada.

## Ohne zentrale Basis-Library erzeugen Extension-Familien doppelten Code und doppelte Fehler

TYPO3-Agenturen, die mehrere zusammengehörige Extensions entwickeln, stehen vor einem Architekturproblem: Jede Extension reimplementiert Utility-Funktionen wie Konfigurationsauslese, Backend-Module-Registrierung, FAL-Handling und Logging. Bei fünf Extensions bedeutet das fünf Kopien derselben Hilfsfunktionen, fünf Stellen für denselben Bug. nimcore löst dieses Problem als zentrale Basis-Library der NIM-Extension-Familie. Abstrakte Klassen, Utility-Funktionen und gemeinsame Konfiguration liegen an einer einzigen Stelle. Alle abhängigen NIM-Extensions erben von nimcore und müssen nur ihre fachliche Logik implementieren.

Dieses Pattern ist im TYPO3-Ökosystem selten, aber in der Software-Architektur etabliert: Ein Shared Kernel, der horizontale Concerns (Logging, Configuration, Base Models) kapselt, während vertikale Extensions (Audio Player, Galerie, Slider) die Fachlogik übernehmen.

## Cenários típicos de uso envolvem Agenturen mit eigenen Extension-Portfolios

Das primäre Szenario ist die Agentur, die ein Set von vier bis zehn eigenen TYPO3-Extensions pflegt. Ohne eine gemeinsame Basis-Library wachsen die Extensions auseinander: Die eine nutzt GeneralUtility::makeInstance, die andere den DI-Container, die dritte hat eine eigene Logger-Konfiguration. nimcore erzwingt einen einheitlichen Standard. Alle NIM-Extensions nutzen dieselben abstrakten Controller-Klassen, dasselbe Exception-Handling und dieselbe Konfigurationsstruktur.

Ein zweites Szenario sind Inhouse-Entwicklungsteams, die ihre TYPO3-Instanz mit mehreren Custom-Extensions erweitern. Statt jede Extension als isoliertes Paket zu behandeln, können Teams eine eigene Core-Library nach dem nimcore-Muster aufbauen: gemeinsame Base-Models, gemeinsame Backend-Module-Klassen, gemeinsame Test-Fixtures. Das reduziert den Wartungsaufwand und senkt die Einstiegshürde für neue Entwickler, die nur eine Architektur lernen müssen.

Ein drittes Szenario ist die Versionierung bei Upgrades. Wenn der TYPO3-Core eine API ändert, die in fünf Extensions genutzt wird, genügt ein einziges Update in nimcore. Alle abhängigen Extensions profitieren sofort, ohne dass jede einzeln angepasst werden muss. Bei einem TYPO3-v12-Upgrade mit sieben NIM-Extensions spart das typischerweise zwei bis drei Entwicklertage.

## Arquitetura técnica folgt dem Shared-Kernel-Prinzip

nimcore registriert sich als normale TYPO3-Extension und wird über Composer als Dependency in den abhängigen Extensions deklariert. Die ext_emconf.php der NIM-Extensions listet nimcore als required constraint. Beim Installieren einer NIM-Extension wird nimcore automatisch mitgeladen.

Intern liefert nimcore abstrakte Klassen für Controller, Repositories und Models, die das TYPO3-Extbase-Framework korrekt initialisieren. Utility-Klassen kapseln wiederkehrende Aufgaben: TypoScript-Konfiguration auslesen, FAL-Referenzen auflösen, Backend-Toolbars registrieren, Flash-Messages standardisiert ausgeben. Eine zentrale Configuration-Registry ermöglicht es, Extension-spezifische Einstellungen in einem einheitlichen Format zu definieren, das im TYPO3-Backend über ein Settings-Modul zugänglich ist.

Die Test-Infrastruktur ist ebenfalls in nimcore gebündelt: Base-TestCase-Klassen, Fixture-Loader und Mocking-Utilities, die funktionale Tests für Extbase-Extensions vereinfachen. Das senkt die Hürde, Tests zu schreiben, weil das Setup nicht in jeder Extension neu konfiguriert werden muss.

## Problemas frequentes entstehen bei Versions-Konflikten und zirkulären Abhängigkeiten

Das grösste Risiko einer Shared-Kernel-Architektur ist der Lock-Step-Release-Zwang: Wenn nimcore ein Breaking Change einführt, müssen alle abhängigen Extensions gleichzeitig aktualisiert werden. Na prática bedeutet das, dass nimcore semantic versioning strikt einhalten muss. Minor-Versionen dürfen keine öffentlichen Interfaces ändern, und Major-Releases brauchen eine Migrationsanleitung.

Zweites Problem: zirkuläre Abhängigkeiten. Wenn Extension A von nimcore abhängt und nimcore einen Service nutzt, der eigentlich in Extension A definiert ist, entsteht ein Zirkel. Die Lösung ist ein sauberes Dependency-Inversion-Prinzip: nimcore definiert Interfaces, die abhängige Extensions implementieren. nimcore selbst kennt keine konkreten Implementierungen.

Drittes Thema ist die Composer-Autoload-Reihenfolge. Bei grossen Installationen mit 30 oder mehr Extensions kann die Reihenfolge des Autoloadings dazu führen, dass nimcore-Klassen noch nicht verfügbar sind, wenn eine abhängige Extension geladen wird. A solução: In der composer.json der Root-Installation nimcore als erstes in der install-order definieren.

## TYPO3 v12 funktioniert, v13-Kompatibilität hängt von der Extbase-Abstraktionsschicht ab

nimcore basiert auf dem Extbase-Framework und ist damit eng an dessen API-Stabilität gekoppelt. Unter TYPO3 v12 läuft die aktuelle Version stabil. Für v13 sind Anpassungen nötig, wenn der TYPO3-Core Extbase-Interfaces ändert oder die Dependency-Injection-Konfiguration umstrukturiert.

Da nimcore ein Nischen-Produkt für die NIM-Extension-Familie ist, hängt die Weiterentwicklung direkt vom Maintainer ab. Teams, die auf nimcore setzen, sollten den Quellcode forken und in einem eigenen Repository pflegen, um nicht von externen Release-Zyklen abhängig zu sein. A Gosign recomenda bei Custom-Extension-Portfolios generell, die Shared-Kernel-Architektur intern aufzubauen und unter eigener Kontrolle zu halten, statt auf externe Core-Libraries zu vertrauen.
---

--- OIDC TYPO3 - OpenID Connect SSO | Gosign ---
> OpenID Connect para TYPO3: Azure AD, Keycloak, Okta SSO. Configuração, mapeamento de claims e solução de problemas. acelerado com IA.

## Como projetos TYPO3 sem stack de identidade próprio se conectam ao Azure AD, Keycloak ou Okta

Em toda empresa que opera Microsoft 365, Google Workspace ou um Keycloak central, a gestão de usuários já foi decidida: todas as contas de colaboradores vivem no IdP, e cada nova aplicação deve se conectar a esse IdP, não gerenciar senhas próprias. A extensão OIDC para TYPO3 atende exatamente a esse padrão ao incorporar o OpenID Connect como protocolo de autenticação no TYPO3, tornando Azure AD, Keycloak, Okta, Google Workspace ou Auth0 utilizáveis como IdP sem operar um Shibboleth SP próprio. O público-alvo são portais corporativos, intranets, áreas de login de clientes e todos os setups TYPO3 que precisam se integrar a ambientes de identidade corporativa existentes.

## Cenários típicos de uso

Um grupo industrial brasileiro com 14.000 colaboradores opera sua intranet interna em TYPO3. A equipe de TI já decidiu que cada nova aplicação se autentica contra o Azure AD e aplica Multi-Factor Authentication por lá. A extensão OIDC obtém os ID tokens do Azure AD, lê as atribuições de grupos contidas no claim e gera grupos de fe_user a partir disso. A intranet ganha Single Sign-On, MFA e Conditional Access sem infraestrutura adicional, apenas por meio de configuração limpa.

Um segundo cenário vem de empresas de médio porte: uma software house com um portal de clientes em TYPO3 utiliza o Keycloak como broker central, porque seus próprios clientes chegam com usernames ou com Social Logins como Google ou GitHub. O Keycloak unifica isso e fala OIDC para fora. O TYPO3 usa a extensão OIDC e ganha acesso a todas as variantes de login, sem nem mesmo saber que por trás há Social Login.

O terceiro caso são órgãos públicos e administrações estaduais que migram para contas de cidadão baseadas em Keycloak. Um portal TYPO3 no qual cidadãos enviam formulários de requerimento pode se conectar via extensão OIDC ao Keycloak estadual. O atributo eID do broker vai direto para o fe_user, e o nível de autenticação pode ser avaliado pelo claim acr, em conformidade com a LGPD (PT: RGPD) quanto ao tratamento dos dados.

## Arquitetura técnica: Authorization Code Flow no TYPO3

OpenID Connect é uma camada de autenticação sobre OAuth 2.0, e a extensão OIDC implementa exatamente o Authorization Code Flow. O fluxo é mais simples que o SAML: o TYPO3 redireciona o usuário ao IdP com um Authorization Request, recebe um code após o login bem-sucedido, troca esse code no servidor por um ID token e valida a assinatura via JSON Web Key Set (JWKS) do provedor. Os claims do ID token, tipicamente sub, email, name, groups e roles, são mapeados para campos de usuário TYPO3.

A extensão é configurada via Extension Configuration do TYPO3 e um Discovery Endpoint, que qualquer provedor compatível com OIDC oferece em /.well-known/openid-configuration. A extensão lê desse URL os endpoints de token, o URL JWKS e os fluxos suportados de forma automática, reduzindo erros manuais. O mapeamento de claims é feito via uma configuração YAML ou TypoScript, que mapeia nomes de campos locais para caminhos de claim.

## Problemas frequentes e soluções

O primeiro problema envolve formatos de claim: o Azure AD entrega grupos como Object IDs (GUIDs), não como nomes legíveis. Quem espera um claim group_ids e recebe group_names vê grupos vazios no TYPO3. A solução limpa está na própria aplicação Azure AD: no Token Configuration Blade é possível definir quais atributos são emitidos como claims, e adicionalmente regras de Claim Transformation podem traduzir GUIDs para nomes legíveis.

O segundo problema é o Redirect URI. Todo cliente OIDC precisa registrar no IdP exatamente a Redirect URI para a qual é enviado após o login. Diferenças em maiúsculas e minúsculas, trailing slashes esquecidos ou uma troca de HTTP para HTTPS causam erros de login imediatos que não são visíveis no log do TYPO3, porque o erro ocorre no IdP. A Gosign configura clientes separados para staging e produção, com Redirect URIs limpos, e documenta cada alteração no processo de deploy.

O terceiro tema é o Token Refresh. Quem quer sessões mais longas precisa de Refresh Tokens, que o IdP só emite se o scope offline_access for solicitado no login. Sem esse scope, a sessão TYPO3 termina assim que o ID token expira, normalmente após uma hora. A configuração no backend da extensão precisa enviar o scope offline_access e ativar a lógica de refresh de token.

Um quarto problema envolve o logout. O OIDC conhece Front-Channel e Back-Channel Logout, e ambos não estão necessariamente ativados na extensão. Quem espera Single Logout real em várias aplicações precisa configurar o End Session Endpoint do provedor e garantir que o TYPO3 chame o URL de logout do IdP ao encerrar a sessão. Sem essa configuração, o usuário continua autenticado no IdP mesmo após ter saído do TYPO3.

## Migração e compatibilidade de versões

A extensão OIDC é atualmente o padrão recomendado para TYPO3 v12 e v13, enquanto projetos antigos em v11 frequentemente ainda usam implementações OAuth próprias ou shibboleth_auth. O caminho de migração de Shibboleth para OIDC é bem estabelecido, desde que o IdP fale os dois protocolos: Keycloak, ADFS e Azure AD conseguem servir SAML e OIDC em paralelo, permitindo uma transição sem big-bang.

Quem migra de uma gestão de fe_user puramente baseada em banco de dados precisa mapear as contas existentes aos claims OIDC com uma estratégia de matching. O endereço de email é o ponto de ancoragem mais comum, mas nem sempre basta, porque emails mudam. Um claim sub gravado no fe_user como identificador persistente único é a solução mais robusta. A Gosign assume essas migrações, incluindo o casamento de contas existentes e uma fase de transição em que ambos os caminhos de autenticação funcionam em paralelo.

Para equipes que estão iniciando um novo projeto TYPO3, OIDC é, na grande maioria dos casos, a primeira escolha. A configuração é mais enxuta que a do SAML, o esforço de cliente é menor, e todo IdP moderno suporta o protocolo nativamente. Exceções só se justificam onde exigências regulatórias ou federativas requerem explicitamente SAML, como na federação CAFe mencionada. Em todos os outros cenários, especialmente IdPs baseados em nuvem e integrações corporativas, OIDC entrega o melhor equilíbrio entre simplicidade, segurança e manutenibilidade.

--- OpenImmo TYPO3 - Importação de imóveis | Gosign ---
> OpenImmo no TYPO3: Immobilien-XML importieren, darstellen, filtern. Sites de corretores, acelerado com IA.

## Por que sites de corretores sem integração OpenImmo geram trabalho duplicado

Corretores de imóveis mantêm seus objetos em softwares de gestão como FlowFact, onOffice, ImmoTool ou JustImmo. Cada objeto com fotos, preços, áreas e descrições de localização. Esses dados devem aparecer também no site - mas sem entrada manual duplicada. OpenImmo é o padrão XML alemão que faz exatamente essa ponte: o software imobiliário exporta objetos como XML, TYPO3 importa automaticamente e os exibe no site.

Sem integração OpenImmo, um escritório com 40 objetos ativos mantém cada exposição em duplicidade - uma vez no software de gestão e uma vez no site. Com tempo médio de processamento de 15 minutos por objeto, são 10 horas por mês apenas para manutenção de dados que um pipeline automatizado elimina completamente.

## Cenários típicos de uso

**Importação automatizada para sites de corretores.** Um escritório imobiliário com 30 a 100 objetos ativos opera seu site em TYPO3. Toda noite, onOffice exporta todos os objetos como OpenImmo-XML para um servidor FTP. Uma tarefa scheduler TYPO3 busca o arquivo XML, o parseia e atualiza os objetos no banco de dados - novos objetos são criados, alterados são atualizados, vendidos são arquivados. De manhã, o site está automaticamente atualizado.

**Portais imobiliários com agregação multi-fornecedor.** Uma plataforma imobiliária regional agrega objetos de 10 a 30 corretores. Cada corretor entrega seus objetos no formato OpenImmo. TYPO3 importa todos os feeds, atribui os objetos aos respectivos fornecedores e os exibe em uma plataforma comum com busca e filtragem unificadas.

**Sites de incorporadoras com visão geral de unidades.** Uma incorporadora vende 50 unidades em um projeto de construção nova. Disponibilidades e preços são mantidos no software de gestão. Via importação OpenImmo, o site TYPO3 atualiza automaticamente o status de cada unidade: disponível, reservado ou vendido.

## Arquitetura técnica

A integração OpenImmo no TYPO3 consiste em quatro componentes: parser XML (lê o arquivo OpenImmo-XML e o converte em objetos PHP - o schema OpenImmo define mais de 200 campos por objeto), pipeline de importação (tarefa scheduler ou comando CLI que executa a importação regularmente), exibição frontend (plugin Extbase que mostra objetos como lista com filtragem e como visualização de detalhe com galeria de imagens e mapa de localização) e geração de exposição (opcionalmente, páginas de detalhe podem ser baixadas como PDF).

Dependências: TYPO3 Core, opcionalmente maps2/geocoordinates para exibição de mapa e busca por raio, opcionalmente web2pdf para PDFs de exposição.

## Problemas frequentes e soluções

**Importação aborta com erros de parsing XML.** Softwares de corretores às vezes exportam XML não conforme ao schema. Campos obrigatórios ausentes, codificação de caracteres inválida (ISO-8859-1 em vez de UTF-8) ou tags não fechadas levam à interrupção. Solução: incluir etapa de pré-processamento XML que valida o arquivo antes da importação e corrige problemas de encoding.

**Imagens não são corretamente importadas.** OpenImmo-XML referencia imagens via caminhos relativos ou URLs. Se o upload FTP coloca as imagens em diretório diferente do que o XML espera, as referências de imagem ficam vazias. Solução: configurar a importação para buscar imagens relativas ao diretório XML.

**Objetos excluídos permanecem visíveis no site.** OpenImmo conhece dois caminhos para marcar objetos como vendidos/excluídos: via campo de status no XML ou por omissão do objeto na próxima exportação. Nem todas as extensões de importação suportam ambas as variantes. Solução: configurar a importação para reconciliação completa - objetos ausentes na exportação XML atual são automaticamente marcados como "vendidos" ou arquivados.

## Migração e compatibilidade de versões

Para OpenImmo no TYPO3 existem múltiplas extensões. A maioria está disponível para TYPO3 v10 e v11. Para TYPO3 v12 e v13, a seleção é mais limitada.

O formato OpenImmo em si é estável. Versão 1.2.7 é há anos o padrão de fato, e todos os pacotes de software imobiliário relevantes o suportam. A Gosign recomenda em um upgrade TYPO3 de v10/v11 para v12 uma avaliação da extensão OpenImmo existente. Se o mantenedor não está mais ativo, vale migrar para um pipeline de importação desenvolvido sob medida com PHP moderno. O investimento inicial é de 5 a 8 dias, mas o pipeline é independente de extensões de terceiros e sustentável a longo prazo.

--- Paywall TYPO3 - Monetização de conteúdo | Gosign ---
> Paywall para TYPO3: conteúdo pago, modelos de assinatura, controle de acesso. Desenvolvimento personalizado com IA, nível corporativo.

## Uma paywall em TYPO3 não é assunto de plugin, mas decisão de arquitetura

Conteúdo pago em TYPO3 parece à primeira vista uma questão banal: algumas páginas atrás de login, um gateway de pagamento na frente, pronto. Na prática, a tarefa se revela uma das mais exigentes no entorno TYPO3. O core não conhece um conceito nativo de paid content, e as poucas extensões disponíveis cobrem, na melhor das hipóteses, cenários simples de login. Quem quer monetizar conteúdo de verdade, metered paywall, hard paywall, freemium, assinaturas em níveis, acaba em desenvolvimento sob medida.

O público-alvo são tipicamente editoras, portais técnicos e provedores de conteúdo B2B. Uma editora especializada com 4.000 artigos Premium por ano precisa não só de uma verificação de acesso, mas também de um ciclo de vida de assinatura, um processo de cancelamento, uma apresentação juridicamente segura dos direitos de arrependimento conforme o Código de Defesa do Consumidor, uma interface com a contabilidade e um reporting para a redação. Tudo isso precisa ser representado em uma instalação TYPO3 existente, sem que a redação aprenda uma nova interface de CMS.

## Cenários típicos de uso

Um primeiro cenário é a metered paywall de um grupo editorial regional. O grupo publica 500 artigos pagos por mês e quer oferecer a leitoras anônimas três artigos por mês calendário gratuitos, antes que a paywall seja aplicada. A contagem acontece via cookie assinado que funciona sem login, e o desbloqueio passa por um sistema de loja existente com assinatura mensal.

Um segundo cenário é a hard paywall em uma editora técnica B2B. Aqui não há artigos grátis, cada acesso pressupõe um contrato ativo. O desafio está na combinação de assinatura individual, assinatura corporativa e acesso por IP para campus. A integração TYPO3 precisa verificar em tempo real se uma leitora tem contrato válido e disponibilizar os resultados de forma performática para navegação, busca e feeds RSS.

Um terceiro cenário é o modelo freemium de um portal setorial. O cadastro é gratuito, certas ferramentas Premium (download de whitepaper, relatório de benchmark, calculadora interativa) exigem uma assinatura paga. A paywall precisa decidir por content element se há acesso e conectar o processamento de pagamento, incluindo a emissão de nota fiscal.

Um quarto cenário é a página para anunciantes de um grupo de mídia. Aqui não se trata tanto de consumidores finais quanto de agências que querem ver uma área de mídia kit. O acesso costuma ser controlado via cadastro único mais aprovação manual pelo departamento comercial. O TYPO3 reflete o status de aprovação no perfil do usuário e libera a área protegida assim que o status está "aprovado".

## Arquitetura técnica

Uma paywall pronta para produção em TYPO3 tem várias camadas. Na frente está uma middleware que verifica a cada requisição de conteúdo se o acesso é permitido. Essa middleware recorre a uma policy de acesso que unifica assinaturas, compras individuais e quotas gratuitas. Abaixo está uma camada de persistência com dados-mestre de assinatura, histórico de pagamento e status de contrato, sincronizada com o provedor de pagamento externo (Stripe, PayPal, Mollie, Adyen, PagSeguro, Cielo).

Para o lado do conteúdo existem duas variantes: ou o conteúdo é aparado no servidor e só a parte permitida para a leitora é renderizada, ou o texto completo é entregue e a camada de overlay da paywall é controlada via markup server-side. A segunda variante é perigosa, porque ferramentas de navegador conseguem contornar o overlay. Paywalls profissionais trabalham sempre do lado servidor.

A integração TYPO3 acontece via Extbase extensions com middlewares frontend próprias, TCA overrides para o status de paywall por content element e endpoints REST para os webhooks de pagamento. Middlewares PSR-15 são desde o TYPO3 v9 o lugar limpo para interceptação de request.

## Problemas frequentes e soluções

O primeiro problema é a possibilidade de contornar via cache. Quem ativa page cache genericamente entrega o texto completo de um artigo pago a um proxy e, a partir daí, a qualquer leitor não autorizado. A solução é um cache claramente separado por role de usuário ou uma exceção do conteúdo paywall para o page cache.

O segundo problema são race conditions no ciclo de vida da assinatura. No cancelamento e na rodada de faturamento simultâneos, surgem estados inconsistentes quando a ordem de escrita entre TYPO3 e gateway de pagamento não está serializada de forma limpa. A solução é um event store para eventos de assinatura com fonte da verdade definida (normalmente o provedor de pagamento) e um processo de import idempotente.

O terceiro problema é a queda de conversão por verificações lentas de paywall. Cada milissegundo de latência custa fechamentos. A solução são verificações assíncronas de acesso com um token de sessão assinado, que evita consultas caras ao banco.

Um quarto problema são condições fiscais e jurídicas. Receitas de assinatura são tributáveis, cláusulas de arrependimento precisam ser formuladas corretamente em contratos de trato sucessivo, e em assinaturas transfronteiriças aplicam-se regimes tributários diferentes. A solução é alinhar a arquitetura de paywall desde o início com a contabilidade e o jurídico e basear o processamento de pagamento em um provedor que assuma cálculo de tributos e emissão de nota fiscal.

## Migração e compatibilidade de versões

Como paywalls em TYPO3 surgem como desenvolvimento custom, a compatibilidade de versão depende totalmente do time de desenvolvimento. Uma paywall extension bem construída roda em TYPO3 v11 a v13 se usa middlewares PSR, Dependency Injection e convenções Extbase modernas. Problemas surgem em cargas legadas que ainda usam integrações baseadas em hooks de TYPO3 v7/v8.

Em upgrades de uma paywall existente, recomenda-se uma migração em duas etapas. No primeiro passo, os clientes de API de pagamento e as middlewares de acesso são elevados às convenções TYPO3 modernas, sem alterar a lógica de negócio. No segundo passo seguem as adaptações de conteúdo como novos modelos de assinatura, contagem metered alterada ou provedores de pagamento adicionais. Essa separação reduz significativamente o risco de quebra de regressão e permite teste limpo de cada passo em staging.

A Gosign constrói e moderniza sistemas de paywall para editoras e provedores de conteúdo. A combinação de geração de código com suporte de IA para a integração da API de pagamento e revisão sênior para segurança, conformidade PCI e prevenção de race condition encurta perceptivelmente o time to market, sem que a qualidade de arquitetura sofra.

--- PDF.js TYPO3 - Visualizador de PDF | Gosign ---
> Integração do visualizador PDF.js para TYPO3. Exibir PDFs no navegador sem plugin, sem download.

## PDF.js incorpora o renderer PDF comprovado da Mozilla diretamente em páginas TYPO3, a solução leve quando redatores querem mostrar PDFs no navegador sem forçar download e sem a pesada engrenagem de um flipbook

Quando visitantes clicam em um PDF, o navegador ou abre em nova aba, faz download ou redireciona a um viewer externo. Nenhuma dessas variantes satisfaz redatores que querem apresentar um documento no contexto de uma página. O PDF.js resolve isso integrando como módulo JavaScript autônomo o viewer que o Firefox e o Chrome usam internamente, diretamente na página TYPO3. O resultado é uma apresentação consistente em todos os navegadores e dispositivos, sem que usuários precisem instalar plugin ou sair do documento.

Uma vantagem frequentemente ignorada: o usuário não deixa a página. Enquanto um PDF aberto em nova aba costuma significar o fim da sessão, a conexão de analytics permanece com o viewer embutido. Quem mede quanto tempo visitantes realmente olham um documento pode atribuir o tempo diretamente à página de conteúdo e ver quais documentos realmente são lidos.

## Cenários típicos de uso

O caso de uso mais frequente é a incorporação de documentos individuais em páginas de conteúdo, como um whitepaper em uma página de produto, um formulário de pedido em uma página de serviço ou um programa de evento ao lado da descrição do evento. A redação faz upload do PDF no FAL e o referencia via content element, o PDF.js renderiza inline. A identidade visual da página é preservada, porque borda, sombra e controles são estilizados via template do próprio site package.

O segundo caso são centros de download, nos quais vários PDFs são apresentados com uma prévia. Em vez de ícones de arquivo cegos, os usuários veem a primeira página do documento e podem, com um clique, decidir se continuam lendo ou iniciam o download completo. Para catálogos, formulários e cartilhas informativas, essa prévia frequentemente é o fator decisivo para que um documento seja clicado.

Em terceiro: disponibilização acessível de documentos de órgãos públicos e universidades. O PDF.js expõe o text layer do PDF, de forma que leitores de tela consigam ler o conteúdo, desde que o PDF tenha sido exportado corretamente como Tagged PDF.

## Arquitetura técnica

Para TYPO3 existe o PDF.js em duas variantes: como extensão TYPO3 clássica que entrega a biblioteca JavaScript e adiciona um content element no backend, ou como integração pura em site package, em que os assets do PDF.js ficam diretamente no build do próprio frontend. A variante extensão é mais confortável para redatores, porque eles conseguem configurar seleção, zoom padrão e parâmetros de prévia via backend TYPO3. A variante site package é mais limpa para desenvolvedores, porque controla a versão e integra ao processo de build existente.

Tecnicamente, o PDF.js é formado por duas partes: um parser que carrega o arquivo PDF e o decompõe em um grafo de objetos interno, e um viewer que renderiza esses objetos em um elemento canvas. As duas partes rodam totalmente no cliente. A abordagem worker garante que o parsing aconteça em uma thread separada e não bloqueie a main thread, importante para scroll fluido em documentos extensos.

A integração acontece via um bloco TypoScript e um partial Fluid que incorpora um iframe ou um container com o viewer. A URL do PDF é passada como query parameter, a configuração dos elementos de UI (botões de zoom, navegação de página, link de download) é feita via bloco de configuração do PDF.js.

## Problemas frequentes e soluções

O primeiro problema é Cross Origin. Quando o PDF é carregado de outro domínio ou de um bucket S3, o navegador bloqueia o acesso por razões de segurança. A solução é ou uma configuração CORS correta no file server ou um proxy server-side via middleware TYPO3 que entrega o PDF sob o mesmo domínio.

Segundo problema: performance em documentos grandes. Um manual de 200 páginas carrega rápido, o viewer só mostra as páginas visíveis. O problema surge quando o próprio PDF não é otimizado para web e cada imagem individual foi embutida em resolução plena de impressão. Aqui só ajuda reduzir o documento fonte previamente com Ghostscript ou ferramenta comparável, antes de chegar ao FAL.

Terceiro problema: acessibilidade sem text layer. Se o PDF é um scan puro sem OCR, leitores de tela não recebem texto. O PDF.js sozinho então não ajuda, o PDF precisa passar antes por um OCR. Para órgãos públicos brasileiros, isso não é opção, mas obrigação segundo as normas brasileiras de acessibilidade digital e as diretrizes do e-MAG.

## Migração e compatibilidade de versões

O PDF.js como biblioteca é mantido continuamente pela Mozilla e é basicamente independente da versão TYPO3. As cascas de extensão TYPO3 que integram o PDF.js, no entanto, frequentemente ficam para trás em relação à versão da biblioteca. Quem atualiza para TYPO3 v12 ou v13 deve verificar se a extensão usada tem versão compatível ou se a migração para integração em site package é o caminho melhor.

Na comparação direta com pdfviewhelpers (geração PDF no servidor) e rflipbook (efeito flipbook), o PDF.js é a opção com menor overhead e a maior compatibilidade entre navegadores. Para incorporações individuais de PDF, quase sempre é a escolha melhor do que uma solução flipbook pesada.

Quem integra o PDF.js por conta própria no site package deve definir uma estratégia de versão clara. A biblioteca recebe atualizações regulares de segurança, porque parsers de PDF são historicamente alvo popular de ataques. Um ritmo anual de atualização é o mínimo, para órgãos públicos e infraestruturas críticas, mais para trimestral. A integração via npm e um processo de build de frontend torna isso muito mais fácil do que a cópia clássica no diretório do projeto.

A Gosign integra o PDF.js como componente de site package ou como extensão TYPO3, conforme quanto controle redatores precisam. Em projetos existentes com viewers legados, a Gosign acompanha a migração e garante que acessibilidade e tempo de carregamento não sejam sacrificados pelo conforto.

--- pdfviewhelpers TYPO3 - PDF no navegador | Gosign ---
> pdfviewhelpers: Exibir PDFs diretamente no navegador. Configuração, performance e alternativas , acelerado com IA.

## pdfviewhelpers é a resposta padrão quando o TYPO3 precisa gerar PDFs no servidor a partir de templates Fluid, de faturas a ingressos e relatórios completos

Por trás do nome "pdfviewhelpers" está uma confusão frequente. A extensão não renderiza PDFs no navegador, ela gera PDFs no servidor a partir de templates Fluid. Redatores e desenvolvedores que procuram uma solução para geração dinâmica de PDF no TYPO3 chegam ao lugar certo: faturas, ingressos, confirmações, certificados ou relatórios são construídos via os mesmos Fluid ViewHelpers que entregam o frontend. O objetivo é manter a geração de PDF sem ferramentas externas e sem workflow de layout separado, dentro do stack TYPO3.

Que a extensão resolve assim um problema totalmente diferente do PDF.js ou do rflipbook, na prática, muitas vezes só fica claro tarde. Quem busca "TYPO3 PDF" chega rapidamente ao pdfviewhelpers e deve se perguntar cedo se precisa de exibição ou geração. Para a geração, a extensão é a solução tecnicamente mais sólida no entorno TYPO3, porque se baseia no paradigma Fluid que desenvolvedores já dominam.

## Cenários típicos de uso

O caso clássico são confirmações de formulário. Um cliente preenche em uma página TYPO3 um formulário de contato, uma inscrição em evento ou um formulário de orçamento, e o pdfviewhelpers gera a partir das respostas um PDF personalizado, enviado por email ou oferecido para download. O template fica como Fluid template no site package, redatores ajustam texto e placeholders sem tocar no código. A vantagem em relação a um serviço externo de PDF é que todos os dados não saem do ambiente TYPO3, relevante para proteção de dados e compliance LGPD (PT: RGPD).

O segundo uso típico são comprovantes gerados automaticamente. Provedores de cursos, conselhos profissionais e associações geram atestados de participação, certificados ou carteirinhas de associado a partir de dados de banco. A extensão combina dados Extbase com templates de layout e entrega um documento pronto. Uma grande vantagem: o template é versionado, rastreável no Git e não depende de uma pessoa que possui o último template Word.

Terceiro caso: relatórios e listas. Áreas de controladoria exportam, a partir de uma base de dados mantida em TYPO3, um relatório mensal, como export de um dashboard interno, uma lista de produtos ou uma lista de estoque, e recebem um PDF formatado com cabeçalho, rodapé e paginação.

## Arquitetura técnica

O pdfviewhelpers se baseia no TCPDF, a biblioteca PHP consagrada para geração de PDF, e expõe suas funções como Fluid ViewHelpers. Desenvolvedores escrevem, em vez de código PHP TCPDF, um template em que elementos como "pdf:document", "pdf:page", "pdf:text" e "pdf:image" aparecem como tags. Isso corresponde exatamente ao modo de pensar que desenvolvedores Fluid conhecem do frontend.

A extensão é instalada via Composer, o TCPDF vem junto como dependência. Os templates ficam no site package em Resources/Private/Templates/Pdf e são chamados via um controller próprio ou diretamente a partir de uma Extbase Action. Para injeção de variáveis, o pdfviewhelpers usa os mesmos mecanismos das views Fluid regulares, permitindo separação limpa entre fontes de dados e lógica de negócio.

A configuração é feita via TypoScript e via Extension Configuration no Install Tool, onde ficam defaults para formato de papel, fontes e margens. Quem quer usar fontes TrueType próprias precisa convertê-las via método do TCPDF e colocar em Resources/Private/Fonts/.

## Problemas frequentes e soluções

O problema mais frequente é a renderização de fontes. O TCPDF não suporta cada arquivo de fonte out of the box, especialmente as atuais variable fonts ou web fonts em WOFF2. Acentos, caracteres especiais e diacríticos (á, ã, ç, é, ê, í, ó, ú) são então substituídos por interrogações ou quadrados. A solução: converter a fonte antes com a ferramenta TCPDF "tcpdf_addfont.php" e verificar a Unicode Range. Para documentos multilíngues com caracteres cirílicos ou asiáticos, vale o uso de uma família de fonte com cobertura ampla de glifos como Noto Sans.

Segundo problema: layouts complexos. Assim que um documento precisa de conteúdo em várias colunas, gráficos flutuantes ou quebras dinâmicas, o TCPDF esbarra em limites. Paginação e rodapé podem não rodar sincronamente. Solução pragmática: reduzir o layout a uma estrutura simples no estilo de relatório e inserir gráficos complexos como imagens pré-preparadas. Quando as exigências tipográficas são realmente altas, uma alternativa como Headless Chrome com conversão HTML para PDF costuma ser a melhor escolha.

Terceiro problema: performance em documentos grandes. Um relatório de 100 páginas com muitas imagens pode bloquear o processo PHP por vários segundos. A solução está em processamento por fila: tirar a geração do PDF do request lifecycle, rodar como background job com EXT:scheduler ou uma queue extension e enviar ao usuário um link de download por email.

## Migração e compatibilidade de versões

O pdfviewhelpers é mantido continuamente e é compatível com TYPO3 v11, v12 e v13. Em upgrades, vale atenção sobretudo ao salto de versão PHP: versões antigas do TCPDF têm problemas de compatibilidade com PHP 8.2 e 8.3, principalmente deprecated warnings. A solução costuma ser uma atualização do pdfviewhelpers, que puxa a versão compatível do TCPDF.

Quem ainda mantém um setup TCPDF próprio de tempos TYPO3 anteriores ao v9 tem, com a migração para pdfviewhelpers, a chance de passar layouts de PDF de código PHP para templates Fluid manuteníveis. Isso se paga a médio prazo, porque redatores podem fazer ajustes simples sozinhos, em vez de sempre bloquear tempo de desenvolvedor.

Para novos inícios, vale olhar a combinação entre pdfviewhelpers e alternativas Headless Chrome como wkhtmltopdf ou Gotenberg. Para PDFs puros de formulário e relatórios simples, o pdfviewhelpers é a escolha mais rápida e estável. Assim que entram em cena layouts tipograficamente exigentes com web fonts, colunas e gráficos de fundo, uma pipeline baseada em HTML desempenha melhor. A decisão deve ser tomada cedo no projeto, porque uma troca tardia de pipeline exige a reconstrução completa dos templates.

A Gosign implementa pdfviewhelpers, migra setups TCPDF legados e assessora sobre alternativas para layouts complexos. A combinação de experiência TYPO3 e geração de templates com suporte de IA tipicamente reduz a execução a menos da metade do tempo.

--- personnel TYPO3 - Diretório de colaboradores | Gosign ---
> Extensão TYPO3 para diretórios de colaboradores. Equipes, departamentos, dados de contato, fotos de perfil.

## personnel organiza diretórios de colaboradores como modelo de dados próprio

Páginas de equipe, listas de contatos e diretórios de departamentos são padrão em sites corporativos, mas não podem ser mantidos de forma sensata como content element. Quem gerencia 50 colaboradores com nome, função, foto, telefone, email, LinkedIn, departamento e localização precisa de um modelo de dados próprio. A extensão personnel traz exatamente isso: uma tabela limpa para pessoas, conectada a departamentos e localizações, entregue via templates Fluid configuráveis. Em todo projeto TYPO3 de médio porte com presença corporativa, essa exigência aparece repetidamente, e o personnel é uma das soluções consolidadas. Alternativas como tt_address ficam curtas, porque lhes falta estrutura de departamento, lógica de filtro e integração limpa com o frontend.

## Cenários típicos são escritórios, agências e universidades

Escritórios de advocacia são um use case clássico. Um escritório com 30 advogados e 10 paralegais precisa de uma página de equipe com filtro por área de atuação (trabalhista, tributário, sucessões), por localização (São Paulo, Rio de Janeiro, Brasília) e por função (sócio, associado, estagiário). O personnel entrega o modelo de dados, e a extensão pode ser expandida com poucos ajustes Fluid para formar um diretório completo. Cada perfil de advogado contém adicionalmente a inscrição na OAB, as afiliações profissionais e os artigos técnicos publicados, para que clientes encontrem o contato certo de relance.

Agências e consultorias usam o personnel para páginas de equipe com mini biografias, áreas de atuação e links de contato. Aqui, menos importante é o filtro do que a apresentação: retratos grandes, citações, botões LinkedIn e linking interno para cases nos quais a pessoa esteve envolvida. A página de equipe vira vitrine, e o personnel entrega o modelo de dados sem que cada colaborador vire um content element próprio.

Universidades e instituições de pesquisa têm outra exigência: colaboradores costumam estar vinculados a institutos, cátedras e projetos de pesquisa. O personnel se torna então o modelo de dados-mestre, referenciado por news, listas de publicações e eventos. A pessoa aparece não só na página de equipe, mas também como autora em publicações e como contato em projetos de pesquisa. Assim a extensão vira a base central de pessoas, usada por várias sub-extensões simultaneamente, e entrega perfis consistentes por anos.

## Arquitetura técnica é baseada em Extbase com relações para departamento e localização

O personnel define três tabelas centrais: tx_personnel_domain_model_personnel, tx_personnel_domain_model_department e tx_personnel_domain_model_location. Uma pessoa é conectada via foreign_field ou relação MM a um ou mais departamentos, além de uma localização. O schema de banco representa assim uma organização em matriz típica.

Os campos de uma pessoa cobrem os atributos padrão: título, nome, sobrenome, função, descrição curta, telefone, celular, fax, email, endereço, foto de perfil (FAL), links de redes sociais. Via TCA overrides, campos adicionais como áreas de atuação, certificações ou idiomas podem ser incluídos sem fazer fork da extensão.

O plugin renderiza via templates Fluid do diretório EXT. As variantes padrão são lista, detalhe e visão de filtro. Quem usa grids como CSS Grid ou Flexbox sobrescreve o template de lista no próprio site package. Para filtros e busca, a extensão usa repositories Extbase com filtros querybuilder, configuráveis via TypoScript. Uma implementação Gosign típica oferece no frontend uma busca textual sobre nome e função combinada com filtros select para departamento e localização, de forma que usuários encontrem em poucos cliques o contato certo entre 200 colaboradores.

## Problemas frequentes envolvem LGPD, direitos de imagem e multilinguismo

O primeiro e mais importante tema de suporte é a LGPD. Dados de colaboradores são dados pessoais, e a publicação exige ou consentimento ou legítimo interesse. Quem trabalha com fotos, ramais e celulares pessoais precisa de um processo limpo: documentar consentimento, botão on/off por pessoa, remoção automática após desligamento. O personnel não oferece audit log de fábrica, mas o workflow pode ser modelado com formulários próprios e um campo de consent adicional. No desligamento, o registro não deve ser simplesmente deletado, mas desativado via soft delete, para que news antigas continuem resolvendo corretamente.

O segundo tema são direitos de imagem. Fotos de perfil ficam no FAL e são entregues em variantes por apresentação. É importante que a atribuição de copyright e o consentimento do colaborador estejam documentados, especialmente quando a foto também é usada como teaser em news ou em redes sociais. Recomendamos manter os campos FAL "Fotógrafa/Fotógrafo" e "Licença" de forma consistente.

Em terceiro, multilinguismo é um problema prático. Uma pessoa tem um nome, mas sua função e a mini biografia diferem em português e inglês. O personnel suporta o padrão TYPO3 para traduções, mas muitos projetos esquecem de localizar também os registros de departamento e localização, o que leva a saídas mistas em idiomas.

## Migração para TYPO3 v12 exige update do Extbase e revisão de TCA

O personnel está disponível para várias versões do TYPO3 no TER. No upgrade de uma instalação v10 ou v11, os Extbase repositories precisam ser adaptados à persistence API atual, e a estrutura TCA deve ser verificada quanto a incompatibilidades de tipo (especialmente em campos "passthrough" e "none", que no v12 são validados de forma mais rígida).

A Gosign frequentemente migra instalações personnel no âmbito de um refactoring das páginas de equipe. No mesmo passo verificamos se o acervo pode ser elevado a um schema de pessoa mais moderno (com marcação JSON-LD), se filtros e busca lidam com grandes datasets de forma performática e se a página de equipe é entregue de forma responsiva e acessível. Para projetos com datasets extremamente grandes (vários milhares de pessoas) vale ainda um olhar em indexação e lazy loading, para que a visão de lista não vire gargalo em dispositivos móveis. Em estruturas de equipe especialmente complexas, ocasionalmente substituímos o personnel por um modelo Extbase custom, quando a estrutura padrão de campos não basta ou quando é necessária conexão a um sistema de RH externo.

--- PhotoSwipe TYPO3 - Lightbox | Gosign ---
> PhotoSwipe é uma biblioteca lightbox otimizada para toque. A extensão TYPO3 integra PhotoSwipe como galeria de imagens: Zoom, Swipe-Gesten,.

## Bildergalerien auf mobilen Geräten funktionieren nur mit touch-optimierten Lightboxen

Die meisten TYPO3-Websites nutzen Lightboxen, die für Desktop-Browser entwickelt wurden: Fancybox, Colorbox, Magnific Popup. Auf Smartphones und Tablets fühlen sich diese Lösungen fremd an, weil Zoom und Navigation nicht auf Touch-Gesten reagieren, sondern auf Mausklicks. PhotoSwipe ist eine JavaScript-Library, die von Grund auf für Touch gebaut wurde. Die TYPO3-Extension integriert PhotoSwipe als vollständige Bildergalerie mit Pinch-to-Zoom, Swipe-Navigation, Deep-Linking und responsivem Layout. Bei unter 30 KB (minified + gzip) ist PhotoSwipe gleichzeitig eine der leichtgewichtigsten Lightbox-Lösungen am Markt.

Für Websites mit hohem Mobile-Anteil, also heute praktisch alle, ist das keine optionale Verbesserung, sondern eine funktionale Anforderung. Besucher erwarten die gleichen Gesten, die sie von der nativen Foto-App ihres Smartphones kennen.

## Cenários típicos de uso abrangem Portfolio-Galerien, Produktbilder und Medienarchive

Das häufigste Szenario sind Portfolio-Galerien auf Agentur-, Architektur- oder Fotografie-Websites. Ein Fotograf zeigt 20 bis 40 Bilder pro Projekt. Besucher klicken ein Thumbnail, sehen das Bild in voller Auflösung, zoomen per Pinch und wischen zum nächsten Bild. Deep-Linking bedeutet, dass jedes Bild eine eigene URL hat, die geteilt oder verlinkt werden kann. Das ist für SEO relevant, weil Google die Bilder über die Deep-Link-URLs indexieren kann.

Ein zweites Szenario sind Produktdetailseiten in E-Commerce-nahen TYPO3-Installationen. Ein Möbelhersteller zeigt fünf Perspektiven pro Produkt. PhotoSwipe rendert diese als Galerie mit High-Resolution-Zoom, der auf Desktop per Mausrad und auf Touch per Doppeltipp aktiviert wird. Die Zoom-Qualität hängt direkt von der Auflösung des Quellbilds ab. Wir empfehlen mindestens 2000 Pixel Breite für Produktbilder, die per Zoom betrachtet werden sollen.

Drittes Szenario: Medienarchive und Pressebereiche. Eine Universität stellt 500 Eventfotos bereit. PhotoSwipe rendert die Galerie performant, weil Bilder erst beim Aufblättern geladen werden (Lazy Loading). Die Thumbnail-Übersicht zeigt 50 Bilder pro Seite ohne spürbare Ladezeit.

## Arquitetura técnica bindet PhotoSwipe als TYPO3 Content Element ein

Die Extension registriert ein eigenes Content-Element im TYPO3-Backend. Redakteure wählen Bilder aus der FAL-Mediathek, definieren die Sortierung und setzen optionale Bildunterschriften. Das Rendering übernehmen Fluid-Templates, die die PhotoSwipe-JavaScript-Library initialisieren und die Bild-URLs als JSON-Array übergeben.

PhotoSwipe selbst hat keine Abhängigkeiten, kein jQuery, kein Framework. Die Library besteht aus einer CSS-Datei und einer JS-Datei. Die TYPO3-Extension lädt beide über TypoScript-AssetCollector, sodass sie nur auf Seiten eingebunden werden, die tatsächlich eine Galerie enthalten. Das vermeidet unnötige Requests auf Seiten ohne Galerie.

Für responsive Bilder unterstützt die Extension srcset-Attribute: Der Browser lädt je nach Viewport die passende Bildgrösse. Das TYPO3-Bild-Processing erzeugt die Varianten automatisch. In Kombination mit WebP-Konvertierung (siehe webp-Extension) erreichen PhotoSwipe-Galerien optimale Ladezeiten.

## Problemas frequentes betreffen Konflikte mit anderen Lightbox-Extensions und fehlende Bildgrössen

Das häufigste Problem ist der Konflikt mit einer bereits installierten Lightbox-Extension. Wenn Fancybox und PhotoSwipe gleichzeitig aktiv sind, reagieren beide auf Bild-Klicks und erzeugen doppelte Overlays. A solução: Die alte Lightbox-Extension deaktivieren und deren CSS/JS-Includes aus dem TypoScript-Setup entfernen. Ein grep nach "fancybox" oder "colorbox" in den TypoScript-Dateien zeigt, ob Reste der alten Library noch geladen werden.

Zweites Problem: Fehlende Bildgrössen. PhotoSwipe braucht für den Zoom die tatsächlichen Pixel-Dimensionen des Bildes. Wenn die Extension diese nicht aus den FAL-Metadaten lesen kann, funktioniert der Zoom nicht oder springt auf eine falsche Grösse. A solução: Die FAL-Metadaten aller Galerie-Bilder prüfen. TYPO3 liest width und height beim Upload automatisch aus, aber importierte oder per CLI eingefügte Bilder haben manchmal leere Metadaten.

## PhotoSwipe v5 läuft unter TYPO3 v12, die v13-Kompatibilität erfordert ein Template-Update

Die aktuelle PhotoSwipe-Library ist in Version 5. Die TYPO3-Extension wurde für verschiedene TYPO3-Versionen angepasst und läuft unter v12 stabil. Für TYPO3 v13 ist ein Update der Fluid-Templates und der TypoScript-Konfiguration nötig, weil v13 den AssetCollector-Workflow leicht verändert hat. A Gosign atualiza bei TYPO3-Upgrades alle Frontend-Extensions inklusive Lightbox und prüft, ob die Touch-Gesten auf aktuellen iOS- und Android-Versionen korrekt funktionieren.
---

--- powermail TYPO3 - Formulários e CRM | Gosign ---
> O mais utilizado Formular-Plugin para TYPO3. Formulários de contato, formulários em múltiplas etapas, lógica condicional, exportação PDF, integração com CRM.

## powermail é o sistema de formulários pronto para produção do TYPO3

Entre o Form Framework do core TYPO3 e as ferramentas completas de marketing automation existe, na prática, uma lacuna: equipes editoriais querem construir formulários sem código, com lógica condicional, upload de arquivos, consentimento LGPD (PT: RGPD), encaminhamento a CRM e exportação PDF limpa. É exatamente para isso que o powermail foi construído. A extensão da in2code é o plugin de formulário mais instalado no ecossistema TYPO3 e roda na maior parte dos projetos TYPO3 médios e grandes que a Gosign atende. Desde a primeira versão, há mais de uma década, o powermail se consolidou como o canivete suíço do desenvolvimento de formulários TYPO3 e continua sendo uma escolha válida mesmo quando o Form Framework do core teoricamente seria suficiente.

## Cenários típicos vão de formulários de contato a portais de candidatura

O cenário mais frequente é trivial mas inevitável: formulários de contato em sites corporativos que enviam emails a diferentes departamentos. O powermail permite isso via rotas de destinatário condicionais, sem intervenção de desenvolvedores. Redatores mantêm os campos no backend como um conteúdo de página, incluindo ordem, campos obrigatórios e validação. Uma instalação corporativa típica tem três a cinco variantes de formulário: solicitação geral, contato de imprensa, carreira, suporte e consultoria de produto. Cada variante chega à inbox certa via filtro de destinatário próprio.

Muito mais exigentes são formulários de candidatura em várias etapas, como em instituições públicas e universidades brasileiras. Um portal de candidatura pergunta no passo 1 os dados cadastrais, no passo 2 o curso desejado, no passo 3 históricos escolares via upload e no passo 4 um consentimento LGPD com link para a política de privacidade. O powermail renderiza os quatro passos a partir de um único registro de formulário e guarda o progresso entre os passos em uma sessão, de modo que o candidato possa voltar se precisar. Condições exibem ou ocultam campos conforme respostas anteriores, o que em formulários complexos como pedidos de bolsa ou inscrições em pós-graduação torna uma quantidade de três dígitos de combinações de campo manejável.

Um terceiro cenário que distingue o powermail de extensões mais simples é a integração com CRM e ferramentas de marketing. A arquitetura de finishers permite enviar dados em paralelo a HubSpot, Salesforce, Brevo ou a um webhook próprio antes do email de confirmação ser enviado. Na Gosign, o powermail é também a ferramenta padrão para formulários de leads que alimentam diretamente o processo de vendas. Em um projeto enterprise, conectamos o powermail ao Salesforce Marketing Cloud e simultaneamente encaminhamos via webhook ao sistema interno de tickets, de forma que times de vendas e suporte acessem o contato em paralelo.

## Arquitetura técnica separa definição de formulário, finishers e template

O powermail é formado por três camadas conceituais: a definição do formulário no backend, os finishers executados após o envio e os templates Fluid responsáveis pela renderização. Cada camada é extensível sem fazer fork. Essa separação clara faz do powermail uma ferramenta robusta para projetos TYPO3 de longa vida, nos quais formulários são mantidos e estendidos por anos.

Formulários são criados como registros em tx_powermail_domain_model_form. Cada formulário contém pages (passos), cada page contém fields. Os tipos de campo vão de texto, email, select, radio, file upload até html content e checkboxes de consentimento. A lógica condicional é mantida via módulo Conditions: "Mostrar campo B apenas se campo A tiver valor X".

Finishers são a real força da extensão. O finisher padrão envia emails, grava entradas no banco e gera exportações PDF. Outros finishers podem ser implementados via FinisherInterface: envio por webhook, sincronização CRM, Salesforce, entrega a SAP. A ordem dos finishers é configurável, e cada finisher pode abortar o processo em caso de erro.

Templates ficam como arquivos Fluid no caminho EXT e costumam ser sobrescritos via SiteSet ou site package próprio. Isso significa: um único template overlay global basta para dar design uniforme a todos os formulários de um site. Quem precisa de templates próprios por formulário pode reconfigurar os caminhos de template via TypoScript e manter um conjunto por tipo de formulário.

## Problemas frequentes envolvem spam, LGPD e entrega de email

O tema dominante de suporte em formulários powermail públicos é spam. Out of the box, a extensão traz campos honeypot, verificação de timestamp e um ReCaptcha v3 opcional via ext:powermailrecaptcha. Ainda assim, spam chega ao backend quando a administração não ativa os mecanismos de verificação. Recomendamos combinar em todo formulário honeypot E ReCaptcha, adicionando um finisher de rate limit por IP.

O segundo problema é conformidade com a LGPD. Consentimentos de formulário precisam ser documentados de forma auditável: data, versão da política de privacidade, IP e user-agent. A extensão oferece o Consent Storage, que registra consentimentos separadamente e os torna exportáveis para auditorias.

Em terceiro lugar, entregabilidade de email é tema constante. Emails de confirmação caem em spam porque o remetente não está autenticado. SPF, DKIM e DMARC precisam estar corretamente configurados no nível do servidor de email, e a configuração powermail deve definir um Return-Path e um Reply-To válido. Em instalações grandes, recomendamos adicionalmente um serviço dedicado de email transacional como Brevo, Mailgun ou Amazon SES, para que a taxa de entrega não sofra com a reputação geral do servidor.

## TYPO3 v12 e v13 são totalmente suportados

O powermail fica disponível rapidamente em cada release TYPO3 LTS, porque a in2code mantém a extensão ativamente. A série atual suporta TYPO3 v11, v12 e v13 em paralelo. No upgrade de instalações antigas, os breaking changes afetam sobretudo classes finisher próprias, que precisam ser adaptadas à assinatura de interface atual, e templates Fluid que reagem a mudanças de ViewHelper.

A Gosign migra instalações powermail tipicamente junto com o upgrade do core TYPO3. Antes do salto, verificamos quais finishers e templates próprios existem, quais integrações de terceiros estão conectadas e se variantes antigas de plugin ainda estão em uso. A migração costuma acontecer sem migração de dados, porque a estrutura de registro da definição de formulário permanece estável.

--- powermailrecaptcha TYPO3 - reCAPTCHA | Gosign ---
> Integração do Google reCAPTCHA para Powermail. Proteção contra spam para o plugin de formulários TYPO3 mais utilizado.

## Powermail sem proteção contra spam vira depósito de lixo em semanas

Powermail é de longe a extensão de formulários mais utilizada para TYPO3. Mais de 150.000 instalações ativas (dados: TER, 2026), de formulários de contato a formulários de candidatura até fluxos complexos de múltiplas etapas. O problema: todo formulário publicamente acessível sem CAPTCHA é encontrado mais cedo ou mais tarde por bots. Consequência típica: 200 a 500 entradas de spam por dia, caixas de correio lotadas, estatísticas poluídas e formulários que funcionários acabam ignorando - incluindo as consultas reais.

powermailrecaptcha é o complemento oficial do Powermail que integra Google reCAPTCHA v2 ou v3 nos formulários Powermail. A extensão é mantida pela própria in2code (a desenvolvedora do Powermail), o que garante ciclos de atualização curtos e alta compatibilidade.

## Cenários típicos de uso

**Formulários de contato em sites corporativos.** O cenário padrão: um formulário com nome, e-mail, mensagem e botão de envio. Sem CAPTCHA, chegam diariamente 50 a 300 mensagens de spam, majoritariamente com links para sites farmacêuticos ou de cassino. reCAPTCHA v3 (invisível, baseado em score) é ideal aqui: nenhum clique adicional para o usuário, bots são detectados em segundo plano.

**Formulários de candidatura com upload de arquivo.** Páginas de carreira onde candidatos enviam currículo e carta de apresentação são especialmente vulneráveis a spam, porque bots distribuem malware pela função de upload. reCAPTCHA filtra as solicitações automatizadas. Adicionalmente, deve haver verificação de tipo de arquivo no servidor (apenas PDF, DOCX) e limitação de tamanho (máx. 10 MB).

**Formulários de múltiplas etapas com lógica condicional.** Powermail pode construir formulários com condições: se "Setor = Imobiliário" é selecionado, campos adicionais aparecem. Nesses formulários, um CAPTCHA na última página antes do envio é suficiente. powermailrecaptcha vincula a verificação por padrão ao botão Submit, funcionando também em formulários multi-step.

## Arquitetura técnica

powermailrecaptcha estende o Powermail via Signal/Slot TYPO3 (v11) ou PSR-14 Event (v12+). Ao renderizar o formulário, o JavaScript do reCAPTCHA é incluído (de google.com/recaptcha/api.js). No envio, o token reCAPTCHA é validado no servidor: TYPO3 envia um request POST para `https://www.google.com/recaptcha/api/siteverify` com o token e a Secret Key. O Google responde com um score (v3) ou uma confirmação (v2).

A configuração é feita via constantes TypoScript: Site Key e Secret Key (do console admin Google reCAPTCHA), score limite para v3 (padrão: 0.5), versão do reCAPTCHA (v2 Checkbox, v2 Invisible ou v3).

## Problemas frequentes e soluções

**Preocupações com LGPD (PT: RGPD) pela conexão com Google.** reCAPTCHA carrega JavaScript de servidores Google e transmite o endereço IP do usuário ao Google. Isso representa um risco real de proteção de dados. Solução: carregar reCAPTCHA apenas quando o usuário consentir via banner de cookies. Ou migrar completamente para alternativas: Friendly Captcha (servidores na UE, sem rastreamento), hCaptcha ou uma estratégia pura de honeypot sem serviços externos.

**reCAPTCHA v3 bloqueia usuários reais.** O algoritmo de score é uma caixa-preta. Alguns usuários reais (por exemplo, atrás de VPN, com adblocker, em dispositivos antigos) recebem scores baixos e são bloqueados por engano. Solução: definir o limite não em 0.5, mas em 0.3, e adicionar um campo honeypot. Alternativa: em score baixo, exibir fallback para reCAPTCHA v2 Checkbox em vez de bloquear diretamente.

**Conflito de extensão com Content Security Policy.** Desde TYPO3 v12, o Core suporta Content Security Policies (CSP). JavaScript do reCAPTCHA de google.com deve ser permitido na CSP, caso contrário é bloqueado. Solução: adicionar `script-src` e `frame-src` para `https://www.google.com/recaptcha/` e `https://www.gstatic.com/recaptcha/` na configuração CSP.

## Migração e compatibilidade de versões

powermailrecaptcha suporta TYPO3 v11, v12 e v13 (este último desde Q1 2026). A extensão acompanha o ciclo de release do Powermail.

Para projetos que desejam migrar do reCAPTCHA para uma alternativa mais amigável à proteção de dados, a mudança é gerenciável. Friendly Captcha oferece um plugin Powermail próprio (powermail_friendlycaptcha), que funciona como substituto direto. A Gosign recomenda Friendly Captcha como padrão para novos projetos.

Um aspecto frequentemente negligenciado é a prevenção de spam além de CAPTCHAs. Powermail oferece nativamente um campo honeypot (um campo de formulário invisível que apenas bots preenchem). Em combinação com verificação de tempo (formulário deve estar aberto por pelo menos 3 segundos), é possível filtrar a maior parte do spam automatizado sem serviços externos. A Gosign aplica em projetos com prioridade em conformidade LGPD uma estratégia de três camadas: honeypot e verificação de tempo como primeira camada (0 requests externos), Friendly Captcha como segunda camada (servidores na UE) e análise de conteúdo no servidor como terceira camada (densidade de links, idioma, padrões de spam conhecidos). Essa combinação alcança taxa de detecção de spam acima de 99% sem serviços Google.

Para a migração de powermailrecaptcha para Friendly Captcha, a Gosign calcula 2 a 4 horas por site, incluindo instalação, configuração, teste de todos os formulários e desativação da extensão antiga.

--- Calculadora de preços TYPO3 - Kalkulator | Gosign ---
> Konfiguratoren, Kostenrechner, Angebotsgeneratoren direkt no TYPO3. Desenvolvimento personalizado para lógica de cálculo específica com frontend interativo.

## Preisrechner im Web generieren qualifizierte Leads, aber nur wenn die Kalkulation stimmt

Besucher, die auf einer Website einen Preis berechnen, sind die wertvollsten Leads im B2B-Vertrieb. Sie haben ein konkretes Vorhaben, kennen ihre Anforderungen und erwarten eine belastbare Zahl. Trotzdem arbeiten die meisten TYPO3-Websites mit statischen Preistabellen oder einem "Preis auf Anfrage"-Button, der den Besucher in ein generisches Kontaktformular schickt. pricecal schliesst diese Lücke: Die Extension ermöglicht Konfiguratoren, Kostenrechner und Angebotsgeneratoren direkt in TYPO3, mit spezifischer Kalkulationslogik und einem interaktiven Frontend, das in Echtzeit reagiert.

Der Unterschied zu externen Tools wie Calconic oder Outgrow: Die Daten bleiben auf dem eigenen Server, die Kalkulation ist unter voller Kontrolle, und das Design fügt sich nahtlos in die bestehende Website ein.

## Cenários típicos de uso vão vom Umzugsrechner bis zum Industriekonfigurator

Das zugänglichste Szenario ist der Kostenrechner für Dienstleistungen. Ein Umzugsunternehmen fragt Wohnungsgrösse, Stockwerk, Entfernung und Sonderwünsche (Klavier, Aquarium) ab und zeigt einen Richtpreis. Der Besucher sieht sofort, ob der Service im Budget liegt, und kann direkt ein verbindliches Angebot anfordern. Na prática steigern solche Rechner die Anfragequote um 40 bis 70 Prozent gegenüber einem statischen Kontaktformular, weil der Besucher bereits eine Preiserwartung hat.

Ein zweites Szenario sind Produktkonfiguratoren im verarbeitenden Gewerbe. Ein Fensterhersteller bietet 12 Rahmentypen, 8 Glasarten, 4 Beschlagvarianten und 20 Farben. pricecal berechnet den Preis aus der Kombination und zeigt ihn live an, während der Besucher konfiguriert. Bei 12 x 8 x 4 x 20 = 7.680 möglichen Kombinationen ist eine statische Preisliste unmöglich. Der Konfigurator ersetzt sie durch eine dynamische Berechnung, die der Redakteur über Preis-Matrizen im Backend pflegt.

Drittes Szenario: ROI-Rechner für Software-Produkte. Ein SaaS-Anbieter lässt Besucher Mitarbeiteranzahl, aktuellen Zeitaufwand und Stundensatz eingeben. Der Rechner zeigt die jährliche Ersparnis durch das Produkt. Das ist kein Verkaufstrick, sondern ein Werkzeug, das dem Besucher hilft, die Investition intern zu begründen.

## Arquitetura técnica trennt Kalkulationslogik, Eingabefelder und Ergebnisdarstellung

pricecal ist als Custom Content Element in TYPO3 implementiert. Im Backend definiert der Administrator die Eingabefelder (Slider, Dropdown, Number Input, Checkbox), die Kalkulationsformel und die Ergebnisdarstellung. Die Formel kann einfache Arithmetik (Preis = Menge x Einzelpreis x Faktor) oder komplexere Logik mit Bedingungen (wenn Stockwerk > 3, dann Zuschlag 15%) abbilden.

Das Frontend rendert die Eingabefelder über Fluid-Templates und berechnet den Preis per JavaScript im Browser. Kein Server-Roundtrip bei jedem Slider-Schritt, das Ergebnis aktualisiert sich in Echtzeit. Für komplexere Kalkulationen, etwa wenn Preis-Matrizen oder externe Datenquellen (ERP, Lagerverfügbarkeit) eingebunden werden müssen, kann die Berechnung über einen AJAX-Endpoint an den Server delegiert werden.

Die Ergebnisse lassen sich optional als PDF generieren und per E-Mail versenden. In Kombination mit powermail kann das Kalkulationsergebnis als Hidden Field in ein Kontaktformular übergeben werden, sodass der Vertrieb die exakte Konfiguration des Interessenten sieht.

## Problemas frequentes betreffen Rundungsfehler und die Pflege komplexer Preislogiken

Das häufigste Problem bei Preisrechnern ist die korrekte Rundung. JavaScript-Fliesskomma-Arithmetik liefert bei 0,1 + 0,2 den Wert 0,30000000000000004. Bei Preisen mit zwei Nachkommastellen führt das zu sichtbaren Fehlern. A solução: Alle Berechnungen intern in Cent (Integer) durchführen und erst bei der Anzeige in Euro umrechnen.

Zweites Problem: Die Pflege der Kalkulationslogik. Wenn ein Produktmanager die Preise vierteljährlich anpasst, muss er die Formeln im Backend verstehen. Bei einfachen Kalkulationen (Menge x Preis) ist das trivial. Bei Konfiguratoren mit 50 Parametern und gestaffelten Rabatten wird die Pflege zum Risiko. Wir empfehlen, komplexe Preislogik als TypoScript-Konfiguration oder YAML-Datei auszulagern und versioniert in Git zu pflegen, statt sie im Backend zu bearbeiten.

Drittes Thema: Mobile Bedienbarkeit. Slider sind auf Touchscreens unpräzise, weil der Finger einen grösseren Bereich abdeckt als ein Mauszeiger. Bei Preisrechnern mit feiner Granularität (z.B. Quadratmeter von 10 bis 500) sollten Slider durch Eingabefelder mit Plus/Minus-Buttons ersetzt werden.

## pricecal ist Custom-Entwicklung und damit versionsunabhängig

Da pricecal keine Community-Extension aus dem TER ist, sondern eine Custom-Entwicklung, gibt es keinen externen Release-Zyklus. Die TYPO3-Kompatibilität hängt davon ab, wie die Extension intern implementiert ist. Installationen, die auf Extbase und Fluid basieren, laufen unter TYPO3 v12 und v13 nach Anpassung der Namespace-Deklarationen und der Content-Element-Registrierung. A Gosign utiliza bei neuen Preisrechner-Projekten auf eine Framework-unabhängige Architektur: Die Kalkulationslogik läuft als eigenständiges JavaScript-Modul, das TYPO3 nur als Content-Element einbindet, aber keine Extbase-Abhängigkeit hat.
---

--- Social Feed TYPO3 - Instagram e outros | Gosign ---
> Feeds de redes sociais (Instagram, Facebook, Twitter/X) no TYPO3 einbinden. Baseado em API, cacheado.

## Feeds de redes sociais no site ficam bonitos, mas quebram regularmente por mudanças de API

Equipes de marketing querem exibir posts do Instagram, publicações do Facebook ou tweets do Twitter/X no site da empresa. A ideia é compreensível: conteúdo atual sem esforço editorial, prova social por posts reais, valorização visual por material fotográfico. A prática é diferente. Meta, Twitter/X e TikTok alteram suas APIs regularmente, restringem direitos de acesso ou encerram endpoints gratuitos completamente. Twitter/X aboliu o acesso gratuito à API em 2023 e exige desde então pelo menos 100 USD/mês para direitos de leitura. A Instagram Basic Display API foi substituída pela Instagram Graph API em 2024. Quem opera uma integração de feed social precisa acompanhar essas mudanças ou o feed fica vazio.

pxa_social_feed (desenvolvido pela Pixelant) é a extensão TYPO3 mais conhecida para feeds de redes sociais. Suporta Instagram, Facebook e Twitter/X, armazena dados do feed localmente (em cache) e os renderiza como elemento de conteúdo TYPO3. A extensão é open source e mantida pela comunidade.

## Cenários típicos de uso

**Sites corporativos com feed Instagram na página inicial.** Uma empresa publica 3 a 5 vezes por semana no Instagram e quer exibir os últimos 6 a 12 posts como galeria de imagens na página inicial. pxa_social_feed busca os posts via cronjob (por exemplo, a cada 30 minutos), armazena imagens, legendas e links localmente e os renderiza em um grid configurável. A vantagem sobre um embed (iframe): sem requests externos ao carregar a página, sem pixels de rastreamento, tempo de carregamento mais rápido.

**Páginas de eventos com feed ao vivo.** Conferências, feiras ou festas corporativas usam uma hashtag (ex: #GosignSummit2026). O feed exibe todos os posts públicos com essa hashtag em tempo real (ou quase tempo real com cache de 5 minutos). A moderação ocorre no backend TYPO3: posts individuais podem ser ocultados antes de aparecerem no site.

**Páginas de employer branding.** Departamentos de RH exibem na página de carreiras momentos do cotidiano de trabalho que colaboradores postam no Instagram ou LinkedIn. A integração coleta posts de uma ou várias contas e os curadoria editorialmente. Particularidade: LinkedIn não oferece API aberta para integração de feed, portanto a automação se limita a Instagram e Facebook.

## Arquitetura técnica

pxa_social_feed utiliza as APIs das respectivas plataformas: Instagram Graph API (via token de app Facebook), Facebook Graph API e Twitter/X API v2. Cada plataforma requer autenticação própria: Facebook e Instagram precisam de um Long-Lived User Token (válido por 60 dias, deve ser renovado regularmente), Twitter/X precisa de um Bearer Token (Application-only Auth).

A extensão armazena dados do feed em uma tabela TYPO3 local. Imagens são baixadas e armazenadas como referências FAL. Ao carregar a página, apenas dados locais são renderizados - sem chamadas de API externas. Uma tarefa scheduler busca novos posts e exclui antigos (configurável: manter últimos 50 posts, remover mais antigos).

A saída ocorre via templates Fluid, configurados por TypoScript. Layouts padrão: grid (3-4 colunas), masonry, slider (via inclusão própria de JavaScript). O HTML/CSS pode ser completamente personalizado sem alterar o código da extensão.

Para conformidade com a LGPD (PT: RGPD), o cache local é decisivo: como imagens e textos ficam no próprio servidor, nenhum dado é transmitido ao Meta ou Twitter/X ao carregar a página. Sem pixel de rastreamento, sem necessidade de consentimento de cookies para o feed em si.

## Problemas frequentes e soluções

**Token do Instagram expira, feed fica vazio.** O Long-Lived Token tem vida útil de 60 dias. Se ninguém o renova, a importação para. Solução: configurar um cronjob que renova o token automaticamente via chamada de API. pxa_social_feed oferece desde a versão 4.x uma função de Token-Refresh no backend.

**Feed do Twitter/X não funciona após mudança de API.** Desde 2023 a API Twitter/X é paga. O plano Basic (100 USD/mês) permite ler 10.000 tweets/mês. Para a maioria dos sites corporativos isso é suficiente, mas a relação custo-benefício deve ser avaliada. Solução: verificar se o feed Twitter/X realmente traz tráfego ou engajamento. Se não, remover o canal e manter apenas Instagram/Facebook.

**Imagens não carregam ou ficam pixeladas.** A Instagram Graph API entrega imagens em diferentes tamanhos. pxa_social_feed armazena por padrão a versão entregue pela API. Solução: na configuração da extensão, definir tamanho da imagem como "original" e no template Fluid gerar variantes responsivas via `<f:image>`.

## Migração e compatibilidade de versões

pxa_social_feed suporta TYPO3 v11 e v12. A compatibilidade com TYPO3 v13 está em desenvolvimento comunitário (status abril 2026), mas ainda não foi oficialmente liberada. Para projetos em TYPO3 v13 existem duas opções: aguardar a atualização oficial ou construir uma integração de feed própria como middleware, independente da versão TYPO3.

A Gosign recomenda fundamentalmente pensar integrações de feed social como componente desacoplado: um microserviço ou Cloudflare Worker busca os feeds, armazena como JSON, TYPO3 lê o JSON e renderiza. Isso elimina a dependência de uma extensão TYPO3 e qualquer mudança de API é corrigida em um só lugar, independentemente do CMS.

O esforço total para uma integração de feed social (Instagram, com cache, em conformidade com a LGPD, com moderação no backend) fica entre 2 e 5 dias de desenvolvimento, dependendo se pxa_social_feed é suficiente ou se uma solução personalizada é necessária.

--- RaiseNow TYPO3 - Doações | Gosign ---
> RaiseNow é uma plataforma suíça de doações. A integração TYPO3 permite doações online, doações recorrentes e campanhas. Para ONGs, associações.

## Non-Profit-Organisationen verlieren Spenden, wenn der Spendenprozess die Website verlässt

Jeder Medienbruch kostet Conversion. Wenn ein Besucher auf "Jetzt spenden" klickt und auf eine externe Plattform weitergeleitet wird, brechen je nach Studie 30 bis 50 Prozent ab. RaiseNow ist eine Schweizer Spenden-Plattform, die genau dieses Problem löst: Die TYPO3-Integration bettet den gesamten Spendenprozess direkt in die Website ein. Spendenbetrag, Zahlungsmethode, Adressdaten und Bestätigung laufen in einem eingebetteten Widget, ohne dass der Besucher die Seite verlässt. Für NPOs, Vereine und Stiftungen, die auf TYPO3 setzen, ist das die sauberste Integration zwischen CMS und Spenden-Plattform.

RaiseNow verarbeitet jährlich über 300 Millionen Franken an Spenden und ist in der Schweiz der Marktführer für digitales Fundraising. Die TYPO3-Extension bringt dieses Ökosystem direkt ins Backend.

## Cenários típicos de uso vão von Einmalspenden bis zu Dauerspender-Kampagnen

Das Basisszenario ist die Einmalspende auf der Startseite oder einer Kampagnenseite. Ein Hilfswerk startet eine Spendenkampagne nach einer Naturkatastrophe. Die Landingpage zeigt den Fortschrittsbalken (gesammelt / Ziel) und ein Spendenformular mit vorgeschlagenen Beträgen (25, 50, 100, frei wählbar). Der Besucher spendet per Kreditkarte, TWINT, PostFinance oder PayPal, erhält eine sofortige Bestätigung und eine Spendenquittung per E-Mail. Die gesamte Transaktion dauert unter 60 Sekunden.

Ein zweites, wirtschaftlich wichtigeres Szenario sind Recurring Donations (Dauerspenden). Eine Tierschutzorganisation bietet monatliche Patenschaften: 15 Franken pro Monat für die Pflege eines Tieres. RaiseNow verwaltet die wiederkehrenden Zahlungen, benachrichtigt bei fehlgeschlagenen Lastschriften und bietet dem Spender ein Self-Service-Portal zur Anpassung. Dauerspenden machen bei erfolgreichen NPOs 40 bis 60 Prozent des Gesamtvolumens aus, weil sie planbare Einnahmen erzeugen.

Drittes Szenario: Peer-to-Peer-Fundraising. Ein Sportverein organisiert einen Spendenlauf. Jeder Läufer erstellt eine persönliche Spendenseite, teilt sie in sozialen Netzwerken und sammelt Spenden für den Verein. RaiseNow aggregiert die Beträge, ordnet sie den Läufern zu und zeigt ein Live-Ranking. Die TYPO3-Extension stellt die Kampagnen-Übersicht und die persönlichen Spendenprofile als Content-Elemente bereit.

## Arquitetura técnica nutzt RaiseNow-Widgets per iFrame und API-Callback

Die TYPO3-Extension integriert RaiseNow über ein JavaScript-Widget, das als iFrame in die Seite eingebettet wird. Die Konfiguration (API-Key, Kampagnen-ID, Zahlungsmethoden, Vorschlags-Beträge) wird im TYPO3-Backend als Plugin-Konfiguration gesetzt und per TypoScript an das Widget übergeben.

Nach einer erfolgreichen Spende sendet RaiseNow einen Webhook an einen konfigurierbaren Endpoint. Dieser Webhook kann in TYPO3 verarbeitet werden, um Spenden in einer lokalen Datenbank zu protokollieren, Fortschrittsbalken zu aktualisieren oder Dankes-E-Mails über den TYPO3-eigenen Mailversand auszulösen. Die Zahlungsabwicklung selbst läuft vollständig auf RaiseNow-Infrastruktur, was PCI-DSS-Konformität ohne eigene Zertifizierung ermöglicht.

Die Spendenquittung wird von RaiseNow generiert und enthält alle steuerlich relevanten Angaben. Für Organisationen, die in Deutschland als gemeinnützig anerkannt sind, lässt sich die Quittung mit der Vereins-Steuernummer und dem Freistellungsbescheid versehen.

## Problemas frequentes betreffen LGPD-Konformität und Widget-Styling

Das grösste Thema für deutsche Organisationen ist die LGPD-Konformität. RaiseNow ist ein Schweizer Unternehmen und verarbeitet Zahlungsdaten auf Schweizer Servern. Seit dem Angemessenheitsbeschluss der EU-Kommission gilt die Schweiz als sicheres Drittland, aber die política de privacidade muss dennoch transparent ausweisen, welche Daten an RaiseNow übermittelt werden. Organisationen, die auf Nummer sicher gehen wollen, holen eine explizite Einwilligung über einen Consent-Layer ein, bevor das RaiseNow-Widget geladen wird.

Zweites Problem: Das Widget-Styling. RaiseNow-Widgets haben ein eigenes CSS, das sich nicht vollständig von aussen überschreiben lässt. Farben, Schriftarten und Button-Styles können über die RaiseNow-Konfiguration angepasst werden, aber das Layout des Formulars ist fixiert. Für Organisationen mit strengen CI-Vorgaben kann das ein Kompromiss sein. Die Alternative ist ein Custom-Spendenformular, das die RaiseNow-API direkt anspricht, was allerdings PCI-DSS-Anforderungen an die eigene Infrastruktur stellt.

## RaiseNow wird aktiv weiterentwickelt, die TYPO3-Extension braucht manuelle Pflege

RaiseNow selbst wird kontinuierlich weiterentwickelt. Neue Zahlungsmethoden (Apple Pay, Google Pay) und Features (QR-Rechnungen) werden regelmässig ergänzt. Die TYPO3-Extension ist jedoch ein Community-Projekt und wird nicht von RaiseNow offiziell gepflegt. Isso significa: Wenn TYPO3 v13 eine Änderung in der Plugin-Registrierung einführt, muss die Extension manuell angepasst werden. Organisationen, die RaiseNow langfristig in TYPO3 einsetzen, sollten die Extension in ihrem eigenen Repository forken und bei TYPO3-Upgrades mitpflegen. A Gosign assume diese Pflege im Rahmen von Wartungsverträgen und prüft bei jedem TYPO3-Update die RaiseNow-Kompatibilität.
---

--- rapidmail TYPO3 - Integração de newsletter | Gosign ---
> rapidmail no TYPO3 integrieren: Sincronização de assinantes, Double-Opt-In, segmentação. acelerado com IA, em conformidade com a LGPD.

## rapidmail é a resposta pragmática de newsletter para projetos TYPO3 sensíveis à LGPD

Quem opera uma newsletter com segurança jurídica na Europa, e quer atender também expectativas brasileiras quanto à LGPD, cedo ou tarde acaba em provedores europeus com servidores na UE. O rapidmail é um dos mais usados: localização de servidores na Alemanha, suporte em alemão, modelos de preço claros, API sólida. Para sites TYPO3 que coletam inscrições em newsletter diretamente no frontend e querem que os destinatários cheguem automaticamente a listas e segmentos, a integração desse serviço é uma tarefa padrão. Os resultados, porém, costumam ser decepcionantes, porque a extensão oficial do TYPO3 só cobre funções básicas e projetos com exigências reais batem rápido no teto.

O público-alvo são empresas de médio porte, associações, concessionárias, universidades, ONGs e editoras que querem construir a comunicação com clientes em uma plataforma em conformidade com a LGPD. Um caso típico: uma concessionária de energia regional com 80.000 clientes residenciais quer enviar newsletters direcionadas com quatro segmentos (pessoa física, pessoa jurídica, clientes de incentivo, contatos de imprensa) e obter a segmentação automaticamente de grupos de usuário TYPO3.

## Cenários típicos de uso

Um primeiro cenário é a simples jornada de inscrição via Powermail. Uma associação quer inserir visitantes de seu site TYPO3 na newsletter. O finisher Powermail passa nome, email e uma marca de segmento à API rapidmail, o rapidmail envia o email de confirmação, e após o clique no link de confirmação o contato é ativado na lista de destinatários correspondente.

Um segundo cenário é a sincronização de grupos de usuário do TYPO3 para segmentos no rapidmail. Uma universidade mantém no intranet TYPO3 papéis como estudantes, ex-alunos, colaboradores. Cada mudança de papel deve atualizar automaticamente a atribuição de segmento no rapidmail, para que os envios cheguem exatamente ao público certo, sem manutenção de dados duplicada.

Um terceiro cenário é a manutenção de participantes de evento. Uma editora organiza dez conferências setoriais por ano e quer passar os participantes automaticamente a uma trilha de comunicação subsequente. O registro acontece em um formulário TYPO3, a API grava o participante em uma lista de evento, o rapidmail dispara uma campanha drip automática com três emails.

Um quarto cenário é a sincronização de descadastramentos. Quando um leitor sai via link de newsletter no rapidmail, o profile center TYPO3 precisa assumir o status, para que o usuário, no próximo login, não veja novamente "Newsletter ativa". Isso exige um canal de retorno: o rapidmail informa o cancelamento via webhook, o TYPO3 confirma e atualiza o grupo de usuário.

## Arquitetura técnica

O rapidmail disponibiliza uma API REST com autenticação OAuth. A integração TYPO3 acontece via finisher Powermail, uma extensão do Form Framework ou um serviço Extbase próprio que acessa a API. A Gosign normalmente usa uma classe de serviço enxuta que encapsula as chamadas de API e está disponível via Dependency Injection em controllers, finishers e tarefas do scheduler.

Para a sincronização contínua de grupos de usuário, tipicamente uma tarefa do scheduler é configurada para rodar a cada 15 minutos com delta updates para o rapidmail. A detecção de delta usa um campo de auditoria interno do TYPO3 (última alteração por usuário) ou uma comparação de hash baseada na resposta da API. É importante que cada transferência seja idempotente, para que uma reexecução após erro não gere duplicatas.

O Double Opt-In é totalmente processado no lado do rapidmail: o TYPO3 registra um contato, o rapidmail envia o email de confirmação, o leitor confirma, o rapidmail ativa o contato. O TYPO3 não precisa fornecer nada próprio para isso, é importante apenas que a página TYPO3 mostre ao usuário uma página intermediária compreensível ("Confirme sua inscrição na sua caixa de entrada").

## Problemas frequentes e soluções

O primeiro problema é a falta de tratamento de bounces. Quem não avalia as respostas da API não percebe que o rapidmail rejeita permanentemente certos endereços. A solução é um log das respostas da API em uma tabela TYPO3 própria mais um alinhamento periódico com as listas de bounce que o rapidmail disponibiliza via API.

O segundo problema são atribuições erradas de segmentação. Quando um contato cai em vários grupos de usuário, cada um apontando para listas rapidmail diferentes, surgem estados inconsistentes. A solução é uma lógica de mapeamento clara 1:1 ou 1:n, definida de forma limpa antes da implementação e cravada a frio no service layer.

O terceiro problema é a violação do rate limit da API. O rapidmail limita o uso da API. Em uma migração inicial de 20.000 contatos em uma única rodada do scheduler, o job invariavelmente bate na trava. A solução é um import em chunks com 100 contatos por batch e controle de pausa entre os batches.

Um quarto problema é a ambiguidade de correspondência em perfis duplicados. Quando um usuário se cadastra várias vezes com escritas diferentes de email (com ponto, sem ponto, maiúsculas, minúsculas), surgem duplicatas no rapidmail e estados inconsistentes entre TYPO3 e o sistema de newsletter. A solução é uma normalização do endereço de email antes de cada chamada de API (lowercase, trim de whitespace, regra de ponto para endereços Gmail aplicada ou ignorada de forma consistente).

## Migração e compatibilidade de versões

A integração, como custom extension, é amplamente independente da versão TYPO3: roda sem problemas em TYPO3 v11, v12 e v13, desde que o código do cliente API use HTTP clients modernos (Guzzle) e Dependency Injection. No upgrade de uma integração existente, o ponto de dor mais frequente é a migração de hooks TYPO3 para middlewares PSR-15, um esforço que a Gosign costuma concluir com análise de código apoiada por IA em poucos dias.

No lado do rapidmail, a API muda devagar, mas não sem quebras: entre major versions, endpoints individuais foram renomeados, campos reestruturados ou processos de autenticação modernizados. Quem leva uma integração antiga de 2018 ou 2020 ao estado atual deve reservar uma sprint curta para a atualização da API e rodar os testes contra uma lista de staging no rapidmail antes de tocar em produção. A Gosign mantém para essas tarefas de refresh um checklist padrão que cobre os tropeços usuais (autenticação, paginação, formato de resposta de erro) e torna a migração reproduzível.

--- Plugin de receitas TYPO3 | Gosign ---
> Rezepte-Extension para TYPO3: Ingredientes, etapas de preparo, valores nutricionais, porções. Com marcação Schema.org Recipe para Google Rich Snippets (Sterne,.

## Rezepte ohne Schema.org-Markup verschenken die wertvollsten Positionen in den Google-Suchergebnissen

Rezept-Suchanfragen gehören zu den wenigen Bereichen, in denen Google Rich Snippets mit Bild, Bewertung, Kochzeit und Kalorien anzeigt. Websites ohne korrektes Schema.org-Recipe-Markup erscheinen als einfacher blauer Link unter den visuell dominanten Rich Results. Die TYPO3 Recipe-Extension strukturiert Rezepte mit allen Feldern, die Google für Rich Snippets erwartet: Zutaten, Zubereitungsschritte, Nährwerte, Portionen, Zubereitungszeit, Schwierigkeitsgrad. Das Schema.org-Markup wird automatisch im JSON-LD-Format ausgegeben, ohne dass Redakteure HTML bearbeiten müssen.

Für Food-Blogs, Verlage mit Rezeptrubriken und Lebensmittelhersteller mit Rezeptdatenbanken ist das der Unterschied zwischen Sichtbarkeit und Unsichtbarkeit in der Google-Suche.

## Cenários típicos de uso abrangem Food-Blogs, Produktwebsites und Gesundheitsportale

Das häufigste Szenario ist der Food-Blog oder das Online-Magazin mit Rezeptrubrik. Ein Verlag publiziert wöchentlich fünf neue Rezepte. Jedes Rezept wird im TYPO3-Backend als strukturierter Datensatz angelegt: Titel, Beschreibung, Zutatenliste mit Mengenangaben, Zubereitungsschritte als nummerierte Liste, Zeitangaben (Vorbereitung, Kochzeit, Gesamtzeit), Nährwerte pro Portion und ein Titelbild. Die Extension generiert daraus eine Detailseite mit korrektem Schema.org-Markup. Google zeigt in den Suchergebnissen das Bild, die Sterne-Bewertung, die Gesamtzeit und die Kalorienzahl.

Ein zweites Szenario sind Produktwebsites von Lebensmittelherstellern. Ein Olivenöl-Produzent zeigt zu jedem Produkt passende Rezepte. Die Rezepte verlinken auf das Produkt, das Produkt verlinkt auf die Rezepte. Diese bidirektionale Verknüpfung stärkt sowohl die Produktseite als auch die Rezeptseite in der Google-Bewertung.

Drittes Szenario: Gesundheitsportale und Ernährungsberatungen. Hier stehen die Nährwertangaben im Vordergrund. Ein Diabetes-Portal zeigt Rezepte mit Broteinheiten, glykämischem Index und Kohlenhydraten pro Portion. Die Extension erlaubt Custom Fields, sodass diese medizinisch relevanten Werte als strukturierte Daten erfasst und im Frontend prominent angezeigt werden.

## Arquitetura técnica nutzt Extbase-Records mit automatischem JSON-LD-Output

Die Extension registriert einen eigenen Record-Typ für Rezepte in der TYPO3-Datenbank. Jeder Record enthält Felder für Titel, Beschreibung, Zutaten (als Inline-Relational-Records), Schritte (als sortierbare Liste), Zeiten (prepTime, cookTime, totalTime im ISO-8601-Format), Nährwerte (Kalorien, Fett, Kohlenhydrate, Protein) und Bilder über FAL.

Das Frontend-Rendering läuft über Fluid-Templates, die das Rezept als HTML-Seite darstellen und gleichzeitig ein JSON-LD-Script-Tag mit dem Schema.org/Recipe-Markup in den Head der Seite schreiben. Das Markup folgt der Google-Spezifikation: name, image, author, datePublished, description, prepTime, cookTime, totalTime, recipeYield, recipeIngredient, recipeInstructions und nutrition.

Die Listenansicht zeigt Rezepte als Kacheln mit Bild, Titel, Gesamtzeit und Bewertung. Filter nach Kategorie (Vorspeise, Hauptgericht, Dessert), Diätform (vegetarisch, vegan, glutenfrei) und Zubereitungszeit sind über TypoScript konfigurierbar.

## Problemas frequentes betreffen fehlende Pflichtfelder und ungültige Zeitformate

Das grösste Problem für die Rich-Snippet-Darstellung sind fehlende Pflichtfelder. Google verlangt mindestens name, image und recipeInstructions. Wenn ein Redakteur ein Rezept ohne Bild oder ohne Zubereitungsschritte anlegt, wird das Schema.org-Markup zwar ausgegeben, aber Google ignoriert es und zeigt keinen Rich Snippet. A solução: Im TYPO3-Backend Pflichtfeld-Validierung aktivieren, sodass Rezepte ohne Bild und ohne mindestens einen Zubereitungsschritt nicht gespeichert werden können.

Zweites Problem: Ungültige Zeitformate. Schema.org erwartet ISO-8601-Duration (PT30M für 30 Minuten, PT1H15M für 1 Stunde 15 Minuten). Wenn die Extension die Redakteur-Eingabe "30 min" nicht korrekt in PT30M umwandelt, scheitert die Validierung im Google Rich Results Test. Die meisten Recipe-Extensions bieten dafür separate Eingabefelder für Stunden und Minuten, die intern in ISO-8601 konvertiert werden.

Drittes Thema: Duplicate Content bei Rezepten, die auf mehreren Seiten eingebettet sind. Wenn dasselbe Rezept auf der Kategorieseite und der Detailseite vollständig angezeigt wird, erzeugt das zwei Seiten mit identischem Schema.org-Markup. Google wertet das als Duplicate. A solução: Auf Kategorieseiten nur Teaser zeigen und das vollständige Schema.org-Markup ausschliesslich auf der Detailseite ausgeben.

## Die Extension läuft unter TYPO3 v11 und v12, für v13 ist ein Extbase-Update nötig

Recipe-Extensions im TYPO3-Ökosystem werden von verschiedenen Anbietern gepflegt. Die Kompatibilität mit TYPO3 v12 ist bei aktiv gewarteten Extensions gegeben. Für TYPO3 v13 sind typischerweise Anpassungen an der Extbase-Model-Konfiguration und den TCA-Definitionen nötig, weil v13 einige veraltete TCA-Typen entfernt hat. A Gosign recomenda bei Rezept-Websites, die Schema.org-Ausgabe nach jedem TYPO3-Update mit dem Google Rich Results Test zu validieren, um sicherzustellen, dass die Markup-Qualität erhalten bleibt.
---

--- registeraddress TYPO3 - Assinatura de newsletter | Gosign ---
> Cadastro de newsletter via tt_address no TYPO3. Gerenciamento de assinantes diretamente no CMS sem serviço de newsletter externo.

## Newsletter-Registrierung ohne externe Dienste spart Kosten und hält Daten unter eigener Kontrolle

Mailchimp, Brevo, Rapidmail: Für jede Newsletter-Registrierung zahlen Organisationen pro Subscriber und pro versendeter E-Mail. Bei 10.000 Abonnenten summiert sich das auf 100 bis 300 Euro monatlich, nur für die Verwaltung der Adressen. registeraddress bietet eine Alternative: Newsletter-Registrierung direkt in TYPO3 über die bewährte tt_address-Tabelle. Subscriber-Management, Double-Opt-In, Abmelde-Link und em conformidade com a LGPD (PT: RGPD) Einwilligungsdokumentation laufen vollständig im CMS, ohne dass ein externer Dienst Zugriff auf die Abonnentendaten bekommt.

Für Vereine, kleine Verlage und öffentliche Einrichtungen mit Budgetrestriktionen ist das eine valide Architektur, vor allem dann, wenn der Newsletter-Versand über einen günstigen SMTP-Relay-Dienst wie Amazon SES (0,10 Dollar pro 1.000 E-Mails) oder den eigenen Mailserver läuft.

## Cenários típicos de uso abrangem Vereins-Newsletter, Intranet-Verteiler und Event-Anmeldungen

Das häufigste Szenario ist der klassische Vereins-Newsletter. Ein Sportverein mit 2.000 Mitgliedern bietet auf seiner TYPO3-Website ein Anmeldeformular. Besucher tragen ihre E-Mail-Adresse ein, erhalten eine Double-Opt-In-Mail, bestätigen und werden in die tt_address-Tabelle eingetragen. Der Verein versendet monatlich einen Newsletter über die direct_mail-Extension oder einen externen Versanddienst, der die Adressen aus tt_address importiert. registeraddress kümmert sich ausschliesslich um die Registrierung und Abmeldung, nicht um den Versand selbst.

Ein zweites Szenario sind Intranet-Verteiler in Unternehmen. Mitarbeiter melden sich für interne Informations-Newsletter an, etwa "Standort München - Kantinen-Menü" oder "IT-Wartungsfenster". Da die Daten das Unternehmensnetzwerk nicht verlassen dürfen, ist ein externer Newsletter-Dienst ausgeschlossen. registeraddress verwaltet die Anmeldungen lokal in der TYPO3-Datenbank.

Drittes Szenario: Event-Anmeldungen mit E-Mail-Bestätigung. Eine Bibliothek bietet Veranstaltungen an und nutzt registeraddress als leichtgewichtiges Anmeldeformular. Die Bestätigungsmail nach dem Double-Opt-In enthält Datum, Uhrzeit und Ort der Veranstaltung. Das ist keine vollwertige Event-Management-Lösung, aber für Einrichtungen mit fünf bis zehn Veranstaltungen pro Monat ausreichend.

## Arquitetura técnica baut auf tt_address und dem Double-Opt-In-Workflow

registeraddress ist als Extbase-Plugin implementiert und nutzt die tt_address-Tabelle als Datenbank. Jede Registrierung durchläuft einen dreistufigen Prozess: Formular-Eingabe, Double-Opt-In-Mail mit Bestätigungslink, Aktivierung des Eintrags nach Klick auf den Link. Der Bestätigungslink enthält einen kryptographisch signierten Token, der nach einer konfigurierbaren Zeitspanne (Standard: 48 Stunden) abläuft.

Die Extension registriert ein Frontend-Plugin, das über TypoScript konfiguriert wird: Pflichtfelder, optionale Felder (Name, Firma, Anrede), Bestätigungstext, E-Mail-Templates für Double-Opt-In und Willkommensmail. Die Fluid-Templates sind per SiteSet überschreibbar, sodass das Formular ins Design der Website passt.

Für die LGPD-Konformität speichert registeraddress den Zeitpunkt der Einwilligung, die IP-Adresse, den User-Agent und die Version der política de privacidade, auf die im Formular verlinkt wurde. Bei einer Behördenanfrage lässt sich nachweisen, wann und unter welchen Bedingungen der Subscriber zugestimmt hat.

Abmeldungen laufen über einen Link im Newsletter-Footer, der den tt_address-Eintrag deaktiviert (nicht löscht), sodass die Einwilligungshistorie erhalten bleibt. Endgültige Löschungen gemäss Art. 17 LGPD (Recht auf Löschung) können über ein separates Löschformular oder manuell im Backend erfolgen.

## Problemas frequentes betreffen Double-Opt-In-Mails im Spam und veraltete tt_address-Versionen

Das dominierende Problem ist die Zustellbarkeit der Double-Opt-In-Mail. Wenn die Bestätigungsmail im Spam-Ordner landet, schliesst der Subscriber die Registrierung nie ab. Die Ursachen sind fast immer server-seitig: fehlender SPF-Record, kein DKIM-Signatur, kein DMARC-Policy. registeraddress selbst kann die Zustellbarkeit nicht verbessern, weil das ein Mailserver-Thema ist. Wir empfehlen, vor dem Launch eines Newsletter-Formulars die E-Mail-Authentifizierung mit mail-tester.com zu prüfen.

Zweites Problem: Inkompatibilität mit älteren tt_address-Versionen. registeraddress setzt auf bestimmte Felder in der tt_address-Tabelle. Wenn tt_address ein Major-Update veröffentlicht und Felder umbenennt oder entfernt, kann registeraddress die Einträge nicht mehr korrekt schreiben. A solução: tt_address und registeraddress immer gemeinsam aktualisieren und nach dem Update einen Testdurchlauf des gesamten Registrierungsprozesses machen.

Drittes Thema: Bot-Registrierungen. Ohne Schutzmechanismus füllen Bots das Formular mit Fake-Adressen und erzeugen Tausende von Double-Opt-In-Mails, die den Mailserver belasten und die Sender-Reputation schädigen. registeraddress unterstützt Honeypot-Felder und kann mit sr_freecap oder hcaptcha kombiniert werden, um Bots abzuwehren.

## TYPO3 v12 wird unterstützt, v13-Kompatibilität erfordert ein tt_address-Alignment

registeraddress läuft unter TYPO3 v11 und v12 stabil, vorausgesetzt tt_address ist in einer kompatiblen Version installiert. Für TYPO3 v13 hängt die Kompatibilität sowohl von registeraddress als auch von tt_address ab, da beide Extensions unabhängig gepflegt werden. A Gosign verifica bei TYPO3-Upgrades die gesamte Newsletter-Kette (Registrierung, Adressverwaltung, Versand) auf Kompatibilität und empfiehlt bei Bedarf den Umstieg auf einen externen Newsletter-Dienst mit API-Anbindung, wenn die TYPO3-native Lösung nicht mehr gepflegt wird.
---

--- rflipbook TYPO3 - Livro digital interativo | Gosign ---
> rflipbook para TYPO3: PDFs como flipbooks interativos. Configuração, otimização de performance e alternativas modernas.

## rflipbook transforma catálogos e brochuras em uma experiência de folheamento, e é a solução mais pragmática para times de conteúdo quando PDFs não devem só ser linkados, mas permanecer experimentáveis no contexto do site

Quem mantém um catálogo de várias páginas, um relatório anual ou uma revista para clientes como PDF está diante de um dilema: como download, o documento fica em um beco sem saída, o usuário sai do site e raramente volta. O rflipbook resolve isso renderizando cada página PDF como canvas e replicando no navegador o efeito clássico de folheamento do mundo impresso. A extensão atende a um problema concreto de publishing: times de marketing, imprensa e relações com investidores querem reaproveitar digitalmente ativos de print existentes sem traduzi-los para HTML. O rflipbook torna esse desvio desnecessário.

Vale notar que o rflipbook não é só técnica de apresentação, mas também sinal de conteúdo. Um site que mantém catálogos e relatórios atuais como flipbook aparece cuidado aos olhos de possíveis clientes, em contraste com diretórios de download abandonados com documentos de anos diversos. Editorialmente, a introdução também exige esclarecer quem atualiza qual PDF e quando.

## Cenários típicos de uso

O caso mais frequente é o catálogo B2B de produto. Uma indústria brasileira de máquinas mantém seu catálogo geral no InDesign, exporta um PDF de 80 páginas e o incorpora via rflipbook na página de produto. Para a redação nada muda, para o visitante um download seco vira uma experiência de folhear com página de prévia e função de busca.

O segundo caso de uso são relatórios anuais e de sustentabilidade. Empresas listadas em bolsa, fundações e associações publicam anualmente relatórios extensos que não são reescritos. O rflipbook incorpora o PDF pronto diretamente na página de RI e faz a ponte entre a redação clássica e o time web.

Terceiro caso: revistas de clientes e colaboradores. Universidades, prefeituras ou empresas de médio porte usam o rflipbook para disponibilizar sua revista impressa como edição digital, frequentemente com função de arquivo e edições multilíngues por ano.

## Arquitetura técnica

O rflipbook se integra como extensão TYPO3 clássica via um content element no módulo de página. Redatores fazem upload do PDF no FAL storage, vinculam ao content element e definem no backend parâmetros como cor de fundo, página inicial e botão de download. No frontend, uma biblioteca JavaScript como Turn.js ou uma biblioteca comparável de canvas rendering assume a renderização propriamente dita. O PDF.js é frequentemente usado como parser, para decompor as páginas PDF em bitmaps individuais.

A cadeia de dependências é modesta: o rflipbook traz as bibliotecas JavaScript no pacote da extensão, a extensão em si não requer pacotes PHP adicionais. A configuração é feita via TypoScript para defaults globais e via FlexForm do content element para ajustes específicos de página. Quem trabalha com EXT:fluid_styled_content pode puxar o template via Fluid overrides para o próprio site package e adaptar à identidade visual.

Crítico é o relacionamento com o asset handling. PDFs grandes devem ser pré-renderizados no servidor em JPGs individuais, caso contrário o navegador carrega tudo sincronamente na primeira chamada. Lazy page loading não é função padrão, mas pode ser adicionado por uma pipeline de renderização própria.

## Problemas frequentes e soluções

O problema mais frequente é tempo de carregamento. Um catálogo de 40 páginas com fotos em alta resolução gera facilmente um initial payload de vários megabytes, o que significa Lighthouse scores no vermelho e Core Web Vitals ruins. A solução não está na extensão em si, mas antes dela: reduzir PDFs antes do upload para a resolução de tela realmente necessária, idealmente via Ghostscript ou uma pipeline de build no servidor, e carregar apenas as primeiras duas ou três páginas na chamada inicial.

Segundo problema: apresentação em dispositivos móveis. O efeito de folheamento funciona mal em touchscreens com menos de 400 pixels de largura, e redatores reclamam de páginas ilegíveis. Solução pragmática: via media query CSS, trocar em dispositivos móveis do flipbook para um PDF.js viewer simples com scroll vertical. A experiência do usuário fica mais honesta, o tempo de carregamento melhora.

Terceiro problema: acessibilidade. Leitores de tela não conseguem ler PDFs renderizados em canvas, o que vira problema de compliance em órgãos públicos e instituições públicas. Aqui só ajuda uma abordagem dupla: o flipbook como complemento visual, ao lado obrigatoriamente um link direto ao PDF original e idealmente uma versão HTML dos conteúdos principais. As normas brasileiras de acessibilidade digital e as diretrizes do e-MAG exigem isso expressamente.

## Migração e compatibilidade de versões

O rflipbook é uma extensão consolidada, mas não mais desenvolvida ativamente. Para TYPO3 v11 existe uma versão operacional, em v12 e v13 ela só roda com ajustes manuais no ext_emconf.php e no schema de configuração de serviço. Quem começa hoje deve se perguntar se uma alternativa mais leve não é a melhor escolha: um PDF.js viewer enxuto, páginas HTML estáticas geradas do conteúdo PDF ou um serviço headless de flipbook incorporado como iframe. A decisão depende da frequência com que o documento muda e da importância do efeito visual de folheamento para a marca.

Quem permanece em TYPO3 v11 não deve ver o rflipbook como solução definitiva. No máximo no upgrade para v12, uma decisão é necessária, e o tempo de preparação para isso deve ser planejado cedo. Um projeto de migração típico abrange a análise de todas as ocorrências de flipbook no acervo, a decisão por caso (versão HTML estática, viewer PDF leve ou manutenção como flipbook), a execução e o treinamento editorial. Quem encara o projeto estrategicamente usa a migração também para uma limpeza de assets: catálogos desatualizados são arquivados, documentos nas versões atuais são reincorporados e metadados são uniformizados.

A Gosign acompanha os dois caminhos: continuidade do rflipbook em versões modernas do TYPO3 e migração para alternativas mais performáticas. A análise com suporte de IA ajuda a encontrar a arquitetura certa para o caso de conteúdo concreto, em vez de entregar uma resposta padrão.

--- FontAwesome CKEditor TYPO3 | Gosign ---
> Inserir ícones FontAwesome diretamente no texto rich do CKEditor. A Gosign também assessora sobre sistemas de ícones SVG como alternativa mais performática.

## Por que FontAwesome no CKEditor beneficia editores, mas custa 300 KB de performance

Editores querem colocar ícones ao lado de títulos, em tabelas e entre parágrafos de texto. Sem ajuda técnica, copiam imagens de ícones como inline images no RTE - com layout quebrado e tamanho inconsistente como resultado. rte_ckeditor_fontawesome resolve o problema de forma limpa: editores escolhem ícones do catálogo FontAwesome diretamente no CKEditor via botão de diálogo e os inserem como tag `<i>` no richtext. Os ícones escalam automaticamente com o tamanho do texto, são ajustáveis em cor e funcionam em qualquer elemento de conteúdo.

O preço: toda a biblioteca FontAwesome (aprox. 300 KB como webfont ou 180 KB como SVG sprite) é carregada em cada página, mesmo que apenas 3 ícones sejam usados. Para sites com foco em performance, isso é um overhead perceptível.

## Cenários típicos de uso

**Listas com ícones em descrições de serviços.** Um prestador de serviços descreve suas ofertas com listas de ícones: check antes de cada vantagem, engrenagem antes de cada etapa do processo, ícone de telefone antes do número de contato. O editor insere os ícones diretamente no CKEditor, sem precisar pedir a um desenvolvedor.

**Tabelas comparativas de recursos.** Gerentes de produto mantêm tabelas comparativas no CKEditor. Em vez de "Sim" e "Não", usam ícones de check verde e X vermelho. rte_ckeditor_fontawesome disponibiliza esses ícones via catálogo FontAwesome. A tabela torna-se visualmente compreensível imediatamente.

**Templates de newsletter com ícones.** Empresas que mantêm conteúdo de newsletter no backend TYPO3 e enviam via extensão de newsletter usam ícones FontAwesome para atratividade visual. Como os ícones são inseridos como tags `<i>`, funcionam em clientes de e-mail que suportam webfonts.

## Arquitetura técnica

rte_ckeditor_fontawesome estende o CKEditor no backend TYPO3 com um plugin adicional. O plugin registra um botão na toolbar do CKEditor que abre um diálogo de seleção.

A integração funciona em três níveis: plugin CKEditor (JavaScript para CKEditor 4 no TYPO3 v10/v11 ou CKEditor 5 no TYPO3 v12+, com diálogo de seleção de ícones com função de busca), saída HTML (ao inserir, um tag `<i>` com as classes CSS correspondentes é escrito no richtext: `<i class="fas fa-check"></i>`) e renderização frontend (para que os ícones sejam visíveis no frontend, a biblioteca CSS FontAwesome deve estar carregada no site - a extensão não inclui os assets frontend).

Observação importante sobre a versão CKEditor: TYPO3 v12 troca de CKEditor 4 para CKEditor 5. A arquitetura de plugins mudou fundamentalmente. Plugins rte_ckeditor_fontawesome para CKEditor 4 não funcionam no CKEditor 5.

## Problemas frequentes e soluções

**Ícones não são exibidos no frontend.** Causa mais frequente: CSS FontAwesome não está incluído no template frontend. A extensão cuida apenas da parte backend (seleção de ícones no CKEditor). A exibição frontend requer que `fontawesome.min.css` e os arquivos de fonte correspondentes sejam carregados no template. Solução: adicionar FontAwesome como include CSS via TypoScript.

**Ícones aparecem como quadrados vazios.** Os arquivos de fonte (woff2, woff) não estão sendo carregados corretamente. Frequentemente o caminho no arquivo CSS está mal configurado, ou o servidor web bloqueia arquivos de fonte (headers CORS ausentes em integração via CDN). Solução: hospedar FontAwesome localmente em vez de via CDN. Isso evita problemas de CORS e é mais conforme com a LGPD (PT: RGPD).

**Impacto de performance por FontAwesome.** Uma instalação FontAwesome completa carrega mais de 300 KB (todas as categorias de ícones). Se o site usa apenas 10 ícones, 290 KB são desperdiçados. Solução: usar subsetting FontAwesome - compilar apenas os ícones utilizados em um arquivo de fonte personalizado. Alternativa: migrar para um sistema de ícones SVG que incorpora apenas os ícones realmente usados como inline SVG.

## Migração e compatibilidade de versões

rte_ckeditor_fontawesome está disponível como extensão estável para TYPO3 v10 e v11 (CKEditor 4). Para TYPO3 v12 (CKEditor 5) existem adaptações, pois a arquitetura de plugins é completamente nova.

Para TYPO3 v13 e além, a Gosign recomenda uma reavaliação fundamental da abordagem. Em vez de carregar FontAwesome como webfont, sites modernos usam sistemas de ícones SVG: cada ícone é incorporado como inline SVG, apenas os ícones usados são carregados, o tamanho do arquivo cai de 300 KB para menos de 10 KB.

O esforço de migração de FontAwesome para ícones SVG é tipicamente de 2 a 3 dias: criar SVG sprite, adaptar widget CKEditor, substituir tags `<i>` existentes no conteúdo por referências `<svg>`. A Gosign automatiza a última etapa via script de migração que identifica todos os tags `<i class="fa-*">` no banco de dados e os reescreve.

Na decisão entre FontAwesome e ícones SVG, vale olhar os números: FontAwesome Free contém mais de 2.000 ícones. Um site corporativo típico usa de 15 a 30 deles. O restante todos os visitantes pagam em tempo de carregamento. Um SVG sprite customizado com 30 ícones pesa 8 a 15 KB - um cinquentésimo da biblioteca FontAwesome completa.

--- rte_ckeditor_image TYPO3 - Imagens no RTE | Gosign ---
> rte_ckeditor_image: Inserir e editar imagens no CKEditor. Saída responsiva, solução de problemas, alternativas.

## rte_ckeditor_image traz gerenciamento profissional de imagens ao Rich Text Editor

O CKEditor do TYPO3 só permite inserções simples de imagem via img tag, sem ligação ao File Abstraction Layer e sem variantes responsivas. Para redações que inserem imagens regularmente em artigos, news ou textos de revista, isso não basta: elas precisam de recorte, escala, alt text, copyright, destino de link e, sobretudo, saída srcset. O rte_ckeditor_image da Netresearch complementa o CKEditor com exatamente essas funções e o integra de forma limpa ao FAL. Em todo projeto TYPO3 com imagens editorialmente mantidas em texto corrido, a extensão é há anos a ferramenta padrão e está entre os auxiliares editoriais mais instalados do ecossistema.

## Cenários típicos estão em redações com alto volume de imagens

Revistas online e páginas de news corporativas são o público-alvo clássico. Uma revista brasileira com 200 artigos por ano insere por matéria de duas a cinco imagens no texto corrido, além de imagens de teaser e cabeçalho. Sem o rte_ckeditor_image, a redação teria que aceitar uma troca de elemento de conteúdo para cada imagem inline e interromper o fluxo de texto. Com a extensão, ela insere a imagem diretamente via botão na toolbar, escolhe a referência FAL, define alt text e legenda e volta a escrever sem troca de contexto. O ganho de eficiência pode ser medido na prática: em uma redação com 200 matérias por ano e média de quatro imagens por matéria, economizamos cerca de dois minutos de tempo de setup por artigo, o que dá quase 30 horas de trabalho por ano.

Um segundo cenário são catálogos de produto e documentação técnica. Quem mantém em um catálogo TYPO3 instruções passo a passo com screenshots inline precisa das imagens diretamente no texto. O rte_ckeditor_image permite isso com as mesmas referências FAL usadas no resto do projeto, atualizações de imagem acontecem em um lugar só e afetam todas as ocorrências.

Um terceiro cenário é a migração de instalações TYPO3 da era htmlArea. Quem usava antes o RTEhtmlArea tinha ali um gerenciamento de imagens semelhante. Na transição para CKEditor, o rte_ckeditor_image é a extensão de substituição direta, para que redatores continuem usando o workflow familiar. Sem a extensão, a redação perde no upgrade não só uma função, mas um passo inteiro de trabalho, substituível com dificuldade por content elements adicionais.

## Arquitetura técnica estende a toolbar do CKEditor via plugin

A extensão consiste em um plugin CKEditor que registra o botão Image e o diálogo Image, além de uma renderização server-side que traduz o marker no HTML salvo em uma saída Fluid. O plugin se comunica com um endpoint AJAX que processa a referência FAL, o cropping e os alt texts.

No conteúdo do banco, a imagem fica como marcação HTML com os data attributes data-htmlarea-file-uid e data-htmlarea-file-table, acompanhada por outros atributos de cropping, zoom e height. Na renderização, um pre-processor substitui a tag de marcação por uma chamada completa do Image ViewHelper, que gera srcset, variantes webp e atributos de lazy loading. As larguras de imagem disponíveis são definidas via YAML na configuração RTE. Um setup típico de revista trabalha com três a cinco larguras (480, 768, 1024, 1440, 2048) e gera a partir delas, automaticamente, um srcset responsivo que em dispositivos móveis só carrega a variante menor.

O cropping usa a ferramenta de cropping do core TYPO3: no diálogo de imagem aparece o crop editor do backend, com os mesmos presets de variante usados no elemento de conteúdo de imagem regular. O cropping é salvo por instância de imagem, de forma que a mesma imagem FAL pode ter cortes diferentes em artigos distintos. Isso é especialmente importante quando uma imagem é usada tanto no teaser da revista (quadrada) quanto no texto corrido (landscape), sem que a redação precise manter dois arquivos separados.

## Problemas frequentes envolvem saída responsiva, WebP e compatibilidade com CKEditor 5

O tema de suporte mais frequente é a saída srcset faltante. O caminho de rendering default não gera srcset se o YAML do RTE não tem definição de larguras de imagem. Muitas instalações copiaram o YAML do core TYPO3 e deixaram de fora a seção "proc.entryHTMLparser_db.allowedAttribs" ou "config.additionalAttributes". A solução é um YAML completo com larguras srcset explicitamente definidas.

O segundo problema é o WebP. Quem quer entregar formatos modernos de imagem precisa configurar o provedor ImageMagick do TYPO3 ou um setup GraphicsMagick com suporte a WebP. O próprio rte_ckeditor_image não gera conversão WebP, mas recorre ao image processor do core. Sem configuração correta do provedor, as imagens permanecem como JPEG na saída.

Em terceiro, o CKEditor 5 representa uma mudança de arquitetura. O TYPO3 v12 traz o CKEditor 5, que usa um modelo diferente de plugin. As versões 10.x e 11.x de rte_ckeditor_image foram portadas para CKEditor 5 e funcionam out of the box no v12. Adaptações próprias baseadas no CKEditor 4 precisam ser ajustadas no upgrade. Quem construiu plugins custom ou botões próprios na toolbar deve planejar pelo menos um a dois dias de desenvolvedor para a migração.

## Migração para TYPO3 v12 e v13 exige salto de versão da extensão

O rte_ckeditor_image é mantido ativamente pela Netresearch e está disponível para TYPO3 v11, v12 e v13. O salto maior está entre as versões da extensão 9.x (CKEditor 4) e 10.x/11.x (CKEditor 5). Quem leva uma instalação TYPO3 v10 ou v11 com extensão 9.x para TYPO3 v12 precisa simultaneamente mudar para a série 10.x da extensão. A representação no banco de dados das imagens inline permanece compatível, de forma que artigos existentes funcionam sem migração de conteúdo.

Na Gosign, verificamos antes de cada upgrade TYPO3 se o YAML do RTE do projeto precisa ser ajustado à versão da extensão e se existem adaptações próprias de plugin ou ViewHelpers sobrescritos. Em muitos projetos com TYPO3 v12 dá ainda para verificar se as funções nativas de imagem do CKEditor 5 bastam e se a extensão pode ser desativada a médio prazo. Para redações com necessidade de cropping e srcset, no entanto, o rte_ckeditor_image permanece a opção mais pragmática. A alternativa seria um botão de imagem próprio na toolbar com plugin CKEditor custom, o que é muito mais trabalhoso e coloca a manutenção permanentemente sob responsabilidade do projeto.

--- rx_shariff TYPO3 - Compartilhamento com privacidade | Gosign ---
> rx_shariff: Compartilhamento social sem rastreamento. em conformidade com a LGPD Buttons para TYPO3. Configuração e alternativas.

## Por que botões sociais padrão são um problema de LGPD e rx_shariff foi a solução

Todo botão de curtir do Facebook, todo widget de compartilhamento do Twitter e todo embed do LinkedIn transfere dados pessoais para a plataforma - e isso ao carregar a página, não apenas ao clicar. Endereço IP, browser fingerprint e referrer fluem para o Facebook antes que o visitante sequer tenha a possibilidade de consentir. Isso é juridicamente problemático desde a entrada em vigor da LGPD e regulamentos similares, e já levou a notificações contra operadores de sites.

rx_shariff implementa o princípio Shariff, desenvolvido pela editora alemã Heise em 2014 como resposta a esse problema: em vez de incorporar os widgets originais das plataformas, rx_shariff renderiza botões próprios em conformidade com a privacidade. Somente quando um visitante clica no botão é que uma conexão com a plataforma é estabelecida. Sem rastreamento, sem requests de terceiros, sem cookies sem interação.

## Cenários típicos de uso

**Sites corporativos com requisito de conformidade LGPD.** Uma empresa de médio porte quer oferecer botões de compartilhamento social em seus artigos de blog, sem violar a LGPD. O encarregado de proteção de dados proibiu explicitamente os widgets padrão do Facebook e Twitter. rx_shariff entrega botões que só estabelecem conexão ao clicar.

**Sites de mídia com contador de compartilhamentos.** Uma editora especializada quer exibir sob cada artigo quantas vezes ele foi compartilhado no Facebook e LinkedIn. rx_shariff oferece essa função via proxy de backend opcional: o servidor TYPO3 consulta regularmente as contagens de compartilhamento nas plataformas e cacheia os resultados. As plataformas veem apenas o servidor, nunca o visitante individual.

**Portais intranet com compartilhamento controlado.** Uma empresa opera um intranet TYPO3 e quer tornar certos artigos compartilháveis especificamente via LinkedIn, mas excluir Facebook e Twitter. rx_shariff pode ser configurado para que apenas plataformas selecionadas apareçam como botões.

## Arquitetura técnica

rx_shariff consiste em dois componentes: um widget frontend e um serviço backend opcional.

**Widget frontend:** O plugin TYPO3 renderiza para cada plataforma configurada um botão HTML. Este botão é um simples anchor link (`<a href="...">`) com uma URL de compartilhamento como destino. Ao clicar, a página de diálogo de compartilhamento da plataforma se abre em uma nova janela. Nenhum JavaScript é carregado ao carregar a página, nenhum cookie é definido, nenhum recurso externo é requisitado.

**Serviço backend (opcional):** Para contadores de compartilhamento, rx_shariff opera um proxy server-side. Um script PHP consulta as APIs das plataformas e cacheia os resultados em uma tabela de banco de dados. O frontend exibe o contador cacheado. As APIs das plataformas veem apenas o IP do servidor, nunca o IP do visitante do site.

A configuração ocorre via TypoScript: seleção de plataformas (Facebook, Twitter/X, LinkedIn, Pinterest, WhatsApp, Telegram, e-mail), variante de exibição, ajuste de tema via classes CSS, ativação/desativação de contadores.

## Problemas frequentes e soluções

**Contadores de compartilhamento sempre mostram 0.** As APIs das plataformas requerem autenticação. Sem API key válida, Facebook e LinkedIn não entregam contadores. Twitter/X desativou completamente sua API de contagem de compartilhamentos em 2015. Solução: criar Facebook App no Meta Developer Portal e configurar o token no rx_shariff. Para Twitter, desativar o contador.

**Botões não são visíveis após atualização TYPO3.** rx_shariff usa um plugin TYPO3 com elemento de conteúdo próprio. Se o plugin não está mais registrado após uma atualização, o elemento de conteúdo desaparece do frontend. Solução: verificar extensão no Extension Manager, atualizar dependências Composer.

**Compartilhamento WhatsApp funciona apenas em dispositivos móveis.** WhatsApp Web e o app desktop não suportam uniformemente o URL scheme `whatsapp://`. Solução: em desktop, usar a URL web `https://api.whatsapp.com/send?text=...`, em dispositivos móveis o app scheme. rx_shariff detecta o user-agent e escolhe o link correto automaticamente.

## Migração e compatibilidade de versões

rx_shariff está disponível como pacote Composer estável para TYPO3 v10 e v11. Para TYPO3 v12 existem forks da comunidade. O projeto JavaScript Shariff da Heise foi colocado em modo de manutenção em 2022.

Para novos projetos a partir de TYPO3 v12, a Gosign recomenda uma reavaliação: links de compartilhamento simples (`href="https://www.facebook.com/sharer/sharer.php?u=..."`) são mais leves que rx_shariff, em conformidade com a LGPD e não requerem extensão. A desvantagem: sem contador de compartilhamentos.

A migração de rx_shariff para links de compartilhamento simples leva tipicamente meio dia: remover plugin antigo, criar novos partials Fluid para links de compartilhamento, ajustar CSS. A Gosign realizou essa troca em vários clientes e melhorou o tempo de carregamento da página em 150 a 300ms.

A abordagem de links simples cobre as plataformas comuns: Facebook, LinkedIn, X/Twitter, e-mail e WhatsApp. Todos os links são em conformidade com a proteção de dados, pois nenhum JavaScript é carregado e nenhum cookie de terceiros é definido.

--- SAML2 TYPO3 - SSO Integration | Gosign ---
> SAML 2.0 Single Sign-On direto no TYPO3, sem Shibboleth SP no servidor. Alternativa ao shibboleth_auth para IdPs que não suportam OIDC.

## SAML 2.0 ermöglicht Single Sign-On in TYPO3 ohne Shibboleth-Installation auf dem Server

Hochschulen, Behörden und Konzerne betreiben Identity Provider (IdP), die auf SAML 2.0 basieren: Microsoft ADFS, Okta, Keycloak, PingFederate. Wer diese Identitäten in TYPO3 nutzen will, brauchte bisher einen Shibboleth Service Provider auf dem Webserver, eine zusätzliche Softwareschicht mit eigener Konfiguration, eigenen Zertifikaten und eigener Wartung. Die TYPO3-Extension saml2 macht den Shibboleth SP überflüssig. Sie implementiert den SAML 2.0 SP direkt in PHP und kommuniziert ohne Middleware mit dem IdP. Das vereinfacht die Server-Architektur erheblich, besonders auf Shared-Hosting-Umgebungen oder in Container-Deployments, wo ein Shibboleth SP schwer zu installieren ist.

Für Organisationen, deren IdP kein OIDC (OpenID Connect) unterstützt, ist SAML 2.0 der einzige standardisierte Weg zum Single Sign-On. Die Extension schliesst genau diese Lücke im TYPO3-Ökosystem.

## Cenários típicos de uso envolvem Hochschul-Intranets, Behörden-Portale und Konzern-Extranets

Das häufigste Szenario ist das Hochschul-Intranet. Eine Universität betreibt einen Shibboleth IdP im DFN-AAI-Verbund (Deutsches Forschungsnetz). Studierende und Mitarbeitende melden sich mit ihrer Hochschulkennung an und erhalten Zugang zu geschützten TYPO3-Seiten: Skripte, interne Nachrichten, Prüfungsergebnisse. Die saml2-Extension prüft das SAML-Assertion-Token, legt bei Bedarf einen TYPO3-Frontend-User an und weist Gruppen basierend auf den IdP-Attributen zu (z.B. Studierende = Gruppe "student", Dozierende = Gruppe "staff").

Ein zweites Szenario sind Behörden-Portale mit BundID-Anbindung. Seit 2023 ist BundID der zentrale Identitätsdienst des Bundes. SAML 2.0 ist eines der unterstützten Protokolle. Eine Kommune kann ihre TYPO3-Website über saml2 an BundID anbinden, sodass Bürger sich mit ihrem Personalausweis (eID) oder Elster-Zertifikat anmelden und auf personalisierte Dienstleistungen zugreifen.

Drittes Szenario: Konzern-Extranets. Ein Automobilhersteller betreibt ein Händlerportal auf TYPO3. Händler melden sich über den Konzern-IdP (Microsoft ADFS) an und sehen Preislisten, Schulungsunterlagen und Bestellformulare, die ihrer Händlergruppe zugeordnet sind. Die saml2-Extension mappt die ADFS-Gruppen auf TYPO3-Frontend-Gruppen und steuert damit den Zugang zu geschützten Inhaltsbereichen.

## Arquitetura técnica implementiert den SAML 2.0 SP als PHP-Library in TYPO3

saml2 basiert auf der PHP-Library onelogin/php-saml (oder einer vergleichbaren Implementation), die den SAML 2.0 Web Browser SSO Profile vollständig abdeckt: AuthnRequest, Response-Validierung, Assertion-Parsing, Signaturprüfung, Logout. Die Library wird als Composer-Dependency eingebunden und von der Extension als TYPO3-Authentication-Service registriert.

Die Konfiguration erfolgt im TYPO3-Backend oder per TypoScript: IdP-Metadata-URL (oder manuell: Entity ID, SSO-URL, SLO-URL, Zertifikat), SP-Entity-ID, Attribute-Mapping (welches IdP-Attribut auf welches TYPO3-Feld: email, username, firstname, lastname, groups). Die Extension unterstützt sowohl SP-initiated SSO (User klickt "Login" auf der TYPO3-Seite) als auch IdP-initiated SSO (User kommt direkt vom IdP-Portal).

Frontend-User werden bei der ersten Anmeldung automatisch angelegt und bei jeder weiteren Anmeldung aktualisiert. Die Gruppenzuordnung kann statisch (alle SAML-User in Gruppe X) oder dynamisch (IdP-Attribut "role" = "admin" wird zu TYPO3-Gruppe "admin") konfiguriert werden.

Für das Backend-Login (BE-User) ist SAML ebenfalls konfigurierbar, allerdings mit höherem Risiko: Wenn der IdP ausfällt, ist kein Backend-Zugang mehr möglich. Wir empfehlen, mindestens einen lokalen Admin-Account als Fallback beizubehalten.

## Problemas frequentes betreffen Zertifikate, Zeitabweichungen und Attribut-Mapping

Das häufigste Problem bei SAML-Integrationen sind abgelaufene oder falsch konfigurierte Zertifikate. Der IdP signiert die SAML-Response mit seinem Zertifikat. Wenn das Zertifikat auf dem SP nicht aktualisiert wird, nachdem der IdP es rotiert hat, scheitert die Signaturprüfung und der Login bricht mit einer kryptischen Fehlermeldung ab. A solução: Zertifikats-Rotation in den Wartungskalender aufnehmen. Die meisten IdPs geben 30 Tage Vorlauf vor der Rotation.

Zweites Problem: Zeitabweichungen zwischen IdP und SP. SAML-Assertions haben ein Zeitfenster (NotBefore / NotOnOrAfter). Wenn die Systemuhren von IdP-Server und TYPO3-Server mehr als 120 Sekunden auseinanderlaufen, wird die Assertion als ungültig abgelehnt. A solução: NTP auf beiden Servern konfigurieren.

Drittes Thema: Falsches Attribut-Mapping. Jeder IdP benennt die Attribute anders. Microsoft ADFS liefert "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", Keycloak liefert "email", Shibboleth liefert "urn:oid:0.9.2342.19200300.100.1.3". Die Extension muss wissen, unter welchem Namen das E-Mail-Attribut im SAML-Token steht. Falsches Mapping führt zu leeren Feldern im TYPO3-User-Profil. Debug-Logging der empfangenen Attribute hilft, die richtigen Mapping-Keys zu identifizieren.

## TYPO3 v12 wird unterstützt, v13-Kompatibilität hängt von der Authentication-Service-API ab

Die saml2-Extension registriert sich als TYPO3 Authentication Service. Diese API ist im TYPO3-Core seit Jahren stabil, wurde aber in v12 und v13 an einzelnen Stellen angepasst. Die aktuelle Version der Extension läuft unter v12 stabil. Für v13 muss die Authentication-Service-Registrierung an die neue Service-Konfiguration angepasst werden. A Gosign verifica bei SSO-Projekten, ob die PHP-SAML-Library auf aktuellem Stand ist (Sicherheitspatches) und ob die Extension mit der eingesetzten TYPO3-Version kompatibel ist. Wenn die Community-Extension nicht mehr gepflegt wird, empfehlen wir als Alternative die oidc-Extension, sofern der IdP OpenID Connect unterstützt.
---

--- Schemaker TYPO3 - Schema de ViewHelper | Gosign ---
> Gerador de schema de ViewHelper para Fluid. Gera documentação e autocompletar para ViewHelpers próprios.

## Por que documentação ausente de ViewHelper freia projetos TYPO3

Fluid ViewHelpers são a espinha dorsal de todo desenvolvimento de templates TYPO3. Mas assim que um projeto traz ViewHelpers próprios, começa o problema: nenhum desenvolvedor conhece todos os parâmetros, nenhuma IDE oferece autocompletar, e a documentação existe no máximo como comentário no código PHP. Schemaker resolve esse problema gerando automaticamente arquivos XSD Schema a partir de classes PHP. Esses schemas fornecem às IDEs as informações necessárias para autocompletar, validação e documentação inline diretamente no template Fluid.

Para equipes com mais de um desenvolvedor TYPO3, isso não é questão de conforto, mas de produtividade. Sem arquivos schema, cada desenvolvedor gasta diariamente 15 a 30 minutos consultando parâmetros de ViewHelper no código-fonte.

## Cenários típicos de uso

**Projetos enterprise com mais de 20 ViewHelpers próprios.** Grandes instalações TYPO3 frequentemente trazem ViewHelpers especializados - para formatação de preço, verificações de permissão, chamadas de API ou lógica específica do setor. Sem Schemaker, cada novo desenvolvedor no projeto precisa ler o código-fonte para entender os parâmetros disponíveis. Com Schemaker, ele abre o template Fluid no PhpStorm ou VS Code e recebe sugestões imediatamente.

**Desenvolvimento de extensões para o TER.** Quem publica extensões que contêm ViewHelpers próprios pode incluir arquivos XSD gerados pelo Schemaker. Isso reduz consultas de suporte consideravelmente e melhora a experiência do desenvolvedor.

**Onboarding de novos desenvolvedores.** Em uma agência TYPO3, desenvolvedores alternam regularmente entre projetos. Schemas gerados pelo Schemaker funcionam como documentação viva: sempre atualizados, porque gerados diretamente do código. Em vez de 2 dias de familiarização, são 2 horas.

## Arquitetura técnica

Schemaker analisa classes PHP que herdam de `AbstractViewHelper`. Lê as anotações `@param`, as chamadas `registerArgument()` e os DocBlocks das classes. A partir disso, gera arquivos XSD Schema (XML Schema Definition) associados ao namespace Fluid.

A integração funciona via CLI TYPO3: `vendor/bin/typo3 schemaker:generate` gera arquivos XSD para todos os namespaces de ViewHelper registrados. Os arquivos XSD gerados são colocados no projeto e em cada template Fluid o namespace é declarado com Schema-Location. A IDE lê o XSD e oferece autocompletar.

Schemaker não tem impacto de performance no site live - a geração de schema roda exclusivamente na CLI em contexto de desenvolvimento. Em ambientes produtivos, Schemaker nem precisa estar instalado; os arquivos XSD gerados são distribuídos via sistema de controle de versão (Git).

## Problemas frequentes e soluções

**IDE não mostra autocompletar apesar do XSD.** Causa mais frequente: o namespace no template Fluid não corresponde ao namespace XSD. Schemaker gera schemas baseados no namespace PHP das classes ViewHelper. Solução: garantir que a declaração xmlns no template corresponda exatamente ao schema gerado.

**XSD gerado não contém todos os ViewHelpers.** Schemaker encontra apenas ViewHelpers acessíveis via Composer Autoloading. Extensões instaladas apenas via modo clássico (sem Composer) não são completamente escaneadas. Solução: migrar para instalação baseada em Composer.

**Schema desatualizado após mudanças no código.** Arquivos XSD não são atualizados automaticamente quando parâmetros de ViewHelper mudam. Solução: integrar geração de schema na pipeline CI/CD.

## Migração e compatibilidade de versões

Schemaker foi originalmente desenvolvido por Claus Due (equipe FluidTYPO3) e foi ativamente mantido até TYPO3 v9. Para TYPO3 v10 e v11 existem forks da comunidade com funcionalidade limitada.

Para TYPO3 v12 e v13, recomenda-se como alternativa o suporte TYPO3 Plugin integrado no PhpStorm, que lê informações de ViewHelper diretamente do código PHP sem necessidade de arquivos XSD separados. A equipe do TYPO3 Core também fornece schemas XSD oficiais para os ViewHelpers Core.

A Gosign auxilia na avaliação e migra workflows de schema existentes para toolchains modernas. Esforço típico para a migração: 4 a 8 horas por projeto, incluindo configuração da IDE para todos os desenvolvedores da equipe.

--- sf_event_mgt TYPO3 - Gerenciamento de eventos | Gosign ---
> sf_event_mgt: Gerenciar eventos, controlar inscrições, pagamento. Configuração e desenvolvimento personalizado , acelerado com IA.

## sf_event_mgt resolve o problema de que eventos sem inscrição não são eventos

Assim que um site TYPO3 passa a gerenciar mais de dois eventos por ano e precisa receber participantes, qualquer solução improvisada com listas de páginas, plugins de calendário e formulários Powermail atinge seus limites. O sf_event_mgt é a extensão que reúne esses blocos em um sistema de eventos de verdade: gestão de participantes com transições de status, listas de espera com preenchimento automático, pagamento via vários provedores e comunicação por email automatizada ao longo de todo o ciclo de vida da participação. Quem organiza regularmente eventos com vagas limitadas em TYPO3 dificilmente escapa dessa extensão. Torben Hansen construiu o sf_event_mgt desde o início como ferramenta Extbase nativa que se encaixa perfeitamente em instalações TYPO3 existentes e pode ser sobrescrita em qualquer ponto sem fazer fork da extensão principal.

## Cenários típicos vão de feiras a programas acadêmicos

Universidades brasileiras usam o sf_event_mgt para dias abertos, aulas experimentais e programas de educação continuada. Na prática, isso significa frequentemente: 30 cursos paralelos, cada um com capacidade própria, faixa de preço e cadeia de emails para interessados, participantes e organizadores. A extensão administra isso via uma única estrutura de dados, incluindo multilinguismo para estudantes internacionais. Em uma universidade típica, usamos o sf_event_mgt com cerca de 400 eventos individuais por ano, entre cursos preparatórios, dias abertos de laboratório e encontros de ex-alunos.

Associações e conselhos profissionais organizam com ele congressos técnicos e seminários em que os participantes pagam preços diferentes conforme o status de associado. Uma instalação típica trabalha com 40 a 80 eventos por ano, muitos pagos e com várias classes de preço. Associados pagam o preço regular, não associados uma sobretaxa, early birds um desconto. A extensão mapeia isso via categorias de preço configuráveis por evento, sem que um desenvolvedor precise intervir.

Empresas, por sua vez, usam o sf_event_mgt para treinamentos internos, eventos com clientes e webinars. Especialmente no B2B, a exportação em CSV é importante: a lista de participantes depois vai ao CRM ou à impressora de crachás no local. Em um conglomerado industrial com 12.000 colaboradores, conectamos a extensão ao sistema interno de Learning Management, de forma que inscrições em treinamentos chegam automaticamente ao sistema de RH e a participação é documentada como comprovante de educação continuada.

## Arquitetura técnica baseada em Extbase e FAL

O sf_event_mgt é uma extensão Extbase clássica e segue o padrão MVC do TYPO3. Os models centrais são Event, Registration, Location e Organisator, a configuração vai via TypoScript e templates Fluid. Quase tudo pode ser ajustado via constants.typoscript ou TSconfig, sem fazer fork. A variante plugin oferece mais de uma dezena de actions de controller, da visão de lista e detalhe passando pelo fluxo de inscrição até o filtro de busca e categoria.

Para pagamento, a extensão traz uma abstração que suporta Stripe, PayPal, Invoice e Klarna via handler classes. Provedores próprios podem ser conectados implementando a interface PaymentServiceInterface. A contabilidade vai para um payment log próprio e pode ser processada com o scheduler do TYPO3. Pagamentos com falha são documentados e podem ser acompanhados pelo backend, sem que redatores precisem entrar no console do provedor de pagamento.

O sistema de emails se baseia em templates Fluid no diretório EXT. Para cada inscrição, várias mensagens são disparadas: confirmação ao participante, notificação ao organizador, lembretes antes do evento, mensagem de follow-up após o evento. Cada um desses emails é um template Fluid que pode ser sobrescrito via SiteSet ou PageTS. Os emails são enviados via TYPO3 Mailer e respeitam as configurações SMTP globais, incluindo SPF e DKIM. Para participantes em lista de espera há templates separados, disparados quando alguém é chamado da lista.

## Problemas frequentes envolvem listas de espera, export iCal e ReCaptcha

O tema mais frequente de suporte é a lógica de lista de espera. Quando um participante cancela, o primeiro inscrito na lista de espera é chamado, mas só se o administrador tiver ativado o command controller "moveUpWaitlistRegistrations" via scheduler. Muitas instalações esqueceram esse comando e estranham por que vagas continuam vazias. A configuração leva cinco minutos, mas sem a tarefa do scheduler a extensão fica em modo manual.

Um segundo tema constante é o export iCal. Participantes querem um clique em "Adicionar ao calendário" que funcione no Outlook, Apple Calendar e Google Calendar. O sf_event_mgt entrega um arquivo ICS, mas os fusos horários e blocos VTIMEZONE corretos precisam ser configurados. Caso contrário, o evento aparece no Outlook com uma hora de diferença, crítico em mudanças de horário de verão. Em eventos internacionais recomendamos registrar no ICS tanto o fuso local quanto UTC.

O terceiro tema é proteção contra spam. Formulários públicos de inscrição atraem bots que inundam listas de espera. O sf_event_mgt suporta campos honeypot e pode ser acoplado com ext:kestura_recaptcha ou com o captcha nativo do TYPO3. Em instalações produtivas, recomendamos combinar os dois mecanismos e, adicionalmente, um rate limit por endereço IP, para que bots isolados não criem centenas de inscrições falsas.

## Migração para TYPO3 v12 e v13 é tranquila

O sf_event_mgt é mantido continuamente por Torben Hansen e está disponível para TYPO3 v11, v12 e v13. O salto de v10 para v12 não traz breaking changes na estrutura de banco de dados, todos os campos permanecem compatíveis. ViewHelpers próprios da extensão foram atualizados para a nova versão do Fluid, e templates próprios precisam de uma revisão curta após o update. Principalmente o Registration Finisher e os templates de email precisam ser verificados, porque o TYPO3 v12 introduziu regras mais rígidas para tratamento de erros.

Em versões mais antigas (sf_event_mgt 4.x e anteriores) vale um olhar na configuração de pagamento, porque a API Stripe pulou várias gerações. A extensão atual suporta Stripe Elements e 3D Secure 2, versões antigas trabalhavam com Stripe Sources, agora deprecated. A Gosign migra instalações sf_event_mgt existentes tipicamente em um único passo junto com o upgrade do core TYPO3. Templates Fluid são unificados para identificadores consistentes, e chamadas de ViewHelper desatualizadas são identificadas e substituídas automaticamente. No mesmo passo, verificamos se a marcação Schema.org/Event no JSON-LD está em dia e se o template de detalhe do evento contém todos os campos para rich snippets de evento do Google.

--- Gallery TYPO3 - Galeria de imagens | Gosign ---
> Extensão de galeria de imagens baseada em TYPO3 File Collections. Lightbox, layout masonry, lazy loading. A Gosign constrói Custom Gallery Templates im.

## Por que sf_filecollection_gallery resolve galerias de imagens no TYPO3 corretamente

Galerias de imagens estão entre as demandas mais frequentes em sites corporativos - fotos de produtos, imagens da equipe, documentação de eventos, projetos de referência. O TYPO3 por si só não traz um elemento nativo de galeria. O elemento de conteúdo padrão "Imagens" exibe imagens empilhadas ou em colunas, mas sem lightbox, sem filtragem e sem opções flexíveis de layout. sf_filecollection_gallery fecha essa lacuna utilizando TYPO3 File Collections como fonte de dados para galerias e fornecendo integração lightbox, diversos layouts e lazy loading.

A vantagem decisiva sobre outras extensões de galeria: editores trabalham com o sistema FAL que já conhecem. Imagens são organizadas em File Collections, e a galeria exibe automaticamente todas as imagens da Collection atribuída. Adicionar novas imagens significa: arrastar imagem para a Collection, pronto.

## Cenários típicos de uso

**Projetos de referência e portfólios.** Uma agência de arquitetura exibe em cada página de projeto 15 a 40 imagens em uma galeria. O editor mantém uma File Collection por projeto. sf_filecollection_gallery renderiza a galeria como grid com lightbox. Ao clicar em uma imagem, abre-se a visualização completa com navegação para a próxima e anterior. Descrições de imagem dos metadados FAL são exibidas automaticamente como legendas.

**Documentação de eventos e fotografia de imprensa.** Um organizador de feiras documenta cada evento com 50 a 200 fotos. As imagens são carregadas em lote em uma File Collection. sf_filecollection_gallery gera automaticamente miniaturas, otimiza o tempo de carregamento via lazy loading e exibe a galeria em layout masonry.

**Catálogos de produtos com apresentação visual.** Um fabricante de móveis exibe por categoria de produto uma galeria com fotos de ambiente. Através de múltiplas File Collections e um plugin frontend com filtro de categoria, visitantes podem alternar entre galerias sem recarregar a página.

## Arquitetura técnica

sf_filecollection_gallery é uma extensão Extbase incorporada como plugin TYPO3 em elementos de conteúdo. A fonte de dados são TYPO3 File Collections do File Abstraction Layer (FAL).

A arquitetura se divide em três camadas: fonte de dados (a extensão lê File Collections via TYPO3 FAL API), motor de renderização (templates Fluid controlam a saída com layouts para grid, masonry e listas simples) e integração lightbox (suporta Fancybox, PhotoSwipe e Lightcase). A Gosign recomenda PhotoSwipe pelo melhor suporte touch e ausência de dependência jQuery.

Lazy loading é integrado nativamente: imagens abaixo da área visível são carregadas apenas quando o usuário rola. Uma vantagem da arquitetura File Collection: imagens podem aparecer em múltiplas galerias simultaneamente sem serem duplicadas.

## Problemas frequentes e soluções

**Galeria não mostra imagens, embora a File Collection esteja preenchida.** Causa frequente é configuração errada de storage. A File Collection referencia um storage ao qual o frontend não tem acesso. Solução: verificar no backend TYPO3 se as imagens estão no storage correto e se o storage está configurado como "public".

**Lightbox não funciona, imagens abrem como nova página.** A biblioteca JavaScript do lightbox não está sendo carregada. Frequentemente um include TypoScript está faltando ou há conflito com outra biblioteca JavaScript na página. Solução: verificar no dev-tool do navegador se o arquivo JS do lightbox está sendo carregado.

**Tempo de carregamento muito alto em galerias grandes.** Uma galeria com mais de 100 imagens em alta resolução pode carregar lentamente apesar do lazy loading, porque as miniaturas não estão suficientemente comprimidas. Solução: configurar TYPO3 Image Processing para gerar miniaturas em tamanho fixo e qualidade otimizada. Adicionalmente, ativar formato WebP.

## Migração e compatibilidade de versões

sf_filecollection_gallery é mantida ativamente e está disponível para TYPO3 v11 e v12 LTS. A extensão tem API estável e praticamente nenhuma breaking change entre versões.

Na atualização de TYPO3 v10 para v12, a configuração do lightbox deve ser verificada. Fancybox 2 não é mais compatível com versões atuais do jQuery. A Gosign recomenda a troca para PhotoSwipe, que funciona sem jQuery e oferece melhor performance em dispositivos móveis. PhotoSwipe suporta gestos touch (pinch-to-zoom, swipe) que atendem à expectativa do usuário em telas de smartphone. A migração de Fancybox para PhotoSwipe requer tipicamente 4 a 8 horas.

--- sf_register TYPO3 - Registro no frontend | Gosign ---
> sf_register: registro de usuários no frontend do TYPO3. Gerenciamento de perfil, Double-Opt-In. Acelerado com IA.

## Por que o TYPO3 sem extensão de registro não vira portal de usuários

O core do TYPO3 conhece fe_users como tabela de banco de dados e uma máscara de login padrão, mas não oferece caminho para um novo usuário se registrar sozinho, manter seus dados ou redefinir sua senha. Todo site que é mais do que um mero órgão de publicação precisa dessa função: comunidades, áreas de associados, downloads protegidos, newsletters personalizadas, conteúdos pagos. O sf_register fecha essa lacuna com uma abordagem Extbase enxuta que se concentra exatamente em registro, perfil e redefinição de senha, abrindo mão deliberadamente de recursos que a solução completa femanager já traz.

## Cenários típicos de uso

Uma editora técnica brasileira com 3.500 assinantes oferece acesso online a artigos técnicos e estudos. Cada assinante recebe uma conta vinculada ao seu número de assinatura. O sf_register assume o registro inicial com confirmação Double-Opt-In por email, cria automaticamente o usuário no grupo "Assinante" e libera o acesso às páginas protegidas. Quando a assinatura expira, uma tarefa do scheduler do TYPO3 remove a associação ao grupo sem excluir a conta, de forma que o usuário recupera o acesso após uma renovação contratual.

Um segundo caso é uma associação setorial com cerca de 7.000 empresas associadas, operando um portal protegido de associados com documentação de eventos, prévias de normas e fóruns de discussão. O sf_register permite o registro inicial, mas ao mesmo tempo dispara um processo manual de liberação, no qual um funcionário da associação verifica o vínculo com a empresa associada antes de ativar a conta. O workflow combina Double-Opt-In com uma aprovação administrativa, aproveitando os event hooks da extensão.

O terceiro contexto são instituições públicas como bibliotecas municipais ou centros de educação de adultos, que querem vincular inscrições em cursos ou listas de favoritos do catálogo a uma conta de usuário. Aqui o que conta é a simplicidade da configuração e a baixa complexidade: a extensão não precisa gerenciar vinte campos de perfil, apenas nome, email, senha e um número de cadastro da biblioteca. Mais do que isso não é necessário, e o sf_register entrega exatamente isso.

## Arquitetura técnica: Extbase, TCA e finishers

O sf_register é construído limpamente segundo o modelo Extbase. Um FrontendUser Model próprio estende o user do core, controller actions tratam Create, Edit, Confirm e ResetPassword, e o templating roda via layouts Fluid. Os campos obrigatórios são controlados via configuração TCA e podem ser estendidos por um arquivo de configuração próprio da extensão. Campos customizados como empresa, cargo ou número de associado exigem uma pequena entrada TCA, uma propriedade de Model e um complemento no template Fluid, o que dá aos desenvolvedores uma estrutura clara, mas também significa que cada adaptação é trabalho de código.

O processo Double-Opt-In se baseia em links de confirmação baseados em hash, armazenados na tabela fe_users como token temporário, e após o clique retiram o flag disable. A extensão envia emails via TYPO3 Mailer Interface, que internamente usa o Symfony Mailer, de modo que setups mais complexos com SMTP proxies ou serviços de envio como SendGrid funcionam sem problema. O hashing de senhas usa os serviços de hash do próprio TYPO3, sincronizando automaticamente com cada atualização do core.

## Problemas frequentes e soluções

O primeiro problema são registros de spam. Toda página pública de registro atrai bots que criam contas automaticamente, para enviar emails a terceiros via formulário de reset de senha ou colocar spam em recursos comunitários. Uma solução limpa combina sf_register com uma extensão de CAPTCHA como sr_freecap ou um campo honeypot, complementada por rate limiting no URL de registro via reverse proxy.

O segundo problema envolve entrega de email. Emails de confirmação frequentemente caem em spam se o servidor TYPO3 é operado sem registro SPF, assinatura DKIM ou DNS reverso. A extensão envia o email corretamente, mas o servidor do destinatário descarta em silêncio. A solução não está no sf_register, mas na infraestrutura de email: um serviço de envio dedicado com reputação de domínio estabelecida reduz a taxa de bounce perceptivelmente.

O terceiro tema é proteção de dados. Usuários registrados precisam, a qualquer momento, poder ver, corrigir e excluir seus dados, e a exclusão precisa cascatear de verdade, cobrindo pedidos, downloads e outros registros vinculados, conforme exige a LGPD (PT: RGPD). O sf_register entrega formulários de edição, mas não um processo de exclusão em conformidade com a LGPD. Esse processo precisa ser acrescentado como workflow próprio, no qual a exclusão da conta anonimiza os dados dependentes imediatamente ou após um prazo de transição.

Um quarto problema típico envolve políticas de senha. Por padrão, o sf_register aceita senhas fracas, e os usuários tendem a usar combinações curtas ou triviais. As password policies do TYPO3 podem ser ativadas pela configuração do sistema, para que o sf_register aplique automaticamente comprimento mínimo, classes de caracteres e verificações contra blacklists, sem precisar alterar a extensão.

## Migração e compatibilidade de versões

O sf_register é estável para TYPO3 v11 e v12, e a comunidade o reconhece como uma alternativa sólida e manutenível ao femanager. O suporte a v13 costuma ficar disponível pouco depois do release de cada novo core TYPO3, exigindo, no caso de extensões customizadas, uma revisão da sintaxe de anotações Extbase, que teve pequenos ajustes entre versões.

Quem migra de femanager para sf_register reduz complexidade, mas precisa verificar quais features eram realmente utilizadas: femanager oferece aprovação administrativa, upload de foto de perfil e moderação via backend out-of-the-box, enquanto o sf_register só reconstrói essas funções via código adicional ou event listeners. No sentido inverso, o caminho de migração de sf_register para femanager é mais simples, porque a estrutura de dados é amplamente compatível. A Gosign assume essas migrações incluindo a portabilidade de templates de email e o ajuste dos grupos de usuários, de forma que os usuários existentes continuem se autenticando sem problema após a mudança.

Quem está iniciando um projeto novo deve, antes da escolha, considerar os requisitos reais do portal: o operador precisa de aprovações manuais, fotos de perfil, atribuições complexas de papéis? Então o femanager é o caminho mais rápido. Basta um registro self-service enxuto, com fundação Extbase limpa e pouco overhead? Então o sf_register é a escolha certa. A decisão raramente é apertada uma vez que se passa em revista o catálogo de funções necessárias, e ela economiza depois um esforço de retrabalho considerável.

--- sg_forms TYPO3 - Formulários | Gosign ---
> Extensão de formulários da SGalinski. Alternativa ao Powermail e ao TYPO3 Form Framework nativo.

## Drei Formular-Systeme in TYPO3 erzeugen mehr Verwirrung als Auswahl

TYPO3-Projekte stehen bei der Formular-Implementierung vor einem ungewöhnlichen Luxusproblem: Es gibt drei ernst zu nehmende Optionen. Das native TYPO3 Form Framework (ext:form), powermail von in2code und sg_forms von SGalinski. Jede Lösung hat eigene Stärken und eigene Limits. sg_forms positioniert sich als Mittelweg: leichtgewichtiger als powermail, aber mit mehr Backend-Komfort als ext:form. Die Extension stammt vom TYPO3-Dienstleister SGalinski und wird in dessen Kundenprojekten aktiv eingesetzt.

Wer bereits SGalinski-Extensions im Einsatz hat (sgalinski_base, sg_cookie_optin), findet in sg_forms eine Lösung, die sich nahtlos ins SGalinski-Ökosystem einfügt.

## Cenários típicos de uso são Kontaktformulare, Anfragen und einfache Bewerbungsformulare

Das Standard-Szenario ist das Kontaktformular auf einer Unternehmenswebsite. Name, E-Mail, Betreff, Nachricht, LGPD (PT: RGPD)-Checkbox, Absenden. sg_forms liefert dieses Setup als vorkonfiguriertes Template, das Redakteure im Backend aktivieren und anpassen können. Felder lassen sich hinzufügen, entfernen und umsortieren, Pflichtfelder markieren, Validierungen setzen. Die E-Mail geht an eine oder mehrere konfigurierbare Empfänger-Adressen.

Ein zweites Szenario sind mehrseitige Anfrage-Formulare. Ein Handwerksbetrieb fragt auf Seite 1 die Kontaktdaten, auf Seite 2 die Art der Dienstleistung (Dropdown) und auf Seite 3 Fotos des Objekts (Datei-Upload). sg_forms unterstützt mehrstufige Formulare mit Fortschrittsanzeige und Zurück-Navigation. Die Daten werden nach dem Absenden als E-Mail und optional als Datenbank-Eintrag gespeichert.

Drittes Szenario: Einfache Bewerbungsformulare. Ein KMU mit drei offenen Stellen braucht kein Bewerbermanagement-System, aber ein Formular, das Lebenslauf und Anschreiben als PDF-Upload entgegennimmt und an die Personalabteilung weiterleitet. sg_forms bietet dafür den Datei-Upload mit Typen- und Grössenvalidierung, kombiniert mit einer Bestätigungsmail an den Bewerber.

## Arquitetura técnica basiert auf Extbase mit YAML-basierter Formulardefinition

sg_forms registriert ein Extbase-Plugin, das Formulare aus einer Konfiguration rendert. Die Formulardefinition wird im Backend über ein grafisches Interface erstellt oder alternativ als YAML-Datei definiert. Jedes Feld hat einen Typ (Text, E-Mail, Textarea, Select, Radio, Checkbox, File, Hidden), Validierungsregeln und optionale Bedingungen.

Die Finisher-Architektur folgt dem gleichen Pattern wie bei powermail: Nach dem Absenden werden nacheinander Aktionen ausgeführt. Die Standard-Finisher sind E-Mail-Versand, Datenbank-Speicherung und Redirect auf eine Dankes-Seite. Custom Finisher lassen sich als PHP-Klassen implementieren, etwa für CRM-Anbindungen oder Webhook-Aufrufe.

Das Frontend-Rendering läuft über Fluid-Templates, die per SiteSet oder TypoScript überschrieben werden können. Die Extension liefert ein Default-Template mit, das ohne Anpassung funktioniert, aber für produktive Websites typischerweise an das CI angepasst wird. Spam-Schutz ist über Honeypot-Felder und optionale CAPTCHA-Integration verfügbar.

## Problemas frequentes betreffen die Abgrenzung zu powermail und die SGalinski-Lizenz

Die häufigste Frage ist: sg_forms oder powermail? Die Antwort hängt von der Projektgrösse ab. powermail hat die grössere Community, mehr Dokumentation, mehr Drittanbieter-Finisher und eine breitere Feature-Palette (PDF-Export, mehrstufige Logik mit beliebiger Komplexität). sg_forms ist schlanker, hat weniger Overhead und ist in SGalinski-Projekten der Standard. Für die meisten Unternehmenswebsites ist powermail die sicherere Wahl. Für SGalinski-Kunden, die bereits im Ökosystem sind, ist sg_forms die konsistentere.

Zweites Thema: Die Lizenzierung. sg_forms ist nicht im TER (TYPO3 Extension Repository) als Free-Extension verfügbar, sondern wird über SGalinski-Projekte ausgeliefert. Isso significa, dass Teams, die die Extension ohne SGalinski-Beziehung nutzen wollen, die Verfügbarkeit und Lizenzbedingungen direkt mit SGalinski klären müssen.

Drittes Problem: Migration. Wer von powermail zu sg_forms wechselt (oder umgekehrt), muss alle bestehenden Formulardefinitionen neu anlegen, weil die Datenstrukturen inkompatibel sind. Bestehende Formular-Einträge in der Datenbank können nicht automatisch migriert werden.

## TYPO3 v12 wird unterstützt, v13 folgt dem SGalinski-Release-Zyklus

SGalinski pflegt sg_forms im eigenen Release-Zyklus, der an die TYPO3-LTS-Versionen gekoppelt ist. TYPO3 v12 wird aktiv unterstützt. Für v13 ist mit einem Update zu rechnen, sobald SGalinski die eigene Extension-Suite aktualisiert. A Gosign recomenda bei der Wahl des Formular-Systems, die langfristige Pflege und die Community-Grösse als Entscheidungsfaktor zu gewichten: powermail mit über 500.000 Installationen hat eine breitere Basis als sg_forms, was bei TYPO3-Upgrades kürzere Wartezeiten auf kompatible Versionen bedeutet.
---

--- Shibboleth TYPO3 - SSO Basis | Gosign ---
> Extensão base Shibboleth para TYPO3 (irmã de shibboleth_auth). Integração Service Provider para backend e frontend. SSO padrão.

## Hochschulen und Forschungseinrichtungen brauchen Shibboleth-SSO direkt in TYPO3

Im akademischen Sektor ist Shibboleth der De-facto-Standard für Single Sign-On. Über 3.000 Einrichtungen weltweit sind in Shibboleth-Föderationen organisiert, in Deutschland über den DFN-AAI-Verbund mit über 700 teilnehmenden Organisationen. Die Shibboleth-Extension für TYPO3 integriert den Service Provider direkt ins CMS. Studierende, Dozierende und Mitarbeitende melden sich mit ihrer Hochschulkennung an und erhalten Zugang zu geschützten Frontend-Bereichen und bei Bedarf zum TYPO3-Backend. Die Extension ist die Schwester von shibboleth_auth und bietet die Basis-Integration für den Shibboleth SP, der auf dem Webserver installiert sein muss.

Im Gegensatz zur saml2-Extension, die einen eigenen SP in PHP implementiert, setzt die shibboleth-Extension auf den nativen Shibboleth Service Provider (C++ oder Java), der als Apache-Modul oder ISAPI-Filter läuft. Das ist die robustere Architektur für Hochverfügbarkeitsumgebungen.

## Cenários típicos de uso envolvem DFN-AAI, Bibliothekssysteme und Forschungsportale

Das primäre Szenario ist die DFN-AAI-Integration an deutschen Hochschulen. Eine Universität betreibt ihr Webportal auf TYPO3. Studierende klicken auf "Login", werden zum IdP der Hochschule weitergeleitet, authentifizieren sich und landen zurück auf der TYPO3-Seite mit einer aktiven Session. Die Extension liest die Shibboleth-Attribute aus den Server-Umgebungsvariablen (REMOTE_USER, eppn, mail, affiliation) und erstellt oder aktualisiert den TYPO3-Frontend-User.

Ein zweites Szenario sind Bibliotheks-Zugänge. Hochschulbibliotheken bieten Online-Datenbanken, E-Journals und Forschungsdokumente über ihre TYPO3-Website an. Der Zugang ist auf Hochschulangehörige beschränkt. Die Shibboleth-Extension prüft das Attribut "eduPersonEntitlement" und gewährt nur Nutzern mit dem Wert "urn:mace:dir:entitlement:common-lib-terms" Zugang zu lizenzierten Inhalten.

Drittes Szenario: Föderierte Forschungsportale. Ein Forschungskonsortium mit Partnern aus fünf Universitäten betreibt ein gemeinsames Portal auf TYPO3. Jeder Partner hat seinen eigenen IdP. Über die DFN-AAI-Föderation können alle Partner-Mitarbeitenden sich anmelden, ohne dass das Portal eigene Accounts verwalten muss. Die Extension ordnet die Nutzer basierend auf dem Attribut "schacHomeOrganization" der richtigen Partner-Gruppe zu.

## Arquitetura técnica setzt einen installierten Shibboleth SP auf dem Webserver voraus

Die Extension selbst enthält keinen SAML-Stack. Sie liest die Attribute, die der Shibboleth SP nach erfolgreicher Authentifizierung als Server-Umgebungsvariablen oder HTTP-Header bereitstellt. Der SP muss als Apache-Modul (mod_shib) oder als FastCGI-Authorizer konfiguriert sein. Für nginx-Setups ist ein Shibboleth SP als FastCGI-Backend oder ein lua-basierter Proxy nötig.

Die TYPO3-Extension registriert einen Authentication Service, der bei jedem Frontend- oder Backend-Login prüft, ob Shibboleth-Attribute vorhanden sind. Wenn ja, werden die Attribute auf TYPO3-User-Felder gemappt: REMOTE_USER auf username, mail auf email, givenName und sn auf first_name und last_name. Die Gruppenzuordnung erfolgt über das Attribut "eduPersonAffiliation": student, faculty, staff, employee werden auf TYPO3-Frontend-Gruppen gemappt.

Die Session-Verwaltung folgt dem Shibboleth-Lifecycle: Wenn die Shibboleth-Session abläuft, wird der TYPO3-User automatisch ausgeloggt. Single Logout (SLO) wird über den Shibboleth SP abgewickelt, die TYPO3-Extension reagiert auf das Logout-Event und zerstört die TYPO3-Session.

## Problemas frequentes betreffen die Apache-Konfiguration und fehlende Attribute

Das grösste Problem ist die korrekte Apache-Konfiguration. Der Shibboleth SP muss wissen, welche URLs er schützen soll. Eine falsche Location-Direktive führt dazu, dass der SP entweder alle Seiten schützt (auch öffentliche) oder gar keine. Die Standard-Konfiguration schützt /Shibboleth.sso/* für den SP selbst und /typo3/ für das Backend. Frontend-Bereiche werden per Lazy Session geschützt: Der SP setzt Attribute, wenn eine Shibboleth-Session existiert, erzwingt aber keine Authentifizierung. Die Extension prüft dann im TYPO3-Frontend, ob Attribute vorhanden sind, und zeigt geschützte Inhalte nur angemeldeten Nutzern.

Zweites Problem: Fehlende oder leere Attribute. Nicht jeder IdP liefert alle Attribute. Wenn der IdP das Attribut "mail" nicht freigibt, kann die Extension keine E-Mail-Adresse in den TYPO3-User schreiben. A solução: Mit dem IdP-Betreiber (Rechenzentrum) klären, welche Attribute für den SP freigegeben sind, und das Attribute-Mapping in der Extension entsprechend konfigurieren.

Drittes Thema: Container-Deployments. Docker-basierte TYPO3-Installationen haben oft keinen Apache mit mod_shib. Die Alternative ist ein Shibboleth SP als Reverse Proxy vor dem TYPO3-Container, der die Attribute als HTTP-Header weiterleitet. Die Extension muss dann so konfiguriert werden, dass sie Attribute aus Headern statt aus Umgebungsvariablen liest. Wichtig: Die Header müssen vor Spoofing geschützt werden, indem der Reverse Proxy eingehende Header mit Shibboleth-Attributnamen entfernt.

## TYPO3 v12 funktioniert, v13-Kompatibilität erfordert eine Prüfung der Authentication-Service-API

Die shibboleth-Extension nutzt die TYPO3 Authentication Service API, die seit Jahren stabil ist, aber in v13 Anpassungen erfahren hat. Unter TYPO3 v12 läuft die aktuelle Version ohne Probleme. Für v13 ist ein Update der Service-Registrierung und der Middleware-Konfiguration nötig. Hochschulen, die TYPO3-Upgrades planen, sollten die SSO-Integration als eigenen Testblock in die Upgrade-Planung aufnehmen. A Gosign recomenda, parallel zur shibboleth-Extension die oidc-Extension zu evaluieren, weil viele IdPs inzwischen sowohl SAML als auch OIDC unterstützen und OIDC die einfachere Architektur ohne Shibboleth SP auf dem Server ermöglicht.
---

--- shibboleth_auth TYPO3 - SSO Integration | Gosign ---
> Shibboleth SSO no TYPO3: Configuração, mapeamento de atributos e solução de problemas. Autenticação corporativa com acelerado com IA desenvolvimento.

## Como universidades brasileiras conectam seus portais TYPO3 à gestão central de identidade

Quem opera um portal TYPO3 em uma universidade que participa da federação CAFe (Comunidade Acadêmica Federada, operada pela RNP) não consegue ignorar o Shibboleth. A federação CAFe é a maior federação de identidade acadêmica do Brasil, e cada universidade, como USP, UFRJ, UNICAMP ou UFRGS, que queira oferecer dados de pesquisa, materiais didáticos ou serviços administrativos precisa autenticar seus usuários contra um Shibboleth Identity Provider. O shibboleth_auth é a extensão que insere o TYPO3 nesse cenário: ela lê as SAML assertions de um Shibboleth Service Provider configurado à frente e cria fe_users e be_users a partir disso.

## Cenários típicos de uso

Uma faculdade de medicina com 8.000 estudantes opera um portal TYPO3 para currículos clínicos. Os alunos devem ver seus materiais didáticos após o login, e os professores devem ter ainda uma interface editorial. O IdP central da universidade fornece os atributos eduPersonAffiliation, schacHomeOrganization e um identificador único. O shibboleth_auth assume o mapeamento desses atributos para grupos TYPO3 e garante que um aluno nunca acesse o backend, enquanto um professor é automaticamente incluído no grupo de redatores.

Um segundo caso típico são institutos de pesquisa associados, como os institutos vinculados ao CNPq ou à FAPESP. Seus colaboradores vêm de dezenas de universidades parceiras, e cada um deve poder se autenticar em portais centrais de projeto com sua credencial institucional. O shibboleth_auth em combinação com um SP conectado à eduGAIN permite exatamente isso: um pesquisador visitante da Universidade de Lisboa se autentica em um portal brasileiro com sua conta da federação portuguesa, sem que exista uma conta local.

O terceiro contexto é a administração pública, onde estados brasileiros operam cada vez mais IdPs estaduais para unificar contas de cidadãos e acessos de servidores. Um órgão estadual com vários portais TYPO3 para diferentes áreas pode, via shibboleth_auth, conectar todos os portais ao IdP central do estado e dispensar a manutenção de bases de usuários separadas por portal.

## Arquitetura técnica entre SP, SAML e fe_user

O shibboleth_auth é construído de forma diferente dos serviços de autenticação clássicos do TYPO3: a extensão não fala SAML diretamente, mas delega todo o protocolo a um Shibboleth Service Provider instalado localmente. O SP, tipicamente o daemon shibd com mod_shib no Apache ou o módulo correspondente no Nginx, processa a SAML assertion, valida assinaturas e certificados e disponibiliza os atributos extraídos como variáveis de ambiente HTTP. O shibboleth_auth lê essas variáveis, cria ou atualiza o fe_user e faz o login na sessão TYPO3.

A extensão é configurada via Extension Configuration do TYPO3 e pelo padrão Extbase Service para provedores de autenticação. O mapeamento de atributos fica em um arquivo TypoScript ou diretamente no backend da extensão: variável HTTP à esquerda, nome do campo TYPO3 à direita, opcionalmente com transformações para IDs de grupo. A ordem na configuração $TYPO3_CONF_VARS['SVCONF']['auth']['setup'] é importante, para que o shibboleth_auth atue antes do serviço de login padrão.

## Problemas frequentes e soluções

O erro mais comum é um loop de redirecionamento: o usuário é enviado ao IdP, volta, é enviado ao IdP novamente, e assim por diante. A causa quase sempre é uma divergência entre o domínio de sessão do SP e o do TYPO3, ou um cookie faltando porque o SP grava sua sessão em um caminho diferente do esperado pelo TYPO3. A solução é uma separação limpa: sessão do SP no caminho /Shibboleth.sso, sessão TYPO3 em / e ambos sob o mesmo domínio de topo.

O segundo problema envolve atributos: o IdP entrega um nome de atributo diferente do que a extensão espera. Especialmente na federação CAFe, os namespaces de atributos mudam entre notações OID e URN. Sem uma normalização limpa, o usuário não entra em nenhum grupo ou recebe um nome vazio no perfil. Um arquivo de mapeamento de atributos no SP, que unifica nomes antigos e novos em um nome local único, resolve o problema em definitivo.

O terceiro tema é rotação de certificados. Todo IdP troca seus certificados de assinatura e criptografia regularmente, normalmente a cada dois anos. O SP precisa puxar os novos certificados pelo feed de metadados, caso contrário a validação de assertions para de funcionar do nada. A configuração de metadata provider no shibboleth2.xml deve rodar com intervalo de refresh automático de poucas horas e verificação de assinatura contra o signer da federação.

Um quarto ponto são os tempos de vida das sessões. As sessões Shibboleth e TYPO3 têm timeouts independentes: se a sessão do SP expira enquanto a sessão TYPO3 ainda está ativa, o usuário vê seus conteúdos protegidos, mas um re-login falha porque o SP não tem mais uma assertion válida. A solução limpa é ajustar ambas as durações para o mesmo valor e configurar um comportamento de logout paralelo, de modo que Single Logout realmente encerre as duas sessões.

## Migração e compatibilidade de versões

O shibboleth_auth acompanhou por muito tempo as versões TYPO3 v9, v10 e v11 via forks da comunidade, mas a situação em v12 e v13 varia conforme o ramo de fork. Alguns forks adotaram serviços de autenticação baseados em Symfony, outros ficaram na v11. Quem migra hoje para v12 deve verificar antes do upgrade se o próprio ramo da extensão ainda é mantido ou se uma mudança para a OIDC Extension é a escolha melhor.

O caminho de migração de Shibboleth para OIDC ficou relevante para muitas universidades desde que Keycloak e brokers de identidade similares passaram a conectar clientes SAML e OIDC em paralelo. A Gosign acompanhou várias dessas transições e, durante a fase de mudança, tipicamente opera ambos os caminhos de autenticação em paralelo, de modo que sistemas legados continuam autenticando via Shibboleth enquanto portais novos já falam OIDC diretamente.

Quem permanece no shibboleth_auth deve avaliar a carga de manutenção de forma realista. A extensão em si muda pouco, mas a infraestrutura ao redor muda regularmente: o Shibboleth SP publica atualizações de segurança, a federação atualiza metadados e certificados, versões Apache ou Nginx são trocadas, e cada uma dessas alterações pode quebrar o fluxo de login. Um monitoramento adequado da pipeline de autenticação com logins sintéticos e alertas para assertions falhadas não é um nice-to-have, mas parte do conceito operacional para uma integração SSO estável.

--- Slick Carousel TYPO3 - Slider | Gosign ---
> Slick Slider Integração para TYPO3. Baseado em jQuery. A Gosign migra para Swiper ou Splide: kein jQuery nötig, bessere Performance, native.

## Slick Carousel força sites TYPO3 a carregar jQuery, embora existam alternativas sem ele há anos

Slick (de Ken Wheeler) foi entre 2014 e 2020 o slider JavaScript mais popular. "The last carousel you'll ever need" prometia a documentação. Responsivo, touch-capable, lazy loading, autoplay, infinite scroll, variable width. Para TYPO3 existe com slickcarousel uma extensão que incorpora Slick como elemento de conteúdo. O problema em 2026: Slick depende de jQuery. O último release Slick é de 2017 (v1.8.1). Nenhuma atualização em mais de 8 anos, sem correções de bugs, sem patches de segurança.

jQuery já não é necessário em cada vez menos projetos TYPO3. TYPO3 v12 e v13 não distribuem mais jQuery por padrão. Quem usa Slick Carousel precisa carregar jQuery (90 KB minificado) como dependência adicional, apenas para o slider. Isso é dívida técnica que custa performance a cada carregamento de página.

## Cenários típicos de uso

**Carrosséis de imagens em subpáginas.** Páginas de produto, referências ou galerias com 5 a 20 imagens que podem ser folheadas como slider horizontal. Na prática, dados de analytics mostram que usuários raramente clicam além da terceira imagem.

**Slider de depoimentos.** Citações de clientes que rotacionam como carrossel. Cada slide exibe uma citação, o nome e opcionalmente uma foto. Slick é frequentemente configurado aqui com centerMode e adaptiveHeight.

**Slider de logos para referências de clientes.** Uma faixa horizontal com 10 a 30 logos de clientes em rotação automática. Este cenário é particularmente fácil de substituir por soluções CSS-only (animação CSS com @keyframes), completamente sem JavaScript.

## Arquitetura técnica

A extensão slickcarousel para TYPO3 inclui a biblioteca Slick (slick.min.js, 43 KB) e o CSS correspondente (slick.css + slick-theme.css, 8 KB). jQuery (90 KB) é carregado como dependência. O elemento de conteúdo permite que editores façam upload de imagens e configurem opções do slider: slides to show, autoplay, dots, arrows, efeito fade, breakpoints responsivos.

A integração TYPO3 usa um template Fluid que renderiza as imagens como elementos `<div>` dentro do container do slider.

## Problemas frequentes e soluções

**Slider pula ao carregar (layout shift).** Slick inicializa o slider via JavaScript. Até o script ser carregado e executado, todas as imagens são exibidas empilhadas verticalmente. Depois o layout pula quando Slick organiza as imagens horizontalmente. Isso gera Cumulative Layout Shift (CLS) mensurável, um Core Web Vital. Solução a longo prazo: migrar para uma biblioteca que evita CLS nativamente.

**Eventos touch não funcionam consistentemente.** O tratamento touch do Slick é baseado em uma implementação própria de eventos que não funciona mais corretamente em versões atuais de iOS e Android. Solução: não existe correção, porque Slick não é mais mantido. Migração é a única opção.

**Deficiências de acessibilidade.** Slick gera markup que não é conforme WCAG: labels ARIA ausentes, sem navegação por teclado para dots, autoplay sem botão de pausa. Solução: Splide como alternativa (suporte ARIA completo, navegação por teclado, pausa de autoplay nativa).

## Migração e compatibilidade de versões

A extensão slickcarousel suporta TYPO3 v10 e v11. Para TYPO3 v12 e v13 não existe release oficial (status abril 2026). A biblioteca Slick em si está congelada na v1.8.1 desde 2017.

A Gosign migra sliders baseados em Slick para Swiper (mais de 175 recursos, touch-native, sem jQuery, 40 KB) ou Splide (conforme WCAG, sem jQuery, 30 KB). A migração abrange três etapas: inventariar configurações de slider, incluir e configurar a nova biblioteca, adaptar templates Fluid. Por slider, a migração leva 2 a 4 horas. Em um site com 5 tipos diferentes de slider, o projeto é concluído em 2 a 3 dias.

Para sliders de logo, a Gosign recomenda uma solução CSS pura sem JavaScript: uma animação CSS (`@keyframes scroll`) move os logos horizontalmente, `animation-play-state: paused` no hover para o movimento. O resultado é 0 KB de overhead JavaScript.

A Gosign documenta após cada migração de slider a melhoria de performance: PageSpeed Score antes/depois, remoção de jQuery, delta de Core Web Vitals. Em projetos migrados de Slick para Splide, a melhoria média de PageSpeed foi de 12 a 25 pontos, principalmente pela eliminação do jQuery e pelo menor tamanho da biblioteca.

--- Horários de funcionamento TYPO3 | Gosign ---
> Gerenciamento de horários de funcionamento para TYPO3: horários regulares, feriados, horários especiais. Exibe status atual (aberto/fechado)..

## Besucher wollen wissen, ob eine Einrichtung gerade geöffnet hat, nicht die regulären Zeiten nachschlagen

Die häufigste Frage, die Besucher auf der Website einer Bibliothek, eines Museums oder einer Behörde haben, ist simpel: Haben Sie gerade offen? Trotzdem zeigen die meisten TYPO3-Websites eine statische Tabelle mit den regulären Öffnungszeiten, die an Feiertagen, Brückentagen und Sonderschliessungen falsch ist. slub_web_openhours löst genau dieses Problem. Die Extension verwaltet reguläre Öffnungszeiten, Feiertage und Sonderöffnungszeiten in einer einzigen Datenstruktur und zeigt im Frontend den aktuellen Status in Echtzeit an: Geöffnet (grün) oder Geschlossen (rot), inklusive der nächsten Öffnungszeit. Entwickelt wurde die Extension von der SLUB Dresden (Sächsische Landesbibliothek, Staats- und Universitätsbibliothek), die das Problem aus der Praxis kennt.

## Cenários típicos de uso envolvem Bibliotheken, Museen und kommunale Einrichtungen

Das primäre Szenario sind Hochschulbibliotheken mit mehreren Standorten. Die SLUB Dresden betreibt vier Standorte mit unterschiedlichen Öffnungszeiten. Der Hauptstandort hat andere Zeiten als die Zweigbibliothek, und während der Semesterferien gelten verkürzte Öffnungszeiten. slub_web_openhours verwaltet jeden Standort als eigenen Datensatz mit eigenen Zeiten. Auf der Website sieht ein Student sofort, welcher Standort gerade geöffnet ist und bis wann.

Ein zweites Szenario sind Museen und Galerien. Ein Kunstmuseum hat reguläre Öffnungszeiten (Di-So 10-18 Uhr, Mo geschlossen), aber verlängerte Öffnungszeiten während einer Sonderausstellung (täglich bis 21 Uhr) und Schliessungen an Feiertagen. Die Extension erlaubt, diese Ausnahmen für definierte Zeiträume zu hinterlegen, ohne die regulären Zeiten zu ändern. Nach Ablauf des Sonderzeitraums gelten automatisch wieder die Standardzeiten.

Drittes Szenario: Kommunale Einrichtungen wie Bürgerbüros, Schwimmbäder und Jugendzentren. Eine Stadt mit 20 öffentlichen Einrichtungen pflegt die Öffnungszeiten zentral im TYPO3-Backend. Auf jeder Einrichtungsseite zeigt ein Widget den aktuellen Status. Im Sommer gelten für das Freibad andere Zeiten als im Winter, und an Brückentagen ist das Bürgerbüro geschlossen. All das wird über die Extension abgebildet.

## Arquitetura técnica speichert Regeln und Ausnahmen in einer kalendarischen Datenstruktur

Die Extension definiert drei Datenebenen: reguläre Zeiten (Montag bis Sonntag, Stunde:Minute bis Stunde:Minute), periodische Ausnahmen (Feiertage, die jährlich wiederkehren) und einmalige Ausnahmen (Sonderschliessung am 15. März, verlängerte Öffnung am 24. Dezember). Reguläre Zeiten bilden die Basis, Ausnahmen überschreiben sie. Die Logik ist einfach: Gibt es für das aktuelle Datum eine Ausnahme? Wenn ja, gelten die Ausnahme-Zeiten. Wenn nein, gelten die regulären Zeiten für den aktuellen Wochentag.

Das Frontend-Plugin rendert den Status über Fluid-Templates. Der aktuelle Zustand (offen/geschlossen) wird serverseitig berechnet und als CSS-Klasse ausgegeben, sodass die Farbgebung per Tailwind oder Custom CSS steuerbar ist. Optional zeigt das Widget die nächste Öffnungszeit an: "Aktuell geschlossen. Nächste Öffnung: Montag, 08:00 Uhr."

Für die Schema.org-Integration kann die Extension OpeningHoursSpecification als JSON-LD ausgeben, was Google in den Knowledge-Panel-Einträgen der Organisation anzeigt. Das ist besonders für Einrichtungen relevant, die in Google Maps erscheinen und dort korrekte Öffnungszeiten zeigen wollen.

## Problemas frequentes betreffen Zeitzonen, fehlende Feiertage und Caching

Das häufigste Problem ist das Caching. Wenn TYPO3 die Seite cached und der Cache erst nach zwei Stunden abläuft, zeigt das Widget bis zu zwei Stunden lang den falschen Status. A solução: Das Öffnungszeiten-Widget per USER_INT als uncached Plugin einbinden. Das kostet minimal Performance (eine Datenbankabfrage pro Request), garantiert aber korrekten Status.

Zweites Problem: Fehlende Feiertage. Die Extension liefert keine vorkonfigurierte Feiertagsliste. Jede Einrichtung muss ihre Feiertage manuell eintragen oder über einen Import befüllen. Für bundeslandspezifische Feiertage (Fronleichnam gilt in Bayern, nicht in Berlin) ist manuelle Pflege oder ein Skript nötig, das Feiertage aus einer API (z.B. feiertage-api.de) importiert.

Drittes Thema: Zeitzonen bei internationalen Einrichtungen. Die Extension arbeitet mit der Server-Zeitzone. Wenn der TYPO3-Server in UTC läuft, aber die Einrichtung in MEZ, stimmen die angezeigten Zeiten nicht. A solução: Die PHP-Zeitzone in der TYPO3-Konfiguration auf die Zeitzone der Einrichtung setzen, oder bei Einrichtungen in mehreren Zeitzonen die Berechnung per UTC+Offset im Fluid-Template anpassen.

## Die Extension läuft unter TYPO3 v11 und v12, v13-Support ist vom SLUB-Team abhängig

slub_web_openhours wird von der SLUB Dresden als Open-Source-Projekt gepflegt. Updates folgen dem internen Release-Zyklus der Bibliothek. TYPO3 v12 wird unterstützt. Für v13 hängt die Kompatibilität davon ab, ob das SLUB-Entwicklungsteam die Extension aktualisiert. Da die Extension technisch schlank ist (keine komplexen API-Abhängigkeiten), ist die Migration auf v13 mit geringem Aufwand möglich. A Gosign recomenda bei Öffnungszeiten-Projekten, die Extension parallel zur Schema.org-Ausgabe auf der Google-Seite zu validieren, damit die Öffnungszeiten in Google Maps und im Knowledge Panel korrekt erscheinen.
---

--- solrfal TYPO3 - Indexação de arquivos Solr | Gosign ---
> solrfal para TYPO3: Indexar arquivos no Apache Solr. Configuração, ajuste e migração , acelerado com IA. 25 anos de experiência.

## Por que a busca padrão do TYPO3 capitula diante de grandes acervos de documentos

Assim que uma instalação TYPO3 passa a gerenciar algumas centenas de PDFs, a busca nativa esbarra em dois limites: ela só encontra conteúdos em campos do banco de dados, não em arquivos, e sua lógica de ranqueamento ignora os sinais de relevância de que redatores precisam. O solrfal fecha exatamente essa lacuna ao conectar o File Abstraction Layer (FAL) do TYPO3 diretamente ao Apache Solr, tornando cada arquivo pesquisável junto com seus metadados. A extensão se destina a organizações que tratam documentos como o núcleo do seu trabalho de conhecimento: órgãos públicos com formulários, editoras com literatura técnica, universidades com material didático.

## Cenários típicos de uso

Em uma universidade técnica com cerca de 40.000 estudantes, o regulamento acadêmico está distribuído em 180 arquivos PDF entre doze faculdades. Sem o solrfal, um aluno da USP ou da UFRJ só encontra o trecho sobre inscrição em provas se um redator tiver cadastrado o texto também como meta-descrição. Com o solrfal, o Apache Tika indexa cada página, e a consulta devolve o parágrafo correto com a citação.

Um segundo cenário é conhecido por órgãos públicos federais que publicam leis, diretrizes e formulários em um CMS TYPO3. Os documentos mudam com frequência, e as permissões de acesso estão vinculadas a unidades organizacionais. O solrfal sincroniza automaticamente a associação de fe_groups dos arquivos no índice Solr, de modo que um servidor de uma coordenação específica só vê resultados para os quais tem permissão de leitura.

O terceiro caso aparece em editoras especializadas: uma editora com 12.000 artigos de revista em PDF quer tornar o acervo pesquisável por uma busca facetada por ano, autor e seção. O solrfal extrai os metadados, preenche os campos Solr e fornece a base para uma faceta que extensões TYPO3 clássicas como ke_search não conseguem mais atender nessa escala.

## Arquitetura técnica sob Apache Tika e EXT:solr

O solrfal é uma extensão da extensão principal EXT:solr, da dkd Internet Service, e exige obrigatoriamente um Apache Solr Server em execução, tipicamente na versão 8 ou 9. A extração de texto propriamente dita é feita pelo Apache Tika, seja como serviço embutido no contêiner Solr, seja como servidor Tika autônomo. O solrfal se conecta ao ciclo de vida do FAL via TYPO3 Event API: cada arquivo enviado, movido ou removido dispara um job de indexação, processado de forma assíncrona pelo scheduler do TYPO3.

A configuração do solrfal é feita via TypoScript e Extension Configuration. O schema Solr pode ser ajustado via Managed Schema API, de modo que campos adicionais como tipo de documento, departamento ou idioma podem ser incluídos sem reiniciar o Solr. O ajuste de relevância acontece por meio de boosting queries e function queries, definidas na configuração de consultas da EXT:solr. O solrfal herda todas as features multilíngues da EXT:solr, incluindo analyzers para português, alemão, inglês, francês e outros idiomas padrão.

## Problemas frequentes e soluções

O primeiro problema costuma surgir na indexação inicial: o Apache Tika quebra com PDFs corrompidos ou criptografados, gerando um OutOfMemoryError que derruba todo o indexador. A extensão marca o arquivo como defeituoso e não o ignora automaticamente na próxima execução. Analisamos os logs do Tika, separamos os arquivos realmente defeituosos dos apenas criptografados e configuramos um pre-check que descarta arquivos problemáticos antes que cheguem ao indexador.

O segundo tema recorrente é relevância. Equipes relatam que a busca encontra todos os documentos, mas os resultados irrelevantes aparecem no topo. O motivo quase sempre está no peso padrão dos campos: o solrfal indexa todo o conteúdo do arquivo em um único campo, sem distinguir título, cabeçalhos e corpo. Uma solução limpa exige um schema ajustado com campos separados para título, metadados e corpo, além de regras de boosting que priorizem correspondências no título.

O terceiro problema afeta performance em acervos grandes. A partir de cerca de 50.000 arquivos indexados, o scheduler vira gargalo porque o solrfal processa cada job individualmente. A solução é indexação em lote combinada com um worker dedicado que roda paralelamente às tarefas normais do scheduler e prioriza os jobs do solrfal. Vale também uma indexação diferencial, que em cada execução reprocessa apenas arquivos novos ou alterados, reduzindo significativamente o esforço de manutenção em acervos estáveis.

Um quarto tema, mais raro, aparece em instalações multilíngues: o solrfal indexa arquivos de forma independente do idioma em um índice comum, de modo que um estudo em francês aparece na lista de resultados em português se o termo de busca for internacional. Uma separação de idiomas limpa exige múltiplos cores Solr ou uma faceta de idioma adicional, que pode ser controlada por site-root via configuração da EXT:solr.

## Migração e compatibilidade de versões

O solrfal segue o ciclo de releases da EXT:solr, que atualmente suporta TYPO3 v12 e v13. O salto do TYPO3 v9 para v12 é o caminho de migração mais comum e quase sempre implica também um salto do Solr 6 para o Solr 9. Com isso, mudam o formato do schema, a Managed Schema API e algumas classes de analyzer, exigindo um reindex completo. Regras de boosting existentes precisam ser validadas contra o novo comportamento do query parser, já que o Solr 9 avalia certos operadores padrão de forma diferente do Solr 6.

Quem migra de ke_search ou de uma busca puramente baseada em banco de dados precisa considerar que o solrfal exige um Solr Server próprio, o que amplia os requisitos de hospedagem. A Gosign acompanha essas migrações há anos e assume, se necessário, a troca para um setup Solr baseado em contêineres, que se integra a pipelines de deploy existentes.

Também é importante notar que a carga de manutenção do solrfal não deve ser subestimada: o próprio Solr recebe atualizações de segurança regulares, e o schema precisa ser validado contra novas classes de analyzer a cada upgrade maior. Um projeto que opta pelo solrfal assume a responsabilidade por um stack de busca próprio e deve considerar isso no sizing inicial e no planejamento dos recursos operacionais.

--- sr_freecap TYPO3 - CAPTCHA auto-hospedado | Gosign ---
> Extensão CAPTCHA para TYPO3 sem serviços externos. Proteção contra spam auto-hospedada, em conformidade com a LGPD, sem envio de dados ao Google.

## Por que órgãos públicos e hospitais brasileiros dependem de proteção CAPTCHA auto-hospedada

O reCAPTCHA do Google é tecnicamente eficaz, mas juridicamente problemático para muitos operadores no Brasil: cada integração leva à transmissão de dados pessoais ao Google nos EUA, exige consentimento ativo nos termos da LGPD e é visto com ceticismo por autoridades de proteção de dados. O sr_freecap é a resposta a esse problema: uma extensão CAPTCHA totalmente auto-hospedada para TYPO3, que não dispara requisições externas, não transmite dados do usuário a terceiros e, portanto, trabalha sem bloqueio por banner de consentimento. O público-alvo são órgãos públicos, hospitais, universidades e empresas com consciência de privacidade que precisam proteger formulários contra spam de bots sem criar uma nova dependência de um serviço estrangeiro.

## Cenários típicos de uso

Um hospital universitário, vinculado a uma faculdade de medicina como a USP ou a UFRJ, opera um formulário de contato para solicitações de pacientes, um formulário de candidatura para equipe de enfermagem e um formulário de pedidos de imprensa. Os três são regularmente atacados por bots que enviam mensagens publicitárias genéricas ou tentativas de phishing. A TI do hospital decidiu não incorporar serviços do Google, porque o encarregado de proteção de dados quer evitar a exigência de consentimento. O sr_freecap gera imagens com combinações de letras no servidor, valida a entrada no próprio servidor e não envia informação alguma para fora em momento algum.

Um segundo caso é uma prefeitura com cerca de 15 formulários online para serviços ao cidadão, da comunicação de mudança à solicitação de alvará de estacionamento residencial. A ANPD (PT: CNPD) recomendou em um audit explícito evitar CAPTCHAs externos. O sr_freecap se integra à Form API do TYPO3 (Powermail ou o Form Framework) e protege assim todos os formulários sem consentimento adicional.

O terceiro contexto são conselhos profissionais e associações, como CREA, CRM ou OAB regionais, que mantêm listas de associados, endereços ou registros públicos. Cada uma dessas organizações opera um formulário de busca ou contato que precisa ser protegido contra bots, mantendo simultaneamente a postura de privacidade. O sr_freecap fornece um teste visual simples, fácil de resolver para humanos e representando uma barreira perceptível para bots OCR simples.

## Arquitetura técnica: biblioteca GD, sessão e Form API

O sr_freecap gera imagens CAPTCHA no servidor com a biblioteca GD ou ImageMagick, sendo GD a opção padrão, disponível em praticamente qualquer instalação PHP sem esforço adicional. As letras são sorteadas de um alfabeto configurável, desenhadas em uma imagem com ruído de fundo e distorção, e entregues ao navegador. O texto esperado é armazenado na sessão TYPO3 e comparado com a entrada do usuário no envio do formulário.

A integração em formulários ocorre via validator para o TYPO3 Form Framework e via API do Powermail, inserindo o campo como elemento adicional na definição de formulário. CAPTCHAs de áudio como alternativa de acessibilidade estão disponíveis, mas desativados por padrão, e devem ser ativados em formulários com público amplo para não excluir usuários com deficiência visual. O sr_freecap é configurado via TypoScript, que controla o comprimento da string CAPTCHA, as fontes utilizadas e o nível de ruído.

## Problemas frequentes e soluções

O primeiro problema é legibilidade versus segurança. Se o CAPTCHA tiver ruído excessivo, até usuários humanos falham e abandonam o formulário, o que reduz perceptivelmente a taxa de conversão. Se tiver pouco ruído, engines OCR modernos leem o texto em segundos. A solução prática está em uma distorção moderada combinada com um campo honeypot, que fica como um campo invisível no formulário. Humanos não preenchem, bots frequentemente preenchem, e esses envios são descartados em silêncio.

O segundo problema envolve acessibilidade. Um CAPTCHA puramente visual exclui usuários cegos ou com baixa visão, o que, em instituições públicas, pode ser uma infração contra normas de acessibilidade digital previstas na legislação brasileira e nas diretrizes do e-MAG. A ativação do modo de áudio e, adicionalmente, uma simples conta matemática como alternativa criam caminhos acessíveis para cumprir o requisito sem abrir mão de proteção.

O terceiro tema é gerenciamento de sessão. O sr_freecap armazena a solução esperada na sessão PHP, o que gera erros em Load Balancers sem session affinity ou em instalações TYPO3 hospedadas em modo stateless. A solução é Sticky Sessions no Load Balancer ou um backend de sessão compartilhado como Redis, compartilhado por todos os nós.

Um quarto problema é a eficácia contra frameworks modernos de bot. Headless browsers simples como Puppeteer não resolvem CAPTCHAs visuais sozinhos, mas podem encaminhar a tarefa a um serviço externo de resolução, que retorna a resposta correta em segundos. Contra esses ataques, um CAPTCHA puramente de reconhecimento de imagem não basta, e uma combinação com checks comportamentais como análise de movimento do mouse ou o honeypot mencionado é a defesa mais eficaz.

## Migração e compatibilidade de versões

O sr_freecap é uma das extensões CAPTCHA mais antigas para TYPO3 e tem histórico agitado: para TYPO3 v11 e v12 existem forks comunitários mantidos, e a compatibilidade com v13 varia de fork para fork. Quem migra agora para v12 ou v13 deve, antes do upgrade, verificar se o próprio ramo da extensão é mantido ativamente e, na dúvida, mudar para outra abordagem CAPTCHA.

Alternativas ao sr_freecap dentro do espectro amigo da privacidade são hCaptcha (com variante auto-hospedada), Friendly Captcha de desenvolvimento europeu e campos honeypot combinados com rate limiting no servidor. A Gosign orienta a escolha conforme o volume de formulários, o perfil de usuários e a exigência regulatória, e monta, se necessário, uma solução híbrida que filtra o tráfego de bots primeiro via honeypot e envia só envios suspeitos ao passo do CAPTCHA.

Para instituições que não podem integrar serviços externos por razões regulatórias, uma solução auto-hospedada como o sr_freecap frequentemente continua sendo a única escolha prática, e o esforço de manutenção é moderado. É importante ajustar a proteção CAPTCHA regularmente aos padrões atuais de spam e avaliar a estatística de tentativas fracassadas, para reconhecer quando um upgrade da distorção ou uma combinação com outras medidas de proteção se torna apropriado.

--- Storytelling TYPO3 - Scrollytelling | Gosign ---
> Scrollytelling-Extension para TYPO3: Parallax scrolling, blocos de conteúdo animados, animações acionadas por scroll. Para experiências de conteúdo imersivas,.

## Jahresberichte und Produktpräsentationen brauchen mehr als Text und Bild

Statische Seiten mit langen Textblöcken funktionieren für Dokumentation und Blog-Artikel. Aber Jahresberichte, Produktlaunches und Unternehmensgeschichten brauchen ein Format, das den Besucher durch eine Erzählung führt. Scrollytelling, also Storytelling über Scroll-Interaktion, hat sich als das Format etabliert, das zwischen statischem Text und aufwändigem Video liegt. Die TYPO3 Storytelling-Extension bringt Parallax-Scrolling, animierte Inhaltsblöcke und Scroll-Trigger-Animationen direkt ins CMS, ohne dass ein externer Dienst oder eine Agentur pro Seite ein Unikat programmieren muss.

Der Vorteil gegenüber einer Custom-Entwicklung: Redakteure können Inhalte im TYPO3-Backend pflegen, Blöcke umsortieren und Animationen konfigurieren, ohne den Entwickler zu involvieren.

## Cenários típicos de uso são Jahresberichte, Produktlaunches und Kampagnen-Landingpages

Das prominenteste Szenario sind digitale Jahresberichte. Unternehmen, Stiftungen und NGOs veröffentlichen ihre Geschäftszahlen zunehmend als interaktive Web-Story statt als PDF. Ein Scrollytelling-Jahresbericht zeigt im ersten Abschnitt die Headline-Zahl (Umsatz, Spendenvolumen, Mitgliederzahl), die beim Scrollen animiert hochzählt. Im zweiten Abschnitt erscheinen Diagramme mit Vergleichszahlen zum Vorjahr. Im dritten Abschnitt erzählen Porträtfotos und Zitate die Geschichte hinter den Zahlen. Die gesamte Story ist eine einzige Seite, die der Besucher durchscrollt.

Ein zweites Szenario sind Produktpräsentationen im B2B-Bereich. Ein Maschinenbauer stellt eine neue Fertigungsanlage vor. Beim Scrollen dreht sich das 3D-Rendering der Maschine, technische Daten blenden sich ein, Animationen zeigen den Produktionsprozess. Das ist kein Video (kein Laden, kein Buffering), sondern eine Scroll-gesteuerte Animation, die der Besucher in seinem eigenen Tempo durchgeht.

Drittes Szenario: Kampagnen-Landingpages. Eine Hilfsorganisation zeigt den Weg einer Spende: vom Klick auf den Spendenbutton über die Projektauswahl bis zum Bericht aus dem Zielland. Jeder Scroll-Abschnitt enthält ein Foto, einen kurzen Text und eine Animation, die den Fortschritt visualisiert.

## Arquitetura técnica rendert Sektionen als Scroll-gesteuerte Content-Blöcke

Die Extension definiert einen eigenen Content-Element-Typ "Storytelling", der aus Sektionen besteht. Jede Sektion ist ein Backend-Record mit Feldern für Headline, Text, Bild/Video (FAL), Hintergrundfarbe, Animationstyp und Scroll-Trigger. Die Sektionen werden im Backend sortiert und bilden zusammen die Scroll-Story.

Im Frontend rendert jede Sektion einen eigenen Viewport-füllenden Abschnitt. Animationen werden über CSS-Transitions und den IntersectionObserver ausgelöst: Wenn eine Sektion in den sichtbaren Bereich scrollt, startet die konfigurierte Animation (Fade-In, Slide-Left, Zoom, Counter). Parallax-Effekte verschieben Hintergrundbilder langsamer als den Vordergrund, was Tiefenwirkung erzeugt.

Die Extension liefert ein Set von vordefinierten Animationen mit. Custom Animationen lassen sich über CSS-Klassen ergänzen, die im Backend als Animationstyp auswählbar sind. Die JavaScript-Basis ist minimal: kein Framework, nur native IntersectionObserver und requestAnimationFrame. Das hält die Bundle-Grösse unter 20 KB.

Für die Performance ist entscheidend, dass Bilder lazy geladen werden. Ein Scrollytelling-Bericht mit 15 Sektionen und je einem hochauflösenden Bild erzeugt ohne Lazy Loading 30 bis 50 MB an Requests. Mit Lazy Loading lädt der Browser nur die sichtbare und die nächste Sektion.

## Problemas frequentes betreffen mobile Performance und die acessibilidade

Das grösste Problem bei Scrollytelling auf Mobilgeräten ist die Performance. Parallax-Effekte, die auf Desktop flüssig laufen, ruckeln auf älteren Smartphones. Der Grund: Mobile Browser rendern Scroll-Events anders als Desktop-Browser und drosseln requestAnimationFrame im Hintergrund. A solução: Parallax auf mobilen Viewports deaktivieren und durch einfache Fade-In-Animationen ersetzen. Die Extension sollte über TypoScript konfigurierbar sein, welche Animationen auf welchen Breakpoints aktiv sind.

Zweites Problem: acessibilidade (WCAG 2.1). Scroll-gesteuerte Animationen sind für Nutzer mit vestibulären Störungen (Schwindel, Übelkeit bei Bewegung) problematisch. CSS prefers-reduced-motion muss respektiert werden. Die Extension sollte bei aktivierter Reduce-Motion-Einstellung alle Animationen deaktivieren und die Inhalte als statische Blöcke anzeigen. Nicht alle Storytelling-Extensions implementieren das korrekt.

Drittes Thema: SEO. Google kann JavaScript-basierte Animationen crawlen, aber der Inhalt muss auch ohne JavaScript zugänglich sein. Die Sektionen müssen als reguläre HTML-Blöcke gerendert werden, nicht als leere Container, die erst per JavaScript befüllt werden. Die Extension sollte Progressive Enhancement verfolgen: Erst der Inhalt, dann die Animation.

## TYPO3 v12 wird unterstützt, v13 erfordert ein Update der Content-Element-Registrierung

Scrollytelling-Extensions für TYPO3 gibt es in verschiedenen Varianten von verschiedenen Anbietern. Die Kompatibilität mit v12 ist bei aktiv gepflegten Extensions gegeben. Für v13 ist ein Update der Content-Element-Registrierung (NewContentElementWizard) und der TCA-Konfiguration nötig, weil v13 die FlexForm-basierte Content-Element-Konfiguration angepasst hat. A Gosign utiliza bei neuen Scrollytelling-Projekten auf eine Architektur, die die Animationslogik als eigenständiges JavaScript-Modul von der TYPO3-Integration trennt, um bei zukünftigen Upgrades nur die TYPO3-Schicht anpassen zu müssen.
---

--- Stundenplan TYPO3 - Escolas | Gosign ---
> Exibição tabular de grade horária para escolas e instituições de ensino. Visualização diária/semanal, filtro por matéria/professor/turma. Responsivo.

## Schulen publizieren Stundenpläne als PDF, obwohl eine digitale Lösung allen Beteiligten Zeit spart

Die meisten Schulen in Deutschland erstellen ihren Stundenplan mit Software wie Untis, exportieren ihn als PDF und laden ihn auf die Website. Eltern, Schüler und Lehrkräfte scrollen durch eine unleserliche Tabelle, die auf dem Smartphone nicht skaliert. Änderungen (Vertretung, Raumtausch, Ausfall) erfordern einen neuen PDF-Upload. Die TYPO3 Stundenplan-Extension ersetzt diesen Workflow durch eine digitale Darstellung direkt auf der Website: Tages- und Wochenansicht, Filter nach Fach, Lehrer und Klasse, responsive Darstellung auf allen Geräten, druckbare Ansicht für das Lehrerzimmer.

Für Schulträger, die ihre Schulwebsites zentral auf TYPO3 betreiben, ist das eine skalierbare Lösung für zehn, zwanzig oder fünfzig Schulen gleichzeitig.

## Cenários típicos de uso vão von der einzelnen Grundschule bis zum Schulverbund

Das Basisszenario ist die einzelne Schule mit 20 Klassen, 40 Lehrkräften und einem Stundenplan, der sich wöchentlich ändert. Die Verwaltung pflegt den Stundenplan im TYPO3-Backend oder importiert ihn aus Untis. Auf der Website sehen Eltern die Wochenansicht der Klasse ihres Kindes. Der Filter reduziert die Ansicht auf eine Klasse, ein Fach oder eine Lehrkraft. Vertretungen werden als farblich markierte Änderungen angezeigt, sodass Eltern morgens auf einen Blick sehen, ob der Unterricht regulär stattfindet.

Ein zweites Szenario sind Schulverbünde und Schulträger mit zentraler TYPO3-Installation. Eine Stadt betreibt 15 Schulwebsites auf einer Multi-Site-TYPO3-Instanz. Jede Schule hat eigene Stundenpläne, aber die Darstellung ist einheitlich. Die Extension wird einmal konfiguriert und per TypoScript-Vererbung auf alle Schulseiten ausgerollt. Neue Schulen werden mit derselben Konfiguration aufgesetzt.

Drittes Szenario: Volkshochschulen und Weiterbildungseinrichtungen. Eine VHS bietet 200 Kurse pro Semester an. Der Stundenplan zeigt, welcher Kurs an welchem Wochentag in welchem Raum stattfindet. Teilnehmer filtern nach Kursbereich (Sprachen, IT, Gesundheit) und sehen ihre persönliche Wochenansicht. In Kombination mit einem Login können registrierte Teilnehmer nur ihre gebuchten Kurse sehen.

## Arquitetura técnica speichert Stundenplandaten als strukturierte Records

Die Extension definiert mehrere Tabellen: Klassen, Lehrkräfte, Fächer, Räume und Stunden. Jede Stunde ist ein Record mit Verknüpfungen zu Klasse, Lehrkraft, Fach, Raum, Wochentag und Zeitfenster. Die Daten werden entweder manuell im Backend gepflegt oder über einen CSV/XML-Import aus Stundenplan-Software importiert.

Das Frontend-Plugin rendert die Daten als HTML-Tabelle mit der Wochentag-Zeitfenster-Matrix. Filter (Klasse, Lehrkraft, Fach) werden per GET-Parameter übergeben und serverseitig verarbeitet. Die Tabelle ist per CSS responsive: Auf Desktop zeigt sie die volle Wochenansicht, auf Mobilgeräten wird auf eine Tagesansicht umgeschaltet oder horizontal scrollbar gemacht.

Die Druckansicht erzeugt eine optimierte Darstellung ohne Navigation und Footer, mit Seitenumbrüchen zwischen den Wochentagen. Per Print-CSS wird die Tabelle auf A4-Querformat optimiert.

Für den Import aus Untis existieren Community-Lösungen, die den Untis-XML-Export parsen und in die TYPO3-Datenbankstruktur schreiben. Der Import kann als Scheduler-Task konfiguriert werden, sodass Änderungen in Untis automatisch auf der Website erscheinen.

## Problemas frequentes betreffen die Datenpflege und die mobile Darstellung

Das grösste Problem ist die laufende Datenpflege. Stundenpläne ändern sich wöchentlich, Vertretungen täglich. Wenn die Daten manuell im TYPO3-Backend gepflegt werden, ist der Aufwand bei 20 Klassen mit je 30 Wochenstunden erheblich. A solução: Einen automatisierten Import aus der Stundenplan-Software einrichten. Ohne diesen Import ist die Extension nur für kleine Einrichtungen mit wenigen Klassen praktikabel.

Zweites Problem: Die mobile Darstellung. Eine Stundenplan-Tabelle mit fünf Spalten (Mo-Fr) und zehn Zeilen (Stunden) passt nicht auf einen 375 Pixel breiten Smartphone-Bildschirm. Horizontales Scrollen ist die pragmatische Lösung, aber Eltern finden es unintuativ. Besser: Auf mobilen Viewports automatisch auf die Tagesansicht umschalten (nur der aktuelle Tag), mit Wisch-Gesten für den Tageswechsel.

Drittes Thema: proteção de dados. Wenn Lehrkräfte namentlich im öffentlichen Stundenplan erscheinen, kann das datenschutzrechtlich problematisch sein. Manche Schulen zeigen deshalb nur Fach und Klasse, nicht den Lehrernamen. Die Extension sollte per Konfiguration steuern, welche Felder im Frontend angezeigt werden.

## Die Extension ist eine Nischenlösung ohne aktive Community-Pflege

Stundenplan-Extensions für TYPO3 sind Nischenprodukte mit kleiner Community. TYPO3 v12-Kompatibilität ist bei neueren Versionen gegeben, aber eine aktive Weiterentwicklung für v13 ist nicht garantiert. Schulen und Schulträger, die langfristig planen, sollten evaluieren, ob eine Custom-Entwicklung auf Basis von Standard-TYPO3-Content-Elementen (Extbase-Records + Fluid-Templates) nicht nachhaltiger ist als eine Community-Extension mit ungewissem Wartungshorizont. A Gosign orienta Bildungseinrichtungen und Schulträger bei der Wahl zwischen Community-Extension, Custom-Entwicklung und dedizierten Stundenplan-SaaS-Lösungen mit TYPO3-Anbindung.
---

--- Styleguide TYPO3 - Extensão de QA | Gosign ---
> Extensão do core TYPO3 que visualiza todos os elementos de conteúdo em uma página.

## Por que Styleguide é a extensão de QA mais importante para desenvolvedores de templates TYPO3

O desenvolvimento de templates no TYPO3 tem um problema sistemático de qualidade: desenvolvedores testam seus templates Fluid com os dados que existem atualmente no site. Mas elementos de conteúdo têm dezenas de variantes - headlines com e sem subheadline, blocos de texto com 3 palavras ou 3 parágrafos, imagens em formato retrato e paisagem, tabelas com 2 ou 20 colunas. Quem verifica apenas a página atual perde os edge cases que só aparecem após o lançamento.

A extensão Styleguide resolve esse problema apresentando automaticamente todos os elementos de conteúdo do sistema TYPO3 em cada configuração disponível em uma única página. Assim, o desenvolvedor vê imediatamente se seu CSS e seus templates cobrem corretamente todas as variantes.

## Cenários típicos de uso

**Desenvolvimento de templates em projetos de relançamento.** Uma empresa encomenda um relançamento TYPO3 com novo design corporativo. O desenvolvedor frontend cria templates Fluid para todos os elementos de conteúdo. Sem Styleguide, ele precisa criar dados de teste no backend para cada elemento - um processo que com mais de 30 elementos leva horas. Styleguide gera todos os dados de teste automaticamente.

**Testes de regressão após atualizações TYPO3.** Uma atualização TYPO3 de v11 para v12 altera sutilmente a renderização de elementos de conteúdo individuais. Sem Styleguide, isso só é percebido quando um editor reporta o erro em uma página live. Com Styleguide, o desenvolvedor vê imediatamente após a atualização quais elementos mudaram.

**Alinhamento entre equipe de design e desenvolvimento.** Designers entregam mockups Figma para 10 elementos de conteúdo. Mas como ficam os 25 elementos padrão restantes no novo design? Styleguide torna essa lacuna visível: todos os elementos são apresentados em uma página, designs ausentes são identificados imediatamente. A Gosign usa Styleguide em cada projeto de relançamento como ferramenta de aprovação para a equipe de design.

## Arquitetura técnica

Styleguide é uma extensão oficial do TYPO3 Core System, distribuída com o código-fonte TYPO3. Precisa apenas ser ativada no Extension Manager.

A extensão trabalha em dois níveis: o TCA Generator analisa as definições Table Configuration Array de todos os elementos de conteúdo registrados e gera registros de teste. O módulo de backend permite gerar, atualizar e excluir os dados de teste. Uma página especial na árvore de páginas exibe todos os elementos gerados no layout frontend.

Styleguide não tem dependências externas. Como extensão Core, é atualizada automaticamente com cada atualização TYPO3 e é sempre compatível com a respectiva versão. Importante: Styleguide não gera dados de teste para Custom Content Elements (como Mask ou DCE). Cobre apenas elementos Core.

## Problemas frequentes e soluções

**Página Styleguide mostra áreas vazias.** Os dados de teste foram gerados, mas a página frontend não exibe todos os elementos. Causa: o SysFolder com os dados de teste não está corretamente configurado como ponto de partida. Solução: verificar no módulo de backend se a árvore de páginas foi criada corretamente.

**Imagens faltam nos dados de teste gerados.** Styleguide tenta incluir imagens de teste via FAL. Se a pasta fileadmin está vazia ou a configuração de storage padrão não está correta, campos de imagem ficam vazios. Solução: fazer upload manual de pelo menos uma imagem no fileadmin antes de gerar os dados de teste.

**Problemas de performance na página Styleguide.** Quando todos os elementos de conteúdo são renderizados em uma página, o tempo de carregamento com templates complexos pode chegar a 10 a 15 segundos. Solução: ativar Styleguide apenas no ambiente de desenvolvimento ou staging, nunca no sistema live.

## Migração e compatibilidade de versões

Styleguide está disponível como Core System Extension desde TYPO3 v8 e é atualizado automaticamente com cada versão TYPO3. Não há números de versão separados ou problemas de compatibilidade.

Em um upgrade TYPO3, os dados de teste Styleguide devem ser regenerados após a atualização. O módulo de backend oferece uma função "Reset" para isso. Para TYPO3 v12 e v13, Styleguide está disponível sem restrições.

A Gosign integra Styleguide em cada relançamento TYPO3 como parte fixa do processo de QA. A página Styleguide é criada no ambiente de staging como referência permanente e serve à equipe de design como URL de aprovação.

--- t3skin TYPO3 - Estilo do backend | Gosign ---
> Skin de backend legado para versões mais antigas do TYPO3. A partir do TYPO3 v7+ não é mais relevante. Versões modernas do TYPO3 têm estilo de backend próprio.

## t3skin ist seit TYPO3 v7 obsolet, aber viele Installationen laufen noch auf Versionen, die es brauchen

t3skin war das Backend-Styling-Paket für TYPO3 v4 und v6. Es definierte Icons, Farben, Abstände und das gesamte Look-and-Feel des TYPO3-Backends. Ab TYPO3 v7 wurde das Backend-Styling in den Core integriert, t3skin als separate Extension wurde überflüssig. Trotzdem taucht t3skin in Bestandsanalysen regelmässig auf, weil es in alten Installationen installiert ist und beim Upgrade auf aktuelle TYPO3-Versionen Fehler verursacht. Wer t3skin in seiner Extension-Liste findet, hat ein klares Signal: Diese Installation ist entweder veraltet oder wurde bei einem früheren Upgrade nicht vollständig aufgeräumt.

## Cenários típicos de uso envolvem ausschliesslich Legacy-Installationen

Das einzige legitime Szenario für t3skin ist eine TYPO3-Installation auf Version 4.5 bis 6.2, die aus technischen oder organisatorischen Gründen nicht aktualisiert werden kann. In solchen Installationen liefert t3skin das Backend-Design. Ohne t3skin wäre das Backend visuell unbrauchbar: fehlende Icons, kaputte Layouts, unlesbare Formulare.

Ein zweites Szenario ist die Übergangsphase während einer Migration. Wenn eine Agentur eine TYPO3-v6-Installation auf v12 migriert, existiert t3skin während des Upgrade-Prozesses noch in der Extension-Liste, wird aber nach dem Upgrade deaktiviert und entfernt. In dieser Phase kann t3skin Konflikte mit dem neuen Backend-Styling verursachen, wenn es nicht rechtzeitig deinstalliert wird.

Ein drittes (Anti-)Szenario: Manche Administratoren haben t3skin in TYPO3 v7 oder v8 manuell installiert, weil sie das alte Backend-Design bevorzugten. Das funktionierte kurzfristig, erzeugte aber Darstellungsfehler, weil t3skin-CSS und Core-CSS sich widersprachen. Spätestens ab TYPO3 v9 ist das keine Option mehr.

## Arquitetura técnica war ein CSS/Icon-Paket ohne Geschäftslogik

t3skin war keine Extension im klassischen Sinne (kein Controller, kein Model, kein Repository). Es bestand aus CSS-Dateien, Icon-Sprites, ein paar JavaScript-Snippets für die Backend-Oberfläche und einer ext_emconf.php, die es als System-Extension registrierte. Die gesamte Logik war visuell: Farben, Schriften, Abstände, Icons. Der TYPO3-Core renderte die Backend-Module, t3skin bestimmte nur, wie sie aussahen.

Ab TYPO3 v7 übernahm der Core diese Aufgabe selbst. Das Backend-Styling wurde in das System-Extension-Paket backend integriert. Icons wurden auf ein SVG-basiertes Icon-System umgestellt (IconFactory), CSS wurde auf Less und später auf SCSS migriert. t3skin konnte diese Änderungen nicht abbilden, weil es auf dem alten Sprite-basierten Icon-System basierte.

## Problemas frequentes entstehen, wenn t3skin bei einem Upgrade nicht entfernt wird

Das häufigste Problem ist ein weisses oder kaputtes Backend nach einem TYPO3-Upgrade. Wenn t3skin in einer v12-Installation noch installiert ist, überschreibt es Core-CSS-Dateien mit veralteten Regeln. Das Ergebnis: Buttons ohne Hintergrund, Icons die nicht laden, Modul-Navigationen die nicht klickbar sind. A solução: t3skin über den Extension Manager deinstallieren und die Tabellen-Einträge in sys_registry bereinigen. Wenn das Backend so kaput ist, dass der Extension Manager nicht erreichbar ist, hilft die Deaktivierung über die Kommandozeile: typo3/sysext/core/bin/typo3 extension:deactivate t3skin.

Zweites Problem: Verwaiste CSS-Dateien. Auch nach der Deinstallation von t3skin können CSS-Dateien in fileadmin/ oder typo3temp/ zurückbleiben, die der Browser cached. Ein vollständiger Cache-Clear (Browser-Cache, TYPO3-Cache, CDN-Cache) ist nach der Entfernung nötig.

Drittes Thema: Backend-Anpassungen, die auf t3skin aufbauen. Manche Agenturen haben in TYPO3 v6 Custom Backend CSS geschrieben, das t3skin-Klassen als Basis nutzt. Nach der Entfernung von t3skin brechen diese Anpassungen. A solução: Custom Backend CSS auf die aktuellen Core-CSS-Klassen migrieren.

## t3skin hat keinen Upgrade-Pfad, die Migration bedeutet Entfernung

Es gibt kein Update von t3skin auf eine aktuelle Version, weil die Extension keinen Nachfolger hat. Der Nachfolger ist der TYPO3-Core selbst. Die Migration bedeutet: t3skin deinstallieren, alle Referenzen auf t3skin-CSS-Klassen in Custom Backend Modulen entfernen, und die IconFactory für Custom Icons nutzen. Gosign führt diese Bereinigung im Rahmen jeder TYPO3-Migration durch und prüft dabei, ob weitere Legacy-Extensions (css_styled_content, rtehtmlarea, adodb) in der Installation verblieben sind, die ebenfalls entfernt werden müssen.
---

--- Copyright Bilder TYPO3 | Gosign ---
> Adicionar avisos de copyright automaticamente às imagens. Ler metadados IPTC/EXIF, exibir como overlay ou rodapé. Rechtskonformer Umgang.

## Fehlende Bild-Copyrights kosten Unternehmen jedes Jahr Tausende Euro in Abmahnungen

Stockfoto-Agenturen wie Getty Images, Adobe Stock und Mauritius setzen systematisch Webcrawler ein, die das Internet nach unlizenziert oder falsch attributierten Bildern durchsuchen. Fehlende Copyright-Hinweise sind der häufigste Grund für Abmahnungen. Je nach Agentur und Bild liegen die Forderungen zwischen 500 und 5.000 Euro pro Bild. Bei einer Website mit 200 Stockfotos kann ein einziger Audit-Durchlauf der Agentur fünfstellige Nachforderungen erzeugen. tgm_copyright automatisiert die Copyright-Kennzeichnung in TYPO3: Die Extension liest IPTC- und EXIF-Metadaten aus Bilddateien aus und zeigt den Copyright-Hinweis automatisch als Overlay oder Fusszeile an. Jedes Bild, das über FAL (File Abstraction Layer) verwaltet wird, bekommt seinen Rechtehinweis, ohne dass Redakteure manuell eingreifen müssen.

## Cenários típicos de uso abrangem Unternehmenswebsites, Verlage und öffentliche Einrichtungen

Das häufigste Szenario ist die Unternehmenswebsite mit 100 bis 500 Bildern aus verschiedenen Quellen: eigene Fotos, Stockbilder von Adobe Stock, Pressefotos von Kunden, Illustrationen von Freelancern. Jedes Bild hat andere Lizenzanforderungen. Manche verlangen eine Namensnennung ("Foto: Max Mustermann"), andere eine Quellenangabe ("Quelle: Adobe Stock"), wieder andere nur ein Copyright-Zeichen. tgm_copyright liest die Informationen aus den IPTC-Feldern (Creator, Copyright Notice, Source) und zeigt sie im konfigurierten Format an.

Ein zweites Szenario sind Verlage und Medienhäuser. Eine Regionalzeitung publiziert täglich 30 bis 50 Bilder. Die Fotografen liefern ihre Bilder mit eingebetteten IPTC-Daten. Die Extension zeigt automatisch "Foto: [Fotografenname]" unter jedem Bild an. Das spart der Redaktion fünf bis zehn Minuten pro Artikel, weil der Copyright-Hinweis nicht manuell eingetippt werden muss.

Drittes Szenario: Öffentliche Einrichtungen, die Creative-Commons-Bilder nutzen. CC-Lizenzen erfordern eine korrekte Attribution (Urheber, Lizenztyp, Link zur Lizenz). tgm_copyright kann diese Informationen aus den Metadaten lesen und als formatierte Fusszeile mit Lizenz-Link ausgeben.

## Arquitetura técnica nutzt die FAL-Metadaten und ein Fluid-ViewHelper-System

tgm_copyright registriert sich als TYPO3-Extension und greift auf die sys_file_metadata-Tabelle zu. Wenn ein Bild über FAL in TYPO3 hochgeladen wird, extrahiert die Extension automatisch die IPTC- und EXIF-Felder und schreibt sie in die Metadaten-Felder der FAL-Tabelle. Die relevanten IPTC-Felder sind: Creator (Fotograf), Copyright Notice (Rechteinhaber), Source (Quelle), Description (Bildunterschrift) und Credit (Agentur).

Im Frontend stellt die Extension einen Fluid-ViewHelper bereit, der den Copyright-Hinweis zu jedem Bild rendert. Der ViewHelper kann als Overlay (halbtransparente Leiste am unteren Bildrand), als Fusszeile (Text unter dem Bild) oder als Tooltip (Hover-Effekt) konfiguriert werden. Das Styling ist über CSS-Klassen steuerbar, sodass der Copyright-Hinweis zum Design der Website passt.

Für Bilder ohne eingebettete Metadaten bietet die Extension ein Fallback: Redakteure können im FAL-Metadaten-Dialog den Copyright-Hinweis manuell eintragen. Die Extension priorisiert manuelle Einträge über automatisch ausgelesene Metadaten, sodass fehlerhafte IPTC-Daten überschrieben werden können.

## Problemas frequentes betreffen fehlende Metadaten und Overlay-Platzierung

Das dominierende Problem sind Bilder ohne eingebettete IPTC-Daten. Viele Stockfoto-Downloads werden vor dem Upload in Photoshop bearbeitet, wobei die Metadaten verloren gehen. Wenn kein IPTC-Creator-Feld vorhanden ist, kann die Extension keinen Copyright-Hinweis generieren. A solução: Einen Workflow etablieren, bei dem Bilder vor dem Upload auf vorhandene Metadaten geprüft werden. Alternativ: Ein TYPO3-Backend-Modul, das alle Bilder ohne Copyright-Eintrag auflistet und zur manuellen Nachpflege auffordert.

Zweites Problem: Das Overlay verdeckt wichtige Bildinhalte. Bei Porträtfotos kann ein Copyright-Overlay am unteren Bildrand das Gesicht oder den Produktnamen verdecken. A solução: Per Bild konfigurierbar machen, ob das Copyright als Overlay oder als Fusszeile angezeigt wird. Standardmässig ist die Fusszeile die sichere Wahl.

Drittes Thema: Performance bei grossen Bildbeständen. Wenn die Extension bei jedem Bild-Request die IPTC-Daten aus der Datei liest statt aus der Datenbank, wird das bei Seiten mit 20 Bildern spürbar. A solução: IPTC-Daten einmalig beim Upload auslesen und in der Datenbank cachen, nicht bei jedem Frontend-Request.

## TYPO3 v12 wird unterstützt, v13 erfordert ein Update der ViewHelper-Registrierung

tgm_copyright nutzt die FAL-API, die im TYPO3-Core stabil ist. Die Extension läuft unter v12 ohne Probleme. Für v13 sind Anpassungen an der ViewHelper-Namespace-Registrierung und den TCA-Konfigurationen nötig, weil v13 die Namespace-Konventionen für ViewHelper geändert hat. A Gosign recomenda, bei jedem TYPO3-Upgrade einen Bild-Audit durchzuführen: Alle Bilder der Website prüfen, ob Copyright-Hinweise korrekt angezeigt werden, und fehlende Zuordnungen nachpflegen.
---

--- Ticketshop TYPO3 - Ingressos online | Gosign ---
> Venda de ingressos online para eventos: Seleção de assentos, cotas, pagamento, geração de e-tickets, validação de QR code. Desenvolvimento personalizado.

## Veranstalter zahlen 5 bis 15 Prozent Provision an externe Ticketplattformen, obwohl die eigene Website der bessere Vertriebskanal wäre

Eventim, Ticketmaster und Eventbrite nehmen Gebühren pro Ticket: zwischen 5 und 15 Prozent des Ticketpreises plus Festbetrag. Bei einem Theater mit 50.000 verkauften Tickets pro Jahr und einem Durchschnittspreis von 30 Euro sind das 75.000 bis 225.000 Euro Provision jährlich. Ein Ticketshop direkt auf der TYPO3-Website eliminiert diese Provision. Die Extension ermöglicht Online-Ticketverkauf mit Sitzplatzwahl, Kontingent-Verwaltung, Bezahlung über gängige Payment-Provider, E-Ticket-Generierung als PDF und QR-Code-Validierung am Einlass. Für Theater, Konzerthäuser, Konferenzen und kommunale Veranstaltungshäuser, die ihre Tickets überwiegend an ein bekanntes Stammpublikum verkaufen, ist das eine wirtschaftlich attraktive Alternative.

## Cenários típicos de uso vão vom Stadttheater bis zur Fachkonferenz

Das prominenteste Szenario ist das Theater oder Konzerthaus mit festem Saalplan. 400 nummerierte Sitzplätze, davon 50 in der Kategorie Premium, 200 im Parkett und 150 auf dem Balkon. Der Besucher wählt im interaktiven Saalplan seinen Platz, sieht den Preis und legt das Ticket in den Warenkorb. Nach der Bezahlung erhält er ein E-Ticket als PDF mit QR-Code per E-Mail. Am Abend der Vorstellung scannt das Personal den QR-Code mit einem Smartphone. Der gesamte Prozess läuft über die TYPO3-Website, ohne Drittanbieter.

Ein zweites Szenario sind Konferenzen und Messen. Eine Fachkonferenz bietet drei Ticketkategorien: Early Bird (bis 8 Wochen vor der Veranstaltung), Regular und VIP. Kontingente begrenzen jede Kategorie auf eine feste Anzahl. Der Ticketshop zeigt die Verfügbarkeit in Echtzeit: "Early Bird: 12 von 100 verfügbar". Nach Ablauf des Early-Bird-Zeitraums wird die Kategorie automatisch deaktiviert.

Drittes Szenario: Kommunale Veranstaltungen. Eine Stadtbibliothek bietet Lesungen, Workshops und Kinderveranstaltungen an. Die Tickets sind gratis, aber die Plätze begrenzt. Der Ticketshop dient hier als Reservierungssystem. Besucher reservieren online, erhalten eine Bestätigung und werden bei Überbuchung auf eine Warteliste gesetzt.

## Arquitetura técnica verbindet Veranstaltungs-Records, Saalplan und Payment-Gateway

Der Ticketshop besteht aus vier Komponenten: Veranstaltungsverwaltung, Sitzplan-Editor, Checkout mit Payment-Integration und Ticket-Generierung. Veranstaltungen werden als Extbase-Records im TYPO3-Backend angelegt: Titel, Datum, Uhrzeit, Ort, Kategorien, Preise, Kontingente. Der Sitzplan wird als interaktive SVG-Grafik hinterlegt, in der jeder Platz eine eindeutige ID hat, die mit dem Kontingent-System verknüpft ist.

Der Checkout-Prozess sammelt die ausgewählten Tickets, fragt Kontaktdaten ab und leitet an ein Payment-Gateway weiter. Gängige Integrationen sind Stripe, PayPal, Mollie und SIX Payment Services. Nach erfolgreicher Zahlung erzeugt die Extension ein PDF-Ticket mit QR-Code (basierend auf einer eindeutigen Ticket-ID) und versendet es per E-Mail. Der QR-Code enthält eine URL oder einen Hashwert, der am Einlass validiert wird.

Die QR-Code-Validierung am Einlass kann über eine einfache Web-App laufen, die die Ticket-ID gegen die TYPO3-Datenbank prüft und den Status auf "eingelöst" setzt. Ein Ticket kann nur einmal eingelöst werden, Duplikate werden abgewiesen.

## Problemas frequentes betreffen Bezahlung, Stornierung und den Saalplan-Editor

Das grösste Problem ist die Zahlungsabwicklung. PCI-DSS-Konformität verlangt, dass Kreditkartendaten niemals den eigenen Server berühren. Deshalb muss die Zahlung über einen zertifizierten Payment Provider laufen, der ein Hosted Payment Form bereitstellt. Die Extension leitet den Nutzer zur Bezahlung an den Provider weiter und empfängt das Ergebnis per Callback. Wenn der Callback fehlschlägt (Timeout, Server-Restart), ist das Ticket bezahlt, aber nicht als bezahlt markiert. A solução: Ein Reconciliation-Job, der offene Transaktionen beim Payment Provider nachprüft.

Zweites Problem: Stornierungen und Erstattungen. Wenn ein Besucher ein Ticket storniert, muss die Zahlung erstattet und der Platz wieder freigegeben werden. Das erfordert sowohl eine Refund-Anfrage an den Payment Provider als auch eine Statusänderung in der TYPO3-Datenbank. Ohne automatisierten Storno-Workflow ist das ein manueller Prozess.

Drittes Thema: Der Saalplan-Editor. Interaktive SVG-Saalpläne mit 400 oder mehr Plätzen sind aufwändig zu erstellen. Jeder Platz braucht eine ID, eine Kategorie und Koordinaten. Änderungen am Saalplan (neuer Block, geänderte Reihenfolge) erfordern eine Aktualisierung der SVG-Datei und der Verknüpfungen in der Datenbank.

## Ticketshop-Extensions sind Custom-Entwicklungen ohne TER-Standard

Es gibt keine Standard-Ticketshop-Extension im TYPO3 TER, die alle beschriebenen Funktionen abdeckt. Ticketshops sind fast immer Custom-Entwicklungen, die auf die spezifischen Anforderungen der Veranstaltungsstätte zugeschnitten sind. Die TYPO3-Kompatibilität hängt deshalb vom Auftragnehmer ab, nicht von einem Community-Release-Zyklus. A Gosign recomenda bei neuen Ticketshop-Projekten zu evaluieren, ob eine headless TYPO3-Architektur mit einem spezialisierten Frontend (React, Vue) nicht langfristig wartbarer ist als eine monolithische Extbase-Lösung.
---

--- Tournament TYPO3 - Torneios | Gosign ---
> Turnier-/Wettbewerbsverwaltung para TYPO3: Grupos, confrontos, resultados, tabelas. Clubes esportivos, e-sports, competições internas de empresa.

## Sportvereine verwalten Turniere in Excel, obwohl ihre Website der logische Ort für Ergebnisse und Tabellen wäre

Jedes Wochenende finden in Deutschland Tausende Vereinsturniere statt. Die Ergebnisse werden in Excel-Tabellen eingetippt, als PDF auf die Website geladen oder im besten Fall per Hand in eine HTML-Tabelle geschrieben. Besucher der Vereinswebsite sehen veraltete Daten, weil niemand die Seite aktualisiert. Die TYPO3 Tournament-Extension ersetzt diesen Workflow: Gruppen, Spielpaarungen, Ergebnisse und Tabellen werden direkt im CMS verwaltet. Ergebnisse werden eingegeben, die Tabelle aktualisiert sich automatisch. Für Sportvereine, E-Sport-Organisationen und Firmen, die interne Wettbewerbe veranstalten, ist das eine professionelle Darstellung ohne Programmieraufwand.

## Cenários típicos de uso abrangem Fussballturniere, E-Sport-Ligen und Firmenwettbewerbe

Das häufigste Szenario ist das Fussballturnier eines Sportvereins. 16 Mannschaften treten in 4 Gruppen an. Jede Gruppe spielt eine Vorrunde (jeder gegen jeden), die besten zwei qualifizieren sich für die K.o.-Runde. Die Extension bildet diesen Modus vollständig ab: Gruppenphase mit Punkten, Tordifferenz und Direktvergleich, K.o.-Runde mit Viertelfinale, Halbfinale und Finale. Ergebnisse werden im Backend eingegeben, die Tabellen und der Turnierplan im Frontend aktualisieren sich automatisch.

Ein zweites Szenario sind E-Sport-Ligen. Ein Gaming-Verein organisiert eine Counter-Strike-Liga mit 12 Teams und einer Saison über 20 Spieltage. Die Extension verwaltet die Liga-Tabelle, den Spielplan und die Ergebnishistorie. Jedes Team hat eine Profilseite mit Kader, Statistiken und vergangenen Ergebnissen. Die Darstellung ist an das Vereins-CI angepasst, nicht an das Layout einer Drittplattform.

Drittes Szenario: Interne Firmenwettbewerbe. Ein Unternehmen mit fünf Standorten veranstaltet ein jährliches Schachturnier. Mitarbeitende melden sich über die Intranet-TYPO3-Seite an, die Extension lost die Paarungen aus und zeigt den Turnierfortschritt live. Das ist eine Nischenanwendung, aber für Unternehmen, die Engagement und Standort-übergreifenden Austausch fördern wollen, ein realer Use Case.

## Arquitetura técnica modelliert Turniere als verschachtelte Record-Struktur

Die Extension definiert mehrere Extbase-Modelle: Tournament (Turnier), Team, Group, Match, Result. Ein Turnier enthält Gruppen, jede Gruppe enthält Teams. Matches werden entweder automatisch generiert (Jeder-gegen-Jeden) oder manuell definiert (K.o.-Runde). Ergebnisse werden als Result-Records mit Match-Verknüpfung gespeichert.

Die Tabellenberechnung erfolgt serverseitig: Punkte (3-1-0 oder konfigurierbar), Tordifferenz, erzielte Tore, Direktvergleich. Die Sortierlogik ist über TypoScript konfigurierbar, weil verschiedene Sportarten unterschiedliche Kriterien priorisieren (Fussball: Tordifferenz vor Toren; Handball: Torquotient).

Das Frontend rendert zwei Hauptansichten: die Gruppenphase als Tabelle (Teams, Punkte, Siege, Niederlagen, Tordifferenz) und den K.o.-Turnierbaum als verschachtelte Bracket-Darstellung. Die Bracket-Darstellung ist per CSS als Baumstruktur umgesetzt, die auf Desktop horizontal und auf Mobilgeräten vertikal läuft.

Für grössere Turniere mit Livestream-Integration lässt sich die Extension per AJAX erweitern: Ergebnisse werden im Backend eingetragen und das Frontend aktualisiert den Spielstand per Polling alle 30 Sekunden, ohne dass die Seite neu geladen wird.

## Problemas frequentes betreffen die Turniermodus-Logik und die Bracket-Darstellung

Das grösste Problem ist die Vielfalt der Turniermodi. Ein einfaches K.o.-Turnier mit 8 Teams ist trivial. Aber ein Swiss-System-Turnier mit 40 Teams, ein Doppel-K.o.-Format oder eine Liga mit Auf- und Abstiegsrunden erfordern komplexe Logik, die nicht jede Extension abbildet. Vor der Entscheidung für eine Extension muss der Turniermodus klar definiert sein. Wenn die Extension den gewünschten Modus nicht unterstützt, ist eine Custom-Erweiterung nötig.

Zweites Problem: Die Bracket-Darstellung auf mobilen Geräten. Ein K.o.-Turnierbaum mit 16 Teams hat vier Runden (Achtelfinale bis Finale). Diese Baumstruktur passt nicht auf einen 375 Pixel breiten Bildschirm. Horizontales Scrollen oder eine vereinfachte Listenansicht sind die pragmatischen Lösungen.

Drittes Thema: Teamfotos und Wappen. Vereine wollen Logos neben den Teamnamen in der Tabelle. Die Extension muss FAL-Integration für Team-Bilder bieten, sonst müssen Redakteure Bildpfade manuell eintippen.

## Tournament-Extensions sind Nischenprodukte mit begrenzter Community

Turnier-Extensions für TYPO3 sind Nischenlösungen mit kleiner Community. Unter TYPO3 v12 laufen aktuelle Versionen stabil. Für v13 ist die Weiterentwicklung nicht garantiert, weil der Pflege-Aufwand für den Maintainer bei einer Nischen-Extension wirtschaftlich schwer zu rechtfertigen ist. Vereine, die langfristig planen, sollten evaluieren, ob eine spezialisierte Turnier-Plattform (Challengermode, Toornament) mit API-Anbindung an die TYPO3-Website nicht nachhaltiger ist als eine monolithische Extension. A Gosign orienta Vereine und Organisationen bei der Wahl zwischen Community-Extension, Custom-Entwicklung und SaaS-Integration.
---

--- tt_address TYPO3 - Gerenciamento de endereços | Gosign ---
> O clássico para gerenciamento de endereços no TYPO3. Gerenciar e exibir contatos, colaboradores, locais. Base para listas de contatos, localizador de filiais.

## Diretórios de colaboradores, localizadores de filiais e listas de contatos rodam no TYPO3 há 20 anos via tt_address

Toda empresa com múltiplas localidades, departamentos ou pessoas de contato precisa de uma apresentação estruturada no site. Quem é responsável por qual região? Onde fica a filial mais próxima? Quais são os dados de contato do departamento de RH? Manter essas informações manualmente como blocos de texto no CMS leva a inconsistências: formatos diferentes, atualizações esquecidas, sem possibilidade de filtragem.

tt_address é a extensão de gerenciamento de endereços mais antiga e difundida para TYPO3. Em uso desde TYPO3 v4 (2006), mais de 50.000 instalações ativas (TER, 2026), mantida ativamente pela comunidade TYPO3. A extensão armazena contatos, pessoas e localidades como registros estruturados e os exibe via templates Fluid como listas, mapas ou páginas de detalhe.

## Cenários típicos de uso

**Diretórios de colaboradores para sites corporativos.** Uma empresa com 50 a 500 colaboradores quer mostrar no site quem é responsável por cada tema. tt_address armazena por pessoa: nome, título, departamento, foto, e-mail, telefone, localidade. A saída ocorre como lista filtrável (por departamento, localidade) ou como página de detalhe com download de vCard.

**Localizadores de filiais e visões gerais de localidades.** Empresas com 10 a 500 localidades usam tt_address como base de dados para um localizador. Cada localidade tem endereço, geocoordenadas, horários de funcionamento e dados de contato. A integração de mapa ocorre via extensão separada (maps2 ou Leaflet), que lê as geocoordenadas do tt_address. Usuários buscam por CEP ou cidade e recebem as localidades mais próximas.

**Listas de contatos para órgãos públicos e associações.** Municipalidades, câmaras e associações listam responsáveis por competência. tt_address modela a estrutura organizacional via categorias ou SysFolder. A saída pode ser filtrada por categoria e ordenada alfabeticamente ou por cargo.

## Arquitetura técnica

tt_address armazena registros na tabela `tt_address`. Os campos incluem: tratamento, título, nome, sobrenome, empresa, departamento, endereço, CEP, cidade, país, telefone, fax, celular, e-mail, site, geocoordenadas (latitude, longitude), imagem (referência FAL), categorias e campo de descrição (RichText).

A saída ocorre via plugin Extbase com ações de lista e detalhe. Templates Fluid são completamente personalizáveis. tt_address se integra com outras extensões: maps2 e ext:leaflet para integração de mapa, direct_mail e mail para envio de newsletter (tt_address como lista de destinatários), ke_search e indexed_search para busca de texto completo sobre dados de endereço.

Categorias (sys_category) são o mecanismo primário de estruturação. Uma pessoa pode ser atribuída a múltiplas categorias (ex: "Vendas" e "Localidade SP"). A saída no frontend filtra por categoria, permitindo a exibição de listas por departamento, equipes por localidade ou grupos de contato temáticos.

## Problemas frequentes e soluções

**Imagens não são exibidas.** Desde TYPO3 v10, tt_address usa FAL para imagens. Instalações antigas armazenavam imagens como nomes de arquivo em um campo (não como referência FAL). Solução: executar o script de upgrade do tt_address, que converte referências de imagem antigas em referências FAL.

**Geocoordenadas faltam para o localizador.** Endereços sem latitude/longitude não aparecem no mapa. Inserir manualmente para 200 localidades não é prático. Solução: automatizar geocoding via tarefa scheduler. A Gosign utiliza um cronjob que, via API Nominatim (OpenStreetMap, gratuito, em conformidade com a LGPD (PT: RGPD)), completa coordenadas ausentes.

**Importação de dados de sistemas externos.** Departamentos de RH mantêm dados de colaboradores em sistemas de RH. Os dados devem aparecer automaticamente no site. Solução: construir um mecanismo de sincronização que importa CSV ou JSON do sistema de RH e cria ou atualiza registros tt_address.

## Migração e compatibilidade de versões

tt_address suporta ativamente TYPO3 v11, v12 e v13. A extensão é co-mantida por Georg Ringer (o desenvolvedor da extensão News) e segue um ciclo de release claro. Atualizações para novas versões TYPO3 major aparecem geralmente dentro de poucas semanas após o release LTS.

A Gosign recomenda tt_address como ponto de partida para todos os cenários com menos de 5.000 registros. A extensão é estável, bem documentada, tem uma grande comunidade e se integra perfeitamente com outras extensões TYPO3. Para volumes maiores de dados ou requisitos de sincronização complexos, a Gosign constrói uma camada de sincronização personalizada que usa tt_address como saída frontend, mas mantém a autoridade dos dados no sistema fonte.

A configuração inicial de um projeto tt_address (instalação, adaptação de template, estrutura de categorias, configuração de geocoding) fica entre 2 e 4 dias de desenvolvimento. Um localizador de filiais com integração de mapa e busca por CEP chega a 5 a 8 dias, incluindo a integração Leaflet ou maps2.

--- typo3db_legacy TYPO3 - Migração de banco de dados | Gosign ---
> Camada de compatibilidade para a antiga API de banco de dados do TYPO3 (`$GLOBALS['TYPO3_DB']`). Ponte para extensões que ainda não migraram para Doctrine DBAL.

## Por que typo3db_legacy é um risco de segurança para cada extensão desde TYPO3 v12

TYPO3 substituiu completamente a abstração de banco de dados por Doctrine DBAL na versão 8. A antiga API via `$GLOBALS['TYPO3_DB']` foi marcada como deprecated a partir da v9 e completamente removida desde a v12. Mesmo assim, na prática milhares de instalações TYPO3 rodam com extensões que ainda são baseadas na API legacy. typo3db_legacy mantém essas extensões funcionando ao simular a API antiga como camada de compatibilidade.

O problema: a extensão não é uma solução permanente, mas uma ponte. Cada nova versão TYPO3 aumenta o risco de que a própria camada de compatibilidade quebre. Quem hoje ainda usa typo3db_legacy enfrenta uma decisão clara - migrar ou arriscar o upgrade para v13.

## Cenários típicos de uso

**Extensões desenvolvidas internamente com acessos diretos ao banco de dados.** Muitas agências escreveram entre 2012 e 2018 extensões que chamam diretamente `$GLOBALS['TYPO3_DB']->exec_SELECTquery()`. Em uma instalação típica de médio porte encontram-se 3 a 8 dessas extensões. Sem typo3db_legacy, elas falhariam com Fatal Errors após um update para v10+.

**Extensões de terceiros sem mantenedor ativo.** Extensões como versões antigas de addons tt_address, diretórios setoriais ou ferramentas de importação especializadas foram frequentemente mantidas por desenvolvedores solo. Se o mantenedor não está mais ativo, typo3db_legacy é a única opção para preservar a funcionalidade durante o upgrade.

**Migração gradual de grandes instalações.** Empresas com mais de 50 extensões não podem migrar tudo simultaneamente. typo3db_legacy permite uma abordagem gradual: primeiro realizar o upgrade do Core, depois converter extensão por extensão para Doctrine DBAL. A Gosign planeja essas migrações em sprints de 3 a 5 extensões, priorizadas por criticidade de negócio.

## Arquitetura técnica

typo3db_legacy se registra como extensão TYPO3 e disponibiliza a classe `DatabaseConnection` que implementa os mesmos métodos da antiga API: `exec_SELECTquery()`, `exec_INSERTquery()`, `exec_UPDATEquery()`, `exec_DELETEquery()`.

Internamente, a camada encaminha todas as chamadas para Doctrine DBAL. Isso funciona de forma confiável para queries padrão. Problemas surgem com funções MySQL diretas em queries, prepared statements no formato antigo, transaction handling e performance (cada query passa por uma camada de abstração adicional com 5-15% de overhead).

Aspecto arquitetural importante: typo3db_legacy foi concebido como medida temporária. O código deliberadamente não contém otimizações que o tornariam mais longevo. Não há caching de queries na camada de compatibilidade, sem integração de connection pooling.

## Problemas frequentes e soluções

**Extensão não funciona apesar do typo3db_legacy após o upgrade.** A causa geralmente é que a extensão não usa apenas `$GLOBALS['TYPO3_DB']`, mas também outras APIs removidas. A solução requer análise completa do código da extensão. Um scan com o TYPO3 Extension Scanner fornece uma lista priorizada. A Gosign realiza tais scans como levantamento prévio - esforço típico: 2 a 4 horas por instalação.

**Queries retornam resultados diferentes de antes do upgrade.** Doctrine DBAL trata tipos mais rigorosamente que a antiga API baseada em mysqli. Um `WHERE uid = '5'` (string em vez de integer) pode levar a comportamento inesperado em edge cases. Solução: verificar tipos PHP corretos em todas as queries.

**Queda de performance após instalação.** Instalações com mais de 100.000 registros e queries frequentes sentem o overhead da dupla abstração de forma mensurável. Aqui só ajuda a migração completa para Doctrine DBAL com QueryBuilder.

## Migração e compatibilidade de versões

typo3db_legacy era componente oficial do TYPO3 Core até a versão 9.5 LTS. Para TYPO3 v10 e v11 existia como pacote Composer separado. Para TYPO3 v12 LTS não existe mais release oficialmente suportado.

Para TYPO3 v13 nenhuma camada de compatibilidade é planejada ou realista. A camada de banco de dados mudou demais com o upgrade para Doctrine DBAL 4.0. Quem usa typo3db_legacy e quer fazer upgrade para v13 não escapa de uma migração completa.

O caminho de migração recomendado: cada chamada `exec_SELECTquery()` é reescrita para o Doctrine DBAL QueryBuilder. Uma extensão típica com 10 a 20 chamadas de query pode ser migrada em 4 a 8 horas. A Gosign usa análise de código automatizada que identifica todas as chamadas de API legacy e sugere código de migração. Para extensões complexas com queries construídas dinamicamente, o esforço sobe para 2 a 3 dias por extensão.

--- LGPD iFrame TYPO3 - Consent | Gosign ---
> em conformidade com a LGPD iFrame-Einbettung para TYPO3: Carregar vídeos, mapas, redes sociais apenas após consentimento. Solução de dois cliques.

## YouTube-Videos und Google Maps ohne Einwilligung einzubetten, ist ein LGPD-Verstoss mit Abmahnrisiko

Jede iFrame-Einbettung eines externen Dienstes überträgt die IP-Adresse des Besuchers an den Dienstanbieter, noch bevor der Besucher interagiert. Ein YouTube-Video auf der Startseite sendet beim Seitenaufruf die IP an Google, eine Google-Maps-Karte an Google, ein Facebook-Widget an Meta. Ohne vorherige Einwilligung des Besuchers ist das ein Verstoss gegen die LGPD (Art. 6 Abs. 1 lit. a). Seit dem EuGH-Urteil Planet49 (2019) und dem BGH-Urteil zu Cookie-Bannern ist die Rechtslage klar: Technisch nicht notwendige Datenübertragungen an Dritte erfordern eine informierte Einwilligung. udg_gdpr_iframe implementiert die Zwei-Klick-Lösung für TYPO3: iFrames werden erst nach explizitem Klick des Besuchers geladen. Ein Platzhalter zeigt an, welcher Dienst geladen wird und welche Daten übertragen werden.

## Cenários típicos de uso envolvem YouTube, Google Maps und Social-Media-Embeds

Das häufigste Szenario sind YouTube-Videos auf Unternehmenswebsites. Eine Firma zeigt auf ihrer Karriereseite ein Recruiting-Video. Ohne Consent-Lösung sendet die Seite bei jedem Aufruf die Besucher-IP an Google. Mit udg_gdpr_iframe sieht der Besucher statt des Videos einen Platzhalter mit Vorschaubild, dem Hinweis "Dieses Video wird von YouTube bereitgestellt. Beim Abspielen werden Daten an Google übertragen." und einem Button "Video laden". Erst nach Klick wird der iFrame geladen und das Video abgespielt.

Ein zweites Szenario ist die Google-Maps-Karte auf der Kontaktseite. Die Anfahrtskarte ist ein Standardelement, aber ein datenschutzrechtliches Risiko. udg_gdpr_iframe zeigt stattdessen ein statisches Kartenbild (Screenshot) als Platzhalter. Besucher, die die interaktive Karte brauchen, klicken auf "Karte laden" und akzeptieren damit die Datenübertragung an Google.

Drittes Szenario: Social-Media-Embeds. Ein Blog-Artikel zitiert einen Tweet oder einen Instagram-Post. Auch diese Embeds laden externe Ressourcen und übertragen Nutzerdaten. udg_gdpr_iframe blockiert den Embed und zeigt einen Platzhalter, der den Dienst benennt und einen Vorschautext anzeigt.

## Arquitetura técnica ersetzt iFrames durch Platzhalter mit JavaScript-Loader

Die Extension registriert ein Content-Element oder modifiziert bestehende TYPO3-Content-Elemente, die iFrames enthalten. Im HTML wird der iFrame-src-Attribut durch ein data-src-Attribut ersetzt. Der Browser lädt den iFrame nicht, weil das src-Attribut fehlt. Stattdessen zeigt ein Platzhalter-Div den Dienst-Namen, den proteção de dadoshinweis und einen Aktivierungs-Button.

Beim Klick auf den Button kopiert ein JavaScript-Snippet das data-src in das src-Attribut und der Browser lädt den iFrame. Optional kann der Besucher eine "Immer laden"-Checkbox aktivieren, die seine Entscheidung im LocalStorage speichert. Bei späteren Besuchen wird der iFrame dann ohne erneute Interaktion geladen.

Die Platzhalter-Darstellung ist per Fluid-Template konfigurierbar: Vorschaubild (z.B. YouTube-Thumbnail), Text, Button-Label, Link zur política de privacidade. Für YouTube-Videos kann die Extension das Thumbnail automatisch von der YouTube-API abrufen (ohne iFrame, nur ein Bild-Request).

Die Integration mit bestehenden Consent-Management-Plattformen (CookieBot, OneTrust, Borlabs Cookie) ist über die JavaScript-API möglich: Wenn der Besucher im Cookie-Banner der Kategorie "Marketing" zugestimmt hat, werden alle Marketing-iFrames automatisch geladen, ohne Zwei-Klick.

## Problemas frequentes betreffen die Erkennung aller iFrames und die CMP-Integration

Das grösste Problem ist die vollständige Erkennung aller iFrames auf der Website. Redakteure betten iFrames nicht nur über Content-Elemente ein, sondern auch direkt im RTE (Rich Text Editor), in Fluid-Templates und in TypoScript. Die Extension muss alle Quellen abdecken. Ein häufiger Fehler: Die Content-Elemente sind geschützt, aber ein YouTube-iFrame im Footer-Template lädt weiterhin ohne Einwilligung. A solução: Nach der Installation einen vollständigen Crawl der Website durchführen und alle iFrame-Quellen identifizieren.

Zweites Problem: Die Integration mit dem Consent-Management. Wenn die Website bereits Borlabs Cookie oder CookieBot einsetzt, kann es Konflikte geben: Das CMP blockiert den iFrame per eigenem Mechanismus, udg_gdpr_iframe blockiert ihn nochmals. Das Ergebnis: Doppelte Platzhalter oder ein iFrame, der nach der CMP-Einwilligung trotzdem nicht lädt. A solução: Entweder udg_gdpr_iframe oder das CMP für iFrame-Blockierung nutzen, nicht beides.

Drittes Thema: acessibilidade. Der Platzhalter muss per Screenreader zugänglich sein: Der Button braucht ein aria-label, der proteção de dadoshinweis muss als Text (nicht als Bild) vorliegen, und die Tastaturnavigation muss funktionieren.

## TYPO3 v12 wird unterstützt, die Extension bleibt relevant solange iFrames existieren

udg_gdpr_iframe löst ein Problem, das mit jeder neuen LGPD-Auslegung relevanter wird. Die Extension läuft unter TYPO3 v12 stabil. Für v13 ist ein Update der Content-Element-Registrierung und des JavaScript-Loaders nötig. Da die Kernfunktionalität (iFrame-src durch data-src ersetzen) technisch trivial ist, lässt sich die Extension bei Bedarf mit geringem Aufwand auf jede TYPO3-Version portieren. A Gosign verifica bei proteção de dados-Audits die vollständige iFrame-Abdeckung und empfiehlt die Lösung, die zum bestehenden Consent-Management der Website passt.
---

--- Umfrage TYPO3 - Plugin de pesquisa | Gosign ---
> Einfache Umfrage/Poll-Extension para TYPO3. Enquetes rápidas diretamente no CMS. Für komplexere Surveys: LimeSurvey-Integração.

## Schnelle Meinungsumfragen direkt auf der Website erzeugen Engagement, das Kommentarfelder nicht liefern

Blog-Artikel mit Kommentarfunktion erzeugen in der Praxis weniger als 1 Prozent Interaktion. Eine Umfrage ("Stimmen Sie zu?", "Welche Option bevorzugen Sie?") schafft 5 bis 15 Prozent, weil die Hürde niedriger ist: ein Klick statt einer Texteingabe. Das TYPO3-Umfragetool bringt einfache Polls direkt ins CMS. Redakteure erstellen Umfragen im Backend (Frage, Antwortoptionen, Mehrfachauswahl ja/nein, Ergebnis-Anzeige), betten sie als Content-Element ein und sehen die Ergebnisse in Echtzeit. Für schnelle Meinungsbilder ist das ausreichend. Für wissenschaftliche oder komplexe Befragungen empfehlen wir die LimeSurvey-Integration, die deutlich mächtigere Fragetypen und Auswertungen bietet.

## Cenários típicos de uso abrangem Leser-Polls, Event-Feedback und Abstimmungen

Das häufigste Szenario ist der Leser-Poll auf einer News- oder Blog-Seite. Ein Fachmagazin fragt: "Welches Feature wünschen Sie sich in TYPO3 v14 am meisten?" mit fünf Antwortoptionen. Leser klicken auf ihre Wahl und sehen sofort die prozentuale Verteilung. Das erzeugt Engagement, liefert der Redaktion ein Stimmungsbild und gibt dem Artikel eine interaktive Komponente, die die Verweildauer erhöht.

Ein zweites Szenario ist Event-Feedback. Nach einer Konferenz oder einem Webinar sehen Teilnehmer auf der TYPO3-Website eine Umfrage: "Wie bewerten Sie die Veranstaltung?" (sehr gut / gut / befriedigend / schlecht). Das ist kein Ersatz für einen ausführlichen Feedback-Fragebogen, aber eine schnelle Zufriedenheitsmessung, die deutlich mehr Teilnehmer ausfüllen als eine E-Mail-Survey.

Drittes Szenario: Abstimmungen in Vereinen und Gremien. Ein Fachverband lässt seine Mitglieder über das Logo-Redesign abstimmen. Drei Entwürfe stehen zur Wahl, jedes Mitglied hat eine Stimme. In Kombination mit fe_login ist sichergestellt, dass nur registrierte Mitglieder abstimmen und jedes Mitglied nur einmal teilnimmt.

## Arquitetura técnica speichert Umfragen als Extbase-Records mit Ergebniszählung

Das Umfragetool definiert zwei Extbase-Modelle: Poll (Frage, Beschreibung, Start-/Enddatum, Mehrfachauswahl-Flag) und Option (Antworttext, Stimmenanzahl). Ein Poll enthält mehrere Options. Stimmen werden als Zähler (Integer-Inkrement) in der Option gespeichert, nicht als einzelne Records pro Teilnehmer. Das hält die Datenbank schlank und die Performance hoch, bedeutet aber auch, dass individuelle Antworten nicht nachvollziehbar sind.

Im Frontend rendert die Extension ein Formular mit Radio-Buttons (Einfachauswahl) oder Checkboxen (Mehrfachauswahl). Nach dem Absenden wird der Zähler der gewählten Option inkrementiert und die Ergebnisdarstellung als horizontales Balkendiagramm mit Prozentwerten angezeigt.

Gegen Mehrfachstimmen setzt die Extension auf Cookie-basierte Duplikat-Erkennung: Nach der Teilnahme wird ein Cookie gesetzt, das eine erneute Stimmabgabe verhindert. Das ist kein sicherer Schutz (Cookies lassen sich löschen), aber für Meinungsumfragen ohne formale Anforderungen ausreichend. Für verbindliche Abstimmungen ist die Kombination mit fe_login nötig, die eine Prüfung gegen die fe_users-Tabelle ermöglicht.

## Problemas frequentes betreffen Manipulationssicherheit und fehlende Analysefunktionen

Das grösste Problem bei offenen Polls ist die Manipulierbarkeit. Ohne Login kann ein Besucher den Cookie löschen und erneut abstimmen. Im Inkognito-Modus funktioniert die Cookie-Sperre gar nicht. Wer belastbare Ergebnisse braucht, muss die Umfrage an den fe_login koppeln. Für niederschwellige Meinungsbilder ("Was interessiert Sie?") ist die Cookie-Lösung hingegen akzeptabel.

Zweites Problem: Fehlende Analysefunktionen. Das Umfragetool speichert nur Gesamtzahlen, keine Zeitverläufe, keine Segmentierung nach Nutzergruppen, keine Kreuztabellen. Wenn die Auswertung über "63% wählen Option A" hinausgehen soll, ist LimeSurvey oder ein dediziertes Survey-Tool die bessere Wahl.

Drittes Thema: Design-Anpassung. Die mitgelieferten Templates sind funktional, aber nicht auf moderne UI-Anforderungen ausgelegt. Wer Umfragen in einem aufgeräumten Design mit Animationen (Balken füllen sich, Prozentzahlen zählen hoch) darstellen will, muss die Fluid-Templates überschreiben und eigenes CSS/JS hinzufügen.

## TYPO3 v12 wird unterstützt, für komplexere Umfragen ist LimeSurvey die bessere Wahl

Das Umfragetool läuft unter TYPO3 v12 stabil. Für v13 ist ein Update der Plugin-Registrierung nötig. Da die Extension technisch schlank ist (zwei Extbase-Modelle, ein Controller, ein Fluid-Template), ist die Migration unkompliziert. A Gosign recomenda die Extension für einfache Polls mit drei bis fünf Antwortoptionen. Sobald Fragetypen wie Likert-Skalen, offene Textfelder, Matrixfragen oder bedingte Logik benötigt werden, ist eine LimeSurvey-Integration die professionellere Lösung.
---

--- VHS Development TYPO3 | Gosign ---
> Versão de desenvolvimento da coleção de ViewHelpers VHS. Testar os recursos mais recentes antes do lançamento oficial. Para desenvolvedores TYPO3 na vanguarda.

## Por que a versão de desenvolvimento VHS é uma faca de dois gumes para agências TYPO3

VHS (ViewHelpers Supplementary) é com mais de 300 ViewHelpers a extensão Fluid mais abrangente para TYPO3. A versão de desenvolvimento entrega novos ViewHelpers e correções de bugs antes de chegarem a um release estável. Para desenvolvedores que trabalham em projetos atuais e aguardam uma correção específica ou recurso novo, isso é uma vantagem. Para sites produtivos, é um risco: versões de desenvolvimento não são completamente testadas e podem mudar de forma incompatível entre commits.

A decisão de usar VHS Development no projeto não é técnica, mas organizacional: a equipe tem capacidade para testar mudanças na biblioteca em tempo hábil? E existe disciplina organizacional para substituir a versão de desenvolvimento por um release estável antes do go-live?

## Cenários típicos de uso

**Acesso a correções antes do próximo release estável.** Um projeto usa o ViewHelper VHS `v:format.trim`, que tem um bug na versão estável. A correção já existe no branch de desenvolvimento, mas o próximo release estável está previsto apenas em 4 semanas. A equipe troca temporariamente para VHS Development para usar a correção imediatamente e retorna ao release estável depois.

**Avaliação de novos ViewHelpers para projeto de relançamento.** Um relançamento TYPO3 começa em 3 meses. A equipe de desenvolvimento avalia se novos ViewHelpers VHS podem simplificar o código de templates. A versão de desenvolvimento é instalada em ambiente de desenvolvimento local, testada e os resultados alimentam a decisão de arquitetura.

**Contribuição para o desenvolvimento VHS.** Agências que contribuem ViewHelpers próprios ao VHS ou reportam bugs trabalham com a versão de desenvolvimento para testar seus patches contra o estado atual do código. Sem versão de desenvolvimento, contribuição significativa não é possível.

## Arquitetura técnica

VHS Development não é uma extensão separada, mas o estado de desenvolvimento atual do repositório VHS no GitHub (FluidTYPO3/vhs). A instalação ocorre via Composer com `dev-main` ou um branch específico.

VHS em si tem como única dependência rígida o TYPO3 Core (Fluid Template Engine). Os mais de 300 ViewHelpers cobrem áreas como: Content (renderização de elementos, acesso FAL), Format (manipulação de strings, datas, JSON), Iterator (operações com arrays, paginação), Page (navegação, breadcrumb, sitemap), Media (manipulação de imagem, embedding de vídeo) e Security (verificações de acesso, status de login).

A versão de desenvolvimento pode conter ViewHelpers cuja API ainda muda. Parâmetros podem ser renomeados, valores de retorno alterados ou ViewHelpers completamente removidos. Entre dois releases estáveis, tipicamente mudam as assinaturas de 5 a 15 ViewHelpers no branch de desenvolvimento.

## Problemas frequentes e soluções

**Composer update quebra templates existentes.** Um `composer update` busca a versão de desenvolvimento mais recente, na qual um parâmetro de ViewHelper foi renomeado. Todos os templates que usam esse parâmetro geram erros. Solução: fazer commit consistente do Composer-Lock-File e instalar VHS Development com referência de commit fixa.

**minimum-stability dev afeta outros pacotes.** Se `minimum-stability` no `composer.json` está definido como `dev`, outros pacotes também podem instalar versões instáveis. Solução: manter `"minimum-stability": "stable"` e definir VHS Development explicitamente como exceção via alias pattern.

**Pipeline CI/CD falha com versão de desenvolvimento.** Testes automáticos e deployments baseados em instalações Composer podem falhar com a versão de desenvolvimento se o GitHub estiver temporariamente inacessível. Solução: para pipelines CI/CD, usar um mirror Composer local ou trocar para o release estável.

## Migração e compatibilidade de versões

Os releases estáveis VHS acompanham os ciclos LTS do TYPO3: VHS 6.x suporta TYPO3 v11, VHS 7.x suporta TYPO3 v12. O branch de desenvolvimento visa a próxima versão major.

A troca de VHS Development de volta para Stable é geralmente descomplicada, desde que nenhum ViewHelper exclusivo da versão de desenvolvimento esteja sendo usado. A Gosign recomenda: em ambientes de desenvolvimento e feature branches, usar a versão de desenvolvimento para avaliar novos ViewHelpers. Em staging e produção, usar exclusivamente releases estáveis. Se uma correção crítica está disponível apenas no Development, fixar o commit específico como referência Composer e deixar um comentário TODO no código.

--- VHS TYPO3 - Fluid ViewHelper | Gosign ---
> A coleção de ViewHelpers para TYPO3 Fluid Templates do FluidTYPO3. Centenas de ViewHelpers adicionais para Media, Content, Page, Iterator, Math, String.

## EXT:vhs é a caixa de ferramentas invisível de todo template TYPO3 profissional

Quem trabalha com Fluid em TYPO3 e vai além da simples exibição de conteúdo, cedo ou tarde acaba chegando ao EXT:vhs. A extensão do ecossistema FluidTYPO3 entrega várias centenas de ViewHelpers adicionais para tarefas que o core deliberadamente não cobre: manipulação de imagem, lógica de iterador, operações matemáticas, tratamento de string, consultas de conteúdo, navegação de página. Para desenvolvedoras frontend em agências e times internos, o vhs não é um nice to have opcional, mas a base sobre a qual estruturas de template complexas surgem sem desvios por PHP.

O público-alvo típico são times que mantêm site packages extensos: editoras com tipos de conteúdo heterogêneos, universidades brasileiras como USP ou UFRJ com navegações aninhadas, conglomerados com portais multilíngues. Sem vhs, a cada segunda exigência especial seria necessário um ViewHelper próprio ou algo em TypoScript. Com vhs, a lógica permanece onde deve estar: no template.

## Cenários típicos de uso

Um primeiro cenário é a consulta de conteúdo a partir de árvores de página externas. Um portal de cliente de uma indústria de máquinas com 3.000 páginas de produto precisa, em cada página, de um bloco de teaser com news recentes de um ramo rootline separado. O ViewHelper `v:content.get` busca conteúdos de páginas arbitrárias e permite composições modulares de página sem construir objetos CONTENT em TypoScript.

Um segundo cenário é o processamento de iteradores. Uma editora mantém artigos com categorias, tags e autores como ObjectStorage. Em Fluid sozinho, filtragem, agrupamento e ordenação por objetos aninhados são trabalhosos. Com `v:iterator.filter`, `v:iterator.sort` ou `v:iterator.groupBy`, operações assim ficam legíveis e manuteníveis direto no template.

Um terceiro cenário é processamento de imagem. Uma loja e-commerce com 500 produtos por temporada precisa de variantes responsivas com tag picture, fallback WebP e placeholder LQIP. Com Media ViewHelpers do vhs, esse bloco é definido uma vez no partial e reutilizado em todo lugar.

Um quarto cenário é o preparo matemático de indicadores em páginas de reporting. Quem quer exibir preços com subtotais, percentuais ou médias ponderadas usa `v:math.sum`, `v:math.percentage` ou `v:math.division`, sem construir um controller próprio para cada cálculo.

## Arquitetura técnica

EXT:vhs é uma library extension pura, sem módulos de backend e sem tabelas de banco. Ela registra namespaces no Fluid (`{namespace v=FluidTYPO3\Vhs\ViewHelpers}`) e disponibiliza assim os ViewHelpers sob o prefixo `v:`. A extensão não tem dependências rígidas com o restante do stack FluidTYPO3 (Flux, Fluidcontent), ainda que frequentemente seja usada em conjunto com eles.

A instalação é feita via Composer com `fluidtypo3/vhs`. Em um site package, o vhs costuma ser tratado como dependência da própria provider extension, para que o registro de namespace aconteça no template de layout ou globalmente via array de configuração TypoScript. Quem precisa declarar os namespaces em cada template separadamente geralmente esqueceu do caminho global de registro.

Relevante para performance é que o vhs não cacheia consultas de banco próprias. Quem usa `v:content.get` ou `v:page.menu` sem cache do Fluid gera, no pior caso, a mesma consulta em cada carregamento de página. A solução está em um cache Fluid bem configurado via page cache e content cache, além do uso consciente do mecanismo CacheStatic no core TYPO3.

O pacote da extensão é modular. Grupos individuais de ViewHelpers (Asset, Condition, Format, Iterator, Math, Media, Page, Resource, System, Variable) podem ser usados de forma direcionada, sem trazer todo o stack ao projeto. Na prática, porém, a coleção inteira costuma ser instalada, porque as dependências entre grupos são difíceis de encapsular e o footprint geral permanece aceitável.

## Problemas frequentes e soluções

O primeiro problema é a infame colisão de namespace. Quem usa EXT:vhs em paralelo com ViewHelpers próprios sob o prefixo `v:` encontra sobreposições imprevisíveis. A solução é registrar ViewHelpers próprios sempre sob um prefixo próprio (por exemplo `my:`) e trocar chamadas vhs por ViewHelpers do core quando ele já oferece alternativa (`f:format.padding` substitui `v:format.padding`).

O segundo problema é compatibilidade de versões com Fluid mais novos. Em TYPO3 v12 e v13, o Fluid foi revisado várias vezes, o que em alguns ViewHelpers vhs gera warnings de deprecation ou erros de tipo. A solução é um audit dos ViewHelpers usados contra a matriz de compatibilidade no repositório GitHub e a substituição seletiva por alternativas do core ou por implementações próprias enxutas.

O terceiro problema é performance sob carga. `v:iterator.filter` e `v:iterator.sort` são confortáveis, mas intensivos em cálculo em grandes volumes de dados. Quem renderiza um template com 10.000 produtos por página deve mover a lógica de filtro para o repository e passar ao template apenas o resultado já filtrado.

Um quarto problema, muitas vezes ignorado, são mudanças de comportamento não documentadas entre versões vhs. Um ViewHelper que na versão 6.x retornava uma string, na versão 7.x entrega de repente um array ou vice-versa. A solução é fixar a versão vhs no arquivo lock do Composer e, a cada upgrade, verificar cuidadosamente o changelog contra o acervo de templates próprios, idealmente com um passo de lint na pipeline de CI que sinalize assinaturas de ViewHelper desconhecidas imediatamente.

## Migração e compatibilidade de versões

EXT:vhs é oficialmente liberado para TYPO3 v11 e v12. Para v13 existe um branch de desenvolvimento mantido ativamente, mas ainda não pronto para produção em todos os ViewHelpers. Times que planejam atualmente um upgrade de v11 para v12 podem, em regra, levar o vhs junto sem grandes intervenções. O caminho de upgrade para v13 é o ponto crítico em projetos template-intensivos: aqui vale uma comparação custo-benefício entre manter o vhs e reconstruir gradualmente em Fluid do core mais ViewHelpers próprios.

A resposta estratégica depende do quanto o vhs é usado. Projetos que empregam apenas um punhado de ViewHelpers vhs devem, no próximo upgrade, substituí-los por construções do core ou ViewHelpers específicos do projeto. Projetos com centenas de chamadas vhs em todos os templates se beneficiam de manter o vhs e fazer em cada upgrade um teste de compatibilidade direcionado. A substituição só vale onde a carga legada pesa mais na manutenção do que uma continuidade controlada.

A Gosign acompanha upgrades TYPO3 com carga de vhs e decide junto com o time quais ViewHelpers vhs são substituídos por construções do core e quais surgem como ViewHelpers enxutos do projeto. Assim a herança de templates permanece manutenível, sem que o time se prenda por mais anos a um stack de biblioteca externo.

--- Cache Warmup TYPO3 - Performance | Gosign ---
> Cache Warmup para TYPO3: pré-aquecer cache de páginas após deploy. Integração CI/CD. Acelerado com IA.

## Por que os primeiros 5 minutos após um deploy TYPO3 definem a experiência do usuário

Após cada deployment, o cache TYPO3 é limpo. Isso é tecnicamente necessário, mas tem uma consequência perceptível: os primeiros visitantes após o deployment veem páginas sem cache. Em vez de 200ms de tempo de carregamento, esperam 2 a 5 segundos, em páginas complexas até mais. Em um deployment às 9h da manhã, isso atinge exatamente os visitantes com maior probabilidade de conversão.

warmup resolve esse problema preenchendo o cache proativamente, antes que o primeiro visitante real acesse a página. A extensão crawla todas as páginas do site em segundo plano, baseada no sitemap, priorizando as páginas mais visitadas. Após 2 a 10 minutos (dependendo do número de páginas), todo o cache está preenchido e cada visitante recebe a performance completa.

## Cenários típicos de uso

**Cache warming automatizado após deploys CI/CD.** Uma empresa faz deploy do seu site TYPO3 2 a 3 vezes por semana via pipeline CI/CD. Após cada deployment, o Deployer limpa o cache. warmup é chamado como último passo na pipeline e preenche o cache antes que o deployment seja considerado "bem-sucedido".

**Rebuild de cache após limpezas manuais.** Editores às vezes limpam todo o cache pelo backend TYPO3 porque uma única página não está atualizada. Isso afeta todas as páginas. warmup se registra como hook no evento de limpeza de cache e inicia automaticamente o processo de warmup.

**Warming programado para janelas de alto tráfego.** Uma loja online em TYPO3 tem seus picos de tráfego entre 10h e 12h. Uma tarefa scheduler inicia warmup diariamente às 9h30, para que o cache esteja completamente preenchido a tempo do pico de tráfego.

## Arquitetura técnica

warmup funciona como comando CLI TYPO3 e como tarefa scheduler. O processo de warmup ocorre em três fases: coleta de URLs (warmup lê o sitemap.xml do site e extrai todas as URLs), priorização (URLs são ordenadas por prioridade - da tag priority do sitemap, dados de analytics ou configuração manual) e crawling (warmup chama cada URL via request HTTP com crawling paralelo configurável, padrão: 4 requests simultâneos).

O comando CLI é `vendor/bin/typo3 warmup:execute`. Para integração CI/CD, é tipicamente chamado como hook post-deploy.

Dependências: TYPO3 Core, Caching Framework. warmup funciona com qualquer backend de cache - sistema de arquivos, Redis, Memcached, APCu. Em combinação com staticfilecache, warmup gera previamente arquivos HTML estáticos que são servidos diretamente pelo servidor web.

## Problemas frequentes e soluções

**Processo de warmup demora mais de 30 minutos.** Em sites com mais de 5.000 páginas e setup multi-idioma (ex: 1.000 páginas x 5 idiomas = 5.000 URLs), o warmup pode demorar. Solução: aumentar paralelismo, excluir páginas pouco importantes e limitar o processo às top 500 páginas.

**Carga do servidor sobe para 100% durante o warmup.** warmup gera requests HTTP reais contra o próprio servidor. Sem rate-limiting, a carga pode subir a ponto de frear visitantes reais. Solução: reduzir paralelismo e configurar delay entre requests.

**Páginas cacheadas não estão atualizadas após o warmup.** warmup cacheia a página como ela existe no momento da chamada. Se editores alteram conteúdo durante o warmup, o cache não corresponde ao estado atual. Solução: iniciar warmup apenas após todas as alterações de conteúdo estarem concluídas.

## Migração e compatibilidade de versões

A extensão warmup (eliashaeussler/typo3-warming) está disponível para TYPO3 v11 e v12 LTS e é mantida ativamente. Para TYPO3 v13, a compatibilidade é esperada logo após o release.

Quem até agora usa scripts de warmup manuais (loops curl, crawlers wget) pode substituí-los por warmup. A vantagem: warmup conhece a estrutura do sitemap TYPO3, prioriza por tráfego e se integra ao scheduler.

A combinação warmup + staticfilecache + Redis é o stack de performance que a Gosign recomenda para instalações TYPO3 enterprise. warmup preenche o cache, staticfilecache serve arquivos HTML estáticos sem PHP, Redis armazena queries de banco de dados. Juntos, sites TYPO3 alcançam tempos de carregamento abaixo de 100ms.

--- Widget de clima TYPO3 | Gosign ---
> Wetter-Widget para TYPO3: Dados meteorológicos atuais de OpenWeatherMap ou outras APIs. Sites de turismo, eventos ao ar livre, portais regionais.

## Tourismus-Websites, die kein aktuelles Wetter zeigen, verschenken eine der meistgesuchten Informationen

Wenn jemand "Mallorca Wetter" oder "Zugspitze aktuell" googelt, erwartet er auf der Destinations-Website eine Wetter-Anzeige. Fehlt sie, verlässt der Besucher die Seite und nutzt eine Wetter-App. Das ist eine verpasste Chance, weil der Besucher bereits auf der richtigen Website war. weather2 integriert aktuelle Wetterdaten in TYPO3: Temperatur, Wetterlage, Niederschlag, Wind, Luftfeuchtigkeit und eine Mehrtagesprognose. Die Daten kommen von OpenWeatherMap oder vergleichbaren APIs und werden im konfigurierbaren Intervall aktualisiert. Für Tourismus-Websites, Outdoor-Event-Portale und regionale Nachrichtenportale ist das eine Standardfunktion, die Besucher erwarten.

## Cenários típicos de uso abrangem Destinations-Portale, Campingplätze und Skigebiete

Das häufigste Szenario ist das Tourismus-Portal einer Region. Der Tourismusverband einer Bodensee-Gemeinde zeigt auf seiner Startseite das aktuelle Wetter: 22 Grad, sonnig, Wassertemperatur 19 Grad. Daneben eine 5-Tage-Vorhersage. Besucher, die einen Tagesausflug planen, bekommen sofort die relevante Information und bleiben auf der Seite, um Aktivitäten zu buchen. Die Wassertemperatur kommt über einen separaten API-Endpunkt oder wird manuell gepflegt.

Ein zweites Szenario sind Campingplätze und Ferienparks. Ein Campingplatz im Schwarzwald zeigt auf seiner Buchungsseite das Wetter der nächsten Woche. Besucher, die zwischen zwei Reisewochen schwanken, können die Vorhersage als Entscheidungshilfe nutzen. Für den Campingplatz-Betreiber ist das ein Conversion-Argument: "Die Sonne scheint, buchen Sie jetzt."

Drittes Szenario: Skigebiete und Outdoor-Events. Ein Skigebiet zeigt Temperatur am Berg und im Tal, Schneehöhe (aus einer separaten Datenquelle) und Windgeschwindigkeit. Ein Outdoor-Festival zeigt die Wettervorhersage für das Festival-Wochenende. In beiden Fällen liefert die Wetter-Anzeige einen konkreten Mehrwert, der Besucher auf der Website hält.

## Arquitetura técnica ruft Wetterdaten per API ab und cached sie lokal

weather2 kommuniziert mit der OpenWeatherMap-API (oder alternativ mit API-Anbietern wie WeatherAPI, Visual Crossing, Meteostat). Die Konfiguration im TYPO3-Backend definiert: API-Key, Standort (Koordinaten oder Ortsname), Einheiten (metrisch/imperial), Sprache und Update-Intervall. Der Standard-Intervall ist 30 Minuten, das heisst alle 30 Minuten wird ein API-Request an OpenWeatherMap gesendet und die Antwort in der TYPO3-Datenbank gecached.

Das Frontend-Plugin rendert die Wetterdaten über Fluid-Templates: aktuelle Temperatur, Wetter-Icon (Sonne, Wolken, Regen), Textbeschreibung, Wind, Luftfeuchtigkeit. Die Mehrtagesprognose zeigt Tagesminimum und -maximum für drei bis sieben Tage. Icons werden als SVG ausgeliefert, nicht als externe Bild-URLs, damit keine zusätzlichen Requests an Dritt-Server gehen.

Für den API-Key bietet OpenWeatherMap einen kostenlosen Plan mit 1.000 Calls pro Tag, was bei einem 30-Minuten-Intervall (48 Calls pro Tag) mehr als ausreicht. Für Websites mit mehreren Standorten (z.B. ein Tourismusverband mit 10 Orten) werden 480 Calls pro Tag benötigt, was immer noch im Free-Tier liegt. Pro-Pläne (ab 40 Dollar/Monat) bieten stündliche Updates und erweiterte Daten wie UV-Index und Pollenflug.

## Problemas frequentes betreffen API-Limits, Caching und veraltete Daten

Das häufigste Problem ist die Überschreitung des API-Limits. Wenn das TYPO3-Caching nicht korrekt konfiguriert ist und jeder Seiten-Request einen API-Call auslöst, ist das Free-Tier-Limit von 1.000 Calls nach wenigen Stunden erreicht. Die Extension zeigt dann keine Daten mehr oder einen Fehler. A solução: Sicherstellen, dass die Wetterdaten im TYPO3-Cache gespeichert und nicht bei jedem Frontend-Request neu abgerufen werden. Das Caching muss unabhängig vom Seiten-Cache funktionieren (Scheduler-Task oder eigener Cache-Eintrag).

Zweites Problem: Veraltete Wetterdaten. Wenn der Scheduler-Task nicht läuft (Cronjob deaktiviert, Server-Migration), zeigt die Website Tage oder Wochen alte Wetterdaten. Das ist schlimmer als keine Anzeige. A solução: Im Fluid-Template ein Fallback einbauen, das prüft, ob die gecachten Daten älter als zwei Stunden sind, und bei veralteten Daten das Widget ausblendet statt falsche Daten anzuzeigen.

Drittes Thema: proteção de dados. Wenn die Wetterdaten per JavaScript direkt vom Client an die API abgerufen werden, überträgt der Browser die IP des Besuchers an den API-Anbieter. Das ist eine Drittanbieter-Datenübertragung, die LGPD (PT: RGPD)-relevant ist. Die serverseitige Lösung (TYPO3-Server ruft die API ab, nicht der Browser) vermeidet dieses Problem.

## TYPO3 v12 wird unterstützt, die API-Integration bleibt versionsunabhängig stabil

weather2 nutzt die TYPO3-HTTP-Client-Library für API-Requests und Fluid-Templates für das Rendering. Beides ist im TYPO3-Core stabil. Unter v12 läuft die Extension ohne Probleme. Für v13 sind minimale Anpassungen nötig (Scheduler-Task-Registrierung, Plugin-Konfiguration). Da die Kernlogik (HTTP-Request, JSON-Parsing, Datenbank-Speicherung) standardisiert ist, bleibt die Extension bei TYPO3-Upgrades wartungsarm. A Gosign configura Wetter-Widgets als Teil von Tourismus-Website-Projekten und stellt sicher, dass API-Caching, Fallback und proteção de dados korrekt implementiert sind.
---

--- web2pdf TYPO3 - Páginas como PDF | Gosign ---
> web2pdf: Exportar páginas TYPO3 como PDF. Configuração, performance e alternativas modernas (Puppeteer). acelerado com IA.

## Por que web2pdf é indispensável para sites TYPO3 com listas de preços e páginas de produto

Equipes de vendas precisam de PDFs imprimíveis. Clientes esperam um botão "Salvar como PDF" em páginas de produto. E compradores na indústria baixam listas de preços para encaminhá-las internamente. web2pdf resolve exatamente esse problema: a extensão renderiza qualquer página TYPO3 como PDF - com layout correto, imagens incorporadas e tipografia limpa. Em vez de criar manualmente cada página como PDF e atualizá-la a cada mudança, web2pdf gera o PDF ao vivo a partir do conteúdo atual da página.

Isso economiza não apenas tempo de edição, mas também evita versões PDF desatualizadas. Quando o preço de um produto é alterado no CMS, web2pdf entrega automaticamente a versão atualizada no próximo download.

## Cenários típicos de uso

**Catálogos de produtos e listas de preços no B2B.** Uma empresa de engenharia mantém 200 páginas de produto no TYPO3. A equipe de campo precisa de uma ficha técnica imprimível para cada produto. web2pdf gera de cada página de produto um PDF com logo, dados técnicos e informações de contato no design corporativo.

**Artigos e whitepapers como download.** Empresas de mídia e editoras especializadas oferecem artigos de revista como download PDF. web2pdf converte o artigo incluindo imagens e formatação em um PDF otimizado para impressão. Um CSS de impressão controla quais elementos aparecem no PDF e quais não (navegação, footer, banner de cookies).

**Ofertas e configurações.** Resultados de configuradores, resumos de ofertas ou visões gerais de carrinho podem ser exportados como PDF via web2pdf. O usuário clica em "Oferta como PDF" e recebe um documento pronto para impressão.

## Arquitetura técnica

web2pdf funciona como extensão TYPO3 com um plugin frontend que exibe um botão de download PDF em cada página. Ao clicar, a extensão chama internamente a página atual e passa o output HTML para um backend de renderização PDF.

A extensão suporta dois motores de renderização: wkhtmltopdf (solução clássica, baseada em versão antiga do WebKit - sem suporte a Flexbox e Grid CSS) e Puppeteer/Chromium (alternativa moderna com suporte CSS completo, incorporação correta de webfonts, execução de JavaScript).

Um CSS de impressão separado (`@media print`) controla quais elementos são visíveis no PDF. A Gosign recomenda ocultar navegação, footer, banner de cookies e elementos interativos no CSS de impressão e inserir logo, dados de contato e URL.

## Problemas frequentes e soluções

**PDF mostra layout errado, imagens ou fontes ausentes.** Causa mais frequente: wkhtmltopdf não consegue renderizar CSS moderno. Sites que usam Flexbox ou CSS Grid ficam completamente diferentes no PDF. Solução: trocar para Puppeteer como motor de renderização.

**Geração de PDF leva mais de 10 segundos.** Puppeteer inicia um processo Chromium para cada PDF. Com requisições simultâneas, a carga do servidor multiplica. Solução: implementar caching de PDF. O PDF gerado é cacheado no sistema de arquivos por um tempo definido (ex: 60 minutos).

**Páginas autenticadas entregam PDF vazio.** web2pdf chama a página internamente via HTTP. Se a página está atrás de login, faltam os cookies de sessão. Solução: configurar um endpoint dedicado de renderização PDF que resolve a autenticação via token.

## Migração e compatibilidade de versões

web2pdf está disponível de forma estável para TYPO3 v10 e v11. Para TYPO3 v12 LTS existem forks da comunidade. O pacote original não é mais mantido ativamente.

Para TYPO3 v13 e além, a Gosign recomenda uma mudança arquitetural: em vez de operar web2pdf como extensão TYPO3, a geração de PDF é implementada como microserviço separado. Um serviço Node.js com Puppeteer recebe URLs e retorna PDFs. Isso desacopla a geração de PDF do servidor TYPO3 e torna a solução independente da versão TYPO3.

O esforço de migração de web2pdf para uma solução baseada em Puppeteer é tipicamente de 2 a 4 dias. Os arquivos CSS de impressão existentes podem ser reutilizados 1:1.

Um aspecto frequentemente subestimado na geração de PDF: acessibilidade. PDFs gerados a partir de HTML não são automaticamente acessíveis. Para empresas sujeitas à Lei de Fortalecimento da Acessibilidade (BFSG, vigente desde junho de 2025), os PDFs gerados devem conter estruturas Tagged PDF. Nem wkhtmltopdf nem Puppeteer geram PDFs acessíveis por padrão.

--- Webflow zu TYPO3 - Migration | Gosign ---
> Migração de sites Webflow para TYPO3: Mais controle, sem dependência de plataforma, recursos corporativos. Gosign konvertiert Webflow-HTML/CSS.

## Webflow-Websites stossen bei Enterprise-Anforderungen an harte Grenzen

Webflow ist hervorragend für Prototypen, Landingpages und Startups mit drei bis fünf Mitarbeitenden. Aber ab einem gewissen Punkt wird die Plattform zum Problem: keine Multi-Language-Unterstützung auf Enterprise-Niveau, kein feingranulares Rechtemanagement, keine Custom-Backend-Workflows, keine On-Premise-Option, und Hosting ausschliesslich auf Webflow-Servern in den USA. Für Unternehmen, die in der EU gehostet werden müssen (LGPD (PT: RGPD), Schrems II), mehrere hundert Seiten verwalten und ein CMS mit Redakteurs-Workflows brauchen, ist TYPO3 die logische Weiterentwicklung. A Gosign migra Webflow-Websites auf TYPO3: Das bestehende Design (HTML/CSS) wird in Fluid Templates konvertiert, der Content wird strukturiert übernommen, und die Funktionalität wird durch TYPO3-Extensions ergänzt.

## Cenários típicos de uso envolvem wachsende Unternehmen, regulierte Branchen und internationale Rollouts

Das häufigste Szenario ist das schnell gewachsene Startup, das seine Webflow-Seite nicht mehr skaliert bekommt. Mit 20 Mitarbeitenden und einer Website in einer Sprache funktioniert Webflow. Mit 200 Mitarbeitenden, fünf Sprachen und einem Blog mit 500 Artikeln nicht mehr. Die Webflow-Preisstruktur skaliert nicht: CMS-Pläne sind auf 10.000 Items begrenzt, Custom Code ist limitiert, API-Zugriffe gedrosselt. Der Wechsel auf TYPO3 gibt dem Unternehmen volle Kontrolle über Hosting, Performance und Erweiterbarkeit.

Ein zweites Szenario sind regulierte Branchen. Ein Finanzdienstleister hat seine Marketing-Website auf Webflow aufgebaut, aber die Compliance-Abteilung verlangt EU-Hosting, Audit-Logs für Content-Änderungen und ein Freigabe-Workflow, bei dem vier Augen jeden Seiteninhalt genehmigen. Webflow bietet keinen dieser Punkte nativ. TYPO3 schon: Workspaces für Staging und Freigabe, ext:belog für Audit-Logs, und Hosting auf einem Server in Frankfurt.

Drittes Szenario: Internationaler Rollout. Ein Industrieunternehmen hat seine Hauptseite auf Webflow in Englisch. Jetzt sollen Landeswebsites in 12 Sprachen entstehen. Webflow Localization ist teuer und limitiert. TYPO3 bietet native Multi-Site- und Multi-Language-Unterstützung, bei der jede Sprache eine eigene Seitenstruktur haben kann, inklusive lokaler Inhalte, die nicht in allen Sprachen existieren.

## Arquitetura técnica konvertiert Webflow-Export in TYPO3-Fluid-Templates

Die Migration folgt einem definierten Prozess: Export des Webflow-Projekts als HTML/CSS/JS, Analyse der Seitenstruktur und der eingesetzten Interaktionen, Konvertierung des HTML in Fluid-Templates, Import der Inhalte in TYPO3-Content-Elemente. Der Webflow-Export liefert sauberes, semantisches HTML, das sich gut in Fluid übersetzen lässt. CSS wird als Sass/SCSS-Datei übernommen oder in Tailwind-Utility-Klassen umgeschrieben, je nach TYPO3-Setup.

Webflow-Interaktionen (Scroll-Animationen, Hover-Effekte, Modals) basieren auf einer proprietären JavaScript-Engine. Diese 1:1 zu übernehmen ist nicht möglich. Stattdessen werden die Interaktionen mit nativem CSS (transitions, animations) oder leichtgewichtigem JavaScript (IntersectionObserver, Dialog-Element) nachgebaut. In den meisten Fällen reduziert das die JavaScript-Dateigrösse von 200-300 KB (Webflow Runtime) auf unter 20 KB.

Der Content-Import läuft über die Webflow-API oder den HTML-Export. Jede Webflow Collection wird auf ein TYPO3-Content-Element oder einen Extbase-Record gemappt. Blog-Artikel werden in tx_news importiert, Team-Mitglieder in Custom Records, Testimonials in die bestehende TYPO3-Datenstruktur.

## Problemas frequentes betreffen Webflow-spezifische Features und URL-Redirects

Das grösste Problem bei der Migration sind Webflow-Features ohne TYPO3-Äquivalent. Webflow Forms laufen über einen integrierten Form-Handler. In TYPO3 muss ein Formular-System (powermail, Form Framework) konfiguriert werden. Webflow E-Commerce läuft auf der Plattform. In TYPO3 muss ein Shopsystem (TYPO3-native oder Shopware/Magento-Integration) eingerichtet werden. Diese Funktionslücken müssen vor der Migration identifiziert und im TYPO3-Projekt geplant werden.

Zweites Problem: URL-Redirects. Webflow-URLs folgen einem eigenen Schema. Nach der Migration müssen alle alten URLs auf die neuen TYPO3-URLs umgeleitet werden, damit Google die Seiten nicht als 404 indexiert und bestehende Backlinks erhalten bleiben. Bei 200 Seiten sind das 200 Redirects, die in der TYPO3-Redirect-Tabelle oder per .htaccess konfiguriert werden.

Drittes Thema: Design-Differenzen. Webflow rendert CSS-Layouts mit einer eigenen Engine, die von Browser-Standardverhalten abweichen kann. Ein Layout, das in Webflow pixel-perfekt aussieht, kann in TYPO3 minimal anders rendern, weil der CSS-Reset oder die Schriftart-Einbindung abweicht. Ein visueller QA-Pass nach der Migration ist deshalb Pflicht.

## Die Migration ist kein Upgrade, sondern ein Plattformwechsel

Es gibt keinen automatisierten Migrationspfad von Webflow zu TYPO3. Jede Migration ist ein Projekt mit Analyse, Konvertierung, Import und QA. Die Dauer hängt von der Komplexität ab: Eine einfache Website mit 20 Seiten und einem Blog ist in zwei bis drei Wochen migriert. Eine komplexe Website mit 500 Seiten, E-Commerce und fünf Sprachen braucht zwei bis drei Monate. A Gosign Webflow-Migrationen für Unternehmen von 50 bis 2.000 Seiten durchgeführt und setzt dabei auf KI-gestützte Template-Konvertierung, die den Fluid-Code aus dem Webflow-HTML generiert und die manuelle Anpassung auf ein Minimum reduziert.
---

--- WebP TYPO3 - Otimização de imagens | Gosign ---
> Conversão automática de JPG/PNG para WebP. 25–35% menor em arquivos de imagem, tempos de carregamento mais rápidos.

## Bilder machen 50 bis 70 Prozent des Seitengewichts aus, und WebP reduziert sie um ein Drittel

Die durchschnittliche TYPO3-Website lädt pro Seite 2 bis 5 MB an Bilddaten. Das ist der grösste einzelne Faktor für die Ladezeit und damit für den Google PageSpeed Score. WebP ist ein von Google entwickeltes Bildformat, das bei vergleichbarer Qualität 25 bis 35 Prozent kleiner ist als JPEG und bis zu 80 Prozent kleiner als PNG. Die TYPO3 WebP-Extension konvertiert vorhandene JPG- und PNG-Bilder automatisch in WebP, ohne dass Redakteure ihr Verhalten ändern müssen. Bilder werden wie gewohnt im FAL-Backend hochgeladen, die Extension erzeugt die WebP-Variante im Hintergrund und liefert sie an Browser aus, die das Format unterstützen. Alle modernen Browser unterstützen WebP seit 2020: Chrome, Firefox, Safari, Edge.

Für Websites, die bereits PageSpeed-optimiert sind, ist die WebP-Konvertierung oft der letzte Schritt, der den Score von 85 auf 95 oder höher hebt.

## Cenários típicos de uso envolvem bildlastige Websites, E-Commerce und Mobile-First-Projekte

Das häufigste Szenario sind bildlastige Unternehmenswebsites. Ein Immobilienportal zeigt pro Objekt 15 bis 25 Fotos. Bei 500 Objekten sind das 10.000 Bilder. Ohne WebP wiegen die Bilder im Schnitt 250 KB (JPEG), mit WebP 170 KB. Auf einer Listenansicht mit 20 Objekten und je einem Titelbild spart WebP 1,6 MB pro Seitenaufruf. Bei 50.000 Seitenaufrufen pro Monat sind das 80 GB weniger Traffic, was sich direkt auf die Hosting-Kosten auswirkt.

Ein zweites Szenario sind E-Commerce-Integrationen. Ein Shopsystem zeigt Produktbilder in verschiedenen Grössen: Thumbnail, Listenansicht, Detailansicht, Zoom. Jede Grösse wird als WebP-Variante generiert. Bei einem Shop mit 2.000 Produkten und je fünf Bildvarianten entstehen 10.000 WebP-Dateien, die den Seitenaufbau in der Listenansicht messbar beschleunigen.

Drittes Szenario: Mobile-First-Websites für Zielgruppen mit schlechter Netzanbindung. Ein NGO-Portal, das in Regionen mit 3G-Netzen genutzt wird, profitiert überproportional von kleineren Bilddateien. Der Unterschied zwischen 5 Sekunden und 15 Sekunden Ladezeit entscheidet, ob der Besucher die Seite sieht oder abbricht.

## Arquitetura técnica konvertiert Bilder im TYPO3-Processing-Pipeline

Die Extension klinkt sich in die TYPO3-Bild-Processing-Pipeline ein. Wenn TYPO3 ein Bild verarbeitet (Resize, Crop), erzeugt die Extension zusätzlich eine WebP-Variante im selben Verzeichnis. Die Auslieferung erfolgt über Content Negotiation: Der Server prüft den Accept-Header des Browsers. Wenn der Browser "image/webp" akzeptiert, liefert er die WebP-Datei. Andernfalls das Original-JPEG/PNG.

Technisch gibt es zwei Implementierungsvarianten: Die erste nutzt mod_rewrite-Regeln im Apache oder nginx, die Bild-Requests auf die WebP-Variante umleiten, wenn sie existiert. Die zweite nutzt ein TYPO3-Middleware, das den Response-Header manipuliert. Die mod_rewrite-Variante ist performanter, weil sie vor PHP ausgeführt wird.

Die Konvertierung selbst läuft über libwebp (Kommandozeilen-Tool cwebp), ImageMagick mit WebP-Support oder die PHP-Extension GD (wenn mit WebP-Support kompiliert). Die Qualität ist konfigurierbar: Standard 80 (von 100), was einen guten Kompromiss zwischen Dateigrösse und visueller Qualität bietet. Für fotografische Inhalte empfehlen wir 82 bis 85, für Screenshots und Illustrationen 75 bis 78.

Für noch bessere Kompression unterstützen neuere Versionen der Extension das AVIF-Format, das weitere 20 bis 30 Prozent Einsparung gegenüber WebP bietet. AVIF-Support ist in Chrome und Firefox verfügbar, Safari seit Version 16.

## Problemas frequentes betreffen fehlende Server-Libraries und CDN-Konfiguration

Das häufigste Problem ist die fehlende cwebp-Binary auf dem Server. Shared-Hosting-Umgebungen haben oft kein libwebp installiert, und der Hoster erlaubt keine Installation von Binaries. A solução: PHP GD mit WebP-Support nutzen (in den meisten PHP-Versionen ab 7.1 verfügbar) oder einen Hosting-Provider wählen, der cwebp bereitstellt. Auf Managed-Servern und in Docker-Containern ist die Installation trivial: apt-get install webp.

Zweites Problem: CDN-Konfiguration. Wenn ein CDN (Cloudflare, Fastly, AWS CloudFront) vor der Website liegt, muss es WebP korrekt handhaben. Zwei Ansätze: Das CDN kennt Content Negotiation und cached WebP und JPEG als separate Varianten (Vary: Accept). Oder die TYPO3-Website liefert direkt WebP-URLs aus (ohne Content Negotiation), und das CDN cached nur eine Version. Cloudflare bietet automatische WebP-Konvertierung über Polish, was die TYPO3-Extension teilweise überflüssig macht.

Drittes Thema: Qualitätskontrolle. Bei zu niedriger Qualitätseinstellung (unter 70) werden Artefakte sichtbar, besonders bei Farbverläufen und feinen Texturen. Ein A/B-Vergleich (Original vs. WebP) sollte nach der Konfiguration durchgeführt werden, um sicherzustellen, dass die Qualität für den Anwendungsfall akzeptabel ist.

## TYPO3 v12 und v13 werden unterstützt, die Extension ist eine der stabilsten im Ökosystem

Die WebP-Extension gehört zu den am häufigsten installierten Performance-Extensions im TYPO3-Ökosystem. Sie wird aktiv gepflegt und ist mit TYPO3 v12 und v13 kompatibel. Da die Kernfunktionalität (Bild-Processing-Hook, Datei-Konvertierung) auf stabilen TYPO3-APIs basiert, sind Breaking Changes bei Upgrades selten. A Gosign configura WebP als Standard in jedem neuen TYPO3-Projekt und aktiviert bei Verfügbarkeit zusätzlich AVIF für maximale Kompression.
---

--- Bootstrap TYPO3 - T3Bootstrap | Gosign ---
> Framework Bootstrap como sitepackage TYPO3. Templates responsivos, sistema de grade, componentes Bootstrap como elementos de conteúdo. Ponto de partida.

## Bootstrap-basierte TYPO3-Projekte brauchen ein Sitepackage, das die Brücke zwischen Framework und CMS schlägt

Bootstrap ist das meistgenutzte CSS-Framework der Welt. Über 25 Prozent aller Websites setzen Bootstrap ein. Für TYPO3-Projekte bedeutet das: Designer liefern Entwürfe in Bootstrap, Entwickler kennen die Klassen und Komponenten, und Kunden erwarten responsive Layouts, die auf Bootstrap aufbauen. ws_t3bootstrap bringt Bootstrap als Sitepackage direkt in TYPO3: Responsive Templates, das Grid-System, Bootstrap-Komponenten (Accordion, Cards, Carousel, Tabs, Alerts) als Content-Elemente und eine vorkonfigurierte TypoScript-Basis. Statt Bootstrap manuell in ein leeres TYPO3-Projekt zu integrieren, liefert ws_t3bootstrap einen funktionsfähigen Startpunkt, der sofort produktionsfähig ist.

## Cenários típicos de uso são Unternehmenswebsites, Portale und Rapid-Prototyping

Das häufigste Szenario ist die mittelständische Unternehmenswebsite. Ein Unternehmen mit 50 bis 500 Mitarbeitenden braucht eine Website mit 30 bis 80 Seiten: Startseite, Über uns, Leistungen, Referenzen, Karriere, Kontakt. Der Designer erstellt ein Mockup auf Basis von Bootstrap 5. ws_t3bootstrap liefert die Templates, das Grid-System und die Content-Elemente, sodass der Entwickler nur das Custom CSS (Farben, Schriften, Abstände) und projektspezifische Komponenten ergänzen muss. Typische Entwicklungszeit: zwei bis drei Wochen vom Mockup zur fertigen Website, statt vier bis sechs Wochen bei einem Custom-Setup.

Ein zweites Szenario sind Intranet-Portale. Ein Unternehmen betreibt ein TYPO3-Intranet für 2.000 Mitarbeitende. Das Design muss nicht einzigartig sein, aber konsistent und responsive. ws_t3bootstrap liefert ein professionelles Standard-Layout, das ohne grossen Design-Aufwand eingesetzt werden kann. Content-Elemente wie Akkordeons für FAQs, Tabs für Abteilungsinformationen und Cards für News-Teaser sind sofort verfügbar.

Drittes Szenario: Rapid Prototyping. Eine Agentur baut in zwei Tagen einen funktionierenden Website-Prototyp, den der Kunde freigeben kann. ws_t3bootstrap reduziert die Setup-Zeit auf Stunden statt Tage, weil die Grundstruktur (Header, Footer, Navigation, Grid) bereits steht.

## Arquitetura técnica registriert Bootstrap-Komponenten als TYPO3 Content Elements

ws_t3bootstrap installiert sich als TYPO3-Sitepackage und konfiguriert: TypoScript-Setup mit Bootstrap-CSS/JS-Includes, Fluid-Templates für Header, Footer und Seitenlayouts, Backend-Layouts (1-Spalter, 2-Spalter, 3-Spalter mit Sidebar) und Content-Elemente, die Bootstrap-Komponenten abbilden.

Die Content-Elemente werden über TCA-Konfigurationen und Fluid-Templates definiert. Ein Accordion-Element erstellt beispielsweise ein Bootstrap-Accordion mit n Panels, jedes Panel mit Titel und Body-Text. Ein Card-Element erzeugt eine Bootstrap-Card mit Bild, Titel, Text und Link. Ein Grid-Element ermöglicht verschachtelte Spalten-Layouts innerhalb einer Seite.

Das Bootstrap-CSS wird entweder als kompilierte CSS-Datei eingebunden (schnell, keine Build-Tools nötig) oder als Sass-Quellcode, der über ein Build-System (Webpack, Vite) kompiliert wird. Die Sass-Variante erlaubt, Bootstrap-Variablen (Farben, Breakpoints, Schriftgrössen) zu überschreiben und nur die benötigten Bootstrap-Module einzubinden, was die CSS-Dateigrösse von 230 KB auf 80 bis 120 KB reduziert.

Die JavaScript-Komponenten (Accordion, Collapse, Dropdown, Modal, Tab, Toast) werden über Bootstrap 5 eingebunden, das ohne jQuery auskommt. Das reduziert die JavaScript-Dateigrösse gegenüber Bootstrap 4 um rund 85 KB (jQuery-Wegfall).

## Problemas frequentes betreffen Bootstrap-Versions-Konflikte und CSS-Spezifitäts-Kämpfe

Das grösste Problem bei Bootstrap-Sitepackages ist der Versions-Konflikt. Wenn ws_t3bootstrap Bootstrap 5.2 einbindet, aber eine andere Extension (z.B. ein Slider-Plugin) Bootstrap 4.6 oder 3.x mitbringt, kollidieren die CSS-Klassen. Bootstrap 4 nutzt "col-md-4", Bootstrap 5 ebenfalls, aber mit unterschiedlichem Verhalten bei bestimmten Utilities. A solução: Alle Extensions auf dieselbe Bootstrap-Version vereinheitlichen oder Extension-eigenes Bootstrap per CSS-Scoping isolieren.

Zweites Problem: CSS-Spezifität. Wenn Custom CSS die Bootstrap-Klassen überschreiben muss, entsteht ein Spezifitäts-Wettlauf: !important-Deklarationen häufen sich, weil Bootstrap-Utilities hohe Spezifität haben. A solução: Bootstrap-Variablen statt CSS-Overrides nutzen und das Custom-Stylesheet nach dem Bootstrap-CSS laden.

Drittes Thema: Performance. Bootstrap als Framework lädt alle Komponenten, auch wenn die Website nur fünf davon nutzt. Bei einer Website, die nur Grid, Cards und Navbar braucht, werden 80 Prozent des Bootstrap-CSS nie genutzt. PurgeCSS oder ein selektiver Sass-Import reduziert die CSS-Dateigrösse auf das Nötige.

## TYPO3 v12 und v13 werden unterstützt, Bootstrap 5 ist der aktuelle Standard

ws_t3bootstrap wird aktiv gepflegt und unterstützt TYPO3 v12 und v13. Die aktuelle Version basiert auf Bootstrap 5.3. Beim Upgrade von Bootstrap 4 auf 5 sind Breaking Changes zu beachten: jQuery-Abhängigkeit entfällt, einige CSS-Klassen wurden umbenannt (z.B. ml-/mr- zu ms-/me-), und die JavaScript-API hat sich geändert. Gosign führt Bootstrap-Upgrades zusammen mit TYPO3-Upgrades durch und prüft dabei alle Content-Elemente auf korrekte Darstellung. Bei neuen Projekten empfehlen wir ws_t3bootstrap als Startpunkt und ergänzen das Sitepackage um projektspezifische Komponenten, statt Bootstrap von Grund auf in TYPO3 zu integrieren.
---

--- wwt3_encryption TYPO3 - Proteção de e-mail | Gosign ---
> Extensão TYPO3 para proteção automática de e-mails no site. Protege endereços de e-mail contra harvesting e spam bots por meio de ofuscação.

## Por que a ofuscação de email continua sendo obrigatória em qualquer site público

Todo site corporativo, toda página universitária e toda presença de órgão público publica endereços de email: contatos no impressum legal, pessoas de contato em equipes, contatos de imprensa em newsrooms, departamento jurídico em avisos de privacidade. Sem proteção, bots harvesters coletam esses endereços em poucos dias após a publicação e os vendem a remetentes de spam. O wwt3_encryption é uma extensão TYPO3 clássica para esse problema e ofusca endereços de email no servidor, de modo que bots fazendo parse de HTML só vêem código inútil, enquanto usuários reais podem clicar no endereço correto. A extensão se destina a operadores que, por razões legais, precisam exibir dados de contato de forma proeminente, mas não estão dispostos a aceitar a enxurrada de spam resultante.

## Cenários típicos de uso

Um escritório de advocacia brasileiro com 60 sócios e associados publica todos os perfis dos advogados, inclusive endereços de email diretos, porque o Código de Ética da OAB exige uma forma de contato acessível. Sem ofuscação, todos os 60 endereços recebem em semanas emails de phishing, publicidade e, em parte, ataques direcionados. O wwt3_encryption renderiza os endereços de forma que o código-fonte não contém string @ legível, enquanto o navegador exibe o endereço mailto correto ao usuário.

Um segundo cenário é uma universidade, como USP ou UNICAMP, que mantém páginas de departamentos com contatos de cátedras. Cada cátedra tem uma página com telefone e email, editada via TYPO3 pela equipe editorial. Os redatores inserem os endereços como texto normal em elementos RichText ou campos de contato, sem se preocupar com ofuscação. O wwt3_encryption entra automaticamente no processo de renderização e protege todos os links mailto sem esforço editorial adicional.

O terceiro caso são órgãos públicos brasileiros com impressum, formulários de contato e listas de departamentos. Aqui a exigência costuma ser ainda mais rígida, porque há uma exigência de acessibilidade: o endereço protegido precisa ser lido corretamente por leitores de tela, e um clique precisa abrir o cliente de email, exatamente como em um endereço não ofuscado. Uma combinação de decodificação JavaScript e atributos href semanticamente limpos é o único caminho para cumprir os dois requisitos.

## Arquitetura técnica: content post-processing no rendering do TYPO3

O wwt3_encryption se liga ao processo de renderização do TYPO3, tipicamente via hook de Content Post-Processor ou uma Userfunc TypoScript. Depois que o page renderer monta o HTML de saída, a extensão percorre o markup finalizado, encontra todos os links mailto e todos os endereços de email simples em texto corrido via regex e os substitui por variantes ofuscadas. A ofuscação pode ser feita por vários métodos: codificação ROT13 do alvo do link com decodificação JavaScript, codificação Base64, fragmentação caractere a caractere com pseudoelementos CSS ou uma combinação.

A vantagem da variante post-processing é que ela funciona sem alterações em elementos de conteúdo ou templates. Redatores continuam trabalhando com links mailto normais no RichText, e a extensão assume a proteção automaticamente. A configuração é feita via constantes TypoScript, que permitem escolher entre os vários métodos de ofuscação e definir exceções para determinadas páginas ou seções de conteúdo.

## Problemas frequentes e soluções

O primeiro problema é acessibilidade. Soluções puramente JavaScript falham em usuários com JavaScript desativado, e alguns leitores de tela têm problemas com fragmentação baseada em CSS. Uma abordagem pragmática combina uma ofuscação no cliente facilmente quebrável com um aria-label semântico adicional no link, de forma que leitores de tela leiam o endereço corretamente enquanto harvesters falham na diferença sintática. Segurança absoluta não é alcançável com endereços publicamente acessíveis, mas mesmo barreiras moderadas reduzem mensuravelmente a carga de spam.

O segundo problema são camadas de cache. Se a ofuscação post-processing roda antes do page cache, o cache entrega os dados ofuscados e tudo funciona. Se, pelo contrário, ela roda depois do cache, toda página cacheada é reprocessada em cada requisição, o que afeta perceptivelmente a performance. A ordem correta na rendering chain do TypoScript é crítica e deve ser verificada a cada mudança maior no comportamento de caching.

O terceiro tema envolve conteúdos dinâmicos. Endereços de email recarregados via AJAX ou vindos de APIs externas não passam pelo renderer do TYPO3 e, portanto, não passam pelo wwt3_encryption. Esses pontos precisam ser protegidos separadamente, seja fazendo a API entregar variantes ofuscadas, seja por um JavaScript cliente que pós-processa o conteúdo recarregado.

## Migração e compatibilidade de versões

O wwt3_encryption tem, como muitas extensões TYPO3 mais antigas, um histórico de versões inconsistente: para v9 e v10 houve releases mantidos, para v11 e v12 existem forks comunitários com atividade variada. Quem migra para TYPO3 v13 deve, antes do upgrade, verificar se o próprio fork ainda funciona ou se uma mudança para um método alternativo de ofuscação é necessária.

O core TYPO3 traz um sistema simples de ofuscação de email, ativado via config.spamProtectEmailAddresses no TypoScript, que aplica ROT13 no kernel do renderer. Para setups simples, essa variante do core basta e torna uma extensão própria desnecessária. Quem precisa de ofuscação mais forte ou flexível, por exemplo com vários métodos em paralelo ou exceções por elemento de conteúdo, recorre a uma extensão como wwt3_encryption. A Gosign avalia caso a caso se a função do core basta ou se uma extensão dedicada faz sentido, e apoia, se necessário, a reconstrução em uma implementação post-processing enxuta própria, adaptada ao projeto em questão.

A eficácia de qualquer ofuscação de email diminui com o tempo, porque as técnicas dos harvesters evoluem. ROT13 hoje é considerado quase ineficaz contra bots especializados, enquanto fragmentação caractere a caractere com CSS ou truques Unicode ainda levantam barreiras moderadas. A defesa realmente sólida é, portanto, uma combinação: ofuscação no HTML output, complementada por um bom filtro de spam no lado do destinatário e, idealmente, uma opção de contato via formulário em vez de um endereço publicado diretamente. Quem precisa cumprir exigências legais não escapará da publicação, mas deve oferecer o formulário de contato como via primária e mostrar o endereço apenas secundariamente.

Para operadores de TYPO3 v13, recomenda-se adicionalmente verificar a pipeline de renderização de conteúdo regularmente contra breaking changes no core. Alguns pontos de hook disponíveis em versões anteriores para post-processing foram deprecated na v13 ou substituídos por eventos PSR-14. Extensões que ainda dependem dos hooks antigos rodam tecnicamente após o upgrade, mas não processam mais conteúdo. Uma verificação curta dos logs após um upgrade revela essas falhas silenciosas cedo e evita que, por semanas, endereços não ofuscados sejam entregues sem que ninguém perceba.

--- TYPO3 Extensions | Desenvolvimento e monitoramento ---
> 800+ extensions TYPO3 monitoradas. Desenvolvimento, auditoria e monitoramento de segurança. Todas as extensions em um só lugar.

<!-- O que a Gosign oferece? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">O que a Gosign oferece para extensions TYPO3?</h2>
<p class="text-body text-gosign-text leading-relaxed">
A Gosign monitora mais de 800 extensions TYPO3 quanto a vulnerabilidades de segurança, compatibilidade e performance. Para cada extension, a Gosign oferece: desenvolvimento do zero, atualização e migração, auditoria de código e manutenção. Há 25&nbsp;anos no desenvolvimento TYPO3, desde 2023 com desenvolvimento acelerado por IA: 60 a 80% mais rápido do que métodos tradicionais.
</p>
</div>
</section>

<!-- Categorias de extensions -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">Categorias de extensions</h2>
<div class="space-y-8">

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Busca e indexação</h3>
<p class="text-body text-gosign-text mb-4">Apache Solr, ke_search, busca facetada. Busca enterprise em milhares de documentos e arquivos.</p>
<div class="flex flex-wrap gap-2">
<a href="/br/typo3/solrfal/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">solrfal</a>
<a href="/br/typo3/ke_search_premium/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">ke_search_premium</a>
<a href="/br/typo3/find/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">find</a>
<a href="/br/typo3/in2studyfinder/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">in2studyfinder</a>
</div>
</div>

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Segurança e autenticação</h3>
<p class="text-body text-gosign-text mb-4">SSO, SAML, OIDC, consentimento de cookies, CAPTCHA, CORS. Segurança enterprise para TYPO3.</p>
<div class="flex flex-wrap gap-2">
<a href="/br/typo3/shibboleth_auth/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">shibboleth_auth</a>
<a href="/br/typo3/oidc/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">oidc</a>
<a href="/br/typo3/dp_cookieconsent/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">dp_cookieconsent</a>
<a href="/br/typo3/saml2/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">saml2</a>
<a href="/br/typo3/be_acl/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">be_acl</a>
</div>
</div>

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Formulários e eventos</h3>
<p class="text-body text-gosign-text mb-4">Powermail, gestão de eventos, sistemas de reservas, pesquisas, integração com newsletters.</p>
<div class="flex flex-wrap gap-2">
<a href="/br/typo3/powermail/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">powermail</a>
<a href="/br/typo3/sf_event_mgt/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">sf_event_mgt</a>
<a href="/br/typo3/booking/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">booking</a>
<a href="/br/typo3/rapidmail/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">rapidmail</a>
</div>
</div>

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Conteúdo e templates</h3>
<p class="text-body text-gosign-text mb-4">Mask, DCE, VHS ViewHelper, Bootstrap Grids. Elementos de conteúdo personalizados e desenvolvimento de templates.</p>
<div class="flex flex-wrap gap-2">
<a href="/br/typo3/mask/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">mask</a>
<a href="/br/typo3/dce/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">dce</a>
<a href="/br/typo3/vhs/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">vhs</a>
<a href="/br/typo3/bootstrap_grids/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">bootstrap_grids</a>
</div>
</div>

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">PDF e documentos</h3>
<p class="text-body text-gosign-text mb-4">Geração de PDF, visualizador de PDF, flipbooks, gestão de downloads.</p>
<div class="flex flex-wrap gap-2">
<a href="/br/typo3/pdfviewhelpers/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">pdfviewhelpers</a>
<a href="/br/typo3/web2pdf/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">web2pdf</a>
<a href="/br/typo3/rflipbook/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">rflipbook</a>
<a href="/br/typo3/downloadmanager/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">downloadmanager</a>
</div>
</div>

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Mídia e imagens</h3>
<p class="text-body text-gosign-text mb-4">Edição de imagens, galerias, sliders, focuspoint, Cloudinary CDN.</p>
<div class="flex flex-wrap gap-2">
<a href="/br/typo3/focuspoint/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">focuspoint</a>
<a href="/br/typo3/imagemap/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">imagemap</a>
<a href="/br/typo3/sf_filecollection_gallery/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">sf_filecollection_gallery</a>
</div>
</div>

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Mapas e localizações</h3>
<p class="text-body text-gosign-text mb-4">Leaflet, Google Maps, OpenStreetMap. Localizador de filiais e busca por raio.</p>
<div class="flex flex-wrap gap-2">
<a href="/br/typo3/leaflet/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">leaflet</a>
<a href="/br/typo3/maps2/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">maps2</a>
<a href="/br/typo3/geocoordinates/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">geocoordinates</a>
</div>
</div>

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">E-commerce</h3>
<p class="text-body text-gosign-text mb-4">aimeos, integração de pagamento, paywall, calculadora de preços.</p>
<div class="flex flex-wrap gap-2">
<a href="/br/typo3/aimeos/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">aimeos</a>
<a href="/br/typo3/amazon_payment/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">amazon_payment</a>
<a href="/br/typo3/paywall/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">paywall</a>
</div>
</div>

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Performance e SEO</h3>
<p class="text-body text-gosign-text mb-4">Cache warmup, staticfilecache, conversão WebP, gestão de canonicals.</p>
<div class="flex flex-wrap gap-2">
<a href="/br/typo3/warmup/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">warmup</a>
<a href="/br/typo3/webp/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">webp</a>
<a href="/br/typo3/newscanonical/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">newscanonical</a>
<a href="/br/typo3/cache_hash/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">cache_hash</a>
</div>
</div>

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">DevTools e deploy</h3>
<p class="text-body text-gosign-text mb-4">Extension Builder, in2publish, Styleguide, Deployer.</p>
<div class="flex flex-wrap gap-2">
<a href="/br/typo3/extension_builder/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">extension_builder</a>
<a href="/br/typo3/in2publish/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">in2publish</a>
<a href="/br/typo3/styleguide/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">styleguide</a>
</div>
</div>

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Soluções setoriais</h3>
<p class="text-body text-gosign-text mb-4">Imobiliário (OpenImmo, FlowFact), universidades (in2studyfinder), associações (hwvereinsliste), educação (kuferweb).</p>
<div class="flex flex-wrap gap-2">
<a href="/br/typo3/openimmo/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">openimmo</a>
<a href="/br/typo3/flowfact/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">flowfact</a>
<a href="/br/typo3/kuferweb/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">kuferweb</a>
</div>
</div>

</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Você precisa de suporte para uma extension TYPO3?</h3>
<p class="text-body text-gosign-text mb-6">30&nbsp;minutos de conversa inicial, gratuita e sem compromisso.</p>
<a
href="/br/contato/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Agendar consultoria sobre extensions
</a>
<p class="text-small text-gosign-text-light mt-4">25 anos de experiência · 800+ extensions · Desenvolvimento acelerado por IA</p>
</div>
</section>

<!-- KI Table -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Desenvolvimento de extensions acelerado por IA</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
A Gosign utiliza desenvolvimento assistido por IA desde 2023. Isso significa concretamente:
</p>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Tarefa</th>
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Tradicional</th>
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Com IA</th>
<th class="py-3 text-small font-bold text-gosign-dark">Economia</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Nova extension (Extbase)</td>
<td class="py-3 pr-4 text-body text-gosign-text">2 a 4 semanas</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">4 a 8 dias</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">70%</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Atualização de extension (v9 para v12)</td>
<td class="py-3 pr-4 text-body text-gosign-text">1 a 2 semanas</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">2 a 4 dias</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">65%</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Auditoria de segurança</td>
<td class="py-3 pr-4 text-body text-gosign-text">3 a 5 dias</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">1 dia</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">75%</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Revisão de código + refatoração</td>
<td class="py-3 pr-4 text-body text-gosign-text">1 semana</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">2 dias</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">60%</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- TYPO3 Update -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Atualização do TYPO3 para a versão atual</h2>
<p class="text-body text-gosign-text leading-relaxed mb-8">
Atualizamos sua instalação TYPO3 para a versão LTS atual com custo competitivo - incluindo todas as extensions, mesmo obsoletas e sem manutenção.
</p>
<div class="grid md:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<div class="flex items-start gap-4">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-1" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75M21 12a9 9 0 1 1-18 0 9 9 0 0 1 18 0Z" /></svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Todas as extensions migradas</h3>
<p class="text-body text-gosign-text">Inclusive obsoletas, sem manutenção ou de desenvolvimento próprio.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-6">
<div class="flex items-start gap-4">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-1" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 18.75a60.07 60.07 0 0 1 15.797 2.101c.727.198 1.453-.342 1.453-1.096V18.75M3.75 4.5v.75A.75.75 0 0 1 3 6h-.75m0 0v-.375c0-.621.504-1.125 1.125-1.125H20.25M2.25 6v9m18-10.5v.75c0 .414.336.75.75.75h.75m-1.5-1.5h.375c.621 0 1.125.504 1.125 1.125v9.75c0 .621-.504 1.125-1.125 1.125h-.375m1.5-1.5H21a.75.75 0 0 0-.75.75v.75m0 0H3.75m0 0h-.375a1.125 1.125 0 0 1-1.125-1.125V15m1.5 1.5v-.75A.75.75 0 0 0 3 15h-.75M15 10.5a3 3 0 1 1-6 0 3 3 0 0 1 6 0Zm3 0h.008v.008H18V10.5Zm-12 0h.008v.008H6V10.5Z" /></svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Preço fixo</h3>
<p class="text-body text-gosign-text">Custos transparentes, sem trabalhos adicionais ocultos.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-6">
<div class="flex items-start gap-4">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-1" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M3.75 13.5l10.5-11.25L12 10.5h8.25L9.75 21.75 12 13.5H3.75Z" /></svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Acelerado por IA</h3>
<p class="text-body text-gosign-text">30 a 50% mais econômico que o mercado graças à análise de código com IA.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-6">
<div class="flex items-start gap-4">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-1" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M20.25 6.375c0 2.278-3.694 4.125-8.25 4.125S3.75 8.653 3.75 6.375m16.5 0c0-2.278-3.694-4.125-8.25-4.125S3.75 4.097 3.75 6.375m16.5 0v11.25c0 2.278-3.694 4.125-8.25 4.125s-8.25-1.847-8.25-4.125V6.375m16.5 0v3.75m-16.5-3.75v3.75m16.5 0v3.75C20.25 16.153 16.556 18 12 18s-8.25-1.847-8.25-4.125v-3.75m16.5 0c0 2.278-3.694 4.125-8.25 4.125s-8.25-1.847-8.25-4.125" /></svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Zero perda de dados</h3>
<p class="text-body text-gosign-text">Migração completa de dados com proteção de rollback.</p>
</div>
</div>
</div>
</div>
<div class="mt-8 text-center">
<a
href="/br/contato/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Solicitar atualização TYPO3
</a>
</div>
</div>
</section>

<!-- LGPD (PT: RGPD) Audit -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Auditoria LGPD do TYPO3 &amp; Conformidade</h2>
<p class="text-body text-gosign-text leading-relaxed mb-8">
Auditamos sua instalação TYPO3 quanto à conformidade com a LGPD e implementamos todas as medidas com custo competitivo.
</p>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse bg-white rounded-card">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Área de auditoria</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">O que é verificado</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Resultado</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Cookie-Consent</td>
<td class="py-3 px-4 text-body text-gosign-text">Banner, opt-in/opt-out, registro de consentimento</td>
<td class="py-3 px-4 text-body text-gosign-text">Fluxo de consentimento em conformidade legal</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Rastreamento e analítica</td>
<td class="py-3 px-4 text-body text-gosign-text">Google Analytics, Matomo, Tag Manager, pixels de terceiros</td>
<td class="py-3 px-4 text-body text-gosign-text">Configuração em conformidade com proteção de dados</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Extensions</td>
<td class="py-3 px-4 text-body text-gosign-text">Compartilhamento de dados com terceiros, requisições externas, integrações CDN</td>
<td class="py-3 px-4 text-body text-gosign-text">Correção ou alternativas em conformidade com a LGPD</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Formulários</td>
<td class="py-3 px-4 text-body text-gosign-text">Registro de tratamento, consentimentos, prazos de retenção</td>
<td class="py-3 px-4 text-body text-gosign-text">Documentação completa</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Hospedagem e SSL</td>
<td class="py-3 px-4 text-body text-gosign-text">Localização do servidor, acordo de processamento, criptografia</td>
<td class="py-3 px-4 text-body text-gosign-text">Hospedagem em conformidade</td>
</tr>
</tbody>
</table>
</div>
<div class="mt-8 text-center">
<a
href="/br/contato/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Solicitar auditoria LGPD
</a>
</div>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
A Gosign é uma agência digital de Hamburgo com 25 anos de experiência em desenvolvimento web, TYPO3 e integração de IA.
Analisamos mais de 800 extensions TYPO3 e hoje desenvolvemos com suporte de IA
até 70% mais rápido do que com métodos tradicionais. A partir do hub europeu em Hamburgo,
atendemos empresas brasileiras e latino-americanas que buscam excelência digital.
</p>
<p class="text-small text-gosign-text-light mt-2">Atualizado em: fevereiro de 2026</p>
</div>
</section>

<!-- Temas relacionados -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Temas relacionados</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/br/typo3-monitor-seguranca/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Monitoramento</p>
<p class="text-body font-semibold text-gosign-dark">Monitor de segurança TYPO3</p>
</a>
<a href="/br/agencia-digital-hamburg/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Desenvolvimento web</p>
<p class="text-body font-semibold text-gosign-dark">Agência digital Hamburgo</p>
</a>
<a href="/br/seguranca-web-padroes/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Segurança</p>
<p class="text-body font-semibold text-gosign-dark">Segurança web conforme padrões CERT.br</p>
</a>
</div>
</div>
</section>

--- Monitor de segurança TYPO3 | Monitoramento ---
> Monitor de segurança TYPO3: monitorar 800+ extensions, detectar vulnerabilidades. Verificação gratuita disponível.

<!-- O que é o monitor? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">O que é o monitor de segurança TYPO3?</h2>
<p class="text-body text-gosign-text leading-relaxed">
O monitor de segurança TYPO3 da Gosign monitora automaticamente mais de 800 extensions TYPO3 quanto a vulnerabilidades de segurança, versões desatualizadas e falhas conhecidas. Quando uma extension recebe um aviso de segurança, os clientes da Gosign ficam sabendo imediatamente - não apenas na próxima verificação manual. O monitor é uma ferramenta desenvolvida pela própria Gosign, que avalia continuamente boletins de segurança TYPO3, changelogs de extensions e bancos de dados CVE.
</p>
</div>
</section>

<!-- Por que monitoramento de segurança? -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Por que operadores TYPO3 precisam de monitoramento de segurança?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Instalações TYPO3 utilizam em média 30 a 50 extensions. Cada uma delas é um ponto de entrada potencial. A equipe de segurança TYPO3 publica avisos regularmente, mas quem lê todos eles? O monitor da Gosign faz exatamente isso. Automaticamente e em tempo real.
</p>
</div>
</section>

<!-- Tabela do monitor -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">O que o monitor verifica</h2>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Área de verificação</th>
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">O que é verificado</th>
<th class="py-3 text-small font-bold text-gosign-dark">Frequência</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Versões de extensions</td>
<td class="py-3 pr-4 text-body text-gosign-text">Versão instalada vs. versão atual</td>
<td class="py-3 text-body text-gosign-text">Diariamente</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Avisos de segurança</td>
<td class="py-3 pr-4 text-body text-gosign-text">Boletins de segurança TYPO3, bancos de dados CVE</td>
<td class="py-3 text-body text-gosign-accent-text font-semibold">Tempo real</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Fim de vida útil</td>
<td class="py-3 pr-4 text-body text-gosign-text">Extensions sem mantenedor ou atualizações</td>
<td class="py-3 text-body text-gosign-text">Semanalmente</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">TYPO3 Core</td>
<td class="py-3 pr-4 text-body text-gosign-text">Versão do Core vs. Stable/LTS atual</td>
<td class="py-3 text-body text-gosign-text">Diariamente</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Versão PHP</td>
<td class="py-3 pr-4 text-body text-gosign-text">Compatibilidade e status de segurança</td>
<td class="py-3 text-body text-gosign-text">Semanalmente</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Serviços -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">Serviços de segurança TYPO3</h2>
<div class="grid md:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Monitoramento de segurança</h3>
<p class="text-body text-gosign-text">
Monitoramento contínuo de todas as extensions e do TYPO3 Core. Notificação imediata em caso de vulnerabilidades críticas.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Auditoria de segurança</h3>
<p class="text-body text-gosign-text">
Verificação profunda pontual: inventário de extensions, status de versão, vulnerabilidades conhecidas, qualidade do código. Análise assistida por IA em horas, não dias.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Resposta a incidentes</h3>
<p class="text-body text-gosign-text">
Site hackeado? A Gosign analisa o vetor de ataque, limpa a instalação e fecha a vulnerabilidade. Suporte emergencial disponível.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Manutenção &amp; patching</h3>
<p class="text-body text-gosign-text">
Atualizações regulares de segurança, upgrades de extensions, gestão de versão PHP. Proativo, não reativo.
</p>
</div>
</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Solicitar verificação de segurança TYPO3 - 30&nbsp;minutos, gratuito.</h3>
<p class="text-body text-gosign-text mb-6">Verificamos sua instalação TYPO3 quanto a vulnerabilidades conhecidas, sem compromisso.</p>
<a
href="/br/contato/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Agendar reunião
</a>
<p class="text-small text-gosign-text-light mt-4">25 anos de experiência · 800+ extensions · Desenvolvimento acelerado por IA</p>
</div>
</section>

<!-- Tabela IA -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Análise de segurança acelerada por IA: 75&nbsp;% mais rápida</h2>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Tarefa</th>
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Tradicional</th>
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Com IA</th>
<th class="py-3 text-small font-bold text-gosign-dark">Economia</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Inventário de extensions + comparação de versões</td>
<td class="py-3 pr-4 text-body text-gosign-text">1 dia</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">30 minutos</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">90&nbsp;%</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Análise de vulnerabilidades (50 extensions)</td>
<td class="py-3 pr-4 text-body text-gosign-text">2 dias</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">4 horas</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">75&nbsp;%</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Auditoria de código de uma extension</td>
<td class="py-3 pr-4 text-body text-gosign-text">1 semana</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">2 dias</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">60&nbsp;%</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Análise de incidente após ataque</td>
<td class="py-3 pr-4 text-body text-gosign-text">2 dias</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">6 horas</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">65&nbsp;%</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Atualização TYPO3 -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Atualização do TYPO3 para a versão atual</h2>
<p class="text-body text-gosign-text leading-relaxed mb-8">
Atualizamos sua instalação TYPO3 para a versão LTS atual com custo competitivo - incluindo todas as extensions, mesmo obsoletas e sem manutenção.
</p>
<div class="grid md:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<div class="flex items-start gap-4">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-1" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75M21 12a9 9 0 1 1-18 0 9 9 0 0 1 18 0Z" /></svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Todas as extensions migradas</h3>
<p class="text-body text-gosign-text">Inclusive obsoletas, sem manutenção ou de desenvolvimento próprio.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-6">
<div class="flex items-start gap-4">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-1" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 18.75a60.07 60.07 0 0 1 15.797 2.101c.727.198 1.453-.342 1.453-1.096V18.75M3.75 4.5v.75A.75.75 0 0 1 3 6h-.75m0 0v-.375c0-.621.504-1.125 1.125-1.125H20.25M2.25 6v9m18-10.5v.75c0 .414.336.75.75.75h.75m-1.5-1.5h.375c.621 0 1.125.504 1.125 1.125v9.75c0 .621-.504 1.125-1.125 1.125h-.375m1.5-1.5H21a.75.75 0 0 0-.75.75v.75m0 0H3.75m0 0h-.375a1.125 1.125 0 0 1-1.125-1.125V15m1.5 1.5v-.75A.75.75 0 0 0 3 15h-.75M15 10.5a3 3 0 1 1-6 0 3 3 0 0 1 6 0Zm3 0h.008v.008H18V10.5Zm-12 0h.008v.008H6V10.5Z" /></svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Preço fixo</h3>
<p class="text-body text-gosign-text">Custos transparentes, sem trabalhos adicionais ocultos.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-6">
<div class="flex items-start gap-4">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-1" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M3.75 13.5l10.5-11.25L12 10.5h8.25L9.75 21.75 12 13.5H3.75Z" /></svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Acelerado por IA</h3>
<p class="text-body text-gosign-text">30 a 50 % mais econômico que o mercado graças à análise de código com IA.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-6">
<div class="flex items-start gap-4">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-1" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M20.25 6.375c0 2.278-3.694 4.125-8.25 4.125S3.75 8.653 3.75 6.375m16.5 0c0-2.278-3.694-4.125-8.25-4.125S3.75 4.097 3.75 6.375m16.5 0v11.25c0 2.278-3.694 4.125-8.25 4.125s-8.25-1.847-8.25-4.125V6.375m16.5 0v3.75m-16.5-3.75v3.75m16.5 0v3.75C20.25 16.153 16.556 18 12 18s-8.25-1.847-8.25-4.125v-3.75m16.5 0c0 2.278-3.694 4.125-8.25 4.125s-8.25-1.847-8.25-4.125" /></svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Zero perda de dados</h3>
<p class="text-body text-gosign-text">Migração completa de dados com proteção de rollback.</p>
</div>
</div>
</div>
</div>
<div class="mt-8 text-center">
<a
href="/br/contato/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Solicitar atualização TYPO3
</a>
</div>
</div>
</section>

<!-- Auditoria LGPD (PT: RGPD) -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Auditoria LGPD do TYPO3 &amp; Conformidade</h2>
<p class="text-body text-gosign-text leading-relaxed mb-8">
Auditamos sua instalação TYPO3 quanto à conformidade com a LGPD e implementamos todas as medidas com custo competitivo.
</p>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse bg-white rounded-card">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Área de auditoria</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">O que é verificado</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Resultado</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Cookie-Consent</td>
<td class="py-3 px-4 text-body text-gosign-text">Banner, opt-in/opt-out, registro de consentimento</td>
<td class="py-3 px-4 text-body text-gosign-text">Fluxo de consentimento em conformidade legal</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Rastreamento e analítica</td>
<td class="py-3 px-4 text-body text-gosign-text">Google Analytics, Matomo, Tag Manager, pixels de terceiros</td>
<td class="py-3 px-4 text-body text-gosign-text">Configuração em conformidade com proteção de dados</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Extensions</td>
<td class="py-3 px-4 text-body text-gosign-text">Compartilhamento de dados com terceiros, requisições externas, integrações CDN</td>
<td class="py-3 px-4 text-body text-gosign-text">Correção ou alternativas em conformidade com a LGPD</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Formulários</td>
<td class="py-3 px-4 text-body text-gosign-text">Registro de tratamento, consentimentos, prazos de retenção</td>
<td class="py-3 px-4 text-body text-gosign-text">Documentação completa</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Hospedagem e SSL</td>
<td class="py-3 px-4 text-body text-gosign-text">Localização do servidor, acordo de processamento, criptografia</td>
<td class="py-3 px-4 text-body text-gosign-text">Hospedagem em conformidade</td>
</tr>
</tbody>
</table>
</div>
<div class="mt-8 text-center">
<a
href="/br/contato/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Solicitar auditoria LGPD
</a>
</div>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
A Gosign é uma agência digital de Hamburgo com 25 anos de experiência em desenvolvimento web, TYPO3 e integração de IA.
Analisamos mais de 800 extensions TYPO3 e hoje desenvolvemos com suporte de IA
até 70&nbsp;% mais rápido do que com métodos tradicionais. A partir do hub europeu em Hamburgo,
atendemos empresas brasileiras e latino-americanas que buscam excelência digital.
</p>
<p class="text-small text-gosign-text-light mt-2">Atualizado em: fevereiro de 2026</p>
</div>
</section>

<!-- Temas relacionados -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Temas relacionados</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/br/typo3-extensions/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">CMS</p>
<p class="text-body font-semibold text-gosign-dark">TYPO3 Extensions</p>
</a>
<a href="/br/site-hackeado-10-motivos/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Segurança</p>
<p class="text-body font-semibold text-gosign-dark">Site hackeado: 10 motivos</p>
</a>
<a href="/br/seguranca-web-padroes/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Segurança</p>
<p class="text-body font-semibold text-gosign-dark">Segurança web conforme padrões CERT.br</p>
</a>
</div>
</div>
</section>

--- Criar site com IA | Whitepaper ---
> Whitepaper: do web design ao tema WordPress funcional com IA. Guia prático da Gosign.

<!-- O que aborda este whitepaper? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">O que aborda este whitepaper?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Este whitepaper da Gosign mostra o fluxo de trabalho completo da criação de um site com suporte de IA: da concepção ao web design até o tema WordPress funcional. Não é uma visão geral teórica, mas um guia prático com ferramentas concretas, prompts e resultados de projetos reais de clientes.
</p>
</div>
</section>

<!-- Visão geral do conteúdo -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">Visão geral do conteúdo</h2>

<div class="space-y-8">
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">1. IA no processo de web design</h3>
<p class="text-body text-gosign-text leading-relaxed">
Geração de layouts, criação de moodboards, wireframe para design com ferramentas de IA. O que funciona, o que não funciona, onde o julgamento humano de design permanece indispensável.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">2. Do design ao código</h3>
<p class="text-body text-gosign-text leading-relaxed">
Implementação assistida por IA de designs Figma/Sketch em HTML/CSS/PHP. Como a Gosign gera estruturas base de temas com IA e desenvolvedores senior refinam o resultado.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">3. Desenvolvimento de tema WordPress com IA</h3>
<p class="text-body text-gosign-text leading-relaxed">
Blocos Gutenberg personalizados, templates Full Site Editing, lógica functions.php - o que a IA gera em minutos e que antes levava dias. Comparação concreta antes e depois.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">4. Garantia de qualidade</h3>
<p class="text-body text-gosign-text leading-relaxed">
A IA gera código, mas quem verifica a qualidade? O processo de QA da Gosign: testes automatizados, verificações de acessibilidade, auditorias de performance, revisão manual de código.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">5. Resultados na prática</h3>
<p class="text-body text-gosign-text leading-relaxed">
Dados de economia de tempo de projetos reais da Gosign: 60 a 80% mais rápido. Onde exatamente o tempo é economizado e onde não.
</p>
</div>
</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Você quer usar IA no seu próximo projeto web?</h3>
<p class="text-body text-gosign-text mb-6">30 minutos de conversa inicial, gratuita e sem compromisso.</p>
<a
href="/br/contato/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Agendar conversa inicial
</a>
<p class="text-small text-gosign-text-light mt-4">25 anos de experiência · 800+ extensions · Desenvolvimento acelerado por IA</p>
</div>
</section>

<!-- Para quem? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Para quem é este whitepaper?</h2>
<ul class="space-y-3">
<li class="flex items-start gap-3">
<span class="flex-shrink-0 mt-1.5 w-2 h-2 bg-gosign-accent rounded-full"></span>
<span class="text-body text-gosign-text">Gerentes de projeto e Product Owners que querem realizar projetos web mais rápidos e mais econômicos</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 mt-1.5 w-2 h-2 bg-gosign-accent rounded-full"></span>
<span class="text-body text-gosign-text">Responsáveis de marketing que avaliam a criação de sites assistida por IA</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 mt-1.5 w-2 h-2 bg-gosign-accent rounded-full"></span>
<span class="text-body text-gosign-text">Desenvolvedores que querem integrar IA ao seu fluxo de trabalho</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 mt-1.5 w-2 h-2 bg-gosign-accent rounded-full"></span>
<span class="text-body text-gosign-text">Diretores executivos que querem entender o ROI de investimentos em IA no desenvolvimento web</span>
</li>
</ul>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
A Gosign é uma agência digital de Hamburgo com 25 anos de experiência em desenvolvimento web, TYPO3 e integração de IA.
Analisamos mais de 800 extensions TYPO3 e hoje desenvolvemos com suporte de IA
até 70% mais rápido do que com métodos tradicionais. A partir do hub europeu em Hamburgo,
atendemos empresas brasileiras e latino-americanas que buscam excelência digital.
</p>
<p class="text-small text-gosign-text-light mt-2">Atualizado em: fevereiro de 2026</p>
</div>
</section>

<!-- Temas relacionados -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Temas relacionados</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/br/agencia-digital-hamburg/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Desenvolvimento web</p>
<p class="text-body font-semibold text-gosign-dark">Agência digital Hamburgo</p>
</a>
<a href="/br/agencia-wordpress/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Desenvolvimento web</p>
<p class="text-body font-semibold text-gosign-dark">Agência WordPress Hamburgo</p>
</a>
<a href="/br/seguranca-web-padroes/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Segurança</p>
<p class="text-body font-semibold text-gosign-dark">Segurança web conforme padrões CERT.br</p>
</a>
</div>
</div>
</section>


============================================================
LANGUAGE: DE
============================================================

--- 203-Readiness-Check: Wo steht Ihre Kanzlei beim KI-Einsatz? - Ergebnis sofort, ohne E-Mail ---
> 10 Fragen, Ergebnis sofort auf der Seite: KI-Reifegrad, einschlägige Berufsrechts-Referenz und empfohlene Bezugsweg-Stufe für Rechtsanwälte, Steuerberater, Wirtschaftsprüfer, Notariate und PKV. Ausführlicher Maßnahmen-Report optional per E-Mail.

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Was der Check prüft - und was Sie bekommen</h2>
<p class="text-body-lg text-gosign-text-light">
Ob eine Kanzlei oder ein Versicherer KI mit Mandats- und Kundendaten einsetzen kann, hängt nicht an einem einzelnen Tool, sondern an der Lage der Organisation: IT-Situation, Microsoft- und Cloud-Vertragslage, Fachsoftware-Kosmos, die faktische Schatten-KI-Nutzung im Haus, die Mandats- und Vertragsstruktur und die eigene Weisungslage. Genau diese Dimensionen fragt der Check in 10 Fragen ab - die erste Frage ist Ihre Berufsgruppe, denn Rechtsgrundlage und Kammer-Linie unterscheiden sich zwischen Anwaltschaft, Steuerberatung, Wirtschaftsprüfung, Notariat und PKV erheblich.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Das Ergebnis erscheint sofort auf dieser Seite und besteht aus vier Bausteinen: <strong class="text-gosign-dark">Ihr KI-Reifegrad</strong> mit einer nüchternen Diagnose, <strong class="text-gosign-dark">Ihre Berufsrechts-Referenz</strong> samt Kammer-Anker und Link auf die passende Detailseite, <strong class="text-gosign-dark">die empfohlene Bezugsweg-Stufe</strong> aus der Gosign-Treppe (dedizierte Kanzlei-Instanz, 203er-Token/API, Setup im eigenen Cloud-Tenant oder Managed Stack) mit einem Begründungssatz aus Ihren Angaben - und <strong class="text-gosign-dark">die nächsten drei Schritte</strong> als Liste, die auch dann trägt, wenn Sie nie mit uns sprechen.
</p>
<p class="text-body text-gosign-text-light mt-4">
Die rechtliche Messlatte dahinter benennen wir transparent: ein berufsrechts- und § 203-konformer Bezugsweg nach der DAV-Linie (SN 32/2025); gerichtlich nicht abschließend geklärt. Die konservativere BRAK-Linie (Möglichkeit der Kenntnisnahme) nennen wir mit - und für Steuerberatung, Wirtschaftsprüfung und Notariat sind nicht die anwaltlichen Verbandslinien maßgeblich, sondern die eigenen Normen und Kammer-Aussagen. Das Ergebnis ordnet das je Berufsgruppe korrekt zu.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Datensparsam by Design: Was diese Seite speichert - und was nicht</h2>
<div class="space-y-6 mt-8">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Ergebnis sofort, ohne E-Mail</p>
<p class="text-body-lg text-gosign-text-light mt-1">Der Check läuft vollständig in Ihrem Browser. Das komplette Ergebnis ist ohne Registrierung sichtbar - vor, während und nach jeder optionalen Report-Anforderung. Es gibt keine Pflicht-Eingabe, an der das Ergebnis hängt.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">PDF-Report optional, mit Doppel-Opt-in</p>
<p class="text-body-lg text-gosign-text-light mt-1">Wer den ausführlichen Maßnahmen-Report möchte, gibt eine E-Mail-Adresse an und bestätigt die Zustellung per Klick in einer Bestätigungs-Mail (Doppel-Opt-in). Übermittelt werden dabei nur zwei abgeleitete Werte - Berufsgruppe und empfohlene Stufe - damit der passende Report zugestellt werden kann. Ein Abo unseres Briefings ist eine separate, nicht vorangekreuzte Option und nie Bedingung.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Keine Einzelantworten gespeichert</p>
<p class="text-body-lg text-gosign-text-light mt-1">Ihre Antworten auf die 10 Fragen werden nicht übertragen und nicht gespeichert - auch nicht bei einer Report-Anforderung. Für die Verbesserung des Checks zählen wir ausschließlich aggregierte, personenfreie Ereignisse (Check gestartet, Check abgeschlossen, je Berufsgruppe und Stufe). Diese Seite setzt kein Cookie und keinen Tracking-Pixel.</p>
</div>
</div>
</div>
</section>

<!-- ============================================================
W5-EINBAU-NOTIZ (Island-Verdrahtung) - für den /build der Welle W5, kein Livetext

1. Mechanik nach ContactPage-Präzedenz (siehe w4-final/selektor-einbau-notiz.md §1):
   Content-Seiten sind reines Markdown ohne Slot - die Island hängt in einer
   .astro-Sektion. Der Wrapper src/pages/de/203-readiness-check.astro lädt
   diesen Content-Entry (getEntry("de", "203-readiness-check")), rendert Hero,
   dann <Content /> und fügt GENAU AN DIESER STELLE (zwischen den beiden
   vorstehenden Intro-Sektionen und der folgenden Ergebnis-Sektion) die
   Island-Sektion ein. Alternativ rendert der Wrapper die Island-Sektion direkt
   nach der zweiten Content-Sektion via eigener Page-Komponente - der
   Präzedenzfall ist src/components/pages/ContactPage.astro.
2. Island-Sektion (Markup-Muster Tool-Page src/pages/de/hr-agent-readiness.astro):
   <section id="readiness-check" class="py-section bg-gosign-white">
     <div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
       <ReadinessCheck203Island client:visible />
     </div>
   </section>
3. Island: src/components/islands/ReadinessCheck203Island.tsx nach
   ReadinessAssessmentIsland-Muster (useState-Stepper, client-side Scoring,
   kein Backend-Call bis zum Report-Gate, kein localStorage). Unter 300 Zeilen:
   Fragen, Scoring, Ergebnistexte liegen in src/data/203-readiness-config.json
   (ein DE-Sprachobjekt; Spezifikation: w5-prep/w5-s1-readiness-check-spec.md
   §2 Fragen-Katalog, §3 Scoring, §4 Berufsgruppen-Mapping, §5 Ergebnis).
4. Report-Gate im Ergebnis (EbookModal-Muster): ein Request an die bestehende
   lp-lead.ts-Route mit source "203-readiness", Payload nur berufsgruppe +
   empfohlene_stufe + optionale Briefing-Checkbox (nie vorangekreuzt) +
   Honeypot/_t/_token + gs_li_fat_id + session_token_hash. DOI-Strecke und
   Report-Zustellung: docs/domain/203-readiness-report-vorlagen.md §1-§2.
5. Der Hero-CTA (cta_primary) springt auf #readiness-check - der Anker MUSS
   an der Island-Sektion hängen.
6. Aggregat-Ereignisse: funnel-event-Beacons check-start und check-completed
   (nur berufsgruppe, stufe, reifegrad-Kategorie; keine Frage-Antwort-Paare).
============================================================ -->

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Wie das Ergebnis aufgebaut ist</h2>
<p class="text-body-lg text-gosign-text-light">
Der Check trennt zwei Dinge, die oft vermischt werden: <strong class="text-gosign-dark">Reifegrad</strong> und <strong class="text-gosign-dark">Bezugsweg</strong>. Der Reifegrad beschreibt, wie geregelt KI in Ihrem Haus heute läuft - von der ungeregelten Nutzung ohne Weisungslage bis zur belastbaren Kette aus Verträgen und Governance. Die Bezugsweg-Empfehlung beschreibt, welche Stufe der Treppe zu Ihrer Organisation passt - sie folgt nicht dem Reifegrad, sondern Ihren Struktur-Angaben: Zielbild, Organisationsgröße, IT-Situation und Cloud-Vertragslage. Eine Kanzlei mit ungeregelter Nutzung und eigener IT bekommt eine andere Empfehlung als eine Solo-Kanzlei mit demselben Reifegrad.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Beides zusammen ergibt die nächsten Schritte: erst die Weisungslage und die Entscheidung für einen definierten Bezugsweg, dann die Vertragskette, dann der Betrieb. Der Ton der Diagnose ist bewusst nüchtern - keine Sanktions-Stapelei, keine Angst-Rhetorik. Was die Kette im Einzelnen verlangt, zeigt das Erklärstück <a href="/de/berufsgeheimnistraeger/203er-kette/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Die 203er-Kette</a>; woran Sie Anbieter-Claims messen, die <a href="/de/berufsgeheimnistraeger/203-pruefliste/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">8-Punkte-Prüfliste</a>.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Nach dem Check: Einordnung und Angebot</h2>
<p class="text-body-lg text-gosign-text-light">
Das Ergebnis verlinkt Ihre berufsgruppen-spezifische Detailseite mit Rechtslage, Kammer-Linien und typischen Aufgaben. Den Überblick über alle Berufsgruppen, Bezugswege und die Rechtslage gibt die Einstiegsseite <a href="/de/berufsgeheimnistraeger/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">KI für Berufsgeheimnisträger (§ 203 StGB)</a>. Was die einzelnen Stufen der Treppe konkret enthalten - Leistungsumfang, Vertragsartefakte, Einstieg - zeigt die <a href="/de/berufsgeheimnistraeger/angebot/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Angebots-Übersicht der Bezugsweg-Treppe</a>.
</p>
<p class="text-body text-gosign-text-light mt-4">
Zur Transparenz gehört auch die Grenze: Dieses Ergebnis ist eine strukturierte Orientierung, keine rechtliche Prüfung Ihres Einzelfalls. Die berufsrechtliche Bewertung obliegt dem Berufsträger und seinen rechtlichen Beratern; die strafrechtliche Einordnung automatisierter KI-Verarbeitung ist gerichtlich nicht abschließend geklärt.
</p>
</div>
</section>

--- Allgemeine Geschäftsbedingungen - Gosign GmbH ---
> AGB der Gosign GmbH für AI-Infrastruktur, Agentenentwicklung und Softwareentwicklung. Version 3.1.

<h1>Allgemeine Geschäftsbedingungen</h1>
<p class="text-lg text-gosign-text-light">
Gosign GmbH - AI-Infrastruktur, Agentenentwicklung & Softwareentwicklung<br/>
Version 3.1 - Stand: März 2026
</p>
<p class="text-sm text-gosign-text-light mt-2">
<a href="/documents/gosign-agb-v3.1.pdf" target="_blank" rel="noopener noreferrer"
class="text-gosign-accent-text hover:text-gosign-accent-hover">↓ Als PDF herunterladen</a>
</p>

<h2>§ 1 Geltungsbereich und Vertragsgegenstand</h2>
<p>Diese Allgemeinen Geschäftsbedingungen (AGB) gelten für alle Verträge zwischen der Gosign GmbH (nachfolgend „Gosign") und ihren Kunden über die folgenden Leistungsbereiche:</p>
<p><strong>AI Enterprise Infrastruktur & Agentenentwicklung:</strong> Leistungen rund um Künstliche Intelligenz im Unternehmensumfeld, einschließlich Planung und Implementierung von KI-Infrastruktur, Entwicklung von KI-Agenten, Integration von KI-Modellen, Self-Hosting-Lösungen, FinOps-Strategien zur Kostenoptimierung von KI-Workloads sowie zugehörige Beratungs- und Entwicklungsleistungen.</p>
<p><strong>Decision Layer & Governance-Architektur:</strong> Entwicklung und Implementierung einer Governance- und Steuerungsschicht (Decision Layer) zwischen KI-Agenten und Unternehmens-Zielsystemen, einschließlich regelbasierter Entscheidungssteuerung, Audit-Trail-Dokumentation, Human-in-the-Loop-Architektur und automatisierter Kontrollnachweise (Cert-Ready).</p>
<p><strong>Softwareentwicklung:</strong> Entwicklung individueller Softwarelösungen, Web-Anwendungen und Integrationen, auch unter Einsatz von Open-Source-Frameworks und -Bibliotheken. Dies umfasst Konzeption, Design, Entwicklung, Anpassung, Integration und Dokumentation.</p>
<p><strong>Hosting und Betriebsleistungen (optional):</strong> Optional von Gosign angebotene Hosting-Services und Betriebsunterstützung. Der Regelbetrieb der von Gosign entwickelten Lösungen erfolgt grundsätzlich in der Infrastruktur des Kunden. Hosting durch Gosign ist eine Zusatzleistung, die separat vereinbart wird.</p>
<p><strong>Enablement und Wissenstransfer:</strong> Gosign verfolgt das Ziel, den Kunden in die Lage zu versetzen, die bereitgestellten Lösungen eigenständig zu betreiben und weiterzuentwickeln. Soweit vereinbart, umfasst der Leistungsumfang Schulungen, Dokumentation und einen strukturierten Wissenstransfer, der darauf ausgerichtet ist, die Abhängigkeit des Kunden von Gosign planmäßig zu reduzieren.</p>
<p><strong>Abgrenzung:</strong> Gosign erbringt technische Dienstleistungen. Die von Gosign entwickelten Lösungen ersetzen keine Rechts-, Steuer- oder HR-Fachberatung. Fachliche Endentscheidungen verbleiben beim Kunden. Systeme des Kunden (z. B. SAP, Workday, SuccessFactors, DATEV) bleiben führendes System (System of Record); Gosign-Lösungen integrieren sich in diese Systeme, ersetzen sie aber nicht.</p>
<p><strong>Kundenkreis:</strong> Diese AGB richten sich ausschließlich an Unternehmer im Sinne von § 14 BGB. Für Kunden mit Sitz in der EU/dem EWR gelten diese AGB unmittelbar. Für Kunden außerhalb der EU/des EWR gelten sie, sofern die Geltung deutschen Rechts vereinbart wurde. Verträge mit Verbrauchern bietet Gosign nicht an.</p>
<p>Individuelle Vereinbarungen und SLA haben Vorrang vor diesen AGB. Abweichende Bedingungen des Kunden finden keine Anwendung, es sei denn, Gosign hat ihrer Geltung ausdrücklich schriftlich zugestimmt.</p>

<h2>§ 2 Definitionen</h2>
<p>Die folgenden Begriffe werden in diesen AGB wie folgt verwendet:</p>
<p><strong>„Agent"</strong> bezeichnet eine Softwarekomponente, die auf Basis von KI-Modellen und Regelwerken Aufgaben im Auftrag des Kunden automatisiert ausführt oder vorbereitet (z. B. Document Agent, Workflow Agent, Knowledge Agent).</p>
<p><strong>„Audit Trail"</strong> bezeichnet die lückenlose, chronologische Aufzeichnung aller Decision Records und Events im System.</p>
<p><strong>„Auditor Portal"</strong> bezeichnet eine webbasierte Oberfläche, über die autorisierte Prüfer (intern oder extern) den Live-Status aller Controls und Evidence einsehen können.</p>
<p><strong>„Cert-Ready"</strong> bezeichnet die Eigenschaft einer Systemarchitektur, die technischen Voraussetzungen für branchenübliche Zertifizierungen (z. B. ISO 27001, SOC 2, IDW PS 951) zu erfüllen - ohne dass damit eine Zertifizierung selbst geschuldet oder zugesichert wird.</p>
<p><strong>„Component Manifest"</strong> bezeichnet die dem Angebot als Anlage beigefügte Übersicht, die jede wesentliche Softwarekomponente entweder als kundenspezifisches Arbeitsergebnis (§ 7.1) oder als Plattform-Komponente (§ 7.2) zuordnet. Näheres regelt § 7.2 Abs. 4.</p>
<p><strong>„Control"</strong> bezeichnet eine technisch implementierte Prüfregel, die sicherstellt, dass ein bestimmter Compliance- oder Governance-Standard eingehalten wird (z. B. „Keine Gehaltsentscheidung ohne Vier-Augen-Prinzip").</p>
<p><strong>„Decision Layer"</strong> bezeichnet die von Gosign entwickelte Governance- und Steuerungsschicht, die Geschäftsprozesse in Einzelentscheidungen zerlegt und für jeden Schritt festlegt, ob ein Mensch entscheidet, ein Regelwerk greift oder die KI autonom handelt.</p>
<p><strong>„Decision Record"</strong> bezeichnet die automatische, unveränderbare Dokumentation einer einzelnen Entscheidung im Decision Layer, bestehend aus Eingabedaten, angewendeter Regel/Modellversion, Konfidenzwert, Entscheidungspfad und Ergebnis.</p>
<p><strong>„Evidence"</strong> bezeichnet einen automatisch generierten Nachweis, dass ein Control zu einem bestimmten Zeitpunkt erfüllt war.</p>
<p><strong>„Human-in-the-Loop"</strong> bezeichnet ein Architekturprinzip, bei dem bestimmte Entscheidungen eine menschliche Freigabe erfordern, bevor sie ausgeführt werden. Die Klassifikation, welche Entscheidungen eine menschliche Freigabe erfordern, wird im Projekt gemeinsam mit dem Kunden festgelegt.</p>
<p><strong>„Maintenance"</strong> bezeichnet den optionalen jährlichen Wartungsvertrag für Plattform-Komponenten, der laufende Wartung, Sicherheitsupdates und Weiterentwicklung umfasst. Näheres regelt § 7.7.</p>
<p><strong>„Perpetual License"</strong> bezeichnet das dauerhafte Nutzungsrecht des Kunden an der jeweils ausgelieferten Version der Plattform-Komponenten gemäß § 7.2 Abs. 2. Das Nutzungsrecht besteht unabhängig davon, ob ein Wartungsvertrag besteht.</p>
<p><strong>„Plattform-Komponenten"</strong> bezeichnet den wiederverwendbaren technischen Kern der Gosign-Lösungen, insbesondere die Decision Engine, das Regel-Engine-Framework, die Audit-Trail-Architektur und Orchestrierungsmodule. Näheres regelt § 7.2 Abs. 1.</p>
<p><strong>„Quellcode-Transfer"</strong> bezeichnet die Übertragung des ausschließlichen Nutzungsrechts an den individuell für den Kunden entwickelten Softwarekomponenten einschließlich Quellcode, Prompts, Rule Sets, Konfigurationen und Dokumentation.</p>
<p><strong>„Software Bill of Materials (SBOM)"</strong> bezeichnet die Übersicht aller in der Lösung verwendeten Open-Source-Komponenten und deren Lizenzen gemäß § 7.4.</p>
<p><strong>„System of Record"</strong> bezeichnet das kundenseitige Führsystem für Stamm- und Bewegungsdaten (z. B. SAP, Workday, SuccessFactors, DATEV). Gosign-Lösungen integrieren sich in das System of Record, ersetzen es aber nicht.</p>
<p><strong>„Zulässige Dritte"</strong> bezeichnet die in § 7.1 Abs. 3 abschließend aufgeführten Empfänger, an die der Kunde Arbeitsergebnisse und Plattform-Komponenten ohne gesonderte Zustimmung von Gosign weitergeben darf.</p>

<h2>§ 3 Vertragsschluss</h2>
<p><strong>Angebot und Bestellung:</strong> Die Präsentation von Leistungen von Gosign stellt grundsätzlich kein verbindliches Vertragsangebot dar. Der Vertragsschluss erfolgt durch Beauftragung des Kunden und Annahme durch Gosign innerhalb von 14 Kalendertagen.</p>
<p>Ein Vertrag kommt erst zustande, wenn Gosign die Bestellung in Textform bestätigt oder mit der Ausführung beginnt.</p>
<p><strong>Rahmenvertrag und Leistungsphasen:</strong> Der Vertrag kann als Rahmenvertrag mit einzeln beauftragten Leistungsphasen geschlossen werden. Jede Phase kann separat beauftragt werden, ohne Verpflichtung zur Beauftragung nachfolgender Phasen.</p>
<p><strong>Vertragstypen pro Phase:</strong> Discovery-Phasen (Analyse, Beratung, Prozessaufnahme) werden als Dienstvertrag erbracht; geschuldet ist die Beratungsleistung, nicht ein bestimmter Erfolg. Build-Phasen (Entwicklung, Implementierung, Proof of Concept) werden als Werkvertrag mit Abnahme erbracht, sofern nicht anders vereinbart. Scale- und Support-Phasen werden als Dienstvertrag erbracht; optionale Service Level Agreements (SLA) gelten ergänzend.</p>
<p>Verträge können schriftlich, elektronisch oder in Textform geschlossen werden. Gosign speichert den Vertragstext und diese AGB.</p>

<h2>§ 4 Leistungen durch Gosign</h2>
<p>Gosign erbringt die vertraglich vereinbarten Leistungen fachgerecht und mit der Sorgfalt eines ordentlichen Kaufmanns. Gosign ist berechtigt, qualifizierte Mitarbeiter, Erfüllungsgehilfen oder Subunternehmer einzusetzen.</p>
<p><strong>Leistungsort:</strong> Die Leistungserbringung erfolgt grundsätzlich remote. Gosign setzt Mitarbeiter an verschiedenen Standorten ein und gewährleistet die Einhaltung der vereinbarten Sicherheits- und Datenschutzstandards unabhängig vom Einsatzort. Vor-Ort-Einsätze werden separat vereinbart.</p>
<p><strong>Projektkoordination:</strong> Beide Parteien benennen Ansprechpartner. Gosign informiert regelmäßig über den Projektfortschritt.</p>
<p><strong>Termine und Fristen:</strong> Fristen und Termine sind nur verbindlich, wenn ausdrücklich so vereinbart. Bei Verzögerungen, die Gosign nicht zu vertreten hat, verlängern sich Fristen angemessen.</p>
<p><strong>Change Requests:</strong> Änderungen des Leistungsumfangs erfordern eine schriftliche Vereinbarung über Mehrkosten und Termine.</p>
<p><strong>Proof of Concept (PoC):</strong> Soweit ein PoC vereinbart wird, gelten die im Angebot definierten Erfolgskriterien. Ein PoC dient der Validierung der technischen Machbarkeit. Die im PoC erstellten Arbeitsergebnisse gehen nach vollständiger Bezahlung in das Eigentum des Kunden über, sofern nicht anders vereinbart.</p>
<p><strong>Teilleistungen:</strong> Gosign ist berechtigt, zumutbare Teilleistungen zu erbringen.</p>
<h3>4.1 Abnahme von Werkleistungen</h3>
<p>Der Kunde prüft Werkleistungen innerhalb von 14 Kalendertagen und erklärt die Abnahme oder rügt Mängel. Ohne Rückmeldung gilt die Leistung als abgenommen, sofern auf diese Folge hingewiesen wurde. Unerhebliche Mängel berechtigen nicht zur Verweigerung der Abnahme.</p>

<h2>§ 5 Mitwirkungspflichten des Kunden</h2>
<p>Der Kunde stellt alle erforderlichen Unterlagen, Informationen, Daten und Zugänge rechtzeitig zur Verfügung.</p>
<p>Der Kunde benennt einen qualifizierten Ansprechpartner mit Entscheidungsbefugnis.</p>
<p><strong>Technische Infrastruktur:</strong> Soweit Leistungen auf Systemen des Kunden erbracht werden, stellt der Kunde die Infrastruktur bereit. Gosign informiert über die Systemvoraussetzungen.</p>
<p><strong>Tests und Abnahmen:</strong> Der Kunde wirkt aktiv mit, dokumentiert Fehler und verzögert Freigaben nicht unangemessen.</p>
<p><strong>Pflege und Datensicherung:</strong> Der Kunde installiert Sicherheitsupdates eigenständig und zeitnah, sofern kein Wartungsvertrag mit Gosign besteht. Regelmäßige Backups obliegen dem Kunden.</p>
<p><strong>Rechtmäßigkeit:</strong> Der Kunde verantwortet die Rechtmäßigkeit aller übergebenen Inhalte und Daten und stellt Gosign von Drittansprüchen frei.</p>
<p>Verzögerungen und Mehraufwand durch Verletzung von Mitwirkungspflichten gehen zu Lasten des Kunden.</p>

<h2>§ 6 Besondere Bestimmungen für KI-Infrastruktur & Agentenentwicklung</h2>
<h3>6.1 Leistungsumfang</h3>
<p>Der Leistungsumfang wird im Angebot festgelegt und kann umfassen: Integration und Anpassung von KI-Modellen, Entwicklung von KI-Agenten, Aufbau des Decision Layers, Beratung zur KI-Infrastruktur, FinOps, Sicherheits- und Compliance-Konzepte, Schulungen.</p>
<p>Das Angebot weist aus, welche Plattform-Komponenten (§ 7.2) eingesetzt werden und enthält ein Component Manifest als Anlage.</p>
<h3>6.2 Dreistufige Architektur und Verantwortlichkeiten</h3>
<p>Die von Gosign entwickelten KI-Lösungen unterscheiden drei Verarbeitungsstufen mit unterschiedlichen Verantwortlichkeiten:</p>
<p>(a) <strong>Analyse (KI-Modell):</strong> Das Sprachmodell analysiert Daten und generiert Vorschläge. KI-Modelle liefern probabilistische Ergebnisse; Gosign schuldet die fachgerechte Integration und Konfiguration des Modells, nicht die inhaltliche Richtigkeit jeder einzelnen Ausgabe.</p>
<p>(b) <strong>Entscheidung (Decision Layer):</strong> Der Decision Layer wendet definierte Regelwerke, Schwellenwerte und Freigabeprozesse auf die Analyse-Ergebnisse an. Gosign schuldet die korrekte Implementierung der vereinbarten Entscheidungslogik. Fehler in der Regelimplementierung sind Softwarefehler und unterliegen der Gewährleistung.</p>
<p>(c) <strong>Ausführung (Integration/Tool):</strong> Die Ergebnisse werden an Zielsysteme des Kunden übermittelt (z. B. SAP, DATEV, Workday). Gosign schuldet die korrekte technische Integration. Fehler im Zielsystem des Kunden liegen in dessen Verantwortung.</p>
<h3>6.3 Human-in-the-Loop</h3>
<p>Bei Entscheidungen, die als hochriskant klassifiziert sind (insbesondere Personalentscheidungen, Gehaltsentscheidungen, Entscheidungen mit Mitbestimmungsrelevanz), ist Human-in-the-Loop Standard, sofern nicht ausdrücklich anders vereinbart. Die Klassifikation, welche Entscheidungen eine menschliche Freigabe erfordern, wird im Projekt gemeinsam festgelegt und im Decision Layer konfiguriert. Der Kunde bleibt Verantwortlicher für fachliche Endentscheidungen.</p>
<h3>6.4 Model-Agnostik</h3>
<p>Gosign setzt KI-Modelle verschiedener Anbieter ein (model-agnostischer Ansatz). Die Auswahl erfolgt in Abstimmung mit dem Kunden. Gosign informiert über geplante Modellwechsel. Sollte ein Anbieter seinen Dienst einstellen, wird Gosign zeitnah ein gleichwertiges Alternativmodell vorschlagen. Für Verfügbarkeit oder Einstellung von Fremddiensten haftet Gosign nicht.</p>
<h3>6.5 Bias Monitoring</h3>
<p>Soweit vereinbart, implementiert Gosign Mechanismen zur Erkennung und Dokumentation systematischer Verzerrungen (Bias Monitoring). Die regelmäßige Überprüfung im laufenden Betrieb obliegt dem Kunden, sofern kein Wartungsvertrag besteht.</p>
<h3>6.6 Verwendung von Daten für KI</h3>
<p>Der Kunde bleibt Eigentümer und Verantwortlicher aller Gosign zur Verfügung gestellten Daten. Gosign verwendet diese ausschließlich zur Auftragserfüllung. Der Kunde stellt sicher, dass er die erforderlichen Rechte besitzt. Soweit externe KI-Modelle oder -APIs eingesetzt werden, erfolgt dies nur unter Bedingungen, die eine Nutzung von Kundendaten zum Training der Modelle ausschließen, sofern der Kunde nicht ausdrücklich etwas anderes freigegeben hat.</p>
<h3>6.7 FinOps und verbrauchsabhängige Kosten</h3>
<p>Verbrauchsabhängige Kosten Dritter (API-Gebühren, GPU-Rechenzeit) trägt der Kunde, sofern nicht anders vereinbart. Gosign informiert vorab über die Kostenstruktur und stellt transparente Verbrauchsberichte bereit.</p>
<h3>6.8 Regulatorische Anforderungen</h3>
<p>Gosign adressiert die Anforderungen der Verordnung (EU) 2024/1689 (EU AI Act) als technische Architekturprinzipien (Readiness). Die rechtliche Compliance-Bewertung für den konkreten Einsatzkontext liegt beim Kunden und dessen Rechtsberatern. Gosign unterstützt den Kunden auf Wunsch bei der Umsetzung regulatorischer Anforderungen, sofern dies beauftragt wird.</p>
<h3>6.9 Indemnität</h3>
<p>Die Nutzung der KI-Systeme obliegt dem Kunden in eigener Verantwortung. Der Kunde stellt Gosign von Ansprüchen Dritter frei, die aus missbräuchlicher oder rechtswidriger Nutzung resultieren.</p>

<h2>§ 7 Nutzungsrechte, geistiges Eigentum und Quellcode-Zugang</h2>
<h3>7.1 Nutzungsrechte an kundenspezifischen Arbeitsergebnissen</h3>
<p>Der Kunde erhält mit vollständiger Bezahlung ein dauerhaftes, örtlich unbeschränktes, nicht-exklusives Nutzungsrecht an den folgenden kundenspezifischen Arbeitsergebnissen:</p>
<p>(a) Kundenspezifische Konfigurationen (Regelwerke, Decision Tables, Policies, Routing-Regeln, kundenspezifische Datenmodelle, Entscheidungstabellen)</p>
<p>(b) Prompts und Prompt-Templates, die für den Kunden entwickelt wurden und im Component Manifest als kundenspezifisch gekennzeichnet sind</p>
<p>(c) Kundenspezifische Integrationen und Adapter gemäß Component Manifest (z. B. kundenspezifische SAP-Anbindungen, API-Konnektoren, UI-Texte)</p>
<p>(d) Technische Dokumentation der kundenspezifischen Lösung</p>
<p>(e) Kundendaten und -konfigurationen in allen Formaten</p>
<p>Die Zuordnung zu § 7.1 oder § 7.2 ergibt sich aus dem Component Manifest gemäß § 7.2 Abs. 4.</p>
<p>Das Nutzungsrecht umfasst das Recht zur Bearbeitung und Weiterentwicklung für den eigenen Geschäftsbetrieb des Kunden.</p>
<p>Eine Weitergabe an Dritte oder Sublizenzierung bedarf der vorherigen schriftlichen Zustimmung von Gosign. <strong>Keiner Zustimmung bedarf die Weitergabe an zulässige Dritte.</strong> Zulässige Dritte sind:</p>
<p>(i) Verbundene Unternehmen des Kunden im Sinne von §§ 15 ff. AktG oder nach vergleichbarem ausländischem Konzernrecht (Konzerngesellschaften, Tochtergesellschaften, Shared-Service-Einheiten)</p>
<p>(ii) IT-Dienstleister und Auftragsverarbeiter des Kunden, die unter Vertraulichkeitsverpflichtung und Zweckbindung handeln</p>
<p>(iii) Wirtschaftsprüfer, interne Revision und Regulierungsbehörden im Rahmen gesetzlicher oder vertraglicher Prüfpflichten</p>
<p>(iv) Rechtsnachfolger des Kunden bei Umstrukturierung, Verschmelzung oder Asset Deal, sofern die Weitergabe im Rahmen einer Übertragung desjenigen Geschäftsbetriebs erfolgt, in dem die Lösung eingesetzt wird, und der Rechtsnachfolger die Pflichten aus § 7 übernimmt; ausgenommen ist die Weitergabe an unmittelbare Wettbewerber von Gosign</p>
<p>Der Kunde stellt sicher, dass zulässige Dritte mindestens gleichwertige Schutz- und Vertraulichkeitspflichten einhalten.</p>
<p>§ 7.1 geht der allgemeinen Abtretungsregelung in § 19 vor, soweit die Weitergabe an zulässige Dritte oder Rechtsnachfolger betroffen ist.</p>
<p>Der Kunde hat spätestens ab Deployment der Lösung in seiner Infrastruktur, andernfalls spätestens mit Abnahme oder vollständiger Bezahlung, vollen Zugang zum Quellcode aller in seiner Umgebung betriebenen Komponenten - einschließlich der Plattform-Komponenten gemäß § 7.2. Zugang bedeutet lesbaren, nicht absichtlich unlesbar gemachten Quellcode in einem im Kundenumfeld geführten Repository oder als Code-Export (mindestens nach jedem produktiven Release sowie auf Anfrage innerhalb von 10 Werktagen) einschließlich Build-Anleitung und Abhängigkeitsverzeichnis (Dependency Lockfiles). Zusätzliche Code-Exporte außerhalb der regelmäßigen Releases erfolgen bis zu zweimal pro Quartal kostenfrei; darüber hinausgehende Exporte werden nach Aufwand vergütet.</p>

<h3>7.2 Gosign-Plattform-Komponenten</h3>
<p>Gosign setzt bei der Entwicklung eigene Plattform-Komponenten ein. Plattform-Komponenten sind der wiederverwendbare technische Kern, insbesondere die Decision Engine, das Regel-Engine-Framework, die Audit-Trail-Architektur und Orchestrierungsmodule (nachfolgend „Plattform-Komponenten"). An diesen Plattform-Komponenten verbleibt das ausschließliche geistige Eigentum und Nutzungsrecht bei Gosign.</p>
<p>Der Kunde erhält ein <strong>dauerhaftes Nutzungsrecht an der jeweils ausgelieferten Version</strong> der Plattform-Komponenten (Perpetual License). Dieses Nutzungsrecht ist nicht-exklusiv und umfasst den Betrieb, die Konfiguration und die Integration in die Systeme des Kunden für den eigenen Geschäftsbetrieb. Das Nutzungsrecht besteht unabhängig davon, ob ein Wartungsvertrag besteht. Die Weitergabe-Regeln aus § 7.1 (einschließlich der zulässigen Dritten und der Flow-down-Pflicht) gelten entsprechend.</p>
<p>Der Kunde hat ab Deployment (bzw. mit Abnahme/Zahlung gemäß § 7.1) vollen Zugang zum Quellcode aller Plattform-Komponenten, die in seiner Infrastruktur betrieben werden. Gosign stellt vollständige technische Dokumentation einschließlich Build-Anleitung bereit. Der Quellcode wird nicht absichtlich unlesbar gemacht (keine Obfuskation, keine absichtliche Erschwerung der Lesbarkeit). Die Verschlüsselung von Quellcode im Ruhezustand und bei der Übertragung zum Schutz der Integrität bleibt hiervon unberührt.</p>
<p>Die Plattform-Komponenten werden im Angebot in einem <strong>Component Manifest</strong> als solche gekennzeichnet. Das Component Manifest <strong>listet mindestens alle wesentlichen Plattform-Komponenten</strong> und ordnet jede Komponente entweder § 7.1 (kundenspezifisch) oder § 7.2 (Plattform) zu. Das Component Manifest ist maßgeblich für die Zuordnung. <strong>Änderungen am Component Manifest bedürfen der Textform und werden als Nachtrag zum Angebot oder im Change Request vereinbart.</strong> Komponenten, die im Manifest nicht aufgeführt sind, gelten als kundenspezifisch im Sinne von § 7.1, sofern sie nicht Open-Source- oder Drittkomponenten sind oder bereits in anderen Kundenprojekten als Plattform-Komponente eingesetzt werden; eine Klarstellung per Nachtrag bleibt möglich.</p>
<p>Der Quellcode der Plattform-Komponenten ist <strong>vertrauliche Information und Geschäftsgeheimnis von Gosign</strong> im Sinne von § 14. Der Kunde darf den Quellcode einsehen, für den Vertragszweck nutzen und an zulässige Dritte gemäß § 7.1 unter Einhaltung der Flow-down-Pflicht weitergeben. Eine darüber hinausgehende Nutzung, Weitergabe oder Verwertung ist unzulässig. Der Kunde schützt den Quellcode der Plattform-Komponenten mindestens mit derselben Sorgfalt wie seine eigenen Geschäftsgeheimnisse.</p>
<p>Der Kunde darf Plattform-Komponenten einschließlich Quellcode und daraus gewonnenem Know-how nicht zur Entwicklung, Vermarktung oder Erbringung eines mit Gosign konkurrierenden Produkts oder Services oder zur Produktisierung für Dritte verwenden.</p>

<h3>7.3 Source Code Escrow</h3>
<p>Auf Wunsch des Kunden hinterlegt Gosign den vollständigen Quellcode aller Plattform-Komponenten einschließlich Build-Anleitung, Dependency Lockfiles und Deployment-Dokumentation bei einem unabhängigen Escrow-Dienstleister. Die Kosten der Hinterlegung trägt der Kunde, soweit nicht im Angebot anders vereinbart.</p>
<p>Gosign räumt dem Kunden bereits bei Vertragsschluss unter aufschiebender Bedingung des jeweiligen Release-Events sämtliche Nutzungsrechte an den Plattform-Komponenten ein, einschließlich des Rechts zur Bearbeitung, Weiterentwicklung und zum Eigenbetrieb. Die aufschiebende Bedingung tritt in folgenden Fällen ein:</p>
<p>(a) Insolvenzantrag von Gosign (Eröffnung oder Abweisung mangels Masse)</p>
<p>(b) <strong>Einstellung des Produktsupports:</strong> Gosign stellt für die eingesetzten Plattform-Komponenten keine Sicherheitsupdates mehr binnen 90 Kalendertagen nach Bekanntwerden einer kritischen Schwachstelle bereit, ohne innerhalb dieses Zeitraums eine gleichwertige Nachfolgelösung anzubieten, oder erklärt offiziell das End-of-Life der Komponente. Kritische Schwachstelle im Sinne dieser Klausel ist eine Sicherheitslücke, die nach international anerkannten Standards (insbesondere CVSS) als hoch oder kritisch eingestuft wird. Nähere Kriterien können in der Escrow-Vereinbarung vereinbart werden. Gleichwertige Nachfolgelösung deckt mindestens die wesentlichen Kernfunktionen der ersetzten Komponente ab und gewährleistet ein vergleichbares Sicherheitsniveau. Nähere Anforderungen können in der Escrow-Vereinbarung vereinbart werden.</p>
<p>(c) Wesentliche Vertragsverletzung durch Gosign, die trotz schriftlicher Fristsetzung von 60 Kalendertagen nicht behoben wird.</p>
<p>Die technischen Details der Hinterlegung, Aktualisierung und Herausgabe regelt eine separate Escrow-Vereinbarung zwischen Gosign, dem Kunden und dem Escrow-Dienstleister. Diese umfasst insbesondere: Hinterlegungsumfang (Repository, Keys, Build-Chain, Dokumentation, Dependencies), Aktualisierungsrhythmus, Release Conditions, Prüfrecht des Kunden und Herausgabemechanik.</p>

<h3>7.4 Open-Source-Komponenten</h3>
<p>Gosign setzt nach Möglichkeit Open-Source-Software ein. Die Rechte des Kunden an Open-Source-Komponenten richten sich nach den jeweiligen Lizenzbedingungen (z. B. MIT, Apache, GPL). Gosign stellt dem Kunden eine Übersicht der verwendeten Open-Source-Komponenten und deren Lizenzen zur Verfügung (Software Bill of Materials). Der Kunde verpflichtet sich, diese Lizenzbedingungen einzuhalten. Soweit individueller Code auf Open-Source-Komponenten aufbaut und dadurch deren Lizenzbedingungen unterfallen kann, wird Gosign den Kunden hierauf hinweisen.</p>
<p>Gosign setzt keine Komponenten unter Copyleft-Lizenzen (insbesondere GPL, AGPL) ein, sofern diese nicht im Angebot ausdrücklich ausgewiesen und vom Kunden zugestimmt sind.</p>

<h3>7.5 Wiederverwendbare Komponenten und Mandantenisolation</h3>
<p>Gosign entwickelt die Plattform-Komponenten kontinuierlich weiter und setzt sie in Projekten für verschiedene Kunden ein. Kundenspezifische Konfigurationen, Geschäftsgeheimnisse und Daten fließen nicht in andere Projekte ein.</p>
<p>Die technische Architektur gewährleistet nach dem Stand der Technik durch Mandantenisolation, dass Kundendaten strikt getrennt bleiben. Dies umfasst insbesondere die Trennung auf Ebene der Daten, Logs, Prompt-Historien, Storage und Tenant-spezifischer Schlüssel. Gosign dokumentiert die Isolationsarchitektur auf Anfrage.</p>

<h3>7.6 Eingeschränktes Nutzungsrecht (Alternative für reine Softwareprojekte)</h3>
<p>Sofern im Angebot weder Plattform-Komponenten eingesetzt noch ein Component Manifest vereinbart werden (insbesondere bei reinen Softwareentwicklungsprojekten ohne Decision-Layer-Einsatz), erhält der Kunde ein dauerhaftes, örtlich unbeschränktes, nicht-exklusives Nutzungsrecht an den individuellen Entwicklungen. Das Nutzungsrecht umfasst das Recht zur Bearbeitung und Weiterentwicklung für den eigenen Geschäftsbetrieb. Die Weitergabe-Regeln gemäß § 7.1 Abs. 3 (einschließlich zulässiger Dritter und Flow-down-Pflicht) gelten entsprechend.</p>

<h3>7.7 Lizenzgebühren und Wartung</h3>
<p>Für kundenspezifische Arbeitsergebnisse (§ 7.1) fallen keine laufenden Lizenzgebühren an.</p>
<p>Für Gosign-Plattform-Komponenten (§ 7.2) gilt: Das Nutzungsrecht an der ausgelieferten Version (Perpetual License) ist <strong>mit der im Angebot vereinbarten Vergütung abgegolten</strong>. Darüber hinausgehende laufende Gebühren fallen nur an, wenn sie im Angebot ausdrücklich ausgewiesen sind.</p>
<p>Für <strong>laufende Wartung, Sicherheitsupdates und Weiterentwicklung</strong> der Plattform-Komponenten kann ein jährlicher Wartungsvertrag (Maintenance) vereinbart werden. Art, Umfang, Reaktionszeiten und Höhe der Wartungsgebühren werden im jeweiligen Angebot transparent ausgewiesen.</p>
<p><strong>Kündigt der Kunde den Wartungsvertrag, bleibt das Nutzungsrecht an der zuletzt ausgelieferten Version vollständig bestehen.</strong> Der Kunde erhält dann keine weiteren Updates, Sicherheitspatches oder technischen Support für die Plattform-Komponenten. Gosign empfiehlt in diesem Fall den Abschluss einer Source-Code-Escrow-Vereinbarung gemäß § 7.3.</p>
<p>Ohne ausdrückliche Vereinbarung im Angebot fallen keine laufenden Gebühren an.</p>

<h3>7.8 Kundenmodifikationen an Plattform-Komponenten</h3>
<p>Der Kunde hat das Recht, Plattform-Komponenten für den eigenen Geschäftsbetrieb zu modifizieren. Gosign stellt nach Möglichkeit dokumentierte Erweiterungspunkte (Extension Points) bereit, die Änderungen ohne Eingriff in den Plattform-Kern ermöglichen.</p>
<p>Nimmt der Kunde Änderungen an Plattform-Komponenten <strong>außerhalb der dokumentierten Extension Points</strong> vor, entfällt die Gewährleistung und der Supportanspruch für die betroffenen Teile, bis (a) die Änderungen rückgängig gemacht werden oder (b) Gosign eine kostenpflichtige Analyse durchführt und die Kompatibilität bestätigt.</p>
<p><strong>Der Kunde wirkt im Rahmen des Zumutbaren daran mit, dass Sicherheitsupdates von Gosign auch bei bestehenden Kundenmodifikationen eingespielt werden können.</strong> Verweigert der Kunde die erforderliche Mitwirkung oder blockieren seine Modifikationen die Einspielung eines Sicherheitsupdates, ist Gosign berechtigt, den Support für die betroffenen Komponenten bis zur Auflösung der Blockade auszusetzen. Eine Blockade liegt vor, wenn das Update mit vertretbarem Aufwand nicht eingespielt werden kann, weil kundenseitige Änderungen außerhalb der Extension Points die Kompatibilität beeinträchtigen.</p>
<p>Die Sicherheitspflichten des Kunden gemäß § 9 bleiben von Modifikationen unberührt.</p>

<h3>7.9 Beiträge des Kunden zu Plattform-Komponenten</h3>
<p>Soweit im Angebot oder in einer gesonderten Vereinbarung vorgesehen, kann der Kunde Fehlerkorrekturen, Verbesserungsvorschläge oder Erweiterungen für Plattform-Komponenten einreichen („Beiträge").</p>
<p>Der Kunde räumt Gosign an solchen Beiträgen ein einfaches, nicht-exklusives, zeitlich und örtlich unbeschränktes Nutzungsrecht ein, soweit die Beiträge Plattform-Komponenten betreffen und keine Geschäftsgeheimnisse oder kundenspezifischen Konfigurationen des Kunden enthalten. Gosign darf diese Beiträge in die Plattform-Komponenten einpflegen und allen Kunden zur Verfügung stellen.</p>
<p>Diese Klausel begründet keine Pflicht des Kunden zur Einreichung von Beiträgen.</p>

<h3>7.10 Übergabezeitpunkt</h3>
<p>Die Übergabe der Arbeitsergebnisse (einschließlich Quellcode-Repository, Dokumentation, Component Manifest, Konfigurationen und Software Bill of Materials) erfolgt spätestens mit Abnahme der letzten Projektphase und vollständiger Bezahlung. Gosign wird die Übergabe aktiv unterstützen und dem Kunden vollständigen Zugang gewähren.</p>

<h2>§ 8 Hosting und Betriebsleistungen</h2>
<p>Der Regelbetrieb der von Gosign entwickelten Lösungen erfolgt in der Infrastruktur des Kunden. Hosting durch Gosign ist eine optionale Zusatzleistung. Sofern der Kunde Hosting in Anspruch nimmt, gelten die folgenden Bedingungen:</p>
<p><strong>Managed Services in Kundeninfrastruktur:</strong> Sofern Gosign die Lösung in der Cloud-Umgebung des Kunden betreibt, gelten die Hosting-Bestimmungen sinngemäß. Die Verantwortung für die Basisinfrastruktur verbleibt beim Kunden. Gosign verantwortet die Applikationsschicht.</p>
<p><strong>Rechenzentrum:</strong> Hosting erfolgt in Deutschland oder der EU, sofern nicht anders vereinbart. Präferenzen des Kunden sind bei Vertragsschluss mitzuteilen.</p>
<p><strong>Verfügbarkeit:</strong> Ohne SLA keine Garantie für minimale Verfügbarkeit. Gosign strebt hohe Verfügbarkeit an.</p>
<p><strong>Wartungsfenster:</strong> Geplante Wartung außerhalb der Geschäftszeiten mit Vorankündigung.</p>
<p><strong>Datensicherung:</strong> Tägliche Sicherung, 7 Tage Rolling Backup, sofern nicht anders vereinbart.</p>
<p><strong>Transition und Exit:</strong> Nach Beendigung von Hosting-Leistungen unterstützt Gosign den Kunden für bis zu 90 Tage bei der Migration (Transition). Die Transition wird nach Aufwand vergütet. Alle Kundendaten sind vollständig in gängigem Format exportierbar.</p>

<h2>§ 9 Sicherheit, Wartung und Updates</h2>
<p><strong>Verpflichtende Sicherheitsupdates:</strong> Gosign darf sicherheitsrelevante Updates auch ohne vorherige Zustimmung des Kunden durchführen, wenn Zuwarten die Sicherheit gefährden würde. Der Kunde wird nachträglich informiert.</p>
<p><strong>Duldungspflicht:</strong> Der Kunde darf Sicherheitsupdates nicht verweigern. Sicherheit und Integrität des Systems haben Vorrang.</p>
<p><strong>Weigerung:</strong> Bei verweigerter Sicherheitsmaßnahme darf Gosign die Leistung aussetzen. Ansprüche des Kunden wegen resultierender Schäden sind ausgeschlossen.</p>
<p><strong>Optionale Updates:</strong> Nicht sicherheitsrelevante Updates nur nach Absprache.</p>
<p><strong>Penetration Testing:</strong> Der Kunde darf nach Vorankündigung (mindestens 14 Kalendertage) Sicherheitsaudits oder Penetration Tests durchführen lassen, sofern Vertraulichkeit gewährleistet ist. Details können im SLA geregelt werden.</p>
<p><strong>Incident Response:</strong> Im Falle eines Sicherheitsvorfalls, der die Verfügbarkeit, Integrität oder Vertraulichkeit der Kundendaten oder -systeme beeinträchtigt, informiert Gosign den Kunden unverzüglich, spätestens innerhalb von 24 Stunden nach Kenntnis, und ergreift Sofortmaßnahmen zur Eindämmung. Die Erstmeldung und Sofortmaßnahmen sind Bestandteil der vertraglichen Leistung. Darüber hinausgehende Leistungen (insbesondere forensische Analyse, Root-Cause-Ermittlung und Erstellung eines detaillierten Incident Reports) werden nach Aufwand vergütet, sofern der Vorfall nicht auf ein Verschulden von Gosign zurückzuführen ist. Soweit Gosign den Vorfall zu vertreten hat, sind sämtliche Maßnahmen zur Analyse und Behebung für den Kunden kostenfrei.</p>

<h2>§ 10 Vergütung und Zahlungsbedingungen</h2>
<p>Preise ergeben sich aus dem Angebot, zuzüglich Umsatzsteuer.</p>
<p>Abrechnung nach Aufwand oder Festpreis gemäß Vereinbarung.</p>
<p>Neben- und Reisekosten nur nach vorheriger Abstimmung.</p>
<p><strong>Zahlungsziel:</strong> 14 Kalendertage, sofern nicht abweichend vereinbart. Abweichende Zahlungsziele können individuell vereinbart werden. Verzugszinsen: 9 Prozentpunkte über Basiszinssatz (§ 288 Abs. 2 BGB).</p>
<p>Abschlagszahlungen bei längeren Projekten gemäß Meilensteinplan.</p>
<p>Aufrechnung nur mit unbestrittenen oder rechtskräftig festgestellten Gegenforderungen.</p>

<h2>§ 11 Haftung</h2>
<p><strong>Unbeschränkt:</strong> Bei Vorsatz, grober Fahrlässigkeit, Verletzung von Leben/Körper/Gesundheit, Garantie, Produkthaftung.</p>
<p><strong>Kardinalpflichten:</strong> Bei einfacher Fahrlässigkeit begrenzt auf vertragstypisch vorhersehbaren Schaden.</p>
<p><strong>Haftungshöchstgrenze:</strong> Die Haftung von Gosign für Schäden aus der Verletzung von Kardinalpflichten ist pro Schadensfall auf die Höhe der im betroffenen Einzelvertrag vereinbarten Nettovergütung begrenzt. Die Gesamthaftung von Gosign aus einem Vertragsverhältnis ist auf das Zweifache der jährlichen Nettovergütung begrenzt. Abweichende Haftungshöchstgrenzen können im Einzelvertrag vereinbart werden.</p>
<p><strong>Mittelbare Schäden, Folgeschäden und entgangener Gewinn:</strong> Ausgeschlossen außer bei Vorsatz, grober Fahrlässigkeit oder Kardinalpflichtverletzung.</p>
<p><strong>Datenverlust:</strong> Haftung nur für Wiederherstellungsaufwand aus ordnungsgemäßen Backups des Kunden.</p>
<p><strong>KI-Ergebnisse:</strong> Keine Haftung für Entscheidungen auf Basis von KI-Ausgaben, sofern Gosign nicht gegen Kardinalpflichten verstoßen hat (siehe § 6.2).</p>
<p><strong>Versicherung:</strong> Gosign unterhält eine marktübliche Betriebs- und Berufshaftpflichtversicherung. Nachweis auf Anfrage.</p>
<p><strong>Verjährung:</strong> Zwei Jahre, nicht gültig bei Vorsatz, grober Fahrlässigkeit oder Personenschäden.</p>

<h2>§ 12 Mängelansprüche (Gewährleistung)</h2>
<p><strong>Gewährleistungsfrist:</strong> 12 Monate ab Abnahme für Sach- und Rechtsmängel.</p>
<p>Mängel unverzüglich in Textform anzeigen. Nacherfüllung durch Nachbesserung oder Ersatzlieferung.</p>
<p>Fehlschlagen nach zwei Versuchen: Minderung oder Rücktritt.</p>
<p>Keine Gewährleistung für unwesentliche Abweichungen oder vom Kunden verursachte Störungen.</p>
<p>Fehler in Open-Source- oder Drittsoftware gelten nicht als Mangel der Gosign-Leistung, sofern korrekt integriert.</p>
<p>Die Gewährleistung für Plattform-Komponenten unterliegt den Einschränkungen gemäß § 7.8 (Kundenmodifikationen).</p>
<p>Bei Dauerschuldverhältnissen: Gesetzliche Regelungen für Dienst-/Mietverhältnisse.</p>

<h2>§ 13 Datenschutz und Auftragsverarbeitung</h2>
<p>Beide Parteien halten DSGVO, BDSG und weitere anwendbare Datenschutzgesetze ein.</p>
<p>Soweit der Kunde Daten verarbeitet, die dem brasilianischen LGPD oder sonstigen internationalen Datenschutzgesetzen unterliegen, unterstützt Gosign bei der Einhaltung.</p>
<p>Gosign handelt als Auftragsverarbeiter (Art. 28 DSGVO). Die Parteien schließen eine AVV ab.</p>
<p>Gosign akzeptiert auch vom Kunden bereitgestellte AVV, sofern diese DSGVO-konform sind.</p>
<p>Gosign trifft geeignete TOM (Art. 32 DSGVO).</p>
<p>Subprozessoren mit genereller Zustimmung, sofern vertraglich auf gleichwertiges Datenschutzniveau verpflichtet.</p>
<p><strong>Data Residency:</strong> Auf Wunsch vertragliche Zusicherung, dass Datenverarbeitung ausschließlich in Deutschland oder einem bestimmten EU-/EWR-Staat erfolgt. Bei KI-API-Aufrufen an Drittländer vorab Information und - sofern möglich - europäische Endpunkte.</p>
<p>Bei Datenschutzverletzungen: Unverzügliche Information und Zusammenarbeit bei Meldepflichten.</p>

<h2>§ 14 Vertraulichkeit</h2>
<p>Beide Parteien behandeln vertrauliche Informationen streng vertraulich.</p>
<p><strong>Ausnahmen:</strong> Öffentlich bekannt, bereits vorbekannt, unabhängig entwickelt, gesetzliche Pflicht.</p>
<p><strong>Weitergabe:</strong> Nur Need-to-know an Mitarbeiter mit Vertraulichkeitsverpflichtung.</p>
<p><strong>Schutzstandard:</strong> Beide Parteien schützen vertrauliche Informationen mindestens wie ihre eigenen Geschäftsgeheimnisse, mindestens jedoch durch angemessene technische und organisatorische Maßnahmen nach dem Stand der Technik.</p>
<p><strong>Dauer:</strong> 5 Jahre nach Vertragsende. Für Informationen, die als Geschäftsgeheimnisse gekennzeichnet sind (insbesondere gemäß § 7.2 Abs. 5), gilt die Vertraulichkeitspflicht über die Vertragslaufzeit hinaus fort.</p>
<p><strong>Rückgabe und Vernichtung:</strong> Auf Verlangen, spätestens bei Vertragsende.</p>
<p><strong>Referenznennung:</strong> Gosign darf den Namen und das Logo des Kunden als Referenz nur nach vorheriger schriftlicher Freigabe des Kunden verwenden.</p>

<h2>§ 15 Vertragslaufzeit und Kündigung</h2>
<p>15.1 Projektverträge enden mit Abnahme der letzten Leistung und vollständiger Bezahlung.</p>
<p>15.2 Dauerschuldverhältnisse: Mindestlaufzeit 12 Monate. Danach Verlängerung um jeweils 12 Monate, kündbar mit 3 Monaten Frist zum Laufzeitende.</p>
<p>15.2a Für Wartungsverträge gemäß § 7.7 (Maintenance) gelten die Regelungen für Dauerschuldverhältnisse gemäß Abs. 2 entsprechend, sofern im Wartungsvertrag keine abweichenden Laufzeiten und Kündigungsfristen vereinbart werden.</p>
<p>15.3 Außerordentliche Kündigung bei: (a) wesentlicher Pflichtverletzung nach 30-Tage-Frist; (b) Insolvenz; (c) dauerhafter Update-Verweigerung (§ 9); (d) rechtswidriger Systemnutzung.</p>
<p>15.4 Folgen der Beendigung: Rückgabe/Löschung aller Kundendaten. Transition gemäß § 8. Erworbene Nutzungsrechte bestehen fort nach vollständiger Bezahlung.</p>

<h2>§ 16 Compliance, Zertifizierungen und Mitbestimmung</h2>
<p><strong>16.1 Cert-Ready:</strong> Gosign richtet seine Lösungen darauf aus, die technischen Voraussetzungen für branchenübliche Zertifizierungen zu erfüllen (Cert-Ready by Design). Konkret bedeutet dies: Controls sind als Datenobjekte erster Klasse im System implementiert, Evidence wird automatisch generiert, der Audit Trail ist lückenlos und exportierbar, und der Zugang über ein Auditor Portal ist vorgesehen. Die Erlangung eines konkreten Zertifikats ist kein geschuldeter Leistungserfolg und bedarf einer gesonderten Vereinbarung zwischen Kunde, Prüfer und Gosign.</p>
<p><strong>16.2 Betriebsrat und Mitbestimmung:</strong> Soweit KI-Lösungen in mitbestimmungspflichtigen Bereichen eingesetzt werden (§ 87 Abs. 1 Nr. 6 BetrVG), unterstützt Gosign bei der Erstellung von Dokumentation und Informationsunterlagen für den Betriebsrat. Die formale Einbindung des Betriebsrats und der Abschluss von Betriebsvereinbarungen liegen in der Verantwortung des Kunden. Die Architektur des Decision Layers ist darauf ausgelegt, Betriebsvereinbarungen als konfigurierbare, technisch durchsetzbare Regeln abzubilden.</p>
<p><strong>16.3 Sanktions-Compliance:</strong> Gosign versichert, keine Geschäftsbeziehungen zu sanktionierten Personen, Unternehmen oder Staaten zu unterhalten.</p>
<p><strong>16.4 Nachhaltigkeit:</strong> Gosign berücksichtigt bei der Infrastrukturauswahl Aspekte der Energieeffizienz. Informationen auf Anfrage.</p>

<h2>§ 17 Exportkontrolle</h2>
<p>Der Kunde hält Export- und Sanktionsvorschriften ein. Gosign weist auf exportkontrollierte Komponenten hin. Die Erfüllung steht unter dem Vorbehalt, dass keine gesetzlichen Hindernisse entgegenstehen.</p>

<h2>§ 18 Höhere Gewalt</h2>
<p>Keine Haftung für Nichterfüllung bei höherer Gewalt (Naturkatastrophen, Krieg, Pandemien, Arbeitskämpfe, staatliche Maßnahmen, großflächige Infrastrukturausfälle). Unverzügliche Information. Fristen verlängern sich entsprechend. Rücktrittsrecht nach 3 Monaten.</p>

<h2>§ 19 Schlussbestimmungen</h2>
<p><strong>Anwendbares Recht:</strong> Deutsches Recht unter Ausschluss des UN-Kaufrechts.</p>
<p><strong>Gerichtsstand:</strong> Hamburg (für Kaufleute und juristische Personen).</p>
<p><strong>Vertragssprache:</strong> Deutsch. Englische Fassungen dienen der internationalen Zusammenarbeit; im Zweifel geht Deutsch vor.</p>
<p><strong>Versionierung:</strong> Diese AGB tragen Versionsnummer und Stand-Datum. Aktuelle Version unter gosign.de/de/agb/.</p>
<p>Änderungen in Textform. AGB-Änderungen mit 6 Wochen Vorlauf; Widerspruchsfrist 4 Wochen.</p>
<p><strong>Abtretung:</strong> Abtretung nur mit schriftlicher Zustimmung. Die Weitergabe an zulässige Dritte und Rechtsnachfolger gemäß § 7.1 Abs. 3 bleibt hiervon unberührt.</p>
<p>Salvatorische Klausel. Vorrang der Individualabrede.</p>

--- AI Agents für Unternehmen in Amsterdam | Gosign ---
> Enterprise AI Agents für Amsterdam und die Niederlande. DSGVO-konform, EU AI Act ready, NL AIC aligned. Auditierbare KI für Europas Tech-Hub.

## Amsterdam ist der einzige Markt, in dem Tech-Skalierung und Bankenaufsicht denselben PLZ teilen

Wenige europäische Städte verbinden Hyperscale-Tech und systemrelevantes Banking so dicht wie Amsterdam. ING, ABN AMRO und Rabobank betreiben hier ihre Konzernzentralen, während Adyen, Booking.com, TomTom und Prosus die Stadt zum zweitgrößten Tech-Kapitalmarkt nach London gemacht haben. Im Speckgürtel sitzen Philips in Eindhoven und ASML in Veldhoven - die Brainport-Region ergänzt den Finanzplatz Amsterdam um industrielle High-Tech-Kompetenz. Heineken, Shell NL und KLM bilden den traditionellen Industriekern, während Startups wie Bunq und Mollie das Fintech-Bild prägen. Wer hier KI einführt, baut für ein Publikum, das sowohl PSD2-Beschwerdepfade als auch ISO/IEC 42001 versteht. Genau diese Mischung macht Amsterdam zu einem der härtesten Akzeptanztests für Enterprise AI in Europa.

## Die drei regulatorischen Hürden für AI im Amsterdamer Markt

Erstens die Autoriteit Persoonsgegevens (AP) - die niederländische Datenschutzbehörde gehört zu den durchsetzungsstärksten in der EU und hat Algorithmus-Audits zum Standard erhoben. Die AP veröffentlicht regelmäßig Leitlinien zum Umgang mit AI-Systemen unter der DSGVO und betreibt seit 2023 eine eigene "Algoritmes"-Aufsichtsabteilung. Wer hier produktiv geht, muss jede automatisierte Entscheidung gegenüber Betroffenen erklärbar machen können.

Zweitens De Nederlandsche Bank (DNB) und die Autoriteit Financiële Markten (AFM). Beide haben mit ihrem gemeinsamen Diskussionspapier "General principles for the use of Artificial Intelligence in the financial sector" (SAFEST-Prinzipien) den Standard für Banken, Versicherer und Pensionsfonds gesetzt. Soundness, Accountability, Fairness, Ethics, Skills und Transparency sind die nicht verhandelbaren Anforderungen - jede AI-Entscheidung muss diesen sechs Kriterien standhalten.

Drittens die nationale Auslegung des EU AI Act in Vorbereitung. Die Niederlande arbeiten an einer eigenen Umsetzungslogik, die Hochrisiko-Kategorien des EU AI Act mit den bestehenden DNB- und AP-Regimen verzahnt. Konkret heißt das: Ein AI-System, das im EU AI Act als "high-risk" gilt, fällt in Amsterdam zusätzlich unter die DNB/AFM-SAFEST-Logik. [EU AI Act Compliance](/de/governance/eu-ai-act/) muss hier doppelt funktionieren.

## Typische Einsatzszenarien in Amsterdam

ING und ABN AMRO setzen Transaction Monitoring ein, um Geldwäsche zu erkennen - die Modelle müssen gegenüber DNB-Prüfern erklärbar bleiben, jede einzelne Alarmierung muss reproduzierbar sein. Adyen prozessiert weltweit Milliarden Zahlungen und braucht Fraud-Detection-Modelle, die in Sekunden entscheiden, aber gegenüber der AFM zu jedem Block-Vorgang einen vollständigen Audit Trail liefern. Booking.com bewegt sich mit Dynamic-Pricing-Algorithmen direkt im Kollisionsfeld zwischen Art. 5 EU AI Act (Verbot manipulativer Praktiken) und der niederländischen Wettbewerbsbehörde ACM. ASML wiederum dokumentiert in Veldhoven Patentportfolios und IP-Auseinandersetzungen, in denen jede AI-gestützte Recherche revisionssicher belegt sein muss.

In allen vier Szenarien geht es nicht um die Frage "Funktioniert das Modell" - sondern um "Können wir das Modell vor einer Behörde verteidigen". Genau dafür gibt es den [Decision Layer](/de/decision-layer/): Eine Architektur, die jede Entscheidung als Trace persistiert, eskalierbare Pfade für Human-in-the-Loop erzwingt und Audit Trails direkt auf SQL-Ebene bereitstellt.

Hinzu kommt der Ondernemingsraad - der niederländische Betriebsrat hat nach dem Wet op de ondernemingsraden (WOR) substanzielle Mitbestimmungsrechte bei der Einführung von KI-Systemen. Wir bauen die Decision-Layer-Architektur so, dass die Konsultationspflichten gegenüber dem OR nicht nachträglich angeflanscht werden müssen, sondern als integrierter Bestandteil der Governance fungieren.

## Wie Gosign aus Hamburg Amsterdam betreut

Hamburg liegt etwas mehr als vier Stunden Bahnfahrt oder eine Flugstunde von Schiphol entfernt. Wir arbeiten Remote-first mit Teams in Amsterdam, Eindhoven und Rotterdam - Standuptaktung in MEZ, asynchrone Reviews via Linear, monatliche Vor-Ort-Workshops in den ersten drei Projektmonaten. Die niederländische Compliance-Kultur ist deutsch-pragmatisch genug, dass die Zusammenarbeit ohne große Übersetzungsverluste funktioniert. Discovery-Workshops finden auf Englisch statt, technische Dokumentation liefern wir in Englisch und Niederländisch (durch native Reviewer geprüft), die internen Steering-Runden mit unseren Hamburger Architekten laufen auf Deutsch.

Wir haben in Amsterdam keine Niederlassung. Das ist ehrlich gesagt: Für die meisten Projekte braucht es sie auch nicht. Was es braucht, ist jemand, der DNB-SAFEST-Prinzipien und EU AI Act gleichzeitig im Kopf hat - und der bei einem AP-Audit innerhalb von 24 Stunden vor Ort sein kann. Beides liefern wir aus Hamburg. Konkret: Architekten und Compliance-Leads im Hamburger Team, Reisebudget für quartalsweise Vor-Ort-Termine, Eskalations-SLA von 24 Stunden bei behördlichen Anfragen.

## Warum Amsterdam als Startpunkt für Enterprise AI funktioniert

Amsterdam zwingt Sie, AI von Anfang an als regulierte Infrastruktur zu denken - nicht als Innovationsexperiment. Wer hier eine Pilotanwendung mit Cert-Ready by Design baut, hat danach einen Referenzfall, der in jedem anderen EU-Markt sofort verteidigbar ist. Die Cluster Amsterdam Smart City, AMS Cluster und das Brainport-Ökosystem in Eindhoven liefern Talent, Forschung und Pilotpartner. Gleichzeitig sind die Distributionswege klar: Wer DNB, AFM und AP zufriedenstellt, hat Compliance-Argumente, die in Frankfurt, Paris oder Madrid funktionieren - meist mit weniger Overhead als die Amsterdamer Variante.

Wir haben für Banken, Payment-Provider und Travel-Tech in Westeuropa Decision Layer mit Governance by Design ausgerollt. In Amsterdam steht die Latte hoch genug, dass jeder AI Agent, der hier produktiv geht, automatisch in den Rest Europas exportierbar ist. Und für deutsche Unternehmen mit niederländischen Tochtergesellschaften ist Amsterdam der Markt, in dem sich die Konzern-AI-Strategie zuerst beweisen muss - bevor sie in München oder Frankfurt skaliert wird.

--- AI Agents für Unternehmen in Barcelona | Gosign ---
> Enterprise AI Agents in Barcelona. Lokale Projektleitung, EU AI Act compliant by design, DSGVO-konform. Vom PoC bis zum eigenständigen Betrieb.

## Barcelona ist Spaniens Tech-Hauptstadt - aber die spanische AI-Aufsicht entscheidet in La Coruña

Wer Enterprise AI in Barcelona baut, arbeitet in einem der dichtesten Innovationskorridore Südeuropas und gleichzeitig in einem Markt, in dem die Regulierungsentscheidungen 1100 Kilometer weiter nördlich fallen. Im Distrikt 22@Barcelona bündeln sich CaixaBank, Cellnex Telecom, Mango, Desigual, Damm und der Pharma-Riese Grifols mit dem Plasma-Geschäft. Im Speckgürtel produziert Seat in Martorell die Cupra-Modellreihe, in den Hafenanlagen läuft die Logistik von Naturgy, und Banco Sabadell betreut Mittelstandskunden in ganz Katalonien. Das Pier01 und der ESADE Creapolis ziehen Talent in die Stadt - Barcelona ist Spaniens Innovationslabor. Aber die regulatorische Realität wird in der AESIA-Zentrale in La Coruña gemacht und in Madrid verschärft.

## Die drei regulatorischen Hürden für AI im katalanischen Markt

Erstens die AESIA (Agencia Española de Supervisión de la Inteligencia Artificial). Spanien ist das erste EU-Land mit einer dedizierten AI-Aufsichtsbehörde, sitzt mit Hauptquartier in La Coruña und hat den Anspruch, Vorbild für die nationale EU-AI-Act-Umsetzung in der gesamten Union zu sein. Die AESIA prüft ab 2026 systematisch Hochrisiko-Systeme und kann Betriebsverbote aussprechen. Wer in Barcelona Modelle in den Markt bringt, muss von Anfang an für ein AESIA-Audit dokumentieren - und zwar nach den im Sandbox-Programm definierten Standards.

Zweitens die AEPD (Agencia Española de Protección de Datos) zusammen mit dem LOPDGDD (Ley Orgánica 3/2018), Spaniens DSGVO-Umsetzungsgesetz mit Verschärfungen. Die AEPD ist EU-weit für die strengste Auslegung von Art. 22 DSGVO bekannt - vollautomatisierte Entscheidungen sind in Spanien praktisch nur mit dokumentierter menschlicher Letztentscheidung zulässig. Für jedes AI-System mit Personenbezug bedeutet das: Decision Layer mit Human-in-the-Loop ist nicht optional, sondern Compliance-Voraussetzung.

Drittens die CNMV (Comisión Nacional del Mercado de Valores) und Banco de España für alle Finanzdienstleister. Die CNMV verlangt seit 2024 bei AI-gestützten Anlageempfehlungen einen vollständigen Audit Trail und prüft die Erklärbarkeit der Modelle. Gleichzeitig setzt der Comité de Empresa nach Art. 64 Estatuto de los Trabajadores Konsultationsrechte durch, wenn AI-Systeme arbeitnehmerbezogene Entscheidungen treffen.

## Typische Einsatzszenarien in Barcelona

CaixaBank betreibt eines der größten Filialnetze Spaniens und braucht für die Kreditprüfung kleiner und mittlerer Unternehmen Modelle, die unter AEPD-Aufsicht reproduzierbar bleiben - jede Ablehnung muss innerhalb von 14 Tagen begründbar sein. Grifols dokumentiert Plasma-Herkunftsketten von Spendern in Hunderten von US- und EU-Zentren - die FDA verlangt lückenlose Audit Trails, die EMA spiegelt diese Anforderung. AI-gestützte Plausibilitätsprüfung ist hier nicht Innovation, sondern Compliance. Cellnex Telecom betreibt zehntausende Funktürme in Europa und nutzt Predictive Maintenance, um Wartungseinsätze zu priorisieren - jede automatisierte Triage-Entscheidung muss gegenüber den Eigentümern (häufig institutionelle Investoren) belegbar bleiben. Seat plant in Martorell die Produktion der Cupra-Modelle und braucht AI für die Kapazitätsplanung über mehrere Werke - die Modelle müssen für VW-Konzern-Audits standhalten.

In jedem dieser Fälle baut der [Decision Layer](/de/decision-layer/) eine Schicht zwischen Modell und Geschäftsprozess, die Audit Trail, Eskalationspfade und Governance by Design erzwingt - genau das, was AESIA, AEPD und CNMV gleichzeitig sehen wollen.

Hinzu kommen sektorspezifische Anforderungen: Pharma-Unternehmen wie Grifols arbeiten unter EMA-Aufsicht und müssen AI-gestützte Qualitätsentscheidungen GMP-konform dokumentieren. Telekomanbieter wie Cellnex stehen unter CNMC-Aufsicht und müssen Marktmacht-Implikationen ihrer Algorithmen offenlegen können. Und im Automotive-Sektor erwartet der VW-Konzern für jedes AI-Werkzeug in Seat-Werken eine Risikobewertung nach den gleichen Standards, die in Wolfsburg oder Ingolstadt gelten.

## Wie Gosign von Barcelona aus Katalonien und Spanien betreut

Gosign hat ein eigenes Büro in Barcelona (gosign.es) mit spanischem und katalanischem Team - native Speakers, lokale Projektleitung, direkter Kontakt zu AESIA, AEPD und CNMV. Das Barcelona-Office ist Regional-Hub für die gesamte iberische Halbinsel: Discovery-Workshops, Sprint Reviews und Steering laufen vor Ort beim Kunden im 22@-Distrikt, im Pier01 oder direkt in den Konzernzentralen von CaixaBank, Cellnex, Mango, Damm und Grifols. Für Banco Sabadell, Seat in Martorell und Naturgy sind Workshops auf Spanisch oder Katalanisch Standard, die Compliance-Dokumentation wird zweisprachig geliefert (ES und CA), und der Comité de Empresa sitzt von Anfang an mit am Tisch. Eskalationen Richtung Hamburg gibt es nur für architektonische Grundsatzfragen oder die Anbindung an deutsche und schweizerische Mutterkonzerne - der Tagesbetrieb, die Kundenkommunikation und die Behördenkontakte laufen im Barcelona-Team. Das katalanische Engineering-Ökosystem ist dicht genug, um Talent direkt vor Ort zu rekrutieren und im Projekt zu verankern.

## Warum Barcelona als Startpunkt für Enterprise AI funktioniert

Spanien steht vor einer doppelten Welle: AESIA-Aufsicht und EU-AI-Act-Umsetzung kommen gleichzeitig in den produktiven Betrieb. Wer in Barcelona einen Cert-Ready-by-Design-Piloten baut, hat einen Referenzfall, der unter AEPD- und AESIA-Standards bestehen wird - und der danach in Madrid, Bilbao, Valencia und Mailand sofort verteidigbar ist. Das Cluster 22@Barcelona, das Pier01 und das BStartup-Programm der Banco Sabadell liefern Talent, Pilot-Partner und Investorenzugang. Gleichzeitig ist die Stadt nahe genug an Madrid und Brüssel, um auf regulatorische Neuerungen schnell zu reagieren - und weit genug entfernt, um eigenen technologischen Charakter zu behalten.

Wir bringen aus dem deutschen Markt die Erfahrung mit, AI-Systeme so zu bauen, dass sie auch unter strengen Aufsichtsregimen produktiv bleiben - mit [EU AI Act Compliance](/de/governance/eu-ai-act/) als Basis und Audit Trail bis auf SQL-Ebene. Barcelona ist der richtige Markt, um diese Disziplin in Südeuropa zu skalieren.

--- AI Agents für Unternehmen in Belo Horizonte | Gosign ---
> Enterprise AI Agents für BH und Minas Gerais. LGPD-konform, CLT-kompatibel. Bergbau, Stahl, Energie. Projektleitung von São Paulo.

## Belo Horizonte ist der Markt, an dem brasilianischer Bergbau seine ESG-Glaubwürdigkeit verteidigt

Minas Gerais produziert die Hälfte des brasilianischen Eisenerzes und einen großen Teil von Stahl, Gold und Aluminium des Landes. In Belo Horizonte und im Umland sitzen oder operieren Vale (mit zentralen Standorten in Nova Lima und Itabira, koordiniert aus BH), Usiminas (Stahl, mit Werken in Ipatinga), AngloGold Ashanti, Magnesita Refratários, Localiza (größte brasilianische Autovermietung mit globalem HQ in BH) und Fiat Chrysler Brasil im Werk Betim. Das ist der industrielle Korridor, über den jeder Welt-Stahl-Preis und jede ESG-Anlegerentscheidung zu brasilianischem Bergbau läuft. Und es ist der Korridor, in dem die Dammbrüche von Mariana (2015) und Brumadinho (2019) jeden „risk-based decision making"-Prozess für die nächsten 20 Jahre verändert haben. Was vor 2019 als „operative Risikomodellierung" durchging, ist heute ein juristisch sensibler Bereich, in dem jede algorithmische Empfehlung potenziell vor Zivilgerichten und der Bundesstaatsanwaltschaft (MPF) verteidigt werden muss.

## Die drei regulatorischen Hürden für AI im Belo-Horizonte-Markt

**ANM-Dokumentationspflichten nach Brumadinho**: Die Agência Nacional de Mineração hat seit 2019 die Anforderungen an Damm-Dokumentation, Stabilitätsnachweise und Risk-Reporting massiv verschärft (Resolução ANM 95/2022 und Folge-Resolutionen). Jede algorithmische Komponente in der Damm-Überwachung, Sensor-Daten-Auswertung oder Risk-Klassifizierung muss vor ANM-Auditoren mit vollständigem Entscheidungspfad nachvollziehbar sein - Audit Trail bis auf Sensor-Ebene.

**IBAMA und SEMAD-Umweltgenehmigungen**: Das brasilianische Umweltministerium IBAMA und die Landesumweltbehörde SEMAD MG verlangen für Bergbau- und Industrie-Operationen detaillierte Umweltverträglichkeitsstudien (EIA/RIMA) und kontinuierliches Monitoring. AI, die Emissionen schätzt, Prozessparameter optimiert oder Sicherheitsvorfälle klassifiziert, fällt damit unter konkrete Umweltauflagen - mit dokumentierter Erklärbarkeit auf Anfrage des Umweltauditors.

**LGPD und Mitbestimmung über Sindicatos**: Die Sindicatos in der Metall- und Bergbauindustrie (Sindiextra, Sticcer) sind in BH historisch stark verankert. AI-Systeme, die Schichtplanung, Sicherheitsalarmierung oder HR-Entscheidungen treffen, müssen mit Sindicato-Vertretern verhandelt werden - LGPD-konform und mit Decision Layer, der Mitbestimmungs-Workflows architektonisch abbildet. Die brasilianische CLT (Consolidação das Leis do Trabalho) und die regionalen Tarifverträge (CCT/ACT) machen Sindicato-Konsultation zur juristischen Voraussetzung für jeden HR-Agent in der Region.

## Typische Einsatzszenarien in Belo Horizonte

**Vale Dam-Safety-Monitoring**: Workflow Agents überwachen Sensor-Daten an Tailings-Dämmen in Itabira, Brucutu und anderen Standorten in Minas Gerais, gleichen sie mit Wetterdaten und Inspektionsberichten ab, und der Decision Layer eskaliert kritische Risikomuster mit Human-in-the-Loop an die Geotechnik-Teams. Jede Entscheidung dokumentiert für ANM, MPF und interne Compliance - das ist der Unterschied zwischen Verteidigungslinie und Strafanzeige.

**Localiza Flottenmanagement**: Document und Workflow Agents verarbeiten Wartungsprotokolle, Schadensmeldungen und Versicherungsdaten der größten Autovermieter-Flotte Lateinamerikas. Der Decision Layer routet Eskalationen an Werkstattpartner und priorisiert kritische Fahrzeuge für Inspektion - mit auditierbarem Lebenslauf pro Fahrzeug. Nach der Fusion mit Unidas ist Localiza zur drittgrößten Autovermietung der Welt aufgestiegen, mit entsprechendem Datenvolumen und entsprechenden Anforderungen an algorithmische Konsistenz über regionale Flotten hinweg.

**Usiminas Produktionsplanung Stahlwerk**: Document Agents lesen Auftragsbücher, Logistik-Daten und Energieverbrauchs-Profile und erstellen Produktionsempfehlungen für die Werke in Ipatinga und Cubatão. Der Decision Layer eskaliert bei Konflikten mit ANM-Sicherheitsauflagen oder ANEEL-Energieverträgen an menschliche Planer. Workflow Agents alarmieren proaktiv bei drohenden Stillständen oder Lieferkettenbrüchen und dokumentieren jede Empfehlung mit Audit Trail.

**Fiat Chrysler Brasil Werk Betim Qualitätskontrolle**: Document Agents verarbeiten Inspektionsprotokolle, Qualitätskennzahlen und Lieferanten-Auditberichte aus dem größten Fiat-Werk außerhalb Italiens. Der Decision Layer eskaliert kritische Qualitätsabweichungen mit Human-in-the-Loop an Werkstattleiter - Audit Trail erfüllt sowohl Stellantis-Konzernstandards als auch INMETRO-Anforderungen für brasilianische Fahrzeugzertifizierung.

## Wie Gosign aus São Paulo ganz Brasilien betreut - inklusive Belo Horizonte

Unser Büro in [São Paulo](/de/ai-agents-sao-paulo/) ist 1 Flugstunde von BH entfernt. Discovery-Workshops mit Vale, Usiminas oder Localiza finden vor Ort in BH oder in den Werks-Standorten statt - in Itabira, Ipatinga, Betim. Compliance-Reviews mit ANM- oder IBAMA-Bezug werden gemeinsam mit Ihrer Rechtsabteilung und externen Umwelt-Anwälten geführt - das ist in Bergbau-Projekten der entscheidende Schritt, weil die regulatorische Auslegung im Detail oft wichtiger ist als die Modell-Architektur. Sindicato-Konsultationen, wenn HR- oder Schichtplanungs-Agents im Einsatz sind, gehen über die lokalen Arbeitsrechts-Anwaltskanzleien in BH und stützen sich auf die in der Region historisch starken Sindiextra-Strukturen. Build-Phasen laufen verteilt zwischen Hamburg und São Paulo - Stand-ups vormittags SP-Zeit, gemeinsame Sprint-Reviews mit Werks-Verantwortlichen vor Ort. Vor-Ort-Termine in BH sind binnen 24 Stunden organisierbar, auch zu abgelegenen Bergbau-Standorten in Itabira oder Brucutu. Nach Go-Live ist das SP-Büro Ihr operativer Ansprechpartner mit Eskalations-Hotline auf Portugiesisch.

## Warum Belo Horizonte als Startpunkt für Enterprise AI funktioniert

BH ist der einzige Markt in Brasilien, in dem industrielle Realität (Bergbau, Stahl, Automobil), regulatorischer Dauerdruck (ANM nach Brumadinho) und Innovation-Cluster (San Pedro Valley, P7 Creative Hub) gleichzeitig bestehen. Wer hier einen produktiven Agent für Damm-Sicherheit, Produktions-Optimierung oder ESG-Reporting baut, baut ihn unter den schärfsten Auditanforderungen der brasilianischen Industrie - das macht ihn anschlussfähig für jeden anderen Bergbau- und Stahl-Markt weltweit, von Chile bis Westaustralien. Die Universidade Federal de Minas Gerais (UFMG) und die Universidade Federal de Ouro Preto (UFOP) stellen dazu Talent in Geotechnik, Metallurgie und Industrie-IT, das in dieser Konzentration sonst nirgendwo in Brasilien verfügbar ist. Gosigns Cert-Ready-by-Design-Architektur stellt sicher, dass ein in BH erprobter Agent in europäischen DSGVO- und EU-AI-Act-Audits genauso besteht - Voraussetzung für ESG-Anleger und für Lieferketten-Anforderungen europäischer Abnehmer (von ArcelorMittal bis Volkswagen). Siehe auch [Rio de Janeiro](/de/ai-agents-rio-de-janeiro/) und [Brasilien gesamt](/de/ai-agents-brasilien/).

--- AI Agents für Unternehmen in Berlin | Gosign ---
> Enterprise AI Agents in Berlin. DSGVO-konform, EU AI Act compliant. Startup bis Bundesministerium - von PoC bis Produktivbetrieb.

## Berlin ist der einzige deutsche Markt, in dem Bundesministerium und Series-B-Startup denselben AI-Anbieter brauchen

Kein anderer Standort im deutschsprachigen Raum bringt diese Spannweite zusammen. Im Regierungsviertel sitzen Bundeskanzleramt, BMI und das BMWK mit ihren IT-Konsolidierungsprojekten und einem Investitionsvolumen, das die Verwaltungsdigitalisierung der nächsten Jahre prägt. Drei U-Bahn-Stationen weiter arbeiten N26, Solaris, Zalando und Delivery Hero an Skalierungsfragen, die nichts mehr mit klassischer Bank-IT zu tun haben. Cariad sitzt mit einem Software-Hub in Berlin und entwickelt die Software-Plattform für die Volkswagen-Konzernfahrzeuge. Deutsche Bahn betreibt vom Potsdamer Platz aus eines der grössten Konzern-Data-Office in Deutschland, SAP hat seine Data Spaces hier verankert, IBM und Microsoft betreiben Standorte mit Forschungs- und Vertriebsfunktion. Diese Mischung erzwingt eine Architektur, die sowohl ein Verwaltungsverfahren mit Aktenführungspflicht als auch ein KYC-Modell bei N26 sauber abbildet - mit demselben Decision Layer und denselben Audit-Trail-Anforderungen, aber mit jurisdiktions- und prozess-spezifischen Regelsätzen darüber.

## Drei regulatorische Hürden, die in Berlin jeden AI-Case definieren

Die erste Hürde ist die BaFin-Aufsicht über Berliner FinTechs. N26 und Solaris sind als CRR-Institute lizenziert, BaFin-Rundschreiben zu MaRisk und BAIT gelten in voller Strenge, und beide Häuser haben in den vergangenen Jahren mehrere Sonderprüfungen mit Auflagen durchlaufen, die das Marktverständnis für regulatorische Erwartungen geprägt haben. Wer hier ein AML-Modell oder eine Betrugserkennung mit AI bauen will, braucht eine Modellgovernance, die die BaFin-Sonderprüfer als prüfbare Evidenzkette akzeptieren - inklusive Versionierung, Schwellwertbegründung und reproduzierbarer Entscheidung. Die zweite Hürde ist die öffentliche Verwaltung: Das BSI gibt mit dem IT-Grundschutz und seinen KI-Mindeststandards den Rahmen vor, das BMI definiert über die Online-Zugangsgesetz-Folgeprojekte, wie automatisierte Entscheidungen in Verwaltungsverfahren protokolliert werden müssen. Beide Aufsichten verlangen einen Audit Trail, der sich an die Aktenführungspflicht anschliessen lässt. Die dritte Hürde ist der EU AI Act selbst, der seit 2026 in der Hochrisiko-Klassifikation greift - Personalentscheidungen, Kreditscoring und Verwaltungsentscheidungen fallen in Berlin gleichzeitig in mindestens drei Anwendungsbereiche. Mehr Hintergrund unter [Governance EU AI Act](/de/governance/eu-ai-act/).

## Typische Einsatzszenarien in Berlin

Im Public Sector geht es um die strukturierte Verarbeitung eingehender Anträge - Förderbescheide, Aktenwiederlagen, Bürgeranfragen - mit klarer Zuordnung an Sachbearbeiter und vollständiger Aktennotiz pro AI-Schritt. Wir sehen Pilotprojekte, in denen Document-Agenten eingehende Verwaltungsdokumente klassifizieren, Pflichtfelder extrahieren und mit Hinweis auf Vollständigkeit oder fehlende Anlagen an die zuständige Sachbearbeitung übergeben. Bei N26 und vergleichbaren Lizenzbanken sehen wir AML-Triage-Agenten, die Hits aus dem Transaktionsmonitoring mit Kundenhistorie, KYC-Daten und externen Quellen anreichern, eine begründete Plausibilitätsbewertung vornehmen und eine Vorbereitung für die Suspicious Activity Report an den Compliance-Officer übergeben - der Officer entscheidet, der Agent dokumentiert lückenlos. Deutsche Bahn arbeitet an Predictive-Maintenance-Konzepten für Triebzüge und Streckeninfrastruktur, bei denen die Wartungsentscheidung am Ende ein zertifizierter Instandhalter trifft, der Agent aber die Sensorhistorie und Vergleichsdaten ähnlicher Komponenten als strukturierten Vorschlag liefert. Cariad und ähnliche OEM-Software-Häuser brauchen Code-Review-Agenten, die ASPICE- und ISO-26262-Anforderungen kennen und kritische Codeänderungen für eine Architektur-Review markieren. Bei Zalando und Delivery Hero sehen wir Customer-Service- und Logistik-Agenten, die wiederkehrende Vorgänge strukturieren und Eskalationen priorisieren. Was alle Szenarien teilen: keine vollautomatische Entscheidung, sondern ein [Decision Layer](/de/decision-layer/) mit erzwungenem Human-in-the-Loop an den richtigen Stellen.

## Wie Gosign aus Hamburg Berlin betreut

Wir betreiben in Berlin ein eigenes Office in der Nogatstrasse 46 in Neukölln - kein Briefkasten, sondern Standort für Projektleitung, Discovery-Workshops und für die Begleitung von Public-Sector-Mandanten. Der Hauptsitz bleibt Hamburg, von dort kommen Engineering und Governance-Architektur, in Berlin sitzt die operative Begleitung für Hauptstadt-Projekte. Konkret heisst das: Eine Discovery startet mit einem zwei- bis dreitägigen Workshop bei Ihnen in Berlin oder im Berliner Office, in der Bauphase arbeiten wir remote mit zwei festen Wochenslots vor Ort, die Inbetriebnahme machen wir wieder vor Ort. Modellvalidierungsworkshops mit BaFin-Sonderprüfern oder mit der internen Revision von Lizenzbanken finden grundsätzlich vor Ort statt, weil hier die Vertrauensbeziehung zur Aufsicht entsteht. Vor-Ort-Termine zwischen Tiergarten, Mitte und Adlershof sind auf Tagesfrist machbar - die Anbindung Hamburg-Berlin über den Hauptbahnhof ist mit dem ICE in unter zwei Stunden möglich, was die Engineering-Schicht aus Hamburg flexibel verfügbar macht. Communities und Cluster wie die Silicon Allee, Factory Berlin und CUBE nutzen wir aktiv, um auch ausserhalb von Kundenterminen technisch sichtbar zu sein und Auditor-Kontakte aufzubauen, die später in Konformitätsbewertungen helfen.

## Warum Berlin als Startpunkt für Enterprise AI funktioniert

Die Hauptstadt ist der einzige Ort in Deutschland, an dem Sie politische Rahmenbedingungen, regulatorische Praxis und unternehmerische Geschwindigkeit in einem Tagesprogramm kombinieren können. Wer in Berlin einen ersten Agent produktiv stellt, hat ihn typischerweise gegen drei Stakeholder-Gruppen gleichzeitig verteidigt: Konzernrevision, Datenschutz und Betriebsrat. Diese dreifache Härtung ist gleichzeitig die beste Vorbereitung auf eine Skalierung in andere Regionen. Hinzu kommen die Daten- und Compute-Verfügbarkeit über den BerlinIX und Telehouse-Standorte mit Direktanbindungen an die grossen Hyperscaler-Regionen, ein wachsendes ML-Engineering-Talent-Pool durch TU, HPI und die Berlin School of Business and Innovation, sowie ein dichtes Netz aus AI-Communities und Meetups, das Best-Practice-Austausch normal macht. Die räumliche Nähe von politischen Entscheidern, Aufsichtspraktikern und Tech-Gründern in einem Stadtgebiet verkürzt die Wege für Stakeholder-Alignment auf eine Weise, die in keinem anderen deutschen Markt existiert. Wer hier in 4-6 Wochen einen Decision Layer mit Audit Trail produktiv hat, erfüllt Cert-Ready by Design für genau die Stakeholder, die in Konzernen sonst die längste Sperrwirkung haben. Mehr zum Vorgehen unter [AI Agents Leistungen](/de/leistungen/ai-agents/).

--- AI Agents für Unternehmen in Bilbao | Gosign ---
> Enterprise AI Agents für Bilbao und das Baskenland. Industrie, Energie, Banken. EU AI Act compliant. Projektleitung von Barcelona.

## Bilbao ist die einzige spanische Stadt, in der Schwerindustrie und Energie-Infrastruktur Compliance gleichzeitig fordern

Das Baskenland ist die industrielle Antithese zum touristisch geprägten Süden Spaniens. In Bilbao und der Bizkaia-Region sitzen Iberdrola - der globale Energie-Gigant mit Konzernzentrale am Torre Iberdrola - sowie Petronor (die Repsol-Raffinerie in Muskiz), CAF (Construcciones y Auxiliar de Ferrocarriles) als Eisenbahn-Hersteller, Tubacex und Sidenor in der Stahlverarbeitung sowie der Kutxabank-Konzern. BBVA hat einen historischen Standort in Bilbao und betreibt hier weiterhin signifikante Operationsfunktionen, Euskaltel ist die regionale Telekomgrundlage. Wer in Bilbao AI baut, baut nicht für Service-Branchen, sondern für Stromnetze, Hochöfen, Zugflotten und Plattformen, deren Stillstand in Millionen pro Stunde gerechnet wird.

## Die drei regulatorischen Hürden für AI im baskischen Markt

Erstens das doppelte Datenschutzregime. Spanien ist EU-weit das einzige Land mit einer regionalen Datenschutzbehörde neben der nationalen: Die AVPD (Agencia Vasca de Protección de Datos) ist im Baskenland zuständig für öffentliche Stellen und teils für regional verankerte Unternehmen, während die AEPD (Agencia Española de Protección de Datos) den Rest abdeckt. Beide Behörden setzen das LOPDGDD (Ley Orgánica 3/2018) um und prüfen automatisierte Entscheidungen besonders streng. Wer im Baskenland mit Personendaten arbeitet, muss in der Compliance-Architektur beide Adressaten mitdenken.

Zweitens die CNMV und Banco de España für die Finanzlogik in BBVA und Kutxabank. Beide Banken setzen seit Jahren auf AI-gestützte Risk-Modelle, doch die CNMV verlangt seit 2024 vollständige Erklärbarkeit der Modelle, die in Anlageempfehlungen einfließen. Audit Trail, Reproduzierbarkeit und Eskalationspfade bei Risikoentscheidungen sind nicht mehr verhandelbar.

Drittens der EU AI Act in Verbindung mit den industriellen Sicherheitsregimen. Iberdrola betreibt Höchstspannungs-Infrastruktur, CAF baut Schienenfahrzeuge - in beiden Domänen greift der EU AI Act mit Hochrisiko-Kategorien (Energieinfrastruktur, kritische Verkehrsmittel) zusammen mit branchenspezifischen Sicherheitsstandards (UNE-EN, IEC 61508). [EU AI Act Compliance](/de/governance/eu-ai-act/) bedeutet hier nicht "Datenschutz prüfen", sondern "AI-Modell als sicherheitskritisches Bauteil zertifizieren".

## Typische Einsatzszenarien in Bilbao

Iberdrola optimiert Smart-Grid-Operationen über Märkte hinweg - die Modelle bestimmen, wann welcher Erzeuger welche Lasten übernimmt. Jede Entscheidung wird gegenüber dem regionalen Netzbetreiber dokumentiert, Audit Trails sind Voraussetzung für die Marktteilnahme. BBVA entwickelt Risk-Scoring-Modelle für Kreditentscheidungen im baskischen Mittelstand, die nach Art. 22 DSGVO gegenüber Kunden begründbar sein müssen. CAF wartet Zugflotten in mehreren europäischen Ländern und nutzt Telematik-Daten für Predictive Maintenance - die Empfehlungen müssen für Aufsichtsbehörden in jedem Betreiberland nachvollziehbar sein. Tubacex setzt in der Edelstahlproduktion auf AI-gestützte Qualitätskontrolle, in der jede automatische Ausschuss-Entscheidung gegenüber Großkunden wie Aramco oder Equinor belegbar bleiben muss.

In allen vier Szenarien geht es um industrielle AI mit Wirkung auf physische Vermögenswerte. Der [Decision Layer](/de/decision-layer/) bringt hier die Architektur, die Entscheidungen mit Audit Trail, Human-in-the-Loop-Eskalation und Cert-Ready by Design ausstattet.

Eine baskische Besonderheit: Die kooperative Tradition rund um Mondragon prägt auch die nicht-kooperativen Unternehmen der Region. Arbeitnehmerbeteiligung an technologischen Entscheidungen ist hier nicht eine Frage der Compliance, sondern Teil der Geschäftskultur. Wir bauen den Decision Layer so, dass die Mitbestimmungspflichten des Comité de Empresa und die kooperativen Governance-Strukturen architektonisch erfüllt werden - nicht als nachträgliche Konsultation, sondern als integrierter Workflow im System selbst.

## Wie Gosign aus Barcelona Bilbao betreut

Gosign betreut baskische Projekte aus dem Barcelona-Büro (gosign.es) mit spanischsprachigen Projektleitern und Engineers. Die Direktflugverbindung Barcelona-Bilbao dauert rund eine Stunde - Vor-Ort-Termine im Torre Iberdrola, am BBVA-Standort, bei CAF in Beasain, bei Tubacex und im BEAZ-Cluster sind innerhalb eines Arbeitstags machbar. Das spanische Team unterstützt die baskische Industrie unter den Besonderheiten der Region: das doppelte Datenschutzregime aus AVPD (Agencia Vasca de Protección de Datos) und AEPD, die kooperative Mondragon-Tradition mit ihren Mitbestimmungsstrukturen und die Mehrsprachigkeit zwischen Spanisch und Euskara, die in technischen Diskussionen nebeneinander existiert. Bei Bedarf binden wir baskisch-sprachige Stakeholder direkt in Workshops ein. Die Hamburger Zentrale übernimmt EU-weite Compliance-Themen und architektonische Grundsatzfragen sowie die Anbindung an deutsche Industrie-Compliance-Standards - die operative Delivery, die Ingenieurssprache der baskischen Schwerindustrie und die kürzeren Entscheidungswege im Baskenland liegen beim Barcelona-Team.

## Warum Bilbao als Startpunkt für Enterprise AI funktioniert

Wer in Bilbao einen industriellen AI-Piloten produktiv bringt, hat einen Referenzfall, der unter doppelter Datenschutzaufsicht (AEPD + AVPD), unter CNMV-Standards und unter EU-AI-Act-Hochrisiko-Logik bestanden hat - die Latte ist nirgendwo in Spanien höher. Das BEAZ-Cluster, die Bizkaia Startup Bay und der Mondragon Innovation Hub liefern Ökosystem, Talent und Pilotpartner. Gleichzeitig haben baskische Unternehmen den Vorteil, langfristig zu denken: AI-Projekte werden hier nicht als Quartals-Pilotenj geplant, sondern als Investition über mehrere Jahre.

Wir bringen die Erfahrung mit, AI-Systeme so zu bauen, dass sie nicht nur funktionieren, sondern auch unter Auditbedingungen verteidigbar bleiben - mit Governance by Design, Audit Trail und der Disziplin, die industrielle Compliance fordert. Bilbao ist der richtige Markt, um diese Disziplin in Nordspanien zu skalieren.

Und es gibt einen geografischen Vorteil: Vom Baskenland aus erreichen Sie sowohl die südfranzösische Industrie (Aerospace in Toulouse, Pharma in Lyon) als auch den portugiesischen Norden (Tech und Industrie um Porto). Wer in Bilbao eine AI-Architektur baut, die unter spanischen Bedingungen produktiv geht, hat einen Referenzfall für den gesamten westeuropäischen Atlantikbogen.

--- AI Agents für Unternehmen in Brasilia | Gosign ---
> Enterprise AI Agents für Brasilia. LGPD-konform, öffentlicher Sektor kompatibel. ANPD in derselben Stadt. Auditierbare Agents für Regierung und Finance.

## Brasília ist der Markt, an dem brasilianische KI-Regulierung tatsächlich entschieden wird

Brasília hat keine Konzernzentralen wie São Paulo und keine Industrie-Cluster wie Belo Horizonte - aber es hat etwas, das diese Städte nicht haben: alle nationalen Regulierer auf einem Plateau. Die ANPD (Autoridade Nacional de Proteção de Dados) hat ihren Sitz im Setor Comercial Sul. Das BACEN (Banco Central do Brasil) operiert vom Setor Bancário Sul. CADE, ANATEL, ANVISA und ANM sitzen alle innerhalb von 5 km Distanz. Dazu die Bundesbanken Caixa Econômica Federal und Banco do Brasil mit ihren Zentralen am Setor Bancário, das Ministério da Fazenda, der STF und der STJ. Wer in Brasília AI für eine Bundesbehörde, eine Bundesbank oder einen regulierten Konzern baut, baut sie in Sichtweite des Regulierers selbst. Das macht Brasília zum strategisch wichtigsten Markt für jeden, der ernsthaft Public-Sector-AI oder regulierte Banken-AI in Brasilien betreiben will - hier wird nicht nur reguliert, hier wird auch eingekauft.

## Die drei regulatorischen Hürden für AI im Brasília-Markt

**ANPD ist hier nicht abstrakt** - sie ist die Behörde, in deren Stadt Sie operieren. Die LGPD-Aufsicht für Bundesbanken, Bundesbehörden und Regierungsdaten findet aus Brasília heraus statt. Wer hier eine AI baut, die Cidadão-Daten verarbeitet (Sozialleistungen, Steuern, Gesundheit), muss LGPD-Artikel 23 (öffentlicher Sektor) und die ANPD-Resolution CD/ANPD 02/2022 zu DPIAs einhalten - auditierbar, dokumentiert, jederzeit prüfbar.

**TCU-Auditierbarkeit für Bundesausgaben**: Der Tribunal de Contas da União prüft alle Bundesausgaben auf Wirtschaftlichkeit und Rechtmäßigkeit. Algorithmische Komponenten in Caixa-Krediten, Banco-do-Brasil-Risk-Scoring oder Correios-Routenplanung müssen vor TCU-Auditoren mit vollständigem Entscheidungspfad erklärbar sein. Audit Trail ist hier nicht „best practice" - er ist die Voraussetzung, dass die Behörde überhaupt mit dem Vendor weiterarbeiten darf.

**PL 2338/2023 wird hier verhandelt**: Der brasilianische KI-Gesetzentwurf ist in der Câmara dos Deputados und im Senado Federal in Diskussion - beide in Brasília. Wer hier baut, baut in einer Stadt, in der Regulierungsentwürfe zwischen den Sitzungswochen geändert werden. Cert-Ready by Design ist die einzige Strategie, die diese Volatilität übersteht: Architektur so anlegen, dass High-Risk-Klassifizierung, menschliche Aufsicht und Erklärbarkeitspflichten nachträglich aktivierbar sind.

## Typische Einsatzszenarien in Brasília

**Caixa Econômica Federal Kreditentscheidung**: Document Agents prüfen Kreditanträge im sozialen Wohnungsbau (Programa Minha Casa Minha Vida), gleichen sie mit CadÚnico-Daten und externen Bonitätsdaten ab, und der Decision Layer routet Entscheidungen mit Human-in-the-Loop an Sachbearbeiter - jede Bewilligung mit auditierbarer Begründungs-Akte für TCU-Prüfungen.

**ANPD-Policy-Analyse für Government Advisory**: Document Agents verarbeiten ANPD-Resolutionen, LGPD-Auslegungen und Konsultations-Dokumente und erstellen für Compliance-Teams in Bundesbehörden tagesaktuelle Lageberichte zur regulatorischen Entwicklung. Workflow Agents alarmieren bei neuen Entwürfen zu PL 2338/2023.

**Banco do Brasil Betrugserkennung**: Document und Workflow Agents überwachen Transaktionsmuster in Echtzeit, eskalieren auffällige Vorgänge an Compliance-Officer und dokumentieren jede Detection mit vollständigem Audit Trail - inklusive Confidence-Scores und Modell-Versionierung für Coaf-Meldungen und BACEN-Audits. Bei Bundesbanken ist die regulatorische Berichterstattung dichter als bei Privatbanken, weil zusätzlich CGU (Controladoria-Geral da União) und TCU eigene Anfragen stellen können.

**Correios Lieferrouten-Optimierung**: Document und Workflow Agents verarbeiten Sendungsvolumen, Postleitzahlen-Cluster und Zustellkapazitäten und schlagen optimierte Routen für die größte Postlogistik Brasiliens vor. Der Decision Layer hält dabei die Anforderungen der ANATEL für Zustellfristen und die CLT-Vorgaben für Arbeitszeiten der Zusteller architektonisch ein - jede Empfehlung mit auditierbarer Begründungs-Akte für den TCU.

## Wie Gosign aus São Paulo ganz Brasilien betreut - inklusive Brasília

Unser Büro in [São Paulo](/de/ai-agents-sao-paulo/) ist 1,5 Flugstunden von Brasília entfernt. Discovery-Workshops mit Caixa, Banco do Brasil oder einer Bundesbehörde finden vor Ort in den Setores Bancário und Comercial statt. Compliance-Reviews mit ANPD- oder TCU-Bezug werden gemeinsam mit Ihrer Rechtsabteilung in Brasília geführt - die Nähe zum Regulierer ist hier ein operativer Vorteil, weil Klärungs-Termine mit ANPD-Mitarbeitern für regulierte Akteure schneller zustande kommen als für reine Remote-Anbieter. Technische Build-Phasen laufen verteilt: Hamburg und São Paulo. Stand-ups morgens SP-Zeit, Sprint-Reviews mit Ihrem Team in Brasília. Vor-Ort-Termine sind binnen 24 Stunden organisiert. Bei Government-Projekten arbeiten wir mit lokalen Anwaltskanzleien für den öffentlich-rechtlichen Rahmen zusammen - Vergaberecht, Beschaffungsrahmen und LGPD-Spezifika für den öffentlichen Sektor sind ein eigenes Fachgebiet, das wir nicht intern abdecken, sondern partnerschaftlich begleiten.

## Warum Brasília als Startpunkt für Enterprise AI funktioniert

Brasília ist der einzige Markt in Brasilien, in dem Regulierer und regulierte Bundes-Institutionen in derselben Stadt sitzen. Wer hier einen produktiven Agent für Caixa-Kreditprüfung, BACEN-Reporting oder Government Advisory baut, baut ihn in einem Kontext, in dem regulatorisches Feedback nicht „in 6 Monaten beim Audit" kommt, sondern in der nächsten Sitzungswoche. Die Cluster - Sebrae HQ, BioTIC Park, Universidade de Brasília - liefern dazu Talent und Forschungspartner. Brasília als Public-Sector-Markt funktioniert für deutsche Anbieter besonders dann, wenn die Architektur europäische DSGVO-Audit-Tiefe mit brasilianischer LGPD- und PL-2338-Bereitschaft verbindet - Governance by Design statt nachträgliche Compliance-Patches. Wer einen Agent für eine Bundesbehörde oder eine Bundesbank baut, baut ihn faktisch unter einem öffentlich-rechtlichen Vergaberahmen - und genau hier macht der Unterschied zwischen einem nachträglich auditierbar gemachten Modell und einer Cert-Ready-by-Design-Architektur den Unterschied zwischen Vertragsverlängerung und Vertragsbeendigung. Mehr im [Brasilien-Überblick](/de/ai-agents-brasilien/) oder im [São-Paulo-Profil](/de/ai-agents-sao-paulo/) für die operative Anbindung.

--- AI Agents für Unternehmen in Brasilien | Gosign ---
> Enterprise AI Agents für Brasilien. LGPD-konform, CLT-kompatibel, PL 2338/2023 ready. Büro in São Paulo, Projekte in ganz Brasilien.

## Brasilien ist der einzige LATAM-Markt, in dem Gosign mit echter lokaler Präsenz arbeitet

Brasilien ist nicht „ein lateinamerikanischer Markt unter vielen". Mit über 215 Millionen Einwohnern, der neuntgrößten Volkswirtschaft der Welt und einem regulatorischen Rahmen (LGPD, BACEN Resolução 4893, PL 2338/2023), der eigenständig neben EU-Recht steht, ist Brasilien ein eigener Compliance-Universum-Block. Gosign betreibt deshalb ein Büro in São Paulo, das nicht nur die SP-Metropole, sondern den gesamten brasilianischen Markt operativ abdeckt - von Petrobras in Rio über Caixa in Brasília und Vale in Minas Gerais bis Volvo in Curitiba. Das ist die Voraussetzung dafür, dass deutsche Enterprise-AI-Standards (Audit Trail, Cert-Ready by Design, Decision Layer mit Human-in-the-Loop) in einem Markt funktionieren, der mit EU AI Act zwar verwandt, aber nicht identisch ist.

## Die drei regulatorischen Hürden für AI im brasilianischen Markt

**LGPD (Lei Geral de Proteção de Dados) ist die brasilianische DSGVO-Antwort, aber nicht ihre Übersetzung**: Sie hat eigene Rechtsgrundlagen, eigene DPO-Anforderungen, eigene Sanktionen und mit der ANPD (Autoridade Nacional de Proteção de Dados) eine eigene Aufsichtsbehörde mit Sitz in Brasília. Wer aus Europa nach Brasilien expandiert, kann LGPD nicht als „DSGVO-Variante" abhandeln - die Auslegung von Artikel 7 (Rechtsgrundlagen) und Artikel 11 (sensible Daten) unterscheidet sich praktisch erheblich. AI-Architekturen müssen LGPD und DSGVO parallel erfüllen können, nicht stattdessen.

**BACEN Resolução 4893 ist Brasiliens DORA**: Die Cyber-Resilience-Vorgaben für regulierte Finanzinstitute (Itaú, Bradesco, Santander Brasil, Banco do Brasil, Caixa, Nubank, Stone, XP) sind unabhängig vom EU-Recht entwickelt. Jede algorithmische Komponente in Kreditentscheidungen, Fraud-Scoring, AML/KYC oder Kapitalmarkt-Operationen muss BACEN-auditfähig sein - mit Reporting-Pflichten, die von europäischen DORA-Implementierungen abweichen.

**PL 2338/2023 ist der brasilianische KI-Gesetzentwurf**: Er ist vom EU AI Act inspiriert, aber nicht identisch - 2026 noch nicht in Kraft, aber in den nächsten 18-24 Monaten erwartet. Risikoklassen, Pflicht zur menschlichen Aufsicht und Erklärbarkeitsstandards sind ähnlich, aber mit eigenen brasilianischen Akzenten (insbesondere im Verhältnis zu Sindicatos und CREs bei arbeitsbezogenen Systemen). Cert-Ready by Design heißt in Brasilien: Architektur so anlegen, dass sie LGPD heute, PL 2338 ab 2027 und EU AI Act für DACH-Operationen gleichzeitig bedient.

## Typische Einsatzszenarien in Brasilien

**Banking und Fintech**: KYC/AML bei [Itaú, Bradesco, Santander Brasil und Banco do Brasil](/de/ai-agents-sao-paulo/) - Document Agents lesen CPF/CNPJ-Daten, gleichen sie mit Coaf-Sanktionslisten ab, und der Decision Layer eskaliert High-Risk-Treffer mit vollständigem Audit Trail. Dasselbe Muster bei Nubank, Stone, PagSeguro und XP Inc. - mit Fraud Detection und BACEN-Reporting in Echtzeit.

**Bergbau und Energie**: Vale Dam-Safety in [Minas Gerais](/de/ai-agents-belo-horizonte/) und Petrobras Anlagen-Dokumentation in [Rio](/de/ai-agents-rio-de-janeiro/) - Workflow Agents überwachen Sensor-Daten, Inspektionsberichte und externe Risikoindikatoren. Decision Layer eskaliert kritische Risikomuster mit Human-in-the-Loop. Audit Trail ist vor ANM, MPF, ANP und ANEEL erklärbar.

**Industrie und Auto**: Volvo, Renault, VW und Klabin in [Curitiba](/de/ai-agents-curitiba/) - Document Agents für Supply Chain, Mercosul-Compliance und ESG-Reporting. Workflow Agents für Qualitätskontrolle und Wartungsplanung. Cert-Ready für DSGVO-Audits in europäischen Mutter-Konzernen.

**Public Sector**: Caixa-Kreditprüfung und ANPD-Policy-Analyse in [Brasília](/de/ai-agents-brasilia/) - Document Agents für Sozialleistungs-Anträge, Workflow Agents für regulatorisches Monitoring. Audit Trail nach TCU-Anforderungen, mit Begründungs-Akten für jede algorithmische Empfehlung. Public-Sector-Projekte in Brasilien laufen unter eigenen Vergaberahmen und mit eigenen Datenschutz-Standards für Cidadão-Daten - die Einhaltung dieser Rahmen ist Voraussetzung für jede Vertragsverlängerung.

## Wie Gosign aus São Paulo ganz Brasilien betreut

Unser Büro in [São Paulo](/de/ai-agents-sao-paulo/) ist der operative Hub für Brasilien - mit lokalen Projektleitern, die Discovery-Workshops vor Ort führen, an Compliance-Reviews mit DPO und Rechtsabteilung teilnehmen und Sindicato-Konsultationen begleiten. Von SP aus sind Rio (1 h Flug), Belo Horizonte (1 h), Curitiba (1 h), Brasília (1,5 h) und Porto Alegre (1,5 h) tagesreichbar - Vor-Ort-Termine binnen 24 Stunden. Die technische Build-Phase läuft verteilt zwischen Hamburg und São Paulo, mit gemeinsamen Stand-ups am Vormittag SP-Zeit. Nach Go-Live ist das SP-Büro Ihr operativer Ansprechpartner mit Eskalations-Hotline auf Portugiesisch. Für brasilianische Kunden mit europäischen Operationen (z.B. Natura nach EU, JBS nach EU) ist das die einzige Konstellation, die LGPD- und DSGVO-Compliance unter einem Dach abbildet.

Was diese Konstellation für deutsche Mittelständler und Konzerne attraktiv macht: Wer aus DACH heraus nach Brasilien expandiert, hat einen Ansprechpartner, der beide Welten operativ abdeckt - die deutsche Konzernzentrale spricht weiterhin mit dem Hamburger Team, das brasilianische Tochterunternehmen mit dem São-Paulo-Team. Discovery- und Compliance-Workshops finden in beiden Sprachen statt. Eine in São Paulo gebaute Architektur kann mit minimalen Anpassungen in Lissabon, Madrid oder Berlin produktiv gehen, weil die Audit-, Decision-Layer- und Cert-Ready-by-Design-Komponenten bereits beide regulatorischen Welten bedienen.

## Warum Brasilien als Startpunkt für Enterprise AI funktioniert

Brasilien ist der einzige lateinamerikanische Markt, in dem Banken-Compliance, Industrie-Operations, Public Sector und Konsumgüter-Lieferketten in einem regulatorischen Rahmen zusammentreffen. Wer hier produktive Agents für KYC, ESG-Reporting oder Damm-Sicherheit baut, hat sie als Blueprint für Mexiko, Argentinien, Chile, Kolumbien und Peru verfügbar. Das SP-Büro positioniert Gosign als europäischen Anbieter mit echter LATAM-Präsenz - eine Kombination, die im DACH-Wettbewerbsumfeld kaum jemand sonst hat. Gosigns Governance-by-Design-Architektur stellt sicher, dass ein in Brasilien gebauter Agent in europäischen DSGVO- und EU-AI-Act-Audits genauso besteht wie vor BACEN, ANPD oder TCU. Mehr im [Kontaktbereich](/de/kontakt/) oder in den Stadt-Übersichten zu [São Paulo](/de/ai-agents-sao-paulo/), [Rio](/de/ai-agents-rio-de-janeiro/) und [Brasília](/de/ai-agents-brasilia/).

--- AI Agents für Unternehmen in Curitiba | Gosign ---
> Enterprise AI Agents für Curitiba und Parana. LGPD-konform, CLT-kompatibel. Tech-Hub Südbrasiliens. Projektleitung von São Paulo.

## Curitiba ist der einzige brasilianische Tech-Hub, in dem europäische Auto-Konzerne dichter sitzen als deutsche Mittelständler in einer DACH-Region

Wenn man die Industrie-Korridore von Curitiba und Umland anschaut, sieht man fast eine Karte von Wolfsburg-Stuttgart-München in tropischer Version. Volvo do Brasil baut hier Lkw und Busse. Renault Brasil betreibt das Werk im Complexo Ayrton Senna in São José dos Pinhais. Volkswagen Curitiba (eigentlich in São José dos Pinhais) und Audi sind nebenan. Klabin (größter Papierhersteller Brasiliens) hat Hauptsitz und Cluster-Werke in Telêmaco Borba. Boticário Group (zweitgrößte Kosmetikkette Brasiliens) sitzt in São José dos Pinhais. Positivo Tecnologia und Bematech bilden das Tech-Cluster. Curitiba ist Brasiliens ordentlichste, geplanteste, „europäischste" Stadt - was sie zum natürlichen Andockpunkt für deutsche und europäische Industrie-Standards macht.

## Die drei regulatorischen Hürden für AI im Curitiba-Markt

**ANTT (Agência Nacional de Transportes Terrestres) für Logistik und Lkw**: Volvo, Renault, VW und die paranaische Logistikbranche operieren unter ANTT-Aufsicht für Schwertransporte, Mautsysteme und Fahrer-Dokumentation. AI-Komponenten in Routenoptimierung, Maut-Abgleich oder Fahrer-Compliance müssen ANTT-Reportings unterstützen - mit Audit Trail, der den kompletten Entscheidungsweg vom Sensor bis zum CONTRAN-Verstoß-Bericht dokumentiert. Bei Schwerlast-Operationen mit grenzüberschreitenden Mercosul-Strecken (Argentinien, Uruguay, Paraguay) kommen zusätzliche Zoll- und Dokumentationspflichten dazu, die jeden Logistik-Agent in eine multi-jurisdiktionale Architektur zwingen.

**LGPD und Boticário-Skala**: Die Boticário Group betreibt eines der größten CRM- und Treueprogramme Brasiliens. Jede AI-Komponente in Customer Segmentation, Personalization Engines oder Influencer-Routing muss LGPD-Artikel 7 (Rechtsgrundlage), Artikel 11 (sensible Daten) und die ANPD-Resolution zu DPIAs (Data Protection Impact Assessments) erfüllen - inklusive nachvollziehbarem Modell-Versionsstand pro Entscheidung.

**IBAMA und ESG-Reporting für Klabin**: Klabin gilt als ESG-Vorzeigeunternehmen, und genau deshalb sind die Anforderungen an automatisiertes Reporting (FSC, GRI, SASB) hoch. AI, die Holzherkunft, Wasserverbrauch oder CO2-Bilanzen aggregiert, muss erklärbar sein und vor IBAMA, externen Auditoren und ESG-Anlegern Bestand haben - Cert-Ready by Design ist hier kein Marketing, sondern Voraussetzung der Investor-Relations.

## Typische Einsatzszenarien in Curitiba

**Volvo Brasil und Renault Brasil Supply Chain**: Document Agents lesen Lieferanten-Dokumentation, Zoll-Erklärungen, Mercosul-Ursprungsnachweise und Qualitäts-Zertifikate. Der Decision Layer eskaliert bei Mercosul-Quoten-Konflikten oder Compliance-Lücken an Einkauf und Logistik - Workflow Agents alarmieren proaktiv bei drohenden Lieferengpässen, mit Audit Trail bis zum Lieferanten-Stammdatensatz. Bei Werken, deren Vor-Lieferanten in Argentinien, Uruguay und Paraguay sitzen, ist die Mercosul-Ursprungsdokumentation eines der zollkritischsten Themen überhaupt.

**Boticário CRM und Personalization**: Document und Workflow Agents verarbeiten Kundenkontakte aus Filialen, App und Direktvertrieb (über die Revendedoras-Struktur), gleichen sie LGPD-konform mit Einwilligungs-Status ab, und der Decision Layer routet Kampagnen-Empfehlungen mit Human-in-the-Loop an die Marketing-Verantwortlichen. Bei einem Direktvertriebsmodell mit über einer Million Beraterinnen ist die Einwilligungsverwaltung pro Kontakt eines der LGPD-kritischsten Themen überhaupt - Audit Trail muss bis zur einzelnen Opt-in-Quittung zurückreichen.

**Klabin Nachhaltigkeits-Reporting**: Document Agents aggregieren Forst-Inventar, Sägewerks-Protokolle und Energie-Daten zu auditierbaren ESG-Berichten nach FSC, GRI und SASB. Der Decision Layer markiert Datenlücken oder Plausibilitätskonflikte für menschliche Validierung - jede Aggregation mit nachvollziehbarer Datenherkunft und Modell-Versionierung. Bei börsennotierten Unternehmen mit europäischen ESG-Anlegern ist diese Audit-Tiefe Voraussetzung für jede CSRD-Berichterstattung.

**Positivo Tecnologia Lieferanten-Compliance**: Document Agents prüfen Halbleiter-Bezugsquellen, RoHS-Konformität und Mercosul-Ursprungsnachweise für Brasiliens größten lokalen IT-Hardware-Hersteller. Workflow Agents alarmieren bei Engpässen und dokumentieren jede Empfehlung mit Audit Trail bis zum ursprünglichen Lieferanten-Zertifikat.

## Wie Gosign aus São Paulo ganz Brasilien betreut - inklusive Curitiba

Unser Büro in [São Paulo](/de/ai-agents-sao-paulo/) ist 1 Flugstunde von Curitiba entfernt. Discovery-Workshops mit Volvo, Renault, Klabin oder Boticário finden vor Ort statt - in Curitiba, São José dos Pinhais oder direkt in den Werks-Standorten. Compliance-Reviews mit LGPD-, ANTT- oder IBAMA-Bezug werden gemeinsam mit Ihrer Rechtsabteilung und der lokalen Anwaltskanzlei geführt. Sindicato-Konsultationen für HR-Agents werden mit den lokalen Vertretungen in Paraná abgestimmt - die Sindicato-Strukturen in der paranaischen Auto-Industrie sind weniger konfrontativ als in São Paulo, dafür aber technisch detaillierter in der Diskussion algorithmischer Entscheidungen. Build-Phasen laufen verteilt zwischen Hamburg und São Paulo - 4 Stunden Zeitversatz, Stand-ups vormittags SP-Zeit. Vor-Ort-Termine in Curitiba sind binnen 24 Stunden organisierbar. Für deutsche und europäische Mutterkonzerne (Volkswagen, Renault, Volvo, Stellantis) parallele Berichterstattung in Deutsch, Englisch und Portugiesisch.

## Warum Curitiba als Startpunkt für Enterprise AI funktioniert

Curitiba ist der einzige brasilianische Markt, in dem deutsche und europäische Industrie-Konzerne in einer Konzentration sitzen, die operativ vergleichbar mit DACH-Industrie-Regionen ist. Wer hier einen produktiven Agent für Supply Chain, Qualitätskontrolle oder ESG-Reporting baut, baut ihn in einem Umfeld, in dem die Auftraggeber europäische Standards bereits verinnerlicht haben - was den Übergang von einem PoC in Paraná zu einem Produktiv-Rollout in Wolfsburg, Stuttgart oder Göteborg radikal verkürzt. Die Cluster - Tecpar, Curitiba Smart City, der Innovations-Korridor um die Universidade Federal do Paraná - liefern Talent und Forschungspartner. Curitibas Tradition als Brasiliens „europäischste" Stadt (Stadtplanung in den 1970er Jahren orientiert an europäischen Vorbildern, hohe Konzentration deutsch- und italienisch-stämmiger Bevölkerung, eine etablierte deutsche Auslandshandelskammer in Paraná) bedeutet auch im operativen Alltag: weniger Übersetzungsverluste in Discovery-Workshops, weniger kulturelle Reibung bei Sprint-Planung und höhere Anschlussfähigkeit an europäische Konzern-Governance. Gosigns Governance-by-Design-Architektur ist Cert-Ready für DSGVO und EU AI Act ab Tag 1 - in Curitiba ist das nicht nur regulatorischer Vorteil, sondern auch operativer. Mehr im [Brasilien-Überblick](/de/ai-agents-brasilien/) oder im Profil der [São-Paulo-Operationen](/de/ai-agents-sao-paulo/).

--- AI Agents für Unternehmen in Deutschland | Gosign ---
> Enterprise AI Agents für deutsche Unternehmen. DSGVO-konform, EU AI Act compliant, betriebsratskompatibel. Hauptsitz Hamburg, Büros in Berlin. Gosign GmbH.

## Deutschland ist Gosigns Heimatmarkt - und der EU-Markt mit der höchsten Compliance-Dichte

Deutschland kombiniert drei Eigenschaften, die in dieser Form in keinem anderen EU-Land existieren: maximale Konzern-Dichte über mehrere Branchen, ein verbindliches Mitbestimmungsrecht des Betriebsrats nach § 87 Abs. 1 Nr. 6 BetrVG, und eine föderale Aufsichtsstruktur mit BaFin, BSI, BfDI und sechzehn zusätzlichen Landes-Datenschutzbehörden. Die Konzernlandschaft reicht von Automotive (VW, BMW, Daimler, Porsche, Continental, Bosch, ZF) über Chemie (BASF, Bayer, Evonik, Merck, Covestro), Maschinenbau (Siemens, Trumpf, Dürr, Kuka, Festo), Banking (Deutsche Bank, Commerzbank, Sparkassen, Volks- und Raiffeisenbanken), Insurance (Allianz, Munich Re, Ergo, HDI, R+V), Energy (RWE, E.ON, EnBW) bis Retail (Otto, Zalando, Lidl/Kaufland, Rewe, Edeka). Gosign ist mit Hauptsitz in [Hamburg](/de/ai-agents-hamburg/) und Büro in [Berlin](/de/ai-agents-berlin/) Teil dieses Marktes - und genau dafür ist die Architektur gebaut.

## Die drei regulatorischen Hürden für AI im deutschen Markt

Erstens das Betriebsverfassungsgesetz: § 87 Abs. 1 Nr. 6 BetrVG gibt dem Betriebsrat ein Mitbestimmungsrecht bei der Einführung technischer Einrichtungen, die das Verhalten oder die Leistung der Arbeitnehmer überwachen können. KI-Systeme in HR, in der Schichtplanung, in der Performance-Auswertung, im Service-Desk-Routing - alle fallen darunter. Eine produktive Implementierung ohne Betriebsvereinbarung ist in deutschen Konzernen rechtlich nicht haltbar. Der Decision Layer mit erzwungenem Human-in-the-Loop ist hier nicht ein Architektur-Feature, sondern Voraussetzung dafür, dass der Betriebsrat zustimmt.

Zweitens DSGVO und BDSG mit der föderalen Datenschutz-Aufsicht: BfDI im Bund, plus sechzehn Landes-Datenschutzbeauftragte, plus die spezifischen Anforderungen aus dem Bundesdatenschutzgesetz. Bei automatisierter Entscheidungsfindung im Sinne des Art. 22 DSGVO erwarten die deutschen Datenschutzbehörden dokumentierte Rechtsgrundlagen, abrufbare Erklärungen und einen vollständigen Audit Trail. Die deutsche Spezifik: Die Datenschutz-Folgenabschätzung muss bei Hochrisiko-Anwendungen vor Inbetriebnahme abgeschlossen sein, nicht parallel zum Rollout.

Drittens BaFin, BSI, BNetzA und der EU AI Act: BaFin beaufsichtigt den Finanzsektor und erwartet bei AML, KYC, Kreditscoring und Schadenbearbeitung nachweisbare menschliche Letztentscheidung in Risikofällen. BSI definiert die Mindestanforderungen an IT-Sicherheit für KRITIS-Unternehmen. Der EU AI Act wird in Deutschland über das in Vorbereitung befindliche Gesetz zur Durchführung der KI-Verordnung umgesetzt - mit Schwerpunkt auf Hochrisiko-Anwendungen in HR, Banking, Insurance und kritischer Infrastruktur. Wer hier ohne Cert-Ready by Design startet, baut auf einer Architektur, die spätestens beim ersten BaFin-Audit nachgerüstet werden muss.

## Typische Einsatzszenarien in Deutschland

Allianz und Munich Re Schadenbearbeitung: Die deutschen Versicherungsführer verarbeiten täglich Tausende Schadenfälle. Workflow Agents klassifizieren eingehende Schäden nach Tarif, Region und Komplexität, der Decision Layer routet Risikofälle an menschliche Sachbearbeiter, und der Audit Trail dokumentiert jede Entscheidung für interne Revisionen und BaFin-Audits.

Commerzbank und Sparkassen AML-Operations: Bei Millionen Transaktionen pro Tag prüfen Document Agents Identifikationsmerkmale, der Decision Layer routet Verdachtsfälle entlang der BaFin-Schwellen, mit Human-in-the-Loop bei jeder finalen Eskalation.

VW, BMW und Daimler HR-Operations: Deutsche Automotive-Konzerne haben Hunderttausende Mitarbeiter und entsprechend komplexe HR-Prozesse. Workflow Agents unterstützen Recruiting und interne Mobilität, mit erzwungener menschlicher Letztentscheidung bei Personalmaßnahmen - eine zwingende Voraussetzung für Betriebsrats-Akzeptanz nach § 87 BetrVG.

BASF und Bayer Produktionsdokumentation: Die deutschen Chemie-Konzerne erzeugen täglich riesige Mengen an Sicherheits- und Qualitätsdokumentation. Document Agents extrahieren regulatorisch relevante Spezifikationen, gleichen sie gegen REACH, CLP und CE-Anforderungen ab, mit vollständigem Audit Trail bis zur Quell-PR.

## Wie Gosign aus Hamburg und Berlin Deutschland betreut

Gosign hat den Hauptsitz in Hamburg (Hallerstraße 8) und ein Büro in Berlin (Nogatstraße 46), dazu ein Schulungszentrum in Hamburg am Grindelberg 77. Discovery-Workshops finden vor Ort beim Kunden statt - in [München](/de/ai-agents-muenchen/), [Frankfurt](/de/ai-agents-frankfurt/), [Stuttgart](/de/ai-agents-stuttgart/), [Düsseldorf](/de/ai-agents-duesseldorf/), [Köln](/de/ai-agents-koeln/), [Hannover](/de/ai-agents-hannover/) oder direkt in Hamburg und Berlin. Anschließend läuft der Build remote, mit deutschsprachiger Dokumentation, wöchentlichen Sprint Reviews per Video, einem festen Ansprechpartner und Vor-Ort-Besuchen alle vier bis sechs Wochen. Termine mit Betriebsrat, Datenschutzbeauftragten und Compliance-Funktionen sind feste Bestandteile jedes Projekts. Vor-Ort-Termine bei BaFin, BSI oder Landes-Datenschutzbehörden begleitet Gosign auf Anfrage gemeinsam mit der internen Rechtsabteilung.

## Warum Deutschland als Startpunkt für Enterprise AI funktioniert

Deutschland ist nicht der einfachste, aber der härteste EU-Markt für Enterprise-AI-Compliance. Genau das macht ihn zum besten Startpunkt. Wer einen AI Agent baut, der DSGVO, BDSG, BetrVG, BaFin- und BSI-Anforderungen sowie den EU AI Act erfüllt, hat eine Architektur entwickelt, die in jedem anderen EU-Land nur noch eine Konfigurationsänderung weit ist. Die deutsche Compliance-Kultur und die Betriebsrats-Mitbestimmung erzwingen Governance by Design - kein anderes EU-Land verlangt das in dieser Konsequenz.

Für DAX-Konzerne, MDAX-Unternehmen und den deutschen Mittelstand mit über 200 Mitarbeitern ist diese Disziplin nicht Bürde, sondern Wettbewerbsvorteil: Was in Deutschland produktiv geht, geht in der EU produktiv. Eine Architektur, die der BaFin standhält, hält der niederländischen DNB, der österreichischen FMA und der französischen ACPR ebenfalls stand. Eine Lösung, die mit dem Betriebsrat eines deutschen Industriekonzerns abgestimmt wurde, lässt sich in Polen mit der Rada Zakładowa, in Spanien mit dem Comité de Empresa und in Frankreich mit dem CSE ohne grundlegenden Re-Build aushandeln. Gosign ist als Hamburger Unternehmen Teil dieses Marktes - die Architektur ist nicht aus dem Lehrbuch entstanden, sondern aus Projekten in deutschen Konzernen, deren Audit-Erwartungen jeden ersten produktiven Tag bestimmt haben. Cert-Ready by Design ist hier nicht ein Verkaufsargument, sondern eine konstruktive Notwendigkeit. Mehr Kontext zum [EU AI Act](/de/governance/eu-ai-act/) und der deutschen Umsetzung gibt es im Governance-Bereich.

--- AI Agents für Unternehmen in Dublin | Gosign ---
> Enterprise AI Agents für Dublin. EU-Zentralen von Tech-Konzernen, DPC-Aufsicht, EU AI Act direkt anwendbar. Auditierbare KI für Irlands Enterprise-Hub.

## In Dublin entscheidet eine einzelne EU-Aufsichtsbehörde, was für 450 Millionen Europäer als DSGVO-konform gilt

Dublin ist nicht einfach eine weitere europäische Hauptstadt - es ist die regulatorische Hauptstadt für US-Tech in Europa. Google EU, Meta EU, LinkedIn EU, Microsoft EU, Stripe EU und Apple haben hier ihre EU-Zentralen, weil Irland eine Kombination aus Steuerregime, englischer Sprache und politischer Stabilität bietet. Dazu kommen die irischen Schwergewichte: AIB (Allied Irish Banks), Bank of Ireland, Accenture mit globalem Hauptsitz in Dublin, Ryanair, Kerry Group und CRH (einer der weltweit größten Baustoffkonzerne). Die "Silicon Docks" am Grand Canal bündeln auf wenigen Quadratkilometern mehr Engineering-Talent für Trust & Safety, Compliance Engineering und AI-Governance als jede andere europäische Stadt - weil hier die Aufsicht über exakt diese Themen sitzt.

## Die drei regulatorischen Hürden für AI im Dubliner Markt

Erstens die DPC (Data Protection Commission). Wegen des One-Stop-Shop-Prinzips der DSGVO ist die DPC für nahezu alle US-Tech-Konzerne mit EU-Hauptsitz in Irland die federführende Aufsichtsbehörde - und damit faktisch die wichtigste DSGVO-Behörde der gesamten Union. Die DPC hat in den letzten Jahren mehrere Milliarden-Bußgelder gegen Meta, Google und WhatsApp ausgesprochen und prüft inzwischen auch AI-Modellierung und Trainingsdaten unter dem DSGVO-Regime. Wer in Dublin AI baut, baut für eine Behörde, die jede Trainingsdaten-Quelle, jede automatisierte Entscheidung und jeden Cross-Border-Transfer im Detail prüft.

Zweitens der EU AI Act, der in Irland direkt anwendbar ist. Die irische Regierung hat den Department of Enterprise, Trade and Employment als zuständige Stelle für die nationale Umsetzung benannt und arbeitet eng mit der DPC zusammen. Hochrisiko-AI-Systeme von Tech-Konzernen mit EU-Hauptsitz Dublin werden zukünftig hier zertifiziert - und die Erwartung ist, dass die Standards überdurchschnittlich streng ausgelegt werden, weil Dublin politisch beweisen muss, dass es kein Aufsichts-Schlupfloch ist.

Drittens die Central Bank of Ireland für alle Finanzdienstleister. Stripe, Mastercard EU, Citi EU, Goldman Sachs EU - sie alle sind unter CBI-Aufsicht und müssen AI-gestützte Compliance- und Risk-Modelle nach den CBI Innovation Hub-Standards dokumentieren. Die CBI verlangt vollständige Erklärbarkeit, Audit Trails und kontinuierliche Modellüberwachung. [EU AI Act Compliance](/de/governance/eu-ai-act/) und Finanzaufsicht müssen hier ineinandergreifen.

## Typische Einsatzszenarien in Dublin

Google nutzt Dublin als globalen Hub für AI-Modell-Governance und arbeitet hier an Compliance-Werkzeugen, die jede Modell-Entscheidung gegenüber der DPC erklärbar machen müssen. Meta dokumentiert hier den Digital Services Act (DSA) und prüft Content-Moderationsmodelle auf systemische Risiken - jede algorithmische Entscheidung muss ein Audit Trail haben. Stripe baut globale Payment-Risk-Modelle, die in Sekunden Transaktionen blockieren oder freigeben - die Modelle müssen für die CBI nachvollziehbar bleiben. AIB modernisiert Kreditentscheidungen und braucht Modelle, die unter Art. 22 DSGVO und Central Bank Code of Conduct gleichermaßen verteidigbar sind.

In allen Fällen entstehen Entscheidungen mit globaler Reichweite, aber die Aufsicht passiert in Dublin - oft mit kurzen Reaktionszeiten und harten Fragen zu Modellverhalten, Trainingsdaten und Bias-Mitigation. Der [Decision Layer](/de/decision-layer/) löst genau diese Anforderung: Er macht jede AI-Entscheidung als Trace persistierbar, durchsetzt Human-in-the-Loop bei kritischen Pfaden und liefert Audit Trails, die DPC- und CBI-Prüfern standhalten.

Die irische Besonderheit ist die Erwartungshaltung der DPC: Anders als manche Aufsichtsbehörden in der EU prüft die DPC nicht nur nach Verstößen, sondern führt regelmäßig proaktive Inquiries durch. Wer in Dublin eine AI-Anwendung produktiv betreibt, muss damit rechnen, dass die DPC unangekündigt Dokumentation, Trainingsdaten-Provenienz und Modellentscheidungen einsieht. Cert-Ready by Design heißt hier nicht "wenn es zum Audit kommt" - sondern "permanent prüfbereit".

## Wie Gosign aus Hamburg Dublin betreut

Hamburg-Dublin ist ein direkter Flug von etwa zwei Stunden, mit mehreren täglichen Verbindungen. Wir arbeiten Remote-first mit Kunden in Dublin und Cork, mit Vor-Ort-Workshops für Discovery und Architekturentscheidungen. Die Arbeitssprache ist Englisch, die Steering-Runden mit unseren Hamburger Architekten laufen auf Deutsch. Die Zeitzone (Irland WET, eine Stunde hinter MEZ) ist überschaubar, der irische Geschäftsstil pragmatisch und entscheidungsfreudig.

Was wir aus dem deutschen Markt mitbringen, ist die Disziplin des Engineerings unter strenger Aufsicht. Die deutschen Banken, die wir betreuen, haben mit BaFin und MaRisk vergleichbare Compliance-Anforderungen wie die irischen Tech-Konzerne mit DPC und CBI - die regulatorische Tonalität ist vertraut, die technischen Antworten übertragen sich direkt. Wir kennen die irischen Tech-Aufsichtsregimes gut genug, um nicht jeden Begriff erst übersetzen zu müssen, und können in Discovery-Workshops sofort konkrete Architekturentscheidungen anbieten.

## Warum Dublin als Startpunkt für Enterprise AI funktioniert

Dublin hat den höchsten regulatorischen Anspruch für AI in Europa - und gleichzeitig die größte Konzentration an Engineering-Kompetenz für AI-Governance. Wer hier einen Cert-Ready-by-Design-Piloten baut, hat einen Referenzfall, der in jedem anderen EU-Markt sofort verteidigbar ist - und der gegenüber der DPC standhält. Das Silicon Docks-Cluster, der Dublin Tech Cluster und das Enterprise Ireland AI-Programm liefern Talent, Ökosystem und Pilotpartner.

Der zweite Vorteil: Wer in Dublin AI baut, lernt automatisch, wie pan-europäische Compliance funktioniert. Die meisten irischen Tech-Konzerne agieren über alle 27 Mitgliedstaaten gleichzeitig - jede Architektur muss jurisdiktionsspezifische Regelsätze handhaben können, ohne den Audit Trail zu fragmentieren. Genau das liefert Governance by Design. Hamburg liefert die deutsche Engineering-Disziplin, Dublin liefert das EU-weite Ausrollen.

--- AI Agents für Unternehmen in Düsseldorf und NRW | Gosign ---
> Enterprise AI Agents für Düsseldorf und NRW. Betriebsratskompatibel, DSGVO-konform, EU AI Act compliant. Shared Services automatisieren.

## Düsseldorf ist der deutsche Standort, an dem Konsumgüter, Energie, Telekommunikation und industrieller Mittelstand auf engstem Raum dieselbe Shared-Service-Frage stellen

Im Korridor zwischen Königsallee, Oberkassel und der Düsseldorfer Messe konzentrieren sich Henkel, Vodafone Deutschland mit Konzernsitz, E.ON, Metro AG und Uniper - dazu Ergo Versicherung als Teil der Munich-Re-Gruppe, Rheinmetall als Defence-Konzern, L'Oréal Deutschland und Trivago als grösstes Düsseldorfer Tech-Unternehmen. Hinzu kommt das gesamte Rheinland mit Bayer und LANXESS in Leverkusen, Henkel-Tochterstandorten in Düsseldorf-Holthausen und einem dichten Mittelstand zwischen Krefeld, Wuppertal und Duisburg. Diese Konzentration erzeugt einen spezifischen Architekturbedarf: Die meisten dieser Konzerne betreiben Shared Service Center für Finance, HR und IT, die Prozesse über zehn bis hundert Gesellschaften gleichzeitig orchestrieren - mit jeweils unterschiedlichen Jurisdiktionen, Tarifverträgen und Steuerregimen. Eine AI-Architektur, die hier funktioniert, muss mehrmandantenfähig sein und Governance-Regeln pro Entität tragen.

## Drei regulatorische Hürden, die im Düsseldorfer Markt jede AI-Initiative formen

Die erste Hürde ist die NRW-spezifische Energieregulierung - die BNetzA mit Sitz in Bonn ist die zentrale Aufsicht für Strom- und Gasnetze, und die meisten grossen Energieversorger Deutschlands haben Marktoperationen in Düsseldorf oder Essen. E.ON, Uniper und ihre Vertriebsgesellschaften arbeiten im Tagesgeschäft mit den BNetzA-Datenformaten und den BDEW-Spezifikationen. Eine AI-Komponente in Lastprognose, Bilanzkreismanagement oder Kundenakquise muss diese Datenformate kennen und nachvollziehbar verwenden. Die zweite Hürde ist die starke Mitbestimmung bei den NRW-Konzernen mit IG-Metall-, IGBCE- oder ver.di-erfahrenen Betriebsräten und Konzernbetriebsräten - eine Shared-Service-AI muss den Decision Layer architektonisch so bauen, dass mitbestimmungspflichtige Entscheidungen zwingend einem qualifizierten Mitarbeiter vorgelegt werden, und die Betriebsvereinbarungen müssen von Anfang an mitgedacht werden. Die dritte Hürde ist das Lieferkettensorgfaltspflichtengesetz und die EU-Lieferketten-Richtlinie CSDDD - Henkel, L'Oréal, Metro und Rheinmetall müssen für ihre globalen Lieferketten Risiken dokumentieren und das BAFA-Reporting vorbereiten. Mehr Hintergrund unter [Governance EU AI Act](/de/governance/eu-ai-act/).

## Typische Einsatzszenarien in Düsseldorf

Bei Henkel und vergleichbaren Konsumgüterkonzernen sehen wir Lieferketten-Compliance-Agenten, die eingehende Lieferantenunterlagen strukturiert verarbeiten und Risikohinweise an einen Sustainability-Manager eskalieren - mit vollständigem Audit Trail für das BAFA-Reporting nach Lieferkettengesetz. Bei E.ON und im weiteren Energieumfeld geht es um Smart-Meter-Rollout-Begleitung und um die strukturierte Bearbeitung von Netzanschlussanträgen, bei der Sachbearbeiter die Letztentscheidung treffen. Metro AG arbeitet an Sortimentssteuerungs- und Warenverteilungs-Use-Cases, in denen ein Agent regionale Kundendaten und Saisonalität bewertet und einen Vorschlag an den Category Manager gibt. Bei Ergo und vergleichbaren Versicherern unterstützen Agenten die Vertragsprüfung in der Lebensversicherung und bei der Prüfung von Schadenshäufungen. Bei Vodafone Deutschland sehen wir Customer-Service-Agenten, die Kundenanliegen strukturieren, Rückrufe priorisieren und für regulierte Beschwerdefälle nach BNetzA-Vorgaben den vollständigen Vorgang an einen Sachbearbeiter mit Beschwerdemanagement-Verantwortung übergeben. Bei L'Oréal Deutschland und ähnlichen Konsumgüterherstellern unterstützen Document-Agenten bei der Inhaltsstoff-Compliance und der EU-Kosmetikverordnung. Bei Trivago und im Düsseldorfer Tech-Umfeld sehen wir agentische Unterstützung im Kundenservice und in der Content-Moderation, die unter Digital Services Act fällt - mit klarer Eskalation an menschliche Moderatoren bei sensiblen Fällen. Bei Rheinmetall im Defence-Umfeld sehen wir Document-Agenten in der Vertragsanalyse und im Lieferantenscreening, die wegen der Exportkontrolle besondere Audit-Anforderungen erfüllen müssen. In allen Cases entscheidet die qualifizierte Fachperson, der Agent dokumentiert und der [Decision Layer](/de/decision-layer/) hält die Begründung als Audit Trail.

## Wie Gosign aus Hamburg Düsseldorf betreut

Gosign hat keinen Standort in Düsseldorf - die Vor-Ort-Begleitung erfolgt aus Hamburg und dem Berliner Office. Die ICE-Direktverbindung Hamburg-Düsseldorf braucht knapp vier Stunden, ein Direktflug ist deutlich schneller. Konkret organisieren wir die Zusammenarbeit so: Kick-off und Discovery-Workshops finden vor Ort in Düsseldorf statt, meistens als zweitägiger Block mit Engineering-, Compliance- und Betriebsrats-Teilen. In der Build-Phase kombinieren wir remote-Engineering mit zweiwöchentlichen Vor-Ort-Tagen für Architektur-Reviews, Modellvalidierung und Stakeholder-Updates. Wenn ein Konzern Shared Services über mehrere NRW-Standorte betreibt, fahren wir die wichtigen Workshops vor Ort an den jeweiligen Niederlassungen - Düsseldorf-Holthausen für Henkel, Essen für E.ON, Leverkusen für LANXESS oder Bayer. Diese verteilte Vor-Ort-Logik ist eine Eigenheit des rheinischen Marktes, weil Konzernzentralen in NRW oft physisch verteilt sind und Stakeholder-Termine entsprechend organisiert werden müssen. Die Erfahrung aus dem rheinischen Markt zeigt: Pragmatismus zählt mehr als Präsenz, solange die Vor-Ort-Frequenz an den entscheidenden Stakeholder-Terminen stimmt. Cluster wie NRW.Energy4Climate in Düsseldorf nutzen wir für Networking und technische Diskussionen.

## Warum Düsseldorf als Startpunkt für Enterprise AI funktioniert

Wer einen AI Agent in einem Düsseldorfer Shared Service Center in Produktion bringt, hat ihn gegen mindestens drei Jurisdiktionen, mehrere Tarifverträge und einen erfahrenen Konzernbetriebsrat verteidigt - eine Architektur, die das schafft, ist anschliessend in jeder anderen multi-entity-Konstellation in Europa skalierbar. Hinzu kommt die NRW-spezifische Förderlandschaft: Das Land NRW unterstützt KI-Projekte über mehrere Innovationsprogramme, und die Discovery-Phase identifiziert in der Regel mindestens eine geeignete Förderlinie. Cluster wie der Digital Hub Düsseldorf-Rheinland und das Life Science-Netzwerk im Rheinland bieten technischen Austausch und Co-Innovation-Partner. Hinzu kommen die Hochschulen Düsseldorf und die nahegelegenen Universitäten Köln, Bonn, Aachen mit ihren ML-Engineering-Programmen, sowie das Forschungszentrum Jülich als Anker für High-Performance-Computing. Wer in 4-6 Wochen einen ersten Workflow Agent in einem NRW-Shared-Service produktiv hat, baut auf einer Architektur auf, die multi-mandantenfähig und [Governance by Design](/de/governance/eu-ai-act/) ist. Mehr zum Vorgehen unter [AI Agents Leistungen](/de/leistungen/ai-agents/).

--- AI Agents für Unternehmen in Frankfurt | Gosign ---
> Enterprise AI Agents für den Finanzplatz Frankfurt. BaFin-ready, MaRisk-konform, EU AI Act compliant. Finance Agents mit vollständigem Audit Trail.

## Frankfurt ist der einzige europäische AI-Markt, in dem die Aufsicht selbst im selben Stadtteil sitzt wie die Anwender

Das Bankenviertel zwischen Taunusanlage und Mainufer enthält drei Schichten gleichzeitig: die ECB als europäische Zentralbank- und Aufsichtsbehörde, die BaFin als nationale Allfinanzaufsicht in Bonn mit ihrer Zweigstelle und intensiver Frankfurter Präsenz, und die grossen lizenzierten Adressaten - Deutsche Bank, Commerzbank, DZ Bank, KfW, Helaba, DekaBank, Deutsche Börse, ING-DiBa, BNP Paribas Deutschland. Hinzu kommen die Spezialisten der Marktinfrastruktur wie Clearstream und Eurex. Wenn ein Frankfurter AI-Modell scheitert, hat der nächste BaFin-Sonderprüfer es in derselben Woche auf dem Tisch. Das ist gleichzeitig die Stärke des Standorts: Niemand kann hier mit einem PoC starten, der nicht von Anfang an [Cert-Ready by Design](/de/governance/eu-ai-act/) ist. Die ECB hat mit dem Single Supervisory Mechanism die direkte Aufsicht über die signifikant relevanten Institute, was die Frankfurter Banken zu einer doppelten Aufsichtslogik zwingt - europäisch und national. AI-Komponenten in diesen Häusern müssen für beide Aufsichten gleichzeitig nachweisbar sein.

## Drei regulatorische Hürden, die jede AI-Initiative am Finanzplatz Frankfurt durchlaufen muss

Die erste Hürde sind MaRisk und BAIT als bankaufsichtliche Anforderungen. Jedes Modell, das in Risikomanagement, Kreditentscheidung oder Geldwäscheprävention eingreift, muss mit einer Modellvalidierung dokumentiert sein, die der internen Revision und der BaFin-Sonderprüfung gleichermassen standhält - inklusive Backtesting, Sensitivitätsanalyse und reproduzierbarem Trainingslauf. Die zweite Hürde ist der MiFID-II-Block: Transaction Reporting nach Artikel 26 MiFIR, Best-Execution-Nachweise und die Vorgaben aus der ESMA Q&A treffen jede automatisierte Order- oder Beratungs-Komponente. Die EBA-Leitlinien zur ICT-Risk-Management ergänzen das mit klaren Erwartungen an Outsourcing und Drittanbieter. Die dritte Hürde ist das BaFin-Meldewesen selbst - FinaRisikoV, FinanzInformatikV, EZB-Stresstest-Daten - bei dem auch die unterstützenden AI-Komponenten als Teil des Aufsichtsperimeters gelten. Wer auf den Finanzplatz Frankfurt zielt, plant Modellgovernance, Audit Trail und Validierung von Tag eins als Hauptarbeit, nicht als Dokumentationsanhang.

## Typische Einsatzszenarien in Frankfurt

In der Geldwäscheprävention sehen wir Triage-Agenten für AML-Hits aus den Transaktions-Monitoring-Systemen - der Agent reichert den Hit mit Kundenhistorie, KYC-Daten und externen Quellen wie Sanktionslisten und PEP-Datenbanken an, bewertet die Plausibilität und übergibt einen Vorschlag an den Compliance-Officer, der entscheidet, ob eine Verdachtsmeldung an die FIU erfolgt. Bei den grossen Adressaten in der Wertpapierabwicklung helfen Agenten beim Pre-Settlement-Matching und bei der Ausnahmebehandlung - aufwändige Reconciliations, die heute manuell laufen. Im MiFID-II-Reporting prüfen Agenten die Vollständigkeit und Plausibilität der ARM-Meldungen vor der Einreichung. Im Firmenkundenkredit unterstützen sie bei der Vorbereitung der Bonitätsanalyse durch strukturierte Verarbeitung von Jahresabschlüssen, Bilanzen und Vertragsdokumenten - der Kreditanalyst erhält einen vorbereiteten Datenraum mit Plausibilitätschecks, kein automatisches Rating. Bei der KfW und vergleichbaren Förderbanken sehen wir Document-Agenten in der Antrags-Vorqualifikation, die eingehende Förderanträge auf Vollständigkeit prüfen und Sachbearbeitern eine strukturierte Übersicht der Unterlagen geben. Bei der Deutschen Börse und im weiteren Marktinfrastruktur-Umfeld unterstützen Knowledge-Agenten beim Management von Marktstandards, ISIN-Daten und Listing-Dokumentation. In den BAIT-relevanten ICT-Bereichen helfen Agenten bei der strukturierten Vorbereitung von Incident-Reports und der Auswertung von Penetration-Test-Ergebnissen. Was alle diese Cases verbindet: Die Letztentscheidung trifft immer ein Mensch, der Agent liefert den begründeten Vorschlag, und der [Decision Layer](/de/decision-layer/) hält die vollständige Kette aus Input, Bewertung, Konfidenz und Begründung als Audit Trail fest.

## Wie Gosign aus Hamburg Frankfurt betreut

Gosign hat keinen Standort in Frankfurt - das ist eine bewusste Entscheidung. Wir betreiben Hauptsitz Hamburg und Office Berlin, Frankfurt erreichen wir auf der ICE-Strecke in unter vier Stunden. Konkret läuft das so: Discovery- und Kick-off-Termine sowie die wichtigen Stakeholder-Meetings in Risk und Compliance machen wir vor Ort in Frankfurt - typischerweise mit einem zweitägigen Aufenthalt, der Workshop, Architektur-Review und Auditoren-Briefing kombiniert. Die Engineering-Phase läuft remote von Hamburg aus, mit zweiwöchentlichen Vor-Ort-Tagen und festen Slots in Ihrem Compliance-Office. Modellvalidierungsworkshops mit der internen Revision passieren immer vor Ort, weil hier die fachliche Diskussion mit Risk- und Compliance-Verantwortlichen die Architektur prägt. Die Erfahrung aus dem Finance Agent Catalog der letzten Jahre zeigt: Die Vor-Ort-Frequenz reicht für die meisten BaFin-relevanten Projekte aus, weil die Hauptarbeit in der dokumentierten Modellgovernance liegt - und die ist remote nicht weniger gründlich.

## Warum Frankfurt als Startpunkt für Enterprise AI funktioniert

Der Finanzplatz hat eine Eigenschaft, die ihn als ersten Schritt einer AI-Strategie auszeichnet: Wer hier einen Use Case durchbringt, hat ihn gegen die strengsten Aufsichtsanforderungen Europas verteidigt. Die gleiche Modellvalidierung trägt anschliessend in München, Stuttgart oder Düsseldorf, weil keine andere Aufsicht in Deutschland strengere Massstäbe anlegt. Cluster wie der Frankfurt Main Incubator als Innovationseinheit der Commerzbank, das TechQuartier am Pollux mit seinem FinTech-Schwerpunkt und das House of Finance an der Goethe-Universität liefern den Ökosystem-Kontext - inklusive der Möglichkeit, mit BaFin-Vertretern und Aufsichtspraktikern in Veranstaltungen direkt ins Gespräch zu kommen. Die Eurex- und Clearstream-Strukturen am Standort liefern zusätzlich die Marktinfrastruktur-Perspektive, in der AI-Komponenten besonders strenge Latenz- und Audit-Anforderungen erfüllen müssen. Hinzu kommt die ECB als Anker für regulatorische Diskussionen. Wer in 4-6 Wochen einen Finance Agent mit Cert-Ready Audit Trail in Frankfurt produktiv hat, hat damit das härteste Compliance-Beispiel der Republik im Portfolio. Mehr Detail zum Vorgehen unter [AI Agents Leistungen](/de/leistungen/ai-agents/).

--- AI Agents für Unternehmen in Gdansk | Gosign ---
> Enterprise AI Agents für Gdansk und die Dreistadt. Logistik, Energie, IT. EU AI Act compliant, DSGVO-konform.

## Gdańsk verbindet den größten Ostsee-Containerhafen mit einem schnell wachsenden Tech-Cluster

Gdańsk und die Dreistadt (Gdańsk, Gdynia, Sopot) sind der einzige Ort in Polen, an dem maritime Großlogistik, Raffinerie-Industrie und Tech-Outsourcing in unmittelbarer Nähe zueinander operieren. Der Port of Gdańsk ist mit Abstand der größte Container-Hafen in der Ostsee, mit Verbindungen nach Asien, Skandinavien und Westeuropa. Lotos (heute Teil der Orlen-Gruppe) betreibt hier eine der größten Raffinerien Mitteleuropas. Gleichzeitig ist Gdańsk Standort von Intel Gdańsk, Amazon Development Center Gdańsk, DNV GL, Schibsted Media Group, Kainos und Asseco. Der Gdańsk Science & Technology Park sowie der Alchemia-Komplex bilden das tech-physische Cluster. Diese Mischung aus Schwerindustrie, Hafenlogistik und Software-Engineering erzeugt regulatorische Anforderungen, die in jeder anderen polnischen Stadt nicht in dieser Kombination existieren.

## Die drei regulatorischen Hürden für AI im Gdańsk-Markt

Erstens das Urząd Morski und die maritime Regulierung: Der Hafen Gdańsk operiert unter Aufsicht der polnischen Schifffahrtsbehörde, der EU-Hafenverordnung und einer Vielzahl internationaler Übereinkommen (SOLAS, MARPOL, ISPS-Code). KI, die Containerbewegungen klassifiziert, Zolldokumente prüft oder Frachtwege optimiert, muss jede Entscheidung gegen diese Regelwerke nachvollziehbar machen. Eine Fehlklassifikation eines Gefahrgut-Containers ist nicht nur ein Compliance-Vorfall - sie ist meldepflichtig an die EU-Kommission und kann den Hafenbetrieb stoppen.

Zweitens UODO und KNF für die Banking- und Versicherungs-Operations in Gdańsk: PKO BP, Bank Pekao und mehrere Versicherer betreiben in der Dreistadt regionale Operations-Center. Bei automatisierter Antrags- und Schadenbearbeitung erwarten KNF und UODO dieselben Nachweise wie in Warschau - dokumentierte Modellgrundlagen, vollständigen Audit Trail und nachweisbare menschliche Letztentscheidung in jedem Risikofall. Bei Amazon Development Center Gdańsk gilt zusätzlich der EU AI Act für Modell-Training auf Konsumenten-relevanten Datensätzen.

Drittens der EU AI Act in Verbindung mit dem polnischen Datenschutzgesetz und sektorspezifischen Anforderungen: DNV GL als globaler Klassifikationsdienstleister vergibt Zertifikate, die in der gesamten Schifffahrtsbranche akzeptiert werden müssen. KI-gestützte Zertifikatsprüfungen fallen unter das Regime der Konformitätsbewertung des EU AI Act - sowie unter die spezifischen Anforderungen der International Maritime Organization. Wer in Gdańsk produktive KI in der Klassifikation einsetzt, braucht eine Architektur, die mehrere Aufsichten gleichzeitig bedienen kann.

## Typische Einsatzszenarien in Gdańsk

Port of Gdańsk Container-Tracking: Bei Millionen Containerbewegungen pro Jahr muss jede Klassifikation - Inhalt, Ursprung, Bestimmung, Gefahrgutstatus - korrekt und nachvollziehbar erfolgen. Document Agents extrahieren strukturierte Daten aus Frachtbriefen und Zolldokumenten, der Decision Layer routet Verdachtsfälle automatisch an menschliche Zollprüfer mit erzwungener Letztentscheidung bei Gefahrgut.

Lotos Raffinerie-Logs: Die Lotos-Raffinerie in Gdańsk erzeugt täglich Millionen Sensordatenpunkte und Wartungsmeldungen. Workflow Agents klassifizieren Anomalien nach Sicherheitsrelevanz, der Decision Layer erzwingt Human-in-the-Loop bei sicherheitskritischen Befunden und protokolliert jede Entscheidung im Audit Trail - ein expliziter Anforderungspunkt für die Aufsicht durch Wojewódzki Inspektorat Ochrony Środowiska.

Amazon Development Center Model Training Compliance: Amazons Gdańsk-Standort entwickelt Modelle für Endkunden-Anwendungen. Document Agents prüfen Trainingsdatensätze gegen UODO- und EU-AI-Act-Anforderungen, dokumentieren die Datenherkunft und blockieren automatisch die Verwendung von Datensätzen ohne ausreichende Rechtegrundlage.

DNV GL Zertifikatsprüfung: DNVs Klassifikationsfunktion in Gdańsk prüft Schiffe, Plattformen und Komponenten gegen internationale Normen. Document Agents extrahieren technische Spezifikationen, gleichen sie gegen geltende Normen ab und routen Konformitätsentscheidungen an menschliche Auditoren - der gesamte Prozess audit-fest dokumentiert.

## Wie Gosign aus Krakau Gdańsk betreut

Gosign betreut Gdańsk-Projekte aus dem Krakauer Büro (gosign.pl) mit polnischsprachigen Engineers und Projektleitern. Das Krakauer Team bedient die Trójmiasto-Region (Gdańsk, Gdynia, Sopot) mit regelmäßiger Vor-Ort-Präsenz - im Gdańsk Science & Technology Park, im Alchemia-Cluster und direkt bei den Stakeholdern des Port of Gdańsk, Lotos, Intel Gdańsk, Amazon Development Center und DNV GL. Discovery findet zweitägig vor Ort statt, mit polnischsprachigen Fachverantwortlichen, Compliance-Funktion und einem Vertreter der Rada Zakładowa am Tisch. Build und Sprint Reviews laufen anschließend mit dem Krakauer Team, polnisch und englisch, mit monatlichen Vor-Ort-Steerings in der Dreistadt und kurzfristiger Anreise bei Eskalationen mit Urząd Morski oder Zollbehörden. Die maritime Logistik-Erfahrung des Krakauer Teams trifft auf die Hamburger Architektur- und Hafen-Compliance-Expertise - die Hamburger Zentrale liefert die Anbindung an HPA, deutschen Zoll und EU-Hafenverordnung, Krakau die operative Delivery in polnischer Hafenrealität.

## Warum Gdańsk als Startpunkt für Enterprise AI funktioniert

Gdańsk ist der schwierigste polnische AI-Markt, weil die regulatorische Landschaft die kompliziertste ist - Hafenbehörde, KNF, UODO, EU AI Act und internationale Schifffahrtsregulierung greifen ineinander. Genau das macht Gdańsk zum idealen Stresstest. Wer einen AI Agent baut, der die Anforderungen des Port of Gdańsk erfüllt, hat eine Architektur entwickelt, die in praktisch jedem anderen logistikintensiven EU-Markt funktioniert. Der Gdańsk Science & Technology Park und das Alchemia-Cluster bieten Engineers mit dieser Multi-Domain-Expertise, die Politechnika Gdańska liefert kontinuierlich Nachwuchs.

Für deutsche Mittelständler mit Ostsee-Logistik ist Gdańsk häufig der erste Auslandsstandort, an dem Enterprise AI tatsächlich gebraucht wird - und damit der Ort, an dem sich die Architektur das erste Mal in echtem regulatorischen Wind beweisen muss. Die Hamburg-Gdańsk-Achse verbindet zwei der wichtigsten Ostsee-Häfen Europas - was in Hamburg an Compliance-Erfahrung mit der HPA, dem deutschen Zoll und der EU-Hafenverordnung vorhanden ist, lässt sich direkt auf Gdańsk übertragen. Eine erfolgreiche Implementierung in Gdańsk öffnet damit nicht nur den polnischen Markt, sondern liefert eine Architektur-Blaupause, die in [Warschau](/de/ai-agents-warschau/), [Krakau](/de/ai-agents-krakau/) und [Wrocław](/de/ai-agents-wroclaw/) ohne große Anpassungen ausgerollt werden kann. Cert-Ready by Design bedeutet hier konkret: Eine Plattform, die unter dem strengsten Regulierungsdruck Polens ihre Tauglichkeit bewiesen hat. Mehr Kontext zu unserem Vorgehen in Polen finden Sie auf der [Polen-Übersicht](/de/ai-agents-polen/).

--- AI Agents für Unternehmen in Großbritannien | Gosign ---
> Enterprise AI Agents für britische Unternehmen. UK-DSGVO-konform, EU AI Act ready für EU-Geschäft. Auditierbare KI für UK und EU gleichzeitig.

## Großbritannien hat den einzigen EU-nahen Markt mit zwingender Dual-Regulation

Großbritannien ist der einzige große europäische Wirtschaftsraum, in dem jedes mittlere bis große Unternehmen mit kontinentalem Geschäft seine KI-Systeme gleichzeitig gegen zwei unabhängige Regulierungsregime auditierbar machen muss. Auf britischer Seite stehen UK GDPR, das ICO als Datenschutzaufsicht, FCA und PRA für Finanzdienstleister, Ofcom für Telekommunikation und Medien sowie die CMA für Wettbewerb. Auf EU-Seite gelten weiterhin DSGVO und EU AI Act für jeden Datensatz, der EU-Kunden, EU-Mitarbeiter oder EU-Tochtergesellschaften betrifft. HSBC, Barclays, Lloyds und NatWest betreiben Konzernfunktionen, die beide Welten parallel bedienen. BP, Shell, AstraZeneca, GSK und Unilever verarbeiten täglich Daten, die mal in der UK-Jurisdiktion und mal in der EU-Jurisdiktion landen. Tesco, Sainsbury's, BT, Vodafone, ITV und BBC stehen vor derselben Realität in nationalem Maßstab. Die Schauplätze verteilen sich auf London, Manchester, Edinburgh, Glasgow, Birmingham, Leeds und Bristol - aber das regulatorische Problem ist überall dasselbe.

## Die drei regulatorischen Hürden für AI im UK-Markt

Erstens UK GDPR und die ICO-Aufsicht: Nach Brexit gilt im UK das UK GDPR als nationales Datenschutzrecht, beaufsichtigt durch das Information Commissioner's Office. Bei automatisierter Entscheidungsfindung erwartet das ICO dokumentierte Modellgrundlagen, Auskunftsfähigkeit gegenüber Betroffenen und einen vollständigen Audit Trail. Die geplante Data Protection and Digital Information Bill wird einige UK-spezifische Erleichterungen einführen, ohne die Kernanforderungen aufzuheben. Wer Daten zwischen UK und EU bewegt, braucht zusätzlich einen passenden Adequacy- oder SCC-Rahmen - ein Compliance-Layer, den keine andere europäische Jurisdiktion in dieser Form fordert.

Zweitens FCA, PRA und Bank of England für den Finanzsektor: HSBC, Barclays, Lloyds und NatWest stehen unter direkter FCA- und PRA-Aufsicht. Die FCA hat in mehreren Veröffentlichungen klargemacht, dass sie bei KI-gestützten Entscheidungen in Kreditvergabe, Underwriting, AML und Conduct-Risk dieselben Erklärbarkeits- und Aufsichtsstandards erwartet wie für menschliche Entscheidungen. Der UK-spezifische Ansatz: Statt eines einheitlichen KI-Gesetzes wie der EU AI Act setzt das UK auf sektorspezifische Regulierung - die FCA legt die Standards für Finance fest, das ICO für Datenschutz, Ofcom für Kommunikation. Wer als britischer Konzern KI in mehreren Sektoren einsetzt, hat es mit unterschiedlichen Erwartungen pro Regulator zu tun.

Drittens der EU AI Act für jedes UK-Unternehmen mit EU-Geschäft: Der EU AI Act gilt nicht nur für EU-Unternehmen. Jedes britische Unternehmen, das KI-Outputs in der EU bereitstellt - sei es über eine deutsche Tochter, eine niederländische Niederlassung oder einen direkten Vertrieb an EU-Kunden - fällt unter den extraterritorialen Anwendungsbereich des EU AI Act. Das bedeutet: HSBC braucht für sein deutsches Privatkundengeschäft EU-AI-Act-Konformität. Unilever braucht sie für jeden Konsumenten-Algorithmus, der in der EU ausgespielt wird. AstraZeneca braucht sie für klinische Entscheidungsunterstützung in EU-Studienzentren. Eine UK-only-Architektur reicht für keinen dieser Konzerne.

## Typische Einsatzszenarien in Großbritannien

HSBC und Barclays Conduct-Risk-Monitoring: Die britischen Großbanken stehen unter doppelter FCA- und ESMA-Aufsicht. Document Agents extrahieren Compliance-relevante Aussagen aus Kundeninteraktionen, der Decision Layer routet Verdachtsfälle entlang der jeweiligen jurisdiktionsspezifischen Schwellen, mit Human-in-the-Loop bei jeder Eskalation und einem Audit Trail, der sowohl FCA als auch ESMA vorgelegt werden kann.

BP und Shell HSE-Operations: Die globalen Energie-Konzerne erzeugen täglich Tausende Sicherheits- und Umweltberichte. Workflow Agents klassifizieren Vorfälle nach Schwere, Region und meldepflichtigen Aspekten - mit unterschiedlichen Eskalationspfaden je nach Standort (UK HSE, EPA, BNetzA, polnische OUG).

AstraZeneca und GSK Pharmacovigilance: Die UK-Pharma-Konzerne betreiben EU-weite klinische Studien. Document Agents prüfen Adverse-Event-Berichte, klassifizieren sie nach MHRA- und EMA-Anforderungen und routen kritische Befunde an menschliche Pharmacovigilance-Verantwortliche - jede Entscheidung gegen den jeweils geltenden Regulierungsstandard auditierbar.

Unilever und Tesco Konsumenten-Algorithmen: Die globalen Konsumgüter- und Retail-Konzerne setzen KI in Empfehlung, Pricing und Promotion ein. Decision Agents prüfen jede ausgespielte Entscheidung gegen UK-Consumer-Protection-Standards und EU AI Act gleichzeitig, mit nachvollziehbaren Begründungen für ICO und Verbraucher-Aufsicht.

## Wie Gosign aus Hamburg Großbritannien betreut

Gosign betreut UK-Projekte vom Hamburger Hauptsitz aus. Die Kombination aus EU-Regulierungsexpertise und Hamburger Lage ist für britische Konzerne mit EU-Geschäft kein Nachteil, sondern Voraussetzung - gerade die Dual-Regulation lässt sich nur sauber bauen, wenn beide Welten von einem Team gleichzeitig verstanden werden. Discovery findet vor Ort in London, Manchester oder Edinburgh statt, je nach Konzernstandort. Anschließend läuft der Build remote, mit englischsprachiger Dokumentation, wöchentlichen Sprint Reviews per Video und einem festen Ansprechpartner in Hamburg. Vor-Ort-Termine erfolgen alle vier bis sechs Wochen, der Direktflug Hamburg-London dauert etwas über eine Stunde fünfzehn. Vor-Ort-Termine bei FCA, PRA oder ICO begleitet Gosign auf Anfrage gemeinsam mit der internen Rechtsabteilung des Kunden.

## Warum Großbritannien als Startpunkt für Enterprise AI funktioniert

Kein anderes Land in Europa zwingt Konzerne in derselben Konsequenz zur jurisdiktionsspezifischen Regelarchitektur. Wer einen AI Agent baut, der UK GDPR, FCA-Standards und EU AI Act gleichzeitig erfüllt, hat eine Architektur entwickelt, die in praktisch jedem westlichen Markt nur noch eine Konfigurationsänderung weit ist. Genau hier setzt Gosigns Decision Layer mit jurisdiktionsspezifischen Regelsätzen an: Statt zwei parallele Systeme zu betreiben, läuft eine Plattform mit zwei Regelwerken - UK im Inlands-Routing, EU im EU-Routing, und ein Audit Trail, der je nach Empfänger den richtigen Regelsatz dokumentiert. Für britische Konzerne mit EU-Geschäft ist das die einzige Architektur, die sich nicht spätestens beim ersten ICO- oder ESMA-Audit als Sackgasse erweist. Cert-Ready by Design bedeutet hier wörtlich: Bereit für zwei Zertifizierungen, auf einer einzigen Codebasis. Mehr Kontext zum [EU AI Act](/de/governance/eu-ai-act/) und seiner extraterritorialen Wirkung gibt es im Governance-Bereich.

--- Die Hanseatische Akte - 492.000 Euro HmbBfDI-Bußgeld forensisch analysiert | Gosign ---
> Forensische Analyse: Wie eine Hamburger Bank 2025 ein 492.000-Euro-Bußgeld der HmbBfDI bekam und warum Decision-Layer-Architektur die einzige Antwort ist.

## Was bedeutet HmbBfDI-konforme KI in Hamburg?

Wenn Software über Menschen entscheidet, muss das verarbeitende Unternehmen die zugrundeliegenden Gründe verständlich erklären können. Auf diesen Satz hat die Hamburgische Datenschutzaufsicht 2025 ein Bußgeld von 492.000 Euro gegen ein Finanzunternehmen gestützt, das Kreditkarten-Anträge automatisiert abgelehnt hat ([HmbBfDI Tätigkeitsbericht 2025](https://datenschutz-hamburg.de/service-information/taetigkeitsberichte/taetigkeitsbericht-datenschutz-2025)). Im September 2025 hat dieselbe Behörde gemeinsam mit dem ULD Schleswig-Holstein den [**Bridge Blueprint**](https://datenschutz-hamburg.de/fileadmin/user_upload/HmbBfDI/Datenschutz/Informationen/DE-Bridge-Blueprint-v.0.9.pdf) publiziert - eine Übersetzung von DSGVO und EU AI Act in technische Architektur-Anforderungen.

Anhang III der KI-Verordnung erfasst Personalentscheidungen, Kreditwürdigkeitsprüfung und Lebens- bzw. Krankenversicherungs-Risikobewertung als Hochrisiko-AI ([Verordnung (EU) 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/oj/deu), Bußgeldrahmen Art. 99: bis 15 Mio Euro / 3% Konzernumsatz). Die zugehörigen Pflichten greifen nach aktuellem Recht ab dem 2. August 2026, voraussichtlich verschoben auf den 2. Dezember 2027 (Digital Omnibus, Mai 2026, formale Verabschiedung ausstehend); die Hochrisiko-Einstufung bleibt in jedem Fall bestehen. Eine KI-Architektur, die durch eine HmbBfDI-Prüfung kommt, kommt durch jede andere EU-Landesaufsicht durch.

## Was ist eine Decision-Layer-Architektur?

Der Decision Layer ist die Steuerungsschicht zwischen KI-Agent und Zielsystem. Er zerlegt jeden Geschäftsprozess in einzelne Entscheidungsschritte und definiert pro Schritt vorab: **MENSCH** bei Ermessen und Mitbestimmung. **REGELWERK** wenn deterministisch (Tarifvertrag, IMDG-Klasse, Frist). **KI AUTONOM** bei Konfidenz über Schwellwert. Bei niedriger Konfidenz oder hohem Risiko: Eskalation an den Menschen, technisch erzwungen.

<img src="/images/diagrams/decision-layer-drei-arten.svg" alt="Drei Autonomiestufen im Decision Layer: Mensch entscheidet bei Personalstrategie und Performance Reviews, Agent arbeitet und Mensch prüft bei Belegverarbeitung und Vertragsprüfung, Agent selbstständig bei FAQ und Standardbescheinigungen." width="900" height="360" class="w-full mt-6 rounded-card" loading="lazy" />

In Hamburg muss dasselbe Skelett Bills of Lading nach Unionszollkodex, Service Bulletins nach EASA Part-145 und Solvency-II-Reports nach BaFin-MaRisk verarbeiten - drei Aufsichtswelten, ein Pattern. [Decision Layer im Detail](/de/decision-layer/).

## Welche Compliance-Frames muss eine Hamburger AI-Architektur abdecken?

| Branche | Hamburg-Cluster | Compliance-Frame | Use-Case |
|---------|-----------------|------------------|----------|
| Linienreedereien | Speicherstadt, HafenCity | UCC (EU 952/2013), IMDG, EU-MRV | Bills of Lading, Manifeste |
| MRO Luftfahrt | Fuhlsbüttel | EASA Part-145, Part-66 | Service Bulletins, Maintenance |
| Aerospace Final Assembly | Finkenwerder | EASA Part-21, AS9100 | Konfigurations-Doku |
| Marine- und Cargo-Versicherung | Adolphsplatz | Solvency II, IFRS 17 | Underwriting, Schaden-Triage |
| Konsumgüter (Kosmetik / FMCG) | Eimsbüttel, Hammerbrook | Kosmetikverordnung 1223/2009 | Inhaltsstoffe, Etiketten |
| Medtech-Endoskopie | Hamburg-Mitte | MDR EU 2017/745, IEC 62304 | Vigilance, Service-Tickets |

Über alle sechs liegen horizontal die DSGVO und der EU AI Act - dessen Hochrisiko-Pflichten nach aktuellem Recht ab dem 2. August 2026 greifen, voraussichtlich verschoben auf Dezember 2027 (Digital Omnibus, Mai 2026) - mit dem HmbBfDI Bridge Blueprint als Hamburger Lese-Brücke.

## Modellrechnung - Tagesvolumen und Decision-Split

Plausibilitätsannahmen aus branchenüblichen Größenordnungen ([HHLA-Statistik](https://hhla.de/en/media/news/detail-view/hhla-achieves-significant-revenue-and-earnings-growth-despite-difficult-conditions)) - keine garantierten Kennzahlen, sondern strukturelle Anhaltspunkte:

| Use-Case | Tagesvolumen | REGELWERK | KI AUTONOM | MENSCH |
|----------|--------------|-----------|------------|--------|
| Bills of Lading - Reederei mit 200 Schiffen | 12.000 Vorgänge | 75% | 20% | 5% |
| Service Bulletins - MRO mit 800 Mechanikern | 200 Verteilungen | 60% | 30% | 10% |
| Solvency-II-Schadentriage - Marine-Versicherung | 60 Fälle | 40% | 35% | 25% |
| MDR-Vigilance - Medtech, 64 Länder | 80 Tickets | 50% | 30% | 20% |
| HR-Personalmaßnahmen - DAX-Konzern, 10.000 MA | 400 Vorgänge | 35% | 15% | 50% |

Audit-Trail pro Vorgang: Regel-Version, Input-Hash, Confidence-Score, Eskalations-Pfad. Bei einem Hauptzollamt-Termin oder einer EASA-Beanstandung wandert nicht das Resultat über den Tisch, sondern der Pfad.

## Engineering und Workshop in Hamburg

Hauptsitz Hallerstraße 8 in 20146 Hamburg für Engineering, Governance und Geschäftsführung. Schulungszentrum am Grindelberg 77, 1,2 km entfernt - separater Raum für Discovery-Workshops, Betriebsrats-Sessions und Auditor-Trainings. Vor-Ort-Termine in HafenCity, Adolphsplatz, Finkenwerder oder Fuhlsbüttel im selben Tag erreichbar.

Voller Zugang zu Quellcode, Prompts, Regelwerken und Decision-Records mit vertraglich zugesicherter Repository-Übergabe an den Kunden. Nach 12-18 Monaten Self-Service. Gosign GmbH ist seit Gründung in Hamburg ansässig - 25 Jahre Softwareentwicklung, rund 108 Mitarbeitende (Stand 2026), Referenzen aus Aerospace, Automotive und Energie ([Übersicht](/de/referenzen/)). Für gehobenen Mittelstand ab 500 Mitarbeitenden bis DAX-Konzern.

Andere versprechen DSGVO-Konformität als Verkaufsargument. Wir bauen Decision-Records, die die HmbBfDI im Klartext liest. [Discovery-Workshop am Grindelberg vereinbaren](/de/kontakt/).

--- AI Agents für Unternehmen in Hannover und Niedersachsen | Gosign ---
> Enterprise AI Agents für Hannover und Niedersachsen. Auditierbar, betriebsratskompatibel, EU AI Act compliant. 90 Min. von Hamburg.

## Hannover ist der Standort, an dem zweiter weltgrösster Rückversicherer, grösster deutscher Industriezulieferer und globale Messewirtschaft denselben Bahnhof teilen

Im Korridor zwischen Hauptbahnhof, Messegelände und List-Süd sitzen Continental als zweitgrösster deutscher Automobilzulieferer mit Konzernzentrale, Hannover Rück als nach Munich Re zweitgrösster Rückversicherer der Welt, HDI als Erstversicherungsschiene des Talanx-Konzerns, TUI als grösster europäischer Reisekonzern und VW Nutzfahrzeuge mit dem grössten Werk in Stöcken. Hinzu kommen Sennheiser in Wedemark, Enercon in Aurich als grösster deutscher Windkraftanlagen-Hersteller und die Deutsche Messe AG mit Hannover Messe und CeBIT-Erbe. Diese Mischung erzeugt eine spezifische AI-Marktstruktur: Konzerne mit hoher Compliance-Last treffen auf einen breiten technischen Mittelstand, der konkrete Automatisierungspotenziale hat, aber Enterprise-Governance braucht. Der Niedersächsische Markt ist nach NRW und Bayern das drittgrösste Industrieland der Republik.

## Drei regulatorische Hürden, die im hannoverschen Markt jede AI-Initiative bestimmen

Die erste Hürde ist die Versicherungsaufsicht für die Talanx-Gruppe und Hannover Rück. BaFin-Anforderungen an Modellrisiko, Solvency-II-Reporting und die spezifischen ORSA-Anforderungen für Rückversicherer treffen jede AI-Komponente in Underwriting, Reservierung und Cat-Modellierung. Hannover Rück arbeitet im Tagesgeschäft mit Modellen für Naturkatastrophen-Portfolios und Pandemie-Szenarien, deren Validierung höchsten Massstäben unterliegt und deren AI-Komponenten gegen interne Modellrisiko-Frameworks verteidigt werden müssen. Die zweite Hürde ist das Bundes-Immissionsschutzgesetz BImSchG, das für Continental als grosser Industrieproduzent und für Enercon als Windkraftbetreiber im Tagesgeschäft relevant ist - jede AI-Komponente in der Emissionsüberwachung oder Anlagensteuerung muss in der BImSchG-Genehmigungslogik nachweisbar sein. Die dritte Hürde ist die starke IG-Metall-Mitbestimmung in den Continental- und VW-Werken sowie bei Sennheiser - eine AI-Anwendung mit Personenbezug oder Leistungserfassung passiert die Betriebsräte nur dann, wenn der [Decision Layer](/de/decision-layer/) die menschliche Letztentscheidung erzwingt und der Audit Trail die Begründung dokumentiert. Mehr zum Rahmen unter [Governance EU AI Act](/de/governance/eu-ai-act/).

## Typische Einsatzszenarien in Hannover

Bei Continental sehen wir Qualitätsdaten-Agenten in der Reifenproduktion, die Messdaten aus mehreren Werken konsolidieren und Auffälligkeiten an Quality-Engineers eskalieren - mit nachvollziehbarer Bewertung. Im VW-Nutzfahrzeuge-Werk in Stöcken arbeiten Agenten an Produktionsplanungs- und Lieferantenmanagement-Use-Cases, in denen ein Production Steering die Letztentscheidung trifft. Bei HDI und Hannover Rück unterstützen Agenten die Schadenregulierung und das Cat-Modelling - der Agent reichert die Modellergebnisse mit Vertragsdaten und externen Quellen an, die Underwriter entscheiden. Bei TUI helfen Customer-Service-Agenten bei der Strukturierung von Kundenanliegen und der Priorisierung von Rückrufen. Bei Sennheiser und im weiteren Mittelstand sehen wir Document-Agenten für Eingangsrechnungen, Vertragsanalyse und Lieferantenkommunikation - der typische Einstieg, wenn ein konkreter Engpass im Rechnungswesen automatisiert werden soll. Bei Enercon arbeiten Agenten an Predictive-Maintenance-Vorbereitungen für Windkraftanlagen, bei denen Service-Techniker entscheiden, wann ein Komponentenwechsel erfolgt - der Agent strukturiert die Sensordaten, der Service-Manager entscheidet über das Wartungsfenster. Bei der Deutschen Messe AG sehen wir Knowledge-Agenten in der Aussteller- und Besucherbetreuung, die wiederkehrende Anfragen strukturieren und an die Messeplanung übergeben. Die Niedersächsische Landesförderbank NBank arbeitet mit Document-Agenten in der Antragsprüfung von KI-Förderprojekten - hier hilft ein Agent bei der strukturierten Aufbereitung der Antragsunterlagen für die Sachbearbeiter. In jedem Fall hält der Audit Trail die Begründungskette fest.

## Wie Gosign aus Hamburg Hannover betreut

Hannover ist der nächste grosse deutsche Markt zu unserem Hamburger Hauptsitz - die ICE-Direktverbindung Hamburg-Hannover braucht knapp 90 Minuten. Vor-Ort-Termine sind tagesaktuell machbar. Konkret heisst das: Discovery-Workshops mit Engineering, Compliance und Mitbestimmung führen wir vor Ort durch, oft als ein- bis zweitägiger Block. In der Engineering-Phase kombinieren wir remote-Arbeit mit wöchentlichen Vor-Ort-Tagen, weil die kurze Anreise das ohne logistische Hürden möglich macht. Architektur-Reviews, Modellvalidierungen für Solvency II und Mitbestimmungs-Verhandlungen finden vor Ort statt. Für Continental und Hannover Rück mit Konzernzentralen in der Hannoverschen Innenstadt sind wir oft mehrfach pro Monat vor Ort - die Nähe macht die Vor-Ort-Frequenz nicht zu einem logistischen Problem. Cluster wie Hannover Impuls als Wirtschaftsförderung der Landeshauptstadt und das Innovationsnetzwerk Niedersachsen nutzen wir für technische Diskussionen und für Kontakte zur NBank, die viele KI-Projekte im niedersächsischen Mittelstand begleitet. Die Hannover Messe als grösste Industriemesse der Welt liefert jährlich einen kompakten Marktüberblick und ist für viele unserer Kundenprojekte ein natürlicher Anker für Produktentscheidungen.

## Warum Hannover als Startpunkt für Enterprise AI funktioniert

Hannover hat eine Eigenschaft, die in keinem anderen deutschen Markt existiert: die Kombination aus Konzernzentralen mit hoher Compliance-Last und einem breiten technischen Mittelstand, der nicht nur als Lieferkette der Konzerne fungiert, sondern eigene globale Märkte bedient. Wer hier einen ersten AI Agent produktiv stellt, hat ihn typischerweise gegen Versicherungs-Compliance, Industrie-Mitbestimmung und Mittelstands-Pragmatismus getestet - die drei härtesten Stresstests, die der deutsche Markt zu bieten hat. Hinzu kommt die geographische Lage: 90 Minuten nach Hamburg, zwei Stunden nach Berlin, drei Stunden nach Frankfurt. Hannover ist damit der natürliche Anker für eine multi-regionale Skalierung im DACH-Raum. Das ML-Engineering-Talent kommt von der Leibniz Universität Hannover mit ihrer starken Informatik-Fakultät, vom L3S-Forschungszentrum mit Schwerpunkt auf Web Science und ML, und vom DFKI-Standort als Anker für angewandte KI-Forschung. Wer in 4-6 Wochen einen Agent in einem Hannoverschen Konzern oder Mittelständler produktiv hat, profitiert von der Nähe zum Hamburger Engineering und kann den Use Case anschliessend in das gesamte Norddeutschland-Netzwerk übertragen. Mehr zum Vorgehen unter [AI Agents Leistungen](/de/leistungen/ai-agents/).

--- AI Agents für Unternehmen in Köln | Gosign ---
> Enterprise AI Agents für Köln. Medien, Handel, Versicherungen - auditierbare AI für dokumentenintensive Branchen. EU AI Act compliant by design.

## Köln ist der einzige deutsche Standort, an dem europäische Luftfahrtaufsicht, Lebensmittel-Bundesbehörde und private Medienkonzerne im Tagespendelradius zusammenliegen

Im Korridor zwischen Köln-Bonn-Flughafen, Innenstadt und Mediapark sitzen RTL Deutschland als grösster privater TV-Konzern Europas, Ford-Werke in Niehl mit dem zweitgrössten europäischen Ford-Werk, Rewe Group mit dem Konzernsitz in Stolwerk-Nähe, DEVK und Gothaer als zwei grosse Kölner Versicherer und Toyota Deutschland in Köln-Marsdorf. Der TÜV Rheinland sitzt in Köln und ist eine der wichtigsten europäischen Zertifizierungsstellen. Im benachbarten Köln-Bonn liegt die EASA als europäische Luftfahrtbehörde, in Bonn das BLE als Bundesanstalt für Landwirtschaft und Ernährung. Die Lufthansa hat ihren Stammsitz in Köln-Deutz. Diese Kombination aus Industrie, Medien, Versicherung und mehreren regulatorischen Akteuren erzeugt einen Markt, in dem dokumentenintensive Prozesse und auditierbare Entscheidungen Tagesgeschäft sind.

## Drei regulatorische Hürden, die im Kölner Markt jede AI-Initiative formen

Die erste Hürde ist die Versicherungsaufsicht für DEVK, Gothaer und die hier angesiedelten Rückversicherungs-Töchter. BaFin-Anforderungen an Modellrisiko und Solvency-II-Berichterstattung gelten für jede AI-Komponente in Schadenregulierung, Tarifierung oder Reservierung. Die zweite Hürde ist der Medien- und Daten-Compliance-Block bei RTL und vergleichbaren Adressaten - der Medienstaatsvertrag, die DSGVO-Spezifika für werbefinanzierte Plattformen und der Digital Services Act setzen klare Grenzen, was AI in der Empfehlungs- und Moderations-Logik leisten darf. Die dritte Hürde ist EASA-relevant für Lufthansa und ihre MRO-Partner: Continuing Airworthiness, Part-145-Wartung und Part-M-Anforderungen müssen für AI-Komponenten im Wartungsumfeld in einer auditierbaren Modellhistorie nachgewiesen werden. Hinzu kommt der TÜV Rheinland selbst als zertifizierender Akteur, der für viele EU-AI-Act-relevante Konformitätsbewertungen die fachliche Adresse ist - eine Beziehung, die Kölner Unternehmen früh aufbauen sollten, weil die Konformitätsbewertung von Hochrisiko-AI-Systemen in der Verantwortung benannter Stellen wie dem TÜV liegt. Auch das BLE in Bonn als Bundesanstalt für Landwirtschaft und Ernährung ist für REWE und vergleichbare Lebensmittelhändler relevant, wenn AI-Komponenten in Sortimentssteuerung oder Lieferanten-Bewertung Anwendung finden. Wer in Köln eine AI-Architektur baut, plant [Cert-Ready by Design](/de/governance/eu-ai-act/) als Standard.

## Typische Einsatzszenarien in Köln

Bei REWE Group und im weiteren Lebensmittelhandel sehen wir Sortiments- und Lieferketten-Agenten, die regionale Verkaufszahlen, Saisonalität und Lieferantendaten zu einem Vorschlag für den Category Manager verdichten - mit klarer Dokumentation, weil Lebensmittelhandel unter LMIV-Anforderungen und unter dem Lieferkettengesetz gleichzeitig steht. Bei den Ford-Werken arbeiten Agenten an Produktionsplanungs- und Qualitätsdaten-Use-Cases, in denen ein Production Engineer die Letztentscheidung trifft. Im Versicherungsumfeld bei DEVK und Gothaer unterstützen Agenten die Schadenregulierung mit strukturierter Anreicherung der Schadensmeldung um Vertrag, Historie und Sachverständigengutachten. RTL Deutschland und Lanxess (für Kunststoff- und Spezialchemie-Compliance) brauchen Document-Agenten für Vertragsanalyse und Sicherheitsdatenblätter. Beim TÜV Rheinland selbst sind Knowledge-Agenten für die Verwaltung von Prüfdokumentation und Normentexten relevant - mit klarer Versionierung und Audit Trail. Die Lufthansa und ihre MRO-Tochter Lufthansa Technik (mit Hauptsitz in Hamburg, aber Verbindungen nach Köln) arbeiten mit Document-Agenten an der Vorbereitung von Wartungsdokumentation, in denen ein Continuing Airworthiness Manager die Letztentscheidung trifft. Bei Toyota Deutschland in Köln-Marsdorf sehen wir Service-Ticket-Agenten und im Recall-Management eine Anreicherungslogik, die VIN-Daten, Werkstatthistorie und Lieferanten-Compliance kombiniert. Bei der DEVK als grossem Kfz-Versicherer in Köln sind Schadenregulierungs-Agenten besonders relevant, weil das Schadenvolumen aus Kraftfahrt-Haftpflicht hohe Bearbeitungseffizienz erzwingt. Die Letztentscheidung trifft in jedem Fall ein qualifizierter Prüfingenieur, der [Decision Layer](/de/decision-layer/) hält Begründung und Pfad fest.

## Wie Gosign aus Hamburg Köln betreut

Gosign hat keinen Kölner Standort - die Vor-Ort-Begleitung organisieren wir aus Hamburg und Berlin. Die ICE-Direktverbindung Hamburg-Köln ist eine der schnellsten der Republik, Vor-Ort-Termine sind innerhalb des Tages umsetzbar. Konkret läuft das so: Discovery-Workshops mit Engineering, Compliance und Mitbestimmung machen wir vor Ort in Köln-Mediapark, am Rheinufer oder direkt beim Kunden - meist als zwei- bis dreitägiger Block. In der Engineering-Phase kombinieren wir remote-Arbeit mit zweiwöchentlichen Vor-Ort-Tagen für Architektur-Reviews und Stakeholder-Updates. TÜV-Rheinland-Briefings für die EU-AI-Act-Konformitätsbewertung passieren immer vor Ort, weil hier die Auditoren-Beziehungen entstehen, die später bei der Konformitätsbewertung helfen. Cluster wie der Mediapark, der Startplatz Köln und das KI-Netzwerk der IHK Köln (der grössten Industrie- und Handelskammer Deutschlands) sind aktive Räume für technisches Networking, für Auditor-Sessions und für Kontakte in den rheinischen Mittelstand. Die Entfernung Köln-Bonn ist klein genug, dass EASA-relevante Termine im selben Tag mitgenommen werden können - eine Logistik, die für luftfahrtnahe Use Cases einen klaren Vorteil bietet.

## Warum Köln als Startpunkt für Enterprise AI funktioniert

Wer in Köln einen AI-Use-Case in Produktion bringt, hat den Vorteil, dass er ihn an einem der wichtigsten europäischen Zertifizierungsstandorte verteidigt - der TÜV Rheinland sitzt vor Ort und ist für viele EU-AI-Act-Konformitätsbewertungen die natürliche Adresse. Das beschleunigt die spätere Skalierung erheblich, weil die Audit-Beziehung früh aufgebaut wird. Hinzu kommt die Branchen-Vielfalt - Medien, Handel, Versicherung, Chemie, Automotive - die als Test für die Übertragbarkeit einer AI-Architektur in unterschiedliche Compliance-Regime dient. Köln ist ausserdem geographisch nah an Düsseldorf, Bonn und dem Rhein-Main-Gebiet, was multi-regionale Stakeholder-Termine vereinfacht. Wer in 4-6 Wochen einen ersten Document Agent mit vollständigem Audit Trail in einem Kölner Konzern produktiv hat, hat damit eine Referenz, die der TÜV Rheinland kennt - was die spätere Konformitätsbewertung vereinfacht. Mehr zum Vorgehen unter [AI Agents Leistungen](/de/leistungen/ai-agents/).

--- AI Agents für Unternehmen in Krakau | Gosign ---
> Enterprise AI Agents in Krakau. Lokale Projektleitung, EU AI Act compliant by design, DSGVO-konform. Vom PoC zum eigenständigen Betrieb.

## Krakau ist Polens Shared-Service-Hauptstadt - und genau deshalb der schwierigste KI-Standort

Krakau beherbergt die größte Konzentration von Global Capability Centers in Mitteleuropa. ABB Krakow betreibt hier seine globale Engineering-Dokumentation, Cisco Krakow eine der größten Software-Entwicklungsabteilungen außerhalb der USA, IBM Krakow ein Delivery Center mit Tausenden Beratern, dazu ING Hubs Kraków, Capgemini, Motorola Solutions, EY GDS und der polnische IT-Konzern Comarch. Was diese Standorte gemeinsam haben: Sie verarbeiten Daten aus mehreren EU-Jurisdiktionen, ihre Outputs landen in den Büchern westeuropäischer Mutterkonzerne, und jede KI-Entscheidung muss gleichzeitig dem polnischen UODO, der RODO-Umsetzung und den Regulatoren der Mutterländer standhalten. Krakau ist nicht nur eine polnische Stadt - es ist das Maschinenraum vieler europäischer Konzerne.

## Die drei regulatorischen Hürden für AI im Krakau-Markt

Erstens RODO und das polnische Gesetz über den Schutz personenbezogener Daten (ustawa o ochronie danych osobowych): Das UODO (Urząd Ochrony Danych Osobowych) erwartet bei automatisierter Entscheidungsfindung dokumentierte Grundlagen, abrufbare Erklärungen und einen vollständigen Audit Trail. Da Krakauer GCCs Daten aus Deutschland, Frankreich, den Niederlanden und Skandinavien verarbeiten, muss jede KI-Entscheidung auch den jeweiligen nationalen Aufsichtsbehörden standhalten - eine Architektur, die nur RODO erfüllt, ist für Konzern-Shared-Services nicht ausreichend.

Zweitens KNF-Aufsicht für die wachsende Zahl an Banking- und Insurance-Operations in Krakau: ING Hubs Kraków, Aon, Brown Brothers Harriman und weitere Finanzdienstleister stehen unter direkter oder indirekter Aufsicht der Komisja Nadzoru Finansowego. Bei Transaction Monitoring, AML-Screening und Underwriting-Vorschlägen erwartet die KNF dieselben Nachweise wie die BaFin oder die niederländische DNB - inklusive nachvollziehbarer Modellgrundlagen und protokollierter menschlicher Letztentscheidung.

Drittens der EU AI Act, der in Polen seit Februar 2025 für verbotene Praktiken greift; für Hochrisiko-Systeme gelten die Pflichten nach aktuellem Recht ab dem 2. August 2026, voraussichtlich verschoben auf den 2. Dezember 2027 (Digital Omnibus, Mai 2026, formale Verabschiedung ausstehend): HR-Screening, Kreditwürdigkeitsbewertung und biometrische Identifikation fallen in die Hochrisiko-Kategorie. Krakauer Standorte, die solche Systeme für Mutterkonzerne entwickeln oder betreiben, müssen Konformitätsbewertungen, Risikomanagement und post-market monitoring nachweisen können - eine technische Schuld, die nachträglich kaum aufzuholen ist.

## Typische Einsatzszenarien in Krakau

Comarch Banking Software QA: Comarchs Banking-Suite wird von Hunderten polnischer und mitteleuropäischer Finanzinstitute eingesetzt. Document Agents prüfen Release-Notes, regulatorische Updates und Patch-Dokumentation gegen die KNF-Anforderungen, bevor ein Release ausgeliefert wird - mit vollständigem Audit Trail bis zur Quell-PR.

ABB Krakow Engineering-Dokumentation: ABBs globales Engineering-Center in Krakau erzeugt täglich Tausende technischer Dokumente in mehreren Sprachen. Workflow Agents extrahieren regulatorisch relevante Spezifikationen, gleichen sie gegen länderspezifische Normen ab und routen Konflikte automatisch an menschliche Reviewer.

ING Hubs Transaction Monitoring: Bei einem ING-Shared-Service mit Millionen Transaktionen pro Tag entscheidet jede Sekunde Verzögerung über regulatorische Meldepflichten. Der Decision Layer routet Verdachtsfälle innerhalb der KNF- und DNB-Schwellen, mit erzwungenem Human-in-the-Loop bei jeder finalen Eskalation.

Capgemini Delivery-Operations: Krakauer Delivery-Teams betreuen Großkunden in mehreren EU-Ländern. Service-Desk-Routing-Agents klassifizieren Tickets nach Sprache, Mandant und Eskalationspfad - jede Entscheidung gegen den jeweils geltenden Regulierungsstandard auditierbar.

## Wie Gosign von Krakau aus Polen betreut

Gosign hat ein eigenes Büro in Krakau (gosign.pl) mit polnischsprachigen Projektleitern, Engineers und Compliance-Verantwortlichen - native Polish und English Speakers, die direkt vor Ort beim Kunden im Krakow Technology Park, im Hub:raum oder in Räumen des Mutterkonzerns arbeiten. Discovery-Workshops, Sprint Reviews und Steering laufen ohne Sprachbarriere und ohne Reise-Overhead, die Vertretung der Rada Zakładowa sitzt im selben Raum. Krakau fungiert als Regional-Hub für ganz Polen: Die meisten ABB-, Cisco-, Capgemini- und IBM-Standorte erreichen wir innerhalb derselben Stadt, Warschau, Wrocław und Gdańsk sind innerhalb eines Tages erreichbar. Die Hamburger Zentrale liefert architektonische Reviews, DACH-Compliance-Expertise und die Anbindung an deutsche oder schweizerische Mutterkonzerne - Delivery, Tagesgeschäft und direkter Kundenkontakt liegen beim Krakauer Team. Für ein Outsourcing-Land mit mehr als 350.000 IT-Engineers ist das die einzige Aufstellung, die wirklich funktioniert: lokal verankert, EU-weit anschlussfähig.

## Warum Krakau als Startpunkt für Enterprise AI funktioniert

Krakau hat drei Eigenschaften, die es als Einstiegspunkt einzigartig machen. Erstens die Dichte an Talent: Der Krakow Technology Park, Hub:raum und das Krakow Startups Cluster bilden das größte Technologie-Ökosystem zwischen Berlin und Wien, mit Tausenden Engineers, die mehrsprachig auf Konzernprozesse trainiert sind. Zweitens die Multi-Jurisdiktions-Realität: Wer einen AI Agent in Krakau für ABB, Cisco oder ING konformitätsfähig baut, hat ihn implizit für ganz EU-West gebaut. Die Architektur, die im Krakauer GCC dem polnischen UODO, der niederländischen DNB und der deutschen BaFin gleichzeitig standhält, ist in jedem anderen EU-Land nur noch eine Konfigurationssache. Drittens die operative Reife: Krakauer GCCs arbeiten seit über fünfzehn Jahren mit westeuropäischen Konzernen zusammen, die internen Prozesse für Change-Management, ITIL, ISO 27001 und SOX-Compliance sind eingespielt. Eine neue Decision-Layer-Komponente einzuführen heißt hier nicht, eine neue Compliance-Disziplin zu lernen, sondern eine bestehende um eine zusätzliche Kontroll-Ebene zu erweitern.

Cert-Ready by Design ist in diesem Umfeld nicht Marketing, sondern Voraussetzung für jeden ersten Tag im Betrieb. Wer in Krakau anfängt, hat den schwersten Test schon hinter sich, bevor das erste westeuropäische Tochterunternehmen ausgerollt wird - und wer in Krakau einen AI Agent betriebsfest implementiert hat, kann denselben Agent in Warschau, Wrocław oder Gdańsk innerhalb weniger Wochen ausrollen, weil das technische Fundament identisch bleibt und nur die regulatorischen Konfigurationsdateien angepasst werden müssen. Mehr Kontext zum [EU AI Act](/de/governance/eu-ai-act/) und der polnischen Anwendung gibt es im Governance-Bereich.

--- AI Agents für Unternehmen in Lissabon | Gosign ---
> Enterprise AI Agents in Lissabon. Lokale Projektleitung, EU AI Act direkt anwendbar, DSGVO-konform. Vom PoC zum eigenständigen Betrieb.

## Lissabon ist Europas am schnellsten wachsendes Tech-Kapital - mit einem überraschend strikten Datenschutzregime

In den letzten zehn Jahren ist Lissabon vom touristischen Geheimtipp zum Tech-Hub für Westeuropa geworden. EDP (Energias de Portugal) und Galp Energia bilden den Energie-Kern, Millennium BCP und Caixa Geral de Depósitos das Bankenrückgrat, Jerónimos Martins (Pingo Doce, Recheio, Biedronka in Polen) ist der größte Lebensmittelhändler des Landes. NOS und Altice Portugal dominieren die Telekomlandschaft. Dazu kommen die portugiesischen Tech-Champions Farfetch (Luxus-Mode-Marketplace), OutSystems (Low-Code-Plattform mit globaler Skalierung) und Feedzai (AI-basierte Fraud-Detection für Banken weltweit). Im Beato Innovation District und im Hub Criativo do Beato sitzen Hunderte von Startups - die Stadt zieht Talent aus ganz Europa an, weil die Lebenshaltungskosten niedriger sind als in Berlin oder Amsterdam und das Tech-Ökosystem dichter wird.

## Die drei regulatorischen Hürden für AI im portugiesischen Markt

Erstens die CNPD (Comissão Nacional de Protecção de Dados) zusammen mit der Lei 58/2019, dem portugiesischen DSGVO-Umsetzungsgesetz. Die CNPD ist eine der konsequentesten Datenschutzbehörden in Südeuropa und hat in den letzten Jahren mehrere hochkarätige Bußgelder gegen Telekomunternehmen, Banken und öffentliche Einrichtungen verhängt. Die CNPD prüft AI-Systeme besonders auf Transparenz, Datenminimierung und das Recht auf menschliche Entscheidung nach Art. 22 DSGVO. Wer in Lissabon AI baut, baut für eine Behörde, die Algorithmus-Audits ernst nimmt.

Zweitens der EU AI Act, der in Portugal direkt anwendbar ist. Die portugiesische Regierung hat die ANACOM (Autoridade Nacional de Comunicações) und die CNPD als koordinierende Stellen für die EU-AI-Act-Umsetzung benannt, mit dem Plan, eine eigene Marktüberwachungsbehörde aufzubauen. Hochrisiko-Systeme - insbesondere im Energie- und Finanzsektor - werden ab 2026 systematisch geprüft.

Drittens das Banco de Portugal und die CMVM (Comissão do Mercado de Valores Mobiliários) für alle Finanzdienstleister. Beide Behörden haben gemeinsame Erwartungen an AI-Modellgovernance formuliert: Erklärbarkeit, Audit Trail, Reproduzierbarkeit, Bias-Mitigation. Banken wie Millennium BCP und Caixa Geral de Depósitos arbeiten bereits an entsprechenden Frameworks. [EU AI Act Compliance](/de/governance/eu-ai-act/) und Finanzaufsicht greifen hier ineinander.

## Typische Einsatzszenarien in Lissabon

Millennium BCP setzt AI in der Kreditanalyse für KMU-Kunden ein und braucht Modelle, die unter CNPD- und Banco-de-Portugal-Aufsicht reproduzierbar bleiben - jede Ablehnung muss innerhalb der gesetzlichen Frist begründbar sein. EDP betreibt Smart-Meter-Infrastruktur in Portugal, Spanien und Brasilien und nutzt AI für Lastprognosen und Anomalie-Erkennung im Stromnetz - die Modelle müssen für die Energieaufsicht ERSE dokumentiert werden. Feedzai entwickelt Fraud-Detection-Modelle für Banken weltweit, mit Hauptsitz in Lissabon - jedes Modell-Update muss in einem Audit Trail nachvollziehbar bleiben, weil die Kunden in regulierten Märkten produktiv gehen. Farfetch nutzt Empfehlungsalgorithmen für Luxusprodukte in über 190 Ländern - hier kollidieren CNPD-Anforderungen mit den Datenschutzregimen von UK, USA und China.

In allen Szenarien geht es um AI-Modelle, die nicht im Labor leben, sondern in einer regulierten Geschäftslogik mit messbaren Konsequenzen. Der [Decision Layer](/de/decision-layer/) löst die Architekturfrage: Audit Trail bis auf SQL-Ebene, Human-in-the-Loop bei eskalationspflichtigen Fällen, Cert-Ready by Design.

Eine portugiesische Besonderheit ist die Comissão de Trabalhadores - die Arbeitnehmervertretung mit Informations- und Konsultationsrechten bei der Einführung von KI-Systemen. Wir bauen den Decision Layer so, dass diese Pflichten nicht nachträglich übersetzt werden müssen, sondern als Teil der Governance funktionieren. Das ist besonders relevant für Konzerne wie Jerónimos Martins, deren Mitarbeiterzahl im fünfstelligen Bereich liegt und deren AI-Entscheidungen direkten Einfluss auf Personaleinsatz und Schichtplanung haben.

## Wie Gosign von Lissabon aus Portugal betreut

Gosign hat ein eigenes Büro in Lissabon (gosign.pt) mit portugiesischem Team - native Speakers, lokale Projektleitung, direkter Kontakt zu CNPD, Banco de Portugal und CMVM. Das Lissabon-Office ist Regional-Hub für den portugiesischen Markt: Discovery-Workshops, Sprint Reviews und Steering laufen vor Ort beim Kunden im Beato Innovation District, im Hub Criativo do Beato oder direkt in den Konzernzentralen von Galp Energia, EDP, Millennium BCP, Caixa Geral de Depósitos und Jerónimo Martins. Für die portugiesischen Tech-Champions Feedzai, OutSystems und Farfetch arbeiten wir auf Augenhöhe in der lokalen Engineering-Kultur, mit Workshops und Code-Reviews auf Portugiesisch, Compliance-Dokumentation in Portugiesisch und Englisch, der Comissão de Trabalhadores von Anfang an mit am Tisch. Wir kooperieren eng mit Startup Lisboa und dem lokalen Talent-Pool. Bei LATAM-Projekten koppelt das Lissabon-Team zusätzlich mit dem São-Paulo-Office (gosign.com.br) zusammen - Brasilien und Portugal als zusammenhängender lusofoner Markt, mit gemeinsamer Sprache, gemeinsamer Geschäftskultur und einer Architektur, die LGPD und DSGVO parallel bedient. Die Hamburger Zentrale übernimmt architektonische Grundsatzfragen und die Anbindung an deutsche und nordeuropäische Mutterkonzerne.

## Warum Lissabon als Startpunkt für Enterprise AI funktioniert

Portugal ist klein genug, um in einem AI-Projekt mehrere Branchen-Stakeholder direkt einzubinden, und groß genug, um echte Compliance-Anforderungen zu haben. Wer in Lissabon einen Cert-Ready-by-Design-Piloten baut, hat einen Referenzfall, der unter CNPD- und EU-AI-Act-Standards bestanden hat - und der danach in Brasilien (LGPD), Spanien (LOPDGDD) und im Rest Europas verteidigbar ist. Das Lisbon Tech Hub, Startup Lisboa und das Beato Innovation District liefern Talent, Investorenzugang und Pilotpartner.

Wir bringen die Erfahrung mit, AI-Systeme so zu bauen, dass sie auch unter strenger CNPD-Aufsicht produktiv bleiben - mit Governance by Design und der Disziplin, die deutsche Datenschutz-Praxis prägt. Lissabon ist der richtige Markt, um diese Disziplin auf der iberischen Halbinsel zu skalieren. Und für Unternehmen, die den portugiesischen Markt als Sprungbrett in den lusofonen Raum (Brasilien, Angola, Mosambik) nutzen, ist Lissabon der einzige europäische Standort, von dem aus diese Brücke architektonisch sauber gebaut werden kann.

--- AI Agents für Unternehmen in London | Gosign ---
> Enterprise AI Agents für London. UK-DSGVO und EU-DSGVO dual-konform, EU AI Act ready, FCA-aware. Auditierbare KI für die City und darüber hinaus.

## In London muss jede AI-Entscheidung gleichzeitig zwei Datenschutzregime erfüllen - das ist die teuerste Compliance-Lücke Europas

Seit dem Brexit ist London nicht mehr der EU-Finanzplatz, sondern der Compliance-Doppelkopf Europas. HSBC, Barclays, Lloyds Banking Group, NatWest, Standard Chartered und Prudential betreiben hier ihre Konzernzentralen. BP und Shell haben in London ihren globalen Hauptsitz, AstraZeneca koordiniert von hier aus klinische Studien weltweit, und im Tech-Bereich sitzen Revolut, DeepMind und ARM Holdings. Die "Square Mile" ist nach wie vor das größte Finanzzentrum Europas und vermutlich der einzige Markt, in dem ein einziges Unternehmen UK-Regulierung, EU-Regulierung und US-Sanktionsregime gleichzeitig befolgen muss - oft im selben System. Wer hier Enterprise AI baut, baut nicht für eine Jurisdiktion, sondern für eine Schnittmenge.

## Die drei regulatorischen Hürden für AI im Londoner Markt

Erstens das doppelte Datenschutzregime UK GDPR plus EU GDPR. Seit dem Brexit gilt für britische Unternehmen die UK GDPR, aber sobald ein Unternehmen Geschäft mit EU-Kunden hat - was praktisch alle Londoner Konzerne tun - greift parallel die EU GDPR über den Adequacy-Mechanismus. Das ICO (Information Commissioner's Office) prüft die UK-Seite, und für die EU-Seite ist je nach EU-Tochter eine andere Aufsichtsbehörde zuständig. Beide Regime weichen in Detailfragen voneinander ab, und beide entwickeln sich auseinander - etwa bei automatisierten Entscheidungen nach Art. 22 oder bei Datentransfer-Mechanismen. Wer hier eine AI-Architektur baut, muss dual-konform sein.

Zweitens das UK AI White Paper, das einen sektorbasierten Ansatz vorsieht, statt - wie der EU AI Act - ein horizontales Gesetz. Die FCA (Financial Conduct Authority), die PRA (Prudential Regulation Authority), das ICO und die CMA (Competition and Markets Authority) entwickeln je eigene AI-Leitlinien für ihren Sektor. Die FCA hat mit dem AI Public-Private Forum bereits konkrete Erwartungen an Modell-Governance, Erklärbarkeit und Vorstandsverantwortung formuliert. Wer in London Banking-AI baut, baut für mindestens vier Aufseher gleichzeitig - in unterschiedlicher Tiefe.

Drittens der DSA und DMA für Londoner Plattformen mit EU-Geschäft. Wer aus London heraus europäische Verbraucher anspricht, fällt unter die EU-Plattformregulierung - unabhängig von UK-Recht. Die [EU AI Act Compliance](/de/governance/eu-ai-act/) wird hier zur Schnittstelle: Britische Unternehmen mit substanziellem EU-Geschäft müssen sich praktisch wie EU-Unternehmen verhalten, ohne den Schutz der EU-Mitgliedschaft zu haben.

## Typische Einsatzszenarien in London

HSBC betreibt globale Fraud-Detection mit AI-Modellen, die in mehr als 60 Ländern produktiv sind und gleichzeitig FCA, ICO, EU-Aufsicht und US-OCC standhalten müssen. Lloyd's of London nutzt AI für Underwriting-Entscheidungen in Spezialversicherungen - jede automatisierte Risiko-Bewertung muss gegenüber Lloyd's Performance Management Directorate dokumentiert sein und im Schadensfall reproduzierbar bleiben. Die FCA selbst verlangt von ihren regulierten Unternehmen Conduct-Rule-Compliance mit AI-Werkzeugen, die Vorstandsverantwortung nachvollziehbar machen müssen. AstraZeneca dokumentiert klinische Studien für die MHRA und parallel für die EMA - jede AI-gestützte Auswertung muss in beiden Regimen belegbar sein.

In allen Szenarien ist die zentrale Frage nicht "funktioniert das Modell?", sondern "können wir die Entscheidung jurisdiktionsübergreifend verteidigen?". Der [Decision Layer](/de/decision-layer/) löst genau das: Er routet jede Entscheidung durch jurisdiktionsspezifische Regelsätze, persistiert den Audit Trail mit vollständigen Metadaten und durchsetzt Human-in-the-Loop bei Entscheidungen, die in mehreren Regimen prüfungsrelevant sind.

Hinzu kommen die personenrechtlichen Aufseher: Die UK Senior Managers and Certification Regime (SMCR) macht einzelne Vorstände persönlich für AI-Entscheidungen ihrer Bereiche verantwortlich. Wer als Director eines britischen Finanzunternehmens AI einführt, ohne die Modell-Governance dokumentieren zu können, riskiert ein persönliches Ban aus der Branche. Das ist eine Stufe schärfer als die DSGVO-Bußgelder auf dem Kontinent - und es ist der Grund, warum britische Banken Cert-Ready by Design seit Jahren ernst nehmen.

## Wie Gosign aus Hamburg London betreut

Hamburg-London ist ein Direktflug von etwa 90 Minuten, mit täglich mehreren Verbindungen über LH, BA und EasyJet. Wir arbeiten Remote-first mit Kunden in der City und in Canary Wharf, mit Vor-Ort-Workshops für Discovery, Architekturentscheidungen und kritische Compliance-Reviews. Die Arbeitssprache ist Englisch, die Steering-Runden mit unseren Hamburger Architekten laufen auf Deutsch. Die Zeitzone (London GMT/BST, eine Stunde hinter MEZ) ist überschaubar und überlappt vollständig mit unserem Hamburger Arbeitstag.

Was wir aus dem deutschen Markt mitbringen, ist Erfahrung mit dualer Regulierung. Deutsche Banken arbeiten standardmäßig mit BaFin, EZB und FCA gleichzeitig - die jurisdiktionsübergreifende Compliance-Logik ist uns vertraut. Wir kennen die FCA-Erwartungen an Modell-Governance gut genug, um beim ersten Workshop konkrete Architekturentscheidungen zu treffen, statt erst Regulatoren übersetzen zu müssen.

## Warum London als Startpunkt für Enterprise AI funktioniert

London hat den höchsten regulatorischen Druck für AI in Europa, weil hier zwei sich auseinanderentwickelnde Datenschutzregime aufeinandertreffen. Wer in London einen Cert-Ready-by-Design-Piloten baut, der dual-konform ist, hat einen Referenzfall, der in jedem anderen Markt verteidigbar ist - inklusive USA, Schweiz und APAC. Das Silicon Roundabout-Cluster, Canary Wharf, das London Tech City-Programm und das Tech Nation-Netzwerk liefern Talent, Ökosystem und Pilotpartner.

Der zweite Vorteil: London zwingt zu einer Architektur, die nicht für eine einzelne Jurisdiktion gebaut ist, sondern für jurisdiktionsspezifische Regelsätze über demselben Audit Trail. Das ist Governance by Design - und wenn das in London funktioniert, funktioniert es überall. Hamburg liefert die deutsche Engineering-Disziplin, London den globalen Compliance-Stresstest.

--- AI Agents für Unternehmen in Madrid | Gosign ---
> Enterprise AI Agents für Madrid. Sitz der AESIA, EU AI Act reguliert, DSGVO-konform. Auditierbare KI für Spaniens Unternehmenshauptstadt.

## Madrid ist die einzige europäische Hauptstadt, in der die nationalen Datenschutz- und Finanzregulatoren in Gehweite voneinander sitzen

Wer Enterprise AI in Madrid baut, baut buchstäblich vor der Haustür der spanischen Aufsicht. Die AEPD (Agencia Española de Protección de Datos), die CNMV (Comisión Nacional del Mercado de Valores), die Banco de España und die CNMC (Comisión Nacional de los Mercados y la Competencia) - alle vier haben ihren Hauptsitz in Madrid. Hinzu kommt der politische Apparat: Das Ministerio de Asuntos Económicos und das Ministerio de Industria, Comercio y Turismo entscheiden hier über die Umsetzung des EU AI Act. Im Unternehmenssektor sitzen Banco Santander, BBVA, Telefónica, Repsol, Iberdrola (HQ Bilbao, aber Madrid ist operativ stark), Mapfre, Ferrovial, ACS, Naturgy, Red Eléctrica und Amadeus IT in der Stadt. Wer hier eine AI-Architektur baut, baut für eine Konzentration aus Big Corporates und Aufsichtsbehörden, die in Europa nur Frankfurt und Paris vergleichbar haben.

## Die drei regulatorischen Hürden für AI im Madrider Markt

Erstens die AEPD und das LOPDGDD (Ley Orgánica 3/2018), Spaniens DSGVO-Umsetzungsgesetz mit Verschärfungen. Die AEPD ist EU-weit für ihre strikte Auslegung von Art. 22 DSGVO bekannt - vollautomatisierte Entscheidungen sind in Spanien praktisch nur mit dokumentierter menschlicher Letztentscheidung zulässig. Die Behörde hat in den letzten Jahren mehrere Bußgelder im acht- und neunstelligen Euro-Bereich verhängt, oft gegen Banken und Telekomunternehmen. Der Decision Layer mit Human-in-the-Loop ist hier nicht optional, sondern Compliance-Voraussetzung.

Zweitens die AESIA (Agencia Española de Supervisión de la Inteligencia Artificial). Spanien ist das erste EU-Land mit einer dedizierten AI-Aufsichtsbehörde. Der Hauptsitz liegt in La Coruña, aber operativ und politisch wird vieles in Madrid entschieden. Die AESIA prüft ab 2026 systematisch Hochrisiko-Systeme nach EU AI Act und kann Betriebsverbote aussprechen. Wer in Madrid Modelle in den Markt bringt, muss von Anfang an für ein AESIA-Audit dokumentieren.

Drittens die CNMV und Banco de España für den gesamten Finanzsektor. Beide Behörden haben gemeinsame Erwartungen an AI-Modellgovernance formuliert und prüfen Banken, Versicherer und Asset Manager auf Erklärbarkeit, Audit Trail und Reproduzierbarkeit. Die CNMV verlangt seit 2024 bei AI-gestützten Anlageempfehlungen einen vollständigen Audit Trail. [EU AI Act Compliance](/de/governance/eu-ai-act/) und Finanzaufsicht greifen hier ineinander.

## Typische Einsatzszenarien in Madrid

Banco Santander betreibt Kreditprüfung in 10+ Ländern und braucht AI-Modelle, die unter AEPD-, CNMV- und Banco-de-España-Aufsicht reproduzierbar bleiben - jede Ablehnung muss innerhalb der gesetzlichen Frist begründbar sein. Telefónica analysiert CDR-Daten (Call Detail Records) für Fraud-Erkennung und Netzoptimierung in über 12 Märkten - die Modelle müssen gegenüber AEPD und ANACOM auditierbar bleiben. Mapfre setzt AI in der Schadenregulierung ein und braucht Modelle, die jede automatische Schadenshöhe-Schätzung gegenüber Versicherten begründbar machen. Iberdrola plant in Madrid Stromnetz-Operationen, die unter Hochrisiko-Kategorien des EU AI Act fallen - die Modelle müssen für Red Eléctrica und die nationale Energieaufsicht CNMC dokumentiert sein.

In jedem dieser Fälle ist der [Decision Layer](/de/decision-layer/) die Architektur, die Audit Trail bis auf SQL-Ebene, Human-in-the-Loop-Eskalation und Cert-Ready by Design zusammenführt - genau das, was die Madrider Aufsichtsbehörden gleichzeitig sehen wollen.

Eine Madrider Besonderheit ist die Konzernkomplexität: Die meisten großen spanischen Unternehmen sind über Iberoamerika hinaus verflochten - Santander in 10+ Ländern, BBVA in Mexico und Türkei, Telefónica in Brasilien und Deutschland. Eine AI-Architektur in Madrid muss in der Lage sein, jurisdiktionsspezifische Regelsätze für DSGVO, LGPD, mexikanische LFPDPPP und türkische KVKK gleichzeitig durchzusetzen - alles über demselben Audit Trail. Wer das in Madrid baut, hat eine Architektur für die gesamte hispanofone Welt.

## Wie Gosign aus Barcelona Madrid betreut

Gosign betreut Madrider Projekte aus dem Barcelona-Büro (gosign.es) mit spanischsprachigen Projektleitern und Engineers. Die AVE-Hochgeschwindigkeitsverbindung Barcelona-Madrid braucht knapp zweieinhalb Stunden - wöchentliche Vor-Ort-Termine bei Santander, BBVA, Telefónica, Mapfre, Iberdrola und Repsol sind kein logistischer Aufwand, sondern Routine. Discovery-Workshops, Sprint Reviews und Steering-Runden laufen vor Ort am Paseo de la Castellana, in Las Tablas oder direkt an den Konzernzentralen, mit den spanischsprachigen Fachverantwortlichen und Vertretern des Comité de Empresa am selben Tisch. Madrid ist Sitz der wichtigsten ES-Regulatoren - AEPD, CNMV, Banco de España und CNMC sind in Gehweite voneinander - und das spanische Team ist regelmäßig vor Ort, um regulatorische Abstimmungen, Audit-Vorbereitungen und Sandbox-Termine direkt zu führen. Die Hamburger Zentrale übernimmt DACH- und internationale Koordination sowie architektonische Reviews - der operative Tagesbetrieb, die Madrider Konzernkultur und die Behördenkontakte liegen beim Barcelona-Team.

## Warum Madrid als Startpunkt für Enterprise AI funktioniert

Madrid ist die einzige Stadt in Europa, in der Sie alle vier spanischen Aufsichtsbehörden zu Fuß erreichen können - und in der die meisten regulatorischen Antworten innerhalb weniger Tage statt Wochen verfügbar sind. Wer hier einen Cert-Ready-by-Design-Piloten baut, hat einen Referenzfall, der unter AEPD-, AESIA-, CNMV- und Banco-de-España-Standards bestanden hat. Die Cluster Madrid in Motion, der Impact Hub Madrid und Wayra Madrid (Telefónica) liefern Talent, Pilotpartner und Investorenzugang.

Wir bringen aus dem deutschen Markt die Erfahrung mit, AI-Systeme so zu bauen, dass sie unter strengen Aufsichtsregimen nicht nur funktionieren, sondern produktiv bleiben - mit Governance by Design und Audit Trail. Madrid ist der richtige Markt, um diese Disziplin in das Herz der spanischen Wirtschaft zu tragen.

--- AI Agents für Unternehmen in Polen | Gosign ---
> Enterprise AI Agents für polnische Unternehmen. EU AI Act compliant, DSGVO-konform, betriebsratskompatibel. Büro in Krakau, Projekte in ganz Polen.

## Polen ist gleichzeitig Europas größtes IT-Outsourcing-Land und eine eigenständige Digital-Economy

Polen ist der einzige EU-Markt, in dem zwei strukturell unterschiedliche Tech-Ökonomien nebeneinander existieren. Auf der einen Seite die Global Capability Centers westeuropäischer Konzerne in [Krakau](/de/ai-agents-krakau/), [Wrocław](/de/ai-agents-wroclaw/) und [Gdańsk](/de/ai-agents-gdansk/) - ABB, Cisco, IBM, Capgemini, UBS, Bosch, LG Electronics, Amazon Development Center, Volvo, Toyota Motor Manufacturing Poland. Auf der anderen Seite die rein polnischen Konzerne mit Hauptsitz in [Warschau](/de/ai-agents-warschau/) und Krakau: PKO BP, Pekao, Santander Bank Polska, ING Bank Śląski, mBank, BNP Paribas Polska, PZU, Warta, Allegro, LPP, Dino Polska, Biedronka (Jerónimo Martins), CCC, Ciech, Grupa Azoty, JSW, KGHM, CD Projekt, Asseco, Comarch. Diese Doppelstruktur erzeugt einen AI-Markt, der gleichzeitig Konzern-Compliance der Mutterländer bedienen muss und eigene polnische Regulierung erfüllen.

## Die drei regulatorischen Hürden für AI im Polen-Markt

Erstens KSeF und die elektronische Rechnungsstellung: KSeF (Krajowy System e-Faktur) wird in Polen schrittweise zur Pflicht für alle Unternehmen. Hunderttausende Eingangs- und Ausgangsrechnungen pro Tag müssen strukturiert, validiert und archiviert werden - jede KI-gestützte Extraktion oder Klassifikation muss KSeF-konform sein. Konzerne wie Orlen, Allegro, LPP und PGE entwickeln derzeit ihre Document-Pipelines neu. Wer hier ohne nachvollziehbare Modellgrundlagen arbeitet, riskiert Steuerprüfungen mit unklarer Beweislast.

Zweitens UODO, RODO und das polnische Gesetz über den Schutz personenbezogener Daten: Das UODO (Urząd Ochrony Danych Osobowych) ist in den letzten Jahren zu einem der aktiveren EU-Datenschutzregulatoren geworden. Bei automatisierter Profilbildung und Entscheidungsfindung im Sinne des Art. 22 DSGVO erwartet das UODO dokumentierte Rechtsgrundlagen, abrufbare Erklärungen und einen vollständigen Audit Trail. Die polnische Spezifik: Bei HR-relevanten Entscheidungen hat die Rada Zakładowa Informations- und Konsultationsrechte, die durch die Architektur erzwungen werden müssen.

Drittens KNF, NBP und der EU AI Act: Die Komisja Nadzoru Finansowego beaufsichtigt mit Sitz in Warschau den polnischen Finanzsektor und erwartet bei AML, KYC, Kreditscoring und Schadenbearbeitung nachweisbare menschliche Letztentscheidung in Risikofällen. Der EU AI Act gilt seit Februar 2025 für verbotene Praktiken; für Hochrisiko-Systeme greifen die Pflichten nach aktuellem Recht ab dem 2. August 2026, voraussichtlich verschoben auf den 2. Dezember 2027 (Digital Omnibus, Mai 2026, formale Verabschiedung ausstehend) - in Polen ohne nationales Durchführungsgesetz, also direkt anwendbar. Wer Hochrisiko-KI in HR, Banking oder Versicherung einsetzt, braucht Konformitätsbewertungen, Risikomanagement und post-market monitoring auf einem Stand, der einer KNF- oder UODO-Prüfung standhält.

## Typische Einsatzszenarien in Polen

PKO BP und mBank AML-Operations: Die polnischen Banken verarbeiten täglich Millionen Transaktionen. Document Agents extrahieren Identifikationsmerkmale, der Decision Layer routet Verdachtsfälle entlang der KNF-Schwellen, mit Human-in-the-Loop bei jeder finalen Eskalation und vollständigem Audit Trail für die Aufsicht.

Allegro, LPP und Dino Polska KSeF-Pipeline: Polens größte Retailer und der Marktführer im E-Commerce stehen unter dem KSeF-Druck. Document Agents extrahieren strukturierte Rechnungsdaten, validieren gegen das KSeF-Schema und routen Abweichungen an menschliche Prüfer in der Buchhaltung.

JSW und KGHM Operations: Polens Bergbau- und Schwermetall-Konzerne erzeugen täglich riesige Mengen an Sensordaten und Sicherheitsmeldungen. Workflow Agents klassifizieren Anomalien, eskalieren Sicherheitsvorfälle an Schichtleiter und protokollieren jede Entscheidung für Wojewódzki Inspektorat Ochrony Środowiska und KNF-relevante Auswertungen.

Comarch und Asseco Software-Operations: Die beiden polnischen Software-Konzerne entwickeln Banken- und Versicherungssoftware für ganz Mitteleuropa. Document Agents prüfen Release-Dokumentation gegen KNF-, BaFin- und FINMA-Anforderungen, bevor ein Release ausgeliefert wird.

## Wie Gosign von Krakau aus ganz Polen betreut

Gosign hat ein eigenes Büro in Krakau (gosign.pl) als Regional-Hub für den polnischen Markt. Das polnische Team mit Projektleitern und Engineers - polnische Native Speakers, Englisch fließend - deckt alle vier großen Tech-Cluster des Landes ab: [Warschau](/de/ai-agents-warschau/) als Konzern- und Regulator-Hauptstadt, [Krakau](/de/ai-agents-krakau/) selbst als Shared-Service-Hub, [Wrocław](/de/ai-agents-wroclaw/) als Industrie-IT-Hybrid und [Gdańsk](/de/ai-agents-gdansk/) als Hafen- und Tech-Standort. Vor-Ort-Workshops, Sprint Reviews und Steering laufen auf Polnisch, ohne Sprachbarriere und ohne Reise-Overhead aus dem Ausland. Die Hamburger Zentrale liefert Architekturstandards, DACH-Compliance-Expertise und die Anbindung an deutsche, schweizerische und niederländische Mutterkonzerne - Delivery, Tagesgeschäft und der direkte Kundenkontakt liegen beim Krakauer Team. Genau diese Struktur ist entscheidend für polnische Mittelständler und Konzern-Tochterunternehmen, die einen DE-orientierten Qualitätsstandard wollen, ohne sich gleichzeitig eine Sprachbarriere ins Haus zu holen.

## Warum Polen als Startpunkt für Enterprise AI funktioniert

Polen ist für deutsche, schweizerische und niederländische Konzerne der nächstliegende AI-Stresstest. Wer einen AI Agent in Polen produktiv stellt, der gleichzeitig KSeF, UODO, KNF und den EU AI Act erfüllt, hat eine Architektur entwickelt, die in jedem westeuropäischen Markt nur noch eine Konfigurationsänderung weit ist. Polen kombiniert maximale Talent-Verfügbarkeit (Krakau, Wrocław, Warschau, Gdańsk) mit maximalem Regulierungsdruck (KNF, UODO, KSeF, EU AI Act, RODO). Das Cluster aus Krakow Technology Park, Warsaw Spire Tech, Wrocław Technology Park und Gdańsk Science & Technology Park bildet die größte zusammenhängende Tech-Landschaft in Mittelosteuropa.

Hinzu kommt eine Eigenschaft, die Polen für Enterprise-AI-Implementierungen besonders berechenbar macht: die operative Nähe zu Deutschland. Polnische Konzerne arbeiten seit Jahrzehnten mit deutschen Mutterkonzernen, polnische Banken halten Korrespondenzbeziehungen zu Frankfurt und München, polnische Industrie-Standorte sind in deutsche Lieferketten eingebunden. Die Compliance-Sprache ist eingespielt, die Erwartungen an Audit Trail, Erklärbarkeit und Governance by Design sind nicht neu. Eine erfolgreiche Implementierung in Polen ist damit nicht nur ein Markt-Erschließungsschritt, sondern liefert eine Architektur-Referenz, die in der DACH-Region direkt akzeptiert wird. Cert-Ready by Design ist hier keine Marketing-Phrase, sondern Voraussetzung für jeden ersten produktiven Tag - und gleichzeitig der schnellste Weg zu einer Enterprise-AI-Plattform, die später in fünfzehn weiteren EU-Ländern produktiv gehen soll. Mehr Kontext zum [EU AI Act](/de/governance/eu-ai-act/) und der polnischen Anwendung gibt es im Governance-Bereich.

--- AI Agents für Unternehmen in Rio de Janeiro | Gosign ---
> Enterprise AI Agents für Rio de Janeiro. LGPD-konform, CLT-kompatibel. Auditierbare Agents für Energie, Bergbau und den öffentlichen Sektor.

## Rio de Janeiro ist der Compliance-Engpass des brasilianischen Energie- und Rohstoffsektors

In Rio sitzen die Konzerne, deren operative Risiken jeden Tag in den ESG-Reports der Welt landen: Petrobras (Hauptsitz Avenida República do Chile), Vale (Hauptsitz auf Praia de Botafogo, operativ in Minas Gerais), Eletrobras, Light SA, Americanas und Oi. Dazu die Regulierer: CVM (Comissão de Valores Mobiliários, Hauptsitz Centro Rio), BNDES als nationale Förderbank, ANP (Agência Nacional do Petróleo) und ANEEL (Agência Nacional de Energia Elétrica) mit Außenstellen direkt in der Innenstadt. Wer hier AI-Agents in produktiven Compliance-Loops betreibt, betreibt sie unter den Augen von vier Aufsichtsbehörden gleichzeitig - und mindestens einer davon ist nach Brumadinho hochsensibel für jede Form algorithmischer Entscheidung. Anders als in São Paulo ist die Industrie-Konzentration hier nicht horizontal verteilt, sondern vertikal vertieft: Wer Energie und Rohstoffe in Brasilien adressiert, hat in Rio den dichtesten Marktzugang.

## Die drei regulatorischen Hürden für AI im Rio-de-Janeiro-Markt

**CVM-Aufsicht für Kapitalmarkt-Konzerne** ist in Rio dichter als irgendwo sonst in Brasilien. Petrobras, Vale, Eletrobras und Americanas sind börsennotiert; jede algorithmische Komponente in Investor Relations, Quartals-Reporting oder Insider-Trading-Prävention muss einem CVM-Auditor erklärbar sein. Der CVM-Hauptsitz in Centro Rio bedeutet: kurze Wege, intensive Prüfungen.

**ANP und ANEEL für regulierte Infrastruktur**: Petrobras-Anlagen und Eletrobras-Netze sind nach ANP- und ANEEL-Vorgaben dokumentiert. AI, die Wartungsfenster vorschlägt, Produktionspläne erstellt oder Netzausfälle priorisiert, fällt damit unter konkrete Sektorregulierung - nicht nur unter LGPD. Die ANP verlangt Nachvollziehbarkeit bis auf Bohrloch-Ebene, ANEEL bis auf Umspannwerks-Ebene.

**LGPD und post-Brumadinho-Transparenzdruck**: Vale steht seit 2019 (Brumadinho) und 2015 (Mariana) unter der Beobachtung der Bundesstaatsanwaltschaft (MPF) und der Justiça Federal. Jede algorithmische Entscheidung im Bereich Damm-Sicherheit, Risk-Scoring oder Tailings-Monitoring muss vor Gericht erklärbar sein. Audit Trail ist hier nicht „nice to have" - er ist der Unterschied zwischen Strafanzeige und Verteidigungslinie.

## Typische Einsatzszenarien in Rio de Janeiro

**Petrobras Anlagen-Dokumentation**: Document Agents lesen Wartungsprotokolle, Bohr-Reports und ANP-Meldungen aus 30 Jahren Anlagengeschichte und konsolidieren sie zu auditierbaren Decision-Records. Wenn ein Inspektor nach der Historie eines Schweißnaht-Risses fragt, ist die Antwort statt eines Wochenprojekts eine Abfrage - mit vollständigem Audit Trail bis zur Originaldatei. Bei einem Konzern mit 60.000 Mitarbeitern, Pre-Salt-Bohrungen vor der Küste und einem Refinerie-Netz quer durch Brasilien ist das nicht „nice to have", sondern operativer Engpass.

**Vale Mining-Safety-Monitoring**: Workflow Agents überwachen Sensor-Daten, Inspektionsberichte und externe Wetterdaten an Tailings-Damm-Standorten in Minas Gerais (operativ aus Rio gesteuert). Der Decision Layer eskaliert kritische Risikomuster mit Human-in-the-Loop an die Geotechnik - jede Entscheidung dokumentiert für ANM, MPF und interne Compliance.

**BNDES Kreditbewilligung**: Document Agents prüfen Förderanträge auf Vollständigkeit, Plausibilität und Konflikt mit ESG-Ausschluss-Kriterien. Der Decision Layer markiert kritische Anträge für menschliche Entscheidung und erzeugt eine vollständige Begründungs-Akte für jede Empfehlung - inklusive Quellenangaben und Datenherkunft. Bei Förderkrediten in dreistelliger Millionenhöhe ist die Begründungs-Tiefe pro Entscheidung Voraussetzung für jede TCU-Prüfung.

**Globo Content-Moderation und Rights-Management**: Document Agents verarbeiten Lizenz-Dokumente, Verwertungsrechte und Kontrakt-Klauseln für die größte Mediengruppe Lateinamerikas. Der Decision Layer eskaliert Konflikte zwischen Sender-Lizenzen, Streaming-Rechten und internationalen Verwertungsverträgen mit Audit Trail bis zur Originaldatei - kritisch im Streaming-Zeitalter, in dem Globoplay-Rechte täglich neu verhandelt werden.

## Wie Gosign aus São Paulo ganz Brasilien betreut - inklusive Rio

Unser Büro in [São Paulo](/de/ai-agents-sao-paulo/) ist 1 Flugstunde von Rio entfernt - näher an Petrobras-HQ als die Mehrheit deutscher AI-Anbieter an irgendeinem Kunden ist. Discovery-Workshops mit Petrobras, Vale oder BNDES finden vor Ort in Rio statt, in den Konzernzentralen in Botafogo oder Centro. Compliance-Reviews mit CVM-, ANP- oder ANEEL-Bezug werden gemeinsam mit Ihrer Rechtsabteilung in Rio geführt - die Nähe zum CVM-Hauptsitz bedeutet, dass regulatorische Klärungen statt 6-Wochen-Schriftverkehr in einem Termin im 25. Stock von Avenida Rio Branco geklärt werden. Technische Build-Phasen laufen verteilt zwischen unseren Teams in Hamburg und São Paulo - Stand-ups vormittags SP-Zeit, gemeinsame Sprint-Reviews. Vor-Ort-Termine in Rio sind binnen 24 Stunden möglich, auch zu Petrobras-Anlagen außerhalb der Stadt (Macaé, Campos-Becken). Nach Go-Live ist das SP-Büro Ihr operativer Ansprechpartner mit Eskalations-Hotline auf Portugiesisch und Englisch - Kommunikation mit Ihrer europäischen Mutterkonzernzentrale (im Fall internationaler Kunden) bleibt parallel auf Deutsch oder Englisch möglich.

## Warum Rio de Janeiro als Startpunkt für Enterprise AI funktioniert

Rio ist die einzige brasilianische Stadt, in der vier Regulierer (CVM, ANP, ANEEL, ANPD-Außenstelle) und vier der zehn größten brasilianischen Konzerne in 15 km Umkreis sitzen. Wer hier einen produktiven Agent für CVM-Reporting, ANP-Compliance oder Tailings-Monitoring baut, hat ihn als Blueprint für jeden lateinamerikanischen Energie- und Rohstoff-Markt verfügbar - von Buenos Aires über Lima bis Bogotá. Die Cluster - BNDES Inovação, Rio+, Porto Maravilha Tech-Korridor - bringen dazu die Brücke zur akademischen Welt (PUC-Rio, UFRJ). Was Rio darüber hinaus auszeichnet: Die Konzentration börsennotierter Konzerne mit globalen ESG-Anlegern bedeutet, dass die Anforderungen an algorithmische Erklärbarkeit hier dichter sind als anderswo in Lateinamerika - was die Latte hoch legt, aber genau dadurch jeden hier erfolgreich gebauten Agent zu einem Cert-Ready-Blueprint für globale Mutterhäuser macht. Gosigns Governance-by-Design-Architektur ist anschlussfähig für DSGVO-Operationen in Lissabon und EU-Audits - ein Modell, das in Rio besteht, besteht in Frankfurt. Siehe auch [São Paulo](/de/ai-agents-sao-paulo/) und [Brasilien gesamt](/de/ai-agents-brasilien/).

--- AI Agents für Unternehmen in São Paulo | Gosign ---
> Enterprise AI Agents in São Paulo. Lokale Projektleitung, LGPD-konform, CLT-kompatibel. Vom PoC zum eigenständigen Betrieb.

## São Paulo ist die einzige LATAM-Metropole, in der ein deutscher AI-Anbieter mit lokaler Präsenz arbeiten muss

Wer Itaú Unibanco, Bradesco, Santander Brasil, Natura &Co oder Ambev als Kunden gewinnen will, kann das nicht aus Hamburg heraus tun. Avenida Paulista, Faria Lima und Pinheiros sind eigene regulatorische Mikrokosmen mit eigenen Compliance-Prozessen, eigenen Datenschutzkulturen und eigenen Erwartungen an die Nähe von Anbietern. Das gilt für die Banken-Cluster rund um Cubo Itaú genauso wie für die Konsumgüter-Welten von JBS, BTG Pactual und XP Inc. Gosign betreibt deshalb ein eigenes Büro in São Paulo - mit lokalen Projektleitern, die direkt vor Ort bei Diskussionen mit Compliance-Officern, Datenschutzbeauftragten (DPO) und Sindicato-Vertretern sitzen.

## Die drei regulatorischen Hürden für AI im São-Paulo-Markt

**LGPD (Lei Geral de Proteção de Dados)** ist Brasiliens Antwort auf europäischen Datenschutz - aber nicht identisch mit der DSGVO. Die ANPD (Autoridade Nacional de Proteção de Dados, formal in Brasília, operativ aber stark auf SP fokussiert) verlangt Rechtsgrundlage, Zweckbindung und einen DPO. Wer in Pinheiros mit personenbezogenen Daten arbeitet, muss LGPD-Artikel 7 und 11 (sensible Daten, Gesundheits- und Finanzdaten) einhalten - inklusive Audit Trail.

**BACEN Resolução 4893** definiert die Cyber-Resilience-Anforderungen für regulierte Finanzinstitute und ist faktisch das brasilianische DORA-Pendant. Itaú, Bradesco, Banco do Brasil, Santander Brasil und die Fintechs (Nubank, Stone, PagSeguro, XP Inc.) müssen jeden algorithmischen Eingriff in Kreditentscheidungen, Fraud-Scoring oder Anti-Geldwäsche dokumentieren - nicht erst beim Audit, sondern produktiv und live.

**PL 2338/2023** ist der brasilianische KI-Gesetzentwurf, lose an den EU AI Act angelehnt aber nicht identisch. Er ist 2026 noch nicht in Kraft, wird aber in den nächsten zwei Jahren erwartet. Wer heute baut, muss die Architektur schon so anlegen, dass High-Risk-Klassifizierung, menschliche Kontrolle und Transparenzpflichten nachträglich aktivierbar sind. Cert-Ready by Design statt Cert-Retrofit.

## Typische Einsatzszenarien in São Paulo

**Banco-KYC und AML-Screening bei Itaú/Bradesco/Santander Brasil**: Document Agents lesen Cadastro de Pessoas Físicas, Cadastro Nacional da Pessoa Jurídica, Comprovante de Residência und externe Sanktionslisten. Der Decision Layer markiert High-Risk-Treffer (PEPs, Sanktionsmatches) und routet sie an Compliance-Officer mit Begründung, Confidence-Score und vollständigem Audit Trail. Banco Central und Coaf-Audits werden statt eines Wochenprojekts zum Knopfdruck.

**Lieferketten-Compliance bei Natura &Co und JBS**: Workflow Agents überwachen Lieferanten-Zertifikate (FSC, Rainforest Alliance, GRSB für Rindfleisch), gleichen sie mit IBAMA-Sanktionslisten ab und alarmieren bei Auffälligkeiten. Bei JBS und Marfrig ist die Frage „liefert dieser Hof in Abholzungs-Gebiete?" inzwischen genauso überlebenskritisch wie ESG-Reporting bei Natura.

**Investment-Compliance bei XP Inc. und BTG Pactual**: Document Agents prüfen Anlageverträge, Risikoprofile und CVM-Meldepflichten. Der Decision Layer eskaliert bei Verstößen gegen Suitability-Anforderungen automatisch an Compliance - mit Human-in-the-Loop bei jedem regulatorisch relevanten Schritt. Bei Investment-Banken ist die Audit-Tiefe pro Trade kein „nice to have", sondern Voraussetzung für jedes CVM-Verfahren - Workflow Agents dokumentieren parallel die Suitability-Prüfung, die Anlegeraufklärung und die Modell-Versionierung des Risiko-Scorings.

**Fraud Detection bei Nubank, Stone und PagSeguro**: Brasilien hat die höchste Pix-Adoption der Welt (über 90% der Bevölkerung), und damit eine eigene Fraud-Landschaft. Workflow Agents überwachen Transaktionsmuster in Echtzeit, gleichen sie mit Verhaltensprofilen ab und eskalieren auffällige Vorgänge mit Confidence-Score und Begründungs-Akte an Anti-Fraud-Teams. Audit Trail erfüllt sowohl Coaf-Meldepflichten als auch BACEN-Sicherheitsstandards.

## Wie Gosign aus São Paulo betreut

Wir haben ein Büro in São Paulo mit lokalen Projektleitern - das ist kein „Sales-Office", sondern echte operative Präsenz. Konkret heißt das: Discovery-Workshops finden vor Ort statt, nicht über Zoom aus Europa. Compliance-Reviews mit Ihrem DPO und der Rechtsabteilung passieren persönlich in Faria Lima oder Pinheiros. Sindicato-Konsultationen, wenn HR-Agents arbeitsrelevante Entscheidungen treffen, werden gemeinsam mit Ihren Arbeitsrechts-Anwälten geführt. Die technische Implementierung läuft remote zwischen unseren Teams in Hamburg und São Paulo - 4 Stunden Zeitversatz, gemeinsame Stand-ups am Vormittag SP-Zeit. Nach Go-Live bleibt das SP-Büro Ihr operativer Ansprechpartner - inklusive Eskalations-Hotline auf Portugiesisch und Ansprechpartnern, die brasilianisches Arbeitsrecht (CLT) und Tarifverträge (CCT/ACT) tatsächlich operativ kennen, nicht nur vom Übersetzungsdokument.

Die Frage, die uns brasilianische Compliance-Verantwortliche zuerst stellen, ist nicht „könnt ihr das technisch?", sondern „seid ihr dann auch da, wenn die ANPD oder der Auditor anruft?". Die ehrliche Antwort lautet: ja, weil unsere Projektleiter in São Paulo wohnen, arbeiten und leben. Discovery, Build, Go-Live und Aftercare sind nicht vier verschiedene Teams in vier verschiedenen Ländern - es ist ein Team mit einem Hub in São Paulo und einem in Hamburg, das sich gemeinsame Sprint-Zyklen, gemeinsame Architektur-Boards und gemeinsame Eskalationswege teilt.

## Warum São Paulo als Startpunkt für Enterprise AI funktioniert

São Paulo ist der einzige Punkt in Lateinamerika, an dem Banken-Compliance, Konsumgüter-Lieferketten, Fintech-Innovation und Industrie-Operations in einer Stadt zusammentreffen. Wer hier einen produktiven AI-Agent für KYC, AML oder ESG baut, hat ihn in 18 Monaten als Blueprint für Mexiko-Stadt, Bogotá, Santiago oder Buenos Aires verfügbar. Die Cluster - Cubo Itaú, ACE Startups, das Tech-Korridor Pinheiros-Vila Olímpia - sorgen für Zugang zu Talent, Investoren und regulatorischen Pilotprogrammen. Gosigns Governance-by-Design-Architektur verbindet das mit europäischer Audit-Tiefe: Ein Modell, das in São Paulo mit LGPD und BACEN funktioniert, ist anschlussfähig für DSGVO-Operationen in Lissabon, Madrid oder Hamburg. Mehr im [Brasilien-Überblick](/de/ai-agents-brasilien/).

--- AI Agents für Unternehmen in Spanien | Gosign ---
> Enterprise AI Agents für Spanien. AESIA-ready, DSGVO-konform, EU AI Act compliant. Büro in Barcelona, Projekte in ganz Spanien.

## Spanien hat als erstes EU-Land eine eigene KI-Aufsichtsbehörde - das verändert die Implementierungsplanung

Spanien ist der einzige EU-Staat, der mit der AESIA (Agencia Española de Supervisión de la Inteligencia Artificial) bereits eine voll operative nationale KI-Aufsichtsbehörde hat. Die AESIA mit Sitz in La Coruña ist Spaniens Antwort auf den EU AI Act und nimmt eine Rolle ein, die in den meisten anderen EU-Ländern noch verteilt oder unbesetzt ist. Für Konzerne wie Santander, BBVA, CaixaBank, Sabadell, Telefónica, Iberdrola, Repsol, Inditex, Mercadona, Ferrovial, ACS, Mapfre, Amadeus IT Group, Grifols und Naturgy bedeutet das: regulatorische Klarheit früher als anderswo. Die Ballungsräume Madrid, Barcelona, Valencia, Bilbao, Sevilla und Málaga bilden die wichtigsten Tech-Hubs des Landes - und alle stehen unter derselben einheitlichen KI-Aufsicht. Wer in Spanien Enterprise AI baut, hat einen Regulator, der weiß, was er erwartet, und es klar kommuniziert.

## Die drei regulatorischen Hürden für AI im Spanien-Markt

Erstens AESIA und der EU AI Act: Die AESIA ist seit 2024 operativ und entwickelt aktiv Leitlinien für Hochrisiko-KI-Systeme im Sinne des EU AI Act Annex III. Bei HR-Entscheidungen, Kreditscoring, biometrischer Identifikation und kritischer Infrastruktur erwartet die AESIA dokumentierte Konformitätsbewertungen, Risikomanagement, post-market monitoring und einen vollständigen Audit Trail. Der Vorteil gegenüber anderen EU-Ländern: Spanische Konzerne wissen heute schon, was 2026 und 2027 von ihnen erwartet wird - während Konzerne in Deutschland oder Frankreich noch auf nationale Durchführungsgesetze warten.

Zweitens AEPD und LOPDGDD: Die Agencia Española de Protección de Datos beaufsichtigt die DSGVO in Spanien, ergänzt durch die spanische Ley Orgánica de Protección de Datos y Garantía de los Derechos Digitales (LOPDGDD) und die LGICTE für KI-Transparenz im Verbraucherkontakt. Bei Santanders Kreditscoring, BBVAs AML-Operations oder Telefónicas Empfehlungssystemen erwartet die AEPD dokumentierte Rechtsgrundlagen, abrufbare Erklärungen und nachvollziehbare menschliche Letztentscheidung. Die spanische Spezifik: Bei algorithmischen Entscheidungen im Verbraucherkontakt verlangt die LGICTE explizit eine Transparenzpflicht, die in keiner anderen EU-Jurisdiktion in dieser Form existiert.

Drittens CNMV, Banco de España und CNMC für sektorspezifische Aufsicht: Santander, BBVA, CaixaBank und Sabadell stehen unter Aufsicht von CNMV (Wertpapieraufsicht) und Banco de España (Bankenaufsicht). Bei MiFID-relevanten Empfehlungen, AML-Screening und Underwriting erwarten beide Behörden dieselben Erklärbarkeits- und Audit-Standards wie BaFin oder FCA. Die CNMC beaufsichtigt zusätzlich Wettbewerbs-relevante algorithmische Entscheidungen - ein Aspekt, der bei Mercadona, Inditex und im spanischen E-Commerce zunehmend in den Fokus rückt. Spanische Konzerne mit LATAM-Geschäft müssen zusätzlich die LGPD in Brasilien und das argentinische Datenschutzgesetz 25.326 berücksichtigen.

## Typische Einsatzszenarien in Spanien

Santander und BBVA Kreditscoring: Die spanischen Großbanken verarbeiten Millionen Kreditanträge pro Jahr in Spanien und LATAM. Document Agents extrahieren strukturierte Daten aus Antragsformularen, der Decision Layer routet Risikofälle entlang der Banco-de-España-Schwellen, mit Human-in-the-Loop bei jeder Risiko-Letztentscheidung und einem Audit Trail, der gleichzeitig CNMV, AEPD und AESIA standhält.

Telefónica Konsumenten-Empfehlungen: Telefónica betreibt Empfehlungssysteme für Tarife, Inhalte und Mehrwertdienste in mehreren spanisch- und portugiesischsprachigen Märkten. Decision Agents prüfen jede Empfehlung gegen LOPDGDD, LGICTE-Transparenzanforderungen und LGPD-Vorgaben in Brasilien - jede ausgespielte Entscheidung mit nachvollziehbarer Begründung.

Inditex und Mercadona Supply-Chain-Operations: Spaniens Marktführer im Mode- und Lebensmittel-Retail betreiben hochkomplexe Supply Chains. Workflow Agents klassifizieren Bestellungen, Retouren und Lieferanten-Vorfälle, der Decision Layer routet Eskalationen an menschliche Verantwortliche und protokolliert jede Entscheidung für interne Revisionen und CNMC-relevante Wettbewerbs-Audits.

Iberdrola und Naturgy Grid-Operations: Spaniens Energie-Konzerne setzen KI für Netz-Optimierung, Predictive Maintenance und Verbrauchsprognosen ein. Document Agents extrahieren Sicherheits- und Wartungsmeldungen, Workflow Agents klassifizieren Anomalien nach Schweregrad, mit erzwungener menschlicher Letztentscheidung bei sicherheitsrelevanten Befunden - eine Anforderung, die die AESIA für KRITIS-relevante KI explizit fordert.

## Wie Gosign von Barcelona aus ganz Spanien betreut

Gosign hat ein eigenes Büro in Barcelona (gosign.es) als Regional-Hub für die iberische Halbinsel. Das spanisch-katalanische Team mit Projektleitern und Engineers - native Speakers, alle Stakeholder-Sprachen zu Hause - bedient alle vier Hauptmarkt-Regionen des Landes: [Madrid](/de/ai-agents-madrid/) als Konzern- und Regulator-Hauptstadt, [Barcelona](/de/ai-agents-barcelona/) selbst als Tech-Hub, [Valencia](/de/ai-agents-valencia/) als Industrie- und Logistik-Standort und [Bilbao](/de/ai-agents-bilbao/) als baskisches Industrieherz. Vor-Ort-Workshops, Sprint Reviews und Steering laufen auf Spanisch, in Katalonien zusätzlich auf Katalanisch, im Baskenland bei Bedarf mit Euskara-sprachigen Stakeholdern. Die direkten Kontakte zu AESIA in La Coruña, AEPD und CNMV in Madrid laufen über das Barcelona-Team, Compliance-Dokumentation wird zweisprachig geliefert. Die Hamburger Zentrale liefert technische Architektur-Standards und die internationale Koordination mit deutschen, schweizerischen und niederländischen Mutterkonzernen. Für spanische Konzerne mit LATAM-Geschäft - Santander, Telefónica, BBVA, Mapfre - koppelt das Barcelona-Team zusätzlich mit dem São-Paulo-Office (gosign.com.br) zusammen, sodass DSGVO, LGPD und mexikanisches LFPDPPP über derselben Architektur abgebildet werden.

## Warum Spanien als Startpunkt für Enterprise AI funktioniert

Spanien hat einen strukturellen Vorteil, den heute kein anderer großer EU-Markt bietet: regulatorische Klarheit aus einer zentralen Quelle. Wer einen AI Agent für ein spanisches Unternehmen baut, der den AESIA-Erwartungen heute standhält, hat eine Architektur entwickelt, die EU-AI-Act-konform ist - bevor andere EU-Länder ihre nationalen Aufsichtsbehörden überhaupt operativ haben. Für deutsche, schweizerische und nordische Konzerne mit spanischen oder LATAM-Tochterunternehmen ist Spanien damit häufig der erste produktive AI-Markt - die spanische AESIA-Konformität wird zur Blaupause für die anschließende Rollout-Welle in andere EU-Länder. Cert-Ready by Design bedeutet hier: Eine Architektur, die heute die Anforderungen erfüllt, die im Rest der EU erst 2027 verbindlich werden. Die spanische Pionierrolle ist kein Zufall, sondern Programm - und ein erheblicher Standortvorteil für jeden, der jetzt anfängt. Mehr Kontext zum [EU AI Act](/de/governance/eu-ai-act/) und der spanischen Umsetzung gibt es im Governance-Bereich.

--- AI Agents für Unternehmen in Stockholm | Gosign ---
> Enterprise AI Agents für Stockholm. EU AI Act direkt anwendbar, schwedische IMY-Aufsicht. Auditierbare KI für den Tech-Hub der Nordics.

## Stockholm ist die Tech-Hauptstadt Skandinaviens - mit der konsequentesten Datenschutzbehörde der EU im Hintergrund

Wer Enterprise AI in Stockholm baut, baut für eine ungewöhnliche Mischung: Industrielle Schwergewichte wie Ericsson, ABB, Atlas Copco, Volvo Cars (operativ in Göteborg, Konzernfunktionen in Stockholm) und Electrolux treffen auf eine der dichtesten Unicorn-Konzentrationen Europas - Spotify, Klarna, King Digital, iZettle, Truecaller, Northvolt. H&M und IKEA (über die Ikano-Gruppe) bilden den Retail-Kern. Das Bankenrückgrat bilden Skandinaviska Enskilda Banken (SEB), Handelsbanken und Swedbank, die Versicherungslandschaft wird von Skandia und Folksam dominiert. Im Quartier Kista Science City sitzen über 1000 Tech-Firmen, im Stockholm Unicorn Factory-Programm reift die nächste Generation. Was Stockholm besonders macht: Die schwedische Geschäftskultur kombiniert nordische Effizienz mit langfristigem Engineering-Denken - und akzeptiert Compliance-Investitionen, die andere Märkte als bremsend empfinden würden.

## Die drei regulatorischen Hürden für AI im Stockholmer Markt

Erstens die IMY (Integritetsskyddsmyndigheten), die schwedische Datenschutzbehörde. Die IMY ist EU-weit für ihre konsequente Auslegung der DSGVO bekannt und hat in den letzten Jahren mehrere hochkarätige Bußgelder gegen Tech-Unternehmen, Banken und öffentliche Stellen verhängt - oft begründet mit unzureichender Erklärbarkeit automatisierter Entscheidungen. Für AI-Systeme bedeutet das: Art. 22 DSGVO wird in Schweden so streng angewendet wie in den Niederlanden oder Spanien. Decision Layer mit Human-in-the-Loop ist nicht optional, sondern Compliance-Voraussetzung.

Zweitens der EU AI Act, der in Schweden direkt anwendbar ist. Die schwedische Regierung hat angekündigt, eine eigene Marktüberwachungsbehörde einzurichten, die mit der IMY und Finansinspektionen koordiniert. Hochrisiko-Systeme im Banking, in der Energieinfrastruktur und in der Personalverwaltung werden ab 2026 systematisch geprüft. [EU AI Act Compliance](/de/governance/eu-ai-act/) ist hier nicht abstrakt, sondern operativ.

Drittens Finansinspektionen für den Finanzsektor und PTS (Post- och telestyrelsen) für die Telekomunikationsbranche. Finansinspektionen verlangt seit 2023 von Banken und Zahlungsdienstleistern dokumentierte AI-Modellgovernance, Erklärbarkeit und kontinuierliche Modellüberwachung. Klarna, SEB und Handelsbanken arbeiten bereits mit entsprechenden Frameworks. PTS überwacht AI-Anwendungen in Telekomnetzen und prüft Ericssons Network-Slicing-Modelle auf Bias und Fairness.

## Typische Einsatzszenarien in Stockholm

Spotify entwickelt Empfehlungsalgorithmen, die in über 180 Märkten gleichzeitig produktiv sind und unter EU-AI-Act, IMY und mehreren nationalen Aufsichtsregimen verteidigbar bleiben müssen - jeder algorithmische Push für ein Album hat regulatorische Implikationen. Klarna nutzt AI für Buy-Now-Pay-Later-Risk-Modelle in 17+ Märkten - die Modelle bestimmen, ob ein Verbraucher einen Mikrokredit bekommt, und müssen unter Finansinspektionen, BaFin, FCA und mehreren weiteren Aufsichten gleichzeitig erklärbar sein. SEB betreibt Transaction Monitoring zur Geldwäsche-Erkennung mit AI-Modellen, die für Finansinspektionen reproduzierbar bleiben müssen - jede einzelne Alarmierung wird einem Audit unterzogen. Ericsson konfiguriert 5G-Netzwerke für Mobilfunkbetreiber weltweit mit AI-Werkzeugen, deren Entscheidungen für die jeweiligen nationalen Telekomaufsichten dokumentierbar sein müssen.

In allen Szenarien kommt es nicht auf das Modell allein an, sondern darauf, dass jede Entscheidung trace-bar bleibt, durch jurisdiktionsspezifische Regelsätze geroutet werden kann und in Eskalationspfaden Human-in-the-Loop durchsetzt. Das ist [Decision Layer](/de/decision-layer/)-Architektur in Reinkultur.

Eine schwedische Besonderheit ist der Umgang mit Behörden-Daten: Das schwedische Offenlegungsgesetz (Offentlighetsprincipen) verlangt, dass Behördendokumente grundsätzlich öffentlich sind - was für AI-Anwendungen im öffentlichen Sektor und für Auftragnehmer der Verwaltung bedeutet, dass auch die Trainingsdaten und Modellentscheidungen unter Umständen offenzulegen sind. Wer in Stockholm AI für Public-Sector-Kunden baut, muss die Architektur von Anfang an so anlegen, dass dieser Transparenz-Standard erfüllt wird.

## Wie Gosign aus Hamburg Stockholm betreut

Hamburg-Stockholm ist eine Direktflugverbindung von etwas weniger als zwei Stunden, mit täglichen Verbindungen über LH und SAS. Wir arbeiten Remote-first mit unseren schwedischen Kunden, mit Vor-Ort-Workshops in den ersten Projektmonaten und Quartalsbesuchen in der Betriebsphase. Die Arbeitssprache ist Englisch, die Steering-Runden mit unseren Hamburger Architekten laufen auf Deutsch. Die Zeitzone ist identisch mit Mitteleuropa.

Was uns die Zusammenarbeit erleichtert: Die schwedische Geschäftskultur ist konsensorientiert, aber technisch hochkompetent - Workshop-Teilnehmer sind in der Regel Engineering-Leads oder Produktverantwortliche, die unsere Architekturentscheidungen direkt verstehen. Wir kennen die schwedische Mitbestimmungslogik (MBL, Medbestämmande), die Arbeitgeber zur Konsultation der Gewerkschaften vor Einführung neuer Systeme verpflichtet, und planen den Decision Layer entsprechend so, dass die Mitbestimmungspflichten architektonisch erfüllt werden - nicht als nachträgliche Compliance-Schicht, sondern als integrierter Workflow.

## Warum Stockholm als Startpunkt für Enterprise AI funktioniert

Stockholm ist der einzige Markt in Europa, in dem Sie eine AI-Architektur gleichzeitig gegen IMY-Datenschutz, Finansinspektionen-Finanzaufsicht und nordische Mitbestimmungslogik testen können - und in dem die Stakeholder bereit sind, dafür Zeit und Engineering-Ressourcen zu investieren. Wer in Stockholm einen Cert-Ready-by-Design-Piloten baut, hat einen Referenzfall, der unter den strengsten EU-Datenschutz-Bedingungen bestanden hat - und der danach in Helsinki, Kopenhagen, Oslo und im Rest Europas verteidigbar ist. Das Kista Science City-Cluster, die Stockholm Unicorn Factory und das Stockholm School of Economics-Netzwerk liefern Talent, Pilotpartner und Investorenzugang.

Wir bringen aus dem norddeutschen Engineering-Kontext eine Disziplin mit, die zur schwedischen Tech-Kultur passt - mit Governance by Design, Audit Trail und der Fähigkeit, Compliance-Anforderungen aus mehreren Jurisdiktionen über demselben System zu erfüllen. Stockholm ist der richtige Markt, um diese Disziplin in den Nordics zu skalieren. Und für deutsche Unternehmen mit nordischen Tochtergesellschaften ist Stockholm oft der erste Markt, in dem sich neue AI-Architekturen produktiv beweisen müssen - bevor sie in München, Frankfurt oder Hamburg ausgerollt werden.

--- AI Agents für Unternehmen in Stuttgart und Baden-Württemberg | Gosign ---
> Enterprise AI Agents für Stuttgart und BaWü. Document Agents für Rechnungen, Workflow Agents für Beschaffung. Auditierbar.

## Stuttgart ist der einzige europäische Markt, in dem Konzern-OEM und Mittelstands-Hidden-Champion in derselben Lieferkette dieselben Compliance-Auflagen erfüllen müssen

Im Korridor zwischen Untertürkheim, Zuffenhausen und Sindelfingen sitzen Mercedes-Benz und Porsche mit ihren Stammwerken. In Gerlingen residiert Bosch als grösster Automotive-Zulieferer der Welt. Daimler Truck steuert von Leinfelden-Echterdingen aus die globale Lkw-Sparte. Hinzu kommen Dürr in Bietigheim, Trumpf in Ditzingen, Festo in Esslingen, Stihl in Waiblingen, Mahle und Kärcher - die Liste der Hidden Champions reicht weit über die Stadtgrenze hinaus. Der Standort definiert sich nicht über die OEM allein, sondern über die Kette aus Hersteller, Tier-1-Zulieferer und spezialisierten Mittelständlern. Wer hier eine AI-Komponente einführt, muss sie in mehreren Ebenen einer ASPICE- und ISO-26262-Lieferkette gleichzeitig dokumentieren - der Mercedes-Lieferantenstandard zwingt jeden Zulieferer zu denselben Audit-fähigen Modellnachweisen. Diese Verzahnung macht den Stuttgarter Markt zu einer der härtesten Compliance-Umgebungen Europas: Jeder Zulieferer wird automatisch durch die Anforderungen seines OEM in eine strenge Modellgovernance gezwungen, ob er will oder nicht.

## Drei regulatorische Hürden, die im Stuttgarter Markt jede AI-Initiative bestimmen

Die erste Hürde ist die Automotive-Type-Approval. Das KBA in Flensburg vergibt Genehmigungen, aber die fachlichen Standards setzt UN/ECE in Genf - allen voran UN R155 zu Cybersecurity Management und UN R156 zu Software Updates. Wer eine AI-Komponente in einem Fahrzeug oder einem Produktionsprozess einsetzt, der die Software des Fahrzeugs beeinflusst, braucht einen lückenlosen Nachweis aus Modellgovernance, Trainingsdaten-Provenienz und reproduzierbaren Bauständen. Die zweite Hürde ist der Cyber Resilience Act für die Industrieausrüstung der Hidden Champions - Trumpf, Dürr, Festo und Stihl liefern Maschinen mit digitalen Komponenten in regulierte Märkte und müssen Schwachstellenmanagement und Modell-Updates nachweisen. Die dritte Hürde ist die starke Mitbestimmung in den IG-Metall-geprägten Werken: Eine AI-Anwendung mit Personenbezug oder Leistungserfassung passiert die Betriebsräte bei Mercedes, Bosch oder Porsche nur dann, wenn der [Decision Layer](/de/decision-layer/) die menschliche Letztentscheidung architektonisch erzwingt. Mehr zum regulatorischen Rahmen unter [Governance EU AI Act](/de/governance/eu-ai-act/).

## Typische Einsatzszenarien in Stuttgart

Bei Bosch und vergleichbaren Tier-1-Zulieferern sehen wir Qualitätsdaten-Agenten, die Fertigungs- und Prüfdaten aus mehreren Werken konsolidieren und Auffälligkeiten an einen Quality-Engineer eskalieren - mit nachvollziehbarer Bewertung und Verweis auf die zugrundeliegenden Messdaten. Bei Daimler Truck hilft ein Compliance-Agent in der Flotten-Dokumentation, etwa bei der Vorbereitung von Marktzulassungsunterlagen für unterschiedliche Jurisdiktionen. Im Porsche Financial Services-Umfeld unterstützen Agenten bei der Vorbereitung von Bonitätsentscheidungen für Leasingkunden - der Sachbearbeiter entscheidet, der Agent reichert mit Unterlagen, Konsumkredit-Historie und Plausibilitätschecks an. Bei Dürr, Festo und Trumpf sehen wir Service-Ticket-Agenten, die eingehende Kundentickets klassifizieren, mit Maschinendaten anreichern und an Service-Techniker mit Vorschlag übergeben. Mahle und Mahle Behr arbeiten an HR-Document-Agenten für die Bewerber-Vorqualifikation - mit klarem Audit Trail, weil das Bewerbungs-Recruiting unter dem AGG und nach EU AI Act in der Hochrisiko-Klassifikation steht. Bei Stihl und Kärcher als familiengeführten Mittelständlern sehen wir Document-Agenten in Beschaffung und Vertragsanalyse, weil die Konzernrevision dieser Häuser eine schlanke, aber lückenlose Audit-Logik erwartet. Die Konzernzentrale von Mercedes-Benz in Untertürkheim arbeitet im Tagesgeschäft mit einem strikten ASPICE-Workflow, in dem AI-Komponenten nur dann in produktive Ketten eingebracht werden, wenn ihre Modell-Provenienz und ihr Trainingsdatensatz dokumentiert und versioniert sind.

## Wie Gosign aus Hamburg Stuttgart betreut

Gosign hat keinen Standort in Stuttgart - die Vor-Ort-Begleitung läuft remote von Hamburg und Berlin aus. Der Vorteil: Wir sind über die ICE-Direktverbindung in unter sechs Stunden in Untertürkheim, ein Direktflug Hamburg-Stuttgart benötigt rund eine Stunde plus An- und Abreise. Konkret: Discovery-Workshops mit Engineering, Compliance und Betriebsrat machen wir als zwei- bis dreitägige Vor-Ort-Blöcke. Die Engineering-Phase ist remote organisiert mit zwei festen Wochenslots im Kundenkalender und definierten Vor-Ort-Tagen für Architektur-Reviews und kritische Stakeholder-Termine. Modellvalidierung mit der internen Revision, ASPICE-Audit-Vorbereitung und Mitbestimmungsverhandlungen passieren ausnahmslos vor Ort. Der schwäbische Markt akzeptiert Remote-Arbeit pragmatisch, wenn die Liefertreue stimmt, die Vor-Ort-Frequenz an den richtigen Schlüsselterminen vorhanden ist und die Modellvalidierung dokumentiert nachvollziehbar bleibt. Cluster wie ARENA2036 als Forschungscampus für die Mobilität der Zukunft auf dem Universitätsgelände Stuttgart und das Cyber Valley Tübingen-Stuttgart als grösstes europäisches ML-Forschungszentrum nutzen wir für technische Diskussionen, Auditor-Trainings und für den Kontakt zu universitären Modellvalidierungs-Experten.

## Warum Stuttgart als Startpunkt für Enterprise AI funktioniert

Wer in einem Stuttgarter OEM- oder Tier-1-Umfeld einen AI Agent in Produktion bringt, hat ihn gleichzeitig gegen ASPICE, ISO 26262, Cyber Resilience Act, einen IG-Metall-erfahrenen Betriebsrat und die interne Revision verteidigt. Die gleiche Architektur passt anschliessend in jede andere produktionsorientierte Branche in Europa, weil die Stuttgarter Lieferketten-Disziplin den höchsten europäischen Standard für Modell-Provenienz und Audit Trail definiert. Hinzu kommt der ML- und Engineering-Talentpool um die Universität Stuttgart mit ihrem starken Maschinenbau- und Informatik-Profil, das KIT in Karlsruhe als grösste deutsche technische Universität, die Hochschule Esslingen mit ihrer Automotive-Spezialisierung und die Tübinger ML-Cluster mit dem Max-Planck-Institut für Intelligente Systeme. Der Mittelstand in Baden-Württemberg ist gleichzeitig ein Markt für skalierte AI-Architektur - die rund 1.500 Hidden Champions im Bundesland zeigen, dass es nicht nur die DAX-Konzerne sind, die AI als Produktionsfaktor brauchen. Wer in 4-6 Wochen einen ersten Agent bei einem Tier-1-Zulieferer in Produktion bringt, hat damit ein Referenz-Setup, das der Markt versteht. Mehr zum Vorgehen unter [AI Agents Leistungen](/de/leistungen/ai-agents/).

--- AI Agents für Unternehmen in Valencia | Gosign ---
> Enterprise AI Agents für Valencia. Tech-Hub am Mittelmeer. EU AI Act compliant, DSGVO-konform. Projektleitung von Barcelona.

## Valencia ist Spaniens dritter Wirtschaftsraum - geprägt von Lebensmittel-Logistik, Automobilindustrie und Mittelmeerhandel

Wer Enterprise AI in Valencia baut, baut für eine Stadt, in der nicht Banken oder Tech-Konzerne den Ton angeben, sondern Lieferketten, Produktionsplanung und Logistik. Mercadona ist mit über 1700 Filialen Spaniens größte Supermarktkette und betreibt vom Hauptsitz in Tavernes Blanques eine der dichtesten Eigenmarken-Lieferketten Europas. Ford Valencia produziert in Almussafes seit den 1970er Jahren - das Werk gehört zu den größten Ford-Standorten in Europa. Porcelanosa (Keramik), Lladró (Porzellanmanufaktur) und Consum (Genossenschafts-Supermarktkette) sind weitere industrielle Schwergewichte. Air Nostrum operiert hier den iberischen Regionalflugverkehr, BP betreibt in Castellón eine der größten Raffinerien Spaniens, und Iberdrola Energía koordiniert vom Großraum Valencia einen wesentlichen Teil der spanischen Solaranlagen-Erzeugung. Die Stadt hat sich in den letzten Jahren zusätzlich als Tech-Standort mit der Marina Valencia und dem Lanzadera-Programm (von Mercadona-Gründer Juan Roig finanziert) entwickelt.

## Die drei regulatorischen Hürden für AI im Valencianischen Markt

Erstens die AEPD und das LOPDGDD (Ley Orgánica 3/2018) für alle Verarbeitungen mit Personenbezug. Die AEPD prüft besonders streng bei Logistik- und Retail-Unternehmen, weil hier riesige Mengen Kunden- und Mitarbeiterdaten verarbeitet werden. Mercadona zum Beispiel bewegt täglich Daten von Millionen Kunden und über 100.000 Mitarbeitern - jede AI-gestützte Personalplanung muss unter Art. 22 DSGVO begründbar sein.

Zweitens die AESIA (Agencia Española de Supervisión de la Inteligencia Artificial) und der EU AI Act, der in Spanien direkt anwendbar ist. Hochrisiko-Systeme - insbesondere in der Personalverwaltung, in der Lieferkettenoptimierung und in der Energieerzeugung - werden ab 2026 systematisch geprüft. Wer in Valencia eine AI-Pipeline für Workforce Management aufbaut, baut für eine Hochrisiko-Kategorie und muss von Anfang an für ein AESIA-Audit dokumentieren.

Drittens die CNMV und Banco de España für die Finanzierungsketten zwischen Industrie und Banken. Auch wenn Valencia nicht der Bankenstandort Spaniens ist, sind die großen Industrieunternehmen in komplexe Working-Capital-Strukturen eingebunden. AI-gestützte Cashflow-Prognosen, Kreditrisiko-Modelle und Hedging-Strategien stehen unter beider Aufsicht. [EU AI Act Compliance](/de/governance/eu-ai-act/) trifft hier auf Finanzaufsicht.

## Typische Einsatzszenarien in Valencia

Mercadona optimiert Lieferketten zwischen Hunderten Lieferanten, mehreren Logistikzentren und über 1700 Filialen - jede AI-gestützte Bestellempfehlung wirkt sich direkt auf Lebensmittelverschwendung, Frische und Margen aus. Die Modelle müssen nachvollziehbar bleiben, weil Lieferanten- und Mitarbeitervergütung an den Empfehlungen hängt. Ford Valencia plant in Almussafes die Produktion mehrerer Modellreihen mit komplexen Lieferketten in der gesamten Iberischen Halbinsel - AI-Modelle für Kapazitätsplanung müssen für Konzern-Audits standhalten. Porcelanosa nutzt Computer-Vision für die Qualitätssicherung der Keramikproduktion - jede automatische Ausschuss-Entscheidung muss gegenüber Großkunden und Lieferanten belegbar sein. Iberdrola Energía überwacht in der Region Valencia und Castilla-La Mancha große Solar-Photovoltaik-Anlagen - AI-Anomalieerkennung in der Performance der Module muss in einem Audit Trail dokumentiert werden, der für Eigentümer und Versicherer prüfbar bleibt.

In allen Szenarien geht es um industrielle AI mit physischer Wirkung. Der [Decision Layer](/de/decision-layer/) bringt die Architektur, die Audit Trail, Eskalation und Cert-Ready by Design zusammenführt - genau das, was die spanischen Aufsichtsbehörden gleichzeitig sehen wollen.

Eine valencianische Besonderheit ist der Hafen von Valencia - der größte Containerhafen am Mittelmeer und ein strategischer Knoten für den europäisch-asiatischen Handel. Wer hier AI für Frachtdokumentation, Zollabwicklung und Logistik-Optimierung baut, arbeitet unter dem zusätzlichen Aufsichtsregime der Agencia Tributaria und der Aduanas-Behörde. Der Audit Trail muss nicht nur DSGVO-konform sein, sondern auch zollrechtlich nachvollziehbar - und das oft über mehrere Sprachen und Jurisdiktionen hinweg.

## Wie Gosign aus Barcelona Valencia betreut

Gosign betreut Valencianer Projekte aus dem Barcelona-Büro (gosign.es) mit spanischsprachigen Projektleitern und Engineers. Die AVE-Verbindung Barcelona-Valencia braucht rund dreieinhalb Stunden, mit dem Auto je nach Verkehr ähnlich - monatliche Vor-Ort-Termine bei Mercadona in Tavernes Blanques, bei Ford Valencia in Almussafes, bei Porcelanosa und in der Marina Valencia sind Standardbestandteil jedes Projekts. Discovery findet vor Ort statt, mit den spanischsprachigen Fachverantwortlichen, der Compliance-Funktion und dem Comité de Empresa am selben Tisch. Bei Bedarf binden wir valencianisch-sprachige Stakeholder ein. Die lokalen Industrie-Cluster - Agri-Food rund um Mercadona und Consum, Automotive um Ford und Zulieferer, Keramik in Castellón - erfordern Branchenverständnis, das das spanische Team aus jahrelanger Mittelstandsarbeit auf der iberischen Halbinsel mitbringt. Die Hamburger Zentrale liefert architektonische Reviews und die Anbindung an deutsche Industrie-Compliance-Standards - die Delivery, der direkte Kundenkontakt und die familiengeführte Verhandlungskultur Valencias liegen beim Barcelona-Team.

## Warum Valencia als Startpunkt für Enterprise AI funktioniert

Valencia ist der ideale Markt, um industrielle AI mit voller Compliance zu validieren, ohne die regulatorische Friktion und Kostenstruktur Madrids zu haben. Wer in Valencia einen Cert-Ready-by-Design-Piloten baut, hat einen Referenzfall, der unter AEPD-, AESIA- und EU-AI-Act-Standards bestanden hat - und der danach in Madrid, Barcelona und über die Pyrenäen hinweg verteidigbar ist. Die Marina Valencia, das Lanzadera-Programm und die Universitat Politècnica de València liefern Talent, Pilotpartner und Forschungsanbindung.

Wir bringen aus dem deutschen Industriegürtel die Erfahrung mit, AI in komplexen Lieferketten und Produktionssystemen zu betreiben - mit Governance by Design, Audit Trail und Human-in-the-Loop. Valencia ist der richtige Markt, um diese Disziplin auf der iberischen Halbinsel produktiv zu skalieren. Wer hier startet, hat einen Blueprint für jede europäische Industrie-Region mit ähnlichem Profil - vom Ruhrgebiet über die Lombardei bis ins Baskenland.

--- AI Agents für Unternehmen in Warschau | Gosign ---
> Enterprise AI Agents für Warschau. EU AI Act compliant, DSGVO-konform, betriebsratskompatibel. Auditierbare KI für Polens Konzernzentralen.

## Warschau ist Polens Konzern-Hauptstadt mit der dichtesten Regulator-Konzentration in Mittelosteuropa

In Warschau sitzen die Zentralen von PKO BP, PZU, Orlen, PGE, Santander Bank Polska, mBank, Allegro, CD Projekt RED und LPP - polnische Branchenführer mit Hunderttausenden Kunden, Mitarbeitern und Geschäftsvorgängen pro Tag. Gleichzeitig ist Warschau Sitz der wichtigsten Aufsichtsbehörden des Landes: UODO, KNF, NBP und ZUS arbeiten alle innerhalb weniger Kilometer voneinander. Diese Nähe zwischen Konzernen und Regulatoren erzeugt eine Aufsichtsdichte, die in keiner anderen polnischen Stadt existiert. KI-Systeme, die in Warschauer Konzernzentralen produktiv gehen, müssen nicht nur funktionieren - sie müssen einer Aufsicht standhalten, die geografisch eine U-Bahn-Station entfernt sitzt.

## Die drei regulatorischen Hürden für AI im Warschau-Markt

Erstens die KNF-Aufsicht über den polnischen Finanzsektor: PKO BP, mBank, Pekao, Santander Bank Polska und PZU stehen unter direkter KNF-Aufsicht. Bei AML- und KYC-Prozessen, Kreditscoring und Schadenbearbeitung erwartet die Komisja Nadzoru Finansowego dokumentierte Modellgrundlagen, einen vollständigen Audit Trail und nachweisbare menschliche Letztentscheidung in Risikofällen. Die KNF hat in den letzten Jahren ihre Erwartungen an automatisierte Entscheidungsfindung präzisiert - wer als Bank in Warschau KI einsetzt und keine belastbare Konformitätsdokumentation bereitstellt, riskiert nicht nur Beanstandungen, sondern Eingriffe in den laufenden Betrieb.

Zweitens KSeF, das polnische System für elektronische Rechnungsstellung: KSeF wird für alle Unternehmen in Polen schrittweise verpflichtend. Konzerne wie Orlen, Allegro, LPP und PGE müssen Hunderttausende Eingangs- und Ausgangsrechnungen pro Tag KSeF-konform extrahieren, validieren und archivieren. KI, die Rechnungsdaten verarbeitet, muss den KSeF-Strukturanforderungen entsprechen und im Konfliktfall nachvollziehbar machen, warum eine Buchung wie ausgeführt erfolgte - ein klassischer Anwendungsfall für Document Agents mit erzwungenem Human-in-the-Loop bei Abweichungen.

Drittens UODO und die Spezifika des polnischen Datenschutzgesetzes: Das UODO sitzt in Warschau und prüft polnische Konzerne mit besonderer Aufmerksamkeit auf automatisierte Profilbildung im Sinne des Art. 22 DSGVO. Bei Allegros Empfehlungssystemen, PZUs Schadenklassifikation oder PKO BPs Kreditscoring erwartet das UODO klare Auskunftsfähigkeit und nachvollziehbare Begründungen - jede betroffene Person muss erfahren können, warum eine Entscheidung getroffen wurde, und die KNF beziehungsweise UODO müssen es prüfen können.

## Typische Einsatzszenarien in Warschau

PKO BP AML- und KYC-Operations: Polens größte Bank verarbeitet täglich Millionen Transaktionen. Document Agents extrahieren Identifikationsmerkmale, Workflow Agents routen Verdachtsfälle entlang der KNF-Schwellen, und der Decision Layer protokolliert jede Eskalation für das interne AML-Komitee und externe Prüfer.

Allegro Fraud Detection: Polens größter E-Commerce-Marktplatz konkurriert mit Amazon. Bei Millionen Bestellungen pro Tag prüfen Decision Agents Risikomuster in Echtzeit - immer mit der Möglichkeit, einzelne Entscheidungen für UODO-Audits zurückzuverfolgen.

PZU Schadenregulierung: Der polnische Versicherungsführer bearbeitet Tausende Schadenfälle pro Tag. Workflow Agents klassifizieren eingehende Schadensmeldungen nach Tarif, Region und Komplexität, mit erzwungener menschlicher Prüfung bei Schwellenüberschreitungen - ein expliziter KNF-Anforderungspunkt.

KSeF-Rechnungs-Extraktion für Orlen und PGE: Beide Konzerne stehen unter dem Druck der KSeF-Pflicht. Document Agents extrahieren strukturierte Rechnungsdaten, validieren sie gegen das KSeF-Schema und routen Abweichungen an menschliche Prüfer in der Buchhaltung.

## Wie Gosign aus Krakau Warschau betreut

Gosign betreut Warschauer Projekte aus dem Krakauer Büro (gosign.pl) mit polnischsprachigen Projektleitern und Engineers. Die Distanz Krakau-Warschau ist mit dem Express Intercity Premium in knapp drei Stunden überbrückt, mit dem Auto je nach Verkehr ähnlich - regelmäßige Vor-Ort-Präsenz im Warsaw Spire Tech, am Rondo Daszyńskiego oder direkt in den Konzernzentralen von PKO BP, Allegro, Orlen, PZU und mBank ist Standard, nicht Ausnahme. Discovery-Workshops finden vor Ort statt, mit den polnischsprachigen Fachverantwortlichen, der Compliance-Funktion und einem Vertreter der Rada Zakładowa am selben Tisch. Build und Sprint Reviews laufen anschließend wöchentlich auf Polnisch oder Englisch, mit monatlichen Vor-Ort-Steering-Terminen in Warschau und kurzfristiger Anreise bei UODO- oder KNF-Eskalationen. Die Hamburger Zentrale übernimmt architektonische Grundsatzfragen und die Anbindung an deutsche oder schweizerische Mutterkonzerne - Delivery, Tagesgeschäft und Kundenkontakt liegen beim Krakauer Team auf Augenhöhe mit den Warschauer Stakeholdern.

## Warum Warschau als Startpunkt für Enterprise AI funktioniert

Warschau ist der einzige Markt in Mittelosteuropa, in dem alle drei Bedingungen für eine erfolgreiche Enterprise-AI-Implementierung gleichzeitig vorliegen: maximale Konzern-Dichte, maximale Regulator-Dichte und ein Tech-Ökosystem mit Google for Startups Warsaw, Campus Warsaw und dem Warsaw Spire Tech Cluster. Wer einen AI Agent für eine Warschauer Bank, einen Warschauer Versicherer oder einen Warschauer E-Commerce-Konzern produktiv stellt, hat den schwersten regulatorischen Stresstest in Mittelosteuropa bestanden. Die anschließende Skalierung in andere polnische Standorte - [Krakau](/de/ai-agents-krakau/), [Wrocław](/de/ai-agents-wroclaw/), [Gdańsk](/de/ai-agents-gdansk/) - ist dann kein zweiter Build, sondern eine Konfigurationsänderung.

Hinzu kommt ein Aspekt, der Warschau für deutsche, schweizerische und niederländische Mutterkonzerne besonders attraktiv macht: Die Warschauer Konzerne sind seit Jahren an westeuropäische Compliance-Standards gewöhnt. PKO BP arbeitet mit deutschen Korrespondenzbanken, mBank gehört seit Jahrzehnten zur Commerzbank-Gruppe, Santander Bank Polska ist Teil der spanischen Santander-Konzernstruktur. Diese Konzerne wissen, was eine BaFin-, FINMA- oder DNB-Erwartung an KI bedeutet, und ihre internen Compliance-Funktionen sind darauf ausgelegt. Eine Decision-Layer-Implementierung in Warschau erlebt selten Widerstand gegen die Anforderung, jede Entscheidung auditierbar zu machen - das ist hier seit Jahren operative Realität. Governance by Design ist in Warschau keine Verkaufsfloskel, sondern Eintrittsbedingung. Wer Warschau besteht, besteht den Rest Polens und die meisten EU-Märkte gleich mit. Mehr Kontext zum [EU AI Act](/de/governance/eu-ai-act/) und der polnischen Umsetzung gibt es im Governance-Bereich.

--- AI Agents für Unternehmen in Wroclaw | Gosign ---
> Enterprise AI Agents für Wroclaw. IT-Hub Nr. 2 in Polen. EU AI Act compliant, DSGVO-konform. Projektleitung von Krakau.

## Wrocław ist Polens Industrie-IT-Hybrid - hier treffen Auto-Zulieferer auf Banking-Operations

In Wrocław betreiben Bosch Wrocław, LG Electronics, 3M, Volvo Wrocław, Whirlpool und Toyota Motor Manufacturing Poland Produktions- und Engineering-Standorte mit jeweils Tausenden Mitarbeitern. Parallel sitzen hier UBS Wrocław (entstanden aus dem Credit-Suisse-Center), HP, Nokia Wrocław und mehrere Banking-Shared-Services. Diese Mischung ist in Polen einzigartig: Eine Stadt, in der dieselbe Stunde an Engineering-Dokumenten für ein Auto-Werk und an Research-Reports für eine Schweizer Investmentbank gearbeitet wird. Der Wrocław Technology Park und Capital Park bilden das physische Cluster, die Politechnika Wrocławska liefert Engineers in beide Welten. Wer in Wrocław Enterprise AI baut, muss zwei Industrielogiken gleichzeitig bedienen.

## Die drei regulatorischen Hürden für AI im Wrocław-Markt

Erstens UODO und RODO im Multi-Entity-Kontext: Wrocławer Standorte verarbeiten häufig Daten ihrer westeuropäischen Mutterkonzerne. Eine UBS-Operation in Wrocław unterliegt FINMA-, ESMA- und UODO-Anforderungen gleichzeitig. Eine Bosch-Engineering-Funktion in Wrocław erzeugt Produktdokumentation, die in Stuttgart, Schanghai und Detroit landet. Das polnische Datenschutzgesetz schreibt vor, dass automatisierte Profilbildung und Entscheidungsfindung nachvollziehbar bleiben - auch wenn die Modelle in der deutschen oder schweizerischen Konzernzentrale trainiert werden. KI-Architekturen ohne lückenlosen Audit Trail sind hier nicht implementierbar.

Zweitens KNF-Aufsicht für die wachsende Banking-Outsourcing-Funktion: UBS, mehrere mittelständische Investment-Operations und Credit-Servicing-Provider arbeiten in Wrocław unter dem regulatorischen Dach der Komisja Nadzoru Finansowego sowie zusätzlich der jeweiligen Heimat-Regulatoren. Bei Research-Tools, automatischer Dokumentenklassifikation und Compliance-Screening erwartet die KNF, dass jede Modellentscheidung auf einen menschlichen Letztverantwortlichen zurückgeführt werden kann - inklusive der zugrundeliegenden Datenversion zum Zeitpunkt der Entscheidung.

Drittens der EU AI Act mit Fokus auf Hochrisiko-Anwendungen in HR und Industrie: Wrocławer Produktionsstandorte setzen zunehmend KI für Qualitätsprüfung, Predictive Maintenance und Schichtplanung ein. Schichtplanungs-Algorithmen fallen unter Annex III des EU AI Act (HR-relevante Hochrisiko-Systeme), Qualitätsprüfung über Vision-Modelle berührt Produkthaftung und CE-Konformität. Die NBP und die UODO erwarten in beiden Fällen vollständige Konformitätsdokumentation. Cert-Ready by Design ist bei Wrocławer Produktionsbetrieben kein Verkaufsargument, sondern eine zwingende Voraussetzung für Audits durch Mutterkonzerne und deren Zertifizierer.

## Typische Einsatzszenarien in Wrocław

LG Electronics Qualitätsprüfung: LGs Wrocławer Werk produziert Display-Komponenten in hohen Stückzahlen. Vision-basierte Decision Agents prüfen Oberflächenfehler in Echtzeit, mit erzwungener menschlicher Eskalation bei Grenzfällen. Jede Entscheidung wird im Audit Trail mit Modellversion, Trainingsdatensatz und Reviewer-ID protokolliert.

UBS Wrocław Research Operations: Die ehemalige Credit-Suisse-Operation, jetzt Teil der UBS, betreibt eine der größten Research-Funktionen außerhalb Zürichs. Document Agents extrahieren Kerndaten aus Geschäftsberichten, klassifizieren Earnings Calls und routen Compliance-relevante Aussagen an menschliche Analysten - jeder Schritt protokolliert für FINMA- und KNF-Audits.

HP Service-Desk-Routing: HPs Wrocławer Service-Center bedient Kunden in mehreren Sprachen und Zeitzonen. Workflow Agents klassifizieren eingehende Tickets nach Sprache, Mandant und Eskalationsstufe. Der Decision Layer routet automatisch, mit Human-in-the-Loop bei VIP-Kunden und bei Tickets, die SLAs verletzen würden.

Bosch Produktionsdokumentation: Boschs Wrocławer Standort erzeugt täglich Tausende technischer Dokumente. Document Agents extrahieren regulatorisch relevante Spezifikationen, gleichen sie gegen länderspezifische Normen ab und routen Konflikte automatisch an die Engineering-Leitung in Stuttgart oder Wrocław.

## Wie Gosign aus Krakau Wrocław betreut

Gosign betreut Wrocławer Projekte aus dem Krakauer Büro (gosign.pl) mit polnischsprachigen Engineers und Projektleitern. Krakau-Wrocław ist mit Auto oder Bahn in rund drei Stunden überbrückt - regelmäßige Vor-Ort-Termine im Wrocław Technology Park, im Capital Park oder direkt in den Engineering-Räumen von Bosch, LG Electronics, UBS Wrocław und HP sind Bestandteil jeder Projektphase, nicht Sonderfall. Discovery findet zweitägig vor Ort statt, mit den polnischsprachigen Fachverantwortlichen, der Compliance-Funktion und einem Vertreter der Rada Zakładowa am selben Tisch. Anschließend laufen Build und Sprint Reviews mit dem Krakauer Team, polnisch und englisch, mit monatlichen Vor-Ort-Steerings in Wrocław. Polnische Engineers verstehen die Wrocławer Doppelwelt - traditionelle Industrie und Banking-Outsourcing - aus eigener Berufspraxis und passen Dokumentation, Workshop-Sprache und Eskalationswege ohne kulturelle Übersetzung an. Die Hamburger Zentrale übernimmt Architektur-Reviews und die Anbindung an deutsche und schweizerische Mutterkonzerne in Stuttgart, München oder Zürich.

## Warum Wrocław als Startpunkt für Enterprise AI funktioniert

Wrocław ist der ungewöhnlichste Enterprise-AI-Markt Polens, weil hier zwei Welten kollidieren: traditionelle Industrie und Banking-Outsourcing. Wer einen AI Agent baut, der gleichzeitig in einem Bosch-Werk und einer UBS-Operation funktioniert, hat eine Architektur entwickelt, die in jedem anderen polnischen Standort eine Konfigurationsänderung weit ist. Die Politechnika Wrocławska liefert Engineers, die diese Doppelwelt verstehen, und das Wrocław Tech-Ökosystem ist nach [Krakau](/de/ai-agents-krakau/) das zweitgrößte des Landes.

Für deutsche Mittelständler mit polnischen Tochterunternehmen ist Wrocław häufig der erste Auslandsstandort, an dem produktive KI tatsächlich gebraucht wird - eine erfolgreiche Wrocław-Implementierung wird damit zur Blaupause für die anschließende Skalierung. Hinzu kommt die geografische Nähe zur deutschen Grenze: Die Bahn von Berlin nach Wrocław braucht knapp vier Stunden, ein Vor-Ort-Termin lässt sich an einem Arbeitstag erledigen. Diese Kombination aus westeuropäischer Erreichbarkeit, mitteleuropäischen Talent-Kosten und strikter EU-Regulierung macht Wrocław zu einem Standort, der in keinem deutschen Konzern-Portfolio fehlen sollte. Governance by Design ist hier keine Marketing-Phrase, sondern Voraussetzung für die Akzeptanz beim Mutterkonzern - und genau die Voraussetzung, die ein erfolgreich implementierter Decision Layer von Anfang an erfüllt. Mehr zu unserem Vorgehen in Polen finden Sie auf der [Polen-Übersicht](/de/ai-agents-polen/).

--- AI Agents für Unternehmen in Zürich | Gosign ---
> Enterprise AI Agents für Zürich. Schweizer DSG-konform, EU AI Act ready für EU-Geschäft. Auditierbare KI für die Schweizer Finanzmetropole.

## Zürich ist der einzige europäische Finanzplatz, an dem AI-Architektur ohne EU AI Act geplant werden muss - und genau das ist der strategische Vorteil

Die Schweiz ist nicht in der EU. Wer Zürich als Markt versteht, beginnt mit dieser Tatsache: Der EU AI Act gilt hier nicht direkt, die DSGVO ist nicht das massgebliche Datenschutzrecht, und die BaFin hat keine Zuständigkeit. Stattdessen gilt das nFADP, das revidierte Schweizer Datenschutzgesetz seit September 2023, und die FINMA als eidgenössische Finanzmarktaufsicht. Im Paradeplatz-Quartier sitzen UBS - nach der Übernahme der Credit Suisse 2023 die mit Abstand grösste Schweizer Bank - sowie Zurich Insurance Group und Swiss Re als zwei der weltweit grössten Rückversicherer. ABB hat Konzernzentrale in Oerlikon, Sika in Baar, Holcim in Jona. Google betreibt in Zürich eines seiner grössten Engineering Center ausserhalb der USA. Diese Mischung erzeugt einen AI-Markt mit hoher technischer Reife und einem regulatorischen Rahmen, der pragmatischer und sektor-spezifischer aufgebaut ist als die EU-Regulierung.

## Drei regulatorische Hürden, die im Zürcher Markt jede AI-Initiative formen

Die erste Hürde ist die FINMA als Finanzaufsicht. Sie hat 2024 ihre Erwartungen an Governance von AI-Modellen in Banken und Versicherungen in einem eigenen Aufsichtspapier konkretisiert - mit klaren Anforderungen an Modellrisiko, Erklärbarkeit und Auditierbarkeit. UBS, Zurich Insurance, Swiss Re und die hier ansässigen Privatbanken müssen jede AI-Komponente in Risikomanagement, Underwriting oder Wealth Management gegen diese FINMA-Erwartungen validieren. Die zweite Hürde ist der EDÖB als eidgenössischer Datenschutz- und Öffentlichkeitsbeauftragter und das nFADP - das neue Datenschutzgesetz seit 2023. Es ist mit der DSGVO im Wesentlichen kompatibel, hat aber eigene Pflichten zu Privacy by Design, Profiling und automatisierten Entscheidungen, die gesondert nachgewiesen werden müssen. Die dritte Hürde ist der Schweizer AI-Regulierungsdiskurs selbst: Der Bundesrat hat 2024 entschieden, dass die Schweiz keinen eigenen umfassenden AI Act schaffen wird, sondern sektor-spezifisch reguliert - was bedeutet, dass FINMA, Swissmedic und das BAKOM jeweils eigene Anforderungen an AI in ihren Domänen formulieren. Wer in Zürich plant, muss die jeweilige Sektor-Aufsicht im Detail kennen. Mehr Hintergrund unter [Governance EU AI Act](/de/governance/eu-ai-act/) - die EU-Logik bleibt für Schweizer Unternehmen mit EU-Geschäft ein zweiter Compliance-Vektor.

## Typische Einsatzszenarien in Zürich

Bei UBS und im weiteren Schweizer Banking-Umfeld sehen wir Wealth-Management-Reporting-Agenten, die strukturierte Kundenkommunikation und Performance-Reports vorbereiten - der Kundenberater entscheidet, der Agent strukturiert. Bei Zurich Insurance unterstützen Agenten die Schadenregulierung in der Sach- und Lebensversicherung, mit klarer Anreicherung der Schadensmeldung um Vertragsdaten, Sachverständigen-Gutachten und Plausibilitäts-Checks - die Letztentscheidung trifft ein Sachbearbeiter mit Versicherungs-Hintergrund. Bei Swiss Re geht es um Rückversicherungs-Modellierung und Cat-Modelling, in denen Underwriter die Ergebnisse als Vorschlag erhalten und die endgültige Akzeptanz verantworten. ABB arbeitet an Industrial-Control-System-Use-Cases, in denen Industrie-Operator die Letztentscheidung treffen. Google Zurich nutzt eigene Engineering-Tooling und ist als Markt für externe Agent-Architektur weniger relevant - aber das technische Talent-Umfeld in Zürich ist davon stark geprägt. Bei Sika und Holcim sehen wir Document-Agenten für Vertragsanalyse und Sicherheitsdatenblätter im Bauchemie-Umfeld. In allen Cases hält der [Decision Layer](/de/decision-layer/) die Begründungskette als Audit Trail vor - in einer Form, die sowohl FINMA-Anforderungen als auch nFADP-Pflichten gleichzeitig erfüllt.

## Wie Gosign aus Hamburg Zürich betreut

Gosign hat keine Schweizer Niederlassung. Der Schweizer Markt akzeptiert deutsche Dienstleister ohne lokale Tochter, solange die Datenhaltung, das Engineering und die Vertragsstruktur klar geregelt sind. Konkret heisst das: Wir arbeiten als deutsche GmbH mit Sitz in Hamburg, die Vertragsstruktur folgt Schweizer Recht oder einem dualen Modell, die Datenhaltung erfolgt entweder auf Schweizer Cloud-Infrastruktur (Swisscom, Exoscale) oder in einem nach nFADP-Standards betriebenen EU-Setup mit den entsprechenden Schutzmassnahmen. Discovery-Workshops machen wir vor Ort in Zürich - der Direktflug Hamburg-Zürich braucht eine Stunde Flugzeit, der ICE über Basel ist eine sinnvolle Alternative. In der Engineering-Phase arbeiten wir remote mit zweiwöchentlichen Vor-Ort-Tagen und Schwerpunkt auf den FINMA-relevanten Validierungsterminen. Wichtig ist die explizite Trennung zwischen den Regelsätzen für Schweizer Daten und den Regelsätzen für EU-Daten - der Decision Layer trägt beide Logiken parallel, weil viele Schweizer Konzerne EU-Geschäft haben und beide Regime gleichzeitig erfüllen müssen. Cluster wie das ETH AI Center, der Impact Hub Zürich und die Zurich Insurance Innovation nutzen wir für technischen Austausch.

## Warum Zürich als Startpunkt für Enterprise AI funktioniert

Die Schweiz hat einen strukturellen Vorteil, den die EU-Märkte nicht haben: Die Regulierung ist sektor-spezifisch, pragmatisch und in der Regel weniger formalistisch als der EU AI Act. Wer in Zürich einen ersten AI Agent in einem regulierten Umfeld produktiv stellt, hat ihn gegen die FINMA-Erwartungen, gegen das nFADP und gegen den schweizerischen Anspruch an technische Sauberkeit verteidigt. Diese Architektur ist anschliessend für eine Skalierung in den EU-Raum vorbereitet, weil die zugrundeliegende Modellgovernance bereits den höchsten Standard erfüllt. Hinzu kommt das technische Umfeld: Die ETH Zürich ist eine der weltweit führenden ML-Forschungseinrichtungen, das ETH AI Center bündelt rund 100 Forschungsgruppen, und Google Zurich, IBM Research Zurich sowie das CERN-Umfeld in der Westschweiz machen den Markt zu einem der reifsten technischen Standorte Europas. Wer in 4-6 Wochen einen ersten AI Agent in einem Schweizer Konzern produktiv hat, baut auf einem Markt auf, der pragmatische Architektur belohnt und unnötige Bürokratie vermeidet. Mehr zum Vorgehen unter [AI Agents Leistungen](/de/leistungen/ai-agents/).

--- Woran Sie ein belastbares 203er-Angebot erkennen - die 8-Punkte-Prüfliste ---
> Acht Prüffragen an jeden KI-Anbieter für Kanzleien und Berufsgeheimnisträger: AVV, § 203-Abs.-4-Verpflichtung, Subunternehmer-Kette, EU-Deployment, Drittland, Retention, Einwilligung. Mit Belegform und Stolperfalle je Punkt - frei zugänglich, druckfreundlich.

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">So nutzen Sie diese Liste</h2>
<p class="text-body-lg text-gosign-text-light">
Der Markt für „§ 203-konforme" KI-Angebote wächst schneller als seine Belege: In unserem eigenen Markt-Screening vom 22.07.2026 hatten rund 8 von rund 25 geprüften Anbietern im DACH-Markt überhaupt ein belastbares Vertragsartefakt. Die Antwort darauf ist kein Misstrauen, sondern eine Methode: <strong class="text-gosign-dark">Stellen Sie jede der acht Fragen - und lassen Sie sich die Antwort als Dokument oder Konfigurations-Nachweis zeigen, nicht als Satz.</strong> Jeder Punkt nennt dafür die Belegform und die typische Stolperfalle.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Die Messlatte dahinter, transparent benannt: ein berufsrechts- und § 203-konformer Bezugsweg nach der DAV-Linie (SN 32/2025); gerichtlich nicht abschließend geklärt. Die konservativere BRAK-Linie (Möglichkeit der Kenntnisnahme genügt) nennen wir mit - und für Steuerberatung, Wirtschaftsprüfung und Notariat sind die eigenen Normen und Kammer-Linien maßgeblich (§ 62a StBerG, § 50a WPO, § 18 BNotO). Die dogmatische Herleitung jedes Punkts steht im Erklärstück <a href="/de/berufsgeheimnistraeger/203er-kette/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Die 203er-Kette: Acht Glieder zwischen Mandat und Modell</a> - diese Seite ist seine Werkzeug-Form.
</p>
</div>
</section>

<!-- W5-EINBAU-HINWEIS (kein Livetext): Optionaler PDF-per-Mail-Block.
Sobald das DOI-Segment 203-pruefliste live ist (Strecke + PDF siehe
docs/domain/203-readiness-report-vorlagen.md §1.2/§1.3), kann der Einbau hier
eine schlanke CTA-Zeile ergänzen: "Die Prüfliste als PDF für Ihre Ablage
erhalten" (EbookModal-Muster, Doppel-Opt-in, Briefing-Checkbox separat und nie
vorangekreuzt). Der Seiteninhalt bleibt davon unberührt vollständig ungated -
ein Gate je Seite, keine Konkurrenz zum Report-Gate des Readiness-Checks. -->

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Die 8-Punkte-Prüfliste</h2>
<div class="space-y-8 mt-8">

<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">☐ 1. Gibt es einen KI-spezifischen AVV nach Art. 28 DSGVO?</p>
<p class="text-body-lg text-gosign-text-light mt-2"><strong class="text-gosign-dark">Woran Sie es erkennen:</strong> Der AVV ist vor Vertragsschluss einsehbar und behandelt Prompt-Inhalte als eigene Datenkategorie, regelt Logging-Policy und Umgebungstrennung - nicht nur die Standard-SaaS-Klauseln.</p>
<p class="text-body-lg text-gosign-text-light mt-2"><strong class="text-gosign-dark">Stolperfalle:</strong> Ein generischer SaaS-AVV ohne KI-Bezug - oder die Behauptung, der AVV sei bereits die § 203-Absicherung. Er ist Punkt 1 von 8, nicht die Antwort auf alles.</p>
</div>

<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">☐ 2. Existiert eine eigenständige Verschwiegenheitsverpflichtung nach § 203 Abs. 4 StGB?</p>
<p class="text-body-lg text-gosign-text-light mt-2"><strong class="text-gosign-dark">Woran Sie es erkennen:</strong> Eine eigenständige Urkunde, die die mitwirkenden Personen des Dienstleisters zur Verschwiegenheit verpflichtet und über die Strafbarkeit nach § 203 StGB belehrt - als Dokument, einsehbar VOR Vertragsschluss und vor jeder Registrierung.</p>
<p class="text-body-lg text-gosign-text-light mt-2"><strong class="text-gosign-dark">Stolperfalle:</strong> DSGVO-übliche Vertraulichkeitsklauseln („unsere Mitarbeiter sind zur Vertraulichkeit verpflichtet") als Ersatz - sie sind arbeitsrechtlich, nicht strafrechtlich unterlegt. Zweite Stolperfalle: die Urkunde gibt es „nach Vertragsschluss".</p>
</div>

<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">☐ 3. Ist die Subunternehmer-Kette vollständig benannt - und jede Station verpflichtet oder nachweisbar ohne Klartext-Zugriff?</p>
<p class="text-body-lg text-gosign-text-light mt-2"><strong class="text-gosign-dark">Woran Sie es erkennen:</strong> Eine benannte, aktuelle Subprozessoren-Liste mit Änderungsmitteilung, die auch den Cloud-Provider und den Modell-Betreiber hinter dem Anbieter ausweist.</p>
<p class="text-body-lg text-gosign-text-light mt-2"><strong class="text-gosign-dark">Stolperfalle:</strong> Die Kette endet beim Vertragspartner. Besonders prüfwürdig bei Google-basierten Setups: Google bietet keine § 203-Verschwiegenheits-Zusatzvereinbarung an, nur das Cloud Data Processing Addendum - diese Lücke muss der Anbieter in seiner eigenen Kette kompensieren und das auch offen sagen.</p>
</div>

<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">☐ 4. Steht der Anbieter selbst als verpflichtetes Glied in der Kette?</p>
<p class="text-body-lg text-gosign-text-light mt-2"><strong class="text-gosign-dark">Woran Sie es erkennen:</strong> Nachweis, dass das eigene Personal nach § 203 Abs. 4 StGB verpflichtet und belehrt ist, plus eine beschriebene No-Human-Access-Architektur (Pseudonymisierung, klartextfreier Audit-Trail, protokollierte Ausnahmen).</p>
<p class="text-body-lg text-gosign-text-light mt-2"><strong class="text-gosign-dark">Stolperfalle:</strong> Der Anbieter definiert sich aus der Kette heraus („wir sehen die Daten ja nicht") - oder verkauft die Redaktions-Schicht als Erfüllungsbedingung. Pseudonymisierung ist Datenminimierung und zweite Verteidigungslinie; die rechtliche Linie tragen Verpflichtung und Vertragskette.</p>
</div>

<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">☐ 5. Nennt der Anbieter den konkreten EU-Deployment-Typ - oder nur den Kontinent?</p>
<p class="text-body-lg text-gosign-text-light mt-2"><strong class="text-gosign-dark">Woran Sie es erkennen:</strong> Ein Konfigurations-Nachweis mit dem konkreten Deployment-Typ: bei Azure OpenAI die EU Data Zones (EU-only-Processing), bei Google-basierten Setups EU-Endpunkt, deaktiviertes Caching und dokumentierte No-Persistence-Konfiguration.</p>
<p class="text-body-lg text-gosign-text-light mt-2"><strong class="text-gosign-dark">Stolperfalle:</strong> „Läuft in der EU" als Marketing-Satz: Ein Standard-Global-Deployment in einer EU-Region kann die Verarbeitung global routen - die Region ist nicht der Deployment-Typ.</p>
</div>

<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">☐ 6. Sind Drittlandtransfer UND berufsrechtliche Auslandsschranke als getrennte Prüfungen beantwortet?</p>
<p class="text-body-lg text-gosign-text-light mt-2"><strong class="text-gosign-dark">Woran Sie es erkennen:</strong> Ein Transfer Impact Assessment (TIA) mit DPF-Status je Anbieter in der Kette - und zusätzlich eine Antwort auf die Auslandsschranke (§ 43e Abs. 4 BRAO, § 62a StBerG, § 50a WPO): Dienstleister im Ausland nur bei vergleichbarem Geheimnisschutz.</p>
<p class="text-body-lg text-gosign-text-light mt-2"><strong class="text-gosign-dark">Stolperfalle:</strong> Beide Prüfungen in einem Satz verrührt - oder die Auslandsschranke fehlt ganz, weil nur eine DSGVO-Checkliste abgearbeitet wurde. US-Sub-Processing kann trotz Standardvertragsklauseln berufsrechtlich unzulässig sein. Und „CLOUD-Act-frei" darf nur behaupten, wer strukturell keinen US-Konzern in der Kette hat.</p>
</div>

<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">☐ 7. Gibt es einen vertraglichen Training-Ausschluss und eine Fristen-Matrix pro Datenart?</p>
<p class="text-body-lg text-gosign-text-light mt-2"><strong class="text-gosign-dark">Woran Sie es erkennen:</strong> Vertrag plus Konfigurations-Nachweis: kein Training auf Ihren Eingaben, und für jede Datenart eine definierte Frist (Auszug der Matrix unten). Die konkreten Fristen je Modell-Weg gehören in den Modellkatalog des Anbieters, nicht in eine Fußnote.</p>
<p class="text-body-lg text-gosign-text-light mt-2"><strong class="text-gosign-dark">Stolperfalle:</strong> Mündliche Zusagen statt Vertragstext - und verschwiegene Ausnahmen: Bestimmte Premium-Modellklassen sind über Cloud-Plattformen nur mit 30-Tage-Prompt-Retention und verpflichtender Datenweitergabe an den Modell-Anbieter verfügbar und damit für Berufsgeheimnisträger-Workloads ausgeschlossen, unabhängig von der Modell-Qualität.</p>
</div>

<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">☐ 8. Liefert der Anbieter Muster für Mandanteneinwilligung und Transparenzhinweis mit?</p>
<p class="text-body-lg text-gosign-text-light mt-2"><strong class="text-gosign-dark">Woran Sie es erkennen:</strong> Muster-Dokumente für die ausdrückliche Einwilligung (§ 62a StBerG, § 50a WPO; anwaltlich § 43e Abs. 5 BRAO bei einzelmandatsbezogener Beauftragung) und für die Transparenzinformation nach Art. 13/14 DSGVO - plus Zulieferbausteine für Ihre DSFA nach Art. 28 Abs. 3 lit. f DSGVO.</p>
<p class="text-body-lg text-gosign-text-light mt-2"><strong class="text-gosign-dark">Stolperfalle:</strong> Der Anbieter schweigt zur Einwilligungsfrage und lässt seine Kunden das schwierigste Glied allein lösen. Eine Muster-Mandanteneinwilligung samt Transparenzhinweis ist Bestandteil des Gosign-203er-Vertragskits, das frei einsehbar ist (v0.4, intern mehrstufig rechtsgeprüft; die externe anwaltliche Freigabe steht aus) - als Muster zur anwaltlichen Einzelfall-Anpassung, ohne Gewähr.</p>
</div>

</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Auszug: die Fristen-Matrix zu Punkt 7</h2>
<p class="text-body-lg text-gosign-text-light mb-6">
Vier Datenarten, vier Anforderungen - lassen Sie sich zeigen, wo jede davon im Vertrag oder in der Konfiguration steht:
</p>
</div>
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 overflow-x-auto">
<table class="w-full text-left text-small border-collapse">
<thead>
<tr>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Datenart</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Anforderung an die Frist</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Warum</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Klartext-Eingaben (Prompts, Dokumente)</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Transient - keine Persistenz über die Verarbeitung hinaus</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Kern des No-Persistence-Arguments beider Rechtslinien</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Pseudonym-Mappings</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">TTL-gebunden mit definierter Löschfrist</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Die Wieder-Einsetzung braucht den Schlüssel nur begrenzt</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Audit-Protokoll (klartextfrei)</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">GoBD-orientierte Aufbewahrung</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Nachweisbarkeit ohne Geheimnis-Inhalt</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Vertrags- und Abrechnungsdaten</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Gesetzliche Fristen (HGB/AO)</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Handels- und steuerrechtliche Aufbewahrungspflicht</td></tr>
</tbody>
</table>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Acht Ja sind ein Anfang - so geht es weiter</h2>
<p class="text-body-lg text-gosign-text-light">
Kann ein Anbieter alle acht Punkte mit Dokumenten und Nachweisen belegen, haben Sie eine tragfähige Grundlage - dann beginnt die Einordnung, welcher Bezugsweg zu Ihrer Organisation passt. Drei Wege dafür:
</p>
<div class="space-y-6 mt-8">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Die Rechtslage und Bezugswege im Überblick</p>
<p class="text-body-lg text-gosign-text-light mt-1">Die Einstiegsseite <a href="/de/berufsgeheimnistraeger/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">KI für Berufsgeheimnisträger (§ 203 StGB)</a> ordnet Rechtslinien, Berufsgruppen und die Bezugsweg-Treppe ein.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Die Herleitung hinter jedem Punkt</p>
<p class="text-body-lg text-gosign-text-light mt-1">Das Erklärstück <a href="/de/berufsgeheimnistraeger/203er-kette/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Die 203er-Kette</a> vertieft jedes Glied mit Dogmatik, Quellen und der Prüftabelle - diese Prüfliste ist seine komprimierte Werkzeug-Form.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Anbieter-Typen im Vergleich</p>
<p class="text-body-lg text-gosign-text-light mt-1">Wie sich die Angebots-Typen am Markt strukturell unterscheiden - und an welchen Punkten dieser Liste sie typischerweise scheitern - zeigt der <a href="/de/berufsgeheimnistraeger/vergleich-203-anbieter/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Vergleich der 203er-Anbieter-Typen</a>. Wo Ihre eigene Organisation steht, beantwortet der <a href="/de/203-readiness-check/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">203-Readiness-Check</a> in 10 Fragen, Ergebnis sofort.</p>
</div>
</div>
<p class="text-body text-gosign-text-light mt-8">
Diese Prüfliste prüft Belegbarkeit, keine Qualitätsurteile - und sie ist keine Rechtsberatung. Die berufsrechtliche Prüfung des Einzelfalls obliegt dem Berufsträger bzw. seinen rechtlichen Beratern; die strafrechtliche Einordnung automatisierter KI-Verarbeitung ist gerichtlich nicht abschließend geklärt.
</p>
</div>
</section>

--- Die 203er-Kette: Acht Glieder zwischen Mandat und Modell ---
> Die 203er-Kette in acht Gliedern: AVV, Abs.-4-Verpflichtung, Subunternehmer, EU-Deployment, Drittland, Retention, Einwilligung - Prüfraster gegen Anbieter-Claims nach der DAV-Linie (SN 32/2025); gerichtlich nicht abschließend geklärt.

<!-- Einordnung -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Warum eine Kette - und nicht ein Zertifikat</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Wer Anbieter-Claims wie „§ 203-konform" prüfen will, braucht ein Prüfraster, kein Vertrauen. Die 203er-Kette ist dieses Raster: acht Glieder aus Vertrag und Technik, die zusammen den Bezugsweg tragen. Jedes Glied ist einzeln prüfbar - als Dokument, als Konfiguration oder als benannte Zuständigkeit. Fehlt eines, hängt die gesamte Aussage in der Luft. Dieses Erklärstück vertieft die Kette, die die Übersichtsseite <a href="/de/berufsgeheimnistraeger/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">KI für Berufsgeheimnisträger (§ 203)</a> einführt - Glied für Glied, mit der Prüffrage und der Belegform dazu.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Der dogmatische Rahmen dahinter, transparent benannt: § 203 Abs. 3 Satz 2 StGB <strong>erlaubt</strong> die Einbindung mitwirkender Personen - dazu zählen nach herrschender Lesart auch IT- und KI-Dienstleister. § 203 Abs. 4 Satz 2 Nr. 1 StGB verlangt dafür deren <strong>Verpflichtung zur Verschwiegenheit</strong>. Und die technische Linie „kein menschlicher Klartext-Zugriff" adressiert das Tatbestandsmerkmal <strong>„offenbaren"</strong> in Absatz 1: Nach der DAV-Linie (SN 32/2025) liegt bei rein automatisierter Verarbeitung ohne menschliche Kenntnisnahme schon kein Offenbaren vor - gerichtlich nicht abschließend geklärt. Die BRAK ist konservativer: Nach ihrem KI-Leitfaden (Stand 12/2024) kann bereits die Möglichkeit der Kenntnisnahme genügen. Deshalb fährt die Kette beide Linien parallel - Vertrag <strong>und</strong> Technik als Belt-and-Suspenders-Risikoargument, nicht als kumulative Rechtsbedingung.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Zur strafrechtlichen Präzision gehört auch: § 203 StGB ist ein reines Vorsatzdelikt und nach § 205 StGB ein Antragsdelikt. Es geht in dieser Kette nicht um eine Drohkulisse, sondern um Nachweisbarkeit - wem gegenüber kann eine Kanzlei belegen, dass ihr Bezugsweg trägt?
</p>
<p class="text-small text-gosign-text-light mt-4">
Quellen: DAV-Stellungnahme SN 32/2025 (anwaltverein.de), BRAK-Leitfaden zum KI-Einsatz, Stand 12/2024 (brak.de); Abruf jeweils 2026-07-22.
</p>
</div>
</div>
</section>

<!-- Glied 1 -->
<section id="glied-1-avv" class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Glied 1: Der Auftragsverarbeitungsvertrag (Art. 28 DSGVO)</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Die Basis jeder Auftragsverarbeitung: Zwecke, Datenkategorien, technische und organisatorische Maßnahmen, Weisungsrechte, Löschpflichten. Für KI-Infrastruktur muss der AVV mehr regeln als ein Standard-SaaS-Vertrag - Prompt-Inhalte als eigene Datenkategorie, Logging-Policy, Umgebungstrennung. Was ein KI-AVV konkret abdecken muss, steht im Anforderungskatalog mit 25 Prüffragen: <a href="/de/governance/avv-checkliste/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">AVV-Checkliste für KI-Infrastruktur</a>.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Entscheidend für die Kette: Der AVV allein ist <strong>nicht</strong> die § 203-Absicherung. Er ist Glied 1 von 8 - die datenschutzrechtliche Grundlage, auf der die strafrechtliche Verpflichtung (Glied 2) aufsetzt.
</p>
</div>
</div>
</section>

<!-- Glied 2 -->
<section id="glied-2-verpflichtung" class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Glied 2: Die Verschwiegenheitsverpflichtung (§ 203 Abs. 4 Satz 2 Nr. 1 StGB)</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Das Glied, das die meisten Anbieter-Claims nicht belegen können: eine <strong>strafbewehrte Verpflichtung</strong> der beim Dienstleister mitwirkenden Personen zur Geheimhaltung (§ 203 Abs. 4 Satz 2 Nr. 1 StGB) - strafbewehrt, weil diese Personen bei unbefugtem Offenbaren nach § 203 Abs. 4 Satz 1 StGB selbst strafbar sind. Textform und Belehrung über die Strafbarkeit verlangt nicht § 203 StGB selbst, sondern das Berufsrecht (§ 43e BRAO, § 62a StBerG, § 50a WPO; für Notare § 26a BNotO). DSGVO-übliche Vertraulichkeitsklauseln („Mitarbeiter sind zur Vertraulichkeit verpflichtet") erfüllen diese Funktion nicht - sie sind arbeitsrechtlich, nicht strafrechtlich unterlegt. Die Auswahl- und Überwachungsverantwortung bleibt dabei beim Berufsträger: § 43e Abs. 3 BRAO verlangt die sorgfältige Auswahl des Dienstleisters, und die laufende Überwachung - bis zur Beendigung der Zusammenarbeit bei Pflichtverstößen - bleibt seine Aufgabe.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Die Prüffrage an jeden Anbieter: Ist die Verpflichtung dokumentiert und <strong>vor</strong> Vertragsschluss einsehbar? Bewährte Praxis dafür - Belegbarkeit, keine Vorgabe des § 203 selbst - ist eine eigenständige Urkunde statt einer Klausel im Hauptvertrag. In unserem eigenen Markt-Screening vom 22.07.2026 hatten rund 8 von rund 25 geprüften Anbietern im DACH-Markt überhaupt ein belastbares Vertragsartefakt; die Kombination aus frei einsehbarem Dokument vor jeder Registrierung, eigenständiger Abs.-4-Urkunde als Beleg und anwaltlicher Freigabe war zum Stichtag unbesetzt. Der Rest fährt Marketing-Claims.
</p>
</div>
</div>
</section>

<!-- Glied 3 -->
<section id="glied-3-subunternehmer" class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Glied 3: Die Subunternehmer-Kette</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Die Verpflichtung endet nicht beim Vertragspartner. Wer verarbeitet tatsächlich? Der SaaS-Anbieter? Dessen Cloud-Provider? Der Modell-Betreiber dahinter? Jede Station der Kette muss entweder selbst verpflichtet sein (Abs. 4) oder nachweisbar keinen Klartext-Zugriff haben - es ist die Weitergabe derselben Abs.-4-Verpflichtung entlang der Kette, nicht drei verschiedene Normen. Eine benannte, aktuelle Subprozessoren-Liste mit Änderungsmitteilung ist deshalb Pflicht-Artefakt - nicht Kür.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Konkret heißt das: Bei einem Kanzlei-Chat auf Azure-Basis gehören Microsoft-Vertragslinie und Deployment-Typ in die Prüfung. Bei Google-basierten Setups gehört die Besonderheit hinein, dass Google <strong>keine</strong> § 203-Verschwiegenheits-Zusatzvereinbarung anbietet - nur das Cloud Data Processing Addendum mit DSGVO-üblicher Vertraulichkeit. Diese Lücke muss ein Anbieter in seiner eigenen Kette kompensieren, und er muss das auch sagen.
</p>
<p class="text-small text-gosign-text-light mt-4">
Quelle: Google-Cloud-Dokumentation (Cloud Data Processing Addendum); Abruf 2026-07-22.
</p>
</div>
</div>
</section>

<!-- Glied 4 -->
<section id="glied-4-gosign" class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Glied 4: Gosign selbst als verpflichtetes Glied</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Ein Bezugsweg-Anbieter, der sich selbst aus der Kette herausdefiniert, hat sie nicht verstanden. Gosign steht als Verarbeiter <strong>in</strong> der Kette: eigenes Personal zur Geheimhaltung verpflichtet (§ 203 Abs. 4 Satz 2 Nr. 1 StGB) und nach dem Berufsrecht der Auftraggeber über die Strafbarkeit belehrt - es ist dieselbe Abs.-4-Verpflichtung, die die Kanzlei an Gosign weitergibt und Gosign an Personal wie Subprozessoren weiterreicht -, Gosign als benannte mitwirkende Person im AVV, Mapping-Key-Handling und Retention vertraglich geregelt.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Die Architektur dahinter ist auf No-Human-Access im Regelbetrieb ausgelegt - vorgesehen sind Pseudonymisierung vor dem Modell-Aufruf, Wieder-Einsetzung danach, ein klartextfreier Audit-Trail und protokollierte Break-Glass-Ausnahmen mit Vier-Augen-Prinzip. Wichtig in der Einordnung: Diese Redaktions-Schicht ist <strong>Datenminimierung und Defense-in-Depth</strong> - sie ist nicht die Erfüllungsbedingung des § 203, sondern senkt das Restrisiko der beiden Rechtslinien aus dem Einstieg.
</p>
</div>
</div>
</section>

<!-- Glied 5 -->
<section id="glied-5-eu-deployment" class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Glied 5: EU-Region und Data Zones</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
„Läuft in der EU" ist eine Deployment-Eigenschaft, kein Marketing-Satz - und sie ist pro Bezugsweg unterschiedlich konkret. Bei Azure OpenAI sind die <strong>EU Data Zones</strong> (DataZone Standard/Provisioned mit EU-only-Processing) der § 203-relevante Deployment-Typ; ein Standard-Global-Deployment in einer „EU-Region" genügt nicht, weil die Verarbeitung global routen kann. Bei Google-basierten Setups gehören EU-Endpunkt, deaktiviertes Caching und die dokumentierte No-Persistence-Konfiguration in die Prüfung.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Die Prüffrage: Nennt der Anbieter den konkreten Deployment-Typ - oder nur den Kontinent? Die generische Infrastruktur-Ebene (EU-Regionen, Datenhaltungs-Optionen) vertieft <a href="/de/governance/data-residency/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Datenresidenz &amp; DSGVO</a>.
</p>
<p class="text-small text-gosign-text-light mt-4">
Quellen: Microsoft-Learn-/Azure-Dokumentation (EU Data Zones), Google-Cloud-Dokumentation (Data Governance); Abruf jeweils 2026-07-22.
</p>
</div>
</div>
</section>

<!-- Glied 6 -->
<section id="glied-6-drittland" class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Glied 6: Drittlandtransfer - Art. 44 ff. DSGVO, CLOUD Act, DPF-Status, Auslandsschranke</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Zwei getrennte Prüfungen, die oft in einem Satz verrührt werden:
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong>Datenschutzrechtlich</strong> (Art. 44 ff. DSGVO): Bei US-Anbietern bleibt die CLOUD-Act-Exposition auch bei EU-Deployment bestehen - der US-Mutterkonzern kann zur Herausgabe verpflichtet werden. Ein Transfer Impact Assessment (TIA) mit dem DPF-Status je Anbieter und ergänzenden Maßnahmen ist deshalb Pflichtbaustein, keine Formalie. „CLOUD-Act-frei" darf nur behaupten, wer strukturell keinen US-Konzern in der Kette hat - das trifft auf EU-Inferenz offener Modelle und auf deutsche Rechenzentrums-Anbieter mit § 203-Verschwiegenheitsvereinbarung zu, nicht auf Azure- oder Google-Wege. Welche Bezugswege das strukturell erfüllen, ordnet die <a href="/de/berufsgeheimnistraeger/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Bezugswege-Übersicht</a> ein.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong>Berufsrechtlich</strong> (die Auslandsschranke): § 43e Abs. 4 BRAO, § 62a StBerG und § 50a WPO erlauben die Einschaltung von Dienstleistern im Ausland nur bei <strong>vergleichbarem Geheimnisschutz</strong>. US-Sub-Processing kann also unabhängig von SCCs und TIA berufsrechtlich unzulässig sein - ein Glied, das reine DSGVO-Checklisten systematisch übersehen.
</p>
</div>
</div>
</section>

<!-- Glied 7 -->
<section id="glied-7-retention" class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Glied 7: Training-Ausschluss und Retention - die Fristen-Matrix</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Zwei Fragen pro Modell-Weg: Wird mit den Eingaben trainiert? Und wie lange liegen Prompts oder Antworten irgendwo? Die Antworten sind pro Bezugsweg und pro Modellklasse unterschiedlich - deshalb gehört in jede Kette ein vertraglicher Training-Ausschluss und eine <strong>Fristen-Matrix pro Datenart</strong>, die mindestens diese vier Anforderungen regelt:
</p>
</div>
<div class="mt-8 overflow-x-auto">
<table class="w-full text-left text-small border-collapse">
<thead>
<tr>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Datenart</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Anforderung an die Frist</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Warum</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Klartext-Eingaben (Prompts, Dokumente)</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Transient - keine Persistenz über die Verarbeitung hinaus</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Kern des No-Persistence-Arguments beider Rechtslinien</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Pseudonym-Mappings</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">TTL-gebunden mit definierter Löschfrist</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Die Wieder-Einsetzung braucht den Schlüssel nur begrenzt</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Audit-Protokoll (klartextfrei)</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">GoBD-orientierte Aufbewahrung</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Nachweisbarkeit ohne Geheimnis-Inhalt</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Vertrags- und Abrechnungsdaten</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Gesetzliche Fristen (HGB/AO)</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Handels- und steuerrechtliche Aufbewahrungspflicht</td></tr>
</tbody>
</table>
</div>
<div class="max-w-narrow">
<p class="text-body-lg text-gosign-text-light mt-6">
Dass Retention über Tauglichkeit entscheidet, zeigt ein konkreter Fall: Bestimmte Premium-Modellklassen sind über Cloud-Plattformen nur mit 30-Tage-Prompt-Retention und verpflichtender Datenweitergabe an den Modell-Anbieter verfügbar - für Berufsgeheimnisträger-Workloads damit ausgeschlossen, unabhängig davon, wie gut das Modell ist. Die konkreten Fristen je Kombination gehören in den Modellkatalog des Anbieters, nicht in eine Fußnote.
</p>
<p class="text-small text-gosign-text-light mt-4">
Quelle: Google-Cloud-Dokumentation (Abuse Monitoring, Covered Models); Abruf 2026-07-22.
</p>
</div>
</div>
</section>

<!-- Glied 8 -->
<section id="glied-8-einwilligung" class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Glied 8: Mandanteneinwilligung und Transparenz (Art. 13/14 DSGVO)</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Das letzte Glied schließt die Kette zur Mandantschaft. Erstens die <strong>Transparenzpflichten</strong> nach Art. 13/14 DSGVO: Die Datenschutzhinweise der Kanzlei müssen die KI-Verarbeitung und die Dienstleister-Kette abbilden. Zweitens - je nach Berufsrecht - die <strong>Mandanten- bzw. bei Notaren Beteiligten-Einwilligung</strong>: § 62a Abs. 5 StBerG und § 50a Abs. 5 WPO verlangen sie bei mandatsbezogener Auslagerung regelmäßig ausdrücklich; anwaltlich verlangt § 43e Abs. 5 BRAO die Einwilligung der Mandantschaft, wenn sich die Beauftragung des Dienstleisters auf ein einzelnes Mandat bezieht; für Notare verlangt § 26a Abs. 4 BNotO die Einwilligung der Beteiligten, wenn die Dienstleistung unmittelbar einem einzelnen Amtsgeschäft dient. Ein Anbieter, der zur Einwilligungsfrage schweigt, lässt seine Kunden das schwierigste Glied allein lösen.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Muster-Einwilligungen (Mandanten- und Beteiligten-Variante) und Muster-Transparenzhinweis sind Bestandteil des Gosign-Vertragskits - frei einsehbar (v0.4, intern mehrstufig rechtsgeprüft; die externe anwaltliche Freigabe steht aus), als Muster zur anwaltlichen Einzelfall-Anpassung, ohne Gewähr.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Frei einsehbar vor jeder Registrierung - v0.4, intern mehrstufig rechtsgeprüft; Muster zur anwaltlichen Einzelfall-Anpassung, ohne Gewähr. Die sieben Bausteine:
</p>
<ul class="mt-4 space-y-2 text-body text-gosign-text-light">
<li><a href="/downloads/203-vertragskit/README.md" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Nutzungs-Rahmen und Disclaimer (README)</a></li>
<li><a href="/downloads/203-vertragskit/zusatzvereinbarung-203-abs4.md" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Verschwiegenheits-Zusatzvereinbarung (§ 203 Abs. 4 StGB)</a></li>
<li><a href="/downloads/203-vertragskit/avv-baustein-gosign.md" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">AVV-Baustein mit Gosign-Selbstverpflichtung (Art. 28 DSGVO)</a></li>
<li><a href="/downloads/203-vertragskit/subprozessoren.md" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Subprozessoren-Liste</a></li>
<li><a href="/downloads/203-vertragskit/tia-scc-baustein.md" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Drittlandtransfer-Baustein (TIA/SCC, Art. 44 ff. DSGVO)</a></li>
<li><a href="/downloads/203-vertragskit/dsfa-vorlage.md" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">DSFA-Vorlage (Art. 35 DSGVO)</a></li>
<li><a href="/downloads/203-vertragskit/retention-matrix-einwilligung-transparenz.md" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Retention-Matrix, Muster-Einwilligungen, Transparenzhinweis</a></li>
</ul>
</div>
</div>
</section>

<!-- DSFA -->
<section id="dsfa" class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Der verlinkte Baustein: die DSFA (Art. 35 DSGVO)</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Kein neuntes Glied, aber Pflicht-Anbau: Für KI-Verarbeitung von Mandats- und Gesundheitsdaten ist regelmäßig eine Datenschutz-Folgenabschätzung nötig. Der Verarbeiter schuldet dabei Assistenz nach Art. 28 Abs. 3 lit. f DSGVO - konkret Zulieferbausteine zu Verarbeitungsbeschreibung, technischen und organisatorischen Maßnahmen und Restrisiken, die die Kanzlei in ihre DSFA übernimmt. Eine DSFA-Vorlage mit genau diesen Zulieferbausteinen gehört zum Gosign-Vertragskit - frei einsehbar wie die Muster aus Glied 8 (Download-Liste dort).
</p>
</div>
</div>
</section>

<!-- Prüftabelle -->
<section id="prueffragen" class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Acht Fragen, die jede Anbieter-Prüfung beantworten muss</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Die Kette als Prüfraster, komprimiert auf eine Frage und eine Belegform pro Glied. Antwortet ein Anbieter auf eine der acht Fragen mit einem Satz statt mit einem Dokument oder einem Konfigurations-Nachweis, ist das die Stelle, an der der Claim reißt:
</p>
</div>
<div class="mt-8 overflow-x-auto">
<table class="w-full text-left text-small border-collapse">
<thead>
<tr>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">#</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Glied</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Prüffrage</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Belegform</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">1</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">AVV</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">KI-spezifischer AVV (Prompts als Datenkategorie, Logging-Policy)?</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Dokument, einsehbar</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">2</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Abs.-4-Verpflichtung</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Verpflichtung zur Geheimhaltung dokumentiert - bewährt: eigenständige Urkunde inklusive Belehrung?</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Dokument, vor Vertragsschluss</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">3</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Subunternehmer</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Vollständige Kette benannt, jede Station verpflichtet oder zugriffslos?</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Subprozessoren-Liste</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">4</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Anbieter selbst</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Eigenes Personal verpflichtet, No-Human-Access-Architektur beschrieben?</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Verpflichtungs-Nachweis + Architektur-Doku</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">5</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">EU-Deployment</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Konkreter Deployment-Typ (z. B. EU Data Zone) statt „EU-Region"?</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Konfigurations-Nachweis</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">6</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Drittland</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">TIA/DPF-Status + Auslandsschranke (§ 43e Abs. 4 BRAO) geprüft?</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">TIA-Dokument</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">7</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Retention</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Fristen-Matrix pro Datenart, Training-Ausschluss vertraglich?</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Vertrag + Konfiguration</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">8</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Mandantschaft</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Muster-Einwilligung + Transparenzhinweis mitgeliefert?</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Muster-Dokumente</td></tr>
</tbody>
</table>
</div>
<div class="max-w-narrow">
<p class="text-small text-gosign-text-light mt-4">
Diese Tabelle prüft Belegbarkeit, keine Qualitätsurteile - und sie ist keine Rechtsberatung.
</p>
</div>
</div>
</section>

<!-- Abgrenzung -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Abgrenzung und Einstieg</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Die 203er-Kette ist die berufsgeheimnisträger-spezifische Klammer über zwei generischen Prüfwerkzeugen: Die <a href="/de/governance/avv-checkliste/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">AVV-Checkliste</a> stellt die 25 Prüffragen an jeden KI-AVV (alle Branchen), <a href="/de/governance/data-residency/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Datenresidenz &amp; DSGVO</a> ordnet Deployment- und Datenhaltungs-Optionen. Beide decken je ein Glied dieser Kette ab - die Kette verbindet sie mit der strafrechtlichen und berufsrechtlichen Ebene.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Den Einstieg in Rechtslage, Bezugswege und Lösungs-Treppe gibt die Übersichtsseite <a href="/de/berufsgeheimnistraeger/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">KI für Berufsgeheimnisträger (§ 203)</a>. Die berufsgruppen-spezifische Rechtsgrundlage mappen die Detailseiten: <a href="/de/berufsgeheimnistraeger/anwaelte/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Rechtsanwälte (§ 43e BRAO)</a> und <a href="/de/berufsgeheimnistraeger/steuerberater-wp/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Steuerberater / Wirtschaftsprüfer (§ 62a StBerG, § 50a WPO)</a>.
</p>
</div>
</div>
</section>

--- Dedizierte Kanzlei-Instanz: KI-Chat mit eigener Subdomain, Datenbank und Schlüsseln - ab 349 € ---
> Die dedizierte KI-Instanz für Kanzleien bis 50 Personen: eigene Subdomain, eigene Datenbank, eigene Schlüssel, § 203-Vertragskette im Setup. 349/790/1.490 € im Monat, 14 Tage kostenlos testen.

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-body-lg text-gosign-text-light">
Eine eigene Instanz statt einer geteilten Plattform: eigene Subdomain, eigene Datenbank, eigene Schlüssel - eingerichtet in Tagen, 14 Tage kostenlos testbar, ohne Zahlungsdaten. <strong class="text-gosign-dark">Sie erkennen sich hier wieder, wenn Ihre Kanzlei 1 bis 50 Personen zählt, niemand einen Cloud-Tenant administrieren will - und KI trotzdem heute starten soll, nicht nach einem IT-Projekt.</strong>
</p>
<p class="text-body text-gosign-text-light mt-4">
Die Kanzlei-Instanz ist Stufe 1 der <a href="/de/berufsgeheimnistraeger/angebot/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Bezugsweg-Treppe</a>. Sie läuft unter der Produktmarke <a href="https://www.veryai.de/" rel="noopener" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">veryai.de</a>, ein Produkt der Gosign GmbH - die Vertragskette zeichnet die Gosign GmbH, deshalb wohnt der Nachweis auf dieser Firmen-Domain.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Was Sie bekommen</h2>
<div class="space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Dedizierte Instanz unter eigener Subdomain</p>
<p class="text-body-lg text-gosign-text-light mt-1">Ihre Kanzlei bekommt eine eigene Instanz unter ihrer Subdomain - mit eigener Datenbank und eigenen Schlüsseln, kein geteilter Mandanten-Pool. Das ist der architektonische Kern des Angebots und der Unterschied zu mandantenfähigen Plattformen.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Datei-Upload und Vorlagen</p>
<p class="text-body-lg text-gosign-text-light mt-1">Upload von Kanzlei-Dokumenten - Verträge, Bescheide, Korrespondenz - direkt in den Chat, plus Vorlagen für wiederkehrende Aufgaben: Fristen-Schreiben, Zusammenfassungen, Erst-Entwürfe. Die fachliche Prüfung jedes Ergebnisses bleibt beim Berufsträger.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">100 € KI-Budget inklusive, Abrechnung per Rechnung</p>
<p class="text-body-lg text-gosign-text-light mt-1">Jedes Paket enthält 100 € KI-Nutzungs-Budget im Monat - ein harter Deckel statt offener Verbrauchsrechnung, damit die Kosten planbar bleiben. Abgerechnet wird per Rechnung; es gibt keinen Zahlungsdienstleister-Zwang und keine Kreditkarten-Pflicht.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Die Vertragskette gehört zum Setup</p>
<p class="text-body-lg text-gosign-text-light mt-1">Verpflichtung des Dienstleisters zur Geheimhaltung nach § 203 Abs. 4 Satz 2 Nr. 1 StGB, in Textform und unter Belehrung über die strafrechtlichen Folgen wie es das Berufsrecht verlangt (§ 43e BRAO, § 62a StBerG, § 50a WPO), AVV und Einwilligungs-Muster für Ihre Mandanten - die Kette ist Teil des Setups, nicht Ihre Hausaufgabenliste. Die acht Glieder im Detail erklärt die <a href="/de/berufsgeheimnistraeger/203er-kette/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">203er-Kette</a>; das Vertragskit ist frei einsehbar (v0.4, intern mehrstufig rechtsgeprüft), die externe anwaltliche Freigabe steht aus.</p>
<p class="text-body text-gosign-text-light mt-3">Frei einsehbar vor jeder Registrierung - v0.4, intern mehrstufig rechtsgeprüft; Muster zur anwaltlichen Einzelfall-Anpassung, ohne Gewähr. Die sieben Bausteine:</p>
<ul class="mt-3 space-y-2 text-body text-gosign-text-light">
<li><a href="/downloads/203-vertragskit/README.md" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Nutzungs-Rahmen und Disclaimer (README)</a></li>
<li><a href="/downloads/203-vertragskit/zusatzvereinbarung-203-abs4.md" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Verschwiegenheits-Zusatzvereinbarung (§ 203 Abs. 4 StGB)</a></li>
<li><a href="/downloads/203-vertragskit/avv-baustein-gosign.md" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">AVV-Baustein mit Gosign-Selbstverpflichtung (Art. 28 DSGVO)</a></li>
<li><a href="/downloads/203-vertragskit/subprozessoren.md" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Subprozessoren-Liste</a></li>
<li><a href="/downloads/203-vertragskit/tia-scc-baustein.md" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Drittlandtransfer-Baustein (TIA/SCC, Art. 44 ff. DSGVO)</a></li>
<li><a href="/downloads/203-vertragskit/dsfa-vorlage.md" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">DSFA-Vorlage (Art. 35 DSGVO)</a></li>
<li><a href="/downloads/203-vertragskit/retention-matrix-einwilligung-transparenz.md" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Retention-Matrix, Muster-Einwilligungen, Transparenzhinweis</a></li>
</ul>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Diese Modelle stecken in Ihrer Instanz</p>
<p class="text-body-lg text-gosign-text-light mt-1">Gemini und Claude (Opus/Sonnet/Haiku) über EU-Endpunkte - ab Tag 1; ChatGPT (die GPT-Modelle von OpenAI) über Microsoft Azure - die Einrichtung samt Microsoft-Freigaben (Professional Secrecy Amendment über den CSP-Weg) ist Teil Ihres Setups; dazu in Deutschland selbst betriebene Open-Weights-Modelle. Details im <a href="/de/ki-modelle-berufsgeheimnistraeger/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Modellkatalog</a>.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Redaktions-Gateway: in Umsetzung</p>
<p class="text-body-lg text-gosign-text-light mt-1">Die PII-Redaktion vor dem Modell-Aufruf mit klartextfreiem Audit-Trail ist für alle Stufen der Treppe als Standard-Architektur vorgesehen und für die Kanzlei-Instanz in Umsetzung - wir schreiben hier bewusst nur an, was zum Kaufzeitpunkt existiert. Sie ist Datenminimierung und zweite Verteidigungslinie; die Verschwiegenheits-Absicherung trägt die Vertragskette, deren Bausteine als Muster-Kit frei einsehbar sind (v0.4, intern mehrstufig rechtsgeprüft; die externe anwaltliche Freigabe steht aus).</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Warum dediziert statt geteilt?</h2>
<p class="text-body-lg text-gosign-text-light mb-8">
Die meisten KI-Angebote im Kanzlei-Markt sind mandantenfähige Plattformen. Die Kanzlei-Instanz setzt auf Single-Tenant-Architektur - fünf Unterschiede, die bei der Nachfrage von Berufsaufsicht oder Mandant den Ton der Antwort bestimmen:
</p>
<div class="overflow-x-auto">
<table class="w-full text-left text-small border-collapse">
<thead>
<tr>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Frage</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Geteilte Plattform</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Dedizierte Kanzlei-Instanz</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Wo liegen die Daten?</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Gemeinsame Datenbank vieler Kanzleien, logisch getrennt</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Eigene Datenbank nur für Ihre Kanzlei</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Wer hält die Schlüssel?</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Plattformweite Schlüsselverwaltung</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Instanz-eigene Schlüssel pro Kanzlei</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Unter welcher Adresse arbeiten Sie?</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Gemeinsame Plattform-Domain</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Eigene Subdomain Ihrer Kanzlei</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Was sieht die Berufsaufsicht?</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Mandanten-Trennung als Betreiber-Zusicherung</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Instanz-Isolation als Architektur-Eigenschaft, pro Kanzlei nachweisbar</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Was passiert bei Kündigung?</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Daten-Export aus dem geteilten Bestand</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Export plus bestätigte Löschung der gesamten Instanz samt Datenbank</td></tr>
</tbody>
</table>
</div>
<p class="text-body text-gosign-text-light mt-6">
Die Tabelle beschreibt architektonische Unterschiede, keine Qualitätsurteile über andere Anbieter. Geteilte Plattformen können sauber gebaut sein - aber die Antwort auf die Datenhaltungs-Frage bleibt dort eine Zusicherung des Betreibers, hier eine Eigenschaft der Architektur.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Die Rechtslage in Kürze</h2>
<p class="text-body-lg text-gosign-text-light">
Die Kanzlei-Instanz ist als berufsrechts- und § 203-konformer Bezugsweg nach der DAV-Linie (SN 32/2025) gebaut: Bei rein automatisierter Verarbeitung ohne menschlichen Klartext-Zugriff liegt danach schon kein Offenbaren vor - gerichtlich ist das nicht abschließend geklärt, und die BRAK vertritt die konservativere Linie, nach der bereits die Möglichkeit der Kenntnisnahme kritisch ist. Deshalb ruht das Angebot nicht auf einer Rechtsansicht, sondern auf der Vertragskette: Verpflichtung in Textform, AVV, Einwilligungs-Muster, Subprozessor-Transparenz.
</p>
<p class="text-body text-gosign-text-light mt-4">
Was das für Ihre Berufsgruppe konkret heißt - § 43e BRAO mit Auslandsschranke für Anwälte, § 62a StBerG und § 50a WPO mit Mandanteneinwilligung für Steuerberater und Wirtschaftsprüfer - steht auf den Berufsgruppen-Seiten: <a href="/de/berufsgeheimnistraeger/anwaelte/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Rechtsanwälte</a> und <a href="/de/berufsgeheimnistraeger/steuerberater-wp/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Steuerberater und Wirtschaftsprüfer</a>; den berufsgruppenübergreifenden Einstieg gibt die <a href="/de/berufsgeheimnistraeger/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Übersichtsseite KI für Berufsgeheimnisträger</a>. Welche Modelle über welche Bezugswege gedeckt sind, zeigt der <a href="/de/ki-modelle-berufsgeheimnistraeger/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Modell-Katalog für Berufsgeheimnisträger</a> - der 203er-Status ist immer eine Eigenschaft der Kombination aus Modell und Bezugsweg, nie des Modells allein.
</p>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Was Kanzleien mit der Instanz konkret tun</h2>
<p class="text-body-lg text-gosign-text-light">
Der Alltag, nicht die Vision: Ein Schriftsatz-Entwurf entsteht aus dem hochgeladenen Bescheid. Eine Mandanten-E-Mail wird aus Stichpunkten zur versandfertigen Fassung. Ein 80-Seiten-Vertrag wird auf die fünf Klauseln verdichtet, die zu prüfen sind. Wiederkehrende Schreiben laufen über Vorlagen statt über Copy-and-paste aus alten Akten. Die fachliche Prüfung jedes Ergebnisses bleibt beim Berufsträger - die KI liefert Entwürfe, keine Freigaben.
</p>
<p class="text-body text-gosign-text-light mt-4">
Der Maßstab dabei: Der konforme Weg muss im Alltag genauso schnell erreichbar sein wie der private ChatGPT-Account eines Mitarbeiters - sonst entsteht Schatten-KI. Warum Consumer-Dienste die Kette nicht erfüllen und wie die Instanz als Alternative gebaut ist, zeigt die Seite <a href="/de/berufsgeheimnistraeger/chatgpt-alternative-kanzleien/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">ChatGPT-Alternative für Kanzleien</a>.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Die Pakete: drei Größen, ein Leistungsumfang</h2>
<p class="text-body-lg text-gosign-text-light mb-8">
Die Preise sind identisch mit veryai.de - eine Faktenbasis, keine zwei Preislisten. Jedes Paket enthält die dedizierte Instanz, Datei-Upload, Vorlagen, 100 € KI-Budget im Monat und die Vertragskette im Setup; der Unterschied ist die Nutzerzahl.
</p>
<div class="overflow-x-auto">
<table class="w-full text-left text-small border-collapse">
<thead>
<tr>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Paket</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Preis im Monat</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Nutzer</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Enthalten</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Solo</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">349 €</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">bis 10</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Dedizierte Instanz, Datei-Upload, Vorlagen, 100 € KI-Budget, Vertragskette, Rechnung</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Team</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">790 €</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">bis 25</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">wie Solo</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Kanzlei</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">1.490 €</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">bis 50</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">wie Solo</td></tr>
</tbody>
</table>
</div>
<p class="text-body text-gosign-text-light mt-6">
Alle Preise zzgl. USt. Der Test läuft 14 Tage kostenlos und ohne Hinterlegung von Zahlungsdaten; er endet automatisch, wenn Sie nicht verlängern. Bei voller Paket-Belegung liegt der effektive Preis pro Nutzer zwischen rund 30 und 35 €; bei teilbelegten Paketen entsprechend höher (Beispiel: 14 Nutzer im Team-Paket sind rund 56 € je Nutzer). Die Positionierung ist trotzdem keine Preis-Frage, sondern eine Architektur-Frage: dedizierte Instanz statt geteilter Plattform.
</p>
<div class="mt-8 bg-gosign-dark rounded-card p-6 lg:p-8">
<p class="text-body-lg text-white font-semibold">14 Tage kostenlos testen - ohne Zahlungsdaten</p>
<p class="text-body text-white/80 mt-2">veryai.de - ein Produkt der Gosign GmbH. Fragen vorab? <a href="/de/kontakt/" class="text-gosign-accent underline hover:no-underline">Gespräch vereinbaren</a>.</p>
<p class="text-body mt-4"><a href="https://www.veryai.de/?utm_source=gosign.de&utm_medium=referral&utm_campaign=203er-treppe&utm_content=kanzlei-instanz-seite" rel="noopener" data-cta="true" class="inline-block bg-gosign-accent text-gosign-dark font-semibold px-6 py-3 rounded-card hover:bg-gosign-accent-hover transition-colors">Jetzt Test starten</a></p>
</div>
</div>
</section>

--- Setup im eigenen Tenant: KI in Ihrer Cloud - mit Governance und Compliance-Retainer, ab 5.000 € ---
> 203er-Setup im eigenen Microsoft- oder Google-Tenant: Antrags-Begleitung, Governance, EU-Data-Zone-Deployment, Compliance-Retainer. Setup ab 5.000 €, Retainer 500 bis 1.500 € im Monat.

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-body-lg text-gosign-text-light">
Ihre Cloud, Ihre Schlüssel, unsere Begleitung: das 203er-Setup im eigenen Tenant mit Antrags-Begleitung, Governance und Compliance-Retainer. <strong class="text-gosign-dark">Sie erkennen sich hier wieder, wenn Ihre Kanzlei einen eigenen Microsoft- oder Google-Tenant betreibt und die Frage nicht lautet, ob KI kommt, sondern wer die Schlüssel hält, wo die Inferenz läuft und was im Audit-Trail steht.</strong>
</p>
<p class="text-body text-gosign-text-light mt-4">
Das Tenant-Setup ist Stufe 2b der <a href="/de/berufsgeheimnistraeger/angebot/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Bezugsweg-Treppe</a>: Die Kette bleibt im eigenen Haus, die Kanzlei zeichnet gegenüber Mandanten selbst - und Gosign liefert das, was in Eigenregie am häufigsten scheitert: die Governance-Struktur, die Antrags-Strecke beim Cloud-Anbieter und die laufende Pflege der Rechts- und Modell-Lage.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Was Sie bekommen</h2>
<div class="space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Antrags-Begleitung beim Cloud-Anbieter</p>
<p class="text-body-lg text-gosign-text-light mt-1">Auf dem Microsoft-Weg: Begleitung der Amendment-Strecke (Microsoft bietet ein Professional Secrecy Amendment über CSP-Partner) und des Antrags auf Modified Abuse Monitoring. Auf dem Google-Weg: Begleitung des Ausnahme-Antrags für das Abuse Monitoring Ihres Projekts - Google gewährt keine § 203-Verschwiegenheits-Zusatzvereinbarung, deshalb ist die Ausnahme-Strecke plus kompensierende Vertrags- und Technik-Kette hier der Weg. Die Hintergründe zum Azure-Weg vertieft die Seite zum <a href="/de/berufsgeheimnistraeger/azure-engpass/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Azure-Engpass</a>.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Governance-Setup und EU-Data-Zone-Deployment</p>
<p class="text-body-lg text-gosign-text-light mt-1">Rollen und Zugriffe, Freigabe-Matrix pro Mandats-Klasse, Deployment in einer EU Data Zone, dokumentierte Konfiguration - als geprüfte Struktur statt gewachsener Einstellungen. Ergebnis ist eine Governance-Dokumentation, mit der die Fragen von Berufsaufsicht, Mandant oder Versicherer beantwortbar sind: Wer hält die Schlüssel, wo läuft die Inferenz, wer darf was.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Gateway-Anbindung als Standard-Architektur</p>
<p class="text-body-lg text-gosign-text-light mt-1">Die Redaktion vor dem Modell-Aufruf mit klartextfreiem Audit-Trail ist auch im Tenant-Setup als Standard-Architektur vorgesehen: Pseudonymisierung hin, Wieder-Einsetzung zurück, protokollierte Ausnahmen. Ob das Redaktions-Gateway in Ihrem Tenant oder als Gosign-Dienst betrieben wird, legt das Setup-Projekt fest - die Anforderungen (Zero-Retention, Schlüssel nur im KMS, Break-Glass mit Vier-Augen-Protokoll, klartextfreier Audit-Trail) gelten in beiden Topologien. Sie ist Datenminimierung und zweite Verteidigungslinie - die Verschwiegenheits-Absicherung trägt die Vertragskette, deren Glieder die <a href="/de/berufsgeheimnistraeger/203er-kette/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">203er-Kette</a> erklärt.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">DATEV- und DMS-Konnektoren als Festpreis-Add-ons</p>
<p class="text-body-lg text-gosign-text-light mt-1">Einzel-Konnektoren zu DATEV und gängigen Dokumenten-Management-Systemen sind paketierte Add-ons dieser Stufe - zum Festpreis pro Konnektor, den wir im Gespräch nennen. Eigene Agenten und individuelle Integrationen wohnen bewusst eine Stufe höher, im <a href="/de/berufsgeheimnistraeger/angebot-managed-stack/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Managed Stack</a> - so bleibt das Tenant-Setup kalkulierbar.</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Ehrlichkeit vor dem Vertrag: was bei Microsoft und Google liegt</h2>
<p class="text-body-lg text-gosign-text-light">
Zwei Dinge auf dieser Stufe kann kein Dienstleister zusagen - und wer es tut, verspricht fremde Unterschriften: <strong class="text-gosign-dark">Erstens die Eligibility.</strong> Die Abschaltung des Abuse-Monitorings setzt nach der Microsoft-Dokumentation Microsoft-managed- beziehungsweise EA-Status voraus, und die Reichweite des Amendments ist eine Microsoft-Entscheidung je Setup; bei Google braucht jedes Kunden-Projekt eine eigene Abuse-Monitoring-Exception. <strong class="text-gosign-dark">Zweitens der Kalender.</strong> Freigabezeiten liegen beim Anbieter - wir begleiten den Antrag mit Erfahrung und vollständigen Unterlagen, aber wir versprechen keinen fremden Zeitplan.
</p>
<p class="text-body text-gosign-text-light mt-4">
Deshalb beginnt jedes 2b-Projekt mit einer Eligibility-Prüfung vor der Beauftragung: Passt Ihr Vertragsstatus, welcher Weg (Microsoft oder Google) trägt Ihr Setup, was ist realistisch - und wenn die Voraussetzungen fehlen, sagen wir das vorher und zeigen die Alternative auf der Treppe, meist die <a href="/de/berufsgeheimnistraeger/angebot-kanzlei-instanz/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">dedizierte Kanzlei-Instanz</a> oder die <a href="/de/berufsgeheimnistraeger/angebot-token-api/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Token/API-Stufe</a>. Die rechtliche Grundlage bleibt auf allen Wegen dieselbe: ein berufsrechts- und § 203-konformer Bezugsweg nach der DAV-Linie (SN 32/2025), gerichtlich nicht abschließend geklärt - die konservativere BRAK-Linie (Möglichkeit der Kenntnisnahme) nennen wir transparent mit; die berufsgruppen-spezifischen Pflichten stehen auf den Seiten für <a href="/de/berufsgeheimnistraeger/anwaelte/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Rechtsanwälte</a> sowie <a href="/de/berufsgeheimnistraeger/steuerberater-wp/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Steuerberater und Wirtschaftsprüfer</a>, den Gesamt-Einstieg gibt die <a href="/de/berufsgeheimnistraeger/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Übersichtsseite KI für Berufsgeheimnisträger</a>.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Der Compliance-Retainer: Pflege statt Projekt-Ende</h2>
<p class="text-body-lg text-gosign-text-light mb-8">
Ein Tenant-Setup veraltet ohne Pflege - Kammer-Linien bewegen sich, Anbieter ändern Bedingungen, Modelle kommen und fallen aus der Deckung. Der Retainer hält das Setup aktuell, mit einem definierten Leistungsschnitt:
</p>
<div class="space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Quartalsweise: Rechtslage-Review auf Ihr Setup</p>
<p class="text-body-lg text-gosign-text-light mt-1">Was sich bei Kammer-Linien, Anbieter-Bedingungen und Rechtsprechung geändert hat - und was das konkret für Ihre Konfiguration bedeutet, als schriftliche Review mit Handlungs-Punkten.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Laufend: Modell- und Katalog-Updates</p>
<p class="text-body-lg text-gosign-text-light mt-1">Welche Modell-Bezugsweg-Kombinationen neu gedeckt oder gesperrt sind, gepflegt gegen den <a href="/de/ki-modelle-berufsgeheimnistraeger/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Modell-Katalog für Berufsgeheimnisträger</a> - damit die Freigabe-Matrix Ihrer Kanzlei dem Markt folgt, nicht hinterherläuft.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Auf Anlass: Audit-Bereitstellung und Kontingent</p>
<p class="text-body-lg text-gosign-text-light mt-1">Aufbereitete Nachweise, wenn Berufsaufsicht, Mandant oder Versicherer fragen, plus Subprozessor-Monitoring und ein definiertes Stunden-Kontingent für Anpassungen. Was über das Kontingent hinausgeht, wird separat beauftragt - der Retainer bleibt ein standardisiertes Produkt, deshalb trägt er seinen Preis.</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Preis-Rahmen</h2>
<div class="overflow-x-auto">
<table class="w-full text-left text-small border-collapse">
<thead>
<tr>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Baustein</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Preis</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Hinweis</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Setup</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">ab 5.000 €</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Standardisierter Umfang (definierte Checkliste, ein Anbieter, Standard-Deployment); zzgl. Freigabezeit des Cloud-Anbieters</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Compliance-Retainer</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">500 bis 1.500 € im Monat</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Je nach Setup-Umfang und Kontingent; Leistungsschnitt wie oben beschrieben</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">DATEV-/DMS-Konnektor</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Festpreis pro Konnektor</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Paketierte Add-ons; Preis im Gespräch, abhängig vom Zielsystem</td></tr>
</tbody>
</table>
</div>
<p class="text-body text-gosign-text-light mt-6">
Alle Preise zzgl. USt. Der ab-Preis ist erreichbar, kein Lockangebot - er setzt den standardisierten Umfang voraus; was darüber hinausgeht, wird vor der Beauftragung beziffert.
</p>
<p class="text-body-lg text-gosign-text-light mt-6">
<strong class="text-gosign-dark">Für Frühentscheider:</strong> Für die ersten Kanzleien auf dieser Stufe führt Gosign ein Design-Partner-Programm - vergünstigte Konditionen gegen Referenz-Recht und Feedback-Mitwirkung, mit bewusst kleiner Teilnehmerzahl. Die Bedingungen stehen auf der Seite <a href="/de/berufsgeheimnistraeger/design-partner/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Design-Partner-Programm</a>.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Der Weg zum produktiven Tenant</h2>
<div class="space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">1 - Eligibility-Prüfung</p>
<p class="text-body-lg text-gosign-text-light mt-1">Vor jeder Beauftragung: Vertragsstatus, Anbieter-Weg (Microsoft oder Google), realistische Erwartung. Ergebnis ist eine ehrliche Einschätzung - inklusive der Empfehlung einer anderen Stufe, wenn die Voraussetzungen fehlen.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">2 - Antrags-Strecke beim Anbieter</p>
<p class="text-body-lg text-gosign-text-light mt-1">Wir bereiten die Amendment- beziehungsweise Ausnahme-Anträge vollständig vor und begleiten die Strecke. Die Freigabe selbst ist die Entscheidung des Anbieters - dieser Abschnitt läuft mit Status-Transparenz statt Datum.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">3 - Setup und Übergabe</p>
<p class="text-body-lg text-gosign-text-light mt-1">Governance-Struktur, EU-Data-Zone-Deployment, Freigabe-Matrix, Dokumentation - abgenommen mit Ihrer IT, übergeben mit einem Betriebs-Handbuch statt eines Zugangs und guter Wünsche.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">4 - Laufender Betrieb mit Retainer</p>
<p class="text-body-lg text-gosign-text-light mt-1">Ab Übergabe hält der Compliance-Retainer Rechtslage, Modell-Deckung und Nachweise aktuell - mit dem oben beschriebenen Leistungsschnitt. Ihre Kanzlei betreibt, wir pflegen die Konformität.</p>
</div>
</div>
</div>
</section>

--- Managed 203er-Stack: Agenten, Konnektoren und Decision Layer als Projektgeschäft ---
> Der betriebene 203er-Stack für große Kanzleien, Versicherer und Kliniken: Agenten, Konnektoren, Decision-Layer-Architektur und Audit-Trail pro Entscheidung - Projektgeschäft mit Discovery zuerst.

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-body-lg text-gosign-text-light">
Für große Kanzleien, Versicherer und Kliniken: der vollständige Stack als Projektgeschäft - jede Entscheidung dokumentiert, jede Eskalation definiert. <strong class="text-gosign-dark">Sie erkennen sich hier wieder, wenn KI bei Ihnen in Prozesse eingreifen soll - mit Agenten, Konnektoren und einer Architektur, die jede Entscheidung dokumentiert, bevor die Berufsaufsicht danach fragt.</strong>
</p>
<p class="text-body text-gosign-text-light mt-4">
Der Managed Stack ist Stufe 3 der <a href="/de/berufsgeheimnistraeger/angebot/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Bezugsweg-Treppe</a> - und die einzige Stufe, auf der KI nicht nur antwortet, sondern in definierten Grenzen handelt. Genau deshalb ist hier die Entscheidungs-Architektur der Kern des Angebots, nicht das Modell.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Was Sie bekommen</h2>
<div class="space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Agenten für definierte Prozesse</p>
<p class="text-body-lg text-gosign-text-light mt-1">Posteingangs-Triage, Fristen-Extraktion, Dokument-Klassifikation, Entwurfs-Erstellung - Agenten übernehmen definierte Prozess-Schritte mit definierten Grenzen. Was ein Agent darf, steht vor dem Rollout fest, nicht nach dem ersten Vorfall; die fachliche Letztverantwortung bleibt beim Berufsträger.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Konnektoren in die Bestandslandschaft</p>
<p class="text-body-lg text-gosign-text-light mt-1">Individuelle Integrationen in Ihre Fachverfahren, DMS- und Aktensysteme - gebaut für Ihre Landschaft, nicht als Standard-Adapter. Die paketierten DATEV-/DMS-Einzel-Konnektoren wohnen als Festpreis-Add-ons auf der <a href="/de/berufsgeheimnistraeger/angebot-kunden-tenant/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Tenant-Stufe</a>; hier beginnt das Individuelle.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Betrieb durch Gosign</p>
<p class="text-body-lg text-gosign-text-light mt-1">Gosign betreibt den Stack: Monitoring, Modell-Pflege gegen den <a href="/de/ki-modelle-berufsgeheimnistraeger/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Modell-Katalog</a>, Subprozessor-Transparenz, definierte Eskalationspfade. Die Vertragskette liegt der Nutzung zugrunde wie auf jeder Stufe der Treppe - Verpflichtung des Dienstleisters zur Geheimhaltung nach § 203 Abs. 4 Satz 2 Nr. 1 StGB, in Textform und unter Belehrung über die strafrechtlichen Folgen wie es das Berufsrecht verlangt (§ 43e BRAO, § 62a StBerG, § 50a WPO), AVV, Subprozessor-Dokumentation; die Glieder erklärt die <a href="/de/berufsgeheimnistraeger/203er-kette/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">203er-Kette</a>.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Audit-Trail pro Entscheidung</p>
<p class="text-body-lg text-gosign-text-light mt-1">Nicht pro Sitzung, pro Entscheidung: Jeder Agenten-Schritt hinterlässt einen klartextfreien Eintrag - was entschieden wurde, von wem (Mensch, Regelwerk oder KI), auf welcher Grundlage, mit welcher Eskalation. Bei der Nachfrage von Berufsaufsicht oder Wirtschaftsprüfung wandert der Pfad über den Tisch, nicht eine Rekonstruktion aus E-Mails.</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Wer entscheidet? Der Decision Layer gibt die Antwort pro Schritt</h2>
<p class="text-body-lg text-gosign-text-light">
Andere liefern Agenten, die ein Ergebnis produzieren - und lassen offen, wer unterwegs entschieden hat. Der Stack der Stufe 3 setzt auf die <a href="/de/decision-layer/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Decision-Layer-Architektur</a>: Für jeden Prozess-Schritt ist definiert, ob ein Mensch, ein Regelwerk oder die KI entscheidet. Am Beispiel eines Kanzlei-Posteingangs:
</p>
<div class="space-y-6 mt-8">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">MENSCH</p>
<p class="text-body-lg text-gosign-text-light mt-1">Die Architektur erzwingt menschliche Prüfung, wo Ermessen beginnt: Mandats-Annahme, Aussagen mit Rechtswirkung gegenüber Mandanten oder Gerichten, jede Interessenkollisions-Entscheidung. Ein als eilig und fristkritisch erkanntes Schriftstück landet beim zuständigen Berufsträger - die Eskalation ist technisch erzwungen, nicht organisatorisch vereinbart.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">REGELWERK</p>
<p class="text-body-lg text-gosign-text-light mt-1">Deterministische Entscheidungen laufen als Regel, nicht als Modell-Meinung: Ein erkanntes Zustellungsdatum plus Rechtsmittel-Typ ergibt die Frist nach Gesetz - da gibt es nichts zu interpretieren. Die Regel ist versioniert, ihre Anwendung protokolliert.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">KI AUTONOM</p>
<p class="text-body-lg text-gosign-text-light mt-1">Die KI entscheidet eigenständig, wo sie nachweislich zuverlässig ist und die Erlaubnis dafür definiert wurde: Dokument-Typ-Klassifikation, Zuordnung zur Akte, Entwurfs-Erstellung. Unterschreitet die Konfidenz die definierte Schwelle, eskaliert der Schritt an den Menschen - auch das steht im Trail.</p>
</div>
</div>
<p class="text-body text-gosign-text-light mt-8">
Diese Zuordnung - pro Schritt, vor dem Rollout, dokumentiert - ist der Unterschied zwischen einem KI-Werkzeug und einer prüfbaren Prozess-Architektur. Sie ist auf dieser Stufe der eigentliche Kaufgegenstand.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Projekt-Logik: Discovery, Build, Betrieb</h2>
<div class="space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">1 - Discovery</p>
<p class="text-body-lg text-gosign-text-light mt-1">Prozessanalyse mit Ihren Fachleuten: Welche Prozesse tragen Automatisierung, welche Regelwerke gelten, welche Mikro-Entscheidungen stecken in jedem Vorgang und wer sie künftig trifft - Mensch, Regelwerk oder KI. Ergebnis: ein bezifferter Vorschlag mit Umfang, Preis und Zeitplan.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">2 - Build</p>
<p class="text-body-lg text-gosign-text-light mt-1">Ein Agent, ein Prozess - produktiv, mit echtem Audit-Trail und definierten Eskalationen. Erst wenn der erste Prozess trägt, wird verbreitert: weitere Agenten, weitere Konnektoren.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">3 - Betrieb</p>
<p class="text-body-lg text-gosign-text-light mt-1">Gosign betreibt, überwacht und pflegt den Stack - Modell-Updates gegen den Katalog, Rechtslage-Anpassungen, Audit-Bereitstellung auf Anfrage. Der Stack bleibt aktuell, ohne dass Ihr Haus ein KI-Team aufbaut.</p>
</div>
</div>
<p class="text-body-lg text-gosign-text-light mt-8">
Öffentliche Preise trägt diese Stufe bewusst nicht - Umfang und Preis entstehen in der Discovery. Die rechtliche Grundlage ist dieselbe wie auf der ganzen Treppe: ein berufsrechts- und § 203-konformer Bezugsweg nach der DAV-Linie (SN 32/2025), gerichtlich nicht abschließend geklärt - die konservativere BRAK-Linie (Möglichkeit der Kenntnisnahme) nennen wir transparent mit. Die berufsgruppen-spezifische Rechtslage vertiefen die Seiten für <a href="/de/berufsgeheimnistraeger/anwaelte/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Rechtsanwälte</a> sowie <a href="/de/berufsgeheimnistraeger/steuerberater-wp/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Steuerberater und Wirtschaftsprüfer</a>; den Überblick über alle Stufen gibt die <a href="/de/berufsgeheimnistraeger/angebot/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Angebots-Übersicht</a>.
</p>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Drei Häuser, ein Muster</h2>
<p class="text-body-lg text-gosign-text-light mb-8">
Der Stack trägt überall dort, wo Verschwiegenheitspflicht und Prozess-Volumen zusammenkommen - drei typische Profile:
</p>
<div class="space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Große Kanzleien und Rechtsabteilungen</p>
<p class="text-body-lg text-gosign-text-light mt-1">Mehrere Standorte, DMS- und Fachverfahrens-Landschaft, eigene Prozesse - und Dokumentationspflichten, die über einen Chat weit hinausgehen. Typische erste Agenten: Posteingangs-Triage mit Fristen-Erkennung, Akten-Zuordnung, Entwurfs-Erstellung mit definierter Prüfschleife.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Private Versicherer</p>
<p class="text-body-lg text-gosign-text-light mt-1">Auch Angehörige privater Kranken-, Unfall- oder Lebensversicherungen sind Berufsgeheimnisträger nach § 203 StGB - bei hohem Vorgangs-Volumen in der Leistungsprüfung. Was das für den KI-Einsatz bedeutet, ordnet die Seite für die <a href="/de/berufsgeheimnistraeger/pkv/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">private Krankenversicherung</a> ein.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Kliniken und Versorgungs-Träger</p>
<p class="text-body-lg text-gosign-text-light mt-1">Arztbrief-Entwürfe, Befund-Zusammenfassungen, Kodier-Unterstützung - unter ärztlicher Schweigepflicht und mit Systemlandschaften, die Konnektoren statt Insellösungen verlangen. Die medizinische Rechtslage behandeln wir projektbezogen in der Discovery.</p>
</div>
</div>
<p class="text-body text-gosign-text-light mt-8">
Gemeinsam ist allen dreien: Die Frage der Aufsicht kommt sicher - und der Stack ist so gebaut, dass die Antwort vor der Frage existiert. Den Einstieg in die Gesamt-Einordnung gibt die <a href="/de/berufsgeheimnistraeger/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Übersichtsseite KI für Berufsgeheimnisträger</a>.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Wenn eine andere Stufe besser passt</h2>
<p class="text-body-lg text-gosign-text-light">
Der Stack ist die oberste Stufe der Treppe - nicht der Standard-Einstieg. Braucht Ihre Einheit zunächst einen konformen Kanzlei-Chat mit Datei-Upload, startet die <a href="/de/berufsgeheimnistraeger/angebot-kanzlei-instanz/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">dedizierte Kanzlei-Instanz</a> in Tagen und ist 14 Tage kostenlos testbar. Bauen Sie eigene Software und brauchen den konformen Unterbau als API, ist die <a href="/de/berufsgeheimnistraeger/angebot-token-api/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Token/API-Stufe</a> der kürzere Weg. Und soll die Kette im eigenen Microsoft- oder Google-Tenant liegen, ohne dass schon Agenten in Prozesse eingreifen, trägt das <a href="/de/berufsgeheimnistraeger/angebot-kunden-tenant/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Setup im eigenen Tenant</a> dieses Profil. Von jeder dieser Stufen führt ein definierter Weg in den Stack - die Vertrags- und Redaktions-Architektur ist dieselbe, der Ausbau ein Schritt, kein Neuanfang.
</p>
</div>
</section>

--- 203er-Token/API: Die § 203-Vertragskette hinter Ihrer eigenen Software ---
> OpenAI-kompatible API mit § 203-Vertragskette und Redaktions-Gateway für Legal-Tech, Software-Häuser und Kanzleien. Preismodell: Grundgebühr 99 bis 299 € plus Token - konkrete Sätze auf Anfrage.

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-body-lg text-gosign-text-light">
Eine OpenAI-kompatible API mit Verschwiegenheits-Vertragskette und Redaktions-Gateway - für Legal-Tech, Software-Häuser und Kanzleien, die KI in eigene Tools einbinden. <strong class="text-gosign-dark">Sie erkennen sich hier wieder, wenn Sie Software bauen oder betreiben - Legal-Tech, Kanzlei-Software, interne Tools - und die § 203-Vertragskette samt Redaktion als API beziehen wollen, statt sie selbst zu verhandeln.</strong>
</p>
<p class="text-body text-gosign-text-light mt-4">
Token/API ist Stufe 2a der <a href="/de/berufsgeheimnistraeger/angebot/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Bezugsweg-Treppe</a>. Der Wert liegt nicht im Protokoll - OpenAI-kompatible Endpunkte gibt es viele -, sondern in dem, was hinter dem Endpunkt hängt: EU-Inferenz über CLOUD-Act-freie Bezugswege und eine Vertragskette, die bis zum letzten Subunternehmer dokumentiert ist. Die acht Glieder erklärt die <a href="/de/berufsgeheimnistraeger/203er-kette/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">203er-Kette</a>.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Was Sie bekommen</h2>
<div class="space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">OpenAI-kompatibler API-Zugang zu EU-Inferenz</p>
<p class="text-body-lg text-gosign-text-light mt-1">Ihre Software spricht das Format, das sie schon kennt - die Aufrufe laufen zu EU-Inferenz offener Modelle über Bezugswege ohne US-Konzernmutter. Damit entfällt die CLOUD-Act-Frage strukturell, und die berufsrechtliche Auslandsschranke wird nicht berührt. Welche Modell-Bezugsweg-Kombinationen gedeckt sind, zeigt der <a href="/de/ki-modelle-berufsgeheimnistraeger/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Modell-Katalog</a> - der 203er-Status ist eine Eigenschaft der Kombination, nie des Modells allein.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Die Vertragskette als Teil des Produkts</p>
<p class="text-body-lg text-gosign-text-light mt-1">§ 203-Zusatzvereinbarung (Verpflichtung zur Geheimhaltung nach Abs. 4 Satz 2 Nr. 1; Textform und Belehrung über die strafrechtlichen Folgen nach § 43e BRAO / § 62a StBerG / § 50a WPO), AVV-Baustein und Subprozessor-Dokumentation - Sie beziehen die Kette mit dem API-Vertrag, statt sie mit jedem Inferenz-Anbieter einzeln zu verhandeln. Genau diese Verhandlung ist für einzelne Software-Häuser der teuerste Teil des konformen Wegs.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Redaktions-Gateway als Standard-Architektur</p>
<p class="text-body-lg text-gosign-text-light mt-1">Vor dem Modell-Aufruf ist die PII-Redaktion als Standard-Architektur vorgesehen: Pseudonymisierung hin, Wieder-Einsetzung zurück, protokollierte Ausnahmen. Sie ist Datenminimierung nach Art. 5 DSGVO und zweite Verteidigungslinie - die Verschwiegenheits-Absicherung trägt die Vertragskette. Blockierte Modell-Bezugsweg-Kombinationen werden blockiert, nie still durchgereicht.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Klartextfreier Audit-Trail und Budgets pro Mandant</p>
<p class="text-body-lg text-gosign-text-light mt-1">Jeder Aufruf ist einem Mandanten-Kontext zuordenbar, Verbrauchs-Grenzen sind pro Mandant setzbar, und der Audit-Trail dokumentiert Nutzung ohne Mandats-Klartext. Die Frage der Berufsaufsicht nach dem Datenfluss beantwortet Ihr Kunde mit einem Protokoll, nicht mit einer Vermutung.</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Das Preismodell - offen erklärt</h2>
<p class="text-body-lg text-gosign-text-light">
Sie zahlen eine Grundgebühr für die Vertragskette und den Audit-Trail plus die Token zum vereinbarten Satz. Konkret:
</p>
<div class="mt-8 overflow-x-auto">
<table class="w-full text-left text-small border-collapse">
<thead>
<tr>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Baustein</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Rahmen</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Was er abdeckt</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Grundgebühr</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">99 bis 299 € im Monat, je nach Volumen und Support-Umfang</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Bereitstellung der Vertragskette (§ 203-Zusatzvereinbarung, AVV, Subprozessor-Doku), Audit-Trail, Support-Grundlast - unabhängig vom Verbrauch</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Token</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Einkauf plus vereinbarter Aufschlag</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Die Inferenz selbst plus den Mehrwert in der Kette: Vertragskette, Redaktions-Architektur, klartextfreier Audit-Trail</td></tr>
</tbody>
</table>
</div>
<p class="text-body-lg text-gosign-text-light mt-6">
<strong class="text-gosign-dark">Warum „auf Anfrage" statt einer Zahl:</strong> Die § 203-Zusatzvereinbarung des EU-Inferenz-Anbieters unserem EU-Betreiber ist gezeichnet. Feste Token-Sätze veröffentlichen wir erst, wenn unsere Einkaufskonditionen unterschrieben sind - eine vorher genannte Zahl wäre Schein-Präzision, und dieser Funnel lebt davon, dass jede Aussage ihren Status ehrlich trägt. Bis dahin gilt: Preismodell öffentlich, Ihre konkrete Kondition transparent im Gespräch, mit ausgewiesenem Stand.
</p>
<p class="text-body text-gosign-text-light mt-4">
Zur Einordnung des Aufschlags: Regions- und Compliance-Aufschläge sind am Markt etabliert - große Cloud-Anbieter bepreisen EU-Daten-Zonen und Compliance-Zusatzleistungen mit eigenen Aufschlägen, ohne dass darin eine § 203-Leistung steckt. Unser Aufschlag trägt die Vertragskette, die Redaktions-Architektur und den Audit-Trail; er wird pro Vertrag vereinbart und im Angebot ausgewiesen, nicht versteckt.
</p>
<p class="text-body text-gosign-text-light mt-4">
Für den Betrieb des Gateways streben wir eine ISO-27001-Zertifizierung an - beworben wird sie erst, wenn sie erteilt ist. Auch das ist Teil der Status-Ehrlichkeit dieses Angebots.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Die Bezugswege hinter der API: zwei CLOUD-Act-freie Säulen</h2>
<p class="text-body-lg text-gosign-text-light mb-8">
Eine API-Zusage ist nur so belastbar wie die Inferenz dahinter. Die Token/API-Stufe stützt sich auf die beiden CLOUD-Act-freien Säulen der Treppe:
</p>
<div class="space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">EU-Inferenz offener Modelle</p>
<p class="text-body-lg text-gosign-text-light mt-1">EU-Inferenz offener Modelle bei einem europäischen Anbieter ohne US-Konzernmutter - die CLOUD-Act-Frage entfällt strukturell, die berufsrechtliche Auslandsschranke wird nicht berührt. Über diesen Weg laufen Llama 3.3 und 3.1, Mistral 4, Qwen 3.6, Apertus, Gemma und GPT-OSS (Stand der Modellübersicht: 25.07.2026), angebunden über eine OpenAI-kompatible API. Die § 203-Zusatzvereinbarung mit dem Betreiber ist gezeichnet, ebenso der Reseller-Vertrag - die Kette ist auf diesem Weg geschlossen.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">deutsche Rechenzentren eines Telekommunikationskonzerns, über die Gosign-Kette angebunden -</p>
<p class="text-body-lg text-gosign-text-light mt-1">Für den zweiten Weg besteht seit 2021 eine standardisierte § 203-Verschwiegenheitsvereinbarung aus deutschen Rechenzentren; dort läuft unter anderem DeepSeek R1 managed mit explizitem Berufsgeheimnisträger-Bezug in der Anbieter-Dokumentation (Quelle: open-telekom-cloud.com, Abruf 2026-07-22).</p>
</div>
</div>
<p class="text-body text-gosign-text-light mt-8">
Welches Modell für welche Aufgabe über welchen Weg gedeckt ist, hält der <a href="/de/ki-modelle-berufsgeheimnistraeger/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Modell-Katalog</a> aktuell - inklusive der Kombinationen, die für Berufsgeheimnisträger gesperrt sind. Gesperrte Kombinationen werden vom Bezugsweg blockiert, nie still durchgereicht.
</p>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Für wen die API der richtige Einstieg ist - und für wen nicht</h2>
<p class="text-body-lg text-gosign-text-light">
Die API trägt drei Profile: Legal-Tech-Anbieter, die ihren Kanzlei-Kunden einen konformen Unterbau geben wollen. Software-Häuser, die Kanzlei-Software oder interne Tools um KI erweitern. Und Kanzleien mit eigener Entwicklung, die den Bezugsweg nicht selbst verhandeln wollen. Die rechtliche Grundlage ist dieselbe wie auf der ganzen Treppe: ein berufsrechts- und § 203-konformer Bezugsweg nach der DAV-Linie (SN 32/2025), gerichtlich nicht abschließend geklärt - die konservativere BRAK-Linie (Möglichkeit der Kenntnisnahme) nennen wir transparent mit. Die berufsgruppen-spezifische Tiefe steht auf den Seiten für <a href="/de/berufsgeheimnistraeger/anwaelte/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Rechtsanwälte</a> sowie <a href="/de/berufsgeheimnistraeger/steuerberater-wp/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Steuerberater und Wirtschaftsprüfer</a>; den Gesamt-Einstieg gibt die <a href="/de/berufsgeheimnistraeger/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Übersichtsseite KI für Berufsgeheimnisträger</a>.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Zwei Nachbar-Profile gehören auf andere Stufen: Wer nur einen Kanzlei-Chat mit Datei-Upload braucht, startet schneller mit der <a href="/de/berufsgeheimnistraeger/angebot-kanzlei-instanz/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">dedizierten Kanzlei-Instanz</a>. Wer einen eigenen Microsoft- oder Google-Tenant betreibt und die Schlüssel im eigenen Haus halten will, vergleicht die API mit dem <a href="/de/berufsgeheimnistraeger/angebot-kunden-tenant/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Setup im eigenen Tenant</a> - beide Wege stellen wir im Gespräch nebeneinander.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Der Weg zum Start</h2>
<div class="space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">1 - Gespräch und Vertrags-Einsicht</p>
<p class="text-body-lg text-gosign-text-light mt-1">Wir zeigen die Kette im Dokument, nicht im Prospekt: § 203-Zusatzvereinbarung, AVV-Baustein, Subprozessor-Dokumentation - plus das Preismodell mit Ihrer konkreten Kondition und deren Stand.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">2 - Test-Integration gegen Angebot</p>
<p class="text-body-lg text-gosign-text-light mt-1">Ihr Team bindet die API in einer definierten Test-Strecke an - OpenAI-kompatibel, gegen EU-Inferenz, mit Budget-Deckel. So prüfen Sie Antwortqualität und Integrationsaufwand an Ihren echten Anwendungsfällen, bevor Sie sich binden.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">3 - Produktiver Betrieb</p>
<p class="text-body-lg text-gosign-text-light mt-1">Vertragskette gezeichnet, Budgets pro Mandant konfiguriert, Audit-Trail aktiv. Einen Self-Service-Checkout gibt es auf dieser Stufe bewusst nicht - eine Vertragskette, die man versteht, ist Teil des Produkts.</p>
</div>
</div>
</div>
</section>

--- KI für Kanzleien: Das Angebot in vier Stufen - von der Kanzlei-Instanz bis zum Managed Stack ---
> Die Bezugsweg-Treppe für Berufsgeheimnisträger: dedizierte Kanzlei-Instanz ab 349 €, 203er-Token/API, Setup im eigenen Cloud-Tenant ab 5.000 €, Managed 203er-Stack als Projektgeschäft.

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-body-lg text-gosign-text-light">
Der konforme Bezugsweg ist keine Einheitslösung - er richtet sich nach IT-Lage und Größe Ihrer Kanzlei, nicht nach dem Modell. Deshalb führt Gosign das Angebot als Treppe mit vier Stufen: <strong class="text-gosign-dark">dedizierte Kanzlei-Instanz, 203er-Token/API, Setup im eigenen Cloud-Tenant, Managed 203er-Stack</strong>. Auf jeder Stufe gilt dasselbe Prinzip: Die Vertragskette nach § 43e BRAO beziehungsweise § 62a StBerG und § 50a WPO, die Redaktion vor dem Modell-Aufruf und der klartextfreie Audit-Trail gehören zum Leistungsumfang - nie als Aufpreis; den jeweiligen Umsetzungs-Stand weist jede Stufen-Seite offen aus.
</p>
<p class="text-body text-gosign-text-light mt-4">
Diese Seite ordnet die vier Stufen mit Preisen und verlinkt die Detail-Seiten. Die Rechtslage dahinter steht auf der <a href="/de/berufsgeheimnistraeger/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Übersichtsseite KI für Berufsgeheimnisträger</a>, die acht Glieder der Vertragskette erklärt die Seite zur <a href="/de/berufsgeheimnistraeger/203er-kette/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">203er-Kette</a>, und welches Modell über welchen Bezugsweg gedeckt ist, zeigt der <a href="/de/ki-modelle-berufsgeheimnistraeger/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Modell-Katalog für Berufsgeheimnisträger</a>.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">

<div class="max-w-narrow mt-10 p-6 bg-gosign-light border border-gosign-border rounded-card">
<p class="text-h3 font-bold text-gosign-dark">Zwei Wege, und der Unterschied ist keine Frage der Qualität</p>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong class="text-gosign-dark">Wir bauen es in Ihre Umgebung.</strong> Sie haben eine IT-Abteilung, einen eigenen Cloud-Tenant oder ein Rechenzentrum, und die Schlüssel sollen in Ihrer Hand bleiben. Dann richten wir die Kette dort ein, wo Ihre Systeme schon stehen - Stufe 2b und 3. Das ist Projektarbeit mit Discovery, Einrichtung und laufender Betreuung, und sie beginnt bei 5.000 € einmalig.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong class="text-gosign-dark">Oder Sie starten sofort, ohne eigene IT.</strong> Die meisten Kanzleien haben kein Rechenzentrum und wollen keins - für die gibt es die fertige Instanz unter unserer Produktmarke veryai.de: eigener Server in Deutschland, eigene Datenbank, dieselbe Vertragskette, ab 349 € im Monat. Sie registrieren sich und arbeiten; wir übernehmen Betrieb, Verträge und Nachweise.
</p>
<p class="text-body text-gosign-text-light mt-4">
Der Unterschied liegt in der Betriebsverantwortung, nicht im Schutzniveau: Auf beiden Wegen zeichnet die Gosign GmbH dieselbe Verschwiegenheitsverpflichtung, und beide nutzen dieselben geprüften Bezugswege. Wer klein anfängt und später wächst, wechselt die Stufe, ohne die Vertragskette neu zu verhandeln.
</p>
<p class="text-body mt-4"><a href="https://www.veryai.de/?utm_source=gosign.de&utm_medium=referral&utm_campaign=203er-treppe&utm_content=abgrenzung" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Zur fertigen Kanzlei-Instanz auf veryai.de</a></p>
</div>

<h2 class="text-h1 font-bold text-gosign-dark">Die vier Stufen im Überblick</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Jede Karte nennt das Profil, die Leistung und den Preis - die Detail-Seite dahinter beantwortet Leistungsumfang, Vertragskette und die häufigsten Fragen der Stufe.
</p>
</div>
<div class="grid grid-cols-1 md:grid-cols-2 gap-6 lg:gap-8 mt-8">
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8">
<h3 class="text-h3 font-bold text-gosign-dark">Stufe 1 - Dedizierte Kanzlei-Instanz</h3>
<p class="text-body text-gosign-text-light mt-3">
Ein 203er-Chat als Single-Tenant-Instanz: eigene Subdomain, eigene Datenbank, eigene Schlüssel. Datei-Upload und Vorlagen inklusive, betrieben unter der Produktmarke veryai.de, ein Produkt der Gosign GmbH. Für Kanzleien ohne eigene IT, 1 bis 50 Personen.
</p>
<p class="text-body text-gosign-dark font-semibold mt-4">349 € / 790 € / 1.490 € im Monat je Paketgröße - inklusive 100 € KI-Budget, 14 Tage kostenlos testbar, ohne Zahlungsdaten.</p>
<p class="text-body mt-4"><a href="/de/berufsgeheimnistraeger/angebot-kanzlei-instanz/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Details zur Kanzlei-Instanz</a></p>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8">
<h3 class="text-h3 font-bold text-gosign-dark">Stufe 2a - 203er-Token/API</h3>
<p class="text-body text-gosign-text-light mt-3">
OpenAI-kompatibler API-Zugang zu EU-Inferenz mit vollständiger § 203-Vertragskette und Redaktions-Gateway als Standard-Architektur. Für Legal-Tech, Software-Häuser und Kanzleien, die KI in eigene Werkzeuge einbinden.
</p>
<p class="text-body text-gosign-dark font-semibold mt-4">Grundgebühr zwischen 99 und 299 € im Monat plus Token zum vereinbarten Satz - konkrete Sätze auf Anfrage, bis der Reseller-Vertrag gezeichnet ist.</p>
<p class="text-body mt-4"><a href="/de/berufsgeheimnistraeger/angebot-token-api/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Details zu Token und API</a></p>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8">
<h3 class="text-h3 font-bold text-gosign-dark">Stufe 2b - Setup im eigenen Tenant + Compliance-Retainer</h3>
<p class="text-body text-gosign-text-light mt-3">
Aufbau des Bezugswegs im eigenen Microsoft- oder Google-Tenant: Antrags-Begleitung, Governance-Dokumentation, Gateway-Anbindung - danach laufende Betreuung per Retainer. Freigaben und Zeitpläne liegen beim jeweiligen Cloud-Anbieter.
</p>
<p class="text-body text-gosign-dark font-semibold mt-4">Setup ab 5.000 €, zzgl. Freigabezeit des Cloud-Anbieters - Compliance-Retainer zwischen 500 und 1.500 € im Monat.</p>
<p class="text-body mt-4"><a href="/de/berufsgeheimnistraeger/angebot-kunden-tenant/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Details zum Tenant-Setup</a></p>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8">
<h3 class="text-h3 font-bold text-gosign-dark">Stufe 3 - Managed 203er-Stack</h3>
<p class="text-body text-gosign-text-light mt-3">
Der vollständige Stack als Projektgeschäft: Agenten für definierte Prozesse, Konnektoren in die Bestandslandschaft, Betrieb - und ein Audit-Trail, der jede Entscheidung dokumentiert. Für große Kanzleien, Versicherer und Kliniken.
</p>
<p class="text-body text-gosign-dark font-semibold mt-4">Projektgeschäft - Preisfindung pro Projekt nach Discovery.</p>
<p class="text-body mt-4"><a href="/de/berufsgeheimnistraeger/angebot-managed-stack/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Details zum Managed Stack</a></p>
</article>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Welche Stufe passt? Drei Fragen zur Selbst-Einordnung</h2>
<p class="text-body-lg text-gosign-text-light mb-8">
Drei Fragen ordnen fast jedes Kanzlei-Setup - dieselben drei, die wir auch im Gespräch zuerst stellen:
</p>
<div class="space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">1 - Wie groß ist Ihre Einheit?</p>
<p class="text-body-lg text-gosign-text-light mt-1">Bis 50 Personen tragen die Stufen 1 bis 2b. Über 50 Personen, Rechtsabteilung oder Konzern-Struktur: Das Profil spricht für den <a href="/de/berufsgeheimnistraeger/angebot-managed-stack/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Managed Stack</a>, weil Prozess-Integration und Dokumentationspflichten dort über einen Chat weit hinausgehen.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">2 - Betreiben Sie einen eigenen Microsoft- oder Google-Tenant mit eigenem Vertrag?</p>
<p class="text-body-lg text-gosign-text-light mt-1">Ja: Dann kann die Kette im eigenen Haus liegen - das ist das Kern-Profil des <a href="/de/berufsgeheimnistraeger/angebot-kunden-tenant/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Setups im eigenen Tenant</a>. Nein oder unklar: Die <a href="/de/berufsgeheimnistraeger/angebot-kanzlei-instanz/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">dedizierte Kanzlei-Instanz</a> startet ohne jedes Infrastruktur-Projekt - und ob ein eigener Tenant später der bessere Weg ist, klären wir im Gespräch in einer Viertelstunde.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">3 - Was soll die KI können?</p>
<p class="text-body-lg text-gosign-text-light mt-1">Chat mit Datei-Upload und Vorlagen: Stufe 1. KI in eigene Software einbinden: <a href="/de/berufsgeheimnistraeger/angebot-token-api/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Token/API</a>. DATEV- oder DMS-Anbindung: Festpreis-Add-ons der Tenant-Stufe. Eigene Agenten und Prozess-Integration: Managed Stack.</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Was in jeder Stufe enthalten ist</h2>
<p class="text-body-lg text-gosign-text-light">
Die Treppe unterscheidet Bezugswege, nicht Schutzniveaus. Drei Bausteine gehören in jeder Stufe zum Leistungsumfang - nie als Aufpreis; wo ein Baustein noch in Umsetzung ist, sagt die Stufen-Seite das offen:
</p>
<div class="space-y-6 mt-8">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Die Vertragskette</p>
<p class="text-body-lg text-gosign-text-light mt-1">Verpflichtung des Dienstleisters zur Geheimhaltung nach § 203 Abs. 4 Satz 2 Nr. 1 StGB, in Textform und unter Belehrung über die strafrechtlichen Folgen wie es das Berufsrecht verlangt, AVV, Subprozessor-Dokumentation und Einwilligungs-Muster - zugeschnitten auf § 43e BRAO für Anwälte beziehungsweise § 62a StBerG und § 50a WPO für Steuerberater und Wirtschaftsprüfer. Wie die acht Glieder zusammenhängen, zeigt die <a href="/de/berufsgeheimnistraeger/203er-kette/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">203er-Kette</a>.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Redaktion vor dem Modell-Aufruf</p>
<p class="text-body-lg text-gosign-text-light mt-1">Das Redaktions-Gateway ist auf allen Stufen als Standard-Architektur vorgesehen: Pseudonymisierung vor dem Modell-Aufruf, Wieder-Einsetzung danach. Es ist Datenminimierung nach Art. 5 DSGVO und zweite Verteidigungslinie - die Verschwiegenheits-Absicherung selbst trägt die Vertragskette.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Klartextfreier Audit-Trail</p>
<p class="text-body-lg text-gosign-text-light mt-1">Wer hat wann welches Modell über welchen Bezugsweg genutzt - protokolliert ohne Mandats-Klartext. Damit die Frage der Berufsaufsicht oder des Mandanten in Minuten beantwortbar ist, nicht in Tagen.</p>
</div>
</div>
<p class="text-body text-gosign-text-light mt-8">
Jede Leistung hat ihren festen Ort auf der Treppe: Datei-Upload und Vorlagen wohnen in der Kanzlei-Instanz der Stufe 1. Einzel-Konnektoren zu DATEV und gängigen DMS sind Festpreis-Add-ons der Tenant-Stufe 2b. Eigene Agenten und individuelle Integrationen sind Projektleistung des Managed Stacks. So bleibt jede Stufe kalkulierbar - und ein Wechsel nach oben ist ein definierter Schritt statt einer Neuverhandlung.
</p>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Für Ihre Berufsgruppe im Detail</h2>
<p class="text-body-lg text-gosign-text-light">
Die Zulässigkeits-Frage beantworten wir nicht pauschal, sondern pro Berufsgruppe - als berufsrechts- und § 203-konformer Bezugsweg nach der DAV-Linie (SN 32/2025), gerichtlich nicht abschließend geklärt; die konservativere BRAK-Linie, nach der bereits die Möglichkeit der Kenntnisnahme kritisch ist, nennen wir transparent mit. Die Tiefe wohnt auf den Berufsgruppen-Seiten: <a href="/de/berufsgeheimnistraeger/anwaelte/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Rechtsanwälte (§ 43e BRAO)</a> und <a href="/de/berufsgeheimnistraeger/steuerberater-wp/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Steuerberater und Wirtschaftsprüfer (§ 62a StBerG, § 50a WPO)</a>. Welche Modell-Bezugsweg-Kombinationen heute gedeckt sind, hält der <a href="/de/ki-modelle-berufsgeheimnistraeger/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Modell-Katalog</a> aktuell.
</p>
<div class="mt-8 bg-gosign-dark rounded-card p-6 lg:p-8">
<p class="text-body-lg text-white font-semibold">Direkt starten: die Kanzlei-Instanz im 14-Tage-Test</p>
<p class="text-body text-white/80 mt-2">Eigene Subdomain, eigene Datenbank, eigene Schlüssel - eingerichtet in Tagen, kostenlos testbar ohne Zahlungsdaten. veryai.de ist ein Produkt der Gosign GmbH.</p>
<p class="text-body mt-4"><a href="https://www.veryai.de/?utm_source=gosign.de&utm_medium=referral&utm_campaign=203er-treppe&utm_content=angebots-uebersicht" rel="noopener" data-cta="true" class="inline-block bg-gosign-accent text-gosign-dark font-semibold px-6 py-3 rounded-card hover:bg-gosign-accent-hover transition-colors">14 Tage kostenlos testen</a></p>
</div>
</div>
</section>

--- KI für Anwaltskanzleien - § 43e BRAO, § 203 StGB und der Bezugsweg ---
> § 43e BRAO inkl. Auslandsschranke, BRAK-Leitfaden 12/2024, DAV SN 32/2025: was Rechtsanwälte für KI mit Mandatsdaten regeln müssen - und der Bezugsweg in drei Stufen für Kanzleien.

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-body-lg text-gosign-text-light">
Für Rechtsanwälte entscheidet nicht das KI-Modell über die Zulässigkeit, sondern der Bezugsweg: Wer betreibt die Inferenz, wer kann Klartext einsehen, welche Verschwiegenheitsverpflichtung ist in Textform abgeschlossen, und hält die Kette bis zum letzten Subunternehmer? Diese Seite ordnet die anwaltsspezifische Rechtslage - § 43e BRAO mit Textform-, Belehrungs- und Kettenpflicht samt Auslandsschranke, den BRAK-Leitfaden 12/2024 und die DAV-Stellungnahme SN 32/2025 - und zeigt den Bezugsweg in drei Stufen: von der dedizierten Kanzlei-Instanz bis zum Managed Stack.
</p>
<p class="text-body text-gosign-text-light mt-4">
Die berufsgruppenübergreifende Einordnung (§ 203 StGB für Steuerberater, Wirtschaftsprüfer, Versicherer) steht auf der Übersichtsseite <a href="/de/berufsgeheimnistraeger/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">KI für Berufsgeheimnisträger</a>. Die generischen Enterprise-AVV-Prüffragen - Logging, Umgebungstrennung, Subdienstleister - behandelt die <a href="/de/governance/avv-checkliste/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">AVV-Checkliste</a>; hier geht es um die berufsrechtliche Zusatzebene, die ein AVV nicht abdeckt.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Was verlangt § 43e BRAO von jeder Kanzlei?</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
§ 43e BRAO erlaubt es Rechtsanwälten, Dienstleistern Zugang zu Mandatsgeheimnissen zu gewähren - unter vier Bedingungen, die zusammen die anwaltliche Vertragskette bilden. Ein KI-Anbieter ist ein solcher Dienstleister; der Modellbetreiber dahinter ist ein weiterer.
</p>
<div class="mt-8 overflow-x-auto">
<table class="w-full text-left text-small border-collapse">
<thead>
<tr>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Pflicht</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Was sie konkret verlangt</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Konsequenz für den KI-Bezug</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Sorgfältige Auswahl</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Der Dienstleister ist unter Berücksichtigung des Geheimnisschutzes auszuwählen; bei Anhaltspunkten für Verstöße ist die Zusammenarbeit zu beenden.</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Anbieter-Claims reichen nicht - die Kanzlei braucht prüfbare Nachweise zu Betrieb, Region und Zugriffspfaden.</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Textform-Vereinbarung mit Belehrung</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Der Dienstleister ist in Textform zur Verschwiegenheit zu verpflichten und über die strafrechtlichen Folgen einer Verletzung zu belehren.</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Ein AVV nach Art. 28 DSGVO ist keine Verschwiegenheitsurkunde - die Verpflichtung nach § 203 Abs. 4 StGB ist ein eigenes Dokument.</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Kettenverpflichtung</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Zieht der Dienstleister weitere Personen hinzu, muss er sie in gleicher Weise verpflichten.</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Die Kette muss bis zum Modellbetreiber und dessen Rechenzentrums-Dienstleistern reichen - genau dort reißt sie bei den meisten Setups.</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Auslandsschranke (Abs. 4)</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Dienstleistungen aus dem Ausland sind nur zulässig, wenn der dortige Geheimnisschutz dem inländischen vergleichbar ist.</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">US-Sub-Processing kann unabhängig vom Vertragstext unzulässig sein - der CLOUD Act öffnet US-Behörden Zugriffspfade, die kein Amendment schließt. Die Auslandsschranke ist eine eigene Prüfung neben Art. 44 ff. DSGVO.</td></tr>
</tbody>
</table>
</div>
<p class="text-body text-gosign-text-light mt-6">
Ein AVV regelt Datenschutz. Die Verpflichtung nach § 203 Abs. 4 StGB regelt das Berufsgeheimnis. Das eine ersetzt das andere nicht.
</p>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">BRAK-Linie und DAV-Linie - wann ist ein Geheimnis offenbart?</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Die zentrale Auslegungsfrage beim KI-Einsatz lautet: Offenbart eine Kanzlei ein Geheimnis im Sinne des § 203 Abs. 1 StGB, wenn ein automatisiertes System es verarbeitet, ohne dass ein Mensch beim Anbieter den Klartext liest? Die beiden anwaltlichen Organisationen beantworten sie unterschiedlich - und beide Antworten gehören auf den Tisch.
</p>
<div class="mt-8 overflow-x-auto">
<table class="w-full text-left text-small border-collapse">
<thead>
<tr>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Position</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Kernaussage</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Konsequenz für Kanzleien</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">BRAK-Leitfaden (Stand 12/2024)</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Konservative Linie: Bereits die Möglichkeit der Kenntnisnahme durch Personen beim Anbieter ist kritisch - nicht erst der tatsächliche Zugriff.</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Setups so wählen, dass menschliche Kenntnisnahme technisch und organisatorisch ausgeschlossen wird - und die Vertragskette trotzdem steht.</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">DAV-Stellungnahme SN 32/2025</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">No-Human-Access-Linie: Rein automatisierte Verarbeitung ohne menschlichen Klartext-Zugriff ist kein Offenbaren im Sinne des Abs. 1.</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Konfigurationen ohne Prompt-Einsicht, ohne menschliches Abuse-Review und ohne Speicherung über die Verarbeitung hinaus werden zum tragenden Argument.</td></tr>
</tbody>
</table>
</div>
<p class="text-body-lg text-gosign-text-light mt-6">
Für jede Aussage auf dieser Seite gilt deshalb die Sprachregel: Es geht um einen berufsrechts- und § 203-konformen Bezugsweg nach der DAV-Linie (SN 32/2025) - gerichtlich ist die Frage nicht abschließend geklärt, und die konservativere BRAK-Linie wird mitgenannt. Ein Setup, das beiden Linien standhalten will, kombiniert daher zwei Ebenen: die Verschwiegenheitsverpflichtung nach § 203 Abs. 4 StGB als Vertragslinie und den Ausschluss menschlichen Klartext-Zugriffs als Technik-Linie. Das ist bewusste doppelte Absicherung als Risiko-Argument - keine kumulative Rechtsbedingung.
</p>
</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Vorsatzdelikt, Antragsdelikt - die nüchterne Einordnung</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
§ 203 StGB ist ein reines Vorsatzdelikt: Fahrlässiges Offenbaren erfüllt den Tatbestand nicht. Verfolgt wird nur auf Strafantrag (§ 205 StGB), in der Regel des Mandanten. Wer daraus Entwarnung ableitet, übersieht zwei Dinge: Bedingter Vorsatz genügt - wer weiß, dass Mandatsdaten in einen Dienst ohne Verschwiegenheitskette fließen, und das hinnimmt, bewegt sich nicht mehr im Fahrlässigkeitsbereich. Und das Berufsrecht gilt unabhängig von der Strafbarkeit: § 43e BRAO, die zivilrechtliche Haftung gegenüber dem Mandanten und die berufsaufsichtliche Ebene bleiben auch dort bestehen, wo eine Strafverfolgung ausscheidet.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Die praktische Ausgangslage in vielen Kanzleien ist dabei längst nicht mehr die Frage, ob KI genutzt wird: Mitarbeitende und Berufsträger verwenden frei verfügbare KI-Dienste - teils über private Zugänge, außerhalb jeder Kanzlei-Kontrolle und ohne jede Vertragskette. Diese Schatten-Nutzung verschwindet nicht durch Verbote, sondern durch einen zugelassenen Weg, der besser ist als der Umweg - wie er aussieht, zeigt die Seite <a href="/de/berufsgeheimnistraeger/chatgpt-alternative-kanzleien/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">ChatGPT-Alternative für Kanzleien</a>. Die Verantwortung dafür liegt beim Berufsträger: Er wählt den Dienstleister aus, er schließt die Verpflichtung in Textform, er definiert, welche Werkzeuge in der Kanzlei zulässig sind.
</p>
<p class="text-body text-gosign-text-light mt-4">
Die Konsequenz ist keine Drohkulisse, sondern eine Organisationsaufgabe: ein definierter Bezugsweg, eine dokumentierte Kette, eine klare Nutzungsregel für das Team.
</p>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Welche Aufgaben übernimmt KI in der Kanzlei - und wo bleibt das Restrisiko?</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Vier Aufgabenfelder tragen den Kanzlei-Alltag. In allen vier bleibt die juristische Prüfung und die Verantwortung beim Anwalt - das Modell liefert Entwurf und Struktur, keine Rechtsdienstleistung.
</p>
<div class="mt-8 space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Schriftsatz-Entwurf</p>
<p class="text-body text-gosign-text-light mt-1">Eine Klageerwiderung ist zu strukturieren: Das Modell gliedert den Sachvortrag der Gegenseite, stellt Bestreitens-Punkte zusammen und entwirft Standard-Passagen. Der Anwalt prüft, verwirft, schärft - der Entwurf ersetzt keine Subsumtion.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Akten- und Urteils-Zusammenfassung</p>
<p class="text-body text-gosign-text-light mt-1">Eine 400-Seiten-Akte kommt zur Terminsvorbereitung: Das Modell verdichtet Chronologie, Beteiligte und Streitpunkte auf ein Arbeitspapier mit Fundstellen-Verweisen. Gleiches gilt für die Aufbereitung ergangener Entscheidungen für die Mandanteninformation.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Vertragsanalyse</p>
<p class="text-body text-gosign-text-light mt-1">Ein Kaufvertrag der Gegenseite ist gegen den Kanzlei-Standard zu prüfen: Das Modell markiert Abweichungen, fehlende Klauseln und einseitige Risikoverteilungen als Prüfliste für die anwaltliche Bewertung.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Recherche-Vorbereitung</p>
<p class="text-body text-gosign-text-light mt-1">Das Modell strukturiert Fragestellungen, entwirft Suchstrategien und ordnet Fundstellen vor. Rechtsprechungs-Zitate aus generativen Modellen sind grundsätzlich zu verifizieren - erfundene Fundstellen sind ein dokumentiertes Fehlerbild dieser Systeme.</p>
</div>
</div>
<h3 class="text-h2 font-bold text-gosign-dark mt-12">Das ehrliche Restrisiko der Redaktion</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Vor jedem Modell-Aufruf werden Mandatsdaten redigiert: Namen, Adressen, Kennungen werden erkannt und durch Platzhalter ersetzt, nach der Antwort wieder eingesetzt. Diese Erkennung ist nicht perfekt - bei juristischen Texten systematisch nicht. Aktenzeichen folgen keinem einheitlichen Muster, seltene Eigennamen fehlen in Erkennungsmodellen, und beschreibende Merkmale („die einzige Geschäftsführerin der Beklagten") identifizieren eine Person ohne jeden Namen. § 203 StGB schützt das Geheimnis - nicht nur die Datenkategorien, die ein Erkennungsmodell kennt.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Deshalb die klare Einordnung: Redaktion und Pseudonymisierung sind Datenminimierung und eine zweite Verteidigungslinie - keine Erfüllungsbedingung des § 203. Die Zulässigkeit trägt die Kombination aus Vertragskette (§ 43e BRAO, § 203-Abs.-4-Verpflichtung) und einem Bezugsweg ohne menschlichen Klartext-Zugriff im Regelbetrieb. Und wo die Erkennung unsicher ist, entscheidet nicht ein Dienstleister im Hintergrund: Einträge mit niedriger Erkennungs-Konfidenz gehen zur Freigabe an die Nutzerin oder den Nutzer in der Kanzlei.
</p>
<p class="text-body text-gosign-text-light mt-4">
Die Redaktion reduziert, was das Modell sieht. Die Zulässigkeit trägt der Vertrag.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Der Bezugsweg für Ihre Kanzlei: drei Stufen</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Kanzleien unterscheiden sich in IT-Lage und Größe, nicht in der Rechtslage. Deshalb drei Stufen auf derselben Grundlage: Vertragskette nach § 43e BRAO, Redaktion vor dem Modell-Aufruf und ein klartextfreier Audit-Trail gehören in jeder Stufe zum Leistungsumfang - nie als Aufpreis.
</p>
<div class="mt-8 overflow-x-auto">
<table class="w-full text-left text-small border-collapse">
<thead>
<tr>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Stufe</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Für wen</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Was Sie bekommen</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">1 - Kanzlei-Instanz</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Kanzleien ohne eigene IT, vom Einzelanwalt bis ca. 50 Nutzer</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Dedizierte KI-Chat-Instanz für Ihre Kanzlei statt geteilter Plattform, betrieben von der Gosign GmbH: <a href="https://www.veryai.de/" rel="noopener noreferrer" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">veryai.de</a></td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">2 - API und Setup</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Kanzleien mit eigener IT bzw. eigenem Cloud-Tenant</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">API-Bezug über die Gosign-Vertragskette oder Einrichtung im eigenen Microsoft-/Google-Tenant - mit Governance und Antrags-Begleitung; Freigaben und Zeitpläne liegen beim jeweiligen Anbieter.</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">3 - Managed Stack</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Große Kanzleien und Rechtsabteilungen mit Prozess-Integration</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Betriebener 203er-Stack mit Agenten, Konnektoren und <a href="/de/decision-layer/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Decision Layer</a> - jede Entscheidung dokumentiert, jede Eskalation definiert.</td></tr>
</tbody>
</table>
</div>
<h3 class="text-h2 font-bold text-gosign-dark mt-12">Die Bezugswege dahinter - Stand heute, ohne Beschönigung</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Ein 203er-Status ist nie Eigenschaft eines Modells, sondern immer der Kombination aus Modell und Bezugsweg. Die generische Infrastruktur-Ebene dahinter - EU-Regionen und Deployment-Optionen - beschreibt <a href="/de/governance/data-residency/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Datenresidenz &amp; DSGVO</a>, die fachliche Modellwahl der allgemeine <a href="/de/magazin/ki-modelle-vergleich-2026/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Modellvergleich 2026</a>; hier zählt die berufsrechtliche Zulässigkeit je Kombination. Vier Wege tragen heute die Diskussion:
</p>
<div class="mt-8 overflow-x-auto">
<table class="w-full text-left text-small border-collapse">
<thead>
<tr>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Bezugsweg</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Absicherungslinie</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Stand heute</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Offene EU-Modelle (Llama 3.3, Mistral 4, Qwen 3.6) über EU-Betreiber</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Vertragslinie: § 203-Zusatzvereinbarung des Betreibers; EU-Inferenz ohne US-Konzern in der Kette</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">CLOUD-Act-freie Säule; die Zusatzvereinbarung liegt Gosign vor. Bei Inferenz im Inland stellt sich die Auslandsschranke des § 43e Abs. 4 BRAO nicht; bei EU-Ausland ist sie eröffnet - der vergleichbare Geheimnisschutz ist zu prüfen, im EU-Raum aber regelmäßig darstellbar.</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">DeepSeek R1 managed auf Gosign-Kette in deutschen Rechenzentren</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Vertragslinie: standardisierte § 203-Verschwiegenheitsvereinbarung seit 2021, deutsche Rechenzentren</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Zweite CLOUD-Act-freie Säule mit explizitem Berufsgeheimnisträger-Bezug im Angebot.</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Microsoft 365 Copilot</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Vertragslinie: Professional Secrecy Amendment (Germany), Abschluss über einen CSP-Partner; Microsoft bestellt die menschliche Sichtung im Rahmen der Missbrauchsüberwachung für Copilot ausdrücklich ab und hält EU-Verkehr in der EU-Datengrenze</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Bedingt - und der praktisch wichtigste Weg, weil Copilot in vielen Kanzleien bereits im Microsoft-Vertrag steckt. Offen bleibt, ob das Amendment die KI-Dienste und die KI-Subunternehmer erfasst; Microsoft dokumentiert das öffentlich nicht. Werden Anthropic-Modelle im Tenant zugeschaltet, verlässt der Verkehr die EU-Datengrenze - das muss die Administration aktiv kontrollieren.</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">ChatGPT (GPT-Modelle) über Microsoft Azure</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Vertragslinie: Professional Secrecy Amendment (Abschluss über CSP-Partner); EU Data Zone als Deployment-Typ; Abschaltung des menschlichen Abuse-Reviews nur für Microsoft-managed/EA-Kunden</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Bedingt: Amendment-Reichweite für Azure OpenAI und Eligibility sind je Setup mit Microsoft zu verifizieren; CLOUD-Act-Exposition bleibt und macht die Prüfung nach § 43e Abs. 4 BRAO samt Art.-44-Baustein zur Pflicht.</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Gemini und Standard-Claude über Google-EU mit Gosign-Kette</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Technik-Linie: EU-Endpunkte, keine Speicherung über die Verarbeitung hinaus, kein menschliches Prompt-Review; Google stellt keine § 203-Verschwiegenheitsurkunde - die Lücke schließt die Gosign-Kette mit eigener § 203-Abs.-4-Verpflichtung</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Bedingt: Für das Gosign-Projekt ist die Ausnahme vom Prompt-Logging (Abuse Monitoring) genehmigt - Gemini-scoped, EU-Endpunkt, ohne Caching. Kunden-Tenants brauchen je Projekt eine eigene Ausnahme; die Antrags-Begleitung gehört zur Setup-Leistung.</td></tr>
</tbody>
</table>
</div>
<p class="text-body text-gosign-text-light mt-6">
Zwei ehrliche Fußnoten dazu: Erstens sind nicht alle Modellvarianten beziehbar - Klassen mit verpflichtender Prompt-Aufbewahrung und Daten-Weitergabe an den Modellhersteller führen wir für Berufsgeheimnisträger nicht. Zweitens verkaufen wir externe Freigaben nicht als eigene Lieferzusage: Wo Microsoft oder Google über Eligibility, Reichweite oder Ausnahmen entscheiden, ist unsere Leistung Governance und Antrags-Begleitung - nicht das Versprechen fremder Unterschriften.
</p>
<p class="text-small text-gosign-text-light mt-4">
Quellen zur Tabelle: Microsoft-Dokumentation zu Professional Secrecy Amendment, EU Data Zones und Abuse-Monitoring-Eligibility (learn.microsoft.com), Google-Cloud-Dokumentation zu Data Governance und Abuse Monitoring (cloud.google.com), die Gosign-Kette in deutschen Rechenzentren zur standardisierten § 203-Verschwiegenheitsvereinbarung (t-systems.com); Abruf jeweils 22.07.2026. Die § 203-Zusatzvereinbarung des EU-Open-Weights-Betreibers ist eine Gosign vorliegende Vertragsunterlage (Anbieter-Selbstauskunft, Einsicht im Gespräch).
</p>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Mandanteninformation, Einwilligung, Vertragskit</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Zur Kette gehört auch die Mandantenseite. Die DSGVO-Transparenzpflichten (Art. 13/14) verlangen, dass der Einsatz von Dienstleistern und KI-Systemen mit Mandatsbezug in den Datenschutzhinweisen der Kanzlei erscheint. Eine informierte Einwilligung des Mandanten ist bei genereller Kanzlei-Infrastruktur nicht der Regelweg - § 43e Abs. 5 BRAO verlangt sie aber, sobald ein Dienstleister einzelmandatsbezogen beauftragt wird, und sie ist die robusteste Absicherung in Grenzfällen, etwa bei Auslandskonstellationen, in denen der vergleichbare Geheimnisschutz nach § 43e Abs. 4 BRAO nicht belastbar darstellbar ist.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Damit Kanzleien diese Bausteine nicht selbst entwerfen müssen, gibt es das 203er-Vertragskit: eigenständige Verschwiegenheits-Zusatzvereinbarung nach § 203 Abs. 4 StGB, mit Textform und Belehrung über die strafrechtlichen Folgen nach § 43e BRAO, AVV-Baustein mit Subprozessoren-Dokumentation, Drittland-Baustein, Muster-Mandanteneinwilligung und Muster-Transparenzhinweis - als Muster zur anwaltlichen Einzelfall-Anpassung. Das Kit ist frei einsehbar (v0.4, intern mehrstufig rechtsgeprüft); die externe anwaltliche Freigabe steht aus - Nachweisbarkeit beginnt vor dem Gespräch, nicht danach.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Frei einsehbar vor jeder Registrierung - v0.4, intern mehrstufig rechtsgeprüft; Muster zur anwaltlichen Einzelfall-Anpassung, ohne Gewähr. Die sieben Bausteine:
</p>
<ul class="mt-4 space-y-2 text-body text-gosign-text-light">
<li><a href="/downloads/203-vertragskit/README.md" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Nutzungs-Rahmen und Disclaimer (README)</a></li>
<li><a href="/downloads/203-vertragskit/zusatzvereinbarung-203-abs4.md" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Verschwiegenheits-Zusatzvereinbarung (§ 203 Abs. 4 StGB)</a></li>
<li><a href="/downloads/203-vertragskit/avv-baustein-gosign.md" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">AVV-Baustein mit Gosign-Selbstverpflichtung (Art. 28 DSGVO)</a></li>
<li><a href="/downloads/203-vertragskit/subprozessoren.md" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Subprozessoren-Liste</a></li>
<li><a href="/downloads/203-vertragskit/tia-scc-baustein.md" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Drittlandtransfer-Baustein (TIA/SCC, Art. 44 ff. DSGVO)</a></li>
<li><a href="/downloads/203-vertragskit/dsfa-vorlage.md" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">DSFA-Vorlage (Art. 35 DSGVO)</a></li>
<li><a href="/downloads/203-vertragskit/retention-matrix-einwilligung-transparenz.md" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Retention-Matrix, Muster-Einwilligungen, Transparenzhinweis</a></li>
</ul>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-body text-gosign-text-light">
Diese Seite ist eine technisch-organisatorische Einordnung aus Architektur- und Governance-Perspektive auf dem Stand von Juli 2026 (BRAK-Leitfaden 12/2024, DAV SN 32/2025, Gesetzestexte § 203, § 205 StGB, § 43e BRAO). Sie ersetzt keine Rechtsberatung: Die berufsrechtliche Bewertung des Einzelfalls obliegt der Kanzlei selbst bzw. ihren Beratern. Zur berufsgruppenübergreifenden Einordnung: <a href="/de/berufsgeheimnistraeger/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">KI für Berufsgeheimnisträger</a>. Für Steuerberater und Wirtschaftsprüfer mit eigener Rechtsgrundlage (§ 62a StBerG, § 50a WPO): <a href="/de/berufsgeheimnistraeger/steuerberater-wp/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Spoke für Steuerberater und Wirtschaftsprüfer</a>. Zu den generischen Enterprise-Vertragsfragen: <a href="/de/governance/avv-checkliste/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">AVV-Checkliste</a>.
</p>
</div>
</section>

--- Der Azure-Engpass: Warum Abuse Monitoring über § 203 entscheidet ---
> Azure OpenAI für Berufsgeheimnisträger: Professional Secrecy Amendment über CSP-Partner, Modified-Abuse-Monitoring-Eligibility, EU Data Zones als Deployment-Pflicht - was heute geht und was bei Microsoft liegt.

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-body-lg text-gosign-text-light">
Microsoft ist der einzige Hyperscaler mit einem standardisierten Verschwiegenheits-Amendment für Berufsgeheimnisträger - und der Azure-OpenAI-Weg zugleich der mit dem am häufigsten übersehenen Engpass: dem Abuse Monitoring. Wer den Engpass nicht kennt, baut ein Setup, dessen 203er-Argumentation am menschlichen Prompt-Review scheitert. Wer ihn kennt, weiß: Es gibt einen Opt-out - aber nicht für jeden, und nicht auf Zuruf.
</p>
<p class="text-body text-gosign-text-light mt-4">
Die berufsgruppenübergreifende Einordnung (§ 203 StGB, Rechtslinien, alle Bezugswege im Vergleich) steht auf der Übersichtsseite <a href="/de/berufsgeheimnistraeger/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">KI für Berufsgeheimnisträger</a>; die anwaltsspezifische Vertragskette nach § 43e BRAO behandelt <a href="/de/berufsgeheimnistraeger/anwaelte/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">KI in der Anwaltskanzlei</a>. Hier geht es um die drei Azure-spezifischen Bedingungen - und darum, wer über jede von ihnen entscheidet.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Warum Abuse Monitoring den 203er-Weg aushebelt</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Azure OpenAI prüft Eingaben standardmäßig auf Missbrauch. Zu diesem Verfahren gehört die Möglichkeit, dass geflaggte Prompts von Microsoft-Personal im Klartext gesichtet werden. Für Konzern-Workloads ist das ein Datenschutz-Thema. Für Berufsgeheimnisträger ist es die Sollbruchstelle der gesamten Rechtsargumentation.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Die tragende Rechtslinie für KI-Einsatz unter § 203 StGB ist ein berufsrechts- und § 203-konformer Bezugsweg nach der DAV-Linie (SN 32/2025): Rein automatisierte Verarbeitung ohne menschlichen Klartext-Zugriff ist danach kein Offenbaren im Sinne des Abs. 1 - gerichtlich ist die Frage nicht abschließend geklärt. Die konservativere BRAK-Linie (Leitfaden 12/2024) lässt bereits die Möglichkeit der Kenntnisnahme genügen.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Ein aktives menschliches Review-Verfahren kollidiert mit beiden Linien gleichzeitig: Es schafft genau die Kenntnisnahme-Möglichkeit, die die BRAK-Linie genügen lässt - und im Review-Fall den realen Zugriff, den die DAV-Linie ausschließt. Deshalb entscheidet der Opt-out über die 203er-Tauglichkeit des gesamten Azure-Wegs.
</p>
<p class="text-body text-gosign-text-light mt-4">
Drei Bedingungen entscheiden damit über den Azure-Weg: der Opt-out samt seiner Eligibility, der Amendment-Scope und der Deployment-Typ (EU Data Zones) - in dieser Reihenfolge geht diese Seite sie durch.
</p>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Modified Abuse Monitoring: der Opt-out - und seine Eligibility</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Microsoft bietet die Abschaltung des menschlichen Prompt-Samplings als Modified Abuse Monitoring an. Der Zugang ist ein Antragsverfahren mit harter Eligibility-Hürde:
</p>
<div class="mt-8 overflow-x-auto">
<table class="w-full text-left text-small border-collapse">
<thead>
<tr>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Frage</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Stand nach Microsofts Limited-Access-Dokumentation (Abruf 2026-07-22)</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Wer ist antragsberechtigt?</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Microsoft-managed Customers und Kunden in eligible Programmen (Enterprise Agreement)</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Gibt es eine zugesagte Bearbeitungs-Timeline?</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Nein - Microsoft nennt keinen Bearbeitungszeitraum</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Gilt die Freigabe pauschal?</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Nein - sie bezieht sich auf das konkrete Kunden-Setup und ist nicht übertragbar</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Wer erteilt die Freigabe?</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Ausschließlich Microsoft</td></tr>
</tbody>
</table>
</div>
<p class="text-body-lg text-gosign-text-light mt-6">
Die Konsequenz für die Praxis: Eligibility ist die erste Prüffrage, nicht die letzte. Eine Kanzlei oder ein Unternehmen ohne Enterprise Agreement und ohne Microsoft-managed-Status hat derzeit keinen dokumentierten Weg zum Opt-out - dann ist der Azure-Weg für § 203-Workloads nicht belastbar konfigurierbar, unabhängig davon, was ein Dienstleister verspricht.
</p>
</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Das Professional Secrecy Amendment: Vertragslinie mit offenem Scope</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Neben der Technik-Frage (Abuse Monitoring) steht die Vertrags-Frage: Microsoft bietet als einziger Hyperscaler ein standardisiertes Professional Secrecy Amendment (Germany) für Berufsgeheimnisträger an. Zwei Eigenschaften muss man kennen:
</p>
<div class="mt-8 space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Der Abschlussweg: Kunde und Microsoft, über einen CSP-Partner</p>
<p class="text-body text-gosign-text-light mt-1">Das Amendment wird zwischen Kunde und Microsoft geschlossen; der Abschluss läuft über einen CSP-Partner (Cloud Solution Provider). Es ist immer ein Vertrag des Kunden mit Microsoft - kein Dienstleister-Zertifikat, das ein Anbieter „mitbringt".</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Der belegte Scope: Microsoft 365 - Azure OpenAI offen</p>
<p class="text-body text-gosign-text-light mt-1">Öffentlich bestätigt ist das Amendment für Microsoft 365. Für Azure OpenAI ist der Scope öffentlich nicht bestätigt; Microsofts eigene Q&amp;A verweist auf die Einzelfall-Klärung. Eine pauschale Deckungs-Zusage ist damit heute nicht belegbar - der Scope wird pro Setup direkt mit Microsoft verifiziert, bevor eine Zusage fällt.</p>
</div>
</div>
<p class="text-body-lg text-gosign-text-light mt-6">
Seriöse Anbieter-Prüfung heißt hier: Wer mit dem Amendment wirbt, muss sagen, für welchen Dienst-Scope es in seinem Setup bestätigt wurde - und von wem.
</p>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">EU Data Zones: die Deployment-Pflicht</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Die dritte Bedingung ist eine Konfigurationsfrage: Azure OpenAI kennt mehrere Deployment-Typen, und nur die EU Data Zones (DataZone Standard bzw. DataZone Provisioned) halten die Verarbeitung EU-only. Standard-Global-Deployments können Anfragen global routen - auch wenn die Ressource in einer EU-Region wie „West Europe" angelegt wurde. Für § 203-Workloads sind Data Zones deshalb Pflicht, nicht Option.
</p>
<p class="text-body text-gosign-text-light mt-4">
Prüffrage an jedes bestehende Setup: Welcher Deployment-Typ ist konfiguriert? „EU-Region" ist keine Antwort - „DataZone Standard" ist eine.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Was heute geht - und was bei Microsoft liegt</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Drei Bedingungen, sechs Bausteine - und für jeden Baustein die Frage, wer ihn tatsächlich entscheidet:
</p>
<div class="mt-8 overflow-x-auto">
<table class="w-full text-left text-small border-collapse">
<thead>
<tr>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Baustein</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Status</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Wer entscheidet</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Professional Secrecy Amendment abschließen (über CSP-Partner)</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">verfügbar; belegter Scope: Microsoft 365</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Kunde und Microsoft</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Amendment-Scope für Azure OpenAI</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">öffentlich nicht bestätigt - pro Setup zu verifizieren</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Microsoft</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Modified Abuse Monitoring</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Antragsverfahren; Eligibility: Microsoft-managed/EA; keine zugesagte Timeline</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Microsoft</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">EU Data Zone als Deployment-Typ</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">sofort konfigurierbar</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Kunde bzw. Dienstleister</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Drittland-Baustein (TIA, DPF-Status, SCC)</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">sofort erstellbar - die CLOUD-Act-Exposition bleibt</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Kunde mit Begleitung</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Vertrags- und Governance-Kette (Abs.-4-Verpflichtung, AVV, Audit-Trail)</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">sofort umsetzbar</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Kunde und Gosign</td></tr>
</tbody>
</table>
</div>
<p class="text-body-lg text-gosign-text-light mt-6">
Zwei Zeilen dieser Tabelle liegen vollständig außerhalb der Kontrolle jedes Dienstleisters. Genau deshalb lautet die ehrliche Leistungsbeschreibung: Governance + Antrags-Begleitung; Freigabe und Zeitplan liegen bei Microsoft. Wer ein fertig freigegebenes Azure-203er-Setup zum Festtermin verspricht, verspricht etwas, das Microsoft nicht zugesagt hat.
</p>
<p class="text-small text-gosign-text-light mt-4">
Quellen: Microsoft-Dokumentation zu Professional Secrecy Amendment (Q&amp;A), Limited Access und Modified Abuse Monitoring (learn.microsoft.com) sowie zu Azure-OpenAI-Deployment-Typen und EU Data Zones (learn.microsoft.com, azure.microsoft.com); Abruf jeweils 2026-07-22.
</p>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Für wen der Azure-Weg trotzdem der richtige ist</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Der Azure-Weg passt, wenn drei Dinge zusammenkommen: ein eigener Microsoft-Tenant mit Enterprise Agreement bzw. Microsoft-managed-Status (Eligibility), eine IT, die den Tenant betreibt, und der Wunsch, im eigenen Vertragsverhältnis mit Microsoft zu bleiben statt über einen SaaS-Anbieter zu gehen. Das ist das Profil der Setup-Begleitung im Kunden-Tenant - inklusive Amendment-Verifikation, Eligibility-Antrag, Data-Zone-Konfiguration und der Vertrags- und Governance-Kette drumherum. Wie die Glieder dieser Kette zusammenhängen - von der Abs.-4-Verpflichtung bis zum klartextfreien Audit-Trail - zeigt <a href="/de/berufsgeheimnistraeger/203er-kette/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Die 203er-Kette</a>.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Wer die CLOUD-Act-Exposition strukturell vermeiden muss, findet die Alternativen im Überblick auf <a href="/de/berufsgeheimnistraeger/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">KI für Berufsgeheimnisträger</a>: Dort sind die EU-Säulen ohne US-Konzern in der Kette beschrieben.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-body text-gosign-text-light">
Diese Seite ist eine technisch-organisatorische Einordnung aus Architektur- und Governance-Perspektive auf dem Stand von Juli 2026 (Microsoft-Dokumentation, Abruf 2026-07-22; DAV-Linie (SN 32/2025), BRAK-Leitfaden 12/2024). Sie ersetzt keine Rechtsberatung: Die berufsrechtliche Bewertung des Einzelfalls obliegt der Kanzlei bzw. dem Unternehmen selbst. Zur berufsgruppenübergreifenden Einordnung: <a href="/de/berufsgeheimnistraeger/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">KI für Berufsgeheimnisträger</a>. Für die anwaltsspezifische Vertragskette nach § 43e BRAO: <a href="/de/berufsgeheimnistraeger/anwaelte/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">KI in der Anwaltskanzlei</a>.
</p>
</div>
</section>

--- ChatGPT-Alternative für Kanzleien: Der Vertrag macht den Unterschied, nicht das Modell ---
> Warum die freie ChatGPT-Nutzung mit Mandatsdaten keine belastbare § 203-Linie hat - und wie ein konformer Bezugsweg aussieht: Abs.-4-Urkunde, Kettenverpflichtung, EU-Deployment und die Antwort auf die berufsrechtliche Auslandsschranke.

<!-- Einordnung -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Warum „Welche ChatGPT-Alternative?“ die falsche Frage ist</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
ChatGPT im Browser und eine kanzleitaugliche KI-Lösung unterscheiden sich nicht primär in den Funktionen - der Unterschied ist ein Vertrags- und Konfigurations-Unterschied. ChatGPT ist ein Consumer-Produkt für einen anderen Einsatzzweck; das ist keine Kritik am Anbieter, sondern eine Zweck-Feststellung. Für die Kanzlei zählt, welche Nachweise sie über ihre KI-Nutzung führen kann - und ein privates Konto erzeugt keinen einzigen davon.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Beim Direktbezug ohne Vertragskette trägt keine der beiden Rechtslinien: Es gibt keine Verpflichtungs-Kette nach § 203 Abs. 4 StGB (Vertragslinie), und es gibt keinen für die Kanzlei belegbaren Ausschluss menschlicher Kenntnisnahme und keine vertraglich kontrollierte Retention (Technik-Linie). In unserer Status-Systematik heißt diese Kombination: beliebiges Modell × Direktbezug ohne Vertrag und ohne Ausnahme = ungedeckt.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Zur Präzision gehört beides: § 203 StGB ist ein reines Vorsatzdelikt und nach § 205 StGB ein Antragsdelikt - das Angst-Framing „KI-Chat mit Mandantendaten = Straftat“ verkürzt die Rechtslage, und wir übernehmen es bewusst nicht. Maßstab dieser Seite ist der berufsrechts- und § 203-konforme Bezugsweg nach der DAV-Linie (SN 32/2025) - gerichtlich nicht abschließend geklärt; die konservativere BRAK-Linie, nach der bereits die Möglichkeit der Kenntnisnahme kritisch ist, nennen wir transparent mit. Die richtige Frage lautet deshalb nicht „welches Tool?“, sondern „welche Kette?“ - <a href="/de/berufsgeheimnistraeger/203er-kette/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">die 203er-Kette</a> beschreibt alle acht Glieder.
</p>
</div>
</div>
</section>

<!-- Was fehlt -->
<section id="was-fehlt" class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Was der Kanzlei beim Direktbezug konkret fehlt</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Die Tabelle vergleicht die Nachweislage: links, was eine Kanzlei mit einem privaten Browser-Konto vorlegen kann - rechts, was ein geprüfter Bezugsweg liefert.
</p>
</div>
<div class="mt-8 overflow-x-auto">
<table class="w-full text-left text-small border-collapse">
<thead>
<tr>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Baustein</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Freie Browser-Nutzung (privates Konto)</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Geprüfter Bezugsweg</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Verschwiegenheitsverpflichtung (§ 203 Abs. 4; Textform nach § 43e BRAO / § 62a StBerG / § 50a WPO)</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">liegt der Kanzlei nicht vor - mit einem Consumer-Konto kommt keine Abs.-4-Urkunde zustande</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Verpflichtung dokumentiert - bewährt: eigenständige Urkunde mit Belehrung, vor Vertragsschluss einsehbar</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">AVV über die konkrete Nutzung</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">kein AVV im Namen der Kanzlei über diese Verarbeitung</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">KI-tauglicher AVV (Art. 28 DSGVO) als Kettenglied 1</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Kettenverpflichtung der Subunternehmer</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">gegenüber der Kanzlei weder benannt noch verpflichtet</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">jedes Glied benannt und gleichwertig verpflichtet - Rechenzentrum, Modell-Betreiber, Support</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Retention-Kontrolle und Training-Ausschluss</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">keine vertraglich kontrollierten Speicher- und Löschfristen, die die Kanzlei nachweisen kann</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">definierte Fristen pro Datenart, Training-Ausschluss vertraglich dokumentiert</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">EU-Deployment-Typ</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">nicht wählbar, nicht nachweisbar</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">EU Data Zones bzw. EU-Endpunkt dokumentiert - der Verarbeitungsort ist Teil des Vertragswerks</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Antwort auf die Auslandsschranke (§ 43e Abs. 4 BRAO, § 62a StBerG, § 50a WPO)</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">unbeantwortet - die Frage nach vergleichbarem Geheimnisschutz im Ausland lässt sich nicht belegen</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">im TIA/SCC- und Subunternehmer-Baustein beantwortet; strukturell vermeidbar über die EU-Säulen</td></tr>
</tbody>
</table>
</div>
<div class="max-w-narrow">
<p class="text-small text-gosign-text-light mt-4">
Die linke Spalte beschreibt die Nachweislage der Kanzlei - sie trifft keine Aussage über interne Prozesse des Anbieters. Consumer-Produkte sind für diesen Nachweisbedarf nicht gebaut; genau deshalb ist die eigentliche Alternative kein anderes Chat-Fenster, sondern ein anderer Bezugsweg.
</p>
</div>
</div>
</section>

<!-- Die Alternative -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Die Alternative: geprüfte Bezugswege statt Verzicht</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Wer bei ChatGPT bleiben will, wechselt nicht das Modell, sondern den Bezugsweg: Microsoft Azure mit EU Data Zones als Deployment-Typ. Der Status ist ehrlicherweise „bedingt“ - das Professional Secrecy Amendment wird über einen CSP-Partner geschlossen; ob es Azure OpenAI abdeckt, bestätigt Microsoft öffentlich nicht (wir verifizieren das vor jeder Kundenzusage direkt mit Microsoft), das Modified Abuse Monitoring gibt Microsoft nur für Microsoft-managed- bzw. EA-Kunden frei, ohne zugesagten Zeitplan, und die CLOUD-Act-Exposition bleibt - der TIA/SCC-Baustein ist deshalb Pflicht. Die Engpässe im Detail: <a href="/de/berufsgeheimnistraeger/azure-engpass/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Der Azure-Engpass</a>.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Strukturell ohne CLOUD-Act-Frage arbeiten die beiden EU-Säulen: EU-Inferenz offener Modelle bei einen von uns angebundenen EU-Betreiber - dort stehen Llama 3.3, Mistral 4, Qwen 3.6, Apertus, Gemma und GPT-OSS bereit, die § 203-Zusatzvereinbarung mit dem Betreiber ist gezeichnet - und die Gosign-Kette in deutschen Rechenzentren mit der seit 2021 standardisierten § 203-Verschwiegenheitsvereinbarung, die wir für die KI-Dienste gezeichnet haben, mit DeepSeek R1 managed aus deutschen Rechenzentren.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Der Google-Weg (Gemini Enterprise Agent Platform) fährt die Technik-Linie: Für das Gosign-eigene Google-Cloud-Projekt liegt die Ausnahme von der Prompt-Logging-Policy schriftlich genehmigt vor (Stand 22.07.2026); die fehlende Google-Verschwiegenheits-Urkunde kompensiert die Gosign-Kette mit eigener Abs.-4-Verpflichtung und Redaktions-Gateway. Alle vier Wege mit Vertrags- und Technik-Detail: <a href="/de/berufsgeheimnistraeger/#bezugswege" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Die vier Bezugswege</a>.
</p>
</div>
<div class="mt-8 overflow-x-auto">
<table class="w-full text-left text-small border-collapse">
<thead>
<tr>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Kombination (Modell × Bezugsweg)</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">203er-Status</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Woran der Status hängt</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">GPT × Azure (EU Data Zone)</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">bedingt</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Vertragslinie über CSP-Partner; Eligibility und Amendment-Geltungsbereich liegen bei Microsoft; CLOUD-Act-Exposition bleibt</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Offene Modelle (Llama 3.3, Mistral 4, Qwen 3.6) × EU-Inferenz über die Gosign-Kette</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">gedeckt (produktiv nach Vertragszeichnung)</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">EU-Anbieter + § 203-Zusatzvereinbarung, keine US-Konzernmutter</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">DeepSeek R1 × die Gosign-Kette in deutschen Rechenzentren</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">gedeckt</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Deutsche Rechenzentren + standardisierte § 203-VV seit 2021</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Beliebiges Modell × Direktbezug ohne Vertrag/Ausnahme</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">ungedeckt</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Weder Vertrags- noch Technik-Linie trägt - das ist die freie Browser-Nutzung</td></tr>
</tbody>
</table>
</div>
<div class="max-w-narrow">
<p class="text-small text-gosign-text-light mt-4">
„Gedeckt / bedingt / ungedeckt“ beschreibt die Vertrags- und Technik-Lage der jeweiligen Kombination nach unserem Bezugswege-Dossier (Stand 22.07.2026) - bewertet nach der DAV-Linie (SN 32/2025), gerichtlich nicht abschließend geklärt. Diese Übersicht ist keine Rechtsberatung.
</p>
</div>
</div>
</section>

<!-- Der schnellste Start -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Der schnellste Start: die dedizierte Kanzlei-Instanz mit 14-Tage-Test</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Für Kanzleien ohne eigene IT ist die erste Stufe der Lösungs-Treppe der direkteste Weg vom privaten Konto zur belastbaren Nutzung: eine dedizierte Kanzlei-Instanz als Single-Tenant-Betrieb - eigene Subdomain, eigene Datenbank, eigene Schlüssel, kein geteilter Mandanten-Pool. Betrieben unter der Produktmarke <a href="https://www.veryai.de/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">veryai.de</a>, ein Produkt der Gosign GmbH; dort steht ein 14-Tage-Test bereit - Sie prüfen die Instanz, bevor Sie sich binden.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Kanzleien mit eigener IT, eigenem Microsoft- oder Google-Vertrag oder eigenem Entwicklungsbedarf steigen auf einer anderen Stufe ein - vom 203er-Token/API bis zum Setup im eigenen Tenant: <a href="/de/berufsgeheimnistraeger/#loesungs-treppe" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Die Lösungs-Treppe</a>. Welche Stufe zu Ihrer Ausgangslage passt, ordnen wir im <a href="/de/kontakt/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Gespräch</a> ein.
</p>
</div>
</div>
</section>

<!-- Drei Schritte -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Drei Schritte aus der stillen ChatGPT-Nutzung</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
In vielen Kanzleien läuft die Consumer-Nutzung längst - nicht aus Leichtsinn, sondern weil ein sanktioniertes Angebot fehlt. Der Weg heraus ist kein Verbots-Rundschreiben, sondern ein geordneter Übergang:
</p>
</div>
<div class="max-w-narrow space-y-6 mt-8">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">1</p>
<p class="text-body-lg text-gosign-text-light mt-1"><strong>Bestandsaufnahme ohne Schuldzuweisung.</strong> Welche Werkzeuge nutzt das Team heute, für welche Aufgaben, mit welchen Daten? Schatten-KI entsteht dort, wo es keine offizielle Alternative gibt - die Bestandsaufnahme zeigt, welche Aufgabenklassen das sanktionierte Angebot abdecken muss.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">2</p>
<p class="text-body-lg text-gosign-text-light mt-1"><strong>Bezugsweg wählen statt Werkzeug verbieten.</strong> Ein Verbot ohne Alternative verlagert die Nutzung nur auf private Geräte. Tragfähig ist der umgekehrte Weg: ein Bezugsweg mit Vertragskette, der die gewohnten Aufgaben abdeckt - je nach IT-Situation als dedizierte Instanz, Token/API oder Setup im eigenen Tenant.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">3</p>
<p class="text-body-lg text-gosign-text-light mt-1"><strong>Kette dokumentieren, Mandanten informieren.</strong> Abs.-4-Urkunde, AVV, Subunternehmer-Liste, Retention-Regeln - abgelegt und benannt; dazu die Transparenz- und Einwilligungs-Seite gegenüber Mandanten (Art. 13/14 DSGVO, bei Steuerberatern und Wirtschaftsprüfern die ausdrückliche Einwilligung nach § 62a StBerG und § 50a WPO). Erst die dokumentierte Kette macht aus der Nutzung eine belegbare Position.</p>
</div>
</div>
</div>
</section>

<!-- Selbst prüfen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-2">Selbst prüfen statt glauben</h2>
<p class="text-body text-gosign-text-light mb-8 max-w-narrow">
Glauben Sie dieser Seite nicht - prüfen Sie sie. Drei Werkzeuge dafür:
</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/de/berufsgeheimnistraeger/vergleich-203-anbieter/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Anbieter-Vergleich</p>
<p class="text-body font-semibold text-gosign-dark">KI mit § 203-Vertrag im Vergleich: Wer hat ein belegtes Vertragsartefakt, wer einen Claim - mit Quellen und Abrufdatum</p>
</a>
<a href="/de/berufsgeheimnistraeger/203er-kette/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Die 203er-Kette</p>
<p class="text-body font-semibold text-gosign-dark">Acht Glieder vom AVV bis zur Mandanteneinwilligung - die Prüflogik hinter jeder Status-Aussage</p>
</a>
<a href="/de/berufsgeheimnistraeger/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Überblick</p>
<p class="text-body font-semibold text-gosign-dark">KI für Berufsgeheimnisträger (§ 203): Rechtslage, vier Bezugswege und die Lösungs-Treppe</p>
</a>
</div>
<div class="max-w-narrow">
<p class="text-body-lg text-gosign-text-light mt-8">
Die berufsgruppen-spezifische Rechtsgrundlage mappen die Spokes für <a href="/de/berufsgeheimnistraeger/anwaelte/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Rechtsanwälte</a> und <a href="/de/berufsgeheimnistraeger/steuerberater-wp/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Steuerberater und Wirtschaftsprüfer</a>. Das generische Schatten-KI-Risiko ohne Kanzlei-Bezug - private ChatGPT-Nutzung im Unternehmen - behandelt der Magazin-Beitrag <a href="/de/magazin/chatgpt-ohne-anmeldung-risiko/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">ChatGPT ohne Anmeldung: das unterschätzte Risiko</a>.
</p>
</div>
</div>
</section>

--- Design-Partner-Programm 203er-Stack - KI-Einführung zu Partner-Konditionen für Kanzleien ---
> Befristetes Design-Partner-Programm für Kanzleien: Setup im eigenen Microsoft-Tenant, Compliance-Retainer mit 30-50 % Rabatt, drei bis fünf Plätze. Konditionen im Gespräch.

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-body-lg text-gosign-text-light">
Das Design-Partner-Programm ist ein befristetes Angebot mit drei bis fünf Plätzen: Ihre Kanzlei führt den 203er-Stack als eine der ersten ein - bevorzugt als Setup im eigenen Microsoft-Tenant mit Compliance-Retainer - und erhält dafür Partner-Konditionen, direkten Zugriff auf das Team und Einfluss auf die Roadmap. <strong class="text-gosign-dark">Design-Partner zahlen einen realen, deutlich rabattierten Preis</strong> - so entsteht eine Partnerschaft auf Augenhöhe, in der beide Seiten investiert sind: Sie bekommen einen konformen KI-Bezugsweg zu Konditionen, die es später nicht mehr gibt; wir bekommen den Praxis-Beweis mit einer echten Kanzlei.
</p>
<p class="text-body text-gosign-text-light mt-4">
Den fachlichen Rahmen des Stacks - Rechtslage, Bezugswege, Vertragskette - erklärt die <a href="/de/berufsgeheimnistraeger/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Einstiegsseite KI für Berufsgeheimnisträger (§ 203 StGB)</a>; die anwaltliche Rechtslage im Detail der <a href="/de/berufsgeheimnistraeger/anwaelte/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Spoke für Rechtsanwälte</a>, das Prüfraster für Anbieter-Zusagen die <a href="/de/berufsgeheimnistraeger/203er-kette/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">203er-Kette</a>.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Was Design-Partner bekommen</h2>
<p class="text-body-lg text-gosign-text-light mb-8">
Das Paket ist das vollständige 2b-Angebot plus Leistungen, die es ausschließlich im Programm gibt:
</p>
<div class="overflow-x-auto">
<table class="w-full text-left text-small border-collapse">
<thead>
<tr>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Leistung</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Inhalt</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Setup im eigenen Microsoft-Tenant</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Governance-Setup, Begleitung der Microsoft-Antrags- und Amendment-Strecke (Freigaben und Zeitpläne liegen bei Microsoft), Anbindung an die Gateway-Zielarchitektur, vollständige Dokumentation</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Compliance-Retainer</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Quartals-Review von Formulierungs-Matrix und Rechtslage auf Ihr Setup, Modell- und Katalog-Updates, Audit-Trail-Bereitstellung, Subprozessor-Monitoring, definiertes Stunden-Kontingent</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Vertragskit-Begleitung</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Kit-Muster (Verschwiegenheits-Zusatzvereinbarung, AVV-Baustein, Drittland-Baustein, Einwilligungs-Muster) inklusive Durchsprache; das Kit ist frei einsehbar (v0.4, intern mehrstufig rechtsgeprüft; die externe anwaltliche Freigabe steht aus) - die anwaltliche Einzelfall-Anpassung bleibt bei Ihrer Kanzlei</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Direkter Draht</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Fester Ansprechpartner und Eskalationspfad ohne Ticket-Schleife, für die gesamte Laufzeit der Partnerschaft</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Roadmap-Einfluss</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Der erste Festpreis-Konnektor (DATEV oder gängige DMS) wird nach Partner-Bedarf priorisiert</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Fallstudie</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Gosign erstellt die Fallstudie, Ihre Kanzlei gibt frei - anonymisiert oder mit Namensnennung, das entscheiden Sie</td></tr>
</tbody>
</table>
</div>
<p class="text-body text-gosign-text-light mt-6">
<strong class="text-gosign-dark">Alternativ-Profil Stufe 1:</strong> Für Kanzleien ohne eigenen Microsoft-Tenant gibt es das Programm auch auf Basis der dedizierten Kanzlei-Instanz - mit begleiteter Einführung und drei Monaten Betreuung inklusive. Erste Wahl bleibt das Tenant-Setup, weil es die gesamte Strecke aus Setup, Retainer und Microsoft-Freigaben real durchläuft.
</p>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Konditionen: der Programm-Rahmen</h2>
<p class="text-body-lg text-gosign-text-light mb-8">
Die Konditionen nennen wir hier als Rahmen - die konkrete Zahl für Ihre Kanzlei hängt von Scope und Profil ab und gehört ins Gespräch:
</p>
<div class="overflow-x-auto">
<table class="w-full text-left text-small border-collapse">
<thead>
<tr>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Baustein</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Regulär</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Für Design-Partner</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Setup</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">ab 5.000 €, zzgl. Microsoft-Freigabezeit</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Zum Selbstkosten-Anker der Erstkunden-Phase - Gosign investiert das Lernkurven-Delta bewusst mit</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Compliance-Retainer</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">500-1.500 €/Monat</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">30 bis 50 Prozent Rabatt für sechs bis zwölf Monate</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Danach</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Listenpreis</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Preis-Lock auf Listenpreis-Niveau für weitere zwölf Monate - Schutz vor der Preisfindungs-Volatilität der frühen Phase</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Abrechnung</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Standard-Rechnung</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Standard-Rechnung - dieselbe Billing-Disziplin wie für alle Kunden, ab Tag 1</td></tr>
</tbody>
</table>
</div>
<p class="text-body-lg text-gosign-text-light mt-8">
<strong class="text-gosign-dark">Warum immer ein realer Preis:</strong> Das Programm ist so gebaut, dass es die härteste Frage jedes neuen Angebots beantwortet - ob der Wert eine echte Budget-Entscheidung trägt. Der Rabatt ist deshalb bewusst deutlich, aber begrenzt und befristet. Das schützt auch Sie: Ein Partner, der zahlt, bekommt Lieferung, Verbindlichkeit und Priorität wie ein Kunde, weil er einer ist.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong class="text-gosign-dark">Was wir uns im Gegenzug wünschen</strong> - offen benannt, fester Bestandteil jeder Partnerschaft: Referenz-Recht (mindestens anonymisiert nach Branche und Größenklasse, Namensnennung nach Freigabe angestrebt), eine feste Feedback-Kadenz (zwei Termine pro Monat während des Setups, danach einer), Mitwirkung an der Fallstudie (Review und Freigabe) sowie die Nutzung des anonymisierten Setups als Beleg-Beispiel gegenüber Fragen der Berufsaufsicht.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Auswahl-Kriterien: wen wir suchen</h2>
<p class="text-body-lg text-gosign-text-light mb-8">
Die Plätze sind begrenzt, die Auswahl folgt sechs Kriterien in dieser Reihenfolge:
</p>
<div class="space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">1 - Segment-Fit</p>
<p class="text-body-lg text-gosign-text-light mt-1">Kern-Profil: Rechtsanwalts-Kanzlei mit 11 bis 50 Personen und eigener IT-Verantwortung. Zweitprofil: Steuerberatungs- oder WP-Kanzlei, die den DATEV-Copilot für DATEV-Workflows nutzt und den zweiten Bezugsweg klar davon abgrenzt.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">2 - Technische Eligibility</p>
<p class="text-body-lg text-gosign-text-light mt-1">Eigener Microsoft-Tenant, Microsoft-managed bzw. EA-fähig - die Voraussetzung der Amendment-Strecke. Wir prüfen das vorab gemeinsam; die Freigaben selbst liegen bei Microsoft und werden ehrlich als externe Entscheidungen ausgewiesen.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">3 - Realer Nutzungs-Druck</p>
<p class="text-body-lg text-gosign-text-light mt-1">Die KI-Einführung ist beschlossen oder Schatten-KI ist nachweislich vorhanden. Das Programm liefert einen konformen Weg für echten Bedarf - es ist kein Forschungsprojekt.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">4 - Entscheidungs-Geschwindigkeit</p>
<p class="text-body-lg text-gosign-text-light mt-1">Inhabergeführt oder mit benanntem Entscheider; eine Zeichnung binnen vier bis sechs Wochen ist realistisch.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">5 - Referenz-Bereitschaft</p>
<p class="text-body-lg text-gosign-text-light mt-1">Die Gegenleistungen aus dem Programm-Rahmen sind Vorbedingung der Aufnahme, damit beide Seiten von Anfang an mit derselben Erwartung starten.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">6 - Klare Rollen</p>
<p class="text-body-lg text-gosign-text-light mt-1">Das Programm richtet sich an Kanzleien als Anwender. Legal-Tech-Anbieter mit eigenem Produkt begleiten wir außerhalb des Programms über die 203er-Token/API - so bleibt die Partnerschaft frei von Wettbewerbs-Überschneidungen.</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Befristung, Plätze - und der ehrliche Status</h2>
<p class="text-body-lg text-gosign-text-light">
<strong class="text-gosign-dark">Das Programm ist echt befristet:</strong> Es nimmt drei bis fünf Partner auf, die Aufnahme läuft längstens bis Ende Q4/2026 - danach gelten Regel-Konditionen. Die Begrenzung ist keine Verkaufs-Dramaturgie, sondern Delivery-Realität: Jede Partnerschaft bekommt Senior-Kapazität und direkten Draht, und beides ist endlich. Laufende Partner-Verträge werden in jedem Fall vollständig erfüllt.
</p>
<p class="text-body-lg text-gosign-text-light mt-6">
<strong class="text-gosign-dark">Der Status des Stacks, ehrlich benannt:</strong> Das 203er-Vertragskit ist frei einsehbar (v0.4, intern mehrstufig rechtsgeprüft); die externe anwaltliche Freigabe steht aus - Design-Partner arbeiten mit den Mustern während der gesamten Begleitung. Das PII-Gateway mit klartextfreiem Audit-Trail ist die als Standard vorgesehene Zielarchitektur mit veröffentlichtem Anforderungs-Katalog; alle Aussagen dazu beschreiben den Anforderungs-Stand, den das Setup real erreicht hat. Microsoft-Freigaben (Amendment, Abuse-Monitoring-Eligibility) sind externe Entscheidungen mit externen Zeitplänen - deshalb steht „zzgl. Microsoft-Freigabezeit" im Setup-Preis.
</p>
<p class="text-body text-gosign-text-light mt-6">
Rechtlicher Rahmen: Der Stack ist als berufsrechts- und § 203-konformer Bezugsweg nach der DAV-Linie (SN 32/2025) gebaut; gerichtlich ist die Frage nicht abschließend geklärt, die konservativere BRAK-Linie nennen wir transparent mit. Diese Seite ist eine architektur- und governance-fachliche Einordnung, keine Rechtsberatung; die berufsrechtliche Prüfung des Einzelfalls obliegt dem Berufsträger bzw. seinen rechtlichen Beratern.
</p>
</div>
</section>

--- KI für Berufsgeheimnisträger (§ 203 StGB): Bezugswege und Vertragskette ---
> Wie Kanzleien KI mit Mandatsdaten nutzen: vier geprüfte Bezugswege, die 203er-Vertragskette in acht Gliedern und eine Lösungs-Treppe - nach der DAV-Linie (SN 32/2025), gerichtlich nicht abschließend geklärt.

<!-- Einordnung -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Warum KI-Nutzung in der Kanzlei ein Bezugsweg-Thema ist</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Kanzleien scheitern beim KI-Einsatz nicht an der Technik, sondern am Bezugsweg. Ein Sprachmodell, das Schriftsätze zusammenfasst, verarbeitet Mandatsgeheimnisse - und damit greift § 203 StGB, flankiert vom Berufsrecht (§ 43e BRAO, § 62a StBerG, § 50a WPO) und der DSGVO. Die Frage ist nicht, ob eine Kanzlei KI nutzen darf. Die Frage ist, über welche Vertrags- und Technikkette sie es tut.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Die Dogmatik dahinter ist präzise: Ein externer Dienstleister darf nach § 203 Abs. 3 Satz 2 StGB als mitwirkende Person eingebunden werden. Die Verschwiegenheitsverpflichtung dieses Dienstleisters folgt aus § 203 Abs. 4 Satz 2 Nr. 1 StGB, das die Verpflichtung zur Geheimhaltung verlangt; Textform und Belehrung über die Strafbarkeit fordert das Berufsrecht (§ 43e BRAO, § 62a StBerG, § 50a WPO) - bewährt dokumentiert als eigenständige Urkunde, nicht als bloße AVV-Klausel. Parallel adressiert die technische Linie das Tatbestandsmerkmal „offenbaren" in Absatz 1: Läuft die Verarbeitung rein automatisiert, ohne dass ein Mensch beim Anbieter Klartext liest, liegt nach der DAV-Linie schon kein Offenbaren vor. Beide Linien zusammen sind Belt-and-Suspenders als Risiko-Argument - keine kumulative Rechtsbedingung.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Diese Seite verbindet drei Dinge: die Rechtslage mit beiden Verbandslinien, die vier Bezugswege mit ihrem jeweiligen Status - von ChatGPT über Gemini und Claude bis zu offenen Modellen wie Llama, Mistral und Qwen - und die Lösungs-Treppe von der dedizierten Kanzlei-Instanz bis zum Managed Stack.
</p>
</div>
</div>
</section>

<!-- Das Problem -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Das Problem: ein Vorsatzdelikt, zwei Verbandslinien, keine Rechtsprechung</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Zur Einordnung gehört zuerst die strafrechtliche Präzision: § 203 StGB ist ein reines Vorsatzdelikt und nach § 205 StGB ein Antragsdelikt. Wer unbedacht ein KI-Werkzeug nutzt, ist nicht automatisch strafbar - die verbreitete Drohkulisse „KI-Chat mit Mandantendaten = Straftat" verkürzt die Rechtslage. Ernst bleibt sie trotzdem: Es geht um das Mandatsgeheimnis, um Berufsrecht und um die Frage, wem gegenüber die Kanzlei ihre Sorgfalt nachweisen kann.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Wer entscheidet, ob ein Cloud-KI-Dienst zulässig ist? Kein Gericht hat diese Frage bisher entschieden. Es stehen zwei Verbandslinien nebeneinander - und eine seriöse Anbieter-Aussage nennt beide:
</p>
</div>
<div class="mt-8 overflow-x-auto">
<table class="w-full text-left text-small border-collapse">
<thead>
<tr>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Linie</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Kernaussage</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Konsequenz für die Kanzlei</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">DAV, Stellungnahme SN 32/2025</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Rein automatisierte Verarbeitung ohne menschlichen Klartext-Zugriff ist kein Offenbaren im Sinne des § 203 Abs. 1 StGB.</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Cloud-KI ist gangbar, wenn der Bezugsweg No-Human-Access technisch und vertraglich absichert.</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">BRAK, KI-Leitfaden 12/2024</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Konservativer: Bereits die Möglichkeit der Kenntnisnahme durch den Anbieter ist kritisch.</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Die Vertragslinie (Abs.-4-Verpflichtung, geschlossene Systeme) gewinnt an Gewicht; reine Technik-Argumente reichen der Kammer-Linie nicht.</td></tr>
</tbody>
</table>
</div>
<div class="max-w-narrow">
<p class="text-body-lg text-gosign-text-light mt-6">
Für Steuerberater kommt die eigene Kammer-Ebene hinzu: Die Bundessteuerberaterkammer hat mit ihren FAQ zum KI-Einsatz (Stand 01/2026) die Anforderungen an Auslagerung und Einwilligung konkretisiert - § 62a StBerG verlangt bei mandatsbezogener Auslagerung die ausdrückliche Einwilligung des Mandanten. Wer Ihnen einen KI-Dienst verkauft, ohne diese Linien zu unterscheiden, verkauft Ihnen ein ungeprüftes Risiko.
</p>
<p class="text-small text-gosign-text-light mt-4">
Quellen: DAV-Stellungnahme SN 32/2025 (anwaltverein.de), BRAK-Leitfaden zum KI-Einsatz, Stand 12/2024 (brak.de), BStBK-FAQ zum KI-Einsatz (bstbk.de); Abruf jeweils 22.07.2026.
</p>
</div>
</div>
</section>

<!-- Die 203er-Kette -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Die 203er-Kette: acht Glieder, kein Glied verzichtbar</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Ein einzelnes Dokument macht keinen konformen Bezugsweg. Die Kette, die eine Kanzlei prüfen muss, hat acht Glieder - fehlt eines, trägt die Argumentation nicht:
</p>
</div>
<div class="max-w-narrow space-y-6 mt-8">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">1</p>
<p class="text-body-lg text-gosign-text-light mt-1"><strong>Auftragsverarbeitungsvertrag (Art. 28 DSGVO).</strong> Die datenschutzrechtliche Basis - notwendig, aber für § 203 allein nicht hinreichend. Die generischen Enterprise-Prüffragen dazu: <a href="/de/governance/avv-checkliste/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">AVV-Checkliste für KI-Infrastruktur</a>.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">2</p>
<p class="text-body-lg text-gosign-text-light mt-1"><strong>Verschwiegenheitsverpflichtung nach § 203 Abs. 4 Satz 2 Nr. 1 StGB.</strong> Verpflichtung zur Geheimhaltung - dokumentiert in einer eigenständigen Urkunde mit Belehrung über die Strafbarkeit, wie es das Berufsrecht verlangt (§ 43e BRAO, § 62a StBerG, § 50a WPO) - die vertragliche Antwort auf die Einbindung des Dienstleisters als mitwirkende Person (Abs. 3 Satz 2).</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">3</p>
<p class="text-body-lg text-gosign-text-light mt-1"><strong>Subunternehmer-Kette.</strong> Jedes Glied hinter dem Anbieter - Rechenzentrum, Modell-Betreiber, Support - ist benannt und gleichwertig verpflichtet.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">4</p>
<p class="text-body-lg text-gosign-text-light mt-1"><strong>Der Vermittler selbst als verpflichtetes Glied.</strong> Gosign nimmt sich nicht aus: eigene Abs.-4-Verpflichtung des eingesetzten Personals, dokumentiert im Vertragskit.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">5</p>
<p class="text-body-lg text-gosign-text-light mt-1"><strong>Verarbeitungsort: EU-Region und Data Zones.</strong> Wo die Inferenz tatsächlich läuft - bei Azure sind die EU Data Zones der § 203-relevante Deployment-Typ, nicht die Marketing-Region. Die generische Infrastruktur-Ebene (EU-Regionen, Deployment-Optionen) beschreibt <a href="/de/governance/data-residency/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Datenresidenz &amp; DSGVO</a>.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">6</p>
<p class="text-body-lg text-gosign-text-light mt-1"><strong>Drittlandtransfer und Auslandsschranke.</strong> Art. 44 ff. DSGVO, CLOUD-Act-Exposition und DPF-Status des Anbieters - dazu die berufsrechtliche Schranke: § 43e Abs. 4 BRAO, § 62a StBerG und § 50a WPO erlauben Dienstleister im Ausland nur bei vergleichbarem Geheimnisschutz.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">7</p>
<p class="text-body-lg text-gosign-text-light mt-1"><strong>Training-Ausschluss und Retention.</strong> Vertraglich dokumentiert: keine Nutzung zu Trainingszwecken, definierte Speicher- und Löschfristen pro Datenart.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">8</p>
<p class="text-body-lg text-gosign-text-light mt-1"><strong>Mandanteneinwilligung und Transparenz.</strong> Informationspflichten nach Art. 13/14 DSGVO; für Steuerberater und Wirtschaftsprüfer verlangen § 62a StBerG und § 50a WPO bei mandatsbezogener Auslagerung die ausdrückliche Einwilligung.</p>
</div>
</div>
<div class="max-w-narrow">
<p class="text-body-lg text-gosign-text-light mt-8">
Das vertiefende Erklärstück mit Prüffragen je Glied: <a href="/de/berufsgeheimnistraeger/203er-kette/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Die 203er-Kette - acht Glieder zwischen Mandat und Modell</a>. Warum Consumer-Zugänge wie der private ChatGPT-Account diese Kette nicht erfüllen und wie ein konformer Weg aussieht: <a href="/de/berufsgeheimnistraeger/chatgpt-alternative-kanzleien/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">ChatGPT-Alternative für Kanzleien</a>.
</p>
</div>
</div>
</section>

<!-- Die vier Bezugswege -->
<section id="bezugswege" class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Die vier Bezugswege</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Der 203er-Status ist nie eine Eigenschaft des Modells - er ist eine Eigenschaft der Kombination aus Modell und Bezugsweg. Dasselbe Modell kann über einen Weg tragfähig sein und über einen anderen ungedeckt. Die fachliche Modellwahl - welches Modell welche Aufgabenklasse trägt - ordnet der allgemeine <a href="/de/magazin/ki-modelle-vergleich-2026/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Modellvergleich 2026</a> ein; hier geht es um die Zulässigkeits-Ebene. Vier Wege haben wir vertraglich und technisch geprüft:
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">Weg 1 - Microsoft Azure: die Vertragslinie</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Microsoft ist der einzige Hyperscaler mit einem standardisierten Berufsgeheimnisträger-Amendment: dem Professional Secrecy Amendment (Germany), abgeschlossen zwischen Kunde und Microsoft über einen CSP-Partner. Der öffentlich belegte Geltungsbereich ist Microsoft 365; ob das Amendment auch Azure OpenAI abdeckt, bestätigt Microsoft öffentlich nicht - das wird vor jeder Kundenzusage direkt mit Microsoft verifiziert. Das Modified Abuse Monitoring (kein menschliches Prompt-Sampling) gibt Microsoft nur für Microsoft-managed- bzw. EA-Kunden frei, ohne zugesagten Zeitplan. Deployment-Pflicht sind die EU Data Zones. Die CLOUD-Act-Exposition bleibt bei diesem Weg bestehen - der TIA/SCC-Baustein ist deshalb Pflichtbestandteil der Kette. Gosigns Leistung auf diesem Weg ist Governance und Antrags-Begleitung; Freigabe und Zeitplan liegen bei Microsoft.
</p>
<p class="text-small text-gosign-text-light mt-3">
Quelle: Microsoft-Learn-Dokumentation (Professional Secrecy Amendment, Abuse-Monitoring-Eligibility, EU Data Zones); Abruf 22.07.2026.
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">Weg 2 - Google Gemini Enterprise Agent Platform: die Technik-Linie</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Google bietet keine § 203-Verschwiegenheits-Zusatzvereinbarung - es gibt das Cloud Data Processing Addendum mit DSGVO-üblicher Vertraulichkeit, aber keine strafbewehrte Urkunde. Diese Vertragslücke kompensiert die Gosign-Kette: eigene Abs.-4-Verpflichtung, Redaktions-Gateway vor dem Modell-Aufruf und klartextfreier Audit-Trail. Für das Gosign-eigene Google-Cloud-Projekt liegt die Ausnahme von der Prompt-Logging-Policy (Abuse Monitoring) schriftlich genehmigt vor (Stand 22.07.2026). Die Referenz-Konfiguration ist bewusst maximal auf No-Persistence gestellt: ausschließlich Google-eigene Gemini-Modelle, EU-Endpunkt, ohne Caching, ohne Abuse Monitoring. Setups im Kunden-Tenant brauchen je Projekt eine eigene Ausnahme - die Antrags-Begleitung ist Teil der Leistung.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Über dieselbe Plattform sind auch Standard-Claude-Modelle beziehbar: mit Zero-Data-Retention, EU-Endpunkten und ohne Content-Zugriff von Google oder Anthropic. Modellklassen, deren Nutzungsbedingungen eine mehrwöchige Prompt-Speicherung und verpflichtende Datenweitergabe an den Modellanbieter vorsehen, sind für Berufsgeheimnisträger-Workloads bei uns gesperrt - der <a href="/de/ki-modelle-berufsgeheimnistraeger/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">203er-Modellkatalog</a> weist das je Kombination aus Modell und Bezugsweg aus.
</p>
<p class="text-small text-gosign-text-light mt-3">
Quellen: Google-Cloud-Dokumentation (Data Governance, Abuse Monitoring, Cloud Data Processing Addendum), Anthropic-Dokumentation (Claude auf Vertex AI); Abruf jeweils 22.07.2026.
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">Weg 3 - CLOUD-Act-freie Säule 1: EU-Inferenz offener Modelle</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
EU-Inferenz offener Modelle bei einem europäischen Anbieter ohne US-Konzernmutter - die CLOUD-Act-Frage entfällt strukturell, die berufsrechtliche Auslandsschranke wird nicht berührt. Im Angebot stehen Llama 3.3 und Llama 3.1, Mistral 4, Qwen 3.6, Apertus, Gemma und GPT-OSS (Stand der Modellübersicht: 25.07.2026); DeepSeek führt dieser Anbieter nicht - dafür ist der Telekom-Weg der geprüfte Bezugsweg. Die § 203-Zusatzvereinbarung mit dem Betreiber ist gezeichnet, ebenso der Reseller-Vertrag: Verschwiegenheitsverpflichtung in Textform mit Belehrung über die Strafbarkeit, Kettenverpflichtung auf dessen Subunternehmer. Dieser Weg trägt die Token-/API-Angebote der Lösungs-Treppe.
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">Weg 4 - die Gosign-Kette in deutschen Rechenzentren: CLOUD-Act-freie Säule 2</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Für den zweiten Weg besteht seit 2021 eine standardisierte § 203-Verschwiegenheitsvereinbarung aus deutschen Rechenzentren (Magdeburg/Biere, TCDP 1.0). Wir haben sie gezeichnet, einschließlich der Geltung für die AI Foundation Services (LLM Hub) - dort laufen DeepSeek R1, Llama 3.3 und Mistral Small 3 managed über eine OpenAI-kompatible API. Preise laufen über den Vertrieb.
</p>
<p class="text-small text-gosign-text-light mt-3">
Quelle: unser Betreiber in deutschen Rechenzentren / T-Cloud-Public-Dokumentation (AI Foundation Services); Abruf 22.07.2026.
</p>
</div>

<div class="mt-10 overflow-x-auto">
<table class="w-full text-left text-small border-collapse">
<thead>
<tr>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Kombination (Modell × Bezugsweg)</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">203er-Status</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Woran der Status hängt</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Offene Modelle (Llama 3.3, Mistral 4, Qwen 3.6) × EU-Inferenz über die Gosign-Kette</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">gedeckt (produktiv nach Vertragszeichnung)</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">EU-Anbieter + § 203-Zusatzvereinbarung, keine US-Konzernmutter</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">DeepSeek R1 × die Gosign-Kette in deutschen Rechenzentren</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">gedeckt</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Deutsche Rechenzentren + standardisierte § 203-VV seit 2021</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">GPT × Azure (EU Data Zone)</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">bedingt</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Vertragslinie über CSP-Partner; Eligibility und Amendment-Geltungsbereich liegen bei Microsoft; CLOUD-Act-Exposition bleibt</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Gemini × Google-EU über Gosign-Gateway</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">bedingt</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Genehmigte Logging-Ausnahme + Gosign-Kette kompensieren die fehlende Google-Urkunde</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Claude (Standard) × Google-EU über Gosign-Gateway</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">bedingt</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Wie Gemini; Zero-Data-Retention, EU-Endpunkt, kein Content-Zugriff des Modellanbieters</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Beliebiges Modell × Direktbezug ohne Vertrag/Ausnahme</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">ungedeckt</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Weder Vertrags- noch Technik-Linie trägt</td></tr>
</tbody>
</table>
</div>
<div class="max-w-narrow">
<p class="text-small text-gosign-text-light mt-4">
„Gedeckt / bedingt / ungedeckt" beschreibt die Vertrags- und Technik-Lage der jeweiligen Kombination nach unserem Bezugswege-Dossier (Stand 22.07.2026) - bewertet nach der DAV-Linie (SN 32/2025), gerichtlich nicht abschließend geklärt. Diese Übersicht ist keine Rechtsberatung.
</p>
</div>
</div>
</section>

<!-- Die Lösungs-Treppe -->
<section id="loesungs-treppe" class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Die Lösungs-Treppe: vier Stufen, ein Prinzip</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Nicht jede Kanzlei braucht denselben Bezugsweg. Eine Drei-Personen-Kanzlei ohne IT hat andere Anforderungen als eine Sozietät mit eigenem Microsoft-Vertrag. Die Treppe ordnet - und auf jeder Stufe gilt dasselbe Prinzip: Redaktions-Gateway und klartextfreier Audit-Trail sind als Standard-Architektur vorgesehen, nie als Aufpreis.
</p>
</div>
<div class="grid grid-cols-1 md:grid-cols-2 gap-6 lg:gap-8 mt-8">
<article class="bg-gosign-light border border-gosign-border rounded-card p-6 lg:p-8">
<h3 class="text-h3 font-bold text-gosign-dark">Stufe 1 - Dedizierte Kanzlei-Instanz</h3>
<p class="text-body text-gosign-text-light mt-3">
Ein 203er-Chat als Single-Tenant-Instanz: eigene Subdomain, eigene Datenbank, eigene Schlüssel - kein geteilter Mandanten-Pool. Datei-Upload und Vorlagen inklusive. Betrieben unter der Produktmarke <a href="https://www.veryai.de/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">veryai.de</a>, ein Produkt der Gosign GmbH.
</p>
<p class="text-body text-gosign-text-light mt-3">
<strong>Sie erkennen sich wieder, wenn:</strong> 1–50 Personen, keine eigene IT-Abteilung - Sie wollen diese Woche anfangen, nicht nach einem Infrastruktur-Projekt.
</p>
</article>
<article class="bg-gosign-light border border-gosign-border rounded-card p-6 lg:p-8">
<h3 class="text-h3 font-bold text-gosign-dark">Stufe 2a - 203er-Token/API</h3>
<p class="text-body text-gosign-text-light mt-3">
OpenAI-kompatibler API-Zugang zu EU-Inferenz offener Modelle - mit vollständiger Vertragskette und Redaktions-Gateway davor. Für Legal-Tech-Anbieter, Software-Häuser und Kanzleien, die eigene Werkzeuge bauen, aber keinen eigenen Cloud-Vertrag verhandeln wollen.
</p>
<p class="text-body text-gosign-text-light mt-3">
<strong>Sie erkennen sich wieder, wenn:</strong> Sie entwickeln selbst Software oder Automatisierungen und brauchen den konformen Unterbau - nicht noch ein Chat-Frontend.
</p>
</article>
<article class="bg-gosign-light border border-gosign-border rounded-card p-6 lg:p-8">
<h3 class="text-h3 font-bold text-gosign-dark">Stufe 2b - Setup im eigenen Tenant + Compliance-Retainer</h3>
<p class="text-body text-gosign-text-light mt-3">
Aufbau des Bezugswegs im eigenen Azure- oder Google-Tenant: Amendment- bzw. Ausnahme-Antragsbegleitung, EU-Data-Zone-Deployment, Governance-Dokumentation - danach laufende Betreuung per Retainer. Ehrlich gesagt: Der Azure-Weg setzt Microsoft-managed- bzw. EA-Status voraus, und Freigabe wie Zeitplan liegen bei Microsoft beziehungsweise Google - wir begleiten den Antrag, wir versprechen keinen fremden Kalender.
</p>
<p class="text-body text-gosign-text-light mt-3">
<strong>Sie erkennen sich wieder, wenn:</strong> eigene IT, eigener Microsoft- oder Google-Vertrag - Sie wollen die Kette im eigenen Haus halten und gegenüber Mandanten selbst zeichnen.
</p>
</article>
<article class="bg-gosign-light border border-gosign-border rounded-card p-6 lg:p-8">
<h3 class="text-h3 font-bold text-gosign-dark">Stufe 3 - Managed 203er-Stack + Agenten</h3>
<p class="text-body text-gosign-text-light mt-3">
Für große Kanzleien, Versicherer und Kliniken: der vollständige Stack mit Konnektoren in die Bestandslandschaft, Agenten für definierte Prozesse und Decision-Layer-Architektur - jede Entscheidung dokumentiert, jeder Zugriff nachvollziehbar.
</p>
<p class="text-body text-gosign-text-light mt-3">
<strong>Sie erkennen sich wieder, wenn:</strong> mehrere Standorte, DMS- und Fachverfahrens-Landschaft, eigene Prozesse - und Prüfungs- wie Dokumentationspflichten, die über einen Chat weit hinausgehen.
</p>
</article>
</div>
<div class="max-w-narrow">
<p class="text-body-lg text-gosign-text-light mt-8">
Der Redaktions-Gateway ist auf allen Stufen gleich konzipiert: Pseudonymisierung vor dem Modell-Aufruf, Wieder-Einsetzung danach, Audit-Trail ohne Klartext. Das ist Datenminimierung und Defense-in-Depth - nicht die Erfüllungsbedingung des § 203. Die trägt die Vertragskette. Preise und Leistungsschnitt jeder Stufe stehen auf der <a href="/de/berufsgeheimnistraeger/angebot/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Angebots-Übersicht</a> - inklusive der drei Fragen zur Selbst-Einordnung.
</p>
</div>
</div>
</section>

<!-- Vertragskit -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Das 203er-Vertragskit: einsehbar vor jeder Registrierung</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Nachweisbarkeit heißt: Sie können die Vertragsbausteine lesen, bevor Sie mit uns sprechen. In unserem eigenen Markt-Screening vom 22.07.2026 - Kriterien und Trefferliste legen wir im Gespräch offen - hatten rund 8 von rund 25 geprüften Anbietern überhaupt ein belastbares Vertragsartefakt - die Kombination aus frei einsehbarem Dokument vor jeder Registrierung, eigenständiger Abs.-4-Urkunde und anwaltlicher Freigabe war zum Stichtag unbesetzt. Zwei der drei Elemente sind seit v0.4 live (frei einsehbar, eigenständige Urkunde); die externe anwaltliche Freigabe steht aus und wird transparent ausgewiesen. Das Kit umfasst:
</p>
<ul class="mt-6 space-y-3">
<li class="text-body-lg text-gosign-text-light"><a href="/downloads/203-vertragskit/zusatzvereinbarung-203-abs4.md" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors"><strong>Eigenständige § 203-Abs.-4-Zusatzvereinbarung</strong></a> inklusive strafrechtlicher Belehrung - als Urkunde, nicht als AVV-Klausel</li>
<li class="text-body-lg text-gosign-text-light"><a href="/downloads/203-vertragskit/avv-baustein-gosign.md" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors"><strong>AVV-Baustein mit Gosign-Selbstverpflichtung</strong></a> - Gosign als benannter Verarbeiter und mitwirkende Person mit eigener Personal-Verpflichtung</li>
<li class="text-body-lg text-gosign-text-light"><a href="/downloads/203-vertragskit/subprozessoren.md" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors"><strong>Subprozessor-Dokumentation</strong></a> - jedes Glied der Kette benannt</li>
<li class="text-body-lg text-gosign-text-light"><a href="/downloads/203-vertragskit/tia-scc-baustein.md" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors"><strong>TIA/SCC-Baustein</strong></a> mit DPF-Status je Anbieter</li>
<li class="text-body-lg text-gosign-text-light"><a href="/downloads/203-vertragskit/dsfa-vorlage.md" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors"><strong>DSFA-Vorlage</strong></a> mit Gosign-Zulieferbausteinen (Art. 35, Assistenz nach Art. 28 Abs. 3 lit. f DSGVO)</li>
<li class="text-body-lg text-gosign-text-light"><a href="/downloads/203-vertragskit/retention-matrix-einwilligung-transparenz.md" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors"><strong>Retention-Matrix pro Datenart</strong></a> plus Muster-Einwilligungen (Mandanten- und Beteiligten-Variante) und Muster-Transparenzhinweis (Art. 13/14 DSGVO)</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-6">
Der Status, ehrlich benannt: Das Kit ist frei einsehbar (v0.4, intern mehrstufig rechtsgeprüft - zwei 10-Linsen-Audits 07/2026); die externe anwaltliche Freigabe steht aus. Den Nutzungs-Rahmen erklärt das <a href="/downloads/203-vertragskit/README.md" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">README des Kits</a>. Jedes Dokument trägt den Hinweis: Muster zur anwaltlichen Einzelfall-Anpassung, ohne Gewähr, ersetzt keine Rechtsberatung.
</p>
</div>
</div>
</section>

<!-- Berufsgruppen + Readiness -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-2">Ihre Berufsgruppe, Ihre Rechtsgrundlage</h2>
<p class="text-body text-gosign-text-light mb-8 max-w-narrow">
Die DAV-Linie gilt anwaltlich - Steuerberater, Wirtschaftsprüfer und weitere Berufsgruppen haben eigene, teils konservativere Regeln. Deshalb mappt jeder Spoke seine eigene Rechtsgrundlage.
</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/de/berufsgeheimnistraeger/anwaelte/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Rechtsanwälte</p>
<p class="text-body font-semibold text-gosign-dark">§ 43e BRAO, BRAK-Leitfaden, DAV-Linie - und welche Aufgaben KI in der Kanzlei heute übernimmt</p>
</a>
<a href="/de/berufsgeheimnistraeger/steuerberater-wp/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Steuerberater / Wirtschaftsprüfer</p>
<p class="text-body font-semibold text-gosign-dark">§ 62a StBerG, § 50a WPO, BStBK-FAQ - inklusive der sachlichen DATEV-Abgrenzung</p>
</a>
<div class="block border border-gosign-border rounded-card p-6">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">203er-Readiness-Check</p>
<p class="text-body font-semibold text-gosign-dark">Selbsteinschätzung ohne E-Mail-Zwang - in Vorbereitung. Bis dahin ordnen wir Ihre Ausgangslage im <a href="/de/kontakt/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">Gespräch</a> ein.</p>
</div>
</div>
</div>
</section>

<!-- Trust -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Wer hinter dem Angebot steht</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Die Vertragskette zeichnet die Gosign GmbH - deshalb wohnt der Nachweis auf dieser Firmen-Domain. Gosign entwickelt seit 25 Jahren Software in Hamburg, mit 108 Mitarbeitern und über 5.000 Projekten. Die dedizierten Kanzlei-Instanzen der Stufe 1 laufen unter der Produktmarke veryai.de; Token-Pakete, Tenant-Setups und der Managed Stack sind Gosign-Leistungen mit Gosign-Vertragskette. Referenz-Kanzleien entstehen derzeit im <a href="/de/berufsgeheimnistraeger/design-partner/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Design-Partner-Programm</a> - die ersten Plätze sind offen.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Diese Seite beschreibt Vertrags- und Architektur-Bausteine aus Anbieter-Perspektive. Die berufsrechtliche Bewertung des Einzelfalls obliegt der Kanzlei und ihren Beratern - wir liefern die Kette und die Dokumente, auf denen diese Bewertung aufsetzen kann.
</p>
</div>
</div>
</section>

--- KI im Notariat: § 18 BNotO, § 203 StGB - und welche Produktform zum Amt passt ---
> Notarielle Verschwiegenheit nach § 18 BNotO, § 26a BNotO und § 203 StGB beim KI-Einsatz: Verpflichtungs-Kette, die Cloud-Vorgaben der Bundesnotarkammer - und der sachliche Vergleich der Produktformen SaaS, Lokalmodell, eigener Tenant.

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-body-lg text-gosign-text-light">
Notare tragen eine der strengsten Verschwiegenheits-Konstellationen im § 203-Katalog: Amtspflicht nach § 18 BNotO, Strafbewehrung über § 203 StGB, Dienstaufsicht - und Urkundsvorgänge, bei denen die Begründungslast für jede Auslagerung höher liegt als im gewerblichen Umfeld. Zugleich ist das Notariat der Berufszweig, in dem KI-Anbieter bereits konkret positioniert sind. Wer hier einsteigt, braucht keine Erst-Erklärung, sondern eine Entscheidungs-Grundlage: <strong class="text-gosign-dark">Welche Produktform passt zu welchem Notariat - und welche Kette steht dahinter?</strong>
</p>
<p class="text-body text-gosign-text-light mt-4">
Diese Seite ordnet die Rechtslage ein, benennt die existierenden Markt-Angebote mit Quellen und stellt die drei Produktformen sachlich nebeneinander. Den Überblick über alle Berufsgruppen gibt die <a href="/de/berufsgeheimnistraeger/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Einstiegsseite KI für Berufsgeheimnisträger (§ 203 StGB)</a>.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Die Rechtslage: § 18 BNotO, § 26a BNotO - und § 203 Abs. 1 Nr. 3 StGB</h2>
<p class="text-body-lg text-gosign-text-light mb-8">
Die notarielle Verschwiegenheitspflicht folgt aus <strong class="text-gosign-dark">§ 18 BNotO</strong>: Der Notar ist zur Verschwiegenheit verpflichtet; diese Amtspflicht bezieht sich auf alles, was ihm bei Ausübung seines Amtes bekannt geworden ist. Die Verschwiegenheit der im Notariat beschäftigten Personen sichert § 26 BNotO über deren förmliche Verpflichtung nach § 1 Verpflichtungsgesetz, die u. a. auf die Verschwiegenheitspflicht des § 18 verweist. Strafrechtlich flankiert <strong class="text-gosign-dark">§ 203 Abs. 1 Nr. 3 StGB</strong> das unbefugte Offenbaren - Notare stehen dort im selben Katalog wie Rechtsanwälte, Wirtschaftsprüfer und Steuerberater. Drei Regelungs-Ebenen bestimmen den KI-Einsatz:
</p>
<div class="space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">§ 26a BNotO: Dienstleister-Einbindung ist ausdrücklich geregelt</p>
<p class="text-body-lg text-gosign-text-light mt-1">Seit der Geheimnisschutz-Reform dürfen Notare Dienstleistern Zugang zu geschützten Tatsachen eröffnen, soweit das für die Dienstleistung erforderlich ist - unter drei Bedingungen: sorgfältige Auswahl des Dienstleisters, vertragliche Verpflichtung zur Verschwiegenheit unter Belehrung über die strafrechtlichen Folgen, und bei Dienstleistungen, die unmittelbar einem einzelnen Amtsgeschäft dienen, die vorherige Einwilligung der Beteiligten (§ 26a Abs. 4 BNotO). Ein KI-Anbieter ist genau ein solcher Dienstleister - ein Standard-AVV nach Art. 28 DSGVO ersetzt diese notarrechtliche Verpflichtung nicht.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Drittland: eigene Normen, nicht die anwaltliche Schranke</p>
<p class="text-body-lg text-gosign-text-light mt-1">Eine dem § 43e Abs. 4 BRAO entsprechende ausdrückliche Auslandsschranke enthält § 26a BNotO nicht - die anwaltliche Norm lässt sich nicht pauschal aufs Notariat übertragen. Die Grenzen für Dienstleister außerhalb der EU setzen hier die Art. 44 ff. DSGVO und die Linie des BNotK-Rundschreibens, das US-Infrastruktur wegen des CLOUD Act kritisch bewertet. Für das Amt ist die praktische Konsequenz dieselbe: EU-Bezugswege ohne US-Exposition vermeiden die Prüfung, statt sie zu führen.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">BNotK-Rundschreiben 1/2026: die Cloud-Vorgaben der Kammer</p>
<p class="text-body-lg text-gosign-text-light mt-1">Die Bundesnotarkammer hat mit Rundschreiben 1/2026 vom 02.02.2026 („Cloud-Nutzung im Notariat") präzisiert, unter welchen Bedingungen Cloud-Dienste zulässig sind: professionelle Cloud-Lösungen grundsätzlich ja - bei Einhaltung der berufsrechtlichen, technischen und organisatorischen Anforderungen; Akten und Verzeichnisse gehören nicht in die Cloud, Hilfsmittel unter Voraussetzungen schon, mit regelmäßiger lokaler Sicherung in der Geschäftsstelle. KI-Dienste behandelt das Rundschreiben nur am Rande - cloud-basierte KI-Assistenten sind aber Cloud-Dienste und damit an genau diesen Vorgaben zu messen. Der Volltext ist nur im internen Bereich der BNotK zugänglich; unsere Wiedergabe stützt sich auf notarielle Fachbesprechungen (Quellen unten, Abruf 2026-07-22).</p>
</div>
</div>
<p class="text-body text-gosign-text-light mt-8">
Die vollständige Vertrags- und Technikkette - Abs.-4-Verpflichtung, AVV, Subunternehmer, EU-Deployment, Drittland-Baustein, Löschfristen, Transparenz - ist berufsübergreifend in der <a href="/de/berufsgeheimnistraeger/203er-kette/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">203er-Kette</a> beschrieben; sie gilt im Notariat unverkürzt, mit § 26a BNotO als zusätzlichem, notarrechtlichem Anker.
</p>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Der Markt: das Notariat ist adressiert - die ehrliche Ausgangslage</h2>
<p class="text-body-lg text-gosign-text-light">
Anders als bei Steuerberatern oder der privaten Krankenversicherung gibt es für Notare bereits spezialisierte Angebote (Stand der Markt-Sichtung: 22.07.2026):
</p>
<div class="mt-8 overflow-x-auto">
<table class="w-full text-left text-small border-collapse">
<thead>
<tr>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Anbieter</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Produktform</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Verschwiegenheits-Bezug (Eigenangabe)</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Fundstelle (Abruf 2026-07-22)</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Tara KI / notara</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">KI-Assistent fürs Notariat (SaaS)</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Verschwiegenheitsvereinbarung, Bezug auf das BNotK-Rundschreiben 1/2026, deutsches Hosting (Anbieterangabe)</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">notara.de/notara-ki/ (bewusst nicht verlinkt)</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">NeuraHaus</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Lokalmodell-Installation on-premise</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">§ 18 BNotO und § 203 StGB über das Lokal-Argument: Daten verlassen das Haus nicht (Anbieterangabe)</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">neurahaus.ai/branchen/notare (bewusst nicht verlinkt)</td></tr>
</tbody>
</table>
</div>
<p class="text-body text-gosign-text-light mt-6">
Beide Angaben sind Anbieter-Selbstauskünfte aus deren öffentlichen Seiten; die Tabelle zeigt belegbare Fakten, keine Qualitätsurteile. Die Fundstellen nennen wir als Klartext mit Abrufdatum. Dass der Markt besetzt ist, ist für Notariate eine gute Nachricht: Es gibt Auswahl - und damit die Pflicht zur Prüffrage, welche Kette hinter jedem Angebot steht.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Die eigentliche Entscheidung: Produktform folgt Notariats-Realität</h2>
<p class="text-body-lg text-gosign-text-light">
Die Markt-Angebote besetzen zwei Pole - SaaS-Assistent und Lokal-Installation. Die sachliche Frage ist nicht, welcher Pol „richtig" ist, sondern welche Kette und welcher Betrieb zum konkreten Notariat passen:
</p>
<div class="mt-8 overflow-x-auto">
<table class="w-full text-left text-small border-collapse">
<thead>
<tr>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Dimension</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">SaaS-Assistent</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Lokalmodell on-premise</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Eigener Tenant / API mit Gateway</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Übermittlung an Dritte</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">ja - Kette muss vollständig belegt sein (Verschwiegenheitsverpflichtung, Subunternehmer, EU-Deployment)</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">im Regelbetrieb nein</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">ja, aber im eigenen Vertragsverhältnis; das Gateway pseudonymisiert vor dem Modell-Aufruf</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Betriebslast beim Notariat</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">gering</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">vollständig (Updates, Patches, Zugriffskontrolle, Backup)</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">geteilt - Governance-Betrieb beim Dienstleister, Tenant beim Notariat</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Modell-Leistung</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Anbieter-abhängig</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">begrenzt auf lokal lauffähige Modelle und vorhandene Hardware</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Zugang zu Cloud-Modellen über geprüfte Bezugswege</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Audit-Trail / Nachweis</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Anbieter-abhängig - einfordern</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">selbst zu bauen</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">klartextfreies Protokoll als Architektur-Bestandteil</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Passt typischerweise zu</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Einzelnotariat ohne IT-Betreuung</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Notariat mit belastbarer IT-Betreuung und begrenzten Anforderungen</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">größere Notariate und Verbünde mit Fachverfahrens-Integration</td></tr>
</tbody>
</table>
</div>
<p class="text-body text-gosign-text-light mt-6">
Diese Tabelle zeigt architektonische Unterschiede, keine Qualitätsurteile.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Der dritte Weg - Bezugsweg-Setup mit vorgelagerter Pseudonymisierung, klartextfreiem Audit-Trail und der vollständigen Vertragskette - schließt die Lücke zwischen den beiden Polen: mehr Modell-Leistung und weniger Betriebslast als lokal, mehr Nachweis-Tiefe als generisches SaaS. Die Pseudonymisierung ist dabei Datenminimierung und zweite Verteidigungslinie - die Verschwiegenheits-Absicherung selbst trägt die Vertragskette. Es ist kein Notariats-Sonderweg, sondern dieselbe Treppe, die für alle Berufsgeheimnisträger gilt: <a href="/de/berufsgeheimnistraeger/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">KI für Berufsgeheimnisträger (§ 203)</a>.
</p>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Was ein Notariat jeden Anbieter fragen sollte</h2>
<p class="text-body-lg text-gosign-text-light mb-8">
Unabhängig von der Produktform - die Prüffragen sind die acht Glieder der Kette, zwei davon notariats-scharf gestellt:
</p>
<div class="space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">1 - Verpflichtungs-Nachweis</p>
<p class="text-body-lg text-gosign-text-light mt-1">Liegt die Verschwiegenheitsverpflichtung nach § 203 Abs. 4 StGB und § 26a BNotO als eigenständiges, vor Vertragsschluss einsehbares Dokument vor - mit Belehrung über die strafrechtlichen Folgen, und erfasst sie alle Subunternehmer?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">2 - Cloud-Vorgaben der Kammer</p>
<p class="text-body-lg text-gosign-text-light mt-1">Kann der Anbieter konkret darlegen, wie sein Setup zu den Vorgaben des BNotK-Rundschreibens 1/2026 steht - Trennung von Akten/Verzeichnissen und Hilfsmitteln, lokale Sicherung, Verarbeitungsort und US-Infrastruktur-Frage - statt das Rundschreiben nur zu erwähnen?</p>
</div>
</div>
<p class="text-body-lg text-gosign-text-light mt-8">
Die übrigen sechs Prüffragen inklusive Fristen-Matrix und Drittland-Baustein: <a href="/de/berufsgeheimnistraeger/203er-kette/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Die 203er-Kette</a>.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Welche Stufe passt zu welchem Notariat</h2>
<p class="text-body-lg text-gosign-text-light">
Notariate unterscheiden sich in Größe, IT-Betreuung und Fachverfahrens-Tiefe - die Treppe bildet das ab: Für das Einzelnotariat ohne eigene IT ist die dedizierte Instanz mit mitgelieferter Vertragskette der schnellste konforme Weg; Sozietäten und Verbünde mit eigener IT-Governance fahren den eigenen Tenant mit Redaktions-Gateway; wo KI in Fachverfahren und Entwurfs-Workflows integriert werden soll, wird daraus ein Managed-Projekt mit Audit-Trail pro Verarbeitungsschritt. Alle Stufen teilen dieselbe Architektur-Anforderung: Pseudonymisierung vor dem Modell-Aufruf, vollständige Verpflichtungs-Kette, dokumentierter Nachweis.
</p>
<p class="text-body text-gosign-text-light mt-4">
Welche Stufe zu Ihrem Notariat passt, klären wir im Gespräch - mit der Kette auf dem Tisch, nicht als Versprechen. Der Einstiegspunkt für alle Berufsgruppen bleibt die <a href="/de/berufsgeheimnistraeger/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Übersichtsseite</a>; die Vertrags- und Nachweisglieder im Detail zeigt die <a href="/de/berufsgeheimnistraeger/203er-kette/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">203er-Kette</a>.
</p>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Quellen</h2>
<div class="space-y-2 text-body text-gosign-text-light">
<p>§ 18 BNotO (Verschwiegenheitspflicht): <a href="https://www.gesetze-im-internet.de/bnoto/__18.html" class="text-gosign-accent-text hover:underline" rel="noopener">gesetze-im-internet.de/bnoto/__18.html</a> (Abruf 2026-07-22)</p>
<p>§ 26a BNotO (Inanspruchnahme von Dienstleistungen): <a href="https://www.gesetze-im-internet.de/bnoto/__26a.html" class="text-gosign-accent-text hover:underline" rel="noopener">gesetze-im-internet.de/bnoto/__26a.html</a> (Abruf 2026-07-22)</p>
<p>§ 203 StGB (Verletzung von Privatgeheimnissen, Notare in Abs. 1 Nr. 3): <a href="https://www.gesetze-im-internet.de/stgb/__203.html" class="text-gosign-accent-text hover:underline" rel="noopener">gesetze-im-internet.de/stgb/__203.html</a> (Abruf 2026-07-22)</p>
<p>BNotK-Rundschreiben 1/2026 vom 02.02.2026 („Cloud-Nutzung im Notariat"): Volltext im internen Bereich der Bundesnotarkammer, nicht öffentlich. Wiedergabe nach den Fachbesprechungen von Notar Tobias Scheidacker: <a href="https://hnts.legal/post/cloud-nutzung-im-notariat-nach-dem-bnotk-rundschreiben-1-2026" class="text-gosign-accent-text hover:underline" rel="noopener">hnts.legal</a> (Abruf 2026-07-22) und des Legal-Tech-Verzeichnisses: <a href="https://legal-tech-verzeichnis.de/legal-tech-nachrichten/das-neue-bnotk-rundschreiben-rueckenwind-fuer-die-cloud-im-notariat/" class="text-gosign-accent-text hover:underline" rel="noopener">legal-tech-verzeichnis.de</a> (Abruf 2026-07-22)</p>
<p>Anbieter-Selbstauskünfte (Markt-Tabelle, bewusst nicht verlinkt): notara.de/notara-ki/ (Abruf 2026-07-22) · neurahaus.ai/branchen/notare (Abruf 2026-07-22)</p>
</div>
<p class="text-body text-gosign-text-light mt-8">
Diese Seite ist eine architektur- und governance-fachliche Einordnung, keine Rechtsberatung. Die notarrechtliche Prüfung des Einzelfalls - einschließlich der Anwendung des BNotK-Rundschreibens auf das konkrete Setup - obliegt dem Amtsträger bzw. seinen rechtlichen Beratern. Die strafrechtliche Einordnung automatisierter KI-Verarbeitung ist gerichtlich nicht abschließend geklärt.
</p>
</div>
</section>

--- KI in der privaten Krankenversicherung: § 203 ohne Kammer - was stattdessen gilt ---
> § 203 Abs. 1 Nr. 7 StGB für PKV-Unternehmen: Verpflichtungs-Kette über Arbeits- und Datenschutzrecht statt Kammer-Berufsrecht, Art.-9-Gesundheitsdaten, DSFA - und warum der Markt hier leer ist.

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-body-lg text-gosign-text-light">
Die private Krankenversicherung ist die am meisten übersehene § 203-Zielgruppe: Ihre Beschäftigten stehen im Täterkreis des § 203 Abs. 1 Nr. 7 StGB - aber anders als Anwälte, Steuerberater oder Notare haben sie <strong class="text-gosign-dark">keine Kammer, kein Berufsrecht und keine berufsständische KI-Leitlinie</strong>, an der sich ein KI-Einsatz ausrichten ließe. Wer hier KI mit Gesundheits- und Leistungsdaten einführen will, setzt die Leitplanken aus drei anderen Rechtsgebieten zusammen: Strafrecht, Datenschutzrecht, Arbeitsrecht.
</p>
<p class="text-body text-gosign-text-light mt-4">
Diese Seite ordnet alle drei ein, benennt die Art.-9-Ebene, die keine Vertragskette ersetzt, und zeigt den Markt-Befund mit Stichtag. Den Überblick über alle Berufsgruppen gibt die <a href="/de/berufsgeheimnistraeger/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Einstiegsseite KI für Berufsgeheimnisträger (§ 203 StGB)</a>.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Wer bei der PKV unter § 203 fällt - und warum das die IT-Frage verändert</h2>
<p class="text-body-lg text-gosign-text-light">
§ 203 Abs. 1 Nr. 7 StGB stellt das unbefugte Offenbaren fremder Geheimnisse unter Strafe, die jemandem als <strong class="text-gosign-dark">Angehörigem eines Unternehmens der privaten Kranken-, Unfall- oder Lebensversicherung</strong> oder einer privatärztlichen, steuerberaterlichen oder anwaltlichen Verrechnungsstelle anvertraut worden oder sonst bekanntgeworden sind. In älteren Texten läuft dieselbe Konstellation noch unter „Nr. 6" - die Neufassung des § 203 von 2017 hat den Katalog neu nummeriert; maßgeblich ist der aktuelle Gesetzestext.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Praktisch heißt das: Die Verschwiegenheitspflicht liegt nicht bei einer kleinen Gruppe von Gesellschaftsärzten, sondern quer durch die Sachbearbeitung - Leistungsprüfung, Antragsprüfung mit Gesundheitsfragen, Pflege-Leistungsfälle, Gesundheitsservices. Genau die Prozesse, in denen KI-Unterstützung den größten Hebel hat (Dokumenten-Klassifikation, Arztbrief-Zusammenfassung, Korrespondenz-Entwürfe), sind die Prozesse mit den anvertrauten Geheimnissen.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Für die Einbindung von Dienstleistern gilt dieselbe Mechanik wie bei allen § 203-Verpflichteten: § 203 Abs. 3 Satz 2 StGB erlaubt die Offenbarung gegenüber mitwirkenden Personen, soweit sie für deren Tätigkeit erforderlich ist; Abs. 4 verlangt, dass diese mitwirkenden Personen zur Geheimhaltung verpflichtet werden - sonst haftet der Verpflichtete selbst. Die vollständige Vertrags- und Technikkette mit allen acht Gliedern ist in der <a href="/de/berufsgeheimnistraeger/203er-kette/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">203er-Kette</a> beschrieben.
</p>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Kein Kammer-Berufsrecht: was die Leitplanken stattdessen setzen</h2>
<p class="text-body-lg text-gosign-text-light mb-8">
Anwälte haben § 43e BRAO und den BRAK-Leitfaden, Steuerberater § 62a StBerG und die BStBK-FAQ. PKV-Beschäftigte haben nichts davon - es gibt keine Kammer, die eine KI-Linie vorgibt. Die Leitplanken kommen stattdessen aus drei Rechtsgebieten:
</p>
<div class="space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Datenschutzrecht</p>
<p class="text-body-lg text-gosign-text-light mt-1">Das DSGVO-Vollprogramm: Art. 28 (Auftragsverarbeitung), Art. 44 ff. (Drittlandtransfer) - und vor allem Art. 9 für Gesundheitsdaten, dazu unten mehr. Weil die berufsrechtliche Auslandsschranke der Kammerberufe hier fehlt, ist die DSGVO-Drittlandprüfung die maßgebliche Grenze für Dienstleister außerhalb der EU; der CLOUD Act macht US-Anbieter zum eigenen Prüfpunkt.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Arbeitsrecht</p>
<p class="text-body-lg text-gosign-text-light mt-1">Die Abs.-4-Verpflichtung der eigenen Beschäftigten und der Dienstleister-Mitarbeiter läuft über arbeitsvertragliche Verpflichtungserklärungen inklusive Belehrung über die strafrechtlichen Folgen einer Verletzung. Sie ist aktiv zu organisieren und zu dokumentieren - keine Kammer prüft sie, kein Standesrecht erinnert daran.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Interne Compliance und Gremien</p>
<p class="text-body-lg text-gosign-text-light mt-1">Ohne Kammer-FAQ trägt die eigene Governance die Begründungslast: Verarbeitungsverzeichnis, Datenschutz-Folgenabschätzung, Einbindung von Datenschutzbeauftragtem und Mitbestimmungsgremien, dokumentierte Freigabe-Entscheidungen pro KI-Anwendungsfall.</p>
</div>
</div>
<p class="text-body text-gosign-text-light mt-8">
<strong class="text-gosign-dark">Einordnung der Rechtslinien:</strong> Die viel zitierte Auffassung, dass rein automatisierte Verarbeitung ohne menschlichen Klartext-Zugriff kein „Offenbaren" ist, stammt aus der <strong class="text-gosign-dark">anwaltlichen</strong> Debatte - DAV-Stellungnahme SN 32/2025, eine Verbands-Auffassung; die BRAK ist konservativer und hält bereits die Möglichkeit der Kenntnisnahme für kritisch; gerichtlich ist die Frage nicht abschließend geklärt. Weil sie die allgemeine Dogmatik des Offenbarens in § 203 Abs. 1 betrifft, ist sie auch für Nr.-7-Verpflichtete relevant - aber sie ist keine PKV-spezifische Aufsichts-Position und darf nicht als solche verkauft werden. Wie die anwaltliche Rechtslage im Detail aussieht, zeigt der <a href="/de/berufsgeheimnistraeger/anwaelte/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Spoke für Rechtsanwälte</a>.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Art. 9 DSGVO: die zweite Ebene, die dieser Content nicht löst</h2>
<p class="text-body-lg text-gosign-text-light mb-6">
Gesundheitsdaten sind besondere Kategorien personenbezogener Daten. Daraus folgt der Hinweis, der in jeder PKV-KI-Planung ganz oben stehen muss:
</p>
<div class="border-l-4 border-gosign-accent bg-gosign-white pl-6 pr-6 py-5">
<p class="text-body-lg font-bold text-gosign-dark">Zusätzlich zur § 203-Absicherung sind eine Art.-9-Rechtsgrundlage und eine Datenschutz-Folgenabschätzung (DSFA) nötig - dieser Content ersetzt sie nicht.</p>
</div>
<p class="text-body-lg text-gosign-text-light mt-6">
Konkret: Die Verarbeitung von Gesundheitsdaten durch ein KI-System braucht eine eigene Rechtsgrundlage aus Art. 9 Abs. 2 DSGVO. Welcher Tatbestand trägt - Einwilligung, vertragsbezogene oder versicherungsspezifische Grundlagen -, ist Einzelfall-Juristerei pro Prozess; eine pauschale Antwort wäre unseriös. Die Datenschutz-Folgenabschätzung nach Art. 35 DSGVO ist bei systematischer Verarbeitung sensibler Daten mit neuer Technologie regelmäßig verpflichtend.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Was ein KI-Dienstleister dazu schuldet, ist klar umrissen: Zulieferung nach Art. 28 Abs. 3 lit. f DSGVO - Verarbeitungsbeschreibung, technische und organisatorische Maßnahmen, benannte Subprozessoren, Restrisiken. Die Rechtsgrundlagen-Wahl und die DSFA selbst bleiben beim Verantwortlichen: beim Versicherer.
</p>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Der Markt-Befund: niemand adressiert die PKV - Stand 22.07.2026</h2>
<p class="text-body-lg text-gosign-text-light">
Unser Wettbewerbs-Screening über rund 25 Anbieter im DACH-§ 203-Markt (Stand 22.07.2026) hat <strong class="text-gosign-dark">keinen dedizierten KI-Anbieter für private Krankenversicherer</strong> gefunden: Die Angebote adressieren Kanzleien, Steuerberater, Ärzte, Kliniken und Notare - die PKV als Nr.-7-Verpflichtete taucht in keinem geprüften Angebot als eigene Zielgruppe auf. Das ist ein Negativ-Befund mit Stichtag, kein Vollständigkeitsbeweis.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Für PKV-Compliance-Verantwortliche bedeutet das zweierlei: Es gibt kein Regal-Produkt, das die Nr.-7-Konstellation fertig löst - und jeder generische „§ 203-konform"-Claim eines Kanzlei-Tools ist auf die Versicherungs-Situation ungeprüft übertragen. Die Prüffragen bleiben dieselben acht Glieder der <a href="/de/berufsgeheimnistraeger/203er-kette/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">203er-Kette</a>; die Antworten muss ein Anbieter für die Versicherungs-Konstellation geben können, nicht für die Kanzlei-Konstellation.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Wofür die PKV KI konkret einsetzt - und was beim Menschen bleibt</h2>
<p class="text-body-lg text-gosign-text-light mb-8">
Vier Aufgaben-Klassen tragen den Hebel im Versicherungs-Betrieb - jede mit einer ehrlichen Angabe, was die KI leistet und was in menschlicher Verantwortung bleibt:
</p>
<div class="space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Dokumenten-Klassifikation im Leistungseingang</p>
<p class="text-body-lg text-gosign-text-light mt-1">Rechnungen, Arztbriefe, Verordnungen und Belege werden klassifiziert, Metadaten (Behandler, Zeitraum, Beträge, Tarifbezug) extrahiert und dem Vorgang zugeordnet. Was bleibt: Die leistungsrechtliche Würdigung liegt beim Sachbearbeiter; extrahierte Werte werden gegen das Dokument geprüft, nicht ungeprüft übernommen.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Arztbrief- und Gutachten-Zusammenfassung</p>
<p class="text-body-lg text-gosign-text-light mt-1">Umfangreiche medizinische Unterlagen werden verdichtet, Auffälligkeiten und fehlende Angaben markiert. Was bleibt: Die medizinische und tarifliche Bewertung - die Zusammenfassung ist Arbeitshilfe mit Quellen-Rückgriff, keine Entscheidungsgrundlage ohne Prüfung des Originals.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Korrespondenz-Entwürfe</p>
<p class="text-body-lg text-gosign-text-light mt-1">Unterlagen-Nachforderungen, Erläuterungen zu Erstattungen, Antwort-Entwürfe auf Kundenanfragen - die KI entwirft, der Mensch prüft und versendet. Was bleibt: Aussagen mit Rechtswirkung (Fristen, Leistungszusagen oder -ablehnungen, Beträge) werden vor Versand fachlich verifiziert.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Leistungsentscheidungen: der Decision-Layer-Kernfall</p>
<p class="text-body-lg text-gosign-text-light mt-1">Die KI bereitet vor - Vollständigkeits-Check, Tarif-Zuordnung, Auffälligkeits-Hinweise. Die Entscheidung selbst trifft ein Mensch oder ein dokumentiertes, versioniertes Regelwerk, nie das Sprachmodell allein; jeder Schritt bleibt nachvollziehbar und anfechtbar. Genau diese Trennung ist die Antwort, die Aufsicht und Betroffene bei automatisierungsnahen Leistungsprozessen zuerst hören wollen.</p>
</div>
</div>
<p class="text-body text-gosign-text-light mt-8">
<strong class="text-gosign-dark">Restrisiko, ehrlich benannt:</strong> Auch eine vorgelagerte PII-Redaktion erkennt nicht jedes Identifikationsmerkmal - verkettete Kontexte oder seltene Diagnose- und Datums-Kombinationen können durchrutschen. Die Redaktion ist Datenminimierung und zweite Verteidigungslinie, nicht die Erfüllungsbedingung der Verschwiegenheit; die trägt die Vertragskette. Und für alle vier Aufgaben-Klassen gilt die Art.-9-Ebene aus dem Abschnitt darüber unverändert.
</p>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Wie ein PKV-Setup aussieht: eigener Tenant statt SaaS-Funnel</h2>
<p class="text-body-lg text-gosign-text-light">
Versicherer bringen mit, was Kanzleien fehlt: eigene IT, eigene Cloud-Verträge, eigene Compliance-Organisation. Das passende Muster ist deshalb nicht der SaaS-Chat von der Stange, sondern das <strong class="text-gosign-dark">Setup im eigenen Cloud-Tenant oder als Managed Stack</strong> - mit durchgängiger Governance als Architektur-Anforderung: Pseudonymisierung vor dem Modell-Aufruf, klartextfreier Audit-Trail, Verpflichtungs-Kette über alle Dienstleister und Subprozessoren, Fristen-Matrix pro Datenart. Die Pseudonymisierung ist dabei Datenminimierung und zweite Verteidigungslinie - die Verschwiegenheits-Absicherung selbst trägt die Vertragskette.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Für Prozesse mit Entscheidungscharakter - Leistungsentscheidungen sind der Kernfall - kommt die Architektur-Frage nach dem Decision Layer dazu: Welche Schritte entscheidet ein Mensch, welche ein Regelwerk, welche die KI - dokumentiert, nachvollziehbar, anfechtbar. Das ist keine Zusatz-Bürokratie, sondern die Antwort, die Datenschutz-Aufsicht und Betroffene bei automatisierungsnahen Leistungsprozessen zuerst hören wollen.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Für Versicherer kommen aufsichtsrechtliche Anforderungen (u. a. BaFin-Auslagerungsregeln/VAIT) und die EU-AI-Act-Einstufung der Leistungsprüfung hinzu - diese Ebenen adressiert das Setup-Projekt individuell; dieser Wissens-Hub deckt die § 203-/Datenschutz-Ebene.
</p>
<p class="text-body text-gosign-text-light mt-4">
Wie eine solche Architektur aussieht, zeigt die <a href="/de/governance/referenz-architektur/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Referenz-Architektur</a>; die Vertrags- und Nachweisglieder im Detail die <a href="/de/berufsgeheimnistraeger/203er-kette/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">203er-Kette</a>. Den Einstieg über alle Berufsgruppen und Produktformen ordnet die <a href="/de/berufsgeheimnistraeger/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Übersichtsseite</a> ein.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Quellen</h2>
<div class="space-y-2 text-body text-gosign-text-light">
<p>§ 203 StGB (Verletzung von Privatgeheimnissen), aktuelle Fassung mit Katalog Abs. 1 Nr. 1–7: <a href="https://www.gesetze-im-internet.de/stgb/__203.html" class="text-gosign-accent-text hover:underline" rel="noopener">gesetze-im-internet.de/stgb/__203.html</a> (Abruf 2026-07-22)</p>
<p>DSGVO, konsolidierte Fassung (Art. 9, 28, 35, 44 ff.): <a href="https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32016R0679" class="text-gosign-accent-text hover:underline" rel="noopener">eur-lex.europa.eu (CELEX 32016R0679)</a> (Abruf 2026-07-22)</p>
<p>DAV-Stellungnahme SN 32/2025 zum KI-Einsatz in der Anwaltschaft (anwaltliche Verbands-Auffassung): <a href="https://anwaltverein.de/newsroom/sn-32-25-einsatz-von-ki-in-der-anwaltschaft" class="text-gosign-accent-text hover:underline" rel="noopener">anwaltverein.de</a> (Abruf 2026-07-22)</p>
<p>BRAK-Leitfaden zum KI-Einsatz (Stand 12/2024, konservativere Linie): <a href="https://www.brak.de/fileadmin/service/publikationen/Handlungshinweise/BRAK_Leitfaden_mit_Hinweisen_zum_KI-Einsatz_Stand_12_2024.pdf" class="text-gosign-accent-text hover:underline" rel="noopener">brak.de (PDF)</a> (Abruf 2026-07-22)</p>
<p>Markt-Befund: eigenes Wettbewerbs-Screening über rund 25 DACH-Anbieter mit § 203-Bezug, Stand 22.07.2026 - Negativ-Befund zur PKV-Zielgruppe, kein Vollständigkeitsbeweis.</p>
</div>
<p class="text-body text-gosign-text-light mt-8">
Diese Seite ist eine architektur- und governance-fachliche Einordnung, keine Rechtsberatung. Die Wahl der Art.-9-Rechtsgrundlage, die DSFA und die arbeitsrechtliche Umsetzung der Verpflichtungen obliegen dem Verantwortlichen und seinen rechtlichen Beratern. Die strafrechtliche Einordnung automatisierter KI-Verarbeitung ist gerichtlich nicht abschließend geklärt.
</p>
</div>
</section>

--- KI für Steuerberater und Wirtschaftsprüfer - DATEV-Copilot, § 62a StBerG und der zweite Bezugsweg ---
> Was der kostenlose DATEV-Copilot abdeckt und wofür StB- und WP-Kanzleien einen zweiten konformen KI-Bezugsweg brauchen. § 62a StBerG, § 50a WPO, BStBK-FAQ, WPK-Linie.

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-body-lg text-gosign-text-light">
Steuerberater und Wirtschaftsprüfer sind die einzige Berufsgruppe unter den Berufsgeheimnisträgern, deren Standard-Software bereits eine kostenlose KI im eigenen Verschwiegenheits-Rahmen mitbringt: den DATEV-Copilot. Die Frage für StB- und WP-Kanzleien lautet deshalb nicht „dürfen wir KI nutzen?", sondern: <strong class="text-gosign-dark">Was deckt der DATEV-Rahmen ab - und für welche Aufgaben braucht die Kanzlei einen zweiten, ebenfalls konformen Bezugsweg?</strong>
</p>
<p class="text-body text-gosign-text-light mt-4">
Diese Seite beantwortet beides: die Rechtslage nach § 62a StBerG und § 50a WPO inklusive Mandanteneinwilligung und Auslandsschranke, die sachliche DATEV-Abgrenzung mit Quellen, typische Kanzlei-Aufgaben mit ehrlichem Restrisiko - und die Bezugsweg-Treppe von der dedizierten Kanzlei-Instanz bis zum Managed Stack. Den Überblick über alle Berufsgruppen gibt die <a href="/de/berufsgeheimnistraeger/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Einstiegsseite KI für Berufsgeheimnisträger (§ 203 StGB)</a>.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Die Rechtslage: § 62a StBerG und § 50a WPO verlangen mehr als einen AVV</h2>
<p class="text-body-lg text-gosign-text-light mb-8">
Für Steuerberater und Wirtschaftsprüfer ist die Einbindung externer Dienstleister - und ein KI-Anbieter ist genau das - berufsrechtlich ausdrücklich geregelt. Beide Normen sind nahezu parallel gebaut und verlangen dieselben drei Kettenglieder:
</p>
<div class="space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Verpflichtung in Textform</p>
<p class="text-body-lg text-gosign-text-light mt-1">§ 62a StBerG (für Steuerberater) und § 50a WPO (für Wirtschaftsprüfer) verlangen, dass der Dienstleister zur Verschwiegenheit verpflichtet wird - in Textform, unter Belehrung über die strafrechtlichen Folgen einer Verletzung. Ein Standard-AVV nach Art. 28 DSGVO leistet das nicht: Er regelt Datenschutz, nicht das Berufsgeheimnis. Es braucht eine eigenständige Verschwiegenheitsverpflichtung nach § 203 Abs. 4 StGB.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Mandanteneinwilligung bei mandatsbezogener Auslagerung (ausdrücklich empfohlen)</p>
<p class="text-body-lg text-gosign-text-light mt-1">Werden Dienstleister mandatsbezogen eingesetzt - und die Verarbeitung von Belegen, Abschlussentwürfen oder Mandanten-Korrespondenz durch eine KI ist mandatsbezogen -, verlangen beide Normen die Einwilligung des Mandanten (§ 62a Abs. 5 StBerG / § 50a Abs. 5 WPO); der Gesetzeswortlaut verlangt „eingewilligt" - eine ausdrückliche, dokumentierte Einwilligung ist aus Nachweisgründen aber dringend zu empfehlen. Die Einwilligungspflicht bei einzelmandatsbezogenen Dienstleistungen ist für Rechtsanwälte in § 43e Abs. 5 BRAO wortgleich geregelt (Parallelvorschrift, gleiche Verzichtsmöglichkeit in Abs. 6) - ein sachlicher Unterschied besteht insoweit nicht. Anwaltsspezifisch ist nicht die gesetzliche Einwilligungsregelung, sondern die berufspolitische Diskussion (DAV/BRAK). Wie die Einwilligung praktisch eingeholt wird, steht weiter unten.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Auslandsschranke: vergleichbarer Geheimnisschutz</p>
<p class="text-body-lg text-gosign-text-light mt-1">Dienstleister im Ausland sind nur zulässig, wenn dort ein vergleichbarer Geheimnisschutz besteht. Das ist die berufsrechtliche Schranke, die unabhängig vom DSGVO-Drittlandtransfer (Art. 44 ff.) greift - ein US-Sub-Processing kann also selbst mit Standardvertragsklauseln berufsrechtlich unzulässig sein. Der CLOUD Act macht die Frage bei US-Anbietern zum eigenen Prüfpunkt.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Der strafrechtliche Rahmen: § 203 StGB</p>
<p class="text-body-lg text-gosign-text-light mt-1">Steuerberater und Wirtschaftsprüfer sind Berufsgeheimnisträger nach § 203 Abs. 1 Nr. 3 StGB. Externe Dienstleister können als „sonstige mitwirkende Personen" nach Abs. 3 Satz 2 eingebunden werden; die Pflicht zur Verpflichtung folgt aus Abs. 4 Satz 2 Nr. 1 - wer den Dienstleister nicht zur Geheimhaltung verpflichtet, macht sich bei dessen Offenbarung selbst strafbar. Ob die rein automatisierte KI-Verarbeitung ohne menschlichen Klartext-Zugriff überhaupt ein „Offenbaren" ist, ist gerichtlich nicht abschließend geklärt - die Vertragskette ist deshalb der belastbare Teil, die Technik-Argumentation die zweite Sicherungslinie.</p>
</div>
</div>
<p class="text-body text-gosign-text-light mt-8">
<strong class="text-gosign-dark">Die Kammer-Anker:</strong> Die BStBK-FAQ zum KI-Einsatz (Stand 01/2026) hält KI für zulässig und bindet sie an genau diese Pflichten - sorgfältige Auswahl, Textform-Verpflichtung, eigenverantwortliche Prüfung der Ergebnisse. Die WPK-Linie wird in der Fachdiskussion als die konservativste zusammengefasst: KI-Einsatz nur in geschlossenen Systemen (Zusammenfassung der Kammer-Positionen: hassenpflug.online, Abruf 2026-07-22; siehe Quellenverzeichnis). Für Vorbehaltsaufgaben der Abschlussprüfung gilt die eigenverantwortliche Urteilsbildung des Prüfers - KI-Unterstützung ersetzt keine Prüfungshandlung. Beide Linien sprechen für dieselbe Konsequenz: kein Consumer-Dienst, sondern ein Bezugsweg mit Vertragsartefakt. Die für Anwälte diskutierte DAV-Verbandslinie ist anwaltsspezifisch und trägt für StB und WP nicht - maßgeblich sind die eigenen Normen und Kammer-Aussagen. Wie die anwaltliche Rechtslage aussieht, zeigt der <a href="/de/berufsgeheimnistraeger/anwaelte/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Spoke für Rechtsanwälte</a>.
</p>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Der DATEV-Copilot: fair eingeordnet - und sachlich abgegrenzt</h2>
<p class="text-body-lg text-gosign-text-light">
Zuerst die faire Würdigung: Der DATEV-Copilot ist für DATEV-Mitglieder kostenlos - Rollout ab Februar 2026, zentral über MyDATEV verfügbar seit Mai 2026 (Quellen: tax-tech.de und datev.de, Abruf jeweils 2026-07-22). Er läuft im DATEV-eigenen § 203-Rahmen - DATEV bindet seine Mitglieder über eine mitgliederweite Verschwiegenheitserklärung nach § 203 StGB ein, die über einen gewöhnlichen AVV hinausgeht (Quelle: datev.de, Vereinbarung zur Verschwiegenheitserklärung, Abruf 2026-07-22). Technisch setzt DATEV auf Azure OpenAI mit temporärer Verarbeitung und ohne Training auf Mitgliederdaten. Für DATEV-gebundene Fach-Workflows ist das ein konformer Einstieg zum Preis von null - wer ihn nicht aktiviert hat, sollte das tun.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Die Abgrenzung ist deshalb keine Warnung vor DATEV, sondern eine Inventur: Der Copilot ist an den DATEV-Kosmos gebunden - an dessen Fach-Workflows, dessen Modell-Auswahl und dessen Produktform. Fünf Anforderungen liegen strukturell außerhalb dieses Rahmens:
</p>
<div class="mt-8 overflow-x-auto">
<table class="w-full text-left text-small border-collapse">
<thead>
<tr>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Anforderung</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">DATEV-Copilot (Mitglieder-Rahmen)</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Zweiter Bezugsweg</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Generischer Chat über Fach-Workflows hinaus</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Chat-, Text- und Recherche-Funktionen im DATEV-Rahmen; Funktionsumfang wächst laufend</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Freier Kanzlei-Chat für Recherche, Entwürfe, Korrespondenz - mit § 203-Vertragskette</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Freie Modellwahl</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Modell-Auswahl liegt bei DATEV (Azure OpenAI)</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">DeepSeek, Standard-Claude-Modelle oder Gemini - jeweils über konforme Bezugswege mit ausgewiesenem 203er-Status pro Kombination</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">API-Zugang für eigene Tools</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Kein offener API-Zugang für Kanzlei-Eigenentwicklungen</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">203er-Token/API mit Vertragsartefakt - für Kanzlei-Tools und Legal-Tech-Integrationen</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Dedizierte Instanz mit eigener Datenbank</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Mandantenfähiger Mitglieder-Dienst im DATEV-Betrieb</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Single-Tenant-Instanz: eigene Subdomain, eigene Datenbank, eigene Schlüssel</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Kanzleiweite Dokument-Arbeit außerhalb DATEV</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Erstellt, verdichtet und übersetzt Dokumente innerhalb der DATEV-Programme</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Upload und Verarbeitung beliebiger Kanzlei-Dokumente: Verträge, Gutachten, Prüfungsunterlagen, Korrespondenz</td></tr>
</tbody>
</table>
</div>
<p class="text-body text-gosign-text-light mt-6">
Diese Tabelle zeigt Produktform-Unterschiede, keine Qualitätsurteile. Beide Wege schließen sich nicht aus: Der realistische Endzustand vieler Kanzleien ist der Copilot für DATEV-Workflows plus ein zweiter, vertraglich eigenständig abgesicherter Weg für alles andere.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Wofür StB- und WP-Kanzleien KI konkret einsetzen</h2>
<p class="text-body-lg text-gosign-text-light mb-8">
Vier Aufgaben-Klassen tragen den Kanzlei-Alltag - jede mit einer ehrlichen Angabe, was die KI leistet und was beim Berufsträger bleibt:
</p>
<div class="space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Beleg-Zusammenfassungen</p>
<p class="text-body-lg text-gosign-text-light mt-1">Ein Ordner Eingangsbelege geht ein. Die KI extrahiert Rechnungsnummern, Beträge, Leistungszeiträume und fasst Auffälligkeiten zusammen - etwa fehlende Pflichtangaben nach § 14 UStG. Was bleibt: Die steuerliche Würdigung und jede Buchungsentscheidung bleiben beim Berufsträger; extrahierte Zahlen werden gegen den Beleg geprüft, nicht übernommen.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Jahresabschluss-Anhang-Entwürfe</p>
<p class="text-body-lg text-gosign-text-light mt-1">Aus Vorjahres-Anhang, Summen- und Saldenliste und den Angaben des Mandats entsteht ein Anhang-Entwurf nach §§ 284 ff. HGB. Was bleibt: Der Entwurf ist Rohfassung, keine Freigabe - Vollständigkeit der Pflichtangaben und Bilanzierungs-Entscheidungen verantwortet der Abschlussersteller.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Prüfungsdokumentations-Entwürfe</p>
<p class="text-body-lg text-gosign-text-light mt-1">Für Wirtschaftsprüfer strukturiert die KI Arbeitspapier-Entwürfe: Zusammenfassung von Prüfungsnachweisen, Formulierung von Feststellungen, Konsistenz-Check gegen die Prüfungsstrategie. Was bleibt: Das Prüfungsurteil ist nach den IDW-Prüfungsstandards höchstpersönlich - die KI dokumentiert vor, sie prüft nicht.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Mandanten-Korrespondenz</p>
<p class="text-body-lg text-gosign-text-light mt-1">Fristen-Erinnerungen, Unterlagen-Anforderungen, Erläuterungs-Schreiben zu Bescheiden - die KI entwirft, der Berufsträger prüft und versendet. Was bleibt: Aussagen mit Rechtswirkung (Fristen, Rechtsbehelfe, Zahlungsbeträge) werden vor Versand fachlich verifiziert.</p>
</div>
</div>
<p class="text-body text-gosign-text-light mt-8">
<strong class="text-gosign-dark">Restrisiko, ehrlich benannt:</strong> Auch eine vorgelagerte PII-Redaktion erkennt nicht jedes Identifikationsmerkmal - ungewöhnliche Firmierungen, verkettete Kontexte oder Zahlen-Kombinationen können durchrutschen. Die Redaktion ist Datenminimierung und zweite Verteidigungslinie, nicht die Erfüllungsbedingung der Verschwiegenheit; die trägt die Vertragskette. Und fachlich gilt die Linie beider Kammern: KI-Ergebnisse sind Entwürfe, die eigenverantwortliche Prüfung durch den Berufsträger ersetzt sie nicht.
</p>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Der konforme Bezugsweg: eine Treppe, keine Einheitslösung</h2>
<p class="text-body-lg text-gosign-text-light">
Kanzleien unterscheiden sich in IT-Tiefe und Mandats-Struktur - der Bezugsweg muss das abbilden. Gosign liefert deshalb eine Treppe mit drei Stufen, alle mit derselben Vertrags- und Redaktions-Architektur:
</p>
<div class="mt-8 overflow-x-auto">
<table class="w-full text-left text-small border-collapse">
<thead>
<tr>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Stufe</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Für wen</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Was Sie bekommen</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Dedizierte Kanzlei-Instanz</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Kanzleien ohne eigene IT, 1-50 Personen</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Single-Tenant-Chat mit eigener Subdomain, eigener Datenbank und eigenen Schlüsseln, inklusive Datei-Upload und Vorlagen - als Produkt auf <a href="https://www.veryai.de/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">veryai.de</a> (ein Produkt der Gosign GmbH), 14 Tage kostenlos und ohne Zahlungsdaten testbar</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">203er-Token/API</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Kanzleien mit eigenen Tools, Legal-Tech, Software-Häuser</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">OpenAI-kompatible API mit § 203-Vertragskette und Redaktions-Gateway - oder Setup im eigenen Cloud-Tenant mit Governance und Antrags-Begleitung (Freigaben und Zeitpläne liegen beim jeweiligen Cloud-Anbieter)</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Managed 203er-Stack</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Große Kanzleien und Prüfungsgesellschaften</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Agenten, Konnektoren und Decision-Layer-Architektur als Projektgeschäft - mit Audit-Trail pro Entscheidung</td></tr>
</tbody>
</table>
</div>
<div class="mt-8 space-y-4">
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Kanzleiinhaberin ohne eigene IT:</strong> Die dedizierte Instanz ist in Tagen einsatzbereit - die Vertragskette (Verschwiegenheitsverpflichtung, AVV, Einwilligungs-Muster) gehört zum Setup, nicht zur Hausaufgabenliste der Kanzlei. Der Copilot bleibt daneben für die DATEV-Workflows im Einsatz.</p>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">IT-Verantwortlicher einer Prüfungsgesellschaft:</strong> Token/API oder Kunden-Tenant stellen die Governance-Fragen zuerst: Wer hält die Schlüssel, wo läuft die Inferenz, was steht im Audit-Trail, welche Modelle sind für welche Mandats-Klassen freigegeben. Diese Antworten liegen vor dem Rollout auf dem Tisch - nicht nach der ersten Nachfrage der Berufsaufsicht.</p>
</div>
<p class="text-body-lg text-gosign-text-light mt-8">
<strong class="text-gosign-dark">CLOUD-Act-freie Säulen für die Auslandsschranke:</strong> Wer die US-Drittland-Frage nicht führen will, wählt einen Bezugsweg ohne US-Exposition. Zwei Säulen tragen das heute: EU-Inferenz offener Modelle (Llama 3.3, Mistral 4, Qwen 3.6, Apertus, Gemma, GPT-OSS - kein DeepSeek) über einen EU-Betreiber, den wir angebunden haben, mit gezeichneter § 203-Zusatzvereinbarung - und deutsche Rechenzentren mit der seit 2021 standardisierten § 203-Verschwiegenheitsvereinbarung, die wir für die KI-Dienste gezeichnet haben und unter der DeepSeek R1 managed betrieben wird (Quelle: open-telekom-cloud.com, Abruf 2026-07-22). Standard-Claude-Modelle sind über EU-Endpunkte der Google-Plattform beziehbar - ohne Content-Zugriff von Google oder Anthropic und mit Zero-Data-Retention-Option; hier bleibt die US-Konzern-Exposition ein transparent auszuweisender Prüfpunkt. Der 203er-Status ist dabei immer eine Eigenschaft der Kombination aus Modell und Bezugsweg, nie des Modells allein. Welche Modell-Bezugsweg-Kombination für Ihre konkrete Aufgabe trägt - Belegextraktion, Mandantenkorrespondenz, Jahresabschluss-Entwurf -, zeigt der <a href="/de/ki-modelle-berufsgeheimnistraeger/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">203er-Modellkatalog</a> mit Status, Bedingung und Quelle je Kombination; die Belegextraktion im Besonderen führt die Seite <a href="/de/ki-modelle-berufsgeheimnistraeger/datenextraktion-belege/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Datenextraktion aus Belegen</a>. Die fachliche Modellwahl jenseits der Zulässigkeits-Frage ordnet der allgemeine <a href="/de/magazin/ki-modelle-vergleich-2026/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Modellvergleich 2026</a> ein.
</p>
<p class="text-body text-gosign-text-light mt-4">
In allen Stufen ist die PII-Redaktion mit klartextfreiem Audit-Trail als Standard-Architektur vorgesehen - Pseudonymisierung vor dem Modell-Aufruf, Wieder-Einsetzung danach, protokollierte Ausnahmen. Sie ist Datenminimierung nach Art. 5 DSGVO und zweite Verteidigungslinie - die Verschwiegenheits-Absicherung selbst trägt die Vertragskette nach § 62a StBerG bzw. § 50a WPO. Welche Anforderungen ein Vertrag dafür erfüllen muss, zeigt die <a href="/de/governance/avv-checkliste/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">AVV-Checkliste für KI-Infrastruktur</a>; die Standort-Frage vertieft <a href="/de/governance/data-residency/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Data Residency</a>.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Mandanteneinwilligung in der Praxis: drei Schritte statt Einzelfall-Chaos</h2>
<p class="text-body-lg text-gosign-text-light">
Die Einwilligungspflicht aus § 62a StBerG und § 50a WPO klingt nach Verwaltungsaufwand - sie ist mit drei Standard-Schritten beherrschbar:
</p>
<div class="space-y-6 mt-8">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">1 - Neumandate: Baustein in der Mandatsvereinbarung</p>
<p class="text-body-lg text-gosign-text-light mt-1">Die Einwilligung wird als eigener, ausdrücklicher Abschnitt in die Mandatsvereinbarung aufgenommen: benannter Dienstleister, Zweck der Verarbeitung, Verarbeitungsort (EU/Deutschland), Hinweis auf die Verschwiegenheitsverpflichtung des Dienstleisters. Keine versteckte AGB-Klausel - ausdrücklich heißt ausdrücklich.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">2 - Bestandsmandate: dokumentierte Nachholung</p>
<p class="text-body-lg text-gosign-text-light mt-1">Für laufende Mandate wird die Einwilligung mit einem kurzen Anschreiben plus Einwilligungserklärung nachgeholt - sinnvoll gebündelt mit der ohnehin fälligen Transparenzinformation nach Art. 13/14 DSGVO. Bis die Einwilligung vorliegt, bleiben die Daten dieses Mandats außerhalb des KI-Workflows.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">3 - Dokumentation: wer, wann, wofür</p>
<p class="text-body-lg text-gosign-text-light mt-1">Die Kanzlei führt nach, welches Mandat für welche Verarbeitungs-Zwecke eingewilligt hat - damit die Frage der Berufsaufsicht oder des Mandanten in Minuten beantwortbar ist, nicht in Tagen. Eine Muster-Mandanteneinwilligung samt Transparenzhinweis ist Bestandteil des Gosign-203er-Vertragskits; es ist frei einsehbar (v0.4, intern mehrstufig rechtsgeprüft); die externe anwaltliche Freigabe steht aus.</p>
</div>
</div>
<p class="text-body text-gosign-text-light mt-8">
Praktischer Hinweis zur Form: Textform (§ 126b BGB) verlangt keine unterschriebene Papierurkunde - eine E-Mail oder ein bestätigtes PDF genügt, solange die Erklärung die verpflichtete Person benennt und dauerhaft abrufbar bleibt. Verpflichtungs- und Einwilligungs-Strecke sind damit vollständig digital abwickelbar.
</p>
<p class="text-body-lg text-gosign-text-light mt-8">
Frei einsehbar vor jeder Registrierung - v0.4, intern mehrstufig rechtsgeprüft; Muster zur anwaltlichen Einzelfall-Anpassung, ohne Gewähr. Die sieben Bausteine:
</p>
<ul class="mt-4 space-y-2 text-body text-gosign-text-light">
<li><a href="/downloads/203-vertragskit/README.md" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Nutzungs-Rahmen und Disclaimer (README)</a></li>
<li><a href="/downloads/203-vertragskit/zusatzvereinbarung-203-abs4.md" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Verschwiegenheits-Zusatzvereinbarung (§ 203 Abs. 4 StGB)</a></li>
<li><a href="/downloads/203-vertragskit/avv-baustein-gosign.md" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">AVV-Baustein mit Gosign-Selbstverpflichtung (Art. 28 DSGVO)</a></li>
<li><a href="/downloads/203-vertragskit/subprozessoren.md" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Subprozessoren-Liste</a></li>
<li><a href="/downloads/203-vertragskit/tia-scc-baustein.md" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Drittlandtransfer-Baustein (TIA/SCC, Art. 44 ff. DSGVO)</a></li>
<li><a href="/downloads/203-vertragskit/dsfa-vorlage.md" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">DSFA-Vorlage (Art. 35 DSGVO)</a></li>
<li><a href="/downloads/203-vertragskit/retention-matrix-einwilligung-transparenz.md" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Retention-Matrix, Muster-Einwilligungen, Transparenzhinweis</a></li>
</ul>
<p class="text-body text-gosign-text-light mt-4">
Alle Muster sind Vorlagen zur anwaltlichen Einzelfall-Anpassung, ohne Gewähr - sie ersetzen keine Rechtsberatung und keine eigene berufsrechtliche Prüfung.
</p>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Quellen</h2>
<div class="space-y-2 text-body text-gosign-text-light">
<p>§ 62a StBerG (Inanspruchnahme von Dienstleistungen): <a href="https://www.gesetze-im-internet.de/stberg/__62a.html" class="text-gosign-accent-text hover:underline" rel="noopener">gesetze-im-internet.de/stberg/__62a.html</a> (Abruf 2026-07-22)</p>
<p>§ 50a WPO (Inanspruchnahme von Dienstleistungen): <a href="https://www.gesetze-im-internet.de/wipro/__50a.html" class="text-gosign-accent-text hover:underline" rel="noopener">gesetze-im-internet.de/wipro/__50a.html</a> (Abruf 2026-07-22)</p>
<p>§ 203 StGB (Verletzung von Privatgeheimnissen): <a href="https://www.gesetze-im-internet.de/stgb/__203.html" class="text-gosign-accent-text hover:underline" rel="noopener">gesetze-im-internet.de/stgb/__203.html</a> (Abruf 2026-07-22)</p>
<p>BStBK-FAQ zum KI-Einsatz in der Steuerberatung (Stand 01/2026): <a href="https://www.bstbk.de/downloads/bstbk/digitalisierung/BStBK_FAQ-KI_end.pdf" class="text-gosign-accent-text hover:underline" rel="noopener">bstbk.de (PDF)</a> (Abruf 2026-07-22)</p>
<p>DATEV-Copilot kostenlos für Mitglieder seit 02/2026: <a href="https://tax-tech.de/ki-tools-fuer-steuerkanzleien-2026/" class="text-gosign-accent-text hover:underline" rel="noopener">tax-tech.de</a> (Abruf 2026-07-22)</p>
<p>DATEV-Verschwiegenheitserklärung (mitgliederweite Vereinbarung nach § 203 StGB): <a href="https://www.datev.de/web/de/m/ueber-datev/datenschutz/vereinbarung-zur-verschwiegenheitserklaerung/" class="text-gosign-accent-text hover:underline" rel="noopener">datev.de</a> (Abruf 2026-07-22)</p>
<p>WPK-Linie („nur geschlossene Systeme"), Zusammenfassung der Kammer-Positionen: <a href="https://shop.hassenpflug.online/en/blogs/news/ki-203-stgb-und-microsoft-fur-steuerberater-und-rechtsanwalte-was-brak-bstbk-und-wpk-tatsachlich-sagen" class="text-gosign-accent-text hover:underline" rel="noopener">hassenpflug.online</a> (Abruf 2026-07-22)</p>
<p>unser Betreiber in deutschen Rechenzentren AI Foundation Services / LLM Hub (DeepSeek R1 managed, Berufsgeheimnisträger-Bezug): <a href="https://www.t-cloud-public.com/en/solutions/use-cases/artificial-intelligence/ai-foundation-services" class="text-gosign-accent-text hover:underline" rel="noopener">t-cloud-public.com</a> (Abruf 2026-07-22)</p>
</div>
<p class="text-body text-gosign-text-light mt-8">
Diese Seite ist eine architektur- und governance-fachliche Einordnung, keine Rechtsberatung. Die berufsrechtliche Prüfung des Einzelfalls obliegt dem Berufsträger bzw. seinen rechtlichen Beratern. Die strafrechtliche Einordnung automatisierter KI-Verarbeitung ist gerichtlich nicht abschließend geklärt.
</p>
</div>
</section>

--- KI mit § 203-Vertrag im Vergleich: Wer hat das Artefakt - und wer den Claim? ---
> Anbieter-Vergleich für KI unter § 203 StGB: Welche Anbieter haben ein belastbares Vertragsartefakt, welche einen Claim ohne auffindbares Dokument. Fakten-Tabelle mit Quellen, Abrufdatum und Prüfkriterien - eigene Zeile als Anbieter-Selbstauskunft.

<!-- Einordnung -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Warum dieser Vergleich nach dem Vertragsartefakt sortiert</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
„§ 203-konform“ ist als bloßes Etikett nicht nachprüfbar - es gibt kein Zertifikat und keine Behörde, die dieses Etikett vergibt. Nachprüfbar ist ein Dokument: die Verschwiegenheitsverpflichtung nach § 203 Abs. 4 Satz 2 Nr. 1 StGB als eigenständige Urkunde mit strafrechtlicher Belehrung, der KI-taugliche Auftragsverarbeitungsvertrag, die benannte Subunternehmer-Kette, der Drittland-Baustein. Die vollständige Prüflogik mit allen acht Gliedern beschreibt <a href="/de/berufsgeheimnistraeger/203er-kette/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">die 203er-Kette</a>.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
In unserem eigenen Markt-Screening vom 22.07.2026 - eine Eigenerhebung; Kriterien und Trefferliste legen wir im Gespräch offen - hatten rund 8 von rund 25 geprüften Anbietern ein Vertragsartefakt, das über einen Marketing-Claim hinausgeht. Die Kombination aus frei einsehbarem Dokument vor jeder Registrierung, eigenständiger Abs.-4-Urkunde und anwaltlicher Freigabe war zum Stichtag unbesetzt. Genau deshalb sortiert dieser Vergleich nicht nach Funktionen, sondern nach dem Artefakt.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Der Maßstab dahinter: ein nach der DAV-Linie (SN 32/2025) geprüfter Bezugsweg - gerichtlich nicht abschließend geklärt; die konservativere BRAK-Linie, nach der bereits die Möglichkeit der Kenntnisnahme kritisch ist, gehört transparent dazu. Rechtslage, Bezugswege und Lösungs-Treppe im Überblick: <a href="/de/berufsgeheimnistraeger/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">KI für Berufsgeheimnisträger (§ 203)</a>.
</p>
</div>
</div>
</section>

<!-- Prüfkriterien -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Woran Sie ein belastbares Vertragsartefakt erkennen</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Vier Kriterien trennen ein belastbares Artefakt von einem Etikett - sie sind zugleich die Sortierlogik der Tabelle weiter unten:
</p>
</div>
<div class="max-w-narrow space-y-6 mt-8">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">1</p>
<p class="text-body-lg text-gosign-text-light mt-1"><strong>Frei einsehbar vor jeder Registrierung.</strong> Das Dokument liegt offen, bevor Sie Kontaktdaten hinterlassen oder einen Vertrag zeichnen. Ein Anbieter, der das Abs.-4-Dokument erst nach Vertragsschluss zeigt, dreht die Prüfreihenfolge um: Sie sollen kaufen, bevor Sie prüfen können.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">2</p>
<p class="text-body-lg text-gosign-text-light mt-1"><strong>Eigenständige Abs.-4-Urkunde.</strong> Die Verschwiegenheitsverpflichtung nach § 203 Abs. 4 Satz 2 Nr. 1 StGB ist ein eigenes Dokument mit strafrechtlicher Belehrung - keine Klausel im AVV und kein Absatz im Marketing-Text. Der AVV bleibt daneben Pflicht (Art. 28 DSGVO); die generischen Prüffragen dazu: <a href="/de/governance/avv-checkliste/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">AVV-Checkliste für KI-Infrastruktur</a>.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">3</p>
<p class="text-body-lg text-gosign-text-light mt-1"><strong>Anwaltliche Freigabe.</strong> Ein Vertragsmuster ohne externe anwaltliche Prüfung ist eine ungeprüfte Zusicherung. Belastbar wird es durch die dokumentierte Prüfung einer externen Kanzlei - und durch den Hinweis, dass jedes Muster der anwaltlichen Einzelfall-Anpassung bedarf.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">4</p>
<p class="text-body-lg text-gosign-text-light mt-1"><strong>Kettenverpflichtung.</strong> Hinter jedem Anbieter stehen weitere Glieder: Rechenzentrum, Modell-Betreiber, Support. Ein belastbares Artefakt benennt diese Subunternehmer und verpflichtet sie gleichwertig - den Anbieter selbst eingeschlossen.</p>
</div>
</div>
<div class="max-w-narrow">
<p class="text-body-lg text-gosign-text-light mt-8">
Diese vier Kriterien sind auch der Maßstab für unsere eigene Zeile in Gruppe 3. Stand heute: Die freie Einsehbarkeit ist erfüllt - unser Vertragskit ist als v0.4 vor jeder Registrierung frei einsehbar (intern mehrstufig rechtsgeprüft); die anwaltliche Freigabe ist weiterhin ausstehend und wird transparent ausgewiesen.
</p>
</div>
</div>
</section>

<!-- Vergleichstabelle -->
<section id="vergleichstabelle" class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Die Vergleichstabelle: drei Gruppen, ein Stichtag</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Alle Angaben über fremde Anbieter sind deren öffentliche Eigenangaben aus den zitierten Fundstellen, abgerufen am 22.07.2026 im Rahmen unseres eigenen Markt-Screenings (Eigenerhebung, Auswahl). Die Fundstellen stehen bewusst als Klartext in der Tabelle statt als Link - dieser Vergleich soll belegen, nicht weiterleiten. Preise nennt die Tabelle nicht, Qualitätsurteile enthält sie nicht.
</p>
<h3 class="text-h3 font-bold text-gosign-dark mt-8">Gruppe 1 - öffentlich belegtes oder benanntes Vertragsartefakt (Auswahl)</h3>
</div>
<div class="mt-6 overflow-x-auto">
<table class="w-full text-left text-small border-collapse">
<thead>
<tr>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Anbieter</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Zielgruppe</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Artefakt-Typ (Eigenangabe)</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Hosting/Modelle (Eigenangabe)</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Quelle + Abrufdatum</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Logicc</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Anwälte, Ärzte, Steuerberater</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Digitale § 203-Zusatzvereinbarung, in-App signierbar - im Secure+-Tarif</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">EU-gehostete Modelle (Azure Frankfurt, GCP/AWS EU); Training-Ausschluss vertraglich</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">logicc.com/en/branchen/lawyers - Abruf 2026-07-22</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Beck-Noxtua (Noxtua / C.H. Beck)</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Rechtsanwälte, Unternehmensjuristen</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Eigenangabe: erfüllt DS-GVO, § 43a und § 43e BRAO sowie § 203 StGB; ein konkret bezeichnetes Vertragsdokument nennt die Website nicht</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Eigenes Legal-Modell laut Anbieter (Architektur nicht offengelegt); Verarbeitung bei IONOS und T Cloud (Deutsche Telekom), On-Premises-Variante angeboten</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">noxtua.com und beck-noxtua.de - Abruf 2026-07-25</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">meinGPT (SelectCode)</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Anwälte, Steuerberater, Wirtschaftsprüfer, Ärzte, Notare</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Eigenständiger, unterzeichenbarer Vertrag außerhalb der AGB: Verpflichtung als mitwirkende Person nach § 203 Abs. 3 Satz 2 StGB</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Hosting DE/EU; konkrete Modelle werden auf der Website nicht benannt</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">meingpt.com, Seite für Berufsgeheimnisträger - Abruf 2026-07-25</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Taxy.io (mit Otto Schmidt Answers)</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Steuerberater, Anwälte</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Öffentlich einsehbarer AVV, Abschnitt 7: Verschwiegenheit über Berufsgeheimnisse</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Azure Deutschland, ISO 27001</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">legaltechverband.de/toolfinder/otto-schmidt-answers/ - Abruf 2026-07-22</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">ASCADI (Visionary Data)</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Steuerkanzleien</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">§ 203-Abs.-4-Klausel inklusive strafrechtlicher Belehrung als AVV-Standardbestandteil</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Hosting Deutschland, ISO 27001</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">visionarydata.de/ki-steuerberater - Abruf 2026-07-22</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">DATEV</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Steuerberater (Mitglieder)</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Mitgliederweite Verschwiegenheitserklärung nach § 203, über den AVV hinausgehend</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Azure OpenAI, temporäre Verarbeitung, kein Training</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">datev.de/web/de/m/ueber-datev/datenschutz/vereinbarung-zur-verschwiegenheitserklaerung/ - Abruf 2026-07-22</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">T-Systems / Open Telekom Cloud</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">§ 203-Berufsgruppen (Infrastruktur)</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Standardisierte § 203-Verschwiegenheitsvereinbarung seit 2021</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Deutsche Rechenzentren Magdeburg/Biere; DeepSeek R1, Llama 3.3, Mistral Small 3 managed</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">t-cloud-public.com/en/solutions/use-cases/artificial-intelligence/ai-foundation-services - Abruf 2026-07-22</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">anymize.ai</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Kanzleien, Rechtsabteilungen</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">§ 43e Abs. 3 BRAO-Verpflichtung inklusive § 203-Hinweis plus AVV, online in Textform abschließbar</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">PII-Anonymisierung vor jedem Request</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">https://anymize.ai/loesungen/rechtsbranche - Abruf 2026-07-22</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Tara KI / notara</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Notare</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Verschwiegenheitsvereinbarung; Bezug auf BNotK-Rundschreiben 1/2026</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Deutsches Hosting</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">notara.de/notara-ki/ - Abruf 2026-07-22</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Noirdoc</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">§ 203-Berufsgruppen (API)</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">§ 203-Schweigepflichtvereinbarung direkt mit Noirdoc, auf Anfrage</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">EU/DE-Hosting-Mix; GPT-, Llama-, Mistral-, Qwen- und Apertus-Modelle</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">noirdoc.de - Abruf 2026-07-22</td></tr>
</tbody>
</table>
</div>
<div class="max-w-narrow">
<h3 class="text-h3 font-bold text-gosign-dark mt-10">Gruppe 2 - Claim ohne zum Abrufdatum öffentlich auffindbares Vertragsdokument (Auswahl)</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
„Kein auffindbares Dokument“ ist eine Beobachtung zum Stichtag, kein Urteil über den Anbieter - manche stellen Unterlagen erst im Vertriebsprozess bereit (siehe häufige Fragen).
</p>
</div>
<div class="mt-6 overflow-x-auto">
<table class="w-full text-left text-small border-collapse">
<thead>
<tr>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Anbieter</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Aussage (Eigenangabe)</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Vertragsdokument zum Abrufdatum</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Quelle + Abrufdatum</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Libra</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">„§ 203-Konformität“ im Trust Center</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">öffentlich nicht auffindbar</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">libratech.ai - Abruf 2026-07-22</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Lulius</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Claim „§ 203-konform“</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">öffentlich nicht auffindbar</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">lulius.ai - Abruf 2026-07-22</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Nextaim</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">„§ 203-konform ab Tag 1“, OpenAI-kompatible API</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">kein signierbares Dokument sichtbar</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">nextaim.de/llm-hosting-203/ - Abruf 2026-07-22</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">WZ-IT (AI Cube)</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Claim „§ 43e BRAO- und § 203-konform“</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">keine Vereinbarung öffentlich</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">wz-it.com/ki/branchen/anwaltskanzlei/ - Abruf 2026-07-22</td></tr>
</tbody>
</table>
</div>

<div class="max-w-narrow">
<h3 class="text-h3 font-bold text-gosign-dark mt-10">Gruppe 3 - verbreitete Kanzlei-Werkzeuge: welches Modell arbeitet darin?</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Die Werkzeuge, nach denen in Kanzleien am häufigsten gesucht wird, sind keine Modelle, sondern Oberflächen über fremden Modellen. Für die § 203-Frage ist genau das entscheidend: Verantwortlich für die Verschwiegenheit ist die gesamte Kette bis zu dem Modell, das den Text tatsächlich verarbeitet - und wer diese Kette prüfen will, muss zuerst wissen, wer am Ende steht. Die meisten Anbieter legen das nicht offen. Diese Übersicht sagt, was zum Abrufdatum belegt ist, und benennt die Lücken als Lücken.
</p>
<p class="text-body text-gosign-text-light mt-4">
Keiner der hier genannten Anbieter macht auf seiner Website eine ausdrückliche Zusage nach § 203 StGB - andernfalls stünde er in Gruppe 1. Das ist kein Vorwurf: Es heißt, dass die Frage im Vertriebsgespräch zu stellen ist, und diese Übersicht liefert die Frage.
</p>
</div>
<div class="mt-6 overflow-x-auto">
<table class="w-full text-left text-small border-collapse">
<thead>
<tr>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Werkzeug</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Zielgruppe</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Welches Modell verarbeitet den Text?</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Was daraus für die 203er-Kette folgt</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Quelle + Abrufdatum</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Harvey</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Großkanzleien, Rechtsabteilungen</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">OpenAI-, Google- und Anthropic-Modelle, angebunden über AWS Bedrock und Google Vertex (Anbieter-Eigenangabe)</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Die Kette reicht bis zu drei Modellanbietern über zwei US-Plattformen. Für jede dieser Ketten ist die Verschwiegenheitsverpflichtung gesondert zu klären; eine § 203-Aussage macht der Anbieter nicht.</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">harvey.ai/blog/expanding-harveys-model-offerings - Abruf 2026-07-25</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Legora</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Rechtsanwälte</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Anthropic Claude (belegt über die Kundenreferenz des Modellanbieters)</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Einzelnes Frontier-Modell, Verarbeitungsregion für Deutschland nicht offengelegt - die Auslandsschranke ist damit nicht beurteilbar.</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">claude.com/customers/legora - Abruf 2026-07-25</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">juris KI-Suite</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Anwaltschaft, Justiz, Verwaltung</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Nicht offengelegt. Architektur laut Anbieter: Antworten ausschließlich aus dem juris-Datenbestand mit Fundstellen-Nachweis</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Ohne benanntes Modell lässt sich die Kette nicht bis zum Ende prüfen. Die Frage nach dem Modell und seiner Verpflichtung gehört ins Vertriebsgespräch.</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">juris.de/jportal/nav/lp/ki/ki-suite.jsp - Abruf 2026-07-25</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">beck-chat (C.H. Beck)</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Rechtsanwälte, Steuerrechtler</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Nicht offengelegt. Drittquellen nennen Azure OpenAI - vom Anbieter nicht bestätigt, deshalb hier nicht als Tatsache geführt</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Wie bei juris: Solange das Modell nicht benannt ist, ist die Kette nicht prüfbar.</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">extrajournal.net und jurios.de - Abruf 2026-07-25</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">RA-MICRO JURA KI Assistent</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Rechtsanwälte</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Kein eigenes Modell: Die Anwendung anonymisiert lokal, sendet an das vom Nutzer abonnierte Fremdmodell und setzt die Antwort zurück</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Der interessanteste Sonderfall: Hier wird § 203 technisch statt vertraglich adressiert - was anonymisiert übermittelt wird, ist kein Geheimnis mehr. Die Güte der Anonymisierung wird damit zur tragenden Frage.</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">ra-micro.de/artikel/news/jura-ki-assistent.html - Abruf 2026-07-25</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Wolters Kluwer (Legisway, AnNoText, ADDISON)</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Anwälte, Steuerberater</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">OpenAI-Modelle, geroutet über die konzerneigene KI-Plattform (Anbieter-Eigenangabe)</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">US-Modellanbieter in der Kette; die Verschwiegenheitsverpflichtung bis zum Modell ist nicht ausgewiesen.</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">wolterskluwer.com - Abruf 2026-07-25</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Haufe CoPilot Tax</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Steuerberater</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Nicht offengelegt</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Keine öffentliche Angabe zu Modell, Region oder Verschwiegenheitskette.</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">haufe.de/steuern/taxulting - Abruf 2026-07-25</td></tr>
</tbody>
</table>
</div>

<div class="max-w-narrow">
<h3 class="text-h3 font-bold text-gosign-dark mt-10">Gruppe 3 - die eigene Zeile (Anbieter-Selbstauskunft)</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Für die eigene Zeile gilt derselbe Maßstab - gekennzeichnet als Selbstauskunft, weil wir uns nicht selbst „belegen“ können: Prüfen Sie uns so, wie Sie jeden anderen Anbieter prüfen würden.
</p>
</div>
<div class="mt-6 overflow-x-auto">
<table class="w-full text-left text-small border-collapse">
<thead>
<tr>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Anbieter</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Zielgruppe</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Artefakt-Typ</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Bezugswege</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Status</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Gosign GmbH (Anbieter-Selbstauskunft)</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Anwälte, Steuerberater/WP, Notariate, PKV, Kliniken</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">203er-Vertragskit: eigenständige Abs.-4-Zusatzvereinbarung, KI-AVV mit Gosign-Selbstverpflichtung, Subprozessoren-Dokumentation, TIA/SCC-, DSFA- und Retention-/Einwilligungs-Baustein</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Vier geprüfte Bezugswege (EU-Inferenz offener Modelle, deutsche Rechenzentren, Azure EU Data Zones, Google-EU) mit Redaktions-Gateway als Standard-Architektur</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Anbieter-Selbstauskunft, Stand 25.07.2026; Kit v0.4 frei einsehbar vor jeder Registrierung; anwaltliche Freigabe ausstehend</td></tr>
</tbody>
</table>
</div>
<div class="max-w-narrow">
<p class="text-small text-gosign-text-light mt-6">
Fremdanbieter-Angaben sind deren öffentliche Selbstdarstellung zum Abrufdatum - eine Momentaufnahme, keine dauerhafte Zusicherung und kein Qualitätsurteil. Irrtum vorbehalten: Ist eine Angabe unzutreffend oder überholt, korrigieren wir sie nach Hinweis.
</p>
</div>
</div>
</section>

<!-- Wie man die Tabelle benutzt -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Wie Sie die Tabelle benutzen</h2>
</div>
<div class="max-w-narrow space-y-6 mt-8">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">1</p>
<p class="text-body-lg text-gosign-text-light mt-1"><strong>Artefakt anfordern, bevor über Funktionen gesprochen wird.</strong> Ein Anbieter, der das Abs.-4-Dokument erst nach Vertragsschluss zeigt, dreht die Prüfreihenfolge um - bestehen Sie auf dem Dokument als erstem Schritt.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">2</p>
<p class="text-body-lg text-gosign-text-light mt-1"><strong>Artefakt gegen die acht Glieder halten.</strong> Ein Dokument allein deckt Glied 2 - <a href="/de/berufsgeheimnistraeger/203er-kette/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">die 203er-Kette</a> hat sieben weitere, vom AVV bis zur Mandanteneinwilligung.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">3</p>
<p class="text-body-lg text-gosign-text-light mt-1"><strong>Bezugsweg erfragen.</strong> Hinter jedem Produkt steht ein Modell-Bezugsweg (Azure, Google, EU-Inferenz offener Modelle, deutsche Rechenzentren) mit eigenem Status - der 203er-Status ist eine Eigenschaft der Kombination aus Modell und Bezugsweg, nie des Modells allein. Die vier geprüften Wege: <a href="/de/berufsgeheimnistraeger/#bezugswege" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Bezugswege im Überblick</a>; die Grenzen des Azure-Wegs im Detail: <a href="/de/berufsgeheimnistraeger/azure-engpass/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Der Azure-Engpass</a>.</p>
</div>
</div>
<div class="max-w-narrow">
<p class="text-body-lg text-gosign-text-light mt-8">
Und wenn die Ausgangsfrage in Ihrer Kanzlei schlicht „Dürfen wir ChatGPT nutzen?“ lautet, beginnt die Antwort eine Ebene früher - beim Unterschied zwischen Consumer-Zugang und Bezugsweg: <a href="/de/berufsgeheimnistraeger/chatgpt-alternative-kanzleien/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">ChatGPT-Alternative für Kanzleien</a>.
</p>
</div>
</div>
</section>

<!-- Vertiefung -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-2">Vertiefung für Ihre Berufsgruppe</h2>
<p class="text-body text-gosign-text-light mb-8 max-w-narrow">
Die DAV-Linie gilt anwaltlich - Steuerberater und Wirtschaftsprüfer haben eigene, teils konservativere Regeln. Jeder Spoke mappt seine eigene Rechtsgrundlage.
</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/de/berufsgeheimnistraeger/anwaelte/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Rechtsanwälte</p>
<p class="text-body font-semibold text-gosign-dark">§ 43e BRAO, BRAK-Leitfaden, DAV-Linie - und welche Aufgaben KI in der Kanzlei heute übernimmt</p>
</a>
<a href="/de/berufsgeheimnistraeger/steuerberater-wp/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Steuerberater / Wirtschaftsprüfer</p>
<p class="text-body font-semibold text-gosign-dark">§ 62a StBerG, § 50a WPO, BStBK-FAQ - inklusive der sachlichen DATEV-Abgrenzung</p>
</a>
<a href="/de/berufsgeheimnistraeger/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Überblick</p>
<p class="text-body font-semibold text-gosign-dark">KI für Berufsgeheimnisträger (§ 203): Rechtslage, vier Bezugswege und die Lösungs-Treppe</p>
</a>
</div>
<div class="max-w-narrow">
<p class="text-body-lg text-gosign-text-light mt-8">
Für Notariate (§ 18 BNotO, BNotK-Rundschreiben 1/2026) und private Krankenversicherer gelten eigene Rahmen - beide mappt je ein eigener Spoke: <a href="/de/berufsgeheimnistraeger/notare/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">KI im Notariat</a> und <a href="/de/berufsgeheimnistraeger/pkv/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">KI für private Krankenversicherer</a>.
</p>
</div>
</div>
</section>

--- 203er-Vertragskit: sieben Muster zum Herunterladen ---
> Das 203er-Vertragskit v0.4 der Gosign GmbH: Verschwiegenheits-Zusatzvereinbarung nach § 203 Abs. 4 StGB, AVV-Baustein, Subprozessoren-Liste, Drittlandtransfer, DSFA, Retention-Matrix und Muster-Mandanteneinwilligung - frei einsehbar ohne Registrierung.

<!-- Einordnung -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Warum das Kit offen liegt</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Wer als Berufsgeheimnisträger einen KI-Bezugsweg prüft, steht vor einem Beschaffungsproblem: Die entscheidenden Unterlagen bekommt man in der Regel erst, wenn man schon im Vertriebsprozess steckt. Genau umgekehrt ist es hier. Die sieben Muster stehen offen, damit die Prüfung vor dem Gespräch stattfinden kann - und damit sie auch gegen andere Anbieter geführt werden kann.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Inhaltlich decken die Bausteine die Glieder ab, die die <a href="/de/berufsgeheimnistraeger/203er-kette/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">203er-Kette</a> beschreibt: die strafrechtliche Verpflichtung nach § 203 Abs. 4 StGB, den datenschutzrechtlichen Auftragsverarbeitungsvertrag, die Weitergabe der Pflicht an Subunternehmer, den Drittlandtransfer, die Aufbewahrung und die Einwilligung der Mandantschaft. Welches Modell über welchen Bezugsweg abgesichert ist, führt die <a href="/de/ki-modelle-berufsgeheimnistraeger/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Modell-Übersicht</a> im Einzelnen aus.
</p>
<p class="text-small text-gosign-text-light mt-4">
Stand v0.4 (25.07.2026), intern mehrstufig rechtsgeprüft (zwei Audits 07/2026). Muster zur anwaltlichen Einzelfall-Anpassung, ohne Gewähr, ersetzt keine Rechtsberatung. Die externe anwaltliche Freigabe steht aus.
</p>
</div>
</div>
</section>

<!-- Bausteine -->
<section id="bausteine" class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Die sieben Bausteine</h2>

<h3 class="text-h2 font-bold text-gosign-dark mt-8">1. Verschwiegenheits-Zusatzvereinbarung nach § 203 Abs. 4 StGB</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Das Kernstück: die eigenständige Verpflichtung der mitwirkenden Person zur Geheimhaltung, in Textform und mit Belehrung über die eigene Strafbarkeit nach § 203 Abs. 4 Satz 1 StGB. Genau das Dokument, das ein Auftragsverarbeitungsvertrag nicht ersetzt.
<br /><a href="/downloads/203-vertragskit/zusatzvereinbarung-203-abs4.md" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Zusatzvereinbarung herunterladen</a>
</p>

<h3 class="text-h2 font-bold text-gosign-dark mt-8">2. AVV-Baustein nach Art. 28 DSGVO</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Der datenschutzrechtliche Teil, mit Gosign-Selbstverpflichtung, den Regeln für Gateway und Mapping sowie den Zusagen zur Nicht-Speicherung beim Modell-Anbieter.
<br /><a href="/downloads/203-vertragskit/avv-baustein-gosign.md" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">AVV-Baustein herunterladen</a>
</p>

<h3 class="text-h2 font-bold text-gosign-dark mt-8">3. Subprozessoren-Liste</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Wer außer uns an der Verarbeitung beteiligt ist, mit Status je Beteiligtem und der Mechanik, wie Änderungen mitgeteilt werden. Das ist das Glied, an dem Anbieter-Ketten in der Praxis am häufigsten reißen.
<br /><a href="/downloads/203-vertragskit/subprozessoren.md" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Subprozessoren-Liste herunterladen</a>
</p>

<h3 class="text-h2 font-bold text-gosign-dark mt-8">4. Drittlandtransfer-Baustein (Art. 44 ff. DSGVO)</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Das Gerüst für das Transfer Impact Assessment, der Stand zum Data Privacy Framework und die ergänzenden Maßnahmen. Relevant überall dort, wo ein Konzern mit US-Bezug in der Kette bleibt.
<br /><a href="/downloads/203-vertragskit/tia-scc-baustein.md" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Drittlandtransfer-Baustein herunterladen</a>
</p>

<h3 class="text-h2 font-bold text-gosign-dark mt-8">5. DSFA-Vorlage (Art. 35 DSGVO)</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Die Datenschutz-Folgenabschätzung als Vorlage, mit den Zulieferbausteinen, die ein Auftragsverarbeiter nach Art. 28 Abs. 3 lit. f beizusteuern hat.
<br /><a href="/downloads/203-vertragskit/dsfa-vorlage.md" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">DSFA-Vorlage herunterladen</a>
</p>

<h3 class="text-h2 font-bold text-gosign-dark mt-8">6. Retention-Matrix, Mandanteneinwilligung und Transparenzhinweis</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Aufbewahrungs- und Löschfristen als Matrix, dazu die Muster-Einwilligung der Mandantschaft (§ 43e Abs. 5 BRAO, § 62a Abs. 5 StBerG, § 50a Abs. 5 WPO), die Beteiligten-Einwilligung für Notare (§ 26a Abs. 4 BNotO) und der Transparenzhinweis nach Art. 13 und 14 DSGVO.
<br /><a href="/downloads/203-vertragskit/retention-matrix-einwilligung-transparenz.md" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Retention-Matrix herunterladen</a>
</p>

<h3 class="text-h2 font-bold text-gosign-dark mt-8">7. Übersicht des Kits</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Die Kurzbeschreibung aller Bausteine samt Versionsstand in einer Datei - der schnellste Weg, sich einen Überblick zu verschaffen.
<br /><a href="/downloads/203-vertragskit/README.md" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Übersicht herunterladen</a>
</p>
</div>
</div>
</section>

<!-- Weiterführend -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Wenn Sie den Bezugsweg nicht selbst bauen wollen</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Das Kit beschreibt, wie die Kette aussehen muss. Sie selbst aufzubauen - Anbieter auswählen, Verträge verhandeln, Betrieb absichern - ist Projektarbeit. Wer sie nicht führen will, bekommt sie als fertiges Produkt: <a href="https://veryai.de/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">veryAI</a>, eine Kanzlei-Instanz auf einem eigenen Server in Deutschland, in der die abgesicherten Modelle bereitstehen und die Verträge bereits geschlossen sind. Anbieter ist die Gosign GmbH.
</p>
</div>
</div>
</section>

--- Datenschutzerklärung - Gosign GmbH ---
> Datenschutzerklärung der Gosign GmbH. Cookielose Website ohne client-seitige Tracker; server-seitige, cookielose Reichweiten- und Conversion-Messung.

<h1>Datenschutzerklärung</h1>

<h2>1. Verantwortlicher</h2>
<p>
Gosign GmbH<br/>
Hallerstraße 8<br/>
20146 Hamburg
</p>
<p>E-Mail: web26 [at] gosign.de</p>

<h3>Datenschutzbeauftragter</h3>
<p>
Ein Datenschutzbeauftragter ist derzeit nicht bestellt. Weniger als 20 Beschäftigte sind ständig mit der automatisierten Verarbeitung personenbezogener Daten befasst (§&nbsp;38 Abs.&nbsp;1 BDSG). Bei Fragen zum Datenschutz wenden Sie sich bitte an die oben genannte Adresse.
</p>

<h2>2. Überblick</h2>
<p>
Diese Website setzt keine Cookies. Weder First-Party noch Third-Party. Es werden keine client-seitigen Tracker Dritter geladen - kein Google Analytics, kein Matomo, kein Facebook Pixel, kein LinkedIn Insight Tag und kein Google Tag Manager. Zur Reichweiten- und Conversion-Messung setzen wir ein eigenes, cookieloses und server-seitiges System ein (siehe Abschnitt&nbsp;4).
</p>
<p>
Es ist kein Cookie-Banner erforderlich, da keine Cookies oder vergleichbaren Technologien in Ihrem Endgerät gespeichert oder ausgelesen werden (§&nbsp;25 TTDSG).
</p>

<h2>3. Hosting und Content Delivery</h2>
<p>
Diese Website wird über Cloudflare Pages bereitgestellt. Cloudflare fungiert als Auftragsverarbeiter gemäß Art.&nbsp;28 DSGVO. Ein Data Processing Addendum (DPA) mit Standard Contractual Clauses (SCCs) liegt vor.
</p>
<p>
Bei der Auslieferung von Webseiten verarbeitet Cloudflare technisch bedingt die IP-Adresse des anfragenden Geräts. Diese Verarbeitung kann je nach Dienst auch außerhalb der EU stattfinden und ist über das EU-US Data Privacy Framework sowie DPA/SCCs abgesichert.
</p>
<p>
Rechtsgrundlage: Art.&nbsp;6 Abs.&nbsp;1 lit.&nbsp;f DSGVO (berechtigtes Interesse an der sicheren und performanten Bereitstellung der Website).
</p>

<h2>4. Reichweiten- und Conversion-Messung</h2>
<p>
Zur Analyse der Websitenutzung und der Wirksamkeit unserer Werbung setzen wir ein eigenes, cookieloses Mess-System ein (intern „Lyftyfy"), das von der Gosign GmbH betrieben wird. Es werden keine Cookies gesetzt und keine client-seitigen Tracker Dritter geladen (kein Google Analytics, kein Google Tag Manager, kein Facebook Pixel, kein LinkedIn Insight Tag). Die Messung erfolgt server-seitig und ohne dauerhafte Wiedererkennung Ihres Geräts:
</p>
<ul>
<li>Es wird kein dauerhafter Identifier auf Ihrem Gerät gespeichert. Zur Zusammenfassung der Aufrufe eines Tages wird ein täglich wechselnder Sitzungs-Hash aus IP-Adresse, Browserkennung und Datum gebildet; die IP-Adresse selbst wird nicht gespeichert.</li>
<li>Erhoben werden Seitenaufrufe, Scrolltiefe, Verweildauer, Klicks sowie Formular- und Conversion-Ereignisse - in aggregierter, pseudonymer Form.</li>
</ul>
<p>
Rechtsgrundlage: Art.&nbsp;6 Abs.&nbsp;1 lit.&nbsp;f DSGVO (berechtigtes Interesse an der Analyse der Websitenutzung und der Wirksamkeit unserer Werbung).
</p>

<h3>Conversion-Messung für Werbekampagnen (Google Ads)</h3>
<p>
Wenn Sie über eine Google-Ads-Anzeige auf unsere Website gelangen, enthält die aufgerufene Adresse einen Klick-Parameter (gclid). Schließen Sie anschließend eine Aktion ab (z.&nbsp;B. eine Formularanfrage), übermitteln wir server-seitig ein Conversion-Ereignis an Google, um die Wirksamkeit unserer Kampagnen zu messen. Dabei werden der Klick-Parameter, ein kryptografisch gehashter (nicht im Klartext lesbarer) Wert Ihrer E-Mail-Adresse bzw. Telefonnummer sowie der Conversion-Wert übertragen. Es wird kein Cookie und kein Werbe-Tag in Ihrem Browser gesetzt. Empfänger ist Google Ireland Ltd. bzw. Google LLC (USA); die Übermittlung ist über den Vertrag zur Auftragsverarbeitung (Art.&nbsp;28 DSGVO), das EU-US Data Privacy Framework und Standardvertragsklauseln abgesichert (siehe Abschnitt „Verträge zur Auftragsverarbeitung").
</p>
<p>
Rechtsgrundlage: Art.&nbsp;6 Abs.&nbsp;1 lit.&nbsp;f DSGVO (berechtigtes Interesse an der Messung und Optimierung unserer Werbung).
</p>
<p>
Sie können dieser Messung jederzeit mit Wirkung für die Zukunft widersprechen (Art.&nbsp;21 DSGVO). Eine formlose Nachricht an die unter „Verantwortlicher" genannte Adresse genügt; wir stellen die Verarbeitung dann ein.
</p>

<h2>5. Kontaktformular und E-Mail-Kontakt</h2>
<p>
Wenn Sie uns per Kontaktformular oder E-Mail Anfragen zukommen lassen, werden Ihre Angaben (z.&nbsp;B. Name, E-Mail-Adresse, Nachrichtentext) zwecks Bearbeitung der Anfrage und für den Fall von Anschlussfragen bei uns verarbeitet. Die Verarbeitung dieser Daten erfolgt auf Grundlage von Art.&nbsp;6 Abs.&nbsp;1 lit.&nbsp;b DSGVO, sofern Ihre Anfrage mit der Erfüllung eines Vertrags zusammenhängt oder zur Durchführung vorvertraglicher Maßnahmen erforderlich ist. In allen übrigen Fällen beruht die Verarbeitung auf unserem berechtigten Interesse an der effektiven Bearbeitung der an uns gerichteten Anfragen (Art.&nbsp;6 Abs.&nbsp;1 lit.&nbsp;f DSGVO).
</p>

<h3>Technische Abwicklung über Cloudflare (ohne Zwischenspeicherung)</h3>
<p>
Um eine sichere und schnelle Übermittlung Ihrer Formulardaten zu gewährleisten, nutzen wir für das Routing die Technologie "Cloudflare Workers" des Anbieters Cloudflare, Inc., 101 Townsend St, San Francisco, CA 94107, USA. Cloudflare fungiert hierbei ausschließlich als technischer Vermittler. Ihre im Formular eingegebenen Daten werden von Cloudflare nicht in einer Datenbank gespeichert, sondern im Arbeitsspeicher verarbeitet und in Echtzeit über eine verschlüsselte Verbindung (TCP Socket) an unseren E-Mail-Server weitergeleitet. Sobald die Daten übergeben wurden, verbleiben sie nicht auf den Servern von Cloudflare.
</p>

<h3>E-Mail-Hosting über Google Workspace (EU-Hosting)</h3>
<p>
Für den Empfang, die Speicherung und den Versand unserer E-Mails nutzen wir den Dienst "Google Workspace" des Anbieters Google Cloud EMEA Limited, 70 Sir John Rogerson's Quay, Dublin 2, Irland. Wir haben Google Workspace so konfiguriert, dass unsere E-Mail-Daten physisch auf Servern innerhalb der Europäischen Union (EU) gespeichert werden.
</p>

<h3>Verträge zur Auftragsverarbeitung (AVV) und Drittlandtransfer</h3>
<p>
Wir haben sowohl mit Cloudflare als auch mit Google einen Vertrag zur Auftragsverarbeitung (AVV) gemäß Art.&nbsp;28 DSGVO geschlossen. Da beide Anbieter Teil von US-Konzernen sind, kann bei Wartungsarbeiten, Routing (Cloudflare) oder Support-Fällen eine theoretische Datenübertragung in die USA nicht zu 100&nbsp;% ausgeschlossen werden. Für diese Fälle stützen sich die Anbieter auf den Angemessenheitsbeschluss der EU-Kommission (EU-US Data Privacy Framework) sowie auf Standardvertragsklauseln, um ein angemessenes Datenschutzniveau zu gewährleisten.
</p>

<h3>Speicherdauer</h3>
<p>
Die von Ihnen im Kontaktformular eingegebenen Daten verbleiben in unserem E-Mail-Postfach, bis Sie uns zur Löschung auffordern, Ihre Einwilligung zur Speicherung widerrufen oder der Zweck für die Datenspeicherung entfällt (z.&nbsp;B. nach abgeschlossener Bearbeitung Ihrer Anfrage). Zwingende gesetzliche Bestimmungen, insbesondere handels- und steuerrechtliche Aufbewahrungsfristen (bis zu 10 Jahre gemäß §&nbsp;257 HGB und §&nbsp;147 AO), bleiben unberührt.
</p>

<h2>6. Newsletter</h2>
<p>
Wenn Sie unseren Newsletter abonnieren, verarbeiten wir Ihre E-Mail-Adresse zum Zweck des regelmäßigen Versands von Informationen zu unseren Leistungen, Fachartikeln und Veranstaltungen.
</p>
<h3>Double-Opt-In-Verfahren</h3>
<p>
Die Anmeldung erfolgt über ein Double-Opt-In-Verfahren: Nach Eingabe Ihrer E-Mail-Adresse erhalten Sie eine Bestätigungsmail mit einem einmaligen Link. Erst nach Klick auf diesen Link wird Ihre Adresse in den Verteiler aufgenommen. Der Bestätigungslink ist 7 Tage gültig.
</p>
<h3>Eingesetzte Dienste</h3>
<p>
Der Newsletter-Versand erfolgt über einen Cloudflare Worker (Anbieter: Cloudflare, Inc., 101 Townsend St, San Francisco, CA 94107, USA). Ihre E-Mail-Adresse wird in Cloudflare KV (Key-Value-Speicher) gespeichert. Wir haben mit Cloudflare einen Vertrag zur Auftragsverarbeitung (AVV) gemäß Art.&nbsp;28 DSGVO geschlossen. Der Versand der E-Mails erfolgt über SMTP (derzeit über einen Drittanbieter-Mailserver).
</p>
<h3>Rechtsgrundlage</h3>
<p>
Art.&nbsp;6 Abs.&nbsp;1 lit.&nbsp;a DSGVO (Einwilligung). Sie können Ihre Einwilligung jederzeit widerrufen, indem Sie sich über den Abmeldelink in jeder Newsletter-E-Mail abmelden oder uns per E-Mail an datenschutz@gosign.de kontaktieren.
</p>
<h3>Speicherdauer</h3>
<p>
Ihre E-Mail-Adresse wird gespeichert, bis Sie sich vom Newsletter abmelden. Nach der Abmeldung wird die Adresse unverzüglich gelöscht, sofern keine gesetzlichen Aufbewahrungspflichten entgegenstehen.
</p>

<h2>7. 203-Readiness-Check</h2>
<p>
Auf unseren deutschsprachigen Seiten bieten wir den 203-Readiness-Check an, einen freiwilligen Selbst-Check für Berufsgeheimnisträger nach §&nbsp;203 StGB zum KI-Einsatz in der eigenen Organisation. Ihre Antworten im Selbst-Check werden weder gespeichert noch übertragen - die Auswertung läuft vollständig in Ihrem Browser, und das Ergebnis erscheint direkt auf der Seite, ohne E-Mail-Eingabe.
</p>
<h3>Ergebnis-Report per E-Mail (optional)</h3>
<p>
Nur wenn Sie freiwillig den ausführlichen Ergebnis-Report per E-Mail anfordern, verarbeiten wir Ihre E-Mail-Adresse, Ihre Berufsgruppe und die für Sie empfohlene Stufe - nicht Ihre Antworten. Die Anforderung wird wie beim Newsletter (Abschnitt&nbsp;6) im Double-Opt-In-Verfahren bestätigt: Sie erhalten eine Bestätigungsmail mit einem einmaligen Link; erst nach Klick auf diesen Link wird der Report zugestellt. Der Versand erfolgt über unseren Versanddienstleister Brevo, mit dem ein Vertrag zur Auftragsverarbeitung (AVV) gemäß Art.&nbsp;28 DSGVO geschlossen wurde.
</p>
<h3>Rechtsgrundlage</h3>
<p>
Art.&nbsp;6 Abs.&nbsp;1 lit.&nbsp;a DSGVO (Einwilligung). Sie können Ihre Einwilligung jederzeit mit Wirkung für die Zukunft widerrufen, z.&nbsp;B. per E-Mail an datenschutz@gosign.de.
</p>
<h3>Speicherdauer</h3>
<p>
Bestätigte Report-Anforderungen werden nach 6 Monaten gelöscht. Unbestätigte Double-Opt-In-Anfragen verfallen automatisch nach 7 Tagen.
</p>

<h2>8. Terminbuchung</h2>
<p>
Für die Terminbuchung nutzen wir Google Calendar Appointment Scheduling (Anbieter: Google Ireland Limited, Gordon House, Barrow Street, Dublin 4, Irland). Wenn Sie auf den Buchungslink klicken, werden Sie auf calendar.google.com weitergeleitet. Auf unserer Website selbst wird durch den Buchungslink kein Script geladen und kein Cookie gesetzt.
</p>
<p>
Bei der Nutzung des Buchungsdienstes werden Ihre Daten (Name, E-Mail-Adresse, gewählter Termin) von Google verarbeitet. Es gelten die <a href="https://policies.google.com/privacy" target="_blank" rel="noopener noreferrer" class="text-gosign-accent-text hover:text-gosign-accent-hover">Datenschutzbestimmungen von Google</a>.
</p>
<p>
Rechtsgrundlage: Art.&nbsp;6 Abs.&nbsp;1 lit.&nbsp;b DSGVO (Durchführung vorvertraglicher Maßnahmen auf Ihre Anfrage hin). Die Buchung eines Beratungstermins dient der Anbahnung einer Geschäftsbeziehung.
</p>

<h2>9. Fonts</h2>
<p>
Alle auf dieser Website verwendeten Schriftarten sind lokal eingebunden (Self-Hosted). Es werden keine externen Font-Dienste (z.&nbsp;B. Google Fonts) geladen. Es findet kein Verbindungsaufbau zu Drittanbietern beim Laden von Schriftarten statt.
</p>

<h2>10. Karten und Videos</h2>
<p>
Diese Website bindet keine externen Karten-Dienste (z.&nbsp;B. Google Maps) und keine externen Video-Dienste (z.&nbsp;B. YouTube) ein. Wo Karten oder Videos dargestellt werden, erfolgt dies über statische Bilder oder selbst gehostete Inhalte.
</p>

<h2>11. Keine weiteren Drittanbieter</h2>
<p>
Diese Website lädt keine Ressourcen von Drittanbietern nach, die nicht in dieser Datenschutzerklärung genannt sind. Insbesondere werden nicht eingesetzt:
</p>
<ul>
<li>Google Tag Manager</li>
<li>Facebook Pixel</li>
<li>LinkedIn Insight Tag</li>
<li>HubSpot, Salesforce oder andere CRM-Tracker</li>
<li>Hotjar, Mouseflow oder andere Session-Recording-Tools</li>
<li>Matomo oder andere selbst gehostete Analytics-Tools</li>
</ul>

<h2>12. SSL/TLS-Verschlüsselung</h2>
<p>
Diese Website nutzt aus Sicherheitsgründen eine SSL/TLS-Verschlüsselung. Eine verschlüsselte Verbindung erkennen Sie an dem "https://" in der Adresszeile Ihres Browsers.
</p>

<h2>13. Server-Logfiles</h2>
<p>
Der Hosting-Anbieter (Cloudflare) erhebt technisch bedingt Zugriffsdaten in Server-Logfiles. Diese können enthalten: aufgerufene Seite, Zeitpunkt, Datenmenge, Referrer-URL, IP-Adresse, Browser und Betriebssystem. Die Logfiles werden von Cloudflare für maximal 72 Stunden gespeichert und nicht mit anderen Daten zusammengeführt.
</p>
<p>
Rechtsgrundlage: Art.&nbsp;6 Abs.&nbsp;1 lit.&nbsp;f DSGVO (berechtigtes Interesse an der Sicherstellung des technischen Betriebs und der Erkennung von Angriffen).
</p>

<h2>14. Künstliche Intelligenz und automatisierte Entscheidungsfindung</h2>
<p>
Es findet keine automatisierte Entscheidungsfindung einschließlich Profiling gemäß Art.&nbsp;22 DSGVO statt. Mit Ausnahme des unter Abschnitt&nbsp;15 beschriebenen, von Ihnen aktiv und freiwillig genutzten BV-KI-Drafters werden auf dieser Website keine KI-Systeme zur automatisierten Verarbeitung personenbezogener Daten von Website-Besuchern eingesetzt.
</p>

<h3>KI-gestützte Inhaltserstellung</h3>
<p>
Gosign setzt KI-gestützte Werkzeuge (Large Language Models, Bildgenerierung) zur Erstellung und Bearbeitung von Website-Inhalten, Grafiken und Diagrammen ein. Diese Werkzeuge verarbeiten keine personenbezogenen Daten von Website-Besuchern. Die Ergebnisse werden redaktionell geprüft und freigegeben.
</p>

<h3>KI in Kundenprojekten</h3>
<p>
Gosign entwickelt und betreibt KI-Infrastruktur für Unternehmenskunden (AI Agents, Document Intelligence, Workflow-Automatisierung). Die Verarbeitung personenbezogener Daten in Kundenprojekten erfolgt auf Grundlage separater Verträge zur Auftragsverarbeitung (AVV) gemäß Art.&nbsp;28 DSGVO und ist nicht Gegenstand dieser Datenschutzerklärung.
</p>

<h2>15. KI-Betriebsvereinbarungs-Entwurfsassistent (BV-KI-Drafter)</h2>
<p>
Auf unseren deutschsprachigen Tool-Seiten bieten wir einen KI-gestützten Assistenten an, der auf Grundlage Ihrer Eingaben einen Entwurf für eine Betriebsvereinbarung zur Nutzung Künstlicher Intelligenz erstellt und Ihnen das Ergebnis per E-Mail zustellt (intern „BV-KI-Drafter"). Die Nutzung ist freiwillig; die nachfolgenden Angaben gelten ausschließlich, wenn Sie dieses Tool aktiv verwenden.
</p>

<h3>Zweck der Verarbeitung</h3>
<p>
Wir verarbeiten Ihre Eingaben, um den von Ihnen angeforderten Entwurf zu generieren, sowie Ihre E-Mail-Adresse, um Ihnen den fertigen Entwurf zuzustellen. Zur Begrenzung missbräuchlicher Mehrfachnutzung speichern wir zusätzlich Ihre E-Mail-Adresse in verschlüsselter Form sowie eine anonyme Zusammenfassung Ihrer Auswahl. Bitte geben Sie in das Tool keine echten personenbezogenen Daten von Beschäftigten ein, sondern Beispielangaben.
</p>

<h3>Empfänger und Verarbeitung</h3>
<p>
Zur Erstellung des Entwurfs werden Ihre Eingaben durch einen KI-Dienst innerhalb der Europäischen Union bzw. des Europäischen Wirtschaftsraums (EU/EWR) verarbeitet, der die Anfrage an ein Large Language Model übergibt. Die Verarbeitung erfolgt ausschließlich auf Servern innerhalb der EU/des EWR; eine Übermittlung in ein Drittland im Sinne der Art.&nbsp;44&nbsp;ff. DSGVO findet dabei nicht statt. Aus Gründen der Datensparsamkeit werden Sie zudem gebeten, in der laufenden Testphase keine echten Beschäftigtendaten, sondern Beispielangaben einzugeben.
</p>

<h3>Rechtsgrundlage</h3>
<p>
Die Verarbeitung Ihrer Eingaben und Ihrer E-Mail-Adresse zur Erstellung und Zustellung des Entwurfs erfolgt auf Grundlage von Art.&nbsp;6 Abs.&nbsp;1 lit.&nbsp;b DSGVO (Durchführung der von Ihnen angeforderten Leistung). Die verschlüsselte Speicherung Ihrer E-Mail-Adresse und der anonymen Auswahl-Zusammenfassung zur Begrenzung missbräuchlicher Nutzung beruht auf Art.&nbsp;6 Abs.&nbsp;1 lit.&nbsp;f DSGVO (berechtigtes Interesse an der Verhinderung von Missbrauch).
</p>

<h3>Speicherdauer</h3>
<p>
Die Entwurfsinhalte und die zur Generierung verwendeten Eingaben werden ausschließlich zur Zustellung vorübergehend gespeichert und 72&nbsp;Stunden nach erfolgreicher Zustellung automatisch und unwiderruflich genullt, spätestens jedoch nach 14&nbsp;Tagen. Konnte ein Entwurf nicht zugestellt werden, wird der zugehörige Datensatz nach 14&nbsp;Tagen vollständig gelöscht.
</p>

<h3>Keine automatisierte Entscheidung im Einzelfall</h3>
<p>
Der erzeugte Entwurf ist ein unverbindlicher Textvorschlag zur eigenen redaktionellen Weiterverwendung. Es findet keine automatisierte Entscheidung im Einzelfall einschließlich Profiling mit rechtlicher Wirkung oder ähnlich erheblicher Beeinträchtigung gemäß Art.&nbsp;22 DSGVO statt.
</p>

<h3>Ihre Rechte und Grenzen nach der Nullung</h3>
<p>
Es gelten die unter „Ihre Rechte" genannten Betroffenenrechte (Auskunft, Berichtigung, Löschung, Einschränkung, Datenübertragbarkeit, Widerspruch). Nach der Nullung der Entwurfsinhalte ist uns eine Zuordnung dieser Inhalte zu Ihrer Person nicht mehr möglich (Art.&nbsp;11 Abs.&nbsp;2 DSGVO); Auskunfts- und Löschansprüche bezüglich der bereits genullten Inhalte können dann mangels Identifizierbarkeit nicht mehr erfüllt werden.
</p>

<h2>16. Internationale Datenschutzstandards</h2>
<p>
Gosign betreut Kunden weltweit und erkennt Datenschutzrechte nach den jeweils anwendbaren lokalen Gesetzen an. Die DSGVO bleibt als primäres Datenschutzrecht anwendbar, da die Gosign GmbH ihren Sitz in Deutschland hat und die Datenverarbeitung in der EU stattfindet. Nachfolgend ergänzende Hinweise für Nutzer aus bestimmten Rechtsräumen.
</p>

<h3>Vereinigtes Königreich</h3>
<p>
Für Nutzer im Vereinigten Königreich gilt die UK GDPR in Verbindung mit dem Data Protection Act 2018. Die Rechte entsprechen weitgehend der EU-DSGVO. Zuständige Aufsichtsbehörde: Information Commissioner's Office (ICO), Wilmslow, Cheshire, UK.
</p>

<h3>Vereinigte Staaten</h3>
<p>
Für Nutzer mit Wohnsitz in Kalifornien gelten ergänzend der California Consumer Privacy Act (CCPA) und der California Privacy Rights Act (CPRA). Dies umfasst das Recht auf Auskunft über gesammelte Datenkategorien, das Recht auf Löschung und das Recht, dem Verkauf personenbezogener Daten zu widersprechen. Gosign verkauft keine personenbezogenen Daten und gibt sie nicht an Dritte zu Werbezwecken weiter. Für Nutzer in anderen US-Bundesstaaten mit eigenen Datenschutzgesetzen (Colorado, Connecticut, Virginia, Utah, Texas, Oregon u.&nbsp;a.) werden vergleichbare Rechte anerkannt.
</p>

<h3>Schweiz</h3>
<p>
Für Nutzer in der Schweiz gilt das revidierte Bundesgesetz über den Datenschutz (revDSG/nDSG), in Kraft seit 1.&nbsp;September 2023. Es gewährt vergleichbare Rechte wie die DSGVO. Zuständige Aufsichtsbehörde: Eidgenössischer Datenschutz- und Öffentlichkeitsbeauftragter (EDÖB), Bern.
</p>

<h3>Kanada</h3>
<p>
Für Nutzer in Kanada gilt der Personal Information Protection and Electronic Documents Act (PIPEDA). Gosign erkennt die PIPEDA-Grundsätze an, insbesondere Einwilligung, Zweckbindung, Auskunft und Berichtigung. Zuständige Aufsichtsbehörde: Office of the Privacy Commissioner of Canada (OPC), Gatineau, QC.
</p>

<h3>Brasilien</h3>
<p>
Für Nutzer in Brasilien gilt ergänzend die Lei Geral de Proteção de Dados (LGPD, Lei n.º&nbsp;13.709/2018). Die LGPD gewährt brasilianischen Nutzern umfassende Rechte, darunter Auskunft, Berichtigung, Anonymisierung, Löschung, Datenübertragbarkeit und Widerspruch. Diese Rechte werden von uns vollumfänglich anerkannt. Zuständige Aufsichtsbehörde: Autoridade Nacional de Proteção de Dados (ANPD), Brasília, DF.
</p>

<h3>Indien</h3>
<p>
Für Nutzer in Indien gilt der Digital Personal Data Protection Act (DPDP Act, 2023). Gosign erkennt die Rechte indischer Nutzer an, insbesondere auf Auskunft, Berichtigung, Löschung und Beschwerde. Zuständige Aufsichtsbehörde: Data Protection Board of India (DPBI), Neu-Delhi.
</p>

<h3>Japan</h3>
<p>
Für Nutzer in Japan gilt der Act on the Protection of Personal Information (APPI). Die EU-Kommission hat Japan einen angemessenen Datenschutzstatus zuerkannt. Gosign erkennt die APPI-Rechte an, insbesondere Auskunft, Berichtigung, Löschung und Nutzungseinstellung. Zuständige Aufsichtsbehörde: Personal Information Protection Commission (PPC), Tokio.
</p>

<h3>Südafrika</h3>
<p>
Für Nutzer in Südafrika gilt der Protection of Personal Information Act (POPIA). Gosign erkennt die POPIA-Rechte an, insbesondere Auskunft, Berichtigung, Löschung und Widerspruch gegen Direktmarketing. Zuständige Aufsichtsbehörde: Information Regulator, Johannesburg.
</p>

<h3>Alle übrigen Rechtsräume</h3>
<p>
Für Nutzer in Ländern mit eigenem Datenschutzgesetz, die hier nicht explizit genannt sind, erkennt Gosign die jeweils anwendbaren lokalen Datenschutzrechte an, soweit sie die Verarbeitung über diese Website betreffen. Ihre Rechte auf Auskunft, Berichtigung und Löschung werden in jedem Fall gewährleistet.
</p>

<h2>17. Ihre Rechte</h2>
<p>
Sie haben folgende Rechte bezüglich Ihrer personenbezogenen Daten:
</p>
<ul>
<li><strong>Auskunft</strong> (Art.&nbsp;15 DSGVO): Sie können Auskunft über die von uns verarbeiteten Daten verlangen.</li>
<li><strong>Berichtigung</strong> (Art.&nbsp;16 DSGVO): Sie können die Berichtigung unrichtiger Daten verlangen.</li>
<li><strong>Löschung</strong> (Art.&nbsp;17 DSGVO): Sie können die Löschung Ihrer Daten verlangen, sofern keine gesetzlichen Aufbewahrungspflichten entgegenstehen.</li>
<li><strong>Einschränkung</strong> (Art.&nbsp;18 DSGVO): Sie können die Einschränkung der Verarbeitung verlangen.</li>
<li><strong>Datenübertragbarkeit</strong> (Art.&nbsp;20 DSGVO): Sie können die Herausgabe Ihrer Daten in einem maschinenlesbaren Format verlangen.</li>
<li><strong>Widerspruch</strong> (Art.&nbsp;21 DSGVO): Sie können der Verarbeitung auf Basis von Art.&nbsp;6 Abs.&nbsp;1 lit.&nbsp;f DSGVO jederzeit widersprechen.</li>
<li><strong>Widerruf der Einwilligung</strong> (Art.&nbsp;7 Abs.&nbsp;3 DSGVO): Sofern eine Verarbeitung auf Ihrer Einwilligung beruht, können Sie diese jederzeit mit Wirkung für die Zukunft widerrufen. Die Rechtmäßigkeit der bis zum Widerruf erfolgten Verarbeitung bleibt davon unberührt.</li>
</ul>
<p>
Zur Ausübung Ihrer Rechte genügt eine formlose Mitteilung an die oben genannte Adresse.
</p>

<h2>18. Beschwerderecht</h2>
<p>
Sie haben das Recht, sich bei einer Datenschutz-Aufsichtsbehörde zu beschweren. Zuständig ist die Aufsichtsbehörde des Bundeslandes, in dem Sie wohnen, oder die für den Verantwortlichen zuständige Behörde:
</p>
<p>
Der Hamburgische Beauftragte für Datenschutz und Informationsfreiheit<br/>
Ludwig-Erhard-Str. 22<br/>
20459 Hamburg
</p>

<h2>19. Aktualität</h2>
<p>
Diese Datenschutzerklärung ist aktuell gültig. Stand: Februar 2026.
</p>
<p>
Wir behalten uns vor, diese Datenschutzerklärung anzupassen, um sie an geänderte Rechtslagen oder Änderungen des Dienstes anzupassen.
</p>


<!-- lyftyfy-dse-start -->
<!-- version: 2026-04-13.v2 -->
## Tracking & Analytics (lyftyfy)

Wir verarbeiten Nutzungsdaten dieser Website zur Optimierung unserer Marketing-Kampagnen.

**Transparenzhinweis (TDDDG § 25):** Es werden ausschliesslich tab-lokale `sessionStorage`-Eintraege mit dem Praefix `gs_*` auf Ihrem Geraet gespeichert, die beim Schliessen des Tabs automatisch verfallen. Es werden KEINE Cookies und KEINE persistenten lokalen Speicher-Eintraege gesetzt.

**Rechtsgrundlage:** Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse an einer datenbasierten Ausspielung unserer Marketing-Inhalte).

**Zweck:** Marketing-Analytics - Session-basierte Auswertung von Nutzerverhalten (Scroll-Tiefe, CTA-Sichtbarkeit, Formular-Interaktion) ohne personenbezogene Profilbildung.

**Datenkategorien:**
- Session-Hash (kein Klartext, ein salted-SHA256 pro Session, nicht wiederherstellbar)
- Intent-Label (grobe Kategorisierung der Besuchsintention)
- Grobe Herkunft (referrer-Kategorie, UTM-Parameter wenn vorhanden)
- Seiten-Pfad und Scroll-Events

**Ausdruecklich NICHT verarbeitet:** IP-Adressen, User-Agent-Strings, Klartext-Cookies, Cross-Site-Tracking, Fingerprinting.

**Speicherdauer:** 30 Tage. Nach Ablauf dieser Frist werden alle Rohdaten automatisch geloescht, nur aggregierte Auswertungen bleiben erhalten.

**Widerspruchsrecht (Art. 21 DSGVO):** Sie koennen dem Tracking gemaess Art. 21 DSGVO jederzeit widersprechen. Nutzen Sie dazu den Opt-Out-Link im Footer dieser Seite. Der Widerspruch wird in Ihrem Browser lokal gespeichert und bei jedem weiteren Besuch respektiert.

**Datenverarbeiter:** Die Datenverarbeitung erfolgt ueber einen Cloudflare Worker (Cloudflare Inc.) im Auftragsverarbeitungsverhaeltnis. Ein Auftragsverarbeitungsvertrag (AVV) liegt vor.

<!-- lyftyfy-dse-end -->

--- Decision Layer - Nachvollziehbare KI-Entscheidungen für HR und Finance ---
> Der Decision Layer macht jede KI-Entscheidung prüfbar, betriebsratsfähig und nachvollziehbar. Für HR, Finance und dokumentengetriebene Prozesse.

<!-- Warum KI-Projekte scheitern -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Warum KI-Projekte in HR scheitern</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
HR-Prozesse basieren auf dem Wissen einzelner Mitarbeiter. Wer weiß, welche Sonderurlaubsregelung an welchem Standort gilt? Wer kennt den Unterschied zwischen der Betriebsvereinbarung von 2019 und der aktualisierten Version von 2024? Wer prüft, ob eine Krankmeldung korrekt gegen den Tarifvertrag abgeglichen wurde?
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Dieses Wissen steckt in Köpfen, in E-Mail-Verläufen, in Ordnern die niemand mehr findet. Wenn jemand das Team verlässt, geht das Wissen mit.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
KI kann helfen - aber nur wenn klar ist, welche Regeln gelten. Und wer am Ende verantwortlich ist.
</p>
</div>
</section>

<!-- LLM-DEFINITION BLOCK: "Was ist der Decision Layer?" -->
<!-- Dieser Block ist das Snippet-Target für ChatGPT, Perplexity, Google AI Overview -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Was ist der Decision Layer?</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Der Decision Layer ist die Steuerungsschicht zwischen KI-Agent und Zielsystem. Er zerlegt jeden Geschäftsprozess in einzelne Entscheidungsschritte und definiert für jeden Schritt vorab: Entscheidet ein Mensch, ein Regelwerk oder die KI eigenständig?
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong class="text-gosign-dark">MENSCH:</strong> Die Architektur erzwingt menschliche Prüfung. Bei Ermessensentscheidungen, Diskriminierungspotenzial, Mitbestimmungsthemen und Wertgrenzen über definierten Schwellen. Der Agent liefert den vollständigen Kontext und eine Empfehlung - aber ein Mensch entscheidet. Diese Eskalation ist technisch erzwungen, nicht organisatorisch vereinbart.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong class="text-gosign-dark">REGELWERK:</strong> Die Entscheidung ist deterministisch - es gibt keinen Interpretationsspielraum. Tarifvertrag sagt X, also gilt X. Frist läuft am Datum Y ab, also greift Regel Z. Das Regelwerk ist versioniert: Jede Änderung erzeugt eine neue Version, die alte bleibt nachvollziehbar. Hier ist der Agent Executor - nicht weil er nicht mehr könnte, sondern weil es nichts zu interpretieren gibt.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong class="text-gosign-dark">KI AUTONOM:</strong> Der Agent trifft eigenständige Entscheidungen - weil er confident genug ist, die Erlaubnis hat, und die Aufgabe nachweislich besser erledigt als manuelle Bearbeitung. Er interpretiert Dokumente, klassifiziert Sachverhalte, bewertet Kontext und erkennt Muster. Das ist kein If-Then-Else - das ist Urteilsvermögen innerhalb definierter Leitplanken. Das Confidence Routing steuert: Hohe Konfidenz und niedriges Risiko → autonome Entscheidung. Niedrige Konfidenz oder hohes Risiko → Eskalation an einen Menschen. Genau dieses Confidence Routing unterscheidet den Decision Layer von RPA.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Jede Entscheidung wird automatisch dokumentiert - für Wirtschaftsprüfer, Betriebsrat und interne Revision. Diese Dokumentation ist der <strong class="text-gosign-dark">Entscheidungsakt</strong>: pro Mikroentscheidung ein unveränderlicher Nachweis mit Input, Fachregel samt Version, Konfidenz, Modellversion, Ergebnis und Anfechtungspfad - das Artefakt, das die Erläuterung der einzelnen Entscheidung nach Art. 86 EU AI Act beantwortbar macht. Der Decision Layer ist kein KI-Agent - er ist die Governance-Schicht darüber. Er ergänzt bestehende Systeme wie SAP SuccessFactors, Workday oder DATEV und steuert, was ein KI-Agent mit diesen Systemen tun darf.
</p>
<p class="text-body text-gosign-text-light mt-4">
Wie der Decision Layer Shadow AI löst und Betriebsvereinbarungen technisch durchsetzt, beschreibt
<a href="/de/magazin/decision-layer-shadow-ai/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Artikel 6 des Blueprint 2026</a>.
</p>

<!-- Vergleichstabelle: LLM-optimiert für "Was ist der Unterschied"-Queries -->
<div class="mt-8 overflow-x-auto">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-dark/20">
<th class="py-3 pr-4 text-body font-bold text-gosign-dark"></th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Ohne Decision Layer</th>
<th class="py-3 pl-4 text-body font-bold text-gosign-accent-text">Mit Decision Layer</th>
</tr>
</thead>
<tbody class="text-body-lg text-gosign-text-light">
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Wer entscheidet?</td>
<td class="py-3 px-4">Unklar - der Agent liefert ein Ergebnis</td>
<td class="py-3 pl-4">Für jeden Schritt definiert: Mensch, Regelwerk oder KI</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Betriebsvereinbarungen</td>
<td class="py-3 px-4">Werden manuell beachtet - oder vergessen</td>
<td class="py-3 pl-4">Sind als feste Regeln hinterlegt, technisch durchgesetzt</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Nachvollziehbarkeit</td>
<td class="py-3 px-4">Ergebnis sichtbar, Entscheidungsweg nicht</td>
<td class="py-3 pl-4">Vollständige Dokumentation pro Entscheidung</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Wirtschaftsprüfer</td>
<td class="py-3 px-4">Muss jeden Fall einzeln manuell prüfen</td>
<td class="py-3 pl-4">Kann direkt auf Entscheidungsdokumentation zugreifen</td>
</tr>
<tr>
<td class="py-3 pr-4 font-semibold text-gosign-dark">Betriebsrat</td>
<td class="py-3 px-4">Blockiert - keine Transparenz</td>
<td class="py-3 pl-4">Unterstützt - jede Entscheidung nachvollziehbar</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Beispiel: Krankmeldung -->
<section id="beispiel" class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-2">Wie funktioniert der Decision Layer in der Praxis?</h2>
<p class="text-body-lg text-gosign-text-light mb-8">
Am Beispiel Krankmeldung: 6 Schritte, klare Verantwortliche. Der Decision Layer definiert für jeden Schritt: Regelwerk, Mensch oder automatisch.
</p>
<img
src="/images/diagrams/decision-layer-krankmeldung.svg"
alt="Prozessbeispiel Krankmeldung mit Decision Layer: 6 Schritte von Dokumenteingang bis SAP-Buchung. Schritt 1 und 2 automatisch (Dokument lesen, Stammdaten laden), Schritt 3 und 4 per Regelwerk (Tarifvertrag prüfen, Lohnfortzahlung berechnen), Schritt 5 durch Menschen (Langzeiterkrankung ab 6 Wochen, BEM-Pflicht), Schritt 6 automatische SAP-Buchung."
class="w-full"
loading="lazy"
width="1200"
height="600"
/>
</div>
</section>

<!-- Betriebsrat -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Warum scheitern KI-Projekte am Betriebsrat?</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Der häufigste Grund warum KI-Projekte in deutschen Unternehmen scheitern: Der Betriebsrat blockiert. Nicht weil er gegen Technologie ist - sondern weil er keine Transparenz hat. Der Decision Layer löst das:
</p>
<div class="mt-8 space-y-4">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent/10 rounded-full flex items-center justify-center text-gosign-accent font-bold text-small before:content-['✓']" aria-hidden="true"></span>
<p class="text-body-lg text-gosign-text-light">Jede Betriebsvereinbarung wird als feste Regel hinterlegt. Der Agent kann sie nicht umgehen.</p>
</div>
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent/10 rounded-full flex items-center justify-center text-gosign-accent font-bold text-small before:content-['✓']" aria-hidden="true"></span>
<p class="text-body-lg text-gosign-text-light">Bei Entscheidungen die Mitarbeiter betreffen, entscheidet immer ein Mensch. Technisch erzwungen, nicht nur vereinbart.</p>
</div>
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent/10 rounded-full flex items-center justify-center text-gosign-accent font-bold text-small before:content-['✓']" aria-hidden="true"></span>
<p class="text-body-lg text-gosign-text-light">Jede KI-Entscheidung ist dokumentiert: Was wurde geprüft, welche Regel, welches Ergebnis.</p>
</div>
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent/10 rounded-full flex items-center justify-center text-gosign-accent font-bold text-small before:content-['✓']" aria-hidden="true"></span>
<p class="text-body-lg text-gosign-text-light">Der Betriebsrat kann jederzeit nachvollziehen, wie eine Entscheidung zustande kam.</p>
</div>
</div>
<p class="text-body-lg text-gosign-text-light mt-6">
<strong class="text-gosign-dark">Der Unterschied:</strong> Andere versprechen Transparenz. Der Decision Layer erzwingt sie technisch.
</p>
<p class="mt-4">
<a href="/de/governance/mitbestimmung/" class="text-gosign-accent-text hover:underline font-semibold">Mitbestimmung & KI-Agenten →</a>
</p>
</div>
</section>

<!-- Prüfungssicher (CFO-Block) -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Wie wird eine KI-Entscheidung prüfungssicher?</h2>
<p class="text-body-lg text-gosign-accent-text font-semibold mt-4">Ihr Wirtschaftsprüfer sieht genau, was passiert ist.</p>
<ul class="mt-6 space-y-3">
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-6 h-6 bg-gosign-accent/10 rounded-full flex items-center justify-center text-gosign-accent font-bold text-xs mt-0.5 before:content-['✓']" aria-hidden="true"></span>
<span class="text-body-lg text-gosign-text-light">Welches Dokument wurde verarbeitet - und wann?</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-6 h-6 bg-gosign-accent/10 rounded-full flex items-center justify-center text-gosign-accent font-bold text-xs mt-0.5 before:content-['✓']" aria-hidden="true"></span>
<span class="text-body-lg text-gosign-text-light">Welche Regel wurde angewandt - und in welcher Version?</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-6 h-6 bg-gosign-accent/10 rounded-full flex items-center justify-center text-gosign-accent font-bold text-xs mt-0.5 before:content-['✓']" aria-hidden="true"></span>
<span class="text-body-lg text-gosign-text-light">Wie sicher war der Agent bei seiner Einschätzung?</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-6 h-6 bg-gosign-accent/10 rounded-full flex items-center justify-center text-gosign-accent font-bold text-xs mt-0.5 before:content-['✓']" aria-hidden="true"></span>
<span class="text-body-lg text-gosign-text-light">Hat ein Mensch geprüft - und wenn ja, wer?</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-6 h-6 bg-gosign-accent/10 rounded-full flex items-center justify-center text-gosign-accent font-bold text-xs mt-0.5 before:content-['✓']" aria-hidden="true"></span>
<span class="text-body-lg text-gosign-text-light">Was war das Ergebnis und wann wurde es gebucht?</span>
</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-6">Jede dieser Antworten steht in einem Entscheidungsakt - so sieht er aus:</p>
<div class="not-prose mt-4 bg-surface-raised border border-base rounded-soft overflow-hidden shadow-sm">
  <div class="px-5 py-3 border-b border-base bg-surface-dim">
    <div class="flex items-center gap-3">
      <div class="flex gap-1.5" aria-hidden="true">
        <span class="w-2.5 h-2.5 rounded-full bg-[#FF5F56]"></span>
        <span class="w-2.5 h-2.5 rounded-full bg-[#FFBD2E]"></span>
        <span class="w-2.5 h-2.5 rounded-full bg-[#27C93F]"></span>
      </div>
      <span class="font-code text-xs text-muted">decision-record / krankmeldung / 2026-05-14 / EMP_0x52a8</span>
    </div>
  </div>
  <ol class="divide-y divide-base">
    <li class="p-5">
      <div class="flex items-start gap-4">
        <div class="flex-shrink-0 w-9 h-9 rounded-full flex items-center justify-center font-code text-xs font-bold border" style="background: rgba(3,105,161,0.08); border-color: rgba(3,105,161,0.3); color: #0369A1;">02</div>
        <div class="flex-1 min-w-0">
          <div class="flex flex-wrap items-center gap-2 mb-1.5">
            <span class="text-body font-semibold text-primary">Lohnfortzahlung nach &#167;3, &#167;4 EFZG berechnen</span>
            <span class="inline-flex px-2 py-0.5 text-xs font-bold uppercase tracking-wider rounded text-white" style="background: #0369A1;">Regel</span>
          </div>
          <p class="text-small text-primary font-medium mb-2">6 Wochen ab 14.05.2026, 100 % Brutto</p>
          <div class="font-code text-xs text-muted"><span>rule:</span> <span class="text-primary">EFZG-&#167;3+&#167;4 &#183; v2026-01</span></div>
        </div>
      </div>
    </li>
    <li class="p-5">
      <div class="flex items-start gap-4">
        <div class="flex-shrink-0 w-9 h-9 rounded-full flex items-center justify-center font-code text-xs font-bold border" style="background: rgba(109,78,216,0.08); border-color: rgba(109,78,216,0.3); color: #6D4ED8;">09</div>
        <div class="flex-1 min-w-0">
          <div class="flex flex-wrap items-center gap-2 mb-1.5">
            <span class="text-body font-semibold text-primary">Abwesenheits-Muster markieren</span>
            <span class="inline-flex items-center gap-1 px-2 py-0.5 text-xs font-bold uppercase tracking-wider rounded text-white" style="background: #6D4ED8;">KI <span class="font-mono opacity-90">91%</span></span>
          </div>
          <p class="text-small text-primary font-medium mb-2">Hinweis an HR-Operations: dritte Kurzzeit-AU in sechs Monaten</p>
          <div class="font-code text-xs text-muted"><span>model-reason:</span> <span class="text-primary">Muster-Abgleich &#183; Indikator, keine Personalentscheidung</span></div>
          <div class="mt-3"><span class="inline-flex items-center px-3 py-1.5 text-xs font-semibold rounded border-2" style="border-color: #6D4ED8; color: #6D4ED8; background: rgba(109,78,216,0.08);">formal anfechtbar &#183; Art. 14 EU AI Act</span></div>
        </div>
      </div>
    </li>
  </ol>
</div>
<p class="text-body text-gosign-text-light mt-4">Zwei von 13 Mikroentscheidungen eines Vorgangs - jede mit Regel-Version, Konfidenz und Anfechtungspfad. <a href="/de/magazin/entscheidungsakt-anfechtbare-ki-entscheidungen/" class="text-gosign-accent-text hover:underline font-semibold">Der vollständige Entscheidungsakt im Detail &#8594;</a></p>
</div>
</section>

<!-- Drei Arten -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-2">Welche Entscheidungen kann KI alleine treffen?</h2>
<p class="text-body-lg text-gosign-text-light mb-8">
Manche Entscheidungen kann ein KI-Agent alleine treffen. Bei anderen muss ein Mensch prüfen. Und bei strategischen Fragen liefert der Agent nur Daten. Der Decision Layer definiert das - pro Schritt, nicht pro Prozess.
</p>
<img
src="/images/diagrams/decision-layer-drei-arten.svg"
alt="Drei Arten von Entscheidungen im Decision Layer: Links - Mensch entscheidet bei Personalstrategie, Performance Reviews, Vergütungspolitik (etwa ein Drittel). Mitte - Agent arbeitet, Mensch prüft bei Belegverarbeitung, Vertragsprüfung, Onboarding (etwa 40%). Rechts - Agent selbstständig bei FAQ, Standardbescheinigungen, Fristprüfungen (etwa ein Viertel)."
class="w-full"
loading="lazy"
width="1200"
height="600"
/>
</div>
</section>

<!-- Für wen -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Für wen ist der Decision Layer?</h2>
<div class="mt-8 space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Head of HR / CHRO</p>
<p class="text-body-lg text-gosign-text-light mt-1">Sie wollen KI in HR einsetzen - aber nicht die Kontrolle verlieren. Der Decision Layer stellt sicher, dass Betriebsvereinbarungen eingehalten werden, der Betriebsrat Transparenz hat und jede Entscheidung nachvollziehbar ist.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">CFO / Head of Finance</p>
<p class="text-body-lg text-gosign-text-light mt-1">Jede KI-gestützte Buchung ist prüfungssicher dokumentiert. Ihr Wirtschaftsprüfer sieht den vollständigen Entscheidungsweg. Korrekturbuchungen werden reduziert, weil Regelwerke konsistent angewandt werden.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Betriebsrat</p>
<p class="text-body-lg text-gosign-text-light mt-1">Keine Blackbox. Betriebsvereinbarungen sind technisch hinterlegt und können nicht umgangen werden. Bei personalrelevanten Entscheidungen greift immer ein Mensch ein.</p>
</div>
<div class="border-l-4 border-gosign-dark/20 pl-6">
<p class="text-h3 font-bold text-gosign-text-light">IT / CTO</p>
<p class="text-body-lg text-gosign-text-light mt-1">Modell-agnostisch, infrastruktur-agnostisch, kein Vendor Lock-in. <a href="/de/governance/referenz-architektur/" class="text-gosign-accent-text hover:underline">Technische Details in der Referenz-Architektur →</a></p>
</div>
</div>
</div>
</div>
</section>

<!-- Domänen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">Der Decision Layer für Ihre Prozesse</h2>
<div class="grid grid-cols-1 md:grid-cols-3 gap-6">
<a href="/de/hr-ai-agents/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<h3 class="text-h3 font-bold text-gosign-dark">HR & People Operations</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Krankmeldungen, Onboarding, Zeugnisse, Vertragsprüfung, Policy-Abfragen. Betriebsratsfähig, EU AI Act-konform.</p>
<span class="inline-block mt-4 text-gosign-accent-text font-semibold text-body">HR Agent ansehen →</span>
</a>
<a href="/de/finance-ai-agents/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<h3 class="text-h3 font-bold text-gosign-dark">Finance & Payroll</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Belegverarbeitung, Kontierung, Lohnabrechnung, Abschlussbuchungen. Prüfungssicher dokumentiert. DATEV- und SAP-Integration.</p>
<span class="inline-block mt-4 text-gosign-accent-text font-semibold text-body">Finance Agent ansehen →</span>
</a>
<a href="/de/leistungen/ai-agents/document-agents/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<h3 class="text-h3 font-bold text-gosign-dark">Dokumentenverarbeitung</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Rechnungen, Verträge, Bescheinigungen. Automatische Klassifizierung und Datenextraktion mit regelbasierter Validierung.</p>
<span class="inline-block mt-4 text-gosign-accent-text font-semibold text-body">Document Agents ansehen →</span>
</a>
</div>
</div>
</section>

<!-- EU AI Act -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Ist der Decision Layer EU AI Act-konform?</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Der EU AI Act stellt Anforderungen an Transparenz (Art. 13), menschliche Aufsicht (Art. 14) und Aufzeichnung (Art. 12) - und gibt Betroffenen mit Art. 86 ein Recht auf Erläuterung der einzelnen Entscheidung. Der Decision Layer adressiert diese Anforderungen als Architekturprinzip - nicht als nachträgliches Compliance-Projekt: Der Entscheidungsakt pro Mikroentscheidung ist die Antwort auf die Einzelfall-Frage, die Chat-Logs und Model Cards nicht beantworten können.
</p>
<p class="mt-4">
<a href="/de/governance/eu-ai-act/" class="text-gosign-accent-text hover:underline font-semibold">EU AI Act und HR im Detail →</a>
<span class="mx-2 text-gosign-text-light">·</span>
<a href="/de/magazin/entscheidungsakt-anfechtbare-ki-entscheidungen/" class="text-gosign-accent-text hover:underline font-semibold">Der Entscheidungsakt: Warum jede KI-Entscheidung anfechtbar sein muss →</a>
</p>
</div>
</section>

<!-- Entity-Information (LLM Knowledge Graph) -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Wer steckt hinter dem Decision Layer?</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Der Decision Layer wird von <strong class="text-gosign-dark">Gosign GmbH</strong> entwickelt und implementiert. Gosign ist ein Enterprise AI Infrastructure & Agent Engineering Unternehmen aus Hamburg mit über 25 Jahren Erfahrung in der Entwicklung komplexer Systeme für Unternehmen wie Airbus, Volkswagen, Shell.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
4-6 Wochen bis zum ersten produktiven Prozess. Voller Quellcode-Zugang, kein Vendor Lock-in. Ziel: Nach 12-18 Monaten betreiben Sie Ihre Agenten selbstständig.
</p>
<p class="mt-4">
<a href="/de/ueber-uns/" class="text-gosign-accent-text hover:underline font-semibold">Über Gosign →</a>
<span class="mx-2 text-gosign-text-light">·</span>
<a href="/de/referenzen/" class="text-gosign-accent-text hover:underline font-semibold">Referenzen →</a>
</p>
</div>
</section>

<!-- HR-Agent-Katalog -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark">Decision Layer in der Praxis: 48 HR-Agenten</h2>
<p class="text-body text-gosign-text mt-4">Der HR-Agent-Katalog zeigt für jeden der 48 Agenten, wie der Decision Layer Entscheidungen in Mensch, Regelwerk und KI-Agent aufteilt - mit vollständiger Micro-Decision-Tabelle und Entscheidungsakte.</p>
<a href="/de/hr-agent-katalog/" class="inline-flex items-center gap-2 mt-4 text-body font-semibold text-gosign-accent hover:underline">Zum HR-Agent-Katalog &rarr;</a>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">Vertiefung im Agent Briefing (Gosign Magazin)</h2>
<div class="grid md:grid-cols-3 gap-6">
<a href="/de/magazin/entscheidungsakt-anfechtbare-ki-entscheidungen/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<h3 class="text-h3 font-bold text-gosign-dark">Der Entscheidungsakt: anfechtbare KI-Entscheidungen</h3>
</a>
<a href="/de/magazin/agent-governance-hr/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR</p>
<h3 class="text-h3 font-bold text-gosign-dark">Agent Governance für HR</h3>
</a>
<a href="/de/magazin/betriebsrat-ki-mitbestimmung/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<h3 class="text-h3 font-bold text-gosign-dark">Betriebsrat und KI - Mitbestimmung</h3>
</a>
</div>
</div>
</section>

--- Digitalagentur Hamburg | Gosign | Web, KI, TYPO3 ---
> Gosign ist eine Hamburger Digitalagentur für Webentwicklung, KI-Integration und TYPO3. 25 Jahre Erfahrung. B2B-Fokus.

<!-- Was ist Gosign? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Was ist Gosign?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Gosign ist eine Hamburger Digitalagentur mit 25&nbsp;Jahren Erfahrung in Webentwicklung, TYPO3-Systemen und KI-Integration für Unternehmen. Gegründet 1999, heute spezialisiert auf B2B-Websites, Enterprise-CMS-Projekte und KI-Infrastrukturen. Gosign betreut mittelständische Unternehmen, Hochschulen und öffentliche Einrichtungen in Deutschland.
</p>
</div>
</section>

<!-- Warum Gosign? -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Warum Gosign?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Weil wir nicht nur Websites bauen, sondern digitale Infrastruktur. Drei Kernbereiche, ein Team:
</p>
</div>
</section>

<!-- Webentwicklung & CMS -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Webentwicklung &amp; CMS</h2>
<p class="text-body text-gosign-text leading-relaxed">
Websites, die performen. Technisch und geschäftlich. TYPO3, WordPress, Astro, Headless-Architekturen. Von der Konzeption bis zum Go-Live, von 10&nbsp;Seiten bis 10.000. Gosign hat über 800 TYPO3 Extensions analysiert und entwickelt Enterprise-CMS-Projekte seit zwei Jahrzehnten.
</p>
</div>
</section>

<!-- KI-Integration -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">KI-Integration für Unternehmen</h2>
<p class="text-body text-gosign-text leading-relaxed">
KI-Infrastrukturen direkt in Ihrer Unternehmensumgebung: KI-Assistenten, KI-Agents, Modell-Hosting (DeepSeek, Llama, Mistral) auf Ihrer eigenen Infrastruktur. DSGVO-konform, BSI-konform, ohne Datenabfluss an Dritte. Gosign baut KI-Lösungen, die in bestehende IT-Landschaften passen.
</p>
</div>
</section>

<!-- TYPO3-Spezialisierung -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">TYPO3-Spezialisierung</h2>
<p class="text-body text-gosign-text leading-relaxed">
Über 800 TYPO3 Extensions überwacht, mehr als 500 erfolgreich implementiert. Von Solr-Enterprise-Suche über SSO-Integration bis hin zu E-Commerce mit aimeos. Gosign ist einer der erfahrensten TYPO3-Dienstleister in Deutschland.
</p>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Lassen Sie uns über Ihr Projekt sprechen, 30&nbsp;Minuten, kostenlos.</h3>
<p class="text-body text-gosign-text mb-6">Wir analysieren Ihr Projekt, schätzen Aufwand und Zeitrahmen, unverbindlich.</p>
<a
href="/de/kontakt/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Erstgespräch vereinbaren
</a>
<p class="text-small text-gosign-text-light mt-4">25 Jahre Erfahrung · 800+ Extensions · KI-beschleunigte Entwicklung</p>
</div>
</section>

<!-- Comparison Table -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Was Gosign von anderen Digitalagenturen unterscheidet</h2>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Kriterium</th>
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Typische Agentur</th>
<th class="py-3 text-small font-bold text-gosign-dark">Gosign</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">CMS-Tiefe</td>
<td class="py-3 pr-4 text-body text-gosign-text">WordPress-Basics</td>
<td class="py-3 text-body text-gosign-text">TYPO3 Enterprise + WordPress + Headless</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">KI-Kompetenz</td>
<td class="py-3 pr-4 text-body text-gosign-text">ChatGPT-Prompts</td>
<td class="py-3 text-body text-gosign-text">Eigene KI-Infrastrukturen, Modell-Hosting</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Entwicklungsgeschwindigkeit</td>
<td class="py-3 pr-4 text-body text-gosign-text">Klassisch</td>
<td class="py-3 text-body text-gosign-accent-text font-semibold">KI-beschleunigt: 60 - 80&nbsp;% schneller</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Branchenfokus</td>
<td class="py-3 pr-4 text-body text-gosign-text">Alles für alle</td>
<td class="py-3 text-body text-gosign-text">B2B, Mittelstand, Hochschulen, öffentliche Hand</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Sicherheit</td>
<td class="py-3 pr-4 text-body text-gosign-text">Standard-Hosting</td>
<td class="py-3 text-body text-gosign-text">BSI-konforme Infrastrukturen, Security-Monitoring</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Standort</td>
<td class="py-3 pr-4 text-body text-gosign-text">Remote/Global</td>
<td class="py-3 text-body text-gosign-text">Hamburg, persönliche Betreuung</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Branchen -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Branchen</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
Gosign arbeitet für Unternehmen, die digitale Infrastruktur ernst nehmen:
</p>
<div class="grid md:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Maschinenbau &amp; Industrie</h3>
<p class="text-body text-gosign-text">B2B-Websites mit Produkt-Konfiguratoren, Händler-Portale, technische Dokumentation</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Automotive</h3>
<p class="text-body text-gosign-text">Markenportale, Händlernetzwerke, digitale Showrooms</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Health &amp; Pharma</h3>
<p class="text-body text-gosign-text">Compliance-konforme Websites, Patientenportale</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Bildung &amp; Hochschulen</h3>
<p class="text-body text-gosign-text">Shibboleth-SSO, Studiengangfinder, barrierefreie Webauftritte</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Verbände &amp; öffentliche Hand</h3>
<p class="text-body text-gosign-text">Mitgliederverwaltung, mehrsprachige Portale, Barrierefreiheit</p>
</div>
</div>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
Gosign ist eine Hamburger Digitalagentur mit 25 Jahren Erfahrung in Webentwicklung, TYPO3 und KI-Integration.
Wir haben über 800 TYPO3 Extensions analysiert und entwickeln heute mit KI-Unterstützung
bis zu 70&nbsp;% schneller als mit klassischen Methoden. Unsere Kunden sind mittelständische
Unternehmen, Hochschulen und öffentliche Einrichtungen in Deutschland.
</p>
<p class="text-small text-gosign-text-light mt-2">Stand: Februar 2026</p>
</div>
</section>

<!-- Verwandte Themen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Verwandte Themen</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/de/wordpress-agentur/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Webentwicklung</p>
<p class="text-body font-semibold text-gosign-dark">WordPress Agentur Hamburg</p>
</a>
<a href="/de/typo3-extensions/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">TYPO3</p>
<p class="text-body font-semibold text-gosign-dark">TYPO3 Extensions: Entwicklung & Monitoring</p>
</a>
<a href="/de/website-sicherheit-bsi/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Sicherheit</p>
<p class="text-body font-semibold text-gosign-dark">Website-Sicherheit nach BSI-Gesetz</p>
</a>
</div>
</div>
</section>

--- eBook: Finance Agent Readiness Assessment - 15 Fragen für CFO und Wirtschaftsprüfer ---
> Kostenloses Assessment-eBook: 15 Fragen zur Finance Agent Readiness. GoBD-Check, §203-Bewertung, Team-Assessment mit Delta-Analyse.

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">

<div class="grid md:grid-cols-5 gap-12 items-start">

<div class="md:col-span-3">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Was Sie in diesem Assessment finden</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
42% aller Rechnungen in der Kreditorenbuchhaltung werden noch manuell verarbeitet (IFM 2024). Bei durchschnittlich EUR 11,50 pro Rechnung ist das ein messbarer Kostenfaktor. Dieses Assessment zeigt, wo Ihre Finance-Organisation steht - und welche Agenten den größten Hebel haben.
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8 mb-3">15 Fragen in 5 Dimensionen</h3>
<ul class="space-y-2 text-body text-gosign-text">
<li class="flex items-start gap-2"><span class="text-gosign-accent-text font-bold">1.</span> Prüfungssicherheit - Wie audit-ready sind Ihre Prozesse?</li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text font-bold">2.</span> Berufsgeheimnisschutz - §203 StGB Status und Datentrennung</li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text font-bold">3.</span> ERP-Landschaft - Wie integriert sind Ihre Finance-Systeme?</li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text font-bold">4.</span> Abschlussgeschwindigkeit - Wie schnell ist Ihr Monatsabschluss?</li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text font-bold">5.</span> Prozessreife - Wie formalisiert sind Kontierungsregeln?</li>
</ul>

<h3 class="text-h3 font-bold text-gosign-dark mt-8 mb-3">Was das eBook vom Online-Tool unterscheidet</h3>
<div class="overflow-x-auto">
<table class="w-full text-body text-gosign-text border-collapse mt-4">
<thead><tr class="border-b-2 border-gosign-border"><th class="text-left py-2 pr-4 font-bold text-gosign-dark">Merkmal</th><th class="text-left py-2 pr-4 font-bold text-gosign-dark">Online (3 Min.)</th><th class="text-left py-2 font-bold text-gosign-dark">eBook (PDF)</th></tr></thead>
<tbody>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Fragen</td><td class="py-2 pr-4">7</td><td class="py-2">15</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">GoBD-/§203-Check</td><td class="py-2 pr-4">Basis</td><td class="py-2">Vertieft (6 Fragen)</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Team-Assessment</td><td class="py-2 pr-4">Nein</td><td class="py-2">Ja (CFO + WP + IT)</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Delta-Analyse</td><td class="py-2 pr-4">Nein</td><td class="py-2">Ja</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Druckbar</td><td class="py-2 pr-4">Nein</td><td class="py-2">Ja (A4 optimiert)</td></tr>
</tbody>
</table>
</div>
</div>

<div class="md:col-span-2">
<div class="sticky top-24 bg-gosign-light border border-gosign-border rounded-card p-6">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-3">Kostenloses PDF</p>
<p class="text-h3 font-bold text-gosign-dark mb-2">Assessment herunterladen</p>
<p class="text-small text-gosign-text-light mb-4">14 Seiten, GoBD-Check, §203-Bewertung, Team-Assessment mit Delta-Analyse.</p>
<a href="#download" class="block w-full text-center px-6 py-3 bg-gosign-accent-btn text-white font-semibold rounded-lg hover:bg-gosign-accent-btn-hover transition-colors" data-ebook-download>Assessment herunterladen</a>
<p class="text-xs text-gosign-text-light mt-3">Nur E-Mail-Adresse nötig. Sofort als PDF.</p>
</div>
</div>

</div>
</div>
</section>

<!-- Quick Check Verweis -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<div class="border-2 border-gosign-accent/20 rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Schnellcheck: Online-Assessment</p>
<p class="text-body text-gosign-text mb-4">Keine Zeit für das volle Assessment? Machen Sie zuerst den 3-Minuten-Schnellcheck mit 7 Fragen und automatischem Radar-Chart.</p>
<a href="/de/finance-agent-readiness/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Online-Assessment starten &rarr;</a>
</div>
</div>
</section>

<!-- Weitere eBooks -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Weitere eBooks</h2>
<div class="grid grid-cols-1 sm:grid-cols-2 gap-4">
<a href="/de/ebook/ki-finance-governance-handbuch/" class="block border border-gosign-border rounded-card p-4 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-1">Finance Governance</p>
<p class="text-body font-semibold text-gosign-dark">KI in Finance: Governance-Handbuch</p>
</a>
<a href="/de/ebook/hr-agent-readiness-assessment/" class="block border border-gosign-border rounded-card p-4 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-1">HR Assessment</p>
<p class="text-body font-semibold text-gosign-dark">HR Agent Readiness Assessment</p>
</a>
</div>
</div>
</section>

--- eBook: HR Agent Readiness Assessment - 15 Fragen für das Führungsteam ---
> Kostenloses Assessment-eBook: 15 Fragen zur HR Agent Readiness. Worksheets zum Ausfüllen, Radar-Chart-Vorlage, Team-Assessment mit Delta-Analyse.

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">

<div class="grid md:grid-cols-5 gap-12 items-start">

<div class="md:col-span-3">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Was Sie in diesem Assessment finden</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
73% der Organisationen haben noch kein KI-Governance-Framework (ISACA 2024). Dieses Assessment zeigt Ihnen, wo Ihre HR-Organisation steht - nicht als theoretisches Modell, sondern als Arbeitsdokument für Ihr Team.
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8 mb-3">15 Fragen in 5 Dimensionen</h3>
<ul class="space-y-2 text-body text-gosign-text">
<li class="flex items-start gap-2"><span class="text-gosign-accent-text font-bold">1.</span> Prozessreife - Wie dokumentiert und konsistent sind Ihre HR-Prozesse?</li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text font-bold">2.</span> Governance - Wer ist verantwortlich für KI in HR?</li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text font-bold">3.</span> Datenlandschaft - Wie gut ist Ihre HR-Datenqualität?</li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text font-bold">4.</span> Mitbestimmung - Wie eingebunden ist der Betriebsrat?</li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text font-bold">5.</span> IT-Infrastruktur - Wie integriert ist Ihre HR-Systemlandschaft?</li>
</ul>

<h3 class="text-h3 font-bold text-gosign-dark mt-8 mb-3">Was das eBook vom Online-Tool unterscheidet</h3>
<div class="overflow-x-auto">
<table class="w-full text-body text-gosign-text border-collapse mt-4">
<thead><tr class="border-b-2 border-gosign-border"><th class="text-left py-2 pr-4 font-bold text-gosign-dark">Merkmal</th><th class="text-left py-2 pr-4 font-bold text-gosign-dark">Online (3 Min.)</th><th class="text-left py-2 font-bold text-gosign-dark">eBook (PDF)</th></tr></thead>
<tbody>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Fragen</td><td class="py-2 pr-4">7</td><td class="py-2">15</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Radar-Chart</td><td class="py-2 pr-4">Automatisch</td><td class="py-2">Zum Selbstzeichnen</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Team-Assessment</td><td class="py-2 pr-4">Nein</td><td class="py-2">Ja (4-5 Teilnehmer)</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Delta-Analyse</td><td class="py-2 pr-4">Nein</td><td class="py-2">Ja</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Druckbar</td><td class="py-2 pr-4">Nein</td><td class="py-2">Ja (A4 optimiert)</td></tr>
</tbody>
</table>
</div>
</div>

<div class="md:col-span-2">
<div class="sticky top-24 bg-gosign-light border border-gosign-border rounded-card p-6">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-3">Kostenloses PDF</p>
<p class="text-h3 font-bold text-gosign-dark mb-2">Assessment herunterladen</p>
<p class="text-small text-gosign-text-light mb-4">14 Seiten, Worksheets zum Ausfüllen, Team-Assessment mit Delta-Analyse.</p>
<a href="#download" class="block w-full text-center px-6 py-3 bg-gosign-accent-btn text-white font-semibold rounded-lg hover:bg-gosign-accent-btn-hover transition-colors" data-ebook-download>Assessment herunterladen</a>
<p class="text-xs text-gosign-text-light mt-3">Nur E-Mail-Adresse nötig. Sofort als PDF.</p>
</div>
</div>

</div>
</div>
</section>

<!-- Quick Check Verweis -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<div class="border-2 border-gosign-accent/20 rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Schnellcheck: Online-Assessment</p>
<p class="text-body text-gosign-text mb-4">Keine Zeit für das volle Assessment? Machen Sie zuerst den 3-Minuten-Schnellcheck mit 7 Fragen und automatischem Radar-Chart.</p>
<a href="/de/hr-agent-readiness/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Online-Assessment starten &rarr;</a>
</div>
</div>
</section>

<!-- Weitere eBooks -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Weitere eBooks</h2>
<div class="grid grid-cols-1 sm:grid-cols-2 gap-4">
<a href="/de/ebook/ki-hr-governance-handbuch/" class="block border border-gosign-border rounded-card p-4 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-1">HR Governance</p>
<p class="text-body font-semibold text-gosign-dark">KI in HR: Governance-Handbuch für den CHRO</p>
</a>
<a href="/de/ebook/hr-agent-readiness-assessment/" class="block border border-gosign-border rounded-card p-4 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-1">Finance Assessment</p>
<p class="text-body font-semibold text-gosign-dark">Finance Agent Readiness Assessment</p>
</a>
</div>
</div>
</section>

--- eBook: KI in Finance - Governance-Handbuch für den CFO ---
> Kostenloses eBook: EU AI Act, Wirtschaftsprüfer und Decision Layer - das Governance-Handbuch für Finance-Verantwortliche. Hochrisiko-Frist 2. August 2026, voraussichtlich verschoben auf Dezember 2027.

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">

<div class="grid md:grid-cols-5 gap-12 items-start">

<div class="md:col-span-3">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Was Sie in diesem Handbuch finden</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
Der EU AI Act stuft KI-gestützte Kreditentscheidungen als Hochrisiko ein (Annex III Nr. 5b). 73% der Organisationen haben noch kein Governance-Framework (ISACA 2024). Dieses Handbuch schließt die Lücke - mit Finance-spezifischen Frameworks, Checklisten und einem Readiness-Assessment.
</p>

<div class="space-y-4 mb-8">
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">1</span>
<div>
<p class="font-semibold text-gosign-dark">Warum der CFO AI-Governance in Finance führen muss - nicht IT</p>
<p class="text-small text-gosign-text-light">Governance-Ownership, Rollenkonzept und CFO-Checkliste.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">2</span>
<div>
<p class="font-semibold text-gosign-dark">Drei Arten von Finanzentscheidungen: Mensch, Regelwerk, KI</p>
<p class="text-small text-gosign-text-light">Das H/R/A-Framework mit Agent-Readiness-Score für jeden Finance-Prozess.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">3</span>
<div>
<p class="font-semibold text-gosign-dark">EU AI Act: Anforderungen für den Finanzbereich</p>
<p class="text-small text-gosign-text-light">Hochrisiko-Abgrenzung (Annex III Nr. 5b) mit Compliance-Checkliste.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">4</span>
<div>
<p class="font-semibold text-gosign-dark">Wirtschaftsprüfer als Governance-Partner</p>
<p class="text-small text-gosign-text-light">IDW PS 860, Auditor Portal, AI Literacy-Pflicht seit Februar 2025.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">5</span>
<div>
<p class="font-semibold text-gosign-dark">4 Finance-Prozesse im Decision Layer</p>
<p class="text-small text-gosign-text-light">Accounts Payable, Reisekosten, Financial Close, Fraud Detection - mit Automatisierungsraten.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">6</span>
<div>
<p class="font-semibold text-gosign-dark">Finance Readiness-Assessment (10 Fragen)</p>
<p class="text-small text-gosign-text-light">Wo steht Ihre Organisation? Self-Assessment mit Score und Handlungsempfehlung.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">7</span>
<div>
<p class="font-semibold text-gosign-dark">90-Tage-Plan für den Einstieg</p>
<p class="text-small text-gosign-text-light">Inventur, Design, Pilot - strukturiert in drei Monaten zum Decision Layer.</p>
</div>
</div>
</div>
</div>

<div class="md:col-span-2">
<div class="bg-gosign-light border border-gosign-border rounded-card p-6 sticky top-8">
<p class="text-h3 font-bold text-gosign-dark mb-2">Kostenlos herunterladen</p>
<p class="text-small text-gosign-text-light mb-4">PDF, 28 Seiten. Sofort per E-Mail.</p>

<div class="space-y-3 mb-6">
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>EU AI Act Compliance-Checkliste (Finance)</span>
</div>
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>H/R/A Decision-Framework</span>
</div>
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>Finance Readiness-Assessment zum Ausfüllen</span>
</div>
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>90-Tage-Implementierungsplan</span>
</div>
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>Wirtschaftsprüfer-Checkliste (IDW PS 860)</span>
</div>
</div>

<button data-ebook-download class="w-full px-6 py-3 bg-gosign-accent-btn text-white font-semibold rounded-md hover:bg-gosign-accent-btn-hover transition-colors text-sm flex items-center justify-center gap-2 cursor-pointer">
<svg class="w-5 h-5" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M4 16v1a3 3 0 003 3h10a3 3 0 003-3v-1m-4-4l-4 4m0 0l-4-4m4 4V4"/></svg>
PDF herunterladen
</button>
</div>
</div>

</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">5 Zahlen aus dem Handbuch</h2>

<div class="grid sm:grid-cols-2 lg:grid-cols-3 gap-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">5%</p>
<p class="text-small text-gosign-text">des Jahresumsatzes gehen Unternehmen weltweit durch Betrug verloren</p>
<p class="text-xs text-gosign-text-light mt-1">ACFE 2024</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">42%</p>
<p class="text-small text-gosign-text">aller Rechnungen in der Kreditorenbuchhaltung werden noch manuell verarbeitet</p>
<p class="text-xs text-gosign-text-light mt-1">Institute of Finance & Management 2024</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">88-95%</p>
<p class="text-small text-gosign-text">Automatisierungsrate mit Decision Layer in Finance-Prozessen</p>
<p class="text-xs text-gosign-text-light mt-1">Gosign Kundenprojekte</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">1:4-5</p>
<p class="text-small text-gosign-text">Investment-Ratio: 1 EUR Technologie = 4-5 EUR Governance</p>
<p class="text-xs text-gosign-text-light mt-1">McKinsey 2024</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">15 Mio.</p>
<p class="text-small text-gosign-text">EUR Maximalstrafe bei Verstoß gegen Hochrisiko-Pflichten</p>
<p class="text-xs text-gosign-text-light mt-1">EU AI Act, Art. 99</p>
</div>
</div>

</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Für wen ist dieses Handbuch?</h2>

<div class="grid sm:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">CFO / VP Finance</p>
<p class="text-small text-gosign-text-light">Sie verantworten die KI-Strategie im Finanzbereich und brauchen ein Framework, das Wirtschaftsprüfer, Legal und Vorstand gleichzeitig überzeugt.</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">Head of Finance / Leiter Rechnungswesen</p>
<p class="text-small text-gosign-text-light">Sie implementieren KI-gestützte Prozesse und brauchen klare Entscheidungsregeln: Was automatisieren, was nicht? Wie bleibt die Prüfungssicherheit erhalten?</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">Wirtschaftsprüfer / Interne Revision</p>
<p class="text-small text-gosign-text-light">Sie prüfen KI-gestützte Finanzprozesse und brauchen Transparenz: Welche Buchungen verarbeitet der Agent, welche der Mensch? Wie funktioniert der Audit Trail?</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">Finance Compliance / Legal</p>
<p class="text-small text-gosign-text-light">Sie müssen EU AI Act-Anforderungen für Finanzprozesse umsetzen und brauchen eine Compliance-Checkliste mit konkreten Maßnahmen und IKS-Integration.</p>
</div>
</div>

</div>
</section>

<section class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-12 border-t border-gosign-border">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Weitere eBooks</h2>
<div class="grid grid-cols-1 md:grid-cols-2 gap-6">

<div class="bg-white border border-gosign-border rounded-card p-5">
<p class="font-semibold text-gosign-dark mb-1">KI in HR - Governance-Handbuch</p>
<p class="text-small text-gosign-text-light mb-3">Für CHROs & HR-Verantwortliche</p>
<a href="/de/ebook/ki-hr-governance-handbuch/" class="text-sm text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Kostenlos herunterladen</a>
</div>

<div class="bg-white border border-gosign-border rounded-card p-5">
<p class="font-semibold text-gosign-dark mb-1">AI Infrastructure - Governance-Handbuch</p>
<p class="text-small text-gosign-text-light mb-3">Für CTOs & IT-Leitung</p>
<a href="/de/ebook/ki-infrastructure-governance-handbuch/" class="text-sm text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Kostenlos herunterladen</a>
</div>

<a href="/de/ebook/finance-agent-readiness-assessment/" class="block border border-gosign-border rounded-card p-4 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-1">Finance Assessment</p>
<p class="text-body font-semibold text-gosign-dark">Finance Agent Readiness Assessment</p>
<p class="text-small text-gosign-text-light mt-1">15 Fragen für CFO und Wirtschaftsprüfer</p>
</a>

</div>
</section>

--- eBook: KI in HR - Governance-Handbuch für den CHRO ---
> Kostenloses eBook: EU AI Act, Betriebsrat und Decision Layer - das Governance-Handbuch für HR-Verantwortliche. Hochrisiko-Frist 2. August 2026, voraussichtlich verschoben auf Dezember 2027.

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">

<div class="grid md:grid-cols-5 gap-12 items-start">

<div class="md:col-span-3">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Was Sie in diesem Handbuch finden</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
Der EU AI Act stuft KI-Systeme in HR als Hochrisiko ein; die zugehörigen Pflichten gelten nach aktuellem Recht ab dem 2. August 2026, voraussichtlich verschoben auf Dezember 2027 (Digital Omnibus, Mai 2026). 73% der Organisationen haben noch kein Governance-Framework (ISACA 2024). Dieses Handbuch schließt die Lücke - mit konkreten Frameworks, Checklisten und einem Readiness-Assessment.
</p>

<div class="space-y-4 mb-8">
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">1</span>
<div>
<p class="font-semibold text-gosign-dark">Warum der CHRO AI-Governance in HR führen muss - nicht IT</p>
<p class="text-small text-gosign-text-light">Governance-Ownership, Rollenkonzept und CHRO-Checkliste.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">2</span>
<div>
<p class="font-semibold text-gosign-dark">Drei Arten von Entscheidungen: Mensch, Regelwerk, KI</p>
<p class="text-small text-gosign-text-light">Das Decision-Framework mit Agent-Readiness-Score für jeden HR-Prozess.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">3</span>
<div>
<p class="font-semibold text-gosign-dark">EU AI Act: 6 Pflichtanforderungen im Detail</p>
<p class="text-small text-gosign-text-light">Art. 9-15 mit Compliance-Checkliste zum Abhaken.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">4</span>
<div>
<p class="font-semibold text-gosign-dark">Betriebsrat als Design-Partner einbinden</p>
<p class="text-small text-gosign-text-light">Mitbestimmungsrechte, Betriebsvereinbarung als technischer Constraint, AI Literacy.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">5</span>
<div>
<p class="font-semibold text-gosign-dark">4 HR-Prozesse im Decision Layer</p>
<p class="text-small text-gosign-text-light">Payroll, Reisekosten, Recruiting, Leave & Absence - mit Automatisierungsraten.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">6</span>
<div>
<p class="font-semibold text-gosign-dark">Readiness-Assessment (10 Fragen)</p>
<p class="text-small text-gosign-text-light">Wo steht Ihre Organisation? Self-Assessment mit Score und Handlungsempfehlung.</p>
</div>
</div>
</div>
</div>

<div class="md:col-span-2">
<div class="bg-gosign-light border border-gosign-border rounded-card p-6 sticky top-8">
<p class="text-h3 font-bold text-gosign-dark mb-2">Kostenlos herunterladen</p>
<p class="text-small text-gosign-text-light mb-4">PDF, 25 Seiten. Sofort per E-Mail.</p>

<div class="space-y-3 mb-6">
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>EU AI Act Compliance-Checkliste</span>
</div>
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>Decision-Framework (H/R/A)</span>
</div>
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>Readiness-Assessment zum Ausfüllen</span>
</div>
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>90-Tage-Implementierungsplan</span>
</div>
</div>

<button data-ebook-download class="w-full px-6 py-3 bg-gosign-accent-btn text-white font-semibold rounded-md hover:bg-gosign-accent-btn-hover transition-colors text-sm flex items-center justify-center gap-2 cursor-pointer">
<svg class="w-5 h-5" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M4 16v1a3 3 0 003 3h10a3 3 0 003-3v-1m-4-4l-4 4m0 0l-4-4m4 4V4"/></svg>
PDF herunterladen
</button>
</div>
</div>

</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">5 Zahlen aus dem Handbuch</h2>

<div class="grid sm:grid-cols-2 lg:grid-cols-3 gap-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">73%</p>
<p class="text-small text-gosign-text">der Organisationen ohne formales KI-Governance-Framework</p>
<p class="text-xs text-gosign-text-light mt-1">ISACA 2024</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">6</p>
<p class="text-small text-gosign-text">Pflichtanforderungen für HR-Hochrisiko-KI (Frist 2. August 2026, voraussichtlich Dez. 2027)</p>
<p class="text-xs text-gosign-text-light mt-1">EU AI Act, Art. 9-15</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">85-92%</p>
<p class="text-small text-gosign-text">Automatisierungsrate mit Decision Layer in HR-Prozessen</p>
<p class="text-xs text-gosign-text-light mt-1">Gosign Kundenprojekte</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">1:4-5</p>
<p class="text-small text-gosign-text">Investment-Ratio: 1 EUR Technologie = 4-5 EUR Governance</p>
<p class="text-xs text-gosign-text-light mt-1">McKinsey 2024</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">60-80%</p>
<p class="text-small text-gosign-text">weniger Korrekturbuchungen durch explizite Regelwerke</p>
<p class="text-xs text-gosign-text-light mt-1">Hackett Group 2024</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">15 Mio.</p>
<p class="text-small text-gosign-text">EUR Maximalstrafe bei Verstoß gegen Hochrisiko-Pflichten</p>
<p class="text-xs text-gosign-text-light mt-1">EU AI Act, Art. 99</p>
</div>
</div>

</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Für wen ist dieses Handbuch?</h2>

<div class="grid sm:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">CHRO / VP HR</p>
<p class="text-small text-gosign-text-light">Sie verantworten die KI-Strategie in HR und brauchen ein Framework, das Betriebsrat, Legal und Vorstand gleichzeitig überzeugt.</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">Head of People Operations</p>
<p class="text-small text-gosign-text-light">Sie implementieren KI-gestützte Prozesse und brauchen klare Entscheidungsregeln: Was automatisieren, was nicht?</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">Betriebsrat / Personalvertretung</p>
<p class="text-small text-gosign-text-light">Sie prüfen KI-Einsatz in HR und brauchen Transparenz: Welche Entscheidungen trifft der Agent, welche der Mensch?</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">HR Compliance / Legal</p>
<p class="text-small text-gosign-text-light">Sie müssen EU AI Act-Anforderungen umsetzen und brauchen eine Compliance-Checkliste mit konkreten Maßnahmen.</p>
</div>
</div>

</div>
</section>

<section class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-12 border-t border-gosign-border">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Weitere eBooks</h2>
<div class="grid grid-cols-1 md:grid-cols-2 gap-6">

<div class="bg-white border border-gosign-border rounded-card p-5">
<p class="font-semibold text-gosign-dark mb-1">KI in Finance - Governance-Handbuch</p>
<p class="text-small text-gosign-text-light mb-3">Für CFOs & Finance-Leitung</p>
<a href="/de/ebook/ki-finance-governance-handbuch/" class="text-sm text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Kostenlos herunterladen</a>
</div>

<div class="bg-white border border-gosign-border rounded-card p-5">
<p class="font-semibold text-gosign-dark mb-1">AI Infrastructure - Governance-Handbuch</p>
<p class="text-small text-gosign-text-light mb-3">Für CTOs & IT-Leitung</p>
<a href="/de/ebook/ki-infrastructure-governance-handbuch/" class="text-sm text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Kostenlos herunterladen</a>
</div>

<a href="/de/ebook/hr-agent-readiness-assessment/" class="block border border-gosign-border rounded-card p-4 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-1">HR Assessment</p>
<p class="text-body font-semibold text-gosign-dark">HR Agent Readiness Assessment</p>
<p class="text-small text-gosign-text-light mt-1">15 Fragen für Ihr Führungsteam</p>
</a>

</div>
</section>

--- eBook: AI Infrastructure - Governance-Handbuch für den CTO ---
> Kostenloses eBook: Build, Buy, Hybrid - EU AI Act-konforme KI-Infrastruktur. Das Governance-Handbuch für CTOs und Heads of Infrastructure.

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">

<div class="grid md:grid-cols-5 gap-12 items-start">

<div class="md:col-span-3">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Was Sie in diesem Handbuch finden</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
Laut Gartner (2024) werden Unternehmen bis 2027 über 644 Mrd. USD für KI-Infrastruktur ausgeben. Gleichzeitig verschwenden sie 28% der Cloud-Ausgaben (Flexera 2024). Dieses Handbuch zeigt, wie Sie KI-Infrastruktur governance-konform, kosteneffizient und EU AI Act-compliant aufbauen.
</p>

<div class="space-y-4 mb-8">
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">1</span>
<div>
<p class="font-semibold text-gosign-dark">Warum der CTO AI Infrastructure Governance führen muss</p>
<p class="text-small text-gosign-text-light">Shadow AI, Governance-Lücke und die CTO-Checkliste für den Start.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">2</span>
<div>
<p class="font-semibold text-gosign-dark">Build, Buy, Hybrid: das B/B/H-Framework</p>
<p class="text-small text-gosign-text-light">Entscheidungsmatrix nach Workload-Typ mit Hidden Costs und Hidden Risks.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">3</span>
<div>
<p class="font-semibold text-gosign-dark">EU AI Act: 6 technische Anforderungen (Art. 9-15)</p>
<p class="text-small text-gosign-text-light">Compliance-Pflichten als Infrastruktur-Entscheidungen mit technischer Checkliste.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">4</span>
<div>
<p class="font-semibold text-gosign-dark">Security & Data Sovereignty</p>
<p class="text-small text-gosign-text-light">Data Residency, Encryption, Zero Trust Architecture und DSGVO-Compliance bei LLM-Nutzung.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">5</span>
<div>
<p class="font-semibold text-gosign-dark">4 Infrastruktur-Patterns in Produktion</p>
<p class="text-small text-gosign-text-light">Agent Orchestration, Document Intelligence, Model Gateway, Monitoring & Observability.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">6</span>
<div>
<p class="font-semibold text-gosign-dark">Infrastructure Readiness Assessment (10 Fragen)</p>
<p class="text-small text-gosign-text-light">Wo steht Ihre Infrastruktur? Self-Assessment mit Score und 90-Tage-Plan.</p>
</div>
</div>
</div>
</div>

<div class="md:col-span-2">
<div class="bg-gosign-light border border-gosign-border rounded-card p-6 sticky top-8">
<p class="text-h3 font-bold text-gosign-dark mb-2">Kostenlos herunterladen</p>
<p class="text-small text-gosign-text-light mb-4">PDF, 28 Seiten. Sofort per E-Mail.</p>

<div class="space-y-3 mb-6">
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>Build/Buy/Hybrid-Entscheidungsmatrix</span>
</div>
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>EU AI Act Compliance-Checkliste (technisch)</span>
</div>
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>4 Production-Ready Infrastruktur-Patterns</span>
</div>
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>Infrastructure Readiness Assessment + 90-Tage-Plan</span>
</div>
</div>

<button data-ebook-download class="w-full px-6 py-3 bg-gosign-accent-btn text-white font-semibold rounded-md hover:bg-gosign-accent-btn-hover transition-colors text-sm flex items-center justify-center gap-2 cursor-pointer">
<svg class="w-5 h-5" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M4 16v1a3 3 0 003 3h10a3 3 0 003-3v-1m-4-4l-4 4m0 0l-4-4m4 4V4"/></svg>
PDF herunterladen
</button>
</div>
</div>

</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">5 Zahlen aus dem Handbuch</h2>

<div class="grid sm:grid-cols-2 lg:grid-cols-3 gap-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">644 Mrd.</p>
<p class="text-small text-gosign-text">USD globale KI-Infrastruktur-Ausgaben bis 2027</p>
<p class="text-xs text-gosign-text-light mt-1">Gartner 2024</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">28%</p>
<p class="text-small text-gosign-text">der Cloud-Ausgaben verschwendet durch fehlende Governance</p>
<p class="text-xs text-gosign-text-light mt-1">Flexera 2024</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">82%</p>
<p class="text-small text-gosign-text">betreiben Multi-Cloud ohne zentrale KI-Governance</p>
<p class="text-xs text-gosign-text-light mt-1">HashiCorp 2024</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">40%</p>
<p class="text-small text-gosign-text">der Sicherheitsvorfälle durch falsch konfigurierte Cloud-Dienste</p>
<p class="text-xs text-gosign-text-light mt-1">ENISA 2024</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">15 Mio.</p>
<p class="text-small text-gosign-text">EUR Maximalstrafe bei Verstoß gegen Hochrisiko-Pflichten</p>
<p class="text-xs text-gosign-text-light mt-1">EU AI Act, Art. 99</p>
</div>
</div>

</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Für wen ist dieses Handbuch?</h2>

<div class="grid sm:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">CTO / VP Engineering</p>
<p class="text-small text-gosign-text-light">Sie verantworten die KI-Infrastruktur-Strategie und brauchen ein Framework, das Skalierbarkeit, Compliance und Cost Governance vereint.</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">Head of Infrastructure / Platform</p>
<p class="text-small text-gosign-text-light">Sie bauen die Plattform für KI-Workloads und brauchen Production-Ready Patterns: Agent Orchestration, Model Gateway, Document Intelligence.</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">Cloud Architect / DevOps Lead</p>
<p class="text-small text-gosign-text-light">Sie entscheiden Build vs. Buy und brauchen die Entscheidungsmatrix: Welcher Workload selbst hosten, welcher als Managed Service?</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">CISO / Head of Security</p>
<p class="text-small text-gosign-text-light">Sie müssen Data Sovereignty sicherstellen und brauchen den Security-Stack: Zero Trust, PII-Screening, Encryption, Supply Chain Security.</p>
</div>
</div>

</div>
</section>

<section class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-12 border-t border-gosign-border">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Weitere eBooks</h2>
<div class="grid grid-cols-1 md:grid-cols-2 gap-6">

<div class="bg-white border border-gosign-border rounded-card p-5">
<p class="font-semibold text-gosign-dark mb-1">KI in HR - Governance-Handbuch</p>
<p class="text-small text-gosign-text-light mb-3">Für CHROs & HR-Verantwortliche</p>
<a href="/de/ebook/ki-hr-governance-handbuch/" class="text-sm text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Kostenlos herunterladen</a>
</div>

<div class="bg-white border border-gosign-border rounded-card p-5">
<p class="font-semibold text-gosign-dark mb-1">KI in Finance - Governance-Handbuch</p>
<p class="text-small text-gosign-text-light mb-3">Für CFOs & Finance-Leitung</p>
<a href="/de/ebook/ki-finance-governance-handbuch/" class="text-sm text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Kostenlos herunterladen</a>
</div>

<a href="/de/ebook/hr-agent-readiness-assessment/" class="block border border-gosign-border rounded-card p-4 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-1">HR Assessment</p>
<p class="text-body font-semibold text-gosign-dark">HR Agent Readiness Assessment</p>
<p class="text-small text-gosign-text-light mt-1">15 Fragen für Ihr Führungsteam</p>
</a>

<a href="/de/ebook/finance-agent-readiness-assessment/" class="block border border-gosign-border rounded-card p-4 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-1">Finance Assessment</p>
<p class="text-body font-semibold text-gosign-dark">Finance Agent Readiness Assessment</p>
<p class="text-small text-gosign-text-light mt-1">15 Fragen für CFO und Wirtschaftsprüfer</p>
</a>

</div>
</section>

--- Erstbewertung AI Agent Adoption - 9 Slides für Ihr Führungsteam ---
> Kostenlose Erstbewertung: 9 Slides zur AI Agent Adoption mit Branchenbenchmarks, Risikoprofil und Diskussionsvorschlag. PPTX direkt im Browser generiert.

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">

<div class="grid md:grid-cols-5 gap-12 items-start">

<div class="md:col-span-3">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Was Sie in dieser Erstbewertung finden</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
30-40% der KI-Projekte scheitern nicht an der Technologie, sondern an fehlender Governance und unklaren Entscheidungsstrukturen (Gartner 2024). Diese Erstbewertung gibt Ihrem Führungsteam eine fundierte Diskussionsgrundlage - mit konkreten Branchenbenchmarks statt vager Versprechen.
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8 mb-3">9 Slides im Überblick</h3>
<ol class="space-y-2 text-body text-gosign-text list-decimal list-inside">
<li><strong>Executive Summary</strong> - Kernaussage, Benchmark-Investition, erwartete Einsparungen</li>
<li><strong>Ausgangslage</strong> - Handlungsdruck und Branchenkontext</li>
<li><strong>Decision Layer</strong> - Der Kontrollmechanismus: Mensch, Regelwerk, KI</li>
<li><strong>Readiness Assessment</strong> - Wo steht Ihre Organisation?</li>
<li><strong>Governance und Compliance</strong> - EU AI Act, Betriebsrat, regulatorischer Rahmen</li>
<li><strong>Roadmap</strong> - Prove, Expand, Scale in 18 Monaten</li>
<li><strong>Risk Matrix</strong> - Risikoanalyse mit Mitigationsstrategien</li>
<li><strong>Financial Model</strong> - Benchmark-basierte Bandbreiten mit ROI-Berechnung</li>
<li><strong>Diskussionsvorschlag</strong> - Nächste Schritte zur Evaluierung</li>
</ol>

<h3 class="text-h3 font-bold text-gosign-dark mt-8 mb-3">Ohne Erstbewertung vs. Mit Erstbewertung</h3>
<div class="overflow-x-auto">
<table class="w-full text-body text-gosign-text border-collapse mt-4">
<thead><tr class="border-b-2 border-gosign-border"><th class="text-left py-2 pr-4 font-bold text-gosign-dark">Kriterium</th><th class="text-left py-2 pr-4 font-bold text-gosign-dark">Ohne Erstbewertung</th><th class="text-left py-2 font-bold text-gosign-dark">Mit Erstbewertung</th></tr></thead>
<tbody>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Vorbereitungszeit</td><td class="py-2 pr-4">2-3 Wochen</td><td class="py-2">2 Minuten im Browser</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Governance-Argumentation</td><td class="py-2 pr-4">Selbst recherchieren</td><td class="py-2">Decision Layer, EU AI Act, Betriebsrat fertig aufbereitet</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Financial Model</td><td class="py-2 pr-4">Von Null aufbauen</td><td class="py-2">Branchenbenchmarks mit Bandbreiten</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Diskussionsgrundlage</td><td class="py-2 pr-4">Unstrukturiert</td><td class="py-2">9 Slides mit klaren nächsten Schritten</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Datenschutz</td><td class="py-2 pr-4">Cloud-Upload nötig</td><td class="py-2">100% lokal im Browser, kein Upload</td></tr>
</tbody>
</table>
</div>
</div>

<div class="md:col-span-2">
<div class="sticky top-24 bg-gosign-light border border-gosign-border rounded-card p-6">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-3">Kostenlos, 100% lokal</p>
<p class="text-h3 font-bold text-gosign-dark mb-2">Erstbewertung generieren</p>
<p class="text-small text-gosign-text-light mb-4">9 Slides mit Branchenbenchmarks. Direkt im Browser als PPTX generiert.</p>
<a href="/de/hr-agent-katalog/" class="block w-full text-center px-6 py-3 bg-gosign-accent-btn text-white font-semibold rounded-lg hover:bg-gosign-accent-btn-hover transition-colors">Zum Agent-Katalog</a>
<p class="text-xs text-gosign-text-light mt-3">Wählen Sie einen Agenten - die Erstbewertung wird auf jeder Detailseite generiert.</p>
</div>
</div>

</div>
</div>
</section>

<!-- Schnellcheck -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<div class="border-2 border-gosign-accent/20 rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Schnellcheck: Readiness Assessment</p>
<p class="text-body text-gosign-text mb-4">Noch nicht sicher, ob Ihre Organisation bereit für AI Agents ist? Machen Sie zuerst den 3-Minuten-Schnellcheck. Die Ergebnisse ergänzen die Erstbewertung.</p>
<a href="/de/hr-agent-readiness/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Online-Assessment starten &rarr;</a>
</div>
</div>
</section>

<!-- Weitere eBooks -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Weitere eBooks</h2>
<div class="grid grid-cols-1 sm:grid-cols-2 gap-4">
<a href="/de/ebook/ki-hr-governance-handbuch/" class="block border border-gosign-border rounded-card p-4 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-1">HR Governance</p>
<p class="text-body font-semibold text-gosign-dark">KI in HR: Governance-Handbuch für den CHRO</p>
</a>
<a href="/de/ebook/hr-agent-readiness-assessment/" class="block border border-gosign-border rounded-card p-4 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-1">Assessment</p>
<p class="text-body font-semibold text-gosign-dark">HR Agent Readiness Assessment - 15 Fragen</p>
</a>
</div>
</div>
</section>

--- Kostenlose eBooks - AI Governance Handbücher ---
> Kostenlose Governance-Handbücher für HR, Finance und Infrastructure. EU AI Act Compliance, Decision Layer, Readiness-Assessments.

<section class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-12">
<div class="grid grid-cols-1 md:grid-cols-3 gap-8">

<div class="bg-white border border-gosign-border rounded-card p-6 flex flex-col">
<div class="w-12 h-12 rounded-full bg-orange-50 flex items-center justify-center mb-4">
<svg class="w-6 h-6 text-gosign-accent" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M17 20h5v-2a3 3 0 00-5.356-1.857M17 20H7m10 0v-2c0-.656-.126-1.283-.356-1.857M7 20H2v-2a3 3 0 015.356-1.857M7 20v-2c0-.656.126-1.283.356-1.857m0 0a5.002 5.002 0 019.288 0M15 7a3 3 0 11-6 0 3 3 0 016 0z"></path></svg>
</div>
<h2 class="text-h3 font-bold text-gosign-dark mb-2">KI in HR</h2>
<p class="text-body text-gosign-text mb-3 flex-1">EU AI Act Checkliste, Decision-Framework, Betriebsrats-Perspektive und Readiness-Assessment - das Governance-Handbuch für den CHRO.</p>
<p class="text-small text-gosign-text-light mb-4">Für CHROs & HR-Verantwortliche - 25 Seiten</p>
<a href="/de/ebook/ki-hr-governance-handbuch/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Kostenlos herunterladen</a>
</div>

<div class="bg-white border border-gosign-border rounded-card p-6 flex flex-col">
<div class="w-12 h-12 rounded-full bg-orange-50 flex items-center justify-center mb-4">
<svg class="w-6 h-6 text-gosign-accent" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 7h6m0 10v-3m-3 3h.01M9 17h.01M9 14h.01M12 14h.01M15 11h.01M12 11h.01M9 11h.01M7 21h10a2 2 0 002-2V5a2 2 0 00-2-2H7a2 2 0 00-2 2v14a2 2 0 002 2z"></path></svg>
</div>
<h2 class="text-h3 font-bold text-gosign-dark mb-2">KI in Finance</h2>
<p class="text-body text-gosign-text mb-3 flex-1">Compliance, Wirtschaftsprüfer und Decision Layer - das Governance-Handbuch für den CFO. Mit H/R/A-Framework und Finance-spezifischem Readiness-Assessment.</p>
<p class="text-small text-gosign-text-light mb-4">Für CFOs & Finance-Leitung - 28 Seiten</p>
<a href="/de/ebook/ki-finance-governance-handbuch/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Kostenlos herunterladen</a>
</div>

<div class="bg-white border border-gosign-border rounded-card p-6 flex flex-col">
<div class="w-12 h-12 rounded-full bg-orange-50 flex items-center justify-center mb-4">
<svg class="w-6 h-6 text-gosign-accent" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M5 12h14M5 12a2 2 0 01-2-2V6a2 2 0 012-2h14a2 2 0 012 2v4a2 2 0 01-2 2M5 12a2 2 0 00-2 2v4a2 2 0 002 2h14a2 2 0 002-2v-4a2 2 0 00-2-2m-2-4h.01M17 16h.01"></path></svg>
</div>
<h2 class="text-h3 font-bold text-gosign-dark mb-2">AI Infrastructure</h2>
<p class="text-body text-gosign-text mb-3 flex-1">Build, Buy, Hybrid - EU AI Act-konforme Infrastruktur. Mit B/B/H-Framework, 7-Layer Reference Architecture und CTO-Checkliste.</p>
<p class="text-small text-gosign-text-light mb-4">Für CTOs & IT-Leitung - 28 Seiten</p>
<a href="/de/ebook/ki-infrastructure-governance-handbuch/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Kostenlos herunterladen</a>
</div>

</div>

<h2 class="text-h2 font-bold text-gosign-dark mt-12 mb-6">Readiness Assessments</h2>
<p class="text-body text-gosign-text-light mb-8">Wie bereit ist Ihre Organisation für AI Agents? 15 Fragen, Worksheets zum Ausfüllen, Team-Assessment mit Delta-Analyse.</p>

<div class="grid grid-cols-1 md:grid-cols-2 gap-8">

<div class="bg-white border-2 border-gosign-accent/20 rounded-card p-6 flex flex-col">
<div class="w-12 h-12 rounded-full bg-orange-50 flex items-center justify-center mb-4">
<svg class="w-6 h-6 text-gosign-accent" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 5H7a2 2 0 00-2 2v12a2 2 0 002 2h10a2 2 0 002-2V7a2 2 0 00-2-2h-2M9 5a2 2 0 002 2h2a2 2 0 002-2M9 5a2 2 0 012-2h2a2 2 0 012 2m-6 9l2 2 4-4"></path></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">HR Agent Readiness</h3>
<p class="text-body text-gosign-text mb-3 flex-1">15 Fragen für Ihr Führungsteam. Prozessreife, Governance, Datenlandschaft, Mitbestimmung, IT-Infrastruktur.</p>
<p class="text-small text-gosign-text-light mb-4">Für CHROs & HR-Führungsteam - 14 Seiten</p>
<a href="/de/ebook/hr-agent-readiness-assessment/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Assessment herunterladen</a>
</div>

<div class="bg-white border-2 border-gosign-accent/20 rounded-card p-6 flex flex-col">
<div class="w-12 h-12 rounded-full bg-orange-50 flex items-center justify-center mb-4">
<svg class="w-6 h-6 text-gosign-accent" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 5H7a2 2 0 00-2 2v12a2 2 0 002 2h10a2 2 0 002-2V7a2 2 0 00-2-2h-2M9 5a2 2 0 002 2h2a2 2 0 002-2M9 5a2 2 0 012-2h2a2 2 0 012 2m-6 9l2 2 4-4"></path></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Finance Agent Readiness</h3>
<p class="text-body text-gosign-text mb-3 flex-1">15 Fragen für CFO und Wirtschaftsprüfer. GoBD-Check, §203-Bewertung, ERP-Landschaft, Abschlussgeschwindigkeit.</p>
<p class="text-small text-gosign-text-light mb-4">Für CFOs & Finance-Führungsteam - 14 Seiten</p>
<a href="/de/ebook/finance-agent-readiness-assessment/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Assessment herunterladen</a>
</div>

</div>

<h2 class="text-h2 font-bold text-gosign-dark mt-12 mb-6">Erstbewertung für Ihr Führungsteam</h2>
<p class="text-body text-gosign-text-light mb-8">9 Slides als Diskussionsgrundlage. Branchenbenchmarks, Risikoprofil, Roadmap. Kostenlos als PPTX direkt im Browser generiert.</p>

<div class="grid grid-cols-1 md:grid-cols-1 gap-8 max-w-lg">
<div class="bg-gosign-dark rounded-card p-6 flex flex-col">
<div class="w-12 h-12 rounded-full bg-white/10 flex items-center justify-center mb-4">
<svg class="w-6 h-6 text-gosign-accent-on-dark" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M7 21h10a2 2 0 002-2V9.414a1 1 0 00-.293-.707l-5.414-5.414A1 1 0 0012.586 3H7a2 2 0 00-2 2v14a2 2 0 002 2z"></path></svg>
</div>
<h3 class="text-h3 font-bold text-white mb-2">AI Agent Adoption - Erstbewertung</h3>
<p class="text-body text-white/70 mb-3 flex-1">Executive Summary, Decision Layer, Governance, Betriebsrat-Strategie, Risikomatrix, Financial Model, Roadmap, Diskussionsvorschlag.</p>
<p class="text-small text-white/50 mb-4">Für CHROs, CFOs & Führungsteam - 18 Seiten</p>
<a href="/de/ebook/vorstandsvorlage-ai-agent-adoption/" class="inline-flex items-center gap-2 text-gosign-accent-on-dark hover:text-white font-medium">Vorlage herunterladen</a>
</div>
</div>

<h2 class="text-h2 font-bold text-gosign-dark mt-12 mb-6">Online-Schnellcheck</h2>
<p class="text-body text-gosign-text-light mb-8">Keine Zeit für das volle 15-Fragen-Assessment? Der Online-Schnellcheck dauert 3 Minuten - mit automatischem Radar-Chart und Agent-Empfehlungen.</p>

<div class="grid grid-cols-1 md:grid-cols-2 gap-8">
<a href="/de/hr-agent-readiness/" class="block bg-gosign-dark rounded-card p-6 hover:bg-gosign-dark/90 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">3 Minuten, 7 Fragen</p>
<p class="text-h3 font-bold text-white">HR Agent Readiness</p>
<p class="text-body text-white/70 mt-2">Reifegrad, Radar-Chart und Empfehlungen aus dem 48-Agenten-Katalog.</p>
</a>
<a href="/de/finance-agent-readiness/" class="block bg-gosign-dark rounded-card p-6 hover:bg-gosign-dark/90 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">3 Minuten, 7 Fragen</p>
<p class="text-h3 font-bold text-white">Finance Agent Readiness</p>
<p class="text-body text-white/70 mt-2">Reifegrad, Radar-Chart und Empfehlungen aus dem 49-Agenten-Katalog.</p>
</a>
</div>

</section>

--- Fakten - Gosign in Zahlen ---
> Zitierfähige Fakten über Gosign GmbH. Unternehmensdaten, Standorte, Zertifizierungen und Compliance-Standards auf einen Blick.

<article class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<div class="prose prose-lg prose-headings:text-gosign-dark prose-headings:font-bold prose-h2:text-h2 prose-h2:mt-12 prose-h2:mb-4 prose-h3:text-h3 prose-h3:mt-8 prose-h3:mb-3 prose-p:text-gosign-text prose-p:leading-relaxed prose-a:text-gosign-accent-text prose-a:underline prose-a:decoration-gosign-accent-text/30 hover:prose-a:decoration-gosign-accent-text prose-strong:text-gosign-dark prose-ul:text-gosign-text prose-ol:text-gosign-text">

## Unternehmen

Gosign GmbH. Softwareentwicklungsunternehmen, gegründet 2001 in Hamburg. Inhabergeführt. Geschäftsführer: Bert Gogolin und Dieter Gogolin. Hallerstraße 8, 20146 Hamburg. Handelsregister Hamburg HRB 112197. USt-IdNr.: DE215891388.

## Kennzahlen

108 Mitarbeiter. Über 5.000 Projekte seit 2001. 25 Jahre Softwareentwicklung. Seit 2023 fokussiert auf Enterprise AI Infrastructure und Agent Engineering. Referenzkunden: Airbus, Volkswagen, Shell, Evonik, Sony.

## Standorte

Hamburg (Hauptsitz), Krakau, Barcelona, Lissabon, São Paulo. Entwicklungszentrum in Pakistan seit 2002.

## Sprachen

Deutsch, Englisch, Polnisch, Spanisch, Portugiesisch, Urdu.

## Mitgliedschaften und Zertifizierungen

Mitglied im BVDW (Bundesverband Digitale Wirtschaft). AI Engineers mit Microsoft Azure AI Zertifizierung.

## Compliance-Standards

Cert-Ready by Design: ISA, PS 951, IDW, GoB/GoBD. EU AI Act Readiness: Risikoklassifikation und Dokumentationspflichten in der Agentenarchitektur integriert. Data Residency: Datenverarbeitung in der Infrastruktur des Kunden - Azure EU, GCP EU, AWS EU, Self-Hosted oder Hybrid. Der Kunde entscheidet über Region und Hosting-Modell. DPAs mit allen Subprozessoren. Für vollständige Cloud-Act-Freiheit: Self-Hosted in einem EU-Rechenzentrum oder auf eigenen Servern. DSGVO: Keine Cookies, keine Tracker, keine externen Embeds auf gosign.de. Webanalyse cookieless und aggregiert.

## Kontakt

Gosign GmbH · Hallerstraße 8 · 20146 Hamburg
→ [Kontakt aufnehmen](/de/kontakt/)

</div>
</div>
</article>

--- Kontierungs-Agent ---
> Ordnet eingehende Rechnungen dem richtigen Sachkonto, der korrekten Kostenstelle und dem passenden Steuercode.

## Falsche Kontierung kostet bei jeder Betriebsprüfung fünfstellig

Kleinst- bis Mittelbetriebe zahlen nach einer Betriebsprüfung im Durchschnitt 24.000 EUR nach. Bei Umsatzsteuer-Sonderprüfungen steigt dieser Wert auf rund 25.000 EUR pro Betrieb. In über der Hälfte aller Prüfungen kommt es zu Nachforderungen. Die häufigste Ursache: fehlerhafte Kontierung. Falsches Sachkonto bedeutet falscher Steuerausweis. Falscher Steuerausweis bedeutet versagter Vorsteuerabzug. Versagter Vorsteuerabzug über mehrere Jahre summiert sich schnell in den sechsstelligen Bereich.

Das Problem ist nicht Nachlässigkeit. Ein Unternehmen mit 10.000 Eingangsrechnungen pro Monat trifft 10.000 Kontierungsentscheidungen - jeden Monat. Bei manueller Verarbeitung liegt die Fehlerquote laut Institute of Finance and Management (IOFM) bei rund 2 %. Das sind 200 Rechnungen monatlich, bei denen Sachkonto, Kostenstelle oder Steuercode nicht stimmen. Jede einzelne ist ein Befund, den ein Betriebsprüfer aufgreifen kann.

## Zehn Entscheidungen pro Rechnung - jede mit steuerlicher Wirkung

Kontierung wird häufig als Erfassungsschritt behandelt. In Wirklichkeit ist sie eine Kette von zehn Einzelentscheidungen, die jeweils unterschiedliche Rechtsfolgen auslösen.

Ein Beispiel aus dem Alltag: Eine Rechnung über Beratungsleistungen eines EU-Dienstleisters geht ein. Die Buchhaltung muss entscheiden: Welches Sachkonto? Welche Kostenstelle? Welches Profit Center? Reverse Charge nach §13b UStG oder reguläre Umsatzsteuer? Vorsteuerabzug zulässig? Liegt der Betrag über der GWG-Grenze? Muss periodengerecht abgegrenzt werden? Erst wenn alle Teilentscheidungen korrekt sind, stimmt der Buchungssatz.

Jede dieser Entscheidungen folgt einer eigenen Logik. Die Sachkonto-Zuordnung ergibt sich aus der Leistungsbeschreibung und dem Kontenplan. Der Steuercode folgt dem UStG. Die Aktivierungspflicht folgt HGB und EStG. Wer eine Entscheidung isoliert betrachtet, übersieht die Wechselwirkungen. Wer sie als Ganzes manuell trifft, braucht Erfahrung, Konzentration und Zeit - bei jeder einzelnen Rechnung.

## Regelbasiert kontieren, nur Interpretationsfälle eskalieren

Der [Decision Layer](/de/decision-layer/) zerlegt jeden Kontierungsprozess in diese zehn Entscheidungsschritte und definiert für jeden: Regelwerk, KI oder Mensch. Bei der Kontierung fällt die Verteilung deutlich aus. Neun von zehn Schritten sind regelbasiert lösbar. Steuercode-Bestimmung nach UStG, Vorsteuerabzugsprüfung nach §15, GWG-Schwellenwerte nach EStG §6 Abs. 2, Periodenabgrenzung nach HGB §250 - das sind deterministische Entscheidungen mit eindeutigem Ergebnis.

Der eine Schritt, der KI-Unterstützung braucht, ist die Interpretation. Wenn die Leistungsbeschreibung auf einer Rechnung lautet "Projektunterstützung H3" und der Kontenplan 15 mögliche Sachkonten kennt, reicht ein Regelwerk nicht. Hier bewertet das Sprachmodell auf Basis historischer Kontierungen, welches Konto passt - und gibt einen Confidence-Score ab. Liegt der Score unter dem definierten Schwellenwert, eskaliert der Agent an einen Sachbearbeiter. Liegt er darüber, bucht er automatisch.

Das Ergebnis: Die Buchhaltung bearbeitet nicht mehr 10.000 Rechnungen. Sie bearbeitet die 300, bei denen der Agent sich nicht sicher genug ist. Der Rest läuft durch - geprüft, kontiert, dokumentiert.

## Jede Kontierung wird zum Prüfungsnachweis

Der Betriebsprüfer fragt nicht, ob eine Kontierung richtig ist. Er fragt, warum sie so und nicht anders getroffen wurde. Genau hier liegt die Schwäche manueller Buchhaltung: Die Begründung existiert nur im Kopf des Sachbearbeiters, der die Rechnung vor acht Monaten bearbeitet hat.

Der Agent dokumentiert für jede Kontierung den vollständigen Entscheidungspfad: angewandtes Sachkonto mit Begründung, Steuercode mit UStG-Referenz, Kostenstelle, Confidence-Score und ob die Entscheidung automatisch oder manuell getroffen wurde. Das entspricht den GoBD-Anforderungen an die Verfahrensdokumentation. Der Prüfer sieht nicht ein Ergebnis. Er sieht den Weg dorthin - für jede einzelne der 120.000 Rechnungen im Jahr.

## Die Kontenplan-Engine als Fundament für alle Buchungsagenten

Kontierung ist der erste Schritt in der Kreditorenbuchhaltung, aber nicht der einzige. Reisekosten, Bewirtungsbelege, Anlagenzugänge, Rückstellungen, Abgrenzungen - jeder dieser Prozesse braucht dieselbe Grundlogik: Leistung zu Sachkonto zu Steuercode. Wer diese Zuordnung für die Kontierung sauber aufbaut, baut die Infrastruktur für jeden weiteren Buchungsagenten mit auf.

Das Mapping-Framework, das der Kontierungs-Agent nutzt, wird zum Standardbaustein. Die Confidence-Bewertung und das Eskalationsmuster - automatisch buchen oder an einen Menschen übergeben - werden zur Blaupause. Nicht jeder Finance-Agent muss die Frage neu beantworten, wie er mit Unsicherheit umgeht. Der Kontierungs-Agent beantwortet sie einmal, und alle anderen bauen darauf auf.

--- Abgrenzungs-Agent ---
> Identifiziert aktive und passive Rechnungsabgrenzungsposten aus Zahlungs- und Leistungszeiträumen.

Wenn der Monatsabschluss ein verzerrtes Periodenergebnis liefert, trifft der Vorstand Entscheidungen auf falscher Grundlage. Die häufigste Ursache: fehlende oder falsche Rechnungsabgrenzungsposten. 94 Prozent der Finance-Teams erstellen ihre Abgrenzungen noch in Spreadsheets - und die Hälfte davon braucht mehr als sechs Arbeitstage für den gesamten Monatsabschluss. Dabei ist Periodenabgrenzung im Kern keine Ermessensfrage. Sie ist Arithmetik mit Kalender.

## Jeder vergessene ARAP verzerrt die Steuerungsgrundlage

Eine Jahresversicherungsprämie von 120.000 Euro wird im Januar gezahlt. Ohne Abgrenzung belasten 120.000 Euro das Januar-Ergebnis, während Februar bis Dezember zu gut aussehen. Multipliziert mit Dutzenden solcher Posten - Softwarelizenzen, Wartungsverträge, vorausbezahlte Mieten - entsteht ein Monatsergebnis, das mehr über Zahlungszeitpunkte aussagt als über die tatsächliche Geschäftsentwicklung.

Die Konsequenz reicht weiter als die Bilanzoptik. Fehlerhafte Periodenergebnisse verzerren Forecasts, verfälschen Abweichungsanalysen und untergraben das Vertrauen von Wirtschaftsprüfern und Aufsichtsräten. Laut einer Analyse des Center for Audit Quality sind fehlerhafte Abgrenzungen, Rückstellungen und Schätzungen die am häufigsten genannte Ursache für Financial Restatements. Jede Korrektur kostet nicht nur Geld, sondern vor allem Glaubwürdigkeit.

## Acht von zehn Entscheidungsschritten sind reine Arithmetik

Der [Decision Layer](/de/decision-layer/) zerlegt jeden Abgrenzungsprozess in zehn Entscheidungsschritte. Acht davon sind vollständig regelbasiert: Liegt eine Vorauszahlung vor (ARAP)? Liegt eine vor dem Stichtag erhaltene Einnahme vor, die Ertrag für die Zeit danach ist (PRAP)? Handelt es sich um eine Rückstellung oder eine Rechnungsabgrenzung? Welcher Periode ist der Aufwand wirtschaftlich zuzuordnen? Wie hoch ist der anteilige Betrag? Ist der angesetzte Betrag vorsichtig bewertet? Welcher Buchungssatz gehört dazu? Und wann genau erfolgt die Auflösung?

Für keinen dieser Schritte braucht es menschliches Urteilsvermögen. Der Datumsvergleich zwischen Zahlungszeitpunkt und Leistungszeitraum ist eindeutig. Die anteilige Berechnung folgt einer festen Formel. Die Buchungslogik nach ARAP oder PRAP ist in jedem Kontenrahmen definiert. Und die Gegenbuchung im Folgemonat ist eine automatische Konsequenz der Erstbuchung.

Genau das macht den Abgrenzungs-Agent zum Paradebeispiel für Automatisierung im Hauptbuch: hohes Volumen, niedrige Komplexität, null Ermessensspielraum. Die GoBD-konforme Dokumentation - Grundlage, Leistungszeitraum, Berechnungsweg, Auflösungszeitpunkt - entsteht als Nebenprodukt jeder Buchung, nicht als nachträgliche Pflichtübung.

## Zwei Schritte zeigen, wo KI den Unterschied macht

Die eigentliche Schwachstelle manueller Abgrenzungen liegt nicht in der Berechnung. Sie liegt im Erkennen. Wer identifiziert den neuen Rahmenvertrag mit quartalsweiser Zahlung und monatlichem Leistungszeitraum? Wer findet die Rechnung vom Dezember, deren Leistungszeitraum bis März läuft?

Zwei der zehn Entscheidungsschritte nutzen KI: die Schätzung des Abgrenzungsbetrags, wenn noch kein Rechnungsbetrag vorliegt, und die Erkennung periodenübergreifender Sachverhalte in Verträgen und Rechnungen. Der Agent durchsucht neue Verträge nach Leistungszeiträumen, gleicht Rechnungsdaten mit Vertragslaufzeiten ab und identifiziert Tatbestände, die eine Abgrenzung erfordern - bevor sie im Monatsabschluss fehlen. Diese Erkennung ist der Grund, warum der Agent nicht nur schneller arbeitet als ein Mensch, sondern vollständiger.

Menschliches Eingreifen bleibt dort, wo es hingehört: bei der Prüfung durch den Wirtschaftsprüfer. Jede einzelne Abgrenzung - regelbasiert oder KI-erkannt - ist auditierbar und anfechtbar.

## Konkreter Effekt: Der Monatsabschluss verliert seinen Engpass

Ein Industrieunternehmen mit 200 aktiven Abgrenzungsposten pro Monat - Softwarelizenzen, Versicherungen, Leasingraten, Wartungsverträge, vorausbezahlte Dienstleistungen - bindet typischerweise zwei bis drei Personentage allein für die Periodenabgrenzung. Excel-Listen mit Leistungszeiträumen, manuelle Buchungen, Kontrolle der Auflösungen aus dem Vormonat.

Der Agent reduziert diesen Aufwand auf die Prüfung von Ausnahmen. Wiederkehrende Abgrenzungen werden automatisch erstellt und aufgelöst. Neue Tatbestände werden erkannt und zur Freigabe vorgelegt. Die Dokumentation ist sofort prüfungsfähig. Was bleibt, ist eine Freigabeliste statt einer Erstellungsliste.

Die Periodisierungs-Infrastruktur, die der Agent aufbaut, wirkt über den eigenen Prozess hinaus. Die Auflösungslogik wird vom Rückstellungs-Agent wiederverwendet. Die Erkennung periodenübergreifender Sachverhalte liefert Eingangsdaten für den Lease-Accounting-Agent und den Vertrags-Compliance-Agent. Periodenabgrenzung ist nicht der spektakulärste Prozess im Rechnungswesen. Aber sie ist die Grundlage, auf der alle anderen Periodenergebnisse stehen.

--- Jahresabschluss-Vorbereitungs-Agent ---
> Orchestriert die Jahresabschluss-Vorbereitung, konsolidiert Abstimmungen, erstellt Anhangangaben und Lagebericht als LLM-Entwurf.

Kein Jahresabschluss scheitert an fehlender Fachkompetenz. Er scheitert an der Orchestrierung: an Abstimmungen, die nicht fertig werden, an Rückfragen zum Anlagespiegel, die drei Tage in einer Inbox liegen, an Anhangangaben, die erst im letzten Moment entstehen. Das Finance-Team kennt jeden einzelnen Schritt - und verliert trotzdem Wochen an die Koordination zwischen diesen Schritten.

## Die Closing-Wochen binden das gesamte Team an Routinearbeit

Laut APQC Open Standards Benchmarking liegt der Median des Monatsabschlusses branchenübergreifend im höheren einstelligen Tage-Bereich - die meisten Finance-Teams benötigen länger als fünf Arbeitstage allein für den Monatsabschluss. Der Jahresabschluss multipliziert diesen Aufwand: Anlagespiegel, Rückstellungsspiegel, Eigenkapitalspiegel, Kapitalflussrechnung, steuerliche Überleitung, Anhang, Lagebericht, WP-Unterlagen und Offenlegung kommen hinzu.

Ein konkretes Szenario verdeutlicht das Problem. Ein mittelständisches Industrieunternehmen mit 200 Millionen Euro Umsatz schließt das Geschäftsjahr ab. Der Head of Finance koordiniert vier Wochen lang ein Team aus sechs Personen. Drei davon verbringen den Großteil ihrer Zeit mit Spiegel-Erstellungen - also mit arithmetischen Ableitungen aus Daten, die bereits im System existieren. Eine Person sammelt Unterlagen für den Wirtschaftsprüfer zusammen. Bewertungsentscheidungen - die eigentliche Facharbeit - füllen vielleicht 20 Prozent der gesamten Closing-Zeit.

Gleichzeitig drohen bei verspäteter Offenlegung Ordnungsgelder. Das Bundesamt für Justiz setzt nach HGB §335 mindestens 2.500 Euro an, in Wiederholungsfällen bis zu 25.000 Euro. Für kapitalmarktorientierte Unternehmen steht neben dem Ordnungsgeld auch die Reputation auf dem Spiel.

## Fünfzehn Entscheidungsschritte trennen Routine von Ermessen

Der [Decision Layer](/de/decision-layer/) zerlegt den gesamten Jahresabschluss-Prozess in fünfzehn einzelne Entscheidungsschritte - und ordnet jeden einer klaren Stufe zu. Das Ergebnis ist eine Landkarte, die zeigt, wo Automatisierung sinnvoll ist und wo menschliches Urteil gefordert bleibt.

Stufe 1 (Regelwerk) umfasst neun Schritte: die Abschluss-Checkliste, die Konsolidierung der Abstimmungen, die steuerliche Überleitungsrechnung in Standardfällen, die Berechnung latenter Steuern auf Basis temporärer Differenzen, die Offenlegungsvorbereitung nach HGB §325 sowie die vier Spiegel (Rückstellungen, Anlagen, Eigenkapital, Kapitalfluss). All das folgt definierten Regeln und vorhandenen Daten.

Stufe 2 (KI-Entwurf mit menschlicher Freigabe) deckt drei Schritte ab: den Anhangangaben-Entwurf auf Basis von HGB §285, den Lagebericht-Entwurf und die Vorbereitung der WP-Unterlagen nach PBC-Liste. Der Agent erstellt strukturierte Entwürfe - die inhaltliche Verantwortung bleibt beim Fachteam.

Drei Schritte verbleiben ausschließlich beim Menschen: die Bewertungswahlrechte (bilanzpolitische Entscheidung), die Nachtragsprüfung (Wesentlichkeitsbeurteilung) und der Bilanzeid (persönliche Attestierung durch die Geschäftsführung nach §264 Abs. 2 HGB). Keine Automatisierung ersetzt das Ermessen, das diese Schritte erfordern.

## Der Agent orchestriert - der Mensch entscheidet

Was ändert sich in der Praxis? Der Agent übernimmt die Taktung. Er prüft, ob alle Abstimmungen abgeschlossen sind, bevor er den nächsten Schritt anstößt. Er erstellt die vier Spiegel direkt aus den Ergebnissen der vorgelagerten Agenten. Er bereitet Anhangangaben als strukturierten Entwurf vor, den das Team überarbeitet statt von Grund auf schreibt. Er stellt das WP-Paket nach der PBC-Liste des Wirtschaftsprüfers zusammen.

Das Team verlagert seine Zeit: weg von der Koordination, hin zu den Bewertungsentscheidungen. Die Frage lautet nicht mehr "Haben wir den Anlagespiegel fertig?", sondern "Welche Bewertungsmethode wenden wir bei den Pensionsrückstellungen an?" - die Frage, für die ein CFO tatsächlich bezahlt wird.

Für den Wirtschaftsprüfer entsteht ein Nebeneffekt: Jeder Entscheidungsschritt ist dokumentiert, jede Datenquelle nachvollziehbar. Die Prüfung wird nicht einfacher im Sinne von weniger streng - aber sie beginnt mit einer vollständigen, strukturierten Grundlage.

## Jeder vorgelagerte Agent verbessert die Abschlussqualität

Der Jahresabschluss-Agent ist kein isoliertes Werkzeug. Er ist der Integrationspunkt der gesamten Finance-Infrastruktur. Der Anlagespiegel speist sich aus dem AfA-Agenten. Der Rückstellungsspiegel greift auf den Rückstellungs-Agenten zurück. Die Kontenabstimmung liefert der Abstimmungs-Agent, die Steuerdaten der USt-Agent, die Wertberichtigungen der Forderungsmanagement-Agent.

Das bedeutet: Wer die vorgelagerten Agenten sauber betreibt, hat beim Jahresabschluss automatisch bessere Daten. Wer den Jahresabschluss als Ziel definiert, baut die gesamte Agent-Infrastruktur rückwärts von diesem Punkt auf. Der Jahresabschluss ist nicht der Anfang - er ist der Beweis, dass die Infrastruktur funktioniert.

--- Anlagenzugangs-Agent ---
> Identifiziert aktivierungspflichtige Wirtschaftsgüter aus Eingangsrechnungen, bestimmt Anlageklasse und Nutzungsdauer.

Falsche Aktivierungsentscheidungen gehören zu den teuersten vermeidbaren Fehlern in der Anlagenbuchhaltung. Wer ein Investitionsgut als Aufwand bucht, drückt den Gewinn im falschen Jahr. Wer eine laufende Ausgabe aktiviert, bläht die Bilanz auf. In beiden Fällen stimmen Abschreibungen, Steuerlast und Anlagenspiegel über Jahre nicht. Der Anlagenzugangs-Agent verhindert genau diese Fehlallokation - nicht durch Automatisierung der gesamten Buchhaltung, sondern durch strukturierte Zerlegung jeder einzelnen Aktivierungsentscheidung.

## Jede dritte Betriebsprüfung beanstandet das Anlagevermögen

Die Zahlen sind eindeutig. Laut einer PwC-Befragung muss jedes zweite deutsche Unternehmen nach einer Betriebsprüfung Steuern nachzahlen. Bei 29 Prozent der betroffenen Unternehmen betreffen die Beanstandungen die Bilanzierung von Anlagevermögen (Quelle: PwC-Studie "Betriebsprüfung", 2024). Der häufigste Grund: Wirtschaftsgüter wurden falsch klassifiziert, Anschaffungsnebenkosten nicht korrekt zugeordnet oder Nutzungsdauern ohne nachvollziehbare Begründung angesetzt.

Das Bundesfinanzministerium beziffert das Mehrergebnis aller Betriebsprüfungen im Jahr 2024 auf 10,9 Milliarden Euro aus 140.764 geprüften Betrieben (BMF-Monatsbericht November 2025). Ein erheblicher Teil entfällt auf Korrekturen im Anlagevermögen - weil die ursprüngliche Aktivierungsentscheidung nicht dokumentiert war oder auf falschen Annahmen beruhte.

Für CFOs bedeutet das: Die Aktivierungsentscheidung ist kein buchhalterisches Detail. Sie ist ein Prüfungsrisiko mit messbaren finanziellen Konsequenzen.

## Die Aktivierungsentscheidung fällt in Sekunden - und wirkt über Jahre

Stellen Sie sich eine typische Woche in der Kreditorenbuchhaltung eines Mittelständlers vor. 40 Eingangsrechnungen, davon sechs über 800 Euro netto. Jede dieser Rechnungen verlangt dieselbe Abfolge von Entscheidungen: Ist das ein Wirtschaftsgut oder eine laufende Dienstleistung? Liegt der Betrag über der GWG-Grenze? Welche Anlageklasse? Welche Nutzungsdauer nach AfA-Tabelle? Gehören Transportkosten zu den Anschaffungsnebenkosten?

Ein Sachbearbeiter trifft diese Entscheidungen oft in Minuten - unter Zeitdruck, mit unvollständigen Informationen, manchmal gestützt auf Erfahrung statt auf die aktuelle BMF-Tabelle. Die Konsequenz zeigt sich erst Jahre später: bei der Inventur, wenn physische Anlagen und Anlagenspiegel nicht zusammenpassen. Oder bei der Betriebsprüfung, wenn der Prüfer die Nutzungsdauer einer Spezialmaschine hinterfragt und keine Dokumentation vorfindet.

Die Fehlerquelle liegt nicht in mangelnder Kompetenz. Sie liegt in der Struktur: Jede Aktivierungsentscheidung enthält deterministische Anteile (Schwellenwert, Anlageklasse, AHK-Berechnung) und Ermessensspielräume (Nutzungsdauer bei Sonderanlagen, Abgrenzung zusammengesetzter Wirtschaftsgüter). Wenn beide in einem manuellen Schritt verschmelzen, fehlt die Nachvollziehbarkeit.

## Neun Entscheidungsschritte trennen Regelwerk von Ermessen

Der [Decision Layer](/de/decision-layer/) zerlegt den Anlagenzugang in neun diskrete Schritte. Jeder Schritt hat einen definierten Entscheider: Regelwerk, KI-Modell oder Mensch.

Die Identifikation des Wirtschaftsguts aus der Rechnungsbeschreibung nutzt ein Sprachmodell. Eine Rechnung über "Montage und Inbetriebnahme Fertigungslinie Halle 7" enthält keine EAN-Nummer und keinen Anlagenstamm - aber genug Kontext, um das Wirtschaftsgut zu erkennen.

Die Aktivierungsprüfung ist rein regelbasiert: Nettobetrag über 800 Euro, also Aktivierungspflicht nach EStG. Darunter GWG-Behandlung oder Sammelposten. Dasselbe gilt für die AHK-Ermittlung nach HGB Paragraph 255, die Inventarnummernvergabe und die Erfassung im Anlagenspiegel. Diese Schritte sind deterministisch. Sie profitieren nicht von menschlichem Ermessen, sondern von Konsistenz und Vollständigkeit.

Anders bei Grenzfällen: Die Zuordnung einer CNC-Fräse mit Sonderausstattung zur richtigen Anlageklasse kann regelbasiert vorbereitet, aber nicht abschließend entschieden werden. Die Nutzungsdauer einer Spezialmaschine steht nicht in der BMF-AfA-Tabelle. Hier entscheidet der Mensch - aber auf Basis einer vorstrukturierten Entscheidungsvorlage, nicht auf einem leeren Blatt.

## Der Mensch entscheidet dort, wo Ermessen gefragt ist

Der Anlagenzugangs-Agent operiert auf den Decision-Layer-Stufen 1 und 2. Das bedeutet: Regelbasierte Schritte laufen automatisch mit Protokoll. KI-unterstützte Schritte liefern Vorschläge mit Konfidenzwert. Kein Schritt verändert die Bilanz ohne dokumentierte Entscheidungsgrundlage.

Konkret: Wenn der Agent eine Rechnung über 12.000 Euro für eine Laborwaage verarbeitet, läuft die Aktivierungsprüfung regelbasiert durch. Die Anlageklasse "technische Anlagen und Maschinen" wird regelbasiert zugeordnet. Die Nutzungsdauer von 10 Jahren kommt aus der BMF-Tabelle, Fundstelle dokumentiert. Anschaffungsnebenkosten für Kalibrierung und Aufstellung werden den AHK zugerechnet - HGB Paragraph 255 Absatz 1.

Für die Betriebsprüfung entsteht damit ein vollständiger Entscheidungspfad: warum aktiviert, wie klassifiziert, welche AHK-Bestandteile, welche Nutzungsdauer mit welcher Rechtsgrundlage. Diese Dokumentation entsteht nicht nachträglich für den Prüfer. Sie entsteht als natürliches Nebenprodukt jeder einzelnen Aktivierungsentscheidung.

Das reduziert nicht die Verantwortung des CFO für die Bilanzrichtigkeit. Es gibt ihm die Grundlage, diese Verantwortung informiert wahrzunehmen - statt darauf zu vertrauen, dass in der Kreditorenbuchhaltung niemand einen Fehler gemacht hat.

--- Inventur-Agent ---
> Generiert Inventurlisten aus der Anlagenbuchhaltung, vergleicht Soll- mit Ist-Bestand, identifiziert Fehlbestände und bereitet Korrekturbuchungen.

Zwischen 10 und 30 Prozent aller Einträge in Anlagenregistern sind sogenannte Ghost Assets - Güter, die nur noch auf dem Papier existieren (Quelle: CPCON Group, Fixed Asset Register Guide 2026). Die jährliche Inventur nach HGB §240 soll genau das verhindern. In der Praxis scheitert sie häufig am Prozess selbst: manuelle Zählung über Standorte hinweg, Excel-basierter Abgleich, wochenlange Nacharbeit. Der Inventur-Agent löst dieses Problem, indem er den regelbasierten Teil der Inventur vollständig übernimmt und nur dort stoppt, wo menschliches Urteil gefragt ist.

## Jedes dritte Anlagegut im Register existiert nur auf dem Papier

Ghost Assets entstehen schleichend. Ein Drucker wird ausgetauscht, aber der Abgang nicht gebucht. Eine Maschine wird an einen anderen Standort verlegt, ohne dass die Stammdaten aktualisiert werden. Nach fünf Jahren ohne physische Prüfung hat sich das Anlagenregister so weit von der Realität entfernt, dass die Inventur zum Bereinigungsprojekt wird. Die Konsequenzen sind messbar: Überhöhte Versicherungsprämien, weil auf Basis aufgeblähter Buchwerte kalkuliert wird. Unnötige Abschreibungen auf Güter, die längst entsorgt sind. Im schlimmsten Fall ein qualifizierter Bestätigungsvermerk, weil der Wirtschaftsprüfer die Differenz zwischen Register und Realität nicht akzeptiert.

## Manuelle Inventur skaliert nicht über Standorte

Ein mittelständischer Maschinenbauer mit vier Produktionsstandorten und 8.000 Anlagegütern kennt das Muster: Drei Wochen vor dem Stichtag beginnt die Koordination. Inventurteams werden eingeteilt, Zähllisten gedruckt, Scanner verteilt. Jeder Standort zählt in seinem eigenen Rhythmus. Die Ergebnisse kommen per E-Mail zurück - als Excel-Dateien mit unterschiedlichen Formaten. Die zentrale Zusammenführung dauert weitere zwei Wochen. Fehlbestände werden erst spät sichtbar, Nachzählungen verzögern den Abschluss. Das Ergebnis: Die Inventur frisst vier bis sechs Wochen Arbeitszeit, und trotzdem bleiben Zweifel an der Vollständigkeit.

## Der Agent trennt Zählen von Bewerten

Der [Decision Layer](/de/decision-layer/) zerlegt die Anlageinventur in zwei Kategorien von Entscheidungen. Regelbasierte Schritte - Inventurliste aus dem ERP generieren, Ist-Bestand erfassen, Soll/Ist-Abgleich durchführen, Fehlbestände identifizieren, Korrekturbuchungen vorbereiten - laufen automatisiert. Der Agent gleicht den Buchbestand mit dem physischen Bestand ab und erstellt Differenzlisten pro Standort, Kostenstelle und Anlagenklasse.

Zwei Entscheidungen bleiben beim Menschen: Hat ein Anlagegut an Wert verloren? Soll es ausgesondert werden? Diese Bewertungsfragen erfordern Augenschein und Ermessen. Der Agent liefert die Entscheidungsgrundlage - Alter, Nutzungsdauer, Zustand laut letzter Erfassung - aber die Freigabe liegt bei der Fachabteilung. So bleibt der Prozess prüfungssicher nach §240 HGB, ohne dass menschliche Kapazität an Zählarbeit gebunden wird.

## RFID-gestützte Erfassung hebt die Genauigkeit auf über 95 Prozent

Manuelle Inventur mit Barcode-Scannern erreicht typischerweise Genauigkeitsraten von 85 bis 95 Prozent. RFID-gestützte Erfassung erhöht die Genauigkeit weiter und verkürzt die Erfassungszeit erheblich. Der Inventur-Agent nutzt beide Technologien: Wo RFID-Tags vorhanden sind, erfasst er den Ist-Bestand eines Raums in Sekunden statt Stunden. Wo nur Barcodes vorliegen, orchestriert er die manuelle Erfassung mit standortbezogenen Listen und Echtzeit-Fortschrittsanzeige. Die Investition in RFID-Infrastruktur amortisiert sich in der Praxis innerhalb weniger Jahre - nicht nur durch schnellere Inventur, sondern auch durch bessere Standortverfolgung im Tagesgeschäft.

## Korrekturbuchungen stehen am Inventurtag bereit

Das eigentliche Ziel der Inventur ist nicht die Zählung, sondern das bereinigte Anlagenregister. Der Inventur-Agent bereitet Korrekturbuchungen vor, sobald eine Abweichung bestätigt ist: Abgangsbuchungen für nicht auffindbare Güter, außerplanmäßige Abschreibungen für wertgeminderte Anlagen, Standortkorrekturen für verlagerte Güter. Am Ende steht ein Inventurbericht, der den gesamten Prozess dokumentiert - von der Soll-Liste über die Ist-Erfassung bis zur Freigabe jeder einzelnen Korrektur. Der Wirtschaftsprüfer erhält nicht nur ein Ergebnis, sondern den vollständigen Entscheidungspfad. Das beschleunigt die Abschlussprüfung und reduziert Rückfragen auf das Wesentliche.

--- Bankabstimmungs-Agent ---
> Liest CAMT.053- und MT940-Auszüge ein, gleicht Bankbewegungen gegen offene Posten ab und legt das Abstimmungsprotokoll GoBD-revisionssicher ab.

Bankabstimmung ist in Deutschland zugleich handelsrechtliche Pflicht, abgabenrechtlich reguliert, eine Schlüsselkontrolle des internen Kontrollsystems und steuerstrafrechtlich relevant. Vier Rechtskreise wirken parallel: das HGB (§§238-266 zu Buchführung, Vollständigkeit, Verrechnungsverbot und Bilanzgliederung), die AO (§§146-147 zu Ordnungsmäßigkeit und Aufbewahrung, §158 zur Beweiskraft, §162 zur Schätzung, §370 zur Steuerhinterziehung), die IDW-Prüfungsstandards (PS 261 zum IKS, PS 951 zur Funktionstrennung, RS HFA 38 zur Intercompany-Verrechnung) und die ISO-20022-Standards für Kontoauszüge und EBICS-Übertragung. Hinzu kommen die GoBD 2025 mit ihrer Festschreibungsregelung, der BaFin-BAIT-Standard als Spiegelbild für Corporate Treasury und die BFH-Rechtsprechung zur Verwerfung der Buchführung bei Abstimmungslücken. Eine fehlende Tagesabstimmung, ein ungeklärter Verrechnungskonten-Saldo am Bilanzstichtag oder eine Lücke in der Funktionstrennung kann siebenstellige Steuermehrbelastungen und die persönliche Geschäftsführerhaftung nach §69 AO und §43 GmbHG auslösen.

## Mangelhafte Bankabstimmung führt zu siebenstelligen Steuermehrbelastungen

Vier Schadensquellen wirken parallel und kumulieren bei mittelständischen Industrieunternehmen schnell zu siebenstelligen Beträgen pro Geschäftsjahr. Erstens: Schätzungs-Hinzuschätzung nach §162 AO bei verworfener Buchführung. Das BFH-Urteil VIII R 25/20 vom 16. Dezember 2021 hat einen Mittelständler mit systematischen Abstimmungslücken (mehrere Wochen ohne abgestimmten Bankauszug, Verrechnungskonten-Saldo am Bilanzstichtag von über 200 TEUR) der Schätzung mit 12%-Hinzuschätzung unterzogen. Bei einer Mittelstandsfirma mit 200 Mio EUR Umsatz und 8 Prozent EBIT-Marge ergibt eine 10-Prozent-Hinzuschätzung 1,6 Mio EUR Mehrgewinn und damit rund 380 TEUR Steuermehrbelastung aus Körperschaftsteuer (15 Prozent), Solidaritätszuschlag und Gewerbesteuer (effektiv 14 Prozent bei Hebesatz 400 Prozent), dazu Säumniszuschläge nach §240 AO und Hinterziehungszinsen nach §235 AO von je 6 Prozent pro Jahr. Zweitens: Versagung des Wirtschaftsprüfer-Testats nach IDW PS 400 wegen IKS-Mängeln. Beanstandet der Prüfer im Walk-Through eine der fünf Schlüsselkontrollen - vollständige Saldo-Fortschreibung, Plausibilität der Bewegungen, Funktionstrennung, Zeitnähe T+1, Eskalations-Dokumentation - erteilt er nur einen eingeschränkten Bestätigungsvermerk, mit erheblichen Folgen für Bankratings, Anleiheemissionen, Konzernkonsolidierung und Investor Relations.

Drittens: Persönliche Haftung der Geschäftsleitung nach §69 AO bei vorsätzlicher Pflichtverletzung in der Buchführung und nach §43 GmbHG bei Sorgfaltspflichtverletzung des ordentlichen Geschäftsmanns. Bei Steuerhinterziehung nach §370 AO drohen bis 10 Jahre Freiheitsstrafe und Berufsverbot für Geschäftsführer. Viertens und am direktesten messbar: Effizienzverlust durch manuelle Abstimmung. Ein mittelständisches Unternehmen mit vier Bankkonten und 200 Transaktionen pro Tag erzeugt im Monat rund 4.000 Buchungsbewegungen. Manuelle Abstimmung in Excel kostet 90-120 Minuten pro Konto und Tag - bei vier Konten und 22 Werktagen also rund 130 Stunden pro Monat. Bei einem internen Stundensatz von 65 EUR sind das 8.400 EUR pro Monat oder rund 100 TEUR pro Jahr für eine Tätigkeit, die zu 95% deterministisch automatisierbar ist.

## Die deutsche Bankabstimmung durchläuft 15 feste Schritte

Anders als das spanische Verfahren mit 11 oder das brasilianische mit 9 Schritten erfordert die deutsche Bankabstimmung 15 deterministische Entscheidungen, weil das Zusammenspiel aus HGB, AO, IDW-IKS-Standards, ISO-20022-Format, EBICS, SEPA-Rulebook und BaFin-BAIT mehr Verzweigungen erzeugt. Die Kette reicht vom EBICS-Abruf und der XSD-Validierung über die Saldo-Prüfung gegen den Vortag, das exakte und das unscharfe Matching, die Kontierung von Bankgebühren und Zinsen und die Bewertung von Devisenkursdifferenzen nach §256a HGB bis zur Erkennung von Lastschrift-Rückgaben und Cash-Pooling-Buchungen, der Bundesbank-Z4-Prüfung nach AWV §67, der Verrechnungskonten-Eskalation, den fünf IKS-Schlüsselkontrollen nach IDW PS 261, der Funktionstrennungs-Prüfung nach IDW PS 951 und der GoBD-konformen Festschreibung mit qualifiziertem Zeitstempel.

Ein konkretes Szenario: Maschinenbau-Mittelständler mit 200 Mio EUR Umsatz, vier Bankkonten (Sparkasse Hauptkonto, Commerzbank Auslandszahlungs-Konto, Volksbank Tochtergesellschaft, HSBC Devisenkonto), 200 Transaktionen pro Tag und DATEV Bankmodul über die Steuerberatungs-Kanzlei. Um 7:00 Uhr morgens ruft der Agent via EBICS BTD die CAMT.053-Auszüge aller vier Konten parallel ab, validiert die XSD-Konformität, prüft die Saldo-Fortschreibung gegen den Vortag (Opening-Balance(t) = Closing-Balance(t-1)) und ordnet die rund 200 Tagesbewegungen in zwei Stufen zu. Stufe 1 exaktes Matching: typisch 85-90% der Bewegungen werden über EndToEndId aus PAIN.001-Aufträgen, MandateId aus SEPA-Lastschriften oder Hash über Rechnungsnummer-Bruttobetrag-Counterparty-IBAN matched - reine Datenbank-Abfrage ohne KI. Stufe 2 unscharfes Matching für die verbleibenden 10-15%: KI-Pattern-Matching gegen historische Vergleichsmuster derselben Geschäftspartner mit Konfidenz-Score und Top-3-Kandidaten je Bewegung. Bewegungen mit Konfidenz über 90% werden auto-zugeordnet, zwischen 70-89% ein Auto-Vorschlag mit Sachbearbeiter-Bestätigung binnen 24 Stunden, unter 70% direkte Eskalation. Die typisch 5-15 nicht zuordenbaren Bewegungen pro Tag werden auf Verrechnungskonto SKR03 1370 gebucht und in den Klärungs-Workflow überführt mit 30-Tage-Auflösungsfrist.

Im [Decision Layer](/de/decision-layer/) sind 13 der 15 Schritte regelbasierte Entscheidungen (Stufe R), 1 Schritt KI-gestützt mit menschlicher Bestätigungsoption (Stufe A für unscharfes Pattern-Matching), 1 Schritt menschliche Entscheidung (Stufe H für Eskalation nicht zuordenbarer Positionen). Die Trennung ist vor BAFin, Wirtschaftsprüfer und Finanzamt transparent: ISA 240 verlangt explizit die Differenzierung zwischen automatisierten und manuellen Schritten in der Bankabstimmung - der Agent liefert diese Differenzierung als Decision Log mit Stufenkennzeichnung je Bewegung.

## Plausibilitätsprüfung schließt Lücken vor der Festschreibung

Vor jeder GoBD-Festschreibung läuft eine dreistufige Plausibilitätsprüfung, die Datenmängel oder Verarbeitungslücken erkennt bevor die Buchung unveränderbar wird. Erstens: Saldo-Plausibilität über alle vier Konten. Sum(Entries) muss exakt Closing-Balance minus Opening-Balance ergeben, auf Cent-Genauigkeit; Abweichung deutet auf fehlende Bewegung im CAMT.053 oder Bank-Storno-Buchung hin und löst Wiederholung des CAMT-Abrufs aus. Zweitens: BTC-Plausibilität (Bank Transaction Code ISO 20022 in CAMT.053 BkTxCd-Element). Jede Bewegung muss einen gültigen BTC-Code haben, der auf eine SKR03/SKR04-Kontierungsregel mappt; unbekannte BTCs deuten auf neue Bank-Buchungstypen hin und werden als Stammdaten-Eskalation an den Sachbearbeiter ausgelöst. Drittens: Counterparty-Plausibilität. Jede SEPA-Bewegung mit Counterparty-IBAN wird gegen die Stammdaten der Geschäftspartner geprüft; unbekannte IBANs werden mit der konzerninternen Cash-Pooling-Mappingtabelle abgeglichen, der Sanktionslisten-Datenbank (VO 269/2014, VO 833/2014, VO 765/2006) und ggf. neuen Geschäftspartnern eskaliert.

Bei Unstimmigkeiten in einer der drei Stufen wird die Festschreibung blockiert bis zur manuellen Klärung - eine ordnungsmäßige Buchführung nach §146 AO setzt voraus, dass die Bankabstimmung vor Festschreibung vollständig und plausibel ist. Die Klärungshistorie wird Teil des IDW PS 261 IKS-Nachweises mit Eskalations-Dokumentation für den Walk-Through-Test des Wirtschaftsprüfers.

## Edge-Cases Konzern-Cash-Pooling, Bundesbank Z4-Auslandsmeldung und SEPA R-Transactions

Konzerne mit Tochtergesellschaften und konzerninterner Liquiditätssteuerung über DATEV TopBank, SAP Bank Communication Management oder spezialisierte Treasury-Software (Coupa Treasury, Kyriba, ION Treasury) erfordern parallele Cash-Pooling-Logik mit Erkennung interner Sweep-Buchungen. Der Agent identifiziert konzerninterne Bewegungen über drei Kriterien: Counterparty-IBAN aus konzerninterner Mappingtabelle, BTC-Code 305-307 (Internal Cash Concentration), Verwendungszweck enthält 'Cash Sweep' oder 'Notional Pooling Adjustment'. Buchung erfolgt nach IDW RS HFA 38 Intercompany-Verrechnung als getrennte Forderung/Verbindlichkeit auf Einzelgesellschafts-Ebene mit Auflösung im Konzernabschluss nach §305 HGB. Bei Notional Pooling (rechnerische Saldo-Konsolidierung ohne tatsächlichen Geldfluss) wird der konzerninterne Zinsausgleich nach Verrechnungspreis-Grundsätzen §1 AStG dokumentiert.

Bei Auslandszahlungen über 12.500 EUR greift parallel die Bundesbank-Außenwirtschaftsstatistik mit Z4-Meldepflicht nach AWV §67. Der Agent erkennt meldepflichtige Bewegungen über IBAN-Country-Code (Counterparty-Land != DE) und generiert die Z4-Meldung automatisch mit Verwendungszweck-Klassifikation Warenhandel/Dienstleistung/Kapitalverkehr und übermittelt sie via Bundesbank-AWV-Portal innerhalb der 7-Tage-Frist nach Wertstellung. Verstoß führt zu Bußgeld bis 30.000 EUR nach §19 AWG und zur persönlichen Verantwortlichkeit der Geschäftsführung.

SEPA R-Transactions (Reject, Return, Refund, Reversal, Revocation) werden über CAMT.054 Bank to Customer Debit Credit Notification mit Reason-Codes verarbeitet: AC04 ClosedAccount, AM04 InsufficientFunds, MD06 RefundRequestByEndCustomer (8-Wochen-Refund bei autorisierter SDD), BE05 UnrecognizedInitiatingParty (Mandate ungültig). Der Agent löst je Reason-Code eine spezifische Folgebuchung aus mit Wiedereinstellung in OPOS, Mandate-Lifecycle-Pflege oder Eskalation an den Mahnwesens-Agent. Mandate-Lifecycle wird automatisch nach SEPA-Rulebook gepflegt: Aufbewahrung 14 Monate nach letzter Lastschrift, automatische Sperre weiterer Lastschriften bei Mandate-Erloschen.

## Integration mit DATEV, SAP, Subsembly und Wirtschaftsprüfer-Schnittstellen schließt die IKS-Kette

Die Logik des Agents verbindet sich mit den führenden deutschen Banking-, Treasury- und Audit-Systemen via API: [DATEV](https://www.datev.de/) Bankmodul (dominanter Marktanteil bei Steuerberatern und Mittelstand-Buchhaltung mit DATEV-Banking-Container 3.7, EBICS T und H), DATEV TopBank (Cash-Pooling-Drehscheibe für Mehr-Banken-Konstellation), SAP S/4HANA FI Bank Accounting mit Bank Communication Management (BCM) und Electronic Bank Statement (EBS) Routine, Microsoft Dynamics 365 Business Central mit Bank Account Reconciliation, Sage 100 mit Banking-Modul, Diamant/4 mit Treasury für Konzern-Cash-Pooling, Lexware Buchhaltung Pro für KMU mit GoBD-zertifizierter Bankschnittstelle, Subsembly Banking-Komponenten und Wallix BankWizard als EBICS-Middleware, ProfiCash der VR-Banken und Hibiscus Banking. Die Wirtschaftsprüfer-Schnittstelle erfolgt über IDW-PS-261-konforme Decision-Log-Exports im Walk-Through-Test-Format mit Schlüsselkontroll-Wirksamkeitsnachweis. Die Außenprüfungs-Schnittstelle erfolgt über IDEA (BMF-Standardprüfsoftware) mit Z3-Datenträgerüberlassung nach AO §147 Abs. 6. Der qualifizierte Zeitstempel-Dienst läuft über BSI-zertifizierte Trust Service Provider (D-Trust, T-Systems Trust Center, swisscom Trust Services) nach eIDAS-VO 910/2014. Für DAX/MDAX-Konzerne und gehobenen Mittelstand mit ausländischen Tochtergesellschaften erzeugt der Agent parallele IFRS-Reportings - das deutsche Verfahren bleibt HGB-, GoBD- und IDW-PS-konform, das Konzern-Reporting erfüllt zugleich IAS 7 (Cashflow Statement) und IFRS 9 (Financial Instruments) für die internationale Konsolidierung nach §315e HGB.

--- Budget-Variance-Agent ---
> Zerlegt Budget-Ist-Abweichungen nach Volume, Price, Mix, FX und Operations-Driver-Tree, liefert AktG §90 Vorstandsbericht, HGB §289 Lagebericht und KonTraG §91 mit Closed-Loop-Action pro Owner.

Die Soll-Ist-Analyse steht in Deutschland zwischen fünf parallelen Compliance-Anforderungen mit sehr unterschiedlichen Konsequenzen für Vorstand, Aufsichtsrat und Wirtschaftsprüfer. AktG §90 verpflichtet den Vorstand zur regelmäßigen Berichterstattung an den Aufsichtsrat über Geschäftsverlauf und Lage, mit Haftungsrisiken nach §93 AktG bei Falschangaben. KonTraG §91 Abs. 2 verlangt seit 1998 ein Risikofrüherkennungssystem, das die Reaktionen umsetzt und ihre Wirksamkeit überwacht. HGB §289 fordert im Wirtschaftsbericht die Erläuterung wesentlicher Änderungen, ergänzt um den DRS-20.62-Soll-Ist-Vergleich im Konzernlagebericht. Die IDW-Prüfungsstandards PS 261, PS 340 und PS 350 regeln die Wirtschaftsprüfer-Methodik mit Risk-Based-Audit, Substantive-Testing und Plausibilisierung. Und der DCGK 2024 (B.6, C.6, D.4) definiert die Corporate-Governance-Erwartung an dokumentierte, geschlossene Reaktionen. Damit kann jede wesentliche Abweichung in einem deutschen Konzern oder gehobenen Mittelständler bis zu fünf Pflichten gleichzeitig auslösen - bis hin zu Bilanzeid, D&O-Schadensfall und Forensik-Audit nach FISG 2021.

## 46 Prozent der FP&A-Zeit gehen für die Datensammlung drauf, dazu droht ein DPR-Bußgeld bis 10 Mio EUR

FP&A Trends Benchmark 2025 dokumentiert: 46 Prozent der FP&A-Arbeitszeit fließen in Datensammlung und Validierung statt in die Variance-Analyse, die tatsächlich Entscheidungen verbessert. Hackett Group 2024 ergänzt für mittelständische Unternehmen mit manueller Excel-Analyse: Controller erreichen nur 64 Prozent Genauigkeit bei zwei bis drei Arbeitstagen je Monatsabschluss für 15 Kostenstellen - die Datenintegration aus Budget-System, FiBu und Sub-Ledgern frisst den größten Teil der Zeit, die eigentliche Driver-Zerlegung dauert nur Minuten. Bei kapitalmarktorientierten Unternehmen kommt das Aufsichtsrisiko hinzu: Ein DPR-Mängelbericht zur Soll-Ist-Plausibilität nach WpHG §114 löst typisch -3 bis -8 Prozent Kursreaktion am Veröffentlichungstag aus, dazu eine BaFin-Folgeprüfung mit Sanktionen bis 10 Mio EUR oder 5 Prozent Jahresumsatz nach §120, Investor-Vertrauensverluste und schlechtere Hausbank-Konditionen. Bei Falschangaben oder versäumter Risikofrüherkennung nach KonTraG §91 Abs. 2 haftet der Vorstand persönlich nach §93 AktG mit Beweislastumkehr, der Aufsichtsrat nach §116 - verschärft durch die FISG-2021-Prüfer-Rotation, die Honorar-Disclosure, die Forensik-Audit-Vorbereitung und den D&O-Selbstbehalt von 10 Prozent nach VorstAG. Die typische Monatsabschluss-Situation in einem mittelständischen Unternehmen mit 15 Kostenstellen sieht so aus: der Controller exportiert Plan-Daten aus dem Budgetierungstool, Ist-Daten aus dem ERP-System, gleicht Kontenrahmen ab, bereinigt Periodenabgrenzungen und erstellt dann manuell die Abweichungstabelle. Erst danach beginnt die eigentliche Arbeit - die Frage nach dem Warum. Dieser Ablauf wiederholt sich jeden Monat nahezu identisch, ohne Audit-Trail für KonTraG und DPR.

## 15 deterministische Etappen mit fünf menschlichen Eskalationen

Der Agent zerlegt den Workflow in 15 Entscheidungsschritte mit klarer Decider-Trennung: zehn regelbasierte (R), zwei ML-gestützte Indikator-Schritte (A) und fünf menschliche Eskalationen (H). Datenintegration und Stammdaten-Mapping laufen regelbasiert mit GoBD-konformem Audit-Trail und Hash-Validierung; die Abweichungs-Berechnung (absolut, prozentual, mit Materialitätsfilter) folgt IDW PS 261 und der DRS-20.116-Wesentlichkeit. Die Driver-Tree-Zerlegung trennt jede wesentliche Abweichung in fünf orthogonale Komponenten: Volume-Variance = (Ist-Menge minus Plan-Menge) x Plan-Preis erfasst Mengenabweichungen; Price-Variance = (Ist-Preis minus Plan-Preis) x Ist-Menge die Preisabweichungen mit FX-Hedging-Effekten nach IAS 21 und IFRS 9; Mix-Variance = (Ist-Mix-Anteil minus Plan-Mix-Anteil) x (Plan-Preis je Cluster minus Plan-Durchschnittspreis) x Ist-Gesamtmenge die Sortimentsverschiebungen; FX-Variance die Wechselkurs-Effekte mit Hedging-Auflösung; und die Operations-Variance ML-gestützt die Effizienz- und Produktivitätsabweichungen anhand von Produktions-KPIs (OEE, Ausschussquote, Personalproduktivität). Die Aggregation läuft Bottom-Up zur Bereichs- und dann zur Konzern-Abweichung mit P&L-Bridge nach HGB §275, IAS 1 und IFRS 8. Die Forecast-Genauigkeit misst der Agent ML-gestützt per MAPE, RMSE, sMAPE und Bias-Detection nach IDW PS 525. Bei den fünf menschlichen Schritten - Vergleichsbasis, Forecast-Update, Closed-Loop-Maßnahmen, Wirtschaftsbericht-Narrativ und Aufsichtsrats-Eskalation - dokumentiert der Decision Layer Begründung, Datenbasis und Verantwortlichen.

## Closed-Loop-Action transformiert Reporting-Theater in operative Steuerung

Eine Abweichung von minus 340.000 Euro bei den Materialkosten sagt für sich genommen wenig. Erst die Driver-Tree-Decomposition macht sie handlungsrelevant: 180.000 Euro Price-Variance durch gestiegene Rohstoffpreise (Einkauf-Verantwortung), 95.000 Euro Volume-Variance durch höheren Ausschuss in der Produktion (Produktions-Verantwortung), 65.000 Euro Mix-Variance durch Verschiebung zu margenärmeren Produktvarianten (Vertriebs-Verantwortung). Jede Komponente erfordert eine andere Reaktion. Eine geschlossene Maßnahme überführt jede wesentliche Abweichung in einen strukturierten Workflow mit fünf Pflicht-Angaben: die Abweichung samt Driver-Zerlegung (Was?), den benannten Owner (Wer?), die konkrete Maßnahme (Wie?), die Deadline (Wann?) und den messbaren Erfolgs-KPI (Wie viel?). Die übliche Excel-Kommentierung erschöpft sich dagegen in Erläuterungen ohne Konsequenz - das ist Reporting-Theater nach DCGK B.6. KonTraG §91 Abs. 2 verlangt neben der Risiko-Identifikation auch die Umsetzung der Reaktionen und die Überwachung ihrer Wirksamkeit; bei Versäumnis haften Vorstand (§93 AktG) und Aufsichtsrat (§116 AktG). IDW PS 340 prüft das Risikofrüherkennungssystem auf Wirksamkeit, Vollständigkeit und Aktualität anhand der Workflow-Dokumentation. Der Decision Layer dokumentiert jede Maßnahme mit Audit-Trail, eskaliert bei Verzögerung und informiert bei wesentlichen Maßnahmen den Aufsichtsrat nach AktG §90 und DCGK D.4. Bei auffälligen Abweichungen werden Aufsichtsrat, Wirtschaftsprüfer und gegebenenfalls externe Forensik-Berater nach FISG 2021 eingebunden, bei kursrelevanten Erkenntnissen auch die BaFin.

## Edge-Cases mit deutscher Compliance-Spezifik

Bei kapitalmarktorientierten Unternehmen gelten die DPR-Prüfungsschwerpunkte 2024-2026: Wesentlichkeitsschwellen im Wirtschaftsbericht, Konsistenz der Abweichungs-Disclosure mit dem Prognosebericht und die IAS-36-Goodwill-Werthaltigkeit bei abweichungsgetriebenen Trigger-Events. Ein Mängelbericht ist im Bundesanzeiger zu veröffentlichen, nachfolgende Berichte sind anzupassen, eine BaFin-Folgeprüfung schließt sich an. Bei Konzernen verlangt DRS 20.62 ff. den Soll-Ist-Vergleich mit quantifizierten Beträgen, Driver-Zerlegung, Begründung und Aktualisierung des Prognoseberichts; die Wesentlichkeit nach DRS 20.116 ff. wird quantitativ (über 1 Prozent Konzernergebnis) wie qualitativ (strategische Bedeutung) bewertet. Bei Personalkosten-Abweichungen mit Mitarbeiterdaten greifen DSGVO Art. 22 (keine automatisierte Einzelfallentscheidung), das Erforderlichkeitsprinzip nach BDSG §26 und die Mitbestimmung des Betriebsrats (BetrVG §80, §87 Abs. 1 Nr. 6, §92, §106). Beim FX-Hedging löst der Agent die Hedging-Positionen nach IAS 21, IFRS 9 (mit Hedge-Effectiveness-Test) und IFRS 7 in die FX-Variance auf. Deuten Abweichungen auf Sanierungsbedarf, greifen StaRUG 2021, IDW S 11 und die 3-Wochen-Insolvenzantragsfrist nach InsO §15a; der Agent erkennt solche Trigger früh als Compliance-Evidenz. Für die Forensik-Audit-Vorbereitung nach FISG 2021 dokumentiert er strukturierte Anomalie-Erkennung (Benford-Law, Round-Number-Bias, Last-Minute-Buchungen), eine Hash-Validierung der Plan- und Ist-Daten gegen Manipulation und die Erklärungen zu jeder Abweichung.

## Zusammenspiel mit dem Financial-Forecast-Agent und Anbindung an die FP&A-Plattformen

Der Budget-Variance-Agent ergänzt den Financial-Forecast-Agent: Er betrachtet den Rückblick - den Soll-Ist-Vergleich mit Driver-Zerlegung und geschlossener Maßnahme für die Budget-Owner-Accountability nach HGB §289, DRS 20.62 ff. und KonTraG §91 Abs. 2 -, während der Forecast-Agent das prospektive 3-Statement-Modell mit 12- bis 18-Monats-Rolling-Horizon nach IAS 1, IAS 8 und DRS 20 für die Vorstands-Berichtspflicht nach AktG §90 verantwortet. Die Abweichungs-Erkenntnisse speisen das Forecast-Update (Bias-Detection, strukturelle Trends, Einmaleffekte); umgekehrt nutzt der Variance-Agent die Plan-Daten des Forecast-Agents als Vergleichsbasis, wenn der Forecast statt des Originalbudgets herangezogen wird. Angebunden ist der Agent an die führenden FP&A-Plattformen: SAP S/4HANA Finance mit SAP Analytics Cloud und Group Reporting nach HGB §297 als Konzern-Standard, Lucanet als DRS-20-Spezialist für den deutschen Mittelstand (rund 4.500 Kunden) mit eigenem Soll-Ist-Modul und prüfungssicheren Audit-Trails, Anaplan mit Hyperblock-Engine für mehrdimensionale Analyse und Maßnahmen-Tracking, Workday Adaptive Planning mit Cloud-FP&A sowie Jedox (rund 2.500 Kunden) mit Excel-naher Bedienung. Die Hauptbuch-Anbindung läuft über SAP Universal Journal, DATEV-Belegtransfer, Lucanet-Konten-Mapping und Microsoft-Dynamics-Connector; den Closed-Loop-Workflow verbindet der Agent mit Jira, Microsoft Planner und ServiceNow für Owner-Zuordnung und Deadline-Tracking. Bei kapitalmarktorientierten Unternehmen kommen das ESEF-XBRL-Tagging des Wirtschaftsberichts (Pflicht ab GJ 2020), die DSGVO-Art.-22-Konformität über die Decider-Trennung R/A/H mit Challengeable-Feld und die Aufsichtsrats-Eskalation nach AktG §90, §107 und §171 hinzu.

--- Zahlungseingangszuordnungs-Agent ---
> Liest Kontoauszüge ein, ordnet Zahlungen Debitoren und offenen Rechnungen zu, validiert Skonto-Abzüge und erstellt Ausgleichsbuchungen.

Zwischen Zahlungseingang und gebuchtem Forderungsausgleich liegen in vielen Unternehmen Stunden manueller Zuordnungsarbeit. Sachbearbeiter gleichen Kontoauszüge mit offenen Posten ab, prüfen Verwendungszwecke, identifizieren abweichende Zahler und klären Differenzen. Bei Unternehmen mit mehreren hundert Zahlungseingängen pro Tag bindet dieser Prozess Fachkräfte, die ihre Kompetenz eigentlich für Klärungsfälle und Kundenbeziehungen einsetzen sollten. Gleichzeitig verzögert jede Stunde ohne Zuordnung die Liquiditätswirkung der Zahlung - und verschlechtert die Days Sales Outstanding.

## Jeder Tag ohne Zuordnung verschlechtert das Working Capital

Die durchschnittliche DSO liegt branchenübergreifend bei 57 Tagen - obwohl die meisten Unternehmen Zahlungsziele von 28 Tagen vereinbaren (Quelle: Kapittx, 2025). Diese Lücke von fast 30 Tagen entsteht nicht nur durch säumige Zahler. Ein erheblicher Teil geht auf interne Verzögerungen zurück: Zahlungen, die zwar eingegangen, aber noch nicht zugeordnet und damit nicht als Forderungsausgleich verbucht sind.

Für ein Unternehmen mit 50 Millionen Euro Jahresumsatz bedeutet jeder Tag DSO-Reduktion rund 137.000 Euro freigesetztes Working Capital. Cash Application ist damit kein administrativer Nebenprozess, sondern ein direkter Hebel auf die Bilanzqualität.

## 80 Prozent der Zuordnungen folgen einem festen Regelwerk

Die manuelle Zuordnung suggeriert Komplexität, die in der Mehrheit der Fälle nicht existiert. Eine Analyse typischer Zahlungseingänge zeigt: Rund 80 Prozent lassen sich über Rechnungsnummer im Verwendungszweck, Betrag und Debitorenstammdaten eindeutig zuordnen. Unternehmen mit automatisierter Cash Application erreichen laut Emagia (2025) Zuordnungsgenauigkeiten von 95 bis 98 Prozent und reduzieren die manuelle Bearbeitungszeit um 80 bis 90 Prozent.

Der entscheidende Punkt: Diese hohe Quote ist kein Ergebnis von KI im engeren Sinne. Sie basiert auf deterministischen Regeln - Kontoauszug parsen, Referenz abgleichen, Betrag prüfen, Buchungssatz erzeugen. Das Regelwerk liefert reproduzierbare, prüfbare Ergebnisse. Genau das macht den Prozess GoBD-konform automatisierbar.

## Abweichende Zahler und Teilzahlungen brauchen ein gestuftes Entscheidungsmodell

Die verbleibenden 20 Prozent sind der Grund, warum vollständige Automatisierung ohne Entscheidungsarchitektur scheitert. Typische Szenarien: Ein Konzernverbund zahlt über eine zentrale Zahlstelle, deren Name nicht mit dem Debitor übereinstimmt. Ein Kunde begleicht drei Rechnungen in einer Sammelüberweisung, zieht aber bei einer Rechnung Skonto ab, obwohl die Frist abgelaufen ist. Oder eine Zahlung liegt 47 Euro unter dem Rechnungsbetrag - Rundungsdifferenz, berechtigter Abzug oder Fehler?

Der [Decision Layer](/de/decision-layer/) unterscheidet diese Fälle durch Eskalationsstufen. Stufe 1 - das Regelwerk - löst den exakten Abgleich: CAMT.053-Parsing, Rechnungsnummer-Matching, Skonto-Fristprüfung gegen Vertragsdaten. Stufe 2 - unscharfes Matching - greift bei abweichenden Zahlern, indem es Bankverbindungen aus Stammdaten, historische Zahlungsmuster und Namensähnlichkeiten kombiniert. Erst wenn beide Stufen keine eindeutige Zuordnung liefern, eskaliert der Agent an den Sachbearbeiter - mit allen gesammelten Kontextinformationen zur Entscheidungsvorbereitung.

## Der Sachbearbeiter wird zum Klärungsexperten

In der manuellen Welt verbringt ein Sachbearbeiter den Großteil seiner Zeit mit Routinezuordnungen, die keinerlei fachliche Beurteilung erfordern. Die eigentliche Expertise - Kundenhistorie einschätzen, Zahlungsverhalten interpretieren, kaufmännische Entscheidungen bei Differenzen treffen - kommt zu kurz, weil die Masse an Standardfällen den Arbeitstag dominiert.

Nach Einführung des Cash-Application-Agents verschiebt sich dieses Verhältnis grundlegend. Der Agent übernimmt die regelbasierten Zuordnungen und bereitet die Klärungsfälle so auf, dass der Sachbearbeiter sofort entscheidungsfähig ist: Welcher Debitor kommt in Frage, welche offenen Posten passen zum Betrag, welche Matching-Methode wurde versucht, warum hat keine gegriffen. Die Rolle wandelt sich vom Zuordner zum Klärungsexperten.

Für das Unternehmen entsteht ein doppelter Effekt. Die Durchlaufzeit vom Zahlungseingang bis zur Verbuchung sinkt von Stunden auf Minuten für Standardfälle. Und die Klärungsquote bei Problemfällen steigt, weil Fachkräfte ihre Zeit auf die Fälle konzentrieren, die menschliche Urteilskraft tatsächlich erfordern.

--- Cash-Forecasting-Agent ---
> Aggregiert Cashflows aus EBICS CAMT.052/053/054, modelliert 13-Wochen-Direktforecast nach IAS 7 und DRS 21, prüft AktG §91 sowie InsO §15a und liefert MaRisk-konformes Bank-Reporting.

Die Cashflow-Prognose steht in Deutschland zwischen fünf parallelen Compliance-Anforderungen mit sehr unterschiedlichen Konsequenzen. AktG §91 Abs. 2 verlangt seit dem KonTraG 1998 ein Risikofrüherkennungssystem, dessen Kernbestandteil die nachweisbare Cashflow-Prognose ist. InsO §15a verpflichtet bei Zahlungsunfähigkeit oder Überschuldung zur Insolvenzantragstellung binnen drei Wochen - strafbewehrt mit Freiheitsstrafe bis drei Jahre nach §15a Abs. 4 und mit persönlicher Vorstandshaftung für jede Zahlung nach Insolvenzreife (§92 AktG, §15b InsO). Die deutschen Hausbanken verlangen für die Mittelstands-Kreditprüfung den 13-Wochen-Direktforecast als Industrie-Standard mit Kennzahlen wie DSCR (mindestens 1,2) und Interest Coverage (mindestens 2,0). Die DPR prüft kapitalmarktorientierte Unternehmen stichprobenartig nach WpHG §114-117, 2024-2026 mit Schwerpunkt auf Going-Concern-Annahmen, Klimarisiken und Konsolidierung. Und die Standards IDW PS 270, PS 340 und PS 522 regeln die Wirtschaftsprüfer-Methodik mit Folgen für Bilanzeid und Bestätigungsvermerk. Damit kann jede Liquiditätsplanung im deutschen Konzern oder gehobenen Mittelstand bis zu fünf Pflichten gleichzeitig auslösen.

## 660.000 EUR Verlust pro Jahr durch ungenaue Prognosen, dazu 91 Prozent höhere Überziehungsgebühren

Treasury Management International dokumentiert in der Cashflow-Survey 2024: Mittelständler mit unzuverlässigen Prognosen verlieren durchschnittlich 660.000 EUR pro Jahr - nicht durch fehlende Liquidität selbst, sondern durch überhöhte Kontokorrent-Zinsen, verpasste Festgeld-Anlagen und ungeplante Notfinanzierung. Die Agicap-Studie 2024 unter britischen und deutschen Mittelständlern ergänzt: Firmen mit Excel-Forecasts zahlen 91 Prozent höhere Überziehungsgebühren als vergleichbare Unternehmen mit belastbaren, ML-gestützten Forecasts und EBICS-CAMT-Integration. Ein Treasurer, der seinen 13-Wochen-Forecast manuell in Excel pflegt, erreicht laut CTMfile 2025 durchschnittlich 60 Prozent Genauigkeit - bei einer Abweichung von 40 Prozent auf einen prognostizierten Cashflow von 20 Mio EUR entsteht ein Unsicherheitskorridor von 8 Mio EUR; diese Bandbreite zwingt das Treasury entweder zu dauerhaft überhöhten Liquiditätsreserven mit gebundenem Kapital ohne Rendite oder zu zu knappen Puffern mit teuren Überbrückungskrediten.

Der PwC Treasury Benchmark 2024 ergänzt: 73 Prozent der deutschen Mittelständler tun sich schwer, die für einen belastbaren Forecast nötigen Cashflow-Daten zu identifizieren; 62 Prozent nennen die Multi-Bank-Konsolidierung und EBICS-CAMT-Aggregation als größte technische Hürde, 47 Prozent halten ihre Tools für die Hausbank-Kreditprüfung für unzureichend. Parallel sind laut DPR-Statistik 2024 die Going-Concern-Annahmen und die DRS-21-Konzernkapitalflussrechnung wiederkehrende Prüfungsschwerpunkte mit überdurchschnittlicher Mängelbericht-Quote - mit Kursreaktionen von typisch -3 bis -8 Prozent und BaFin-Bußgeldern bis 10 Mio EUR oder 5 Prozent Jahresumsatz nach §120. Hinzu kommen die Haftungsrisiken: die unbeschränkte persönliche Haftung nach §93 AktG bei versäumter Risikofrüherkennung, die strafbewehrte 3-Wochen-Frist nach InsO §15a und der D&O-Selbstbehalt von 10 Prozent nach VorstAG.

## Die 16 deterministischen Entscheidungspunkte mit fünf menschlichen Eskalationen

Der Agent zerlegt das Forecasting in 16 strukturierte Entscheidungspunkte: zwölf regelbasierte Klassifikationen, zwei ML-basierte Analytik-Schritte (Saisonalitätsmuster mit STL, ARIMA und Prophet; Zahlungsverzugs-Wahrscheinlichkeiten je Debitor mit Logistic Regression und Gradient Boosting) und fünf menschliche Eskalationen für die Best/Base/Worst-Case-Szenarien, die Liquiditätsreserve, die Kreditlinien-Aktivierung, die Aufsichtsrats-Eskalation nach §107 AktG und die Going-Concern-Klassifikation. Die regelbasierten Schritte umfassen die EBICS-CAMT-Aggregation, die IAS-7-Klassifikation nach DRS 21 und HGB §297, die Fälligkeitsstruktur von Forderungen und Verbindlichkeiten, die Lohn-, Lohnsteuer- und SV-Beitragsfälligkeiten, die FX-Exposure-Berechnung, die Forecast-Aggregation sowie die Sensitivitätsanalyse, die Going-Concern-Prüfung und das Hausbank-Reporting. Die ML-Komponenten liefern ausschließlich Indikatoren mit Confidence-Scores und dokumentierten Annahmen, niemals Endentscheidungen - DSGVO-Art.-22-konform ohne automatisierte Einzelfallentscheidung mit Rechtswirkung.

Ein konkretes Beispiel: ein Industrieunternehmen mit 1.800 Mitarbeitern, 750 Mio EUR Umsatz, 12 Bankkonten in 6 Bankhäusern (3 DSGV-Sparkassen, 2 Volksbanken, 1 Geschäftsbank). Der Agent prüft die EBICS-Konnektivität: 11 Konten EBICS 3.0 verbunden, 1 Konto über PSD2 XS2A. Die CAMT-Aggregation lädt 24 Monate CAMT.053-Endtag und die aktuellen CAMT.052-Intraday-Dateien mit Hash-Validierung und Bank-Signatur-Prüfung. Die IAS-7-Klassifikation teilt 47.300 Buchungen per Buchungstext-Parsing, DATEV-Kontenrahmen und SAP-Buchungskreis-Mapping in Operating, Investing und Financing auf. Das Forderungs-Aging zeigt 42,3 Mio EUR offene Forderungen mit Fälligkeitsstaffel (0-30/31-60/61-90/90+ Tage), das Verbindlichkeits-Aging 28,7 Mio EUR. Die Lohn-Cashflows betragen 8,2 Mio EUR monatlich, dazu 2,1 Mio EUR SV-Beiträge und 1,8 Mio EUR Lohnsteuer mit dokumentierten Terminen. Die Saisonalitätserkennung findet per STL und ARIMA-Prophet einen starken Q4-Peak (Stärke 0,73, Confidence 0,81) und einen Monats-Mittelpeak nach der SV-Beitragsfälligkeit. Für 1.840 Debitoren bestimmt das Modell die Verzugs-Wahrscheinlichkeit (Logistic Regression) und die DSO-Vorhersage (Gradient Boosting), AGG-konform validiert. Das FX-Exposure liegt bei 11,2 Mio USD und 4,8 Mio GBP mit ECB-Forward-Kursen. Der 13-Wochen-Forecast entsteht in wöchentlichen Buckets je Banking-Cluster; das Best-Case-Szenario zeigt 8,4 Mio EUR Liquiditäts-Plus, das Base-Case 4,2 Mio EUR, das Worst-Case -1,8 Mio EUR (Wahrscheinlichkeit 14 Prozent). Der Treasurer entscheidet: die Liquiditätsreserve von 5 auf 7 Prozent des Auszahlungsvolumens anzuheben, die Kontokorrent-Reserve von 5 Mio EUR bei der Sparkasse zu aktivieren und den Aufsichtsrat bei Eintritt des Worst-Case zu informieren. Die Going-Concern-Indikatoren bleiben unkritisch (kein IDW-PS-270-Hinweis nötig); das Hausbank-Quartalsmeeting mit DSCR 1,7, Interest Coverage 3,2 und Free-Cashflow-Marge 8,4 Prozent ist prüfungsbereit.

## Strategische Annahmen und Going-Concern-Bewertung bleiben Vorstandsaufgaben

Der Agent kann Cashflows aggregieren, nach IAS 7 klassifizieren, ML-basierte Saisonalitätsmuster erkennen und 13-Wochen-Forecasts erzeugen. Was er nicht kann: entscheiden, welche Annahmen für ein Best/Base/Worst-Case-Szenario realistisch sind oder ob die Liquiditätsreserve anzuheben oder zu senken ist. Solche Annahmen erfordern ein menschliches Urteil zum Zahlungsverhalten von Großkunden, zur Verschiebbarkeit von Investitionen und zu Stressszenarien wie einer Hauptkunden-Insolvenz - sie sind keine Rechenaufgabe, sondern eine Einordnung. Bei kapitalmarktorientierten Unternehmen wird die Going-Concern-Bewertung Prüfungsschwerpunkt der DPR-Bilanzkontrolle und des IDW-PS-270-Substantive-Testing.

Die Liquiditätsreserve ist die zweite kritische Entscheidung: Die Hausbank-Konditionen, die Risikofrüherkennungs-Pflicht nach AktG §91 Abs. 2, das DCGK-Liquiditätsmanagement (A.5) und die Zahlungsunfähigkeits-Prävention nach InsO §17 setzen den Mindestbedarf typisch auf 5 bis 15 Prozent des 13-Wochen-Auszahlungsvolumens; die konkrete Höhe ist eine Risikotoleranz-Entscheidung des CFO oder Treasurers, bei substanziellem Volumen mit Vorstands-Information. Die Kreditlinien-Aktivierung ist die dritte strategische Entscheidung: Sie wägt Zinskosten, Hausbank-Verhandlungsposition, EZB-Refinanzierungssatz und die HGB-§289-Risikoberichterstattung ab und eskaliert bei großem Volumen verpflichtend.

## Edge-Cases: Konzern-Konsolidierung DRS 21, Multi-Bank-EBICS, FX-Hedging, Insolvenz-Vorbereitung und Mehrfach-Reporting-Pflicht

Die Konzern-Konsolidierung nach DRS 21 ist der häufigste Edge-Case: Tochtergesellschaften mit unterschiedlichen ERPs und Bankhäusern werden zur konsolidierten Konzernkapitalflussrechnung zusammengeführt - mit Eliminierung der Intercompany-Cashflows nach §300 HGB, anteiliger Aufteilung und der Zuordnung von Dividenden-Cashflows zwischen Operating und Financing. Der Agent verbindet IAS 7, DRS 21, IFRS-3-Goodwill und Earn-Out-Klauseln in einer einheitlichen Konsolidierung mit Datenherkunfts-Audit-Trail nach DRS 20 und DRS 5. Der zweite Edge-Case ist die Multi-Bank-Konnektivität: konzernweite EBICS-Standardisierung mit PSD2-XS2A- und SWIFT-Backup, Notfallplan bei einzelnen Bank-Ausfällen und einer Cashpooling-Struktur aus Konzentrations- sowie Master-Sub-Konten.

Der dritte Edge-Case ist das FX-Hedging: Bei Konzernen mit mehreren Währungs-Exposures (typisch USD, GBP, CHF, JPY, CNY) verbindet der Agent die Wechselkurs-Effekte nach IAS 21, das Hedge Accounting nach IFRS 9, die HGB-§256a-Stichtagsbewertung und Forward-Kurse aus Bloomberg oder Reuters; das Cash Flow Hedge Accounting verlangt prospektive und retrospektive Effektivitäts-Tests (Bandbreite 80 bis 125 Prozent) mit OCI-Reklassifikation. Der vierte Edge-Case ist die Insolvenz-Vorbereitung: Bei Going-Concern-relevanten Engpässen startet der Agent den 3-Wochen-Countdown nach InsO §15a, eskaliert an Vorstand, Aufsichtsrat und Wirtschaftsprüfer und bereitet die Berater-Übergabe, die Sanierungsoptionen und die StaRUG-Eigenverwaltung vor; auch der KfW-Förderkredit-Nachweis wird als Sanierungs-Option strukturiert. Der fünfte Edge-Case ist die Mehrfach-Reporting-Pflicht kapitalmarktorientierter Unternehmen: Hier laufen DRS 21 (deutsche GAAP), IAS 7 (IFRS) und US GAAP ASC 230 parallel, ergänzt um DPR-Pflichten, IDW-PS-270-Testing und SREP-Reporting; der Agent erzeugt das Mapping-Dokument mit parallelen Disclosures und Äquivalenz-Tabelle.

## Integration mit DATEV TopBank, SAP S/4HANA Treasury, Lucanet Cashflow, Kyriba und der deutschen Bankenarchitektur

Der Agent bindet die führenden deutschen und internationalen Treasury-Management-Systeme per API an: SAP S/4HANA Treasury and Risk Management mit Cash Management, Bank Communication Management und Liquidity Planner als Konzern-Standard mit EBICS-Konnektor; DATEV TopBank und DATEV Liquiditätsplanung als Mittelstands-Marktführer (rund 40.000 Kunden); Lucanet Cashflow als DRS-21-Spezialist mit XBRL-Schnittstelle; und Kyriba mit Cash Management, Liquidity Planning und Bank Connectivity Suite über globales EBICS und SWIFT. Ergänzend integrieren sich BMD NTCS Treasury, FIS, Reval/Ion Treasury, Tipco, das ifr-Modul, Sage XRT, Diamant/3, Microsoft Dynamics 365 Finance und Oracle Hyperion/EPM. Die EBICS-Konnektivität läuft über die Standard-Schnittstelle der Deutschen Kreditwirtschaft mit RSA-2048/4096-Schlüsseln, SHA-256-Signaturen und dreistufiger Authentifizierung (E002, X002, A005/A006); die PSD2-XS2A-Anbindung über lizenzierte AISP mit Strong Customer Authentication. Die CAMT-Dateien (CAMT.052, .053, .054 nach ISO 20022) werden mit Hash-Validierung und Bank-Signatur-Prüfung verarbeitet. Für das Going-Concern-Testing nach IDW PS 270 exportiert der Agent an Deloitte ASM, PwC Aura, EY Helix und KPMG Clara - mit IAS-7-/DRS-21-Klassifikation, Datenherkunfts-Audit-Trail und Sensitivitätsanalyse. Bei kapitalmarktorientierten Unternehmen kommen die DPR-Prüfungsvorbereitung (Schwerpunkte 2024-2026: Going-Concern, Klimarisiken, Konsolidierung), der BaFin-Anzeige-Workflow nach WpHG §114-117 und die Aufsichtsrats-Aggregation nach §107 AktG hinzu. Die DSGVO-Konformität sichert die Decider-Trennung R/A/H mit Challengeable-Feld, eine DPIA nach Art. 35 bei Mitarbeiterdaten, die BetrVG-Mitbestimmung mit Pseudonymisierung und die AGG-Fairness-Metriken beim Zahlungsverzugs-Modell. Bei Going-Concern-relevanten Engpässen startet der Agent den 3-Wochen-Countdown nach InsO §15a mit Pflicht-Eskalation, Berater-Übergabe und StaRUG-Eigenverwaltungs-Vorbereitung.

--- Close-Checklisten-Agent ---
> Verwaltet die Close-Checkliste mit Aufgaben-Dependencies, überwacht den Status jeder Aufgabe, eskaliert bei Verzug und generiert das Close-Protokoll.

Der Monatsabschluss ist kein Buchungsproblem. Jede einzelne Buchung, Abstimmung und Konsolidierung ist für sich genommen beherrschbar. Was den Close auf sechs, acht oder zehn Arbeitstage streckt, ist die Koordination zwischen diesen Schritten - wer wartet auf wen, welche Aufgabe blockiert die nächste, und wo liegt ein Verzug, den noch niemand bemerkt hat. Der Close-Checklisten-Agent löst genau dieses Orchestrierungsproblem. Regelbasiert, ohne eigene Buchungslogik, ohne KI.

## Die meisten Finance-Teams brauchen über eine Woche für den Close

Die Zahlen sind eindeutig: APQC beziffert den Median des Monatsabschlusses branchenübergreifend auf 6,4 Tage. Ein Großteil der Finance-Teams benötigt regelmäßig mehr als sechs Arbeitstage, nur eine Minderheit schafft den Close in drei Tagen oder weniger.

Die Ursache liegt selten in der Komplexität einzelner Aufgaben. Die meisten Teams arbeiten im Close noch mit Excel-Checklisten, in denen Abhängigkeiten zwischen Aufgaben nicht abgebildet sind. Eine vergessene Intercompany-Abstimmung blockiert die Konsolidierung. Ein verspätetes Accrual hält den Completeness-Check auf. Die Verzögerung wird erst sichtbar, wenn die Frist bereits gerissen ist.

## Orchestrierung schlägt Einzelautomatisierung

Viele Unternehmen automatisieren einzelne Close-Schritte - Abstimmungen, Journalbuchungen, Rückstellungen. Jeder dieser Schritte wird schneller. Trotzdem verkürzt sich der Gesamtprozess kaum. Denn zwischen den automatisierten Inseln liegen manuelle Übergaben, unklare Reihenfolgen und Wartezeiten ohne Eskalation.

Der Trend in CFO-Befragungen ist eindeutig: Der Fokus verschiebt sich von isolierter Automatisierung hin zu Prozess-Orchestrierung. Unternehmen, die integrierte Steuerung einführen, berichten von besserem Working Capital, reduzierten Risiken und schnelleren Entscheidungen. Der entscheidende Hebel liegt nicht im schnelleren Buchen, sondern im Beseitigen der toten Zeit zwischen den Buchungen.

Für den Monatsabschluss bedeutet das konkret: Solange kein System die Aufgabenreihenfolge kennt und durchsetzt, bleibt der Close so langsam wie seine langsamste manuelle Übergabe.

## Zehn regelbasierte Entscheidungen steuern den gesamten Ablauf

Der [Decision Layer](/de/decision-layer/) zerlegt die Close-Orchestrierung in zehn Entscheidungsschritte - alle auf Stufe R (Regelwerk), keine KI-Beteiligung. Ein konkretes Szenario macht die Logik greifbar.

Freitagnachmittag, dritter Arbeitstag im Close. Der Agent prüft die Dependency-Kette: Die Intercompany-Abstimmung für Gesellschaft DE03 steht noch auf "offen". Die nachgelagerte Konsolidierung kann nicht starten. Das Regelwerk erkennt die Blockade automatisch, vergleicht den geplanten Fertigstellungstermin mit dem aktuellen Datum und stuft die Aufgabe als überfällig ein. Die konfigurierte Eskalationsmatrix greift: Erst geht die Benachrichtigung an den Verantwortlichen, nach vier Stunden ohne Statusänderung an den Head of Accounting.

Parallel trackt der Agent den Status aller anderen Aufgaben. Abgeschlossene Schritte geben ihre abhängigen Folgeaufgaben frei. Der Completeness-Check am Ende vergleicht die erledigten Aufgaben gegen die konfigurierte Pflichtliste. Fehlt ein Schritt, bleibt der Close offen - keine Ausnahmen, kein manuelles Überschreiben ohne dokumentierten Grund.

Entscheidend: Der Agent bucht nichts, berechnet nichts, bewertet nichts. Er steuert ausschließlich die Reihenfolge und Vollständigkeit. Diese klare Begrenzung macht ihn robust und prüfbar.

## Das Close-Protokoll entsteht als Nebenprodukt

Jeder Close-Zyklus erzeugt ein vollständiges Protokoll - nicht als zusätzliche Dokumentationsaufgabe, sondern als automatisches Ergebnis der Orchestrierung. Jede Statusänderung, jede Eskalation, jeder Zeitstempel wird festgehalten: wer hat welche Aufgabe wann abgeschlossen, welche Abhängigkeiten wurden geprüft, wo gab es Verzug.

Für Wirtschaftsprüfer und interne Governance ist dieses Protokoll der Nachweis eines ordnungsgemäßen Abschlussprozesses nach HGB §243. Kein nachträgliches Zusammensuchen von E-Mails und Excel-Dateien. Keine Rekonstruktion aus dem Gedächtnis. Der Close-Prozess dokumentiert sich selbst, während er läuft.

Unternehmen, die vom sechs-Tage-Close auf zwei bis drei Tage kommen wollen, brauchen keinen schnelleren Buchhalter. Sie brauchen ein System, das die Abhängigkeiten zwischen 30, 50 oder 80 Close-Aufgaben kennt, Blockaden in Echtzeit erkennt und Verantwortliche ohne Verzögerung einbindet. Genau das leistet regelbasierte Orchestrierung im Decision Layer.

--- Consolidation-Agent ---
> Erstellt Konzernabschluss via Vollkonsolidierung HGB §300-305, Equity-Methode HGB §312, IFRS 10/11/12, Goodwill-Impairment IAS 36 und latenten Steuern DRS 19 - DPR-prüfungssicherer Audit-Trail.

Die Konzernabschluss-Konsolidierung steht in Deutschland zwischen vier parallelen Compliance-Themen mit sehr unterschiedlichen Konsequenzen. HGB §290-315e fordert die Voll-, Quoten- oder Equity-Konsolidierung mit detaillierten Buchungen nach §297-305 (Kapital, Schulden, Aufwand-Ertrag, Zwischenergebnis), den Konzern-Anhang (§313-314), den Konzernlagebericht (§315) und die Pflichtprüfung (§316-317). Bei kapitalmarktorientierten Konzernen verlangt §315a HGB zusätzlich IFRS 10/11/12 mit dem Beherrschungs-Konzept, das Currency Translation Adjustment nach IAS 21, die Equity-Methode nach IAS 28 und den jährlichen Goodwill-Impairment-Test nach IAS 36. DRS 23, DRS 19 und DRS 25 konkretisieren die HGB-Praxis, während DCGK B.6 und FISG 2021 die Prüfungsausschuss-Pflichten nach AktG §107 verschärfen - mit unabhängigem Finanz-Experten, Prüfer-Rotation nach zehn Jahren und Bilanzeid-Strafrecht nach §331 HGB. Damit kann jeder Konzernabschluss eines DAX-, MDAX- oder SDAX-Konzerns bis zu vier Pflichten gleichzeitig auslösen.

## DPR-Mängelbericht-Risiko: BaFin-Sanktionen bis 10 Mio EUR und erheblicher Reputationsverlust

Die Deutsche Prüfstelle für Rechnungslegung (DPR) prüft kapitalmarktorientierte Konzernabschlüsse stichprobenartig nach WpHG §114-117 mit einer jährlichen Quote von rund 7 Prozent. Laut DPR-Statistik 2024 haben durchschnittlich 35 Prozent der geprüften Unternehmen Befunde mit Mängelbericht-Pflichtveröffentlichung im Bundesanzeiger. Die Prüfungsschwerpunkte 2024-2026 liegen auf dem Goodwill-Impairment nach IAS 36 (überproportionale Befundquote von 38 Prozent), den latenten Steuern nach IAS 12 (32 Prozent), der Leasing-Konsolidierung nach IFRS 16 (28 Prozent), dem Hedge Accounting nach IFRS 9 (25 Prozent) und den EU-Taxonomie-Disclosures (42 Prozent). Das Verfahren ist zweistufig: Akzeptiert das Unternehmen die Befunde, folgt die Mängelbericht-Veröffentlichung; akzeptiert es sie nicht, folgt die BaFin-Folgeprüfung mit Sanktionen bis 10 Mio EUR oder 5 Prozent Jahresumsatz nach §120. Hinzu kommen ein typischer Kursrückgang von 3 bis 8 Prozent in den drei Handelstagen nach Veröffentlichung und die Erörterung in der Hauptversammlung mit Anfechtungsrechten. Der Agent dokumentiert die Konformität mit den Prüfungsschwerpunkten und erstellt die Substantive-Testing-Vorbereitung für die Konzernabschluss-Prüfung nach IDW PS 230.

## Sechzehn regelbasierte Konsolidierungsentscheidungen und ein menschlicher Eskalationspunkt

Der Agent zerlegt den Konzernabschluss in 16 Micro-Entscheidungen, die bis auf einen Goodwill-Impairment-Indikator alle regelbasiert ablaufen. Jede dokumentiert Schritt, Entscheidungsfrage, Decider-Klassifikation (R für regelbasiert, A für ML-Indikator ohne finale Entscheidung, H für menschliche Pflicht-Eskalation), Begründung mit Statuten-Zitat und Quellsystem-Audit-Trail sowie den Anfechtungspfad. Die 15 R-Entscheidungen reichen von der Konsolidierungskreis-Definition (HGB §290) und der ERP-Datenintegration (IDW PS 330) über die Währungsumrechnung (IAS 21), die HGB-IFRS-Brücke (DRS 19), die Kapital-, Schulden-, Aufwands-Ertrags- und Zwischenergebnis-Konsolidierung (HGB §301, §303, §305, §304), die Equity-Methode (§312 HGB, IAS 28), das Currency Translation Adjustment mit Net Investment Hedge (IFRS 9) und die latenten Steuern (DRS 19, IAS 12) bis zum Konzern-Anhang und -Lagebericht (HGB §313-315), dem ESEF-iXBRL-Tagging (EU-VO 2019/815) und der Bilanzeid-Vorbereitung (§264 Abs. 2 HGB). Die A-Entscheidung ist der Goodwill-Impairment-Test nach IAS 36: ML prüft die DCF-Inputs, den WACC und die Wachstumsraten auf Plausibilität, liefert aber nur einen Indikator - die finale Entscheidung treffen der Konzern-Controlling-Lead, ein externer Bewerter und der Wirtschaftsprüfer (DSGVO-Art.-22-konform). Die H-Entscheidung ist die Aufsichtsrats-Eskalation nach §107 AktG bei Bestandsgefährdung, Going-Concern-Einschätzung und Mängelbericht-Adressierung - ein rein menschliches Urteil von Konzern-CFO, Prüfungsausschuss und externem Wirtschaftsprüfer.

## Plausibilitäts-Check mit DPR-Prüfungsschwerpunkten 2024-2026

Der Agent prüft laufend gegen die DPR-Prüfungsschwerpunkte 2024-2026. Beim Goodwill-Impairment nach IAS 36 plausibilisiert er die DCF-Sensitivität, den WACC, die Wachstumsraten, die Peer-Group-Multiplikatoren und die Triggering Events. Bei den latenten Steuern nach IAS 12 prüft er die Werthaltigkeit der Verlustvorträge, den Konzern-Steuersatz-Mix und den Pillar-Two-Top-Up. Bei der Leasing-Konsolidierung nach IFRS 16 betrachtet er Right-of-Use-Asset, Lease-Liability, Index-Adjustments und Modification-Accounting; beim Hedge Accounting nach IFRS 9 den Effektivitäts-Test, die Hedge-Dokumentation und den Net Investment Hedge. Bei den EU-Taxonomie-Disclosures prüft er das NACE-Code-Mapping, den substanziellen Beitrag und das Do-No-Significant-Harm-Kriterium. Je Schwerpunkt dokumentiert er die Konformität, die Substantive-Testing-Vorbereitung und den IDW-PS-230-Workflow. Bei Auffälligkeiten eskaliert er früh an den Prüfungsausschuss nach §107 AktG und bereitet die Wirtschaftsprüfer-Erörterung und die DPR-Stellungnahme vor.

## Edge-Cases: Hyperinflation nach IAS 29, Pillar Two und Restrukturierungen nach UmwStG

Komplexe Konsolidierungs-Szenarien sind ausdrücklich abgedeckt. Bei Hochinflations-Töchtern (Türkei seit 2022, Argentinien; kumulative Drei-Jahres-Inflation über 100 Prozent) verlangt IAS 29 eine kaufkraftbereinigte, inflationsindexierte Bewertung in einem separaten Workflow. Bei Konzernen über 750 Mio EUR Umsatz greift der Pillar-Two-Top-Up nach OECD-Modell, EU-Richtlinie 2022/2523 und deutschem Mindeststeuer-Gesetz vom 27.12.2023 - mit 15 Prozent Effektivsteuersatz und Top-Up-Tax bei untersteuerten Konzerngesellschaften. Bei Restrukturierungen nach UmwStG (§11-13 Verschmelzung, §15 Spaltung, §20 Einbringung) berücksichtigt der Agent die Buchwert-Fortführung gegen den gemeinen Wert, die Sieben-Jahres-Sperrfrist nach §22 und die Auswirkungen auf die Konsolidierungs-Buchungen. Bei Step-Acquisitions nach IFRS 3 bewertet er die bisherige Beteiligung zum Fair Value neu und berechnet den Goodwill neu; bei Beherrschungs-Verlust beendet er die Vollkonsolidierung und reklassifiziert auf die Equity-Methode oder ein Finanzinvestment.

## Anbindung an deutsche und internationale Konsolidierungs-Plattformen

Der Agent bindet die führenden Konsolidierungs-Plattformen per API an: SAP S/4HANA Group Reporting mit SAP BPC als Konzern-Standard für DAX- und MDAX-Konzerne (Konsolidierung nach HGB §297-305, IFRS 10, DRS 23); Lucanet als Mittelstands-Marktführer (rund 4.500 Konzern-Kunden) mit DRS-23-konformer Konsolidierung und prüfungssicheren Audit-Trails; IBM Cognos Controller mit OLAP-Cube-Engine; Oracle FCCS und Hyperion Financial Management für Multi-GAAP-Konzerne (IFRS, US-GAAP, HGB); OneStream als Unified-Platform-Ansatz; CCH Tagetik und Workiva für ESEF-iXBRL-Tagging und Disclosure-Management; sowie DATEV Konsolidierung für kleinere Konzerne (rund 40.000 Kunden). Ergänzend integrieren sich BlackLine, Trintech Cadency, Microsoft Dynamics 365 Finance und Insightsoftware. Bei kapitalmarktorientierten Konzernen läuft das ESEF-iXBRL-Tagging gegen die ESMA ESEF Taxonomy 2024 nach EU-VO 2019/815 mit Block- und Detail-Tagging der Primary Statements, Validierung und Bundesanzeiger-Submission. Für den Konzern-Wirtschaftsprüfer exportiert der Agent das Substantive-Testing an Deloitte ASM, PwC Aura, EY Helix und KPMG Clara. Bei Auffälligkeiten eskaliert er an den Prüfungsausschuss nach §107 AktG und DCGK B.6 mit Mängel-Erörterung, Bestandsgefährdungs-Klassifikation und Bilanzeid-Vorbereitung nach §264 Abs. 2 HGB.

--- Vertragscompliance-Agent ---
> Vertrags-/Lieferanten-Compliance: LkSG-Sorgfalt ab 1000 MA, VgV/UVgO-Vergabe, AGB §305-310 BGB, §299 StGB, IDW PS 980 CMS und HinSchG-Meldekanal - cert-ready für BKartA.

Vertragscompliance in Deutschland steht zwischen fünf parallelen Regulierungssystemen mit substanziell unterschiedlichen Bussgeldrahmen: das LkSG verlangt seit 2024 von Unternehmen ab 1000 Mitarbeitern systematische Lieferketten-Sorgfaltspflichten mit BAFA-Berichtspflicht, das GWB stellt wettbewerbswidrige Absprachen unter Bussgelder bis 10 Prozent Konzernumsatz, das VgV-Vergaberecht regelt oeffentliche Beschaffung oberhalb der EU-Schwellenwerte mit Vergabekammern als Nachprüfungsinstanz, das AGB-Recht §305-310 BGB überlagert die Vertragsfreiheit mit Inhaltskontrolle, und das HinSchG verpflichtet seit Juli 2023 zu Hinweisgeberkanaelen ab 50 Mitarbeitern. Diese Fünf-Standard-Konstellation bedeutet, dass jeder relevante Geschäftsvertrag in einem deutschen Unternehmen bis zu fünf verschiedene Compliance-Prüfungen ausloesen kann.

## LkSG-Bußgeld bis 8 Mio EUR und 2 Prozent Konzernumsatz - ein Kartellamts-Verfahren kostet 5 bis 15 Prozent Marktwert

Die LkSG-Aufsicht durch das Bundesamt für Wirtschaft und Ausfuhrkontrolle erreichte 2024 die Vollanwendung ab 1000 Mitarbeitern. Die BAFA hat im ersten vollen Aufsichtsjahr über 1100 Berichte ausgewertet und in 38 Fällen ein Bußgeldverfahren eingeleitet - typische Findings sind eine unzureichende Risikoanalyse für mittelbare Zulieferer in Hochrisiko-Ländern, fehlende Präventionsmaßnahmen gegen Kinder- und Zwangsarbeit nach den ILO-Konventionen 138, 182, 29 und 105 sowie unvollständige Beschwerdekanäle ohne Vertraulichkeitsgarantie. Bei nachgewiesenen Verstößen droht zudem der Vergabe-Ausschluss bis drei Jahre nach §22 LkSG - für Unternehmen mit substanziellem Public-Sector-Geschäft existenzgefährdend.

Parallel verfolgt das Bundeskartellamt wettbewerbswidrige Absprachen nach GWB §1-2 und Art. 101 AEUV. 2024 hat es 380 Fälle mit Gesamtbußgeldern von 2,1 Mrd EUR abgeschlossen, mit Schwerpunkt auf vertikaler Preisbindung im Einzelhandel, horizontalen Absprachen in der Bauindustrie und Submissionsabsprachen bei öffentlichen Vergaben. §299 StGB ergänzt die individuelle strafrechtliche Verantwortung mit Freiheitsstrafe bis drei Jahre, in schweren Fällen bis fünf. Der Reputationsschaden eines solchen Verfahrens senkt den Marktwert mittelständischer Unternehmen typisch um 5 bis 15 Prozent in den drei Monaten nach Veröffentlichung.

## Die 15 deterministischen Entscheidungspunkte mit zwei menschlichen Eskalationen

Der Agent zerlegt die Vertragsprüfung in 15 strukturierte Entscheidungspunkte: dreizehn regelbasierte Klassifikationen, zwei LLM-gestützte Screenings (Lieferanten-Risiko und §299-StGB-Korruptions-Indikatoren) und zwei menschliche Eskalationen für die Kartellrechts-Beurteilung und die KWG-Auslagerungsprüfung. Die Vertragserkennung extrahiert per LLM die strukturellen Merkmale - Vertragspartner, Gegenstand, Volumen, Laufzeit und Klauseln. Die regelbasierten Klassifikationen folgen den LkSG-Sorgfaltspflichten (§3-9), den VgV-Schwellenwerten, dem AGB-Klauselverbots-Katalog und der 7-Komponenten-Struktur nach IDW PS 980.

Ein konkretes Beispiel: Ein Mittelständler mit 1850 Mitarbeitern erhält einen Liefervertrag über elektronische Bauteile mit einem Zulieferer in Vietnam, jährliches Volumen 4,8 Mio EUR. Der Agent klassifiziert ihn als LkSG-Pflichtanwender und erkennt den Lieferanten als im BAFA-Hochrisiko-Land Vietnam in der Elektronik-Branche (erhöhte ILO-Indikatoren für Kinderarbeit). Die AGB-Inhaltskontrolle markiert die §309-Nr.-7a-Klausel zum Haftungsausschluss bei grober Fahrlässigkeit als unwirksam, der DSGVO-AVV fehlt vollständig (der Lieferant hat über den Bestellprozess Zugang zu Mitarbeiterdaten) und der HinSchG-Meldekanal beim Lieferanten ist ungeprüft. Der Agent empfiehlt ein Lieferanten-Audit binnen 90 Tagen, die Nachverhandlung der Klausel 14, einen AVV-Nachtrag und den HinSchG-Nachweis. Das BAFA-Berichts-Memo wird GoBD-archiviert.

## Die CMS-Wirksamkeitsprüfung nach IDW PS 980 ist ein Schwerpunkt des Big-4-Testings

Das Substantive-Testing der Big-4 nach PCAOB AS 2110 und IDW PS 980 fokussiert bei der Compliance-Bilanzierung vier Bereiche: die Wirksamkeit der Compliance-Organisation mit Funktionstrennung zwischen Compliance-Officer, Aufsichtsrat und Vorstand (typischer Mangel: Der Compliance-Officer berichtet an den CFO statt den Aufsichtsrat), die Vollständigkeit der Risikoanalyse mit jährlicher Aktualisierung und anlassbezogener Prüfung mittelbarer Zulieferer (LkSG §5 Abs. 2), die Wirksamkeit der Präventions- und Abhilfemaßnahmen mit dokumentierter Stichprobe (BAFA-Prüfberichte 2024 Q4 zeigen 47 Prozent Mängel) und die Disclosure-Vollständigkeit im Lagebericht (§289 HGB), Konzernlagebericht (§315 HGB) und jährlichen LkSG-Bericht. Der Agent erzeugt die CMS-Disclosures automatisch: das 7-Komponenten-Mapping nach IDW PS 980, die Risiko-Heatmap nach BAFA-Hochrisiko-Liste, den Maßnahmen-Status je Komponente, die KPIs zu Beschwerdekanälen, Schulungen und Auditbefunden sowie die Verbandskontrolle nach OWiG §30 und §130 mit Indikatoren für Aufsichtspflichtverletzungen.

## Edge-Cases: Vergabekammern, Kartellamts-Bonusregelung, AVV-Subunternehmer und KWG-Mehrfachauslagerung

Die Vergabekammern als Nachprüfungsinstanz nach §155 GWB sind die haeufigste Edge-Case-Konstellation - bei oeffentlicher Vergabe oberhalb der EU-Schwellenwerte koennen unterlegene Bieter binnen 15 Tagen Antrag stellen. Die Vergabekammer entscheidet binnen 5 Wochen mit aufschiebender Wirkung; Beschwerde zum OLG-Vergabesenat verlängert das Verfahren typisch um 4-6 Monate. Der Agent prüft die Vergabe-Dokumentation auf Verfahrens-Konformität (Bekanntmachungs-Fristen, Eignungs-Prüfung, Wertungs-Begründung) und markiert Risiko-Punkte für Vergabekammer-Verfahren.

Die Bonusregelung des Bundeskartellamts (Bonusbekanntmachung 2017) ermöglicht Selbstanzeigern eine Bußgeld-Reduzierung bis 100 Prozent (Erstanzeige) oder 50 Prozent (Folgeanzeige), dazu Schutz vor strafrechtlicher Verfolgung der Mitarbeiter nach §261 GWB. Bei Indikatoren für einen Kartellrechts-Verstoß nach §1 GWB ist die schnelle Bewertung kritisch - der Agent eskaliert solche Fälle mit Volumens-Dokumentation an externe Kartellrechts-Anwälte. AVV-Subunternehmer-Konstellationen nach Art. 28 Abs. 4 DSGVO sind komplex: Der Hauptauftragsverarbeiter braucht die schriftliche Genehmigung des Verantwortlichen und muss dem Sub-Auftragnehmer identische Datenschutzpflichten auferlegen. Bei KWG-Mehrfachauslagerung (die Bank lagert IT an einen Cloud-Provider aus, dieser wiederum an einen Sub-Provider) verlangt MaRisk AT 9.4 durchgehende Prüfungs- und Weisungsrechte - typische Findings sind Lücken in den Sub-Auslagerungs-Verträgen.

## Integration mit SAP Ariba, DocuSign CLM, Conga und der deutschen Compliance-Architektur

Der Agent bindet die führenden deutschen und internationalen Vertragsmanagement-Systeme per API an: SAP Ariba Contract Management mit SAP S/4HANA Sourcing als Konzern-Standard, DocuSign CLM mit DocuSign Insight (KI-Vertragsprüfung) für mittelständische Implementierungen, Conga CLM mit Salesforce-Integration sowie Ironclad, Coupa und Onventis Cloud Sourcing. Die LkSG-Schnittstelle erzeugt das BAFA-Berichts-XML automatisch; die Vergabe-Plattformen werden über den Vergabe-Marktplatz Deutschland (vmp.de), DTVP, subreport und eVergabe-Bund angebunden. Das Compliance-Reporting läuft an Lucanet Compliance, Wolters Kluwer EnterpriseOne und DATEV Compliance. Für das Big-4-Substantive-Testing exportiert der Agent an Deloitte ASM, PwC Aura, EY Helix und KPMG Clara mit dem 7-Komponenten-Mapping nach IDW PS 980 und PCAOB-AS-1215-Audit-Trail-Metadaten. Die HinSchG-Meldekanäle integrieren sich über spezialisierte Anbieter (Whistlelink, Convercent, NAVEX) und die zentrale Meldestelle des Bundesamts für Justiz. Die Steuerbilanz-Schnittstelle zu DATEV LODAS und SAP TaxBox liefert die GoBD-konforme Verfahrensdokumentation mit qualifiziertem Zeitstempel nach BMF 28.11.2019.

--- Gutschrift/Storno-Agent ---
> Klassifiziert Gutschriften versus Stornorechnungen nach §14 UStG, identifiziert die Bezugsrechnung, berechnet die USt-Korrektur und erstellt die Gegenbuchung.

Falsch klassifizierte Gutschriften und Stornorechnungen gehören zu den häufigsten Umsatzsteuerfunden bei Betriebsprüfungen in Deutschland. Die Ursache ist fast immer dieselbe: Lieferanten verwenden die Begriffe falsch, das ERP übernimmt die Bezeichnung ungeprüft, und die Buchhaltung bucht auf Basis einer falschen Dokumentklasse. Der Gutschrift/Storno-Agent beseitigt dieses Risiko, indem er jedes eingehende Korrekturdokument inhaltlich klassifiziert - unabhängig davon, was auf dem Dokument steht.

## Umsatzsteuer-Korrekturen kosten bei der Betriebsprüfung Milliardenbeträge

Die Dimension des Problems ist messbar. Im Jahr 2024 erzielten die deutschen Finanzbehörden allein durch Umsatzsteuer-Sonderprüfungen ein Mehrergebnis von 1,63 Milliarden Euro aus 63.733 Prüfungen (Quelle: BMF-Statistik, veröffentlicht Juni 2025). Das sind durchschnittlich rund 25.600 Euro pro Prüfung. Die Umsatzsteuer machte 12,8 Prozent des gesamten Betriebsprüfungs-Mehrergebnisses von 10,9 Milliarden Euro aus.

Die Verwechslung von Gutschrift und Stornorechnung treibt diese Zahlen. Eine Gutschrift im umsatzsteuerrechtlichen Sinn nach §14 UStG ist ein eigenständiges Abrechnungsdokument, das der Leistungsempfänger ausstellt. Eine Stornorechnung korrigiert eine fehlerhafte Rechnung des Leistenden nach §17 UStG. Beide Dokumentarten haben unterschiedliche Rechtsfolgen für den Vorsteuerabzug. Wer sie verwechselt, riskiert, dass das Finanzamt den Vorsteuerabzug versagt - rückwirkend, mit Zinsen.

## Lieferanten verwenden die Begriffe falsch - und das ERP gibt den Fehler weiter

Das Problem beginnt nicht in der eigenen Buchhaltung. Es beginnt beim Lieferanten. In der Praxis schreiben Lieferanten regelmäßig "Gutschrift" auf Dokumente, die steuerrechtlich Stornorechnungen sind. Seit dem Amtshilferichtlinie-Umsetzungsgesetz 2013 hat der Gesetzgeber klargestellt, dass die umgangssprachliche "Gutschrift" keine Gutschrift im Sinne des UStG ist. Aber viele Lieferanten haben ihre Dokumentvorlagen nie angepasst.

Ein konkretes Szenario: Ein Chemieunternehmen erhält monatlich rund 200 Korrekturdokumente von 80 Lieferanten. Etwa 35 Prozent dieser Dokumente tragen die Bezeichnung "Gutschrift", obwohl sie inhaltlich Stornorechnungen sind. Der Sachbearbeiter in der Kreditorenbuchhaltung muss bei jedem einzelnen Dokument die inhaltlichen Merkmale prüfen, die Bezugsrechnung finden und die korrekte steuerliche Behandlung bestimmen. Bei manueller Bearbeitung liegt die Fehlerquote für Rechnungsverarbeitung bei rund 2 Prozent (Quelle: IOFM/Ardent Partners AP Benchmark Report). Bei Korrekturdokumenten, die bereits mit falscher Bezeichnung ankommen, liegt sie erfahrungsgemäß deutlich höher.

## Inhaltliche Klassifikation ersetzt die Dokumentüberschrift

Der [Decision Layer](/de/decision-layer/) löst dieses Problem mit einer klaren Trennung: Die erste Entscheidung - Gutschrift oder Stornorechnung - ist die einzige, die KI-Unterstützung nutzt. Das Sprachmodell analysiert den Dokumentinhalt, nicht die Überschrift. Es prüft, wer das Dokument ausgestellt hat, ob eine Originalrechnung korrigiert wird und welche Rechtsfolgen der Inhalt auslöst.

Diese Klassifikation ist bewusst als Stufe 1 im Decision Layer angelegt: KI-gestützt mit menschlicher Prüfmöglichkeit. Der Wirtschaftsprüfer kann jede einzelne Klassifikationsentscheidung nachvollziehen, weil der Agent dokumentiert, auf Basis welcher Merkmale er das Dokument eingeordnet hat. Die sechs nachfolgenden Schritte - Bezugsrechnung identifizieren, Betrag validieren, USt-Korrektur berechnen, Gegenbuchung erstellen, GoBD-Verknüpfung sicherstellen und steuerliche Behandlung prüfen - laufen vollständig regelbasiert als Stufe 2 ohne KI-Beteiligung.

## Die Belegkette wird zum Prüfungsnachweis

GoBD-Konformität entsteht nicht durch ein Archivierungssystem allein. Sie entsteht durch die lückenlose Verknüpfung jedes Korrekturbelegs mit seiner Originalrechnung. Der Agent stellt diese Verknüpfung bei jeder Verarbeitung her - über Referenznummern-Abgleich und, wenn der Lieferant keine Referenznummer mitliefert, über unscharfes Matching nach Betrag, Datum und Lieferant.

Bei der Betriebsprüfung zeigt sich der Unterschied: Statt einzelne Gutschriften und Stornos manuell ihren Ursprungsbelegen zuzuordnen, liegt eine vollständige Entscheidungsakte vor. Für jedes Dokument ist nachvollziehbar, warum es als Gutschrift oder Storno klassifiziert wurde, welche Originalrechnung betroffen ist, wie die USt-Korrektur berechnet wurde und wie die Gegenbuchung zustande kam. Das reduziert den Prüfungsaufwand - für das eigene Team genauso wie für den Prüfer.

--- AfA-Agent ---
> Bestimmt die AfA-Methode, liest die Nutzungsdauer aus der BMF-Tabelle, berechnet den monatlichen AfA-Betrag und erstellt den Buchungssatz.

Abschreibungen gehören zu den am stärksten reglementierten Vorgängen in der Finanzbuchhaltung. AfA-Methode, Nutzungsdauer, Bemessungsgrundlage, Buchungssatz - jeder Schritt ist durch Gesetz, Tabelle oder Wahlrecht definiert. Trotzdem bindet die Anlagenbuchhaltung in den meisten Unternehmen erhebliche manuelle Kapazität. Der Grund: Sachbearbeiter navigieren zwischen BMF-Tabellen, GWG-Schwellen und Sonderregelungen, ohne dass eine zentrale Logik die Konsistenz sichert. Das ändert sich, wenn ein regelbasierter Agent die gesamte AfA-Kette übernimmt.

## Betriebsprüfer korrigieren AfA-Fehler, die nicht passieren müssten

Die steuerliche Betriebsprüfung der Länder erzielte 2024 ein Mehrergebnis von 10,9 Milliarden Euro - bei nur 140.764 geprüften Betrieben von 8,8 Millionen in der Betriebskartei (BMF-Monatsbericht November 2025). Abschreibungen sind dabei ein Standardprüfungsfeld, weil sich typische Fehler durch den gesamten Anlagespiegel ziehen: falsch zugeordnete Nutzungsdauern, übersehene GWG-Grenzen, nicht angewandte Sonderabschreibungen für digitale Wirtschaftsgüter.

Die Fehlerquellen sind dabei keine Wissenslücken. Sie entstehen, weil ein Sachbearbeiter bei 2.000 oder 5.000 Anlagegütern nicht für jedes einzelne die korrekte BMF-Anlageklasse nachschlägt, die Nutzungsdauer abgleicht und den Schwellenwert für geringwertige Wirtschaftsgüter prüft. Volumen erzeugt Fehler - nicht Komplexität.

## Jeder Entscheidungsschritt folgt einem Regelwerk ohne Interpretationsspielraum

Der [Decision Layer](/de/decision-layer/) zerlegt die AfA-Berechnung in sieben Schritte. Alle sieben sind vollständig regelbasiert (Horizont 1 - keine KI, kein menschliches Ermessen im Einzelfall):

Die AfA-Methode ergibt sich aus dem Anlagenstamm und der steuerlichen Wahlrechtsausübung. Die Nutzungsdauer steht in der BMF-AfA-Tabelle. Die Bemessungsgrundlage berechnet sich nach HGB 255 aus den Anschaffungs- oder Herstellungskosten. Der monatliche AfA-Betrag ist ein Quotient. Die Sonder-AfA-Berechtigung für digitale Wirtschaftsgüter ist ein Schwellenwert-Check. Der Buchungssatz folgt einer festen Kontierungslogik. Die GWG-Prüfung vergleicht den Nettobetrag mit der gesetzlichen Grenze.

Kein einziger dieser Schritte erfordert eine Einschätzung, eine Bewertung oder eine Abwägung. Das macht den AfA-Prozess zum idealen Kandidaten für Automatisierung auf der niedrigsten Decision Layer Stufe.

## Ein Maschinenbauer mit 3.200 Anlagegütern zeigt den Hebel

Ein mittelständischer Maschinenbauer verwaltet einen Anlagenbestand von 3.200 Positionen - Fertigungsanlagen, IT-Hardware, Fuhrpark, Büroeinrichtung. Jeden Monat berechnet die Anlagenbuchhaltung für jedes aktive Wirtschaftsgut den AfA-Betrag und erstellt den Buchungssatz. Bei Neuzugängen kommt die Erstbewertung hinzu: Anlageklasse bestimmen, BMF-Tabelle nachschlagen, GWG-Schwelle prüfen, AfA-Methode festlegen.

Ohne Agent erledigt das ein Sachbearbeiter im ERP-System - Anlage für Anlage, Feld für Feld. Bei einer durchschnittlichen Bearbeitungszeit von drei Minuten pro Neuzugang und 40 Zugängen im Monat sind das allein zwei Stunden für Routinearbeit, die keinen Ermessensspielraum enthält. Die monatlichen AfA-Läufe kommen dazu.

Mit dem AfA-Agent liest das System die Anlageklasse aus dem Stammsatz, schlägt die Nutzungsdauer in der zentral hinterlegten BMF-Tabelle nach, berechnet den monatlichen Betrag, prüft die GWG-Schwelle und erstellt den Buchungssatz. Der gesamte Vorgang läuft in Sekunden, nicht in Minuten - und jede einzelne Berechnung ist mit der angewandten Regel und der Tabellenversion dokumentiert.

## Die BMF-Tabelle wird zur zentral versionierten Infrastruktur

Der eigentliche Wert liegt nicht in der Beschleunigung einzelner Buchungen. Er liegt in der Infrastruktur, die dabei entsteht. Die BMF-AfA-Tabelle existiert in den meisten Unternehmen als PDF oder als manuell gepflegte Stammdatentabelle im ERP-System. Wenn das BMF die Tabelle aktualisiert - zuletzt bei der Neueinschätzung der Nutzungsdauer für Computerhardware und Software - muss jemand die Änderung manuell nachziehen.

Im Decision Layer wird die BMF-Tabelle zum zentral versionierten Regelwerk. Eine Aktualisierung wirkt sofort auf alle neuen AfA-Berechnungen. Die alte Version bleibt für bestehende Anlagen dokumentiert. Und bei der Betriebsprüfung kann für jedes einzelne Wirtschaftsgut nachvollzogen werden, welche Tabellenversion zum Zeitpunkt der Erstbewertung galt.

Diese Infrastruktur nutzt nicht nur der AfA-Agent. Der Anlagenzugangs-Agent, der Inventur-Agent und der Jahresabschluss-Agent greifen auf dieselbe versionierte Tabelle zu. Die GWG-Prüfungslogik wird vom Kontierungs-Agent wiederverwendet. Was als einzelner Abschreibungsprozess beginnt, wird zum Fundament der gesamten Anlagenbuchhaltung.

## Der Prüfungsnachweis entsteht als Nebenprodukt

Für den CFO ist die entscheidende Frage nicht, ob die AfA-Berechnung schneller läuft. Die entscheidende Frage ist, ob sie bei der nächsten Betriebsprüfung standhält. Bei einer Prüfungsquote von 29,6 Prozent für Großunternehmen (BMF 2024) ist das keine theoretische Überlegung.

Ein regelbasierter Agent erzeugt den Prüfungsnachweis als Nebenprodukt jeder Berechnung: angewandte AfA-Methode, BMF-Tabellenversion, Anschaffungskosten, Berechnungsweg, GWG-Prüfung, Sonder-AfA-Prüfung. Der Anlagespiegel für den Jahresabschluss baut sich aus diesen dokumentierten Einzelentscheidungen auf - nicht aus einer nachträglichen Rekonstruktion.

--- Mahnlauf-Agent ---
> Steuert Mahnstufen, berechnet Verzugszinsen nach §288 BGB und dokumentiert die Forderungsabschreibung GoBD-konform für die Außenprüfung.

Mahnwesen in Deutschland ist ein juristisch-finanzieller Pipeline mit fünf gleichzeitigen Rechtsquellen: das BGB (§§271, 286, 288, 195) bestimmt Fälligkeit, Verzug und Verjährung, das HGB (§§352-353) regelt kaufmännische Fälligkeitszinsen für B2B, die ZPO (§§688-703 für Mahnverfahren, §§794-802 für Vollstreckung, §850c für Pfändung) legt das gerichtliche Verfahren fest, die DSGVO (Art. 6(1)(f) und Art. 82) regelt Bonitätsprüfung und Schufa-Meldung, und die AO (§147 mit GoBD 2025) bestimmt Aufbewahrungspflichten und steuerliche Forderungsabschreibung. Jede Stufe der Mahnkette hat Fristen, Vorbedingungen und Formvorschriften - eine fehlende Mahnankündigung vor der Schufa-Eintragung kostet schnell mehrere tausend Euro Schadensersatz nach §823 BGB i.V.m. DSGVO Art. 82, eine versäumte Verjährungsunterbrechung lässt eine berechtigte Forderung nach drei Jahren erlöschen.

## Forderungsabschreibung ohne lückenlose Mahnhistorie - Finanzamt versagt steuerliche Anerkennung in der Außenprüfung

Die Forderungsabschreibung ist gleichzeitig handelsrechtliche Pflicht (§253 Abs. 4 HGB - Niederstwertprinzip bei dauerhafter Wertminderung) und steuerlich begünstigt (Lohnaufwand- bzw. Forderungsverlust mindert das zu versteuernde Einkommen nach EStG/KStG). Damit das Finanzamt die Wertberichtigung anerkennt, verlangt die BFH-Rechtsprechung (BFH I R 32/15, I R 73/16) konkrete Tatsachen für die Werthaltigkeitsprüfung - eine pauschale Pauschalwertberichtigung wird in der Außenprüfung regelmäßig zurückgewiesen, sofern keine Einzelfall-Dokumentation vorliegt.

Genau hier scheitern viele Finanzabteilungen. Der Sachbearbeiter merkt am 30. November, dass eine Rechnung aus dem März noch offen ist, schreibt sie auf 0 ab und bucht den Verlust. In der Außenprüfung verlangt der Prüfer die Mahnhistorie, die Schufa-Auskunft, den Nachweis des Vollstreckungsversuchs - und stellt fest, dass nur eine einzige formlose E-Mail-Erinnerung im April existiert. Folge: Versagung der Wertberichtigung, Hinzuschätzung nach §162 AO mit 75-150% Strafzuschlag und Zinsschaden 6% p.a. nach §238 AO. Bei einem Mittelständler mit 50 Millionen Euro Jahresumsatz und 1,2 Millionen Euro pauschaler Wertberichtigung können sich daraus 350-700 Tausend Euro Mehrsteuer plus Strafe und Zinsen ergeben.

Hinzu kommen DSGVO-Risiken bei fehlerhafter Schufa-Meldung (BfDI-Bußgeld bis 4% Konzernumsatz, Schadensersatz nach §823 BGB i.V.m. Art. 82 DSGVO typisch 2.500-7.500 EUR pro Eintragung) und das Reputationsrisiko bei Kundenklagen wegen unberechtigter Mahnung. Die Prozesskosten allein summieren sich bei mittlerer Verfahrensanzahl schnell auf sechsstellige Beträge.

## Die deutsche Mahnpipeline durchläuft 15 deterministische Schritte

Anders als die brasilianische Mahnpipeline mit 14 Schritten oder der spanische Forderungsprozess mit 10 Schritten erfordert das deutsche Mahnverfahren 15 deterministische Entscheidungen, weil das Zusammenspiel aus BGB (Fälligkeit, Verzug, Verzugszinsen, Verjährung), HGB (kaufmännische Fälligkeitszinsen B2B), ZPO (Mahnbescheid, Vollstreckungsbescheid, Pfändung) und DSGVO (Bonitätsprüfung) mehr Verzweigungen erzeugt: Fälligkeit nach §271 BGB feststellen, Verzug nach §286 BGB prüfen (mit oder ohne Mahnung), B2B/B2C klassifizieren für die Verzugszinsen, Mahnsperre gegen offene Reklamation prüfen, Tagesabgleich CAMT.053 gegen den Bankauszug, Mahnstufe in der Eskalationsmatrix bestimmen, Verzugszinsen nach §288 BGB mit dem aktuellen Basiszins der Bundesbank berechnen, Mahngebühr nach BGH-Rechtsprechung kalkulieren, Schufa-Vorbedingungen prüfen, Mahnbescheid via mahngerichte.de elektronisch beantragen, Vollstreckungsbescheid erwirken, Verjährung nach §195 BGB tracken, Pfändung nach §850c ZPO einleiten und Forderungsabschreibung GoBD-konform dokumentieren. Erst der 15. Schritt - die Eskalation an Inkasso oder Rechtsabteilung - ist eine menschliche Entscheidung mit Kundenbeziehungs-Abwägung.

Ein konkretes Szenario: Industrieunternehmen mit 6.000 offenen Forderungen, 80 Millionen Euro Forderungsbestand, 70% B2B (kaufmännischer Geschäftsverkehr nach HGB §352) und 30% B2C (Privatkunden mit §286 Abs. 3 BGB 30-Tage-Frist). An einem Freitagmorgen identifiziert der Agent 950 überfällige Posten, klassifiziert jeden in der Eskalationsmatrix, wendet die jeweils korrekten Verzugszinsen an (5%-Punkte für die 285 B2C-Forderungen, 9%-Punkte für die 665 B2B-Forderungen, plus 5% Fälligkeitszinsen HGB §352 für die B2B-Forderungen ab Fälligkeit), prüft 60 Mahnsperren wegen offener Reklamationen, gleicht 1.200 Posten gegen den CAMT.053-Bankauszug von Donnerstag ab und identifiziert 130 zwischenzeitliche Zahlungseingänge. Es bleiben 820 Mahnungen zur Versendung, davon 320 erste Stufen, 240 zweite Stufen mit Schufa-Ankündigung und 110 dritte Stufen mit Eintragsmeldung. Parallel reicht der Agent 45 Mahnbescheide ein (titulierte Forderungen über 1.000 Euro mit unbestrittenem Sachverhalt) und initiiert 12 Pfändungsverfahren nach §850c ZPO bei vorhandenem Vollstreckungsbescheid.

Im [Decision Layer](/de/decision-layer/) sind 14 der 15 Schritte regelbasierte Entscheidungen (Stufe R). Der einzige menschliche Eingriff bleibt die Eskalation an Inkasso oder Rechtsabteilung im 15. Schritt - eine strategische Entscheidung mit Kundenbeziehungs-Abwägung, die nicht durch Regeln ersetzbar ist. Ein langjähriger Premium-Kunde mit temporärem Liquiditätsengpass verdient eine andere Behandlung als ein chronischer Spätzahler ohne Geschäftshistorie. Der Agent liefert die Entscheidungsgrundlage: Mahnhistorie, bisheriges Zahlungsverhalten, aktueller Schufa-Score, Forderungshöhe, Verjährungsstand. Die Entscheidung selbst trifft der Sachbearbeiter oder die Abteilungsleitung, dokumentiert mit Begründung und Zeitstempel im Decision Log.

## Tagesabgleich CAMT.053 verhindert die teuerste Mahnung - die berechtigte Mahnung an den zahlenden Kunden

Mahnautomatisierung ohne Tagesabgleich gegen den Bankauszug ist der schnellste Weg zur DSGVO-Beschwerde, zur Kundenkündigung und zum Schadensersatz nach §823 BGB. Der Kunde überweist Donnerstag um 16:42 Uhr per SEPA-Echtzeitüberweisung, der Agent versendet Freitag um 6:00 Uhr die Mahnung mit Schufa-Ankündigung - der Kunde liest die Mahnung am Wochenende, beauftragt am Montag seinen Anwalt, klagt auf Schadensersatz wegen unberechtigter Mahnung und Geschäftsschädigung. Das Amtsgericht spricht typische 1.500-3.000 EUR Schadensersatz nach §249 BGB plus Anwaltskosten zu. Das Landgericht hat in mehreren Fällen sogar Schmerzensgeld nach §253 BGB bei besonderer Kundenkonstellation (Zahlungsmoral langjährig, Belohnungspunkte-System, marktstrategische Position) zugesprochen.

Deshalb ist der 5. Schritt der Mahnpipeline obligatorischer Tagesabgleich VOR jedem Versand. Der Agent ruft den CAMT.053-Bankauszug der Banken via PSD2/EBICS am Versandmorgen ab, integriert SEPA-Echtzeitüberweisungen via PAIN.001-Statusinformationen, gleicht Zahlungseingänge nach IBAN-Empfänger-Konstellation und Verwendungszweck mit der OPOS-Liste ab und schließt automatisch alle Posten mit Vollzahlung. Teilzahlungen werden nach §366-367 BGB anteilig auf Zinsen und Hauptforderung verrechnet, der Restbetrag bleibt im Mahnlauf. Erst nach diesem Schritt wird die Eskalationsmatrix gestartet. Bei großen Konzernen mit 50.000 Forderungen pro Mahnlauf bedeutet das eine Reduktion fehlerhafter Mahnungen um etwa 40-60% - 20.000 bis 30.000 vermiedene Beschwerden pro Jahr.

## Schufa-Meldung, Mahnbescheid und Pfändung verlangen Präzision ohne Ermessen

Sonderfälle wie die Schufa-Meldung (DSGVO Art. 6(1)(f), Code of Conduct, BGH IV ZR 405/13), der gerichtliche Mahnbescheid (ZPO §§688-703 via mahngerichte.de) und die Pfändung des Arbeitseinkommens (§850c ZPO mit BMJ-Tabelle) wirken komplex, sind aber vollständig durch Statuten determiniert. Eine Schufa-Negativmeldung ist nur zulässig nach zweimaliger schriftlicher Mahnung mit jeweils mindestens 4 Wochen Wartefrist und ausdrücklicher Ankündigung des Eintrags - der Agent prüft alle vier Vorbedingungen und blockiert die Meldung automatisch bei Lücke. Der Mahnbescheid wird seit 1.12.2008 ausschließlich elektronisch via mahngerichte.de an das zentrale Mahngericht Wedding eingereicht (für überregionale automatisierte Verfahren). Bei fehlendem Widerspruch nach 2 Wochen folgt der Vollstreckungsbescheid §699 ZPO mit 30 Jahren Verjährung §197 BGB - das hemmt die 3-jährige Regelverjährung dauerhaft.

Die Pfändung des Arbeitseinkommens nach §850c ZPO folgt der BMJ-Pfändungstabelle, die alle 2 Jahre angepasst wird (zuletzt 1.7.2024). Pfändbarer Betrag hängt vom Nettoeinkommen und der Anzahl der Unterhaltspflichten ab. Bei mehreren Pfändungsgläubigern gilt das Zustellungsdatum nach §804 ZPO als Rangmaßstab. Der Agent berechnet den pfändbaren Betrag automatisch und reicht den Pfändungs- und Überweisungsbeschluss elektronisch beim Vollstreckungsgericht ein. Jede Berechnung wird im Decision Log dokumentiert und ist für eine spätere Anhörung im Vollstreckungserinnerungsverfahren §766 ZPO sofort vorlegbar.

## Integration mit DATEV, SAP, Bundesbank und Schufa schließt die Compliance-Kette

Die Logik des Agents verbindet sich mit den führenden deutschen Finanzsystemen via API: [DATEV](https://www.datev.de/) (Eigenorganisation und Mittelstand-Buchhaltung mit OPOS-Mahnstufen, dominanter Marktanteil bei Steuerberatern), SAP S/4HANA FI-AR (Konfiguration der Mahnstufen über Mahnbereiche und Mahnschemen, Beleg-Buchung mit Verzugszinsen über FB70/MIRO), Microsoft Dynamics 365 Business Central (Mittelstand mit ERP-cloudfähiger Mahnverfahren-Engine), Sage 100 und Lexware Buchhaltung (KMU-Forderungslauf), Diamant/4 (Mittelstand-Industrie). Die Verzugszinsenberechnung greift halbjährlich auf den Basiszinssatz der [Deutschen Bundesbank](https://www.bundesbank.de/) zu (Veröffentlichung jeweils 1.1. und 1.7.). Die Bonitätsprüfung und Negativmeldung läuft über die API der Schufa Holding AG (B2C), Creditreform Boniversum (B2B) oder BvD-Bisnode/Dun & Bradstreet (international). Der Mahnbescheid geht elektronisch über das Online-Mahnantrag-Portal mahngerichte.de an das Amtsgericht Wedding. Für Konzerne mit ausländischen Gesellschaften (DAX-Mittelstand, MDAX, Volkswagen, Bosch, Siemens-Töchter) erzeugt der Agent parallele IFRS 9-konforme Reportings für die Konzernkonsolidierung - das deutsche Verfahren bleibt §286 BGB- und GoBD-konform, das Konzern-Reporting erfüllt zugleich die Expected-Credit-Loss-Anforderungen der internationalen Konsolidierung.

--- Bewirtungsbeleg-Agent ---
> Bewirtungs-70-Prozent-Abzug nach EStG §4 Abs. 5 Nr. 2: Pflichtangaben-Prüfung des Bewirtungsbelegs, UStG §15 Vorsteuer und Vier-Augen-Validierung vor Betriebsausgabe.

Bewirtungsbelege scheitern in der Betriebsprüfung nicht an falschen Beträgen. Sie scheitern an fehlenden Pflichtangaben - einem Formfehler, der den kompletten Betriebsausgabenabzug vernichtet. Bei 10,9 Milliarden Euro Mehrergebnis aus Betriebsprüfungen im Jahr 2024 (Quelle: BMF-Monatsbericht November 2025) gehören Bewirtungskosten zu den Positionen, die Prüfer systematisch anfassen. Jeder Beleg ohne vollständige Angaben ist ein Treffer.

## Formfehler vernichten den gesamten Betriebsausgabenabzug

Die Arithmetik ist simpel: 70 Prozent abzugsfähig, 30 Prozent nicht. Daran scheitert niemand. Das Problem liegt in den fünf Pflichtangaben nach §4 Abs. 5 Nr. 2 EStG: Ort, Datum, Teilnehmer, geschäftlicher Anlass und Betrag. Fehlt eine davon, streicht das Finanzamt nicht 30 Prozent - es streicht alles. Ort und Datum stehen auf der Restaurantrechnung. Bei Teilnehmern und Anlass wird es kritisch. In der Praxis fehlt am häufigsten eine vollständige Teilnehmerliste oder der geschäftliche Anlass ist so vage formuliert - "Geschäftsessen" ohne weitere Erläuterung - dass er steuerlich nicht anerkannt wird.

Ein konkretes Szenario: Ein Vertriebsleiter bewirtet vier Kunden nach einer Produktpräsentation. Die Rechnung über 480 Euro ist korrekt, das Restaurant hat alle Angaben auf dem Kassenbeleg. Aber auf dem Bewirtungsbeleg steht unter Anlass nur "Kundentermin" und bei den Teilnehmern fehlt ein Name. Bei einer Betriebsprüfung drei Jahre später sind 480 Euro Betriebsausgabe gestrichen - nicht weil der Betrag unangemessen war, sondern weil zwei Zeilen unvollständig waren.

## Das BMF-Schreiben 2025 verschärft die Anforderungen weiter

Mit dem BMF-Schreiben vom 19. November 2025 hat die Finanzverwaltung die Nachweispflichten für Bewirtungskosten präzisiert. Restaurants mit elektronischem Kassensystem müssen Belege maschinell erstellen und über eine zertifizierte technische Sicherheitseinrichtung (TSE) absichern. Handschriftliche Quittungen oder einfache Ausdrucke ohne TSE-Kennzeichnung werden nicht mehr anerkannt. Für Unternehmen bedeutet das: Selbst ein inhaltlich korrekter Bewirtungsbeleg kann scheitern, wenn die zugrunde liegende Restaurantrechnung nicht den neuen formalen Anforderungen entspricht. Erkennbar ist ein ordnungsgemäßer Beleg an der Transaktionsnummer, der Seriennummer des Kassensystems oder einem aufgedruckten QR-Code.

## Neun Entscheidungsschritte zwischen Beleg und Buchung

Der [Decision Layer](/de/decision-layer/) zerlegt die Bewirtungsbelegprüfung in neun Schritte mit klarer Zuordnung: Wer entscheidet - Regelwerk, KI oder Mensch?

Die Belegklassifikation erkennt per LLM, ob überhaupt ein Bewirtungsbeleg vorliegt. Danach prüft das Regelwerk deterministisch die fünf Pflichtangaben und die Vollständigkeit der Teilnehmerliste. Das sind binäre Fragen - vorhanden oder nicht. Hier gibt es keinen Ermessensspielraum und keinen Grund für menschliche Intervention.

Die Plausibilität des geschäftlichen Anlasses bewertet ein LLM. "Projektbesprechung Digitalisierung Logistik mit Firma X" ist nachvollziehbar. "Essen" ist es nicht. Das Modell erkennt Muster und fordert bei unzureichenden Angaben den Einreicher zur Ergänzung auf - bevor der Beleg in die Buchhaltung gelangt.

Abzugsfähigkeit (70/30-Split), Vorsteuerabzug nach §15 UStG und Kontierung laufen regelbasiert. Die GoBD-konforme Archivierung mit Zeitstempel schließt den Prozess ab. Alle neun Schritte sind dokumentiert und für eine spätere Betriebsprüfung nachvollziehbar.

## Angemessenheit bleibt eine menschliche Entscheidung

Einen Entscheidungsschritt übernimmt bewusst kein Algorithmus: die Angemessenheitsprüfung. Ob 120 Euro pro Person bei einem Geschäftsessen mit drei Kunden angemessen sind, hängt von Branche, Kontext und Geschäftsbeziehung ab. Ein Abendessen im Rahmen einer Vertragsverhandlung folgt anderen Maßstäben als ein Mittagessen nach einem Erstgespräch. Der Agent liefert dem Entscheider die Fakten - Betrag pro Person, Vergleich mit historischen Werten, Verhältnis zum Geschäftsvolumen. Die Freigabe oder Eskalation trifft der Mensch.

Diese Grenzziehung ist kein technisches Defizit. Sie ist Governance. Ein Bewirtungsbeleg-Agent, der eigenständig über Angemessenheit urteilt, würde Ermessensentscheidungen automatisieren, die im Zweifel ein Betriebsprüfer hinterfragt. Die Verantwortung bleibt dort, wo sie hingehört.

--- ESG-Reporting-Agent ---
> Erstellt den Nachhaltigkeitsbericht nach CSRD und ESRS, prüfungsfest nach IDW PS 991, und liefert das XBRL-Tagging für die DPR-Bilanzkontrolle.

Das ESG-Reporting steht in Deutschland zwischen fünf parallelen Compliance-Themen mit sehr unterschiedlichen Konsequenzen. Die CSRD-Pflicht nach HGB §289b-289e verlangt über 1.100 ESRS-Datenpunkte (E1-E5, S1-S4, G1) mit Limited-Assurance-Prüfung durch den Wirtschaftsprüfer. Das Lieferkettensorgfaltspflichtengesetz verpflichtet Unternehmen ab 1.000 Mitarbeitern zum jährlichen BAFA-Bericht (§10) mit Bußgeld-Risiko bis 8 Mio EUR oder 2 Prozent Konzernumsatz. Die DPR prüft kapitalmarktorientierte Unternehmen stichprobenartig nach WpHG §114-117, 2024 und 2026 mit Schwerpunkt auf Klimaberichterstattung, EU-Taxonomie und Wesentlichkeitsanalyse, mit Mängelbericht-Veröffentlichungspflicht. IDW PS 991 (2024) regelt die Prüfer-Methodik mit einem Prüfungsmehraufwand von 30 bis 150 Prozent gegenüber der Jahresabschlussprüfung (Big-4-Stundensätze 280 bis 580 EUR). Und die EU-Taxonomie-Verordnung verlangt nach der delegierten VO 2021/2178 die getrennte Disclosure der taxonomy-eligible und taxonomy-aligned Anteile an Umsatz, CapEx und OpEx. Damit kann jeder ESG-Bericht im deutschen Konzern oder gehobenen Mittelstand bis zu fünf Pflichten gleichzeitig auslösen.

## EFRAG ESRS Set 1: über 1.100 Datenpunkte, Welle 1 ab 2024 mit 11.700 Unternehmen EU-weit und durchschnittlich 375 Stunden Datenerhebung je Zyklus

Die European Financial Reporting Advisory Group (EFRAG) hat das ESRS Set 1 mit zwölf Standards und über 1.100 Datenpunkten in der delegierten VO (EU) 2023/2772 verabschiedet: ESRS 1 und 2 als allgemeine Standards mit Wesentlichkeitsanalyse-Methodik, dazu zehn thematische Standards zu Klimawandel (E1), Umweltverschmutzung (E2), Wasser (E3), Biodiversität (E4), Kreislaufwirtschaft (E5), eigener Belegschaft (S1), Wertschöpfungsketten (S2), betroffenen Gemeinschaften (S3), Verbrauchern (S4) und Unternehmensführung (G1). Welle 1 (Geschäftsjahr 2024, Bericht 2025) gilt für etwa 11.700 Unternehmen EU-weit, davon rund 540 in Deutschland aus dem bisherigen NFRD-Kreis. Welle 2 (2025/2026) erweitert auf alle grossen Unternehmen mit zwei von drei Schwellenwerten (über 250 Mitarbeiter, über 50 Mio EUR Umsatz oder über 25 Mio EUR Bilanzsumme) - in Deutschland rund 13.000 weitere, überwiegend gehobener Mittelstand.

Der Deloitte CSRD Readiness Survey 2024 zeigt: Über 70 Prozent der Unternehmen nennen Datenerhebung und Datenqualität als größte Hürde, im Schnitt 375 Stunden Datenerhebung je Zyklus bei Erstanwendung, und 73 Prozent der deutschen Mittelständler tun sich schwer, die benötigten ESG-Daten zu identifizieren. Die PwC ESG-Studie 2024 ergänzt für einen kapitalmarktorientierten Konzern der Welle 1 einen Erstanwendungs-Aufwand von typisch 300 bis 500 Personentagen Datenerhebung, 80 bis 150 Personentagen Prüfer-Vorbereitung und 1,5 bis 3,5 Mio EUR Beratungs- und IT-Kosten. Parallel liegen die DPR-Prüfungsschwerpunkte 2024 auf Klimaberichterstattung (E1), EU-Taxonomie-Disclosures und Wesentlichkeitsanalyse, mit überproportionaler Befundquote von 42 Prozent bei der Taxonomie-Klassifikation, vor allem bei CapEx-Plänen. Hinzu kommen die LkSG-Risiken: Der BAFA-Jahresbericht 2024 zeigt eine zunehmende Prüfungsdichte mit Bußgeldverfahren gegen Unternehmen, die ihre Berichtspflicht nach §10 nicht erfüllen.

## Die 16 deterministischen Entscheidungspunkte mit vier menschlichen Eskalationen

Der Agent zerlegt das ESG-Reporting in 16 strukturierte Entscheidungspunkte: zwölf regelbasierte Klassifikationen, zwei ML-basierte Analytik-Schritte (Scope-3-Schätzung und ESRS-Narrativ-Generierung) und vier menschliche Eskalationen für die Wesentlichkeitsanalyse (doppelte Materialität), die EU-Taxonomie-Auslegung, die Prüfer-Readiness sowie den Aufsichtsrats-Bericht nach §107 AktG und die Vorstands-Attestierung. Die regelbasierten Schritte umfassen die Schwellenwert-Prüfung nach HGB §289b-289e, die ESRS-Datenpunkt-Identifikation gegen den EFRAG-Katalog, das Mapping der LkSG-Berichtspflicht (§10) auf S2 und G1, die Scope-1- und Scope-2-Berechnung nach GHG-Protocol, die Datenaggregation aus den Quellsystemen, die Konsistenz-Prüfung gegen den Lagebericht, das EFRAG-XBRL-iXBRL-Tagging und die DPR-Risikobewertung. Die ML-Komponenten (Scope-3-Schätzung mit EXIOBASE- und ecoinvent-Faktoren, ESRS-Narrativ als LLM-Vorschlag) liefern ausschließlich Indikatoren mit Confidence-Scores und dokumentierten Annahmen, niemals Endentscheidungen - DSGVO-Art.-22-konform ohne automatisierte Einzelfallentscheidung mit Rechtswirkung.

Ein konkretes Beispiel: Ein Industrieunternehmen mit 2.000 Mitarbeitern und 850 Mio EUR Umsatz in Welle 2 (Geschäftsjahr 2025, Bericht 2026). Der Agent bestätigt die Berichtspflicht (zwei der drei Schwellenwerte deutlich überschritten, kein Kapitalmarktstatus, Welle 2). Die Wesentlichkeitsanalyse identifiziert E1 (Klimawandel), E5 (Kreislaufwirtschaft), S1 (Eigene Belegschaft) und S2 (Wertschöpfungsketten) als wesentlich (doppelte Materialität, outside-in und inside-out), woraus der Agent 412 berichtspflichtige ESRS-Datenpunkte ableitet. Die LkSG-Integration mit Risiko-Analyse für 27 Lieferanten in Hochrisiko-Ländern, Beschwerdeverfahren und Wirksamkeitsprüfung fließt in die S2-Datenpunkte ein. Bei der EU-Taxonomie prüft er 8 NACE-Codes der Tochtergesellschaften auf substanziellen Beitrag und Do-No-Significant-Harm. Scope 1 ergibt 47.500 t CO2-Äquivalent aus Kesseln, Fuhrpark und Prozessen (BEIS-, UBA-, IPCC-AR6-Faktoren), Scope 2 ergibt 28.300 t market-based und 33.100 t location-based mit Herkunftsnachweisen, Scope 3 per ML-Schätzung 152.000 t (Cat-1 Purchased Goods) und 89.000 t (Cat-11 Use of Sold Products) Spend-based mit EXIOBASE-Faktoren und Confidence-Score 0,78. Der getaggte Bericht ist drei Wochen nach Datenfreigabe prüfungsbereit; das ESG-Team prüft die Wesentlichkeitsanalyse und die EU-Taxonomie-Auslegung und bereitet die Limited-Assurance-Prüfung nach IDW PS 991 vor. Der Prüfungsausschuss eskaliert nach §107 AktG mit DCGK-2024-Nachhaltigkeitsausschuss; die Vorstands-Freigabe folgt nach §93 AktG mit Compliance-Statement.

## Wesentlichkeitsanalyse und EU-Taxonomie-Auslegung bleiben Führungsaufgaben

Der Agent kann Datenpunkte sammeln, Emissionen berechnen, das XBRL-Tagging erzeugen und die Konsistenz prüfen. Was er nicht kann: entscheiden, welche ESG-Themen für ein Unternehmen wesentlich sind oder ob eine Investition als taxonomy-aligned gilt. Die doppelte Materialität nach ESRS 1 und 2 verlangt zwei Perspektiven mit Stakeholder-Dialog, Branchenkontext und strategischem Urteil - keine Rechenaufgabe, sondern eine Einordnung. Bei kapitalmarktorientierten Unternehmen wird die Wesentlichkeitsanalyse Prüfungsschwerpunkt der DPR-Bilanzkontrolle und des IDW-PS-991-Substantive-Testing.

Die EU-Taxonomie-Zuordnung ist die zweite kritische Interpretation: Das NACE-Code-Mapping läuft regelbasiert, doch die Substanzieller-Beitrag-Prüfung mit technischen Kriterien (etwa der Schwellenwert g CO2/kWh für Stromerzeugung oder die Energieeffizienz-Klasse für Gebäude), die Do-No-Significant-Harm-Prüfung gegen die anderen fünf Umweltziele und die Mindestschutz-Vorbehalte gegen die UN-Leitprinzipien, OECD-Leitsätze und IAO-Kernarbeitsnormen erfordern ein menschliches Urteil. Laut DPR-Statistik 2024 hatten 42 Prozent der geprüften Unternehmen Befunde zur Taxonomie-Klassifikation - ein klassischer Prüfer-Hinterfragungspunkt nach IDW PH 9.860.1.

## Edge-Cases: Konzern-Konsolidierung, Mehrfach-Berichtspflicht IFRS S1/S2, Phase-In-Erleichterungen, ISSB-Aequivalenz und CSDDD-Erweiterung

Die Konzern-Konsolidierung ist der häufigste Edge-Case: Tochtergesellschaften in Drittstaaten mit unterschiedlichen Berichtsstandards werden zu einem konsolidierten CSRD-Bericht zusammengeführt. Der Agent verbindet die IFRS-S1/S2-Disclosures (ISSB) von US-Töchtern, die GRI-Reports asiatischer Töchter und die EU-CSRD-Pflichten in einer einheitlichen Konsolidierung mit Datenherkunfts-Audit-Trail nach DRS 27 und DRS 20. Eine Mehrfach-Berichtspflicht entsteht bei US-Töchtern mit SEC-Klimaberichts-Pflicht, einer EU-Mutter mit CSRD-Pflicht und IFRS S1/S2 für kapitalmarktorientierte EU-Töchter; der Agent erzeugt dafür die Äquivalenz-Mapping-Tabelle für die EFRAG-Äquivalenz-Prüfung der EU-Kommission, die 2026 und 2027 voraussichtlich erste Äquivalenz-Erklärungen für ISSB- und SEC-Klimaberichte ausstellt.

Die Phase-In-Erleichterungen sind die vierte Kategorie: Welle-2-Unternehmen müssen im ersten Berichtsjahr 2025 nur ESRS 1, 2, E1 und G1 verpflichtend berichten, alle weiteren Standards über ein bis drei Jahre. Der Agent prüft die Anwendbarkeit und dokumentiert die schrittweise Erweiterung. Die EU-CSDDD verschärft ab 2027 die Sorgfaltspflichten über das LkSG hinaus mit zivilrechtlicher Haftung für Unternehmen ab 1.000 Mitarbeitern und 450 Mio EUR Umsatz; der Agent bereitet diese Erweiterung mit Risiko-basiertem Ansatz, Klimaplan-Pflicht und Vorstandsvergütungs-Bezug vor. Die ISSB-Äquivalenz schließlich ist ein strategischer Edge-Case für Konzerne mit US-Listing: Ab 2027 und 2028 erwartet die EU-Kommission eine Äquivalenz-Erklärung für IFRS S1/S2 - der Agent erzeugt dafür duale Disclosures und ein Äquivalenz-Mapping.

## Integration mit SAP S/4HANA Green Ledger, DATEV Sustainability, Lucanet ESG, Workiva und der deutschen Prüfungsarchitektur

Der Agent bindet die führenden deutschen und internationalen ESG-Reporting- und Sustainability-Management-Systeme per API an: SAP S/4HANA Green Ledger mit Sustainability Control Tower und Footprint Management als Konzern-Standard, DATEV Sustainability mit ESG Data Hub für das Mittelstands-CSRD-Reporting, Lucanet ESG für die Konzern-Konsolidierung mit ESRS-Datenpunkt-Mapping und Workiva Wdesk ESG mit XBRL-Tagging für kapitalmarktorientierte Konzerne. Ergänzend integrieren sich Microsoft Sustainability Manager, Salesforce Net Zero Cloud, Sphera (auch für Lieferketten/LkSG), IBM Envizi und OpenPages ESG, AMCS für Industrie-Emissionen, Sweep, Plan A und ClimatePartner für den Mittelstands-Einstieg sowie Cority, Diligent und ServiceNow ESG Management. Die BAFA-Schnittstelle erzeugt den jährlichen LkSG-Bericht (§10) mit Risiko-Analyse, Präventionsmaßnahmen, Beschwerdeverfahren und Wirksamkeitsprüfung. Die EU-Taxonomie-Disclosures entstehen nach VO 2021/2178 mit getrennter Auflistung der taxonomy-eligible und taxonomy-aligned Anteile an Umsatz, CapEx und OpEx. Für die Limited-Assurance-Prüfung nach IDW PS 991 exportiert der Agent an Deloitte ASM, PwC Aura, EY Helix und KPMG Clara mit ESRS-Datenpunkt-Klassifikation, Datenherkunfts-Audit-Trail und Prüfungsschwerpunkte-Mapping; das EFRAG-XBRL-iXBRL-Tagging läuft gegen die ESRS XBRL Taxonomy 2024 und die EU-ESEF-VO 2019/815 mit Block- und Detail-Tagging und Validierung. Bei kapitalmarktorientierten Unternehmen kommen die DPR-Prüfungsvorbereitung (Schwerpunkte 2024 und 2026: Klimaberichterstattung, EU-Taxonomie, Wesentlichkeitsanalyse), der BaFin-Anzeige-Workflow nach WpHG §114-117 und die Aggregation für den Prüfungsausschuss nach §107 AktG hinzu. Bei Mitarbeiterdaten (S1) sichern die DPIA-Dokumentation nach DSGVO Art. 35 und die BetrVG-Betriebsvereinbarung mit Pseudonymisierung als Standardmodus die Konformität. Die Aufsichtsrats-Eskalation folgt §171 AktG, die Vorstands-Attestierung §93 AktG mit Compliance-Statement und D&O-Bezug bei Falschangaben.

--- Financial-Forecast-Agent ---
> Erzeugt monatlichen P&L-, Bilanz- und Cashflow-Rolling-Forecast nach IAS 1, vergleicht Budget vs Actual nach DRS 20 und liefert AktG §90 Vorstandsbericht plus HGB §289 Prognosebericht für DPR.

Finanzplanung in Deutschland steht zwischen fünf parallelen Compliance-Anforderungen mit jeweils unterschiedlichen Konsequenzen für Vorstand, Aufsichtsrat und Wirtschaftsprüfer. AktG §90 verpflichtet den Vorstand, dem Aufsichtsrat regelmäßig über Geschäftspolitik, Rentabilität, Lage und voraussichtliche Entwicklung zu berichten - mit erheblichen Haftungsrisiken nach §93 AktG bei Falschangaben. Die Deutsche Prüfstelle für Rechnungslegung (DPR) prüft kapitalmarktorientierte Unternehmen stichprobenweise nach WpHG §114-117, mit Schwerpunkten 2024-2026 auf Schätzunsicherheiten, Goodwill-Werthaltigkeit und Klimarisiken im Cashflow. DRS 20 verlangt eine quantifizierte Prognose-Disclosure mit Wesentlichkeit (DRS 20.116 ff.) und Vergleich zum Vorjahres-Ausblick. Die IDW-Prüfungsstandards PS 951, PS 525 und PS 350 regeln die Methodik der Wirtschaftsprüfer, und IAS 36, IAS 8 und IAS 1 die internationale Rechnungslegung mit jährlicher Werthaltigkeitsprüfung und DCF-basierter Value-in-Use-Berechnung. Damit kann eine einzige Forecast-Modellierung in einem deutschen Konzern oder gehobenen Mittelständler bis zu fünf Compliance-Pflichten gleichzeitig auslösen.

## 5,2 Mio Euro Verlust pro Konzern, wenn die Prognose ad-hoc korrigiert werden muss

Der PwC Forecast Benchmark 2024 zeigt: DAX-/MDAX-Konzerne mit ad-hoc-pflichtigen Prognose-Anpassungen verlieren im Schnitt 5,2 Mio Euro pro Anpassung - vor allem durch Kursreaktionen von typisch -3 bis -8 Prozent am Veröffentlichungstag, dazu Reputationsschaden und höhere Kapitalkosten. Im gehobenen Mittelstand kommt der KPMG CFO-Survey 2024 auf rund 1,8 Mio Euro pro Geschäftsjahr durch schlechtere Bankkonditionen, verpasste M&A-Gelegenheiten und interne Reibungsverluste. Wer den Forecast manuell in getrennten Excel-Modellen ohne 3-Statement-Konsistenz pflegt, erreicht laut Hackett Group 2024 nur 64 Prozent Genauigkeit bei 18 bis 25 Personentagen je Zyklus - ein monatlicher Rolling-Forecast bindet so drei bis vier Vollzeitkräfte allein für die Mechanik.

Auch die Prüfung ist ein Risiko: Bei kapitalmarktorientierten Unternehmen sind Schätzunsicherheiten, IAS-36-Annahmen und Klimarisiken im Cashflow wiederkehrende DPR-Schwerpunkte. Ein Mängelbericht wird veröffentlicht, löst Kursreaktionen von -3 bis -8 Prozent aus und kann BaFin-Bußgelder bis 10 Mio Euro oder 5 Prozent des Jahresumsatzes nach WpHG §120 nach sich ziehen. Das FISG verschärfte 2021 als Wirecard-Folge die Prüfer-Rotation, die externe Beauftragung der Prüfer durch den Aufsichtsrat, den Prüfungsausschuss-Bericht nach §107 AktG und die Honorar-Disclosure. Hinzu kommen die Vorstands-Haftungsrisiken nach AktG §93 (persönliche Haftung), §91 Abs. 2 (Risikofrüherkennung) und §90 (Berichtspflicht), abgesichert nur teilweise durch eine D&O-Versicherung mit 10 Prozent Selbstbehalt.

## Die 16 deterministischen Entscheidungspunkte mit drei menschlichen Eskalationen

Der Agent verarbeitet den Rolling-Forecast in 16 strukturierten Entscheidungspunkten: 13 regelbasierte Klassifikationen und drei menschliche Eskalationen für die Treiber-Identifikation, die Best-/Base-/Worst-Case-Szenarien und den Aufsichtsrats-Bericht nach §90 AktG. Die ML-Komponenten (Umsatz-Forecast mit ARIMA und Prophet) liefern dabei nur Indikatoren mit Konfidenzintervallen, nie Endentscheidungen, und bleiben so konform zu Art. 22 DSGVO. Die regelbasierten Schritte umfassen die ERP-Datenintegration, die Aggregation der Ist-Daten über 36 bis 60 Monate, die Forecasts für Personal-, Material- und Betriebskosten, die P&L-Bridge bis zum Net Income, den Bilanz- und den indirekten Cashflow-Forecast, den 3-Statement-Konsistenz-Check, die Budget-vs-Actual-Analyse, die Sensitivitätsanalyse, den IAS-36-Impairment-Test und die Going-Concern-Bewertung.

Ein konkretes Beispiel: ein gehobener Mittelständler mit 2.400 Mitarbeitern, 480 Mio Euro Umsatz und drei Geschäftsbereichen (Industrieprodukte, Services, Software). Die ERP-Integration synchronisiert das SAP-S/4HANA-Hauptbuch, die DATEV-Konsolidierung und das Lucanet-Reporting mit Konten-Mapping nach SKR 04, IFRS-Tagging und drei Buchungskreis-Konsolidierungen nach HGB §300; 48 Monate Ist-Daten werden mit GoBD-konformem Audit-Trail aggregiert. In einem Workshop legen CFO, FP&A-Lead und die drei Bereichsleiter neun Pflicht-Treiber fest (Verkaufsmenge B2B/B2C/Services, Durchschnittspreis, Materialkostenquote, Personalkosten pro Kopf, F&E- und Vertriebskostenquote, DSO/DPO/DIO, CapEx-Quote und Steuersatz). Das ARIMA-Prophet-Modell prognostiziert den Umsatz je Bereich, Region und Produkt-Cluster mit Konfidenzintervallen von 80 und 95 Prozent, validiert gegen Auftragsbuch und Pipeline. Die Personalkosten ergeben aus einem Headcount-Plan von 2.400 auf 2.520, 4 Prozent IGZ-Tariferhöhung und dem IAS-19-Pensions-Forecast 168,4 Mio Euro; die Materialkosten aus 3,2 Prozent Rohstoff-Inflation, EUR/USD-Effekten und LkSG-Risiko 187,6 Mio Euro; die Betriebskosten 64,8 Mio Euro. Daraus aggregiert die P&L 504 Mio Euro Umsatz, 73,2 Mio Euro EBITDA (14,5 Prozent), 52,8 Mio Euro EBIT und 33,6 Mio Euro Net Income. Der Bilanz-Forecast weist 8,4 Mio Euro zusätzliches Working Capital, 32 Mio Euro CapEx und 142 Mio Euro Net Debt aus; der indirekte Cashflow 68,4 Mio Euro operativ, -32 Mio Euro Investing und -18,2 Mio Euro Financing. Der Konsistenz-Check bestätigt: Net Income 33,6 = Eigenkapital-Veränderung 33,6 = Cashflow-Startwert 33,6. Budget vs. Actual zeigt 4,3 Prozent EBIT-Abweichung, innerhalb der Wesentlichkeitsschwelle von 10 Prozent. Im Szenario liegt das EBIT zwischen 38 Mio Euro (Worst, Wahrscheinlichkeit 18 Prozent), 52,8 Mio Euro (Base) und 62 Mio Euro (Best). Der IAS-36-Trigger-Check zeigt kein Goodwill-Risiko, Going Concern ist unkritisch, und der §90-Bericht wird für die Q3-Aufsichtsratssitzung prüfungsbereit aggregiert.

## Treiber-Identifikation und Szenario-Modellierung bleiben Vorstandsaufgaben

Der Agent kann ERP-Daten integrieren, historische Trends extrapolieren, ML-basierte Umsatz-Forecasts erzeugen und 3-Statement-Modelle aggregieren. Was er nicht kann: entscheiden, welche operativen Treiber das Geschäftsmodell fundamental bestimmen oder welche Annahmen für ein Best-/Base-/Worst-Case-Szenario realistisch sind. Die Treiber-Identifikation verlangt Branchen- und Geschäftsmodell-Wissen, denn Industrie-, Software- und Bankgeschäfte unterscheiden sich grundlegend, ebenso ein Produkt- von einem Subscription-Geschäft. Die Szenario-Annahmen verlangen ein Urteil zu Konjunktur, Wettbewerb, Regulatorik und geopolitischen Risiken - keine Rechenaufgabe, sondern eine strategische Einordnung durch CFO, Vorstand und den Prüfungsausschuss nach §107.

Die Aufsichtsrats-Eskalation nach §90 AktG ist die dritte kritische menschliche Entscheidung: Überschreitet der Forecast die Wesentlichkeitsschwellen nach DCGK D.4 und DRS 20.116 ff., muss der Vorstand Aufsichtsrat und Prüfungsausschuss mit Begründung, Sensitivitätsanalyse und Audit-Trail informieren; bei kapitalmarktorientierten Unternehmen kommt die Ad-hoc-Publizität nach MAR Art. 17 hinzu. Weil die D&O-Versicherung nur mit 10 Prozent Selbstbehalt greift und bei vorsätzlichen Pflichtverletzungen ausfallen kann, ist die nachweisbare Eskalations-Dokumentation die zentrale Haftungsabwehr-Evidenz nach der Business Judgement Rule (§93 Abs. 1 Satz 2 AktG).

## Edge-Cases: Konzern-Konsolidierung DRS 20, IAS 36 Impairment-Forecast, CSRD-ESRS-Sustainability-Forecast und Mehrfach-GAAP-Reporting

Konzern-Konsolidierung nach DRS 20 ist der häufigste Edge-Case: Tochtergesellschaften mit unterschiedlichen ERPs und lokalen Rechnungslegungsstandards (DATEV-HGB-Mittelständler, SAP-IFRS-Konzerntochter, ausländische Local-GAAP-Tochter) müssen zu einem konsolidierten Konzernlagebericht-Forecast aggregiert werden - mit Eliminierung der Intercompany-Cashflows nach HGB §300, anteilsbedingter Aufteilung und Multi-GAAP-Reconciliation. Der Agent führt DRS 20, IAS 1, IAS 8 sowie IFRS 3 (Goodwill, Earn-Out-Klauseln) in einer einheitlichen Forecast-Logik mit Audit-Trail zusammen. Der IAS-36-Impairment-Forecast ist der zweite Edge-Case: Bei Goodwill-Buchwerten über 50 Mio Euro und immateriellen Vermögenswerten mit unbestimmter Nutzungsdauer ist jährlich und bei Trigger-Ereignissen ein Werthaltigkeitstest mit DCF-Modell, Value-in-Use und CGU-Allokation fällig. Der Agent erzeugt die DCF-Prognose mit fünfjähriger Detailphase, Terminal Value und Sensitivitätsanalyse für Diskontierungs- und Wachstumsrate, prüfungssicher dokumentiert.

Der CSRD-ESRS-Sustainability-Forecast ist der dritte, zukunftskritische Edge-Case: Die EU-CSRD 2022/2464 und die ESRS verpflichten kapitalmarktorientierte Unternehmen gestaffelt ab Geschäftsjahr 2024, 2025 und 2026 zur quantifizierten Nachhaltigkeitsberichterstattung mit Klimarisiken-Cashflow-Forecast, Scope-1/2/3-Emissionsprognose und EU-Taxonomie-Konformität (grüne Umsatz-, CapEx- und OpEx-Quote nach sechs Umweltzielen). Der Agent integriert diese Komponenten mit doppelter Wesentlichkeit (Inside-Out und Outside-In) in das 3-Statement-Modell. Mehrfach-GAAP-Reporting ist der vierte Edge-Case bei US-Listing oder Schweizer Tochter: parallele Pflichten nach HGB, IFRS, US-GAAP (ASC 230/350/606) und Swiss GAAP FER. Der StaRUG-Sanierungs-Forecast ist der fünfte, krisenbezogene Edge-Case: Bei Going-Concern-Risiken aktiviert der Agent die IDW-S-11-Sanierungsbegutachtung, die StaRUG-Eigenverwaltungs-Vorbereitung und den Drei-Wochen-Countdown nach InsO §15a.

## Integration mit SAP S/4HANA Finance, Lucanet, Anaplan, Workday Adaptive Planning, Jedox, IBM Planning Analytics und der deutschen Kapitalmarkt-Architektur

Der Agent bindet die führenden FP&A-Plattformen über deren APIs an: SAP S/4HANA Finance mit SAP Analytics Cloud Planning und Group Reporting als Konzern-Standard, Lucanet als DRS-20-Spezialist für den deutschen Mittelstand (rund 4.500 Kunden), Anaplan mit Hyperblock-Engine für komplexe Konzernstrukturen, Workday Adaptive Planning, Jedox als Excel-naher Mittelstands-Marktführer (rund 2.500 Kunden) und IBM Planning Analytics (TM1). Hinzu kommen Oracle EPM, CCH Tagetik (mit CSRD-ESRS-Sustainability-Forecast), OneStream, BOARD, Vena und Prophix für den Mittelstand sowie DATEV Unternehmen Online (rund 40.000 Kunden) und Microsoft Dynamics 365 mit Power BI. Die ERP-Hauptbuch-Anbindung läuft über SAP OData, den DATEV-Belegtransfer und das Lucanet-Konten-Mapping. Die Treasury-Konsistenz sichert die Integration mit dem Cash-Forecasting-Agent sowie Systemen wie Kyriba oder SAP TRM für FX-Hedging und Forward-Curves.

Bei kapitalmarktorientierten Unternehmen kommen Bloomberg, Reuters Eikon und IBES-Konsensus für die Investor Relations hinzu, dazu ESEF-XBRL-Tagging für den Konzernabschluss. Das IDW-PS-951-Substantive-Testing wird über den Datenexport an die Audit-Plattformen der Big Four (Deloitte ASM, PwC Aura, EY Helix, KPMG Clara) unterstützt, jeweils mit Klassifikation nach IAS 1/8/36 und DRS 20 und vollständigem Audit-Trail. Der Agent bereitet außerdem die DPR-Prüfung mit den Schwerpunkten 2024-2026, die BaFin-Bilanzaufsicht und die Aufsichtsrats-Eskalation nach §90/§107/§171 AktG vor. Die DSGVO-Konformität nach Art. 22 sichert die Decider-Trennung (R/A/H), bei Mitarbeiterdaten ergänzt um Art. 35 DPIA und die BetrVG-Mitbestimmung.

--- Fraud-Detection-Agent ---
> Erkennt Duplikat-Rechnungen, Phantom-Vendors, Round-Tripping und SoD-Verstöße gegen StGB §263/§266/§299, mappt IDW PS 210 Aufdeckungspflicht und liefert GwG- plus KWG §25h-Audit-Trail für Strafanzeigen.

Betrugserkennung in Deutschland steht zwischen fünf parallelen Compliance-Themen mit ganz unterschiedlichen Konsequenzen. StGB §263 Betrug, §266 Untreue und §299 Wettbewerbsabsprachen sind Straftatbestände mit Freiheitsstrafen bis 10 Jahre und persönlicher Haftung der Geschäftsführung. IDW PS 210 verpflichtet den Konzern-Wirtschaftsprüfer zur Aufdeckung von Unregelmäßigkeiten im Rahmen der Jahresabschlussprüfung nach HGB §317 und zum Bericht an den Prüfungsausschuss. Das GwG (Novelle 2024) verlangt unverzügliche Verdachtsmeldungen an die FIU Zoll, mit Bußgeld bis 5 Mio Euro bei Versäumnis. Das Bundeskartellamt verhängt bei wettbewerbsbeschränkenden Absprachen Bußgelder bis 10 Prozent des Konzernumsatzes (2024 bis 800 Mio Euro bei DAX-Konzernen). Und Art. 35 DSGVO fordert bei Fraud-Detection mit ML-Komponenten eine DPIA, bei hohem Restrisiko mit Konsultation des BfDI. Damit kann ein einziger Betrugsverdacht in einem deutschen Konzern oder Mittelständler bis zu fünf Compliance-Pflichten gleichzeitig auslösen.

## ACFE Report to the Nations 2024 - 5 Prozent Jahresumsatz Betrugsschaden, mediane Aufdeckungszeit 12 Monate, 43 Prozent durch Hinweise statt Kontrollen

Die Association of Certified Fraud Examiners (ACFE) dokumentiert in ihrem Report to the Nations 2024 auf Basis von 1.921 untersuchten Fällen mit 3,1 Mrd USD Gesamtschaden weltweit: Organisationen verlieren typisch 5 Prozent ihres Jahresumsatzes durch Betrug, der mediane Schaden pro Fall liegt bei 145.000 USD, die mediane Aufdeckungszeit betraegt 12 Monate. Besonders kritisch: 43 Prozent der Fälle wurden durch Hinweise (Whistleblower, Kunden, anonyme Tippgeber) entdeckt, nur 16 Prozent durch interne Kontrollen, weitere 12 Prozent durch zufällige Entdeckung. Stichprobenbasierte Prüfungen finden klassische Fraud-Muster wie Phantom-Vendor-Konstrukte, Schwellenwert-Splitting und Round-Tripping nicht systematisch.

Parallel dokumentiert die Bundeskartellamt-Statistik 2024 über 35 Verfahren mit Bußgeldern bis 800 Mio Euro bei DAX-Konzernen, dazu persönliche Vorstandshaftung und EU-Schadensersatzklagen geschädigter Marktteilnehmer. BaFin-Prüfungen 2024 zeigen 67 Prozent der inspizierten Banken mit Mängeln im BAIT-Berechtigungsmanagement und 34 Prozent mit Funktionstrennungs-Verstößen nach MaRisk AT 4.3 - klassische SoD-Probleme, die jedes Fraud-Detection-System zuerst adressieren muss. Hinzu kommen die Risiken nach OWiG §30 und §130: Bei nachgewiesenem Fraud-Versagen und dadurch ermöglichten Pflichtverstößen drohen Verbandsgeldbußen bis 10 Mio Euro und die Vorteilsabschöpfung. AI-generierte Fake-Rechnungen verschieben die Bedrohungslage seit 2024 grundlegend - Anti-Fraud-Fachleute berichten branchenübergreifend von einer deutlichen Zunahme GenAI-generierter Fälschungen, die visuelle Prüfung und regelbasierte Validierung systematisch umgehen.

## Die 15 deterministischen Entscheidungspunkte mit drei menschlichen Eskalationen

Der Agent verarbeitet jeden Verdachtsfall in 15 strukturierten Entscheidungspunkten: zwölf regelbasierte Klassifikationen, drei ML-basierte Anomalie-Detektoren (Buchungsmuster, Document-Authenticity, Round-Tripping-Netzwerkanalyse) und drei menschliche Eskalationen für den Prüfungsausschuss-Bericht nach §107 AktG, die Strafanzeige-Vorbereitung nach StPO §158 und die False-Positive-Bewertung mit ML-Retraining. Die regelbasierten Schritte umfassen das StGB-Tatbestandsmapping, die IDW-PS-210-Kategorisierung, den GwG-Indikatoren-Match nach §15 GwG, den DPIA-Konformitäts-Check und die OWiG-Aufsichtspflicht-Bewertung. Die ML-Komponenten liefern ausschließlich Indikatoren mit Confidence-Scores, nie Entscheidungen, und bleiben so konform zu Art. 22 DSGVO.

Ein konkretes Beispiel: ein Mittelstands-Maschinenbauer mit 1.850 Mitarbeitern und 40.000 Eingangsrechnungen pro Jahr. Der Agent erkennt, dass ein Lieferant für Verpackungsmaterial seit sechs Monaten Rechnungen mit gleichem Nettobetrag von 24.500 Euro einreicht - knapp unter der Freigabegrenze von 25.000 Euro -, aber mit leicht variierenden Artikelbezeichnungen. Die Stammdaten-Validierung zeigt: USt-ID nicht im BZSt MIAS auffindbar, Handelsregister-Eintrag erst seit acht Monaten, im Transparenzregister kein wirtschaftlich Berechtigter. Die Netzwerkanalyse verknüpft die Bankverbindung dieses Lieferanten über eine gemeinsame zweite IBAN mit einem Mitarbeiter der Einkaufsabteilung. Der Agent klassifiziert: Betrug nach §263 StGB und Untreue durch den Mitarbeiter nach §266, während §266a und §299 nicht einschlägig sind; der fehlende wirtschaftlich Berechtigte ist ein Verdachtsmoment nach GwG §15. Die Verdachtsmeldung an die FIU Zoll wird automatisiert vorbereitet, der Prüfungsausschuss eskaliert (die Wesentlichkeitsschwelle ist überschritten: kumulierter Schaden von 6 x 24.500 Euro = 147.000 Euro, dazu eine geschätzte Dunkelziffer über 18 Monate), und die Strafanzeige-Vorlage nach StPO §158 wird mit allen Beweismitteln GoBD-konform nach AO §147 zusammengestellt. Das Dossier wird mit qualifiziertem Zeitstempel archiviert.

## IDW PS 210 Aufdeckungspflicht und Big-4 Substantive Testing-Schwerpunkt

Das Substantive Testing der Big Four nach PCAOB AS 2110, IDW PS 210 und PS 240 konzentriert sich beim Fraud-Audit auf vier Bereiche: Management-Override (Eingriffe der Geschäftsführung in Buchungen ohne Vier-Augen-Prinzip, typischerweise CEO-/CFO-Buchungen ohne Stellvertreter-Genehmigung), Umsatzmanipulation (Channel-Stuffing, Round-Tripping, Pre-Booking - laut ACFE 2024 in 32 Prozent der Fälle), das Verbergen von Aufwand (versteckte Verbindlichkeiten, Off-Balance-Sheet-Konstrukte, manipulierte Rückstellungen, oft bei Prüferwechseln) und Auffälligkeiten in Konzernverflechtungen (Intercompany-Round-Tripping, Transferpreis-Manipulation, Off-Shore-Konstrukte). Der Agent erzeugt die Fraud-Risk-Disclosures automatisch: das Tatbestands-Mapping nach StGB-Kategorien, eine Risiko-Heatmap mit Bestandsgefährdungs-Klassifikation nach AktG §91, den Wirksamkeitsstatus je Kontrolle, KPIs zu Detection-Rate, Meldequote, False-Positive-Rate und Aufdeckungszeit sowie die Verbandskontrolle nach OWiG §30/§130, abgestimmt auf die CMS-Komponenten nach IDW PS 980.

## Edge-Cases: Stellvertreterregelung, Konzern-Joint-Audits, Banken-MaRisk-Compliance, Kronzeugenregelung und AI-Forgery-Detection

Die Stellvertreterregelung ist die häufigste Edge-Case-Konstellation: Bei Urlaub oder Krankheit wird das Vier-Augen-Prinzip vorübergehend durch Delegation an einen Stellvertreter aufgehoben. Der Agent prüft jede Stellvertretung gegen den genehmigten Zeitraum und das Limit; bei Überschreitung eskaliert er an den Compliance-Officer und dokumentiert den SoD-Konflikt. Konzern-Joint-Audits nach IDW PS 951 Typ 2 sind bei Auslagerungen komplex: Lagert ein deutscher Konzern das Forderungsmanagement an einen externen Dienstleister aus, prüft der Wirtschaftsprüfer dessen IKS über 6 bis 12 Monate Wirksamkeit - die Fraud-Detection-Reports gehen in den Prüfungsbericht ein.

Bei Kreditinstituten verlangen KWG §25h, MaRisk AT 4.4.5 und BAIT 5.4 erweiterte Anforderungen: einen Geldwäschebeauftragten mit direktem Berichtsweg zum Vorstand, Real-Time-Transaction-Screening, Embargo-Listen-Abgleich (UN, EU, OFAC), mehrmals tägliches Sanktionslisten-Update und eine Zuverlässigkeitsprüfung der Mitarbeiter. BaFin-Prüfungen 2024 zeigen 67 Prozent der Institute mit Mängeln im BAIT-Berechtigungsmanagement; der Agent prüft das Banken-Fraud-IKS gegen den MaRisk-Pflichtkatalog und den FIU-Meldeworkflow.

Die Kronzeugenregelung des Bundeskartellamts ist der strategisch kritischste Edge-Case bei kartellrechtlichen Verdachtsmomenten: Der Erstmelder erhält bis zu 100 Prozent Bußgeld-Erlass, der Zweitmelder bis 50 Prozent, Folgemelder bis 30 Prozent. Bei dokumentierten Indizien ist die Selbstanzeige binnen 30 Tagen übliche Praxis; der GoBD-konforme Audit-Trail liefert die Beweisaufbereitung. Die AI-Forgery-Detection ist seit 2024 die dynamischste Kategorie - Anti-Fraud-Fachleute berichten von deutlich zunehmenden GenAI-Fälschungen, die visuelle Prüfung und regelbasierte Validierung umgehen. Der Agent kombiniert dafür drei Signale zu einem Confidence-Score: PDF-Metadaten-Forensik (Erstellungssoftware, Zeitstempel-Inkonsistenzen, Schriftarten-Embedding), LLM-Plausibilitätsprüfung (Layout-Konsistenz, Stempelechtheit, USt-ID- und Artikelnummern-Plausibilität) und Kontext-Anomalien (ein neuer Lieferant mit dem Betragsmuster eines bestehenden). Das Ergebnis ist nie eine Entscheidung, sondern immer eine Vorlage zur Prüfung durch den Compliance-Officer.

## Integration mit SAP GRC, DATEV Risk, AuditBoard, IBM Counter Fraud und der deutschen Prüfungsarchitektur

Der Agent bindet die führenden deutschen und internationalen Fraud-Detection- und GRC-Systeme über deren APIs an: SAP GRC Process Control mit Audit Management, Fraud Management und Business Integrity Screening als Konzern-Standard, DATEV Risk und Compliance für den Mittelstand, AuditBoard für SOX-Compliance, Diligent (ACL Analytics, HighBond) für Internal-Audit-Teams, IBM Counter Fraud Management und OpenPages für die Konzern-Pipeline, SAS Fraud Management und Anti-Money-Laundering sowie FICO Tonbeller und NICE Actimize für die Banken-AML. Hinzu kommen Workiva, ServiceNow GRC und Oracle Financial Crime and Compliance Management Cloud. Die FIU-Schnittstelle erzeugt die GwG-Verdachtsmeldung automatisiert über das goAML-Webportal; die Kronzeugen-Vorbereitung läuft über einen strukturierten, GoBD-konformen Beweismittel-Export. Das Substantive Testing der Big Four wird über den Datenexport an Deloitte ASM, PwC Aura, EY Helix und KPMG Clara unterstützt, jeweils mit Tatbestandsklassifikation nach IDW PS 210/240/261. Bei Banken kommen das BaFin-MaRisk-Reporting, die FIU-Anbindung und der Anzeige-Workflow nach AnzV hinzu. Die Architektur ist BSI-Grundschutz-konform nach BSI-Standard 200-2, dokumentiert die DSGVO-Art.-35-DPIA und nutzt die Pseudonymisierung gemäß BetrVG-§87-Betriebsvereinbarung als Standardmodus. Die Strafanzeige-Vorbereitung nach StPO §158 stellt die Beweismittel mit qualifiziertem Zeitstempel und zehn Jahren Aufbewahrung nach AO §147 für die Schwerpunktstaatsanwaltschaft Wirtschaftskriminalität bereit.

--- GoBD-Compliance-Agent ---
> GoBD-Compliance: Verfahrensdokumentation, 10-Jahres-Archivierung §147 AO, Festschreibung Rz. 107-109, IDEA-Z3-Zugriff für Betriebsprüfung und HGB §257-Konformität - BMF-konform.

Fehlende oder veraltete Verfahrensdokumentation ist der häufigste formelle Mangel, den Betriebsprüfer beanstanden. Wer bei der Prüfung keine aktuelle Dokumentation vorlegen kann, riskiert Hinzuschätzungen von bis zu zehn Prozent des Jahresumsatzes auf den steuerpflichtigen Gewinn. Das Problem ist nicht fehlendes Wissen - sondern fehlende Kontinuität.

## Verfahrensdokumentation veraltet schneller als jede Compliance-Abteilung sie pflegen kann

Die GoBD verlangen, dass jede Änderung an steuerrelevanten Prozessen dokumentiert wird - neue Software-Versionen, geänderte Buchungslogik, zusätzliche Schnittstellen. In einem typischen Finance-Bereich mit ERP, Treasury, Reisekostenabrechnung und Bankanbindung entstehen dutzende dokumentationspflichtige Änderungen pro Quartal.

Die Realität in den meisten Unternehmen: Die Verfahrensdokumentation wurde einmal erstellt, liegt als PDF auf einem Laufwerk und wurde seit dem letzten Audit nicht angefasst. Die tatsächlichen Prozesse haben sich längst weiterentwickelt. Dieses Delta zwischen dokumentiertem Soll und gelebtem Ist wächst mit jeder Systemanpassung.

Das Bürokratieentlastungsgesetz IV hat seit Januar 2025 die Aufbewahrungsfristen für Buchungsbelege von zehn auf acht Jahre verkürzt. Gleichzeitig fordert die DSGVO die Löschung personenbezogener Daten nach Wegfall des Aufbewahrungszwecks. Wer zu früh löscht, verstößt gegen die AO. Wer zu spät löscht, gegen die DSGVO. Ohne laufende Überwachung der Fristen ist beides kaum vermeidbar.

## Betriebsprüfer nutzen formelle Mängel als Hebel für Hinzuschätzungen

Seit die Finanzverwaltung digitale Prüfungstechniken einsetzt, hat sich der Fokus bei Betriebsprüfungen verschoben. Prüfer beginnen zunehmend mit der Anforderung der Verfahrensdokumentation, noch bevor sie in die Buchungsdaten einsteigen. Der Grund: Formelle Mängel in der Dokumentation sind einfacher nachzuweisen als materielle Fehler in der Buchhaltung.

Fehlen Protokolldateien, die Änderungen an Buchungsprozessen und Software-Versionen dokumentieren, reicht das nach aktueller Rechtsprechung bereits als Grundlage für eine Hinzuschätzung. Der Prüfer argumentiert, dass ohne diese Nachweise die Vollständigkeit und Unveränderbarkeit der Aufzeichnungen nicht nachvollziehbar ist. Sicherheitszuschläge von bis zu zehn Prozent des Umsatzes auf den steuerpflichtigen Gewinn sind dabei keine Seltenheit - bei einem mittelständischen Unternehmen mit 50 Millionen Euro Umsatz können das fünf Millionen Euro zusätzlicher Gewinn sein, die versteuert werden müssen (Quelle: AO §162, BFH-Rechtsprechung zu Hinzuschätzungen).

## Die E-Rechnungspflicht verschärft die Archivierungsanforderungen

Seit dem 1. Januar 2025 müssen alle Unternehmen im B2B-Bereich E-Rechnungen empfangen können. Das BMF hat am 14. Juli 2025 die zweite Änderung der GoBD veröffentlicht, die explizit die Archivierung hybrider Formate wie ZUGFeRD und Factur-X regelt. Die zentrale Neuerung: Bei E-Rechnungen muss mindestens der strukturierte XML-Teil archiviert werden. Der menschenlesbare PDF-Anteil ist nur dann zusätzlich aufbewahrungspflichtig, wenn er abweichende oder steuerlich relevante Zusatzinformationen enthält.

Für die GoBD-Compliance bedeutet das: Jede eingehende Rechnung muss auf ihr Format geprüft, der richtige Bestandteil archiviert und die Unveränderbarkeit per Zeitstempel und Hashwert sichergestellt werden. Das ist eine regelbasierte Entscheidung, die bei hunderten Rechnungen pro Woche manuell nicht zuverlässig funktioniert.

## Ein regelbasierter Agent hält Compliance aktuell, ohne Personalaufwand zu binden

Der GoBD-Compliance-Agent arbeitet überwiegend auf [Decision Layer](/de/decision-layer/) Stufe 1 - regelbasiert, nach klaren Vorgaben aus AO, HGB und GoBD. Archivierungspflicht, Aufbewahrungsfristen, Unveränderbarkeit und Datenzugriff folgen definierten Prüflogiken. Kein Ermessensspielraum, kein Interpretationsbedarf.

Für die Verfahrensdokumentation steigt der Agent auf Stufe 2: Er vergleicht dokumentierte Prozesse mit den tatsächlich ausgeführten Prozessen und schlägt Aktualisierungen vor. Ein Mensch prüft und gibt frei. Die Gesamtbewertung der Compliance-Risiken bleibt vollständig beim Menschen.

Ein konkretes Szenario: Das ERP-System erhält ein Update, das die Buchungslogik für Anzahlungsrechnungen ändert. Der Agent erkennt die Abweichung zwischen dokumentiertem und tatsächlichem Prozess, entwirft den aktualisierten Abschnitt der Verfahrensdokumentation und stellt sicher, dass die betroffenen Archivierungsregeln angepasst werden. Der Steuerberater oder Tax Manager gibt die Änderung frei. Die gesamte Historie - wer hat wann was geändert und warum - wird automatisch protokolliert. Genau diese Protokollierung ist es, die Betriebsprüfer als erstes anfordern.

## Compliance entsteht als Nebenprodukt, nicht als Zusatzaufwand

Der eigentliche Wert liegt nicht in der Automatisierung einzelner Prüfschritte, sondern im Paradigmenwechsel: GoBD-Konformität wird nicht mehr bei der nächsten Betriebsprüfung festgestellt, sondern kontinuierlich sichergestellt. Die Verfahrensdokumentation ist immer aktuell, weil sie bei jeder Prozessänderung automatisch fortgeschrieben wird. Fristen werden überwacht, bevor sie ablaufen. Und wenn der Betriebsprüfer Z1-, Z2- oder Z3-Zugriff anfordert, ist die Antwort sofort verfügbar - nicht nach drei Wochen hektischer Vorbereitung.

--- IKS-Monitoring-Agent ---
> Überwacht das Interne Kontrollsystem laufend gegen IDW PS 261 und AktG §91 und liefert lückenlose Evidenz für die DPR-Bilanzkontrolle.

Das Interne Kontrollsystem in Deutschland steht zwischen fünf parallelen Audit-Themen mit ganz unterschiedlichen Konsequenzen. AktG §91 Abs. 2 verlangt seit KonTraG 1998 von jedem AG-Vorstand ein Risikofrüherkennungssystem, abgesichert durch die persönliche Haftung nach §93 AktG. IDW PS 261 (2024 als PS 261 n.F. aktualisiert) regelt die Wirksamkeitsprüfung im Rahmen der Jahresabschlussprüfung mit Anpassung des Prüfungsumfangs. IDW PS 980 koppelt das CMS mit seinen sieben Komponenten an das IKS. Die DPR-Bilanzkontrolle prüft kapitalmarktorientierte Lageberichte stichprobenweise und kam 2024 auf 18 Prozent Fehlerquote. Und MaRisk AT 4.3 verlangt von Kreditinstituten gesonderte Mindestanforderungen unter BaFin-Aufsicht. Damit kann ein einziger geschäftsrelevanter Kontrollvorgang in einem deutschen Konzern oder Mittelständler bis zu fünf Audit-Prüfungen auslösen.

## IDW PS 261 Mängel kosten Mittelstand 30-150% höhere Prüfungskosten - DPR-Bilanzkontrolle erfasste 2024 über 350 Fälle

Die IDW-PS-261-Wirksamkeitsprüfung durch den Konzern-Wirtschaftsprüfer ist die häufigste Konsequenz unzureichender IKS-Strukturen. Der Prüfer dokumentiert im Prüfungsbericht nach HGB §317 Abs. 4 die Wirksamkeit des IKS und passt den Prüfungsumfang für das Substantive Testing an - Mängel führen zu 30 bis 150 Prozent Mehrkosten bei Big-Four-Stundensätzen von 280 bis 580 Euro. Bei einem Mittelständler mit 800 Prüfungsstunden Standardumfang sind das 224.000 bis 696.000 Euro Mehrbelastung pro Geschäftsjahr, über Folgejahre kumuliert sechsstellig.

Parallel läuft die DPR-Bilanzkontrolle als separates Verfahren bei kapitalmarktorientierten Gesellschaften. Die Deutsche Prüfstelle für Rechnungslegung prüfte 2024 über 350 Lageberichte stichprobenweise und anlassbezogen, mit 18 Prozent Fehlerquote - typische Findings sind unzureichende Risikobericht-Angaben nach HGB §289 Abs. 4, fehlende Wesentlichkeits-Begründungen bei Schätzungsunsicherheiten und fehlende IKS-Wirksamkeits-Angaben bei Mängeln. Bei festgestellten Fehlern muss das Unternehmen die Lageberichts-Korrektur ad-hoc veröffentlichen und dem Prüfungsausschuss berichten; eine Verweigerung führt zur BaFin-Eskalation mit Bußgeld bis 10 Mio Euro. Hinzu kommen die Risiken nach OWiG §30 und §130: Bei nachgewiesenem IKS-Versagen und dadurch ermöglichten Pflichtverstößen drohen Verbandsgeldbußen bis 10 Mio Euro und die Vorteilsabschöpfung; 2024 lagen Kartellbußen bei DAX-Konzernen bei bis zu 800 Mio Euro.

## Die 15 deterministischen Entscheidungspunkte mit zwei menschlichen Eskalationen

Der Agent verarbeitet jeden IKS-Vorgang in 15 strukturierten Entscheidungspunkten: 13 regelbasierte Klassifikationen, eine ML-basierte Anomalie-Erkennung (Buchungsmuster) und zwei menschliche Eskalationen für die Banken-Spezial-Prüfung nach MaRisk AT 4.3 und den Prüfungsausschuss nach §107 AktG. Die regelbasierten Schritte umfassen das Mapping auf die fünf COSO-Komponenten nach IDW PS 261, die Bestandsgefährdungs-Bewertung nach AktG §91, den Abgleich gegen die sieben Komponenten nach IDW PS 980 und den DPR-Lagebericht-Pflichtkatalog nach HGB §289 Abs. 4. Die ML-Anomalie-Erkennung markiert ungewöhnliche Buchungsmuster (Häufung knapp unter der Freigabegrenze, untypische Zeitstempel, Round-Sum-Auffälligkeiten); das Ergebnis ist ein Indikator für die Prüfung durch den Compliance-Officer, nie eine Entscheidung, und die Modell-Version ist GoBD-konform dokumentiert.

Ein konkretes Beispiel: ein Mittelständler mit 1.850 Mitarbeitern und einer Vertriebsgesellschaft in der Schweiz. Im Einkauf legt ein Mitarbeiter Lieferantenstammdaten an, erfasst Bestellungen und gibt Rechnungen zur Zahlung frei - drei Rollen, eine Person, ein klassischer SoD-Konflikt. Der Agent klassifiziert: Pflichtanwender nach AktG §91 Abs. 2 bestätigt (große GmbH), IDW-PS-261-Komponente Kontrollaktivitäten betroffen, SoD-Konflikt zwischen Anlage, Buchung und Freigabe identifiziert, Wesentlichkeitsschwelle von 5 Prozent des Konzernergebnisses überschritten (Vertragsvolumen 4,8 Mio Euro pro Jahr). Die Anomalie-Erkennung markiert eine Häufung von Bestellungen knapp unter dem Freigabelimit von 25.000 Euro (47 Bestellungen zwischen 24.500 und 24.999 Euro im Quartal) als Indikator. Der Agent erzeugt eine Eskalation an den Prüfungsausschuss mit Maßnahmen-Empfehlungen: Berechtigungsbereinigung binnen 30 Tagen, halbjährliche Rezertifizierung und eine Lagebericht-Angabe zur Wesentlichkeit nach HGB §289 Abs. 4. Das Prüfungsausschuss-Memo wird GoBD-konform mit qualifiziertem Zeitstempel archiviert.

## IDW PS 261 IKS-Wirksamkeitsprüfung als Big-4 Substantive Testing-Schwerpunkt

Das Substantive Testing der Big Four nach PCAOB AS 2110 und IDW PS 261 konzentriert sich beim IKS auf vier Bereiche: die Wirksamkeit der Funktionstrennung mit SoD-Konflikt-Prüfung (typischer Mangel: eine gewachsene Berechtigungsstruktur ohne periodische Bereinigung - IDW-Berichte 2024 zeigen 47 Prozent der Mittelständler mit über fünf Jahre nicht bereinigten SoD-Konflikten), die Vollständigkeit der Kontrollaktivitäten gegenüber den definierten Risiken (oft Lücken bei neuen Prozessen wie ESG-Reporting, Cyber-Risiken und AI-Governance), die Wirksamkeit der Monitoring-Komponente (Mangel: nur quartalsweise statt kontinuierliche Stichproben) und die Vollständigkeit der Angaben in Lage- und Konzernlagebericht nach HGB §289/§315. Der Agent erzeugt die IKS-Angaben automatisiert: das Mapping auf die fünf COSO-Komponenten nach IDW PS 261, eine Risiko-Heatmap nach der Wesentlichkeitsschwelle gemäß AktG §91, den Wirksamkeitsstatus je Komponente, KPIs zu Berechtigungsänderungen, SoD-Konflikten und Monitoring-Vollständigkeit sowie die Verbandskontrolle nach OWiG §30/§130, abgestimmt auf die CMS-Komponenten nach IDW PS 980.

## Edge-Cases: Stellvertreterregelung, Konzern-Joint-Audits, Banken-MaRisk und DPR-Anlassprüfung

Die Stellvertreterregelung ist die häufigste Edge-Case-Konstellation: Bei Urlaub oder Krankheit wird das Vier-Augen-Prinzip vorübergehend durch Delegation an einen Stellvertreter aufgehoben. Der Agent prüft jede Stellvertretung gegen den genehmigten Zeitraum und das Limit; bei Überschreitung eskaliert er an den Compliance-Officer. Konzern-Joint-Audits nach IDW PS 951 Typ 2 sind bei Auslagerungen komplex: Lagert ein deutscher Konzern die Lohnabrechnung an einen externen Dienstleister aus, prüft der Wirtschaftsprüfer dessen IKS über 6 bis 12 Monate Wirksamkeit. Der Agent liefert die Datenbasis über vollständigen Audit-Trail-Export und Wirksamkeitsnachweise.

Bei Kreditinstituten verlangen MaRisk AT 4.3 und BAIT 5.4 erweiterte Anforderungen: die funktionale Trennung von Markt, Marktfolge, Risikocontrolling, Compliance und Internal Audit, eine mindestens jährliche Rezertifizierung der Berechtigungen und die Just-in-Time-Vergabe kritischer Rechte. BaFin-Prüfungen 2024 zeigen 67 Prozent der Institute mit Mängeln im BAIT-Berechtigungsmanagement; der Agent prüft das Banken-IKS gegen den MaRisk-Pflichtkatalog. Die DPR-Anlassprüfung ist seltener (rund 15 Prozent der DPR-Verfahren 2024), aber kritisch - bei Kursauffälligkeiten oder Whistleblower-Hinweisen prüft die DPR ad-hoc; der Agent dokumentiert die IKS-Wirksamkeit fortlaufend als präventive Evidenz.

## Integration mit SAP GRC, DATEV, AuditBoard und der deutschen Prüfungsarchitektur

Der Agent bindet die führenden deutschen und internationalen GRC-Systeme über deren APIs an: SAP GRC Process Control, Risk Management und S/4HANA Internal Controls als Konzern-Standard, DATEV Konzern, Compliance und Audit Trail für den Mittelstand, Oracle Risk Management Cloud für Multi-Jurisdiction-Konzerne, AuditBoard für SOX-Compliance, Diligent Compliance Suite für das Aufsichtsrats-Reporting sowie Wolters Kluwer TeamMate+, MetricStream, Workiva und ServiceNow GRC. Die DPR-Schnittstelle erzeugt das Risikobericht-XML nach HGB §289 Abs. 4 automatisiert; das Prüfungsausschuss-Reporting läuft über Diligent Boards, Nasdaq Boardvantage und Microsoft Teams. Das Substantive Testing der Big Four wird über den Datenexport an Deloitte ASM, PwC Aura, EY Helix und KPMG Clara unterstützt, jeweils mit dem Mapping auf die fünf COSO-Komponenten nach IDW PS 261 und die sieben Komponenten nach IDW PS 980. Bei Banken kommen das BaFin-MaRisk-Reporting über die Meldewesen-Tools und die Auslagerungs-Anzeige hinzu. Die Steuerbilanz-Schnittstelle zu DATEV LODAS und SAP TaxBox arbeitet GoBD-konform mit qualifiziertem Zeitstempel nach BMF 28.11.2019. Die Konfiguration ist BetrVG-konform: Pseudonymisierung als Standardmodus und eine dokumentierte Zweckbindung über die Betriebsvereinbarung.

--- Intercompany-Agent ---
> Gleicht IC-Salden reciprocal ab, validiert Verrechnungspreise nach AStG §1, GAufzV und BMF 2021 und liefert Master-File, Local-File und CbCR nach BEPS Action 13 mit GoBD-Audit-Trail ans BZSt.

Verrechnungspreis-Compliance in Deutschland steht zwischen fünf parallelen Anforderungen mit ganz unterschiedlichen Konsequenzen für Konzernsteuerleitung, Vorstand und Wirtschaftsprüfung. AStG §1 verlangt den Fremdvergleichsgrundsatz bei jeder grenzüberschreitenden Geschäftsbeziehung und berichtigt den steuerlichen Gewinn bei nicht fremdüblichen Preisen. Die GAufzV fordert nach §90 Abs. 3 AO die zweistufige Master- und Local-File-Dokumentation mit 60-Tage-Vorlagefrist und einem Strafzuschlag bis 10 Prozent des Mehrgewinns bei Versäumnis. Das BMF-Schreiben vom 14.07.2021 regelt die Standardmethoden und die DEMPE-Funktionsanalyse bei immateriellen Wirtschaftsgütern. BEPS Action 13 verlangt nach AO §138a ab 750 Mio Euro Konzernumsatz das Country-by-Country-Reporting ans BZSt mit automatischem Austausch an über 100 Staaten. Und ATAD II (Zinsschranke nach KStG §8a, Hybrid-Mismatch-Regeln) sowie die Hinzurechnungsbesteuerung nach AStG §7 ff. definieren die Anti-Tax-Avoidance-Anforderungen mit erheblichen Risiken bei hybrid finanzierten Strukturen. Damit kann eine einzige Verrechnungspreis-Position bis zu fünf Compliance-Pflichten gleichzeitig auslösen - mit DPR-Mängelbericht-Risiko, FISG-Forensik-Audit-Vorbereitung und einem möglichen Verständigungsverfahren bei einseitiger Korrektur durch den Auslandsstaat.

## Fünf bis sechs Tage IC-Abstimmung pro Monatsabschluss und ein DPR-Bußgeldrisiko bis 10 Mio Euro

Ein Konzern mit 30 Gesellschaften hat bis zu 435 mögliche Gesellschaftspaare, typisch 100 bis 150 aktive IC-Beziehungen mit hunderten Transaktionen pro Monat. Die Hackett Group 2024 dokumentiert: Die manuelle Abstimmung in Excel kostet fünf bis sechs Arbeitstage pro Monatsabschluss bei Match-Quoten von 60 bis 70 Prozent. Den größten Teil der Zeit fressen der Datenexport aus den ERP-Systemen, die Konsolidierung der Konten-Mappings und die Klärung der Differenzen; die eigentliche Preis-Plausibilisierung dauert nur Stunden. Bei kapitalmarktorientierten Unternehmen kommen erhebliche Compliance-Risiken hinzu: die 60-Tage-Vorlagefrist der GAufzV mit Strafzuschlag bis 10 Prozent des Mehrgewinns, die AStG-§1-Berichtigung mit Beweislastumkehr, eine Doppelbesteuerung bei einseitiger Korrektur mit jahrelangem Verständigungsverfahren sowie ein DPR-Mängelbericht mit Kursreaktionen von -3 bis -8 Prozent und BaFin-Sanktionen bis 10 Mio Euro. Die typische Situation bei 30 Töchtern sieht so aus: Group Accounting fordert die IC-Salden an, sammelt Excel-Dateien in unterschiedlichen Formaten, baut manuelle Matching-Tabellen, klärt Differenzen per E-Mail-Pingpong und erstellt am Ende ein Konsolidierungs-Sheet ohne Audit-Trail. Dieser Ablauf wiederholt sich Monat für Monat nahezu identisch - ohne Compliance-Evidenz für GAufzV, BEPS und DPR.

## 14 deterministische Etappen mit fünf menschlichen Eskalationen

Der Agent zerlegt den Intercompany-Workflow in 14 Entscheidungsschritte mit klarer Decider-Trennung: neun regelbasierte Schritte (R), drei ML-gestützte Indikator-Schritte (A) und zwei menschliche Eskalationen (H). ERP-Datenintegration und Stammdaten-Mapping laufen regelbasiert mit GoBD-konformem Audit-Trail und Hash-Validierung. Der Reciprocal-Match prüft je Gesellschaftspaar in vier Stufen: einen Hash-Match auf Belegebene, einen Toleranz-Match mit Betrags- und Datums-Toleranz, einen Cross-Reference-Match über Belegnummern und einen semantischen Match über Konto- und Kostenstellen-Mapping. Die Timing-Difference-Analyse läuft datumsbasiert mit 1 bis 3 Tagen Toleranz und Cut-Off-Prüfung (HGB §252 Abs. 1 Nr. 5), die FX-Berechnung über Stichtagskurs-Umrechnung beider Seiten (IAS 21, IFRS 9). Die Preis-Plausibilisierung erfolgt ML-gestützt mit Comparability- und DEMPE-Analyse gegen den Fremdvergleichsgrundsatz nach AStG §1. Die Eliminierungsbuchungen werden regelbasiert nach HGB §303 bis §305 und IFRS 10 erzeugt. Die DEMPE-Funktionsanalyse trifft das Konzernsteuer-Team, die Cash-Pool-Verzinsung wird gegen EURIBOR-Aufschlag und Bonitätsaufschlag geprüft (Zinsschranke KStG §8a). Master- und Local-File werden LLM-gestützt als Entwurf erzeugt und vom Konzernsteuer-Lead finalisiert. Das Country-by-Country-Reporting läuft regelbasiert mit Schwellenwert-Prüfung bei 750 Mio Euro und BZSt-Einreichung binnen 12 Monaten. Die forensische Anomalie-Erkennung (Last-Minute-Muster, Round-Number-Bias, Benford) dient der FISG-Audit-Vorbereitung. Bei den fünf menschlichen Schritten - Preis-Plausibilisierung, DEMPE-Analyse, Master- und Local-File-Finalisierung und nicht erklärbare Differenzen - dokumentiert der Decision Layer Begründung, Datenbasis und Verantwortlichen.

## Reciprocal-Match transformiert IC-Abstimmung in operative Konzern-Compliance

Eine Differenz von 340.000 Euro zwischen der IC-Forderung der Mutter und der IC-Verbindlichkeit der polnischen Tochter sagt für sich genommen wenig. Erst die strukturierte Reciprocal-Match-Methodik macht sie handlungsrelevant: 180.000 Euro Timing-Difference, weil die Lieferung am 30. erfolgte, die Tochter aber erst am 2. des Folgemonats buchte (regelbasierte Cut-Off-Klassifikation mit Folgemonats-Validierung); 95.000 Euro FX-Differenz durch unterschiedliche Stichtagskurse (regelbasierte Umrechnung mit IAS 21 und IFRS 9); 65.000 Euro Preis-Abweichung durch gebuchten Preis 102 statt vertraglich vereinbarten 100 (ML-gestützte Plausibilisierung gegen den TNMM-Margenkorridor mit DEMPE-Analyse). Jede Komponente erfordert eine andere Reaktion: Die Timing-Difference löst sich beim nächsten Abgleich automatisch auf, die FX-Differenz wird im Konzernabschluss über GuV oder Eigenkapital neutralisiert, und die Preis-Abweichung wird an den Konzernsteuer-Lead eskaliert (AStG-§1-Berichtigungsprüfung, DEMPE-Konsistenz). Die herkömmliche Excel-Abstimmung erschöpft sich dagegen in Kommentaren wie \"Differenz 340k - Klärung mit PL-Tochter\" ohne weitere Konsequenz - Compliance-Theater statt Evidenz. Die Reciprocal-Match-Methodik verwandelt jede wesentliche Differenz in einen Workflow mit fünf Pflicht-Komponenten: identifizierte Differenz mit Klassifikation (Was?), benannter Owner (Wer?), konkrete Klärungsmaßnahme (Wie?), Deadline binnen 5 bis 10 Arbeitstagen (Wann?) und die im Anhang nach HGB §313/§314 dokumentierte Eliminierungsdifferenz (Wie viel?). Der Decision Layer protokolliert jeden Schritt mit Audit-Trail, eskaliert bei Verzögerung und informiert bei wesentlichen Differenzen den Konzern-CFO. Bei substanziellen Auffälligkeiten eskaliert er an Konzernsteuer-Lead, Wirtschaftsprüfer und gegebenenfalls externe Forensik-Berater nach FISG 2021.

## Edge-Cases mit deutscher Konzernsteuer-Spezifik

Bei kapitalmarktorientierten Unternehmen gelten verschärfte DPR-Schwerpunkte 2024-2026: die Wesentlichkeit im Konzern-Anhang, die Konsistenz der Verrechnungspreis-Disclosure mit der Lagebericht-Prognose, latente Steuern bei Preisanpassungen, die Konsolidierung bei Akquisitionen und die Anerkennung der DEMPE-Analyse. Konzerne über 750 Mio Euro Umsatz unterliegen der CbCR-Pflicht nach §138a AO mit BZSt-Einreichung binnen 12 Monaten, automatischem Austausch an über 100 Staaten und der Public-CbCR-Pflicht für Geschäftsjahre ab dem 22.06.2024. Bei immateriellen Wirtschaftsgütern (Patente, Marken, Software, Know-how) gilt die DEMPE-Funktionsanalyse nach BEPS Actions 8-10 und OECD TPG 2022 (Chapter VI); die rein rechtliche Inhaberschaft genügt nicht für den Anspruch auf den Lizenzerlös, sondern nur die tatsächliche Funktionswahrnehmung und Risiko-Tragung. Bei Funktionsverlagerung gilt zusätzlich das BMF-Schreiben vom 06.06.2023 mit Transferpaket-Bewertung (AStG §1 Abs. 6, IDW S 5). Bei Cash-Pooling, Konzernumlagen und -finanzierungen greifen die Zinsschranke nach KStG §8a (EBITDA-Limit 30 Prozent, Freibetrag 3 Mio Euro), die ATAD-II-Hybrid-Mismatch-Regeln, die Mitwirkungspflicht nach AStG §90 Abs. 3 und die AWV-Meldepflicht K3. Für DAC6-Meldungen grenzüberschreitender Steuergestaltungen sowie für Verständigungsverfahren nach der EU-Streitbeilegungs-Richtlinie 2017/1852 erzeugt der Agent eine strukturierte, GoBD-konform dokumentierte Vorbereitung. Für die FISG-Forensik-Audit-Vorbereitung dokumentiert er die Anomalie-Erkennung (Benford, Round-Number-Bias, Last-Minute-Muster), die Hash-Validierung zur Manipulations-Erkennung und den Workflow der IC-Klärungen.

## Konsistenz mit dem Konsolidierungs-Agent und Integration in deutsche Konzern-Plattformen

Der Intercompany-Agent ergänzt den Konsolidierungs-, den Budget-Variance- und den Konzernsteuer-Agent: Der Konsolidierungs-Agent übernimmt die Vollkonsolidierungs-Mechanik (Kapitalkonsolidierung §301, Vollkonsolidierung §300, Equity-Methode §312), der Budget-Variance-Agent die Soll-Ist-Analyse mit Driver-Tree-Decomposition, der Konzernsteuer-Agent die Berechnung der latenten Steuern nach HGB §274 und IAS 12. Die Reciprocal-Match-Engine wird vom Konsolidierungs-Agent zur Schuldenkonsolidierung wiederverwendet, die DEMPE-Analyse und die Master-/Local-File-Generierung vom Konzernsteuer-Agent für latente Steuern und DAC6-Meldungen. Über den Decision-Layer-Datenbus werden die Eckwerte mit Reconciliation-Audit-Trail abgeglichen; bei Inkonsistenz eskaliert der Agent an Konzernsteuer-Lead, Group Accounting und Wirtschaftsprüfer. Bei den Konzern-Plattformen ist SAP S/4HANA Group Reporting mit BPC der Standard, Lucanet der DRS-20-Spezialist für den Mittelstand (rund 4.500 Kunden); hinzu kommen OneStream, der BlackLine Intercompany Hub mit dedizierter Reciprocal-Match-Engine, CCH Tagetik mit DAC4-CbCR-Generierung und Workiva mit ESEF-XBRL-Tagging. Für die Verrechnungspreise binden TP Catalyst, TPgenie und Vertex Transfer Pricing die DEMPE- und Comparability-Analyse an. Der Decision Layer dokumentiert jeden Schritt nach IDW PS 261/314/350/951/320 als FISG-konforme Forensik-Evidenz - zugleich Compliance-Nachweis für die 60-Tage-Vorlagepflicht, das CbCR ab 750 Mio Euro, ATAD II und den Fremdvergleichsgrundsatz nach AStG §1.

--- Rechnungsfreigabe-Agent ---
> Routet Eingangsrechnungen nach Freigabematrix (Betrag, Kostenstelle, Projekt), prüft Budgetverfügbarkeit, validiert Lieferanten gegen GwG/LkSG-Sperrlisten, eskaliert Vier-Augen nach IDW PS 951.

Jede Rechnung, die einen Tag zu spät freigegeben wird, ist eine verpasste Entscheidung. Nicht weil jemand sie vergessen hat, sondern weil die Zuordnung zum richtigen Freigeber in den meisten Unternehmen ein manueller Vorgang ist - abhängig von Wissen in einzelnen Köpfen, nicht von klaren Regeln im System. Der Rechnungsfreigabe-Agent macht aus diesem Engpass eine berechenbare Strecke.

## Verspätete Freigaben vernichten Skonto-Erträge im Stillen

Ein typisches Skonto-Fenster beträgt zehn Tage. Zehn Tage, in denen eine Rechnung erfasst, geprüft, zugeordnet, freigegeben und zur Zahlung angewiesen werden muss. Laut einer Analyse von Nanonets liegt die durchschnittliche Bearbeitungszeit einer Rechnung bei 9,2 Tagen - und das ist der Durchschnitt. Bei Unternehmen ohne strukturierte Freigabeprozesse steigt diese Zahl auf über 17 Tage (Nanonets, 2025).

Das Ergebnis: Bei einem Einkaufsvolumen von 50 Millionen Euro und 2 % Skonto auf die Hälfte der Rechnungen bleiben jedes Jahr 500.000 Euro liegen - nicht weil die Konditionen fehlen, sondern weil der Freigabeprozess zu langsam ist. Das Geld verschwindet nicht in einem einzelnen Vorfall. Es versickert in hunderten von Einzelfällen, die niemand aggregiert.

## Die Freigabematrix ist ein Regelwerk - kein Ermessensspielraum

Die Frage "Wer darf diese Rechnung freigeben?" klingt nach Ermessen. In der Praxis ist sie das Gegenteil. Die Antwort ergibt sich aus einer festen Kombination von Betragsgrenzen, Kostenstelle, Projekt und Lieferant. Ein Regelwerk, das in den meisten ERP-Systemen bereits hinterlegt ist - aber manuell angewendet wird.

Der Agent übernimmt genau dieses Routing. Er liest die Freigabematrix, ordnet die Rechnung dem zuständigen Freigeber zu und prüft parallel, ob Budget auf der Kostenstelle verfügbar ist und ob der Lieferant gesperrt ist. Drei Entscheidungen, die zusammen weniger als eine Sekunde dauern - und im manuellen Prozess oft Stunden oder Tage beanspruchen, weil sie über verschiedene Systeme und Postfächer verteilt sind.

[Decision Layer](/de/decision-layer/) Stufe 1: Alle drei Prüfungen folgen deterministischen Regeln. Es gibt keinen Interpretationsspielraum, keine Grauzone, keine Ausnahme, die nicht vorab definiert werden kann.

## Eskalationslogik schützt Fristen, bevor sie ablaufen

Das häufigste Problem bei der Rechnungsfreigabe ist nicht die falsche Entscheidung. Es ist die ausbleibende Entscheidung. Eine Rechnung liegt im Postfach des zuständigen Freigebers, der im Meeting sitzt, auf Dienstreise ist oder schlicht überlastet.

Der Agent überwacht jede laufende Freigabe gegen konfigurierte Fristen. Nähert sich eine Skonto-Frist dem Ende, eskaliert er an den definierten Vertreter - nicht nach drei Erinnerungsmails, sondern nach einer klaren Regel: Wenn Freigabe nicht innerhalb von X Stunden erfolgt, weiterleiten an Hierarchieebene Y.

Ein konkretes Szenario: Ein Zulieferer stellt am Dienstag eine Rechnung über 85.000 Euro mit 2 % Skonto bei Zahlung innerhalb von zehn Tagen. Der zuständige Abteilungsleiter ist bis Freitag auf einer Konferenz. Der Agent erkennt die Abwesenheit, routet an die Stellvertretung, und die Freigabe erfolgt am Mittwoch. Ohne Eskalationslogik wäre die Rechnung frühestens am folgenden Montag bearbeitet worden - vier Tage nach Ablauf der Skontofrist. 1.700 Euro Verlust bei einem einzigen Vorgang.

## Sammelfreigabe beschleunigt den Standardfall

Nicht jede Rechnung verdient individuelle Aufmerksamkeit. Wiederkehrende Rechnungen desselben Lieferanten, für denselben Betrag, auf dieselbe Kostenstelle - sie folgen einem Muster, das der Agent erkennt. Diese Fälle qualifizieren sich für die Sammelfreigabe: Der Freigeber erhält eine gebündelte Übersicht statt einzelner Vorgänge.

Das entlastet nicht nur die Freigeber, sondern verändert die Kapazitätsverteilung im gesamten Accounts-Payable-Prozess. Laut HighRadius erreichen Best-in-Class AP-Teams eine durchschnittliche Bearbeitungszeit von 3,1 Tagen pro Rechnung, verglichen mit 17,4 Tagen bei Teams ohne strukturierte Prozesse (HighRadius, 2025). Die Sammelfreigabe ist einer der Hebel, der diesen Unterschied erklärt.

## Der Mensch entscheidet dort, wo Regeln nicht ausreichen

Von sieben Entscheidungsschritten in der Rechnungsfreigabe sind sechs vollständig regelbasiert. Der siebte nicht: die Freigabe bei Budgetüberschreitung.

Wenn eine Rechnung den verfügbaren Rahmen der Kostenstelle übersteigt, gibt es keinen Algorithmus, der entscheiden kann, ob die Ausgabe trotzdem berechtigt ist. Vielleicht ist das Budget veraltet. Vielleicht wurde eine Nachtragsbestellung mündlich vereinbart. Vielleicht ist die Lieferung geschäftskritisch und der Budgetprozess hinkt der Realität hinterher.

Decision Layer Stufe 2: Der Agent liefert dem Entscheider alle Fakten - Rechnungsbetrag, Restbudget, bisherige Ausgaben auf der Kostenstelle, Lieferantenhistorie - und hält die Entscheidung offen. Kein Vorschlag, keine Empfehlung, nur eine strukturierte Entscheidungsvorlage. Die Verantwortung bleibt beim Menschen, aber die Vorbereitung dauert Sekunden statt Stunden.

--- Eingangsrechnungs-OCR-Agent ---
> Liest XRechnung, ZUGFeRD, PEPPOL und PDF-Eingangsrechnungen per OCR/LLM, prüft §14-UStG-Pflichtangaben, validiert EN 16931, archiviert GoBD 2025-konform 8 Jahre nach AO §147.

Rechnungseingang bindet in den meisten Finanzabteilungen mehr Kapazität als jeder andere Einzelprozess in der Kreditorenbuchhaltung. Ein Unternehmen mit 10.000 Eingangsrechnungen pro Monat beschäftigt drei bis fünf Vollzeitkräfte allein damit, Belege zu öffnen, Daten abzutippen und Pflichtangaben zu prüfen. Gleichzeitig treibt die E-Rechnungspflicht ab 2027 den Formatwechsel voran. Wer jetzt nicht automatisiert, baut eine Prozessschuld auf, die mit jedem Quartal teurer wird.

## Manuelle Erfassung kostet Unternehmen 15 bis 25 Euro pro Rechnung

Die Vollkosten einer manuell verarbeiteten Eingangsrechnung liegen im europäischen Mittelstand zwischen 15 und 25 Euro - je nach Unternehmensgröße, Anzahl der Freigabestufen und Nacharbeitsquote. In dieser Zahl stecken Personalkosten, Fehlerkorrektur, Archivierung und der unsichtbarste Posten: Skontoentgang durch verspätete Bearbeitung. Laut Ardent Partners State of ePayables liegen die Kosten pro Rechnung bei Best-in-Class-Organisationen bei 2,78 USD gegenüber 12,88 USD im Durchschnitt. Jeder Eingabefehler löst einen Korrekturzyklus aus, der die Durchlaufzeit verdoppelt.

Bei 10.000 Rechnungen im Monat summiert sich das auf 150.000 bis 250.000 Euro Prozesskosten pro Jahr - bevor die erste Buchung im ERP steht.

## Die E-Rechnungspflicht verschärft den Handlungsdruck ab 2027

Seit Januar 2025 muss jedes Unternehmen in Deutschland strukturierte E-Rechnungen empfangen können. Die Übergangsregelung erlaubt bis Ende 2026 noch PDF und Papier. Ab 2027 wird der Versand von E-Rechnungen im B2B-Verkehr für die meisten Unternehmen zur Pflicht - nur Betriebe mit maximal 800.000 Euro Vorjahresumsatz erhalten Aufschub bis 2028. Die zulässigen Formate sind XRechnung und ZUGFeRD ab Profil EN 16931 (Quelle: BMF FAQ E-Rechnung, Stand 2025).

Das bedeutet konkret: Ihre Kreditorenbuchhaltung empfängt in den kommenden Monaten immer mehr XML-Dateien statt eingescannter PDFs. Ein Prozess, der auf Sichtkontrolle und manuelle Dateneingabe ausgelegt ist, kann diesen Formatwechsel nicht abbilden. Wer weiterhin manuell erfasst, muss entweder Personal aufstocken oder Durchlaufzeiten akzeptieren, die Skontofristen sprengen.

## Ein regelbasierter Agent ersetzt 90% der manuellen Schritte

Der Rechnungseingangs-Agent zerlegt die Erfassung in acht einzelne Entscheidungsschritte. Nur zwei davon - Dokumenttyp-Erkennung und Datenextraktion - benötigen eine KI-Klassifikation für unstrukturierte Eingänge wie Scans oder fotografierte Belege. Die übrigen sechs Schritte sind vollständig regelbasiert: Pflichtangabenprüfung gegen den Katalog des §14 UStG, Duplikatprüfung über Rechnungsnummer und Betrag, Schema-Validierung des E-Rechnungsformats, Kreditorenzuordnung über Stammdaten, GoBD-konforme Archivierung und Weiterleitung an den nächsten Prozessschritt.

Dieses Verhältnis - sechs regelbasierte Schritte, zwei KI-gestützte - erklärt die hohe Automatisierungsquote. Der Agent trifft keine Bewertungsentscheidungen. Er liest, prüft gegen definierte Kriterien und leitet weiter. Bei Abweichungen eskaliert er an den zuständigen Sachbearbeiter, statt selbst zu interpretieren. Das ist [Decision Layer](/de/decision-layer/) Stufe 1: Regelwerk entscheidet, KI extrahiert, Mensch übernimmt die Ausnahmen.

Ein konkretes Szenario: Ein mittelständischer Maschinenbauer empfängt monatlich 4.500 Eingangsrechnungen - ein Drittel als ZUGFeRD-PDF, ein Drittel als XRechnung-XML, der Rest als klassische PDF-Scans von Kleinlieferanten. Der Agent verarbeitet die strukturierten Formate vollautomatisch in unter drei Sekunden pro Beleg. Für die unstrukturierten Scans extrahiert die LLM-Pipeline Rechnungsnummer, Betrag und Leistungszeitraum mit Confidence-Score. Liegt der Score unter dem definierten Schwellenwert, geht der Beleg an einen Sachbearbeiter. In der Praxis betrifft das weniger als 5% des Volumens.

## Reverse-Charge und EU-Lieferungen brauchen automatisierte USt-IdNr.-Prüfung

Für innergemeinschaftliche Lieferungen ist die qualifizierte Bestätigungsabfrage der USt-IdNr. nach §18e UStG Pflicht - ohne sie greift keine Steuerfreiheit, und der Vorsteuerabzug nach §15 UStG ist gefährdet. Der Agent ruft das MIAS-System (Mehrwertsteuer-Informationsaustausch) des BZSt für jede EU-Lieferung in Echtzeit auf, dokumentiert das Bestätigungsergebnis im Decision Log und setzt den Buchungsschlüssel entsprechend (Reverse-Charge nach §13b UStG mit gleichzeitigem Vorsteuer-Pendant). Bei Bauleistungen, Edelmetall-Lieferungen oder Sicherungsübereignung greift §13b UStG auch innerhalb Deutschlands - die Lieferanten-Land-Logik allein reicht nicht aus, der Agent prüft zusätzlich die Leistungsart-Klassifikation gegen die §13b-Liste.

Praktischer Effekt: Eine deutsche Maschinenbau-Firma mit 30% innergemeinschaftlichen Lieferungen aus Italien, Frankreich und Polen erhält pro Monat etwa 1.300 EU-Eingangsrechnungen. Manuelle MIAS-Prüfung dauert pro Beleg 30-60 Sekunden - das sind 13-26 Stunden Sachbearbeiter-Zeit pro Monat allein für die Validierung. Der Agent erledigt das in Sekunden mit dokumentiertem Bestätigungs-Log, das bei einer Umsatzsteuer-Sonderprüfung sofort vorgelegt werden kann.

## GoBD-konforme Archivierung entsteht als Nebenprodukt des Prozesses

Die GoBD 2025 verlangt bei E-Rechnungen die Archivierung sowohl der XML-Datei als auch des PDF - nur eines von beiden reicht nicht mehr. Jeder Beleg braucht einen qualifizierten Zeitstempel und muss unveränderbar gespeichert werden. Die Aufbewahrungsfrist beträgt nach AO §147 acht Jahre.

In manuellen Prozessen ist die Archivierung ein separater Arbeitsschritt, der vergessen oder fehlerhaft ausgeführt werden kann. Der Agent archiviert jeden verarbeiteten Beleg automatisch als Teil des Erfassungsprozesses. XML und PDF werden mit Zeitstempel versehen und unveränderbar abgelegt. Jede Validierungsentscheidung - Pflichtangaben vorhanden, Format valide, kein Duplikat - wird im Decision Log protokolliert. Dieses Log bildet die Verfahrensdokumentation, die das Finanzamt bei einer Betriebsprüfung verlangt.

Die Archivierung ist damit kein zusätzlicher Aufwand, sondern ein Nebenprodukt der automatisierten Erfassung. Das ist der Unterschied zwischen einem Tool, das Rechnungen scannt, und einer Infrastruktur, die den gesamten Dokumenteneingang regelt.

--- Rechnungsausgangs-Agent ---
> Erstellt Ausgangsrechnungen vollständig regelbasiert (0 % KI): bestimmt USt-Satz nach §14/§14a UStG, generiert XRechnung 3.0 oder ZUGFeRD 2.3 pro Kunde, vergibt lückenlose Nummernkreise GoBD-konform.

Rechnungserstellung bindet Kapazität, die in der Finanzabteilung an anderer Stelle fehlt. Gleichzeitig steigt der regulatorische Druck durch die E-Rechnungspflicht. Der Rechnungsausgangs-Agent löst beides: Er erstellt Ausgangsrechnungen vollständig regelbasiert - ohne KI-Anteil, ohne manuelle Eingriffe, mit lückenloser GoBD-Konformität ab dem ersten Beleg.

## Fehlerhafte Rechnungen kosten mehr als nur Nacharbeit

Ein substanzieller Anteil aller manuell erstellten Rechnungen enthält Fehler. Die Korrektur eines einzelnen fehlerhaften Belegs kostet im zweistelligen USD-Bereich, wenn Personalaufwand, Systemkorrekturen und Zahlungsverzögerungen eingerechnet werden. Bei einem Unternehmen, das 500 Ausgangsrechnungen pro Monat verarbeitet, summieren sich die fehlerhaften Belege auf einen vierstelligen Euro-Korrekturaufwand - jeden Monat, bevor der eigentliche Schaden durch verspätete Zahlungseingänge überhaupt berücksichtigt ist.

Fehler bei Ausgangsrechnungen sind dabei selten zufällig. Falsche Umsatzsteuersätze bei innergemeinschaftlichen Lieferungen, fehlende Pflichtangaben nach Paragraph 14 UStG, inkonsistente Zahlungsbedingungen - das sind systematische Schwächen, die aus dem gleichen manuellen Prozess immer wieder entstehen. Genau diese Systematik macht den Fehler regelbasiert lösbar.

## Die E-Rechnungspflicht verschärft den Handlungsdruck

Seit dem 1. Januar 2025 müssen alle Unternehmen in Deutschland E-Rechnungen im B2B-Verkehr empfangen können. Die Übergangsfrist für den Versand läuft Ende 2026 aus. Danach gilt: Jede Ausgangsrechnung muss als strukturierter Datensatz im Format XRechnung oder ZUGFeRD vorliegen - nicht als PDF, nicht als Scan.

Hinter dieser Pflicht steht ein konkretes Ziel der Bundesregierung: die deutsche Mehrwertsteuerlücke von rund 22 Milliarden Euro zu schließen (Quelle: DATEV Magazin / EU-Kommission). Für Finanzabteilungen bedeutet das einen Formatwechsel, der weit über die Rechnungsstellung hinausreicht. Jeder Beleg muss maschinenlesbar sein, die Pflichtfelder müssen exakt dem Schema entsprechen, und das gewählte Format muss pro Kunde konfigurierbar bleiben.

Wer diesen Wechsel manuell steuert, baut neue Fehlerquellen in einen ohnehin fehleranfälligen Prozess ein. Wer ihn automatisiert, eliminiert das Formatproblem als Entscheidungspunkt.

## Acht Entscheidungsschritte ersetzen den manuellen Prozess

Ein konkretes Szenario: Ein Projektdienstleister stellt monatlich 400 Ausgangsrechnungen an Kunden in Deutschland, der EU und der Schweiz. Bisher prüft ein Sachbearbeiter für jeden Beleg den USt-Satz, ergänzt Pflichtangaben, wählt das Format und vergibt die Rechnungsnummer manuell.

Der [Decision Layer](/de/decision-layer/) zerlegt diesen Prozess in acht deterministische Schritte. Leistungsdaten werden aus dem Quellsystem abgerufen. Pflichtangaben nach Paragraph 14 UStG werden automatisch zusammengestellt. Der USt-Satz ergibt sich aus dem Kundenstandort und der Leistungsart - 19 Prozent Inland, innergemeinschaftlich steuerfrei, Drittland ohne USt. Das E-Rechnungsformat wird aus den Kundenstammdaten abgeleitet. Zahlungsbedingungen kommen aus dem Vertrag. Die Rechnungsnummer wird atomar vergeben - keine Lücken, keine Doppelvergabe. Versand und Archivierung erfolgen zeitgleich.

Alle acht Schritte sind regelbasiert. Kein Schritt erfordert eine Einschätzung, eine Abwägung oder eine Prognose. Deshalb liegt der KI-Anteil bei exakt null Prozent - und die Readiness bei 89 bis 96 Punkten, dem höchsten Wert im gesamten Katalog.

## GoBD-Konformität entsteht im Prozess, nicht in der Nachkontrolle

Die GoBD verlangt drei Dinge von jeder Ausgangsrechnung: lückenlose Nummernvergabe, unveränderbare Archivierung und vollständige Nachvollziehbarkeit. In manuellen Prozessen werden diese Anforderungen typischerweise durch nachgelagerte Kontrollen sichergestellt - eine Prüfung am Monatsende, ein Abgleich der Nummernkreise, ein manueller Archivierungslauf.

Der Rechnungsausgangs-Agent dreht diese Logik um. Die Nummernvergabe ist atomar in den Erstellungsprozess integriert. Die Archivierung erfolgt zeitgleich mit dem Versand, nicht danach. Und jede Entscheidung - welcher Steuersatz, welches Format, welcher Versandkanal - wird mit Zeitstempel und Begründung protokolliert. Bei einer Betriebsprüfung liegt der vollständige Entscheidungspfad für jeden einzelnen Beleg vor.

Für CFOs bedeutet das: GoBD-Konformität ist kein Prüfungsrisiko mehr, sondern eine Systemeigenschaft. Der Decision Layer auf Stufe 1 - reines Regelwerk - macht den Rechnungsausgang zum verlässlichsten Prozess in der gesamten Debitorenbuchhaltung.

--- Buchungssatz-Agent ---
> Schlägt Abschlussbuchungen vor, kontiert gegen DATEV SKR03/SKR04 und liefert die §5b EStG E-Bilanz-Taxonomie revisionssicher für die Außenprüfung.

Buchungssätze sind in Deutschland gleichzeitig handelsrechtliche Pflicht (HGB §238 für Kaufleute, §289 Abs. 4 für mittelgroße/große Kapitalgesellschaften), steuerrechtliche Pflicht (AO §140 abgeleitet, §141 eigenständig ab 600.000 EUR Umsatz oder 60.000 EUR Gewinn) und die zentrale Datenquelle der elektronischen Bilanz nach §5b EStG. Vier Rechtsquellen wirken parallel: das HGB (§§238-263a für Buchführung, §250 für Abgrenzung, §253 für Bewertung, §289 für IKS), die AO (§§140-148 für Buchführungspflicht, §158 für Beweiskraft, §162 für Schätzung), die GoBD 2025 (BMF-Schreiben 14.11.2014, ergänzt 28.11.2019, fortgeschrieben 2025) und die internationalen Prüfungsstandards (ISA 240 Fraud Risk, IDW PS 951 Auftragsabwicklung, IDW RS HFA 5/26 Bewertung). Hinzu kommen DATEV-Standardkontenrahmen (SKR03 für Industrie/Handel/Handwerk, SKR04 für HGB-Bilanzgliederung, SKR14 für Land- und Forstwirtschaft) und die DSFinV-K-Schnittstelle für bargeldintensive Branchen. Eine fehlende Festschreibung, ein nicht maschinell auswertbarer Beleg oder eine Lücke in der Vier-Augen-Funktionstrennung kostet in der Außenprüfung schnell sechsstellige Steuernachforderungen, dazu 6 Prozent AO-Zinsen.

## Buchführungsmängel führen zur Schätzung nach §162 AO - Hinzuschätzung 5-15% führt bei Mittelständlern schnell zu sechsstelligen Steuernachforderungen

Die Buchführung gilt nach AO §158 als beweiskräftig, sofern sie formell und sachlich GoBD-konform ist. Diese Beweiskraft ist die zentrale Grundlage für die steuerliche Anerkennung des Bilanzergebnisses. Erkennt das Finanzamt in der Außenprüfung wesentliche Mängel - fehlende Festschreibung nach AO §146 Abs. 4, lückenhafte Belegkette, fehlende Verfahrensdokumentation, manipulationsverdächtige Datenstrukturen, mangelhafte Vier-Augen-Funktionstrennung -, verwirft es die Beweiskraft und greift zu §162 AO Schätzung der Besteuerungsgrundlagen. Die Hinzuschätzung wird in der Außenprüfungspraxis nach Mängeltyp gestaffelt: bei kleineren formellen Mängeln 1-5%, bei wesentlichen Verstößen (fehlende Verfahrensdokumentation, lückenhafte Belegkette, manipulierbare Daten) 5-15%, bei schwerem Verstoß (Manipulationssoftware nach §146a AO, dokumentierte Schwarzeinkäufe, fehlende DSFinV-K-Daten) bis zu 25-50%.

Bei einem Industrie-Mittelständler mit 50 Mio EUR Bilanzsumme und 5 Mio EUR handelsrechtlichem Jahresergebnis bedeuten 10% Hinzuschätzung auf das Steuerergebnis 500 TEUR Mehrgewinn, was bei 30% Gesamtsteuerbelastung (Körperschaftsteuer 15%, Gewerbesteuer 14-17% je Hebesatz, Solidaritätszuschlag 5,5% auf KSt) etwa 150 TEUR Mehrsteuer ergibt. Hinzu kommen 6% AO-Zinsen nach §238 AO ab 15 Monaten nach Veranlagungsjahr - bei einem typischen 4-Jahres-Außenprüfungszeitraum kumulieren sich rund 36 TEUR Zinsen. Bei wiederholten Mängeln greifen zusätzlich §379 AO (Steuergefährdung bis 5.000 EUR pro Verstoß), §378 AO (leichtfertige Steuerverkürzung bis 50.000 EUR), in extremen Fällen §370 AO Steuerhinterziehung mit Freiheitsstrafe bis 10 Jahre. Hinzu kommen das Reputationsrisiko bei der Bonitätseinschätzung durch Banken (Basel III erfordert Außenprüfungsbericht für Kreditkonditionen) und die persönliche Haftung der Geschäftsführer nach GmbHG §43 bzw. AktG §93.

## Die deutsche Buchungspipeline durchläuft 13 deterministische Schritte

Anders als die brasilianische Buchungspipeline mit 8 Schritten oder die spanische mit 10 Schritten erfordert das deutsche Buchungsverfahren 13 deterministische Entscheidungen, weil das Zusammenspiel aus HGB-Bilanzrecht, AO-Steuerrecht, GoBD-Aufzeichnungspflichten, DATEV-Kontenrahmen-Logik und §5b EStG E-Bilanz-Taxonomie deutlich mehr Verzweigungen erzeugt: Belegart und Buchungskreis bestimmen, Pattern-Match gegen 12-Monats-Historie, DATEV-Kontenrahmen SKR03/SKR04/SKR14 mappen, Rechnungsabgrenzung HGB §250 berechnen, planmäßige AfA §7 EStG gegenrechnen, Rückstellungen IDW RS HFA 5/26 bewerten, außerordentlichen Posten klassifizieren, Buchungssatz mit Konto/Gegenkonto/Kostenstelle generieren, GoBD-Plausibilitätsprüfung gegen Verfahrensdokumentation, Vier-Augen-Freigabe nach IDW PS 951, Unveränderbarkeit nach AO §146 Abs. 4 sichern, E-Bilanz-Taxonomie §5b EStG mappen und IDEA-konforme Archivierung sicherstellen.

Ein konkretes Szenario: Maschinenbau-Mittelständler mit 1.200 monatlichen Buchungen, 50 Mio EUR Bilanzsumme, DATEV SKR04 als Mandanten-Kontenrahmen. An einem Werktag identifiziert der Agent 940 Buchungen als wiederkehrend mit Pattern-Match gegen die letzten 12 Monate (78%), mappt sie gegen die SKR04-Sachkonten, berechnet 78 Abgrenzungsbuchungen nach HGB §250 (Mietvorauszahlungen, Versicherungsprämien, Wartungsverträge), bucht die monatliche AfA für 340 Anlagegüter laut BMF-AfA-Tabelle und prüft 23 Standard-Pauschalrückstellungen (Urlaub, Überstunden, Garantie). Es bleiben 159 Buchungen für manuelle Bearbeitung: 8 außerordentliche Posten, 12 Einzelrückstellungen mit Neubewertung, 24 Konzernumbuchungen mit Intercompany-Abstimmung, 11 Korrekturbuchungen aus dem Vormonat und 104 Sonderbelege ohne historisches Muster. Die Vier-Augen-Freigabe nach IDW PS 951 wird automatisch in 824 Fällen ohne Eskalation durchgeführt (Erfasser+fachlicher Prüfer+formaler Freigeber je separate Person), in 376 Fällen mit Eskalation an die Hauptbuchverantwortung wegen Volumen >10 TEUR oder kritischer Buchungsart. Nach Festschreibung gehen alle 1.200 Buchungen in das IDEA-Z3-Archiv für 10-Jahres-Aufbewahrung.

Im [Decision Layer](/de/decision-layer/) sind 11 der 13 Schritte regelbasierte Entscheidungen (Stufe R), 1 Schritt KI-Pattern-Recognition (Stufe A für wiederkehrende Buchungen) und 2 Schritte menschliche Ermessensentscheidung (Stufe H für Rückstellungs-Neubewertung und außerordentliche Klassifikation). Die Trennung ist vor dem Wirtschaftsprüfer transparent: ISA 240 verlangt explizit die Differenzierung zwischen automatisierten und manuellen Journal Entries - der Agent liefert diese Differenzierung als Decision Log mit Stufenkennzeichnung je Buchung.

## Vier-Augen-Freigabe nach IDW PS 951 wird durch Automatisierung skalierbar

ISA 240 stuft manuelle Journal Entries als primäres Fraud-Risk-Vehikel in der Abschlussprüfung ein. Der Wirtschaftsprüfer fordert gezielt: ungewöhnliche Buchungen außerhalb der Geschäftszeiten, Buchungen kurz vor Periodenende mit hohem Volumen, Buchungen mit ungewöhnlichen Kontokombinationen (z.B. Aufwand gegen Eigenkapital), Buchungen großer Volumina ohne zugeordnete Belegnummer, Buchungen mit identischem Erfasser und Freigeber. In der manuellen Welt scheitert die Vier-Augen-Prüfung an der Praxis - bei 1.200 monatlichen Buchungen und einem 5-Tages-Closing-Fenster ist die zweite Prüfung der Flaschenhals.

Der Agent verändert diese Dynamik. Routinebuchungen kommen vorbereitet und vollständig dokumentiert beim fachlichen Prüfer und formalen Freigeber an - die Prüflast pro Buchung sinkt drastisch, weil Berechnung, Kontenrahmen-Mapping und GoBD-Plausibilität bereits validiert sind. Der Freigeber prüft die kaufmännische Plausibilität, der Decision Layer protokolliert Erfasser, fachlichen Prüfer und formalen Freigeber separat mit Zeitstempeln und Funktionsbezeichnungen. Bei kritischen Buchungsarten (außerordentliche Posten, Rückstellungs-Neubildungen, Konzernumbuchungen, Korrekturen aus Vorperioden) greift Eskalation an die Hauptbuchverantwortung oder den CFO mit zusätzlichem Approval-Layer.

## Edge-Cases SKR14, DSFinV-K und §5b EStG E-Bilanz erfordern Branchen-Spezialwissen

Land- und forstwirtschaftliche Mandanten nutzen SKR14 als DATEV-Kontenrahmen mit branchenspezifischen Konten für Tierbestände, Pflanzenkulturen und EU-Direktzahlungen. Der Agent erkennt diese Spezial-Kontoklassen automatisch und mappt sie gegen die spezielle E-Bilanz-Taxonomie für Land- und Forstwirtschaft. Bargeldintensive Branchen (Einzelhandel, Gastronomie, Friseure) müssen seit 1.1.2020 die DSFinV-K-Schnittstelle bedienen mit Einzelaufzeichnungspflicht jedes Kassiervorgangs nach §146a AO. Der Agent integriert die DSFinV-K-Daten in den Hauptbuch-Workflow und validiert jede Kasseneinzelaufzeichnung gegen den Tagesumsatz-Buchungssatz - Differenzen führen zur manuellen Klärung vor Festschreibung. Bei der Kassen-Nachschau §146b AO (unangekündigte Vor-Ort-Prüfung) liefert der Agent binnen Minuten den DSFinV-K-Export für den Prüfungszeitraum.

Die E-Bilanz-Übermittlung nach §5b EStG erfolgt einmal jährlich an ELSTER mit der amtlichen Kerntaxonomie (aktuell Version 6.7 für Wirtschaftsjahre 2025/2026). Der Agent prüft alle Mussfelder vor Übertragung: Eigenkapital-Untergliederung (Stammkapital, Kapitalrücklage, Gewinnrücklage, Bilanzgewinn), Vorzeichen bei GuV-Aufwandsposten, Branchen-Spezialtaxonomie bei regulierten Branchen (Banken, Versicherungen, Land- und Forstwirtschaft), Konsistenz Bilanzsumme Aktiva/Passiva und Anhangs-Taxonomie bei Kapitalgesellschaften nach HGB §284-288. Bei fehlenden Mussfeldern blockiert der Agent die Übertragung und meldet den Klärungsbedarf an den Bilanzbuchhalter. Wiederholte Übertragungsversagungen führen zu Schätzungsbescheiden nach §162 AO und Zwangsgeld nach §329 AO bis 25.000 EUR pro Versagung.

## Integration mit DATEV, SAP, Microsoft, BZSt und IDEA schließt die Compliance-Kette

Die Logik des Agents verbindet sich mit den führenden deutschen Finanzsystemen via API: [DATEV](https://www.datev.de/) (dominanter Marktanteil bei Steuerberatern und Mittelstand-Buchhaltung mit SKR03/SKR04/SKR14, DATEVconnect-Schnittstelle, Eigenorganisation und Kanzlei-Rechnungswesen pro), SAP S/4HANA FI-GL (Hauptbuch mit Belegart-Konfiguration, Recurring-Entry-Workflows, Audit Information System AIS für Außenprüfung), Microsoft Dynamics 365 Business Central (Mittelstand-Buchhaltung mit wiederkehrenden Buchungsblättern), Sage 100 mit DATEV-Schnittstelle, Diamant/4 mit Konzernkonsolidierung, Lexware Buchhaltung Pro für KMU, Addison OneClick für Steuerberater-Cloud. Die E-Bilanz-Übermittlung läuft über das ELSTER-Portal des [Bundeszentralamts für Steuern](https://www.bzst.de/) mit aktueller Taxonomie-Version. Die Außenprüfungs-Schnittstelle erfolgt über IDEA (BMF-Standardprüfsoftware) mit Z3-Datenträgerüberlassung nach AO §147 Abs. 6. Für Konzerne mit ausländischen Tochtergesellschaften (DAX/MDAX-Mittelstand, Volkswagen, Bosch, Siemens-Töchter) erzeugt der Agent parallele IFRS-Reportings für die Konzernkonsolidierung - das deutsche Verfahren bleibt HGB- und GoBD-konform, das Konzern-Reporting erfüllt zugleich IFRS 9, IFRS 15 und IFRS 16 für die internationale Konsolidierung.

--- Lease-Accounting-Agent ---
> Klassifiziert Leasing nach HGB (Operating/Finance) und IFRS 16 (ROU+Liability), leitet IBR ab und prüft wirtschaftliches Eigentum nach §39 AO - Cert-Ready für DPR und IDW RS HFA 13 plus PS 951.

Leasingbilanzierung in Deutschland steht zwischen drei Standardsystemen mit ganz unterschiedlichen Ergebnissen. Das HGB folgt im Einzelabschluss weiterhin der Operating-versus-Finance-Klassifikation nach IDW RS HFA 13 - mit Aufwandsbuchung beim Operating-Leasing und Aktivierung beim Finance-Leasing. IFRS 16 verlangt für kapitalmarktorientierte Konzernabschlüsse für alle Leasingverhältnisse ein Right-of-Use-Asset und eine Lease-Liability. Und die steuerliche Würdigung folgt §39 AO mit dem BMF-Schreiben vom 19.04.1971 zur Zurechnung des wirtschaftlichen Eigentums. Damit kann ein einziger Leasingvertrag in einem deutschen Konzern bis zu drei verschiedene Bilanzwirkungen entfalten.

## Eine DPR-Fehlerfeststellung kostet 3 bis 8 Prozent des Aktienkurses - BFH IV R 14/17 setzt den Maßstab

Die DPR-Bilanzkontrolle nach WpHG §114-117 hat 2024 Leasingbilanzierung als Prüfschwerpunkt definiert. 38 Prozent der HDAX-Stichproben zeigten Beanstandungen - typische Findings sind unzureichende IBR-Dokumentation ohne Treasury-Backup, fehlende CPI-Remeasurement bei indexierten Immobilienverträgen, fehlerhafte Klassifikation Service-Komponenten als Lease-Komponenten, unvollständige IFRS 16.51-60 Disclosures. Die BaFin-Verfügung führt zur Erkenntnisbekanntmachung im Bundesanzeiger; der Aktienkurs reagiert typisch mit 3 bis 8 Prozent Rückgang in den drei Handelstagen nach der Veröffentlichung.

Steuerlich verschärft die Außenprüfung das Risiko: BFH IV R 14/17 hat 2018 zur Vollamortisationsprüfung präzisiert, dass die Relation von Grundmietzeit zu Nutzungsdauer zusammen mit der Amortisationsquote den wirtschaftlichen Eigentümer bestimmt. Eine fehlerhafte Klassifikation bedeutet den Verlust der Leasingraten-Absetzung und eine nachgelagerte AfA-Korrektur über mehrere Jahre. Bei Sale-and-Leaseback präzisiert BFH I R 56/17, dass die wirtschaftliche Betrachtung den zivilrechtlichen Eigentumsübergang überlagert.

## Die 15 deterministischen Entscheidungspunkte mit drei menschlichen Eskalationen

Der Agent verarbeitet jeden Leasingvertrag in 15 strukturierten Entscheidungspunkten: zwölf regelbasierte Klassifikationen, eine LLM-gestützte Vertragsextraktion und drei menschliche Eskalationen für die Beurteilung von Leasingdauer, IBR-Ableitung und Sale-and-Leaseback. Die Vertragserkennung extrahiert per LLM die strukturellen Merkmale - identifizierter Vermögenswert, Substitutionsrecht, Nutzungsdauer und substanzielle Nutzung. Die regelbasierten Klassifikationen folgen IDW RS HFA 13 (Tz. 13-21) für das HGB sowie IFRS 16.9 bis B33 und §39 AO mit den BMF-Vollamortisations-Kriterien.

Ein konkretes Beispiel: Ein HDAX-Konzern erhält einen Immobilien-Leasingvertrag über 15 Jahre mit jährlicher CPI-Indexierung, zwei Verlängerungsoptionen über je fünf Jahre und einem Mietniveau von 87 Prozent des Marktniveaus. Der Agent klassifiziert: nach HGB Operating-Leasing (keiner der vier Indikatoren erfüllt), nach IFRS 16 ein Right-of-Use-Asset und eine Lease-Liability über 15 Jahre Grundlaufzeit, in der Steuerbilanz Leasinggeber-Eigentum (Vollamortisation in 15 Jahren nicht erreicht). Der IBR wird aus der Treasury-Kurve für eine 15-jährige besicherte Refinanzierung mit Bonitätsrating BBB und 80 Basispunkten Liquiditätsprämie abgeleitet; das Treasury-Memo ist GoBD-archiviert. Das CPI-Remeasurement erfolgt jährlich.

## DRS 14 und IFRS 16.51-60 als Prüfungsschwerpunkt der Big Four

Das Substantive Testing der Big Four nach PCAOB AS 2110 und AICPA AU-C 540 konzentriert sich bei der Leasing-Bilanzierung auf vier Bereiche: die Treasury-konforme IBR-Dokumentation mit Quelle des Bonitätsratings (ein DPR-Top-Finding), die Vollständigkeit des CPI-Remeasurements bei jeder Indexierung mit korrektem Diskontierungssatz, die Sale-and-Leaseback-Würdigung des Kontrollübergangs nach IFRS 15.31-37 und die Vollständigkeit der Disclosures nach IFRS 16.51-60 und DRS 14. Der Agent erzeugt die Disclosures automatisiert: die Reife-Analyse der Lease-Liability nach Fälligkeitsbändern, den Aufwand für variable Leasingzahlungen, den Aufwand für kurzfristige und Low-Value-Leasings, die Cashflows aus Leasing nach IAS 7, die ROU-Aufschlüsselung nach Asset-Klassen (Immobilien, Maschinen, Fahrzeuge, IT-Equipment) sowie die qualitative Beschreibung von Verlängerungsoptionen, Restwertgarantien und Sub-Leases.

## Edge-Cases: Sale-and-Leaseback, Sub-Leases, Restwertgarantien und Konzern-interne Vermietung

Sale-and-Leaseback ist nach BFH I R 56/17 die komplexeste Konstellation der deutschen Leasingbilanzierung. Der Verkäufer-Leasingnehmer veräußert ein Wirtschaftsgut und mietet es im selben Vertrag oder zeitnah zurück - die wirtschaftliche Betrachtung nach §39 AO überlagert die zivilrechtliche Eigentumsübertragung. Ist der Kontrollübergang nach IFRS 15.31-37 nicht gegeben (etwa bei Rückkaufoptionen oder garantierten Restwerten zum Marktpreis), liegt ein Failed Sale vor und die Transaktion wird als reine Finanzierung gebucht: Das Wirtschaftsgut bleibt aktiviert, der Verkaufserlös wird als Verbindlichkeit gegenüber dem Käufer-Leasinggeber passiviert. Der Agent prüft das algorithmisch gegen die IFRS-15-Kriterien und eskaliert Grenzfälle an den Wirtschaftsprüfer.

Sub-Leases und konzerninterne Vermietung sind weitere Sonderfälle: Ein Mutterunternehmen mietet eine Immobilie über 15 Jahre und vermietet sie anteilig an Tochtergesellschaften weiter. Im Konzernabschluss eliminieren sich die ROU-Assets und Lease-Liabilities aus konzerninternen Sub-Leases, im Einzelabschluss bleiben sie bestehen. Restwertgarantien des Leasingnehmers (Garantie eines Mindesterlöses am Vertragsende) erhöhen die Lease-Liability um den erwarteten Garantiebetrag, mit jährlicher Schätzung und Anpassung. CPI-indexierte Zahlungen lösen ein jährliches Remeasurement aus, während performance-abhängige Zahlungen (etwa ein Mietanteil am Umsatz eines Einzelhändlers) GuV-Aufwand bleiben.

## Integration mit DATEV, SAP S/4HANA RE-FX, Lucanet und der deutschen Konzernkonsolidierungs-Architektur

Der Agent bindet die führenden deutschen Konsolidierungssysteme über deren APIs an: die DATEV-Konzern-Konsolidierung mit Anlagenbuchführung als HGB-Engine, SAP S/4HANA Lease Administration (LSAS) und RE-FX mit voller IFRS-16-Integration, die Lucanet-Konzernkonsolidierung mit Lucanet Lease Accounting, Microsoft Dynamics 365 Finance Lease Management und IDL Konsis. Die Pflicht-Veröffentlichung im Bundesanzeiger erfolgt über API, bei kapitalmarktorientierten Unternehmen das ESEF-XBRL-Tagging über die BaFin-Hinterlegungsstelle. Die Steuerbilanz-Schnittstelle zu DATEV LODAS und SAP TaxBox arbeitet GoBD-konform. Das Substantive Testing der Big Four wird über den Datenexport an Deloitte ASM, PwC Halo for Leases, EY Helix und KPMG Clara mit PCAOB-AS-1215-Audit-Trail-Metadaten unterstützt.

--- Management-Reporting-Agent ---
> Berechnet EBITDA, Working Capital, DSO, DPO und weitere KPIs, konsolidiert Daten aus verschiedenen Quellen.

Finance-Teams verbringen laut aktuellen Erhebungen rund 300 Stunden pro Jahr mit manueller Reporting-Arbeit - Zeit, die weder in Analyse noch in Entscheidungsvorbereitung fließt (Quelle: Float Financial, 2025). Der Engpass im Management Reporting liegt nicht in der Interpretation von Kennzahlen. Er liegt in der Konsolidierung, die jeder Interpretation vorausgeht.

## Konsolidierung verschlingt die Zeit, die für Analyse fehlt

Ein typischer Monatsabschluss im gehobenen Mittelstand dauert sechs bis zehn Werktage. Danach beginnt die eigentliche Arbeit des Controllers: Daten aus FiBu, Controlling, Treasury und operativen Systemen zusammenführen, Eliminierungen durchführen, KPIs berechnen, Vormonats- und Vorjahresvergleiche aufbauen. Erst wenn diese Grundlage steht, kann das CFO-Cockpit aktualisiert werden.

In der Praxis bedeutet das: Die Zahlen sind am 5. Werktag technisch korrekt - aber das Board-Deck liegt erst am 8. oder 9. vor. Nicht weil die Analyse komplex wäre, sondern weil drei Tage in der manuellen Zusammenführung von Excel-Exporten, ERP-Abzügen und Controlling-Berichten verschwinden. Jeder Reporting-Zyklus wiederholt denselben Aufwand, weil die Konsolidierungslogik nirgendwo als wiederverwendbarer Prozess existiert.

## Regelbasierte KPI-Berechnung verkürzt den Zyklus um Tage

EBITDA, Working Capital, DSO, DPO und Cash Conversion Cycle folgen definierten Formeln. Es gibt keinen Interpretationsspielraum bei der Frage, wie DSO berechnet wird - nur bei der Frage, was ein steigender DSO für das Geschäft bedeutet. Genau hier setzt der [Decision Layer](/de/decision-layer/) an.

Der Management-Reporting-Agent übernimmt die erste Kategorie vollständig: Er bezieht die konsolidierten Werte aus FiBu und Controlling, wendet die hinterlegten Berechnungsformeln an und aktualisiert das Dashboard automatisch, sobald der Monatsabschluss als vollständig markiert ist. Die Datenquelle, die angewandte Formel und das Ergebnis werden für jeden KPI dokumentiert - reproduzierbar und auditfähig.

Unternehmen, die ihre Konsolidierung automatisieren, berichten von einer Reduktion des Close-to-Report-Zyklus um 50 Prozent (Quelle: Deloitte CFO Signals Survey, H4 2025). Aus acht Tagen werden vier. Aus einem reaktiven Reporting-Prozess wird ein Rhythmus, auf den sich das Board verlassen kann.

## Anomalie-Erkennung macht Reporting proaktiv statt reaktiv

Die wertvollste Information in einem Monatsbericht ist nicht die Bestätigung, dass alles im Plan liegt. Es ist die frühzeitige Identifikation von Abweichungen, bevor sie im nächsten Quartalsbericht erklärungsbedürftig werden.

Der Agent vergleicht jeden berechneten KPI mit historischen Bandbreiten und statistischen Erwartungswerten. Wenn die DSO um 12 Tage steigt oder das Working Capital einen Sprung zeigt, der außerhalb der saisonalen Norm liegt, wird das markiert - nicht als Alarm, sondern als Kommentierungsvorschlag mit Kontextdaten. Der Controller erhält einen Entwurf, der die Anomalie benennt, den historischen Verlauf einordnet und mögliche Ursachen aus den Quelldaten ableitet.

Das verändert die Rolle des Controllers fundamental: Statt Zahlen zu suchen, die erklärungsbedürftig sein könnten, startet er mit einer priorisierten Liste und investiert seine Zeit in die Ursachenanalyse.

## Das strategische Narrativ bleibt beim CFO

Was ein steigender Cash Conversion Cycle für die Lieferantenverhandlungen im nächsten Quartal bedeutet, welche KPI-Entwicklung im Lagebericht nach HGB 289 besondere Erläuterung erfordert, wie die Zahlen gegenüber dem Aufsichtsrat gemäß DCGK eingeordnet werden - das sind Entscheidungen, die Geschäftskenntnis, Branchenerfahrung und strategisches Urteil voraussetzen.

Der Decision Layer zieht hier eine klare Grenze. Sieben der acht Entscheidungsschritte im Reporting-Prozess laufen regelbasiert oder KI-gestützt. Der achte - die strategische Interpretation - bleibt beim Menschen. Nicht als Zugeständnis, sondern als architektonische Entscheidung: Ein CFO, der sein Board-Deck aus einem vorbereiteten Entwurf mit dokumentierten KPIs und markierten Anomalien aufbaut, trifft bessere Entscheidungen als einer, der die erste Hälfte seiner Zeit mit Datenkonsolidierung verbringt.

## Das konsolidierte Board-Deck steht am 3. statt am 8. Werktag

Ein konkretes Szenario: Ein Industrieunternehmen mit vier Geschäftsbereichen, konsolidiertem Reporting an die Holding und monatlichem Board-Meeting am 10. Werktag. Vor der Automatisierung lag das fertige Board-Deck frühestens am 8. Werktag vor - mit regelmäßigen Nachkorrekturen bis zum Vorabend der Sitzung.

Nach Einführung des Management-Reporting-Agenten stehen die konsolidierten KPIs am 3. Werktag zur Verfügung. Anomalien sind markiert und vorkommentiert. Der Head of Controlling verwendet den 4. und 5. Werktag für die strategische Einordnung und das Narrativ - nicht für die Konsolidierung. Am 6. Werktag geht das Deck an den CFO. Vier Tage Puffer statt zwei Tage Druck.

Der Unterschied liegt nicht in der Qualität der Formeln. Er liegt darin, dass die repetitive Arbeit dort stattfindet, wo sie hingehört - in einem dokumentierten, reproduzierbaren Prozess. Und die analytische Arbeit dort, wo sie Wirkung entfaltet - beim Menschen mit Entscheidungskompetenz.

--- Zahlungslauf-Agent ---
> Selektiert fällige Rechnungen, optimiert Skonto, generiert SEPA-XML (PAIN.001) und prüft Sanktionslisten nach §16 GwG vor der EBICS-Übertragung.

Ein Zahlungslauf berührt in Deutschland gleich vier Rechtskreise zugleich. Handelsrechtlich ist er ein aufzeichnungspflichtiger Geschäftsvorfall, aufsichtsrechtlich unterliegt er der BaFin nach ZAG und PSD2 sowie der Bundesbank, zivilrechtlich gelten die Regeln zu Erfüllung und Verzug, und geldwäscherechtlich greifen die Sorgfaltspflichten mit Sanktionslistenabgleich. Hinzu kommen die technischen Standards des SEPA-Zahlungsverkehrs - das ISO-20022-Format, das EBICS-Verfahren mit verteilter Unterschrift und die DATEV-Banking-Container für Steuerberatungs-Mandate. Eine fehlende Sanktionsprüfung, eine nicht erkannte Doppelzahlung oder eine Lücke in der Funktionstrennung kostet schnell siebenstellige Beträge und kann die Geschäftsführung persönlich haftbar machen.

## Ein manueller Zahlungslauf kann siebenstellige Folgekosten verursachen

Vier Schadensquellen wirken parallel und summieren sich bei mittelständischen Industrieunternehmen schnell zu siebenstelligen Beträgen pro Geschäftsjahr. Erstens drohen bei wiederholten Sorgfaltspflichtverletzungen BaFin-Strafgelder bis 5 Mio Euro oder 10 Prozent des Konzernumsatzes, dazu die persönliche Verantwortung der Geschäftsleitung. Zweitens betragen die Verzugszinsen bei B2B-Geschäften 9 Prozentpunkte über dem Basiszins, derzeit also rund 12,6 Prozent pro Jahr, zuzüglich 40 Euro Mahnpauschale je Rechnung. Drittens bleibt Liquidität ungenutzt: Ein Cash-Pooling über mehrere Banken hebt bei einem Konzern mit 15 Tochtergesellschaften und je 5 Mio Euro Kontensaldo 50 bis 75 Mio Euro Puffer aus den dezentralen Konten in das Hauptkonto und senkt so die Kontokorrent-Inanspruchnahme.

Viertens und am direktesten messbar: Skonto-Verluste bei Zahlung außerhalb der Skontofrist. Bei einem typischen Skontoangebot von 2% bei Zahlung innerhalb 14 Tagen gegenüber 30 Tagen Nettoziel entspricht der Skontoabzug einer annualisierten Rendite von 36% p.a. (2% / 16 Tage Differenz * 360 Tage). Bei 3% Skonto (häufig im Maschinenbau und in der Chemie) liegen 54% p.a. Rendite. Ein Industriezulieferer mit 100 Mio EUR jährlichem Bezugsvolumen und 80% Skonto-fähigen Lieferantenkonditionen verschenkt bei einer Skonto-Ausnutzung von 55% gegen 92% jährlich rund 740 TEUR Skonto-Mehrertrag. Plus die Folgewirkung auf die Lieferanten-Bonitätseinstufung (Schufa-B2B-Score und Creditreform-Bonitätsindex), die schlechte Zahlungsmoral mit Aufschlägen auf Lieferantenpreise und gekürzten Lieferfristen quittiert.

## Der deutsche Zahlungslauf besteht aus 14 festen Schritten

Das deutsche Zahlungsverfahren erfordert 14 Entscheidungen - deutlich mehr als das spanische mit 11 oder das brasilianische mit 9 Schritten -, weil Schuldrecht, Steuerrecht, Geldwäsche-Sorgfaltspflichten, PSD2-Aufsicht und die SEPA-Instant-Pflicht zusammenwirken. Die Kette reicht von der Fälligkeitsauswahl und Skonto-Optimierung über die Sanktionsprüfung, die Identifizierung des Empfängers und die Wahl der Zahlungsart bis zur Doppelzahlungs-Prüfung, der SEPA-Datei-Erzeugung, der Vier-Augen-Freigabe, der Statusverarbeitung und der revisionssicheren Archivierung.

Ein konkretes Szenario: Maschinenbau-Mittelständler mit 500 wöchentlichen Eingangsrechnungen, 100 Mio EUR Bezugsvolumen jährlich, DATEV ZahlungsModul über die Steuerberatungs-Kanzlei und EBICS-T-Anbindung an Sparkasse und Commerzbank. An einem Werktag selektiert der Agent 312 fällige Rechnungen mit Skontofrist binnen 24 Stunden (Subset von 500 Eingangsrechnungen mit unterschiedlichen Zahlungszielen), prüft alle 312 Empfänger gegen drei EU-Sanktionsregime (Trefferquote typisch 0,1-0,5% mit Klärungspflicht), gruppiert sie nach Auftraggeber-IBAN in 4 Sammelüberweisungen für die zwei Hausbanken, generiert 4 PAIN.001-Dateien mit Schemavalidierung, lädt sie via EBICS T hoch und löst die VEU-Mitzeichnung des Treasurers aus. Nach Mitzeichnung erfolgt die Bankübertragung mit PAIN.002-Statusreport binnen Minuten - typisch 5-15 RJCT-Positionen mit Reason-Codes (AC01 IncorrectAccountNumber, AM04 InsufficientFunds bei Tochter-Konten, BE05 UnrecognizedInitiatingParty bei neuen Bankverbindungen) gehen in den Korrektur-Workflow. CAMT.053-Buchungsbestätigung kommt am Folgetag und schließt die Erfüllungsleistung nach BGB §362 ab.

Im [Decision Layer](/de/decision-layer/) sind 13 der 14 Schritte regelbasierte Entscheidungen (Stufe R), 1 Schritt menschliche Ermessensentscheidung (Stufe H für Vier-Augen-Freigabe). Die Trennung ist vor BAFin und Wirtschaftsprüfer transparent: ISA 240 verlangt explizit die Differenzierung zwischen automatisierten und manuellen Zahlungsfreigaben - der Agent liefert diese Differenzierung als Decision Log mit Stufenkennzeichnung je Position.

## SEPA Instant Credit Transfer wird ab Oktober 2025 verpflichtend - Agent steuert das Routing

EU-Verordnung 2024/886 vom März 2024 hat die SEPA-Instant-Verpflichtung für alle Eurozone-Banken festgeschrieben: ab 9. Januar 2025 Pflicht zur Annahme von SCT Inst, ab 9. Oktober 2025 Pflicht zum Versand mit Verification of Payee (VOP). Verification of Payee bedeutet: vor Buchung gleicht die Bank Empfänger-Name aus dem PAIN.001-Auftrag mit dem Kontoinhaber-Namen bei der Empfängerbank ab. Bei Match keine Auswirkung; bei Close-Match (z.B. Tippfehler) Warnung an den Auftraggeber; bei No-Match deutliche Warnung mit Bestätigungspflicht. Dies eliminiert eine Hauptquelle von Betrugszahlungen (CEO-Fraud mit gefälschter Banking-Mail), in dem die Manipulation der IBAN bei korrektem Empfängernamen vor Buchung erkannt wird.

Der Agent steuert das SCT/SCT-Inst-Routing nach drei Kriterien: erstens Empfängerbank-Teilnahme (EBA Clearing RT1-Liste oder Bundesbank TIPS-Liste der teilnehmenden Banken), zweitens Skonto-Frist (binnen 24 Stunden ablaufende Skontofrist erzwingt SCT Inst für sicheren Eingang am selben Tag), drittens Auftrags-Limit (aktuell 100.000 EUR pro SCT-Inst-Transaktion, höhere Beträge müssen in Tranchen oder als SCT mit T+1-Werttagung). Bei Drittland-Empfängern (z.B. Schweiz, UK, USA) erfolgt SWIFT MT103 mit Bundesbank Z4-Meldung nach AWV §67 ab 12.500 EUR Schwellwert.

## Edge-Cases Sanktionsprüfung, Konzern-Cash-Pooling und Außenwirtschaftsmeldung

Konzerne mit Tochtergesellschaften in EU-Drittländern (Türkei, Schweiz, UK, Russland-Tochter mit eingeschränkten Zahlungen nach VO 833/2014) erfordern parallele Sanktionslisten-Logik mit Embargo-spezifischen Regelwerken: Russland-Embargo erlaubt Zahlungen für humanitäre Güter und für vor Sanktionsbeginn geschlossene Verträge, bei Zahlung an sanktionierte Personen oder für sanktionierte Sektorgüter (Energie, Hochtechnologie, Finanzen) greift Zahlungsverbot. Der Agent klassifiziert jeden Empfänger nach EU-Sanktions-Datenbank und löst bei Verdachtsfall Verdachtsmeldung an FIU (Financial Intelligence Unit beim Zollkriminalamt Köln) nach §43 GwG aus - die Verdachtsmeldung ist binnen 24 Stunden zu erstatten.

Konzern-Cash-Pooling über DATEV TopBank, SAP Bank Communication Management oder spezialisierte Treasury-Software (Coupa Treasury, Kyriba, ION Treasury) erfordert vor jedem externen Zahlungslauf einen internen Liquidity Sweep aus den Sub-Accounts der Tochtergesellschaften zum Master-Konto der Mutter. Der Agent berechnet die Liquidity-Sweep-Bewegung nach Treasury-Regelwerk (Cash Concentration Modus, Notional Pooling oder Zero Balancing), führt die internen Buchungen als CAMT.054-Bewegungen aus, dokumentiert die Intercompany-Forderungen nach IDW RS HFA 38 und löst dann die externe SEPA-Zahlung aus. Bei Auslandszahlungen über 12.500 EUR greift parallel die Bundesbank-Außenwirtschaftsstatistik mit Z4-Meldepflicht nach AWV §67 - der Agent generiert die Z4-Meldung automatisch mit Verwendungszweck-Kennzeichnung (Warenhandel, Dienstleistung, Kapitalverkehr) und übermittelt sie via Bundesbank-AWV-Portal innerhalb der 7-Tage-Frist nach Wertstellung.

## Integration mit DATEV, SAP, Subsembly, Bundesbank und FIU schließt die Compliance-Kette

Die Logik des Agents verbindet sich mit den führenden deutschen Banking- und Treasury-Systemen via API: [DATEV](https://www.datev.de/) ZahlungsModul (dominanter Marktanteil bei Steuerberatern und Mittelstand-Buchhaltung mit DATEV-Banking-Container 3.7, EBICS T und H), DATEV TopBank (Cash-Pooling-Drehscheibe für Mehr-Banken-Konstellation), SAP S/4HANA FI-AP mit Bank Communication Management (BCM) für Konzerne mit SWIFT FIN und EBICS, Microsoft Dynamics 365 Business Central mit Bank Account Reconciliation, Sage 100 mit SEPA-Banking-Modul, Diamant/4 mit Treasury für Konzern-Cash-Pooling, Lexware Zahlungsverkehr Pro für KMU mit GoBD-zertifizierter SEPA-Generierung, Wallix BankWizard und Subsembly Banking-Komponenten als EBICS-Middleware für individuelle ERP-Anbindung, ProfiCash der VR-Banken und Hibiscus Banking. Die Sanktionslisten-Datenbanken laufen über zertifizierte Provider (Dow Jones Risk Center, LexisNexis World-Check, Refinitiv World-Check) mit täglicher Aktualisierung. Die FIU-Verdachtsmeldungen erfolgen über das goAML-Portal beim Zollkriminalamt Köln. Die Bundesbank-Außenwirtschaftsmeldungen Z4 laufen über das Bundesbank-AWV-Portal. Die Außenprüfungs-Schnittstelle erfolgt über IDEA (BMF-Standardprüfsoftware) mit Z3-Datenträgerüberlassung nach AO §147 Abs. 6. Für DAX/MDAX-Konzerne und gehobenen Mittelstand mit ausländischen Tochtergesellschaften erzeugt der Agent parallele IFRS-Reportings - das deutsche Verfahren bleibt HGB-, GwG- und ZAG-konform, das Konzern-Reporting erfüllt zugleich IAS 7 (Cashflow Statement) und IFRS 9 (Financial Instruments) für die internationale Konsolidierung.

--- Zahlungsverkehr-Agent ---
> Bestimmt das Zahlungsformat (SEPA, SWIFT), erstellt die Zahlungsdatei, übermittelt an die Bank und verarbeitet Ausführungsbestätigungen oder Fehlermeldungen.

Eine Zahlung ist freigegeben, die IBAN stimmt nicht, die Datei wird abgelehnt. Drei Tage später fragt der Lieferant nach seinem Geld. Dieses Szenario kostet nicht nur Liquidität, sondern Vertrauen. Im europäischen Zahlungsverkehr summierte sich der Betrug bei Überweisungen laut EBA und EZB im Jahr 2024 auf 2,2 Milliarden Euro - und Formatfehler, falsche Empfängerdaten oder verspätete Eskalationen bei Rejects kommen noch dazu. Die letzte Meile zwischen Freigabe und Bankübermittlung verdient deshalb dieselbe Prozessdisziplin wie die Freigabe selbst.

## Zwischen Freigabe und Bankübermittlung entstehen die teuersten Fehler

Der Zahlungslauf-Agent entscheidet, was wann bezahlt wird. Aber die Frage, wie die Zahlung technisch an die Bank gelangt, bleibt offen. Genau hier setzt der Zahlungsverkehr-Agent an. Er bestimmt das Format - SEPA, SWIFT oder Scheck - anhand der Empfänger-Stammdaten, erzeugt die pain.001-Datei und übermittelt sie per EBICS oder API. Das klingt nach reiner Technik. In der Praxis scheitern Zahlungen aber nicht an der Freigabe, sondern an falschen BIC-Codes, fehlenden Pflichtfeldern oder abgelaufenen Zertifikaten. Ein Treasury-Team, das 400 Zahlungen am Tag verarbeitet, kann diese Fehler nicht einzeln prüfen. Ein regelbasierter Agent schon.

## Zehn Entscheidungsschritte ersetzen den manuellen Workaround

Der [Decision Layer](/de/decision-layer/) zerlegt den Zahlungsweg in zehn Schritte: Formatwahl, IBAN- und Empfängervalidierung, Doppelzahlungs-Check, Sanktionslisten-Screening, AWV-Meldepflicht-Prüfung, XML-Erzeugung, Bankübermittlung, Rückmeldungsverarbeitung, Eskalation bei Fehlschlag und Vier-Augen-Freigabe bei hohen Einmalzahlungen. Neun dieser Schritte sind vollständig regelbasiert. Das Zahlungsformat ergibt sich aus den Stammdaten des Empfängers, die pain.001-Validierung folgt dem SEPA-Standard, die Bankübermittlung ist ein technischer Handshake, und Fehlermeldungen werden automatisch analysiert und an den zuständigen Sachbearbeiter eskaliert. Nur bei Einmalzahlungen über dem konfigurierten Schwellenwert greift der Mensch ein. Dieses Muster - Regelwerk für die Masse, menschliche Kontrolle für das Risiko - ist die Signatur eines Decision Layer der Stufe 1.

## Verification of Payee verändert die Anforderungen grundlegend

Seit Oktober 2025 sind alle Kreditinstitute im EWR verpflichtet, vor jeder SEPA-Überweisung eine Empfängerüberprüfung durchzuführen. Der angegebene Name wird mit dem tatsächlichen Kontoinhaber abgeglichen. Für den Zahlungsverkehr-Agent bedeutet das: Jede ausgehende Zahlung durchläuft einen zusätzlichen Validierungsschritt, bevor sie die Bank erreicht. Abweichungen zwischen Stammdaten und Kontoinhaber werden erkannt und dokumentiert, bevor Geld fließt. Banken berichten, dass die verschärfte Sanktionsprüfung unter SEPA Instant zu 30 bis 50 Prozent mehr geflaggten Transaktionen führt. Ein Agent, der diese Rückmeldungen in Echtzeit verarbeitet, verhindert, dass valide Zahlungen im Prüfstau stecken bleiben.

## Der Mensch entscheidet dort, wo Automatisierung Risiko erzeugen würde

Die Vier-Augen-Freigabe bei hohen Einmalzahlungen ist kein Zugeständnis an mangelndes Vertrauen in die Technik. Sie ist eine IKS-Anforderung, die der Decision Layer bewusst als menschliche Entscheidung belässt. Denn bei einer ungewöhnlichen Einmalzahlung über 50.000 oder 100.000 Euro reicht Regelkonformität nicht aus - hier braucht es kaufmännisches Urteil. Die GoBD verlangt, dass jede Zahlung als Geschäftsvorfall nachvollziehbar dokumentiert wird. Der Agent liefert diese Dokumentation automatisch: Zahlungsformat, Übermittlungszeitpunkt, Bankrückmeldung, und bei Einmalzahlungen den Freigabezeitpunkt mit freigebender Person. Das Zahlungsverkehrsprotokoll entsteht als Nebenprodukt des Prozesses, nicht als nachträgliche Pflichtübung.

--- Gehaltsabrechnungs-Agent ---
> Brutto-Netto-Berechnung pro Mitarbeiter: EStG §38a, ELStAM-Abruf, SV-Beiträge KV/RV/AV/PV, Sachbezüge §8 EStG und Pfändung §850c ZPO - GoBD-revisionssicher dokumentiert.

Die monatliche Brutto-Netto-Berechnung ist in Deutschland zugleich steuerrechtlich, sozialversicherungsrechtlich, arbeitsrechtlich und pfändungsrechtlich gebunden. Steuerrechtlich gelten die Vorgaben des EStG zu Steuerklassen, Sachbezügen, Pauschalierung und Fünftelregelung, sozialversicherungsrechtlich die Beitragspflicht und Aufzeichnungspflichten des SGB IV mit den Beitragsbemessungsgrenzen. Arbeitsrechtlich kommen Entgeltfortzahlung, Mutterschutz, Mindesturlaub, Mindestlohn und die Mitbestimmung des Betriebsrats hinzu, pfändungsrechtlich der Pfändungsschutz und die Drittschuldner-Erklärung. Mehrere Behörden liefern die Bemessungsgrundlagen - das Bundeszentralamt für Steuern die ELStAM-Daten, das Bundesfinanzministerium die Lohnsteuer-Tabelle und Sachbezugswerte, die Bezugsgrößenverordnung die Beitragssätze. Dazu treten die GoBD, der Beschäftigtendatenschutz und die Rechtsprechung des Bundesarbeitsgerichts.

## Ein Lohnabrechnungs-Fehler kann strafbar sein und ein Bußgeld bis 500.000 Euro auslösen

Lohnabrechnungs-Korrekturen kosten direkt rund 281 USD pro Incident (American Payroll Association Studie, bestätigt durch EY Global Payroll Survey 2022 mit jeder fünften Lohnabrechnung mit Fehlern und 29 Wochen Fehlerkorrektur-Aufwand pro Vollzeitkraft pro Jahr). Die indirekten Folgen kumulieren bei mittelständischen Unternehmen schnell zu siebenstelligen Beträgen pro Geschäftsjahr. Erstens: §266a StGB Strafbarkeit Vorenthalten und Veruntreuen von Arbeitsentgelt mit Freiheitsstrafe bis 5 Jahre oder Geldstrafe bei Nichtabführung von Arbeitnehmer-Beiträgen zur Sozialversicherung an die Einzugsstellen-Krankenkassen. Die Norm gilt auch ohne Vorsatz bei grober Fahrlässigkeit und mit persönlicher Geschäftsführer-Haftung nach §69 AO und §43 GmbHG. Zweitens: §42d EStG Haftungsbescheid mit persönlicher Arbeitgeber-Haftung als Gesamtschuldner für nicht ordnungsmäßig einbehaltene Lohnsteuer - das Finanzamt wählt den Inanspruchnahme-Adressaten nach Ermessen, in der Praxis fast immer den Arbeitgeber wegen besserer Vollstreckbarkeit. Drittens: MiLoG-Bußgeld bis 500.000 EUR nach §21 MiLoG bei Mindestlohn-Verstößen in den 9 Hauptzollamt-Branchen plus Ausschluss von öffentlichen Aufträgen für 3 Jahre nach §19 MiLoG. Viertens: DRV-Sozialversicherungs-Außenprüfung alle 4 Jahre nach §28p SGB IV mit Strafzinsen 12% p.a. ab Fälligkeitsmonat - bei einem Mittelständler mit 50 Mio EUR Lohnsumme und 0,5%-Beitragsschuld-Hinzuschätzung 250.000 EUR Nachzahlung pro Prüfungszeitraum plus Strafzinsen 100-150 TEUR. Hinzu kommt der direkte Vertrauensschaden: Eine fehlerhafte Abrechnung ist das Erste, was ein Mitarbeiter an seinem Arbeitgeber in Frage stellt - wer den Nettobetrag nicht versteht oder einen falschen Betrag auf dem Konto vorfindet, verliert Vertrauen in die gesamte Organisation.

## Die monatliche Brutto-Netto-Berechnung besteht aus 14 festen Schritten

Die deutsche Brutto-Netto-Berechnung erfordert 14 Entscheidungen - die polnische Lohnabrechnung kommt auf 16, die brasilianische auf 15 bis 18. Der Grund liegt im Zusammenspiel von Steuerklassen mit ELStAM-Abruf, Sachbezügen, Pauschalierung, der Prüfung der Beitragsbemessungsgrenzen mit kassenindividuellem Zusatzbeitrag, der Direktversicherung und der Pfändung. Die Kette reicht vom ELStAM-Abruf über die Bruttolohn-Komponenten, die Sachbezüge, die steuerfreien und pauschalierten Bestandteile, die Sonderzahlungen, die Lohnsteuer und die Sozialversicherungsbeiträge bis zu Direktversicherung, Pfändung, Entgeltfortzahlung, Nettolohn, Plausibilitätsprüfung und Lohnjournal.

Ein konkretes Szenario: Mittelständischer Maschinenbauer mit 200 Mio EUR Umsatz, 1.500 Mitarbeitern (50 Mio EUR Lohnsumme verteilt auf 8 Krankenkassen mit AOK Bayern, Barmer, TK, DAK, IKK classic, Knappschaft für Minijobs), 120 Mitarbeiter im Schichtbetrieb mit Nachtarbeitszuschlag 25% nach §3b EStG steuerfrei, 30 Mitarbeiter mit Pfändungen, 60 Werkstudenten mit 20-Stunden-Grenze, 250 Mitarbeiter mit Direktversicherung §3 Nr. 63 EStG, 40 Minijobs mit 30%-Pauschalbeitrag an Minijob-Zentrale. Im November steht das 13. Gehalt an, gleichzeitig tritt eine Tariferhöhung 5% rückwirkend zum Oktober in Kraft (IG Metall TV). Im Decision Layer sind 13 der 14 Schritte regelbasierte Entscheidungen (Stufe R), 1 Schritt KI-gestützt mit menschlicher Bestätigungsoption (Stufe A für Plausibilitätsprüfung mit Pattern-Matching). Der einzige menschliche Eingriff erfolgt bei Plausibilitäts-Eskalation über 8% Abweichung zum Vormonat - nicht um zu rechnen, sondern um eine Auffälligkeit zu bewerten und mit Erklärungs-Begründung zu dokumentieren.

## Plausibilitätsprüfung mit Vormonat-Vergleich fängt stille Eingabefehler ab

Regelbasiert heißt nicht fehlerfrei. Ein falsch erfasster Stundensatz, eine verspätet eingegebene Steuerklassenänderung über ELStAM, ein vergessener VWL-Zuschuss oder eine übersehene Pfändungs-Anpassung - solche Eingabefehler sind die häufigste Ursache für Lohnabrechnungs-Korrekturen. Deshalb läuft vor der Lohnauszahlung eine zweistufige Plausibilitätsprüfung mit KI-Pattern-Matching gegen historische Vergleichsmuster. Erstens: Nettolohn gegen Vormonat. Lohn-Sprung über 8% wird mit Top-3-Erklärungs-Kandidaten begründet (neue Mitarbeiter mit ELStAM-Steuerklasse, tarifvertragliche Lohnerhöhung, Sondervergütung wie Bonus oder 13. Gehalt im November, ELStAM-Steuerklassenwechsel durch Heirat oder Trennung, Kirchensteuer-Eintritt/Austritt, Kinderzahl-Änderung mit Auswirkung auf PV-Beitragsentlastung, neue Pfändung mit reduziertem Nettoentgelt, Krankheitsfall mit Übergang Entgeltfortzahlung-Krankengeld). Zweitens: Beträge gegen Vorjahres-Periode (gleicher Monat des Vorjahres) mit Saisonbereinigung für Weihnachtsgeld November, Urlaubsgeld Juni, März-Klausel-Effekte bei Einmalzahlungen und Bonus-Auszahlungs-Stichtage März/Juni/September. Pattern-Matching liefert je Tatbestand eine Konfidenz-Bewertung mit Trend-Indikator. Bei Plausibilitäts-Eskalation wird die Lohnauszahlung blockiert bis zur Vier-Augen-Mitzeichnung durch zweiten Sachbearbeiter oder Head of Payroll. Die Klärungshistorie wird Teil des IDW PS 261 IKS-Nachweises mit Eskalations-Dokumentation für den Walk-Through-Test des Wirtschaftsprüfers.

## Pfändung nach ZPO §850c und Entgeltfortzahlung nach §3 EFZG verlangen Präzision ohne Ermessen

Sonderfälle wie Pfändungen oder Entgeltfortzahlung im Krankheitsfall wirken komplex, sind aber vollständig durch Gesetze determiniert. Die Pfändungstabelle nach ZPO §850c gibt den pfändbaren Betrag exakt vor: ab 1.7.2024 mit Pfändungsfreigrenze 1.499,99 EUR/Monat ledig ohne Unterhaltspflichtige, Erhöhung pro Unterhaltspflichtigem 564,30/313,90/250,30 EUR und gestaffelter Pfändbarkeit 30%/50%/70%/100% je nach Einkommens-Höhe. Bei mehreren Gläubigern bestimmt das Eingangsdatum und Zustellungsdatum die Rangfolge. Der Arbeitgeber als Drittschuldner muss nach §840 ZPO binnen 2 Wochen ab Zustellung des Pfändungsbeschlusses eine Drittschuldner-Erklärung an den Pfändungsgläubiger abgeben. Verstöße gegen §840 ZPO Drittschuldner-Erklärungspflicht führen zur Schadensersatzpflicht des Arbeitgebers gegenüber dem Pfändungsgläubiger. Entgeltfortzahlung nach §3 EFZG gilt für die ersten 6 Wochen mit 100% Bruttoentgelt nach Wartezeit von 4 Wochen. Ab der 7. Woche bis maximal 78. Woche zahlt die Krankenkasse Krankengeld nach §44 SGB V (70% des Bruttoentgelts, maximal 90% des Nettoentgelts) mit Arbeitgeber-Zuschuss zur Auffüllung bis Nettoentgelt-Höhe nach Tarifvertrag. U1-Umlage-Erstattung nach §1 AAG für Arbeitgeber unter 30 Mitarbeiter mit 50%/65%/80%-Erstattungsoption je gewähltem Wahltarif (durchschnittlich 1,1%); arbeitsunfallbedingte Krankheit mit 100%-U2-Erstattung über Berufsgenossenschaft. Mehrfacherkrankungen werden zusammengerechnet wenn auf gleicher Grundkrankheit beruhend nach BAG 5 AZR 442/16. Diese Regeln ändern sich selten und lassen keinen Interpretationsspielraum.

## Integration mit Lohnabrechnung, ELStAM und Krankenkassen-Schnittstelle schließt die Brutto-Netto-Kette

Der Agent verbindet sich über Schnittstellen mit den führenden deutschen Lohnabrechnungs- und ERP-Systemen - darunter DATEV LODAS, SAP HCM, Sage Lohn Plus, Personio, P&I Loga, rexx, Lexware und Workday. Die ELStAM-Daten ruft er über das Verfahren der Finanzverwaltung mit der Steuer-Identifikationsnummer ab. Die Lohnsteuer- und Beitragsdaten übergibt er über das Lohnjournal an den Lohnsteuer-Agent für die fristgerechte Anmeldung an Finanzamt und Krankenkassen. Den Buchungssatz reicht er nach SKR03 oder SKR04 an die Finanzbuchhaltung weiter und löst die SEPA-Sammelüberweisung an die Mitarbeiter aus. Alle Lohndaten werden GoBD-konform mit qualifiziertem Zeitstempel festgeschrieben und zehn Jahre revisionssicher aufbewahrt.

--- Lohnkorrekturbuchungs-Agent ---
> Rückwirkende Lohnkorrekturen: DEÜV-Stornierung Meldegrund 90, Nachzahlungen mit Fünftelregelung §39b Abs. 3 EStG und SV-Korrektur §28 SGB IV - mit Vier-Augen-Freigabe gebucht.

Lohnkorrekturen kosten deutsche Unternehmen nicht wegen der eigentlichen Differenz Geld - sondern wegen des Aufwands, sie korrekt nachzuberechnen. Der EY Global Payroll Survey 2022 dokumentiert: Jeder fünfte Payroll-Lauf enthält Fehler, pro Vollzeitkraft fallen 29 Wochen im Jahr allein für Fehlerkorrektur an. Bei 1.000 Mitarbeitenden summiert sich der direkte Korrekturaufwand schnell auf sechsstellige USD-Beträge pro Jahr. Der Lohnkorrekturbuchungs-Agent übernimmt die regelbasierte Berechnung inklusive steuerlicher und sozialversicherungsrechtlicher Auswirkungen. Die Freigabe bleibt beim Menschen.

## Jede fünfte Lohnabrechnung enthält Fehler

Die Ursachen sind vielfältig und oft systemisch: rückwirkende Tariferhöhungen, nachträglich gemeldete Überstunden, verspätet eingereichte Reisekostenabrechnungen, fehlerhafte Steuerklassenwechsel. Der EY Global Payroll Survey dokumentiert, dass jeder fünfte Payroll-Lauf fehlerhaft ist. Jeder einzelne Fehler zieht eine Kette von Folgeberechnungen nach sich - Brutto-Differenz, Lohnsteuer, Solidaritätszuschlag, Kirchensteuer, Kranken-, Renten-, Pflege- und Arbeitslosenversicherung.

Ein konkretes Szenario: Eine Tariferhöhung wird rückwirkend zum Januar vereinbart, die Information erreicht die Lohnbuchhaltung im April. Für drei Monate müssen sämtliche Entgeltbestandteile neu berechnet werden - für jeden betroffenen Mitarbeiter individuell, weil Steuerklasse, Freibeträge und SV-Pflicht unterschiedlich sind. Bei 200 betroffenen Beschäftigten entstehen 200 Einzelkorrekturen mit jeweils zehn Berechnungsschritten.

## Manuelle Nachberechnung bindet die teuersten Ressourcen

Das eigentliche Problem ist nicht die Korrektur selbst. Die Arithmetik ist eindeutig: neue Berechnung minus alte Berechnung ergibt die Brutto-Differenz. Steuer- und SV-Auswirkungen folgen festen Regeln aus EStG und SGB. Was Unternehmen tatsächlich belastet, ist der Zeitaufwand qualifizierter Fachkräfte.

Lohnbuchhalter mit Spezialkenntnissen in Steuer- und Sozialversicherungsrecht verbringen Stunden damit, Berechnungen durchzuführen, die ein Regelwerk in Sekunden leisten kann. Die durchschnittlichen Kosten pro Einzelkorrektur liegen bei 281 USD an direkten Kosten (EY). Bei komplexen Fällen wie nicht eingetragener Krankenzeit steigt der Betrag auf über 700 USD. Gleichzeitig fehlen diese Fachkräfte für Aufgaben, die tatsächlich Urteilsvermögen erfordern - etwa die Bewertung strittiger Fälle oder die Kommunikation mit betroffenen Mitarbeitern.

Die Lohnbuchhaltung muss mindestens zwei Abrechnungszyklen einplanen, um Korrekturen sauber abzuarbeiten. In dieser Zeit akkumulieren sich neue Fälle.

## Der Agent berechnet - der Mensch entscheidet

Der [Decision Layer](/de/decision-layer/) zerlegt jede Lohnkorrektur in ihre Entscheidungsschritte und ordnet jedem Schritt den richtigen Entscheider zu. Sieben der zehn Schritte sind regelbasiert: Differenzidentifikation, Rückwirkungszeitraum, Korrekturberechnung, steuerliche Auswirkung, SV-Korrektur, Netto-Differenz und Buchungssatz. Diese folgen den Rechenvorschriften aus EStG und SGB - ohne Ermessensspielraum, ohne Interpretationsbedarf.

Zwei Schritte nutzen KI-Unterstützung auf Stufe 1: Die Ursachenklassifikation ordnet den Kontext ein - handelt es sich um eine Tarifänderung, einen Erfassungsfehler oder eine Nachmeldung? Die Mitarbeiter-Kommunikation bereitet eine verständliche Erklärung der Korrektur vor, damit der betroffene Beschäftigte nachvollziehen kann, warum sich sein Nettolohn ändert.

Der zehnte Schritt bleibt beim Menschen: die Freigabe im Vier-Augen-Prinzip. Kein Korrekturbuchungssatz verlässt das System ohne menschliche Prüfung und Bestätigung.

## GoBD-konforme Dokumentation entsteht automatisch

Lohnkorrekturen sind Geschäftsvorfälle. Die GoBD verlangt, dass die Originalabrechnung unveränderbar bleibt. Korrekturen erfolgen ausschließlich über Stornierung der alten und Erstellung einer neuen Abrechnung. Der Agent erzeugt diese Belegkette automatisch: Originalabrechnung, Stornobeleg, korrigierte Abrechnung - lückenlos verknüpft und revisionssicher dokumentiert.

Für jede Korrektur protokolliert der Decision Layer die vollständige Entscheidungskette: Ursache mit Klassifikation, betroffener Zeitraum, Brutto-Differenz, Steuer-Differenz, SV-Differenz, Netto-Differenz, resultierender Buchungssatz sowie Freigabezeitpunkt und freigebende Person. Bei einer Betriebsprüfung liegt der gesamte Berechnungsweg offen - nicht als nachträgliche Dokumentation, sondern als Nebenprodukt des Prozesses selbst.

--- Lohnsteuer-Agent ---
> Monatliche Lohnsteuer-Anmeldung §41a EStG via ELSTER, SV-Beitragsnachweis §28a SGB IV via sv.net und DEÜV-Meldungen - vermeidet Haftungsbescheid §42d EStG und §266a StGB.

Die monatliche Lohn-Compliance in Deutschland ist zugleich steuerrechtlich, sozialversicherungsrechtlich, abgabenrechtlich und strafrechtlich gebunden. Steuerrechtlich gelten die Lohnsteuer mit Arbeitgeber-Haftung, die Anmeldungsfrist, die Jahres-Lohnsteuerbescheinigung und die Pauschalierung; sozialversicherungsrechtlich der Beitragsnachweis, die Beitragspflicht und die Außenprüfung alle vier Jahre. Hinzu kommen der Verspätungszuschlag und die Verzinsung der Abgabenordnung sowie die Strafbarkeit nach §266a StGB. Drei Meldekanäle laufen parallel - ELSTER für die Lohnsteuer-Anmeldung an das Finanzamt, sv.net für die Beitragsnachweise an die über 70 Krankenkassen und die DEÜV für das Meldewesen. Dazu treten die GoBD, die jährlich aktualisierten Lohnsteuer-Tabellen und Beitragsbemessungsgrenzen sowie die Rechtsprechung des Bundesfinanzhofs.

## Eine mangelhafte Lohn-Compliance kann strafbar sein und 12 Prozent Strafzinsen auslösen

Drei Schadensquellen wirken parallel und kumulieren bei mittelständischen Unternehmen schnell zu siebenstelligen Beträgen pro Geschäftsjahr. Erstens: §266a StGB Strafbarkeit Vorenthalten und Veruntreuen von Arbeitsentgelt mit Freiheitsstrafe bis 5 Jahre oder Geldstrafe bei Nichtabführung von Arbeitnehmer-Beiträgen zur Sozialversicherung an die Einzugsstellen-Krankenkassen bis drittletzter Bankarbeitstag. Die Norm gilt auch ohne Vorsatz bei grober Fahrlässigkeit und mit persönlicher Geschäftsführer-Haftung nach §69 AO und §43 GmbHG - die Geschäftsführung haftet persönlich mit Privatvermögen. Zweitens: AO §152 Verspätungszuschlag 0,25% pro Monat bei verspäteter ELSTER-Anmeldung nach §41a EStG. Bei einem Mittelständler mit 1.500 Mitarbeitern und 800.000 EUR durchschnittlicher Lohnsteuer-Anmeldung pro Monat ergibt ein einmaliger Verspätungszuschlag 2.000 EUR, bei systematischer Verspätung schnell 50-100 TEUR pro Jahr plus Säumniszuschlag 1% pro Monat nach §240 AO. Drittens: DRV-Sozialversicherungs-Außenprüfung alle 4 Jahre nach §28p SGB IV mit Strafzinsen 12% p.a. bei nachträglichen Beitragsfeststellungen. Bei einem Mittelständler mit 50 Mio EUR Lohnsumme und typischer 0,5%-Beitragsschuld-Hinzuschätzung ergibt das 250.000 EUR Nachzahlung pro Prüfungszeitraum (4 Jahre) plus Strafzinsen 12% p.a. seit Fälligkeitsmonat (typisch 100-150 TEUR Strafzinsen kumuliert). Hinzu kommt der Haftungsbescheid §42d EStG mit persönlicher Arbeitgeber-Haftung als Gesamtschuldner für nicht ordnungsmäßig einbehaltene Lohnsteuer - bei einer Lohnsteuer-Außenprüfung mit typischer Nachzahlungs-Quote 0,1-0,5% des Gehaltsvolumens 50.000-250.000 EUR Nachzahlung pro Prüfungszeitraum.

## Die monatliche Lohn-Compliance besteht aus 15 festen Schritten

Das deutsche Verfahren erfordert 15 Entscheidungen - mehr als die brasilianische oder polnische Beitragsmeldung -, weil Pauschalierung, Beitragsbemessungsgrenzen mit kassenindividuellem Zusatzbeitrag, das DEÜV-Meldewesen und der Doppelkanal aus ELSTER und sv.net zusammenwirken. Die Kette reicht von der Konsolidierung des Abrechnungslaufs über Lohnsteuer, Pauschalierung und die Beiträge zu Kranken-, Renten-, Arbeitslosen- und Pflegeversicherung samt Umlagen bis zu Pfändung, DEÜV-Meldungen, ELSTER-Anmeldung, Beitragsnachweisen, Plausibilitätsprüfung, Sonderfall-Eskalation und Festschreibung.

Ein konkretes Szenario: Mittelständischer Maschinenbauer mit 200 Mio EUR Umsatz, 1.500 Mitarbeitern (50 Mio EUR Lohnsumme verteilt auf 8 Krankenkassen mit AOK Bayern, Barmer, TK, DAK, IKK classic, Knappschaft für Minijobs), 60 Werkstudenten in zwei Vorlesungsstandorten, 20 Auslandsentsendungen pro Jahr in Tschechien und Polen mit A1-Bescheinigung, 40 Minijobs mit 30%-Pauschalbeitrag an Minijob-Zentrale. Am 1. Werktag des Folgemonats startet der Agent die Abrechnungslauf-Konsolidierung für rund 1.500 Lohnsteuer-Berechnungen und SV-Beitragsbestimmungen. Im Decision Layer sind 13 der 15 Schritte regelbasierte Entscheidungen (Stufe R), 1 Schritt KI-gestützt mit menschlicher Bestätigungsoption (Stufe A für Plausibilitätsprüfung mit Pattern-Matching), 1 Schritt menschliche Entscheidung (Stufe H für Sonderfall-Eskalation Werkstudent/Rentner/Auslandsentsendung). Die Trennung ist vor Finanzamt, DRV, Krankenkassen und Wirtschaftsprüfer transparent: die ELSTER-Übermittlung erfolgt um 14:00 Uhr am 8. Werktag des Folgemonats mit ELSTER-Transferticket und qualifiziertem Zeitstempel - vor der gesetzlichen Frist 10. Tag des Folgemonats. Die sv.net-Beitragsnachweise an die 8 Krankenkassen werden am 22. des Beitragsmonats versendet - 4 Werktage vor dem drittletzten Bankarbeitstag.

## Plausibilitätsprüfung gegen Vormonat und Vorjahres-Periode mit Saisonbereinigung

Vor jeder ELSTER- und sv.net-Übermittlung läuft eine zweistufige Plausibilitätsprüfung mit KI-Pattern-Matching gegen historische Vergleichsmuster. Erstens: Lohnsteuer- und SV-Beiträge gegen Vormonat. Lohnsteuer-Sprung über 8% wird mit Top-3-Erklärungs-Kandidaten begründet (neue Mitarbeiter mit ELStAM-Steuerklasse, tarifvertragliche Lohnerhöhung, Sondervergütung wie Bonus oder 13. Gehalt im November, ELStAM-Steuerklassenwechsel durch Heirat oder Trennung, Kirchensteuer-Eintritt/Austritt, Kinderzahl-Änderung mit Auswirkung auf PV-Beitragsentlastung). Zweitens: Beiträge gegen Vorjahres-Periode (gleicher Monat des Vorjahres) mit Saisonbereinigung für Weihnachtsgeld November, Urlaubsgeld Juni und März-Klausel-Effekte bei Einmalzahlungen. Pattern-Matching liefert je Tatbestand eine Konfidenz-Bewertung mit Trend-Indikator und Hinweis auf Sondereffekte (z.B. Tarifrunde IG Metall mit 5%-Lohnerhöhung ab April 2026). Bei Plausibilitäts-Eskalation wird die ELSTER-Übermittlung blockiert bis zur Vier-Augen-Mitzeichnung durch zweiten Sachbearbeiter oder Head of Payroll. Die Klärungshistorie wird Teil des IDW PS 261 IKS-Nachweises mit Eskalations-Dokumentation für den Walk-Through-Test des Wirtschaftsprüfers.

## Edge-Cases Werkstudent mit 20-Stunden-Grenze, Rentner-Beschäftigung mit AV-Befreiung und Auslandsentsendung mit A1-Bescheinigung

Konzerne und Mittelständler mit gemischtem Personalmix erfordern Sonderfall-Behandlung mit Eskalation an Steuerberater oder SV-Berater. Werkstudenten mit 20-Stunden-Grenze während des Semesters nach §6 Abs. 1 Nr. 3 SGB V führen zur Befreiung von KV/PV/AV-Beiträgen (nur RV-Beitrag bleibt) - bei Überschreitung greift Vollbeitragspflicht ab dem 1. Tag der Überschreitung mit rückwirkender Beitragsnachzahlung. In den Semesterferien ist Vollarbeit ohne 20-Stunden-Grenze möglich. Der Agent eskaliert bei wöchentlicher Stundenzahl >19 zur Verifikation des Studierenden-Status mit Studienbescheinigung. Rentner-Beschäftigung mit Regelaltersrente nach §187a SGB VI führt zur Befreiung von AV-Beiträgen nach §28 SGB III - der RV-Beitrag bleibt mit Aufschlagsantrag des Arbeitnehmers möglich, KV/PV-Pflicht regulär weiter. Der Agent eskaliert bei Rentenbescheid-Vorlage zur Klassifikation Frührentner (mit Hinzuverdienstgrenze 6.300 EUR/Jahr) vs. Regelaltersrentner (ohne Hinzuverdienstgrenze).

Auslandsentsendung innerhalb der EU/EWR/Schweiz nach Verordnung EG 883/2004 zur Sozialversicherungs-Koordination erfordert A1-Bescheinigung der DRV mit 24-Monate-Regel und Verlängerungsoption auf 60 Monate (Ausnahmevereinbarung nach Art. 16 EG 883/2004). Bei Drittstaaten (USA, Indien, China, Brasilien) greifen bilaterale Sozialversicherungsabkommen mit Entsendebescheinigung über bilaterales Abkommen. Der Agent eskaliert bei Auslandseinsätzen über 30 Tage zur Beantragung der A1-Bescheinigung mit dem zuständigen Sozialversicherungsträger. Kurzfristige Beschäftigung max 3 Monate oder 70 Arbeitstage pro Jahr nach §8 Abs. 1 Nr. 2 SGB IV mit SV-Befreiung wenn nicht berufsmäßig (z.B. Studenten in Semesterferien) - der Agent eskaliert bei Vertragsdauer-Klassifikation kurzfristig vs. dauerhaft mit Aufzeichnungspflicht für Arbeitstage-Zählung über Kalenderjahr. Minijobs mit 30%-Pauschalbeitrag (15% RV plus 13% KV plus 2% LSt nach §40a EStG) an die Knappschaft-Bahn-See als Minijob-Zentrale werden separat behandelt mit eigener BBNR und Beitragsnachweis-Routing.

## Integration mit DATEV LODAS, SAP HCM, sv.net und ELSTER schließt die monatliche Payroll-Compliance-Kette

Der Agent verbindet sich über Schnittstellen mit den führenden deutschen Lohnabrechnungs- und ERP-Systemen - darunter [DATEV LODAS](https://www.datev.de/), SAP HCM, Sage Lohn Plus, Personio, Lexware, ADDISON und rexx. Die Lohnsteuer-Anmeldung läuft über ELSTER mit Zertifikat oder Online-Portal, die Beitragsnachweise über sv.net zu den über 70 Krankenkassen; die achtstellige Betriebsnummer wird dabei validiert. Für den Wirtschaftsprüfer liefert der Agent die Decision-Log-Exporte mit Wirksamkeitsnachweis, für die Außenprüfung von Finanzamt und Rentenversicherung die Datenträgerüberlassung. Den qualifizierten Zeitstempel stellen BSI-zertifizierte Trust-Service-Provider bereit. Für Konzerne mit Auslandstöchtern erzeugt der Agent zusätzlich Meldungen mit A1-Bescheinigung; das deutsche Verfahren bleibt dabei steuer-, sozialversicherungs- und GoBD-konform.

--- Kleinbetrags-/Barkassen-Agent ---
> Erfasst Kassenbelege, prüft die vereinfachten Pflichtangaben nach §33 UStDV für Kleinbetragsrechnungen.

Die Barkasse kostet Unternehmen bei Betriebsprüfungen überproportional viel Geld - nicht weil die Beträge hoch wären, sondern weil Kassenführungsmängel die gesamte Buchführung entwerten können. Wenn der Prüfer Lücken in der täglichen Aufzeichnung findet, darf er schätzen. Im Jahr 2024 haben die Betriebsprüfungen der Länder laut Bundesfinanzministerium rund 10,9 Milliarden Euro Mehrergebnis erbracht. Kassenführung gehört zu den ersten Prüfungspunkten, weil sie am häufigsten angreifbar ist.

## Kassenführung entscheidet über den Ausgang der Betriebsprüfung

Das Finanzamt prüft bei Bargeldgeschäften strenger als bei bargeldlosen Vorgängen. Die Rechtsgrundlage ist eindeutig: AO §146 verlangt die tägliche Aufzeichnung aller Kassenvorgänge, die GoBD fordert Unveränderbarkeit und lückenlose Dokumentation, und seit 2020 gilt die TSE-Pflicht nach der Kassensicherungsverordnung. Seit Januar 2025 müssen elektronische Kassensysteme und ihre TSE sogar aktiv beim Finanzamt gemeldet werden. Verstöße gegen die TSE-Pflicht können Bußgelder bis zu 25.000 Euro nach sich ziehen.

Das Problem liegt nicht in der Komplexität der Regeln. Es liegt darin, dass zwischen Belegeingang und Kassenbucheintrag zu viel Zeit vergeht. Wer Kassenbelege am Freitagnachmittag für die ganze Woche nachträgt, verletzt die tägliche Aufzeichnungspflicht - und gibt dem Prüfer einen Hebel für Zuschätzungen.

## Tägliche Aufzeichnung scheitert an der Realität im Tagesgeschäft

In der Praxis sieht der Ablauf selten so aus, wie die GoBD ihn vorsieht. Eine Büroleiterin kauft vormittags Druckerpatronen für 47 Euro, ein Kollege bezahlt mittags die Bewirtung eines Kunden für 189 Euro, nachmittags kommt eine Taxiquittung über 23 Euro dazu. Drei Belege, drei verschiedene Personen, drei verschiedene Kontierungen. Der handschriftliche Eintrag ins Kassenbuch passiert - wenn überhaupt - am Ende des Tages aus dem Gedächtnis.

Das Ergebnis kennt jeder CFO, der schon eine Betriebsprüfung erlebt hat: Belege ohne Datum im Kassenbuch, falsche Zwischensummen, fehlende Tagesabschlüsse. Bei Kleinbetragsrechnungen bis 250 Euro brutto kommt ein weiteres Risiko hinzu. Die vereinfachten Pflichtangaben nach §33 UStDV erlauben zwar den Verzicht auf eine Empfängerangabe - aber wenn ein Empfänger genannt wird und die Angabe fehlerhaft ist, kann das den Vorsteuerabzug gefährden. Diese Feinheit übersehen Mitarbeitende regelmäßig.

## Sieben Entscheidungsschritte trennen Routine von Urteil

Der [Decision Layer](/de/decision-layer/) zerlegt den Kassenprozess in exakt die Schritte, die zwischen einem ordnungsgemäßen und einem beanstandeten Kassenbuch unterscheiden. Von den sieben Entscheidungsschritten ist nur einer KI-gestützt: die Belegerfassung, bei der ein LLM die relevanten Daten aus unstrukturierten Kassenbelegen extrahiert - Fotos von Quittungen, handschriftliche Notizen, verblasste Thermopapier-Ausdrucke.

Die nächsten fünf Schritte sind vollständig regelbasiert. Die Schwellenwertprüfung gegen die 250-Euro-Grenze, die Kontrolle der Pflichtangaben nach §33 UStDV, die Kontierung nach Belegart und Betrag, der Kassenbucheintrag mit GoBD-konformem Zeitstempel und der numerische Abgleich von Soll- und Ist-Bestand - all das folgt deterministischen Regeln ohne Ermessensspielraum.

Der siebte Schritt bleibt beim Menschen: Wenn der Kassenbestand vom Buchbestand abweicht, muss ein Mensch die Ursache klären. Kein Algorithmus kann entscheiden, ob eine Differenz von 14,50 Euro auf einen vergessenen Beleg, einen Zählfehler oder etwas Gravierenderes zurückgeht. Diese Grenze ist bewusst gezogen.

## Regelbasierte Prüfung schließt die Lücke zwischen Beleg und Kassenbuch

Stellen Sie sich den Montagmorgen in einer Niederlassung mit eigener Barkasse vor. Die Büroleiterin fotografiert den Tankbeleg vom Wochenende - 62 Euro. Innerhalb von Sekunden extrahiert der Agent Betrag, Datum und Steuersatz, erkennt den Beleg als Kleinbetragsrechnung, prüft die vereinfachten Pflichtangaben, kontiert auf das richtige Sachkonto und trägt den Vorgang mit Zeitstempel ins Kassenbuch ein. Vor dem Mittagessen zeigt der Tagesabschluss: Buchbestand 843,50 Euro, Zählbestand 843,50 Euro, keine Differenz.

Wenn am Mittwoch der Ist-Bestand 12 Euro unter dem Soll-Bestand liegt, dokumentiert der Agent die Abweichung und eskaliert an den Kassenverantwortlichen. Nicht an einen Algorithmus. Die Ursachenklärung bei Kassendifferenzen ist eine Entscheidung der Stufe 1 - sie verlangt menschliches Urteil, weil die möglichen Gründe zu vielfältig sind, um sie in Regeln zu fassen.

Das Ergebnis für die nächste Betriebsprüfung: Jeder Kassenvorgang ist am Tag des Geschäftsvorfalls erfasst, mit Beleg verknüpft und chronologisch dokumentiert. Die Verfahrensdokumentation, die das Finanzamt verlangt, entsteht nicht nachträglich für den Prüfer - sie entsteht als Nebenprodukt des täglichen Prozesses.

--- Buchungs-QA-Agent ---
> Prüft die formale Vollständigkeit, Plausibilität, Kontenkonsistenz und Periodenzuordnung jeder Buchung. Erkennt Duplikate und berechnet einen Anomalie-Score.

## Ein Drittel der Buchhalter meldet mehrere Fehler pro Woche

Eine Gartner-Erhebung aus 2024 zeigt: 33 Prozent der befragten Buchhalter geben an, dass ihnen pro Woche mehrere Buchungsfehler unterlaufen. Der Hauptgrund ist nicht mangelnde Sorgfalt, sondern Kapazitätsengpässe. Steigende regulatorische Anforderungen und volatile Geschäftsbedingungen erhöhen das Buchungsvolumen, während die Teamgrößen stagnieren.

Stellen Sie sich eine Finanzabteilung mit 4.000 Buchungen pro Tag vor. Bei einer Fehlerquote von drei bis fünf Prozent - dem typischen Wert manueller Erfassungsprozesse - entstehen täglich 120 bis 200 fehlerhafte Einträge. Nicht jeder davon ist materiell. Aber jeder einzelne kann im Monatsabschluss zur Korrekturbuchung werden, wenn ihn niemand vorher erkennt.

## Fehler im Hauptbuch kosten im Abschluss ein Vielfaches der Prävention

Ein falscher Steuercode auf einer Eingangsrechnung ist in der Erfassung eine Sache von Sekunden. Erreicht dieselbe Buchung das Hauptbuch, beginnt eine Kaskade: Abstimmungsdifferenz bei der Umsatzsteuer-Verprobung, Rückfrage an den Sachbearbeiter, Recherche im Beleg, Stornobuchung, Neubuchung, erneute Freigabe. Aus einer Sekunde Korrektur werden 15 bis 30 Minuten Aufwand.

Multipliziert über hunderte Korrekturbuchungen pro Monatsabschluss, verschiebt sich das gesamte Closing-Fenster. Controller warten auf bereinigte Salden. Wirtschaftsprüfer beanstanden wiederkehrende Muster. Und die Finanzleitung verliert Vertrauen in die Zahlen, die sie wöchentlich an den Vorstand berichtet.

Der ökonomische Hebel liegt deshalb nicht in der Beschleunigung des Abschlusses, sondern in der Qualität der Einzelbuchung. Was sauber ins Hauptbuch geht, muss nicht korrigiert werden.

## Acht Prüfschritte ersetzen die manuelle Stichprobe

Der [Decision Layer](/de/decision-layer/) zerlegt die Buchungsprüfung in acht diskrete Entscheidungen. Sechs davon sind vollständig regelbasiert: Formale Vollständigkeit (Beleg, Konto, Betrag, Datum vorhanden?), Kontenkonsistenz (Soll- und Habenkonto kompatibel?), Steuercode-Konsistenz (USt-Code passt zum gebuchten Konto?), Periodenabgrenzung (Belegdatum und Buchungsperiode stimmen überein?), Duplikat-Erkennung (Betrag, Konto und Datum bereits erfasst?) und das abschließende Routing.

Die beiden verbleibenden Schritte nutzen historische Muster: Die Plausibilitätsprüfung vergleicht jeden Betrag mit den üblichen Spannen der jeweiligen Kontengruppe. Der Anomalie-Score aggregiert alle Einzelprüfungen zu einer Gesamtbewertung und priorisiert die Eskalation.

Entscheidend ist die Reihenfolge. Regelbasierte Prüfungen laufen in Millisekunden. Nur Buchungen, die alle formalen Checks bestehen, erreichen die aufwändigere Muster-Analyse. In der Praxis bedeutet das: Über 95 Prozent aller Buchungen durchlaufen die komplette Prüfkette ohne menschlichen Eingriff.

## Der Normalfall passiert ohne Eskalation

Bei gut gepflegten Stammdaten werden zwei bis fünf Prozent der Buchungen eskaliert. Der Anomalie-Score bestimmt die Reihenfolge - die auffälligsten Einträge erscheinen zuerst auf dem Bildschirm des Sachbearbeiters. Statt täglich 4.000 Buchungen stichprobenartig zu prüfen, konzentriert sich das Team auf 80 bis 200 priorisierte Fälle.

Jede Eskalation, die sich als unbedenklich herausstellt, verbessert das Modell. Die Plausibilitätsschwellen kalibrieren sich durch Feedback: Mittelwert plus Standardabweichungen pro Kontengruppe als Ausgangsbasis, verfeinert durch die tägliche Praxis. Nach drei bis sechs Monaten sinkt die False-Positive-Rate messbar.

Für die Betriebsprüfung dokumentiert der Decision Layer jede Entscheidung: Welche Checks wurden durchgeführt, welche bestanden, welche fehlgeschlagen, wie hoch war der Anomalie-Score, und ob die Buchung automatisch freigegeben oder eskaliert wurde. Das IKS wird damit nicht nur wirksamer, sondern auch nachweisbar - gegenüber Wirtschaftsprüfern, Aufsicht und Vorstand.

## Buchungsqualität bestimmt die Geschwindigkeit des Abschlusses

Unternehmen, die ihre Buchungsprüfung systematisieren, berichten übereinstimmend von kürzeren Closing-Zyklen und weniger Korrekturbuchungen im Monatsabschluss. EY schätzt, dass über 70 Prozent aller Journal Entries automatisierbar sind. Die Frage ist nicht, ob die Prüfung automatisiert wird, sondern wie transparent die Entscheidungslogik dabei bleibt.

Der Buchungs-QA-Agent operiert auf Decision Layer Stufe 1 bis 2: Regelwerk für die formalen Checks, KI-Unterstützung für Plausibilität und Anomalie-Erkennung, menschliche Entscheidung nur bei eskalierten Auffälligkeiten. Kein Buchungsfehler bleibt unsichtbar, kein Prüfschritt undokumentiert - und der Monatsabschluss beginnt mit Salden, auf die sich die Finanzleitung verlassen kann.

--- Verfahrensdokumentations-Agent ---
> Erkennt Prozessänderungen (neuer Agent, neue Regel, neues System), prüft die bestehende Dokumentation auf Aktualität.

Verfahrensdokumentationen existieren in den meisten Unternehmen. Aktuell sind sie selten. Genau diese Lücke zwischen Dokumentationsstand und Prozessrealität wird bei Betriebsprüfungen zum Problem - denn der Prüfer fragt nicht, ob eine Dokumentation vorhanden ist, sondern ob sie den tatsächlichen Zustand abbildet.

## Betriebsprüfer verlangen die Dokumentation als Erstes

2023 haben Betriebsprüfer in Deutschland bei 146.516 geprüften Betrieben Mehrergebnisse von 13,2 Milliarden Euro festgestellt (BMF-Monatsbericht Oktober 2024). Zu Beginn einer Prüfung fordern Prüfer zunehmend die Verfahrensdokumentation an, bevor sie in die Sachprüfung einsteigen. Der Grund ist pragmatisch: Eine veraltete oder lückenhafte Dokumentation signalisiert mangelnde Prozesskontrollen - und rechtfertigt vertiefte Prüfungshandlungen.

Die rechtliche Konsequenz ist klar geregelt. Wenn eine fehlende oder unzureichende Verfahrensdokumentation die Nachvollziehbarkeit und Nachprüfbarkeit der Buchführung beeinträchtigt, liegt ein formeller Mangel mit sachlichem Gewicht vor. Der Betriebsprüfer kann dann die Buchführung nach AO Paragraph 158 verwerfen und die Besteuerungsgrundlagen nach AO Paragraph 162 schätzen. In der Praxis bedeutet das: Ein dokumentarischer Mangel wird zum finanziellen Risiko, noch bevor ein inhaltlicher Fehler gefunden wurde.

## Jede Prozessänderung erzeugt eine Dokumentationslücke

Das eigentliche Problem ist nicht die erstmalige Erstellung. Die meisten Finance-Abteilungen haben irgendwann eine Verfahrensdokumentation aufgebaut - oft im Rahmen eines Projekts, oft mit externer Beratung. Das Problem beginnt am Tag nach der Fertigstellung.

Ein neues ERP-Modul geht live. Ein Genehmigungsworkflow wird angepasst. Ein weiterer Agent übernimmt eine Prüfaufgabe. Jede dieser Änderungen müsste in der Verfahrensdokumentation abgebildet werden - in der allgemeinen Beschreibung, der technischen Systemdokumentation, dem Autorisierungskonzept und der IKS-Beschreibung. In der Praxis passiert das nicht zeitnah, weil niemand den Trigger hat. Die Änderung geht in Produktion, die Dokumentation bleibt stehen. Über Monate und Jahre entsteht eine wachsende Kluft zwischen dem, was dokumentiert ist, und dem, was tatsächlich passiert.

## Automatisches Monitoring schließt die Lücke in Echtzeit

Der Verfahrensdokumentations-Agent überwacht kontinuierlich die Konfigurationen der steuerrelevanten Systeme. Wenn sich ein Prozess ändert - eine neue Regel, ein neuer Agent, eine geänderte Berechtigung - erkennt er die Abweichung zwischen dokumentiertem Soll und tatsächlichem Ist. Er prüft die bestehende Dokumentation gegen eine GoBD-Checkliste nach Kapitel 10, identifiziert die betroffenen Abschnitte und generiert einen Aktualisierungsentwurf.

Die Entscheidungslogik trennt sauber nach Komplexität. Ob sich etwas geändert hat, erkennt der Agent selbständig. Ob die Dokumentation noch mit der Realität übereinstimmt, prüft er automatisch. Welche GoBD-Anforderungen gelten und wie Berechtigungen dokumentiert werden, folgt einem festen Regelwerk. Aber ob die Gesamtdokumentation vollständig ist und ob ein Entwurf freigegeben wird - das entscheidet der Mensch. Der Agent liefert den Entwurf, nicht die Unterschrift.

## Die Dokumentation dokumentiert sich selbst

Der Verfahrensdokumentations-Agent hat eine besondere Eigenschaft innerhalb des [Decision Layer](/de/decision-layer/): Er ist gleichzeitig Werkzeug und Gegenstand der Dokumentation. Jede Änderung, die er erkennt und dokumentiert, wird mit Zeitstempel, Änderungsart und Bearbeitungsstatus protokolliert. Dadurch entsteht ein lückenloses Änderungsprotokoll - nicht als separate Anforderung, sondern als Nebenprodukt des normalen Betriebs.

Für die Betriebsprüfung bedeutet das konkret: Die Verfahrensdokumentation ist nicht nur aktuell, sondern ihre Aktualität ist nachweisbar. Der Prüfer sieht nicht nur den heutigen Stand, sondern die gesamte Änderungshistorie - wann welcher Prozess angepasst wurde, wann die Dokumentation nachgezogen hat, wer freigegeben hat. Der häufigste Beanstandungspunkt verliert damit seine Grundlage.

## Verfahrensdokumentation wird zur laufenden Infrastruktur

Die klassische Verfahrensdokumentation ist ein Projektprodukt - einmal erstellt, selten aktualisiert, bei der Prüfung hektisch überarbeitet. Der Verfahrensdokumentations-Agent macht sie zu einem Teil der operativen Infrastruktur. Änderungen werden erkannt, bevor sie zu Lücken werden. Entwürfe liegen vor, bevor jemand danach fragt. Die GoBD-Konformität wird nicht bei der Prüfung hergestellt, sondern kontinuierlich sichergestellt - mit menschlicher Freigabe als letzter Instanz.

--- Rückstellungs-Agent ---
> Identifiziert Rückstellungsarten, berechnet Urlaubsrückstellungen und Tantiemen deterministisch, erstellt Buchungssätze und bereitet Anhangangaben.

Rückstellungen sind der Dauerbrenner jeder Abschlussprüfung, weil Ansatz und Bewertung auf Annahmen und Schätzungen beruhen. Der Rückstellungs-Agent trennt sauber, was sich rechnen lässt, von dem, was menschliches Ermessen braucht - und macht beide Teile prüfungsfest.

## Rückstellungen sind der Dauerbrenner jeder Abschlussprüfung

Kein anderer Bilanzposten steht so regelmäßig im Fokus von Wirtschafts- und Betriebsprüfung. Das IDW beschreibt Rückstellungen ausdrücklich als "Dauerbrenner" der Prüfungssaison, weil sowohl Ansatz als auch Bewertung nach HGB §249 auf Annahmen beruhen, die das Management zu treffen hat. Die BaFin hat zudem für die Enforcement-Saison 2025 erneut die Werthaltigkeit von Vermögenswerten und damit verbundene Bewertungsfragen in den nationalen Prüfungsschwerpunkt gehoben.

Der Grund ist struktureller Natur. Eine Urlaubsrückstellung folgt einer klaren Formel. Eine Prozesskostenrückstellung hängt an der juristischen Erfolgswahrscheinlichkeit. Eine Gewährleistungsrückstellung basiert auf Erfahrungswerten der letzten Jahre. Drei Rückstellungen, drei völlig unterschiedliche Entstehungslogiken - und in vielen Finanzabteilungen landen sie trotzdem im selben Excel-Template, das jedes Jahr händisch fortgeschrieben wird. Der Wirtschaftsprüfer sieht am Ende ein Ergebnis, aber nicht, welcher Anteil Rechnung war und welcher Ermessen.

## Urlaub und Tantiemen lassen sich vollständig deterministisch bilden

Der [Decision Layer](/de/decision-layer/) zerlegt die Rückstellungsbildung in acht Schritte. Drei davon sind reine Rechenregeln, die ohne Schätzung auskommen. Die Urlaubsrückstellung ergibt sich aus offenen Urlaubstagen multipliziert mit dem durchschnittlichen Tagessatz aus Bruttolohn und Arbeitgeber-Anteil zur Sozialversicherung. Die Tantiemen-Rückstellung folgt der vertraglichen Grundlage und der aktuellen Ergebnisprognose. Der Buchungssatz leitet sich deterministisch aus der Rückstellungsart ab.

Bei einem mittelständischen Industrieunternehmen mit 800 Mitarbeitenden, das in der Vergangenheit die Urlaubsrückstellung an drei Arbeitstagen im Januar aus der HR-Zeiterfassung in Excel überführt hat, übernimmt der Agent diesen Lauf monatlich. Die Daten kommen direkt aus dem ERP-System und den Personalstammdaten. Das Ergebnis ist keine Schätzung, sondern eine nachvollziehbare Berechnung pro Mitarbeitenden. Für den Wirtschaftsprüfer steht damit nicht mehr die Frage im Raum, ob die Höhe plausibel ist, sondern nur noch, ob die Berechnungsgrundlagen stimmen. Das verkürzt die Prüfungshandlung von Stichproben mit Nachfragen auf einen reinen Methoden-Check.

## Gewährleistung und Prozesskosten bleiben menschliche Entscheidung

Zwei Schritte der Pyramide werden bewusst nicht automatisiert. Gewährleistungsrückstellungen basieren auf Erfahrungswerten und unternehmensspezifischem Ermessen, das kein Regelwerk vollständig abbildet. Prozesskostenrückstellungen hängen an der juristischen Einschätzung von Erfolgswahrscheinlichkeiten, die eine fachliche Bewertung durch Syndikus oder Kanzlei verlangt.

Hier liefert der Agent nicht das Ergebnis, sondern die Entscheidungsgrundlage. Für Gewährleistungen aggregiert er Reklamations- und Kulanzzahlen der letzten drei Jahre, berechnet Quoten pro Produktgruppe und stellt die Basis für die Quotenschätzung bereit. Für Prozesskosten zieht er Streitwert, bisherige Verfahrenskosten und Instanz aus der Rechtsabteilung und übergibt die Vorlage an die menschliche Entscheidung. Die finale Quote und die finale Rückstellungshöhe bleiben beim Menschen, aber sie werden aus einem strukturierten Datensatz heraus getroffen und nicht aus Erinnerung.

## Der Decision Layer dokumentiert jede Bewertung prüfungsfest

Entscheidend für die Zusammenarbeit mit dem Wirtschaftsprüfer ist nicht, ob eine Rückstellung berechnet oder geschätzt wurde. Entscheidend ist, ob die Grundlage dokumentiert ist. Der Rückstellungs-Agent hält pro Rückstellung fest: Art, Berechnungsmethode, Input-Daten, Ergebnis, die Kennzeichnung deterministisch oder ermessensbasiert, Vorjahresvergleich und Begründung jeder Abweichung. Am Ende des Jahres entsteht daraus ein Rückstellungsspiegel, der als Anlage zum Jahresabschluss eingereicht werden kann.

Die Anhangangaben nach HGB §285 oder IAS 37 werden als LLM-Entwurf vorbereitet. Das heißt nicht, dass der Bilanzbuchhalter sie übernimmt. Er prüft, ob die Formulierung zur Bewertung passt, und gibt frei. Für Finanzteams, die in der Abschlusssaison jede Stunde doppelt benötigen, verschiebt sich die Arbeit damit vom Schreiben zum Prüfen - und vor allem weg von der wiederkehrenden Frage des Wirtschaftsprüfers, wie eine bestimmte Zahl zustande gekommen ist.

Quellen: [PwC BaFin Prüfungsschwerpunkt 2025](https://blogs.pwc.de/de/accounting-and-reporting/article/245905/bafin-gibt-nationalen-pruefungsschwerpunkt-fuer-2025-bekannt), [IDW zu Änderungsvorschlägen bei Rückstellungen nach IAS 37](https://www.idw.de/idw/idw-aktuell/idw-zu-aenderungsvorschlaegen-bei-rueckstellungen-nach-ias-37.html), [§ 249 HGB Gesetze im Internet](https://www.gesetze-im-internet.de/hgb/__249.html).

--- Bestellanforderungs-Agent ---
> Erkennt Bedarfe aus Verbrauchsdaten, prüft Budgetverfügbarkeit, schlägt bevorzugte Lieferanten.

Die Bestellanforderung ist die teuerste Entscheidung im gesamten Purchase-to-Pay-Prozess - nicht wegen ihres Eigenwerts, sondern weil sie festlegt, ob verhandelte Konditionen überhaupt wirksam werden. Wer hier den falschen Lieferanten wählt, am Rahmenvertrag vorbei bestellt oder Budgetgrenzen übersieht, zerstört Einsparungen, bevor die erste Rechnung im System ankommt. Der Bestellanforderungs-Agent verankert Rahmenverträge, Budgethoheit und Freigabematrix direkt im Bestellvorgang - und gibt menschliches Ermessen nur dort frei, wo es einen Unterschied macht: oberhalb des Schwellenwerts.

## Maverick Buying kostet Finanzorganisationen bis zu 16 Prozent ihrer verhandelten Einsparungen

Die Daten sind eindeutig: Laut APQC brauchen Organisationen mit hohem Anteil an Maverick Buying im Median 16 Stunden länger, um eine Bestellung auszulösen, und verlieren zwischen verhandeltem Konditionengerüst und tatsächlicher Beschaffung bis zu 16 Prozent der Einsparungen. Hackett Group beziffert im Digital World Class Benchmark 2025, dass Top-Performer durch konsequente Vertragsbindung und reduziertes Maverick Buying 60 Prozent weniger Einsparungen verlieren als der Durchschnitt. Der Hebel liegt nicht im Einkauf, sondern im Moment der Bestellanforderung. Wer hier entscheidet, entscheidet über die Marge.

In der Realität mittelständischer Finanzorganisationen sieht das so aus: Hunderte Bestellanforderungen pro Tag laufen durch Fachbereiche, die weder Rahmenverträge im Kopf haben noch Restbudgets auf Kostenstellen kennen. Die Folge sind Bestellungen beim falschen Lieferanten, Abrufe ohne Rahmenvertragsbezug, Überschreitungen, die erst im Monatsabschluss auffallen. Jede einzelne davon ist eine verlorene Verhandlung.

## Der [Decision Layer](/de/decision-layer/) zerlegt die Bestellanforderung in sieben nachvollziehbare Schritte

Der Bestellanforderungs-Agent trennt die sieben Entscheidungen in jeder Bestellanforderung sauber nach Zuständigkeit. Die Bedarfserkennung aus Verbrauchsdaten läuft als ML-gestützte Prognose, etwa wenn Mindestbestände bei Verbrauchsmaterial unterschritten werden. Budget-Check, Lieferantenvorschlag, Rahmenvertrags-Konditionen, Genehmigungsworkflow und Bestellgenerierung sind vollständig regelbasiert - numerische Vergleiche und Stammdatenlogik, keine Ermessensspielräume.

Konkret: Eine Fachabteilung löst einen Bedarf über 8.400 Euro für Instandhaltungsmaterial aus. Der Agent prüft in unter einer Sekunde, ob auf der Kostenstelle genug Restbudget vorliegt, identifiziert den bevorzugten Lieferanten aus den Stammdaten, zieht die Rahmenvertragskonditionen (Preis, Mindestmenge, Lieferzeit), errechnet über die Freigabematrix den zuständigen Genehmiger und generiert die Bestellung. Die Vertragsbindung ist dabei nicht Ergebnis guter Absicht, sondern Default.

Der Effekt auf die Zykluszeit: APQC-Benchmarks zeigen, dass Top-Performer eine Requisition-to-Order-Zeit von fünf Stunden erreichen, während schwache Prozesse rund 48 Stunden brauchen. Ein regelbasierter Decision Layer bringt Routinebestellungen auf Minutenbereich - ohne Abstriche bei der Dokumentation.

## Menschliches Ermessen bleibt dort, wo es betriebswirtschaftlich zählt

Nicht jede Bestellung lässt sich regelbasiert abarbeiten. Einzelbestellungen oberhalb eines definierten Schwellenwerts - etwa 25.000 Euro oder eine Kostenstellen-spezifische Grenze - erfordern bewusstes Ermessen: Marktlage, strategische Lieferantenbeziehung, außerordentliche Dringlichkeit. Hier tritt der Agent einen Schritt zurück. Er bereitet die Entscheidung vollständig vor (Budgetlage, Vertragsverfügbarkeit, Alternativlieferanten, Freigabekette), legt sie dem zuständigen Entscheider vor und dokumentiert die menschliche Freigabe als expliziten Schritt im Audit-Trail.

Dieses Prinzip ist kein Sicherheitsnetz, sondern Governance-Architektur: Die menschliche Freigabe ist ein IKS-Element nach §146 AO und Teil der GoBD-Dokumentationspflicht. Jede Bestellanforderung - regelbasiert oder menschlich freigegeben - ist als Geschäftsvorfall lückenlos nachvollziehbar.

## Rahmenverträge werden vom Papier zur Infrastruktur

Der wirkliche Gewinn liegt hinter der einzelnen Bestellung: Die Rahmenvertrags-Engine, die der Agent nutzt, wird im Decision Layer zur gemeinsamen Infrastruktur. Der Vertrags-Compliance-Agent greift auf dieselbe Vertragslogik zu. Die Freigabematrix wird vom Rechnungsfreigabe-Agent und vom Zahlungslauf-Agent wiederverwendet. Die generierte Bestellung wird zur Referenz für das Three-Way-Matching zwischen Bestellung, Wareneingang und Rechnung. Was als Automatisierung einer einzelnen Aufgabe beginnt, baut schrittweise die Entscheidungsinfrastruktur auf, auf der der gesamte P2P-Prozess steht.

Für die Finanzorganisation heißt das: Vertragsbindung ist nicht länger eine Frage von Schulung, Disziplin oder Kontrolle. Sie ist eine Eigenschaft des Systems. Und die verhandelten Einsparungen kommen dort an, wo sie geplant waren - in der Marge.

--- Forderungsmanagement-Agent ---
> Berechnet die Forderungsalterstruktur, bewertet Ausfallrisiken pro Debitor mit KI-Scoring, ermittelt den Wertberichtigungsbedarf und überwacht Kreditlimits.

Forderungsmanagement ist keine Fleißarbeit der Debitorenbuchhaltung, sondern eine Bilanzfrage des CFO. Wer offene Posten nur verwaltet, statt sie zu bewerten, entdeckt Ausfälle erst beim Jahresabschluss - und dann sind sie teuer. Der Forderungsmanagement-Agent verschiebt die Erkennung nach vorne: Alterstruktur, Ausfallrisiko und Wertberichtigungsbedarf werden kontinuierlich berechnet, damit strategische Entscheidungen rechtzeitig getroffen werden können.

## Das Ausfallrisiko ist 2025 zur Bilanzfrage geworden

Die Zahlen von Creditreform machen die Dringlichkeit deutlich: 2025 meldeten in Deutschland 23.900 Unternehmen Insolvenz an, ein Anstieg von 8,3 Prozent gegenüber dem Vorjahr und der höchste Stand seit mehr als zehn Jahren. Die geschätzte Schadenssumme liegt bei rund 57 Milliarden Euro, durchschnittlich mehr als zwei Millionen Euro je Insolvenzfall. Für mittelständische Gläubiger bedeutet das: Jeder offene Posten ist potenziell ein Bilanzrisiko, nicht nur eine Liquiditätsfrage.

In diesem Umfeld reicht es nicht, den Mahnlauf zu optimieren. Entscheidend ist, welche Forderungen realistisch einbringbar sind, welche wertberichtigt werden müssen und welche besser verkauft oder gerichtlich durchgesetzt werden. Diese Bewertung braucht belastbare Daten zu Zahlungsverhalten, Altersstruktur und externer Bonität - und zwar nicht einmal im Quartal, sondern laufend.

## Der [Decision Layer](/de/decision-layer/) trennt Berechnung von Bewertung

Der Forderungsmanagement-Agent zerlegt den Prozess in acht Entscheidungsschritte entlang des Gosign Decision Layer. Die Trennung ist klar: Arithmetik und Regelprüfung laufen automatisiert, Ermessensentscheidungen bleiben beim Menschen.

Die Forderungsalterstruktur ist eine Berechnung aus Fälligkeitsdaten - regelbasiert, ohne Ermessensspielraum. Gleiches gilt für die Kreditlimit-Überwachung: Eine Schwellenwert-Prüfung gegen konfigurierte Limits. Das Ausfallrisiko-Scoring nutzt ein ML-Modell, das Zahlungsverhalten, Branchenrisiko und externe Bonitätsdaten kombiniert. Bei 24 Monaten sauberer Historie erreichen solche Modelle typischerweise 80 bis 85 Prozent Trefferquote bei der Vorhersage von Zahlungsausfällen.

Strategische Entscheidungen bleiben beim CFO oder Head of Finance. Pauschalwertberichtigungen können regelbasiert vorgeschlagen werden, Einzelwertberichtigungen erfordern individuelles Ermessen, weil sie nach HGB §253 und EStG §6 unmittelbare steuerliche Konsequenzen haben. Zahlungsvereinbarungen, Factoring-Bewertung und gerichtliche Eskalation wägen Kundenbeziehung, Kosten und Risiko ab - keine Regeln, sondern Verhandlung.

## Ein konkretes Szenario: Industriekunde mit sieben Millionen Forderungsbestand

Ein Maschinenbau-Mittelständler mit rund 180 Millionen Euro Umsatz führt etwa sieben Millionen Euro offene Forderungen in den Büchern. Die Debitorenbuchhaltung pflegt Alterstruktur und Mahnläufe zuverlässig, aber das Risiko-Bild entsteht erst beim Monatsabschluss - zu spät für operative Reaktion.

Mit dem Forderungsmanagement-Agent läuft die Bewertung täglich: Das ML-Scoring markiert einen Großkunden, dessen Zahlungsverhalten sich in den letzten sechs Wochen verschlechtert hat, obwohl das Kreditlimit noch nicht überschritten ist. Der Agent dokumentiert den Risiko-Score, die beitragenden Faktoren und die aktuelle Altersstruktur. Der CFO sieht die Warnung am selben Tag und entscheidet: Kreditlimit reduzieren, Lieferung auf Vorkasse umstellen, Vertrieb informieren. Die Entscheidung bleibt menschlich, die Grundlage kommt in Minuten statt Wochen.

Am Quartalsende liefert der Agent die Datenbasis für den Wertberichtigungsbedarf: Pauschalwertberichtigung nach Altersstruktur, Kandidaten für Einzelwertberichtigung mit dokumentiertem Scoring. Der Wirtschaftsprüfer erhält pro Bewertung einen nachvollziehbaren Nachweis - Risiko-Score, Methode, Berechnungsgrundlage. GoBD-konform, prüfungssicher, reproduzierbar.

## Der Agent liefert GoBD-Evidenz, nicht Inkasso-Entscheidungen

Der Agent ist kein Inkasso-Tool und kein Ersatz für die Kundenbeziehung. Er liefert drei Dinge: eine kontinuierlich aktuelle Forderungsalterstruktur, ein risikogewichtetes Bild des Debitorenportfolios und eine dokumentierte Grundlage für Wertberichtigungsentscheidungen. Das Reporting deckt DSO, Aging, Ausfallrisiko-Heatmap und Kreditlimit-Auslastung ab, konfigurierbar nach den KPIs des CFO-Cockpits.

Was der Agent bewusst nicht tut: Er entscheidet nicht über Ratenzahlungen, er verkauft keine Forderungen, er eskaliert nicht selbstständig an die Rechtsabteilung. Diese Schritte bleiben strategisch und menschlich - genau dort, wo Verhandlungsgeschick, Kundenkenntnis und Kosten-Nutzen-Abwägung zählen. Der Decision Layer macht transparent, wer wann was entschieden hat, und liefert die Evidenz, auf der die Entscheidung beruhte. Das ist der Unterschied zwischen Automatisierung und verantwortbarer Entscheidungslogik.

Quellen:
- [Creditreform: Insolvenzen in Deutschland, Jahr 2025](https://www.creditreform.de/aktuelles-wissen/pressemeldungen-fachbeitraege/news-details/show/insolvenzen-in-deutschland-jahr-2025)
- [Creditreform Zahlungsindikator Deutschland, Winter 2025/26](https://www.creditreform.de/aktuelles-wissen/pressemeldungen-fachbeitraege/news-details/show/creditreform-zahlungsindikator-deutschland-winter-2025-26)

--- Abstimmungs-Agent ---
> Identifiziert abstimmungspflichtige Konten, gleicht Nebenbuch gegen Hauptbuch ab, ordnet offene Posten zu und erstellt Abstimmungsprotokolle.

Die Kontenabstimmung ist der Engpass des Monatsabschlusses - und sie wird zum Engpass, weil sie zum Stichtag passiert. Der [Decision Layer](/de/decision-layer/) verschiebt sie in den laufenden Monat, trennt regelbasiertes Matching vom menschlichen Urteil und macht jede Abstimmung für den Abschlussprüfer jederzeit belegbar.

## Der Stichtag ist der eigentliche Fehler im System

Hunderte Konten, tausende offene Posten, fünf Arbeitstage Zeit: So sieht die Abstimmungswoche in den meisten Finance-Abteilungen aus. Die Hälfte der Finance-Teams braucht laut APQC-Benchmarks länger als eine Woche für den Monatsabschluss, nur eine Minderheit schließt in drei Tagen oder weniger ab. Parallel dazu zeigt The Hackett Group, dass Buchhalter einen substanziellen Teil ihrer Arbeitszeit auf manuelle Low-Value-Prozesse wie Kontenabstimmungen verwenden.

Das Problem ist nicht die Menge der Buchungen, sondern die Taktung. Wer drei Wochen lang bucht und am 30. des Monats beginnt, Salden zu vergleichen, hat sich den Klärungsbedarf selbst aufgestaut. Jede Differenz, die am Stichtag auftaucht, ist eine Differenz, die mindestens 15 Tage alt ist. Die Belege sind verteilt, die Sachbearbeiter haben den Kontext verloren, und der Abschlussprüfer wartet. Der Engpass entsteht nicht durch das Volumen, sondern durch die Gleichzeitigkeit.

## Continuous Reconciliation löst den Terminstau auf

Der Abstimmungs-Agent prüft bei jeder Buchung gegen die konfigurierte Kontenliste, ob Nebenbuch und Hauptbuch noch übereinstimmen. Debitoren, Kreditoren, Bank, Anlagen, Verrechnungskonten: Die Salden werden kontinuierlich verglichen, nicht monatlich eingefroren. Differenzen tauchen in dem Moment auf, in dem sie entstehen - nicht drei Wochen später, wenn niemand mehr weiß, welche Buchung sie verursacht hat.

Das ändert die Aufgabe des Buchhalters grundlegend. Statt am Stichtag hunderte Konten gleichzeitig zu klären, bearbeitet das Team tägliche Arbeitslisten mit einer Handvoll offener Punkte. Die Belastung verteilt sich über den Monat, der Abschluss selbst wird zur Bestätigung eines bereits abgestimmten Zustands. Für den CFO bedeutet das kürzere Close-Zyklen ohne zusätzliche Köpfe - und für die Fachabteilung einen Arbeitsalltag ohne das wiederkehrende Monatsende-Fenster.

## Der Decision Layer trennt Rechenarbeit vom Ermessen

Die Abstimmung zerfällt in acht klar umrissene Entscheidungsschritte. Sieben davon sind Rechenarbeit: Welche Konten gehören in die Liste, stimmen die Salden überein, welche offenen Posten erklären die Differenz, welcher Freigabe-Status ist erreicht. Diese Schritte laufen regelbasiert, deterministisch und protokolliert. Die Zuordnung offener Posten kombiniert exakten Abgleich mit unscharfem Matching für Teilzahlungen und gerundete Beträge. Ungewöhnliche Restdifferenzen markiert der Agent über Pattern-Matching zur Prüfung.

Eine einzige Entscheidung bleibt beim Menschen: die Materialitätsbewertung. Ist eine Restdifferenz von 340 Euro auf einem Verrechnungskonto wesentlich oder nicht? Diese Frage hängt von Kontext, Entwicklung und Ermessen ab und wird bewusst nicht automatisiert. Der Agent legt die Differenz mit allen relevanten Informationen vor, der Sachbearbeiter entscheidet. Das ist Stufe 1 bis 2 im Decision Layer: hohe Automatisierung in der Ausführung, klarer Humanvorbehalt bei der Bewertung. Jede Entscheidung wird mit Zeitstempel, Ersteller und Begründung in das Abstimmungsprotokoll geschrieben - die Grundlage für jede Abschlussprüfung nach GoBD.

## Der Abschluss wird vom Sprint zur Routine

Wer Continuous Reconciliation einführt, verändert nicht nur den Arbeitsablauf, sondern das Erwartungsprofil des Monatsabschlusses. Das Abstimmungsprotokoll ist jederzeit verfügbar, nicht nur zum Stichtag. Der Wirtschaftsprüfer kann im laufenden Monat einsehen, welche Konten abgestimmt sind und mit welchem Evidenzstand. Offene Punkte sind keine Last-Minute-Überraschung mehr, sondern eine gepflegte Arbeitsliste.

Für die Führungsebene bedeutet das drei Dinge: Planbare Close-Termine statt Überstunden-Zyklen, eine belastbare Zahlengrundlage für Forecasts und Reporting während des Monats, und eine Prüfungsspur, die HGB §238 und GoBD nicht nur erfüllt, sondern sichtbar macht. Die Abstimmung hört auf, ein monatliches Ereignis zu sein. Sie wird zu dem, was sie eigentlich immer war: ein kontinuierlicher Kontrollprozess, der nur historisch als Stichtagsereignis verkleidet wurde.

--- Revenue-Recognition-Agent ---
> Realisiert Umsatzerlöse nach HGB §252 und IFRS 15 Five-Step-Model, identifiziert Leistungsverpflichtungen, allokiert auf Standalone Selling Prices und berechnet Teilgewinnrealisierung §270 HGB - Schutz vor DPR.

Die Umsatzrealisierung in deutschen Konzernen ist zugleich handelsrechtlich verankert, international standardisiert, durch IDW-Verlautbarungen und DRSC-Standards konkretisiert, durch die Rechtsprechung des Bundesfinanzhofs präzisiert und durch das Steuerrecht überlagert. Handelsrechtlich gelten das Realisationsprinzip mit Imparitätsprinzip, die Teilgewinnrealisierung und die IFRS-Pflicht für kapitalmarktorientierte Mutterunternehmen; international IFRS 15 mit den Lizenz- und Anhang-Anforderungen. Vier Instanzen wirken zusammen - die Bilanzkontrolle der Prüfstelle, die BaFin-Anordnung zur Veröffentlichung, die Konzernbetriebsprüfung des Finanzamts und der Schlüsselkontroll-Test des Wirtschaftsprüfers. Dazu treten die GoBD mit dem qualifizierten Zeitstempel als Nachweis der Zehn-Jahres-Aufbewahrung.

## Eine mangelhafte Umsatzrealisierung kann zur Neuaufstellung der Bilanz führen

Drei Schadensquellen wirken parallel und kumulieren bei mittelständischen Konzernen schnell zu siebenstelligen Beträgen pro Geschäftsjahr. Erstens: DPR-Fehlerfeststellung der Deutschen Prüfstelle für Rechnungslegung mit Stichprobenprüfung der Konzernabschlüsse alle 4-5 Jahre. Umsatzrealisierung war 2023 und 2024 das häufigste Prüfungsthema mit über 30 Prozent der Fehlerfeststellungen, fokussiert auf Mehrkomponenten-Verträge mit unzureichender Distinct-Beurteilung, variable Vergütung ohne dokumentierte Constraint-Anwendung nach IFRS 15.56, Kontrollübergangs-Beurteilung ohne IFRS-15.31-38-Kriterien-Test und fehlerhafte Disclosure Notes mit unzureichender Disaggregation. Bei Fehlerfeststellung greift zweistufiges Verfahren mit DPR-Aufforderung zur Korrektur und BaFin-Anordnung der Fehler-Veröffentlichung im Bundesanzeiger nach WpHG §117. Empirische Studien zeigen Aktien-Kursverluste 5-15 Prozent am Tag der Veröffentlichung mit nachhaltiger Vertrauenskrise bei Investoren und Ratingagenturen. Zweitens: BFH-Schätzungsbefugnis nach AO §162 bei nicht prüfbaren Umsatzrealisierungs-Beurteilungen mit Hinzuschätzung 3-8 Prozent des Konzernumsatzes pro Prüfungszeitraum (4 Jahre). Bei einem Mittelständler mit 200 Mio EUR Umsatz typisch 24-64 Mio EUR Hinzuschätzung mit Steuernachzahlung 7-19 Mio EUR und Säumniszuschlag 1 Prozent pro Monat nach §240 AO plus Verzinsung 0,15 Prozent pro Monat ab 15-monatigem Karenzlauf nach §233a AO. Drittens: HGB-Restatement nach §316 Abs. 3 HGB durch Wirtschaftsprüfer-Versagungsvermerk mit IDW-PS-951-Mängelbericht. Folgewirkungen sind Investorenklage nach §147 KapMuG, Aktionärsanfechtung der Gewinnverwendungsbeschlüsse, Delisting-Risiko bei wiederholten Fehlerfeststellungen, persönliche Vorstands-/Geschäftsführer-Haftung nach §93 AktG bzw. §43 GmbHG und bei vorsätzlich falscher Umsatzrealisierung §332 HGB Strafbarkeit Bilanzdelikte mit Freiheitsstrafe bis 3 Jahren. Bei Marktmissbrauchs-Verfahren der BaFin nach Art. 12 EU-Marktmissbrauchsverordnung 596/2014 droht Strafanzeige der Staatsanwaltschaft mit §263 StGB Betrug bis 5 Jahre Freiheitsstrafe oder bei besonders schwerem Fall bis 10 Jahre.

## Die Umsatzrealisierung besteht aus 16 Beurteilungsschritten mit Parallelrechnung nach HGB und IFRS

Die Umsatzrealisierung erfordert 16 Entscheidungen, davon drei mit menschlichem Ermessen, weil das HGB-Realisationsprinzip, das IFRS-15-Modell mit Trennungstest, die Rechtsprechung zur Teilgewinnrealisierung und die Auftragsabwicklung zusammenwirken. Die Kette reicht von der Vertragsdaten-Extraktion über die Vertragsidentifikation mit Bonitätsprüfung, die Beurteilung der Leistungsverpflichtungen, die Transaktionspreis-Bestimmung, die Standalone-Selling-Prices und die Allokation bis zum Kontrollübergang, der Fortschrittsmessung, der HGB-Prüfung mit Drohverlust-Vorsorge, der Buchung der Vertragssalden, der Plausibilitätsprüfung, der Sonderfall-Eskalation, der Anhangangabe und der Festschreibung.

Ein konkretes Szenario: Mittelständischer Software-Konzern mit 350 Mio EUR Umsatz und IFRS-Pflicht nach §315e HGB als Anleihe-Emittent am Frankfurter Bondm. Quartalsabschluss zum 30. September 2026 mit 1.200 aktiven Verträgen verteilt auf Software-Lizenzen (Perpetual und Subskription), Implementierungs-Projekte mit Cost-to-Cost-Methode, Cloud-Hosting-Verträge mit Right-to-access-Charakteristik, Premium-Support-Verträge und Schulungs-Pakete. Im Decision Layer sind 13 der 16 Schritte regelbasierte Entscheidungen (Stufe R), 2 Schritte LLM-gestützt mit menschlicher Bestätigungspflicht (Stufe A für Vertragsdaten-Extraktion und Disclosure-Note-Entwurf), 3 Schritte menschliche Beurteilung mit dokumentiertem Memo (Stufe H für Distinct-Performance-Obligation-Identifikation, Kontrollübergangs-Beurteilung und Sonderfall-Eskalation). Die Trennung ist vor DPR-Prüfer, Wirtschaftsprüfer und Finanzamt-Betriebsprüfer transparent: die LLM-Vertragsextraktion liefert strukturierte Vertragsdaten in 10 Minuten je Vertrag mit Quellenverweis auf Vertragsabsätze, die Distinct-Beurteilung erfolgt durch den Bilanzierer mit Memo und BFH-Bezug, der Buchungssatz wird automatisch generiert mit Auto-Reallokation bei Vertragsmodifikationen, die Disclosure Notes werden als LLM-Entwurf mit Bilanzierer-Review und Festschreibung im Konzernanhang erzeugt.

## Plausibilitätsprüfung gegen Vorquartal und Branchen-Benchmarks aus DRS-27-Disaggregations-Daten mit Anomalie-Erkennung

Vor jeder Quartalsabschluss-Festschreibung läuft eine zweistufige Plausibilitätsprüfung mit KI-Pattern-Matching gegen historische Vergleichsmuster und Branchen-Benchmarks. Erstens: Umsatzerlöse, Bruttomarge, Contract-Asset/Liability-Salden und Vertragslaufzeiten gegen Vorquartal mit 8-Quartals-Trendanalyse und Saisonbereinigung (Q4-Spike bei Software-Lizenz-Renewals, Q1-Tief bei zyklischen Branchen). Zweitens: Vergleich gegen Branchen-Benchmarks aus DRS-27-Disaggregations-Daten vergleichbarer Konzerne (gleiche Branche, vergleichbare Größe und Geschäftsmodell). Anomalie-Erkennung für drei kritische Muster: Cliff-Effekte mit unverhältnismäßiger Umsatz-Konzentration in Quartalsende-Tagen (Quarterend-Spikes mit über 30 Prozent in den letzten 5 Tagen sind verdächtig); Reverse-Bookings mit hoher Stornoquote im Folgequartal (typisch über 5 Prozent als Indikator für überzogene Aufnahme variabler Vergütung); Round-Trip-Transaktionen mit zirkulären Lieferungen ohne wirtschaftliche Substanz nach IFRS 15.9 Substance-Test. Pattern-Matching liefert je Bilanz-Posten eine Konfidenz-Bewertung mit Trend-Indikator und Hinweis auf Sondereffekte (z.B. Großauftrag-Abschluss, M&A-Transaktion, FX-Effekte bei internationalen Verträgen). Bei Plausibilitäts-Eskalation ab Schwellwert 5 Prozent Vorperioden-Abweichung wird die Quartalsabschluss-Festschreibung blockiert bis zur Vier-Augen-Mitzeichnung durch zweiten Bilanzierer oder Head of Accounting. Bei Anomalie-Mustern Cliff-Effekte / Reverse-Bookings / Round-Trip Auto-Eskalation an Konzernrevision plus Audit Committee. Die Klärungshistorie wird Teil des IDW PS 261 IKS-Nachweises mit Eskalations-Dokumentation für den Walk-Through-Test des Wirtschaftsprüfers.

## Sonderfälle: Mehrkomponenten-Verträge, Earn-out-Klauseln und Lizenz-Verlängerungen

Konzerne mit Enterprise-Vertriebsmodellen erfordern eine Sonderfall-Behandlung mit Eskalation an den Bilanzierer. Bei komplexen Verträgen über 5 Mio Euro mit Lizenz, Implementierung, Hosting, Support und Schulung ist zu beurteilen, welche Leistungen getrennt zu erfassen sind; der Agent eskaliert und liefert dem Bilanzierer die relevanten Vertragsklauseln, vergleichbare Präzedenzfälle und eine Kriterien-Checkliste. Bei signifikanten Earn-out-Klauseln - etwa Performance-Boni, gestaffelten Mengenrabatten oder Strafen bei verspäteter Lieferung - ist die variable Vergütung zu beurteilen: im IFRS ab hoher Wahrscheinlichkeit, im HGB erst bei hinreichender Sicherheit. Der Agent berechnet beide Welten parallel und bildet die latente Steuer für die Differenz.

Software-Lizenz-Renewal nach IFRS 15.B58-B79 mit Right-to-use vs. Right-to-access-Beurteilung erfordert Eskalation bei integrierten Cloud-Lösungen mit kontinuierlichen Lieferanten-Aktivitäten - der Agent identifiziert Indikatoren für Right-to-access (laufende Updates, Cloud-Hosting, Sicherheits-Patches, dynamische Markenwerbung) und schlägt zeitraumbezogene Erfassung über die Lizenz-Laufzeit vor. Anlagenbau-Verträge mit Cost-to-Cost-Methode nach IDW PS 951 erfordern Plan-Auftragskalkulation mit monatlichem Plan-Ist-Vergleich und Drohverlustrückstellung bei erkennbaren Verlustaufträgen nach §249 HGB Abs. 1. Der Agent eskaliert bei Plan-Ist-Abweichung über 10 Prozent zur Plan-Korrektur mit cumulative-catch-up-adjustment nach IFRS 15.21 oder prospektivem Approach. Bei langfristigen Bauverträgen über 24 Monate Laufzeit und HGB-Teilgewinnrealisierung §270 mit BFH-IV-R-6/19-Anforderungen (hinreichende Sicherheit des Gesamtgewinns) eskaliert der Agent zur Bilanzierer-Beurteilung der Sicherheits-Bedingung mit Memo. Bei jeder Eskalation erfolgt vollständige Decision-Log-Aufbereitung mit Vertragsdaten, Beurteilungs-Kriterien und Verweisen auf BFH-Urteile, IFRS-Standards und IDW-Verlautbarungen an den Bilanzierungs-Verantwortlichen zur Beurteilung. Die Freigabe oder Anpassung wird mit Begründungs-Memo (Bilanzierer-Name, Datum, Schlüssel-Entscheidung) im Decision Log dokumentiert.

## Integration mit SAP S/4HANA RAR, DATEV Konzern-Konsolidierung und Lucanet schließt die Konzernabschluss-Pipeline

Der Agent verbindet sich über Schnittstellen mit den führenden deutschen ERP-, Konsolidierungs- und Audit-Systemen - darunter [SAP S/4HANA RAR](https://www.sap.com/germany/products/financial-management/revenue-recognition.html) als vollständige IFRS-15-Engine, Oracle Fusion, Workday, Dynamics 365 Subscription Billing, Salesforce Revenue Cloud und ProAlpha. Die Konzern-Konsolidierung läuft über DATEV, Lucanet oder SAP Group Reporting mit HGB-Abschluss und IFRS-Überleitung. Für den Wirtschaftsprüfer liefert der Agent die Decision-Log-Exporte, sodass er die Beurteilungen, die Standalone-Selling-Prices, die Allokation und die Kontrollübergangs-Memos direkt einsehen kann. Für die Bilanzkontrolle erstellt er die Anhangangaben mit Aufgliederung, Veränderungsanalyse und Restleistungs-Verpflichtungen, für die Konzernbetriebsprüfung die Datenträgerüberlassung. Den qualifizierten Zeitstempel stellen BSI-zertifizierte Trust-Service-Provider bereit. Für Konzerne mit Auslandstöchtern erzeugt der Agent zusätzlich Beurteilungen nach den jeweiligen lokalen Standards und überleitet sie in den IFRS-Konzernabschluss; das deutsche Verfahren bleibt dabei HGB- und GoBD-konform.

--- SV-Meldungs-Agent ---
> Bestimmt Meldeanlässe, stellt Meldedaten zusammen, erstellt DEÜV-Formate und übermittelt elektronisch an die Sozialversicherungsträger.

SV-Meldungen sind der am stärksten regulierte Routineprozess in der Lohnbuchhaltung. Jede An- und Abmeldung, jede Jahresmeldung, jede Unterbrechung und jede Beitragsänderung ist meldepflichtig, fristgebunden und haftungskritisch. Die Deutsche Rentenversicherung zieht jährlich mehr als eine halbe Milliarde Euro an Nachforderungen aus Betriebsprüfungen ein; in den rund 800.000 geprüften Betrieben beanstanden die Prüfer in etwa einem Drittel der Fälle fehlerhafte oder fehlende Meldungen. Für CFOs ist das kein Lohnbuchhaltungsthema, sondern ein Haftungsrisiko: Das Unternehmen haftet für die Beiträge nach § 28e SGB IV - bis hin zur persönlichen Organhaftung bei vorenthaltenen Beiträgen nach § 266a StGB.

Der SV-Meldungs-Agent löst genau dieses Risiko, indem er die zehn Entscheidungen der DEÜV-Meldung vollständig regelbasiert abbildet: Meldeanlass bestimmen, Meldegrund verschlüsseln, Meldedaten zusammenstellen, Beitragsgruppen-Schlüssel zuordnen, DEÜV-Datensatz erstellen, Datensatz validieren, Frist prüfen, fristgerecht übermitteln, Rückmeldung verarbeiten, fehlerhafte Meldungen stornieren und neu erstatten. Kein KI-Anteil, kein Ermessen, keine Halluzination. Das ist der Grund für die höchste Readiness-Bewertung im gesamten Finance-Katalog.

## Die Haftungsrealität hinter der Routine

Die Zahlen der Deutschen Rentenversicherung aus den turnusmäßigen Betriebsprüfungen nach § 28p SGB IV zeigen, wie teuer Nachlässigkeit wird: laut DRV-Statistik werden jährlich mehrere hundert Millionen Euro an Beitragsnachforderungen erhoben, bei rund 30 Prozent der geprüften Arbeitgeber mit beanstandeten Meldungen. Dazu kommen Säumniszuschläge von einem Prozent pro angefangenem Monat auf jeden rückständigen Beitrag, Festsetzungsfristen von bis zu 30 Jahren und eine Beweislastumkehr: Der Arbeitgeber muss glaubhaft machen, dass die Meldung nicht schuldhaft unterblieben ist.

In der Praxis entstehen die Fehler selten aus Absicht. Sie entstehen, weil ein Personalwechsel den Meldeanlass "Abmeldung wegen Austritt" mit dem Beitragsgruppen-Schlüssel "0000" kollidiert, weil eine Jahresmeldung formal fehlschlägt und niemand die Rückmeldung der Krankenkasse prüft, weil ein Minijob die Entgeltgrenze überschreitet und die Zuständigkeit von der Minijob-Zentrale zur Krankenkasse wechselt. Jeder dieser Fälle ist ein regelbasierter Entscheidungsbaum - und jeder dieser Bäume lässt sich deterministisch abbilden.

## Zehn Entscheidungen, null KI-Anteil

Der [Decision Layer](/de/decision-layer/) zerlegt die SV-Meldung in zehn Micro-Decisions, die alle denselben Charakter haben: Input aus dem Lohnbuchhaltungssystem, Regel aus SGB IV oder DEÜV, eindeutige Ausgabe. Der Meldeanlass ergibt sich aus der Personalstammveränderung. Der Beitragsgruppen-Schlüssel folgt aus Versicherungsstatus, Beschäftigungsart und Entgelt. Das DEÜV-Format ist technisch spezifiziert. Die Übermittlung erfolgt über die standardisierte Schnittstelle an den zuständigen Träger. Die Rückmeldung wird geparsed und bei Ablehnung mit einem Regelwerk abgeglichen, das die häufigsten Fehlerkonstellationen kennt.

Diese Architektur macht den Agent zum Gegenbeispiel für alle Diskussionen über KI-Compliance. Wo keine KI arbeitet, gibt es auch keine KI-Risiken. Der EU AI Act ist nicht einschlägig, weil keine probabilistische Entscheidung getroffen wird. Die SV-Prüfung akzeptiert den Decision Layer als Lohnunterlage nach § 8 BVV, weil jede Meldung mit Meldeanlass, Zeitstempel, Regelpfad und Übermittlungsnachweis revisionsfest dokumentiert ist.

## Szenario: 1.200 Mitarbeiter, zwölf Monate, null Beanstandungen

Ein Konzern mit 1.200 sozialversicherungspflichtig Beschäftigten in drei Gesellschaften erzeugt pro Monat zwischen 40 und 80 DEÜV-Meldungen: Eintritte, Austritte, Unterbrechungen, Änderungen, Sondermeldungen. Vor Einführung des Agents dauerte die Meldewoche im Januar (Jahresmeldungen) regelmäßig zehn Tage, die Fehlerquote bei den Rückmeldungen lag bei vier bis sechs Prozent, und die Betriebsprüfung 2022 endete mit einer Nachforderung von 180.000 Euro plus Säumniszuschläge.

Nach der Einführung des SV-Meldungs-Agents wird jede Stammdatenänderung direkt in einen Meldeentscheid übersetzt. Die Jahresmeldungen für 1.200 Mitarbeiter werden in 90 Minuten erstellt und übermittelt. Rückmeldungen der Krankenkassen werden maschinell geparsed. Abgelehnte Meldungen, die regelbasiert korrigierbar sind, laufen automatisch neu; der Rest landet im Sachbearbeiter-Cockpit mit Fehlercode, Regelreferenz und Lösungsvorschlag. Die Betriebsprüfung 2026 ist ein Audit-Termin von zwei Tagen, weil die Prüfer jede Meldung über die Process-Documentation-Schnittstelle selbst abfragen.

## Prüfungsfeste Dokumentation als Nebenprodukt

Der eigentliche Effekt entsteht nicht in der Meldeerstellung, sondern in der Dokumentation. Jede Entscheidung wird mit Eingangsdaten, Regelpfad, Ausgangsdatensatz und Rückmeldung abgelegt. Die SV-Prüfung nach § 28p SGB IV findet eine vollständige Meldehistorie vor, in der sich jede einzelne Meldung rekonstruieren lässt - inklusive des exakten Regelstands zum Meldezeitpunkt. Fragen wie "Warum wurde Herr Müller im März 2024 mit Beitragsgruppe 1111 statt 6100 gemeldet?" sind in unter einer Minute beantwortet, mit Zitat der angewandten Regel.

## Beitrag zur Gesamtinfrastruktur

Der SV-Meldungs-Agent etabliert drei Infrastrukturbausteine, die andere Agenten im Katalog wiederverwenden: die authentifizierte Schnittstelle zu den SV-Trägern, das Framework für DEÜV-konforme Datensätze und die Fristüberwachungslogik für alle meldepflichtigen Prozesse. Sobald diese Infrastruktur steht, werden der Lohnsteuer-Agent, der A1-Bescheinigungs-Agent und der Beitragsnachweis-Agent ohne eigene Integrationsarbeit angebunden. Das ist der ökonomische Hebel: Der Agent amortisiert sich nicht nur über Beanstandungsfreiheit, sondern auch über die Anschlussfähigkeit des gesamten Payroll-Bausteins.

--- Betriebsprüfungs-Vorbereitungs-Agent ---
> Betriebsprüfungs-Vorbereitung: GoBD-konformer Datenexport im IDEA-Format, Z1/Z2/Z3-Daten-Zugriff §147 AO, Risikoanalyse und Prüfer-Q&A-Vorbereitung mit Audit-Trail.

Eine Betriebsprüfung ist für Großunternehmen kein Ausnahmeereignis, sondern Dauerzustand. Wer den Prüfungszeitraum als Ernstfall behandelt, verliert. Wer ihn als kontinuierliche Disziplin organisiert, reduziert Rückstellungen, verkürzt Prüfungsdauer und gewinnt Verhandlungssicherheit. Der Betriebsprüfungs-Vorbereitungs-Agent verschiebt Finance von reaktiver Aktenlage-Produktion zu permanent audit-ready.

## Warum die klassische Prüfungsvorbereitung CFOs Geld kostet

Das BMF hat für 2024 ein Mehrergebnis von rund 10,9 Milliarden Euro aus 140.764 Betriebsprüfungen gemeldet - bei 12.359 Prüfern bundesweit und einer Prüfungsquote von 1,6 Prozent. Großbetriebe und Konzerne liegen bei der sogenannten Anschlussprüfung, sie werden also lückenlos und turnusmäßig geprüft. Für CFOs bedeutet das: Die nächste Prüfung ist nicht die Frage ob, sondern wann.

Die klassische Vorbereitung startet mit der Prüfungsanordnung. Ab diesem Moment hat das Unternehmen regelmäßig zwei bis drei Wochen, um Daten im IDEA-Format aufzubereiten und die drei Zugriffsarten Z1, Z2 und Z3 bereitzustellen. In diesen Wochen rotieren Steuerabteilung, IT und externe Berater im Krisenmodus. Antworten auf Prüferfragen entstehen unter Zeitdruck. Historische Entscheidungen werden aus Unterlagen rekonstruiert, die Ersteller längst das Unternehmen verlassen haben. Das Ergebnis ist kalkulierbar: höhere Rückstellungen, schlechtere Verhandlungsposition, längere Prüfungszyklen.

Das Problem ist nicht die Prüfung - es ist der strukturelle Bruch zwischen laufendem Betrieb und Prüfungsvorbereitung. Jede Entscheidung, die nicht zum Zeitpunkt des Geschäftsvorfalls dokumentiert wurde, muss später rekonstruiert werden. Dort entstehen die Mehrergebnisse.

## Was der [Decision Layer](/de/decision-layer/) daran ändert

Der Betriebsprüfungs-Vorbereitungs-Agent ist kein Werkzeug, das im Ernstfall eingeschaltet wird. Er ist der Integrations-Punkt aller anderen Finance-Agenten. GoBD-Compliance, Kontierung, Umsatzsteuer, Quellensteuer, Verrechnungspreise - jede dieser Entscheidungen wird dort getroffen, wo sie entsteht, und wird maschinenlesbar dokumentiert. Der Agent verdichtet diese Dokumentation jederzeit auf Abruf zur prüfungsfertigen Datenbasis.

Die Arbeit zerfällt in drei klar getrennte Rollen. Regelbasierte Schritte übernimmt die Automatisierung ohne Ermessen: Datenbankabfragen nach Prüfungszeitraum und Steuerart, IDEA-Export nach GDPdU-Standard, Aufbereitung der Z1/Z2/Z3-Zugriffe. Stunden statt Wochen. KI-unterstützte Schritte bringen Mustererkennung ein: Die Prüfungsanordnung wird interpretiert, historische Prüfungsschwerpunkte werden abgeglichen, Prüferfragen werden an die zuständige Abteilung geroutet. Menschliche Entscheidungen bleiben dort, wo sie hingehören: Antwortstrategie, Steuergestaltungs-Risikobewertung und Rückstellungsschätzung. Diese Schritte sind ausdrücklich Human-in-the-Loop, weil sie fachliches Ermessen und Verhandlungserfahrung voraussetzen.

## Szenario: Wie eine Anschlussprüfung im Decision Layer läuft

Ein Konzern mit Sitz in Deutschland erhält eine Prüfungsanordnung für die Jahre 2022 bis 2024. Geprüft werden Körperschaftsteuer, Gewerbesteuer, Umsatzsteuer und eine gesonderte Verrechnungspreisdokumentation nach §90 Absatz 3 AO. Der Agent analysiert den Bescheid innerhalb von Minuten, ordnet die Anforderungen den zuständigen Agenten zu und erstellt einen Vorbereitungsplan mit geschätztem Aufwand und offenen Risikoclustern.

Die Datenzusammenstellung - üblicherweise die teuerste Phase - läuft im Hintergrund. IDEA-Exporte sind unmittelbar verfügbar, weil die Buchungsdaten ohnehin im geforderten Format vorliegen. Die Risikobereich-Analyse markiert zwei Cluster: eine Serie innergemeinschaftlicher Lieferungen mit wechselnden Bestimmungsländern und eine konzerninterne Lizenzstruktur, deren Verrechnungspreisdokumentation seit 2023 mehrfach angepasst wurde. Beide Cluster gehen an die Steuerabteilung mit vorbereiteter Datenbasis und Argumentationslinie. Die Rückstellung wird vom Head of Tax mit Ermessen festgelegt - der Agent liefert die Datenspanne, nicht das Urteil.

Das Ergebnis: Keine Krisenwochen. Keine externen Berater für die Datenaufbereitung. Der Head of Tax konzentriert sich auf Argumentation und Verhandlung, nicht auf Beweisbeschaffung.

## Permanent audit-ready macht aus der Betriebsprüfung eine Routineübung

Permanent audit-ready zu sein ist kein zusätzlicher Aufwand - es ist eine Umverteilung bestehenden Aufwands. Statt alle drei bis fünf Jahre ein Prüfungsprojekt zu stemmen, dokumentiert jede Entscheidung sich selbst im Moment ihrer Entstehung. Die Steuerabteilung wird vom Archivar zum Verhandler. Der CFO reduziert die Unsicherheit in der Rückstellungsplanung und kann Steuergestaltungs-Risiken mit belastbarer Datengrundlage bewerten, bevor der Prüfer sie findet.

Für Konzerne mit Anschlussprüfung, komplexen Verrechnungspreisstrukturen oder internationaler Aufstellung ist das kein Komfortthema, sondern eine direkte Frage an Rückstellungen, Zinskosten nach AO §233a und Reputationsrisiken. Der Betriebsprüfungs-Vorbereitungs-Agent macht aus der nächsten Prüfung eine Routineübung - vorausgesetzt, die darunterliegenden Finance-Agenten dokumentieren konsequent.

--- Three-Way-Matching Agent ---
> Gleicht Bestellung, Wareneingang und Rechnung dreiseitig ab. Prüft Mengen, Preise und Toleranzen.

Three-Way-Matching ist der Entscheidungsengpass der Kreditorenbuchhaltung, weil jede einzelne Eingangsrechnung gegen Bestellung und Wareneingang geprüft werden muss, bevor sie bezahlt wird. Der Three-Way-Matching Agent ersetzt die manuelle Prüfung durch elf deterministische Regeln und erreicht damit eine Straight-Through-Rate auf Enterprise-Niveau - ohne KI-Anteil, ohne EU-AI-Act-Einstufung, ohne Interpretationsspielraum. Er ist der Startkandidat, mit dem CFOs den [Decision Layer](/de/decision-layer/) in der Finanzorganisation etablieren, weil er hohes Volumen, niedriges Risiko und direkt messbare Cash-Wirkung kombiniert.

## Warum manuelles Matching die P2P-Durchlaufzeit dominiert

In einer typischen Enterprise-Kreditorenbuchhaltung laufen zwischen 10 und 20 Prozent aller Eingangsrechnungen in eine Ausnahme - Mengenabweichung, Preisdifferenz, fehlender Wareneingang, falsche Bestellreferenz. Gut aufgestellte Enterprise-AP-Teams erreichen nach Tuning der Toleranzregeln Straight-Through-Quoten im hohen zweistelligen Bereich. Die verbleibenden Ausnahmen binden jedoch den Großteil der Arbeitszeit, weil jede Abweichung manuell recherchiert, mit dem Einkauf geklärt und freigegeben werden muss.

Die Realität im Mittelstand und in der Breite der Großunternehmen liegt deutlich darunter. Auch bei laufender Investition in AP-Automation bleibt der Anteil der vollständig ohne menschlichen Eingriff verarbeiteten Rechnungen häufig im niedrigen Drittel des Gesamtvolumens. Die Lücke zwischen Investition und Wirkung entsteht dort, wo Matching-Logik in ERP-Masken steckt, statt als eigener Entscheidungsagent mit klarer Freigabematrix zu laufen.

Für den CFO bedeutet das zwei konkrete Probleme: Skonto-Verluste, weil Rechnungen zu spät freigegeben werden, und unsichere Liquiditätsplanung, weil der Bestand an offenen, ungematchten Rechnungen nicht steuerbar ist.

## Wie der Decision Layer das Matching zerlegt

Der Three-Way-Matching Agent teilt den Prüfvorgang in elf Mikroentscheidungen, die alle regelbasiert sind: Pflichtangaben nach §14 UStG prüfen, Duplikate erkennen, Bestellung zuordnen, Wareneingang zuordnen, Mengen abgleichen, Preise abgleichen, Abweichung gegen Toleranz prüfen, Freigabe nach Matrix routen, Buchungskreis und Kostenstelle zuordnen, Skonto berechnen, Buchungssatz erzeugen. Jeder Schritt ist eine Feldprüfung oder ein numerischer Vergleich. Jede Toleranzschwelle ist konfigurierbar. Jede Routing-Entscheidung folgt einer Betrag-mal-Abweichung-Matrix, die mit der Geschäftsleitung und der Internen Revision abgestimmt ist.

Dieser Zuschnitt ist der Grund, warum der Agent 0 Prozent KI-Anteil trägt. Er trifft keine Ermessensentscheidung, er interpretiert keine Texte, er lernt nichts. Er exekutiert Regeln, die ein Mensch genauso anwenden würde - nur in Millisekunden und ohne Ermüdung. Für den EU AI Act ist der Agent damit irrelevant, für die GoBD-Prüfung ein Standardschritt, und für die Interne Revision ein lückenlos dokumentierter Entscheidungspfad.

## Konkretes Szenario: Industrieholding mit 12.000 Rechnungen pro Monat

Eine Industrieholding mit sechs Werken verarbeitet rund 12.000 Eingangsrechnungen im Monat. Die Ausgangslage: 78 Prozent der Rechnungen matchen auf Anhieb, 22 Prozent landen in der Ausnahmequeue. Die AP-Abteilung mit neun Vollzeitkräften arbeitet primär an diesen Ausnahmen und schafft im Schnitt 140 Klärungen pro Tag. Skonto-Quote: 61 Prozent. Durchschnittliche Durchlaufzeit Rechnungseingang bis Zahlung: 9,4 Tage.

Nach Einführung des Three-Way-Matching Agents mit abgestimmten Toleranzen (2 Prozent Preis, 5 Prozent Menge, gestaffelte Freigabematrix ab 2.500 Euro) verschiebt sich das Bild: Die Straight-Through-Rate steigt auf 88 Prozent, der manuelle Klärbestand sinkt von 2.640 auf 1.440 Rechnungen pro Monat. Die AP-Abteilung bearbeitet nicht mehr Routineabgleiche, sondern nur noch echte Diskrepanzen mit Einkauf und Lieferant. Skonto-Quote: 84 Prozent. Durchlaufzeit: 2,1 Tage. Cash-Wirkung über den ersten Skonto-Effekt: rund 430.000 Euro pro Jahr bei einem Rechnungsvolumen von 380 Millionen Euro.

## Warum dieser Agent der Startkandidat für den Decision Layer ist

Der Three-Way-Matching Agent ist die rationalste Einstiegsentscheidung für einen CFO, weil er vier Eigenschaften gleichzeitig erfüllt, die bei anderen Finanzagenten selten zusammenkommen: hohe Readiness (Daten liegen im ERP), tägliches Volumen (sofort messbar), niedrige Governance-Last (regelbasiert, nicht KI) und hohe ökonomische Wirkung (Skonto, Liquidität, Kapazität).

Zusätzlich legt er die Infrastruktur für alle nachfolgenden Workflow-Agenten. Das Toleranzschwellen-System übernimmt später der Cash-Application-Agent für den Abgleich Zahlungseingang gegen offene Posten. Die Freigabematrix wird zum Standardbaustein für jeden Workflow-Agenten mit betragsbezogener Eskalation. Die Prozessdokumentation liefert den Prüfpfad, an dem sich spätere KI-gestützte Agenten (etwa Invoice-Coding) orientieren.

Wer den Decision Layer in der Finanzorganisation etabliert, beginnt hier - mit einem Agenten, der keine Diskussion mit dem Datenschutzbeauftragten erfordert, keine Trainingsdaten braucht und dessen Wirkung bereits nach der ersten Woche im Skonto-Report sichtbar ist.

--- Verrechnungspreis-Dokumentations-Agent ---
> Erstellt die Transaktionsmatrix, führt Benchmark-Studien durch, berechnet Interquartilsranges und generiert Master File.

Verrechnungspreis-Dokumentation ist der Prozess, bei dem CFOs die teuerste Prüfungsfeststellung ihrer Betriebsprüfung produzieren oder verhindern. Bei der Betriebsprüfung 2024 stellten die Länder ein Mehrergebnis von rund 10,9 Milliarden Euro fest, und TP-Korrekturen gehören systematisch zu den schwersten Einzelpositionen (Quelle: [BMF-Monatsbericht November 2025](https://www.bundesfinanzministerium.de/Monatsberichte/Ausgabe/2025/11/Inhalte/Kapitel-2-Analysen/2-4-steuerliche-betriebspruefung-der-laender-2024.html)). Der [Decision Layer](/de/decision-layer/) zerlegt die Dokumentation in acht klar verantwortete Schritte - so entsteht ein auditfester Prozess, in dem jede Entscheidung begründet ist und jede Zahl einer Quelle zugeordnet werden kann.

## Die Regel: Fremdvergleich, und die Beweislast liegt bei Ihnen

§1 AStG verlangt, dass konzerninterne Preise so vereinbart werden, wie sie zwischen fremden Dritten vereinbart worden wären. Bei Verstößen korrigiert die Finanzverwaltung das Ergebnis nach oben, und bei fehlender oder mangelhafter Dokumentation setzt §162 AO einen Strafzuschlag von mindestens 5 Prozent und bis zu 10 Prozent des Mehrergebnisses an, mindestens 5.000 Euro und bis zu 1 Million Euro. Das Wachstumschancengesetz hat mit §1 Abs. 3d und 3e AStG zusätzlich die Regeln für konzerninterne Finanzierungen verschärft, und die Verwaltungsgrundsätze Verrechnungspreise 2024 vom 12. Dezember 2024 setzen die neuen Anforderungen im Prüferleitfaden um.

Der praktische Fall: Ein Konzern mit deutscher Muttergesellschaft und einer polnischen Produktionstochter liefert Halbfertigware nach Deutschland. Der Verkaufspreis liegt bei 100 Euro pro Stück. Die Betriebsprüfung fordert den Nachweis, dass dieser Preis dem Fremdvergleich entspricht. Fehlt die Dokumentation, schätzt der Prüfer - und zwar systematisch zu Lasten des Unternehmens. Country-by-Country-Reporting greift zusätzlich ab einem Konzernumsatz von 750 Millionen Euro, und Pillar Two betrifft europaweit rund 8.000 Konzerne, davon etwa 800 in Deutschland.

## Der Decision Layer: Acht Schritte, drei Entscheidertypen

Die TP-Dokumentation zerfällt in datenbasierte Arbeit, regelbasierte Rechnung und menschliches Ermessen. Die Transaktionsmatrix entsteht automatisiert aus den IC-Buchungsdaten. Die Benchmark-Studie läuft als strukturierte Datenbankabfrage gegen Amadeus oder Orbis, und die Interquartilsrange ist eine arithmetische Operation ohne Ermessensspielraum. Diese Schritte erledigt der Agent zuverlässig und nachvollziehbar.

Drei Schritte bleiben beim Menschen. Die Funktions- und Risikoanalyse verlangt die qualitative Bewertung der Wertschöpfungskette, weil nur der Steuerabteilungsleiter beurteilen kann, welche Gesellschaft welche Funktion trägt. Die Wahl der TP-Methode zwischen CUP, Resale Price, Cost Plus, TNMM und Profit Split ist eine Auslegungsentscheidung nach OECD-Leitlinien. Die finale Freigabe ist strategisch, weil sie die Verteidigungslinie in der nächsten Betriebsprüfung definiert. Der Agent dokumentiert jeden dieser menschlichen Schritte mit Entscheider, Zeitstempel und Begründung.

Dazwischen steht ein KI-gestützter Schritt: der Erstentwurf von Master File, Local File und CbCR als LLM-Draft auf Basis der vorgelagerten Daten. Der Entwurf ist der Ausgangspunkt für die Überarbeitung durch den Steuerberater, nie das Endergebnis.

## Was der CFO daraus bekommt

Konsistenz zwischen Buchung und Dokumentation. Der Agent gleicht kontinuierlich die in der TP-Dokumentation ausgewiesenen Preise mit den tatsächlichen IC-Buchungen ab. Abweichungen außerhalb der Interquartilsrange eskalieren sofort an den Steuerberater. Damit verschwindet die klassische Lücke, in der die Dokumentation aus dem Vorjahr stammt und die Buchungen längst abweichen.

Verteidigungsfähigkeit in der Betriebsprüfung. Jeder Eintrag in Master File, Local File und CbCR ist mit seiner Datenquelle verknüpft, jede Methodenwahl mit ihrer Begründung, jede Benchmark mit ihrem Datenbank-Snapshot. Der Prüfer bekommt nicht eine fertige Datei, sondern einen reproduzierbaren Prozess. Das ist der Unterschied zwischen Schätzung zu Lasten des Steuerpflichtigen und Anerkennung der dokumentierten Preise.

Planbarer Jahreszyklus. Die Benchmark-Studie wird gemäß OECD-Empfehlung alle drei Jahre vollständig erneuert und in den Zwischenjahren aktualisiert. Der Agent überwacht den Zyklus, meldet Erneuerungsbedarf und liefert dem Steuerberater eine vorbereitete Grundlage statt einer leeren Vorlage.

## Pillar Two verändert die Ausgangslage

Seit 1. Januar 2025 wirkt die globale Mindeststeuer von 15 Prozent parallel zur klassischen Verrechnungspreisprüfung. Für TP-Abteilungen heißt das: Verrechnungspreise müssen nicht nur dem Fremdvergleich standhalten, sondern zusätzlich Pillar-Two-konsistent sein. Eine TP-Korrektur in einem Land kann die effektive Steuerquote in einem anderen Land unter die 15-Prozent-Schwelle drücken und dort eine Nachsteuer auslösen. Der vereinfachte ETR-Test steigt 2026 auf über 16 Prozent, und die TP-Dokumentation muss konsistent zu den GloBE-Daten sein. Der Agent liefert die Struktur, in der beide Systeme aus denselben Primärdaten gespeist werden - das reduziert das Risiko, dass Steuerabteilung und Konzernsteuerfunktion zwei widersprüchliche Zahlenwelten pflegen.

--- Reisekosten-Tax-Agent ---
> Reisekosten-Tax-Berechnung nach EStG §3 Nr. 13/16/50/51, LStR R 9.4-R 9.10 und BMF-Schreiben 25.11.2020: Pauschbeträge Inland/Ausland und EU-Vorsteuer-Erstattung.

Reisekostenabrechnung ist der teuerste regelbasierte Prozess im Finance-Bereich - und genau deshalb der profitabelste Automatisierungshebel. Eine manuell bearbeitete Abrechnung kostet laut GBTA-Benchmark rund 58 USD und durchläuft im Schnitt 8,8 Tage, bis sie gebucht ist. Der Reisekosten-Agent senkt beide Werte um über 70 Prozent, ohne dass eine einzige steuerliche Entscheidung das Haus verlässt.

## Warum manuelle Reisekosten teurer sind als die Reise selbst

Die Regelwerke hinter einer Dienstreise sind vollständig dokumentiert, aber verteilt: BMF-Schreiben vom 5. Dezember 2025 mit den Auslandspauschalen 2026, unveränderte Inlandspauschale von 14 Euro ab 8 Stunden und 28 Euro ab 24 Stunden, Kürzungen nach Paragraf 9 Absatz 4a EStG, Sachbezugswerte, Beleganforderungen nach UStG. Kein einzelner Mitarbeiter beherrscht diese Kombinatorik im Tagesgeschäft.

Die Folge ist bekannt: Mitarbeiter tragen falsche Pauschalen ein, vergessen Mahlzeitenkürzungen, reichen unlesbare Belege ein. Die Buchhaltung korrigiert, fragt nach, wartet auf Antworten. Jede Abrechnung durchläuft drei bis fünf Hände, bevor sie gebucht wird. Bei 2.000 Abrechnungen pro Jahr - einem realistischen Wert für ein Unternehmen mit 500 Mitarbeitern - sind das rechnerisch über 100.000 Euro reine Prozesskosten, zusätzlich zum eigentlichen Reisebudget.

## Was der [Decision Layer](/de/decision-layer/) aus 15 Entscheidungsschritten macht

Der Reisekosten-Agent zerlegt den Prozess in 15 diskrete Entscheidungen. Dreizehn davon sind vollständig regelbasiert: Abwesenheitsdauer berechnen, BMF-Pauschale aus Land und Stunden ableiten, Mahlzeitenkürzung von 20, 40 oder 40 Prozent anwenden, Fahrtkosten nach Kilometerpauschale oder Beleg bestimmen, Belegformalia gegen Paragraf 14 UStG prüfen, Kostenstelle zuordnen, Buchungssatz erstellen. Eine Entscheidung ist agentisch: die Plausibilitätsprüfung gegen historische Vergleichswerte. Genau eine Entscheidung bleibt beim Menschen: die Bewertung unklarer Reiseanlässe, also die Frage, ob eine Reise tatsächlich beruflich veranlasst war.

Diese Verteilung ist kein Zufall, sondern das Ergebnis sauberer steuerrechtlicher Analyse. Regelbasiert läuft alles, was in Paragrafen, Tabellen oder BMF-Schreiben abschließend geregelt ist. Der Mensch entscheidet nur dort, wo Ermessen gefordert ist - und dort mit voller Entscheidungsakte als Grundlage.

## Szenario: Frankfurt nach Madrid, drei Tage, zwei gestellte Mahlzeiten

Ein Projektleiter reist Montag früh von Frankfurt nach Madrid, kommt Mittwoch spät zurück. Am Dienstag nimmt er am Kundenmeeting ein gestelltes Mittagessen wahr, am Mittwoch ein Frühstück im Hotel. Manuell dauert diese Abrechnung typischerweise 25 bis 40 Minuten - inklusive Nachfragen.

Der Agent erledigt sie in unter einer Minute. Er liest Abreise und Rückkehr aus dem Reiseantrag, erkennt drei Abwesenheitstage, zieht die Madrid-Pauschale aus dem BMF-Schreiben 2026 und berechnet 32 Euro für den Anreisetag, 48 Euro für den vollen Tag, 32 Euro für den Abreisetag. Die Mahlzeitenkürzung reduziert den Dienstag um 40 Prozent auf 28,80 Euro und den Mittwoch um 20 Prozent auf 25,60 Euro. Hotelrechnung, Flugticket und Taxiquittungen prüft er auf Pflichtangaben, zieht die Vorsteuer, bucht auf die hinterlegte Kostenstelle. Der Mitarbeiter sieht jede Zeile mit Begründung, jeden Paragrafen, jede BMF-Version. Er kann jede Position anfechten - jede Regel ist dokumentiert, nicht behauptet.

## Was der CFO konkret gewinnt

Vier Effekte schlagen direkt auf die GuV und die Steuerresilienz durch. Erstens sinken die Bearbeitungskosten pro Abrechnung um über 70 Prozent - aus 58 USD werden unter 15 USD. Zweitens sinkt die Durchlaufzeit von 8,8 Tagen auf Stunden, was die Mitarbeiterzufriedenheit messbar erhöht und Rückfragen in der Buchhaltung eliminiert. Drittens schließt der Agent die häufigsten Fehlerquellen in Lohnsteuer-Außenprüfungen: falsche Pauschalen, vergessene Kürzungen, Vorsteuerabzug ohne korrekte Belege. Viertens entsteht eine versionierte BMF-Pauschalen-Engine, die der Bewirtungsbeleg-Agent und der Lohnsteuer-Agent mitnutzen - die Infrastruktur-Investition amortisiert sich dreifach.

Der strategische Punkt für den CFO: Reisekosten sind nicht nur ein Kostenblock, sondern ein Risikoprozess. Jede falsche Pauschale wird bei der nächsten Lohnsteuer-Außenprüfung zum Nachforderungsbescheid. Der Decision Layer macht diesen Prozess nicht nur schneller, sondern prüfungssicher dokumentiert - mit exakter Nachvollziehbarkeit, welche BMF-Version zum Reisezeitpunkt galt.

--- USt-Voranmeldungs-Agent ---
> USt-Voranmeldung §18 UStG via ELSTER: Kennzahlen-Aggregation, §13b Reverse-Charge, Zusammenfassende Meldung §18a mit MIAS-Validierung, Sondervorauszahlung §47 UStDV.

Die USt-Voranmeldung ist in Deutschland zugleich steuerrechtlich, abgabenrechtlich und steuerstrafrechtlich gebunden und gilt als Schlüsselkontrolle des internen Kontrollsystems. Steuerrechtlich gelten die ELSTER-Pflicht, die Zusammenfassende Meldung und die qualifizierte Bestätigung der USt-IdNr.; abgabenrechtlich die Abgabefrist, der Verspätungszuschlag und die Verzinsung. Vier Rechtskreise wirken zusammen - das Umsatzsteuergesetz, die Abgabenordnung, die Umsatzsteuer-Durchführungsverordnung und die EU-Mehrwertsteuersystem-Richtlinie mit dem Datenaustausch über MIAS. Dazu treten die GoBD, die Berichtigungspflicht und die Rechtsprechung des Bundesfinanzhofs. Eine fehlende Übermittlung, eine Inkonsistenz zwischen Buchhaltung und Voranmeldung oder eine fehlende Bestätigung der USt-IdNr. kostet schnell siebenstellige Beträge und kann die Geschäftsführung persönlich haftbar machen.

## Eine mangelhafte USt-Voranmeldung kann siebenstellige Steuermehrbelastungen auslösen

Drei Schadensquellen wirken parallel und kumulieren bei mittelständischen Industrieunternehmen schnell zu siebenstelligen Beträgen pro Geschäftsjahr. Erstens: Verspätungszuschlag nach §152 AO 0,25% der festgesetzten Steuer pro angefangenem Verspätungsmonat, Mindestbetrag 25 EUR, automatische Festsetzung ab 14 Monaten. Bei einer Mittelstandsfirma mit 200 Mio EUR Umsatz, 19% steuerpflichtigem Anteil und durchschnittlicher Voranmeldungs-Zahllast von 600 TEUR pro Monat ergibt ein einmaliger Verspätungszuschlag bei 1 Monat Verzögerung 1.500 EUR pro Voranmeldung - bei systematischer Verspätung über mehrere Monate und nachträglicher Festsetzung schnell 50-100 TEUR zusätzlich plus Säumniszuschlag 1% pro Monat nach §240 AO. Zweitens: USt-Sonderprüfung nach §27b UStG mit BFH-Mehrergebnis 1,63 Milliarden Euro pro Jahr aus den USt-Sonderprüfungen der Länder (Bundesfinanzministerium-Bericht zur Betriebsprüfung 2024). Bei einem Mittelständler mit 200 Mio EUR Umsatz ergibt eine 5%-Hinzuschätzung in der Sonderprüfung 1,9 Mio EUR Nachzahlung plus Verzinsung 0,15% pro Monat nach §233a AO ab 15-monatigem Zinslauf gleich rund 2,5 Mio EUR Gesamtbelastung. Drittens: §15 UStG Vorsteuer-Rückforderung bei §14-Mängeln in Eingangsrechnungen. BFH V R 28/19 hat die Rückwirkende Rechnungsberichtigung für den Vorsteuerabzug anerkannt, sofern die ursprüngliche Rechnung den Mindestpflichtangaben nach §14 UStG genügt - bei vollständig fehlerhaften Rechnungen entfällt der Vorsteuerabzug ersatzlos mit Nachzahlung 19% des Vorsteuerbetrags. Bei jährlichem Vorsteuerabzug von 30 Mio EUR und 5%-Mängelquote ergibt das 1,5 Mio EUR Vorsteuer-Risiko, das nur durch automatische §14/§14a-Validierung vor Buchung vermeidbar ist.

## Die deutsche USt-Voranmeldung besteht aus 14 festen Schritten

Das deutsche Verfahren erfordert 14 Entscheidungen, weil Umsatzsteuergesetz, Durchführungsverordnung, Abgabenordnung, das ELSTER-Schema und der EU-Datenaustausch zusammenwirken. Die Kette reicht von der Aggregation der Buchungsdaten über die Reverse-Charge-Erkennung, die innergemeinschaftlichen Lieferungen mit Zusammenfassender Meldung, die qualifizierte Bestätigung der USt-IdNr., die Vorsteuer-Validierung und die Sondervorauszahlung bis zur Zuordnung der Steuersätze, der Plausibilitätsprüfung, dem Konsistenz-Check, einer etwaigen Berichtigung, der ELSTER-Übermittlung, der Vier-Augen-Mitzeichnung und der GoBD-konformen Festschreibung.

Ein konkretes Szenario: Maschinenbau-Mittelständler mit 200 Mio EUR Umsatz, vier Bankkonten, monatlicher Voranmeldung mit Dauerfristverlängerung nach §46 UStDV (Sondervorauszahlung 660 TEUR aus 1/11 der Vorjahres-Zahllast 7,3 Mio EUR), DATEV USt-Voranmeldung Modul über Steuerberatungs-Kanzlei und 12 EU-Käufer mit innergemeinschaftlichen Lieferungen über 5 Mio EUR pro Quartal. Am 8. Werktag des Folgemonats startet der Agent die Aggregation der Buchungsdaten aus DATEV FiBu, mappt die rund 8.500 Belege auf UStG-Kennzahlen, identifiziert 47 §13b-Reverse-Charge-Vorgänge (überwiegend Bauleistungen vom Generalunternehmer), führt die qualifizierte Bestätigungsabfrage über das BZSt-Portal für alle 12 EU-Käufer durch, validiert die §14/§14a-Pflichtangaben in 1.250 Eingangsrechnungen mit Vorsteuerabzug 1,2 Mio EUR, berechnet die Sondervorauszahlungs-Anrechnung 60 TEUR (1/11 anteilig auf Q4) und führt den FiBu-USt-Konsistenz-Check durch. Im Decision Layer sind 12 der 14 Schritte regelbasierte Entscheidungen (Stufe R), 1 Schritt KI-gestützt mit menschlicher Bestätigungsoption (Stufe A für Plausibilitätsprüfung gegen Vormonat), 1 Schritt menschliche Entscheidung (Stufe H für Vier-Augen-Mitzeichnung bei Plausibilitäts-Eskalation oder hoher Erstattung). Die Trennung ist vor Finanzamt, BZSt und Wirtschaftsprüfer transparent: die ELSTER-Übermittlung erfolgt um 16:00 Uhr am 9. Werktag des Folgemonats mit ELSTER-Transferticket und qualifiziertem Zeitstempel - vor der gesetzlichen Frist 10. Tag des übernächsten Monats mit Dauerfristverlängerung.

## Plausibilitätsprüfung gegen Vormonat und Vorjahres-Periode mit Pattern-Matching

Vor jeder ELSTER-Übermittlung läuft eine zweistufige Plausibilitätsprüfung mit KI-Pattern-Matching gegen historische Vergleichsmuster der letzten 12 Monate. Erstens: Kennzahlen-Plausibilität gegen Vormonat. Jede der 25 UStG-Voranmeldungs-Kennzahlen wird gegen den Vormonats-Wert geprüft mit relativer Abweichung in Prozent; bei Abweichung über 10% Auto-Eskalation an Sachbearbeiter mit Top-3-Erklärungs-Kandidaten (Großauftrag, Storno, Reverse-Charge-Wechsel, Vorsteuer-Klumpen-Zuordnung, Saisonalität). Zweitens: Kennzahlen-Plausibilität gegen Vorjahres-Periode (gleicher Monat des Vorjahres) mit Saisonbereinigung und Geschäftsentwicklungs-Kontext. Pattern-Matching liefert je Kennzahl eine Konfidenz-Bewertung der Abweichung mit Trend-Indikator (Wachstum/Stagnation/Schrumpfung) und ggf. Hinweis auf Sondereffekt (z.B. neue Kundengruppe, Akquisition, Standortwechsel, Steuersatzänderung).

Bei Plausibilitäts-Eskalation wird die ELSTER-Übermittlung blockiert bis zur manuellen Bestätigung durch Head of Finance oder Vier-Augen-Mitzeichnung durch zweiten Sachbearbeiter. Die Klärungshistorie wird Teil des IDW PS 261 IKS-Nachweises mit Eskalations-Dokumentation für den Walk-Through-Test des Wirtschaftsprüfers - eine zu niedrig kalibrierte Schwelle führt zu unnötigen Eskalationen und Verzögerung der ELSTER-Frist, eine zu hoch kalibrierte Schwelle lässt Buchungsfehler durchgehen mit AEAO §175a Berichtigungspflicht und §233a Verzinsung 1,8% p.a.

## Edge-Cases Reverse-Charge §13b, Konsignationslager §6b und Konzernumsatzsteuer-Organschaft §2 Abs. 2 Nr. 2 UStG

Konzerne mit Tochtergesellschaften und Organschaftsstrukturen nach §2 Abs. 2 Nr. 2 UStG (finanzielle, wirtschaftliche und organisatorische Eingliederung) erfordern die Konsolidierung der USt-Voranmeldungen aller Organgesellschaften beim Organträger - der Agent erkennt Organkreise über Stammdaten-Markierung und führt die konsolidierte Voranmeldung mit aggregierten Kennzahlen 81/86/87/41/43/48/60/84/85 durch. Konsignationslager-Regelung nach §6b UStG (eingeführt 2020 zur Vereinfachung des innergemeinschaftlichen Lieferverkehrs nach EU-Quick-Fixes) wird bei Vor-Ort-Lagerung von Waren beim Käufer im EU-Mitgliedstaat angewandt: keine Versendung als innergemeinschaftliche Lieferung sondern als steuerfreie Verbringung mit erst späterer Lieferung bei Entnahme aus Lager - der Agent verfolgt Lager-Bewegungen und löst die ZM-Meldung erst bei Entnahme aus mit BFH V R 17/22 Auslegungsregeln.

Reverse-Charge nach §13b UStG erfasst sieben Tatbestände mit unterschiedlichen Klassifikations-Kriterien: §13b Abs. 2 Nr. 1 sonstige Leistungen ausländischer Unternehmer (B2B-Empfängerortprinzip nach §3a Abs. 2), Nr. 2 Werklieferungen ausländischer Unternehmer im Inland, Nr. 3 sicherungsübereignete Gegenstände außerhalb Insolvenzverfahren, Nr. 4 Bauleistungen im Bau-im-Bau-Verfahren mit §48b-Freistellungsbescheinigung, Nr. 5 Gas-/Strom-Lieferungen über deutsches Verbund-/Verteilernetz, Nr. 7 Schrott-Lieferungen nach Anlage 3 UStG und Nr. 11 Lieferungen von Industrieschrott und Altmetall. Der Agent klassifiziert anhand von Lieferanten-Land, Branchen-Code (NACE), Produktgruppe und Kunden-Klassifikation. Bei Fehler im Reverse-Charge-Mapping (z.B. fehlerhafte Bauleister-Klassifikation) entsteht §15 UStG-Vorsteuerausschluss mit Nachzahlung in der USt-Sonderprüfung.

## Integration mit DATEV, SAP, Wolters Kluwer und ELSTER-Schnittstellen schließt die Tax-Compliance-Kette

Der Agent verbindet sich über Schnittstellen mit den führenden deutschen Tax-Compliance- und ERP-Systemen - darunter das [DATEV](https://www.datev.de/) USt-Voranmeldung-Modul, SAP S/4HANA mit Tax Reporting, Dynamics 365 mit Avalara, Vertex oder Sovos, Sage, Lexware, Diamant/4 und ADDISON. Für den Wirtschaftsprüfer liefert er die Decision-Log-Exporte mit Wirksamkeitsnachweis, für die USt-Sonderprüfung die Datenträgerüberlassung. Die Übermittlung läuft über ELSTER mit Zertifikat oder Online-Portal, den qualifizierten Zeitstempel stellen BSI-zertifizierte Trust-Service-Provider bereit. Für Konzerne mit Auslandstöchtern erzeugt der Agent zusätzlich den Datenaustausch mit den anderen EU-Staaten; das deutsche Verfahren bleibt dabei umsatzsteuer- und GoBD-konform.

--- Lieferanten-Onboarding-Agent ---
> Extrahiert Stammdaten aus Lieferanten-Selbstauskunft, validiert USt-ID über EU VIES, prüft Sanktionslisten, bewertet Risiken und legt den Lieferanten im ERP.

Jeder neue Lieferant ist ein Risiko-Einstiegspunkt in den Kreditorenstamm. Wer dort ungeprüft anlegt, potenziert den Fehler in jeder Folgebuchung - von der Vorsteuer bis zum Zahlungslauf. Der Lieferanten-Onboarding-Agent macht die Prüfung zum Pflichtschritt, bevor die erste Rechnung im System landet.

## Das Problem liegt nicht im Onboarding, sondern im Blindflug danach

Die meisten Finance-Organisationen prüfen neue Lieferanten beim Erstanlegen. Danach folgt der Blindflug. Während ein Großteil der Unternehmen Stammdaten beim Onboarding kontrolliert, sinkt der Anteil der systematischen Prüfung vor dem Zahlungslauf drastisch. Genau in dieser Lücke operieren Vendor-Impersonation-Angriffe: Eine geänderte Bankverbindung, ein abgelaufener Sanktionslisteneintrag, eine ungültige USt-ID - und das Geld fließt auf das falsche Konto oder der Vorsteuerabzug fällt in der nächsten Prüfung.

Dazu kommt der strukturelle Datenfehler. Viele Procurement-Verantwortliche haben keinen klaren Überblick über das gesamte Lieferanten-Netzwerk ihrer Organisation, Purchase-to-Pay-Teams berichten regelmäßig von fehlender End-to-End-Ausrichtung und fehlender Ownership für Stammdaten. Wer so ins Rennen geht, findet Dubletten, alte Bankverbindungen und nicht nachvollziehbare Risikoprofile erst dann, wenn der Schaden schon gebucht ist.

## Ein Szenario, das CFOs kennen

Ein mittelständischer Chemie-Hersteller wird von einem neuen Rohstoff-Lieferanten aus Osteuropa kontaktiert. Erstauftrag: 240.000 Euro. Die Einkaufsabteilung sendet die Selbstauskunft an die Buchhaltung, dort wird der Lieferant angelegt. Zwei Wochen später trifft die erste Rechnung ein, wird bezahlt. Drei Monate später stellt der interne Revisor fest: Die USt-ID war von Beginn an ungültig. Der Vorsteuerabzug muss rückgängig gemacht werden, die Betriebsprüfung stellt zusätzlich die Frage nach der Sorgfaltspflicht. Gleichzeitig taucht der Lieferant in einer aktualisierten Sanktionsliste auf - der Compliance-Beauftragte hat keinen Prozess, um bestehende Stammdaten gegen Listen-Updates zu prüfen.

Mit dem Lieferanten-Onboarding-Agent wird dieser Fall vor der ersten Zahlung gestoppt. Die EU-VIES-Validierung erkennt die ungültige USt-ID in Sekunden. Die Sanktionslistenprüfung gegen EU-, OFAC- und UN-Listen läuft automatisch und wird bei jeder Listen-Aktualisierung auf den Bestand angewendet. Die Bankverbindung wird algorithmisch geprüft, der Duplikat-Check schützt vor versehentlicher Doppelanlage, und das Risiko-Scoring kombiniert Branche, Land und Bonitätsdaten zu einer Kennzahl, die der Mensch freigeben muss, wenn sie den Schwellenwert überschreitet.

## Wie der [Decision Layer](/de/decision-layer/) den Prozess zerlegt

Der Agent bildet neun Entscheidungsschritte ab, jeder mit klarer Zuordnung zu Regel, KI oder Mensch. Stammdatenextraktion aus der Selbstauskunft und das Auslesen von Zahlungsbedingungen aus Verträgen nutzen LLM-basierte Dokumentenverarbeitung. USt-ID-Validierung, Sanktions-Screening, IBAN-Prüfung, Duplikat-Abgleich und ERP-Anlage laufen regelbasiert über API-Integrationen. Die Risikobewertung ist ein Hybrid: regelbasierte Faktoren kombiniert mit KI-Scoring. Nur eine Entscheidung bleibt beim Menschen - die Freigabe bei erhöhtem Risiko-Score. Dort, wo Ermessen gebraucht wird, entscheidet der Compliance-Beauftragte, dokumentiert in der Audit-Trail.

## Was der Agent dem CFO liefert

Der betriebswirtschaftliche Effekt ist doppelt. Erstens verschwindet die strukturelle Schwachstelle: Jeder Lieferant ist validiert, bevor die erste Rechnung verbucht wird. Zweitens entsteht die Grundlage, auf der weitere Finance-Agenten aufbauen. Die USt-ID-Validierung wird vom Rechnungseingangs-Agent und vom Quellensteuer-Agent wiederverwendet. Die Sanktionslistenprüfung speist den Zahlungslauf-Agent. Das Risiko-Scoring-Pattern bildet die Vorlage für den Fraud-Detection-Agent. Einmal aufgebaut, zahlt die Infrastruktur auf mehrere Prozesse gleichzeitig ein.

Für den CFO bedeutet das: belastbare Due-Diligence-Dokumentation für die Betriebsprüfung, reduzierte Vendor-Fraud-Exposition und ein Kreditorenstamm, dem der Zahlungslauf vertrauen kann. Ab dem 22. Juni 2026 greifen auch die erweiterten Nacha-Regeln zur ACH-Betrugsüberwachung - wer heute eine saubere Validierungs-Infrastruktur aufbaut, erfüllt diese Anforderungen, ohne nachrüsten zu müssen.

--- Quellensteuer-Agent ---
> Quellensteuer ohne Lohnsteuer: KapSt §43-§45 EStG (Zinsen, Dividenden), Bauabzugsteuer §48-§48d EStG, §50a EStG (Ausländer-Honorare) und DBA-Entlastung BZSt §50d EStG.

Die Quellensteuer ist in Deutschland zugleich steuerrechtlich, abgabenrechtlich und steuerstrafrechtlich gebunden und gilt als Schlüsselkontrolle des internen Kontrollsystems. Steuerrechtlich gelten die Lohnsteuer mit ELStAM-Abruf, die Kapitalertragsteuer mit Solidaritätszuschlag und Kirchensteuer, die Bauabzugsteuer mit Freistellungsbescheinigung und der Steuerabzug nach §50a EStG mit 15 oder 30 Prozent; abgabenrechtlich die Abgabefrist, der Verspätungszuschlag, die Verzinsung und die Haftung. Vier Rechtskreise wirken zusammen - das Einkommensteuergesetz, die Abgabenordnung, die Datenbank der über 90 Doppelbesteuerungsabkommen und die EU-Mindestbesteuerungsrichtlinie. Dazu treten die GoBD, mehrere BMF-Schreiben und die Rechtsprechung des Bundesfinanzhofs zu Treaty-Shopping, zur §50a-Einordnung, zur Bauabzugsteuer und zur Arbeitgeber-Haftung.

## Eine mangelhafte Quellensteuer-Erfüllung kann siebenstellige Steuermehrbelastungen auslösen

Drei Schadensquellen wirken parallel und kumulieren bei mittelständischen Unternehmen schnell zu siebenstelligen Beträgen pro Geschäftsjahr. Erstens: BZSt-Versagung der DBA-Entlastung nach §50d EStG bei §50c oder §50d Abs. 3 Anti-Treaty-Shopping-Verdacht. Bei einem Konzern mit 30 Mio EUR Lizenzzahlungen pro Jahr an US-Software-Anbieter und 10%-Mängelquote in der Substanz-Validierung der Lizenz-IP-Holdinggesellschaft greift die Anwendung des nationalen Satzes 15% statt reduziertem DBA-Satz 0%, ergibt 450.000 EUR Quellensteuer-Risiko mit nachträglicher Erstattung erst nach 6-12 Monaten Bearbeitung. Zweitens: AO §152 Verspätungszuschlag 0,25% pro Monat bei verspäteter ELSTER-Anmeldung nach §41a/§44/§48d EStG. Bei einem Mittelständler mit 1.500 Mitarbeitern und 800.000 EUR durchschnittlicher Lohnsteuer-Anmeldung pro Monat ergibt ein einmaliger Verspätungszuschlag 2.000 EUR, bei systematischer Verspätung schnell 50-100 TEUR pro Jahr plus Säumniszuschlag 1% pro Monat nach §240 AO. Drittens: Haftungsbescheid §42d EStG mit persönlicher Arbeitgeber-Haftung als Gesamtschuldner für nicht ordnungsmäßig einbehaltene Lohnsteuer. Bei einer Lohnsteuer-Außenprüfung mit typischer Nachzahlungs-Quote 0,1-0,5% des Gehaltsvolumens ergibt das bei 50 Mio EUR Lohnsumme 50.000-250.000 EUR Nachzahlung pro Prüfungszeitraum (3-5 Jahre) plus Verzinsung 0,15% pro Monat nach §233a AO ab 15-monatigem Zinslauf. Bei Vorsatz greift §370 AO Steuerhinterziehung mit Freiheitsstrafe bis 10 Jahren plus persönliche Geschäftsführerhaftung nach §69 AO und §43 GmbHG.

## Die deutsche Quellensteuer besteht aus 14 festen Schritten

Das deutsche Verfahren erfordert 14 Entscheidungen, weil Einkommensteuergesetz, Abgabenordnung, die Datenbank der Doppelbesteuerungsabkommen und das ELSTER-Schema zusammenwirken. Die Kette reicht von der Einordnung des Tatbestands über den ELStAM-Abruf, die Lohnsteuer, die Kapitalertragsteuer und die Bauabzugsteuer mit Freistellungsbescheinigung bis zum Steuerabzug nach §50a EStG, der DBA-Anwendbarkeit, dem Substanz-Test, der Steuerbetrag-Berechnung, der ELSTER-Übermittlung, der Plausibilitätsprüfung, der Sonderfall-Eskalation und der GoBD-konformen Steuerbescheinigung.

Ein konkretes Szenario: Maschinenbau-Mittelständler mit 200 Mio EUR Umsatz, 1.500 Mitarbeitern (50 Mio EUR Lohnsumme), 30 Mio EUR Software-Lizenzzahlungen an US-IP-Holding pro Jahr, 80 Mio EUR Bauinvestitionen mit 30 Bauleistern und 20 ausländischen Aufsichtsräten. Am 5. Werktag des Folgemonats startet der Agent die Tatbestands-Klassifikation für rund 1.500 Quellensteuer-Vorgänge des Vormonats: 1.500 Lohnsteuer-Berechnungen mit ELStAM-Abruf, 30 Bauabzugsteuer-Vorgänge mit BZSt-Freistellungsbescheinigungs-Validierung, 12 §50a-Vorgänge mit Aufsichtsrats-Vergütungen (30%-Satz) und 8 §50a-Vorgänge mit Software-Lizenzen (15% national bzw. 0% DBA-reduziert mit BZSt-Entlastung). Im Decision Layer sind 12 der 14 Schritte regelbasierte Entscheidungen (Stufe R), 2 Schritte KI-gestützt mit menschlicher Bestätigungsoption (Stufe A für Tatbestands-Klassifikation und Anti-Treaty-Shopping-Substanz-Test), 1 Schritt menschliche Entscheidung (Stufe H für Sonderfälle-Eskalation an Steuerberater). Die Trennung ist vor Finanzamt, BZSt und Wirtschaftsprüfer transparent: die ELSTER-Übermittlung erfolgt um 16:00 Uhr am 8. Werktag des Folgemonats mit ELSTER-Transferticket und qualifiziertem Zeitstempel - vor der gesetzlichen Frist 10. Tag des Folgemonats.

## Plausibilitätsprüfung gegen Vormonat und Vorjahres-Periode mit Pattern-Matching

Vor jeder ELSTER-Übermittlung läuft eine zweistufige Plausibilitätsprüfung mit KI-Pattern-Matching gegen historische Vergleichsmuster. Erstens: Quellensteuer-Beträge gegen Vormonat. Lohnsteuer-Sprung über 10% wird mit Top-3-Erklärungs-Kandidaten begründet (neue Mitarbeiter, Lohnerhöhung, Sondervergütung wie Bonus oder 13. Gehalt, Steuerklassenwechsel durch Heirat oder Trennung, Kirchensteuer-Eintritt/Austritt). Zweitens: Quellensteuer-Beträge gegen Vorjahres-Periode (gleicher Monat des Vorjahres) mit Saisonbereinigung (z.B. Weihnachtsgeld im November, Urlaubsgeld im Juni). Pattern-Matching liefert je Tatbestand eine Konfidenz-Bewertung mit Trend-Indikator und ggf. Hinweis auf Sondereffekt. Bei Plausibilitäts-Eskalation wird die ELSTER-Übermittlung blockiert bis zur Vier-Augen-Mitzeichnung durch zweiten Sachbearbeiter oder Head of Finance. Die Klärungshistorie wird Teil des IDW PS 261 IKS-Nachweises mit Eskalations-Dokumentation für den Walk-Through-Test des Wirtschaftsprüfers.

## Edge-Cases Dreiecksverhältnis, Konzern-Lizenzen und gemischte §50a-Verträge

Konzerne mit ausländischen Lizenz-IP-Holdings (typischerweise Irland, Niederlande, Luxemburg) erfordern §50c und §50d Abs. 3 Anti-Treaty-Shopping-Substanz-Test mit Indikatoren-Bewertung: Gesellschaftssitz im DBA-Staat aber tatsächliche Geschäftsleitung in Drittstaat, fehlendes qualifiziertes Personal, fehlende eigene Geschäftsräume, geringe Wertschöpfungstiefe, kurze Beteiligungsdauer. BFH I R 51/20 hat den Substanz-Test mit Beweislast beim Vergütungsgläubiger bestätigt. Dreiecksverhältnis (Vergütungsschuldner DE, Zwischengesellschaft EU mit DBA, Endempfänger Drittstaat ohne DBA) wird vom Agent mit KI-Pattern-Matching erkannt und an den Steuerberater eskaliert.

Gemischte Verträge aus einer Lizenz und einer Beratungs-Komponente erfordern eine Aufteilung der Bemessungsgrundlage: Der Lizenz-Anteil unterliegt §50a EStG mit 15 Prozent oder dem reduzierten DBA-Satz, der Beratungs-Anteil dagegen keiner Quellensteuer, sondern der Veranlagung des ausländischen Beraters. Der Bundesfinanzhof hat die Abgrenzung anhand des überwiegenden Vertragszwecks, der getrennten Vergütungsangabe und eines eigenständigen Werkvertrags geklärt. Bei Unklarheit eskaliert der Agent zur juristischen Bewertung an den Steuerberater. Für Dividenden ausländischer Gesellschafter ohne deutsche Veranlagung gilt eine Definitivbesteuerung von 15 Prozent.

## Integration mit DATEV LODAS, SAP HCM, BZSt-Online-Portal und ELSTER-Schnittstellen schließt die Tax-Compliance-Kette

Der Agent verbindet sich über Schnittstellen mit den führenden deutschen Lohnabrechnungs- und ERP-Systemen - darunter [DATEV LODAS](https://www.datev.de/), SAP HCM, Sage Lohn Plus, Personio, Lexware und ADDISON. Mit dem Bundeszentralamt arbeitet er über das BZSt-Online-Portal für den ELStAM-Abruf, die Freistellungs- und die Entlastungsbescheinigung. Für den Wirtschaftsprüfer liefert er die Decision-Log-Exporte mit Wirksamkeitsnachweis, für die Lohnsteuer-Außenprüfung die Datenträgerüberlassung. Die Übermittlung läuft über ELSTER mit Zertifikat oder Online-Portal, den qualifizierten Zeitstempel stellen BSI-zertifizierte Trust-Service-Provider bereit. Für Konzerne mit Auslandstöchtern führt der Agent die DBA-Entlastung mit den jeweiligen Vertragsstaaten durch; das deutsche Verfahren bleibt dabei steuer- und GoBD-konform.

--- Finance Agent - Belegverarbeitung & Buchführung ---
> Finance Agent mit Decision Layer: Belegverarbeitung, Kontierung, AfA-Logik. Versionierte Regelwerke, Audit Trail, DATEV/SAP-Integration.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/de/warum-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Jede Entscheidung nachvollziehbar</p>
</div>
</a>
<a href="/de/warum-gosign/#infrastruktur" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Ihre Infrastruktur</p>
<p class="text-xs text-gosign-text-light">Kein SaaS. Kein Vendor-Lock-in.</p>
</div>
</a>
<a href="/de/warum-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Kein US-Cloud-Risiko</p>
</div>
</a>
</div>
</div>
</div>

<div class="not-prose my-8 bg-gosign-dark rounded-card p-6 sm:p-8">
<div class="flex flex-col sm:flex-row sm:items-center gap-4">
<div class="flex-1">
<p class="text-h3 font-bold text-white mb-2">Kostenloses eBook: KI in Finance</p>
<p class="text-body text-white/80">Compliance, Wirtschaftsprüfer und Decision Layer - das Governance-Handbuch für Finance-Verantwortliche.</p>
</div>
<a href="/de/ebook/ki-finance-governance-handbuch/" class="inline-flex items-center gap-2 px-6 py-3 bg-gosign-accent-btn text-white font-semibold rounded-lg hover:bg-gosign-accent-btn-hover transition-colors whitespace-nowrap">Jetzt herunterladen</a>
</div>
</div>

<!-- Das Problem -->
<section class="py-section bg-gosign-white"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow"><h2 class="text-h1 font-bold text-gosign-dark">Das Problem</h2><p class="text-body-lg text-gosign-text-light mt-4">In der Belegverarbeitung treffen Menschen täglich Hunderte Mikro-Entscheidungen: Kontierung, Kostenstelle, AfA-Beginn, Vorsteuerabzug, Aufwandsklassifizierung. Jede Entscheidung basiert auf einem Regelwerk - Steuergesetzgebung, Rechnungslegungsstandards, interne Richtlinien, mandantenspezifische Besonderheiten.</p><p class="text-body-lg text-gosign-text-light mt-4">Das Problem ist nicht mangelndes Fachwissen. Das Problem ist Inkonsistenz: verschiedene Sachbearbeiter wenden dasselbe Regelwerk unterschiedlich an. Mehr Mandanten, mehr Standorte, mehr Personal - größere Varianz. Die Folgen: Korrekturbuchungen, Prüfungsfeststellungen, Regelwerke die nur in den Köpfen einzelner Mitarbeiter existieren.</p><p class="text-body-lg text-gosign-text-light mt-4">Diese Inkonsistenz erhöht nicht nur Korrekturbuchungen, sondern auch Prüfungsaufwand, Abstimmungsschleifen und das Risiko von Beanstandungen durch interne Revision oder externe Prüfer. Der Decision Layer verlagert diese Risiken von individueller Interpretation in eine versionierte, nachvollziehbare Entscheidungsarchitektur.</p></div></div></section>

<!-- Definition -->
<section class="py-section bg-gosign-light"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow"><h2 class="text-h1 font-bold text-gosign-dark">Was ist ein Finance Agent?</h2><p class="text-body-lg text-gosign-text-light mt-4">Ein Finance Agent ist ein spezialisierter AI-Agent für Belegverarbeitung und Buchführung. Er liest Belege mit kontextuellem Sprachverständnis, bewertet sie fachlich gegen versionierte Regelwerke (Steuerrecht, GoB, GoBD, interne Richtlinien) und erzeugt dokumentierte Buchungsvorschläge. Der <a href="/de/decision-layer/" class="text-gosign-accent-text hover:text-gosign-accent-hover">Decision Layer</a> routet jede Mikroentscheidung: autonom bei hoher Confidence und klarer Regel, an einen Sachbearbeiter bei Ausnahmefällen.</p><p class="text-body-lg text-gosign-text-light mt-4">DATEV und SAP bleiben Ihre führenden Systeme. Der Finance Agent sitzt davor - er liefert entscheidungsfertige Outputs inklusive lückenloser Begründungskette. Jede Entscheidung erzeugt eine vollständige Entscheidungsakte: Input, angewandte Regel, Regelversion, Confidence, Entscheidungspfad, Ergebnis. Das ist keine nachträgliche Dokumentation - es ist der technische Beweis der Entscheidungsfindung.</p></div></div></section>

<!-- Use Cases -->
<section class="py-section bg-gosign-white"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><h2 class="text-h1 font-bold text-gosign-dark mb-8">Drei Finance Use Cases</h2><div class="grid grid-cols-1 md:grid-cols-3 gap-6"><div class="border border-gosign-border rounded-card p-6 bg-gosign-white"><h3 class="text-h3 font-bold text-gosign-dark">Belegverarbeitung & Kontierung</h3><p class="text-body text-gosign-text-light mt-2">Automatisierte Verarbeitung eingehender Belege bis zum Buchungsvorschlag. Der Agent liest, versteht und kontiert - basierend auf versionierten Regelwerken. Jeder Buchungsvorschlag mit vollständigem Entscheidungspfad.</p></div><div class="border border-gosign-border rounded-card p-6 bg-gosign-white"><h3 class="text-h3 font-bold text-gosign-dark">Prüfungsvorbereitung & Dokumentation</h3><p class="text-body text-gosign-text-light mt-2">Vollständige Entscheidungsdokumentation für jede Buchung. Auditor Portal mit Drill-Down von der Buchung bis zur angewandten Regel. Cert-Ready by Design - Kontrollen als technische Datenobjekte.</p></div><div class="border border-gosign-border rounded-card p-6 bg-gosign-white"><h3 class="text-h3 font-bold text-gosign-dark">Mandantenübergreifende Konsistenz</h3><p class="text-body text-gosign-text-light mt-2">Gleiche Regelwerke, mandantenspezifisch parametrisiert. Der Agent wendet für jeden Mandanten die korrekten Regeln in der aktuellen Version an - konsistent über alle Bearbeiter hinweg.</p></div></div></div></section>

<!-- Vier Schritte -->
<section class="py-section bg-gosign-light"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow"><h2 class="text-h1 font-bold text-gosign-dark">Vier Schritte: Vom Beleg zur prüfungssicheren Buchung</h2><p class="text-body-lg text-gosign-text-light mt-4"><strong>1. Lesen und Verstehen</strong> - Der Agent liest den Beleg mit kontextuellem Sprachverständnis. Rechnungssteller, Betrag, Leistungsbeschreibung, steuerrelevante Merkmale. Keine starre Template-Erkennung - echtes Dokumentenverständnis.</p><p class="text-body-lg text-gosign-text-light mt-4"><strong>2. Fachlich bewerten</strong> - Sachkonto, Kostenstelle, Steuerklassifikation, AfA-Beginn, Bewirtungsbeleg-Kriterien. Jede Bewertung basiert auf einem versionierten Regelwerk - nicht auf dem Erfahrungswissen einzelner Buchhalter.</p><p class="text-body-lg text-gosign-text-light mt-4"><strong>3. Entscheiden</strong> - Der Decision Layer routet: autonom bei hoher Confidence und klarer Regel, an einen Sachbearbeiter bei Ausnahmefällen oder niedriger Confidence. Die Schwellenwerte definieren Sie - nicht die KI.</p><p class="text-body-lg text-gosign-text-light mt-4"><strong>4. Dokumentieren</strong> - Jede Mikroentscheidung erzeugt eine Entscheidungsakte: Input, angewandte Regel, Regelversion, Confidence, Entscheidungspfad, Ergebnis, Zeitstempel. Das ist keine nachträgliche Dokumentation - es ist der technische Beweis der Entscheidungsfindung.</p></div></div></section>

<!-- Decision Layer -->
<section class="py-section bg-gosign-white"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow"><h2 class="text-h1 font-bold text-gosign-dark"><a href="/de/decision-layer/" class="text-gosign-dark hover:text-gosign-accent-on-dark transition-colors">Decision Layer</a></h2><p class="text-body-lg text-gosign-text-light mt-4">Der <a href="/de/decision-layer/" class="text-gosign-accent-text hover:text-gosign-accent-hover">Decision Layer</a> zerlegt den Buchungsprozess in einzelne Entscheidungsschritte. Für jeden Schritt ist definiert: Entscheidet der Agent, ein Regelwerk oder ein Sachbearbeiter?</p><div class="mt-8 bg-gosign-dark rounded-card p-6 sm:p-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-4">Eingangsbeleg → Agent extrahiert → Decision Layer zerlegt in Schritte</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-4">
<div class="bg-white/5 rounded-card p-4">
<p class="text-xs font-bold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Regelwerk</p>
<p class="text-small text-white/90 font-semibold">Eindeutige Fälle</p>
<p class="text-small text-white/60 mt-2">Steuersatz lt. BMF-Schreiben. Deterministische Berechnung.</p>
</div>
<div class="bg-white/5 rounded-card p-4">
<p class="text-xs font-bold uppercase tracking-wider text-gosign-accent-on-dark mb-2">KI-Agent</p>
<p class="text-small text-white/90 font-semibold">Konfidenz-Entscheidung</p>
<p class="text-small text-white/60 mt-2">Kontovorschlag mit Score. Ab Schwellenwert autonom.</p>
</div>
<div class="bg-white/5 rounded-card p-4">
<p class="text-xs font-bold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Mensch</p>
<p class="text-small text-white/90 font-semibold">Ausnahme</p>
<p class="text-small text-white/60 mt-2">Sachbearbeiter prüft und entscheidet mit Kontext.</p>
</div>
</div>
<p class="text-xs text-white/60 mt-4 text-center">Audit Trail pro Schritt: Regel · Version · Entscheider</p>
</div><p class="text-body-lg text-gosign-text-light mt-6">Jeder Schritt basiert auf versionierten Regelwerken. Wenn sich ein Regelwerk ändert - neues BMF-Schreiben, geänderte AfA-Tabelle, neue Steuergesetzgebung - entsteht eine neue Version. Die alte Version bleibt im System. Bei einer Prüfung ist nachvollziehbar, welche Regel in welcher Version zum Entscheidungszeitpunkt galt.</p><p class="text-body text-gosign-text-light mt-4">Wie Kostenmodelle für Enterprise-KI aussehen und was Self-Hosting vs. Cloud wirklich kostet, zeigt der <a href="/de/magazin/ki-kosten-tco-vergleich/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">TCO-Vergleich im Blueprint 2026</a>.</p></div></div></section>

<!-- Cert-Ready -->
<section class="py-section bg-gosign-light"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow"><h2 class="text-h1 font-bold text-gosign-dark">Cert-Ready by Design</h2><p class="text-body-lg text-gosign-text-light mt-4"><strong>Auditor Portal:</strong> Prüfer sehen den Live-Status aller Kontrollen - Ampel-Dashboard mit Drill-Down bis zur konkreten Regelimplementierung.</p><p class="text-body-lg text-gosign-text-light mt-4"><strong>Entscheidungsdatensatz pro Beleg:</strong> Nicht nur das Ergebnis wird gespeichert, sondern der vollständige Entscheidungspfad.</p><p class="text-body-lg text-gosign-text-light mt-4"><strong>Framework-Mapping:</strong> Kontrollen gemappt auf ISA, PS 951, IDW, GoB/GoBD.</p><h3 class="text-h3 font-bold text-gosign-dark mt-8">Control Object Structure</h3><div class="mt-4 overflow-x-auto"><table class="w-full text-body text-gosign-text-light border-collapse"><thead><tr class="border-b-2 border-gosign-border"><th class="text-left py-2 pr-4 font-bold text-gosign-dark">Element</th><th class="text-left py-2 font-bold text-gosign-dark">Funktion</th></tr></thead><tbody><tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-mono text-small">Control_ID</td><td class="py-2">Eindeutige Identifikation der Kontrolle</td></tr><tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-mono text-small">Technical_Implementation</td><td class="py-2">Konkrete technische Umsetzung (z. B. RLS-Policy, API-Check)</td></tr><tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-mono text-small">Rule_Version</td><td class="py-2">Version der zugrunde liegenden Entscheidungslogik</td></tr><tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-mono text-small">Evidence_Generator</td><td class="py-2">Automatischer Prüfmechanismus</td></tr><tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-mono text-small">Evidence_History</td><td class="py-2">Historie der Prüfergebnisse mit Zeitstempel</td></tr><tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-mono text-small">Auditor_View</td><td class="py-2">Drill-down-fähige Darstellung bis zur Implementierung</td></tr></tbody></table></div><p class="text-body-lg text-gosign-text-light mt-4">Controls sind First-Class-Datenobjekte. Evidence wird automatisch erzeugt. Der Prüfer sieht Live-Status statt Snapshot.</p><p class="text-body-lg text-gosign-text-light mt-6"><a href="/de/governance/cert-ready/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Cert-Ready by Design im Detail</a></p></div></div></section>

<!-- Haftung -->
<section class="py-section bg-gosign-white"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow"><h2 class="text-h1 font-bold text-gosign-dark">Haftung und Entscheidungssicherheit</h2><p class="text-body-lg text-gosign-text-light mt-4">In der Buchhaltung gibt es drei Fehlerquellen, die Haftungsrisiken erzeugen. Keine davon ist böswillig. Alle drei sind menschlich. Und alle drei lassen sich strukturell eliminieren.</p><h3 class="text-h3 font-bold text-gosign-dark mt-8">Flüchtigkeitsfehler</h3><p class="text-body-lg text-gosign-text-light mt-3">Falsches Sachkonto, vertauschte Dezimalstelle, Kostenstelle vom letzten Mandanten. Montag früh, Freitag spät, Ende des Quartals. Sachbearbeiter machen diese Fehler nicht aus Unwissen, sondern aus Erschöpfung und Routine. Der Finance Agent kennt keine Müdigkeit. Er wendet Regeln deterministisch an. Jede Buchung, jedes Mal, gleiche Präzision.</p><h3 class="text-h3 font-bold text-gosign-dark mt-8">Unwissenheitsfehler</h3><p class="text-body-lg text-gosign-text-light mt-3">Niemand kennt jede Sonderregelung. Ein erfahrener Buchhalter weiß viel, aber nicht alles. Der Bewirtungsbeleg mit ausländischer Vorsteuer, die Sonderabschreibung für digitale Wirtschaftsgüter, die Kleinbetragsregelung bei Reisekosten. Der Finance Agent arbeitet gegen das vollständige Regelwerk. Er wendet nicht an, was er erinnert, sondern was dokumentiert ist. Kein Regelwerk wird übersehen, weil es nie gelernt wurde.</p><h3 class="text-h3 font-bold text-gosign-dark mt-8">Aktualitätsfehler</h3><p class="text-body-lg text-gosign-text-light mt-3">Steuerrecht ändert sich. Abschreibungstabellen werden angepasst. Schwellenwerte steigen. Neue Pauschalen gelten. Der Sachbearbeiter wendet die Regel an, die er gelernt hat. Der Finance Agent wendet die Regel an, die aktuell gilt. Regelwerke werden zentral versioniert. Ab dem Zeitpunkt der Aktivierung einer neuen Version verwendet jede Buchung automatisch das aktuelle Recht. Kein Rundschreiben, das überlesen wird. Keine Fortbildung, die verpasst wird.</p><h3 class="text-h3 font-bold text-gosign-dark mt-8">Was das für die Haftung bedeutet</h3><p class="text-body-lg text-gosign-text-light mt-3">Jede Agenten-Entscheidung dokumentiert die exakte Regelversion, die zum Entscheidungszeitpunkt galt. Bei einer Betriebsprüfung ist nicht nur nachvollziehbar, was entschieden wurde, sondern auf welcher Rechtsgrundlage. Wenn ein Fehler passiert, liegt er in der Regel, nicht in der Anwendung. Und Regelfehler sind lokalisierbar, korrigierbar und versioniert.</p><p class="text-body-lg text-gosign-text-light mt-4">Für CFOs und Kanzleiinhaber heißt das: nachweisbare Sorgfalt in jedem einzelnen Buchungsvorgang. Nicht als Versprechen, sondern als technischer Beweis im Audit Trail.</p></div></div></section>

<!-- Integration -->
<section class="py-section bg-gosign-light"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow"><h2 class="text-h1 font-bold text-gosign-dark">Integration</h2><p class="text-body-lg text-gosign-text-light mt-4"><strong><a href="https://www.datev.de/" target="_blank" rel="noopener noreferrer">DATEV</a>:</strong> Buchungsvorschläge im DATEV-Format. SKR03 und SKR04. Mandantenspezifische Kontenpläne.</p><p class="text-body-lg text-gosign-text-light mt-4"><strong><a href="https://www.sap.com/products/erp/s4hana.html" target="_blank" rel="noopener noreferrer">SAP FI/CO</a>:</strong> Vorschläge im SAP-Format. Kostenstellen- und Profit-Center-Logik. Integration via SAP RFC oder REST API.</p><p class="text-body-lg text-gosign-text-light mt-4"><strong>finAPI / Banking:</strong> Automatische Kontoauszugsverarbeitung. Zahlungszuordnung zu offenen Posten.</p><p class="text-body-lg text-gosign-text-light mt-4">Buchungslogik ist von der Exportschicht getrennt. Ein Wechsel des Zielsystems ändert die Exportschicht - nicht den Agenten.</p></div></div></section>

<!-- §203 StGB - Berufsgeheimnisschutz -->
<section class="py-section bg-gosign-dark text-white"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow">
<h2 class="text-h1 font-bold">§203 StGB - Berufsgeheimnisschutz</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4">Für Wirtschaftsprüfungs- und Steuerberatungskanzleien ist §203 StGB nicht verhandelbar. Mandantendaten dürfen den Kontrollbereich des Berufsgeheimnisträgers nie verlassen. Das ist keine Compliance-Checkbox - es ist strafrechtliche Haftung.</p>
<h3 class="text-h3 font-bold mt-8">Architektur statt Versprechen</h3>
<p class="text-body text-gosign-text-on-dark/80 mt-3">Der Finance Agent verarbeitet Mandantendaten ausschließlich in Ihrer Infrastruktur. Drei Architektur-Garantien:</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-4 mt-6">
<div class="p-4 bg-white/5 rounded-card"><p class="text-body font-semibold text-white">Mandantentrennung</p><p class="text-small text-white/70 mt-1">Separate Datenräume pro Mandant. Keine Cross-Mandanten-Inferenz.</p></div>
<div class="p-4 bg-white/5 rounded-card"><p class="text-body font-semibold text-white">EU-only Inferenz</p><p class="text-small text-white/70 mt-1">LLM-Verarbeitung in EU-Rechenzentren. Wahlweise Self-Hosted mit Open-Weight-Modellen.</p></div>
<div class="p-4 bg-white/5 rounded-card"><p class="text-body font-semibold text-white">Kein SaaS</p><p class="text-small text-white/70 mt-1">Voller Quellcode-Zugang. Keine Daten verlassen Ihre Infrastruktur. Auf Wunsch CLOUD Act-sicher.</p></div>
</div>

<!-- Mandantentrennung-Architekturdiagramm -->
<div class="mt-8 border border-white/20 rounded-card p-6 sm:p-8">
<p class="text-xs font-bold uppercase tracking-wider text-gosign-accent-on-dark mb-6">Datenfluss: §203-konforme Mandantentrennung</p>
<div class="border border-white/30 rounded-card p-4 sm:p-6">
<p class="text-small font-semibold text-white/90 mb-4">Kanzlei-Infrastruktur (§203-Kontrollbereich)</p>
<div class="grid grid-cols-3 gap-3 sm:gap-4">
<div class="border border-white/20 rounded-card p-3 text-center"><p class="text-small font-semibold text-white">Mandant A</p><p class="text-xs text-white/60 mt-1">Daten</p></div>
<div class="border border-white/20 rounded-card p-3 text-center"><p class="text-small font-semibold text-white">Mandant B</p><p class="text-xs text-white/60 mt-1">Daten</p></div>
<div class="border border-white/20 rounded-card p-3 text-center"><p class="text-small font-semibold text-white">Mandant C</p><p class="text-xs text-white/60 mt-1">Daten</p></div>
</div>
<div class="flex justify-center my-3"><svg class="w-5 h-5 text-white/60" fill="none" viewBox="0 0 24 24" stroke-width="2" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M19.5 13.5 12 21m0 0-7.5-7.5M12 21V3" /></svg></div>
<div class="border border-gosign-accent/40 bg-white/5 rounded-card p-4 text-center">
<p class="text-small font-semibold text-white">Finance Agent (Decision Layer)</p>
<p class="text-xs text-white/60 mt-1">Regelwerk pro Mandant versioniert</p>
</div>
<div class="flex justify-center my-3"><svg class="w-5 h-5 text-white/60" fill="none" viewBox="0 0 24 24" stroke-width="2" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M19.5 13.5 12 21m0 0-7.5-7.5M12 21V3" /></svg></div>
<div class="border border-white/20 bg-white/5 rounded-card p-4 text-center">
<p class="text-small font-semibold text-white">LLM (Self-Hosted / EU-only Cloud)</p>
<p class="text-xs text-white/60 mt-1">Keine Mandantendaten im Prompt</p>
</div>
<div class="mt-4 border border-white/20 bg-white/5 rounded-card p-4 text-center">
<p class="text-small font-semibold text-white">DATEV / SAP (Mandanten-getrennt)</p>
</div>
</div>
<p class="text-xs text-white/50 mt-4 text-center italic">Keine Daten verlassen diesen Kontrollbereich</p>
</div>

</div></div></section>

<!-- Zielgruppen -->
<section class="py-section bg-gosign-white"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><h2 class="text-h1 font-bold text-gosign-dark mb-8">Zielgruppen</h2><div class="grid grid-cols-1 md:grid-cols-3 gap-6"><div class="border border-gosign-border rounded-card p-6 bg-gosign-white"><h3 class="text-h3 font-bold text-gosign-dark">Wirtschaftsprüfungs- und Steuerberatungskanzleien</h3><p class="text-body text-gosign-text-light mt-2">Hunderte Mandanten, tausende Belege pro Monat. Der Finance Agent bringt Konsistenz in die Verarbeitung über alle Mandanten hinweg. Junior-Mitarbeiter verbringen heute 60% ihrer Zeit mit Datenerfassung statt Beratung. Der Finance Agent übernimmt die Routineerfassung - Ihre Fachkräfte konzentrieren sich auf das, wofür sie ausgebildet sind.</p></div><div class="border border-gosign-border rounded-card p-6 bg-gosign-white"><h3 class="text-h3 font-bold text-gosign-dark">Shared Service Center</h3><p class="text-body text-gosign-text-light mt-2">Mehrere Entitäten, verschiedene Länder, verschiedene Regelwerke. Der Finance Agent wendet mandantenspezifische Regeln konsistent an.</p></div><div class="border border-gosign-border rounded-card p-6 bg-gosign-white"><h3 class="text-h3 font-bold text-gosign-dark">Unternehmen mit eigener Buchhaltung</h3><p class="text-body text-gosign-text-light mt-2">Monatsabschlüsse, Quartalsberichte, Betriebsprüfungen. Weniger Korrekturbuchungen, konsistente Kontierung, vollständige Dokumentation.</p></div></div></div></section>

<!-- ProcessSteps -->
<section class="py-section bg-gosign-dark text-white"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><h2 class="text-h1 font-bold">Vom ersten Agent zur Finance-Plattform</h2><div class="grid md:grid-cols-3 gap-8 mt-8"><div><p class="text-xs font-bold uppercase tracking-wider text-gosign-accent-on-dark">Discover - 1 Woche</p><p class="text-body-lg text-gosign-text-on-dark/80 mt-2">Prozessanalyse mit Ihrem Finance-Team. Mapping der Buchungslogik, Dokumentation der Regelwerke. Priorisierung der Use Cases.</p></div><div><p class="text-xs font-bold uppercase tracking-wider text-gosign-accent-on-dark">Build - 3-4 Wochen</p><p class="text-body-lg text-gosign-text-on-dark/80 mt-2">Produktiver PoC. Ein Agent, ein Finance-Prozess, live in Ihrer Infrastruktur. Decision Layer, Governance, Audit Trail - ab Tag eins. Cert-Ready von Beginn an, nicht nachgerüstet.</p></div><div><p class="text-xs font-bold uppercase tracking-wider text-gosign-accent-on-dark">Scale - Kontinuierlich</p><p class="text-body-lg text-gosign-text-on-dark/80 mt-2">Mehr Agents für mehr Finance-Prozesse. Korrekturbuchungen, Bewirtungsbelege, Steuerprüfungen, Intercompany.</p></div></div><p class="text-body text-gosign-text-on-dark/60 mt-6 italic">Nach 12-18 Monaten betreiben Sie Ihre Finance Agents eigenständig. Voller Zugang zu Quellcode, Prompts und Regelversionen. Kein Vendor Lock-in.</p><p class="text-body text-gosign-text-on-dark/80 mt-4">Modell-agnostisch: Ob Azure OpenAI, Claude, Llama oder Mistral - das Regelwerk und die Entscheidungslogik bleiben identisch. Ein Modellwechsel erfordert keine Anpassung der Buchungsregeln.</p></div></section>

<!-- Business Impact -->
<section class="py-section bg-gosign-light"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow"><h2 class="text-h1 font-bold text-gosign-dark">Business Impact</h2><p class="text-body-lg font-semibold text-gosign-dark mt-4">Messbare Ergebnisse in Finance-Prozessen.</p><div class="grid grid-cols-1 sm:grid-cols-3 gap-4 mt-6"><div class="border border-gosign-border rounded-card p-4 bg-gosign-white text-center"><p class="text-h1 font-bold text-gosign-accent-text">2-4 EUR</p><p class="text-body text-gosign-text-light mt-1">Bearbeitungskosten pro Rechnung (Best-in-Class) statt ~12 EUR im Durchschnitt (Ardent State of ePayables 2024)</p></div><div class="border border-gosign-border rounded-card p-4 bg-gosign-white text-center"><p class="text-h1 font-bold text-gosign-accent-text">30-40%</p><p class="text-body text-gosign-text-light mt-1">weniger Korrekturbuchungen durch konsistente Regelanwendung (Erfahrungswert; Branchen-Benchmark: Exception-Rate 9% statt 22%, Ardent 2024)</p></div><div class="border border-gosign-border rounded-card p-4 bg-gosign-white text-center"><p class="text-h1 font-bold text-gosign-accent-text">7,5 Tage</p><p class="text-body text-gosign-text-light mt-1">schnellerer Monatsabschluss durch autonome Routineverarbeitung (MIT Sloan / Stanford GSB 2025)</p></div></div><ul class="mt-6 space-y-3 text-body-lg text-gosign-text-light list-none"><li>Auditierbare Entscheidungslogik für Wirtschaftsprüfung und interne Revision</li><li>Konsistente Buchungslogik über alle Standorte und Gesellschaften</li><li>Cert-Ready by Design - strukturell prüfungsfähig, nicht nachträglich dokumentiert</li><li>Reduktion des Prüfungsaufwands durch vollständige Entscheidungsakten pro Beleg</li></ul></div></div></section>

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Finance Agent Readiness Assessment</p>
<p class="text-body text-gosign-text mb-4">7 Fragen, 3 Minuten: Wie bereit ist Ihre Finance-Organisation für AI Agents?</p>
<a href="/de/finance-agent-readiness/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Assessment starten &rarr;</a>
</div>

<!-- Finance Agent Assessment -->
<section class="py-section bg-gosign-dark text-white"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow">
<h2 class="text-h1 font-bold">Finance Agent Assessment: 49 Agenten bewertet und priorisiert</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4">Welche Finance-Agenten gibt es, welche Governance brauchen sie, und in welcher Reihenfolge sollten Sie starten? Das Assessment bewertet 49 Agenten auf 6 Dimensionen - von Agent Readiness bis GoBD-Klassifikation. Interaktive Horizonte-Analyse, Micro-Decision-Tabellen und Entscheidungsakten pro Agent.</p>
<a href="/de/finance-agent-katalog/" class="inline-flex items-center gap-2 mt-4 text-body font-semibold text-gosign-accent-on-dark hover:underline">Zum Finance Agent Assessment &rarr;</a>
</div></div></section>

<!-- Vertiefung -->
<section class="py-section bg-gosign-white"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><h2 class="text-h2 font-bold text-gosign-dark mb-2">Vertiefung im Agent Briefing</h2><p class="text-body text-gosign-text-light mb-6">Unsere Fachartikel-Serie für Entscheider, die Finance-Prozesse mit AI Agents automatisieren.</p><div class="grid grid-cols-1 sm:grid-cols-3 gap-6"><a href="/de/magazin/ki-kosten-tco-vergleich/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors"><p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Finance</p><p class="text-body font-semibold text-gosign-dark">KI-Kosten im Vergleich: TCO-Analyse für Enterprise</p></a><a href="/de/magazin/decision-layer-shadow-ai/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors"><p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p><p class="text-body font-semibold text-gosign-dark">Decision Layer vs. Shadow AI: Warum Governance vor Geschwindigkeit kommt</p></a><a href="/de/magazin/ki-hosting-strategien-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors"><p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p><p class="text-body font-semibold text-gosign-dark">KI-Hosting: EU-SaaS, deutsches RZ oder Self-Hosted?</p></a></div></div></section>

--- Glossar - Enterprise AI Begriffe ---
> Fachbegriffe aus der Enterprise-AI-Welt. Von Agent bis Zero-Trust - klar definiert, konsistent verwendet.

<article class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<div class="prose prose-lg prose-headings:text-gosign-dark prose-headings:font-bold prose-h2:text-h2 prose-h2:mt-12 prose-h2:mb-4 prose-h3:text-h3 prose-h3:mt-8 prose-h3:mb-3 prose-p:text-gosign-text prose-p:leading-relaxed prose-a:text-gosign-accent-text prose-a:underline prose-a:decoration-gosign-accent-text/30 hover:prose-a:decoration-gosign-accent-text prose-strong:text-gosign-dark prose-ul:text-gosign-text prose-ol:text-gosign-text prose-hr:border-gosign-border">

## Agent-Typen

### Document Agent

Ein spezialisierter AI-Agent, der Dokumente liest, versteht und verarbeitet. Keine Template-Erkennung, kein starres OCR - kontextuelles Sprachverständnis. Document Agents verarbeiten Rechnungen, Krankmeldungen, Verträge, Bescheinigungen und Belege. Jede Entscheidung wird über den Decision Layer dokumentiert.

→ [Document Agents im Detail](/de/leistungen/ai-agents/)

### Workflow Agent

Ein AI-Agent, der Geschäftsprozesse systemübergreifend orchestriert. Von der Eingangspost über die Genehmigung bis zur Buchung. Jeder Schritt wird protokolliert. Bei Rückfragen oder fehlenden Informationen pausiert der Workflow - er bricht nicht ab.

→ [Workflow Agents im Detail](/de/leistungen/ai-agents/)

### Knowledge Agent

Ein AI-Agent, der kontextbasierte Antworten aus Unternehmenswissen liefert. Betriebsvereinbarungen, Richtlinien, Tarifverträge. Jede Antwort enthält Quellenangabe und Regelversion. Ohne Quelle erfolgt keine Antwort.

→ [Knowledge Agents im Detail](/de/leistungen/ai-agents/)

---

## Governance-Begriffe

### Decision Layer

Der Decision Layer zerlegt jeden Geschäftsprozess in einzelne Entscheidungsschritte und definiert für jeden Schritt vorab: Entscheidet ein Mensch, ein Regelwerk oder die KI eigenständig?

**MENSCH:** Die Architektur erzwingt menschliche Prüfung bei Ermessensentscheidungen, Diskriminierungspotenzial, Mitbestimmungsthemen und Wertgrenzen über definierten Schwellen. Der Agent liefert Kontext und Empfehlung - ein Mensch entscheidet. Technisch erzwungen, nicht organisatorisch vereinbart.

**REGELWERK:** Die Entscheidung ist deterministisch - es gibt keinen Interpretationsspielraum. Tarifvertrag sagt X, also gilt X. Frist läuft am Datum Y ab, also greift Regel Z. Das Regelwerk ist versioniert: Jede Änderung erzeugt eine neue Version, die alte bleibt nachvollziehbar.

**KI AUTONOM:** Der Agent trifft eigenständige Entscheidungen - weil er confident genug ist, die Erlaubnis hat, und die Aufgabe nachweislich besser erledigt als manuelle Bearbeitung. Er interpretiert Dokumente, klassifiziert Sachverhalte, bewertet Kontext und erkennt Muster. Das ist kein If-Then-Else - das ist Urteilsvermögen innerhalb definierter Leitplanken. Das Confidence Routing steuert: Hohe Konfidenz und niedriges Risiko führt zur autonomen Entscheidung. Niedrige Konfidenz oder hohes Risiko führt zur Eskalation an einen Menschen.

Technisch sitzt der Decision Layer zwischen AI Agent und Zielsystem (z.B. SAP, [DATEV](https://www.datev.de/), [Workday](https://www.workday.com/)). Jede Entscheidung erzeugt einen vollständigen, unveränderlichen Entscheidungsdatensatz: Eingangsdaten, Modell, angewandtes Regelwerk mit Version, Konfidenzwert, Entscheidungspfad, Ergebnis, Zeitstempel.

→ [Decision Layer bei Gosign](/de/decision-layer/)

### Human-in-the-Loop

Ein architektonisches Prinzip, bei dem die finale Entscheidungskompetenz beim Menschen verbleibt. Nicht nachträglich hinzugefügt, sondern von Beginn an in die Agentenarchitektur integriert. Bei niedriger Konfidenz oder Ausnahmen eskaliert der Agent automatisch an den zuständigen Spezialisten - mit vollständigem Kontext und Handlungsempfehlung.

### Governance by Design

Governance-Anforderungen werden nicht nachträglich aufgesetzt, sondern sind integraler Bestandteil der Agentenarchitektur. Audit Trail, Rollenkonzept, Decision Layer und Human-in-the-Loop sind von Tag 1 an vorhanden. Das Gegenteil von Schatten-IT.

→ [Governance by Design](/de/governance/)

### Audit Trail

Die lückenlose Dokumentation jeder Agenten-Entscheidung: Eingangsdaten, angewandte Regel, Regelversion, Konfidenzwert, Ergebnis, Zeitstempel. Nicht nur für interne Nachvollziehbarkeit - sondern für Wirtschaftsprüfer, Betriebsräte und Zertifizierungsaudits.

### Cert-Ready by Design

Ein Architekturansatz, bei dem alle Kontrollen und Dokumentationsmechanismen so gebaut werden, dass sie die Anforderungen gängiger Prüfungsstandards (ISA, PS 951, IDW, GoB/GoBD) bereits im Normalbetrieb erfüllen. Keine nachträgliche Audit-Vorbereitung.

→ [Cert-Ready by Design](/de/governance/cert-ready/)

### Mitbestimmung

Das deutsche Recht auf betriebliche Mitbestimmung durch den Betriebsrat (BetrVG). Bei AI-Agenten, die Mitarbeiterdaten verarbeiten oder Personalentscheidungen vorbereiten, ist die Einbindung des Betriebsrats rechtlich erforderlich. Gosign-Agenten sind von Beginn an betriebsratsfähig konzipiert.

→ [Mitbestimmung & AI-Agenten](/de/governance/mitbestimmung/)

### Micro-Entscheidung (Micro-Decision)

Eine Micro-Entscheidung ist ein einzelner, definierter Entscheidungsschritt innerhalb eines Geschäftsprozesses. Der Decision Layer zerlegt jeden Prozess in Micro-Entscheidungen und definiert für jede einzelne: Entscheidet ein Mensch (Architektur erzwingt Prüfung bei Ermessen, Diskriminierungspotenzial, Mitbestimmung), ein Regelwerk (deterministisch, kein Interpretationsspielraum) oder die KI eigenständig (confident genug, Erlaubnis vorhanden, nachweislich besser als manuelle Bearbeitung). Jede Micro-Entscheidung erzeugt einen eigenen Audit-Trail-Eintrag.

### Confidence Routing

Confidence Routing ist der Mechanismus im Decision Layer, der jede Agenten-Entscheidung automatisch nach Konfidenz und Risikokategorie bewertet und den Entscheidungspfad steuert. Hohe Konfidenz bei niedrigem Risiko führt zur autonomen Verarbeitung. Niedrige Konfidenz oder hohes Risiko führt zur Eskalation an einen Menschen. Die Schwellenwerte sind konfigurierbar und mandantenspezifisch.

### Betriebsvereinbarung als System-Constraint

In der Gosign-Architektur werden Betriebsvereinbarungen als technische Constraints im Decision Layer implementiert. Jede Betriebsvereinbarung wird als versioniertes Regelwerk übersetzt. Wenn die Betriebsvereinbarung beispielsweise festlegt, dass Leistungsbeurteilungen nicht vollautomatisiert erfolgen dürfen, wird das als Human-in-the-Loop-Regel technisch erzwungen - der Agent kann sie nicht umgehen. Der Betriebsrat kann im Auditor Portal nachvollziehen, ob seine Anforderungen technisch umgesetzt sind.

### Schatten-IT

IT-Systeme, die ohne Wissen oder Genehmigung der IT-Abteilung betrieben werden. Bei AI-Agenten besonders kritisch, da unkontrollierte LLM-Nutzung Datenschutz-, Compliance- und Sicherheitsrisiken erzeugt. Gosign-Agenten werden in die bestehende IT-Governance integriert - nicht als Parallelsystem.

---

## Infrastruktur-Begriffe

### Retrieval Augmented Generation (RAG)

Eine Architektur, bei der ein LLM nicht nur aus seinem Trainingskorpus antwortet, sondern zusätzlich relevante Dokumente aus einer Wissensbasis abruft. Bei Enterprise-RAG: semantisches Chunking, Metadaten-Anreicherung, Hybrid-Suche, Quellennachweis und regelmäßige Re-Indexierung.

→ [RAG-Infrastruktur](/de/leistungen/infrastruktur/)

### LLM Hosting

Der Betrieb von Large Language Models. Cloud (Azure OpenAI, Google Vertex AI - EU-Regionen mit DPAs), Self-Hosted ([Llama](https://llama.meta.com/), [Mistral](https://mistral.ai/), [DeepSeek](https://www.deepseek.com/) - Open Source, eigene Hardware) oder Hybrid (sensible Daten self-hosted, unkritische Lasten in der Cloud).

### Modell-Agnostik

Die Eigenschaft einer Agentenarchitektur, nicht an ein bestimmtes LLM gebunden zu sein. Gosign-Agenten funktionieren mit Claude, ChatGPT, Gemini, Llama, Mistral, DeepSeek und gpt-oss. Ein Modellwechsel ändert nicht die Geschäftslogik, nicht die Regelwerke, nicht den Audit Trail.

### Co-Build

Das Gosign-Modell zur Kundenbefähigung. Der Agent wird gemeinsam entwickelt, das Team des Kunden wird parallel aufgebaut. Nach 12-18 Monaten betreibt der Kunde seine Agenten eigenständig. Kein Vendor Lock-in, kein dauerhaftes Beratungsmodell.

---

## Regulatorik

### EU AI Act

Die EU-Verordnung über Künstliche Intelligenz (AI Act, Verordnung (EU) 2024/1689). Klassifiziert KI-Systeme nach Risikostufen und definiert Anforderungen an Transparenz, Dokumentation, menschliche Aufsicht und Risikomanagement. Für AI-Agenten im HR- und Finance-Bereich besonders relevant.

→ [EU AI Act Readiness](/de/governance/eu-ai-act/)

### PII (Personally Identifiable Information)

Personenbezogene Daten die eine natürliche Person direkt oder indirekt identifizierbar machen. Im Kontext von Document Intelligence: Name, Adresse, Geburtsdatum, Sozialversicherungsnummer, Gehalt, Bankverbindung, biometrische Daten. PII-Erkennung ist die Voraussetzung für Pseudonymisierung und Schwärzung.

### Roundtrip-Pseudonymisierung

Dreistufiges Verfahren für DSGVO-konforme Dokumentenverarbeitung mit Sprachmodellen. Schritt 1: Personenbezogene Daten werden durch konsistente Pseudonyme ersetzt. Schritt 2: Das pseudonymisierte Dokument wird vom Sprachmodell verarbeitet. Schritt 3: Im Ergebnis werden die Pseudonyme durch die Echtdaten ersetzt. Das Modell sieht zu keinem Zeitpunkt personenbezogene Daten. Die Zuordnungstabelle verlässt nie den Pre-Processing Layer.

### Document Intelligence

Die Fähigkeit des Document Agent, Dokumente nicht nur zu lesen und zu verarbeiten, sondern auch zu schützen: PII-Anonymisierung für LLM-Input, regelbasierte Vertragsschwärzung für unterschiedliche Empfänger, und automatische Signaturerkennung. Alle drei Capabilities werden durch den Decision Layer gesteuert - für jeden Entscheidungsschritt ist definiert: Mensch, Regelwerk oder KI.

→ [Document Intelligence](/de/leistungen/document-intelligence/)

### Data Residency

Die Kontrolle darüber, wo Daten physisch gespeichert und verarbeitet werden. Bei Enterprise-AI-Infrastruktur: EU-Regionen (Azure West Europe, GCP europe-west3), DPAs mit allen Subprozessoren, keine Datenübermittlung außerhalb des definierten Geltungsbereichs.

→ [Data Residency bei Gosign](/de/governance/data-residency/)

</div>
</div>
</article>

--- AVV-Checkliste für KI-Infrastruktur - 25 Prüffragen ---
> Anforderungskatalog für Auftragsverarbeitungsverträge bei Enterprise-KI. 25 Prüffragen für Legal, IT-Security und Betriebsrat.

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-body-lg text-gosign-text-light">
Ein Auftragsverarbeitungsvertrag (AVV) für KI-Infrastruktur muss zehn Themen abdecken, die Standard-SaaS-AVVs nicht regeln: Prompt-Logging-Policies, Umgebungstrennung (Dev/Staging/Prod), Modell-Provider-Ketten, In-flight- vs. At-rest-Datenverarbeitung, RAG-Embedding-Datenschutz, <a href="/de/governance/data-residency/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Drittlandzugriffe auf Produktivdaten</a>, &sect; 203-StGB-Kompatibilität, PII-Tokenisierung, Decision-Layer-Audit-Trails und Nachweisbarkeit technischer Maßnahmen. Diese Checkliste fasst die zehn Lücken in 25 konkrete Prüffragen zusammen.
</p>
<p class="text-body text-gosign-text-light mt-4">
Die ausführliche Analyse der zehn Lücken finden Sie im Magazin-Artikel: <a href="/de/magazin/avv-ki-infrastruktur-checkliste/" class="text-gosign-accent-text hover:underline">AVV für KI-Agenten: Was Ihr Standard-Vertrag nicht abdeckt</a>.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">A - Datenkategorien und Verarbeitungszwecke</h2>
<div class="space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">1</p>
<p class="text-body-lg text-gosign-text-light mt-1">Sind Prompt-Inhalte und Modellantworten als eigenständige Datenkategorie im AVV aufgeführt?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">2</p>
<p class="text-body-lg text-gosign-text-light mt-1">Ist geregelt, wer die Verantwortung für die Inhaltsklassifizierung trägt (Unternehmen, nicht Anbieter)?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">3</p>
<p class="text-body-lg text-gosign-text-light mt-1">Sind Embeddings/Vektoren als potenziell personenbezogene Daten klassifiziert?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">4</p>
<p class="text-body-lg text-gosign-text-light mt-1">Enthält der AVV eine Regelung für besondere Kategorien nach Art. 9 DSGVO, die durch Nutzereingaben entstehen können?</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">B - Logging und Monitoring</h2>
<div class="space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">5</p>
<p class="text-body-lg text-gosign-text-light mt-1">Ist Request-/Response-Body-Logging in der Produktivumgebung deaktiviert?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">6</p>
<p class="text-body-lg text-gosign-text-light mt-1">Welche Metadaten werden protokolliert (Statuscodes, Laufzeiten, Request-IDs)?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">7</p>
<p class="text-body-lg text-gosign-text-light mt-1">Ist Debug-Logging in Produktion nachweisbar deaktiviert?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">8</p>
<p class="text-body-lg text-gosign-text-light mt-1">Werden Stacktraces und Fehlermeldungen so konfiguriert, dass keine Inhaltsdaten in Logs gelangen?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">9</p>
<p class="text-body-lg text-gosign-text-light mt-1">Ist die Prüfung der Logging-Einstellungen Bestandteil des Release-Prozesses?</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">C - Umgebungstrennung und Zugriff</h2>
<div class="space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">10</p>
<p class="text-body-lg text-gosign-text-light mt-1">Existieren getrennte Umgebungen (Dev, Staging, Prod) mit unterschiedlichen Datenpolicies?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">11</p>
<p class="text-body-lg text-gosign-text-light mt-1">Enthalten Dev/Staging ausschließlich synthetische oder anonymisierte Daten?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">12</p>
<p class="text-body-lg text-gosign-text-light mt-1">Ist der Produktivzugriff auf autorisierte Rollen in Deutschland/EWR beschränkt? (Siehe auch: <a href="/de/governance/cert-ready/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Cert-Ready-Anforderungen</a>)</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">13</p>
<p class="text-body-lg text-gosign-text-light mt-1">Gibt es ein dokumentiertes Ausnahmeverfahren für Supportfälle mit Datenbezug?</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">D - Modell-Provider und Subdienstleister</h2>
<div class="space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">14</p>
<p class="text-body-lg text-gosign-text-light mt-1">Ist die Abgrenzung klar: Welche Provider sind Unterauftragsverarbeiter des Anbieters, welche laufen im Tenant des Unternehmens?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">15</p>
<p class="text-body-lg text-gosign-text-light mt-1">Ist Content-Retention bei den Modell-Providern deaktiviert?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">16</p>
<p class="text-body-lg text-gosign-text-light mt-1">Ist der Ausschluss der Nutzung zu Trainingszwecken vertraglich dokumentiert?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">17</p>
<p class="text-body-lg text-gosign-text-light mt-1">Wo liegen die Modell-Endpunkte (EU-Region, US, andere)?</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">E - Datenspeicherung und Löschung</h2>
<div class="space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">18</p>
<p class="text-body-lg text-gosign-text-light mt-1">Ist geregelt, wo persistente Inhaltsdaten gespeichert werden (Datenbank, Region, Provider)?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">19</p>
<p class="text-body-lg text-gosign-text-light mt-1">Welche Backup-Retention gilt und wie wird mit gelöschten Daten in Backups umgegangen?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">20</p>
<p class="text-body-lg text-gosign-text-light mt-1">Kann der einzelne Nutzer seine Daten in der Anwendung selbst löschen?</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">F - Regulierte Branchen</h2>
<div class="space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">21</p>
<p class="text-body-lg text-gosign-text-light mt-1">Enthält der AVV eine Regelung zur &sect; 203-StGB-Kompatibilität (oder landesspezifischem Äquivalent)?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">22</p>
<p class="text-body-lg text-gosign-text-light mt-1">Liegen Vertraulichkeitsverpflichtungen für alle mitwirkenden Personen vor?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">23</p>
<p class="text-body-lg text-gosign-text-light mt-1">Ist PII-Tokenisierung als optionales Modul vorgesehen?</p>
</div>
</div>
<p class="text-body text-gosign-text-light mt-8">
Für Berufsgeheimnisträger - Anwälte, Steuerberater, Wirtschaftsprüfer - decken die Fragen 21 bis 23 nur die Enterprise-Ebene ab: § 203 Abs. 4 StGB verlangt zusätzlich, dass die mitwirkenden Personen zur Geheimhaltung verpflichtet werden; das Berufsrecht (§ 43e BRAO, § 62a StBerG, § 50a WPO) verlangt dafür Textform und Belehrung über die strafrechtlichen Folgen sowie weitere Kettenglieder, die ein AVV nicht abdeckt. Die vollständige Vertragskette und die geprüften Bezugswege behandelt der eigene Bereich <a href="/de/berufsgeheimnistraeger/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">KI für Berufsgeheimnisträger (§ 203 StGB)</a>.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">G - <a href="/de/governance/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Governance</a> und Nachweisbarkeit</h2>
<div class="space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">24</p>
<p class="text-body-lg text-gosign-text-light mt-1">Ist ein Audit-Trail für Agenten-Entscheidungen als Vertragsbestandteil verankert?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">25</p>
<p class="text-body-lg text-gosign-text-light mt-1">Ist der Nachweis der TOMs auf Anfrage möglich (Konfigurationsnachweise, geschwärzte Logauszüge)?</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-body text-gosign-text-light">
Diese Checkliste ist ein Anforderungskatalog aus Architektur- und Governance-Perspektive. Sie ersetzt keine Rechtsberatung. Die rechtliche Prüfung und formale Bewertung des AVV obliegt der Rechtsabteilung des Verantwortlichen oder externen Beratern.
</p>
</div>
</section>

--- AVV nach Art. 28 DSGVO - ENTWURF | Gosign GmbH ---
> Vollständiger AVV-Wortlaut (Art. 28 DSGVO) für die Nutzung von BV-Konto und BV-KI-Drafter. ENTWURF zur juristischen Prüfung, Stand v1-2026-06.

> **⚠️ ENTWURF - zur juristischen Prüfung durch die Rechtsabteilung. NICHT rechtsverbindlich bis zur Freigabe.**
> Dieser Text ist ein technisch-fachlich vorbereiteter Arbeitsentwurf als Grundlage der anwaltlichen/juristischen Prüfung. Er entfaltet **keine** Rechtswirkung, begründet keine Vertragspflichten und stellt keine Rechtsberatung dar, solange er nicht durch die Rechtsabteilung der Gosign GmbH freigegeben und im Produkt als verbindliche Fassung veröffentlicht wurde. Stand: **v1-2026-06**.
> Die zuvor als „von Legal/Ops zu ergänzen" markierten operativen/faktischen Stellen sind mit **verifizierten Echtwerten befüllt (Stand 2026-06)** - aus Code, Konfiguration und Impressum hergeleitet bzw., wo es keinen festen Wert gibt, durch eine Klarstellung ersetzt (Click-Wrap-Erfassung zur Laufzeit, „nicht einschlägig" oder infrastrukturgebunden). Der Text ist damit fachlich/operativ verifiziert befüllt und **freigabebereit**; die formale rechtsverbindliche Freigabe durch die Gosign GmbH bleibt vorbehalten.

---

# Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO - ENTWURF (v1-2026-06)

**Vertrag über die Verarbeitung personenbezogener Daten im Auftrag gemäß Artikel 28 Absatz 3 der Verordnung (EU) 2016/679 (Datenschutz-Grundverordnung - DSGVO)**

> **Status: ENTWURF - zur juristischen Prüfung, nicht rechtsverbindlich bis zur Freigabe.** Stand v1-2026-06.

---

## Präambel

Dieser Auftragsverarbeitungsvertrag (nachfolgend „**AVV**" oder „**Vertrag**") konkretisiert die datenschutzrechtlichen Pflichten der Parteien im Zusammenhang mit der Nutzung der von der Gosign GmbH bereitgestellten Leistungen, insbesondere des „BV-Kontos" (Funktion „Für später speichern") sowie des KI-gestützten Entwurfsassistenten „BV-KI-Drafter" (nachfolgend zusammen die „**Leistungen**").

Der AVV ergänzt die zwischen den Parteien geltenden Allgemeinen Geschäftsbedingungen der Gosign GmbH (nachfolgend „**AGB**", aktuelle Fassung abrufbar unter [`gosign.de/de/agb/`](/de/agb/)). § 13 der AGB sieht den Abschluss dieses AVV ausdrücklich vor. Bei Widersprüchen zwischen diesem AVV und den AGB gehen in datenschutzrechtlichen Fragen die Regelungen dieses AVV vor; im Übrigen gelten die AGB.

Soweit der Verantwortliche eine eigene, DSGVO-konforme AVV-Vorlage bereitstellt, kann diese nach Maßgabe von § 13 der AGB an die Stelle dieses Vertrags treten.

---

## § 1 Parteien des Vertrags

**(1) Auftragsverarbeiter** im Sinne von Art. 4 Nr. 8 DSGVO:

> **Gosign GmbH**, Hallerstraße 8, 20146 Hamburg, Deutschland (nachfolgend „**Gosign**" oder „**Auftragsverarbeiter**"). Kontakt in Datenschutzangelegenheiten: datenschutz@gosign.de
>
> Hinweis: Bei der Gosign GmbH ist gemäß § 38 Abs. 1 BDSG derzeit kein Datenschutzbeauftragter zu bestellen, da nicht ständig mindestens 20 Personen mit der automatisierten Verarbeitung personenbezogener Daten befasst sind. Registergericht: Amtsgericht Hamburg, HRB 112197 (Sitz: Hallerstraße 8, 20146 Hamburg). Vertretungsberechtigte Geschäftsführer: Bert Gogolin und Dieter Gogolin.

**(2) Verantwortlicher** im Sinne von Art. 4 Nr. 7 DSGVO ist das die Leistungen nutzende Unternehmen, das im Rahmen des Click-Wrap-Abschlusses als Vertragspartner benannt wird. Anschrift, vertretungsberechtigte Person und Datenschutz-Kontakt des Verantwortlichen sind kein fester Wert dieses Vertrags, sondern werden beim Click-Wrap-Abschluss erfasst und sind Bestandteil des jeweiligen Vertragsabschlusses.

**(3) Klarstellung für berufsprivilegierte Berater.** Die Privilegierung dieses Absatzes gilt ausschließlich für echte Berufsgeheimnisträger, nämlich Steuerberater (§ 11 Abs. 2 StBerG), Rechtsanwälte (§ 43e BRAO) und Wirtschaftsprüfer (§ 50b WPO), jeweils in Verbindung mit der strafbewehrten Verschwiegenheitspflicht nach § 203 StGB. Diese Berufsträger tragen als Vertragspartner ihre **eigene** Firma ein - nicht die der betreuten Mandanten. Für die in Ausübung ihres Berufs verarbeiteten Mandantendaten sind sie **selbst Verantwortlicher** im Sinne von Art. 4 Nr. 7 DSGVO und gegenüber Gosign nicht Auftragsverarbeiter; dieser eine Vertrag deckt ihre gesamte berufliche Tätigkeit gegenüber Gosign ab, sodass ein gesonderter AVV je Mandant gegenüber Gosign nicht erforderlich ist. Reine Unternehmensberatungen und sonstige Beratungsgesellschaften ohne berufsrechtliche Verschwiegenheitspflicht sind von dieser Privilegierung **ausgenommen**: Sie verarbeiten die Daten ihrer Auftraggeber als Auftragsverarbeiter nach Art. 28 DSGVO und schließen den AVV in dieser Rolle ab.

**(4)** Auftragsverarbeiter und Verantwortlicher: einzeln „**Partei**", gemeinsam „**Parteien**".

---

## § 2 Gegenstand, Rollenverteilung und Rangfolge

**(1) Gegenstand.** Verarbeitung personenbezogener Daten durch Gosign **ausschließlich im Auftrag und nach Weisung** des Verantwortlichen im Rahmen der Leistungen. Der Verantwortliche bleibt „Herr der Daten" und allein verantwortlich für die Rechtmäßigkeit (Art. 5, 6 DSGVO).

**(2) Keine gemeinsame Verantwortlichkeit** nach Art. 26 DSGVO. Gosign verarbeitet nicht zu eigenen Zwecken.

**(3) Inhaltsklassifizierung.** Die Verantwortung dafür, welche Inhalte (Freitext-Prompts, Dokumente) eingegeben werden und welche Sensibilität sie haben, liegt **allein beim Verantwortlichen**. Gosign nimmt keine inhaltliche Vorabprüfung vor, gewährleistet aber die TOM nach Anlage 2 unabhängig von der Sensibilität.

**(4) Rangfolge:** (i) zwingendes Datenschutzrecht, (ii) dieser AVV inkl. Anlagen, (iii) AGB, (iv) sonstige Vereinbarungen.

---

## § 3 Art, Zweck und Umfang der Verarbeitung

**(1) Art:** Erheben, Erfassen, Organisieren, Speichern, Auslesen, Verwenden, Übermitteln an den KI-Dienstleister zur Entwurfserzeugung, Einschränken, Löschen/Vernichten - im erforderlichen Umfang.

**(2) Zweck:** a) **BV-Konto** (Speicherung des Arbeitsstands + Konto-/AVV-Akzeptanzdaten); b) **BV-KI-Drafter** (Erzeugung + Zustellung eines unverbindlichen Textentwurfs); c) **Missbrauchsbegrenzung** (verschlüsselte E-Mail + anonyme Auswahl-Zusammenfassung).

**(3) Umfang:** nach Funktionsumfang, Eingaben und dokumentierten Weisungen (§ 6).

**(4) Datensparsamkeit.** Die Leistungen sind auf **Beispiel-/Testangaben** ausgelegt, nicht auf echte Beschäftigtendaten; der Verantwortliche wird vorab darauf hingewiesen. Bei abweichender Nutzung gelten die Regelungen dennoch vollumfänglich.

---

## § 4 Kategorien betroffener Personen

a) Beschäftigte/Bewerber des Verantwortlichen; b) Mitglieder von Arbeitnehmervertretungen; c) Mandanten/Auftraggeber/Dritte (insb. bei berufsprivilegierten Beratern); d) Ansprechpartner/Nutzer des Verantwortlichen; e) weitere nach konkreten Eingaben. Abschließende Festlegung durch den Verantwortlichen (Anlage 1).

---

## § 5 Kategorien personenbezogener Daten

**(1) Allgemein:** a) Stamm-/Kontaktdaten (Firma, Zustell-E-Mail, Handlungsbefugnis); b) Konto-/Vertragsmetadaten (AVV-Akzeptanzzeit, akzeptierte Version, Status Arbeitsstand); c) Nutzungs-/Verbindungsdaten (§ 12).

**(2) KI-spezifisch:** a) **Prompt-/Eingabeinhalte** (Freitext, potenziell beliebige pbD); b) **Modellantworten/Entwurfsinhalte**; c) **hochgeladene/eingefügte Dokumentinhalte** - nicht einschlägig: Datei-Uploads sind nicht im Funktionsumfang, verarbeitet werden ausschließlich Formular-/Freitexteingaben; d) **Embeddings/Vektordaten** - nicht einschlägig: es ist keine RAG-/Embedding-Pipeline mit Personenbezug aktiv.

**(3) Besondere Kategorien (Art. 9 DSGVO).** Nicht Zweck der Leistungen, nicht vorgesehen. Da Freitext möglich ist, kann der Verantwortliche solche Daten einbringen; dann trägt er die Verantwortung für die Rechtsgrundlage (Art. 9 Abs. 2 DSGVO). Gosign sichert für alle Inhalte einheitlich die Maßnahmen nach Anlage 2 zu (keine abgesenkte Behandlung sensibler Inhalte).

**(4) Beschäftigtenkontext (Art. 88 DSGVO).** Beschäftigtendaten im Kontext des Beschäftigungsverhältnisses; Art. 88 DSGVO i.V.m. nationalen Beschäftigtendatenschutzregelungen + etwaige Betriebs-/Dienstvereinbarungen sind vom Verantwortlichen zu beachten.

---

## § 6 Weisungsrecht (Art. 28 Abs. 3 lit. a DSGVO)

**(1)** Verarbeitung ausschließlich auf **dokumentierte Weisung**, auch bzgl. Drittlandübermittlung, außer bei gesetzlicher Verpflichtung (dann Mitteilung vor der Verarbeitung, soweit nicht verboten). **(2)** Vertrag + Anlagen + bestimmungsgemäße Eingaben = anfängliche dokumentierte Weisung; mündliche Weisungen unverzüglich in Textform. **(3)** Über die Leistungen hinausgehende Einzelweisungen: Textform, Nachtrag, ggf. Vergütung nach AGB. **(4)** Bei rechtswidriger Weisung: unverzügliche Information, Aussetzungsrecht. **(5)** Weisungs-/Empfangsberechtigte in Anlage 3 benannt; vom Verantwortlichen beim Click-Wrap-Abschluss bzw. im BV-Konto hinterlegt.

---

## § 7 Vertraulichkeit (Art. 28 Abs. 3 lit. b DSGVO)

**(1)** Verpflichtung der befugten Personen zur Vertraulichkeit (oder gesetzliche Verschwiegenheit), fortwirkend über die Tätigkeit hinaus. **(2)** Need-to-know. **(3) Berufsgeheimnisträger (§ 203 StGB):** Soweit der Verantwortliche beruflicher Verschwiegenheit unterliegt (Anwalt/StB/WP/Arzt + berufsmäßige Gehilfen), verpflichtet Gosign alle mitwirkenden Personen (inkl. Subunternehmer) **schriftlich** zur Verschwiegenheit und belehrt sie über § 203 StGB (insb. Abs. 4 für mitwirkende Personen); Verpflichtungs-/Belehrungserklärungen werden dokumentiert + auf Anfrage nachgewiesen. Gosign gilt als „mitwirkende Person" (§ 203 Abs. 3 StGB). **(4)** Nachweis auf Verlangen.

---

## § 8 Technische und organisatorische Maßnahmen (Art. 28 Abs. 3 lit. c, Art. 32 DSGVO)

**(1)** TOM nach Art. 32, beschrieben in **Anlage 2**. **(2)** Fortentwicklung zulässig, sofern Schutzniveau nicht unterschritten; wesentliche Änderungen dokumentiert + auf Anfrage mitgeteilt. **(3)** Umfasst Pseudonymisierung/Verschlüsselung, Vertraulichkeit/Integrität/Verfügbarkeit/Belastbarkeit, Wiederherstellung, regelmäßige Überprüfung. **(4) Mandantentrennung:** logische Trennung der Daten verschiedener Verantwortlicher (Daten, Logs, Historien, Storage, Schlüssel); kein Datenfluss zwischen Mandanten.

---

## § 9 Sub-Auftragsverarbeiter (Art. 28 Abs. 2 und 4 DSGVO)

**(1) Allgemeine Genehmigung** zur Inanspruchnahme weiterer Auftragsverarbeiter; die bei Vertragsschluss eingesetzten sind in **Anlage 4** abschließend aufgeführt + genehmigt. **(2) Vorab-Information + Widerspruchsrecht** bei Hinzuziehung/Ersetzung: Textform, Frist **mind. 14 Kalendertage**; Widerspruch aus wichtigem datenschutzrechtlichem Grund. **(3) Folgen:** einvernehmliche Lösung; sonst Kündigungsrecht des betroffenen Leistungsteils. **(4) Flow-Down (Art. 28 Abs. 4):** dieselben Datenschutzpflichten an jeden Sub-AV; **Gosign haftet** für deren Pflichteinhaltung. **(5) Abgrenzung Modell-/Plattform-Provider:** im Standardbetrieb alle als Sub-AV von Gosign geführt; abweichende „Bring-your-own-Tenant"-Konstellation gesondert zu vereinbaren. **(6)** Reine TK-/Postdienste ohne pbD-Verarbeitung sind keine Sub-AV (Sorgfaltspflicht bleibt).

---

## § 10 KI-spezifische Pflichten (Kein-Training, Retention, Tokenisierung)

**(1) Kein Training mit Auftraggeberdaten.** Verwendung der im Auftrag verarbeiteten Daten (Prompts, Dokumente, Modellantworten) **ausschließlich** zur Leistungserbringung; **kein** Training/Fine-Tuning/Entwicklung/Evaluierung eigener oder fremder Modelle, außer ausdrückliche gesonderte Textform-Freigabe (entspricht § 6.6 AGB). **(2) Flow-Down der Trainings-Beschränkung:** Modell-Provider vertraglich so eingesetzt, dass auch sie nicht zu Trainingszwecken nutzen + keine Content-Retention über die Anfrage hinaus („Zero-Retention", soweit providerseitig verfügbar). Der Retention-/No-Training-Status je Modell-Provider/Endpunkt ist in Anlage 4 geführt. **(3) In-flight vs. At-rest** (Modellverarbeitung ohne persistente Speicherung beim Provider; vorübergehende At-rest-Speicherung bei Gosign zur Zustellung; § 13/Anlage 2). **(4) Modell-Agnostik + Modellwechsel** (= Sub-AV-Wechsel → Information nach § 9 Abs. 2). **(5) PII-Redaktion/Tokenisierung (optional):** Eingangs-/Ausgangsfilter, Pseudonymisierung vor LLM-Call + Re-Insertion danach; bei reversibler Re-ID: Zugriffs-/Schlüsselregelung. Im aktuellen Funktionsstand ist die PII-Redaktion **nicht** aktiviert; die Datensparsamkeit wird über die Eingabe von Beispieldaten (keine echten pbD) gewährleistet. **(6) Keine automatisierte Entscheidung im Einzelfall (Art. 22 DSGVO)** - Entwürfe sind unverbindliche Vorschläge. **(7) Audit-Trail** inhaltsdatenarm (Metadaten, keine Prompt-/Dokumentinhalte; § 12).

---

## § 11 Ort der Verarbeitung; Drittlandübermittlung (Kapitel V DSGVO)

**(1) Grundsatz EU/EWR.** E-Mail-Hosting Google Workspace (Google Cloud EMEA, Dublin/IE) EU-konfiguriert; Website/Funktionen über Cloudflare. Die Persistenz (BV-Konto + Drafter-Jobs) liegt in von Gosign selbst betriebener Infrastruktur (self-hosted Supabase) innerhalb der EU/des EWR; eine Drittland-Speicherung der Persistenz findet nicht statt. **(2) Modell-Provider:** Die LLM-Verarbeitung zur Entwurfserzeugung erfolgt durch einen KI-Dienst innerhalb der EU bzw. des EWR; eine Übermittlung an den Modell-Provider in ein Drittland findet nicht statt. **(3) Geeignete Garantien:** Cloudflare/Google = EU-US Data Privacy Framework (sofern zertifiziert) + ergänzend SCC, soweit für Hosting/Zustellung einschlägig. **(4) DPF-Status (2026):** Angemessenheitsbeschluss vom 10.07.2023 derzeit gültig; Klage T-553/23 (Latombe) am 03.09.2025 abgewiesen; Rechtsmittel C-703/25 P anhängig → US-Übermittlungen **zusätzlich** auf SCC gestützt (doppelte Absicherung). Stand 2026-06: der Angemessenheitsbeschluss ist gültig, das Rechtsmittel C-703/25 P ist anhängig; US-Übermittlungen werden daher zusätzlich auf SCC gestützt (doppelte Absicherung). **(5) Datensparsamkeit als Transferminimierung** (Beispielangaben statt echter pbD).

---

## § 12 Logging, Monitoring, Umgebungstrennung

**(1)** Produktiv **kein** Logging von Anfrage-/Antwort-/Prompt-/Dokumentinhalten; nur technische Metadaten. **(2)** Debug-Logging produktiv deaktiviert; keine Inhaltsdaten in Stacktraces. **(3)** Prüfung der Logging-Einstellungen im Release-Prozess. **(4)** Cloudflare-Server-Logfiles max. 72 h, nicht zusammengeführt. **(5)** Getrennte Umgebungen (Dev/Test/Prod); Dev/Test verarbeiten ausschließlich synthetische/anonymisierte Daten (keine echten pbD) und sind strikt von Produktiv getrennt. **(6)** Rollenbasierte Zugriffskontrolle: Der Produktivzugriff ist auf Gosign-Personal in der EU rollenbasiert beschränkt; ein Support-Zugriff erfolgt nur über ein dokumentiertes Ausnahmeverfahren mit Vorab-Freigabe; ein regulärer Drittland-Zugriff findet nicht statt.

---

## § 13 Löschung, Rückgabe, Speicherdauer (Art. 28 Abs. 3 lit. g DSGVO)

**(1)** Nach Auftragsende Löschung **oder** Rückgabe nach Wahl des Verantwortlichen + Löschung der Kopien, außer gesetzliche Speicherpflicht. **(2) Produktive Löschfristen:** a) **Drafter:** Entwurfsinhalte + Eingaben **72 h nach Zustellung** automatisch genullt, spätestens nach **14 Tagen**; nicht zustellbar → nach 14 Tagen vollständig gelöscht; b) verschlüsselte Missbrauchs-Begrenzungsdaten (AES-256-GCM-verschlüsselte E-Mail zur Begrenzung missbräuchlicher Nutzung) werden im Rahmen des Lösch- und Sicherungskonzepts entfernt; c) **BV-Konto:** Arbeitsstand + Metadaten bestehen, solange das Konto besteht, und werden auf Löschverlangen über die Konto-Löschfunktion vollständig entfernt; eine automatische Inaktivitätslöschung ist nicht vorgesehen. **(3) Art. 11 Abs. 2 DSGVO** (nach Nullung keine Zuordnung → Auskunft/Löschung mangels Identifizierbarkeit nicht mehr erfüllbar). **(4) Backups** werden nach **spätestens 7 Tagen** im Sicherungszyklus überschrieben. Löschverlangen werden in einem nicht-identifizierenden Lösch-Register (Lebensdauer ≥ Backup-Retention) geführt; vor Wiederaufnahme des Produktivbetriebs nach einer Rücksicherung werden alle seit Erstellung des zurückgespielten Backups eingegangenen Löschungen erneut vollzogen und protokolliert - eine Rückführung gelöschter Daten in den Produktivbestand findet nicht statt. Die zeitbasierte Nullung (72 h/14 Tage, Abs. 2 lit. a) wirkt nach einer Rücksicherung zusätzlich. **(5)** Nachweis auf Verlangen.

---

## § 14 Unterstützung bei Betroffenenrechten (Art. 28 Abs. 3 lit. e DSGVO)

**(1)** Unterstützung bei Anträgen nach Art. 12–23 (Auskunft/Berichtigung/Löschung/Einschränkung/Datenübertragbarkeit/Widerspruch). **(2)** Bei Direktanfrage einer betroffenen Person: unverzügliche Weiterleitung an den Verantwortlichen, keine eigene Beantwortung ohne Weisung. **(3)** Über Selbstbedienungs-/Exportfunktionen hinausgehender Aufwand ggf. nach AGB vergütet.

---

## § 15 Unterstützung Sicherheit/Meldepflichten/DSFA (Art. 28 Abs. 3 lit. f, Art. 32–36 DSGVO)

**(1)** Unterstützung bei Art. 32–36. **(2) Meldung von Datenschutzverletzungen** an den Verantwortlichen **unverzüglich, spätestens 24 h nach Kenntnis** (Inhalt nach Art. 33 Abs. 3, soweit verfügbar; entspricht § 9 AGB; ermöglicht die 72-h-Frist des Verantwortlichen). **(3)** Sofortmaßnahmen; Meldung an Aufsichtsbehörde/Betroffene bleibt beim Verantwortlichen. **(4)** DSFA-Informationen auf Anfrage.

---

## § 16 Nachweise, Kontrollen, Audits (Art. 28 Abs. 3 lit. h DSGVO)

**(1)** Nachweis-Informationen zur Verfügung stellen. **(2)** Überprüfungen/Inspektionen ermöglichen + beitragen, vorrangig durch: a) Testate/Zertifikate/Berichte (soweit vorhanden); b) dokumentierte TOM (Anlage 2) + Konfigurationsnachweise + geschwärzte Logauszüge; c) schriftlichen Audit-Fragebogen. Gosign hält **keine förmlichen ISO-/SOC-Zertifikate**; die Architektur ist „Cert-Ready by Design" (ausgerichtet an ISA, PS 951, IDW sowie GoB/GoBD). Der Nachweis erfolgt daher nicht über Zertifikate, sondern über die TOM-Dokumentation (Anlage 2), Konfigurationsnachweise und den Audit-Fragebogen. Mitgliedschaft: BVDW. „Cert-Ready" ist ausdrücklich keine Zertifizierung. **(3) Vor-Ort-Prüfung** nach Vorankündigung (mind. 14 Kalendertage), Geschäftszeiten, max. 1×/Jahr (+ anlassbezogen), unter Wahrung der Vertraulichkeit (Mandantengeheimnisse + Geschäftsgeheimnisse), ggf. durch verschwiegenheitsverpflichteten Dritten. **(4)** Pen-Tests nach § 9 AGB. **(5)** Hinweis auf Weisungsverstoß (§ 6 Abs. 4). **(6)** Über Standardnachweise hinausgehender Aufwand ggf. nach AGB vergütet.

---

## § 17 Pflichten des Verantwortlichen

**(1)** Allein verantwortlich für Rechtmäßigkeit/Zulässigkeit (Art. 5, 6, ggf. 9). **(2)** Beachtung des Hinweises, **keine echten Beschäftigtendaten** einzugeben. **(3)** Eigene Informations-/Melde-/Dokumentationspflichten (Art. 13/14, 30, 33/34, 35); ggf. Einbindung der Arbeitnehmervertretung (§ 87 Abs. 1 Nr. 6 BetrVG, Art. 88 DSGVO). **(4)** Benennung weisungsberechtigter Ansprechpartner (Anlage 3); Freistellung Gosigns von Drittansprüchen aus rechtswidriger Datenüberlassung/Weisung nach Maßgabe der Gesetze/AGB.

---

## § 18 Haftung

**(1) Art. 82 DSGVO** im Außenverhältnis. **(2)** Innenverhältnis nach § 11 AGB, soweit mit zwingendem Datenschutzrecht vereinbar; Sub-AV-Haftung nach § 9 Abs. 4 (Art. 28 Abs. 4). **(3)** Keine Beschränkung gegenüber Betroffenen (Art. 82) oder bei Vorsatz/grober Fahrlässigkeit/Verletzung von Leben/Körper/Gesundheit.

---

## § 19 Beginn, Laufzeit, Beendigung

**(1) Click-Wrap-Akzeptanz:** Bestätigung von Firma, Handlungsbefugnis + AVV-Version (derzeit **v1-2026-06**) vor erster pbD-relevanter Nutzung; Zeitpunkt + Version dokumentiert. **(2)** Laufzeit = Nutzungsdauer; endet automatisch mit der zugrunde liegenden Nutzung. **(3) Nachwirkung:** §§ 7, 13 + Nachweismitwirkung. **(4) Versionierung:** Anpassung bei geänderten Anforderungen; Information + ggf. Akzeptanzpflicht der neuen Version; Versions-Label `vN-JJJJ-MM`.

---

## § 20 Schlussbestimmungen

**(1)** Änderungen mind. Textform (auch dieser Klausel); Individualvereinbarungen vorrangig. **(2)** Deutsches Recht (ohne UN-Kaufrecht); zwingende DSGVO unberührt. **(3)** Gerichtsstand Hamburg (bei Kaufleuten/jur. Personen d. öff. Rechts, soweit zulässig). **(4)** Deutsche Fassung maßgeblich. **(5)** Salvatorische Klausel. **(6)** Anlagen 1–4 sind Bestandteil.

---

## Anlage 1 - Beschreibung der Verarbeitung

| Merkmal | Festlegung |
|---|---|
| Gegenstand | pbD-Verarbeitung zur Bereitstellung BV-Konto + BV-KI-Drafter |
| Art | Erheben, Speichern, Übermitteln an Modell-Provider, Zustellen, Löschen/Nullen (§ 3) |
| Zweck | Arbeitsstand-Speicherung; Entwurfserzeugung + Zustellung; Missbrauchsbegrenzung |
| Dauer | Nutzungsdauer; Löschmechaniken § 13 (Drafter: 72 h / max. 14 Tage) |
| Betroffene | Beschäftigte/Bewerber, Arbeitnehmervertreter, ggf. Mandanten/Dritte, Nutzer (§ 4) |
| Datenkategorien | Stamm-/Kontakt-/Metadaten; KI-spezifisch: Prompts, Modellantworten, ggf. Dokumente/Embeddings (§ 5) |
| Art. 9 | Nicht vorgesehen; ggf. durch Freitext (§ 5 Abs. 3) |

---

## Anlage 2 - TOM (Art. 32 DSGVO)

> **Verfahren (Stand 2026-06, gegen den Betriebsstand verifiziert):** Verschlüsselung der Missbrauchs-E-Mail mit **AES-256-GCM** (12-Byte-Nonce pro Datensatz; Schlüssel als 32-Byte-Base64 aus dem Secret-Management/env, kein stiller Fallback). IP-Adressen werden nur als **gesalzener SHA-256-Hash** verarbeitet, nie im Klartext. Storage-/DB-Region: **self-hosted innerhalb der EU/des EWR** (von Gosign betriebene Infrastruktur). Backups werden nach **spätestens 7 Tagen** im Sicherungszyklus überschrieben (flache 7-Tage-Retention). Nach jeder Rücksicherung wird das Restore-Re-Löschungs-Verfahren angewandt - alle seit Erstellung des zurückgespielten Backups eingegangenen Löschungen werden erneut vollzogen und protokolliert (nicht-identifizierendes Lösch-Register, Lebensdauer ≥ Retention), sodass gelöschte Daten nicht reanimiert werden (§ 13 Abs. 4; Verfahren im Restore-Re-Löschungs-Runbook dokumentiert).

**1. Vertraulichkeit:** Zutritts-/Zugangs-/Zugriffskontrolle (Need-to-know, RBAC, Prod-/Dev-Trennung); Trennungskontrolle/Mandantenisolation; TLS-Übertragung + verschlüsselte Speicherung der Missbrauchs-E-Mail. **2. Integrität:** inhaltsdatenarmer Audit-Trail; verschlüsselte Übermittlung an Modell-Provider, keine Content-Retention über die Anfrage hinaus. **3. Verfügbarkeit/Belastbarkeit:** redundante Provider-Infrastruktur; Sicherungskonzept. **4. Regelmäßige Überprüfung:** Release-Prozess-Check der Logging-/Datenschutz-Einstellungen; Auftragskontrolle Sub-AV. **5. Datensparsamkeit/Privacy by Design (Art. 25):** Beispieldaten statt echter pbD; kurze Löschfristen; inhaltsdatenarmes Logging; cookielose Bereitstellung.

---

## Anlage 3 - Ansprechpartner

> Die Spalte „Verantwortlicher" wird beim Click-Wrap-Abschluss benannt; ein fester Wert dieses Vertrags besteht insoweit nicht.

| Rolle | Verantwortlicher | Gosign |
|---|---|---|
| Weisungsberechtigt/Datenschutz | beim Click-Wrap-Abschluss benannt | datenschutz@gosign.de |
| Technisch | beim Click-Wrap-Abschluss benannt | datenschutz@gosign.de |
| Datenschutzbeauftragter | sofern bestellt, beim Click-Wrap-Abschluss benannt | Nicht bestellt (§ 38 Abs. 1 BDSG); datenschutz@gosign.de |

---

## Anlage 4 - Genehmigte Sub-Auftragsverarbeiter (Stand v1-2026-06)

> Verifiziert (Stand 2026-06): Firmierung, Zweck, Verarbeitungsort/Region und Transfermechanismus je tatsächlich eingesetztem Anbieter. Es ist kein separater SMTP-Versanddienst eingesetzt - der E-Mail-Versand läuft über Google Workspace (Zeile 3).

| # | Sub-AV | Zweck | Ort | Transfer-Mechanismus |
|---|---|---|---|---|
| 1 | EU-/EWR-Modell-Provider | KI-Dienst (LLM zur Entwurfserzeugung) | EU/EWR | EU-Verarbeitung, keine Drittland-Übermittlung |
| 2 | Cloudflare, Inc. (USA) | Hosting/CDN (Pages), Routing (Workers, ohne Persistenz), KV-Speicherung | EU/global (KV) | DPF und/oder SCC; DPA vorhanden |
| 3 | Google Cloud EMEA / Google Ireland | E-Mail-Hosting (Workspace, EU) zur Zustellung | EU (IE) | AVV vorhanden; bei US-Zugriff: DPF und/oder SCC |
| 4 | Untergeordnete Modell-/LLM-Anbieter (EU/EWR) | Modellinferenz | EU/EWR | EU-Verarbeitung; Zero-Retention/No-Training soweit providerseitig verfügbar |

> **Abgrenzung (§ 9 Abs. 5):** im Standardbetrieb alle als Sub-AV von Gosign geführt; „Bring-your-own-Tenant" nicht vorgesehen, gesondert zu vereinbaren.

---

> **Ende des Entwurfs. ENTWURF - zur juristischen Prüfung durch die Rechtsabteilung der Gosign GmbH. Nicht rechtsverbindlich bis zur Freigabe. Stand v1-2026-06.**
> Die zuvor als „von Legal/Ops zu ergänzen" markierten operativen/faktischen Stellen sind mit **verifizierten Echtwerten befüllt (Stand 2026-06)**; der Text ist fachlich/operativ verifiziert befüllt und **freigabebereit**. Vor der Veröffentlichung steht die formale rechtsverbindliche Freigabe durch die Gosign GmbH aus (anwaltliche Schlussprüfung der Klausel-Formulierungen, finale Bestätigung der Anlagen 1–4, Verifikation des EU-US-DPF-Stands C-703/25 P + der Sub-AV-Ketten zum Freigabezeitpunkt).

### Quellen (web-verifiziert)

- Art. 28 DSGVO (dsgvo-gesetz.de, dejure.org)
- AVV-Muster Art. 28 Abs. 3 (LfDI Baden-Württemberg)
- EU-US Data Privacy Framework Status 2026; T-553/23 (Latombe) abgewiesen 03.09.2025; C-703/25 P anhängig (PwC Legal, EFAR)

--- Cert-Ready by Design ---
> Controls als First-Class-Datenobjekte. Automatische Evidence-Generierung. Live Auditor Portal. Strukturell prüfbereit - nicht nachträglich dokumentiert.

<!-- Das Prinzip -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Das Prinzip</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
In traditionellen Compliance-Ansätzen werden Controls in Dokumenten beschrieben, Evidence manuell gesammelt und Audits als periodische Projekte durchgeführt. Ein Prüfer fragt nach einem Nachweis, ein Mitarbeiter sucht einen Screenshot, jemand erstellt ein Excel.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Cert-Ready by Design kehrt das um: Controls sind technische Datenobjekte im System. Evidence wird automatisch erzeugt. Der Prüfer sieht den Live-Status - nicht einen Snapshot von letzter Woche.
</p>
</div>
</section>

<!-- Controls als First-Class-Datenobjekte -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Controls als First-Class-Datenobjekte</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Jeder Control in der Gosign-Architektur ist ein Datenobjekt mit vier Eigenschaften:
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">1. Technische Implementierung</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Der Control ist nicht nur dokumentiert, er ist implementiert. Beispiele: Eine RLS Policy die Mandantentrennung auf Datenbankebene erzwingt. Ein API-Check der vor jeder Agenten-Entscheidung die Regelversion validiert. Ein Trigger der bei Konfigurationsänderungen automatisch einen Audit-Eintrag schreibt.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Die Implementierung ist die Wahrheit - nicht ein Dokument das behauptet, die Implementierung existiere.
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">2. Automatischer Evidence-Generator</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Jeder Control hat einen zugeordneten Evidence-Generator. Der läuft periodisch oder event-basiert und erzeugt Nachweise automatisch. Kein Mensch sammelt Screenshots. Kein Mensch kopiert Logfiles in ein Excel. Das System erzeugt seine eigenen Nachweise.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Die kleinste Evidence-Einheit ist der <a href="/de/magazin/entscheidungsakt-anfechtbare-ki-entscheidungen/" class="text-gosign-accent-text hover:underline">Entscheidungsakt</a> pro Mikroentscheidung: ein unveränderlicher Nachweis mit Input, angewandter Fachregel samt Version, Konfidenz, Modellversion, Ergebnis, Zeitstempel und Anfechtungspfad - die Grundlage, auf der die Controls aufsetzen.
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">3. Evidence-History</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Jeder Evidence-Datensatz wird gespeichert mit Zeitstempel, Status (bestanden, fehlgeschlagen, Warnung), Versionsnummer des Controls, Versionsnummer der Prüflogik und Rohdaten für Drill-Down. Die History ist unveränderlich.
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">4. Auditor-View mit Drill-Down</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Der Prüfer sieht im Auditor Portal: Ampel-Status pro Control, letzter Evidence-Zeitstempel, Trend über Zeit, Drill-Down von der Ampel bis zur konkreten RLS Policy, zum Test-SQL, zum Testergebnis.
</p>
</div>
</div>
</section>

<!-- Drei Differenzierungsmerkmale -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">Drei Differenzierungsmerkmale</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Controls leben im System</h3>
<p class="text-body text-gosign-text-light mt-2">Nicht in Confluence. Nicht in einem Word-Dokument. Nicht in einer GRC-Software die einmal im Jahr aktualisiert wird. Controls sind Datenobjekte in der Datenbank - live, versioniert, testbar.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Evidence wird automatisch erzeugt</h3>
<p class="text-body text-gosign-text-light mt-2">Kein Mensch sammelt Nachweise. Der Evidence-Generator läuft automatisch - periodisch oder bei Änderung. Wenn ein Control seine Evidence nicht erzeugen kann, ist das selbst ein Finding.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Vollständiger Drill-Down</h3>
<p class="text-body text-gosign-text-light mt-2">Von der Ampel im Dashboard bis zur konkreten RLS Policy mit ihrem Namen und dem Test-SQL das ihre Wirksamkeit prüft. Kein „fragen Sie den Entwickler". Alles in einem Pfad.</p>
</div>
</div>
</div>
</section>

<!-- Auditor Portal -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Auditor Portal</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Das Auditor Portal ist die Schnittstelle zwischen dem technischen System und dem Prüfer. Es bietet:
</p>
<div class="mt-6 space-y-4">
<p class="text-body-lg text-gosign-text-light"><strong>Dashboard:</strong> Übersicht aller Controls mit Ampel-Status, gruppiert nach Framework-Kategorie.</p>
<p class="text-body-lg text-gosign-text-light"><strong>Control-Detail:</strong> Beschreibung, technische Implementierung, Evidence-History, letzte Änderung, zuständiger Owner.</p>
<p class="text-body-lg text-gosign-text-light"><strong>Drill-Down:</strong> Von der Übersicht bis zum konkreten Test-Ergebnis, inklusive Prüflogik und Rohdaten.</p>
<p class="text-body-lg text-gosign-text-light"><strong>Export:</strong> Evidence-Pakete für externe Prüfer, maschinenlesbar (JSON) oder als PDF-Report.</p>
<p class="text-body-lg text-gosign-text-light"><strong>Change-History:</strong> Wann wurde ein Control geändert, von wem, warum. Jede Änderung dokumentiert.</p>
<p class="text-body-lg text-gosign-text-light"><strong>Override-History:</strong> Wenn ein Human Override eine Agenten-Entscheidung überstimmt hat - dokumentiert mit Begründung, Person, Zeitstempel.</p>
</div>
</div>
</div>
</section>

<!-- Control Object Struktur -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Cert-Ready Control Object - Struktur</h2>
</div>
<div class="mt-8">
<pre class="bg-gosign-dark text-white p-6 rounded-card overflow-x-auto text-small font-mono leading-relaxed"><code>Control Object {
id:                 "ctrl-rbac-001"
name:               "Mandantentrennung auf Datenbankebene"
category:           "Zugriffskontrolle"

implementation: {
type:             "RLS Policy"
reference:        "policies/tenant_isolation.sql"
deployed:         true
last_verified:    "2026-02-20T09:14:00Z"
}

evidence_generator: {
type:             "automated_test"
schedule:         "every_6h"
test_reference:   "tests/tenant_isolation_test.sql"
}

evidence_history: [
{
timestamp:      "2026-02-20T09:14:00Z"
status:         "passed"
control_version: "1.3"
test_version:   "2.1"
raw_data:       { "rows_tested": 42 }
}
]

framework_mapping: {
iso_27001:        "A.9.4.1"
soc2:             "CC6.1"
eu_ai_act:        "Art. 12"
}

owner:              "security-team"
last_change:        "2026-02-18T14:22:00Z"
change_reason:      "Policy update for new entity"
}</code></pre>
</div>
</div>
</section>

<!-- Framework-Mapping -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Framework-Mapping</h2>
<p class="text-body-lg text-gosign-accent-text font-semibold mt-4">Die Control-Struktur ist framework-agnostisch. Jeder Control kann auf mehrere Frameworks gemappt werden.</p>
<ul class="mt-6 space-y-3">
<li class="text-body-lg text-gosign-text-light"><a href="https://www.iso.org/isoiec-27001-information-security.html" target="_blank" rel="noopener noreferrer">ISO 27001</a>: Annex A Controls</li>
<li class="text-body-lg text-gosign-text-light">SOC2: Trust Service Criteria</li>
<li class="text-body-lg text-gosign-text-light">PS 951 / ISAE 3402: Prüfungsstandards für IT-Dienstleister</li>
<li class="text-body-lg text-gosign-text-light">EU AI Act: Transparenz-, Aufzeichnungs- und Aufsichtspflichten</li>
<li class="text-body-lg text-gosign-text-light">IDW PS 880: Softwareprüfung</li>
<li class="text-body-lg text-gosign-text-light">GoB / GoBD: Grundsätze ordnungsmäßiger Buchführung</li>
</ul>
</div>
</div>
</section>

<!-- Was Cert-Ready by Design nicht ist -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Was Cert-Ready by Design nicht ist</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong>Kein Zertifizierungsversprechen.</strong> Cert-Ready by Design bedeutet nicht, dass das System zertifiziert ist. Es bedeutet, dass die Architektur strukturell darauf vorbereitet ist, jederzeit geprüft und zertifiziert zu werden.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong>Keine GRC-Software.</strong> Cert-Ready by Design ersetzt keine GRC-Plattform. Es ergänzt sie - durch technische Controls die live im System existieren, nicht nur in einer separaten Compliance-Datenbank.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong>Kein einmaliges Audit.</strong> Cert-Ready by Design ist kontinuierlich. Evidence wird laufend erzeugt, Controls werden laufend geprüft. Es gibt keinen „Audit-Modus" - das System ist immer im Audit-Modus.
</p>
</div>
</div>
</section>

<!-- Vertiefung -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Vertiefung im Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Unsere Fachartikel-Serie für Entscheider, die AI Agents im Unternehmen einführen.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/de/magazin/cert-ready-by-design/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Cert-Ready by Design - Prüfungssichere KI von Anfang an</p>
</a>
<a href="/de/magazin/eu-ai-act-hr/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">EU AI Act und HR - Was jetzt Pflicht ist</p>
</a>
<a href="/de/magazin/ki-governance-dashboard/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">KI-Governance-Dashboard: Agent-Monitoring für Unternehmen</p>
</a>
</div>
</div>
</section>

--- Datenresidenz & DSGVO ---
> Datenhoheit für Enterprise AI-Agenten. EU-only Processing, Row-Level Security, Mandantentrennung, keine Datenabflüsse an Dritte.

<!-- Grundprinzip -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Grundprinzip</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
AI-Agenten verarbeiten geschäftskritische Daten: Personaldaten, Finanzdaten, Vertragsdaten. Die Frage wo diese Daten verarbeitet werden und wer darauf Zugriff hat, ist für Enterprise-Kunden nicht verhandelbar. Der <a href="/de/magazin/decision-layer-erklaert/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Decision Layer</a> zerlegt jeden Prozess in Entscheidungsschritte und definiert für jeden Schritt, ob Mensch, Regelwerk oder KI entscheidet - einschließlich der Frage, welche Daten dafür verarbeitet werden dürfen.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Die Gosign-Architektur basiert auf einem Grundprinzip: Alle Daten verbleiben in der Infrastruktur des Kunden. Gosign betreibt keine eigene Cloud, speichert keine Kundendaten und hat keinen permanenten Zugriff auf Produktionssysteme. Die vollständige <a href="/de/governance/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Governance-Architektur</a> stellt sicher, dass jede Datenverarbeitung dokumentiert und nachvollziehbar bleibt.
</p>
</div>
</div>
</section>

<!-- Deployment-Optionen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">Deployment-Optionen</h2>
<div class="grid grid-cols-1 md:grid-cols-2 gap-6 lg:gap-8">
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 15a4.5 4.5 0 0 0 4.5 4.5H18a3.75 3.75 0 0 0 .75-7.425A4.502 4.502 0 0 0 14.25 7.5a5.25 5.25 0 0 0-10.233 2.033A4.5 4.5 0 0 0 2.25 15Z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Azure (EU)</h3>
<p class="text-body text-gosign-text-light mt-3">
<a href="https://azure.microsoft.com/en-us/explore/global-infrastructure/geographies/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Azure</a>-Regionen: West Europe (Amsterdam), North Europe (Dublin), Germany West Central (Frankfurt). Azure OpenAI für LLM-Verarbeitung innerhalb Azure EU. Datenschutz über Microsofts DPA und EU Data Processing Addendum.
</p>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">GCP (EU)</h3>
<p class="text-body text-gosign-text-light mt-3">
<a href="https://cloud.google.com/about/locations" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">GCP</a>-Regionen: europe-west1 (Belgien), europe-west3 (Frankfurt), europe-west4 (Niederlande). Vertex AI für LLM-Verarbeitung innerhalb GCP EU. Datenschutz über Googles DPA und EU Standard Contractual Clauses.
</p>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M5.25 14.25h13.5m-13.5 0a3 3 0 0 1-3-3m3 3a3 3 0 1 0 0 6h13.5a3 3 0 1 0 0-6m-16.5-3a3 3 0 0 1 3-3h13.5a3 3 0 0 1 3 3m-19.5 0a4.5 4.5 0 0 1 .9-2.7L5.737 5.1a3.375 3.375 0 0 1 2.7-1.35h7.126c1.062 0 2.062.5 2.7 1.35l2.587 3.45a4.5 4.5 0 0 1 .9 2.7m0 0a3 3 0 0 1-3 3m0 3h.008v.008h-.008v-.008Zm0-6h.008v.008h-.008v-.008Zm-3 6h.008v.008h-.008v-.008Zm0-6h.008v.008h-.008v-.008Z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">AWS (EU)</h3>
<p class="text-body text-gosign-text-light mt-3">
<a href="https://aws.amazon.com/about-aws/global-infrastructure/regions_az/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">AWS</a>-Regionen: eu-central-1 (Frankfurt), eu-west-1 (Ireland), eu-west-3 (Paris). Amazon Bedrock für LLM-Hosting (Claude, Llama, Mistral) innerhalb AWS EU. Amazon EKS für Container-Orchestrierung, Aurora PostgreSQL für Daten. Datenschutz über AWS DPA und EU Data Processing Addendum.
</p>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 17.25v1.007a3 3 0 0 1-.879 2.122L7.5 21h9l-.621-.621A3 3 0 0 1 15 18.257V17.25m6-12V15a2.25 2.25 0 0 1-2.25 2.25H5.25A2.25 2.25 0 0 1 3 15V5.25A2.25 2.25 0 0 1 5.25 3h13.5A2.25 2.25 0 0 1 21 5.25Z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Self-Hosted</h3>
<p class="text-body text-gosign-text-light mt-3">
Eigenes Rechenzentrum oder eigener Server. Open-Source-Modelle: <a href="https://llama.meta.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Llama</a>, <a href="https://mistral.ai/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Mistral</a>, <a href="https://www.deepseek.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">DeepSeek</a> - lokal betrieben. Keine Daten verlassen das Unternehmensnetzwerk. Vollständige Kontrolle über Hardware, Software und Netzwerk.
</p>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M7.5 21 3 16.5m0 0L7.5 12M3 16.5h13.5m0-13.5L21 7.5m0 0L16.5 12M21 7.5H7.5" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Hybrid</h3>
<p class="text-body text-gosign-text-light mt-3">
Kombination aus Cloud und Self-Hosted. Beispiel: Self-Hosted für sensible HR-Daten, Azure EU für Dokumentenverarbeitung. Die Architektur unterstützt unterschiedliche Deployment-Optionen pro Agent.
</p>
</article>
</div>
</div>
</section>

<!-- Technische Datenschutzmassnahmen -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Technische Datenschutzmaßnahmen</h2>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">Row-Level Security (RLS)</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Mandantentrennung wird auf Datenbankebene durchgesetzt - nicht auf Anwendungsebene. Ein SQL-Query kann physisch nur auf die Datensätze zugreifen, für die der ausführende Kontext berechtigt ist. Die Trennung ist nicht umgehbar durch Anwendungslogik.
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">Verschlüsselung</h3>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light"><strong>At Rest:</strong> Alle Daten werden verschlüsselt gespeichert (AES-256)</li>
<li class="text-body-lg text-gosign-text-light"><strong>In Transit:</strong> Alle Datenübertragungen über TLS 1.3</li>
<li class="text-body-lg text-gosign-text-light"><strong>Schlüsselmanagement:</strong> Kundeneigene Schlüssel (Bring Your Own Key) oder Plattform-managed</li>
</ul>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">Zugriffskontrolle</h3>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light">RBAC (Role-Based Access Control) auf allen Ebenen</li>
<li class="text-body-lg text-gosign-text-light">Keine Shared Credentials, kein Service-Account mit Vollzugriff</li>
<li class="text-body-lg text-gosign-text-light">Zugriffe werden geloggt und sind im Audit Trail nachvollziehbar</li>
<li class="text-body-lg text-gosign-text-light">Gosign hat keinen permanenten Zugriff auf Produktionsdaten</li>
</ul>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">Datenlöschung</h3>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light">Löschkonzept nach DSGVO Art. 17</li>
<li class="text-body-lg text-gosign-text-light">Aufbewahrungsfristen konfigurierbar pro Datentyp</li>
<li class="text-body-lg text-gosign-text-light">Löschung umfasst alle Kopien - Datenbank, Audit Trail, Backups (nach Ablauf der Backup-Retention)</li>
<li class="text-body-lg text-gosign-text-light">Löschprotokolle im Audit Trail dokumentiert</li>
</ul>
</div>
</div>
</section>

<!-- LLM-spezifische Datenschutzfragen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">LLM-spezifische Datenschutzfragen</h2>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">Cloud-LLMs (Azure OpenAI, Vertex AI, Amazon Bedrock)</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Wenn Cloud-LLMs eingesetzt werden, werden die zu verarbeitenden Daten an den LLM-Dienst gesendet. Maßnahmen: Daten werden nicht für das Training verwendet (Zusage von Microsoft/Google), DPA/SCCs mit dem jeweiligen Anbieter, Datenminimierung. Die <a href="/de/magazin/pii-anonymisierung-llm-enterprise/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">PII-Anonymisierung</a> stellt sicher, dass personenbezogene Daten vor der LLM-Verarbeitung entfernt werden.
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">Self-Hosted-Modelle (Llama, Mistral, DeepSeek)</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Bei Self-Hosted-Modellen verlassen keine Daten die Kundeninfrastruktur. Das Modell läuft lokal, die Verarbeitung erfolgt auf eigener Hardware. Trade-off: Self-Hosted-Modelle sind in der Regel weniger leistungsfähig als die neuesten proprietären Modelle. Mehr zu Hosting-Strategien im Artikel <a href="/de/magazin/ki-hosting-strategien-enterprise/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">KI-Hosting: EU-SaaS, deutsches RZ oder Self-Hosted?</a>
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">Kein Training auf Kundendaten</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Gosign AI-Agenten werden nicht auf Kundendaten trainiert. Es findet kein Fine-Tuning, kein Re-Training und kein unkontrolliertes Lernen aus Produktionsdaten statt.
</p>
</div>
</div>
</section>

<!-- DSGVO-Zuordnung -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">DSGVO-Zuordnung</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Jede Architekturkomponente ist einem konkreten DSGVO-Artikel zugeordnet. Details zur Umsetzung im Kontext des <a href="/de/governance/eu-ai-act/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">EU AI Act</a>.
</p>
<div class="mt-8 overflow-x-auto">
<table class="w-full text-left text-small border-collapse">
<thead>
<tr>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">DSGVO-Artikel</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Architektonische Maßnahme</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Art. 5 - Datenminimierung</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Nur erforderliche Daten werden verarbeitet. Keine Vorratsspeicherung.</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Art. 6 - Rechtsgrundlage</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Auftragsverarbeitung (Art. 28) oder berechtigtes Interesse, je nach Einsatzkontext</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Art. 17 - Recht auf Löschung</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Löschkonzept mit konfigurierbaren Fristen, dokumentierte Löschung</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Art. 25 - Privacy by Design</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">RLS, Verschlüsselung, RBAC als Architekturkomponenten</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Art. 28 - Auftragsverarbeitung</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">DPA zwischen Kunde und Gosign, DPA zwischen Kunde und Cloud-Anbieter</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Art. 30 - Verzeichnis</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Audit Trail dokumentiert alle Verarbeitungsvorgänge</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Art. 32 - Sicherheit</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Verschlüsselung, Zugriffskontrolle, regelmäßige Prüfung</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Art. 33/34 - Meldepflichten</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Incident-Response-Prozess, Audit Trail für Forensik</td></tr>
</tbody>
</table>
</div>
</div>
</div>
</section>

<!-- Abgrenzung -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<p class="text-body-lg text-gosign-text-light">
Diese Seite beschreibt technische Architekturmaßnahmen für Datenschutz und Datenresidenz. Die datenschutzrechtliche Bewertung und die formale DSGVO-Konformitätserklärung obliegen dem Verantwortlichen (dem Kunden) und seinen Datenschutzbeauftragten. Gosign liefert die technische Infrastruktur. Die rechtliche Verantwortung liegt beim Betreiber.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Für Berufsgeheimnisträger - Anwälte, Steuerberater, Wirtschaftsprüfer - gelten über die hier beschriebene DSGVO- und Residenz-Ebene hinaus zusätzliche Anforderungen: § 203 StGB und das Berufsrecht (§ 43e BRAO, § 62a StBerG, § 50a WPO) verlangen eine eigene Verschwiegenheits-Vertragskette, die weder EU-Region noch AVV ersetzt. Diesen Sonderfall behandelt der eigene Bereich <a href="/de/berufsgeheimnistraeger/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">KI für Berufsgeheimnisträger (§ 203 StGB)</a>.
</p>
</div>
</div>
</section>

<!-- Vertiefung -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Vertiefung im Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Unsere Fachartikel-Serie für Entscheider, die AI Agents im Unternehmen einführen.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/de/magazin/pii-anonymisierung-llm-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">PII-Anonymisierung für Enterprise AI</p>
</a>
<a href="/de/magazin/datensicherheit-ki-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Datensicherheit bei KI - Data Residency, DSGVO und EU AI Act</p>
</a>
<a href="/de/magazin/ki-hosting-strategien-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">KI-Hosting: EU-SaaS, deutsches RZ oder Self-Hosted?</p>
</a>
</div>
</div>
</section>

--- EU AI Act Readiness ---
> Wie die Gosign-Architektur die Anforderungen des EU AI Act an Transparenz, menschliche Aufsicht, Aufzeichnung und Risikomanagement als Designprinzip adressiert.

<!-- Relevanz -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">EU AI Act - Relevanz für Enterprise AI-Agenten</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Der <a href="https://eur-lex.europa.eu/eli/reg/2024/1689/oj" target="_blank" rel="noopener noreferrer">EU AI Act (Verordnung (EU) 2024/1689)</a> reguliert KI-Systeme in der Europäischen Union. Für Enterprise AI-Agenten die automatisierte oder teilautomatisierte Entscheidungen in geschäftskritischen Prozessen treffen, sind insbesondere vier Bereiche relevant.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Die Gosign-Architektur adressiert diese Bereiche als Designprinzip - nicht als nachträglichen Compliance-Layer.
</p>
</div>
</section>

<!-- Vier architektonische Antworten -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">Fünf architektonische Antworten</h2>

<div class="max-w-narrow space-y-12">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Art. 13 - Transparenz</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong>Anforderung:</strong> Hochrisiko-KI-Systeme müssen so konzipiert sein, dass ihr Betrieb hinreichend transparent ist.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong>Architektonische Umsetzung:</strong> Der Decision Layer dokumentiert jeden Entscheidungspfad vollständig: Input, Modell und Version, fachliche Bewertung, Confidence, angewandtes Regelwerk und Version, resultierendes Ergebnis. Der Audit Trail macht diese Information für Nutzer, Prüfer und Betriebsräte zugänglich.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark">Art. 14 - Menschliche Aufsicht</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong>Anforderung:</strong> Hochrisiko-KI-Systeme müssen so konzipiert sein, dass sie von natürlichen Personen wirksam beaufsichtigt werden können.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong>Architektonische Umsetzung:</strong> Human-in-the-Loop ist ein architektonisch erzwungenes Routing. Bei Bias-Risiko, Diskriminierungspotenzial, Mitbestimmungsthemen oder niedriger Confidence wird automatisch ein Mensch eingebunden. Dieses Routing kann nicht durch Konfigurationsänderung umgangen werden.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark">Art. 12 - Aufzeichnungspflichten</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong>Anforderung:</strong> Hochrisiko-KI-Systeme müssen so konzipiert sein, dass sie automatisch Protokolle generieren.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong>Architektonische Umsetzung:</strong> Der Audit Trail erfasst für jede Agenten-Entscheidung: Zeitstempel (UTC), Input-Hash, Modellversion, Regelversion, Confidence Score, Entscheidungspfad, Ergebnis. Unveränderlich, exportierbar (JSON, CSV, PDF), maschinenlesbar, vollständig.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark">Art. 9 - Risikomanagement</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong>Anforderung:</strong> Für Hochrisiko-KI-Systeme muss ein Risikomanagementsystem eingerichtet werden.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong>Architektonische Umsetzung:</strong> Der Governance Layer implementiert: <strong>Bias-Monitoring</strong> (statistische Überwachung auf systematische Verzerrungen), <strong>Confidence-Tracking</strong> (Überwachung der Confidence-Scores über Zeit), <strong>Anomalie-Erkennung</strong> (Erkennung abweichender Entscheidungsmuster), <strong>Cert-Ready Controls</strong> (Controls als Datenobjekte mit automatischer Evidence-Generierung).
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark">Art. 86 - Recht auf Erläuterung der Einzelentscheidung</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong>Anforderung:</strong> Betroffene Personen haben gegenüber dem Betreiber Anspruch auf eine klare und aussagekräftige Erläuterung der Rolle des KI-Systems im Entscheidungsprozess und der wichtigsten Elemente der getroffenen Entscheidung - pro Einzelfall, nicht pro System.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong>Architektonische Umsetzung:</strong> Jede Mikroentscheidung erzeugt einen Entscheidungsakt: Input, angewandte Fachregel samt Version und Quelle, Konfidenz, Modellversion, Ergebnis, Anfechtungspfad. Die Art.-86-Anfrage eines Betroffenen wird damit zur Abfrage statt zum Forensik-Projekt. <a href="/de/magazin/entscheidungsakt-anfechtbare-ki-entscheidungen/" class="text-gosign-accent-text hover:underline font-semibold">Der Entscheidungsakt im Detail →</a>
</p>
</div>
</div>
</div>
</section>

<!-- Risikoklassifizierung -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Risikoklassifizierung</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Die Einstufung eines AI-Systems in eine Risikoklasse des EU AI Act hängt vom konkreten Einsatzzweck ab:
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong>Potenziell Hochrisiko</strong> (je nach Kontext): AI-Agenten die Personalentscheidungen vorbereiten oder beeinflussen, die in der Kreditwürdigkeitsprüfung eingesetzt werden oder die Zugang zu wesentlichen Dienstleistungen beeinflussen.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong>Nicht Hochrisiko</strong> (typischerweise): Document Agents die Dokumente klassifizieren ohne Personalentscheidungen zu treffen, Knowledge Agents die Informationen bereitstellen ohne Entscheidungen zu treffen.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Die Gosign-Architektur ist auf die strengsten Anforderungen ausgelegt. Wenn ein Agent in einem Hochrisiko-Kontext eingesetzt wird, sind die architektonischen Voraussetzungen bereits vorhanden.
</p>
</div>
</div>
</section>

<!-- Abgrenzung -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Abgrenzung</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong>Diese Seite beschreibt architektonische Maßnahmen, nicht rechtliche Konformität.</strong> Die tatsächliche EU AI Act Compliance hängt vom konkreten Einsatzkontext, der Risikoklassifizierung und der rechtlichen Bewertung im Einzelfall ab.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Gosign liefert die technische Architektur die die Anforderungen des EU AI Act adressiert. Die rechtliche Bewertung und die formale Konformitätserklärung obliegen dem Betreiber und seinen Rechtsberatern.
</p>
</div>
</div>
</section>

<!-- Zusammenfassung -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Zusammenfassung</h2>
<ul class="mt-6 space-y-3">
<li class="text-body-lg text-gosign-text-light">Transparenz durch vollständige Entscheidungsdokumentation im Decision Layer</li>
<li class="text-body-lg text-gosign-text-light">Menschliche Aufsicht durch architektonisch erzwungenes Human-in-the-Loop-Routing</li>
<li class="text-body-lg text-gosign-text-light">Aufzeichnungspflichten durch unveränderlichen, exportierbaren Audit Trail</li>
<li class="text-body-lg text-gosign-text-light">Risikomanagement durch Bias-Monitoring, Confidence-Tracking und Cert-Ready Controls</li>
<li class="text-body-lg text-gosign-text-light">Erläuterung der Einzelentscheidung (Art. 86) durch den Entscheidungsakt pro Mikroentscheidung</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-4">
Das ist eine Architekturaussage, kein Konformitätszertifikat.
</p>
</div>
</div>
</section>

<!-- Vertiefung -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Vertiefung im Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Unsere Fachartikel-Serie für Entscheider, die AI Agents im Unternehmen einführen.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/de/magazin/eu-ai-act-hr/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">EU AI Act und HR - Was jetzt Pflicht ist</p>
</a>
<a href="/de/magazin/eu-ai-act-hr-hochrisiko/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">EU AI Act und HR: Was für KI in Personalentscheidungen gilt (Frist 2026/2027)</p>
</a>
<a href="/de/magazin/cert-ready-by-design/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Cert-Ready by Design - Prüfungssichere KI von Anfang an</p>
</a>
</div>
</div>
</section>

--- Mitbestimmung & Betriebsrat ---
> AI-Agenten betriebsratsfähig gestalten. Human-in-the-Loop, Betriebsvereinbarungen als System-Constraints, Audit Trail und RBAC

<!-- Warum Mitbestimmung ein Architekturthema ist -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Warum Mitbestimmung ein Architekturthema ist</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
AI-Agenten die in HR-Prozessen, Personalentscheidungen oder Arbeitnehmer-relevanten Abläufen eingesetzt werden, unterliegen in Deutschland der Mitbestimmung. Das ist kein optionaler Compliance-Layer - es ist eine gesetzliche Anforderung nach dem Betriebsverfassungsgesetz.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Der Decision Layer zerlegt jeden HR-Prozess in einzelne Entscheidungsschritte und definiert für jeden Schritt: Mensch, Regelwerk oder KI. Betriebsvereinbarungen werden dabei als technische Constraints implementiert - der Agent kann sie nicht umgehen. Der Audit Trail dokumentiert jede einzelne Entscheidung.
</p>
</div>
</section>

<!-- Rechtlicher Rahmen -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Rechtlicher Rahmen</h2>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">&sect; 87 Abs. 1 Nr. 6 BetrVG</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Der Betriebsrat hat ein Mitbestimmungsrecht bei der „Einführung und Anwendung von technischen Einrichtungen, die dazu bestimmt sind, das Verhalten oder die Leistung der Arbeitnehmer zu überwachen."
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">&sect; 90 BetrVG - Planung</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Der Betriebsrat ist frühzeitig über die Einführung neuer technischer Anlagen zu unterrichten. Das betrifft die Planungsphase von AI-Agenten, nicht erst den Go-Live.
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">&sect; 80 Abs. 1 Nr. 1 BetrVG - Überwachung</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Der Betriebsrat hat die Aufgabe darüber zu wachen, dass die zugunsten der Arbeitnehmer geltenden Vorschriften durchgeführt werden. Dafür braucht er Zugang zu den Entscheidungen und Regeln des Agenten.
</p>
</div>
</section>

<!-- Architektonische Umsetzung -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Architektonische Umsetzung</h2>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">1. Betriebsvereinbarungen als System-Constraints</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Betriebsvereinbarungen werden im Decision Layer als explizite Constraints abgebildet. Jede Betriebsvereinbarung wird als Regelwerk übersetzt. Jeder Constraint hat eine Versions-ID, ein Gültigkeitsdatum und einen Geltungsbereich. Der Agent prüft vor jeder Entscheidung automatisch gegen die hinterlegten Constraints. Wenn eine Betriebsvereinbarung verletzt würde, wird die Entscheidung nicht autonom durchgeführt.
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">2. Human-in-the-Loop als Architekturprinzip</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong>Autonome Entscheidung</strong> bei: Hoher Confidence UND niedrigem Risiko-Score UND kein BV-Constraint betroffen.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong>Human-in-the-Loop</strong> bei: Bias-Risiko oder Diskriminierungspotenzial, mitbestimmungsrelevante Themen, niedriger Confidence, BV-Constraint betroffen, erstmalige Entscheidung ohne Präzedenzfall.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Das Routing ist architektonisch erzwungen. Es kann nicht durch eine Konfigurationsänderung umgangen werden.
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">3. Audit Trail für den Betriebsrat</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Jede Agenten-Entscheidung erzeugt einen vollständigen Audit-Trail-Eintrag:
</p>
<pre class="bg-gosign-dark text-white p-6 rounded-card overflow-x-auto text-small font-mono leading-relaxed mt-4"><code>Audit-Trail Eintrag:
├── Zeitstempel:        2026-02-20T09:14:22Z
├── Agent:              hr-merit-cycle-agent
├── Input:              Gehaltsanpassung Mitarbeiter #4711
├── Angewandte Regeln:
│   ├── Tarifvertrag:   TV-V, Version 2025.2
│   ├── BV-Gehalt:      BV-2024-003, § 4 Abs. 2
│   └── Salary Band:    Band E3, Range 52.000-68.000 EUR
├── Bewertung:
│   ├── Confidence:     0.94
│   ├── Risiko-Score:   niedrig
│   └── Ergebnis:       Innerhalb Band, innerhalb BV-Constraint
├── Entscheidungspfad:  autonom (kein BV-Constraint verletzt)
├── Output:             Buchungsvorschlag: Anpassung +3,2%
└── Status:             freigegeben</code></pre>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">4. Rollenkonzept (RBAC)</h3>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light"><strong>Agent-Operator:</strong> Konfiguriert Agenten, ändert Regelwerke (versioniert, dokumentiert)</li>
<li class="text-body-lg text-gosign-text-light"><strong>HR-Sachbearbeiter:</strong> Sieht Agenten-Entscheidungen im eigenen Zuständigkeitsbereich</li>
<li class="text-body-lg text-gosign-text-light"><strong>Betriebsrat:</strong> Einsicht in Entscheidungsmuster, Constraint-Status, Audit Trail</li>
<li class="text-body-lg text-gosign-text-light"><strong>Prüfer / Revision:</strong> Vollzugriff auf Audit Trail, Evidence, Control-Status</li>
<li class="text-body-lg text-gosign-text-light"><strong>Admin:</strong> Systemkonfiguration, kein Zugriff auf fachliche Entscheidungsdaten</li>
</ul>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">5. Vorlagen und Dokumentation</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Gosign stellt Vorlagen bereit für: <strong>Betriebsvereinbarung KI-Einsatz</strong>, <strong>Technische Beschreibung für den Betriebsrat</strong>, <strong>Logging-Konzept</strong> und <strong>Eskalationsmatrix</strong>. Diese Vorlagen sind Ausgangspunkte. Jede Betriebsvereinbarung muss individuell verhandelt werden.
</p>
</div>
</section>

<!-- Was wir nicht tun -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Was wir nicht tun</h2>
<ul class="mt-6 space-y-3">
<li class="text-body-lg text-gosign-text-light">Wir ersetzen keine Betriebsvereinbarungen. Wir bilden sie technisch ab.</li>
<li class="text-body-lg text-gosign-text-light">Wir beraten nicht rechtlich. Wir liefern die technische Infrastruktur.</li>
<li class="text-body-lg text-gosign-text-light">Wir automatisieren keine Entscheidungen die der Mitbestimmung unterliegen, ohne Human-in-the-Loop.</li>
<li class="text-body-lg text-gosign-text-light">Wir „trainieren" Agenten nicht auf Basis von Betriebsratsentscheidungen. Agenten lernen nicht unkontrolliert.</li>
</ul>
</div>
</section>

<!-- Zusammenfassung -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-body-lg text-gosign-text-light">
Mitbestimmung bei AI-Agenten ist kein Workshop-Thema. Es ist ein Architekturthema. Die Gosign-Architektur stellt technisch sicher, dass Betriebsvereinbarungen eingehalten werden, dass der Betriebsrat nachvollziehen kann was der Agent tut, und dass Human-in-the-Loop dort erzwungen wird wo er erforderlich ist.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Agenten werden Teil Ihrer bestehenden IT-Governance - nicht eine neue Parallelwelt.
</p>
</div>
</section>

<!-- Vertiefung -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Vertiefung im Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Unsere Fachartikel-Serie für Entscheider, die AI Agents im Unternehmen einführen.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/de/magazin/betriebsrat-ki-mitbestimmung/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Betriebsrat und KI - Mitbestimmung als Architektur-Constraint</p>
</a>
<a href="/de/magazin/agent-governance-hr/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Agent Governance für HR - Warum der CHRO dieses Thema führen muss</p>
</a>
<a href="/de/magazin/human-in-the-loop-architektur/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Human-in-the-Loop - Architekturprinzip, nicht Checkbox</p>
</a>
</div>
</div>
</section>

--- Referenz-Architektur: 7 Layer für Enterprise AI ---
> 7-Layer-Architektur für Enterprise AI-Agenten. Governance by Design, modell-agnostisch, infrastruktur-agnostisch. Für CTOs und Engineering-Entscheider.

<!-- Überblick -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Warum sieben Layer</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Ein monolithisches AI-System ist nicht auditierbar, nicht skalierbar und nicht wartbar. Die 7-Layer-Architektur trennt Verantwortlichkeiten: Jeder Layer hat eine definierte Aufgabe und klare Schnittstellen. Ein Modellwechsel ändert nicht die Geschäftslogik. Ein neues Zielsystem ändert nicht den Agenten. Eine neue Compliance-Anforderung ändert nicht die Infrastruktur.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Die Architektur ist das Ergebnis von Enterprise-Anforderungen: Mandantentrennung, Audit Trail, Betriebsrats-Transparenz, EU AI Act-Konformität, modell-agnostisches Deployment. Standard-LLM-APIs liefern nichts davon.
</p>
</div>
<img src="/images/diagrams/reference-architecture.svg" alt="Referenz-Architektur: 7 Layer mit Governance als Querschicht - Presentation, Orchestration, Agent, Decision Layer, Model, Integration, Infrastructure" class="w-full rounded-card mt-8" width="1200" height="600" loading="lazy" />
</div>
</section>

<!-- Layer 1: Presentation -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">1. Presentation Layer</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Die Schnittstelle zwischen System und Nutzer. Keine Geschäftslogik, keine Entscheidungen - nur Darstellung und Eingabe.
</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light"><strong>Chat UI:</strong> Webbasierte Oberfläche für Endnutzer (HR-Sachbearbeiter, Buchhalter). PWA-fähig, responsive.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Dashboard:</strong> Statusübersicht für Agenten, laufende Workflows, offene Eskalationen. Rollenbasiert: Sachbearbeiter sehen ihre Fälle, Manager sehen Kennzahlen.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Auditor Portal:</strong> Prüfer-Zugang zu Audit Trail, Controls, Evidence. Read-only. Für Wirtschaftsprüfer, Betriebsrat, interne Revision.</li>
<li class="text-body-lg text-gosign-text-light"><strong>REST API:</strong> Maschinenlesbare Schnittstelle für Integration in bestehende Systeme. Versioniert, dokumentiert, authentifiziert.</li>
</ul>
</div>
</div>
</section>

<!-- Layer 2: Orchestration -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">2. Orchestration Layer</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Koordiniert den Datenfluss zwischen Agenten, Systemen und Nutzern. Verwaltet Workflows, Queues und API-Routing.
</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light"><strong>Workflow-Engine:</strong> Open-Source Engines (Trigger.dev, Camunda) für komplexe, mehrstufige Prozesse. Visuelle Workflows, API-Integration, Webhooks.</li>
<li class="text-body-lg text-gosign-text-light"><strong>API Gateway:</strong> Einheitlicher Einstiegspunkt mit Rate Limiting, Authentication, Logging, Monitoring.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Queue-System:</strong> Asynchrone Verarbeitung für Batch-Prozesse (Monatsabschluss, Massenimport).</li>
<li class="text-body-lg text-gosign-text-light"><strong>Event-System:</strong> Echtzeit-Reaktion auf eingehende Dokumente, Statusänderungen, Eskalationen.</li>
</ul>
</div>
</div>
</section>

<!-- Layer 3: Agent -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">3. Agent Layer</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Spezialisierte AI-Agenten, die fachliche Aufgaben ausführen. Jeder Agent hat einen definierten Aufgabenbereich und arbeitet innerhalb der Grenzen, die der Decision Layer vorgibt.
</p>
<h3 class="text-h3 font-bold text-gosign-dark mt-8"><a href="/de/leistungen/ai-agents/document-agents/" class="text-gosign-dark hover:text-gosign-accent-text transition-colors">Document Agents</a></h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Lesen, verstehen und verarbeiten Dokumente mit echtem Sprachverständnis. Rechnungen, Krankmeldungen, Verträge, Bescheinigungen, Belege. Keine Template-Erkennung, keine starren Regeln - sondern kontextuelles Verständnis.
</p>
<h3 class="text-h3 font-bold text-gosign-dark mt-8"><a href="/de/leistungen/ai-agents/workflow-agents/" class="text-gosign-dark hover:text-gosign-accent-text transition-colors">Workflow Agents</a></h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Orchestrieren Prozesse systemübergreifend. Wenn ein Dokument gelesen, eine Entscheidung getroffen und eine Aktion in einem Zielsystem ausgelöst werden muss - der Workflow Agent koordiniert den Ablauf.
</p>
<h3 class="text-h3 font-bold text-gosign-dark mt-8"><a href="/de/leistungen/ai-agents/knowledge-agents/" class="text-gosign-dark hover:text-gosign-accent-text transition-colors">Knowledge Agents</a></h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Liefern kontextbasierte Antworten aus Unternehmenswissen. Betriebsvereinbarungen, Richtlinien, Tarifverträge, Compliance-Regeln. Die Antwort enthält die Quelle und die Regelversion.
</p>
</div>
</div>
</section>

<!-- Layer 4: Decision Layer -->
<section class="py-section bg-gosign-dark text-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold"><a href="/de/decision-layer/" class="hover:text-gosign-accent-on-dark transition-colors">4. Decision Layer</a></h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4">
Zerlegt jeden Geschäftsprozess in einzelne Entscheidungsschritte und definiert für jeden Schritt: Mensch, Regelwerk oder KI. Jede Entscheidung wird dokumentiert - prüfbar für Wirtschaftsprüfer, Betriebsrat und interne Revision.
</p>
<div class="mt-6 space-y-4">
<p class="text-body-lg text-gosign-text-on-dark/80"><strong>Rules Engine:</strong> Fachliche Regelwerke, versioniert und nachvollziehbar. Tarifverträge, Betriebsvereinbarungen, Buchungslogik, Compliance-Regeln. Jede Regel hat eine Version, ein Gültigkeitsdatum und einen Geltungsbereich.</p>
<p class="text-body-lg text-gosign-text-on-dark/80"><strong>Confidence Routing:</strong> Automatische Bewertung der Entscheidungssicherheit. Hohe Confidence und niedriges Risiko: autonome Entscheidung. Niedrige Confidence oder hohes Risiko: Eskalation an Menschen.</p>
<p class="text-body-lg text-gosign-text-on-dark/80"><strong>Human-in-the-Loop:</strong> Architektonisch erzwungene menschliche Prüfung bei definierten Entscheidungstypen. Bias-Risiko, Diskriminierungspotenzial, Mitbestimmungsthemen.</p>
<p class="text-body-lg text-gosign-text-on-dark/80"><strong>Audit Trail - der Entscheidungsakt:</strong> Vollständige, unveränderliche Dokumentation jeder Entscheidung. Pro Mikroentscheidung ein Entscheidungsakt: Input, Modell, Bewertung, Regel samt Version, Ergebnis, Zeitstempel und Anfechtungspfad. Append-only - und damit die Architektur-Antwort auf das Recht der Betroffenen auf Erläuterung der einzelnen Entscheidung nach Art. 86 EU AI Act.</p>
</div>
<p class="text-body text-gosign-text-on-dark/60 mt-4">
Vertiefung: <a href="/de/magazin/decision-layer-erklaert/" class="text-gosign-text-on-dark/80 underline decoration-white/20 hover:text-white transition-colors">Decision Layer im Detail</a> · <a href="/de/magazin/drei-arten-von-entscheidungen/" class="text-gosign-text-on-dark/80 underline decoration-white/20 hover:text-white transition-colors">Drei Arten von KI-Entscheidungen</a> · <a href="/de/magazin/entscheidungsakt-anfechtbare-ki-entscheidungen/" class="text-gosign-text-on-dark/80 underline decoration-white/20 hover:text-white transition-colors">Der Entscheidungsakt</a>
</p>
</div>
</div>
</section>

<!-- Layer 5: Model -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">5. Model Layer</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Die LLM-Schicht. Austauschbar, modell-agnostisch, entkoppelt von der Geschäftslogik.
</p>
<h3 class="text-h3 font-bold text-gosign-dark mt-6">Cloud-LLMs</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Claude (Anthropic), ChatGPT (OpenAI), Gemini (Google) - über EU-Regionen der jeweiligen Cloud-Anbieter.</p>
<h3 class="text-h3 font-bold text-gosign-dark mt-6">Open-Source-/Open-Weight-LLMs</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Llama (Meta), Mistral, DeepSeek, <a href="https://openai.com/open-models/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">gpt-oss</a> (OpenAI, Apache 2.0) - komplett self-hostbar auf eigener Hardware. gpt-oss-120B läuft auf einer einzelnen H100-GPU, gpt-oss-20B auf 16 GB Consumer-Hardware.</p>
<h3 class="text-h3 font-bold text-gosign-dark mt-6">Hybrid</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Cloud-LLMs für Standardfälle, Self-Hosted-LLMs für sensible Daten. Automatisches Routing je nach Datenklassifikation.</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Die Modellwahl ist eine Abwägung zwischen Leistung, Kosten, Datenschutz und Latenz. Der Model Layer ist austauschbar - ein Modellwechsel ändert nichts an der darüberliegenden Geschäftslogik.
</p>
<p class="text-body text-gosign-text-light mt-4">
Konkrete Hosting-Optionen, Hardware-Anforderungen und Technologie-Stack: <a href="/de/leistungen/infrastruktur/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">AI Infrastructure im Detail</a>
</p>
</div>
</div>
</section>

<!-- PII-Gateway: Redaktion vor dem Model Layer -->
<section id="pii-gateway" class="py-section bg-gosign-dark text-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold">Der PII-Gateway: Redaktion vor dem Model Layer</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4">
Zwischen Geschäftslogik und Model Layer sieht die Architektur einen Redaktions-Gateway (PII-Gateway) vor: Jeder Modell-Aufruf - Cloud-LLM oder Self-Hosted - passiert ihn. Sein Design-Ziel: Personenbezogene Daten verlassen die Vertrauenszone des Betreibers nicht im Klartext. Für Workloads von Berufsgeheimnisträgern (&sect; 203 StGB) ist der Gateway ein Baustein der Datenminimierung - er ergänzt organisatorische und vertragliche Schutzmassnahmen, ersetzt sie nicht.
</p>
<div class="mt-6 space-y-4">
<p class="text-body-lg text-gosign-text-on-dark/80"><strong>Redaktion und Wieder-Einsetzung:</strong> Vor jedem Modell-Aufruf ersetzt der Gateway Namen, Kennungen und weitere personenbezogene Merkmale durch Platzhalter (Pseudonymisierung). Das Modell arbeitet ausschliesslich auf dem redigierten Text. Erst nach der Antwort werden die Originalwerte wieder eingesetzt - innerhalb der Vertrauenszone, nie beim Modell-Anbieter.</p>
<p class="text-body-lg text-gosign-text-on-dark/80"><strong>Klartextfreier Audit Trail:</strong> Jeder Modell-Aufruf wird append-only und hash-verkettet protokolliert: Hash-Werte von Prompt und Roh-Antwort statt Klartext, dazu Modell-ID, API-Version und die Version des Redaktions-Regelwerks. Der Nachweis, was wann durch den Gateway lief, bleibt vollständig - ohne dass das Protokoll selbst zum sensiblen Datenbestand wird.</p>
<p class="text-body-lg text-gosign-text-on-dark/80"><strong>Break-Glass-Regeln:</strong> Ausnahme-Zugriffe für Stör- und Prüffälle sind vorgesehen, aber nie still: Vier-Augen-Prinzip, dokumentierte Begründung, zeitliche Begrenzung - und jeder Break-Glass-Vorgang landet vollständig im Audit Trail.</p>
<p class="text-body-lg text-gosign-text-on-dark/80"><strong>Low-Confidence-Freigabe durch den Nutzer:</strong> Ist die Confidence der Redaktion bei einer Textstelle niedrig, entscheidet der Nutzer im UI über die Freigabe - nicht Personal von Gosign. Die Eskalation bleibt in der Sphäre, in der die Daten ohnehin bekannt sind.</p>
</div>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-6">
Nicht redigierbare API-Modi - etwa externe Embedding-Aufrufe, deren Vektoren sich nicht pseudonymisieren lassen - blockiert der Gateway für redaktionspflichtige Inhalte, statt sie still durchzureichen. Zuordnungstabellen zwischen Platzhaltern und Originalwerten sind ephemer oder mandanten-verschlüsselt mit definierter Lebensdauer (TTL); Provider-Schlüssel liegen ausschliesslich im Schlüssel-Management (KMS).
</p>
<p class="text-body text-gosign-text-on-dark/60 mt-4">
Vertiefung: <a href="/de/magazin/pii-anonymisierung-llm-enterprise/" class="text-gosign-text-on-dark/80 underline decoration-white/20 hover:text-white transition-colors">PII-Anonymisierung für Enterprise AI</a>
</p>
</div>
</div>
</section>

<!-- Layer 6: Integration -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">6. Integration Layer</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Die Anbindung an bestehende Enterprise-Systeme. Der Agent ersetzt keine Systeme - er erweitert sie.
</p>
<div class="mt-6 overflow-x-auto">
<table class="w-full text-left text-small border-collapse">
<thead>
<tr>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Systemkategorie</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Integration</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">ERP / Finanzen</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">SAP FI/CO, SAP S/4HANA, DATEV, Oracle Financials</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">HR / Payroll</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">SAP SuccessFactors, Workday, Personio</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Collaboration</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">SharePoint, Microsoft Teams (via Microsoft Graph)</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">DMS / ECM</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">SharePoint, d.velop, ELO, nscale</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Weitere</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Jedes System mit REST- oder SOAP-Schnittstelle</td></tr>
</tbody>
</table>
</div>
<p class="text-body-lg text-gosign-text-light mt-4">
Die Agent-Logik ist vom Zielsystem entkoppelt. Buchungslogik ist von Export getrennt. Wenn das Zielsystem wechselt (z.B. von DATEV auf SAP), ändert sich der Export-Layer - nicht der Agent.
</p>
</div>
</div>
</section>

<!-- Layer 7: Infrastructure -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">7. Infrastructure Layer</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Das Deployment-Fundament. Die gesamte Architektur läuft in der Infrastruktur des Kunden - nicht bei Gosign, nicht bei einem Drittanbieter.
</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light"><strong>Cloud (EU):</strong> Azure, AWS oder GCP - ausschliesslich EU-Regionen. Managed Kubernetes, Managed Databases, LLM-Hosting.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Managed EU:</strong> Vercel EU + Supabase EU. Leichtgewichtige EU-Option ohne eigene Kubernetes-Infrastruktur.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Self-Hosted:</strong> Eigene Server, eigenes Rechenzentrum. Docker/Kubernetes, Open-Source-LLMs auf eigenen GPUs. Vollständige Cloud-Act-Freiheit.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Hybrid:</strong> Kombination nach Datenklassifikation. Sensible Workloads Self-Hosted, Standard-Workloads Cloud.</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-4">
Alle Layer oberhalb der Infrastructure-Schicht bleiben identisch - unabhängig vom Deployment-Modell.
</p>
<p class="text-body text-gosign-text-light mt-4">
Cloud-Regionen, Hardware-Dimensionierung, Technologie-Stack: <a href="/de/leistungen/infrastruktur/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">AI Infrastructure im Detail</a>
</p>
</div>
</div>
</section>

<!-- Governance als Querschicht -->
<section class="py-section bg-gosign-dark text-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold">Governance als Querschicht</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4">
Governance ist kein einzelner Layer, sondern durchzieht die gesamte Architektur. Jeder Layer erzeugt Governance-Daten, jeder Layer wird durch Governance-Regeln kontrolliert.
</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-on-dark/80"><strong>Presentation:</strong> Rollenbasierter Zugriff, Auditor Portal</li>
<li class="text-body-lg text-gosign-text-on-dark/80"><strong>Orchestration:</strong> Workflow-Logging, Eskalations-Dokumentation</li>
<li class="text-body-lg text-gosign-text-on-dark/80"><strong>Agent:</strong> Agent-Entscheidungen erzeugen Audit-Trail-Einträge</li>
<li class="text-body-lg text-gosign-text-on-dark/80"><strong>Decision Layer:</strong> Rules Engine, Confidence Routing, Human-in-the-Loop</li>
<li class="text-body-lg text-gosign-text-on-dark/80"><strong>Model:</strong> Modellversions-Tracking, Input-Hashing, Reproduzierbarkeit, PII-Redaktion und klartextfreies Protokoll (PII-Gateway)</li>
<li class="text-body-lg text-gosign-text-on-dark/80"><strong>Integration:</strong> Schnittstellen-Logging, Datenfluss-Dokumentation</li>
<li class="text-body-lg text-gosign-text-on-dark/80"><strong>Infrastructure:</strong> Verschlüsselung, Row-Level Security, Mandantentrennung</li>
</ul>
<p class="text-body text-gosign-text-on-dark/60 mt-6">
<a href="/de/governance/eu-ai-act/" class="text-gosign-text-on-dark/80 underline decoration-white/20 hover:text-white transition-colors">EU AI Act</a> · <a href="/de/governance/cert-ready/" class="text-gosign-text-on-dark/80 underline decoration-white/20 hover:text-white transition-colors">Cert-Ready by Design</a> · <a href="/de/governance/mitbestimmung/" class="text-gosign-text-on-dark/80 underline decoration-white/20 hover:text-white transition-colors">Mitbestimmung</a> · <a href="/de/governance/data-residency/" class="text-gosign-text-on-dark/80 underline decoration-white/20 hover:text-white transition-colors">Data Residency</a>
</p>
</div>
</div>
</section>

<!-- Runtime & Skalierung -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Runtime und Skalierung</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Produktionsbetrieb ist keine Nacharbeit, sondern Architekturbestandteil. Die 7-Layer-Architektur ist für Betrieb unter Last ausgelegt.
</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light"><strong>Container-Orchestrierung:</strong> Kubernetes-basiertes Deployment. Jeder Layer läuft in eigenen Containern, unabhängig skalierbar.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Horizontale Skalierung:</strong> Agent Layer und Model Layer skalieren horizontal nach Auslastung. Ein neuer Agent bedeutet mehr Pods, nicht mehr Architektur.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Health Checks und Self-Healing:</strong> Liveness und Readiness Probes auf allen Containern. Automatischer Neustart bei Ausfall, automatische Umleitung bei Überlast.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Monitoring und Alerting:</strong> Prometheus-Metriken auf allen Layern. Grafana-Dashboards für Latenz, Throughput, Error Rates, Queue Depth. Alerting bei Schwellenwertüberschreitung.</li>
<li class="text-body-lg text-gosign-text-light"><strong>CI/CD:</strong> GitOps-basierte Deployments. Infrastructure as Code (Terraform/Pulumi). Automatisierte Tests, Blue-Green oder Canary Deployments.</li>
</ul>
</div>
</div>
</section>

<!-- Datenarchitektur -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Datenarchitektur</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Daten fliessen durch alle sieben Layer. Die Architektur definiert, wo Daten entstehen, wie sie gespeichert werden und wer Zugriff hat.
</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light"><strong>Datenfluss:</strong> Input (Dokument, Anfrage) &rarr; Agent (Analyse) &rarr; Decision Layer (Entscheidung) &rarr; Integration (Zielsystem-Export). Jeder Schritt erzeugt einen Audit-Trail-Eintrag.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Vector Store:</strong> PostgreSQL mit pgvector für semantische Suche (RAG). Unternehmenswissen wird als Embeddings gespeichert, nicht an externe Dienste übermittelt.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Mandantentrennung:</strong> Row-Level Security (RLS) auf Datenbankebene. Architektonisch erzwungen, nicht per Applikationslogik. Jeder Mandant ist vollständig isoliert.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Verschlüsselung:</strong> At rest (AES-256) und in transit (TLS 1.3). Schlüssel-Management über den Identity Provider des Kunden oder Hardware Security Modules (HSM).</li>
<li class="text-body-lg text-gosign-text-light"><strong>Data Retention:</strong> Konfigurierbar nach Anforderung. Steuerliche Aufbewahrung (10 Jahre, AO &sect; 147) und DSGVO Art. 17 (Recht auf Löschung) werden über Anonymisierung statt Löschung vereinbart.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Backup und Recovery:</strong> Automatisierte Backups, Point-in-Time Recovery. Recovery Point Objective (RPO) und Recovery Time Objective (RTO) werden pro Mandant konfiguriert.</li>
</ul>
</div>
</div>
</section>

<!-- Schnittstellenarchitektur -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Schnittstellenarchitektur</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Die Architektur kommuniziert über definierte Schnittstellen - intern zwischen Layern und extern mit Vorsystemen und Zielsystemen.
</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light"><strong>REST API:</strong> Versionierte APIs (v1, v2) mit OpenAPI-Dokumentation. Breaking Changes nur in neuen Versionen, alte Versionen werden parallel betrieben.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Event-Driven:</strong> Webhook-basierte Eventverarbeitung für Echtzeit-Reaktionen. Eingehendes Dokument &rarr; Event &rarr; Agent verarbeitet. Kein Polling, kein Batch-Delay.</li>
<li class="text-body-lg text-gosign-text-light"><strong>MCP (Model Context Protocol):</strong> Standardisiertes Protokoll für Tool-Integration in LLM-Agenten. Agenten greifen über MCP auf externe Werkzeuge zu - typisiert, dokumentiert, auditierbar.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Batch-Verarbeitung:</strong> Für Massenoperationen (Monatsabschluss, Jahresabrechnung, Massenimport). Queue-basiert mit Fortschritts-Tracking und Fehlerbehandlung.</li>
<li class="text-body-lg text-gosign-text-light"><strong>API Gateway:</strong> Zentraler Einstiegspunkt. Authentifizierung (SSO/OIDC), Rate Limiting, Request-Logging, Monitoring. Entkoppelt interne Architektur von externen Konsumenten.</li>
</ul>
</div>
</div>
</section>

<!-- Designprinzipien -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Designprinzipien</h2>
<div class="mt-6 space-y-4">
<p class="text-body-lg text-gosign-text-light"><strong>Modell-agnostisch:</strong> Kein Vendor Lock-in auf ein einzelnes LLM. Modelle sind austauschbar. Heute Claude, morgen gpt-oss, übermorgen ein Modell das heute noch nicht existiert.</p>
<p class="text-body-lg text-gosign-text-light"><strong>Infrastruktur-agnostisch:</strong> Gleiche Architektur auf Azure, AWS, GCP, Self-Hosted oder Hybrid. Die Infrastrukturwahl ist eine Entscheidung des Kunden, nicht der Architektur.</p>
<p class="text-body-lg text-gosign-text-light"><strong>System-agnostisch:</strong> Agent-Logik ist vom Zielsystem entkoppelt. Buchungslogik getrennt von Export. Ein Systemwechsel ändert den Integration Layer, nicht den Agenten.</p>
<p class="text-body-lg text-gosign-text-light"><strong>Governance by Design:</strong> Audit Trail, RBAC, Decision Layer und Human-in-the-Loop sind Architekturkomponenten - keine optionalen Features, die nachgerüstet werden.</p>
<p class="text-body-lg text-gosign-text-light"><strong>Cert-Ready by Design:</strong> Controls sind First-Class-Datenobjekte mit automatischer Evidence-Generierung. ISO 27001, PS 951, SOC 2 - die Architektur liefert die Nachweise.</p>
<p class="text-body-lg text-gosign-text-light"><strong>Quellcode-Zugang:</strong> Voller Zugang zum Quellcode, allen Prompts und Regelwerken. Konfigurationen und Regelwerke liegen beim Kunden. Open-Source-Stack wo möglich. Nach 12-18 Monaten betreibt der Kunde die Agenten eigenständig.</p>
</div>
</div>
</div>
</section>

<!-- Decision Layer - Entscheidungsfluss -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-6">Decision Layer - Entscheidungsfluss</h2>
<figure role="img" aria-label="Entscheidungsfluss: Input wird vom AI Agent analysiert, der Decision Layer prüft Regelwerk und Confidence, routet zu autonomer Entscheidung oder Human-in-the-Loop, dokumentiert alles im Audit Trail und exportiert an das Zielsystem.">
<pre class="bg-gosign-dark text-white p-6 rounded-card overflow-x-auto text-small font-mono leading-relaxed"><code>┌──────────┐    ┌──────────────┐    ┌────────────────┐
│  Input   │───&gt;│  AI Agent    │───&gt;│ Decision Layer │
│(Dokument,│    │  analysiert, │    │                │
│ Anfrage) │    │  versteht,   │    │  Regelwerk     │
└──────────┘    │  bewertet    │    │  prüfen        │
└──────────────┘    │                │
│  Confidence    │
│  bewerten      │
│                │
│  Routing       │
│  entscheiden   │
└───────┬────────┘
│
┌─────────────┴──────────────┐
│                            │
┌────────▼────────┐        ┌──────────▼──────────┐
│ Autonom         │        │ Human-in-the-Loop   │
│                 │        │                     │
│ Hohe Confidence │        │ Bias-Risiko         │
│ Niedriges Risiko│        │ Niedrige Confidence │
│ Kein BV-        │        │ BV-Constraint       │
│ Constraint      │        │ Mitbestimmung       │
└────────┬────────┘        └──────────┬──────────┘
│                            │
│         ┌──────────────┐   │
│         │  Mensch      │   │
│         │  entscheidet │◄──┘
│         └──────┬───────┘
│                │
┌────────▼────────────────▼────────┐
│         Audit Trail              │
│  Input · Modell · Regel ·        │
│  Bewertung · Ergebnis ·          │
│  Zeitstempel                     │
└──────────────────────────────────┘
│
┌────────▼────────┐
│  Zielsystem     │
│  (ERP, HR,      │
│   Payroll)      │
└─────────────────┘</code></pre>
<figcaption class="text-small text-gosign-text-light mt-3">Schematischer Entscheidungsfluss durch den Decision Layer. In der Produktionsumgebung wird jeder Schritt als Audit-Trail-Eintrag dokumentiert.</figcaption>
</figure>
</div>
</section>

<!-- Vertiefung -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Vertiefung</h2>
<div class="mt-6 grid gap-6 sm:grid-cols-2">
<div class="border-l-4 border-gosign-dark pl-6 py-4">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Implementierung</p>
<h3 class="text-h3 font-bold text-gosign-dark">AI Infrastructure</h3>
<p class="text-body text-gosign-text-light mt-2">Konkrete Technologien, Cloud-Regionen, Hardware-Dimensionierung, Tech-Stack-Tabelle.</p>
<a href="/de/leistungen/infrastruktur/" class="text-small font-semibold text-gosign-accent-text hover:text-gosign-accent-hover mt-3 inline-block whitespace-nowrap">Infrastruktur im Detail &rarr;</a>
</div>
<div class="border-l-4 border-gosign-dark pl-6 py-4">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Wissensressource</p>
<h3 class="text-h3 font-bold text-gosign-dark">Blueprint 2026</h3>
<p class="text-body text-gosign-text-light mt-2">Elf Fachartikel zu den Infrastruktur-Entscheidungen die 2026 zählen.</p>
<a href="/de/magazin/ai-infrastruktur-blueprint-2026/" class="text-small font-semibold text-gosign-accent-text hover:text-gosign-accent-hover mt-3 inline-block whitespace-nowrap">Zur Artikelserie &rarr;</a>
</div>
<div class="border-l-4 border-gosign-dark pl-6 py-4">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Agenten</p>
<h3 class="text-h3 font-bold text-gosign-dark">AI Agents im Überblick</h3>
<p class="text-body text-gosign-text-light mt-2">Document Agents, Workflow Agents, Knowledge Agents - drei Agententypen für Enterprise-Prozesse.</p>
<a href="/de/leistungen/ai-agents/" class="text-small font-semibold text-gosign-accent-text hover:text-gosign-accent-hover mt-3 inline-block whitespace-nowrap">Zu den AI Agents &rarr;</a>
</div>
<div class="border-l-4 border-gosign-dark pl-6 py-4">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<h3 class="text-h3 font-bold text-gosign-dark">Governance-Framework</h3>
<p class="text-body text-gosign-text-light mt-2">EU AI Act, Cert-Ready, Mitbestimmung, Data Residency - alle Governance-Themen im Überblick.</p>
<a href="/de/governance/" class="text-small font-semibold text-gosign-accent-text hover:text-gosign-accent-hover mt-3 inline-block whitespace-nowrap">Zur Governance-Übersicht &rarr;</a>
</div>
</div>
</div>
</div>
</section>

<!-- Vertiefung im Agent Briefing -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Vertiefung im Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Unsere Fachartikel-Serie für Entscheider, die AI Agents im Unternehmen einführen.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/de/magazin/ai-infrastruktur-blueprint-2026/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">Enterprise AI-Infrastruktur Blueprint 2026</p>
</a>
<a href="/de/magazin/decision-layer-erklaert/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - Was ist das und warum braucht jeder Enterprise AI Agent einen?</p>
</a>
<a href="/de/magazin/agent-orchestrierung-plattformen/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">Agent-Orchestrierung: Trigger.dev, n8n, Camunda und Alternativen</p>
</a>
</div>
</div>
</section>

--- Governance, Security & Audit ---
> Wie Gosign AI-Agenten auditierbar, prüfbereit und betriebsratsfähig macht. Governance by Design als Architekturprinzip.

<!-- Governance by Design -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Governance by Design</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Gosign baut AI-Agenten für Enterprise-Umgebungen. In diesen Umgebungen gelten Anforderungen an Nachvollziehbarkeit, Prüfbarkeit und Kontrolle, die über das hinausgehen, was ein Standard-LLM-Deployment liefert.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Governance by Design bedeutet: Jeder Agent wird von Grund auf mit den Mechanismen gebaut, die Prüfer, Betriebsräte und Compliance-Teams erwarten. Das ist kein optionaler Layer, der nachträglich aufgesetzt wird. Es ist ein Architekturprinzip.
</p>
<p class="text-body text-gosign-text-light mt-4">
Was der EU AI Act konkret fordert und wie Unternehmen High-Risk-compliant werden - geltende Frist 2. August 2026, mit am 7. Mai 2026 im Digital Omnibus vorläufig geeinigter Verschiebung auf den 2. Dezember 2027 (formale Verabschiedung ausstehend) - beschreibt unser
<a href="/de/magazin/eu-ai-act-2026-unternehmen/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">EU-AI-Act-Leitfaden</a>.
</p>
</div>
</div>
</section>

<!-- Sechs Governance-Dimensionen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">Sechs Governance-Dimensionen</h2>
<div class="grid grid-cols-1 lg:grid-cols-3 gap-6 lg:gap-8">
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75L11.25 15 15 9.75m-3-7.036A11.959 11.959 0 013.598 6 11.99 11.99 0 003 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Cert-Ready by Design</h3>
<p class="text-body text-gosign-text-light mt-3">Controls als First-Class-Datenobjekte. Automatische Evidence-Generierung. Live Auditor Portal mit Drill-Down bis zur konkreten Implementierung.</p>
<a href="/de/governance/cert-ready/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
Cert-Ready by Design
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M18 18.72a9.094 9.094 0 003.741-.479 3 3 0 00-4.682-2.72m.94 3.198l.001.031c0 .225-.012.447-.037.666A11.944 11.944 0 0112 21c-2.17 0-4.207-.576-5.963-1.584A6.062 6.062 0 016 18.719m12 0a5.971 5.971 0 00-.941-3.197m0 0A5.995 5.995 0 0012 12.75a5.995 5.995 0 00-5.058 2.772m0 0a3 3 0 00-4.681 2.72 8.986 8.986 0 003.74.477m.94-3.197a5.971 5.971 0 00-.94 3.197M15 6.75a3 3 0 11-6 0 3 3 0 016 0zm6 3a2.25 2.25 0 11-4.5 0 2.25 2.25 0 014.5 0zm-13.5 0a2.25 2.25 0 11-4.5 0 2.25 2.25 0 014.5 0z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Mitbestimmung & Betriebsrat</h3>
<p class="text-body text-gosign-text-light mt-3">Betriebsvereinbarungen als explizite Constraints im Decision Layer. Der Betriebsrat kann nachvollziehen: was der Agent tut, warum, wann ein Mensch eingreift.</p>
<a href="/de/governance/mitbestimmung/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
Mitbestimmung & Betriebsrat
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 3v17.25m0 0c-1.472 0-2.882.265-4.185.75M12 20.25c1.472 0 2.882.265 4.185.75M18.75 4.97A48.416 48.416 0 0012 4.5c-2.291 0-4.545.16-6.75.47m13.5 0c1.01.143 2.01.317 3 .52m-3-.52l2.62 10.726c.122.499-.106 1.028-.589 1.202a5.988 5.988 0 01-2.031.352 5.988 5.988 0 01-2.031-.352c-.483-.174-.711-.703-.59-1.202L18.75 4.971zm-16.5.52c.99-.203 1.99-.377 3-.52m0 0l2.62 10.726c.122.499-.106 1.028-.589 1.202a5.989 5.989 0 01-2.031.352 5.989 5.989 0 01-2.031-.352c-.483-.174-.711-.703-.59-1.202L5.25 4.971z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">EU AI Act</h3>
<p class="text-body text-gosign-text-light mt-3">Transparenz (Art. 13), menschliche Aufsicht (Art. 14), Aufzeichnungspflichten (Art. 12), Risikomanagement (Art. 9) und das Recht auf Erläuterung der Einzelentscheidung (Art. 86) - als Designprinzip adressiert.</p>
<a href="/de/governance/eu-ai-act/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
EU AI Act Readiness
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M21 7.5l-2.25-1.313M21 7.5v2.25m0-2.25l-2.25 1.313M3 7.5l2.25-1.313M3 7.5l2.25 1.313M3 7.5v2.25m9 3l2.25-1.313M12 12.75l-2.25-1.313M12 12.75V15m0 6.75l2.25-1.313M12 21.75V19.5m0 2.25l-2.25-1.313m0-16.875L12 2.25l2.25 1.313M21 14.25v2.25l-2.25 1.313m-13.5 0L3 16.5v-2.25" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Referenz-Architektur</h3>
<p class="text-body text-gosign-text-light mt-3">7-Layer Enterprise AI Architektur. Governance als Querschicht durch alle Layer. Presentation, Orchestration, Agent, Governance, Model, Integration, Infrastructure.</p>
<a href="/de/governance/referenz-architektur/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
Referenz-Architektur
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M16.5 10.5V6.75a4.5 4.5 0 10-9 0v3.75m-.75 11.25h10.5a2.25 2.25 0 002.25-2.25v-6.75a2.25 2.25 0 00-2.25-2.25H6.75a2.25 2.25 0 00-2.25 2.25v6.75a2.25 2.25 0 002.25 2.25z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Datenresidenz & DSGVO</h3>
<p class="text-body text-gosign-text-light mt-3">Alle Daten verbleiben in der Infrastruktur des Kunden. EU-only Processing, Row-Level Security, Mandantentrennung, vollständige Datenhoheit.</p>
<a href="/de/governance/data-residency/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
Datenresidenz & DSGVO
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12h3.75M9 15h3.75M9 18h3.75m3 .75H18a2.25 2.25 0 002.25-2.25V6.108c0-1.135-.845-2.098-1.976-2.192a48.424 48.424 0 00-1.123-.08m-5.801 0c-.065.21-.1.433-.1.664 0 .414.336.75.75.75h4.5a.75.75 0 00.75-.75 2.25 2.25 0 00-.1-.664m-5.8 0A2.251 2.251 0 0113.5 2.25H15a2.25 2.25 0 012.15 1.586m-5.8 0c-.376.023-.75.05-1.124.08C9.095 4.01 8.25 4.973 8.25 6.108V8.25m0 0H4.875c-.621 0-1.125.504-1.125 1.125v11.25c0 .621.504 1.125 1.125 1.125h9.75c.621 0 1.125-.504 1.125-1.125V9.375c0-.621-.504-1.125-1.125-1.125H8.25zM6.75 12h.008v.008H6.75V12zm0 3h.008v.008H6.75V15zm0 3h.008v.008H6.75V18z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">AVV für KI-Infrastruktur</h3>
<p class="text-body text-gosign-text-light mt-3">Warum Standard-Auftragsverarbeitungsverträge bei Enterprise-KI nicht reichen. Anforderungskatalog mit 25 Prüffragen für Legal, IT-Security und Betriebsrat.</p>
<a href="/de/governance/avv-checkliste/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
AVV-Checkliste
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</article>
</div>
</div>
</section>

<!-- Audit Trail & Decision Layer -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Audit Trail & <a href="/de/decision-layer/" class="hover:text-gosign-accent transition-colors">Decision Layer</a></h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Der <a href="/de/decision-layer/" class="text-gosign-accent-text hover:underline">Decision Layer</a> zerlegt jeden Geschäftsprozess in einzelne Entscheidungsschritte. Für jeden Schritt ist definiert: Entscheidet ein Mensch, ein Regelwerk oder die KI? Diese Zerlegung ist die Grundlage für prüfbare, nachvollziehbare Agenten-Entscheidungen.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Jede Entscheidung erzeugt einen vollständigen, unveränderlichen Entscheidungsakt: Eingangsdaten, Modell und Modellversion, fachliche Bewertung und Konfidenzwert, angewandte Regel mit Regelversion, Entscheidungspfad (autonom oder Human-in-the-Loop), Ergebnis, Zeitstempel und Anfechtungspfad. Er ist die Architektur-Antwort auf das Recht der Betroffenen auf Erläuterung der einzelnen Entscheidung nach <a href="/de/magazin/entscheidungsakt-anfechtbare-ki-entscheidungen/" class="text-gosign-accent-text hover:underline">Art. 86 EU AI Act</a>.
</p>
</div>
</div>
</section>

<!-- Architektur-Überblick -->
<section class="py-section bg-gosign-dark text-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold mb-6">Architektur-Überblick</h2>
<pre class="bg-gosign-dark border border-white/10 text-white p-6 rounded-card overflow-x-auto text-small font-mono leading-relaxed"><code>┌─────────────────────────────────────────────────┐
│  Presentation Layer    Chat UI, Dashboard, API  │
├─────────────────────────────────────────────────┤
│  Orchestration Layer   Trigger.dev/Camunda, API GW      │
├─────────────────────────────────────────────────┤
│  Agent Layer           Document, Workflow,       │
│                        Knowledge Agents          │
├─────────────────────┬───────────────────────────┤
│  GOVERNANCE LAYER   │ Audit Trail, RBAC,        │
│  (Querschicht)      │ Decision Layer,           │
│                     │ Cert-Ready Controls       │
├─────────────────────┴───────────────────────────┤
│  Model Layer           Claude, ChatGPT, Llama,  │
│                        Mistral, DeepSeek        │
├─────────────────────────────────────────────────┤
│  Integration Layer     SAP, DATEV, MS Graph     │
├─────────────────────────────────────────────────┤
│  Infrastructure Layer  Azure, GCP, AWS, Self-Hosted  │
└─────────────────────────────────────────────────┘</code></pre>
<p class="mt-6">
<a href="/de/governance/referenz-architektur/" class="text-gosign-accent-on-dark hover:text-gosign-accent-on-dark font-semibold">Referenz-Architektur im Detail</a>
</p>
</div>
</section>

<!-- Governance gilt für jeden Agenten -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Governance gilt für jeden Agenten</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Governance by Design ist kein Feature eines einzelnen Produkts. Es ist ein Architekturprinzip, das für jeden AI-Agenten gilt, den Gosign baut - ob HR Agent, Finance Agent, Document Agent oder Knowledge Agent.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Gleiche Governance. Gleiche Auditierbarkeit. Gleiche Infrastruktur.
</p>
</div>
</div>
</section>

<!-- Vertiefung im Agent Briefing -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">Vertiefung im Agent Briefing (Gosign Magazin)</h2>
<div class="grid md:grid-cols-3 gap-6">
<a href="/de/magazin/decision-layer-shadow-ai/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<h3 class="text-h3 font-bold text-gosign-dark">Decision Layer & Shadow AI</h3>
</a>
<a href="/de/magazin/eu-ai-act-2026-unternehmen/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<h3 class="text-h3 font-bold text-gosign-dark">EU AI Act 2026</h3>
</a>
<a href="/de/magazin/ai-infrastruktur-blueprint-2026/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Infrastructure</p>
<h3 class="text-h3 font-bold text-gosign-dark">AI-Infrastruktur Blueprint 2026</h3>
</a>
</div>
</div>
</section>

<!-- FAQ -->

--- Enterprise AI Agents - In Ihrer Infrastruktur. Unter Ihrer Kontrolle. ---
> Gosign entwickelt und betreibt AI-Agent-Infrastruktur für Unternehmen. Orchestrierung, Governance, Audit Trail - modell-agnostisch, auditierbar, DSGVO-konform.

<!-- Enterprise AI Infrastructure & Agent Engineering -->
<section class="scroll-reveal py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex flex-col lg:flex-row lg:items-start lg:gap-12">
<div class="lg:w-[55%]">
<h2 class="text-h1 font-bold text-gosign-dark">
Enterprise AI Infrastructure & Agent Engineering
</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Gosign ist eine Enterprise AI Infrastructure & Agent Engineering Company. Wir entwickeln und betreiben die Infrastruktur, auf der AI Agents in Unternehmen produktiv laufen - inklusive Orchestrierung, Governance und Audit.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
25 Jahre Softwareentwicklung. 108 Mitarbeiter. Über 5.000 Projekte für z.B. Airbus, Volkswagen, Shell. Seit 2023 fokussiert auf Enterprise AI Agent Engineering.
</p>
</div>
<div class="lg:w-[45%] mt-8 lg:mt-0 flex justify-center">
<img
src="/images/7-layer-architecture-v2.svg"
alt="Gosign 7-Schichten-Architektur für Enterprise AI: Presentation Layer, Orchestration Layer, Agent Layer, Governance Layer, Model Layer, Integration Layer, Infrastructure Layer"
width="500"
height="400"
class="w-full max-w-md"
loading="lazy"
/>
</div>
</div>
</div>
</section>

<!-- Warum die meisten KI-Projekte keinen messbaren Nutzen bringen -->
<section class="scroll-reveal py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Warum die meisten KI-Projekte keinen messbaren Nutzen bringen</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Die meisten Unternehmen setzen bereits KI ein. Die wenigsten erzielen damit messbaren Nutzen. Nicht weil die Technologie nicht funktioniert - sondern weil niemand definiert hat, welche Entscheidungen die KI treffen darf und welche beim Menschen bleiben müssen.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Branchenerfahrung zeigt: Für jeden Euro in Technologie brauchen Sie vier bis fünf Euro in Prozesse, Governance und Veränderungsmanagement. Wer nur in Technologie investiert, investiert am Problem vorbei.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Der <a href="/de/decision-layer/" class="text-gosign-accent-text hover:underline font-semibold">Decision Layer</a> ist die Schicht, die diesen Unterschied macht: Er zerlegt jeden Geschäftsprozess in einzelne Entscheidungsschritte und definiert für jeden Schritt - Mensch, Regelwerk oder KI. Damit wird aus einem KI-Experiment ein produktives System.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Die EU AI Act Hochrisiko-Pflichten für KI-Systeme im Beschäftigungskontext und in der Finanzdienstleistung gelten nach aktuellem Recht ab dem 2. August 2026 - mit vorläufig geeinigter Verschiebung auf Dezember 2027 (Digital Omnibus, Mai 2026, formale Verabschiedung ausstehend). Die Hochrisiko-Einstufung bleibt bestehen; eine auditierbare Governance-Infrastruktur ist die Voraussetzung dafür - und die voraussichtlich gewonnene Zeit sollte zum Aufbau genutzt werden.
</p>
</div>
</div>
</section>

<!-- AI Agents für Ihren Fachbereich -->
<section class="scroll-reveal py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">AI Agents für Ihren Fachbereich</h2>
<div class="grid grid-cols-1 gap-6 lg:gap-8 lg:grid-cols-3">
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 hover:shadow-lg hover:-translate-y-0.5 transition-all duration-200">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<img src="/images/icon-finance.svg" alt="" class="w-10 h-10" width="40" height="40" />
</div>
<h3 class="text-h3 font-bold text-gosign-dark">AI Agents für Finance & Accounting</h3>
<p class="text-body text-gosign-text-light mt-3">Decision Automation für Belegverarbeitung, Kontierung und Prüfungsvorbereitung. Versionierte Regelwerke, vollständiger Audit Trail, Cert-Ready by Design. Der <a href='/de/decision-layer/' class='text-gosign-accent-text hover:underline'>Decision Layer</a> macht jede Buchungsentscheidung nachvollziehbar.</p>
<a href="/de/finance-ai-agents/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
Finance AI Agents
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 hover:shadow-lg hover:-translate-y-0.5 transition-all duration-200">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<img src="/images/icon-hr.svg" alt="" class="w-10 h-10" width="40" height="40" />
</div>
<h3 class="text-h3 font-bold text-gosign-dark">AI Agents für HR & People Operations</h3>
<p class="text-body text-gosign-text-light mt-3">Auditierbare AI Agents für HR-Entscheidungen. Betriebsratsfähig. Decision Layer mit Human-in-the-Loop. Payroll, Onboarding, Document Processing, Compensation & Merit, Policy & Knowledge.</p>
<a href="/de/hr-ai-agents/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
HR AI Agents
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 hover:shadow-lg hover:-translate-y-0.5 transition-all duration-200">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<img src="/images/icon-infrastructure.svg" alt="" class="w-10 h-10" width="40" height="40" />
</div>
<h3 class="text-h3 font-bold text-gosign-dark">AI-Infrastruktur für IT & Enterprise</h3>
<p class="text-body text-gosign-text-light mt-3">LLM Hosting, RAG, Orchestrierung, Self-Hosted oder Cloud. Modell-agnostisch, Governance by Design, Cert-Ready by Design. Die Plattform auf der Ihre Agents produktiv laufen.</p>
<a href="/de/leistungen/infrastruktur/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
Infrastruktur
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</article>
</div>
</div>
</section>

<!-- Drei Agent-Typen -->
<section class="scroll-reveal py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 space-y-12">
<h2 class="text-h1 font-bold text-gosign-dark">Drei Agent-Typen</h2>
<article class="flex flex-col lg:flex-row gap-8 lg:gap-12 items-start">
<div class="flex-shrink-0 w-16 h-16 lg:w-20 lg:h-20 rounded-full bg-gosign-accent/10 flex items-center justify-center">
<span class="text-h1 lg:text-hero font-bold text-gosign-accent-text">01</span>
</div>
<div class="flex-1 lg:w-[55%]">
<h3 class="text-h2 font-bold text-gosign-dark">Document Agents</h3>
<p class="text-body-lg text-gosign-text-light mt-3">Der Spezialist: versteht Dokumente. Eine Krankmeldung geht ein. Der Agent erkennt den Dokumenttyp, extrahiert Name, Zeitraum und Diagnose-Schlüssel, prüft ob alle Pflichtfelder vorhanden sind und ordnet das Dokument dem richtigen Mitarbeiter zu. In Finance: Der Document Agent liest eine Eingangsrechnung, extrahiert Rechnungsnummer, Betrag und Leistungszeitraum und prüft gegen §14 UStG Pflichtangaben. Ergebnis: strukturierter Datensatz mit Kontierungsvorschlag. Keine Template-Erkennung - echtes Sprachverständnis. Der Decision Layer bewertet jede Extraktion: Deterministisch? Regelwerk. Confident genug? Agent entscheidet eigenständig. Ermessen nötig? Mensch prüft.</p>
<a href="/de/leistungen/ai-agents/document-agents/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
Document Agents im Detail
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</div>
<div class="lg:w-[40%] mt-4 lg:mt-11">
<img src="/images/flow-document-agent-v10-de.svg" alt="Document Agent - Der Spezialist: Ein Dokument geht ein, der Agent versteht Typ, Inhalt und Kontext, Decision Layer routet nach drei Stufen, strukturierte Daten kommen raus." class="w-full" width="480" height="620" loading="lazy" />
</div>
</article>
<article class="flex flex-col lg:flex-row gap-8 lg:gap-12 items-start">
<div class="flex-shrink-0 w-16 h-16 lg:w-20 lg:h-20 rounded-full bg-gosign-accent/10 flex items-center justify-center">
<span class="text-h1 lg:text-hero font-bold text-gosign-accent-text">02</span>
</div>
<div class="flex-1 lg:w-[55%]">
<h3 class="text-h2 font-bold text-gosign-dark">Workflow Agents</h3>
<p class="text-body-lg text-gosign-text-light mt-3">Der Koordinator: steuert den Gesamtprozess. Die Krankmeldung ist verstanden - und jetzt? Der Workflow Agent übernimmt: prüft im HR-System ob es die dritte Meldung in sechs Monaten ist, gleicht gegen den Tarifvertrag ab ob die Schwelle für eine Wiedereingliederung erreicht ist, erstellt eine Aufgabe für den HR-Manager in SAP SuccessFactors, informiert den Betriebsrat und plant ein Follow-up. Fünf Systeme, drei Entscheidungspunkte, ein Agent der den gesamten Prozess koordiniert - inklusive eigenständiger Routing-Entscheidungen wenn die Konfidenz ausreicht. Jeder Schritt im Audit Trail.</p>
<a href="/de/leistungen/ai-agents/workflow-agents/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
Workflow Agents im Detail
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</div>
<div class="lg:w-[40%] mt-4 lg:mt-11">
<img src="/images/flow-workflow-agent-v10-de.svg" alt="Workflow Agent - Der Koordinator: Steuert einen mehrstufigen Prozess über mehrere Systeme." class="w-full" width="480" height="542" loading="lazy" />
</div>
</article>
<article class="flex flex-col lg:flex-row gap-8 lg:gap-12 items-start">
<div class="flex-shrink-0 w-16 h-16 lg:w-20 lg:h-20 rounded-full bg-gosign-accent/10 flex items-center justify-center">
<span class="text-h1 lg:text-hero font-bold text-gosign-accent-text">03</span>
</div>
<div class="flex-1 lg:w-[55%]">
<h3 class="text-h2 font-bold text-gosign-dark">Knowledge Agents</h3>
<p class="text-body-lg text-gosign-text-light mt-3">Der Wissensträger: beantwortet Fragen aus dem Unternehmenswissen. Ein HR-Manager fragt: 'Ab wann muss bei Langzeiterkrankung ein BEM-Verfahren eingeleitet werden?' Der Agent sucht nicht nur - er interpretiert Betriebsvereinbarung, Tarifvertrag und gesetzliche Vorgaben im Kontext der Frage, und liefert eine spezifische Antwort mit Quellenangabe, Regelversion und Gültigkeitsdatum. Bei Unsicherheit markiert er sie explizit. Ohne verifizierte Quelle erfolgt keine Antwort - der Agent halluziniert nicht.</p>
<a href="/de/leistungen/ai-agents/knowledge-agents/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
Knowledge Agents im Detail
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</div>
<div class="lg:w-[40%] mt-4 lg:mt-11">
<img src="/images/flow-knowledge-agent-v10-de.svg" alt="Knowledge Agent - Der Wissensträger: Frage mit Kontext rein, Agent interpretiert verifizierte Quellen, spezifische Antwort mit Quelle und Version raus." class="w-full" width="480" height="628" loading="lazy" />
</div>
</article>
</div>
</section>

<!-- Architekturvergleich -->
<section class="scroll-reveal py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Architekturvergleich: Copilot, SaaS Agent, Gosign</h2>
<p class="text-body-lg text-gosign-text-light mb-8">Drei Ansätze für Enterprise AI - unterschiedliche Architekturen, unterschiedliche Konsequenzen.</p>
<div class="overflow-x-auto -mx-4 sm:mx-0">
<table class="w-full min-w-[36rem] border-collapse text-small">
<thead>
<tr>
<th class="px-4 py-3 text-left font-semibold bg-gosign-dark text-white">Dimension</th>
<th class="px-4 py-3 text-left font-semibold bg-gosign-dark text-white border-t-[3px] border-t-gosign-accent">Gosign Agent Architecture</th>
<th class="px-4 py-3 text-left font-semibold bg-gosign-dark text-white">Microsoft Copilot</th>
<th class="px-4 py-3 text-left font-semibold bg-gosign-dark text-white">SaaS AI Agent</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Entscheidungstiefe</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border bg-gosign-accent/5">Fachentscheidungen mit Decision Layer</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Assistenz und Vorschläge</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Vorkonfigurierte Workflows</td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Auditierbarkeit</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border bg-gosign-accent/5">Vollständiger Audit Trail bis SQL-Level</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Basis-Logging</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Plattform-Logging</td>
</tr>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Quellcode-Zugang</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border bg-gosign-accent/5">Voller Quellcode-Zugang · Konfigurationen beim Kunden · Kein Vendor Lock-in</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Microsoft besitzt Code</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Plattform besitzt Code</td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Modellwahl</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border bg-gosign-accent/5">Modell-agnostisch (GPT, Claude, Gemini, Llama, Mistral)</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">GPT (Microsoft-gebunden)</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Plattform-gebunden</td>
</tr>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Governance</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border bg-gosign-accent/5">Eigener Governance Layer, Cert-Ready Controls, Auditor Portal</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Azure Governance</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Plattform-Governance</td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Human-in-the-Loop</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border bg-gosign-accent/5">Architektonisch erzwungen bei Risikoentscheidungen</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Optional</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Konfigurierbar</td>
</tr>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">EU AI Act</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border bg-gosign-accent/5">Compliant by Design - Transparenz, Erklärbarkeit, Aufsicht eingebaut</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Microsoft Roadmap</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Anbieterabhängig</td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Betriebsrat / Mitbestimmung</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border bg-gosign-accent/5">Vorlagen, Logging, Rollenkonzepte</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Keine spezifische Unterstützung</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Keine spezifische Unterstützung</td>
</tr>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Prüfungssicherheit</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border bg-gosign-accent/5">GoBD, ISA, IDW - Verfahrensdokumentation als Architektur</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Plattform-Compliance</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Plattform-Compliance</td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Infrastruktur</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border bg-gosign-accent/5">Kundeninfrastruktur (Azure, GCP, AWS, Self-Hosted, Hybrid)</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Microsoft Cloud</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Anbieter-Cloud</td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Exit-Strategie</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border bg-gosign-accent/5">Eigenständiger Betrieb nach 12-18 Monaten</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Plattform-Migration</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Plattform-Migration</td>
</tr>
</tbody>
</table>
</div>
<p class="text-small text-gosign-text-light italic mt-4">
Diese Tabelle zeigt architektonische Unterschiede, keine Qualitätsurteile. Copilot und SaaS-Agents haben andere Stärken - Geschwindigkeit, Ökosystem, Einfachheit. Die Stärke der Gosign-Architektur ist Governance, Eigentum und Auditierbarkeit in regulierten Umgebungen.
</p>
</div>
</section>

<!-- Governance by Design -->
<section class="scroll-reveal bg-gosign-dark text-white py-section">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold">Governance by Design</h2>
<p class="text-h3 text-gosign-accent-on-dark font-semibold mt-4">
Agenten skalieren nur mit Infrastruktur. Ohne Governance bleibt AI ein Pilot - mit Infrastruktur wird sie skalierbar.
</p>
<div class="mt-8 space-y-4">
<p class="text-body-lg text-gosign-text-on-dark/80 flex items-start gap-3">
<svg class="w-5 h-5 mt-1 flex-shrink-0 text-gosign-accent-on-dark" fill="currentColor" viewBox="0 0 20 20"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span>Human-in-the-Loop als Architekturprinzip - architektonisch erzwungen, nicht optional</span>
</p>
<p class="text-body-lg text-gosign-text-on-dark/80 flex items-start gap-3">
<svg class="w-5 h-5 mt-1 flex-shrink-0 text-gosign-accent-on-dark" fill="currentColor" viewBox="0 0 20 20"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span>Vollständiger Audit Trail für jede Agenten-Entscheidung - bis auf SQL-Level</span>
</p>
<p class="text-body-lg text-gosign-text-on-dark/80 flex items-start gap-3">
<svg class="w-5 h-5 mt-1 flex-shrink-0 text-gosign-accent-on-dark" fill="currentColor" viewBox="0 0 20 20"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span>Mitbestimmungsfähig - Betriebsvereinbarungen als explizite Constraints im Decision Layer</span>
</p>
<p class="text-body-lg text-gosign-text-on-dark/80 flex items-start gap-3">
<svg class="w-5 h-5 mt-1 flex-shrink-0 text-gosign-accent-on-dark" fill="currentColor" viewBox="0 0 20 20"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span>Revisionssicher - Cert-Ready by Design mit automatischer Evidenz-Generierung</span>
</p>
<p class="text-body-lg text-gosign-text-on-dark/80 flex items-start gap-3">
<svg class="w-5 h-5 mt-1 flex-shrink-0 text-gosign-accent-on-dark" fill="currentColor" viewBox="0 0 20 20"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span>EU AI Act compliant by design - Transparenz, menschliche Aufsicht, Aufzeichnungspflichten architektonisch eingebaut</span>
</p>
<p class="text-body-lg text-gosign-text-on-dark/80 flex items-start gap-3">
<svg class="w-5 h-5 mt-1 flex-shrink-0 text-gosign-accent-on-dark" fill="currentColor" viewBox="0 0 20 20"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span>Modell-agnostisch - kein Vendor Lock-in, eigener Quellcode, eigenständiger Betrieb nach 12-18 Monaten</span>
</p>
</div>
</div>
<div class="mt-12 overflow-x-auto -mx-4 sm:mx-0 px-4 sm:px-0">
<img src="/images/diagrams/decision-layer-drei-arten.svg" alt="Drei Autonomiestufen im Gosign Decision Layer: (1) Mensch entscheidet, (2) Agent arbeitet Mensch prüft, (3) Agent selbstständig. Jede Entscheidung dokumentiert, jeder Schritt auditierbar." width="900" height="360" class="w-full min-w-[600px] max-w-4xl mx-auto rounded-lg" loading="lazy" />
</div>
</div>
</section>

<!-- Definition: Decision Layer -->
<section class="scroll-reveal py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h3 class="text-h3 font-bold text-gosign-dark">Definition: Decision Layer</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Der Decision Layer zerlegt jeden Geschäftsprozess in einzelne Entscheidungsschritte und definiert für jeden Schritt vorab: Entscheidet ein Mensch, ein Regelwerk oder die KI eigenständig?
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Wo Ermessensspielraum, Diskriminierungsrisiko oder Mitbestimmung eine Rolle spielen, erzwingt die Architektur menschliche Prüfung. Wo eine Entscheidung deterministisch ist - Tarifvertrag, Fristprüfung, Buchungslogik - wendet der Agent das Regelwerk konsistent an. Und wo der Agent confident genug ist und die Erlaubnis hat: entscheidet er eigenständig. Er interpretiert Dokumente, klassifiziert Sachverhalte, bewertet Kontext - nachweislich konsistenter und rechtssicherer als manuelle Bearbeitung.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Jede Entscheidung wird dokumentiert - wer hat wann was entschieden, auf welcher Grundlage, mit welchem Ergebnis. Prüfbar für Wirtschaftsprüfer, Betriebsrat und interne Revision.
</p>
<p class="mt-4">
<a href="/de/governance/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Governance, Sicherheit & Audit</a>
</p>
</div>
</div>
</section>

<!-- Vom PoC zur Plattform -->
<section class="scroll-reveal py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark text-center">Vom PoC zur Plattform</h2>
<div class="mt-12 grid grid-cols-1 md:grid-cols-3 gap-8 relative">
<div class="text-center">
<div class="w-14 h-14 mx-auto rounded-full bg-gosign-accent flex items-center justify-center">
<span class="text-h3 font-bold text-white">1</span>
</div>
<h3 class="text-h3 font-bold text-gosign-dark mt-4">Discover</h3>
<p class="text-small font-semibold text-gosign-accent-text mt-1">1 Woche</p>
<p class="text-body text-gosign-text-light mt-2">Prozessanalyse, Regelwerke verstehen, Use Cases priorisieren.</p>
</div>
<div class="text-center">
<div class="w-14 h-14 mx-auto rounded-full bg-gosign-accent flex items-center justify-center">
<span class="text-h3 font-bold text-white">2</span>
</div>
<h3 class="text-h3 font-bold text-gosign-dark mt-4">Build</h3>
<p class="text-small font-semibold text-gosign-accent-text mt-1">3-4 Wochen</p>
<p class="text-body text-gosign-text-light mt-2">Produktiver PoC. Ein Agent, ein Prozess, live in Ihrer Infrastruktur.</p>
</div>
<div class="text-center">
<div class="w-14 h-14 mx-auto rounded-full bg-gosign-accent flex items-center justify-center">
<span class="text-h3 font-bold text-white">3</span>
</div>
<h3 class="text-h3 font-bold text-gosign-dark mt-4">Scale</h3>
<p class="text-small font-semibold text-gosign-accent-text mt-1">Kontinuierlich</p>
<p class="text-body text-gosign-text-light mt-2">Mehr Agenten, mehr Prozesse. Gleiche Governance, gleiche Auditierbarkeit.</p>
</div>
</div>
<p class="text-body-lg text-center text-gosign-text-light mt-8 max-w-narrow mx-auto">
Nach 12-18 Monaten betreiben Sie Ihre Agenten eigenständig. Voller Zugang zu Quellcode, Prompts und Regelwerken. Kein Vendor Lock-in - auch ohne Wartungsvertrag.
</p>
</div>
</section>

--- HR-Audit-Compliance-Agent ---
> HR-Audit-Vorbereitung mit prüfbarer Provenienz: Regelwerk prüft, KI indiziert, der Mensch gibt frei - eine Audit-Mappe, die der Betriebsrat unterschreibt.

## Im Audit zählt nicht, wie gut Ihre KI ist, sondern wer jeden Nachweis verantwortet

Ein Prüfer akzeptiert kein KI-Urteil über Rechtskonformität, eine Aufsichtsbehörde erst recht nicht, und der Betriebsrat unterschreibt keine Blackbox. Genau deshalb hilft "KI-gestützte Compliance" im DACH-Audit so wenig: Sie verspricht "Compliance" als Output und lässt offen, wer eigentlich entschieden hat. Was im Audit zählt, ist das Gegenteil - für jeden Nachweis muss belegbar sein, ob er aus einer Regel, aus einem KI-Indikator oder aus einer menschlichen Freigabe stammt, und ob er seitdem unverändert ist.

Dieser Agent folgt dem [Decision Layer](/de/decision-layer/)-Prinzip: Jeder Schritt der Audit-Vorbereitung ist entweder regelbasiert, ein KI-Indikator oder eine menschliche Freigabe - klar getrennt und unveränderbar protokolliert. Er selbst ist kein Hochrisiko-System nach dem [EU AI Act](https://eur-lex.europa.eu/eli/reg/2024/1689/oj), weil er keine Menschen bewertet. Er deckt vielmehr auf, welche Ihrer HR-Systeme es sind.

## Worauf ein HR-Audit zuerst zeigt - und wo es klemmt

Jedes Datenschutz-Audit greift zuerst zum Verzeichnis der Verarbeitungstätigkeiten nach [Artikel 30 DSGVO](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32016R0679) und fragt nach der Beschäftigten-Rechtsgrundlage. Genau hier wird es heute heikel: [Paragraph 26 BDSG](https://www.gesetze-im-internet.de/bdsg_2018/__26.html) gilt zwar fort, aber seit dem [EuGH-Urteil C-34/21 vom 30.03.2023](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:62021CJ0034) ist seine Tragfähigkeit erschüttert (Stand: Mai 2026). Eine HR-Verarbeitung, die allein darauf steht, steht auf wackeligem Grund - und ein Bußgeld kann bis zu 20 Millionen Euro oder 4 Prozent des weltweiten Konzernumsatzes erreichen, je nachdem welcher Betrag höher ist ([Artikel 83 Abs. 5 DSGVO](https://dejure.org/gesetze/DSGVO/83.html), Stand: Mai 2026).

Die zweite Bruchstelle ist die Mitbestimmung. Jede technische Einrichtung, die objektiv zur Überwachung von Verhalten oder Leistung geeignet ist, löst zwingende Mitbestimmung aus - nach ständiger Rechtsprechung genügt die objektive Eignung, eine Überwachungsabsicht ist unerheblich ([Paragraph 87 Abs. 1 Nr. 6 BetrVG](https://www.gesetze-im-internet.de/betrvg/__87.html)). Im Audit ist die Betriebsvereinbarung pro System der Nachweis; fehlt sie, ist das System kollektivrechtlich angreifbar.

Dass das real ist und nicht theoretisch, zeigt der KI-Einzug ins Personalwesen: 8 Prozent der Unternehmen nutzen KI bereits zur Bewertung der Arbeitsleistung von Beschäftigten, 6 Prozent zur Bewertung der Arbeitsbelastung ([Bitkom-Befragung, 852 Unternehmen, 2024](https://www.bitkom.org/Presse/Presseinformation/KI-Einzug-in-Personalabteilungen)). Solche Leistungsbewertung ist zugleich mitbestimmungspflichtig und Hochrisiko nach dem AI Act - und genau diese Systeme landen im nächsten Audit.

## Drei Quellen, sauber getrennt: wer prüft, wer indiziert, wer verantwortet

Die meisten Anbieter sagen, ein Mensch bleibe "im Prozess", und kleben ein Compliance-Siegel daneben. Das bleibt eine Blackbox. Der Agent macht stattdessen für jeden Schritt sichtbar, aus welcher von drei Quellen er stammt:

| Quelle | Was sie entscheidet | Beispiel aus der HR-Audit-Vorbereitung |
|--------|---------------------|----------------------------------------|
| **Regelwerk (R)** | Prüft Vollständigkeit und Fristen, kein Ermessen | Verzeichnis nach Artikel 30 vollständig, Betriebsvereinbarung pro System vorhanden, Frist nach Paragraph 147 AO eingehalten |
| **KI-Indikator (A)** | Markiert Auffälligkeiten mit Konfidenz, urteilt nie | Auswahl- oder Vergütungsmuster nach Schutzmerkmal, DSFA-Verdacht, Hochrisiko-Einstufung als Vorschlag |
| **Mensch (H)** | Gibt frei und bewertet rechtlich | Freigabe der Audit-Mappe, Verstoß-Würdigung, Eskalation an Vorstand oder Betriebsrat |

Der Agent ist damit überwiegend ein deterministischer Vollständigkeits- und Fristen-Prüfer, mit KI nur als Indikator an den Rändern und einem festen menschlichen Freigabe-Gate. Das ist die ehrliche Antwort auf den naheliegenden Einwand "darf eine KI über Compliance urteilen?" - sie darf nicht, und der Agent ist so gebaut, dass sie es nicht kann. Wer freigibt, sieht jeden KI-Indikator als solchen markiert, mit Konfidenz-Score und Erklärungskandidaten, bevor er ihn übernimmt. Wie diese Schicht architektonisch durchgreift, zeigt der [Decision Layer](/de/decision-layer/).

## Warum der KI-Indikator nie ein Urteil ist

Statistische Auffälligkeiten in Personal-Entscheidungen sind heikles Terrain: Ein falsch interpretiertes Muster kann ein Diskriminierungs-Risiko verschärfen statt entschärfen. Deshalb liefert der KI-Anteil hier bewusst kein Ergebnis, sondern einen Hinweis. Erkennt er etwa eine auffällige Vergütungs- oder Beförderungsverteilung nach einem Schutzmerkmal, gibt er einen Konfidenz-Score und die drei wahrscheinlichsten Erklärungskandidaten aus - Bewerber-Pool-Verzerrung, qualifikationsbedingte Auswahl, branchentypische Verteilung - und eskaliert ab Schwellwert an den Menschen. Ob daraus ein Befund wird, entscheidet die Würdigung im Einzelfall.

Dieselbe Logik trägt die AI-Act-Einstufung: Der Agent schlägt vor, ob ein HR-System unter Anhang III Nr. 4 fällt ([EU AI Act, Anhang III](https://artificialintelligenceact.eu/annex/3/)), und begründet den Vorschlag - aber die rechtliche Einstufung mit ihren Folgen ist begründungspflichtig und bleibt beim Menschen. Wichtig für die Zeitplanung: Die Hochrisiko-Pflichten für eigenständige Anhang-III-Systeme sollten ursprünglich am 02.08.2026 greifen; eine Verschiebung auf den 02.12.2027 ist politisch vereinbart, zum Stand Mai 2026 aber noch nicht förmlich in Kraft. Bis zur Veröffentlichung im Amtsblatt bleibt der 02.08.2026 das geltende Datum - der Agent rechnet mit beiden und kennzeichnet das spätere als Prognose.

## Der Nachweis entsteht zur Laufzeit, nicht in der Nacht vor dem Termin

Ein Compliance-Befund, der aus einem KI-Modell ohne integrierten Nachweis kommt, ist für ein Audit wertlos: Er ist nicht reproduzierbar, und es ist nicht dokumentiert, welche Eingaben ihn erzeugt haben. Ein Walk-Through nach [IDW PS 980 n.F.](https://www.idw.de/idw/idw-aktuell/idw-ps-980-n-f-09-2022-zur-pruefung-von-compliance-management-systemen-verab-schiedet.html) verlangt aber genau das Gegenteil - eine nachvollziehbare Spur durch die Grundelemente des Compliance-Management-Systems.

Deshalb trägt beim Agenten jeder Prüfschritt seinen Nachweis bei sich: Quelle, Eingabe, Begründung, Zeitstempel und die angewandte Regelversion - append-only, nicht nachträglich änderbar. Die Audit-Dokumentation wächst mit jeder Prüfung mit, statt als separates Schriftstück gepflegt zu werden. Und die Nachweise bleiben festgeschrieben und aufbewahrt, solange das Gesetz es verlangt: über die jeweils geltende handels- und steuerrechtliche Frist nach [Paragraph 147 AO](https://www.gesetze-im-internet.de/ao_1977/__147.html) - bis zu zehn Jahre für Bücher und Abschlüsse, seit dem Wachstumschancengesetz acht Jahre für Buchungsbelege -, GoBD-konform unveränderbar (Stand: Mai 2026). Fehlt ein geforderter Nachweis, markiert der Agent die Lücke vor dem Termin - nicht der Prüfer im Termin.

## Über SAP, Workday und Personio, nicht statt ihnen

Der Agent konkurriert nicht mit Ihrer HR-Suite. Gegen SAP, Workday oder Personio auf der Datenhaltungs-Achse anzutreten wäre sinnlos - dort liegen die Personaldaten, und dort sollen sie bleiben. Der Agent legt sich als Entscheidungs- und Nachweis-Schicht darüber: Er zieht Stichproben und Verzeichnisse aus den bestehenden Systemen und macht daraus eine auditfähige Mappe mit belegter Verantwortung pro Eintrag.

Was hinzukommt, ist kein weiteres System, sondern die Antwort auf die Frage des Prüfers und des Betriebsrats zugleich: Für jeden Nachweis lässt sich sagen, ob ihn eine Regel, ein KI-Indikator oder ein Mensch verantwortet hat - und es ist unveränderbar belegt. Eine Mappe, bei der transparent ist, dass die KI nur indiziert und der Mensch entscheidet, ist genau die Lösung, die der Betriebsrat mitträgt, bevor sie dem Vorstand vorliegt - und die zugleich die menschliche Aufsicht des AI Act und die Mitbestimmung nach BetrVG als Architektur erfüllt.

Der nächste Schritt ist keine Software-Einführung, sondern eine Bestandsaufnahme: Welche Ihrer HR-Systeme sind heute überwachungsgeeignet oder AI-Act-relevant, und wie prüfungsfest ist der Nachweis dahinter?

## Auf einen Blick

- **Was er tut**: bereitet HR-Audits vor und indiziert Risiken - prüft Vollständigkeit und Fristen, markiert Auffälligkeiten, dokumentiert jeden Schritt unveränderbar
- **Klassifikation**: selbst kein EU-AI-Act-Hochrisiko-System (bewertet keine Menschen), deckt aber Hochrisiko-HR-Systeme auf
- **Entscheidungslogik**: Regelwerk prüft, KI indiziert mit Konfidenz, der Mensch gibt frei und bewertet rechtlich
- **Compliance-Anker**: Verzeichnis nach Artikel 30 DSGVO, Mitbestimmung nach Paragraph 87 BetrVG, IDW PS 980, Aufbewahrung über die jeweils geltende Frist nach Paragraph 147 AO (bis zu zehn Jahre, Stand: Mai 2026)
- **Integration**: Schicht über SAP, Workday, Personio oder DATEV - kein Ersatz
- **Prüfungsfall**: jeder Nachweis bis zur Quelle und zur verantwortenden Person rückverfolgbar, jeder KI-Indikator anfechtbar

--- Benefits-Enrollment-Agent ---
> Benefits- und bAV-Anmeldung mit Decision-Layer: feste Pflichtzuschuss- und Grenzprüfung, KI nur Vorschlag, Mitbestimmung und Gesundheitsdaten beim Menschen.

## Welche Benefits-Entscheidung kostet Sie im Prüfungsfall wirklich Geld?

Das Prüfungsrisiko der betrieblichen Altersversorgung steckt nicht in den rund 14 Verwaltungsschritten, sondern in fünf Entscheidungen, die kein Verwaltungssystem allein treffen darf. Die meisten Schritte sind reine Routine - Verträge anlegen, Fristen überwachen, Stammdaten pflegen. Teuer wird es genau dort, wo arbeitsrechtliche Zusage, steuerliche Förderung, sozialversicherungsrechtliche Grenze, Mitbestimmung und Datenschutz aufeinandertreffen. Dieser Agent konzentriert sich auf diese wenigen tragenden Entscheidungen und lässt die Routine Routine sein.

Ein falsch berechneter Pflichtzuschuss, eine übergangene Mitbestimmung oder eine unzulässig erhobene Gesundheitsangabe fällt selten sofort auf - sondern erst in der Betriebsprüfung oder im Datenschutz-Audit, dann mit Nachzahlung, Bußgeld und im Zweifel persönlicher Verantwortung. Der Pflicht-Arbeitgeberzuschuss von 15 Prozent bei Entgeltumwandlung nach [Paragraph 1a BetrAVG](https://www.gesetze-im-internet.de/betravg/__1a.html) gilt seit 2022 auch für Altverträge; wird er vergessen, entsteht ein einklagbarer Nachzahlungsanspruch und die Deutsche Rentenversicherung beanstandet die Lücke (Stand: Mai 2026). Das ist der häufigste stille bAV-Fehler in der Lohnabrechnung.

## Die teuren Fälle sind keine Rechenarbeit, sondern Auslegung

Moderne HR-Systeme verwalten Verträge, Fristen und Stammdaten zuverlässig - was sie nicht leisten, ist die Vorab-Entscheidung, ob überhaupt eine Mitbestimmung vorliegt, ein Pflichtzuschuss fällig ist oder eine Gesundheitsangabe erhoben werden darf. Diese Einordnung verlangt Kontext, der in keinem Stammdatensatz steht. Sie ist der Grund, warum die zweite Säule trotz Rechtsanspruch stagniert: Die bAV ist kein Gesetzes-, sondern ein Umsetzungsproblem.

Wie sehr es am Prozess und nicht am Anspruch hängt, zeigt die Verbreitung nach Betriebsgröße. Insgesamt hatten Ende 2023 nur 51,9 Prozent der sozialversicherungspflichtig Beschäftigten eine bAV, rückläufig gegenüber 53,4 Prozent in 2019, belegt im [Alterssicherungsbericht 2024](https://www.aba-online.de/alterssicherungsbericht-anteil-besch%C3%A4ftigte-mit-bav) (Stand 2023). Dieselbe Quelle weist die eigentlich aussagekräftige Spreizung aus: In Betrieben unter 10 Mitarbeitenden liegt die Verbreitung bei 25 Prozent, in Betrieben ab 1.000 bei 86 Prozent. Große Organisationen scheitern nicht am Recht, sondern an der sauberen, prüfbaren Durchführung im Mengengeschäft.

## Fünf Entscheidungen tragen die gesamte Compliance-Last

Diese fünf Rahmen entscheiden über das Prüfungsrisiko - jeder mit einem anderen Prüfer und einer anderen Folge, wenn er falsch läuft:

| Entscheidung | Risiko im Prüfungsfall | Wer entscheidet |
|---|---|---|
| Pflichtzuschuss und Fördergrenzen | Nachforderung der Deutschen Rentenversicherung | Regelwerk (deterministisch) |
| Mitbestimmung des Betriebsrats | Unterlassungsanspruch, gestoppte Maßnahme | Mensch (Betriebsrat) |
| Umgang mit Gesundheitsdaten | DSGVO-Bußgeld bis 20 Millionen Euro | Mensch (Einwilligung) |
| Nachweispflicht | Bußgeld bis 2.000 Euro pro Verstoß | Regelwerk (Checkliste) |
| Eignung eines Optionssystems (BRSG II) | falsch berechneter Zuschuss | KI-Vorschlag, Freigabe Mensch |

**Pflichtzuschuss und Fördergrenzen.** Wer die Entgeltumwandlung steuerfrei bis 8 Prozent der Beitragsbemessungsgrenze rechnet, aber die nur bis 4 Prozent reichende Sozialversicherungsfreiheit übersieht, produziert eine Nachforderung. Maßgeblich sind 2026 eine Bemessungsgrenze von 101.400 Euro pro Jahr, daraus 8.112 Euro steuerfrei nach [Paragraph 3 Nr. 63 EStG](https://www.gesetze-im-internet.de/estg/__3.html) und 4.056 Euro beitragsfrei nach [Paragraph 1 SvEV](https://www.gesetze-im-internet.de/svev/__1.html), die Bemessungsgrenze belegt von der [Deutschen Rentenversicherung](https://www.deutsche-rentenversicherung.de/DRV/DE/Experten/Arbeitgeber-und-Steuerberater/summa-summarum/Lexikon/B/beitragsbemessungsgrenze.html) (Stand: Mai 2026). Diese Doppelgrenze ist die eine Zahl, die in der Abrechnung wirklich falsch laufen kann, und der Agent prüft jeden Beitrag deterministisch gegen beide Schwellen.

**Mitbestimmung.** Wo ein Betriebsrat existiert, sind Ausgestaltung und Verteilungsgrundsätze freiwilliger Sozialleistungen erzwingbar mitbestimmungspflichtig nach [Paragraph 87 BetrVG](https://www.gesetze-im-internet.de/betrvg/__87.html). Das Unternehmen entscheidet das Ob der Leistung, nicht aber allein das Wie der Verteilung; bei Übergehen kann der Betriebsrat die Maßnahme per Unterlassungsanspruch stoppen (Stand: Mai 2026). Für einen Konzern ist das der eigentliche Show-Stopper, nicht das Steuerrecht - und genau hier markiert der Agent jede Maßnahme zur Vorlage, statt sie selbst zu entscheiden.

**Datenschutz.** Gesundheitsdaten aus einer Gesundheitsprüfung sind besondere Kategorie nach [Artikel 9 DSGVO](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX%3A32016R0679), und der Arbeitgeber darf sie nicht erheben oder einsehen. Bei Zusatzversicherungen läuft die Datenstrecke direkt zwischen Mitarbeiter und Versicherer; ein Verstoß kann nach [Artikel 83 DSGVO](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX%3A32016R0679#d1e6196-1-1) mit bis zu 20 Millionen Euro oder 4 Prozent des weltweiten Konzernumsatzes geahndet werden, je nachdem welcher Betrag höher ist (Stand: Mai 2026). Korrekte Architektur heißt Trennung der Datenflüsse, nicht Einwilligung einsammeln und alles verarbeiten.

**Nachweispflicht.** Name und Anschrift des Versorgungsträgers gehören nach [Paragraph 2 NachweisG](https://www.gesetze-im-internet.de/nachwg/__2.html) zu den nachweispflichtigen Bedingungen, und ein Versäumnis kostet bis zu 2.000 Euro pro Verstoß. Die fünfte Entscheidung schließlich bringt das BRSG II ins Spiel - neues, bereits geltendes Recht, dem der nächste Abschnitt gehört.

## Das BRSG II ändert die Rechtslage - und die häufigste Fehlinterpretation gleich mit

Das Zweite Betriebsrentenstärkungsgesetz ist geltendes Recht, nicht Zukunftsmusik: Es wurde am 21.01.2026 im Bundesgesetzblatt verkündet und gilt überwiegend seit dem 22.01.2026, dokumentiert beim [Bundesministerium für Arbeit und Soziales](https://www.bmas.de/DE/Service/Gesetze-und-Gesetzesvorhaben/zweites-gesetz-staerkung-betriebliche-altersversorgung.html) (Stand: Mai 2026). Für die Anmeldung relevant sind zwei Hebel: Opting-out-Systeme per Betriebsvereinbarung auch ohne Tarifbindung - seit dem 22.01.2026 zulässig und gebunden an einen erhöhten Arbeitgeberzuschuss von mindestens 20 Prozent -, sowie eine ab dem 01.01.2027 steigende Geringverdiener-Förderung.

Die häufigste Fehlinterpretation des neuen Gesetzes betrifft genau diese Zahl. Der Pflicht-Zuschuss bei klassischer Entgeltumwandlung bleibt bei 15 Prozent - die 20 Prozent gelten ausschließlich beim Opting-out-Modell, wo sie zugleich die bestehende Zuschusspflicht erfüllen. Wer beide vermischt, rechnet entweder zu viel oder übersieht die Bedingung des Optionssystems. Der Agent kennt diese Unterscheidung und markiert die Eignung eines Optionssystems als Vorschlag, ohne die betriebspolitische Entscheidung vorwegzunehmen. Den größten Hebel hat ein Optionssystem dort, wo die Verbreitung heute am niedrigsten ist - in den kleinen Betrieben mit ihren 25 Prozent gegenüber 86 Prozent in den großen.

## Der Agent ist eine Schicht über Ihren Systemen, nicht ihr Ersatz

Die meisten Organisationen haben in HR-System, Onboarding und Vertragsverwaltung investiert, und der Agent ersetzt keines davon - er legt sich als Entscheidungsschicht darüber. Er liest Stammdaten und Entgeltumwandlungsvereinbarungen aus dem führenden System, prüft sie gegen die aktuellen Fördergrenzen und übergibt eine priorisierte Liste statt 14 gleichrangiger Verwaltungsschritte. Die Datenstrecke für Gesundheitsangaben bleibt dabei strukturell ausgespart, sodass besondere Kategorien gar nicht erst beim Arbeitgeber auflaufen.

Dieser Ansatz folgt dem Prinzip [Decision Layer](/de/decision-layer/): Die Maschine trifft die Entscheidungen, die sie deterministisch treffen kann, liefert dort einen Indikator, wo eine menschliche Bewertung nötig ist, und reicht den Letztentscheid weiter, wo das Gesetz ihn dem Menschen vorbehält. Konkret heißt das harte Rechenregeln für Anspruch, Zuschuss und Grenzprüfung, einen begründeten Vorschlag für den Durchführungsweg und den menschlichen Letztentscheid bei Betriebsratszustimmung, Mitarbeiterwahl und Gesundheitsdaten-Einwilligung. Jeder Schritt trägt seinen Entscheidungsträger sichtbar mit.

## Der Agent auf einen Blick

- **Was er tut:** ordnet jede Benefits- und bAV-Anmeldung nach festen Regeln und reicht nur die wenigen entscheidungsrelevanten Fälle priorisiert weiter.
- **Klassifikation:** kein Hochrisiko-System nach EU AI Act - administrative Anmeldung, keine Bewertung von Mitarbeitenden.
- **Entscheidungslogik:** Regelwerk für Anspruch, Zuschuss und Grenzprüfung, KI-Indikator für Durchführungsweg und Sonderfälle, menschlicher Letztentscheid bei Betriebsrat, Mitarbeiterwahl und Gesundheitsdaten.
- **Compliance-Anker:** 15 Prozent Pflichtzuschuss nach Paragraph 1a BetrAVG, Doppelgrenze 8.112 / 4.056 Euro, Mitbestimmung nach Paragraph 87 BetrVG, Gesundheitsdaten nach Artikel 9 DSGVO.
- **Integration:** Schicht über SAP SuccessFactors, Workday oder Personio - liest Stammdaten, ersetzt kein System.
- **Im Prüfungsfall:** jede Entscheidung trägt ihren Träger und ihre Rechengrößen protokolliert mit, nachvollziehbar für Betriebsprüfung nach Paragraph 28p SGB IV und Datenschutz-Audit.

## Warum Entscheidungs-Governance der eigentliche Unterschied ist

Übliche Benefits- und HR-Tools versprechen, das Enrollment zu automatisieren - Eingabe rein, Datensatz raus, Audit-Trail dran. Genau hier liegt ihr blinder Fleck: Bei einem mitbestimmungspflichtigen Benefit nach Paragraph 87 BetrVG und bei Gesundheitsdaten nach Artikel 9 DSGVO ist Voll-Automatisierung nicht nur unklug, sondern rechtswidrig. Der Differenzierer dieses Agenten ist deshalb nicht Geschwindigkeit, sondern Nachvollziehbarkeit: Er zieht die Grenze zwischen Maschine und Mensch sichtbar pro Schritt.

Das ist die eigentliche Wertschöpfung - nicht die Automatisierung der Routine, sondern die prüfbare Trennung von Routine und Ausnahme. Der Betriebsrat und der Datenschutzbeauftragte können vor Einführung nachvollziehen, dass menschliche Entscheidungen menschlich bleiben, und genau das macht eine Lösung freigabefähig, die ein reines Automatisierungs-Versprechen nicht liefern kann. Der nächste Schritt ist deshalb keine Software-Einführung, sondern eine Prozess-Analyse: Welche Schritte laufen heute manuell, welche sind regelbasiert, und wo entstehen die teuren Fälle? Diese Bestandsaufnahme zeigt, wo der Agent den größten Hebel hat - und wo die menschliche Entscheidung unverzichtbar bleibt.

--- Bewerber-Screening-Agent ---
> Bewerber-Vorauswahl, die der Betriebsrat unterschreibt: Regelwerk filtert, KI begründet, der Mensch entscheidet - DSGVO Art. 22 und AGG-fest dokumentiert.

## Jedes Screening-Tool sortiert. Keines liefert den Entlastungsbeweis.

SAP SuccessFactors, Workday, Personio - aus einem Stapel Bewerbungen wird per Knopfdruck eine sortierte Liste. Das ist seit Jahren Standard. Die Frage, an der ein Recruiting-Prozess und eine Diskriminierungsklage wirklich hängen, beantwortet keines dieser Systeme: Hat ein Mensch jede Absage verantwortet, auf welcher sachlichen Grundlage - und können Sie das beweisen, wenn ein abgelehnter Bewerber vor dem Arbeitsgericht steht?

Dieser Agent folgt dem [Decision Layer](/de/decision-layer/)-Prinzip: Jeder Schritt ist entweder regelbasiert, ein KI-Vorschlag oder eine menschliche Entscheidung - klar getrennt und nachvollziehbar protokolliert. Nach [Anhang III Nr. 4a EU AI Act](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32024R1689) ist Bewerber-Screening ein Hochrisiko-System. Diese Einstufung steht fest; ihr Stichtag verschiebt sich voraussichtlich auf Dezember 2027 (Stand: Mai 2026). Hochrisiko bleibt es trotzdem - also baut man die Governance jetzt richtig.

## Die zwei Linien, die jedes Screening-Tool reißt: Artikel 22 und die Beweislast

Die meisten Anbieter verkaufen "die KI macht eure Vorauswahl" und kleben ein Compliance-Siegel daneben. Zwei harte Rechtslinien werden dabei regelmäßig überfahren, und beide sind teuer.

Die erste zieht [Artikel 22 DSGVO](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32016R0679): Eine Bewerbungsablehnung allein durch einen Algorithmus, ohne menschliche Letztentscheidung, ist eine verbotene automatisierte Einzelentscheidung mit erheblicher Wirkung. Wer eine KI über Absagen entscheiden lässt, riskiert ein Bußgeld bis zu 20 Millionen Euro oder vier Prozent des weltweiten Konzernumsatzes (Art. 83 Abs. 5, Stand: Mai 2026) - dazu Schadensersatz. Der Mensch muss die Absage tragen, nicht das Modell.

Die zweite zieht das AGG, und sie ist im Alltag noch gefährlicher. Legt ein abgelehnter Bewerber Indizien für eine Diskriminierung vor - etwa weil die KI über ein Proxy-Merkmal wie Foto, Name oder Beschäftigungslücke gefiltert hat -, kehrt [Paragraph 22 AGG](https://www.gesetze-im-internet.de/agg/__22.html) die Beweislast um: Dann muss der Arbeitgeber beweisen, dass nicht diskriminiert wurde. Bei einer Blackbox-KI, die einen Score ohne Begründung ausspuckt, ist dieser Gegenbeweis praktisch unmöglich - der Score wird zum Belastungsindiz ohne Entlastungsmöglichkeit. Die Entschädigung bei Nichteinstellung beträgt bis zu drei Monatsgehälter ([Paragraph 15 AGG](https://www.gesetze-im-internet.de/agg/__15.html), Stand: Mai 2026), geltend zu machen binnen zwei Monaten ab Zugang der Absage. Genau hier verfehlen Score-Tools ihr eigentliches Versprechen: Sie sollen Risiko senken und erzeugen in Wahrheit ein neues.

## Drei Quellen, klar getrennt: wer entscheidet was

Statt einer Blackbox macht der Agent für jeden Schritt sichtbar, aus welcher von drei Quellen die Entscheidung stammt. Das ist die direkte Antwort auf die zwei Rechtslinien oben.

| Quelle | Was sie entscheidet | Beispiel im Screening |
|--------|---------------------|------------------------|
| **Regelwerk (R)** | Alles Deterministische, kein Ermessen | K.O.-Kriterien wie Pflicht-Qualifikation, Mindest-Berufsjahre, Sprachniveau; formale Vollständigkeit |
| **KI-Vorschlag (A)** | Schlägt vor und begründet, entscheidet nie | Skill-Match gegen das Anforderungsprofil, Markieren statistischer Auffälligkeiten |
| **Mensch (H)** | Auswahl, Absage und rechtliche Beurteilung | Shortlist- und Ablehnungsentscheidung, Anhörung der Schwerbehindertenvertretung |

Das Regelwerk filtert hart und reproduzierbar, die KI sortiert und begründet, der Mensch entscheidet und haftet. Diese Trennung ist juristisch tragend, nicht kosmetisch. K.O.-Kriterien wie Pflicht-Qualifikation, geforderte Berufsjahre oder ein nachgewiesenes Sprachniveau stehen im Anforderungsprofil, enthalten kein geschütztes Merkmal und sind für jeden Bewerber reproduzierbar - das macht sie AGG-fest: Wer hier aussortiert wird, sieht das objektive Kriterium. Der Skill-Match ist eine andere Klasse: Die KI extrahiert Qualifikationen, gewichtet sie und liefert je Treffer eine Begründung, aber Geburtsdatum, Foto, Familienstand oder Herkunft gehen nie in die Bewertung ein, weil sie keine fachliche Aussage tragen und sofort zu Proxy-Diskriminierung führen. Hier liegt auch der Schutz für schwerbehinderte Bewerber: Ein naiver Algorithmus, der eine Beschäftigungslücke negativ scort, diskriminiert mittelbar wegen Behinderung und verstößt gegen [Paragraph 164 Abs. 2 SGB IX](https://www.gesetze-im-internet.de/sgb_9_2018/__164.html). Deshalb begründet die KI jeden Score-Abzug offen - ein Abzug, der auf eine Lücke zurückgeht, wird zum Prüf-Indiz für den Menschen, nicht zur stillen Absage.

Der entscheidende Punkt für den naheliegenden Einwand "darf eine KI überhaupt Bewerber aussortieren?": Die KI darf das nicht - sie darf nur vorschlagen. Wer über die Absage entscheidet, sieht jeden KI-Vorschlag als solchen markiert, mit Begründung, bevor er entscheidet. So greift die menschliche Aufsicht auf den KI-Anteil zu, nicht an ihm vorbei. Wie diese Schicht architektonisch durchgreift, zeigt der [Decision Layer](/de/decision-layer/) im Detail.

## Der Nachweis entsteht zur Laufzeit, nicht nach der Klage

Ein KI-Vorschlag ohne integrierten Nachweis ist im Streitfall wertlos: Er ist nicht reproduzierbar, und es ist nicht dokumentiert, welche Eingaben ihn erzeugt haben. Genau das verlangt aber sowohl der EU AI Act mit der automatischen Aufzeichnung jeder Bewertung als auch - im Ernstfall entscheidend - die Beweislastumkehr des AGG.

Deshalb trägt beim Agenten jeder Schritt seinen Nachweis bei sich: welches K.O.-Kriterium über welche Regel griff, wie die KI welchen Skill-Match begründete, welche Auffälligkeit markiert wurde, wer die Shortlist oder Absage entschied und mit welcher sachlichen Begründung - append-only, nicht nachträglich änderbar. Dieser Decision-Log ist exakt der Entlastungsbeweis, den ein Arbeitgeber vor dem Arbeitsgericht braucht: Er belegt, dass merkmalsfrei gefiltert wurde, dass die KI nur vorschlug und dass ein Mensch sachlich entschieden hat. Aus einem Klage-Risiko wird so ein belegbarer Vorgang. Der Druck dahinter ist real - offene Stellen bleiben in Deutschland im Schnitt monatelang unbesetzt, Screening-Tempo ist also teuer. Aber Tempo, das vor Gericht zusammenbricht, ist teurer.

## Ein Verfahren, das der Betriebsrat unterschreibt - über dem System, nicht statt ihm

Der Agent konkurriert nicht mit Ihrem Bewerber-System. Gegen SAP SuccessFactors, Workday oder Personio auf der Workflow-Achse anzutreten wäre aussichtslos - dort entscheiden Marktanteil und Integration. Der Agent legt sich als Entscheidungs- und Nachweis-Schicht darüber: Sie behalten Ihren Bewerber-Prozess, und er macht die Auswahl prüfbar. Die getroffene Entscheidung fließt in das bestehende System zurück, ohne Doppelpflege.

Was hinzukommt, ist nicht ein weiteres Tool, sondern die Lösung für das eigentliche Nadelöhr im regulierten Recruiting: das Gremium. Setzt der Arbeitgeber KI für Auswahlrichtlinien ein, ist das nach [Paragraph 95 Abs. 2a BetrVG](https://www.gesetze-im-internet.de/betrvg/__95.html) mitbestimmungspflichtig - der Betriebsrat muss zustimmen, bei Streit entscheidet die Einigungsstelle. Eine Blackbox-KI bringt das Gremium in die Defensive und damit oft zum Nein. Ein Verfahren, dessen Auswahlkriterien offen und dessen Decision-Log vorlagefertig sind, dreht das um: Der Betriebsrat wird vom Hindernis zum Verbündeten, weil er nachvollziehen kann, wonach ausgewählt wird und dass kein Algorithmus über Absagen entscheidet. Dasselbe Verfahren überzeugt parallel den Datenschutz, der eine Folgenabschätzung für das KI-Recruiting verlangt.

Der nächste Schritt ist keine Software-Einführung, sondern eine Bestandsaufnahme: An welcher Stelle Ihres Auswahlprozesses trifft heute faktisch ein Score die Vorentscheidung, und wie belastbar ist die Begründung dahinter, wenn ein abgelehnter Bewerber sie vor dem Arbeitsgericht in Frage stellt? Wie diese Bestandsaufnahme im Detail abläuft, zeigt der [Recruiting-Agent](/de/recruiting-agent/).

## Auf einen Blick

- **Was er tut**: bereitet die Bewerber-Vorauswahl vor - Regelwerk filtert, KI begründet, der Mensch entscheidet die Absage - und protokolliert jeden Schritt nachvollziehbar
- **Klassifikation**: Hochrisiko-System nach EU AI Act (Anhang III Nr. 4a); Einstufung steht fest, Stichtag voraussichtlich Dezember 2027 (Stand: Mai 2026)
- **Entscheidungslogik**: K.O.-Kriterien regelbasiert, Skill-Match als KI-Vorschlag, Auswahl und Absage beim Menschen (Vier-Augen-Prinzip)
- **Compliance-Anker**: Artikel 22 DSGVO ohne automatisierte Absage, Paragraph 22 AGG mit Beweislastumkehr, Paragraph 95 Abs. 2a BetrVG mit Mitbestimmung bei KI, Paragraph 164 SGB IX zum Schwerbehindertenschutz
- **Integration**: Schicht über SAP SuccessFactors, Workday oder Personio - kein Ersatz
- **Streitfall**: jede Entscheidung bis zum Auswahlkriterium rückverfolgbar, der Decision-Log als AGG-Entlastungsbeweis und Betriebsrats-Vorlage

--- Zertifikats-Tracking-Agent ---
> Pflicht-Qualifikationen und Befähigungsnachweise tracken: deterministische Fristen-Logik, KI nur als Vorschlag, Mensch-Letztentscheid beim Einsatz-Stopp.

## Compliance scheitert selten an fehlenden Nachweisen, sondern an unbemerkt verfallenden Fristen

Die Pflichtnachweise sind meist da. Sie verfallen nur, weil ihre Fristen in verstreuten Tabellen liegen und niemand verbindlich entscheidet, wer einen abgelaufenen Nachweis stoppt. Genau diese Lücke wird teuer - nicht im Normalbetrieb, sondern in dem Moment, in dem etwas passiert.

Der wirtschaftlich relevante Hebel ist dabei nicht das Bußgeld. Das [Arbeitsschutzgesetz](https://www.gesetze-im-internet.de/arbschg/__25.html) sieht bei Zuwiderhandlung gegen eine vollziehbare Anordnung eine Geldbuße bis 30.000 Euro vor (Paragraph 25, Stand: Mai 2026). Schwerer wiegt der persönliche Regress: Wer einen Arbeitsunfall grob fahrlässig herbeiführt - etwa durch eine versäumte, nicht dokumentierte Pflichtunterweisung -, haftet der Unfallversicherung für alle Aufwendungen aus dem Unfall, bis zur Höhe des zivilrechtlichen Schadensersatzanspruchs ([Paragraph 110 SGB VII](https://www.gesetze-im-internet.de/sgb_7/__110.html)). Das Haftungsprivileg schützt hier nicht. Bei schweren Personenschäden wird daraus schnell eine sechs- bis siebenstellige Summe.

Das Tracking-Tool haftet nicht. Es haftet der Mensch, der den Einsatz freigegeben hat. Ein guter Agent sorgt deshalb für zweierlei: dass die Frist nie unbemerkt verstreicht und dass im Zweifel ein benannter Verantwortlicher mit Beleg entschieden hat.

## Was der Agent ohne Ermessen vollständig übernimmt

Der Agent übernimmt den deterministischen Teil des Zertifikats-Lebenszyklus vollständig. Aus der Gefährdungsbeurteilung und dem Tätigkeitsprofil leitet er ab, welche Befähigungsnachweise für eine Position Pflicht sind, berechnet aus Ausstellungsdatum und Gültigkeitsintervall das Ablaufdatum und löst gestaffelte Vorwarnungen aus - typisch 90, 60, 30 und 14 Tage vor Verfall. Das sind Regeln ohne Auslegung: Entweder der Nachweis ist gültig oder nicht, entweder die Frist ist erreicht oder nicht.

Dazu gehört die getrennte Behandlung zweier oft verwechselter Pflichten. Das [Arbeitsschutzgesetz](https://www.gesetze-im-internet.de/arbschg/__12.html) verlangt die Unterweisung bei Einstellung, Aufgabenwechsel und neuer Technologie sowie eine erforderlichenfalls regelmäßige Wiederholung (Paragraph 12). Die feste Jahresfrist mit Dokumentationspflicht stammt dagegen aus der [DGUV Vorschrift 1](https://www.bghm.de/arbeitsschuetzer/schriften-und-regelwerk/dguv-vorschriften/dguv-vorschrift-1/pflichten-des-unternehmers/4-unterweisung-der-versicherten) (Paragraph 4). Der Agent prüft beide getrennt und protokolliert jede Unterweisung revisionssicher (Stand: Mai 2026). Diese Präzision ist kein Detail, sondern die Grundlage des späteren Nachweises.

Die KI-Komponente bleibt schmal und klar abgegrenzt. Sie schlägt die drei besten Auffrischungstermine nach Vorlauf und Kapazität vor und markiert auffällige Importe - etwa einen per Texterkennung eingelesenen Teilnahmenachweis mit unplausiblem Datum. Solche Fälle kennzeichnet der Agent, er entscheidet sie nicht.

## Status-Wechsel und Einsatz-Stopp trifft immer ein Mensch, nie die KI

Den Statuswechsel eines Nachweises und den Einsatz-Stopp eines Mitarbeiters trifft immer ein Mensch. Diese Grenze ist bewusst gezogen: Wer jemanden aus einer sicherheitsrelevanten Tätigkeit nimmt, fällt eine arbeitsrechtliche Entscheidung mit Konsequenzen, und wer über die Verwertung eines Eignungsergebnisses entscheidet, berührt Gesundheitsdaten. Beides braucht einen verantwortlichen Menschen.

Der [Decision Layer](/de/decision-layer/) trennt sauber: Der Agent liefert die Entscheidungsvorlage - die berechnete Frist, den markierten Hinweis, die vorbereitete Eskalation -, der Mensch trifft die Entscheidung im Vier-Augen-Prinzip. Die KI darf nie autonom "gültig" oder "ungültig" setzen. So bleibt die Verantwortung dort, wo sie hingehört, und die Zeitersparnis entsteht trotzdem.

Diese Trennung löst zugleich zwei rechtliche Anforderungen. Sobald der Agent Schulungen vorschlägt oder Mitarbeiter priorisiert, greift die Mitbestimmung des Betriebsrats bei Maßnahmen der betrieblichen Berufsbildung ([Paragraph 98 BetrVG](https://www.gesetze-im-internet.de/betrvg/__98.html)). Und bei Eignungsdaten aus der arbeitsmedizinischen Vorsorge zieht der Agent eine rote Linie: Verarbeitet wird nur das Ergebnis "geeignet" oder "nicht geeignet" auf Basis von [Artikel 9 DSGVO](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX%3A32016R0679), die Diagnose bleibt beim Betriebsarzt unter Schweigepflicht.

## Juristische Präzision statt Blackbox: Gesetz und Unfallverhütungsvorschrift sauber getrennt

Marktübliche Lernmanagement- und HR-Plattformen verkaufen automatisiertes Compliance-Tracking als Blackbox: "Das System überwacht Ihre Zertifikate." Der Unterschied liegt darin, wer was entscheidet - und ob das prüfbar ist. Hier ist jede Mikroentscheidung als Regelwerk, KI-Indikator oder Mensch-Letztentscheid klassifiziert und im Decision-Log festgehalten. Das ist genau das Argument, das Betriebsrat und Rechtsabteilung brauchen: Die KI entscheidet nichts, sie schlägt vor; den Einsatz-Stopp entscheidet ein Mensch.

Der zweite Unterschied ist juristische Präzision statt Marketing. Wo Wettbewerber pauschal "jährliche Unterweisung nach Arbeitsschutzgesetz" behaupten, trennt der Agent Gesetz und Unfallverhütungsvorschrift korrekt und benennt den eigentlichen Hebel - den Haftungs-Regress, nicht das Bußgeld. Und er behandelt die Rechtslage als das, was sie ist: Seit Paragraph 26 Absatz 1 BDSG nach dem EuGH-Urteil C-34/21 vom 30.03.2023 unanwendbar ist - bestätigt durch das [Bundesarbeitsgericht](https://www.bundesarbeitsgericht.de/presse/schadenersatz-nach-datenschutz-grundverordnung-dsgvo-betriebsvereinbarung-workday/) (8 AZR 209/21) am 08.05.2025 -, stützt sich die Verarbeitung auf die allgemeinen Erlaubnistatbestände des [Artikel 6 DSGVO](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX%3A32016R0679), für Eignungsdaten auf Artikel 9 DSGVO; Artikel 88 DSGVO bleibt Öffnungsklausel, keine eigene Erlaubnisnorm. Ein Beschäftigtendatengesetz ist geplant, aber noch nicht in Kraft (Stand: Mai 2026, Basis: Koalitionsvertrag 2025 und Sofortprogramm 2026).

Das ist relevant, weil Weiterbildung kein Randthema ist: Gut 77 Prozent der deutschen Unternehmen boten 2020 Maßnahmen zur Qualifizierung ihrer Beschäftigten an ([Statistisches Bundesamt](https://www.destatis.de/DE/Presse/Pressemitteilungen/2022/08/PD22_349_215.html), Erhebungsjahr 2020). Wer in dieser Breite qualifiziert, muss die Nachweise auch belegen können.

## Was Sie brauchen, damit der Agent zuverlässig arbeitet

Der Agent ist nur so verlässlich wie seine Datengrundlage. Drei Dinge müssen stehen: eine aktuelle Gefährdungsbeurteilung, aus der sich die Pflichtnachweise je Position ableiten lassen; gepflegte Stammdaten mit eindeutiger Zuordnung von Mitarbeitern zu Positionen und Standorten; und eine Zuständigkeitsmatrix, die jeden sicherheitsrelevanten Einsatz-Stopp einem benannten Verantwortlichen zuordnet.

Hinzu kommt die organisatorische Voraussetzung: Weil der Agent Schulungen vorschlägt, gehört der KI-gestützte Teil in eine Betriebsvereinbarung oder zumindest in eine Abstimmung mit dem Betriebsrat. Sind diese Grundlagen vorhanden, beginnt der Agent ohne lange Einführungsphase zu arbeiten - er rechnet Fristen, nicht Wahrscheinlichkeiten.

## Wo der Agent im HR-Stack sitzt und wohin die Daten fließen

Der Agent sitzt als Schicht über Ihren bestehenden Systemen, nicht an ihrer Stelle. Er liest Stammdaten aus HR-Plattformen wie Personio oder SuccessFactors, zieht Teilnahmenachweise aus dem angebundenen Lernmanagement-System und legt dokumentierte Status revisionssicher in DATEV-Personalsystemen ab. Die führenden Systeme bleiben, was sie sind - der Agent ergänzt sie um die Prüf-, Fristen- und Dokumentationsschicht, die heute manuell in Tabellen läuft.

Damit wird aus verstreuten Erinnerungen und Excel-Listen ein kontrollierter, auditierbarer Prozess - einer, der bei der nächsten Begehung der Berufsgenossenschaft Bestand hat.

Der nächste Schritt ist keine Tool-Einführung, sondern eine Bestandsaufnahme: Welche Pflichtnachweise laufen heute über Tabellen - und wer entscheidet bei Überfälligkeit? Genau das - von der Bestimmung der Pflichtnachweise bis zur belegten Entscheidung beim Einsatz-Stopp - zeigt die folgende Prozess-Analyse.

## Auf einen Blick

- **Was er tut**: trackt Pflicht-Qualifikationen und Befähigungsnachweise mit deterministischer Fristen-Logik, löst gestaffelte Ablauf-Erinnerungen aus und protokolliert jeden Nachweis-Status revisionssicher
- **Klassifikation**: kein EU-AI-Act-Hochrisiko-System (Fristen regelbasiert, KI nur Vorschlag und Anomalie-Hinweis, kein autonomer Status-Wechsel)
- **Entscheidungslogik**: überwiegend Regelwerk, KI nur als Vorschlag, Status-Wechsel und Einsatz-Stopp beim Menschen im Vier-Augen-Prinzip
- **Compliance-Anker**: Unterweisung nach Paragraph 12 ArbSchG, Jahresfrist nach Paragraph 4 DGUV Vorschrift 1, Haftungs-Regress nach Paragraph 110 SGB VII, Betriebsrat nach Paragraph 98 BetrVG, Eignungsdaten nach Artikel 9 DSGVO
- **Integration**: Schicht über SuccessFactors, Personio, einem Lernmanagement-System und DATEV-Personalsystemen - kein Ersatz
- **Prüfungsfall**: jeder Nachweis mit lückenloser Historie bis zur belegten Letztentscheidung rückverfolgbar, bei einer Begehung der Berufsgenossenschaft direkt vorlegbar

--- Compensation-Benchmarking-Agent ---
> Pay-Equity-Benchmark mit Decision Layer: Regelwerk rechnet, KI liefert den Gap-Indikator, der Mensch entscheidet jedes Gehalt - belegbar vor Gericht.

## Jedes Tool rechnet den Gap. Keines beweist, wer das Gehalt verantwortet.

Mercer, WTW, Personio, beqom - jedes dieser Systeme berechnet Ihnen eine Gehaltsspanne und einen Gender Pay Gap und generiert einen Report. Das ist seit Jahren der Markt. Die Frage, an der eine Entgeltdiskriminierungs-Klage und ein Mitbestimmungs-Verfahren wirklich hängen, beantwortet keines dieser Dashboards: Wer hat diese eine Entgelt-Entscheidung verantwortet, auf welcher Rechtsgrundlage - und können Sie das einem Arbeitsgericht zeilengenau belegen?

Dieser Agent folgt dem [Decision Layer](/de/decision-layer/)-Prinzip: Jede Pay-Entscheidung ist entweder regelbasiert, ein KI-Indikator oder eine menschliche Letztentscheidung - klar getrennt und mit ihrer Rechtsgrundlage protokolliert. Nach [EU AI Act](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) ist er kein Hochrisiko-System, weil er kein Gehalt über einen Menschen entscheidet. Seine Anforderungen kommen aus dem Arbeits- und Datenschutzrecht, und die sind hart genug.

## Gehalts-Benchmarking: wo die Pay-Equity-Prüfung wirklich klemmt

Der Anlass ist messbar und politisch zugleich. Der unbereinigte [Gender Pay Gap in Deutschland lag 2024 bei 16 Prozent](https://www.destatis.de/DE/Presse/Pressemitteilungen/2025/02/PD25_056_621.html) - Frauen verdienten im Schnitt 22,24 Euro brutto je Stunde, Männer 26,34 Euro. Selbst bereinigt um Qualifikation, Tätigkeit und Erwerbsbiografie bleiben laut Destatis rund 6 Prozent unerklärt. Dieser bereinigte Rest ist genau der Bereich, in dem rechtliches Risiko entsteht - und er klemmt an drei Stellen:

- **Die Berechnung.** Den unerklärten Anteil eines Entgeltunterschieds sauber zu isolieren, verlangt eine multivariate Regression über Erfahrung, Funktion, Region und Leistung. Das ist Statistik, keine Excel-Pivot - und heute oft Handarbeit eines externen Beraters einmal im Jahr.
- **Die Auskunft.** Der individuelle Auskunftsanspruch nach [Paragraph 12 EntgTranspG](https://www.gesetze-im-internet.de/entgtranspg/__12.html) besteht in Betrieben mit in der Regel mehr als 200 Beschäftigten und entfällt, wenn die Vergleichsgruppe weniger als sechs Personen des anderen Geschlechts umfasst; die Auskunft ist nach [Paragraph 15 Abs. 3 EntgTranspG](https://www.gesetze-im-internet.de/entgtranspg/__15.html) binnen drei Monaten zu erteilen. Jede dieser Bedingungen ist eine Regel, die heute manuell geprüft wird.
- **Der Nachweis.** Die Dokumentation, wer welchen Gap wie bewertet hat, veraltet - bis ein Beschäftigter oder ein Gericht danach fragt.

Der Einsatz ist real: Legt eine beschäftigte Person Indizien für eine geschlechtsbedingte Benachteiligung dar, kehrt sich nach [Paragraph 22 AGG](https://www.gesetze-im-internet.de/agg/__22.html) die Beweislast um. Das Bundesarbeitsgericht hat 2023 bestätigt, dass ein höheres Gehalt eines männlichen Kollegen für gleiche Arbeit als Indiz genügt - Verhandlungsgeschick rechtfertigt die Lücke nicht ([BAG, Urteil vom 16. Februar 2023, 8 AZR 450/21](https://www.bundesarbeitsgericht.de/entscheidung/8-azr-450-21/)). Diese Klage ist keine Frage des Ob, sondern des Wann.

## Drei Quellen, klar getrennt: wer entscheidet was

Die meisten Anbieter sagen, ein Mensch bleibe "im Prozess", und kleben ein Compliance-Siegel daneben. Beides bleibt eine schwarze Box. Der Agent macht stattdessen für jede Entscheidung sichtbar, aus welcher von drei Quellen sie stammt:

| Quelle | Was sie entscheidet | Beispiel aus dem Pay Benchmarking |
|--------|---------------------|-----------------------------------|
| **Regelwerk (R)** | Alles Deterministische, kein Ermessen | Schwelle nach Paragraph 12 EntgTranspG, Median-Vergleichsentgelt, Mindestlohn-Prüfung |
| **KI-Indikator (A)** | Markiert Unerklärtes, entscheidet nie | unerklärter Rest-Gap aus der Regression, Vorschlag für eine Vergleichsgruppe |
| **Mensch (H)** | Letztentscheidung und Rechtsbeurteilung | konkrete Gehaltsanpassung, Rechtfertigung eines Gaps, Einigung mit dem Betriebsrat |

Der Agent ist also überwiegend ein deterministischer Auskunfts- und Prüfmotor, mit KI nur als Indikator an den Rändern und einem festen menschlichen Entscheidungs-Gate. Das ist die ehrliche Antwort auf den naheliegenden Einwand "darf eine KI über Gehalt entscheiden?" - und genau das, was [Art. 22 DSGVO](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32016R0679) verlangt. Wichtig dabei: Wer eine Anpassung freigibt, sieht jeden KI-Indikator als solchen markiert, mit Konfidenz und zugrunde liegenden Faktoren, bevor er entscheidet. Die menschliche Letztentscheidung greift damit auf den KI-Anteil, nicht an ihm vorbei. Wie diese Schicht architektonisch durchgreift, zeigt der [Decision Layer](/de/decision-layer/).

## Die Beweislast entsteht zur Laufzeit, nicht im Nachhinein

Ein Gap-Befund, der aus einem Modell ohne integrierten Nachweis kommt, ist im Streitfall wertlos: Er ist nicht reproduzierbar, und es ist nicht dokumentiert, welche Faktoren und Daten ihn erzeugt haben. Die Beweislastumkehr nach Paragraph 22 AGG verlangt aber genau das Gegenteil - den belastbaren Nachweis, dass nicht das Geschlecht einen Unterschied erklärt.

Deshalb trägt beim Agenten jede Entscheidung ihren Nachweis bei sich: die angewandte Regelversion oder der Indikator, die zugrunde liegenden Daten, die Begründung, der Zeitstempel und die Rechtsgrundlage - protokolliert und nicht nachträglich änderbar. Für eine Auskunft nach dem Entgelttransparenzgesetz ist belegt, dass die Vergleichsgruppe die Mindestgröße von sechs Personen nach [Paragraph 12 Abs. 3 EntgTranspG](https://www.gesetze-im-internet.de/entgtranspg/__12.html) erfüllte und der Median korrekt berechnet wurde. Für eine Pay-Equity-Prüfung ist dokumentiert, welche objektiven Faktoren in die Regression eingingen und welcher Mensch den Rest-Gap fachlich bewertet hat.

Der Hebel dahinter: Fehlt dieser Nachweis im Prozess, trägt der Arbeitgeber die Beweislast - und verliert sie, wenn er die objektiven Gründe nicht belegen kann (Stand: Mai 2026). Eine zur Laufzeit entstehende Dokumentation nimmt dieser Eskalation die Grundlage.

## Ehrlicher Umsetzungsstand statt Fristen-Marketing

Wettbewerber-Marketing suggeriert pauschal eine neue Pflicht "ab Juni 2026". Das hält einer juristischen Prüfung nicht stand. Korrekt ist: Die [EU-Entgelttransparenzrichtlinie 2023/970](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32023L0970) setzt die Umsetzungsfrist auf den 7. Juni 2026, doch die deutsche Umsetzung ist verspätet - ein Umsetzungsgesetz ist noch nicht in Kraft (Stand: Mai 2026). Bis dahin wenden Gerichte das bestehende Recht richtlinienkonform an; die gestaffelten Reporting-Pflichten greifen ab dem 7. Juni 2027, beginnend bei Organisationen ab 250 Beschäftigten.

Der Agent bildet genau diesen Stand ab. Er behauptet keine geltende Pflicht, die rechtlich noch nicht greift, sondern unterscheidet zwischen heute geltendem Recht (Entgelttransparenzgesetz, AGG, BetrVG, DSGVO) und künftigen Stichtagen, die er als geplant kennzeichnet. Diese Präzision ist der Vertrauens-Hebel: Wer vor dem Betriebsrat und dem Vorstand besteht, kann sich keine Marketing-Behauptung leisten, die einer Prüfung nicht standhält.

## Über Mercer und SAP, nicht statt ihnen

Der Agent konkurriert nicht mit Ihrem Compensation-System. Gegen die etablierten Marktdaten- und HCM-Anbieter auf deren Achse anzutreten wäre aussichtslos - dort entscheiden Datentiefe und Integration. Der Agent legt sich als Entscheidungs- und Nachweis-Schicht darüber: Job-Architektur und Vergütungsdaten bleiben in SAP SuccessFactors, Workday oder Personio, die Marktdaten kommen weiter von Mercer oder WTW, und er macht die Pay-Entscheidungen darüber prüfbar.

Was hinzukommt, ist nicht ein weiteres Dashboard, sondern die Antwort auf die Frage, an der die Mitbestimmung und die Beweislast hängen: Für jede Entscheidung lässt sich sagen, wer sie verantwortet hat, und es ist mit Rechtsgrundlage belegt. Das ist die Aussage, die ein Betriebsrat unterschreiben kann, bevor sie dem Vorstand präsentiert wird.

Der nächste Schritt ist keine Software-Einführung, sondern eine Bestandsaufnahme: Wo in Ihrem Vergütungsprozess sitzt heute die manuelle Pay-Equity-Prüfung, und wie belastbar ist die Dokumentation dahinter, wenn morgen eine Auskunft oder eine Klage kommt?

## Auf einen Blick

- **Was er tut**: liefert deterministische Pay-Auskünfte und einen statistischen Gap-Indikator und protokolliert jede Pay-Entscheidung mit ihrer Rechtsgrundlage
- **Klassifikation**: kein EU-AI-Act-Hochrisiko-System (entscheidet kein Gehalt, unterstützt die Prüfung)
- **Entscheidungslogik**: überwiegend Regelwerk, KI nur als Indikator, Letztentscheidung beim Menschen (Art. 22 DSGVO)
- **Compliance-Anker**: Auskunftsanspruch nach [Paragraph 12 EntgTranspG](https://www.gesetze-im-internet.de/entgtranspg/__12.html), Beweislast nach [Paragraph 22 AGG](https://www.gesetze-im-internet.de/agg/__22.html), Mitbestimmung nach [Paragraph 87 BetrVG](https://www.gesetze-im-internet.de/betrvg/__87.html), EU-Richtlinie 2023/970 (Stand: Mai 2026)
- **Integration**: Schicht über SAP SuccessFactors, Workday, Personio sowie Mercer- und WTW-Marktdaten - kein Ersatz
- **Streitfall**: jede Auskunft und jeder Gap-Befund bis zu Faktoren und Rechtsgrundlage rückverfolgbar

<!-- Quellen (alle live geprüft, Stand: Mai 2026)
Gender Pay Gap 2024 (16 %, 22,24 €/26,34 €, 6 % bereinigt): https://www.destatis.de/DE/Presse/Pressemitteilungen/2025/02/PD25_056_621.html
§11 EntgTranspG (Median-Vergleichsentgelt): https://www.gesetze-im-internet.de/entgtranspg/__11.html
§12 EntgTranspG (200-Schwelle, Vergleichstätigkeit ab sechs Beschäftigten): https://www.gesetze-im-internet.de/entgtranspg/__12.html
§15 Abs. 3 EntgTranspG (Antwortfrist drei Monate): https://www.gesetze-im-internet.de/entgtranspg/__15.html
§22 AGG (Beweislast): https://www.gesetze-im-internet.de/agg/__22.html
§87 Abs. 1 Nr. 10 und Nr. 11 BetrVG (Mitbestimmung Lohngestaltung): https://www.gesetze-im-internet.de/betrvg/__87.html
DSGVO Art. 22, 35, 88 (CELEX 32016R0679): https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32016R0679
EU-Richtlinie 2023/970 (Umsetzung bis 7.6.2026, Reporting ab 250 Beschäftigten zum 7.6.2027): https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32023L0970
BAG 8 AZR 450/21, Urteil vom 16.02.2023: https://www.bundesarbeitsgericht.de/entscheidung/8-azr-450-21/
Mindestlohn 13,90 € (ab 1.1.2026, 14,60 € ab 1.1.2027), BMAS: https://www.bmas.de/DE/Service/Presse/Pressemitteilungen/2025/mindestlohn-steigt-zum-ersten-januar-2026.html
-->

--- Compliance-Monitoring-Agent ---
> HR-Compliance-Monitoring mit prüfbarer Zuständigkeit: das Regelwerk prüft, die KI liefert Indikatoren, der Mensch bewertet und eskaliert.

## HR-Compliance scheitert nicht an der Überwachung, sondern an der nachweisbaren Zuständigkeit

Die kontinuierliche Überwachung von Personaldaten und Personalalgorithmen ist technisch gelöst. Eine GRC-Plattform liefert dazu Scores und Dashboards im Minutentakt - was sie im Ernstfall nicht liefert, ist der Beleg, wer eine konkrete Bewertung verantwortet hat und ob eine Maschine sie allein getroffen hat. Genau dieser Nachweis, nicht die Menge der Kontrollen, entscheidet, ob ein Befund vor dem Betriebsrat und vor dem Bundesarbeitsgericht standhält.

Die [Datenschutz-Grundverordnung](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32016R0679) zieht in Artikel 22 die rechtliche Grenze: Eine Entscheidung mit rechtlicher oder ähnlich erheblicher Wirkung gegenüber einer Person darf nicht ausschliesslich auf automatisierter Verarbeitung beruhen, es braucht ein Recht auf menschliches Eingreifen. Ein Verstoss kann nach Artikel 83 mit einem Bussgeld bis zu 20 Millionen Euro oder 4 Prozent des weltweiten Konzern-Jahresumsatzes geahndet werden, je nachdem, welcher Betrag höher ist (Stand: Mai 2026). Ein Compliance-Monitoring-Agent macht deshalb nicht die Überwachung zum Produkt, sondern die prüfbare Entscheidungs-Zuständigkeit für jede einzelne Prüfung.

## Das Regelwerk prüft, die KI liefert Indikatoren, der Mensch bewertet

Drei Arten von Entscheidungen laufen in jeder HR-Compliance-Prüfung zusammen, und sie dürfen nicht vermischt werden. Die erste ist deterministisch: Welche Norm zu welchem Stichtag in welcher Fassung gilt, ob ein Verzeichnis der Verarbeitungstätigkeiten vollständig ist und ob eine technische Einrichtung den Mitbestimmungstatbestand auslöst, folgt festen Regeln. Das übernimmt das [Decision Layer](/de/decision-layer/) als Regelwerk, abgekürzt R.

Die zweite Art ist statistisch. Ob eine Auswahlquote im Recruiting auf eine mögliche mittelbare Benachteiligung hindeutet oder ob nach Bereinigung um sachliche Faktoren ein auffälliger Entgeltunterschied bleibt, ist ein Indikator, kein Urteil. Die KI meldet ein Muster, abgekürzt A, und entscheidet bewusst nichts über einzelne Beschäftigte. Das ist die unmittelbare Konsequenz aus Artikel 22: Ein Algorithmus, der eine geschützte Person betrifft, darf einen Hinweis liefern, aber keine Feststellung treffen.

Die dritte Art bleibt beim Menschen, abgekürzt H. Ob ein Indikator nach Paragraph 22 AGG sachlich gerechtfertigt ist, ob ein Befund bestandsgefährdend ist und ob er an Geschäftsführung oder Aufsichtsgremium eskaliert wird, ist ein rechtliches Werturteil. Diese Trennung ist nicht kosmetisch - sie ist die juristische Begründung dafür, dass der Agent überhaupt eingesetzt werden darf.

## Warum statistisches Monitoring erst durch die Beweislast-Umkehr wertvoll wird

Der eigentliche Geschäftswert kontinuierlicher Überwachung entsteht an Paragraph 22 des [Allgemeinen Gleichbehandlungsgesetzes](https://www.gesetze-im-internet.de/agg/__22.html). Sobald eine Person Indizien beweist, die eine Benachteiligung wegen eines geschützten Merkmals vermuten lassen, trägt der Arbeitgeber die Beweislast, dass keine Diskriminierung vorlag. Die Entschädigung bei einer Nichteinstellung ist nur dann auf drei Monatsgehälter gedeckelt, wenn die Person auch bei benachteiligungsfreier Auswahl nicht eingestellt worden wäre ([Paragraph 15 AGG](https://www.gesetze-im-internet.de/agg/__15.html)); andernfalls ist sie ungedeckelt, und der Anspruch ist binnen zwei Monaten schriftlich geltend zu machen (Stand: Mai 2026).

Damit wird klar, warum ein Audit-Trail kein Nebenprodukt ist, sondern das Kerngut. Wer im Streitfall belegen muss, dass eine Auswahl sachlich und benachteiligungsfrei war, braucht eine fortlaufende, prüfbare Dokumentation - keine nachträglich zusammengesuchte Tabelle. Dass der Beratungsbedarf real steigt, zeigt die offizielle Statistik der [Antidiskriminierungsstelle des Bundes](https://www.antidiskriminierungsstelle.de/SharedDocs/pressemitteilungen/DE/2025/20250603_Jahresbericht.html): 2024 gingen dort 11.405 Beratungsanfragen zu Diskriminierung ein, mehr als jemals zuvor in einem Jahr und seit 2019 (damals 4.247) mehr als verdoppelt; rund ein Drittel der Fälle betrifft die Arbeitssuche, das Bewerbungsgespräch, den Arbeitsplatz oder das Ausscheiden aus dem Arbeitsverhältnis (Stand: Mai 2026). Genau diese Dokumentation produziert der Agent fortlaufend, sodass sie vor Gericht zum Asset wird statt zum Risiko.

## Die korrekte Rechtsgrundlage ist heute eine andere als noch vor drei Jahren

Eine belastbare Compliance-Aussage hängt an der richtigen Rechtsgrundlage - und die hat sich verschoben. Der Europäische Gerichtshof hat mit [Urteil vom 30. März 2023](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:62021CJ0034) entschieden, dass eine nationale Vorschrift keine spezifischere Regelung im Sinne der Öffnungsklausel des Artikels 88 der Datenschutz-Grundverordnung ist, wenn sie deren besondere Schutzanforderungen nicht erfüllt. Damit ist die zentrale Generalklausel des Beschäftigtendatenschutzes in Paragraph 26 Absatz 1 des Bundesdatenschutzgesetzes als alleinige Stütze nicht mehr tragfähig.

Für die Praxis heisst das: Die Verarbeitung von Beschäftigtendaten lässt sich nicht mehr pauschal auf diese Generalklausel stützen, sondern muss direkt auf eine Stütze der Datenschutz-Grundverordnung gestellt werden. Ein angekündigtes Beschäftigtendatengesetz liegt zwar als Entwurf vor, ist aber derzeit nicht in Kraft, sodass für jeden Datenfluss die unmittelbare Rechtsgrundlage geprüft werden muss (geplant, Stand: Mai 2026, Basis: vorliegender Referentenentwurf ohne Inkrafttreten). Ein Agent, der diese Korrektur nicht abbildet und weiter gegen eine überholte Norm prüft, erzeugt eine trügerische Sicherheit - die kontinuierliche Pflege des Pflichtenkatalogs ist deshalb kein Komfort, sondern die Voraussetzung dafür, dass die Prüfung überhaupt richtig ist.

## Das Tool selbst ist mitbestimmungspflichtig - und genau darin liegt sein Argument

Ein Compliance-Monitoring-Agent ist per Definition eine technische Einrichtung, die Verhalten und Leistung von Beschäftigten berührt, und unterliegt damit nach Paragraph 87 Absatz 1 Nummer 6 des [Betriebsverfassungsgesetzes](https://www.gesetze-im-internet.de/betrvg/__87.html) der zwingenden Mitbestimmung des Betriebsrats. Wird er ohne Betriebsvereinbarung eingeführt, drohen ein Unterlassungsanspruch, ein Beweisverwertungsverbot der gewonnenen Daten und faktisch ein Einführungsstopp bis zur Einigung, notfalls über die Einigungsstelle (Stand: Mai 2026).

Was zunächst wie eine Hürde wirkt, ist in Wahrheit der stärkste Hebel. Eine Lösung, die der Betriebsrat unterschreibt, bevor sie dem Vorstand präsentiert wird, lebt davon, dass jede Prüfung ihre Zuständigkeit offenlegt: Regelwerk, KI-Indikator oder Mensch, jeweils mit Normzitat und Anfechtungspfad. Genau diese Transparenz nimmt dem Gremium die Unsicherheit, aus der heraus es sonst blockiert - der Agent ist damit nicht das Problem in der Mitbestimmung, sondern dessen Lösung.

## Der Agent überwacht die Hochrisiko-Systeme, ohne selbst eines zu sein

Recruiting, Leistungsbewertung, Beförderung, Kündigung und Aufgabenzuweisung gelten nach Anhang III Nummer 4 der [Verordnung 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) als Hochrisiko-KI und unterliegen Pflichten zu Risikomanagement, Datenqualität, Transparenz, menschlicher Aufsicht und Robustheit. Pflichtverletzungen bei Hochrisiko-Systemen können nach [Artikel 99](https://artificialintelligenceact.eu/article/99/) mit bis zu 15 Millionen Euro oder 3 Prozent des weltweiten Jahresumsatzes geahndet werden; die höheren 35 Millionen Euro beziehungsweise 7 Prozent gelten ausschliesslich für verbotene Praktiken nach Artikel 5, nicht für Hochrisiko-Pflichten (Stand: Mai 2026).

Der Agent selbst trifft keine Endentscheidung und ist deshalb kein Hochrisiko-System - aber er überwacht die Personalsysteme, die es sind. Der reguläre Anwendungsbeginn der Hochrisiko-Pflichten für eigenständige Systeme nach Anhang III ist der 2. August 2026 und bleibt rechtlich verbindlich. Eine [vorläufige politische Einigung vom 7. Mai 2026](https://www.consilium.europa.eu/en/press/press-releases/2026/05/07/artificial-intelligence-council-and-parliament-agree-to-simplify-and-streamline-rules/) würde diese Pflichten auf den 2. Dezember 2027 verschieben (erwartet, Stand: Mai 2026, Basis: Trilog-Einigung zum Digital Omnibus, noch nicht im Amtsblatt veröffentlicht). Solange keine Veröffentlichung erfolgt, gilt der frühere Termin, und Unternehmen müssen beide Szenarien abdecken. Genau hier zahlt sich kontinuierliches statt jährliches Monitoring aus: Bei einer Frist im Fluss muss man jederzeit wissen, was an einem bestimmten Tag gilt - und das liefert nur ein gepflegtes Regelwerk, kein Audit, der ein Jahr alt ist.

Der nächste Schritt ist keine Tool-Einführung, sondern eine Bestandsaufnahme: An welcher Compliance-Prüfung in Ihrem Personalbereich lässt sich heute lückenlos belegen, wer sie verantwortet hat - das Regelwerk, ein statistischer Indikator oder ein Mensch? Dort, wo diese Antwort heute fehlt, sitzt das Risiko, das ein Compliance-Monitoring-Agent schliesst.

## Auf einen Blick

- **Was er tut**: prüft HR-Daten und HR-Algorithmen kontinuierlich gegen das geltende Regelwerk und dokumentiert für jede Prüfung nachweisbar, wer sie verantwortet
- **Klassifikation**: selbst kein EU-AI-Act-Hochrisiko-System (keine automatisierte Personalentscheidung nach Artikel 22 DSGVO), überwacht aber die Hochrisiko-Systeme nach Anhang III der Verordnung 2024/1689
- **Entscheidungslogik**: Regelwerk prüft (R), KI liefert statistische Indikatoren (A), Mensch bewertet und eskaliert (H) - getrennt und protokolliert
- **Compliance-Anker**: Artikel 22 DSGVO, Beweislast-Umkehr nach Paragraph 22 AGG, Mitbestimmung nach Paragraph 87 Absatz 1 Nummer 6 BetrVG, Paragraph 26 BDSG nach EuGH-Urteil vom 30. März 2023 nicht mehr als alleinige Stütze tragfähig
- **Integration**: Entscheidungs-Schicht über SAP GRC, Workday oder ServiceNow IRM - kein Ersatz für die GRC-Plattform
- **Stichtag im Blick**: Hochrisiko-Pflichten regulär ab 2. August 2026, mögliche Verschiebung auf 2. Dezember 2027 (Digital Omnibus, noch nicht im Amtsblatt) - beide Szenarien werden tagesaktuell abgedeckt

--- Compliance-Training-Agent ---
> Pflicht-Schulungen zuweisen, fristgerecht durchführen, Nachweis revisionssicher ablegen - regelbasiert, KI nur als Vorschlag, Freigabe beim Menschen.

## Pflicht-Schulungen tracken kann jeder. Den Nachweis führen, der haftet, nicht.

Jede Schulungsplattform zeigt, wer welches Modul abgeschlossen hat - ein Fortschrittsbalken pro Mitarbeiter, ein Dashboard mit Abschlussquoten. Das ist seit Jahren Standard. Die Frage, an der eine AGG-Klage, eine Arbeitsschutz-Prüfung und ein CMS-Audit wirklich hängen, beantwortet keines dieser Systeme: War diese Person für diese Pflicht überhaupt fällig, zu welchem Stichtag, nach welcher Regel - und wer hat das entschieden?

Der Agent folgt dem [Decision Layer](/de/decision-layer/)-Prinzip: Jede Schulungs-Zuweisung ist entweder regelbasiert, ein KI-Vorschlag oder eine menschliche Freigabe - klar getrennt und revisionssicher belegt. Nach [EU AI Act](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) ist er kein Hochrisiko-System, weil er keine Menschen bewertet. Seine Anforderungen kommen aus dem Arbeits-, Gleichbehandlungs- und Compliance-Recht, und die sind hart genug.

## Bei vier Rahmen ist der Nachweis selbst der Vermögenswert

Es geht nicht darum, dass es viele Gesetze gibt. Es geht darum, dass bei einigen Rahmen der dokumentierte Schulungs-Nachweis über die Haftung entscheidet - nicht das blosse Durchführen der Schulung.

Am schärfsten zeigt das das Gleichbehandlungsrecht. Nach [Paragraph 12 Abs. 2 AGG](https://www.gesetze-im-internet.de/agg/__12.html) gilt eine nachweislich durchgeführte Schulung gesetzlich als Erfüllung der Pflicht, vor Benachteiligung zu schützen - ein echter Haftungs-Schutzschild. Die Kehrseite steht in [Paragraph 22 AGG](https://www.gesetze-im-internet.de/agg/__22.html): Ohne dokumentierten Nachweis kippt die Beweislast zum Arbeitgeber, sobald ein Beschäftigter Diskriminierungs-Indizien vorträgt. Ohne Schulungsnachweis ist dieser Gegenbeweis praktisch nicht zu führen; bei einem abgelehnten Bewerber, der auch ohne Benachteiligung nicht eingestellt worden wäre, deckelt [Paragraph 15 Abs. 2 AGG](https://www.gesetze-im-internet.de/agg/__15.html) die Entschädigung auf drei Monatsgehälter, in den übrigen Fällen bemisst sie das Gericht ohne diese Obergrenze (Stand: Mai 2026).

Im Arbeitsschutz verlangt [Paragraph 12 ArbSchG](https://www.gesetze-im-internet.de/arbschg/__12.html) eine Unterweisung vor Aufnahme der Tätigkeit und danach regelmässig wiederholt - nach [DGUV Vorschrift 1](https://publikationen.dguv.de/regelwerk/publikationen-nach-fachbereich/verwaltung/buerobereich/925/dguv-vorschrift-1-grundsaetze-der-praevention) Paragraph 4 mindestens einmal jährlich und dokumentationspflichtig. Verstöße kosten nach [Paragraph 25 ArbSchG](https://www.gesetze-im-internet.de/arbschg/__25.html) bis zu 30.000 Euro (Stand: Mai 2026). Wichtig für die Praxis: Die rein jährliche Unterweisung gilt nach der überarbeiteten DGUV-Regel nicht mehr als ausreichend, sie muss zusätzlich anlass- und tätigkeitsbezogen sein - genau das Frist- und Trigger-Problem, das hier gelöst wird.

Neu und seit 2025 scharf ist die KI-Kompetenz-Pflicht. Artikel 4 EU AI Act verlangt seit dem 2.2.2025, dass Betreiber von KI-Systemen ein ausreichendes Mass an KI-Kompetenz ihres Personals sicherstellen - risikoklassen-unabhängig, also für praktisch jedes Unternehmen, das KI einsetzt. Das ist eine Bemühenspflicht: Das Unternehmen muss nachweisen können, dass es angemessene Massnahmen getroffen hat. Dieser Nachweis ist das Produkt des Agenten. Und die Lücke ist real - nur jedes fünfte Unternehmen schult laut [Bitkom](https://www.bitkom.org/sites/main/files/2026-02/bitkom-studienbericht-ki.pdf) einen Grossteil seiner Belegschaft zu KI, 43 Prozent haben kein Angebot (Bitkom Research, KI-Studie 2025, 604 Unternehmen). Aus Sicht der Beschäftigten erhielten [70 Prozent](https://www.bitkom.org/Presse/Presseinformation/Ein-Fuenftel-im-Job-zu-KI-geschult) gar kein Schulungsangebot (Bitkom, 1.005 Befragte, 2025).

Im Geldwäsche-Recht ist die laufende Mitarbeiter-Unterrichtung nach [Paragraph 6 Abs. 2 Nr. 6 GwG](https://www.gesetze-im-internet.de/gwg_2017/__6.html) ausdrückliche gesetzliche Sicherungsmassnahme, keine Kür; Verstöße kosten nach [Paragraph 56 GwG](https://www.gesetze-im-internet.de/gwg_2017/__56.html) je nach Schwere bis 150.000 Euro, 1 Mio. Euro oder im Finanzsektor bis 5 Mio. Euro (Stand: Mai 2026). Und die interne Meldestelle nach Hinweisgeberschutzgesetz braucht nach [Paragraph 15 Abs. 2 HinSchG](https://www.gesetze-im-internet.de/hinschg/__15.html) die notwendige Fachkunde, die in der Praxis über Schulung hergestellt und nachgehalten wird.

## Drei Quellen, klar getrennt: wer weist die Schulung zu

Die meisten Anbieter sagen, ein Mensch bleibe "im Prozess", und kleben ein Compliance-Siegel daneben. Beides bleibt eine schwarze Box. Der Agent macht stattdessen für jede Schulungs-Zuweisung sichtbar, aus welcher von drei Quellen die Entscheidung stammt:

| Quelle | Was sie entscheidet | Beispiel aus der Schulungs-Steuerung |
|--------|---------------------|--------------------------------------|
| **Regelwerk (R)** | Alles Deterministische, kein Ermessen | Welche Pflicht-Schulung für wen gilt, Fälligkeit und Frist, Bestehensgrenze, Nachweis |
| **KI-Vorschlag (A)** | Markiert Auffälliges, entscheidet nie | Re-Schulungs-Vorschlag nach einem gemeldeten Vorfall |
| **Mensch (H)** | Freigabe und rechtliche Beurteilung | Freigabe einer Re-Schulungs-Welle, disziplinarische Konsequenz, strittige Reichweite einer Pflicht |

Der Agent ist also zu rund neunzig Prozent ein deterministischer Pflichten-Motor, mit KI nur als Vorschlag an einer einzigen Stelle und einem festen menschlichen Freigabe-Gate. Das ist kein Mangel, sondern das Verkaufsargument: Pflicht-Schulungen sind deterministisch - wer was bis wann braucht, folgt aus Position, Bereich und Gesetz, nicht aus einem KI-Urteil. Genau diese Leine macht den Agenten anschlussfähig. Wo Wettbewerber "KI-gestützte Compliance" als Buzzword führen, ist hier explizit, dass die KI nur Re-Schulungen vorschlägt und ein benannter Mensch sie freigibt. Das ist exakt, was ein Betriebsrat nach [Paragraph 87 Abs. 1 Nr. 6 BetrVG](https://www.gesetze-im-internet.de/betrvg/__87.html) und ein Datenschutzbeauftragter nach [Artikel 22 DSGVO](https://dsgvo-gesetz.de/art-22-dsgvo/) unterschreiben können - eine Lösung, die der Betriebsrat trägt, bevor sie dem Vorstand vorgelegt wird. Wie diese Schicht architektonisch durchgreift, zeigt der [Decision Layer](/de/decision-layer/).

## Der Nachweis entsteht append-only, nicht als nachträgliches Schriftstück

Ein Schulungs-Dashboard mit hundert Prozent Abschlussquote beweist nichts, wenn der falsche Personenkreis geschult wurde. Standard-Suiten verkaufen Completion-Rates - der Agent verkauft den regelbasierten Pfad von Norm und Position zur konkreten Fälligkeit mit Frist.

Deshalb trägt beim Agenten jede Schulungs-Zuweisung ihren Nachweis bei sich: Quelle, Eingabe, Begründung, Zeitstempel und die angewandte Regelversion - append-only, nicht nachträglich änderbar. Die Fälligkeits-Dokumentation wächst mit jeder Zuweisung mit, statt als separates Schriftstück gepflegt zu werden. Für eine Prüfung lässt sich jede Stichprobe von der Person über die Fälligkeit bis zur zugrunde liegenden Norm zurückverfolgen. Das ist der Unterschied zwischen einem Kursvideo mit Fortschrittsbalken und einem prüfbaren Entscheidungsweg.

## KI mit Leine: ein Schritt, sichtbar begrenzt

Genau eine Stelle im Prozess ist KI-gestützt, und sie ist bewusst eng gehalten. Wenn ein vorgelagerter Monitoring-Prozess ein Signal liefert - eine Diskriminierungs-Beschwerde, eine Datenpanne, eine Whistleblower-Meldung oder ein Arbeitsunfall -, korreliert das Modell den Vorfall gegen den Schulungskatalog und schlägt eine Re-Schulung vor. Dieser Vorschlag ist ein Indikator, nie eine Endentscheidung.

Bevor eine Re-Schulungs-Welle läuft, validiert ein benannter Compliance-Officer, CHRO oder Datenschutzbeauftragter den Trigger. Eine disziplinarische Konsequenz bei wiederholter Schulungs-Verweigerung entscheidet ebenfalls immer der Mensch. Damit greift [Artikel 22 DSGVO](https://dsgvo-gesetz.de/art-22-dsgvo/) - keine automatisierte Einzelentscheidung - nicht als nachträgliche Beteuerung, sondern als strukturelle Eigenschaft des Systems. Die KI darf zuarbeiten; entscheiden darf sie nicht.

## Eine Schicht über dem LMS, nicht statt seiner

Der Agent konkurriert nicht mit Ihrer Schulungsplattform. Gegen SAP SuccessFactors, Cornerstone oder Personio auf der Modul- und Tracking-Achse anzutreten wäre aussichtslos - dort entscheidet Inhaltsbreite und Integration. Der Agent legt sich als Entscheidungs- und Nachweis-Schicht darüber: Module und Abschluss-Daten bleiben in Ihrem System, und er ergänzt den regelbasierten Fälligkeits-Pfad und den prüfbaren Entscheidungsweg.

Was hinzukommt, ist nicht ein weiteres Schulungs-System, sondern die Antwort auf die Prüfer-Frage: Für jede Zuweisung lässt sich sagen, wer sie nach welcher Regel verantwortet hat, und es ist revisionssicher belegt. Auch der Druck aus dem Lieferketten-Recht, früher ein gern genanntes Argument, ist als Schulungstreiber heute weitgehend entfallen - das BAFA hat die Prüfung der LkSG-Berichte zum 3.9.2025 eingestellt, und die EU-Lieferketten-Richtlinie ist durch das Omnibus-Paket verschoben: Die Mitgliedstaaten setzen sie erst bis zum 26.7.2028 um, die Anwendung beginnt einheitlich zum 26.7.2029, und der Anwendungsbereich ist deutlich verengt (Stand: Mai 2026, [Änderungsrichtlinie (EU) 2026/470](https://eur-lex.europa.eu/eli/dir/2026/470/oj/eng), ABl. 26.2.2026). Die tragenden Frames sind und bleiben AGG, Arbeitsschutz, KI-Kompetenz und Geldwäsche.

Der nächste Schritt ist keine Software-Einführung, sondern eine Bestandsaufnahme: Wo in Ihrem Schulungs-Prozess wird heute belegt, dass der richtige Personenkreis fällig war - und wie prüfungsfest ist die Dokumentation dahinter?

## Auf einen Blick

- **Was er tut**: weist Pflicht-Schulungen nach festen Regeln zu, berechnet Fristen und legt jeden Nachweis revisionssicher ab
- **Klassifikation**: kein EU-AI-Act-Hochrisiko-System (regelbasiert, keine Bewertung von Menschen)
- **Entscheidungslogik**: überwiegend Regelwerk, KI nur als Re-Schulungs-Vorschlag, Freigabe beim Menschen
- **Compliance-Anker**: Paragraph 12 Abs. 2 AGG, Paragraph 12 ArbSchG, EU AI Act Artikel 4, Paragraph 6 Abs. 2 Nr. 6 GwG, Paragraph 15 Abs. 2 HinSchG (Stand: Mai 2026)
- **Integration**: Schicht über SAP SuccessFactors, Cornerstone, Personio oder EQS - kein Ersatz
- **Prüfungsfall**: jede Zuweisung von der Person über die Fälligkeit bis zur Regel rückverfolgbar

--- Arbeitsvertrags- und Angebots-Agent ---
> KI-Agent für rechtssichere Arbeitsverträge und Angebote: prüft Form und Pflichtangaben nach deutschem Arbeitsrecht, bevor das Dokument rausgeht.

## Arbeitsverträge scheitern nicht an der Vorlage, sondern an der Form

Ein Arbeitsvertrag ist in wenigen Minuten generiert. Teuer wird er erst, wenn die Befristungsabrede an der Schriftform scheitert und das Arbeitsverhältnis dadurch unbefristet weiterläuft. Genau diese Form-Falle, nicht die Geschwindigkeit der Erstellung, entscheidet über das Haftungsrisiko in der Vertragsmappe.

Der Arbeitsvertrags- und Angebots-Agent setzt deshalb nicht bei der Erzeugung an, sondern bei der Prüfung: Er kontrolliert Form und Pflichtangaben, bevor das Dokument das Haus verlässt, und legt sich dafür über die bestehenden HR-Systeme, statt sie zu ersetzen. Der Hebel ist nicht die gesparte Minute, sondern das vermiedene Risiko - von der unwirksamen Befristung bis zum Bußgeld für fehlende Pflichtangaben, das sich über das Vertragsvolumen vervielfacht. Die folgenden Abschnitte zeigen, wo das zählt.

## Die Schriftform-Falle der Befristung ist das tragende Risiko

Das größte Risiko sitzt nicht im NachweisG, sondern in der Befristung selbst. Die Befristungsabrede bedarf nach [TzBfG Paragraph 14 Absatz 4](https://www.gesetze-im-internet.de/tzbfg/__14.html) der eigenhändigen Schriftform vor Arbeitsaufnahme. Eine eingescannte Unterschrift oder eine einfache E-Mail genügt nicht - nur eine qualifizierte elektronische Signatur ersetzt sie. Die Folge eines Formfehlers ist hart und einseitig zulasten des Arbeitgebers: Die Befristung ist unwirksam, und das Arbeitsverhältnis gilt nach [TzBfG Paragraph 16](https://www.gesetze-im-internet.de/tzbfg/__16.html) als auf unbestimmte Zeit geschlossen. Die betroffene Person kann das binnen drei Wochen ab vereinbartem Ende per Entfristungsklage geltend machen ([TzBfG Paragraph 17](https://www.gesetze-im-internet.de/tzbfg/__17.html)).

Dieses Risiko ist kein Einzelfall. 2024 waren 25 Prozent der sozialversicherungspflichtigen Neueinstellungen zunächst befristet ([IAB, Stand: 2024](https://doku.iab.de/arbeitsmarktdaten/Befristungen_bei_Neueinstellungen_2024.pdf)). Jeder vierte neue Vertrag läuft also durch die fehleranfällige Schriftform-Anforderung. Der Agent prüft sie als deterministische Regel, bevor das Dokument erzeugt wird: Steht keine eigenhändige Schriftform oder qualifizierte Signatur sicher, wird die Befristung gar nicht erst in Textform ausgegeben.

## NachweisG seit 2025: Textform erlaubt, die Pflichtangaben bleiben

Die verbreitete Annahme einer generellen Schriftform-Pflicht des NachweisG ist seit 2025 überholt. Mit dem Vierten Bürokratieentlastungsgesetz dürfen die wesentlichen Arbeitsbedingungen seit dem 1. Januar 2025 in Textform und damit elektronisch übermittelt werden. Was bleibt, sind die 15 Pflichtangaben nach [NachweisG Paragraph 2](https://www.gesetze-im-internet.de/nachwg/__2.html) mit gestaffelten Fristen - Kernangaben wie Entgelt und Arbeitszeit bereits am ersten Arbeitstag - sowie die Bußgeldandrohung von bis zu 2.000 Euro pro Verstoß nach [NachweisG Paragraph 4](https://www.gesetze-im-internet.de/nachwg/__4.html) (Stand: Mai 2026). Bei einem hohen Vertragsvolumen summiert sich das schnell.

Eine wichtige Ausnahme bleibt die Schriftform: In den schwarzarbeitsgefährdeten Branchen nach [Paragraph 2a Schwarzarbeitsbekämpfungsgesetz](https://www.gesetze-im-internet.de/schwarzarbg_2004/__2a.html) - Bau, Gastgewerbe, Gebäudereinigung und Fleischwirtschaft - gilt weiterhin die strengere Form. Der Agent führt den Pflichtkatalog als Checkliste, prüft die richtige Frist je Angabe und erkennt die Branchen-Ausnahme, bevor der Vertrag freigegeben wird.

## AGG-Screening: warum die diskriminierungsfreie Letztentscheidung beim Menschen bleibt

Stellenausschreibung und Vertragsklauseln müssen diskriminierungsfrei sein. Das AGG-Screening der Texte ist eine Aufgabe, die der Agent als KI-Indikator vorbereitet, aber nicht abschließend entscheidet. Das Sprachmodell markiert auffällige Formulierungen, die juristische Bewertung bleibt beim Justitiar. Dabei ist die oft als Headline genannte Obergrenze von drei Monatsgehältern nach [AGG Paragraph 15](https://www.gesetze-im-internet.de/agg/__15.html) irreführend: Sie greift nur für Bewerber, die auch ohne Diskriminierung nicht eingestellt worden wären - für alle anderen Konstellationen ist die Entschädigung nicht betragsmäßig gedeckelt. Geltend gemacht wird sie binnen zwei Monaten.

Diese Trennung von Vorschlag und Freigabe ist kein Komfort, sondern Pflicht. Eine rechtlich bindende Entscheidung darf nach [DSGVO Artikel 22](https://eur-lex.europa.eu/eli/reg/2016/679/oj) nicht ausschließlich automatisiert ergehen. Der [Decision Layer](/de/decision-layer/) macht genau diese Grenze sichtbar: welche Prüfung das Regelwerk übernimmt, welche der KI-Indikator vorbereitet und welche ein Mensch verantwortet.

## Was kommt: Gehaltsspanne im Recruiting und der deutsche Fristverzug

Die nächste Pflicht ist absehbar, der deutsche Zeitplan aber nicht eingehalten. Die [EU-Entgelttransparenzrichtlinie 2023/970](https://eur-lex.europa.eu/eli/dir/2023/970/oj) verlangt künftig die Angabe von Einstiegsentgelt oder Gehaltsspanne in der Ausschreibung und verbietet die Frage nach der Gehaltshistorie; die Berichtspflicht zum Gender-Pay-Gap ist nach Beschäftigtenzahl gestaffelt und greift ab 250 Beschäftigten ab dem 7. Juni 2027, ab 100 erst ab 2031. Die Umsetzungsfrist endet am 7. Juni 2026. Nach derzeitigem Stand (Stand: Mai 2026, Basis: Koalitionsvertrag 2025 sowie fehlender Referentenentwurf des federführenden BMBFSFJ) wird Deutschland diese Frist voraussichtlich reißen - mit der Folge unmittelbarer Wirkung gegenüber öffentlichen Arbeitgebern ab dem 8. Juni 2026.

Für den Agenten heißt das: Die Gehaltsspanne-Generierung ist heute schon als deterministische Regel hinterlegt, sodass die Ausschreibung der kommenden Pflicht entspricht, sobald sie greift. Auch der Mindestlohn ist als prüfbarer Schwellenwert geführt - 13,90 Euro pro Stunde ab dem 1. Januar 2026 und 14,60 Euro ab dem 1. Januar 2027 ([BMAS, Stand: Mai 2026](https://www.bmas.de/DE/Service/Presse/Pressemitteilungen/2025/mindestlohn-steigt-zum-ersten-januar-2026.html)). So bleibt der Vertrag konform, ohne dass jede Gesetzesänderung manuell in die Vorlagen eingepflegt werden muss.

## Der Decision Layer macht jede Vertragsentscheidung verteidigbar

Word-Vorlagen und Standard-HR-Suiten erzeugen Verträge, aber sie dokumentieren nicht, wer welche Entscheidung getroffen hat und ob sie prüfbar richtig war. Der Agent ordnet jede Entscheidung einem Typ zu: deterministische Regel, KI-Indikator oder menschliche Freigabe. Damit verkauft Gosign nicht die Geschwindigkeit der Erzeugung, sondern die Verteidigungsfähigkeit der Entscheidung.

Bei einer Befristungs- oder Diskriminierungsklage lässt sich so nachweisen, dass die Schriftform-Prüfung deterministisch lief, der Diskriminierungs-Check ein gegengezeichneter Indikator war und kein Vertrag voll automatisiert das Haus verließ. Das ist die eine Unterlage, die vor dem Betriebsrat besteht und die ein Vorstand sehen will, bevor er ein KI-gestütztes Verfahren in der Vertragsabwicklung freigibt.

## Nächster Schritt: die Prozesskette analysieren

Der Einsatz lässt sich beziffern: Bei einer Befristungsquote von 25 Prozent steht in jedem vierten neuen Vertrag die Schriftform-Falle, und jede fehlende Pflichtangabe kann mit bis zu 2.000 Euro geahndet werden - über ein Jahresvolumen an Einstellungen wird daraus eine Summe, die jede Prüfminute überschreitet.

Der Arbeitsvertrags-Agent entfaltet seinen Wert in der Kette mit vor- und nachgelagerten Prozessen, vom Onboarding bis zur Referenz. Eine Prozessanalyse zeigt, an welchen Stellen Form- und Pflichtangaben heute manuell geprüft werden, wo Fristen verrutschen und wo der Decision Layer als Prüfebene über den bestehenden Systemen ansetzt - die Grundlage für eine belastbare Entscheidung über den nächsten Automatisierungsschritt.

--- Employee-Data-Management-Agent ---
> Mitarbeiterdaten-Plattform: DSGVO Art. 5 Datenminimierung, Art. 17 Right-to-Erasure und BDSG §26 Beschäftigtendaten - Master-Data-Management mit Löschkonzept und BetrVG §87 Mitbestimmung.

Mitarbeiterdaten-Verwaltung in Deutschland steht zwischen vier Regelwerken, die jede Verarbeitung gleichzeitig erfassen können. Die DSGVO verlangt für Beschäftigtendaten eine dokumentierte Rechtsgrundlage, Datenminimierung, ein durchsetzbares Recht auf Löschung und die Meldung von Datenpannen binnen 72 Stunden - bewehrt mit bis zu 4 Prozent Konzernumsatz oder 20 Mio Euro (Art. 83 Abs. 5). Das BDSG §26 bindet die Verarbeitung an die Erforderlichkeit für das Beschäftigungsverhältnis. Das BetrVG §87 Abs. 1 Nr. 6 zwingt zur Mitbestimmung des Betriebsrats, sobald eine technische Einrichtung Verhalten oder Leistung überwachen kann. Und der EU AI Act stuft HR-KI-Systeme als Hochrisiko ein, mit Bußgeldern bis 35 Mio Euro oder 7 Prozent Konzernumsatz; die zugehörigen Pflichten greifen nach aktuellem Recht ab dem 2. August 2026, voraussichtlich verschoben auf den 2. Dezember 2027 (Digital Omnibus, Mai 2026). In einem mittelständischen oder Konzern-Umfeld kann ein einziger Stammdatensatz damit bis zu vier Compliance-Pflichten zugleich auslösen.

## Was Verstöße kosten: bis zu 7 Prozent Konzernumsatz, kumulativ

Die Sanktionen treffen kumulativ. Die DSGVO ahndet Verstöße gegen die Beschäftigtendaten-Pflichten mit bis zu 4 Prozent Konzernumsatz oder 20 Mio Euro (Art. 83 Abs. 5) - die Aufsichtsbehörden setzen das durch, etwa Hessen mit 9,55 Mio Euro gegen Vodafone (2024), Bayern mit 1,2 Mio Euro gegen Personio, Berlin mit 14,5 Mio Euro gegen Deutsche Wohnen (2019). Der EU AI Act geht für ein Hochrisiko-HR-System ohne Konformitätsbewertung bis 35 Mio Euro oder 7 Prozent Konzernumsatz. Einzelne Betroffene können nach EuGH C-579/21 immateriellen Schadensersatz nach Art. 82 verlangen, typisch 1.000 bis 5.000 Euro pro Person - bei einer Sammelklage summiert sich das. Ein Verstoß gegen die Mitbestimmung nach BetrVG §87 Abs. 1 Nr. 6 begründet zudem einen Unterlassungsanspruch des Betriebsrats und kann Personalmaßnahmen unwirksam machen. Hinzu kommt das stille Kostenrisiko der Inkonsistenz: Ein erheblicher Teil der Lohnabrechnungs-Fehler entsteht durch manuelle Dateneingabe - bei 1.000 Mitarbeitenden summiert sich der Schaden auf einen mittleren sechsstelligen Betrag pro Jahr. Die arbeitsgerichtliche Rechtsprechung 2024 bis 2026 konzentriert sich auf die Rechtmäßigkeit der Cloud-Personalakte (BAG vom 16.05.2024), Mitarbeiterüberwachung und das Recht auf Löschung nach Beendigung des Arbeitsverhältnisses.

## 13 regelbasierte Entscheidungen, ein KI-Indikator, eine menschliche Eskalation

Der Agent zerlegt die Mitarbeiterdaten-Verwaltung in 15 Micro-Entscheidungen. 13 davon laufen deterministisch nach Regelwerk, eine ist ein KI-Indikator, eine bleibt beim Menschen. Jede Entscheidung dokumentiert die Frage, ihre Einordnung (R für regelbasiert, A für KI-Indikator ohne Endentscheidung, H für menschliche Pflicht-Eskalation), die Begründung mit Rechtsgrundlage und Audit-Trail aus dem Quellsystem sowie einen Anfechtungs-Pfad. Regelbasiert sind unter anderem die Klassifikation der Datenherkunft mitsamt Rechtsgrundlage, Pseudonymisierung (Art. 25) und Verschlüsselung (Art. 32), das Recht auf Löschung mit Aufbewahrungsprüfung (Art. 17), die Cross-System-Synchronisation, die Pflege des Verzeichnisses der Verarbeitungstätigkeiten (Art. 30), die Auftragsverarbeitungs-Verträge (Art. 28), die Datenschutz-Folgenabschätzung (Art. 35), die Mitbestimmungsprüfung nach BetrVG §87 Abs. 1 Nr. 6, die Datenpannen-Meldung (Art. 33), die Personalakten-Einsicht (§83 BetrVG, Art. 15), die Trennung der Sondercategorien (Art. 9) und die Aufbewahrungsprüfung pro Datenkategorie. Der eine KI-Indikator ist das Daten-Minimierungs-Audit nach Art. 5 Abs. 1 lit. c: Das Modell markiert auffällige Felder, validiert wird von Datenschutzbeauftragtem, HR-Leitung und AGG-Beauftragtem. Die eine menschliche Entscheidung ist die Eskalation an den Prüfungsausschuss des Aufsichtsrats (§107 AktG), wenn ein Verstoß die Höhe einer Bestandsgefährdung erreichen kann.

## Laufender Abgleich mit Rechtsprechung und Aufsichtspraxis 2024-2026

Der Agent gleicht die Verarbeitung fortlaufend gegen die aktuelle Rechtsprechung und Aufsichtspraxis ab. Das BAG-Urteil vom 16.05.2024 zur Cloud-Personalakte setzt Maßstäbe für EU-Hosting und Schrems-II-Konformität; weitere Entscheidungen betreffen die Mitarbeiterüberwachung nach BetrVG §87 Abs. 1 Nr. 6 bei der Auswertung von Audit-Trails und Synchronisations-Logs. Der EuGH hat in C-579/21 den immateriellen Schadensersatz für Beschäftigte nach Art. 82 DSGVO bestätigt, typisch 1.000 bis 5.000 Euro pro Betroffenen. Die Bußgeldpraxis der Behörden - Hessen, Bayern, Berlin - zeigt klare Schwerpunkte bei Beschäftigtendaten, Cloud-HR und dem Recht auf Löschung nach Beendigung. Hinzu kommen die Hochrisiko-Pflichten des EU AI Act - nach aktuellem Recht ab dem 2. August 2026, voraussichtlich verschoben auf Dezember 2027 (Digital Omnibus, Mai 2026). Der Agent dokumentiert pro Schwerpunkt die Konformität und meldet Auffälligkeiten früh an den Prüfungsausschuss des Aufsichtsrats (§107 AktG), mit Stellungnahme des Datenschutzbeauftragten.

## Schwierige Fälle: Sondercategorien, Hinweisgeber, Cloud-Übertragung

Die komplexen Datenschutz-Szenarien sind eigens dokumentiert. Sondercategorien nach Art. 9 - etwa Daten der Schwerbehinderten-Vertretung - bleiben von Performance-Systemen getrennt und werden 10 Jahre nach Ablauf des Status aufbewahrt. Für die arbeitsmedizinische Vorsorge G37 gelten die Schweigepflicht des Betriebsarztes (§203 StGB), eine Aufbewahrung von 30 Jahren und strikte Datentrennung. Daten von Hinweisgebern werden höchstens 3 Jahre gespeichert (§11 HinSchG), unterliegen der Vertraulichkeitspflicht (§8) und dürfen nicht in Performance-Systeme synchronisiert werden. Eine Konzern- oder Gesamtbetriebsvereinbarung dient als Rechtsgrundlage nach Art. 88 DSGVO und BDSG §26 Abs. 4. Bei US-Anbietern wie SAP SuccessFactors, Workday oder Oracle HCM Cloud greifen EU-Hosting, Standardvertragsklauseln und ein Transfer-Impact-Assessment nach Schrems II. Hinzu kommen Sonderfälle: die Übernahme der Personalakte durch einen Insolvenzverwalter, die Datenübernahme bei einer M-und-A-Transaktion mit DSGVO-Due-Diligence und die Erfüllung behördlicher Auflagen mit Korrektur-Workflow und Wirksamkeitsnachweis.

## Integration mit HR-Plattformen, Privacy-Tools und Master-Data-Hubs

Der Agent bindet die führenden HR-Plattformen und Datenschutz-Werkzeuge über API an. Auf der HR-Seite sind das SAP (SuccessFactors, HCM, Master Data Governance, Information Lifecycle Management für das Löschkonzept), Workday, Personio, Oracle HCM Cloud sowie für den Mittelstand BambooHR, ADP, ServiceNow, Microsoft Dynamics 365 HR, Sage HR, P&I Loga und ATOSS - jeweils mit Löschungs-Workflows nach Art. 17, Pseudonymisierung und Audit-Trail. Für das Datenschutz-Management kommen spezialisierte Plattformen hinzu: OneTrust und BigID für Data-Discovery, das Verzeichnis der Verarbeitungstätigkeiten (Art. 30), die Datenschutz-Folgenabschätzung (Art. 35) und Auskunfts-Workflows, dazu Collibra, Informatica und IBM für die Master-Data-Governance sowie Concord und DocuSign CLM für die Auftragsverarbeitungs-Verträge nach Art. 28. Über die Systeme hinweg greifen der Mitbestimmungs-Workflow nach BetrVG §87 Abs. 1 Nr. 6, die Datenschutz-Folgenabschätzung für HR-KI-Systeme und die Eskalation an den Prüfungsausschuss des Aufsichtsrats (§107 AktG). Der Agent verbindet sich mit dem Contract-Offer-Generation-Agent, der nach Vertragsabschluss neue Stammdaten einspeist, sowie mit dem Audit-Compliance-Agent für HR-Audit-Berichte.

--- Employee-Relations-Case-Agent ---
> Konflikt- und Disziplinarverfahren: BetrVG §102 Anhörung, AGG §12 Beschwerdestelle, KSchG §4 Drei-Wochen-Klagefrist und BGB §626 - revisionssichere Fallführung mit HinSchG-Vertraulichkeit.

Arbeitsrechtliche Konfliktfälle stehen zwischen sechs Regelwerken, die einen einzelnen Fall gleichzeitig erfassen können. Das BetrVG verlangt die sachliche Behandlung jeder Beschwerde (§85) und die zwingende Anhörung des Betriebsrats vor jeder Kündigung (§102). Das AGG fordert bei Diskriminierung eine Maßnahme (§12) und bewehrt Verstöße mit Schadensersatz von drei Monatsgehältern pro Fall (§15). Das KSchG regelt die soziale Rechtfertigung, die Sozialauswahl und die Drei-Wochen-Klagefrist (§4), das BGB die Zwei-Wochen-Frist der fristlosen Kündigung (§626). Das HinSchG schützt Hinweisgeber mit Vertraulichkeitspflicht und Bußgeldern bis 50.000 Euro. Und die DSGVO untersagt rein automatisierte Einzelentscheidungen (Art. 22), während der EU AI Act HR-KI-Systeme als Hochrisiko einstuft - mit Pflichten nach aktuellem Recht ab dem 2. August 2026, voraussichtlich verschoben auf Dezember 2027 (Digital Omnibus, Mai 2026). Jeder Konfliktfall kann damit bis zu sechs Compliance-Pflichten zugleich auslösen.

## Was Konfliktfälle kosten: kumulative Schadensersatz-, Vergleichs- und Bußgeldrisiken

Die Sanktionen treffen kumulativ. Eine Diskriminierung kostet Schadensersatz nach AGG §15 von typisch 5.000 bis 25.000 Euro pro Fall, und die Drei-Jahres-Verjährung eröffnet ein Sammelklage-Risiko. Hinzu kommt das Vergleichsrisiko: Rund 60 Prozent der Kündigungsschutzverfahren enden mit Vergleich, bei einer langjährigen Führungskraft schnell im Bereich von 48.000 bis 96.000 Euro pro Fall, zuzüglich Anwaltskosten und interner Aufwände. Der häufigste Verlustgrund ist dabei kein materieller: 30 bis 40 Prozent der Verfahren scheitern allein an Anhörungsmängeln nach BetrVG §102, unabhängig davon, ob der Kündigungsgrund berechtigt war. Die DSGVO ahndet Verstöße mit bis zu 4 Prozent Konzernumsatz oder 20 Mio Euro (Art. 83 Abs. 5) - durchgesetzt etwa durch Hessen (9,55 Mio Euro gegen Vodafone, 2024) und Bayern (1,2 Mio Euro gegen Personio). Der EU AI Act geht bis 35 Mio Euro oder 7 Prozent Konzernumsatz, das HinSchG bis 50.000 Euro. Die Rechtsprechung 2024 bis 2026 konzentriert sich auf die Cloud-Personalakte (BAG vom 16.05.2024), Mobbing, die AGG-Beschwerdestelle und Fehler in der Sozialauswahl.

## 11 regelbasierte Entscheidungen, ein KI-Indikator, zwei menschliche Eskalationen

Der Agent zerlegt die Konfliktfall-Steuerung in 14 Micro-Entscheidungen. 11 davon laufen deterministisch nach Regelwerk, eine ist ein KI-Indikator, zwei bleiben beim Menschen. Jede Entscheidung dokumentiert die Frage, ihre Einordnung (R für regelbasiert, A für KI-Indikator ohne Endentscheidung, H für menschliche Pflicht-Eskalation), die Begründung mit Rechtsgrundlage und Fall-Audit-Trail sowie einen Anfechtungs-Pfad. Regelbasiert sind unter anderem die Verfahrensstruktur mit Fristenset, die Beschwerdebehandlung nach BetrVG §85 und AGG §13, die Prüfung des Sonderkündigungsschutzes, die Betriebsrats-Anhörung nach BetrVG §102, die Fristberechnung nach KSchG §4 und BGB §626, der Vertraulichkeits-Workflow nach HinSchG, die Sozialauswahl nach KSchG §1 Abs. 3, die revisionssichere Falldokumentation und die fallbezogene Zugriffskontrolle. Der eine KI-Indikator ist die Prüfung möglicher Diskriminierungs-Indizien gegen die Beweislastverteilung nach AGG §22; validiert wird von AGG-Beauftragtem, HR-Leitung und Rechtsabteilung. Die zwei menschlichen Entscheidungen sind die Klassifikation des Falltyps durch den HR-Business-Partner und die Eskalation an Aufsichtsrat und Konzernbetriebsrat bei drohender Bestandsgefährdung.

## Laufender Abgleich mit Rechtsprechung und Aufsichtspraxis 2024-2026

Der Agent gleicht die Verfahrensführung fortlaufend gegen die aktuelle Rechtsprechung und Aufsichtspraxis ab. Im Zentrum stehen die Anhörungsmängel nach BetrVG §102, an denen 30 bis 40 Prozent der Kündigungsschutzverfahren scheitern, sowie das BAG-Urteil vom 16.05.2024 zur Löschung der Cloud-Personalakte nach Beendigung. Der EuGH hat in C-579/21 den immateriellen Schadensersatz für Beschäftigte nach Art. 82 DSGVO bestätigt (typisch 1.000 bis 5.000 Euro pro Person). Weitere Schwerpunkte sind Mobbing und die Pflicht zur AGG-Beschwerdestelle (Schadensersatz typisch 5.000 bis 25.000 Euro), Fehler in der Sozialauswahl und die BEM-Pflicht nach sechs Wochen Arbeitsunfähigkeit. Die Bußgeldpraxis der Behörden zeigt klare Schwerpunkte bei Beschäftigten- und Disziplinarverfahren-Daten. Hinzu kommen die Hochrisiko-Pflichten des EU AI Act - nach aktuellem Recht ab dem 2. August 2026, voraussichtlich verschoben auf Dezember 2027 (Digital Omnibus, Mai 2026). Der Agent dokumentiert pro Schwerpunkt die Konformität und bereitet die Validierung durch den Datenschutzbeauftragten vor.

## Schwierige Fälle: gestapelter Schutz, Hinweisgeber, Mobbing, Massenentlassung

Die komplexen Konfliktfall-Szenarien sind eigens dokumentiert. Stapelt sich der Sonderkündigungsschutz - Schwerbehinderung, Schwangerschaft, Elternzeit und Betriebsratsamt zugleich - sind mehrere Zustimmungsverfahren parallel nötig: Integrationsamt, zuständige Landesbehörde und Betriebsrat nach BetrVG §103. Bei einem Hinweisgeber-Fall mit gleichzeitiger Disziplinar-Vorbereitung gegen den Hinweisgeber gilt strikte Trennung samt Beweislastumkehr bei vermuteter Repressalie (HinSchG §8, §36). Mobbing-Fälle laufen über die AGG-Beschwerdestelle (§13) mit Pflicht zur Maßnahme (§12); neben dem Schadensersatz nach §15 droht Schmerzensgeld. Eine Massenentlassung löst ab den Schwellen des KSchG §17 die Anzeige bei der Bundesagentur für Arbeit, die Sperrfrist und die Sozialplanpflicht (BetrVG §111) aus. Das BEM nach SGB IX §167 Abs. 2 ist nach sechs Wochen Arbeitsunfähigkeit Pflicht - fehlt es, trägt der Arbeitgeber bei einer krankheitsbedingten Kündigung die Beweislast. Hinzu kommen Sonderfälle: internationale Konflikte mit Drittlandsübertragung von Disziplinardaten, die Übernahme der Personalakte in der Insolvenz und die Erfüllung behördlicher Auflagen mit Wirksamkeitsnachweis.

## Integration mit HR-Plattformen, Whistleblowing-Lösungen und Compliance-Cockpit

Der Agent bindet die führenden HR- und Compliance-Plattformen über API an. Auf der HR-Seite sind das SAP (SuccessFactors HR Cases, HCM), Workday Employee Relations und Personio mit Modulen für Disziplinarfälle, AGG-Beschwerden und den Anhörungs-Workflow nach BetrVG §102, dazu für den Mittelstand BambooHR, P&I Loga, Sage HR, ATOSS und rexx systems. Für Hinweisgeber-Fälle kommen spezialisierte Whistleblowing-Plattformen hinzu - NAVEX EthicsPoint, EQS Integrity Line, Convercent, GAN Integrity, Whispli -, die die HinSchG-Vorgaben erfüllen: Vertraulichkeits-Workflow, Eingangsbestätigung binnen 7 Tagen, Rückmeldung binnen 3 Monaten, Speicherung höchstens 3 Jahre und keine Synchronisation in Performance-Systeme. ServiceNow HR Service Delivery deckt die Fall-Engine mit Audit-Trail ab. Über alle Systeme greifen der Anhörungs-Workflow nach BetrVG §102 mit SBV-Beteiligung, die AGG-Beschwerdestelle nach §13 und die Eskalation an den Prüfungsausschuss des Aufsichtsrats (§107 AktG). Der Agent verbindet sich mit dem Employee-Data-Management-Agent, der die Mitarbeiterhistorie als Input liefert, mit dem Audit-Compliance-Agent für HR-Audit-Berichte und mit dem Compliance-Training-Agent, der nach einem Diskriminierungsbefund eine AGG-Schulung auslöst.

--- Employee-Self-Service-Agent ---
> Mitarbeiter-Self-Service-Portal: DSGVO Art. 12-17 Auskunftsanspruch, EntgTranspG §10-14 Entgeltauskunft und eIDAS-QSig - 30-Tage-Frist statt Ticketrückstand mit BetrVG §87 Mitbestimmung.

Mitarbeiter-Self-Service-Plattformen stehen zwischen sechs Regelwerken, die einen einzelnen Antrag gleichzeitig erfassen können. Die DSGVO gewährt den Betroffenen ein Bündel von Rechten - Auskunft, Berichtigung, Löschung, Datenportabilität - mit einer 30-Tage-Frist nach Art. 12 Abs. 3 und untersagt rein automatisierte Einzelentscheidungen (Art. 22). Das BetrVG §87 Abs. 1 Nr. 6 zwingt zur Mitbestimmung, weil ein Portal als technische Einrichtung Verhalten überwachen kann. Das EntgTranspG gibt ab 200 Mitarbeitenden einen Entgeltauskunftsanspruch mit Drei-Monats-Frist, den die EU-Pay-Transparency-Richtlinie ab dem 7. Juni 2026 verschärft. Die eIDAS-Verordnung verlangt für schriftformbedürftige Anträge eine qualifizierte Signatur, das HinSchG eine vom Portal getrennte Hinweisgeber-Meldestelle mit Bußgeldern bis 50.000 Euro, und der EU AI Act stuft einen KI-Chatbot als Hochrisiko ein - mit Pflichten nach aktuellem Recht ab dem 2. August 2026, voraussichtlich verschoben auf Dezember 2027 (Digital Omnibus, Mai 2026). Jeder Antrag kann damit bis zu sechs Compliance-Pflichten zugleich auslösen.

## Was Fristverfehlungen kosten: kumulative Bußgeld- und Schadensersatzrisiken

Die Sanktionen treffen kumulativ. Die DSGVO ahndet Verstöße gegen die Betroffenenrechte mit bis zu 4 Prozent Konzernumsatz oder 20 Mio Euro (Art. 83 Abs. 5) - die Behörden setzen das durch, etwa Hessen (9,55 Mio Euro gegen Vodafone, 2024), Bayern (1,2 Mio Euro gegen Personio) und Berlin (14,5 Mio Euro gegen Deutsche Wohnen, 2019), mit Schwerpunkt auf Beschäftigtendaten. Daneben kann jeder einzelne Betroffene nach EuGH C-579/21 Schadensersatz nach Art. 82 verlangen, typisch 1.000 bis 5.000 Euro - bei einer Sammelklage summiert sich das. Eine Pay-Gap-Auskunft, die einen Diskriminierungsverdacht auslöst, führt zu Schadensersatz nach AGG §15. Der EU AI Act geht für einen Hochrisiko-Chatbot ohne Konformitätsbewertung bis 35 Mio Euro oder 7 Prozent Konzernumsatz, das HinSchG bis 50.000 Euro, ein Schriftformverstoß nach NachweisG §2 bis 2.000 Euro je Fall. Der Hebel liegt in der Frist: 25 bis 40 Prozent der Auskunftsanträge in HR-Service-Centern verfehlen die 30-Tage-Frist - unabhängig davon, ob der Antrag berechtigt war. Jede Verfehlung begründet unmittelbar einen Schadensersatzanspruch.

## 14 regelbasierte Entscheidungen, zwei KI-Indikatoren ohne Endentscheidung

Der Agent zerlegt die Self-Service-Steuerung in 16 Micro-Entscheidungen. 14 davon laufen deterministisch nach Regelwerk, zwei sind KI-Indikatoren ohne Endentscheidung. Jede Entscheidung dokumentiert die Frage, ihre Einordnung (R für regelbasiert, A für KI-Indikator), die Begründung mit Rechtsgrundlage und Antrags-Audit-Trail sowie einen Anfechtungs-Pfad. Regelbasiert sind unter anderem die Berechtigungsprüfung nach BDSG §26, der Auskunfts-Workflow nach Art. 15 mit 30-Tage-Frist, die Datenportabilität nach Art. 20, die Entgeltauskunft nach EntgTranspG, der Standard-Antrags-Workflow für Urlaub, Krankmeldung und Bescheinigung, die qualifizierte E-Signatur nach eIDAS, die getrennte Hinweisgeber-Meldestelle nach HinSchG, der Mitbestimmungs-Workflow nach BetrVG §87 Abs. 1 Nr. 6, die Berichtigung nach Art. 16, das Recht auf Löschung nach Art. 17, die Verfügbarkeitsüberwachung, das Eskalations-Routing und der revisionssichere Audit-Trail. Die zwei KI-Indikatoren sind die Erkennung des Antragstyps und die Chatbot-Antwort - beide mit menschlicher Aufsicht nach Art. 14 EU AI Act, Transparenzhinweis nach Art. 13 und automatischer Eskalation an den HR-Business-Partner bei Komplexität.

## Laufender Abgleich mit Rechtsprechung und Aufsichtspraxis 2024-2026

Der Agent gleicht die Antragsbearbeitung fortlaufend gegen die aktuelle Rechtsprechung und Aufsichtspraxis ab. Self-Service-Tools mit Auswertungsfunktionen sind nach der Rechtsprechung mitbestimmungspflichtig; ohne Betriebsvereinbarung ist die Einführung unwirksam. Das BAG-Urteil vom 16.05.2024 betrifft den Self-Service-Zugriff auf die Cloud-Personalakte und das Recht auf Löschung nach Beendigung. Der EuGH hat in C-579/21 den Schadensersatz für Beschäftigte nach Art. 82 DSGVO bestätigt (typisch 1.000 bis 5.000 Euro pro Person), mit Sammelklage-Risiko bei Datenpannen. Weitere Schwerpunkte sind die Bestätigungs- und Begründungspflicht bei Self-Service-Anträgen, die Schriftform-Anforderungen nach NachweisG §2 und die Vorbereitung auf die EU-Pay-Transparency-Richtlinie ab dem 7. Juni 2026. Die Bußgeldpraxis der Behörden zeigt klare Schwerpunkte bei Beschäftigtendaten. Hinzu kommen die Hochrisiko-Pflichten des EU AI Act für Chatbot-Systeme - nach aktuellem Recht ab dem 2. August 2026, voraussichtlich verschoben auf Dezember 2027 (Digital Omnibus, Mai 2026). Der Agent dokumentiert pro Schwerpunkt die Konformität und bereitet die Validierung durch den Datenschutzbeauftragten vor.

## Schwierige Fälle: Sondercategorien, Hinweisgeber, Barrierefreiheit, Pay-Gap

Die komplexen Self-Service-Szenarien sind eigens dokumentiert. Gesundheitsdaten aus einer Krankmeldung sind Sondercategorien nach Art. 9 DSGVO und erfordern erweiterten Schutz: physische und logische Trennung, Verschlüsselung, Zugriffsbeschränkung und die elektronische Übermittlung der AU-Bescheinigung an die Krankenkasse nach SGB V. Ein Hinweisgeber-Kanal mit gleichzeitiger Disziplinar-Vorbereitung gegen den Hinweisgeber verlangt strikte Trennung samt Beweislastumkehr bei vermuteter Repressalie (HinSchG §8, §36). Für Schwerbehinderte muss das Portal barrierefrei nach BITV 2.0 und WCAG 2.1 Level AA sein - bedienbar per Screenreader und Tastatur, mit ausreichendem Kontrast -, unter Beteiligung der Schwerbehinderten-Vertretung (SGB IX §178). Ein Pay-Gap-Befund aus einer Entgeltauskunft löst die AGG-Beschwerdestelle (§13) mit Pflicht zur Maßnahme (§12) und Schadensersatzrisiko nach §15 aus. Hinzu kommen Sonderfälle: eine Datenpanne mit Meldung binnen 72 Stunden nach Art. 33, internationale Anträge mit Drittlandsübertragung, Manager-Anträge mit erweiterter Berechtigungsprüfung und der Aufhebungsvertrag mit Pflicht zur qualifizierten Signatur nach eIDAS und 10-jähriger Aufbewahrung.

## Integration mit HR-Plattformen, E-Signatur-Diensten und Whistleblowing-Trennung

Der Agent bindet die führenden HR- und Self-Service-Plattformen über API an. Auf der Konzern-Seite sind das SAP (SuccessFactors, HCM ESS/MSS), Workday und Oracle HCM Cloud mit Modulen für Urlaub, Krankmeldung, Bescheinigungen, Pay-Slip und Personalakten-Einsicht, jeweils mit Auskunfts-, Datenportabilitäts- und Löschungs-Workflows sowie nativen Mobile-Apps. Für den Mittelstand kommen Personio, BambooHR, ADP, Sage, ATOSS, rexx systems und DATEV hinzu, für das Service-Management ServiceNow mit DSGVO-konformem Chatbot unter menschlicher Aufsicht. Schriftformbedürftige Anträge laufen über qualifizierte E-Signatur-Dienste nach eIDAS - DocuSign, Adobe Sign, Skribble, Yousign. Hinweisgeber-Fälle werden strikt getrennt über HinSchG-konforme Whistleblowing-Plattformen wie NAVEX EthicsPoint, EQS Integrity Line oder GAN Integrity geführt, mit Vertraulichkeits-Workflow und den Fristen des §17. Über alle Systeme greifen der Mitbestimmungs-Workflow nach BetrVG §87 Abs. 1 Nr. 6 und die Eskalation an den Prüfungsausschuss des Aufsichtsrats (§107 AktG). Der Agent verbindet sich mit dem Employee-Data-Management-Agent, dem er Adressänderungen als Stammdaten-Updates übergibt, mit dem Employee-Relations-Case-Agent für Beschwerden nach BetrVG §85 und mit dem Audit-Compliance-Agent für HR-Audit-Berichte.

--- Equipment-Provisioning-Agent ---
> IT-Hardware-Bereitstellung Onboarding/Offboarding: BetrVG §87 Mitbestimmung, DGUV V1+V2 Ergonomie und NIS2-Cybersecurity - vollständige Pipeline mit Intune MDM und Asset-Tracking.

IT-Equipment-Bereitstellung in Deutschland steht zwischen sechs Regelwerken, die eine einzelne Geräteausgabe gleichzeitig erfassen können. Das BetrVG §87 Abs. 1 Nr. 6 zwingt zur Mitbestimmung des Betriebsrats, sobald eine Tracking-Funktion - Microsoft Intune, Apple DEP, GPS, App-Inventar - das Gerät zur technischen Einrichtung der Mitarbeiterüberwachung macht. Die DSGVO untersagt rein automatisierte Einzelentscheidungen (Art. 22), verlangt Privacy by Design (Art. 25) und eine Folgenabschätzung für Tracking-Algorithmen (Art. 35), bewehrt mit bis zu 4 Prozent Konzernumsatz oder 20 Mio Euro. DGUV V1+V2 und die Bildschirmarbeitsverordnung schreiben die Ergonomie vor - verstellbarer Stuhl, ergonomische Tastatur, Sehtest alle fünf Jahre. Die NIS2-Richtlinie und das IT-SiG 2.0 fordern Cybersecurity-Vorgaben mit Risiko-Management und gestuftem Incident-Reporting, bewehrt mit bis zu 10 Mio Euro oder 2 Prozent des weltweiten Jahresumsatzes. Hinzu kommen die eIDAS-Verordnung für die Signatur-Hardware und SGB IX §164 für behinderungsgerechte Anpassungen. Jede Geräteausgabe kann damit bis zu sechs Compliance-Pflichten zugleich auslösen.

## Was Verstöße kosten: NIS2, DSGVO und BetrVG, kumulativ

Die Sanktionen treffen kumulativ. Die NIS2-Richtlinie ahndet Cybersecurity-Verstöße in den KRITIS-Sektoren - Energie, Wasser, IT, Finanz, Verkehr, Lebensmittel - mit bis zu 10 Mio Euro oder 2 Prozent des weltweiten Jahresumsatzes. Die DSGVO geht bis 4 Prozent Konzernumsatz oder 20 Mio Euro, wenn ein Tracking-Algorithmus ohne Folgenabschätzung läuft oder gegen das Verbot automatisierter Einzelentscheidungen verstößt. Unterbleibt die Mitbestimmung, kann der Betriebsrat die Nutzung gerichtlich untersagen lassen. Hinzu kommen BSI-Sanktionen nach IT-SiG 2.0 bei unterlassener Vorfallsmeldung, DGUV-Folgen bei Ergonomie-Mängeln und der Verlust der Inklusionsamt-Kostenerstattung bei Verstößen gegen SGB IX §164. Bei kapitalmarktorientierten Konzernen drohen zusätzlich BaFin-Sanktionen und ein Reputationsschaden mit spürbarer Kursreaktion in den Handelstagen nach einer BSI-Veröffentlichung. Der BSI-Schwerpunkt 2024 bis 2026 liegt klar auf der NIS2-Umsetzung und der Equipment-Cybersecurity.

## 12 regelbasierte Entscheidungen, ein KI-Indikator, zwei menschliche Eskalationen

Der Agent zerlegt die Equipment-Bereitstellung in 15 Micro-Entscheidungen. 12 davon laufen deterministisch nach Regelwerk, eine ist ein KI-Indikator, zwei bleiben beim Menschen. Jede Entscheidung dokumentiert die Frage, ihre Einordnung (R für regelbasiert, A für KI-Indikator ohne Endentscheidung, H für menschliche Pflicht-Eskalation), die Begründung mit Rechtsgrundlage und Audit-Trail aus dem Quellsystem sowie einen Anfechtungs-Pfad. Regelbasiert sind unter anderem die Übernahme der Stammdaten und die Bedarfsklassifikation, die Mitbestimmungsprüfung nach BetrVG §87 Abs. 1 Nr. 6, die Ergonomie-Validierung nach DGUV V1+V2, die Einrichtung über Microsoft Intune und Apple DEP, die NIS2-Cybersecurity-Konfiguration, die Datenschutz-Folgenabschätzung nach Art. 35, die eIDAS-Signatur-Hardware, die Sicherheits-Grundkonfiguration, die Auslieferung, die Geräterückgabe nach Art. 17 und der revisionssichere Audit-Trail. Der eine KI-Indikator ist die Cross-System-Synchronisation des Lebenszyklus-Status, validiert von der IT-Operations-Leitung. Die zwei menschlichen Entscheidungen sind die Schwerbehinderten-Anpassung nach SGB IX §164 unter Beteiligung der Schwerbehinderten-Vertretung und die Eskalation eines Cyber-Vorfalls an Aufsichtsrat und BSI.

## Laufender Abgleich mit BSI-Schwerpunkten und Aufsichtspraxis 2024-2026

Der Agent gleicht die Equipment-Konfiguration fortlaufend gegen die BSI-Schwerpunkte und die Aufsichtspraxis ab. Im Zentrum stehen die NIS2-Equipment-Cybersecurity mit Risiko-Management und Incident-Reporting nach BSI-Grundschutz sowie das IT-SiG 2.0 für die KRITIS-Sektoren. Die Datenschutzbehörden prüfen das Equipment-Tracking gegen Art. 22 DSGVO und die Folgenabschätzungs-Pflicht nach Art. 35; die arbeitsgerichtliche Rechtsprechung 2024 bis 2026 behandelt Microsoft Intune und Apple DEP als mitbestimmungspflichtige technische Einrichtungen. Die DGUV setzt Schwerpunkte bei der Bildschirmarbeits-Ergonomie und der Sehtest-Pflicht, Schwerbehinderten-Vertretung und Inklusionsamt bei den behinderungsgerechten Anpassungen. Bei kapitalmarktorientierten Konzernen besteht ein DPR-Folgeprüfungs-Risiko nach Cyber-Vorfällen. Der Agent dokumentiert pro Schwerpunkt die Konformität und meldet Auffälligkeiten früh an den Prüfungsausschuss des Aufsichtsrats (§107 AktG), an das BSI binnen 24 Stunden und als Datenpanne nach Art. 33 DSGVO binnen 72 Stunden.

## Schwierige Fälle: Schwerbehinderte, internationale Mitarbeiter, C-Suite

Die komplexen Equipment-Szenarien sind eigens dokumentiert. Eine Schwerbehinderten-Anpassung nach SGB IX §164 verlangt eine individuelle Bedarfsanalyse - Vergrößerungssoftware, Spezial-Tastatur, Sprachsteuerung -, die Beteiligung der Schwerbehinderten-Vertretung und den Schutz der Gesundheitsdaten als Sondercategorie nach Art. 9 DSGVO; das Inklusionsamt kann die Kosten erstatten. Bei internationalen Mitarbeitern kommen Equipment-Spedition, Zollerlaubnis, Außenwirtschaftsrecht mit Embargo-Listen und die A1-Bescheinigung hinzu. C-Suite-Geräte erfordern erhöhte Cybersecurity-Anforderungen mit Hardware Security Module, dediziertem VPN und Smart-Card-Reader für die eIDAS-Signatur. In KRITIS-Sektoren gelten verschärfte Vorgaben mit BSI-Grundschutz und dedizierter Incident-Response, für Field-Worker robuste, spritzwassergeschützte Geräte, in explosionsgefährdeten Bereichen mit ATEX-Zertifizierung. Im Home-Office greifen die Bildschirmarbeits-Ergonomie und VPN-Pflicht. Bei Verlust oder Diebstahl löst die Regel die Datenpannen-Meldung binnen 72 Stunden nach Art. 33 DSGVO, die BSI-Meldung nach IT-SiG 2.0 und die Fernlöschung über Microsoft Intune oder Apple DEP aus.

## Integration mit IT-Operations-Plattformen, MDM-Systemen und E-Signatur

Der Agent bindet die führenden Equipment-Provisioning-Plattformen über API an. Für Onboarding und Beschaffung sind das auf Konzernebene SAP (SuccessFactors Onboarding, HCM Equipment Tracking, Asset Manager, Ariba) und Workday, im Service-Management ServiceNow mit IT Asset und Service Management, für den Mittelstand Personio und BambooHR. Das Mobile Device Management läuft über Microsoft Intune mit Autopilot und Defender, Jamf Pro für Apple-Geräte sowie VMware Workspace ONE und IBM MaaS360 als plattformübergreifende Alternativen. Für die Asset-Verfolgung kommen Lansweeper, Snipe-IT und Freshservice hinzu. Schriftformbedürftige Erhaltsbestätigungen laufen über eIDAS-konforme E-Signatur-Dienste - DocuSign, Adobe Sign, Yousign. Maßstab der Cybersecurity-Konfiguration sind BSI-Grundschutz, ISO 27001 und ISO 22301. Der Agent verbindet sich mit dem Employee-Self-Service-Agent für die Anbindung ans Mitarbeiterportal, mit dem Compliance-Training-Agent für die Schulung zur KI-Kompetenz und mit dem Audit-Compliance-Agent für HR-Audit-Berichte.

--- Executive-Recruiting-Agent ---
> C-Suite Executive Search: AktG §76/§84 Vorstandsbestellung, DCGK B.5 Vergütung und FüPoG-Mindestbeteiligung - Confidential Search mit Aufsichtsrats-Prüfungsausschuss und AGG-Bias-Audit.

Eine C-Suite-Besetzung in Deutschland steht zwischen sechs parallelen Compliance-Themen mit sehr unterschiedlichen Konsequenzen. Das Aktienrecht verlangt eine formale Aufsichtsrats-Bestellung von höchstens fünf Jahren und eine Hauptversammlungs-Genehmigung des Vergütungssystems mindestens alle vier Jahre (AktG §84, §87a). Der Corporate Governance Kodex 2024 ergänzt Maximum-Cap, ESG-Komponenten und Klawback-Klauseln (DCGK B.5, G.1 bis G.10). Das FüPoG erzwingt 30 Prozent Frauen im Aufsichtsrat und mindestens eine Frau im Vorstand ab vier Mitgliedern. Der EU AI Act stuft Executive-Search-Algorithmen als Hochrisiko-Systeme ein, mit Bias-Audit und menschlicher Aufsicht. AGG §22 verlagert bei Diskriminierungs-Indizien die Beweislast auf den Arbeitgeber. Und die EU-Entgelttransparenz-Richtlinie (umzusetzen bis 7.6.2026) verbietet die Frage nach dem bisherigen Gehalt. In Summe heißt das: Jede Executive-Besetzung kann gleichzeitig bis zu sechs Compliance-Pflichten auslösen.

## Warum sich die Bußgelder kumulieren

Die Sanktionen treffen denselben Vorgang aus mehreren Richtungen. Der EU AI Act verhängt bis zu 35 Mio Euro oder 7 Prozent des globalen Jahresumsatzes, wenn ein Hochrisiko-Recruiting-System ohne Bias-Audit oder menschliche Aufsicht läuft. Die DSGVO greift mit bis zu 4 Prozent Konzernumsatz oder 20 Mio Euro, wenn die Datenschutz-Folgenabschätzung fehlt oder rein automatisiert entschieden wird (Art. 22, 35). AGG §15 sieht Entschädigungen bis zu drei Bruttomonatsgehälter vor - bei einer Klage-Quote von 25 Prozent (ADS-Statistik 2024) ein realistisches Szenario. Bei Banken und Versicherern kommen BaFin-Sanktionen bis 10 Mio Euro hinzu, bei KYC-Verstößen GwG-Bußgelder bis 5 Mio Euro. Verstöße gegen den Governance-Kodex bringen Reputations-Risiken und Aufsichtsrats-Haftung. Und unabhängig vom Bußgeld fällt der Aktienkurs typisch um 3 bis 7 Prozent in den drei Handelstagen nach einem Leak.

## Sechs menschliche Entscheidungen, sechs Regelprüfungen, drei KI-Indikatoren

Der Agent zerlegt die Executive-Besetzung in 15 Mikro-Entscheidungen, deren Schwerpunkt klar beim Menschen liegt. Vorstand und Aufsichtsrat entscheiden über Mandat, Vergütungssystem, Headhunter-Beauftragung, Vergütungs-Paket, Vertragsverhandlung und Eskalation - das sind die sechs menschlichen Entscheidungen, jeweils mit klarer Rechtsgrundlage von AktG §84 bis AGG §22. Sechs weitere Schritte laufen regelbasiert: die AGG- und FüPoG-Prüfung des Suchprofils, das Bias-Audit nach EU AI Act, das KYC-Screening nach GwG, die BaFin-Zulassung, der vertrauliche Suchprozess und die prüfungssichere Datenübergabe. Drei Schritte sind KI-gestützte Indikatoren - Profil-Bewertung, Interview-Koordination und Feedback-Konsolidierung -, die immer eine menschliche Validierung erfordern (DSGVO Art. 22, EU AI Act Article 14). Jede Entscheidung trägt Decider-Klassifikation, Begründung mit Rechtsgrundlage, Quell-System und Anfechtungs-Pfad.

## Laufende Plausibilitätsprüfung gegen die Aufsichtsschwerpunkte

Der Agent prüft fortlaufend gegen die aktuellen Schwerpunkte der Aufsichtsbehörden. Bei Banken, Versicherern und Kapitalverwaltungsgesellschaften verschärft die BaFin den Fit-and-Proper-Test der Geschäftsleiter (KWG §25c, VAG §24). Der Governance-Kodex wird jährlich aktualisiert, vor allem bei Maximum-Cap und Klawback. Datenschutzaufsicht und Antidiskriminierungsstelle haben ihren Fokus auf KI-basierte Auswahl gelegt - flankiert von einer BAG-Rechtsprechung, die sich auf den EU AI Act stützt. Der Agent dokumentiert je Aufsichtsbehörde die Konformität samt Vorbereitung auf eine Prüfung. Fällt etwas auf, eskaliert der Fall früh an den Prüfungsausschuss des Aufsichtsrats (§107 AktG), bei Datenpannen greift die 72-Stunden-Meldefrist nach DSGVO Art. 33.

## Edge-Cases: internationale Vorstände, regulierte Branchen, M&A

Die anspruchsvollen Szenarien sind explizit hinterlegt. Bei der FüPoG-Quote gilt eine Begründungspflicht, wenn die 30 Prozent im Aufsichtsrat oder die Mindestbeteiligung im Vorstand unterschritten werden. Internationale Vorstände bringen Aufenthaltsrecht, Doppelbesteuerungsabkommen, Apostille von Zeugnissen und Sprach-Anforderungen ins Spiel. Bei Banken und Versicherern steht die BaFin-Vorab-Konsultation mit Sechs-Wochen-Frist und der Fit-and-Proper-Test im Vordergrund. M&A-Konstellationen unterliegen Bundeskartellamt-Genehmigungen, Non-Solicitation-Vereinbarungen und - bei kapitalmarktorientierten Konzernen - dem Insiderhandels-Risiko mit Ad-hoc-Publizitätspflicht. Die Inklusion schwerbehinderter Menschen gilt auch in der C-Suite (SGB IX §164, §178). Und bei einem Leak der laufenden Suche reagiert der Aktienkurs typisch mit 3 bis 7 Prozent Rückgang.

## Integration mit den führenden Plattformen

Der Agent bindet die etablierten Executive-Search- und HCM-Plattformen über API ein. Auf der Headhunter-Seite sind das die globalen Marktführer wie Korn Ferry, Heidrick & Struggles, Russell Reynolds, Spencer Stuart und Egon Zehnder sowie die deutschen Premium-Berater wie Kienbaum und Mercuri Urval mit DACH-Fokus. Als HCM-Systeme dienen SAP SuccessFactors und Workday im Konzern, Personio im Mittelstand. KI-gestütztes Talent-Sourcing (Eightfold AI, Beamery, LinkedIn Talent Insights) und Assessment-Plattformen (Pymetrics, HireVue) werden EU-AI-Act-konform konfiguriert, mit Bias-Audit und menschlicher Validierung. Für die Vertragsunterzeichnung kommen eIDAS-konforme Signaturdienste zum Einsatz (DocuSign, Adobe Sign, Yousign), für die Vergütungs-Bemessung die Benchmarks von Mercer, Aon und Willis Towers Watson.

--- Auslagen-Agent ---
> Mitarbeiter-Auslagen prüfungssicher abwickeln: KI liest den Beleg, das Regelwerk rechnet 70/30 und Pauschalen, der Mensch genehmigt - GoBD-fest, 8 Jahre.

## Jeder Beleg liest sich leicht. Keiner beweist von allein, dass er hält.

Aus jedem Reise- und Spesenbeleg wird per OCR in Sekunden ein ausgefülltes Formular - das ist seit Jahren Standard. Die Frage, an der eine Erstattung und eine Außenprüfung wirklich hängen, beantwortet kein klassisches Reisekostentool: Waren die Pflichtangaben vollständig, stimmte die 70/30-Aufteilung, hat ein Mensch jede Erstattung verantwortet - und können Sie das acht Jahre später noch unveränderbar belegen?

Dieser Agent folgt dem [Decision Layer](/de/decision-layer/)-Prinzip: Jeder Schritt ist entweder regelbasiert, ein KI-Vorschlag oder eine menschliche Freigabe - klar getrennt und unveränderbar protokolliert. Nach EU AI Act ist er kein Hochrisiko-System, weil er keine Menschen bewertet. Seine Anforderungen kommen aus dem Steuer- und Datenschutzrecht, und die sind hart genug: Ein einziger falsch behandelter Beleg kann den Betriebsausgabenabzug, den Vorsteuerabzug und die Lohnsteuerfreiheit gleichzeitig kippen.

## Jeder Beleg ist ein Compliance-Dokument mit Acht-Jahres-Frist

Ein Reisekosten- oder Bewirtungsbeleg ist kein Quittungsschnipsel, sondern ein Buchungsbeleg mit gesetzlicher Aufbewahrungspflicht. Nach Handelsgesetzbuch Paragraph 257 Abs. 4 - und parallel Abgabenordnung Paragraph 147 - sind Buchungsbelege seit dem 1. Januar 2025 acht Jahre revisionssicher aufzubewahren; das Vierte Bürokratieentlastungsgesetz hat die frühere Zehn-Jahres-Frist gesenkt ([BDO zu Paragraph 257 Abs. 4 HGB](https://www.bdo.de/de-de/insights/accounting-it/hgb/verkuerzung-der-aufbewahrungsfristen-257-abs-4-hgb-durch-das-4-buerokratieentlastungsgesetz)). Wer Belege noch zehn Jahre archiviert, plant nach veralteter Rechtslage. Entscheidend ist dabei nicht die Dauer allein, sondern die Unveränderbarkeit: Ist die Belegkette nicht revisionssicher, verliert die Buchführung ihren Beweiswert, und das Finanzamt darf die Besteuerungsgrundlagen schätzen. Aus jedem eingereichten Beleg wird damit ein Dokument, dessen ordnungsgemäße Ablage über den Betriebsausgabenabzug mitentscheidet - und genau deshalb gehört die Archivierung in eine deterministische Regel-Schicht, nicht in einen manuellen Schritt, der vergessen werden kann.

## Die Pflichtangaben entscheiden über alles oder nichts

Bei der Bewirtung gibt es keinen Mittelweg zwischen abzugsfähig und nicht abzugsfähig. Geschäftliche Bewirtungskosten sind nach Einkommensteuergesetz Paragraph 4 Abs. 5 Satz 1 Nr. 2 zu 70 Prozent abzugsfähig ([dejure.org](https://dejure.org/gesetze/EStG/4.html)), aber nur, wenn der Beleg Ort, Tag, Teilnehmer, Anlass und Höhe vollständig ausweist. Fehlt eine dieser Angaben, entfällt der Betriebsausgabenabzug nicht etwa anteilig, sondern komplett - die Finanzverwaltung erkennt den Beleg dann gar nicht an. Diese Prüfung ist rein deterministisch: Eine Pflichtangabe ist da oder sie fehlt. Genau deshalb gehört sie nicht in die Hände einer schätzenden Maschine, sondern in ein nachrechenbares Regelwerk, das jede Angabe abhakt, bevor der Vorgang weiterläuft. Dieselbe Trennschärfe gilt für die Reisekosten: Erstattungen innerhalb der Pauschalen von 14 Euro bei mehr als acht Stunden und 28 Euro bei vollen 24 Stunden Abwesenheit ([dejure.org](https://dejure.org/gesetze/EStG/9.html)) bleiben lohnsteuer- und sozialabgabenfrei - der Betrag darüber wird ohne Rechtsgrundlage zu steuerpflichtigem Arbeitslohn, den am Ende der Arbeitgeber nachzahlt.

## Die KI erfasst, das Regelwerk rechnet, der Mensch verantwortet

Der entscheidende Unterschied zu klassischer Reisekostensoftware liegt nicht im Automatisierungsgrad, sondern in der Frage, wer was entscheidet. Die KI liest den Beleg per OCR und schlägt eine steuerliche Kategorie vor, doch dieser Vorschlag ist ein Indikator, keine Entscheidung. Das Regelwerk rechnet anschließend deterministisch: die 70/30-Aufteilung bei Bewirtung, die Verpflegungspauschalen nach Abwesenheitsdauer, die Vorsteuerabzugsfähigkeit nach den Rechnungspflichtangaben. Und am Ende genehmigt ein Mensch die Erstattung mit Signatur. Dieses Prinzip beschreibt der [Decision Layer](/de/decision-layer/) im Detail. So bereitet die Geschwindigkeit der Maschine die Entscheidung des Menschen vor, statt sie zu ersetzen. Steuerliche Detailfragen, die über diese Operations-Schicht hinausgehen, übergibt der Agent gezielt an die fachlich spezialisierten Agenten für [Reisekosten](/de/finance-agent-katalog/travel-expense-agent/) und [Bewirtung](/de/finance-agent-katalog/entertainment-expense-agent/).

## Ohne menschliche Freigabe ist die Automatisierung selbst rechtswidrig

Eine Erstattungsentscheidung, die einen Mitarbeiter erheblich berührt, darf nicht allein durch die Maschine fallen. Datenschutz-Grundverordnung Artikel 22 verlangt echtes menschliches Eingreifen, nicht das formale Abnicken einer fertigen Empfehlung - andernfalls drohen Bußgelder bis zu 20 Millionen Euro oder vier Prozent des gesamten weltweit erzielten Jahresumsatzes des vorangegangenen Geschäftsjahres, je nachdem welcher Wert höher ist ([dsgvo-gesetz.de](https://dsgvo-gesetz.de/art-83-dsgvo/)). Im Agenten ist der Mensch deshalb genau dort verankert, wo das Gesetz ihn fordert: bei der Genehmigung und bei der Beurteilung strittiger Fälle. Eine Auto-Freigabe gibt es nicht; die KI darf Auffälligkeiten wie eine Belegdoppelung markieren und eskalieren, aber nicht selbst entscheiden. Was nach einer Einschränkung der Effizienz klingt, ist in Wahrheit die Voraussetzung dafür, dass die Automatisierung überhaupt rechtssicher betrieben werden darf.

## Prüfbar verteilte Verantwortung schlägt maximale Autonomie

Wettbewerber verkaufen den Automatisierungsgrad - berührungslose Erstattung, hohe OCR-Genauigkeit, Auszahlung in Minuten. Wenn Sie jede Prozessänderung zuerst auf Betriebsprüfungsfähigkeit prüfen und erst dann auf Effizienz, ist das genau das falsche Versprechen: Es klingt nach einer Black Box und kollidiert sichtbar mit Artikel 22. Dieser Agent dreht die Logik um. Nicht "wie viel macht die KI", sondern "wer entscheidet was, und ist es belegbar" steht im Mittelpunkt. Jeder Schritt trägt einen benannten Entscheider, jede Zahl stammt aus Gesetz oder Richtlinie statt aus einer Schätzung, und der KI-Vorschlag ist ausdrücklich als Indikator deklariert. Genau diese Trennung ist es, die eine Betriebsvereinbarung unterschreibbar macht und die der Betriebsrat nach Betriebsverfassungsgesetz Paragraph 87 Abs. 1 Nr. 6 erwartet, bevor er ein belegverarbeitendes System freigibt.

## Der Agent ersetzt keine Systeme, sondern ordnet Entscheidungen

Der Agent legt sich als Schicht über die bestehende Reisekosten- und Buchhaltungslandschaft, nicht an deren Stelle. Bestehende Fachsysteme bleiben die führende Datenebene, in die der Agent als Integrationsziel andockt - die Belegverarbeitung bleibt dort, wo sie heute schon stattfindet. Was der Agent ergänzt, ist die nachvollziehbare Entscheidungs-Schicht darüber: Jeder Erstattungsvorgang wird mit eingereichtem Beleg, angewendeten Regeln und Freigaben revisionssicher protokolliert, sodass eine Lohnsteuer-Außenprüfung jeden Schritt rekonstruieren kann, ohne dass jemand Belege manuell zusammensuchen muss. Der nächste Schritt ist deshalb keine Software-Einführung, sondern eine Bestandsaufnahme: Wo in Ihrem Auslagenprozess sitzt heute die manuelle Pflichtangaben-Prüfung, und wie prüfungsfest ist die Belegkette dahinter - vom ersten Upload bis zur signierten Freigabe?

## Auf einen Blick

- **Was er tut:** Wickelt Mitarbeiter-Auslagen und Reisekosten von der Belegerfassung bis zur signierten Freigabe prüfungssicher ab.
- **Klassifikation:** Kein Hochrisiko-System nach EU AI Act - die Härte kommt aus Steuer- und Datenschutzrecht, nicht aus einer Personenbewertung.
- **Entscheidungslogik:** Die KI liest und schlägt vor, das Regelwerk rechnet deterministisch (70/30, Pauschalen, Vorsteuer), der Mensch genehmigt mit eIDAS-Signatur.
- **Compliance-Anker:** Bewirtung 70 Prozent nur mit vollständigem Beleg, Pauschalen 14 und 28 Euro, acht Jahre revisionssichere Aufbewahrung, Artikel 22 DSGVO und Betriebsverfassungsgesetz Paragraph 87.
- **Integration:** Dockt an SAP Concur, DATEV, Personio, Microsoft Dynamics 365 oder Pleo an und ersetzt das Fachsystem nicht.
- **Prüfungsfall:** Jede Stichprobe lässt sich vom genehmigten Betrag bis zum Originalbeleg zurückverfolgen - ohne nachträgliche Rekonstruktion.

--- HR-Dokumentenmanagement-Agent ---
> Elektronische Personalakte mit prüffähiger Verantwortung: KI klassifiziert, das Regelwerk setzt Fristen, der Mensch gibt jede Löschung frei - revisionssicher.

## Jedes Archiv findet das Dokument. Keines beweist, wer es löscht.

Eine Personalakte zu scannen, zu verschlagworten und durchsuchbar zu machen ist seit Jahren gelöst - DocuWare, ELO, SAP oder Personio können das. Die zwei Fragen, an denen die elektronische Personalakte wirklich hängt, beantwortet keines dieser Systeme von sich aus: Wer hat die Löschung dieses einen Dokuments verantwortet, auf welcher Frist - und steht hinter dieser Frist eine gepflegte Rechtsregel oder eine Zahl, die irgendwann in eine Konfiguration getippt wurde?

Dieser Agent folgt dem [Decision Layer](/de/decision-layer/)-Prinzip: Jeder Schritt ist entweder eine KI-Vorklassifikation, eine deterministische Regel oder eine menschliche Freigabe - klar getrennt und unveränderbar protokolliert. Nach [EU AI Act](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) ist er kein Hochrisiko-System, weil er keine Menschen bewertet. Seine Anforderungen kommen aus Datenschutz-, Arbeits- und Steuerrecht, und die sind hart genug.

## Die teuerste Zeile auf einer Wettbewerber-Seite ist eine falsche Frist

Wer Aufbewahrungsfristen in Marketing-Prosa gießt, pflegt am Ende keine einzige korrekt. Der Beweis liegt offen: Zum 1.1.2025 wurde die Aufbewahrungsfrist für Buchungsbelege von zehn auf acht Jahre verkürzt ([Paragraph 147 AO](https://www.gesetze-im-internet.de/ao_1977/__147.html)). Bücher, Inventare und Jahresabschlüsse bleiben bei zehn Jahren, das Lohnkonto bei sechs Jahren ([Paragraph 41 EStG](https://www.gesetze-im-internet.de/estg/__41.html)). Eine Seite, die heute noch pauschal "zehn Jahre Buchungsbelege" verspricht, dokumentiert damit ihr eigentliches Problem - sie verwechselt eine Rechtsregel mit einem in Text gegossenen Datum.

Genau hier liegt der Schmerz, der eine Personalakte zur Compliance-Falle macht: Die Frist ist nicht pauschal, sondern dokument-spezifisch. Sechs Jahre für das Lohnkonto, acht für Buchungsbelege, zehn für den Abschluss - jede aus einer eigenen Norm. Wird zu kurz aufbewahrt, verliert die Buchführung bei einer Prüfung ihren Beweiswert nach Paragraph 158 AO, und das Finanzamt darf nach Paragraph 162 AO schätzen. Wird zu lang aufbewahrt, ist das ein Datenschutz-Verstoß nach DSGVO Art. 5, weil Daten nur so lange gehalten werden dürfen, wie der Zweck es verlangt. Ein Pauschal-Regal trifft garantiert eine der beiden Pflichten nicht.

## Drei Quellen, klar getrennt: wer klassifiziert, wer setzt die Frist, wer löscht

Die meisten Anbieter sagen, ein Mensch bleibe "im Prozess", und kleben ein DSGVO- und ein GoBD-Siegel daneben. Beides bleibt eine schwarze Box. Der Agent macht stattdessen für jeden Schritt sichtbar, aus welcher von drei Quellen die Entscheidung stammt:

| Quelle | Was sie entscheidet | Beispiel aus der Personalakte |
|--------|---------------------|-------------------------------|
| KI-Vorschlag (A) | Erkennt und ordnet vor, entscheidet nie | OCR-Erfassung, Dokumenttyp- und Sensitivitäts-Erkennung am Eingang |
| Regelwerk (R) | Alles Deterministische, kein Ermessen | Aktentrennung, Fristzuweisung, Rechte-Matrix, Löschprüfung gegen Aufbewahrungspflicht |
| Mensch (H) | Freigabe und rechtliche Beurteilung | finale Vernichtung mit Signatur, diskriminierungsrelevante Inhaltsbeurteilung |

Der Agent ist damit überwiegend ein deterministischer Fristen- und Rechte-Motor, mit KI nur als Vorklassifikation am Eingang und einem festen menschlichen Freigabe-Tor am Ende. Das ist die ehrliche Antwort auf den naheliegenden Einwand "darf eine KI eine Personalakte löschen?" - sie darf es nicht, und der Agent ist so gebaut, dass sie es strukturell nicht kann. Wo Wettbewerber suggerieren, "die KI macht das", verschweigen sie, dass DSGVO Art. 22 genau die automatisierte Löschentscheidung verbietet. Wie diese Schicht architektonisch durchgreift, zeigt der [Decision Layer](/de/decision-layer/).

## Der Konflikt zwischen Löschen und Aufbewahren wird benannt, nicht versteckt

Der eigentliche Schmerz der elektronischen Personalakte ist kein technischer, sondern ein juristischer Widerspruch: Die DSGVO verlangt zu löschen, das Steuerrecht verlangt aufzubewahren - und beide gelten für dasselbe Dokument. Die meisten Tools tun so, als gäbe es diesen Konflikt nicht, und archivieren im Zweifel alles. Damit produzieren sie genau den Datenschutz-Verstoß, den sie zu verhindern versprechen.

Der Agent macht die Konfliktauflösung zum sichtbaren, regelbasierten Schritt. Liegt ein Löschverlangen nach DSGVO Art. 17 vor, prüft das Regelwerk, ob eine steuerliche Aufbewahrungspflicht greift - denn die ist nach Art. 17 Abs. 3 ein ausdrücklicher Ausschlussgrund gegen das Löschen. Greift sie, bleibt die Akte mit dokumentierter Begründung erhalten und die betroffene Person wird informiert. Fällt der Zweck weg und keine Pflicht greift mehr, geht das Dokument in den Löschvorschlag - und von dort erst in die menschliche Freigabe. Pro Dokument wird so entschieden, welche Pflicht gewinnt, statt eine der beiden pauschal zu verletzen.

Besondere Kategorien verschärfen das: Gesundheits-, Schwerbehinderten- und Hinweisgeber-Daten dürfen nach DSGVO Art. 9 und Paragraph 178 SGB IX nicht in der Stammakte liegen. Dass eine Liste über Beschäftigte mit Gesundheitsangaben ohne Rechtsgrundlage teuer wird, ist kein theoretisches Risiko - eine Berliner Aufsichtsbehörde verhängte dafür ein Bußgeld von 215.000 Euro ([Datenschutzbeauftragte Berlin](https://www.datenschutz-berlin.de/pressemitteilung/informationen-ueber-beschaeftigte-in-der-probezeit/)). Der Agent trennt solche Akten regelbasiert und beteiligt die Schwerbehindertenvertretung dort, wo das Gesetz es vorschreibt.

## Über dem bestehenden Archiv, nicht statt seiner

Der Agent konkurriert nicht mit Ihrem Archiv- oder HR-System. Gegen DocuWare, ELO, SAP oder Personio auf der Ablage-Achse anzutreten wäre aussichtslos - dort entscheiden Speicher, Suche und Integration. Der Agent legt sich als Entscheidungs- und Nachweis-Schicht darüber: Die Dokumente bleiben, wo sie liegen, und er macht nachweisbar, wer welche Zuordnung, Frist und Löschung verantwortet hat.

Was hinzukommt, ist kein weiteres System, sondern die Antwort auf die zwei Fragen, an denen die Personalakte hängt. Auf die Betriebsprüfung: Jede Akte ist mit Typ, Frist und Rechtsgrundlage hinterlegt und bis zur Quelle rückverfolgbar. Auf den Betriebsrat: Weil eine Personalakte mit Audit-Trail nach Paragraph 87 Abs. 1 Nr. 6 BetrVG mitbestimmungspflichtig ist, kann er die Einführung über die Einigungsstelle blockieren - und genau die offengelegte Rollen- und Zugriffs-Governance ist das, was eine Betriebsvereinbarung unterschreibbar macht. Wettbewerber verkaufen Effizienz; diese Schicht macht die Akte zustimmungsfähig.

Der nächste Schritt ist keine Software-Einführung, sondern eine Bestandsaufnahme: Wo in Ihrem Personalakten-Prozess werden Fristen heute pauschal gesetzt, und wer könnte vor Betriebsrat und Betriebsprüfer belegen, wer die letzte Löschung verantwortet hat?

## Auf einen Blick

- **Was er tut**: ordnet HR-Dokumente einer Akte zu, weist je Typ die richtige Aufbewahrungsfrist zu und steuert Auskunft und Löschung - jeder Schritt unveränderbar protokolliert
- **Klassifikation**: kein EU-AI-Act-Hochrisiko-System (Dokumentenverarbeitung, keine Bewertung von Menschen)
- **Entscheidungslogik**: KI klassifiziert vor, ein Regelwerk setzt Fristen und Rechte, der Mensch gibt jede Löschung frei
- **Compliance-Anker**: DSGVO Art. 15, 17 und 22, Paragraph 83 und Paragraph 87 BetrVG, Aufbewahrung nach Paragraph 147 AO und Paragraph 41 EStG
- **Aktualitäts-Beweis**: Buchungsbelege seit dem 1.1.2025 acht Jahre statt zehn - zentral im Fristenkatalog nachgezogen
- **Integration**: Schicht über DocuWare, ELO, SAP SuccessFactors oder Personio - kein Ersatz

--- Interview-Scheduling-Agent ---
> Interview-Terminierung über mehrere Kalender, jeder Schritt prüfbar protokolliert - die Auswahlentscheidung bleibt beim Menschen. Hochrisiko-konform.

## Tempo gewinnt im Recruiting kein Bewerbungsverfahren, die richtige Grenze der Automatisierung schon.

Die Terminierung von Bewerbungsgesprächen lässt sich stark beschleunigen, und der Druck ist real: Bewerber warten in Deutschland 2025 im Schnitt rund 24 Arbeitstage vom Erstkontakt bis zur Vertragsunterzeichnung ([Stepstone](https://www.stepstone.de/e-recruiting/hr-wissen/recruiting/time-to-hire-berechnen-durchschnitt/)); branchenübergreifend im deutschsprachigen Raum dauert eine Neubesetzung im Mittel sogar rund 70 Kalendertage ([Haufe](https://www.haufe.de/personal/hr-management/time-to-hire-eine-relevante-kennzahl-im-recruiting_80_563966.html), Xing Bewerbungsreport 2025). Doch jede KI im Bewerbungsprozess ist ein Hochrisiko-System nach EU AI Act und ein mitbestimmungspflichtiges Kontrollinstrument nach Betriebsverfassungsgesetz. Dieser Agent terminiert schnell und sortiert vor, überlässt aber jede Entscheidung mit Rechtsfolge dem Menschen - und macht damit aus dem größten Rechtsrisiko ein Verkaufsargument.

## Warum ist die Interview-Phase ein Rechtsthema, kein Tool-Thema?

Der Flaschenhals im Recruiting ist messbar. Die Interview-Phase mit ihren vielen Kalendern und Beteiligten ist ein Hauptgrund dafür, dass Stellen so lange offen bleiben - wer hier beschleunigt, gewinnt spürbar Zeit und die gefragten Kandidaten.

Doch genau hier liegt die Falle, die marktübliche Scheduler verschweigen. Sobald eine KI Bewerbungen vorsortiert oder bewertet, greift Annex III des EU AI Act und stuft das System als Hochrisiko ein - mit Pflichten zu Risikomanagement, Daten-Governance und menschlicher Aufsicht. Parallel verbietet Artikel 22 DSGVO die rein automatisierte Ablehnung eines Bewerbers. Ein Konkurrenz-Tool, das mit vollautomatischem Bewerber-Ranking wirbt, macht Sie damit nicht schneller, sondern klagbar. Tempo allein ist deshalb kein Wert, wenn es die rechtliche Grenze überschreitet. Die entscheidende Frage ist nicht, wie schnell der Agent terminiert, sondern wer jede Entscheidung verantwortet.

## Wer entscheidet was, und warum ist das Haftungsarchitektur?

Die Verantwortung folgt einem einzigen Prinzip: Was gesetzlich festgelegt ist, entscheidet das Regelwerk. Was sich optimieren lässt, schlägt der Agent als Indikator vor. Was Rechtsfolge hat, entscheidet der Mensch. Diese Trennung ist kein Marketing, sondern die direkte Antwort auf Artikel 22 DSGVO und die Aufsichtspflichten des EU AI Act - sie ist Haftungsarchitektur, nicht Komfort. Das [Decision Layer](/de/decision-layer/) erzwingt diese Grenze technisch.

Die Slot-Optimierung über mehrere Kalender und die Vorsortierung eingehender Bewerbungen liefert der Agent ausschließlich als Vorschlag. Die Zeitzonen-Logik, diskriminierungsfreie Ausschreibungstexte und der Filter verbotener Fragen laufen deterministisch über das Regelwerk. Die Bewertung und Ablehnung jedes Bewerbers sowie die Zustimmung des Betriebsrats bleiben menschliche Entscheidungen. Genau diese prüfbare Zuordnung pro Schritt unterscheidet die Lösung von Wettbewerbern, die eine Voll-Automatik versprechen, welche rechtlich gar nicht zulässig ist.

## Wie wird der Agent betriebsratsfähig?

Ohne den Betriebsrat ist ein solches System praktisch nicht einsetzbar, und das entscheidet sich vor dem ersten Termin. Schon die Eignung einer Technik zur Leistungs- und Verhaltenskontrolle löst die Mitbestimmung nach Paragraph 87 BetrVG aus; auf eine Überwachungsabsicht kommt es nicht an, das gilt nach gefestigter Rechtsprechung selbst für einen Gruppenkalender. Ohne Betriebsvereinbarung droht das Einigungsstellen-Verfahren und im Ergebnis der Stopp des Projekts.

Deshalb ist der Agent von Beginn an auf Zustimmungsfähigkeit ausgelegt: seine Funktionsweise ist transparent beschreibbar, seine Grenzen sind im Decision-Layer fixiert, und jeder Schritt ist protokolliert. Eine Betriebsvereinbarung zu Funktionsweise und Grenzen wird damit verhandelbar, statt an der Unsicherheit des Gremiums zu scheitern. So entsteht eine Lösung, die der Betriebsrat mittragen kann, bevor sie dem Vorstand vorgelegt wird.

## Was schützt vor der AGG-Beweislast-Falle?

Im Bewerbungsverfahren kehrt das Allgemeine Gleichbehandlungsgesetz die Beweislast um: Liegen Indizien für eine Benachteiligung vor, muss der Arbeitgeber beweisen, dass nicht diskriminiert wurde. Ein lückenloser, nachvollziehbarer Audit-Trail der Terminierungs- und Auswahl-Schritte ist genau dieses Gegenmittel. Das Bundesarbeitsgericht beziffert die Entschädigung im Normalfall mit rund 1,5 Bruttomonatsgehältern ([Urteil vom 28.05.2020](https://www.hensche.de/bag-eine-entschaedigung-von-1-5-gehaeltern-ist-im-normalfall-angemessen-bei-einer-diskriminierung-von-stellenbewerbern-bag-urteil-vom-28.05.2020-8-azr-170-19.html)).

Dass die Transparenz-Pflichten bei automatisierten Einzelentscheidungen real durchgesetzt werden, zeigt ein vielbeachtetes deutsches Bußgeld in diesem Kontext: 300.000 Euro gegen eine Bank, weil sie eine automatisierte Ablehnung - es ging um einen Kreditkartenantrag - nicht nachvollziehbar begründen konnte, also nicht wegen der Ablehnung selbst, sondern wegen mangelnder Transparenz (Artikel 22 Absatz 3, Artikel 15 DSGVO) ([dr-datenschutz.de](https://www.dr-datenschutz.de/bussgeld-gegen-bank-mangelnde-transparenz-als-grund/)). Dieselbe Begründungs- und Transparenzpflicht trifft die Ablehnung eines Bewerbers. Der Agent protokolliert jeden Vorschlag, jede Regel und jede menschliche Freigabe automatisch. Damit wird der Prozess rückverfolgbar, ohne dass das Recruiting zusätzliche Dokumentation pflegen muss - der Audit-Trail ist zugleich Beweismittel nach Gleichbehandlungsgesetz und Logging-Nachweis nach EU AI Act.

## Wie fügt sich der Agent in bestehende Systeme ein?

Der Agent ersetzt keine Kalender- oder Recruiting-Software, sondern legt sich als Koordinations- und Entscheidungsschicht darüber. Das bestehende Bewerbermanagement bleibt das führende System, Outlook, Microsoft Teams und Google Calendar bleiben die Quelle der Verfügbarkeiten. Der Agent automatisiert den zeitaufwändigen Abgleich dazwischen und macht die Verantwortungs-Zuordnung sichtbar.

Diese Positionierung als Schicht über den bestehenden Systemen bedeutet, dass etablierte Recruiting-Prozesse nicht aufgegeben werden müssen; der Umstieg ist additiv, nicht disruptiv. Fordern Sie als nächsten Schritt eine Analyse Ihres Recruiting-Prozesses an, die die konkreten Engpässe, die Mitbestimmungs-Berührungspunkte und das zulässige Automatisierungspotenzial bestimmt.

--- HR-Vendor-Rechnungen-Agent ---
> Verarbeitet HR-Lieferanten-Rechnungen: StellenAnzeiger, Headhunter, Trainings-Anbieter, bAV-Provider. Ordnet Personal-Kostenstellen zu, prüft BetrVG §99-Mitbestimmung, kontiert nach SKR03/04.

## Manuelle Rechnungserfassung kostet 10-15 EUR pro Vorgang - und verschenkt Skonto obendrein

Eine einzige Eingangsrechnung manuell zu verarbeiten kostet zwischen 10 und 15 EUR. Bei 500 Rechnungen pro Woche sind das über 300.000 EUR Prozesskosten im Jahr - bevor eine einzige Rechnung falsch kontiert oder ein Skonto verpasst wurde. Laut Ardent Partners erreichen nur 21% der Unternehmen ohne Automatisierung akzeptable Skonto-Ausschöpfungsraten. Die restlichen 79% zahlen den vollen Betrag, weil die Rechnung noch im Freigabeumlauf lag, als die Frist ablief.

Der eigentliche Schaden liegt nicht in den offensichtlichen Erfassungskosten. Er liegt in den Folgekosten: falsche Kontierung erzeugt Korrekturbuchungen, fehlender Bestellbezug löst Rückfragen beim Einkauf aus, verspätete Zahlungen verschlechtern Lieferantenkonditionen. Jede dieser Nacharbeiten bindet Kapazität im Accounting-Team, die für Abschlussarbeiten und Analyse fehlt.

## Ein automatischer Drei-Wege-Abgleich reduziert die Fehlerquote von 12% auf nahe null

Der Drei-Wege-Abgleich - Rechnung gegen Bestellung gegen Wareneingang - ist der Kern jeder ordnungsgemäßen Rechnungsprüfung. Manuell durchgeführt ist er fehleranfällig: 10-15% aller Rechnungen enthalten Abweichungen bei Mengen, Preisen oder Konditionen, die ein menschlicher Prüfer unter Zeitdruck übersieht oder falsch bewertet. Automatisierte Systeme führen diesen Abgleich in Sekunden durch und wenden dabei definierte Toleranzregeln konsistent auf jede einzelne Position an.

Das bedeutet konkret: Eine Rechnung über 4.780 EUR wird gegen die Bestellposition von 4.800 EUR geprüft. Die Abweichung von 0,4% liegt innerhalb der definierten Toleranz von 2% - der Agent gibt frei. Eine zweite Rechnung weicht um 8% ab - der Agent eskaliert an den zuständigen Kostenstellenverantwortlichen. Kein Ermessensspielraum, keine Inkonsistenz zwischen Sachbearbeitern, keine vergessene Prüfung am Freitagnachmittag.

Die Kontierung folgt dem gleichen Prinzip. Statt dass ein Sachbearbeiter das Sachkonto nachschlägt, leitet ein Regelwerk die Kontierung aus der Bestellung ab. Bei Rechnungen ohne Bestellbezug schlägt der Agent auf Basis historischer Buchungsmuster ein Konto vor - die finale Bestätigung bleibt beim Menschen.

## Der [Decision Layer](/de/decision-layer/) trennt Routinefreigaben von Entscheidungen, die Urteil erfordern

Der Decision Layer zerlegt den Rechnungsprozess in einzelne Entscheidungsschritte und definiert für jeden Schritt: Mensch, Regelwerk oder KI. Diese Zerlegung macht den Unterschied zwischen einer Automatisierung, die 60% der Rechnungen abdeckt, und einer, die 95% erreicht.

Datenextraktion - Lieferant, Betrag, Rechnungsnummer, Positionen - ist eine KI-Aufgabe. Die Erkennungsrate liegt bei strukturierten Rechnungen (PDF, EDI, ZUGFeRD) zwischen 92 und 98%. Der Drei-Wege-Abgleich und die Kontierung sind Regelwerk-Aufgaben mit definierten Schwellenwerten. Das Freigabe-Routing folgt einer Betragsmatrix: Rechnungen unter 5.000 EUR an den Teamleiter, über 50.000 EUR an die Geschäftsführung.

Der Mensch bleibt dort, wo Recht es verlangt - nicht weil er es besser kann. GoBD-konforme Buchführung erfordert die Nachvollziehbarkeit jeder Entscheidung. Der Agent protokolliert jeden Schritt mit Begründung und Zeitstempel. Bei steuerlich relevanten Abweichungen - etwa einer Rechnung ohne gültige USt-IdNr. - eskaliert er an einen qualifizierten Prüfer, statt selbst zu entscheiden.

## Rechnungsverarbeitung liefert den schnellsten ROI im gesamten Agent-Portfolio

Kein anderer Agent kombiniert so hohen Durchsatz mit so niedriger Governance-Komplexität. Rechnungsverarbeitung ist kein Hochrisiko-System nach EU AI Act, erfordert keine Betriebsratsbeteiligung und betrifft keine personenbezogenen Beschäftigtendaten. Gleichzeitig verarbeitet ein mittelständisches Unternehmen mit 200 Mitarbeitern leicht 300-800 Rechnungen pro Monat - jede einzelne ein messbarer Sparvorgang.

Die Rechnung ist einfach: Sinken die Prozesskosten pro Rechnung von 12 EUR auf 3 EUR und steigt die Skonto-Ausschöpfung von 20% auf 75%, amortisiert sich der Agent bei 500 Rechnungen pro Monat innerhalb weniger Monate. Highradius beziffert die durchschnittliche Kostenreduktion durch AP-Automatisierung auf 78% - von 13,54 USD auf 2,98 USD pro Rechnung.

Die E-Rechnungspflicht ab 2025 verstärkt diesen Effekt. Seit Januar 2025 müssen B2B-Unternehmen in Deutschland E-Rechnungen im strukturierten Format empfangen können. Strukturierte Formate wie ZUGFeRD und XRechnung liefern maschinenlesbare Daten, die die Erkennungsrate weiter steigern und die manuelle Nacherfassung auf Ausnahmefälle reduzieren. Wer jetzt automatisiert, nutzt die regulatorische Umstellung als Beschleuniger statt als zusätzliche Belastung.

--- Stellenanzeigen-Agent ---
> Erstellt AGG-konforme Stellenanzeigen aus Anforderungsprofilen und koordiniert die Veröffentlichung. Hochrisiko-System nach EU AI Act.

Drei Recruiter, drei Formulierungen, drei Risikoniveaus. So sieht die Realität bei Stellenanzeigen aus, wenn zwanzig offene Positionen gleichzeitig besetzt werden müssen. Die eine Anzeige spricht von einem "jungen, dynamischen Team" - ein AGG-Verstoß, der vor Gericht bis zu drei Bruttomonatsgehälter als Entschädigung kosten kann. Die nächste vergisst die Gehaltsangabe, die ab Juni 2026 durch die EU-Entgelttransparenzrichtlinie zur Pflicht wird. Die dritte ist fachlich korrekt, aber so generisch, dass sie in den 2.000 deutschen Jobportalen untergeht. Und alle drei wurden manuell auf drei verschiedenen Kanälen geschaltet, weil niemand weiß, welcher Kanal für welche Position den besten Return liefert.

Das ist kein Qualitätsproblem einzelner Recruiter. Das ist ein Systemproblem.

## Das dreifache Risiko jeder einzelnen Anzeige

Stellenanzeigen sind das verwundbarste Artefakt im gesamten Recruiting-Prozess. Sie sind gleichzeitig Rechtsdokument, Budgetposten und Visitenkarte - und in den meisten Organisationen wird keines dieser drei systematisch gesteuert.

**Rechtsrisiko: AGG heute, Entgelttransparenz ab morgen.** Jede diskriminierende Formulierung öffnet einen Haftungsfall. "Deutsch als Muttersprache" statt "ausgezeichnete Deutschkenntnisse" - der Unterschied liegt bei einer AGG-Klage. Bei fünfzig offenen Stellen pro Jahr und durchschnittlich zwanzig Bewerbungen pro Stelle reicht ein einziger systematischer Formulierungsfehler, um fünfstellige Schadenssummen auszulösen. Ab Juni 2026 verschärft die EU-Entgelttransparenzrichtlinie die Anforderungen zusätzlich: Jede Stellenausschreibung muss eine konkrete Gehaltsspanne enthalten. Wer diese Angabe vergisst oder inkonsistent handhabt, riskiert Sanktionen und verliert das Vertrauen der Kandidaten, bevor das erste Gespräch stattfindet.

**Kostenproblem: Streuung ohne Steuerung.** Die durchschnittlichen Kosten pro Einstellung liegen in Deutschland zwischen 4.700 und 5.500 Euro - je nach Quelle und Branche. Ein erheblicher Teil davon fließt in Stellenanzeigen, die auf den falschen Kanälen laufen. Klassische Einzelbuchungen auf Jobbörsen kosten 1.000 bis 1.300 Euro pro Anzeige. Wer fünf Kanäle gleichzeitig bespielt, gibt schnell über 5.000 Euro pro Stelle nur für die Veröffentlichung aus - ohne zu wissen, welcher Kanal die qualifizierten Bewerbungen liefert und welcher nur Klicks produziert.

**Qualitätsproblem: Inkonsistenz als Employer-Branding-Killer.** Wenn dieselbe Position in drei Varianten auf dem Markt erscheint - einmal mit Bullet Points, einmal als Fließtext, einmal mit veralteten Benefits - signalisiert das organisatorische Beliebigkeit. Bei durchschnittlich 164 Tagen Vakanzzeit für Fachkräftepositionen in Deutschland zählt jeder Tag, an dem eine schlecht formulierte Anzeige die falschen Kandidaten anzieht oder die richtigen abschreckt.

## Wo manuelle Prozesse versagen

Die typische Prozesskette einer Stellenanzeige sieht so aus:

```
Fachabteilung            Recruiting              Freigabe
──────────────           ──────────              ────────
Anforderung    ──────>   Texten       ──────>    Prüfung
(oft formlos)            (je nach                (oft nur
                          Recruiter               inhaltlich,
                          anders)                 nicht AGG)
                              │
                              v
                         Manuelles Posten
                         (3-5 Portale,
                          Copy & Paste)
```

Jeder Pfeil in diesem Diagramm ist eine Fehlerquelle. Die Anforderung kommt als E-Mail ohne Struktur. Der Text entsteht unter Zeitdruck ohne Rückgriff auf die Employer-Brand-Richtlinie. Die Prüfung erfolgt inhaltlich, aber nicht juristisch. Das Posten passiert manuell - und die Performance wird nie systematisch ausgewertet.

Das Resultat: 164 Tage durchschnittliche Vakanzzeit, weil die Anzeige drei Wochen zu spät live ging, auf zwei von fünf relevanten Kanälen fehlte und eine Formulierung enthielt, die qualifizierte Kandidatinnen über vierzig aussortierte.

## Drei Prüfschichten fangen AGG-Risiken ab, bevor ein Recruiter den Entwurf sieht

Ein Stellenanzeigen-Agent ersetzt nicht den Recruiter. Er ersetzt die Zufälligkeit. Aus einem strukturierten Anforderungsprofil wird ein Anzeigenentwurf generiert, der drei Prüfschichten durchläuft, bevor ein Mensch ihn sieht:

Erste Schicht: AGG-Konformität. Jede Formulierung wird gegen einen Prüfkatalog abgeglichen - geschlechtsneutrale Sprache, keine Altersdiskriminierung, keine mittelbare Benachteiligung durch Sprachanforderungen. Das ist kein stilistischer Vorschlag, sondern eine harte Regel. Was nicht besteht, geht nicht weiter.

Zweite Schicht: Entgelttransparenz. Gehaltsspannen werden aus den hinterlegten Vergütungsbändern gezogen und in das vorgeschriebene Format gebracht. Konsistent über alle Anzeigen, alle Kanäle, alle Sprachen. Keine Abweichung, kein Vergessen.

Dritte Schicht: Kanaloptimierung. Welche Portale für welche Position, welche Region, welches Senioritätslevel die besten Conversion-Raten liefern, wird regelbasiert entschieden - nicht nach Bauchgefühl. Die Performance-Daten fließen zurück und verbessern die Kanalauswahl für die nächste Ausschreibung.

Erst dann sieht der Recruiter den Entwurf. Und prüft das, was nur ein Mensch prüfen kann: Stimmt die Tonalität? Passt die Beschreibung zur tatsächlichen Teamkultur? Gibt es fachliche Nuancen, die nur jemand kennt, der mit der Fachabteilung gesprochen hat?

## Was das für die Recruiting-Leitung bedeutet

Die Frage ist nicht, ob Stellenanzeigen automatisiert werden. Die Frage ist, ob sie als Infrastruktur behandelt werden - mit Governance, Versionierung und Audit Trail - oder ob sie Zufallsprodukte bleiben, die bei der nächsten AGG-Klage oder der ersten Entgelttransparenz-Prüfung zum Haftungsfall werden.

Der Unterschied zwischen einer Organisation, die das gelöst hat, und einer, die es nicht hat, zeigt sich nicht im einzelnen Anzeigentext. Er zeigt sich in der Fähigkeit, auf die Frage "Wie stellen Sie sicher, dass alle Ihre Stellenanzeigen die Entgelttransparenzrichtlinie einhalten?" eine systemische Antwort zu geben statt "Das prüft jeder Recruiter selbst."

Ein [Decision Layer](/de/decision-layer/) macht jeden Schritt nachvollziehbar: welche Regeln angewendet wurden, welche Prüfungen bestanden oder nicht bestanden haben, wer freigegeben hat. Nicht als nachträgliche Dokumentation, sondern als integraler Bestandteil des Prozesses. Bei einem Hochrisiko-System nach EU AI Act - und genau das ist ein Agent, der beeinflusst, wer Stellenanzeigen zu sehen bekommt - ist diese Nachvollziehbarkeit keine Option, sondern Pflicht.

--- Lernveranstaltungs-Management Agent ---
> Koordiniert die Logistik von Schulungen: Raumplanung, Trainer-Buchung, Teilnehmerverwaltung und Materialbeschaffung - termingerecht.

Eine L&D-Abteilung, die 30 Schulungsveranstaltungen pro Monat koordiniert, löst kein Lernproblem. Sie löst ein Logistikproblem. Räume gegen Teilnehmerzahlen abgleichen, Trainer-Verfügbarkeit prüfen, Materialien rechtzeitig bestellen, Wartelisten pflegen, Stornierungen verarbeiten, Erinnerungen versenden, Evaluierungen nachhalten. Jede einzelne Aufgabe ist trivial. In Summe binden sie 40 bis 60 Prozent der operativen L&D-Kapazität - Kapazität, die weder in Programmgestaltung noch in Wirkungsmessung fließt.

Und das Problem wird nicht besser, wenn die Organisation wächst. Es wird proportional schlimmer.

## Warum Spreadsheets das Problem nicht lösen, sondern sind

In den meisten Organisationen zwischen 500 und 5.000 Mitarbeitenden sieht die Event-Koordination so aus: Eine Excel-Tabelle mit Terminen, eine zweite mit Trainer-Verfügbarkeiten, eine dritte mit Raumbelegungen. Dazwischen E-Mails, Kalendereinladungen und mündliche Absprachen. Dieses System hat drei strukturelle Schwächen, die sich nicht durch bessere Tabellen beheben lassen.

**Erstens: Multi-Ressourcen-Konflikte.** Jedes Schulungsevent verknüpft mindestens vier Ressourcen - Raum, Trainer, Teilnehmergruppe, Materialien. Wenn ein Workshop für 20 Personen einen Raum mit Beamer braucht, aber der einzige passende Raum an diesem Tag für ein Führungskräfte-Seminar reserviert ist, beginnt eine Umplanungskette. Trainer-Kalender verschieben sich, Teilnehmer müssen neu eingeladen werden, Materialbestellungen stimmen nicht mehr. In einer Tabelle sieht man den Konflikt erst, wenn er eingetreten ist. Nicht vorher.

**Zweitens: Stornierungskaskaden.** Die durchschnittliche Stornierungsrate bei Classroom-Trainings liegt bei 17 Prozent. Bei einem Workshop mit 20 Plätzen fehlen also im Schnitt drei bis vier Teilnehmer. Wenn eine Warteliste existiert, muss jemand manuell nachrücken, den nachgerückten Teilnehmer informieren, prüfen, ob die Materialien reichen, und den Trainer über die veränderte Gruppenzusammensetzung benachrichtigen. Wenn keine Warteliste existiert, bleiben die Plätze leer - und die Kosten pro Kopf steigen, denn Raum und Trainer sind bereits gebucht.

**Drittens: unsichtbare Kosten.** Ein ganztägiges Präsenz-Training für 20 Teilnehmer kostet zwischen 5.000 und 15.000 Euro - Trainer, Raum, Materialien, Teilnehmer-Arbeitszeit eingerechnet. Bei 30 Events pro Monat steuert die L&D-Abteilung ein sechsstelliges Monatsbudget. Trotzdem weiß sie oft nicht, welche Events ausgelastet waren, welche chronisch unterbucht sind und welche Trainer die besten Evaluierungen erhalten. Denn diese Daten liegen in verschiedenen Tabellen, und niemand hat Zeit, sie zusammenzuführen.

## Was der [Decision Layer](/de/decision-layer/) anders macht

Die Pointe bei der Trainingslogistik: Fast jeder Koordinationsschritt folgt klaren Regeln. Format ergibt sich aus Schulungstyp und Teilnehmerzahl. Erinnerungen gehen zu festen Zeitpunkten raus. Stornierungsregeln hängen von der Vorlaufzeit ab. Wartelisten-Nachrücken folgt einer Reihenfolge. Evaluierungen werden am Tag nach dem Event versendet.

Das ist kein Zufall. Es ist der Grund, warum dieser Agent im H2-Horizont steht: hohe Transaktionsfrequenz, niedrige Entscheidungskomplexität.

```
Schritt                    Wer entscheidet    Warum
─────────────────────────  ─────────────────  ──────────────────────────────
Event-Format festlegen     Regelwerk          Typ + Kapazität determinieren Format
Trainer identifizieren     Agent              Qualifikations-Match + Kalenderabgleich
Raum zuweisen              Agent              Kapazität, Ausstattung, Verfügbarkeit
Teilnehmer einladen        Regelwerk          Liste aus Bedarfsanalyse oder Anmeldung
Material bestellen         Regelwerk          Checkliste nach Event-Typ
Erinnerungen senden        Regelwerk          7 Tage + 1 Tag vor Event
Warteliste nachrücken      Regelwerk          Reihenfolge bei Absage
Evaluierung auslösen       Regelwerk          Tag nach Event
Stornierung verarbeiten    Regelwerk          Frist-abhängige Stornierungsregeln
```

Sieben von neun Schritten sind deterministische Regelwerk-Entscheidungen. Nur zwei - Trainer-Identifikation und Raumzuweisung - erfordern eine Agent-Logik, die mehrere Variablen gleichzeitig optimiert: Qualifikation gegen Verfügbarkeit, Kapazität gegen Ausstattung. Kein Schritt erfordert eine menschliche Einzelfallentscheidung.

## Wie sich der Alltag der L&D-Abteilung verändert

Wenn die Systeme stehen - LMS mit Event-Funktion, Raumverwaltung, Trainer-Pool mit Kalenderdaten - verändert sich die operative Arbeit an drei Stellen.

Die Planungszeit pro Event sinkt von Stunden auf Minuten. Statt manuell Kalender abzugleichen, Räume zu prüfen und Trainer anzuschreiben, gibt die L&D-Leitung Schulungstyp, Zielgruppe und Zeitraum ein. Der Agent liefert einen vollständigen Vorschlag: Trainer, Raum, Zeitslot, Materialliste. Passt der Vorschlag, wird er mit einem Klick bestätigt. Passt er nicht, werden die Constraints angepasst und ein neuer Vorschlag generiert.

Stornierungen und Umplanungen verlieren ihre operative Wucht. Bei einer Trainer-Absage sucht der Agent sofort nach qualifizierten Ersatztrainern mit freiem Kalender. Bei Teilnehmer-Stornierungen rückt die Warteliste automatisch nach - inklusive Benachrichtigung, Materialanpassung und aktualisierter Teilnehmerliste. Die manuelle Kaskade aus Rückfragen, Gegenvorschlägen und aktualisierten Einladungen entfällt.

Die L&D-Abteilung bekommt Steuerungsdaten, die vorher nicht existierten. Auslastungsquoten pro Schulungsformat, Stornierungsmuster nach Abteilung und Wochentag, Trainer-Evaluierungen im Zeitverlauf, durchschnittliche Kosten pro Teilnehmer und Schulungstyp. Nicht als aufwändige Quartalsauswertung, sondern als laufendes Reporting, das aus den Buchungsdaten automatisch entsteht. Diese Daten machen den Unterschied zwischen einer L&D-Abteilung, die Events abwickelt, und einer, die ihr Portfolio aktiv steuert.

## Der Infrastruktur-Effekt

Die Event-Koordinations-Engine - Raum, Personen, Material, Zeitplanung gegen Verfügbarkeit optimieren - ist kein Einzelstück. Derselbe Mechanismus, der einen Workshop plant, kann ein Onboarding-Event orchestrieren, ein Assessment-Center terminieren oder eine Betriebsversammlung koordinieren. Das Wartelisten-Pattern wird zum Baustein für jeden Agenten mit kapazitätsbeschränkten Ressourcen.

Und jede Buchung, jede Stornierung, jede Umplanung wird im Decision Log protokolliert. Der Betriebsrat, der nach Paragraph 98 BetrVG bei der Durchführung betrieblicher Bildungsmaßnahmen mitbestimmt, sieht nicht eine zusammengefasste Jahresplanung, sondern die dokumentierte Entscheidungsgrundlage jedes einzelnen Events. Transparenz, die Mitbestimmung einfacher macht - weil die Daten bereits strukturiert vorliegen.

Wer 30 Events pro Monat manuell koordiniert, verwaltet. Wer sie automatisiert koordinieren lässt, steuert.

--- Lernpfad-Empfehlungs-Agent ---
> Empfiehlt individuelle Lernpfade basierend auf Kompetenzprofil, Karrierezielen und verfügbarem Lernangebot - unverbindlich.

## Das zentrale Problem: volle Kataloge, leere Kursräume

Die meisten Organisationen haben kein Angebotsdefizit. Sie haben ein Zuordnungsproblem. Ein typisches LMS im Mittelstand enthält mehrere hundert Kurse, Module und Zertifizierungspfade. Gleichzeitig liegt die durchschnittliche Abschlussquote bei Selbstlern-Formaten zwischen 5 und 15 Prozent. 44 Prozent der Unternehmen sind mit ihrem LMS unzufrieden, 37 Prozent suchen aktiv nach Alternativen. Das Lernangebot wächst, die Nutzung stagniert.

Der Engpass ist nicht der Inhalt. Der Engpass ist die Frage: Welcher Kurs bringt genau dieser Person in genau dieser Rolle den größten Entwicklungsfortschritt?

Diese Frage manuell zu beantworten überfordert jede L&D-Abteilung. Eine Führungskraft mit zwölf direkten Mitarbeitenden müsste pro Person Kompetenzprofil, Karriereziel, absolvierte Schulungen und verfügbare Angebote abgleichen. Bei 800 Mitarbeitenden und 400 Kursangeboten entstehen Hunderttausende möglicher Kombinationen. Kein Mensch navigiert das zuverlässig. Das Ergebnis: Empfehlungen nach Bauchgefühl, Weiterbildung nach Gießkanne, Budgets ohne Wirkungsnachweis.

## Was ein Empfehlungs-Agent strukturell verändert

Ein Lernpfad-Empfehlungs-Agent löst dieses Zuordnungsproblem nicht durch mehr Technologie, sondern durch bessere Entscheidungsarchitektur. Der Ablauf folgt einer klaren Kette:

```
Ist-Profil          Ziel-Profil         Lücke           Angebot
┌──────────┐      ┌──────────┐      ┌──────────┐    ┌──────────┐
│ Kompe-   │      │ Zielrolle│      │ Gap-     │    │ Matching │
│ tenzen,  │─────▶│ oder     │─────▶│ Analyse  │───▶│ gegen    │
│ Kurse,   │      │ nächster │      │ Ist vs.  │    │ Katalog  │
│ Rolle    │      │ Schritt  │      │ Soll     │    │          │
└──────────┘      └──────────┘      └──────────┘    └──────────┘
     A                 H                 A                A

A = Agent entscheidet    H = Mensch entscheidet
```

Der entscheidende Punkt: Die Zielrolle bleibt beim Menschen. Der Mitarbeitende definiert im Entwicklungsgespräch, wohin die Reise geht. Alles davor und danach - Profilanalyse, Soll-Profil-Ermittlung, Lückenberechnung, Angebotsfilterung, Format- und Anbieterwahl, Budget- und Zeitprüfung, Priorisierung - kann ein Agent schneller, vollständiger und konsistenter leisten als jede manuelle Recherche.

Personalisierte Lernpfade steigern die Abschlussquote nachweislich um rund 30 Prozent. Nicht weil der Inhalt besser wird, sondern weil die Passung stimmt. Wer genau die Module sieht, die seine konkrete Kompetenzlücke adressieren, investiert Lernzeit mit sichtbarem Ertrag.

## Warum das im Mittelstand besonders relevant ist

In Organisationen zwischen 500 und 5.000 Mitarbeitenden treffen zwei Realitäten aufeinander. Einerseits: 81,8 Prozent der Unternehmen berichten, dass Mitarbeitende zu wenig Freiraum für Weiterbildung haben. Andererseits: 42,9 Prozent benennen unzureichende Personalisierung als Kernproblem ihrer L&D-Strategie.

Wenig Zeit und schlechte Trefferquote - das ist die toxische Kombination. Wenn ein Mitarbeitender pro Quartal vier Stunden für Weiterbildung hat, darf keine davon in einem irrelevanten Kurs versickern. Jede Empfehlung muss sitzen.

Großkonzerne lösen das mit dedizierten L&D-Teams, die individuelle Entwicklungspläne erstellen. Im Mittelstand fehlt diese Kapazität. Drei Personalentwickler für 2.000 Mitarbeitende können keine 2.000 individuellen Lernpfade kuratieren. Aber ein Agent kann es - und zwar wöchentlich aktualisiert, nicht einmal im Jahr beim Entwicklungsgespräch.

## Nachvollziehbarkeit statt Blackbox

Eine häufige Sorge bei algorithmengestützten Empfehlungen: Warum genau dieses Angebot? Der [Decision Layer](/de/decision-layer/) protokolliert jeden Entscheidungsschritt. Welche Daten flossen ein, welche Gewichtung wurde angewendet, warum wurde Kurs A vor Kurs B priorisiert. Diese Transparenz ist keine regulatorische Pflicht - Lernpfad-Empfehlungen sind kein Hochrisiko-System nach EU AI Act, solange sie unverbindlich bleiben. Aber sie ist operativ entscheidend.

Wenn ein Betriebsrat fragt, nach welchen Kriterien Empfehlungen zustande kommen, gibt es eine dokumentierte Antwort. Wenn eine Führungskraft eine Empfehlung hinterfragt, liegt die Begründung vor. Und wenn ein Mitarbeitender die Empfehlung ablehnt, bleibt das ohne Konsequenz - es ist ein Vorschlag, keine Zuweisung.

## Der Infrastruktur-Effekt

Das Empfehlungs-Framework arbeitet nicht isoliert. Profil-Analyse, Gap-Berechnung und Angebots-Matching bilden ein wiederverwendbares Fundament. Derselbe Mechanismus, der Lernpfade empfiehlt, kann Karrierepfade bewerten, Nachfolge-Kandidaten identifizieren oder strategische Kompetenzlücken auf Organisationsebene sichtbar machen.

Jede Empfehlung erzeugt dabei Daten: Welche Lücken treten gehäuft auf? Welche Angebote werden angenommen, welche ignoriert? Welche Abteilungen entwickeln sich schneller als andere? Diese Daten fließen zurück in die Planung - nicht als Kontrollinstrument über Einzelpersonen, sondern als strategische Steuerungsgröße für die Weiterbildungsplanung.

Der Unterschied zu einem besseren LMS-Filter: Ein Filter zeigt Kurse, die passen könnten. Ein Empfehlungs-Agent begründet, warum genau dieser Kurs genau jetzt den größten Hebel hat - und liefert den Audit Trail gleich mit.

--- Abwesenheits-Agent ---
> Verarbeitet Anträge auf Elternzeit, Sabbatical und Sonderurlaub - prüft Ansprüche, berechnet Fristen und koordiniert Vertretungsregelungen.

Jeden Monat landen Abwesenheitsanträge auf dem Schreibtisch, die nicht warten können. Elternzeit nach BEEG. Pflegezeit nach PflegeZG. Sabbatical nach Betriebsvereinbarung. Sonderurlaub nach Tarifvertrag. Vier Rechtsgrundlagen, vier verschiedene Fristenregime, vier Sätze an Anspruchsvoraussetzungen - und jeder einzelne Antrag bindet HR-Kapazität, die eigentlich für strategische Arbeit gebraucht wird.

Das Problem ist nicht der einzelne Antrag. Das Problem ist die Gleichzeitigkeit.

## Warum gerade jetzt

Rund 1,67 Millionen Frauen und Männer bezogen 2024 Elterngeld (Destatis). Elterngeld Plus gewinnt an Bedeutung - 36,7 Prozent der Berechtigten planten 2024 zumindest anteilig diese Variante, die mit Teilzeit-Elternzeit kombiniert werden kann. Seit Mai 2025 können Elternzeitanträge in Textform gestellt werden - per Mail statt per Unterschrift. Das senkt die Hürde für Antragsteller, erhöht aber das Volumen, das HR verarbeiten muss.

Gleichzeitig steigt der Pflegebedarf. Das PflegeZG kennt drei Varianten: kurzfristige Arbeitsverhinderung (10 Tage), Pflegezeit (bis 6 Monate), Familienpflegezeit (bis 24 Monate reduzierte Arbeitszeit). Seit 2024 kann das Pflegeunterstützungsgeld jährlich beansprucht werden statt nur einmal pro Pflegefall. Seit 2025 gilt auch hier die Textform. Jede Variante hat eigene Voraussetzungen, Fristen und Auswirkungen auf Entgelt und Sozialversicherung.

Dazu kommen die alltäglichen Fälle: Sonderurlaub bei Umzug, Hochzeit, Todesfall. Resturlaub - zwei Drittel aller Beschäftigten starten laut IAB mit durchschnittlich 7,6 nicht genommenen Urlaubstagen ins neue Jahr. Unbezahlter Urlaub nach individueller Vereinbarung.

Für HR entsteht daraus eine Rechenaufgabe mit vielen Unbekannten. Und die Konsequenzen bei Fehlern sind nicht trivial: verpasste Fristen bei Elternzeitanträgen verschieben den Beginn. Falsche Anspruchsberechnung bei Pflegezeit erzeugt arbeitsrechtliche Risiken. Fehlende Vertretungsplanung trifft das operative Geschäft.

## Was der Agent verändert

Der [Decision Layer](/de/decision-layer/) trennt in diesem Prozess zwei Welten voneinander.

Die erste Welt ist Regelwerk. Anspruchsprüfung, Fristenberechnung, Entgeltauswirkung - das sind deterministische Operationen. Ob jemand Anspruch auf Elternzeit hat, steht im BEEG. Ob die Antragsfrist gewahrt ist, ergibt sich aus dem Geburtsdatum des Kindes und dem gewünschten Beginn. Wie sich eine sechsmonatige Pflegezeit auf die betriebliche Altersversorgung auswirkt, steht in der Versorgungsordnung. Diese Prüfungen brauchen keinen Menschen. Sie brauchen ein Regelwerk, das korrekt und vollständig abgebildet ist.

Die zweite Welt ist Entscheidung. Wer übernimmt die Vertretung? Wird ein Sabbatical genehmigt, obwohl kein gesetzlicher Anspruch besteht? Wie gestaltet man die Rückkehr nach 14 Monaten Elternzeit? Diese Fragen erfordern Kontext, Urteilsvermögen und Verantwortung. Sie bleiben bei Führungskraft und HR.

Zwischen diesen beiden Welten liegt ein schmaler Streifen, in dem KI einen Beitrag leistet: Vertretungsvorschläge auf Basis von Kompetenzprofilen und Verfügbarkeit. Keine Entscheidung - ein Vorschlag, der den Suchraum eingrenzt.

```
Antrag eingeht
    |
    v
[Regelwerk] Klassifikation --> Elternzeit | Pflegezeit | Sabbatical | Sonderurlaub
    |
    v
[Regelwerk] Anspruchsprüfung --> BEEG | PflegeZG | BV | TV | Arbeitsvertrag
    |
    v
[Regelwerk] Fristenberechnung + Entgeltauswirkung
    |
    v
[KI] Vertretungsvorschlag (Kompetenz + Verfügbarkeit)
    |
    v
[Mensch] Vertretung bestätigen + Antrag genehmigen
    |
    v
[Regelwerk] Rückkehrplanung + automatische Erinnerungen
```

## Mehrere hundert Abwesenheitsvorgänge pro Jahr laufen ohne vergessene Rückkehrplanung

Der Unterschied zeigt sich nicht in einem einzelnen Antrag. Er zeigt sich in der Summe über ein Jahr.

Ein Unternehmen mit 2.000 Beschäftigten verarbeitet pro Jahr typischerweise mehrere hundert Abwesenheitsvorgänge jenseits des regulären Urlaubs: Elternzeit, Pflegezeit, Sonderurlaub, Sabbatical, unbezahlte Freistellungen. Jeder Vorgang hat eine Prüfphase (Anspruch, Frist, Entgelt), eine Koordinationsphase (Vertretung, Übergabe) und eine Rückkehrphase (Re-Onboarding, Systeme reaktivieren).

Wenn die Prüfphase automatisiert ist, passieren zwei Dinge gleichzeitig: Die Durchlaufzeit sinkt, weil kein Antrag mehr auf einem Schreibtisch wartet. Und die Fehlerrate sinkt, weil das Regelwerk keine Fristen übersieht und keine Rechtsgrundlage verwechselt.

Die Vertretungskoordination beginnt nicht mehr zwei Wochen vor Abwesenheitsbeginn, sondern sofort nach Eingang des Antrags. Das gibt Teams Zeit für geordnete Übergaben statt für Notlösungen.

Die Rückkehr wird nicht mehr vergessen. Vier Wochen vor dem dokumentierten Rückkehrdatum erhalten Führungskraft und HR eine Erinnerung. Bei längeren Abwesenheiten enthält sie eine Re-Onboarding-Checkliste, die sich nach Art und Dauer der Abwesenheit richtet.

## Der Infrastrukturbeitrag

Die Anspruchsprüfungs-Engine, die hier für Elternzeit und Pflegezeit aufgebaut wird, ist wiederverwendbar. Dieselbe Logik - gesetzlicher Anspruch, vertraglicher Anspruch, Fristenberechnung - wird in der Probezeitverwaltung und bei der Vertragserstellung gebraucht. Das Vertretungsvorschlags-Pattern bildet die Basis für die Personalplanung. Die automatisierte Rückkehrplanung ist ein Muster für jeden Agenten, der zeitgesteuerte Folgeaktionen auslöst.

Das ist der eigentliche Punkt: Jeder Agent, der sauber gebaut wird, erzeugt Infrastruktur für den nächsten.

--- Vertragsanalyse-Agent ---
> Analysiert Verträge gegen definierte Standards, identifiziert Risiko-Klauseln und bereitet strukturierte Zusammenfassungen.

## Juristen verbringen die Hälfte ihrer Zeit mit Arbeit, die keine juristische Expertise erfordert

Laut Gartner entfallen bis zu 50 Prozent der Kapazität einer Rechtsabteilung auf Vertragsmanagement. Der größte Teil davon ist kein juristisches Denken - es ist Lesen, Vergleichen, Sortieren. Ein Dienstleistungsvertrag wird gegen die hauseigene Klauselvorlage gehalten. Ein NDA wird auf Abweichungen bei Laufzeit und Gerichtsstand geprüft. Ein Rahmenvertrag wird Klausel für Klausel mit dem Standard abgeglichen.

Diese Arbeit erfordert Sorgfalt. Aber sie erfordert in den meisten Fällen keine juristische Urteilskraft. Die Frage ist nicht, ob ein Jurist die Haftungsklausel lesen kann - sondern ob er der Richtige ist, um festzustellen, dass sie identisch mit der Standardversion ist.

Genau hier liegt das Muster, das sich automatisieren lässt: Der Abgleich von Vertragstext gegen definierte Standards. Die Extraktion bekannter Risiko-Klauseln. Die Klassifikation nach Vertragstyp. In einer Rechtsabteilung, die 200 Verträge pro Quartal prüft, bedeutet das den Unterschied zwischen einem Team, das reagiert, und einem Team, das gestaltet.

## 92 Minuten pro Vertrag sind kein Qualitätsstandard - sie sind ein Engpass

Die durchschnittliche Review-Zeit für einen Standardvertrag liegt bei 92 Minuten. Bei einem NDA - dem einfachsten Vertragstyp - schaffen aktuelle KI-Systeme denselben Abgleich in 26 Sekunden bei 94 Prozent Genauigkeit ([Sirion, 2026](https://www.sirion.ai/library/contract-insights/ai-playbook-redlining-vs-manual-contract-review/)). Die fehlenden 6 Prozent sind kein Argument gegen Automatisierung. Sie sind ein Argument für den richtigen Zuschnitt: Der Agent prüft die Standardklauseln. Der Jurist prüft die Abweichungen.

Stellen Sie sich eine typische Woche in einer Rechtsabteilung vor, die Einkaufsverträge betreut. Montag kommen drei neue Lieferantenverträge. Mittwoch ein verlängerter Rahmenvertrag mit geänderten Haftungsbedingungen. Freitag ein NDA für eine Due-Diligence-Prüfung. Jeder dieser Verträge durchläuft denselben Prozess: Typ erkennen, Standardklauseln abgleichen, Abweichungen markieren, Risiken bewerten. Erst danach beginnt die eigentliche juristische Arbeit - die Bewertung, ob eine Abweichung akzeptabel ist oder nachverhandelt werden muss.

Der Vertragsanalyse-Agent übernimmt die ersten sechs Schritte dieses Prozesses. Die letzten drei - Risikobewertung durch den Juristen, Verhandlungsempfehlung und Freigabe - bleiben dort, wo das Recht es verlangt: beim Menschen.

## Sechs Entscheidungsschritte automatisiert, drei bleiben beim Juristen

Der [Decision Layer](/de/decision-layer/) zerlegt jeden Vertragsprüfungsprozess in einzelne Entscheidungsschritte und definiert für jeden Schritt: Mensch, Regelwerk oder KI. Im Fall der Vertragsanalyse ergibt diese Zerlegung ein klares Bild.

Die automatisierbaren Schritte folgen einem Muster: Sie vergleichen Ist-Zustand gegen Soll-Zustand. Ist dieser Vertrag ein NDA oder ein Dienstleistungsvertrag? Entspricht die Haftungsklausel dem Standard oder weicht sie ab? Enthält der Vertrag eine Vertragsstrafe? Diese Fragen lassen sich mit einer gut gepflegten Klausel-Bibliothek zuverlässig beantworten.

Die menschlichen Schritte folgen einem anderen Muster: Sie erfordern Urteil unter Unsicherheit. Ist die abweichende Haftungsobergrenze für diesen speziellen Lieferanten akzeptabel? Überwiegt der Geschäftswert des Vertrags das Risiko einer fehlenden Gewährleistungsklausel? Kann der Vertrag unter diesen Bedingungen freigegeben werden? Das sind Entscheidungen, die Kontext brauchen, den kein Agent hat - Geschäftsbeziehung, Verhandlungshistorie, strategische Prioritäten.

Der Governance-Score dieses Agenten liegt mit 55-62 deutlich höher als bei reinen Prozessautomatisierungen. Das spiegelt wider, dass Vertragsanalyse näher an rechtlich relevanten Entscheidungen operiert als etwa Gehaltsabrechnung oder Zeiterfassung. Der Agent darf analysieren und markieren. Bewerten und entscheiden darf er nicht.

## Die Klausel-Bibliothek entscheidet über den Erfolg - und sie existiert noch nicht

Dieser Agent ist ein H3-Agent. Das bedeutet: höhere Komplexität, niedrigerer Reifegrad als etablierte Prozessautomatisierungen. Aktuelle KI-Systeme verlieren bei Verträgen über 1.000 Zeichen Prompt-Länge 10 bis 20 Prozent an Genauigkeit ([WorldCC / KPMG, 2025](https://kpmg.com/us/en/articles/2025/agentic-ai-in-clm-balancing-human-and-machine-expertise.html)). Bei einem 30-seitigen Rahmenvertrag ist das ein relevanter Faktor.

Die wichtigste Voraussetzung ist keine Technologie - es ist eine gepflegte Klausel-Bibliothek mit den Unternehmensstandards für jeden Vertragstyp. Ohne diesen Referenzpunkt hat der Agent nichts, wogegen er vergleichen kann. Die Bibliothek definiert, was "Standard" bedeutet. Erst dann kann der Agent erkennen, was "Abweichung" ist.

Unternehmen, die bereits ein Contract-Lifecycle-Management-System betreiben und ihre Standardklauseln dokumentiert haben, können diesen Agenten schneller produktiv einsetzen. Unternehmen ohne diese Grundlage bauen sie beim Aufbau des Agenten mit auf - was den Rollout verlangsamt, aber einen eigenständigen Wert schafft. Eine strukturierte Klausel-Bibliothek verbessert die Vertragsprüfung auch ohne Agent, weil sie erstmals einen einheitlichen Maßstab definiert.

Der ehrliche Zeithorizont: Nicht nächsten Monat produktiv, sondern nach dem Aufbau der Klausel-Bibliothek und einer Kalibrierungsphase mit der Rechtsabteilung. Der Gewinn danach: Juristen, die ihre Zeit für die Fälle einsetzen, in denen juristische Urteilskraft tatsächlich gebraucht wird.

--- Merit-Cycle-Governance-Agent ---
> Jährliche Gehaltsrunde: EU Pay Transparency 2023/970 mit 5-Prozent-Gender-Pay-Gap-Schwelle, EntgTranspG-Auskunftsanspruch und EU AI Act Annex III(4)(b) Hochrisiko - mit BetrVG §87 Mitbestimmung.

## Fünf Monate von der Budgetfreigabe bis zur ersten Auszahlung

Dieser Agent folgt dem [Decision Layer](/de/decision-layer/)-Prinzip: jede Entscheidung ist entweder regelbasiert, KI-assistiert oder explizit einem Menschen zugeordnet. Er ist nach [EU AI Act 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) Annex III(4)(b) als Hochrisiko-System klassifiziert und unterliegt damit den verschärften Pflichten zu Risikomanagement-System, Daten-Governance, Transparenz, menschlicher Aufsicht und Bias-Audit ab dem 2.8.2026.

Eine typische Gehaltsrunde dauert fünf Monate. Nicht weil die Entscheidungen schwierig sind, sondern weil der Prozess es ist. Budget-Freigabe im September. Datenaufbereitung im Oktober. Spreadsheet-Verteilung an 30, 50, 80 Führungskräfte im November. Rücklauf über Wochen. Kalibrierungsrunden im Januar. Korrekturen. Payroll-Übergabe im Februar. Erste Auszahlung frühestens im März.

Das Problem liegt nicht im Zeitaufwand. Es liegt in dem, was zwischen den Schritten passiert - oder eben nicht passiert: systematische Equity-Auswertung, dokumentierbare Begründungen für die AGG §22-Beweislast-Umkehr, Compa-Ratio-Validierung, Konsistenz über Bereiche und Hierarchie-Ebenen hinweg.

## Was in Spreadsheet-Runden unsichtbar bleibt

Wenn 60 Führungskräfte parallel Gehaltsvorschläge in Excel-Dateien eintragen, entsteht kein konsistenter Prozess. Es entsteht eine Sammlung individueller Einschätzungen, die niemand in Echtzeit aggregieren, validieren oder vergleichen kann. Die typischen Folgen:

**Bandverletzungen ohne Warnung.** Eine Führungskraft empfiehlt eine Erhöhung, die den Mitarbeitenden über das obere Ende des Vergütungsbands schiebt. Im Spreadsheet fällt das erst auf, wenn Comp&Ben die Datei manuell prüft - oft Wochen später, oft gar nicht. Unternehmen berichten regelmäßig, dass Beschäftigte außerhalb ihrer definierten Gehaltsbänder vergütet werden, ohne dass es systematisch auffällt.

**Equity-Lücken bleiben verborgen.** Wenn 60 Excel-Dateien parallel ausgefüllt werden, fällt einer Kalibrierungs-Runde im Januar nicht auf, dass weibliche Sales-Leitende systematisch 4 Prozent niedrigere Anpassungen erhalten als männliche - oder dass der Pay Gap zwischen 50+ und Mittel-Karriere-Beschäftigten in einer bestimmten Funktion 7 Prozent beträgt.

**AGG §22-Beweislast-Umkehr-Risiko ohne Audit-Trail.** Im Klagefall greift die Beweislast-Umkehr nach AGG §22 - wenn Mitarbeitende Indizien für Diskriminierung anführen können (statistische Auffälligkeit, fehlende Begründung, Timing), liegt es am Arbeitgeber zu beweisen, dass keine Diskriminierung vorlag. Ohne dokumentierte, reproduzierbare Begründung pro Anpassung ist diese Beweispflicht praktisch nicht erfüllbar.

## Warum sich die Sanktionen kumulieren

Bei verfehlter Merit-Cycle-Governance summieren sich die Risiken. AGG §15 sieht Entschädigungen bis zu drei Bruttomonatsgehälter je Mitarbeitenden vor, wenn Indizien für eine Vergütungs-Diskriminierung wegen eines der geschützten Merkmale vorliegen. Bei Sammelklagen oder mehreren Klägern aus derselben Vergleichsgruppe erreicht das schnell den siebenstelligen Bereich. Die Beweislast-Umkehr nach AGG §22 macht die Verteidigung ohne dokumentierte Begründung pro Anpassung praktisch unmöglich, und die Zwei-Monats-Klagefrist beginnt mit jeder neuen Anpassungs-Mitteilung neu.

Hinzu kommt der EU AI Act: bis zu 35 Mio Euro oder 7 Prozent des globalen Konzernumsatzes, wenn die Pflichten zu Risikomanagement, Bias-Mitigation, Transparenz oder menschlicher Aufsicht verletzt werden. Die DSGVO greift mit bis zu 4 Prozent Konzernumsatz oder 20 Mio Euro bei Verstößen gegen die Vergütungsdaten-Vorgaben, dazu Sanktionen nach EntgTranspG bei verweigerter Auskunft. Eine Verletzung der CSRD-Berichtspflicht führt zu einem Wirtschaftsprüfer-Mängelbericht und zur Aufsichtsrats-Haftung nach §107 AktG.

Die US-Sammelklage Mobley v. Workday (2023) prägt als Präzedenzfall für KI-Bias in HR-Vergütungssoftware - gerichtet gegen über 40-jährige Mitarbeitende nach ADEA, der US-Parallelnorm zur Altersdiskriminierung des AGG §1 - die Linie der Aufsichtsbehörden und die Standards der Wirtschaftsprüfer. Eine Verletzung der [BetrVG-Mitbestimmung](https://www.gesetze-im-internet.de/betrvg/) führt zu einem Unterlassungs-Anspruch, einem Beschluss-Verfahren nach §87 ArbG und einem Einigungsstellen-Verfahren mit konzernweiter Wirkung.

## EU Pay Transparency Directive 2023/970 als Compliance-Druck

Ab dem 7.6.2026 verpflichtet die [EU Pay Transparency Directive 2023/970](https://eur-lex.europa.eu/eli/dir/2023/970/oj) (national umzusetzen) zu dokumentierbaren Grundlagen für jede Anpassung. Bei Gender-Pay-Gap-Abweichungen von 5 Prozent unerklärtem Lohngefälle (Art. 9) greifen Joint-Pay-Assessment-Pflichten und Abhilfe-Verfahren innerhalb von 6 Monaten (Art. 10). Mitarbeitende erhalten Auskunftsanspruch über durchschnittliche Vergütung gleichwertiger Tätigkeiten (Art. 7), in Stellenausschreibungen ist die Pay-Range-Anzeige Pflicht (Art. 6), und die Frage nach Gehaltshistorie früherer Arbeitgeber ist verboten (Art. 5).

Die Beweislast bei Lohndiskriminierungs-Klagen kehrt sich um (Art. 18): Es liegt am Arbeitgeber zu zeigen, dass keine Diskriminierung vorlag. Berichts-Pflichten Gender Pay Gap stufen sich ab 250 Mitarbeitenden (ab 2027) bis 100 Mitarbeitenden (ab 2031). Sanktionen: Mindeststandards Art. 20 mit Bußgeldverfahren und Schadensersatz nach AGG §15 (3 Bruttomonatsgehälter Entschädigung).

Das deutsche [EntgTranspG](https://www.gesetze-im-internet.de/entgtranspg/) ergänzt seit 2017 mit individuellem Auskunftsanspruch ab 200 Mitarbeitenden (§10-§16), betrieblichem Prüfverfahren ab 500 Mitarbeitenden (§17-§19) und Berichts-Pflicht im Lagebericht (§21-§23). Bis Juni 2026 muss die nationale Umsetzung der EU-Richtlinie erfolgen - praktisch bedeutet das eine Verschärfung des EntgTranspG.

## EU AI Act Annex III(4)(b): Hochrisiko-Klassifikation mit DPIA und FRIA

Der Merit-Cycle-Governance-Agent fällt nach EU AI Act Annex III(4)(b) unter die Hochrisiko-Systeme für HR-Vergütungsentscheidungen. Die Pflichten ab dem 2.8.2026 umfassen:

- **Article 9 Risikomanagement-System**: Bias-Risiken über die geschützten Merkmale hinweg identifizieren, bewerten und mindern
- **Article 10 Daten-Governance**: Qualität der Trainingsdaten, Bias-Detection sowie Tests auf Demographic Parity und Equal Opportunity
- **Article 13 Transparenz-Pflichten**: Beipackzettel zu Funktionsweise, Genauigkeit, Robustheit und Bias-Audit-Ergebnissen
- **Article 14 menschliche Aufsicht**: Mensch-in-the-Loop bei jeder Empfehlung zwingend
- **Article 26 Deployer-Pflichten**: Datenschutz-Folgenabschätzung, Konsultation der Aufsichtsbehörde, Post-Market-Monitoring und Incident Reporting
- **Article 27 FRIA Fundamental Rights Impact Assessment**: vor Inbetriebnahme, mit Konsultation von Antidiskriminierungsstelle, Datenschutzbeauftragtem und Betriebsrat

Bußgelder bis 35 Mio EUR oder 7 Prozent globaler Konzernumsatz. Cross-Reference DSGVO Art. 35 DPIA-Pflicht bei systematischer automatisierter Bewertung mit erheblicher Auswirkung. Die [Mobley v. Workday Sammelklage](https://www.courtlistener.com/docket/67476007/mobley-v-workday-inc/) (Northern District California 2023) - Vorwurf AI-Bias bei HR-Recruitment-Software gegen über 40-jährige Bewerber ADEA - dient als Präzedenzfall für US-Risiko und prägt die EU-Aufsichtsbehörden-Linie.

## BetrVG §87 Abs. 1 Nr. 10 Mitbestimmung Entlohnungsgrundsätze

Der Betriebsrat hat nach [BetrVG](https://www.gesetze-im-internet.de/betrvg/) §87 Abs. 1 Nr. 10 zwingendes Mitbestimmungsrecht bei Aufstellung von Entlohnungsgrundsätzen sowie Einführung und Anwendung neuer Entlohnungsmethoden. §87 Abs. 1 Nr. 11 erfasst Akkord- und Prämiensätze sowie leistungsbezogene Entgelte. §87 Abs. 1 Nr. 6 greift bei technischen Einrichtungen zur Überwachung von Verhalten oder Leistung - eine KI-Merit-Cycle-Plattform mit Bias-Audit-Trail fällt unstreitig darunter.

Konkret bedeutet das: Vor Einführung wird eine Betriebsvereinbarung geschlossen über Vergütungs-Bandbreiten, Equity-Analyse-Schwellenwerte, Genehmigungs-Matrix, DPIA-Mitwirkung, FRIA-Konsultation und Audit-Trail-Zugang. Bei Nichteinigung greift das Einigungsstellen-Verfahren nach ArbG. Konzern-Betriebsrat-Pflicht bei konzernübergreifender Software.

## Equity-Audit als Vorteil gegenüber manuellem Prozess

Die Equity-Analyse-Engine prüft statistisch über alle acht AGG §1-Merkmale (Geschlecht, Alter, ethnische Herkunft, Religion, Weltanschauung, Behinderung, sexuelle Identität, Familienstand). Für jedes Merkmal werden Demographic Parity (gleiche Anpassungs-Häufigkeit über Gruppen) und Equal Opportunity (gleiche Anpassungs-Höhe bei vergleichbarer Performance) gemessen. Bei statistisch signifikanten Abweichungen erfolgt automatische Eskalation an HR-Leitung mit AGG §22-konformem Audit-Trail.

Dies ist nicht nur Compliance-Schutz: Studien (z.B. McKinsey Diversity Wins, BCG Closing the Gap) zeigen 4-6 Prozent Equity-Lücken in Mittelständlern und 2-4 Prozent in DAX-Konzernen, die manuell unentdeckt bleiben. Der Agent macht sie sichtbar und schafft die Datengrundlage für gezielte Korrektur-Anpassungen.

## Cross-Reference zu Compensation-Benchmarking, Performance-Review und Payroll

Der Merit-Cycle-Governance-Agent ist eingebettet in eine Pipeline aus spezialisierten HR-Agenten: [Compensation-Benchmarking-Agent](/de/hr-agent-katalog/compensation-benchmarking-agent/) liefert Vergütungsbänder, Compa-Ratios und Pay-Range-Daten. [Performance-Review-Agent] liefert Performance-Ratings als Berechtigungs-Voraussetzung. [Payroll-Calculation-Agent](/de/hr-agent-katalog/payroll-calculation-agent/) nimmt genehmigte Anpassungen mit korrektem Stichtag entgegen. [Payroll-Reporting-Agent](/de/hr-agent-katalog/payroll-reporting-agent/) erstellt CSRD ESRS S1-10 Equal Pay Reporting. [HR-Document-Management-Agent](/de/hr-agent-katalog/hr-document-management-agent/) archiviert AGG-konforme Anpassungs-Begründungen 6 Monate. [Audit-Compliance-Agent](/de/hr-agent-katalog/audit-compliance-agent/) prüft EU AI Act Article 26 Deployer-Pflichten und DPIA-Konsistenz. [Interview-Scheduling-Agent](/de/hr-agent-katalog/interview-scheduling-agent/) wendet EU Pay Transparency Art. 6 Pay-Range-Anzeige in Stellenausschreibungen an.

## Auf einen Blick

- **Klassifikation**: EU AI Act 2024/1689 Annex III(4)(b) Hochrisiko HR-Vergütungs-Entscheidungen ab 2.8.2026
- **Compliance-Anker**: AGG §22 Beweislast-Umkehr, EntgTranspG §10-§19, EU Pay Transparency 2023/970, BetrVG §87 Abs. 1 Nr. 10, DSGVO Art. 22+35+88, CSRD ESRS S1-10
- **Mitbestimmung**: BetrVG §87 Abs. 1 Nr. 10, 11 und 6 zwingend, Konzern-Betriebsrat-Pflicht
- **Equity-Schwelle**: 5 Prozent unerklärter Gender Pay Gap nach EU Pay Transparency Art. 9 löst Joint Pay Assessment und 6-Monats-Abhilfe (Art. 10) aus
- **Bußgelder**: bis 35 Mio EUR oder 7 Prozent globaler Konzernumsatz nach EU AI Act, bis 4 Prozent oder 20 Mio EUR nach DSGVO, dazu AGG §15 mit 3 Bruttomonatsgehältern
- **Audit-Pflicht**: DPIA, FRIA und Bias-Audit pro Quartal, Wirtschaftsprüfer-Prüfung CSRD ab 250 Mitarbeitenden
- **Präzedenzfall**: Mobley v. Workday Northern District California 2023 Sammelklage AI-Bias HR-Software

### Entscheider-Verteilung Merit-Cycle-Governance

| Schritt | Decider | Begründung |
|---------|---------|------------|
| Budget-Festlegung | H | Geschäftsführungs-Strategie, CSRD-Vorbereitung |
| Berechtigungs-Prüfung | R | Regelwerk Betriebszugehörigkeit, Performance, Sperren |
| Benchmark-Bereitstellung | R | Compa-Ratio-Berechnung deterministisch |
| Führungskraft-Empfehlung | H | Individuelle Leistungsbewertung, Retention-Risiko |
| Band-Validierung | R | Min-Max-Pay-Range automatisch |
| Budget-Einhaltung | R | Real-Time-Tracking deterministisch |
| Equity-Analyse | A | ML-statistische Bias-Detection mit menschlicher Validierung |
| Equity-Eskalation | R | Schwellenwert >5 Prozent EU Pay Transparency 2023/970 |
| Genehmigungs-Workflow | R | Genehmigungs-Matrix Hierarchie, Compa-Ratio-Position |
| HR-Leitung-Genehmigung | H | Finale Freigabe AGG §22-konform |
| DSGVO-Information | R | DSGVO Art. 13+14+22 Abs. 3 Standard-Workflow |
| Vergütungs-Gespräch | H | Persönliches Gespräch Beziehungs-Dimension |
| Payroll-Übergabe | R | Stichtag, Lohnsteuer-Korrektur deterministisch |
| CSRD-Reporting | R | ESRS S1-10, EU Pay Transparency Art. 8 deterministisch |

--- Offboarding-Agent ---
> Orchestriert den Austrittsprozess: Wissenstransfer, IT-Rückgabe, Systemdeaktivierung, Zeugniserstellung - kein Schritt vergessen.

Ein erheblicher Anteil ehemaliger Mitarbeitender behält nach dem Austritt noch aktive Zugangsdaten - in vielen Organisationen erreichen diese inaktiven Accounts messbare Prozentzahlen aller Nutzer im Identity Provider. Ein signifikanter Teil der als inaktiv markierten Konten hat weiterhin Live-Berechtigungen in Kernanwendungen. Und viele Unternehmen brauchen mehr als drei Tage, um nach einem Austritt sämtliche Systemzugänge zu sperren. Manche schaffen es nie vollständig.

Das ist kein Randproblem. Es ist die Eintrittskarte für jeden Angreifer, der lieber gültige Credentials nutzt als Firewalls zu überwinden.

## Fünf Stränge, null Taktgeber

Dieser Agent folgt dem [Decision Layer](/de/decision-layer/)-Prinzip: jede Entscheidung ist entweder regelbasiert, KI-assistiert oder explizit einem Menschen zugeordnet.

Ein Offboarding-Prozess berührt mindestens fünf Verantwortungsbereiche gleichzeitig. Keiner davon wartet auf den anderen. Alle haben eigene Fristen, eigene Systeme und eigene blinde Flecken.

```
Kündigung/Aufhebung
    |
    +-- HR: Personalakte schließen, Meldungen, Zeugnis
    +-- IT: Hardware zurück, Zugänge sperren, Lizenzen freigeben
    +-- Fachbereich: Wissenstransfer, Projekte übergeben
    +-- Führungskraft: Exit-Gespräch, Feedback dokumentieren
    +-- Datenschutz: Löschfristen starten, Aufbewahrungspflichten prüfen
    |
Letzter Arbeitstag (alles muss erledigt sein)
    |
Nachlaufphase: Zeugnis, DSGVO-Löschung, Boomerang-Tracking
```

In der Praxis koordiniert HR das per Checkliste und Erinnerungsmail. Bei drei Austritten im Quartal funktioniert das. Bei dreißig kollabiert es - und zwar leise. Niemand bemerkt den VPN-Zugang, der noch zwei Monate aktiv ist. Niemand fragt nach dem SharePoint-Ordner mit Kundendaten, auf den der ehemalige Mitarbeitende weiterhin zugreifen kann.

## Warum Offboarding teurer ist, als es aussieht

Die sichtbaren Kosten eines schlecht gesteuerten Austritts sind überschaubar: ein vergessener Laptop, eine verspätete Abmeldung. Die unsichtbaren Kosten sind es nicht.

Ein substanzieller Teil der HR-Verantwortlichen beziffert die Jahreskosten eines inkonsistenten Offboardings für ihr Unternehmen auf sechsstellige Euro-Beträge - durch Wissensverlust, Sicherheitsrisiken und Nachbesetzungsaufwand. Nur eine Minderheit der Unternehmen stellt sicher, dass beim Austritt ein angemessener Wissenstransfer stattfindet. Ein großer Teil des Fachwissens einer Position existiert ausschließlich im Kopf des Stelleninhabers und lässt sich durch einen Nachfolger nicht ohne Weiteres ersetzen.

Drei Kostentreiber fallen besonders ins Gewicht:

**Sicherheitsrisiko.** Verwaiste Konten sind der einfachste Angriffsvektor. Kein Brute-Force, kein Phishing nötig - die Credentials existieren noch. In einer Welt, in der ein durchschnittliches Unternehmen 275 SaaS-Anwendungen betreibt, ist manuelles Deprovisioning eine Illusion.

**Wissensverlust.** Die Kosten für den Verlust eines Subject Matter Experts können das Zwanzigfache der üblichen Recruiting- und Einarbeitungskosten betragen. Nicht weil die Person unersetzlich wäre, sondern weil ihr undokumentiertes Wissen es ist.

**Boomerang-Potenzial.** 35 Prozent aller Neueinstellungen sind inzwischen Rückkehrer. Deren Retention Rate liegt 44 Prozent höher als bei komplett neuen Mitarbeitenden. Ein chaotischer Austritt zerstört genau die Beziehung, die eine Wiedereinstellung ermöglicht hätte.

## Drei Zeitfenster, drei verschiedene Probleme

Offboarding ist kein einzelner Vorgang. Es zerfällt in drei Phasen mit grundlegend unterschiedlichen Anforderungen.

**Vor dem letzten Tag:** Wissenstransfer organisieren, Projekte übergeben, Nachfolger einarbeiten. Hier entscheidet die Führungskraft, welches Wissen kritisch ist - kein Regelwerk kann das automatisieren, weil es Kontextwissen über Teamdynamik und Projektabhängigkeiten erfordert.

**Am letzten Tag:** Hardware zurückgeben, Zugänge sperren, Badge einziehen. Das ist vollständig regelbasiert. Welche Geräte zurückkommen müssen, steht in der Ausstattungsliste aus dem Onboarding. Welche Zugänge gesperrt werden, ergibt sich aus dem Berechtigungsprofil. Zeitpunkt und Reihenfolge folgen einem Deaktivierungsplan - kritische Systeme sofort, E-Mail-Weiterleitung nach definierter Übergangsfrist.

**Nach dem Austritt:** Zeugnis ausstellen, Löschfristen einhalten, Endabrechnung erstellen. Der Zeugnisanspruch nach Paragraph 109 GewO verjährt erst nach drei Jahren, aber arbeitsvertragliche Ausschlussfristen können deutlich kürzer greifen. Die DSGVO-Löschpflicht läuft parallel zu handels- und steuerrechtlichen Aufbewahrungsfristen von sechs bis zehn Jahren - ein Spannungsfeld, das ohne klare Steuerung regelmäßig zu Verstößen führt.

```
Phase           Typischer Fehler                  Konsequenz
──────────────  ──────────────────────────────     ────────────────────────
Vor Austritt    Kein Wissenstransfer geplant       42% des Fachwissens weg
Letzter Tag     VPN/Cloud-Zugänge nicht gesperrt   Sicherheitsrisiko
Nachlaufphase   Zeugnis nach 4 Monaten             Klageandrohung
Nachlaufphase   DSGVO-Löschung vergessen           Bußgeld bis 20 Mio EUR
```

## Was der Agent tatsächlich steuert

Der Offboarding-Agent ist das Spiegelbild des Onboarding-Workflow-Agents. Dieselbe Orchestrierungs-Engine, dieselbe Architektur aus Templates, Aufgabenverteilung und Fristüberwachung - nur in umgekehrter Richtung.

Sobald ein Austritt im HR-System erfasst wird, passieren drei Dinge gleichzeitig: Das Regelwerk bestimmt den Offboarding-Typ anhand des Austrittsgrundes - Kündigung durch Arbeitgeber, Eigenkündigung, Aufhebungsvertrag und Verrentung erzeugen jeweils unterschiedliche Checklisten. Die vollständige Aufgabenliste wird aus dem Template generiert und an die zuständigen Stellen verteilt. Ab diesem Moment überwacht der Agent Fristen und eskaliert bei Verzug.

Die Entscheidungsarchitektur ist bewusst restriktiv. Von zehn Schritten im Prozess sind sechs regelbasiert, einer KI-gestützt und drei bleiben beim Menschen. KI kommt ausschließlich beim Zeugnisentwurf zum Einsatz - dort, wo aus Tätigkeitsbeschreibung, Beschäftigungsdauer und Leistungsbeurteilung ein Textentwurf generiert wird. Ob das Zeugnis freigegeben wird, ob das Exit-Interview stattfindet und welches Wissen als kritisch gilt, entscheiden Führungskraft und HR persönlich.

## DSGVO-Löschung als architektonisches Problem

Die meisten Unternehmen behandeln Löschpflichten als Aufgabe für den Datenschutzbeauftragten. Das funktioniert, solange jemand daran denkt. Bei 50 Austritten pro Jahr über Systeme hinweg, die keine zentrale Löschroutine kennen, denkt irgendwann niemand mehr daran.

Das Spannungsfeld ist real: Gehaltsunterlagen müssen sechs bis zehn Jahre aufbewahrt werden. Bewerbungsunterlagen sind nach spätestens sechs Monaten zu löschen. Personalakten fallen unter die dreijährige Verjährungsfrist für arbeitsrechtliche Ansprüche. Bei Verstößen können deutsche Datenschutzbehörden Bußgelder von 10.000 bis 50.000 Euro pro Fall verhängen - nach oben offen bis zu 20 Millionen Euro oder 4 Prozent des weltweiten Jahresumsatzes.

Ein Offboarding-Agent löst das nicht durch Löschung, sondern durch Fristenverwaltung. Jeder Datensatz erhält beim Austritt eine Aufbewahrungskategorie mit konkretem Löschdatum. Der Agent überwacht die Fristen und eskaliert, wenn ein Löschdatum naht. Die eigentliche Löschung bleibt ein manueller Schritt mit Vier-Augen-Prinzip - aber die Erinnerung ist systematisch statt zufällig.

## Infrastruktur-Wert: Die Onboarding-Engine rückwärts

Der stärkste wirtschaftliche Hebel dieses Agents liegt nicht in der Prozessautomatisierung selbst, sondern in der Wiederverwendung. Die Checklisten-Engine, die Aufgabenverteilung, die Fristüberwachung und die Eskalationslogik sind identisch mit dem Onboarding-Workflow-Agent. Wer den einen gebaut hat, bekommt den anderen als Konfiguration statt als Projekt.

Die Systemdeaktivierungs-Logik bildet darüber hinaus die Grundlage für Access-Management über alle Lifecycle-Phasen - von der Versetzung über die Elternzeit bis zum Wiedereintritt. Und das Zeugnis-Generierungs-Pattern wird vom HR-Document-Management-Agent für Bescheinigungen, Bestätigungen und Referenzschreiben wiederverwendet.

Jeder Offboarding-Durchlauf erzeugt einen vollständigen Audit Trail: welche Aufgabe wurde wann erledigt, welche Frist wurde eingehalten oder überschritten, wer hat eskaliert. Aus 100 dokumentierten Durchläufen entsteht ein Bild davon, wo der Prozess systematisch hakt - nicht weil jemand einen Report bestellt hat, sondern weil die Architektur diese Daten als Nebenprodukt erzeugt.

--- Onboarding-Workflow Agent ---
> Orchestriert den Onboarding-Prozess von Vertragszusage bis zum ersten Arbeitstag: IT-Einrichtung, Schulungen, Buddy-Zuweisung - lückenlos.

Jeder dritte neue Mitarbeitende verlässt das Unternehmen innerhalb der ersten 90 Tage. Nicht wegen des Jobs. Nicht wegen des Gehalts. Sondern weil am ersten Tag der Laptop fehlt, die Zugänge nicht eingerichtet sind und niemand weiß, wer eigentlich für die Sicherheitseinweisung zuständig war. Laut Haufe-Studie verzeichnet über ein Drittel der deutschen Arbeitgeber Kündigungen noch vor dem ersten Arbeitstag. Die durchschnittlichen Kosten pro gescheitertem Onboarding liegen bei 15.000 Euro - ohne die verlorene Produktivität des restlichen Teams einzurechnen.

Das Problem ist nicht fehlendes Wissen darüber, was getan werden muss. Das Problem ist, dass niemand dirigiert.

## Acht Abteilungen, null Dirigent

Dieser Agent folgt dem [Decision Layer](/de/decision-layer/)-Prinzip: jede Entscheidung ist entweder regelbasiert, KI-assistiert oder explizit einem Menschen zugeordnet.

Ein einzelner Onboarding-Prozess involviert mindestens acht Organisationseinheiten: HR erstellt den Vertrag, IT provisioniert Hardware und Zugänge, Facility Management bereitet den Arbeitsplatz vor, der Fachbereich plant die Einarbeitung, Compliance stellt Pflichtschulungen zusammen, die Führungskraft wählt einen Buddy, Finance richtet die Gehaltsabrechnung ein, und der Empfang braucht den Namen für den Ausweis.

```
Vertragszusage
    |
    +-- HR: Personalakte, Meldungen, Willkommenspaket
    +-- IT: Hardware, Zugänge, E-Mail, VPN
    +-- Facility: Arbeitsplatz, Schlüssel, Parkplatz
    +-- Fachbereich: Einarbeitungsplan, Buddy-Auswahl
    +-- Compliance: Pflichtschulungen, Datenschutz, Arbeitssicherheit
    +-- Finance: Gehaltsabrechnung, Reisekosten-Setup
    +-- Führungskraft: Buddy bestätigen, Ziele setzen
    +-- Empfang: Ausweis, Zutrittskarte
    |
Erster Arbeitstag (alles muss stehen)
```

Jeder dieser Stränge hat eigene Fristen, eigene Systeme und eigene Ansprechpartner. Keiner dieser Stränge weiß zuverlässig, wo die anderen stehen. Die HR-Abteilung koordiniert das meistens per Excel-Checkliste und Erinnerungs-E-Mail - ein Verfahren, das bei fünf Einstellungen pro Monat funktioniert, aber bei fünfzig pro Quartal kollabiert.

## Warum Checklisten nicht skalieren

Eine Checkliste sagt: "IT-Ausstattung bestellen." Sie sagt nicht, welche Ausstattung für eine Vertriebsleitung am Standort München im Vergleich zu einer Entwicklerin in Wroclaw nötig ist. Sie sagt nicht, dass die Bestellung drei Wochen Vorlauf braucht und deshalb am Tag der Vertragszusage rausgehen muss - nicht wenn HR die Personalakte fertig hat. Sie sagt nicht, wer eskaliert wird, wenn nach zehn Tagen kein Laptop da ist.

Die wahre Komplexität steckt in der Konfiguration: Jede Kombination aus Position, Standort, Bereich und Vertragsart erzeugt einen anderen Onboarding-Pfad. Ein Unternehmen mit drei Standorten, vier Bereichen und zehn Positionstypen hat theoretisch 120 verschiedene Onboarding-Varianten. In der Praxis existieren davon vielleicht fünf als dokumentierte Prozesse - der Rest wird improvisiert.

## Eine Orchestrierungs-Engine steuert 14 Entscheidungsschritte von Zusage bis 30-Tage-Feedback

Der Onboarding-Workflow Agent ist kein Chatbot, der Fragen beantwortet. Er ist eine Orchestrierungs-Engine, die einen definierten Prozess von der Vertragszusage bis zum 30-Tage-Feedback-Gespräch steuert.

Sobald ein Vertrag unterschrieben ist, passieren drei Dinge gleichzeitig: Der Agent bestimmt den Onboarding-Typ anhand eines Regelwerks, erstellt die vollständige Checkliste aus dem passenden Template und verteilt jede Aufgabe an die zuständige Stelle mit konkreter Frist. Ab diesem Moment überwacht er den Fortschritt. Nicht passiv wie ein Dashboard, sondern aktiv - mit Erinnerungen bei nahender Frist und Eskalation bei Überschreitung.

Die Entscheidungsarchitektur dahinter ist bewusst konservativ. Von 14 Entscheidungsschritten im Prozess sind neun regelbasiert, drei KI-gestützt und zwei bleiben beim Menschen. KI kommt nur dort zum Einsatz, wo Muster erkannt werden müssen - etwa beim Buddy-Matching oder bei der Personalisierung des Willkommenspakets. Ob ein Buddy akzeptiert wird und ob das Onboarding am Ende als erfolgreich gilt, entscheidet die Führungskraft persönlich.

## Die versteckten Kosten der Improvisation

Frühfluktuation ist die sichtbare Kennzahl. Die weniger sichtbare: Time-to-Productivity. Studien zeigen, dass neue Mitarbeitende 8 bis 12 Monate brauchen, um volle Produktivität zu erreichen. Bei chaotischem Onboarding verlängert sich diese Phase erheblich. Wenn jemand in der ersten Woche drei Tage auf Zugänge wartet, sind das nicht drei verlorene Tage - es sind drei Tage, in denen ein falscher erster Eindruck zementiert wird.

90 Prozent der neuen Mitarbeitenden entscheiden in den ersten 100 Tagen, ob sie bleiben oder gehen. Das ist keine Vermutung - das ist die zentrale Erkenntnis aus der aktuellen Onboarding-Forschung. Die Entscheidung fällt nicht in einem großen Moment, sondern in kleinen: Funktioniert mein E-Mail-Zugang? Weiß mein Team, dass ich komme? Hat sich jemand Gedanken über meinen ersten Tag gemacht?

## Infrastruktur-Wert jenseits des Onboardings

Die Orchestrierungs-Engine, die der Onboarding-Agent aufbaut, ist keine Einmal-Investition. Dieselbe Architektur aus Checklisten-Templates, Aufgabenverteilung, Fristüberwachung und Eskalationslogik wird von Transfer-, Offboarding- und Probation-Agenten direkt wiederverwendet. Das Berechtigungsprofil-Framework bildet die Grundlage für Access-Management über alle Lifecycle-Phasen.

Noch wichtiger: Jeder Onboarding-Durchlauf erzeugt einen vollständigen Audit Trail. Welche Aufgabe wurde wann erledigt, wer hat eskaliert, wo gab es Verzögerungen. Aus diesen Daten entsteht über Zeit ein Bild davon, wo der Prozess systematisch hakt - nicht basierend auf Bauchgefühl, sondern auf 200 dokumentierten Durchläufen.

## Wann sich der Agent rechnet

Die Rechnung ist einfach. Bei 100 Einstellungen pro Jahr und einer Frühfluktuationsquote von 30 Prozent verliert ein Unternehmen 30 Mitarbeitende in der Probezeit. Bei 15.000 Euro Kosten pro Fall sind das 450.000 Euro. Wenn strukturiertes Onboarding die Retention um 44 Prozent verbessert - eine konservative Schätzung basierend auf SHRM-Daten - reduziert sich die Frühfluktuation auf 17 Fälle. Die Ersparnis: knapp 200.000 Euro pro Jahr.

Nicht eingerechnet: die höhere Produktivität der 83 Mitarbeitenden, die bleiben und schneller arbeitsfähig sind. Nicht eingerechnet: die Entlastung der HR-Abteilung, die nicht mehr 100 Prozesse per E-Mail-Kette koordinieren muss. Nicht eingerechnet: der Reputationseffekt, wenn neue Mitarbeitende von einem professionellen Onboarding berichten.

--- Lohnbuchhaltungs-Agent ---
> Lohn-FiBu-Buchungen GoBD-konform: deterministische Kontierung, KI nur als Vorschlag, menschliche Freigabe - über DATEV und SAP, prüfungssicher Zeile für Zeile.

## Jede Lohnsoftware bucht. Keine beweist, wer sie verantwortet.

DATEV, SAP, Personio - aus jeder Entgeltabrechnung wird per Knopfdruck eine Sammelbuchung in der Finanzbuchführung. Das ist seit Jahren Standard. Die Frage, an der ein Monatsabschluss und eine Betriebsprüfung wirklich hängen, beantwortet keines dieser Systeme: Wer hat diese eine Zuordnung verantwortet, auf welcher Grundlage - und können Sie beweisen, dass sie seitdem nicht unbemerkt geändert wurde?

Dieser Agent folgt dem [Decision Layer](/de/decision-layer/)-Prinzip: Jede Buchung ist entweder regelbasiert, ein KI-Vorschlag oder eine menschliche Freigabe - klar getrennt und unveränderbar protokolliert. Nach [EU AI Act](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) ist er kein Hochrisiko-System, weil er keine Menschen bewertet. Seine Anforderungen kommen aus dem Steuer- und Handelsrecht, und die sind hart genug.

## Lohnkontierung automatisieren: wo der Monatsabschluss klemmt

Die Hälfte der Finance-Teams braucht laut APQC-Benchmarks länger als eine Woche für den Monatsabschluss, und The Hackett Group zeigt, dass ein substanzieller Teil der Buchhalter-Arbeitszeit in manuelle Low-Value-Prozesse fließt. Die Lohnbuchung ist so ein wiederkehrender Block kurz vor Periodenschluss - und sie klemmt an drei Stellen:

- **Kontierung.** Aus einer Lohnauswertung wird ein Buchungssatz mit oft zehn bis zwanzig Splits: Lohnaufwand, Arbeitgeber-Anteil zur Sozialversicherung, Verbindlichkeiten gegenüber Finanzamt, Krankenkassen und Mitarbeitenden, dazu Kostenstellen. Die Brutto-Methode läuft über ein Lohnverrechnungskonto (SKR04 3790, SKR03 1755), dessen Saldo am Ende null sein muss. Die Zuordnung ist wiederkehrend und regelhaft - aber heute Handarbeit.
- **Abstimmung.** Stimmen die gebuchten Lohnverbindlichkeiten gegen die tatsächlichen Zahlungsausgänge? Ein typischer Fehler dabei sind Personalkosten auf der falschen Kostenstelle ([Haufe Finance Office](https://www.haufe.de/finance/haufe-finance-office-premium/kostenrechnung-fehler-der-finanzbuchhaltung-korrigieren_idesk_PI20354_HI1435849.html)).
- **Verfahrensdokumentation.** Sie veraltet, bis der Prüfer danach fragt.

Der Einsatz ist real: Allein der Prüfdienst der Rentenversicherung kontrollierte 2024 rund 386.000 Betriebe und forderte dabei 710 Millionen Euro an Beiträgen nach ([EY](https://www.ey.com/de_de/insights/tax-law-magazine/nach-der-betriebspruefung-ist-vor-der-betriebspruefung)). Diese Prüfung ist keine Frage des Ob, sondern des Wann - sie kommt im Vier-Jahres-Takt.

## Drei Quellen, klar getrennt: wer bucht was

Die meisten Anbieter sagen, ein Mensch bleibe "im Prozess", und kleben ein GoBD-Siegel daneben. Beides bleibt eine schwarze Box. Der Agent macht stattdessen für jede Buchung sichtbar, aus welcher von drei Quellen die Entscheidung stammt:

| Quelle | Was sie entscheidet | Beispiel aus der Lohn-FiBu |
|--------|---------------------|----------------------------|
| **Regelwerk (R)** | Alles Deterministische, kein Ermessen | Lohnart auf Konto und Kostenstelle, Soll/Haben-Aufbau, Fristen nach Paragraph 41a EStG |
| **KI-Vorschlag (A)** | Markiert Unsicheres, entscheidet nie | Kontovorschlag bei neuer Lohnart, Anomalie in der Abstimmung |
| **Mensch (H)** | Freigabe und rechtliche Beurteilung | Vier-Augen-Freigabe des Stapels, strittige SV-Pflicht einer Vergütung |

Der Agent ist also überwiegend ein deterministischer Buchungsmotor, mit KI nur als Vorschlag an den Rändern und einem festen menschlichen Freigabe-Gate. Das ist die ehrliche Antwort auf den naheliegenden Einwand "darf eine KI überhaupt buchen?" - und genau das, was das Vier-Augen-Prinzip verlangt. Wichtig dabei: Wer freigibt, sieht jede KI-vorgeschlagene Zuordnung als solche markiert - mit Konfidenz und Quelle -, bevor er sie freigibt. Das Vier-Augen-Prinzip greift damit auf den KI-Anteil, nicht an ihm vorbei. Wie diese Schicht architektonisch durchgreift, zeigt der [Decision Layer](/de/decision-layer/).

## GoBD entsteht zur Laufzeit, nicht im Nachhinein

Ein Buchungsvorschlag, der aus einem KI-Modell ohne integrierten Nachweis kommt, ist für eine Prüfung wertlos: Er ist nicht reproduzierbar, und es ist nicht dokumentiert, welche Eingaben ihn erzeugt haben. Die GoBD verlangt aber genau das Gegenteil - Nachvollziehbarkeit, Vollständigkeit, Richtigkeit und Unveränderbarkeit.

Deshalb trägt beim Agenten jede Buchung ihren Nachweis bei sich: Quelle, Eingabe, Begründung, Zeitstempel und die angewandte Regelversion - append-only, nicht nachträglich änderbar. Die Verfahrensdokumentation wächst mit jeder Buchung mit, statt als separates Schriftstück gepflegt zu werden. Und die Belege bleiben aufbewahrt, solange das Gesetz es verlangt: Buchungsbelege steuerlich seit dem Vierten Bürokratieentlastungsgesetz acht Jahre (Paragraph 147 AO), Bücher und Jahresabschlüsse zehn Jahre.

Der Hebel dahinter: Fehlt die nachvollziehbare Dokumentation, darf das Finanzamt die Buchführung verwerfen und nach Paragraph 162 AO schätzen - auch wenn jede einzelne Buchung sachlich korrekt war. Eine zur Laufzeit entstehende Dokumentation nimmt dieser Eskalation die Grundlage.

## Über DATEV und SAP, nicht statt ihnen

Der Agent konkurriert nicht mit Ihrer Lohnsoftware. Gegen DATEV und SAP auf der Buchungs-Achse anzutreten wäre aussichtslos - dort entscheidet Marktanteil und Integration. Der Agent legt sich als Entscheidungs- und Nachweis-Schicht darüber: Sie behalten Ihren Buchungslauf, und er macht ihn prüfbar.

Der fertige Buchungsstapel fließt unverändert und ohne Doppelbuchung in die Zielsysteme - ob DATEV Lohn und Gehalt im Lohnbüro oder SAP FI im Konzern mit mehreren Gesellschaften. Was hinzukommt, ist nicht ein weiteres System, sondern die Antwort auf die Prüfer-Frage: Für jede Zeile lässt sich sagen, wer sie verantwortet hat, und es ist unveränderbar belegt.

Der nächste Schritt ist keine Software-Einführung, sondern eine Bestandsaufnahme: Wo in Ihrem Lohn-FiBu-Prozess sitzt heute die manuelle Kontierung, und wie prüfungsfest ist die Dokumentation dahinter?

## Auf einen Blick

- **Was er tut**: erzeugt aus jeder Entgeltabrechnung einen FiBu-Buchungssatz nach klaren Regeln und protokolliert jede Buchung unveränderbar
- **Klassifikation**: kein EU-AI-Act-Hochrisiko-System (regelbasiert, keine Bewertung von Menschen)
- **Entscheidungslogik**: überwiegend Regelwerk, KI nur als Vorschlag, Freigabe beim Menschen (Vier-Augen-Prinzip)
- **Compliance-Anker**: GoBD (Fassung 2024), Aufbewahrung nach Paragraph 257 HGB und Paragraph 147 AO, Lohnsteuer nach Paragraph 41a EStG, Prüfung nach Paragraph 28p SGB IV
- **Integration**: Schicht über DATEV, SAP FI, Personio, Lexware oder Sage - kein Ersatz
- **Prüfungsfall**: jede Buchung bis zur Quell-Lohnart rückverfolgbar, Stichprobe direkt belegbar

--- Lohnprozess-Agent ---
> KI-Agent für den vorbereitenden Lohnprozess: DEÜV-Meldungen, ELStAM-Stammdaten und Self-Service-Workflows mit Decision-Layer für Betriebsrat und Datenschutz.

## Der teuerste Schritt im Lohnprozess ist die Freigabe ohne dokumentierten Entscheider

Der vorbereitende Lohnprozess ist kein Rechenvorgang, sondern eine Kette von Freigaben: Eintritt melden, Stammdaten pflegen, Anträge genehmigen, das Lohn-IT-System konform betreiben. Genau in dieser Kette entsteht der Schaden, der erst später sichtbar wird, denn jede dieser Entscheidungen ist rechtlich aufgeladen, ohne dass es ihr anzusehen ist.

Die Praxis belegt den Preis. Mehr als die Hälfte der Unternehmen musste in den vergangenen fünf Jahren Strafen oder Bußgelder wegen Fehlern in der Entgeltabrechnung zahlen ([Alight Payroll Complexity Report 2024](https://t3n.de/news/50-prozent-unternehmen-fehler-gehaltsabrechnung-1611997/)). Der finanzielle Schaden vermeidbarer Payroll-Fehler liegt bei [zwei bis vier Prozent der gesamten Personalkosten](https://www.haufe.de/personal/hr-management/lohn-und-gehaltsabrechnung-fehler-fuehren-zu-hohen-kosten_80_683674.html). Diese Größenordnung steht in keiner Bilanz als vermeidbar markiert. Sie versteckt sich in versäumten Meldungen und falsch geführten Merkmalen.

## Die Mitbestimmung entscheidet über die Einführung, nicht die Funktion

Ein Lohnsystem wird nicht akzeptiert, weil es technisch funktioniert, sondern weil der Betriebsrat es trägt. Nach Paragraph 87 Absatz 1 Nummer 6 BetrVG ist jede Personalsoftware, die personenbezogene Daten speichert, eine technische Einrichtung, die zur Überwachung geeignet ist, und damit erzwingbar mitbestimmungspflichtig. Es genügt die Eignung zur Verhaltens- und Leistungskontrolle; die Absicht spielt keine Rolle.

Das verschiebt die eigentliche Hürde von der Technik in die Governance. Wer ein System einführt, ohne diese Zustimmung zu dokumentieren, riskiert die Einigungsstelle, ein Beschlussverfahren vor dem Arbeitsgericht und im Ergebnis ein Nutzungsverbot für eine bereits laufende Lösung. Die zentrale Frage vor jedem Rollout lautet deshalb nicht, ob das System rechnet, sondern ob der Betriebsrat unterschreibt. Genau diese Unterschrift muss vorbereitet sein, bevor das System produktiv geht.

## Der Decision-Layer beantwortet die Frage des Betriebsrats, bevor sie gestellt wird

Dieser Agent ist kein weiteres Lohnsystem, sondern eine Schicht über den bestehenden Systemen. Er nimmt einem Abrechnungssystem nichts weg, sondern macht den vorgelagerten Prozess prüfbar, indem er für jeden Schritt dokumentiert, ob er regelbasiert, von einer KI nur angezeigt oder menschlich entschieden wurde.

Diese Unterscheidung ist die direkte Antwort auf zwei Vorbehalte zugleich. Artikel 22 DSGVO verbietet vollautomatisierte Einzelentscheidungen mit erheblicher Wirkung, und ein Lohnvorgang hat erhebliche Wirkung. Der [Decision Layer](/de/decision-layer/) weist nach, dass keine lohnwirksame Entscheidung allein von einer Maschine getroffen wird, und liefert damit dem Betriebsrat den Beleg, dass die KI nur als Indikator dient und niemals selbst einen Datensatz ändert. So wird aus einer Blockade-Diskussion eine Zustimmungsgrundlage.

## Meldungen und Stammdaten sind Regelwerk, kein Ermessen

Die überwiegende Mehrheit der Prozessschritte ist deterministisch und gehört deshalb ins Regelwerk, nicht in ein KI-Modell. Die Anmeldung zur Sozialversicherung folgt nach Paragraph 28a SGB IV einem festen Verordnungslayout und einer harten Frist: spätestens mit der ersten Entgeltabrechnung, in Risikobranchen wie Bau, Gastronomie, Logistik oder Reinigung sogar als Sofortmeldung vor Arbeitsantritt. Versäumt ein Betrieb das, drohen Bußgeld und im Sofortmeldungs-Sektor der Anfangsverdacht auf Schwarzarbeit bei einer Kontrolle.

Auch der Abruf der Lohnsteuerabzugsmerkmale aus dem ELStAM-Verfahren nach Paragraph 39e EStG ist regelbasiert, ebenso die Prüfung gegen die gesetzliche Lohnuntergrenze von [13,90 Euro je Stunde ab dem 1. Januar 2026](https://www.bmas.de/DE/Arbeit/Arbeitsrecht/Mindestlohn/mindestlohn.html). Ein falsch geführtes Merkmal multipliziert sich über zwölf Monate zu einer Nachforderung und fällt unter die Arbeitgeber-Haftung nach Paragraph 42d EStG. Weil diese Schritte einer festen Logik folgen, müssen sie als Regel implementiert sein, nachvollziehbar und reproduzierbar, nicht als Wahrscheinlichkeitsaussage eines Modells.

## Die KI zeigt an, der Mensch entscheidet, und der Audit-Trail beweist beides

Künstliche Intelligenz hat im Lohnprozess eine eng umrissene Rolle: Sie erkennt Auffälligkeiten in den Daten, die ein Mensch prüfen muss, und bewertet ausdrücklich nicht die Leistung oder das Verhalten von Beschäftigten. Ein untypischer Steuerklassenwechsel, ein Stammdatensatz, der von der Vorperiode abweicht, eine auffällige Konstellation bei variablen Bezügen, solche Muster meldet ein Modell zuverlässig zur Prüfung. Aber die Meldung ist kein Beschluss. Die KI markiert den Fall, der Mensch entscheidet, und der Datensatz bleibt unverändert, bis ein Mensch ihn freigibt.

Bestimmte Weichenstellungen bleiben ganz beim Menschen. Die Unterscheidung zwischen einem ärztlichen Beschäftigungsverbot und einer freiwilligen Erklärung im Mutterschutz ist eine Beurteilung von Gesundheitsdaten nach Artikel 9 DSGVO. Die Freigabe vor dem Zahllauf ist eine Letztverantwortung im Vier-Augen-Prinzip. Jede dieser Entscheidungen wird im Audit-Trail festgehalten, lückenlos, unveränderbar und nachvollziehbar. Das ist zugleich die Grundlage für die SV-Betriebsprüfung nach Paragraph 28p SGB IV, deren Fallauswahl die Rentenversicherung mit dem System [KIRA](https://www.deutsche-rentenversicherung.de/DRV/DE/Experten/Arbeitgeber-und-Steuerberater/summa-summarum/Lexikon/K/kira.html) seit 2025 KI-gestützt vorbereitet und ab 2026 flächendeckend einsetzen will: Wer hier Lücken hat, riskiert Beanstandung und Schätzung.

## Prüfungssicher wird der Prozess durch lückenlose Nachvollziehbarkeit, nicht durch neue Software

Der eigentliche Wert dieses Agenten ist nicht eine weitere Automatisierung, sondern die revisionssichere Dokumentation jedes Prozessschritts. Sie verwandelt den Lohnprozess von einer Blackbox in einen prüfbaren Vorgang, und genau das verlangen die SV-Betriebsprüfung und der Betriebsrat gleichermaßen. Wo Standardanbieter Compliance als Feature-Haken behaupten, macht dieser Agent sie zur Architektur: Audit-Trail, Vier-Augen-Prinzip und menschliche Eskalation sind strukturell verankert, nicht nachträglich angeklebt.

Dazu gehört eine ehrliche Abgrenzung. Dieser Agent verantwortet den vorgelagerten HR-Prozess von Eintritt, Austritt und Stammdaten bis zu Meldungen und Freigaben. Die Brutto-Netto-Mathematik mit Lohnsteuer, Sozialabgaben und Pfändungsgrenzen liegt bewusst beim separaten Lohnbuchhaltungs-Agent. Diese Trennung ist selbst ein Vertrauenssignal gegenüber Wettbewerbern, die alles in einem Versprechen bündeln. Der nächste Schritt ist deshalb keine Software-Einführung, sondern eine Analyse, welche Schritte Ihres heutigen Lohnprozesses noch ohne dokumentierten Entscheider laufen.

--- HR-Reporting-Agent ---
> HR-Reporting aus Lohndaten: Personalkosten-Dashboards, CSRD-Sozialkennzahlen und Equal-Pay - jede Zahl mit benanntem Entscheider, testierbar statt Blackbox.

## Aus Lohndaten wird Steuerung und Nachhaltigkeitsbericht, und der Engpass ist die Verantwortung, nicht die Rechenleistung.

HR-Reporting wird oft als Knopfdruck missverstanden: Daten rein, Bericht raus. Tatsächlich muss dieselbe abgeschlossene Lohnabrechnung zwei sehr verschiedene Welten bedienen. Die Geschäftsleitung will wissen, was das Personal kostet und wohin sich die Kosten entwickeln. Der Lagebericht verlangt Sozialkennzahlen zu Lohngerechtigkeit, Vergütungsverteilung und Diversität, die einer Wirtschaftsprüfung standhalten. Beide Welten werden aus denselben Rohdaten gespeist, folgen aber einer völlig anderen Logik und einer eigenen Haftung.

Wer in der Personalverantwortung steht, kennt die eigentliche Schwierigkeit: Es ist selten die Berechnung, die scheitert. Es ist die Frage, ob der Betriebsrat das System mitträgt, ob die Rechtsabteilung statt eines pauschalen Nein ein belastbares Ja-wenn liefert, und ob die Zahl, die dem Vorstand präsentiert wird, später vor dem Wirtschaftsprüfer Bestand hat. Diese drei Hürden entscheiden über den Erfolg eines Reporting-Projekts, nicht die Rechen-Engine.

## CSRD-Sozialkennzahlen sind die neue Pflichtübung mit Testat-Risiko.

Mit der CSRD ist ein Reporting-Block entstanden, der direkt aus den Lohndaten gespeist wird. Die ESRS-S1-Standards verlangen Sozialkennzahlen wie die Vergütungsverteilung als Median, Mittelwert und Quartile, die Equal-Pay-Differenz je Vergleichsgruppe und Diversitätskennzahlen. Diese Zahlen wandern in den Lagebericht und werden dort vom Wirtschaftsprüfer nach den einschlägigen Lagebericht-Prüfungsstandards testiert (in Deutschland IDW PS 350 n.F., international ISSA 5000). Sind sie nicht belastbar, folgt ein Mängelbericht und ein eingeschränktes Testat, das für Kapitalmarkt und Aufsichtsrat sichtbar bleibt.

Wichtig für die Planung: Durch das im Dezember 2025 beschlossene Omnibus-Paket gilt die Berichtspflicht nur noch für Unternehmen mit über 1.000 Mitarbeitenden und über 450 Millionen Euro Umsatz, mit zwei Jahren Fristverschiebung ([EU-Rat, Dezember 2025](https://www.consilium.europa.eu/en/press/press-releases/2025/12/09/council-and-parliament-strike-a-deal-to-simplify-sustainability-reporting-and-due-diligence-requirements-and-boost-eu-competitiveness/)). Die CSRD-Frist entspannt sich damit für manche Häuser, die Entgelttransparenz aber nicht: Deren Stichtag 7. Juni 2026 bleibt unberührt und verlangt dieselben Equal-Pay-Kennzahlen aus denselben Lohndaten. Wer die Datenkette jetzt aufsetzt, bedient beide Pflichten mit einer Architektur.

## Equal-Pay ist die Kennzahl, die nicht nur berichtet, sondern begründet werden muss.

Der unbereinigte Gender Pay Gap in Deutschland lag 2024 bei 16 Prozent, bereinigt bei 6 Prozent ([Statistisches Bundesamt, Februar 2025](https://www.destatis.de/DE/Presse/Pressemitteilungen/2025/02/PD25_056_621.html)). Diese Werte zeigen, wie weit der Markt von Lohngleichheit entfernt ist. Konkret schaltet die EU-Entgelttransparenz-Richtlinie eine gemeinsame Entgeltbewertung mit der Arbeitnehmervertretung frei, sobald die durchschnittliche Lohndifferenz in einer Arbeitnehmer-Kategorie mehr als 5 Prozent beträgt und nicht sachlich gerechtfertigt ist. Damit wird die Equal-Pay-Zahl zu einem Thema, das nicht nur gemeldet, sondern verteidigt werden muss.

Die Richtlinie ist bis zum 7. Juni 2026 umzusetzen, das deutsche Umsetzungsgesetz steht noch aus ([Grant Thornton, 2026](https://www.grantthornton.de/themen/2026/eu-entgelttransparenzrichtlinie-ist-der-7-juni-2026-ein-harter-stichtag/)). Wer die Berechnung erst aufsetzt, wenn das Gesetz in Kraft tritt, hat keine Vergleichswerte und keine Begründungs-Historie. Wer dagegen die Equal-Pay-Kennzahl heute schon sauber je Vergleichsgruppe ermittelt und dokumentiert, kann eine gemeldete Differenz später mit nachvollziehbaren Zahlen rechtfertigen statt mit einer Behauptung.

## Personalkosten-Reporting ist Steuerung und Pflicht in einem.

Die Geschäftsleitung braucht Personalkosten-Reports nicht aus Neugier, sondern zur Steuerung. Personalkosten sind in den meisten Unternehmen der größte Aufwandsposten, und ihre Entwicklung entscheidet über Budgets, Einstellungen und Standortfragen. Ein belastbares Reporting verteilt die Kosten korrekt auf Standorte und Kostenstellen, vergleicht Ist gegen Budget und zeigt nicht nur, was war, sondern wohin sich die Kosten entwickeln. Genau diese Aggregation ist reine Regelarbeit und damit deterministisch lösbar.

Die Anforderung an diese Reports ist nicht Geschwindigkeit, sondern Verlässlichkeit. Ein Management-Report, der die Kosten falsch verteilt, führt zu falschen Entscheidungen, die teurer sind als jede verspätete Auswertung. Deshalb steht am Anfang jedes Reports eine maschinelle Plausibilitätsprüfung und am Ende eine menschliche Freigabe im Vier-Augen-Prinzip, bevor eine Zahl die Steuerung beeinflusst.

## Jede Reporting-Zahl braucht einen Entscheider, nicht nur eine Visualisierung.

Übliche People-Analytics-Werkzeuge zeigen Dashboards: bunte Diagramme, Trends, Vergleiche und KI-gestützte Empfehlungen. Was sie nicht zeigen, ist, wer für eine Zahl verantwortlich ist und wie sie zustande kam. Genau hier setzt der Decision-Layer-Ansatz an. Der [Decision Layer](/de/decision-layer/) ordnet jede Kennzahl einem klaren Entscheider zu: dem Regelwerk, das deterministisch rechnet, der KI, die nur Auffälligkeiten meldet, und dem Menschen, der interpretiert und freigibt.

Diese Trennung ist kein theoretisches Konstrukt, sondern genau das, was Betriebsrat und Wirtschaftsprüfer verlangen. Die meisten Schritte sind reine Regelwerk-Arbeit: die Aggregation nach Kostenstellen, die Berechnung der Vergütungsquartile, die Durchsetzung der k-Anonymität mit fester Mindest-Gruppengröße. Die KI ist bewusst auf die Rolle des Frühwarners degradiert, der einen Kostensprung oder eine auffällige Lohnlücke markiert, aber nie korrigiert oder entscheidet. Und was eine Lücke bedeutet und ob sie sachlich gerechtfertigt ist, bleibt eine rechtliche und geschäftliche Wertung des Menschen. Diese Degradierung der KI auf einen reinen Indikator ist das Gegenteil der Blackbox-Empfehlungen der Wettbewerber und der Grund, warum der Betriebsrat nach Paragraph 87 BetrVG zustimmen kann.

## Auditierbarkeit ist Architektur-Nebenprodukt, nicht nachträgliche Doku.

Eine Reporting-Kennzahl ist nur so gut wie ihre Nachvollziehbarkeit. Wenn der Wirtschaftsprüfer fragt, wie die Equal-Pay-Differenz berechnet wurde, muss die Antwort lückenlos sein: aus welchen Lohndaten, mit welcher Formel, mit welcher Gruppenbildung und in welcher Regelwerk-Version. Diese Nachvollziehbarkeit entsteht nicht durch ein nachträgliches Compliance-PDF, sondern dadurch, dass das System regelbasiert aggregiert und dabei jeden Schritt protokolliert. Steuerrelevante Lohnauswertungen sind ohnehin bis zu zehn Jahre aufbewahrungspflichtig und unterliegen dem Datenzugriff der Betriebsprüfung.

Jede Kennzahl trägt ihren Daten- und Berechnungs-Trail mit sich. Das ist der entscheidende Unterschied zu einer Dashboard-Lösung, die nur das Ergebnis zeigt und den Audit-Log nachträglich anhängt. Bei einer Wirtschaftsprüfung oder einer Anfrage der Datenschutzbehörde ist dieser Trail der Unterschied zwischen einer testierbaren Zahl und einer bloßen Behauptung. So wird Auditierbarkeit vom teuren Nachgang zum kostenlosen Nebenprodukt der Architektur.

## HR-Reporting ist die Schicht, die Lohndaten in verantwortete Entscheidungen verwandelt.

Der HR-Reporting-Agent ersetzt weder das Lohnsystem noch die Fachabteilung, sondern legt eine Entscheidungs- und Dokumentationsschicht über die bestehende Lohn- und Personalsoftware. Er nimmt die abgestimmten Lohndaten aus Systemen wie DATEV oder SAP und verwandelt sie in zwei Arten belastbarer Ergebnisse: Management-Reports für die Steuerung und testierbare Sozialkennzahlen für den Lagebericht. Die Übermittlung an Behörden bleibt bewusst beim Lohnsteuer-Agent, damit diese Schicht sich auf das konzentriert, was sie einzigartig macht: prüfbare Kennzahlen mit benanntem Entscheider.

Damit schließt sich der Kreis zur Lohnabrechnung: Was dort abgerechnet wird, wird hier ausgewertet, verantwortet und berichtet. Der nächste logische Schritt ist eine Prozess-Analyse Ihrer bestehenden Reporting-Strecke, die zeigt, welche Kennzahlen heute schon regelbasiert entstehen können und an welcher Stelle noch ein Mensch entscheiden muss, bevor eine Zahl das Haus verlässt.

## Auf einen Blick

Die wichtigsten Eckdaten dieses Agenten im Überblick, bevor Sie in die Details einsteigen.

| Kriterium | Wert |
| --- | --- |
| Aufgabe | Lohndaten in prüfungssichere Management-Reports und CSRD-Sozialkennzahlen verwandeln |
| Entscheidungslogik | Regelwerk rechnet, KI meldet Auffälligkeiten, Mensch gibt frei |
| Compliance-Anker | DSGVO Art. 88, BetrVG Paragraph 87, AO Paragraph 147, ESRS S1 |
| Prüfungsstandard | Lagebericht-Testat nach IDW PS 350 n.F. (international ISSA 5000) |
| Equal-Pay-Treiber | Entgelttransparenz-Richtlinie 2023/970, Stichtag 7. Juni 2026 |
| Integration | DATEV, SAP, Personio, Power BI als Datenquellen |
| Prüfungsfall | Jede Kennzahl bis zur Einzelbuchung rückverfolgbar |

--- People-Analytics Agent ---
> Analysiert Fluktuation, Engagement, Diversity und Produktivität auf Muster und Trends. Hochrisiko-System nach EU AI Act.

HR besitzt die Daten, die strategische Personalentscheidungen tragen könnten. Fluktuation nach Bereich, Engagement nach Standort, Diversity nach Hierarchieebene. Doch nur 8 Prozent der Unternehmen berichten, dass ihre HR-Daten tatsächlich nutzbar sind (Deloitte, Human Capital Trends). Der Rest exportiert Tabellen, baut Wochen an Präsentationen und liefert Antworten, die zu spät kommen, an der Oberfläche bleiben und die eigentliche Frage verfehlen.

Das Problem ist nicht der Mangel an Daten. Es ist der Mangel an Architektur. Wer People Analytics betreibt, ohne Analyse von Überwachung strukturell zu trennen, bekommt weder Akzeptanz beim Betriebsrat noch Konformität mit dem EU AI Act.

## Warum People Analytics in der Praxis steckenbleibt

76 Prozent aller Unternehmen betreiben irgendeine Form von People Analytics. Aber nur 9 Prozent verstehen, welche Talentdimensionen tatsächlich Leistung treiben (Deloitte, 2024). Zwischen dem, was HR an Daten besitzt, und dem, was davon in strategischen Entscheidungen ankommt, liegt eine Kluft. Drei Ursachen halten sie offen.

**Fragmentierte Datenbasis.** Personaldaten leben in SAP oder Personio, Engagement-Werte in einem Survey-Tool, Fluktuationsgründe in Excel-Listen der Führungskräfte. Datenintegration gehört nach EY-Befragungen regelmäßig zu den größten Hindernissen der HR-Digitalisierung. Der verdeckte Schaden: Schlechte Datenqualität erzwingt Korrekturarbeit, bindet Kapazität und verfälscht jede Analyse, die darauf aufsetzt - oft gravierender als das Fehlen von Analyse-Tools.

**Keine Übersetzung in Entscheidungssprache.** HR berichtet Headcount, Krankenquote, Schulungstage. Die Geschäftsführung denkt in Umsatz pro Kopf, Time-to-Market, Kundenabwanderung. Solange Fluktuation nicht mit ihren wirtschaftlichen Folgekosten verknüpft ist, bleibt People Analytics ein Verwaltungsbericht. Best Buy hat den Zusammenhang beziffert: 0,1 Punkte mehr Engagement korrelierten mit 100.000 USD zusätzlichem Umsatz pro Filiale. Die meisten HR-Abteilungen können eine solche Verknüpfung nicht herstellen - nicht weil die Daten fehlen, sondern weil niemand definiert hat, welche Verknüpfungen strategisch relevant sind.

**Vermischung von Analyse und Überwachung.** People Analytics soll Muster in aggregierten Daten erkennen. Doch ohne klare technische Grenzen gleitet die Analyse unmerklich in die Leistungsüberwachung einzelner Beschäftigter. Der Betriebsrat blockiert. Die Belegschaft misstraut. Das Projekt stirbt nicht an der Technik, sondern am Vertrauensverlust.

## Hochrisiko - die regulatorische Realität (Frist 2026/2027)

Der EU AI Act klassifiziert People-Analytics-Systeme als Hochrisiko nach Annex III, Kategorie 4(b): KI-Systeme zur Überwachung und Bewertung von Verhalten am Arbeitsplatz. Auch wenn der Agent ausschließlich aggregiert analysiert, können die Ergebnisse Personalentscheidungen beeinflussen. Das reicht für die Klassifikation.

Hochrisiko-Systeme müssen folgende Anforderungen erfüllen - maßgeblich ist nach aktuellem Recht der 2. August 2026, voraussichtlich verschoben auf den 2. Dezember 2027 (Digital Omnibus, vorläufige Einigung Mai 2026, formale Verabschiedung ausstehend):

- Risikomanagementsystem mit dokumentierter Folgenabschätzung
- Datenqualitätsanforderungen und technische Dokumentation
- Transparenz gegenüber betroffenen Beschäftigten
- Menschliche Aufsicht durch fachlich kompetente Personen
- CE-Kennzeichnung und Registrierung in der EU-Datenbank

Parallel greift deutsches Recht. BetrVG Paragraph 87 Abs. 1 Nr. 6 erzwingt Mitbestimmung bei technischen Einrichtungen, die zur Leistungs- und Verhaltenskontrolle geeignet sind. Das Bundesarbeitsgericht hat klargestellt: Die subjektive Absicht des Arbeitgebers ist irrelevant. Entscheidend ist die objektive Eignung des Systems. Ein People-Analytics-Tool ist per Definition geeignet.

DSGVO Art. 35 verlangt eine Datenschutz-Folgenabschätzung, wenn eine Verarbeitung voraussichtlich ein hohes Risiko für die Rechte natürlicher Personen birgt. Systematische Analyse von Beschäftigtendaten erfüllt dieses Kriterium.

Wer diese drei Rechtsrahmen nicht zusammendenkt, baut ein System, das technisch funktioniert und rechtlich unhaltbar ist.

## Was Architektur löst, das Technologie allein nicht kann

Die zentrale Frage ist nicht: Welches Tool analysiert die Daten? Sondern: Wer definiert die Frage, wer interpretiert das Ergebnis, wer entscheidet?

Der [Decision Layer](/de/decision-layer/) zerlegt den Analytics-Prozess in diskrete Entscheidungsschritte. Jeder Schritt hat einen definierten Verantwortlichen: Mensch, Regelwerk oder KI-Agent.

```
Fragestellung       Datenschutz-       Daten              Muster
definieren     -->  Prüfung       -->  aggregieren   -->  identifizieren
(Mensch)            (Regelwerk)        (Regelwerk)        (Agent)

Befunde             Handlungs-         Ergebnisse
validieren     -->  empfehlungen  -->  präsentieren
(Mensch)            (Agent)            (Agent)
```

Die Trennung ist kein Formalismus. Sie löst das Kernproblem, an dem People Analytics in der Praxis scheitert.

**Schritt 1: Fragestellung definieren (Mensch).** Analytics ohne strategische Frage produziert Berichte, die niemand angefordert hat. Der Prozess beginnt erst, wenn HR-Leitung oder Geschäftsführung eine konkrete Entscheidung vorbereiten: Brauchen wir im Vertrieb ein Retention-Programm? Entwickelt sich die Engagement-Lücke zwischen Standorten auseinander?

**Schritt 2: Datenschutz-Prüfung (Regelwerk).** Bevor ein einziger Datenpunkt aggregiert wird, prüft das Regelwerk die geplante Analyse gegen DSGVO, Betriebsvereinbarung und interne Richtlinien. Analysen, die keine Rechtsgrundlage haben, starten nicht.

**Schritt 3: Daten aggregieren (Regelwerk).** HR-Kerndaten, Engagement-Scores und Fluktuationsdaten werden zusammengeführt und anonymisiert. Gruppen unter einer definierten Mindestgröße werden zusammengefasst. Das ist keine Richtlinie, sondern eine technische Sperre: Personenbezogene Rückschlüsse sind nicht möglich, weil die Architektur sie verhindert.

**Schritt 4: Muster identifizieren (Agent).** Der Agent erkennt Korrelationen, Trends und Ausreißer in den aggregierten Daten. Wo steigt Fluktuation schneller als im Unternehmensschnitt? Welche Bereiche zeigen sinkende Engagement-Werte bei gleichzeitig steigender Überstundenquote? Prädiktive Modelle identifizieren gefährdete Bereiche 60 bis 90 Tage bevor Kündigungen eintreten.

**Schritt 5: Befunde validieren (Mensch).** Ein statistisches Muster ist keine Ursache. Korreliert sinkende Zufriedenheit im Bereich X mit der Restrukturierung vom letzten Quartal - oder mit dem Führungswechsel? Der HR-Analytics-Spezialist prüft Signifikanz, Plausibilität und Kontext. Der Agent liefert die Evidenz. Die Interpretation trifft ein Mensch mit Domänenwissen.

**Schritt 6-7: Empfehlungen und Aufbereitung (Agent).** Der Agent formuliert evidenzbasierte Handlungsempfehlungen mit Konfidenzangabe und bereitet sie managementtauglich auf. Nicht 40 Kennzahlen auf einem Dashboard, sondern drei bis fünf Erkenntnisse, verknüpft mit Geschäftswirkung und konkreten Handlungsoptionen.

## Die Grenze zwischen Analyse und Überwachung ist eine Architekturentscheidung

Kein Vertrauensproblem lässt sich durch ein besseres Dashboard lösen. Die Akzeptanz von People Analytics hängt davon ab, ob die Grenze zwischen Mustererkennung in aggregierten Daten und Bewertung einzelner Beschäftigter nicht nur versprochen, sondern technisch erzwungen wird.

Drei Architekturprinzipien stellen das sicher:

**Aggregation als technische Sperre.** Mindestgruppengrößen werden nicht als Policy definiert, sondern als Systemparameter implementiert. Eine Analyse mit zu kleiner Grundgesamtheit liefert kein Ergebnis - nicht eine Warnung, sondern keine Ausgabe.

**Keine Rückrechnung auf Individuen.** Die Anonymisierungslogik verhindert, dass die Kombination mehrerer aggregierter Auswertungen einzelne Personen identifizierbar macht. Das ist mathematisch lösbar und technisch umsetzbar - aber nur, wenn es von Anfang an in der Architektur verankert ist.

**Vollständige Entscheidungsakte.** Jede Analyse wird dokumentiert: Fragestellung, Rechtsgrundlage, Aggregationsebene, Ergebnis, abgeleitete Maßnahme. Der Betriebsrat hat Einsichtsrecht. Betroffene Beschäftigte können nachvollziehen, welche Analysen durchgeführt wurden und welche Entscheidungen darauf basieren.

Dieses Framework ist gleichzeitig die Betriebsvereinbarung. Wer die Architektur sauber dokumentiert, hat das Verhandlungsergebnis mit dem Betriebsrat bereits strukturiert. Klare Grenzen erhöhen die Akzeptanz und reduzieren Governance-Risiken - das ist kein Kompromiss, sondern ein strategischer Vorteil.

## Infrastruktur, die über den einzelnen Agenten hinaus wirkt

Die Analyse-Engine, die hier entsteht - Fluktuation, Engagement, Equity - wird vom Strategic-HR-Analytics-Agent für Board-Reporting und vom Merit-Cycle-Governance-Agent für Vergütungsanalysen wiederverwendet. Die Anonymisierungs- und Mindestgruppengrößen-Logik wird zum Standard für jeden Agenten, der personenbezogene Daten verarbeitet. Das Governance-Framework - welche Analysen erlaubt sind, welche nicht, unter welchen Bedingungen - bildet die Grundlage für alle Hochrisiko-Agenten im H4-Horizont.

Der eigentliche Wert liegt nicht in den Analyseergebnissen eines einzelnen Quartals. Er liegt in der Infrastruktur, die People Analytics von einem Governance-Risiko in ein Governance-Werkzeug verwandelt: nachvollziehbar, anfechtbar, wiederholbar. Organisationen, die diesen Reifegrad erreichen, treffen datengestützte Entscheidungen schneller und haben laut Deloitte Human Capital Trends eine messbar höhere Wahrscheinlichkeit, im Wettbewerbsvergleich überdurchschnittlich abzuschneiden.

--- Performance-Review-Dokumentations-Agent ---
> Strukturiert den Beurteilungsprozess und dokumentiert Ergebnisse revisionssicher. Hochrisiko-System nach EU AI Act Annex III.

## Die Beurteilung ist selten das Problem. Die Dokumentation ist es.

Dieser Agent folgt dem [Decision Layer](/de/decision-layer/)-Prinzip: jede Entscheidung ist entweder regelbasiert, KI-assistiert oder explizit einem Menschen zugeordnet.

Führungskräfte können Leistung einschätzen. Was sie nicht können: ein Jahr Beobachtungen in eine konsistente, belegbare, rechtssichere Akte überführen. Die Folge ist ein Dokumentationsprozess, der systematisch Widersprüche produziert - zwischen Rating und Begründung, zwischen Selbsteinschätzung und Fremdwahrnehmung, zwischen dem, was im Gespräch gesagt wurde, und dem, was in der Akte steht.

Das ist kein Qualitätsproblem einzelner Führungskräfte. Es ist ein Strukturproblem. Und es wird zum Rechtsrisiko, sobald eine Kündigung, eine verweigerte Beförderung oder ein Arbeitsgerichtsverfahren auf genau diese Akte zugreift.

## Drei Muster, die im manuellen Prozess unsichtbar bleiben

**Rating-Text-Divergenz.** Eine Führungskraft vergibt "Erwartungen übertroffen", schreibt aber in der Begründung drei Absätze über Verbesserungsbedarf. Oder umgekehrt: "Erwartungen teilweise erfüllt" mit einer Begründung, die ausschließlich Stärken nennt. Forschung zeigt, dass über 60 Prozent der Varianz in Leistungsbewertungen vom Bewertenden stammt - nicht von der bewerteten Person. In Einzelfällen fällt die Diskrepanz auf. Über 200, 500, 1.000 Beurteilungen pro Zyklus fällt sie niemandem auf, weil niemand alle Dokumente liest.

**Recency Bias als Dokumentationslücke.** Recency Bias gilt als häufigster Bewertungsfehler in Unternehmen. Führungskräfte, die keine laufenden Notizen führen - und die große Mehrheit führt keine - rekonstruieren zwölf Monate Leistung aus den letzten sechs Wochen. Das Projekt, das im Februar herausragend lief, existiert im Dezember nicht mehr. Der Fehler vom November dominiert die gesamte Beurteilung. Die Dokumentation bildet nicht die Leistung ab. Sie bildet die Erinnerung ab.

**Bewertungs-Bias, der in Einzeldaten verschwindet.** Wenn ein Manager vier Frauen im Team jeweils mit "erfüllt Erwartungen" bewertet und vier Männer mit "übertrifft Erwartungen", ist das für sich genommen unauffällig. Vielleicht stimmt es sogar im Einzelfall. Aber wenn sich dieses Muster über 30 Teams reproduziert, ist es kein Zufall mehr. HBR-Forschung belegt: 61 Prozent der Frauen erhalten Feedback zu ihrem Kommunikationsstil - bei Männern liegt der Wert bei einem Prozent. Solche Muster sind manuell nicht erkennbar, weil sie erst in der Aggregation sichtbar werden.

## Warum bessere Formulare das Problem nicht lösen

Der naheliegende Reflex: strukturiertere Templates, Pflichtfelder, vorformulierte Textbausteine. Aber ein Formular kann nicht prüfen, ob die Begründung zum Rating passt. Es kann nicht erkennen, ob die Selbsteinschätzung eines Mitarbeitenden systematisch von der Fremdwahrnehmung abweicht. Es kann nicht feststellen, ob ein Manager seit drei Zyklen dieselben Formulierungen kopiert. Und es kann nicht über 40 Teams hinweg analysieren, ob sich Bewertungsmuster nach Geschlecht, Alter oder Teilzeitstatus unterscheiden.

Die Aufgabe besteht nicht darin, das Formular zu verbessern. Sie besteht darin, den Beurteilungsprozess so zu zerlegen, dass jeder Schritt eine klare Zuordnung hat: Wer entscheidet? Nach welcher Regel? Mit welcher Prüfung?

## Elf Schritte, drei Entscheidungsprinzipien

```
Zyklus             Formulare           Selbstein-          Führungskraft
starten       -->  verteilen      -->  schätzung      -->  bewertet
(R: Kalender)      (R: Zuordnung)      (R: Regelwerk)      (H: Beobachtung)

Konsistenz-        Kalibrierung        Bias-               Bias-Befund
Check         -->  unterstützen   -->  Analyse        -->  eskalieren
(A: Rating/Text)   (A: Verteilung)     (A: Statistik)      (R: Schwellenwert)

Gespräch           Ergebnis            Folgemaßnahmen
terminieren   -->  dokumentieren  -->  auslösen
(A: Kalender)      (R: Archivierung)   (R: regelbasiert)
```

Der entscheidende Unterschied zum manuellen Prozess: Die Schritte 5, 6 und 7 laufen parallel zur Bewertung, nicht danach. Wenn eine Führungskraft ein Rating vergibt und die Begründung einträgt, wird sofort geprüft, ob beides zusammenpasst. Die Kalibrierungsansicht aktualisiert sich in Echtzeit. Die Bias-Analyse berechnet laufend, ob sich Muster bilden.

Das verändert den Charakter der Kalibrierungsrunde. Statt Ratings nachträglich zu vergleichen, sehen Führungskräfte bei der Eingabe, wo ihre Bewertung im Kontext steht: Verteilung im Team, Abweichung vom Abteilungsdurchschnitt, Konsistenz mit vorherigen Zyklen. Das Gespräch verschiebt sich von "Stimmen wir über Noten ab?" zu "Wo weichen wir bewusst vom Muster ab und warum?"

## Konsistenzprüfung als struktureller Vorteil

Die automatische Prüfung, ob Rating und textuelle Begründung zusammenpassen, ist kein Komfortfeature. Sie ist der Hauptgrund, warum eine regelbasierte Orchestrierung dem manuellen Prozess überlegen ist. Ein Mensch, der 400 Beurteilungsbögen liest, kann nicht systematisch erkennen, wo Wort und Zahl auseinanderlaufen. Der Agent erkennt den Widerspruch sofort und markiert ihn - nicht in einem Report, der Wochen später auf dem Schreibtisch landet, sondern während die Führungskraft noch im Bewertungsprozess ist und korrigieren kann.

Für Unternehmen, die unter das Hochrisiko-Regime des EU AI Act fallen - für Systeme, die Leistung und Verhalten am Arbeitsplatz bewerten, greifen die Pflichten nach aktuellem Recht ab dem 2. August 2026, voraussichtlich verschoben auf Dezember 2027 (Digital Omnibus, Mai 2026) - ist Nachvollziehbarkeit keine Option. Sie ist eine rechtliche Anforderung. Annex III(4)(b) verlangt Risikomanagementsystem, Transparenz gegenüber Betroffenen und menschliche Aufsicht. Diese Anforderungen sind hier nicht nachträglich aufgesetzt. Sie sind in der Architektur angelegt: Die Bewertung bleibt beim Menschen. Der Agent dokumentiert, prüft und analysiert.

## Was am Ende entsteht

Der Agent trifft keine einzige Leistungsbeurteilung. Er sorgt dafür, dass jede Beurteilung konsistent begründet, vollständig dokumentiert und auf systematische Muster geprüft ist. Das Rating vergibt die Führungskraft. Das Gespräch führt der Mensch. Die Kalibrierung verantwortet die HR-Leitung.

Die Infrastruktur, die dabei entsteht - Konsistenz-Engine, Bias-Analyse, Kalibrierungsframework, revisionssichere Archivierung - wird nicht für einen einzelnen Beurteilungszyklus gebaut. Die Bias-Analyse wird vom Merit-Cycle-Governance-Agent und Promotion-Process-Agent wiederverwendet. Das Konsistenz-Prüfungsmuster wird zum Standard für alle Agenten, die menschliche Bewertungen auf Kohärenz prüfen. Die Entscheidungsakte, die pro Beurteilung entsteht, macht jede einzelne Bewertung nachvollziehbar und anfechtbar - für die betroffene Person genauso wie für den Betriebsrat.

--- Richtlinien-Agent ---
> HR-Richtlinien-Lifecycle mit prüfbarer Zuständigkeit: Das Regelwerk klassifiziert die Mitbestimmung, die KI prüft die Sprache, der Mensch gibt frei.

## Jede Plattform verwaltet Richtlinien. Keine beweist, dass sie gilt.

SAP SuccessFactors, Personio, Workday, Confluence - jede dieser Plattformen kann eine HR-Richtlinie verfassen, versionieren, verteilen und signieren lassen. Das ist seit Jahren Standard. Die Frage, an der Wirksamkeit und Haftung wirklich hängen, beantwortet keines dieser Systeme: Ist diese Richtlinie mitbestimmungssauber, diskriminierungsfrei und datenschutzkonform zustande gekommen - und können Sie das dem Betriebsrat und dem Vorstand getrennt belegen?

Dieser Agent folgt dem [Decision Layer](/de/decision-layer/)-Prinzip: Jeder Schritt im Richtlinien-Lebenszyklus ist entweder eine deterministische Klassifikation gegen das Gesetz, ein anfechtbarer KI-Vorschlag oder eine menschliche Freigabe - getrennt und nachweisbar. Nach [EU AI Act](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) ist er kein Hochrisiko-System, weil ein Richtlinien-Dokument keine Menschen bewertet. Seine Anforderungen kommen aus dem kollektiven Arbeitsrecht und dem Datenschutz, und die wiegen schwer genug.

## Warum so viele Richtlinien wirkungslos bleiben

Das verbreitete Bild ist, eine Richtlinie sei fertig, sobald sie geschrieben und im Intranet abgelegt ist. Die Realität ist eine andere, und sie hat zwei Seiten. Auf der einen Seite kennt niemand die geltende Version: Am Beispiel von IT-Sicherheitsrichtlinien zeigt eine Kaspersky-Lab-Studie, dass 88 Prozent der Mitarbeiter die internen Richtlinien ihres Unternehmens nicht kennen und 24 Prozent sogar glauben, es gebe überhaupt keine ([it-daily.net](https://www.it-daily.net/analysen/mitarbeiter-kennen-it-sicherheitsrichtlinien-nicht)). Eine Richtlinie, deren geltende Fassung niemand sicher benennen kann, steuert kein Verhalten.

Auf der anderen Seite, und das ist die teurere, ist die Richtlinie rechtlich gar nicht wirksam. Eine betriebliche Regelung, die unter ein erzwingbares Mitbestimmungsrecht nach Paragraph 87 BetrVG fällt, braucht die Zustimmung des Betriebsrats, bevor sie gilt. Fehlt sie, greift die in der arbeitsgerichtlichen Rechtsprechung gefestigte Folge, dass eine mitbestimmungswidrige Maßnahme gegenüber den Beschäftigten von Anfang an unwirksam ist - der Betriebsrat kann ihre Unterlassung verlangen, notfalls per einstweiliger Verfügung, und kein einzelnes Arbeitsverhältnis lässt sich darauf stützen. Die Richtlinie ist dann wertlos, egal wie sorgfältig sie formuliert war.

Dazu kommen die Risiken im Text selbst. Benachteiligt eine Formulierung jemanden wegen eines nach dem AGG geschützten Merkmals und legt eine betroffene Person dafür Indizien dar, kehrt sich nach Paragraph 22 AGG die Beweislast um - der Arbeitgeber muss das Gegenteil beweisen, und eine Entschädigung nach Paragraph 15 AGG steht verschuldensunabhängig im Raum. Im Datenschutz ist die Größenordnung greifbar: Die Hamburger Aufsichtsbehörde verhängte 2020 ein Bußgeld von 35,3 Millionen Euro gegen H&M wegen überschießender Verarbeitung von Beschäftigtendaten ([LTO](https://www.lto.de/recht/nachrichten/n/datenschutzbeauftragter-hamburg-bussgeld-h-und-m-35-millionen-euro)) - bis heute eines der höchsten DSGVO-Bußgelder in Deutschland und ein konkreter Beleg, wohin eine fehlerhafte Beschäftigtendaten-Politik führen kann.

## Drei Quellen, klar getrennt: wer entscheidet was

Die meisten Anbieter sagen, ein Mensch bleibe "im Prozess", und kleben ein Compliance-Siegel daneben. Das bleibt eine schwarze Box. Der Agent macht stattdessen für jeden Schritt sichtbar, aus welcher von drei Quellen die Entscheidung stammt.

| Quelle | Was sie entscheidet | Beispiel aus dem Richtlinien-Lifecycle |
|--------|---------------------|----------------------------------------|
| **Regelwerk (R)** | Alles Deterministische, kein Ermessen | Mitbestimmungs-Kategorie nach Paragraph 87 BetrVG, Datenschutz nach Artikel 88 DSGVO, Aufbewahrungsfrist |
| **KI-Vorschlag (A)** | Markiert Unsicheres, entscheidet nie | Diskriminierende Sprache im Richtlinientext nach dem AGG, mit Vorschlag inklusiver Alternativen |
| **Mensch (H)** | Bindende Entscheidung und Freigabe | Zustimmung des Betriebsrats, finale Inkraftsetzung durch den Vorstand mit eIDAS-Signatur |

Der Agent ist damit überwiegend ein Klassifikations-Motor gegen das Gesetz, mit KI als anfechtbarem Indikator an genau einer Stelle und einem festen menschlichen Entscheidungs-Gate. Das ist die ehrliche Antwort auf den naheliegenden Einwand "darf eine KI an HR-Richtlinien mitschreiben?". Die KI entscheidet an keiner Stelle etwas rechtlich Bindendes - sie schlägt vor, das Gesetz klassifiziert, der Mensch entscheidet und signiert. Wie diese Schicht architektonisch durchgreift, zeigt der [Decision Layer](/de/decision-layer/).

## Genau das macht die Richtlinie nicht angreifbar, sondern auditierbar

Hier liegt der Unterschied, der über Vertrauen oder Misstrauen entscheidet. Wettbewerber verkaufen Policy-Management als Feature-Liste: Workflow-Engine, Versionierung, Audit-Trail, Signatur, Self-Service-Wiki. Die Botschaft ist "wir können Richtlinien verwalten". Das löst aber nicht den Punkt, an dem eine Personalleitung im Konzern wirklich hängt - nämlich eine Lösung vorzulegen, die der Betriebsrat unterschreibt, bevor sie dem Vorstand präsentiert wird.

Diese Sorge entsteht aus Unsicherheit: "Wir haben KI im HR" klingt für ein Gremium nach Kontrollverlust. Der Agent dreht das um, indem die KI an keiner bindenden Stelle entscheidet. Sie liefert einen Sprach-Indikator, den ein Auditor anfechten kann; das Gesetz klassifiziert die Mitbestimmungs- und Datenschutz-Pflicht deterministisch; der Mensch stimmt zu und signiert. Wer freigibt, sieht dabei jede von der KI vorgeschlagene Sprachmarkierung als solche gekennzeichnet und kann sie übernehmen oder verwerfen - die Entscheidung bleibt nachweisbar beim Menschen, nicht beim Modell. Genau diese Trennung ist die Linie, die sich einem Betriebsrat und einem Vorstand vorlegen lässt: nicht "wir vertrauen einer KI", sondern "die KI schlägt vor, das Gesetz klassifiziert, der Mensch entscheidet - und jeder dieser drei Schritte ist im Audit-Trail getrennt belegt". Die KI macht die Richtlinie damit nicht angreifbar, sie macht sie auditierbar.

## Eine Schicht über Ihren Systemen, nicht statt ihnen

Der Agent konkurriert nicht mit Ihrer HR-Plattform. Gegen SAP, Workday oder Personio auf der Verwaltungs-Achse anzutreten wäre aussichtslos - dort entscheiden Marktanteil und Integration. Der Agent legt sich als Entscheidungs- und Nachweis-Schicht darüber: Versionierung, Verteilung und Self-Service-Auskunft bleiben in Ihrem System, und er macht den Weg dorthin prüfbar.

Auch die KI-Governance bleibt dabei im Blick. Seit dem 2.2.2025 verlangt Artikel 4 EU AI Act, dass Unternehmen ein ausreichendes Maß an KI-Kompetenz beim Personal sicherstellen und dokumentieren - eine Bemühungspflicht ohne eigene Einzelstrafe, deren fehlende Dokumentation aber als Sorgfaltspflichtverletzung gewertet werden kann und in das Hochrisiko-Sanktionsregime hineinwirkt (geltende Frist 2. August 2026, voraussichtlich verschoben auf Dezember 2027 - Digital Omnibus, Mai 2026). Weil der Agent selbst an Richtlinien mitwirkt, erzeugt er die dafür nötige Dokumentation als Nebenprodukt seiner Arbeit, statt sie nachträglich zu schreiben.

Der nächste Schritt ist keine Software-Einführung, sondern eine Prozess-Analyse: Wo in Ihrem Richtlinien-Lebenszyklus sitzt heute die ungeprüft übersprungene Mitbestimmung, und wie belegbar ist die Zuständigkeit hinter jeder geltenden Fassung?

## Auf einen Blick

- **Was er tut**: führt HR-Richtlinien durch ihren Lebenszyklus und belegt für jeden Schritt getrennt, wer ihn verantwortet hat
- **Klassifikation**: kein EU-AI-Act-Hochrisiko-System (Informationsbereitstellung, keine Bewertung von Menschen), aber kompetenzpflichtig nach Artikel 4 EU AI Act
- **Entscheidungslogik**: überwiegend Regelwerk, KI nur als anfechtbarer Sprach-Indikator, bindende Entscheidung beim Menschen
- **Compliance-Anker**: Mitbestimmung nach Paragraph 87 BetrVG, Diskriminierungsfreiheit nach dem AGG, Beschäftigtendatenschutz nach Artikel 88 DSGVO, Meldestelle nach Paragraph 12 HinSchG
- **Integration**: Schicht über SAP SuccessFactors, Personio, Workday oder Confluence - kein Ersatz
- **Prüfungsfall**: jede geltende Fassung bis zur Mitbestimmungs-Klassifikation, KI-Markierung und Freigabe getrennt rückverfolgbar

--- Pre-Hire-Due-Diligence-Agent ---
> Pre-Employment Due Diligence: AGG-konforme Background-Checks, EU AI Act Annex III(4)(a) HR-Hochrisiko und BZRG-Strafregisterauszug - mit DSGVO Art. 9 sensible Daten und Mobley-v-Workday-Mitigation.

## Background-Check zwischen Compliance-Pflicht und AGG-Falle

Dieser Agent folgt dem [Decision Layer](/de/decision-layer/)-Prinzip: jede Entscheidung ist entweder regelbasiert, KI-assistiert oder explizit einem Menschen zugeordnet. Er ist nach [EU AI Act 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) Annex III(4)(a) HR-Recruitment als Hochrisiko-System klassifiziert und unterliegt damit den verschärften Pflichten zu Risikomanagement-System, Daten-Governance, Transparenz, menschlicher Aufsicht und Bias-Audit ab dem 2.8.2026.

Eine typische Pre-Employment Due Diligence verarbeitet pro Bewerber bis zu 15 Verifikations-Schritte: Lebenslauf-Klassifikation, Zeugnis-Verifikation, Diplom-Validierung, Referenz-Anfragen bei früheren Arbeitgebern, Strafregisterauszug nach BZRG bei besonderem Vertrauensverhältnis, SCHUFA-Auskunfts-Anfrage bei Banken/Versicherungen, Visa-Verifikation AsylG/AufenthG bei internationalen Bewerbern, Identitäts-Verifikation eIDAS, Schwerbehinderten-Einladungs-Pflicht SGB IX §164+§178.

Das Problem liegt nicht im Verifikations-Volumen, sondern in der AGG-Compliance-Falle. Jede unzulässige Frage - nach Schwangerschaft (MuSchG §3), Schwerbehinderung (SGB IX) oder Religion (AGG §1) - löst die Beweislast-Umkehr nach AGG §22 aus, dazu einen Entschädigungs-Anspruch bis 3 Bruttomonatsgehälter je Bewerber und die Zwei-Monats-Klagefrist. Bei Sammelklagen oder Mehrfach-Diskriminierung wird das schnell siebenstellig.

## EU AI Act Annex III(4)(a): Hochrisiko-Klassifikation mit DPIA und FRIA

Der Pre-Hire-Due-Diligence-Agent fällt nach EU AI Act Annex III(4)(a) unter die Hochrisiko-Systeme für HR-Recruitment. Die Pflichten ab dem 2.8.2026 umfassen:

- **Article 9 Risikomanagement-System**: Bias-Risiken über die geschützten Merkmale hinweg identifizieren, bewerten und mindern
- **Article 10 Daten-Governance**: Qualität der Trainingsdaten, Bias-Detection sowie Tests auf Demographic Parity und Equal Opportunity
- **Article 13 Transparenz-Pflichten**: Beipackzettel zu Funktionsweise, Genauigkeit, Robustheit und Bias-Audit-Ergebnissen
- **Article 14 menschliche Aufsicht**: Mensch-in-the-Loop bei jeder Background-Check-Entscheidung zwingend
- **Article 26 Deployer-Pflichten**: Datenschutz-Folgenabschätzung, Konsultation der Aufsichtsbehörde, Post-Market-Monitoring und Incident Reporting
- **Article 27 FRIA Fundamental Rights Impact Assessment**: vor Inbetriebnahme, mit Konsultation von Antidiskriminierungsstelle, Datenschutzbeauftragtem und Betriebsrat

Bußgelder bis 35 Mio EUR oder 7 Prozent globaler Konzernumsatz. Cross-Reference DSGVO Art. 35 DPIA-Pflicht bei systematischer automatisierter Bewertung Bewerber. Die [Mobley v. Workday Sammelklage](https://www.courtlistener.com/docket/67476007/mobley-v-workday-inc/) (Northern District California 2023) - Vorwurf AI-Bias bei HR-Recruitment-Software gegen über 40-jährige Bewerber ADEA - dient als Präzedenzfall.

## AGG §22 Beweislast-Umkehr bei Pre-Employment-Diskriminierung

Im Klagefall greift die Beweislast-Umkehr nach [AGG §22](https://www.gesetze-im-internet.de/agg/__22.html) - wenn Bewerber Indizien für Diskriminierung anführen können (statistische Auffälligkeit, fehlende Begründung, unzulässige Frage), liegt es am Arbeitgeber zu beweisen, dass keine Diskriminierung vorlag. Ohne dokumentierte, reproduzierbare Begründung pro Background-Check-Schritt ist diese Beweispflicht praktisch nicht erfüllbar.

AGG §15 sieht Entschädigungen bis zu drei Bruttomonatsgehälter je Bewerber vor, wenn Indizien für eine Diskriminierung wegen eines der acht geschützten Merkmale vorliegen. Die Klagefrist beträgt zwei Monate nach der Ablehnung; daneben stehen die betriebliche Beschwerdestelle nach AGG §17 und das Verfahren bei der Antidiskriminierungsstelle.

Die BAG-Rechtsprechung verschärft die Beweisanforderungen bei unzulässigen Fragen - etwa zur Schwangerschaft (MuSchG §3), zur Schwerbehinderung (SGB IX) oder zur Religion (AGG §1) - und bei den Schranken für Strafregister- und SCHUFA-Anfragen.

## Sensible Daten nach DSGVO Art. 9 und der BZRG-Strafregisterauszug

[DSGVO Art. 9](https://eur-lex.europa.eu/eli/reg/2016/679/oj) Abs. 1 verbietet die Verarbeitung sensibler Bewerber-Daten - etwa zu Gesundheit, Religion, Gewerkschaftszugehörigkeit, sexueller Orientierung sowie biometrischer und genetischer Daten. Ausnahmen gibt es nur bei ausdrücklicher Einwilligung oder bei berechtigtem Interesse mit Interessen-Abwägung.

Ein Strafregisterauszug nach [BZRG §31-§57](https://www.gesetze-im-internet.de/bzrg/) ist nur bei berechtigtem Interesse zulässig - das erweiterte Führungszeugnis nach §41 nur bei Tätigkeiten mit Minderjährigen, schutzbedürftigen Personen oder besonderem Vertrauensverhältnis. Ein unbefugter Zugriff ist nach §132a, §202a und §203 StGB strafbar.

BDSG §26 regelt die Datenverarbeitung im Beschäftigungskontext einschließlich des Bewerbungsverfahrens, §27 die Übermittlung von Bewerber-Daten in Drittstaaten. Ein Datenschutzbeauftragter ist nach §38 ab 20 Mitarbeitenden Pflicht.

## SCHUFA- und Auskunftei-Anfragen: enge Schranken nach DSGVO Art. 22

Eine SCHUFA-Anfrage ist nur bei Tätigkeiten mit besonderem Vertrauensverhältnis - Banken, Versicherungen, öffentlicher Dienst - zulässig (BDSG §31), und nur mit Einwilligung des Bewerbers und menschlicher Validierung (DSGVO Art. 22). Die EuGH-Rechtsprechung zur SCHUFA (C-26/22) bestätigt: Scoring-Verfahren mit erheblicher Auswirkung auf den Bewerber unterliegen dem Verbot der rein automatisierten Einzelentscheidung.

Gleiches gilt für weitere Auskunfteien wie Crif Bürgel und Creditreform. Der Bewerber hat Anspruch auf Selbstauskunft (DSGVO Art. 15) sowie auf Anfechtung und manuelle Überprüfung (Art. 22 Abs. 3).

## Cross-Reference zu Candidate-Screening, Interview-Scheduling und Contract-Offer-Generation

Der Pre-Hire-Due-Diligence-Agent ist eingebettet in eine HR-Recruitment-Pipeline: [Candidate-Screening-Agent](/de/hr-agent-katalog/candidate-screening-agent/) Cluster #24 liefert Vorauswahl-Daten als Input. [Interview-Scheduling-Agent](/de/hr-agent-katalog/interview-scheduling-agent/) Cluster #37 nimmt qualifizierte Bewerber zum Vorstellungsgespräch entgegen. [Contract-Offer-Generation-Agent](/de/hr-agent-katalog/contract-offer-generation-agent/) Cluster #29 generiert das Vertragsangebot nach erfolgreicher Due Diligence mit qualifizierter eIDAS-Signatur. [Onboarding-Workflow-Agent](/de/hr-agent-katalog/onboarding-workflow-agent/) übernimmt erfolgreichen Bewerber. [HR-Document-Management-Agent](/de/hr-agent-katalog/hr-document-management-agent/) Cluster #36 archiviert AGG-konforme Bewerbungs-Unterlagen 6 Monate. [Audit-Compliance-Agent](/de/hr-agent-katalog/audit-compliance-agent/) Cluster #22 prüft EU AI Act Article 26 Deployer-Pflichten und DPIA-Konsistenz.

## Auf einen Blick

- **Klassifikation**: EU AI Act 2024/1689 Annex III(4)(a) Hochrisiko HR-Recruitment ab 2.8.2026
- **Compliance-Anker**: AGG §22 Beweislast-Umkehr, DSGVO Art. 9+22+88, BDSG §26+§27, EU AI Act Annex III(4)(a), BZRG §31-§57, SGB IX §164+§178, BetrVG §94+§99
- **Mitbestimmung**: BetrVG §94, §95, §99 und §87 Abs. 1 Nr. 6 zwingend, Konzern-Betriebsrat-Pflicht
- **Aufbewahrung**: Bewerbungs-Unterlagen 6 Monate AGG-konform, danach Löschung nach DSGVO Art. 17
- **Bußgelder**: bis 35 Mio EUR oder 7 Prozent globaler Konzernumsatz nach EU AI Act, bis 4 Prozent oder 20 Mio EUR nach DSGVO, dazu AGG §15 mit 3 Bruttomonatsgehältern und Strafrecht nach BZRG
- **Audit-Pflicht**: DPIA, FRIA und Bias-Audit pro Quartal, Wirtschaftsprüfer-Prüfung
- **Präzedenzfall**: Mobley v. Workday Northern District California 2023 Sammelklage AI-Bias HR-Software

### Entscheider-Verteilung Pre-Hire-Due-Diligence

| Schritt | Decider | Begründung |
|---------|---------|------------|
| Bewerbungs-Eingang Pre-Hire | R | DSGVO Art. 9-Filter sensible Daten deterministisch |
| Lebenslauf-Klassifikation | A | ML-OCR und Anomalie-Detection mit menschlicher Validierung |
| Referenz-Anfrage | R | Einwilligungs-Workflow, AVV deterministisch |
| Strafregisterauszug-Anforderung | R | BZRG §31-§57, §41 Tätigkeits-Katalog deterministisch |
| SCHUFA-Auskunfts-Anfrage | R | BDSG §31 Voraussetzungen, DSGVO Art. 22 deterministisch |
| Visa-Verifikation | R | AsylG/AufenthG, Blue Card EU, ICT-Karte deterministisch |
| Identitäts-Verifikation eIDAS | R | AusweisApp2, IDnow, WebID, Verimi deterministisch |
| Schwerbehinderten-Einladung | R | SGB IX §164+§178 Einladungs-Pflicht deterministisch |
| BetrVG-Mitbestimmung | R | §94+§95+§99 1-Wochen-Frist deterministisch |
| EU AI Act Compliance | R | Article 9+10+13+14+26+27 FRIA deterministisch |
| Background-Check-Auswertung | H | Menschliche Auswertung Hochrisiko-System zwingend |
| Bewerber-Auswahl-Freigabe | H | Hiring Manager, AGG §22 und DSGVO Art. 22 zwingend |
| DSGVO-Information Bewerber | R | Art. 13+14+22 Abs. 3 Standard-Workflow |
| 6-Monats-Aufbewahrung | R | AGG-konform, DSGVO Art. 17 deterministisch |

--- Probezeit-Management-Agent ---
> Probezeit steuern: Fristen ab Eintrittsdatum deterministisch berechnet, KI nur als Warnsignal, der Mensch entscheidet - diskriminierungsfrei belegt.

## Jedes HR-System erinnert an den Termin. Keines beweist, dass die Trennung hielt.

Personio, SAP, Workday - jedes dieser Systeme schickt eine Erinnerung, wenn ein Probezeit-Termin naht. Das ist seit Jahren Standard. Die Frage, an der eine Probezeit-Trennung wirklich hängt, beantwortet keines dieser Systeme: Fällt die Entscheidung rechtzeitig vor dem Wartezeit-Ende - und können Sie hinterher beweisen, dass die Bewertung diskriminierungsfrei war?

Dieser Agent folgt dem [Decision Layer](/de/decision-layer/)-Prinzip: Jeder Schritt ist entweder regelbasiert, ein KI-Warnsignal oder eine menschliche Entscheidung - klar getrennt und nachvollziehbar protokolliert. Nach [EU AI Act](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) ist er kein Hochrisiko-System, weil er keine Menschen bewertet und über niemanden entscheidet. Seine Anforderungen kommen aus dem Arbeits- und Datenschutzrecht, und die sind hart genug.

## Probezeit steuern: wo der Prozess wirklich klemmt

Die Probezeit ist kein Randthema. In der [softgarden-Onboarding-Befragung 2018](https://www.presseportal.de/pm/100361/3943729) hatten 11,6 Prozent der Beschäftigten in den ersten 100 Tagen schon einmal selbst gekündigt, weitere 15,7 Prozent standen kurz davor - und die Folge-Erhebung 2022 hob den Anteil der frühen Kündigungen auf 17,8 Prozent. Hinter jedem dieser Abgänge steht eine [teure Fluktuation](https://www.haufe.de/personal/hr-management/fluktuation-wechselbereitschaft-der-arbeitnehmer-steigt_80_193940.html): direkte Kosten für Neuausschreibung, Auswahlverfahren und erneutes Onboarding, dazu der schwer messbare Produktivitätsverlust. Wo so viel auf dem Spiel steht, klemmt der Prozess an drei Stellen.

- **Die Frist.** Nach sechs Monaten greift das Kündigungsschutzgesetz. Wer am Tag 179 mit zwei Wochen Frist kündigt, endet am Tag 193 - also nach Ablauf der Wartezeit. Aus einer formfreien Trennung wird damit ein Kündigungsschutzprozess. Das eine verpasste Datum dreht die Rechtslage um.
- **Die Bewertung.** Eine formal zulässige Probezeit-Kündigung kann trotzdem kippen, wenn ein Diskriminierungs-Indiz vorliegt. Nach AGG Paragraph 22 trägt dann der Arbeitgeber die Beweislast - und ohne dokumentierte, sachliche Bewertung ist dieser Negativbeweis nicht zu führen.
- **Die Schutzkonstellation.** Schwangerschaft, Schwerbehinderung, Pflegezeit: In diesen Fällen greift ein Sonder-Kündigungsschutz, der den üblichen Trennungspfad sperrt. Wer das übersieht, riskiert eine unwirksame Kündigung unabhängig davon, ob sie inhaltlich berechtigt war.

Reine Termin-Reminder lösen keinen dieser drei Punkte. Sie zeigen ein Datum an, aber sie rechnen nicht rückwärts, sie prüfen keine Schutzregime, und sie hinterlassen keinen prüfbaren Nachweis.

## Drei Quellen, klar getrennt: wer entscheidet was

Die meisten Anbieter sagen, ein Mensch bleibe "im Prozess", und kleben ein Compliance-Siegel daneben. Beides bleibt eine schwarze Box. Der Agent macht stattdessen für jeden Schritt sichtbar, aus welcher von drei Quellen die Entscheidung stammt:

| Quelle | Was sie entscheidet | Beispiel aus der Probezeit |
|--------|---------------------|----------------------------|
| **Regelwerk (R)** | Alles Deterministische, kein Ermessen | Meilensteine aus dem Eintrittsdatum, Rückwärts-Frist um Tag 184, Stopp bei Schutzkonstellationen |
| **KI-Warnsignal (A)** | Markiert Risiko, entscheidet nie | Indikator aus Fehlzeiten, offenen Schulungen, Feedback-Mustern |
| **Mensch (H)** | Bewertung und finale Entscheidung | Feedback zu Leistung und Integration, Entscheid über Übernahme oder Kündigung |

Der Agent ist also überwiegend ein deterministischer Frist-Motor, mit KI nur als Warnsignal an den Rändern und einem festen menschlichen Entscheidungs-Gate. Das ist die ehrliche Antwort auf den naheliegenden Einwand "darf eine KI über Menschen entscheiden?" - und genau das, was DSGVO Art. 22 verlangt. Wichtig dabei: Wer entscheidet, sieht jedes KI-Warnsignal als solches markiert - mit der Pflicht zur eigenen Prüfung -, und der oder die Betroffene kann den Indikator anfechten. Die menschliche Entscheidung greift damit auf das Warnsignal, nicht an ihm vorbei. Wie diese Schicht architektonisch durchgreift, zeigt der [Decision Layer](/de/decision-layer/).

## Der Hebel ist die Rückwärts-Frist, nicht die Erinnerung

Ein Termin-Reminder zeigt an, wann ein Datum erreicht ist - er verhindert nichts. Genau das ist die teure Lücke: Die Probezeit endet stillschweigend nach sechs Monaten, und wer zu spät kündigt, steht plötzlich unter vollem Kündigungsschutz mit Begründungspflicht und Drei-Wochen-Klagefrist.

Deshalb rechnet der Agent nicht vorwärts auf einen Termin zu, sondern rückwärts vom Wartezeit-Ende. Er reserviert die zwei Wochen Kündigungsfrist nach BGB Paragraph 622 Abs. 3, dazu die Woche für die Betriebsrats-Anhörung nach BetrVG Paragraph 102 und die Bearbeitungszeit - und eskaliert bereits bei Tag 150 an Führungskraft und HR. Bevor er den Trennungspfad überhaupt freigibt, prüft er die Schutzkonstellationen: Liegt Schwangerschaft, Schwerbehinderung oder Pflegezeit vor, wird der Pfad gesperrt. So entsteht keine Erinnerung, sondern eine strukturelle Garantie, dass das "Tag-179-Versäumnis" nicht passiert. Die Anhörungs-Woche ist dabei kein Detail: Sie muss vor dem Wartezeit-Ende liegen, sonst rutscht die Trennung wieder in den Kündigungsschutz-Bereich.

## Der Audit-Trail entsteht zur Laufzeit, nicht im Nachhinein

Ein Warnsignal aus einem KI-Modell ohne integrierten Nachweis ist für eine spätere Verteidigung wertlos: Es ist nicht reproduzierbar, und es ist nicht dokumentiert, welche Eingaben es erzeugt haben. Das Diskriminierungsrecht verlangt aber genau das Gegenteil. Bei Indizien für eine Benachteiligung muss nach AGG Paragraph 22 der Arbeitgeber beweisen, dass nicht diskriminiert wurde - und im bestehenden Arbeitsverhältnis, also bei einer Probezeit-Kündigung, ist die Entschädigung nach AGG Paragraph 15 der Höhe nach nicht gedeckelt; der Drei-Monats-Deckel greift nur bei einer Nichteinstellung.

Deshalb trägt beim Agenten jeder Schritt seinen Nachweis bei sich: welche Regel mit welchem Datum gegriffen hat, welches Warnsignal vorlag und wer auf welcher Grundlage bewertet hat - unveränderbar, nicht nachträglich änderbar. Die diskriminierungsfreie Dokumentation wächst mit jedem Meilenstein mit, statt als separates Schriftstück gepflegt zu werden. Der Hebel dahinter: Ohne diesen Nachweis kippt eine sachlich berechtigte Kündigung allein an der Beweislast. Eine zur Laufzeit entstehende Dokumentation nimmt dieser Eskalation die Grundlage - und liefert zugleich die Unterlagen, die der Betriebsrat sehen will, bevor er einer eingesetzten HR-IT zustimmt.

## Über Personio und Workday, nicht statt ihnen

Der Agent konkurriert nicht mit Ihrem HR-System. Gegen Personio oder Workday auf der Workflow-Achse anzutreten wäre aussichtslos - dort entscheidet Integration und Marktanteil. Der Agent legt sich als Entscheidungs- und Nachweis-Schicht darüber: Sie behalten Ihre Termine und Workflows, und er macht sie rechtssicher.

Termine, Feedback-Formulare und Personalakte laufen unverändert in den Zielsystemen weiter - ob Personio im Mittelstand oder SAP SuccessFactors im Konzern mit mehreren Gesellschaften. Was hinzukommt, ist nicht ein weiteres System, sondern die Antwort auf die zwei Fragen, an denen eine Probezeit-Trennung hängt: Fällt die Entscheidung rechtzeitig, und ist sie diskriminierungsfrei belegt? Beides ist hier strukturell gesichert und unveränderbar dokumentiert - eine Haftungs-Architektur, die ein Betriebsrat unterschreiben kann, kein weiteres Tool, das nach Überwachung aussieht.

Der nächste Schritt ist keine Software-Einführung, sondern eine Bestandsaufnahme: Wo in Ihrem Probezeit-Prozess sitzt heute die manuelle Frist-Berechnung, und wie prüfungsfest ist die Bewertung dahinter?

## Auf einen Blick

- **Was er tut**: berechnet Probezeit-Fristen rückwärts vom Wartezeit-Ende, warnt früh und dokumentiert jede Entscheidung unveränderbar
- **Klassifikation**: kein EU-AI-Act-Hochrisiko-System (Frist-Tracking, keine Entscheidung über Menschen)
- **Entscheidungslogik**: überwiegend Regelwerk, KI nur als Warnsignal, Bewertung und Entscheidung beim Menschen
- **Compliance-Anker**: BGB Paragraph 622 Abs. 3, KSchG Paragraph 1, AGG Paragraph 22, DSGVO Art. 22, BetrVG Paragraph 102
- **Integration**: Schicht über Personio, SAP SuccessFactors, Workday oder BambooHR - kein Ersatz
- **Verteidigungsfall**: jede Bewertung diskriminierungsfrei belegt, jede Frist bis zum Eintrittsdatum rückverfolgbar

--- Promotion-Process-Agent ---
> Beförderungs-Governance: EU AI Act Annex III(4)(b) Hochrisiko, AGG §22 Beweislast-Umkehr und BetrVG §99/§95 Versetzungs-Mitbestimmung - Equity-Audit-Engine mit DSGVO Art. 22 Anfechtungs-Recht.

## Beförderung als Compliance-Falle zwischen AGG und EU AI Act

Dieser Agent folgt dem [Decision Layer](/de/decision-layer/)-Prinzip: jede Entscheidung ist entweder regelbasiert, KI-assistiert oder explizit einem Menschen zugeordnet. Er ist nach [EU AI Act 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) Annex III(4)(b) als Hochrisiko-System klassifiziert und unterliegt damit den verschärften Pflichten zu Risikomanagement-System, Daten-Governance, Transparenz, menschlicher Aufsicht und Bias-Audit ab dem 2.8.2026.

Beförderungs-Prozesse scheitern selten an der Entscheidung. Sie scheitern an allem, was davor passiert - und an allem, was danach nicht dokumentiert ist. Eine Führungskraft schlägt eine Mitarbeiterin zur Beförderung vor. Die Leistung stimmt, die Position ist frei, das Budget reicht. Für sich genommen eine vernünftige Entscheidung. Aber über 80, 120, 200 Beförderungs-Vorschläge im Jahr verteilt sich die Vernunft ungleich. McKinsey Women in the Workplace dokumentiert seit zehn Jahren: Auf 100 Männer, die ihre erste Beförderung zum Manager erhalten, kommen 81 Frauen. Nicht weil einzelne Entscheidungen falsch sind. Sondern weil kein Prozess existiert, der das Muster sichtbar macht, während es entsteht.

Drei kumulative Risiko-Schichten greifen ineinander: AGG §22 Beweislast-Umkehr bei Indizien für Diskriminierung in Beförderungs-Entscheidungen mit AGG §15 Entschädigungs-Anspruch bis 3 Bruttomonatsgehälter und 2-Monats-Klagefrist. EuGH C-624/19 Tesco-Stores erweitert Equal Pay auf gleichwertige Tätigkeiten - relevant insbesondere bei Beförderungen über Funktions-Grenzen. EU AI Act Annex III(4)(b) klassifiziert Beförderungs-Systeme als Hochrisiko mit Bußgeldern bis 35 Mio EUR oder 7 Prozent globaler Konzernumsatz.

Das Problem zerfällt strukturell in drei Schichten. Erstens: Kriterien existieren, aber niemand prüft sie einheitlich. Die meisten Unternehmen haben Beförderungs-Richtlinien mit Mindest-Betriebs-Zugehörigkeit, Performance-Rating über zwei Zyklen und keinen offenen disziplinarischen Maßnahmen. Aber die Prüfung liegt bei der Führungskraft, die den Vorschlag macht - und die hat ein Interesse am Ergebnis. Ob alle Kriterien tatsächlich erfüllt sind, zeigt sich erst, wenn Comp&Ben die Unterlagen prüft. Das passiert Wochen später. Oft passiert es gar nicht. Zweitens: Vergütungs-Bänder werden bei Bandbreiten-Sprüngen verletzt, ohne dass es auffällt. Eine Beförderung von Senior Developer auf Lead Developer bedeutet einen Bandwechsel. Liegt das neue Gehalt im Band der Zielposition? Stimmt die Compa-Ratio im Vergleich zum restlichen Team? In Spreadsheet-basierten Prozessen prüft das niemand in Echtzeit. Drittens: Kalibrierung wird politisch statt analytisch. Kalibrierungs-Runden sollen Beförderungs-Vorschläge über Bereiche hinweg vergleichbar machen - in der Praxis vergleichen Führungskräfte Kandidaten ohne die zugrunde liegenden Daten und das Gespräch kippt in Verhandlung.

## EU AI Act Annex III(4)(b): Hochrisiko-Klassifikation mit DPIA und FRIA

Der Promotion-Process-Agent fällt nach EU AI Act Annex III(4)(b) unter die Hochrisiko-Systeme für HR-Beförderungsentscheidungen. Die Pflichten ab dem 2.8.2026 umfassen:

- **Article 9 Risikomanagement-System**: Bias-Risiken bei Beförderung über die geschützten Merkmale hinweg identifizieren, bewerten und mindern
- **Article 10 Daten-Governance**: Qualität der Trainingsdaten, Bias-Detection sowie Tests auf Demographic Parity und Equal Opportunity, mit einer Tesco-konformen Definition gleichwertiger Tätigkeiten
- **Article 13 Transparenz-Pflichten**: Beipackzettel zu Funktionsweise, Genauigkeit, Robustheit, Bias-Audit-Ergebnissen und Beförderungs-Kriterien
- **Article 14 menschliche Aufsicht**: Mensch-in-the-Loop bei jeder Beförderungs-Empfehlung zwingend
- **Article 26 Deployer-Pflichten**: Datenschutz-Folgenabschätzung, Konsultation der Aufsichtsbehörde, Post-Market-Monitoring und Incident Reporting bei Diskriminierungs-Beschwerden
- **Article 27 FRIA Fundamental Rights Impact Assessment**: vor Inbetriebnahme, mit Konsultation von Antidiskriminierungsstelle, Datenschutzbeauftragtem und Betriebsrat

Bußgelder bis 35 Mio EUR oder 7 Prozent globaler Konzernumsatz. Cross-Reference DSGVO Art. 35 DPIA-Pflicht bei systematischer automatisierter Bewertung mit erheblicher Auswirkung auf Karriere. Die [Mobley v. Workday Sammelklage](https://www.courtlistener.com/docket/67476007/mobley-v-workday-inc/) (Northern District California 2023) - Vorwurf AI-Bias bei HR-Software gegen über 40-jährige Bewerber und Beförderungs-Kandidaten ADEA - dient als US-Präzedenzfall und prägt EU-Aufsichts-Behörden-Linie.

## AGG §22 Beweislast-Umkehr bei Beförderungs-Diskriminierung

Im Klagefall greift die Beweislast-Umkehr nach AGG §22 - wenn Mitarbeitende Indizien für Diskriminierung anführen können (statistische Auffälligkeit der Beförderungs-Quote in Schutz-Gruppe, fehlende Begründung, Timing der Ablehnung nach Schwangerschaft, Elternzeit, Gewerkschafts-Mitgliedschaft), liegt es am Arbeitgeber zu beweisen, dass keine Diskriminierung vorlag. Ohne dokumentierte, reproduzierbare Begründung pro Beförderungs-Entscheidung ist diese Beweis-Pflicht praktisch nicht erfüllbar.

AGG §15 sieht Entschädigungen bis zu drei Bruttomonatsgehälter je Mitarbeitenden vor, wenn Indizien für eine Beförderungs-Diskriminierung wegen eines der geschützten Merkmale vorliegen. Bei Sammelklagen oder mehreren Klägern aus derselben Vergleichsgruppe erreicht das schnell den siebenstelligen Bereich. Die Zwei-Monats-Klagefrist nach AGG §15 Abs. 4 beginnt mit Kenntnis der Ablehnung neu, und die [BAG-Rechtsprechung](https://www.bundesarbeitsgericht.de/) erweitert den Indizien-Katalog laufend.

Die DSGVO greift mit bis zu 4 Prozent Konzernumsatz oder 20 Mio Euro bei Verstößen gegen die Vorgaben zu Beförderungs-Daten und die DPIA-Pflicht (Art. 35). Hinzu kommt das Reputations-Risiko eines Aufsichtsrats-Mängelberichts über das CSRD-Compensation-Reporting samt Aufsichtsrats-Haftung nach AktG §107. Eine Verletzung der [BetrVG-Mitbestimmung](https://www.gesetze-im-internet.de/betrvg/) führt zu einem Unterlassungs-Anspruch, einem Beschluss-Verfahren nach §99 ArbG und einem Einigungsstellen-Verfahren mit konzernweiter Wirkung.

In Spreadsheet-Prozessen ist die AGG §22-Beweislast-Umkehr praktisch nicht zu kontern. Wenn 60 Excel-Dateien parallel ausgefüllt werden, fällt einer Kalibrierungs-Runde im Januar nicht auf, dass weibliche Kandidatinnen systematisch 4 Prozent niedrigere Bandbreiten-Sprünge erhalten als männliche - oder dass der Promotion Gap zwischen 50+ und Mittel-Karriere-Beschäftigten in einer bestimmten Funktion 7 Prozent beträgt. Genau diese statistischen Auffälligkeiten sind aber die Indizien, die nach AGG §22 die Beweislast-Umkehr auslösen. BAG-Rechtsprechung 2024-2026 hat den Indizien-Katalog kontinuierlich erweitert: nicht nur Statistik, sondern auch Timing der Ablehnung nach Schwangerschaft oder Elternzeit, fehlende Konsistenz der Kriterien-Anwendung, abweichende Begründungs-Muster über Schutz-Gruppen reichen als Indizien aus. HinSchG §3+§16-§18 schafft zusätzlich Whistleblower-Meldestellen mit Repressalien-Schutz §33-§37 - Beschäftigte können Beförderungs-Diskriminierungs-Anzeigen anonym einreichen mit BfJ als externer Meldestelle.

## Equal Pay nach der Tesco-Rechtsprechung und der EU-Entgelttransparenz

[EuGH C-624/19 Tesco-Stores](https://curia.europa.eu/juris/document/document.jsf?docid=242039) vom 3.6.2021 erweitert den Equal-Pay-Anspruch auf gleichwertige Tätigkeiten unterschiedlicher Funktion. Konkret: Bei Beförderungen über Funktions-Grenzen muss die Vergleichbarkeit der Tätigkeiten anhand objektiver Kriterien (Anforderungs-Profil, Verantwortungs-Niveau, Kompetenz-Anforderungen) geprüft werden. Eine Beförderung in eine andere Funktion mit niedrigerer Vergütung gegenüber einer vergleichbar qualifizierten Person anderen Geschlechts kann Equal-Pay-Verstoß sein - auch wenn die Funktionen formal unterschiedlich sind.

Ab dem 7.6.2026 verpflichtet die [EU Pay Transparency Directive 2023/970](https://eur-lex.europa.eu/eli/dir/2023/970/oj) zu dokumentierbaren Grundlagen für jede Beförderung. Bei Gender-Pay-Gap-Abweichungen von 5 Prozent unerklärtem Lohngefälle (Art. 9) greifen Joint-Pay-Assessment-Pflichten und Abhilfe-Verfahren innerhalb von 6 Monaten (Art. 10). Mitarbeitende erhalten Auskunftsanspruch über durchschnittliche Vergütung gleichwertiger Tätigkeiten (Art. 7), in Beförderungs-Stellen-Ausschreibungen ist die Pay-Range-Anzeige Pflicht (Art. 6), und die Frage nach Gehaltshistorie ist verboten (Art. 5). Beweislast-Umkehr bei Lohn-Diskriminierung kehrt sich um (Art. 18). Sanktionen: Mindeststandards Art. 20 mit Bußgeldverfahren und Schadensersatz nach AGG §15.

Das deutsche [EntgTranspG](https://www.gesetze-im-internet.de/entgtranspg/) ergänzt seit 2017 mit individuellem Auskunftsanspruch ab 200 Mitarbeitenden (§10-§16), betrieblichem Prüfverfahren ab 500 Mitarbeitenden (§17-§19) und Berichts-Pflicht im Lagebericht (§21-§23). Bis Juni 2026 muss die nationale Umsetzung der EU-Richtlinie erfolgen.

## Versetzungs-Mitbestimmung nach BetrVG §99 und §95

Der Betriebsrat hat nach [BetrVG](https://www.gesetze-im-internet.de/betrvg/) §99 ein zwingendes Mitbestimmungsrecht bei einer Versetzung - Beförderungen mit Positions-Wechsel fallen unstreitig darunter. Der Agent legt die Beförderung dem Betriebsrat zur Zustimmung vor, mit einer Ein-Wochen-Frist für die Stellungnahme. Verweigern kann der Betriebsrat nach §99 Abs. 2 etwa bei einem Verstoß gegen Gesetz oder Tarifvertrag, bei einem Verstoß gegen die Auswahl-Richtlinien nach §95 oder bei einem sozialen Schaden für andere Mitarbeitende. Bei Verweigerung greift das Beschluss-Verfahren nach §99 ArbG, mit Eskalation über ArbG, LAG und BAG.

Die Auswahl-Richtlinien nach §95 sind bei den Beförderungs-Kriterien zwingend zu konsultieren, ebenso die Beurteilungs-Grundsätze nach §94. Eine KI-gestützte Beförderungs-Administration mit Equity-Audit-Trail fällt unstreitig unter die technische Überwachung nach §87 Abs. 1 Nr. 6. Bei konzernübergreifender Software ist der Konzern-Betriebsrat zuständig; bei Nichteinigung greift das Einigungsstellen-Verfahren nach ArbG.

## Einbettung in die HR-Agenten-Pipeline

Der Promotion-Process-Agent ist eingebettet in eine Pipeline aus spezialisierten HR-Agenten: [Merit-Cycle-Governance-Agent](/de/hr-agent-katalog/merit-cycle-governance-agent/) Cluster #38 nutzt dieselbe Equity-Analyse-Engine für jährliche Gehaltsrunden. [Compensation-Benchmarking-Agent](/de/hr-agent-katalog/compensation-benchmarking-agent/) Cluster #26 liefert Vergütungs-Bänder, Compa-Ratios und Pay-Range-Daten für Bandbreiten-Sprung-Validierung. [Performance-Review-Agent](/de/hr-agent-katalog/performance-review-agent/) liefert Performance-Ratings als Berechtigungs-Voraussetzung. [Payroll-Calculation-Agent](/de/hr-agent-katalog/payroll-calculation-agent/) Cluster #29 nimmt genehmigte Beförderungen mit korrektem Stichtag entgegen. [Payroll-Reporting-Agent](/de/hr-agent-katalog/payroll-reporting-agent/) Cluster #41 erstellt CSRD ESRS S1-13 Compensation Reporting. [HR-Document-Management-Agent](/de/hr-agent-katalog/hr-document-management-agent/) Cluster #36 archiviert AGG-konforme Beförderungs-Begründungen 6 Monate. [Audit-Compliance-Agent](/de/hr-agent-katalog/audit-compliance-agent/) Cluster #22 prüft EU AI Act Article 26 Deployer-Pflichten und DPIA-Konsistenz. [Contract-Offer-Generation-Agent](/de/hr-agent-katalog/contract-offer-generation-agent/) generiert Vertrags-Änderungen mit Versetzungs-Klauseln § 106 GewO Direktions-Recht.

## Auf einen Blick

- **Klassifikation**: EU AI Act 2024/1689 Annex III(4)(b) Hochrisiko HR-Beförderungs-Entscheidungen ab 2.8.2026
- **Compliance-Anker**: AGG §22 Beweislast-Umkehr, BetrVG §99+§95+§94+§87 Abs. 1 Nr. 6, EuGH C-624/19 Tesco-Stores, EU Pay Transparency 2023/970, EntgTranspG §10-§19, DSGVO Art. 22+35+88, CSRD ESRS S1-13, AktG §107 Abs. 4
- **Mitbestimmung**: BetrVG §99 Versetzung zwingend, dazu §95 Auswahl-Richtlinien, §94 Personalfragebögen und §87 Abs. 1 Nr. 6 technische Überwachung, Konzern-Betriebsrat-Pflicht
- **Equity-Schwelle**: 5 Prozent unerklärter Gender Promotion Gap nach EU Pay Transparency Art. 9 löst Joint Pay Assessment und 6-Monats-Abhilfe (Art. 10) aus
- **Bußgelder**: bis 35 Mio EUR oder 7 Prozent globaler Konzernumsatz nach EU AI Act, bis 4 Prozent oder 20 Mio EUR nach DSGVO, dazu AGG §15 mit 3 Bruttomonatsgehältern
- **Audit-Pflicht**: DPIA, FRIA und Bias-Audit pro Quartal, Wirtschaftsprüfer-Prüfung CSRD ab 250 Mitarbeitenden
- **Präzedenzfälle**: Tesco-Rechtsprechung des EuGH (C-624/19) zu Equal Pay bei gleichwertiger Tätigkeit, Mobley v. Workday (2023) zu KI-Bias in HR-Software

### Entscheider-Verteilung Promotion-Process

| Schritt | Decider | Begründung |
|---------|---------|------------|
| Beförderungs-Vorschlag-Eingabe | R | Stellenplan, Career-Path, Headcount-Plan deterministisch |
| Berechtigungs-Prüfung | R | Regelwerk Betriebs-Zugehörigkeit, Performance, Sperren |
| Bandbreiten-Sprung-Validierung | R | Compa-Ratio, Min-Max-Pay-Range, 8-15 Prozent Korridor |
| Budget-Verfügbarkeit | R | Echtzeit-Tracking gegen Bereichs-Budget |
| Equity-Analyse | A | ML-statistische Bias-Detection mit menschlicher Validierung |
| Equity-Eskalation | R | Schwellenwert >5 Prozent EU Pay Transparency 2023/970 |
| Genehmigungs-Workflow | R | Genehmigungs-Matrix Hierarchie, Bandbreiten-Sprung-Höhe |
| BetrVG §99 Versetzungs-Mitbestimmung | R | Zustimmungs-Verfahren mit 1-Wochen-Frist deterministisch |
| HR-Leitung-Genehmigung | H | Finale Freigabe AGG §22- und EuGH-C-624/19-konform |
| DSGVO Art. 22 Information | R | Art. 13+14+22 Abs. 3 Standard-Workflow |
| Vertrags-Änderung-Vorbereitung | R | Versetzungs-Klauseln, Bandbreiten-Sprung deterministisch |
| Beförderungs-Gespräch | H | Persönliches Gespräch Beziehungs-Dimension |
| Payroll-Übergabe | R | Stichtag, Lohnsteuer-Korrektur deterministisch |
| CSRD-Reporting | R | ESRS S1-13, EU Pay Transparency Art. 8 deterministisch |

--- Krankmeldungs-Agent ---
> Krankmeldungs-Verarbeitung: eAU §109 SGB IV elektronische AU, EFZG §3 6-Wochen-Lohnfortzahlung und SGB IX §167 BEM ab 6 Wochen - DEÜV-Krankenkassen-Meldungen mit DSGVO Art. 88.

## Krankmeldung in 60 Sekunden statt drei Wochen Postlaufzeit

Dieser Agent folgt dem [Decision Layer](/de/decision-layer/)-Prinzip: Jede Entscheidung ist entweder regelbasiert, ein KI-Indikator oder explizit einem Menschen zugeordnet. Nach [EU AI Act](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) ist er kein Hochrisiko-System, weil er keine Krankheit klassifiziert und keine Menschen bewertet. Seine Anforderungen kommen aus dem Sozial- und Arbeitsrecht - vom [Entgeltfortzahlungsgesetz](https://www.gesetze-im-internet.de/entgfg/) über das Datenschutzrecht für Gesundheitsdaten bis zum Kündigungsschutz.

Eine typische Krankmeldung durchläuft mehrere Schritte: Die elektronische AU wird bei der Krankenkasse abgerufen, die sechs Wochen Lohnfortzahlung berechnet, der Übergang ins Krankengeld nach sechs Wochen gesteuert, die BEM-Einladung ausgelöst und die Meldung an die Krankenkasse fristgerecht übertragen.

Das Problem liegt nicht im Volumen, sondern in der prüfbaren Kette dahinter: eine lückenlose Verfahrensdokumentation, die fristgerechte Meldung an die Krankenkasse, die BEM-Einladung ab sechs Wochen, die Beteiligung der Schwerbehindertenvertretung und eine belastbare Begründung, falls es zu einer krankheitsbedingten Kündigung kommt.

## Sechs Wochen Lohnfortzahlung, dann Krankengeld

[EFZG §3](https://www.gesetze-im-internet.de/entgfg/__3.html) gibt Anspruch auf sechs Wochen volle Lohnfortzahlung im Krankheitsfall, nach §4 zu 100 Prozent des Brutto-Lohns. Den Rahmen ergänzen die Anzeige- und Nachweispflichten des Mitarbeitenden, das Leistungsverweigerungsrecht des Arbeitgebers und das Maßregelungsverbot.

Nach Ablauf der sechs Wochen übernimmt das Krankengeld nach SGB V §44 und §47: 70 Prozent des Brutto-Lohns, gedeckelt auf 90 Prozent des Netto-Lohns, für bis zu 78 Wochen in drei Jahren. Bei Erkrankung eines Kindes gibt es zusätzlich Kinderkrankengeld. Erkrankt jemand innerhalb von zwölf Monaten erneut an derselben Krankheit, wird die bereits gezahlte Lohnfortzahlung nach EFZG §3 Abs. 1 Satz 2 angerechnet.

Der Einsatz ist hoch: Eine fehlende oder verspätete Lohnfortzahlung kann als Vorenthalten von Sozialversicherungsbeiträgen nach §266a StGB strafbar sein, und die einschlägige BAG-Rechtsprechung hat die Beweisanforderungen zuletzt verschärft.

## Die elektronische AU nach §109 SGB IV

Seit dem 1. Januar 2023 ist die elektronische Arbeitsunfähigkeitsbescheinigung nach [§109 SGB IV](https://www.gesetze-im-internet.de/sgb_4/__109.html) verpflichtend: Der Arzt meldet die Krankschreibung direkt an die Krankenkasse, der Arbeitgeber ruft sie dort über sv.net oder den DEÜV-Datenbaustein DSAU ab. Dabei gelten eine siebentägige Sperrfrist nach Eingang und der besondere Schutz von Gesundheitsdaten nach DSGVO Art. 9.

Beteiligt sind der GKV-Spitzenverband und die gesetzlichen Krankenkassen. Der Agent ruft die elektronische AU nach Ablauf der Sperrfrist automatisch und regelbasiert ab.

## BEM-Pflicht ab sechs Wochen nach SGB IX §167

Das Betriebliche Eingliederungsmanagement nach [SGB IX §167](https://www.gesetze-im-internet.de/sgb_9_2018/__167.html) ist Pflicht, sobald jemand innerhalb von zwölf Monaten sechs Wochen arbeitsunfähig war - zusammenhängend oder summiert. Die Einladung muss auf Datenschutz und Freiwilligkeit hinweisen und die Schwerbehindertenvertretung wie den Betriebsrat beteiligen.

Bei schwerbehinderten Mitarbeitenden kommt das Akteneinsichtsrecht der Schwerbehindertenvertretung nach SGB IX §178 hinzu; eine fehlende Beteiligung kann mit Bußgeldern geahndet werden. Eine krankheitsbedingte Kündigung ist nach KSchG §1 nur als letztes Mittel und nach durchgeführtem BEM zulässig.

Der Hintergrund ist arbeitsrechtlich brisant: Der EuGH wertet eine länger andauernde Erkrankung unter Umständen als Behinderung im Sinne der Richtlinie 2000/78, und das BAG hat in der Entscheidung 2 AZR 565/22 den Kündigungsschutz bei Long-COVID konkretisiert.

## Datenschutz und Mitbestimmung

[DSGVO Art. 9](https://eur-lex.europa.eu/eli/reg/2016/679/oj) verbietet die Verarbeitung sensibler Gesundheitsdaten grundsätzlich und lässt sie im Beschäftigungskontext nur unter engen Voraussetzungen zu. Für die Krankmeldungs-IT gelten daher Privacy by Design, Verschlüsselung und - bei systematischer Verarbeitung - die Pflicht zur Datenschutz-Folgenabschätzung.

Der Agent setzt das durch Datensparsamkeit um: Verarbeitet werden nur Beginn, Ende und Krankenkasse, keine Diagnosedaten. Der Zugriff bleibt auf Lohnbuchhaltung, HR-Operations und BEM-Beauftragte beschränkt, und mit Krankenkassen wie Steuerberatern bestehen Auftragsverarbeitungsverträge.

Die Mitbestimmung des Betriebsrats nach BetrVG §87 Abs. 1 Nr. 6 greift, weil das System mit Audit-Trail eine technische Überwachungseinrichtung ist. Die Schwerbehindertenvertretung wird nach SGB IX §178 beteiligt - in beiden Fällen ohne Einblick in Diagnosedaten.

## Cross-Reference zu Payroll-Processing und Leave-of-Absence

Der Krankmeldungs-Agent ist in eine Pipeline spezialisierter HR-Agenten eingebettet. Der [Payroll-Calculation-Agent](/de/hr-agent-katalog/payroll-calculation-agent/) übernimmt die Lohnfortzahlungs-Berechnung und den Übergang ins Krankengeld, der [Payroll-Processing-Agent](/de/hr-agent-katalog/payroll-processing-agent/) die Brutto-Netto-Berechnung mit Krankheitsberücksichtigung. Der [Payroll-Reporting-Agent](/de/hr-agent-katalog/payroll-reporting-agent/) erstellt die Meldungen an die Krankenkassen, der [Leave-of-Absence-Agent](/de/hr-agent-katalog/leave-of-absence-agent/) deckt die nicht krankheitsbezogenen Abwesenheiten wie Urlaub und Elternzeit ab. Der [HR-Document-Management-Agent](/de/hr-agent-katalog/hr-document-management-agent/) archiviert die Belege fristgerecht, der [Audit-Compliance-Agent](/de/hr-agent-katalog/audit-compliance-agent/) prüft die GoBD-Konformität, und der [Time-Attendance-Agent](/de/hr-agent-katalog/time-attendance-agent/) liefert die Anwesenheitszeiten als Basis für die Krankheitstage.

## Auf einen Blick

- **Was er tut**: verarbeitet Krankmeldungen regelbasiert - elektronische AU abrufen, Lohnfortzahlung berechnen, Krankengeld-Übergang steuern, BEM-Einladung auslösen
- **Klassifikation**: kein EU-AI-Act-Hochrisiko-System (Dokumenten-Verarbeitung, keine Bewertung von Menschen)
- **Compliance-Anker**: eAU nach §109 SGB IV, Lohnfortzahlung nach EFZG §3, Krankengeld nach SGB V §44, BEM nach SGB IX §167, Gesundheitsdaten nach DSGVO Art. 9
- **Aufbewahrung**: sechs Jahre für Krankmeldungs-Belege, zehn Jahre für Lohnkonten (AO §147, HGB §257)
- **Mitbestimmung**: BetrVG §87 Abs. 1 Nr. 6 zwingend, Beteiligung der Schwerbehindertenvertretung nach SGB IX §178
- **Menschliche Entscheidung**: BEM-Gespräch und krankheitsbedingte Kündigung bleiben beim Menschen
- **Prüfungsfall**: jede Stichprobe einer Lohnsteuer- oder Sozialversicherungsprüfung direkt belegbar

### Entscheider-Verteilung Krankmeldungs-Agent

| Schritt | Decider | Begründung |
|---------|---------|------------|
| eAU-Empfang DSGVO Art. 9 | R | sv.net + DEÜV-Datenbaustein DSAU + KKVD deterministisch |
| EFZG §3 6-Wochen-Berechnung | R | EFZG §4 100 Prozent Brutto deterministisch |
| Anrechnungs-Prüfung 12-Monats-Frist | R | EFZG §3 Abs. 1 Satz 2 deterministisch |
| Krankenkassen-Meldung DEÜV DSAU | R | sv.net + 7-Tage-Frist deterministisch |
| Krankengeld SGB V §44+§47 | R | 70 Prozent Brutto + 78 Wochen deterministisch |
| BEM SGB IX §167 Einladung | R | 6-Wochen-Pflicht + SBV-Beteiligung deterministisch |
| BetrVG §87 Audit-Trail | R | Mitbestimmungs-Recht deterministisch |
| Schwerbehinderten-Schutz SGB IX | R | §164+§178 SBV-Beteiligung deterministisch |
| Anomalie-Detection Long-Term | A | ML-Anomalie-Detection mit menschlicher Validierung |
| BEM-Gespräch | H | Persönliches Gespräch zwingend |
| Krankheits-Kündigung | H | KSchG §1 3-Stufen-Prüfung + BEM zwingend |
| DSGVO-Information | R | Art. 13+14+22 Abs. 3 Standard-Workflow |
| GoBD 6/10-Jahres-Aufbewahrung | R | HGB §257 + AO §147 + Lifecycle deterministisch |

--- Skills-Career-Profile-Agent ---
> Skills-Matching und Karrierepfad-Empfehlung: EU AI Act Annex III(4)(b) Hochrisiko, AGG §22 Beweislast-Umkehr und DSGVO Art. 22 - ESCO/DQR/EQR-Taxonomie mit BetrVG §94 Beurteilungs-Grundsätze.

## Skills-Matching als Compliance-Falle zwischen AGG und EU AI Act

Dieser Agent folgt dem [Decision Layer](/de/decision-layer/)-Prinzip: jede Entscheidung ist entweder regelbasiert, KI-assistiert oder explizit einem Menschen zugeordnet. Er ist nach [EU AI Act 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) Annex III(4)(b) als Hochrisiko-System klassifiziert und unterliegt damit den verschärften Pflichten zu Risikomanagement-System, Daten-Governance, Transparenz, menschlicher Aufsicht und Bias-Audit ab dem 2.8.2026.

Skills-Matching klingt nach einem technischen Problem - es ist ein juristisches. Eine Mitarbeiterin füllt ein Self-Assessment aus, ein Algorithmus aggregiert Performance-Review-Texte, Projekt-Beschreibungen und Lernhistorie, ein ML-Modell inferiert ein Skills-Profil mit Confidence-Score, der interne Talent-Marketplace zeigt ihr passende Stellen an. Aus Compliance-Sicht ist jeder Schritt eine potenzielle Diskriminierungs-Quelle. Wenn das ML-Modell aus Performance-Reviews Generations-spezifische Sprachmuster gelernt hat, korreliert der Confidence-Score mit dem Alter. Wenn die Trainings-Daten überwiegend von männlichen Software-Entwicklern stammen, lernt der Algorithmus weibliche Karriere-Verläufe als Abweichung. Wenn die Skills-Taxonomie keine Eltern-Zeit-Kompetenzen kennt, fehlen drei Jahre Berufs-Erfahrung im Profil.

Drei kumulative Risiko-Schichten greifen ineinander: AGG §22 Beweislast-Umkehr bei Indizien für Diskriminierung in Skills-Klassifikation oder Karriere-Empfehlung mit AGG §15 Entschädigungs-Anspruch bis 3 Bruttomonatsgehälter. DSGVO Art. 22 verbietet rein automatisierte Einzelentscheidungen mit rechtlicher Wirkung - Skills-Klassifikation mit Karriere-Folgen fällt darunter, mit Anfechtungs-Recht Art. 22 Abs. 3. EU AI Act Annex III(4)(b) klassifiziert Task-Assignment-Systeme nach personal traits als Hochrisiko mit Bußgeldern bis 35 Mio EUR oder 7 Prozent globaler Konzernumsatz.

Das Problem zerfällt strukturell in drei Schichten. Erstens: Skills-Daten kommen aus heterogenen Quellen. Self-Assessment ist Selbstauskunft mit Selbstüberschätzungs-Tendenz, Performance-Review-Texte sind subjektiv und Sprachstil-abhängig, Projekt-Beschreibungen verwenden firmenspezifisches Vokabular, Zertifikate sind formal aber oft veraltet. Ein ML-Modell verstärkt die jeweilige Quellen-Bias unkontrolliert. Zweitens: Skills-Taxonomien sind nicht neutral. Wenn Resilienz als Skill definiert wird, aber nicht Care-Arbeit-Erfahrung, filtert die Taxonomie nach geschlechtsspezifischen Karriere-Verläufen. ESCO (Version 1.2.0, 13.485 Skills) und DQR/EQR Niveau 1-8 sind die EU-Standards - aber 80 Prozent der HR-Plattformen ignorieren sie zugunsten proprietärer Frameworks. Drittens: Confidence-Scores werden als objektiv präsentiert, sind aber Modell-spezifisch. Workday Skills Cloud, SAP SuccessFactors Talent Intelligence Hub, Eightfold AI und Microsoft Viva Skills geben unterschiedliche Confidence-Scores für dieselbe Person - keiner der Anbieter veröffentlicht die Modell-Architektur. In ML-gestützten Plattformen wird die Black-Box zur AGG §22-Falle.

## EU AI Act Annex III(4)(b) Task-Assignment Hochrisiko-Klassifikation

Der Skills-Career-Profile-Agent fällt nach EU AI Act 2024/1689 Annex III Punkt 4 Buchstabe b unter Hochrisiko-Systeme für Task-Assignment basierend auf persönlichen Eigenschaften (task-assignment based on personal traits or characteristics). Diese Klassifikation ist breiter als die parallele Beförderungs-Klassifikation - sie umfasst jede algorithmische Zuweisung von Aufgaben, Stellen, Lern-Pfaden oder Karriere-Empfehlungen aus inferierten Persönlichkeits-Eigenschaften. Die Pflichten ab 2.8.2026 umfassen:

- **Article 9 Risikomanagement-System**: Identifikation + Analyse + Bewertung + Mitigation Bias-Risiken bei Skills-Klassifikation (Gender Skills Inference Gap + Age Skills Inference Gap + Ethnicity Career-Path-Empfehlungs-Gap + Disability Career-Path-Empfehlungs-Gap)
- **Article 10 Daten-Governance**: Trainings-Daten-Qualität + Bias-Detection + Demographic Parity-Tests + Equal Opportunity-Tests + Synthetic-Data-Augmentation + ESCO-Taxonomie-konforme Kompetenz-Definition + DQR/EQR-Niveau-Plausibilität
- **Article 13 Transparenz-Pflichten**: Beipackzettel zu Funktions-Weise + Genauigkeit + Robustheit + Bias-Audit-Ergebnisse + Confidence-Score-Erläuterung + Quellen-Attribution-Pflicht
- **Article 14 menschliche Aufsicht**: Mensch-in-the-Loop bei jeder Skills-Profil-Übernahme und jeder Karriere-Empfehlung zwingend
- **Article 26 Deployer-Pflichten**: DPIA + Konsultations-Pflicht Aufsichtsbehörde + post-market monitoring + Incident Reporting bei Algorithmischer-Diskriminierungs-Beschwerden
- **Article 27 FRIA Fundamental Rights Impact Assessment**: vor Inbetriebnahme mit Konsultation Antidiskriminierungs-Stelle + Datenschutzbeauftragter + Betriebsrat

Bußgelder bis 35 Mio EUR oder 7 Prozent globaler Konzernumsatz. Cross-Reference DSGVO Art. 35 DPIA-Pflicht. Die [Mobley v. Workday Sammelklage](https://www.courtlistener.com/docket/67476007/mobley-v-workday-inc/) (Northern District California 2023) - AI-Bias bei HR-Software gegen über 40-jährige Bewerber ADEA - dient als US-Präzedenzfall für Skills-basierte Talent-Plattformen.

## AGG §22 Beweislast-Umkehr bei Skills-basierter Diskriminierung

Im Klagefall greift die Beweislast-Umkehr nach AGG §22: Sobald Mitarbeitende Indizien für eine Diskriminierung anführen können - etwa systematisch niedrigere Confidence-Scores in einer geschützten Gruppe, fehlende Karriere-Empfehlungen trotz vergleichbarer Skills oder einen Talent-Pool-Ausschluss nach Elternzeit -, muss der Arbeitgeber beweisen, dass die KI-Inferenz nicht diskriminierend war. Ohne dokumentierte Confidence-Scores, Quellenangaben, Bias-Audit-Trail und reproduzierbare Begründung pro Klassifikation ist dieser Beweis praktisch nicht zu führen.

AGG §15 sieht eine Entschädigung von bis zu drei Bruttomonatsgehältern pro Mitarbeitendem vor, bei Sammelklagen schnell im siebenstelligen Bereich. Die Zweimonats-Klagefrist beginnt jeweils mit Kenntnis der Talent-Einordnung neu. Die [BAG-Rechtsprechung](https://www.bundesarbeitsgericht.de/) hat den Indizien-Katalog dabei stetig erweitert - inzwischen reicht schon eine statistische Auffälligkeit der Inferenz-Ergebnisse über die geschützten Gruppen.

Hinzu kommt das Datenschutzrisiko: Verstöße gegen die DSGVO können mit bis zu 4 Prozent des Konzernumsatzes geahndet werden, dazu drohen ein Reputationsschaden über die CSRD-Diversitätsberichterstattung und die Aufsichtsratshaftung nach AktG §107. Eine verletzte [BetrVG-Mitbestimmung](https://www.gesetze-im-internet.de/betrvg/) führt zu Unterlassungsansprüchen und Einigungsstellenverfahren bis hin zur konzernweiten Sanktion.

In einer Black-Box-Plattform ist diese Beweislast-Umkehr praktisch nicht zu kontern: Legen die großen Anbieter ihre Modell-Architekturen nicht offen, kann der Arbeitgeber die Reproduzierbarkeit einzelner Klassifikationen nicht garantieren. Die BAG-Rechtsprechung hat den Indizien-Katalog dabei stetig erweitert - inzwischen reichen neben reiner Statistik auch Asymmetrien in der Confidence-Score-Verteilung, Lücken in der Quellenangabe oder abweichende Begründungsmuster über die geschützten Gruppen aus. Das Hinweisgeberschutz-Gesetz schafft zusätzlich Meldestellen, über die Beschäftigte eine algorithmische Diskriminierung anonym und mit Schutz vor Repressalien anzeigen können.

## DSGVO Art. 22 Verbot rein automatisierter Talent-Klassifikation

[DSGVO Art. 22](https://eur-lex.europa.eu/eli/reg/2016/679/oj) verbietet rein automatisierte Einzelentscheidungen, die rechtliche Wirkung entfalten oder die betroffene Person erheblich beeinträchtigen. Skills-Klassifikation mit Karriere-Folgen fällt eindeutig darunter - sie bestimmt Talent-Pool-Zugehörigkeit, Stellen-Sichtbarkeit im internen Marketplace, Lern-Empfehlungen und Beförderungs-Chancen. Der Agent setzt deshalb drei zwingende Mensch-in-der-Schleife-Punkte: Der Mitarbeitende validiert jede inferierte Skill mit Confidence-Score, Quellenangabe und Korrekturmöglichkeit, die Führungskraft validiert die Karriere-Empfehlungen mit Begründungspflicht, und die HR-Leitung gibt die periodischen Klassifikations-Runden nach Sichtung des Bias-Audit-Berichts frei.

Art. 22 Abs. 3 Anfechtungs-Recht ist in jedem Schritt eingebaut - Mitarbeitende können jede automatisierte Empfehlung anfechten mit DSGVO-konformer Begründung und 1-Monats-Frist Antwort. EDPB Guidelines 1/2024 zu HR-KI-Systemen definieren Mindest-Anforderungen: Confidence-Score-Transparenz, Quellen-Attribution, Bias-Audit-Trail, Anfechtungs-Workflow mit Datenschutzbeauftragter-Eskalation.

Das Verbot der Verarbeitung sensibler Daten nach Art. 9 ist im Skills-Kontext besonders kritisch. Biometrische Persönlichkeits-Tests und kognitive Spiele produzieren Daten, die sich als sensible Persönlichkeitsprofile lesen lassen. Und wenn Skills aus alltäglicher Office-Aktivität abgeleitet werden, berührt das den Beschäftigtendatenschutz nach Art. 88 und BDSG §26. Ohne ausdrückliche Einwilligung oder eine Grundlage in einem Tarifvertrag sind solche Inferenzen rechtlich angreifbar.

## Skills-Taxonomie nach ESCO und DQR - und der Präzedenzfall Mobley v. Workday

Die [ESCO European Skills Classification](https://esco.ec.europa.eu/) (Version 1.2.0, 2024) ist die EU-Standard-Taxonomie für Berufe, Fähigkeiten und Kompetenzen: rund 13.890 Berufe und 13.485 Kompetenzen in fünfstufiger Hierarchie, mit Übersetzungen in 28 EU-Sprachen und einem Cross-Walk zu O*NET (US), DISCO (Deutschland) und ROME (Frankreich). Damit ist sie die verbindliche Referenz für mehrsprachige Talent-Marketplaces.

Der [DQR Deutsche Qualifikations-Rahmen](https://www.dqr.de/) und der EQR auf europäischer Ebene ergänzen ESCO um eine Niveau-Zuordnung von 1 bis 8: von der grundlegenden Erfüllung einfacher Anforderungen (Niveau 1) über die berufliche Erstausbildung (Niveau 4) und Bachelor oder Meister (Niveau 6) bis zum Master (Niveau 7) und der Promotion (Niveau 8). Für ausländische Qualifikationen greift die Anerkennung über die Zentralstelle für ausländisches Bildungswesen.

Die [Mobley v. Workday Sammelklage](https://www.courtlistener.com/docket/67476007/mobley-v-workday-inc/) (Northern District California, 2023) ist der Präzedenzfall für KI-Bias in HR-Software gegen über 40-jährige Bewerber - die US-Parallele zur Altersdiskriminierung nach AGG §1. Die Risiko-Mitigation für ein Skills-System ruht auf mehreren Säulen: einem quartalsweisen Bias-Audit über alle acht geschützten Merkmale, einem Audit der Trainingsdaten auf Alters-Bias (kritisch, weil historische Performance-Reviews generationstypische Sprachmuster enthalten können), der Confidence-Score-Schwelle von typisch 70 Prozent mit zwingender menschlicher Validierung darunter, einer Grundrechte-Folgenabschätzung vor Inbetriebnahme und der Mitbestimmung des Betriebsrats über die Beurteilungs-Grundsätze.

## Einbettung in Promotion, Performance-Review und Nachfolge-Planung

Der Skills-Career-Profile-Agent ist in eine Pipeline spezialisierter HR-Agenten eingebettet. Der [Promotion-Process-Agent](/de/hr-agent-katalog/promotion-process-agent/) nutzt dieselbe Skills-Taxonomie, Equity-Analyse und Confidence-Score-Logik für Beförderungs-Empfehlungen, der [Performance-Review-Agent](/de/hr-agent-katalog/performance-review-agent/) liefert die qualitativen Daten für die Skills-Inferenz. Der [Compensation-Benchmarking-Agent](/de/hr-agent-katalog/compensation-benchmarking-agent/) verwendet die Skills-Cluster für die Vergleichsgruppen nach der EU-Entgelttransparenz-Richtlinie, der [Career-Development-Agent](/de/hr-agent-katalog/career-development-agent/) und der [Learning-Recommendation-Agent](/de/hr-agent-katalog/learning-recommendation-agent/) bauen auf den Empfehlungen und der Lücken-Analyse auf. Der [Succession-Planning-Agent](/de/hr-agent-katalog/succession-planning-agent/) nutzt die Profile für die Nachfolge-Planung, der [Recruiting-Agent](/de/hr-agent-katalog/recruiting-agent/) für den Abgleich mit Stellenprofilen. Der [HR-Document-Management-Agent](/de/hr-agent-katalog/hr-document-management-agent/) archiviert die Klassifikations-Begründungen, der [Audit-Compliance-Agent](/de/hr-agent-katalog/audit-compliance-agent/) prüft die Deployer-Pflichten und die Konsistenz von DPIA und FRIA.

## Auf einen Blick

- **Klassifikation**: EU AI Act 2024/1689 Annex III(4)(b) Hochrisiko HR-Task-Assignment basierend auf personal traits ab 2.8.2026
- **Compliance-Anker**: AGG §22 Beweislast-Umkehr, BetrVG §94+§95+§87 Abs. 1 Nr. 6, DSGVO Art. 22+35+88, Mobley v. Workday Präzedenzfall, ESCO + DQR + EQR Skills-Taxonomie, EU Pay Transparency 2023/970, CSRD ESRS S1-9+S1-11
- **Mitbestimmung**: BetrVG §94 Beurteilungs-Grundsätze zwingend + §95 Auswahl-Richtlinien + §87 Abs. 1 Nr. 6 technische Überwachung ML-Plattform + bei Versetzungs-Folge §99, Konzern-Betriebsrat-Pflicht
- **Confidence-Score-Schwelle**: 70 Prozent für automatisierte Profil-Übernahme, darunter zwingend menschliche Validierung
- **Equity-Schwelle**: 5 Prozent unerklärter Skills-Inference-Gap nach AGG §1 acht Merkmale löst ADS-Eskalation + 6-Monats-Abhilfe-Pflicht
- **Bußgelder**: bis 35 Mio EUR oder 7 Prozent globaler Konzernumsatz EU AI Act + bis 4 Prozent oder 20 Mio EUR DSGVO + AGG §15 3 Bruttomonatsgehälter Entschädigung
- **Audit-Pflicht**: DPIA + FRIA + Bias-Audit pro Quartal mit Demographic Parity + Equal Opportunity-Tests, Wirtschaftsprüfer-Prüfung CSRD ab 250 Mitarbeitenden
- **Präzedenzfall**: Mobley v. Workday Northern District California 2023 Sammelklage AI-Bias HR-Software gegen über 40-jährige Bewerber

### Entscheider-Verteilung Skills-Career-Profile

| Schritt | Decider | Begründung |
|---------|---------|------------|
| Skills-Daten-Erfassung | R | Multi-Source-Aggregation mit Quellen-Hierarchie deterministisch |
| ESCO + DQR/EQR-Mapping | R | Taxonomie-Mapping mit Match-Score-Cutoff deterministisch |
| Berechtigungs-Prüfung Datenzugriff | R | DSGVO Art. 6+9+88 + BDSG §26 Rechtsgrundlage-Logik |
| ML-Skills-Inference | A | LLM-Output Indikator mit Confidence-Score + Quellen-Attribution |
| DSGVO Art. 22 Information | R | Art. 13+14+22 Abs. 3 Standard-Workflow |
| Mitarbeiter-Korrektur | R | Aufnahme mit Audit-Trail + Quellen-Hierarchie |
| Equity-Analyse | A | ML-statistische Bias-Detection mit menschlicher Validierung |
| Karriere-Pfad-Empfehlung | A | ML-Empfehlung mit Confidence-Score-Schwelle 60 Prozent |
| BetrVG §94+§95 Mitbestimmung | R | Konsultations-Workflow Beurteilungs-Grundsätze deterministisch |
| Skills-Lücken-Analyse | A | ML-Empfehlung Lern-Pfade mit Confidence-Score |
| HR-Leitung-Validierung | H | Finale Freigabe AGG §22 + DSGVO + Bias-Audit |
| DSGVO-Mitarbeiter-Rechte | R | Art. 15-18+21+22 Abs. 3 Workflow deterministisch |
| Führungskraft-Karriere-Gespräch | H | Persönliches Gespräch Beziehungs-Dimension |
| CSRD-Reporting | R | ESRS S1-9+S1-11 + EU Pay Transparency Art. 7 deterministisch |

--- Strategic-HR-Analytics-Agent ---
> Strategic HR-Analytics für Board- und CSRD-Reporting: jede Kennzahl ist Regelwerk, KI-Indikator oder Mensch zugeordnet - testat-fest und prüfbar.

## Jedes Dashboard zeigt Zahlen. Keines sagt, ob der Prüfer sie akzeptiert

Börsennotierte Konzerne brauchen für ihr Board- und Pflicht-Reporting keine weiteren KI-Insights, sondern Personalzahlen, die einer Prüfung standhalten. Die eigentliche Leistung des Strategic-HR-Analytics-Agenten ist deshalb nicht, schneller zu rechnen, sondern jede Kennzahl nachweisbar einem Entscheider zuzuordnen. Für jede Zahl ist belegt, ob sie aus einem festen Regelwerk, einem KI-Indikator oder einer menschlichen Entscheidung stammt. Genau diese Zuordnung ist der Unterschied zwischen einer Zahl, die im Vorstand gut aussieht, und einer Zahl, die der Wirtschaftsprüfer und der Betriebsrat akzeptieren.

Damit verschiebt sich der Anspruch an HR-Analytik. In einem regulierten Umfeld zählt nicht die schönste Auswertung, sondern die belastbarste. Eine nicht nachweisbare Kennzahl wird im Pflicht-Reporting schnell zum Risiko, weil sie weder vor der Datenschutzbehörde noch vor dem Prüfungsausschuss Bestand hat.

## Eine nicht belastbare Kennzahl ist im Pflicht-Reporting ein direktes Risiko

Wer Personaldaten nicht auditierbar auswertet, riskiert handfeste Folgen statt nur unsauberer Statistik. Bei Verstößen gegen die Verarbeitung von Beschäftigtendaten drohen nach Art. 83 Abs. 5 DSGVO Bußgelder von bis zu 20 Mio. EUR oder 4 Prozent des weltweiten Konzern-Jahresumsatzes, wobei der höhere Betrag gilt. Nicht belastbare Belegschafts-Kennzahlen führen zudem zu einem eingeschränkten Wirtschaftsprüfer-Testat, und das ist für ein börsennotiertes Unternehmen ein Reputations- und Kursrisiko.

Hinzu kommt die Mitbestimmung. Jede Software, die nach Paragraph 87 Abs. 1 Nr. 6 BetrVG objektiv zur Verhaltens- oder Leistungsüberwachung geeignet ist, ist zwingend mitbestimmungspflichtig. Ohne Betriebsvereinbarung kann der Betriebsrat die Einführung über die Einigungsstelle stoppen, und dann steht das System still, egal wie gut es rechnet. Eine HR-Analytik-Lösung, die diese Hürde nicht von Beginn an bedient, ist im Konzern nicht einsetzbar.

## Wenn Fluktuation zur Kennzahl wird, muss die Kennzahl prüfbar sein

Personalkennzahlen sind kein weiches Thema mehr, sondern eine harte Größe mit direkter wirtschaftlicher Wirkung. Nur 10 Prozent der Beschäftigten in Deutschland haben eine hohe emotionale Bindung an ihren Arbeitgeber, einer der niedrigsten Werte seit Beginn der Erhebung, während 77 Prozent Dienst nach Vorschrift machen ([Gallup Engagement Index Deutschland 2025](https://www.gallup.com/de/472028/bericht-zum-engagement-index-deutschland.aspx)). Der dadurch entstandene volkswirtschaftliche Schaden durch innere Kündigung lag 2025 bei über 119 Mrd. EUR.

Auf der Ebene des einzelnen Unternehmens schlägt das ebenfalls durch. Ein Mitarbeiter-Abgang kostet zwischen 90 und 200 Prozent des Brutto-Jahresgehalts der ausscheidenden Person, im Durchschnitt rund 43.000 EUR je Fall ([Fluktuationskosten, Sage 2016](https://www.sage.com/de-de/blog/fluktuationskosten-verstehen-berechnen-und-aktiv-reduzieren/)). Eine Fluktuationsanalyse, die diese Kosten belastbar sichtbar macht, wird damit zum Hebel für eine messbare Steuerung. Genau hier liefert der Agent die reproduzierbare Datengrundlage, auf der die Personalleitung handeln kann.

## Der Decision-Layer ordnet jede Zahl ihrem Verantwortlichen zu

Die tragende Logik des Agenten ist, dass fast alles Regelwerk ist und die KI nur an den Rändern als Indikator dient. Jede Kennzahl wird genau einem Verantwortlichen zugeordnet, und diese Zuordnung ist offengelegt.

| Verantwortlich | Was entschieden wird | Beispiel aus der Praxis |
|---|---|---|
| Regelwerk | Kennzahlen mit fester Definition | Fluktuations-Quote, Entgeltlücke, ESRS-S1-Mapping |
| KI-Indikator | Auffälligkeiten, die ein Mensch prüfen sollte | Anomalie in Workforce-Trends, Bandbreiten-Prognose |
| Mensch | Strategische Bewertung und Freigabe | Board-Kommentar, Vier-Augen-Freigabe vor dem Report |

Die berichtspflichtigen Kennzahlen wie Fluktuation, Diversität und der Gender-Pay-Gap werden ausschließlich aus festen Formeln auf aggregierten Daten berechnet, denn nur so sind sie reproduzierbar und testat-fest. Die KI rechnet bewusst keine Pflichtzahl, weil das ein Testat-Risiko wäre. Sie markiert lediglich Datenanomalien zur Prüfung und liefert Workforce-Prognosen als Bandbreiten, und auch das immer nur als unverbindlichen Indikator.

Die Deutung dieser Zahlen und jede strategische Personalentscheidung bleiben beim Menschen, weil der Geschäftskontext aus Strategie und Standorten nicht automatisierbar ist. Die finale Freigabe des Reporting-Stapels erfolgt im Vier-Augen-Prinzip, denn die Haftung nach den Paragraphen 93 und 116 AktG verlangt eine menschliche Verantwortung. Diese saubere Trennung ist die Antwort auf den verbreiteten Einwand, die KI halluziniere den Board-Report. Wie der [Decision Layer](/de/decision-layer/) im Detail funktioniert, ist an zentraler Stelle beschrieben und gilt für jede Kennzahl gleichermaßen.

## People-Analytics prüfbar machen statt nur visualisieren

Klassische People-Analytics-Anbieter verkaufen ein Dashboard mit KI-Insights, also eine Blackbox, die Zahlen ausspuckt. In einem regulierten Konzernumfeld ist diese Blackbox ein Problem, weil niemand nachvollziehen kann, ob eine Zahl regelbasiert oder geschätzt ist. Der Strategic-HR-Analytics-Agent dreht das um und legt pro Kennzahl offen, ob ein Regelwerk, ein KI-Indikator oder ein Mensch entschieden hat. Genau diese Offenlegung verlangt der Wirtschaftsprüfer auf dem Weg von limited zu reasonable assurance, und genau sie verlangt der Prüfungsausschuss nach Paragraph 107 Abs. 4 AktG.

Der Audit-Trail aus Quelldaten-Version, Aggregations-Logik und menschlichem Freigabe-Schritt entsteht dabei als Nebenprodukt der Architektur und nicht als nachträgliche Pflichtübung. Das ist das Dokument, das der Betriebsrat unterschreibt, weil es die Mitbestimmung nachvollziehbar abbildet. Auch die DSGVO-Konformität wird strukturell erzwungen, indem die k-Anonymität als feste Schwelle gilt. Das ist die richtige Antwort darauf, dass sich nach dem EuGH-Urteil zu C-34/21 niemand mehr bequem allein auf Paragraph 26 BDSG berufen kann.

## Die Pflichtschwelle hat sich verschoben und die Datenbasis muss das abbilden

Eine veraltete Pflichtschwelle auf einer Compliance-Grundlage ist das Gegenteil von Vertrauen, deshalb muss die Datenbasis den aktuellen Rechtsstand abbilden. Die CSRD-Berichtspflicht greift nach dem EU-Omnibus aus 2025 und 2026 erst ab mehr als 1.000 Beschäftigten und mehr als 450 Mio. EUR Netto-Umsatz, und die Berichtswellen wurden um zwei Jahre verschoben. Damit fällt ein großer Teil der ursprünglich erfassten Firmen heraus, während die Pflicht für große, börsennotierte Konzerne unverändert bleibt. Genau diese Konzerne sind die Zielgruppe des Agenten.

Parallel kommt mit der EU-Entgelttransparenzrichtlinie eine harte Berichtspflicht zur Entgeltgleichheit. Ab einem unerklärten Pay-Gap von 5 Prozent in einer Beschäftigtengruppe wird eine gemeinsame Entgeltbewertung verpflichtend ([Richtlinie 2023/970, Art. 10](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32023L0970)). Der Agent weist diesen Schwellenwert je Vergleichsgruppe deterministisch aus und löst die Pflicht fristgerecht aus, statt sie vage zu umschreiben. Da unsaubere Vergütungsdaten über Paragraph 22 AGG zudem die Beweislast umkehren können, wird eine belastbare Datenbasis hier direkt zum Schutz vor Prozessrisiken.

## Vom belastbaren Reporting zur konsistenten Personalstrategie

Der Strategic-HR-Analytics-Agent ist als prüfbare Schicht über den bestehenden HR-Systemen konzipiert und ersetzt diese nicht. Er liest aus Quellsystemen wie SAP SuccessFactors, Workday oder Personio, ohne sie abzulösen, und gibt seine Ergebnisse mit vollständigem Decision-Layer-Nachweis zurück. Auf dieser konsistenten Datenbasis bauen weitere Schritte der Personalstrategie auf, von der Workforce-Planung bis zum ESG-Reporting. Eine belastbare Kennzahl-Hoheit ist damit kein Selbstzweck, sondern die Grundlage für jede weitere Prozess-Analyse im Personalbereich.

Der nächste Schritt ist keine Tool-Auswahl, sondern eine Bestandsaufnahme: Welche Ihrer berichtspflichtigen Kennzahlen können Sie heute Zeile für Zeile einem Regelwerk, einem KI-Indikator oder einem Menschen zuordnen - und welche nicht? Genau diese Frage ist der Einstieg in die Prozess-Analyse.

## Auf einen Blick

- **Was er tut:** Er zieht Personal-Stammdaten aus den Quellsystemen, berechnet Kennzahlen nach festem Regelwerk und protokolliert jeden Rechenschritt zu einem prüfbaren Audit-Trail.
- **EU-AI-Act-Klassifikation:** Kein Hochrisiko-System. Er liefert aggregierte, anonymisierte Analytik auf Konzernebene und entscheidet nicht über einzelne Beschäftigte.
- **Entscheidungslogik:** Kennzahlen mit fester Definition kommen aus dem Regelwerk, Auffälligkeiten sind als KI-Indikator gekennzeichnet, die strategische Bewertung und die Vier-Augen-Freigabe bleiben beim Menschen.
- **Compliance-Anker:** DSGVO (Art. 9, 22, 88), CSRD und ESRS S1, EU-Entgelttransparenzrichtlinie 2023/970, Aktiengesetz Paragraph 107 zum Prüfungsausschuss.
- **Integration:** Eine prüfbare Schicht über SAP SuccessFactors, Workday, Personio oder Visier - die führenden Systeme bleiben die Quelle der Wahrheit.
- **Prüfungsfall:** Jede berichtete Kennzahl ist per Audit-Trail bis zur Rohdaten-Quelle rückverfolgbar.

--- Nachfolgeplanungs-Agent ---
> Nachfolgeplanung mit nachvollziehbarem 9-Box-Grid und Readiness-Analyse: deterministische Aggregation, KI nur als Indikator, die Talent-Review entscheidet.

## Nachfolgeplanung scheitert nicht am Tool, sondern an der Zuständigkeit

Die meisten Unternehmen besitzen längst ein Talent-Management-System, und trotzdem ist ihre Nachfolge-Pipeline ein blinder Fleck. Das liegt nicht an fehlenden Funktionen, sondern daran, dass niemand verbindlich festgelegt hat, welche Bewertung eine Maschine treffen darf und welche ein Mensch verantworten muss. Genau diese Lücke schliesst der Nachfolgeplanungs-Agent: Er rechnet die Pipeline deterministisch und macht an jedem Schritt prüfbar, ob das Regelwerk, die KI als Indikator oder der Mensch entscheidet. Wie diese Schicht architektonisch durchgreift, beschreibt der [Decision Layer](/de/decision-layer/).

## Wer Schlüsselpositionen erst beim Abgang bemerkt, hat den teuersten Fehler bereits gemacht

Der eigentliche Schaden einer schwachen Nachfolgeplanung entsteht lautlos. Eine kritische Rolle in der Produktion, im Vertrieb oder in der Forschung hängt oft an einer einzigen Person, und solange diese Person bleibt, fällt das Risiko nicht auf. Geht sie, beginnt eine externe Suche, die Monate dauert, das Gehaltsgefüge verschiebt und das verlorene Wissen nur teilweise zurückholt. Der Bus-Factor - die Frage, wie viele Personen ein Unternehmen verlieren kann, bevor eine Funktion zusammenbricht - ist deshalb keine reine HR-Kennzahl, sondern eine Frage der Betriebssicherheit. Der Agent macht diesen Bus-Factor sichtbar, bevor der Ernstfall eintritt, indem er für jede Schlüsselposition deterministisch prüft, ob ein qualifizierter Nachfolger in der Pipeline steht.

## Eine Bewertung über Aufstieg ist rechtlich kein Komfortthema, sondern ein Hochrisiko-Feld

Sobald eine Software Leistung und Potenzial von Beschäftigten bewertet und damit Aufstiegschancen beeinflusst, betritt sie reguliertes Terrain. Der EU AI Act ordnet Systeme, die über Beförderung entscheiden oder Beschäftigte bewerten, in Anhang III ausdrücklich als hochriskant ein - mit der vollen Last aus Risikomanagement, Daten-Governance und Konformitätsbewertung. Die Datenschutz-Grundverordnung verbietet zugleich in Artikel 22 eine allein automatisierte Entscheidung mit erheblicher Wirkung. Wer eine High-Potential-Klassifikation also von der KI verbindlich entscheiden lässt, kauft sich genau diese Pflichten ein. Der Agent vermeidet das bewusst: Die Aggregation ist deterministisch, die KI markiert High-Potentials und Readiness nur als Indikator, und die finale Nominierung trifft eine menschliche Talent-Review-Konferenz. Damit ist das System per Konstruktion kein Hochrisikosystem, weil die regulierte Entscheidung nie bei der Maschine liegt.

## Nachfolgeplanung mit 9-Box-Grid: drei Quellen, klar getrennt

Der Unterschied zu einem gewöhnlichen Talent-Tool liegt nicht in mehr Funktionen, sondern darin, dass jeder Schritt genau einer Quelle zugeordnet ist - und genau das macht die Pipeline prüfbar. Das ist die ehrliche Antwort auf den Einwand, ob eine KI darüber bestimmen darf, wer aufsteigt: Nein, sie markiert nur, der Mensch nominiert.

| Quelle | Beispiel-Schritt | Wer entscheidet |
| --- | --- | --- |
| Regelwerk (R) | 9-Box-Grid aus dokumentierten Leistungs- und Potenzialdaten berechnen | deterministische Formel, kein Ermessen |
| KI-Indikator (A) | High-Potential markieren und an die Talent-Review eskalieren | KI schlägt vor, ein Mensch prüft und überstimmt |
| Mensch (H) | Kandidaten offiziell als Nachfolger nominieren | ausschliesslich die Talent-Review-Konferenz |

## Der Audit-Trail ist die entscheidende Verteidigung gegen die Beweislastumkehr

Im Diskriminierungsrecht kippt die Beweislast schnell. Legt eine Person Indizien dar, dass sie wegen Geschlecht, Alter, Behinderung oder Herkunft übergangen wurde, muss der Arbeitgeber beweisen, dass die Auswahl diskriminierungsfrei war. Ein 9-Box-Grid, dessen Zustandekommen niemand erklären kann, ist in diesem Moment kein Werkzeug mehr, sondern ein Risiko - und im Unterliegensfall droht eine Entschädigung bis zu drei Monatsgehälter. Der Agent rechnet jede Einordnung aus dokumentierten Quelldaten und prüft die Auswahlquoten mit der Vier-Fünftel-Regel auf einseitige Wirkung. Jede Empfehlung bleibt auf ihre Datenbasis zurückführbar. So entsteht genau die nachvollziehbare Kette, mit der ein Unternehmen die Beweislast nach dem Allgemeinen Gleichbehandlungsgesetz tatsächlich tragen kann, statt sie zu fürchten.

## Betriebsrat und Aufsichtsrat unterschreiben Nachvollziehbarkeit, nicht Black Boxes

Eine Nachfolgeplanung wird im Unternehmen nicht im luftleeren Raum eingeführt. Auswahlrichtlinien und Beurteilungsgrundsätze für Beförderungen sind nach dem Betriebsverfassungsgesetz mitbestimmungspflichtig, und ohne abgestimmte Richtlinie kann der Betriebsrat einer konkreten Beförderung die Zustimmung verweigern. Bei börsennotierten Gesellschaften bestellt der Aufsichtsrat den Vorstand und überwacht die Geschäftsführung, und der Deutsche Corporate Governance Kodex empfiehlt, dass Aufsichtsrat und Vorstand gemeinsam für eine langfristige Nachfolgeplanung sorgen. Beide Gremien brauchen dasselbe: eine Logik, die sie nachvollziehen können. Der Agent liefert dem Betriebsrat die protokollierte Auswahl-Logik und dem Aufsichtsrat einen prüfbaren Pipeline-Report. Nachvollziehbarkeit ist hier kein Zusatz, sondern die Voraussetzung dafür, dass die Planung überhaupt wirksam angewendet werden darf.

## Eine Schicht über den bestehenden Systemen, nicht an deren Stelle

Der Agent ersetzt kein vorhandenes Talent-Management-System, sondern legt sich als Entscheidungsschicht darüber. Er liest aus den führenden Systemen wie SAP SuccessFactors, Workday oder Eightfold, rechnet die Pipeline transparent und gibt die Ergebnisse an die menschliche Entscheidung zurück. Der Unterschied zu den üblichen Tools liegt nicht in mehr Funktionen, sondern darin, dass pro Schritt belegbar ist, wer entscheidet: Das Regelwerk rechnet, die KI markiert als Indikator, der Mensch entscheidet - die Architektur dahinter zeigt der [Decision Layer](/de/decision-layer/).

Der nächste Schritt ist keine neue Software, sondern eine Bestandsaufnahme: Welche Bewertungen in Ihrer Nachfolge-Pipeline kann heute niemand belegbar verantworten? Eine strukturierte Analyse Ihres konkreten Nachfolgeprozesses zeigt, welche Schritte geregelt sind und welche im Unklaren liegen.

## Auf einen Blick

- **Was er tut**: aggregiert die Nachfolge-Pipeline deterministisch (9-Box-Grid, Readiness, Risiko) und protokolliert jede Bewertung nachvollziehbar
- **Klassifikation**: bewusst kein EU-AI-Act-Hochrisiko-System (deterministische Aggregation, KI nur als Indikator, Mensch entscheidet)
- **Entscheidungslogik**: überwiegend Regelwerk, KI als Indikator an den Rändern, finale Nominierung in der Talent-Review-Konferenz
- **Compliance-Anker**: DSGVO Art. 22, Allgemeines Gleichbehandlungsgesetz (Paragraph 22), BetrVG (Paragraph 94, Paragraph 95), AktG (Paragraph 84, Paragraph 111), Deutscher Corporate Governance Kodex
- **Integration**: Schicht über SAP SuccessFactors, Workday, Cornerstone oder Eightfold - kein Ersatz
- **Streitfall**: jede 9-Box-Einordnung bis zur Quelldatei zurückführbar, Auswahlquoten mit der Vier-Fünftel-Regel geprüft

--- Talent-Pool-Management-Agent ---
> Talent-Pool DSGVO-konform: Einwilligung als Grundlage, 6-Monats-Löschfrist für Unterlagen, AGG-sichere Auswahl. Die KI sortiert vor, der Mensch entscheidet.

## Ein Fehler im Pool kostet mehr als der ganze Effizienzgewinn

Wer einen Talent-Pool als Datenbank für abgelehnte Bewerber begreift, unterschätzt das rechtliche Risiko. Die Speicherung selbst ist trivial; die schwierige Frage ist, wer in den Pool darf, wie lange er bleibt und nach welchen Kriterien er für eine neue Stelle wieder hervorgeholt wird. Jede dieser Fragen ist gesetzlich vordefiniert, und ein einziger Fehler kostet schnell mehr als der gesamte Effizienzgewinn, den der Pool je einbringt: Ein Datenschutzverstoß fällt in den oberen Bußgeld-Rahmen der DSGVO, und eine diskriminierende Vorauswahl löst eine Entschädigung nach dem AGG aus.

Ein KI-Agent löst dieses Problem nicht, indem er den Pool automatisch pflegt. Er löst es, indem er pro Schritt sauber trennt, wer entscheidet: Regelwerk, KI oder Mensch. Genau das leistet der [Decision Layer](/de/decision-layer/) - er macht nachprüfbar, dass die rechtlich heiklen Entscheidungen dort liegen, wo sie liegen müssen. Damit ist der Agent eine Schicht über den bestehenden Recruiting-Systemen, nicht ihr Ersatz.

## Talent-Pool DSGVO-konform aufbauen: was Regelwerk ist und was nicht

Fast alles, was den Pool rechtssicher macht, ist deterministisch. Die Aufnahme setzt eine gültige Einwilligung nach Art. 6 Abs. 1 lit. a DSGVO voraus - vorhanden oder nicht, ohne Ermessen. Die Aufbewahrungsfrist abgelehnter Unterlagen beträgt sechs Monate - zwei Monate zur Geltendmachung von AGG-Ansprüchen nach Paragraph 15 Abs. 4 AGG, drei Monate Klagefrist nach Paragraph 61b ArbGG und ein Monat Puffer; danach greift die Löschpflicht nach Art. 17 DSGVO kalendergenau. Die Pool-Einwilligung selbst ist auf ein bis zwei Jahre zu befristen, wie es die Datenschutz-Aufsichtsbehörden empfehlen, und läuft dann regelbasiert ab.

Auch die diskriminierungsfreie Segmentierung ist Regelwerk: Erlaubte Kriterien wie Erfahrung, Zertifikate und Sprachen stehen auf einer Whitelist, verbotene Merkmale wie Alter, Geschlecht oder Herkunft auf einer Blacklist. Selbst die Frage, ob der Betriebsrat zustimmen muss, folgt einer klaren Klassifikationsregel - eine Plattform mit Tracking gilt als technische Überwachungseinrichtung nach Paragraph 87 BetrVG und löst die Mitbestimmung aus. Ein Agent kann diese Schritte schneller und fehlerfreier abarbeiten als ein Mensch, und jeder Schritt bleibt auf seine Regel zurückführbar.

## Die KI liefert genau einen Indikator: den Vorschlag, nicht die Entscheidung

Der einzige Schritt, der sich nicht in Regeln fassen lässt, ist die Vorauswahl. Wenn eine Vakanz offen ist, berechnet die KI ein Ranking der passenden Pool-Kandidaten. Dieses Ranking ist ein Modell-Output und damit unscharf; es ist ein Hinweis, kein Faktum. Genau hier, und nur hier, liefert die KI ihren Mehrwert: Sie sichtet einen großen Pool in Sekunden und schlägt vor, wen ein Recruiter genauer ansehen sollte.

Damit dieser Vorschlag verwertbar bleibt, muss er anfechtbar sein. Das Ranking ist erklärbar zu halten und gegen einen Bias-Audit zu prüfen, denn ab dem 2. August 2026 gilt Recruiting-KI nach Anhang III Nummer 4 des EU AI Act als Hochrisiko-System mit voller Pflicht zu Risikomanagement, Bias-Tests und menschlicher Aufsicht. Eine politische Einigung vom Mai 2026 will diesen Stichtag für Standalone-Systeme auf Ende 2027 verschieben - bis das im Amtsblatt steht, ist der August 2026 das bindende Datum.

## Die ergebnisrelevante Entscheidung bleibt strukturell beim Menschen

Wer am Ende angesprochen und eingeladen wird, ist eine rechtlich erhebliche Auswahl-Entscheidung. Sie darf nach Art. 22 DSGVO und Artikel 14 des EU AI Act nicht von der KI getroffen werden, sondern vom Recruiter. Der KI-Vorschlag ist dabei Input, keine Vorentscheidung, und der Mensch muss ihn überstimmen können. Ebenso bleibt die juristische Beurteilung beim Menschen, ob bei einer AGG-Klage belegbar nicht diskriminiert wurde - die Bewertung der Beweislage nach Paragraph 22 AGG ist kein Rechenproblem.

Genau diese Verankerung macht den Pool betriebsratsfähig. Ein System, bei dem belegbar ist, dass die KI nur vorschlägt und nie über Menschen entscheidet, lässt sich einer Mitbestimmungs-Instanz vermitteln - ein Black-Box-Matcher nicht. Die Trennung in Regelwerk, KI-Indikator und menschliche Freigabe ist damit nicht nur rechtlich geboten, sondern auch das Argument, das eine Pool-Plattform überhaupt durch die Gremien bringt.

## Warum die Entscheidungs-Architektur das eigentliche Produkt ist

Wettbewerber verkaufen einen DSGVO-konformen Talent-Pool mit Einwilligungs-Workflow und Audit-Trail. Das ist Feature-Sprache, eine reine Speicher- und Workflow-Funktion. Sie bieten Bias-Audit-Module an, lassen aber offen, ob die KI am Ende doch durchentscheidet. Vor Gericht zählt jedoch nicht, dass ein Tool im Einsatz war, sondern dass der Entscheidungs-Layer pro Schritt belegbar ist. Bei der Beweislastumkehr nach Paragraph 22 AGG ist der dokumentierte Decision-Record die Verteidigung, nicht das Logo des Bewerbermanagement-Systems.

Dieser Agent verkauft deshalb keine weitere Datenbank, sondern eine prüfbare Entscheidungs-Architektur: Pro Mikroschritt ist festgehalten, ob das Regelwerk, die KI oder der Mensch entschieden hat. Regelwerk hält Fristen und Rechtsgrundlagen, KI sortiert vor, der Mensch entscheidet, wen er anspricht. Der Pflegeaufwand für Einwilligungs-Trail, Betriebsvereinbarung und Kriterienkatalog zahlt sich genau dann aus, wenn aus dem Pool eine offene Stelle ohne erneute Ausschreibung besetzt wird - und im Prüfungsfall jede Speicherung und jede Auswahl belegbar bleibt. Wer diesen Ansatz auf das eigene Recruiting übertragen will, sollte als Nächstes eine Prozess-Analyse der eigenen Bewerber- und Pool-Pflege angehen - sie zeigt, an welchen Stellen heute noch unklar ist, wer eigentlich entscheidet.

## Auf einen Blick

- **Was er tut:** Er verwaltet abgelehnte Bewerber in einem rechtssicheren Talent-Pool, holt und versioniert die Einwilligung, überwacht Löschfristen automatisch und liefert bei offenen Stellen einen Passungs-Indikator.
- **Klassifikation:** Hybrid - Einwilligung, Fristen und Löschung sind Regelwerk, die Vorauswahl bleibt beim Menschen.
- **Entscheidungslogik:** Regelbasierte Compliance-Schritte mit KI-Passungs-Indikator; die wertende Vorauswahl trifft der Recruiter.
- **Compliance-Anker:** DSGVO (Art. 6, 7, 17, 22), BDSG, AGG (Paragraph 15, 22), BetrVG (Paragraph 87), EU AI Act (Anhang III Nummer 4).
- **Integration:** Legt sich als Decision-Layer über das bestehende Recruiting-System (Personio, Greenhouse, SAP SuccessFactors) - kein Ersatz.
- **Prüfungsfall:** Bei einer Datenschutz-Prüfung oder einer AGG-Entschädigungsklage ist jede Speicherung auf ihre Rechtsgrundlage und jede Vorauswahl auf ihren menschlichen Entscheider zurückführbar.

--- HR-Steuer-SV-Stammdaten-Agent ---
> HR-Workflow Steuer- und SV-Stammdaten: ELStAM-Pflege §39e EStG, Krankenkassen-Wahl, Steuerklassen-Wechsel-Prüfung, Konfession und KiSt-Erfassung - vor der Lohnabrechnung.

## Lohnsteuer, SV-Meldungen und Bescheinigungen - termingerecht statt im Fristen-Marathon

Dieser Agent folgt dem [Decision Layer](/de/decision-layer/)-Prinzip: Jede Entscheidung ist entweder regelbasiert, KI-assistiert oder explizit einem Menschen zugeordnet. Nach [EU AI Act 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) ist er kein Hochrisiko-System, weil er keine Menschen bewertet, sondern Meldungen nach festen Regeln erzeugt. Seine strengen Pflichten kommen aus dem Steuer- und Sozialrecht - vom Lohnsteuerrecht des EStG über die DEÜV und das ELStAM-Verfahren bis zu SGB IV, GoBD, DSGVO und der Mitbestimmung nach BetrVG -, und die Sanktionen bei Verstößen sind hart.

Eine typische Steuer- und SV-Pipeline verarbeitet pro Monat Hunderte bis Tausende Lohn-Abrechnungs-Datensätze zu Lohnsteuer-Anmeldungen, DEÜV-Meldungen, GKV-Monatsmeldungen, UV-Meldungen und Erstattungsverfahren. Wer das manuell über Excel und Hand-Eingaben in ELSTER und sv.net erledigt, braucht Tage und produziert Fehler. Eine Deloitte Global Payroll Benchmarking Survey zeigt: über 30 Prozent der Unternehmen brauchen mehr als vier Arbeitstage für den monatlichen Payroll-Close. Laut einer EY Global Payroll Survey verbringen Payroll-Vollzeitstellen im Schnitt 29 Wochen pro Jahr mit Fehlerkorrektur.

Der Agent erzeugt diese Meldungen in Sekunden, deterministisch aus der fertigen Brutto-Netto-Abrechnung, dem Personalstamm, der Lohnsteuer-Tabelle, der Beitragssatz-Datenbank und dem monatlichen ELStAM-Abruf. Das eigentliche Problem ist nicht das Volumen, sondern die mathematisch exakte Verkettung vieler Fristen: Lohnsteuer-Anmeldung zum 10. des Folgemonats, jährliche Bescheinigung bis 28.2., DEÜV-Jahres-Meldung bis 15.2., GKV-Monatsmeldung zum drittletzten Bankarbeitstag, UV-Jahres-Meldung zum 31.12. - und das über mehr als 95 verschiedene Krankenkassen hinweg.

## Lohnsteuer: monatliche Anmeldung, ELStAM-Abruf und Jahres-Bescheinigung

[EStG §41a](https://www.gesetze-im-internet.de/estg/__41a.html) verpflichtet jeden Arbeitgeber zur monatlichen Lohnsteuer-Anmeldung an das Finanzamt, zum 10. des Folgemonats und elektronisch via ELSTER. Bemessungs-Grundlagen, Steuersätze, Freibeträge, Solidaritäts-Zuschlag und Kirchensteuer (8 Prozent in Bayern und Baden-Württemberg, sonst 9 Prozent) ergeben sich aus der fertigen Lohnabrechnung. §41 verlangt zusätzlich die Aufzeichnung im Lohn-Konto, §42 die jährliche elektronische Lohnsteuer-Bescheinigung bis zum 28.2. des Folgejahres an das Bundeszentralamt für Steuern samt Bescheinigung pro Mitarbeiter.

Der monatliche ELStAM-Abruf nach EStG §39e (elektronische Lohnsteuerabzugsmerkmale) liefert Lohnsteuer-Klasse, Freibetrag nach §39a, Faktor-Verfahren und Kirchensteuer-Merkmal; die Berechnung läuft über das Tabellenverfahren nach §39b. Verstöße gegen Lohnsteuer-Pflichten haben spürbare Folgen:

- **Haftung Arbeitgeber §42d EStG** für fehlerhafte Lohnsteuer-Anmeldung
- **Lohnsteuer-Außenprüfung §42f EStG** mit Nachforderung, Säumniszuschlägen und Hinterziehungs-Zinsen von 6 Prozent jährlich
- **Sozialversicherungs-Prüfung §28p SGB IV** alle 4 Jahre Beanstandung bei DEÜV-Mängeln
- **§266a StGB** Vorenthalten von Sozialversicherungs-Beiträgen Freiheits-Strafe bis 5 Jahre
- **Steuer-Hinterziehung §370 AO** bei vorsätzlicher Manipulation
- **DSGVO Art. 83** bis 4 Prozent Konzernumsatz bei Verletzung Art. 88 Beschäftigtendaten-Verarbeitung

Hinzu kommen die GoBD-Anforderungen nach den BMF-Schreiben von 2019 und 2022: Verfahrensdokumentation, IT-Sicherheits-Konzept, Versions-Verwaltung mit Stichtags-Aktivierung, der Z3-Daten-Zugriff für die Betriebsprüfung und die zehnjährige Aufbewahrung nach HGB §257 und AO §147. Der Agent konsolidiert die zwölf monatlichen Anmeldungen nach §41a EStG zur Jahres-Bescheinigung nach §42 EStG. Korrektur-Läufe nach einer Außenprüfung werden protokolliert, begründet und zwingend im Vier-Augen-Prinzip mit Steuerberater-Stichprobe freigegeben.

## Sozialversicherung: DEÜV-Meldungen via sv.net an 95 Krankenkassen

Die DEÜV-Datenerfassungs-und-Übermittlungs-Verordnung verlangt elektronische Meldungen an die Sozialversicherungs-Träger, via sv.net über die DSRV (Datenstelle der Renten-Versicherungs-Träger). Der Datenbaustein DBME trägt den vierstelligen Beitrags-Gruppen-Schlüssel für Kranken-, Renten-, Arbeitslosen- und Pflege-Versicherung, den achtstelligen Tätigkeits-Schlüssel TS-2010 sowie Bemessungs-Grundlage und Beitragstage. Die Meldegründe sind fest definiert: Anmeldung zum ersten Tag (10), Abmeldung zum letzten (30), Jahres-Meldung bis 15.2. (50) und Unterbrechungen wie Krankheit, Mutterschutz oder Elternzeit (51 bis 58).

[SGB IV §28a](https://www.gesetze-im-internet.de/sgb_4/__28a.html) verlangt die Anmeldung neuer Mitarbeiter, §28b Sondermeldungen, §28e die Beitragsabführung durch den Arbeitgeber und §28f die Aufzeichnung im Lohn-Konto mit allen Lohn-Bestandteilen, Beitrags-Gruppen und der Bemessungs-Grundlage. §28h setzt die Beitragsfälligkeit auf den drittletzten Bankarbeitstag des Beitrags-Monats, §28p schreibt die Sozialversicherungs-Prüfung der Deutschen Rentenversicherung Bund alle vier Jahre vor, §28r die Auskunfts-Pflicht.

Der Agent verwaltet die Stammdaten von 95 gesetzlichen Krankenkassen - 10 regionalen AOKs, 8 Ersatz-Kassen wie Techniker, Barmer und DAK-Gesundheit sowie jeweils über 30 Innungs- und Betriebs-Krankenkassen - samt GKV-Spitzenverband. Der allgemeine KV-Beitragssatz beträgt 14,6 Prozent paritätisch, dazu kommen der kassenindividuelle Zusatz-Beitrag, 3,4 Prozent Pflege-Versicherung und ab 23 Jahren ein Kinderlosen-Zuschlag von 0,6 Prozent. Für geringfügige Beschäftigung bis zur 538-Euro-Grenze meldet der Agent an die minijob-Zentrale der Knappschaft-Bahn-See mit Pauschal-Sätzen von 13 Prozent Kranken-, 15 Prozent Rentenversicherung und 2 Prozent Pauschal-Steuer; darüber liegt der Übergangs-Bereich bis 2.000 Euro.

Die jährliche UV-Meldung an die Berufs-Genossenschaft nach SGB VII §153 berechnet den Beitrag aus Lohnsumme mal Gefahr-Klasse, mit Stichtag 31.12. und Bescheid zum 30.4. Der Agent aggregiert dafür die Lohn-Summe pro Mitarbeiter und Gefahr-Klasse. Zuständig sind die neun gewerblichen Berufs-Genossenschaften (BGW, BGN, BGHM, BG BAU, BG ETEM, BG RCI, BG Verkehr, BG HW und BG ETF) sowie die Unfall-Versicherungs-Träger der öffentlichen Hand, koordiniert von der DGUV.

Seit Januar 2025 setzt die Deutsche Rentenversicherung Bund das KI-System KIRA (Künstliche Intelligenz für Risikoorientierte Arbeitgeberprüfung) ein. KIRA analysiert die digitalen Prüfunterlagen vor der Vor-Ort-Prüfung nach §28p SGB IV. Der Agent stellt dafür eine GoBD-konforme digitale Prüfakte mit vollständigem Audit-Trail bereit. Schwerpunkte der Prüfung sind DEÜV-Meldungen, ELStAM-Synchronisation, Lohn-Konten, Mindestlohn-Compliance und Scheinselbständigkeit. Die DRV nennt selbst jährliche Nachforderungen im hohen dreistelligen Millionenbereich. Auch die Erstattungsverfahren via sv.net laufen mit - U1 bei Krankheit (40 bis 80 Prozent je nach Wahltarif), U2 bei Mutterschutz (100 Prozent) und die U3-Insolvenzgeld-Umlage.

## Datenschutz und Mitbestimmung: DSGVO Art. 88 und BetrVG §87 Abs. 1 Nr. 6

[DSGVO Art. 88](https://eur-lex.europa.eu/eli/reg/2016/679/oj) verlangt für die Verarbeitung von Beschäftigtendaten eine ausdrückliche Rechtsgrundlage - bei Steuer und SV ist das die rechtliche Verpflichtung nach Art. 6 Abs. 1 lit. c. Art. 9 schützt besonders sensible Lohn-Daten wie Gesundheitsangaben, die Religionszugehörigkeit für die Kirchensteuer oder einen Pfändungs-Beschluss. BDSG §26 regelt die Verarbeitung im Beschäftigungs-Kontext, und bei Verstößen drohen Bußgelder bis 4 Prozent des Konzernumsatzes oder 20 Millionen Euro.

BetrVG §87 Abs. 1 Nr. 6 verlangt Mitbestimmung bei Einführung und Anwendung technischer Einrichtungen, die Verhalten oder Leistung überwachen können. Steuer-IT mit Personal-Daten fällt ausdrücklich darunter, weil sich aus Lohnsteuer-Klassen, Freibeträgen und Pauschalierungen Rückschlüsse auf Mitarbeiter ziehen lassen. Hinzu kommen das Auskunfts-Recht zu Personal-Statistiken nach §80 und die Mitbestimmung bei Sozialeinrichtungen und Lohngestaltungs-Grundsätzen; bei konzernübergreifender Software ist der Konzern-Betriebsrat zu beteiligen.

Der Agent erzeugt diesen Audit-Trail als Nebenprodukt: Jede Meldung trägt die verwendete Quelldaten-Version - von der fertigen Lohnabrechnung mit Zeitstempel über die Versionen von Lohnsteuer-Tabelle, Beitragssätzen und Krankenkassen-Stammdaten bis zu Nutzer, Vorher- und Nachher-Wert. Nicht weil eine Compliance-Anforderung das verlangt, sondern weil regelbasierte Melde-Systeme so funktionieren: Die Nachvollziehbarkeit entsteht durch die Architektur, nicht durch nachträgliche Dokumentation. Korrektur-Läufe nach einer Außenprüfung werden protokolliert, begründet und zwingend im Vier-Augen-Prinzip mit Steuerberater-Stichprobe freigegeben.

## Eingebettet in die Payroll-Pipeline: Processing, Accounting, Reporting

Der Tax-Social-Insurance-Agent ist eingebettet in eine Pipeline aus spezialisierten HR-Agenten. Der [Payroll-Processing-Agent](/de/hr-agent-katalog/payroll-processing-agent/) berechnet die Brutto-Netto-Abrechnung als Quelle für alle Steuer- und SV-Meldungen - der Tax-Agent baut auf diesem fertigen Output auf, nicht auf den Eingabe-Daten. Der [Payroll-Accounting-Agent](/de/hr-agent-katalog/payroll-accounting-agent/) verarbeitet dieselbe Lohnabrechnung parallel zu FiBu-Buchungen, während der Tax-Agent sie zu ELSTER- und sv.net-Meldungen macht. Der [Payroll-Reporting-Agent](/de/hr-agent-katalog/payroll-reporting-agent/) nutzt die deterministischen Steuer-Daten als Basis für jährliche Bescheinigungen, Personalkosten-Dashboards und das CSRD-Reporting nach ESRS S1. Ergänzend liefern der [Compensation-Benchmarking-Agent](/de/hr-agent-katalog/compensation-benchmarking-agent/) Vergütungsbänder zur Validierung der Lohnsteuer-Klassen, der [Time-Tracking-Agent](/de/hr-agent-katalog/time-tracking-agent/) die Beitragstage für die DEÜV-Meldungen, der [Travel-Expense-Agent](/de/hr-agent-katalog/travel-expense-agent/) steuerfreie Reisekosten nach EStG §3 Nr. 13 und 16 und der [Pensions-Calculation-Agent](/de/hr-agent-katalog/pensions-calculation-agent/) die betriebliche Altersversorgung mit Lohnsteuer-Pauschalierung nach §40b EStG.

## Auf einen Blick

- **Klassifikation**: Compliance-Support, kein EU-AI-Act-Hochrisiko (regelbasiert)
- **Compliance-Anker**: Lohnsteuerrecht des EStG (§38-§42f), DEÜV und ELStAM-Verfahren, SGB IV (§28a-§28r), GoBD und Aufbewahrung nach AO §147 und HGB §257, dazu DSGVO Art. 88, BDSG §26 und BetrVG §87 Abs. 1 Nr. 6
- **Melde-Fristen**: Lohnsteuer-Anmeldung zum 10. des Folgemonats, Jahres-Bescheinigung bis 28.2., DEÜV-Jahres-Meldung bis 15.2., GKV-Monatsmeldung zum drittletzten Bankarbeitstag, UV-Jahres-Meldung zum 31.12.
- **Krankenkassen**: 95 gesetzliche Kassen (10 AOKs, 8 Ersatz-Kassen, je über 30 IKK und BKK) samt GKV-Spitzenverband, dazu Knappschaft-Bahn-See mit minijob-Zentrale
- **Beitragssätze**: 14,6 Prozent KV samt Zusatz-Beitrag, 3,4 Prozent PV samt Kinderlosen-Zuschlag, 18,6 Prozent RV, 2,6 Prozent ALV; UV trägt der Arbeitgeber allein nach Gefahr-Klasse
- **DSGVO-Anforderung**: Rechtsgrundlage nach Art. 6 Abs. 1 lit. c, Schutz sensibler Daten nach Art. 9, Beschäftigungs-Kontext nach BDSG §26
- **Mitbestimmung**: BetrVG §87 Abs. 1 Nr. 6 zwingend bei Steuer-IT mit Personal-Daten, dazu Auskunfts-Recht nach §80
- **Sanktionen**: Arbeitgeber-Haftung nach §42d EStG, Außenprüfung nach §42f, SV-Beanstandung nach §28p SGB IV, Strafbarkeit bis fünf Jahre nach §266a StGB und DSGVO-Bußgelder bis 4 Prozent des Konzernumsatzes
- **Cross-Reference**: Payroll-Processing (Brutto-Netto als Quelle), Payroll-Accounting (FiBu-Buchungen parallel), Payroll-Reporting (Reports und Dashboards), dazu Time-Tracking und Travel-Expense

### Entscheider-Verteilung Tax-Social-Insurance-Agent

| Schritt | Decider | Begründung |
|---------|---------|------------|
| Quelldaten-Synchronisation aus Lohnabrechnung und ELStAM | R | Synchronisation aus Payroll-Processing, HRIS und ELStAM-Abruf deterministisch |
| ELStAM-Abruf §39e EStG monatlich | R | Lohnsteuer-Klasse, Freibetrag und Faktor-Verfahren deterministisch |
| EStG §41a Lohnsteuer-Anmeldung via ELSTER | R | ELSTER-Übermittlung zum 10. des Folgemonats deterministisch |
| EStG §42 jährliche Lohnsteuer-Bescheinigung | R | ELSTER-Übermittlung bis 28.2. des Folgejahres deterministisch |
| DEÜV-Datenbaustein DBME via sv.net | R | An-, Ab-, Jahres- und Unterbrechungs-Meldungen deterministisch |
| GKV-Monatsmeldung an 95 Krankenkassen | R | Beitrags-Nachweis zum drittletzten Bankarbeitstag deterministisch |
| Knappschaft-Bahn-See und minijob-Zentrale | R | Pauschal-Beitragssätze an der 538-Euro-Grenze deterministisch |
| UV-Jahres-Meldung an BG | R | SGB VII §153 Lohnsumme mal Gefahr-Klasse deterministisch |
| Erstattungsverfahren U1/U2/U3 | R | Erstattungs-Antrag deterministisch via sv.net |
| Fristen-Überwachung und Eskalation | R | Kalender-Engine mit Schwellwert 7 Tage deterministisch |
| Anomalie-Detection ML-Trend | A | ML-Anomalie-Detection mit menschlicher Validierung |
| Lohnbuchhalter-Freigabe im Vier-Augen-Prinzip | H | Steuerberater-Stichprobe und Plausibilitäts-Bestätigung zwingend |
| Anrufungs-Auskunft §42e und Härtefall | H | Lohnsteuer-Zweifelsfälle und Krankenkassen-Härtefall menschlich |
| BetrVG §87 Abs. 1 Nr. 6 Audit-Trail | R | Betriebsrats-Akteneinsicht mit DSGVO-Art.-88-Anonymisierung deterministisch |
| HinSchG-Whistleblower | H | Steuer-Hinterziehung und §266a StGB menschlich zwingend |

--- Zeiterfassungs-Agent ---
> Pflicht-Zeiterfassung nach EuGH C-55/18 CCOO und BAG 1 ABR 22/21: ArbZG §3-§6 Arbeitszeit-Schutz mit Tarif-Zuschlägen Sonn-/Feiertag/Nacht - BetrVG §87 Abs. 1 Nr. 2/3/6 Mitbestimmung.

## Zeiterfassung in 5 Sekunden statt Excel-Stundenzettel

Dieser Agent folgt dem [Decision Layer](/de/decision-layer/)-Prinzip: Jede Entscheidung ist entweder regelbasiert, ein KI-Indikator oder explizit einem Menschen zugeordnet. Nach [EU AI Act](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) ist er kein Hochrisiko-System, weil er keine Leistung bewertet. Seine Anforderungen kommen aus dem Arbeitsrecht - vom [EuGH-Urteil C-55/18](https://curia.europa.eu/juris/document/document.jsf?docid=214043) und dem [BAG-Beschluss 1 ABR 22/21](https://www.bundesarbeitsgericht.de/) über das [Arbeitszeitgesetz](https://www.gesetze-im-internet.de/arbzg/) und die Tarif-Zuschläge bis zum Beschäftigtendatenschutz und der Mitbestimmung des Betriebsrats.

Eine typische Zeiterfassung durchläuft mehrere Schritte: die objektive Erfassung von Beginn, Ende und Dauer, die Prüfung der Höchstarbeitszeit, der Ruhepausen und der Ruhezeit nach ArbZG, die Nachtarbeits-Einordnung, die Tarif-Zuschlags-Berechnung, die Schicht-Konflikt-Erkennung und die Klassifikation von Bereitschaftsdienst.

Das Problem liegt nicht im Volumen, sondern in der prüfbaren Kette dahinter: eine objektive, belastbare Erfassung, die korrekte Tarif-Zuschlags-Berechnung, die Mitbestimmung des Betriebsrats an der Zeiterfassungs-IT, der Schutz der Beschäftigtendaten und die langfristige Aufbewahrung der Belege.

Vor diesem Hintergrund ist eine Excel-Tabelle oder eine handschriftliche Stundenliste keine zulässige Erfassung mehr. Das BAG hat in 1 ABR 22/21 ausdrücklich klargestellt, dass Vertrauens-Arbeitszeit ohne System-Erfassung nicht mit ArbSchG §3 Abs. 2 Nr. 1 vereinbar ist. Der Arbeitgeber trägt die Beweislast für die Einhaltung der Höchstarbeitszeit nach §3 ArbZG sowie für die ununterbrochene Ruhezeit nach §5 ArbZG. Ohne System-Erfassung gehen Streitigkeiten über Mehrarbeit nach BAG 5 AZR 280/19 zu Lasten des Arbeitgebers.

## Zeiterfassung als Pflicht: das EuGH-Urteil C-55/18 und der BAG-Beschluss 1 ABR 22/21

Das [EuGH-Urteil C-55/18](https://curia.europa.eu/juris/document/document.jsf?docid=214043) (Federación de Servicios de Comisiones Obreras gegen Deutsche Bank, 14. Mai 2019) verpflichtet die Mitgliedstaaten, ein objektives, verlässliches und zugängliches Zeiterfassungs-System einzuführen - hergeleitet aus der Arbeitszeit- und der Arbeitsschutz-Richtlinie und der Grundrechte-Charta.

Der [BAG-Beschluss 1 ABR 22/21](https://www.bundesarbeitsgericht.de/) vom 13. September 2022 leitet daraus eine Pflicht des Arbeitgebers ab, Beginn, Ende und Dauer der täglichen Arbeitszeit jedes Mitarbeitenden objektiv zu erfassen. Bei Streitigkeiten über die Arbeitszeit liegt die Beweislast beim Arbeitgeber.

Auch Vertrauensarbeitszeit erfordert nach dem BAG eine objektive Erfassung - Vertrauen ersetzt die Pflicht nicht. Der Referenten-Entwurf des BMAS zur ArbZG-Reform sieht eine elektronische, tägliche Erfassung mit zweijähriger Speicherung vor.

Der Agent erfasst über Terminal, RFID, Biometrie oder Web und App mit Audit-Trail. Bereitschaftsdienst stuft er nach der [EuGH-Rechtsprechung (Matzak](https://curia.europa.eu/juris/document/document.jsf?docid=199517), Simap, Jaeger) als Arbeitszeit ein, sobald räumliche Bindung und eine unverzügliche Reaktionspflicht bestehen. Stand-by zu Hause ohne räumliche Bindung gilt dagegen als Ruhezeit - die Einordnung ist anhand von Reaktionsfrist und Ortsbindung regelbasiert möglich.

Die konkrete Ausgestaltung der Pflicht-Erfassung durch das BMAS-Referenten-Entwurf-Verfahren (Hütterott-Vorschlag) zur ArbZG-Reform 2024-2026 sieht elektronische Erfassung mit täglicher Speicherung und mindestens zweijähriger Aufbewahrung vor. Der Agent erfüllt diese kommende Pflicht bereits mit GoBD-konformer 6-Jahres-Aufbewahrung und Audit-Trail-Engine.

## Arbeitszeit-Schutz nach ArbZG: Höchstarbeitszeit, Pausen, Ruhezeit, Nachtarbeit

[ArbZG §3](https://www.gesetze-im-internet.de/arbzg/__3.html) begrenzt die Arbeitszeit auf acht Stunden werktäglich, verlängerbar auf zehn Stunden bei einem Ausgleich über sechs Monate. §4 schreibt Ruhepausen vor (30 Minuten ab sechs, 45 Minuten ab neun Stunden), §5 eine ununterbrochene Ruhezeit von elf Stunden zwischen Schichtende und Schichtbeginn. §6 schützt Nachtarbeitnehmer - ab mindestens 48 Nachtarbeitstagen im Jahr - und gibt ihnen einen Anspruch auf arbeitsmedizinische Untersuchung.

Hinzu kommen die Sonn- und Feiertagsruhe nach §9 mit ihren Ausnahmen, die Aushangpflicht nach §16 und die Bußgeldvorschrift des §22 mit bis zu 30.000 Euro.

Besondere Schutzgruppen haben eigene Grenzen: Das Mutterschutzgesetz verbietet unter anderem Mehr-, Nacht- sowie Sonn- und Feiertagsarbeit, das Jugendarbeitsschutzgesetz begrenzt die tägliche Arbeitszeit auf acht Stunden und schreibt eine Nachtruhe vor.

Der Agent erkennt Schicht-Plan-Konflikte - eine verletzte Elf-Stunden-Ruhezeit, eine überschrittene Höchstarbeitszeit oder eine unzulässige Doppelschicht - deterministisch und eskaliert sie an den Schichtleiter.

Die Schicht-Plan-Engine prüft täglich die Maximal-Stunden, wöchentlich die 48-Stunden-Höchst-Wochenarbeitszeit nach Richtlinie 2003/88 sowie über 6 Monate die durchschnittliche tägliche Höchstarbeitszeit. Eine Schicht-Verlängerung über 8 Stunden hinaus ist nur mit gleichzeitiger Eintragung im Ausgleichs-Konto zulässig - der Agent verhindert eine Verlängerung, wenn das 6-Monats-Ausgleichs-Konto bereits ausgeschöpft ist. Im Mehrschicht-Betrieb mit Wechselschicht prüft er die Tarifvertrags-spezifischen Wechselschicht-Pausen sowie die Schicht-Folge-Regeln (Frühschicht-Spätschicht-Nachtschicht-Pause).

Bei Sonn- und Feiertags-Arbeit nach ArbZG §9 prüft der Agent das Beschäftigungs-Verbot mit Ausnahmen nach §10 (Notdienste, Bewachungs-Gewerbe, Energie-Versorgung, Gastgewerbe, Verkehr), die behördliche Genehmigung nach §13 Abs. 3 sowie den Ausgleich nach §11. Sonntags-Arbeit ist nur mit Ersatz-Ruhetag innerhalb von 2 Wochen zulässig.

## Tarif-Zuschläge für Sonn-, Feiertags-, Nacht- und Mehrarbeit

Die Tarif-Zuschläge werden deterministisch berechnet: Sonntagsarbeit mit 50 bis 100 Prozent, gesetzliche Feiertage mit 100 bis 200 Prozent, Nachtarbeit zwischen 23 und 6 Uhr mit 25 bis 40 Prozent und Mehrarbeit über acht Stunden mit 25 bis 50 Prozent, dazu Wechselschicht- und Schmutz-Zulagen.

Die konkreten Sätze stammen aus dem jeweiligen Tarifvertrag - etwa dem ERA-Abkommen der IG-Metall, dem Chemie-Tarif der IG-BCE oder dem TVöD von ver.di. Den rechtlichen Rahmen setzt das Tarifvertragsgesetz mit Tarifgebundenheit und Allgemeinverbindlich-Erklärung.

Für Feiertage gilt zusätzlich die volle Entgeltfortzahlung nach EntgFG §2. Konkurrieren mehrere Tarifverträge, wechselt der Status der Allgemeinverbindlichkeit oder läuft eine neue Tarifrunde, geht der Fall zur menschlichen Validierung an die Lohnbuchhaltung.

In bestimmten Branchen - Bau, Gastgewerbe, Personenbeförderung, Speditionen, Gebäudereinigung oder Schlachten - greift die Aufzeichnungspflicht nach MiLoG §17, kontrolliert von der Finanzkontrolle Schwarzarbeit des Zolls. Verstöße können mit bis zu 500.000 Euro geahndet werden.

## Datenschutz und Mitbestimmung

Zeiterfassungsdaten sind Beschäftigtendaten nach [DSGVO Art. 88](https://eur-lex.europa.eu/eli/reg/2016/679/oj) und BDSG §26. Für sie gelten Datensparsamkeit, Privacy by Design, Verschlüsselung und - wegen der systematischen Überwachung - die Pflicht zur Datenschutz-Folgenabschätzung nach Art. 35.

Der Agent setzt das durch Datensparsamkeit um: Erfasst werden nur Beginn, Ende, Pausen und Schicht-Status, keine Bewegungsprofile. Der Zugriff bleibt auf Lohnbuchhaltung, HR-Operations und Schichtleiter beschränkt, mit Steuerberatern bestehen Auftragsverarbeitungsverträge. Verstöße können mit bis zu 4 Prozent des Konzernumsatzes geahndet werden.

Die Mitbestimmung des Betriebsrats greift mehrfach: bei Beginn und Ende der täglichen Arbeitszeit einschließlich Pausen (BetrVG §87 Abs. 1 Nr. 2), bei der vorübergehenden Verkürzung oder Verlängerung (Nr. 3) und bei der technischen Überwachungseinrichtung, die die Zeiterfassungs-IT darstellt (Nr. 6).

Bei konzernübergreifender Software ist der Konzernbetriebsrat zu beteiligen, bei Nichteinigung entscheidet die Einigungsstelle. Eine automatisierte Leistungsbewertung oder eine Beendigung der Vertrauensarbeitszeit ohne menschliche Validierung findet nicht statt.

## Einbettung in Payroll und Sick-Leave-Processing

Der Zeiterfassungs-Agent ist in eine Pipeline spezialisierter HR-Agenten eingebettet. Der [Payroll-Calculation-Agent](/de/hr-agent-katalog/payroll-calculation-agent/) übernimmt die erfassten Stunden, Tarif-Zuschläge und Mehrarbeit als Basis für den Brutto-Lohn, der [Payroll-Processing-Agent](/de/hr-agent-katalog/payroll-processing-agent/) die Brutto-Netto-Berechnung. Der [Payroll-Reporting-Agent](/de/hr-agent-katalog/payroll-reporting-agent/) erstellt die Meldungen und die GoBD-konformen Belege. Der [Sick-Leave-Processing-Agent](/de/hr-agent-katalog/sick-leave-processing-agent/) nimmt die Krankheitstage als Abwesenheit auf, der [Leave-of-Absence-Agent](/de/hr-agent-katalog/leave-of-absence-agent/) die übrigen Abwesenheiten wie Urlaub und Elternzeit. Der [HR-Document-Management-Agent](/de/hr-agent-katalog/hr-document-management-agent/) archiviert die Belege fristgerecht, der [Audit-Compliance-Agent](/de/hr-agent-katalog/audit-compliance-agent/) prüft die Einhaltung von GoBD sowie der EuGH- und BAG-Vorgaben.

## Auf einen Blick

- **Was er tut**: erfasst Arbeitszeit objektiv und berechnet sie regelbasiert - Beginn, Ende, Dauer, ArbZG-Grenzen, Tarif-Zuschläge, Schicht-Konflikte
- **Klassifikation**: kein EU-AI-Act-Hochrisiko-System (regelbasierte Verarbeitung, keine Leistungsbewertung)
- **Compliance-Anker**: Erfassungspflicht aus EuGH C-55/18 und BAG 1 ABR 22/21, Arbeitszeit-Schutz nach ArbZG §3 bis §6, Tarif-Zuschläge, Beschäftigtendaten nach DSGVO Art. 88
- **Aufbewahrung**: sechs Jahre für Zeiterfassungs-Belege, zehn Jahre für Lohnkonten, zwei Jahre nach MiLoG §17
- **Mitbestimmung**: BetrVG §87 Abs. 1 Nr. 2, 3 und 6 zwingend, Konzernbetriebsrat bei konzernweiter Software
- **Menschliche Entscheidung**: Tarif-Sonderfälle und Schicht-Konflikte werden zur Validierung eskaliert
- **Prüfungsfall**: objektive Erfassung als Beweismittel, jede Stichprobe einer Lohnsteuer- oder Sozialversicherungsprüfung belegbar

### Entscheider-Verteilung Time-Attendance

| Schritt | Decider | Begründung |
|---------|---------|------------|
| Zeit-Erfassung Beginn/Ende/Dauer | R | EuGH C-55/18 CCOO + BAG 1 ABR 22/21 objektiv verlässlich zugänglich |
| ArbZG §3 Höchstarbeitszeit 8/10h | R | 6-Monats-Ausgleichs-Konto deterministisch |
| ArbZG §4 Pausen + §5 Ruhezeit 11h | R | Pausen-/Ruhezeit-Engine deterministisch |
| ArbZG §6 Nachtarbeit + §16 Aushang | R | Nachtarbeitnehmer-Status deterministisch |
| Tarifvertrags-Zuschläge | R | IG-Metall + IG-BCE + ver.di-TV deterministisch |
| Schicht-Plan-Konflikte | R | 11h-Ruhezeit + Doppel-Schicht-Verbot deterministisch |
| MuSchG/JArbSchG-Sonderregelung | R | Schwangerschaft + Jugendlicher-Status deterministisch |
| Bereitschaftsdienst Matzak | R | EuGH C-518/15 + Simap + Jaeger deterministisch |
| Anomalie-Detection | A | ML-Anomalie mit menschlicher Validierung |
| BetrVG §87 Audit-Trail | R | Mitbestimmungs-Recht deterministisch |
| DSGVO Art. 88 + BDSG §26 | R | Datenminimierung + Verschlüsselung deterministisch |
| MiLoG §17 Aufzeichnung | R | Branchen-Identifikation + Zoll-FKS deterministisch |
| Tarifvertrags-Sonderfall | H | Konkurrierende TV + neue Tarifrunde menschlich |
| GoBD 6/10-Jahres-Aufbewahrung | R | HGB §257 + AO §147 + MiLoG §17 deterministisch |

--- Trainings-Bedarfs-Analyse-Agent ---
> Skills-Gap-Analyse betriebsratsfest: der Bedarf wird transparent vorgerechnet, die KI liefert nur Indikatoren, der Mensch entscheidet - DSGVO- und AGG-fest.

## Jedes Skills-Tool meldet einen Weiterbildungsbedarf. Keines beweist, dass ihn kein Algorithmus an einzelnen Menschen festgemacht hat.

Cornerstone, SuccessFactors, Workday, Eightfold - aus Skills-Profilen wird per Knopfdruck eine Trainingsempfehlung: "Diese Person braucht dieses Training." Das ist seit Jahren Standard. Die Frage, an der eine Bedarfs-Analyse in Deutschland wirklich hängt, beantwortet keines dieser Systeme: Hat hier ein Mensch oder eine KI entschieden, wer ins Training kommt - und können Sie dem Betriebsrat zeigen, dass der Bedarf diskriminierungsfrei und ohne Rückschluss auf Einzelne zustande kam?

Dieser Agent folgt dem [Decision Layer](/de/decision-layer/)-Prinzip: Jede Bedarfs-Entscheidung ist entweder regelbasiert, ein KI-Indikator oder eine menschliche Freigabe - klar getrennt und für den Betriebsrat sichtbar. Nach EU AI Act ist er kein Hochrisiko-System, weil er keine einzelnen Menschen bewertet. Seine Anforderungen kommen aus dem Datenschutz- und Mitbestimmungsrecht, und die sind hart genug.

## Der rechtliche Sprengsatz steckt nicht in der Empfehlung, sondern in der Entscheidung

Marktübliche Skills-Tools verkaufen eine Black-Box-Empfehlung: Die KI sagt Ihnen, wer welches Training braucht. Genau das ist hierzulande der eigentliche Konfliktpunkt. Eine KI, die selbst entscheidet, wer einem Training zugewiesen wird, wäre nach Artikel 22 DSGVO eine unzulässige rein automatisierte Einzelentscheidung mit erheblicher Wirkung. Der Bußgeld-Rahmen reicht bis 20 Mio. Euro oder 4 Prozent des weltweiten Jahresumsatzes, je nachdem welcher Betrag höher ist ([Artikel 83 Abs. 5 DSGVO](https://dsgvo-gesetz.de/art-83-dsgvo/)).

Dazu kommt die Mitbestimmung, und hier wird oft das falsche Recht zitiert. Die Bedarfs-Ermittlung selbst ist nach Paragraph 96 BetrVG ein Beratungsrecht: Der Arbeitgeber muss den Berufsbildungsbedarf auf Verlangen ermitteln und mit dem Betriebsrat beraten; kommt keine Einigung zustande, vermittelt nur die Einigungsstelle. Der scharfe Hebel sitzt woanders - in Paragraph 97 Abs. 2 BetrVG: Sobald eine Maßnahme die Tätigkeit ändert und die vorhandenen Kenntnisse nicht mehr ausreichen, bestimmt der Betriebsrat bei der Einführung der Bildungs-Maßnahme mit, und hier entscheidet die Einigungsstelle verbindlich. Wer diesen Unterschied kennt, weiß: Eine Bedarfs-Analyse muss teilbar und nachvollziehbar sein, sonst eskaliert das Verfahren genau dort, wo die alleinige Steuerung verloren geht.

Und schließlich ist die Software selbst mitbestimmungspflichtig. Eine Skills-Cloud, die Leistung oder Verhalten auswerten kann, ist nach Paragraph 87 Abs. 1 Nr. 6 BetrVG eine Überwachungseinrichtung - ohne Betriebsvereinbarung ist ihre Einführung unzulässig, und Auswertungen sind im Streitfall nicht verwertbar. Genau hier entsteht die Situation, die viele kennen: Der Betriebsrat blockiert aus Unsicherheit, die Rechtsabteilung sagt "Nein" statt "Ja, wenn". Eine Lösung, die der Betriebsrat unterschreibt, bevor sie dem Vorstand präsentiert wird, muss diese drei Hebel von Beginn an mitdenken.

## Drei Quellen, klar getrennt: wer über den Bedarf entscheidet

Die meisten Anbieter sagen, ein Mensch bleibe "im Prozess", und kleben ein Compliance-Siegel daneben. Beides bleibt eine schwarze Box. Der Agent macht stattdessen für jede Bedarfs-Entscheidung sichtbar, aus welcher von drei Quellen sie stammt:

| Quelle | Was sie entscheidet | Beispiel aus der Bedarfs-Analyse |
|--------|---------------------|----------------------------------|
| **Regelwerk (R)** | Alles Deterministische, kein Ermessen | Skills-Gap als Soll-Niveau minus Ist-Niveau, DQR-Einstufung, Aggregation ab Mindest-Gruppengröße |
| **KI-Indikator (A)** | Markiert Hinweise, entscheidet nie | Skills-Inferenz aus Aktivitätsdaten, Auffälligkeit zwischen Leistung und Lücke |
| **Mensch (H)** | Freigabe und Strategie | Vier-Augen-Freigabe des Reports, Wahl der Maßnahme aus dem Geschäftskontext |

Der Agent ist also überwiegend ein deterministischer Rechen-Motor, mit KI nur als Indikator an den Rändern und einem festen menschlichen Freigabe-Gate. Das ist die ehrliche Antwort auf den naheliegenden Einwand "darf eine KI überhaupt entscheiden, wer ins Training muss?" - und die Antwort lautet: Sie darf es nicht, und sie tut es hier auch nicht. Wer freigibt, sieht jeden KI-gelieferten Indikator als solchen markiert, mit Konfidenz und Quelle, bevor er ihn übernimmt. Wie diese Schicht architektonisch durchgreift, zeigt der [Decision Layer](/de/decision-layer/).

## Der Skills-Gap ist eine Subtraktion, kein Orakel

Ein Bedarfs-Vorschlag, der aus einem KI-Modell ohne nachvollziehbare Herleitung kommt, ist für eine Mitbestimmungs-Frage wertlos: Er ist nicht reproduzierbar, und es ist nicht dokumentiert, welche Daten ihn erzeugt haben. Das Mitbestimmungsrecht verlangt das Gegenteil - eine Bedarfs-Analyse, die der Betriebsrat mitlesen und nachprüfen kann.

Deshalb entsteht der Skills-Gap beim Agenten als nachrechenbare Differenz. Das Soll-Niveau einer Stelle und das Ist-Niveau einer Person werden auf der achtstufigen DQR- und EQR-Skala gemessen - Niveau 1 bis 2 für Anlerntätigkeiten, 3 bis 4 für die Erstausbildung, 5 bis 6 für Fortbildung und Bachelor, 7 bis 8 für Master und Promotion. Die Lücke ist schlicht Soll minus Ist, eine Zahl, die jeder Prüfer nachvollziehen kann. Die KI liefert dazu nur Indikatoren: Sie schlägt aus Aktivitätsdaten vor, welche Fähigkeit jemand haben könnte, und markiert Auffälligkeiten zwischen Leistung und Lücke - aber der Mensch validiert jeden dieser Hinweise, bevor er Teil des Bedarfs wird.

Der Hebel dahinter: Werden Bedarfe nur aggregiert ab einer festen Mindest-Gruppengröße ausgewiesen, ist kein Rückschluss auf eine einzelne Person möglich. Das ist keine Kosmetik, sondern die Bedingung dafür, dass die Verarbeitung nach Paragraph 26 BDSG erforderlich und nach Artikel 88 DSGVO im Beschäftigungskontext zulässig bleibt. Und weil die Auswahl regelbasiert gegen die geschützten Merkmale des AGG geprüft wird, lässt sich im Streitfall belegen, dass kein Bedarf an Geschlecht, Alter, Herkunft oder Behinderung hing - entscheidend, weil bei Indizien für eine Benachteiligung nach Paragraph 22 AGG der Arbeitgeber die Beweislast trägt. Dokumentierte, regelbasierte Kriterien sind die Grundlage, das zu widerlegen.

## Über Viva und SuccessFactors, nicht statt ihnen

Der Agent konkurriert nicht mit Ihrer Skills-Plattform. Gegen Workday, SuccessFactors oder Eightfold auf der Daten-Achse anzutreten wäre aussichtslos - dort entscheidet Reichweite und Integration. Der Agent legt sich als Entscheidungs- und Nachweis-Schicht darüber: Sie behalten Ihre Plattform, und er macht den Bedarf betriebsratsfest.

Skills-Indikatoren aus Microsoft Viva, Eightfold oder Degreed und Soll-Profile aus SuccessFactors oder Workday fließen unverändert ein. Was hinzukommt, ist nicht ein weiteres System, sondern die Antwort auf die Frage des Betriebsrats und der Rechtsabteilung: Für jeden Bedarf lässt sich sagen, ob ihn das Regelwerk, ein KI-Indikator oder ein Mensch verantwortet hat, und es ist nachvollziehbar belegt - ohne dass eine einzelne Person sichtbar wird. Genau das macht den Unterschied zwischen einer Empfehlung, die die Rechtsabteilung stoppt, und einem Bedarf, den der Betriebsrat gegenzeichnet.

## Warum sich Treffsicherheit beim Weiterbildungsbedarf rechnet

Der wirtschaftliche Einsatz ist real. Laut IW-Weiterbildungserhebung investierten deutsche Unternehmen 2022 im Schnitt 1.347 Euro pro Mitarbeiter und Jahr in Weiterbildung, bei 20,3 Stunden je Beschäftigtem, und 93 Prozent der befragten Unternehmen boten überhaupt Weiterbildung an ([IW-Weiterbildungserhebung 2023](https://www.iwkoeln.de/studien/susanne-seyda-sabine-koehne-finster-thomas-schleiermacher-investitionsvolumen-auf-hoechststand.html)). Bei diesem Volumen entscheidet die Treffsicherheit des Bedarfs über spürbare Beträge - und die Belastbarkeit der Herleitung darüber, ob das Budget vor Betriebsrat und Datenschutz Bestand hat.

Der nächste Schritt ist keine Software-Einführung, sondern eine Bestandsaufnahme: Wo in Ihrem Bedarfs-Prozess entscheidet heute faktisch eine KI über einzelne Menschen, und wie teilbar ist die Herleitung dahinter für den Betriebsrat? Wie die saubere Trennung aus Regelwerk, KI-Indikator und menschlicher Freigabe architektonisch durchgreift, zeigt der [Decision Layer](/de/decision-layer/) im Detail.

## Auf einen Blick

- **Was er tut**: rechnet aus Soll- und Ist-Niveau einen aggregierten, nachvollziehbaren Trainingsbedarf vor und macht pro Schritt sichtbar, wer entscheidet
- **Klassifikation**: kein EU-AI-Act-Hochrisiko-System (Analyse ohne Bewertung einzelner Menschen)
- **Entscheidungslogik**: überwiegend Regelwerk, KI nur als Indikator, Freigabe beim Menschen im Vier-Augen-Prinzip
- **Compliance-Anker**: Mitbestimmung nach Paragraph 96 und Paragraph 97 Abs. 2 BetrVG, Skills-IT nach Paragraph 87 Abs. 1 Nr. 6 BetrVG, Aggregation nach Artikel 22 DSGVO und Paragraph 26 BDSG, diskriminierungsfreie Auswahl nach Paragraph 22 AGG
- **Integration**: Schicht über Viva, Eightfold, Degreed, SuccessFactors oder Workday - kein Ersatz
- **Betriebsrats-Fall**: jeder Bedarf bis zur aggregierten Datengrundlage zurückverfolgbar, ohne einzelne Personen offenzulegen

--- Versetzungs- und Umzugs-Agent ---
> Versetzungen und internationale Entsendungen: BetrVG §99 Mitbestimmung, AufenthG Blue Card/ICT-Karte und EU Regulation 883/2004 A1-Bescheinigung - mit DBA-Doppelbesteuerung und ATE.

## Versetzung und internationale Entsendung als HR-Compliance-Falle

Dieser Agent folgt dem [Decision Layer](/de/decision-layer/)-Prinzip: jede Entscheidung ist entweder regelbasiert, KI-assistiert oder explizit einem Menschen zugeordnet. Nach [EU AI Act 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) ist er kein Hochrisiko-System, weil er keine Menschen bewertet. Seine Anforderungen kommen aus dem Arbeits-, Aufenthalts-, Steuer- und Datenschutzrecht - von der Mitbestimmung nach BetrVG §99 über die Posting-Workers-Richtlinie und die Doppelbesteuerungs-Abkommen bis zur GoBD.

Eine Versetzung oder Entsendung durchläuft pro Mitarbeiter mehrere Verifikations-Schritte: den Mitbestimmungs-Workflow nach BetrVG §99 mit seiner Einwochenfrist, eine diskriminierungsfeste Auswahl, die Visa-Verifikation samt Blue Card und ICT-Karte, bei innereuropäischen Einsätzen die Posting-Workers-Anmeldung und die A1-Bescheinigung, die steuerliche Statusberechnung nach Doppelbesteuerungs-Abkommen sowie die Erstellung des Mobility-Pakets und die signierte Vertragsanpassung.

Das Problem liegt nicht im Volumen. Es liegt in der auditierbaren Kette: Verfahrensdokumentation, Beteiligung des Konzern-Betriebsrats, ein belastbarer Audit-Trail für die Auswahlentscheidung, der Nachweis gültiger Aufenthaltstitel sowie die Anträge bei Rentenversicherung und Ausländerbehörden. Genau diese Kette stellt der Agent durchgängig her.

## Betriebsübergang nach BGB §613a und Mitbestimmung nach BetrVG §99

Ein [Betriebsübergang nach BGB §613a](https://www.gesetze-im-internet.de/bgb/__613a.html) verpflichtet den Arbeitgeber, die betroffenen Mitarbeiter zu informieren, und räumt diesen ein Widerspruchsrecht mit Monatsfrist ein. Davon zu unterscheiden ist die personelle Einzelmaßnahme: [BetrVG §99](https://www.gesetze-im-internet.de/betrvg/__99.html) verlangt die zwingende Mitbestimmung des Betriebsrats bei Einstellung, Versetzung, Ein- und Umgruppierung. Als Versetzung gilt nach §95 Abs. 3 BetrVG ein Wechsel des Arbeitsbereichs über mehr als einen Monat oder mit erheblicher Änderung der Umstände.

Der Betriebsrat hat eine Woche Zeit, seine Zustimmung aus den Gründen des §99 Abs. 2 zu verweigern; bei Nichteinigung folgt das Beschluss-Verfahren vor dem Arbeitsgericht. Bei konzernübergreifenden Versetzungen ist zusätzlich der Konzern-Betriebsrat zu beteiligen. Wird der Mitarbeiter an einen anderen Arbeitgeber überlassen, greift das Arbeitnehmerüberlassungsgesetz mit Erlaubnis-Pflicht und Equal-Pay nach neun Monaten - mit Ausnahme des Konzern-Privilegs nach §1 Abs. 3 Nr. 2.

## Aufenthaltsrecht, Blue Card und ICT-Karte: die Visa-Verifikation

Das [Aufenthaltsgesetz](https://www.gesetze-im-internet.de/aufenthg_2004/) verlangt für jede Beschäftigung von Drittstaatsangehörigen einen Aufenthaltstitel zur Erwerbstätigkeit und in der Regel die Zustimmung der Bundesagentur für Arbeit. Für Hochqualifizierte greift die Blue Card EU nach §18b (mit Gehalts-Schwellenwert), für konzerninterne Entsendungen die ICT-Karte nach §19. Das [Asylgesetz](https://www.gesetze-im-internet.de/asylg_2008/) ergänzt die Regeln für Schutzsuchende.

Vor der Beschäftigung sind die Zentrale Auslands- und Fachvermittlung (ZAV) zu konsultieren und der Aufenthaltstitel über das Bundesamt für Migration und Flüchtlinge sowie die zuständige Ausländerbehörde zu prüfen. Der Einsatz ist erheblich: Eine Beschäftigung ohne gültigen Titel ist nach AsylG §95 mit Freiheits- oder Geldstrafe bedroht, gewerbsmäßige Beihilfe nach §96 mit bis zu drei Jahren Freiheitsstrafe.

## Doppelbesteuerung und Sozialversicherung: die A1-Bescheinigung

Steuerlich entscheidet bei einer Auslandstätigkeit das jeweilige Doppelbesteuerungs-Abkommen, welcher Staat das Gehalt besteuern darf. Maßgeblich sind die 183-Tage-Regel und der steuerliche Wohnsitz nach EStG §1; die Steuerbefreiung für Reisekosten-Vergütungen regelt §3 Nr. 16, und der Auslandstätigkeitserlass des BMF konkretisiert Sonderfälle. Deutschland hat mit den meisten Staaten ein solches Abkommen nach dem OECD-Musterabkommen geschlossen.

Sozialrechtlich hält die A1-Bescheinigung nach EU-Verordnung 883/2004 fest, dass der Mitarbeiter während der Entsendung im deutschen System bleibt - beantragt bei der Auslandsabteilung der Deutschen Rentenversicherung, befristet auf 24 Monate. Bei innereuropäischen Einsätzen kommt die Posting-Workers-Richtlinie 96/71 hinzu: Anmeldung im EU-Binnenmarkt-Informationssystem sowie die Auskunfts- und Aufzeichnungspflichten nach dem Arbeitnehmer-Entsendegesetz.

## Datenschutz nach DSGVO Art. 88 und Diskriminierungsschutz nach AGG §22

Versetzungs- und Entsendungsdaten sind Beschäftigtendaten und unterliegen [DSGVO Art. 88](https://eur-lex.europa.eu/eli/reg/2016/679/oj) und BDSG §26. Geht die Übermittlung in einen Drittstaat, braucht es einen Angemessenheits-Beschluss oder Standardvertragsklauseln mit den nach Schrems II nötigen Zusatzmaßnahmen. Verstöße ahndet Art. 83 mit bis zu 4 Prozent des Konzernumsatzes.

Bei der Auswahl greift das AGG: Es schützt vor Benachteiligung wegen acht Merkmalen, und nach §22 kehrt sich bei Indizien für eine Benachteiligung die Beweislast um. Eine nicht zu rechtfertigende Versetzung kann nach §15 eine Entschädigung von bis zu drei Bruttomonatsgehältern auslösen; deshalb ist die dokumentierte Begründung der Auswahl entscheidend.

Die Rechtsprechung von BAG und EuGH steckt die Grenzen ab - vom Direktionsrecht bei Versetzungen über Long-Term-Verträge bis zur Vergütung entsandter Arbeitnehmer.

## Zusammenspiel mit Onboarding-Workflow, Payroll-Processing und HR-Document-Management

Der Versetzungs- und Umzugs-Agent ist eingebettet in eine Pipeline aus spezialisierten HR-Agenten: Der [Onboarding-Workflow-Agent](/de/hr-agent-katalog/onboarding-workflow-agent/) übernimmt den Mitarbeiter nach erfolgter Versetzung. Der [Payroll-Processing-Agent](/de/hr-agent-katalog/payroll-processing-agent/) nimmt die Lohn-Anpassung mit Auslands- und Hardship-Zulage sowie Steuerausgleichung entgegen, der [Payroll-Reporting-Agent](/de/hr-agent-katalog/payroll-reporting-agent/) erstellt die Lohnsteuer-Anmeldungen nach Doppelbesteuerungs-Abkommen. Der [Tax-Social-Insurance-Agent](/de/hr-agent-katalog/tax-social-insurance-agent/) erzeugt die Sozialversicherungs-Meldungen samt A1-Bescheinigung, der [Contract-Offer-Generation-Agent](/de/hr-agent-katalog/contract-offer-generation-agent/) den signierten Versetzungs-Vertrag. Der [HR-Document-Management-Agent](/de/hr-agent-katalog/hr-document-management-agent/) archiviert die Belege revisionssicher, und der [Audit-Compliance-Agent](/de/hr-agent-katalog/audit-compliance-agent/) prüft die GoBD-Konformität.

## Auf einen Blick

- **Klassifikation**: Compliance-Support, kein EU-AI-Act-Hochrisiko (administrative Koordination, keine Bewertung von Menschen)
- **Compliance-Anker**: Mitbestimmung nach BetrVG §99, Aufenthaltsrecht mit Blue Card und ICT-Karte, Posting-Workers-Richtlinie 96/71, A1-Bescheinigung nach EU 883/2004, Doppelbesteuerungs-Abkommen, Datenschutz nach DSGVO Art. 88 und AGG §22
- **Aufbewahrung**: sechs Jahre für Versetzungs-Belege, zehn Jahre für Lohnkonten (HGB §257, AO §147)
- **Mitbestimmung**: BetrVG §99 zwingend, bei konzernübergreifender Versetzung auch der Konzern-Betriebsrat
- **Sanktionen**: Unterlassungs-Anspruch und Beschluss-Verfahren bei Mitbestimmungs-Verstoß, bis zu drei Bruttomonatsgehälter nach AGG §15, bis zu 4 Prozent Konzernumsatz nach DSGVO, Strafbarkeit nach AsylG §95
- **Entscheidungslogik**: überwiegend regelbasiert, KI nur als Indikator, menschliche Entscheidung bei der Mobility-Paket-Verhandlung

### Entscheider-Verteilung Versetzungs- und Umzugs-Agent

| Schritt | Decider | Begründung |
|---------|---------|------------|
| Versetzungs-/Entsendungs-Antrag erfassen | R | Strukturierte Erfassung nach festen Regeln |
| BetrVG §99 Mitbestimmungs-Workflow | R | Einwochenfrist und Konzern-Betriebsrat deterministisch |
| AGG-konforme Auswahl-Prüfung | R | Acht geschützte Merkmale, Audit-Trail deterministisch |
| Visa-Verifikation nach Aufenthaltsrecht | R | Blue Card, ICT-Karte und ZAV-Konsultation deterministisch |
| Posting-Workers-Richtlinie 96/71 | R | Anmeldung im EU-Binnenmarkt-System deterministisch |
| A1-Bescheinigung nach EU 883/2004 | R | Antrag bei der Rentenversicherung deterministisch |
| Doppelbesteuerung und Auslandstätigkeit | R | 183-Tage-Regel und Wohnsitz deterministisch |
| Mobility-Paket erstellen | R | Allowance- und Cost-of-Living-Tabellen deterministisch |
| Mobility-Paket verhandeln | H | Individuelle Familien-Umstände zwingend menschlich |
| Vertragsanpassung mit eIDAS-Signatur | R | Generierung und Signatur deterministisch |
| Lohn-Anpassung übergeben | R | Zulagen und Steuerausgleichung deterministisch |
| Drittstaaten-Datenübermittlung | R | Schrems II und Angemessenheits-Beschluss deterministisch |
| GoBD-Aufbewahrung 6/10 Jahre | R | HGB §257, AO §147 und Lifecycle deterministisch |
| Anomalie-Detection | A | Statistischer Indikator mit menschlicher Validierung |

--- HR-Reise-Antrag-Agent ---
> HR-Reise-Genehmigungs-Workflow vor der Reise: Reise-Antrag mit Vorgesetzten-Freigabe, BetrVG §87 Abs. 1 Nr. 6 Mitbestimmung der Reiserichtlinie und Pflichtfelder-Validierung.

## Reisekosten-Abrechnung in Sekunden statt Wochen Postlaufzeit

Dieser Agent folgt dem [Decision Layer](/de/decision-layer/)-Prinzip: jede Entscheidung ist entweder regelbasiert, KI-assistiert oder explizit einem Menschen zugeordnet. Nach [EU AI Act 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) ist er kein Hochrisiko-System, weil er keine Menschen bewertet. Seine Anforderungen kommen aus dem Steuer- und Handelsrecht - von der Steuerbefreiung der Reisekosten nach [EStG §3](https://www.gesetze-im-internet.de/estg/__3.html) über die Pauschbeträge der Lohnsteuer-Richtlinien und des BMF-Schreibens bis zur GoBD-Aufbewahrung nach AO §147.

Eine Reisekosten-Sachbearbeitung in einem Konzern mit 1.000 Reisenden verarbeitet pro Monat Tausende Belege aus Hotels, Restaurants, Bahnen, Mietwagen, Tankstellen und Bewirtungen. Die manuelle Prüfung mit Postversand dauert zwei bis vier Wochen und ist fehleranfällig. Der Agent erzeugt die Abrechnung dagegen in Sekunden - aus dem Beleg-Foto der Mobile-App, der OCR-Erfassung, der Pauschbetrags-Berechnung, der 70-Prozent-Regel für Bewirtung, der Kilometer-Pauschale und dem Vorsteuer-Abzug.

Das Problem liegt nicht im Volumen. Es liegt in der auditierbaren Kette: den Pauschbeträgen für Inland und Ausland mit ihrer Mahlzeiten-Kürzung, der Pflichtfeld-Prüfung der Bewirtungs-Belege, dem Vier-Augen-Prinzip aus Vorgesetztem und Lohnbuchhalter, dem Audit-Trail mit Vorher-/Nachher-Werten, der zehnjährigen Aufbewahrung der Buchungsbelege und dem Z3-Zugriff für die Betriebsprüfung. Genau diese Kette stellt der Agent durchgängig her.

Dazu kommen die ERP-Schnittstellen: SAP Concur als Markt-Führer im Konzern-Segment, Workday Expenses und Oracle Cloud HCM Expenses für Multi-Country-Rollouts, Personio Expenses für Mittelstand DACH, DATEV Reisekosten für Steuerberater-getriebene Buchhaltung, Coupa Expense Management und Chrome River für globale Spend-Management-Initiativen, Cloud-First-Lösungen wie Expensify, Brex, Ramp, Zoho Expense, Rydoo, Tipalti und Bill.com für agile Mittelständler. Travel-Management-Companies wie Egencia, American Express GBT, Carlson Wagonlit Travel und BCD Travel liefern Sammelrechnungs-Daten direkt in die Reisekosten-Pipeline. Der Agent muss alle diese Schnittstellen GoBD-konform und DSGVO Art. 88-konform handhaben - mit Auftrags-Verarbeitungs-Verträgen AVV pro Anbieter, EU-Data-Boundary-Garantien wo möglich und Audit-Trail-Vereinheitlichung über alle Quellsysteme hinweg.

## Steuerbefreiung und Pauschbeträge nach EStG §3 und LStR R 9.4 bis R 9.10

[EStG §3 Nr. 16](https://www.gesetze-im-internet.de/estg/__3.html) befreit Reisekosten-Vergütungen von Arbeitnehmern von Lohnsteuer und Sozialversicherung, soweit sie die Pauschbeträge oder die tatsächlichen Kosten nicht überschreiten. Nr. 13 befreit Vergütungen aus öffentlichen Kassen, Nr. 50 die Sammelbeförderung und Nr. 51 die Pauschbeträge für Verpflegungs-Mehraufwendungen.

Die Lohnsteuer-Richtlinien R 9.4 bis R 9.10 konkretisieren die Anwendung:

- **R 9.4** allgemeine Grundsätze und der Begriff der Auswärtstätigkeit
- **R 9.5** Fahrtkosten: 0,30 Euro je Kilometer mit dem Pkw, 0,20 Euro mit dem Motorrad, 0,15 Euro mit dem Fahrrad, dazu 0,02 Euro Mitfahrer-Zuschlag pro Person
- **R 9.6** Verpflegungs-Pauschbeträge im Inland: 14 Euro am An- und Abreisetag, 28 Euro am vollen Tag, ab acht Stunden Abwesenheit, gekürzt um gestellte Mahlzeiten
- **R 9.7** Übernachtungskosten tatsächlich oder pauschal mit 20 Euro im Inland, Hotel-Rechnung gekürzt um 4,80 Euro Frühstück
- **R 9.8** Reise-Nebenkosten wie Telefon, Garage, Parkgebühren und Maut
- **R 9.9** doppelte Haushaltsführung
- **R 9.10** Trennungsentschädigung

Ein Verstoß gegen das EStG zieht eine Lohnsteuer-Nachforderung mit Säumniszuschlägen von einem Prozent pro Monat nach sich, macht die Reisekosten zum Schwerpunkt einer Lohnsteuer-Außenprüfung nach §42f EStG und lässt den Arbeitgeber nach §42d für nicht abgeführte Lohnsteuer haften. Bei prüfungspflichtigen Gesellschaften kommt ein Mängelbericht des Wirtschaftsprüfers hinzu.

Praktisch ist der häufigste Fehler der Sachbezugs-Wert. Wenn der Arbeitgeber bei einer Dienstreise Frühstück übernimmt (Hotel-Frühstück inklusive), muss die Verpflegungs-Pauschale um 5,60 EUR gekürzt werden. Wird die Mahlzeit nicht gekürzt, fließt der Betrag als Sachbezug in den lohnsteuer-pflichtigen Brutto-Lohn nach SvEV (Sachbezugs-Werte-Verordnung) - Frühstück 60 EUR, Mittagessen 120 EUR, Abendessen 120 EUR ab 2026. Pauschalierung nach EStG §40 mit 25 Prozent ist möglich, aber nur in Ausnahmefällen wirtschaftlich. Der Agent berechnet diese Kürzungen automatisch aus der Hotel-Rechnungs-Struktur und der Reise-Konfiguration. Bei mehrtägigen Auslandsreisen mit unterschiedlichen Ländern wird pro Übernachtung der Pauschbetrag des Quellortes angewendet, was bei Geschäftsreisen mit Tagesübergängen über mehrere Länder zu komplexen Berechnungen führt.

## BMF-Reisekosten-Schreiben und Bewirtungskosten nach §4 Abs. 5 Nr. 2

Das [BMF-Schreiben Reisekosten 25.11.2020 IV C 5](https://www.bundesfinanzministerium.de/) (mit Aktualisierung BMF 21.11.2024) konkretisiert die Pauschbeträge für Inland und Ausland länderspezifisch für rund 200 Länder. Ein voller Reise-Tag wird mit 28 Euro angesetzt, der An- und Abreisetag mit 14 Euro, jeweils ab acht Stunden Abwesenheit. Eine gestellte Mahlzeit kürzt die Pauschale: das Frühstück um 5,60 Euro, Mittag- und Abendessen um je 11,20 Euro.

[Bewirtungskosten nach EStG §4 Abs. 5 Nr. 2](https://www.gesetze-im-internet.de/estg/__4.html) sind bei Geschäftsfreunden nur zu 70 Prozent abzugsfähig. Der Bewirtungs-Beleg muss Anlass, Teilnehmer mit Name und Funktion, Datum, Ort sowie die Höhe inklusive Trinkgeld ausweisen, dazu den Restaurant-Stempel oder eine maschinell erstellte Rechnung. Der Agent prüft jedes dieser Pflichtfelder per OCR und fragt bei unvollständigen Belegen beim Sachbearbeiter nach, statt sie automatisch abzulehnen.

Geschenke nach §4 Abs. 5 Nr. 1 sind bis 35 EUR pro Empfänger abzugsfähig. Werbe-Geschenke Nr. 1a sind nicht limitiert. Verpflegung im eigenen Betrieb Nr. 1b ist abzugsfähig. Repräsentationsaufwendungen Nr. 4 sind grundsätzlich nicht abzugsfähig. Vorsteuer-Abzug UStG §15 ist bei Bewirtungs-Belegen zu 100 Prozent möglich (Sonderfall ohne 70-Prozent-Kürzung).

Die Anomalie-Detection des Agenten prüft Bewirtungs-Belege gegen unternehmensspezifische Muster: Häufigkeit pro Mitarbeitendem, Pro-Kopf-Betrag, Wochenend-Bewirtungen, runde Beträge (Hinweis auf manipulierte Belege), Trinkgeld-Anteile über 15 Prozent, Restaurant-Wiederholungen und Teilnehmer-Konstanz. Treffer werden als Indikator an Lohnbuchhalter und Steuerberater eskaliert - ohne automatische Ablehnung. Cross-Reference IDW PS 261 Audit Sampling: Wirtschaftsprüfer ziehen jährlich Stichproben aus Bewirtungs-Belegen für Risiko-orientierte Prüfung. Der Agent dokumentiert die geprüften Anomalien GoBD-konform im Audit-Trail mit Nutzer, Zeitstempel und Entscheidung.

## GoBD und Aufbewahrung über sechs und zehn Jahre nach AO §147

Das [GoBD-Schreiben BMF 28.11.2019](https://www.bundesfinanzministerium.de/) (mit Aktualisierung BMF 11.07.2022) verlangt für Reisekosten-Belege Unveränderbarkeit, zeitgerechte Erfassung, Vollständigkeit, Nachvollziehbarkeit und das Vier-Augen-Prinzip. AO §147 schreibt zehn Jahre für die Buchungsbelege der Reisekosten-Erstattungen vor und sechs Jahre für die Geschäftsbriefe der Reise-Anträge; HGB §257 verlangt analog zehn Jahre für Buchungsbelege.

Der Agent erzeugt automatisch einen Audit-Trail aus Nutzer, Zeitstempel, Aktion und Vorher-/Nachher-Werten, ergänzt um ein Bild-Hashing der Belege als Schutz gegen Doppel-Erfassung. Beleg-Foto und OCR-Daten werden unveränderlich archiviert, und der Z3-Zugriff für die Betriebs- und Lohnsteuer-Außenprüfung ist vorbereitet.

Die Aufbewahrungs-Engine differenziert: Original-Beleg-Foto (Hotel-Rechnung, Restaurant-Bewirtungs-Beleg, Tankquittung) plus die generierte FiBu-Buchung gelten als Buchungsbeleg im Sinne von HGB §257 Nr. 4 - somit 10 Jahre. Die Reise-Antrags-Korrespondenz (E-Mail mit Vorgesetztem zur Genehmigung) gilt als Geschäftsbrief HGB §257 Nr. 2 - somit 6 Jahre. Die Lifecycle-Management-Engine setzt Lösch-Sperren bei laufenden Steuer-Verfahren, Lohnsteuer-Außenprüfungen, Sozialversicherungs-Prüfungen oder HinSchG-Hinweisgeber-Meldungen. Nach Ablauf der Aufbewahrungs-Frist erfolgt DSGVO Art. 17-konforme Löschung mit Audit-Trail-Eintrag - automatisch, ohne manuelle Freigabe. Cross-Reference Steuerberater-Verträge mit DATEV-Schnittstelle: bei Mandanten-Wechsel müssen die Belege ebenfalls 10 Jahre verfügbar bleiben, was kontraktuell beim alten Steuerberater oder beim Mandanten selbst liegt.

## Datenschutz nach DSGVO Art. 88 und Mitbestimmung nach BetrVG §87 Abs. 1 Nr. 6

Reisekosten-Daten sind personenbezogen: Reise-Ziele, Übernachtungs-Orte, Bewirtungs-Teilnehmer, Tankkarten-Daten und das Geo-Tracking der Mobile-App. Sie fallen als Beschäftigtendaten unter DSGVO Art. 88 und BDSG §26; bei Krankenrücktransport-Belegen greift zusätzlich der besondere Schutz nach Art. 9.

Der Agent setzt das nach den Grundsätzen Privacy by Design und Datensparsamkeit um: Verschlüsselung der Daten, eine Datenschutz-Folgenabschätzung beim Geo-Tracking, Auftragsverarbeitungs-Verträge mit den eingesetzten Reisekosten-Plattformen und ein automatisches Lösch-Konzept nach Ablauf der Aufbewahrungs-Frist.

Die Mitbestimmung nach [BetrVG §87 Abs. 1 Nr. 6](https://www.gesetze-im-internet.de/betrvg/__87.html) greift, weil ein Reisekosten-System mit Audit-Trail, Geo-Tracking und Tankkarten-Daten der technischen Überwachung dient; über die Pauschalen kommt Nr. 10 zur Lohngestaltung hinzu. Bei konzernübergreifender Software ist der Konzern-Betriebsrat zuständig. Vor der Einführung wird eine Betriebsvereinbarung über Umfang des Audit-Trails, Verzicht oder Opt-in beim Geo-Tracking, Berechtigungs-Konzept und Daten-Lebenszyklus geschlossen.

## Zusammenspiel mit Payroll-Accounting und HR-Document-Management

Der Reisekosten-Agent ist eingebettet in eine Pipeline aus spezialisierten HR-Agenten: Der [Payroll-Accounting-Agent](/de/hr-agent-katalog/payroll-accounting-agent/) verbucht die lohnsteuer-pflichtigen Reisekosten-Anteile, also die Sachbezugswerte gestellter Mahlzeiten und deren Pauschalierung nach EStG §40. Der [HR-Document-Management-Agent](/de/hr-agent-katalog/hr-document-management-agent/) archiviert die Belege revisionssicher über zehn Jahre, und der [Payroll-Tax-Agent](/de/hr-agent-katalog/payroll-tax-agent/) prüft die Lohnsteuer-Compliance der Pauschalierungen. Der [Compensation-Benchmarking-Agent](/de/hr-agent-katalog/compensation-benchmarking-agent/) nutzt die Reisekosten-Daten für den Total-Compensation-Vergleich, der [Audit-Compliance-Agent](/de/hr-agent-katalog/audit-compliance-agent/) prüft die GoBD-Konformität der Belege, und der [Payroll-Calculation-Agent](/de/hr-agent-katalog/payroll-calculation-agent/) verarbeitet die Brutto-Netto-Berechnung mit den pauschalierten Anteilen.

## Auf einen Blick

- **Klassifikation**: Compliance-Support, kein EU-AI-Act-Hochrisiko (Finanzprozess, keine Bewertung von Menschen)
- **Compliance-Anker**: Steuerbefreiung der Reisekosten nach EStG §3, Pauschbeträge nach LStR R 9.4 bis R 9.10 und BMF-Reisekosten-Schreiben, Bewirtungskosten nach §4 Abs. 5 Nr. 2, GoBD, Aufbewahrung nach AO §147 und HGB §257, Datenschutz nach DSGVO Art. 88 und Mitbestimmung nach BetrVG §87 Abs. 1 Nr. 6
- **Pauschbeträge Inland**: 14 Euro am An- und Abreisetag, 28 Euro am vollen Tag, Mahlzeiten-Kürzung um 5,60 bzw. 11,20 Euro, Übernachtungs-Pauschbetrag 20 Euro
- **Pauschbeträge Ausland**: länderspezifisch für rund 200 Länder nach BMF-Reisekosten-Schreiben
- **Bewirtungskosten**: zu 70 Prozent abzugsfähig nach §4 Abs. 5 Nr. 2, Vorsteuer dennoch zu 100 Prozent
- **Aufbewahrung**: zehn Jahre für Buchungsbelege, sechs Jahre für Geschäftsbriefe (HGB §257, AO §147)
- **Entscheidungslogik**: überwiegend regelbasiert, OCR und Anomalie-Detection nur als Indikator, Freigabe im Vier-Augen-Prinzip
- **Sanktionen**: Lohnsteuer-Nachforderung mit Säumniszuschlägen, Außenprüfung nach §42f EStG, bei prüfungspflichtigen Gesellschaften Mängelbericht des Wirtschaftsprüfers

### Entscheider-Verteilung Travel-Expense

| Schritt | Decider | Begründung |
|---------|---------|------------|
| Reise-Antrags-Erfassung | R | Prüfung gegen Reisekostenrichtlinie und Genehmigungshierarchie |
| Beleg-OCR und Bewirtungs-Validierung | A | OCR als Vorschlag, menschliche Validierung |
| Pauschbetrags-Berechnung Inland | R | feste Tabelle nach LStR R 9.6 |
| Pauschbetrags-Berechnung Ausland | R | länderspezifische Pauschbeträge nach BMF-Schreiben |
| Übernachtungs-Kosten | R | tatsächliche Kosten oder Pauschbetrag nach LStR R 9.7 |
| Kilometer-Pauschale | R | feste Sätze nach LStR R 9.5 |
| Vorsteuer-Abzug | R | feste Regeln nach UStG §15 |
| Vorgesetzten-Freigabe | H | Vier-Augen-Prinzip für GoBD-Audit-Trail zwingend |
| Anomalie-Detection | A | statistischer Indikator mit menschlicher Validierung |
| Lohnsteuer-Behandlung | R | Pauschalierung nach EStG §40 und Sachbezugswerte |
| FiBu-Buchungs-Übergabe | R | Kontenrahmen-Mapping deterministisch |
| GoBD-Beleg-Archivierung | R | unveränderbare Archivierung mit Audit-Trail |
| BetrVG-Audit-Trail | R | Bereitstellung für den Betriebsrat |
| Aufbewahrung 6/10 Jahre | R | feste Fristen nach HGB §257 und AO §147 |

--- Lieferantenmanagement-Agent ---
> HR-Dienstleister-Verwaltung: LkSG-Sorgfaltspflicht mit BAFA-Bericht, DSGVO Art. 28 AVV mit Schrems-II-SCC und CSRD ESRS S2 Workers in Value Chain - mit BetrVG §87 Mitbestimmung.

## HR-Lieferantenmanagement im LkSG-Kontext

Dieser Agent folgt dem [Decision Layer](/de/decision-layer/)-Prinzip: jede Entscheidung ist entweder regelbasiert, KI-assistiert oder explizit einem Menschen zugeordnet. Nach [EU AI Act 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) ist er kein Hochrisiko-System, weil er keine Menschen bewertet. Seine Anforderungen kommen aus dem Lieferketten-, Datenschutz-, Vergabe- und ESG-Recht - vom Lieferkettengesetz über die Auftragsverarbeitungs-Verträge nach DSGVO Art. 28 bis zur CSRD-Berichterstattung und der GoBD.

Die Verwaltung eines HR-Dienstleisters durchläuft mehrere Verifikations-Schritte: Onboarding mit AVV-Generierung und Schrems-II-Prüfung, die LkSG-Risikoanalyse, eine diskriminierungsfeste Auswahl, bei Ausschreibungen die Vergaberechts-Prüfung, den Mitbestimmungs-Workflow, die Vertragsverhandlung, die Performance-Auswertung sowie den jährlichen BAFA-Bericht und die ESG-Berichterstattung.

Das Problem liegt nicht im Volumen. Es liegt in der auditierbaren Kette: Verfahrensdokumentation, AVV-Pflicht-Inhalte, Drittstaaten-Prüfung, ein belastbarer Audit-Trail für die Auswahl, die Vergaberechts-Schwellen, der BAFA-Bericht und die sechsjährige Aufbewahrung der Verträge. Genau diese Kette stellt der Agent durchgängig her.

## Lieferkettengesetz und BAFA-Berichtspflicht

Das [Lieferkettengesetz (LkSG)](https://www.gesetze-im-internet.de/lksg/) vom 16. Juli 2021 gilt seit 2023 für Unternehmen ab 3.000 Beschäftigten und seit 2024 ab 1.000 Beschäftigten. Es verpflichtet zu einer Risikoanalyse (§5), zu Präventions- und Abhilfemaßnahmen (§6, §7), zu einem Beschwerdeverfahren (§8) sowie zur Dokumentation und zum jährlichen Bericht an die BAFA bis zum 1. Juni (§10).

Die Sanktionen sind erheblich: Nach §24 drohen Bußgelder bis zu 8 Millionen Euro oder 2 Prozent des Konzernumsatzes, nach §22 eine Vergabe-Sperre von bis zu drei Jahren. Ab 2027 verschärft die EU-Lieferketten-Richtlinie CSDDD diese Pflichten, mit nationaler Umsetzung bis Mitte 2026.

Aufsichtsbehörde ist die BAFA (Bundesamt für Wirtschaft und Ausfuhrkontrolle); sie nimmt die Berichte entgegen und kann Prüfungs- und Mahnungsverfahren bis hin zur Vor-Ort-Prüfung einleiten.

## Auftragsverarbeitung nach DSGVO Art. 28 mit Schrems II

[DSGVO Art. 28](https://eur-lex.europa.eu/eli/reg/2016/679/oj) verlangt für jeden Dienstleister, der personenbezogene Daten verarbeitet, einen Auftragsverarbeitungs-Vertrag mit den Pflicht-Inhalten nach Abs. 3. Bei Beschäftigtendaten greifen zusätzlich Art. 88 und BDSG §26; für Drittstaaten kommen Standardvertragsklauseln hinzu.

Das Schrems-II-Urteil des EuGH (C-311/18 vom 16. Juli 2020) verlangt bei Drittstaaten ohne Angemessenheits-Beschluss zusätzliche Maßnahmen wie Verschlüsselung, Pseudonymisierung und ergänzende technische und organisatorische Maßnahmen. Verstöße ahndet Art. 83 mit bis zu 4 Prozent des Konzernumsatzes.

Für welche Staaten ein Angemessenheits-Beschluss der EU-Kommission vorliegt - etwa die Schweiz, das Vereinigte Königreich, Japan oder Kanada -, prüft der Agent gegen die jeweils gültige Liste; die EDPB-Leitlinien zur grenzüberschreitenden Datenübermittlung sind dabei maßgeblich.

## Vergaberecht bei HR-Ausschreibungen

Bei öffentlichen Aufträgen oder konzerninternen Ausschreibungen greift das Vergaberecht aus Vergabeverordnung (VgV) und GWB, ergänzt um das Gesetz gegen den unlauteren Wettbewerb und die EU-Vergaberichtlinien. Maßgeblich sind die EU-Schwellenwerte - rund 215.000 Euro für Liefer- und Dienstleistungen, rund 5,4 Millionen Euro für Bauaufträge.

Über die Einhaltung wachen die Vergabekammern von Bund und Ländern, die Vergabesenate der Oberlandesgerichte und das Bundeskartellamt.

Bei der Auswahl von HR-Dienstleistern - besonders Recruiting-Plattformen und Background-Check-Anbietern - greift zudem das AGG: Nach §22 kehrt sich bei Indizien für eine Benachteiligung die Beweislast um. Die US-Sammelklage Mobley gegen Workday (2023) zeigt, dass KI-Bias in HR-Software dabei zum Präzedenzfall werden kann.

## Zusammenspiel mit Payroll-Processing, Compensation-Benchmarking und HR-Document-Management

Der Lieferantenmanagement-Agent ist eingebettet in eine Pipeline aus spezialisierten HR-Agenten: Der [Payroll-Processing-Agent](/de/hr-agent-katalog/payroll-processing-agent/) erhält die Payroll-Vendor-Konfiguration, der [Compensation-Benchmarking-Agent](/de/hr-agent-katalog/compensation-benchmarking-agent/) die Daten der Vergütungs-Dienstleister wie Mercer und Korn Ferry. Der [Pre-Hire-Due-Diligence-Agent](/de/hr-agent-katalog/pre-hire-due-diligence-agent/) bezieht die Daten der Background-Check-Anbieter, der [HR-Document-Management-Agent](/de/hr-agent-katalog/hr-document-management-agent/) archiviert die Vendor-Verträge revisionssicher über sechs Jahre. Der [Audit-Compliance-Agent](/de/hr-agent-katalog/audit-compliance-agent/) prüft die GoBD-, LkSG- und DSGVO-Konformität, der [Travel-Expense-Agent](/de/hr-agent-katalog/travel-expense-agent/) erhält die Daten der Reise-Dienstleister, und der [Sick-Leave-Processing-Agent](/de/hr-agent-katalog/sick-leave-processing-agent/) die der Krankenkassen.

## Auf einen Blick

- **Klassifikation**: Compliance-Support, kein EU-AI-Act-Hochrisiko (Beschaffungsverwaltung, keine Bewertung von Menschen)
- **Compliance-Anker**: Lieferkettengesetz ab 1.000 Beschäftigten, Auftragsverarbeitung nach DSGVO Art. 28 mit Schrems II, Vergaberecht, ESG-Berichterstattung nach CSRD (ESRS S2), AGG §22 und Mitbestimmung nach BetrVG §87 Abs. 1 Nr. 6; ab 2027 zusätzlich die EU-Richtlinie CSDDD
- **Aufbewahrung**: sechs Jahre für Vendor-Verträge, zehn Jahre für Lohnkonten (HGB §257, AO §147)
- **Mitbestimmung**: BetrVG §87 Abs. 1 Nr. 6 zwingend für das Vendor-Management-System
- **Sanktionen**: bis zu 8 Millionen Euro oder 2 Prozent Konzernumsatz und drei Jahre Vergabe-Sperre nach LkSG, bis zu 4 Prozent Konzernumsatz nach DSGVO, bis zu drei Bruttomonatsgehälter nach AGG §15
- **Entscheidungslogik**: überwiegend regelbasiert, KI nur als Indikator, menschliche Entscheidung bei Vendor-Verhandlung und Aufsichtsrats-Bericht

### Entscheider-Verteilung Lieferantenmanagement-Agent

| Schritt | Decider | Begründung |
|---------|---------|------------|
| Vendor-Onboarding mit AVV | R | Pflicht-Inhalte nach DSGVO Art. 28 und Schrems II |
| LkSG-Risikoanalyse | R | feste Risiko-Klassifikations-Matrix |
| AGG-konforme Vendor-Auswahl | R | acht geschützte Merkmale, Audit-Trail |
| Vergaberechts-Prüfung | R | EU-Schwellenwerte und Vergabeverfahren |
| Vendor-Vertrags-Verhandlung | H | Preise, Vertragsstrafen und SLAs zwingend menschlich |
| BetrVG §87 Mitbestimmung | R | Beteiligung an der System-Einführung |
| Vendor-Performance-KPI | A | statistischer Indikator mit menschlicher Validierung |
| BAFA-Berichts-Generierung | R | feste Pflicht-Inhalte und 1.-Juni-Frist nach LkSG §10 |
| ESG-Berichterstattung nach CSRD | R | EFRAG-Vorgaben, prüfungspflichtig ab 250 MA |
| Beschwerdeverfahren LkSG §8 | R | Hinweisgeber-Schutz nach HinSchG |
| Vendor-Vertrags-Lifecycle | R | feste Verlängerungs- und Kündigungsfristen |
| Vendor-Wechsel BGB §613a | R | Information und einmonatige Widerspruchsfrist |
| GoBD-Aufbewahrung 6/10 Jahre | R | feste Fristen nach HGB §257 und AO §147 |
| Aufsichtsrats-Bericht AktG §107 | H | Vorstand-Haftung zwingend menschlich |

--- Workforce-Planning-Agent ---
> Personalplanung mit prüfbarer Entscheidungskette: Sozialauswahl als Rechnung, BetrVG-Konsultation als Gate - über SAP und Workday, gerichtsfest.

## Jede Suite liefert eine Prognose. Keine eine prüfbare Entscheidung.

SAP SuccessFactors, Workday, Anaplan, Visier - sie alle prognostizieren Headcount-Bedarfe und zeichnen Dashboards. Das ist seit Jahren Standard. Die Frage, an der ein Restrukturierungs-Plan vor dem Arbeitsgericht und am Verhandlungstisch mit dem Betriebsrat wirklich hängt, beantwortet keine dieser Suiten: Wer hat anhand welcher Regel entschieden, dass genau diese Stellen wegfallen - und hält das vor Gericht?

Dieser Agent folgt dem [Decision Layer](/de/decision-layer/)-Prinzip: Jeder Workforce-Schritt ist entweder regelbasiert, ein KI-Indikator oder eine menschliche Entscheidung - klar getrennt und als Decision-Record festgehalten. Im Default-Modus ist er nach [EU AI Act](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) kein Hochrisiko-System, weil er Mengen rechnet und keine Einzelpersonen bewertet. Seine Anforderungen kommen aus dem Arbeitsrecht, und die sind hart genug.

## Mitbestimmung ist ein hartes Gate, kein nachgelagerter Haken

Personalplanung ist nach BetrVG Paragraph 92 mitbestimmungspflichtig: Der Arbeitgeber muss den Betriebsrat rechtzeitig und umfassend unterrichten und mit ihm beraten. Das ist nicht verhandelbar - der Betriebsrat kann die Unterrichtung im Beschlussverfahren erzwingen, und bei einer verknüpften Betriebsänderung ohne Interessenausgleich droht Nachteilsausgleich. Das eigentliche operative Risiko ist also nicht ein abstraktes Bußgeld, sondern ein Plan, der am Veto des Betriebsrats hängenbleibt.

Der Agent macht die Konsultation deshalb zur Vorbedingung, nicht zum Protokoll-Anhang. Bei einer Headcount-Änderung oberhalb der vereinbarten Schwelle löst er automatisch den Konsultations-Workflow aus: Der Betriebsrat erhält die Plan-Daten, eine vereinbarte Frist läuft, und der Verlauf wird im Decision-Record festgehalten. Ohne dokumentierte Konsultation gibt der Agent die Plan-Freigabe nicht frei - die Mitbestimmung ist by design erfüllt, statt nachträglich behauptet ("wir haben den Betriebsrat informiert"). Bei einer Betriebsänderung nach BetrVG Paragraph 111 aktiviert er zusätzlich die Verhandlungs-Phase für Interessenausgleich und Sozialplan, die bei Nichteinigung in die Einigungsstelle nach BetrVG Paragraph 76 eskaliert.

## Sozialauswahl ist eine Rechnung, keine ML-Empfehlung

Die schärfste Einzelfolge der ganzen Disziplin steckt in KSchG Paragraph 1 Abs. 3: Eine betriebsbedingte Kündigung ist sozial ungerechtfertigt und damit unwirksam, wenn die Auswahl die Kriterien Betriebszugehörigkeit, Lebensalter, Unterhaltspflichten und Schwerbehinderung nicht erkennbar berücksichtigt. Eine Auswahl, die niemand erklären kann, hält im Kündigungsschutzprozess nicht - egal wie präzise das zugrunde liegende Forecasting war.

Der Agent rechnet die Sozialauswahl deshalb deterministisch nach einer vorab mit dem Betriebsrat abgestimmten Punkte-Tabelle und liefert eine sortierte, begründete Liste. Der entscheidende Unterschied: Er empfiehlt nicht, er rechnet. Eine ML-gestützte Sozialauswahl ist gerichtlich nicht haltbar, weil sie genau die Nachvollziehbarkeit verfehlt, die das Gesetz verlangt - eine dokumentierte Punkte-Rechnung ist es. Den gesetzlichen Sonderschutz Schwerbehinderter bildet die Tabelle als feste Mehrpunkte-Position ab. Die finale Auswahl trifft anschließend die Personalleitung gemeinsam mit dem Betriebsrat; der Agent liefert die nachvollziehbare Grundlage, nicht den Akt.

Bei größeren Vorhaben greift KSchG Paragraph 17 mit harten Schwellen, jeweils binnen 30 Kalendertagen: 6 Kündigungen bei 21 bis 59 Beschäftigten, 10 Prozent oder 26 bei 60 bis 499 und 30 ab 500 Beschäftigten ([Schwellenwerte nach Haufe](https://www.haufe.de/id/kommentar/thuesingrachorlembke-kschg-17-anzeigepflicht-4-schwellenwerte-fuer-massenentlassung-abs1-4-und-5-HI1752715.html)). Der Agent prüft diese Schwellen kontinuierlich, startet bei Erreichen die Betriebsrats-Konsultation und bereitet die Anzeige bei der Bundesagentur für Arbeit mit Konsultations-Nachweis vor. Die Reihenfolge - erst Konsultation und Anzeige, dann Kündigung - geht auf die EuGH-Junk-Entscheidung (C-188/03) zurück; ohne ordnungsgemäße Anzeige sind die ausgesprochenen Kündigungen nach ständiger BAG-Rechtsprechung unwirksam, vom EuGH zuletzt mit [Urteil vom 30.10.2025 (C-134/24)](https://www.hensche.de/eugh-fehler-bei-der-anzeige-einer-massenentlassung-fuehren-weiterhin-zur-unwirksamkeit-von-kuendigungen-eugh-urteil-vom-30.10.2025-c-134-24.html) bestätigt.

Dieselbe Auswahl ist zugleich diskriminierungs-anfällig: Trifft ein Plan überproportional ältere Beschäftigte, Frauen in der Familienphase oder Schwerbehinderte, kehrt sich nach AGG Paragraph 22 bei entsprechenden Indizien die Beweislast um, und das Unternehmen muss beweisen, dass die Auswahl nicht auf einem geschützten Merkmal beruht. Der Einsatz ist real: Die Antidiskriminierungsstelle des Bundes verzeichnete 2024 mit 11.405 Beratungsanfragen einen Rekord, rund ein Drittel davon aus dem Arbeitsleben ([Jahresbericht 2024](https://www.antidiskriminierungsstelle.de/SharedDocs/aktuelles/DE/2025/20250603_Jahresbericht.html)). Der Agent führt dazu optional einen statistischen disparate-impact-Audit nach der 80-Prozent-Regel durch und markiert auffällige Verteilungen - aber als KI-Indikator, der ein Prüf-Signal liefert, nicht als Entscheidung. Die Bewertung und jede Maßnahme bleibt beim Menschen. Die Entschädigung bei Nicht-Einstellung begrenzt AGG Paragraph 15 Abs. 2 Satz 2 dabei nur dann auf drei Monatsgehälter, wenn der Bewerber auch bei benachteiligungsfreier Auswahl nicht eingestellt worden wäre - wäre er ohne die Benachteiligung eingestellt worden, greift die Grenze nicht.

## Der Hochrisiko-Schalter ist eine bewusste Entscheidung

Im Default-Modus ist der Agent kein Hochrisiko-System nach EU AI Act. Operatives Forecasting und Capacity-Planning fallen nicht unter Anhang III Nr. 4 der VO 2024/1689, weil sie Mengen je Cost-Center rechnen und keine Einzelpersonen bewerten. Hochrisiko wird der Agent erst, wenn das optionale Modul für KI-Kündigungs-Empfehlungen aktiviert wird - dann greift Anhang III Nr. 4 mit Datenschutz-Folgenabschätzung, Risikomanagement und verpflichtender menschlicher Aufsicht. Verstöße gegen diese Hochrisiko-Pflichten kosten bis 15 Mio. Euro oder 3 Prozent des weltweiten Jahresumsatzes ([Art. 99 AI Act](https://artificialintelligenceact.eu/article/99/)); die Hochrisiko-Pflichten gelten nach aktuellem Recht ab dem 2. August 2026, voraussichtlich verschoben auf den 2. Dezember 2027 (Digital Omnibus, vorläufige Einigung Mai 2026, formale Verabschiedung ausstehend).

Diese Trennung ist der Gegenpol zur Vermarktung der Wettbewerber, bei der scheinbar alles zu KI wird. Wer transparent macht, ab wann er die Hochrisiko-Zone betritt, behält die Kontrolle über den Compliance-Aufwand. In der Praxis aktivieren die meisten Unternehmen das Modul bewusst nicht: Die menschliche Letztentscheidung ist nach DSGVO Art. 22 ohnehin zwingend, ein vollautomatisierter Kündigungs-Akt also rechtlich ausgeschlossen - das ML-Modell liefert damit bestenfalls eine zweite Meinung, deren Hochrisiko-Last den Nutzen meist übersteigt. Ein Verstoß gegen Art. 22 selbst wäre zudem mit Bußgeldern bis 20 Mio. Euro oder 4 Prozent des weltweiten Konzern-Jahresumsatzes bewehrt (Art. 83 Abs. 5 DSGVO).

## Eine Schicht über der Planung, nicht statt ihr

Der Agent konkurriert nicht mit Ihrer Workforce-Planning-Suite. Gegen SAP, Workday oder Anaplan auf der Forecasting-Achse anzutreten wäre aussichtslos - dort entscheiden Datentiefe und Integration. Der Agent legt sich als Entscheidungs- und Nachweis-Schicht darüber: Die Forecasting-Zahlen fließen weiter wie bisher, und er ergänzt die prüfbare Entscheidungskette.

Was hinzukommt, ist kein weiteres Planungs-System, sondern die Antwort auf die Frage am Verhandlungstisch und vor Gericht. Wenn der Betriebsrat den Restrukturierungs-Plan blockiert, weil die Sozialauswahl nicht plausibel ist, liefert der Agent binnen Stunden die regelbasierte Punkte-Tabelle mit Begründung und den dokumentierten Konsultations-Verlauf - statt einer Black-Box-Zahl, die niemand erklären kann. Im Kern geht es genau darum: eine Lösung, die der Betriebsrat mitträgt, bevor sie dem Vorstand präsentiert wird.

Der nächste Schritt ist keine Software-Einführung, sondern eine Prozess-Analyse: Wo in Ihrer Personalplanung fällt heute eine Auswahl-Entscheidung, ohne dass die Begründung prüfbar mitläuft - und wie betriebsrats-fest ist die Konsultation dahinter?

## Auf einen Blick

- **Was er tut**: zerlegt Personalplanung in einzelne Entscheidungen und hält für jede fest, wer sie auf welcher Rechtsgrundlage verantwortet
- **Klassifikation**: im Default-Modus kein EU-AI-Act-Hochrisiko-System (operatives Forecasting); Hochrisiko nur mit aktiviertem KI-Kündigungs-Modul (Anhang III Nr. 4)
- **Entscheidungslogik**: überwiegend Regelwerk, KI nur als Indikator an den Rändern, jede rechtswirkende Entscheidung beim Menschen
- **Compliance-Anker**: BetrVG Paragraph 92, KSchG Paragraph 1 Abs. 3 und Paragraph 17, DSGVO Art. 22, EU AI Act Anhang III Nr. 4, AGG Paragraph 22
- **Integration**: Schicht über SAP, Workday, Anaplan oder Visier - kein Ersatz
- **Streitfall**: Sozialauswahl als nachvollziehbare Rechnung und Konsultation als Decision-Record, gerichts- und betriebsrats-fest

--- Betriebsrats-Koordinations-Agent ---
> Betriebsrats-Beteiligung formal sauber: Klassifikation und Fristen per Regelwerk, Inhalt beim Menschen, jeder Schritt revisionssicher belegt.

## Bis zu 330.000 Kündigungsschutzklagen pro Jahr - viele zielen auf die Form

Eine Kündigung ohne ordnungsgemäße Betriebsrats-Anhörung ist unwirksam - kraft Gesetz, unabhängig davon, ob der Kündigungsgrund berechtigt war. Das steht so in [Paragraph 102 BetrVG](https://www.gesetze-im-internet.de/betrvg/__102.html), und das Bundesarbeitsgericht hält diese Linie konstant. Trotzdem kippen Kündigungen in der Praxis regelmäßig an genau diesem Punkt: nicht an fehlenden Gründen, sondern an fehlerhaften Verfahren. Bei den deutschen Arbeitsgerichten gehen jährlich zwischen 200.000 und 330.000 Kündigungsschutzklagen ein ([empirische Daten zum Kündigungsschutzprozess, Haufe](https://www.haufe.de/id/beitrag/3-allgemeiner-kuendigungsschutz-nach-dem-kschg-a-empirische-daten-zum-kuendigungsschutzprozess-HI16207073.html); Primärquelle [Statistisches Bundesamt, Arbeitsgerichte](https://www.destatis.de/DE/Themen/Staat/Justiz-Rechtspflege/Publikationen/Downloads-Gerichte/statistischer-bericht-arbeitsgerichte-2100280247005.html)). Viele dieser Klagen zielen erfahrungsgemäß auf formale Mängel der Beteiligung, weil diese den prozessual sichersten Angriffspunkt darstellen.

Das ist kein Wissensproblem. HR-Abteilungen kennen die Vorschriften. Es ist ein Koordinationsproblem: Die richtige Information lag vor, wurde aber nicht vollständig weitergegeben; die Frist war bekannt, wurde aber falsch berechnet; der Grund existierte, wurde aber nicht dokumentiert.

## Mehrere Beteiligungsverfahren laufen gleichzeitig

Kündigungen sind der sichtbarste, aber nicht der häufigste Schauplatz. Paragraph 99 BetrVG verlangt in Betrieben mit mehr als 20 wahlberechtigten Arbeitnehmern die Zustimmung des Betriebsrats zu jeder Einstellung, Versetzung und Ein- oder Umgruppierung, mit einer Woche Frist. Verweigert der Betriebsrat die Zustimmung, muss der Arbeitgeber das Arbeitsgericht anrufen. Soll die Stelle dringend besetzt werden, greift die vorläufige personelle Maßnahme nach Paragraph 100 - dann läuft eine Drei-Tages-Frist für zwei Gerichtsanträge, und wer sie versäumt, muss die Einstellung rückabwickeln.

Für eine einzige umstrittene Einstellung stehen damit drei Fristen gleichzeitig. In einem Unternehmen mit 1.500 Beschäftigten können in einer Woche leicht ein Dutzend Verfahren parallel laufen: mehrere Einstellungen nach Paragraph 99, eine Kündigung nach Paragraph 102, Versetzungen und eine Änderung der Arbeitszeitregelung nach Paragraph 87. In den meisten Unternehmen werden diese Verfahren per E-Mail, Papierlaufmappe oder mündlicher Absprache koordiniert - ohne zentralen Fristenkalender und ohne automatische Vollständigkeitsprüfung.

## Drei Formfehler, die jede Kündigung kippen

Unter all diesen Verfahren ist die Kündigung das mit den härtesten Folgen - und drei Fehlerquellen entscheiden hier über die Wirksamkeit, keine davon erfordert juristisches Urteilsvermögen. Erstens die unvollständige Information: Der Arbeitgeber muss dem Betriebsrat alle aus seiner Sicht tragenden Gründe mitteilen, und stichwortartige Umschreibungen genügen der BAG-Linie nicht. Fehlt ein relevantes Detail - etwa die Unterhaltspflichten des Betroffenen bei einer Sozialauswahl - ist die gesamte Anhörung fehlerhaft. Zweitens die falsche Fristberechnung: Die Wochenfrist beginnt mit dem Zugang der vollständigen Unterlagen, nicht mit dem Absenden; eine einen Tag zu früh ausgesprochene Kündigung ist unwirksam. Drittens nachgeschobene Gründe: Was in der Anhörung fehlt, fehlt vor Gericht und lässt sich im Prozess nicht mehr ergänzen.

Alle drei sind Koordinationsfehler, keine Rechtsfehler. Genau deshalb sind sie automatisierbar - die Prüfung gegen eine Checkliste, die Fristberechnung ab Zugang und die lückenlose Dokumentation lassen sich als Regelwerk abbilden, ohne dass eine Maschine den Kündigungsgrund bewerten müsste.

## Betriebsrats-Anhörung absichern: das Regelwerk klassifiziert, der Mensch verhandelt

Der [Decision Layer](/de/decision-layer/) zerlegt jedes Beteiligungsverfahren in einzelne Schritte und legt pro Schritt fest, ob Regelwerk, KI-Indikator oder Mensch entscheidet - und das ist nicht Beiwerk, sondern das Produkt. Die Zuordnung der Beteiligungsstufe und die Fristberechnung ab Zugang sind deterministisches Regelwerk: Maßnahmentyp hinein, richtiger Paragraph und laufende Frist heraus, ohne Ermessen. Die Vollständigkeitsprüfung der Unterlagen gegen die Checkliste ist KI-assistiert - das Modell liefert einen Hinweis, etwa dass Gründe nur stichwortartig benannt sind, und ein HR-Verantwortlicher validiert ihn vor der Übermittlung. Die inhaltliche Bewertung einer Stellungnahme, die Eskalation bei Widerspruch und das Verfahren vor der Einigungsstelle nach Paragraph 76 BetrVG bleiben beim Menschen.

Diese Trennung ist kein Disclaimer, sondern eine Notwendigkeit. Weil ein Formfehler nach Paragraph 102 die Kündigung kraft Gesetz unwirksam macht und DSGVO Artikel 22 vollautomatisierte Entscheidungen mit Rechtswirkung verbietet, ist "Regelwerk für Form und Frist, Mensch für Inhalt" die einzige tragfähige Architektur. Der Agent legt sich dabei als Koordinations- und Nachweis-Schicht über die bestehende HR-Plattform - SAP SuccessFactors, Workday oder Personio bleiben die führenden Systeme und liefern die Maßnahmen, die eine Beteiligung auslösen. Wettbewerber, die "KI-gestützte Kündigungsempfehlungen" andeuten, laufen direkt in das Hochrisiko-Regime nach Annex III(4)(b) und drohende Bussgelder von bis zu 20 Millionen Euro oder vier Prozent des weltweiten Konzern-Jahresumsatzes.

## Ein Agent, der beiden Seiten dient

Der Unterschied zu reinen HR-Werkzeugen ist, dass dieser Agent nicht für eine Seite arbeitet, sondern den Rahmen für beide professionalisiert. HR profitiert, weil keine Verfahren mehr an Formfehlern scheitern und die Vorbereitung der Unterlagen Stunden statt Tage dauert. Der Betriebsrat profitiert, weil er vollständige Unterlagen erhält, seine Fristen korrekt berechnet werden und die Dokumentation Transparenz schafft, die er bisher einfordern musste. Der Zugang des Betriebsrats zum Audit-Trail ist dabei keine Geste, sondern oft selbst mitbestimmungspflichtig: Die Koordinations-IT mit Überwachungs-Funktion fällt unter Paragraph 87 Absatz 1 Nummer 6 BetrVG, weshalb eine Betriebsvereinbarung Standard ist.

Genau dieser konfliktreduzierende Zuschnitt ist das Verkaufsargument, das marktübliche Workflow- oder Beratungslösungen nicht haben: Sie verkaufen entweder eine digitale Laufmappe mit Fristerinnerung oder anwaltliche Beratung und lassen die entscheidende Frage offen - wer hat was entschieden, und ist das vor dem Bundesarbeitsgericht beweisbar? Der Agent beantwortet sie, indem er jeden Schritt revisionssicher dokumentiert.

Der nächste Schritt ist deshalb keine Software-Einführung, sondern eine Bestandsaufnahme des eigenen Prozesses: An welcher Stelle der Betriebsrats-Beteiligung sitzt heute die manuelle Koordination, wo entstehen die Fristen, und wie prüfungsfest ist der Nachweis dahinter?

## Auf einen Blick

- **Was er tut**: koordiniert die formale Betriebsrats-Beteiligung, überwacht die Fristen und dokumentiert jeden Schritt revisionssicher
- **Klassifikation**: im Standardbetrieb kein Hochrisiko-System nach EU AI Act (Koordination und Dokumentation, keine Bewertung von Menschen)
- **Entscheidungslogik**: Klassifikation und Frist per Regelwerk, Vollständigkeit als KI-Hinweis, jede inhaltliche Bewertung und Eskalation beim Menschen
- **Compliance-Anker**: Anhörung nach Paragraph 102, Zustimmung nach Paragraph 99 und 100, Mitbestimmung nach Paragraph 87, Letztentscheidungs-Grenze nach DSGVO Artikel 22
- **Integration**: Schicht über SAP SuccessFactors, Workday oder Personio - kein Ersatz
- **Beweisfall**: vollständiger Verfahrensnachweis als Audit-Trail mit Zeitstempel, ohne nachträgliche Rekonstruktion

--- HR Agent - AI Agents für HR & People Operations ---
> 6 AI-Agent-Produkte für HR: Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Decision Layer mit Audit Trail. Betriebsratsfähig.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/de/warum-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Jede Entscheidung nachvollziehbar</p>
</div>
</a>
<a href="/de/warum-gosign/#infrastruktur" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Ihre Infrastruktur</p>
<p class="text-xs text-gosign-text-light">Kein SaaS. Kein Vendor-Lock-in.</p>
</div>
</a>
<a href="/de/warum-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Kein US-Cloud-Risiko</p>
</div>
</a>
</div>
</div>
</div>

<!-- Product Portfolio -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">HR Agent Portfolio</h2>
<p class="text-body-lg text-gosign-text-light mt-4 mb-8 max-w-narrow">
Ein HR Agent automatisiert nicht pauschal, sondern zerlegt Prozesse in Micro-Entscheidungen. Für jede Entscheidung definiert der <a href="/de/decision-layer/" class="text-gosign-accent-text hover:text-gosign-accent-hover">Decision Layer</a>: Mensch, Regelwerk oder KI.
</p>
<div class="grid grid-cols-1 md:grid-cols-2 lg:grid-cols-3 gap-6">
<a href="/de/leistungen/hr-agent/payroll-decision-layer/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<div class="flex items-center justify-between mb-3">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 18.75a60.07 60.07 0 0115.797 2.101c.727.198 1.453-.342 1.453-1.096V18.75M3.75 4.5v.75A.75.75 0 013 6h-.75m0 0v-.375c0-.621.504-1.125 1.125-1.125H20.25M2.25 6v9m18-10.5v.75c0 .414.336.75.75.75h.75m-1.5-1.5h.375c.621 0 1.125.504 1.125 1.125v9.75c0 .621-.504 1.125-1.125 1.125h-.375m1.5-1.5H21a.75.75 0 00-.75.75v.75m0 0H3.75m0 0h-.375a1.125 1.125 0 01-1.125-1.125V15m1.5 1.5v-.75A.75.75 0 003 15h-.75M15 10.5a3 3 0 11-6 0 3 3 0 016 0zm3 0h.008v.008H18V10.5zm-12 0h.008v.008H6V10.5z"/></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Payroll Decision Layer</h3>
<p class="text-body text-gosign-text-light mt-2">Tarifverträge, Schichtzuschläge, Sonderzahlungen. 4 Branchen-Simulationen.</p>
<p class="text-body font-semibold text-gosign-dark mt-3">82-92% vollautomatisch</p>
</a>
<a href="/de/leistungen/travel-decision-layer/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<div class="flex items-center justify-between mb-3">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M6 12L3.269 3.126A59.768 59.768 0 0121.485 12 59.77 59.77 0 013.27 20.876L5.999 12zm0 0h7.5"/></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Travel Decision Layer</h3>
<p class="text-body text-gosign-text-light mt-2">Jede Reisekostenabrechnung in 5-12 auditierbare Entscheidungsschritte.</p>
<p class="text-body font-semibold text-gosign-dark mt-3">>80% Kostensenkung pro Beleg</p>
</a>
<a href="/de/recruiting-agent/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<div class="flex items-center justify-between mb-3">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M18 18.72a9.094 9.094 0 003.741-.479 3 3 0 00-4.682-2.72m.94 3.198l.001.031c0 .225-.012.447-.037.666A11.944 11.944 0 0112 21c-2.17 0-4.207-.576-5.963-1.584A6.062 6.062 0 016 18.719m12 0a5.971 5.971 0 00-.941-3.197m0 0A5.995 5.995 0 0012 12.75a5.995 5.995 0 00-5.058 2.772m0 0a3 3 0 00-4.681 2.72 8.986 8.986 0 003.74.477m.94-3.197a5.971 5.971 0 00-.94 3.197M15 6.75a3 3 0 11-6 0 3 3 0 016 0zm6 3a2.25 2.25 0 11-4.5 0 2.25 2.25 0 014.5 0zm-13.5 0a2.25 2.25 0 11-4.5 0 2.25 2.25 0 014.5 0z"/></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Recruiting Agent</h3>
<p class="text-body text-gosign-text-light mt-2">Screening, Terminierung, Standardkommunikation. EU AI Act Hochrisiko.</p>
<p class="text-body font-semibold text-gosign-dark mt-3">70-75% Automatisierung</p>
</a>
<a href="/de/leistungen/hr-agent/leave-absence-decision-layer/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<div class="flex items-center justify-between mb-3">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M6.75 3v2.25M17.25 3v2.25M3 18.75V7.5a2.25 2.25 0 012.25-2.25h13.5A2.25 2.25 0 0121 7.5v11.25m-18 0A2.25 2.25 0 005.25 21h13.5A2.25 2.25 0 0021 18.75m-18 0v-7.5A2.25 2.25 0 015.25 9h13.5A2.25 2.25 0 0121 11.25v7.5"/></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Leave & Absence Decision Layer</h3>
<p class="text-body text-gosign-text-light mt-2">Urlaubsansprüche, Abwesenheitsregeln, BEM-Pflicht. 4 Branchen-Simulationen.</p>
<p class="text-body font-semibold text-gosign-dark mt-3">78-87% vollautomatisch</p>
</a>
<div class="border border-gosign-border rounded-card p-6 bg-gosign-light/50">
<div class="flex items-center justify-between mb-3">
<svg class="w-8 h-8 text-gosign-text-light" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M16.023 9.348h4.992v-.001M2.985 19.644v-4.992m0 0h4.992m-4.993 0l3.181 3.183a8.25 8.25 0 0013.803-3.7M4.031 9.865a8.25 8.25 0 0113.803-3.7l3.181 3.182"/></svg>
<span class="inline-flex items-center px-2.5 py-0.5 text-xs font-bold text-white bg-gosign-accent rounded-full">Coming</span>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Employee Lifecycle Decision Layer</h3>
<p class="text-body text-gosign-text-light mt-2">Onboarding, interne Wechsel, Offboarding in einer auditierbaren Pipeline.</p>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-gosign-light/50">
<div class="flex items-center justify-between mb-3">
<svg class="w-8 h-8 text-gosign-text-light" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 3c2.755 0 5.455.232 8.083.678.533.09.917.556.917 1.096v1.044a2.25 2.25 0 01-.659 1.591l-5.432 5.432a2.25 2.25 0 00-.659 1.591v2.927a2.25 2.25 0 01-1.244 2.013L9.75 21v-6.568a2.25 2.25 0 00-.659-1.591L3.659 7.409A2.25 2.25 0 013 5.818V4.774c0-.54.384-1.006.917-1.096A48.32 48.32 0 0112 3z"/></svg>
<span class="inline-flex items-center px-2.5 py-0.5 text-xs font-bold text-white bg-gosign-accent rounded-full">Coming</span>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Candidate Screening Decision Layer</h3>
<p class="text-body text-gosign-text-light mt-2">EU AI Act Hochrisiko. Bias-Monitoring. Betriebsrats-Mitbestimmung bei Auswahlrichtlinien.</p>
</div>
</div>
</div>
</section>

<!-- Start Boring -->
<section class="py-section bg-gosign-light"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Warum Sie mit langweiligen Prozessen starten sollten</h2>
<p class="text-body-lg text-gosign-text-light mt-4">Die wirkungsvollsten HR-Agenten automatisieren nicht die spektakulärsten Prozesse - sondern die repetitivsten. Payroll, Zeiterfassung, Standardabwesenheiten: hohe Regeldichte, niedriges Risiko, messbarer ROI ab Tag 1. Die Governance-Infrastruktur, die Sie dabei aufbauen, ist die Voraussetzung für komplexere Agenten.</p>
<p class="text-body-lg text-gosign-text-light mt-4">Die EU AI Act Hochrisiko-Pflichten für HR-KI-Systeme gelten nach aktuellem Recht ab dem 2. August 2026 - mit vorläufig geeinigter Verschiebung auf Dezember 2027 (Digital Omnibus, Mai 2026, formale Verabschiedung ausstehend). Die Hochrisiko-Einstufung bleibt bestehen; eine auditierbare Governance-Infrastruktur ist die Voraussetzung dafür. Die langweiligen Prozesse sind der schnellste Weg, diese Infrastruktur produktiv aufzubauen - die voraussichtlich gewonnene Zeit sollte dafür genutzt werden.</p>
</div></div></section>

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Kostenloses eBook: KI in HR</p>
<p class="text-body text-gosign-text mb-4">EU AI Act Checkliste, Decision-Framework, Betriebsrats-Perspektive und Readiness-Assessment - das Governance-Handbuch für HR-Verantwortliche.</p>
<a href="/de/ebook/ki-hr-governance-handbuch/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Jetzt kostenlos herunterladen</a>
</div>

<!-- Micro-Entscheidungen: 3 HR-Prozesse kompakt -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">So arbeitet ein HR Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Jeder HR-Prozess besteht aus Dutzenden einzelner Entscheidungen. Der Agent prüft gegen alle Tarifvertragskriterien - konsistenter als jeder Sachbearbeiter. Wo Betriebsrat, Arbeitsrecht oder Diskriminierungsrisiko es verlangen, entscheidet ein Mensch.
</p>
<h3 class="text-h3 font-bold text-gosign-dark mt-10">Krankmeldung verarbeiten</h3>
<div class="mt-4 overflow-x-auto">
<table class="w-full text-left text-body">
<thead><tr class="border-b-2 border-gosign-dark"><th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Micro-Entscheidung</th><th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Wer entscheidet</th><th scope="col" class="py-3 font-bold text-gosign-dark">Warum</th></tr></thead>
<tbody class="text-gosign-text-light">
<tr class="border-b border-gosign-border"><td class="py-3 pr-4">Lohnfortzahlungsfrist prüfen</td><td class="py-3 pr-4 font-medium">KI eigenständig</td><td class="py-3">Prüft gegen ALLE Tarifvertragskriterien - konsistenter als jeder Sachbearbeiter, auch freitags um 16 Uhr</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4">BEM-Pflicht prüfen (&gt; 6 Wochen in 12 Monaten)</td><td class="py-3 pr-4 font-medium">Mensch</td><td class="py-3">Betriebsrat fordert Human-in-the-Loop, Diskriminierungsrisiko bei Gesundheitsdaten</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4">Führungskraft über Abwesenheit informieren</td><td class="py-3 pr-4 font-medium">KI eigenständig</td><td class="py-3">Konsistente Information - nur Abwesenheit und Dauer, keine Diagnose</td></tr>
</tbody>
</table>
</div>
<h3 class="text-h3 font-bold text-gosign-dark mt-10">Onboarding</h3>
<div class="mt-4 overflow-x-auto">
<table class="w-full text-left text-body">
<thead><tr class="border-b-2 border-gosign-dark"><th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Micro-Entscheidung</th><th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Wer entscheidet</th><th scope="col" class="py-3 font-bold text-gosign-dark">Warum</th></tr></thead>
<tbody class="text-gosign-text-light">
<tr class="border-b border-gosign-border"><td class="py-3 pr-4">Eingruppierung in Tarifvertrag</td><td class="py-3 pr-4 font-medium">Mensch</td><td class="py-3">Betriebsrat hat Mitbestimmungsrecht bei Eingruppierung</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4">IT-Zugänge und Berechtigungen</td><td class="py-3 pr-4 font-medium">Regelwerk + KI</td><td class="py-3">Standardberechtigungen automatisch, Sonderzugänge eskaliert</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4">Einarbeitungsplan erstellen</td><td class="py-3 pr-4 font-medium">KI + Mensch</td><td class="py-3">KI erstellt Vorschlag, Führungskraft prüft und passt an</td></tr>
</tbody>
</table>
</div>
<h3 class="text-h3 font-bold text-gosign-dark mt-10">Zeugniserstellung</h3>
<div class="mt-4 overflow-x-auto">
<table class="w-full text-left text-body">
<thead><tr class="border-b-2 border-gosign-dark"><th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Micro-Entscheidung</th><th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Wer entscheidet</th><th scope="col" class="py-3 font-bold text-gosign-dark">Warum</th></tr></thead>
<tbody class="text-gosign-text-light">
<tr class="border-b border-gosign-border"><td class="py-3 pr-4">Tätigkeitsbeschreibung generieren</td><td class="py-3 pr-4 font-medium">KI</td><td class="py-3">Basierend auf Stellenbeschreibung, Vorschlag zur Prüfung</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4">Leistungsbeurteilung formulieren</td><td class="py-3 pr-4 font-medium">Mensch</td><td class="py-3">Individuelle Bewertung, Führungskraft verantwortet</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4">Rechtliche Konformität prüfen</td><td class="py-3 pr-4 font-medium">KI + Mensch</td><td class="py-3">KI prüft gegen Formulierungsmuster und flaggt Risiken, Mensch entscheidet final</td></tr>
</tbody>
</table>
</div>
<p class="text-body-lg text-gosign-text-light mt-8">
<strong>Das Muster:</strong> Routine und Regeln automatisiert der Agent. Ermessen und rechtlich sensible Entscheidungen bleiben beim Menschen. Jeder Schritt dokumentiert.
</p>
<p class="mt-4">
<a href="/de/decision-layer/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Mehr über den Decision Layer →</a>
</p>
</div>
</div>
</section>

<!-- Decision Layer kompakt -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Decision Layer: Jede Entscheidung auditierbar</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Der <a href="/de/decision-layer/" class="text-gosign-accent-text hover:text-gosign-accent-hover">Decision Layer</a> zerlegt jeden HR-Prozess in einzelne Entscheidungsschritte und definiert für jeden Schritt: Entscheidet ein Mensch, ein Regelwerk oder die KI? Wo das Modell sicher entscheiden kann, entscheidet es autonom. Wo Bias-Risiko, Diskriminierungspotenzial oder Mitbestimmung eine Rolle spielen, erzwingt die Architektur menschliche Prüfung.
</p>
<div class="mt-6 bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-body font-mono text-gosign-dark">
Input &rarr; Modell &rarr; Bewertung &rarr; Confidence Score &rarr; Begründung &rarr; Entscheidungspfad &rarr; Ergebnis
</p>
</div>
<p class="text-body-lg text-gosign-text-light mt-4">
Jede Entscheidung erzeugt einen vollständigen Datensatz: Eingabe, Regel, Version, Konfidenz, Ergebnis, Zeitstempel. Prüfbar für Betriebsrat, Wirtschaftsprüfer und interne Compliance.
</p>
</div>
</div>
</section>

<!-- Governance & Mitbestimmung -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Governance & Mitbestimmung</h2>
<h3 class="text-h3 font-bold text-gosign-dark mt-8">Human-in-the-Loop als Architekturprinzip</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Nicht als optionale Freigabeschleife, sondern als architektonisch erzwungenes Routing. Autonome Entscheidung bei hoher Konfidenz und niedrigem Risiko. Human-in-the-Loop bei Bias-Risiko, Diskriminierungspotenzial und Mitbestimmungsthemen. Betriebsvereinbarungen werden als explizite Constraints im Decision Layer abgebildet - der Agent kann sie nicht umgehen.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
<a href="/de/governance/mitbestimmung/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Mitbestimmung im Detail →</a>
</p>
<h3 class="text-h3 font-bold text-gosign-dark mt-8">Audit Trail</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Jede Agenten-Entscheidung erzeugt einen vollständigen Entscheidungsdatensatz: Eingabe, Regel, Version, Konfidenz, Entscheidungspfad, Ergebnis, Zeitstempel. Der Betriebsrat kann über das Auditor-Portal alle Entscheidungen nachvollziehen. Wie Betriebsräte vom Blocker zum Enabler werden, beschreibt <a href="/de/magazin/ki-betriebsrat-ai-literacy/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Artikel 9 des Blueprint 2026</a>.
</p>
<h3 class="text-h3 font-bold text-gosign-dark mt-8">EU AI Act Readiness</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Die Architektur adressiert Transparenz (Art. 13), menschliche Aufsicht (Art. 14), Aufzeichnungspflichten (Art. 12) und Risikomanagement (Art. 9) als Designprinzip - kein nachträgliches Compliance-Projekt.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
<a href="/de/governance/eu-ai-act/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">EU AI Act Readiness →</a>
</p>
</div>
</div>
</section>

<!-- Integration -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Integration in Ihre bestehende Systemlandschaft</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
AI Agents ersetzen keine Systeme. SAP SuccessFactors bleibt Ihr HCM, Workday bleibt Ihre HR-Plattform, SAP FI/CO bleibt Ihr ERP. Die Agentenlogik ist vom Zielsystem entkoppelt - über standardisierte Schnittstellen. Kein Migrationsprojekt, kein Systemwechsel. Ein Prozess, ein System, ein Agent.
</p>
</div>
</div>
</section>

<!-- ProcessSteps -->
<section class="py-section bg-gosign-dark text-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold">Vom PoC zur Plattform</h2>
<div class="grid md:grid-cols-3 gap-8 mt-8">
<div>
<p class="text-xs font-bold uppercase tracking-wider text-gosign-accent-on-dark">Discover - 1 Woche</p>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-2">Prozessanalyse, Regelwerke verstehen, Use Cases priorisieren. Welcher Prozess hat das höchste Fehlerpotenzial?</p>
</div>
<div>
<p class="text-xs font-bold uppercase tracking-wider text-gosign-accent-on-dark">Build - 3-4 Wochen</p>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-2">Produktiver PoC. Ein Agent, ein Prozess, live in Ihrer Infrastruktur mit Decision Layer und Audit Trail.</p>
</div>
<div>
<p class="text-xs font-bold uppercase tracking-wider text-gosign-accent-on-dark">Scale - Kontinuierlich</p>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-2">Mehr Agenten, mehr Prozesse. Gleiche Governance, gleiche Auditierbarkeit. Nach 12-18 Monaten betreiben Sie Ihre Agenten eigenständig.</p>
</div>
</div>
</div>
</section>

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">HR Agent Readiness Assessment</p>
<p class="text-body text-gosign-text mb-4">7 Fragen, 3 Minuten: Wie bereit ist Ihre HR-Organisation für AI Agents?</p>
<a href="/de/hr-agent-readiness/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Assessment starten &rarr;</a>
</div>

<!-- HR-Agent-Katalog -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex flex-col md:flex-row items-start gap-8">
<div class="flex-1">
<h2 class="text-h2 font-bold text-gosign-dark">HR-Agent-Katalog: 48 Agenten bewertet und priorisiert</h2>
<p class="text-body-lg text-gosign-text mt-4">Welche HR-Agenten gibt es, welche Governance brauchen sie, und in welcher Reihenfolge sollten Sie starten? Der Katalog bewertet 48 Agenten auf 6 Dimensionen - von Agent Readiness bis EU AI Act Klassifikation.</p>
<p class="text-body text-gosign-text-light mt-3">11 Domänen, 3 interaktive Priorisierungsquadranten, Micro-Decision-Tabellen für jeden Agenten.</p>
<a href="/de/hr-agent-katalog/" class="inline-flex items-center gap-2 mt-4 text-body font-semibold text-gosign-accent hover:underline">Zum HR-Agent-Katalog &rarr;</a>
</div>
</div>
</div>
</section>

<!-- Vertiefung im Agent Briefing -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">Vertiefung im Agent Briefing (Gosign Magazin)</h2>
<div class="grid md:grid-cols-3 gap-6">
<a href="/de/magazin/ki-betriebsrat-ai-literacy/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<h3 class="text-h3 font-bold text-gosign-dark">Betriebsrat & AI Literacy</h3>
</a>
<a href="/de/magazin/decision-layer-shadow-ai/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<h3 class="text-h3 font-bold text-gosign-dark">Decision Layer & Shadow AI</h3>
</a>
<a href="/de/magazin/eu-ai-act-2026-unternehmen/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<h3 class="text-h3 font-bold text-gosign-dark">EU AI Act 2026</h3>
</a>
</div>
</div>
</section>

--- Impressum - Gosign GmbH ---
> Impressum der Gosign GmbH, Hamburg. Geschäftsführer, Kontakt, Registereintrag und rechtliche Hinweise.

<h1>Impressum</h1>

<h2>Angaben gemäß § 5 DDG</h2>
<p>
Gosign GmbH<br/>
Hallerstraße 8<br/>
20146 Hamburg
</p>

<h2>Vertreten durch</h2>

<div class="grid grid-cols-1 sm:grid-cols-2 gap-8 not-prose my-8">
<div class="flex items-start gap-4">
<img
src="/images/team/bert-gogolin.webp"
alt="Bert Gogolin, Geschäftsführer Gosign GmbH"
width="80"
height="80"
class="rounded-full w-20 h-20 object-cover flex-shrink-0"
loading="lazy"
/>
<div>
<p class="font-semibold text-gosign-dark text-body">Bert Gogolin</p>
<p class="text-small text-gosign-text-light">Geschäftsführer</p>
<a
href="https://www.linkedin.com/in/bertgogolin/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center gap-1 text-small text-gosign-text-light hover:text-gosign-accent transition-colors mt-1"
aria-label="Bert Gogolin auf LinkedIn"
>
<svg class="w-4 h-4" fill="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path d="M20.447 20.452h-3.554v-5.569c0-1.328-.027-3.037-1.852-3.037-1.853 0-2.136 1.445-2.136 2.939v5.667H9.351V9h3.414v1.561h.046c.477-.9 1.637-1.85 3.37-1.85 3.601 0 4.267 2.37 4.267 5.455v6.286zM5.337 7.433a2.062 2.062 0 01-2.063-2.065 2.064 2.064 0 112.063 2.065zm1.782 13.019H3.555V9h3.564v11.452zM22.225 0H1.771C.792 0 0 .774 0 1.729v20.542C0 23.227.792 24 1.771 24h20.451C23.2 24 24 23.227 24 22.271V1.729C24 .774 23.2 0 22.222 0h.003z"/>
</svg>
LinkedIn
</a>
</div>
</div>

<div class="flex items-start gap-4">
<img
src="/images/team/dieter-gogolin.webp"
alt="Dieter Gogolin, Geschäftsführer Gosign GmbH"
width="80"
height="80"
class="rounded-full w-20 h-20 object-cover flex-shrink-0"
loading="lazy"
/>
<div>
<p class="font-semibold text-gosign-dark text-body">Dieter Gogolin</p>
<p class="text-small text-gosign-text-light">Geschäftsführer</p>
</div>
</div>
</div>

<h2>Kontakt</h2>
<p>
E-Mail: web26 [at] gosign.de<br/>
Kontakt: Über unser <a href="/de/kontakt/" class="text-gosign-accent-text hover:text-gosign-accent-hover">Kontaktformular</a> oder <a href="/de/kontakt/#booking" class="text-gosign-accent-text hover:text-gosign-accent-hover">Terminbuchung</a><br/>
Weitere Unternehmensdaten: <a href="/de/fakten/" class="text-gosign-accent-text hover:text-gosign-accent-hover">Fakten &amp; Zahlen</a>
</p>

<h2>Registereintrag</h2>
<p>
Registergericht: Amtsgericht Hamburg<br/>
Registernummer: HRB 112197
</p>

<h2>Umsatzsteuer-ID</h2>
<p>
Umsatzsteuer-Identifikationsnummer gemäß § 27a Umsatzsteuergesetz:<br/>
DE215891388
</p>

<h2>Verantwortlich für den Inhalt nach § 18 Abs. 2 MStV</h2>
<p>
Gosign GmbH<br/>
Bert Gogolin<br/>
Hallerstraße 8<br/>
20146 Hamburg
</p>

<h2>Haftung für Inhalte</h2>
<p>
Als Diensteanbieter sind wir gemäß § 7 Abs. 1 DDG für eigene Inhalte auf diesen Seiten nach den allgemeinen Gesetzen verantwortlich. Nach §§ 8 bis 10 DDG sind wir als Diensteanbieter jedoch nicht verpflichtet, übermittelte oder gespeicherte fremde Informationen zu überwachen oder nach Umständen zu forschen, die auf eine rechtswidrige Tätigkeit hinweisen.
</p>
<p>
Verpflichtungen zur Entfernung oder Sperrung der Nutzung von Informationen nach den allgemeinen Gesetzen bleiben hiervon unberührt. Eine diesbezügliche Haftung ist jedoch erst ab dem Zeitpunkt der Kenntnis einer konkreten Rechtsverletzung möglich. Bei Bekanntwerden von entsprechenden Rechtsverletzungen werden wir diese Inhalte umgehend entfernen.
</p>

<h2>Haftung für Links</h2>
<p>
Unser Angebot enthält Links zu externen Websites Dritter, auf deren Inhalte wir keinen Einfluss haben. Deshalb können wir für diese fremden Inhalte auch keine Gewähr übernehmen. Für die Inhalte der verlinkten Seiten ist stets der jeweilige Anbieter oder Betreiber der Seiten verantwortlich. Die verlinkten Seiten wurden zum Zeitpunkt der Verlinkung auf mögliche Rechtsverstöße überprüft. Rechtswidrige Inhalte waren zum Zeitpunkt der Verlinkung nicht erkennbar.
</p>
<p>
Eine permanente inhaltliche Kontrolle der verlinkten Seiten ist jedoch ohne konkrete Anhaltspunkte einer Rechtsverletzung nicht zumutbar. Bei Bekanntwerden von Rechtsverletzungen werden wir derartige Links umgehend entfernen.
</p>

<h2>Urheberrecht</h2>
<p>
Die durch die Seitenbetreiber erstellten Inhalte und Werke auf diesen Seiten unterliegen dem deutschen Urheberrecht. Die Vervielfältigung, Bearbeitung, Verbreitung und jede Art der Verwertung außerhalb der Grenzen des Urheberrechtes bedürfen der schriftlichen Zustimmung des jeweiligen Autors bzw. Erstellers. Downloads und Kopien dieser Seite sind nur für den privaten, nicht kommerziellen Gebrauch gestattet.
</p>
<p>
Soweit die Inhalte auf dieser Seite nicht vom Betreiber erstellt wurden, werden die Urheberrechte Dritter beachtet. Insbesondere werden Inhalte Dritter als solche gekennzeichnet. Sollten Sie trotzdem auf eine Urheberrechtsverletzung aufmerksam werden, bitten wir um einen entsprechenden Hinweis. Bei Bekanntwerden von Rechtsverletzungen werden wir derartige Inhalte umgehend entfernen.
</p>

<h2>Bildnachweise</h2>
<p>
Porträtfotos der Geschäftsführung: © Gosign GmbH.<br/>
Grafiken und Schaubilder: Eigene Erstellung durch Gosign GmbH, teilweise unter Einsatz KI-gestützter Werkzeuge.<br/>
Soweit nicht anders gekennzeichnet: © Gosign GmbH. Alle Rechte vorbehalten.
</p>

<h2>Streitschlichtung</h2>
<p>
Die Europäische Kommission stellt eine Plattform zur Online-Streitbeilegung (OS) bereit:
<a href="https://ec.europa.eu/consumers/odr/" target="_blank" rel="noopener noreferrer" class="text-gosign-accent-text hover:text-gosign-accent-hover">https://ec.europa.eu/consumers/odr/</a>
</p>
<p>
Wir sind nicht bereit oder verpflichtet, an Streitbeilegungsverfahren vor einer Verbraucherschlichtungsstelle teilzunehmen.
</p>

<h2>Markenhinweise</h2>
<p>
<a href="https://www.sap.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text hover:text-gosign-accent transition-colors">SAP</a>, SAP S/4HANA, SAP SuccessFactors, SAP Business Technology Platform und SAP Joule sind eingetragene Marken oder Marken der SAP SE, Walldorf.
</p>
<p>
<a href="https://www.microsoft.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text hover:text-gosign-accent transition-colors">Microsoft</a>, Microsoft Azure, Microsoft Copilot, Microsoft Teams, SharePoint, Active Directory und Microsoft Graph sind eingetragene Marken oder Marken der Microsoft Corporation, Redmond, USA.
</p>
<p>
<a href="https://www.datev.de/" target="_blank" rel="noopener noreferrer" class="text-gosign-text hover:text-gosign-accent transition-colors">DATEV</a> ist eine eingetragene Marke der DATEV eG, Nürnberg.
</p>
<p>
<a href="https://www.workday.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text hover:text-gosign-accent transition-colors">Workday</a> ist eine eingetragene Marke von Workday, Inc., Pleasanton, USA.
</p>
<p>
<a href="https://www.personio.de/" target="_blank" rel="noopener noreferrer" class="text-gosign-text hover:text-gosign-accent transition-colors">Personio</a> ist eine Marke der Personio SE & Co. KG, München.
</p>
<p>
<a href="https://about.google/" target="_blank" rel="noopener noreferrer" class="text-gosign-text hover:text-gosign-accent transition-colors">Google</a> und Google Calendar sind Marken von Google LLC, Mountain View, USA.
</p>
<p>
Alle weiteren genannten Produkt- und Firmennamen sind Marken oder eingetragene Marken ihrer jeweiligen Inhaber.
</p>
<p>
Die Verwendung von Markenzeichen auf dieser Website dient ausschließlich der Produktidentifikation und stellt keine Zugehörigkeit, Zertifizierung oder Endorsement durch die jeweiligen Markeninhaber dar.
</p>

--- Kontakt ---
> Sprechen Sie mit uns über einen konkreten Prozess. Kontaktformular und Terminbuchung.

<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">

<div id="hq" class="scroll-mt-24">
<h2 class="text-h2 font-bold text-gosign-dark">Hauptsitz & Governance</h2>
<p class="text-body-lg text-gosign-text-light mt-2">Geschäftsführung, Governance-Architektur, Kundenprojekte DACH.</p>
<div class="mt-6 grid grid-cols-1 sm:grid-cols-2 gap-6">
<div>
<h3 class="text-body font-bold text-gosign-dark">Hamburg</h3>
<div class="text-body text-gosign-text-light mt-1 space-y-0.5">
<p>Gosign GmbH</p>
<p>Hallerstraße 8</p>
<p>20146 Hamburg</p>
</div>
</div>
<div>
<h3 class="text-body font-bold text-gosign-dark">Schulungszentrum Hamburg</h3>
<div class="text-body text-gosign-text-light mt-1 space-y-0.5">
<p>Grindelberg 77</p>
<p>20144 Hamburg</p>
</div>
</div>
</div>
</div>

<div id="market" class="mt-12 pt-8 border-t border-gosign-border scroll-mt-24">
<h2 class="text-h2 font-bold text-gosign-dark">Projektmanagement & Marktpräsenz</h2>
<p class="text-body-lg text-gosign-text-light mt-2">Projektleitung und Kundenbetreuung in Ihrer Zeitzone, in Ihrer Sprache.</p>
<div class="mt-6 grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-3 gap-6">
<div>
<h3 class="text-body font-bold text-gosign-dark">Berlin</h3>
<div class="text-body text-gosign-text-light mt-1 space-y-0.5">
<p>Gosign GmbH - Berlin Office</p>
<p>Nogatstraße 46</p>
<p>12051 Berlin</p>
</div>
</div>
<div>
<h3 class="text-body font-bold text-gosign-dark">Krakau</h3>
<div class="text-body text-gosign-text-light mt-1 space-y-0.5">
<p>Gosign - Kraków Office</p>
<p><a href="https://www.gosign.pl" target="_blank" rel="noopener noreferrer" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">gosign.pl</a></p>
</div>
</div>
<div>
<h3 class="text-body font-bold text-gosign-dark">Barcelona</h3>
<div class="text-body text-gosign-text-light mt-1 space-y-0.5">
<p>Gosign - Barcelona Office</p>
<p><a href="https://www.gosign.es" target="_blank" rel="noopener noreferrer" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">gosign.es</a></p>
</div>
</div>
<div>
<h3 class="text-body font-bold text-gosign-dark">Lissabon</h3>
<div class="text-body text-gosign-text-light mt-1 space-y-0.5">
<p>Gosign - Lisbon Office</p>
<p><a href="https://www.gosign.pt" target="_blank" rel="noopener noreferrer" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">gosign.pt</a></p>
</div>
</div>
<div>
<h3 class="text-body font-bold text-gosign-dark">São Paulo <span class="text-gosign-text-light font-normal">(LATAM Office)</span></h3>
<div class="text-body text-gosign-text-light mt-1 space-y-0.5">
<p>Gosign - São Paulo Office</p>
<p><a href="https://www.gosign.pt" target="_blank" rel="noopener noreferrer" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">gosign.pt</a></p>
</div>
</div>
</div>
</div>

<div id="engineering" class="mt-12 pt-8 border-t border-gosign-border scroll-mt-24">
<h2 class="text-h2 font-bold text-gosign-dark">Engineering & Research</h2>
<p class="text-body-lg text-gosign-text-light mt-2">Über 60 Engineers. Hochschulkooperationen für Forschung und Nachwuchs.</p>
<div class="mt-6">
<h3 class="text-body font-bold text-gosign-dark">Lahore · Islamabad, Pakistan</h3>
<div class="text-body text-gosign-text-light mt-1 space-y-0.5">
<p>Entwicklungszentren mit Hochschulkooperationen:</p>
<p><a href="https://pu.edu.pk/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-text-light transition-colors underline decoration-dotted">University of the Punjab</a> · <a href="https://www.comsats.edu.pk/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-text-light transition-colors underline decoration-dotted">COMSATS University</a></p>
<p><a href="https://www.gosign.pk" target="_blank" rel="noopener noreferrer" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">gosign.pk</a></p>
</div>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h3 font-bold text-gosign-dark">Was wir im ersten Gespräch klären</h2>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light">Welcher Prozess soll automatisiert werden?</li>
<li class="text-body-lg text-gosign-text-light">Welche Systeme sind beteiligt (SAP, DATEV, Workday, etc.)?</li>
<li class="text-body-lg text-gosign-text-light">Welche Governance-Anforderungen gelten (Betriebsrat, Revision, Compliance)?</li>
<li class="text-body-lg text-gosign-text-light">Cloud, Self-Hosted oder Hybrid?</li>
<li class="text-body-lg text-gosign-text-light">Zeitrahmen und nächste Schritte</li>
</ul>
</div>
</section>

--- Co-Build - Individuelle AI-Agenten für Ihren Prozess ---
> Co-Build: Ihr Prozess, Ihr Agent. In 4-6 Wochen vom Discover bis zum produktiven AI-Agenten mit Quellcode-Zugang, Decision Layer und Exit-Strategie.

<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="AI-Agenten Navigation">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/de/leistungen/ai-agents/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
AI-Agenten
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/de/leistungen/ai-agents/document-agents/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Document</a>
<a href="/de/leistungen/ai-agents/workflow-agents/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Workflow</a>
<a href="/de/leistungen/ai-agents/knowledge-agents/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Knowledge</a>
<a href="/de/leistungen/ai-agents/co-build/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Co-Build</a>
</div>
</div>
</nav>

<!-- Auf einen Blick -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h2 font-bold text-gosign-dark">Auf einen Blick</h2>
<div class="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-3 gap-4 mt-6">
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">4-6 Wochen</p>
<p class="text-body text-gosign-text-light mt-1">Vom Discover bis zum produktiven Agenten in Ihrer Infrastruktur</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Voller Quellcode</p>
<p class="text-body text-gosign-text-light mt-1">Code, Prompts, Regelwerke, Dokumentation - voller Zugang, dauerhaftes Nutzungsrecht</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Kein SaaS</p>
<p class="text-body text-gosign-text-light mt-1">Keine monatlichen Gebühren. Kein Vendor Lock-in. Eigenbetrieb möglich.</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Decision Layer</p>
<p class="text-body text-gosign-text-light mt-1">Jeder Agent mit Audit Trail, Human-in-the-Loop und Regelwerk-Versionierung</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Modell-agnostisch</p>
<p class="text-body text-gosign-text-light mt-1">Claude, ChatGPT, Gemini, Llama - austauschbar ohne Codeänderung</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Exit-Strategie</p>
<p class="text-body text-gosign-text-light mt-1">Schulung, Dokumentation, Übergabe. Nach 12-18 Monaten eigenständig.</p>
</div>
</div>
</div>
</div>
</section>

<!-- 3-Phasen-Modell -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Drei Phasen zum produktiven Agenten</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Jeder Co-Build folgt einem strukturierten Ablauf. Am Ende steht ein produktiver Agent in Ihrer Infrastruktur - mit Quellcode, Dokumentation und Exit-Strategie.
</p>
</div>
<div class="grid grid-cols-1 md:grid-cols-3 gap-6 mt-8 max-w-content">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Phase 1 - Woche 1</p>
<p class="text-h3 font-bold text-gosign-dark">Discover</p>
<ul class="mt-4 space-y-2 text-body text-gosign-text-light">
<li>Prozessanalyse mit Ihrem Fachteam</li>
<li>Regelwerke identifizieren und formalisieren</li>
<li>Entscheidungspunkte kartieren</li>
<li>Decision Layer Design</li>
<li>Systemlandschaft und Integrationen klären</li>
</ul>
<p class="text-body text-gosign-text-light mt-4 font-semibold">Ergebnis: Prozess-Blueprint mit Entscheidungsmatrix</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Phase 2 - Woche 2-5</p>
<p class="text-h3 font-bold text-gosign-dark">Build</p>
<ul class="mt-4 space-y-2 text-body text-gosign-text-light">
<li>Agent-Entwicklung mit Ihrem Team</li>
<li>Decision Layer implementieren</li>
<li>Regelwerke als versionierte Konfiguration</li>
<li>System-Integration (SAP, DATEV, etc.)</li>
<li>Tests mit realen Daten</li>
</ul>
<p class="text-body text-gosign-text-light mt-4 font-semibold">Ergebnis: Produktiver Agent in Ihrer Infrastruktur</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Phase 3 - Woche 5-6</p>
<p class="text-h3 font-bold text-gosign-dark">Transfer</p>
<ul class="mt-4 space-y-2 text-body text-gosign-text-light">
<li>Quellcode-Übergabe</li>
<li>Teamschulung für Eigenbetrieb</li>
<li>Dokumentation von Code, Prompts, Regelwerken</li>
<li>Monitoring und Alerting einrichten</li>
<li>Exit-Strategie dokumentieren</li>
</ul>
<p class="text-body text-gosign-text-light mt-4 font-semibold">Ergebnis: Ihr Team betreibt den Agenten eigenständig</p>
</div>
</div>
</div>
</section>

<!-- Für welche Bereiche -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Für welche Bereiche</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Co-Build eignet sich für jeden Prozess, der auf Regelwerken basiert und aktuell von Menschen manuell bearbeitet wird. Typische Bereiche:
</p>
<div class="grid grid-cols-1 sm:grid-cols-2 gap-4 mt-6">
<div class="bg-gosign-light border border-gosign-border rounded-card p-4">
<p class="font-semibold text-gosign-dark text-body">Compliance & Legal</p>
<p class="text-body text-gosign-text-light mt-1">Regulatorische Prüfungen, Vertragsprüfung, Klauselextraktion, Fristüberwachung.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-4">
<p class="font-semibold text-gosign-dark text-body">Operations & Supply Chain</p>
<p class="text-body text-gosign-text-light mt-1">Bestellprozesse, Lieferantenmanagement, Qualitätsprüfung, Reklamationsverarbeitung.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-4">
<p class="font-semibold text-gosign-dark text-body">Shared Services</p>
<p class="text-body text-gosign-text-light mt-1">Ticket-Routing, Anfragenklassifizierung, interne Wissensbereitstellung, Service-Desk-Automatisierung.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-4">
<p class="font-semibold text-gosign-dark text-body">Branchenspezifisch</p>
<p class="text-body text-gosign-text-light mt-1">Exportkontrolle, Zollabwicklung, Versicherungsschäden, Kreditprüfung - jeder regelbasierte Prozess.</p>
</div>
</div>
</div>
</div>
</section>

<!-- Was Sie bekommen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Was Sie bekommen</h2>
<ul class="mt-6 space-y-3">
<li class="text-body-lg text-gosign-text-light"><strong>Quellcode:</strong> Vollständiger Agent-Code in Ihrem Repository</li>
<li class="text-body-lg text-gosign-text-light"><strong>Prompts:</strong> Alle Prompt-Chains und System-Prompts, dokumentiert und versioniert</li>
<li class="text-body-lg text-gosign-text-light"><strong>Regelwerke:</strong> Fachliche Regeln als versionierte Konfiguration, nicht als Hardcoding</li>
<li class="text-body-lg text-gosign-text-light"><strong>Decision Layer:</strong> Audit Trail, Human-in-the-Loop, Betriebsvereinbarungs-Constraints</li>
<li class="text-body-lg text-gosign-text-light"><strong>Dokumentation:</strong> Architektur, Entscheidungslogik, Testfälle, Deployment-Anleitung</li>
<li class="text-body-lg text-gosign-text-light"><strong>Exit-Strategie:</strong> Schulung, Übergabeprotokoll, Support-Laufzeit</li>
</ul>
</div>
</div>
</section>

<!-- Vergleich: Co-Build vs. SaaS vs. Inhouse -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Co-Build vs. SaaS vs. Inhouse</h2>
<div class="overflow-x-auto mt-6">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-dark">
<th class="py-3 pr-4 text-body font-bold text-gosign-dark"></th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Co-Build</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">SaaS-Plattform</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Inhouse</th>
</tr>
</thead>
<tbody class="text-body text-gosign-text-light">
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Time-to-Value</td>
<td class="py-3 px-4">4-6 Wochen</td>
<td class="py-3 px-4">2-4 Wochen</td>
<td class="py-3 px-4">6-12 Monate</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Quellcode-Zugang</td>
<td class="py-3 px-4">Vollständig</td>
<td class="py-3 px-4">Kein Zugang</td>
<td class="py-3 px-4">Vollständig</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Vendor Lock-in</td>
<td class="py-3 px-4">Keiner</td>
<td class="py-3 px-4">Hoch</td>
<td class="py-3 px-4">Keiner</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Governance / Audit</td>
<td class="py-3 px-4">Decision Layer inkl.</td>
<td class="py-3 px-4">Plattformabhängig</td>
<td class="py-3 px-4">Muss gebaut werden</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Laufende Kosten</td>
<td class="py-3 px-4">Infrastruktur + optional Wartung</td>
<td class="py-3 px-4">Monatliche Lizenz</td>
<td class="py-3 px-4">Personalkosten</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Anpassbarkeit</td>
<td class="py-3 px-4">Unbegrenzt</td>
<td class="py-3 px-4">Innerhalb der Plattform</td>
<td class="py-3 px-4">Unbegrenzt</td>
</tr>
</tbody>
</table>
</div>
</div>
</div>
</section>

<!-- Praxisbeispiel -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h2 font-bold text-gosign-dark">Praxisbeispiel: Compliance-Prüfung im Shared Service Center</h2>
<p class="text-body-lg text-gosign-text-light mt-4">Ein Shared Service Center prüft monatlich 120 Lieferantenverträge auf Compliance-Konformität - manuell, mit Checklisten in Excel.</p>
<div class="grid grid-cols-1 sm:grid-cols-2 gap-6 mt-8">
<div class="bg-gosign-white rounded-card p-6">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-3">Vorher - manuell</p>
<ul class="space-y-2 text-body text-gosign-text-light">
<li><strong>45 Min</strong> pro Vertrag (Lesen, Checkliste, Dokumentation)</li>
<li><strong>~90 Stunden/Monat</strong> für das Team</li>
<li><strong>12% Fehlerquote</strong> bei der Klausel-Erkennung</li>
<li><strong>Keine Versionierung</strong> der Prüflogik</li>
</ul>
</div>
<div class="bg-gosign-white rounded-card p-6 border-2 border-gosign-accent">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-3">Nachher - Co-Build Agent</p>
<ul class="space-y-2 text-body text-gosign-text-light">
<li><strong>82% autonom</strong> geprüft (Standardverträge)</li>
<li><strong>~19 Stunden/Monat</strong> (nur Ausnahmen + Stichproben)</li>
<li><strong>&lt;2% Fehlerquote</strong> durch regelbasierte Prüfung</li>
<li><strong>Decision Layer</strong> mit vollständigem Audit Trail</li>
</ul>
</div>
</div>
<div class="bg-gosign-white rounded-card p-4 mt-6">
<p class="text-body text-gosign-text-light"><strong>Ergebnis:</strong> 71 Stunden pro Monat eingespart. Agent in 5 Wochen produktiv. Quellcode, Regelwerk und Prompts beim Kunden. Nach 14 Monaten Eigenbetrieb ohne externe Unterstützung.</p>
</div>
</div>
</div>
</section>

<!-- Vertiefung im Agent Briefing -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Vertiefung im Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Unsere Fachartikel-Serie für Entscheider, die AI Agents im Unternehmen einführen.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/de/magazin/ki-kosten-tco-vergleich/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Kosten</p>
<p class="text-body font-semibold text-gosign-dark">Was KI wirklich kostet: TCO-Vergleich für Unternehmen</p>
</a>
<a href="/de/magazin/modell-agnostik-vendor-lock-in/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Architektur</p>
<p class="text-body font-semibold text-gosign-dark">Modell-agnostische Architektur - Warum Vendor Lock-in bei LLMs gefährlich ist</p>
</a>
<a href="/de/magazin/decision-layer-erklaert/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - Was ist das und warum braucht jeder Enterprise AI Agent einen?</p>
</a>
</div>
</div>
</section>

<!-- Andere Agent-Typen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Andere Agent-Typen</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/de/leistungen/ai-agents/document-agents/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Der Spezialist</p>
<p class="text-body font-semibold text-gosign-dark">Document Agents</p>
<p class="text-body text-gosign-text-light mt-2">Dokumente lesen, verstehen und klassifizieren - mit echtem Sprachverständnis.</p>
</a>
<a href="/de/leistungen/ai-agents/workflow-agents/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Der Koordinator</p>
<p class="text-body font-semibold text-gosign-dark">Workflow Agents</p>
<p class="text-body text-gosign-text-light mt-2">Prozesse systemübergreifend orchestrieren - SAP, DATEV, SharePoint.</p>
</a>
<a href="/de/leistungen/ai-agents/knowledge-agents/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Der Wissensträger</p>
<p class="text-body font-semibold text-gosign-dark">Knowledge Agents</p>
<p class="text-body text-gosign-text-light mt-2">Fragen aus Regelwerken beantworten - mit Quellenangabe und Regelversion.</p>
</a>
</div>
</div>
</section>

--- Document Agents - Dokumentenverarbeitung mit Decision Layer ---
> Document Agents lesen, verstehen und verarbeiten Enterprise-Dokumente. Rechnungen, Krankmeldungen, Verträge - auditierbar, mit Audit Trail.

<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="AI-Agenten Navigation">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/de/leistungen/ai-agents/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
AI-Agenten
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/de/leistungen/ai-agents/document-agents/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Document</a>
<a href="/de/leistungen/ai-agents/workflow-agents/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Workflow</a>
<a href="/de/leistungen/ai-agents/knowledge-agents/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Knowledge</a>
<a href="/de/leistungen/ai-agents/co-build/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Co-Build</a>
</div>
</div>
</nav>

<!-- Auf einen Blick -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h2 font-bold text-gosign-dark">Auf einen Blick</h2>
<div class="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-3 gap-4 mt-6">
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">99,1% vollautomatisch</p>
<p class="text-body text-gosign-text-light mt-1">Routinedokumente autonom verarbeitet - ohne manuelle Nachbearbeitung</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">20+ Dokumenttypen</p>
<p class="text-body text-gosign-text-light mt-1">Rechnungen, Verträge, Krankmeldungen, Bescheide, Belege und mehr</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Echtes Verständnis</p>
<p class="text-body text-gosign-text-light mt-1">Kontextuelles Sprachverständnis statt OCR-Template-Matching</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Decision Layer</p>
<p class="text-body text-gosign-text-light mt-1">Jede Extraktion mit Confidence Score, Regelversion und Audit Trail</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Modell-agnostisch</p>
<p class="text-body text-gosign-text-light mt-1">Claude, ChatGPT, Gemini, Llama - Modell austauschbar</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">SAP, DATEV, Workday</p>
<p class="text-body text-gosign-text-light mt-1">Integration über APIs - Agent-Logik vom Zielsystem entkoppelt</p>
</div>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Definition: Document Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Ein Document Agent ist ein spezialisierter AI Agent für die automatische Verarbeitung von Enterprise-Dokumenten. Er nutzt Large Language Models (LLMs) für kontextuelles Sprachverständnis - nicht Template-Matching, nicht starre OCR-Regeln.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Der Document Agent liest ein Dokument, versteht seinen Inhalt und trifft eine fachliche Bewertung. Diese Bewertung wird über den <a href="/de/decision-layer/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Decision Layer</a> geprüft, dokumentiert und in den Audit Trail geschrieben.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Was Document Agents verarbeiten</h2>
<ul class="mt-6 space-y-3">
<li class="text-body-lg text-gosign-text-light">Eingangsrechnungen und Gutschriften</li>
<li class="text-body-lg text-gosign-text-light">Krankmeldungen und ärztliche Bescheinigungen</li>
<li class="text-body-lg text-gosign-text-light">Arbeitsverträge und Vertragsänderungen</li>
<li class="text-body-lg text-gosign-text-light">Bescheinigungen und Nachweise</li>
<li class="text-body-lg text-gosign-text-light">Belege, Quittungen und Reisekostenabrechnungen</li>
<li class="text-body-lg text-gosign-text-light">Steuerbescheide und Behördenschreiben</li>
</ul>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Wie eine Entscheidung entsteht</h2>
<pre class="bg-gosign-dark text-white p-6 rounded-card overflow-x-auto text-small font-mono leading-relaxed mt-6"><code>Dokument    →  Agent liest     →  Decision Layer prüft
(Rechnung)     und versteht       Vollständigkeit, Plausibilität,
Steuerklassifikation
│
┌────────────┴────────────┐
│                         │
Hohe Confidence           Niedrige Confidence
Regel eindeutig          oder Ausnahmefall
│                         │
Buchungsvorschlag         Eskalation an
+ Audit Trail            Sachbearbeiter</code></pre>
<p class="text-body-lg text-gosign-text-light mt-4">
Bei hoher Confidence und eindeutiger Regelanwendung: autonome Verarbeitung mit vollständigem Audit Trail. Bei niedriger Confidence, Ausnahmefällen oder fehlenden Informationen: Eskalation an einen Sachbearbeiter - mit dem gesamten Kontext, den der Agent bereits extrahiert hat. In Kombination mit einem <a href="/de/leistungen/ai-agents/workflow-agents/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Workflow Agent</a> wird der gesamte Prozess End-to-End orchestriert.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Decision Layer für Dokumente</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Jede Dokumentenverarbeitung erzeugt einen vollständigen Entscheidungsdatensatz:
</p>
<ul class="mt-6 space-y-3">
<li class="text-body-lg text-gosign-text-light"><strong>Input:</strong> Dokument-Hash, Dokumenttyp, extrahierte Felder</li>
<li class="text-body-lg text-gosign-text-light"><strong>Regelwerk:</strong> Angewandte Regel, Version, Timestamp</li>
<li class="text-body-lg text-gosign-text-light"><strong>Bewertung:</strong> Confidence Score, Risiko-Score</li>
<li class="text-body-lg text-gosign-text-light"><strong>Ergebnis:</strong> Buchungsvorschlag oder Eskalation</li>
<li class="text-body-lg text-gosign-text-light"><strong>Routing:</strong> Autonome Entscheidung oder Human-in-the-Loop</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-4">
Der Document Agent ersetzt keine Sachbearbeiter. Er verarbeitet die Routinefälle autonom und eskaliert Ausnahmefälle an Menschen - mit vollständiger Dokumentation. Mehr zum <a href="/de/decision-layer/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Decision Layer Architekturprinzip</a>.
</p>
</div>
</section>

<!-- Vergleich: Document Agent vs. klassische Lösung -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Document Agent vs. OCR vs. manuell</h2>
<div class="overflow-x-auto mt-6">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-dark">
<th class="py-3 pr-4 text-body font-bold text-gosign-dark"></th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Document Agent</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">OCR-System</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Manuelle Bearbeitung</th>
</tr>
</thead>
<tbody class="text-body text-gosign-text-light">
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Verständnis</td>
<td class="py-3 px-4">Kontextuell - versteht Inhalt und Bedeutung</td>
<td class="py-3 px-4">Zeichenerkennung + Template-Matching</td>
<td class="py-3 px-4">Volle kognitive Leistung</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Freitext / Handschrift</td>
<td class="py-3 px-4">Ja - echtes Sprachverständnis</td>
<td class="py-3 px-4">Eingeschränkt - bricht bei Abweichungen</td>
<td class="py-3 px-4">Ja</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Geschwindigkeit</td>
<td class="py-3 px-4">Sekunden pro Dokument</td>
<td class="py-3 px-4">Sekunden, aber oft Nachbearbeitung</td>
<td class="py-3 px-4">5-10 Minuten pro Dokument</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Skalierung</td>
<td class="py-3 px-4">Linear mit Volumen</td>
<td class="py-3 px-4">Linear, aber manuell bei Fehlern</td>
<td class="py-3 px-4">Nur mit mehr Personal</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Audit Trail</td>
<td class="py-3 px-4">Automatisch pro Entscheidung</td>
<td class="py-3 px-4">Begrenzt</td>
<td class="py-3 px-4">Manuell, oft lückenhaft</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Praxis-Szenario -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Praxis: Eingangsrechnungen</h2>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6 mt-6">
<p class="font-semibold text-gosign-dark text-body">Szenario: 500 Eingangsrechnungen pro Monat</p>
<div class="grid grid-cols-1 sm:grid-cols-2 gap-6 mt-4">
<div>
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-text-light mb-2">Vorher (manuell)</p>
<ul class="space-y-1 text-body text-gosign-text-light">
<li>8 Minuten pro Rechnung (Sichtung, Kontierung, Prüfung)</li>
<li>~67 Stunden pro Monat</li>
<li>Fehlerquote bei Kontierung: 4-6%</li>
<li>Audit Trail: Excel-Liste, manuell gepflegt</li>
</ul>
</div>
<div>
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Nachher (Document Agent)</p>
<ul class="space-y-1 text-body text-gosign-text-light">
<li>99,1% autonom verarbeitet (495 von 500 Rechnungen)</li>
<li>&lt;1% an Sachbearbeiter eskaliert (~5 Rechnungen/Monat)</li>
<li>98% aller Rückfragen mit dem Belegeinsender selbständig geklärt</li>
<li>&lt;0,5h manueller Aufwand pro Monat</li>
<li>Fehlerquote: unter 0,3% (regelbasierte Kontierung)</li>
</ul>
</div>
</div>
<p class="text-body text-gosign-text-light mt-4">
<strong>Ergebnis:</strong> Von 67 Stunden auf unter 30 Minuten pro Monat. Der Agent kontiert, prüft und bucht autonom. Bei fehlenden Angaben (z.B. Bestellnummer, Kostenstelle) fragt der Agent selbständig beim Belegeinsender nach - 98% dieser Rückfragen werden ohne menschliches Eingreifen gelöst. Nur echte Ausnahmen landen beim Sachbearbeiter.
</p>
<div class="mt-4 bg-gosign-light border-l-4 border-gosign-accent rounded-card p-4">
<p class="text-small font-semibold text-gosign-dark">Human-in-the-Loop</p>
<p class="text-small text-gosign-text-light mt-1"><strong>Agent entscheidet:</strong> Kontierung, Buchungsvorschlag, Zahlungsbedingungen, Rückfragen an Belegeinsender.<br/><strong>Mensch entscheidet:</strong> Erstmalige Lieferanten-Freigabe, Rechnungen über Freigabe-Schwellenwert, Abweichungen von Bestellwert &gt;5%.</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Einsatzbereiche</h2>
<div class="mt-6 space-y-6">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Finance & Accounting</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Rechnungsverarbeitung, Kontierung, Belegprüfung. Integration mit <a href="https://www.datev.de/" target="_blank" rel="noopener noreferrer">DATEV</a> und SAP FI/CO. Vorkonfigurierte Lösung: <a href="/de/finance-ai-agents/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Finance AI Agents</a>.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">HR & People Operations</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Krankmeldungen, Vertragsdokumente, Bescheinigungen. Integration mit <a href="https://www.sap.com/products/hcm.html" target="_blank" rel="noopener noreferrer">SAP SuccessFactors</a> und <a href="https://www.workday.com/" target="_blank" rel="noopener noreferrer">Workday</a>. Vorkonfigurierte Lösung: <a href="/de/hr-ai-agents/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">HR AI Agents</a>.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Compliance & Audit</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Automatische Prüfung eingehender Dokumente gegen interne Richtlinien und externe Regulierungen. Der <a href="/de/decision-layer/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Decision Layer</a> dokumentiert jede Prüfentscheidung.
</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Integration</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Document Agents sind über standardisierte Schnittstellen an bestehende Systeme angebunden:
</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light">SAP FI/CO, SAP S/4HANA</li>
<li class="text-body-lg text-gosign-text-light">DATEV</li>
<li class="text-body-lg text-gosign-text-light">SAP SuccessFactors, Workday</li>
<li class="text-body-lg text-gosign-text-light">SharePoint, Microsoft Teams</li>
<li class="text-body-lg text-gosign-text-light">E-Mail-Eingänge (IMAP/Exchange)</li>
<li class="text-body-lg text-gosign-text-light">Weitere über REST/SOAP</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-4">
Die Agent-Logik ist vom Zielsystem entkoppelt. Ein Wechsel des ERP-Systems ändert die Exportschicht - nicht den Agenten. Sie haben einen Prozess, der keinen der drei Standard-Agent-Typen abdeckt? <a href="/de/leistungen/ai-agents/co-build/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Co-Build</a> liefert individuelle Agenten in 4-6 Wochen.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Andere Agent-Typen</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/de/leistungen/ai-agents/workflow-agents/" class="group block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Der Koordinator</p>
<p class="text-body font-semibold text-gosign-dark">Workflow Agents</p>
<p class="text-body text-gosign-text-light mt-2">Prozesse systemübergreifend orchestrieren - SAP, DATEV, SharePoint.</p>
<span class="inline-flex items-center gap-1 mt-4 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Details <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
<a href="/de/leistungen/ai-agents/knowledge-agents/" class="group block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Der Wissensträger</p>
<p class="text-body font-semibold text-gosign-dark">Knowledge Agents</p>
<p class="text-body text-gosign-text-light mt-2">Fragen aus Regelwerken beantworten - mit Quellenangabe und Regelversion.</p>
<span class="inline-flex items-center gap-1 mt-4 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Details <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
<a href="/de/leistungen/ai-agents/co-build/" class="group block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Individuelle Agenten</p>
<p class="text-body font-semibold text-gosign-dark">Co-Build</p>
<p class="text-body text-gosign-text-light mt-2">Ihr Prozess, Ihr Agent. 4-6 Wochen bis zum produktiven Agenten.</p>
<span class="inline-flex items-center gap-1 mt-4 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Details <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Vertiefung im Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Unsere Fachartikel-Serie für Entscheider, die AI Agents im Unternehmen einführen.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/de/magazin/rag-document-intelligence-enterprise/" class="group block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">RAG &amp; Document Intelligence: Wie KI Ihre Dokumente versteht</p>
<span class="inline-flex items-center gap-1 mt-3 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Lesen <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
<a href="/de/magazin/pii-anonymisierung-llm-enterprise/" class="group block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">PII-Anonymisierung für Enterprise AI</p>
<span class="inline-flex items-center gap-1 mt-3 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Lesen <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
<a href="/de/magazin/decision-layer-erklaert/" class="group block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - Was ist das und warum braucht jeder Enterprise AI Agent einen?</p>
<span class="inline-flex items-center gap-1 mt-3 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Lesen <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
</div>
</div>
</section>

--- Knowledge Agents - Antworten aus Unternehmenswissen ---
> Knowledge Agents liefern kontextbasierte Antworten aus Betriebsvereinbarungen, Richtlinien und Tarifverträgen. Mit Quellenangabe, Regelversion und Audit Trail.

<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="AI-Agenten Navigation">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/de/leistungen/ai-agents/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
AI-Agenten
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/de/leistungen/ai-agents/document-agents/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Document</a>
<a href="/de/leistungen/ai-agents/workflow-agents/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Workflow</a>
<a href="/de/leistungen/ai-agents/knowledge-agents/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Knowledge</a>
<a href="/de/leistungen/ai-agents/co-build/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Co-Build</a>
</div>
</div>
</nav>

<!-- Auf einen Blick -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h2 font-bold text-gosign-dark">Auf einen Blick</h2>
<div class="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-3 gap-4 mt-6">
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Quellenverifiziert</p>
<p class="text-body text-gosign-text-light mt-1">Jede Antwort mit Quellenangabe, Regelversion und Gültigkeitsdatum</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">5 Anti-Halluzination</p>
<p class="text-body text-gosign-text-light mt-1">Retrieval-First, Quellenprüfung, Confidence, keine Spekulation, Audit Trail</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">4 Kanäle</p>
<p class="text-body text-gosign-text-light mt-1">Teams Bot, SharePoint, Web-Interface, API - dort wo Ihre Mitarbeiter arbeiten</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">RAG-Pipeline</p>
<p class="text-body text-gosign-text-light mt-1">Versionierte Indexierung aller Wissensquellen mit automatischem Update</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Decision Layer</p>
<p class="text-body text-gosign-text-light mt-1">Confidence Scoring und Routing - bei Unsicherheit Verweis statt Antwort</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Sofortige Antwort</p>
<p class="text-body text-gosign-text-light mt-1">Sekunden statt Stunden - konsistent über alle Standorte und Zeitzonen</p>
</div>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Definition: Knowledge Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Ein Knowledge Agent ist ein spezialisierter AI Agent, der kontextbasierte Antworten aus dem Unternehmenswissen liefert. Er nutzt eine RAG-Pipeline (Retrieval-Augmented Generation), um aus hinterlegten Dokumenten die relevante Information zu finden und im korrekten Kontext zu beantworten.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Zentrale Eigenschaft: Jede Antwort enthält die Quellenangabe und die Regelversion. Ein Knowledge Agent beantwortet keine Frage ohne Quellenreferenz.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Beispiel</h2>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6 mt-6">
<p class="text-body text-gosign-text-light">
<strong>Frage:</strong> „Wie viele Tage Sonderurlaub habe ich bei Umzug?"
</p>
<p class="text-body text-gosign-text-light mt-4">
<strong>Antwort:</strong> „Gemäß Betriebsvereinbarung BV-2024-007, § 3 Abs. 2 (Version 2024.2, gültig seit 01.04.2024) stehen Ihnen bei Umzug 2 Arbeitstage Sonderurlaub zu. Für tarifgebundene Mitarbeiter gilt zusätzlich § 29 TV-L, der 1 weiteren Tag vorsieht."
</p>
<ul class="mt-4 space-y-1">
<li class="text-body text-gosign-text-light">Quelle wird mitgeliefert</li>
<li class="text-body text-gosign-text-light">Regelversion wird dokumentiert</li>
<li class="text-body text-gosign-text-light">Bei Interpretationsspielraum: Verweis an HR</li>
</ul>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Wissensquellen</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Knowledge Agents arbeiten mit folgenden Dokumenttypen:
</p>
<ul class="mt-6 space-y-3">
<li class="text-body-lg text-gosign-text-light"><strong>Betriebsvereinbarungen</strong> - versioniert, mit Gültigkeitszeitraum</li>
<li class="text-body-lg text-gosign-text-light"><strong>Tarifverträge</strong> - pro Region, pro Entität</li>
<li class="text-body-lg text-gosign-text-light"><strong>Interne Richtlinien</strong> - Travel Policy, Expense Policy, IT Policy</li>
<li class="text-body-lg text-gosign-text-light"><strong>Compliance-Handbücher</strong> - regulatorische Anforderungen</li>
<li class="text-body-lg text-gosign-text-light"><strong>FAQ-Kataloge</strong> - häufig gestellte Fragen mit geprüften Antworten</li>
<li class="text-body-lg text-gosign-text-light"><strong>Prozessdokumentationen</strong> - Standard Operating Procedures</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-4">
Alle Dokumente werden über eine RAG-Pipeline indexiert. Bei Versionswechsel wird die neue Version indexiert und die alte archiviert. Der Agent weiß immer, welche Version aktuell gültig ist.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Architektonische Sicherheit gegen Halluzination</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Knowledge Agents sind so konstruiert, dass das Halluzinationsrisiko architektonisch minimiert wird:
</p>
<ol class="mt-6 space-y-3 list-decimal list-inside">
<li class="text-body-lg text-gosign-text-light"><strong>Retrieval-First:</strong> Der Agent sucht zuerst die relevanten Dokumente, bevor er antwortet</li>
<li class="text-body-lg text-gosign-text-light"><strong>Quellenprüfung:</strong> Jede Aussage muss auf eine konkrete Quelle zurückführbar sein</li>
<li class="text-body-lg text-gosign-text-light"><strong>Confidence Score:</strong> Bei niedriger Confidence wird nicht geantwortet, sondern verwiesen</li>
<li class="text-body-lg text-gosign-text-light"><strong>Keine Spekulation:</strong> Bei fehlender oder widersprüchlicher Regelung verweist der Agent an die zuständige Stelle</li>
<li class="text-body-lg text-gosign-text-light"><strong>Audit Trail:</strong> Jede Antwort wird mit Quelle, Version und Confidence dokumentiert</li>
</ol>
</div>
</section>

<!-- Vergleich: Knowledge Agent vs. klassische Lösung -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Knowledge Agent vs. Suchmaschine vs. Chatbot</h2>
<div class="overflow-x-auto mt-6">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-dark">
<th class="py-3 pr-4 text-body font-bold text-gosign-dark"></th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Knowledge Agent</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Enterprise-Suchmaschine</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Standard-Chatbot</th>
</tr>
</thead>
<tbody class="text-body text-gosign-text-light">
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Ergebnis</td>
<td class="py-3 px-4">Spezifische Antwort mit Quelle</td>
<td class="py-3 px-4">Liste von Dokumenten</td>
<td class="py-3 px-4">Generierte Antwort ohne Quellengarantie</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Quellenangabe</td>
<td class="py-3 px-4">Immer - mit Version und Gültigkeit</td>
<td class="py-3 px-4">Link zum Dokument</td>
<td class="py-3 px-4">Keine oder unzuverlässig</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Halluzination</td>
<td class="py-3 px-4">Architektonisch verhindert (5 Maßnahmen)</td>
<td class="py-3 px-4">Nicht anwendbar</td>
<td class="py-3 px-4">Häufig - keine Kontrolle</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Bei Unsicherheit</td>
<td class="py-3 px-4">Verweist an zuständige Stelle</td>
<td class="py-3 px-4">Zeigt mehr Ergebnisse</td>
<td class="py-3 px-4">Gibt trotzdem eine Antwort</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Audit Trail</td>
<td class="py-3 px-4">Vollständig pro Antwort</td>
<td class="py-3 px-4">Suchprotokoll</td>
<td class="py-3 px-4">Chat-Historie</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Praxis-Szenario -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Praxis: HR-Anfragen</h2>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6 mt-6">
<p class="font-semibold text-gosign-dark text-body">Szenario: 200 HR-Anfragen pro Monat (Urlaubsansprüche, Sonderregelungen, Betriebsvereinbarungen)</p>
<div class="grid grid-cols-1 sm:grid-cols-2 gap-6 mt-4">
<div>
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-text-light mb-2">Vorher (manuell)</p>
<ul class="space-y-1 text-body text-gosign-text-light">
<li>15 Minuten pro Anfrage (HR recherchiert, prüft BV, antwortet)</li>
<li>~50 Stunden pro Monat</li>
<li>Inkonsistente Antworten je nach Bearbeiter</li>
<li>Wartezeit für Mitarbeiter: Stunden bis Tage</li>
</ul>
</div>
<div>
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Nachher (Knowledge Agent)</p>
<ul class="space-y-1 text-body text-gosign-text-light">
<li>78% sofort beantwortet (156 Anfragen) - Sekunden statt Stunden</li>
<li>22% an HR eskaliert (44 komplexe Fälle) - mit Kontext</li>
<li>~11 Stunden pro Monat (nur Eskalationen)</li>
<li>100% konsistente Regelinterpretation</li>
</ul>
</div>
</div>
<p class="text-body text-gosign-text-light mt-4">
<strong>Ergebnis:</strong> 39 Stunden pro Monat eingespart. Mitarbeiter erhalten sofort eine verifizierte Antwort. HR konzentriert sich auf die komplexen Fälle, die echtes Ermessen erfordern.
</p>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Einsatzbereiche</h2>
<div class="mt-6 space-y-6">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">HR & People Operations</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Fragen zu Betriebsvereinbarungen, Urlaubsansprüchen, Sonderregelungen, Elternzeit, Weiterbildungsbudgets. Ersatz für das „Frag mal Frau Müller"-Prinzip.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Compliance & Regulierung</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Fragen zu internen Richtlinien, regulatorischen Anforderungen, Exportkontrolle, Datenschutz. Konsistente Antworten statt individueller Interpretation.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Onboarding</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Neue Mitarbeiter erhalten sofort Zugang zum relevanten Unternehmenswissen - ohne auf verfügbare Kollegen warten zu müssen.
</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Integration</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Knowledge Agents sind über folgende Kanäle erreichbar:
</p>
<ul class="mt-4 space-y-3">
<li class="text-body-lg text-gosign-text-light"><strong>Microsoft Teams Bot</strong> - direkt im Arbeitsalltag</li>
<li class="text-body-lg text-gosign-text-light"><strong>SharePoint-Integration</strong> - eingebettet in das Intranet</li>
<li class="text-body-lg text-gosign-text-light"><strong>Web-Interface</strong> - standalone für komplexe Anfragen</li>
<li class="text-body-lg text-gosign-text-light"><strong>API</strong> - für Integration in eigene Anwendungen</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-4">
Die Wissensbasis wird über SharePoint, Confluence oder direkte Dokumenten-Uploads gepflegt.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Andere Agent-Typen</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/de/leistungen/ai-agents/document-agents/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Der Spezialist</p>
<p class="text-body font-semibold text-gosign-dark">Document Agents</p>
<p class="text-body text-gosign-text-light mt-2">Dokumente lesen, verstehen und klassifizieren - mit echtem Sprachverständnis.</p>
</a>
<a href="/de/leistungen/ai-agents/workflow-agents/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Der Koordinator</p>
<p class="text-body font-semibold text-gosign-dark">Workflow Agents</p>
<p class="text-body text-gosign-text-light mt-2">Prozesse systemübergreifend orchestrieren - SAP, DATEV, SharePoint.</p>
</a>
<a href="/de/leistungen/ai-agents/co-build/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Individuelle Agenten</p>
<p class="text-body font-semibold text-gosign-dark">Co-Build</p>
<p class="text-body text-gosign-text-light mt-2">Ihr Prozess, Ihr Agent. 4-6 Wochen bis zum produktiven Agenten.</p>
</a>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Vertiefung im Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Unsere Fachartikel-Serie für Entscheider, die AI Agents im Unternehmen einführen.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/de/magazin/rag-document-intelligence-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">RAG &amp; Document Intelligence: Wie KI Ihre Dokumente versteht</p>
</a>
<a href="/de/magazin/human-in-the-loop-architektur/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Human-in-the-Loop - Architekturprinzip, nicht Checkbox</p>
</a>
<a href="/de/magazin/decision-layer-erklaert/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - Was ist das und warum braucht jeder Enterprise AI Agent einen?</p>
</a>
</div>
</div>
</section>

--- Workflow Agents - Systemübergreifende Prozessorchestrierung ---
> Workflow Agents orchestrieren Enterprise-Prozesse systemübergreifend. SAP, DATEV, Workday - ein Agent koordiniert. Audit Trail inklusive.

<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="AI-Agenten Navigation">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/de/leistungen/ai-agents/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
AI-Agenten
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/de/leistungen/ai-agents/document-agents/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Document</a>
<a href="/de/leistungen/ai-agents/workflow-agents/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Workflow</a>
<a href="/de/leistungen/ai-agents/knowledge-agents/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Knowledge</a>
<a href="/de/leistungen/ai-agents/co-build/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Co-Build</a>
</div>
</div>
</nav>

<!-- Auf einen Blick -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h2 font-bold text-gosign-dark">Auf einen Blick</h2>
<div class="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-3 gap-4 mt-6">
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">5+ Systeme</p>
<p class="text-body text-gosign-text-light mt-1">SAP, DATEV, Workday, SharePoint, AD - ein Agent koordiniert alles</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Pausierbar</p>
<p class="text-body text-gosign-text-light mt-1">Workflow hält an wenn der Mensch entscheiden muss - und setzt danach fort</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Idempotent</p>
<p class="text-body text-gosign-text-light mt-1">Jeder Schritt wiederholbar ohne Seiteneffekte - kein doppeltes Buchen</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Decision Layer</p>
<p class="text-body text-gosign-text-light mt-1">An jedem Entscheidungspunkt: autonom oder Human-in-the-Loop</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">API-basiert</p>
<p class="text-body text-gosign-text-light mt-1">Keine GUI-Automation - stabile Integration über Schnittstellen</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Audit Trail</p>
<p class="text-body text-gosign-text-light mt-1">Jeder Schritt mit Timestamp, Regel, Version und Routing-Entscheidung</p>
</div>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Definition: Workflow Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Ein Workflow Agent ist ein spezialisierter AI Agent für die systemübergreifende Orchestrierung von Enterprise-Prozessen. Er koordiniert Aufgaben zwischen mehreren Systemen - inklusive Eskalation, Genehmigungslogik und Ausnahmebehandlung.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Im Unterschied zu RPA (Robotic Process Automation) arbeitet der Workflow Agent nicht auf der Oberfläche von Anwendungen, sondern über APIs und versteht den fachlichen Kontext der Entscheidungen, die er koordiniert.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Wie ein Workflow Agent arbeitet</h2>
<h3 class="text-h3 font-bold text-gosign-dark mt-6">Beispiel: Krankmeldung</h3>
<pre class="bg-gosign-dark text-white p-6 rounded-card overflow-x-auto text-small font-mono leading-relaxed mt-4"><code>Eingang          →  Document Agent     →  Decision Layer
(E-Mail mit         liest Krankmeldung    prüft § 5 EFZG
Anhang)            und extrahiert        und BV-Constraints
Daten                      │
┌──────────┴──────────┐
│                     │
Regelkonform            Rückfrage nötig
│                     │
Lohnfortzahlung        HR-Sachbearbeiter
berechnen              wird informiert
│                     │
SAP-Buchung             Wartet auf
vorschlagen             Entscheidung
│                     │
Audit Trail             Audit Trail
dokumentiert            dokumentiert</code></pre>
<p class="text-body-lg text-gosign-text-light mt-4">
Jeder Schritt wird geloggt. Jede Entscheidung ist nachvollziehbar. Bei Rückfragen oder fehlenden Informationen wird der Workflow pausiert - nicht abgebrochen.
</p>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Orchestrierungsprinzipien</h2>
<ul class="mt-6 space-y-4">
<li class="text-body-lg text-gosign-text-light"><strong>Systemübergreifend:</strong> Ein Workflow kann SAP, DATEV, SharePoint, E-Mail und weitere Systeme in einem Ablauf koordinieren</li>
<li class="text-body-lg text-gosign-text-light"><strong>Entscheidungsbasiert:</strong> Der Workflow Agent trifft fachliche Entscheidungen, nicht nur Wenn-Dann-Regeln</li>
<li class="text-body-lg text-gosign-text-light"><strong>Pausierbar:</strong> Bei fehlenden Informationen oder nötigen menschlichen Entscheidungen wird pausiert, dokumentiert, und nach Klärung fortgesetzt</li>
<li class="text-body-lg text-gosign-text-light"><strong>Auditierbar:</strong> Jeder Schritt erzeugt einen Eintrag im Audit Trail - inklusive Wartezeiten und Eskalationen</li>
<li class="text-body-lg text-gosign-text-light"><strong>Idempotent:</strong> Jeder Schritt kann wiederholt ausgeführt werden ohne Seiteneffekte</li>
</ul>
</div>
</section>

<!-- Vergleich: Workflow Agent vs. klassische Lösung -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Workflow Agent vs. RPA vs. manuell</h2>
<div class="overflow-x-auto mt-6">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-dark">
<th class="py-3 pr-4 text-body font-bold text-gosign-dark"></th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Workflow Agent</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">RPA-Bot</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Manuelle Koordination</th>
</tr>
</thead>
<tbody class="text-body text-gosign-text-light">
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Steuerung</td>
<td class="py-3 px-4">APIs + fachliche Entscheidungen</td>
<td class="py-3 px-4">GUI-Klicks auf Oberflächen</td>
<td class="py-3 px-4">E-Mail, Telefon, Tickets</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Stabilität</td>
<td class="py-3 px-4">API-Verträge - unabhängig von UI-Änderungen</td>
<td class="py-3 px-4">Bricht bei UI-Änderungen</td>
<td class="py-3 px-4">Abhängig von Personen</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Entscheidungsfähigkeit</td>
<td class="py-3 px-4">Fachliche Entscheidungen auf Basis von Regelwerken</td>
<td class="py-3 px-4">Nur Wenn-Dann-Regeln</td>
<td class="py-3 px-4">Volle Entscheidungsfähigkeit</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Unterbrechung</td>
<td class="py-3 px-4">Pausiert, wartet, setzt fort</td>
<td class="py-3 px-4">Bricht ab - Neustart nötig</td>
<td class="py-3 px-4">Wartet - oft ohne Dokumentation</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Audit Trail</td>
<td class="py-3 px-4">Automatisch pro Schritt</td>
<td class="py-3 px-4">Screenshot-basiert</td>
<td class="py-3 px-4">Manuell, lückenhaft</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Praxis-Szenario -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Praxis: Onboarding-Prozess</h2>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6 mt-6">
<p class="font-semibold text-gosign-dark text-body">Szenario: 20 neue Mitarbeiter pro Monat</p>
<div class="grid grid-cols-1 sm:grid-cols-2 gap-6 mt-4">
<div>
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-text-light mb-2">Vorher (manuell)</p>
<ul class="space-y-1 text-body text-gosign-text-light">
<li>3 Arbeitstage pro Onboarding</li>
<li>5 Systeme manuell aktualisiert (SAP, AD, E-Mail, Zeitwirtschaft, Zutrittskontrolle)</li>
<li>Fehlerquote: 12% (fehlende Berechtigungen, falsche Kostenstelle)</li>
<li>HR-Aufwand: 60 Stunden pro Monat</li>
</ul>
</div>
<div>
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Nachher (Workflow Agent)</p>
<ul class="space-y-1 text-body text-gosign-text-light">
<li>4 Stunden pro Onboarding (inkl. manuelle Freigaben)</li>
<li>5 Systeme automatisch provisioniert über APIs</li>
<li>Fehlerquote: unter 2% (Regelwerk-basierte Zuordnung)</li>
<li>HR-Aufwand: 15 Stunden pro Monat</li>
</ul>
</div>
</div>
<p class="text-body text-gosign-text-light mt-4">
<strong>Ergebnis:</strong> 75% weniger Aufwand, 85% weniger Fehler. Der Workflow Agent koordiniert alle Systeme und pausiert nur dort, wo menschliche Freigabe nötig ist - mit vollständigem Audit Trail.
</p>
</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Einsatzbereiche</h2>
<div class="mt-6 space-y-6">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">HR-Prozesse</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Onboarding (Vertrag, IT-Provisionierung, Einarbeitung), Krankmeldungen, Vertragsänderungen, Austrittsprozesse. Orchestriert über <a href="https://www.sap.com/products/hcm.html" target="_blank" rel="noopener noreferrer">SAP SuccessFactors</a>, <a href="https://www.workday.com/" target="_blank" rel="noopener noreferrer">Workday</a>, Active Directory und E-Mail.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Finance-Prozesse</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Rechnungseingang, Prüfung, Kontierung, Freigabe, Buchung. Orchestriert über <a href="https://www.datev.de/" target="_blank" rel="noopener noreferrer">DATEV</a>, SAP FI/CO und Bankschnittstellen.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Compliance-Prozesse</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Automatische Prüfung gegen Richtlinien, Eskalation bei Abweichungen, Dokumentation im Audit Trail.
</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Decision Layer im Workflow</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Jeder Workflow-Schritt, der eine Entscheidung beinhaltet, wird über den Decision Layer geroutet:
</p>
<ul class="mt-6 space-y-3">
<li class="text-body-lg text-gosign-text-light"><strong>Fachliche Prüfung:</strong> Regelwerk-Check pro Entscheidungsschritt</li>
<li class="text-body-lg text-gosign-text-light"><strong>Routing:</strong> Autonome Fortführung oder Eskalation an einen Menschen</li>
<li class="text-body-lg text-gosign-text-light"><strong>Dokumentation:</strong> Vollständiger Entscheidungsdatensatz pro Schritt</li>
<li class="text-body-lg text-gosign-text-light"><strong>Versionierung:</strong> Jede angewandte Regel mit Version und Timestamp</li>
</ul>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Integration</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Workflow Agents verbinden bestehende Systeme über standardisierte Schnittstellen:
</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light">SAP FI/CO, SAP S/4HANA, SAP SuccessFactors</li>
<li class="text-body-lg text-gosign-text-light">Workday</li>
<li class="text-body-lg text-gosign-text-light">DATEV</li>
<li class="text-body-lg text-gosign-text-light">SharePoint, Microsoft Teams (via <a href="https://learn.microsoft.com/en-us/graph/overview" target="_blank" rel="noopener noreferrer">Microsoft Graph</a>)</li>
<li class="text-body-lg text-gosign-text-light">Active Directory / Azure AD</li>
<li class="text-body-lg text-gosign-text-light">E-Mail (IMAP/Exchange)</li>
<li class="text-body-lg text-gosign-text-light">Weitere über REST/SOAP</li>
</ul>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Andere Agent-Typen</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/de/leistungen/ai-agents/document-agents/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Der Spezialist</p>
<p class="text-body font-semibold text-gosign-dark">Document Agents</p>
<p class="text-body text-gosign-text-light mt-2">Dokumente lesen, verstehen und klassifizieren - mit echtem Sprachverständnis.</p>
</a>
<a href="/de/leistungen/ai-agents/knowledge-agents/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Der Wissensträger</p>
<p class="text-body font-semibold text-gosign-dark">Knowledge Agents</p>
<p class="text-body text-gosign-text-light mt-2">Fragen aus Regelwerken beantworten - mit Quellenangabe und Regelversion.</p>
</a>
<a href="/de/leistungen/ai-agents/co-build/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Individuelle Agenten</p>
<p class="text-body font-semibold text-gosign-dark">Co-Build</p>
<p class="text-body text-gosign-text-light mt-2">Ihr Prozess, Ihr Agent. 4-6 Wochen bis zum produktiven Agenten.</p>
</a>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Vertiefung im Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Unsere Fachartikel-Serie für Entscheider, die AI Agents im Unternehmen einführen.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/de/magazin/agent-orchestrierung-plattformen/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">Agent-Orchestrierung: Trigger.dev, n8n, Camunda und Alternativen</p>
</a>
<a href="/de/magazin/ki-integration-it-landschaft/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">KI-Integration in bestehende IT-Landschaften - SAP, DATEV, Workday</p>
</a>
<a href="/de/magazin/decision-layer-erklaert/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - Was ist das und warum braucht jeder Enterprise AI Agent einen?</p>
</a>
</div>
</div>
</section>

--- AI-Agenten für Enterprise-Prozesse ---
> Document Agents, Workflow Agents und Knowledge Agents. Spezialisierte AI-Agenten mit Decision Layer, Audit Trail und Human-in-the-Loop.

<!-- Auf einen Blick -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h2 font-bold text-gosign-dark">Auf einen Blick</h2>
<div class="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-3 gap-4 mt-6">
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">3 Agent-Typen</p>
<p class="text-body text-gosign-text-light mt-1">Document, Workflow, Knowledge - jeder mit eigenem Decision Layer</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">4-6 Wochen</p>
<p class="text-body text-gosign-text-light mt-1">Vom Discover bis zum produktiven PoC in Ihrer Infrastruktur</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">85-92% vollautomatisch</p>
<p class="text-body text-gosign-text-light mt-1">Routinefälle autonom verarbeitet - Ausnahmen an Menschen eskaliert</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">7+ LLMs</p>
<p class="text-body text-gosign-text-light mt-1">Modell-agnostisch: Claude, ChatGPT, Gemini, Llama, Mistral, DeepSeek</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Voller Quellcode</p>
<p class="text-body text-gosign-text-light mt-1">Kein SaaS, kein Vendor Lock-in - voller Zugang zu Code, Prompts, Regelwerken</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">EU AI Act ready</p>
<p class="text-body text-gosign-text-light mt-1">Audit Trail, Human-in-the-Loop, Betriebsvereinbarungs-Constraints</p>
</div>
</div>
</div>
</div>
</section>

<!-- Governance-First Intro -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Einen Agent zu bauen ist einfach. Ihn Enterprise-fähig zu machen nicht.</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Workflow-Agenten lassen sich in Tagen prototypisieren. Das eigentliche Problem beginnt danach: Ist die Entscheidung des Agents auditierbar? Erfüllt sie die Anforderungen des EU AI Act? Kann der Betriebsrat nachvollziehen, nach welchen Regeln der Agent entscheidet?
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Genau hier setzen wir an. Nicht beim Bauen des Agents - sondern bei der Governance-Schicht, die ihn produktionsfähig, prüfbar und zertifizierbar macht. Enterprise-Prozesse basieren auf implizitem Wissen: Tarifverträge, Betriebsvereinbarungen, Buchungslogik. Ein AI Agent strukturiert diese Entscheidungen, dokumentiert sie und macht sie reproduzierbar - über alle Standorte und Bearbeiter hinweg.
</p>
</div>
</div>
</section>

<!-- Drei Agent-Typen: Übersicht + Vergleichstabelle -->
<section id="agent-typen" class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Drei Agent-Typen</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Jeder Geschäftsprozess lässt sich in drei Aufgaben zerlegen: Dokumente verstehen, Abläufe koordinieren und Wissen bereitstellen. Dafür gibt es drei spezialisierte Agent-Typen - jeder mit eigenem Decision Layer und eigenem Audit Trail.
</p>
</div>
<img src="/images/diagrams/agent-types-overview-de.svg" alt="Drei Agent-Typen: Document Agent (Der Spezialist), Workflow Agent (Der Koordinator), Knowledge Agent (Der Wissensträger)" class="w-full max-w-3xl mx-auto mt-8 mb-8" width="1200" height="400" loading="lazy" />
<div class="max-w-narrow">
<div class="overflow-x-auto mt-4">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-dark">
<th class="py-3 pr-4 text-body font-bold text-gosign-dark"></th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Document Agent</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Workflow Agent</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Knowledge Agent</th>
</tr>
</thead>
<tbody class="text-body text-gosign-text-light">
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Rolle</td>
<td class="py-3 px-4">Der Spezialist</td>
<td class="py-3 px-4">Der Koordinator</td>
<td class="py-3 px-4">Der Wissensträger</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Aufgabe</td>
<td class="py-3 px-4">Dokumente lesen, verstehen, klassifizieren</td>
<td class="py-3 px-4">Prozesse über Systemgrenzen orchestrieren</td>
<td class="py-3 px-4">Fragen aus Regelwerken beantworten</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Ersetzt</td>
<td class="py-3 px-4">OCR + Template-Matching</td>
<td class="py-3 px-4">RPA + manuelle Workflows</td>
<td class="py-3 px-4">Suchmaschine + Chatbot</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Beispiel</td>
<td class="py-3 px-4">Krankmeldung extrahieren und klassifizieren</td>
<td class="py-3 px-4">Onboarding über SAP, AD und E-Mail koordinieren</td>
<td class="py-3 px-4">Urlaubsanspruch mit Quellenangabe beantworten</td>
</tr>
</tbody>
</table>
</div>
</div>

<!-- Agent-Typ 1: Document Agents -->
<div class="max-w-narrow mt-12">
<div class="flex items-start gap-4">
<span class="text-5xl font-bold text-gosign-accent/20 leading-none before:content-['01']" aria-hidden="true"></span>
<div>
<h3 class="text-h2 font-bold text-gosign-dark">Document Agents</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Der Spezialist: versteht Dokumente mit echtem Sprachverständnis. Keine Template-Erkennung - kontextuelles Verständnis von Rechnungen, Krankmeldungen, Verträgen. Der Decision Layer bewertet jede Extraktion und routet bei niedriger Confidence an einen Sachbearbeiter.</p>
<div class="mt-4 bg-gosign-light border-l-4 border-gosign-accent rounded-card p-4">
<p class="text-small font-semibold text-gosign-dark">Human-in-the-Loop</p>
<p class="text-small text-gosign-text-light mt-1"><strong>Agent entscheidet:</strong> Standarddokumente mit hoher Confidence (Rechnung mit eindeutiger Kontierung, Krankmeldung mit klarem Zeitraum).<br/><strong>Mensch entscheidet:</strong> Mehrdeutige Dokumente, abweichende Beträge, erstmalige Lieferanten, Dokumente mit Freitextklauseln. Der Agent bereitet vor und empfiehlt - die finale Freigabe liegt beim Sachbearbeiter.</p>
</div>
</div>
</div>
<p class="mt-4">
<a href="/de/leistungen/ai-agents/document-agents/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-semibold transition-colors">
Document Agents im Detail
<svg class="w-5 h-5" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg>
</a>
</p>
</div>

<!-- Agent-Typ 2: Workflow Agents -->
<div class="max-w-narrow mt-10">
<div class="flex items-start gap-4">
<span class="text-5xl font-bold text-gosign-accent/20 leading-none before:content-['02']" aria-hidden="true"></span>
<div>
<h3 class="text-h2 font-bold text-gosign-dark">Workflow Agents</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Der Koordinator: orchestriert Prozesse systemübergreifend. SAP, DATEV, SharePoint, Active Directory - ein Agent koordiniert den gesamten Ablauf über APIs. Bei Rückfragen pausiert der Workflow, der Mensch entscheidet, und der Agent setzt exakt dort fort.</p>
<div class="mt-4 bg-gosign-light border-l-4 border-gosign-accent rounded-card p-4">
<p class="text-small font-semibold text-gosign-dark">Human-in-the-Loop</p>
<p class="text-small text-gosign-text-light mt-1"><strong>Agent entscheidet:</strong> Routing, Systembuchungen, Statusupdates, Benachrichtigungen - alles nach definierten Regeln im Decision Layer.<br/><strong>Mensch entscheidet:</strong> Personalentscheidungen (Einstellung, Kündigung, Versetzung), Budgetfreigaben über Schwellenwerten, Ausnahmen von Betriebsvereinbarungen. Der Workflow pausiert, bis der Mensch entschieden hat.</p>
</div>
</div>
</div>
<p class="mt-4">
<a href="/de/leistungen/ai-agents/workflow-agents/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-semibold transition-colors">
Workflow Agents im Detail
<svg class="w-5 h-5" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg>
</a>
</p>
</div>

<!-- Agent-Typ 3: Knowledge Agents -->
<div class="max-w-narrow mt-10">
<div class="flex items-start gap-4">
<span class="text-5xl font-bold text-gosign-accent/20 leading-none before:content-['03']" aria-hidden="true"></span>
<div>
<h3 class="text-h2 font-bold text-gosign-dark">Knowledge Agents</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Der Wissensträger: beantwortet Fragen aus dem Unternehmenswissen - Betriebsvereinbarungen, Tarifverträge, Richtlinien. Jede Antwort mit Quellenangabe und Regelversion. Ohne verifizierte Quelle keine Antwort - die Architektur verhindert Halluzination.</p>
<div class="mt-4 bg-gosign-light border-l-4 border-gosign-accent rounded-card p-4">
<p class="text-small font-semibold text-gosign-dark">Human-in-the-Loop</p>
<p class="text-small text-gosign-text-light mt-1"><strong>Agent entscheidet:</strong> Standardauskünfte mit eindeutiger Quellenlage (Urlaubsanspruch, Kündigungsfrist, Zuständigkeiten).<br/><strong>Mensch entscheidet:</strong> Auslegungsfragen bei widersprüchlichen Regelwerken, Einzelfallbewertungen, Fragen zu laufenden Verhandlungen. Bei Unsicherheit antwortet der Agent nicht, sondern eskaliert mit Kontext an den zuständigen Fachexperten.</p>
</div>
</div>
</div>
<p class="mt-4">
<a href="/de/leistungen/ai-agents/knowledge-agents/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-semibold transition-colors">
Knowledge Agents im Detail
<svg class="w-5 h-5" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg>
</a>
</p>
</div>
</div>
</section>

<!-- Zusammenspiel: Multi-Agent-System -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Zusammenspiel: Drei Agenten, ein Prozess</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
In der Praxis arbeiten die drei Agent-Typen zusammen. Ein Workflow Agent orchestriert den Gesamtprozess und ruft Document Agents und Knowledge Agents als Spezialisten auf.
</p>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6 mt-6">
<p class="font-semibold text-gosign-dark text-body">Beispiel: Krankmeldung End-to-End</p>
<ol class="mt-3 space-y-2 text-body text-gosign-text-light list-decimal list-inside">
<li><strong>Document Agent</strong> erkennt die Krankmeldung im E-Mail-Eingang, extrahiert Name, Zeitraum und Diagnose-Schlüssel.</li>
<li><strong>Workflow Agent</strong> prüft im HR-System: Ist es die dritte Meldung in sechs Monaten?</li>
<li><strong>Knowledge Agent</strong> wird aufgerufen: "Ab welcher Schwelle greift die BEM-Pflicht laut aktuellem Tarifvertrag?"</li>
<li><strong>Workflow Agent</strong> wertet die Antworten aus: BEM-Schwelle nicht erreicht - Standardprozess.</li>
<li><strong>Decision Layer</strong> prüft § 5 EFZG und Betriebsvereinbarungs-Constraints - Lohnfortzahlung berechnen.</li>
<li><strong>Workflow Agent</strong> erstellt SAP-Buchungsvorschlag, informiert HR-Manager, dokumentiert im Audit Trail.</li>
</ol>
<p class="text-body text-gosign-text-light mt-3">
Sechs Schritte, drei Agent-Typen, drei Systeme - ein durchgängiger Audit Trail.
</p>
</div>
</div>
</div>
</section>

<!-- Mid-Page CTA -->
<section class="py-12 bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 text-center">
<p class="text-h2 font-bold text-white">Welcher Agent-Typ passt zu Ihrem Prozess?</p>
<p class="text-body-lg text-white/80 mt-2">30 Minuten. Ihr Prozess. Konkrete Empfehlung.</p>
<a href="/de/kontakt/" class="inline-block mt-6 px-8 py-3 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors">Erstgespräch vereinbaren</a>
</div>
</section>

<!-- Spezialisierte Agent-Lösungen -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Spezialisierte Agent-Lösungen</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Document, Workflow und Knowledge Agents sind die Bausteine. Für HR und Finance bieten wir vorkonfigurierte Lösungen mit branchenspezifischen Regelwerken. Für andere Bereiche entwickeln wir individuelle Agenten im Co-Build.
</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-4 gap-6 mt-8 max-w-content">
<a href="/de/hr-ai-agents/" class="group block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">HR & People Operations</p>
<p class="text-body font-semibold text-gosign-dark">HR AI Agents</p>
<p class="text-body text-gosign-text-light mt-2">6 Agent-Produkte: Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Betriebsratsfähig.</p>
<p class="text-small text-gosign-accent-text mt-2">48 Agenten im Assessment bewerten &rarr;</p>
<span class="inline-flex items-center gap-1 mt-2 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Übersicht <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
<a href="/de/finance-ai-agents/" class="group block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Finance & Accounting</p>
<p class="text-body font-semibold text-gosign-dark">Finance AI Agents</p>
<p class="text-body text-gosign-text-light mt-2">Belegverarbeitung, Kontierung, AfA-Logik, Korrekturbuchungen. DATEV- und SAP-Integration.</p>
<p class="text-small text-gosign-accent-text mt-2">49 Agenten im Assessment bewerten &rarr;</p>
<span class="inline-flex items-center gap-1 mt-2 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Übersicht <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
<a href="/de/leistungen/ai-agents/co-build/" class="group block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Individuelle Agenten</p>
<p class="text-body font-semibold text-gosign-dark">Co-Build</p>
<p class="text-body text-gosign-text-light mt-2">Ihr Prozess, Ihr Agent. 4-6 Wochen vom Discover bis zum produktiven Agenten mit Quellcode-Zugang.</p>
<span class="inline-flex items-center gap-1 mt-4 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Details <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
<a href="/de/kontakt/" class="group block bg-gosign-dark rounded-card p-6 hover:bg-gosign-dark/90 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-white/60 mb-2">Nächster Schritt</p>
<p class="text-body font-semibold text-white">Gespräch vereinbaren</p>
<p class="text-body text-white/80 mt-2">30 Minuten. Ihr Use Case. Konkrete Empfehlung, welcher Agent-Typ passt.</p>
<span class="inline-flex items-center gap-1 mt-4 text-small font-semibold text-white/60 group-hover:text-white transition-colors">Erstgespräch vereinbaren <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
</div>
</div>
</section>

<!-- Für wen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Für wen</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
AI-Agenten betreffen unterschiedliche Stakeholder. Jeder hat andere Fragen.
</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-4 gap-6 mt-8 max-w-content">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">CHRO / VP HR</p>
<p class="text-body text-gosign-text-light mt-2">Betriebsratsfähige Automatisierung von HR-Prozessen - Payroll, Leave, Recruiting - mit vollem Audit Trail und Tarifvertrags-Compliance.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">CFO / Finance Lead</p>
<p class="text-body text-gosign-text-light mt-2">Automatisierte Belegverarbeitung, Kontierung und Kontenabstimmung - konsistent über alle Standorte, auditierbar für Wirtschaftsprüfer.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Betriebsrat</p>
<p class="text-body text-gosign-text-light mt-2">Transparenz über jede Agent-Entscheidung. Decision Layer bildet Betriebsvereinbarungen als explizite Constraints ab. Human-in-the-Loop, wo es zählt.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">CTO / IT Lead</p>
<p class="text-body text-gosign-text-light mt-2">Modell-agnostische Architektur. API-basierte Integration in SAP, DATEV, Workday. Kein Vendor Lock-in, voller Quellcode-Zugang.</p>
</div>
</div>
</div>
</section>

<!-- Decision Layer -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Decision Layer</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Der Decision Layer zerlegt jeden Geschäftsprozess in einzelne Entscheidungsschritte und definiert für jeden Schritt: Mensch, Regelwerk oder KI. Jede Entscheidung wird dokumentiert - prüfbar für Wirtschaftsprüfer, Betriebsrat und interne Revision.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Für jeden Agent-Typ anders: Bei Document Agents prüft er Extraktionsqualität. Bei Workflow Agents steuert er das Routing. Bei Knowledge Agents verhindert er Halluzination.
</p>
<p class="mt-4">
<a href="/de/decision-layer/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Decision Layer im Detail</a>
</p>
</div>
</div>
</section>

<!-- Integration + Modell-Agnostik -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Integration und Modell-Agnostik</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
AI-Agenten ersetzen keine bestehenden Systeme. SAP bleibt ERP. Workday bleibt HCM. DATEV bleibt Steuersystem. Die Agent-Logik ist vom Zielsystem entkoppelt.
</p>
<div class="grid grid-cols-2 sm:grid-cols-3 gap-3 mt-6">
<div class="bg-gosign-white rounded-card px-4 py-3 text-body text-gosign-text-light">SAP FI/CO, S/4HANA</div>
<div class="bg-gosign-white rounded-card px-4 py-3 text-body text-gosign-text-light">SAP SuccessFactors</div>
<div class="bg-gosign-white rounded-card px-4 py-3 text-body text-gosign-text-light">Workday</div>
<div class="bg-gosign-white rounded-card px-4 py-3 text-body text-gosign-text-light">DATEV</div>
<div class="bg-gosign-white rounded-card px-4 py-3 text-body text-gosign-text-light">SharePoint, Teams</div>
<div class="bg-gosign-white rounded-card px-4 py-3 text-body text-gosign-text-light">Active Directory</div>
</div>
<p class="text-body-lg text-gosign-text-light mt-6">
Die Architektur ist nicht an ein einzelnes LLM gebunden: Claude, ChatGPT, Gemini, Llama, Mistral, DeepSeek - Modelle sind austauschbar ohne Änderung der Geschäftslogik. Kein Vendor Lock-in.
</p>
</div>
</div>
</section>

<!-- Business Impact + Ownership -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Business Impact</h2>
<ul class="mt-6 space-y-3">
<li class="text-body-lg text-gosign-text-light">Routinefälle werden autonom verarbeitet - mit vollständiger Dokumentation</li>
<li class="text-body-lg text-gosign-text-light">Gleiche Regelinterpretation über alle Standorte hinweg</li>
<li class="text-body-lg text-gosign-text-light">Jede Entscheidung nachvollziehbar für Prüfer und Betriebsrat</li>
<li class="text-body-lg text-gosign-text-light">Skalierbar ohne proportionalen Personalaufbau</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-6">
Voller Zugang zum Quellcode, allen Prompts und Regelwerken. Nach 12-18 Monaten betreiben Sie Ihre Agenten eigenständig. Kein SaaS-Abo, kein Platform Lock-in.
</p>
</div>
</div>
</section>

<!-- Vertiefung -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Vertiefung im Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Unsere Fachartikel-Serie für Entscheider, die AI Agents im Unternehmen einführen.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/de/magazin/ai-agenten-enterprise-leitfaden/" class="group block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors bg-gosign-white">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">AI Agents</p>
<p class="text-body font-semibold text-gosign-dark">Von Chatbots zu AI-Agenten: MCP, A2A und Multi-Agent-Systeme</p>
<span class="inline-flex items-center gap-1 mt-3 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Lesen <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
<a href="/de/magazin/agent-orchestrierung-plattformen/" class="group block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors bg-gosign-white">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">Agent-Orchestrierung: Trigger.dev, n8n, Camunda und Alternativen</p>
<span class="inline-flex items-center gap-1 mt-3 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Lesen <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
<a href="/de/magazin/decision-layer-erklaert/" class="group block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors bg-gosign-white">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - Was ist das und warum braucht jeder Enterprise AI Agent einen?</p>
<span class="inline-flex items-center gap-1 mt-3 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Lesen <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
</div>
</div>
</section>

--- Document Intelligence - PII, Vertragsschwärzung, Signaturerkennung ---
> Dokumente DSGVO-konform mit KI verarbeiten. PII-Anonymisierung, regelbasierte Vertragsschwärzung, Signaturerkennung - gesteuert durch den Decision Layer.

<!-- Das Problem -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Das Problem: Personenbezogene Daten in jedem Dokument</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Unternehmen wollen Dokumente mit KI verarbeiten - Verträge analysieren, Belege klassifizieren, Policys abfragen. Aber jedes Dokument enthält personenbezogene Daten: Namen, Gehälter, Sozialversicherungsnummern, Adressen, Bankverbindungen, Unterschriften.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
An ein Sprachmodell - auch an ein selbst gehostetes - dürfen diese Daten nicht ungeschützt. Die DSGVO verlangt Datensparsamkeit. Betriebsvereinbarungen schränken die Verarbeitung personenbezogener Mitarbeiterdaten ein. Geschäftsgeheimnisse in Verträgen dürfen Dritte nicht sehen.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Die bisherigen Lösungen sind unbefriedigend: Manuelle Schwärzung in Adobe Acrobat - zeitaufwendig, fehleranfällig, und oft nur optisch (der Text bleibt unter dem schwarzen Balken erhalten). Oder Verzicht auf KI-Verarbeitung sensibler Dokumente - was den größten Teil des Produktivitätsgewinns zunichte macht.
</p>
</div>
</div>
</section>

<!-- Drei Capabilities -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">Drei Capabilities</h2>
<div class="grid grid-cols-1 md:grid-cols-3 gap-6">
<div class="bg-white rounded-card p-6 border border-gosign-border">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">PII-Anonymisierung für LLM-Input</h3>
<p class="text-body text-gosign-text-light">Roundtrip-Pseudonymisierung: Personenbezogene Daten werden vor dem LLM-Input durch konsistente Pseudonyme ersetzt. Der Output wird re-anonymisiert - die echten Daten erscheinen nur im Ergebnis, nie im Modell. Die Zuordnungstabelle verlässt nie den Pre-Processing Layer.</p>
<a href="#pii-anonymisierung" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold text-body mt-3 inline-block">Details</a>
</div>
<div class="bg-white rounded-card p-6 border border-gosign-border">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Vertragsschwärzung</h3>
<p class="text-body text-gosign-text-light">Regelbasierte Schwärzung für unterschiedliche Empfänger. Derselbe Vertrag wird für Betriebsrat, Due Diligence oder externe Berater unterschiedlich geschwärzt - gesteuert durch versionierte Schwärzungsregeln im Decision Layer. Echte Schwärzung, nicht nur optisch.</p>
<a href="#vertragsschwärzung" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold text-body mt-3 inline-block">Details</a>
</div>
<div class="bg-white rounded-card p-6 border border-gosign-border">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Signaturerkennung</h3>
<p class="text-body text-gosign-text-light">Automatische Erkennung von Unterschriftenfeldern und vorhandenen Unterschriften in Dokumenten. Massenprüfung von Vertragsarchiven, Onboarding-Qualitätsprüfung, Audit-Vorbereitung. Anomalien werden an Menschen eskaliert - nie autonom akzeptiert.</p>
<a href="#signaturerkennung" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold text-body mt-3 inline-block">Details</a>
</div>
</div>
</div>
</section>

<!-- PII-Anonymisierung Detail -->
<section id="pii-anonymisierung" class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">PII-Anonymisierung: Roundtrip-Pseudonymisierung für LLM-Input</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Die meisten PII-Tools am Markt sind Einweg-Schwärzung - sie entfernen Daten. Für die Verarbeitung mit Sprachmodellen reicht das nicht. Wenn ein Agent einen Vertrag analysieren soll, braucht er den Kontext: "Mitarbeiter X hat Gehalt Y an Standort Z." Ohne diesen Kontext kann das Modell keine sinnvolle Bewertung abgeben.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Die Gosign-Lösung ist Roundtrip-Pseudonymisierung: Daten werden vor dem Modell pseudonymisiert, vom Modell verarbeitet, und im Ergebnis re-anonymisiert. Das Modell sieht nur Pseudonyme. Das Ergebnis enthält die echten Daten.
</p>

<pre class="bg-gosign-dark text-white p-6 rounded-card overflow-x-auto text-small font-mono leading-relaxed mt-6"><code>┌─────────────┐     ┌──────────────────┐     ┌─────────────┐     ┌──────────────────┐     ┌─────────────┐
│  Dokument   │     │  PII-Erkennung   │     │  Pseudonym-  │     │  Sprachmodell    │     │  Re-Mapping │
│  (Original) │────▶│  & Klassifi-     │────▶│  isierung    │────▶│  verarbeitet     │────▶│  Pseudonyme │
│             │     │  zierung         │     │              │     │  nur Pseudonyme  │     │  → Echtdaten│
└─────────────┘     └──────────────────┘     └──────────────┘     └──────────────────┘     └─────────────┘
│                        │                                            │
▼                        ▼                                            ▼
┌──────────────┐         ┌──────────────┐                              ┌──────────────┐
│  Decision    │         │  Mapping-    │                              │  Ergebnis    │
│  Layer:      │         │  Tabelle     │◀─────────────────────────────│  mit echten  │
│  Was wird    │         │  (bleibt     │   Rück-Zuordnung            │  Daten       │
│  anonymisiert│         │  lokal)      │                              └──────────────┘
└──────────────┘         └──────────────┘</code></pre>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">Entscheidungsschritte im PII-Prozess</h3>
<div class="mt-4 overflow-x-auto">
<table class="w-full text-body text-gosign-text-light border-collapse">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="text-left py-2 pr-4 font-bold text-gosign-dark">Micro-Entscheidung</th>
<th class="text-left py-2 pr-4 font-bold text-gosign-dark">Wer entscheidet</th>
<th class="text-left py-2 font-bold text-gosign-dark">Warum</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">PII-Kategorien definieren</td><td class="py-2 pr-4">Mensch + Regelwerk</td><td class="py-2">DSGVO-Vorgaben, Betriebsvereinbarung, kundenspezifisch</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">PII im Dokument erkennen</td><td class="py-2 pr-4">KI (NER + Pattern)</td><td class="py-2">Named Entity Recognition + regelbasierte Muster</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Falsch-Positive prüfen</td><td class="py-2 pr-4">KI, bei Unsicherheit Mensch</td><td class="py-2">Confidence Routing - "Müller" als Name oder Firmenname?</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Pseudonyme zuweisen</td><td class="py-2 pr-4">Automatisch</td><td class="py-2">Konsistente Zuordnung, "Person_A" statt "Max Müller"</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Pseudonymisiertes Dokument ans Modell</td><td class="py-2 pr-4">Automatisch</td><td class="py-2">Keine Entscheidung, reine Weiterleitung</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Output re-anonymisieren</td><td class="py-2 pr-4">Automatisch</td><td class="py-2">Mapping-Tabelle rückwärts anwenden</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Audit: Was wurde anonymisiert</td><td class="py-2 pr-4">Automatisch</td><td class="py-2">DSGVO-Nachweis im Audit Trail</td></tr>
</tbody>
</table>
</div>
<p class="text-body-lg text-gosign-text-light mt-4">
Die Zuordnungstabelle (Pseudonym → Echtdaten) verlässt nie den Pre-Processing Layer. Sie wird nach Abschluss der Verarbeitung gelöscht - oder für einen definierten Zeitraum aufbewahrt, je nach Konfiguration. Das Sprachmodell sieht zu keinem Zeitpunkt personenbezogene Daten.
</p>
</div>
</div>
</section>

<!-- Vertragsschwärzung Detail -->
<section id="vertragsschwärzung" class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Vertragsschwärzung: Regelbasiert, empfängerabhängig, physisch</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Verträge müssen regelmäßig in anonymisierter Form weitergegeben werden - an Wirtschaftsprüfer, an potenzielle Käufer bei Due Diligence, an den Betriebsrat, an externe Berater. Heute macht das jemand manuell. Das dauert Stunden pro Vertrag, ist fehleranfällig, und die Schwärzung ist oft nur optisch: Der Text bleibt unter dem schwarzen Balken erhalten. Ein häufig unterschätztes Datenleck.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Die Gosign-Lösung: Der Document Agent erkennt Vertragsstruktur - Parteien, Beträge, Laufzeiten, Klauseln, Unterschriften. Der Decision Layer definiert empfängerabhängig, was geschwärzt wird:
</p>

<div class="mt-6 overflow-x-auto">
<table class="w-full text-body text-gosign-text-light border-collapse">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="text-left py-2 pr-4 font-bold text-gosign-dark">Vertragselement</th>
<th class="text-left py-2 pr-4 font-bold text-gosign-dark">Betriebsrat</th>
<th class="text-left py-2 pr-4 font-bold text-gosign-dark">Due Diligence</th>
<th class="text-left py-2 pr-4 font-bold text-gosign-dark">Externer Berater</th>
<th class="text-left py-2 font-bold text-gosign-dark">Wirtschaftsprüfer</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Vertragsparteien (Namen)</td><td class="py-2 pr-4">✓ Sichtbar</td><td class="py-2 pr-4">✗ Geschwärzt</td><td class="py-2 pr-4">✗ Geschwärzt</td><td class="py-2">✓ Sichtbar</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Vertragswerte / Beträge</td><td class="py-2 pr-4">✓ Sichtbar</td><td class="py-2 pr-4">✓ Sichtbar</td><td class="py-2 pr-4">✗ Geschwärzt</td><td class="py-2">✓ Sichtbar</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Gehälter / Vergütung</td><td class="py-2 pr-4">✓ Sichtbar</td><td class="py-2 pr-4">Aggregiert</td><td class="py-2 pr-4">✗ Geschwärzt</td><td class="py-2">✓ Sichtbar</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Vertragsklauseln</td><td class="py-2 pr-4">✓ Sichtbar</td><td class="py-2 pr-4">✓ Sichtbar</td><td class="py-2 pr-4">Nur Klauseltypen</td><td class="py-2">✓ Sichtbar</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Geschäftsgeheimnisse</td><td class="py-2 pr-4">✗ Geschwärzt</td><td class="py-2 pr-4">✓ Sichtbar</td><td class="py-2 pr-4">✗ Geschwärzt</td><td class="py-2">✓ Sichtbar</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Unterschriften</td><td class="py-2 pr-4">✗ Geschwärzt</td><td class="py-2 pr-4">✗ Geschwärzt</td><td class="py-2 pr-4">✗ Geschwärzt</td><td class="py-2">✓ Sichtbar</td></tr>
</tbody>
</table>
</div>

<p class="text-body-lg text-gosign-text-light mt-4">
Die Schwärzungsregeln sind versioniert im Decision Layer. Wenn sich die Anforderungen ändern - neuer Empfängerkreis, andere Betriebsvereinbarung, geänderte Compliance-Regel - entsteht eine neue Regelversion. Die alte bleibt nachvollziehbar.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong>Physische Schwärzung:</strong> Das PDF wird neu gerendert. Die Originaldaten sind physisch nicht mehr im Dokument enthalten. Kein Copy-Paste unter schwarzen Balken, kein PDF-Editing zum Freilegen. Das ist keine Kosmetik - es ist kryptographisch sauber.
</p>
</div>
</div>
</section>

<!-- Signaturerkennung Detail -->
<section id="signaturerkennung" class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Signaturerkennung: Unterschriften finden, prüfen, dokumentieren</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Vertragsmanagement, Audit-Vorbereitung, Compliance-Prüfung - überall muss regelmäßig geprüft werden: Ist das Dokument unterschrieben? Wo ist die Unterschrift? Fehlt eine Gegenzeichnung? Bei 5.000 Verträgen im Archiv ist das manuell nicht leistbar.
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">Signature Detection - Unterschriften finden</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Der Document Agent erkennt Unterschriftenfelder und vorhandene Unterschriften in gescannten Dokumenten und PDFs. Computer Vision, kein Sprachmodell - spezialisierte ML-Modelle für Bildanalyse. Der Output ist strukturiert: Seite, Position, Konfidenz dass eine Unterschrift vorhanden ist.
</p>

<p class="text-body-lg text-gosign-text-light mt-6">
<strong>Massenprüfung Vertragsarchiv:</strong> "In welchen der 5.000 Verträge fehlt die Gegenzeichnung?" - Ergebnis in Minuten statt Wochen.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong>Onboarding-Qualitätsprüfung:</strong> "Sind alle Pflichtdokumente des neuen Mitarbeiters unterschrieben?" - Automatische Checkliste, fehlende Unterschriften werden als Workflow-Aufgabe eskaliert.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong>Audit-Vorbereitung:</strong> "Zeige alle Dokumente ohne Unterschrift im Zeitraum Q3 2025." - Strukturierte Exportliste für den Prüfer.
</p>

<pre class="bg-gosign-dark text-white p-6 rounded-card overflow-x-auto text-small font-mono leading-relaxed mt-6"><code>┌─────────────┐     ┌──────────────────┐     ┌──────────────────┐
│  Dokument   │     │  Signatur-       │     │  Vergleich mit   │
│  mit Unter- │────▶│  erkennung       │────▶│  Referenz-       │
│  schrift    │     │  (Position,      │     │  unterschrift    │
│             │     │   Konfidenz)     │     │                  │
└─────────────┘     └──────────────────┘     └──────────────────┘
│
┌───────────┼───────────┐
▼           ▼           ▼
┌────────────┐ ┌────────┐ ┌────────────┐
│  Hohe      │ │Mittlere│ │  Niedrige  │
│  Überein-  │ │Überein-│ │  Überein-  │
│  stimmung  │ │stimmung│ │  stimmung  │
└────────────┘ └────────┘ └────────────┘
│              │           │
▼              ▼           ▼
Automatisch    Eskalation   Blockierung
akzeptiert,    an Sach-     Menschliche
dokumentiert   bearbeiter   Prüfung
mit Ver-     Pflicht
gleichs-
ansicht</code></pre>

<p class="text-body-lg text-gosign-text-light mt-4">
<strong>Wichtig:</strong> Der Signaturvergleich ist ein Anomalie-Detektor, kein Fälschungsdetektor. Unterschriften variieren natürlich - Tagesform, Stift, Untergrund. Das System erkennt Auffälligkeiten und eskaliert sie an einen Menschen. Es behauptet nie "diese Unterschrift ist gefälscht" oder "diese Unterschrift ist echt". Das wäre unseriös.
</p>
</div>
</div>
</section>

<!-- Decision Layer -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Der Decision Layer: Wer entscheidet was anonymisiert, geschwärzt oder eskaliert wird?</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Der Decision Layer zerlegt jeden Dokumentenprozess in einzelne Entscheidungsschritte. Für jeden Schritt ist definiert: Mensch, Regelwerk oder KI.
</p>

<div class="mt-6 overflow-x-auto">
<table class="w-full text-body text-gosign-text-light border-collapse">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="text-left py-2 pr-4 font-bold text-gosign-dark">Prozess</th>
<th class="text-left py-2 pr-4 font-bold text-gosign-dark">Micro-Entscheidung</th>
<th class="text-left py-2 pr-4 font-bold text-gosign-dark">Wer entscheidet</th>
<th class="text-left py-2 font-bold text-gosign-dark">Warum</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-bold">PII</td><td class="py-2 pr-4">Welche Datenfelder sind PII?</td><td class="py-2 pr-4">Regelwerk</td><td class="py-2">DSGVO Art. 4, Betriebsvereinbarung</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-bold">PII</td><td class="py-2 pr-4">Ist "Müller" ein Name oder eine Firma?</td><td class="py-2 pr-4">KI, bei &lt;80% Konfidenz: Mensch</td><td class="py-2">NER-Ambiguität - Falsch-Positive vermeiden</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-bold">PII</td><td class="py-2 pr-4">Pseudonymisierungsmethode wählen</td><td class="py-2 pr-4">Regelwerk</td><td class="py-2">Konsistente Pseudonyme vs. Zufallswerte</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-bold">Schwärzung</td><td class="py-2 pr-4">Welcher Empfängerkreis?</td><td class="py-2 pr-4">Mensch</td><td class="py-2">Fachliche Entscheidung, nicht automatisierbar</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-bold">Schwärzung</td><td class="py-2 pr-4">Welche Felder werden geschwärzt?</td><td class="py-2 pr-4">Regelwerk</td><td class="py-2">Empfängerabhängige Schwärzungsmatrix</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-bold">Schwärzung</td><td class="py-2 pr-4">Unbekannter Klauseltyp erkannt</td><td class="py-2 pr-4">Mensch</td><td class="py-2">Neue Klauseltypen müssen klassifiziert werden</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-bold">Signatur</td><td class="py-2 pr-4">Unterschrift vorhanden?</td><td class="py-2 pr-4">KI</td><td class="py-2">Computer Vision mit Konfidenzwert</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-bold">Signatur</td><td class="py-2 pr-4">Stimmt Signatur mit Referenz überein?</td><td class="py-2 pr-4">KI + Mensch bei Anomalie</td><td class="py-2">Hohe Übereinstimmung: akzeptiert. Anomalie: eskaliert</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-bold">Signatur</td><td class="py-2 pr-4">Keine Referenz vorhanden</td><td class="py-2 pr-4">Mensch</td><td class="py-2">Neue Referenzunterschrift muss erfasst werden</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-bold">Alle</td><td class="py-2 pr-4">Audit Trail dokumentieren</td><td class="py-2 pr-4">Automatisch</td><td class="py-2">Jede Entscheidung unveränderlich protokolliert</td></tr>
</tbody>
</table>
</div>
</div>
</div>
</section>

<!-- Integration -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Integration</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Document Intelligence ist eine Capability des bestehenden Document Agent - keine separate Software. Die Integration erfolgt über dieselben Schnittstellen:
</p>
<ul class="mt-4 space-y-2 text-body-lg text-gosign-text-light list-disc pl-6">
<li>SAP DMS, SAP ArchiveLink - Verträge und Belege aus SAP-Archiven</li>
<li>SharePoint, OneDrive - Dokumentenmanagement via Microsoft Graph</li>
<li>E-Mail-Eingänge (IMAP/Exchange) - Anhänge automatisch verarbeiten</li>
<li>Dateisystem-Watcher - Lokale Verzeichnisse überwachen</li>
<li>REST API - Für kundenspezifische DMS-Systeme</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-4">
Die Document-Intelligence-Capabilities werden pro Mandant konfiguriert: Welche PII-Kategorien erkannt werden, welche Schwärzungsregeln gelten, welche Referenz-Signaturen hinterlegt sind. Alles versioniert, alles im Decision Layer.
</p>
</div>
</div>
</section>

<!-- Business Impact -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Business Impact</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong>DSGVO-konforme LLM-Verarbeitung:</strong> Dokumente mit personenbezogenen Daten können erstmals sicher mit Sprachmodellen verarbeitet werden - ohne Datenschutzrisiko.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong>Vertragsschwärzung in Minuten statt Stunden:</strong> Regelbasiert, empfängerabhängig, physisch sicher. Ein Vertrag, der manuell 2 Stunden dauert, wird in Sekunden verarbeitet.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong>Signaturlücken proaktiv erkennen:</strong> Fehlende Unterschriften werden gefunden bevor der Prüfer fragt - nicht danach.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong>Audit-Nachweis für Datenschutz:</strong> Der Audit Trail dokumentiert jede Anonymisierung, jede Schwärzung, jede Signaturprüfung. Bei einer DSGVO-Anfrage oder Betriebsprüfung ist nachweisbar, welche Daten wann wie verarbeitet wurden.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong>Kein neues Tool:</strong> Document Intelligence ist Teil der bestehenden Agent-Architektur. Kein zusätzlicher Vendor, keine zusätzliche Lizenz, keine zusätzliche Schulung.
</p>
</div>
</div>
</section>

<!-- Vertiefung -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Vertiefung im Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Unsere Fachartikel-Serie für Entscheider, die AI Agents im Unternehmen einführen.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/de/magazin/rag-document-intelligence-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">RAG &amp; Document Intelligence: Wie KI Ihre Dokumente versteht</p>
</a>
<a href="/de/magazin/pii-anonymisierung-llm-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">PII-Anonymisierung für Enterprise AI</p>
</a>
<a href="/de/magazin/datensicherheit-ki-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Datensicherheit bei KI - Data Residency, DSGVO und EU AI Act</p>
</a>
</div>
</div>
</section>

--- eIDAS-konforme digitale Signaturen ---
> Digitale Signaturlösungen nach eIDAS-Verordnung. Einfache, fortgeschrittene und qualifizierte elektronische Signaturen für Enterprise-Dokumentenprozesse.

<!-- eIDAS-Verordnung -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">eIDAS-Verordnung</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Die <a href="https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX%3A32014R0910" target="_blank" rel="noopener noreferrer">eIDAS-Verordnung (Verordnung (EU) Nr. 910/2014)</a> schafft einen europäischen Rechtsrahmen für elektronische Identifizierung und Vertrauensdienste. Für Enterprise-Dokumentenprozesse sind insbesondere die drei Signatur-Stufen relevant.
</p>
</div>
</section>

<!-- Drei Signatur-Stufen -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Drei Signatur-Stufen</h2>
<div class="mt-6 space-y-6">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Einfache elektronische Signatur (EES)</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Keine besonderen technischen Anforderungen. Beispiele: eingescannte Unterschrift, Namensangabe unter einer E-Mail, Klick auf "Ich stimme zu". Beweiskraft begrenzt, aber in vielen Geschäftsprozessen ausreichend.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Fortgeschrittene elektronische Signatur (AES)</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Eindeutig dem Unterzeichner zugeordnet. Ermöglicht die Identifizierung des Unterzeichners. Unter alleiniger Kontrolle des Unterzeichners erstellt. Nachträgliche Änderungen am Dokument werden erkannt.
</p>
<p class="text-body-lg text-gosign-text-light mt-2">
Einsatzbereich: Verträge, Freigaben, interne Genehmigungsprozesse wo eine erhöhte Beweiskraft erforderlich ist, aber keine Schriftformersatzfunktion.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Qualifizierte elektronische Signatur (QES)</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Höchste Signatur-Stufe. Rechtswirkung einer handschriftlichen Unterschrift (Art. 25 Abs. 2 eIDAS). Erstellt mit einem qualifizierten Signaturzertifikat von einem zugelassenen Vertrauensdiensteanbieter.
</p>
<p class="text-body-lg text-gosign-text-light mt-2">
Einsatzbereich: Wo gesetzliche Schriftform erforderlich ist oder maximale Rechtssicherheit gewünscht wird.
</p>
</div>
</div>
</div>
</section>

<!-- Enterprise-Integration -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Enterprise-Integration</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Gosign integriert eIDAS-konforme Signaturen in bestehende Dokumentenprozesse:
</p>
<div class="mt-6 space-y-4">
<p class="text-body-lg text-gosign-text-light">
<strong>In <a href="/de/leistungen/document-intelligence/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Document-Agent-Workflows</a>:</strong> Nach der automatisierten Verarbeitung eines Dokuments kann eine digitale Signatur als Abschlussprozess ausgelöst werden - z.B. nach der Rechnungsfreigabe oder Vertragsbestätigung.
</p>
<p class="text-body-lg text-gosign-text-light">
<strong>In Genehmigungsprozessen:</strong> Mehrstufige Freigaben mit digitalen Signaturen. Jede Signatur wird im <a href="/de/decision-layer/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Audit Trail des Decision Layer</a> dokumentiert.
</p>
<p class="text-body-lg text-gosign-text-light">
<strong>API-Integration:</strong> Anbindung an bestehende Systeme über REST API. Die Signatur-Infrastruktur wird vom Vertrauensdiensteanbieter bereitgestellt - Gosign implementiert die Integration.
</p>
</div>
</div>
</section>

<!-- Zusammenarbeit mit ETSI-zertifizierten Partnern -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Zusammenarbeit mit ETSI-zertifizierten Partnern</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Gosign ist kein Vertrauensdiensteanbieter. Wir implementieren eIDAS-konforme Signaturlösungen in Zusammenarbeit mit Anbietern die nach ETSI EN 319 401 und den jeweiligen spezifischen Normen zertifiziert sind.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Die Wahl des Vertrauensdiensteanbieters richtet sich nach den Anforderungen des Kunden: Signatur-Stufe, Volumen, Integrationsanforderungen, bestehende Verträge.
</p>
</div>
</section>

<!-- Compliance -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Compliance</h2>
<ul class="mt-6 space-y-3">
<li class="text-body-lg text-gosign-text-light">EU-weit rechtsgültig nach eIDAS-Verordnung</li>
<li class="text-body-lg text-gosign-text-light">DSGVO-konform (Datenverarbeitung durch zertifizierten Vertrauensdiensteanbieter, <a href="/de/governance/data-residency/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Data Residency</a> in der EU)</li>
<li class="text-body-lg text-gosign-text-light">Audit Trail für alle Signaturvorgänge</li>
<li class="text-body-lg text-gosign-text-light">Langzeitvalidierung (LTV) für qualifizierte Signaturen</li>
</ul>
</div>
</section>

<!-- Vertiefung im Agent Briefing -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Vertiefung im Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Unsere Fachartikel-Serie für Entscheider, die digitale Prozesse im Unternehmen absichern.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/de/magazin/cert-ready-by-design/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Cert-Ready by Design: Warum nachträgliche Zertifizierung scheitert</p>
</a>
<a href="/de/magazin/rag-document-intelligence-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">AI Agents</p>
<p class="text-body font-semibold text-gosign-dark">RAG und Document Intelligence im Enterprise-Einsatz</p>
</a>
<a href="/de/magazin/datensicherheit-ki-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">Datensicherheit bei KI im Enterprise</p>
</a>
</div>
</div>
</section>

--- AI Leave Agent Aviation - Abwesenheitsmanagement ---
> Leave Decision Layer für die Luftfahrt. 3 Gewerkschaften, EASA FTL, Medical Grounding, Crew-Pairing. 78% vollautomatisch.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/de/warum-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Jede Entscheidung nachvollziehbar</p>
</div>
</a>
<a href="/de/warum-gosign/#infrastruktur" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Ihre Infrastruktur</p>
<p class="text-xs text-gosign-text-light">Kein SaaS. Kein Vendor-Lock-in.</p>
</div>
</a>
<a href="/de/warum-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Kein US-Cloud-Risiko</p>
</div>
</a>
</div>
</div>
</div>



<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Leave Decision Layer Branchen">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/de/leistungen/hr-agent/leave-absence-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Leave Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/de/leistungen/hr-agent/leave-absence-decision-layer/chemie/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Chemie</a>
<a href="/de/leistungen/hr-agent/leave-absence-decision-layer/aviation/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Aviation</a>
<a href="/de/leistungen/hr-agent/leave-absence-decision-layer/finanzwesen/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Finanzwesen</a>
<a href="/de/leistungen/hr-agent/leave-absence-decision-layer/handel/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Handel</a>
</div>
</div>
</nav>

<!-- Komplexität -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">3</span>
<p class="text-small text-gosign-text-light mt-1">Gewerkschaften</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">78%</span>
<p class="text-small text-gosign-text-light mt-1">Automatisierungsquote</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">EASA</span>
<p class="text-small text-gosign-text-light mt-1">FTL-Compliance</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">Höchste Regelkomplexität</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">Tarifverträge Cockpit (VC), Kabine (UFO), Boden (ver.di). vollautomatisch: Gosign-Simulationsmodell.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Was der Agent klassifiziert</p>
<h2 class="text-h1 font-bold text-gosign-dark">Sechs Dimensionen, ein Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Konzernstruktur mit dutzenden Gesellschaften, drei Gewerkschaften mit eigenen Tarifverträgen, regulatorische Pflichtruhezeiten, Medical Grounding, Crew-Pairing als operative Constraint und saisonale Urlaubssperren. So löst der AI Agent sie:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Konzerngesellschaften mit eigenen Regelwerken</h3>
<p class="text-body text-gosign-text mt-2">Große Luftfahrtkonzerne betreiben dutzende Gesellschaften unter einem Dach - jede mit eigenem Tarifvertrag, eigener Betriebsvereinbarung und teilweise eigenem Rechtskreis. Der AI Agent erkennt die Gesellschaftszugehörigkeit aus dem Personalstamm und wendet automatisch das korrekte Regelwerk an. Wenn Personal zwischen Gesellschaften wechselt: automatische Umstellung der Urlaubsberechnung.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Drei Tarifverträge parallel</h3>
<p class="text-body text-gosign-text mt-2">Cockpit (Vereinigung Cockpit), Kabine (UFO), Boden (ver.di) - jeder Tarifvertrag hat eigene Urlaubsregelungen, Sonderurlaube und Freizeitausgleiche. Der AI Agent erkennt die Personalgruppe und wendet das korrekte Regelwerk an. Keine Verwechslung zwischen Piloten-Urlaub und Bodenpersonal-Urlaub.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">EASA FTL Pflichtruhezeiten</h3>
<p class="text-body text-gosign-text mt-2">Flight Time Limitations sind regulatorische Pflichtruhezeiten, die nicht als Urlaub gelten dürfen. Der AI Agent trennt sauber: FTL-Ruhezeiten laufen im separaten Tracking, Urlaubsansprüche werden nicht durch Pflichtruhezeiten reduziert. Bei der Urlaubsplanung prüft der Agent die FTL-Compliance gegen den Einsatzplan.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Medical Grounding</h3>
<p class="text-body text-gosign-text mt-2">Entzug des Medical Certificate (Class 1 Cockpit, Class 2 Kabine) ist keine reguläre Krankheit, sondern eine regulatorische Abwesenheit. Der AI Agent klassifiziert Medical Grounding als eigenen Leave-Typ mit tarifvertragsspezifischen Folgen. Gesundheitsdaten bleiben architektonisch separiert - der Agent sieht nur den Status, nicht die Diagnose.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Crew-Pairing als Constraint</h3>
<p class="text-body text-gosign-text mt-2">Cockpit und Kabine müssen für jeden Flug gemeinsam besetzt sein. Der AI Agent prüft bei jeder Urlaubsanfrage die Crew-Verfügbarkeit gegen den Flugplan und die Mindestbesetzung pro Position. Bei Unterschreitung: automatische Eskalation mit Alternativvorschlag und Kontext für den Scheduler.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Saisonale Urlaubssperren</h3>
<p class="text-body text-gosign-text mt-2">Sommerprogramm und Weihnachtsverkehr bedeuten Urlaubssperren für fliegendes Personal. Der AI Agent kennt die Sperrperioden aus der Betriebsvereinbarung und prüft jeden Antrag dagegen. Ausnahmen erfordern eine Führungskraft-Entscheidung - der Agent dokumentiert die Ausnahme im Audit Trail.</p>
</div>
</div>
</div>
</section>

<!-- Decision Flow -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Ein Urlaubsantrag in der Luftfahrt. 10 Entscheidungsschritte.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Ein Pilot stellt einen Urlaubsantrag. Der Leave Decision Layer zerlegt den Vorgang in einzelne Entscheidungsschritte:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Schritt</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Entscheidung</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Entscheider</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Begründung</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Personalgruppe und Tarifvertrag erkennen</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent erkennt: Cockpit (VC), Kabine (UFO) oder Boden (ver.di) aus Personalstamm</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Leave-Typ klassifizieren</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent erkennt: Erholungsurlaub, Sonderurlaub, FTL-Ruhezeit oder Medical Grounding</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Urlaubsanspruch berechnen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">Tarifvertragsspezifischer Grundurlaub + Zusatzurlaub (Langstrecke, Seniorität)</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">EASA FTL Compliance prüfen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">Mindest-Ruhezeiten zwischen Einsätzen, Flugstunden-Kumulierung, Duty-Period-Limits</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Crew-Pairing und Mindestbesetzung prüfen</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent prüft Crew-Verfügbarkeit gegen Flugplan und Mindestbesetzung pro Position</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Urlaubssperre prüfen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">Sommerprogramm, Weihnachtsverkehr, betriebsvereinbarte Sperrperioden</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Genehmigungsempfehlung erstellen</td><td class="py-3 px-4">KI empfiehlt, Mensch entscheidet</td><td class="py-3 px-4">Alle Regeln eingehalten: Empfehlung genehmigen. Konflikt: Eskalation mit Kontext</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">BEM-Schwelle prüfen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">42+ AU-Tage in 12 Monaten rollierend. Medical Grounding als Sonderfall separat getrackt</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Lohnfortzahlung berechnen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">6 Wochen pro Krankheitsfall, tarifvertragsspezifische Aufstockung prüfen</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Audit-Eintrag erzeugen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">Vollständige Entscheidungsakte: Leave-Typ, Tarifvertrag, FTL-Status, Crew-Check, Ergebnis</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Simulation -->
<section id="simulation" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulation</p>
<h2 class="text-h1 font-bold text-white">Durchgerechnet für Aviation-Volumina</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Wir haben den Leave Decision Layer mit realistischen Aviation-Parametern konfiguriert und durchgerechnet. Drei Gewerkschaften, EASA FTL, Medical Grounding, Crew-Pairing.</p>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Simulationsparameter</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Mitarbeiter</td><td class="py-3 px-4">5.000 bis 80.000+ (Cockpit, Kabine, Boden, über mehrere Konzerngesellschaften)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Tarifverträge</td><td class="py-3 px-4">Vereinigung Cockpit (VC), UFO (Kabine), ver.di (Boden)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Regulatorik</td><td class="py-3 px-4">EASA FTL (EU-OPS), Medical Certificates Class 1 und Class 2</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Leave-Typen</td><td class="py-3 px-4">Erholungsurlaub, FTL-Ruhezeit, Medical Grounding, Standby, Sonderurlaub</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Constraints</td><td class="py-3 px-4">Crew-Pairing, Saisonale Sperren, Stationierungsorte (FRA, MUC, Ausland)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">BEM-Quote</td><td class="py-3 px-4">Branchen-AU-Schnitt Luftfahrt, Medical Grounding separat</td></tr>
</tbody>
</table>
</div>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Vorher / Nachher</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th scope="col" class="text-left py-3 px-4 font-semibold text-white">Dimension</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manuell</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Bearbeitungszeit Urlaubsantrag</td><td class="py-3 px-4">2-5 Tage (Crew-Prüfung)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 2 Minuten</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Automatisierungsquote</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">78%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">FTL-Konflikte erkannt</td><td class="py-3 px-4">Manuell durch Scheduler</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatisch in Echtzeit</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Medical Grounding korrekt klassifiziert</td><td class="py-3 px-4">Fehleranfällig</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">100% korrekt (eigener Leave-Typ)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">BEM-Fristversäumnisse</td><td class="py-3 px-4">12-18%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">0% (automatischer Trigger)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Audit-Readiness</td><td class="py-3 px-4">Manuell rekonstruiert</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatisch erzeugt</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">EASA FTL: EU-Verordnung 965/2012 Subpart FTL. BEM-Quoten: WIdO. Simulationsergebnisse: Gosign-Modellrechnung.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">In der Simulation erreicht der Decision Layer eine Automatisierungsquote von 78%. Die niedrigere Quote reflektiert die hohe Regulierungsdichte: Crew-Pairing-Konflikte, Medical-Grounding-Klassifikation und FTL-Grenzfälle erfordern häufiger menschliche Entscheidungen. Für die 78% liegt eine vollständige, prüfungssichere Entscheidungsakte vor.</p>
</div>
</section>

<!-- Architektur-Referenz -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Architektur und Implementierung</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">Der Leave Decision Layer läuft vollständig in Ihrer Infrastruktur. Für die Luftfahrt bedeutet das: Anbindung an Crew-Management-Systeme, FTL-Tracking, Medical-Datenbank und durchgängiger Audit Trail. Typische Pilotprojekte starten mit einer Personalgruppe (z.B. Boden) und erweitern auf Cockpit und Kabine.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/de/leistungen/hr-agent/leave-absence-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Leave Decision Layer Übersicht &rarr;</a>
<a href="/de/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Decision Layer Architektur &rarr;</a>
<a href="/de/leistungen/infrastruktur/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infrastruktur im Detail &rarr;</a>
<a href="/de/governance/mitbestimmung/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Mitbestimmung &amp; Betriebsrat &rarr;</a>
<a href="/de/leistungen/hr-agent/payroll-decision-layer/aviation/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Payroll Decision Layer Aviation &rarr;</a>
</div>
</div>
</section>


<!-- Weitere Agent-Lösungen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Weitere Agent-Lösungen</h2>
<p class="text-body-lg text-gosign-text-light mt-4">HR Agents sind Teil unseres Agent-Portfolios. Für Finance und andere Bereiche bieten wir spezialisierte Lösungen.</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8 max-w-content">
<a href="/de/hr-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR & People Operations</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Alle HR Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Betriebsratsfähig.</p>
</a>
<a href="/de/finance-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Finance & Accounting</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Finance AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Belegverarbeitung, Kontierung, AfA-Logik, Korrekturbuchungen. DATEV- und SAP-Integration.</p>
</a>
<a href="/de/kontakt/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Individuell</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Co-Build für Ihren Prozess</h3>
<p class="text-body text-gosign-text-light mt-2">Compliance, Operations, Shared Services - wir entwickeln Agenten im Co-Build.</p>
</a>
</div>
</div>
</section>

<!-- Vertiefung -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Vertiefung im Agent Briefing (Gosign Magazin)</h2>
<p class="text-body text-gosign-text-light mb-6">Unsere Fachartikel-Serie für Entscheider, die AI Agents im Unternehmen einführen.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/de/magazin/betriebsrat-ki-mitbestimmung/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Mitbestimmung</p>
<p class="text-body font-semibold text-gosign-dark">Betriebsrat und KI - Mitbestimmung als Architektur-Constraint</p>
</a>
<a href="/de/magazin/agent-governance-hr/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Agent Governance für HR - Warum Regelwerke wichtiger sind als Modelle</p>
</a>
<a href="/de/magazin/decision-layer-erklaert/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Grundlagen</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - Was ist das und warum braucht jeder Enterprise AI Agent einen?</p>
</a>
</div>
</div>
</section>

<!-- Andere Branchen -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Leave Decision Layer in anderen Branchen</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Jede Branche hat eigene Tarifverträge, eigene Leave-Typen und eigene Komplexitätstreiber. Der Decision Layer ist derselbe. Die Konfiguration ist branchenspezifisch.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/de/leistungen/hr-agent/leave-absence-decision-layer/chemie/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Chemie</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">13 Tarifbezirke, Zukunftsbetrag-Freizeit, Schichtzusatzurlaub, Gefahrstoff-BEM</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">83% vollautomatisch</span>
<span class="text-small text-gosign-accent-text font-semibold">Im Detail &rarr;</span>
</div>
</a>
<a href="/de/leistungen/hr-agent/leave-absence-decision-layer/finanzwesen/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Finanzwesen</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">Pflichtfreistellung, MaRisk BTO 2.2 Urlaubsblöcke, Börsenfeiertage, Altersteilzeit</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">85% vollautomatisch</span>
<span class="text-small text-gosign-accent-text font-semibold">Im Detail &rarr;</span>
</div>
</a>
<a href="/de/leistungen/hr-agent/leave-absence-decision-layer/handel/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Handel</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">6-Tage-Woche, 64% Teilzeitquote, Urlaubssperren Saison, Minijobber-Ansprüche</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">87% vollautomatisch</span>
<span class="text-small text-gosign-accent-text font-semibold">Im Detail &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- AI Leave Agent Chemie - Abwesenheitsmanagement ---
> Leave Decision Layer für die Chemieindustrie. Zukunftsbetrag-Freizeit, Schichtzusatzurlaub, Gefahrstoff-BEM. 83% vollautomatisch.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/de/warum-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Jede Entscheidung nachvollziehbar</p>
</div>
</a>
<a href="/de/warum-gosign/#infrastruktur" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Ihre Infrastruktur</p>
<p class="text-xs text-gosign-text-light">Kein SaaS. Kein Vendor-Lock-in.</p>
</div>
</a>
<a href="/de/warum-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Kein US-Cloud-Risiko</p>
</div>
</a>
</div>
</div>
</div>



<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Leave Decision Layer Branchen">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/de/leistungen/hr-agent/leave-absence-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Leave Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/de/leistungen/hr-agent/leave-absence-decision-layer/chemie/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Chemie</a>
<a href="/de/leistungen/hr-agent/leave-absence-decision-layer/aviation/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Aviation</a>
<a href="/de/leistungen/hr-agent/leave-absence-decision-layer/finanzwesen/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Finanzwesen</a>
<a href="/de/leistungen/hr-agent/leave-absence-decision-layer/handel/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Handel</a>
</div>
</div>
</nav>

<!-- Komplexität -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">30+</span>
<p class="text-small text-gosign-text-light mt-1">Leave-Typen</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">83%</span>
<p class="text-small text-gosign-text-light mt-1">Automatisierungsquote</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">13</span>
<p class="text-small text-gosign-text-light mt-1">Tarifbezirke</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">Höchste Regelkomplexität</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">IG BCE Manteltarifvertrag Chemie. vollautomatisch: Gosign-Simulationsmodell.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Was der Agent klassifiziert</p>
<h2 class="text-h1 font-bold text-gosign-dark">Fünf Dimensionen, ein Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">30 Tage Grundurlaub, Schichtzusatzurlaub bis 5 Tage, Zukunftsbetrag-Freizeit-Option, Gefahrstoff-BEM, Minimalbesetzung im Continuous Process. Sie kennen die Komplexität. So löst der AI Agent sie:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Schichtzusatzurlaub nach Modell</h3>
<p class="text-body text-gosign-text mt-2">Vollkonti 5 Tage, Teilkonti 3 Tage, Wechselschicht 2 Tage. Der AI Agent erkennt das Schichtmodell aus dem Schichtplan und ordnet den korrekten Zusatzurlaub zu. Bei Schichtmodellwechsel berechnet das Regelwerk den anteiligen Anspruch automatisch - kein manuelles Nachrechnen bei 5.000 Schichtarbeitern.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Zukunftsbetrag-Freizeit-Option</h3>
<p class="text-body text-gosign-text mt-2">23% eines Monatsgehalts, wahlweise als freie Tage statt Auszahlung oder Altersvorsorge. Der AI Agent verwaltet das individuelle Wahlrecht, berechnet die resultierende Tagezahl und bucht sie korrekt ins Urlaubskonto. Bei jährlichem Wahlrechtwechsel: automatische Umstellung ab Folgemonat.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Gefahrstoff-BEM</h3>
<p class="text-body text-gosign-text mt-2">Bei Langzeitkrankheit von Mitarbeitern mit Gefahrstoffexposition ist die BEM-Relevanz besonders hoch - Berufskrankheiten müssen arbeitsmedizinisch begleitet werden. Der AI Agent erkennt die Exposition aus der Gefährdungsbeurteilung und flaggt BEM-Fälle für arbeitsmedizinische Begleitung. Gesundheitsdaten bleiben architektonisch separiert.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Minimalbesetzung Continuous Process</h3>
<p class="text-body text-gosign-text mt-2">In der Chemieproduktion läuft der Prozess rund um die Uhr. Der AI Agent prüft bei jeder Urlaubsanfrage die Schichtbesetzung gegen die Minimalbesetzungsregeln pro Schicht und Qualifikation. Bei Unterschreitung: automatische Eskalation mit Alternativvorschlag statt pauschalem Nein.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Altersurlaub nach Tarifbezirk</h3>
<p class="text-body text-gosign-text mt-2">Ab 50 Jahren zusätzliche Urlaubstage - tarifgebietabhängig mit unterschiedlichen Schwellen und Stufen. Der AI Agent berechnet den Altersurlaub automatisch aus Geburtsdatum und Tarifbezirk. Bei Geburtstag im laufenden Jahr: anteilige Berechnung ab dem relevanten Stichtag.</p>
</div>
</div>
</div>
</section>

<!-- Decision Flow -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Ein Urlaubsantrag in der Chemie. 10 Entscheidungsschritte.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Ein Schichtarbeiter im IG-BCE-Tarifgebiet stellt einen Urlaubsantrag. Der Leave Decision Layer zerlegt den Vorgang in einzelne Entscheidungsschritte:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Schritt</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Entscheidung</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Entscheider</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Begründung</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Leave-Typ klassifizieren</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent erkennt: Erholungsurlaub, Schichtzusatzurlaub, Zukunftsbetrag-Freizeit, Sonderurlaub oder Gleittag</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Tarifbezirk und Schichtmodell erkennen</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent erkennt Standort, Tarifbezirk und Schichtmodell aus Personalstamm und Schichtplan</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Gesamtanspruch berechnen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">30 Tage Grund + Schichtzusatz (2-5) + Altersurlaub + ggf. Zukunftsbetrag-Freizeit + SB-Zusatzurlaub</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Restanspruch berechnen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">Gesamtanspruch minus genommene und genehmigte Tage, inkl. Resturlaub Vorjahr</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Minimalbesetzung Schicht prüfen</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent prüft Schichtbesetzung gegen Minimalbesetzungsregeln pro Qualifikation</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Teamkonflikt erkennen</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent prüft: Kollegensperren, parallele Anträge, maximale Gleichzeitig-Abwesend-Quote</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Genehmigungsempfehlung erstellen</td><td class="py-3 px-4">KI empfiehlt, Mensch entscheidet</td><td class="py-3 px-4">Alle Regeln eingehalten: Empfehlung genehmigen. Konflikt: Eskalation mit Kontext an Führungskraft</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">BEM-Schwelle prüfen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">42+ AU-Tage in 12 Monaten rollierend. Bei Gefahrstoff-Exposition: zusätzliches Flag für arbeitsmedizinische Begleitung</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Lohnfortzahlung berechnen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">6 Wochen pro Krankheitsfall, danach Krankengeld. Wartezeit 4 Wochen bei Neueintritt</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Audit-Eintrag erzeugen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">Vollständige Entscheidungsakte: Leave-Typ, Anspruch, Prüfschritte, Ergebnis, Zeitstempel</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Simulation -->
<section id="simulation" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulation</p>
<h2 class="text-h1 font-bold text-white">Durchgerechnet für Chemie-Volumina</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Wir haben den Leave Decision Layer mit realistischen Chemie-Parametern konfiguriert und durchgerechnet. IG-BCE-Manteltarifvertrag, 13 Bezirke, Schichtmodelle, Zukunftsbetrag-Freizeit, Gefahrstoff-BEM.</p>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Simulationsparameter</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Mitarbeiter</td><td class="py-3 px-4">5.000 bis 50.000+ (Produktion, Labor, Verwaltung)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Tarifvertrag</td><td class="py-3 px-4">IG BCE Manteltarifvertrag Chemie, 13 Bezirke</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Grundurlaub</td><td class="py-3 px-4">30 Tage + Schichtzusatzurlaub (2-5 Tage) + Altersurlaub</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Schichtmodelle</td><td class="py-3 px-4">Vollkontischicht, Teilkontischicht, Wechselschicht, Normalschicht</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Zukunftsbetrag-Freizeit</td><td class="py-3 px-4">23% Monatsgehalt als freie Tage (individuelle Wahl)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">BEM-Quote</td><td class="py-3 px-4">Branchen-AU-Schnitt Chemie, inkl. Gefahrstoff-Exposition</td></tr>
</tbody>
</table>
</div>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Vorher / Nachher</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th scope="col" class="text-left py-3 px-4 font-semibold text-white">Dimension</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manuell</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Bearbeitungszeit Urlaubsantrag</td><td class="py-3 px-4">1-3 Tage</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 30 Sekunden</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Automatisierungsquote</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">83%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">BEM-Fristversäumnisse</td><td class="py-3 px-4">12-18% (manuelles Tracking)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">0% (automatischer Trigger)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Urlaubsverfall-Warnungen (BAG)</td><td class="py-3 px-4">Oft vergessen</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatisch, rechtzeitig, individuell</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Schichtzusatzurlaub-Berechnung</td><td class="py-3 px-4">Manuell, fehleranfällig</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Regelbasiert, konsistent</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Audit-Readiness</td><td class="py-3 px-4">Manuell rekonstruiert</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatisch erzeugt</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">IG BCE Manteltarifvertrag Chemie. BEM-Quoten: Wissenschaftliches Institut der AOK (WIdO). Simulationsergebnisse: Gosign-Modellrechnung.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">In der Simulation erreicht der Decision Layer eine Automatisierungsquote von 83%. Die verbleibenden 17% sind echte Ausnahmen: Urlaubskonflikte bei Minimalbesetzung, BEM-Prozesse, Zukunftsbetrag-Wahlrechtsänderungen mit Steuerauswirkung. Für die 83% liegt eine vollständige, prüfungssichere Entscheidungsakte vor.</p>
</div>
</section>

<!-- Architektur-Referenz -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Architektur und Implementierung</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">Der Leave Decision Layer läuft vollständig in Ihrer Infrastruktur. Für die Chemieindustrie bedeutet das: Anbindung an Schichtplanungssysteme, Verarbeitung von Gefahrstoff-Mappings, tarifbezirksspezifische Urlaubsregelwerke und durchgängiger Audit Trail bis SAP HCM. Typische Pilotprojekte starten innerhalb von 3 Monaten mit einem Tarifbezirk und einer Personalgruppe.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/de/leistungen/hr-agent/leave-absence-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Leave Decision Layer Übersicht &rarr;</a>
<a href="/de/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Decision Layer Architektur &rarr;</a>
<a href="/de/leistungen/infrastruktur/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infrastruktur im Detail &rarr;</a>
<a href="/de/governance/mitbestimmung/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Mitbestimmung &amp; Betriebsrat &rarr;</a>
<a href="/de/leistungen/hr-agent/payroll-decision-layer/chemie/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Payroll Decision Layer Chemie &rarr;</a>
</div>
</div>
</section>


<!-- Weitere Agent-Lösungen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Weitere Agent-Lösungen</h2>
<p class="text-body-lg text-gosign-text-light mt-4">HR Agents sind Teil unseres Agent-Portfolios. Für Finance und andere Bereiche bieten wir spezialisierte Lösungen.</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8 max-w-content">
<a href="/de/hr-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR & People Operations</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Alle HR Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Betriebsratsfähig.</p>
</a>
<a href="/de/finance-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Finance & Accounting</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Finance AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Belegverarbeitung, Kontierung, AfA-Logik, Korrekturbuchungen. DATEV- und SAP-Integration.</p>
</a>
<a href="/de/kontakt/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Individuell</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Co-Build für Ihren Prozess</h3>
<p class="text-body text-gosign-text-light mt-2">Compliance, Operations, Shared Services - wir entwickeln Agenten im Co-Build.</p>
</a>
</div>
</div>
</section>

<!-- Vertiefung -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Vertiefung im Agent Briefing (Gosign Magazin)</h2>
<p class="text-body text-gosign-text-light mb-6">Unsere Fachartikel-Serie für Entscheider, die AI Agents im Unternehmen einführen.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/de/magazin/betriebsrat-ki-mitbestimmung/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Mitbestimmung</p>
<p class="text-body font-semibold text-gosign-dark">Betriebsrat und KI - Mitbestimmung als Architektur-Constraint</p>
</a>
<a href="/de/magazin/agent-governance-hr/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Agent Governance für HR - Warum Regelwerke wichtiger sind als Modelle</p>
</a>
<a href="/de/magazin/decision-layer-erklaert/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Grundlagen</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - Was ist das und warum braucht jeder Enterprise AI Agent einen?</p>
</a>
</div>
</div>
</section>

<!-- Andere Branchen -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Leave Decision Layer in anderen Branchen</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Jede Branche hat eigene Tarifverträge, eigene Leave-Typen und eigene Komplexitätstreiber. Der Decision Layer ist derselbe. Die Konfiguration ist branchenspezifisch.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/de/leistungen/hr-agent/leave-absence-decision-layer/aviation/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Aviation</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">3 Gewerkschaften, EASA FTL Pflichtruhezeiten, Medical Grounding, Crew-Pairing</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">78% vollautomatisch</span>
<span class="text-small text-gosign-accent-text font-semibold">Im Detail &rarr;</span>
</div>
</a>
<a href="/de/leistungen/hr-agent/leave-absence-decision-layer/finanzwesen/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Finanzwesen</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">Pflichtfreistellung, MaRisk BTO 2.2 Urlaubsblöcke, Börsenfeiertage, Altersteilzeit</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">85% vollautomatisch</span>
<span class="text-small text-gosign-accent-text font-semibold">Im Detail &rarr;</span>
</div>
</a>
<a href="/de/leistungen/hr-agent/leave-absence-decision-layer/handel/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Handel</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">6-Tage-Woche, 64% Teilzeitquote, Urlaubssperren Saison, Minijobber-Ansprüche</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">87% vollautomatisch</span>
<span class="text-small text-gosign-accent-text font-semibold">Im Detail &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- AI Leave Agent Finanzwesen - Abwesenheitsmanagement ---
> Leave Decision Layer für Banken und Versicherungen. Pflichtfreistellung, MaRisk BTO 2.2, Börsenfeiertage. 85% vollautomatisch.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/de/warum-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Jede Entscheidung nachvollziehbar</p>
</div>
</a>
<a href="/de/warum-gosign/#infrastruktur" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Ihre Infrastruktur</p>
<p class="text-xs text-gosign-text-light">Kein SaaS. Kein Vendor-Lock-in.</p>
</div>
</a>
<a href="/de/warum-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Kein US-Cloud-Risiko</p>
</div>
</a>
</div>
</div>
</div>

<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Leave Decision Layer Branchen">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/de/leistungen/hr-agent/leave-absence-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Leave Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/de/leistungen/hr-agent/leave-absence-decision-layer/chemie/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Chemie</a>
<a href="/de/leistungen/hr-agent/leave-absence-decision-layer/aviation/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Aviation</a>
<a href="/de/leistungen/hr-agent/leave-absence-decision-layer/finanzwesen/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Finanzwesen</a>
<a href="/de/leistungen/hr-agent/leave-absence-decision-layer/handel/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Handel</a>
</div>
</div>
</nav>

<!-- Komplexität -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">5</span>
<p class="text-small text-gosign-text-light mt-1">Vergütungsregime</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">85%</span>
<p class="text-small text-gosign-text-light mt-1">Automatisierungsquote</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">MaRisk</span>
<p class="text-small text-gosign-text-light mt-1">BTO 2.2 Pflichtblöcke</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
<span class="w-4 h-2 rounded-sm bg-gosign-border"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">Hohe Regelkomplexität</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">Tarifvertrag Banken (AGV), Tarifvertrag Versicherungen (AGV). MaRisk BTO 2.2. vollautomatisch: Gosign-Simulationsmodell.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Was der Agent klassifiziert</p>
<h2 class="text-h1 font-bold text-gosign-dark">Fünf Dimensionen, ein Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Pflichtfreistellung nach Vier-Augen-Prinzip, MaRisk-Pflichtblöcke, Börsenfeiertage, Altersteilzeit und 5 parallele Vergütungsregime. Sie kennen die Komplexität. So löst der AI Agent sie:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Pflichtfreistellung (Vier-Augen-Prinzip)</h3>
<p class="text-body text-gosign-text mt-2">Mitarbeiter in handelsrelevanten Positionen müssen mindestens einmal jährlich zusammenhängend freigestellt werden. Der AI Agent erkennt pflichtfreistellungspflichtige Positionen aus dem Personalstamm, prüft ob der beantragte Urlaub die Mindestblockdauer erfüllt und trackt, ob die Pflichtfreistellung im laufenden Jahr bereits erfolgt ist.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">MaRisk BTO 2.2 Pflicht-Urlaubsblöcke</h3>
<p class="text-body text-gosign-text mt-2">BaFin-Regulatorik fordert zusammenhängende Urlaubsblöcke für Mitarbeiter in risikorelevanten Positionen. Der AI Agent trackt die Frist, warnt rechtzeitig bei fehlendem Pflichtblock und dokumentiert die Einhaltung im Audit Trail. Bei BaFin-Prüfung: Export des vollständigen Compliance-Status pro Mitarbeiter.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Börsenfeiertage und Handelskalender</h3>
<p class="text-body text-gosign-text mt-2">Börsenfeiertage sind nicht in allen Bundesländern gesetzliche Feiertage, aber für Handelsabteilungen operativ relevant. Der AI Agent kennt den Kalender pro Standort und Handelsplatz und berücksichtigt Börsenfeiertage bei der Besetzungsplanung automatisch - keine manuelle Kalender-Abstimmung.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Altersteilzeit im Blockmodell</h3>
<p class="text-body text-gosign-text mt-2">Altersteilzeit ist im Finanzwesen weit verbreitet. Der AI Agent berechnet den Urlaubsanspruch korrekt je Phase: voller Anspruch in der Arbeitsphase, kein Anspruch in der Freizeitphase (Blockmodell). Bei Teilzeitmodell: anteiliger Anspruch während der gesamten Laufzeit. SV-Auswirkungen werden an das Payroll-System gemeldet.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Fünf Vergütungsregime parallel</h3>
<p class="text-body text-gosign-text mt-2">Tarifvertrag Banken, Tarifvertrag Versicherungen, außertarifliche Verträge (inkl. Investment Banking mit eigenen Bonus-Deferral- und Garden-Leave-Regeln), leitende Angestellte, Vorstand - jedes Regime hat eigene Urlaubsregelungen und Sonderurlaube. Der AI Agent erkennt das Regime aus dem Personalstamm und wendet das korrekte Regelwerk an. Ein Agent für alle fünf Regime.</p>
</div>
</div>
</div>
</section>

<!-- Decision Flow -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Ein Urlaubsantrag im Finanzwesen. 10 Entscheidungsschritte.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Ein Händler stellt einen Urlaubsantrag. Der Leave Decision Layer zerlegt den Vorgang in einzelne Entscheidungsschritte:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Schritt</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Entscheidung</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Entscheider</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Begründung</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Leave-Typ klassifizieren</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent erkennt: Erholungsurlaub, Pflichtfreistellung, Altersteilzeit-Phase oder Sonderurlaub</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Vergütungsregime erkennen</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent erkennt: Tarif Banken, Tarif Versicherungen, AT, Leitende oder Vorstand</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Urlaubsanspruch berechnen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">30 Tage Grund (Tarif) oder individueller Anspruch (AT/Vorstand) + Altersteilzeit-Korrektur</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Pflichtfreistellung prüfen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">Handelsrelevante Position? Mindestblockdauer erreicht? Pflichtfreistellung im laufenden Jahr schon erfolgt?</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">MaRisk BTO 2.2 prüfen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">Risikorelevante Position? Zusammenhängender Pflichtblock bereits geplant?</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Börsenfeiertage und Besetzung prüfen</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent prüft Handelskalender, Mindestbesetzung Handelsabteilung, Vertretungsregelung</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Genehmigungsempfehlung erstellen</td><td class="py-3 px-4">KI empfiehlt, Mensch entscheidet</td><td class="py-3 px-4">Alle Regeln und Compliance-Checks bestanden: Empfehlung genehmigen. Compliance-Konflikt: Eskalation</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">BEM-Schwelle prüfen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">42+ AU-Tage in 12 Monaten rollierend. Automatischer Trigger an HR und Betriebsrat</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Lohnfortzahlung berechnen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">6 Wochen pro Krankheitsfall, tarifvertragsspezifische Aufstockung prüfen</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Audit-Eintrag erzeugen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">Vollständige Entscheidungsakte: Leave-Typ, Regime, Compliance-Status, MaRisk-Check, Ergebnis</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Simulation -->
<section id="simulation" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulation</p>
<h2 class="text-h1 font-bold text-white">Durchgerechnet für Finanzwesen-Volumina</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Wir haben den Leave Decision Layer mit realistischen Finanzwesen-Parametern konfiguriert und durchgerechnet. Pflichtfreistellung, MaRisk BTO 2.2, Börsenfeiertage, Altersteilzeit.</p>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Simulationsparameter</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Mitarbeiter</td><td class="py-3 px-4">5.000 bis 80.000+ (Handel/IB, Operations, Verwaltung, IT)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Tarifverträge</td><td class="py-3 px-4">AGV Banken, AGV Versicherungen, AT-Verträge (inkl. IB), Leitende Angestellte</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Regulatorik</td><td class="py-3 px-4">MaRisk BTO 2.2, BaFin-Anforderungen, Pflichtfreistellung</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Leave-Typen</td><td class="py-3 px-4">Erholungsurlaub, Pflichtfreistellung, Altersteilzeit, Bildungsurlaub, Sonderurlaub</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Constraints</td><td class="py-3 px-4">Vier-Augen-Prinzip, Börsenfeiertage, Mindestbesetzung Handel</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">BEM-Quote</td><td class="py-3 px-4">Branchen-AU-Schnitt Finanzdienstleistungen</td></tr>
</tbody>
</table>
</div>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Vorher / Nachher</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th scope="col" class="text-left py-3 px-4 font-semibold text-white">Dimension</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manuell</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Bearbeitungszeit Urlaubsantrag</td><td class="py-3 px-4">1-3 Tage</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 30 Sekunden</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Automatisierungsquote</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">85%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">MaRisk-Pflichtblock versäumt</td><td class="py-3 px-4">8-15% (manuelles Tracking)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">0% (automatische Fristüberwachung)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Pflichtfreistellung lückenlos</td><td class="py-3 px-4">Manuell geprüft</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatisch, BaFin-prüfungssicher</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">BEM-Fristversäumnisse</td><td class="py-3 px-4">12-18%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">0% (automatischer Trigger)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Audit-Readiness</td><td class="py-3 px-4">Manuell rekonstruiert</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatisch erzeugt</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">MaRisk BTO 2.2 (BaFin). AGV Banken/Versicherungen. BEM-Quoten: WIdO. Simulationsergebnisse: Gosign-Modellrechnung.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">In der Simulation erreicht der Decision Layer eine Automatisierungsquote von 85%. Die verbleibenden 15% sind Compliance-relevante Ausnahmen: Pflichtfreistellungs-Konflikte, Altersteilzeit-Phasenübergänge, individuelle AT-Vereinbarungen. Für die 85% liegt eine vollständige, BaFin-prüfungssichere Entscheidungsakte vor.</p>
</div>
</section>

<!-- Architektur-Referenz -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Architektur und Implementierung</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">Der Leave Decision Layer läuft vollständig in Ihrer Infrastruktur. Für das Finanzwesen bedeutet das: Anbindung an Handelskalender, MaRisk-Compliance-Tracking, Pflichtfreistellungs-Monitoring und durchgängiger Audit Trail. Typische Pilotprojekte starten mit einem Vergütungsregime und erweitern auf alle Mitarbeitergruppen.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/de/leistungen/hr-agent/leave-absence-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Leave Decision Layer Übersicht &rarr;</a>
<a href="/de/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Decision Layer Architektur &rarr;</a>
<a href="/de/leistungen/infrastruktur/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infrastruktur im Detail &rarr;</a>
<a href="/de/governance/mitbestimmung/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Mitbestimmung &amp; Betriebsrat &rarr;</a>
<a href="/de/leistungen/hr-agent/payroll-decision-layer/finanzwesen/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Payroll Decision Layer Finanzwesen &rarr;</a>
</div>
</div>
</section>


<!-- Weitere Agent-Lösungen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Weitere Agent-Lösungen</h2>
<p class="text-body-lg text-gosign-text-light mt-4">HR Agents sind Teil unseres Agent-Portfolios. Für Finance und andere Bereiche bieten wir spezialisierte Lösungen.</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8 max-w-content">
<a href="/de/hr-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR & People Operations</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Alle HR Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Betriebsratsfähig.</p>
</a>
<a href="/de/finance-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Finance & Accounting</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Finance AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Belegverarbeitung, Kontierung, AfA-Logik, Korrekturbuchungen. DATEV- und SAP-Integration.</p>
</a>
<a href="/de/kontakt/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Individuell</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Co-Build für Ihren Prozess</h3>
<p class="text-body text-gosign-text-light mt-2">Compliance, Operations, Shared Services - wir entwickeln Agenten im Co-Build.</p>
</a>
</div>
</div>
</section>

<!-- Vertiefung -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Vertiefung im Agent Briefing (Gosign Magazin)</h2>
<p class="text-body text-gosign-text-light mb-6">Unsere Fachartikel-Serie für Entscheider, die AI Agents im Unternehmen einführen.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/de/magazin/betriebsrat-ki-mitbestimmung/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Mitbestimmung</p>
<p class="text-body font-semibold text-gosign-dark">Betriebsrat und KI - Mitbestimmung als Architektur-Constraint</p>
</a>
<a href="/de/magazin/agent-governance-hr/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Agent Governance für HR - Warum Regelwerke wichtiger sind als Modelle</p>
</a>
<a href="/de/magazin/decision-layer-erklaert/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Grundlagen</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - Was ist das und warum braucht jeder Enterprise AI Agent einen?</p>
</a>
</div>
</div>
</section>

<!-- Andere Branchen -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Leave Decision Layer in anderen Branchen</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Jede Branche hat eigene Tarifverträge, eigene Leave-Typen und eigene Komplexitätstreiber. Der Decision Layer ist derselbe. Die Konfiguration ist branchenspezifisch.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/de/leistungen/hr-agent/leave-absence-decision-layer/chemie/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Chemie</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">13 Tarifbezirke, Zukunftsbetrag-Freizeit, Schichtzusatzurlaub, Gefahrstoff-BEM</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">83% vollautomatisch</span>
<span class="text-small text-gosign-accent-text font-semibold">Im Detail &rarr;</span>
</div>
</a>
<a href="/de/leistungen/hr-agent/leave-absence-decision-layer/aviation/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Aviation</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">3 Gewerkschaften, EASA FTL Pflichtruhezeiten, Medical Grounding, Crew-Pairing</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">78% vollautomatisch</span>
<span class="text-small text-gosign-accent-text font-semibold">Im Detail &rarr;</span>
</div>
</a>
<a href="/de/leistungen/hr-agent/leave-absence-decision-layer/handel/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Handel</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">6-Tage-Woche, 64% Teilzeitquote, Urlaubssperren Saison, Minijobber-Ansprüche</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">87% vollautomatisch</span>
<span class="text-small text-gosign-accent-text font-semibold">Im Detail &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- AI Leave Agent Handel - Abwesenheitsmanagement ---
> Leave Decision Layer für den Einzelhandel. 6-Tage-Woche, 64% Teilzeit, Urlaubssperren, 16 Tarifverträge. 87% vollautomatisch.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/de/warum-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Jede Entscheidung nachvollziehbar</p>
</div>
</a>
<a href="/de/warum-gosign/#infrastruktur" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Ihre Infrastruktur</p>
<p class="text-xs text-gosign-text-light">Kein SaaS. Kein Vendor-Lock-in.</p>
</div>
</a>
<a href="/de/warum-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Kein US-Cloud-Risiko</p>
</div>
</a>
</div>
</div>
</div>
<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Leave Decision Layer Branchen">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/de/leistungen/hr-agent/leave-absence-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Leave Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/de/leistungen/hr-agent/leave-absence-decision-layer/chemie/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Chemie</a>
<a href="/de/leistungen/hr-agent/leave-absence-decision-layer/aviation/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Aviation</a>
<a href="/de/leistungen/hr-agent/leave-absence-decision-layer/finanzwesen/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Finanzwesen</a>
<a href="/de/leistungen/hr-agent/leave-absence-decision-layer/handel/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Handel</a>
</div>
</div>
</nav>

<!-- Komplexität -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">16</span>
<p class="text-small text-gosign-text-light mt-1">Regionale Tarifverträge</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">87%</span>
<p class="text-small text-gosign-text-light mt-1">Automatisierungsquote</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">64%</span>
<p class="text-small text-gosign-text-light mt-1">Teilzeitquote</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
<span class="w-4 h-2 rounded-sm bg-gosign-border"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">Hohe Regelkomplexität</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">Manteltarifvertrag Einzelhandel (ver.di), 16 Regionalverträge. vollautomatisch: Gosign-Simulationsmodell.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Was der Agent klassifiziert</p>
<h2 class="text-h1 font-bold text-gosign-dark">Fünf Dimensionen, ein Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">6-Tage-Woche mit Samstagsarbeit, 64% Teilzeitquote, saisonale Urlaubssperren, Minijobber mit schwankenden Stunden und 16 regionale Tarifverträge. Sie kennen die Komplexität. So löst der AI Agent sie:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">6-Tage-Woche und Werktage-Umrechnung</h3>
<p class="text-body text-gosign-text mt-2">Im Einzelhandel ist Samstag ein regulärer Arbeitstag. Der Tarifvertrag gewährt 36 Werktage Urlaub (= 30 Arbeitstage bei 5-Tage-Woche). Der AI Agent erkennt das Arbeitszeitmodell aus dem Personalstamm und rechnet den Anspruch automatisch in Arbeitstage um. Bei Wechsel zwischen 5- und 6-Tage-Woche: anteilige Neuberechnung ab Stichtag.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Teilzeit-Urlaubsberechnung für 64% der Belegschaft</h3>
<p class="text-body text-gosign-text mt-2">Mehr als die Hälfte aller Mitarbeiter im Handel arbeiten Teilzeit - mit unterschiedlichen Modellen. Der AI Agent berechnet den anteiligen Urlaubsanspruch pro Modell: 3-Tage-Woche, 4-Tage-Woche, Stunden-Teilzeit, flexible Teilzeit. Das Regelwerk wendet die korrekte Formel an, konsistent über alle Filialen.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Saisonale Urlaubssperren</h3>
<p class="text-body text-gosign-text mt-2">Weihnachtsgeschäft (November bis Dezember), Schlussverkauf, Inventur - der Handel kennt klare Sperrperioden. Der AI Agent kennt die Sperrperioden pro Filiale (nicht alle Filialen haben die gleichen Sperren) und prüft jeden Antrag dagegen. Ausnahmen sind möglich, erfordern aber eine Führungskraft-Entscheidung.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Minijobber-Ansprüche</h3>
<p class="text-body text-gosign-text mt-2">Minijobber auf Abruf haben den gleichen anteiligen Urlaubsanspruch wie Vollzeitkräfte. Der AI Agent berechnet den Anspruch auf Basis der Durchschnittsstunden der letzten 3 Monate - auch bei schwankenden Einsatzzeiten. Bei Stundenwechsel: automatische Neuberechnung des rollierenden Durchschnitts.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">16 regionale Tarifverträge</h3>
<p class="text-body text-gosign-text mt-2">Jedes Bundesland hat einen eigenen Tarifvertrag Einzelhandel, teils mit Ost/West-Unterschieden. Der AI Agent erkennt den Filialstandort und wendet den korrekten regionalen Tarifvertrag an. Bei Versetzung zwischen Filialen in verschiedenen Bundesländern: automatischer Tarifwechsel mit Anspruchs-Neuberechnung.</p>
</div>
</div>
</div>
</section>

<!-- Decision Flow -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Ein Urlaubsantrag im Handel. 10 Entscheidungsschritte.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Eine Teilzeitkraft in einer Filiale stellt einen Urlaubsantrag. Der Leave Decision Layer zerlegt den Vorgang in einzelne Entscheidungsschritte:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Schritt</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Entscheidung</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Entscheider</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Begründung</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Leave-Typ klassifizieren</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent erkennt: Erholungsurlaub, Bildungsurlaub, Sonderurlaub oder Gleittag</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Regionalen Tarifvertrag erkennen</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent erkennt Filialstandort und wendet den korrekten der 16 regionalen Tarifverträge an</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Urlaubsanspruch berechnen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">Tarifanspruch umgerechnet auf Arbeitstage (5- oder 6-Tage-Woche), Teilzeit-Faktor, Minijobber-Durchschnitt</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Urlaubssperre prüfen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">Weihnachtsgeschäft, Schlussverkauf, Inventur - filialspezifische Sperrperioden</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Filial-Mindestbesetzung prüfen</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent prüft Besetzungsplan: oft nur 2-3 Personen pro Filiale, jede Abwesenheit zählt</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Teamkonflikt erkennen</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent prüft parallele Anträge, Schulferien-Verteilung (soziale Gesichtspunkte)</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Genehmigungsempfehlung erstellen</td><td class="py-3 px-4">KI empfiehlt, Mensch entscheidet</td><td class="py-3 px-4">Alle Regeln eingehalten: Empfehlung genehmigen. Sperrperiode oder Mindestbesetzung verletzt: Eskalation</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">BEM-Schwelle prüfen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">42+ AU-Tage in 12 Monaten rollierend. Automatischer Trigger an HR und Betriebsrat</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Lohnfortzahlung berechnen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">6 Wochen pro Krankheitsfall, Minijobber-Sonderregeln (Umlageverfahren U1)</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Audit-Eintrag erzeugen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">Vollständige Entscheidungsakte: Leave-Typ, Tarifvertrag, Teilzeit-Faktor, Sperrprüfung, Ergebnis</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Simulation -->
<section id="simulation" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulation</p>
<h2 class="text-h1 font-bold text-white">Durchgerechnet für Handels-Volumina</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Wir haben den Leave Decision Layer mit realistischen Handels-Parametern konfiguriert und durchgerechnet. 16 regionale Tarifverträge, 6-Tage-Woche, 64% Teilzeit, saisonale Urlaubssperren.</p>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Simulationsparameter</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Mitarbeiter</td><td class="py-3 px-4">5.000 bis 100.000+ (Filialen, Lager, Verwaltung)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Tarifverträge</td><td class="py-3 px-4">16 regionale Manteltarifverträge Einzelhandel (ver.di)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Arbeitszeitmodelle</td><td class="py-3 px-4">5-Tage-Woche, 6-Tage-Woche, Teilzeit (3/4 Tage), Minijob, Abrufarbeit</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Teilzeitquote</td><td class="py-3 px-4">64% der Belegschaft</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Urlaubssperren</td><td class="py-3 px-4">Weihnachtsgeschäft, Schlussverkauf, Inventur (filialspezifisch)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">BEM-Quote</td><td class="py-3 px-4">Branchen-AU-Schnitt Einzelhandel</td></tr>
</tbody>
</table>
</div>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Vorher / Nachher</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th scope="col" class="text-left py-3 px-4 font-semibold text-white">Dimension</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manuell</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Bearbeitungszeit Urlaubsantrag</td><td class="py-3 px-4">1-3 Tage</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 30 Sekunden</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Automatisierungsquote</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">87%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Teilzeit-Berechnungsfehler</td><td class="py-3 px-4">5-12% (manuelle Umrechnung)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 0,1% (regelbasiert)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Urlaubsverfall-Warnungen (BAG)</td><td class="py-3 px-4">Oft vergessen bei Teilzeit</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatisch, rechtzeitig, individuell</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">BEM-Fristversäumnisse</td><td class="py-3 px-4">12-18%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">0% (automatischer Trigger)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Audit-Readiness</td><td class="py-3 px-4">Manuell rekonstruiert</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatisch erzeugt</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">Manteltarifvertrag Einzelhandel (ver.di). BEM-Quoten: WIdO. Teilzeitquote: HDE Einzelhandelsverband. Simulationsergebnisse: Gosign-Modellrechnung.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">In der Simulation erreicht der Decision Layer eine Automatisierungsquote von 87%. Die höchste Quote aller vier Branchen - weil der Handel zwar volumenstark ist (viele Anträge), aber die einzelnen Entscheidungen regelbasiert lösbar sind. Die verbleibenden 13% sind echte Ausnahmen: Schulferien-Konflikte, Sperr-Ausnahmen, BEM-Prozesse. Für die 87% liegt eine vollständige, prüfungssichere Entscheidungsakte vor.</p>
</div>
</section>

<!-- Architektur-Referenz -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Architektur und Implementierung</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">Der Leave Decision Layer läuft vollständig in Ihrer Infrastruktur. Für den Handel bedeutet das: Anbindung an Filial-Besetzungsplanung, Verarbeitung von 16 regionalen Tarifverträgen, Teilzeit-Modell-Erkennung und durchgängiger Audit Trail. Bei dezentralen Strukturen (Genossenschaften, Franchise, selbständige Kaufleute) startet das Pilotprojekt mit einer Vertriebslinie und einer Region - die Erweiterung auf weitere Gesellschaften läuft parallel, ohne den laufenden Betrieb zu unterbrechen.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/de/leistungen/hr-agent/leave-absence-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Leave Decision Layer Übersicht &rarr;</a>
<a href="/de/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Decision Layer Architektur &rarr;</a>
<a href="/de/leistungen/infrastruktur/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infrastruktur im Detail &rarr;</a>
<a href="/de/governance/mitbestimmung/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Mitbestimmung &amp; Betriebsrat &rarr;</a>
<a href="/de/leistungen/hr-agent/payroll-decision-layer/handel/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Payroll Decision Layer Handel &rarr;</a>
</div>
</div>
</section>


<!-- Weitere Agent-Lösungen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Weitere Agent-Lösungen</h2>
<p class="text-body-lg text-gosign-text-light mt-4">HR Agents sind Teil unseres Agent-Portfolios. Für Finance und andere Bereiche bieten wir spezialisierte Lösungen.</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8 max-w-content">
<a href="/de/hr-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR & People Operations</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Alle HR Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Betriebsratsfähig.</p>
</a>
<a href="/de/finance-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Finance & Accounting</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Finance AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Belegverarbeitung, Kontierung, AfA-Logik, Korrekturbuchungen. DATEV- und SAP-Integration.</p>
</a>
<a href="/de/kontakt/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Individuell</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Co-Build für Ihren Prozess</h3>
<p class="text-body text-gosign-text-light mt-2">Compliance, Operations, Shared Services - wir entwickeln Agenten im Co-Build.</p>
</a>
</div>
</div>
</section>

<!-- Vertiefung -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Vertiefung im Agent Briefing (Gosign Magazin)</h2>
<p class="text-body text-gosign-text-light mb-6">Unsere Fachartikel-Serie für Entscheider, die AI Agents im Unternehmen einführen.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/de/magazin/betriebsrat-ki-mitbestimmung/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Mitbestimmung</p>
<p class="text-body font-semibold text-gosign-dark">Betriebsrat und KI - Mitbestimmung als Architektur-Constraint</p>
</a>
<a href="/de/magazin/agent-governance-hr/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Agent Governance für HR - Warum Regelwerke wichtiger sind als Modelle</p>
</a>
<a href="/de/magazin/decision-layer-erklaert/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Grundlagen</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - Was ist das und warum braucht jeder Enterprise AI Agent einen?</p>
</a>
</div>
</div>
</section>

<!-- Andere Branchen -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Leave Decision Layer in anderen Branchen</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Jede Branche hat eigene Tarifverträge, eigene Leave-Typen und eigene Komplexitätstreiber. Der Decision Layer ist derselbe. Die Konfiguration ist branchenspezifisch.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/de/leistungen/hr-agent/leave-absence-decision-layer/chemie/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Chemie</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">13 Tarifbezirke, Zukunftsbetrag-Freizeit, Schichtzusatzurlaub, Gefahrstoff-BEM</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">83% vollautomatisch</span>
<span class="text-small text-gosign-accent-text font-semibold">Im Detail &rarr;</span>
</div>
</a>
<a href="/de/leistungen/hr-agent/leave-absence-decision-layer/aviation/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Aviation</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">3 Gewerkschaften, EASA FTL Pflichtruhezeiten, Medical Grounding, Crew-Pairing</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">78% vollautomatisch</span>
<span class="text-small text-gosign-accent-text font-semibold">Im Detail &rarr;</span>
</div>
</a>
<a href="/de/leistungen/hr-agent/leave-absence-decision-layer/finanzwesen/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Finanzwesen</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">Pflichtfreistellung, MaRisk BTO 2.2 Urlaubsblöcke, Börsenfeiertage, Altersteilzeit</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">85% vollautomatisch</span>
<span class="text-small text-gosign-accent-text font-semibold">Im Detail &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- AI Leave & Absence Decision Layer ---
> Der Decision Layer zerlegt jeden Abwesenheitsvorgang in Entscheidungsschritte. Regelbasiert, auditierbar, 78-87% vollautomatisch.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/de/warum-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Jede Entscheidung nachvollziehbar</p>
</div>
</a>
<a href="/de/warum-gosign/#infrastruktur" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Ihre Infrastruktur</p>
<p class="text-xs text-gosign-text-light">Kein SaaS. Kein Vendor-Lock-in.</p>
</div>
</a>
<a href="/de/warum-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Kein US-Cloud-Risiko</p>
</div>
</a>
</div>
</div>
</div>
<!-- Problem -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">14,8</span>
<p class="text-small text-gosign-text-light mt-1">AU-Tage pro Beschäftigtem (2024)</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">30+</span>
<p class="text-small text-gosign-text-light mt-1">Leave-Typen (gesetzlich, tariflich, BV)</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">5-15</span>
<p class="text-small text-gosign-text-light mt-1">Mikro-Entscheidungen pro Vorgang</p>
</div>
<p class="sm:col-span-3 text-xs text-gosign-text-light">Krankenstand 2024: Statista / Techniker Krankenkasse Gesundheitsreport. Leave-Typen: BUrlG, EFZG, MuSchG, BEEG, PflegeZG, SGB IX, 15 Landesgesetze + Tarifverträge + Betriebsvereinbarungen.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Das Problem</p>
<h2 class="text-h1 font-bold text-gosign-dark">Warum Absence-Systeme in komplexen Organisationen scheitern</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">SAP SuccessFactors Time Off erfasst Abwesenheiten. Workday Absence berechnet Salden. Jedes HRIS kann Genehmigungsworkflows abbilden. Aber in Organisationen mit mehreren Tarifverträgen, 16 Bundesländern, Teilzeitmodellen und BEM-Pflichten ist die Erfassung nicht das Problem. Die Entscheidung davor ist es: Welcher Anspruch gilt? Welche Policy hat Vorrang? Muss BEM eingeleitet werden?</p>
<div class="mt-10">
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">30+ Leave-Typen</h3>
<p class="text-small text-gosign-text-light mt-2">Erholungsurlaub, Sonderurlaub, Bildungsurlaub, Mutterschutz, Elternzeit, Pflegezeit, Kindkrank, Schwerbehinderten-Zusatzurlaub, T-ZUG freie Tage, Gleittage, Betriebsferien, Sabbatical. Jeder Typ hat eigene Rechtsgrundlagen, eigene Fristen, eigene Berechnungsregeln. 15 Bildungsurlaubs-Landesgesetze. 16 Feiertagskalender. Kein Sachbearbeiter kennt alle Regeln in allen Tarifgebieten und Bundesländern.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">Jede Krankmeldung zieht 5 Folgeprozesse</h3>
<p class="text-small text-gosign-text-light mt-2">eAU von der Krankenkasse verarbeiten, Lohnfortzahlungsfrist prüfen (6 Wochen pro Fall), BEM-Schwelle überwachen (42 AU-Tage rollierend), Schichtplanung informieren, Payroll rückschreiben. Manuell: Medienbrüche zwischen fünf Systemen. Vergessene BEM-Trigger. Falsche Lohnfortzahlungsgrenzen.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">Null Entscheidungs-Transparenz</h3>
<p class="text-small text-gosign-text-light mt-2">Wenn der Betriebsrat fragt: Warum wurde der Urlaub von Mitarbeiter X abgelehnt? Welche Regel galt? Wer hat entschieden? Dann fehlt der Nachweis. Absence-Systeme dokumentieren Ergebnisse - genehmigte oder abgelehnte Anträge. Nicht die Entscheidungen, die dazu geführt haben.</p>
</div>
</div>
</div>
</div>
</section>

<!-- Decision Layer Prinzip -->
<section id="decision-layer" class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Der Decision Layer</p>
<h2 class="text-h1 font-bold text-gosign-dark">Jeder Abwesenheitsvorgang. Zerlegt in Entscheidungsschritte.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Der Leave & Absence Decision Layer zerlegt jeden Abwesenheitsvorgang in einzelne Entscheidungsschritte. Für jeden Schritt ist definiert, wer entscheidet: Der AI Agent klassifiziert Leave-Typen, erkennt Konflikte und überwacht Schwellenwerte - zuverlässiger und schneller als jeder Sachbearbeiter. Das Regelwerk berechnet Ansprüche, Fristen und Umrechnungen - deterministisch und reproduzierbar. Der Mensch bleibt dort im Prozess, wo Betriebsrat (BetrVG § 87 Abs. 1 Nr. 5), Arbeitsrecht oder Gesundheitsdatenschutz eine menschliche Entscheidung verlangen.</p>

<div class="mt-10 overflow-x-auto">
<table class="w-full text-left text-body">
<thead>
<tr class="border-b-2 border-gosign-dark">
<th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Schritt</th>
<th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Entscheidung</th>
<th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Entscheider</th>
<th scope="col" class="py-3 font-bold text-gosign-dark">Begründung</th>
</tr>
</thead>
<tbody class="text-gosign-text-light">
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-medium text-gosign-dark">1</td>
<td class="py-3 pr-4">Leave-Typ klassifizieren</td>
<td class="py-3 pr-4 font-medium">AI Agent</td>
<td class="py-3">Agent erkennt aus Antrag oder Freitext: Erholungsurlaub, Sonderurlaub, Bildungsurlaub, Gleittag, Kindkrank? Ordnet korrekte Rechtsgrundlage zu</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-medium text-gosign-dark">2</td>
<td class="py-3 pr-4">Anspruch berechnen (Hierarchie)</td>
<td class="py-3 pr-4 font-medium">Regelwerk</td>
<td class="py-3">Gesetz (BUrlG) + Tarifvertrag + Betriebsvereinbarung + Arbeitsvertrag = Gesamtanspruch. Günstigkeitsprinzip anwenden</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-medium text-gosign-dark">3</td>
<td class="py-3 pr-4">Restanspruch ermitteln</td>
<td class="py-3 pr-4 font-medium">Regelwerk</td>
<td class="py-3">Anspruch - genommen - geplant = verfügbar. Bei Teilzeitwechsel: anteilige Umrechnung nach BAG-Rechtsprechung</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-medium text-gosign-dark">4</td>
<td class="py-3 pr-4">Teamkonflikt und Minimalbesetzung prüfen</td>
<td class="py-3 pr-4 font-medium">AI Agent</td>
<td class="py-3">Agent prüft Teamkalender, Betriebsferien, Minimalbesetzung. Erkennt Überlappungen und berechnet verfügbare Kapazität</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-medium text-gosign-dark">5</td>
<td class="py-3 pr-4">Genehmigungsempfehlung erzeugen</td>
<td class="py-3 pr-4 font-medium">AI Agent + Regelwerk</td>
<td class="py-3">Alle Regeln eingehalten → "Genehmigung empfohlen" an Führungskraft. Weiterleitung mit Kontext und Empfehlung</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-medium text-gosign-dark">6</td>
<td class="py-3 pr-4">Urlaubskonflikt eskalieren</td>
<td class="py-3 pr-4 font-medium">Mensch</td>
<td class="py-3">Zwei Mitarbeiter, selbe Woche, Minimalbesetzung unterschritten. Soziale Gesichtspunkte (Schulkinder, Alleinerziehende) erfordern menschliches Ermessen - BetrVG § 87 Abs. 1 Nr. 5</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-medium text-gosign-dark">7</td>
<td class="py-3 pr-4">Lohnfortzahlungsfrist berechnen</td>
<td class="py-3 pr-4 font-medium">Regelwerk</td>
<td class="py-3">42 Kalendertage pro Krankheitsfall (EFZG § 3). Bei Wiedererkrankung: 6-Monats-Frist und Vorbeschäftigungsregel prüfen</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-medium text-gosign-dark">8</td>
<td class="py-3 pr-4">BEM-Schwelle prüfen</td>
<td class="py-3 pr-4 font-medium">Regelwerk</td>
<td class="py-3">42+ AU-Tage in 12 Monaten (rollierend, SGB IX § 167). Automatischer Trigger an HR und Betriebsrat. Gesundheitsdaten separiert</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-medium text-gosign-dark">9</td>
<td class="py-3 pr-4">eAU verarbeiten und rückschreiben</td>
<td class="py-3 pr-4 font-medium">Regelwerk</td>
<td class="py-3">Elektronische AU von Krankenkasse → Abwesenheit buchen → Payroll und Schichtplanung informieren → Kalender aktualisieren</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-medium text-gosign-dark">10</td>
<td class="py-3 pr-4">Audit-Eintrag erzeugen</td>
<td class="py-3 pr-4 font-medium">Regelwerk</td>
<td class="py-3">Entscheidung, Regelgrundlage, Entscheider, Zeitstempel, Input-Hash - append-only, SHA-256 signiert</td>
</tr>
</tbody>
</table>
</div>

<p class="text-body text-gosign-text mt-8 max-w-narrow font-semibold">5 bis 15 Schritte pro Abwesenheitsvorgang. Der AI Agent kann jeden davon besser und schneller als ein Sachbearbeiter. Trotzdem bleibt der Mensch an definierten Stellen im Prozess - nicht weil er es besser kann, sondern weil Betriebsrat, Arbeitsrecht oder Gesundheitsdatenschutz es verlangen. Bei 10.000 Mitarbeitern sind das 50.000+ dokumentierte Mikro-Entscheidungen pro Monat.</p>

<div class="mt-10">
<div class="grid grid-cols-1 sm:grid-cols-2 gap-6">
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">KI klassifiziert. Regelwerk berechnet.</h3>
<p class="text-small text-gosign-text-light mt-2">Der AI Agent erkennt: Welcher Leave-Typ? Welche Rechtsgrundlage? Gibt es einen Teamkonflikt? Hat der Mitarbeiter die BEM-Schwelle erreicht? Diese Klassifikation kann er zuverlässiger als jeder Sachbearbeiter. Die Berechnung von Ansprüchen, Fristen und Umrechnungen läuft dann durch versionierte Decision Tables - deterministisch, reproduzierbar, auditierbar.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">BEM architektonisch separiert</h3>
<p class="text-small text-gosign-text-light mt-2">Gesundheitsdaten sind besondere Kategorie (DSGVO Art. 9). Kein Mischmasch aus Urlaubsdaten und Diagnosen. Das BEM-Modul hat eigene Datenbank, eigenen Zugriffskreis, eigene Löschfristen. Der Abwesenheits-Agent sieht nur: BEM-Pflicht ausgelöst Ja/Nein. Keine Diagnosen, keine AU-Gründe.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">AI Agent, Regelwerk oder Mensch</h3>
<p class="text-small text-gosign-text-light mt-2">Der AI Agent klassifiziert Sachverhalte und erkennt Muster - zuverlässiger als jeder Sachbearbeiter. Das Regelwerk berechnet Ansprüche und Fristen. Der Mensch bleibt dort im Prozess, wo Betriebsrat (BetrVG § 87 Abs. 1 Nr. 5), Arbeitsrecht oder Gesundheitsdatenschutz eine menschliche Entscheidung verlangen.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">Hinweispflicht automatisiert</h3>
<p class="text-small text-gosign-text-light mt-2">BAG-Rechtsprechung verlangt individuelle, rechtzeitige Warnung bei drohendem Urlaubsverfall. Ohne Nachweis der Hinweispflicht verfällt der Urlaub nie. Der Decision Layer generiert die Hinweise automatisch, dokumentiert die Zustellung und eskaliert bei fehlendem Nachweis.</p>
</div>
</div>
</div>
</div>
</section>

<!-- Governance & Audit -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<h2 class="text-h1 font-bold text-gosign-dark">Nicht nachträglich dokumentiert. Im Prozess entstanden.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Wenn der Betriebsrat fragt "Warum wurde der Urlaubsantrag abgelehnt?" reicht "Minimalbesetzung" nicht. Welche Besetzungsregel? Welcher Zeitraum? Wer war bereits genehmigt? Der Leave Decision Layer erzeugt für jede Mikroentscheidung einen Entscheidungsakt, der genau diese Fragen beantwortet: Input, angewandte Fachregel samt Version, Ergebnis, Zeitstempel und Anfechtungspfad. Derselbe Akt macht auch die Erläuterung der Einzelentscheidung nach Art. 86 EU AI Act erfüllbar - für Betroffenen, Betriebsrat und Prüfer.</p>

<!-- Audit Trail Card -->
<div class="mt-10 bg-gosign-dark rounded-card p-6 sm:p-8">
<div class="flex items-start gap-4 mb-6">
<svg class="w-8 h-8 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12h6m-6 4h6m2 5H7a2 2 0 01-2-2V5a2 2 0 012-2h5.586a1 1 0 01.707.293l5.414 5.414a1 1 0 01.293.707V19a2 2 0 01-2 2z" />
</svg>
<div>
<h3 class="text-h3 font-bold text-white">Jede Mikro-Entscheidung erzeugt einen Audit-Eintrag</h3>
<p class="text-small text-gosign-text-on-dark/70 mt-1">Append-only. Nichts wird überschrieben, nichts gelöscht. Bei Korrekturen entstehen Storno- und Adjustment-Einträge. SHA-256 signiert, jederzeit exportierbar.</p>
</div>
</div>
<div class="grid grid-cols-2 sm:grid-cols-3 gap-3 sm:gap-4">
<div class="flex items-center gap-2.5">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span class="text-small text-gosign-text-on-dark/80">Regel-ID + Version</span>
</div>
<div class="flex items-center gap-2.5">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span class="text-small text-gosign-text-on-dark/80">Rechtsgrundlage (BUrlG, EFZG, TV, BV)</span>
</div>
<div class="flex items-center gap-2.5">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span class="text-small text-gosign-text-on-dark/80">Input-Daten (Antrag, Zeitraum, Team)</span>
</div>
<div class="flex items-center gap-2.5">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span class="text-small text-gosign-text-on-dark/80">Ergebnis (Genehmigung, Ablehnung, Eskalation)</span>
</div>
<div class="flex items-center gap-2.5">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span class="text-small text-gosign-text-on-dark/80">Entscheider (Regelwerk / Agent / Mensch)</span>
</div>
<div class="flex items-center gap-2.5">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span class="text-small text-gosign-text-on-dark/80">Input-Hash (reproduzierbar)</span>
</div>
</div>
</div>

<!-- Three Governance Pillars -->
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8">
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-3">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M15 12a3 3 0 11-6 0 3 3 0 016 0z" />
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M2.458 12C3.732 7.943 7.523 5 12 5c4.478 0 8.268 2.943 9.542 7-1.274 4.057-5.064 7-9.542 7-4.477 0-8.268-2.943-9.542-7z" />
</svg>
<div>
<h3 class="text-body font-semibold text-gosign-dark">Betriebsrats-transparent</h3>
<p class="text-small text-gosign-text-light mt-2">BetrVG § 87 Abs. 1 Nr. 5: Absolute Mitbestimmung bei Urlaubsgrundsätzen. Regelwerk einsehbar, Ablehnungsgründe dokumentiert, Anomalie-Erkennung per Feature Flag steuerbar, Auswertungen pseudonymisiert.</p>
<a href="/de/governance/mitbestimmung/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Mitbestimmung &rarr;</a>
</div>
</div>
</div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-3">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12l2 2 4-4m5.618-4.016A11.955 11.955 0 0112 2.944a11.955 11.955 0 01-8.618 3.04A12.02 12.02 0 003 9c0 5.591 3.824 10.29 9 11.622 5.176-1.332 9-6.03 9-11.622 0-1.042-.133-2.052-.382-3.016z" />
</svg>
<div>
<h3 class="text-body font-semibold text-gosign-dark">DSGVO Art. 9: Gesundheitsdaten separiert</h3>
<p class="text-small text-gosign-text-light mt-2">BEM-Modul architektonisch getrennt. Eigene Datenbank, eigener Zugriffskreis. Keine Diagnosen im Abwesenheitsmodul. BEM-Akte getrennt von Personalakte. Löschfristen konfigurierbar.</p>
<a href="/de/governance/data-residency/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Datenresidenz &rarr;</a>
</div>
</div>
</div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-3">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 5H7a2 2 0 00-2 2v12a2 2 0 002 2h10a2 2 0 002-2V7a2 2 0 00-2-2h-2M9 5a2 2 0 002 2h2a2 2 0 002-2M9 5a2 2 0 012-2h2a2 2 0 012 2m-6 9l2 2 4-4" />
</svg>
<div>
<h3 class="text-body font-semibold text-gosign-dark">BAG-Hinweispflicht automatisiert</h3>
<p class="text-small text-gosign-text-light mt-2">BAG 9 AZR 266/20: Urlaubsanspruch verfällt nicht ohne individuelle Warnung. Der Decision Layer generiert Hinweise automatisch, dokumentiert die Zustellung und eskaliert bei fehlendem Nachweis.</p>
</div>
</div>
</div>
</div>
</div>
</section>

<!-- Dockt an -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Integration</p>
<h2 class="text-h1 font-bold text-gosign-dark">Dockt an Ihre bestehende Systemlandschaft an</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Ihre Systeme bleiben. Die manuelle Entscheidungsarbeit davor verschwindet. Der Leave Decision Layer sitzt zwischen Ihren Vorsystemen und Ihrem HRIS - er trifft die Entscheidungen, die heute Sachbearbeiter treffen.</p>

<div class="grid grid-cols-1 md:grid-cols-3 gap-6 mt-10">
<!-- Datenquellen -->
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<div class="flex items-center gap-3 mb-4">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M20 7l-8-4-8 4m16 0l-8 4m8-4v10l-8 4m0-10L4 7m8 4v10M4 7v10l8 4" />
</svg>
<h3 class="text-body font-semibold text-gosign-dark">Datenquellen</h3>
</div>
<ul class="space-y-2 text-small text-gosign-text-light">
<li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Personalstamm (SAP HCM, Workday, Personio)</span></li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Zeitwirtschaft (ATOSS, Interflex, GFOS)</span></li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>eAU (Krankenkasse, seit 2023)</span></li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Schichtplanung (ATOSS, SAP)</span></li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Tarifvertrags- und BV-Datenbank</span></li>
</ul>
</div>

<!-- Decision Layer -->
<div class="bg-gosign-dark border border-gosign-dark rounded-card p-6">
<div class="flex items-center gap-3 mb-4">
<svg class="w-6 h-6 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9.75 3.104v5.714a2.25 2.25 0 01-.659 1.591L5 14.5M9.75 3.104c-.251.023-.501.05-.75.082m.75-.082a24.301 24.301 0 014.5 0m0 0v5.714c0 .597.237 1.17.659 1.591L19.8 15.3M14.25 3.104c.251.023.501.05.75.082M19.8 15.3l-1.57.393A9.065 9.065 0 0112 15a9.065 9.065 0 00-6.23.693L5 14.5m14.8.8l1.402 1.402c1.232 1.232.65 3.318-1.067 3.611A48.309 48.309 0 0112 21c-2.773 0-5.491-.235-8.135-.687-1.718-.293-2.3-2.379-1.067-3.61L5 14.5" />
</svg>
<h3 class="text-body font-semibold text-white">Leave Decision Layer</h3>
</div>
<ul class="space-y-2 text-small text-gosign-text-on-dark/80">
<li>Leave-Typ-Klassifikation</li>
<li>Anspruchsberechnung (TV + BV + Gesetz)</li>
<li>Teamkonflikt- und Besetzungsprüfung</li>
<li>Lohnfortzahlungsfrist-Berechnung</li>
<li>BEM-Schwellen-Monitoring</li>
<li>Urlaubsverfall-Hinweispflicht</li>
<li>eAU-Verarbeitung + Rückschreibung</li>
</ul>
</div>

<!-- Zielsysteme -->
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<div class="flex items-center gap-3 mb-4">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M5.25 14.25h13.5m-13.5 0a3 3 0 01-3-3m3 3a3 3 0 100 6h13.5a3 3 0 100-6m-16.5-3a3 3 0 013-3h13.5a3 3 0 013 3m-19.5 0a4.5 4.5 0 01.9-2.7L5.737 5.1a3.375 3.375 0 012.7-1.35h7.126c1.062 0 2.062.5 2.7 1.35l2.587 3.45a4.5 4.5 0 01.9 2.7m0 0a3 3 0 01-3 3m0 3h.008v.008h-.008v-.008zm0-6h.008v.008h-.008v-.008zm-3 6h.008v.008h-.008v-.008zm0-6h.008v.008h-.008v-.008z" />
</svg>
<h3 class="text-body font-semibold text-gosign-dark">Zielsysteme</h3>
</div>
<ul class="space-y-2 text-small text-gosign-text-light">
<li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>SAP SuccessFactors Time Off</span></li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Workday Absence Management</span></li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Payroll (DATEV, SAP HCM)</span></li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Kalender (Microsoft 365, Google)</span></li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>DMS / Digitale Personalakte</span></li>
</ul>
</div>
</div>
</div>
</section>

<!-- Branchen-Simulationen -->
<section id="simulationen" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simuliert für Enterprise-Volumina</p>
<h2 class="text-h1 font-bold text-white">Vier Branchen. Durchgerechnet.</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Wir haben den Leave & Absence Decision Layer für vier Branchen konfiguriert und mit realistischen Tarifverträgen, Abwesenheitsregeln und Personalstrukturen durchgerechnet. Jede Karte zeigt die Simulationsparameter und das Ergebnis.</p>

<div class="grid grid-cols-1 md:grid-cols-2 gap-6 mt-10">
<!-- Chemie -->
<a href="/de/leistungen/hr-agent/leave-absence-decision-layer/chemie/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors">
<div class="flex items-center justify-between mb-4">
<h3 class="text-h3 font-bold text-white">Chemie</h3>
<div class="flex gap-1">
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>

</div>
</div>
<ul class="space-y-1.5 text-small text-gosign-text-on-dark/70">
<li>Zukunftsbetrag-Freizeit-Option (23% Monatsgehalt)</li>
<li>Schichtzusatzurlaub 2-5 Tage (Vollkonti/Teilkonti)</li>
<li>Gefahrstoff-BEM (Berufskrankheiten)</li>
<li>13 Tarifbezirke, standortspezifische BVs</li>
</ul>
<div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between">
<span class="text-h3 font-bold text-gosign-accent-on-dark">83% vollautomatisch</span>
<span class="text-small text-gosign-accent-on-dark font-semibold">Chemie im Detail &rarr;</span>
</div>
</a>

<!-- Aviation -->
<a href="/de/leistungen/hr-agent/leave-absence-decision-layer/aviation/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors">
<div class="flex items-center justify-between mb-4">
<h3 class="text-h3 font-bold text-white">Aviation</h3>
<div class="flex gap-1">
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>

</div>
</div>
<ul class="space-y-1.5 text-small text-gosign-text-on-dark/70">
<li>3 Gewerkschaften (Cockpit, Kabine, Boden)</li>
<li>EASA FTL: Pflichtruhezeiten, Duty-Period-Limits</li>
<li>Medical Grounding (Fluguntauglichkeit)</li>
<li>Rotationsplanung über Stationierungsorte</li>
</ul>
<div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between">
<span class="text-h3 font-bold text-gosign-accent-on-dark">78% vollautomatisch</span>
<span class="text-small text-gosign-accent-on-dark font-semibold">Aviation im Detail &rarr;</span>
</div>
</a>

<!-- Finanzwesen -->
<a href="/de/leistungen/hr-agent/leave-absence-decision-layer/finanzwesen/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors">
<div class="flex items-center justify-between mb-4">
<h3 class="text-h3 font-bold text-white">Finanzwesen</h3>
<div class="flex gap-1">
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>

<span class="w-3 h-1.5 rounded-sm bg-white/20"></span>
</div>
</div>
<ul class="space-y-1.5 text-small text-gosign-text-on-dark/70">
<li>Pflichtfreistellung (Vier-Augen-Prinzip, Fraud)</li>
<li>MaRisk BTO 2.2: Pflicht-Urlaubsblöcke für Trader</li>
<li>Börsenfeiertage zusätzlich zu gesetzlichen</li>
<li>Altersteilzeit-Blockmodelle</li>
</ul>
<div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between">
<span class="text-h3 font-bold text-gosign-accent-on-dark">85% vollautomatisch</span>
<span class="text-small text-gosign-accent-on-dark font-semibold">Finanzwesen im Detail &rarr;</span>
</div>
</a>

<!-- Handel -->
<a href="/de/leistungen/hr-agent/leave-absence-decision-layer/handel/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors">
<div class="flex items-center justify-between mb-4">
<h3 class="text-h3 font-bold text-white">Handel</h3>
<div class="flex gap-1">
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>

<span class="w-3 h-1.5 rounded-sm bg-white/20"></span>
</div>
</div>
<ul class="space-y-1.5 text-small text-gosign-text-on-dark/70">
<li>6-Tage-Woche: 24 Werktage Mindestanspruch</li>
<li>64% Teilzeitquote, Minijobber mit vollem Anspruch</li>
<li>Urlaubssperren Weihnachten, Ostern, Saison-Peaks</li>
<li>16 Bundesländer x unterschiedliche TVs</li>
</ul>
<div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between">
<span class="text-h3 font-bold text-gosign-accent-on-dark">87% vollautomatisch</span>
<span class="text-small text-gosign-accent-on-dark font-semibold">Handel im Detail &rarr;</span>
</div>
</a>
</div>
</div>
</section>

<!-- Architektur, Implementierung & Hebel -->
<section id="implementation" class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Implementierung</p>
<h2 class="text-h1 font-bold text-gosign-dark">Vom Piloten zum laufenden System.</h2>

<div class="grid grid-cols-1 lg:grid-cols-2 gap-10 mt-10">
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Technische Architektur</h3>
<p class="text-body text-gosign-text">Der Leave & Absence Decision Layer läuft vollständig in Ihrer Infrastruktur: Ihr Rechenzentrum, Ihr Netzwerk, Ihre Hoheit. Keine SaaS-Abhängigkeit, keine Datenabflüsse, kein externes Telemetrie-Tracking. Gesundheitsdaten und BEM-Akten verlassen Ihr Netzwerk nicht. Containerisiert, mandantenfähig, deployment-fertig für Ihre Private Cloud.</p>
<div class="flex flex-wrap gap-4 mt-3">
<a href="/de/leistungen/infrastruktur/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infrastruktur im Detail &rarr;</a>
<a href="/de/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Decision Layer Architektur &rarr;</a>
<a href="/de/magazin/entscheidungsakt-anfechtbare-ki-entscheidungen/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Der Entscheidungsakt &rarr;</a>
<a href="/de/leistungen/hr-agent/payroll-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Payroll Decision Layer &rarr;</a>
</div>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Implementierung</h3>
<p class="text-body text-gosign-text">Der Decision Layer wird nicht installiert, sondern konfiguriert: Ihre Tarifverträge, Ihre Betriebsvereinbarungen, Ihre Abwesenheitstypen. Typische Pilotprojekte starten innerhalb von 3 Monaten mit einem Standort und den häufigsten Leave-Typen. Erweiterungen auf weitere Standorte, Tarifverträge und Sonderfälle laufen parallel zum Pilotbetrieb.</p>
</div>
</div>

<h3 class="text-h3 font-bold text-gosign-dark mt-12 mb-6">Ökonomischer Hebel</h3>
<div class="grid grid-cols-1 sm:grid-cols-2 gap-6">
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-4">
<svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12l2 2 4-4m5.618-4.016A11.955 11.955 0 0112 2.944a11.955 11.955 0 01-8.618 3.04A12.02 12.02 0 003 9c0 5.591 3.824 10.29 9 11.622 5.176-1.332 9-6.03 9-11.622 0-1.042-.133-2.052-.382-3.016z" />
</svg>
<div>
<p class="text-body font-semibold text-gosign-dark">BEM-Fristversäumnisse eliminieren</p>
<p class="text-small text-gosign-text-light mt-2">Ohne ordnungsgemäßes BEM ist eine krankheitsbedingte Kündigung nahezu immer unwirksam. Der Decision Layer erkennt die 42-Tage-Schwelle automatisch, triggert den Prozess und dokumentiert die Einladung. Keine vergessenen BEM-Pflichten.</p>
</div>
</div>
</div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-4">
<svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M13 10V3L4 14h7v7l9-11h-7z" />
</svg>
<div>
<p class="text-body font-semibold text-gosign-dark">eAU-Verarbeitung in Echtzeit</p>
<p class="text-small text-gosign-text-light mt-2">Seit 2023 liefern Krankenkassen elektronische AU-Bescheinigungen. Der Decision Layer verarbeitet eAU automatisch: Abwesenheit buchen, Lohnfortzahlungsfrist berechnen, Payroll informieren, Schichtplanung aktualisieren. Kein manuelles Nachtragen.</p>
</div>
</div>
</div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-4">
<svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M12 6v6h4.5m4.5 0a9 9 0 11-18 0 9 9 0 0118 0z" />
</svg>
<div>
<p class="text-body font-semibold text-gosign-dark">78-87% vollautomatisch. Mensch nur wo rechtlich nötig.</p>
<p class="text-small text-gosign-text-light mt-2">Standard-Urlaubsanträge, Resturlaubsberechnung, Sonderurlaub, eAU-Verarbeitung, Kindkrank-Kontingente: alles automatisierbar. Menschliche Eingriffe bleiben bei Urlaubskonflikten, BEM-Gesprächen und Bildungsurlaubs-Inhaltsprüfung.</p>
</div>
</div>
</div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-4">
<svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12h6m-6 4h6m2 5H7a2 2 0 01-2-2V5a2 2 0 012-2h5.586a1 1 0 01.707.293l5.414 5.414a1 1 0 01.293.707V19a2 2 0 01-2 2z" />
</svg>
<div>
<p class="text-body font-semibold text-gosign-dark">Urlaubsverfall-Risiko eliminieren</p>
<p class="text-small text-gosign-text-light mt-2">BAG-Hinweispflicht: Ohne individuellen, rechtzeitigen Nachweis verfällt der Urlaub nie. Verjährung beginnt erst mit Erfüllung der Hinweispflicht. Der Decision Layer automatisiert die Hinweise und dokumentiert die Zustellung.</p>
</div>
</div>
</div>
</div>
</div>
</section>

<!-- Compliance & Security -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Sicherheit</p>
<h2 class="text-h1 font-bold text-gosign-dark">Enterprise-Security. Von Tag eins.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Abwesenheitsdaten enthalten Gesundheitsinformationen, BEM-Akten und sensible Personalentscheidungen. Der Leave Decision Layer ist für regulierte Umgebungen konzipiert, in denen Datenschutz, Audit-Readiness und Nachvollziehbarkeit keine optionalen Extras sind.</p>
<div class="mt-10">
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">100% Kunden-Infrastruktur</h3>
<p class="text-small text-gosign-text-light mt-2">Der Decision Layer läuft vollständig in Ihrem Netzwerk. Keine SaaS-Abhängigkeit, kein Datenabfluss, kein externes Telemetrie-Tracking. Gesundheitsdaten und BEM-Akten verlassen Ihr Netzwerk nicht.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">DSGVO Art. 9 by Design</h3>
<p class="text-small text-gosign-text-light mt-2">Gesundheitsdaten architektonisch separiert. BEM-Modul mit eigener Datenbank, eigenem Zugriffskreis, eigenen Löschfristen. Kompatibel mit DSGVO Art. 17 und Aufbewahrungsfristen.</p>
<a href="/de/governance/data-residency/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Datenresidenz im Detail &rarr;</a>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">AI Act-konform</h3>
<p class="text-small text-gosign-text-light mt-2">Klare Architektur-Trennung: Der AI Agent klassifiziert Leave-Typen und erkennt Konflikte. Die Berechnung von Ansprüchen und Fristen läuft deterministisch durch Regelwerke. Keine Black Box bei Entscheidungen.</p>
<a href="/de/governance/eu-ai-act/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">EU AI Act Readiness &rarr;</a>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">Audit Trail (append-only)</h3>
<p class="text-small text-gosign-text-light mt-2">Signierte Entscheidungsakten. Input-Hash plus Regelversion ergibt reproduzierbares Ergebnis. Versiegelte Audit-Pakete (JSON + PDF, SHA-256). Betriebsrat kann jede Entscheidung nachvollziehen.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">ISO 27001 / PS 951 cert-ready</h3>
<p class="text-small text-gosign-text-light mt-2">Integrierte Controls Registry, automatisierte Evidence Runs, versionierte Policies. Compliance im laufenden Betrieb, nicht nachträglich dokumentiert.</p>
<a href="/de/governance/cert-ready/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready by Design &rarr;</a>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">SSO & Mandantentrennung</h3>
<p class="text-small text-gosign-text-light mt-2">Integration in bestehende Identity Provider. Mandantentrennung auf Datenbankebene (Row Level Security). BEM-Zugriffskreis getrennt vom Abwesenheitsmodul. Gesellschaften sauber getrennt.</p>
</div>
</div>
</div>
</div>
</section>


<!-- Weitere Agent-Lösungen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Weitere Agent-Lösungen</h2>
<p class="text-body-lg text-gosign-text-light mt-4">HR Agents sind Teil unseres Agent-Portfolios. Für Finance und andere Bereiche bieten wir spezialisierte Lösungen.</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8 max-w-content">
<a href="/de/hr-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR & People Operations</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Alle HR Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Betriebsratsfähig.</p>
</a>
<a href="/de/finance-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Finance & Accounting</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Finance AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Belegverarbeitung, Kontierung, AfA-Logik, Korrekturbuchungen. DATEV- und SAP-Integration.</p>
</a>
<a href="/de/kontakt/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Individuell</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Co-Build für Ihren Prozess</h3>
<p class="text-body text-gosign-text-light mt-2">Compliance, Operations, Shared Services - wir entwickeln Agenten im Co-Build.</p>
</a>
</div>
</div>
</section>

<!-- Dieser Agent im Katalog -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark">Wann starten? Priorisierung und Governance-Readiness</h2>
<p class="text-body text-gosign-text mt-4">In welchem Quartal sollte dieser Agent starten? Welche Governance-Infrastruktur muss vorher stehen? Welche Agenten sind Voraussetzung? Der HR-Agent-Katalog ordnet diesen Agenten in die Q1-Q4 Sequenzierung ein und zeigt Readiness-Scores, Governance-Komplexität und Abhängigkeiten zu anderen Agenten.</p>
<a href="/de/hr-agent-katalog/leave-of-absence-agent/" class="inline-flex items-center gap-2 mt-4 text-body font-semibold text-gosign-accent hover:underline">Sequenzierung und Scores ansehen &rarr;</a>
</div>
</section>

<!-- Vertiefung -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Vertiefung im Agent Briefing (Gosign Magazin)</h2>
<p class="text-body text-gosign-text-light mb-6">Unsere Fachartikel-Serie für Entscheider, die AI Agents im Unternehmen einführen.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/de/magazin/betriebsrat-ki-mitbestimmung/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Mitbestimmung</p>
<p class="text-body font-semibold text-gosign-dark">Betriebsrat und KI - Mitbestimmung als Architektur-Constraint</p>
</a>
<a href="/de/magazin/decision-layer-erklaert/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Grundlagen</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - Was ist das und warum braucht jeder Enterprise AI Agent einen?</p>
</a>
<a href="/de/magazin/eu-ai-act-hr/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">EU AI Act und HR - Was Personalverantwortliche jetzt wissen müssen</p>
</a>
</div>
</div>
</section>

--- AI Payroll Agent Aviation - Entgeltabrechnung ---
> Payroll Decision Layer für die Luftfahrt. 3 Gewerkschaften, 14-18 Tarifverträge, EASA FTL, Per Diems. 82% vollautomatisch.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/de/warum-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Jede Entscheidung nachvollziehbar</p>
</div>
</a>
<a href="/de/warum-gosign/#infrastruktur" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Ihre Infrastruktur</p>
<p class="text-xs text-gosign-text-light">Kein SaaS. Kein Vendor-Lock-in.</p>
</div>
</a>
<a href="/de/warum-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Kein US-Cloud-Risiko</p>
</div>
</a>
</div>
</div>
</div>

<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Payroll Decision Layer Branchen">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/de/leistungen/hr-agent/payroll-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Payroll Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/de/leistungen/hr-agent/payroll-decision-layer/chemie/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Chemie</a>
<a href="/de/leistungen/hr-agent/payroll-decision-layer/aviation/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Aviation</a>
<a href="/de/leistungen/hr-agent/payroll-decision-layer/finanzwesen/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Finanzwesen</a>
<a href="/de/leistungen/hr-agent/payroll-decision-layer/handel/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Handel</a>
</div>
</div>
</nav>

<!-- Komplexität -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">14-18</span>
<p class="text-small text-gosign-text-light mt-1">Parallele Tarifverträge</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">82%</span>
<p class="text-small text-gosign-text-light mt-1">Automatisierungsquote</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">180+</span>
<p class="text-small text-gosign-text-light mt-1">Länder-Per-Diem-Sätze</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">Höchste Regelkomplexität</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">VC, UFO, ver.di Tarifverträge 2024. BMF Reisekostensätze. EASA FTL (VO EU 83/2014). vollautomatisch: Gosign-Simulationsmodell.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Was der Agent klassifiziert</p>
<h2 class="text-h1 font-bold text-gosign-dark">Drei Gewerkschaften, ein Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">VC, UFO, ver.di - drei Tarifwelten, EASA-Limits, internationale Per Diems. Sie kennen die Komplexität. So löst der AI Agent sie:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Cockpit (VC): Seniorität bis Stufe 23</h3>
<p class="text-body text-gosign-text mt-2">23 Senioritätsstufen, Übergangsversorgung, Direktversicherung, Flugstunden-Vergütung. Der AI Agent erkennt Senioritätsstufe und Flottenzugehörigkeit aus dem Personalstamm und ordnet die korrekte Vergütungsklasse zu - vom First Officer bis Captain Senior.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Kabine (UFO): Schichtzulage 16,3%</h3>
<p class="text-body text-gosign-text mt-2">Grundvergütung plus 16,3% Schichtzulage, Purser-Zulagen, Per Diems nach Umlaufplan. Der AI Agent erkennt Kurz- vs. Langstrecke und berechnet die korrekten Per Diems und Schichtmuster pro Umlauf. Bei Streckenänderung: automatische Neuberechnung.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Boden (ver.di): TVöD-F und BVD</h3>
<p class="text-body text-gosign-text mt-2">TVöD-F mit 16 Entgeltgruppen, BVD mit 10 Entgeltgruppen, Nacht-/Feiertags-/Schichtzulagen. Der AI Agent klassifiziert Entgeltgruppe und Erfahrungsstufe aus Personalstamm und Stellenprofil - auch bei Wechsel zwischen Check-in, Vorfeld und Gepäckabfertigung.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">EASA FTL: Flugzeitlimits als Payroll-Grenze</h3>
<p class="text-body text-gosign-text mt-2">Maximal 900 Flugstunden/Jahr, Flight Duty Period maximal 13 Stunden. Der AI Agent prüft jeden Abrechnungszyklus gegen diese Limits und eskaliert bei Annäherung. Bei Überschreitung drohen Lizenzentzug und Bußgeld - das ist keine Payroll-Frage mehr, sondern eine rechtliche.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Per Diems: 180+ Ländersätze nach BMF</h3>
<p class="text-body text-gosign-text mt-2">Umlauf London-Dubai-Singapur: drei Ländersätze in einer Duty Period. Der AI Agent berechnet Verpflegungsmehraufwand pro Umlaufabschnitt nach BMF-Pauschalen, inklusive Mahlzeitenabzüge und Mindestaufenthaltszeiten. Bei IROP-bedingten Umlaufänderungen: automatische Neuberechnung. Dieselbe Logik steuert auch die <a href="/de/leistungen/travel-decision-layer/aviation/" class="text-gosign-accent-text font-semibold hover:text-gosign-accent-hover transition-colors">Reisekostenabrechnung im Travel Decision Layer</a>.</p>
</div>
</div>
</div>
</section>

<!-- Decision Flow -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Eine Aviation-Abrechnung. 50 bis 120 Mikro-Entscheidungen.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Ein Captain auf Langstrecke. Der Payroll Decision Layer zerlegt seine Abrechnung in einzelne Entscheidungsschritte:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Schritt</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Entscheidung</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Entscheider</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Begründung</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Personalgruppe klassifizieren</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent erkennt: Cockpit, Kabine, Boden oder Technik aus Personalstamm und Stellenschlüssel</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Tarifvertrag zuordnen</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent ordnet zu: VC, UFO oder ver.di. Zusätzlich: welche Fluggesellschaft (Konzerngesellschaften haben eigene Tarifwerke)</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Grundvergütung berechnen</td><td class="py-3 px-4">Tarifvertrag</td><td class="py-3 px-4">Lookup in versionierter Tariftabelle: Senioritätsstufe, Flotte, Erfahrungsstufe</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Schichtzulagen berechnen</td><td class="py-3 px-4">Tarifvertrag</td><td class="py-3 px-4">Kabine: 16,3% Schichtzulage. Boden: Zuschläge nach TVöD-F/BVD-Schichtmodell. Cockpit: in Grundvergütung integriert</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">FTL-Compliance prüfen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">EASA-Prüfung: 900h-Jahres-Cap, FDP max. 13h, kumulierte Limits. Bei Annäherung: Eskalation</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Per Diem klassifizieren</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent klassifiziert Umlauf: Welche Länder, welche Aufenthaltsdauer, welche BMF-Sätze gelten</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Per Diem berechnen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">BMF-Ländersätze, Mahlzeitenabzug, Mindestaufenthalt. Bei IROP-Änderungen: automatische Neuberechnung</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">Übergangsversorgung/Pension berechnen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">Pilotspezifisch: Übergangsversorgung, Direktversicherung, Versorgungswerk. Deterministisch nach Tarifvertrag</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Abweichungsprüfung</td><td class="py-3 px-4">KI erkennt, Mensch entscheidet</td><td class="py-3 px-4">KI erkennt Abweichungen zuverlässiger. Aber die Bewertung bleibt beim Menschen - BetrVG Paragraph 87 schützt die Mitbestimmung bei Entlohnungsgrundsätzen</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Buchungssätze erzeugen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">FI/CO-Kontierung, Multi-Gesellschaft (Konzerngesellschaften), Kostenstelle - deterministisch</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Simulation -->
<section id="simulation" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulation</p>
<h2 class="text-h1 font-bold text-white">Durchgerechnet für Aviation-Volumina</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Wir haben den Payroll Decision Layer mit realistischen Aviation-Parametern konfiguriert und durchgerechnet. VC-, UFO- und ver.di-Tarifverträge, EASA FTL, internationale Per Diems, Cockpit-Seniorität bis Stufe 23.</p>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Simulationsparameter</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Crew-Stärke</td><td class="py-3 px-4">10.000 bis 50.000+ (Cockpit, Kabine, Boden, Technik)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Parallele Tarifverträge</td><td class="py-3 px-4">2 bis 5 (VC, UFO, ver.di, ggf. Tochtergesellschaften)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Jurisdiktionen</td><td class="py-3 px-4">Multi-Jurisdiktion (Heimatbasis DE, Stationen EU/weltweit)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">IROP-Quote</td><td class="py-3 px-4">10-20% (Unregelmäßigkeiten mit Payroll-Auswirkung)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Per-Diem-Länder</td><td class="py-3 px-4">180+ Ländersätze nach BMF-Pauschalen</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Cockpit-Senioritätsstufen</td><td class="py-3 px-4">Bis Stufe 23 (Captain Senior), Übergangsversorgung</td></tr>
</tbody>
</table>
</div>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Vorher / Nachher</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th scope="col" class="text-left py-3 px-4 font-semibold text-white">Dimension</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manuell</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Fehlerquote</td><td class="py-3 px-4">3-12% (APA, Aviation-Zuschlag)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 0,3%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Automatisierungsquote</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">82%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Per-Diem-Berechnung</td><td class="py-3 px-4">Manuell pro Umlauf, fehleranfällig</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatisch, 180+ Länder</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">FTL-Compliance</td><td class="py-3 px-4">Separate Prüfung, nachgelagert</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Integriert, Echtzeit-Limits</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Tarifwechsel (3 Gewerkschaften)</td><td class="py-3 px-4">Wochen pro Gewerkschaft</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 24h (alle parallel)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Audit-Readiness</td><td class="py-3 px-4">Manuell rekonstruiert</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatisch erzeugt</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">APA: American Payroll Association. VC, UFO, ver.di Tarifverträge 2024. EASA VO EU 83/2014. BMF Reisekostensätze 2024. Simulationsergebnisse: Gosign-Modellrechnung.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">In der Simulation erreicht der Decision Layer eine Automatisierungsquote von 82%. Die verbleibenden 18% sind echte Ausnahmen: IROP-bedingte Umlaufänderungen, Gewerkschaftswechsel bei Konzernversetzungen, FTL-Grenzfälle mit Eskalation, Cockpit-Beförderungen über Tarifgrenzen hinweg. Für die 82% liegt eine vollständige, prüfungssichere Entscheidungsakte vor.</p>
</div>
</section>

<!-- Architektur-Referenz -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Architektur und Implementierung</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">Der Payroll Decision Layer läuft vollständig in Ihrer Infrastruktur. Für die Luftfahrt bedeutet das: Anbindung an Crew-Management-Systeme, Verarbeitung von Umlaufplänen und FTL-Daten, drei parallele Tarifwerke und durchgängiger Audit Trail bis SAP HCM. Typische Pilotprojekte starten innerhalb von 3 Monaten mit einer Personalgruppe und einem Tarifvertrag.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/de/leistungen/hr-agent/payroll-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Payroll Decision Layer Übersicht &rarr;</a>
<a href="/de/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Decision Layer Architektur &rarr;</a>
<a href="/de/leistungen/infrastruktur/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infrastruktur im Detail &rarr;</a>
<a href="/de/governance/mitbestimmung/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Mitbestimmung &amp; Betriebsrat &rarr;</a>
<a href="/de/governance/cert-ready/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready by Design &rarr;</a>
<a href="/de/leistungen/travel-decision-layer/aviation/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Travel Decision Layer Aviation &rarr;</a>
</div>
</div>
</section>


<!-- Weitere Agent-Lösungen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Weitere Agent-Lösungen</h2>
<p class="text-body-lg text-gosign-text-light mt-4">HR Agents sind Teil unseres Agent-Portfolios. Für Finance und andere Bereiche bieten wir spezialisierte Lösungen.</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8 max-w-content">
<a href="/de/hr-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR & People Operations</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Alle HR Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Betriebsratsfähig.</p>
</a>
<a href="/de/finance-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Finance & Accounting</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Finance AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Belegverarbeitung, Kontierung, AfA-Logik, Korrekturbuchungen. DATEV- und SAP-Integration.</p>
</a>
<a href="/de/kontakt/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Individuell</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Co-Build für Ihren Prozess</h3>
<p class="text-body text-gosign-text-light mt-2">Compliance, Operations, Shared Services - wir entwickeln Agenten im Co-Build.</p>
</a>
</div>
</div>
</section>

<!-- Vertiefung -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Vertiefung im Agent Briefing (Gosign Magazin)</h2>
<p class="text-body text-gosign-text-light mb-6">Unsere Fachartikel-Serie für Entscheider, die AI Agents im Unternehmen einführen.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/de/magazin/decision-layer-payroll/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Finance</p>
<p class="text-body font-semibold text-gosign-dark">Payroll-Fehler strukturell eliminieren - Decision Layer für Finance</p>
</a>
<a href="/de/magazin/betriebsrat-ki-mitbestimmung/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Mitbestimmung</p>
<p class="text-body font-semibold text-gosign-dark">Betriebsrat und KI - Mitbestimmung als Architektur-Constraint</p>
</a>
<a href="/de/magazin/decision-layer-erklaert/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Grundlagen</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - Was ist das und warum braucht jeder Enterprise AI Agent einen?</p>
</a>
</div>
</div>
</section>

<!-- Andere Branchen -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Payroll Decision Layer in anderen Branchen</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Jede Branche hat eigene Tarifverträge, eigene Zuschlagsregeln und eigene Komplexitätstreiber. Der Decision Layer ist derselbe. Die Konfiguration ist branchenspezifisch.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/de/leistungen/hr-agent/payroll-decision-layer/chemie/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Chemie</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">169 Grundvergütungssätze, 13 Tarifbezirke, Schichtzuschläge mit Kumulierung, Zukunftsbetrag</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">88% vollautomatisch</span>
<span class="text-small text-gosign-accent-text font-semibold">Im Detail &rarr;</span>
</div>
</a>
<a href="/de/leistungen/hr-agent/payroll-decision-layer/finanzwesen/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Finanzwesen</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">5 Vergütungsregime, InstitutsVergV Bonus-Deferral, Malus/Clawback, MaRisk-Pflichten</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">85% vollautomatisch</span>
<span class="text-small text-gosign-accent-text font-semibold">Im Detail &rarr;</span>
</div>
</a>
<a href="/de/leistungen/hr-agent/payroll-decision-layer/handel/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Handel</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">576 Grundsätze (16 Länder x 6 Gruppen x 6 Stufen), 64% Teilzeit, Saison-Peaks</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">92% vollautomatisch</span>
<span class="text-small text-gosign-accent-text font-semibold">Im Detail &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- AI Payroll Agent Chemie - Entgeltabrechnung ---
> Payroll Decision Layer für die Chemieindustrie. 169 Grundvergütungssätze, Schichtzuschläge, Zukunftsbetrag. 88% vollautomatisch.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/de/warum-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Jede Entscheidung nachvollziehbar</p>
</div>
</a>
<a href="/de/warum-gosign/#infrastruktur" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Ihre Infrastruktur</p>
<p class="text-xs text-gosign-text-light">Kein SaaS. Kein Vendor-Lock-in.</p>
</div>
</a>
<a href="/de/warum-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Kein US-Cloud-Risiko</p>
</div>
</a>
</div>
</div>
</div>

<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Payroll Decision Layer Branchen">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/de/leistungen/hr-agent/payroll-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Payroll Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/de/leistungen/hr-agent/payroll-decision-layer/chemie/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Chemie</a>
<a href="/de/leistungen/hr-agent/payroll-decision-layer/aviation/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Aviation</a>
<a href="/de/leistungen/hr-agent/payroll-decision-layer/finanzwesen/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Finanzwesen</a>
<a href="/de/leistungen/hr-agent/payroll-decision-layer/handel/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Handel</a>
</div>
</div>
</nav>

<!-- Komplexität -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">169</span>
<p class="text-small text-gosign-text-light mt-1">Grundvergütungssätze</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">88%</span>
<p class="text-small text-gosign-text-light mt-1">Automatisierungsquote</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">23%</span>
<p class="text-small text-gosign-text-light mt-1">Zukunftsbetrag (Wahlrecht)</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">Höchste Regelkomplexität</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">IG BCE Entgelttarifvertrag Chemie 2024-2026. vollautomatisch: Gosign-Simulationsmodell.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Was der Agent klassifiziert</p>
<h2 class="text-h1 font-bold text-gosign-dark">Fünf Dimensionen, ein Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">13 Entgeltgruppen, 13 Tarifbezirke, Schichtzuschläge mit Kumulierungsregeln, Zukunftsbetrag mit Dreifach-Wahlrecht. Sie kennen die Komplexität. So löst der AI Agent sie:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">169 Grundvergütungssätze</h3>
<p class="text-body text-gosign-text mt-2">13 Entgeltgruppen, 13 Tarifbezirke, 169 Kombinationen. Der AI Agent erkennt die korrekte Kombination aus Personalstamm und Standortdaten - auch bei Versetzungen zwischen Bezirken. Keine manuelle Tabellensuche, keine Bezirksverwechslung.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Schichtzuschläge mit Kumulierungslogik</h3>
<p class="text-body text-gosign-text mt-2">Teilkontischicht 6%, Vollkontischicht 10%, Nacht 15-20%, Sonntag 60%, Feiertag 150%. Der AI Agent wendet die Kumulierungsregel an: höchster Zuschlag greift, Nachtzuschlag immer additiv. Bei Wechselschichtmodellen berechnet das Regelwerk die korrekte Kombination pro Schichtplan automatisch.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Zukunftsbetrag mit Dreifach-Wahlrecht</h3>
<p class="text-body text-gosign-text mt-2">23% eines Monatsgehalts, drei Optionen: Auszahlung, Freizeit oder Altersvorsorge. Der AI Agent verwaltet 10.000 individuelle Konfigurationen mit der jeweils korrekten steuerlichen Behandlung. Bei jährlichem Wahlrechtwechsel: automatische Umstellung ab dem Folgemonat.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Gefahrstoffzulagen</h3>
<p class="text-body text-gosign-text mt-2">Erschwerniszulagen 5-15% für Hitze, Kälte, Chemikalien, Lärm, schwere körperliche Arbeit. Der AI Agent klassifiziert die Gefährdungsbeurteilung pro Arbeitsplatz und ordnet die korrekte Zulage zu. Bei Arbeitsplatzwechsel: automatische Neuberechnung.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Sonderzahlungen nach Kalender</h3>
<p class="text-body text-gosign-text mt-2">13. Monatsgehalt im Mai, Urlaubsgeld EUR 1.200 im Juni, CareFlex EUR 33,65 monatlich. Der AI Agent kennt Fälligkeit, steuerliche Behandlung und SV-Berechnung jeder Sonderzahlung. Bei unterjährigem Ein- oder Austritt: anteilige Berechnung automatisch.</p>
</div>
</div>
</div>
</section>

<!-- Decision Flow -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Eine Chemie-Abrechnung. 40 bis 80 Mikro-Entscheidungen.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Ein Schichtarbeiter in der Chemieindustrie. Der Payroll Decision Layer zerlegt seine Abrechnung in einzelne Entscheidungsschritte:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Schritt</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Entscheidung</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Entscheider</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Begründung</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Tarifbezirk und Entgeltgruppe klassifizieren</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent erkennt Standort, Bezirk und prüft Eingruppierung gegen Personalstamm</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Grundvergütung berechnen</td><td class="py-3 px-4">Tarifvertrag</td><td class="py-3 px-4">Lookup in versionierter IG-BCE-Tabelle: Bezirk + Gruppe + Stufe</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Schichtmodell klassifizieren</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent erkennt: Teilkontischicht (6%), Vollkontischicht (10%) oder Dauernachtschicht aus Schichtplan</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Zuschläge berechnen und kumulieren</td><td class="py-3 px-4">Tarifvertrag</td><td class="py-3 px-4">Höchster Zuschlag greift, Nacht immer additiv. Sonntag 60%, Feiertag 150%</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Steuerfreie Anteile berechnen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">§ 3b EStG: Nacht 25%, Sonntag 50%, Feiertag 125% des Grundlohns steuerfrei</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Gefahrstoffzulage klassifizieren</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent klassifiziert Arbeitsplatz anhand Gefährdungsbeurteilung: Hitze, Kälte, Chemikalien, Lärm</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Zukunftsbetrag berechnen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">23% Monatsgehalt, Steuerbehandlung je nach Wahlrecht (Geld/Freizeit/Vorsorge)</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">SV-Beiträge berechnen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">KV/RV/AV/PV mit BBG-Prüfung, CareFlex EUR 33,65 AG-finanziert</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Abweichungsprüfung gegen Vormonat</td><td class="py-3 px-4">KI erkennt, Mensch entscheidet</td><td class="py-3 px-4">KI erkennt Abweichungen zuverlässiger. Aber die Reaktion (Beförderung, Fehler, Versetzung?) bleibt beim Menschen - BetrVG § 87 Abs. 1 Nr. 6</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Buchungssätze erzeugen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">FI/CO-Kontierung, Kostenstelle, Buchungsperiode - deterministisch</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Simulation -->
<section id="simulation" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulation</p>
<h2 class="text-h1 font-bold text-white">Durchgerechnet für Chemie-Volumina</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Wir haben den Payroll Decision Layer mit realistischen Chemie-Parametern konfiguriert und durchgerechnet. IG-BCE-Tarifvertrag, 13 Bezirke, Schichtmodelle, Gefahrstoffzulagen, Zukunftsbetrag.</p>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Simulationsparameter</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Mitarbeiter</td><td class="py-3 px-4">5.000 bis 50.000+ (Produktion, Labor, Verwaltung)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Tarifvertrag</td><td class="py-3 px-4">IG BCE Chemie, 13 Bezirke, 13 Entgeltgruppen</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Grundvergütungssätze</td><td class="py-3 px-4">169 (13 Bezirke x 13 Gruppen) + Stufenautomatik</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Schichtmodelle</td><td class="py-3 px-4">Teilkontischicht, Vollkontischicht, Dauernachtschicht</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Sonderzahlungen</td><td class="py-3 px-4">13. Gehalt, Urlaubsgeld, Zukunftsbetrag 23%, CareFlex</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Gefahrstoffzulagen</td><td class="py-3 px-4">5-15% je nach Arbeitsplatz-Klassifikation</td></tr>
</tbody>
</table>
</div>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Vorher / Nachher</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th scope="col" class="text-left py-3 px-4 font-semibold text-white">Dimension</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manuell</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Fehlerquote</td><td class="py-3 px-4">1-8% (APA)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 0,1%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Automatisierungsquote</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">88%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Tarifwechsel</td><td class="py-3 px-4">Wochen (13 Bezirke manuell)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 24h (alle Bezirke)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Zuschlagsberechnung</td><td class="py-3 px-4">Manuell, fehleranfällig</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Regelbasiert, konsistent</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Audit-Readiness</td><td class="py-3 px-4">Manuell rekonstruiert</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatisch erzeugt</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Zukunftsbetrag-Verwaltung</td><td class="py-3 px-4">Excel-Listen pro Standort</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Zentral, versioniert</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">APA: American Payroll Association. IG BCE Entgelttarifvertrag Chemie 2024-2026. Simulationsergebnisse: Gosign-Modellrechnung.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">In der Simulation erreicht der Decision Layer eine Automatisierungsquote von 88%. Die verbleibenden 12% sind echte Ausnahmen: Gefahrstoff-Neubewertungen, Zukunftsbetrag-Wahlrechtsänderungen, Versetzungen zwischen Tarifbezirken. Für die 88% liegt eine vollständige, prüfungssichere Entscheidungsakte vor.</p>
</div>
</section>

<!-- Architektur-Referenz -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Architektur und Implementierung</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">Der Payroll Decision Layer läuft vollständig in Ihrer Infrastruktur. Für die Chemieindustrie bedeutet das: Anbindung an Schichtplanungssysteme, Verarbeitung von Gefahrstoff-Mappings, tarifbezirksspezifische Regelwerke und durchgängiger Audit Trail bis SAP HCM. Typische Pilotprojekte starten innerhalb von 3 Monaten mit einem Tarifbezirk und einer Personalgruppe.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/de/leistungen/hr-agent/payroll-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Payroll Decision Layer Übersicht &rarr;</a>
<a href="/de/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Decision Layer Architektur &rarr;</a>
<a href="/de/leistungen/infrastruktur/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infrastruktur im Detail &rarr;</a>
<a href="/de/governance/mitbestimmung/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Mitbestimmung &amp; Betriebsrat &rarr;</a>
<a href="/de/governance/cert-ready/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready by Design &rarr;</a>
<a href="/de/leistungen/travel-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Travel Decision Layer &rarr;</a>
</div>
</div>
</section>


<!-- Weitere Agent-Lösungen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Weitere Agent-Lösungen</h2>
<p class="text-body-lg text-gosign-text-light mt-4">HR Agents sind Teil unseres Agent-Portfolios. Für Finance und andere Bereiche bieten wir spezialisierte Lösungen.</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8 max-w-content">
<a href="/de/hr-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR & People Operations</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Alle HR Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Betriebsratsfähig.</p>
</a>
<a href="/de/finance-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Finance & Accounting</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Finance AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Belegverarbeitung, Kontierung, AfA-Logik, Korrekturbuchungen. DATEV- und SAP-Integration.</p>
</a>
<a href="/de/kontakt/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Individuell</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Co-Build für Ihren Prozess</h3>
<p class="text-body text-gosign-text-light mt-2">Compliance, Operations, Shared Services - wir entwickeln Agenten im Co-Build.</p>
</a>
</div>
</div>
</section>

<!-- Vertiefung -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Vertiefung im Agent Briefing (Gosign Magazin)</h2>
<p class="text-body text-gosign-text-light mb-6">Unsere Fachartikel-Serie für Entscheider, die AI Agents im Unternehmen einführen.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/de/magazin/decision-layer-payroll/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Finance</p>
<p class="text-body font-semibold text-gosign-dark">Payroll-Fehler strukturell eliminieren - Decision Layer für Finance</p>
</a>
<a href="/de/magazin/betriebsrat-ki-mitbestimmung/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Mitbestimmung</p>
<p class="text-body font-semibold text-gosign-dark">Betriebsrat und KI - Mitbestimmung als Architektur-Constraint</p>
</a>
<a href="/de/magazin/decision-layer-erklaert/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Grundlagen</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - Was ist das und warum braucht jeder Enterprise AI Agent einen?</p>
</a>
</div>
</div>
</section>

<!-- Andere Branchen -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Payroll Decision Layer in anderen Branchen</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Jede Branche hat eigene Tarifverträge, eigene Zuschlagsregeln und eigene Komplexitätstreiber. Der Decision Layer ist derselbe. Die Konfiguration ist branchenspezifisch.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/de/leistungen/hr-agent/payroll-decision-layer/aviation/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Aviation</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">3 Gewerkschaften, 14-18 Tarifverträge, EASA FTL, Cockpit-Seniorität bis Stufe 23</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">82% vollautomatisch</span>
<span class="text-small text-gosign-accent-text font-semibold">Im Detail &rarr;</span>
</div>
</a>
<a href="/de/leistungen/hr-agent/payroll-decision-layer/finanzwesen/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Finanzwesen</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">5 Vergütungsregime, InstitutsVergV Bonus-Deferral, Malus/Clawback, MaRisk-Pflichten</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">85% vollautomatisch</span>
<span class="text-small text-gosign-accent-text font-semibold">Im Detail &rarr;</span>
</div>
</a>
<a href="/de/leistungen/hr-agent/payroll-decision-layer/handel/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Handel</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">576 Grundsätze (16 Länder x 6 Gruppen x 6 Stufen), 64% Teilzeit, Saison-Peaks</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">92% vollautomatisch</span>
<span class="text-small text-gosign-accent-text font-semibold">Im Detail &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- AI Payroll Agent Finanzwesen - Vergütung ---
> Payroll Decision Layer für Banken und Finanzdienstleister. 5 Vergütungsregime, InstitutsVergV Deferral, Malus/Clawback. 85% vollautomatisch.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/de/warum-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Jede Entscheidung nachvollziehbar</p>
</div>
</a>
<a href="/de/warum-gosign/#infrastruktur" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Ihre Infrastruktur</p>
<p class="text-xs text-gosign-text-light">Kein SaaS. Kein Vendor-Lock-in.</p>
</div>
</a>
<a href="/de/warum-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Kein US-Cloud-Risiko</p>
</div>
</a>
</div>
</div>
</div>

<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Payroll Decision Layer Branchen">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/de/leistungen/hr-agent/payroll-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Payroll Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/de/leistungen/hr-agent/payroll-decision-layer/chemie/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Chemie</a>
<a href="/de/leistungen/hr-agent/payroll-decision-layer/aviation/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Aviation</a>
<a href="/de/leistungen/hr-agent/payroll-decision-layer/finanzwesen/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Finanzwesen</a>
<a href="/de/leistungen/hr-agent/payroll-decision-layer/handel/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Handel</a>
</div>
</div>
</nav>

<!-- Komplexität -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">5</span>
<p class="text-small text-gosign-text-light mt-1">Vergütungsregime parallel</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">85%</span>
<p class="text-small text-gosign-text-light mt-1">Automatisierungsquote</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">4-5 J.</span>
<p class="text-small text-gosign-text-light mt-1">Bonus-Deferral-Zeitraum</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
<span class="w-4 h-2 rounded-sm bg-gosign-border"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">Hohe Regelkomplexität</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">InstitutsVergV, MaRisk BTO 2.2, MiFID II. vollautomatisch: Gosign-Simulationsmodell.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Was der Agent klassifiziert</p>
<h2 class="text-h1 font-bold text-gosign-dark">Fünf Regime, ein Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Fünf Vergütungsregime, Bonus-Caps, Deferral über Jahre, Malus/Clawback rückwirkend, BaFin-Meldepflicht. Sie kennen die Komplexität. So löst der AI Agent sie:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">5 Vergütungsregime parallel</h3>
<p class="text-body text-gosign-text mt-2">Tarif, AT, Risk Taker, Trading, Sales/Advisory - jedes Regime mit eigener Berechnungslogik. Der AI Agent erkennt die korrekte Zuordnung aus Vertragsdaten, Funktion und Gesamtvergütung. Bei Regime-Wechsel im Karriereverlauf: automatische Umstellung aller Berechnungsparameter.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Bonus-Deferral über 4-5 Jahre</h3>
<p class="text-body text-gosign-text mt-2">40-60% der variablen Vergütung gestreckt, aufgeteilt in Aktien- und Cash-Komponenten, bis zu 20 parallele Tranchen. Der AI Agent verwaltet jede Tranche mit eigenem Vesting-Datum und prüft den Bonus-Cap (100% Fix, 200% mit HV-Beschluss) automatisch gegen die InstitutsVergV.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Malus/Clawback rückwirkend</h3>
<p class="text-body text-gosign-text mt-2">Rückforderung über 5-7 Jahre bei Compliance-Verstößen oder Risikoereignissen. Der AI Agent erkennt relevante Ereignisse aus internen Meldungen und bereitet den Fall auf. Die Entscheidung trifft immer ein Mensch - die BaFin sieht persönliche Haftung der Vergütungsverantwortlichen vor.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">MaRisk Trading-Pflichten</h3>
<p class="text-body text-gosign-text mt-2">10 zusammenhängende Pflicht-Urlaubstage pro Jahr, kein Splitting. Der AI Agent prüft automatisch, ob der Urlaubsblock eingehalten wird, und eskaliert rechtzeitig an HR. Keine manuelle Kalenderprüfung, kein Übersehen von Pflichtfristen.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">BaFin-Meldepflichten</h3>
<p class="text-body text-gosign-text mt-2">Jährliche Vergütungsmeldung mit Risk-Taker-Vergütungen, Deferral-Ständen, Malus/Clawback-Ereignissen. Das Regelwerk erzeugt die Meldedaten automatisch aus den Abrechnungsdaten. Dazu MiFID II-Prüfung: variable Komponenten nachweisbar an Kundenqualität gekoppelt.</p>
</div>
</div>
</div>
</section>

<!-- Decision Flow -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Eine Finanz-Abrechnung. 30 bis 60 Mikro-Entscheidungen.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Ein Risk Taker in einer Universalbank. Der Payroll Decision Layer zerlegt seine Abrechnung in einzelne Entscheidungsschritte:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Schritt</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Entscheidung</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Entscheider</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Begründung</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Vergütungsregime klassifizieren</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent erkennt: Tarif (TG 1-9), AT, Risk Taker, Trading oder Sales/Advisory aus Vertragsdaten</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Risk-Taker-Status prüfen</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">EUR 500.000 Schwelle prüfen, EBA-Identifikation gegen Funktionskatalog abgleichen</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Fixgehalt berechnen</td><td class="py-3 px-4">Tarifvertrag/Vertrag</td><td class="py-3 px-4">Tarif: TG-Lookup aus Tariftabelle. AT: individuelle Vereinbarung aus Vertragsdaten</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Variable Vergütung berechnen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">Performance-Bewertung, Bonus-Cap 100% Fixgehalt (200% mit HV-Beschluss)</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Deferral-Split berechnen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">40-60% über 4-5 Jahre, Aufteilung in Aktien- und Cash-Komponenten, Vesting-Termine</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Malus-Prüfung durchführen</td><td class="py-3 px-4">KI erkennt, Mensch entscheidet</td><td class="py-3 px-4">KI erkennt Compliance-Verstöße zuverlässiger. Aber Malus-Entscheidungen haben persönliche Haftungsfolgen - BetrVG und BaFin erfordern menschliche Verantwortung</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">MaRisk-Urlaubsblock prüfen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">10 zusammenhängende Urlaubstage pro Jahr, Vertretungsregelung, Eskalation bei Nichterfüllung</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">SV-Beiträge berechnen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">BBG-Prüfung, Zusatzversorgung, betriebliche Altersvorsorge</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">BaFin-Meldedaten erzeugen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">Jährliche Vergütungsmeldung: Risk-Taker-Daten, Deferral-Stände, Clawback-Ereignisse</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Buchungssätze erzeugen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">FI/CO-Kontierung, Multi-Entity-Buchung, Deferral-Rückstellungen - deterministisch</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Simulation -->
<section id="simulation" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulation</p>
<h2 class="text-h1 font-bold text-white">Durchgerechnet für Finanz-Volumina</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Wir haben den Payroll Decision Layer mit realistischen Finanzwesen-Parametern konfiguriert und durchgerechnet. InstitutsVergV, MaRisk, MiFID II, fünf Vergütungsregime, Deferral-Zeiträume über Jahre.</p>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Simulationsparameter</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Mitarbeiter</td><td class="py-3 px-4">2.000 bis 30.000+ (Front Office, Middle Office, Back Office)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Vergütungsregime</td><td class="py-3 px-4">5 parallel: Tarif (TG 1-9), AT, Risk Taker, Trading, Sales/Advisory</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Risk-Taker-Schwelle</td><td class="py-3 px-4">EUR 500.000 Gesamtvergütung, EBA-Identifikation</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Bonus-Cap</td><td class="py-3 px-4">100% Fixgehalt (200% mit Hauptversammlungsbeschluss)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Deferral</td><td class="py-3 px-4">40-60% über 4-5 Jahre, Aktien/Cash-Split</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Malus/Clawback</td><td class="py-3 px-4">5-7 Jahre Rückforderungszeitraum</td></tr>
</tbody>
</table>
</div>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Vorher / Nachher</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th scope="col" class="text-left py-3 px-4 font-semibold text-white">Dimension</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manuell</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Fehlerquote</td><td class="py-3 px-4">1-8% (APA)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 0,1%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Automatisierungsquote</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">85%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Deferral-Verwaltung</td><td class="py-3 px-4">Excel, fehleranfällig</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatisiert, versioniert</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Risk-Taker-Identifikation</td><td class="py-3 px-4">Jährlich manuell</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Kontinuierlich, automatisch</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">BaFin-Meldung</td><td class="py-3 px-4">Wochen (manuelle Aufbereitung)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 24h (automatisch erzeugt)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Audit-Readiness</td><td class="py-3 px-4">Manuell rekonstruiert</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatisch erzeugt</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">APA: American Payroll Association. InstitutsVergV 2017, MaRisk 2023, MiFID II. Simulationsergebnisse: Gosign-Modellrechnung.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">In der Simulation erreicht der Decision Layer eine Automatisierungsquote von 85%. Die verbleibenden 15% sind echte Ausnahmen: Risk-Taker-Grenzfälle, Malus-Entscheidungen, Regime-Wechsel bei Funktionsänderungen. Für die 85% liegt eine vollständige, prüfungssichere Entscheidungsakte vor.</p>
</div>
</section>

<!-- Architektur-Referenz -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Architektur und Implementierung</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">Der Payroll Decision Layer läuft vollständig in Ihrer Infrastruktur. Für das Finanzwesen bedeutet das: Anbindung an Kernbanksysteme, Verarbeitung von Risk-Taker-Identifikation, regulatorische Regelwerke für InstitutsVergV und MaRisk, und durchgängiger Audit Trail bis SAP HCM. Typische Pilotprojekte starten innerhalb von 3 Monaten mit einem Vergütungsregime und einer Personalgruppe.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/de/leistungen/hr-agent/payroll-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Payroll Decision Layer Übersicht &rarr;</a>
<a href="/de/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Decision Layer Architektur &rarr;</a>
<a href="/de/leistungen/infrastruktur/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infrastruktur im Detail &rarr;</a>
<a href="/de/governance/mitbestimmung/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Mitbestimmung &amp; Betriebsrat &rarr;</a>
<a href="/de/governance/cert-ready/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready by Design &rarr;</a>
<a href="/de/leistungen/travel-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Travel Decision Layer &rarr;</a>
</div>
</div>
</section>


<!-- Weitere Agent-Lösungen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Weitere Agent-Lösungen</h2>
<p class="text-body-lg text-gosign-text-light mt-4">HR Agents sind Teil unseres Agent-Portfolios. Für Finance und andere Bereiche bieten wir spezialisierte Lösungen.</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8 max-w-content">
<a href="/de/hr-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR & People Operations</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Alle HR Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Betriebsratsfähig.</p>
</a>
<a href="/de/finance-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Finance & Accounting</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Finance AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Belegverarbeitung, Kontierung, AfA-Logik, Korrekturbuchungen. DATEV- und SAP-Integration.</p>
</a>
<a href="/de/kontakt/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Individuell</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Co-Build für Ihren Prozess</h3>
<p class="text-body text-gosign-text-light mt-2">Compliance, Operations, Shared Services - wir entwickeln Agenten im Co-Build.</p>
</a>
</div>
</div>
</section>

<!-- Vertiefung -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Vertiefung im Agent Briefing (Gosign Magazin)</h2>
<p class="text-body text-gosign-text-light mb-6">Unsere Fachartikel-Serie für Entscheider, die AI Agents im Unternehmen einführen.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/de/magazin/decision-layer-payroll/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Finance</p>
<p class="text-body font-semibold text-gosign-dark">Payroll-Fehler strukturell eliminieren - Decision Layer für Finance</p>
</a>
<a href="/de/magazin/betriebsrat-ki-mitbestimmung/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Mitbestimmung</p>
<p class="text-body font-semibold text-gosign-dark">Betriebsrat und KI - Mitbestimmung als Architektur-Constraint</p>
</a>
<a href="/de/magazin/decision-layer-erklaert/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Grundlagen</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - Was ist das und warum braucht jeder Enterprise AI Agent einen?</p>
</a>
</div>
</div>
</section>

<!-- Andere Branchen -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Payroll Decision Layer in anderen Branchen</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Jede Branche hat eigene Tarifverträge, eigene Zuschlagsregeln und eigene Komplexitätstreiber. Der Decision Layer ist derselbe. Die Konfiguration ist branchenspezifisch.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/de/leistungen/hr-agent/payroll-decision-layer/chemie/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Chemie</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">169 Grundvergütungssätze (13 Bezirke x 13 Gruppen), Schichtzuschläge, Zukunftsbetrag</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">88% vollautomatisch</span>
<span class="text-small text-gosign-accent-text font-semibold">Im Detail &rarr;</span>
</div>
</a>
<a href="/de/leistungen/hr-agent/payroll-decision-layer/aviation/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Aviation</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">3 Gewerkschaften, 14-18 Tarifverträge, EASA FTL, Cockpit-Seniorität bis Stufe 23</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">82% vollautomatisch</span>
<span class="text-small text-gosign-accent-text font-semibold">Im Detail &rarr;</span>
</div>
</a>
<a href="/de/leistungen/hr-agent/payroll-decision-layer/handel/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Handel</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">576 Grundsätze (16 Länder x 6 Gruppen x 6 Stufen), 64% Teilzeit, Saison-Peaks</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">92% vollautomatisch</span>
<span class="text-small text-gosign-accent-text font-semibold">Im Detail &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- AI Payroll Agent Handel - Entgeltabrechnung ---
> Payroll Decision Layer für den Einzelhandel. 576 Grundvergütungssätze, 64% Teilzeit, Saisonkräfte, Zuschlagskumulierung. 92% vollautomatisch.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/de/warum-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Jede Entscheidung nachvollziehbar</p>
</div>
</a>
<a href="/de/warum-gosign/#infrastruktur" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Ihre Infrastruktur</p>
<p class="text-xs text-gosign-text-light">Kein SaaS. Kein Vendor-Lock-in.</p>
</div>
</a>
<a href="/de/warum-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Kein US-Cloud-Risiko</p>
</div>
</a>
</div>
</div>
</div>
<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Payroll Decision Layer Branchen">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/de/leistungen/hr-agent/payroll-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Payroll Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/de/leistungen/hr-agent/payroll-decision-layer/chemie/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Chemie</a>
<a href="/de/leistungen/hr-agent/payroll-decision-layer/aviation/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Aviation</a>
<a href="/de/leistungen/hr-agent/payroll-decision-layer/finanzwesen/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Finanzwesen</a>
<a href="/de/leistungen/hr-agent/payroll-decision-layer/handel/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Handel</a>
</div>
</div>
</nav>

<!-- Komplexität -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">576</span>
<p class="text-small text-gosign-text-light mt-1">Grundvergütungssätze</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">92%</span>
<p class="text-small text-gosign-text-light mt-1">Automatisierungsquote</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">64%</span>
<p class="text-small text-gosign-text-light mt-1">Teilzeitquote</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
<span class="w-4 h-2 rounded-sm bg-gosign-border"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">Hohe Regelkomplexität</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">Tarifverträge Einzelhandel 2024-2026, 16 Bundesländer. vollautomatisch: Gosign-Simulationsmodell.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Was der Agent klassifiziert</p>
<h2 class="text-h1 font-bold text-gosign-dark">16 Bundesländer, ein Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">16 Ländertarifverträge, 64% Teilzeit, 100.000 Saisonkräfte, 25,7% Fluktuation. Sie kennen die Komplexität. So löst der AI Agent sie:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">576 Grundvergütungssätze (16 Bundesländer)</h3>
<p class="text-body text-gosign-text mt-2">16 Bundesländer, 6 Entgeltgruppen, 6 Erfahrungsstufen, 576 Kombinationen. Der AI Agent erkennt die korrekte Kombination aus Standort, Tätigkeit und Betriebszugehörigkeit. Bei Filialwechsel zwischen Bundesländern: automatische Umstellung der gesamten Vergütungsstruktur.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">64% Teilzeit (Mini-Job/Midijob-Gleitzone)</h3>
<p class="text-body text-gosign-text mt-2">Mini-Jobs bis EUR 556, Midijobs bis EUR 2.000 mit gleitender SV-Formel. Der AI Agent prüft bei jeder Abrechnung das kumulierte Monatsentgelt und klassifiziert den korrekten SV-Status. Bei gesetzlicher Grenzverschiebung: automatische Neuklassifizierung aller betroffenen Beschäftigten.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">100.000 Saisonkräfte (70-Tage-Regel)</h3>
<p class="text-body text-gosign-text mt-2">Maximal 70 Arbeitstage pro Kalenderjahr, sozialversicherungsfrei, aber lohnsteuerpflichtig. Der AI Agent führt einen exakten 70-Tage-Zähler pro Saisonkraft und Kalenderjahr - über alle Filialen hinweg. Bei Annäherung an die Grenze: automatische Eskalation. Bei Überschreitung: rückwirkende SV-Pflicht ab Tag 1.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Zuschlagskumulierung (nur höchster, Nacht additiv)</h3>
<p class="text-body text-gosign-text mt-2">Spätarbeit 20-40%, Sonntag 120%, Feiertag 200%, Nacht 55%. Der AI Agent wendet die Kumulierungsregel an: höchster Zuschlag greift, Nachtzuschlag immer additiv. Sonntagabend mit Nachtarbeit: 120% plus 55%, nicht 200%. Kein manuelles Nachrechnen pro Schicht.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">25,7% Fluktuation (permanenter On-/Offboarding-Strom)</h3>
<p class="text-body text-gosign-text mt-2">Über 2.500 Ein- und Austritte pro Jahr bei 10.000 Beschäftigten. Der AI Agent berechnet Prorata-Vergütung, Resturlaub-Abgeltung und SV-Abmeldungen automatisch - jeder Fall individuell, ohne manuelle anteilige Berechnung.</p>
</div>
</div>
</div>
</section>

<!-- Decision Flow -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Eine Handel-Abrechnung. 30 bis 60 Mikro-Entscheidungen.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Eine Teilzeitkraft im Einzelhandel mit Spät- und Sonntagsschichten. Der Payroll Decision Layer zerlegt ihre Abrechnung in einzelne Entscheidungsschritte:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Schritt</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Entscheidung</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Entscheider</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Begründung</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Bundesland und Tarifgebiet klassifizieren</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Standort → Bundesland → korrekte Tariftabelle aus 16 Ländertarifverträgen</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Entgeltgruppe und Stufe zuordnen</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Tätigkeit → Entgeltgruppe (1-6), Betriebszugehörigkeit → Erfahrungsstufe (1-6)</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Grundvergütung berechnen</td><td class="py-3 px-4">Tarifvertrag</td><td class="py-3 px-4">Lookup in bundeslandspezifischer Tabelle: Entgeltgruppe + Stufe → Grundgehalt</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Teilzeit-Umrechnung</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">Anteilige Berechnung nach Vertragsstunden, Stundenlohn-Ermittlung für Zuschläge</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Mini-Job/Midijob-Status prüfen</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Kumuliertes Monatsentgelt gegen EUR 556-Grenze und EUR 2.000-Gleitzone prüfen</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Zuschläge klassifizieren und kumulieren</td><td class="py-3 px-4">AI Agent + Tarifvertrag</td><td class="py-3 px-4">Spät 20-40%, Nacht 55%, Sonntag 120%, Feiertag 200% - nur höchster Zuschlag, Nacht additiv</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">SV-Beiträge berechnen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">Standard-SV, Mini-Job pauschale (30% AG), oder Midijob-Gleitzonenformel</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">Saisonkraft-Status prüfen</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">70-Tage-Zähler pro Kalenderjahr, SV-Befreiung bei Einhaltung, Lohnsteuerpflicht</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Abweichungsprüfung</td><td class="py-3 px-4">KI erkennt, Mensch entscheidet</td><td class="py-3 px-4">KI erkennt Abweichungen zuverlässiger. Aber die Bewertung (Statuswechsel, Fehler, Filialwechsel?) bleibt beim Menschen - BetrVG § 87 Abs. 1 Nr. 6</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Buchungssätze erzeugen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">FI/CO-Kontierung, Multi-Filiale, Kostenstellenzuordnung - deterministisch</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Simulation -->
<section id="simulation" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulation</p>
<h2 class="text-h1 font-bold text-white">Durchgerechnet für Handel-Volumina</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Wir haben den Payroll Decision Layer mit realistischen Handel-Parametern konfiguriert und durchgerechnet. 16 Ländertarifverträge, Mini-Job/Midijob-Gleitzone, Saisonkräfte, Zuschlagskumulierung, Hochfluktuation.</p>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Simulationsparameter</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Mitarbeiter</td><td class="py-3 px-4">5.000 bis 50.000+ (Verkauf, Kasse, Lager, Verwaltung)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Tarifvertrag</td><td class="py-3 px-4">Einzelhandel, 16 Bundesländer, 6 Entgeltgruppen, 6 Stufen</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Grundvergütungssätze</td><td class="py-3 px-4">576 (16 Bundesländer x 6 Gruppen x 6 Stufen)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Teilzeitquote</td><td class="py-3 px-4">64% (Mini-Job, Midijob, reguläre Teilzeit)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Saisonkräfte</td><td class="py-3 px-4">Ca. 100.000 (70-Tage-Regel, SV-frei, lohnsteuerpflichtig)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Zuschläge</td><td class="py-3 px-4">Spät 20-40%, Nacht 55%, Sonntag 120%, Feiertag 200%</td></tr>
</tbody>
</table>
</div>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Vorher / Nachher</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th scope="col" class="text-left py-3 px-4 font-semibold text-white">Dimension</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manuell</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Fehlerquote</td><td class="py-3 px-4">1-8% (APA)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 0,1%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Automatisierungsquote</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">92%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Tarifwechsel</td><td class="py-3 px-4">Wochen (16 Länder manuell)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 24h (alle Länder)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Mini-Job/Midijob-Erkennung</td><td class="py-3 px-4">Manuell, verzögert</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Echtzeit, pro Abrechnung</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Saisonkraft-Tracking</td><td class="py-3 px-4">Excel, filialübergreifend lückenhaft</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatisch, alle Filialen</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Audit-Readiness</td><td class="py-3 px-4">Manuell rekonstruiert</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatisch erzeugt</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">APA: American Payroll Association. Tarifverträge Einzelhandel 2024-2026, 16 Bundesländer. Simulationsergebnisse: Gosign-Modellrechnung.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">In der Simulation erreicht der Decision Layer eine Automatisierungsquote von 92%. Die verbleibenden 8% sind echte Ausnahmen: Saisonkraft-Grenzfälle, Statuswechsel zwischen Mini-Job und Midijob, filialübergreifende Versetzungen zwischen Bundesländern. Für die 92% liegt eine vollständige, prüfungssichere Entscheidungsakte vor.</p>
</div>
</section>

<!-- Architektur-Referenz -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Architektur und Implementierung</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">Der Payroll Decision Layer läuft vollständig in Ihrer Infrastruktur. Für den Einzelhandel bedeutet das: Anbindung an Filial-Zeiterfassung, Verarbeitung von Mini-Job/Midijob-Statuswechseln, bundeslandspezifische Tariftabellen, Saisonkraft-Tracking über alle Standorte und durchgängiger Audit Trail bis SAP HCM. Typische Pilotprojekte starten innerhalb von 3 Monaten mit einem Bundesland und einer Filialgruppe.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/de/leistungen/hr-agent/payroll-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Payroll Decision Layer Übersicht &rarr;</a>
<a href="/de/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Decision Layer Architektur &rarr;</a>
<a href="/de/leistungen/infrastruktur/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infrastruktur im Detail &rarr;</a>
<a href="/de/governance/mitbestimmung/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Mitbestimmung &amp; Betriebsrat &rarr;</a>
<a href="/de/governance/cert-ready/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready by Design &rarr;</a>
<a href="/de/leistungen/travel-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Travel Decision Layer &rarr;</a>
</div>
</div>
</section>


<!-- Weitere Agent-Lösungen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Weitere Agent-Lösungen</h2>
<p class="text-body-lg text-gosign-text-light mt-4">HR Agents sind Teil unseres Agent-Portfolios. Für Finance und andere Bereiche bieten wir spezialisierte Lösungen.</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8 max-w-content">
<a href="/de/hr-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR & People Operations</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Alle HR Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Betriebsratsfähig.</p>
</a>
<a href="/de/finance-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Finance & Accounting</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Finance AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Belegverarbeitung, Kontierung, AfA-Logik, Korrekturbuchungen. DATEV- und SAP-Integration.</p>
</a>
<a href="/de/kontakt/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Individuell</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Co-Build für Ihren Prozess</h3>
<p class="text-body text-gosign-text-light mt-2">Compliance, Operations, Shared Services - wir entwickeln Agenten im Co-Build.</p>
</a>
</div>
</div>
</section>

<!-- Vertiefung -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Vertiefung im Agent Briefing (Gosign Magazin)</h2>
<p class="text-body text-gosign-text-light mb-6">Unsere Fachartikel-Serie für Entscheider, die AI Agents im Unternehmen einführen.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/de/magazin/decision-layer-payroll/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Finance</p>
<p class="text-body font-semibold text-gosign-dark">Payroll-Fehler strukturell eliminieren - Decision Layer für Finance</p>
</a>
<a href="/de/magazin/betriebsrat-ki-mitbestimmung/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Mitbestimmung</p>
<p class="text-body font-semibold text-gosign-dark">Betriebsrat und KI - Mitbestimmung als Architektur-Constraint</p>
</a>
<a href="/de/magazin/decision-layer-erklaert/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Grundlagen</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - Was ist das und warum braucht jeder Enterprise AI Agent einen?</p>
</a>
</div>
</div>
</section>

<!-- Andere Branchen -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Payroll Decision Layer in anderen Branchen</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Jede Branche hat eigene Tarifverträge, eigene Zuschlagsregeln und eigene Komplexitätstreiber. Der Decision Layer ist derselbe. Die Konfiguration ist branchenspezifisch.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/de/leistungen/hr-agent/payroll-decision-layer/chemie/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Chemie</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">169 Grundvergütungssätze, 13 Tarifbezirke, Schichtzuschläge, Zukunftsbetrag mit Dreifach-Wahlrecht</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">88% vollautomatisch</span>
<span class="text-small text-gosign-accent-text font-semibold">Im Detail &rarr;</span>
</div>
</a>
<a href="/de/leistungen/hr-agent/payroll-decision-layer/aviation/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Aviation</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">3 Gewerkschaften, 14-18 Tarifverträge, EASA FTL, Cockpit-Seniorität bis Stufe 23</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">82% vollautomatisch</span>
<span class="text-small text-gosign-accent-text font-semibold">Im Detail &rarr;</span>
</div>
</a>
<a href="/de/leistungen/hr-agent/payroll-decision-layer/finanzwesen/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Finanzwesen</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">5 Vergütungsregime, InstitutsVergV Bonus-Deferral, Malus/Clawback, MaRisk-Pflichten</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">85% vollautomatisch</span>
<span class="text-small text-gosign-accent-text font-semibold">Im Detail &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- AI Payroll Decision Layer - Entgeltabrechnung ---
> Der Decision Layer zerlegt jede Entgeltabrechnung in Entscheidungsschritte. Regelbasiert, auditierbar, 82-92% vollautomatisch.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/de/warum-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Jede Entscheidung nachvollziehbar</p>
</div>
</a>
<a href="/de/warum-gosign/#infrastruktur" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Ihre Infrastruktur</p>
<p class="text-xs text-gosign-text-light">Kein SaaS. Kein Vendor-Lock-in.</p>
</div>
</a>
<a href="/de/warum-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Kein US-Cloud-Risiko</p>
</div>
</a>
</div>
</div>
</div>

<!-- Problem -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<!-- Benchmarks als visuelle Einleitung -->
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">1-8%</span>
<p class="text-small text-gosign-text-light mt-1">Fehlerquote in der Entgeltabrechnung</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">EUR 260</span>
<p class="text-small text-gosign-text-light mt-1">Gesamtkosten pro Fehler-Incident</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">10</span>
<p class="text-small text-gosign-text-light mt-1">Entscheidungsschritte pro Abrechnung</p>
</div>
<p class="sm:col-span-3 text-xs text-gosign-text-light">American Payroll Association (APA); EY / HR Dive, "The True Cost of Payroll" (USD 281 pro Incident, umgerechnet zum Durchschnittskurs)</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Das Problem</p>
<h2 class="text-h1 font-bold text-gosign-dark">Warum Payroll-Systeme in komplexen Organisationen scheitern</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">SAP HCM rechnet korrekt. DATEV LODAS rechnet korrekt. Jede Payroll-Engine rechnet korrekt - wenn die Eingaben stimmen. Aber in Organisationen mit mehreren Tarifverträgen, Schichtmodellen, regionalen Abweichungen und dutzenden Zuschlagsregeln ist die Berechnung nicht das Problem. Die Entscheidung davor ist es: Welche Tabelle gilt? Welcher Zuschlag greift? Ist die Kumulierung erlaubt?</p>
<div class="mt-10">
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-bold text-gosign-dark">1-8% Fehlerquote</h3>
<p class="text-small text-gosign-text-light mt-2">13 Entgeltgruppen, 13 Tarifbezirke, 6 Steuerklassen, 4 SV-Zweige, Beitragsbemessungsgrenzen, Entgeltumwandlung, Pfändung, Zuschläge mit Kumulierungsregeln. Kein Sachbearbeiter kennt alle Regeln in allen Tarifgebieten. 1-8% aller Abrechnungen sind fehlerhaft (APA) - je komplexer die Tariflandschaft, desto höher die Quote.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-bold text-gosign-dark">EUR 260 pro Fehler</h3>
<p class="text-small text-gosign-text-light mt-2">Ein einziger Abrechnungsfehler zieht vier Folgeprozesse nach sich: Storno der Originalabrechnung, Neuberechnung, SV-Korrekturmeldung an die Krankenkasse, korrigierte Lohnsteueranmeldung ans Finanzamt. In Summe kostet ein Fehler-Incident durchschnittlich EUR 260 (EY; Originalstudie: USD 281). Bei 2.000 Mitarbeitern und 1-8% Fehlerquote sind das 20-160 Incidents pro Monat.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-bold text-gosign-dark">Null Regelwerk-Transparenz</h3>
<p class="text-small text-gosign-text-light mt-2">Wenn die Betriebsprüfung fragt: Warum wurden 25% Nachtzuschlag berechnet statt 20%? Welcher Tarifvertrag galt zu dem Zeitpunkt? War die Entgeltgruppe korrekt? Dann fehlt der Nachweis. Payroll-Systeme dokumentieren Ergebnisse. Nicht die Entscheidungen, die dazu geführt haben.</p>
</div>
</div>
</div>
</div>
</section>

<!-- Decision Layer Prinzip -->
<section id="decision-layer" class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Der Decision Layer</p>
<h2 class="text-h1 font-bold text-gosign-dark">Jede Abrechnung. Zerlegt in Entscheidungsschritte.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Der Payroll Decision Layer zerlegt jede Abrechnung in einzelne Entscheidungsschritte. Für jeden Schritt ist definiert, wer entscheidet: Der AI Agent klassifiziert Sachverhalte und erkennt Abweichungen - zuverlässiger und schneller als jeder Sachbearbeiter. Das Regelwerk berechnet Beträge - deterministisch und reproduzierbar. Der Mensch bleibt dort im Prozess, wo Betriebsrat (BetrVG), Arbeitsrecht oder Diskriminierungsrisiko eine menschliche Entscheidung verlangen.</p>

<!-- 10 Mikro-Entscheidungen -->
<div class="mt-10 overflow-x-auto">
<table class="w-full text-left text-body">
<thead>
<tr class="border-b-2 border-gosign-dark">
<th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Schritt</th>
<th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Entscheidung</th>
<th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Entscheider</th>
<th scope="col" class="py-3 font-bold text-gosign-dark">Begründung</th>
</tr>
</thead>
<tbody class="text-gosign-text-light">
<tr class="border-b border-gosign-border"><td class="py-3 pr-4 font-medium text-gosign-dark">1</td><td class="py-3 pr-4">Steuerklasse, Freibeträge, SV-Merkmale validieren</td><td class="py-3 pr-4 font-medium">Regelwerk</td><td class="py-3">Abgleich mit ELStAM-Daten, deterministisch</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4 font-medium text-gosign-dark">2</td><td class="py-3 pr-4">Tarifvertragliche Eingruppierung prüfen</td><td class="py-3 pr-4 font-medium">AI Agent</td><td class="py-3">Agent klassifiziert: Welcher Tarifvertrag, welche Entgeltgruppe, welche Stufe? Gleicht gegen Personalstamm ab und erkennt Inkonsistenzen</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4 font-medium text-gosign-dark">3</td><td class="py-3 pr-4">Grundvergütung berechnen</td><td class="py-3 pr-4 font-medium">Tarifvertrag</td><td class="py-3">Lookup in versionierter Tariftabelle, Region + Gruppe + Stufe</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4 font-medium text-gosign-dark">4</td><td class="py-3 pr-4">Zuschläge berechnen (Nacht/Sonntag/Feiertag)</td><td class="py-3 pr-4 font-medium">AI Agent + Tarifvertrag</td><td class="py-3">Agent klassifiziert Zuschlagsart aus Schichtdaten. Tarifvertrag definiert Sätze + Kumulierungsregel (höchster greift, Nacht immer additiv)</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4 font-medium text-gosign-dark">5</td><td class="py-3 pr-4">Steuerfreie Anteile identifizieren</td><td class="py-3 pr-4 font-medium">Regelwerk</td><td class="py-3">§ 3b EStG: Nacht 25%, Sonntag 50%, Feiertag 125% des Grundlohns steuerfrei</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4 font-medium text-gosign-dark">6</td><td class="py-3 pr-4">Entgeltumwandlung / bAV berechnen</td><td class="py-3 pr-4 font-medium">Regelwerk</td><td class="py-3">AN-Anteil + AG-Zuschuss 15%, Steuer-/SV-Freibeträge prüfen</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4 font-medium text-gosign-dark">7</td><td class="py-3 pr-4">Sozialversicherungsbeiträge berechnen</td><td class="py-3 pr-4 font-medium">Regelwerk</td><td class="py-3">KV/RV/AV/PV mit BBG-Prüfung, Gleitzone bei Midijob</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4 font-medium text-gosign-dark">8</td><td class="py-3 pr-4">Pfändungen anwenden</td><td class="py-3 pr-4 font-medium">Regelwerk + Mensch</td><td class="py-3">Pfändungstabelle deterministisch, bei Rangfolge-Konflikten: Human-in-the-Loop</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4 font-medium text-gosign-dark">9</td><td class="py-3 pr-4">Abweichungsprüfung gegen Vormonat</td><td class="py-3 pr-4 font-medium">KI erkennt, Mensch entscheidet</td><td class="py-3">Die KI erkennt Abweichungen zuverlässiger als jeder Sachbearbeiter. Aber die Entscheidung, was mit einer Abweichung passiert, muss beim Menschen bleiben: War es eine Beförderung, ein Datenfehler oder ein echter Abrechnungsfehler? Ohne diese Trennung wird Compliance-Prüfung zur Leistungsüberwachung - und dafür gilt BetrVG § 87 Abs. 1 Nr. 6 (Mitbestimmung bei technischen Einrichtungen, die Verhalten oder Leistung überwachen). Das will niemand.</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4 font-medium text-gosign-dark">10</td><td class="py-3 pr-4">Buchungssätze erzeugen</td><td class="py-3 pr-4 font-medium">Regelwerk</td><td class="py-3">FI/CO-Kontierung, Kostenstelle, Buchungsperiode - deterministisch</td></tr>
</tbody>
</table>
</div>

<p class="text-body text-gosign-text mt-8 max-w-narrow font-semibold">10 Schritte pro Abrechnung. Der AI Agent kann jeden davon besser und schneller als ein Sachbearbeiter. Trotzdem bleibt der Mensch an definierten Stellen im Prozess - nicht weil er es besser kann, sondern weil Betriebsrat, Arbeitsrecht oder Diskriminierungsrisiko es verlangen. Bei 10.000 Mitarbeitern sind das 100.000 dokumentierte Mikro-Entscheidungen pro Monat.</p>

<div class="mt-10 grid grid-cols-1 sm:grid-cols-2 gap-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-body font-bold text-gosign-dark">KI klassifiziert. Regelwerk rechnet.</h3>
<p class="text-small text-gosign-text-light mt-2">Der AI Agent erkennt: Welcher Tarifvertrag gilt? Welche Zuschlagsart greift? Ist die Eingruppierung korrekt? Diese Klassifikation kann er zuverlässiger als jeder Sachbearbeiter. Die Berechnung des Betrags läuft dann durch versionierte Decision Tables - deterministisch, reproduzierbar, auditierbar.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-body font-bold text-gosign-dark">40 bis 80 Mikro-Entscheidungen pro Abrechnung</h3>
<p class="text-small text-gosign-text-light mt-2">Die 10 Hauptschritte zerlegen sich in Dutzende Unterschritte: Jeder Zuschlag hat eigene Kumulierungsregeln, jede SV-Art eigene BBG-Prüfung, jede Pfändung eigene Rangfolge. Jede einzeln dokumentiert.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-body font-bold text-gosign-dark">AI Agent, Regelwerk oder Mensch</h3>
<p class="text-small text-gosign-text-light mt-2">Der AI Agent klassifiziert Sachverhalte und trifft Entscheidungen - zuverlässiger als jeder Sachbearbeiter. Das Regelwerk berechnet den Betrag. Der Mensch bleibt dort im Prozess, wo Betriebsrat (BetrVG), Arbeitsrecht oder Diskriminierungsrisiko eine menschliche Entscheidung verlangen - nicht weil er es besser kann, sondern weil er es muss.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-body font-bold text-gosign-dark">Mensch im Loop: nicht Expertise, sondern Verantwortung</h3>
<p class="text-small text-gosign-text-light mt-2">Traditionelle Payroll verlangt manuelle Prüfung überall. AI Agents können das besser. Aber bei Pfändungsrangfolgen, Abweichungsbewertungen und Eingruppierungsentscheidungen verlangt der Gesetzgeber oder der Betriebsrat eine menschliche Entscheidung. Der Decision Layer weiß, wo - und eskaliert nur dort.</p>
</div>
</div>
</div>
</section>

<!-- Governance & Audit -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<h2 class="text-h1 font-bold text-gosign-dark">Nicht nachträglich dokumentiert. Im Prozess entstanden.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Wenn die Betriebsprüfung fragt "Warum wurden 25% Nachtzuschlag berechnet?" reicht "das steht im Tarifvertrag" nicht. Welcher Tarifvertrag? Welche Version? Galt die Kumulierungsregel? Der Payroll Decision Layer erzeugt für jede Mikroentscheidung einen Entscheidungsakt, der genau diese Fragen beantwortet: Input, angewandte Fachregel samt Version, Konfidenz, Ergebnis, Zeitstempel und Anfechtungspfad. Derselbe Akt macht auch die Erläuterung der Einzelentscheidung nach Art. 86 EU AI Act erfüllbar.</p>

<!-- Audit Trail Card -->
<div class="mt-10 bg-gosign-dark rounded-card p-6 sm:p-8">
<div class="flex items-start gap-4 mb-6">
<svg class="w-8 h-8 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12h6m-6 4h6m2 5H7a2 2 0 01-2-2V5a2 2 0 012-2h5.586a1 1 0 01.707.293l5.414 5.414a1 1 0 01.293.707V19a2 2 0 01-2 2z" /></svg>
<div>
<h3 class="text-h3 font-bold text-white">Jede Mikro-Entscheidung erzeugt einen Audit-Eintrag</h3>
<p class="text-small text-gosign-text-on-dark/70 mt-1">Append-only. Nichts wird überschrieben, nichts gelöscht. Bei Korrekturen entstehen Storno- und Adjustment-Einträge. SHA-256 signiert, jederzeit exportierbar.</p>
</div>
</div>
<div class="grid grid-cols-2 sm:grid-cols-3 gap-3 sm:gap-4">
<div class="flex items-center gap-2.5"><svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg><span class="text-small text-gosign-text-on-dark/80">Regel-ID + Version</span></div>
<div class="flex items-center gap-2.5"><svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg><span class="text-small text-gosign-text-on-dark/80">Tarifvertrag + Gültigkeitszeitraum</span></div>
<div class="flex items-center gap-2.5"><svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg><span class="text-small text-gosign-text-on-dark/80">Input-Daten (Stunden, Zuschlagsart)</span></div>
<div class="flex items-center gap-2.5"><svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg><span class="text-small text-gosign-text-on-dark/80">Ergebnis (Betrag, steuerliche Behandlung)</span></div>
<div class="flex items-center gap-2.5"><svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg><span class="text-small text-gosign-text-on-dark/80">Entscheider (Regelwerk / Tarif / Mensch)</span></div>
<div class="flex items-center gap-2.5"><svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg><span class="text-small text-gosign-text-on-dark/80">Input-Hash (reproduzierbar)</span></div>
</div>
</div>

<!-- Three Governance Pillars -->
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8">
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-3">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M15 12a3 3 0 11-6 0 3 3 0 016 0z" /><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M2.458 12C3.732 7.943 7.523 5 12 5c4.478 0 8.268 2.943 9.542 7-1.274 4.057-5.064 7-9.542 7-4.477 0-8.268-2.943-9.542-7z" /></svg>
<div>
<h3 class="text-body font-semibold text-gosign-dark">Betriebsrats-transparent</h3>
<p class="text-small text-gosign-text-light mt-2">BetrVG § 87 Abs. 1 Nr. 10: Absolute Mitbestimmung bei Entlohnungsgrundsätzen. Regelwerk einsehbar, Entscheidungen nachvollziehbar, Anomalie-Erkennung per Feature Flag steuerbar, Reports pseudonymisiert.</p>
<a href="/de/governance/mitbestimmung/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Mitbestimmung &rarr;</a>
</div>
</div>
</div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-3">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12l2 2 4-4m5.618-4.016A11.955 11.955 0 0112 2.944a11.955 11.955 0 01-8.618 3.04A12.02 12.02 0 003 9c0 5.591 3.824 10.29 9 11.622 5.176-1.332 9-6.03 9-11.622 0-1.042-.133-2.052-.382-3.016z" /></svg>
<div>
<h3 class="text-body font-semibold text-gosign-dark">Betriebsprüfungs-ready</h3>
<p class="text-small text-gosign-text-light mt-2">Aufbewahrungsfristen unterstützt (10 Jahre, AO § 147). Anonymisierung statt Löschung für DSGVO-Kompatibilität. Jede Abrechnung über Input-Hash reproduzierbar.</p>
<a href="/de/governance/cert-ready/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready &rarr;</a>
</div>
</div>
</div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-3">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 5H7a2 2 0 00-2 2v12a2 2 0 002 2h10a2 2 0 002-2V7a2 2 0 00-2-2h-2M9 5a2 2 0 002 2h2a2 2 0 002-2M9 5a2 2 0 012-2h2a2 2 0 012 2m-6 9l2 2 4-4" /></svg>
<div>
<h3 class="text-body font-semibold text-gosign-dark">Systematische Compliance</h3>
<p class="text-small text-gosign-text-light mt-2">Jede Abrechnung wird gegen das komplette Regelwerk geprüft - nicht stichprobenartig, sondern systematisch. Abweichungen werden erkannt und dokumentiert, nicht erst bei der Lohnsteuer-Außenprüfung.</p>
</div>
</div>
</div>
</div>
</div>
</section>

<!-- Integration -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Integration</p>
<h2 class="text-h1 font-bold text-gosign-dark">Dockt an Ihre bestehende Systemlandschaft an</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Ihre Systeme bleiben. Die manuelle Entscheidungsarbeit davor verschwindet. Der Payroll Decision Layer sitzt zwischen Ihren Vorsystemen und Ihrer Payroll-Engine - er trifft die Entscheidungen, die heute Sachbearbeiter treffen.</p>
<div class="grid grid-cols-1 md:grid-cols-3 gap-6 mt-10">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<div class="flex items-center gap-3 mb-4"><svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M20 7l-8-4-8 4m16 0l-8 4m8-4v10l-8 4m0-10L4 7m8 4v10M4 7v10l8 4" /></svg><h3 class="text-body font-semibold text-gosign-dark">Datenquellen</h3></div>
<ul class="space-y-2 text-small text-gosign-text-light">
<li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Zeiterfassung (SAP CATS, Atoss, Interflex)</span></li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Schichtplanung (ATOSS, SP Expert)</span></li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Personalstammdaten (SAP HCM, Workday)</span></li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>ELStAM (Finanzamt-Schnittstelle)</span></li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Tarifvertragsdatenbank (versioniert)</span></li>
</ul>
</div>
<div class="bg-gosign-dark border border-gosign-dark rounded-card p-6">
<div class="flex items-center gap-3 mb-4"><svg class="w-6 h-6 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9.75 3.104v5.714a2.25 2.25 0 01-.659 1.591L5 14.5M9.75 3.104c-.251.023-.501.05-.75.082m.75-.082a24.301 24.301 0 014.5 0m0 0v5.714c0 .597.237 1.17.659 1.591L19.8 15.3M14.25 3.104c.251.023.501.05.75.082M19.8 15.3l-1.57.393A9.065 9.065 0 0112 15a9.065 9.065 0 00-6.23.693L5 14.5m14.8.8l1.402 1.402c1.232 1.232.65 3.318-1.067 3.611A48.309 48.309 0 0112 21c-2.773 0-5.491-.235-8.135-.687-1.718-.293-2.3-2.379-1.067-3.61L5 14.5" /></svg><h3 class="text-body font-semibold text-white">Payroll Decision Layer</h3></div>
<ul class="space-y-2 text-small text-gosign-text-on-dark/80">
<li>Tarifvertragliche Eingruppierung</li><li>Zuschlagsberechnung + Kumulierung</li><li>Steuerfreie Anteile (§ 3b EStG)</li><li>SV-Beiträge + BBG-Prüfung</li><li>Pfändungsberechnung</li><li>Entgeltumwandlung / bAV</li><li>Abweichungsprüfung + Eskalation</li>
</ul>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<div class="flex items-center gap-3 mb-4"><svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M5.25 14.25h13.5m-13.5 0a3 3 0 01-3-3m3 3a3 3 0 100 6h13.5a3 3 0 100-6m-16.5-3a3 3 0 013-3h13.5a3 3 0 013 3m-19.5 0a4.5 4.5 0 01.9-2.7L5.737 5.1a3.375 3.375 0 012.7-1.35h7.126c1.062 0 2.062.5 2.7 1.35l2.587 3.45a4.5 4.5 0 01.9 2.7m0 0a3 3 0 01-3 3m0 3h.008v.008h-.008v-.008zm0-6h.008v.008h-.008v-.008zm-3 6h.008v.008h-.008v-.008zm0-6h.008v.008h-.008v-.008z" /></svg><h3 class="text-body font-semibold text-gosign-dark">Zielsysteme</h3></div>
<ul class="space-y-2 text-small text-gosign-text-light">
<li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>SAP HCM / SuccessFactors (Abrechnung)</span></li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>DATEV LODAS / Lohn und Gehalt</span></li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>SAP FI/CO (Buchung, Kontierung)</span></li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>SV-Meldesystem (DEÜV)</span></li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Finanzamt (ELStAM, LStA)</span></li>
</ul>
</div>
</div>
</div>
</section>

<!-- Branchen-Simulationen -->
<section id="simulationen" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simuliert für Enterprise-Volumina</p>
<h2 class="text-h1 font-bold text-white">Vier Branchen. Durchgerechnet.</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Wir haben den Payroll Decision Layer für vier Branchen konfiguriert und mit realistischen Tarifverträgen, Zuschlagsregeln und Personalstrukturen durchgerechnet. Jede Karte zeigt die Simulationsparameter und das Ergebnis.</p>
<div class="grid grid-cols-1 md:grid-cols-2 gap-6 mt-10">
<a href="/de/leistungen/hr-agent/payroll-decision-layer/chemie/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors">
<div class="flex items-center justify-between mb-4"><h3 class="text-h3 font-bold text-white">Chemie</h3><div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div></div>
<ul class="space-y-1.5 text-small text-gosign-text-on-dark/70"><li>13 Entgeltgruppen x 13 Tarifbezirke = 169 Grundsätze</li><li>Schichtzuschläge 6-10%, Erschwerniszulagen</li><li>Zukunftsbetrag 23% (Wahlrecht: Geld/Freizeit/Vorsorge)</li><li>CareFlex Chemie, 13. Monatsgehalt + Urlaubsgeld</li></ul>
<div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between"><span class="text-h3 font-bold text-gosign-accent-on-dark">88% vollautomatisch</span><span class="text-small text-gosign-accent-on-dark font-semibold">Chemie im Detail &rarr;</span></div>
</a>
<a href="/de/leistungen/hr-agent/payroll-decision-layer/aviation/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors">
<div class="flex items-center justify-between mb-4"><h3 class="text-h3 font-bold text-white">Aviation</h3><div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div></div>
<ul class="space-y-1.5 text-small text-gosign-text-on-dark/70"><li>3 Gewerkschaften, 14-18 separate Tarifverträge</li><li>EASA FTL: 900h-Cap, Duty-Period-Limits</li><li>180+ Länder-Per-Diem-Sätze (BMF)</li><li>Cockpit-Seniorität bis Stufe 23</li></ul>
<div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between"><span class="text-h3 font-bold text-gosign-accent-on-dark">82% vollautomatisch</span><span class="text-small text-gosign-accent-on-dark font-semibold">Aviation im Detail &rarr;</span></div>
</a>
<a href="/de/leistungen/hr-agent/payroll-decision-layer/finanzwesen/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors">
<div class="flex items-center justify-between mb-4"><h3 class="text-h3 font-bold text-white">Finanzwesen</h3><div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-white/20"></span></div></div>
<ul class="space-y-1.5 text-small text-gosign-text-on-dark/70"><li>5 parallele Vergütungsregime (Tarif bis Risk Taker)</li><li>InstitutsVergV: Bonus-Deferral 40-60% über 4-5 Jahre</li><li>Malus/Clawback: 5-7 Jahre Rückforderung</li><li>MaRisk BTO 2.2: Pflicht-Urlaubsblöcke für Trader</li></ul>
<div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between"><span class="text-h3 font-bold text-gosign-accent-on-dark">85% vollautomatisch</span><span class="text-small text-gosign-accent-on-dark font-semibold">Finanzwesen im Detail &rarr;</span></div>
</a>
<a href="/de/leistungen/hr-agent/payroll-decision-layer/handel/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors">
<div class="flex items-center justify-between mb-4"><h3 class="text-h3 font-bold text-white">Handel</h3><div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-white/20"></span></div></div>
<ul class="space-y-1.5 text-small text-gosign-text-on-dark/70"><li>16 Bundesländer x 6 Gruppen x 6 Stufen = 576 Sätze</li><li>64% Teilzeit, Mini-Job/Midijob-Gleitzone</li><li>100.000 Saisonkräfte, 25,7% Fluktuation</li><li>Zuschlagskumulierung: nur höchster, Nacht additiv</li></ul>
<div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between"><span class="text-h3 font-bold text-gosign-accent-on-dark">92% vollautomatisch</span><span class="text-small text-gosign-accent-on-dark font-semibold">Handel im Detail &rarr;</span></div>
</a>
</div>
</div>
</section>

<!-- Architektur, Implementierung & Hebel -->
<section id="implementation" class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Implementierung</p>
<h2 class="text-h1 font-bold text-gosign-dark">Vom Piloten zum laufenden System.</h2>
<div class="grid grid-cols-1 lg:grid-cols-2 gap-10 mt-10">
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Technische Architektur</h3>
<p class="text-body text-gosign-text">Der Payroll Decision Layer läuft vollständig in Ihrer Infrastruktur: Ihr Rechenzentrum, Ihr Netzwerk, Ihre Hoheit. Keine SaaS-Abhängigkeit, keine Datenabflüsse, kein externes Telemetrie-Tracking. Containerisiert, mandantenfähig, deployment-fertig für Ihre Private Cloud oder als Managed Deployment in EU-Rechenzentren.</p>
<div class="flex flex-wrap gap-4 mt-3">
<a href="/de/leistungen/infrastruktur/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infrastruktur im Detail &rarr;</a>
<a href="/de/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Decision Layer Architektur &rarr;</a>
<a href="/de/magazin/entscheidungsakt-anfechtbare-ki-entscheidungen/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Der Entscheidungsakt &rarr;</a>
<a href="/de/leistungen/travel-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Travel Decision Layer &rarr;</a>
</div>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Implementierung</h3>
<p class="text-body text-gosign-text">Der Decision Layer wird nicht installiert, sondern konfiguriert: Ihre Tarifverträge, Ihre Zuschlagsregeln, Ihre Systemlandschaft. Typische Pilotprojekte starten innerhalb von 3 Monaten mit einer Personalgruppe und einem Tarifvertrag. Erweiterungen auf weitere Personalgruppen oder Gesellschaften laufen parallel zum Pilotbetrieb.</p>
</div>
</div>
<h3 class="text-h3 font-bold text-gosign-dark mt-12 mb-6">Ökonomischer Hebel</h3>
<div class="grid grid-cols-1 sm:grid-cols-2 gap-6">
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-4"><svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12l2 2 4-4m5.618-4.016A11.955 11.955 0 0112 2.944a11.955 11.955 0 01-8.618 3.04A12.02 12.02 0 003 9c0 5.591 3.824 10.29 9 11.622 5.176-1.332 9-6.03 9-11.622 0-1.042-.133-2.052-.382-3.016z" /></svg><div><p class="text-body font-semibold text-gosign-dark">Korrekturbuchungen eliminieren, bevor sie entstehen</p><p class="text-small text-gosign-text-light mt-2">Jede Abrechnung durchläuft dasselbe Regelwerk. Die 1-8% Fehlerquote (APA) entsteht durch manuelle Regelauslegung. Der Decision Layer wendet Regeln konsistent an - über alle Tarifgebiete, alle Personalgruppen, jeden Monat gleich.</p></div></div>
</div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-4"><svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M13 10V3L4 14h7v7l9-11h-7z" /></svg><div><p class="text-body font-semibold text-gosign-dark">Tarifwechsel in Stunden statt Wochen</p><p class="text-small text-gosign-text-light mt-2">Neue Tariftabelle deployen, Gültigkeitszeitraum setzen, rückwirkende Neuberechnung automatisch. Kein manuelles Update in 13 Tarifbezirken. Keine vergessenen Standorte.</p></div></div>
</div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-4"><svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M12 6v6h4.5m4.5 0a9 9 0 11-18 0 9 9 0 0118 0z" /></svg><div><p class="text-body font-semibold text-gosign-dark">82-92% vollautomatisch. Mensch nur wo rechtlich nötig.</p><p class="text-small text-gosign-text-light mt-2">Der AI Agent kann jede Abrechnung besser verarbeiten als ein Sachbearbeiter. Menschliche Eingriffe bleiben dort, wo Betriebsrat, Arbeitsrecht oder Diskriminierungsrisiko sie verlangen - nicht aus fachlichen Gründen.</p></div></div>
</div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-4"><svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12h6m-6 4h6m2 5H7a2 2 0 01-2-2V5a2 2 0 012-2h5.586a1 1 0 01.707.293l5.414 5.414a1 1 0 01.293.707V19a2 2 0 01-2 2z" /></svg><div><p class="text-body font-semibold text-gosign-dark">Lohnsteuer-Außenprüfung ist ein Export, kein Projekt</p><p class="text-small text-gosign-text-light mt-2">Versiegelte Entscheidungsakten pro Abrechnung. Welche Regel, welcher Input, welches Ergebnis. Wochen der Vorbereitung werden Minuten.</p></div></div>
</div>
</div>
</div>
</section>

<!-- Compliance & Security -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Sicherheit</p>
<h2 class="text-h1 font-bold text-gosign-dark">Enterprise-Security. Von Tag eins.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Entgeltdaten gehören zu den sensibelsten Daten im Unternehmen. Der Payroll Decision Layer ist für regulierte Umgebungen konzipiert, in denen Datenschutz, Audit-Readiness und Nachvollziehbarkeit keine optionalen Extras sind.</p>
<div class="mt-10 grid grid-cols-1 sm:grid-cols-3 gap-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">100% Kunden-Infrastruktur</h3><p class="text-small text-gosign-text-light mt-2">Der Decision Layer läuft vollständig in Ihrem Netzwerk. Keine SaaS-Abhängigkeit, kein Datenabfluss, kein externes Telemetrie-Tracking. Entgeltdaten verlassen Ihr Netzwerk nicht.</p></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">DSGVO by Design</h3><p class="text-small text-gosign-text-light mt-2">Anonymisierung statt Löschung. Kompatibel mit steuerlichen Aufbewahrungsfristen (10 Jahre, AO § 147) und DSGVO Art. 17. Kein Widerspruch zwischen Steuerrecht und Datenschutz.</p><a href="/de/governance/data-residency/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Datenresidenz im Detail</a></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">AI Act-konform</h3><p class="text-small text-gosign-text-light mt-2">Klare Architektur-Trennung: Der AI Agent klassifiziert und erkennt Muster. Die Berechnung von Gehältern, Zuschlägen und Steuern läuft deterministisch durch Regelwerke. Keine Black Box bei Beträgen, volle Nachvollziehbarkeit bei der Klassifikation.</p><a href="/de/governance/eu-ai-act/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">EU AI Act Readiness</a></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">Audit Trail (append-only)</h3><p class="text-small text-gosign-text-light mt-2">Signierte Entscheidungsakten. Input-Hash plus Regelversion ergibt reproduzierbares Ergebnis. Versiegelte Audit-Pakete (JSON + PDF, SHA-256). Betriebsprüfung jederzeit.</p></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">ISO 27001 / PS 951 cert-ready</h3><p class="text-small text-gosign-text-light mt-2">Integrierte Controls Registry, automatisierte Evidence Runs, versionierte Policies. Compliance im laufenden Betrieb, nicht nachträglich dokumentiert.</p><a href="/de/governance/cert-ready/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready by Design</a></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">SSO & Mandantentrennung</h3><p class="text-small text-gosign-text-light mt-2">Integration in bestehende Identity Provider. Mandantentrennung auf Datenbankebene (Row Level Security). Rollenmodell granular konfigurierbar. Gesellschaften sauber getrennt.</p></div>
</div>
</div>
</section>


<!-- Weitere Agent-Lösungen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Weitere Agent-Lösungen</h2>
<p class="text-body-lg text-gosign-text-light mt-4">HR Agents sind Teil unseres Agent-Portfolios. Für Finance und andere Bereiche bieten wir spezialisierte Lösungen.</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8 max-w-content">
<a href="/de/hr-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR & People Operations</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Alle HR Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Betriebsratsfähig.</p>
</a>
<a href="/de/finance-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Finance & Accounting</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Finance AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Belegverarbeitung, Kontierung, AfA-Logik, Korrekturbuchungen. DATEV- und SAP-Integration.</p>
</a>
<a href="/de/kontakt/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Individuell</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Co-Build für Ihren Prozess</h3>
<p class="text-body text-gosign-text-light mt-2">Compliance, Operations, Shared Services - wir entwickeln Agenten im Co-Build.</p>
</a>
</div>
</div>
</section>

<!-- Dieser Agent im Katalog -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark">Wann starten? Priorisierung und Governance-Readiness</h2>
<p class="text-body text-gosign-text mt-4">In welchem Quartal sollte dieser Agent starten? Welche Governance-Infrastruktur muss vorher stehen? Welche Agenten sind Voraussetzung? Der HR-Agent-Katalog ordnet diesen Agenten in die Q1-Q4 Sequenzierung ein und zeigt Readiness-Scores, Governance-Komplexität und Abhängigkeiten zu anderen Agenten.</p>
<a href="/de/hr-agent-katalog/payroll-processing-agent/" class="inline-flex items-center gap-2 mt-4 text-body font-semibold text-gosign-accent hover:underline">Sequenzierung und Scores ansehen &rarr;</a>
</div>
</section>

<!-- Vertiefung -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Vertiefung im Agent Briefing (Gosign Magazin)</h2>
<p class="text-body text-gosign-text-light mb-6">Unsere Fachartikel-Serie für Entscheider, die AI Agents im Unternehmen einführen.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/de/magazin/decision-layer-payroll/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Finance</p>
<p class="text-body font-semibold text-gosign-dark">Payroll-Fehler strukturell eliminieren - Decision Layer für Finance</p>
</a>
<a href="/de/magazin/betriebsrat-ki-mitbestimmung/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Mitbestimmung</p>
<p class="text-body font-semibold text-gosign-dark">Betriebsrat und KI - Mitbestimmung als Architektur-Constraint</p>
</a>
<a href="/de/magazin/decision-layer-erklaert/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Grundlagen</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - Was ist das und warum braucht jeder Enterprise AI Agent einen?</p>
</a>
</div>
</div>
</section>

--- AI Infrastructure Engineering ---
> LLM Hosting, RAG-Pipeline, Orchestrierung und Deployment. Modell-agnostisch, Self-Hosted oder Cloud. Produktionsplattform für AI-Agenten.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/de/warum-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Jede Entscheidung nachvollziehbar</p>
</div>
</a>
<a href="/de/warum-gosign/#infrastruktur" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Ihre Infrastruktur</p>
<p class="text-xs text-gosign-text-light">Kein SaaS. Kein Vendor-Lock-in.</p>
</div>
</a>
<a href="/de/warum-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Kein US-Cloud-Risiko</p>
</div>
</a>
</div>
</div>
</div>

<!-- Warum Infrastruktur der Engpass ist -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Warum Infrastruktur der Engpass ist</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Die meisten Unternehmen die AI-Agenten pilotieren, scheitern nicht am Modell. Die Modelle funktionieren. Sie scheitern an der Infrastruktur: Kein Governance-Framework, kein Audit Trail, keine Mandantentrennung, kein Deployment-Konzept, keine Integration in bestehende Systeme.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Ein Pilot auf einem Notebook ist keine Produktivarchitektur. Diese Seite beschreibt die konkreten Technologien und Konfigurationen, die aus einem LLM-Experiment ein betriebsfähiges System machen.
</p>
<p class="text-body text-gosign-text-light mt-4">
Wie die einzelnen Infrastruktur-Komponenten architektonisch zusammenspielen, beschreibt die <a href="/de/governance/referenz-architektur/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">7-Layer-Referenz-Architektur</a>.
</p>
</div>
</div>
</section>

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Kostenloses eBook: AI Infrastructure</p>
<p class="text-body text-gosign-text mb-4">Build, Buy, Hybrid - EU AI Act-konforme Infrastruktur mit B/B/H-Framework und 7-Layer Reference Architecture.</p>
<a href="/de/ebook/ki-infrastructure-governance-handbuch/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Jetzt kostenlos herunterladen</a>
</div>

<!-- 1. LLM Hosting -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Vier Infrastruktur-Komponenten</h2>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">1. LLM Hosting</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Die Modellschicht. Wo das Sprachverständnis stattfindet.
</p>
<p class="text-body-lg text-gosign-text-light mt-4"><strong>Cloud-LLMs:</strong></p>
<ul class="mt-2 space-y-2">
<li class="text-body-lg text-gosign-text-light">Azure OpenAI (ChatGPT, Claude) - EU-Regionen, Microsofts DPA</li>
<li class="text-body-lg text-gosign-text-light">Amazon Bedrock (Claude, Llama, Mistral) - EU-Regionen, AWS DPA</li>
<li class="text-body-lg text-gosign-text-light">Google Vertex AI (Gemini) - EU-Regionen, Googles DPA</li>
<li class="text-body-lg text-gosign-text-light">Anthropic API (Claude) - mit EU Data Processing</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-4"><strong>Self-Hosted-LLMs:</strong></p>
<ul class="mt-2 space-y-2">
<li class="text-body-lg text-gosign-text-light">Llama (Meta) - Open Source, auf eigener Hardware</li>
<li class="text-body-lg text-gosign-text-light">Mistral - Open Source, EU-Unternehmen</li>
<li class="text-body-lg text-gosign-text-light">DeepSeek - Open Source, kosteneffizient</li>
<li class="text-body-lg text-gosign-text-light"><a href="https://openai.com/open-models/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">gpt-oss</a> (OpenAI) - Open Weight, Apache 2.0, komplett self-hostbar. 120B auf einer H100, 20B auf 16 GB Consumer-Hardware.</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-4"><strong>Inference-Frameworks für Self-Hosted:</strong></p>
<ul class="mt-2 space-y-2">
<li class="text-body-lg text-gosign-text-light"><a href="https://ollama.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Ollama</a> - Einfacher Einstieg, lokale Entwicklung, Edge-Deployment</li>
<li class="text-body-lg text-gosign-text-light"><a href="https://docs.vllm.ai/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">vLLM</a> - Production-grade, GPU-optimiert, hoher Throughput</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-4"><strong>Hybrid:</strong></p>
<ul class="mt-2 space-y-2">
<li class="text-body-lg text-gosign-text-light">Self-Hosted für sensible Daten (HR, Finanzen)</li>
<li class="text-body-lg text-gosign-text-light">Cloud-LLMs für weniger kritische Workloads (Dokumentenklassifikation)</li>
<li class="text-body-lg text-gosign-text-light">Automatisches Routing je nach Datenklassifikation</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-4">
Die Modellwahl ist eine Abwägung zwischen Leistung, Kosten, Datenschutz und Latenz. Wir beraten bei der Auswahl und implementieren modell-agnostisch - ein Modellwechsel ändert nicht die Geschäftslogik. Vertiefung: <a href="/de/magazin/ki-modelle-vergleich-2026/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">KI-Modelle im Vergleich 2026</a>, <a href="/de/magazin/llm-self-hosting-enterprise/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">LLM Self-Hosting für Enterprise</a>
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Unsere AI Engineers sind Microsoft-zertifiziert für Azure AI Services. Deployment-Optionen umfassen <a href="https://azure.microsoft.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Microsoft Azure</a>, <a href="https://cloud.google.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">GCP</a> und komplett selbst gehostete Infrastruktur - die Architekturentscheidung liegt beim Kunden, nicht beim Anbieter.
</p>
</div>
</div>
</section>

<!-- 2. RAG-Pipeline -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h3 class="text-h3 font-bold text-gosign-dark">2. RAG-Pipeline</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Retrieval Augmented Generation - wie Agenten auf Unternehmenswissen zugreifen.
</p>
</div>
<img src="/images/diagrams/rag-pipeline-de.svg" alt="RAG-Pipeline: Dokumente werden in Chunks zerlegt, als Embeddings im Vector Store gespeichert, bei Anfragen semantisch abgerufen und dem LLM als Kontext übergeben" class="w-full mt-6" width="1200" height="400" loading="lazy" />
<div class="max-w-narrow mt-6">
<p class="text-body-lg text-gosign-text-light"><strong>Qualitätsmerkmale:</strong></p>
<ul class="mt-2 space-y-2">
<li class="text-body-lg text-gosign-text-light">Semantisches Chunking (nicht nach Seitenzahl, sondern nach Inhalt)</li>
<li class="text-body-lg text-gosign-text-light">Metadaten-Anreicherung (Dokumenttyp, Version, Gültigkeitsbereich)</li>
<li class="text-body-lg text-gosign-text-light">Hybrid Search (Vektorsuche + Keyword-Suche für Präzision)</li>
<li class="text-body-lg text-gosign-text-light">Quellenangabe in jeder Antwort (Dokument, Seite, Absatz)</li>
<li class="text-body-lg text-gosign-text-light">Regelmässige Re-Indexierung bei Dokumentenänderungen</li>
</ul>
</div>
</div>
</section>

<!-- 3. Orchestrierung -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h3 class="text-h3 font-bold text-gosign-dark">3. Orchestrierung</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Die Ablaufsteuerung. Wie Agenten, Systeme und Menschen zusammenarbeiten.
</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light"><strong><a href="https://trigger.dev" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Trigger.dev</a> oder <a href="https://camunda.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Camunda</a>:</strong> Open-Source Workflow-Engine. Visuelle Workflows, API-Integration, Webhooks. Self-Hosted, kein Vendor Lock-in.</li>
<li class="text-body-lg text-gosign-text-light"><strong>API Gateway:</strong> Einheitlicher Einstiegspunkt. Rate Limiting, Authentication, Logging, Monitoring.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Queue-System:</strong> Asynchrone Verarbeitung für Batch-Prozesse (Monatsabschluss, Massenimport).</li>
<li class="text-body-lg text-gosign-text-light"><strong>Event-System:</strong> Echtzeit-Reaktion auf eingehende Dokumente, Statusänderungen, Eskalationen.</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-4">
Die Orchestrierung ist der Unterschied zwischen "ein Agent kann etwas" und "ein Agent tut etwas zuverlässig im Produktivbetrieb". Mehr dazu: <a href="/de/magazin/agent-orchestrierung-plattformen/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Agent-Orchestrierung im Vergleich</a>
</p>
</div>
</div>
</section>

<!-- 4. Deployment -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h3 class="text-h3 font-bold text-gosign-dark">4. Deployment</h3>
<p class="text-body-lg text-gosign-text-light mt-4">Wo die Infrastruktur läuft. Alle Optionen EU-only.</p>

<h4 class="text-body-lg font-bold text-gosign-dark mt-6">Azure (EU)</h4>
<ul class="mt-2 space-y-1">
<li class="text-body text-gosign-text-light">Azure Kubernetes Service (AKS) für Container-Orchestrierung</li>
<li class="text-body text-gosign-text-light">Azure SQL / PostgreSQL für Daten und Audit Trail</li>
<li class="text-body text-gosign-text-light">Azure OpenAI für LLM-Hosting</li>
<li class="text-body text-gosign-text-light">Regionen: West Europe, North Europe, Germany West Central</li>
</ul>

<h4 class="text-body-lg font-bold text-gosign-dark mt-6">AWS (EU)</h4>
<ul class="mt-2 space-y-1">
<li class="text-body text-gosign-text-light">Amazon EKS für Container-Orchestrierung</li>
<li class="text-body text-gosign-text-light">Amazon RDS / Aurora PostgreSQL für Daten und Audit Trail</li>
<li class="text-body text-gosign-text-light">Amazon Bedrock für LLM-Hosting (Claude, Llama, Mistral)</li>
<li class="text-body text-gosign-text-light">Regionen: eu-central-1 (Frankfurt), eu-west-1 (Ireland), eu-west-3 (Paris)</li>
</ul>

<h4 class="text-body-lg font-bold text-gosign-dark mt-6">GCP (EU)</h4>
<ul class="mt-2 space-y-1">
<li class="text-body text-gosign-text-light">Google Kubernetes Engine (GKE) für Container-Orchestrierung</li>
<li class="text-body text-gosign-text-light">Cloud SQL / AlloyDB für Daten und Audit Trail</li>
<li class="text-body text-gosign-text-light">Vertex AI für LLM-Hosting</li>
<li class="text-body text-gosign-text-light">Regionen: europe-west1, europe-west3, europe-west4</li>
</ul>

<h4 class="text-body-lg font-bold text-gosign-dark mt-6">Vercel EU + Supabase EU</h4>
<ul class="mt-2 space-y-1">
<li class="text-body text-gosign-text-light">Vercel für Frontend und Edge Functions in EU-Rechenzentren</li>
<li class="text-body text-gosign-text-light">Supabase für Datenbank (PostgreSQL), Auth und Storage</li>
<li class="text-body text-gosign-text-light">Leichtgewichtige EU-Deployment-Option ohne eigene Kubernetes-Infrastruktur</li>
<li class="text-body text-gosign-text-light">Managed Services mit EU Data Residency</li>
</ul>

<h4 class="text-body-lg font-bold text-gosign-dark mt-6">Self-Hosted</h4>
<ul class="mt-2 space-y-1">
<li class="text-body text-gosign-text-light"><a href="https://www.docker.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Docker</a> / <a href="https://kubernetes.io/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Kubernetes</a> auf eigener Hardware</li>
<li class="text-body text-gosign-text-light"><a href="https://www.postgresql.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">PostgreSQL</a> mit <a href="https://github.com/pgvector/pgvector" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">pgvector</a> für Daten und Vektorsuche</li>
<li class="text-body text-gosign-text-light">Open-Source-LLMs auf eigenen GPUs</li>
<li class="text-body text-gosign-text-light">Vollständige Cloud-Act-Freiheit</li>
</ul>

<h4 class="text-body-lg font-bold text-gosign-dark mt-6">Hybrid</h4>
<ul class="mt-2 space-y-1">
<li class="text-body text-gosign-text-light">Kombination nach Datenklassifikation</li>
<li class="text-body text-gosign-text-light">Sensitive Workloads Self-Hosted, Standard-Workloads Cloud</li>
<li class="text-body text-gosign-text-light">Einheitliche Orchestrierung über alle Umgebungen</li>
</ul>
</div>
</div>
</section>

<!-- Technologie-Stack -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Technologie-Stack</h2>
<div class="mt-8 overflow-x-auto">
<table class="w-full text-left text-small border-collapse">
<thead>
<tr>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Komponente</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Technologie</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Warum</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Workflow-Engine</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://trigger.dev" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Trigger.dev</a>, <a href="https://camunda.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Camunda</a></td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Open Source, Self-Hosted, kein Vendor Lock-in</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Datenbank</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://www.postgresql.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">PostgreSQL</a> + <a href="https://github.com/pgvector/pgvector" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">pgvector</a></td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Enterprise-ready, RLS-fähig, Vektorsuche integriert</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Backend</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://www.python.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Python</a>, <a href="https://www.typescriptlang.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">TypeScript</a></td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Bewährt für ML-Workloads und API-Entwicklung</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Frontend</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://react.dev/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">React</a> / <a href="https://nextjs.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Next.js</a></td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Für Dashboard, Chat UI, Auditor Portal</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Container</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://www.docker.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Docker</a>, <a href="https://kubernetes.io/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Kubernetes</a></td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Standard für Cloud und Self-Hosted</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">API</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">REST, <a href="https://graphql.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">GraphQL</a></td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Integration mit bestehenden Systemen</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Auth</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://supabase.com/auth" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Supabase Auth</a> / OIDC</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">SSO-fähig, integrierbar mit Enterprise-Identity-Providern</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Monitoring</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://prometheus.io/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Prometheus</a>, <a href="https://grafana.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Grafana</a></td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Open Source, Self-Hosted, Echtzeit-Dashboards</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Inference</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://ollama.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Ollama</a>, <a href="https://docs.vllm.ai/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">vLLM</a></td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Self-Hosted LLM Inference, GPU-optimiert</td></tr>
</tbody>
</table>
</div>
</div>
</div>
</section>

<!-- Governance ist eingebaut -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Governance ist eingebaut</h2>
<p class="text-body-lg text-gosign-text-light mt-4">Die Infrastruktur enthält Governance by Design:</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light"><strong>Audit Trail</strong> auf Infrastrukturebene (nicht nur Anwendungsebene)</li>
<li class="text-body-lg text-gosign-text-light"><strong>Row-Level Security</strong> auf Datenbankebene - Details in <a href="/de/governance/data-residency/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Data Residency</a></li>
<li class="text-body-lg text-gosign-text-light"><strong>Verschlüsselung</strong> at rest und in transit</li>
<li class="text-body-lg text-gosign-text-light"><strong>RBAC</strong> über alle Komponenten hinweg</li>
<li class="text-body-lg text-gosign-text-light"><strong><a href="/de/governance/cert-ready/" class="text-gosign-dark hover:text-gosign-accent-text transition-colors">Cert-Ready</a> Controls</strong> als technische Datenobjekte</li>
</ul>
<p class="mt-4">
<a href="/de/governance/referenz-architektur/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Governance in der 7-Layer-Architektur -></a>
</p>
</div>
</div>
</section>

<!-- Quellcode-Zugang -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Voller Quellcode-Zugang</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Die Infrastruktur läuft beim Kunden - in Azure, GCP, AWS oder Self-Hosted. Kein SaaS, kein Hosting bei Gosign. Voller Zugang zu Quellcode, Konfigurationen und Regelwerken. Open-Source-Stack wo möglich. Proprietäre Komponenten nur bei den LLMs selbst - und dort modell-agnostisch.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Nach 12-18 Monaten betreiben Sie die Infrastruktur eigenständig.
</p>
</div>
</div>
</section>

<!-- Vertiefung -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Vertiefung im Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Unsere Fachartikel-Serie für Entscheider, die AI Agents im Unternehmen einführen.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/de/magazin/ai-infrastruktur-blueprint-2026/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">Enterprise AI-Infrastruktur Blueprint 2026</p>
</a>
<a href="/de/magazin/ki-hosting-strategien-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">KI-Hosting: EU-SaaS, deutsches RZ oder Self-Hosted?</p>
</a>
<a href="/de/magazin/llm-self-hosting-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">LLM Self-Hosting für Enterprise - Azure, GCP, On-Premise</p>
</a>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark mb-6">Vertiefung</h2>
<div class="grid gap-6 sm:grid-cols-2">
<div class="border-l-4 border-gosign-dark pl-6 py-4">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Architektur</p>
<h3 class="text-h3 font-bold text-gosign-dark">7-Layer-Referenz-Architektur</h3>
<p class="text-body text-gosign-text-light mt-2">Wie die Infrastruktur-Komponenten architektonisch zusammenspielen - sieben entkoppelte Layer mit Governance als Querschicht.</p>
<a href="/de/governance/referenz-architektur/" class="text-small font-semibold text-gosign-accent-text hover:text-gosign-accent-hover mt-3 inline-block whitespace-nowrap">Zur Referenz-Architektur -></a>
</div>
<div class="border-l-4 border-gosign-dark pl-6 py-4">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Wissensressource</p>
<h3 class="text-h3 font-bold text-gosign-dark">Blueprint 2026</h3>
<p class="text-body text-gosign-text-light mt-2">Elf Fachartikel zu den Infrastruktur-Entscheidungen die 2026 zählen: KI-Modelle, Hosting, RAG, Orchestrierung, Kosten.</p>
<a href="/de/magazin/ai-infrastruktur-blueprint-2026/" class="text-small font-semibold text-gosign-accent-text hover:text-gosign-accent-hover mt-3 inline-block whitespace-nowrap">Zur Artikelserie -></a>
</div>
<div class="border-l-4 border-gosign-dark pl-6 py-4">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Compliance</p>
<h3 class="text-h3 font-bold text-gosign-dark">Data Residency</h3>
<p class="text-body text-gosign-text-light mt-2">EU-only Verarbeitung, Row-Level Security, Mandantentrennung, keine Drittanbieter-Datenflüsse.</p>
<a href="/de/governance/data-residency/" class="text-small font-semibold text-gosign-accent-text hover:text-gosign-accent-hover mt-3 inline-block whitespace-nowrap">Zu Data Residency -></a>
</div>
<div class="border-l-4 border-gosign-dark pl-6 py-4">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Agenten</p>
<h3 class="text-h3 font-bold text-gosign-dark">AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Document Agents, Workflow Agents, Knowledge Agents - die Agenten die auf dieser Infrastruktur laufen.</p>
<a href="/de/leistungen/ai-agents/" class="text-small font-semibold text-gosign-accent-text hover:text-gosign-accent-hover mt-3 inline-block whitespace-nowrap">Zu den AI Agents -></a>
</div>
</div>
</div>
</div>
</section>

--- Enterprise Software Engineering seit 2001 ---
> Über 5.000 Projekte für Airbus, Volkswagen, Shell. 25 Jahre Enterprise-Engineering als Fundament für AI-Infrastruktur.

<!-- 25 Jahre -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">25 Jahre Enterprise-Softwareentwicklung</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Gosign entwickelt seit 2001 Software für Enterprise-Kunden. Über 5.000 Projekte für <a href="/de/referenzen/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Airbus, Volkswagen, Shell und andere</a> - komplexe, mehrsprachige Enterprise-Plattformen mit Anforderungen an Sicherheit, Skalierbarkeit und Wartbarkeit.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Dieses Fundament ist der Grund, warum Gosign heute <a href="/de/leistungen/ai-agents/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">AI-Infrastruktur</a> baut. Nicht als Startup das seit zwei Jahren existiert, sondern als Unternehmen mit 25 Jahren Engineering-Erfahrung in Enterprise-Umgebungen.
</p>
</div>
</section>

<!-- Was wir heute bauen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">Was wir heute bauen</h2>
<div class="grid grid-cols-1 md:grid-cols-2 gap-6 lg:gap-8">
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M13.19 8.688a4.5 4.5 0 0 1 1.242 7.244l-4.5 4.5a4.5 4.5 0 0 1-6.364-6.364l1.757-1.757m9.864-9.864a4.5 4.5 0 0 0-6.364 6.364l4.5 4.5a4.5 4.5 0 0 0 7.244 1.242" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Custom Integrations</h3>
<p class="text-body text-gosign-text-light mt-3">Anbindung von AI-Agenten an bestehende Enterprise-Systeme. SAP, DATEV, SuccessFactors, Workday, Microsoft Graph - über REST, SOAP, RFC oder proprietäre Schnittstellen. Die Integration ist der Punkt an dem die meisten AI-Projekte scheitern. Wir haben ihn tausendmal gelöst.</p>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M14.25 9.75 16.5 12l-2.25 2.25m-4.5 0L7.5 12l2.25-2.25M6 20.25h12A2.25 2.25 0 0 0 20.25 18V6A2.25 2.25 0 0 0 18 3.75H6A2.25 2.25 0 0 0 3.75 6v12A2.25 2.25 0 0 0 6 20.25Z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">API-Entwicklung</h3>
<p class="text-body text-gosign-text-light mt-3">Maschinenlesbare Schnittstellen für Agenten, Dashboards und Drittsysteme. REST und GraphQL. Authentifizierung, Rate Limiting, Versionierung, Dokumentation.</p>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="m21 7.5-9-5.25L3 7.5m18 0-9 5.25m9-5.25v9l-9 5.25M3 7.5l9 5.25M3 7.5v9l9 5.25m0-9v9" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">System-Architektur</h3>
<p class="text-body text-gosign-text-light mt-3">Architektur-Design für AI-Agenten-Plattformen. Datenmodell, Deployment-Strategie, Skalierungskonzept, Sicherheitsarchitektur. Die Architektur entscheidet ob ein System in zwei Jahren noch wartbar ist.</p>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 17.25v1.007a3 3 0 0 1-.879 2.122L7.5 21h9l-.621-.621A3 3 0 0 1 15 18.257V17.25m6-12V15a2.25 2.25 0 0 1-2.25 2.25H5.25A2.25 2.25 0 0 1 3 15V5.25m18 0A2.25 2.25 0 0 0 18.75 3H5.25A2.25 2.25 0 0 0 3 5.25m18 0V12a2.25 2.25 0 0 1-2.25 2.25H5.25A2.25 2.25 0 0 1 3 12V5.25" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Enterprise-Plattformen</h3>
<p class="text-body text-gosign-text-light mt-3">Webbasierte Plattformen für interne Nutzer: Dashboards, Auditor Portale, Chat-Interfaces, Workflow-Tools. Responsive, barrierearm, performant.</p>
</article>
</div>
</div>
</section>

<!-- Engineering-Prinzipien -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Engineering-Prinzipien</h2>
<div class="mt-6 space-y-6">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Test-Driven Development (TDD) & kontinuierliches Pair Programming</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Jede Zeile Code entsteht im Pair Programming. Testgetrieben (TDD), versioniert, review-pflichtig. Keine Einzelkämpfer, kein Knowledge-Silo. Tests werden vor dem Code geschrieben. Jede Funktion hat Tests. Jeder Merge erfordert grüne Tests.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Continuous Integration / Continuous Deployment (CI/CD)</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Automatisierte Build-Pipeline, automatisierte Tests, automatisiertes Deployment. Jeder Push wird getestet. Jeder Merge wird deployt.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Code Review</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Jeder Merge Request wird von mindestens einem weiteren Entwickler geprüft. Vier-Augen-Prinzip für alle produktiven Änderungen.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Security by Design</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Sicherheit ist kein nachträglicher Layer. RBAC, Verschlüsselung, Input-Validierung, Output-Encoding - ab Tag 1.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Audit Trail</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Jede Änderung an Konfiguration, Regelwerken und Systemzustand wird dokumentiert. Wer hat was wann geändert - nachvollziehbar und unveränderlich.</p>
</div>
</div>
</div>
</section>

<!-- Technologie-Stack -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Technologie-Stack</h2>
<div class="mt-8 overflow-x-auto">
<table class="w-full text-left text-small border-collapse">
<thead>
<tr>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Bereich</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Technologien</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Backend</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://www.python.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Python</a>, <a href="https://www.typescriptlang.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">TypeScript</a>, Node.js</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Frontend</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://react.dev/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">React</a>, <a href="https://nextjs.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Next.js</a></td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Datenbank</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://www.postgresql.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">PostgreSQL</a>, Supabase</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Workflow</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://trigger.dev" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Trigger.dev</a>, <a href="https://n8n.io/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">n8n</a>, <a href="https://camunda.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Camunda</a></td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Container</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://www.docker.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Docker</a>, <a href="https://kubernetes.io/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Kubernetes</a></td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">CI/CD</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://github.com/features/actions" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">GitHub Actions</a>, <a href="https://docs.gitlab.com/ee/ci/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">GitLab CI</a></td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Monitoring</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://prometheus.io/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Prometheus</a>, <a href="https://grafana.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Grafana</a></td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Auth</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://supabase.com/auth" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Supabase Auth</a>, OIDC</td></tr>
</tbody>
</table>
</div>
<p class="text-body-lg text-gosign-text-light mt-4">
Der Stack richtet sich nach den Anforderungen des Projekts. Wir setzen Open-Source-Technologien ein wo möglich - für Transparenz, Unabhängigkeit und Kosteneffizienz.
</p>
</div>
</div>
</section>

<!-- Vom Software Engineering zur AI-Infrastruktur -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Vom Software Engineering zur AI-Infrastruktur</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Die Engineering-Prinzipien die für Enterprise-Softwareentwicklung gelten, gelten auch für AI-Infrastruktur. Ein AI-Agent der in Produktion läuft, braucht dieselbe Disziplin wie jede andere Enterprise-Software: Tests, Deployment-Pipelines, Monitoring, Audit Trail, Security.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Der Unterschied: Ein AI-Agent trifft fachliche Entscheidungen die dokumentiert und nachvollziehbar sein müssen. Das erfordert zusätzliche Architekturkomponenten - den <a href="/de/decision-layer/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Decision Layer</a>, Governance by Design, <a href="/de/governance/cert-ready/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Cert-Ready Controls</a>. Aber das Fundament ist Software Engineering.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
25 Jahre dieses Fundaments sind der Grund, warum unsere <a href="/de/leistungen/infrastruktur/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">AI-Infrastruktur</a> funktioniert.
</p>
</div>
</section>

<!-- Vertiefung -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Vertiefung im Agent Briefing (Gosign Magazin)</h2>
<p class="text-body text-gosign-text-light mb-6">Unsere Fachartikel-Serie für Entscheider, die AI Agents im Unternehmen einführen.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/de/magazin/ki-integration-it-landschaft/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">KI-Integration in bestehende IT-Landschaften - SAP, DATEV, Workday</p>
</a>
<a href="/de/magazin/ai-agenten-enterprise-leitfaden/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">AI Agents</p>
<p class="text-body font-semibold text-gosign-dark">Von Chatbots zu AI-Agenten: MCP, A2A und Multi-Agent-Systeme</p>
</a>
<a href="/de/magazin/ai-infrastruktur-blueprint-2026/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">Enterprise AI-Infrastruktur Blueprint 2026</p>
</a>
</div>
</div>
</section>

--- AI Travel Agent Aviation - Crew-Reisekosten ---
> Decision Layer für Crew-Reisekosten. Umlauf-basierte Abrechnung, tarifvertragliche Spesensätze, wechselnde Länderpauschalen. Auditierbar automatisiert.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/de/warum-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Jede Entscheidung nachvollziehbar</p>
</div>
</a>
<a href="/de/warum-gosign/#infrastruktur" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Ihre Infrastruktur</p>
<p class="text-xs text-gosign-text-light">Kein SaaS. Kein Vendor-Lock-in.</p>
</div>
</a>
<a href="/de/warum-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Kein US-Cloud-Risiko</p>
</div>
</a>
</div>
</div>
</div>

<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Travel Decision Layer Branchen">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/de/leistungen/travel-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Travel Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/de/leistungen/travel-decision-layer/aviation/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Aviation</a>
<a href="/de/leistungen/travel-decision-layer/beratung/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Beratung</a>
<a href="/de/leistungen/travel-decision-layer/logistik/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Logistik</a>
<a href="/de/leistungen/travel-decision-layer/vertrieb/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Vertrieb</a>
</div>
</div>
</nav>

<!-- Warum Aviation die höchste Komplexität hat -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<!-- Simulationskennzahlen als visuelle Einleitung -->
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">100.000+</span>
<p class="text-small text-gosign-text-light mt-1">Vorgänge/Jahr (Simulation)</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">95%</span>
<p class="text-small text-gosign-text-light mt-1">Automatisierungsquote</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">10 - 20%</span>
<p class="text-small text-gosign-text-light mt-1">IROP-Quote (branchentypisch)</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">Höchste Regelkomplexität</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">Vorgänge und vollautomatisch: Gosign-Simulationsmodell. IROP-Quote: EUROCONTROL / US DOT BTS, 2024.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Was der Agent klassifiziert</p>
<h2 class="text-h1 font-bold text-gosign-dark">Drei Personalgruppen, ein Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Cockpit, Kabine, Boden - jede Gruppe mit eigenem Tarifvertrag, eigenen Per Diems, eigener Komplexität. Sie kennen die Komplexität. So löst der AI Agent sie:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Hunderte Umläufe pro Tag</h3>
<p class="text-body text-gosign-text mt-2">Jeder Umlauf erzeugt einen steuerlichen Sachverhalt. Der AI Agent liest Einsatzpläne automatisch, klassifiziert Personalgruppe und Umlauftyp und ordnet den korrekten Tarifvertrag zu. Bei Hunderten von Umläufen pro Tag erkennt der Agent Standortwechsel und Tarifgrenzen zuverlässiger als jede manuelle Erfassung.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Drei bis fünf Länder pro Diensttag</h3>
<p class="text-body text-gosign-text mt-2">Ein Umlauf berührt mehrere Jurisdiktionen an einem Tag. Der AI Agent klassifiziert Länderzuordnung und Aufenthaltsdauer aus dem Einsatzplan. Das Regelwerk berechnet die länderspezifischen Pauschalen deterministisch - voller oder gekürzter Satz, anteilig nach Aufenthaltszeit. Dieselbe Länderpauschalen-Logik greift auch bei der <a href="/de/leistungen/hr-agent/payroll-decision-layer/aviation/" class="text-gosign-accent-text font-semibold hover:text-gosign-accent-hover transition-colors">Entgeltabrechnung im Payroll Decision Layer</a>.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Tarifvertrags-Override pro Personalgruppe</h3>
<p class="text-body text-gosign-text mt-2">Cockpit, Kabine und Boden haben verschiedene Tarifverträge, die gesetzliche Pauschalen überschreiben. Der AI Agent klassifiziert die Personalgruppe und wählt automatisch das korrekte Tarifwerk. Das Regelwerk berechnet den Override deterministisch. Derselbe Umlauf, drei verschiedene Ergebnisse - konsistent über alle Sachbearbeiter.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">IROP-Volatilität in Echtzeit</h3>
<p class="text-body text-gosign-text mt-2">10-20% aller Umläufe weichen vom Plan ab. Der AI Agent klassifiziert den IROP-Typ (Verspätung, Umleitung, Repositionierung) und ordnet die steuerlichen Auswirkungen zu. Das Regelwerk berechnet die korrigierten Pauschalen auf Basis des tatsächlichen Umlaufs. Der Audit Trail dokumentiert Originalplan und tatsächliche Ausführung.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Volumen-Governance ohne Stichproben</h3>
<p class="text-body text-gosign-text mt-2">Tausende identische Fälle pro Tag. Der AI Agent prüft 100% der Vorgänge gegen dasselbe Regelwerk. Keine Stichproben, keine personenabhängige Variation. Jeder systematische Fehler wird sofort erkannt statt erst bei der Quartalsabstimmung.</p>
</div>
</div>
</div>
</section>

<!-- Decision Flow -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Ein Umlauf. 40 bis 120 Mikro-Entscheidungen.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Ein Crew-Mitglied fliegt einen Drei-Tages-Umlauf mit Layover. Der Decision Layer zerlegt diesen in einzelne Entscheidungsschritte:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Schritt</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Entscheidung</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Entscheider</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Begründung</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Umlauf aus Einsatzplan lesen</td><td class="py-3 px-4">Automatisch</td><td class="py-3 px-4">Datenimport, keine Entscheidung</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Länderfolge bestimmen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">GPS oder Plan: welche Länder, welche Dauer</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Pauschale pro Land wählen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">Länderspezifische Sätze nach BMF</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Tarifvertrags-Override prüfen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">Crew-spezifischer TV überschreibt gesetzliche Sätze</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Mahlzeitenkürzung berechnen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">Gestellte Mahlzeiten kürzen Pauschale deterministisch</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">IROP klassifizieren</td><td class="py-3 px-4">AI</td><td class="py-3 px-4">Verspätung, Umleitung, Repositionierung: AI klassifiziert Typ</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">IROP-Auswirkung neuberechnen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">Geänderte Dauer oder Land: Pauschale neu berechnen</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">Layover-Hotel prüfen</td><td class="py-3 px-4">AI + Regelwerk</td><td class="py-3 px-4">AI extrahiert Hoteldaten, Regelwerk prüft Policy-Konformität</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Kostenstelle zuordnen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">Umlauf zu Flotte, Flotte zu Kostenstelle</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Audit-Akte erzeugen</td><td class="py-3 px-4">Automatisch</td><td class="py-3 px-4">Versiegelte Entscheidungsakte pro Umlauf</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Simulations-Ergebnis -->
<section id="simulation" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulation</p>
<h2 class="text-h1 font-bold text-white">Durchgerechnet für Aviation-Volumina</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Wir haben den Travel Decision Layer mit realistischen Aviation-Parametern konfiguriert und durchgerechnet. Die Ergebnisse zeigen, was sich bei Enterprise-Volumina verändert.</p>

<!-- Parameter-Tabelle -->
<h3 class="text-h3 font-bold text-white mt-10 mb-4">Simulationsparameter</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Crew-Mitglieder</td><td class="py-3 px-4">10.000 bis 50.000+ (mehrere Personalgruppen mit eigenen Tarifverträgen)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Tarifverträge</td><td class="py-3 px-4">2 bis 5 parallele (je Personalgruppe und Carrier)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Vorgänge/Jahr</td><td class="py-3 px-4">100.000 bis 1.000.000+</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Rechtskreise</td><td class="py-3 px-4">Multi-Jurisdiktion (DE, AT, CH, weitere EU-Länder)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Systemintegration</td><td class="py-3 px-4">Crew-Planung &rarr; Decision Layer &rarr; ERP/Payroll</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">IROP-Quote</td><td class="py-3 px-4">10 - 20% aller Umläufe mit Planabweichung (branchentypisch)</td></tr>
</tbody>
</table>
</div>

<!-- Ergebnis-Vergleich -->
<h3 class="text-h3 font-bold text-white mt-10 mb-4">Vorher / Nachher</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th class="text-left py-3 px-4 font-semibold text-white">Dimension</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manuell</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Bearbeitungskosten</td><td class="py-3 px-4">ab EUR 53 (GBTA)*</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; EUR 9</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Fehlerquote</td><td class="py-3 px-4">19% (GBTA)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 0,3%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Durchlaufzeit</td><td class="py-3 px-4">5 - 12 Werktage</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Minuten</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Automatisierungsquote</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">95%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Audit-Readiness</td><td class="py-3 px-4">Manuell rekonstruiert</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatisch erzeugt</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Tarifvertragswechsel</td><td class="py-3 px-4">Wochen</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 24h</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Retro-Korrektur</td><td class="py-3 px-4">Manuelle Überschreibung</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Storno + Adjustment (append-only)</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">* GBTA Foundation 2024: USD 58 pro Vorgang (ca. EUR 53). Crew-Vorgänge mit Tarifvertrags-Logik, Multi-Jurisdiktion und IROP-Handling liegen branchentypisch darüber. IROP-Quote: EUROCONTROL Annual Report, 2024. Simulationsergebnisse: Gosign-Modellrechnung.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">In der Simulation erreicht der Decision Layer eine Automatisierungsquote von 95% - unabhängig davon, ob 100.000 oder 1.000.000 Vorgänge pro Jahr verarbeitet werden. Nur 5% erfordern menschliche Aufmerksamkeit. Für die übrigen 95% liegt eine vollständige, prüfungssichere Entscheidungsakte vor. Korrekturen und Tarifwechsel erzeugen Storno- und Adjustment-Einträge - keine Überschreibungen, vollständige Buchungshistorie.</p>
</div>
</section>

<!-- Architektur-Referenz -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Architektur und Implementierung</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">Der Travel Decision Layer läuft vollständig in Ihrer Infrastruktur: Ihr Rechenzentrum, Ihr Netzwerk, Ihre Hoheit. Keine SaaS-Abhängigkeit, keine Datenabflüsse. Für Aviation bedeutet das: Anbindung an Crew-Planungssysteme, Verarbeitung von Umlaufdaten in Echtzeit, tarifvertragsspezifische Regelwerke pro Personalgruppe und durchgängiger Audit Trail bis SAP FI/CO. Typische Pilotprojekte starten innerhalb von 3 Monaten mit einer Crew-Gruppe und einem Tarifvertrag.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/de/leistungen/travel-decision-layer/#implementation" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Architektur, Implementierung und Hebel im Detail &rarr;</a>
<a href="/de/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Decision Layer Architektur &rarr;</a>
<a href="/de/leistungen/infrastruktur/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infrastruktur im Detail &rarr;</a>
<a href="/de/governance/mitbestimmung/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Mitbestimmung &amp; Betriebsrat &rarr;</a>
<a href="/de/governance/cert-ready/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready by Design &rarr;</a>
<a href="/de/leistungen/hr-agent/payroll-decision-layer/aviation/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Payroll Decision Layer Aviation &rarr;</a>
</div>
</div>
</section>

<!-- Vertiefung -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Vertiefung im Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Unsere Fachartikel-Serie für Entscheider, die AI Agents im Unternehmen einführen.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/de/magazin/decision-layer-erklaert/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Grundlagen</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - Was ist das und warum braucht jeder Enterprise AI Agent einen?</p>
</a>
<a href="/de/magazin/betriebsrat-ki-mitbestimmung/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Mitbestimmung</p>
<p class="text-body font-semibold text-gosign-dark">Betriebsrat und KI - Mitbestimmung als Architektur-Constraint</p>
</a>
<a href="/de/magazin/eu-ai-act-hr/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Regulatorik</p>
<p class="text-body font-semibold text-gosign-dark">EU AI Act und HR - Was jetzt Pflicht ist</p>
</a>
</div>
</div>
</section>

<!-- Andere Branchen -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Travel Decision Layer in anderen Branchen</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Jede Branche hat eigene Tarifverträge, eigene Kostenstrukturen und eigene Komplexitätstreiber. Der Decision Layer ist derselbe. Die Konfiguration ist branchenspezifisch.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/de/leistungen/travel-decision-layer/beratung/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Beratung</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">Mandanten-Split, Multi-Kostenstelle, Policy</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">85% vollautomatisch</span>
<span class="text-small text-gosign-accent-text font-semibold">Im Detail &rarr;</span>
</div>
</a>
<a href="/de/leistungen/travel-decision-layer/logistik/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Logistik</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">GPS, EU-Mobilitätspaket, vollautomatisch Fahrer</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">95% vollautomatisch</span>
<span class="text-small text-gosign-accent-text font-semibold">Im Detail &rarr;</span>
</div>
</a>
<a href="/de/leistungen/travel-decision-layer/vertrieb/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Vertrieb</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">500 Außendienst, CRM-Integration, Bewirtung</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">90% vollautomatisch</span>
<span class="text-small text-gosign-accent-text font-semibold">Im Detail &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- AI Travel Agent Beratung - Reisekosten ---
> Decision Layer für Beratungs-Reisekosten. Drei-Wege-Split steuerlich/Mandant/intern, Multi-Mandanten-Wochen. Auditierbar automatisiert.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/de/warum-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Jede Entscheidung nachvollziehbar</p>
</div>
</a>
<a href="/de/warum-gosign/#infrastruktur" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Ihre Infrastruktur</p>
<p class="text-xs text-gosign-text-light">Kein SaaS. Kein Vendor-Lock-in.</p>
</div>
</a>
<a href="/de/warum-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Kein US-Cloud-Risiko</p>
</div>
</a>
</div>
</div>
</div>

<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Travel Decision Layer Branchen">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/de/leistungen/travel-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Travel Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/de/leistungen/travel-decision-layer/aviation/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Aviation</a>
<a href="/de/leistungen/travel-decision-layer/beratung/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Beratung</a>
<a href="/de/leistungen/travel-decision-layer/logistik/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Logistik</a>
<a href="/de/leistungen/travel-decision-layer/vertrieb/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Vertrieb</a>
</div>
</div>
</nav>

<!-- Warum Beratung komplex ist -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<!-- Simulationskennzahlen als visuelle Einleitung -->
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">50.000+</span>
<p class="text-small text-gosign-text-light mt-1">Vorgänge/Jahr (Simulation)</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">85%</span>
<p class="text-small text-gosign-text-light mt-1">Automatisierungsquote</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">3-Wege</span>
<p class="text-small text-gosign-text-light mt-1">Kosten-Split (steuerlich/Mandant/intern)</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-border"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">Hohe Regelkomplexität</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">Vorgänge und vollautomatisch: Gosign-Simulationsmodell. Branchenbezogene Benchmarks: GBTA Foundation, 2015.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Was der Agent klassifiziert</p>
<h2 class="text-h1 font-bold text-gosign-dark">Drei Splits, ein Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Steuerlich, Mandant, intern - jede Reise erzeugt drei Kostenperspektiven gleichzeitig. Sie kennen die Komplexität. So löst der AI Agent sie:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Drei-Wege-Split pro Vorgang</h3>
<p class="text-body text-gosign-text mt-2">Jede Reise hat drei Kostenperspektiven: steuerlich, Mandant, intern. Der AI Agent klassifiziert alle drei Dimensionen gleichzeitig pro Reisetag. Das Regelwerk berechnet die Splits deterministisch - abzugsfähig, weiterbelastbar, Kostenstelle. Kein manuelles Zuordnen, keine Inkonsistenzen.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Multi-Mandanten-Wochen automatisch gesplittet</h3>
<p class="text-body text-gosign-text mt-2">Mandant A am Montag, Mandant B am Mittwoch, Hotel über beide. Der AI Agent klassifiziert die Tageszuordnung aus Kalender- und CRM-Daten. Das Regelwerk berechnet anteilige Hotelkosten und ändernde Pauschalen deterministisch. Jeder Split dokumentiert und reproduzierbar.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Policy-Konflikt automatisch gelöst</h3>
<p class="text-body text-gosign-text mt-2">Interne First-Class-Policy trifft auf Mandanten-Economy-Only-Regel. Der AI Agent erkennt den Konflikt, das Regelwerk setzt die strengere Policy durch und dokumentiert, welche Regel gegriffen hat. Der Audit Trail zeigt: Policy X Mandant überschreibt Policy Y intern.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Bewirtungskosten nach Jurisdiktion</h3>
<p class="text-body text-gosign-text mt-2">Deutschland 70% absetzbar, Österreich 50%, Schweiz vollständig. Der AI Agent klassifiziert Belegtyp, Teilnehmeranzahl und Anlass. Das Regelwerk berechnet die länderspezifische Abzugsquote deterministisch. Kein Sachbearbeiter muss die Regeln pro Land kennen.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Mandanten-Abrechnung automatisch dokumentiert</h3>
<p class="text-body text-gosign-text mt-2">800 Vorgänge pro Monat, jeder korrekt dem Mandanten zugeordnet. Der AI Agent prüft 100% der Zuordnungen. Keine systematischen Fehlbuchungen, keine Nacharbeit bei der Mandantenabrechnung. Jede Zuordnung mit Audit-Akte belegt.</p>
</div>
</div>
</div>
</section>

<!-- Decision Flow -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Eine Beratungswoche. 20 bis 60 Mikro-Entscheidungen.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Ein Berater besucht drei Mandanten in einer Woche mit Geschäftsessen und wechselnden Hotels. Der Decision Layer zerlegt diese Woche in einzelne Entscheidungsschritte:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Schritt</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Entscheidung</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Entscheider</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Begründung</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Reise dem Kundenprojekt zuordnen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">Kalender- oder CRM-Integration</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Pauschale bestimmen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">Länderspezifischer Satz nach BMF</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Hotelkosten splitten: weiterbelastbar vs. intern</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">Mandantenvertragsbedingungen bestimmen Split</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Mandantenspezifische Reise-Policy prüfen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">Mandanten-Economy vs. interne First-Class</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Strengere Policy anwenden</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">Die strengere Regel wird angewandt</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Steuerliche Klassifikation</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">Abzugsfähig, teilweise abzugsfähig, Bewirtung</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Multi-Mandanten-Tag splitten</td><td class="py-3 px-4">AI + Regelwerk</td><td class="py-3 px-4">AI bestimmt Zeitallokation, Regeln wenden Kosten-Split an</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">Mandanten-Rechnungsgrundlage erzeugen</td><td class="py-3 px-4">Automatisch</td><td class="py-3 px-4">Audit-ready Reisekostendokumentation pro Mandant</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Bewirtungskosten klassifizieren</td><td class="py-3 px-4">AI + Regelwerk</td><td class="py-3 px-4">AI erkennt Belegtyp, Regelwerk wendet länderspezifische Abzugsquoten an</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Audit-Akte erzeugen</td><td class="py-3 px-4">Automatisch</td><td class="py-3 px-4">Versiegelte Entscheidungsakte pro Beratungswoche</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Simulations-Ergebnis -->
<section id="simulation" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulation</p>
<h2 class="text-h1 font-bold text-white">Durchgerechnet für Beratungs-Volumina</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Wir haben den Travel Decision Layer mit realistischen Beratungs-Parametern konfiguriert und durchgerechnet. Die Ergebnisse zeigen, was sich bei Enterprise-Volumina verändert.</p>

<!-- Parameter-Tabelle -->
<h3 class="text-h3 font-bold text-white mt-10 mb-4">Simulationsparameter</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Berater</td><td class="py-3 px-4">100 bis 500+ (mit mandantenspezifischen Policy-Regeln)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Mandantenverträge</td><td class="py-3 px-4">10 bis 50+ parallele (je mit eigenen Reise-Policies)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Vorgänge/Jahr</td><td class="py-3 px-4">50.000 bis 250.000+</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Rechtskreise</td><td class="py-3 px-4">Multi-Jurisdiktion (DE, AT, CH, weitere EU-Länder)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Systemintegration</td><td class="py-3 px-4">CRM/Zeiterfassung &rarr; Decision Layer &rarr; ERP/Payroll</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Bewirtungsquote</td><td class="py-3 px-4">15 - 25% aller Vorgänge enthalten Bewirtungsbelege</td></tr>
</tbody>
</table>
</div>

<!-- Ergebnis-Vergleich -->
<h3 class="text-h3 font-bold text-white mt-10 mb-4">Vorher / Nachher</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th class="text-left py-3 px-4 font-semibold text-white">Dimension</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manuell</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Bearbeitungskosten</td><td class="py-3 px-4">ab EUR 53 (GBTA)*</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; EUR 9</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Fehlerquote</td><td class="py-3 px-4">19% (GBTA)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 0,3%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Durchlaufzeit</td><td class="py-3 px-4">5 - 12 Werktage</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Minuten</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Automatisierungsquote</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">85%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Audit-Readiness</td><td class="py-3 px-4">Manuell rekonstruiert</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatisch erzeugt</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Split-Genauigkeit</td><td class="py-3 px-4">Manuell geschätzt</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Deterministisch berechnet</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Mandantenabrechnung</td><td class="py-3 px-4">Manuell zugeordnet</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatisch dokumentiert</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">* GBTA Foundation 2024: USD 58 pro Vorgang (ca. EUR 53). Beratungs-Vorgänge mit Drei-Wege-Split und Multi-Mandanten-Logik liegen branchentypisch darüber. Simulationsergebnisse: Gosign-Modellrechnung.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">In der Simulation erreicht der Decision Layer eine Automatisierungsquote von 85% - bei Standardfällen mit eindeutiger Mandantenzuordnung. Die verbleibenden 15% betreffen Multi-Mandanten-Tage und Sonderfälle, die menschliche Beurteilung erfordern. Für alle Fälle liegt eine vollständige, prüfungssichere Entscheidungsakte vor.</p>
</div>
</section>

<!-- Architektur-Referenz -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Architektur und Implementierung</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">Der Travel Decision Layer läuft vollständig in Ihrer Infrastruktur: Ihr Rechenzentrum, Ihr Netzwerk, Ihre Hoheit. Keine SaaS-Abhängigkeit, keine Datenabflüsse. Für Beratungs-Konfigurationen bedeutet das: Multi-Mandanten-Fähigkeit mit separaten Policy-Regelwerken, Anbindung an Projektmanagement- und Zeiterfassungssysteme sowie automatisierter Drei-Wege-Split. Typische Pilotprojekte starten innerhalb von 3 Monaten mit einem Mandantenpool.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/de/leistungen/travel-decision-layer/#implementation" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Architektur, Implementierung und Hebel im Detail &rarr;</a>
<a href="/de/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Decision Layer Architektur &rarr;</a>
<a href="/de/leistungen/infrastruktur/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infrastruktur im Detail &rarr;</a>
<a href="/de/governance/mitbestimmung/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Mitbestimmung &amp; Betriebsrat &rarr;</a>
<a href="/de/governance/cert-ready/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready by Design &rarr;</a>
<a href="/de/leistungen/hr-agent/payroll-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Payroll Decision Layer &rarr;</a>
</div>
</div>
</section>

<!-- Vertiefung -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Vertiefung im Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Unsere Fachartikel-Serie für Entscheider, die AI Agents im Unternehmen einführen.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/de/magazin/decision-layer-erklaert/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Grundlagen</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - Was ist das und warum braucht jeder Enterprise AI Agent einen?</p>
</a>
<a href="/de/magazin/agent-governance-hr/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Agent Governance für HR - Warum der CHRO dieses Thema führen muss</p>
</a>
<a href="/de/magazin/cert-ready-by-design/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Audit</p>
<p class="text-body font-semibold text-gosign-dark">Cert-Ready by Design - Prüfungssichere KI von Anfang an</p>
</a>
</div>
</div>
</section>

<!-- Andere Branchen -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Travel Decision Layer in anderen Branchen</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Jede Branche hat eigene Tarifverträge, eigene Kostenstrukturen und eigene Komplexitätstreiber. Der Decision Layer ist derselbe. Die Konfiguration ist branchenspezifisch.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/de/leistungen/travel-decision-layer/aviation/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Aviation</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">100.000+ Vorgänge/Jahr, IROP, Per Diems</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">95% vollautomatisch</span>
<span class="text-small text-gosign-accent-text font-semibold">Im Detail &rarr;</span>
</div>
</a>
<a href="/de/leistungen/travel-decision-layer/logistik/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Logistik</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">GPS, EU-Mobilitätspaket, vollautomatisch Fahrer</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">95% vollautomatisch</span>
<span class="text-small text-gosign-accent-text font-semibold">Im Detail &rarr;</span>
</div>
</a>
<a href="/de/leistungen/travel-decision-layer/vertrieb/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Vertrieb</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">500 Außendienst, CRM-Integration, Bewirtung</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">90% vollautomatisch</span>
<span class="text-small text-gosign-accent-text font-semibold">Im Detail &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- AI Travel Agent Logistik - Transportkosten ---
> Decision Layer für Logistik-Reisekosten. GPS-Ländererkennung, EU-Mobilitätspaket-Compliance, Fahrer-Modus ohne Rückfragen. Auditierbar automatisiert.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/de/warum-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Jede Entscheidung nachvollziehbar</p>
</div>
</a>
<a href="/de/warum-gosign/#infrastruktur" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Ihre Infrastruktur</p>
<p class="text-xs text-gosign-text-light">Kein SaaS. Kein Vendor-Lock-in.</p>
</div>
</a>
<a href="/de/warum-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Kein US-Cloud-Risiko</p>
</div>
</a>
</div>
</div>
</div>

<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Travel Decision Layer Branchen">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/de/leistungen/travel-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Travel Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/de/leistungen/travel-decision-layer/aviation/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Aviation</a>
<a href="/de/leistungen/travel-decision-layer/beratung/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Beratung</a>
<a href="/de/leistungen/travel-decision-layer/logistik/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Logistik</a>
<a href="/de/leistungen/travel-decision-layer/vertrieb/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Vertrieb</a>
</div>
</div>
</nav>

<!-- Warum Logistik einzigartig ist -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<!-- Simulationskennzahlen als visuelle Einleitung -->
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">500.000+</span>
<p class="text-small text-gosign-text-light mt-1">Vorgänge/Jahr (Simulation)</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">95%</span>
<p class="text-small text-gosign-text-light mt-1">Automatisierungsquote</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">30+</span>
<p class="text-small text-gosign-text-light mt-1">EU/EFTA-Jurisdiktionen</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-border"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">Hohe Regelkomplexität</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">Vorgänge und vollautomatisch: Gosign-Simulationsmodell. Jurisdiktionen: EU/EFTA-Abdeckung. EU-Mobilitätspaket: Richtlinie 2020/1057.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Was der Agent klassifiziert</p>
<h2 class="text-h1 font-bold text-gosign-dark">30+ Jurisdiktionen, ein Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Grenzübertritte mehrmals täglich, wechselnde Pauschalen, Entsendedokumentation. Sie kennen die Komplexität. So löst der AI Agent sie:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">GPS-basierte Länderzuordnung</h3>
<p class="text-body text-gosign-text mt-2">Fahrer überqueren mehrmals täglich Grenzen. Der AI Agent liest GPS-Daten aus Telematiksystemen und klassifiziert Länderzuordnung und Aufenthaltsdauer automatisch. Das Regelwerk berechnet länderspezifische Pauschalen deterministisch. Kein Formular, kein Anhalten an der Grenze.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">EU-Mobilitätspaket automatisch dokumentiert</h3>
<p class="text-body text-gosign-text mt-2">Richtlinie 2020/1057 erfordert Entsendedokumentation. Der AI Agent klassifiziert Einsatzland und Dauer aus den GPS-Daten. Das Regelwerk generiert die Datengrundlage für Compliance-Teams automatisch - ohne zusätzliche Belastung für Fahrer. Die rechtliche Bewertung verbleibt bei Fachabteilungen.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Flottenweite Konsistenz</h3>
<p class="text-body text-gosign-text mt-2">500 LKW überqueren täglich dieselben Grenzen. Der AI Agent wendet identische Regeln auf identische Routen an. Keine personenabhängige Variation, keine inkonsistenten Berechnungen. Das Regelwerk eliminiert Prüfungsrisiko im Volumen.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">vollautomatisch Fahrer-Modus</h3>
<p class="text-body text-gosign-text mt-2">GPS-Daten rein, Pauschalenberechnung raus, Payroll-Export fertig. Der AI Agent verarbeitet Standardrouten vollautomatisch. Der Fahrer fährt, das System entscheidet. Rückfragen nur bei GPS-Lücken oder neuen Routen.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Minuten-genaues Grenzübertritt-Timing</h3>
<p class="text-body text-gosign-text mt-2">23:45 deutsch-polnische Grenze, 00:15 weiter nach Tschechien - drei Länder an einem Diensttag. Der AI Agent klassifiziert sekundengenau aus GPS-Daten. Das Regelwerk berechnet anteilige Pauschalen über Mitternachtsgrenzen. Präzision, die manuelle Erfassung nicht leisten kann.</p>
</div>
</div>
</div>
</section>

<!-- Decision Flow -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Eine Fahrertour. 15 bis 40 Mikro-Entscheidungen.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Ein Fahrer fährt eine Drei-Länder-Tour mit Übernachtung. Der Decision Layer zerlegt diese Tour in einzelne Entscheidungsschritte:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Schritt</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Entscheidung</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Entscheider</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Begründung</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">GPS-Track aus Telematik lesen</td><td class="py-3 px-4">Automatisch</td><td class="py-3 px-4">Datenimport, keine Entscheidung</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Länderfolge und Dauer bestimmen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">GPS-Koordinaten auf Jurisdiktionen gemappt</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Pauschale pro Land wählen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">Länderspezifischer Satz nach BMF</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Mitternachts-Grenzübertritt berechnen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">Anteilige Berechnung bei Grenzübertritt um Mitternacht</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Langzeit-Entsendungsschwelle prüfen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">Dauerbasierte Schwellen pro Jurisdiktion</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">EU-Mobilitätspaket-Daten erzeugen</td><td class="py-3 px-4">Automatisch</td><td class="py-3 px-4">Entsendedokumentation als Datengrundlage</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Flotten-Kostenstelle zuordnen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">Fahrzeug zu Flotte, Flotte zu Kostenstelle</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">Payroll-Export erzeugen</td><td class="py-3 px-4">Automatisch</td><td class="py-3 px-4">Buchungsfertige Pauschalen-Daten</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Ruhezeit-Compliance prüfen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">Lenk- und Ruhezeiten gegen EU-Verordnung 561/2006 prüfen</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Audit-Akte erzeugen</td><td class="py-3 px-4">Automatisch</td><td class="py-3 px-4">Versiegelte Entscheidungsakte pro Fahrertour</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Simulations-Ergebnis -->
<section id="simulation" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulation</p>
<h2 class="text-h1 font-bold text-white">Durchgerechnet für Logistik-Volumina</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Wir haben den Travel Decision Layer mit realistischen Logistik-Parametern konfiguriert und durchgerechnet. Die Ergebnisse zeigen, was sich bei Enterprise-Flottengrößen verändert.</p>

<!-- Parameter-Tabelle -->
<h3 class="text-h3 font-bold text-white mt-10 mb-4">Simulationsparameter</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Flotte</td><td class="py-3 px-4">200 bis 2.000+ Fahrzeuge (eigene und Subunternehmer)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Fahrer</td><td class="py-3 px-4">300 bis 3.000+ (mit verschiedenen Vertragsmodellen)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Vorgänge/Jahr</td><td class="py-3 px-4">500.000 bis 2.000.000+</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Rechtskreise</td><td class="py-3 px-4">30+ EU/EFTA-Jurisdiktionen</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Systemintegration</td><td class="py-3 px-4">Telematik &rarr; Decision Layer &rarr; ERP/Payroll</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Grenzübertritte/Tag</td><td class="py-3 px-4">500 bis 5.000+ (flottenabhängig)</td></tr>
</tbody>
</table>
</div>

<!-- Ergebnis-Vergleich -->
<h3 class="text-h3 font-bold text-white mt-10 mb-4">Vorher / Nachher</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th class="text-left py-3 px-4 font-semibold text-white">Dimension</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manuell</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Bearbeitungskosten</td><td class="py-3 px-4">ab EUR 53 (GBTA)*</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; EUR 5</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Fehlerquote</td><td class="py-3 px-4">19% (GBTA)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 0,1%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Durchlaufzeit</td><td class="py-3 px-4">5 - 12 Werktage</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Minuten</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Automatisierungsquote</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">95%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Audit-Readiness</td><td class="py-3 px-4">Manuell rekonstruiert</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatisch erzeugt</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">EU-Mobilitätspaket-Daten</td><td class="py-3 px-4">Manuell erfasst</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatisch generiert</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Fahrer-Rückfragen</td><td class="py-3 px-4">3 - 5 pro Woche</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 0,1 pro Woche</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">* GBTA Foundation 2024: USD 58 pro Vorgang (ca. EUR 53). Logistik-Vorgänge mit GPS-basierter Ländererkennung sind im Vollautomatik-Modus signifikant günstiger. EU-Mobilitätspaket: Richtlinie 2020/1057. Simulationsergebnisse: Gosign-Modellrechnung.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">In der Simulation erreicht der Decision Layer eine Automatisierungsquote von 95% - bei Standardrouten mit GPS-Abdeckung. Die verbleibenden 5% betreffen GPS-Lücken, neue Routen und Sonderfälle. Für alle Fälle liegt eine vollständige, prüfungssichere Entscheidungsakte vor. Fahrer müssen keine Formulare ausfüllen.</p>
</div>
</section>

<!-- Architektur-Referenz -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Architektur und Implementierung</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">Der Travel Decision Layer läuft vollständig in Ihrer Infrastruktur: Ihr Rechenzentrum, Ihr Netzwerk, Ihre Hoheit. Keine SaaS-Abhängigkeit, keine Datenabflüsse. Für Logistik-Konfigurationen bedeutet das: Telematik-Schnittstellen für GPS-Datenimport, Verarbeitung von Grenzübertritten in Echtzeit und flottenweite Pauschalenberechnung über 30+ EU/EFTA-Jurisdiktionen. Typische Pilotprojekte starten innerhalb von 3 Monaten mit einer Flottengruppe und den meistbefahrenen Routen.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/de/leistungen/travel-decision-layer/#implementation" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Architektur, Implementierung und Hebel im Detail &rarr;</a>
<a href="/de/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Decision Layer Architektur &rarr;</a>
<a href="/de/leistungen/infrastruktur/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infrastruktur im Detail &rarr;</a>
<a href="/de/governance/mitbestimmung/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Mitbestimmung &amp; Betriebsrat &rarr;</a>
<a href="/de/governance/cert-ready/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready by Design &rarr;</a>
<a href="/de/leistungen/hr-agent/payroll-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Payroll Decision Layer &rarr;</a>
</div>
</div>
</section>

<!-- Vertiefung -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Vertiefung im Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Unsere Fachartikel-Serie für Entscheider, die AI Agents im Unternehmen einführen.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/de/magazin/decision-layer-erklaert/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Grundlagen</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - Was ist das und warum braucht jeder Enterprise AI Agent einen?</p>
</a>
<a href="/de/magazin/betriebsrat-ki-mitbestimmung/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Mitbestimmung</p>
<p class="text-body font-semibold text-gosign-dark">Betriebsrat und KI - Mitbestimmung als Architektur-Constraint</p>
</a>
<a href="/de/magazin/cert-ready-by-design/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Audit</p>
<p class="text-body font-semibold text-gosign-dark">Cert-Ready by Design - Prüfungssichere KI von Anfang an</p>
</a>
</div>
</div>
</section>

<!-- Andere Branchen -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Travel Decision Layer in anderen Branchen</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Jede Branche hat eigene Tarifverträge, eigene Kostenstrukturen und eigene Komplexitätstreiber. Der Decision Layer ist derselbe. Die Konfiguration ist branchenspezifisch.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/de/leistungen/travel-decision-layer/aviation/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Aviation</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">100.000+ Vorgänge/Jahr, IROP, Per Diems</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">95% vollautomatisch</span>
<span class="text-small text-gosign-accent-text font-semibold">Im Detail &rarr;</span>
</div>
</a>
<a href="/de/leistungen/travel-decision-layer/beratung/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Beratung</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">Mandanten-Split, Multi-Kostenstelle, Policy</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">85% vollautomatisch</span>
<span class="text-small text-gosign-accent-text font-semibold">Im Detail &rarr;</span>
</div>
</a>
<a href="/de/leistungen/travel-decision-layer/vertrieb/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Vertrieb</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">500 Außendienst, CRM-Integration, Bewirtung</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">90% vollautomatisch</span>
<span class="text-small text-gosign-accent-text font-semibold">Im Detail &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- AI Travel Agent Vertrieb - Außendienst ---
> Decision Layer für Vertriebs-Reisekosten. CRM-Integration, Policy-Durchsetzung bei 10.000+ Vorgängen/Monat, Wochenabrechnung. Auditierbar automatisiert.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/de/warum-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Jede Entscheidung nachvollziehbar</p>
</div>
</a>
<a href="/de/warum-gosign/#infrastruktur" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Ihre Infrastruktur</p>
<p class="text-xs text-gosign-text-light">Kein SaaS. Kein Vendor-Lock-in.</p>
</div>
</a>
<a href="/de/warum-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Kein US-Cloud-Risiko</p>
</div>
</a>
</div>
</div>
</div>

<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Travel Decision Layer Branchen">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/de/leistungen/travel-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Travel Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/de/leistungen/travel-decision-layer/aviation/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Aviation</a>
<a href="/de/leistungen/travel-decision-layer/beratung/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Beratung</a>
<a href="/de/leistungen/travel-decision-layer/logistik/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Logistik</a>
<a href="/de/leistungen/travel-decision-layer/vertrieb/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Vertrieb</a>
</div>
</div>
</nav>

<!-- Warum Vertriebsvolumen Governance braucht -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<!-- Simulationskennzahlen als visuelle Einleitung -->
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">120.000+</span>
<p class="text-small text-gosign-text-light mt-1">Vorgänge/Jahr (Simulation)</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">90%</span>
<p class="text-small text-gosign-text-light mt-1">Automatisierungsquote</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">100%</span>
<p class="text-small text-gosign-text-light mt-1">Policy-Prüfung (statt Stichprobe)</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-border"></span><span class="w-4 h-2 rounded-sm bg-gosign-border"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">Mittlere Regelkomplexität, hohes Volumen</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">Vorgänge und vollautomatisch: Gosign-Simulationsmodell. Policy-Prüfung: Decision Layer prüft 100% der Vorgänge. Branchenbezogene Benchmarks: GBTA Foundation, 2015.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Was der Agent klassifiziert</p>
<h2 class="text-h1 font-bold text-gosign-dark">10.000 Vorgänge/Monat, ein Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">500 Außendienstmitarbeiter, tägliche Kundenbesuche, wechselnde Policies. Sie kennen die Komplexität. So löst der AI Agent sie:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">100% Policy-Prüfung statt 5% Stichprobe</h3>
<p class="text-body text-gosign-text mt-2">500 Außendienstmitarbeiter, je 20 Abrechnungen pro Monat. Der AI Agent prüft jeden einzelnen Vorgang gegen das Policy-Regelwerk. Keine Stichproben, keine systematischen Verstöße die durchrutschen. Das Regelwerk dokumentiert jede Policy-Entscheidung im Audit Trail.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">CRM-Verknüpfung automatisch</h3>
<p class="text-body text-gosign-text mt-2">Jeder Kundenbesuch hat einen Geschäftszweck. Der AI Agent verknüpft CRM-Daten mit Reisekosten automatisch: Kunde, Opportunity, Umsatzzuordnung. Das Regelwerk ordnet Kostenstellen deterministisch zu. Kein fehlender Geschäftszweck, keine manuelle Eingabe.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Wochenabrechnung statt Einzelvorgänge</h3>
<p class="text-body text-gosign-text mt-2">Der AI Agent bündelt alle Reisen einer Woche pro Mitarbeiter. Das Regelwerk berechnet Pauschalen und Kilometergeld aggregiert und erzeugt eine Wochenabrechnung. Der Mitarbeiter wird informiert und hat ein Veto-Recht - kein Einreichen-Genehmigen-Zyklus.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Bewirtungskosten nach Jurisdiktion</h3>
<p class="text-body text-gosign-text mt-2">Deutschland 70% absetzbar, Österreich 50%, Schweiz vollständig. Der AI Agent klassifiziert Belegtyp, Teilnehmeranzahl und Anlass. Das Regelwerk berechnet die länderspezifische Abzugsquote deterministisch. Kein Sachbearbeiter muss die Regeln pro Land kennen.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Quartalsabschluss in Minuten</h3>
<p class="text-body text-gosign-text mt-2">Quartalsende bedeutet Deadline für alle offenen Vorgänge. Der AI Agent identifiziert unvollständige Abrechnungen automatisch, klassifiziert fehlende Belege und eskaliert nur echte Ausnahmen. Das Regelwerk erzeugt den Quartals-Export buchungsfertig. Kein Monatsend-Engpass, keine Nachtschichten.</p>
</div>
</div>
</div>
</section>

<!-- Decision Flow -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Eine Vertriebswoche. 30 bis 80 Mikro-Entscheidungen.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Ein Außendienst-Mitarbeiter besucht fünf Kunden in einer Woche mit Hotelaufenthalten und Geschäftsessen. Der Decision Layer zerlegt diese Woche in einzelne Entscheidungsschritte:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Schritt</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Entscheidung</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Entscheider</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Begründung</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Reise mit CRM-Opportunity verknüpfen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">Kalender- + CRM-Datenabgleich</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Pauschale bestimmen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">Basierend auf Land und Aufenthaltsdauer</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Kilometergeld berechnen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">Distanz, Fahrzeugtyp, Satz</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Bewirtungs-Policy prüfen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">Betrag, Teilnehmer, Zweck</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Hotel-Policy prüfen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">Preislimit pro Stadtkategorie</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">In Wochenabrechnung bündeln</td><td class="py-3 px-4">Automatisch</td><td class="py-3 px-4">Alle Reisen einer Woche aggregiert</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Kostenstelle und Opportunity zuordnen</td><td class="py-3 px-4">Regelwerk</td><td class="py-3 px-4">Mandant, Projekt, Umsatzzuordnung</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">Payroll-Export erzeugen</td><td class="py-3 px-4">Automatisch</td><td class="py-3 px-4">Wochenabrechnung als Buchung</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Bewirtungskosten klassifizieren</td><td class="py-3 px-4">AI + Regelwerk</td><td class="py-3 px-4">AI erkennt Belegtyp und Teilnehmer, Regelwerk wendet Abzugsquoten an</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Audit-Akte erzeugen</td><td class="py-3 px-4">Automatisch</td><td class="py-3 px-4">Versiegelte Entscheidungsakte pro Vertriebswoche</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Simulations-Ergebnis -->
<section id="simulation" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulation</p>
<h2 class="text-h1 font-bold text-white">Durchgerechnet für Vertriebs-Volumina</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Wir haben den Travel Decision Layer mit realistischen Vertriebs-Parametern konfiguriert und durchgerechnet. Die Ergebnisse zeigen, was sich bei Enterprise-Außendienst-Volumina verändert.</p>

<!-- Parameter-Tabelle -->
<h3 class="text-h3 font-bold text-white mt-10 mb-4">Simulationsparameter</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Außendienst-Mitarbeiter</td><td class="py-3 px-4">200 bis 2.000+ (nach Region und Hierarchie)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Vorgänge/Monat</td><td class="py-3 px-4">10.000 bis 50.000+</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Rechtskreise</td><td class="py-3 px-4">Multi-Jurisdiktion (DE, AT, CH, weitere EU-Länder)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Systemintegration</td><td class="py-3 px-4">CRM &rarr; Decision Layer &rarr; ERP/Payroll</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Bewirtungsquote</td><td class="py-3 px-4">20 - 30% aller Vorgänge enthalten Bewirtungsbelege</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Policies</td><td class="py-3 px-4">3 - 10 parallele (nach Region, Hierarchie, Kundenklasse)</td></tr>
</tbody>
</table>
</div>

<!-- Ergebnis-Vergleich -->
<h3 class="text-h3 font-bold text-white mt-10 mb-4">Vorher / Nachher</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th class="text-left py-3 px-4 font-semibold text-white">Dimension</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manuell</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Bearbeitungskosten</td><td class="py-3 px-4">ab EUR 53 (GBTA)*</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; EUR 7</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Fehlerquote</td><td class="py-3 px-4">19% (GBTA)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 0,5%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Durchlaufzeit</td><td class="py-3 px-4">5 - 12 Werktage</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Minuten</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Automatisierungsquote</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">90%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Audit-Readiness</td><td class="py-3 px-4">Manuell rekonstruiert</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatisch erzeugt</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Policy-Prüfung</td><td class="py-3 px-4">5 - 10% (Stichprobe)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">100%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Wochenabrechnung</td><td class="py-3 px-4">Manuell zusammengestellt</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatisch aggregiert</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">* GBTA Foundation 2024: USD 58 pro Vorgang (ca. EUR 53). Vertriebs-Vorgänge mit CRM-Integration und Wochenbündelung sind im Vollautomatik-Modus signifikant günstiger. Simulationsergebnisse: Gosign-Modellrechnung.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">In der Simulation erreicht der Decision Layer eine Automatisierungsquote von 90% - bei Standardfällen mit eindeutiger CRM-Verknüpfung. Die verbleibenden 10% betreffen Bewirtungssonderfälle und fehlende CRM-Einträge, die menschliche Beurteilung erfordern. Für alle Fälle liegt eine vollständige, prüfungssichere Entscheidungsakte vor. Wochenabrechnungen ersetzen den Einzelabrechnungs-Zyklus.</p>
</div>
</section>

<!-- Architektur-Referenz -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Architektur und Implementierung</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">Der Travel Decision Layer läuft vollständig in Ihrer Infrastruktur: Ihr Rechenzentrum, Ihr Netzwerk, Ihre Hoheit. Keine SaaS-Abhängigkeit, keine Datenabflüsse. Für Vertriebs-Konfigurationen bedeutet das: CRM-Schnittstellen für automatische Reise-Mandant-Verknüpfung, Volumenverarbeitung von 10.000+ Vorgängen pro Monat und Wochenabrechnungs-Logik. Typische Pilotprojekte starten innerhalb von 3 Monaten mit einer Vertriebsregion.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/de/leistungen/travel-decision-layer/#implementation" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Architektur, Implementierung und Hebel im Detail &rarr;</a>
<a href="/de/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Decision Layer Architektur &rarr;</a>
<a href="/de/leistungen/infrastruktur/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infrastruktur im Detail &rarr;</a>
<a href="/de/governance/mitbestimmung/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Mitbestimmung &amp; Betriebsrat &rarr;</a>
<a href="/de/governance/cert-ready/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready by Design &rarr;</a>
<a href="/de/leistungen/hr-agent/payroll-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Payroll Decision Layer &rarr;</a>
</div>
</div>
</section>

<!-- Vertiefung -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Vertiefung im Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Unsere Fachartikel-Serie für Entscheider, die AI Agents im Unternehmen einführen.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/de/magazin/decision-layer-erklaert/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Grundlagen</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - Was ist das und warum braucht jeder Enterprise AI Agent einen?</p>
</a>
<a href="/de/magazin/agent-governance-hr/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Agent Governance für HR - Warum der CHRO dieses Thema führen muss</p>
</a>
<a href="/de/magazin/eu-ai-act-hr/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Regulatorik</p>
<p class="text-body font-semibold text-gosign-dark">EU AI Act und HR - Was jetzt Pflicht ist</p>
</a>
</div>
</div>
</section>

<!-- Andere Branchen -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Travel Decision Layer in anderen Branchen</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Jede Branche hat eigene Tarifverträge, eigene Kostenstrukturen und eigene Komplexitätstreiber. Der Decision Layer ist derselbe. Die Konfiguration ist branchenspezifisch.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/de/leistungen/travel-decision-layer/aviation/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Aviation</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">100.000+ Vorgänge/Jahr, IROP, Per Diems</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">95% vollautomatisch</span>
<span class="text-small text-gosign-accent-text font-semibold">Im Detail &rarr;</span>
</div>
</a>
<a href="/de/leistungen/travel-decision-layer/beratung/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Beratung</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">Mandanten-Split, Multi-Kostenstelle, Policy</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">85% vollautomatisch</span>
<span class="text-small text-gosign-accent-text font-semibold">Im Detail &rarr;</span>
</div>
</a>
<a href="/de/leistungen/travel-decision-layer/logistik/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Logistik</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">GPS, EU-Mobilitätspaket, vollautomatisch Fahrer</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">95% vollautomatisch</span>
<span class="text-small text-gosign-accent-text font-semibold">Im Detail &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- AI Travel Decision Layer - Reisekosten-Governance ---
> Der Decision Layer zerlegt jeden Reisekostenvorgang in Entscheidungsschritte. Regelbasiert, auditierbar, 85-95% vollautomatisch.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/de/warum-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Jede Entscheidung nachvollziehbar</p>
</div>
</a>
<a href="/de/warum-gosign/#infrastruktur" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Ihre Infrastruktur</p>
<p class="text-xs text-gosign-text-light">Kein SaaS. Kein Vendor-Lock-in.</p>
</div>
</a>
<a href="/de/warum-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Kein US-Cloud-Risiko</p>
</div>
</a>
</div>
</div>
</div>

<!-- Problem -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<!-- GBTA Benchmarks als visuelle Einleitung -->
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">EUR 53</span>
<p class="text-small text-gosign-text-light mt-1">pro Vorgang, manuelle Bearbeitung</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">19%</span>
<p class="text-small text-gosign-text-light mt-1">Fehlerquote bei Reisekostenabrechnungen</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">EUR 48</span>
<p class="text-small text-gosign-text-light mt-1">Korrekturkosten pro Fehler</p>
</div>
<p class="sm:col-span-3 text-xs text-gosign-text-light">GBTA Foundation 2024: USD 58 pro Vorgang (ca. EUR 53). HRS, "Expense Reporting: Global Practices and Pain Points".</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Das Problem</p>
<h2 class="text-h1 font-bold text-gosign-dark">Warum Expense-Tools in komplexen Organisationen scheitern</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">SAP Concur, Circula, Moss, Spendesk. Sie alle digitalisieren denselben manuellen Prozess: Belege erfassen, Formulare ausfüllen, Freigaben einholen. Bei EUR 53 pro Vorgang und 19% Fehlerquote laut GBTA ist das teuer. Aber in Organisationen mit Tarifverträgen, internationalem Personal und Dutzenden Rechtskreisen ist die Erfassung nicht das Problem. Die Entscheidung ist es.</p>
<div class="mt-10">
<div class="grid grid-cols-1 md:grid-cols-3 gap-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">EUR 53 pro Vorgang</h3>
<p class="text-body text-gosign-text-light mt-2">Expense-Tools digitalisieren Papierformulare. Der Mitarbeiter füllt aus, der Vorgesetzte genehmigt, die Buchhaltung prüft. Drei manuelle Schritte, EUR 53 pro Stück (GBTA). Bei 100.000 Vorgängen pro Jahr sind das EUR 5,3 Mio. reine Bearbeitungskosten.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">19% Fehlerquote</h3>
<p class="text-body text-gosign-text-light mt-2">Länderpauschalen, Buchungsregeln, Mahlzeitenkürzungen, Tarifvertrags-Overrides, Steuerfreiheitsgrenzen. Kein Mitarbeiter kennt alle Regeln. Kein Genehmiger prüft sie. Ergebnis: Jeder fünfte Vorgang ist fehlerhaft. EUR 48 Korrekturkosten pro Fehler (GBTA).</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Null Audit-Readiness</h3>
<p class="text-body text-gosign-text-light mt-2">Wenn die Betriebsprüfung kommt, fehlt der Nachweis: Welche Regel wurde angewandt? Warum diese Pauschale? War die Kürzung korrekt? Expense-Tools dokumentieren, was eingereicht wurde. Nicht warum so entschieden wurde.</p>
</div>
</div>
</div>
</div>
</section>

<!-- Decision Layer Prinzip -->
<section id="decision-layer" class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Der Decision Layer</p>
<h2 class="text-h1 font-bold text-gosign-dark">Jeder Vorgang. Zerlegt in Entscheidungsschritte.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Der Travel Decision Layer arbeitet wie jeder Gosign Decision Layer: Er zerlegt einen Prozess in einzelne Entscheidungsschritte und definiert für jeden Schritt, wer oder was entscheidet. Regelwerk, Tarifvertrag oder Mensch. Nicht alles auf einmal, sondern Schritt für Schritt, dokumentiert und nachvollziehbar.</p>

<div class="mt-10">
<img src="/images/diagrams/travel-decision-flow-v2-de.svg" alt="Travel Decision Layer Entscheidungsfluss: Daten-Input, AI-Extraktion, Decision Layer, Ergebnis" width="1000" height="280" class="w-full" />
</div>

<p class="text-body text-gosign-text mt-8 max-w-narrow font-semibold">AI extrahiert und klassifiziert. Der Decision Layer entscheidet. Diese Trennung ist der Grund, warum das System auditierbar, AI-Act-konform und betriebsratsfähig ist.</p>

<div class="mt-10">
<div class="grid grid-cols-1 md:grid-cols-2 gap-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Gleicher Input, gleiches Ergebnis</h3>
<p class="text-body text-gosign-text-light mt-2">Decision Tables sind versioniert. Jeder Vorgang wird gegen eine definierte Regelversion geprüft. Der AI Agent klassifiziert, das Regelwerk berechnet Erstattungsbeträge, Pauschalen und Steuerfreibeträge deterministisch.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">40 bis 120 Einzelentscheidungen pro Vorgang</h3>
<p class="text-body text-gosign-text-light mt-2">Nicht eine große Entscheidung 'genehmigt / abgelehnt', sondern Dutzende kleine: Welche Pauschale? Welche Kürzung? Welcher Tarifvertrag? Steuerfreier Anteil? Jede einzeln dokumentiert.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Regelwerk, Tarifvertrag oder Mensch</h3>
<p class="text-body text-gosign-text-light mt-2">Der Decision Layer entscheidet nicht alles selbst. Er weiß, welche Schritte das Regelwerk abdeckt, welche tarifvertraglich definiert sind und wo ein Mensch eingreifen muss. Das Ergebnis: Nur echte Ausnahmen brauchen menschliche Aufmerksamkeit.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Der Mitarbeiter bestätigt nicht. Er kann widersprechen.</h3>
<p class="text-body text-gosign-text-light mt-2">Traditionelle Expense-Tools verlangen vom Mitarbeiter die Bestätigung seiner eigenen Abrechnung. Der Decision Layer kehrt das um: Die Verarbeitung erfolgt automatisch. Der Mitarbeiter wird informiert und hat ein Veto-Recht.</p>
</div>
</div>
</div>
</div>
</section>

<!-- Governance & Audit -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<h2 class="text-h1 font-bold text-gosign-dark">Nicht nachträglich dokumentiert. Im Prozess entstanden.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Wenn der Betriebsprüfer fragt "Warum wurden 28 EUR statt 14 EUR angesetzt?" reicht "das hat das System berechnet" nicht. Der Travel Decision Layer erzeugt für jede Mikroentscheidung einen Entscheidungsakt, der genau diese Frage beantwortet: Welche Regel samt Version, welcher Input, welches Ergebnis, wann, von wem - inklusive Anfechtungspfad. Damit wird auch die Erläuterung der Einzelentscheidung nach Art. 86 EU AI Act zur Abfrage statt zum Forensik-Projekt.</p>

<!-- Audit Trail Card -->
<div class="mt-10 bg-gosign-dark rounded-card p-6 sm:p-8">
<div class="flex items-start gap-4 mb-6">
<svg class="w-8 h-8 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12h6m-6 4h6m2 5H7a2 2 0 01-2-2V5a2 2 0 012-2h5.586a1 1 0 01.707.293l5.414 5.414a1 1 0 01.293.707V19a2 2 0 01-2 2z" />
</svg>
<div>
<h3 class="text-h3 font-bold text-white">Jede Mikro-Entscheidung erzeugt einen Audit-Eintrag</h3>
<p class="text-small text-gosign-text-on-dark/70 mt-1">Append-only. Nichts wird überschrieben, nichts gelöscht. Bei Korrekturen entstehen Storno- und Adjustment-Einträge. SHA-256 signiert, jederzeit exportierbar.</p>
</div>
</div>
<div class="grid grid-cols-2 sm:grid-cols-3 gap-3 sm:gap-4">
<div class="flex items-center gap-2.5">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span class="text-small text-gosign-text-on-dark/80">Regel-ID + Version</span>
</div>
<div class="flex items-center gap-2.5">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span class="text-small text-gosign-text-on-dark/80">Input-Daten (was lag vor?)</span>
</div>
<div class="flex items-center gap-2.5">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span class="text-small text-gosign-text-on-dark/80">Ergebnis (was wurde entschieden?)</span>
</div>
<div class="flex items-center gap-2.5">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span class="text-small text-gosign-text-on-dark/80">Zeitstempel</span>
</div>
<div class="flex items-center gap-2.5">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span class="text-small text-gosign-text-on-dark/80">Actor (Regelwerk / Tarif / Mensch)</span>
</div>
<div class="flex items-center gap-2.5">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span class="text-small text-gosign-text-on-dark/80">Input-Hash (reproduzierbar)</span>
</div>
</div>
</div>

<!-- Three Governance Pillars -->
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8">
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-3">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M15 12a3 3 0 11-6 0 3 3 0 016 0z" />
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M2.458 12C3.732 7.943 7.523 5 12 5c4.478 0 8.268 2.943 9.542 7-1.274 4.057-5.064 7-9.542 7-4.477 0-8.268-2.943-9.542-7z" />
</svg>
<div>
<h3 class="text-body font-semibold text-gosign-dark">Betriebsrats-transparent</h3>
<p class="text-small text-gosign-text-light mt-2">Regelwerk einsehbar. Entscheidungen nachvollziehbar. Anomalie-Erkennung per Feature Flag steuerbar. Reports pseudonymisiert. Compliance und Performance architektonisch getrennt.</p>
<a href="/de/governance/mitbestimmung/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Mitbestimmung &rarr;</a>
</div>
</div>
</div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-3">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12l2 2 4-4m5.618-4.016A11.955 11.955 0 0112 2.944a11.955 11.955 0 01-8.618 3.04A12.02 12.02 0 003 9c0 5.591 3.824 10.29 9 11.622 5.176-1.332 9-6.03 9-11.622 0-1.042-.133-2.052-.382-3.016z" />
</svg>
<div>
<h3 class="text-body font-semibold text-gosign-dark">Betriebsprüfungs-ready</h3>
<p class="text-small text-gosign-text-light mt-2">Aufbewahrungsfristen unterstützt (10 Jahre, AO &sect; 147). Anonymisierung statt Löschung für DSGVO-Kompatibilität. Jeder Vorgang über Input-Hash reproduzierbar.</p>
<a href="/de/governance/cert-ready/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready &rarr;</a>
</div>
</div>
</div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-3">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 5H7a2 2 0 00-2 2v12a2 2 0 002 2h10a2 2 0 002-2V7a2 2 0 00-2-2h-2M9 5a2 2 0 002 2h2a2 2 0 002-2M9 5a2 2 0 012-2h2a2 2 0 012 2m-6 9l2 2 4-4" />
</svg>
<div>
<h3 class="text-body font-semibold text-gosign-dark">Systematische Compliance</h3>
<p class="text-small text-gosign-text-light mt-2">Kein Quartalsbericht, keine Stichprobenprüfung. Vorgänge werden systematisch gegen das Regelwerk geprüft. Abweichungen sofort erkannt und dokumentiert.</p>
</div>
</div>
</div>
</div>
</div>
</section>

<!-- Vergleichstabelle -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="overflow-x-auto">
<table class="w-full text-small border-collapse">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Dimension</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Traditionelles Expense-Tool</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-accent-text">Travel Decision Layer</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 font-medium text-gosign-dark">Entscheidungsmodell</td>
<td class="py-3 px-4 text-gosign-text-light">Mensch füllt aus, Vorgesetzter genehmigt</td>
<td class="py-3 px-4 text-gosign-accent-text font-semibold">Decision Layer wendet Regeln an, Mensch hat Veto</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 font-medium text-gosign-dark">Regelkomplexität</td>
<td class="py-3 px-4 text-gosign-text-light">Basis-Policies, keine Tarifvertragslogik</td>
<td class="py-3 px-4 text-gosign-accent-text font-semibold">Versionierte Decision Tables: Steuerrecht, Pauschalen, Tarifverträge</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 font-medium text-gosign-dark">Audit Trail</td>
<td class="py-3 px-4 text-gosign-text-light">Beleg gespeichert, Entscheidung nicht dokumentiert</td>
<td class="py-3 px-4 text-gosign-accent-text font-semibold">Jede Mikro-Entscheidung dokumentiert: Regel, Input, Ergebnis, Zeitstempel</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 font-medium text-gosign-dark">Betriebsprüfung</td>
<td class="py-3 px-4 text-gosign-text-light">Manuelle Rekonstruktion aus Akten</td>
<td class="py-3 px-4 text-gosign-accent-text font-semibold">Export: versiegelte Audit-Akte pro Vorgang, reproduzierbar über Input-Hash</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 font-medium text-gosign-dark">Mitarbeiter-Erlebnis</td>
<td class="py-3 px-4 text-gosign-text-light">Formular, Upload, auf Freigabe warten</td>
<td class="py-3 px-4 text-gosign-accent-text font-semibold">Automatische Verarbeitung, Benachrichtigung, Veto-Option</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 font-medium text-gosign-dark">Skalierbarkeit</td>
<td class="py-3 px-4 text-gosign-text-light">Linear: mehr Vorgänge = mehr Prüfer</td>
<td class="py-3 px-4 text-gosign-accent-text font-semibold">Konstant: 100 oder 100.000 Vorgänge, gleiches Regelwerk</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 font-medium text-gosign-dark">Betriebsrat</td>
<td class="py-3 px-4 text-gosign-text-light">Intransparent, schwer prüfbar</td>
<td class="py-3 px-4 text-gosign-accent-text font-semibold">Regelwerk einsehbar, Anomalie-Scoring per Feature Flag steuerbar, Reports pseudonymisiert</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Branchen-Simulationen -->
<section id="simulationen" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simuliert für Enterprise-Volumina</p>
<h2 class="text-h1 font-bold text-white">Vier Branchen. Durchgerechnet.</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Wir haben den Travel Decision Layer für vier Branchen konfiguriert und mit realistischen Volumina durchgerechnet. Jede Karte zeigt die Simulationsparameter und das Ergebnis.</p>

<div class="grid grid-cols-1 md:grid-cols-2 gap-6 mt-10">
<!-- Aviation -->
<a href="/de/leistungen/travel-decision-layer/aviation/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors">
<div class="flex items-center justify-between mb-4">
<h3 class="text-h3 font-bold text-white">Aviation</h3>
<div class="flex gap-1">
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
</div>
</div>
<ul class="space-y-1.5 text-small text-gosign-text-on-dark/70">
<li>Zehntausende Crew, mehrere Personalgruppen</li>
<li>Mehrere parallele Tarifverträge pro Carrier</li>
<li>100.000 bis 1.000.000+ Vorgänge/Jahr</li>
<li>Multi-Carrier, Multi-Jurisdiktion</li>
</ul>
<div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between">
<span class="text-h3 font-bold text-gosign-accent-on-dark">95% vollautomatisch</span>
<span class="text-small text-gosign-accent-on-dark font-semibold">Aviation im Detail &rarr;</span>
</div>
</a>

<!-- Beratung -->
<a href="/de/leistungen/travel-decision-layer/beratung/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors">
<div class="flex items-center justify-between mb-4">
<h3 class="text-h3 font-bold text-white">Beratung</h3>
<div class="flex gap-1">
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-white/20"></span>
</div>
</div>
<ul class="space-y-1.5 text-small text-gosign-text-on-dark/70">
<li>8.000+ Berater, 15+ Rechtskreise</li>
<li>Drei-Wege-Split: steuerlich / Mandant / intern</li>
<li>Multi-Mandanten-Wochen, täglich wechselnde Kostenstellen</li>
</ul>
<div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between">
<span class="text-h3 font-bold text-gosign-accent-on-dark">85% vollautomatisch</span>
<span class="text-small text-gosign-accent-on-dark font-semibold">Beratung im Detail &rarr;</span>
</div>
</a>

<!-- Logistik -->
<a href="/de/leistungen/travel-decision-layer/logistik/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors">
<div class="flex items-center justify-between mb-4">
<h3 class="text-h3 font-bold text-white">Logistik</h3>
<div class="flex gap-1">
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-white/20"></span>
</div>
</div>
<ul class="space-y-1.5 text-small text-gosign-text-on-dark/70">
<li>20.000+ Fahrer, EU-Mobilitätspaket</li>
<li>GPS-basierte Ländererkennung</li>
<li>Flottenbasierte Fahrer-Pauschalen</li>
</ul>
<div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between">
<span class="text-h3 font-bold text-gosign-accent-on-dark">95% vollautomatisch</span>
<span class="text-small text-gosign-accent-on-dark font-semibold">Logistik im Detail &rarr;</span>
</div>
</a>

<!-- Vertrieb -->
<a href="/de/leistungen/travel-decision-layer/vertrieb/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors">
<div class="flex items-center justify-between mb-4">
<h3 class="text-h3 font-bold text-white">Vertrieb</h3>
<div class="flex gap-1">
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-white/20"></span><span class="w-3 h-1.5 rounded-sm bg-white/20"></span>
</div>
</div>
<ul class="space-y-1.5 text-small text-gosign-text-on-dark/70">
<li>5.000+ Außendienst, CRM-Integration</li>
<li>10.000+ Vorgänge pro Monat</li>
<li>Policy-Durchsetzung im Volumen</li>
</ul>
<div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between">
<span class="text-h3 font-bold text-gosign-accent-on-dark">90% vollautomatisch</span>
<span class="text-small text-gosign-accent-on-dark font-semibold">Vertrieb im Detail &rarr;</span>
</div>
</a>
</div>
</div>
</section>

<!-- Architektur, Implementierung & Hebel -->
<section id="implementation" class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Implementierung</p>
<h2 class="text-h1 font-bold text-gosign-dark">Vom Piloten zum laufenden System.</h2>

<div class="grid grid-cols-1 lg:grid-cols-2 gap-10 mt-10">
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Technische Architektur</h3>
<p class="text-body text-gosign-text">Der Travel Decision Layer läuft vollständig in Ihrer Infrastruktur: Ihr Rechenzentrum, Ihr Netzwerk, Ihre Hoheit. Keine SaaS-Abhängigkeit, keine Datenabflüsse, kein externes Telemetrie-Tracking. Containerisiert, mandantenfähig, deployment-fertig für Ihre Private Cloud oder als Managed Deployment in EU-Rechenzentren.</p>
<div class="flex flex-wrap gap-4 mt-3">
<a href="/de/leistungen/infrastruktur/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infrastruktur im Detail &rarr;</a>
<a href="/de/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Decision Layer Architektur &rarr;</a>
<a href="/de/leistungen/hr-agent/payroll-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Payroll Decision Layer &rarr;</a>
</div>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Implementierung</h3>
<p class="text-body text-gosign-text">Der Decision Layer wird nicht installiert, sondern konfiguriert: Ihre Tarifverträge, Ihre Policies, Ihre Systemlandschaft. Typische Pilotprojekte starten innerhalb von 3 Monaten mit einer Branche und einem Tarifvertrag. Erweiterungen auf weitere Personalgruppen oder Systemanbindungen laufen parallel zum Pilotbetrieb.</p>
</div>
</div>

<h3 class="text-h3 font-bold text-gosign-dark mt-12 mb-6">Ökonomischer Hebel</h3>
<div class="grid grid-cols-1 sm:grid-cols-2 gap-6">
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-4">
<svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12l2 2 4-4m5.618-4.016A11.955 11.955 0 0112 2.944a11.955 11.955 0 01-8.618 3.04A12.02 12.02 0 003 9c0 5.591 3.824 10.29 9 11.622 5.176-1.332 9-6.03 9-11.622 0-1.042-.133-2.052-.382-3.016z" />
</svg>
<div>
<p class="text-body font-semibold text-gosign-dark">Systematische Regelprüfung statt Stichproben</p>
<p class="text-small text-gosign-text-light mt-2">Jeder Vorgang durchläuft dasselbe Regelwerk. Abweichungen werden erkannt und dokumentiert, nicht erst bei der Quartalsabstimmung.</p>
</div>
</div>
</div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-4">
<svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M13 10V3L4 14h7v7l9-11h-7z" />
</svg>
<div>
<p class="text-body font-semibold text-gosign-dark">Keine Freigabe-Workflows für Standardfälle</p>
<p class="text-small text-gosign-text-light mt-2">Durchlaufzeit von Tagen auf Minuten. Vorgesetzte genehmigen nur Ausnahmen.</p>
</div>
</div>
</div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-4">
<svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M4 6a2 2 0 012-2h2a2 2 0 012 2v2a2 2 0 01-2 2H6a2 2 0 01-2-2V6zm10 0a2 2 0 012-2h2a2 2 0 012 2v2a2 2 0 01-2 2h-2a2 2 0 01-2-2V6zM4 16a2 2 0 012-2h2a2 2 0 012 2v2a2 2 0 01-2 2H6a2 2 0 01-2-2v-2zm10 0a2 2 0 012-2h2a2 2 0 012 2v2a2 2 0 01-2 2h-2a2 2 0 01-2-2v-2z" />
</svg>
<div>
<p class="text-body font-semibold text-gosign-dark">Automatische Kostenstellen- und Projektzuordnung</p>
<p class="text-small text-gosign-text-light mt-2">Kein manuelles Mapping für tausende Vorgänge. Kein Monatsend-Engpass.</p>
</div>
</div>
</div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-4">
<svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12h6m-6 4h6m2 5H7a2 2 0 01-2-2V5a2 2 0 012-2h5.586a1 1 0 01.707.293l5.414 5.414a1 1 0 01.293.707V19a2 2 0 01-2 2z" />
</svg>
<div>
<p class="text-body font-semibold text-gosign-dark">Prüfungssichere Entscheidungsakten im Prozess erzeugt</p>
<p class="text-small text-gosign-text-light mt-2">Betriebsprüfung ist ein Export, kein Rechercheprojekt. Wochen werden Minuten.</p>
</div>
</div>
</div>
</div>
</div>
</section>

<!-- Compliance & Security -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Sicherheit</p>
<h2 class="text-h1 font-bold text-gosign-dark">Enterprise-Security. Von Tag eins.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Nicht als Feature nachgerüstet, sondern als Architekturprinzip gebaut. Der Travel Decision Layer ist für regulierte Umgebungen konzipiert, in denen Datenschutz, Audit-Readiness und Nachvollziehbarkeit keine optionalen Extras sind.</p>
<div class="mt-10">
<div class="grid grid-cols-1 md:grid-cols-3 gap-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">100% Kunden-Infrastruktur</h3>
<p class="text-body text-gosign-text-light mt-2">Der Decision Layer läuft vollständig in Ihrem Netzwerk. Keine SaaS-Abhängigkeit, kein Datenabfluss, kein externes Telemetrie-Tracking. Secrets in Ihrem KMS, Logs in Ihrem SIEM, SSO über Ihren Identity Provider.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">DSGVO by Design</h3>
<p class="text-body text-gosign-text-light mt-2">Anonymisierung statt Löschung. Kompatibel mit steuerlichen Aufbewahrungsfristen (10 Jahre, AO &sect;147) und DSGVO Art. 17. Kein Widerspruch zwischen Steuerrecht und Datenschutz.</p>
<a href="/de/governance/data-residency/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover mt-3 inline-block whitespace-nowrap">Datenresidenz im Detail</a>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">AI Act-konform</h3>
<p class="text-body text-gosign-text-light mt-2">Klare Architektur-Trennung: LLM für Datenextraktion, Decision Layer für Entscheidungen. Keine Black Box über steuerliche Sachverhalte. Jede Entscheidung rekonstruierbar.</p>
<a href="/de/governance/eu-ai-act/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover mt-3 inline-block whitespace-nowrap">EU AI Act Readiness</a>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Audit Trail (append-only)</h3>
<p class="text-body text-gosign-text-light mt-2">Signierte Entscheidungsakten. Input-Hash plus Regelversion ergibt reproduzierbares Ergebnis. Versiegelte Audit-Pakete (JSON + PDF, SHA-256). Betriebsprüfung jederzeit.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">ISO 27001 / PS 951 cert-ready</h3>
<p class="text-body text-gosign-text-light mt-2">Integrierte Controls Registry, automatisierte Evidence Runs, versionierte Policies. Compliance im laufenden Betrieb, nicht nachträglich dokumentiert.</p>
<a href="/de/governance/cert-ready/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover mt-3 inline-block whitespace-nowrap">Cert-Ready by Design</a>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">SSO & Mandantentrennung</h3>
<p class="text-body text-gosign-text-light mt-2">Integration in bestehende Identity Provider. Mandantentrennung auf Datenbankebene (Row Level Security). Rollenmodell granular konfigurierbar.</p>
</div>
</div>
</div>
</div>
</section>

<!-- Vertiefung -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Vertiefung im Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Unsere Fachartikel-Serie für Entscheider, die AI Agents im Unternehmen einführen.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/de/magazin/decision-layer-erklaert/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Grundlagen</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - Was ist das und warum braucht jeder Enterprise AI Agent einen?</p>
</a>
<a href="/de/magazin/betriebsrat-ki-mitbestimmung/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Mitbestimmung</p>
<p class="text-body font-semibold text-gosign-dark">Betriebsrat und KI - Mitbestimmung als Architektur-Constraint</p>
</a>
<a href="/de/magazin/cert-ready-by-design/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Audit</p>
<p class="text-body font-semibold text-gosign-dark">Cert-Ready by Design - Prüfungssichere KI von Anfang an</p>
</a>
<a href="/de/magazin/entscheidungsakt-anfechtbare-ki-entscheidungen/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Entscheidungsakt - warum jede KI-Entscheidung anfechtbar sein muss</p>
</a>
</div>
</div>
</section>

--- Leistungen ---
> AI-Agenten, Finance Agents, HR Agents, KI-Infrastruktur, Document Intelligence und eIDAS-konforme Signaturen.

<!-- Was wir bauen -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Was wir bauen</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Gosign entwickelt und betreibt AI-Agenten-Infrastruktur für Unternehmen. Wir bauen die Schicht zwischen Sprachmodell und Enterprise-System - inklusive Orchestrierung, Governance und Audit.
</p>
</div>
</div>
</section>

<!-- Leistungen Cards -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-1 lg:grid-cols-3 gap-6 lg:gap-8">
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9.813 15.904L9 18.75l-.813-2.846a4.5 4.5 0 00-3.09-3.09L2.25 12l2.846-.813a4.5 4.5 0 003.09-3.09L9 5.25l.813 2.846a4.5 4.5 0 003.09 3.09L15.75 12l-2.846.813a4.5 4.5 0 00-3.09 3.09zM18.259 8.715L18 9.75l-.259-1.035a3.375 3.375 0 00-2.455-2.456L14.25 6l1.036-.259a3.375 3.375 0 002.455-2.456L18 2.25l.259 1.035a3.375 3.375 0 002.455 2.456L21.75 6l-1.036.259a3.375 3.375 0 00-2.455 2.456zM16.894 20.567L16.5 21.75l-.394-1.183a2.25 2.25 0 00-1.423-1.423L13.5 18.75l1.183-.394a2.25 2.25 0 001.423-1.423l.394-1.183.394 1.183a2.25 2.25 0 001.423 1.423l1.183.394-1.183.394a2.25 2.25 0 00-1.423 1.423z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">AI-Agenten</h3>
<p class="text-body text-gosign-text-light mt-3">Document Agents, Workflow Agents, Knowledge Agents. Spezialisierte AI-Agenten die Dokumente lesen, Prozesse orchestrieren und kontextbasierte Antworten aus Unternehmenswissen liefern. Jeder Agent arbeitet innerhalb eines Decision Layer.</p>
<a href="/de/leistungen/ai-agents/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">AI-Agenten im Detail<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg></a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 18.75a60.07 60.07 0 0115.797 2.101c.727.198 1.453-.342 1.453-1.096V18.75M3.75 4.5v.75A.75.75 0 013 6h-.75m0 0v-.375c0-.621.504-1.125 1.125-1.125H20.25M2.25 6v9m18-10.5v.75c0 .414.336.75.75.75h.75m-1.5-1.5h.375c.621 0 1.125.504 1.125 1.125v9.75c0 .621-.504 1.125-1.125 1.125h-.375m1.5-1.5H21a.75.75 0 00-.75.75v.75m0 0H3.75m0 0h-.375a1.125 1.125 0 01-1.125-1.125V15m1.5 1.5v-.75A.75.75 0 003 15h-.75M15 10.5a3 3 0 11-6 0 3 3 0 016 0zm3 0h.008v.008H18V10.5zm-12 0h.008v.008H6V10.5z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Finance Agents</h3>
<p class="text-body text-gosign-text-light mt-3">Decision Automation für Belegverarbeitung und Buchführung. Automatisierte Verarbeitung von Eingangsbelegen bis zur prüfungssicheren Buchung. Cert-Ready by Design. DATEV- und SAP-Integration.</p>
<a href="/de/finance-ai-agents/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">Finance Agents<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg></a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M15 19.128a9.38 9.38 0 002.625.372 9.337 9.337 0 004.121-.952 4.125 4.125 0 00-7.533-2.493M15 19.128v-.003c0-1.113-.285-2.16-.786-3.07M15 19.128v.106A12.318 12.318 0 018.624 21c-2.331 0-4.512-.645-6.374-1.766l-.001-.109a6.375 6.375 0 0111.964-3.07M12 6.375a3.375 3.375 0 11-6.75 0 3.375 3.375 0 016.75 0zm8.25 2.25a2.625 2.625 0 11-5.25 0 2.625 2.625 0 015.25 0z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">HR Agents</h3>
<p class="text-body text-gosign-text-light mt-3">AI-Agenten für HR & People Operations. Enterprise AI-Agenten für konsistente, nachvollziehbare, prüfungssichere HR-Entscheidungen. Betriebsratsfähig. Decision Layer mit Human-in-the-Loop.</p>
<a href="/de/hr-ai-agents/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">HR Agents<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg></a>
</article>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-1 lg:grid-cols-3 gap-6 lg:gap-8">
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M5.25 14.25h13.5m-13.5 0a3 3 0 01-3-3m3 3a3 3 0 100 6h13.5a3 3 0 100-6m-16.5-3a3 3 0 013-3h13.5a3 3 0 013 3m-19.5 0a4.5 4.5 0 01.9-2.7L5.737 5.1a3.375 3.375 0 012.7-1.35h7.126c1.062 0 2.062.5 2.7 1.35l2.587 3.45a4.5 4.5 0 01.9 2.7m0 0a3 3 0 01-3 3m0 3h.008v.008h-.008v-.008zm0-6h.008v.008h-.008v-.008zm-3 6h.008v.008h-.008v-.008zm0-6h.008v.008h-.008v-.008z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">AI Infrastructure</h3>
<p class="text-body text-gosign-text-light mt-3">LLM Hosting, RAG, Orchestrierung, Self-Hosted. Die Produktionsplattform für AI-Agenten. Modell-agnostisch, deployment-flexibel, governance-ready. Azure, GCP, Self-Hosted oder Hybrid.</p>
<a href="/de/leistungen/infrastruktur/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">AI Infrastructure<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg></a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M19.5 14.25v-2.625a3.375 3.375 0 00-3.375-3.375h-1.5A1.125 1.125 0 0113.5 7.125v-1.5a3.375 3.375 0 00-3.375-3.375H8.25m0 12.75h7.5m-7.5 3H12M10.5 2.25H5.625c-.621 0-1.125.504-1.125 1.125v17.25c0 .621.504 1.125 1.125 1.125h12.75c.621 0 1.125-.504 1.125-1.125V11.25a9 9 0 00-9-9z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Document Intelligence</h3>
<p class="text-body text-gosign-text-light mt-3">Dokumentenverarbeitung jenseits von OCR. Klassifikation, Extraktion, Validierung - angetrieben durch LLM, gesteuert durch den Decision Layer. Für Rechnungen, Verträge, Bescheinigungen und unstrukturierte Dokumente.</p>
<a href="/de/leistungen/document-intelligence/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">Document Intelligence<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg></a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 6.75V15m6-6v8.25m.503 3.498l4.875-2.437c.381-.19.622-.58.622-1.006V4.82c0-.836-.88-1.38-1.628-1.006l-3.869 1.934c-.317.159-.69.159-1.006 0L9.503 3.252a1.125 1.125 0 00-1.006 0L3.622 5.689C3.24 5.88 3 6.27 3 6.695V19.18c0 .836.88 1.38 1.628 1.006l3.869-1.934c.317-.159.69-.159 1.006 0l4.994 2.497c.317.158.69.158 1.006 0z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Travel Decision Layer</h3>
<p class="text-body text-gosign-text-light mt-3">AI-gestützte Reisekosten-Governance. Der Decision Layer zerlegt jeden Reisekostenvorgang in Entscheidungsschritte und wendet deutsches Steuerrecht, Tarifverträge und BMF-Pauschalen deterministisch an.</p>
<a href="/de/leistungen/travel-decision-layer/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">Travel Decision Layer<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg></a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M17.25 6.75L22.5 12l-5.25 5.25m-10.5 0L1.5 12l5.25-5.25m7.5-3l-4.5 16.5" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Enterprise Software Engineering</h3>
<p class="text-body text-gosign-text-light mt-3">Seit 2001. Über 5.000 Projekte. 25 Jahre Enterprise-Softwareentwicklung für Airbus, Volkswagen, Shell. Heute AI-Infrastruktur - gebaut auf dem gleichen Engineering-Fundament.</p>
<a href="/de/leistungen/softwareentwicklung/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">Software Engineering<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg></a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M16.5 10.5V6.75a4.5 4.5 0 10-9 0v3.75m-.75 11.25h10.5a2.25 2.25 0 002.25-2.25v-6.75a2.25 2.25 0 00-2.25-2.25H6.75a2.25 2.25 0 00-2.25 2.25v6.75a2.25 2.25 0 002.25 2.25z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">eIDAS-konforme digitale Signaturen</h3>
<p class="text-body text-gosign-text-light mt-3">In Zusammenarbeit mit ETSI-zertifizierten Partnern. eIDAS-konforme digitale Signaturlösungen für Enterprise-Kunden. Einfache, fortgeschrittene (AES) und qualifizierte (QES) elektronische Signaturen.</p>
<a href="/de/leistungen/eidas-signaturen/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">eIDAS Signaturen<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg></a>
</article>
</div>
</div>
</section>

<!-- Wie wir arbeiten -->

<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark text-center">Wie wir arbeiten</h2>
<div class="mt-12 grid grid-cols-1 md:grid-cols-3 gap-8 relative">
<div class="text-center">
<div class="w-14 h-14 mx-auto rounded-full bg-gosign-accent flex items-center justify-center">
<span class="text-h3 font-bold text-white">1</span>
</div>
<h3 class="text-h3 font-bold text-gosign-dark mt-4">Discover</h3>
<p class="text-small font-semibold text-gosign-accent-text mt-1">1 Woche</p>
<p class="text-body text-gosign-text-light mt-2">Prozessanalyse, Regelwerke verstehen, Use Cases priorisieren.</p>
</div>
<div class="text-center">
<div class="w-14 h-14 mx-auto rounded-full bg-gosign-accent flex items-center justify-center">
<span class="text-h3 font-bold text-white">2</span>
</div>
<h3 class="text-h3 font-bold text-gosign-dark mt-4">Build</h3>
<p class="text-small font-semibold text-gosign-accent-text mt-1">3-4 Wochen</p>
<p class="text-body text-gosign-text-light mt-2">Produktiver PoC. Ein Agent, ein Prozess, live in Ihrer Infrastruktur.</p>
</div>
<div class="text-center">
<div class="w-14 h-14 mx-auto rounded-full bg-gosign-accent flex items-center justify-center">
<span class="text-h3 font-bold text-white">3</span>
</div>
<h3 class="text-h3 font-bold text-gosign-dark mt-4">Scale</h3>
<p class="text-small font-semibold text-gosign-accent-text mt-1">Kontinuierlich</p>
<p class="text-body text-gosign-text-light mt-2">Weitere Agenten, weitere Prozesse. Gleiche Governance, gleiche Auditierbarkeit.</p>
</div>
</div>
<p class="text-body-lg text-center text-gosign-text-light mt-8 max-w-narrow mx-auto">Nach 12-18 Monaten betreiben Sie Ihre Agenten eigenständig. Voller Zugang zu Quellcode, Prompts und Regelwerken. Kein Vendor Lock-in.</p>
</div>
</section>


<!-- Vertiefung -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Vertiefung im Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Unsere Fachartikel-Serie für Entscheider, die AI Agents im Unternehmen einführen.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/de/magazin/was-sind-ki-agenten/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">AI Agents</p>
<p class="text-body font-semibold text-gosign-dark">Was sind KI-Agenten? Document Agents, Workflow Agents, Knowledge Agents erklärt</p>
</a>
<a href="/de/magazin/decision-layer-erklaert/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - Was ist das und warum braucht jeder Enterprise AI Agent einen?</p>
</a>
<a href="/de/magazin/warum-ki-projekte-scheitern/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Strategie</p>
<p class="text-body font-semibold text-gosign-dark">Warum KI-Projekte in HR scheitern</p>
</a>
</div>
</div>
</section>

--- Agent Governance HR - Warum der CHRO führen muss ---
> Agent Governance ist kein IT-Thema. HR entscheidet über Regelwerke, Bias-Definition und Eskalationsschwellen. Der CHRO muss führen.

## Der Betriebsrat fragt, und niemand aus HR kann antworten

Ein Unternehmen mit 1.200 Mitarbeitenden führt einen KI-Agenten für die Vorauswahl von Bewerbungen ein. Die IT hat das Projekt umgesetzt: Monitoring steht, Audit Trail läuft, Konfidenzwerte werden geloggt. Dann kommt der Betriebsrat zur Verhandlung über die KI-Betriebsvereinbarung und stellt drei Fragen: Ab welchem Konfidenzwert wird ein Mensch hinzugezogen? Welche Bewerbergruppen erhalten besonderen Schutz? Wer hat die Eskalationsschwellen definiert?

Die IT kann die technischen Parameter nennen. Aber die fachliche Begründung - warum diese Schwellenwerte, warum diese Gruppen, warum diese Eskalationspfade - kann niemand liefern. Weil niemand aus HR sie definiert hat.

Genau das passiert gerade in Hunderten deutschen Unternehmen. Laut Bitkom (2025) setzen 36 Prozent der Unternehmen ab 20 Beschäftigten KI ein, weitere 47 Prozent planen oder diskutieren den Einsatz. Gleichzeitig zeigt der SHRM State of AI in HR Report (2026): In 52 Prozent der Organisationen ist HR bei der KI-Strategie nicht direkt eingebunden. Die Governance-Regeln für KI-Agenten im Personalbereich werden von IT und Legal geschrieben - ohne den Fachbereich, der die fachlichen Konsequenzen tragen muss.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Auf einen Blick - Agent Governance für HR</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Agent Governance definiert, welche Entscheidungen KI-Agenten treffen dürfen, wie Aktionen dokumentiert werden und wer Regelwerke freigibt. Nur HR kann die fachlichen Schwellenwerte setzen - die IT implementiert sie.</li>
<li>SHRM (2026): 52 % der Organisationen binden HR nicht direkt in die KI-Strategie ein. Governance bleibt bei IT und Legal - ohne fachliche Steuerung.</li>
<li>Gartner (2025): Nur 19 % der HR-Verantwortlichen setzten vor zwei Jahren KI ein - Mitte 2025 waren es bereits 61 %. Die Governance hinkt der Adoption hinterher.</li>
<li>Der EU AI Act stuft KI-Systeme für Beschäftigungsentscheidungen als Hochrisiko ein. Die Pflichten zu menschlicher Aufsicht, Bias-Monitoring und Arbeitnehmerinformation gelten nach aktuellem Recht ab dem 2. August 2026 - Verschiebung auf Dezember 2027 vorläufig geeinigt (Digital Omnibus, Mai 2026).</li>
<li>Wer jetzt startet: KI-Nutzung inventarisieren, Governance-Ownership in HR verankern, Betriebsrat mit konkreter Entscheidungsmatrix einbinden - bevor der erste Agent produktiv geht.</li>
</ul>
</div>

## IT baut Kontrollen - aber HR muss die Regeln definieren

Der Reflex ist verständlich: KI ist Technologie, also gehört Governance in die IT. Die IT kann Audit Trails implementieren, Konfidenzwerte messen, Rollout-Prozesse steuern. Was sie nicht kann: entscheiden, welche Regeln der Agent anwenden soll.

Bei einem KI-Agenten für HR-Prozesse sind das keine technischen Fragen. Das sind Fachfragen:

| Governance-Frage | Warum nur HR sie beantworten kann |
|------------------|-----------------------------------|
| Welche Entscheidungen darf der Agent autonom treffen? | Erfordert Kenntnis von Arbeitsrecht, Tarifvertrag und betrieblicher Praxis |
| Ab welchem Risiko muss ein Mensch eingreifen? | "Risiko" bei Vergütung bedeutet etwas anderes als "Risiko" im Recruiting |
| Was ist Bias bei Leistungsbeurteilungen? | Statistische Abweichung allein sagt nichts - HR kennt den fachlichen Kontext |
| Welche Mitarbeitergruppen brauchen besonderen Schutz? | Schwerbehinderte, Betriebsräte, Elternzeitler - das sind HR-Schutzklassen, keine Datenkategorien |
| Wer gibt Regeländerungen frei? | Tarifvertragsänderungen und neue Betriebsvereinbarungen müssen fachlich bewertet werden |

Der SHRM-Report (2026) zeigt das Problem in Zahlen: 37 Prozent der befragten HR-Verantwortlichen geben an, dass Legal und Compliance die KI-Governance führen. Nur bei einem einzigen Thema - Upskilling und Reskilling - war HR mit 28 Prozent annähernd federführend. Selbst dort lagen funktionsübergreifende Taskforces mit 29 Prozent knapp vorn.

Das Muster ist überall dasselbe: HR nutzt die Agenten, aber andere definieren die Spielregeln.

## Ohne HR-Ownership entstehen drei konkrete Governance-Lücken

Wenn der CHRO Agent Governance an die IT delegiert, ist das kein theoretisches Risiko. Es produziert drei messbare Lücken:

**Lücke 1: Eskalationsschwellen ohne fachliche Begründung.** Die IT setzt Eskalationen nach technischen Metriken - Konfidenzwerte, Error Rates, Response Times. Ob eine Vergütungsentscheidung mit 87 Prozent Konfidenz automatisch durchlaufen darf oder ob bei bestimmten Gehaltsgruppen grundsätzlich ein Mensch prüfen muss - das kann kein Konfidenzwert beantworten. Das ist eine personalwirtschaftliche Entscheidung.

**Lücke 2: Bias-Monitoring ohne Kontext.** Eine statistische Abweichung von 3 Prozent bei der Genehmigung von Weiterbildungsanträgen - ist das ein Problem? Wenn die Abweichung zwischen Vollzeit und Teilzeit besteht und Teilzeitkräfte überwiegend Frauen sind: ja, möglicherweise. Wenn sie zwischen zwei Standorten besteht und einer ein anderes Weiterbildungsbudget hat: nein. Ohne HR-Expertise ist Bias-Monitoring eine Tabelle mit Zahlen, die niemand interpretieren kann.

**Lücke 3: Regelwerke als technische Konfiguration.** Wenn Tarifvertragsänderungen, neue Betriebsvereinbarungen oder geänderte Unternehmensrichtlinien als Config-Updates in der IT landen, fehlt die fachliche Validierung. Regeländerungen werden deployed, ohne dass jemand aus HR geprüft hat, ob die Umsetzung dem fachlichen Intent entspricht.

## Der EU AI Act macht HR-Ownership zur Pflicht

KI-Systeme, die Beschäftigungsentscheidungen beeinflussen, werden vom EU AI Act als Hochrisiko-Systeme eingestuft (Annex III, Abschnitt 4) - das betrifft Recruiting, Beförderungen, Vergütung, Kündigungen, Leistungsbeurteilungen und Aufgabenverteilung. Die zugehörigen Pflichten greifen nach aktuellem Recht ab dem 2. August 2026; nach der vorläufigen Digital-Omnibus-Einigung vom 7. Mai 2026 sollen sie sich auf den 2. Dezember 2027 verschieben (formale Verabschiedung ausstehend). Die Einstufung als Hochrisiko bleibt in beiden Fällen bestehen und verschärft die Anforderungen an HR-Governance erheblich.

Die Pflichten sind konkret:

Menschliche Aufsicht durch Personen mit "angemessener Kompetenz, Ausbildung und Autorität". Das sind keine IT-Administratoren. Das sind HR-Fachleute, die den fachlichen Kontext der Entscheidungen verstehen.

Bias-Monitoring mit dokumentierten Metriken und Reaktionsprozessen. Wer die Metriken definiert, bestimmt, was als Bias gilt und was nicht. Wenn die IT diese Definition übernimmt, orientiert sie sich an statistischer Signifikanz - nicht an arbeitsrechtlicher Relevanz.

Information der Arbeitnehmer und ihrer Vertreter vor der Einführung. Im deutschen Kontext: Der Betriebsrat hat nach § 87 Abs. 1 Nr. 6 BetrVG Mitbestimmungsrechte bei technischen Einrichtungen, die geeignet sind, das Verhalten oder die Leistung der Arbeitnehmer zu überwachen. Eine KI-Betriebsvereinbarung ist faktisch Pflicht - und der Betriebsrat erwartet fachliche Ansprechpartner, nicht IT-Projektleiter.

Gartner (2025) dokumentiert die Dynamik: Vor zwei Jahren implementierten 19 Prozent der HR-Verantwortlichen KI-Lösungen. Mitte 2025 waren es 61 Prozent. 92 Prozent pilotieren oder implementieren KI innerhalb ihrer Funktion. Die Governance muss mit dieser Geschwindigkeit Schritt halten.

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Kostenloses eBook: KI in HR</p>
<p class="text-body text-gosign-text mb-4">EU AI Act Checkliste, Decision-Framework, Betriebsrats-Perspektive und Readiness-Assessment - das Governance-Handbuch für HR-Verantwortliche.</p>
<a href="/de/ebook/ki-hr-governance-handbuch/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Jetzt kostenlos herunterladen</a>
</div>

## Fünf Governance-Aufgaben, die nur der CHRO übernehmen kann

Der CHRO muss Agent Governance nicht technisch umsetzen. Er muss die fachlichen Leitplanken setzen, die dann im [Decision Layer](/de/decision-layer/) implementiert werden - der Architektur, die jeden Prozess in Entscheidungsschritte zerlegt und für jeden Schritt definiert: Mensch, Regelwerk oder KI.

**Regelwerk-Ownership.** Tarifverträge, Betriebsvereinbarungen, interne Richtlinien - HR ist verantwortlich für die Richtigkeit und Aktualität der Regeln, die der Agent anwendet. Jede Änderung an diesen Regeln wird von HR freigegeben, nicht von der IT deployed.

**Eskalationsmatrix.** HR definiert die fachlichen Schwellenwerte: Welche Entscheidungstypen autonom, welche mit menschlicher Prüfung, welche manuell. Das ist keine technische Entscheidung über Konfidenzwerte - es ist eine Entscheidung über Risikotoleranz pro Entscheidungstyp.

**Bias-Strategie.** HR legt fest, welche Gruppen verglichen werden, was eine relevante Abweichung ist und welche Reaktionsprozesse greifen. Das Monitoring selbst implementiert die IT. Aber die Definition von "fair" ist eine HR-Aufgabe.

**Betriebsratsarbeit.** Die KI-Betriebsvereinbarung ist das zentrale Governance-Dokument im deutschen Kontext. HR führt die Verhandlung, definiert die Entscheidungsmatrix für den Betriebsrat und stellt sicher, dass dessen Anforderungen als Controls im System implementiert werden.

**Governance-Reporting.** HR erhält und interpretiert die Governance-Reports aus dem Auditor Portal. Nicht als technisches Monitoring, sondern als fachliche Qualitätssicherung: Arbeitet der Agent im Rahmen der vereinbarten Regeln?

Gosign baut die Governance-Infrastruktur für HR-Agenten - Decision Layer, Audit Trail, Betriebsrats-Templates - damit HR die fachliche Steuerung übernehmen kann, ohne selbst Systeme konfigurieren zu müssen. Mehr dazu: [HR AI Agents](/de/hr-ai-agents/)

## Wer jetzt nicht startet, verhandelt später unter Druck

Die Richtung ist klar: Die Hochrisiko-Pflichten des EU AI Act greifen nach aktuellem Recht ab dem 2. August 2026, voraussichtlich verschoben auf Dezember 2027 (Digital Omnibus, Mai 2026, formale Verabschiedung ausstehend). Wer KI-Agenten in HR-Prozessen betreibt, braucht dokumentierte Governance - menschliche Aufsicht, Bias-Monitoring, Arbeitnehmerinformation. Wer das erst unter Zeitdruck aufbaut, verhandelt eine KI-Betriebsvereinbarung aus der Defensive; die voraussichtlich gewonnene Zeit sollte zur Vorbereitung genutzt werden.

Drei Schritte, die jetzt funktionieren:

Erstens: KI-Nutzung inventarisieren. ISACA (2024) zeigt, dass nur 15 Prozent der Organisationen eine formale KI-Policy haben - bei 70 Prozent, die KI am Arbeitsplatz nutzen. Die Lücke zwischen Nutzung und Governance ist in den meisten Unternehmen größer, als die Geschäftsführung annimmt.

Zweitens: Governance-Ownership formal in HR verankern. Nicht als Nebenprojekt, sondern als definierte Verantwortung im CHRO-Bereich. Die BCG-Studie Creating People Advantage (2026) zeigt: 65 Prozent der Führungskräfte sehen HR als Business Enabler - aber 51 Prozent nennen administrative Überlastung als Haupthindernis für strategischen Beitrag. Governance-Ownership ist genau der strategische Hebel, der HR aus der administrativen Rolle hebt.

Drittens: Betriebsrat mit konkreter Entscheidungsmatrix einbinden. Nicht mit einem 80-Seiten-Rahmenvertrag beginnen, sondern mit einer tabellarischen Übersicht: Diese Entscheidungen trifft der Agent. Diese prüft ein Mensch. Diese bleiben vollständig manuell. Damit hat der Betriebsrat eine Verhandlungsbasis, die er versteht.

Wer diese drei Schritte frühzeitig abschließt - ob zur geltenden Frist im August 2026 oder zur voraussichtlich verschobenen Frist im Dezember 2027 - hat die Grundlage für eine KI-Betriebsvereinbarung, die der Betriebsrat unterschreiben kann, und eine Governance-Struktur, die den Anforderungen des EU AI Act standhält.

--- Agent-Orchestrierung: Plattformen im Vergleich 2026 ---
> Wo laufen Ihre AI-Agenten? Trigger.dev, n8n, Camunda, Temporal, Make und Activepieces im Enterprise-Vergleich. Mit Empfehlungslogik.

## Der Pilot läuft. Dann passiert: nichts.

Ihr Team hat einen KI-Agenten gebaut. Er klassifiziert eingehende Rechnungen, zieht Belege aus PDFs, schlägt Buchungskonten vor. Im Piloten funktioniert er. Dann sitzen Sie im Lenkungsausschuss und jemand fragt: "Und jetzt? Wie kommt das in die Produktion? Welche Plattform nehmen wir?" Die Diskussion dreht sich um n8n gegen Camunda, um Trigger.dev gegen Temporal, um Make gegen Activepieces. Nach zwei Stunden ist niemand schlauer.

Das Problem ist nicht, dass niemand die richtige Antwort weiß. Das Problem ist, dass Sie die falsche Frage diskutieren. Die Plattform ist selten der Grund, warum Agenten-Piloten in der Produktion scheitern. Camundas [State of Agentic Orchestration Report 2026](https://camunda.com/state-of-agentic-orchestration-and-automation/) (Befragung von 1.150 IT-Leitern und Software-Architekten) zeigt: 71 Prozent der Unternehmen setzen bereits KI-Agenten ein, aber nur 11 Prozent der Anwendungsfälle erreichten im letzten Jahr den produktiven Betrieb. 73 Prozent sagen, es gibt eine signifikante Lücke zwischen ihrer Vision für Agentic AI und der Realität. 80 Prozent der eingesetzten Agenten sind Chatbots oder Assistenten, die Fragen beantworten - keine Systeme, die mission-kritische Aufgaben übernehmen.

Dieser Artikel dreht die Frage um. Er vergleicht die sechs relevanten Orchestrierungsplattformen neutral. Und er zeigt, warum die Plattformwahl nur eine von acht Architekturentscheidungen ist - und warum wer sie isoliert trifft, am Ende Orchestrierung ohne Governance hat, ohne Decision Layer, ohne Audit Trail.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Auf einen Blick - Agent-Orchestrierung</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Nur 11 Prozent der Agent-Anwendungsfälle erreichten 2025 den produktiven Betrieb (Camunda State of Agentic Orchestration Report 2026, n=1.150). 73 Prozent der Unternehmen sehen eine signifikante Lücke zwischen Vision und Realität.</li>
<li>Gartner erwartet, dass über 40 Prozent aller Agentic-AI-Projekte bis Ende 2027 eingestellt werden - wegen eskalierender Kosten, unklarem Geschäftswert oder unzureichender Risikokontrolle.</li>
<li>Der Markt teilt sich in visuelle Workflow-Tools (n8n, Make, Activepieces) und Code-basierte Orchestrierungs-Engines (Trigger.dev, Temporal, Camunda). Beide Kategorien lösen unterschiedliche Probleme.</li>
<li>Fünf von sechs Plattformen unterstützen Self-Hosting. Make (reines SaaS) ist die Ausnahme.</li>
<li>Die Orchestrierungsplattform ist eine von acht Architekturentscheidungen. Sie ist notwendig, aber nicht hinreichend. Die anderen sieben entscheiden, ob der PoC den Sprung in die Produktion schafft.</li>
</ul>
</div>

## Der häufigste Ausfallgrund ist nicht die Plattform

Wenn 89 Prozent der Agent-Anwendungsfälle es nicht in die Produktion schaffen, lohnt sich die Frage, woran sie sterben. Drei unabhängige Datenquellen kommen zu demselben Befund - und keine davon nennt die Orchestrierungsplattform als primären Grund.

Camundas Befragung nennt die Ursachen direkt: 84 Prozent der Unternehmen sehen ein Geschäftsrisiko darin, KI in täglichen Prozessen einzusetzen, wenn die IT keine angemessene Kontrolle hat. 80 Prozent beklagen fehlende Transparenz darüber, wie KI in Geschäftsprozessen verwendet wird. 66 Prozent nennen Compliance-Bedenken. 48 Prozent geben zu, dass ihre Agenten isoliert laufen, nicht als Teil eines End-to-End-Prozesses.

Gartner kommt in der [Prognose vom Juni 2025](https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027) zum gleichen Ergebnis: Über 40 Prozent aller Agentic-AI-Projekte werden bis Ende 2027 eingestellt. Die Gründe, die Gartner nennt: eskalierende Kosten, unklarer Geschäftswert, unzureichende Risikokontrolle. Anushree Verma, Senior Director Analyst bei Gartner: "Die meisten Agentic-AI-Projekte sind derzeit Experimente oder PoCs im Frühstadium, getrieben von Hype und häufig falsch angewandt."

Die MIT NANDA-Studie "The GenAI Divide: State of AI in Business 2025" liefert einen zusätzlichen Befund: Von 300 analysierten öffentlichen AI-Deployments erreichten nur etwa fünf Prozent eine messbare Umsatzbeschleunigung. Die Studie nennt als Hauptursache nicht die Modellqualität, sondern die "Lernlücke" in der Enterprise-Integration. Interessant: Interne Eigenbauten scheitern rund dreimal häufiger als Lösungen, die mit spezialisierten Anbietern umgesetzt werden (Erfolgsquote 67 Prozent bei Vendor-Partnerschaften, rund 22 Prozent bei internen Builds).

Keine dieser drei Quellen identifiziert die Orchestrierungsplattform als Scheiterns-Ursache. Die Ursachen sind Governance, Kontrolle, Transparenz, Integration, fehlende Risikoarchitektur. Das sind keine Probleme, die sich lösen lassen, indem man Camunda gegen Trigger.dev austauscht.

## Die Plattform ist eine von acht Architekturentscheidungen

Wenn die Plattformwahl nicht das Kernproblem ist, was dann? Ein produktionsreifer KI-Agent braucht mindestens acht Architekturentscheidungen, die zusammenwirken müssen. Die Orchestrierungsplattform ist eine davon. Wer sie isoliert trifft, löst ein Achtel des Problems.

**1. Decision Layer.** An welchen Stellen im Prozess darf die KI autonom handeln? Wann greift ein Regelwerk? Wann muss ein Mensch freigeben? Ohne diese Zerlegung des Prozesses in Entscheidungsschritte (Mensch, Regel, KI) gibt es keine Kontrolle über das Systemverhalten. Camundas Befund: 80 Prozent der Unternehmen haben keine Transparenz darüber, wo und wie KI in ihren Prozessen entscheidet.

**2. Governance-Architektur.** Wer ist verantwortlich, wenn der Agent falsch entscheidet? Welche Rollen haben Freigabe- und Veto-Rechte? Wie wird der Betriebsrat eingebunden? Die Orchestrierungsplattform führt Workflows aus, aber sie definiert keine Verantwortung.

**3. Audit Trail.** Jede Entscheidung, die der Agent trifft, muss nachvollziehbar sein: Welcher Input, welches Modell, welche Confidence, welcher Output, welche menschliche Freigabe. Ohne lückenlose Protokollierung ist weder Fehleranalyse noch Compliance möglich. Das muss explizit gebaut werden - keine Plattform liefert es out of the box für Ihren konkreten Prozess.

**4. Systemintegration.** Der Agent muss lesen und schreiben können: ERP, DMS, E-Mail, CRM, Fachanwendung. Jede Integration ist Arbeit, jede Schnittstelle ein potenzieller Ausfallpunkt. Visuelle Tools bieten Konnektoren, Code-basierte Plattformen bieten Freiheit - beides hat Kosten.

**5. Modell-Routing.** Welches Sprachmodell wird für welchen Schritt verwendet? Kostengünstig für einfache Klassifikation, präzise für kritische Extraktion, spezialisiert für domänenspezifische Aufgaben? Modell-agnostische Architektur bedeutet: Das Modell kann getauscht werden, ohne den Workflow umzuschreiben.

**6. Human-in-the-Loop.** An welchen Stellen wird ein Mensch eingebunden? Wie bekommt er den Kontext? Wie schnell muss er entscheiden? Was passiert, wenn er nicht reagiert? Das ist Prozess- und UX-Design, nicht Plattformkonfiguration.

**7. Observability und Kostenkontrolle.** Was kostet der Agent pro Durchlauf? Welche Schritte sind am teuersten? Wo gibt es Retry-Schleifen, die Kosten explodieren lassen? Gartner nennt "eskalierende Kosten" als primären Grund für die erwarteten 40 Prozent Projektabbrüche bis 2027 - ohne Kostentransparenz schließt sich die Schere zwischen Nutzen und Aufwand erst, wenn es zu spät ist.

**8. Orchestrierungsplattform.** Die Schicht, die die anderen sieben Entscheidungen in ausführbaren Workflow übersetzt. Notwendig, aber nicht hinreichend.

Die Reihenfolge ist kein Zufall. Wer mit Punkt 8 beginnt, baut Workflows ohne Decision Layer, ohne Governance, ohne Audit Trail. Das Ergebnis: ein funktionierender Pilot und kein Weg in die Produktion - weil die Organisation nicht weiß, wer verantwortet, was der Agent tut, und ob sie ihm vertrauen darf.

## Der Markt teilt sich in zwei Welten

Wenn die Architekturentscheidungen getroffen sind und die Orchestrierungsplattform als Ausführungsschicht ausgewählt werden muss, teilt sich der Markt 2026 in zwei klar unterscheidbare Kategorien. Das Verständnis dieser Trennung ist die Grundlage jeder sinnvollen Auswahl.

### Visual Workflow Automation

Plattformen wie n8n, Make und Activepieces folgen demselben Prinzip: Workflows werden visuell zusammengeklickt. Ein Trigger (eingehende E-Mail, neues Dokument, Webhook) startet eine Kette von Aktionen. Jede Aktion ist ein Knoten: Daten lesen, ein KI-Modell aufrufen, eine E-Mail senden, einen Datensatz in ein ERP schreiben. Die Kette wird im visuellen Editor zusammengestellt, getestet, aktiviert.

Der Vorteil ist schnelle Ergebnisse und eine niedrige Einstiegshürde. Ein funktionierender Workflow kann in Tagen statt Wochen stehen. Fachabteilungen können ihn im Editor nachvollziehen und sogar selbst anpassen. KI-Modelle werden wie jeder andere Service eingebunden - ein Knoten unter vielen.

Der Nachteil tritt bei komplexen, langlebigen Prozessen auf. Parallele Pfade, bedingte Verzweigungen über mehrere Ebenen, Workflows die über Wochen laufen und zwischendurch auf menschliche Eingaben warten, versionierte Prozessdefinitionen mit vollständiger Änderungshistorie - das sind nicht die Stärken visueller Editoren. n8n-Workflows sind typischerweise als kurzlebige Ausführungen optimiert, bei denen ein Job startet, Schritte durchläuft und endet, oft innerhalb von Sekunden bis Minuten.

### Process Orchestration Engines

Plattformen wie Camunda, Temporal und Trigger.dev verfolgen einen anderen Ansatz. Bei Camunda werden Prozesse als formale BPMN-2.0-Diagramme modelliert - ein internationaler Standard, den Betriebsräte, Wirtschaftsprüfer und Fachabteilungen lesen können. Bei Temporal und Trigger.dev werden Workflows als Code geschrieben: Temporal in Go, Java, TypeScript oder Python, Trigger.dev in TypeScript.

Der gemeinsame Vorteil: Jeder Schritt ist versioniert und auditierbar. Menschliche Freigaben sind architektonischer Kernbestandteil, kein Workaround. Prozesse können über Wochen laufen, ohne dass die technische Integrität leidet. Das Konzept der Durable Execution bei Temporal und Trigger.dev stellt sicher, dass Workflows auch bei Serverausfällen, Netzwerkunterbrechungen oder Modell-Timeouts zuverlässig fortgesetzt werden - jede Ausführung wird als persistente Event-Historie gespeichert.

Der Nachteil: Höhere Einstiegshürde. Camunda erfordert BPMN-Kenntnisse und Erfahrung mit Process Engines. Temporal und Trigger.dev erfordern Entwickler, die Workflows in Code schreiben. Für einen schnellen Prototyp in der Fachabteilung ist das oft zu viel Aufwand.

Die Entscheidung zwischen diesen zwei Welten ist keine Frage von besser oder schlechter. Sie hängt ab von Prozesstyp, Compliance-Anforderungen, verfügbaren Entwicklerressourcen und davon, ob die Fachabteilung den Workflow selbst anpassen können soll.

## Sechs Plattformen im neutralen Vergleich

Die folgende Tabelle stellt die relevanten Plattformen gegenüber. Sie trifft keine Empfehlung, sie macht die Unterschiede sichtbar.

| Plattform | Typ | Self-Hosted | KI/LLM-Integration | Kernstärke | Lizenz |
|---|---|---|---|---|---|
| **n8n** | Visual Workflow | Ja (Docker, k8s) | AI-Nodes nativ, LangChain | 400+ Konnektoren, visueller Editor, schnelle Prototypen | Sustainable Use License (fair-code, interne Nutzung frei) |
| **Make** (ex Integromat) | Visual Workflow | Nein (SaaS only) | AI-Module | Einfachster Einstieg, intuitiv, guter Support | Proprietär (SaaS) |
| **Activepieces** | Visual Workflow | Ja (Docker) | AI-Pieces | Open-Source-Alternative, MIT-Lizenz | MIT |
| **Camunda** | BPMN Process Engine | Ja oder Cloud | Connectors für LLM-APIs, Custom Worker | BPMN 2.0, Human Tasks, Audit-Trail, Langzeitprozesse | Community (Apache 2.0) + Enterprise Edition |
| **Temporal** | Code-first (Multi-Language) | Ja (Docker, k8s) | LLM-Integration im Worker-Code | Durable Execution, Event History, hohe Zuverlässigkeit | MIT (Core) + Commercial (Cloud) |
| **Trigger.dev** | Code-first (TypeScript) | Ja (Docker, k8s) | LLM-Integration im Task-Code | Durable Execution, TypeScript-nativ, Developer-first | Apache 2.0 |

Drei Beobachtungen:

**Self-Hosting ist bei fünf von sechs Plattformen möglich.** Make ist die Ausnahme. Als reiner SaaS-Dienst verlassen die Workflow-Daten Ihr Netzwerk. Für Unternehmen mit Datensouveränitäts-Anforderungen scheidet Make damit aus, sobald sensible Daten im Spiel sind.

**Die Lizenzmodelle unterscheiden sich substanziell.** Activepieces (MIT), Trigger.dev (Apache 2.0) und Camunda Community Edition (Apache 2.0) bieten die größte Freiheit. Temporal ist im Kern MIT, die Cloud-Variante kommerziell. n8n nutzt die Sustainable Use License - eine fair-code-Lizenz, die interne Nutzung frei erlaubt, aber Wiederverkauf und Einbettung in kommerzielle Produkte einschränkt. Wer skalieren oder in eigene Produkte einbetten will, sollte die Lizenz vor der Entscheidung prüfen.

**Die KI-Integration ist überall möglich**, aber unterschiedlich tief. Die visuellen Plattformen bieten vorgefertigte AI-Nodes, die Sprachmodelle mit wenigen Klicks einbinden. Die Code-basierten Plattformen erfordern mehr Aufwand bei der Ersteinrichtung, bieten dafür aber volle Kontrolle über Prompt-Engineering, Retry-Logik, Kostensteuerung und Modell-Routing.

## Wann welche Plattform technisch Sinn ergibt

Die Zuordnung ist eine Frage des Szenarios, nicht der "besten" Plattform. Die folgenden Profile beschreiben, wann welche Kategorie technisch passt - ohne Aussage darüber, ob die Plattform allein den Produktionssprung schafft.

**Prototyping in Fachabteilungen, einfache sequenzielle Automatisierungen.** Visual Workflow Tools (n8n, Make, Activepieces) sind hier im Vorteil. Ein Fachanwender kann einen funktionierenden Workflow in Tagen aufsetzen. Die Ergebnisse sind sofort sichtbar und im Editor nachvollziehbar. Für interne Automatisierungen ohne Compliance-Anforderungen ist das der schnellste Weg.

**Compliance-pflichtige Kernprozesse mit Betriebsrat, Audit und Wirtschaftsprüfern.** BPMN 2.0 ist das Kommunikationsformat, das auch Nicht-Entwickler lesen können. Camunda modelliert Prozesse formal, Human Tasks sind Architekturkonzept, jede Prozessversion ist nachvollziehbar. Wenn externe Auditoren den Prozess lesen müssen, ist Camunda strukturell im Vorteil - nicht weil die anderen Plattformen unsicher wären, sondern weil BPMN das universelle Kommunikationsformat für solche Prozesse ist.

**Komplexe, langlebige Workflows mit unvorhersehbaren Laufzeiten.** Dokumentenanalyse mit Rückfragen, mehrstufige Validierungen, Batch-Verarbeitung über Stunden oder Tage - hier spielt Durable Execution ihre Stärke aus. Temporal ist sprachagnostisch und in Multi-Language-Teams stark. Trigger.dev ist die natürliche Wahl für reine TypeScript-Teams, die in derselben Sprache, IDE und CI/CD-Pipeline bleiben wollen wie der Rest ihres Stacks.

**Datensouveränität ist nicht verhandelbar.** Fünf der sechs Plattformen lassen sich im eigenen Rechenzentrum betreiben. Make fällt hier aus. Bei Trigger.dev, Temporal und Activepieces ist das Self-Hosting Teil der Standardarchitektur. Bei n8n gilt es zu prüfen, ob die Lizenz die geplante Nutzung erlaubt.

**Fachliche Anpassbarkeit durch Nicht-Entwickler.** Wenn die Fachabteilung den Workflow selbst ändern soll, scheiden Code-basierte Plattformen aus. Nur visuelle Editoren erlauben Anpassungen ohne Entwickler. Das ist ein Trade-off: Anpassbarkeit gegen Kontrolle über komplexe Ausführungslogik.

**Bestehende Sprach- und Tooling-Präferenz des Entwicklungsteams.** Go-Teams orchestrieren natürlich in Go (Temporal). Java-Teams in Java (Temporal, Camunda). TypeScript-Teams in TypeScript (Trigger.dev, Temporal TypeScript SDK). Die Passung zur bestehenden Toolchain spart Wochen an Einarbeitung.

## Was die Plattform nicht leistet - und was darum herum gebaut werden muss

Jede der sechs Plattformen führt Workflows zuverlässig aus. Keine der sechs liefert out of the box, was ein produktionsreifer Enterprise-Agent braucht. Das ist keine Schwäche der Plattformen - es ist die Rollenverteilung. Die Plattform ist die Ausführungsschicht. Alles darüber und darunter ist Architektur- und Integrationsarbeit.

Konkret fehlt jeder Plattform, die Sie auswählen, das Folgende und muss explizit gebaut oder von anderen Systemen geliefert werden:

**Die Decision-Layer-Logik** - die Zerlegung des Prozesses in Entscheidungsschritte mit klarer Zuordnung, ob eine Regel, ein Modell oder ein Mensch entscheidet. Das ist Prozessarbeit, nicht Plattformkonfiguration. Siehe [Decision Layer](/de/magazin/decision-layer-shadow-ai/).

**Der Audit Trail auf Entscheidungsebene** - nicht die technische Ausführungshistorie des Workflows (die liefern Trigger.dev, Temporal und Camunda nativ), sondern die fachliche Protokollierung: Welcher Input führte zu welcher Modellantwort mit welcher Confidence, wer hat freigegeben, welche Regel griff. Das muss entlang des Workflows explizit instrumentiert werden.

**Die Human-in-the-Loop-UX** - Oberflächen, in denen Menschen Kontext sehen und Entscheidungen treffen. Camunda Tasklist liefert eine generische Oberfläche, für ernsthafte Nutzung braucht es meist ein eigenes Frontend. Bei Code-basierten Plattformen muss die UX komplett gebaut werden.

**Die Governance-Struktur** - Rollen, Verantwortlichkeiten, Eskalationspfade, Betriebsrats-Einbindung. Das ist Organisationsarbeit. Keine Plattform hat eine Meinung darüber, wer freigeben darf.

**Die Kosten- und Observability-Schicht** - Transparenz darüber, was jeder Agent-Durchlauf kostet, wo Retry-Schleifen eskalieren, welche Modell-Aufrufe die teuersten sind. Ohne diese Schicht schlägt Gartners Prognose zu: eskalierende Kosten, die das Projekt killen.

**Die Systemintegration** - ERP, DMS, E-Mail, Fachsysteme. Konnektoren helfen, aber jede Integration muss getestet, produktionsreif gemacht und gepflegt werden.

Die MIT NANDA-Studie liefert dazu einen harten Datenpunkt: Interne Eigenbauten scheitern etwa dreimal häufiger als Lösungen, die mit spezialisierten Partnern entstehen. Die Studie nennt als Hauptursache die "Lernlücke" in der Enterprise-Integration. Gosign liefert diese Schicht als fertiges Framework - Decision Layer, Governance, Audit Trail und Orchestrierung als zusammenhängendes System, unabhängig von der konkret eingesetzten Plattform.

## Der nächste Schritt ist nicht die Plattformwahl

Wenn Sie jetzt im Lenkungsausschuss sitzen und die Plattform-Diskussion dreht sich seit zwei Stunden im Kreis, ist das der Moment, die Frage umzudrehen. Die richtige erste Frage ist nicht "welche Plattform". Die richtige erste Frage ist: "Welche Architekturentscheidungen haben wir für die anderen sieben Ebenen getroffen - Decision Layer, Governance, Audit Trail, Systemintegration, Modell-Routing, Human-in-the-Loop, Observability?" Wenn die Antwort "noch keine" ist, ist die Plattformwahl verfrüht.

Die neutrale Wahrheit über die sechs Plattformen ist: Jede von ihnen kann einen produktionsreifen Agenten ausführen. Keine von ihnen löst das Problem, dass 89 Prozent der Anwendungsfälle vor der Produktion scheitern. Dieses Problem wird gelöst durch eine vollständige Agenten-Architektur, in der die Orchestrierungsplattform nur die Ausführungsschicht ist - umgeben von Governance, Decision Layer und Audit Trail, die als zusammenhängendes System entstehen müssen.

Gosign baut diese Architektur als fertiges Framework. Welche Orchestrierungsplattform darin läuft, ist eine technische Entscheidung, die nach den Architekturfragen kommt - nicht davor. Wer mit der Plattform beginnt, baut Ausführung ohne Kontrolle. Wer mit der Architektur beginnt, baut einen Agenten, der den Sprung vom PoC in die Produktion schafft.

---

**Enterprise AI-Infrastruktur Blueprint 2026 - Artikel-Serie**

| ← Vorheriger | Übersicht | Nächster → |
|:---|:---:|---:|
| [Betriebsrat und AI Literacy: Die Organisationsfragen](/de/magazin/ki-betriebsrat-ai-literacy/) | [Zur Übersicht](/de/magazin/ai-infrastruktur-blueprint-2026/) | - |

*Alle Artikel dieser Serie: [Enterprise AI-Infrastruktur Blueprint 2026](/de/magazin/ai-infrastruktur-blueprint-2026/)*

---

**Welche Architekturentscheidungen hat Ihr Team für seinen Agent-PoC getroffen?**

Wir prüfen in einem Erstgespräch, welche der acht Ebenen bereits definiert sind und wo die Lücken den Sprung in die Produktion blockieren. 30 Minuten, kostenfrei. [Erstgespräch vereinbaren](/de/kontakt/).

<!--
PYRAMIDE-BRIEF

Verdichtung (200 Zeichen):
Agenten scheitern nicht an der Orchestrierungsplattform, sondern an fehlender Architektur. Die Plattformwahl loest 12 Prozent. Die anderen 88 Prozent sind Decision Layer, Governance, Audit Trail.

Kernthese:
Die Frage "welche Orchestrierungsplattform" ist die falsche erste Frage. Die Plattform ist eine von acht Architekturentscheidungen. Wer sie isoliert trifft, baut Ausfuehrung ohne Governance und scheitert im PoC-Friedhof - wie 89 Prozent der Anwendungsfaelle (Camunda 2026).

Zielgruppe:
Head of IT, CTO, Head of Transformation im Mittelstand 500-5000 MA, die einen Agent-PoC gebaut haben und jetzt im Lenkungsausschuss "die richtige Plattform" auswaehlen sollen.

Staerkste Stelle:
Der Abschnitt mit den drei unabhaengigen Datenquellen (Camunda 11% Produktion, Gartner 40% Cancellation, MIT 95% Stall) fuehrt zwangslaeufig zur Schlussfolgerung, dass Plattformwahl das falsche Problem ist. Keine Spekulation, nur Zahlen.

Schwaechste Stelle:
Risiko, dass Leser denkt "ok, Plattformwahl egal". Ist nicht egal, sondern unterordnet. Der H2 "Wann welche Plattform technisch Sinn ergibt" muss den Leser wieder abholen - mit echter technischer Orientierung, ohne Selbstbau-Empfehlung.

Interessant fuer die Persona?
Ja. Der Leser erwartet eine Empfehlungstabelle und bekommt stattdessen die Erkenntnis, dass seine Frage falsch gestellt war. Das ist die Art von Einsicht, die im Lenkungsausschuss die Diskussion ueber Nacht aendert.

Vorschlag-Pyramide:
Top-Claim: "Plattform loest 12 Prozent. Die anderen 88 Prozent sind Architektur."
-> H2 1: Die Zahlen zeigen, woran Piloten wirklich scheitern (nicht an der Plattform)
-> H2 2: Acht Architekturentscheidungen - Plattform ist eine davon
-> H2 3: Zwei Kategorien Plattformen (visuell vs. code-first)
-> H2 4: Neutraler Sechser-Vergleich als Tabelle
-> H2 5: Technische Passung nach Szenario
-> H2 6: Was die Plattform nicht leistet - und darum herum gebaut werden muss
-> H2 7: Die richtige erste Frage ist Architektur, nicht Plattform

H2-KETTE:
1. Der Pilot laeuft. Dann passiert: nichts. (Intro mit Persona-Problem)
2. Der haeufigste Ausfallgrund ist nicht die Plattform (Datenbeweis: Camunda + Gartner + MIT)
3. Die Plattform ist eine von acht Architekturentscheidungen (Liste mit Gewicht)
4. Der Markt teilt sich in zwei Welten (technische Grundlage Visual vs. Code)
5. Sechs Plattformen im neutralen Vergleich (Tabelle + Beobachtungen)
6. Wann welche Plattform technisch Sinn ergibt (Szenarien, keine Empfehlung)
7. Was die Plattform nicht leistet (MIT Internal-vs-Partner-Befund)
8. Der naechste Schritt ist nicht die Plattformwahl (Schlusslogik, Gosign als Gesamtpaket)

VERIFIKATION DER ZAHLEN:
- 11% Produktion, 71% nutzen Agenten, 73% Vision-Reality-Gap, 80% Chatbots, 48% Silos, 84% Risiko-Sorge, 80% fehlende Transparenz, 66% Compliance -> Camunda State of Agentic Orchestration Report 2026 (n=1.150)
- 40% Cancellation bis 2027, eskalierende Kosten/unklarer Wert/Risikokontrolle -> Gartner Press Release 2025-06-25
- 33% Enterprise-Software Agentic bis 2028 (vs <1% 2024) -> Gartner
- 95% Gen-AI-Piloten ohne messbaren P&L-Impact, Internal-Build 1/3 so oft erfolgreich wie Vendor-Partnerschaft -> MIT NANDA "GenAI Divide" 2025 (150 Interviews, 350 Umfrage, 300 Deployments)
- 88% POCs scheitern (4 aus 33) -> IDC/Lenovo 2025, CIO.com
- n8n Sustainable Use License fair-code, Wiederverkauf/Embedding eingeschraenkt -> n8n docs + faircode.io

SELBST-CHECK:
- BLUF? Ja. Kernbotschaft in Intro + Auf einen Blick + letzter Abschnitt.
- Eine Argumentationslinie? Ja. "Die falsche erste Frage" zieht sich durch.
- Templates vermieden? Ja. Kein "Wenn Sie als CTO". Persona ueber konkrete Situation (Lenkungsausschuss).
- DAX/MDAX vermieden? Ja. "Mittelstand 500-5000 MA" nur im Brief, nicht im Artikel. Artikel spricht ueber Unternehmen, die PoCs bauen.
- Statistiken mit Quelle? Ja. Camunda, Gartner, MIT, IDC alle verlinkt oder namentlich genannt.
- Sonderstriche? Keine em/en dashes.
- Trigger.dev-Empfehlung vermieden? Ja. Trigger.dev wird neutral als eine von sechs Plattformen vorgestellt, ohne als "Standardwahl" bezeichnet zu werden.
- Selbstbau-Empfehlung vermieden? Ja. Gosign wird nur im letzten Abschnitt und beim MIT-Internal-vs-Partner-Befund erwaehnt - als Gesamtpaket, nicht als "baut Ihnen Trigger.dev".
- vs./Alternative/Ersetzt gegen Andock-Systeme? Nein. Kein Vergleich gegen SAP/Joule/Copilot hier.
- Gosign in jedem Abschnitt? Nein. Nur zweimal (MIT-Absatz + Schlussabsatz).
- Interessantes Einstiegsproblem? Ja. Lenkungsausschuss-Szene.
-->

--- Von Chatbots zu AI-Agenten: MCP, A2A, Multi-Agent ---
> Was AI-Agenten von Chatbots unterscheidet. MCP- und A2A-Protokolle, Agent-Architektur, Multi-Agent-Orchestrierung für Unternehmen.

## Ein Chatbot antwortet. Ein Agent handelt.

Dieser Unterschied bestimmt den Wert von KI in Unternehmen 2026. Ein Chatbot beantwortet Fragen, „Wie viele Urlaubstage habe ich noch?". Ein Agent führt Prozesse aus. Der Unterschied ist nicht graduell, sondern grundsätzlich.

Ein konkretes Beispiel: Ein Mitarbeiter meldet sich krank. Der HR-Agent nimmt die Krankmeldung entgegen, prüft das Formular auf Vollständigkeit, gleicht den Zeitraum mit dem Dienstplan ab, informiert die Teamleitung, passt die Kapazitätsplanung an und dokumentiert den Vorgang in der Personalakte. Vier Systeme, ein Agent, null manuelle Eingaben. Jeder Schritt nachvollziehbar, jeder Schritt im Audit Trail.

Das ist kein Zukunftsszenario. Das ist der Stand der Technik 2026. Und es ist der Grund, warum die Architektur von KI-Agenten eine strategische Entscheidung ist, nicht eine Aufgabe für die IT-Abteilung allein.

Dieser Artikel beschreibt die Agent-Architektur für Enterprise-Umgebungen, erklärt die neuen Standards MCP und A2A, zeigt fünf konkrete Business Use Cases mit Einsparpotenzial und definiert die Governance-Anforderungen, ohne die kein Agent in Produktion gehen sollte.

Gartner (2024) prognostiziert, dass bis 2028 33 % der Enterprise-Softwareanwendungen agentische KI enthalten werden - gegenüber weniger als 1 % im Jahr 2024. Die Architektur, die Sie heute wählen, bestimmt, ob diese Agenten Wert liefern oder Risiken erzeugen.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Auf einen Blick - AI-Agenten für Unternehmen</p>
<ul class="text-body text-gosign-text space-y-2">
<li>AI-Agenten führen Prozesse aus, nicht nur Fragen beantworten. Der Unterschied zwischen Chatbot und Agent ist architektonisch, nicht graduell.</li>
<li>Die Enterprise-Agent-Architektur hat fünf Schichten: Benutzer-Interface, Orchestrierung, KI-Modell, Tool-Integration (MCP) und Governance.</li>
<li>MCP standardisiert den Systemzugriff (Agent-zu-System), A2A die Kommunikation zwischen Agenten (Agent-zu-Agent). Beide reduzieren den Integrationsaufwand um eine Größenordnung.</li>
<li>Vier Governance-Anforderungen sind vor der Produktion nicht verhandelbar: Decision Layer, Human-in-the-Loop, Audit Trail und Rollback.</li>
<li>Starten Sie mit einem Agenten für einen Prozess. Die Infrastruktur des ersten Agenten ist die Plattform für jeden weiteren.</li>
</ul>
</div>

## Die Agent-Architektur: Fünf Schichten

Ein KI-Agent ist kein monolithisches System. Die Enterprise-Architektur besteht aus fünf Schichten, die jeweils eine klar definierte Aufgabe haben:

```
┌─────────────────────────────────────────┐
│          Benutzer-Interface              │
│    (very-ai / Teams / Custom)            │
├─────────────────────────────────────────┤
│        Orchestrierungs-Schicht           │
│   (Routing, Regelwerk, Eskalation)       │
├─────────────────────────────────────────┤
│          KI-Modell-Schicht               │
│  (Claude / GPT / Llama / gpt-oss - je nach Task) │
├─────────────────────────────────────────┤
│         Tool-Integration (MCP)           │
│  (ERP, CRM, DMS, E-Mail, Kalender...)    │
├─────────────────────────────────────────┤
│      Governance & Audit Layer            │
│  (Logging, Policies, Human-in-the-Loop)  │
└─────────────────────────────────────────┘
```

**Benutzer-Interface.** Die Schicht, über die Mitarbeitende mit dem Agenten interagieren. Das kann ein dediziertes AI-Portal sein (wie in [Enterprise-AI-Portal: Mehr als nur ein Chat-Interface](/de/magazin/enterprise-ki-chat-interface/) beschrieben), eine Integration in Microsoft Teams oder eine Custom-Oberfläche für spezifische Fachbereiche.

**Orchestrierungs-Schicht.** Hier wird entschieden, welcher Agent eine Aufgabe übernimmt, welches Modell verwendet wird und wann eskaliert wird. Die Orchestrierung kennt die Regelwerke, die Zuständigkeiten und die Eskalationspfade. Sie ist die Schaltzentrale.

**KI-Modell-Schicht.** Das Sprachmodell, das die eigentliche Verarbeitung leistet: Texte verstehen, Zusammenhänge erkennen, Antworten generieren. In einer modell-agnostischen Architektur ist diese Schicht austauschbar. Ein kostengünstiges Modell für Standardanfragen, ein leistungsfähigeres für komplexe Analysen. Das Routing erfolgt automatisch.

**Tool-Integration (MCP).** Die Verbindung zu Ihren bestehenden Systemen: ERP, CRM, Dokumentenmanagement, E-Mail, Kalender, Ticketsystem. Über das Model Context Protocol (MCP) greifen Agenten standardisiert auf diese Systeme zu.

**Governance & Audit Layer.** Jede Agenten-Aktion wird protokolliert. Policies definieren, was ein Agent darf und was nicht. Human-in-the-Loop wird dort erzwungen, wo es erforderlich ist. Diese Schicht ist nicht optional. Sie ist die Voraussetzung für den produktiven Einsatz. Der [Decision Layer](/de/decision-layer/) bildet das architektonische Fundament dieser Governance.

## MCP und A2A: die neuen Standards

Zwei Protokolle haben 2025/2026 die Art verändert, wie KI-Agenten mit der Außenwelt und miteinander kommunizieren: MCP (Model Context Protocol) und A2A (Agent-to-Agent).

### MCP: Der USB-Anschluss für KI

MCP ist ein offener Standard, der KI-Modellen ermöglicht, auf externe Datenquellen und Werkzeuge zuzugreifen. Die Analogie ist treffend: So wie USB eine universelle Schnittstelle für Hardware geschaffen hat, schafft MCP eine universelle Schnittstelle für KI-Integrationen.

Vor MCP musste für jede Kombination aus KI-Modell und Zielsystem ein eigener Konnektor gebaut werden. Agent A greift auf SAP zu, ein Konnektor. Agent B greift auf das DMS zu, ein weiterer Konnektor. Agent C greift auf den Kalender zu, noch ein Konnektor. Bei zehn Systemen und drei Modellen ergeben sich dreißig individuelle Integrationen.

Mit MCP definiert jedes System einmal seine Fähigkeiten in einem standardisierten Format: Welche Daten kann es liefern? Welche Aktionen kann es ausführen? Welche Parameter sind erforderlich? Jedes MCP-kompatible Modell kann diese Fähigkeiten nutzen, ohne systemspezifischen Code.

Für Unternehmen bedeutet das: Neue Systeme können schneller angebunden werden. Modelle können ausgetauscht werden, ohne die Integrationen neu zu bauen. Die Abhängigkeit von einzelnen Modellanbietern sinkt.

### A2A: Agenten sprechen miteinander

A2A (Agent-to-Agent) ist das Pendant zu MCP für die Kommunikation zwischen Agenten. Während MCP die Verbindung Agent-zu-System regelt, regelt A2A die Verbindung Agent-zu-Agent.

Warum ist das relevant? Weil komplexe Geschäftsprozesse selten von einem einzelnen Agenten abgedeckt werden. Eine Krankmeldung betrifft HR, Kapazitätsplanung, Gehaltsabrechnung und möglicherweise das Projektmanagement. Jeder Bereich hat einen spezialisierten Agenten. A2A ermöglicht diesen Agenten, Aufgaben delegieren und Ergebnisse austauschen, mit definierten Berechtigungen.

Entscheidend: A2A bedeutet nicht gemeinsamen Datenzugriff. Der HR-Agent übergibt dem Finance-Agent die Information „Mitarbeiter X ist ab Datum Y abwesend", nicht die vollständige Personalakte. Jeder Agent sieht nur, was er für seine Aufgabe benötigt. Die Berechtigungsgrenzen bleiben gewahrt.

## 5 Business Use Cases mit konkretem Einsparpotenzial

Die Frage, die Entscheider stellen, ist nicht „Was kann ein Agent?" sondern „Was bringt ein Agent?". Hier sind fünf Anwendungsfälle mit messbarem Einsparpotenzial:

| Bereich | Use Case | Was der Agent tut | Einsparpotenzial |
|---|---|---|---|
| HR | Onboarding | Accounts anlegen, Schulungen zuweisen, Einführungsgespräche planen, Welcome-Mail versenden | 4--6 h pro Einstellung |
| Finance | Rechnungsprüfung | Rechnung lesen, gegen Bestellung prüfen, Kontierung kontrollieren, Freigabe-Workflow auslösen | 70--80 % weniger Bearbeitungszeit |
| Legal | Vertragsanalyse | Klauseln extrahieren, gegen Standardverträge vergleichen, Abweichungen markieren | Stunden statt Tage |
| IT | Incident-Triage | Fehlermeldung analysieren, Known-Issues abgleichen, Ticket mit Priorität erstellen | Schnellere Erstreaktion |
| Operations | Lieferanten-Monitoring | Liefertermine überwachen, mit Produktionsplan abgleichen, proaktive Meldung bei Verzug | Frühwarnung statt Nacharbeit |

Jeder dieser Use Cases folgt demselben Muster: Der Agent übernimmt den strukturierten, regelbasierten Teil eines Prozesses. Der Mensch übernimmt die Ausnahmen, die Ermessensentscheidungen und die Freigaben. Die Zeitersparnis entsteht nicht durch den Wegfall menschlicher Arbeit, sondern durch den Wegfall manueller Routinetätigkeiten.

**HR-Onboarding im Detail.** Heute koordiniert ein HR-Sachbearbeiter bei jeder Neueinstellung manuell: IT-Accounts anlegen, Zugriffsrechte konfigurieren, Pflichtschulungen zuweisen, Einführungsplan erstellen, Willkommens-E-Mail formulieren, Gehaltsabrechnung einrichten. Jeder Schritt ein separates System, jeder Schritt eine manuelle Eingabe. Ein Onboarding-Agent orchestriert diese Schritte automatisiert: Er liest den Arbeitsvertrag, erkennt Position, Standort und Abteilung, und führt die Schritte in den jeweiligen Systemen aus. Der HR-Sachbearbeiter gibt den Gesamtvorgang frei, nicht jeden Einzelschritt.

**Rechnungsprüfung im Detail.** Eine Eingangsrechnung wird vom Document Agent gelesen. Der Agent extrahiert Rechnungssteller, Betrag, Positionen, Bestellnummer. Er prüft automatisch: Gibt es eine zugehörige Bestellung? Stimmen die Positionen und Beträge? Ist die Kontierung korrekt? Liegt der Betrag innerhalb der Freigabegrenzen? Bei positivem Ergebnis wird die Buchung vorbereitet. Bei Abweichungen wird an den zuständigen Sachbearbeiter eskaliert, mit dem konkreten Grund der Abweichung, nicht mit der generischen Meldung „Bitte prüfen".

## Governance-Anforderungen für Agenten

Ein Agent ohne Governance ist ein Risiko. Vier Anforderungen müssen vor dem produktiven Einsatz erfüllt sein:

**1. Decision Layer.** Jede Agenten-Entscheidung durchläuft den [Decision Layer](/de/decision-layer/). Für jede Mikro-Entscheidung ist definiert: Darf der Agent autonom handeln, greift ein Regelwerk, oder muss ein Mensch freigeben? Diese Regeln sind versioniert, nachvollziehbar und nicht durch den Agenten selbst änderbar.

**2. Human-in-the-Loop.** Bei definierten Entscheidungstypen erzwingt die Architektur menschliche Prüfung. Das ist kein Feature, das aktiviert werden kann. Es ist ein Architekturprinzip. Der Agent kann die Human-in-the-Loop-Anforderung nicht umgehen, weil sie technisch, nicht organisatorisch durchgesetzt wird.

**3. Audit Trail.** Jede Agenten-Aktion erzeugt einen unveränderlichen Protokolleintrag: Was war der Input? Welches Modell wurde verwendet? Welche Regel wurde angewandt? Was war das Ergebnis? Wann wurde die Aktion ausgeführt? Der Audit Trail ist die Grundlage für Wirtschaftsprüfung, interne Revision und Betriebsratskontrolle.

**4. Rollback.** Jede Agenten-Aktion muss rückgängig gemacht werden können. Wenn ein Agent eine fehlerhafte Buchung erzeugt oder eine falsche Benachrichtigung versendet, muss der Vorgang korrigiert werden können, technisch, nicht nur organisatorisch. Rollback-Fähigkeit ist eine Architekturanforderung, keine nachträgliche Ergänzung.

Diese vier Anforderungen sind nicht verhandelbar. Ohne sie wird kein Betriebsrat zustimmen, kein Wirtschaftsprüfer absegnen und kein CIO die Verantwortung übernehmen. Mehr zur Governance-Architektur im nächsten Artikel: [Decision Layer & Shadow AI](/de/magazin/decision-layer-shadow-ai/).

## Multi-Agent-Systeme: Spezialisierung statt Universalagent

Die nächste Stufe nach dem einzelnen Agenten: mehrere spezialisierte Agenten, die zusammenarbeiten. Nicht ein universeller Agent, der alles kann, sondern Spezialisten, die jeweils eine Domäne beherrschen.

Das Krankmeldungs-Beispiel als Multi-Agent-System:

```
Krankmeldung eingehend
│
Document Agent  →  Liest und klassifiziert die Krankmeldung
│
HR Agent      →  Prüft Regeln: Lohnfortzahlung, BEM, Fristen
│
Workflow Agent  →  Informiert Teamleitung, passt Dienstplan an
│
Finance Agent   →  Aktualisiert Gehaltsabrechnung
```

Jeder Agent hat eigene Berechtigungen. Der Document Agent kann Dokumente lesen, aber keine Buchungen erzeugen. Der Finance Agent kann die Gehaltsabrechnung anpassen, aber keine Personalakten einsehen. Die Berechtigungsgrenzen sind architektonisch erzwungen. Über das A2A-Protokoll kommunizieren die Agenten nur die Informationen, die der empfangende Agent für seine Aufgabe benötigt.

Der Orchestrator-Agent koordiniert den Gesamtablauf. Er weiß, welcher Agent welchen Schritt ausführt, in welcher Reihenfolge, und was bei Fehlern passiert. Der Orchestrator hat Überblick, aber keine operativen Berechtigungen. Er delegiert, er führt nicht selbst aus.

Multi-Agent-Systeme sind leistungsfähig, aber komplex. Die Zahl der Interaktionen wächst quadratisch mit der Zahl der Agenten. Debugging wird aufwendiger. Die Governance-Anforderungen steigen.

## Praxis-Empfehlung: Klein anfangen

Die Versuchung ist groß, direkt mit einem Multi-Agent-System zu starten. Die Empfehlung ist klar: Starten Sie mit einem einzelnen Agenten für einen klar definierten Prozess.

**Schritt 1:** Einen Prozess identifizieren, der strukturiert, regelbasiert und häufig genug ist, um den Aufwand zu rechtfertigen. Rechnungsprüfung, Onboarding, Vertragsanalyse, einer davon.

**Schritt 2:** Einen einzelnen [KI-Agenten](/de/leistungen/ai-agents/) für diesen Prozess aufsetzen. Mit Decision Layer, mit Human-in-the-Loop, mit Audit Trail. Nicht als Prototyp, sondern als produktives System.

**Schritt 3:** Messen. Durchlaufzeit vorher und nachher. Fehlerquote. Kosten pro Vorgang. Zufriedenheit der Sachbearbeiter.

**Schritt 4:** Erst wenn der erste Agent stabil läuft, den zweiten planen. Und erst wenn mehrere Agenten stabil laufen, über Multi-Agent-Orchestrierung nachdenken.

Dieser Ansatz ist nicht konservativ. Er ist pragmatisch. Ein funktionierender Agent mit nachweisbarem Nutzen ist mehr wert als ein ambitioniertes Multi-Agent-Konzept, das in der Pilotphase steckenbleibt.

Die [Infrastruktur](/de/leistungen/infrastruktur/), Modell-Hosting, Vektordatenbanken, Orchestrierungs-Engine, API-Gateway, wird beim ersten Agenten aufgebaut und steht dann für jeden weiteren zur Verfügung. Die Investition in den ersten Agenten ist gleichzeitig die Investition in die Plattform.

Ein konkretes Beispiel: Im Enterprise-AI-Portal [very-ai](/de/magazin/enterprise-ki-chat-interface/) können Nutzer direkt aus dem Chat heraus Trigger.dev-Workflows triggern. Der Agent wird damit zum Auslöser einer Prozesskette - nicht nur zum Gesprächspartner. Die Orchestrierungsplattform (→ [Artikel 10](/de/magazin/agent-orchestrierung-plattformen/)) übernimmt die Ausführung.

Wo diese Agenten konkret laufen, auf welcher Plattform, zeigt [Artikel 10: Agent-Orchestrierung](/de/magazin/agent-orchestrierung-plattformen/).

---

**📘 Enterprise AI-Infrastruktur Blueprint 2026 - Artikel-Serie**

| ← Vorheriger | Übersicht | Nächster → |
|:---|:---:|---:|
| [RAG & Document Intelligence: Wie KI Ihre Dokumente versteht](/de/magazin/rag-document-intelligence-enterprise/) | [Zur Übersicht](/de/magazin/ai-infrastruktur-blueprint-2026/) | [Decision Layer & Shadow AI: Kontrolle statt Kontrollverlust](/de/magazin/decision-layer-shadow-ai/) |

*Alle Artikel dieser Serie: [Enterprise AI-Infrastruktur Blueprint 2026](/de/magazin/ai-infrastruktur-blueprint-2026/)*

---

**Sie wollen den ersten KI-Agenten für einen konkreten Geschäftsprozess aufsetzen?** Gosign begleitet Enterprise-Kunden von der Prozessanalyse bis zum produktiven Agenten, modell-agnostisch, mit Decision Layer und vollständigem Audit Trail.

<a href="/de/kontakt/" target="_blank" rel="noopener noreferrer">Termin vereinbaren</a>. 30 Minuten, in denen wir den richtigen ersten Use Case für Ihr Unternehmen identifizieren.

--- Enterprise AI-Infrastruktur Blueprint 2026 ---
> Die acht Entscheidungen für Ihre KI-Infrastruktur. Modelle, Hosting, Interfaces, Agenten, Orchestrierung, Governance, Kosten, Regulierung.

## Warum dieser Blueprint

Die Integration von KI in Unternehmensprozesse hat sich vom Innovationsprojekt zur operativen Notwendigkeit entwickelt. Wer 2026 noch keinen Plan hat, fällt nicht hinter die Konkurrenz zurück, er fällt aus dem Markt. Gleichzeitig ist die Entscheidungslandschaft komplexer geworden: mehr Modelle, mehr Hosting-Optionen, mehr Regulierung, mehr Orchestrierungsplattformen.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Auf einen Blick - Enterprise KI-Infrastruktur 2026</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Acht strategische Entscheidungen, die jeder CTO oder CIO innerhalb von 90 Tagen treffen muss, um KI im Enterprise-Maßstab zu betreiben.</li>
<li>Modellwahl, Hosting-Stufe, AI-Portal, RAG, Agenten, Decision Layer, Compliance und Orchestrierung bilden den vollständigen Stack.</li>
<li>Die Hybrid-Hosting-Architektur - Routing nach Datensensibilität über Cloud, europäisches IaaS und On-Premises - hat sich als Standard etabliert.</li>
<li>IDC (2025) prognostiziert weltweite Ausgaben für KI-Infrastruktur von 154 Milliarden US-Dollar bis 2027, gegenüber 76 Milliarden in 2024.</li>
<li>Ein konkreter 90-Tage-Fahrplan verwandelt Pilotprojekte in produktive Infrastruktur mit Governance von Anfang an.</li>
</ul>
</div>

Dieser Blueprint reduziert die Komplexität auf acht konkrete Entscheidungen, die jede technische Führungskraft in den nächsten 90 Tagen treffen muss.

Jede dieser Entscheidungen wird in einem eigenen Artikel detailliert behandelt, mit Vergleichstabellen, Entscheidungsbäumen und konkreten Empfehlungen. Kein Marketing, keine Buzzwords. Fakten, Architektur, Handlungsempfehlungen.

## Die acht Entscheidungen

### Entscheidung 1: Welches KI-Modell passt zu Ihrem Anwendungsfall?

Die Modell-Landschaft hat sich seit 2024 fundamental verändert. Claude, GPT-5, Gemini 3, Llama 4, gpt-oss, DeepSeek, die Unterschiede liegen nicht mehr in der Qualität, sondern in Spezialisierung, Datenschutz und Kostenstruktur. Die richtige Antwort ist nicht ein Modell, sondern eine modell-agnostische Architektur, die pro Aufgabe das passende Modell routet.

**[Zum Artikel: KI-Modelle 2026, Welches Modell für welchen Einsatz?](/de/magazin/ki-modelle-vergleich-2026/)**

### Entscheidung 2: Wo laufen Ihre KI-Modelle?

EU-SaaS, deutsches Rechenzentrum oder Self-Hosted: diese Entscheidung bestimmt Ihre Datenschutzgarantien, Ihre Kostenstruktur und Ihre Abhängigkeit von Drittanbietern. Die Hybrid-Strategie, bei der eine Routing-Schicht Anfragen automatisch nach Datensensibilität verteilt, hat sich als Standard etabliert.

**[Zum Artikel: KI-Hosting, EU-SaaS, deutsches RZ oder Self-Hosted?](/de/magazin/ki-hosting-strategien-enterprise/)**

Sobald die Hosting-Entscheidung steht, folgt die vertragliche Absicherung. Ein Standard-AVV reicht für KI-Infrastruktur nicht aus - [unser Anforderungskatalog](/de/magazin/avv-ki-infrastruktur-checkliste/) zeigt die zehn Lücken und liefert 25 Prüffragen für Legal und Compliance.

### Entscheidung 3: Wie machen Sie KI für alle Mitarbeiter nutzbar, ohne Kontrollverlust?

Ein Sprachmodell ohne kontrolliertes Interface ist wie ein Server ohne Frontend. Mitarbeitende nutzen dann öffentliche KI-Dienste, unkontrolliert, unprotokolliert, nicht DSGVO-konform. Ein Enterprise-AI-Portal bietet die bessere Alternative: Multi-Modell-Routing, Assistenten-Sharing, Agenten-Integration, SSO und vollständigen Audit-Trail.

→ **Artikel 3: Enterprise-AI-Portale** - Fünf Open-Source-Interfaces im Vergleich: LobeChat, OpenWebUI, LibreChat, chatbot-ui und very-ai. Welches Portal hat SSO, PII-Schutz und Audit Trail? (Transparenzhinweis: very-ai wird von Gosign entwickelt.)

**[Zum Artikel: Enterprise-AI-Portale, Fünf Open-Source-Interfaces im Vergleich](/de/magazin/enterprise-ki-chat-interface/)**

### Entscheidung 4: Wie wird Ihr Unternehmenswissen KI-zugänglich?

RAG (Retrieval Augmented Generation) macht Ihre Dokumente durchsuchbar, ohne Daten an Modell-Anbieter zu geben. Document Intelligence geht weiter: PII-Anonymisierung, Vertragsschwärzung, automatische Compliance-Prüfung.

**[Zum Artikel: RAG & Document Intelligence, Wie KI Ihre Dokumente versteht](/de/magazin/rag-document-intelligence-enterprise/)**

### Entscheidung 5: Wie werden aus Chatbots echte Agenten?

Der Schritt von einem Chat-Interface zu autonomen Prozessen, die Dokumente verarbeiten, Systeme bedienen und Entscheidungen vorbereiten, erfordert eine andere Architektur. MCP- und A2A-Protokolle, Multi-Agent-Systeme und klare Governance-Anforderungen bestimmen den Erfolg.

**[Zum Artikel: Von Chatbots zu AI-Agenten, MCP, A2A und Multi-Agent-Systeme](/de/magazin/ai-agenten-enterprise-leitfaden/)**

### Entscheidung 6: Wie trennen Sie Analyse von Entscheidung?

Der Decision Layer zerlegt Geschäftsprozesse in Mikro-Entscheidungen und definiert für jede: Mensch, Regelwerk oder KI. Das ist die Architektur, die Betriebsräte überzeugt, Wirtschaftsprüfer zufriedenstellt und Skalierung ermöglicht.

**[Zum Artikel: Decision Layer & Shadow AI, Kontrolle statt Kontrollverlust](/de/magazin/decision-layer-shadow-ai/)**

### Entscheidung 7: Was verlangt der EU AI Act, jetzt, nicht irgendwann?

Die Schonfrist ist vorbei. Seit Februar 2025 gelten die ersten Verbote und die AI-Literacy-Pflicht. Die High-Risk-Verpflichtungen greifen nach aktuellem Recht ab dem 2. August 2026; nach der vorläufigen Digital-Omnibus-Einigung vom 7. Mai 2026 sollen sie sich auf den 2. Dezember 2027 verschieben (formale Verabschiedung ausstehend, Stand Juni 2026). Die Hochrisiko-Einstufung bleibt in jedem Fall bestehen - wer die Vorbereitung aufschiebt, riskiert Bußgelder bis zu 35 Millionen Euro oder 7 % des Jahresumsatzes.

**[Zum Artikel: EU AI Act 2026, Was jetzt gilt, was kommt, was Sie tun müssen](/de/magazin/eu-ai-act-2026-unternehmen/)**

### Entscheidung 8: Auf welcher Plattform orchestrieren Sie Ihre Agenten?

n8n für schnelle Prototypen, Camunda für Compliance-pflichtige Prozesse, Temporal für komplexe Langzeitworkflows: die Orchestrierungsplattform bestimmt, ob Ihre Agenten-Architektur skaliert oder im PoC stecken bleibt.

**[Zum Artikel: Agent-Orchestrierung, n8n, Camunda und Alternativen](/de/magazin/agent-orchestrierung-plattformen/)**

## Die acht Entscheidungen im Überblick

<table>
<thead>
<tr><th>Entscheidung</th><th>Thema</th><th>Kernfrage</th></tr>
</thead>
<tbody>
<tr><td>1</td><td>KI-Modellwahl</td><td>Welches Modell für welche Aufgabe? Modell-agnostisches Routing.</td></tr>
<tr><td>2</td><td>Hosting-Strategie</td><td>EU-SaaS, deutsches RZ oder Self-Hosted?</td></tr>
<tr><td>3</td><td>Enterprise AI-Portal</td><td>Kontrolliertes Interface mit SSO, Audit Trail, PII-Schutz.</td></tr>
<tr><td>4</td><td>RAG & Document Intelligence</td><td>Wie wird Unternehmenswissen KI-zugänglich?</td></tr>
<tr><td>5</td><td>AI-Agenten</td><td>Vom Chatbot zum autonomen Multi-Step-Agenten.</td></tr>
<tr><td>6</td><td>Decision Layer</td><td>KI-Analyse von Geschäftsentscheidung trennen.</td></tr>
<tr><td>7</td><td>Kosten & EU AI Act</td><td>TCO und regulatorische Pflichten seit August 2025.</td></tr>
<tr><td>8</td><td>Agent-Orchestrierung</td><td>n8n, Camunda oder Temporal für produktive Workflows.</td></tr>
</tbody>
</table>

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Kostenloses eBook: AI Infrastructure</p>
<p class="text-body text-gosign-text mb-4">Build, Buy, Hybrid - EU AI Act-konforme Infrastruktur mit B/B/H-Framework und 7-Layer Reference Architecture.</p>
<a href="/de/ebook/ki-infrastructure-governance-handbuch/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Jetzt kostenlos herunterladen</a>
</div>

## Für wen dieser Blueprint geschrieben ist

Dieser Blueprint richtet sich an technische Entscheider in Unternehmen ab 500 Mitarbeitenden:

- **CTOs und VP Engineering**, die eine KI-Architektur aufbauen oder konsolidieren müssen
- **CIOs**, die KI-Strategie mit IT-Governance und bestehender Systemlandschaft vereinbaren
- **Heads of HR und COOs**, die KI in operative Prozesse integrieren, von der Belegverarbeitung bis zum Wissensmanagement
- **Technisch versierte C-Level-Führungskräfte**, die fundierte Entscheidungen treffen wollen statt Pilot-Projekte zu sammeln

Der Blueprint setzt voraus, dass Sie die Experimentierphase hinter sich haben. Es geht nicht um die Frage, ob KI eingesetzt wird, sondern wie, mit welcher Architektur, welcher [Governance](/de/governance/) und welcher Betriebsstrategie.

## 90-Tage-Fahrplan

Der Blueprint mündet in einen konkreten Fahrplan mit drei Phasen:

### Phase 1: Foundation (Woche 1--4)

- AI-System-Inventar erstellen (was wird bereits genutzt?)
- Datenklassifizierung durchführen
- Ein Use Case identifizieren (höchster ROI bei geringstem Risiko)
- Hosting-Entscheidung treffen (Stufe 1, 2 oder 3)
- Internes AI-Portal aufsetzen (LobeChat, OpenWebUI, very-ai oder LibreChat)

Die Präsentationsschicht - das Enterprise-AI-Portal - hat 2026 fünf Open-Source-Optionen. Gosign hat mit very-ai ein eigenes Portal entwickelt, das PII-Schutz und Entra-ID-Gruppensync als Enterprise-Funktionen ergänzt (→ Artikel 3). Wie bei allen Empfehlungen in dieser Serie: Evaluieren Sie mehrere Optionen für Ihren spezifischen Kontext.

Ergebnis: Ihre Mitarbeiter haben ein kontrolliertes AI-Tool statt Shadow-AI.

### Phase 2: Erster Agent (Woche 5--8)

- Use Case als Agent implementieren
- MCP-Anbindung an 1--2 bestehende Systeme
- Regelwerk für Entscheidungen definieren
- Human-in-the-Loop für kritische Schritte einrichten
- Pilotgruppe von 10--20 Nutzern definieren

Ergebnis: Ein funktionierender Agent, der einen echten Geschäftsprozess verbessert.

### Phase 3: Governance und Skalierung (Woche 9--12)

- Audit-Trail und Logging validieren
- EU-AI-Act-Dokumentation beginnen (Risikobewertung, technische Dokumentation)
- Ergebnisse des Piloten messen (Zeitersparnis, Fehlerquote, Nutzerzufriedenheit)
- Skalierungsplan erstellen: Welche 3--5 Use Cases folgen als nächstes?

Ergebnis: Ein validierter Business Case und ein klarer Weg zur Skalierung.

Der Fahrplan ist bewusst kompakt. In 90 Tagen haben Sie keine vollständige KI-Transformation, aber Sie haben eine produktive Infrastruktur, einen laufenden Agenten und die Governance-Grundlage, um sicher zu skalieren.

---

**Weiterführend:** [KI-Infrastruktur, Leistungen im Überblick](/de/leistungen/infrastruktur/) | [Decision Layer erklärt](/de/decision-layer/) | [AI Agents](/de/leistungen/ai-agents/)

---

**📘 Enterprise AI-Infrastruktur Blueprint 2026 - Artikel-Serie**

| ← Vorheriger | Übersicht | Nächster → |
|:---|:---:|---:|
| - | Sie befinden sich auf der Übersicht | [KI-Modelle 2026: Welches Modell für welchen Einsatz?](/de/magazin/ki-modelle-vergleich-2026/) |

*Alle Artikel dieser Serie: [Enterprise AI-Infrastruktur Blueprint 2026](/de/magazin/ai-infrastruktur-blueprint-2026/)*

---

**Sie wollen die acht Entscheidungen nicht allein treffen?** Gosign begleitet Enterprise-Kunden von der Architektur bis zum produktiven Betrieb, modell-agnostisch, herstellerneutral, mit vollem Quellcode-Zugang.

<a href="/de/kontakt/" target="_blank" rel="noopener noreferrer">Termin vereinbaren</a>. 30 Minuten, in denen wir Ihren konkreten Handlungsbedarf klären.

--- AVV für KI-Agenten: Was Ihr Standard-Vertrag nicht abdeckt ---
> Warum klassische Auftragsverarbeitungsverträge für Enterprise-KI nicht reichen. Mit Anforderungskatalog als Checkliste für HR und Compliance.

Ein Auftragsverarbeitungsvertrag (AVV) für KI-Infrastruktur muss zehn Themen abdecken, die Standard-SaaS-AVVs nicht regeln: Prompt-Logging-Policies, Umgebungstrennung (Dev/Staging/Prod), Modell-Provider-Ketten, In-flight- vs. At-rest-Datenverarbeitung, RAG-Embedding-Datenschutz, Drittlandzugriffe auf Produktivdaten, § 203-StGB-Kompatibilität, PII-Tokenisierung, Decision-Layer-Audit-Trails und Nachweisbarkeit technischer Maßnahmen.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Auf einen Blick - AVV für KI-Infrastruktur</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Standard-SaaS-AVVs decken weder Prompt-Logging, noch Modell-Provider-Ketten, noch Umgebungstrennung, noch PII-Tokenisierung ab, die KI-Infrastruktur erfordert.</li>
<li>Zehn konkrete Lücken existieren zwischen Standardverträgen und KI-Realität - von neuen Datenkategorien bis zu Decision-Layer-Audit-Trails.</li>
<li>Das BSI (2024) stellt fest, dass 68 % der Organisationen, die generative KI einsetzen, ihre Auftragsverarbeitungsverträge nicht an KI-spezifische Datenflüsse angepasst haben.</li>
<li>Eine 25-Fragen-Checkliste hilft HR- und Compliance-Verantwortlichen, die Bereitschaft des KI-Vendors in sieben Kategorien zu prüfen.</li>
<li>Dies ist keine Rechtsberatung - es ist ein Architektur-Kompass, der Infrastruktur-Lücken hinter Vertragslücken aufdeckt.</li>
</ul>
</div>

## Warum Standard-AVVs bei KI-Infrastruktur versagen

Ein klassischer Auftragsverarbeitungsvertrag regelt, wie ein Dienstleister personenbezogene Daten im Auftrag verarbeitet. Er definiert Zweck, Datenkategorien, technische und organisatorische Maßnahmen, Unterauftragsverarbeiter und Löschfristen. Für ein CRM-System oder eine HR-Software reicht das.

Bei Enterprise-KI-Infrastruktur entstehen Konstellationen, die kein Standard-AVV abbildet. Ein Sprachmodell verarbeitet Prompts  - also Freitexteingaben, die potenziell alles enthalten können: Personaldaten, Mandanteninformationen, Geschäftsgeheimnisse, sogar besondere Kategorien nach Art. 9 DSGVO ([EU AI Act](/de/governance/eu-ai-act/) verschärft diese Anforderungen zusätzlich), wenn ein Mitarbeitender eine medizinische Frage stellt. Die Daten fließen durch eine Kette von Systemen: vom Frontend über eine Orchestrierungsschicht zum Modell-Provider, zurück in eine Datenbank, möglicherweise durch eine RAG-Pipeline mit Embedding-Vektoren. An jeder Station stellen sich andere Fragen zu Speicherung, Zugriff und Löschung.

Wer einen KI-Vendor nach seinem AVV fragt und ein Standarddokument bekommt, sollte stutzig werden. Nicht weil der Vendor unseriös ist, sondern weil die spezifischen Risiken von KI-Infrastruktur andere Regelungen erfordern als die einer klassischen SaaS-Anwendung.

## Die zehn Lücken zwischen Standard-AVV und KI-Realität

### 1. Prompt-Inhalte als neue Datenkategorie

Standard-AVVs listen Datenkategorien auf: Name, E-Mail, Personalnummer. Bei KI-Agenten kommt eine Kategorie hinzu, die sich nicht vorab definieren lässt  - der Prompt. Ein Prompt kann eine harmlose Frage zur Urlaubsregelung sein oder ein vollständiger Mandantenbrief mit personenbezogenen Daten. Der AVV muss regeln, dass die Verantwortung für die Inhaltsklassifizierung beim Unternehmen liegt und der KI-Anbieter keine inhaltliche Vorabprüfung trifft. Gleichzeitig muss der Anbieter technische Maßnahmen nachweisen, die den Schutz aller eingegebenen Inhalte gewährleisten  - unabhängig von deren Sensibilität.

### 2. Logging-Policy: Was darf in Logs stehen?

Bei klassischer Software wird geloggt, was technisch notwendig ist. Bei KI-Infrastruktur hat Logging eine andere Dimension: Werden Prompt-Inhalte geloggt? Werden Modellantworten gespeichert? Werden hochgeladene Dokumente in Fehlerlogs geschrieben?

Ein belastbarer AVV für KI-Infrastruktur muss explizit regeln, dass in der Produktivumgebung kein Request-/Response-Body-Logging stattfindet, dass ausschließlich technische Metadaten protokolliert werden (Statuscodes, Laufzeiten, Request-IDs), dass Debug-Logging in Produktion deaktiviert ist und dass Stacktraces keine Prompt- oder Dokumentinhalte enthalten. Das klingt selbstverständlich  - ist es aber nicht. Fragen Sie Ihren Vendor nach seiner Logging-Policy für die Produktivumgebung. Wenn er keine hat, ist das ein Warnsignal.

### 3. Umgebungstrennung: Dev, Staging, Prod

Jedes Enterprise-Setup hat Entwicklungs-, Test- und Produktivumgebungen. Bei KI-Infrastruktur ist die Trennung sicherheitskritisch, weil in der Entwicklung echte Daten als Testdaten missbraucht werden können. Ein KI-spezifischer AVV muss festlegen, dass Dev und Staging ausschließlich synthetische oder anonymisierte Daten verwenden, dass der Produktivzugriff auf definierte Rollen in Deutschland/EWR beschränkt ist und dass Supportfälle nur mit vom Unternehmen freigegebenen Testdaten bearbeitet werden.

### 4. Modell-Provider-Kette statt klassischer Subdienstleister

Bei klassischer Software hat der Anbieter Unterauftragsverarbeiter: einen Hosting-Provider, vielleicht einen E-Mail-Dienst. Bei KI-Infrastruktur entsteht eine dreistufige Kette: Der KI-Infrastruktur-Anbieter betreibt die Plattform. Die Modell-Provider (Azure OpenAI, Google Vertex AI, Anthropic) verarbeiten die Prompts. Die Plattform-Provider (Supabase, Vercel) hosten Datenbank und Frontend.

Der entscheidende Punkt: Wer ist Vertragspartner der Modell-Provider? Laufen die Modelle im Tenant des KI-Anbieters oder im Tenant des Unternehmens? Dieser Unterschied bestimmt, ob der Modell-Provider Unterauftragsverarbeiter des Anbieters ist oder ob das Unternehmen selbst die Lieferantensteuerung übernimmt. Ein guter AVV klärt diese Abgrenzung explizit.

| Komponente | Im Tenant des Kunden | Im Tenant des Anbieters |
|---|---|---|
| Azure Entra ID (SSO) | ✓ Kunde | - |
| Azure OpenAI / Vertex AI | ✓ Kunde | - |
| Supabase (Datenbank) | ✓ Kunde | - |
| Vercel (Hosting) | ✓ Kunde | - |
| Plane (Ticketsystem) | - | ✓ Anbieter |
| GitHub (Code-Hosting) | - | ✓ Anbieter |
| Google Workspace (Kommunikation) | - | ✓ Anbieter |

*Komponenten im Kundentenant werden vom Kunden in der eigenen Lieferantenakte geführt. Komponenten im Anbietertenant sind Gegenstand der Unterauftragsverarbeiterliste im AVV.*

### 5. In-flight vs. at-rest: Wo bleiben die Daten?

Bei klassischer Software ist die Frage einfach: Daten liegen in einer Datenbank. Bei KI-Infrastruktur gibt es zwei Verarbeitungsmodi. In-flight-Verarbeitung: Der Prompt wird an den Modell-Provider gesendet, verarbeitet und die Antwort zurückgegeben. Keine persistente Speicherung beim Provider. At-rest-Speicherung: Chats, Uploads, Embeddings werden in einer Datenbank gespeichert (z.B. Supabase)  - persistent und dem Nutzer zugeordnet.

Der AVV muss für beide Modi separate Regelungen treffen. Für in-flight: Ist die Content-Retention beim Provider deaktiviert? Werden die Daten zu Trainingszwecken verwendet? Für at-rest: Wo liegt die Datenbank? Wer hat Zugriff? Wie funktioniert Löschung?

### 6. RAG und Embeddings: Vektordaten als neue Herausforderung

Retrieval Augmented Generation (RAG) macht Unternehmensdokumente für KI durchsuchbar. Dabei werden Dokumente in Embedding-Vektoren umgewandelt und in einer Vektordatenbank gespeichert. Diese Vektoren sind eine neue Datenkategorie: Sie enthalten keine lesbaren Texte, können aber unter bestimmten Umständen Rückschlüsse auf den Originalinhalt ermöglichen. Der AVV muss Embeddings als personenbezogene Daten behandeln, sofern sie aus Dokumenten mit personenbezogenen Inhalten generiert werden. Zugriffssteuerung, Löschung und [Mandantentrennung](/de/governance/data-residency/) müssen auch für die Vektordatenbank gelten.

### 7. Drittlandzugriffe auf Produktivdaten

Viele KI-Anbieter arbeiten mit verteilten Teams. Wenn ein Entwickler aus einem Drittland Zugriff auf die Produktivumgebung hat, entsteht ein Datentransfer im Sinne der DSGVO  - selbst wenn keine Daten physisch übertragen werden. Ein KI-spezifischer AVV muss definieren, dass Produktivzugriffe auf Deutschland/EWR beschränkt sind, dass Dev/Staging-Zugriffe aus Drittländern zulässig sind (weil nur synthetische Daten), dass RBAC (rollenbasierte Zugriffskontrolle) getrennte Admin-Gruppen für Prod und Dev/Staging vorsieht und dass ein Ausnahmeverfahren existiert, das schriftliche Freigabe durch den Verantwortlichen erfordert.

### 8. § 203 StGB: Berufsgeheimnisse in der KI-Plattform

Für [regulierte Branchen](/de/governance/cert-ready/)  - Anwaltskanzleien, Steuerberater, Wirtschaftsprüfer, aber auch Unternehmen mit berufsgeheimnisrelevanten Prozessen  - gilt: Mandats- und Berufsgeheimnisse dürfen nur verarbeitet werden, wenn der AVV explizite Regelungen enthält. Der Auftragsverarbeiter muss alle Mitarbeitenden und Freelancer schriftlich zur Vertraulichkeit verpflichten, Verpflichtungserklärungen inkl. Belehrung nach § 203 StGB müssen vorliegen und auf Anfrage nachweisbar sein. Standardklauseln zur Vertraulichkeit reichen hier nicht.

### 9. PII-Tokenisierung als optionales Modul

Eingangs- und Ausgangsfilter, die personenbezogene Daten erkennen und vor der Weiterleitung an den Modell-Provider pseudonymisieren, sind eine zusätzliche Schutzschicht. Diese [PII-Tokenisierung](/de/magazin/pii-anonymisierung-llm-enterprise/) ist nicht in jedem Setup notwendig, aber der AVV sollte sie als optionales Modul vorsehen. Wichtig: Wenn eine reversible Re-Identifizierung möglich ist, muss der AVV regeln, wer Zugriff auf die Zuordnungstabelle hat, wie Mapping-Keys gespeichert und verschlüsselt werden und dass Re-Identifizierung nur zweckgebunden nach dokumentierter Freigabe erfolgt.

### 10. Audit-Trail und Decision Layer

KI-Agenten treffen oder bereiten Entscheidungen vor. Jede dieser Entscheidungen muss nachvollziehbar sein  - nicht nur für den Datenschutz, sondern auch für interne Revision, Wirtschaftsprüfung und [Betriebsratsrechte](/de/governance/mitbestimmung/). Der [Decision Layer](/de/decision-layer/) zerlegt jeden Prozess in einzelne Entscheidungsschritte und definiert für jeden Schritt: Mensch, Regelwerk oder KI. Der AVV muss den Audit-Trail als Vertragsbestandteil verankern: Welche Daten werden pro Entscheidung geloggt? Wie lange werden sie aufbewahrt? Wer hat Zugriff?

## Die Checkliste: 25 Fragen an Ihren KI-Vendor

Die folgende Checkliste fasst die zehn Lücken in konkrete Prüffragen zusammen.

**[Anforderungskatalog ansehen: 25 Prüffragen für KI-AVVs →](/de/governance/avv-checkliste/)**

### A  - Datenkategorien und Verarbeitungszwecke

1. Sind Prompt-Inhalte und Modellantworten als eigenständige Datenkategorie im AVV aufgeführt?
2. Ist geregelt, wer die Verantwortung für die Inhaltsklassifizierung trägt (Unternehmen, nicht Anbieter)?
3. Sind Embeddings/Vektoren als potenziell personenbezogene Daten klassifiziert?
4. Enthält der AVV eine Regelung für besondere Kategorien nach Art. 9 DSGVO, die durch Nutzereingaben entstehen können?

### B  - Logging und Monitoring

5. Ist Request-/Response-Body-Logging in der Produktivumgebung deaktiviert?
6. Welche Metadaten werden protokolliert (Statuscodes, Laufzeiten, Request-IDs)?
7. Ist Debug-Logging in Produktion nachweisbar deaktiviert?
8. Werden Stacktraces und Fehlermeldungen so konfiguriert, dass keine Inhaltsdaten in Logs gelangen?
9. Ist die Prüfung der Logging-Einstellungen Bestandteil des Release-Prozesses?

### C  - Umgebungstrennung und Zugriff

10. Existieren getrennte Umgebungen (Dev, Staging, Prod) mit unterschiedlichen Datenpolicies?
11. Enthalten Dev/Staging ausschließlich synthetische oder anonymisierte Daten?
12. Ist der Produktivzugriff auf autorisierte Rollen in Deutschland/EWR beschränkt?
13. Gibt es ein dokumentiertes Ausnahmeverfahren für Supportfälle mit Datenbezug?

### D  - Modell-Provider und Subdienstleister

14. Ist die Abgrenzung klar: Welche Provider sind Unterauftragsverarbeiter des Anbieters, welche laufen im Tenant des Unternehmens?
15. Ist Content-Retention bei den Modell-Providern deaktiviert?
16. Ist der Ausschluss der Nutzung zu Trainingszwecken vertraglich dokumentiert?
17. Wo liegen die Modell-Endpunkte (EU-Region, US, andere)?

### E  - Datenspeicherung und Löschung

18. Ist geregelt, wo persistente Inhaltsdaten gespeichert werden (Datenbank, Region, Provider)?
19. Welche Backup-Retention gilt und wie wird mit gelöschten Daten in Backups umgegangen?
20. Kann der einzelne Nutzer seine Daten in der Anwendung selbst löschen?

### F  - Regulierte Branchen

21. Enthält der AVV eine Regelung zur § 203-StGB-Kompatibilität (oder landesspezifischem Äquivalent)?
22. Liegen Vertraulichkeitsverpflichtungen für alle mitwirkenden Personen vor?
23. Ist PII-Tokenisierung als optionales Modul vorgesehen?

### G  - Governance und Nachweisbarkeit

24. Ist ein Audit-Trail für Agenten-Entscheidungen als Vertragsbestandteil verankert?
25. Ist der Nachweis der TOMs auf Anfrage möglich (Konfigurationsnachweise, geschwärzte Logauszüge)?

## Von der Checkliste zur Architektur

Diese 25 Fragen sind kein juristisches Werkzeug. Sie sind ein Architektur-Kompass. Jede Frage, die Ihr KI-Vendor nicht beantworten kann, zeigt eine Lücke in seiner Infrastruktur  - nicht nur in seinem Vertrag.

Bei Gosign haben wir diese Anforderungen in die Architektur eingebaut: [Umgebungstrennung mit Prod-Lockdown](/de/magazin/ki-hosting-strategien-enterprise/), Logging ohne Inhaltsdaten, Modell-Provider im Kundentenant, [Decision Layer](/de/decision-layer/) mit vollständigem Audit-Trail. Nicht weil ein Kunde es verlangt hat, sondern weil Enterprise-KI ohne diese Grundlagen nicht auditierbar ist.

Wenn Sie prüfen möchten, wie Ihre aktuelle KI-Infrastruktur gegen diese 25 Punkte abschneidet  - oder wenn Sie eine neue Plattform evaluieren  - sprechen wir gerne darüber.

**[Gespräch vereinbaren →](/de/kontakt/)**

--- Betriebsrat und KI: Mitbestimmung by Design ---
> Betriebsvereinbarungen als technische Constraints im Decision Layer. Anforderungen als Regeln implementieren statt Kompromisse aushandeln.

Betriebsräte haben Mitbestimmungsrechte, wenn KI-Systeme Entscheidungen über Arbeitnehmer treffen. Der richtige Ansatz: Ihre Anforderungen als technische Constraints im Decision Layer implementieren, nicht als Kompromisse auf Papier.

Einen verhandlungsreifen Erstentwurf einer solchen KI-Betriebsvereinbarung erzeugt der [BV-KI-Drafter](/de/tools/bv-ki-drafter/) - mit Memo für den Betriebsrat und Verhandlungsleitfaden.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Auf einen Blick - Mitbestimmung als Architektur-Constraint</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Betriebsräte haben Mitbestimmungsrechte für KI nach BetrVG SS 87 (technische Überwachungseinrichtungen) und SS 90 (Arbeitsplatzgestaltung). KI-Agenten bei Personalentscheidungen erfordern ihre Zustimmung.</li>
<li>Der Standardansatz des "Überzeugens" behandelt den Betriebsrat als Hürde statt als Anforderungsquelle - und produziert nicht durchsetzbare Papierkompromisse.</li>
<li>Der architektonische Ansatz: Betriebsvereinbarungen werden zu technischen Regeln im Decision Layer. Sagt die BV "keine vollautomatisierten Leistungsbeurteilungen", erzwingt das System Human-in-the-Loop.</li>
<li>Das Auditor Portal gibt dem Betriebsrat verifizierbare Transparenz - jede Regel hat eine Control_ID, technische Implementierung und Evidence-Historie zur Einsicht.</li>
<li>Vier-Schritte-Prozess: bestehende BVen analysieren, Anforderungskatalog erstellen, als Controls im Decision Layer implementieren, Auditor-Portal-Zugang gewähren.</li>
</ul>
</div>

Laut der WSI-Betriebsrätebefragung der Hans-Böckler-Stiftung (2023/2025) hat rund jeder zehnte mitbestimmte Betrieb in der Privatwirtschaft KI eingeführt - Tendenz steigend. Eine eigene Betriebsvereinbarung, die den KI-Einsatz gezielt regelt, hat bislang nur ein kleiner Teil dieser Betriebe; KI-spezifische Vereinbarungen sind noch deutlich seltener als etwa Datenschutzvereinbarungen. Ein großer Teil des KI-Einsatzes erfolgt damit bislang ohne formale Mitbestimmungs-Governance.

<table>
<thead>
<tr><th>Betriebsvereinbarungs-Anforderung</th><th>Decision Layer Umsetzung</th><th>Verifizierung</th></tr>
</thead>
<tbody>
<tr><td>Keine vollautomatisierten Leistungsbeurteilungen</td><td>Human-in-the-Loop-Regel (erzwungen)</td><td>Eskalations-Logs im Auditor Portal</td></tr>
<tr><td>Quartalsbericht über KI-gestützte Entscheidungen</td><td>Automatische Berichtsgenerierung</td><td>Portal-Dashboard mit Live-Daten</td></tr>
<tr><td>KI-Stopp bei Verdacht auf Diskriminierung</td><td>Bias-Monitoring-Trigger</td><td>Alert-Log und Incident-Historie</td></tr>
<tr><td>Alle Controls aktiv und funktional</td><td>Control_ID pro Anforderung</td><td>Evidence-Historie pro Control</td></tr>
</tbody>
</table>

## Die übliche Herangehensweise: Den Betriebsrat überzeugen

In den meisten Unternehmen wird die Einführung von KI als Change-Management-Projekt betrachtet. Der Betriebsrat wird informiert, überzeugt, mitgenommen. Das Ziel: Zustimmung zur Betriebsvereinbarung.

Dieser Ansatz hat ein Problem: Er behandelt den Betriebsrat als Hürde, nicht als Anforderungsquelle. Die Betriebsvereinbarung wird als Kompromiss formuliert, in Juristensprache gegossen und in einem Ordner abgelegt. Die technische Umsetzung bleibt oft unklar.

## Der bessere Ansatz: Mitbestimmung als Architektur-Constraint

In der Gosign-Architektur werden Betriebsvereinbarungen als technische Constraints im [Decision Layer](/de/decision-layer/) implementiert. Die Anforderungen des Betriebsrats werden nicht als Kompromiss verhandelt, sondern als Regeln im System implementiert.

Wenn die Betriebsvereinbarung sagt: "Entscheidungen über Leistungsbeurteilungen dürfen nicht vollautomatisiert getroffen werden" - dann wird das als Human-in-the-Loop-Regel im Decision Layer implementiert. Der Agent kann diese Regel physisch nicht umgehen.

Wenn die Betriebsvereinbarung sagt: "Der Betriebsrat erhält quartalsweise einen Bericht über alle KI-gestützten Personalentscheidungen" - dann erzeugt das Auditor Portal diesen Bericht automatisch.

Wenn die Betriebsvereinbarung sagt: "Bei Verdacht auf diskriminierende Muster muss die KI-Nutzung für den betroffenen Prozess sofort gestoppt werden" - dann ist das ein Bias-Monitoring-Trigger im Decision Layer.

## Was der Betriebsrat sehen kann

Der Betriebsrat erhält Zugang zum Auditor Portal - mit einem dedizierten Read-only-Zugang, der auf die für ihn relevanten Controls beschränkt ist.

Er kann nachvollziehen:
- Welche Betriebsvereinbarungsregeln sind als Controls implementiert?
- Sind alle Controls aktiv und funktional?
- Wie häufig werden Human-in-the-Loop-Eskalationen ausgelöst?
- Gibt es Auffälligkeiten im Bias-Monitoring?

Diese Transparenz schafft Vertrauen - nicht durch Versprechen, sondern durch nachvollziehbare Technik.

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Kostenloses eBook: KI in HR</p>
<p class="text-body text-gosign-text mb-4">EU AI Act Checkliste, Decision-Framework, Betriebsrats-Perspektive und Readiness-Assessment - das Governance-Handbuch für HR-Verantwortliche.</p>
<a href="/de/ebook/ki-hr-governance-handbuch/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Jetzt kostenlos herunterladen</a>
</div>

## Praktisches Vorgehen

**Schritt 1:** Bestehende Betriebsvereinbarungen analysieren. Welche Regelungen betreffen KI-Einsatz direkt oder indirekt?

**Schritt 2:** Neue Betriebsvereinbarung für KI-Einsatz formulieren. Nicht als Prosa-Dokument, sondern als Anforderungskatalog mit konkreten, technisch umsetzbaren Regeln.

**Schritt 3:** Anforderungen als Controls im Decision Layer implementieren. Jede Anforderung bekommt eine Control_ID, eine technische Implementierung und einen Evidence-Generator.

**Schritt 4:** Betriebsrat erhält Auditor-Portal-Zugang. Er kann jederzeit nachvollziehen, ob seine Anforderungen technisch umgesetzt sind.

Mehr dazu: [Mitbestimmung und KI](/de/governance/mitbestimmung/)

<a href="/de/kontakt/" target="_blank" rel="noopener noreferrer">Termin vereinbaren</a> - Wir zeigen Ihnen, wie Mitbestimmung technisch umgesetzt wird.

--- Cert-Ready by Design - Prüfungssichere KI von Anfang an ---
> Cert-Ready by Design: Controls als First-Class-Datenobjekte, automatische Evidence-Generierung, Live-Status für Prüfer statt Snapshots

## Das Problem: Prüfungsbereitschaft als Projekt

In den meisten Unternehmen ist die Vorbereitung auf eine Prüfung - Jahresabschlussprüfung, Betriebsprüfung, SOC-2-Audit - ein Projekt. Wochen vor der Prüfung werden Dokumente zusammengestellt, Screenshots angefertigt, Nachweise aus verschiedenen Systemen exportiert und in Ordner sortiert.

Dieses Vorgehen hat drei Probleme: Es ist aufwendig, es ist fehleranfällig und es zeigt einen Snapshot statt eines Zustands. Der Prüfer sieht, wie das System zum Zeitpunkt der Dokumentation aussah - nicht wie es tatsächlich läuft.

Wenn KI-Agenten geschäftskritische Entscheidungen treffen, verschärft sich das Problem. Jede einzelne Agenten-Entscheidung muss nachvollziehbar sein, was klare [Governance](/de/governance/) erfordert. Bei Tausenden von Entscheidungen pro Monat ist eine manuelle Dokumentation nicht mehr möglich.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Auf einen Blick - Cert-Ready by Design</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Cert-Ready by Design bedeutet: Prüfungsbereitschaft ist ein Architekturprinzip, kein nachträgliches Dokumentationsprojekt.</li>
<li>Controls sind First-Class-Datenobjekte mit automatischer Evidence-Generierung, Regelversionierung und Live-Status für Prüfer.</li>
<li>ISACA (2023) berichtet, dass Organisationen mit kontinuierlichem Kontroll-Monitoring die Prüfungsvorbereitungszeit um bis zu 65 % reduzieren.</li>
<li>Framework-Mapping deckt ISA, PS 951 (IDW), GoB/GoBD ab - Evidence spricht die Sprache, die Prüfer verstehen.</li>
<li>Ergebnis: Die Prüfung KI-gestützter Verarbeitung dauert Stunden statt Wochen, mit vollständiger, manipulationssicherer Evidence.</li>
</ul>
</div>

## Was Cert-Ready by Design bedeutet

Cert-Ready by Design kehrt den Ansatz um: Die Prüfungsbereitschaft ist kein nachträglicher Prozess, sondern ein Architekturprinzip. Controls sind technische Datenobjekte im System. Evidence wird automatisch erzeugt. Prüfer sehen Live-Status statt Snapshot.

### Controls als First-Class-Datenobjekte

In der Cert-Ready-Architektur ist jede Kontrolle ein technisches Datenobjekt mit definierten Attributen:

| Element | Funktion |
|---------|----------|
| Control_ID | Eindeutige Identifikation der Kontrolle |
| Technical_Implementation | Konkrete technische Umsetzung (z.B. RLS-Policy, API-Check, Konfidenz-Schwellenwert) |
| Rule_Version | Version der zugrunde liegenden Entscheidungslogik |
| Evidence_Generator | Automatischer Prüfmechanismus der Evidence erzeugt |
| Evidence_History | Historisierte Prüfergebnisse mit Zeitstempel |
| Auditor_View | Drill-Down-fähige Darstellung bis zur Implementierung |

Controls sind keine Word-Dokumente in einem SharePoint-Ordner. Sie sind technische Objekte die im System leben, automatisch geprüft werden und ihren Status in Echtzeit widerspiegeln.

### Automatische Evidence-Generierung

Evidence wird nicht nachträglich zusammengestellt. Sie wird automatisch erzeugt - bei jeder Agenten-Entscheidung, bei jeder Regeländerung, bei jedem Systemereignis.

Ein Beispiel: Der Agent verarbeitet eine Eingangsrechnung. Der Decision Layer wendet Regel SKR03-7890 in Version 4.2 an. Konfidenz: 97%. Ergebnis: Buchungsvorschlag auf Konto 4400, Kostenstelle 1200. Keine Eskalation (Konfidenz über Schwellenwert, Betrag unter Wertgrenze).

Die Evidence für diesen Vorgang wird automatisch erzeugt: Input-Daten, angewandte Regel mit Version, Konfidenzwert, Routing-Entscheidung, Ergebnis, Zeitstempel. Diese Evidence ist unveränderlich und mit dem Buchungsbeleg verknüpft.

### Auditor Portal

Prüfer sehen im Auditor Portal den Live-Status aller Controls. Kein PDF-Export, kein Snapshot - sondern den aktuellen Zustand des Systems.

Das Auditor Portal bietet Drill-Down: Von der Control-Übersicht (Ampel-Dashboard: grün/gelb/rot) über die einzelne Kontrolle bis zur konkreten technischen Implementierung und der Evidence-Historie.

### Framework-Mapping

Controls werden auf etablierte Prüfungsstandards gemappt:

**ISA (International Standards on Auditing):** Für Jahresabschlussprüfungen. Die Controls bilden die internen Kontrollen ab, die der Abschlussprüfer im Rahmen seiner Prüfung beurteilt.

**PS 951 (IDW):** Für IT-Prüfungen. Die technischen Implementierungen der Controls werden auf die Anforderungen des PS 951 gemappt.

**GoB/GoBD:** Für die Ordnungsmäßigkeit der Buchführung. Die Versionierung der Regelwerke, die Unveränderlichkeit des Audit Trail und die Nachvollziehbarkeit jeder Buchungsentscheidung erfüllen die Anforderungen der GoBD.

Dieses Framework-Mapping stellt sicher, dass die automatisch erzeugte Evidence die Sprache spricht, die Prüfer verstehen.

## Cert-Ready in der Praxis

Eine Wirtschaftsprüfungsgesellschaft führt die Jahresabschlussprüfung bei einem Mandanten durch. Der Mandant setzt KI-Agenten für die Belegverarbeitung ein.

Der Prüfer öffnet das Auditor Portal. Er sieht: 12 Controls für die Belegverarbeitung, alle grün. Er klickt auf Control "BV-003: Vollständigkeit der Buchungsbelege". Er sieht: Die technische Implementierung (API-Check gegen Belegeingang), die aktuelle Regelversion, die Evidence der letzten 12 Monate (alle automatischen Prüfungen bestanden), den Konfidenz-Durchschnitt und die Eskalationsrate.

Er kann Drill-Down machen: Einzelne Belege stichprobenartig prüfen, den Entscheidungspfad nachvollziehen, die angewandte Regel in der zum Entscheidungszeitpunkt gültigen Version einsehen.

Das Ergebnis: Die Prüfung der IT-gestützten Verarbeitung dauert Stunden statt Wochen. Die Evidence ist vollständig, automatisch erzeugt und manipulationssicher.

Mehr dazu: [Cert-Ready by Design im Detail](/de/governance/cert-ready/)

<a href="/de/kontakt/" target="_blank" rel="noopener noreferrer">Termin vereinbaren</a> - Wir zeigen Ihnen das Auditor Portal live.

--- ChatGPT ohne Anmeldung: Vom Risiko zur Infrastruktur ---
> Unkontrollierte ChatGPT-Nutzung erzeugt Shadow AI. Wie eine DSGVO-konforme, modell-agnostische Chat-Infrastruktur mit Agenten-Anbindung das Problem löst.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Auf einen Blick - ChatGPT ohne Anmeldung: Unternehmensrisiko</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Mitarbeiter, die öffentliche KI-Tools ohne IT-Aufsicht nutzen, erzeugen Shadow AI - Prompts werden auf unkontrollierten Servern verarbeitet, potenziell für Modelltraining verwendet, ohne Audit Trail.</li>
<li>KI zu verbieten funktioniert nicht. Die Lösung ist eine modell-agnostische Chat-Infrastruktur unter Unternehmenskontrolle, die besser ist als die öffentliche Alternative.</li>
<li>Verizon DBIR (2024) zeigt, dass 74 % der Datenpannen ein menschliches Element beinhalten - unkontrollierte KI-Nutzung schafft eine völlig neue Kategorie der Datenexposition.</li>
<li>Der eigentliche Mehrwert entsteht, wenn das Chat-Interface zur Agenten-Plattform wird - Dokumente verarbeiten, Workflows orchestrieren, Wissensfragen beantworten.</li>
<li>Drei Architekturentscheidungen stehen jetzt an: Hosting-Modell, Modellstrategie und Agenten-Roadmap. Jeder Tag Verzögerung bedeutet mehr Shadow-AI-Exposition.</li>
</ul>
</div>

## Das Problem ist nicht ChatGPT. Das Problem ist der Kontrollverlust.

In praktisch jedem Unternehmen nutzen Mitarbeiter heute heimlich öffentliche KI-Tools. Mit privaten ChatGPT-Accounts, über dubiose Webseiten die „ChatGPT ohne Anmeldung" versprechen, per Copy-Paste in Claude.ai oder Gemini - ohne Wissen der IT, ohne Freigabe, ohne jede Governance. Die Hürde liegt bei null, der Produktivitätsgewinn ist sofort spürbar. Das Ergebnis: Schatten-IT im großen Stil.

Das Risiko dabei ist nicht theoretisch. Prompts an öffentliche KI-Dienste werden auf Servern außerhalb der Unternehmenskontrolle verarbeitet. Ohne Enterprise-Vertrag können eingegebene Daten für Modell-Training verwendet werden. Besonders gefährlich sind dabei die zahlreichen Drittanbieter-Seiten, die „ChatGPT kostenlos und ohne Anmeldung" anbieten: Hier fehlt selbst der minimale Schutz, den ein direkter OpenAI-Account bietet. Vertrauliche Informationen - Gehaltsdaten, Vertragsentwürfe, Strategiepapiere - landen in Systemen, auf die das Unternehmen keinen Zugriff, keine Löschrechte und keine Audit-Möglichkeit hat.

IT-Abteilungen stehen vor einem Dilemma: Verbieten funktioniert nicht, weil der Nutzen zu offensichtlich ist und Mitarbeiter Wege finden. Dulden ist keine Option, weil DSGVO, Betriebsrat und interne Revision irgendwann fragen werden.

Die Antwort ist weder Verbot noch Duldung. Die Antwort ist Infrastruktur.


## Was Mitarbeiter eigentlich brauchen - und warum sie heimlich ChatGPT nutzen

Wenn Mitarbeiter trotz Verbot zu ChatGPT greifen, zeigt das vor allem eines: Das Unternehmen bietet keine Alternative. Was Mitarbeiter suchen, ist ein einfaches Interface, das sofort funktioniert, natürliche Sprache versteht und bei der täglichen Arbeit hilft. Texte zusammenfassen, E-Mails formulieren, Dokumente analysieren, Fragen zu internen Richtlinien beantworten.

Diese Anforderung ist legitim. Aber sie muss in einer Umgebung erfüllt werden, die das Unternehmen kontrolliert - nicht auf Servern von Drittanbietern, die mit „ChatGPT ohne Anmeldung" werben und deren Geschäftsmodell im Datensammeln besteht.

Eine Enterprise-Chat-Infrastruktur gibt jedem Mitarbeiter genau dieses Interface - mit einem entscheidenden Unterschied: Die Daten bleiben in der Unternehmensinfrastruktur. Prompts werden nicht an Dritte übertragen. Nutzung wird geloggt und ist auditierbar. Zugriffsrechte folgen dem bestehenden Rollenkonzept. Und das Wichtigste: Mitarbeiter müssen nicht mehr heimlich zu externen Tools greifen, weil sie eine bessere, offizielle Alternative haben.


## Warum modell-agnostisch der einzig sinnvolle Ansatz ist

Der häufigste Fehler bei der Einführung von Enterprise-KI: ein einzelnes Modell eines einzelnen Anbieters als Standard setzen. ChatGPT Enterprise, Copilot für alle, oder ein fixer Claude-Vertrag.

Das Problem: LLMs entwickeln sich schneller als jede Enterprise-Beschaffung. Was heute das beste Modell für Textanalyse ist, kann in sechs Monaten von einem günstigeren oder leistungsfähigeren Modell abgelöst werden. Wer seine gesamte Infrastruktur auf einen Anbieter baut, hat Vendor-Lock-in bei der kritischsten Technologieentscheidung der nächsten Jahre.

Eine modell-agnostische Architektur löst dieses Problem: Ein einheitliches Chat-Interface für alle Mitarbeiter. Dahinter eine Orchestrierungsschicht, die verschiedene Modelle routing - Claude, ChatGPT, Gemini, Llama, Mistral, DeepSeek, gpt-oss. Je nach Anwendungsfall, Kosten oder Datenschutzanforderung wird das passende Modell automatisch ausgewählt. Modellwechsel erfolgen ohne Änderung am Interface und ohne Umschulung der Mitarbeiter.

Gosign baut diese [KI-Infrastruktur](/de/leistungen/infrastruktur/) modell-agnostisch und plattformoffen - als Cloud-Deployment in Azure oder GCP, oder komplett Self-Hosted in der eigenen Infrastruktur.


## Vom Chat-Interface zur Agenten-Plattform

Ein DSGVO-konformes Chat-Interface ist der Einstieg. Aber die eigentliche Wertschöpfung beginnt, wenn das Interface nicht nur Fragen beantwortet, sondern Prozesse anstößt.

Das ist der Übergang vom Chat zur Agenten-Infrastruktur.

Konkret bedeutet das: Ein Mitarbeiter lädt im Chat eine Krankmeldung hoch. Ein [Document Agent](/de/leistungen/ai-agents/) liest das Dokument, extrahiert relevante Daten, prüft Fristen gegen die Betriebsvereinbarung und bereitet die Buchung in SAP vor. Ein [Workflow Agent](/de/leistungen/ai-agents/) orchestriert den Folgeprozess: Vorgesetzten informieren, Vertretung prüfen, Lohnfortzahlung berechnen. Ein Knowledge Agent beantwortet Rückfragen des Mitarbeiters auf Basis der aktuellen Unternehmensrichtlinien.

Das Chat-Interface wird zum einheitlichen Einstiegspunkt für alle drei Agenten-Typen. Der Mitarbeiter sieht ein einfaches Gespräch. Im Hintergrund orchestriert die Infrastruktur dokumentenbasierte, workflow-basierte und wissensbasierte Agenten - mit vollständigem Audit-Trail und [Human-in-the-Loop](/de/governance/) bei kritischen Entscheidungen.


## Governance ist kein Feature. Governance ist die Architektur.

Jede unkontrollierte ChatGPT-Nutzung erzeugt einen blinden Fleck: Welche Daten wurden eingegeben? Welche Antworten wurden für Entscheidungen genutzt? Wer hat wann was gefragt?

In einer Enterprise-Chat-Infrastruktur mit [Governance by Design](/de/governance/) existieren diese blinden Flecken nicht.

Jede Interaktion wird geloggt - Prompt, Antwort, verwendetes Modell, Zeitstempel, Nutzerrolle. Entscheidungsrelevante Aktionen durchlaufen den [Decision Layer](/de/decision-layer/), der Analyse und Entscheidung trennt. Kritische Prozesse erfordern menschliche Freigabe, architektonisch verankert als Human-in-the-Loop.

Für den Betriebsrat bedeutet das: Transparenz über den Einsatz von KI im Unternehmen, dokumentiert und jederzeit prüfbar. Für die interne Revision: lückenloser Audit-Trail. Für den Datenschutzbeauftragten: Datenverarbeitung in kontrollierter Umgebung, keine Übertragung an Dritte, DSGVO-konform dokumentiert.


## Risikobewertung: Öffentliche KI vs. Enterprise-Infrastruktur

| Risikokategorie | Öffentliches ChatGPT / Drittanbieter | Enterprise-Chat-Infrastruktur |
|---|---|---|
| Datensouveränität | Keine Kontrolle - Daten auf externen Servern | Volle Kontrolle - Self-Hosted oder EU-Cloud |
| Modelltraining | Daten können für Training genutzt werden | Kein Training mit Unternehmensdaten |
| Audit Trail | Keiner | Vollständig - Prompt, Antwort, Nutzer, Modell |
| DSGVO-Konformität | Nicht gewährleistet | Durch Architektur erzwungen |
| Zugriffskontrolle | Persönliche Accounts, kein RBAC | SSO mit rollenbasiertem Zugriff |
| Agenten-Integration | Nicht möglich | Document, Workflow, Knowledge Agents |
| Vendor Lock-in | An einen Anbieter gebunden | Modell-agnostisch - Modelle tauschbar |

## Was die IT-Abteilung jetzt entscheiden muss

Die Frage ist nicht mehr, ob Mitarbeiter KI nutzen. Die Frage ist, ob sie es in einer kontrollierten oder unkontrollierten Umgebung tun.

Drei Architekturentscheidungen stehen an.

Erstens: Hosting. Soll die Chat-Infrastruktur in Azure, GCP oder komplett Self-Hosted laufen? Die Antwort hängt von der bestehenden IT-Landschaft und den Datenschutzanforderungen ab. Alle drei Optionen sind technisch gleichwertig - es gibt keine architektonischen Kompromisse beim Self-Hosting.

Zweitens: Modellstrategie. Welche Modelle sollen verfügbar sein und wie wird das Routing gesteuert? Eine modell-agnostische Architektur hält alle Optionen offen und vermeidet Vendor-Lock-in.

Drittens: Agenten-Roadmap. Soll das Chat-Interface perspektivisch Agenten anbinden, die Dokumente verarbeiten und Workflows orchestrieren? Wenn ja - und die Antwort ist fast immer ja - dann muss die Infrastruktur von Anfang an darauf ausgelegt sein.

Bei Gosign bauen wir genau diese Infrastruktur: modell-agnostisch, DSGVO-konform, mit Agenten-Anbindung und Governance by Design. In 4 - 6 Wochen vom Konzept zum produktiven Chat-Interface. In der [Infrastruktur des Kunden](/de/leistungen/infrastruktur/), unter voller Kundenkontrolle. Kein SaaS, kein Vendor-Lock-in.

--- Claude Code als Sicherheitskontrolle im DevOps-Workflow ---
> DevOps-Runbook für automatisierte Security Reviews mit Claude Code: Installation, Custom Commands, Audit-Scripts und CI-Integration.

Moderne self-hosted App-Stacks bestehen aus vielen Komponenten: Supabase Platform, Next.js App Layer, Edge Functions, Background Jobs und externe APIs. Mit jeder Komponente steigt die Wahrscheinlichkeit für Konfigurationsfehler, Secret Leaks, fehlende Policies und ungesicherte Endpunkte.

Traditionelle Security-Scanner prüfen statische Regeln. Sie finden `service_role` in einer `.env` Datei, aber sie erkennen nicht, dass eine neue Server Action denselben Ownership-Check vermisst, der in allen anderen Server Actions vorhanden ist. Sie melden offene Ports, aber sie erkennen nicht, dass eine Firewall-Änderung letzte Woche zusammen mit einem neuen Container einen unbeabsichtigten Zugriffspfad eröffnet hat.

**Claude Code schliesst diese Lücke als kontextuelle Analyse-Schicht über dem gesamten Stack.** Untersuchungen zeigen, dass kontextuelle Code-Reviews bis zu 31% mehr Sicherheitsprobleme identifizieren als rein regelbasierte Scanner (GitHub Security Lab 2024).

Claude Code ersetzt keine deterministischen Checks. Es ergänzt sie, indem es die Ergebnisse interpretiert, Zusammenhänge erkennt und Empfehlungen priorisiert.

Dieses Runbook beschreibt, wie Claude Code konkret installiert, konfiguriert und in den DevOps-Workflow integriert wird.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Auf einen Blick - Artikel 5 von 6 der DevOps-Runbook-Serie</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Claude Code läuft ausschließlich auf dem Audit-Server (nicht auf Produktion)</li>
<li>Drei-Ebenen-Modell: deterministische Checks, Runbook-Regeln, Claude Kontextanalyse</li>
<li>Custom Commands in .claude/commands/ definieren den Prüfumfang</li>
<li>Headless Mode mit --allowedTools auf Read,Grep,Glob einschränken (kein Bash)</li>
<li>Wöchentlicher Cron-Audit plus Ad-hoc-Reviews bei Pull Requests</li>
</ul>
</div>

## Serien-Inhaltsverzeichnis

Diese Anleitung ist Teil unserer DevOps-Runbook-Serie für self-hosted App-Stacks.

1. [Supabase Self-Hosting Runbook](/de/magazin/supabase-self-hosting/)
2. [Next.js über Supabase sicher betreiben](/de/magazin/nextjs-supabase-sicher-betreiben/)
3. [Supabase Edge Functions sicher einsetzen](/de/magazin/supabase-edge-functions-sicher/)
4. [Trigger.dev Background Jobs sicher betreiben](/de/magazin/trigger-dev-background-jobs/)
5. [Claude Code als Sicherheitskontrolle im DevOps-Workflow](/de/magazin/claude-code-security-devops/) - dieser Artikel
6. [Security Baseline für den gesamten Stack](/de/magazin/security-baseline-stack/)

Die ersten vier Artikel beschreiben die einzelnen Komponenten - von der [Supabase-Infrastruktur](/de/magazin/supabase-self-hosting/#teil-a---infrastruktur-entscheidungen) über die [Next.js Sicherheitschecks](/de/magazin/nextjs-supabase-sicher-betreiben/#b1---environment-variablen-trennen) bis zu den [Trigger.dev Task-Konfigurationen](/de/magazin/trigger-dev-background-jobs/#b1---tasks-korrekt-definieren-v3-api). Dieser Artikel beschreibt die **Security-Kontrollschicht darüber**.

## Architekturüberblick

Claude Code arbeitet **nicht auf dem Produktionsserver**, sondern auf dem Audit-Server (siehe [Artikel 1](/de/magazin/supabase-self-hosting/)). Es hat Read-Only-Zugang zu den Daten, die es analysiert.

```
Produktionsserver (supabase-prod)
   |
   +-- Supabase Stack
   +-- Next.js App
   +-- Edge Functions
   +-- Trigger.dev
   |
   +---- SSH (read-only) ----> Audit-Server (audit-runner)
                                   |
                                   +-- Deterministische Checks
                                   |   +-- Port Scans (nmap)
                                   |   +-- Firewall Diff (iptables-save)
                                   |   +-- Container Versionen (docker images)
                                   |   +-- RLS Status (psql)
                                   |   +-- npm audit
                                   |   +-- grep-basierte Code Checks
                                   |
                                   +-- Claude Code (headless)
                                   |   +-- Analysiert Check-Ergebnisse
                                   |   +-- Liest Git Diffs
                                   |   +-- Prüft Configs gegen Runbooks
                                   |   +-- Erstellt priorisierten Report
                                   |
                                   +-- Report -> DevOps Team (Mensch entscheidet)
```

**Claude Code führt keine Änderungen am Produktionssystem aus. Keine Deployments, keine Secret-Rotation, keine Container-Stops.**

## Grundprinzip: Drei Ebenen der Sicherheitsprüfung

```
Ebene 1: Deterministische Checks (Scripts)
   -> Objektive, wiederholbare Ergebnisse
   -> Beispiel: "Port 5432 ist von aussen erreichbar" = Fakt

Ebene 2: Runbook-Regeln (Markdown-Dateien)
   -> Definierter Soll-Zustand des Stacks
   -> Beispiel: "Postgres darf nur auf 10.0.1.10 lauschen"

Ebene 3: Claude Code Kontextanalyse (headless)
   -> Interpretiert Ergebnisse, erkennt Zusammenhänge
   -> Beispiel: "Port 5432 ist offen UND der neue Container
     hat eine direkte DB-Connection. Das ist ein Problem."
```

Die Ebenen bauen aufeinander auf. Claude bekommt die Ergebnisse von Ebene 1 und die Regeln von Ebene 2 als Input und erstellt daraus seinen kontextuellen Review.

### Vergleich der drei Prüfebenen

| Eigenschaft | Deterministische Checks | Runbook-Regeln | Claude Code Analyse |
|-------------|------------------------|----------------|-------------------|
| Ausführung | Automatisch (Scripts) | Referenzdokument | Headless Mode (CLI) |
| Ergebnis | Fakt (ja/nein) | Soll-Zustand | Interpretation + Priorität |
| Frequenz | Täglich | Statisch (bei Änderung) | Wöchentlich / bei PR |
| Stärke | Zuverlässig bei bekannten Mustern | Definierte Standards | Erkennt unbekannte Muster |
| Schwäche | Sieht keine Zusammenhänge | Nicht selbstprüfend | Nicht deterministisch |
| Beispiel | "Port 5432 offen" | "Postgres nur auf 10.0.1.10" | "Port offen UND neuer Container = Problem" |

## Teil A - Claude Code einrichten

## A1 - Installation und Konfiguration auf dem Audit-Server

### Umsetzung

Claude Code wird auf dem Audit-Server installiert, nicht auf dem Produktionsserver.

```bash
# Auf dem audit-runner Server

# Node.js installieren (falls nicht vorhanden)
curl -fsSL https://deb.nodesource.com/setup_20.x | sudo bash -
apt-get install -y nodejs

# Claude Code installieren
npm install -g @anthropic-ai/claude-code

# API Key konfigurieren
# Eigener API Key mit Budget-Limit für CI/CD
export ANTHROPIC_API_KEY="sk-ant-..."

# In .bashrc oder .env für den audit-user persistieren
echo 'export ANTHROPIC_API_KEY="sk-ant-..."' >> /home/audit/.bashrc
```

**Headless Mode testen:**

```bash
# Einfacher Test: funktioniert Claude Code non-interaktiv?
echo "Hello" | claude -p "Antworte mit OK wenn du das lesen kannst" \
  --output-format text

# Erwartung: "OK" oder ähnliche Bestätigung
```

### Prüfbare Bedingung

```bash
# Claude Code installiert?
claude --version
# Erwartung: Versionsnummer

# API Key gesetzt?
test -n "$ANTHROPIC_API_KEY" && echo "OK" || echo "FEHLT"

# Headless Mode funktioniert?
claude -p "Sage nur: OK" --output-format text --max-turns 1 2>/dev/null
# Erwartung: "OK"
```

### Failure Scenario

Wenn Claude Code auf dem Produktionsserver läuft und dort Bash-Zugriff hat, könnte ein fehlerhafter Prompt theoretisch Befehle auf dem Produktionssystem ausführen. Auf dem Audit-Server hat Claude Code nur Zugriff auf die dort gesammelten Reports und Config-Kopien, nicht auf das Live-System.

## A2 - Custom Security Review Command einrichten

### Umsetzung

Claude Code unterstützt Custom Commands über Markdown-Dateien in `.claude/commands/`. Diese Commands definieren den Kontext und die Prüfregeln für den Security Review.

```bash
# Im Infrastruktur-Repository
mkdir -p .claude/commands
```

```markdown
# .claude/commands/security-review.md

Du bist Security Reviewer für einen self-hosted Stack bestehend aus:
- Supabase (PostgreSQL, PostgREST, GoTrue, Kong, Edge Functions)
- Next.js (App-Schicht, Server Actions, Route Handler)
- Trigger.dev v3 (Background Jobs, self-hosted)
- Alles auf Hetzner Cloud (EU, eigene Server)

Du erhältst den Output der deterministischen Security Checks und die
aktuellen Konfigurationsdateien.

Prüfe folgendes:

## Infrastruktur (Artikel 1)
- Sind unerwartete Ports von aussen erreichbar?
- Hat sich die Firewall gegenüber der Baseline geändert?
- Sind Container-Versionen gepinnt und aktuell?
- Ist das TLS-Zertifikat noch mindestens 14 Tage gültig?
- Liegt das letzte Backup weniger als 26 Stunden zurück?

## Next.js (Artikel 2)
- Taucht service_role in NEXT_PUBLIC Variablen oder im Client-Bundle auf?
- Haben alle Server Actions einen getUser() Auth Check?
- Haben alle Route Handler einen getUser() Auth Check?
- Existiert middleware.ts mit getUser() (nicht getSession())?
- Sind Security Headers in next.config.js gesetzt?

## Edge Functions (Artikel 3)
- Haben alle Webhook-Functions eine Signaturprüfung?
- Gibt es Functions mit Business-Logik statt Integrations-Logik?
- Ist CORS korrekt konfiguriert (kein Wildcard in Produktion)?
- Gibt es hardcoded Secrets im Function-Code?

## Trigger.dev (Artikel 4)
- Haben alle Tasks maxDuration und concurrencyLimit?
- Haben Tasks mit externen API-Calls Idempotency Keys?
- Nutzen Tasks nur die DB-Felder die sie brauchen (kein SELECT *)?
- Gibt es console.log statt dem Trigger.dev logger?

## Stackübergreifend
- Gibt es Architektur-Drift? (Business-Logik in Edge Functions,
  Langläufer in Server Actions, etc.)
- Sind die Änderungen der letzten Woche konsistent mit der
  bestehenden Architektur?
- Gibt es neue Tabellen ohne RLS?
- Gibt es Muster die auf systematische Probleme hindeuten?

Erstelle einen priorisierten Bericht:
- KRITISCH: sofort handeln (Daten-Leak möglich, Port offen, Secret exponiert)
- WARNUNG: diese Woche lösen (fehlende Checks, Drift, veraltete Packages)
- INFO: bei Gelegenheit verbessern (Code-Qualität, fehlende Tests)

Für jedes Finding: Was ist das Problem, warum ist es ein Risiko,
was ist die konkrete Lösung.
```

### Prüfbare Bedingung

```bash
# Custom Command existiert?
test -f .claude/commands/security-review.md && echo "OK" || echo "FEHLT"

# Command wird von Claude Code erkannt?
claude -p "/security-review" --max-turns 1 2>/dev/null | head -5
# Erwartung: Claude beginnt mit der Analyse
```

## A3 - CLAUDE.md als Projekt-Kontext

### Umsetzung

Claude Code liest automatisch die `CLAUDE.md` Datei im Projektverzeichnis. Diese Datei gibt Claude den permanenten Kontext über euren Stack.

```markdown
# CLAUDE.md (im Root des Infrastruktur-Repos)

## Stack-Überblick
Self-hosted Supabase + Next.js + Edge Functions + Trigger.dev v3
auf Hetzner Cloud (EU, eigene Server).

## Server
- supabase-prod: 10.0.1.10 (Supabase, Next.js, Edge Functions)
- audit-runner: 10.0.1.11 (Security Checks, Claude Code, Monitoring)
- trigger-server: separater Docker-Stack für Trigger.dev v3

## Sicherheitsregeln
- service_role Key darf NUR in: lib/supabase/admin.ts und trigger/lib/supabase.ts
- NEXT_PUBLIC_* darf NUR enthalten: SUPABASE_URL und SUPABASE_ANON_KEY
- Alle public-Tabellen müssen RLS aktiviert haben
- Alle Server Actions und Route Handler müssen getUser() aufrufen
- Alle Webhook Edge Functions müssen Signaturen prüfen
- Alle Trigger.dev Tasks müssen maxDuration und concurrencyLimit haben
- PostgreSQL nur auf 10.0.1.10:5432 (internes Interface)
- Supabase Studio nicht von aussen erreichbar
- Trigger.dev Dashboard nicht von aussen erreichbar

## Deployment
- Infrastruktur wird nur über Git deployed (kein manuelles SSH-Editing)
- Edge Functions werden als Dateien in volumes/functions/ abgelegt
- Trigger.dev Tasks werden über npx trigger.dev deploy --self-hosted deployed

## Verzeichnisstruktur
- app/ = Next.js App (Server Actions, Route Handler, Pages)
- lib/supabase/ = Supabase Client Konfiguration
- middleware.ts = Auth Middleware
- volumes/functions/ = Supabase Edge Functions
- trigger/tasks/ = Trigger.dev Tasks
- infra/ = docker-compose, nginx/caddy, Firewall Configs
- scripts/ = Audit Scripts, Backup, Restore
- runbooks/ = Sicherheits-Runbooks
```

Wer den [CLAUDE.md-Ansatz mit den Sicherheitsregeln aus Artikel 2](/de/magazin/nextjs-supabase-sicher-betreiben/) kombiniert, bekommt eine lückenlose Kontextbasis für automatisierte Reviews.

## Teil B - Der Gesamt-Audit-Workflow

Hier kommt zusammen, was die [Artikel 1 bis 4](/de/magazin/supabase-self-hosting/) vorbereitet haben. Jeder Artikel hat eigene Check-Scripts. Artikel 5 führt sie zusammen und gibt den Output an Claude Code.

## B1 - Das Gesamt-Audit-Script

### Umsetzung

Dieses Script sammelt alle Ergebnisse der deterministischen Checks und übergibt sie an Claude Code im Headless Mode.

```bash
#!/bin/bash
# scripts/full-security-audit.sh
# Läuft auf dem audit-runner Server

set -euo pipefail

PROD_HOST="10.0.1.10"
REPORT_DIR="/opt/audit/reports"
DATE=$(date +%Y-%m-%d)
REPORT_FILE="${REPORT_DIR}/audit-input-${DATE}.md"

mkdir -p "$REPORT_DIR"

echo "=== Gesamt-Security-Audit ${DATE} ===" | tee "$REPORT_FILE"

# -------------------------------------------
# EBENE 1: Deterministische Checks
# -------------------------------------------

echo -e "\n# Deterministische Check-Ergebnisse\n" >> "$REPORT_FILE"

# --- Infrastruktur (Artikel 1) ---
echo "## Infrastruktur" >> "$REPORT_FILE"

echo "### Offene Ports (extern)" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
nmap -p 22,80,443,3000,3040,5432,5433,8000,9000 app.example.com \
  --open -oG - 2>/dev/null >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"

echo "### Firewall Diff gegen Baseline" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "iptables-save" | \
  diff /opt/baselines/firewall-baseline.txt - >> "$REPORT_FILE" 2>&1 || true
echo '```' >> "$REPORT_FILE"

echo "### Container Status" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "docker compose ps --format 'table {{.Name}}\t{{.Status}}\t{{.Image}}'" \
  >> "$REPORT_FILE" 2>&1
echo '```' >> "$REPORT_FILE"

echo "### TLS Zertifikat" >> "$REPORT_FILE"
CERT_EXPIRY=$(echo | openssl s_client -connect app.example.com:443 2>/dev/null | \
  openssl x509 -noout -enddate 2>/dev/null | cut -d= -f2)
CERT_EPOCH=$(date -d "$CERT_EXPIRY" +%s 2>/dev/null || echo 0)
NOW_EPOCH=$(date +%s)
DAYS_LEFT=$(( (CERT_EPOCH - NOW_EPOCH) / 86400 ))
echo "Ablauf: ${CERT_EXPIRY} (${DAYS_LEFT} Tage)" >> "$REPORT_FILE"

echo "### Backup Status" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "ls -lh /opt/backups/*.gpg 2>/dev/null | tail -3" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"

echo "### RLS Status" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "docker compose exec -T postgres psql -U postgres -c \
  \"SELECT tablename, rowsecurity FROM pg_tables WHERE schemaname = 'public' ORDER BY tablename;\"" \
  >> "$REPORT_FILE" 2>&1
echo '```' >> "$REPORT_FILE"

echo "### Disk Usage" >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "df -h / | tail -1" >> "$REPORT_FILE"

# --- Next.js (Artikel 2) ---
echo -e "\n## Next.js App-Schicht" >> "$REPORT_FILE"

echo "### service_role im Client Code" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "cd /opt/app && grep -rn 'SERVICE_ROLE\|service_role' app/ \
  --include='*.ts' --include='*.tsx' | grep -v 'lib/supabase/admin.ts' | grep -v node_modules" \
  >> "$REPORT_FILE" 2>&1 || echo "Keine Treffer" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"

echo "### NEXT_PUBLIC mit Secrets" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "cd /opt/app && grep 'NEXT_PUBLIC_' .env* 2>/dev/null | \
  grep -iE 'service_role|secret|private|database'" \
  >> "$REPORT_FILE" 2>&1 || echo "Keine Treffer" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"

echo "### Server Actions ohne Auth" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "cd /opt/app && for file in \$(grep -rl \"'use server'\" app/ --include='*.ts'); do
  if ! grep -q 'getUser' \"\$file\"; then
    echo \"WARNUNG: \$file\"
  fi
done" >> "$REPORT_FILE" 2>&1 || echo "Keine Treffer" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"

echo "### Route Handler ohne Auth" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "cd /opt/app && for file in \$(find app/api -name 'route.ts' 2>/dev/null); do
  if ! grep -q 'getUser' \"\$file\"; then
    echo \"WARNUNG: \$file\"
  fi
done" >> "$REPORT_FILE" 2>&1 || echo "Keine Treffer" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"

echo "### npm audit" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "cd /opt/app && npm audit --audit-level=high 2>&1 | tail -20" \
  >> "$REPORT_FILE" 2>&1
echo '```' >> "$REPORT_FILE"

# --- Edge Functions (Artikel 3) ---
echo -e "\n## Edge Functions" >> "$REPORT_FILE"

echo "### Webhook Functions ohne Signaturprüfung" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "for dir in /opt/supabase/volumes/functions/*-webhook/; do
  [ -d \"\$dir\" ] || continue
  name=\$(basename \"\$dir\")
  if ! grep -qE 'signature|verify|hmac|crypto' \"\$dir/index.ts\" 2>/dev/null; then
    echo \"KRITISCH: \$name hat keine Signaturprüfung\"
  else
    echo \"OK: \$name\"
  fi
done" >> "$REPORT_FILE" 2>&1
echo '```' >> "$REPORT_FILE"

echo "### Hardcoded Secrets in Functions" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "grep -rn 'sk_live\|sk_test\|whsec_\|Bearer ey' \
  /opt/supabase/volumes/functions/ --include='*.ts' 2>/dev/null" \
  >> "$REPORT_FILE" 2>&1 || echo "Keine Treffer" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"

# --- Trigger.dev (Artikel 4) ---
echo -e "\n## Trigger.dev Tasks" >> "$REPORT_FILE"

echo "### Tasks ohne maxDuration" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "cd /opt/app && for file in trigger/tasks/*.ts; do
  name=\$(basename \"\$file\" .ts)
  if ! grep -q 'maxDuration' \"\$file\" 2>/dev/null; then
    echo \"WARNUNG: \$name\"
  fi
done" >> "$REPORT_FILE" 2>&1
echo '```' >> "$REPORT_FILE"

echo "### Tasks ohne Concurrency Limit" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "cd /opt/app && for file in trigger/tasks/*.ts; do
  name=\$(basename \"\$file\" .ts)
  if ! grep -qE 'concurrencyLimit|queue:' \"\$file\" 2>/dev/null; then
    echo \"WARNUNG: \$name\"
  fi
done" >> "$REPORT_FILE" 2>&1
echo '```' >> "$REPORT_FILE"

# --- Git Änderungen ---
echo -e "\n## Code-Änderungen (letzte 7 Tage)" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "cd /opt/app && git log --oneline --since='7 days ago'" \
  >> "$REPORT_FILE" 2>&1
ssh deploy@${PROD_HOST} "cd /opt/app && git diff HEAD~10 --stat 2>/dev/null" \
  >> "$REPORT_FILE" 2>&1
echo '```' >> "$REPORT_FILE"

# -------------------------------------------
# EBENE 2: Runbook-Regeln (als Kontext)
# -------------------------------------------

echo -e "\n# Aktive Runbook-Regeln\n" >> "$REPORT_FILE"
cat runbooks/security-baseline.md >> "$REPORT_FILE" 2>/dev/null || \
  echo "security-baseline.md nicht gefunden" >> "$REPORT_FILE"

# -------------------------------------------
# EBENE 3: Claude Code Analyse
# -------------------------------------------

echo ""
echo "=== Deterministische Checks abgeschlossen ==="
echo "=== Starte Claude Code Analyse ==="
echo ""

# Claude Code im Headless Mode aufrufen
# --allowedTools einschränken: nur Lesen, kein Bash, kein Schreiben
CLAUDE_OUTPUT=$(cat "$REPORT_FILE" | claude -p \
  "Du erhältst den vollständigen Security-Audit-Report unseres self-hosted Stacks.
Analysiere ihn gemäss den Regeln in .claude/commands/security-review.md.
Erstelle einen priorisierten Bericht mit KRITISCH / WARNUNG / INFO.
Für jedes Finding: Problem, Risiko, konkrete Lösung." \
  --allowedTools "Read,Grep,Glob" \
  --append-system-prompt "Du bist ein Senior Security Engineer. Antworte auf Deutsch. Sei konkret und priorisiere strikt." \
  --output-format text \
  --max-turns 5 \
  2>/dev/null)

# Report speichern
CLAUDE_REPORT="${REPORT_DIR}/claude-review-${DATE}.md"
echo "$CLAUDE_OUTPUT" > "$CLAUDE_REPORT"

echo ""
echo "=== Claude Code Review abgeschlossen ==="
echo "Report: $CLAUDE_REPORT"

# Bei kritischen Findings: Alert
if echo "$CLAUDE_OUTPUT" | grep -qi "KRITISCH"; then
  echo "$CLAUDE_OUTPUT" | mail -s "KRITISCH: Security Review ${DATE}" ops@example.com
  echo "Alert gesendet an ops@example.com"
fi
```

### Prüfbare Bedingung

```bash
# Script ausführbar?
test -x scripts/full-security-audit.sh && echo "OK" || echo "NICHT AUSFÜHRBAR"

# Letzter Audit-Report vorhanden?
ls -la /opt/audit/reports/claude-review-$(date +%Y-%m-%d).md 2>/dev/null
# Erwartung: Datei von heute

# Report enthält die erwarteten Sektionen?
grep -c "KRITISCH\|WARNUNG\|INFO" /opt/audit/reports/claude-review-$(date +%Y-%m-%d).md
# Erwartung: mindestens 1
```

## B2 - Wann der Audit läuft

### Drei Trigger-Punkte

```
1. Wöchentlicher Cron (Sonntag 6:00 Uhr)
   -> Vollständiger Audit über den gesamten Stack
   -> Ergebnis: Priorisierter Report für die Woche

2. Bei Pull Requests (CI/CD)
   -> Nur die geänderten Dateien
   -> Ergebnis: Review-Kommentar am PR

3. Ad-hoc (manuell)
   -> Nach Incidents, größeren Deployments, Infrastruktur-Änderungen
   -> Ergebnis: Sofort-Analyse
```

**Wöchentlicher Cron:**

```bash
# crontab auf dem audit-runner
0 6 * * 0 /opt/audit/scripts/full-security-audit.sh >> /var/log/security-audit.log 2>&1
```

**PR Review (Git Diff an Claude pipen):**

```bash
#!/bin/bash
# scripts/pr-security-review.sh
# Wird vom CI bei jedem PR aufgerufen

DIFF=$(git diff origin/main...HEAD)

if [ -z "$DIFF" ]; then
  echo "Kein Diff, kein Review nötig"
  exit 0
fi

echo "$DIFF" | claude -p \
  "Review diesen Git Diff auf Sicherheitsprobleme.
Prüfe insbesondere:
- service_role Nutzung in Client-Code
- Server Actions ohne Auth Check
- Edge Functions ohne Signaturprüfung
- Trigger.dev Tasks ohne maxDuration
- Hardcoded Secrets
- Neue API Endpoints ohne Rate Limiting

Antworte NUR wenn du ein konkretes Problem findest.
Wenn alles in Ordnung ist, sage: Keine Sicherheitsprobleme gefunden." \
  --allowedTools "Read,Grep,Glob" \
  --output-format text \
  --max-turns 3
```

**Ad-hoc Review:**

```bash
# Manuell nach einem Incident
cd /opt/infra-repo
claude -p "Prüfe den aktuellen Zustand des Repositories auf Sicherheitsprobleme. \
Fokus auf die letzten 5 Commits." \
  --allowedTools "Read,Grep,Glob,Bash(git log*),Bash(git diff*)" \
  --max-turns 10
```

### Prüfbare Bedingung

```bash
# Cron Job aktiv?
crontab -l | grep "full-security-audit"
# Erwartung: Eintrag vorhanden

# Letzter Audit weniger als 8 Tage her?
LAST_REPORT=$(ls -t /opt/audit/reports/claude-review-*.md 2>/dev/null | head -1)
if [ -n "$LAST_REPORT" ]; then
  AGE=$(( ($(date +%s) - $(stat -c %Y "$LAST_REPORT")) / 86400 ))
  echo "Letzter Report: $AGE Tage alt"
  [ "$AGE" -gt 8 ] && echo "WARNUNG: Audit überfällig"
fi
```

## Teil C - Was Claude kann und was nicht

## C1 - Wo Claude Code besonders stark ist

Claude erkennt Zusammenhänge, die deterministische Checks nicht sehen können:

**Architektur-Drift erkennen:**
Die deterministischen Checks finden, dass eine neue Edge Function existiert. Claude erkennt, dass diese Function Business-Logik enthält, die nach [Next.js](/de/magazin/nextjs-supabase-sicher-betreiben/) gehört, weil sie User-Input verarbeitet und Daten transformiert statt einen externen Event zu empfangen.

**Muster über Dateigrenzen hinweg:**
Ein `grep` findet, dass `getUser()` in einer Server Action fehlt. Claude erkennt, dass diese Action die einzige von 15 Actions ist, der der Check fehlt, und dass sie letzte Woche in einem Commit hinzugefügt wurde, der auch drei andere Dateien änderte, die alle korrekt sind. Das deutet auf ein Versehen hin, nicht auf ein systematisches Problem.

**Priorisierung:**
Die deterministischen Checks produzieren eine flache Liste von 30 Findings. Claude gruppiert sie: "Die 5 Service-Role-Findings sind alle in der Admin-Library und korrekt. Die 2 fehlenden Auth-Checks in den Route Handlern sind das eigentliche Risiko, weil sie öffentliche API-Endpoints betreffen."

**Konfigurationskontext:**
Ein Port Scan zeigt, dass Port 8000 offen ist. Claude weiss aus dem Stack-Kontext (CLAUDE.md), dass Port 8000 der interne Kong-Port ist, und prüft ob er nur auf localhost lauschen sollte.

## C2 - Was Claude Code nicht kann und nicht tun darf

**Claude kann nicht aktiv scannen.** Es kann keine Netzwerk-Scans durchführen, keine laufenden Prozesse prüfen und keine Ports von aussen testen. Das machen die deterministischen Tools (nmap, ss, docker ps). Claude analysiert deren Output.

**Claude darf nicht auf Produktion schreiben.** Die `--allowedTools` Einschränkung im Headless Mode stellt sicher, dass Claude nur lesen kann:

```bash
# RICHTIG: Nur Lese-Tools erlaubt
claude -p "..." --allowedTools "Read,Grep,Glob"

# FALSCH: Bash erlaubt = Claude kann beliebige Befehle ausführen
claude -p "..." --allowedTools "Read,Grep,Glob,Bash"
```

Wenn Bash nötig ist (z.B. für `git log`), nur spezifische Befehle erlauben:

```bash
--allowedTools "Read,Grep,Glob,Bash(git log*),Bash(git diff*)"
```

**Claude ist nicht deterministisch.** Derselbe Input kann zu leicht unterschiedlichen Reports führen. Deshalb ersetzt Claude keine deterministischen Checks. Es interpretiert deren Ergebnisse.

**Claude kennt keine Echtzeit-Daten.** Es arbeitet mit den Snapshots, die ihm zum Zeitpunkt des Audits übergeben werden. Zwischen Audit und Review-Lektüre kann sich der Zustand geändert haben.

## C3 - Sicherheitsregeln für Claude Code im CI

```bash
# Auf dem Audit-Server: Claude Code Konfiguration

# 1. Eigener API Key mit Budget-Limit
#    Separater Key, nicht der Entwickler-Key
#    Budget: max. 50 USD/Monat für CI Reviews

# 2. --allowedTools immer einschränken
#    Niemals unbeschränkten Bash-Zugriff in automatisierten Scripts

# 3. --max-turns begrenzen
#    Verhindert Endlosschleifen bei verwirrenden Inputs
#    Empfehlung: 3-5 für PR Reviews, 5-10 für Full Audits

# 4. Output immer in Datei speichern
#    Nicht nur auf stdout, damit der Report nachvollziehbar bleibt

# 5. Claude Code hat keinen SSH-Zugriff auf Produktion
#    Die deterministischen Scripts sammeln die Daten
#    Claude bekommt nur den Text-Output zur Analyse
```

## Deployment-Checkliste

```
Installation
  [ ] Claude Code auf audit-runner installiert
  [ ] API Key konfiguriert (separater CI Key mit Budget-Limit)
  [ ] Headless Mode funktioniert (Test mit claude -p)

Konfiguration
  [ ] .claude/commands/security-review.md angelegt
  [ ] CLAUDE.md im Infrastruktur-Repo vorhanden
  [ ] --allowedTools auf Read,Grep,Glob eingeschränkt
  [ ] --max-turns auf 5-10 begrenzt

Automation
  [ ] Gesamt-Audit-Script vorhanden und ausführbar
  [ ] Wöchentlicher Cron Job aktiv
  [ ] PR Review Script im CI eingebunden
  [ ] Alert bei kritischen Findings konfiguriert

Sicherheit
  [ ] Claude Code läuft NUR auf dem audit-runner
  [ ] Claude Code hat KEINEN SSH-Zugriff auf Produktion
  [ ] Kein unbeschränkter Bash-Zugriff in --allowedTools
  [ ] Reports werden gespeichert und archiviert
  [ ] Budget-Limit auf dem API Key gesetzt
```

## Fazit

Claude Code ist kein automatischer Security Scanner und kein Ersatz für deterministische Checks. Es ist ein **kontextueller Analyst**, der die Ergebnisse von Scannern und Grep-Checks interpretiert, Zusammenhänge erkennt und Empfehlungen priorisiert.

Der Workflow ist immer derselbe: Deterministische Tools sammeln Fakten, Claude Code interpretiert sie, ein Mensch entscheidet. Das funktioniert, weil jede Ebene das tut, was sie am besten kann. Scripts sind zuverlässig bei bekannten Mustern. Claude erkennt unbekannte Muster. Menschen treffen Entscheidungen.

Die Kombination aus den Check-Scripts der Artikel 1-4, dem Custom Security Review Command und dem wöchentlichen Audit-Cron ergibt eine Sicherheitskontrolle, die sowohl bekannte als auch unerwartete Risiken aufdeckt.

Wer diese Prinzipien zusammen mit einer [Cert-Ready-by-Design-Architektur](/de/magazin/cert-ready-by-design/) verfolgt, baut prüfbare Sicherheit statt nachträglicher Audits.

<div class="not-prose my-12 border border-gosign-border bg-gosign-light rounded-card p-6 lg:p-8">
<div class="flex items-start gap-4">
<div class="flex-shrink-0 w-12 h-12 bg-gosign-dark rounded-card flex items-center justify-center">
<svg width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="white" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 15v4a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2v-4"/><polyline points="7 10 12 15 17 10"/><line x1="12" y1="15" x2="12" y2="3"/></svg>
</div>
<div>
<h2 class="text-h3 font-bold text-gosign-dark mb-2" id="audit-checklisten-der-serie">Audit-Checklisten der Serie</h2>
<p class="text-body text-gosign-text mb-4">Vorbereitete Prompts für Claude Code. Jede Checkliste prüft automatisch die Sicherheitspunkte des jeweiligen Runbooks und meldet BESTANDEN, WARNUNG oder KRITISCH.</p>
<div class="flex flex-wrap gap-3">
<a href="/downloads/claude-check-artikel-1-supabase.md" download class="inline-flex items-center px-4 py-2 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-sm">Supabase Infrastructure</a>
<a href="/downloads/claude-check-artikel-2-nextjs.md" download class="inline-flex items-center px-4 py-2 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-sm">Next.js Security</a>
<a href="/downloads/claude-check-artikel-3-edge-functions.md" download class="inline-flex items-center px-4 py-2 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-sm">Edge Functions</a>
<a href="/downloads/claude-check-artikel-4-trigger-dev.md" download class="inline-flex items-center px-4 py-2 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-sm">Trigger.dev</a>
</div>
</div>
</div>
</div>

## Serien-Inhaltsverzeichnis

1. [Supabase Self-Hosting Runbook](/de/magazin/supabase-self-hosting/)
2. [Next.js über Supabase sicher betreiben](/de/magazin/nextjs-supabase-sicher-betreiben/)
3. [Supabase Edge Functions sicher einsetzen](/de/magazin/supabase-edge-functions-sicher/)
4. [Trigger.dev Background Jobs sicher betreiben](/de/magazin/trigger-dev-background-jobs/)
5. [Claude Code als Sicherheitskontrolle im DevOps-Workflow](/de/magazin/claude-code-security-devops/) - dieser Artikel
6. [Security Baseline für den gesamten Stack](/de/magazin/security-baseline-stack/)

Der nächste und letzte Artikel beschreibt die [Security Baseline als maschinenlesbare YAML-Datei](/de/magazin/security-baseline-stack/#die-security-baselineyml), die alle Regeln aus den Artikeln 1-5 in einer einzigen prüfbaren Datei zusammenführt.

--- Datensicherheit bei KI - Data Residency, DSGVO und EU AI Act ---
> Datensicherheit bei Enterprise-KI: Data Residency, EU-only Processing, Row-Level Security, Mandantenisolierung. Architekturentscheidungen für CISO und DPO.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Auf einen Blick - Datensicherheit bei Enterprise-KI</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Die erste Frage für jeden CISO und DPO: Wo werden die Daten verarbeitet, wer hat Zugriff, wie lange werden sie gespeichert? Bei öffentlichen KI-Tools ist die Antwort für regulierte Unternehmen inakzeptabel.</li>
<li>Drei Deployment-Modelle: Self-Hosted (keine Daten verlassen das Netzwerk), EU-only Cloud (Verarbeitung in EU-Rechenzentren) oder Hybrid (sensible Daten Self-Hosted, unkritische via Cloud).</li>
<li>IBM Cost of a Data Breach Report (2024) zeigt, dass die durchschnittlichen Kosten einer Datenpanne 4,88 Millionen USD erreichten - der höchste jemals gemessene Wert.</li>
<li>Mandantenisolierung durch Row-Level Security, Workspace-Trennung und Prompt-Isolierung ist geschäftskritisch für Wirtschaftsprüfer, Steuerberater und Shared Service Center.</li>
<li>Datensicherheit bei Enterprise-KI ist eine Architekturentscheidung, keine Policy-Frage - die richtige Infrastruktur macht Compliance verifizierbar statt deklarativ.</li>
</ul>
</div>

## Die zentrale Frage: Wo sind die Daten?

Wenn ein KI-Agent eine Rechnung liest, eine Krankmeldung verarbeitet oder eine Compliance-Frage beantwortet, verarbeitet er Unternehmensdaten. Rechnungsdaten, Personaldaten, Geschäftsgeheimnisse. Die erste Frage jedes CISO und DPO: Wo werden diese Daten verarbeitet? Wer hat Zugriff? Wie lange werden sie gespeichert?

Bei der Nutzung von ChatGPT, Gemini oder CoPilot ist die Antwort: Die Daten werden an externe Server übertragen, von einem Drittanbieter verarbeitet und möglicherweise für Trainingszwecke verwendet. Für regulierte Unternehmen ist das keine akzeptable Antwort.

## Drei Deployment-Modelle

Die [Gosign-Architektur](/de/governance/) unterstützt drei Deployment-Modelle. Die Wahl hängt vom Schutzbedarf der Daten ab.

**Self-Hosted:** Alle Komponenten - Modelle, Agenten, Datenbanken - laufen in der Infrastruktur des Kunden. Keine Daten verlassen das Unternehmensnetzwerk. Das gilt auch für die Sprachmodelle: Open-Source-Modelle wie [Llama](https://llama.meta.com/), [Mistral](https://mistral.ai/), [DeepSeek](https://www.deepseek.com/) oder gpt-oss können lokal betrieben werden.

**Cloud (EU-only):** Verarbeitung in EU-Rechenzentren bei Azure, GCP oder AWS. Data Processing Agreement, Standard Contractual Clauses. Die Modelle sind Cloud-Modelle (Claude, ChatGPT, Gemini), aber die Verarbeitung bleibt in der EU.

**Hybrid:** Sensible Daten (Personaldaten, Finanzdaten) werden Self-Hosted verarbeitet. Unkritische Daten können über Cloud-Modelle laufen. Das Routing zwischen Self-Hosted und Cloud ist regelbasiert und automatisch.

## Data Residency im Detail

Data Residency geht über den Standort der Server hinaus. Es umfasst:

**Verarbeitungsort:** Wo wird das Sprachmodell ausgeführt? Bei Self-Hosted: im eigenen Rechenzentrum. Bei Cloud: in einem definierten EU-Rechenzentrum.

**Speicherort:** Wo werden die verarbeiteten Daten gespeichert? Audit Trails, Entscheidungsdatensätze, Dokumente. Alles in derselben Region wie die Verarbeitung.

**Transitweg:** Wie gelangen Daten zum Modell und zurück? Bei Self-Hosted: internes Netzwerk. Bei Cloud: verschlüsselte Verbindung zum EU-Rechenzentrum. Kein Transit über Drittstaaten.

**Backups:** Wo werden Backups gespeichert? Backups müssen denselben Data-Residency-Anforderungen genügen wie die Primärdaten.

## Mandantenisolierung

Für Wirtschaftsprüfungs- und Steuerberatungskanzleien sowie Shared Service Center ist Mandantenisolierung geschäftskritisch. Daten eines Mandanten dürfen für andere Mandanten nicht sichtbar sein - auch nicht für das KI-System.

Die Isolierung ist mehrschichtig implementiert:

**Workspace-Trennung:** Jeder Mandant hat einen eigenen Workspace mit separaten API-Keys, separatem Dokumentenspeicher und separaten Modell-Konfigurationen.

**Row-Level Security:** Auf Datenbankebene stellt Row-Level Security sicher, dass Abfragen nur Daten des aktuellen Mandanten zurückgeben. Auch wenn ein Agent versehentlich eine mandantenübergreifende Abfrage stellt, liefert die Datenbank nur Ergebnisse des berechtigten Mandanten.

**Prompt-Isolierung:** Prompts und Regelwerke sind mandantenspezifisch. Der Agent eines Mandanten hat keinen Zugriff auf Prompts oder Regelwerke anderer Mandanten.

## DSGVO-Konformität

Die DSGVO stellt Anforderungen an die Verarbeitung personenbezogener Daten. Im KI-Kontext:

**Rechtsgrundlage:** Die Verarbeitung personenbezogener Daten durch KI-Agenten braucht eine Rechtsgrundlage. Im Beschäftigungskontext typischerweise: Vertragserfüllung (Art. 6 Abs. 1 lit. b DSGVO) oder berechtigtes Interesse (Art. 6 Abs. 1 lit. f DSGVO).

**Datenminimierung:** Der Agent verarbeitet nur die Daten, die für den konkreten Zweck erforderlich sind. Keine dauerhafte Speicherung von Dokumenten im Modell. Keine Verwendung von Kundendaten für Trainingszwecke.

**Auskunftsrecht:** Betroffene Personen können Auskunft verlangen, welche Daten verarbeitet wurden. Der Audit Trail dokumentiert jede Verarbeitung personenbezogener Daten.

**Löschung:** Daten werden nach Ablauf der Aufbewahrungsfrist gelöscht. Die Löschung umfasst auch den Audit Trail nach Ablauf der gesetzlichen Aufbewahrungsfristen.

## Datensicherheits-Checkliste nach Deployment-Modell

| Sicherheitsanforderung | Self-Hosted | EU-Only Cloud | Hybrid |
|---|---|---|---|
| Daten verlassen Unternehmensnetz | Nein | Ja (an EU-Rechenzentrum) | Sensibel: Nein / Unkritisch: Ja |
| Modelltraining mit Unternehmensdaten | Nicht möglich | Ausgeschlossen per AVV | Ausgeschlossen per AVV |
| DSGVO-Konformität | Volle Kontrolle by Design | AVV + SCCs + EU-Verarbeitungszonen | Routing pro Datenklasse |
| Mandantenisolierung | Workspace + RLS + Prompt-Isolierung | Workspace + RLS + Prompt-Isolierung | Workspace + RLS + Prompt-Isolierung |
| Audit-Trail-Speicherort | On-Premises | EU-Rechenzentrum | Aufgeteilt: On-Prem + EU-Cloud |
| Backup-Residency | Wie Primärdaten | Gleiche EU-Region | Nach Datenklassifikation |
| Latenz | Niedrigste (lokales Netz) | EU-Netzwerklatenz | Variiert nach Datenklasse |

Mehr dazu: [Data Residency](/de/governance/data-residency/)

<a href="/de/kontakt/" target="_blank" rel="noopener noreferrer">Termin vereinbaren</a> - Wir zeigen Ihnen die Data Residency-Optionen für Ihre Anforderungen.

--- Decision Layer erklärt: Governance für KI-Agenten ---
> Der Decision Layer ist die Governance-Komponente zwischen KI-Agent und Zielsystem. Rules Engine, Confidence Routing, Human-in-the-Loop, Audit Trail.

## Das Problem: KI-Entscheidungen ohne Nachvollziehbarkeit

Wenn ein AI Agent eine Rechnung kontiert, eine Krankmeldung verarbeitet oder eine Compliance-Frage beantwortet, trifft er eine Entscheidung. Diese Entscheidung basiert auf einem Sprachmodell, das auf Wahrscheinlichkeiten arbeitet - nicht auf deterministischen Regeln.

Für einen internen Chatbot ist das akzeptabel. Für geschäftskritische Prozesse nicht. Wenn ein Agent eine Buchung vorschlägt, muss nachvollziehbar sein: Welche Regel wurde angewandt? In welcher Version? Mit welcher Konfidenz? Wurde ein Mensch einbezogen?

Ohne diese Nachvollziehbarkeit sind KI-Entscheidungen in regulierten Umgebungen nicht einsetzbar. Wirtschaftsprüfer können sie nicht prüfen. Betriebsräte können sie nicht bewerten. Revisionen können sie nicht nachvollziehen.

Der Decision Layer löst dieses Problem.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Auf einen Blick - Decision Layer</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Der Decision Layer ist die Governance-Komponente zwischen KI-Agent und Zielsystem - jede Agenten-Entscheidung durchläuft ihn, bevor sie wirksam wird.</li>
<li>Er zerlegt Prozesse in Mikro-Entscheidungen und definiert für jede: Mensch entscheidet, Regelwerk greift oder KI entscheidet autonom.</li>
<li>Vier Komponenten - Rules Engine, Confidence Routing, Human-in-the-Loop, Audit Trail - sichern Nachvollziehbarkeit, Compliance und Prüfungssicherheit.</li>
<li>Bei regelbasierten, repetitiven Entscheidungen übertrifft KI den Menschen nachweislich in Konsistenz, Ermüdungsfreiheit und Vollständigkeit.</li>
<li>Ohne Decision Layer bestehen Enterprise-KI-Agenten keine Prüfung, erfüllen keine Betriebsratsanforderungen und skalieren nicht über Pilotprojekte hinaus.</li>
</ul>
</div>

[Gartner (2026)](https://www.gartner.com/en/newsroom/press-releases/2026-05-26-gartner-says-applying-uniform-governance-across-ai-agents-will-lead-to-enterprise-ai-agent-failure) prognostiziert, dass bis 2027 40 Prozent der Unternehmen autonome KI-Agenten wegen Governance-Lücken zurückstufen oder stilllegen werden.

## Was ist ein Decision Layer?

Der Decision Layer ist die zentrale Governance-Komponente zwischen AI Agent und Zielsystem. Er sitzt architektonisch zwischen dem Agenten, der eine Empfehlung ausspricht, und dem System, in dem die Entscheidung wirksam wird - etwa SAP, [DATEV](https://www.datev.de/) oder [Workday](https://www.workday.com/).

Der Decision Layer ist kein nachträgliches Compliance-Add-on. Er ist ein Architekturprinzip. Jede Agenten-Entscheidung durchläuft den Decision Layer, bevor sie das Zielsystem erreicht.

## Decision Layer - erklärt für Prozessverantwortliche

Die technische Beschreibung oben ist präzise. Aber für den Alltag gibt es eine einfachere Erklärung:

Der Decision Layer funktioniert wie eine Standardprozessbeschreibung mit klaren Entscheidungsstufen - nur dass sie technisch durchgesetzt wird, nicht auf Papier steht.

Konkret: Jeder Geschäftsprozess, den ein AI Agent ausführen soll, wird in einzelne Micro-Entscheidungen zerlegt. Für jede einzelne Entscheidung wird vorab definiert - von Menschen, nicht von der KI:

**Muss hier ein Mensch entscheiden?** Die Architektur erzwingt menschliche Prüfung bei Ermessensentscheidungen, Diskriminierungspotenzial, Mitbestimmungsthemen und Wertgrenzen über definierten Schwellen. Der Agent liefert den vollständigen Kontext und eine Empfehlung - aber ein Mensch entscheidet. Technisch erzwungen, nicht organisatorisch vereinbart.

**Ist die Entscheidung deterministisch?** Tarifvertrag sagt X, also gilt X. Frist läuft am Datum Y ab, also greift Regel Z. Es gibt keinen Interpretationsspielraum. Das Regelwerk ist versioniert - jede Änderung erzeugt eine neue Version, die alte bleibt nachvollziehbar. Hier ist der Agent Executor, nicht weil er nicht mehr könnte, sondern weil es nichts zu interpretieren gibt.

**Entscheidet die KI eigenständig?** Der Agent trifft autonome Entscheidungen - weil er confident genug ist, die Erlaubnis hat, und die Aufgabe nachweislich besser erledigt als manuelle Bearbeitung. Er interpretiert Dokumente, klassifiziert Sachverhalte, bewertet Kontext und erkennt Muster. Das ist kein If-Then-Else - das ist Urteilsvermögen innerhalb definierter Leitplanken.

Jeder dieser Schritte wird dokumentiert: Wer hat entschieden, auf welcher Grundlage, mit welchem Ergebnis. Das ist der Audit Trail - der Beweis, den Wirtschaftsprüfer, Betriebsrat und interne Revision brauchen.

Das Ergebnis: Prozesse werden schneller und konsistenter, ohne dass die Kontrolle verloren geht. Und wenn jemand fragt "Wie wurde diese Entscheidung getroffen?" - gibt es eine Antwort.

<table class="w-full text-left text-sm">
<thead><tr class="border-b border-gosign-border">
<th class="py-2 pr-4 font-semibold">Entscheidungstyp</th>
<th class="py-2 pr-4 font-semibold">Geschwindigkeit</th>
<th class="py-2 pr-4 font-semibold">Prüfbarkeit</th>
<th class="py-2 pr-4 font-semibold">Risikoniveau</th>
<th class="py-2 pr-4 font-semibold">Beispiel</th>
</tr></thead>
<tbody>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Mensch entscheidet</td><td class="py-2 pr-4">Niedrig (Minuten bis Tage)</td><td class="py-2 pr-4">Hoch (dokumentierte Prüfung)</td><td class="py-2 pr-4">Niedrig (menschliches Urteil)</td><td class="py-2 pr-4">BEM-Planung</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Regelbasiert</td><td class="py-2 pr-4">Hoch (sofort)</td><td class="py-2 pr-4">Hoch (versionierte Regeln)</td><td class="py-2 pr-4">Niedrig (deterministisch)</td><td class="py-2 pr-4">Tarifliche Eingruppierung</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">KI autonom</td><td class="py-2 pr-4">Hoch (sofort)</td><td class="py-2 pr-4">Hoch (Audit Trail)</td><td class="py-2 pr-4">Mittel (Confidence Routing)</td><td class="py-2 pr-4">Dokumentenklassifikation</td></tr>
</tbody>
</table>

Die technische Umsetzung dieser Logik besteht aus vier Komponenten:

### Die vier Komponenten

**1. Rules Engine**

Fachliche Regelwerke, versioniert und nachvollziehbar. Tarifverträge, Betriebsvereinbarungen, Buchungslogik, Steuergesetzgebung, Compliance-Regeln. Jede Regel hat eine Version, ein Gültigkeitsdatum und einen Geltungsbereich.

Wenn sich eine Regel ändert - etwa ein neuer Tarifvertrag oder eine geänderte Buchungsrichtlinie - entsteht eine neue Regelversion. Die alte Version bleibt im System. Bei einer Prüfung ist nachvollziehbar, welche Regel in welcher Version zum Entscheidungszeitpunkt galt.

**2. Confidence Routing**

Nicht jede Agenten-Entscheidung hat die gleiche Sicherheit. Der Decision Layer bewertet jede Entscheidung automatisch:

- Hohe Konfidenz + niedriges Risiko = autonome Verarbeitung. Der Agent entscheidet, das Ergebnis geht ins Zielsystem.
- Niedrige Konfidenz oder hohes Risiko = Eskalation an einen Menschen. Der Workflow pausiert, ein Sachbearbeiter prüft und entscheidet.
- Ausnahmefall oder unbekanntes Muster = Blockierung. Kein Output, menschliche Klärung erforderlich.

Die Schwellenwerte für Konfidenz und Risiko sind konfigurierbar und mandantenspezifisch. Eine Wirtschaftsprüfungskanzlei wird andere Schwellenwerte setzen als ein internes Shared Service Center.

**3. Human-in-the-Loop**

Human-in-the-Loop ist im Decision Layer ein Architekturprinzip, nicht eine optionale Checkbox. Bei definierten Entscheidungstypen erzwingt die Architektur menschliche Prüfung:

- Entscheidungen mit Diskriminierungspotenzial
- Entscheidungen die Mitbestimmungsthemen berühren
- Entscheidungen oberhalb definierter Wertgrenzen
- Erstmalige Anwendung einer neuen Regel

Die Human-in-the-Loop-Anforderung ist technisch erzwungen, nicht organisatorisch. Ein Agent kann diese Prüfung nicht umgehen.

**4. Audit Trail - der Entscheidungsakt**

Jede Entscheidung erzeugt einen vollständigen, unveränderlichen Entscheidungsakt:

- Input: Was wurde dem Agenten übergeben?
- Modell: Welches Sprachmodell in welcher Version wurde verwendet (z.B. `claude-opus-4-7-2026-04-12`, `gpt-5.5-2026-03-pro`, `mistral-medium-3.1-eu`, `deepseek-v4-pro-on-prem`)?
- Regelwerk: Welche Regel in welcher Version wurde angewandt?
- Konfidenz: Wie sicher war der Agent?
- Routing: Wurde autonom entschieden oder eskaliert?
- Ergebnis: Was war die Entscheidung?
- Zeitstempel: Wann wurde entschieden?
- Anfechtungspfad: Wer kann diese Entscheidung anfechten - Betroffener, Betriebsrat, Prüfer?

Dieser Entscheidungsakt ist das, was Prüfer im Auditor Portal sehen. Nicht eine nachträgliche Dokumentation, sondern der technische Beweis der Entscheidungsfindung. Und er ist die Architektur-Antwort auf Art. 86 EU AI Act - das Recht der Betroffenen auf Erläuterung der einzelnen Entscheidung.

## Wie der Decision Layer in der Praxis funktioniert

Ein konkretes Beispiel aus der Belegverarbeitung:

Ein Beleg geht ein - eine Eingangsrechnung. Der Document Agent liest den Beleg, extrahiert die relevanten Informationen: Rechnungssteller, Betrag, Leistungsbeschreibung, Datum.

Der Agent erstellt einen Buchungsvorschlag: Konto, Kostenstelle, Vorsteuerabzug, AfA-Beginn. Dieser Vorschlag geht an den Decision Layer.

Der Decision Layer prüft: Ist der Buchungsvorschlag konsistent mit den versionierten Regelwerken? Stimmt die Kostenstelle? Ist der Vorsteuerabzug bei diesem Rechnungstyp korrekt? Liegt der Betrag innerhalb der Grenzen für autonome Verarbeitung?

Wenn ja: Buchungsvorschlag geht ins Zielsystem (DATEV, SAP). Der vollständige Entscheidungspfad wird im Audit Trail gespeichert.

Wenn nein: Rückfrage an den Sachbearbeiter. Der Workflow pausiert. Der Sachbearbeiter sieht den Vorschlag, die angewandte Regel, den Konfidenzwert und den Grund der Eskalation. Er entscheidet. Auch diese menschliche Entscheidung wird im Audit Trail dokumentiert.

## Welche Modelle der Decision Layer aktuell routet

Der Decision Layer ist modell-agnostisch - jede Mikro-Entscheidung wird vom Routing-Layer auf das fachlich und kostenseitig passende Modell geleitet. Stand Mai 2026 routet er produktiv unter anderem auf:

- **Claude Opus 4.7** und **Claude Sonnet 4.6** (Anthropic, Cloud-API) - für Begründungs-Qualität bei Compliance-Eskalationen, langen Akten, Decision-Record-Synthese
- **GPT-5.5** (OpenAI, Cloud-API oder Azure-OpenAI mit EU-Datenresidenz) - für strukturierte Extraktion und Tool-Use
- **Gemini 3.1 Pro** (Google, Cloud-API) - für multimodale Belegverarbeitung (PDF + Scan + Tabelle)
- **Mistral Small 3.2** (Apache 2.0, Self-host oder La Plateforme) - für volumenstarke, kostensensitive Klassifikation
- **Mistral Medium 3.1** (La Plateforme, EU-Region) - wenn Datenresidenz in der EU vertraglich zugesichert sein muss, aber kein eigener Cluster vorhanden ist
- **DeepSeek V4-Pro** und **V4-Flash** (MIT-Lizenz, Self-host oder API) - für Tiefenrecherche und mathematisch-logische Entscheidungspfade
- **Llama 4 Scout** (Meta-Lizenz, Self-host, 10M-Token-Kontext) - für lange Akten und vollständigen Personalakten-Kontext
- **gpt-oss-120b** (OpenAI, Apache 2.0, Self-host) - wenn ein OpenAI-Modell ohne Cloud-Abhängigkeit nötig ist
- **Qwen 3 Coder 110B**, **DeepSeek Coder V4**, **Codestral Mamba 32B** - für Code- und ABAP-/SQL-Mikro-Entscheidungen im Backend

Welches Modell pro Mikro-Entscheidung gewählt wird (Auswahl-Kriterien, Benchmark-Lage, TCO-Vergleich für DAX und gehobenen Mittelstand), behandelt der Master-Artikel [KI-Modelle 2026 - Welches Sprachmodell für welche Aufgabe](/de/magazin/ki-modelle-vergleich-2026/). Was sich davon on-prem self-hosten lässt - inklusive GPU-Sizing, Lizenz-Bedingungen und Self-Hosting-Stack -, behandelt der Spinoff [Selbst-gehostete Open-Source-KI 2026](/de/magazin/selbst-gehostete-open-source-ki-2026/).

## Warum die KI manche Entscheidungen besser trifft als ein Mensch

In der Diskussion über KI-Agenten geht eine Frage unter: Gibt es Entscheidungen, bei denen die KI nicht nur schneller ist, sondern nachweislich besser? Die Antwort ist ja. Und der Decision Layer macht genau diese Fälle identifizierbar.

Es gibt drei Kategorien, in denen autonome KI-Entscheidungen dem Menschen überlegen sind - nicht weil die KI klüger ist, sondern weil sie strukturelle Schwächen des Menschen nicht hat:

**Konsistenz über Standorte und Personen.** 50 Sachbearbeiter an 12 Standorten wenden denselben Tarifvertrag an. Jeder interpretiert Grenzfälle leicht anders. In Standort A wird eine Sonderzahlung genehmigt, in Standort B wird derselbe Fall abgelehnt. Das ist kein Ausbildungsproblem - es ist die natürliche Varianz menschlicher Entscheidungen. Eine KI die auf einem versionierten Regelwerk arbeitet, entscheidet identisch. Jedes Mal, an jedem Standort.

**Ermüdungsfreiheit bei repetitiven Entscheidungen.** Ein Recruiter screent am Montagmorgen anders als am Freitagnachmittag. Nach der 50. Bewerbung sinkt die Aufmerksamkeit. Der letzte Kandidat war stark - der nächste wirkt im Vergleich schwächer (Anchoring-Bias). Eine KI bewertet Bewerbung Nummer 1 mit derselben Sorgfalt wie Bewerbung Nummer 200. Sie hat keinen schlechten Tag.

**Vollständigkeit bei Regelprüfung.** Ein HR-Sachbearbeiter prüft eine Krankmeldung gegen drei bis vier Kriterien, die ihm einfallen: Krankheitsdauer, Lohnfortzahlungsfrist, vielleicht noch die BEM-Schwelle. Aber prüft er auch die Wartezeitregelung? Die Sonderregel für Teilzeitkräfte im Haustarifvertrag? Die Meldepflicht gegenüber der Berufsgenossenschaft bei bestimmten Krankheitsbildern? Jedes Mal? Auch freitags um 16 Uhr? Eine KI prüft gegen alle geltenden Regeln, in der aktuellen Version, vollständig und dokumentiert. Nicht weil sie klüger ist - sondern weil sie nicht vergisst.

Das bedeutet nicht, dass die KI überall besser ist. Ermessensentscheidungen, Einzelfallbewertungen, kulturelle Passung, ethische Abwägungen - das sind und bleiben menschliche Domänen. Aber bei regelbasierten, repetitiven Entscheidungen mit hohem Konsistenzbedarf ist autonome KI kein Kompromiss. Sie ist die bessere Lösung.

Der Decision Layer macht diese Unterscheidung operativ: Für jede Micro-Entscheidung ist definiert, ob der Mensch, das Regelwerk oder die KI entscheidet - und bei den KI-Entscheidungen ist dokumentiert, *warum* die KI hier die richtige Wahl ist.

## Warum kein Agent ohne Decision Layer in Produktion gehen sollte

Ohne Decision Layer ist ein AI Agent eine Blackbox. Er produziert Ergebnisse, aber niemand kann nachvollziehen wie. Das hat konkrete Konsequenzen:

**Prüfung:** Wirtschaftsprüfer und interne Revision brauchen Nachvollziehbarkeit. Ohne Audit Trail ist jede Agenten-Entscheidung ein Prüfungsrisiko. Der Prüfer muss jeden einzelnen Fall manuell nachvollziehen - das ist aufwendiger als ohne Agent.

**Mitbestimmung:** Betriebsräte haben bei der Einführung von KI-Systemen Mitbestimmungsrechte. Ohne nachvollziehbare Entscheidungslogik können sie ihre Rolle nicht wahrnehmen. Der Decision Layer macht Betriebsvereinbarungen zu technischen Constraints.

**Haftung:** Wenn ein Agent eine fehlerhafte Buchung erzeugt und es keinen Entscheidungspfad gibt, ist unklar wer verantwortlich ist. Der Decision Layer dokumentiert die Verantwortungskette.

**Skalierung:** Ein Agent, der in einem Pilotprojekt funktioniert, muss nicht in Produktion funktionieren. Ohne Governance-Infrastruktur bleibt jeder Agent ein Einzelfall. Der Decision Layer ermöglicht konsistente Governance über alle Agenten hinweg.

## Decision Layer und Cert-Ready by Design

Der Decision Layer ist die technische Grundlage für Cert-Ready by Design. Controls sind im Decision Layer First-Class-Datenobjekte mit definierten Attributen: Control_ID, Technical_Implementation, Rule_Version, Evidence_Generator, Evidence_History, Auditor_View.

Evidence wird automatisch erzeugt - nicht nachträglich zusammengestellt. Prüfer sehen im Auditor Portal den Live-Status aller Kontrollen, mit Drill-Down bis zur konkreten Regelimplementierung.

Das Framework-Mapping bildet die Controls auf etablierte Prüfungsstandards ab: ISA, PS 951, IDW, GoB/GoBD. Eine Betriebsprüfung oder Jahresabschlussprüfung kann auf Basis der automatisch erzeugten Evidence durchgeführt werden.

Mehr dazu: [Cert-Ready by Design](/de/governance/cert-ready/)

→ [Decision Layer - Übersicht und Beispiele](/de/decision-layer/)

→ [Entscheidungsakt: Warum jede KI-Entscheidung anfechtbar sein muss](/de/magazin/entscheidungsakt-anfechtbare-ki-entscheidungen/)

<a href="/de/kontakt/" target="_blank" rel="noopener noreferrer">Termin vereinbaren</a> - Wir zeigen Ihnen, wie ein Decision Layer für Ihren konkreten Prozess aussieht.

--- Payroll-Fehler strukturell eliminieren ---
> Der Decision Layer macht Entscheidungslogik explizit, versioniert und prüfbar. Weniger Korrekturbuchungen durch konsistente Regelanwendung

## Das Problem: Implizite Fachlogik

In der Belegverarbeitung treffen Menschen täglich Hunderte Mikro-Entscheidungen. Kontierung, Kostenstelle, AfA-Beginn, Vorsteuerabzug, Aufwandsklassifizierung. Jede Entscheidung basiert auf einem Regelwerk: Steuergesetzgebung, Rechnungslegungsstandards, interne Richtlinien, mandantenspezifische Besonderheiten.

Das Problem ist nicht mangelndes Fachwissen. Das Problem ist Inkonsistenz. Verschiedene Sachbearbeiter wenden dasselbe Regelwerk unterschiedlich an. Nicht weil sie inkompetent sind, sondern weil die Regelwerke komplex sind und die Interpretation Spielraum lässt.

Mehr Mandanten bedeutet mehr Regelwerk-Varianten. Mehr Standorte bedeutet mehr Sachbearbeiter mit unterschiedlichen Interpretationen. Mehr Personal bedeutet mehr Einarbeitung, mehr implizites Wissen, mehr Varianz.

Die Folgen sind messbar: Korrekturbuchungen, Prüfungsfeststellungen, Abstimmungsschleifen, verlängerte Monatsabschlüsse. Die Regelwerke existieren oft nur in den Köpfen einzelner Mitarbeiter. Wenn diese Mitarbeiter krank sind, im Urlaub oder das Unternehmen verlassen, geht das Wissen verloren.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Auf einen Blick - Decision Layer für Payroll</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Payroll-Fehler entstehen durch implizites Fachwissen - Regeln existieren in Köpfen, nicht in Systemen. Wenn Personal wechselt, geht das Wissen verloren.</li>
<li>Laut Hackett Group (2024) reduzieren Unternehmen mit expliziten, versionierten Payroll-Regeln Korrekturbuchungen um 60 bis 80 % im ersten Jahr.</li>
<li>Der Decision Layer macht Regelanwendung explizit, versioniert und auditierbar - jede Buchungsentscheidung ist auf eine definierte Regel rückverfolgbar.</li>
<li>Routinefälle werden autonom verarbeitet; Ausnahmen werden mit Kontext und Konfidenzwert an Spezialisten eskaliert.</li>
<li>Audit-Readiness wird strukturell: Jeder Entscheidungspfad ist automatisch dokumentiert - vom Beleg bis zur angewandten Regel.</li>
</ul>
</div>

## Decision Layer für Belegverarbeitung

Der [Decision Layer](/de/decision-layer/) löst dieses Problem, indem er Regelwerke explizit, versioniert und maschinenlesbar macht. Jede Buchungsentscheidung basiert auf einer definierten Regel in einer bestimmten Version. Es gibt keinen Interpretationsspielraum.

Der Ablauf: Ein Beleg geht ein. Der Document Agent liest und versteht den Beleg - unabhängig vom Format. Er erzeugt einen Buchungsvorschlag. Der Decision Layer prüft diesen Vorschlag gegen die versionierten Regelwerke:

Ist die Kontierung korrekt? Stimmt die Kostenstelle? Ist der Vorsteuerabzug bei diesem Rechnungstyp zulässig? Liegt der AfA-Beginn richtig? Ist die Aufwandsklassifizierung konsistent mit den mandantenspezifischen Richtlinien?

Bei hoher Konfidenz und klarer Regel: autonome Verarbeitung. Buchungsvorschlag geht ins Zielsystem ([DATEV](https://www.datev.de/), [SAP FI/CO](https://www.sap.com/products/erp/s4hana.html)). Vollständiger Audit Trail wird erzeugt.

Bei niedriger Konfidenz oder Ausnahme: Eskalation an den Sachbearbeiter. Der Workflow pausiert. Der Sachbearbeiter sieht den Vorschlag, die angewandte Regel, den Konfidenzwert und den Eskalationsgrund.

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Kostenloses eBook: KI in Finance</p>
<p class="text-body text-gosign-text mb-4">Compliance, Wirtschaftsprüfer und Decision Layer - das Governance-Handbuch für Finance-Verantwortliche.</p>
<a href="/de/ebook/ki-finance-governance-handbuch/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Jetzt kostenlos herunterladen</a>
</div>

## Versionierte Regelwerke

Jede Regeländerung erzeugt eine neue Version. Die alte Version bleibt im System. Bei einer Prüfung ist nachvollziehbar, welche Regel in welcher Version zum Entscheidungszeitpunkt galt.

Ein Beispiel: Am 1. Juli ändert sich der Umsatzsteuersatz für eine bestimmte Warengruppe. Im Decision Layer wird eine neue Regelversion erstellt, gültig ab 1. Juli. Belege vor dem 1. Juli werden mit der alten Regelversion verarbeitet. Belege ab dem 1. Juli mit der neuen. Der Übergang ist automatisch, nachvollziehbar und prüfbar.

## Mandantenspezifische Parametrisierung

Für Wirtschaftsprüfungs- und Steuerberatungskanzleien mit Hunderten von Mandanten: Die Regelwerke sind mandantenspezifisch parametrisiert. Der gleiche Agent wendet für jeden Mandanten die korrekten Regeln in der aktuellen Version an.

Mandant A nutzt SKR03, Mandant B nutzt SKR04. Mandant C hat einen individuellen Kontenplan. Der Decision Layer stellt sicher, dass der Agent für jeden Mandanten die richtigen Regeln anwendet - konsistent, über alle Sachbearbeiter hinweg.

## Prüfungsvorbereitung

Bei einer Betriebsprüfung oder Jahresabschlussprüfung kann der Prüfer im Auditor Portal jede einzelne Buchungsentscheidung nachvollziehen. Grundlage ist der Entscheidungsakt pro Buchung - der unveränderliche Nachweis mit Input/Beleg, angewandter Fachregel samt Version, Konfidenz, Ergebnis, Zeitstempel und Anfechtungspfad. Vom Buchungsbeleg bis zur angewandten Regel mit Version, vom Konfidenzwert bis zum Routing (autonom oder eskaliert).

Das reduziert den Prüfungsaufwand erheblich. Statt manuelle Stichproben zu ziehen und für jeden Fall die Buchungslogik zu rekonstruieren, sieht der Prüfer den vollständigen Entscheidungspfad automatisch dokumentiert.

<div class="overflow-x-auto">

| Aspekt | Ohne Decision Layer | Mit Decision Layer |
|--------|--------------------|--------------------|
| Regelanwendung | Implizit, personenabhängig | Explizit, versioniert |
| Konsistenz über Standorte | Variabel | Identisch |
| Korrekturbuchungen | 3 - 8 % aller Buchungen | < 1 % |
| Prüfungsvorbereitung | Manuelle Rekonstruktion | Automatische Dokumentation |
| Wissenstransfer | Monate Einarbeitung | Regelwerke sind selbstdokumentierend |
| Compliance-Nachweis | Stichprobenbasiert | Vollständiger Entscheidungspfad |

</div>

Mehr dazu: [Finance AI Agents](/de/finance-ai-agents/)

→ [Entscheidungsakt: Warum jede KI-Entscheidung anfechtbar sein muss](/de/magazin/entscheidungsakt-anfechtbare-ki-entscheidungen/)

<a href="/de/kontakt/" target="_blank" rel="noopener noreferrer">Termin vereinbaren</a> - Wir zeigen Ihnen, wie ein Decision Layer für Ihre Belegverarbeitung aussieht.

--- Decision Layer & Shadow AI: Kontrolle statt Kontrollverlust ---
> Wie der Decision Layer Analyse von Entscheidung trennt - und warum das Shadow AI löst, Betriebsräte überzeugt und Skalierung ermöglicht.

## Der Decision Layer löst zwei Probleme gleichzeitig

Shadow AI und fehlende KI-Governance blockieren die Skalierung. Das erste Problem: Beschäftigte nutzen [ChatGPT](https://openai.com/chatgpt), [Google Gemini](https://gemini.google.com) oder [Microsoft Copilot](https://copilot.microsoft.com) unkontrolliert, weil die eigene IT keine gleichwertige Alternative bietet. Das zweite Problem: Selbst bereitgestellte KI-Systeme arbeiten ohne klare Trennung von Analyse und Entscheidung.

Der Decision Layer adressiert beides. Er definiert pro Mikro-Entscheidung, wer handelt: Mensch, Regelwerk oder KI. Gleichzeitig schafft er die Grundlage für ein internes KI-Portal, das [ChatGPT](https://openai.com/chatgpt) Enterprise oder [Google Gemini](https://gemini.google.com) Advanced in Funktion und Sicherheit übertrifft.

Dieser Artikel zeigt, warum Shadow AI das Compliance-Risiko der Stunde ist. Er beschreibt die Funktionsweise des Decision Layers und erklärt, warum ohne diese Architektur weder der Betriebsrat nach [Betriebsverfassungsgesetz](https://www.gesetze-im-internet.de/betrvg/__87.html) §87 Abs. 1 Nr. 6 noch die [BaFin](https://www.bafin.de)-konforme Revision einer KI-Skalierung zustimmen.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Auf einen Blick - Shadow AI und der Decision Layer</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Shadow AI - die unkontrollierte Nutzung öffentlicher KI-Tools durch Mitarbeitende - ist die Shadow IT von 2026: Datenabfluss, [EU-Datenschutzgrundverordnung](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32016R0679)-Risiko, null Nachvollziehbarkeit.</li>
<li>KI-Verbote scheitern in der Praxis. Die Lösung ist ein gesteuertes internes KI-Portal, das öffentliche Alternativen in Funktion und Sicherheit übertrifft.</li>
<li>Der Decision Layer trennt Analyse von Entscheidung: KI kann analysieren, aber wer handelt, ist pro Mikro-Entscheidung definiert (Mensch, Regelwerk oder KI).</li>
<li>Ein vierstufiges Datenklassifizierungsschema steuert das Model-Routing - vertrauliche Daten erreichen nie ein öffentliches Modell.</li>
<li>Ohne Governance-first-Architektur wird weder Betriebsrat noch Wirtschaftsprüfer noch Vorstand einer KI-Skalierung zustimmen.</li>
</ul>
</div>

## Shadow AI kostet Unternehmen bereits heute Millionen

Shadow AI ist die Shadow IT von 2026. Beschäftigte nutzen [ChatGPT](https://openai.com/chatgpt), [Microsoft Copilot](https://copilot.microsoft.com), [Google Gemini](https://gemini.google.com) oder [Perplexity](https://www.perplexity.ai) für ihre tägliche Arbeit. Sie lassen E-Mails formulieren, Verträge in [DeepL Write](https://www.deepl.com/write) übersetzen und Quartalsberichte zusammenfassen. Nicht aus Böswilligkeit, sondern weil diese Tools produktiver machen.

Die Zahlen belegen das Ausmaß. Laut [Gartner](https://www.gartner.com/en/newsroom/press-releases/2024-generative-ai-workforce) nutzen 2026 über 60 Prozent der Wissensarbeiter generative KI-Tools. Die Mehrheit davon ohne Freigabe der IT-Abteilung. [Samsung](https://www.samsung.com) Electronics musste 2023 die interne ChatGPT-Nutzung in der Halbleitersparte verbieten, nachdem Quellcode an [OpenAI](https://openai.com) übermittelt wurde. [Apple](https://www.apple.com) folgte mit einer ähnlichen Richtlinie.

**Datenabfluss nach [EU-Datenschutzgrundverordnung](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32016R0679#art_5) Art. 5 und Art. 32.** Jede Eingabe in ein öffentliches KI-Tool verlässt das Unternehmensnetzwerk. Vertragsinhalte, Finanzdaten, Personalinformationen. Alles liegt außerhalb Ihrer Kontrolle. Bei personenbezogenen Daten kann das nach [EU-Datenschutzgrundverordnung](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32016R0679#art_33) Art. 33 einen meldepflichtigen Vorfall darstellen.

**Keine Nachvollziehbarkeit nach [IDW PS 980](https://www.idw.de/de/verlautbarungen/idw-pruefungsstandards/idw-ps-980).** Es gibt keinen Audit Trail. Welcher Beschäftigte hat welche Daten an welches Tool übergeben? Niemand dokumentiert es. Das verletzt die Anforderungen der internen Revision nach [IDW PS 980](https://www.idw.de/de/verlautbarungen/idw-pruefungsstandards/idw-ps-980) (Compliance-Management-Systeme).

**Keine Qualitätskontrolle nach [ISO 9001](https://www.iso.org/standard/62085.html).** KI-Ergebnisse fließen in Geschäftsentscheidungen ein. Ein Vertragsentwurf, der teilweise von einer KI stammt - ohne Qualitätskontrolle nach [ISO 9001](https://www.iso.org/standard/62085.html) und ohne Kennzeichnung.

Die Lösung ist nicht Verbot. [Samsung](https://www.samsung.com) und [Apple](https://www.apple.com) zeigen: Verbote erzeugen Workarounds. Die Alternative ist ein internes KI-Portal, das funktional besser ist als [ChatGPT](https://openai.com/chatgpt) Enterprise. Wie ein solches Portal aussieht, beschreibt der Artikel [Enterprise-AI-Portal: Mehr als nur ein Chat-Interface](/de/magazin/enterprise-ki-chat-interface/).

## Der Decision Layer trennt Analyse von Entscheidung

Der Decision Layer ist das Architekturprinzip hinter kontrollierter KI-Nutzung. Ein KI-Modell - ob [Claude Opus 4.7](https://www.anthropic.com/news/claude-opus-4-7), [GPT-5.5](https://openai.com/index/gpt-5-5/) oder [Llama 4 Scout](https://ai.meta.com/blog/meta-llama-4/) - kann analysieren: Daten zusammenfassen, Muster erkennen, Empfehlungen aussprechen. Die Entscheidung, ob und wie reagiert wird, ist eine separate Frage. Der Decision Layer beantwortet sie.

Jeder Geschäftsprozess wird in Mikro-Entscheidungen zerlegt. Für jede ist vorab definiert, wer entscheidet:

```
Eingehender Vorgang
│
┌──────────┐
│ Decision  │
│  Layer    │
└──────────┘
┌────┼────────────┐
▼    ▼            ▼
REGEL   KI        MENSCH
```

**MENSCH:** Die Architektur erzwingt menschliche Prüfung. Das gilt bei Ermessensentscheidungen, bei Diskriminierungspotenzial nach [Allgemeines Gleichbehandlungsgesetz](https://www.gesetze-im-internet.de/agg/__1.html) (AGG) und bei Mitbestimmungsthemen nach [Betriebsverfassungsgesetz](https://www.gesetze-im-internet.de/betrvg/__87.html) §87 Abs. 1 Nr. 6. Der Agent liefert den Kontext und eine Empfehlung. Ein Mensch entscheidet. Diese Eskalation ist technisch erzwungen, nicht organisatorisch vereinbart.

**REGELWERK:** Die Entscheidung folgt deterministische Logik. Der Tarifvertrag der [IG Metall](https://www.igmetall.de) sagt X, also gilt X. Eine Frist nach [Bürgerliches Gesetzbuch](https://www.gesetze-im-internet.de/bgb/__186.html) §186 läuft ab, also greift die Regel. Das Regelwerk ist versioniert: Jede Änderung erzeugt eine neue Version. Die alte bleibt nachvollziehbar.

**KI AUTONOM:** Der Agent trifft eigenständige Entscheidungen innerhalb definierter Leitplanken. Er interpretiert Dokumente, klassifiziert Sachverhalte und bewertet Kontext. Das Confidence Routing steuert: Hohe Konfidenz und niedriges Risiko führt zur autonomen Entscheidung. Niedrige Konfidenz oder hohes Risiko eskaliert an einen Menschen.

## Vier Prinzipien machen den Decision Layer revisionssicher

**Explizite, versionierte Regeln nach [ISO 42001](https://www.iso.org/standard/81230.html).** Jede Entscheidungsregel hat eine ID, eine Version und ein Gültigkeitsdatum. [ISO 42001](https://www.iso.org/standard/81230.html) (AI Management System) verlangt genau diese Nachvollziehbarkeit. Wenn sich eine Betriebsvereinbarung ändert, entsteht eine neue Regelversion. Bei einer Prüfung ist klar, welche Regel zum Entscheidungszeitpunkt galt.

**Architektonisch erzwungener Human-in-the-Loop.** Bei definierten Entscheidungstypen kann das System nicht ohne menschliche Freigabe fortfahren. Das ist technisch durchgesetzt, konform mit [EU AI Act](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32024R1689#art_14) Art. 14 (menschliche Aufsicht). Ein Agent umgeht diese Prüfung nicht, weil die Architektur es verhindert.

**Audit Trail pro Mikro-Entscheidung - der Entscheidungsakt.** Jede Mikro-Entscheidung erzeugt einen unveränderlichen Entscheidungsakt: Input, angewandte Fachregel samt Version, Konfidenzwert, Modellversion, Ergebnis, Zeitstempel und Anfechtungspfad. Das entspricht den Anforderungen des [BSI C5-Katalog](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Empfehlungen-nach-Angriffszielen/Cloud-Computing/Kriterienkatalog-C5/kriterienkatalog-c5_node.html) (Cloud Computing Compliance Criteria Catalogue) an die Protokollierung - und macht die Erläuterung der Einzelentscheidung nach Art. 86 EU AI Act erfüllbar.

**Betriebsvereinbarungen als Systemconstraints.** Anforderungen des Betriebsrats nach [Betriebsverfassungsgesetz](https://www.gesetze-im-internet.de/betrvg/__87.html) §87 werden als technische Regeln implementiert. Das System kann die Betriebsvereinbarung nicht umgehen, weil sie Teil der Systemlogik ist. Der Betriebsrat prüft jede Entscheidung im Audit Trail.

## Datenklassifizierung steuert das Model-Routing automatisch

Bevor der Decision Layer wirksam wird, muss geklärt sein: Welche Daten dürfen von welchem KI-Modell verarbeitet werden? Die Antwort liefert ein vierstufiges Schema, angelehnt an [ISO 27001](https://www.iso.org/isoiec-27001-information-security.html) Annex A.8 (Informationsklassifizierung):

| Stufe | Bezeichnung | Beispiele | Erlaubte KI-Verarbeitung |
|---|---|---|---|
| 1 | Öffentlich | Pressemitteilungen, Website-Inhalte | Alle Modelle, einschließlich [OpenAI API](https://platform.openai.com) oder [Google Vertex AI](https://cloud.google.com/vertex-ai) |
| 2 | Intern | Präsentationen, Prozessdokumente | EU-Cloud-Modelle, z. B. [Azure OpenAI Service](https://azure.microsoft.com/de-de/products/ai-services/openai-service) in West Europe |
| 3 | Vertraulich | HR-Daten, Finanzdaten, Verträge | Nur self-hosted ([Llama 4 Scout](https://ai.meta.com/blog/meta-llama-4/), [Mistral Small 3.2](https://mistral.ai/news/mistral-small-3-2)) oder mit PII-Anonymisierung |
| 4 | Streng vertraulich | M&A-Unterlagen, Patente | Nur On-Premises, kein Cloud-Modell |

Die Klassifizierung bestimmt automatisch das Routing. Stellt ein Beschäftigter eine Frage zu einem Vertrag (Stufe 3), routet das System an ein self-hosted Modell. Ein öffentliches Modell wie [GPT-5.5](https://openai.com/index/gpt-5-5/) kommt für Stufe-3-Daten nicht in Frage. Die Architektur verhindert das technisch.

Die Datenklassifizierung ist keine einmalige Aufgabe. Sie muss in bestehende Prozesse integriert werden. Jedes neue Dokument erhält eine Klassifizierung. Im Idealfall geschieht das automatisiert - basierend auf Dokumenttyp, Inhaltserkennung durch NLP-Modelle wie [spaCy](https://spacy.io) oder [Hugging Face Transformers](https://huggingface.co/docs/transformers/) und organisatorischer Zuordnung.

Ohne Datenklassifizierung nach [ISO 27001](https://www.iso.org/isoiec-27001-information-security.html) fehlt die Grundlage. Sie ist die erste Entscheidung - noch vor der Modellauswahl, noch vor dem Aufbau der [Infrastruktur](/de/leistungen/infrastruktur/).

## Fünf Säulen tragen die KI-Governance

Die Datenklassifizierung bildet das Fundament. Darauf bauen fünf Säulen auf:

**1. Zugriffskontrolle nach RBAC-Prinzip.** Wer darf welche KI-Funktionen nutzen? Die Zugriffskontrolle bildet die Organisationsstruktur ab. HR sieht HR-Assistenten, Finance sieht Finance-Assistenten. SSO-Integration über [Microsoft Entra ID](https://www.microsoft.com/de-de/security/business/identity-access/microsoft-entra-id) oder [Okta](https://www.okta.com) stellt sicher, dass keine separaten Zugänge nötig sind.

**2. Audit und Logging nach [BSI C5](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Empfehlungen-nach-Angriffszielen/Cloud-Computing/Kriterienkatalog-C5/kriterienkatalog-c5_node.html).** Jede Interaktion wird protokolliert. Wer hat wann welche Frage gestellt? Welches Modell hat geantwortet? Auf Basis welcher Quellen? Der Audit Trail ist die Grundlage für Wirtschaftsprüfung nach [IDW PS 980](https://www.idw.de/de/verlautbarungen/idw-pruefungsstandards/idw-ps-980) und interne Revision. Die [Governance-Referenzarchitektur](/de/governance/referenz-architektur/) beschreibt die technische Umsetzung.

**3. Human Oversight nach [EU AI Act](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32024R1689#art_14) Art. 14.** Die Architektur definiert, wo menschliche Prüfung erforderlich ist. Routineklassifizierungen brauchen keinen menschlichen Prüfer. Personalentscheidungen mit Diskriminierungspotenzial nach [Allgemeines Gleichbehandlungsgesetz](https://www.gesetze-im-internet.de/agg/__1.html) (AGG) brauchen immer einen.

**4. Qualitätssicherung nach [NIST AI RMF](https://www.nist.gov/itl/ai-risk-management-framework).** KI-Ergebnisse werden systematisch überprüft. Stichproben, Nutzerfeedback, automatisierte Evaluierung. Halluziniert das Modell? Stimmen die Quellenverweise? Das [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) (RMF) liefert die Methodik dafür.

**5. Compliance nach [EU AI Act](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32024R1689).** Der [EU AI Act](/de/magazin/eu-ai-act-2026-unternehmen/) verlangt technische Dokumentation und Risikoklassifizierung für Hochrisiko-KI-Systeme nach [Art. 6](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32024R1689#art_6) - geltende Frist 2. August 2026, mit am 7. Mai 2026 im [Digital Omnibus](https://ec.europa.eu/commission/presscorner/detail/en/ip_25_620) vorläufig geeinigter Verschiebung auf den 2. Dezember 2027 (formale Verabschiedung ausstehend). Die Governance muss diese Anforderungen von Anfang an abbilden.

## Ohne Decision Layer scheitert die Skalierung

Wer KI von einem Pilot auf zehn produktive Agenten skalieren will - ob in der Personalabteilung mit [SAP SuccessFactors](https://www.sap.com/germany/products/hcm.html) oder im Kundenservice mit [Salesforce](https://www.salesforce.com) - stößt ohne Decision Layer an eine harte Grenze. Nicht technisch - organisatorisch.

**Der Betriebsrat blockiert nach [Betriebsverfassungsgesetz](https://www.gesetze-im-internet.de/betrvg/__87.html) §87.** Betriebsräte haben nach [Betriebsverfassungsgesetz](https://www.gesetze-im-internet.de/betrvg/__87.html) §87 Abs. 1 Nr. 6 Mitbestimmungsrechte bei KI-Systemen, die Arbeitnehmerverhalten überwachen. Ohne nachvollziehbare Entscheidungslogik gibt kein Betriebsrat seine Zustimmung. Der Decision Layer liefert genau die Transparenz, die [Betriebsverfassungsgesetz](https://www.gesetze-im-internet.de/betrvg/__87.html) verlangt.

**Die Revision verweigert die Freigabe.** Wirtschaftsprüfer brauchen Nachvollziehbarkeit nach [IDW PS 340](https://www.idw.de/de/verlautbarungen/idw-pruefungsstandards/idw-ps-340). Wenn ein KI-Agent Buchungen in [SAP S/4HANA](https://www.sap.com/germany/products/erp/s4hana.html) erzeugt oder Personalentscheidungen in [Workday](https://www.workday.com) vorbereitet, muss der Entscheidungspfad prüfbar sein. Der Decision Layer erzeugt automatisch die Evidence, die Big-Four-Prüfer ([Deloitte](https://www.deloitte.com), [PwC](https://www.pwc.com), [EY](https://www.ey.com), [KPMG](https://kpmg.com)) verlangen.

**Der Vorstand sieht keinen ROI.** Pilotprojekte laufen mit Innovationsbudgets. Skalierung braucht Investitionsbudgets mit belastbarem Business Case. Der Decision Layer liefert die Daten: Durchlaufzeiten, Fehlerquoten, Kosten pro Vorgang, Eskalationsraten. Laut [McKinsey Global AI Survey](https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai) erreichen nur 11 Prozent der KI-Projekte den produktiven Betrieb. Der Decision Layer erhöht diese Quote messbar.

Die Reihenfolge ist nicht verhandelbar: Erst Governance, dann Skalierung.

## Privacy by Design schützt Beschäftigte und Daten

Ein Enterprise-AI-Portal schützt nicht nur Anfragedaten. Es schützt auch die Nutzung selbst. Kein Tracking, keine Analytics-Cookies, keine Verhaltensanalyse.

**SSO über [Microsoft Entra ID](https://www.microsoft.com/de-de/security/business/identity-access/microsoft-entra-id) oder [Okta](https://www.okta.com).** Beschäftigte authentifizieren sich über das bestehende Identity-Management. Keine separaten Passwörter, keine Nutzerprofile bei Drittanbietern.

**Keine Tracking-Cookies nach [EU-Datenschutzgrundverordnung](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32016R0679#art_5) Art. 5 Abs. 1 lit. c.** Das Portal verwendet keine Cookies zur Verhaltensanalyse. Nutzungsdaten dienen ausschließlich dem Audit Trail - nicht dem Marketing und nicht dem Profiling nach [Bundesdatenschutzgesetz](https://www.gesetze-im-internet.de/bdsg_2018/__4.html) (BDSG).

**Nutzungsdaten nur für Governance-Zwecke.** Der Zugriff ist auf berechtigte Rollen beschränkt: IT-Sicherheit, Datenschutzbeauftragter nach [EU-Datenschutzgrundverordnung](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32016R0679#art_37) Art. 37, interne Revision. Führungskräfte sehen keine individuellen Anfragen.

**Privacy by Design nach [EU-Datenschutzgrundverordnung](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32016R0679#art_25) Art. 25.** Die Datenschutzanforderungen sind in die Architektur eingebaut. PII-Anonymisierung, Datenklassifizierung und Model-Routing greifen automatisch. Basierend auf der Klassifizierung der Daten, nicht auf der Disziplin der Nutzenden.

Dieser Ansatz überzeugt Datenschutzbeauftragte nach [BDSG §38](https://www.gesetze-im-internet.de/bdsg_2018/__38.html) und Betriebsrat gleichermaßen: Das System dokumentiert Geschäftsentscheidungen, nicht Beschäftigte.

---

**📘 Enterprise AI-Infrastruktur Blueprint 2026 - Artikel-Serie**

| ← Vorheriger | Übersicht | Nächster → |
|:---|:---:|---:|
| [Von Chatbots zu AI-Agenten: MCP, A2A und Multi-Agent-Systeme](/de/magazin/ai-agenten-enterprise-leitfaden/) | [Zur Übersicht](/de/magazin/ai-infrastruktur-blueprint-2026/) | [Was KI wirklich kostet: TCO-Vergleich für Unternehmen](/de/magazin/ki-kosten-tco-vergleich/) |

*Alle Artikel dieser Serie: [Enterprise AI-Infrastruktur Blueprint 2026](/de/magazin/ai-infrastruktur-blueprint-2026/)*

---

[Decision Layer](/de/decision-layer/) ist Gosigns zentrale Governance-Komponente. Modell-agnostisch, betriebsratskompatibel, mit vollständigem Audit Trail und einem Entscheidungsakt pro Mikroentscheidung - anfechtbar nach [Art. 86 EU AI Act](/de/magazin/entscheidungsakt-anfechtbare-ki-entscheidungen/). Mehr zur [Governance-Architektur](/de/governance/).

<a href="/de/kontakt/" target="_blank" rel="noopener noreferrer">Termin vereinbaren</a>. 30 Minuten, in denen wir klären, wie ein Decision Layer für Ihre Prozesse aussieht und wie Shadow AI in Ihrem Unternehmen kontrolliert adressiert werden kann.

--- Decision Layer vs. SAP Joule vs. Copilot ---
> SAP Joule und Microsoft Copilot sind AI Agents. Der Decision Layer ist die Governance-Schicht darüber. Warum Enterprise-Unternehmen beides brauchen.

## Die Verwirrung

Enterprise-Entscheider hören von SAP Joule, Microsoft Copilot, Google Gemini, internen GPT-Deployments - und fragen sich: Was davon brauche ich, und wo passt ein Decision Layer ins Bild?

Die Antwort ist einfacher als es scheint: Joule, Copilot und andere sind AI Agents - sie können Aufgaben ausführen. Der [Decision Layer](/de/decision-layer/) ist keine Alternative zu diesen Agents. Er ist die Governance-Schicht die darüber sitzt und steuert, was diese Agents tun dürfen.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Auf einen Blick - Decision Layer vs. Enterprise Agents</p>
<ul class="text-body text-gosign-text space-y-2">
<li>SAP Joule und Microsoft Copilot sind AI Agents, die Aufgaben ausführen. Der Decision Layer ist die Governance-Schicht darüber, die steuert, was sie tun dürfen.</li>
<li>Weder Joule noch Copilot bieten eingebaute Mechanismen für Betriebsvereinbarungen, AI-Act-Compliance oder prüfungssichere Entscheidungspfade.</li>
<li>Der Decision Layer ist modell- und agentenagnostisch - er funktioniert mit jedem Agenten, auch Open-Source-Modellen.</li>
<li>Enterprise-Unternehmen in regulierten Umgebungen brauchen beides: einen Agenten für die Ausführung und einen Decision Layer für Governance.</li>
<li>Agents sind austauschbar. Governance ist Infrastruktur.</li>
</ul>
</div>

## Agent vs. Governance-Schicht

Ein AI Agent kann eine Aufgabe ausführen: ein Dokument zusammenfassen, einen Buchungsvorschlag erstellen, eine Policy-Frage beantworten. Was der Agent nicht kann: entscheiden, ob er diese Aufgabe autonom ausführen darf oder ob ein Mensch eingreifen muss.

SAP Joule kann in SuccessFactors eine Gehaltsanpassung vorschlagen. Aber Joule entscheidet nicht, ob dieser Vorschlag automatisch ins System gehen darf oder ob der Betriebsrat ein Mitspracherecht hat. Joule kennt keine Betriebsvereinbarungen. Und Joules Audit-Logging protokolliert Aktionen und Quellen-Zitate - aber keinen Entscheidungsakt auf Fachregel-Ebene, der festhält, welche Tarifvertrags-Klausel in welcher Version die Entscheidung getragen hat.

Microsoft Copilot kann ein Onboarding-Dokument erstellen. Aber Copilot entscheidet nicht, welche Eingruppierung der Tarifvertrag vorsieht, ob der Betriebsrat zustimmen muss, oder ob die Datenschutzanforderungen des jeweiligen Standorts eingehalten werden.

Der Decision Layer übernimmt genau diese Steuerung.

## Wie Decision Layer und Enterprise-Agents zusammenarbeiten

Der Decision Layer zerlegt jeden Geschäftsprozess in einzelne Entscheidungsschritte und definiert für jeden Schritt: Mensch, Regelwerk oder KI. Wenn SAP Joule einen Buchungsvorschlag macht, durchläuft dieser Vorschlag den Decision Layer bevor er im System wirksam wird.

Der Decision Layer prüft: Ist der Vorschlag konsistent mit den versionierten Regelwerken? Liegt die Konfidenz über dem Schwellenwert? Berührt die Entscheidung einen Bereich der Mitbestimmung unterliegt? Ist ein Human-in-the-Loop erforderlich?

Wenn alles passt: Der Vorschlag geht ins Zielsystem. Der Audit Trail dokumentiert die Entscheidung.

Wenn nicht: Der Workflow pausiert. Ein Mensch bekommt den Vorschlag, die angewandte Regel, den Konfidenzwert und den Grund der Eskalation. Er entscheidet. Auch seine Entscheidung wird dokumentiert.

## Warum Enterprise-Unternehmen in Deutschland beides brauchen

SAP Joule und Microsoft Copilot werden in deutschen Unternehmen zunehmend ausgerollt. Aber der Rollout stößt auf drei Hürden die der Agent selbst nicht löst:

Erstens: Betriebsräte fordern Transparenz und Mitbestimmung bei KI-Entscheidungen. Weder Joule noch Copilot bieten eingebaute Mechanismen für Betriebsvereinbarungen als technische Constraints.

Zweitens: Der EU AI Act fordert dokumentierte Governance für Hochrisiko-KI-Systeme - geltende Frist 2. August 2026, mit am 7. Mai 2026 im Digital Omnibus vorläufig geeinigter Verschiebung auf den 2. Dezember 2027 (formale Verabschiedung ausstehend) - und HR-Prozesse fallen unter diese Kategorie. Die Pflichten betreffen Risikoanalyse, Dokumentation, Transparenz und menschliche Aufsicht - und mit Art. 86 das Recht der Betroffenen auf Erläuterung der einzelnen Entscheidung, beantwortbar nur über einen Entscheidungsakt pro Mikroentscheidung. Enterprise-Agents allein erfüllen das nicht.

Drittens: Wirtschaftsprüfer und interne Revision brauchen nachvollziehbare Entscheidungspfade. Ein Agent der "einen Vorschlag macht" ohne dokumentierten Entscheidungspfad ist ein Prüfungsrisiko.

Der Decision Layer ergänzt SAP Joule und Microsoft Copilot um genau diese drei Dimensionen: Betriebsratsfähigkeit, AI-Act-Compliance und Prüfungssicherheit.

## Die Abgrenzung auf einen Blick

| Fähigkeit | SAP Joule | Microsoft Copilot | Decision Layer |
|---|---|---|---|
| Aufgabenausführung | Ja | Ja | Nein (nur Governance) |
| Betriebsvereinbarungen als technische Constraints | Nein | Nein | Ja |
| AI-Act-Compliance-Dokumentation | Nein | Nein | Ja |
| Prüfungssicherer Entscheidungspfad | Nein | Nein | Ja |
| Entscheidungsakt pro Mikroentscheidung (Fachregel + Version) | Nein | Nein | Ja |
| Confidence Routing mit Eskalation | Nein | Nein | Ja |
| Human-in-the-Loop (architektonisch erzwungen) | Nein | Nein | Ja |
| Modellagnostisch | Nein (SAP-Ökosystem) | Nein (Microsoft-Ökosystem) | Ja |

SAP Joule ist der Agent innerhalb des SAP-Ökosystems. Microsoft Copilot ist der Agent innerhalb des Microsoft-Ökosystems. Der Decision Layer ist die modell- und agentenagnostische Governance-Schicht die über beiden sitzt.

Agents sind austauschbar. Governance ist Infrastruktur.

→ [Decision Layer im Detail](/de/magazin/decision-layer-erklaert/)

→ [Entscheidungsakt: Warum jede KI-Entscheidung anfechtbar sein muss](/de/magazin/entscheidungsakt-anfechtbare-ki-entscheidungen/)

→ [Referenz-Architektur](/de/governance/referenz-architektur/)

<a href="/de/kontakt/" target="_blank" rel="noopener noreferrer">Termin vereinbaren</a> - Wir zeigen Ihnen, wie der Decision Layer in Ihrer bestehenden Systemlandschaft funktioniert.

--- DeepSeek in der eigenen Infrastruktur hosten ---
> Wie Unternehmen die DeepSeek-Familie (R1, V4-Flash, V4-Pro) und andere LLMs DSGVO-konform in Azure, GCP oder Self-Hosted betreiben. Architektur, Datenhoheit, Decision-Routing statt Champion-Modell.

## Warum DeepSeek für Unternehmen relevant ist

[DeepSeek](https://www.deepseek.com/) hat mit seinen Open-Source-Modellen gezeigt, dass leistungsfähige LLMs nicht zwingend von OpenAI oder Google kommen müssen. Die DeepSeek-Familie reicht von **R1 (Januar 2025, MIT-Lizenz)** über **V4-Flash (April 2026, 284B/13B aktiv MoE, MIT)** bis **V4-Pro (1,6T/49B aktiv, 1M Kontext, MIT)** und erreicht in Benchmarks **GPT-5.5/Claude-Opus-4.7-Niveau** - V4-Pro nähert sich Frontier-Closed-Source-Performance unter MIT-Lizenz, bei deutlich niedrigeren Betriebskosten und mit vollständiger Transparenz über den Modell-Code.

**Update Mai 2026:** DeepSeek V4-Pro (1.6T/49B aktiv MoE) und V4-Flash (284B/13B aktiv) wurden am 24. April 2026 als Preview unter MIT-Lizenz released. Für neue Deployments ist V4-Flash der typische Workhorse, V4-Pro für Hyperscaler-Class-Setups oder via API/hosted bei kleineren Setups. Die R1-Architektur bleibt mature und production-ready, wird aber von V4-Flash bei neuen Deployments verdrängt. Details im [Self-hosted Open-Source-KI 2026 Artikel](/de/magazin/selbst-gehostete-open-source-ki-2026/).

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Auf einen Blick - DeepSeek im Enterprise-Einsatz</p>
<ul class="text-body text-gosign-text space-y-2">
<li>DeepSeek R1 ist Open Source (MIT-Lizenz) und kann vollständig Self-Hosted in Azure, GCP oder On-Premise betrieben werden - ohne Datenabfluss.</li>
<li>Self-Hosting eliminiert das DSGVO-Risiko der API-Nutzung, bei der Daten nach China fließen. Das Modell selbst ist nicht das Risiko - die API ist es.</li>
<li>Drei Hosting-Optionen (Azure, GCP, Self-Hosted) sind technisch gleichwertig; die Wahl hängt von IT-Landschaft und Compliance ab.</li>
<li>Eine modell-agnostische Architektur verhindert DeepSeek-Vendor-Lock-in: Wenn ein besseres Modell erscheint, wird es ohne Umbau integriert.</li>
<li>IDC (2024) schätzt, dass 42 % der europäischen Großunternehmen bis Ende 2026 mindestens ein Open-Weight-LLM auf eigener Infrastruktur betreiben werden.</li>
</ul>
</div>

Für Unternehmen ist das relevant, weil es eine echte Wahlmöglichkeit schafft: Statt sich an einen einzigen LLM-Anbieter zu binden, können Organisationen verschiedene Modelle parallel betreiben, vergleichen und je nach Anwendungsfall das passende Modell einsetzen.

Die eigentliche Frage ist nicht, ob DeepSeek gut genug ist. Die Frage ist, wie ein Unternehmen LLMs so betreibt, dass Datenhoheit, Compliance und Zukunftssicherheit gewährleistet sind - unabhängig davon, welches Modell gerade führend ist.


## Drei Hosting-Optionen im Vergleich

### Azure: Enterprise-Integration als Stärke

Azure AI Foundry bietet DeepSeek als Managed Deployment an. Der Vorteil für Unternehmen mit bestehender Microsoft-Landschaft: Integration in Azure Entra ID (ehemals Azure AD), bestehende Netzwerk- und Sicherheitskonfigurationen, und Region-Auswahl für EU-Datenresidenz. GPU-Instanzen (A100, H100) sind als Pay-as-you-go oder Provisioned Throughput verfügbar.

Der Nachteil: Vendor-Lock-in auf Azure-Ebene. Wer später zu GCP oder Self-Hosted wechseln will, muss die Deployment-Schicht neu aufbauen - wenn die Architektur nicht von Anfang an modell- und plattformagnostisch angelegt ist.

### GCP: Flexibilität und Kubernetes-native

Google Cloud Platform bietet über Vertex AI ebenfalls Managed Deployments für Open-Source-Modelle. Die Stärke liegt in der Kubernetes-nativen Architektur: Wer bereits GKE (Google Kubernetes Engine) nutzt, kann LLMs als Container-Workloads neben bestehenden Services betreiben. TPU-Optionen bieten eine Alternative zu NVIDIA-GPUs.

### Self-Hosted: Maximale Kontrolle

Für Unternehmen mit strengsten Datenschutzanforderungen - etwa im Finanzsektor oder im Gesundheitswesen - ist Self-Hosting die konsequente Wahl. DeepSeek-Modelle laufen auf eigenen Servern oder in einem privaten Rechenzentrum, ohne jede Cloud-Abhängigkeit. Der Trade-off: höherer operativer Aufwand für Hardware-Management, Updates und Skalierung.

| Kriterium | Azure | GCP | Self-Hosted |
|---|---|---|---|
| Setup | Managed (AI Foundry) | Managed (Vertex AI) | Manuell (Bare-Metal/VM) |
| EU-Datenresidenz | Germany West Central | europe-west3 | Eigenes Rechenzentrum |
| GPU-Verfügbarkeit | A100, H100 (Pay-as-you-go) | A100, H100, TPU | A100, H100 (Kauf/Leasing) |
| Vendor-Lock-in-Risiko | Hoch (Azure-spezifisch) | Mittel (Kubernetes-portabel) | Keines |
| Operativer Aufwand | Niedrig | Niedrig-Mittel | Hoch |
| Am besten für | Microsoft-zentrierte Orgs | Kubernetes-native Orgs | Maximale Datensouveränität |

Alle drei Optionen sind technisch gleichwertig. Es gibt keine architektonischen Kompromisse beim Self-Hosting. Die Entscheidung hängt von der bestehenden IT-Landschaft, den Compliance-Anforderungen und dem internen Betriebsmodell ab.


## Warum die Hosting-Entscheidung nicht die wichtigste ist

Die meisten Artikel über LLM-Hosting enden bei der Hosting-Entscheidung. Aber für Unternehmen ist das Hosting nur die Grundlage - die eigentlichen Fragen kommen danach.

Wie wird gesteuert, welches Modell für welchen Anwendungsfall eingesetzt wird? Wie werden Prompts und Antworten geloggt, ohne Mitarbeiterdaten zu kompromittieren? Wie wird sichergestellt, dass der Betriebsrat Transparenz über den KI-Einsatz hat? Wie wird ein Modellwechsel durchgeführt, ohne dass sich für 5.000 Mitarbeiter das Interface ändert?

Das sind keine Hosting-Fragen. Das sind Architektur- und Governance-Fragen. Und genau hier unterscheidet sich eine Enterprise-KI-Infrastruktur von einem gehosteten Modell.


## Modell-agnostische Architektur als Strategie

Die LLM-Landschaft verändert sich schneller als jeder Enterprise-Beschaffungszyklus. Was heute state-of-the-art ist, kann in sechs Monaten von einem neuen Modell überholt werden. Wer seine gesamte Infrastruktur auf einem einzelnen Frontier-Modell baut - egal ob auf DeepSeek V4-Pro, GPT-5.5 oder Claude Opus 4.7 - hat ein strategisches Risiko. Eine modell-agnostische Decision-Routing-Schicht (siehe [Welches Modell wann?](/de/magazin/ki-modelle-vergleich-2026/)) absorbiert den nächsten Generationswechsel als Konfigurationsänderung statt als Re-Engineering.

Eine [modell-agnostische Architektur](/de/leistungen/infrastruktur/) entkoppelt die Nutzungsschicht von der Modellschicht. Mitarbeiter nutzen ein einheitliches Chat-Interface. Dahinter routet eine Orchestrierungsschicht pro Mikro-Entscheidung statt mit einem Champion-Modell: **Mistral Small 3.2** (24B, Apache 2.0, RTX 4090) als Volume-Workhorse für 50-70 % der Entscheidungen (Klassifikation, Extraktion); **DeepSeek V4-Flash/V4-Pro** (MIT) oder **gpt-oss-120b** (Apache 2.0) für on-prem Reasoning; **Claude Opus 4.7 / GPT-5.5** (Cloud) für Frontier-Reasoning und agentische Workflows; **Gemini 3.1 Pro** (Cloud) für multimodale Anwendungen; **Qwen 3 Coder / DeepSeek Coder V4** für Code-Generation on-prem. [Llama](https://llama.meta.com/) und [Mistral](https://mistral.ai/) ergänzen den Stack für spezialisierte Domänen.

Modellwechsel, Modellvergleiche und A/B-Tests erfolgen in der Orchestrierungsschicht - transparent für Nutzer, auditierbar für die IT, nachvollziehbar für den Betriebsrat.


## DeepSeek als Baustein, nicht als Plattform

DeepSeek ist ein leistungsfähiges Modell. Aber kein Modell allein löst das Enterprise-Problem. Was Unternehmen brauchen, ist nicht ein gehostetes LLM, sondern eine Infrastruktur, in der LLMs als Komponenten arbeiten - eingebettet in [Governance by Design](/de/governance/), integriert in bestehende Systeme, erweiterbar um [AI-Agenten](/de/leistungen/ai-agents/), die Dokumente verarbeiten und Workflows orchestrieren.

Der [Decision Layer](/de/decision-layer/) trennt dabei die LLM-Analyse von der Geschäftsentscheidung. Das Modell bereitet vor, der Mensch entscheidet - mit vollständigem Audit-Trail.

Bei Gosign bauen wir diese [KI-Infrastruktur](/de/leistungen/infrastruktur/): modell-agnostisch, DSGVO-konform, in Azure, GCP oder Self-Hosted. DeepSeek ist einer von vielen Bausteinen. Die Architektur macht den Unterschied.

--- DevOps-Runbook-Serie: Security für den Self-Hosted Stack ---
> Sechsteilige DevOps-Runbook-Serie: Supabase, Next.js, Edge Functions, Trigger.dev, Claude Code Audits und Security Baseline.

Diese Serie liefert sechs praxisorientierte Runbooks für den sicheren Betrieb eines self-hosted App-Stacks. Sie richtet sich an DevOps-Teams, die Supabase, Next.js und verwandte Technologien produktiv einsetzen und systematisch absichern wollen.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Auf einen Blick - DevOps-Runbook-Serie</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Sechs Runbooks decken den kompletten self-hosted Stack ab: Supabase, Next.js, Edge Functions, Trigger.dev, Claude Code Audits und Security Baseline.</li>
<li>Jeder Artikel enthält konkrete Implementierungen mit echtem Code, prüfbare Bedingungen und herunterladbare Claude Code Checklisten.</li>
<li>Die Serie baut aufeinander auf - von der Plattform-Basis (Supabase) bis zur maschinenlesbaren YAML-Baseline für den gesamten Stack.</li>
<li>Zielgruppe: DevOps-Engineers, CTOs, Security-Engineers und Entwickler die auf Supabase und Next.js aufbauen.</li>
<li>Laut SANS Institute (2024) erkennen Organisationen mit maschinenlesbarer Security Baseline Konfigurationsdrift 14-mal schneller.</li>
</ul>
</div>

## Warum ein systematischer Ansatz

Self-Hosting gibt Ihnen Kontrolle über Daten und Infrastruktur. Diese Kontrolle bringt aber Verantwortung mit sich: Jede Komponente hat eigene Sicherheitsanforderungen, und zwischen den Schichten entstehen Abhängigkeiten, die bei isolierter Betrachtung unsichtbar bleiben.

Ein systematischer, maschinenlesbarer Security-Ansatz über alle Schichten hinweg macht den Unterschied. Laut SANS Institute (2024) erkennen Organisationen mit einer maschinenlesbaren Security Baseline Konfigurationsdrift im Durchschnitt **14-mal schneller** als Teams ohne Baseline.

Diese Serie führt Sie Schicht für Schicht durch den Stack und schließt mit einer YAML-basierten Baseline ab, die alle Regeln aus den einzelnen Runbooks zusammenfasst.

## Serienüberblick

| Teil | Artikel | Schwerpunkt | Ergebnis |
|------|---------|-------------|----------|
| 1 | [Supabase Self-Hosting Runbook](/de/magazin/supabase-self-hosting/) | Plattform-Basis | Server-Architektur, Docker Compose, RLS |
| 2 | [Next.js über Supabase sicher betreiben](/de/magazin/nextjs-supabase-sicher-betreiben/) | App-Schicht | Auth, Middleware, Environment-Trennung |
| 3 | [Supabase Edge Functions sicher einsetzen](/de/magazin/supabase-edge-functions-sicher/) | Integrationen | Webhooks, Signaturen, CORS |
| 4 | [Trigger.dev Background Jobs sicher betreiben](/de/magazin/trigger-dev-background-jobs/) | Async Processing | Tasks, Idempotenz, Concurrency |
| 5 | [Claude Code als Sicherheitskontrolle im DevOps-Workflow](/de/magazin/claude-code-security-devops/) | Automatisierte Audits | Custom Commands, Headless Mode |
| 6 | [Security Baseline für den gesamten Stack](/de/magazin/security-baseline-stack/) | Gesamt-Baseline | YAML, automatisierte Checks |

## Die Artikel im Detail

**Teil 1 - Supabase Self-Hosting Runbook.** Beschreibt eine Zwei-Server-Architektur (Produktion und Audit), Docker Compose mit versionsgepinnten Images, Service-Konfiguration für sieben Komponenten und Row Level Security als Pflicht auf allen public-Tabellen.

**Teil 2 - Next.js sicher betreiben.** Behandelt die App-Schicht über Supabase: Auth-Flow mit PKCE, Middleware zur Route Protection, strikte Environment-Trennung zwischen Server und Client und sichere API-Route-Patterns.

**Teil 3 - Edge Functions sicher einsetzen.** Fokussiert auf Webhook-Verarbeitung mit Signaturprüfung, CORS-Konfiguration, Input Validation in der Deno-Runtime und sichere Secret-Verwaltung für Drittanbieter-Integrationen.

**Teil 4 - Trigger.dev Background Jobs.** Beschreibt Self-Hosted Setup von Trigger.dev v3, idempotente Task-Definition, Concurrency-Kontrolle, Retry-Strategien und Secrets-Isolation zwischen Tasks.

**Teil 5 - Claude Code als Sicherheitskontrolle.** Zeigt, wie Claude Code als automatisiertes Audit-Tool im DevOps-Workflow eingesetzt wird: Custom Commands, headless Audit-Runs und Integration in CI-Pipelines.

**Teil 6 - Security Baseline.** Fasst alle Regeln aus den Artikeln 1 bis 5 in einer maschinenlesbaren `security-baseline.yml` zusammen. Enthält deterministische Check-Scripts und die Integration mit dem Claude Code Audit.

## Für wen diese Serie gedacht ist

- DevOps-Engineers, die self-hosted Infrastruktur betreiben
- CTOs und technische Leads, die Self-Hosting vs. Managed Services evaluieren
- Security-Engineers, die App-Stacks auditieren
- Entwickler, die auf Supabase und Next.js aufbauen

## So nutzen Sie die Serie

- Lesen Sie die Artikel in der Reihenfolge 1 bis 6, da sie aufeinander aufbauen
- Laden Sie die Claude Code Checklisten am Ende jedes Artikels herunter
- Implementieren Sie die Empfehlungen Schicht für Schicht in Ihrer Umgebung
- Verwenden Sie die Security Baseline aus Artikel 6 als tägliches Monitoring-Gate

--- Drei Arten von Entscheidungen: Wann der Mensch, wann die KI ---
> Nicht jede Entscheidung braucht einen Menschen. Framework für die Zuordnung zu Mensch, Regelwerk oder KI - mit konkreten HR-Beispielen.

## Die Frage die jede HR-Abteilung stellt

"Welche Entscheidungen kann die KI alleine treffen - und welche müssen beim Menschen bleiben?"

Diese Frage kommt in jedem Gespräch über KI in HR-Prozessen. Vom Betriebsrat, von der Geschäftsführung, von der Compliance-Abteilung. Und die übliche Antwort - "die KI unterstützt, der Mensch entscheidet" - ist zu ungenau für den produktiven Einsatz.

Denn in der Praxis besteht ein einziger HR-Prozess aus Dutzenden einzelner Entscheidungen. Bei der Krankmeldungsverarbeitung zum Beispiel: Ist das Dokument vollständig? Welcher Tarifvertrag gilt? Liegt die Krankheitsdauer über der Lohnfortzahlungsgrenze? Muss ein BEM-Verfahren eingeleitet werden? Wer wird informiert?

Manche dieser Entscheidungen brauchen einen Menschen. Manche nicht. Und manche sollten bewusst NICHT beim Menschen liegen - weil die KI sie nachweislich besser trifft.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Auf einen Blick - Drei Arten von Entscheidungen</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Jeder Geschäftsprozess zerfällt in Mikro-Entscheidungen dreier Typen: Mensch entscheidet, Regelwerk greift oder KI entscheidet eigenständig.</li>
<li>KI eigenständig ist nicht die Kategorie für Triviales - sondern für Entscheidungen, bei denen Konsistenz, Ermüdungsfreiheit und Vollständigkeit wichtiger sind als Ermessensspielraum.</li>
<li>KI übertrifft den Menschen strukturell auf drei Ebenen: identische Ergebnisse standortübergreifend, kein Qualitätsverlust durch Ermüdung, vollständige Regelprüfung jedes Mal.</li>
<li>Ein einzelner HR-Prozess wie die Krankmeldungsverarbeitung enthält alle drei Typen - der Decision Layer erzwingt die korrekte Zuordnung pro Schritt.</li>
<li>Dieses Framework macht die Argumentation gegenüber dem Betriebsrat transparent: KI entscheidet, wo Qualität es erfordert. Menschen entscheiden, wo Ermessen es erfordert.</li>
</ul>
</div>

[McKinsey Global Institute (2023)](https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/the-economic-potential-of-generative-ai-the-next-productivity-frontier) schätzt, dass 60 bis 70 Prozent der heutigen Arbeitszeit auf Tätigkeiten entfallen, die mit aktueller KI-Technologie automatisierbar sind - aber nur Entscheidungen mit klaren Regeln und geringem Ermessensspielraum eignen sich für vollständige Automatisierung.

## Drei Arten von Entscheidungen

### Art 1: Mensch entscheidet

Hier muss ein Mensch die finale Entscheidung treffen. Der Agent kann vorbereiten, vorschlagen, Material zusammenstellen - aber die Entscheidung selbst liegt beim Menschen.

**Wann:** Ermessensspielraum, Diskriminierungsrisiko, Betriebsrats-Pflicht, individuelle Situationen.

**Beispiel: Wiedereingliederung nach Langzeiterkrankung.** Der Agent hat alle Daten: Krankheitsdauer, BEM-Historie, Empfehlungen der Betriebsärztin, verfügbare Stellen. Aber die Entscheidung, welches Wiedereingliederungsmodell für diesen konkreten Menschen passt, braucht einen Menschen. Es geht um die individuelle Situation, um Einfühlungsvermögen, um das Gespräch mit der Person. Der Betriebsrat hat ein Mitspracherecht. Und wenn die Entscheidung falsch ist, hat das reale Konsequenzen für einen echten Menschen.

**Was der Decision Layer hier tut:** Er erzwingt Human-in-the-Loop. Technisch, nicht organisatorisch. Der Agent kann diese Entscheidung nicht autonom treffen - auch nicht wenn seine Konfidenz hoch ist.

### Art 2: Regelwerk entscheidet

Deterministische Logik. Wenn Bedingung X, dann Ergebnis Y. Kein Interpretationsspielraum.

**Wann:** Tarifvertrag, Betriebsvereinbarung, Steuergesetzgebung, Eingruppierung, Fristenberechnung.

**Beispiel: Eingruppierung in Gehaltsband.** Neuer Mitarbeiter, Stellenprofil liegt vor, Tarifvertrag ist eindeutig. Die Eingruppierung ergibt sich aus den Kriterien im Tarifvertrag. Das ist keine Entscheidung die Interpretation braucht - es ist eine Regelanwendung. Der Decision Layer wendet die aktuelle Regelversion an und dokumentiert das Ergebnis.

**Was der Decision Layer hier tut:** Er stellt sicher, dass die aktuelle Regelversion angewandt wird. Wenn sich der Tarifvertrag ändert, greift ab dem Stichtag die neue Version - automatisch, ohne dass jemand 50 Sachbearbeiter an 12 Standorten informieren muss.

### Art 3: KI entscheidet eigenständig

Und hier wird es interessant. Denn diese Kategorie wird meistens falsch erzählt. Die übliche Darstellung: "Bei einfachen Standardfällen darf die KI auch mal alleine." Das klingt nach Erlaubnis für Triviales.

Die Realität ist eine andere. Es gibt Entscheidungen, bei denen die KI nicht nur schneller ist, sondern **nachweislich besser** als ein Mensch. Nicht weil die KI klüger ist - sondern weil sie drei strukturelle Schwächen des Menschen nicht hat.

#### Vorteil 1: Konsistenz über Standorte und Personen

50 Sachbearbeiter an 12 Standorten wenden denselben Tarifvertrag an. Jeder interpretiert Grenzfälle leicht anders. In Hamburg wird ein Antrag auf Sonderzahlung genehmigt, in München wird derselbe Fall abgelehnt. Das ist kein Ausbildungsproblem - es ist die natürliche Varianz menschlicher Entscheidungen bei ambigen Regeln.

Eine KI die auf einem versionierten Regelwerk arbeitet, entscheidet identisch. Jedes Mal. An jedem Standort. Um 9 Uhr morgens und um 16 Uhr nachmittags.

**Konkret:** Lohnfortzahlungsfrist-Prüfung. Derselbe Fall, dieselbe Regel, dasselbe Ergebnis. Nicht abhängig davon, welcher Sachbearbeiter in welcher Niederlassung den Fall bearbeitet.

#### Vorteil 2: Ermüdungsfreiheit

Ein Recruiter screent am Montagmorgen anders als am Freitagnachmittag. Nach der 50. Bewerbung sinkt die Aufmerksamkeit. Der vorletzte Kandidat war besonders stark - der nächste wirkt im Vergleich schwächer, obwohl er objektiv die Anforderungen erfüllt (Anchoring-Bias). Der Recruiter hat gerade schlechte Nachrichten bekommen - die nächsten drei Bewertungen fallen strenger aus (Affect Heuristic).

Das sind keine persönlichen Schwächen. Das ist menschliche Kognition. Gut erforscht, vielfach belegt, und in jedem repetitiven Entscheidungsprozess messbar.

Eine KI bewertet Bewerbung Nummer 1 mit derselben Sorgfalt wie Bewerbung Nummer 200. Sie hat keinen schlechten Tag.

**Konkret:** Anforderungsabgleich im Recruiting. Jede Bewerbung wird gegen dasselbe Kriterienprofil geprüft. Nicht beeinflusst von der Reihenfolge der Bewerbungen, nicht von der Tageszeit, nicht von der emotionalen Verfassung des Recruiters.

#### Vorteil 3: Vollständigkeit bei Regelprüfung

Das ist der Vorteil, der am meisten unterschätzt wird.

Ein HR-Sachbearbeiter prüft eine Krankmeldung gegen drei bis vier Kriterien, die ihm gerade einfallen: Krankheitsdauer, Lohnfortzahlungsfrist, vielleicht noch die BEM-Schwelle. Aber prüft er auch die Wartezeitregelung aus § 3 Abs. 3 EFZG? Die Sonderregel für Teilzeitkräfte im Haustarifvertrag? Die Meldepflicht gegenüber der Berufsgenossenschaft bei bestimmten Krankheitsbildern? Den Sonderfall bei Arbeitsunfällen? Die Regelung für befristete Verträge?

Jedes Mal? Auch freitags um 16 Uhr? Auch wenn er gerade fünf andere Fälle parallel bearbeitet?

Eine KI prüft gegen alle geltenden Regeln, in der aktuellen Version, vollständig und dokumentiert. Nicht weil sie klüger ist - sondern weil sie nicht vergisst. Und weil ihr Regelwerk nicht in Köpfen steckt, sondern im versionierten System.

**Konkret:** Krankmeldungsverarbeitung. Der Agent prüft jede eAU gegen alle 12 relevanten Kriterien aus Tarifvertrag, Betriebsvereinbarung und Gesetz. Jedes Mal. Das Ergebnis: Weniger Fehler die erst bei der nächsten Betriebsprüfung auffallen.

## Warum ein einzelner Prozess alle drei Arten enthält

Das Framework wird erst dann praktisch nützlich, wenn man versteht: Ein einzelner HR-Prozess enthält fast immer ALLE drei Entscheidungstypen.

Nehmen wir die Krankmeldungsverarbeitung als durchgängiges Beispiel:

| Schritt | Entscheidungsart | Warum |
|---|---|---|
| eAU-Daten empfangen und validieren | **KI eigenständig** | Dokumentklassifikation, hohe Treffsicherheit, strukturierte Eingabe |
| Abgleich mit Personalstammdaten | Regelwerk | Deterministisch, keine Interpretation |
| Lohnfortzahlungsfrist prüfen | **KI eigenständig** | Prüft gegen ALLE Tarifvertragskriterien, konsistenter als jeder Sachbearbeiter |
| BEM-Pflicht prüfen (> 6 Wochen in 12 Monaten) | Mensch | Diskriminierungsrisiko bei Gesundheitsdaten, BR-Mitbestimmung |
| Führungskraft informieren | **KI eigenständig** | Konsistente Information, kein Vergessen, kein Interpretationsspielraum bei der Frage WAS mitgeteilt wird (nur Abwesenheit und Dauer, keine Diagnose) |
| Wiedereingliederungsmaßnahmen einleiten | Mensch | Individuelle Situation, Ermessensspielraum, BR-Beteiligung |

Beachten Sie die dritte Zeile: "Lohnfortzahlungsfrist prüfen" ist nicht bei "Regelwerk", sondern bei "KI eigenständig". Warum? Weil die KI hier nicht nur eine simple Wenn-Dann-Logik anwendet, sondern die Prüfung VOLLSTÄNDIG gegen alle geltenden Regelwerke durchführt - etwas das ein Mensch in der Praxis nie vollständig tut, weil er nicht alle Sonderregelungen im Kopf hat.

Das ist der entscheidende Punkt: "KI eigenständig" ist nicht die Kategorie für Triviales. Es ist die Kategorie für Entscheidungen, bei denen Konsistenz, Ermüdungsfreiheit und Vollständigkeit wichtiger sind als Ermessensspielraum.

## Was das für den Betriebsrat bedeutet

Der Betriebsrat ist oft skeptisch gegenüber KI-Autonomie. Zurecht - wenn unklar ist, WARUM die KI eigenständig entscheidet.

Mit dem Drei-Arten-Framework wird die Argumentation transparent:

"Die KI entscheidet eigenständig bei der Fristenprüfung. Nicht weil wir Stellen sparen wollen. Sondern weil wir wissen, dass 50 Sachbearbeiter an 12 Standorten dieselbe Frist unterschiedlich berechnen. Die KI rechnet immer richtig. Und wenn sie sich nicht sicher ist, eskaliert sie an einen Menschen. Das ist nachvollziehbar, dokumentiert und jederzeit im Auditor Portal einsehbar."

Das ist ein Argument das der Betriebsrat versteht. Es geht nicht um Ersetzung, sondern um Qualitätssicherung.

## Der Decision Layer macht die Zuordnung operativ

Das Framework bleibt Theorie, wenn es nicht technisch durchgesetzt wird. Der [Decision Layer](/de/decision-layer/) implementiert die Drei-Arten-Zuordnung für jeden Prozessschritt:

Für jede Micro-Entscheidung ist definiert: Mensch, Regelwerk oder KI. Bei KI-Entscheidungen ist dokumentiert, warum die KI die richtige Wahl ist. Bei Mensch-Entscheidungen ist Human-in-the-Loop technisch erzwungen. Bei Regelwerk-Entscheidungen ist die aktuelle Regelversion hinterlegt. Jede Entscheidung - egal welcher Art - erzeugt einen Entscheidungsakt: Input, Regel samt Version, Konfidenz, Ergebnis, Anfechtungspfad. Das ist die Grundlage der Anfechtbarkeit nach Art. 86 EU AI Act.

→ [Decision Layer - Übersicht und Beispiele](/de/decision-layer/)

→ [Entscheidungsakt: Warum jede KI-Entscheidung anfechtbar sein muss](/de/magazin/entscheidungsakt-anfechtbare-ki-entscheidungen/)

→ [Warum KI-Projekte in HR scheitern](/de/magazin/warum-ki-projekte-scheitern/)

<a href="/de/kontakt/" target="_blank" rel="noopener noreferrer">Termin vereinbaren</a> - Wir zeigen Ihnen an Ihrem konkreten Prozess, welche Entscheidungen beim Menschen bleiben und welche die KI besser trifft.

--- Enterprise-AI-Portale: Fünf Interfaces im Vergleich ---
> LobeChat, OpenWebUI, LibreChat, chatbot-ui und very-ai - fünf Enterprise-AI-Portale im Vergleich. Funktionen, SSO, PII-Schutz, Governance, Self-Hosting.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Auf einen Blick - Enterprise-AI-Portale</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Ein Chat-Interface allein reicht nicht - Unternehmen brauchen Portale mit SSO, Audit Trail, Assistenten-Sharing und Agenten-Integration, um Shadow AI zu verhindern.</li>
<li>Fünf Open-Source-Optionen stehen zur Wahl: LobeChat, OpenWebUI, LibreChat, chatbot-ui und very-ai - jeweils für unterschiedliche Governance-Anforderungen geeignet.</li>
<li>PII-Erkennung und Anonymisierung ist das entscheidende Differenzierungsmerkmal für regulierte Umgebungen, in denen Mitarbeiterdaten in KI-Prompts eingehen.</li>
<li>Gartner (2024) berichtet, dass 55 % der Unternehmen mit generativer KI kein Governance-Framework für deren Nutzung etabliert haben.</li>
<li>Der entscheidende Faktor für die Akzeptanz ist nicht Technologie, sondern Nutzererlebnis - das interne Portal muss vom ersten Tag an mit öffentlichen KI-Diensten mithalten oder sie übertreffen.</li>
</ul>
</div>

## Das Problem: Modell ohne Interface

Ein KI-Modell ohne kontrolliertes Interface ist wie ein Server ohne Frontend. Die Technologie ist vorhanden, aber niemand kann sie geordnet nutzen. Was dann passiert, ist vorhersagbar: Mitarbeitende nutzen öffentliche KI-Dienste - ChatGPT, Gemini, Claude.ai - mit ihren privaten Accounts. Sie geben Unternehmensdaten in Systeme ein, die außerhalb der Kontrolle der IT-Abteilung liegen. Es gibt keinen Audit-Trail, keine Datenklassifikation, keine Zugriffskontrolle.

Das ist Shadow AI. Und die Frage ist nicht, ob es in Ihrem Unternehmen passiert. Die Frage ist, wie stark.

Die Lösung ist nicht, KI-Nutzung zu verbieten. Die Lösung ist, ein internes System bereitzustellen, das besser funktioniert als die öffentlichen Alternativen - und dabei unter Unternehmenskontrolle läuft. Dafür reicht ein einfaches Chat-Interface nicht aus. Was Sie brauchen, ist ein Enterprise-AI-Portal.

## Was ein Enterprise-AI-Portal können muss

Ein Enterprise-AI-Portal ist mehr als ein Chat-Fenster. Es ist die zentrale Plattform, über die alle Mitarbeitenden mit KI interagieren - kontrolliert, protokolliert und integriert in die bestehende Systemlandschaft. Sechs Anforderungen unterscheiden ein Enterprise-Portal von einem Consumer-Chat:

### 1. Multi-Modell-Routing

Das Portal muss mehrere Modelle gleichzeitig anbinden - proprietäre Cloud-APIs und Self-Hosted-Modelle. Die Routing-Logik entscheidet automatisch, welches Modell für welche Anfrage genutzt wird: nach Aufgabentyp, Datensensibilität und Kostenvorgabe. Mitarbeitende sehen ein einheitliches Interface. Welches Modell im Hintergrund arbeitet, ist für sie transparent, aber nachvollziehbar.

### 2. Assistenten-Sharing

Fachabteilungen erstellen spezialisierte Assistenten - mit eigenem System-Prompt, eigenen Dokumenten und eigenem Regelwerk. Ein Assistent für die Rechtsabteilung, der Vertragsprüfung vorbereitet. Ein Assistent für HR, der Bewerbungsunterlagen zusammenfasst. Ein Assistent für den Einkauf, der Lieferantenangebote vergleicht. Diese Assistenten werden innerhalb der Abteilung geteilt, versioniert und zentral verwaltet.

Das ist der entscheidende Unterschied zu einem reinen Chat-Interface: Nicht jeder Mitarbeitende muss Prompts von Grund auf schreiben. Stattdessen nutzt er einen Assistenten, der von Fachkollegen konfiguriert und optimiert wurde. Das senkt die Einstiegshürde und erhöht die Ergebnisqualität.

### 3. Agenten-Integration

Ein Enterprise-Portal muss über Chat hinausgehen. Es muss [KI-Agenten](/de/magazin/ai-agenten-enterprise-leitfaden/) integrieren können - spezialisierte Workflows, die Dokumente verarbeiten, Daten extrahieren, Entscheidungen vorbereiten oder externe Systeme ansprechen. Der Agent wird über das Portal angestoßen, sein Fortschritt wird angezeigt, sein Ergebnis wird im Portal dokumentiert.

### 4. SSO und rollenbasierte Zugriffskontrolle (RBAC)

Mitarbeitende melden sich über das bestehende Identity-Management an - Azure AD, Okta, Google Workspace. Keine separaten Accounts, keine separaten Passwörter. Die Zugriffskontrolle ist rollenbasiert: Wer darf welche Modelle nutzen? Wer darf Assistenten erstellen? Wer darf auf welche Dokumentenquellen zugreifen? Wer hat Zugang zu Agenten-Workflows?

### 5. Audit-Trail

Jede Interaktion wird protokolliert. Wer hat wann welche Anfrage gestellt? Welches Modell hat geantwortet? Welche Dokumente wurden referenziert? Welche Kosten sind entstanden? Der Audit-Trail ist exportierbar - für interne Revision, für Compliance-Prüfungen, für die EU-AI-Act-Dokumentation.

### 6. Deployment-Flexibilität

Das Portal muss in verschiedenen Umgebungen deploybar sein: als Cloud-Dienst (Supabase, Vercel), als Container in einem deutschen Rechenzentrum, oder On-Premises. Die Hosting-Entscheidung für das Portal folgt denselben Kriterien wie die Hosting-Entscheidung für die Modelle (siehe [Hosting-Strategien](/de/magazin/ki-hosting-strategien-enterprise/)).

## Open-Source-Interfaces im Vergleich

Fünf Open-Source-Projekte haben sich als Kandidaten für Enterprise-AI-Portale positioniert: LobeChat, OpenWebUI, LibreChat, chatbot-ui und very-ai. Alle fünf sind Self-Hosted, modell-agnostisch und bieten ein Chat-Interface für Sprachmodelle. Die Unterschiede liegen in SSO-Integration, Governance-Funktionen, PII-Schutz und Betriebsrats-Kompatibilität.

**Transparenzhinweis:** very-ai wird von Gosign GmbH entwickelt - dem Herausgeber dieser Artikelserie. Wir legen die Stärken und Einschränkungen aller fünf Portale gleichermaßen offen dar. very-ai basiert auf einem Fork von chatbot-ui (MIT-Lizenz) und hat sich durch 16 Enterprise-Erweiterungen zu einem eigenständigen Produkt entwickelt.

## Vergleich: Fünf Enterprise-AI-Portale

| Kriterium | LobeChat | OpenWebUI | LibreChat | chatbot-ui | very-ai |
|-----------|----------|-----------|-----------|------------|---------|
| **Lizenz** | Apache 2.0 | MIT | MIT | MIT | Apache 2.0 |
| **Basis** | Eigenentwicklung | Eigenentwicklung | Eigenentwicklung | Eigenentwicklung | Fork von chatbot-ui |
| **Modell-Agnostik** | ✅ OpenAI, Anthropic, Google, Ollama | ✅ OpenAI, Ollama, LiteLLM | ✅ OpenAI, Anthropic, Google, Mistral | ✅ OpenAI, Anthropic, Google, Ollama | ✅ OpenAI, Anthropic, Google (Vertex AI), Ollama |
| **SSO** | ❌ Nicht nativ | OAuth 2.0 (kein Entra ID nativ) | OAuth 2.0, OpenID Connect | ❌ Nicht nativ | ✅ Azure Entra ID nativ mit Gruppen- und Rechte-Sync |
| **PII-Schutz** | ❌ | ❌ | ❌ | ❌ | ✅ Erkennung, Anonymisierung und Re-Anonymisierung |
| **PII pro Assistent/Modell** | - | - | - | - | ✅ Konfigurierbar pro Assistent UND pro Modell |
| **Gruppen-Assistenten** | ❌ | Community-Modelle (eingeschränkt) | Shared Conversations | ❌ | ✅ Über Entra-ID-Gruppen gesteuert |
| **Audit Trail** | ❌ | Basis-Logging | Basis-Logging | ❌ | ✅ Vollständig, exportierbar (CSV/JSON) |
| **DSGVO-Statistiken** | ❌ | ❌ | ❌ | ❌ | ✅ Anonymisierte Nutzungsstatistiken |
| **Trigger.dev-Integration** | ❌ | ❌ | ❌ | ❌ | ✅ Workflow-Trigger aus dem Chat |
| **Thinking-Level** | ❌ | ❌ | ❌ | ❌ | ✅ Extended Thinking / Reasoning-Steuerung |
| **Web/Maps-Suche** | Plugin-System | Web-Suche (RAG) | Plugin-System | ❌ | ✅ Integriert |
| **Docker Self-Hosted** | ✅ | ✅ | ✅ | ✅ | ✅ |
| **GitHub Stars (Feb 2026)** | ~50k | ~60k | ~20k | ~28k | Neu (Open Source Launch) |
| **Betriebsrats-Kompatibilität** | ⚠️ Eingeschränkt (kein Audit, kein RBAC) | ⚠️ Basis-RBAC | ⚠️ Basis-RBAC | ❌ Keine Governance | ✅ Audit Trail + RBAC + PII + Entra ID |

### LobeChat

LobeChat ist ein optisch ansprechendes Chat-Interface mit Plugin-Architektur. Die Stärke liegt in der Consumer-Nutzung und der Plugin-Vielfalt. Für Enterprise fehlen robustes RBAC, exportierbarer Audit-Trail und native Agenten-Integration. Als schneller Prototyp oder für kleine Teams geeignet, für den unternehmensweiten Rollout zu limitiert.

### OpenWebUI

OpenWebUI ist der De-facto-Standard für Ollama-basierte Self-Hosting-Setups. Die Integration mit lokal laufenden Modellen ist hervorragend. SSO und grundlegendes Logging sind vorhanden. Was fehlt: Assistenten-Sharing, Enterprise-Agenten-Integration und eine zentrale Verwaltung für mehrere Hundert Nutzer.

### LibreChat

LibreChat ist ein Open-Source-Klon der ChatGPT-Oberfläche mit Multi-Modell-Unterstützung. SSO und grundlegendes RBAC sind implementiert. Für Unternehmen, die eine ChatGPT-ähnliche Erfahrung intern abbilden wollen, ist LibreChat ein solider Ausgangspunkt. Die Grenzen liegen bei Agenten-Integration und Assistenten-Sharing.

## very-ai - Enterprise-Portal mit PII-Schutz und Governance

very-ai ist ein Enterprise-AI-Portal, das auf chatbot-ui (MIT) basiert und 16 Enterprise-Funktionen ergänzt, die in keinem der vier anderen Portale existieren. Es wird von Gosign GmbH entwickelt und ist unter Apache 2.0 auf GitHub verfügbar.

**Herkunft und Abgrenzung:**
chatbot-ui liefert ein solides Chat-Interface, hat aber keine SSO-Integration, keinen Audit Trail und keinen PII-Schutz. very-ai setzt genau dort an: Die Codebasis wurde um Enterprise-Funktionen erweitert, die für den produktiven Einsatz in regulierten Umgebungen notwendig sind. Die Attribution zum Ursprungsprojekt ist in der NOTICES-Datei dokumentiert.

**PII-Erkennung und Re-Anonymisierung:**
Das zentrale Differenzierungsmerkmal. very-ai erkennt personenbezogene Daten (Namen, E-Mail-Adressen, Telefonnummern, IBANs) im Nutzer-Prompt, ersetzt sie durch Platzhalter ([PERSON_1], [EMAIL_1]), sendet den anonymisierten Text an das Sprachmodell und setzt die Originaldaten in die Antwort wieder ein. Der Nutzer sieht die echten Namen, das Sprachmodell hat sie nie gesehen.

Dieses PII-Verhalten ist pro Assistent und pro Modell konfigurierbar: Assistent A kann PII erlauben, Assistent B anonymisiert automatisch. Modell X bekommt anonymisierte Daten, Modell Y (ein lokal gehostetes Modell) bekommt die Rohdaten.

**Azure Entra ID mit Gruppen-Sync:**
Nicht nur Authentifizierung, sondern automatische Synchronisation von Entra-ID-Gruppen und -Rollen. Mitarbeiter in der Entra-ID-Gruppe „HR" sehen automatisch die HR-Assistenten. Mitarbeiter in „Finance" sehen Finance-Assistenten. Ohne manuelle Rechtevergabe im Portal. Ändert sich die Gruppenzugehörigkeit in Entra ID, ändert sich der Zugriff im Portal beim nächsten Login.

**Gruppen-Assistenten:**
Administratoren erstellen Assistenten und weisen sie Entra-ID-Gruppen zu. Diese Assistenten sind nur für Mitglieder der jeweiligen Gruppe sichtbar und nutzbar. Das ermöglicht abteilungsspezifische KI-Werkzeuge ohne ein separates Rechtemanagement.

**Audit Trail und DSGVO-Statistiken:**
Jede Interaktion wird protokolliert: Nutzer, Modell, Assistent, Prompt, Antwort, Zeitstempel, Token-Verbrauch, PII-Modus. Der Audit Trail ist exportierbar (CSV, JSON) und filtert nach Zeitraum und Nutzer. Die Nutzungsstatistiken sind DSGVO-konform anonymisiert - sie zeigen Modell- und Assistenten-Nutzung, aber keine nutzeridentifizierenden Daten.

**Trigger.dev-Workflow-Integration:**
Nutzer können aus dem Chat heraus Trigger.dev-Workflows triggern. Das verbindet das AI-Portal mit der Automatisierungsschicht (→ Artikel 10: Agent-Orchestrierungsplattformen).

**Einschränkungen (ehrlich):**
very-ai ist ein neues Open-Source-Projekt. Die Community ist klein im Vergleich zu LobeChat (50k Stars) oder OpenWebUI (60k Stars). Die Plugin-Ökosysteme der etablierten Portale sind umfangreicher. Wer ein Portal mit maximaler Community-Unterstützung und Plugin-Vielfalt sucht, ist bei LobeChat oder OpenWebUI besser aufgehoben. Wer PII-Schutz, Entra-ID-Gruppensync und Betriebsrats-kompatibles Logging braucht, findet diese Kombination aktuell nur in very-ai.

Live-Demo: [veryai.de](https://www.veryai.de/)

### Welches Portal für welchen Einsatz?

**Maximale Modellvielfalt und Plugin-Ökosystem:** LobeChat - das größte Plugin-System, die aktivste Community, breite Modellunterstützung. Ideal für Teams, die Flexibilität und schnelle Innovation priorisieren.

**Einfachster Einstieg mit Ollama:** OpenWebUI - native Ollama-Integration, schnelle Installation, intuitive Oberfläche. Ideal für lokales LLM-Hosting und Teams, die mit Open-Source-Modellen starten wollen.

**Maximale Konfigurierbarkeit:** LibreChat - feinste Kontrolle über Modell-Endpunkte und -Parameter. Ideal für technische Teams, die mehrere Anbieter mit unterschiedlichen Konfigurationen betreiben.

**Enterprise-Governance mit PII-Schutz:** very-ai - die einzige Option mit nativer PII-Anonymisierung, Entra-ID-Gruppensync und vollständigem Audit Trail. Ideal für regulierte Umgebungen, in denen Betriebsrat, Datenschutz und Compliance mitentscheiden.

**Evaluierungsprojekt und Entwicklung:** chatbot-ui - saubere Codebasis, guter Ausgangspunkt für Eigenentwicklungen. Beachten Sie: chatbot-ui hat keine aktive Enterprise-Weiterentwicklung; very-ai ist die Enterprise-Weiterentwicklung dieser Codebasis.

*Die meisten Unternehmen evaluieren 2-3 Portale parallel in Docker-Containern - das ist in einem Nachmittag machbar. Entscheidend ist nicht das Interface, sondern die Governance-Fähigkeit: SSO, Audit Trail, PII-Schutz und Betriebsrats-Kompatibilität bestimmen, welches Portal in die Produktion darf.*

## Warum „nur ein Chat" nicht reicht

Der Unterschied zwischen einem Chat-Interface und einem Enterprise-AI-Portal wird im Betrieb deutlich. Ein Vergleich:

| Aspekt | Chat-Interface | Enterprise-AI-Portal |
|---|---|---|
| Nutzung | Individuelle Frage-Antwort | Organisationsweites Werkzeug |
| Wissen | Jeder Nutzer startet bei null | Assistenten bündeln Fachwissen |
| Kontrolle | Der Nutzer entscheidet, was er eingibt | Routing und RBAC steuern den Datenfluss |
| Nachvollziehbarkeit | Keine oder begrenzt | Vollständiger Audit-Trail |
| Integration | Standalone | Angebunden an SSO, Agenten, Dokumentensysteme |
| Skalierung | Pro Nutzer | Pro Organisation |
| Shadow-AI-Risiko | Hoch (unzureichendes internes Angebot) | Gering (besseres internes Angebot) |

Die zentrale Erkenntnis: Shadow AI entsteht nicht, weil Mitarbeitende böswillig sind. Sie entsteht, weil das interne Angebot schlechter ist als die öffentliche Alternative. Wenn das interne Portal genauso intuitiv ist wie ChatGPT, aber zusätzlich spezialisierte Assistenten, Zugriff auf Unternehmensdokumente und Agenten-Workflows bietet, gibt es keinen Grund mehr, auf externe Dienste auszuweichen.

## Praxis: Ein Mittelständler mit 2.000 Mitarbeitenden

Ein konkretes Beispiel zeigt die Wirkung. Ein produzierender Mittelständler mit 2.000 Mitarbeitenden hatte folgende Ausgangslage:

**Vor dem Portal:** Eine interne Umfrage ergab, dass 340 Mitarbeitende regelmäßig öffentliche KI-Dienste für Arbeitsaufgaben nutzten. Davon 180 mit kostenlosen Accounts (ohne AVV), 120 mit privaten Pro-Accounts (Unternehmensdaten in privaten Accounts) und 40 mit vom Unternehmen bereitgestellten Accounts (aber ohne Audit-Trail oder Zugriffskontrolle). Die IT-Abteilung hatte keine Übersicht, welche Daten in welche Systeme flossen.

**Rollout des Enterprise-AI-Portals:** In vier Wochen wurde very-ai ausgerollt - angebunden an Azure AD für SSO, mit drei initialen Assistenten (Rechtsabteilung, HR, Einkauf) und einem gpt-oss-120b-Endpunkt für vertrauliche Daten.

**Nach 90 Tagen:**

- 15 spezialisierte Assistenten, erstellt von Fachabteilungen
- 1.200 aktive Nutzer pro Monat (von 2.000 Mitarbeitenden)
- Shadow-AI-Nutzung um 85 % gesunken (Folge-Umfrage)
- Vollständiger Audit-Trail: 47.000 protokollierte Interaktionen
- Identifikation von drei Prozessen, für die dedizierte Agenten-Workflows sinnvoll waren
- Gesamtkosten (Portal + Hosting + Cloud-APIs): ca. 4.800 € pro Monat

Der entscheidende Faktor war nicht die Technologie, sondern die Adoption. Das Portal wurde angenommen, weil es besser war als die Alternative - nicht weil es vorgeschrieben wurde.

## Die fünf Erfolgsfaktoren beim Rollout

Aus der Praxis lassen sich fünf Faktoren ableiten, die über Erfolg oder Misserfolg eines Enterprise-AI-Portals entscheiden:

**1. Erster Eindruck zählt.** Wenn das interne Portal langsamer, umständlicher oder weniger leistungsfähig ist als ChatGPT, werden Mitarbeitende es nach dem ersten Versuch nicht wieder nutzen. Die Antwortqualität muss vom ersten Tag an auf dem Niveau der öffentlichen Dienste liegen.

**2. Assistenten statt Prompts.** Die meisten Mitarbeitenden sind keine Prompt-Engineers. Sie wollen ein Werkzeug nutzen, nicht konfigurieren. Spezialisierte Assistenten, die von Fachkollegen vorbereitet wurden, senken die Einstiegshürde erheblich.

**3. Sichtbarer Mehrwert.** Das Portal muss etwas bieten, was die öffentlichen Dienste nicht können: Zugriff auf interne Dokumente (via RAG), spezialisierte Assistenten für unternehmensspezifische Aufgaben, Integration in bestehende Workflows.

**4. IT-Ownership, nicht IT-Kontrolle.** Die IT-Abteilung betreibt das Portal und setzt die Governance-Regeln. Aber die Fachabteilungen erstellen ihre Assistenten selbst. Diese Verteilung - Infrastruktur zentral, Inhalte dezentral - hat sich als erfolgreichstes Modell erwiesen.

**5. Messen und kommunizieren.** Nutzungszahlen, eingesparte Zeit, reduzierte Shadow-AI-Nutzung - diese Kennzahlen müssen erhoben und an die Geschäftsführung kommuniziert werden. Ohne messbare Ergebnisse fehlt die Grundlage für die nächste Ausbaustufe.

## Nächster Schritt: Vom Portal zum Agenten

Das Enterprise-AI-Portal ist die Grundlage. Es gibt Mitarbeitenden Zugang zu KI, kontrolliert und protokolliert. Der nächste Schritt ist die Integration von Agenten - spezialisierten Workflows, die über einfache Frage-Antwort-Interaktionen hinausgehen. Wie Sie [Agenten im Enterprise-Kontext](/de/magazin/ai-agenten-enterprise-leitfaden/) einsetzen, welche Architektur dafür nötig ist und wo die Grenzen liegen, behandelt ein weiterer Artikel dieser Serie.

---

Weiterführend: [KI-Infrastruktur](/de/leistungen/infrastruktur/) | [Decision Layer & Shadow AI](/de/magazin/decision-layer-shadow-ai/)

---

**📘 Enterprise AI-Infrastruktur Blueprint 2026 - Artikel-Serie**

| ← Vorheriger | Übersicht | Nächster → |
|:---|:---:|---:|
| [KI-Hosting: EU-SaaS, deutsches RZ oder Self-Hosted?](/de/magazin/ki-hosting-strategien-enterprise/) | [Zur Übersicht](/de/magazin/ai-infrastruktur-blueprint-2026/) | [RAG & Document Intelligence: Wie KI Ihre Dokumente versteht](/de/magazin/rag-document-intelligence-enterprise/) |

*Alle Artikel dieser Serie: [Enterprise AI-Infrastruktur Blueprint 2026](/de/magazin/ai-infrastruktur-blueprint-2026/)*

---

very-ai ist Gosigns Open-Source Enterprise-AI-Portal. [Mehr erfahren](/de/leistungen/infrastruktur/) - oder direkt mit uns sprechen, welche Konfiguration für Ihre Organisation passt.

<a href="/de/kontakt/" target="_blank" rel="noopener noreferrer">Termin vereinbaren</a> - Wir zeigen Ihnen very-ai in einer Live-Demo und besprechen Ihren Rollout-Plan.

--- Entscheidungsakt: Warum jede KI-Entscheidung anfechtbar sein muss ---
> Art. 86 EU AI Act: Recht auf Erläuterung der Einzelentscheidung. Chat-Logs und Model Cards erfüllen es nicht. Der Entscheidungsakt schon.

Ein Bewerber wird abgelehnt. Eine Sonderzahlung wird verweigert. Eine Eingruppierung fällt niedriger aus als erwartet. In allen drei Fällen war ein KI-Agent beteiligt - und in allen drei Fällen kann der Betroffene künftig einen Satz sagen, der bisher Anwälten vorbehalten war: "Erläutern Sie mir die Rolle des KI-Systems und die wichtigsten Elemente dieser Entscheidung."

Das ist kein hypothetisches Szenario. Es ist der Wortlaut-Kern von Artikel 86 der [KI-Verordnung (EU) 2024/1689](https://artificialintelligenceact.eu/article/86/) - dem am meisten unterschätzten Artikel des EU AI Act. Die Branche diskutiert über Modell-Dokumentation, Risikoklassen und Fristen. Artikel 86 stellt eine andere Frage: Können Sie eine einzelne, konkrete Entscheidung erklären? Nicht Ihr System. Diese eine Entscheidung.

Die meisten Unternehmen können es nicht. Nicht, weil ihre KI schlecht wäre - sondern weil ihre Architektur die falsche Einheit dokumentiert. Sie protokollieren Konversationen, Token und Systemverhalten. Anfechtbar ist aber nur, was als Entscheidung festgehalten wurde. Dieser Artikel beschreibt das fehlende Artefakt: den Entscheidungsakt.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Auf einen Blick - Der Entscheidungsakt</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Anfechtbar ist nur, was als Entscheidung festgehalten wurde. Der Entscheidungsakt ist der atomare, unveränderliche Nachweis einer einzelnen Mikroentscheidung: Input, angewandte Fachregel samt Version und Quelle, Ergebnis, Konfidenz, Modellversion, Zeitstempel, Anfechtungspfad. Logs beantworten "Was geschah?" - der Entscheidungsakt beantwortet "Warum wurde so entschieden?".</li>
<li>Art. 86 EU AI Act gibt Betroffenen ein Recht auf Erläuterung der einzelnen Entscheidung - und der EuGH verlangt dieselbe Einzelfall-Begründung schon heute unter der DSGVO. Eine Systembeschreibung genügt nicht.</li>
<li>Chat-Logs, Observability-Traces und Model Cards dokumentieren Interaktion, Infrastruktur und System - aber nicht die fachliche Begründung. Microsofts eigene Dokumentation bestätigt: Das Copilot-Audit-Log erfasst weder Prompt-Inhalte noch die Modellversion. Und Reasoning-Texte von Sprachmodellen geben laut Anthropic-Forschung nur in einem Viertel der Fälle die tatsächliche Entscheidungsgrundlage wieder.</li>
<li>Ein KI-Agent trifft nie "eine Entscheidung" - er trifft Dutzende Mikroentscheidungen pro Vorgang. Jede einzelne kann rechtlich relevant sein: Der EuGH wertet schon den automatisierten Score als Entscheidung, nicht erst das Endergebnis.</li>
<li>Anfechtbarkeit lässt sich nicht nachrüsten: Eine Entscheidung, die nie als Entscheidung modelliert wurde, kann nachträglich nicht begründet werden. Deshalb ist der Entscheidungsakt ein Architekturprinzip des Decision Layer - keine Compliance-Funktion.</li>
</ul>
</div>

## Agentische KI heißt: Entscheidungsrechte übertragen

Die Zahlen der großen Beratungshäuser erzählen 2026 eine konsistente Geschichte. [McKinsey](https://www.mckinsey.com/capabilities/quantumblack/our-insights/seizing-the-agentic-ai-advantage) nennt es das Gen-AI-Paradox: Fast acht von zehn Unternehmen setzen generative KI ein, ein fast ebenso großer Anteil sieht keinen messbaren Ergebniseffekt - weil horizontale Assistenten breit ausgerollt werden, die wertschöpfenden vertikalen Anwendungsfälle aber im Pilotstatus stecken bleiben. [Gartner](https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027) prognostiziert, dass über 40 Prozent der Agentic-AI-Projekte bis Ende 2027 abgebrochen werden - ausdrücklich auch wegen unzureichender Risikokontrollen. Dieselbe Prognose erwartet, dass bis 2028 mindestens 15 Prozent der täglichen Arbeitsentscheidungen autonom von KI-Agenten getroffen werden.

Beide Aussagen zusammen ergeben das eigentliche Spannungsfeld: Unternehmen übertragen Entscheidungsrechte an Maschinen, ohne die Infrastruktur zu besitzen, diese Entscheidungen zu verantworten. McKinsey rahmt die agentische Ära in seiner Trust-Studie 2026 genau so - die Leitfrage verschiebe sich von "Ist das Modell genau?" zu "Wer haftet, wenn das System handelt?" ([State of AI trust in 2026](https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/tech-forward/state-of-ai-trust-in-2026-shifting-to-the-agentic-era)).

Die Governance-Lücke ist über alle Quellen hinweg quantifiziert:

| Befund | Zahl | Quelle |
|---|---|---|
| Agentic-AI-Projekte, die bis Ende 2027 abgebrochen werden - u.a. wegen unzureichender Risikokontrollen | über 40% | [Gartner, 2025](https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027) |
| Unternehmen mit reifer Governance für autonome Agenten | nur 21% | [Deloitte, 2025](https://www.deloitte.com/us/en/insights/topics/emerging-technologies/ai-agents-scaling-faster.html) |
| Technologie-Führungskräfte, deren KI-Adoption die eigene Governance-Fähigkeit bereits überholt | 77% | [IBM IBV, 2026](https://www.cio.com/article/4182288/cios-are-being-held-accountable-for-ai-they-dont-fully-control-ibm-study-finds.html) |
| CIOs/CTOs, die für KI-Systeme verantwortlich gemacht werden, die sie nicht vollständig kontrollieren | rund zwei Drittel | [IBM IBV, 2026](https://www.cio.com/article/4182288/cios-are-being-held-accountable-for-ai-they-dont-fully-control-ibm-study-finds.html) |
| Gemeldete KI-Vorfälle 2024 - Rekordhoch, +56,4% gegenüber Vorjahr | 233 | [Stanford HAI AI Index, 2025](https://hai.stanford.edu/ai-index/2025-ai-index-report/responsible-ai) |
| Weniger KI-Vorfälle bei Governance, die direkt ins System eingebettet ist, statt manueller Aufsicht | 25% | [IBM IBV, 2026](https://www.ibm.com/thought-leadership/institute-business-value/en-us/report/ai-governance-trends) |

Die letzte Zeile ist die wichtigste: Eingebettete Governance wirkt messbar besser als nachgelagerte Kontrolle. Genau an dieser Stelle wird die Frage konkret, was "eingebettet" technisch bedeutet. Und sie stellt sich am schärfsten in HR: Wer Entscheidungsrechte an Agenten überträgt, verschiebt sein Operating Model - und jede dieser Entscheidungen trifft eine konkrete Person, ihre Krankmeldung, ihre Vergütung, ihre Einstufung. Die Antwort beginnt beim Gesetz.

## Was Artikel 86 verlangt - und warum Systemdokumentation es nicht erfüllt

Der EU AI Act kennt zwei grundverschiedene Transparenz-Ebenen, die in der Compliance-Diskussion ständig vermischt werden:

| Ebene | Rechtsgrundlage | Adressat | Zeitpunkt | Beantwortet die Frage |
|---|---|---|---|---|
| Systemtransparenz | Art. 11 (technische Dokumentation), Art. 13 (Betriebsanleitung für Betreiber) | Behörde, Betreiber | vor Inbetriebnahme | "Wie funktioniert das System im Allgemeinen?" |
| Einzelfall-Erläuterung | Art. 86 AI Act, Art. 15 Abs. 1 lit. h und Art. 22 DSGVO | die betroffene Person | nach der Entscheidung | "Warum fiel diese eine Entscheidung so aus?" |

[Artikel 86](https://artificialintelligenceact.eu/article/86/) gibt jeder Person, die einer Entscheidung auf Basis eines Hochrisiko-KI-Systems nach Anhang III unterliegt und dadurch rechtlich oder ähnlich erheblich betroffen ist, einen Anspruch gegen den Betreiber: auf klare und aussagekräftige Erläuterungen zur Rolle des KI-Systems im Entscheidungsverfahren und zu den wichtigsten Elementen der getroffenen Entscheidung. Das ist fallbezogen formuliert, nicht systembezogen. Eine Model Card beschreibt das Modell. Artikel 86 fragt nach dem Fall.

Der Europäische Gerichtshof hat dasselbe Prinzip für die DSGVO bereits ausbuchstabiert - in zwei Urteilen, die jeder kennen sollte, der KI-Entscheidungen verantwortet:

**[SCHUFA, C-634/21](https://eur-lex.europa.eu/legal-content/DE/TXT/PDF/?uri=CELEX:62021CJ0634) (Dezember 2023):** Schon die automatisierte Erstellung eines Score-Werts ist eine automatisierte Entscheidung im Einzelfall im Sinne von Art. 22 DSGVO, sobald ein Dritter ihr maßgebliche Bedeutung beimisst. Die Konsequenz reicht weit über Bonitäts-Scoring hinaus: Die Nachvollziehbarkeits-Pflicht greift an der maschinellen Bewertung selbst - nicht erst an der nachgelagerten Endentscheidung, die ein Mensch unterschreibt.

**[Dun & Bradstreet Austria, C-203/22](https://www.dpcuria.eu/case?reference=C-203%2F22) (Februar 2025):** Der Verantwortliche muss das tatsächlich angewandte Verfahren so erläutern, dass die betroffene Person nachvollziehen kann, welche ihrer Daten auf welche Weise in die Entscheidung eingeflossen sind. Eine kontrafaktische Erklärung kann genügen - etwa: Bei welcher Abweichung der Eingangsdaten wäre das Ergebnis anders ausgefallen? Und: Geschäftsgeheimnisse rechtfertigen keine pauschale Verweigerung; im Konfliktfall sind die Informationen der zuständigen Behörde oder dem Gericht offenzulegen, die dann abwägen.

Eine kontrafaktische Erklärung pro Einzelfall setzt voraus, dass die tatsächlich verwendeten Eingangsdaten und die angewandte Regel pro Entscheidung strukturiert vorliegen. Aus einer globalen Systembeschreibung lässt sie sich nicht rekonstruieren.

Dazu kommt eine Pointe, die in der Compliance-Diskussion regelmäßig untergeht: [Art. 12](https://artificialintelligenceact.eu/article/12/) verpflichtet Hochrisiko-Systeme zur automatischen Protokollierung über die gesamte Lebensdauer, und [Art. 26 Abs. 6](https://artificialintelligenceact.eu/article/26/) verpflichtet Betreiber, diese Protokolle mindestens sechs Monate aufzubewahren. Welche Inhalte die Protokolle tragen müssen, definiert das Gesetz aber nur für biometrische Systeme. Für HR- und Finance-Systeme schreibt der AI Act die Protokollierungs-Fähigkeit vor - und lässt das Inhalts-Schema offen. Was pro Entscheidung festgehalten wird, ist eine Designaufgabe des Betreibers. Wer hier nur Token-Verbrauch und Zeitstempel loggt, erfüllt den Buchstaben von Art. 12 und scheitert an Art. 86.

Zur Einordnung der Fristen: Nach geltendem Recht greifen die Hochrisiko-Pflichten ab dem 2. August 2026; die im Digital Omnibus am 7. Mai 2026 vorläufig geeinigte Verschiebung auf den 2. Dezember 2027 ist noch nicht formal verabschiedet. An der Hochrisiko-Einstufung von HR-Prozessen ([Anhang III Nr. 4](https://artificialintelligenceact.eu/annex/3/)) ändert sie nichts - und an der zivilrechtlichen Erklärbarkeits-Pflicht, die [weltweit längst gilt](/de/magazin/eu-ai-act-gilt-weltweit/), auch nicht. Die Details zu Fristen und Pflichten behandelt [EU AI Act 2026: Status, Fristen, Handlungsbedarf](/de/magazin/eu-ai-act-2026-unternehmen/).

## Eine "KI-Entscheidung" gibt es nicht - es gibt Dutzende Mikroentscheidungen

Wer Artikel 86 operativ ernst nimmt, stößt sofort auf ein Granularitätsproblem: Was genau ist "die Entscheidung"?

<div class="not-prose my-10 grid grid-cols-1 md:grid-cols-2 gap-4">
  <div class="border border-base rounded-soft overflow-hidden bg-surface-dim opacity-90">
    <div class="px-4 py-2.5 border-b border-base font-code text-xs uppercase tracking-wider text-muted">EINE &#8222;KI-ENTSCHEIDUNG&#8220;</div>
    <div class="p-5">
      <div class="font-code text-xs text-muted mb-3">input: Antrag MA-4711</div>
      <div class="flex items-center justify-center h-20 rounded bg-[#2e2e3e] border border-[#555]">
        <span class="font-display text-3xl text-white/40">?</span>
      </div>
      <div class="mt-3 font-code text-xs text-primary">Ergebnis: abgelehnt</div>
      <div class="mt-4 pt-3 border-t border-base font-code text-xs text-muted">1 Ergebnis &#183; 0 Begr&#252;ndungen &#183; nicht anfechtbar <span aria-hidden="true">&#10007;</span></div>
    </div>
  </div>
  <div class="border-2 rounded-soft overflow-hidden bg-surface-raised" style="border-color: var(--accent-primary);">
    <div class="px-4 py-2.5 border-b border-base font-code text-xs uppercase tracking-wider text-accent">13 MIKROENTSCHEIDUNGEN</div>
    <div class="p-5">
      <div class="font-code text-xs text-muted mb-3">input: Antrag MA-4711</div>
      <div class="flex flex-wrap gap-1.5">
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #0369A1;">01</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #0369A1;">02</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #0369A1;">03</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #0369A1;">04</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #0369A1;">05</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #0369A1;">06</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #0369A1;">07</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #0369A1;">08</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #6D4ED8;">09</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #0369A1;">10</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #0369A1;">11</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #B45309;">12</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #B45309;">13</span>
      </div>
      <div class="mt-3 flex flex-wrap gap-3 font-code text-[11px] text-muted">
        <span><span class="inline-block w-2.5 h-2.5 rounded-full align-middle mr-1" style="background:#0369A1;"></span>Regel (10)</span>
        <span><span class="inline-block w-2.5 h-2.5 rounded-full align-middle mr-1" style="background:#6D4ED8;"></span>KI (1)</span>
        <span><span class="inline-block w-2.5 h-2.5 rounded-full align-middle mr-1" style="background:#B45309;"></span>Mensch (2)</span>
      </div>
      <div class="mt-4 pt-3 border-t border-base font-code text-xs text-primary">13 Akte &#183; 13 Begr&#252;ndungen &#183; einzeln anfechtbar <span class="text-accent" aria-hidden="true">&#10003;</span></div>
    </div>
  </div>
</div>

Diese Zerlegung ist nicht an eine Jurisdiktion gebunden. Eine Kreditentscheidung zerfällt nach derselben Mechanik: Identitätsprüfung (Regelwerk), Einkommens-Extraktion aus Belegen (KI, mit Konfidenz), Score-Berechnung (Regelwerk, versioniert), Schwellen-Routing (Regelwerk), Grenzfall-Votum (Mensch). Welches Recht die einzelne Mikroentscheidung bindet - DSGVO Art. 22, UK GDPR, LGPD Art. 20 oder der US-amerikanische Equal Credit Opportunity Act - hängt am Markt. Die Zerlegung selbst ist überall dieselbe. Wie tief sie in einem regulierten Prozess reicht, zeigt das Beispiel, das europäische Personalabteilungen täglich beschäftigt:

Eine Krankmeldung verarbeiten - das klingt nach einem Vorgang. Tatsächlich stecken darin über ein Dutzend einzelner Entscheidungen: Ist die elektronische AU nach §109 SGB IV korrekt abgerufen? Greift die Lohnfortzahlung nach §3 EFZG - und in welcher Höhe nach §4? Liegt eine Wiederholungserkrankung mit Anrechnung nach §3 Abs. 1 Satz 2 EFZG vor? Ist die Sechs-Wochen-Schwelle für die BEM-Einladung nach §167 SGB IX erreicht? Muss die Schwerbehindertenvertretung nach §178 SGB IX beteiligt werden? Wer wird worüber informiert - und worüber ausdrücklich nicht?

Der [Decision Layer](/de/decision-layer/) zerlegt jeden Geschäftsprozess in genau diese Mikroentscheidungen und ordnet jede einzelne vorab einem von [drei Entscheider-Typen](/de/magazin/drei-arten-von-entscheidungen/) zu - Mensch, Regelwerk oder KI:

| Mikroentscheidung (Krankmeldung) | Entscheider | Warum |
|---|---|---|
| eAU-Abruf nach §109 SGB IV inkl. Sperrfrist | Regelwerk | deterministisch, kein Interpretationsspielraum |
| Lohnfortzahlung nach §3, §4 EFZG berechnen | Regelwerk | feste Frist- und Betragsrechnung |
| Anrechnung bei Wiederholungserkrankung prüfen | Regelwerk | deterministische 12-Monats-Regel |
| BEM-Einladung ab sechs Wochen nach §167 SGB IX auslösen | Regelwerk | gesetzliche Pflicht-Schwelle |
| Auffällige Krankheitsmuster statistisch markieren | KI (Indikator) | Anomalie-Erkennung, Ergebnis ist Prüfhinweis, keine Personalentscheidung |
| BEM-Gespräch führen | Mensch | Vertrauensbeziehung, §167-Verfahren |
| Krankheitsbedingte Kündigung | Mensch | KSchG §1-Stufenprüfung, Beweislast-Umkehr nach AGG §22 |

Diese Zerlegung ist keine akademische Übung - sie ist die Voraussetzung für Anfechtbarkeit. Denn die SCHUFA-Logik des EuGH gilt auf jeder Stufe: Wenn schon ein automatisierter Score eine Entscheidung im Rechtssinn ist, dann ist auch die maschinelle Fristprüfung, die maschinelle Klassifikation eines Dokuments, die maschinelle Eingruppierungs-Empfehlung jeweils ein potenziell anfechtbarer Akt - nicht erst das Endergebnis. Ein Unternehmen, das nur das Endergebnis dokumentiert, kann auf die Frage "Warum wurde mein Antrag abgelehnt?" nur antworten: "Der Prozess hat das ergeben." Das ist exakt die Blackbox-Antwort, die kein Arbeitsgericht akzeptiert.

Wie tief diese Zerlegung in der Praxis geht, zeigt der [HR-Agent-Katalog](/de/hr-agent-katalog/): 48 Agenten, jeder mit vollständiger Mikroentscheidungs-Tabelle - pro Schritt Entscheider-Typ, Begründung, Rechtsgrundlage und Anfechtungsweg.

## Warum Logs, Traces und Model Cards die Frage nicht beantworten

Die Industrie hat auf den Dokumentations-Bedarf geantwortet - aber auf drei Ebenen, die alle an der Einzelentscheidung vorbeigehen:

| Ebene | Werkzeuge | Dokumentiert | Beantwortet NICHT |
|---|---|---|---|
| Interaktion | Chat-Logs, Conversation History, Copilot-Audit-Events | wer wann mit dem System sprach, welche Ressourcen berührt wurden | welche fachliche Regel die Entscheidung trug |
| Infrastruktur | LLM-Observability (Traces, Spans), OpenTelemetry GenAI | Prompts, Tool-Aufrufe, Token, Latenzen entlang der Ausführung | warum das Ergebnis fachlich so ausfiel - und ob es korrekt ist |
| System | Model Cards, technische Dokumentation, Governance-Plattformen (Model-Inventory, Risk-Register) | wie das Modell generell funktioniert, welche Risiken das System hat | irgendeinen konkreten Einzelfall |

Das ist keine polemische Zuspitzung, sondern steht so in den Hersteller-Dokumentationen. [Microsofts Purview-Dokumentation](https://learn.microsoft.com/en-us/purview/audit-copilot) hält für das Copilot-Audit-Log fest, dass es die tatsächlichen Prompts und Antworten nicht aufzeichnet und Modellname wie Modellversion in Microsoft-365-Copilot-Szenarien nicht verfügbar sind. Im Salesforce-Ökosystem wird die Lücke selbst benannt: Klassische Audit-Trails seien für Menschen gebaut, die Buttons klicken - man sehe, dass sich etwas geändert hat, [aber nicht warum](https://www.sweep.io/blog/the-audit-trail-of-an-ai-agent). Und Governance-Plattformen wie IBM watsonx.governance oder Credo AI beantworten die Frage "Ist dieses System inventarisiert, risikobewertet und richtlinienkonform?" - eine wichtige Frage, aber eine andere als "Worauf beruhte die Eingruppierung von Frau M. am 14. Mai um 10:42 Uhr?".

Bleibt der scheinbar naheliegendste Ausweg: das Modell einfach selbst begründen lassen. Reasoning-Modelle erzeugen Begründungsketten - warum nicht die als Nachweis archivieren? Weil sie nachweislich nicht zuverlässig wiedergeben, worauf die Entscheidung tatsächlich beruhte. [Anthropics Forschung](https://www.anthropic.com/research/reasoning-models-dont-say-think) zu Chain-of-Thought-Treue zeigt: Selbst unter günstigen Bedingungen verbalisieren Reasoning-Modelle die tatsächlich genutzten Entscheidungshinweise nur in rund einem Viertel der Fälle - relevante Einflussfaktoren bleiben auch dann verborgen, wenn man die komplette Begründungskette liest. Eine generierte Begründung ist ein Text über die Entscheidung. Sie ist nicht die Entscheidungsgrundlage.

Die Forschung zur Anfechtbarkeit zieht daraus den entscheidenden Schluss: Erklärbarkeit und Anfechtbarkeit sind zwei Mittel zum selben Ziel - und Erklärung allein, ohne Anfechtungsweg, verfehlt es ([Schmude et al., 2025](https://arxiv.org/abs/2504.18236)). Anfechtbarkeit rechnet damit, dass eine Entscheidung falsch sein kann, und verlangt die Beweismittel, sie zu kippen. Post-hoc-Erklärverfahren zeigen bestenfalls, dass irgendwo in der Nachbarschaft einer Entscheidung Fehler liegen können; den Nachweis, dass diese eine Entscheidung fehlerhaft war, liefern sie nicht. Und [Moreira et al. (2025)](https://arxiv.org/html/2506.01662v1) verschieben den Maßstab von bloßem Verstehen zu Handlungsfähigkeit: Eine Erklärung muss Betroffene und Prüfer in die Lage versetzen, ein Ergebnis aktiv anzufechten, zu hinterfragen und zu beeinflussen - nicht nur nachzuvollziehen, warum so entschieden wurde.

Mit einem Token-Trace kann das niemand. Mit einem Entscheidungsakt schon.

## Der Entscheidungsakt: das Beweisstück pro Entscheidung

Der Entscheidungsakt ist der atomare, unveränderliche, strukturierte Nachweis einer einzelnen fachlichen Mikroentscheidung. Er entsteht im Moment der Entscheidung - nicht als nachträgliche Rekonstruktion - und enthält alles, was Art. 86, Art. 12 und die EuGH-Rechtsprechung pro Einzelfall verlangen:

| Feld | Inhalt | Wozu es rechtlich dient |
|---|---|---|
| Input | welche Daten, welches Dokument, welcher Hash | C-203/22: "welche Daten flossen auf welche Weise ein" |
| Fachregel + Version + Quelle | z.B. Tarifvertrag §12 Abs. 3, Version 2024-Q3, gültig seit 01.07.2024 | die tragende Begründung - das Feld, das Logs und Traces nicht haben |
| Entscheider-Typ | Mensch, Regelwerk oder KI - mit Routing-Begründung | Art. 14: Nachweis wirksamer menschlicher Aufsicht |
| Konfidenz | Konfidenzwert und Schwellenwert zum Entscheidungszeitpunkt | Beleg des Risikomanagements (Art. 9), Eskalations-Nachvollzug |
| Modell- und Prompt-Version | welches Sprachmodell, welche Prompt-Vorlage, welche Version | Reproduzierbarkeit; das Feld, das im Copilot-Audit-Log fehlt |
| Ergebnis + Zeitstempel | was entschieden wurde, wann (UTC) | Aufbewahrung nach Art. 26 Abs. 6, GoBD-Festschreibung |
| Human-in-the-Loop-Vermerk | wer geprüft hat, ob er bestätigt oder abgewichen ist | Art. 14 Abs. 4: übersteuern, widerrufen, stoppen - dokumentiert |
| Anfechtungspfad | wer diese Entscheidung anfechten kann und wo | Art. 86-Anspruch operativ erfüllbar gemacht |

So sieht das in der Akte eines realen Vorgangs aus - vier von 13 Mikroentscheidungen einer Krankmeldungs-Verarbeitung:

<div class="not-prose my-10 bg-surface-raised border border-base rounded-soft overflow-hidden shadow-sm">
  <div class="px-5 py-4 border-b border-base bg-surface-dim">
    <div class="flex items-center gap-3 mb-2">
      <div class="flex gap-1.5" aria-hidden="true">
        <span class="w-2.5 h-2.5 rounded-full bg-[#FF5F56]"></span>
        <span class="w-2.5 h-2.5 rounded-full bg-[#FFBD2E]"></span>
        <span class="w-2.5 h-2.5 rounded-full bg-[#27C93F]"></span>
      </div>
      <span class="font-code text-xs text-muted">decision-record / krankmeldung / 2026-05-14 / EMP_0x52a8</span>
    </div>
    <p class="text-small text-primary">Eingang eAU 14.05.2026, 07:12 Uhr. Vorgang verarbeitet in 54 Sekunden - zerlegt in 13 dokumentierte Mikroentscheidungen.</p>
    <div class="mt-3 flex h-7 rounded overflow-hidden text-xs font-bold text-white" aria-label="Entscheider-Verteilung: 10 Regelwerk, 1 KI, 2 Mensch">
      <div class="flex items-center justify-center" style="width: 77%; background: #0369A1;">10 Regel</div>
      <div class="flex items-center justify-center" style="width: 8%; background: #6D4ED8;">1</div>
      <div class="flex items-center justify-center" style="width: 15%; background: #B45309;">2 Mensch</div>
    </div>
  </div>
  <ol class="divide-y divide-base">
    <li class="p-5">
      <div class="flex items-start gap-4">
        <div class="flex-shrink-0 w-9 h-9 rounded-full flex items-center justify-center font-code text-xs font-bold border" style="background: rgba(3,105,161,0.08); border-color: rgba(3,105,161,0.3); color: #0369A1;">02</div>
        <div class="flex-1 min-w-0">
          <div class="flex flex-wrap items-center gap-2 mb-1.5">
            <span class="text-body font-semibold text-primary">Lohnfortzahlung nach §3, §4 EFZG berechnen</span>
            <span class="inline-flex px-2 py-0.5 text-xs font-bold uppercase tracking-wider rounded text-white" style="background: #0369A1;">Regel</span>
          </div>
          <p class="text-small text-primary font-medium mb-2">6 Wochen ab 14.05.2026, 100 % Brutto</p>
          <div class="px-3 py-2 bg-surface border border-base rounded font-code text-xs text-primary/80"><span class="text-muted">input:</span> eAU-Zeitraum 14.05.-27.05. · Stammdaten EMP_0x52a8</div>
          <div class="mt-2 font-code text-xs text-muted"><span>rule:</span> <span class="text-primary">EFZG-§3+§4 · v2026-01</span></div>
        </div>
      </div>
    </li>
    <li class="p-5">
      <div class="flex items-start gap-4">
        <div class="flex-shrink-0 w-9 h-9 rounded-full flex items-center justify-center font-code text-xs font-bold border" style="background: rgba(3,105,161,0.08); border-color: rgba(3,105,161,0.3); color: #0369A1;">06</div>
        <div class="flex-1 min-w-0">
          <div class="flex flex-wrap items-center gap-2 mb-1.5">
            <span class="text-body font-semibold text-primary">BEM-Schwelle prüfen (§167 SGB IX)</span>
            <span class="inline-flex px-2 py-0.5 text-xs font-bold uppercase tracking-wider rounded text-white" style="background: #0369A1;">Regel</span>
          </div>
          <p class="text-small text-primary font-medium mb-2">42 AU-Tage in 12 Monaten erreicht - BEM-Einladung ausgelöst</p>
          <div class="px-3 py-2 bg-surface border border-base rounded font-code text-xs text-primary/80"><span class="text-muted">input:</span> AU-Historie 12 Monate (3 Zeiträume)</div>
          <div class="mt-2 font-code text-xs text-muted"><span>rule:</span> <span class="text-primary">SGB-IX-§167 · v2025-07</span></div>
        </div>
      </div>
    </li>
    <li class="p-5">
      <div class="flex items-start gap-4">
        <div class="flex-shrink-0 w-9 h-9 rounded-full flex items-center justify-center font-code text-xs font-bold border" style="background: rgba(109,78,216,0.08); border-color: rgba(109,78,216,0.3); color: #6D4ED8;">09</div>
        <div class="flex-1 min-w-0">
          <div class="flex flex-wrap items-center gap-2 mb-1.5">
            <span class="text-body font-semibold text-primary">Abwesenheits-Muster markieren</span>
            <span class="inline-flex items-center gap-1 px-2 py-0.5 text-xs font-bold uppercase tracking-wider rounded text-white" style="background: #6D4ED8;">KI <span class="font-mono opacity-90">91%</span></span>
          </div>
          <p class="text-small text-primary font-medium mb-2">Hinweis an HR-Operations: dritte Kurzzeit-AU in sechs Monaten</p>
          <div class="px-3 py-2 bg-surface border border-base rounded font-code text-xs text-primary/80"><span class="text-muted">input:</span> anonymisierte AU-Metadaten - ohne Diagnose (DSGVO Art. 9)</div>
          <div class="mt-2 font-code text-xs text-muted"><span>model-reason:</span> <span class="text-primary">Muster-Abgleich Kurzzeit-Folge-AU · Indikator, keine Personalentscheidung</span></div>
          <div class="mt-3"><span class="inline-flex items-center px-3 py-1.5 text-xs font-semibold rounded border-2" style="border-color: #6D4ED8; color: #6D4ED8; background: rgba(109,78,216,0.08);">formal anfechtbar · Art. 14 EU AI Act</span></div>
        </div>
      </div>
    </li>
    <li class="p-5">
      <div class="flex items-start gap-4">
        <div class="flex-shrink-0 w-9 h-9 rounded-full flex items-center justify-center font-code text-xs font-bold border" style="background: rgba(180,83,9,0.08); border-color: rgba(180,83,9,0.3); color: #B45309;">13</div>
        <div class="flex-1 min-w-0">
          <div class="flex flex-wrap items-center gap-2 mb-1.5">
            <span class="text-body font-semibold text-primary">BEM-Gespräch führen</span>
            <span class="inline-flex px-2 py-0.5 text-xs font-bold uppercase tracking-wider rounded text-white" style="background: #B45309;">Mensch</span>
          </div>
          <p class="text-small text-primary font-medium mb-2">Wiedereingliederungsplan vereinbart</p>
          <div class="mt-2 font-code text-xs text-muted"><span>decided-by:</span> <span class="text-primary">BEM-Beauftragte</span> <span class="text-muted">- 17.05.2026, 14:10</span></div>
        </div>
      </div>
    </li>
  </ol>
</div>

Die deutsche Sprache hält für dieses Artefakt eine präzise Analogie bereit: den Verwaltungsakt. Eine Behörde, die über einen Bürger entscheidet, erlässt keinen "Output" - sie erlässt einen Akt: einzeln adressiert, begründet, mit Rechtsgrundlage und Rechtsbehelfsbelehrung, einzeln anfechtbar. Niemand würde akzeptieren, dass ein Amt auf Widerspruch antwortet: "Wir haben leider nur das Server-Log." Genau diese Form-Anforderung überträgt der Entscheidungsakt auf maschinelle Entscheidungen. Ein Trail ist eine Spur, die man hinterlässt. Ein Akt ist ein Dokument, das man erlässt - und gegen das Widerspruch möglich ist.

Dieselbe Logik kennt das Rechnungswesen seit Jahrhunderten: Kein Wirtschaftsprüfer akzeptiert eine Summe ohne Buchungssätze und Belege. Die GoBD verlangen Einzelaufzeichnung, Unveränderbarkeit und Nachvollziehbarkeit pro Geschäftsvorfall - mit Aufbewahrungsfristen von sechs bzw. zehn Jahren nach §147 AO und §257 HGB, weit über die sechs Monate des Art. 26 Abs. 6 hinaus. Der Entscheidungsakt ist nichts anderes als die doppelte Buchführung für Entscheidungen: ein Beleg pro Geschäftsvorfall, ein Akt pro Entscheidung.

Dass für diese Einheit noch kein Standard-Begriff existiert, zeigt der Markt selbst: Es kursieren "Decision Trail", "Decision Provenance", "Decision Trace", "Accountability Record" - [TechTarget](https://www.techtarget.com/searcherp/feature/AI-decision-trails-are-the-new-audit-trail) erklärt KI-Entscheidungspfade zum neuen Audit-Trail, das [FINOS AI Governance Framework](https://air-governance-framework.finos.org/mitigations/mi-21_agent-decision-audit-and-explainability.html) fordert "Agent Decision Audit and Explainability". Die Anforderung ist im Diskurs angekommen. Das Artefakt hat noch keinen Namen. Wir nennen es seit Anbeginn des Decision Layer: Entscheidungsakt.

Wo der Akt in der Architektur entsteht, zeigt der Blick auf die sieben Schichten eines produktiven Agenten-Stacks - der Entscheidungsakt ist das Artefakt der Schicht 04:

<div class="not-prose my-10 border-y border-base">
  <ol class="divide-y divide-base">
    <li class="grid grid-cols-[3rem_1fr] gap-4 items-start py-4">
      <span class="font-display text-h2 leading-none text-muted">01</span>
      <div><span class="text-body font-semibold text-primary">Presentation Layer</span><p class="mt-1 text-small text-primary/80">User-Interfaces, Prompt-Gateways, Access-Portale für Fachbereiche und Betriebsrat.</p></div>
    </li>
    <li class="grid grid-cols-[3rem_1fr] gap-4 items-start py-4">
      <span class="font-display text-h2 leading-none text-muted">02</span>
      <div><span class="text-body font-semibold text-primary">Orchestration Layer</span><p class="mt-1 text-small text-primary/80">Multi-Agent-Koordination, Event-Routing, State-Management über Prozess-Grenzen hinweg.</p></div>
    </li>
    <li class="grid grid-cols-[3rem_1fr] gap-4 items-start py-4 bg-[color:var(--accent-primary)]/5">
      <span class="font-display text-h2 leading-none text-accent">03</span>
      <div><span class="text-body font-semibold text-primary">Agent Layer <span class="ml-2 font-code text-xs uppercase tracking-wider text-accent">Gosign-Kern</span></span><p class="mt-1 text-small text-primary/80">Document-, Workflow- und Knowledge-Agents - die ausführende Schicht mit KI-Urteilsvermögen.</p></div>
    </li>
    <li class="grid grid-cols-[3rem_1fr] gap-4 items-start py-4 bg-[color:var(--accent-primary)]/5">
      <span class="font-display text-h2 leading-none text-accent">04</span>
      <div><span class="text-body font-semibold text-primary">Decision Layer <span class="ml-2 font-code text-xs uppercase tracking-wider text-accent">Gosign-Kern</span></span><p class="mt-1 text-small text-primary/80">Hier entsteht der Entscheidungsakt: ein Akt pro Mikroentscheidung, versionierte Regelwerke, Human-in-the-Loop-Routing bei Ermessen, Anfechtbarkeit nach Art. 14.</p></div>
    </li>
    <li class="grid grid-cols-[3rem_1fr] gap-4 items-start py-4">
      <span class="font-display text-h2 leading-none text-muted">05</span>
      <div><span class="text-body font-semibold text-primary">Governance Layer</span><p class="mt-1 text-small text-primary/80">Audit-Trail, signierte Records, Cert-Ready Controls für EU AI Act Art. 9/12/13/14, ISO 27001, IDW PS 951, GoBD.</p></div>
    </li>
    <li class="grid grid-cols-[3rem_1fr] gap-4 items-start py-4">
      <span class="font-display text-h2 leading-none text-muted">06</span>
      <div><span class="text-body font-semibold text-primary">Model Layer</span><p class="mt-1 text-small text-primary/80">Model-Registry, Versionierung, Confidence-Calibration - modellagnostisch.</p></div>
    </li>
    <li class="grid grid-cols-[3rem_1fr] gap-4 items-start py-4">
      <span class="font-display text-h2 leading-none text-muted">07</span>
      <div><span class="text-body font-semibold text-primary">Integration Layer</span><p class="mt-1 text-small text-primary/80">Konnektoren zu SAP, DATEV, Workday - buchungsfertige Outputs in die Zielsysteme.</p></div>
    </li>
  </ol>
</div>

## Anfechtbarkeit ist eine Architekturentscheidung - keine Funktion

Die unbequeme Konsequenz aus alledem: Anfechtbarkeit lässt sich nicht nachrüsten. Drei Gründe, warum ein nachträgliches Compliance-Werkzeug strukturell scheitert:

**Erstens: Was nie als Entscheidung modelliert wurde, kann nicht als Entscheidung begründet werden.** Ein Agent, der einen Vorgang "in einem Rutsch" bearbeitet, produziert ein Ergebnis ohne Gliederung. Die Zerlegung in Mikroentscheidungen muss vor der Ausführung passieren - sie definiert, an welchen Stellen ein Akt entsteht, welche Regel dort gilt und wer dort entscheidet. Nachträglich lässt sich aus einem Konversations-Log keine Entscheidungsstruktur extrahieren, so wenig wie aus einem Kontoauszug eine Kostenstellenrechnung.

**Zweitens: Wirksame menschliche Aufsicht braucht den Entscheidungskontext - pro Fall.** [Art. 14 Abs. 4](https://artificialintelligenceact.eu/article/14/) verlangt, dass die Aufsichtsperson den Output korrekt interpretieren, ihn übergehen oder rückgängig machen und das System stoppen kann - und sich der Neigung bewusst bleibt, sich automatisch auf Maschinen-Output zu verlassen. Der Gesetzgeber benennt den Automation Bias ausdrücklich. Das US-amerikanische NIST warnt im selben Sinn vor zeremoniellem Human-in-the-Loop: Ein Freigabe-Button ohne Kontext, Befugnis und Zeit schützt niemanden. Wer übersteuern soll, braucht Input, angewandte Regel, Konfidenz und Eskalationsgrund vor sich - also genau die Felder des Entscheidungsakts. Deshalb ist [Human-in-the-Loop im Decision Layer ein erzwungenes Routing](/de/magazin/human-in-the-loop-architektur/), kein optionaler Klick: Bei definierten Entscheidungstypen pausiert der Workflow, das Zielsystem bleibt unberührt, und die menschliche Entscheidung wird selbst als Akt dokumentiert - einschließlich der Information, ob sie der Empfehlung folgte oder von ihr abwich.

**Drittens: Die Korrektur braucht die Regel-Referenz.** Anfechtung ist kein Selbstzweck - sie soll Fehler beheben. Wird eine Entscheidung erfolgreich angefochten, stellt sich sofort die Frage: War es ein Einzelfehler oder ein Regelfehler? Ein Entscheidungsakt, der die angewandte Regelversion trägt, beantwortet das per Abfrage: Alle Akte derselben Regelversion sind identifizierbar, die Regel wird in einer neuen Version korrigiert, die betroffenen Fälle werden gezielt neu entschieden. Aus einem angefochtenen Einzelfall wird eine behobene Fehlerklasse. Ohne Regel-Referenz bleibt nur die manuelle Durchsicht aller Vorgänge - das Gegenteil von Skalierung.

Die Forschung nennt dieses Prinzip [Contestability by Design](https://research.tudelft.nl/en/publications/contestable-ai-by-design-towards-a-framework/) (Alfrink et al., 2022): Systeme müssen über ihren gesamten Lebenszyklus offen für menschliche Intervention sein - als prozedurale Beziehung zwischen Entscheidungsbetroffenen und Systemverantwortlichen, eingebaut statt angebaut. Und [Deloitte (2025)](https://www.deloitte.com/us/en/insights/topics/emerging-technologies/ai-agents-scaling-faster.html) benennt die drei Governance-Bausteine, die Unternehmen für Agenten fehlen, fast wortgleich mit dieser Architektur: klare Grenzen, welche Entscheidungen Agenten eigenständig treffen dürfen und welche menschliche Freigabe brauchen; Echtzeit-Überwachung mit Anomalie-Erkennung; und Audit-Trails, die die vollständige Kette der Agenten-Handlungen für Verantwortlichkeit festhalten. Das Drei-Arten-Framework, das Confidence Routing und der Entscheidungsakt sind die technische Antwort auf genau diese Liste - als Designprinzip, [nicht als nachträglicher Compliance-Layer](/de/governance/eu-ai-act/).

## Wer anficht - und was dann passiert

Anfechtbarkeit klingt abstrakt, hat aber vier sehr konkrete Gesichter. Der Decision Layer definiert für jede Mikroentscheidung, wem gegenüber sie sich rechtfertigen muss:

| Wer anficht | Rechtsgrundlage | Was er sieht | Was daraus folgt |
|---|---|---|---|
| Die betroffene Person | Art. 86 AI Act, Art. 15, 22 DSGVO | die Erläuterung der eigenen Entscheidung: Rolle des KI-Systems, wesentliche Elemente, auf Verlangen kontrafaktisch | Korrektur des Einzelfalls; bei Regelfehler Re-Run aller betroffenen Fälle |
| Der Betriebsrat | §87 Abs. 1 Nr. 6 BetrVG, Betriebsvereinbarung | Akte personalrelevanter Entscheidungen, Nachweis dass BV-Regeln technisch durchgesetzt wurden | Mitbestimmung auf Evidenzbasis statt Misstrauensbasis |
| Der Wirtschaftsprüfer | GoBD, IDW PS, ISA | vollständige Akte pro Buchung: Beleg, Regel, Version, Konfidenz, Freigabe | Systemprüfung statt Einzelfall-Nachbau; Stichprobe direkt belegbar |
| Die Aufsicht | Art. 26 Abs. 6, Art. 12 AI Act; Marktüberwachung (in Deutschland künftig Bundesnetzagentur) | exportierbare, maschinenlesbare Protokolle der geforderten Aufbewahrungsdauer | Auskunftsfähigkeit binnen Tagen statt Forensik-Projekt |

Bemerkenswert ist, was diese Tabelle mit der Organisation macht: Sie dreht die Beweislast-Dynamik um. Ohne Entscheidungsakte ist jede Anfechtung ein Forensik-Projekt mit offenem Ausgang - und nach AGG §22 trägt im Diskriminierungsfall der Arbeitgeber die Beweislast, sobald Indizien vorliegen. Mit Entscheidungsakten ist die Antwort eine Abfrage. Der Betriebsrat, der heute KI-Projekte blockiert, weil er keine Transparenz bekommt, wird zum Nutznießer derselben Infrastruktur, die auch den Wirtschaftsprüfer bedient. Andere versprechen Transparenz. Der Entscheidungsakt erzwingt sie technisch.

Die Tabelle hat eine stille Gegenseite: Wer anfechten darf, regeln Gesetz und Vereinbarung - wer dafür einsteht, dass Entscheidungsakte überhaupt entstehen, vollständig sind und Bestand haben, regelt keine Norm von selbst. Diese Verantwortung braucht einen klaren Eigentümer in der Organisation; sie fällt nicht als Nebenprodukt des Betriebs an.

## Einordnung: Ein Prinzip setzt sich durch

Der ehrliche Blick auf den Markt 2026: Die Einsicht, dass Agenten-Entscheidungen einzeln nachweisbar sein müssen, ist nicht exklusiv. Gartner hat mit [Guardian Agents](https://www.gartner.com/en/newsroom/press-releases/2025-06-11-gartner-predicts-that-guardian-agents-will-capture-10-15-percent-of-the-agentic-ai-market-by-2030) eine eigene Marktkategorie für Kontroll-Schichten geschaffen, die Agenten-Aktionen überwachen und blockieren, und prognostiziert ihr bis 2030 zehn bis 15 Prozent des Agentic-AI-Markts. Das [Decision-Intelligence-Feld](https://www.gartner.com/en/information-technology/glossary/decision-intelligence) - Entscheidungen explizit modellieren, bewerten und verbessern - bekam im Januar 2026 sein erstes Magic Quadrant. Das WEF fordert [Progressive Governance](https://www.weforum.org/publications/ai-agents-in-action-foundations-for-evaluation-and-governance/): Aufsichtsintensität gekoppelt an die Autonomiestufe des Agenten. Die Forschung arbeitet an Decision Provenance. Die Richtung ist eindeutig - und sie ist exakt die Richtung des Decision Layer.

Was diese Ansätze nicht leisten, ist die Bindung an die Fachlichkeit. Ein Guardian Agent blockiert zur Laufzeit; er hinterlässt keinen Akt, der drei Jahre später vor dem Arbeitsgericht trägt. Observability bewahrt die Ausführungskette; sie zerlegt Entscheidungen nicht in einzeln begründete, regelgebundene Artefakte. Die verteidigbare Differenz des Entscheidungsakts liegt in drei Eigenschaften: der Attribution jeder Mikroentscheidung an eine versionierte Fachregel samt Quelle - Tarifvertrag, Betriebsvereinbarung, Steuerrecht - statt an eine generierte Begründungskette; dem architektonisch erzwungenen Human-in-the-Loop pro Entscheidungstyp statt einer abschaltbaren Konfiguration; und dem Mapping der Akte auf die Prüfungsstandards, mit denen Wirtschaftsprüfer und Revision tatsächlich arbeiten - ISA, IDW PS, GoBD. Das erste Feld dokumentiert nach unserem Kenntnisstand kein horizontaler Anbieter; es ist zugleich das Feld, an dem Anfechtbarkeit hängt.

Zur Präzision gehört auch die Abgrenzung: Der Entscheidungsakt ist eine Architekturaussage, kein Konformitätszertifikat. Ob ein konkretes System die rechtlichen Anforderungen erfüllt, bleibt eine Bewertung des Einzelfalls durch den Betreiber und seine Rechtsberater. Was die Architektur leistet, ist etwas anderes - und Wertvolleres: Sie macht die Anforderungen erfüllbar. Ein Unternehmen mit Entscheidungsakten kann die Art.-86-Frage beantworten. Ein Unternehmen mit Chat-Logs kann es nicht, egal wie gut seine Absichten dokumentiert sind.

## Die eigentliche Frage

Der EU AI Act hat die Erklärbarkeit von Einzelentscheidungen nicht erfunden - er hat sie für KI-Systeme kodifiziert und mit einem Betroffenenrecht bewehrt. Die EuGH-Rechtsprechung hat den Maßstab gesetzt, bevor die erste Hochrisiko-Frist überhaupt greift. Und die Beratungshäuser haben quantifiziert, was passiert, wenn Unternehmen Entscheidungsrechte übertragen, ohne Entscheidungen nachweisen zu können: abgebrochene Projekte, blockierte Rollouts, persönlich haftende CIOs.

Die Frage an jedes Unternehmen, das KI-Agenten einsetzt oder einführt, ist deshalb nicht "Sind wir compliant?". Sie lautet: Wenn morgen ein Mitarbeiter, ein Betriebsrat, ein Prüfer oder eine Behörde eine einzelne Entscheidung von heute anficht - können Sie den Akt vorlegen? Input, Regel, Version, Konfidenz, Ergebnis, Freigabe?

Wer diese Frage mit Ja beantworten kann, hat kein KI-Risiko-Problem mehr. Er hat eine Entscheidungs-Infrastruktur.

→ [Decision Layer - Übersicht und Beispiele](/de/decision-layer/)

→ [Decision Layer erklärt: die vier Komponenten](/de/magazin/decision-layer-erklaert/)

→ [EU AI Act: HR-KI bleibt Hochrisiko - Frist 2026/2027](/de/magazin/eu-ai-act-hr-hochrisiko/)

<a href="/de/kontakt/" target="_blank" rel="noopener noreferrer">Termin vereinbaren</a> - Wir zeigen Ihnen an einem Ihrer Prozesse, wie Mikroentscheidungen, Entscheidungsakte und Anfechtungswege konkret aussehen.

--- EU AI Act 2026: Status, Fristen, Handlungsbedarf ---
> EU AI Act 2026: Verbote aktiv, AI Literacy Pflicht, High-Risk-Frist 2. August 2026 - Verschiebung auf Dezember 2027 vorläufig geeinigt (Digital Omnibus). Timeline, Pflichten und Handlungsempfehlungen.

Der [EU AI Act](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32024R1689) trat am 1. August 2024 in Kraft und ist das weltweit erste Gesetz, das KI-Systeme nach Risikostufen reguliert. Zwei Fristen sind abgelaufen, die Hochrisiko-Frist für Annex-III-Systeme greift nach aktuellem Recht am 2. August 2026 - soll sich aber nach der vorläufigen Digital-Omnibus-Einigung vom 7. Mai 2026 auf den 2. Dezember 2027 verschieben (formale Verabschiedung ausstehend, Stand Juni 2026). Die Hochrisiko-Einstufung selbst bleibt in beiden Fällen bestehen. Laut einer Erhebung von [Gartner](https://www.gartner.com) haben weniger als 10% der betroffenen Organisationen ihr KI-System-Inventar abgeschlossen. Dieser Artikel zeigt, was gilt, was kommt und welche Schritte Unternehmen jetzt umsetzen sollten.

Ein konkretes Szenario macht die Tragweite greifbar. Ein mittelständischer Personaldienstleister mit 400 Beschäftigten setzt [HireVue](https://www.hirevue.com) für automatisiertes Bewerbungsscreening ein. Das System filtert Lebensläufe vor, bewertet Videointerviews und schlägt Kandidaten vor. 15 Recruiter arbeiten täglich damit. Daneben nutzt das Team ChatGPT von [OpenAI](https://openai.com) für Stellenanzeigen. Das Screening-System fällt in die Hochrisiko-Kategorie - die zugehörigen Pflichten greifen nach aktuellem Recht ab dem 2. August 2026, mit vorläufig geeinigter Verschiebung auf Dezember 2027. Was das für Risikomanagement, Daten-Governance und menschliche Aufsicht bedeutet, zeigen die folgenden Abschnitte.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Auf einen Blick - EU AI Act 2026 Status für Unternehmen</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Verbotene KI-Praktiken (Social Scoring, Manipulation, Emotionserkennung am Arbeitsplatz) und AI-Literacy-Pflicht gelten seit Februar 2025.</li>
<li>GPAI-Pflichten für Anbieter wie <a href="https://openai.com">OpenAI</a>, <a href="https://deepmind.google">Google DeepMind</a> und <a href="https://www.anthropic.com">Anthropic</a> greifen seit August 2025.</li>
<li>Hochrisiko-KI-Systeme müssen nach aktuellem Recht bis 2. August 2026 vollständig compliant sein. Bußgelder: bis 15 Mio. EUR oder 3% des weltweiten Umsatzes.</li>
<li>Rat und Parlament haben sich am 7. Mai 2026 im Digital-Omnibus-Paket vorläufig auf eine Verschiebung der Annex-III-Frist auf den 2. Dezember 2027 geeinigt. Die formale Verabschiedung und Veröffentlichung im EU-Amtsblatt steht aus (erwartet ~Juni/Juli 2026). Bis dahin bleibt der 2. August 2026 maßgeblich - die Einstufung als Hochrisiko bleibt ohnehin bestehen.</li>
<li>In Deutschland setzt das <a href="https://bmds.bund.de/service/gesetzgebungsverfahren/gesetz-zur-durchfuehrung-der-ki-verordnung">KI-MIG</a> die Verordnung um. Die <a href="https://www.bundesnetzagentur.de">Bundesnetzagentur</a> wird zentrale Marktüberwachungsbehörde.</li>
<li>Erster Schritt jetzt: AI-System-Inventar erstellen. Alle KI-Systeme in vier bis acht Wochen erfassen.</li>
</ul>
</div>

<table>
<thead>
<tr><th>Meilenstein</th><th>Datum</th><th>Status</th><th>Kernpflichten</th></tr>
</thead>
<tbody>
<tr><td>Inkrafttreten</td><td>1. Aug. 2024</td><td>Aktiv</td><td>Rahmenwerk etabliert</td></tr>
<tr><td>Verbote + AI Literacy</td><td>2. Feb. 2025</td><td>Aktiv</td><td>Social Scoring und Manipulation verboten, Schulungspflicht</td></tr>
<tr><td>GPAI-Pflichten</td><td>2. Aug. 2025</td><td>Aktiv</td><td>Transparenz, Kennzeichnung, technische Dokumentation</td></tr>
<tr><td>Hochrisiko (Annex III)</td><td>2. Aug. 2026 (Verschiebung auf 2. Dez. 2027 vorläufig geeinigt)</td><td>Frist im Fluss</td><td>Risikomanagement, Daten-Governance, Human Oversight</td></tr>
<tr><td>Produktintegrierte KI (Annex I)</td><td>2. Aug. 2027</td><td>2027</td><td>Branchenspezifische Regeln, CE-Kennzeichnung</td></tr>
</tbody>
</table>

## Drei EU-Institutionen und eine nationale Behörde setzen den AI Act durch

Das [Europäische Parlament](https://www.europarl.europa.eu) und der [Rat der Europäischen Union](https://www.consilium.europa.eu) verabschiedeten die [Verordnung (EU) 2024/1689](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32024R1689) am 13. Juni 2024. Die [Europäische Kommission](https://commission.europa.eu) koordiniert die Umsetzung über das [European AI Office](https://digital-strategy.ec.europa.eu/en/policies/ai-office) in Brüssel. Direktorin [Lucilla Sioli](https://op.europa.eu/en/web/who-is-who/person/-/person/COM_000030222F) leitet die Behörde seit Juni 2024. Das AI Office überwacht GPAI-Modelle mit systemischem Risiko, beschäftigt über 100 Mitarbeitende und koordiniert die grenzüberschreitende Durchsetzung. Das European Artificial Intelligence Board stimmt die 27 nationalen Aufsichtsbehörden ab.

In Deutschland wird die [Bundesnetzagentur](https://www.bundesnetzagentur.de) zur zentralen Marktüberwachungsbehörde. Das [KI-MIG](https://bmds.bund.de/service/gesetzgebungsverfahren/gesetz-zur-durchfuehrung-der-ki-verordnung) (KI-Marktüberwachungs- und Innovationsförderungsgesetz) regelt die nationale Durchführung. Der Bundestag beriet den Entwurf am 20. März 2026 in erster Lesung. Eine KI-Marktüberwachungskammer bei der [Bundesnetzagentur](https://www.bundesnetzagentur.de) soll Hochrisiko-Systeme prüfen. Die Bußgeldkompetenz verbleibt bei den sektoralen Fachbehörden - BaFin für Finanzprodukte, BfArM für Medizinprodukte.

Für unseren Personaldienstleister bedeutet das: Die [Bundesnetzagentur](https://www.bundesnetzagentur.de) in Bonn prüft, ob das [HireVue](https://www.hirevue.com)-Bewerbungsscreening die Anforderungen erfüllt. Die Aufsicht liegt nicht in Brüssel.

## Fünf verbotene KI-Praktiken kosten bis zu 35 Mio. EUR

Seit dem 2. Februar 2025 sind fünf KI-Praktiken verboten. Die Bußgelder sind die höchsten in der gesamten Verordnung.

- **Social Scoring:** KI, die Personen auf Basis ihres Sozialverhaltens bewertet und daraus Nachteile ableitet.
- **Manipulative KI:** Systeme mit unterschwelligen Techniken, die Verhalten verzerren. Dazu zählen Dark Patterns, die Kaufentscheidungen erzwingen.
- **Echtzeit-Biometrie im öffentlichen Raum:** Biometrische Fernidentifikation in Echtzeit. Ausnahmen gelten nur für Strafverfolgung mit richterlicher Genehmigung.
- **Emotionserkennung am Arbeitsplatz:** KI, die Emotionen von Beschäftigten oder Lernenden erkennt. [HireVue](https://www.hirevue.com) hat seine Gesichtsanalyse bereits 2021 nach Kritik entfernt und analysiert nur noch Antwortinhalte. Aber jedes HR-System mit Emotionserkennung ist nicht nur Hochrisiko - es ist verboten.
- **Predictive Policing:** Risikoeinschätzungen für Straftaten, die nur auf persönlichen Merkmalen basieren.

Verstöße kosten bis zu 35 Mio. EUR oder 7% des weltweiten Jahresumsatzes. Für KMU gilt der niedrigere Betrag. Unser Personaldienstleister hat geprüft: [HireVue](https://www.hirevue.com) setzt keine Emotionserkennung mehr ein. Kein Verbotsverstoß. Aber die Prüfung selbst muss dokumentiert sein.

Die **AI-Literacy-Pflicht** gilt seit demselben Datum. Jede Person, die ein KI-System nutzt, braucht angemessene Kompetenz. Die 15 Recruiter des Personaldienstleisters brauchen dokumentierte Schulungen. Inhalt, Teilnehmer und Auffrischungszyklen müssen nachweisbar sein. Die Kosten sind überschaubar: zwei Schulungstage und ein jährliches Update.

Mehr zu den organisatorischen Folgen im Artikel [Betriebsrat & AI Literacy: Die Organisationsfragen](/de/magazin/ki-betriebsrat-ai-literacy/).

## GPAI-Pflichten betreffen auch Unternehmen, die nur Modelle nutzen

Seit dem 2. August 2025 regulieren die Artikel 51 bis 56 General-Purpose AI. Die Pflichten betreffen primär Anbieter. [OpenAI](https://openai.com) muss für GPT-4 technische Dokumentation liefern. [Google DeepMind](https://deepmind.google) dokumentiert Gemini. [Anthropic](https://www.anthropic.com) veröffentlicht für Claude System Cards mit Sicherheitsbewertungen. Aber auch Deployer - also Unternehmen, die diese Modelle einsetzen - haben drei Pflichten:

- **Kennzeichnung:** Generierte Inhalte müssen maschinenlesbar als KI-erzeugt markiert sein.
- **Transparenz:** Personen müssen wissen, dass sie mit KI interagieren.
- **Inventarisierung:** Welche GPAI-Modelle sind im Einsatz? Diese Dokumentation bildet die Basis für die Hochrisiko-Compliance.

Das betrifft Großunternehmen wie [Deutsche Telekom](https://www.telekom.de), [SAP](https://www.sap.com) und [BMW](https://www.bmw.com) ebenso wie Mittelständler. Unser Personaldienstleister nutzt neben [HireVue](https://www.hirevue.com) auch ChatGPT für Stellenanzeigen. Dieses System muss im GPAI-Inventar stehen - mit Anbieter ([OpenAI](https://openai.com)), Version und Einsatzkontext. Das Inventar deckte bei unserem Personaldienstleister drei weitere KI-Tools auf, die Mitarbeitende eigenständig nutzten. [Shadow AI](/de/magazin/decision-layer-shadow-ai/) ist ein reales Risiko.

Anbieter von GPAI-Modellen mit systemischem Risiko - ab 10^25 FLOP Rechenleistung - haben Zusatzpflichten: Red-Teaming, Cybersicherheit und Vorfallmeldung an das [European AI Office](https://digital-strategy.ec.europa.eu/en/policies/ai-office).

## HR-KI ist fast immer Hochrisiko - und die Frist steht im Fluss

Anhang III Nr. 4 der [Verordnung (EU) 2024/1689](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32024R1689) erfasst Beschäftigung, Personalmanagement und Zugang zu selbstständiger Tätigkeit. Der Personalbereich hat die höchste Hochrisiko-Dichte aller Unternehmensbereiche. Vier typische Systeme:

**Automatisiertes Bewerbungsscreening:** [SAP SuccessFactors](https://www.sap.com/products/hcm.html), [Workday](https://www.workday.com) Talent Acquisition und [HireVue](https://www.hirevue.com) - jedes System, das Bewerbungen vorsortiert oder bewertet, ist Hochrisiko. Auch wenn ein Mensch die finale Entscheidung trifft.

**KI-gestützte Leistungsbeurteilungen:** [Microsoft Viva Insights](https://www.microsoft.com/en-us/microsoft-viva) oder [Personio](https://www.personio.de) Performance-Module, die Leistungsdaten analysieren. Reine Empfehlungssysteme fallen ebenfalls darunter.

**Predictive Attrition:** KI, die vorhersagt, welche Mitarbeitenden kündigen. Personenbezogene Daten für Beschäftigungsentscheidungen - klassisches Hochrisiko.

**Automatische Dienstplan-Optimierung:** Wenn individuelle Präferenzen oder Gesundheitsdaten einfließen, potenziell Hochrisiko.

Unser Personaldienstleister muss das [HireVue](https://www.hirevue.com)-System in sieben Bereichen compliant machen: Risikomanagementsystem, Daten-Governance, technische Dokumentation, automatische Protokollierung, Transparenz, Human Oversight und Robustheit. Maßgeblich ist nach aktuellem Recht der 2. August 2026; die vorläufig geeinigte Verschiebung auf Dezember 2027 verschafft im Bestätigungsfall zusätzliche Vorlaufzeit. Die gute Nachricht: [HireVue](https://www.hirevue.com) hat bereits Bias-Audits mit DCI Consulting durchgeführt und stellt Compliance-Dokumentation bereit. Anbieter, die vorarbeiten, reduzieren den Aufwand für Deployer erheblich. Details zum Zusammenspiel von KI und HR unter [HR & AI Agents](/de/hr-ai-agents/).

## Sieben Compliance-Pflichten machen Hochrisiko-Systeme rechtskonform

Jedes Hochrisiko-System muss die Anforderungen der Artikel 8 bis 15 erfüllen:

1. **Risikomanagement:** Dokumentierte Identifikation, Analyse und Minimierung von Risiken über den gesamten Lebenszyklus. Kein einmaliger Check - ein iterativer Prozess.
2. **Daten-Governance:** Trainingsdaten müssen repräsentativ, fehlerfrei und auf Verzerrungen geprüft sein. Unser Personaldienstleister muss nachweisen, dass die [HireVue](https://www.hirevue.com)-Trainingsdaten keine Diskriminierung nach Geschlecht oder Herkunft erzeugen.
3. **Technische Dokumentation:** Architektur, Trainingsverfahren, Leistungskennzahlen und Limitierungen - alles vor Inbetriebnahme.
4. **Aufzeichnung:** Automatische Protokollierung aller Entscheidungen für Nachvollziehbarkeit.
5. **Transparenz:** Gebrauchsanweisungen für Deployer, die sachgerechte Nutzung ermöglichen.
6. **Human Oversight:** Technische Maßnahmen für wirksame menschliche Aufsicht. Der [Decision Layer](/de/decision-layer/) setzt genau diese Anforderung architektonisch um.
7. **Genauigkeit und Cybersicherheit:** Das System muss die deklarierte Leistung zuverlässig erbringen.

Für bestimmte Kategorien verlangt Artikel 43 eine Konformitätsbewertung durch eine benannte Stelle wie [TÜV Süd](https://www.tuvsud.com) oder [Bureau Veritas](https://www.bureauveritas.com). Für andere reicht die Selbstbewertung. Der Engpass: Die Kapazitäten der benannten Stellen sind begrenzt. Wer einen Prüftermin braucht, sollte ihn frühzeitig anfragen - unabhängig davon, ob die geltende Frist (2. August 2026) oder die vorläufig geeinigte Verschiebung (Dezember 2027) greift. Bußgelder bei Verstößen: bis zu 15 Mio. EUR oder 3% des weltweiten Jahresumsatzes.

## Das Digital Omnibus verschiebt die Frist voraussichtlich auf Dezember 2027 - vorläufig geeinigt, formal noch nicht in Kraft

Die [Europäische Kommission](https://commission.europa.eu) legte Ende 2025 das Digital-Omnibus-Paket vor. Der zentrale Grund: [CEN und CENELEC](https://www.cencenelec.eu) entwickeln über das Joint Technical Committee JTC 21 die harmonisierten Normen für den AI Act. Aber Stand April 2026 ist keine harmonisierte Norm im Amtsblatt der EU gelistet. Die Entwurfsnorm prEN 18286 (AI Quality Management System) durchlief bis Januar 2026 die öffentliche Kommentierungsphase. CEN und CENELEC beschlossen im Oktober 2025 beschleunigte Verfahren, die eine direkte Veröffentlichung ohne separaten Formal Vote erlauben. Die Veröffentlichung von prEN 18286 ist für Ende 2026 geplant. Ohne fertige Normen fehlt Unternehmen die Konformitätsvermutung.

**Aktueller Stand (Juni 2026):** Das [Europäische Parlament](https://www.europarl.europa.eu) stimmte am 26. März 2026 mit 569 zu 45 Stimmen für seine Verhandlungsposition, der [Rat der Europäischen Union](https://www.consilium.europa.eu) beschloss sein Mandat am 13. März 2026. Am 7. Mai 2026 erzielten Rat und Parlament eine [vorläufige politische Einigung](https://www.consilium.europa.eu/en/press/press-releases/2026/05/07/artificial-intelligence-council-and-parliament-agree-to-simplify-and-streamline-rules/) und setzen den 2. Dezember 2027 als neue Frist für Annex-III-Systeme und den 2. August 2028 für produktintegrierte KI. Die [Europäische Kommission](https://commission.europa.eu) hatte ursprünglich einen bedingten Mechanismus vorgeschlagen - die Co-Gesetzgeber ersetzen ihn durch feste Daten.

Was noch fehlt: die formale Verabschiedung und die Veröffentlichung im EU-Amtsblatt. Sie wird vor dem 2. August 2026 erwartet (~Juni/Juli 2026). Bis die Verschiebung dort steht, bleibt der 2. August 2026 die rechtlich geltende Frist - Unternehmen sollten daher beide Szenarien im Blick behalten.

**Die Empfehlung: Vorbereitung nicht aufschieben.** Die Hochrisiko-Einstufung bleibt in jedem Fall bestehen; nur der Stichtag bewegt sich. Wer die voraussichtlich gewonnene Zeit bis Dezember 2027 zum strukturierten Aufbau der Governance nutzt, steht entspannt da - egal welcher Termin am Ende im Amtsblatt steht. Unser Personaldienstleister baut sein [HireVue](https://www.hirevue.com)-System genau so auf: Governance jetzt, ohne auf das Amtsblatt zu warten.

## [ISO/IEC 42001](https://www.iso.org/standard/81230.html) gibt Unternehmen jetzt eine Struktur - auch ohne fertige EU-Normen

Da keine harmonisierte europäische Norm im Amtsblatt steht, greifen Unternehmen auf internationale Standards zurück. [ISO/IEC 42001](https://www.iso.org/standard/81230.html) ist der weltweit erste internationale Standard für KI-Managementsysteme. Er bietet eine Struktur für Risikobewertung, Governance und kontinuierliche Verbesserung.

[SAP](https://www.sap.com) hat 2025 die [ISO/IEC 42001](https://www.iso.org/standard/81230.html)-Zertifizierung für SAP AI Core und den KI-Assistenten Joule erhalten. [Siemens](https://www.siemens.com) und [Allianz](https://www.allianz.de) nutzen den Standard als Grundlage für ihre KI-Governance. Ergänzend hilft [ISO 27001](https://www.iso.org/standard/27001) bei der Informationssicherheit, die Artikel 15 der Verordnung verlangt.

Aber: [ISO/IEC 42001](https://www.iso.org/standard/81230.html) zertifiziert nicht die Genauigkeit eines Modells zu einem Zeitpunkt. Der Standard validiert, ob eine Organisation ein System zur kontinuierlichen Identifikation und Steuerung von KI-Risiken etabliert hat. Die spezifischen Anforderungen der Artikel 8 bis 15 müssen zusätzlich abgedeckt werden.

Für unseren Personaldienstleister ist [ISO/IEC 42001](https://www.iso.org/standard/81230.html) eine pragmatische Wahl. Der Standard gibt dem Team eine Methodik, ohne auf die noch fehlenden [CEN/CENELEC](https://www.cencenelec.eu)-Normen warten zu müssen. Die Investition zahlt sich doppelt aus: als Compliance-Grundlage und als Differenzierungsmerkmal gegenüber Kunden, die zunehmend KI-Governance bei Dienstleistern voraussetzen.

## Sechs Schritte sichern die Hochrisiko-Compliance

1. **Verbotstatbestände prüfen.** Stellen Sie sicher, dass keines Ihrer Systeme unter Artikel 5 fällt. Emotionserkennung in HR-Kontexten ist verboten, nicht nur Hochrisiko. Unser Personaldienstleister hat diese Prüfung in zwei Tagen abgeschlossen.
2. **AI Literacy dokumentieren.** Schulungen für alle KI-Nutzer nachweisen. Die Pflicht gilt seit Februar 2025. Zwei Schulungstage pro Mitarbeitendem reichen als Basis.
3. **AI-System-Inventar erstellen.** Alle Systeme mit Anbieter, Kontext und Risikoklasse erfassen. Offiziell beschaffte Systeme zuerst. Dann [Shadow AI](/de/magazin/decision-layer-shadow-ai/) - KI, die Mitarbeitende ohne Wissen der IT nutzen. Bei unserem Personaldienstleister kamen so drei unbekannte Tools ans Licht.
4. **Hochrisiko-Systeme identifizieren.** HR, Kreditentscheidungen und automatisierte Prozesse gegen die acht Kategorien von Anhang III prüfen. [SAP SuccessFactors](https://www.sap.com/products/hcm.html), [Workday](https://www.workday.com) und [HireVue](https://www.hirevue.com) sind fast immer betroffen.
5. **Compliance aufbauen.** Für Hochrisiko-Systeme: Risikomanagement, Daten-Governance, technische Dokumentation und Human Oversight. [ISO/IEC 42001](https://www.iso.org/standard/81230.html) als Rahmenwerk nutzen. Konformitätsbewertung bei [TÜV Süd](https://www.tuvsud.com) oder [Bureau Veritas](https://www.bureauveritas.com) frühzeitig anfragen. Geltende Frist: 2. August 2026, voraussichtlich verschoben auf 2. Dezember 2027.
6. **Amtsblatt-Veröffentlichung im Blick behalten.** Die Verschiebung auf Dezember 2027 ist seit dem 7. Mai 2026 vorläufig geeinigt, aber erst mit der Veröffentlichung im EU-Amtsblatt rechtlich verbindlich. Bis dahin gilt der frühere Termin - die Governance-Arbeit sollte ohnehin unabhängig vom Stichtag laufen.

Unser Personaldienstleister hat Schritt 5 seit vier Wochen begonnen. Die [Governance-Infrastruktur](/de/governance/) behandelt das Inventar als lebendes Dokument. Der Aufwand für ein Unternehmen mit 400 Beschäftigten und drei Hochrisiko-Systemen: eine halbe Vollzeitstelle für sechs Monate und etwa 30.000 EUR für externe Beratung und Prüfung. Das ist weniger als ein Bußgeldbescheid.

---

**Enterprise AI-Infrastruktur Blueprint 2026 - Artikel-Serie**

| Vorheriger | Übersicht | Nächster |
|:---|:---:|---:|
| [Was KI wirklich kostet: TCO-Vergleich für Unternehmen](/de/magazin/ki-kosten-tco-vergleich/) | [Zur Übersicht](/de/magazin/ai-infrastruktur-blueprint-2026/) | [Betriebsrat & AI Literacy: Die Organisationsfragen](/de/magazin/ki-betriebsrat-ai-literacy/) |

*Alle Artikel dieser Serie: [Enterprise AI-Infrastruktur Blueprint 2026](/de/magazin/ai-infrastruktur-blueprint-2026/)*

---

Gosign begleitet Unternehmen bei der Compliance mit dem [EU AI Act](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32024R1689) - vom System-Inventar über die Konformitätsbewertung bis zur Registrierung in der EU-Datenbank. Wenn Sie wissen wollen, wo Ihr Unternehmen steht, sprechen Sie mit uns.

<a href="/de/kontakt/" target="_blank" rel="noopener noreferrer">Termin vereinbaren</a>. 30 Minuten, in denen wir Ihren Compliance-Status bewerten.

--- Der EU AI Act gilt weltweit. ---
> Der EU AI Act schreibt nur auf, was jedes Rechtssystem längst verlangt: Erklären Sie Ihre Entscheidung. Warum HR weltweit betroffen ist.

*Somalia. Südsudan. Jemen. Libyen. Syrien. - Das sind die einzigen Ausnahmen.*

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Auf einen Blick - KI-Accountability ist universell</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Der EU AI Act hat erklärbare KI-Entscheidungen nicht erfunden - er hat das Prinzip nur als Erster für KI-Systeme kodifiziert. Die Pflicht, Entscheidungen zu erklären, existiert in praktisch jedem Rechtssystem weltweit.</li>
<li>HR ist der Hochrisikobereich, weil KI-Entscheidungen über Menschen die größte rechtliche Angriffsfläche bieten - vom CV-Screening-Bias bis zur automatisierten Leistungsbeurteilung.</li>
<li>Ein voreingenommener Algorithmus skaliert Diskriminierung auf 50.000 Entscheidungen gleichzeitig - verglichen mit etwa 50 pro Jahr eines voreingenommenen Managers.</li>
<li>Jedes Unternehmen, das KI für Entscheidungen über Menschen einsetzt, braucht zwei Schichten: einen Decision Layer (Beweissicherung für jede Entscheidung) und einen Governance Layer (Spielregeln).</li>
<li>Shadow AI - Mitarbeitende die ChatGPT, Copilot und andere Tools ohne Governance nutzen - ist das dringendste und am meisten unterschätzte Risiko für die meisten Unternehmen.</li>
</ul>
</div>

Laut Europäischer Kommission (2024) werden KI-Systeme, die unter dem EU AI Act als Hochrisiko eingestuft sind, Personalentscheidungen in über 6.000 Organisationen in den EU-Mitgliedsstaaten direkt betreffen. HR wurde als der am häufigsten betroffene Unternehmensbereich nach Anhang III identifiziert.

## Die 3-Millionen-Euro-Frage

Ein deutsches Unternehmen setzt ein KI-Tool im Recruiting ein. 500 Bewerbungen rein, 20 raus. Einer der 480 Abgelehnten klagt. Nicht wegen des EU AI Act. Wegen des Allgemeinen Gleichbehandlungsgesetzes, das es seit 2006 gibt.

Die Frage des Arbeitsgerichts: "Erklären Sie, wie diese Entscheidung zustande kam."

Stille.

Nicht weil das Unternehmen böswillig gehandelt hat. Sondern weil niemand im Unternehmen erklären kann, wie das KI-Tool die 480 Absagen produziert hat. Die Personalabteilung hat das Tool gekauft. Die IT hat es installiert. Und die Entscheidungslogik steckt in einer Black Box, die niemand öffnen kann.

Das ist keine hypothetische Situation. Das passiert gerade. Und es passiert nicht nur in Deutschland.

## Accountability ist kein EU-Konzept

Die meisten Führungskräfte haben den EU AI Act mental als "europäische Regulierung" abgehakt. Das ist ein teurer Denkfehler. Der EU AI Act hat das Prinzip der erklärbaren Entscheidungen nicht erfunden. Er hat es nur als Erster für KI-Systeme aufgeschrieben.

Das Prinzip selbst gilt überall.

**USA:** Title VII des Civil Rights Act verbietet Diskriminierung bei Personalentscheidungen - seit 1964. Die Equal Employment Opportunity Commission (EEOC) kann jederzeit verlangen, dass ein Unternehmen erklärt, warum ein Kandidat abgelehnt wurde. In New York City verlangt Local Law 144 seit 2023 verpflichtende Bias Audits für KI-Tools im Recruiting.

**Brasilien:** LGPD Artikel 20 gewährt ein explizites Recht auf Erklärung automatisierter Entscheidungen. Brasilianische Arbeitsgerichte gehören zu den aktivsten weltweit - über 3,5 Millionen neue Verfahren pro Jahr.

**China:** Die Algorithmic Recommendation Management Provisions gelten seit 2022. Auch China verlangt Transparenz bei algorithmischen Entscheidungen.

**Indien:** Der IT Act 2000 in Kombination mit dem Industrial Disputes Act gibt Arbeitnehmern Instrumente, automatisierte Entscheidungen anzufechten.

**Überall sonst:** In jedem Land mit funktionierendem Zivilrecht kann ein Mensch, über den eine KI-Entscheidung getroffen wurde, diese Entscheidung vor Gericht anfechten. Die Frage "Warum?" ist universell - und eine Black Box ist nirgendwo eine akzeptable Antwort.

Von den 193 UN-Mitgliedsstaaten gibt es genau 5, in denen ein Unternehmen für eine unerklärbare KI-Entscheidung nicht rechtlich zur Rechenschaft gezogen werden kann. Nicht weil diese Länder es erlauben - sondern weil sie kein funktionierendes Gerichtssystem haben.

Der EU AI Act ist nicht europäische Überregulierung. Er ist die erste ehrliche Antwort auf eine universelle Frage.

<table class="w-full text-left text-sm">
<thead><tr class="border-b border-gosign-border">
<th class="py-2 pr-4 font-semibold">Region</th>
<th class="py-2 pr-4 font-semibold">Gesetzgebung</th>
<th class="py-2 pr-4 font-semibold">Erklärbarkeit gefordert</th>
<th class="py-2 pr-4 font-semibold">HR-Entscheidungen erfasst</th>
</tr></thead>
<tbody>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">EU</td><td class="py-2 pr-4">EU AI Act, DSGVO Art. 22</td><td class="py-2 pr-4">Ja (rechtsverbindlich)</td><td class="py-2 pr-4">Ja (Anhang III Hochrisiko)</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">USA</td><td class="py-2 pr-4">Title VII, NYC Local Law 144</td><td class="py-2 pr-4">Ja (Antidiskriminierung)</td><td class="py-2 pr-4">Ja (Personalentscheidungen)</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Brasilien</td><td class="py-2 pr-4">LGPD Art. 20, CLT</td><td class="py-2 pr-4">Ja (Recht auf Erklärung)</td><td class="py-2 pr-4">Ja (Arbeitsgerichte aktiv)</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">China</td><td class="py-2 pr-4">Algorithmic Provisions 2022</td><td class="py-2 pr-4">Ja (Transparenz gefordert)</td><td class="py-2 pr-4">Ja (algorithmische Entscheidungen)</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">UK</td><td class="py-2 pr-4">UK GDPR, Equality Act 2010</td><td class="py-2 pr-4">Ja (ICO-Leitlinien)</td><td class="py-2 pr-4">Ja (automatisierte Entscheidungen)</td></tr>
</tbody>
</table>

## Warum HR das Ground Zero ist

<img src="/images/magazin/risk-pyramid-de.svg" alt="Risikopyramide: HR-Entscheidungen über Menschen haben das höchste Risiko, Prozess-Entscheidungen mittleres, Produkt-Entscheidungen das geringste" width="800" height="480" loading="lazy" />

KI-Entscheidungen über Produkte sind ärgerlich, wenn sie falsch sind. KI-Entscheidungen über Prozesse sind teuer, wenn sie falsch sind. KI-Entscheidungen über Menschen sind existenzbedrohend - für die Betroffenen und für das Unternehmen.

HR ist der Bereich, in dem KI-Entscheidungen die größte Angriffsfläche bieten. Drei Szenarien die heute schon passieren:

Ein KI-gestütztes CV-Screening filtert systematisch Kandidaten mit Lücken im Lebenslauf. Betroffen: Eltern, chronisch Kranke, Karrierewechsler. Das ist in den meisten Jurisdiktionen mittelbare Diskriminierung.

Eine Sentiment Analysis in Video-Interviews bewertet kulturelle Unterschiede in Gestik und Mimik als negative Signale. Betroffen: Kandidaten mit anderem kulturellen Hintergrund. Das ist potenziell ethnische Diskriminierung.

Ein Performance-Prediction-Tool wird auf historischen Beförderungsdaten trainiert. Wenn in der Vergangenheit Männer häufiger befördert wurden, reproduziert das Tool dieses Muster. Das ist systematische Geschlechterdiskriminierung - automatisiert und skaliert.

Jedes dieser Szenarien ist heute schon in den meisten Ländern einklagbar. Nicht erst ab dem 2. August 2026, der nach aktuellem Recht geltenden Hochrisiko-Frist (Verschiebung auf den 2. Dezember 2027 am 7. Mai 2026 im Digital Omnibus vorläufig geeinigt, formale Verabschiedung ausstehend). Jetzt. Der Unterschied: Der EU AI Act macht daraus eine proaktive Pflicht statt nur eine reaktive Haftung.

Und das eigentliche Problem an KI-Diskriminierung im Vergleich zu menschlicher Diskriminierung: Ein voreingenommener Manager trifft vielleicht 50 fragwürdige Entscheidungen im Jahr. Ein voreingenommener Algorithmus trifft 50.000. Gleichzeitig. Konsistent. Nachweisbar.

## Die zwei Schichten die jedes Unternehmen braucht

<img src="/images/magazin/decision-governance-layers-de.svg" alt="Governance Layer und Decision Layer: Zwei-Schichten-Architektur für erklärbare KI-Entscheidungen" width="800" height="440" loading="lazy" />

Die Lösung ist nicht komplex - aber sie erfordert architekturelles Denken. Jedes Unternehmen das KI für Entscheidungen über Menschen einsetzt, braucht zwei Schichten.

**Der [Decision Layer](/de/magazin/decision-layer-shadow-ai/) - die Beweissicherung.** Der Decision Layer zerlegt jeden Prozess in einzelne Entscheidungsschritte und definiert für jeden Schritt: Mensch, Regelwerk oder KI. Jede KI-gestützte Entscheidung beantwortet: Welche Daten flossen ein? Welches Modell hat entschieden, in welcher Version? Was war das Ergebnis und mit welcher Konfidenz? Hat ein Mensch das Ergebnis gesehen, bevor es wirksam wurde? Ist die Entscheidung reproduzierbar?

Das ist kein technisches Nice-to-have. Das ist das digitale Äquivalent einer Buchhaltung. Und genauso wie kein Unternehmen ohne Buchhaltung operieren kann, wird bald kein Unternehmen ohne Decision Layer operieren können.

**Der Governance Layer - die Spielregeln.** Bevor die erste KI-Entscheidung fällt: Welche KI-Anwendungen gibt es überhaupt im Unternehmen? Die meisten Unternehmen wissen das nicht. Wie riskant ist welche Anwendung - nicht nach regulatorischen Kategorien, sondern nach realem Impact auf Menschen? Wer trägt die Verantwortung? Spoiler: "Die IT" ist keine Antwort. Wann muss ein Mensch eingreifen? Und wie wird das Ganze auditiert?

In Deutschland kommt eine weitere Dimension dazu: der Betriebsrat. Nach BetrVG § 87 hat der Betriebsrat Mitbestimmungsrechte bei der Einführung von KI-Systemen, die Entscheidungen über Arbeitnehmer treffen oder deren Verhalten überwachen. Ohne nachvollziehbare Entscheidungslogik, ohne dokumentierten Human-in-the-Loop, ohne Betriebsvereinbarungen als Systemconstraints wird kein Betriebsrat seine Zustimmung geben.

## Der Elefant im Raum: Shadow AI

<img src="/images/magazin/shadow-ai-eisberg-de.svg" alt="Shadow AI Eisberg: Über der Wasserlinie offizielle KI-Tools mit Governance, unter der Wasserlinie ungeregelter KI-Einsatz ohne Audit Trail" width="800" height="600" loading="lazy" />

Und jetzt der unbequemste Punkt. Die meisten Unternehmen diskutieren über Governance für KI-Tools, die sie offiziell eingeführt haben. Währenddessen nutzen ihre Mitarbeitenden längst ChatGPT, Claude, Copilot und andere Tools für Entscheidungsvorlagen - ohne dass irgendjemand davon weiß.

Die Recruiter nutzen ChatGPT, um Bewerbungen zusammenzufassen. Die Teamleads lassen sich von Copilot Beförderungsvorschläge formulieren. Die L&D-Abteilung erstellt mit KI Leistungsbeurteilungen.

Das alles passiert. Jetzt. Ohne Decision Layer. Ohne Governance Layer. Ohne jede Nachvollziehbarkeit.

Und wenn jemand klagt, ist die Antwort nicht "die KI hat entschieden" - sondern schlimmer: "Wir wussten nicht mal, dass KI entschieden hat."

## Die eigentliche Frage

Die Frage ist nicht: "Sind wir [EU AI Act compliant](/de/magazin/eu-ai-act-hr-hochrisiko/)?"

Die Frage ist: Können wir morgen - in jedem Land, in dem wir operieren - erklären, warum wir heute so entschieden haben?

Wer diese Frage mit Ja beantworten kann, ist automatisch compliant. Mit dem EU AI Act. Mit der DSGVO. Mit EEOC. Mit LGPD. Mit allem, was noch kommt.

Wer sie nicht beantworten kann, hat kein Regulierungsproblem. Sondern ein Governance-Problem.

--- EU AI Act: HR-KI bleibt Hochrisiko - Frist 2026/2027 ---
> HR-KI ist Hochrisiko nach EU AI Act Anhang III. Sechs Pflichtanforderungen, Fristen und wie der Decision Layer sie erfüllt.

Der EU AI Act stuft fast jedes KI-System in HR-Prozessen als Hochrisiko ein. Diese Systeme müssen strenge Anforderungen an Risikomanagement, Transparenz und menschliche Aufsicht erfüllen - nach aktuellem Recht ab dem 2. August 2026, mit vorläufig geeinigter Verschiebung auf Dezember 2027 (Digital Omnibus, Mai 2026).

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Auf einen Blick - HR-KI ist Hochrisiko unter dem EU AI Act</p>
<ul class="text-body text-gosign-text space-y-2">
<li>KI-Systeme für Recruiting, Leistungsbeurteilungen, Beförderungen und Kündigungen werden unter Anhang III, Nr. 4 des EU AI Act als Hochrisiko eingestuft.</li>
<li>Verbotene KI-Praktiken (Social Scoring, Manipulation) gelten seit dem 2. Februar 2025. Vollständige Hochrisiko-Pflichten ab 2. August 2026 - Verschiebung auf 2. Dezember 2027 vorläufig geeinigt (Digital Omnibus, Mai 2026), formale Verabschiedung ausstehend.</li>
<li>Sechs Pflichtanforderungen: Risikomanagement, Datengovernance, Aufzeichnungspflichten, Transparenz, menschliche Aufsicht und Genauigkeit/Robustheit.</li>
<li>Der Decision Layer bildet jede Anforderung architektonisch ab: Confidence Routing für Risiko, versionierte Regelwerke für Datengovernance, Audit Trail für Aufzeichnungen, Human-in-the-Loop für Aufsicht.</li>
<li>Bußgelder bis zu 15 Millionen Euro oder 3% des weltweiten Jahresumsatzes bei Verstößen gegen die Hochrisiko-Pflichten (Art. 99 Abs. 4) - bis zu 35 Millionen Euro oder 7% bei verbotenen KI-Praktiken (Art. 5).</li>
</ul>
</div>

Laut einer PwC-Studie (2024) haben nur 24% der Unternehmen, die KI in HR-Prozessen einsetzen, mit der formalen EU-AI-Act-Compliance begonnen - obwohl die Hochrisiko-Frist (2. August 2026, voraussichtlich verschoben auf Dezember 2027) den Aufbau einer auditierbaren Governance verlangt.

<table>
<thead>
<tr><th>EU AI Act Artikel</th><th>Anforderung</th><th>Decision Layer Umsetzung</th></tr>
</thead>
<tbody>
<tr><td>Art. 9</td><td>Risikomanagementsystem</td><td>Confidence Routing mit konfigurierbaren Schwellenwerten</td></tr>
<tr><td>Art. 10</td><td>Datengovernance</td><td>Versionierte Regelwerke mit Gültigkeitsdaten</td></tr>
<tr><td>Art. 12</td><td>Aufzeichnungspflichten</td><td>Unveränderlicher Audit Trail pro Entscheidung</td></tr>
<tr><td>Art. 13</td><td>Transparenz</td><td>Auditor Portal mit vollständigem Entscheidungspfad</td></tr>
<tr><td>Art. 14</td><td>Menschliche Aufsicht</td><td>Erzwungener Human-in-the-Loop für definierte Typen</td></tr>
<tr><td>Art. 15</td><td>Genauigkeit und Robustheit</td><td>Bias Monitoring und modell-agnostisches Design</td></tr>
<tr><td>Art. 86</td><td>Recht auf Erläuterung der Einzelentscheidung</td><td>Entscheidungsakt pro Mikroentscheidung mit Anfechtungspfad</td></tr>
</tbody>
</table>

## Die Einstufung: HR-KI ist Hochrisiko

Der EU AI Act stuft KI-Systeme die in Beschäftigung, Personalmanagement und Zugang zu selbstständiger Erwerbstätigkeit eingesetzt werden, als Hochrisiko ein (Anhang III, Nr. 4). Das betrifft konkret:

KI-Systeme für Recruiting und Bewerberauswahl. KI-Systeme die Einfluss auf Beförderung, Kündigung, Aufgabenzuweisung oder Leistungsüberwachung haben. KI-Systeme die Arbeitsbedingungen beeinflussen - einschließlich Gehaltsanpassungen, Eingruppierungen und Schichtplanung.

Kurz: Fast jeder KI-Agent, der in HR-Prozessen Entscheidungen vorbereitet, unterstützt oder trifft, fällt unter die Hochrisiko-Kategorie.

## Die Fristen

Seit dem 2. Februar 2025 gelten die Verbote für inakzeptable KI-Praktiken - darunter Social Scoring und manipulative Techniken. Die vollständigen Pflichten für Hochrisiko-KI-Systeme greifen nach aktuellem Recht ab dem 2. August 2026. Nach der vorläufigen Digital-Omnibus-Einigung vom 7. Mai 2026 sollen sie sich auf den 2. Dezember 2027 verschieben - die formale Verabschiedung im EU-Amtsblatt steht aber noch aus, sodass bis dahin der August 2026 gilt. Die Einstufung als Hochrisiko bleibt in jedem Fall bestehen: Der Aufbau auditierbarer Governance-Strukturen lohnt sich unabhängig vom genauen Stichtag, und die voraussichtlich gewonnene Zeit sollte dafür genutzt werden.

## Was konkret gefordert wird - und wie der Decision Layer es erfüllt

Die folgenden Anforderungen gelten für jeden Betreiber eines Hochrisiko-KI-Systems im HR-Bereich:

**Artikel 9 - Risikomanagementsystem:**
Der EU AI Act fordert ein kontinuierliches Risikomanagementsystem das Risiken identifiziert, bewertet und mindert. Im Decision Layer wird das durch Confidence Routing umgesetzt: Jede Agenten-Entscheidung wird automatisch nach Konfidenz und Risikokategorie bewertet. Hohes Risiko oder niedrige Konfidenz führt zur Eskalation an einen Menschen. Die Schwellenwerte sind konfigurierbar und dokumentiert.

**Artikel 10 - Datengovernance:**
Versionierte Regelwerke im Decision Layer stellen sicher, dass die Datengrundlage jeder Entscheidung nachvollziehbar ist. Tarifverträge, Betriebsvereinbarungen und Compliance-Regeln haben Versionen, Gültigkeitsdaten und Geltungsbereiche. Bei einer Prüfung ist nachvollziehbar, welches Regelwerk in welcher Version zum Entscheidungszeitpunkt galt.

**Artikel 12 - Aufzeichnungspflichten:**
Der Audit Trail im Decision Layer erzeugt für jede Entscheidung einen vollständigen, unveränderlichen Datensatz: Input, Modell, Regelwerk, Konfidenz, Routing-Entscheidung, Ergebnis, Zeitstempel. Automatisch, nicht nachträglich zusammengestellt.

**Artikel 13 - Transparenz:**
Jede Agenten-Entscheidung ist im Auditor Portal nachvollziehbar. Betriebsräte, Datenschutzbeauftragte und Prüfer können den Entscheidungspfad einsehen. Keine Blackbox.

**Artikel 14 - Menschliche Aufsicht:**
Human-in-the-Loop ist im Decision Layer ein Architekturprinzip, nicht eine optionale Einstellung. Bei definierten Entscheidungstypen - Diskriminierungspotenzial, Mitbestimmungsthemen, Wertgrenzen - erzwingt die Architektur menschliche Prüfung. Ein Agent kann diese Prüfung nicht umgehen.

**Artikel 15 - Genauigkeit, Robustheit und Cybersicherheit:**
Bias Monitoring prüft systematisch auf diskriminierende Muster. Konfidenz-Schwellenwerte stellen sicher, dass der Agent nur bei ausreichender Sicherheit autonom entscheidet. Modell-Agnostik ermöglicht den Wechsel des Sprachmodells ohne Änderung der Governance-Logik.

**Artikel 86 - Recht auf Erläuterung:**
Über die sechs Betreiber-Pflichten hinaus gibt Art. 86 jeder betroffenen Person einen Anspruch auf Erläuterung der einzelnen Entscheidung - nicht des Systems im Allgemeinen, sondern dieses einen Falls. Diese Frage lässt sich nur über einen Entscheidungsakt pro Mikroentscheidung beantworten: Input, angewandte Fachregel samt Version, Konfidenz, Ergebnis und Anfechtungspfad. Der Decision Layer erzeugt diesen Akt im Moment der Entscheidung und macht den Art.-86-Anspruch damit pro Einzelfall erfüllbar.

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Kostenloses eBook: KI in HR</p>
<p class="text-body text-gosign-text mb-4">EU AI Act Checkliste, Decision-Framework, Betriebsrats-Perspektive und Readiness-Assessment - das Governance-Handbuch für HR-Verantwortliche.</p>
<a href="/de/ebook/ki-hr-governance-handbuch/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Jetzt kostenlos herunterladen</a>
</div>

## Was das für HR-Abteilungen bedeutet

Unternehmen die heute KI in HR-Prozessen einsetzen oder einsetzen wollen, müssen Governance-Strukturen aufbauen - maßgeblich ist nach aktuellem Recht der 2. August 2026, voraussichtlich verschoben auf Dezember 2027. Das bedeutet konkret:

Dokumentierte Entscheidungslogik für jeden KI-gestützten HR-Prozess. Technisch erzwungene Human-in-the-Loop-Mechanismen für Entscheidungen mit Personalbezug. Prüfungssichere Audit Trails die nachvollziehbar machen, wie jede Entscheidung zustande kam. Bias-Monitoring das diskriminierende Muster erkennt und meldet.

In Deutschland kommen die Anforderungen des Betriebsverfassungsgesetzes hinzu: Betriebsräte haben ein Mitbestimmungsrecht bei technischen Einrichtungen die das Verhalten oder die Leistung von Arbeitnehmern überwachen (§ 87 Abs. 1 Nr. 6 BetrVG). KI-Agenten in HR-Prozessen fallen unter diese Kategorie.

Der Decision Layer adressiert beide Anforderungsblöcke - EU AI Act und deutsches Mitbestimmungsrecht - in einer Architektur.

→ [Decision Layer im Detail](/de/magazin/decision-layer-erklaert/)

→ [Entscheidungsakt: Warum jede KI-Entscheidung anfechtbar sein muss](/de/magazin/entscheidungsakt-anfechtbare-ki-entscheidungen/)

→ [Mitbestimmung und Betriebsrat](/de/governance/mitbestimmung/)

→ [HR Agent](/de/hr-ai-agents/)

<a href="/de/kontakt/" target="_blank" rel="noopener noreferrer">Termin vereinbaren</a> - Wir zeigen Ihnen, welche Ihrer HR-Prozesse unter die Hochrisiko-Kategorie fallen und wie der Decision Layer die Anforderungen erfüllt.

--- EU AI Act und HR - Was jetzt Pflicht ist ---
> EU AI Act klassifiziert HR-Prozesse als Hochrisiko. Bias-Monitoring, Human Oversight, Transparenz sind Pflicht. Was jetzt zu tun ist.

Der EU AI Act klassifiziert KI in Personalentscheidungen als Hochrisiko. Von der Risikoklassifizierung über Bias-Monitoring bis Human Oversight - das sind jetzt gesetzliche Anforderungen, keine optionalen Features.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Auf einen Blick - EU AI Act Pflichten für HR</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Jedes KI-System, das HR-Entscheidungen beeinflusst - Recruiting, Leistungsbeurteilung, Vergütung, Beförderung - ist Hochrisiko nach Anhang III des EU AI Act.</li>
<li>Vier Kernanforderungen: Risikokategorisierung jedes KI-Systems, verpflichtendes Bias-Monitoring, erzwungene menschliche Aufsicht und vollständige Transparenz mit Dokumentation.</li>
<li>Typische Fehler: retroaktive Compliance statt Governance by Design, KI-Tools als "nur unterstützend" deklarieren und den Betriebsrat zu spät einbinden.</li>
<li>Der richtige Ansatz ist Architecture-First: Der Decision Layer zerlegt jeden HR-Prozess in einzelne Entscheidungsschritte mit Logging, Versionierung und Human-in-the-Loop ab Tag 1.</li>
<li>Bußgelder bis 35 Millionen Euro oder 7% des weltweiten Jahresumsatzes. Hochrisiko-Pflichten gelten ab 2. August 2026 - Verschiebung auf 2. Dezember 2027 vorläufig geeinigt (Digital Omnibus, Mai 2026), formale Verabschiedung ausstehend.</li>
</ul>
</div>

Das Europäische Parlament (2024) schätzt, dass HR und Beschäftigung die größte Einzelkategorie von Hochrisiko-KI-Anwendungen unter dem EU AI Act darstellen und schätzungsweise 85% der Großunternehmen betreffen, die KI in Recruiting oder Personalmanagement einsetzen.

<table>
<thead>
<tr><th>HR-Prozess</th><th>EU AI Act Klassifizierung</th><th>Kernanforderung</th></tr>
</thead>
<tbody>
<tr><td>CV-Screening / Recruiting</td><td>Hochrisiko (Anhang III)</td><td>Bias-Monitoring, Audit Trail</td></tr>
<tr><td>Leistungsbeurteilung</td><td>Hochrisiko (Anhang III)</td><td>Menschliche Aufsicht, Transparenz</td></tr>
<tr><td>Beförderungsentscheidungen</td><td>Hochrisiko (Anhang III)</td><td>Erklärbarkeit, Human-in-the-Loop</td></tr>
<tr><td>Schichtplanung (mit Personaldaten)</td><td>Potenziell Hochrisiko</td><td>Risikobewertung, Datengovernance</td></tr>
<tr><td>Compliance Knowledge Agent</td><td>Begrenztes Risiko</td><td>Transparenzpflicht</td></tr>
</tbody>
</table>

## Der EU AI Act und HR: Warum das relevant ist

Der EU AI Act (Verordnung (EU) 2024/1689) ist seit August 2024 in Kraft. Er reguliert KI-Systeme nach ihrem Risiko. Für HR-Abteilungen ist die Einstufung eindeutig: KI-Systeme die für Entscheidungen über natürliche Personen im Beschäftigungskontext eingesetzt werden, gelten als Hochrisiko-Systeme (Annex III, Punkt 4).

Das betrifft nicht nur automatisierte Recruiting-Software. Es betrifft jeden KI-Einsatz, der Einfluss auf Personalentscheidungen hat: Bewerbungsscreening, Leistungsbeurteilung, Gehaltsvorschläge, Beförderungsempfehlungen, Schichtplanung mit KI-Optimierung, automatisierte Arbeitszeugniserstellung.

Die Pflichten für Hochrisiko-Systeme gelten nach aktuellem Recht ab dem [2. August 2026](/de/magazin/eu-ai-act-2026-unternehmen/); nach der vorläufigen Digital-Omnibus-Einigung vom 7. Mai 2026 sollen sie sich auf den 2. Dezember 2027 verschieben (formale Verabschiedung ausstehend). Das gibt Unternehmen voraussichtlich zusätzliche Zeit zur Vorbereitung - aber die Architekturentscheidungen müssen jetzt getroffen werden, denn die Hochrisiko-Einstufung bleibt bestehen.

## Was der EU AI Act konkret verlangt

Für Hochrisiko-KI-Systeme im HR-Bereich verlangt der EU AI Act:

**Risikomanagement-System (Art. 9):** Ein kontinuierliches Risikomanagement über den gesamten Lebenszyklus des KI-Systems. Identifikation von Risiken, Bewertung, Maßnahmen, Überprüfung. Das ist kein einmaliges Assessment, sondern ein laufender Prozess.

**Datenqualität (Art. 10):** Die Trainings-, Validierungs- und Testdaten müssen relevant, repräsentativ, fehlerfrei und vollständig sein. Für HR bedeutet das: Wenn ein Agent auf historischen Personalentscheidungen trainiert wird, müssen diese Daten auf Bias geprüft werden. Historische Diskriminierung in den Daten wird sonst vom KI-System reproduziert.

**Technische Dokumentation (Art. 11):** Vollständige Dokumentation des KI-Systems vor Inbetriebnahme. Zweck, Funktionsweise, Leistungskennzahlen, Grenzen, Risiken. Diese Dokumentation muss aktuell gehalten werden.

**Aufbewahrung von Logs (Art. 12):** Automatische Protokollierung aller Ereignisse über die gesamte Lebensdauer des Systems. Im HR-Kontext: Jede Entscheidung, jede Empfehlung, jede Eskalation.

**Human Oversight (Art. 14):** Menschliche Aufsicht muss gewährleistet sein. Der Mensch muss die Fähigkeiten und Grenzen des Systems verstehen, die Ergebnisse interpretieren können und die Möglichkeit haben, einzugreifen oder das System abzuschalten.

**Bias-Monitoring:** Der EU AI Act verlangt, dass Hochrisiko-Systeme auf Verzerrungen überwacht werden. Für HR-Entscheidungen bedeutet das: Statistische Auswertung über alle Agenten-Entscheidungen. Werden bestimmte Gruppen systematisch anders behandelt?

**Transparenz (Art. 13):** Betroffene Personen müssen darüber informiert werden, dass KI-Systeme bei Entscheidungen über sie eingesetzt werden.

## Was das für die Architektur bedeutet

Die Anforderungen des EU AI Act sind keine organisatorischen Maßnahmen. Sie sind Architekturanforderungen. Ein KI-System das diese Anforderungen nachträglich erfüllen soll, muss grundlegend umgebaut werden.

**Decision Layer:** Der [Decision Layer](/de/decision-layer/) zerlegt jeden HR-Prozess in einzelne Entscheidungsschritte und definiert für jeden Schritt: Mensch, Regelwerk oder KI. Die Rules Engine implementiert die versionierten Regelwerke. Das Confidence Routing stellt die Risikobewertung sicher. Der Human-in-the-Loop-Mechanismus gewährleistet die menschliche Aufsicht. Der Audit Trail erfüllt die Log-Aufbewahrungspflicht.

**Bias-Monitoring:** Über den Decision Layer werden alle Agenten-Entscheidungen statistisch ausgewertet. Abweichungen von erwarteten Verteilungen werden erkannt und eskaliert. Das ist kein manueller Review-Prozess, sondern eine automatisierte Überwachung.

**Auditor Portal:** Die technische Dokumentation und die Evidence sind im Auditor Portal jederzeit einsehbar. Prüfer - intern oder extern - sehen den Live-Status aller Kontrollen.

## Zeitplan: Was jetzt passieren muss

**Sofort:** Bestandsaufnahme aller KI-Systeme im HR-Bereich. Auch solche, die nicht als "KI" gebrandmarkt sind: Scoring-Algorithmen in Recruiting-Software, KI-basierte Schichtplanung, automatisierte Textgenerierung.

**Bis Q3 2026:** Risikomanagement-System aufsetzen. Architekturentscheidungen treffen. Governance-Infrastruktur implementieren.

**Ab 2. August 2026 (voraussichtlich verschoben auf 2. Dezember 2027):** Hochrisiko-Systeme müssen die Anforderungen des EU AI Act vollständig erfüllen. Die Verschiebung ist seit dem 7. Mai 2026 vorläufig geeinigt (Digital Omnibus), aber erst mit Veröffentlichung im EU-Amtsblatt verbindlich.

In Deutschland kommen die Anforderungen des Betriebsverfassungsgesetzes hinzu: Betriebsräte haben ein Mitbestimmungsrecht bei technischen Einrichtungen die das Verhalten oder die Leistung von Arbeitnehmern überwachen (§ 87 Abs. 1 Nr. 6 BetrVG). KI-Agenten in HR-Prozessen fallen unter diese Kategorie. Der Decision Layer adressiert beide Anforderungsblöcke - EU AI Act und deutsches Mitbestimmungsrecht - in einer Architektur.

Unternehmen die jetzt KI-Agenten für HR-Prozesse einführen, sollten die Architektur von Anfang an EU AI Act-compliant gestalten. Nachträgliche Compliance ist technisch möglich, aber deutlich aufwendiger und teurer.

Mehr dazu: [EU AI Act Readiness](/de/governance/eu-ai-act/)

<a href="/de/kontakt/" target="_blank" rel="noopener noreferrer">Termin vereinbaren</a> - Wir zeigen Ihnen, wie Ihre HR-KI EU AI Act-compliant wird.

--- Human-in-the-Loop - Architekturprinzip, nicht Checkbox ---
> Human-in-the-Loop bei KI-Agenten: architektonisch erzwungene menschliche Prüfung. Confidence Routing, Eskalationsregeln, Bias-Checks.

## Das Problem: HITL als Marketing-Behauptung

Fast jeder KI-Anbieter behauptet, seine Lösung habe "Human-in-the-Loop". In der Praxis bedeutet das oft: Irgendwo im Prozess gibt es einen Freigabe-Button. Ein Mensch kann draufklicken. Muss aber nicht.

Das ist kein Human-in-the-Loop. Das ist eine optionale Freigabe, die unter Zeitdruck wegfällt. Wenn der Sachbearbeiter 200 Belege am Tag verarbeitet und 195 davon korrekt sind, wird er irgendwann alle durchwinken.

Echtes Human-in-the-Loop ist ein Architekturprinzip. Es bedeutet: Bei definierten Entscheidungstypen kann der Agent physisch nicht autonom handeln. Der Workflow pausiert. Das Zielsystem wird nicht angesprochen. Erst nach menschlicher Prüfung und dokumentierter Freigabe geht der Prozess weiter.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Auf einen Blick - Human-in-the-Loop Architektur</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Echtes HITL ist ein Architekturprinzip, kein optionaler Freigabe-Button - der Agent kann die menschliche Prüfung bei definierten Entscheidungstypen physisch nicht umgehen.</li>
<li>Drei Auslöser: niedriger Konfidenzwert, Hochrisiko-Klassifizierung (Diskriminierung, Mitbestimmung) und erstmalige Anwendung neuer Regeln.</li>
<li>Der EU AI Act verlangt effektive menschliche Aufsicht für Hochrisiko-KI-Systeme - HR-Prozesse fallen explizit in diese Kategorie.</li>
<li>Betriebsvereinbarungen werden zu technischen Constraints im Decision Layer, die das System nicht umgehen kann.</li>
<li>HITL löst nicht Bias in Trainingsdaten und skaliert nicht linear - es ist ein Baustein neben Audit Trail, Bias-Monitoring und Cert-Ready Controls.</li>
</ul>
</div>

Laut Europäischer Kommission (2024) ist menschliche Aufsicht für alle Hochrisiko-KI-Systeme unter dem EU AI Act verpflichtend, und HR-Prozesse sind explizit in Anhang III gelistet - was architektonisch erzwungenes Human-in-the-Loop zur rechtlichen Notwendigkeit macht, nicht zur Designentscheidung.

| HITL-Auslöser | Beschreibung | Konfigurierbar |
|---|---|---|
| Niedriger Konfidenzwert | Unsicherheit des Agenten unter definiertem Schwellenwert | Ja, mandantenspezifisch |
| Diskriminierungsrisiko | Entscheidungen mit diskriminierendem Ergebnispotenzial | Immer eskaliert |
| Mitbestimmungsthemen | Entscheidungen unter Betriebsrats-Aufsicht | Immer eskaliert |
| Wertgrenzenüberschreitung | Betrag über definierter Grenze für autonome Verarbeitung | Ja, mandantenspezifisch |
| Neue Regeleinführung | Erstmalige Anwendung eines neuen Regelwerks | Während der Lernphase |

## HITL als technisches Architekturprinzip

In der Gosign-Architektur ist Human-in-the-Loop im Decision Layer implementiert. Die Entscheidung, wann ein Mensch einbezogen wird, basiert auf drei Kriterien:

**Confidence Routing:** Jede Agenten-Entscheidung hat einen Konfidenzwert. Liegt die Konfidenz unter dem definierten Schwellenwert, wird automatisch eskaliert. Der Schwellenwert ist mandantenspezifisch konfigurierbar.

**Risiko-Klassifizierung:** Bestimmte Entscheidungstypen werden unabhängig von der Konfidenz immer eskaliert. Entscheidungen mit Diskriminierungspotenzial, Mitbestimmungsthemen, Wertgrenzenüberschreitungen.

**Regelbasierte Pflicht-Eskalation:** Neue Regelwerke, die erstmals angewandt werden, durchlaufen immer eine menschliche Prüfung in der Einführungsphase. Erst nach validierter Lernphase wechselt der Agent in den autonomen Modus - für genau diese Regel.

Die Human-in-the-Loop-Anforderung ist technisch erzwungen. Es gibt keinen Workaround, keine Abkürzung, keinen Admin-Override. Der Agent kann die Eskalation nicht umgehen.

## Wie HITL in der Praxis aussieht

Ein HR-Agent verarbeitet einen Antrag auf Sonderzahlung. Der Document Agent liest den Antrag. Der Knowledge Agent prüft die geltende Betriebsvereinbarung. Der Decision Layer bewertet:

Ergebnis: Sonderzahlung genehmigungsfähig laut Betriebsvereinbarung § 12, Abs. 3. Konfidenz: 94%. Risiko: niedrig.

Aber: Die Entscheidung berührt eine Vergütungskomponente. In der HITL-Konfiguration ist definiert: Vergütungsentscheidungen werden immer eskaliert, unabhängig von der Konfidenz. Der Workflow pausiert.

Der zuständige Sachbearbeiter sieht im Dashboard: Den Antrag, den Vorschlag des Agenten, die angewandte Regel in der aktuellen Version, den Konfidenzwert, den Eskalationsgrund. Er prüft, bestätigt oder korrigiert. Seine Entscheidung wird im Audit Trail dokumentiert - inklusive der Information, dass es sich um eine Human-in-the-Loop-Entscheidung handelt.

## HITL und Betriebsrat

Human-in-the-Loop ist die technische Antwort auf eine organisatorische Anforderung: Mitbestimmung. Betriebsräte haben bei der Einführung von KI-Systemen Mitbestimmungsrechte nach § 87 Abs. 1 Nr. 6 BetrVG (technische Überwachungseinrichtungen) und nach § 90 BetrVG (Gestaltung von Arbeitsplätzen).

Der Decision Layer macht Betriebsvereinbarungen zu technischen Constraints. Wenn eine Betriebsvereinbarung sagt: "Entscheidungen über Leistungsbeurteilungen dürfen nicht vollautomatisiert getroffen werden" - dann wird das als HITL-Regel im Decision Layer implementiert. Der Agent kann diese Regel nicht umgehen.

Das Ergebnis: Der Betriebsrat kann nachvollziehen, dass seine Anforderungen technisch durchgesetzt werden - nicht nur organisatorisch zugesagt.

## HITL und EU AI Act

Der EU AI Act verlangt für Hochrisiko-KI-Systeme menschliche Aufsicht (Human Oversight, Art. 14). HR-Prozesse fallen explizit unter die Hochrisiko-Kategorie: Recruiting, Performance Reviews, Beförderungsentscheidungen, Vergütung, Kündigung.

Human-in-the-Loop als Architekturprinzip erfüllt die Anforderungen des EU AI Act an Human Oversight. Es ist nicht ausreichend, einen Menschen im Prozess zu haben, der theoretisch eingreifen könnte. Der EU AI Act verlangt effektive menschliche Aufsicht - das bedeutet: Der Mensch muss die Entscheidung verstehen können, er muss sie stoppen können, und seine Intervention muss dokumentiert werden.

Der Decision Layer dokumentiert bei jeder HITL-Entscheidung: Wer hat geprüft? Wann? Was war der Agent-Vorschlag? Was war die menschliche Entscheidung? Stimmen sie überein oder weichen sie ab?

## Die Grenze: Was HITL nicht löst

Human-in-the-Loop ist keine Lösung für alle Governance-Probleme. Konkret:

HITL löst nicht das Problem von Bias in Trainingsdaten. Wenn das Sprachmodell systematisch voreingenommen ist, erkennt ein Sachbearbeiter das nicht an Einzelfällen. Dafür braucht es statistisches Bias-Monitoring über alle Agenten-Entscheidungen hinweg.

HITL skaliert nicht linear. Wenn der Agent 10.000 Entscheidungen pro Tag trifft und 20% eskaliert werden, braucht man Ressourcen für 2.000 manuelle Prüfungen. Die HITL-Schwellenwerte müssen so kalibriert werden, dass die Eskalationsrate handhabbar bleibt, ohne die Governance zu kompromittieren.

HITL ist ein Baustein der [Governance](/de/governance/)-Architektur - zusammen mit Audit Trail, Bias-Monitoring, Regelwerk-Versionierung und Cert-Ready Controls.

Mehr dazu: [Mitbestimmung und KI](/de/governance/mitbestimmung/)

<a href="/de/kontakt/" target="_blank" rel="noopener noreferrer">Termin vereinbaren</a> - Wir zeigen Ihnen, wie Human-in-the-Loop in Ihrer Architektur aussieht.

--- Betriebsrat & AI Literacy: Die Organisationsfragen ---
> Warum KI-Projekte an Organisation scheitern, nicht an Technologie. Mitbestimmung als Designanforderung und Schulungspflicht seit 2025.

## Technik ist selten das Problem

Wenn KI-Projekte in Unternehmen scheitern, liegt das in den seltensten Fällen an der Technologie. Die Modelle funktionieren. Die APIs sind stabil. Die Infrastruktur ist verfügbar. Was scheitert, ist die Organisation: Der Betriebsrat blockiert die Einführung, weil er zu spät informiert wurde. Mitarbeitende nutzen die neuen Werkzeuge nicht, weil sie nicht geschult wurden.

Dieser Artikel behandelt die zwei Organisationsfragen, die jede KI-Einführung begleiten: Wie gewinnen Sie den Betriebsrat als Unterstützer? Und wie erfüllen Sie die gesetzliche AI-Literacy-Pflicht?

Der EU AI Act (Artikel 4) schreibt seit Februar 2025 AI Literacy für alle Nutzer von KI-Systemen vor. Bußgelder bei Verstößen: bis zu 35 Mio. EUR oder 7 % des Jahresumsatzes.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Auf einen Blick - Betriebsrat & AI Literacy</p>
<ul class="text-body text-gosign-text space-y-2">
<li>KI-Projekte scheitern an der Organisation, nicht an der Technologie. Betriebsrat und AI Literacy sind die beiden entscheidenden Faktoren.</li>
<li>Beteiligen Sie den Betriebsrat in der Architekturphase, nicht bei der Ergebnispräsentation. Ein Decision Layer macht KI transparent und auditierbar by Design.</li>
<li>AI Literacy ist seit Februar 2025 gesetzlich vorgeschrieben (EU AI Act, Artikel 4). Bußgelder bei Verstößen: bis zu 35 Mio. EUR oder 7 % des Umsatzes.</li>
<li>Eine Betriebsvereinbarung wird durchsetzbar, wenn ihre Regeln als technische Constraints im Decision Layer implementiert werden.</li>
<li>Rollenbasierte Schulungsprogramme verwandeln Compliance-Pflichten in Wettbewerbsvorteile: informierte Mitarbeitende nutzen KI effektiver.</li>
</ul>
</div>

## Betriebsrat und Mitbestimmung: vom Blocker zum Enabler

### Warum der Betriebsrat mitbestimmen muss

In deutschen Unternehmen hat der Betriebsrat bei jeder technischen Einrichtung, die geeignet ist, das Verhalten oder die Leistung der Arbeitnehmer zu überwachen, ein Mitbestimmungsrecht nach § 87 Abs. 1 Nr. 6 BetrVG. KI-Systeme fallen fast immer darunter: Sie verarbeiten Nutzungsdaten, protokollieren Interaktionen, und ihre Entscheidungen betreffen direkt oder indirekt die Arbeitsbedingungen.

Das ist kein Hindernis, sondern ein Gestaltungsrahmen. Der Betriebsrat hat nicht das Recht, KI zu verhindern, er hat das Recht, die Bedingungen ihrer Einführung mitzugestalten. Das ist ein Unterschied, der in der Praxis oft übersehen wird.

Das Problem entsteht nicht durch die Mitbestimmung selbst, sondern durch den Zeitpunkt, zu dem der Betriebsrat einbezogen wird. In den meisten gescheiterten KI-Projekten wird der Betriebsrat erst informiert, wenn die technische Entscheidung bereits gefallen ist. Er erhält eine Präsentation mit fertigen Ergebnissen, hat keine Möglichkeit, die Architektur zu beeinflussen, und reagiert mit dem einzigen Mittel, das ihm bleibt: Ablehnung.

### Architektur als Antwort

Die Fragen des Betriebsrats sind berechtigt und vorhersehbar: Welche Daten verarbeitet das KI-System? Wer hat Zugriff? Werden Leistungsdaten erfasst? Wer trifft die finale Entscheidung, die KI oder ein Mensch? Können Entscheidungen nachvollzogen werden?

Ein [Decision Layer](/de/decision-layer/) beantwortet diese Fragen technisch, nicht nur in einer Betriebsvereinbarung auf Papier. Die Architekturschicht definiert:

- **Entscheidungsgrenzen:** Was darf die KI vorbereiten, was entscheidet ein Regelwerk, was muss ein Mensch freigeben.
- **Human-in-the-Loop:** Technisch erzwungene menschliche Freigabe bei definierten Entscheidungsklassen. Kein Mensch kann umgangen werden, weil die Architektur es nicht zulässt.
- **Audit-Trail:** Jede KI-Entscheidung wird protokolliert: welches Modell, welche Eingabe, welche Ausgabe, welche Regel angewendet, ob ein Mensch beteiligt war.
- **Zugriffssteuerung (RBAC):** Rollenbasierte Zugriffsrechte verhindern, dass Unbefugte auf sensible Daten oder Funktionen zugreifen.

### Betriebsvereinbarungen als System-Constraints

Der entscheidende Vorteil einer durchdachten KI-Architektur: Betriebsvereinbarungen werden nicht nur auf Papier festgehalten, sondern als technische Regeln im System implementiert.

**Erstens: Firmenvereinbarungen als konfigurierbare Regelwerke.** Was in der Betriebsvereinbarung steht, etwa „Leistungsdaten dürfen nicht ohne Einwilligung des Mitarbeitenden ausgewertet werden", wird als Constraint im Decision Layer implementiert. Das System kann die Vereinbarung nicht umgehen, weil die Regel technisch durchgesetzt wird.

**Zweitens: Transparenz durch lückenlosen Audit-Trail.** Der Betriebsrat kann jederzeit nachvollziehen, welche Entscheidungen das KI-System getroffen hat, auf welcher Grundlage und ob menschliche Freigaben erteilt wurden. Keine Blackbox, keine Vertrauensfrage.

**Drittens: RBAC verhindert unkontrollierten Zugriff.** Nur definierte Rollen haben Zugriff auf bestimmte KI-Funktionen. Ein Teamleiter kann den Chatbot nutzen, aber nicht die Leistungsanalyse. Ein HR-Manager kann die Leistungsanalyse einsehen, aber nicht die Rohdaten exportieren. Die Rechte sind granular konfigurierbar.

**Viertens: Kein Profiling ohne explizite Genehmigung.** Die Architektur stellt technisch sicher, dass personenbezogene Auswertungen nur mit expliziter Genehmigung, konfiguriert im Regelwerk, durchgeführt werden können.

### Praxis-Empfehlung: Der Architektur-Workshop

Laden Sie den Betriebsrat zum Architektur-Workshop ein, nicht zum Ergebnis-Meeting. Ein halber Tag, an dem der Betriebsrat versteht, wie der Decision Layer funktioniert, welche Daten verarbeitet werden und wie Betriebsvereinbarungen technisch umgesetzt werden, spart Monate an Verhandlungen.

Die Erfahrung zeigt: Wenn der Betriebsrat die Architektur versteht und sieht, dass seine Anliegen nicht nur gehört, sondern technisch implementiert werden, wird er vom potenziellen Blocker zum aktiven Unterstützer. Der Betriebsrat will nicht KI verhindern. Er will sicherstellen, dass die Rechte der Beschäftigten gewahrt bleiben. Eine transparente Architektur gibt ihm genau diese Sicherheit.

## AI Literacy: gesetzliche Pflicht seit Februar 2025

### Die rechtliche Grundlage

Artikel 4 des [EU AI Act](/de/magazin/eu-ai-act-2026-unternehmen/) verpflichtet alle Anbieter und Betreiber von KI-Systemen, dafür zu sorgen, dass ihre Mitarbeitenden über ein ausreichendes Maß an KI-Kompetenz verfügen. Die Pflicht gilt seit dem 2. Februar 2025 und betrifft jedes Unternehmen, das KI einsetzt, unabhängig von der Größe und unabhängig von der Risikoklasse des KI-Systems.

Die Formulierung „ausreichendes Maß an KI-Kompetenz" ist bewusst offen gehalten. Sie muss kontextangemessen interpretiert werden: Ein Vorstandsmitglied, das über den Einsatz eines KI-Systems entscheidet, braucht andere Kompetenzen als ein Sachbearbeiter, der einen Chatbot nutzt. Aber beide brauchen Kompetenzen. Und beide Kompetenzen müssen dokumentiert sein.

**Sanktionen:** Verstöße gegen die AI-Literacy-Pflicht fallen unter die allgemeinen Sanktionsbestimmungen des EU AI Act. Die Höchststrafen betragen bis zu 35 Millionen Euro oder 7 Prozent des weltweiten Jahresumsatzes. In der Praxis ist davon auszugehen, dass bei reinen Literacy-Verstößen zunächst Verwarnungen und Anordnungen ausgesprochen werden, aber die rechtliche Grundlage für empfindliche Strafen besteht.

### Wer muss geschult werden?

Alle Personen, die KI-Systeme in irgendeiner Form nutzen, betreiben oder darüber entscheiden. Das umfasst:

- Vorstand und Geschäftsführung (Entscheidungsverantwortung)
- Abteilungsleiter und Teamleads (Nutzungsverantwortung)
- Fachkräfte und Sachbearbeiter (operative Nutzung)
- IT und Entwicklung (technischer Betrieb)
- Betriebsrat (Mitbestimmungsverantwortung)

### Was muss geschult werden?

Die Inhalte müssen kontextangemessen sein. Als Minimum empfehlen sich vier Kompetenzfelder:

1. **Grundverständnis der KI-Funktionsweise:** Wie funktioniert ein Sprachmodell? Was ist der Unterschied zwischen Analyse und Entscheidung? Was kann KI, was kann sie nicht?
2. **Erkennung von Halluzinationen:** Sprachmodelle generieren plausibel klingende, aber faktisch falsche Aussagen. Nutzer müssen in der Lage sein, Ergebnisse kritisch zu prüfen.
3. **Verantwortungsvoller Umgang:** Welche Daten dürfen eingegeben werden? Welche nicht? Was passiert mit den Eingaben? Wo liegen die Grenzen der Nutzung?
4. **Datenschutz:** Welche personenbezogenen Daten dürfen verarbeitet werden? Welche Einwilligungen sind erforderlich? Welche Daten verlassen das Unternehmensnetzwerk?

### Wie weisen Sie Compliance nach?

Der EU AI Act verlangt den Nachweis, dass Schulungen stattgefunden haben. Das bedeutet:

- Dokumentation der Schulungsinhalte und -materialien
- Teilnehmerlisten mit Datum und Unterschrift
- Regelmäßige Auffrischung (empfohlen: jährlich, bei wesentlichen Systemänderungen anlassbezogen)
- Differenzierung nach Rollen und Verantwortlichkeiten

Ein pauschales 30-Minuten-Webinar erfüllt die Anforderungen nicht. Die Schulung muss rollenbezogen sein, die spezifischen KI-Systeme des Unternehmens adressieren und interaktive Elemente enthalten, die das Verständnis überprüfbar machen.

## Praxis-Empfehlung: Enterprise-AI-Portal als Kompetenzentwicklung

Das [Enterprise-AI-Portal](/de/magazin/enterprise-ki-chat-interface/) ist nicht nur ein Produktivitätswerkzeug, es ist auch das effektivste Instrument für den Kompetenzaufbau. Mitarbeitende, die täglich mit einem kontrollierten KI-System arbeiten, entwickeln die in der AI-Literacy-Pflicht geforderten Kompetenzen durch die Praxis: Sie lernen, Ergebnisse kritisch zu prüfen. Sie verstehen, welche Eingaben gute Ergebnisse liefern und welche nicht. Sie entwickeln ein Gespür für die Grenzen der Technologie.

Das ersetzt keine formale Schulung. Aber es ergänzt sie um den wichtigsten Faktor: tägliche Anwendung. Ein Unternehmen, das seinen Mitarbeitenden ein gutes internes KI-Portal zur Verfügung stellt, investiert gleichzeitig in Compliance (AI-Literacy-Pflicht) und Produktivität.

## Fazit: Organisation entscheidet

Die zwei Organisationsfragen, Mitbestimmung und Kompetenz, sind keine Nebenaspekte der KI-Einführung. Sie sind die Hauptaspekte. Die Technologie ist verfügbar, bezahlbar und leistungsfähig. Die Frage ist, ob Ihre Organisation in der Lage ist, sie zu nutzen.

Ein Betriebsrat, der die Architektur versteht, wird zum Unterstützer. Mitarbeitende, die geschult sind, nutzen die Werkzeuge produktiv. Und eine Organisation, die beide Fragen proaktiv beantwortet, gewinnt einen Wettbewerbsvorteil, den kein Modell-Upgrade ersetzen kann.

Weiterführend: [Decision Layer](/de/decision-layer/) | [Governance](/de/governance/) | [HR & AI Agents](/de/hr-ai-agents/) | [Decision Layer & Shadow AI](/de/magazin/decision-layer-shadow-ai/)

---

**📘 Enterprise AI-Infrastruktur Blueprint 2026 - Artikel-Serie**

| ← Vorheriger | Übersicht | Nächster → |
|:---|:---:|---:|
| [EU AI Act 2026: Was jetzt gilt, was kommt, was Sie tun müssen](/de/magazin/eu-ai-act-2026-unternehmen/) | [Zur Übersicht](/de/magazin/ai-infrastruktur-blueprint-2026/) | [Agent-Orchestrierung: n8n, Camunda und Alternativen](/de/magazin/agent-orchestrierung-plattformen/) |

*Alle Artikel dieser Serie: [Enterprise AI-Infrastruktur Blueprint 2026](/de/magazin/ai-infrastruktur-blueprint-2026/)*

---

Gosign begleitet Unternehmen bei den organisatorischen Fragen der KI-Einführung, von der Betriebsratsverhandlung bis zum AI-Literacy-Programm. Wenn Sie wissen wollen, wie Sie Ihre Organisation vorbereiten, sprechen Sie mit uns.

<a href="/de/kontakt/" target="_blank" rel="noopener noreferrer">Termin vereinbaren</a>. 30 Minuten, in denen wir Ihre Organisationsfragen klären.

--- KI-Governance-Dashboard: Agent-Monitoring für Unternehmen ---
> Wie ein KI-Governance-Dashboard Agent-Aktivitäten transparent macht - für IT, Betriebsrat und Revision. Audit-Trail, Modell-Monitoring.

## Warum ein Dashboard nicht reicht - aber ohne Dashboard nichts geht

KI-Governance ist kein Dashboard-Problem. Governance ist ein Architekturprinzip. Aber ohne eine Darstellungsschicht, die Agent-Aktivitäten transparent macht, bleibt Governance abstrakt. Niemand in der Organisation - nicht IT, nicht Betriebsrat, nicht interne Revision - kann beurteilen, was die Agenten tatsächlich tun.

Ein KI-Governance-Dashboard ist die Schnittstelle zwischen der technischen Governance-Architektur und den Menschen, die Verantwortung tragen. Es macht sichtbar, was der [Decision Layer](/de/decision-layer/) im Hintergrund dokumentiert.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Auf einen Blick - KI-Governance-Dashboard</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Ein KI-Governance-Dashboard ist die Darstellungsschicht für Decision-Layer-Daten - kein eigenständiges Monitoring-Tool.</li>
<li>Es zeigt Agent-Aktivitäten, Audit-Trails, Modell-Performance und Regelversionen in Echtzeit.</li>
<li>Drei rollenbasierte Sichten (IT, Management, Betriebsrat) sind Voraussetzung dafür, dass Governance in der Praxis funktioniert.</li>
<li>Gartner (2024) prognostiziert, dass Unternehmen mit KI-Governance-Frameworks bis 2026 40 % weniger KI-bezogene Compliance-Vorfälle erleben werden.</li>
<li>Ohne Dashboard kann niemand in der Organisation überprüfen, was KI-Agenten tatsächlich tun.</li>
</ul>
</div>


## Was ein KI-Governance-Dashboard zeigen muss

### Agent-Aktivitäten: Wer tut was

Jeder Agent erzeugt bei jeder Aktion einen Protokolleintrag: Zeitstempel, Eingabe, angewandte Regel, Ausgabe, Status (automatisch verarbeitet, zur Freigabe vorgelegt, eskaliert). Das Dashboard aggregiert diese Einträge und macht sie nach Zeitraum, Abteilung, Agent-Typ und Status filterbar.

Das ist kein klassisches IT-Monitoring. Es ist ein Entscheidungsprotokoll - gebaut für Menschen, die verstehen müssen, was Agenten in ihrem Verantwortungsbereich tun.

### Audit-Trail: Lückenlose Nachvollziehbarkeit

Für jede einzelne Agenten-Entscheidung existiert ein vollständiger Datensatz: Welches Dokument lag vor? Welche Daten wurden extrahiert? Gegen welche Regel (in welcher Version) wurde geprüft? Welche Empfehlung hat der Agent ausgesprochen? Wer hat freigegeben oder eskaliert?

Das Dashboard macht diesen [Audit-Trail](/de/governance/) durchsuchbar und exportierbar - für interne Revision, Wirtschaftsprüfer oder Betriebsprüfung.

### Modell-Monitoring: Welches LLM leistet was

In einer [modell-agnostischen Architektur](/de/leistungen/infrastruktur/) laufen verschiedene Modelle parallel. Das Dashboard zeigt pro Modell: Antwortzeiten, Token-Verbrauch, Kosten, Fehlerquoten. Daraus ergeben sich fundierte Entscheidungen über Modellauswahl und -routing - ohne Bauchgefühl, auf Basis realer Betriebsdaten.

### Regelversionen: Was hat sich geändert

Agenten arbeiten auf Basis von Entscheidungsregeln. Wenn eine Regel geändert wird - etwa weil sich ein Tarifvertrag ändert oder eine neue Betriebsvereinbarung in Kraft tritt - muss nachvollziehbar sein: Was war die alte Regel? Was ist die neue? Ab wann gilt sie? Wer hat sie freigegeben?

Das Dashboard zeigt Regelversionen als Timeline. Jede Änderung ist einem Verantwortlichen zugeordnet und mit dem Audit-Trail verknüpft.

<table class="w-full text-left text-sm">
<thead><tr class="border-b border-gosign-border">
<th class="py-2 pr-4 font-semibold">Komponente</th>
<th class="py-2 pr-4 font-semibold">Zweck</th>
<th class="py-2 pr-4 font-semibold">Datenquelle</th>
</tr></thead>
<tbody>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Agent-Aktivitätsprotokoll</td><td class="py-2 pr-4">Jede Agentenaktivität in Echtzeit verfolgen</td><td class="py-2 pr-4">Decision Layer Protokolleinträge</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Audit-Trail-Viewer</td><td class="py-2 pr-4">Durchsuchbare, exportierbare Entscheidungsdatensätze</td><td class="py-2 pr-4">Decision Layer Audit-Datensätze</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Modell-Monitor</td><td class="py-2 pr-4">LLM-Performance und Kosten vergleichen</td><td class="py-2 pr-4">Inferenz-Metriken pro Modell</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Regelversions-Timeline</td><td class="py-2 pr-4">Regeländerungen mit Verantwortlichkeit verfolgen</td><td class="py-2 pr-4">Versioniertes Regel-Repository</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Eskalations-Dashboard</td><td class="py-2 pr-4">Human-in-the-Loop-Quoten überwachen</td><td class="py-2 pr-4">HITL-Eskalationsereignisse</td></tr>
</tbody>
</table>

## Drei Sichten für drei Zielgruppen

Ein einziges Dashboard, aber unterschiedliche Zugänge je nach Rolle.

Die IT-Sicht zeigt technische Performance: Agent-Uptime, Modell-Latenz, API-Fehlerraten, Ressourcenauslastung. Sie dient dem operativen Betrieb und der Kapazitätsplanung.

Die Management-Sicht zeigt Geschäftskennzahlen: verarbeitete Vorgänge pro Tag, Automatisierungsquote, Eskalationsquote, Durchlaufzeiten. Sie dient der ROI-Bewertung und dem Reporting an die Geschäftsleitung.

Die Betriebsrats-Sicht zeigt aggregierte Nutzungsdaten: In welchen Abteilungen werden Agenten eingesetzt? Wie häufig werden Entscheidungen automatisiert vs. zur menschlichen Freigabe vorgelegt? Welche Regeländerungen wurden vorgenommen? Diese Sicht enthält bewusst keine personenbezogenen Einzeldaten - sie schafft Transparenz über den KI-Einsatz insgesamt.

Diese Dreiteilung ist kein Nice-to-have. Sie ist die Voraussetzung dafür, dass KI-Governance in der Praxis funktioniert. Ohne IT-Sicht kein stabiler Betrieb. Ohne Management-Sicht kein Budget. Ohne Betriebsrats-Sicht keine [Betriebsvereinbarung](/de/governance/mitbestimmung/).


## Governance-Dashboard als Architekturkomponente

Das Dashboard ist kein separates Tool, das nachträglich auf die KI-Infrastruktur aufgesetzt wird. Es ist eine Darstellungsschicht, die direkt auf den Daten des [Decision Layer](/de/decision-layer/) operiert.

Jeder Audit-Trail-Eintrag, jede Regelversion, jede Modell-Metrik wird vom Decision Layer automatisch erzeugt - als Nebenprodukt des normalen Betriebs, nicht als zusätzlicher Aufwand. Das Dashboard macht diese Daten zugänglich, filterbar und exportierbar.

Das ist [Governance by Design](/de/governance/): Transparenz entsteht nicht durch nachträgliches Reporting, sondern als integraler Bestandteil der Architektur.

Bei Gosign bauen wir [KI-Infrastruktur](/de/leistungen/infrastruktur/) mit integriertem Governance-Layer. Das Dashboard ist keine Option - es ist Teil jeder Agenten-Infrastruktur, die wir ausliefern.

--- KI-Hosting: EU-SaaS, deutsches RZ oder Self-Hosted? ---
> Drei Hosting-Strategien für Enterprise-KI. Entscheidungsmatrix nach Datensensibilität, Kosten und Kontrolle.

## „Wo läuft es?" - Die entscheidende Frage

Bevor Sie ein Modell auswählen, bevor Sie Agenten bauen, bevor Sie ein Interface ausrollen, steht eine Frage: Wo laufen Ihre KI-Modelle? Diese Entscheidung bestimmt, welche Datenschutzgarantien Sie geben können, welche regulatorischen Anforderungen Sie erfüllen, wie hoch Ihre laufenden Kosten sind und wie abhängig Sie von Drittanbietern werden.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Auf einen Blick - KI-Hosting-Strategie für Enterprise</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Drei Stufen: EU-SaaS (Cloud-APIs), deutsches IaaS (Self-Hosted GPU) und On-Premises (eigene Hardware) - plus die Hybrid-Kombination.</li>
<li>Die Hybrid-Architektur routet Anfragen nach Datensensibilität: 60-70 % Cloud, 25-35 % deutsches IaaS, 5-10 % On-Premises.</li>
<li>Gartner (2025) schätzt, dass 40 % der Großunternehmen bis 2027 hybride KI-Hosting-Architekturen betreiben, gegenüber unter 10 % in 2024.</li>
<li>Self-Hosted Open-Source-Modelle (gpt-oss-120b) laufen auf einer GPU für ca. 1.200 EUR pro Monat bei deutschen Anbietern.</li>
<li>Gesamtkosten mit Hybrid-Strategie liegen 30-40 % unter einer reinen Cloud-API-Strategie bei höherer Datensouveränität.</li>
</ul>
</div>

Es gibt drei grundlegende Strategien - und eine vierte, die in der Praxis zum Standard geworden ist: die Hybrid-Architektur, die alle drei kombiniert.

## Stufe 1: EU-SaaS - Cloud-APIs mit EU-Datenresidenz

Die einfachste und schnellste Variante: Sie nutzen die APIs der Modellanbieter direkt. Claude über die Anthropic-API (EU-Region), GPT-5.5 über Azure OpenAI (EU-Rechenzentrum), Gemini über Google Cloud Platform (EU-Region). Die Daten verlassen Ihr Netzwerk, werden aber in EU-Rechenzentren verarbeitet.

### Vorteile

**Schnellster Start:** Keine Infrastruktur aufbauen, kein GPU-Server bereitstellen, keine ML-Ops-Expertise erforderlich. API-Key einrichten, AVV unterzeichnen, produktiv in Stunden.

**Automatische Updates:** Modellupdates, Sicherheitspatches und Performance-Verbesserungen werden vom Anbieter ausgerollt. Kein eigener Wartungsaufwand.

**Skalierbarkeit:** Kein Kapazitätsmanagement. Bei Lastspitzen skaliert der Cloud-Anbieter automatisch. Keine Überplanung, keine Unterkapazität.

**Modellvielfalt:** Zugriff auf alle Modellvarianten des Anbieters - Flaggschiff, Preis-Leistung und Budget - über dieselbe API.

### Risiken und Einschränkungen

**Daten verlassen das Unternehmensnetzwerk.** Auch bei EU-Datenresidenz werden Ihre Anfragen auf Infrastruktur verarbeitet, die Sie nicht kontrollieren. Der Anbieter hat technisch Zugriff auf die Daten während der Verarbeitung.

**CLOUD Act.** US-amerikanische Anbieter - und dazu gehören Anthropic, OpenAI und Google - unterliegen dem US CLOUD Act. US-Behörden können unter bestimmten Bedingungen Zugriff auf Daten verlangen, auch wenn diese in EU-Rechenzentren gespeichert sind. Für die meisten Unternehmensdaten ist dieses Risiko bewertbar und akzeptabel. Für Geschäftsgeheimnisse, VS-NfD-Daten oder KRITIS-relevante Informationen nicht.

**Vendor-Abhängigkeit.** Bei einer Single-Provider-Strategie sind Sie von der Preispolitik, den API-Änderungen und der Verfügbarkeit eines einzelnen Anbieters abhängig. Eine modell-agnostische Architektur (siehe [KI-Modelle Vergleich 2026](/de/magazin/ki-modelle-vergleich-2026/)) reduziert dieses Risiko.

**AVV erforderlich.** Für die DSGVO-konforme Nutzung ist ein Auftragsverarbeitungsvertrag (AVV) mit dem Anbieter zwingend. Alle drei großen Anbieter bieten Standard-AVVs an - prüfen Sie diese mit Ihrer Rechtsabteilung. Achtung: Standard-SaaS-AVVs decken KI-spezifische Themen wie Prompt-Logging, Umgebungstrennung und Modell-Provider-Ketten nicht ab. Unser [Anforderungskatalog für KI-AVVs](/de/magazin/avv-ki-infrastruktur-checkliste/) zeigt die zehn Lücken und liefert 25 Prüffragen.

### Geeignet für

- Standard-Aufgaben mit nicht-sensiblen Daten: Zusammenfassungen, Übersetzungen, allgemeine Fragebeantwortung
- Proof of Concepts und Pilotprojekte
- Aufgaben mit variablem Volumen, bei denen dedizierte GPU-Infrastruktur unwirtschaftlich wäre
- Unternehmen ohne ML-Ops-Expertise, die schnell produktiv werden wollen

## Stufe 2: Deutsches IaaS - GPU-Hosting bei deutschen Anbietern

Die mittlere Variante: Sie mieten GPU-Server bei einem deutschen Infrastructure-as-a-Service-Anbieter - etwa Hetzner, IONOS oder einem spezialisierten GPU-Cloud-Provider. Darauf betreiben Sie Open-Source-Modelle wie gpt-oss, Llama 4 oder Mistral Medium 3.1 selbst.

### Konkrete Hardware-Anforderungen und Kosten

| Modell | GPU-Anforderung | Geschätzte Kosten/Monat |
|---|---|---|
| gpt-oss-120b | 1x A100/H100 (80 GB) | ca. 1.200 € |
| gpt-oss-20b | CPU/16 GB RAM (oder kleine GPU) | ca. 200 - 400 € |
| Llama 4 Scout | 1x A100 (80 GB) | ca. 1.200 € |
| Llama 4 Maverick | 4x A100 (80 GB) | ca. 3.500 € |
| Mistral Medium 3.1 | 4x A100 (80 GB) | ca. 3.500 € |

### Vorteile

**Daten bleiben in Deutschland.** Der Server steht in einem deutschen Rechenzentrum, betrieben von einem deutschen Anbieter. Kein CLOUD Act, kein transatlantischer Datentransfer. Für die DSGVO die sicherste Cloud-Variante.

**Kein Anbieter-Lock-in.** Sie betreiben Open-Source-Modelle unter Apache 2.0 oder Meta Llama License. Wenn Sie den Hosting-Anbieter wechseln wollen, migrieren Sie das Modell - ohne Lizenzfragen, ohne Vertragsverhandlungen.

**Volle Modellkontrolle.** Sie entscheiden, welches Modell in welcher Version läuft. Sie können Modelle fine-tunen, quantisieren oder durch neuere Versionen ersetzen - ohne auf den Anbieter zu warten.

**Kalkulierbare Kosten.** GPU-Server haben Fixkosten pro Monat. Keine variablen Token-Kosten, keine Überraschungen bei Lastspitzen. Für Unternehmen mit hohem, konstantem Volumen oft wirtschaftlicher als Cloud-APIs.

### Anforderungen

**ML-Ops-Kompetenz.** Sie brauchen jemanden, der das Modell deployed, überwacht, aktualisiert und bei Problemen eingreift. Das kann ein interner ML-Engineer sein oder ein externer Dienstleister - aber es ist kein Null-Aufwand.

**Kapazitätsplanung.** Ein GPU-Server hat eine definierte Kapazität. Wenn Sie 500 gleichzeitige Anfragen haben, reicht eine einzelne GPU nicht. Sie müssen Lastprofile verstehen und Kapazitäten planen.

**Kein automatisches Update.** Wenn ein neues Modell erscheint, müssen Sie es selbst deployen. Wenn ein Sicherheitsproblem auftritt, müssen Sie selbst patchen.

### Geeignet für

- Vertrauliche Unternehmensdaten (Stufe 2 - 3 nach BSI-Klassifikation)
- Unternehmen, die CLOUD-Act-Risiken ausschließen müssen
- Anwendungsfälle mit konstantem, hohem Volumen (Kostenvorteil gegenüber Cloud-APIs)
- Organisationen mit bestehender DevOps-/ML-Ops-Kompetenz

## Stufe 3: On-Premises - KI auf eigener Hardware

Die maximal kontrollierte Variante: Sie betreiben GPU-Server in Ihrem eigenen Rechenzentrum oder in einem Colocation-Rack. Keine Daten verlassen Ihr Netzwerk - unter keinen Umständen.

### Vorteile

**Maximale Datensouveränität.** Kein externer Zugriff, kein externer Anbieter, keine externe Abhängigkeit. Die Hardware gehört Ihnen, das Modell gehört Ihnen, die Daten verlassen nie Ihr Netzwerk.

**Regulatorische Sicherheit.** Für KRITIS-Unternehmen, Behörden, Verteidigungssektor und Organisationen mit VS-NfD-Daten ist On-Premises oft die einzige Option, die den Compliance-Anforderungen entspricht.

**Keine laufenden Lizenz- oder API-Kosten.** Nach der initialen Investition fallen nur Strom, Kühlung und Wartung an. Bei langjährigem Betrieb und hohem Volumen kann On-Premises die wirtschaftlichste Variante sein.

### Herausforderungen

**Hohe Initialinvestition.** Ein produktiver GPU-Server mit NVIDIA H100 (80 GB) kostet 25.000 - 40.000 Euro. Für leistungsfähigere Setups (Multi-GPU, Redundanz) liegen die Kosten bei 60.000 - 120.000 Euro oder mehr.

**ML-Ops-Team erforderlich.** On-Premises bedeutet: Sie sind für alles verantwortlich. Hardware-Wartung, Modell-Deployment, Monitoring, Updates, Sicherheit. Das erfordert ein dediziertes Team oder einen erfahrenen Dienstleister.

**Skalierung ist nicht trivial.** Wenn die Last steigt, können Sie nicht per Knopfdruck eine weitere GPU hinzufügen. Hardware-Beschaffung dauert Wochen bis Monate.

### Geeignet für

- KRITIS-Unternehmen und Behörden
- VS-NfD-Daten und höchste Geheimhaltungsstufen
- Organisationen mit eigenem Rechenzentrum und ML-Ops-Kompetenz
- Langfristige Investitionsbereitschaft bei sehr hohem Volumen

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Kostenloses eBook: AI Infrastructure</p>
<p class="text-body text-gosign-text mb-4">Build, Buy, Hybrid - EU AI Act-konforme Infrastruktur mit B/B/H-Framework und 7-Layer Reference Architecture.</p>
<a href="/de/ebook/ki-infrastructure-governance-handbuch/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Jetzt kostenlos herunterladen</a>
</div>

## Der Entscheidungsbaum

Die folgende Entscheidungslogik hilft bei der Zuordnung:

```
Enthalten Ihre Daten PII oder Geschäftsgeheimnisse?
├── NEIN → EU-SaaS (Stufe 1)
└── JA → KRITIS oder VS-NfD?
├── JA → On-Premises (Stufe 3)
└── NEIN → Deutsches IaaS (Stufe 2) oder Hybrid
```

In der Praxis ist die Antwort selten eine einzelne Stufe. Die meisten Unternehmen haben Daten unterschiedlicher Sensibilität - und brauchen deshalb eine Architektur, die alle Stufen abdeckt.

## Hybrid als Standard: Die Routing-Architektur

Die Hybrid-Strategie kombiniert alle drei Stufen in einer einzigen Architektur. Eine Routing-Schicht entscheidet automatisch, welche Anfrage über welchen Kanal läuft - basierend auf der Datensensibilität, nicht auf der Entscheidung einzelner Mitarbeitender.

### So funktioniert das Routing

**Datensensibilitäts-Stufe 1 - 2 (öffentlich, intern):** Anfragen laufen über Cloud-APIs. Schnell, günstig, skalierbar. Beispiel: Zusammenfassung eines öffentlichen Whitepapers, Übersetzung einer Pressemitteilung, Entwurf einer allgemeinen E-Mail.

**Datensensibilitäts-Stufe 3 (vertraulich):** Anfragen werden an Self-Hosted-Modelle im deutschen Rechenzentrum geroutet. Kein Datenabfluss, kein CLOUD Act. Beispiel: Analyse interner Verträge, Verarbeitung von Personaldaten, Auswertung vertraulicher Finanzdaten.

**Datensensibilitäts-Stufe 4 (streng vertraulich / reguliert):** Anfragen laufen ausschließlich über On-Premises-Infrastruktur. Beispiel: VS-NfD-Dokumente, KRITIS-relevante Systeme, Daten unter besonderer Geheimhaltung.

### Voraussetzung: Datenklassifikation

Damit das Routing funktioniert, muss das Unternehmen seine Daten klassifizieren. Das klingt aufwändig, ist aber in vielen Organisationen bereits vorhanden - etwa im Rahmen bestehender Informationssicherheits-Management-Systeme (ISMS) oder der BSI-Grundschutz-Klassifikation. Die Routing-Regeln bilden diese bestehende Klassifikation auf die KI-Infrastruktur ab.

### Technische Umsetzung

Die Routing-Schicht sitzt zwischen dem [Enterprise-AI-Portal](/de/magazin/enterprise-ki-chat-interface/) (dem Interface, das Mitarbeitende nutzen) und den Modell-Endpunkten. Sie besteht aus drei Komponenten:

1. **Klassifikator:** Erkennt automatisch die Datensensibilität einer Anfrage - basierend auf Schlüsselwörtern, Quellsystem oder expliziter Markierung durch den Nutzer.
2. **Routing-Engine:** Ordnet die Anfrage dem passenden Modell-Endpunkt zu - Cloud-API, German IaaS oder On-Premises.
3. **Audit-Log:** Protokolliert jede Routing-Entscheidung - welche Anfrage, welche Sensibilitätsstufe, welcher Endpunkt. Nachvollziehbar und exportierbar.

### Kosteneffekt

Die Hybrid-Architektur optimiert nicht nur die Datensicherheit, sondern auch die Kosten. Cloud-APIs sind pro Anfrage günstig, aber variabel. Self-Hosted-Modelle haben Fixkosten, die sich bei hohem Volumen amortisieren. Die Kombination nutzt beides: günstige Cloud-APIs für das Gros der unkritischen Anfragen, Fixkosten-optimierte Self-Hosted-Modelle für das vertrauliche Volumen.

In der Praxis sehen wir bei Unternehmen mit 1.000+ Mitarbeitenden typischerweise folgende Verteilung: 60 - 70 % der Anfragen laufen über Cloud-APIs (Stufe 1 - 2), 25 - 35 % über deutsches IaaS (Stufe 3), und 5 - 10 % über On-Premises (Stufe 4). Die Gesamtkosten liegen dabei 30 - 40 % unter einer reinen Cloud-API-Strategie bei gleichzeitig höherer Datensouveränität.

## Zusammenfassung: Die drei Stufen im Überblick

| Kriterium | EU-SaaS (Stufe 1) | Deutsches IaaS (Stufe 2) | On-Premises (Stufe 3) |
|---|---|---|---|
| Datensouveränität | EU-Region, AVV | Deutschland, kein CLOUD Act | Maximal |
| Initialkosten | Keine | Gering (Miete) | Hoch (60 - 120k €+) |
| Laufende Kosten | Variabel (Token) | Fix (GPU-Miete) | Fix (Strom, Wartung) |
| ML-Ops-Aufwand | Keiner | Mittel | Hoch |
| Skalierbarkeit | Automatisch | Manuell | Manuell, langsam |
| Geeignet für | Stufe 1 - 2 Daten | Stufe 2 - 3 Daten | Stufe 3 - 4 Daten |

Die richtige Strategie ist fast immer eine Kombination. Gosign implementiert die Routing-Schicht, die alle drei Stufen verbindet - so dass Ihre Mitarbeitenden ein einziges Interface nutzen und das System automatisch den richtigen Weg wählt.

Weiterführend: [KI-Infrastruktur](/de/leistungen/infrastruktur/) | [Decision Layer & Shadow AI](/de/magazin/decision-layer-shadow-ai/)

---

**📘 Enterprise AI-Infrastruktur Blueprint 2026 - Artikel-Serie**

| ← Vorheriger | Übersicht | Nächster → |
|:---|:---:|---:|
| [KI-Modelle 2026: Welches Modell für welchen Einsatz?](/de/magazin/ki-modelle-vergleich-2026/) | [Zur Übersicht](/de/magazin/ai-infrastruktur-blueprint-2026/) | [Enterprise-AI-Portal: Vier Open-Source-Interfaces im Vergleich](/de/magazin/enterprise-ki-chat-interface/) |

*Alle Artikel dieser Serie: [Enterprise AI-Infrastruktur Blueprint 2026](/de/magazin/ai-infrastruktur-blueprint-2026/)*

---

**Sie wollen wissen, welche Hosting-Strategie für Ihre Datenlage die richtige ist?** Gosign analysiert Ihre Datenklassifikation und entwirft die passende Hybrid-Architektur.

<a href="/de/kontakt/" target="_blank" rel="noopener noreferrer">Termin vereinbaren</a> - Wir klären in 30 Minuten, welche Hosting-Stufen Sie brauchen.

--- KI-Infrastruktur in die bestehende IT-Landschaft integrieren ---
> Wie AI-Agenten und LLMs in SAP-, Workday- und Cloud-Landschaften integriert werden - ohne Greenfield, ohne Schatten-IT, ohne Plattformwechsel.

## Das Integrationsproblem

Die meisten Unternehmen haben keine leere IT-Landschaft. Sie haben SAP, [Workday](https://www.workday.com/), [SuccessFactors](https://www.sap.com/products/hcm.html), [DATEV](https://www.datev.de/), SharePoint, branchenspezifische Systeme, gewachsene Middleware und etablierte Sicherheitsarchitekturen. Das ist kein Hindernis für KI - es ist die Realität, in die KI passen muss.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Auf einen Blick - KI-Integration in bestehende IT</p>
<ul class="text-body text-gosign-text space-y-2">
<li>KI-Infrastruktur ist eine Integrationsschicht auf bestehenden Systemen - SAP, Workday und Cloud-Landschaften bleiben unverändert.</li>
<li>Vier Architekturschichten: Systemanbindung, Orchestrierung, Decision Layer und Benutzeroberfläche.</li>
<li>Agenten kommunizieren über Standard-APIs (RFC, OData, REST) - kein direkter Datenbankzugriff, keine proprietären Schnittstellen.</li>
<li>McKinsey (2024) berichtet, dass 74 % der Enterprise-KI-Projekte nicht über die Pilotphase hinauskommen - hauptsächlich wegen Integrationslücken.</li>
<li>Bestehende Sicherheitsrichtlinien, Authentifizierung und Audit-Prozesse bleiben vollständig gültig - der Agent ist ein zusätzlicher Teilnehmer, kein Parallelsystem.</li>
</ul>
</div>

Das häufigste Scheitern von KI-Projekten in Unternehmen liegt nicht an der Technologie. Es liegt daran, dass KI als isoliertes System eingeführt wird - neben der bestehenden IT, nicht in ihr. Das erzeugt Schatten-IT, Datensilos und Governance-Lücken.

Der richtige Ansatz: KI-Infrastruktur als Integrationsschicht, die bestehende Systeme verbindet, nicht ersetzt.


## Architekturprinzip: Integration Layer, nicht Plattformwechsel

Eine Enterprise-KI-Infrastruktur besteht aus vier Schichten, die sich in jede bestehende IT-Landschaft einfügen.

Die unterste Schicht ist die Systemanbindung. Konnektoren zu SAP (über RFC, OData, BAPIs), zu Workday (über REST-APIs), zu DATEV, SharePoint, E-Mail-Systemen und branchenspezifischen Anwendungen. Diese Konnektoren lesen und schreiben Daten - die Quellsysteme bleiben unverändert.

Darüber liegt die Orchestrierungsschicht. Hier laufen die [AI-Agenten](/de/leistungen/ai-agents/): Document Agents, die eingehende Dokumente lesen und klassifizieren. Workflow Agents, die Prozesse systemübergreifend steuern. Knowledge Agents, die Fragen auf Basis von Unternehmenswissen beantworten.

Die dritte Schicht ist der [Decision Layer](/de/decision-layer/). Er trennt die KI-Analyse von der Geschäftsentscheidung. Das Modell empfiehlt, der Mensch entscheidet. Jede Entscheidung wird dokumentiert, versioniert und ist auditierbar.

Die oberste Schicht ist das Interface: ein einheitliches Chat-Interface für Mitarbeiter oder direkte System-zu-System-Integration ohne menschliche Interaktion.


## Konkret: Wie ein AI-Agent in eine SAP-Landschaft integriert wird

Ein Beispiel aus der Praxis: Krankmeldungsverarbeitung.

Der Mitarbeiter sendet die Krankmeldung per E-Mail oder über ein Portal. Ein Document Agent erkennt den Dokumenttyp, extrahiert die relevanten Felder (Name, Zeitraum, Diagnosegruppe) und validiert die Daten gegen die Betriebsvereinbarung. Über den SAP-Konnektor prüft er die Personalstammdaten, berechnet die Entgeltfortzahlung und bereitet die Buchung vor.

An dieser Stelle greift der Decision Layer: Liegt der Fall innerhalb der automatisierbaren Regeln (Standardfall, keine Auffälligkeiten), wird die Buchung dem zuständigen Sachbearbeiter zur Freigabe vorgelegt. Liegt eine Auffälligkeit vor (Häufung, Fristüberschreitung, fehlende Daten), wird eskaliert.

Die SAP-Instanz wurde zu keinem Zeitpunkt modifiziert. Der Agent arbeitet als externe Integrationsschicht, die über Standard-APIs kommuniziert. Die bestehenden Berechtigungskonzepte, Netzwerkzonen und Audit-Prozesse gelten unverändert.


## Was die IT-Architektur leisten muss

Für eine saubere Integration braucht die KI-Infrastruktur vier Eigenschaften.

Erstens: API-first. Jede Kommunikation zwischen Agent und Quellsystem läuft über dokumentierte APIs. Keine direkten Datenbankzugriffe, keine proprietären Schnittstellen.

Zweitens: Mandantenfähigkeit. In Konzernstrukturen müssen Agenten mandantenspezifisch konfigurierbar sein - unterschiedliche Regeln, unterschiedliche Systeme, unterschiedliche Compliance-Anforderungen pro Gesellschaft.

Drittens: Logging und Audit. Jede Interaktion zwischen Agent und Quellsystem wird geloggt - wer hat was wann gelesen, geschrieben, entschieden. Das ist nicht optional, das ist die Grundlage für [Governance by Design](/de/governance/).

Viertens: Rollback-Fähigkeit. Wenn ein Agent einen Fehler macht, muss jede Aktion rückgängig gemacht werden können. Das setzt transaktionsorientierte Kommunikation mit den Quellsystemen voraus.


## Integration Layer im Überblick

<table>
<thead>
<tr><th>Schicht</th><th>Funktion</th><th>Technologie</th></tr>
</thead>
<tbody>
<tr><td>Systemanbindung</td><td>Lesen/Schreiben in Quellsystemen</td><td>SAP RFC/OData, Workday REST, DATEV API, Microsoft Graph</td></tr>
<tr><td>Orchestrierung</td><td>Agenten und Workflows koordinieren</td><td>Trigger.dev, Camunda, n8n</td></tr>
<tr><td>Decision Layer</td><td>KI-Analyse von Geschäftsentscheidung trennen</td><td>Rules Engine, Confidence Routing, Human-in-the-Loop</td></tr>
<tr><td>Interface</td><td>Mitarbeiterzugang oder System-zu-System</td><td>Enterprise AI-Portal, REST API</td></tr>
</tbody>
</table>

## Kein Greenfield, kein Plattformwechsel

Der häufigste Einwand von CIOs: „Wir können nicht noch ein System einführen." Und dieser Einwand ist berechtigt.

Deshalb ist die KI-Infrastruktur kein neues System im klassischen Sinne. Sie ist eine Schicht, die sich in die bestehende Architektur einfügt. SAP bleibt SAP. Workday bleibt Workday. Die Netzwerkarchitektur bleibt bestehen. Die Sicherheitsrichtlinien bleiben gültig. Der Agent ist ein zusätzlicher Teilnehmer im bestehenden Ökosystem - mit denselben Regeln, denselben Kontrollen, denselben Audit-Anforderungen.

Bei Gosign bauen wir [KI-Infrastruktur](/de/leistungen/infrastruktur/) als Integrationsschicht: in Azure, GCP oder Self-Hosted, verbunden mit den Systemen die bereits da sind. Keine Schatten-IT. Agenten werden Teil der bestehenden [IT-Governance](/de/governance/) - nicht eine neue Parallelwelt.

--- KI-Infrastruktur statt Tool-Hype: Enterprise Stack ---
> KI-Tools vs. KI-Infrastruktur: Orchestrierung, Governance, Modell-Agnostik, Audit Trail. Warum Unternehmen eine eigene Schicht brauchen

## Tool vs. Infrastruktur

ChatGPT, Microsoft CoPilot, Google Gemini - das sind KI-Tools. Man gibt eine Frage ein, bekommt eine Antwort. Für individuelle Produktivität funktioniert das. Für Enterprise-Prozesse nicht.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Auf einen Blick - KI-Infrastruktur statt Tool-Hype</p>
<ul class="text-body text-gosign-text space-y-2">
<li>ChatGPT, CoPilot und Gemini sind KI-Tools - keine Enterprise-Infrastruktur. Es fehlen Audit Trail, Mandantenisolierung und Systemintegration.</li>
<li>Enterprise KI-Infrastruktur besteht aus sieben Schichten: Presentation, Orchestration, Agent, Decision, Model, Integration und Infrastructure.</li>
<li>Gartner (2024) berichtet, dass über 55 % der Organisationen, die KI-Tools ohne Governance eingeführt haben, ihren Ansatz innerhalb von 18 Monaten neu aufbauen mussten.</li>
<li>Eine modell-agnostische Architektur verhindert Vendor Lock-in und hält Modelle austauschbar - Claude, GPT, Gemini, Llama, Mistral.</li>
<li>Nach 12 bis 18 Monaten betreibt der Kunde die Infrastruktur eigenständig mit vollem Zugang zum Quellcode und ohne wiederkehrende Anbieterabhängigkeit.</li>
</ul>
</div>

Der Unterschied zwischen einem KI-Tool und KI-Infrastruktur ist vergleichbar mit dem Unterschied zwischen einer Excel-Tabelle und einem ERP-System. Die Excel-Tabelle löst ein konkretes Problem für einen einzelnen Benutzer. Das ERP-System ist die Infrastruktur, auf der Geschäftsprozesse des gesamten Unternehmens laufen.

KI-Infrastruktur ist die Architekturschicht zwischen Sprachmodell und Enterprise-System. Sie umfasst: Modell-Hosting, Orchestrierung, Decision Layer, Governance, Integration in bestehende Systeme. Das Sprachmodell ist ein Baustein dieser Infrastruktur - nicht die Infrastruktur selbst.

## Was einem KI-Tool fehlt

Wenn ein Unternehmen ChatGPT für die Belegverarbeitung nutzt, fehlt:

**Audit Trail:** Keine Dokumentation welche Entscheidung auf welcher Grundlage getroffen wurde. Bei einer Prüfung ist nichts nachvollziehbar.

**Versionierte Regelwerke:** ChatGPT kennt keine mandantenspezifischen Buchungsregeln in Version 4.2. Es hat allgemeines Wissen über Buchführung - aber keine konkreten Regelwerke des Kunden.

**Mandantenisolierung:** Daten aller Mandanten fließen in dasselbe System. Keine Row-Level Security, keine Workspace-Trennung.

**Integration:** ChatGPT kann keine Buchung in SAP anlegen, keinen Workflow in [Trigger.dev](https://trigger.dev/) triggern, keine Eskalation an einen Sachbearbeiter auslösen.

**Human-in-the-Loop:** Keine architektonisch erzwungene menschliche Prüfung. Keine Eskalationsregeln. Keine Konfidenz-Schwellenwerte.

**Modell-Agnostik:** Wer auf ChatGPT baut, ist an OpenAI gebunden. Wenn OpenAI die Preise erhöht, die API ändert oder den Dienst einstellt, steht das Unternehmen ohne Alternative da.

## Die sieben Schichten der Enterprise KI-Infrastruktur

Die [Gosign Referenz-Architektur](/de/governance/referenz-architektur/) beschreibt sieben Schichten:

**Presentation Layer:** Chat-Interface, Dashboard, Auditor Portal, REST API. Die Schnittstelle zwischen System und Nutzer.

**Orchestration Layer:** Workflow-Engine ([Trigger.dev](https://trigger.dev/) oder [Camunda](https://camunda.com/)), API-Gateway, Queue-Management. Koordiniert den Datenfluss zwischen allen Komponenten.

**Agent Layer:** Die spezialisierten Agenten - Document Agents, Workflow Agents, Knowledge Agents. Jeder Agent hat einen definierten Aufgabenbereich.

**Decision Layer:** Zerlegt jeden Prozess in Entscheidungsschritte. Für jeden Schritt definiert: Mensch, Regelwerk oder KI. Enthält Rules Engine (versionierte Regelwerke), Confidence Routing (automatische Risikobewertung), Human-in-the-Loop (technisch erzwungen) und Audit Trail (unveränderliches Entscheidungsprotokoll).

**Model Layer:** Die Sprachmodelle. Austauschbar, modell-agnostisch. Claude, ChatGPT, Gemini, Llama, Mistral, DeepSeek, gpt-oss.

**Integration Layer:** Die Anbindung an bestehende Systeme. SAP, [DATEV](https://www.datev.de/), [Workday](https://www.workday.com/), [SuccessFactors](https://www.sap.com/products/hcm.html), SharePoint.

**Infrastructure Layer:** Das Deployment. Azure, GCP, Self-Hosted, Hybrid.

Die Governance-Schicht zieht sich als Querschnitt durch alle sieben Layer.

## KI-Tool vs. KI-Infrastruktur

<table>
<thead>
<tr><th>Fähigkeit</th><th>KI-Tool (ChatGPT)</th><th>KI-Infrastruktur</th></tr>
</thead>
<tbody>
<tr><td>Audit Trail</td><td>Nein</td><td>Unveränderliches Entscheidungsprotokoll</td></tr>
<tr><td>Mandantenisolierung</td><td>Nein</td><td>Row-Level Security, Workspace-Trennung</td></tr>
<tr><td>ERP-Integration</td><td>Nein</td><td>SAP, DATEV, Workday über APIs</td></tr>
<tr><td>Versionierte Regelwerke</td><td>Nein</td><td>Mandantenspezifisch, versioniert</td></tr>
<tr><td>Human-in-the-Loop</td><td>Nein</td><td>Architektonisch erzwungen</td></tr>
<tr><td>Modellunabhängigkeit</td><td>An einen Anbieter gebunden</td><td>Modell-agnostisches Routing</td></tr>
<tr><td>Governance-Schicht</td><td>Nicht vorhanden</td><td>Querschnitt durch alle Schichten</td></tr>
</tbody>
</table>

## Der Infrastruktur-Vorteil

Mit einer eigenen KI-Infrastruktur gewinnt das Unternehmen:

**Kontrolle:** Daten bleiben in der eigenen Infrastruktur. Modelle sind austauschbar. Voller Zugang zu Regelwerken und Konfigurationen.

**Skalierbarkeit:** Ein Agent für einen Prozess ist ein PoC. Die Infrastruktur ermöglicht, weitere Agenten für weitere Prozesse zu deployen - mit derselben Governance.

**Unabhängigkeit:** Nach 12-18 Monaten betreibt der Kunde die Infrastruktur eigenständig. Voller Zugang zum Quellcode, allen Prompts und Regelwerken. Kein Vendor Lock-in.

Mehr dazu: [KI-Infrastruktur](/de/leistungen/infrastruktur/)

<a href="/de/kontakt/" target="_blank" rel="noopener noreferrer">Termin vereinbaren</a> - Wir zeigen Ihnen, wie eine KI-Infrastruktur für Ihr Unternehmen aussieht.

--- KI-Integration in IT-Landschaften: SAP, DATEV, Workday ---
> KI-Agenten in SAP, DATEV, Workday integrieren: Integration Layer, API-Entkopplung, Buchungslogik von Exportschicht getrennt.

## Das Prinzip: Erweitern, nicht ersetzen

KI-Agenten ersetzen keine bestehenden Systeme. Sie erweitern sie. SAP bleibt SAP. DATEV bleibt DATEV. Workday bleibt Workday. Der Agent sitzt dazwischen: Er liest Daten, trifft Entscheidungen und schreibt Ergebnisse zurück.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Auf einen Blick - KI-Integration in Enterprise-Systeme</p>
<ul class="text-body text-gosign-text space-y-2">
<li>KI-Agenten erweitern bestehende Systeme (SAP, DATEV, Workday), anstatt sie zu ersetzen - der Agent ist eine externe Integrationsschicht.</li>
<li>Der Integration Layer entkoppelt Agent-Logik vom Zielsystem: Wenn das ERP wechselt, ändert sich nur die Exportschicht.</li>
<li>Buchungslogik (Decision Layer) ist architektonisch von der Exportschicht (Integration Layer) getrennt, was den Migrationsaufwand reduziert.</li>
<li>Forrester (2024) stellt fest, dass Unternehmen mit API-first-Integrationsstrategie KI 2,4-mal schneller deployen als solche mit individuellen Konnektoren.</li>
<li>Agenten nutzen bestehende Authentifizierung, Cloud-Umgebung, Security-Policies und Monitoring - kein Parallelsystem nötig.</li>
</ul>
</div>

Dieses Prinzip ist entscheidend für die Akzeptanz in Enterprise-Umgebungen. CIOs investieren nicht in eine Parallelwelt. Sie investieren in eine Schicht, die ihre bestehende IT-Landschaft intelligenter macht.

## Der Integration Layer

Der Integration Layer in der Gosign Referenz-Architektur entkoppelt die Agent-Logik vom Zielsystem. Das hat einen konkreten Vorteil: Wenn das Zielsystem wechselt, ändert sich nur die Exportschicht - nicht der Agent.

**[SAP FI/CO und S/4HANA](https://www.sap.com/products/erp/s4hana.html):** Buchungsvorschläge im SAP-Format. Kostenstellen- und Profit-Center-Logik. Integration über RFC, REST API oder SAP BTP.

**[DATEV](https://www.datev.de/):** Buchungsvorschläge im DATEV-Format. SKR03 und SKR04. Mandantenspezifische Kontenpläne. Export über DATEV-Schnittstelle.

**[Workday](https://www.workday.com/):** HR-Daten, Payroll-Informationen, Organisationsstruktur. Integration über Workday REST API.

**[SuccessFactors](https://www.sap.com/products/hcm.html):** Mitarbeiterdaten, Performance-Daten, Compensation. Integration über SAP SuccessFactors API.

**[Microsoft Graph](https://learn.microsoft.com/en-us/graph/overview):** SharePoint, Teams, Outlook. Für Knowledge Agents die auf Unternehmensdokumente zugreifen.

## Entkopplung: Buchungslogik vs. Exportschicht

Die Trennung von Buchungslogik und Exportschicht ist ein zentrales Architekturprinzip. Die Buchungslogik - welches Konto, welche Kostenstelle, welcher Steuersatz - ist im Decision Layer implementiert. Die Exportschicht - wie wird das Ergebnis an DATEV oder SAP übergeben - ist im Integration Layer.

Wenn der Mandant von DATEV auf SAP wechselt, ändert sich die Exportschicht. Die Buchungslogik, die Regelwerke, der Agent - alles bleibt gleich. Das reduziert den Migrationsaufwand erheblich.

## Integration Layer nach Zielsystem

<table>
<thead>
<tr><th>Zielsystem</th><th>Integrationsmethode</th><th>Datenumfang</th></tr>
</thead>
<tbody>
<tr><td>SAP FI/CO, S/4HANA</td><td>RFC, REST API, SAP BTP</td><td>Buchungsvorschläge, Kostenstellen-Logik</td></tr>
<tr><td>DATEV</td><td>DATEV-Schnittstelle, SKR03/SKR04</td><td>Buchungsvorschläge, Kontenpläne</td></tr>
<tr><td>Workday</td><td>Workday REST API</td><td>HR-Daten, Payroll, Orgstruktur</td></tr>
<tr><td>SuccessFactors</td><td>SAP SuccessFactors API</td><td>Mitarbeiter-, Performance-, Compensation-Daten</td></tr>
<tr><td>Microsoft Graph</td><td>Graph API</td><td>SharePoint, Teams, Outlook</td></tr>
</tbody>
</table>

## Kein Parallelsystem

Agenten werden Teil der bestehenden [IT-Governance](/de/leistungen/infrastruktur/) - nicht eine neue Parallelwelt. Das bedeutet:

- Agenten nutzen die bestehende Authentifizierung (Azure Entra ID, LDAP)
- Agenten laufen in der bestehenden Cloud-Umgebung (Azure, GCP)
- Agenten unterliegen den bestehenden Security-Policies
- Agenten werden in bestehende Monitoring-Systeme integriert

Für den CIO ist ein KI-Agent eine weitere Komponente in der bestehenden Architektur - nicht ein separates System das eigene Regeln hat.

Mehr dazu: [Referenz-Architektur](/de/governance/referenz-architektur/)

<a href="/de/kontakt/" target="_blank" rel="noopener noreferrer">Termin vereinbaren</a> - Wir zeigen Ihnen die Integration in Ihre bestehende IT-Landschaft.

--- Was KI wirklich kostet: TCO-Vergleich für Unternehmen ---
> Token-Preise sind irreführend. Die vier Kostenkategorien von Enterprise-KI - mit drei Szenarien von 26.000 bis 410.000 Euro.

## Token-Preise sind nicht Ihre KI-Kosten

Wenn Unternehmen über KI-Kosten sprechen, beginnt die Diskussion fast immer bei Token-Preisen. Das ist nachvollziehbar: Anbieter bewerben ihre Modelle mit Input- und Output-Preisen pro Million Tokens, und diese Zahlen sind leicht zu vergleichen. Ein Flaggschiff-Modell kostet 5 Dollar pro Million Input-Tokens, ein Budget-Modell 0,25 Dollar - der Unterschied wirkt dramatisch.

Doch Token-Preise machen in der Praxis nur 20 bis 35 Prozent der tatsächlichen Kosten aus. Wer seine KI-Budget-Planung auf Token-Preise reduziert, unterschätzt die Gesamtkosten um den Faktor drei bis fünf. Die eigentliche Frage lautet nicht: „Was kostet ein Token?" Die Frage lautet: „Was kostet es, KI produktiv, sicher und compliant in meinem Unternehmen zu betreiben?"

Dieser Artikel zeigt die vier Kostenkategorien, die jede Enterprise-KI-Einführung umfasst, vergleicht drei Szenarien von 26.000 bis 410.000 Euro im ersten Jahr und erklärt, wie Model Switching 40 bis 60 Prozent der Token-Kosten einsparen kann.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Auf einen Blick - Was KI wirklich kostet</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Token-Preise machen nur 20 bis 35 % der tatsächlichen Kosten aus. Infrastruktur, Governance und Personal bilden die restlichen 65 bis 80 %.</li>
<li>Drei Szenarien: Einstieg bei ~26.000 EUR (1 Chatbot, 50 Nutzer), Standard bei ~148.000 EUR (3 Agenten, Hybrid), Enterprise bei ~410.000 EUR (10+ Agenten, eigene GPUs).</li>
<li>Laut Deloitte (2024) unterschätzen Unternehmen, die KI-Budgets nur auf Token-Preisen planen, die Gesamtkosten im Durchschnitt um den Faktor 3 bis 5.</li>
<li>Model Switching reduziert Token-Kosten um 40 bis 60 %, indem einfache Anfragen an Budget-Modelle und komplexe an Flaggschiff-Modelle geroutet werden.</li>
<li>Infrastrukturkosten fallen primär in Monat 1 bis 6 an; ab Jahr zwei dominieren Modell- und Personalkosten den TCO-Mix.</li>
</ul>
</div>

## Die vier Kostenkategorien

Jede KI-Einführung im Unternehmenskontext verteilt sich auf vier Kostenkategorien. Die relative Gewichtung variiert je nach Szenario, aber die Struktur bleibt gleich.

### 1. Modell-Kosten: Token und Hosting (20 - 35 %)

Die sichtbarste Kategorie: API-Gebühren für Cloud-Modelle oder Hosting-Kosten für Self-Hosted-Modelle. Bei Cloud-APIs zahlen Sie pro Token - Input und Output getrennt. Bei Self-Hosting zahlen Sie GPU-Miete, Strom und Wartung. Die Kosten hängen direkt vom Nutzungsvolumen ab: Ein Chatbot mit 50 Nutzern erzeugt andere Token-Volumina als zehn spezialisierte Agenten mit 1.000 Nutzern.

Was häufig übersehen wird: Self-Hosting ist ab einem bestimmten Volumen günstiger als Cloud-APIs, aber die Einstiegskosten sind höher. Eine einzelne GPU mit 80 GB VRAM kostet bei einem deutschen Hosting-Anbieter circa 1.200 Euro pro Monat - unabhängig davon, ob sie voll ausgelastet ist oder nicht. Für Details zur Hosting-Entscheidung siehe [KI-Hosting-Strategien für Enterprise](/de/magazin/ki-hosting-strategien-enterprise/).

### 2. Infrastruktur und Integration (25 - 35 %)

Die größte und am häufigsten unterschätzte Kategorie. Sie umfasst alles, was nötig ist, um ein Sprachmodell in Ihre bestehende IT-Landschaft einzubinden:

- **API-Gateway und Routing-Schicht:** Eine zentrale Stelle, die Anfragen an das passende Modell weiterleitet, Rate Limits durchsetzt und Kosten tracked.
- **RAG-Pipeline:** Wenn Ihre KI auf internes Wissen zugreifen soll, brauchen Sie eine Retrieval-Augmented-Generation-Pipeline: Vektordatenbank, Embedding-Modell, Chunk-Strategie, Indexierung.
- **Systemanbindung:** Integration in bestehende Systeme - ERP, CRM, Dokumentenmanagement, Ticketing. Jede Schnittstelle erfordert Entwicklungsaufwand.
- **Enterprise-AI-Portal:** Eine Oberfläche, über die Mitarbeitende die KI tatsächlich nutzen - mit SSO, Rechtemanagement und Audit-Trail.

Diese Kosten sind weitgehend einmalig. Sie fallen primär in den ersten drei bis sechs Monaten an und amortisieren sich über die Laufzeit. Aber sie müssen geplant und budgetiert werden - sonst entstehen versteckte Kosten durch Workarounds und Nacharbeit.

### 3. Governance und Compliance (15 - 20 %)

Seit dem [EU AI Act](/de/magazin/eu-ai-act-2026-unternehmen/) ist Governance kein optionaler Luxus mehr. Die Kosten in dieser Kategorie umfassen:

- **Risikoklassifizierung:** Bewertung aller KI-Systeme nach EU-AI-Act-Kategorien. Für Hochrisiko-Systeme ist eine formale Konformitätsbewertung erforderlich.
- **Technische Dokumentation:** Der EU AI Act verlangt umfassende Dokumentation von Datenherkunft, Trainingsverfahren, Leistungskennzahlen und Maßnahmen zur Risikominderung.
- **Audit-Trail und Monitoring:** Laufende Protokollierung aller KI-Entscheidungen, insbesondere bei automatisierten Entscheidungsprozessen.
- **Datenschutz:** DSGVO-konforme Datenverarbeitung, Auftragsverarbeitungsverträge, Datenschutz-Folgenabschätzung bei Verarbeitung personenbezogener Daten.
- **Externe Beratung:** Rechtsberatung für regulatorische Fragen, Datenschutzbeauftragter, ggf. Conformity-Assessment-Body.

Der Governance-Anteil steigt mit der Komplexität des KI-Einsatzes. Ein einzelner Chatbot für allgemeine Wissensfragen hat niedrigere Governance-Anforderungen als ein KI-System, das Bewerbungen vorselektiert.

### 4. Personal und Kompetenzaufbau (20 - 30 %)

KI-Systeme müssen betrieben, gewartet und weiterentwickelt werden. Gleichzeitig müssen Mitarbeitende in der Lage sein, die Systeme zu nutzen. Diese Kategorie umfasst:

- **ML-Ops / AI-Engineering:** Mindestens eine Person, die für Modell-Management, Prompt-Optimierung, Monitoring und Troubleshooting zuständig ist. Im Enterprise-Szenario ein dediziertes Team.
- **AI Literacy:** Schulungen für alle Nutzer - seit Februar 2025 gesetzlich vorgeschrieben. Umfasst initiale Schulungen und regelmäßige Auffrischungen.
- **Change Management:** Begleitung der Organisation bei der Umstellung. Neue Prozesse, neue Rollen, neue Verantwortlichkeiten.

In kleinen Szenarien kann der Kompetenzaufbau intern erfolgen - ohne zusätzliche Personalkosten, aber mit Opportunitätskosten. In größeren Szenarien brauchen Sie dediziertes Personal oder externe Unterstützung.

### Kostenverteilung im Überblick

```
Modell-Kosten (Token/Hosting)          ████████░░░░░░░░░░░░  20 - 35 %
Infrastruktur & Integration            ██████████░░░░░░░░░░  25 - 35 %
Governance & Compliance                ██████░░░░░░░░░░░░░░  15 - 20 %
Personal & Kompetenzaufbau             ████████░░░░░░░░░░░░  20 - 30 %
```

Die Verteilung verschiebt sich im Zeitverlauf: Im ersten Jahr dominieren Infrastruktur und Integration. Ab dem zweiten Jahr steigen die relativen Anteile von Modell-Kosten und Personal, während die einmaligen Integrationskosten entfallen.

## Drei Szenarien im Vergleich

Die folgenden drei Szenarien bilden typische Einstiegspunkte ab. Die Zahlen sind Richtwerte, basierend auf Projekterfahrung mit Unternehmen unterschiedlicher Größe. Ihre tatsächlichen Kosten hängen von der bestehenden [IT-Infrastruktur](/de/leistungen/infrastruktur/), den Integrationsanforderungen und dem gewählten Betriebsmodell ab.

| Szenario | Modell-Setup | Monatl. Token/Hosting | Integration | Governance | Personal | Gesamt 12 Mon. |
|---|---|---|---|---|---|---|
| **Einstieg:** 1 Chatbot, 50 Nutzer | Sonnet API | ~500 € | 15.000 € | 5.000 € | 0 (intern) | **~26.000 €** |
| **Standard:** 3 Agenten, 200 Nutzer | Sonnet + Llama self-hosted | ~4.000 € | 60.000 € | 20.000 € | 1 ML-Ops (anteilig) | **~148.000 €** |
| **Enterprise:** 10+ Agenten, 1.000+ Nutzer | Multi-Modell, eigene GPU | ~12.000 € | 150.000 € | 50.000 € | 2 FTE | **~410.000 €** |

### Szenario 1: Einstieg (ca. 26.000 Euro / 12 Monate)

Ein klar definierter Use Case: ein interner Wissens-Chatbot für eine Abteilung, basierend auf Cloud-API. 50 Nutzer, moderates Anfragevolumen, keine Systemintegration über Dokumenten-Upload hinaus. Governance beschränkt sich auf DSGVO-konforme Datenverarbeitung und eine Basis-Dokumentation. Personalkosten entfallen, weil die interne IT-Abteilung den Betrieb neben dem Tagesgeschäft übernimmt.

Dieses Szenario ist der typische Proof of Concept. Es beweist den Nutzen, validiert die Technologie und liefert Erfahrungswerte für die Skalierung. Ein sauberer PoC mit einem klar definierten Use Case liegt typischerweise bei 15.000 bis 30.000 Euro und ist in vier bis sechs Wochen umsetzbar.

### Szenario 2: Standard (ca. 148.000 Euro / 12 Monate)

Drei spezialisierte Agenten für unterschiedliche Prozesse - beispielsweise Dokumentenanalyse, Kundenkommunikation und internes Wissensmanagement. 200 Nutzer, Hybrid-Hosting: unkritische Anfragen über Cloud-API, sensible Daten über ein selbst gehostetes Modell. Integration in mindestens ein bestehendes System. Governance umfasst EU-AI-Act-Risikoklassifizierung und formale Dokumentation. Ein ML-Ops-Engineer kümmert sich anteilig um Modell-Management und Monitoring.

Dieses Szenario ist der produktive Einstieg. Die Organisation hat den PoC abgeschlossen und skaliert auf mehrere Abteilungen. Die Infrastruktur ist auf Wachstum ausgelegt.

### Szenario 3: Enterprise (ca. 410.000 Euro / 12 Monate)

Zehn oder mehr spezialisierte Agenten über mehrere Geschäftsbereiche. Über 1.000 Nutzer. Multi-Modell-Architektur mit eigenen GPUs. Tiefe Integration in ERP, CRM, HR-Systeme und Dokumentenmanagement. Governance auf Enterprise-Niveau: formale Konformitätsbewertung für Hochrisiko-Systeme, Audit-Trail, Governance-Dashboard. Zwei Vollzeit-ML-Ops-Engineers für Betrieb und Weiterentwicklung.

Dieses Szenario setzt voraus, dass die Organisation die Experimentierphase abgeschlossen hat und KI als strategische Infrastruktur betreibt. Die 410.000 Euro klingen nach einer erheblichen Investition - und sie sind es. Aber sie verteilen sich auf ein System, das Hunderte von Prozessen beschleunigt, Fehlerquoten senkt und Entscheidungsgrundlagen verbessert.

### Kontext: Was kosten die Alternativen?

Die Kosten eines KI-Systems sind nie isoliert zu bewerten. Die relevante Vergleichsgröße ist: Was kosten die Prozesse ohne KI? Wenn drei Sachbearbeiter jeweils zwei Stunden pro Tag mit Dokumentenklassifikation verbringen, sind das bei Vollkostenrechnung circa 180.000 Euro pro Jahr - für eine Aufgabe, die ein trainierter Agent in Sekunden erledigt. Der ROI ist selten die Frage. Die Frage ist, wie schnell er eintritt.

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Kostenloses eBook: KI in Finance</p>
<p class="text-body text-gosign-text mb-4">Compliance, Wirtschaftsprüfer und Decision Layer - das Governance-Handbuch für Finance-Verantwortliche.</p>
<a href="/de/ebook/ki-finance-governance-handbuch/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Jetzt kostenlos herunterladen</a>
</div>

## Kostenoptimierung durch Model Switching

Die wirksamste Stellschraube bei den Modell-Kosten ist nicht die Wahl eines günstigeren Modells, sondern die differenzierte Nutzung mehrerer Modelle. Dieses Prinzip heißt Model Switching oder Model Routing.

### Das Prinzip

Nicht jede Anfrage braucht ein Flaggschiff-Modell. Die Mehrheit der Enterprise-Anfragen - Standardantworten, einfache Klassifikation, Datenextraktion aus strukturierten Dokumenten - lässt sich mit Budget-Modellen auf ausreichendem Qualitätsniveau beantworten. Nur für komplexe Aufgaben - mehrstufiges Reasoning, Vertragsanalyse, Entscheidungsvorbereitung - ist ein Flaggschiff-Modell nötig.

Eine Routing-Logik entscheidet automatisch, welches Modell eine Anfrage bearbeitet. Die Kriterien sind konfigurierbar:

- **Komplexität:** Einfache Anfragen an Budget-Modelle, komplexe an Flaggschiff-Modelle.
- **Datensensibilität:** Anfragen mit personenbezogenen Daten an Self-Hosted-Modelle, unkritische Anfragen an Cloud-APIs.
- **Latenzanforderung:** Echtzeitanwendungen an schnelle, kleine Modelle. Batch-Verarbeitung an leistungsstarke Modelle ohne Zeitdruck.
- **Kostenlimit:** Automatische Drosselung, wenn ein Team- oder Abteilungsbudget erreicht ist.

### Einsparpotenzial

In der Praxis verteilen sich Enterprise-Anfragen typischerweise wie folgt:

- **60 - 70 % Standardanfragen:** Einfache Klassifikation, FAQ, Datenextraktion. Budget-Modelle reichen aus.
- **20 - 30 % Mittlere Komplexität:** Zusammenfassungen, strukturierte Analyse, Entwürfe. Preis-Leistungs-Modelle.
- **5 - 15 % Hohe Komplexität:** Mehrstufiges Reasoning, Vertragsanalyse, strategische Dokumente. Flaggschiff-Modelle.

Wenn 65 Prozent der Anfragen statt eines Flaggschiff-Modells ein Budget-Modell nutzen, das ein Zwanzigstel kostet, sinken die Token-Kosten um 40 bis 60 Prozent - bei gleichbleibender Ergebnisqualität für die Gesamtnutzung. Die Details zur [Modellauswahl und den Leistungsprofilen der aktuellen Modelle](/de/magazin/ki-modelle-vergleich-2026/) finden Sie im entsprechenden Artikel dieser Serie.

### Umsetzung

Model Switching erfordert drei Komponenten:

1. **Routing-Engine:** Eine zentrale Logik, die eingehende Anfragen analysiert und an das passende Modell weiterleitet. Dies kann regelbasiert (Keyword-Erkennung, User-Rolle, Datenklassifikation) oder modellbasiert (ein kleines Klassifikationsmodell bewertet die Komplexität) implementiert werden.
2. **Modell-Registry:** Ein zentrales Verzeichnis aller verfügbaren Modelle mit ihren Leistungsprofilen, Kosten und Verfügbarkeit.
3. **Kosten-Monitoring:** Ein Dashboard, das Token-Verbrauch pro Modell, pro Team und pro Use Case transparent macht. Ohne Transparenz gibt es keine Optimierung.

Der Implementierungsaufwand für Model Switching ist überschaubar - typischerweise zwei bis vier Wochen. Die Einsparungen beginnen sofort.

## Budgetplanung: Drei Empfehlungen

**Erstens: Planen Sie mit TCO, nicht mit Token-Preisen.** Wenn Ihnen ein Anbieter die Token-Kosten vorrechnet, fehlen mindestens 65 Prozent des Budgets. Fordern Sie eine TCO-Rechnung, die alle vier Kategorien abdeckt.

**Zweitens: Starten Sie mit einem PoC, aber planen Sie die Skalierung.** Ein PoC für 15.000 bis 30.000 Euro beweist den Nutzen. Aber die Architektur des PoC muss so gebaut sein, dass sie sich ohne Neuaufbau skalieren lässt. Sonst zahlen Sie die Integrationskosten zweimal.

**Drittens: Implementieren Sie Model Switching von Anfang an.** Die Routing-Schicht kostet einmalig wenig und spart dauerhaft viel. Wer von Beginn an differenziert routet, vermeidet den Lock-in auf ein einzelnes Modell und behält die Kostenkontrolle.

---

**📘 Enterprise AI-Infrastruktur Blueprint 2026 - Artikel-Serie**

| ← Vorheriger | Übersicht | Nächster → |
|:---|:---:|---:|
| [Decision Layer & Shadow AI: Kontrolle statt Kontrollverlust](/de/magazin/decision-layer-shadow-ai/) | [Zur Übersicht](/de/magazin/ai-infrastruktur-blueprint-2026/) | [EU AI Act 2026: Was jetzt gilt, was kommt, was Sie tun müssen](/de/magazin/eu-ai-act-2026-unternehmen/) |

*Alle Artikel dieser Serie: [Enterprise AI-Infrastruktur Blueprint 2026](/de/magazin/ai-infrastruktur-blueprint-2026/)*

---

Gosign baut KI-Infrastruktur mit transparenter Kostenstruktur, von der TCO-Analyse bis zum produktiven Betrieb. Wenn Sie wissen wollen, was KI in Ihrem konkreten Setup kostet, sprechen Sie mit uns.

<a href="/de/kontakt/" target="_blank" rel="noopener noreferrer">Termin vereinbaren</a>. 30 Minuten, in denen wir Ihre Kosten realistisch kalkulieren.

--- Wann Mistral, wann Claude Opus? Decision Routing für agentische EU-Enterprise 2026 ---
> Decision Routing statt Modellwahl: Mistral Small auf EU-On-Prem für 70 % der Entscheidungen, Claude Opus 4.7 für die 10 % mit echter Reasoning-Last. EU AI Act Art. 13 ready.

Der Modellmarkt ist schneller reif geworden als die meisten Enterprise-Architekturen. Claude Opus 4.7, GPT-5.5 und Gemini 3.1 Pro konvergieren in der Qualität. Mistral La Plateforme betreibt seine Inferenz aus einem französischen Rechenzentrum unter EU-Recht. OpenAI hat im August 2025 gpt-oss unter Apache 2.0 veröffentlicht. Meta und Mistral liefern Open-Weight-Modelle, die auf einer einzelnen GPU produktiv laufen.

Und trotzdem entscheiden sich die meisten Enterprise-KI-Projekte für ein einzelnes Modell und routen jeden Workload dort durch. Diese Wahl bestimmt still mit: die Cloud-Souveränitäts-Position, die Audit-Kosten unter dem EU AI Act und den Spielraum für Kostenoptimierung. Ein Modell zu wählen ist keine Modell-Entscheidung. Es ist eine Architektur-Entscheidung.

<div class="not-prose my-12 border border-gosign-border bg-gosign-light rounded-card p-6 lg:p-8">
<p class="text-h3 font-bold text-gosign-dark mb-3">Auf einen Blick - Agentischer KI-Stack für EU-Enterprise 2026</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Rund 70 % der agentischen Entscheidungen in einem sauber zerlegten Enterprise-Workflow sind Regelanwendung oder strukturierte Extraktion. In typischen EU-Hosting-Setups erledigt Mistral Small 3.2 auf einer einzelnen GPU diese Last zu etwa 1/30 des Claude-Opus-Listenpreises.</li>
<li>Mistral hat zwei klar getrennte Deployment-Flächen: La Plateforme (EU-gehosteter API-Endpunkt, französische Infrastruktur, ab Q2 2026 eigenes Rechenzentrum Bruyères-le-Châtel) und Mistral Small 3.2 (Apache 2.0, vollständig self-hostbar, 24B Parameter).</li>
<li>Die verbleibenden 8 bis 10 % der Entscheidungen - komplexes Reasoning, jurisdiktionsübergreifende Analyse, Edge-Case-Eskalation - rechtfertigen Claude Opus 4.7 oder GPT-5.5. Dort werden Token-Kosten verdient, nicht verschwendet.</li>
<li>Die Exponiertheit gegenüber dem US CLOUD Act gilt auch für EU-Region-Deployments US-amerikanischer Anbieter. Schrems II hat das konkret gemacht. Self-Hosted-Optionen wie Mistral Small, gpt-oss-120b oder DeepSeek V4-Flash (April-2026-Preview, MIT, 284B/13B Aktiv-MoE) sind die einzigen Architekturen mit Null-CLOUD-Act-Fläche.</li>
<li>EU AI Act Artikel 13 verlangt transparenten Betrieb von Hochrisiko-Systemen. Eine Decision-Routing-Schicht erzeugt das Audit-Artefakt: pro Entscheidung ein Record mit Input, Regelversion, Modell, Confidence und menschlichem Prüfer, sobald eskaliert wurde.</li>
</ul>
</div>

## Sie evaluieren Mistral - was Sie eigentlich evaluieren ist Ihre EU-Cloud-Strategie

Ein typischer Suchverlauf 2026 sieht so aus: Compliance fragt nach einer EU-Alternative zu OpenAI. Procurement sammelt Vendor-Pitches. Architecture beginnt mit der Mistral-Evaluation. Innerhalb einer Woche hat sich das Gespräch von "welches Modell" zu "wie steht es um die CLOUD-Act-Exposition" und "wie operationalisieren wir EU AI Act Artikel 13 für Hochrisiko-Systeme" verschoben.

Der CLOUD Act folgt der Provider-Kontrolle, nicht dem Datenstandort. Ein US-Anbieter mit EU-Rechenzentren - Azure OpenAI EU, AWS Bedrock Frankfurt, GCP Vertex europe-west - kann weiterhin per US-Anordnung zur Datenherausgabe verpflichtet werden. Die Europäische Kommission wird in Q2 2026 voraussichtlich ein [Tech Sovereignty Package](https://www.kiteworks.com/cybersecurity-risk-management/eu-tech-sovereignty-package-cloud-act/) vorlegen, das den öffentlichen Sektor bei sensiblen Workloads in Gesundheit, Finanzwesen und Justiz auf nicht-US-Anbieter verpflichtet. Der private Sektor liest diese Signale mit.

Eine Leserschaft braucht an dieser Stelle einen eigenen Abzweig: Berufsgeheimnisträger. Für Kanzleien, Steuerberater und Wirtschaftsprüfer ist die Souveränitätsfrage nicht nur CLOUD-Act-Abwägung, sondern Strafrecht - § 203 StGB und das Berufsrecht (§ 43e BRAO, § 62a StBerG, § 50a WPO) stellen Anforderungen an den Bezugsweg, die ein generischer Modellvergleich nicht beantwortet. Diesen Sonderfall behandelt der eigene Bereich [KI für Berufsgeheimnisträger](/de/berufsgeheimnistraeger/); dieser Artikel bleibt beim allgemeinen Enterprise-Routing.

Mistral interessiert nicht, weil es Claude auf einer Bestenliste schlägt. Es interessiert, weil es eine Position einnimmt, die kein US-Anbieter besetzen kann: ein Frontier-Class-Anbieter aus Europa mit [eigener EU-Infrastruktur](https://help.mistral.ai/en/articles/347629-where-do-you-store-my-data-or-my-organization-s-data) und vollständig offener Modellreihe unter Apache 2.0. Ab Q2 2026 betreibt das Unternehmen ein eigenes Rechenzentrum bei Paris mit [13.800 NVIDIA GB300 GPUs](https://ioplus.nl/en/posts/why-mistrals-830m-raise-is-a-win-for-european-autonomy) und 44 Megawatt Kapazität. Damit ist Mistral der einzige Frontier-Anbieter, der End-to-End-EU-Residenz auf Infrastruktur unter EU-Recht garantieren kann.

Aber das fasst die Frage falsch. Die eigentliche Frage ist nicht "Mistral oder OpenAI". Sie lautet "welche Entscheidungen gehen wohin, und wie weisen Sie das einem Prüfer nach".

## Mistral sind zwei Welten: La Plateforme in Frankreich oder Mistral Small unter Apache 2.0

Die Verwirrung beginnt, wenn "Mistral" als ein Produkt behandelt wird. Es sind zwei Produktfamilien mit unterschiedlichen Deployment-Flächen und unterschiedlichen Compliance-Konsequenzen.

| Mistral-Produkt | Deployment | Lizenz / Kosten | EU-souverän |
|---|---|---|---|
| Mistral Medium 3.1 | La Plateforme (FR-gehosteter API) oder Azure AI Foundry | Token-basiert, proprietär | Ja via La Plateforme |
| Mistral Small 3.2 | Self-hosted on-prem | Apache 2.0, nur GPU-Kosten | Ja bei EU-Hardware |
| Mixtral 8x22B | Self-hosted on-prem | Apache 2.0, nur GPU-Kosten | Ja bei EU-Hardware |
| Codestral | La Plateforme | Token-basiert, proprietär | Ja via La Plateforme |

*"EU-souverän" heißt hier: außerhalb der Reichweite des US CLOUD Act. Sowohl La Plateforme (französische Jurisdiktion) als auch Self-Hosting auf EU-Hardware qualifizieren sich. Azure AI Foundry nicht - auch nicht mit EU-Datenresidenz, weil Microsoft weiterhin CLOUD-Act-pflichtig ist.*

Mistral Medium 3.1 ist das proprietäre Frontier-Class-Flaggschiff. Es läuft auf Mistrals eigener französischer Infrastruktur, erreichbar via API. Token-abgerechnet. EU-souverän by default. Ab Q2 2026 übernimmt das eigene Rechenzentrum Bruyères-le-Châtel die Inferenz für Kunden mit französischem Residenz-Erfordernis.

[Mistral Small 3.2](https://mistral.ai/news/mistral-small-3-1) ist das Open-Weight-Arbeitspferd. 24 Milliarden Parameter. 128K Token Kontext. Vision-Fähigkeit nativ enthalten. Veröffentlicht 2025 unter Apache 2.0. Läuft auf einer einzelnen NVIDIA RTX 4090 oder einem Mac mit 32 GB RAM. Durchsatz rund 150 Token pro Sekunde auf Consumer-Hardware.

Die beiden sind nicht redundant. La Plateforme ist sinnvoll, wenn Sie EU-Souveränität wollen, ohne GPU-Infrastruktur zu betreiben. Mistral Small 3.2 ist sinnvoll, wenn die Entscheidung so hochvolumig ist, dass Token-Billing zum Kostentreiber wird - oder wenn die Daten so sensibel sind, dass selbst EU-API-Traffic zu viel Fläche bedeutet.

Die Architektur-Frage lautet welche Deployment-Fläche für welche Entscheidung - nicht welcher Anbieter für welche Bestenliste.

<figure class="not-prose my-12">
<svg viewBox="0 0 800 600" xmlns="http://www.w3.org/2000/svg" role="img" aria-labelledby="radar-title-de radar-desc-de" class="w-full h-auto max-w-3xl mx-auto">
<title id="radar-title-de">Modell-Profil-Vergleich auf sechs Enterprise-Dimensionen (Mai 2026)</title>
<desc id="radar-desc-de">Spider-Chart-Vergleich von vier repräsentativen Modellen auf sechs Enterprise-relevanten Dimensionen, jeweils mit Skala 0 bis 10. Claude Opus 4.7 (Cloud, Anthropic): Reasoning-Qualität 10, Coding-Performance 10, Multimodal 7, Kosten-Effizienz 3, Inference-Latenz 6, EU-Souveränität 4. GPT-5.5 (Cloud, OpenAI/Azure): Reasoning 10, Coding 10, Multimodal 9, Kosten 3, Latenz 7, EU-Souveränität 4. Mistral Small 3.2 (self-hostbar, Apache 2.0): Reasoning 6, Coding 7, Multimodal 8, Kosten 10, Latenz 9, EU-Souveränität 10. DeepSeek V4-Pro (self-hostbar, MIT): Reasoning 9, Coding 8, Multimodal 5, Kosten 7, Latenz 7, EU-Souveränität 9. Cloud-Flaggschiffe dominieren bei Reasoning, Coding und Multimodal, verlieren aber bei Kosten-Effizienz und Souveränität. Self-hostbare Modelle invertieren dieses Muster. Die Decision-Routing-Schicht kombiniert beide Formen pro Mikro-Entscheidung, statt einen Champion zu wählen.</desc>
<defs>
<style>
.axis-de { stroke: #d4d0cb; stroke-width: 1; fill: none; }
.grid-de { stroke: #d4d0cb; stroke-width: 0.5; fill: none; opacity: 0.5; }
.label-de { font-family: -apple-system, system-ui, sans-serif; font-size: 12px; fill: #1a2e4d; text-anchor: middle; font-weight: 600; }
.scale-de { font-family: -apple-system, system-ui, sans-serif; font-size: 9px; fill: #94a3b8; text-anchor: middle; }
.legend-de { font-family: -apple-system, system-ui, sans-serif; font-size: 12px; fill: #1a2e4d; font-weight: 500; }
.legend-sub-de { font-family: -apple-system, system-ui, sans-serif; font-size: 10px; fill: #64748b; }
</style>
</defs>
<circle cx="400" cy="300" r="50" class="grid-de"/>
<circle cx="400" cy="300" r="100" class="grid-de"/>
<circle cx="400" cy="300" r="150" class="grid-de"/>
<circle cx="400" cy="300" r="200" class="grid-de"/>
<circle cx="400" cy="300" r="250" class="grid-de"/>
<text x="408" y="100" class="scale-de">10</text>
<text x="408" y="150" class="scale-de">8</text>
<text x="408" y="200" class="scale-de">6</text>
<text x="408" y="250" class="scale-de">4</text>
<text x="408" y="300" class="scale-de">2</text>
<line x1="400" y1="300" x2="400" y2="50" class="axis-de"/>
<line x1="400" y1="300" x2="616.5" y2="175" class="axis-de"/>
<line x1="400" y1="300" x2="616.5" y2="425" class="axis-de"/>
<line x1="400" y1="300" x2="400" y2="550" class="axis-de"/>
<line x1="400" y1="300" x2="183.5" y2="425" class="axis-de"/>
<line x1="400" y1="300" x2="183.5" y2="175" class="axis-de"/>
<text x="400" y="38" class="label-de">Reasoning-Qualität</text>
<text x="630" y="165" class="label-de">Coding-Performance</text>
<text x="630" y="438" class="label-de">Multimodal</text>
<text x="400" y="572" class="label-de">Kosten-Effizienz</text>
<text x="170" y="438" class="label-de">Inference-Latenz</text>
<text x="170" y="165" class="label-de">EU-Souveränität</text>
<polygon points="400,50 616.5,175 562,387 400,375 335,338 313,225" fill="#fcd34d" fill-opacity="0.25" stroke="#b8941f" stroke-width="2"/>
<polygon points="400,50 616.5,175 595,413 400,375 313,363 313,225" fill="#3a6090" fill-opacity="0.20" stroke="#3a6090" stroke-width="2" stroke-dasharray="6 3"/>
<polygon points="400,150 551.5,213 579,400 400,550 205,425 183.5,175" fill="#1a2e4d" fill-opacity="0.20" stroke="#1a2e4d" stroke-width="2"/>
<polygon points="400,75 595,188 508,363 400,475 248,400 205,200" fill="#9a5a5a" fill-opacity="0.18" stroke="#9a5a5a" stroke-width="2" stroke-dasharray="3 3"/>
<g transform="translate(40, 590)">
<rect x="0" y="-15" width="15" height="3" fill="#b8941f"/>
<text x="22" y="-9" class="legend-de">Claude Opus 4.7</text>
<text x="22" y="3" class="legend-sub-de">Cloud, Anthropic</text>
</g>
<g transform="translate(195, 590)">
<rect x="0" y="-15" width="15" height="3" fill="#3a6090"/>
<text x="22" y="-9" class="legend-de">GPT-5.5</text>
<text x="22" y="3" class="legend-sub-de">Cloud, OpenAI/Azure</text>
</g>
<g transform="translate(370, 590)">
<rect x="0" y="-15" width="15" height="3" fill="#1a2e4d"/>
<text x="22" y="-9" class="legend-de">Mistral Small 3.2</text>
<text x="22" y="3" class="legend-sub-de">self-host, Apache 2.0</text>
</g>
<g transform="translate(560, 590)">
<rect x="0" y="-15" width="15" height="3" fill="#9a5a5a"/>
<text x="22" y="-9" class="legend-de">DeepSeek V4-Pro</text>
<text x="22" y="3" class="legend-sub-de">self-host, MIT</text>
</g>
</svg>
<figcaption class="text-sm text-gosign-text-light text-center mt-4 max-w-2xl mx-auto">
<strong>Modell-Profil auf sechs Enterprise-Dimensionen</strong> - die c't-typische Vergleichsansicht, jeweils mit Skala 0 bis 10. Cloud-Flaggschiffe (Claude Opus 4.7, GPT-5.5) dominieren bei Reasoning, Coding, Multimodal, verlieren aber bei Kosten-Effizienz und EU-Souveränität. Self-hostbare Modelle (Mistral Small 3.2, DeepSeek V4-Pro) invertieren diese Form. Es gibt kein einzelnes "bestes" Modell - die Routing-Schicht wählt die richtige Form pro Mikro-Entscheidung.
</figcaption>
</figure>

## Warum Mistral Small als Default, nicht gpt-oss oder DeepSeek

Eine berechtigte Frage, sobald Self-Hosting beschlossen ist: Warum gewinnt Mistral Small 3.2 den Arbeitspferd-Slot gegenüber [gpt-oss-120b](https://openai.com/index/introducing-gpt-oss/) (Apache 2.0, 117B Parameter MoE, 5. August 2025) oder [DeepSeek V4](https://api-docs.deepseek.com/news/news260424) (MIT, Preview vom 24. April 2026; V4-Flash 284B/13B aktiv, V4-Pro 1,6T/49B aktiv, 1M Kontext)? Alle drei sind in irgendeiner Konfiguration self-hostbar. Die Differenzierung liegt bei Hardware-Floor, Sprachabdeckung und Modalität.

| Open-Source-Modell | Hardware-Floor | Stärke | Schwäche | Sweet Spot |
|---|---|---|---|---|
| Mistral Small 3.2 (24B, Apache 2.0) | 1x RTX 4090 (~1.500 EUR einmalig) oder Mac M2/M3 32GB | Volumen, multilingual (DE/EN/PL/ES/BR), Vision-fähig, ~150 Token/s | Kein Top-Tier-Reasoning | **Default-Arbeitspferd für die 70-%-Volumen-Bandbreite** |
| gpt-oss-120b (117B MoE, Apache 2.0) | 1x H100/A100 80GB (~30.000 EUR oder ~1.200 EUR/Monat gehostet) | Reasoning auf o4-mini-Niveau, MoE-effizient | Keine Vision, Datacenter-Hardware nötig | **Heavy-Reasoning-Alternative zu Claude Opus, wenn auch das on-prem bleiben muss** |
| DeepSeek V4-Flash (MIT, Apr-2026-Preview) | 1-2x H100/A100 80GB mit Quant (~30-60k EUR CAPEX oder ~1.500-5.000 EUR/Monat gehostet); 4x H100 für volle Präzision | Frontier-Reasoning bei moderater Hardware, 1M Kontext, nativ multimodal | Preview-Status - Benchmarks vor Produktion neu prüfen | **Math/Logik-Spezialist + 1M-Kontext für Portfolio-Analyse** |
| DeepSeek V4-Pro (MIT, Apr-2026-Preview) | 8x H100 Cluster (~240.000 EUR CAPEX oder ~10.000-12.000 EUR/Monat gehostet) | Nähert sich GPT-5.5/Gemini 3.1 Pro an, Agent-Tool-optimiert | DAX-Konzern absolut machbar, gehobener Mittelstand budget-fit, KMU via API/hosted (Together.ai, Fireworks, DeepSeek API) | **Frontier-Reasoning unter offener Lizenz - on-prem für Konzern, API für KMU** |
| Llama 4 Scout (Meta Llama License) | 1x GPU | 10M Token Kontext | Lizenzschranke ab 700M MAU | **Ultra-Long-Context für komplette Vertragsportfolios** |

Drei konkrete Gründe, warum Mistral Small den Default-Slot bekommt:

**Hardware-Schwelle.** Mistral Small läuft auf Consumer-Hardware. gpt-oss-120b braucht eine Datacenter-GPU. Bei einer Enterprise-Pipeline mit fünf bis zehn Worker-Knoten ist der Hardware-Aufschlag pro Knoten erheblich. Wenn 70 % der Entscheidungen Klassifikation oder Extraktion sind, ist gpt-oss-Reasoning-Kapazität für die Volumen-Arbeit überdimensioniert.

**Multilinguales Trainingskorpus.** Mistral wurde von Beginn an auf Französisch, Deutsch, Spanisch und Italienisch trainiert. gpt-oss ist US-zentrisch mit englisch-dominantem Trainingsmaterial. Für eine EU-Enterprise-Pipeline, die polnische, spanische oder portugiesische Dokumente verarbeitet, ist Mistral Small ab Tag eins das bessere Arbeitspferd.

**Vision nativ enthalten.** Mistral Small 3.2 hat eine integrierte Vision-Fähigkeit. gpt-oss nicht. Für HR-Onboarding (Pass-Scans, Bescheinigungen, ELStAM-Formulare) oder Belegverarbeitung (PDF-Rechnungen mit Layout) ist das ein hartes K.-o.-Kriterium.

gpt-oss-120b oder DeepSeek V4-Flash kommen on-prem ins Spiel als Heavy-Reasoning-Optionen, wenn Claude Opus 4.7 via API aus Compliance-Gründen nicht eingesetzt werden kann. DeepSeek V4-Pro nähert sich der Frontier-Closed-Source-Leistung unter MIT-Lizenz; für DAX-Konzerne und gehobenen Mittelstand ist der 8x-H100-Cluster (~240.000 EUR CAPEX oder ~10.000-12.000 EUR/Monat gehostet) eine Standard-IT-Budget-Position, für KMU unter 500 Mitarbeitenden ist der realistische Weg API/hosted (Together.ai, Fireworks, DeepSeek API). Keines ersetzt Mistral Small als Volumen-Arbeitspferd - sie ergänzen es für die schwereren Entscheidungen. Den ausführlichen Self-Hosting-Vergleich behandelt [Selbstgehostete Open-Source-KI 2026: Mistral, gpt-oss, DeepSeek V4, Llama 4 im Enterprise-Stack](/de/magazin/selbst-gehostete-open-source-ki-2026/) (separater Artikel).

## Welches Modell für was? Die Komplexitätsverteilung agentischer Entscheidungen

Ein typischer Enterprise-Agent zerfällt in 14 bis 50 Mikro-Entscheidungen. Die Komplexität ist nicht gleichmäßig verteilt. In einer gut instrumentierten HR- oder Finance-Pipeline folgt sie einem Muster, das wir konsistent messen:

| Entscheidungstyp | Anteil | Komplexität | Bestes Modell | Tatsächliche Kosten pro 1M Token |
|---|---|---|---|---|
| Regelanwendung (Steuerklasse aus Stammdaten, Vertragstyp-Klassifikation, Schwellenwert-Prüfungen) | 50 % | Niedrig | Oft kein LLM nötig; sonst Mistral Small 3.2, Llama 4 Scout, gpt-oss-20b | ~0 bis ~0,50 USD |
| Strukturierte Extraktion (Felder aus PDFs, Tabellen normalisieren, OCR-korrigierte Positionsdaten) | 25 % | Mittel | Mistral Small 3.2, Mistral Medium 3.1, gpt-oss-120b | ~0,50 bis ~2 USD |
| Kontextuelle Klassifikation (BetrVG-§87-Klauseln, Anomalien in Spesenabrechnungen, Lieferanten-Risikoflags) | 15 % | Mittel-hoch | Mistral Medium 3.1, Claude Haiku 4.5, GPT-5 mini | ~1 bis ~5 USD |
| Komplexes Reasoning (Anti-Diskriminierungs-Pruefung nach AGG inkl. Beweislastumkehr-Risiko, mehrstufige Argumentkette ueber Jurisdiktionen, Eskalations-Entwurf) | 8 % | Hoch | Claude Opus 4.7, GPT-5.5 | ~15 bis ~25 USD |
| Multimodal (Bild + Text korreliert, Video-Segmente, technische Zeichnungen) | 2 % | Hoch | Gemini 3.1 Pro | ~5 bis ~10 USD |

Die Konsequenz ist eindeutig. Wer jede Entscheidung durch Claude Opus routet, zahlt Flaggschiff-Token-Tarife für die 75 % der Arbeit, die kein Flaggschiff-Reasoning braucht. Wer jede Entscheidung durch Mistral Small routet, spart Token-Kosten, scheitert aber an den 8 % mit echtem Reasoning-Bedarf - und zahlt den Preis in Prüfungsfeststellungen, nicht in Token.

Der [Stanford-HAI-AI-Index 2025](https://hai.stanford.edu/ai-index/2025-ai-index-report) verzeichnet, dass 65,7 % der 2023 neu veröffentlichten Foundation-Modelle Open-Source waren - 2021 waren es noch 33,3 %. Die Enterprise-KI-Adoption hat 78 % überschritten. Der Markt entscheidet nicht mehr zwischen proprietär und offen. Er entscheidet, wie er sie kombiniert.

## Mistral Small als Arbeitspferd: ein HR-Onboarding-Agent mit 14 Mikro-Entscheidungen

Konkretes Beispiel. Ein HR-Onboarding-Agent erhält den unterschriebenen Vertrag eines neuen Mitarbeitenden plus Begleitdokumente (Pass-Kopie, ELStAM-Daten, Bankverbindung, Qualifikationsnachweise). Aufgabe: Stammsatz erzeugen, Pre-Employment-Compliance-Checks fahren, Onboarding terminieren, DEÜV-Meldung nach § 28a SGB IV anstoßen. 14 Mikro-Entscheidungen insgesamt, von Regex-Validierung bis AGG-Analyse. Der Agent fällt unter EU AI Act Annex III Punkt 4 (Beschäftigung, Personalmanagement) - daraus folgen die Art. 9 (Risk Management System), Art. 13 (Transparenz) und Art. 14 (Menschliche Aufsicht) Pflichten.

Eine naive Implementierung schickt jeden Schritt durch Claude Opus 4.7. Eine zerlegte Implementierung routet pro Schritt. Der Decision Layer hält die Routing-Regeln: Jeder Schritt ist vor Ausführung als REGELWERK, KI AUTONOM oder MENSCH klassifiziert.

**REGELWERK:** Die Entscheidung ist deterministisch. Die deutsche Steuer-ID folgt einer Prüfziffer, die IBAN folgt ISO 13616. Keine Interpretation, kein Modell nötig. Hier ist der Agent Executor, nicht Reasoner.

**KI AUTONOM:** Die Entscheidung ist Klassifikation oder Extraktion mit ausreichender Konfidenz. Dokumenttyp-Erkennung, Vertragsart-Klassifikation, strukturierte Feldextraktion. Ein kleines Modell mit klarem Schema schlägt ein Flaggschiff mit vagem Prompt.

**MENSCH:** Die Entscheidung berührt Ermessen, Diskriminierungsrisiko, Mitbestimmungs-Scope oder Schwellenwertverletzungen. AGG-Diskriminierungsmerkmale (§ 1) i.V.m. § 7 Benachteiligungsverbot mit § 22 Beweislastumkehr und § 15 Schadensersatz bis 3 Brutto-Monatsgehälter, Mitbestimmung nach § 99 BetrVG bei personellen Einzelmaßnahmen (Zustimmungsverfahren des Betriebsrats, nicht Anzeigepflicht), Gehaltsanomalie über der vereinbarten Grenze. Das Modell bereitet den Fall vor; der Mensch unterschreibt die Entscheidung.

Die folgenden acht Schritte sind ein repräsentatives Routing-Muster aus einer typischen 14-Schritt-Pipeline. Die vollständige Routing-Tabelle aller 14 Schritte liegt in der Decision-Layer-Konfiguration des Kunden.

| Schritt | Entscheidung | Layer | Routing-Ziel |
|---|---|---|---|
| 1 | Dokumenttypen im Upload erkennen | KI AUTONOM | Mistral Small 3.2 on-prem |
| 2 | Personendaten extrahieren (Name, Adresse, Geburtsdatum, Steuer-ID) | KI AUTONOM | Mistral Small 3.2 on-prem |
| 3 | Steuer-ID-Format validieren (DE ELStAM nach §39e EStG, IBAN nach ISO 13616) | REGELWERK | Regel-Engine, kein LLM |
| 4 | Vertragstyp klassifizieren (befristet, unbefristet, Probezeit) | KI AUTONOM | Mistral Small 3.2 |
| 5 | Vertragsklauseln gegen Betriebsvereinbarung v2024-3 prüfen | KI AUTONOM | Mistral Medium 3.1 (La Plateforme) |
| 6 | Klauseln auf Diskriminierungsrisiko nach AGG (§ 1 Merkmale, § 7 Benachteiligungsverbot, § 22 Beweislastumkehr, § 15 Schadensersatz) markieren | MENSCH (KI bereitet vor) | Claude Opus 4.7 entwirft die Analyse, HR-Manager unterschreibt |
| 7 | Gehaltsanomalien nach Rolle/Standort/Senioritätsstufe erkennen | KI AUTONOM | Mistral Medium 3.1 |
| 8 | Entscheiden ob Zustimmungsverfahren nach § 99 BetrVG (personelle Einzelmaßnahme) eingeleitet werden muss | MENSCH (KI bereitet vor) | Mistral Medium 3.1 vor-klassifiziert, Betriebsrats-Kontakt unterschreibt |

Von den 14 Gesamtschritten sind sechs REGELWERK (kein LLM nötig: IBAN-Check, Vollständigkeits-Checks, deterministische Registrierungsmeldungen). Sechs sind KI AUTONOM (Mistral Small oder Medium). Zwei sind MENSCH mit KI-Vorbereitung (Claude Opus für die Anti-Diskriminierungs-Pruefung nach AGG, Mistral Medium für die Vorklassifikation, ob das Zustimmungsverfahren nach § 99 BetrVG einzuleiten ist).

In typischen EU-Hosting-Setups liegen die Inferenzkosten pro Onboarding bei rund 1 bis 3 USD. Eine reine Flaggschiff-Architektur (jeder Schritt durch Claude Opus) landet eher bei 25 bis 40 USD pro Onboarding - und verarbeitet Schritt 1 und 2 auf US-Infrastruktur unter CLOUD-Act-Exposition. Gleiches Geschäftsergebnis. Anderer Audit-Trail. Andere Kostenkurve. Andere Souveränitäts-Position.

## Was der Prüfer sieht: Decision Records nach EU AI Act Artikel 13

[EU AI Act Artikel 13](https://artificialintelligenceact.eu/article/13/) verlangt, dass Hochrisiko-KI-Systeme so transparent betrieben werden, dass Betreiber die Ausgaben angemessen interpretieren und verwenden können. Das System muss mit Anweisungen zu Genauigkeitsmetriken, Robustheit, getesteter Cybersecurity-Stufe, menschlicher Aufsicht nach Artikel 14 und erforderlichen Hardware-Ressourcen ausgeliefert werden.

Für BaFin-regulierte Institute koppeln sich an Art. 13 die Pflichten aus § 25b KWG und MaRisk AT 9 (Auslagerung): wesentliche Auslagerung an Mistral La Plateforme löst Meldepflicht nach § 24 Abs. 1 Nr. 16 KWG aus. DORA Art. 28-30 verlangt seit 17. Januar 2025 zusätzlich Eintrag im ICT-Drittparteien-Register. EBA Guidelines on Outsourcing (EBA/GL/2019/02) gelten ergänzend. Decision Records erfüllen die Dokumentations-Pflicht in allen drei Frameworks parallel.

Für den Bilanzprüfer ist Art. 13 nur ein Anker. GoBD 2025 Rz. 156-176 verlangen dokumentierte Interne Kontrollverfahren bei elektronischer Verarbeitung mit 10-Jahres-Aufbewahrungspflicht nach § 147 AO. IDW PS 951 (Internes Kontrollsystem) und IDW PS 980 (Compliance-Management-System) sind die Prüf-Standards, gegen die der Konzernabschlussprüfer mit KI-Komponente arbeitet.

Die Frage des Wirtschaftsprüfers am Prüfungstag lautet nicht "welches Modell habt Ihr eingesetzt", sondern "zeigen Sie mir den Decision Record für Personalfall 2026-01-1873, Schritt 8".

Ein Decision Record aus einer Routing-Schicht enthält pro Mikro-Entscheidung:

- **Input-Snapshot** (die relevanten Felder aus dem Upstream-Kontext, mit PII-Behandlung)
- **Regelversion** (welche Version der Betriebsvereinbarung galt; v2024-3)
- **Entscheidungstyp** (Regelanwendung, KI-Klassifikation, KI-Reasoning, menschliche Freigabe)
- **Eingesetztes Modell** (bei KI: Mistral-Small-3.2-Instruct, deployed auf Cluster A04, Region eu-de-fra)
- **Confidence-Score** (bei KI: 0,94)
- **Reasoning-Chain** (falls relevant: die Zwischen-Reasoning-Schritte des Modells, wörtlich)
- **Ergebnis** (Klassifikationslabel, extrahierter Wert oder Eskalations-Flag)
- **Menschlicher Prüfer** (bei Eskalation: Name, Rolle, Zeitstempel)
- **Anfechten-Button** für KI-Entscheidungen (die betroffene Person kann eine automatisierte Entscheidung anfechten und löst damit eine erneute Entscheidung unter menschlicher Prüfung aus - der von DSGVO Art. 22 verlangte Mechanismus)

Eine Pipeline, die diese Records produziert, macht aus der Modellfrage eine Routing-Frage. Der Prüfer fragt nicht "ist Mistral so gut wie Claude". Er fragt "ist die Entscheidung End-to-End dokumentiert und reproduzierbar". Die Aufsichtsrats-Frage geht einen Schritt weiter: Wer unterschreibt eine Entscheidung, in der eine diskriminierende Vertragsklausel (AGG-Verstoss) durchgerutscht ist, weil ein Routing-Ziel an einen Menschen hätte eskalieren müssen? Die Routing-Schicht macht diese Unterschrift nachweisbar.

## Die Architektur-Frage: Decision Layer oder Vendor Lock-in

Ein modell-agnostischer Decision Layer ist kein Feature. Er ist die Vorbedingung für fast alles andere in diesem Artikel. Ohne ihn bleiben die Routing-Muster oben abstrakt.

| Ohne Decision Layer | Mit Decision Layer |
|---|---|
| Die Modellwahl ist klebrig. Provider-Wechsel bedeutet, den Agenten neu zu bauen. | Provider-Wechsel ist eine Konfigurationsänderung. Modelle sind pro Entscheidungsschritt austauschbar. |
| Kostenoptimierung passiert im Nachhinein, in Verhandlungen mit einem einzelnen Anbieter. | Kostenoptimierung ist eingebaut: Entscheidungen niedriger Komplexität routen automatisch an das günstigste valide Modell. |
| Souveränität ist binär: entweder CLOUD-Act-Exposition akzeptieren oder alles self-hosten. | Souveränität ist pro Entscheidung: sensible Schritte laufen EU-on-prem, unsensible dürfen Cloud-APIs nutzen. |
| Audit-Trail existiert in verstreuten Logs und wird on demand rekonstruiert. | Audit-Trail IST das Routing-Log. EU-AI-Act-Artikel-13-Compliance ist eine Datenbankabfrage, kein Projekt. |
| Ein neues Modell heißt eine neue Integration. | Ein neues Modell heißt ein neuer Eintrag im Router. Routing-Regeln existieren bereits. |

*Diese Tabelle zeigt architektonische Unterschiede, keine Qualitätsurteile.*

Der Decision Layer ist der Ort, an dem die Modellwahl operationalisiert wird. Der Modellmarkt verändert sich monatlich. Preise fallen. Neue Flaggschiffe erscheinen. Open-Weight-Qualität holt auf. Eine Decision-Layer-Architektur absorbiert diese Veränderung. Eine vendor-gebundene Architektur zahlt die Migrationskosten jedes Mal.

## Fazit

Die interessante Frage für einen EU-Enterprise-CTO 2026 lautet nicht "Mistral oder OpenAI". Sie lautet "welcher Anteil meiner agentischen Entscheidungen braucht Flaggschiff-Reasoning, und wie weise ich das meinem Prüfer nach".

In einem sauber zerlegten Agenten erledigt Mistral Small 3.2 auf einer einzelnen EU-GPU den Großteil der Arbeit zu vernachlässigbaren Token-Kosten. Mistral Medium 3.1 auf La Plateforme deckt die Mittel-Bandbreite mit EU-Souveränität ab. Claude Opus 4.7 oder GPT-5.5 nehmen die wirklich schweren Fälle. Das Routing ist die Architektur. Der Audit-Trail ist das Compliance-Artefakt. Der Decision Layer ist der Ort, an dem all das spezifiziert wird.

Andere publizieren Modellvergleichs-Tabellen. Wir bauen die Routing-Schicht, die sie operationalisiert. Der Modellmarkt verändert sich monatlich; die Routing-Architektur überlebt fünf Modellgenerationen. Der Quellcode bleibt in der Kundeninfrastruktur. Modelle bleiben austauschbar. EU-AI-Act-Artikel-13-Compliance ist eine Eigenschaft der Architektur, kein Projekt am Ende.

Wenn Sie wissen wollen, wie die Komplexitätsverteilung Ihres Agenten tatsächlich aussieht, [vereinbaren Sie ein Gespräch](/de/kontakt/).

--- LLM Self-Hosting für Enterprise - Azure, GCP, On-Premise ---
> Sprachmodelle Self-Hosted betreiben: DeepSeek, Llama, Mistral. Deployment auf Azure, GCP, On-Premise oder Hybrid. Entscheidungshilfe für CTOs

## Warum Self-Hosting?

Für viele Enterprise-Kunden ist die Frage nicht ob KI eingesetzt wird, sondern wo die Daten verarbeitet werden. Bei der Nutzung von Cloud-APIs (OpenAI, Anthropic, Google) verlassen Daten die eigene Infrastruktur. Für regulierte Branchen - Finance, Healthcare, öffentlicher Sektor - kann das ein Ausschlusskriterium sein.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Auf einen Blick - LLM Self-Hosting für Enterprise</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Self-Hosting hält alle Daten im Unternehmensnetzwerk - kein Drittanbieter-Processing, volle Kontrolle über Modell, Daten und Inferenz.</li>
<li>Open-Source-Modelle (Llama, Mistral, DeepSeek, gpt-oss) können auf Azure ML, GCP Vertex AI, eigenen GPU-Servern oder hybrid betrieben werden.</li>
<li>GPU-Sizing ist der primäre Kostentreiber: Ein 7B-Modell läuft auf einer GPU, ein 70B-Modell braucht mehrere GPUs oder Quantisierung.</li>
<li>Modell-agnostisches Routing erlaubt Agenten, Self-Hosted-Modelle für sensible Daten und Cloud-APIs für unkritische Aufgaben zu nutzen.</li>
<li>Gartner (2024) prognostiziert, dass 45 % der KI-Deployments in regulierten Branchen bis 2027 auf eigener Infrastruktur laufen werden - gegenüber 20 % in 2023.</li>
</ul>
</div>

Self-Hosting bedeutet: Das Sprachmodell läuft in der Infrastruktur des Kunden. Keine Daten verlassen das Unternehmensnetzwerk, was volle [Data Residency](/de/governance/data-residency/) garantiert. Kein Drittanbieter verarbeitet die Anfragen. Volle Kontrolle über Modell, Daten und Verarbeitung.

## Welche Modelle kann man Self-Hosted betreiben?

Open-Source-Modelle können in der eigenen Infrastruktur betrieben werden:

**Volume-Workhorse - [Mistral](https://mistral.ai/) Small 3.2 (24B, Apache 2.0, EU-built):** Europäisches Modell, läuft auf einer einzelnen RTX 4090 mit 4-bit-Quantisierung. Ideal für Batch-Inferenz auf unkritischen Workloads. Mixtral 8x22B und Codestral Mamba 32B (Coding-spezialisiert) ergänzen das Mistral-Portfolio.

**Reasoning OSS - gpt-oss-120b (OpenAI, Apache 2.0):** 117B Parameter, MoE-Architektur, läuft auf einer einzelnen H100 (80 GB). OpenAIs erstes Open-Source-Modell, gpt-oss-20b für Edge-Szenarien.

**Frontier OSS - [DeepSeek](https://www.deepseek.com/) V4-Flash und V4-Pro (MIT):** DeepSeek V4-Flash (April 2026, 284B/13B aktive MoE) läuft auf einer H100 mit Quantisierung. V4-Pro (1.6T/49B) benötigt einen 8x-H100-Cluster und liefert Frontier-Reasoning. DeepSeek R1 (Jan 2025) bleibt für mature Deployments produktionsreif - die V4-Reihe ersetzt R1 nicht überstürzt.

**Long-Context - [Llama](https://llama.meta.com/) 4 Scout (Meta License):** 10M-Token-Kontextfenster für Dokumentenanalyse über ganze Aktenbestände. Llama 4 Maverick für kürzere Kontexte mit höherer Token-Throughput.

**Coding OSS - Qwen 3 Coder 110B (Apache 2.0, Alibaba) und DeepSeek Coder V4 (MIT):** Spezialisiert auf Codegenerierung und Repository-Verständnis. Codestral Mamba 32B (Mistral, EU-built) als europäische Alternative.

Proprietäre Modelle (Claude Opus 4.7, GPT-5.5, Gemini 3.1 Pro) sind nicht Self-Hosted verfügbar, können aber über API mit EU-Processing genutzt werden.

In der modell-agnostischen Architektur kann ein Agent mehrere Modelle nutzen: Self-Hosted für sensible Daten, Cloud-API für unkritische Aufgaben. Das Routing ist regelbasiert und im Decision Layer konfiguriert.

## Deployment-Optionen

**Azure:** LLMs können auf Azure ML deployed oder auf dedizierten GPU-VMs (NC-Series, ND-Series) betrieben werden. Integration mit Azure Entra ID für Authentifizierung und Zugriffskontrolle. Verarbeitung in EU-Rechenzentren (West Europe, North Europe).

**GCP:** Deployment über Vertex AI oder auf dedizierten GPU-VMs (A2, G2). Integration mit Google Cloud IAM. Verarbeitung in EU-Rechenzentren (europe-west1, europe-west4).

**On-Premise:** Eigene Server mit NVIDIA GPUs (A100, H100, RTX 4000 Ada). Betrieb in TÜV-zertifizierten Rechenzentren in Deutschland. Maximale Kontrolle, keine Cloud-Abhängigkeit.

**Hybrid:** Kombination aus Self-Hosted und Cloud. Sensible Workloads lokal, unkritische in der Cloud. Einheitliche Governance über beide Umgebungen.

<table class="w-full text-left text-sm">
<thead><tr class="border-b border-gosign-border">
<th class="py-2 pr-4 font-semibold">Kriterium</th>
<th class="py-2 pr-4 font-semibold">Self-Hosted</th>
<th class="py-2 pr-4 font-semibold">Cloud API</th>
</tr></thead>
<tbody>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Data Residency</td><td class="py-2 pr-4">Volle Kontrolle, Daten bleiben On-Premise</td><td class="py-2 pr-4">Anbieterabhängig, EU-Regionen verfügbar</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Modellauswahl</td><td class="py-2 pr-4">Nur Open Source (Llama, Mistral, DeepSeek)</td><td class="py-2 pr-4">Proprietär + Open Source via API</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Kosten bei Skalierung</td><td class="py-2 pr-4">Niedriger (fixe GPU-Kosten, keine Token-Gebühren)</td><td class="py-2 pr-4">Höher (Token-Preise skalieren linear)</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Betriebsaufwand</td><td class="py-2 pr-4">Hoch (GPU-Management, Updates, HA)</td><td class="py-2 pr-4">Niedrig (vom Anbieter verwaltet)</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Latenz</td><td class="py-2 pr-4">Niedrig (lokales Netzwerk)</td><td class="py-2 pr-4">Variabel (netzwerkabhängig)</td></tr>
</tbody>
</table>

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Kostenloses eBook: AI Infrastructure</p>
<p class="text-body text-gosign-text mb-4">Build, Buy, Hybrid - EU AI Act-konforme Infrastruktur mit B/B/H-Framework und 7-Layer Reference Architecture.</p>
<a href="/de/ebook/ki-infrastructure-governance-handbuch/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Jetzt kostenlos herunterladen</a>
</div>

## Architekturüberlegungen

**GPU-Sizing:** Die Modellgröße bestimmt den GPU-Bedarf. Ein 7B-Modell läuft auf einer einzelnen GPU. Ein 70B-Modell braucht mehrere GPUs oder Quantisierung. Die richtige Dimensionierung hängt vom Anwendungsfall ab.

**Inference-Optimierung:** Techniken wie Quantisierung (4-bit, 8-bit), Batching und KV-Cache-Optimierung reduzieren den Ressourcenbedarf bei akzeptablem Qualitätsverlust.

**Hochverfügbarkeit:** Für produktive Systeme: Redundante GPU-Server, Load Balancing, automatisches Failover. Kein Single Point of Failure.

**Modell-Updates:** Neue Modellversionen müssen getestet werden, bevor sie in Produktion gehen. Ein Staging-Environment für Modell-Tests ist Teil der Infrastruktur.

**TCO-Crossover Self-host vs Cloud-API:** Die Schwelle liegt bei rund 50-100M Tokens/Monat sustained. Unter dieser Schwelle ist Cloud-API günstiger, darüber amortisiert eine dedizierte H100 in 12-18 Monaten. Siehe [Self-hosted Open-Source AI 2026](/de/magazin/selbst-gehostete-open-source-ki-2026/) für die vollständige Modellmatrix und Kostenrechnung.

Mehr dazu: [KI-Infrastruktur](/de/leistungen/infrastruktur/)

<a href="/de/kontakt/" target="_blank" rel="noopener noreferrer">Termin vereinbaren</a> - Wir zeigen Ihnen die optimale Hosting-Strategie für Ihre Anforderungen.

--- Modell-Agnostik: LLM-Vendor-Lock-in vermeiden ---
> Modell-agnostische Architektur: Geschäftslogik vom LLM entkoppelt. Agenten, Decision Layer und Regelwerke bleiben bei Modellwechsel unverändert

## Das Risiko: Ein Modell, ein Anbieter

Viele Unternehmen bauen ihre KI-Strategie auf einem einzelnen Modell auf. "Wir nutzen ChatGPT" oder "Wir setzen auf Claude". Prompts werden für dieses Modell optimiert. Integrationen werden für die API dieses Anbieters gebaut. Workflows sind auf die Eigenheiten dieses Modells abgestimmt.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Auf einen Blick - Modell-agnostische Architektur</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Wer auf einen einzelnen LLM-Anbieter baut, schafft gefährliche Abhängigkeit: Preise ändern sich, APIs werden umgebaut, Modelle kurzfristig eingestellt.</li>
<li>Eine modell-agnostische Architektur entkoppelt Geschäftslogik vom Sprachmodell - Agenten, Decision Layer und Workflows bleiben bei Modellwechseln unverändert.</li>
<li>Multi-Modell-Routing weist einfachen Aufgaben günstige Modelle und komplexem Reasoning Flaggschiffe zu - das spart 40-60 % Token-Kosten.</li>
<li>Self-Hosted-Modelle verarbeiten sensible Daten, Cloud-APIs bedienen unkritische Anfragen - gesteuert durch den Decision Layer.</li>
<li>Forrester (2024) berichtet, dass Unternehmen mit modell-agnostischer Architektur LLM-Migrationskosten um bis zu 70 % senken.</li>
</ul>
</div>

Dann passiert eines von drei Dingen: Der Anbieter erhöht die Preise. Der Anbieter ändert die API. Ein neues Modell erscheint, das deutlich besser oder günstiger ist. In jedem Fall: Die gesamte Implementierung muss angepasst werden.

Im LLM-Markt passiert das schnell. In den letzten 18 Monaten haben sich Preise halbiert, neue Anbieter sind erschienen, Open-Source-Modelle haben proprietäre Modelle in Benchmarks überholt. Wer sich an einen Anbieter gebunden hat, kann diese Entwicklungen nicht nutzen.

## Modell-Agnostik als Architekturprinzip

In der [Gosign Referenz-Architektur](/de/governance/referenz-architektur/) ist der Model Layer eine austauschbare Schicht. Die Geschäftslogik - Regelwerke, Entscheidungslogik, Workflows - ist im Decision Layer und Agent Layer implementiert, nicht im Modell.

Wenn ein neues Modell verfügbar wird, kann es integriert werden, ohne die darüberliegenden Layer zu ändern. Der Agent weiß nicht welches Modell er nutzt. Er stellt eine Anfrage an den Model Layer und bekommt eine Antwort zurück. Welches Modell die Antwort liefert, ist für den Agenten irrelevant.

## Multi-Modell-Routing

Ein Agent kann mehrere Modelle gleichzeitig nutzen. Das Routing ist regelbasiert:

**Kostenoptimierung:** Einfache Aufgaben (Dokumentenklassifizierung, Datenextraktion) laufen über ein kostengünstiges Modell. Komplexe Aufgaben (Entscheidungsunterstützung, Regelinterpretation) über ein leistungsfähigeres Modell.

**Data Residency:** Sensible Daten gehen an Self-Hosted-Modelle ([Llama](https://llama.meta.com/), [Mistral](https://mistral.ai/), [DeepSeek](https://www.deepseek.com/)). Unkritische Daten können über Cloud-APIs laufen.

**Failover:** Wenn ein Modell-Anbieter ausfällt, kann automatisch auf ein alternatives Modell gewechselt werden.

Die Routing-Regeln sind im Decision Layer konfiguriert und nachvollziehbar.

## Unterstützte Modelle

Die Gosign-Architektur unterstützt aktuell (Stand 2026):
- Claude Opus 4.7 / Sonnet 4.6 / Haiku 4.5 (Anthropic) - Cloud-API
- GPT-5.5 / GPT-5.5-mini (OpenAI) - Cloud-API
- Gemini 3.1 Pro / 3.1 Flash (Google) - Cloud-API
- Llama 4 Scout / Llama 4 Maverick (Meta) - Self-Hosted oder Cloud
- Mistral Small 3.2 / Mistral Large (Mistral AI) - Self-Hosted oder Cloud
- DeepSeek V4-Pro / V4-Flash / R1 (DeepSeek) - Self-Hosted oder Cloud
- gpt-oss (OpenAI) - Self-Hosted oder Cloud

Neue Modelle können integriert werden, sobald sie über eine Standard-API erreichbar sind. Welches dieser Modelle für welche Mikro-Entscheidung das richtige ist, klärt die parallele Analyse [Welches Modell wann? Decision-Routing für agentische Workflows](/de/magazin/ki-modelle-vergleich-2026/).

| Aspekt | Single-Vendor-Setup | Modell-agnostische Architektur |
|---|---|---|
| Modellwechsel | Kompletter Umbau von Prompts, Integrationen, Workflows | Routing-Regel-Änderung, kein Umbau |
| Kostenkontrolle | An ein Preismodell gebunden | Budget-Modelle für einfache, Flaggschiffe für komplexe Aufgaben |
| Datensouveränität | Abhängig vom Anbieter | Self-Hosted für sensible, Cloud für unkritische Daten |
| Failover | Keine Alternative bei Anbieterausfall | Automatischer Wechsel auf alternatives Modell |
| Migrationskosten | Hoch (Forrester: bis zu 70 % höher) | Niedrig (nur Konfigurationsänderung) |
| Zukunftssicherheit | Risiko der Abkündigung | Neue Modelle ohne Änderungen integrierbar |

Mehr dazu: [KI-Infrastruktur](/de/leistungen/infrastruktur/)

## Modell-Agnostik plus Decision-Routing

Modell-Agnostik ist die Vorbedingung, Decision-Routing pro Mikro-Entscheidung ist die Anwendung. Wer den Routing-Layer baut, macht aus der Modellwahl eine Konfiguration und aus dem Modell-Upgrade ein Konfig-Diff statt eines Re-Engineering. Welches Modell für welchen Entscheidungstyp - Klassifikation, Tool-Use, Reasoning, Long-Context - das richtige ist, zeigt der Master-Vergleich: [Welches Modell wann? Decision-Routing für agentische Workflows](/de/magazin/ki-modelle-vergleich-2026/).

<a href="/de/kontakt/" target="_blank" rel="noopener noreferrer">Termin vereinbaren</a> - Wir zeigen Ihnen die modell-agnostische Architektur im Detail.

--- Next.js über Supabase sicher betreiben ---
> DevOps-Runbook für Next.js auf Supabase: Architektur, Middleware, Auth-Patterns, Rate Limiting und Claude-Code-Integration.

Nachdem Supabase als Backend-Plattform [stabil läuft](/de/magazin/supabase-self-hosting/), entsteht der eigentliche Anwendungs-Stack darüber.

In vielen modernen Projekten übernimmt **Next.js** die Rolle der App-Schicht:

- Frontend Rendering
- Server Side Rendering
- Server Actions
- Route Handlers
- API Proxy
- Session Handling

Damit wird Next.js faktisch ein **Backend-Gateway zwischen Browser und Supabase**.

Der häufigste Fehler besteht darin, dass diese Schicht als "Frontend" behandelt wird, obwohl sie tatsächlich **serverseitige Logik mit hohen Privilegien** enthält.

Dieses Runbook beschreibt, wie Next.js sicher über einer self-hosted Supabase-Plattform betrieben wird.

Jeder Abschnitt enthält:

- Implementierung
- prüfbare Bedingung
- Failure-Scenario

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Auf einen Blick - Artikel 2 von 6 der DevOps-Runbook-Serie</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Next.js als eigener Container, physisch getrennt von Supabase</li>
<li>service_role Key nur in einer einzigen Datei erlaubt (lib/supabase/admin.ts)</li>
<li>Middleware mit getUser() auf jedem Request (nicht getSession())</li>
<li>Ownership Checks in allen Server Actions vor Datenänderungen</li>
<li>Rate Limiting mit Upstash Redis auf allen Auth-Endpunkten</li>
</ul>
</div>

## Serien-Inhaltsverzeichnis

Diese Anleitung ist Teil unserer DevOps-Runbook-Serie für self-hosted App-Stacks.

1. [Supabase Self-Hosting Runbook](/de/magazin/supabase-self-hosting/)
2. [Next.js über Supabase sicher betreiben](/de/magazin/nextjs-supabase-sicher-betreiben/) - dieser Artikel
3. [Supabase Edge Functions sicher einsetzen](/de/magazin/supabase-edge-functions-sicher/)
4. [Trigger.dev Background Jobs sicher betreiben](/de/magazin/trigger-dev-background-jobs/)
5. [Claude Code als Sicherheitskontrolle im DevOps-Workflow](/de/magazin/claude-code-security-devops/)
6. [Security Baseline für den gesamten Stack](/de/magazin/security-baseline-stack/)

[Artikel 1 beschreibt die Plattform-Basis](/de/magazin/supabase-self-hosting/#teil-b---supabase-services-einrichten-und-absichern) mit allen Services und deren Sicherheitskonfiguration. Dieser Artikel beschreibt die **App-Schicht darüber**.

## Architekturüberblick

```
Browser (Client)
     |
     | HTTPS
     |
Next.js App Layer
     |
     +-- @supabase/ssr
     |
     +-- service_role client
           (nur isolierte Admin-Kontexte)
     |
Supabase Platform Layer
     |
     +-- Kong API Gateway
     +-- GoTrue Auth
     +-- PostgREST API
     +-- Realtime
     |
PostgreSQL Data Layer
     |
     +-- Row Level Security
```

Grundregeln:

```
Browser    -> spricht nur mit Next.js
Next.js    -> spricht mit Supabase
Supabase   -> kontrolliert Zugriff über RLS
```

Wenn der Browser mehrere Backend-Services direkt anspricht, entstehen unkontrollierbare Sicherheitsgrenzen.

## Teil A - Architekturentscheidungen

Diese Entscheidungen werden selten geändert und bilden das Fundament.

## A1 - Next.js als eigenen Service betreiben

### Umsetzung

Next.js läuft als eigener Container.

```
services

nextjs-app
supabase-stack
postgres
```

Beispiel docker-compose:

```yaml
services:

  nextjs-app:
    build: ./app
    ports:
      - "3000:3000"
    environment:
      - NEXT_PUBLIC_SUPABASE_URL=http://kong:8000
      - NEXT_PUBLIC_SUPABASE_ANON_KEY=${ANON_KEY}
      - SUPABASE_SERVICE_ROLE_KEY=${SERVICE_ROLE_KEY}
    networks:
      - internal
```

Next.js darf **nicht innerhalb des Supabase-Stacks laufen**. Eine Analyse von über 500 Next.js-Deployments zeigt, dass 23% aller produktiven Next.js-Instanzen mindestens eine serverseitige Umgebungsvariable im Client-Bundle exponieren (Snyk State of Open Source Security 2024).

### Prüfbare Bedingung

```
docker ps --format '{{.Names}}'
```

Erwartung:

```
nextjs-app
supabase-kong
supabase-postgres
supabase-auth
```

### Failure Scenario

Wenn Next.js im selben Container wie Supabase läuft:

- Prozessraum wird geteilt
- Secrets liegen im selben Environment
- ein kompromittierter Next.js Server hat direkten Zugriff auf alle Backend-Services

## A2 - Browser spricht nur mit Next.js

### Umsetzung

Der Browser darf nur eine öffentliche URL sehen.

```
https://app.example.com
```

Nicht erlaubt:

```
https://app.example.com:8000
https://app.example.com:5432
https://app.example.com:9000
```

Firewall-Beispiel:

```
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -p tcp --dport 8000 -j DROP
iptables -A INPUT -p tcp --dport 5432 -j DROP
iptables -A INPUT -p tcp --dport 9000 -j DROP
```

### Prüfbare Bedingung

```
nmap -p 443,3000,5432,8000,9000 app.example.com
```

Erwartung:

```
443 open
alle anderen filtered
```

### Failure Scenario

Wenn Supabase Studio öffentlich erreichbar ist:

- vollständiger Datenbankzugriff
- Schema-Manipulation
- Zugriff auf Storage Buckets

## A3 - Security Headers setzen

Next.js fungiert als Gateway und muss HTTP-Security-Header setzen.

### Umsetzung

```
next.config.js
```

```javascript
const securityHeaders = [
  { key: "X-Frame-Options", value: "DENY" },
  { key: "X-Content-Type-Options", value: "nosniff" },
  { key: "Referrer-Policy", value: "strict-origin-when-cross-origin" },
  { key: "Permissions-Policy", value: "camera=(), microphone=()" },
  { key: "Strict-Transport-Security", value: "max-age=63072000; includeSubDomains" },
  {
    key: "Content-Security-Policy",
    value: "default-src 'self'; img-src 'self' data: blob:; frame-ancestors 'none'"
  }
]
```

### Prüfbare Bedingung

```
curl -I https://app.example.com
```

Erwartete Header:

```
X-Frame-Options
Content-Security-Policy
Strict-Transport-Security
```

### Failure Scenario

Ohne CSP:

- XSS-Angriffe laden externe Skripte
- Token können exfiltriert werden

## Teil B - Implementierungschecks

Diese Regeln gelten für jede Codeänderung.

## B1 - Environment Variablen trennen

### Übersicht der Umgebungsvariablen

| Variable | Sichtbarkeit | Erlaubter Ort | Risiko bei Leak |
|----------|-------------|---------------|-----------------|
| NEXT_PUBLIC_SUPABASE_URL | Client | .env, Code | Gering (öffentlich) |
| NEXT_PUBLIC_SUPABASE_ANON_KEY | Client | .env, Code | Mittel (RLS schützt) |
| SUPABASE_SERVICE_ROLE_KEY | Server-only | .env, lib/supabase/admin.ts | Kritisch (umgeht RLS) |
| DATABASE_URL | Server-only | .env | Kritisch (voller DB-Zugang) |
| TRIGGER_API_KEY | Server-only | .env | Hoch (Job-Ausführung) |

Client-sichtbar:

```
NEXT_PUBLIC_SUPABASE_URL
NEXT_PUBLIC_SUPABASE_ANON_KEY
```

Server-only:

```
SUPABASE_SERVICE_ROLE_KEY
DATABASE_URL
TRIGGER_API_KEY
```

### Prüfbare Bedingung

```
grep -r "NEXT_PUBLIC_" .env*
```

Secrets dürfen dort nicht vorkommen.

### Build Leak Check

```
grep -r "SERVICE_ROLE" .next/
```

Erwartung:

```
keine Treffer
```

### Failure Scenario

`service_role` im Client-Bundle bedeutet:

- vollständiger DB-Zugriff
- RLS komplett wirkungslos

Wer die [Grundlagen der Secret-Verwaltung](/de/magazin/datensicherheit-ki-enterprise/) kennt, versteht, warum diese Trennung essenziell ist.

## B2 - Supabase SSR Client korrekt konfigurieren

Server-Client:

```typescript
import { createServerClient } from "@supabase/ssr"
```

Server verwendet **anon key**, nicht service_role.

Admin-Client:

```typescript
createClient(url, SERVICE_ROLE_KEY)
```

Nur für administrative Aufgaben.

### Prüfbare Bedingung

```
grep -rn "SERVICE_ROLE" app/
```

Erwartung: nur in

```
lib/supabase/admin.ts
```

### Failure Scenario

Server-Client mit service_role:

- RLS wird komplett umgangen
- alle Requests haben Adminrechte

## B3 - Middleware für Auth und Token Refresh

Middleware läuft **vor jedem Request**.

```
middleware.ts
```

### Umsetzung

```typescript
const { data: { user } } = await supabase.auth.getUser()
```

Nicht:

```
getSession()
```

### Prüfbare Bedingung

```
grep getUser middleware.ts
```

### Failure Scenario

Ohne Middleware:

- Token Refresh funktioniert nicht
- Session bricht nach 1h ab

## B4 - Mutation Pattern

Alle Mutationen folgen dem gleichen Ablauf.

```
Auth
Input Validation
Ownership Check
Mutation
Logging
```

### Beispiel

```typescript
const { user } = await supabase.auth.getUser()

if (!user) return

const post = await supabase
  .from("posts")
  .select("user_id")
  .eq("id", postId)

if (post.user_id !== user.id)
  throw new Error("forbidden")
```

### Failure Scenario

Ohne Ownership Check:

```
deletePost(id)
```

Ein Nutzer kann fremde Daten löschen.

## B5 - Rate Limiting

Next.js hat kein integriertes Rate Limiting.

Empfohlene Lösung:

```
Upstash Redis
```

### Beispiel

```
10 requests / minute / IP
```

### Prüfbare Bedingung

```
for i in {1..20}
do curl -X POST /api/login
done
```

Erwartung:

```
HTTP 429
```

## B6 - Logging ohne Secrets

Logs dürfen nicht enthalten:

```
JWT Tokens
service_role keys
emails
passwords
```

### Prüfbare Bedingung

```
grep console.log app/
```

## Teil C - Betrieb

## C1 - Dependency Updates

Next.js Releases sind häufig.

Wöchentlich prüfen:

```
npm audit
npm outdated
```

Empfohlen:

```
Renovate / Dependabot
```

## C2 - Claude Code Integration

Architektur:

```
Git Push
   |
Deterministische Checks
   |
Security Report
   |
Claude Analyse
   |
DevOps Entscheidung
```

### Deterministische Checks

```
grep service_role
grep NEXT_PUBLIC
npm audit
```

### Claude Analyse

Claude prüft:

- neue Server Actions
- neue API Routes
- Ownership Patterns
- Input Validation
- Architektur-Drift

Claude führt **keine Änderungen auf Production aus**.

## Deployment-Checkliste

Vor jedem Deployment prüfen:

```
[ ] Next.js läuft als eigener Service
[ ] Supabase Ports extern geschlossen
[ ] Security Headers aktiv

[ ] kein service_role im Client Bundle
[ ] service_role nur im Admin Client

[ ] middleware.ts vorhanden
[ ] Server Actions prüfen Auth
[ ] Ownership Checks implementiert

[ ] Login Rate Limit aktiv

[ ] npm audit ohne critical findings
```

## Fazit

Next.js ist im modernen Stack kein Frontend, sondern eine privilegierte Server-Schicht.

Sicherheit entsteht durch drei Ebenen:

```
Architektur
Implementierungschecks
laufende Audits
```

Die Kombination aus CI Security Checks und Claude Code Analyse erkennt sowohl bekannte Muster als auch neue Risiken.

Wer diese Prinzipien zusammen mit einer [Cert-Ready-by-Design-Architektur](/de/magazin/cert-ready-by-design/) verfolgt, baut prüfbare Sicherheit statt nachträglicher Audits.

<div class="not-prose my-12 border border-gosign-border bg-gosign-light rounded-card p-6 lg:p-8">
<div class="flex items-start gap-4">
<div class="flex-shrink-0 w-12 h-12 bg-gosign-dark rounded-card flex items-center justify-center">
<svg width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="white" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 15v4a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2v-4"/><polyline points="7 10 12 15 17 10"/><line x1="12" y1="15" x2="12" y2="3"/></svg>
</div>
<div>
<h2 class="text-h3 font-bold text-gosign-dark mb-2" id="audit-checkliste-als-download">Audit-Checkliste als Download</h2>
<p class="text-body text-gosign-text mb-2">Vorbereiteter Prompt für Claude Code. Laden Sie die Datei auf Ihren Server und starten Sie Claude Code im Projektverzeichnis Ihrer Next.js-Anwendung. Claude Code prüft automatisch alle Sicherheitspunkte aus diesem Runbook und meldet BESTANDEN, WARNUNG oder KRITISCH.</p>
<p class="text-sm text-gosign-text mb-4 font-mono">claude -p "$(cat claude-check-artikel-2-nextjs.md)" --allowedTools Read,Grep,Glob,Bash</p>
<a href="/downloads/claude-check-artikel-2-nextjs.md" download class="inline-flex items-center px-6 py-3 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-small uppercase tracking-wider">Checkliste herunterladen</a>
</div>
</div>
</div>

## Serien-Inhaltsverzeichnis

1. [Supabase Self-Hosting Runbook](/de/magazin/supabase-self-hosting/)
2. [Next.js über Supabase sicher betreiben](/de/magazin/nextjs-supabase-sicher-betreiben/) - dieser Artikel
3. [Supabase Edge Functions sicher einsetzen](/de/magazin/supabase-edge-functions-sicher/)
4. [Trigger.dev Background Jobs sicher betreiben](/de/magazin/trigger-dev-background-jobs/)
5. [Claude Code als Sicherheitskontrolle im DevOps-Workflow](/de/magazin/claude-code-security-devops/)
6. [Security Baseline für den gesamten Stack](/de/magazin/security-baseline-stack/)

Der nächste Artikel beschreibt, wie [Supabase Edge Functions als Integrationspunkte sicher eingesetzt werden](/de/magazin/supabase-edge-functions-sicher/#a1---edge-functions-nur-für-integrationen-nicht-als-zweites-backend) - ohne eine zweite Backend-Architektur zu bauen.

--- PII-Anonymisierung für Enterprise AI ---
> Wie verarbeitet man Dokumente mit personenbezogenen Daten DSGVO-konform mit KI? Roundtrip-Pseudonymisierung, Decision Layer, Audit Trail.

## Warum personenbezogene Daten ein Problem für KI-Verarbeitung sind

Wenn ein AI Agent einen Arbeitsvertrag analysiert, eine Gehaltsabrechnung prüft oder eine Krankmeldung verarbeitet, arbeitet er mit personenbezogenen Daten. Name, Adresse, Geburtsdatum, Sozialversicherungsnummer, Gehalt, Diagnose.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Auf einen Blick - PII-Anonymisierung für Enterprise AI</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Roundtrip-Pseudonymisierung ersetzt PII durch konsistente Pseudonyme vor der LLM-Verarbeitung und setzt nach der Verarbeitung die Echtdaten wieder ein.</li>
<li>Der Decision Layer steuert, welche PII-Kategorien pro Prozess (HR, Finance, Compliance) erkannt werden - über versionierte Regelwerke.</li>
<li>Pseudonymisierung erhält Dokumentenstruktur und Kontext - anders als Schwärzung, die Dokumente für KI-Analyse unbrauchbar macht.</li>
<li>Confidence Routing eskaliert mehrdeutige Entitäten an einen Menschen; implizite Identifikatoren erfordern Kontextregeln im Regelwerk.</li>
<li>IAPP (2024) stellt fest, dass 58 % der Organisationen, die Dokumente mit KI verarbeiten, keine systematische PII-Erkennung haben - mit entsprechendem DSGVO-Risiko.</li>
</ul>
</div>

Diese Daten an ein Sprachmodell zu senden - auch an ein selbst gehostetes - ist datenschutzrechtlich problematisch. Die DSGVO verlangt [Datensparsamkeit](/de/governance/data-residency/) (Art. 5 Abs. 1 lit. c): Es dürfen nur die Daten verarbeitet werden, die für den Zweck erforderlich sind. Für die Klassifizierung eines Belegtyps braucht das Modell keinen Mitarbeiternamen. Für die Prüfung einer Gehaltsband-Compliance braucht es kein Geburtsdatum.

Trotzdem braucht das Modell Kontext. Ein Vertrag ohne jegliche Personeninformation ist für eine KI-Analyse wertlos - es fehlen die Bezüge, die Relationen, die Zusammenhänge.

Die Lösung ist nicht Schwärzung, sondern Pseudonymisierung.

## Roundtrip-Pseudonymisierung: Das Prinzip

Roundtrip-Pseudonymisierung ist ein dreistufiger Prozess:

**Schritt 1: Erkennen und Ersetzen.** Der Pre-Processing Layer erkennt alle personenbezogenen Daten im Dokument. Jede PII-Instanz wird durch ein konsistentes Pseudonym ersetzt: "Max Müller" wird zu "Person_A", "52.000 EUR" wird zu "Gehalt_A", "Hallerstraße 8" wird zu "Adresse_A". Wichtig: Die Pseudonyme sind konsistent - wenn "Max Müller" auf Seite 3 nochmals erwähnt wird, ist er dort ebenfalls "Person_A". Das erhält die Dokumentenstruktur.

**Schritt 2: Verarbeiten.** Das pseudonymisierte Dokument wird an das Sprachmodell übergeben. Das Modell sieht: "Person_A hat Gehalt_A an Adresse_A. Der Vertrag läuft bis 2027." Es kann die Vertragsanalyse durchführen, die Gehaltsband-Prüfung, die Klausel-Klassifizierung - ohne je einen echten Namen oder ein echtes Gehalt gesehen zu haben.

**Schritt 3: Re-Anonymisieren.** Der Output des Modells enthält Pseudonyme: "Person_A liegt innerhalb des Gehaltsbands E3." Der Re-Anonymisierungs-Layer ersetzt die Pseudonyme durch die Echtdaten: "Max Müller liegt innerhalb des Gehaltsbands E3." Die Zuordnungstabelle wird nach Abschluss gelöscht.

## Was der Decision Layer steuert

Nicht jedes Datenfeld muss pseudonymisiert werden. Der Decision Layer definiert, welche PII-Kategorien erkannt und ersetzt werden - gesteuert durch ein versioniertes Regelwerk:

Für einen HR-Prozess: Namen, Gehälter, Adressen, Sozialversicherungsnummern pseudonymisieren. Jobtitel und Abteilungen können bleiben - sie sind für die Analyse relevant und nicht personenbezogen.

Für einen Finance-Prozess: Firmennamen bleiben, Ansprechpartner werden pseudonymisiert, Beträge bleiben (sie sind für die Buchungsentscheidung relevant), Bankverbindungen werden pseudonymisiert.

Für einen Compliance-Prozess: Alles pseudonymisieren - auch Firmennamen, wenn die Analyse produktübergreifend sein soll.

Diese Regeln sind mandantenspezifisch und versioniert. Wenn sich die Betriebsvereinbarung ändert, entsteht eine neue Regelversion. Bei einer Prüfung ist nachvollziehbar, welche PII-Regel in welcher Version zum Verarbeitungszeitpunkt galt.

## Grenzen und ehrliche Einschätzung

PII-Erkennung ist nicht perfekt. Named Entity Recognition (NER) macht Fehler - besonders bei:

Ambigen Namen: "Müller" kann ein Nachname oder eine Firmenbezeichnung sein. "Frankfurt" kann eine Stadt oder ein Nachname sein. Der Decision Layer adressiert das durch Confidence Routing: Bei hoher Konfidenz wird automatisch pseudonymisiert. Bei niedriger Konfidenz wird an einen Menschen eskaliert.

Impliziten Identifikatoren: "Die einzige Entwicklerin in der Hamburger Niederlassung" enthält keine explizite PII, identifiziert aber eine Person. Solche indirekten Identifikatoren sind schwer automatisch zu erkennen. Der Ansatz: Kontextregeln im Regelwerk definieren die Kombination aus Merkmalen die eine Identifikation ermöglichen.

Neuen Dokumententypen: Wenn ein neuer Dokumententyp verarbeitet wird, muss das PII-Regelwerk geprüft und ggf. erweitert werden. Das ist kein einmaliges Setup, sondern ein laufender Prozess.

| PII-Kategorie | HR-Prozess | Finance-Prozess | Compliance-Prozess |
|---|---|---|---|
| Namen | Pseudonymisiert | Ansprechpartner pseudonymisiert | Alles pseudonymisiert |
| Gehälter / Beträge | Pseudonymisiert | Bleiben (Buchungsentscheidungen) | Pseudonymisiert |
| Adressen | Pseudonymisiert | Bleiben | Pseudonymisiert |
| ID-Nummern (SVN) | Pseudonymisiert | Pseudonymisiert | Pseudonymisiert |
| Firmennamen | Bleiben | Bleiben | Pseudonymisiert |
| Jobtitel | Bleiben | Bleiben | Kontextabhängig |
| Bankverbindungen | Pseudonymisiert | Pseudonymisiert | Pseudonymisiert |

Mehr zu Document Intelligence: [Document Intelligence - PII, Vertragsschwärzung, Signaturerkennung](/de/leistungen/document-intelligence/)

<a href="/de/kontakt/" target="_blank" rel="noopener noreferrer">Termin vereinbaren</a> - Wir zeigen Ihnen die Roundtrip-Pseudonymisierung an Ihren Dokumenten.

--- RAG & Document Intelligence: Wie KI Ihre Dokumente versteht ---
> RAG macht Unternehmensdokumente KI-zugänglich - ohne Training, ohne Datenabfluss. Plus: PII-Anonymisierung und Vertragsschwärzung.

## Die zentrale Frage: Kann die KI unsere eigenen Dokumente verstehen?

„Können wir die KI auf unsere eigenen Dokumente antworten lassen?" Diese Frage stellen Fachbereiche in nahezu jedem Unternehmen. Die Antwort ist ja, mit RAG (Retrieval Augmented Generation). Das Prinzip: Ihre Dokumente bleiben in Ihrer Infrastruktur. Das Sprachmodell wird nicht mit Ihren Daten trainiert. Stattdessen werden relevante Dokumentenabschnitte dem Modell bei jeder Anfrage als Kontext übergeben. Das Modell antwortet auf Basis dieser Abschnitte, mit Quellenangabe.

Kein Datenabfluss an Dritte. Kein Nachtrainieren. Kein Kontrollverlust. Und trotzdem Antworten in natürlicher Sprache, die direkt auf Ihrem Unternehmenswissen basieren.

RAG ist heute der Standard-Ansatz, um Sprachmodelle mit unternehmensspezifischem Wissen zu verbinden. Dieser Artikel erklärt, wie RAG funktioniert, wann es die richtige Wahl ist, und warum Document Intelligence weit über eine bessere Suchfunktion hinausgeht, einschließlich PII-Anonymisierung, Vertragsschwärzung und Signaturerkennung.

IDC (2025) schätzt, dass 90 % aller neuen Unternehmensdaten unstrukturiert sind - Dokumente, E-Mails, Verträge, Besprechungsnotizen. RAG ist das Standardverfahren, um diese Daten KI-zugänglich zu machen, ohne das Modell neu zu trainieren.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Auf einen Blick - RAG & Document Intelligence</p>
<ul class="text-body text-gosign-text space-y-2">
<li>RAG verbindet Sprachmodelle mit Ihren Unternehmensdokumenten - ohne Training, ohne Datenabfluss. Dokumente bleiben in Ihrer Infrastruktur.</li>
<li>Für 90 % der Enterprise-Anwendungsfälle schlägt RAG Fine-Tuning: geringere Kosten, sofortige Aktualisierung per Re-Indexierung, integrierte Quellenangaben.</li>
<li>Document Intelligence geht über Suche hinaus: PII-Anonymisierung, Vertragsschwärzung und Signaturerkennung sind produktionsreife Funktionen.</li>
<li>Indexierungsqualität bestimmt Antwortqualität. Chunk-Strategie, Metadaten-Anreicherung und Zugriffssteuerung sind nicht verhandelbar.</li>
<li>RAG integriert sich in das Enterprise-AI-Portal, sodass jede Abteilung nur auf ihre autorisierte Wissensbasis zugreift.</li>
</ul>
</div>

## Wie RAG funktioniert

RAG besteht aus zwei Phasen: der Indexierung Ihrer Dokumente und der Beantwortung von Anfragen. Der Ablauf lässt sich in einem Flussdiagramm darstellen:

```
Dokumente → Chunking → Embedding → Vektordatenbank
│
Nutzer-Anfrage → Query Embedding → Ähnlichkeitssuche
│
Relevante Abschnitte + Anfrage → LLM → Antwort mit Quellenangabe
```

**Phase 1: Indexierung.** Ihre Dokumente, PDFs, Word-Dateien, HTML-Seiten, gescannte Belege, werden in sinnvolle Abschnitte zerlegt (Chunking). Jeder Abschnitt wird durch ein Embedding-Modell in einen mathematischen Vektor umgewandelt. Diese Vektoren werden in einer Vektordatenbank gespeichert. Der Vektor repräsentiert die Bedeutung des Abschnitts, nicht den Wortlaut. „Regelung zur Telearbeit" und „Homeoffice-Vereinbarung" liegen im Vektorraum nahe beieinander, obwohl sie unterschiedliche Wörter verwenden.

**Phase 2: Anfrage.** Wenn ein Nutzer eine Frage stellt, wird diese ebenfalls in einen Vektor umgewandelt. Die Vektordatenbank findet die Abschnitte, die der Frage semantisch am nächsten liegen, nicht per Stichwortsuche, sondern per Ähnlichkeitsberechnung. Diese relevanten Abschnitte werden zusammen mit der ursprünglichen Frage an das Sprachmodell übergeben. Das Modell generiert eine Antwort auf Basis dieser konkreten Quellen.

Das Ergebnis: Eine Antwort in natürlicher Sprache, die auf Ihren Dokumenten basiert, mit Verweis auf die Quellstellen, aus denen die Information stammt.

Entscheidend ist die Qualität der Indexierung. Zu große Chunks verwässern die Relevanz. Zu kleine Chunks verlieren den Kontext. Die Chunk-Strategie, Größe, Überlappung, Metadaten-Anreicherung, bestimmt maßgeblich die Antwortqualität. Eine gute RAG-Pipeline ist nicht die Technologie selbst, sondern deren Konfiguration auf Ihre spezifische Dokumentenlandschaft.

## RAG vs. Fine-Tuning vs. Prompting

RAG ist nicht der einzige Weg, ein Sprachmodell mit Fachwissen zu versehen. Es gibt drei grundlegende Ansätze, die sich in Aufwand, Kosten und Eignung unterscheiden:

| Ansatz | Was passiert | Wann sinnvoll | Kosten | Aktualität |
|---|---|---|---|---|
| Prompting | Kontext direkt im Prompt | Kleine Datenmengen | Gering | Sofort |
| RAG | Relevante Docs automatisch gefunden | Große Wissensbasen | Mittel | Re-Indexierung |
| Fine-Tuning | Modell nachtrainiert | Spezialsprache/Domäne | Hoch | Nur durch Re-Training |

**Prompting** funktioniert, wenn der relevante Kontext in das Kontextfenster des Modells passt, typischerweise einige Dutzend Seiten. Für eine einzelne Betriebsvereinbarung ist das ausreichend. Für eine Wissensdatenbank mit Hunderten von Dokumenten nicht.

**RAG** skaliert auf große Dokumentenbestände. Die Vektordatenbank kann Hunderttausende von Abschnitten enthalten. Bei jeder Anfrage werden nur die relevanten Abschnitte gefunden und dem Modell übergeben. Die Dokumente können jederzeit aktualisiert werden, eine Re-Indexierung genügt. Das Modell muss nicht neu trainiert werden.

**Fine-Tuning** verändert die Gewichte des Modells selbst. Das ist sinnvoll, wenn das Modell eine völlig neue Fachsprache lernen muss, etwa medizinische Terminologie oder eine proprietäre Nomenklatur, oder wenn ein sehr spezifisches Antwortformat erforderlich ist. Fine-Tuning ist aufwendig, teuer und erfordert bei jeder Aktualisierung ein erneutes Training.

Für 90 % aller Enterprise-Anwendungsfälle ist RAG der richtige Ansatz. Die Kombination aus großen Wissensbasen, häufiger Aktualisierung und dem Bedarf an Quellenangaben macht RAG zum Standard für Unternehmenswissen.

## Document Intelligence: mehr als Suche

RAG beantwortet Fragen auf Basis von Dokumenten. Document Intelligence geht weiter: Sie umfasst alle Verfahren, mit denen KI Dokumente nicht nur liest, sondern versteht, klassifiziert und verarbeitet, einschließlich des Schutzes sensibler Informationen.

Die drei wichtigsten Anwendungsfelder im Enterprise-Kontext: PII-Anonymisierung, Vertragsschwärzung und Signaturerkennung.

### PII-Anonymisierung: Roundtrip-Pseudonymisierung

Personenbezogene Daten (PII, Personally Identifiable Information) dürfen in vielen Anwendungsfällen nicht an ein Sprachmodell übergeben werden. Gehälter, Klarnamen, Personalnummern, Gesundheitsdaten. Die DSGVO und interne Datenschutzrichtlinien setzen klare Grenzen.

Die Lösung ist Roundtrip-Pseudonymisierung. Ein konkretes Beispiel:

**Originaldokument:**
„Max Müller, Abteilung Finanzen, Gehalt 85.000 Euro, tritt der Betriebsvereinbarung zur flexiblen Arbeitszeit bei."

**Nach Pseudonymisierung (Input an das Modell):**
„Person_A, Abteilung_X, Gehalt_Y, tritt der Betriebsvereinbarung zur flexiblen Arbeitszeit bei."

Das Sprachmodell verarbeitet die Anfrage mit den pseudonymisierten Daten. Es sieht zu keinem Zeitpunkt den Klarnamen, die Abteilung oder das Gehalt.

**Nach Re-Identifizierung (Output an den Nutzer):**
Die Platzhalter werden im Ergebnis wieder durch die Originaldaten ersetzt. Der Nutzer sieht die vollständige Antwort. Das Modell hat sie nie gesehen.

Dieser Roundtrip geschieht automatisch. Für den Nutzer ist der Vorgang transparent. Für das Modell sind die Daten zu keinem Zeitpunkt zugänglich. Für die [Infrastruktur](/de/leistungen/infrastruktur/) bedeutet das: Die Pseudonymisierungs-Schicht sitzt zwischen Nutzer und Modell und ist technisch erzwungen, nicht optional.

PII-Anonymisierung ist besonders relevant für HR-Anwendungen, in denen Personalakten, Gehaltsabrechnungen oder Beurteilungen KI-gestützt verarbeitet werden sollen. Ohne Anonymisierung sind solche Anwendungsfälle in der EU nicht DSGVO-konform umsetzbar.

### Vertragsschwärzung (Redaction)

Vertragsschwärzung geht über Pseudonymisierung hinaus. Während Pseudonymisierung Daten ersetzt und am Ende wieder einblendet, entfernt Redaction Inhalte physisch aus dem Dokument, unwiderruflich für den jeweiligen Empfänger.

Der Anwendungsfall: Unterschiedliche Abteilungen benötigen unterschiedliche Sichten auf denselben Vertrag. Die Rechtsabteilung sieht den vollständigen Vertrag. Der Einkauf sieht eine Version ohne Haftungsklauseln. Die Geschäftsführung sieht eine Zusammenfassung ohne operative Details.

Vertragsschwärzung funktioniert regelbasiert. Für jede Dokumentenkategorie und jede Empfängergruppe ist definiert, welche Abschnitte sichtbar sind und welche geschwärzt werden. Die Regeln werden im [Decision Layer](/de/decision-layer/) konfiguriert und versioniert, nicht manuell angewendet.

Das Ergebnis: Jede Rolle sieht genau die Information, die für sie relevant und freigegeben ist. Keine manuelle Schwärzung mit Edding. Keine vergessenen Passagen. Keine Versionen, die versehentlich vollständig weitergeleitet werden.

### Signaturerkennung

Vertragsarchive in Unternehmen umfassen häufig Tausende von Dokumenten. Die Frage, ob ein bestimmter Vertrag vollständig unterschrieben ist, erfordert heute oft manuelles Durchblättern. Bei Hunderten von Verträgen ist das nicht praktikabel.

Document Intelligence löst dieses Problem durch automatisierte Signaturerkennung. Das System prüft gescannte Verträge auf das Vorhandensein von Unterschriften an den vorgesehenen Stellen. Fehlende Signaturen werden automatisch markiert. Das Ergebnis: eine Übersicht aller Verträge im Archiv, die noch nicht vollständig gezeichnet sind, in Minuten statt Wochen.

Der Anwendungsfall geht über die reine Erkennung hinaus. In Kombination mit einer RAG-Pipeline kann das System auch Fragen beantworten wie: „Welche Rahmenverträge mit einer Laufzeit über 3 Jahre wurden im letzten Quartal verlängert, ohne dass eine Unterschrift der Geschäftsführung vorliegt?"

## Praxis-Beispiel: Der Betriebsvereinbarungs-Assistent

Ein konkretes Szenario aus der HR-Praxis. Eine Personalabteilung eines mittelständischen Unternehmens verwaltet über 100 aktive Betriebsvereinbarungen: Arbeitszeit, Homeoffice, Dienstreisen, Weiterbildung, Altersvorsorge, betriebliches Eingliederungsmanagement, Datenschutz, IT-Nutzung, und mehr. Jede Vereinbarung hat Nachträge, Anlagen, Verweise auf andere Vereinbarungen.

Wenn ein Sachbearbeiter die Frage beantworten muss: „Welche Regelung gilt für Homeoffice-Tage bei Teilzeitkräften in der Produktion?", dann bedeutet das heute: die richtige Betriebsvereinbarung finden, die relevante Passage lokalisieren, prüfen ob ein Nachtrag existiert, gegenprüfen mit dem Tarifvertrag, Sonderregelungen für den Standort berücksichtigen. Ergebnis: 30 bis 45 Minuten Recherchezeit. Bei Unsicherheit Rückfrage an die Rechtsabteilung. Nochmals Tage Wartezeit.

Mit einem RAG-basierten Betriebsvereinbarungs-Assistenten: Alle Betriebsvereinbarungen werden indexiert, einschließlich Nachträgen, Anlagen und Querverweisen. Der Sachbearbeiter stellt die Frage in natürlicher Sprache. Das System findet die relevanten Passagen aus den richtigen Dokumenten, berücksichtigt den Nachtrag vom März 2025, verweist auf die Sonderregelung für Produktionsmitarbeitende und liefert die Antwort in 10 Sekunden. Mit Quellenangabe. Mit Regelversion.

Das ist kein theoretisches Szenario. Es ist der Standardanwendungsfall, mit dem Unternehmen ihre erste RAG-Pipeline aufsetzen. Der Aufwand ist überschaubar: Dokumente bereitstellen, Chunk-Strategie konfigurieren, Zugriffsrechte definieren, testen. Die [Infrastruktur](/de/leistungen/infrastruktur/), Vektordatenbank, Embedding-Modell, Sprachmodell, Retrieval-Pipeline, wird einmal aufgebaut und steht dann für weitere Anwendungsfälle zur Verfügung.

## Qualitätssicherung: Warum RAG-Ergebnisse nur so gut sind wie die Indexierung

RAG ist kein Selbstläufer. Die häufigsten Fehlerquellen in der Praxis:

**Schlechte Chunk-Strategie.** Zu große Chunks (ganze Kapitel) liefern zu viel irrelevanten Kontext. Zu kleine Chunks (einzelne Absätze) verlieren den Zusammenhang. Die richtige Chunk-Größe hängt von der Dokumentenart ab, eine technische Spezifikation erfordert andere Chunks als eine Betriebsvereinbarung.

**Fehlende Metadaten.** Ohne Metadaten (Dokumenttyp, Gültigkeitsdatum, Version, Geltungsbereich) kann die Retrieval-Pipeline nicht zwischen einer aktuellen und einer veralteten Regelung unterscheiden. Metadaten-Anreicherung beim Indexieren ist keine Kür, sondern Pflicht.

**Keine Zugriffssteuerung.** In einem Enterprise-Umfeld darf nicht jeder Nutzer auf alle Dokumente zugreifen. Die RAG-Pipeline muss die bestehende Berechtigungsstruktur abbilden: HR-Dokumente nur für HR, Finanzdaten nur für Finance, Vorstandskommunikation nur für berechtigte Personen.

**Keine Quellenprüfung.** RAG liefert Quellenangaben. Aber sind diese korrekt? Eine Qualitätssicherung, stichprobenartige Prüfung der Quellenverweise, Feedback-Mechanismus für Nutzer, regelmäßige Evaluierung, ist notwendig, um Halluzinationen zu erkennen und die Pipeline zu verbessern.

Diese Qualitätssicherung ist Teil des laufenden Betriebs, nicht ein einmaliges Setup. Dokumente ändern sich. Neue kommen hinzu. Alte werden ungültig. Die RAG-Pipeline muss mitwachsen, durch regelmäßige Re-Indexierung, Metadaten-Updates und Nutzerfeedback.

## Integration in das Enterprise-AI-Portal

RAG ist kein isoliertes System. In einer durchdachten Architektur ist die RAG-Pipeline in das [Enterprise-AI-Portal](/de/magazin/enterprise-ki-chat-interface/) integriert. Mitarbeitende stellen Fragen über eine einheitliche Oberfläche, dieselbe, über die sie auch mit [KI-Agenten](/de/leistungen/ai-agents/) interagieren.

Das Portal steuert die Zugriffsrechte: Wer darf welche Wissensbasis abfragen? HR-Mitarbeitende sehen den Betriebsvereinbarungs-Assistenten. Die Rechtsabteilung sieht den Vertrags-Assistenten. Der Einkauf sieht den Lieferantenrichtlinien-Assistenten. Jeder sieht nur das, wofür er berechtigt ist.

Die Kombination aus RAG und KI-Agenten eröffnet erweiterte Möglichkeiten: Ein Agent kann nicht nur eine Frage beantworten, sondern auf Basis der RAG-Ergebnisse eine Handlung auslösen, etwa eine Fristwarnung erzeugen, wenn ein Vertrag ausläuft, oder eine Checkliste generieren, wenn eine neue Betriebsvereinbarung in Kraft tritt.

---

**📘 Enterprise AI-Infrastruktur Blueprint 2026 - Artikel-Serie**

| ← Vorheriger | Übersicht | Nächster → |
|:---|:---:|---:|
| [Enterprise-AI-Portal: Vier Open-Source-Interfaces im Vergleich](/de/magazin/enterprise-ki-chat-interface/) | [Zur Übersicht](/de/magazin/ai-infrastruktur-blueprint-2026/) | [Von Chatbots zu AI-Agenten: MCP, A2A und Multi-Agent-Systeme](/de/magazin/ai-agenten-enterprise-leitfaden/) |

*Alle Artikel dieser Serie: [Enterprise AI-Infrastruktur Blueprint 2026](/de/magazin/ai-infrastruktur-blueprint-2026/)*

---

**Sie wollen Ihr Unternehmenswissen KI-zugänglich machen?** Gosign baut RAG-Pipelines und Document-Intelligence-Lösungen für Enterprise-Kunden, modell-agnostisch, mit PII-Anonymisierung und vollständiger Zugriffssteuerung.

<a href="/de/kontakt/" target="_blank" rel="noopener noreferrer">Termin vereinbaren</a>. 30 Minuten, in denen wir klären, welche Dokumente zuerst KI-zugänglich werden sollten.

--- Reisekosten im Konzern: Was SAP Concur nicht löst ---
> SAP Concur erfasst Belege - aber wer entscheidet über Tarifvertrag, Verpflegungsmehraufwand und IROP? Warum Konzerne mehr brauchen als ein Spesen-Tool.

## SAP Concur ist gut - für das, wofür es gebaut wurde

SAP Concur ist die weltweit meistgenutzte Software für Reisekostenabrechnung. Belegerfassung per App, Genehmigungsworkflows, Integration in SAP-Systeme - für Unternehmen mit standardisierten Inlandsreisen funktioniert das zuverlässig.

Das Problem beginnt, wo Standardprozesse aufhören. Bei Konzernen mit Tarifverträgen, Multi-Jurisdiktions-Reisen und branchenspezifischer Komplexität stößt jedes reine Erfassungstool an seine Grenzen - nicht nur Concur, sondern auch Circula, Rydoo oder HR Works.

Der Grund: Diese Tools lösen das Erfassungsproblem. Nicht das Entscheidungsproblem.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Auf einen Blick - Grenzen von SAP Concur bei Konzern-Reisekosten</p>
<ul class="text-body text-gosign-text space-y-2">
<li>SAP Concur löst die Belegerfassung, nicht die 40 bis 120 Mikro-Entscheidungen hinter jedem Vorgang (Tarifverträge, Multi-Jurisdiktions-Pauschalen, IROP-Neuberechnung).</li>
<li>Manuelle Verarbeitung kostet 58 USD pro Vorgang bei 19 % Fehlerquote und 52 USD pro Korrektur (GBTA Foundation) - bei 100.000 Crew-Vorgängen sind das 6,8 Mio USD pro Jahr.</li>
<li>Tarifverträge, länderübergreifende Grenzüberschreitungen und irregulärer Betrieb liegen außerhalb des Datenmodells jedes Standard-Reisekostentools.</li>
<li>Der Decision Layer sitzt als Governance-Schicht über SAP Concur - versionierte Regeln, deterministische Berechnung, lückenloser Audit Trail.</li>
<li>Ergebnis: 95 % vollautomatisch, Fehlerquote unter 1 %, Kosten pro Vorgang unter 10 USD - ohne Ersatz bestehender Systeme.</li>
</ul>
</div>

## Das Entscheidungsproblem: 40 bis 120 Mikro-Entscheidungen pro Vorgang

Eine Reisekostenabrechnung ist keine Belegerfassung. Hinter jedem Vorgang stehen 40 bis 120 Mikro-Entscheidungen:

- Welche Pauschale gilt (BMF-Länderliste, Stand zum Reisedatum)?
- Greift ein Tarifvertrag, der die gesetzliche Pauschale überschreibt?
- Wie wird die Mahlzeitengestellung gekürzt (Frühstück, Mittag, Abend)?
- Welche Kostenstelle trägt den Vorgang?
- Wie ist die steuerliche Behandlung (steuerfrei, pauschal versteuert, steuerpflichtig)?
- Was passiert bei einer Planänderung mitten in der Reise?

SAP Concur erfasst den Beleg. Aber wer trifft diese Entscheidungen? In den meisten Konzernen: ein Sachbearbeiter im Shared Service Center, manuell, pro Vorgang, ohne dokumentierte Entscheidungslogik.

Das ist teuer. Die GBTA Foundation beziffert die durchschnittlichen Kosten pro manuell bearbeitetem Reisekostenvorgang auf 58 USD - bei einer Fehlerquote von 19 Prozent und Korrekturkosten von 52 USD pro Fehler (Quelle: GBTA Foundation / HRS, "Expense Reporting: Global Practices and Pain Points", 2015).

## Wo Standard-Reisekostentools an ihre Grenzen stoßen

### Tarifvertrag schlägt Gesetz

Die BMF-Pauschalen für Verpflegungsmehraufwand sind der gesetzliche Mindeststandard: 14 Euro für Anreisetage, 28 Euro für volle Abwesenheitstage im Inland (Stand 2026). Viele Tarifverträge definieren höhere Sätze - teilweise deutlich.

Ein Airline-Konzern mit 10.000 Crew-Mitgliedern hat typischerweise 2 bis 5 parallele Tarifverträge: Cockpit, Kabine, Bodenpersonal, Technik. Jeder Tarifvertrag definiert eigene Pauschalen, eigene Kürzungsregeln, eigene Ausnahmen für Mahlzeitengestellung.

SAP Concur kennt keine Tarifverträge. Die Software rechnet mit den gesetzlichen Pauschalen - oder mit einem einzelnen unternehmensweiten Satz. Die tarifvertragskonforme Berechnung des Verpflegungsmehraufwands passiert außerhalb des Tools: manuell, in Excel-Tabellen, oder durch Sachbearbeiter im Shared Service Center, die das Ergebnis händisch zurück ins System übertragen.

Das ist nicht nur ineffizient. Es ist fehleranfällig. Wenn der Sachbearbeiter bei Crew-Gruppe 3 den falschen Tarifvertrag anwendet, entstehen systematische Fehler, die bei Tausenden Vorgängen unbemerkt bleiben - bis zur Betriebsprüfung.

### Multi-Jurisdiktion in einem Vorgang

Ein Crewmitglied auf einem Europaflug berührt an einem Tag 3 bis 5 Länder. Die Pauschale für Verpflegungsmehraufwand richtet sich nach dem Land, in dem der Reisetag endet, oder nach der Mitternachtsregel bei mehrtägigen Reisen. Standard-Reisekostentools rechnen pro Reise mit einem Land. Multi-Jurisdiktion innerhalb eines Vorgangs - mit minutengenauer Grenzüberschreitung - liegt außerhalb ihres Datenmodells.

Das betrifft nicht nur Airlines:

- **Logistik**: Fahrer überqueren täglich mehrere Grenzen. Die Pauschale wechselt an jeder Grenze, die Berechnung muss minutengenau erfolgen - insbesondere bei Mitternachtsüberschreitungen. Dazu kommen die Dokumentationspflichten des [EU-Mobilitätspakets](/de/leistungen/travel-decision-layer/logistik/) (Richtlinie 2020/1057).
- **Vertrieb**: Außendienstmitarbeiter besuchen Kunden in mehreren Ländern pro Woche. Montag Wien, Mittwoch Zürich, Freitag München - drei Jurisdiktionen, drei Pauschalen, ein Vorgang.
- **Beratung**: Berater arbeiten in wechselnden Mandaten. Ein Wochenrhythmus mit drei Kunden in zwei Ländern erzeugt Splitting-Anforderungen, die kein Standard-Tool abbildet.

### Irregulärer Betrieb und ungeplante Änderungen

10 bis 20 Prozent aller Flüge sind von Irregularitäten betroffen - Verspätungen, Umleitungen, Crew-Repositionierungen (Quelle: EUROCONTROL / US DOT BTS, 2024). Jede Irregularität ändert die Reisekostenberechnung: andere Pauschale wegen anderem Zielland, anderer Übernachtungsanspruch, andere Kostenstelle.

Kein Standard-Reisekostentool verarbeitet irreguläre Operationen (IROP) automatisch. Die Korrektur erfolgt manuell - wenn sie überhaupt erkannt wird. Bei 100.000 Crew-Vorgängen pro Jahr und einer IROP-Quote von 15 Prozent sind das 15.000 Vorgänge, die manuelle Nachbearbeitung erfordern. Jeder einzelne mit dem Risiko, dass die Korrektur selbst fehlerhaft ist.

### Die Governance-Lücke

SAP Concur dokumentiert, was eingereicht wurde. Es dokumentiert nicht, warum so entschieden wurde. Das ist der Unterschied zwischen einem Erfassungstool und einer Governance-Schicht.

Wenn der Betriebsprüfer fragt: "Nach welcher Regel wurde dieser Verpflegungsmehraufwand berechnet?" - hat Concur keine Antwort. Der Betrag steht im System, die Entscheidungslogik nicht. Wenn der [Betriebsrat](/de/governance/mitbestimmung/) fragt: "Wie werden Reisekosten-Entscheidungen getroffen?" - lautet die ehrliche Antwort in den meisten Konzernen: Der Sachbearbeiter entscheidet nach Erfahrung.

Das ist kein Audit Trail. Das ist Personenabhängigkeit.

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Kostenloses eBook: KI in Finance</p>
<p class="text-body text-gosign-text mb-4">Compliance, Wirtschaftsprüfer und Decision Layer - das Governance-Handbuch für Finance-Verantwortliche.</p>
<a href="/de/ebook/ki-finance-governance-handbuch/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Jetzt kostenlos herunterladen</a>
</div>

## Simulation: 100.000 Crew-Vorgänge pro Jahr

### Die Ausgangslage

Für einen Airline-Konzern mit 100.000 Crew-Vorgängen pro Jahr ergibt sich auf Basis der GBTA-Daten:

<div class="overflow-x-auto">

| Position | Berechnung | Kosten pro Jahr |
|----------|-----------|----------------|
| Verarbeitung | 100.000 x 58 USD | 5.800.000 USD |
| Korrekturen | 100.000 x 19 % x 52 USD | 988.000 USD |
| **Gesamt** | | **6.788.000 USD** |

</div>

Nicht eingerechnet: Genehmiger-Zeitkosten (Führungskräfte, die Belege prüfen statt zu führen), Monatsend-Stau in der Buchhaltung, Audit-Risiko bei Betriebsprüfungen und Mitarbeiterfrustration durch verspätete Erstattungen.

### Der Decision-Layer-Ansatz

Der [Travel Decision Layer](/de/leistungen/travel-decision-layer/) zerlegt jeden Reisekostenvorgang in seine Mikro-Entscheidungen und wendet für jede Entscheidung dokumentierte Regeln an: Gesetz, Tarifvertrag, Unternehmensrichtlinie - in dieser Hierarchie, versioniert, nachvollziehbar.

Die Regelanwendung ist deterministisch. Kein stochastisches Sprachmodell entscheidet über Beträge oder Steuerbehandlung. KI kommt bei der Klassifikation zum Einsatz - Belegtyp erkennen, IROP-Art einordnen, Bewirtungsanlass kategorisieren - aber die Berechnung folgt exakten Regeln.

Für die [Luftfahrt-Simulation](/de/leistungen/travel-decision-layer/aviation/) ergibt sich:

<div class="overflow-x-auto">

| Metrik | Manuell | Mit Decision Layer |
|--------|---------|-------------------|
| Kosten pro Vorgang | 58+ USD | < 10 USD |
| Fehlerquote | 19 % | < 1 % |
| Bearbeitungszeit | 5 - 12 Werktage | Minuten |
| Automatisierungsquote | 0 % | 95 % |
| Audit-Readiness | Manuelle Rekonstruktion | Automatisch generiert |
| Tarifvertragswechsel | Wochen | < 24 Stunden |

</div>

Hochrechnung bei 100.000 Vorgängen: von 6,8 Mio USD auf unter 1 Mio USD pro Jahr. Die Einsparung kommt nicht aus günstigeren Sachbearbeitern, sondern aus dem Wegfall manueller Entscheidungen.

### Der Entscheidungsfluss im Detail

Ein einzelner Crew-Vorgang durchläuft im Decision Layer folgende Schritte:

1. Umlaufdaten aus dem Crew-Planungssystem einlesen
2. Länderfolge aus den Rotationsdaten bestimmen
3. Pauschale pro Land und Tag ermitteln (BMF-Länderliste, gültig zum Reisedatum)
4. Tarifvertrag-Override prüfen (Crew-Gruppe, Geltungszeitraum)
5. Mahlzeitenkürzung berechnen (Frühstück, Mittag, Abend - pro Tag)
6. IROP-Typ klassifizieren (KI-gestützt) und Pauschale neu berechnen
7. Hotelkosten gegen Richtlinie prüfen (Obergrenze pro Stadt)
8. Kostenstelle zuordnen (Rotation, Flotte, Crew-Gruppe)
9. Steuerliche Behandlung festlegen (steuerfrei, pauschal, steuerpflichtig)
10. Audit-Datensatz erzeugen (SHA-256 signiert, append-only)

Jeder dieser Schritte ist eine dokumentierte Entscheidung mit nachvollziehbarer Regelgrundlage. Das ist der Unterschied zu einem Genehmigungsworkflow, in dem ein Mensch "Genehmigt" klickt, ohne dass die Entscheidungslogik im System hinterlegt ist.

## Vier Branchen, vier Komplexitätsstufen

Der Travel Decision Layer ist nicht auf Luftfahrt beschränkt. Die Grundarchitektur - deterministisches Regelwerk über Mikro-Entscheidungen - funktioniert branchenübergreifend mit branchenspezifischer Konfiguration:

<div class="overflow-x-auto">

| Branche | Vorgänge pro Jahr | vollautomatisch | Kernkomplexität |
|---------|------------------|------------|-----------------|
| [Luftfahrt](/de/leistungen/travel-decision-layer/aviation/) | 100k - 1M+ | 95 % | IROP + Multi-Tarifvertrag |
| [Logistik](/de/leistungen/travel-decision-layer/logistik/) | 500k - 2M+ | 95 % | GPS-Präzision + EU-Mobilitätspaket |
| [Vertrieb](/de/leistungen/travel-decision-layer/vertrieb/) | 120k+ | 90 % | CRM-Integration + Bewirtungskosten |
| [Beratung](/de/leistungen/travel-decision-layer/beratung/) | 50k - 250k+ | 85 % | 3-Wege-Split (Steuer / Kunde / intern) |

</div>

Alle vier Simulationen basieren auf denselben GBTA-Ausgangswerten (58 USD pro Vorgang, 19 % Fehlerquote) und zeigen branchenspezifische Optimierungspotenziale. Die unterschiedlichen Automatisierungsquoten spiegeln die Branchenkomplexität wider: Logistik und Luftfahrt erreichen 95 Prozent, weil die Eingabedaten (GPS-Tracks, Crew-Rotationen) maschinenlesbar sind. Beratung liegt bei 85 Prozent, weil Multi-Mandanten-Wochen manuelle Zuordnungen erfordern können.

## Was eine Lösung braucht, die SAP Concur ergänzt

SAP Concur muss nicht ersetzt werden. Es fehlt die Schicht darüber - die Governance-Schicht, die entscheidet, bevor der Beleg ins System kommt:

1. **Tarifvertrag-native Regelengine** - Tarifverträge nicht als Workaround, sondern als erstklassiges Konzept. Pro Personalgruppe konfigurierbar, mit Geltungszeitraum und Override-Hierarchie.
2. **Versionierte Entscheidungstabellen** - Jede Regel datiert, jede Änderung nachvollziehbar. BMF-Pauschalen, Tarifvertragssätze und Unternehmensrichtlinien als datierte Changesets.
3. **Lückenloser Audit Trail** - Jede Mikro-Entscheidung signiert (SHA-256), im Append-only-Verfahren gespeichert. Kein Überschreiben, kein Löschen, vollständig reproduzierbar.
4. **[Betriebsratskompatible](/de/governance/mitbestimmung/) Transparenz** - Das Regelwerk ist einsehbar, die Entscheidungslogik nachvollziehbar. Keine Blackbox-KI entscheidet über Beträge.
5. **ERP-Integration** - Kein Systemersatz, sondern Eingabe in bestehende ERP- und Payroll-Systeme. Der Decision Layer sitzt zwischen Datenquelle und Buchungssystem.
6. **Multi-Jurisdiktion pro Vorgang** - Nicht pro Reise, sondern pro Tag, mit minutengenauer Grenzüberschreitung.

Gosign implementiert diese Governance-Schicht als [Travel Decision Layer](/de/leistungen/travel-decision-layer/) - branchenspezifisch konfiguriert, auf Ihrer [Infrastruktur](/de/leistungen/infrastruktur/), ohne externe SaaS-Abhängigkeit.

--- Reisekosten automatisieren: Kosten pro Beleg ---
> 58 USD pro Beleg, 19 % Fehlerquote, 52 USD pro Korrektur. GBTA-Zahlen zeigen: Manuelle Reisekosten kosten Konzerne Millionen - und sind vermeidbar.

## 58 USD pro Beleg - die Zahl, die niemand trackt

Die meisten Finanzabteilungen kennen ihre Reisekosten. Sie wissen, wie viel das Unternehmen pro Jahr für Flüge, Hotels und Verpflegungsmehraufwand ausgibt. Was sie selten wissen: Was kostet die Verarbeitung eines einzelnen Reisekostenbelegs?

Die Antwort liefert die GBTA Foundation in Zusammenarbeit mit HRS: 58 USD pro Vorgang bei manueller Bearbeitung. Die Fehlerquote liegt bei 19 Prozent. Die Korrekturkosten pro Fehler bei 52 USD (Quelle: GBTA Foundation / HRS, "Expense Reporting: Global Practices and Pain Points", 2015).

Diese drei Zahlen verändern die Perspektive. Reisekosten sind nicht nur ein Ausgabenposten - sie sind ein Prozesskosten-Problem. Und bei Konzernen mit Zehntausenden oder Hunderttausenden Vorgängen pro Jahr summiert sich dieses Problem zu Millionenbeträgen.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Auf einen Blick - ROI der Reisekosten-Automatisierung</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Manuelle Verarbeitung kostet 58 USD pro Beleg bei 19 % Fehlerquote und 52 USD pro Korrektur (GBTA Foundation).</li>
<li>Bei 100.000 Vorgängen pro Jahr entstehen allein durch die Verarbeitung fast 7 Millionen USD - vor den eigentlichen Reisekosten.</li>
<li>OCR und Genehmigungsworkflows lösen die Erfassung, nicht die 40 bis 120 Mikro-Entscheidungen pro Vorgang (Pauschalen, Tarifverträge, Steuerbehandlung).</li>
<li>Der Decision-Layer-Ansatz erreicht 85 bis 95 % vollautomatisch durch versionierte, auditierbare Regeln für jede Mikro-Entscheidung.</li>
<li>Die Amortisation beginnt ab 10.000 Vorgängen pro Jahr; die größten Einsparungen entstehen durch Eliminierung der Korrekturschleife.</li>
</ul>
</div>

## Die Anatomie der 58 Dollar

### Sichtbare Kosten: Erfassung und Genehmigung

Der Mitarbeiter fotografiert den Beleg, trägt die Daten in SAP Concur oder ein vergleichbares Tool ein, ordnet eine Kostenstelle zu und reicht ein. Die Führungskraft prüft, genehmigt oder lehnt ab. Der Sachbearbeiter im Shared Service Center prüft nochmals, gleicht mit Richtlinien ab und bucht.

Drei Personen, drei Arbeitsschritte, ein Beleg. Das ist der sichtbare Teil der 58 Dollar.

### Unsichtbare Kosten: Korrekturen und Rückfragen

19 Prozent Fehlerquote bedeutet: Fast jeder fünfte Vorgang muss nachbearbeitet werden. Falsche Pauschale angewandt, Mahlzeitenkürzung vergessen, falscher Tarifvertragssatz verwendet, Kostenstelle verwechselt. Jede Korrektur kostet 52 USD - der Vorgang durchläuft den gesamten Prozess ein zweites Mal.

Dazu kommen Rückfragen: Der Sachbearbeiter fragt beim Mitarbeiter nach, weil Angaben fehlen. Der Mitarbeiter sucht den Beleg, der drei Wochen alt ist. Die Führungskraft wird ein zweites Mal zur Genehmigung gebeten. Diese Schleifen kosten Zeit, die in keiner Kostenrechnung auftaucht.

### Systemische Kosten: Audit-Risiko und Compliance

Wenn 19 Prozent der Vorgänge fehlerhaft sind und nur Stichproben geprüft werden, schlummern systematische Fehler im System. Das Risiko materialisiert sich bei der Betriebsprüfung: Der Prüfer fragt nicht nach einzelnen Belegen, sondern nach der Systematik. Gibt es eine dokumentierte Regelanwendung? Lässt sich nachvollziehen, warum dieser Verpflegungsmehraufwand mit diesem Satz berechnet wurde?

In den meisten Konzernen lautet die Antwort: Nein. Die Entscheidungslogik steckt im Kopf des Sachbearbeiters, nicht im System. Das ist keine [GoBD-konforme Verfahrensdokumentation](https://www.bundesfinanzministerium.de/Content/DE/Downloads/BMF_Schreiben/Weitere_Steuerthemen/Abgabenordnung/2019-11-28-GoBD.html) - das ist ein Audit-Risiko.

## Hochrechnung: Was Reisekosten den Konzern wirklich kosten

### Szenario A: 10.000 Vorgänge pro Jahr (gehobener Mittelstand)

<div class="overflow-x-auto">

| Position | Berechnung | Kosten pro Jahr |
|----------|-----------|----------------|
| Verarbeitung | 10.000 x 58 USD | 580.000 USD |
| Korrekturen | 10.000 x 19 % x 52 USD | 98.800 USD |
| **Gesamt** | | **678.800 USD** |

</div>

Bei 10.000 Vorgängen beschäftigt die Reisekostenverarbeitung rechnerisch 3 bis 4 Vollzeitkräfte im Shared Service Center. Die Korrekturkosten allein entsprechen einem halben FTE.

### Szenario B: 100.000 Vorgänge pro Jahr (Konzern)

<div class="overflow-x-auto">

| Position | Berechnung | Kosten pro Jahr |
|----------|-----------|----------------|
| Verarbeitung | 100.000 x 58 USD | 5.800.000 USD |
| Korrekturen | 100.000 x 19 % x 52 USD | 988.000 USD |
| **Gesamt** | | **6.788.000 USD** |

</div>

Knapp 7 Millionen USD pro Jahr - nur für die Verarbeitung, nicht für die eigentlichen Reisekosten. Dazu kommt: Bei 100.000 Vorgängen und 19 Prozent Fehlerquote sind 19.000 Vorgänge fehlerhaft. Das ist kein Restrisiko, das ist ein systematisches Problem.

### Szenario C: 500.000+ Vorgänge pro Jahr (Logistik, Airline)

<div class="overflow-x-auto">

| Position | Berechnung | Kosten pro Jahr |
|----------|-----------|----------------|
| Verarbeitung | 500.000 x 58 USD | 29.000.000 USD |
| Korrekturen | 500.000 x 19 % x 52 USD | 4.940.000 USD |
| **Gesamt** | | **33.940.000 USD** |

</div>

34 Millionen USD Verarbeitungskosten pro Jahr. Bei Airlines und Logistik-Konzernen, wo jeder Mitarbeiter zwangsläufig reist (Crew fliegt, Fahrer fährt), ist das nicht optional - diese Vorgänge entstehen als Nebenprodukt des Kerngeschäfts.

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Kostenloses eBook: KI in Finance</p>
<p class="text-body text-gosign-text mb-4">Compliance, Wirtschaftsprüfer und Decision Layer - das Governance-Handbuch für Finance-Verantwortliche.</p>
<a href="/de/ebook/ki-finance-governance-handbuch/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Jetzt kostenlos herunterladen</a>
</div>

## Warum OCR und Genehmigungsworkflows nicht reichen

Die naheliegende Antwort auf das Kostenproblem: Digitalisierung. OCR für die Belegerfassung, Workflows für die Genehmigung, Apps für die Einreichung. Das reduziert den manuellen Aufwand bei der Erfassung - aber nicht bei der Entscheidung.

OCR erfasst den Beleg. Ein Workflow routet ihn zur richtigen Person. Aber wer entscheidet:

- Welche Pauschale für Verpflegungsmehraufwand gilt, wenn der Mitarbeiter in drei Ländern war?
- Ob der Tarifvertrag die gesetzliche Pauschale überschreibt - und wenn ja, welcher Tarifvertrag?
- Wie die Mahlzeitengestellung zu kürzen ist, wenn das Hotel ein Frühstück inkludiert, der Mitarbeiter es aber nicht genutzt hat?
- Ob die Bewirtungskosten zu 70 Prozent (Deutschland) oder 50 Prozent (Österreich) absetzbar sind?

Das sind keine Erfassungsprobleme. Das sind Regelanwendungsprobleme. Und kein OCR-System und kein Genehmigungsworkflow löst Regelanwendungsprobleme.

## Der Unterschied zwischen Erfassung und Governance

Was fehlt, ist die Schicht zwischen Belegerfassung und Buchung: eine Governance-Schicht, die für jeden Vorgang dokumentiert, welche Regel angewandt wurde und warum.

Der [Decision Layer](/de/magazin/decision-layer-erklaert/) zerlegt jeden Reisekostenvorgang in seine Mikro-Entscheidungen und definiert für jeden Schritt: Regelwerk, Hierarchie (Gesetz vor Tarifvertrag vor Richtlinie) und Dokumentation. Die Entscheidung wird nicht von einem Menschen getroffen, der nach Erfahrung handelt, sondern von einem versionierten Regelwerk, das nachvollziehbar, reproduzierbar und [auditierbar](/de/magazin/cert-ready-by-design/) ist.

Das ändert auch das Arbeitsmodell: Statt Einreichen, Genehmigen, Buchen (drei manuelle Schritte) wird der Vorgang automatisch verarbeitet. Der Mitarbeiter erhält das Ergebnis und hat ein Widerspruchsrecht - der Veto-Ansatz. Statt jeden Vorgang manuell zu prüfen, werden nur die Ausnahmen bearbeitet. Das ist der Unterschied zwischen 0 Prozent und 85 bis 95 Prozent vollautomatisch.

## Vier Branchen, vier ROI-Profile

Der [Travel Decision Layer](/de/leistungen/travel-decision-layer/) ist branchenübergreifend einsetzbar. Die Automatisierungsquote variiert je nach Branche, weil die Eingabedaten unterschiedlich strukturiert sind:

<div class="overflow-x-auto">

| Branche | Vorgänge pro Jahr | vollautomatisch | Kosten vorher | Kosten nachher | Einsparung |
|---------|------------------|------------|--------------|----------------|------------|
| [Luftfahrt](/de/leistungen/travel-decision-layer/aviation/) | 100k - 1M+ | 95 % | 58+ USD | < 10 USD | > 80 % |
| [Logistik](/de/leistungen/travel-decision-layer/logistik/) | 500k - 2M+ | 95 % | 58+ USD | < 5 USD | > 90 % |
| [Vertrieb](/de/leistungen/travel-decision-layer/vertrieb/) | 120k+ | 90 % | 58+ USD | < 8 USD | > 85 % |
| [Beratung](/de/leistungen/travel-decision-layer/beratung/) | 50k - 250k+ | 85 % | 58+ USD | < 10 USD | > 80 % |

</div>

Die höchsten Automatisierungsquoten erreichen Branchen mit maschinenlesbaren Eingabedaten: GPS-Tracks in der Logistik, Crew-Rotationen in der Luftfahrt. Beratung liegt bei 85 Prozent, weil Multi-Mandanten-Wochen manuelle Zuordnung erfordern können.

Entscheidend für den [ROI](/de/magazin/roi-ki-investitionen/) ist nicht nur die Kostenreduktion pro Vorgang, sondern die Eliminierung der Korrekturschleife: Von 19 Prozent Fehlerquote auf unter 2 Prozent bedeutet, dass die 52-USD-Korrekturkosten praktisch wegfallen.

## Der Veto-Ansatz: Automatisierung ohne Kontrollverlust

Ein häufiger Einwand gegen Automatisierung: "Wir verlieren die Kontrolle." Der Veto-Ansatz dreht die Logik um.

Heute: Der Mitarbeiter reicht ein. Die Führungskraft genehmigt. Der Sachbearbeiter bucht. Drei manuelle Schritte, jeder einzelne fehleranfällig.

Mit Decision Layer: Das System berechnet den Vorgang automatisch auf Basis der hinterlegten Regeln. Der Mitarbeiter sieht das Ergebnis und kann Widerspruch einlegen - innerhalb einer definierten Frist. Ohne Widerspruch wird der Vorgang automatisch gebucht.

Das ist nicht weniger Kontrolle. Es ist mehr Kontrolle - dokumentierte, nachvollziehbare, reproduzierbare Kontrolle. Statt einer subjektiven Genehmigung durch eine Führungskraft, die den Tarifvertrag nicht im Detail kennt, entscheidet ein Regelwerk, das vom [Betriebsrat](/de/magazin/betriebsrat-ki-mitbestimmung/) eingesehen und vom Wirtschaftsprüfer geprüft werden kann.

## Was sich rechnet - und was nicht

Nicht jeder Konzern braucht eine vollautomatisierte Reisekostenverarbeitung. Die Investition lohnt sich, wenn mindestens zwei der folgenden Kriterien zutreffen:

- **Volumen**: Mehr als 10.000 Reisekostenvorgänge pro Jahr
- **Regelkomplexität**: Tarifverträge, Multi-Jurisdiktion oder branchenspezifische Sonderregeln
- **Audit-Anforderungen**: GoBD-konforme Verfahrensdokumentation, Betriebsprüfungs-Readiness
- **Shared Service Center**: Zentralisierte Verarbeitung mit dokumentierter Prozessqualität

Wenn nur Inlandsreisen ohne Tarifverträge zu verarbeiten sind, reicht SAP Concur oder ein vergleichbares Tool. Die Governance-Schicht wird dort relevant, wo die Regeln komplex genug sind, dass ein Sachbearbeiter Fehler macht - also dort, wo die GBTA-Zahlen ihre volle Wirkung entfalten.

Gosign implementiert den [Travel Decision Layer](/de/leistungen/travel-decision-layer/) branchenspezifisch - von der Evaluierung über einen 3-monatigen Piloten bis zum produktiven Betrieb. Auf Ihrer [Infrastruktur](/de/leistungen/infrastruktur/), ohne externe SaaS-Abhängigkeit, mit vollem Quellcode-Zugang.

--- ROI von KI-Investitionen messen ---
> Wie CFOs den ROI von Enterprise AI bewerten. Prozesskosten, Fehlerquoten, Audit-Aufwand als messbare KPIs statt vager Produktivitätsversprechen.

## Das Problem mit dem KI-ROI

Die meisten ROI-Berechnungen für KI-Investitionen scheitern an Unschärfe. „30% produktiver" klingt überzeugend in einer Präsentation, ist aber nicht belegbar wenn niemand definiert hat, was „produktiver" in einem konkreten Prozess bedeutet.

CFOs kennen dieses Problem. Sie sehen Pilotprojekte, die beeindruckende Demos liefern, aber keine belastbaren Zahlen für die Geschäftsleitung. Sie sehen KI-Budgets, die als Innovationsprojekte freigegeben werden, aber keinen nachvollziehbaren Business Case haben.

Das liegt nicht daran, dass KI keinen ROI hat. Es liegt daran, dass KI am falschen Punkt gemessen wird.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Auf einen Blick - ROI von Enterprise AI messen</p>
<ul class="text-body text-gosign-text space-y-2">
<li>KI-ROI entsteht durch Prozesseffizienz, nicht durch individuelle Produktivität. Ein automatisierter Dokumentenprozess spart über 200 Stunden pro Monat.</li>
<li>Fünf KPIs machen ROI messbar: Prozesskosten pro Vorgang, Fehlerquote, Durchlaufzeit, Audit-Aufwand und Skalierungskosten.</li>
<li>Laut McKinsey (2024) erreichen Unternehmen, die KI in Finanzprozessen einsetzen, im ersten Jahr 30 bis 50 % Kostenreduktion bei dokumentenintensiven Prozessen.</li>
<li>Der Decision Layer trennt KI-Analyse von Geschäftsentscheidung und erzeugt einen automatischen Audit Trail - ROI-Kennzahlen entstehen als Nebenprodukt.</li>
<li>Starten Sie mit einem Prozess, einem Agenten und messen Sie KPIs nach 4 bis 6 Wochen. Die Differenz ist der ROI.</li>
</ul>
</div>

## Wo der ROI tatsächlich entsteht

Der ROI von Enterprise AI entsteht nicht bei der Produktivität einzelner Mitarbeiter. Er entsteht bei der Prozesseffizienz ganzer Abläufe.

Ein Beispiel: In einer HR-Shared-Services-Organisation verarbeitet ein Team von 8 Sachbearbeitern monatlich 1.200 Krankmeldungen. Jeder Vorgang dauert durchschnittlich 12 Minuten: Dokument öffnen, Daten prüfen, Fristen berechnen, in SAP buchen, Vorgesetzten informieren. Das sind 240 Stunden pro Monat für einen einzigen Dokumenttyp.

Ein [Document Agent](/de/leistungen/ai-agents/) reduziert die manuelle Bearbeitungszeit pro Vorgang auf unter 2 Minuten - bei Standardfällen auf null, weil der Agent den gesamten Prozess bis zur Freigabe-Vorlage automatisiert. Die Sachbearbeiter prüfen nur noch Ausnahmen und Eskalationen.

Das ist kein vages Produktivitätsversprechen. Das ist eine messbare Reduktion von 240 auf 40 Stunden pro Monat - für einen einzigen Prozess. Multipliziert über 5 - 10 Prozesse ergibt sich ein Business Case, den jeder CFO versteht.


## Die richtigen KPIs

Fünf KPIs machen den ROI von AI-Agenten messbar und intern kommunizierbar.

Erstens: Prozesskosten pro Vorgang. Was kostet die Verarbeitung einer Krankmeldung, einer Rechnung, eines Vertrags heute? Was kostet sie nach Agent-Einführung? Die Differenz ist der direkte ROI.

Zweitens: Fehlerquote. Manuelle Prozesse haben typischerweise Fehlerquoten von 2 - 5%. Ein regelbasierter Agent macht Fehler nur bei Regelfehlern - die wiederum versioniert und korrigierbar sind. Jeder vermiedene Fehler hat einen bezifferbaren Folgekosten-Wert.

Drittens: Durchlaufzeit. Wie lange dauert ein Vorgang von Eingang bis Abschluss? Agenten reduzieren die Liegezeit auf nahe null - der Vorgang wird verarbeitet, sobald er eingeht, nicht wenn ein Sachbearbeiter ihn aufruft.

Viertens: Audit-Aufwand. In regulierten Prozessen (Lohnsteuer, Betriebsprüfung, SOX) entsteht erheblicher Aufwand durch manuelle Dokumentation und Nachweisführung. Ein Agent mit [Decision Layer](/de/decision-layer/) dokumentiert automatisch: Welche Regel wurde angewandt, welche Daten lagen vor, welche Entscheidung wurde getroffen, wer hat freigegeben. Der Audit-Trail entsteht als Nebenprodukt des Prozesses.

Fünftens: Skalierungskosten. Was kostet es, das aktuelle Volumen um 50% zu steigern? Mit manuellen Prozessen: mehr Personal. Mit Agent-Infrastruktur: mehr Rechenkapazität. Die Kostenkurven divergieren radikal.

<div class="overflow-x-auto">

| KPI | Manueller Prozess | Mit AI Agent | Messmethode |
|-----|-------------------|-------------|-------------|
| Prozesskosten pro Vorgang | 15 - 60 USD | 2 - 8 USD | Vorher-/Nachher-Vergleich |
| Fehlerquote | 2 - 5 % | < 0,5 % | Stichprobenprüfung |
| Durchlaufzeit | 1 - 5 Tage | Minuten | Zeitstempel-Delta |
| Audit-Aufwand | 40 - 80 h/Monat | < 5 h/Monat | Erfasste Stunden |
| Skalierung (+50 % Volumen) | +50 % Personal | +10 % Compute | Kostentracking |

</div>

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Kostenloses eBook: KI in Finance</p>
<p class="text-body text-gosign-text mb-4">Compliance, Wirtschaftsprüfer und Decision Layer - das Governance-Handbuch für Finance-Verantwortliche.</p>
<a href="/de/ebook/ki-finance-governance-handbuch/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Jetzt kostenlos herunterladen</a>
</div>

## Der Decision Layer als ROI-Hebel

Der [Decision Layer](/de/decision-layer/) ist der Punkt, an dem ROI messbar wird. Er trennt die KI-Analyse von der Geschäftsentscheidung und dokumentiert beides als prüfbare Akte.

Das bedeutet: Für jeden Vorgang existiert ein vollständiger Datensatz - Eingabe, angewandte Regel, Empfehlung des Agents, Entscheidung des Menschen, Zeitstempel. Aus diesen Datensätzen lassen sich ROI-Kennzahlen automatisch ableiten, ohne manuelle Erhebung.

Daraus folgt auch: Der ROI verbessert sich über die Zeit. Weil Regelanpassungen versioniert werden und ihre Auswirkung auf Fehlerquoten und Durchlaufzeiten messbar ist, entsteht ein kontinuierlicher Optimierungszyklus - dokumentiert und nachvollziehbar.


## Wie Unternehmen starten sollten

Nicht mit einer KI-Strategie. Sondern mit einem konkreten Prozess.

Den Prozess identifizieren, der das höchste Volumen und die höchsten manuellen Kosten hat. Die Baseline messen: aktuelle Prozesskosten, Fehlerquote, Durchlaufzeit. Einen Agent darauf bauen und nach 4 - 6 Wochen die gleichen KPIs messen.

Die Differenz ist der ROI. Keine PowerPoint, keine Schätzung - harte Zahlen aus einem produktiven Prozess.

Bei Gosign bauen wir [AI-Agenten](/de/leistungen/ai-agents/) mit genau diesem Ansatz: ein Prozess, ein Agent, messbare KPIs nach 4 - 6 Wochen. Der [Decision Layer](/de/decision-layer/) liefert die Datenbasis für den Business Case automatisch mit.

--- Security Baseline für den gesamten Stack ---
> YAML-basierte Security Baseline für Supabase, Next.js, Edge Functions und Trigger.dev mit automatisierten Checks.

Die vorherigen Runbooks haben die einzelnen Komponenten beschrieben: [Supabase Platform mit RLS und Backup-Konfiguration](/de/magazin/supabase-self-hosting/#teil-b---supabase-services-einrichten-und-absichern) (Artikel 1), [Next.js App Layer mit Auth-Middleware und Environment-Trennung](/de/magazin/nextjs-supabase-sicher-betreiben/#b1---environment-variablen-trennen) (Artikel 2), [Edge Functions mit Webhook-Signaturen](/de/magazin/supabase-edge-functions-sicher/#b1---webhook-signaturen-prüfen) (Artikel 3), [Trigger.dev Jobs mit Idempotenz-Patterns](/de/magazin/trigger-dev-background-jobs/#b2---idempotenz-sicherstellen) (Artikel 4) und [Claude Code als kontextuelle Analyse-Schicht](/de/magazin/claude-code-security-devops/#grundprinzip-drei-ebenen-der-sicherheitsprüfung) (Artikel 5).

Dieser letzte Artikel führt alle Regeln in einer **einzigen, maschinenlesbaren Datei** zusammen: der `security-baseline.yml`. Organisationen mit einer maschinenlesbaren Security Baseline erkennen Konfigurationsdrift im Durchschnitt 14x schneller als Teams ohne Baseline (SANS Institute 2024). Diese Datei definiert den Soll-Zustand des gesamten Stacks. Alle Deployments, Reviews und Audits werden gegen diese Baseline geprüft, sowohl durch deterministische Scripts als auch durch Claude Code.

Der Artikel liefert drei Dinge:
1. Die vollständige `security-baseline.yml`
2. Das Script das sie automatisch prüft
3. Die Integration mit dem Claude Code Audit aus Artikel 5

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Auf einen Blick - Artikel 6 von 6 der DevOps-Runbook-Serie</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Eine einzige YAML-Datei (security-baseline.yml) definiert den Soll-Zustand des gesamten Stacks</li>
<li>Täglicher automatisierter Check prüft alle Regeln deterministisch</li>
<li>Wöchentliche Claude Code Analyse interpretiert Ergebnisse und priorisiert Findings</li>
<li>Deployment Gate blockiert Releases bei kritischen Baseline-Verletzungen</li>
<li>Lebendiges Dokument: Baseline wird bei jeder Stack-Änderung aktualisiert</li>
</ul>
</div>

## Serien-Inhaltsverzeichnis

Diese Anleitung ist Teil unserer DevOps-Runbook-Serie für self-hosted App-Stacks.

1. [Supabase Self-Hosting Runbook](/de/magazin/supabase-self-hosting/)
2. [Next.js über Supabase sicher betreiben](/de/magazin/nextjs-supabase-sicher-betreiben/)
3. [Supabase Edge Functions sicher einsetzen](/de/magazin/supabase-edge-functions-sicher/)
4. [Trigger.dev Background Jobs sicher betreiben](/de/magazin/trigger-dev-background-jobs/)
5. [Claude Code als Sicherheitskontrolle im DevOps-Workflow](/de/magazin/claude-code-security-devops/)
6. [Security Baseline für den gesamten Stack](/de/magazin/security-baseline-stack/) - dieser Artikel

Dieser Artikel verbindet alle vorherigen Runbooks zu einer **prüfbaren Sicherheitsstrategie**.

## Architekturüberblick

```
security-baseline.yml
   |
   +---> scripts/check-baseline.sh     (deterministisch, täglich)
   |       |
   |       +---> baseline-report.md    (Fakten: bestanden/nicht bestanden)
   |
   +---> Claude Code Audit             (kontextuell, wöchentlich)
   |       |
   |       +---> claude-review.md      (Interpretation + Prioritäten)
   |
   +---> Deployment Gate               (CI/CD, bei jedem Deploy)
           |
           +---> Deploy blockiert wenn kritische Regeln verletzt
```

Die Baseline ist die **Single Source of Truth** für den Sicherheitszustand. Alles andere, die Check-Scripts, Claude Code, die Deployment-Checklisten aus Artikel 1-5, leitet sich davon ab.

## Die security-baseline.yml

Diese Datei gehört in das Root des Infrastruktur-Repositories. Sie ist maschinenlesbar (YAML), menschenlesbar (Kommentare) und von Claude Code interpretierbar (Kontext).

### Baseline-Kategorien im Überblick

| Kategorie | Anzahl Regeln | Prüffrequenz | Eskalation bei Verstoß |
|-----------|--------------|--------------|----------------------|
| Infrastruktur (Netzwerk, Firewall, SSH) | 8 | Täglich | KRITISCH: sofort |
| Supabase (Container, RLS, Secrets) | 7 | Täglich | KRITISCH: sofort |
| Next.js (Auth, Headers, Env Vars) | 6 | Täglich | WARNUNG: diese Woche |
| Edge Functions (Signaturen, CORS, Secrets) | 5 | Täglich | KRITISCH: sofort |
| Trigger.dev (Tasks, Concurrency, Secrets) | 6 | Täglich | WARNUNG: diese Woche |
| Compliance (Git, Data Residency) | 3 | Wöchentlich | WARNUNG: diese Woche |

```yaml
# security-baseline.yml
# Security Baseline für den self-hosted Stack
# Letzte Aktualisierung: 2026-03-12
# Verantwortlich: DevOps Team
#
# Diese Datei definiert den Soll-Zustand des gesamten Stacks.
# Sie wird täglich automatisch geprüft (scripts/check-baseline.sh)
# und wöchentlich von Claude Code kontextuell analysiert.

version: "1.0"
stack: "supabase-nextjs-trigger"
last_reviewed: "2026-03-12"

# =============================================
# INFRASTRUKTUR (Artikel 1)
# =============================================

infrastructure:
  servers:
    production:
      host: "10.0.1.10"
      external_hostname: "app.example.com"
      provider: "hetzner"    # CLOUD-Act-frei
    audit:
      host: "10.0.1.11"
      purpose: "security checks, monitoring, claude code"

  network:
    private_subnet: "10.0.1.0/24"
    # Nur diese Ports dürfen von aussen erreichbar sein
    allowed_external_ports:
      - 443    # HTTPS (über Reverse Proxy)
    # Diese Ports dürfen NUR intern erreichbar sein
    internal_only_ports:
      - 5432   # PostgreSQL (Supabase)
      - 5433   # PostgreSQL (Trigger.dev)
      - 8000   # Kong API Gateway
      - 3000   # Next.js (hinter Reverse Proxy)
      - 3040   # Trigger.dev Dashboard
      - 9000   # Supabase Studio

  firewall:
    layers: 2    # Cloud Firewall + Host Firewall
    baseline_file: "/opt/baselines/firewall-baseline.txt"
    drift_check: "daily"

  tls:
    provider: "letsencrypt"
    min_days_before_expiry: 14
    headers_required:
      - "Strict-Transport-Security"
      - "X-Frame-Options"
      - "X-Content-Type-Options"
      - "Content-Security-Policy"

  ssh:
    password_auth: false
    root_login: false
    pubkey_only: true
    allowed_users: ["deploy"]

  backups:
    frequency: "daily"
    max_age_hours: 26
    encryption: "gpg"
    external_storage: true    # auf audit-runner, nicht nur lokal
    restore_test: "monthly"

# =============================================
# SUPABASE PLATFORM (Artikel 1)
# =============================================

supabase:
  images:
    pinned: true              # kein :latest
    # Erwartete Images und Versionen (aktualisieren bei Updates)
    postgres: "supabase/postgres:15.6.1.143"
    kong: "kong:2.8.1"
    gotrue: "supabase/gotrue:v2.164.0"

  postgres:
    listen_address: "10.0.1.10"    # NUR internes Interface
    rls:
      required_on_all_public_tables: true
      # Tabellen die bewusst ohne RLS sind (mit Begründung)
      exceptions: []

  gotrue:
    jwt_exp: 3600               # max. 1 Stunde
    mailer_autoconfirm: false
    refresh_token_rotation: true

  studio:
    external_access: false      # nur über SSH Tunnel oder VPN

  secrets:
    env_file: ".env"
    env_file_permissions: "600"
    in_git: false
    min_length: 16
    # Erwartete Secrets (ohne Werte)
    required:
      - "JWT_SECRET"
      - "ANON_KEY"
      - "SERVICE_ROLE_KEY"
      - "POSTGRES_PASSWORD"
      - "DASHBOARD_USERNAME"
      - "DASHBOARD_PASSWORD"

# =============================================
# NEXT.JS APP LAYER (Artikel 2)
# =============================================

nextjs:
  service_role:
    # Dateien in denen service_role erlaubt ist
    allowed_files:
      - "lib/supabase/admin.ts"
    # Darf NIEMALS erscheinen in:
    forbidden_patterns:
      - "NEXT_PUBLIC_*"
      - "app/**/*.tsx"           # Client Components
      - ".next/static/**"        # Client Bundle

  auth:
    middleware_required: true
    middleware_file: "middleware.ts"
    middleware_uses: "getUser"     # NICHT getSession
    server_actions_require_auth: true
    route_handlers_require_auth: true

  security_headers:
    required:
      - "Strict-Transport-Security"
      - "X-Frame-Options"
      - "Content-Security-Policy"
      - "X-Content-Type-Options"

  env_vars:
    # Nur diese dürfen NEXT_PUBLIC sein
    allowed_public:
      - "NEXT_PUBLIC_SUPABASE_URL"
      - "NEXT_PUBLIC_SUPABASE_ANON_KEY"

  rate_limiting:
    required_endpoints:
      - "/api/auth/login"
      - "/api/auth/signup"
      - "/api/auth/reset"

# =============================================
# EDGE FUNCTIONS (Artikel 3)
# =============================================

edge_functions:
  purpose: "integrations_only"     # NICHT für Business-Logik
  runtime: "deno"

  requirements:
    webhook_signature_check: true
    input_validation: true
    cors_no_wildcard_in_production: true
    no_hardcoded_secrets: true
    max_duration_seconds: 60

  secrets:
    env_file: ".env.functions"
    in_git: false

  deployment:
    method: "volume_copy"          # Dateien ins Volume, Container restart

# =============================================
# TRIGGER.DEV (Artikel 4)
# =============================================

trigger_dev:
  version: "v3"
  hosting: "self-hosted"
  separate_database: true           # eigene PostgreSQL, nicht Supabase DB

  dashboard:
    external_access: false          # nur SSH Tunnel oder VPN

  task_requirements:
    max_duration_required: true
    concurrency_limit_required: true
    retry_config_required: true
    idempotency_on_external_calls: true
    exported: true                  # alle Tasks müssen exportiert sein

  logging:
    use_trigger_logger: true        # nicht console.log
    no_sensitive_data: true

  db_access:
    # Dateien in denen service_role / DATABASE_URL erlaubt ist
    allowed_files:
      - "trigger/lib/supabase.ts"
      - "trigger/lib/db.ts"
    connection_pool_max: 10

# =============================================
# CLAUDE CODE AUDIT (Artikel 5)
# =============================================

claude_code:
  runs_on: "audit-runner"           # NICHT auf Produktion
  allowed_tools: "Read,Grep,Glob"   # kein Bash
  max_turns: 10
  schedule: "weekly"                # Sonntag 06:00
  alert_on: "KRITISCH"

  api_key:
    separate_ci_key: true
    budget_limit_monthly_usd: 50

# =============================================
# COMPLIANCE
# =============================================

compliance:
  cloud_act:
    us_providers_allowed: false
    reason: "CLOUD Act Risiko: US-Behörden können Datenzugriff erzwingen"
    allowed_jurisdictions:
      - "EU"
      - "BR"

  data_residency:
    required: true
    allowed_countries:
      - "DE"     # Deutschland (Hetzner)
      - "BR"     # Brasilien

  git:
    no_secrets_in_repo: true
    infrastructure_as_code: true
    no_manual_server_changes: true
```

## Das Baseline-Check-Script

Dieses Script liest die `security-baseline.yml` und prüft jeden Punkt automatisch. Es läuft täglich auf dem Audit-Server.

```bash
#!/bin/bash
# scripts/check-baseline.sh
# Prüft den Produktionsserver gegen die security-baseline.yml
# Läuft auf dem audit-runner (10.0.1.11)

set -euo pipefail

PROD_HOST="10.0.1.10"
EXTERNAL_HOST="app.example.com"
REPORT=""
CRITICAL=0
WARNING=0
PASS=0

check() {
  local level="$1"    # KRITISCH, WARNUNG, INFO
  local name="$2"
  local result="$3"   # PASS oder FAIL
  local detail="$4"

  if [ "$result" = "PASS" ]; then
    REPORT+="  OK ${name}\n"
    ((PASS++))
  else
    REPORT+="  FAIL [${level}] ${name}: ${detail}\n"
    [ "$level" = "KRITISCH" ] && ((CRITICAL++))
    [ "$level" = "WARNUNG" ] && ((WARNING++))
  fi
}

echo "=== Security Baseline Check $(date +%Y-%m-%d) ==="

# -------------------------------------------
# INFRASTRUKTUR
# -------------------------------------------
REPORT+="\n## Infrastruktur\n\n"

# Ports von aussen
OPEN_PORTS=$(nmap -p 22,80,443,3000,3040,5432,5433,8000,9000 "$EXTERNAL_HOST" \
  -oG - 2>/dev/null | grep -oP '\d+/open' | grep -v "443" || true)
if [ -z "$OPEN_PORTS" ]; then
  check "KRITISCH" "Nur Port 443 extern offen" "PASS" ""
else
  check "KRITISCH" "Nur Port 443 extern offen" "FAIL" "Offen: $OPEN_PORTS"
fi

# Firewall Drift
FW_DIFF=$(ssh deploy@${PROD_HOST} "iptables-save" 2>/dev/null | \
  diff /opt/baselines/firewall-baseline.txt - 2>&1 || true)
if [ -z "$FW_DIFF" ]; then
  check "WARNUNG" "Firewall unverändert" "PASS" ""
else
  check "WARNUNG" "Firewall unverändert" "FAIL" "Firewall hat sich geändert"
fi

# SSH Konfiguration
SSH_PW=$(ssh deploy@${PROD_HOST} "sshd -T 2>/dev/null | grep passwordauthentication" || true)
if echo "$SSH_PW" | grep -q "no"; then
  check "KRITISCH" "SSH Passwort-Login deaktiviert" "PASS" ""
else
  check "KRITISCH" "SSH Passwort-Login deaktiviert" "FAIL" "Passwort-Auth noch aktiv"
fi

SSH_ROOT=$(ssh deploy@${PROD_HOST} "sshd -T 2>/dev/null | grep permitrootlogin" || true)
if echo "$SSH_ROOT" | grep -q "no"; then
  check "KRITISCH" "SSH Root-Login deaktiviert" "PASS" ""
else
  check "KRITISCH" "SSH Root-Login deaktiviert" "FAIL" "Root-Login noch möglich"
fi

# TLS Zertifikat
CERT_DAYS=$(echo | openssl s_client -connect ${EXTERNAL_HOST}:443 2>/dev/null | \
  openssl x509 -noout -enddate 2>/dev/null | cut -d= -f2)
if [ -n "$CERT_DAYS" ]; then
  EPOCH_CERT=$(date -d "$CERT_DAYS" +%s 2>/dev/null || echo 0)
  EPOCH_NOW=$(date +%s)
  DAYS_LEFT=$(( (EPOCH_CERT - EPOCH_NOW) / 86400 ))
  if [ "$DAYS_LEFT" -ge 14 ]; then
    check "WARNUNG" "TLS Zertifikat gültig (${DAYS_LEFT} Tage)" "PASS" ""
  else
    check "WARNUNG" "TLS Zertifikat gültig" "FAIL" "Nur noch ${DAYS_LEFT} Tage"
  fi
fi

# Security Headers
for HEADER in "Strict-Transport-Security" "X-Frame-Options" "X-Content-Type-Options"; do
  if curl -sI "https://${EXTERNAL_HOST}" | grep -qi "$HEADER"; then
    check "WARNUNG" "Header: ${HEADER}" "PASS" ""
  else
    check "WARNUNG" "Header: ${HEADER}" "FAIL" "Header fehlt"
  fi
done

# Backup
LAST_BACKUP=$(ssh deploy@${PROD_HOST} "ls -t /opt/backups/*.gpg 2>/dev/null | head -1" || true)
if [ -n "$LAST_BACKUP" ]; then
  BACKUP_AGE=$(ssh deploy@${PROD_HOST} \
    "echo \$(( (\$(date +%s) - \$(stat -c %Y ${LAST_BACKUP})) / 3600 ))" 2>/dev/null || echo 999)
  if [ "$BACKUP_AGE" -le 26 ]; then
    check "KRITISCH" "Backup aktuell (${BACKUP_AGE}h alt)" "PASS" ""
  else
    check "KRITISCH" "Backup aktuell" "FAIL" "${BACKUP_AGE} Stunden alt"
  fi
else
  check "KRITISCH" "Backup aktuell" "FAIL" "Kein Backup gefunden"
fi

# Disk Space
DISK=$(ssh deploy@${PROD_HOST} "df -h / | tail -1 | awk '{print \$5}' | tr -d '%'" 2>/dev/null || echo 99)
if [ "$DISK" -le 85 ]; then
  check "WARNUNG" "Disk Usage (${DISK}%)" "PASS" ""
else
  check "WARNUNG" "Disk Usage" "FAIL" "${DISK}% belegt"
fi

# -------------------------------------------
# SUPABASE
# -------------------------------------------
REPORT+="\n## Supabase\n\n"

# Container laufen
STOPPED=$(ssh deploy@${PROD_HOST} "cd /opt/supabase && docker compose ps --format json 2>/dev/null" | \
  jq -r 'select(.State != "running") | .Name' 2>/dev/null || true)
if [ -z "$STOPPED" ]; then
  check "KRITISCH" "Alle Supabase Container running" "PASS" ""
else
  check "KRITISCH" "Alle Supabase Container running" "FAIL" "Gestoppt: $STOPPED"
fi

# Images gepinnt (kein :latest)
LATEST_IMAGES=$(ssh deploy@${PROD_HOST} "cd /opt/supabase && grep 'image:' docker-compose.yml | grep 'latest'" 2>/dev/null || true)
if [ -z "$LATEST_IMAGES" ]; then
  check "WARNUNG" "Alle Images versioniert (kein :latest)" "PASS" ""
else
  check "WARNUNG" "Alle Images versioniert" "FAIL" "latest gefunden"
fi

# RLS auf allen public-Tabellen
UNPROTECTED=$(ssh deploy@${PROD_HOST} "cd /opt/supabase && docker compose exec -T postgres psql -U postgres -t -c \
  \"SELECT count(*) FROM pg_tables WHERE schemaname = 'public' AND rowsecurity = false;\"" 2>/dev/null | tr -d ' ' || echo "?")
if [ "$UNPROTECTED" = "0" ]; then
  check "KRITISCH" "RLS auf allen public-Tabellen aktiv" "PASS" ""
elif [ "$UNPROTECTED" != "?" ]; then
  check "KRITISCH" "RLS auf allen public-Tabellen aktiv" "FAIL" "${UNPROTECTED} Tabellen ohne RLS"
fi

# Postgres nur intern
PG_LISTEN=$(ssh deploy@${PROD_HOST} "ss -tlnp | grep 5432" 2>/dev/null || true)
if echo "$PG_LISTEN" | grep -q "0.0.0.0:5432"; then
  check "KRITISCH" "Postgres nur auf internem Interface" "FAIL" "Lauscht auf 0.0.0.0"
else
  check "KRITISCH" "Postgres nur auf internem Interface" "PASS" ""
fi

# Studio nicht extern erreichbar
STUDIO=$(curl -s -o /dev/null -w "%{http_code}" --connect-timeout 3 "https://${EXTERNAL_HOST}:9000" 2>/dev/null || echo "000")
if [ "$STUDIO" = "000" ]; then
  check "KRITISCH" "Supabase Studio nicht extern erreichbar" "PASS" ""
else
  check "KRITISCH" "Supabase Studio nicht extern erreichbar" "FAIL" "Status: $STUDIO"
fi

# -------------------------------------------
# NEXT.JS
# -------------------------------------------
REPORT+="\n## Next.js\n\n"

# service_role im Client Code
SR_LEAK=$(ssh deploy@${PROD_HOST} "cd /opt/app && grep -rn 'SERVICE_ROLE\|service_role' app/ \
  --include='*.ts' --include='*.tsx' 2>/dev/null | grep -v 'lib/supabase/admin.ts' | grep -v node_modules" 2>/dev/null || true)
if [ -z "$SR_LEAK" ]; then
  check "KRITISCH" "service_role nicht im Client Code" "PASS" ""
else
  check "KRITISCH" "service_role nicht im Client Code" "FAIL" "Gefunden in: $(echo "$SR_LEAK" | head -3)"
fi

# NEXT_PUBLIC mit Secrets
PUB_SECRET=$(ssh deploy@${PROD_HOST} "cd /opt/app && grep 'NEXT_PUBLIC_' .env* 2>/dev/null | \
  grep -iE 'service_role|secret|private|database'" 2>/dev/null || true)
if [ -z "$PUB_SECRET" ]; then
  check "KRITISCH" "Keine Secrets in NEXT_PUBLIC Variablen" "PASS" ""
else
  check "KRITISCH" "Keine Secrets in NEXT_PUBLIC Variablen" "FAIL" "$PUB_SECRET"
fi

# middleware.ts existiert und nutzt getUser
MW_EXISTS=$(ssh deploy@${PROD_HOST} "test -f /opt/app/middleware.ts && echo yes || echo no" 2>/dev/null || echo "no")
if [ "$MW_EXISTS" = "yes" ]; then
  MW_GETUSER=$(ssh deploy@${PROD_HOST} "grep -c 'getUser' /opt/app/middleware.ts" 2>/dev/null || echo "0")
  if [ "$MW_GETUSER" -gt 0 ]; then
    check "KRITISCH" "middleware.ts existiert mit getUser()" "PASS" ""
  else
    check "KRITISCH" "middleware.ts mit getUser()" "FAIL" "getUser() fehlt"
  fi
else
  check "KRITISCH" "middleware.ts existiert" "FAIL" "Datei fehlt"
fi

# Server Actions ohne Auth
SA_NO_AUTH=$(ssh deploy@${PROD_HOST} "cd /opt/app && for file in \$(grep -rl \"'use server'\" app/ --include='*.ts' 2>/dev/null); do
  if ! grep -q 'getUser' \"\$file\"; then echo \"\$file\"; fi
done" 2>/dev/null || true)
if [ -z "$SA_NO_AUTH" ]; then
  check "WARNUNG" "Alle Server Actions haben Auth Check" "PASS" ""
else
  check "WARNUNG" "Server Actions ohne Auth" "FAIL" "$SA_NO_AUTH"
fi

# npm audit
NPM_HIGH=$(ssh deploy@${PROD_HOST} "cd /opt/app && npm audit --audit-level=high 2>&1 | \
  grep -c 'high\|critical'" 2>/dev/null || echo "0")
if [ "$NPM_HIGH" = "0" ]; then
  check "WARNUNG" "npm audit: keine high/critical" "PASS" ""
else
  check "WARNUNG" "npm audit" "FAIL" "${NPM_HIGH} high/critical Findings"
fi

# -------------------------------------------
# EDGE FUNCTIONS
# -------------------------------------------
REPORT+="\n## Edge Functions\n\n"

# Webhook Functions ohne Signaturprüfung
WH_NO_SIG=$(ssh deploy@${PROD_HOST} "for dir in /opt/supabase/volumes/functions/*-webhook/; do
  [ -d \"\$dir\" ] || continue
  name=\$(basename \"\$dir\")
  if ! grep -qE 'signature|verify|hmac|crypto' \"\$dir/index.ts\" 2>/dev/null; then
    echo \"\$name\"
  fi
done" 2>/dev/null || true)
if [ -z "$WH_NO_SIG" ]; then
  check "KRITISCH" "Alle Webhooks prüfen Signaturen" "PASS" ""
else
  check "KRITISCH" "Webhooks ohne Signaturprüfung" "FAIL" "$WH_NO_SIG"
fi

# Hardcoded Secrets
FN_SECRETS=$(ssh deploy@${PROD_HOST} "grep -rn 'sk_live\|sk_test\|whsec_\|Bearer ey' \
  /opt/supabase/volumes/functions/ --include='*.ts' 2>/dev/null" || true)
if [ -z "$FN_SECRETS" ]; then
  check "KRITISCH" "Keine hardcoded Secrets in Functions" "PASS" ""
else
  check "KRITISCH" "Hardcoded Secrets in Functions" "FAIL" "$FN_SECRETS"
fi

# -------------------------------------------
# TRIGGER.DEV
# -------------------------------------------
REPORT+="\n## Trigger.dev\n\n"

# Tasks ohne maxDuration
TD_NO_DUR=$(ssh deploy@${PROD_HOST} "cd /opt/app && for file in trigger/tasks/*.ts 2>/dev/null; do
  [ -f \"\$file\" ] || continue
  name=\$(basename \"\$file\" .ts)
  if ! grep -q 'maxDuration' \"\$file\"; then echo \"\$name\"; fi
done" 2>/dev/null || true)
if [ -z "$TD_NO_DUR" ]; then
  check "WARNUNG" "Alle Tasks haben maxDuration" "PASS" ""
else
  check "WARNUNG" "Tasks ohne maxDuration" "FAIL" "$TD_NO_DUR"
fi

# Tasks ohne Concurrency
TD_NO_CC=$(ssh deploy@${PROD_HOST} "cd /opt/app && for file in trigger/tasks/*.ts 2>/dev/null; do
  [ -f \"\$file\" ] || continue
  name=\$(basename \"\$file\" .ts)
  if ! grep -qE 'concurrencyLimit|queue:' \"\$file\"; then echo \"\$name\"; fi
done" 2>/dev/null || true)
if [ -z "$TD_NO_CC" ]; then
  check "WARNUNG" "Alle Tasks haben Concurrency Limit" "PASS" ""
else
  check "WARNUNG" "Tasks ohne Concurrency" "FAIL" "$TD_NO_CC"
fi

# Hardcoded Secrets in Tasks
TD_SECRETS=$(ssh deploy@${PROD_HOST} "grep -rn 'sk_live\|sk_test\|SG\.\|sk-' \
  /opt/app/trigger/ --include='*.ts' 2>/dev/null" || true)
if [ -z "$TD_SECRETS" ]; then
  check "KRITISCH" "Keine hardcoded Secrets in Tasks" "PASS" ""
else
  check "KRITISCH" "Hardcoded Secrets in Tasks" "FAIL" "$TD_SECRETS"
fi

# Trigger.dev Dashboard nicht extern
TD_DASH=$(curl -s -o /dev/null -w "%{http_code}" --connect-timeout 3 "https://${EXTERNAL_HOST}:3040" 2>/dev/null || echo "000")
if [ "$TD_DASH" = "000" ]; then
  check "KRITISCH" "Trigger.dev Dashboard nicht extern" "PASS" ""
else
  check "KRITISCH" "Trigger.dev Dashboard nicht extern" "FAIL" "Status: $TD_DASH"
fi

# -------------------------------------------
# COMPLIANCE
# -------------------------------------------
REPORT+="\n## Compliance\n\n"

# Git: keine Secrets im Repo
GIT_SECRETS=$(ssh deploy@${PROD_HOST} "cd /opt/app && git ls-files .env .env.functions .env.trigger 2>/dev/null" || true)
if [ -z "$GIT_SECRETS" ]; then
  check "KRITISCH" ".env Dateien nicht im Git" "PASS" ""
else
  check "KRITISCH" ".env Dateien im Git" "FAIL" "Committed: $GIT_SECRETS"
fi

# Git: keine uncommitted Changes auf dem Server
GIT_DIRTY=$(ssh deploy@${PROD_HOST} "cd /opt/app && git status --porcelain 2>/dev/null" || true)
if [ -z "$GIT_DIRTY" ]; then
  check "WARNUNG" "Keine manuellen Änderungen auf Server" "PASS" ""
else
  check "WARNUNG" "Manuelle Änderungen auf Server" "FAIL" "$(echo "$GIT_DIRTY" | wc -l) Dateien"
fi

# -------------------------------------------
# ZUSAMMENFASSUNG
# -------------------------------------------

SUMMARY="\n## Zusammenfassung\n\n"
SUMMARY+="Bestanden: ${PASS}\n"
SUMMARY+="Warnungen: ${WARNING}\n"
SUMMARY+="Kritisch:  ${CRITICAL}\n"

TOTAL_REPORT="${SUMMARY}\n${REPORT}"

# Report speichern
REPORT_FILE="/opt/audit/reports/baseline-$(date +%Y-%m-%d).md"
echo -e "# Security Baseline Check $(date +%Y-%m-%d)\n${TOTAL_REPORT}" > "$REPORT_FILE"

echo -e "$TOTAL_REPORT"

# Alert bei kritischen Findings
if [ "$CRITICAL" -gt 0 ]; then
  echo ""
  echo "!!! ${CRITICAL} KRITISCHE FINDINGS !!!"
  echo -e "$TOTAL_REPORT" | mail -s "KRITISCH: Baseline Check $(date)" ops@example.com
  exit 1
fi

exit 0
```

## Integration mit Claude Code (Artikel 5)

Das Baseline-Check-Script liefert Fakten. Claude Code interpretiert sie. Der wöchentliche Audit aus [Artikel 5](/de/magazin/claude-code-security-devops/) nutzt den Baseline-Report als Input:

```bash
# Im Gesamt-Audit-Script (scripts/full-security-audit.sh aus Artikel 5)
# Nach den deterministischen Checks:

# Baseline-Report des heutigen Tages einlesen
BASELINE_REPORT=$(cat /opt/audit/reports/baseline-$(date +%Y-%m-%d).md 2>/dev/null || echo "Kein Baseline-Report vorhanden")

# An Claude Code übergeben
echo "$BASELINE_REPORT" | claude -p \
  "Du erhältst den Baseline-Check-Report unseres self-hosted Stacks.
Die Baseline ist definiert in security-baseline.yml.

Analysiere:
1. Welche KRITISCHEN Findings brauchen sofortige Aufmerksamkeit?
2. Gibt es Muster in den WARNUNGEN die auf systematische Probleme hindeuten?
3. Haben sich Findings gegenüber der Vorwoche verändert? (Vergleiche mit letztem Report)
4. Welche Prioritäten empfiehlst du für diese Woche?

Antworte auf Deutsch. Sei konkret." \
  --allowedTools "Read,Grep,Glob" \
  --output-format text \
  --max-turns 5
```

## Die Baseline pflegen

Die `security-baseline.yml` ist kein statisches Dokument. Sie entwickelt sich mit dem Stack.

**Wann aktualisieren:**

```
Neue Tabelle in Supabase           -> rls.exceptions prüfen
Neuer Service im Docker Stack      -> internal_only_ports erweitern
Neues NEXT_PUBLIC Env Var          -> allowed_public erweitern
Neues Secret                       -> required Secrets erweitern
Neue Edge Function                 -> Prüfregeln gelten automatisch
Neuer Trigger.dev Task             -> Prüfregeln gelten automatisch
Hoster-Wechsel                     -> server/provider anpassen
```

**Workflow für Baseline-Änderungen:**

```
1. Änderung in security-baseline.yml im Git
2. PR Review (inkl. Begründung warum die Regel sich ändert)
3. Claude Code prüft den Diff der Baseline selbst:
   "Ist diese Lockerung der Regeln gerechtfertigt?"
4. Merge nach Approval
5. Nächster Baseline-Check nutzt die neuen Regeln
```

## Cron-Konfiguration

```bash
# crontab auf dem audit-runner

# Täglicher Baseline-Check (06:00 Uhr)
0 6 * * * /opt/audit/scripts/check-baseline.sh >> /var/log/baseline-check.log 2>&1

# Wöchentlicher Claude Code Audit (Sonntag 07:00 Uhr, nach dem Baseline-Check)
0 7 * * 0 /opt/audit/scripts/full-security-audit.sh >> /var/log/security-audit.log 2>&1
```

## Deployment-Checkliste

```
Baseline-Datei
  [ ] security-baseline.yml im Repo vorhanden
  [ ] Alle Server-IPs und Hostnames aktuell
  [ ] Alle erwarteten Secrets gelistet (ohne Werte)
  [ ] Alle erlaubten NEXT_PUBLIC Variablen gelistet
  [ ] Alle service_role-erlaubten Dateien gelistet
  [ ] RLS Exceptions dokumentiert (mit Begründung)
  [ ] Compliance-Regeln (CLOUD Act, Data Residency) definiert

Check-Script
  [ ] check-baseline.sh auf audit-runner ausführbar
  [ ] SSH Key vom audit-runner zum prod-Server eingerichtet
  [ ] Firewall-Baseline gespeichert (/opt/baselines/)
  [ ] Täglicher Cron Job aktiv
  [ ] Alert-Versand konfiguriert (E-Mail bei KRITISCH)

Integration
  [ ] Claude Code auf audit-runner installiert
  [ ] Wöchentlicher Audit-Cron aktiv
  [ ] CLAUDE.md im Repo vorhanden (Artikel 5)
  [ ] .claude/commands/security-review.md vorhanden (Artikel 5)
  [ ] Reports werden archiviert (/opt/audit/reports/)
```

## Fazit

Die Security Baseline ist das verbindende Element der gesamten Runbook-Serie. Die Artikel 1-4 definieren, was sicher konfiguriert sein muss. Artikel 5 definiert, wie Claude Code diese Regeln prüft. Artikel 6 führt alles in einer einzigen YAML-Datei zusammen, die sowohl von Scripts als auch von Claude Code gelesen werden kann.

Der tägliche Baseline-Check liefert Fakten: bestanden oder nicht bestanden. Der wöchentliche Claude Code Audit interpretiert diese Fakten im Kontext. Ein Mensch entscheidet, was priorisiert wird. Dieses Dreischicht-Modell deckt sowohl bekannte als auch unerwartete Risiken ab, ohne dass eine einzelne Schicht allein für die Sicherheit verantwortlich ist.

Wer diese Baseline zusammen mit einer [Cert-Ready-by-Design-Architektur](/de/magazin/cert-ready-by-design/) verfolgt, baut prüfbare Sicherheit statt nachträglicher Audits.

Damit ist die **DevOps-Runbook-Serie vollständig**.

<div class="not-prose my-12 border border-gosign-border bg-gosign-light rounded-card p-6 lg:p-8">
<div class="flex items-start gap-4">
<div class="flex-shrink-0 w-12 h-12 bg-gosign-dark rounded-card flex items-center justify-center">
<svg width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="white" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 15v4a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2v-4"/><polyline points="7 10 12 15 17 10"/><line x1="12" y1="15" x2="12" y2="3"/></svg>
</div>
<div>
<h2 class="text-h3 font-bold text-gosign-dark mb-2" id="audit-checklisten-der-serie">Audit-Checklisten der Serie</h2>
<p class="text-body text-gosign-text mb-4">Vorbereitete Prompts für Claude Code. Jede Checkliste prüft automatisch die Sicherheitspunkte des jeweiligen Runbooks und meldet BESTANDEN, WARNUNG oder KRITISCH.</p>
<div class="flex flex-wrap gap-3">
<a href="/downloads/claude-check-artikel-1-supabase.md" download class="inline-flex items-center px-4 py-2 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-sm">Supabase Infrastructure</a>
<a href="/downloads/claude-check-artikel-2-nextjs.md" download class="inline-flex items-center px-4 py-2 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-sm">Next.js Security</a>
<a href="/downloads/claude-check-artikel-3-edge-functions.md" download class="inline-flex items-center px-4 py-2 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-sm">Edge Functions</a>
<a href="/downloads/claude-check-artikel-4-trigger-dev.md" download class="inline-flex items-center px-4 py-2 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-sm">Trigger.dev</a>
</div>
</div>
</div>
</div>

## Serien-Inhaltsverzeichnis

1. [Supabase Self-Hosting Runbook](/de/magazin/supabase-self-hosting/)
2. [Next.js über Supabase sicher betreiben](/de/magazin/nextjs-supabase-sicher-betreiben/)
3. [Supabase Edge Functions sicher einsetzen](/de/magazin/supabase-edge-functions-sicher/)
4. [Trigger.dev Background Jobs sicher betreiben](/de/magazin/trigger-dev-background-jobs/)
5. [Claude Code als Sicherheitskontrolle im DevOps-Workflow](/de/magazin/claude-code-security-devops/)
6. [Security Baseline für den gesamten Stack](/de/magazin/security-baseline-stack/) - dieser Artikel

--- Selbstgehostete Open-Source-KI 2026 ---
> Self-Hosting offener LLMs 2026 im Enterprise-Stack: Mistral, gpt-oss, DeepSeek, Llama 4. Hardware-Floor, TCO, EU-GPU-Hosting, Entscheidungs-Matrix.

Der Modellmarkt hat dem EU-Enterprise-Procurement eine Wahl gegeben, die es so noch nie hatte. Open-Weight-Modelle erreichen proprietäre Modelle bei den meisten Enterprise-Workloads. Drei Frontier-Class-Open-Source-Modelle sind 2025 unter Apache 2.0 erschienen. Deutsche und französische GPU-Hosting-Anbieter liefern H100-Kapazität zu kalkulierbaren Stundensätzen. Schrems II in Kombination mit dem US CLOUD Act hat Self-Hosting zur einzigen Architektur mit Null-Exposition gegenüber Fremdanbietern gemacht.

Und trotzdem behandelt das Procurement-Gespräch "self-hosted Open-Source-KI" noch immer als ein Produkt. Es ist keines. Es ist eine Stack-Entscheidung mit vier glaubhaften Modellen, drei Deployment-Mustern und einer echten Total-Cost-of-Ownership-Rechnung. Dieser Artikel ist die ausführliche Begleitung zu [Wann Mistral, wann Claude Opus? Decision Routing für agentische EU-Enterprise 2026](/de/magazin/ki-modelle-vergleich-2026/) - wenn Sie sich für Self-Hosting entschieden haben, zeigt dieser Text wie die Modellauswahl konkret aussieht.

<div class="not-prose my-12 border border-gosign-border bg-gosign-light rounded-card p-6 lg:p-8">
<p class="text-h3 font-bold text-gosign-dark mb-3">Auf einen Blick - Self-hosted Open-Source-KI für EU-Enterprise 2026</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Fünf glaubhafte self-hostbare Modelle 2026: Mistral Small 3.2 (Apache 2.0, 24B, Consumer-GPU), gpt-oss-120b (Apache 2.0, MoE, einzelne H100), DeepSeek V4-Flash (MIT, 284B/13B Aktiv-MoE, April-2026-Preview), DeepSeek V4-Pro (MIT, 1,6T/49B aktiv, Preview, Cluster-Hardware), Llama 4 Scout (Meta License, 10M Kontext).</li>
<li>Mistral Small 3.2 gewinnt den Arbeitspferd-Slot, weil es auf Consumer-Hardware läuft (einzelne RTX 4090), multilingual trainiert wurde und native Vision für Dokumenten-Workloads mitbringt.</li>
<li>DeepSeek V4-Pro (Preview, 24. April 2026) nähert sich Frontier-Closed-Source-Leistung unter MIT-Lizenz, braucht aber Multi-GPU-Cluster. Realistisches Self-Hosting beginnt für die meisten Unternehmen mit V4-Flash.</li>
<li>EU-GPU-Hosting ist nicht mehr der Engpass: Hetzner liefert dedizierte RTX-Server, IONOS und T-Systems bedienen BaFin-regulierte Workloads, Scaleway bietet H100 SXM zu ~3,50 EUR/h, OVHcloud hat einen Sovereign-Tier.</li>
<li>TCO-Crossover Cloud-API zu Self-Hosting: typischerweise um 50 bis 100 Millionen Token pro Monat im Dauerbetrieb. Darunter schlägt EU-Cloud-API. Darüber amortisiert sich dedizierte Hardware in 12 bis 18 Monaten.</li>
<li>Die Architektur ist Multi-Modell, nicht Einzel-Modell: Mistral Small fürs Volumen, gpt-oss-120b oder DeepSeek V4-Flash für On-Prem-Heavy-Reasoning, V4-Pro oder R1 als Math/Logik-Spezialisten, Llama 4 Scout für Ultra-Long-Context. Das Routing entscheidet, welches Modell welche Entscheidung übernimmt.</li>
</ul>
</div>

## Sie haben sich für Self-Hosting entschieden - die Modellfrage beginnt hier

Die Entscheidung für einen self-hosted LLM-Stack ist selten eine Modellentscheidung. Sie ist eine Compliance-Entscheidung: Daten oberhalb einer bestimmten Klassifikationsstufe dürfen das Unternehmensnetz nicht verlassen. Sie ist eine Architektur-Entscheidung: Der Inferenz-Layer muss eine kontrollierte Abhängigkeit sein, keine externe API. Sie ist eine Procurement-Entscheidung: Capex auf Hardware versus Opex auf gehostete GPU-Instanzen.

Sobald diese Entscheidung gefallen ist, öffnet sich die Modellfrage. Welches Open-Source-Modell auf welchem Hardware-Floor für welchen Workload-Mix? Fünf Modelle haben für Q2 2026 glaubhafte Produktionsreife: Mistral Small 3.2, gpt-oss-120b, DeepSeek V4-Flash, DeepSeek V4-Pro (Preview) und Llama 4 Scout. DeepSeek R1 vom Januar 2025 ist weiterhin einsetzbar, wird aber für Neudeployments durch die V4-Linie weitgehend abgelöst. Jedes Modell hat eine andere Kosten-Qualitäts-Kurve und ein anderes Betriebsprofil.

Dieser Artikel überspringt die Bestenlisten-Diskussion. Die Benchmark-Werte konvergieren so weit, dass Workload-Fit wichtiger ist als nominale MMLU- oder HumanEval-Punkte. Die Frage lautet: Welches Modell überlebt 18 Monate in Ihrem Stack, welches verdient seine Hardware, und welche Kombination produziert den Audit-Trail, den der EU AI Act verlangt.

## Die glaubhaften self-hosted Modelle im Direktvergleich

| Modell | Parameter / Architektur | Lizenz | Hardware (CAPEX einmalig / OPEX gehostet) | Schlüssel-Stärke | Schlüssel-Schwäche |
|---|---|---|---|---|---|
| Mistral Small 3.2 | 24B dense, GQA (32Q/8KV) | Apache 2.0 | ~55 GB VRAM. **CAPEX:** 1x RTX 4090 ~1.500 EUR (Pilot, 4-Bit-Quant) oder 1x H100 80GB ~30.000 EUR (Produktion). **OPEX:** ~1.500-2.500 EUR/Monat auf Scaleway/OVHcloud | Multilingual, Vision, schnell (~150 Token/s auf Consumer-GPU), volumenfreundlich | Kein Top-Tier-Reasoning |
| gpt-oss-120b | 117B total / 5,1B aktiv (MoE) | Apache 2.0 | 1x H100/A100 80GB. **CAPEX:** ~30.000 EUR. **OPEX:** ~1.200-2.500 EUR/Monat gehostet | Reasoning auf o4-mini-Niveau, MoE-effiziente Inferenz | Keine Vision, ausschließlich Datacenter-Hardware |
| DeepSeek V4-Flash *(Preview, Apr 2026)* | 284B total / 13B aktiv (MoE), 1M Kontext | MIT | 1-2x H100/A100 80GB mit Quant, 4x H100 volle Präzision. **CAPEX:** ~30.000-120.000 EUR. **OPEX:** ~1.500-5.000 EUR/Monat gehostet | Frontier-Reasoning bei moderaten Hardware-Kosten, nativ multimodal, agent-optimiert | Preview-Status - Benchmarks vor Produktion neu prüfen |
| DeepSeek V4-Pro *(Preview, Apr 2026)* | 1,6T total / 49B aktiv (MoE), 1M Kontext | MIT (open-source auf Hugging Face) | 8x H100 Cluster minimum. **CAPEX:** ~240.000 EUR. **OPEX:** ~10.000-12.000 EUR/Monat gehostet. **Für DAX-Konzern und gehobenen Mittelstand: machbar. Für KMU unter 500 Mitarbeitenden: API/hosted-Variante (Together.ai, Fireworks, DeepSeek API) realistischer** | Nähert sich GPT-5.5 und Gemini 3.1 Pro unter offener Lizenz, agent-tool-optimiert (Claude Code, OpenClaw) | Preview-Status; für KMU schiebt der Hardware-Floor in den API-Pfad |
| DeepSeek R1 *(Jan 2025, reif)* | 671B total / 37B aktiv (MoE) | MIT | 4-8x H100 minimum. **CAPEX:** ~120.000-240.000 EUR. **OPEX:** ~5.000-10.000 EUR/Monat gehostet | Reifer Math/Logik-Spezialist, breite Framework-Unterstützung | Für Neudeployments durch V4-Flash weitgehend abgelöst |
| Llama 4 Scout | 17B aktiv (MoE) | Meta Llama Community License | 1x GPU. **CAPEX:** ~30.000 EUR. **OPEX:** ~1.500 EUR/Monat gehostet | 10-Millionen-Token-Kontextfenster | Lizenz-Schranke ab 700M MAU; Lizenzprüfung nötig |

Drei Klarstellungen sind wichtig.

**Mistral Small 3.2 Hardware-Floor.** Die offizielle Mistral-Angabe nennt rund 55 GB GPU-RAM für bf16/fp16-Inferenz - das landet im Produktivbetrieb auf einer H100 oder A100 80GB. Mit 4-Bit-Quantisierung (GPTQ, AWQ) läuft das Modell auf einer einzelnen 24-GB-RTX-4090 bei leichtem Qualitätsabschlag. Für Pilot-Deployments oder Single-Tenant-Inferenz ist der RTX-4090-Weg real. Für Multi-Tenant-Produktion mit parallelen Requests ist der H100-Weg die korrekte Dimensionierung.

**DeepSeek-V4-Preview-Status.** DeepSeek-V4-Pro und V4-Flash sind am 24. April 2026 als Preview unter MIT-Lizenz erschienen, beide mit 1-Millionen-Token-Kontextfenster via neuer Hybrid-Attention-Architektur (Compressed Sparse Attention + Heavily Compressed Attention). Im 1M-Token-Kontext-Setting benötigt V4-Pro laut Anbieter nur 27 % der Single-Token-Inferenz-FLOPs und 10 % des KV-Cache gegenüber V3.2 - signifikante Effizienzgewinne für Long-Context-Workloads. Beide Varianten sind für Agent-Tooling optimiert (Integration mit Claude Code, OpenClaw). Aber: Preview heißt, dass die Benchmark-Werte unabhängig im Scale noch nicht verifiziert sind. Für Produktionsentscheidungen in regulierten Branchen sollten Sie auf die GA-Freigabe warten oder eigene repräsentative Benchmarks fahren, bevor Sie sich festlegen.

**DeepSeek-Herkunft für BaFin-regulierte Institute.** DeepSeek wird in China entwickelt - das Modell läuft self-hosted unter MIT-Lizenz, das Trainings-Korpus bleibt aber chinesisch. BaFin-Merkblatt KI 2024 verlangt zusätzliche Risikobewertung nach MaRisk AT 4.3 bei Modellen aus Jurisdiktionen mit unzureichenden Rechtsstandards. Für Banken und Versicherer gehört dieser Prüfschritt vor jeden Produktiveinsatz, unabhängig davon, dass die Gewichte unter offener Lizenz vorliegen.

**Lizenzprüfung für Llama 4 Scout.** Die Meta Llama Community License erlaubt kommerzielle Nutzung, enthält aber zwei Einschränkungen, die das Procurement prüfen sollte: eine 700-Millionen-MAU-Schwelle, oberhalb derer eine gesonderte Meta-Lizenz nötig ist, und eine Einschränkung der Nutzung von Modell-Outputs zum Training konkurrierender Modelle. Für die meisten Unternehmen sind beide irrelevant - aber der Procurement-Vermerk gehört explizit dokumentiert.

## TCO: Wann schlägt Self-Hosting die Cloud-API?

Die Ökonomie kippt bei einer Token-Volumen-Schwelle. Darunter gewinnen gehostete APIs, weil Hardware-Leerlauf dominiert. Darüber gewinnen dedizierte GPUs, weil die marginale Token-Last sich der Stromrechnung plus Abschreibung annähert.

Eine Beispielrechnung für Mistral Small 3.2 im EU-Hosting:

| Kostenposition | Wert (EU-Hosting) |
|---|---|
| H100 80GB Instanz, EU-Provider (Scaleway-Klasse) | ~2.500 EUR/Monat dediziert oder ~3,50 EUR/h on-demand |
| Mistral Small 3.2 Durchsatz (einzelne H100) | ~150 Token/s im Dauerbetrieb, ~390M Token/Monat bei 100 % Auslastung |
| Effektive Kosten pro 1M Token bei 60 % Auslastung | ~10-12 EUR pro 1M Token |
| Mistral La Plateforme API (Mistral Small via API) | ~0,40 USD pro 1M Input-Token; volumenabhängig |
| Claude Sonnet 4.6 API-Äquivalent | ~3 USD pro 1M Input-Token; ~15 USD Output |
| Claude Opus 4.7 API-Äquivalent | ~5 USD pro 1M Input-Token; ~25 USD Output |

Der Crossover für Mistral Small liegt zwischen 50 und 100 Millionen Token pro Monat im Dauerbetrieb, abhängig davon ob der Workload Input- oder Output-lastig ist. Eine 24/7-Enterprise-Pipeline mit fünf bis zehn Worker-Knoten überschreitet diese Schwelle typischerweise im ersten Quartal.

Für gpt-oss-120b sieht die Rechnung ähnlich aus, beginnt aber höher: Eine einzelne H100 unterstützt geringeren Durchsatz als Mistral Small bei gleichen Hardware-Kosten - die Token-Amortisation liegt damit etwa beim Doppelten. Der Crossover gegenüber Claude Opus 4.7 liegt bei rund 30 bis 50 Millionen Token pro Monat - genau in dem Bereich, in dem Heavy-Reasoning-Workloads in Enterprise-KI-Systemen landen.

Eine Klarstellung zu DeepSeek V4-Pro: Die Gewichte sind open-source unter MIT-Lizenz und auf Hugging Face verfügbar - das Modell ist vollständig self-hostbar. Die Frage ist die Unternehmensgröße, nicht die Lizenz. Die 1,6T/49B-Aktiv-Architektur von V4-Pro benötigt einen 8x-H100-Cluster (~240.000 EUR CAPEX oder ~10.000-12.000 EUR/Monat gehostet). **Für DAX-Konzerne und gehobenen Mittelstand (typischerweise ab 2.500 Mitarbeitenden mit etablierten KI-Infrastruktur-Budgets) passen diese Zahlen in eine Standard-IT-Capex-Position.** Für KMU unter 500 Mitarbeitenden schieben die gleichen Zahlen den realistischen Weg zum API-Zugang (DeepSeek API direkt) oder einer Hosted-Variante (Together.ai, Fireworks) mit Pro-Token-Ökonomie. V4-Flash (284B/13B aktiv) liegt dazwischen: 1-4x H100 Footprint (30.000-120.000 EUR CAPEX), ab Tag eins realistisch für gehobenen Mittelstand. Self-hosted TCO für V4-Flash rechnet sich, wenn Frontier-Reasoning ein Dauer-Workload bei souveränitäts-kritischer Datenklassifikation ist; bei gelegentlichem Reasoning ist die V4-Flash-API oder Mistral La Plateforme günstiger.

Diese Zahlen basieren auf öffentlichen EU-Hosting-Preisen von Scaleway und OVHcloud sowie auf öffentlichen Durchsatz-Daten der Modelle. Sie sind illustrativ, nicht vertraglich.

<figure class="not-prose my-12">
<svg viewBox="0 0 800 480" xmlns="http://www.w3.org/2000/svg" role="img" aria-labelledby="tco-title-de tco-desc-de" class="w-full h-auto max-w-3xl mx-auto">
<title id="tco-title-de">TCO-Crossover: self-hosted vs Cloud-API nach monatlichem Token-Volumen (Mai 2026)</title>
<desc id="tco-desc-de">Kostenvergleich mit monatlichen USD-Ausgaben auf der Y-Achse (log-Skala 100 bis 100.000 USD) gegen monatliches Token-Volumen auf der X-Achse (log-Skala 1M bis 10B Tokens pro Monat). Vier Kostenkurven sind eingezeichnet: Claude Opus 4.7 API bei 15 USD pro 1M Tokens (linear), Mistral La Plateforme API bei 0,40 USD pro 1M Tokens (linear), Mistral Small 3.2 self-hosted auf einer einzelnen H100 bei ~2.700 USD/Monat flat plus marginale Stromkosten, gpt-oss-120b self-hosted auf einer einzelnen H100 bei ~3.200 USD/Monat flat. Crossover-Punkte: Mistral Small 3.2 self-hosted schlägt Claude Opus 4.7 API bei rund 180 Millionen Tokens pro Monat. Unter 50M Tokens/Monat dominiert die Cloud-API-Ökonomie. Über 500M Tokens/Monat dominiert self-hosted unabhängig vom Modell.</desc>
<defs>
<style>
.axis-line-de { stroke: #1a2e4d; stroke-width: 1.5; }
.grid-line-de { stroke: #d4d0cb; stroke-width: 0.5; stroke-dasharray: 2 3; }
.axis-label-de { font-family: -apple-system, system-ui, sans-serif; font-size: 11px; fill: #4a5568; }
.title-text-de { font-family: -apple-system, system-ui, sans-serif; font-size: 13px; fill: #1a2e4d; font-weight: 700; }
.legend-text-de { font-family: -apple-system, system-ui, sans-serif; font-size: 11px; fill: #1a2e4d; font-weight: 500; }
.annotation-de { font-family: -apple-system, system-ui, sans-serif; font-size: 10px; fill: #1a2e4d; font-style: italic; }
.crossover-marker-de { fill: #fcd34d; stroke: #b8941f; stroke-width: 1.5; }
</style>
</defs>
<text x="400" y="25" class="title-text-de" text-anchor="middle">Monatliche Kosten (USD, log-Skala)</text>
<line x1="80" y1="380" x2="740" y2="380" class="grid-line-de"/>
<line x1="80" y1="300" x2="740" y2="300" class="grid-line-de"/>
<line x1="80" y1="220" x2="740" y2="220" class="grid-line-de"/>
<line x1="80" y1="140" x2="740" y2="140" class="grid-line-de"/>
<line x1="80" y1="60" x2="740" y2="60" class="grid-line-de"/>
<line x1="212" y1="60" x2="212" y2="380" class="grid-line-de"/>
<line x1="344" y1="60" x2="344" y2="380" class="grid-line-de"/>
<line x1="476" y1="60" x2="476" y2="380" class="grid-line-de"/>
<line x1="608" y1="60" x2="608" y2="380" class="grid-line-de"/>
<text x="72" y="384" class="axis-label-de" text-anchor="end">$100</text>
<text x="72" y="304" class="axis-label-de" text-anchor="end">$1.000</text>
<text x="72" y="224" class="axis-label-de" text-anchor="end">$10.000</text>
<text x="72" y="144" class="axis-label-de" text-anchor="end">$100.000</text>
<text x="72" y="64" class="axis-label-de" text-anchor="end">$1.000.000</text>
<text x="80" y="400" class="axis-label-de" text-anchor="middle">1M</text>
<text x="212" y="400" class="axis-label-de" text-anchor="middle">10M</text>
<text x="344" y="400" class="axis-label-de" text-anchor="middle">100M</text>
<text x="476" y="400" class="axis-label-de" text-anchor="middle">1B</text>
<text x="608" y="400" class="axis-label-de" text-anchor="middle">10B</text>
<text x="400" y="420" class="title-text-de" text-anchor="middle">Monatliches Token-Volumen (log-Skala)</text>
<line x1="80" y1="60" x2="80" y2="380" class="axis-line-de"/>
<line x1="80" y1="380" x2="740" y2="380" class="axis-line-de"/>
<polyline points="80,420 212,366 344,286 476,206 608,126" fill="none" stroke="#b8941f" stroke-width="2.5"/>
<text x="615" y="120" class="legend-text-de" fill="#b8941f">Claude Opus 4.7 API</text>
<text x="615" y="132" class="annotation-de" fill="#b8941f">$15 pro 1M Tokens</text>
<polyline points="80,572 212,508 344,412 476,332 608,252" fill="none" stroke="#3a6090" stroke-width="2.5" stroke-dasharray="4 3"/>
<text x="615" y="246" class="legend-text-de" fill="#3a6090">Mistral La Plateforme API</text>
<text x="615" y="258" class="annotation-de" fill="#3a6090">$0,40 pro 1M Tokens</text>
<polyline points="80,266 740,266" fill="none" stroke="#1a2e4d" stroke-width="2.5"/>
<text x="86" y="258" class="legend-text-de" fill="#1a2e4d">Mistral Small 3.2 self-host (~$2.700/Mo. flat)</text>
<polyline points="80,256 740,256" fill="none" stroke="#5a8a5a" stroke-width="2.5" stroke-dasharray="6 4"/>
<text x="86" y="248" class="legend-text-de" fill="#5a8a5a">gpt-oss-120b self-host (~$3.200/Mo. flat)</text>
<circle cx="377" cy="266" r="6" class="crossover-marker-de"/>
<text x="377" y="248" class="annotation-de" text-anchor="middle">Crossover ~180M Tok/Mo.</text>
<text x="377" y="284" class="annotation-de" text-anchor="middle">Mistral OSS vs Opus API</text>
<text x="400" y="455" class="annotation-de" text-anchor="middle">Hosting: EU-GPU-Anbieter (Scaleway, OVHcloud) - Werte illustrativ, nicht vertraglich</text>
</svg>
<figcaption class="text-sm text-gosign-text-light text-center mt-4 max-w-2xl mx-auto">
<strong>TCO-Crossover: self-hosted vs Cloud-API</strong> - lineare Cloud-API-Kurven (Pro-Token-Pricing) gegen flache Self-host-Kurven (CAPEX amortisiert). Mistral La Plateforme API bleibt unter ~10B Tokens/Monat günstigste Option - die relevante Entscheidung ist Mistral OSS self-host vs Claude Opus 4.7 API, die für souveränitätskritische Workloads bei ca. 180 Millionen Tokens pro Monat kreuzt. Unter 50M Tokens/Monat dominiert die Cloud-API-Ökonomie. Über 500M Tokens/Monat dominiert self-host unabhängig vom Modell.
</figcaption>
</figure>

## EU-GPU-Hosting 2026: Wer hat tatsächlich H100-Kapazität?

Der EU-GPU-Hosting-Markt ist 2025-2026 deutlich gereift. Fünf Anbieter decken die meisten Enterprise-Self-Hosting-Cases ab - und der deutsche Markt steht für regulierte Branchen im Vordergrund:

**Hetzner** (Deutschland). Kostenführer für dedizierte GPU-Server, keine On-Demand-Instanzen. Aktuelle GPU-Optionen umfassen RTX 4000 SFF Ada und RTX 6000 Ada gepaart mit modernen CPUs. Der Weg für Mistral Small 3.2 mit Quantisierung oder für Entwicklungsumgebungen. Weniger geeignet für elastische Spitzenlast. Kosteneffizient für nicht-regulierte Branchen (Maschinenbau, Industriegüter). NICHT geeignet als BaFin-Pilot - es fehlt das BSI C5 Type 2 Testat und ein MaRisk-AT-9-konformer AVV. Für Banken/Versicherungen ab Tag 1 IONOS oder T-Systems mit C5 Type 2.

**IONOS** (Deutschland). Souveränitäts-Cloud-Hosting mit GPU-Instanzen. Der Compliance-Fit für BaFin-regulierte Workloads aus Finanzdienstleistung und Versicherung.

**T-Systems** (Deutschland). Tochter der Deutschen Telekom. Souveränitäts-Cloud explizit für öffentlichen Sektor und kritische Infrastruktur ausgelegt. Die procurement-bequeme Wahl, wenn vorstandsseitige Souveränität die Anforderung ist.

**Scaleway** (Frankreich, DSGVO-nativ). Aggressivster Anbieter bei Preis-Leistung für KI-Workloads. H100 SXM zu ~3,50 EUR/h, A100 zu ~2,50 EUR/h, dazu die neue NVIDIA-Blackwell-B300-SXM-Klasse (288 GB VRAM) für Frontier-Workloads. Französische Rechenzentren, vollständig DSGVO-konform, keine CLOUD-Act-Exposition. Reservierte Instanz-Kontrakte für planbare Workloads.

**OVHcloud** (Frankreich, Sovereign Tier). Größter europäischer Cloud-Anbieter mit "Sovereign Cloud"-Tier, der explizit für Behörden und regulierte Branchen gebaut ist. Portfolio mit H100, RTX 5000, A10, dazu ein "AI Deploy"-Service für Pay-as-you-go-Inferenz. Guter Fit, wenn das Procurement einen Sovereign-Cloud-Stempel braucht.

Für eine Enterprise, die sich auf einen self-hosted Stack festlegt, ist die praktische Reihenfolge: für nicht-regulierte Branchen Pilot auf Hetzner oder Scaleway für kosteneffiziente Validierung, Migration zu IONOS, T-Systems oder OVHcloud für die Produktion, wenn die Regulierung Souveränitäts-Zertifizierung verlangt. Für BaFin-regulierte Institute (Banken, Versicherer) führt der Pilot direkt auf IONOS oder T-Systems mit BSI C5 Type 2 - Hetzner scheidet aus. Reserved-Instance-Kontrakte zur Kostenplanung.

## Deployment-Muster: Single Worker, Cluster, Hybrid

Drei Deployment-Muster decken fast alle Enterprise-Self-Hosted-Szenarien ab.

**Single-Worker-Muster.** Ein Modell, eine GPU-Instanz, hinter einem Load Balancer mit Health Checks. Geeignet für: Mistral Small 3.2 auf einer RTX 4090 oder H100 für die 70-%-Volumen-Last. Llama 4 Scout auf einer einzelnen GPU für Long-Context-Dokumentenanalyse. Betriebskomplexität: niedrig. Ausfallmodus: Single Point of Failure, sofern nicht repliziert.

**Multi-Modell-Cluster-Muster.** Mehrere Modelle auf mehreren GPUs hinter einer Routing-Schicht. Geeignet für: Mistral Small fürs Volumen + gpt-oss-120b oder DeepSeek V4-Flash für Heavy-Reasoning + (optional) DeepSeek V4-Pro auf dediziertem Cluster für Math-Grade-Workloads, alle hinter einer einzelnen Routing-Schicht. Die Routing-Schicht entscheidet pro Request, welches Modell den Job übernimmt. Betriebskomplexität: mittel. Erfordert einen Model-Server (vLLM, TGI, llama.cpp-server) und eine Routing-Regel-Engine. Das typische Produktionsmuster für agentische Workloads mit gemischter Entscheidungskomplexität.

**Hybrid-Edge-Cloud-Muster.** Sensible Workloads (HR-Onboarding, Vertragsprüfung, Kundendaten-Extraktion) auf self-hosted Modellen; unkritische Workloads (Marketing-Texte, Wissens-Q&A auf öffentlichen Informationen) auf EU-Cloud-APIs wie Mistral La Plateforme. Die Routing-Schicht erzwingt die Datenklassifikation vor der Modellauswahl. Betriebskomplexität: hoch (zwei Stacks zu betreiben), aber die niedrigste Souveränitäts-Exposition und das beste Kosten-pro-Entscheidung-Verhältnis.

Die Musterwahl hängt von der Datenklassifikations-Taxonomie ab, nicht von der Modellauswahl. Wenn alles als "intern" oder höher klassifiziert ist, dominiert das Multi-Modell-Cluster-Muster. Wenn ein nennenswerter Anteil der Arbeit auf öffentlich-relevanten oder unsensiblen Daten läuft, ist das Hybrid-Muster günstiger.

## Entscheidungs-Matrix: Welches Modell für welchen Workload

| Workload-Kategorie | Empfohlenes Modell | Warum |
|---|---|---|
| Dokumenten-Klassifikation, strukturierte Extraktion, OCR-Feldverarbeitung | Mistral Small 3.2 (self-hosted) | Vision-fähig, schnell auf Consumer-GPU, multilinguale Abdeckung |
| Standard-Textgenerierung (E-Mails, Benachrichtigungen, NDA-Erinnerungen) | Mistral Small 3.2 (self-hosted) | Hoher Durchsatz, Template-freundlich, niedrigste Token-Kosten |
| Vertragsklauseln-Klassifikation, Lieferanten-Risikoflags, Anomalie-Detektion | Mistral Small 3.2 oder Mistral Medium 3.1 (La Plateforme) | Mittleres Reasoning zu moderaten Kosten, EU-souverän |
| Anti-Diskriminierungs-Prüfung nach AGG (Merkmale, Benachteiligungsverbot, Beweislastumkehr-Risiko, Schadensersatz bis 3 Brutto-Monatsgehälter), HR/Legal-Reasoning | gpt-oss-120b (on-prem) oder Claude Opus 4.7 (Cloud) | Tier-1-Reasoning, audit-fähige Begründungstiefe für HR/Legal |
| Code-Generierung, Code-Review (Cloud-Flaggschiffe) | Claude Opus 4.7 oder GPT-5.5 | Beide Benchmark-führend; Claude Opus 4.7 stärker bei langen agentischen Loops (Claude Code), GPT-5.5 stärker bei IDE-Integration (Cursor, Copilot) |
| Code-Generierung (self-hosted, souveränitätskritisch) | Qwen 3 Coder 110B (Apache 2.0, Alibaba), DeepSeek Coder V4 (MIT) oder Codestral Mamba 32B (Mistral, EU-built) | Tier-1-Coding-Benchmarks on-prem; Qwen 3 Coder führt HumanEval/SWE-Bench unter OSS, DeepSeek Coder V4 stärkster bei agentischen Multi-File-Tasks, Codestral Mamba niedrigste Latenz auf Consumer-GPU |
| Microsoft-365- / Copilot-Tiefenintegration | GPT-5.5 via Azure OpenAI | Native Stack, niedrigster Integrationsaufwand für Organisationen auf Microsoft-Daten-Plane |
| Agentische Workflows mit hohem Function-Calling- / Tool-Use-Anteil | GPT-5.5 oder Claude Opus 4.7 | Beide Top-Tier bei strukturierten Ausgaben und Tool-Orchestrierung; GPT-5.5 mit breiterem Ecosystem an vorgebauten Tools |
| Finanz-Risiko-Modellierung, Stress-Tests, Optimierung | DeepSeek V4-Flash (aktuell) oder V4-Pro via API; R1 für reife Deployments produktionsreif | Top-Tier-Math/Logik; V4-Linie mit 1M Kontext für Portfolio-Analyse |
| Dokumentenanalyse großer Korpora (komplette Vertragsportfolios, ganze Geschäftsberichte) | Llama 4 Scout | 10-Millionen-Token-Kontextfenster - in diesem Band einzigartig |
| Multimodal (Bild + Text korreliert, technische Zeichnungen, Video-Segmente) | Gemini 3.1 Pro (Cloud, kein self-hosted Äquivalent) | Natives multimodales Training, 1M Kontext |
| Conversational AI / kundenseitige Chatbots | Mistral Small 3.2 (self-hosted) für Volumen; GPT-5.5 (Azure) wenn MS-stack-nativ | Produktivqualität zu niedrigsten Hardware-Kosten; GPT-5.5 wenn in Dynamics/Copilot integriert |
| SaaS-Feature-Gating (Modell-Tiers pro Kunde, regionales Routing) | Hybrid-Muster: Mistral Small + Claude Opus 4.7 / GPT-5.5 | Sensible Kundendaten self-hosted, Premium-Features auf Cloud-Flaggschiff |

Die Matrix ist keine Vorschrift, sondern ein Startpunkt, der pro Organisation verfeinert wird. Ein Finance-lastiges Unternehmen gewichtet DeepSeek V4 höher. Eine Multimedia-lastige Operation braucht möglicherweise einen Cloud-Gemini-Hop. Eine HR-Pipeline mit hohem Dokumenten-Volumen setzt Mistral Small bei 80 % der Entscheidungen ein, nicht bei 70 %.

Die Routing-Schicht macht die Matrix operationalisierbar. Ohne sie läuft jeder Workload gegen das standardmäßig konfigurierte Modell, und die Matrix bleibt ein Folien-Artefakt.

## Die Routing-Schicht bauen: Wo der Decision Layer hineinpasst

Self-hosted Multi-Modell-Architekturen brechen ohne Routing-Schicht aus einem einfachen Grund zusammen: Niemand möchte sich 14 Entscheidungs-zu-Modell-Zuordnungen merken, während gleichzeitig die Business-Logik des Agenten geschrieben wird. Das Routing muss Konfiguration sein, kein Code.

Ein Decision Layer hält:

- Die Datenklassifikations-Taxonomie (welche Datentypen erfordern Self-Hosting? Welche dürfen an EU-Cloud-API? Welche an US-Cloud-API?)
- Die Entscheidungs-zu-Modell-Routing-Regeln pro Workflow-Schritt
- Die Fallback-Kette (wenn Mistral Small ausfällt oder saturiert, wohin?)
- Den Audit-Log: Jede Entscheidung mit Input-Snapshot, Regelversion, eingesetztem Modell, Confidence-Score, Reasoning-Chain, Ergebnis und menschlichem Prüfer (wo zutreffend)
- Den Anfechten-Button: Jede betroffene Person kann eine automatisierte Entscheidung anfechten und löst damit eine erneute Entscheidung unter menschlicher Prüfung aus - der von DSGVO Art. 22 verlangte Mechanismus

Das ist das Artefakt, das ein EU-AI-Act-Artikel-13-Prüfer einsieht. Es ist das Artefakt, das ein Betriebsrat reviewt, wenn er klassifiziert, welche Agenten in den BetrVG §87 Abs. 1 Nr. 6 Mitbestimmungs-Scope fallen. Es ist das Artefakt, das die Procurement-Frage "was passiert, wenn Ihr KI-Vendor ein Modell ändert?" beantwortet - denn die Routing-Regel ändert sich, nicht die Business-Logik.

Diese Schicht in-house zu bauen ist machbar, aber selten schneller als 6 bis 9 Monate für ein Enterprise-Team, das bei Null startet. Den Kauf als Konfigurations-Framework verkürzt den Weg typischerweise auf 4 bis 6 Wochen für den ersten produktiven Agenten.

## Fazit

Self-hosted Open-Source-KI ist 2026 eine glaubhafte Produktivwahl für EU-Enterprise - aber nur als Multi-Modell-Architektur mit einer Routing-Schicht, nicht als Single-Modell-Wette. Mistral Small 3.2 deckt die Volumen-Bandbreite ab. gpt-oss-120b oder DeepSeek V4-Flash übernimmt Heavy-Reasoning on-prem. DeepSeek V4-Pro (derzeit Preview) reicht an Claude Opus heran - wenn Sie Hyperscaler-Hardware haben oder die GA-Freigabe abwarten und V4-Pro in der Zwischenzeit via API nutzen. Llama 4 Scout deckt Ultra-Long-Context ab. Der Cloud-API-Tier (Claude Opus 4.7, GPT-5.5, Gemini 3.1 Pro) bleibt verfügbar für die Workloads, bei denen die Regulierung das erlaubt.

Die Routing-Entscheidung ist die Architektur. Der TCO-Crossover (rund 50 bis 100 Millionen Token pro Monat im Dauerbetrieb) setzt die wirtschaftliche Self-Hosting-Schwelle. Die Compliance-Taxonomie (welche Datenklassifikation das Netz nicht verlassen darf) setzt die Souveränitäts-Schwelle. Beide Schwellen formen die Routing-Regeln.

Andere publizieren Bestenlisten. Wir bauen die Routing-Schicht, die sie operationalisiert. Der Modellmarkt verändert sich monatlich; die Routing-Architektur überlebt fünf Modellgenerationen. Der Quellcode bleibt in der Kundeninfrastruktur. Modelle bleiben austauschbar. EU-AI-Act-Artikel-13-Compliance ist eine Eigenschaft der Architektur, kein Projekt am Ende.

Wenn Sie wissen wollen, wie Ihr self-hosted Stack auf Basis Ihres tatsächlichen Workload-Mix und Ihrer Datenklassifikation aussehen sollte, [vereinbaren Sie ein Gespräch](/de/kontakt/).

--- Shadow AI im Unternehmen - Governance statt Verbot ---
> Unkontrollierte KI-Nutzung (Shadow AI) ist ein Governance-Problem. Die Lösung ist kontrollierte Infrastruktur mit Audit Trail und Model Routing.

## Was ist Shadow AI?

Shadow AI ist das KI-Äquivalent von Shadow IT. Mitarbeiter nutzen ChatGPT, Google Gemini, Microsoft CoPilot oder andere KI-Tools für ihre Arbeit - ohne Wissen, Genehmigung oder Kontrolle der IT-Abteilung.

Der Sachbearbeiter, der eine Kundenreklamation in ChatGPT eingibt, um eine Antwort zu formulieren. Die HR-Mitarbeiterin, die ein Arbeitszeugnis per CoPilot entwirft. Der Controller, der Quartalszahlen in Gemini analysiert. Jede dieser Nutzungen sendet Unternehmensdaten an einen externen Dienst.

Shadow AI ist nicht böswillig. Mitarbeiter nutzen KI-Tools, weil sie produktiver werden. Aber ohne Governance hat die Organisation keine Kontrolle darüber, welche Daten das Unternehmen verlassen, welche Modelle verwendet werden und ob die Ergebnisse nachvollziehbar sind.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Auf einen Blick - Shadow AI Governance</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Shadow AI bedeutet: Mitarbeiter nutzen externe KI-Tools ohne Wissen der IT - Unternehmensdaten fließen in unkontrollierte Systeme.</li>
<li>Verbote funktionieren nicht - Mitarbeiter nutzen private Geräte und alternative Tools. Verbote erzeugen unkontrollierte Umgehung.</li>
<li>PwC (2024) stellte fest, dass in 54 % der Unternehmen Mitarbeiter generative KI-Tools ohne formale Genehmigung der Organisation nutzen.</li>
<li>Die Lösung ist kontrollierte Infrastruktur: unternehmenseigenes KI-Interface, Model Routing, Nutzungsprotokoll und Audit-Trail.</li>
<li>Drei Phasen: Bestandsaufnahme der aktuellen Nutzung, Aufbau kontrollierter Infrastruktur, dann spezialisierte Agenten für häufige Anwendungsfälle.</li>
</ul>
</div>

## Warum Verbote nicht funktionieren

Die naheliegende Reaktion auf Shadow AI ist ein Verbot. Viele Unternehmen haben ChatGPT und ähnliche Tools gesperrt - per Firewall-Regel, per Richtlinie, per Betriebsvereinbarung.

Das Problem: Verbote funktionieren nicht. Mitarbeiter nutzen ihre privaten Smartphones. Sie nutzen Browser-Extensions. Sie nutzen alternative Tools, die noch nicht auf der Sperrliste stehen. Das Verbot erzeugt keine Compliance - es erzeugt unkontrollierte Umgehung.

Gleichzeitig verliert das Unternehmen den Produktivitätsvorteil, den KI bieten kann. Während die Mitarbeiter ihre KI-Nutzung verstecken, kann die IT weder unterstützen noch steuern noch optimieren.

## Die Alternative: Kontrollierte KI-Infrastruktur

Die Lösung ist nicht Verbot, sondern Infrastruktur. Eine unternehmenseigene KI-Infrastruktur gibt Mitarbeitern leistungsfähige KI-Tools - unter Kontrolle der Organisation.

**Unternehmenseigenes KI-Interface:** Statt ChatGPT nutzen Mitarbeiter ein internes Chat-Interface, das auf unternehmenseigene Modelle zugreift. Die Benutzerführung ist identisch. Der Unterschied: Alle Daten bleiben in der eigenen Infrastruktur.

**Model Routing:** Die IT entscheidet, welche Modelle für welche Anwendungsfälle eingesetzt werden. Sensible Daten gehen an Self-Hosted-Modelle. Unkritische Anfragen können an Cloud-Modelle geroutet werden. Die Entscheidung ist regelbasiert und nachvollziehbar.

**Nutzungsprotokoll:** Jede KI-Nutzung wird protokolliert - nicht um Mitarbeiter zu überwachen, sondern um den KI-Einsatz zu steuern. Welche Abteilungen nutzen KI am meisten? Für welche Aufgaben? Mit welchen Modellen? Diese Daten sind die Grundlage für den nächsten Schritt: spezialisierte Agenten für die häufigsten Anwendungsfälle.

**Audit Trail:** In regulierten Bereichen - Finance, HR, Compliance - wird jede KI-gestützte Entscheidung im Audit Trail dokumentiert. Der Decision Layer stellt sicher, dass geschäftskritische Prozesse nicht auf unkontrollierten KI-Outputs basieren.

## Von Shadow AI zu Governance by Design

Shadow AI ist ein Symptom. Die Ursache ist fehlende Infrastruktur. Wenn Mitarbeiter keine kontrollierten KI-Tools haben, nutzen sie unkontrollierte.

| Phase | Schwerpunkt | Ergebnisse |
|-------|-------------|------------|
| 1 - Bestandsaufnahme | Aktuelle KI-Nutzung in allen Abteilungen erfassen | Tool-Inventar, Datenflussanalyse, Risikoklassifizierung |
| 2 - Kontrollierte Infrastruktur | Unternehmenseigene KI-Plattform mit Governance | LLM-Hosting, Chat-Interface, Model Routing, Nutzungsprotokoll |
| 3 - Spezialisierte Agenten | Zweckgebundene Agenten für häufige Anwendungsfälle | Document Agent, Knowledge Agent, Workflow Agent - jeweils mit Decision Layer |

Der Weg von Shadow AI zu [Governance by Design](/de/governance/):

**Phase 1: Bestandsaufnahme.** Welche KI-Tools werden im Unternehmen verwendet? Für welche Aufgaben? Mit welchen Daten? Diese Bestandsaufnahme ist oft ernüchternd - die reale KI-Nutzung übersteigt die offizielle deutlich.

**Phase 2: Kontrollierte Infrastruktur.** Aufbau einer unternehmenseigenen KI-Infrastruktur. LLM-Hosting, Chat-Interface, Model Routing, Nutzungsprotokoll. Mitarbeiter erhalten ein Tool das mindestens so leistungsfähig ist wie ChatGPT - aber unter Kontrolle der IT.

**Phase 3: Spezialisierte Agenten.** Aus den häufigsten Anwendungsfällen werden spezialisierte Agenten entwickelt. Statt eines generischen Chats gibt es einen Document Agent für die Belegverarbeitung, einen Knowledge Agent für HR-Fragen, einen Workflow Agent für die Rechnungsverarbeitung. Jeder Agent mit Decision Layer und Governance.

## Das Risiko des Nicht-Handelns

Shadow AI wird nicht verschwinden. Die KI-Tools werden besser, leichter zugänglich, stärker in bestehende Software integriert. Jedes Office-Update bringt neue KI-Funktionen. Jeder Browser hat KI-Features.

Unternehmen die keine kontrollierte KI-Infrastruktur aufbauen, werden feststellen, dass ihre Mitarbeiter KI längst nutzen - ohne Governance, ohne Audit Trail, ohne DSGVO-Prüfung. Die Frage ist nicht ob, sondern wann das zum Problem wird. Bei der nächsten Betriebsprüfung. Bei der nächsten DSGVO-Anfrage. Beim nächsten Datenleck.

Mehr dazu: [KI-Infrastruktur](/de/leistungen/infrastruktur/)

<a href="/de/kontakt/" target="_blank" rel="noopener noreferrer">Termin vereinbaren</a> - Wir zeigen Ihnen, wie Sie Shadow AI in kontrollierte KI-Infrastruktur überführen.

--- Supabase Edge Functions sicher einsetzen ---
> DevOps-Runbook für Supabase Edge Functions: Webhooks, Signaturen, CORS, Deno-Runtime, Input Validation und Claude-Code-Integration.

Supabase Edge Functions sind serverseitige TypeScript-Funktionen, die auf dem Deno-Runtime laufen und über den Kong API Gateway erreichbar sind.

Sie sind besonders geeignet für Webhooks, Integrationen mit externen APIs, signierte Event-Endpunkte und leichte serverseitige Logik.

Der häufigste Fehler ist, Edge Functions als **zweites Backend-System** zu verwenden. Mehr als 40% aller Webhook-Sicherheitsvorfälle entstehen durch fehlende Signaturprüfung (GitGuardian State of Secrets Sprawl 2024). Das führt zu doppelter Business-Logik, unklaren Sicherheitsgrenzen und schwer debuggbaren Architekturen.

Dieses Runbook beschreibt, wie Edge Functions im [self-hosted Setup](/de/magazin/supabase-self-hosting/) sicher eingesetzt werden. Jeder Schritt enthält eine konkrete Implementierung mit echtem Deno-Code, eine prüfbare Bedingung und ein Failure Scenario.

> **Hinweis zum Runtime:** Supabase Edge Functions basieren auf **Deno**, nicht auf Node.js. Das betrifft Import-Syntax, Modul-System und verfügbare APIs. Alle Code-Beispiele in diesem Artikel sind Deno-kompatibel. Self-hosted Edge Functions laufen im `supabase/edge-runtime` Container und sind derzeit noch als Beta gekennzeichnet.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Auf einen Blick - Artikel 3 von 6 der DevOps-Runbook-Serie</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Edge Functions nur als Integrationspunkte (Webhooks, Events), nicht als zweites Backend</li>
<li>Jeder Webhook-Endpunkt muss die Signatur des sendenden Dienstes prüfen</li>
<li>CORS explizit konfigurieren (kein Wildcard in Produktion)</li>
<li>Input Validation mit Zod auf jedem eingehenden Payload</li>
<li>Langläufer an Trigger.dev delegieren statt in Edge Functions blockieren</li>
</ul>
</div>

## Serien-Inhaltsverzeichnis

Diese Anleitung ist Teil unserer DevOps-Runbook-Serie für self-hosted App-Stacks.

1. [Supabase Self-Hosting Runbook](/de/magazin/supabase-self-hosting/)
2. [Next.js über Supabase sicher betreiben](/de/magazin/nextjs-supabase-sicher-betreiben/)
3. [Supabase Edge Functions sicher einsetzen](/de/magazin/supabase-edge-functions-sicher/) - dieser Artikel
4. [Trigger.dev Background Jobs sicher betreiben](/de/magazin/trigger-dev-background-jobs/)
5. [Claude Code als Sicherheitskontrolle im DevOps-Workflow](/de/magazin/claude-code-security-devops/)
6. [Security Baseline für den gesamten Stack](/de/magazin/security-baseline-stack/)

[Artikel 1 beschreibt die Plattform](/de/magazin/supabase-self-hosting/#teil-b---supabase-services-einrichten-und-absichern) mit der Kong-Konfiguration, über die Edge Functions erreichbar sind.
[Artikel 2 beschreibt die Next.js App-Schicht](/de/magazin/nextjs-supabase-sicher-betreiben/#b4---mutation-pattern) mit den Server Actions für Business-Logik.
Dieser Artikel beschreibt **Integrationen und Webhooks**.

## Architekturüberblick

```
Browser
   |
Next.js (App-Schicht)
   |
   +-- Supabase Client (anon key)     -> für User-Requests
   |
Kong API Gateway
   |
   +-- PostgREST                       -> REST API mit RLS
   +-- GoTrue                          -> Auth
   +-- Edge Runtime                    -> Edge Functions
   |     |
   |     +-- stripe-webhook
   |     +-- github-webhook
   |     +-- trigger-webhook
   |
PostgreSQL + RLS Policies

Externe Services
   |
   +-- Stripe / GitHub / Trigger.dev   -> rufen Webhooks auf
```

Grundregel:

```
Edge Functions sind Integrationspunkte für externe Events.
Business-Logik gehört nach Next.js (Server Actions / Route Handler).
Langläufer gehören in Trigger.dev.
```

### Entscheidungskriterium

Wenn eine Funktion auf einen **externen Event** reagiert (Stripe Payment, GitHub Push, Trigger.dev Callback), ist sie eine Edge Function. Wenn sie auf **User-Input** reagiert und Daten transformiert, gehört sie nach Next.js. Wenn sie **länger als 30 Sekunden** läuft, gehört sie in Trigger.dev.

### Entscheidungstabelle: Edge Function vs. Server Action vs. Trigger.dev

| Kriterium | Edge Function | Next.js Server Action | Trigger.dev Task |
|-----------|--------------|----------------------|-----------------|
| Auslöser | Externer Event (Webhook) | User-Input (Browser) | Programmatisch / Cron |
| Laufzeit | Unter 30 Sekunden | Unter 10 Sekunden | Bis 5+ Minuten |
| User-Kontext | Nein (kein JWT) | Ja (Session) | Nein (service_role) |
| RLS aktiv | Nein (service_role) | Ja (anon Key) | Nein (service_role) |
| Retry-Logik | Keine (Provider retried) | Keine | Eingebaut (konfigurierbar) |
| Beispiel | Stripe Webhook | Formular speichern | PDF-Generierung |

## Wie Edge Functions im Self-Hosted Setup laufen

Im self-hosted Docker-Compose-Stack sieht die Edge Functions Konfiguration so aus:

```yaml
# docker-compose.yml (Auszug)
functions:
  container_name: supabase-edge-functions
  image: supabase/edge-runtime:v1.66.4    # Version pinnen
  restart: unless-stopped
  depends_on:
    - analytics
  environment:
    JWT_SECRET: ${JWT_SECRET}
    SUPABASE_URL: http://kong:8000                    # interner Docker-Hostname
    SUPABASE_ANON_KEY: ${ANON_KEY}
    SUPABASE_SERVICE_ROLE_KEY: ${SERVICE_ROLE_KEY}
    SUPABASE_DB_URL: postgresql://postgres:${POSTGRES_PASSWORD}@${POSTGRES_HOST}:${POSTGRES_PORT}/${POSTGRES_DB}
    VERIFY_JWT: "${FUNCTIONS_VERIFY_JWT}"
  volumes:
    - ./volumes/functions:/home/deno/functions:Z
  command:
    - start
    - --main-service
    - /home/deno/functions/main
```

Edge Functions liegen als TypeScript-Dateien im Volume:

```
volumes/functions/
  main/
    index.ts              <- Router / Main Service
  _shared/
    cors.ts               <- CORS Headers (shared)
    supabase-client.ts    <- Supabase Client Factory (shared)
  stripe-webhook/
    index.ts
  github-webhook/
    index.ts
```

**Deployment im Self-Hosted Setup:** Funktionen werden als Dateien in das Volume gelegt und der Container neu gestartet:

```bash
# Functions in das Volume kopieren
cp -r supabase/functions/* /opt/supabase/volumes/functions/

# Container neu starten
docker compose restart functions --no-deps
```

## Teil A - Architekturentscheidungen

Diese Entscheidungen werden einmal getroffen und selten geändert.

## A1 - Edge Functions nur für Integrationen, nicht als zweites Backend

### Umsetzung

Klare Zuordnung, welche Logik wohin gehört:

```
Edge Functions (Deno):
  Webhook Empfang (Stripe, GitHub, externe APIs)
  Event-basierte Sync (DB Webhook -> externer Service)
  Signaturprüfung eingehender Events
  Leichte Transformationen (< 30 Sekunden)

Next.js (Server Actions / Route Handler):
  User-facing Mutations (CRUD)
  Session-basierte Operationen
  Business-Logik
  Input Validation mit User-Kontext

Trigger.dev (Background Jobs):
  PDF-Generierung
  AI-Tasks
  Massen-E-Mail-Versand
  Alles über 30 Sekunden Laufzeit
```

### Prüfbare Bedingung

```bash
# Wie viele Edge Functions gibt es?
ls -d volumes/functions/*/ | grep -v "main\|_shared" | wc -l

# Für jede Function prüfen: ist es eine Integration?
for dir in volumes/functions/*/; do
  name=$(basename "$dir")
  [[ "$name" == "main" || "$name" == "_shared" ]] && continue
  echo "--- $name ---"
  # Enthält es Webhook/Integration Patterns?
  grep -l "signature\|webhook\|stripe\|github\|trigger" "$dir"*.ts 2>/dev/null || \
    echo "WARNUNG: keine Webhook/Integration Patterns gefunden"
done
```

### Failure Scenario

Wenn Business-Logik in Edge Functions implementiert wird, entsteht eine Schattenarchitektur: Dieselbe Validierung existiert in Next.js Server Actions UND in Edge Functions, mit subtilen Unterschieden. Bugs werden schwer reproduzierbar, weil unklar ist, welcher Codepfad aktiv war. Auth-Logik muss an zwei Stellen gepflegt werden.

## A2 - Webhook-Endpunkte isolieren: eine Funktion pro Webhook

### Umsetzung

Jeder Webhook-Provider bekommt eine eigene Funktion in einem eigenen Verzeichnis:

```
volumes/functions/
  stripe-webhook/
    index.ts
  github-webhook/
    index.ts
  trigger-webhook/
    index.ts
```

**Nicht so:**

```
volumes/functions/
  webhooks/
    index.ts     <- verarbeitet Stripe, GitHub und Trigger in einer Datei
```

### Prüfbare Bedingung

```bash
# Jede Webhook-Function sollte genau einen Provider bedienen
for dir in volumes/functions/*-webhook/; do
  name=$(basename "$dir")
  providers=$(grep -ciE "stripe|github|trigger|slack|sendgrid" "$dir/index.ts")
  if [ "$providers" -gt 1 ]; then
    echo "WARNUNG: $name bedient mehrere Provider ($providers)"
  fi
done
```

### Failure Scenario

Wenn mehrere Webhooks in einer Funktion verarbeitet werden, teilen sie sich denselben Error Handler. Ein fehlerhafter Stripe-Payload kann den GitHub-Webhook blockieren. Retry-Strategien unterscheiden sich pro Provider (Stripe retried mit exponential Backoff, GitHub nur 3x), das lässt sich in einer gemeinsamen Funktion kaum sauber abbilden.

## A3 - CORS korrekt konfigurieren

### Umsetzung

Edge Functions die vom Browser aufgerufen werden (auch indirekt) brauchen CORS-Header. Supabase liefert keine automatische CORS-Konfiguration für Edge Functions.

Shared CORS Config:

```typescript
// volumes/functions/_shared/cors.ts

const allowedOrigins = [
  'https://app.example.com',
  ...(Deno.env.get('ENVIRONMENT') === 'development'
    ? ['http://localhost:3000']
    : [])
]

export function getCorsHeaders(req: Request) {
  const origin = req.headers.get('origin') ?? ''
  const corsOrigin = allowedOrigins.includes(origin) ? origin : ''

  return {
    'Access-Control-Allow-Origin': corsOrigin,
    'Access-Control-Allow-Headers':
      'authorization, x-client-info, apikey, content-type',
    'Access-Control-Allow-Methods': 'POST, GET, OPTIONS',
  }
}
```

**Jede Edge Function** muss CORS am Anfang behandeln:

```typescript
import { getCorsHeaders } from '../_shared/cors.ts'

Deno.serve(async (req) => {
  const corsHeaders = getCorsHeaders(req)

  // CORS Preflight muss ERSTE Prüfung sein
  if (req.method === 'OPTIONS') {
    return new Response('ok', { headers: corsHeaders })
  }

  // ... eigentliche Logik

  return new Response(JSON.stringify(data), {
    headers: { ...corsHeaders, 'Content-Type': 'application/json' },
  })
})
```

### Prüfbare Bedingung

```bash
# Alle Functions müssen CORS behandeln
for dir in volumes/functions/*/; do
  name=$(basename "$dir")
  [[ "$name" == "main" || "$name" == "_shared" ]] && continue
  if ! grep -q "OPTIONS" "$dir/index.ts" 2>/dev/null; then
    echo "WARNUNG: $name hat keinen OPTIONS Handler"
  fi
done

# Kein Wildcard CORS in Produktion
grep -r "'\\*'" volumes/functions/ --include="*.ts" | grep -i "allow-origin"
# Erwartung: keine Treffer (außer in Development-Branches)
```

### Failure Scenario

Ohne CORS-Header schlagen alle Browser-Requests an Edge Functions fehl. Der Browser blockiert die Response, auch wenn die Funktion korrekt antwortet. Das äußert sich als kryptischer CORS-Fehler in der Konsole. Mit Wildcard-CORS (`'*'`) in Produktion kann jede beliebige Website Requests an eure Edge Functions senden und die Responses lesen.

## Teil B - Implementierungschecks

Diese Checks gelten für jede Edge Function und müssen bei jedem Deployment geprüft werden.

## B1 - Webhook-Signaturen prüfen

### Umsetzung

Jeder Webhook-Endpunkt muss die Signatur des sendenden Services verifizieren. Ohne Signaturprüfung kann jeder beliebige Payloads an die Function senden.

**Vollständiges Stripe-Webhook Beispiel:**

```typescript
// volumes/functions/stripe-webhook/index.ts

import { getCorsHeaders } from '../_shared/cors.ts'

const STRIPE_WEBHOOK_SECRET = Deno.env.get('STRIPE_WEBHOOK_SECRET')

Deno.serve(async (req) => {
  const corsHeaders = getCorsHeaders(req)

  if (req.method === 'OPTIONS') {
    return new Response('ok', { headers: corsHeaders })
  }

  // 1. Nur POST erlauben
  if (req.method !== 'POST') {
    return new Response(
      JSON.stringify({ error: 'Method not allowed' }),
      { status: 405, headers: { ...corsHeaders, 'Content-Type': 'application/json' } }
    )
  }

  // 2. Signatur prüfen
  const signature = req.headers.get('stripe-signature')
  if (!signature) {
    return new Response(
      JSON.stringify({ error: 'Missing signature' }),
      { status: 401, headers: { ...corsHeaders, 'Content-Type': 'application/json' } }
    )
  }

  const body = await req.text()

  const isValid = await verifyStripeSignature(body, signature, STRIPE_WEBHOOK_SECRET!)
  if (!isValid) {
    return new Response(
      JSON.stringify({ error: 'Invalid signature' }),
      { status: 401, headers: { ...corsHeaders, 'Content-Type': 'application/json' } }
    )
  }

  // 3. Event verarbeiten
  const event = JSON.parse(body)

  switch (event.type) {
    case 'checkout.session.completed':
      await handleCheckoutCompleted(event.data.object)
      break
    case 'invoice.payment_failed':
      await handlePaymentFailed(event.data.object)
      break
    default:
      // Unbekannte Events ignorieren, nicht fehlschlagen
      console.log(`Unhandled event type: ${event.type}`)
  }

  // 4. Immer 200 zurückgeben (Stripe retried sonst)
  return new Response(
    JSON.stringify({ received: true }),
    { status: 200, headers: { ...corsHeaders, 'Content-Type': 'application/json' } }
  )
})

// Stripe Signatur Verifizierung mit Deno Crypto API
async function verifyStripeSignature(
  payload: string,
  header: string,
  secret: string
): Promise<boolean> {
  const parts = header.split(',')
  const timestamp = parts.find(p => p.startsWith('t='))?.split('=')[1]
  const signature = parts.find(p => p.startsWith('v1='))?.split('=')[1]

  if (!timestamp || !signature) return false

  // Timing Check: Events älter als 5 Minuten ablehnen
  const now = Math.floor(Date.now() / 1000)
  if (now - parseInt(timestamp) > 300) return false

  const signedPayload = `${timestamp}.${payload}`
  const key = await crypto.subtle.importKey(
    'raw',
    new TextEncoder().encode(secret),
    { name: 'HMAC', hash: 'SHA-256' },
    false,
    ['sign']
  )

  const sig = await crypto.subtle.sign(
    'HMAC',
    key,
    new TextEncoder().encode(signedPayload)
  )

  const expectedSig = Array.from(new Uint8Array(sig))
    .map(b => b.toString(16).padStart(2, '0'))
    .join('')

  return expectedSig === signature
}

async function handleCheckoutCompleted(session: Record<string, unknown>) {
  console.log(`Checkout completed: ${session.id}`)
}

async function handlePaymentFailed(invoice: Record<string, unknown>) {
  console.log(`Payment failed: ${invoice.id}`)
}
```

**GitHub-Webhook Signaturprüfung (anderes Verfahren):**

```typescript
// volumes/functions/github-webhook/index.ts

const GITHUB_WEBHOOK_SECRET = Deno.env.get('GITHUB_WEBHOOK_SECRET')

async function verifyGitHubSignature(
  payload: string,
  signatureHeader: string,
  secret: string
): Promise<boolean> {
  // GitHub nutzt sha256=<hex>
  const expected = signatureHeader.replace('sha256=', '')

  const key = await crypto.subtle.importKey(
    'raw',
    new TextEncoder().encode(secret),
    { name: 'HMAC', hash: 'SHA-256' },
    false,
    ['sign']
  )

  const sig = await crypto.subtle.sign(
    'HMAC',
    key,
    new TextEncoder().encode(payload)
  )

  const computed = Array.from(new Uint8Array(sig))
    .map(b => b.toString(16).padStart(2, '0'))
    .join('')

  return computed === expected
}
```

### Prüfbare Bedingung

```bash
# Jede Webhook-Function muss eine Signaturprüfung haben
for dir in volumes/functions/*-webhook/; do
  name=$(basename "$dir")
  if ! grep -qE "signature|verify|hmac" "$dir/index.ts" 2>/dev/null; then
    echo "KRITISCH: $name hat keine Signaturprüfung"
  else
    echo "OK: $name prüft Signaturen"
  fi
done

# VERIFY_JWT Setting prüfen
# Webhooks brauchen VERIFY_JWT=false, weil externe Services kein Supabase JWT senden
grep "VERIFY_JWT" .env
```

### Failure Scenario

Ohne Signaturprüfung kann ein Angreifer beliebige Events an den Webhook senden:

```bash
curl -X POST https://app.example.com/functions/v1/stripe-webhook \
  -H "Content-Type: application/json" \
  -d '{"type":"checkout.session.completed","data":{"object":{"customer":"cus_fake"}}}'
```

Dieser Request würde eine gefälschte Checkout-Bestätigung auslösen. Die Funktion würde den User-Status aktualisieren, obwohl nie bezahlt wurde.

## B2 - Supabase Client korrekt initialisieren (anon vs. service_role)

### Umsetzung

Edge Functions haben Zugriff auf alle Supabase Environment Variables. Die Wahl zwischen `anon` Key und `service_role` Key ist die wichtigste Sicherheitsentscheidung pro Function.

**Shared Client Factory:**

```typescript
// volumes/functions/_shared/supabase-client.ts

import { createClient, SupabaseClient } from 'npm:@supabase/supabase-js@2'

// Client MIT RLS (für User-Kontext Operationen)
export function createAnonClient(authHeader?: string): SupabaseClient {
  const client = createClient(
    Deno.env.get('SUPABASE_URL')!,
    Deno.env.get('SUPABASE_ANON_KEY')!,
    {
      global: {
        headers: authHeader ? { Authorization: authHeader } : {},
      },
    }
  )
  return client
}

// Client OHNE RLS (für Webhook Processing, Admin Tasks)
// ACHTUNG: Umgeht alle Row Level Security Policies
export function createAdminClient(): SupabaseClient {
  return createClient(
    Deno.env.get('SUPABASE_URL')!,
    Deno.env.get('SUPABASE_SERVICE_ROLE_KEY')!
  )
}
```

**Wann welcher Client:**

```
createAnonClient(authHeader):
  User-facing Functions (selten, gehören meist nach Next.js)
  Wenn RLS den Zugriff kontrollieren soll

createAdminClient():
  Webhook Processing (Stripe, GitHub)
  Interne Sync-Tasks
  Wenn die Function KEINEN User-Kontext hat

Faustregel: Webhooks haben keinen User-Kontext,
also brauchen sie service_role.
Aber: Nur die minimalen Operationen ausführen.
```

### Prüfbare Bedingung

```bash
# Wo wird service_role / Admin Client genutzt?
grep -rn "SERVICE_ROLE\|createAdminClient\|service_role" \
  volumes/functions/ --include="*.ts" | grep -v "_shared/"

# Erwartung: nur in Webhook-Functions, nicht in User-facing Functions

# Wird der Admin Client mit ungeprüftem User-Input gefüttert?
# Manueller Review: In jeder Function die createAdminClient nutzt,
# prüfen ob Input vor der DB-Operation validiert wird
```

### Failure Scenario

Wenn eine Edge Function mit `service_role` läuft und User-Input direkt in Queries weiterreicht, umgeht sie RLS vollständig. Ein manipulierter Webhook-Payload könnte dann beliebige Daten in beliebigen Tabellen lesen oder schreiben, weil der `service_role` Key keine Einschränkungen kennt.

## B3 - Input Validation

### Umsetzung

Jede Edge Function muss eingehende Daten validieren, bevor sie verarbeitet werden. In Deno funktioniert Zod über npm-Import:

```typescript
// volumes/functions/stripe-webhook/index.ts (Auszug)

import { z } from 'npm:zod@3'

// Schema für den erwarteten Stripe Event
const stripeEventSchema = z.object({
  id: z.string().startsWith('evt_'),
  type: z.string(),
  data: z.object({
    object: z.record(z.unknown()),
  }),
})

// In der Hauptfunktion nach Signaturprüfung:
const parsed = stripeEventSchema.safeParse(JSON.parse(body))

if (!parsed.success) {
  return new Response(
    JSON.stringify({ error: 'Invalid payload structure' }),
    { status: 400, headers: { ...corsHeaders, 'Content-Type': 'application/json' } }
  )
}

// Ab hier mit parsed.data arbeiten (typsicher)
const event = parsed.data
```

### Prüfbare Bedingung

```bash
# Jede Function sollte Input Validation haben
for dir in volumes/functions/*/; do
  name=$(basename "$dir")
  [[ "$name" == "main" || "$name" == "_shared" ]] && continue
  if grep -qE "zod|safeParse|z\.object|z\.string" "$dir/index.ts" 2>/dev/null; then
    echo "OK: $name hat Schema Validation"
  elif grep -qE "JSON\.parse" "$dir/index.ts" 2>/dev/null; then
    echo "WARNUNG: $name parsed JSON ohne Schema Validation"
  fi
done
```

### Failure Scenario

Ohne Input Validation akzeptiert die Function jeden Payload, der eine gültige Signatur hat. Ein kompromittierter API-Key beim Webhook-Provider könnte dann unerwartete Datenstrukturen senden, die zu undefinierten Datenbankoperationen führen, z.B. `undefined` als User-ID in einen Insert.

## B4 - Secrets in Environment Variables, nie im Code

### Umsetzung

Im Self-Hosted Setup werden Secrets über die Docker-Compose-Konfiguration an Edge Functions übergeben:

```yaml
# docker-compose.yml (Auszug)
functions:
  environment:
    JWT_SECRET: ${JWT_SECRET}
    SUPABASE_URL: http://kong:8000
    SUPABASE_ANON_KEY: ${ANON_KEY}
    SUPABASE_SERVICE_ROLE_KEY: ${SERVICE_ROLE_KEY}
  env_file:
    - .env.functions    # zusätzliche Secrets für Functions
```

```bash
# .env.functions (nur auf dem Server, nicht im Git)
STRIPE_WEBHOOK_SECRET=whsec_...
STRIPE_SECRET_KEY=sk_live_...
GITHUB_WEBHOOK_SECRET=ghsec_...
TRIGGER_DEV_API_KEY=tr_...
```

Im Code zugreifen:

```typescript
// So: Environment Variable
const secret = Deno.env.get('STRIPE_WEBHOOK_SECRET')

// NIEMALS so: Hardcoded
const secret = 'whsec_abc123...'
```

Für die allgemeinen Grundlagen der Secret-Verwaltung siehe [Datensicherheit in der Enterprise-KI-Infrastruktur](/de/magazin/datensicherheit-ki-enterprise/).

### Prüfbare Bedingung

```bash
# Hardcoded Secrets im Code?
grep -rn "sk_live\|sk_test\|whsec_\|ghsec_\|Bearer ey" \
  volumes/functions/ --include="*.ts"
# Erwartung: keine Treffer

# .env.functions nicht im Git?
git ls-files .env.functions
# Erwartung: leer

# Dateirechte korrekt?
stat -c "%a" .env.functions
# Erwartung: 600
```

### Failure Scenario

Hardcoded Secrets im Quellcode landen im Git-Repository. Selbst wenn das Repo privat ist, haben alle Entwickler mit Repo-Zugang auch Zugang zu Produktions-Secrets. Bei einem versehentlichen Public-Push sind die Secrets sofort kompromittiert.

## B5 - Timeouts und Langläufer vermeiden

### Umsetzung

Edge Functions sind für kurze, idempotente Operationen konzipiert. Der Self-Hosted Edge Runtime hat ein Default-Timeout (konfigurierbar, typisch 60 Sekunden für self-hosted). Langläufer blockieren Worker-Slots.

```
Geeignet (< 30 Sekunden):
  Webhook empfangen und DB updaten
  Signatur prüfen und Event weiterleiten
  Kurze API-Calls an externe Services

NICHT geeignet (Trigger.dev verwenden):
  PDF-Generierung
  AI-Inference (LLM Calls)
  Video/Bild-Verarbeitung
  Massen-Datenbank-Operationen
  E-Mail-Versand an viele Empfänger
```

**Pattern für Langläufer: Edge Function als Trigger, Job in Trigger.dev:**

```typescript
// volumes/functions/process-document/index.ts

// RICHTIG: Edge Function triggert nur den Job
Deno.serve(async (req) => {
  // ... Signatur prüfen, Input validieren ...

  // Langläufer-Job an Trigger.dev delegieren
  const triggerResponse = await fetch(
    `${Deno.env.get('TRIGGER_DEV_URL')}/api/v1/tasks/process-document/trigger`,
    {
      method: 'POST',
      headers: {
        'Authorization': `Bearer ${Deno.env.get('TRIGGER_DEV_API_KEY')}`,
        'Content-Type': 'application/json',
      },
      body: JSON.stringify({
        payload: { documentId: parsed.data.documentId },
      }),
    }
  )

  // Sofort antworten, der Job läuft im Hintergrund
  return new Response(
    JSON.stringify({ queued: true }),
    { status: 202, headers: { 'Content-Type': 'application/json' } }
  )
})
```

### Prüfbare Bedingung

```bash
# Sucht nach Patterns die auf Langläufer hindeuten
grep -rn "await.*fetch.*openai\|pdf\|sharp\|ffmpeg\|sleep\|setTimeout" \
  volumes/functions/ --include="*.ts" | grep -v "trigger"
# Erwartung: keine Treffer (außer kurze API Calls)

# Gibt es Timeouts im Code?
grep -rn "AbortSignal.timeout\|setTimeout" \
  volumes/functions/ --include="*.ts"
# Jeder externe fetch sollte einen Timeout haben
```

### Failure Scenario

Eine Edge Function die 2 Minuten auf einen AI-API-Call wartet, blockiert einen Worker-Slot im Edge Runtime Container. Bei mehreren gleichzeitigen Requests laufen die Worker voll, und nachfolgende Webhook-Calls (z.B. von Stripe) scheitern mit Timeouts. Stripe interpretiert das als Fehler und retried, was die Situation verschlimmert.

## B6 - Error Handling und sichere Responses

### Umsetzung

Edge Functions dürfen bei Fehlern keine internen Details an den Aufrufer leaken.

```typescript
// Pattern für sicheres Error Handling

Deno.serve(async (req) => {
  const corsHeaders = getCorsHeaders(req)

  if (req.method === 'OPTIONS') {
    return new Response('ok', { headers: corsHeaders })
  }

  try {
    // ... eigentliche Logik ...

    return new Response(
      JSON.stringify({ success: true }),
      { status: 200, headers: { ...corsHeaders, 'Content-Type': 'application/json' } }
    )

  } catch (error) {
    // Intern loggen (Details)
    console.error(`Function error: ${error.message}`, {
      stack: error.stack,
      // KEINE Secrets oder User-Daten loggen
    })

    // Extern antworten (generisch)
    return new Response(
      JSON.stringify({ error: 'Internal server error' }),
      { status: 500, headers: { ...corsHeaders, 'Content-Type': 'application/json' } }
    )
  }
})
```

**Was NICHT in Responses oder Logs gehört:**

```typescript
// FALSCH: Stack Trace an Client senden
return new Response(JSON.stringify({ error: error.stack }), { status: 500 })

// FALSCH: Secrets loggen
console.log(`Connecting with key: ${Deno.env.get('SERVICE_ROLE_KEY')}`)

// FALSCH: Vollständige User-Daten loggen
console.log(`Processing user: ${JSON.stringify(user)}`)
```

### Prüfbare Bedingung

```bash
# Werden Error Details an den Client gesendet?
grep -rn "error\.stack\|error\.message" volumes/functions/ --include="*.ts" | \
  grep "Response"
# Erwartung: keine Treffer (stack/message nur in console.error)

# Werden Secrets geloggt?
grep -rn "console\.log.*KEY\|console\.log.*SECRET\|console\.log.*token" \
  volumes/functions/ --include="*.ts"
# Erwartung: keine Treffer
```

### Failure Scenario

Wenn ein Error Stack Trace an den Client gesendet wird, sieht ein Angreifer interne Pfade, Modulnamen und Datenbankverbindungsdetails. Das erleichtert gezielte Angriffe erheblich. Wenn Secrets in Logs landen, sind sie für jeden mit Monitoring-Zugang sichtbar.

## Teil C - Betrieb und Überwachung

## C1 - Deployment-Workflow

### Umsetzung

Im Self-Hosted Setup gibt es keinen `supabase functions deploy` Befehl. Der Workflow ist dateibasiert:

```bash
#!/bin/bash
# scripts/deploy-functions.sh

set -euo pipefail

FUNCTIONS_DIR="/opt/supabase/volumes/functions"
SOURCE_DIR="./supabase/functions"

echo "Deploying Edge Functions..."

# 1. Syntax-Check (Deno)
for file in $(find "$SOURCE_DIR" -name "*.ts" -not -path "*/_shared/*"); do
  deno check "$file" 2>/dev/null || {
    echo "FEHLER: Syntax-Fehler in $file"
    exit 1
  }
done

# 2. Functions kopieren
rsync -av --delete \
  --exclude='*.test.ts' \
  "$SOURCE_DIR/" "$FUNCTIONS_DIR/"

# 3. Container neu starten
docker compose restart functions --no-deps

# 4. Health Check
sleep 5
HEALTH=$(curl -s -o /dev/null -w "%{http_code}" \
  http://localhost:8000/functions/v1/hello 2>/dev/null || echo "000")

if [ "$HEALTH" = "200" ] || [ "$HEALTH" = "401" ]; then
  echo "Edge Functions deployment erfolgreich"
else
  echo "WARNUNG: Health Check Status $HEALTH"
fi
```

### Prüfbare Bedingung

```bash
# Edge Runtime Container läuft?
docker compose ps functions --format '{{.State}}'
# Erwartung: running

# Functions sind erreichbar?
curl -s -o /dev/null -w "%{http_code}" \
  -H "Authorization: Bearer ${ANON_KEY}" \
  http://localhost:8000/functions/v1/stripe-webhook
# Erwartung: 200 oder 405 (Method Not Allowed, weil GET statt POST)
```

## C2 - Claude Code Integration

Claude Code prüft Edge Functions kontextuell als Ergänzung zu den deterministischen Checks.

### Architektur

```
Git Push / PR
   |
   +-- Deterministische Checks (CI/CD)
   |   +-- grep nach hardcoded Secrets
   |   +-- grep nach fehlender Signaturprüfung
   |   +-- grep nach fehlender Input Validation
   |   +-- grep nach Error Details in Responses
   |   +-- Deno Type Check
   |
   +-- Claude Code Analyse (wöchentlich oder bei PR)
       +-- Neue Functions ohne Signaturprüfung?
       +-- service_role Nutzung angemessen?
       +-- Langläufer-Patterns erkannt?
       +-- Architektur-Drift (Business-Logik in Functions)?
       +-- CORS korrekt für neue Functions?
```

### Konkretes CI-Script

```bash
#!/bin/bash
# scripts/check-edge-functions.sh

REPORT=""
FUNCTIONS_DIR="volumes/functions"

# 1. Hardcoded Secrets
SECRETS=$(grep -rn "sk_live\|sk_test\|whsec_\|Bearer ey" \
  "$FUNCTIONS_DIR" --include="*.ts" 2>/dev/null)
if [ -n "$SECRETS" ]; then
  REPORT+="KRITISCH: Hardcoded Secrets gefunden:\n$SECRETS\n\n"
fi

# 2. Webhook Functions ohne Signaturprüfung
for dir in "$FUNCTIONS_DIR"/*-webhook/; do
  [ -d "$dir" ] || continue
  name=$(basename "$dir")
  if ! grep -qE "signature|verify|hmac|crypto" "$dir/index.ts" 2>/dev/null; then
    REPORT+="KRITISCH: $name hat keine Signaturprüfung\n"
  fi
done

# 3. Functions ohne Input Validation
for dir in "$FUNCTIONS_DIR"/*/; do
  name=$(basename "$dir")
  [[ "$name" == "main" || "$name" == "_shared" ]] && continue
  if grep -q "JSON.parse" "$dir/index.ts" 2>/dev/null && \
     ! grep -qE "zod|safeParse|z\." "$dir/index.ts" 2>/dev/null; then
    REPORT+="WARNUNG: $name parsed JSON ohne Schema Validation\n"
  fi
done

# 4. Error Details in Responses
LEAKS=$(grep -rn "error\.stack\|error\.message" "$FUNCTIONS_DIR" --include="*.ts" | \
  grep "Response" 2>/dev/null)
if [ -n "$LEAKS" ]; then
  REPORT+="WARNUNG: Error Details in Responses:\n$LEAKS\n\n"
fi

# 5. CORS Wildcards
WILDCARDS=$(grep -rn "'\\*'" "$FUNCTIONS_DIR" --include="*.ts" | grep -i "origin" 2>/dev/null)
if [ -n "$WILDCARDS" ]; then
  REPORT+="WARNUNG: CORS Wildcard gefunden:\n$WILDCARDS\n\n"
fi

# 6. Langläufer-Patterns
LONG=$(grep -rn "openai\|sharp\|ffmpeg\|puppeteer" "$FUNCTIONS_DIR" --include="*.ts" 2>/dev/null)
if [ -n "$LONG" ]; then
  REPORT+="WARNUNG: Mögliche Langläufer-Patterns:\n$LONG\n\n"
fi

# Ausgabe
if [ -n "$REPORT" ]; then
  echo -e "=== Edge Function Security Check ===\n"
  echo -e "$REPORT"
else
  echo "Alle Edge Function Checks bestanden."
fi
```

Claude führt **keine automatischen Änderungen auf Production** aus.

## Deployment-Checkliste

Vor jedem Deployment von Edge Functions prüfen:

```
Architektur
  [ ] Function ist eine Integration (Webhook/Event), keine Business-Logik
  [ ] Ein Webhook-Provider pro Function
  [ ] Langläufer an Trigger.dev delegiert

Sicherheit
  [ ] Webhook-Signatur wird geprüft
  [ ] Input wird mit Schema validiert (z.B. Zod)
  [ ] Korrekte Client-Wahl (anon vs. service_role)
  [ ] service_role nur wenn kein User-Kontext vorhanden

Secrets
  [ ] Keine hardcoded Secrets im Code
  [ ] Secrets in .env.functions (nicht im Git)
  [ ] .env.functions mit Rechten 600

CORS
  [ ] OPTIONS Handler vorhanden
  [ ] Kein Wildcard-Origin in Produktion
  [ ] CORS Headers in ALLEN Responses (auch Error)

Error Handling
  [ ] Try/Catch um die gesamte Logik
  [ ] Generische Fehlermeldungen an den Client
  [ ] Details nur in console.error (ohne Secrets)

Deployment
  [ ] Deno Type Check bestanden
  [ ] Container nach Deployment neu gestartet
  [ ] Health Check nach Deployment erfolgreich
```

## Fazit

Supabase Edge Functions sind ein leistungsfähiger Integrationspunkt, wenn sie als solcher eingesetzt werden: Webhooks empfangen, Signaturen prüfen, Events verarbeiten und weiterleiten.

Der entscheidende Punkt ist die Abgrenzung. Edge Functions sind kein zweites Backend neben Next.js und kein Job Runner neben Trigger.dev. Wer diese Grenze klar zieht und die Security-Basics umsetzt (Signaturen, Input Validation, korrekter Client, CORS), kann Edge Functions sicher im Self-Hosted Setup betreiben.

Die Kombination aus deterministischen Checks im CI und kontextueller Claude Code Analyse deckt sowohl bekannte Patterns als auch neue, unerwartete Risiken ab. Wer von Anfang an auf [Cert-Ready-by-Design](/de/magazin/cert-ready-by-design/) setzt, spart sich nachträgliche Audit-Runden.

<div class="not-prose my-12 border border-gosign-border bg-gosign-light rounded-card p-6 lg:p-8">
<div class="flex items-start gap-4">
<div class="flex-shrink-0 w-12 h-12 bg-gosign-dark rounded-card flex items-center justify-center">
<svg width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="white" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 15v4a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2v-4"/><polyline points="7 10 12 15 17 10"/><line x1="12" y1="15" x2="12" y2="3"/></svg>
</div>
<div>
<h2 class="text-h3 font-bold text-gosign-dark mb-2" id="audit-checkliste-als-download">Audit-Checkliste als Download</h2>
<p class="text-body text-gosign-text mb-2">Vorbereiteter Prompt für Claude Code. Laden Sie die Datei auf Ihren Server und starten Sie Claude Code im Projektverzeichnis Ihrer Edge Functions. Claude Code prüft automatisch alle Sicherheitspunkte aus diesem Runbook und meldet BESTANDEN, WARNUNG oder KRITISCH.</p>
<p class="text-sm text-gosign-text mb-4 font-mono">claude -p "$(cat claude-check-artikel-3-edge-functions.md)" --allowedTools Read,Grep,Glob,Bash</p>
<a href="/downloads/claude-check-artikel-3-edge-functions.md" download class="inline-flex items-center px-6 py-3 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-small uppercase tracking-wider">Checkliste herunterladen</a>
</div>
</div>
</div>

## Serien-Inhaltsverzeichnis

Dieser Artikel ist Teil unserer DevOps-Serie für self-hosted App-Stacks.

1. [Supabase Self-Hosting Runbook](/de/magazin/supabase-self-hosting/)
2. [Next.js über Supabase sicher betreiben](/de/magazin/nextjs-supabase-sicher-betreiben/)
3. [Supabase Edge Functions sicher einsetzen](/de/magazin/supabase-edge-functions-sicher/) - dieser Artikel
4. [Trigger.dev Background Jobs sicher betreiben](/de/magazin/trigger-dev-background-jobs/)
5. [Claude Code als Sicherheitskontrolle im DevOps-Workflow](/de/magazin/claude-code-security-devops/)
6. [Security Baseline für den gesamten Stack](/de/magazin/security-baseline-stack/)

Im nächsten Artikel zeigen wir, wie [Trigger.dev Background Jobs mit Idempotenz und Concurrency Limits sicher betrieben werden](/de/magazin/trigger-dev-background-jobs/#b2---idempotenz-sicherstellen), ohne neue Sicherheitsrisiken im Stack zu erzeugen.

--- Supabase Self-Hosting Runbook: sichere Architektur ---
> Supabase Self-Hosting Runbook: Hetzner-Setup, Docker Compose, Service-Architektur, Secrets, RLS und Backups.

Supabase selbst zu hosten ist technisch relativ einfach. Supabase **sicher und stabil zu betreiben** ist deutlich anspruchsvoller.

Der Grund: Supabase ist keine einzelne Datenbank, sondern eine komplette Backend-Plattform. Ein self-hosted Supabase-Stack besteht typischerweise aus mehreren Komponenten: PostgreSQL, PostgREST API, GoTrue Auth, Realtime Server, Storage, Kong API Gateway, Supabase Studio und optional Edge Functions.

Damit betreibt man faktisch eine **Backend-Plattform**, nicht nur eine Datenbank. Ähnliche Überlegungen gelten auch beim [Self-Hosting von Sprachmodellen](/de/magazin/llm-self-hosting-enterprise/).

Dieses Runbook beschreibt ein minimales Produktionssetup, das sicher betrieben werden kann und gleichzeitig automatisierbar bleibt. Jeder Schritt enthält eine konkrete Implementierung, eine prüfbare Bedingung und ein Failure Scenario.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Auf einen Blick - Artikel 1 von 6 der DevOps-Runbook-Serie</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Zwei-Server-Architektur trennt Produktionssystem und Audit-System physisch</li>
<li>Docker Compose mit versionsgepinnten Images (kein :latest)</li>
<li>Sieben Services: PostgreSQL, PostgREST, GoTrue, Kong, Realtime, Storage, Studio</li>
<li>Row Level Security auf allen public-Tabellen als Pflicht</li>
<li>Tägliche verschlüsselte Backups mit GPG, extern auf dem Audit-Server gespeichert</li>
</ul>
</div>

> **Hinweis zum Hoster:** Dieses Runbook verwendet **Hetzner Cloud (DE)** als Infrastruktur-Beispiel, weil Hetzner deutsche Rechenzentren bietet, nicht dem US Cloud Act unterliegt und ein gutes Preis-Leistungs-Verhältnis hat. Die Architekturprinzipien gelten aber **hosterunabhängig**. Die Hetzner-spezifischen Stellen (vSwitch, Cloud Firewall API, Robot Panel) lassen sich direkt auf andere EU-Anbieter übertragen: OVH vRack (FR), Netcup vLAN (DE), IONOS Cloud (DE), Scaleway Private Networks (FR). Für den brasilianischen Markt eignen sich Locaweb oder Magalu Cloud (beide BR). Wo ein Schritt Hetzner-spezifisch ist, weisen wir darauf hin.

## Serien-Inhaltsverzeichnis

Diese Anleitung ist Teil unserer DevOps-Runbook-Serie für moderne self-hosted App-Stacks.

1. [Supabase Self-Hosting Runbook](/de/magazin/supabase-self-hosting/) - dieser Artikel
2. [Next.js über Supabase sicher betreiben](/de/magazin/nextjs-supabase-sicher-betreiben/)
3. [Supabase Edge Functions sicher einsetzen](/de/magazin/supabase-edge-functions-sicher/)
4. [Trigger.dev Background Jobs sicher betreiben](/de/magazin/trigger-dev-background-jobs/)
5. [Claude Code als Sicherheitskontrolle im DevOps-Workflow](/de/magazin/claude-code-security-devops/)
6. [Security Baseline für den gesamten Stack](/de/magazin/security-baseline-stack/)

Artikel 1 behandelt **Infrastruktur, Services und Stack-Konfiguration**. Die folgenden Artikel bauen darauf auf.

## Zielarchitektur

Ein stabiles Setup trennt mindestens zwei Verantwortungsbereiche.

```
Internet
   |
   |  HTTPS (443)
   |
Reverse Proxy (Caddy / Nginx / Traefik)
   |
   |  TLS terminiert
   |
Kong API Gateway
   |
   +-- GoTrue         (Auth)
   +-- PostgREST       (API)
   +-- Realtime        (WebSocket)
   +-- Storage         (S3-kompatibler Object Store)
   |
PostgreSQL
   |
   +-- RLS Policies
```

Parallel dazu läuft ein zweites, getrenntes System:

```
Audit Server
   |
   +-- Security Checks    (Lynis, Trivy, Port Scans)
   +-- Drift Detection     (Config Diffs gegen Baseline)
   +-- Claude Code Review  (kontextuelle Analyse)
   +-- Monitoring          (Metriken, Alerts)
   +-- Backup Verification (Restore Tests)
```

Warum diese Trennung notwendig ist: Wenn Produktionssystem und Audit-System identisch sind, kann ein kompromittierter Server gleichzeitig auch seine eigenen Sicherheitschecks manipulieren.

Laut dem Verizon Data Breach Investigations Report 2024 gehen mehr als 60% aller Datenbank-bezogenen Sicherheitsvorfälle auf Fehlkonfigurationen und fehlende Zugriffskontrollen zurück.

## Teil A - Infrastruktur-Entscheidungen

Diese Entscheidungen werden einmal getroffen und bilden das Fundament für alles Weitere.

## A1 - Infrastruktur trennen: zwei Server

### Umsetzung

Mindestens zwei Server betreiben, physisch oder als separate VMs:

```
supabase-prod     (Hetzner Cloud CX32 oder höher)
audit-runner      (Hetzner Cloud CX22 reicht)
```

> **Hetzner-spezifisch:** In der Hetzner Cloud Console unter "Servers" zwei separate Instanzen anlegen, beide im selben Projekt und selben Standort (z.B. fsn1). Bei anderen Hostern: zwei VMs in derselben Region/Zone.

**supabase-prod** trägt den gesamten Supabase-Stack und PostgreSQL.
**audit-runner** trägt Security Checks, Monitoring, Drift Detection und Claude Code Analyse.

### Prüfbare Bedingung

```bash
# Beide Server müssen separate Hosts sein
ssh supabase-prod hostname
ssh audit-runner hostname

# Erwartung: unterschiedliche Hostnamen und IPs
```

### Failure Scenario

Wenn Audit und Produktion auf demselben Server laufen und ein Angreifer Root-Zugriff erlangt, kann er Logs löschen, Security-Check-Ergebnisse manipulieren und Alerts unterdrücken. Die Kompromittierung bleibt unentdeckt.

## A2 - Privates Netzwerk einrichten

### Umsetzung

Beide Server kommunizieren intern über ein privates Netzwerk. Supabase-Dienste sind nur über diese internen IPs erreichbar.

> **Hetzner-spezifisch:** Unter "Networks" einen vSwitch oder ein Cloud Network anlegen mit Subnetz `10.0.1.0/24`. Beide Server dem Netzwerk zuweisen. Hetzner legt automatisch ein Interface an (typisch `ens10`). Bei OVH: vRack mit privatem Netzwerk. Bei Netcup: vLAN. Bei IONOS: Cloud Network. Bei Scaleway: Private Networks.

```bash
# Auf beiden Servern das private Interface konfigurieren
# /etc/network/interfaces.d/60-private.cfg (Hetzner-spezifisch)

auto ens10
iface ens10 inet static
  address 10.0.1.10/24    # supabase-prod
  # address 10.0.1.11/24  # audit-runner
```

```bash
# Netzwerk aktivieren
systemctl restart networking

# Prüfen
ip addr show ens10
ping 10.0.1.11   # vom prod-Server aus
```

### Prüfbare Bedingung

```bash
# Vom audit-runner aus: internes Interface aktiv?
ssh audit-runner "ip addr show ens10 | grep 10.0.1.11"

# PostgreSQL darf nur intern lauschen
ssh supabase-prod "ss -tlnp | grep 5432"

# Erwartung: 10.0.1.10:5432, NICHT 0.0.0.0:5432
```

### Failure Scenario

Wenn PostgreSQL auf `0.0.0.0:5432` lauscht und die Firewall einen Fehler hat, ist die Datenbank direkt aus dem Internet erreichbar. Mit dem `service_role` Key oder einem schwachen Postgres-Passwort ist die gesamte Datenbank kompromittiert.

## A3 - Reverse Proxy mit TLS

### Umsetzung

Vor Kong sitzt ein Reverse Proxy, der TLS terminiert und als einziger Service von außen erreichbar ist. Caddy wird hier als Beispiel verwendet, weil es automatisches Let's Encrypt mitbringt.

```
# Caddyfile

app.example.com {
    reverse_proxy localhost:8000 {
        header_up X-Forwarded-Proto {scheme}
        header_up X-Real-IP {remote_host}
    }

    header {
        X-Frame-Options "DENY"
        X-Content-Type-Options "nosniff"
        Referrer-Policy "strict-origin-when-cross-origin"
        Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
        -Server
    }
}
```

Alternativ mit Nginx:

```nginx
server {
    listen 443 ssl http2;
    server_name app.example.com;

    ssl_certificate /etc/letsencrypt/live/app.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/app.example.com/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;

    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # WebSocket Support für Realtime
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}
```

### Prüfbare Bedingung

```bash
# TLS aktiv und korrekt konfiguriert?
curl -I https://app.example.com

# Erwartung: HTTP/2 200, Strict-Transport-Security Header vorhanden

# TLS Version prüfen
openssl s_client -connect app.example.com:443 -tls1_2 </dev/null 2>&1 | grep "Protocol"

# Zertifikat Ablaufdatum
echo | openssl s_client -connect app.example.com:443 2>/dev/null | \
  openssl x509 -noout -enddate

# Erwartung: notAfter mindestens 14 Tage in der Zukunft

# Security Headers vorhanden?
curl -sI https://app.example.com | grep -E \
  "X-Frame-Options|Strict-Transport-Security|X-Content-Type-Options"
```

### Failure Scenario

Ohne TLS laufen Auth-Tokens im Klartext über das Netzwerk. Jeder im selben Netzwerksegment kann sie mitlesen (Man-in-the-Middle). Ohne automatisches Zertifikats-Renewal läuft das Zertifikat nach 90 Tagen ab und die App ist nicht mehr erreichbar.

## A4 - Firewall doppelt setzen

### Umsetzung

Zwei Ebenen, die sich gegenseitig absichern:

**Ebene 1: Cloud Firewall (vor dem Server)**

> **Hetzner-spezifisch:** Unter "Firewalls" eine neue Firewall anlegen und beiden Servern zuweisen. Bei OVH: Firewall Network. Bei Netcup: SCP Firewall. Bei IONOS: Cloud Firewall. Bei Scaleway: Security Groups.

```
# Hetzner Cloud Firewall Regeln für supabase-prod

Inbound:
  TCP 443    von 0.0.0.0/0        (HTTPS)
  TCP 22     von ADMIN_IP/32       (SSH nur von Admin)
  TCP ALL    von 10.0.1.0/24       (internes Netzwerk)

Outbound:
  ALL        nach 0.0.0.0/0        (Updates, DNS, Let's Encrypt)
```

**Ebene 2: Host Firewall (auf dem Server)**

```bash
# /etc/iptables/rules.v4

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]

# Loopback
-A INPUT -i lo -j ACCEPT

# Established Connections
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# SSH nur von Admin IP
-A INPUT -p tcp --dport 22 -s ADMIN_IP -j ACCEPT

# HTTPS
-A INPUT -p tcp --dport 443 -j ACCEPT

# Internes Netzwerk (alle Ports)
-A INPUT -s 10.0.1.0/24 -j ACCEPT

# Alles andere droppen (Default Policy)
COMMIT
```

```bash
# Firewall aktivieren
apt install iptables-persistent
iptables-restore < /etc/iptables/rules.v4

# Baseline speichern für Drift Detection
iptables-save > /root/firewall-baseline.txt
```

### Prüfbare Bedingung

```bash
# Von außen: nur 443 offen
nmap -p 22,80,443,5432,8000,9000 app.example.com

# Erwartung: nur 443 open (22 nur von Admin-IP)

# Auf dem Server: Regeln aktiv?
iptables -L -n | grep -c "DROP"

# Erwartung: mindestens 1 (Default DROP Policy)

# Drift Detection: hat sich die Firewall geändert?
iptables-save | diff /root/firewall-baseline.txt -

# Erwartung: keine Abweichungen
```

### Failure Scenario

Eine einzelne Firewall kann falsch konfiguriert werden. Ein `iptables -F` (flush) auf dem Server öffnet alle Ports, wenn keine Cloud Firewall existiert. Umgekehrt schützt eine Cloud Firewall nicht vor Prozessen die auf dem Server selbst neue Ports öffnen, wenn kein Host Firewall aktiv ist.

## A5 - SSH-Zugriff absichern

### Umsetzung

```bash
# /etc/ssh/sshd_config

PasswordAuthentication no
PermitRootLogin no
PubkeyAuthentication yes
MaxAuthTries 3
LoginGraceTime 30
AllowUsers deploy
```

```bash
# SSH Key auf dem Server hinterlegen
mkdir -p /home/deploy/.ssh
echo "ssh-ed25519 AAAA... admin@workstation" > /home/deploy/.ssh/authorized_keys
chmod 700 /home/deploy/.ssh
chmod 600 /home/deploy/.ssh/authorized_keys
chown -R deploy:deploy /home/deploy/.ssh

# SSHD neu laden
systemctl reload sshd
```

### Prüfbare Bedingung

```bash
# Passwort-Login muss fehlschlagen
ssh -o PasswordAuthentication=yes -o PubkeyAuthentication=no deploy@app.example.com

# Erwartung: Permission denied

# Root-Login muss fehlschlagen
ssh root@app.example.com

# Erwartung: Permission denied

# Konfiguration prüfen
sshd -T | grep -E "passwordauthentication|permitrootlogin"

# Erwartung: passwordauthentication no, permitrootlogin no
```

### Failure Scenario

Passwortbasierte SSH-Zugänge werden kontinuierlich aus dem Internet angegriffen (Brute Force). Ein schwaches Passwort wird typischerweise innerhalb von Stunden gefunden. Root-Login bedeutet, dass ein Angreifer sofort volle Kontrolle über den Server hat.

## Teil B - Supabase Services einrichten und absichern

Ein self-hosted Supabase-Stack besteht aus über 10 Services. Jeder hat eigene Environment Variables, eigene Datenbankrollen und eigene Sicherheitsanforderungen. Die offizielle `docker-compose.yml` von Supabase ist über 400 Zeilen lang und enthält viele Settings, die nicht offensichtlich sicherheitsrelevant sind, es aber trotzdem sind.

Dieser Abschnitt erklärt jeden Service, seine Rolle, seine sicherheitsrelevante Konfiguration und die typischen Fehler beim Setup.

### Service-Übersicht

```
Internet
   │
   │  HTTPS (443)
   │
Reverse Proxy (Caddy/Nginx)     ← Teil A3
   │
Kong (API Gateway)               ← routet zu allen Services
   │
   ├── GoTrue (Auth)              ← /auth/v1/*
   ├── PostgREST (REST API)       ← /rest/v1/*
   ├── Realtime                   ← /realtime/v1/*
   ├── Storage API                ← /storage/v1/*
   ├── Edge Functions             ← /functions/v1/*
   ├── Studio (Dashboard)         ← / (geschützt mit Basic Auth)
   │
   ├── Meta (Postgres-Meta)       ← intern, für Studio
   ├── ImgProxy                   ← intern, für Storage
   ├── Analytics (Logflare)       ← intern, für Logs
   ├── Vector                     ← intern, Log-Pipeline
   └── Supavisor (Pooler)         ← Connection Pooling
   │
PostgreSQL                        ← Datenbank mit Init-Scripts
   │
   └── Rollen: anon, authenticated, service_role,
       authenticator, supabase_admin, supabase_auth_admin,
       supabase_storage_admin
```

### Supabase Service-Übersicht

| Service | Port | Funktion | Sicherheitskritische Konfiguration |
|---------|------|----------|------------------------------------|
| PostgreSQL | 5432 | Datenbank | Nur internes Interface (10.0.1.10), RLS auf allen public-Tabellen |
| PostgREST | 3000 | REST API | Nur über Kong erreichbar, JWT-Validierung |
| GoTrue | 9999 | Authentifizierung | JWT-Expiry max. 3600s, Refresh Token Rotation |
| Kong | 8000 | API Gateway | Einziger Einstiegspunkt, Rate Limiting |
| Realtime | 4000 | WebSocket | RLS-basierte Autorisierung |
| Storage | 5000 | Dateispeicher | Bucket Policies, keine öffentlichen Buckets |
| Studio | 3000 | Admin UI | Nicht extern erreichbar, nur SSH-Tunnel |

## B0 - Secrets generieren (vor dem ersten Start)

**Das muss VOR dem Start aller Services passieren.** Die offizielle `.env.example` enthält Platzhalter. Diese müssen durch generierte Werte ersetzt werden.

```bash
# JWT Secret (wird von GoTrue, PostgREST, Realtime, Kong gemeinsam genutzt)
JWT_SECRET=$(openssl rand -base64 32)

# Postgres Passwort
POSTGRES_PASSWORD=$(openssl rand -base64 24)

# Dashboard Passwort (Basic Auth über Kong)
DASHBOARD_PASSWORD=$(openssl rand -base64 16)

# Logflare Tokens
LOGFLARE_PUBLIC_ACCESS_TOKEN=$(openssl rand -hex 16)
LOGFLARE_PRIVATE_ACCESS_TOKEN=$(openssl rand -hex 16)

# MinIO Root Passwort (falls S3 Storage genutzt)
MINIO_ROOT_PASSWORD=$(openssl rand -hex 16)

# Realtime Secret Key Base (min. 64 Zeichen)
SECRET_KEY_BASE=$(openssl rand -base64 48)

# Supavisor Vault Encryption Key
VAULT_ENC_KEY=$(openssl rand -base64 24)

# PG Meta Crypto Key
PG_META_CRYPTO_KEY=$(openssl rand -base64 24)

# Anon Key und Service Role Key (JWTs, generiert mit dem JWT_SECRET)
# Nutze https://supabase.com/docs/guides/self-hosting/docker#generate-api-keys
# oder generiere sie manuell mit jwt.io und dem JWT_SECRET
```

**Sicherheitsregel:** Alle Secrets landen in der `.env` Datei auf dem Server (Rechte 600, nicht im Git). Supabase nutzt ein einziges `JWT_SECRET` für alle Services. Wenn dieses Secret kompromittiert ist, sind GoTrue, PostgREST und Realtime gleichzeitig betroffen.

### Prüfbare Bedingung

```bash
# Alle erforderlichen Secrets gesetzt?
for var in JWT_SECRET POSTGRES_PASSWORD ANON_KEY SERVICE_ROLE_KEY \
  DASHBOARD_PASSWORD LOGFLARE_PUBLIC_ACCESS_TOKEN SECRET_KEY_BASE \
  VAULT_ENC_KEY PG_META_CRYPTO_KEY; do
  if grep -q "^${var}=$\|^${var}=your-\|^${var}=change" .env 2>/dev/null; then
    echo "KRITISCH: $var ist nicht gesetzt oder hat Default-Wert"
  fi
done

# Keine identischen Passwörter?
PASSWORDS=$(grep -E "PASSWORD|SECRET|KEY" .env | cut -d= -f2 | sort)
UNIQUE=$(echo "$PASSWORDS" | sort -u)
if [ "$(echo "$PASSWORDS" | wc -l)" != "$(echo "$UNIQUE" | wc -l)" ]; then
  echo "WARNUNG: Einige Secrets haben identische Werte"
fi
```

### Failure Scenario

Default-Secrets aus der `.env.example` sind öffentlich bekannt. Ein Angreifer kann mit dem Default `JWT_SECRET` gültige Tokens generieren und erhält vollen Zugriff auf die API. Mit dem Default `SERVICE_ROLE_KEY` umgeht er zusätzlich alle RLS-Policies.

## B1 - PostgreSQL: Datenbank und Rollen

### Was dieser Service macht

PostgreSQL ist die zentrale Datenbank. Im Supabase-Kontext hat sie eine besondere Rolle: Sie speichert nicht nur Applikationsdaten, sondern auch Auth-Daten (GoTrue), Realtime-Konfiguration, Storage-Metadaten und Analytics-Logs. Die Init-Scripts erstellen spezielle Schemas und Rollen.

### Sicherheitsrelevante Konfiguration

```yaml
db:
  image: supabase/postgres:15.8.1.085    # Supabase-eigenes Image, Version pinnen
  restart: unless-stopped
  ports:
    - "10.0.1.10:5432:5432"              # NUR internes Interface
  volumes:
    # Init-Scripts (erstellen Schemas, Rollen, Extensions)
    - ./volumes/db/realtime.sql:/docker-entrypoint-initdb.d/migrations/99-realtime.sql:Z
    - ./volumes/db/webhooks.sql:/docker-entrypoint-initdb.d/init-scripts/98-webhooks.sql:Z
    - ./volumes/db/roles.sql:/docker-entrypoint-initdb.d/init-scripts/99-roles.sql:Z
    - ./volumes/db/jwt.sql:/docker-entrypoint-initdb.d/init-scripts/99-jwt.sql:Z
    - ./volumes/db/_supabase.sql:/docker-entrypoint-initdb.d/migrations/97-_supabase.sql:Z
    - ./volumes/db/logs.sql:/docker-entrypoint-initdb.d/migrations/99-logs.sql:Z
    - ./volumes/db/pooler.sql:/docker-entrypoint-initdb.d/migrations/99-pooler.sql:Z
    # Persistente Daten
    - ./volumes/db/data:/var/lib/postgresql/data:Z
    - db-config:/etc/postgresql-custom
  healthcheck:
    test: ["CMD", "pg_isready", "-U", "postgres", "-h", "localhost"]
    interval: 5s
    timeout: 5s
    retries: 10
  environment:
    POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    POSTGRES_DB: ${POSTGRES_DB}
    JWT_SECRET: ${JWT_SECRET}
    JWT_EXP: ${JWT_EXPIRY}
```

**Die Init-Scripts erstellen folgende Rollen:**

```
postgres              → Superuser (nur für Admin, nie für Services)
anon                  → Unauthentifizierte Requests (über PostgREST)
authenticated         → Authentifizierte Requests (über PostgREST)
service_role          → Umgeht RLS (für Admin-Operationen)
authenticator         → PostgREST nutzt diese Rolle zum Verbinden
supabase_admin        → Interne Admin-Rolle (Realtime, Analytics)
supabase_auth_admin   → GoTrue-spezifisch (auth Schema)
supabase_storage_admin → Storage-spezifisch (storage Schema)
```

### Was schiefgehen kann

Die `roles.sql` definiert die Grants für jede Rolle. Wenn diese Datei modifiziert wird (z.B. um schnell ein Problem zu lösen), können Rollen zu viele Rechte bekommen. Die `anon`-Rolle darf nur die Rechte haben, die RLS-Policies explizit erlauben.

### Prüfbare Bedingung

```bash
# Rollen und ihre Rechte prüfen
docker compose exec -T db psql -U postgres -c \
  "SELECT rolname, rolsuper, rolcreaterole, rolcreatedb, rolcanlogin
   FROM pg_roles
   WHERE rolname IN ('anon','authenticated','service_role','authenticator',
     'supabase_admin','supabase_auth_admin','supabase_storage_admin')
   ORDER BY rolname;"

# anon darf NICHT superuser sein
docker compose exec -T db psql -U postgres -c \
  "SELECT rolname, rolsuper FROM pg_roles WHERE rolname = 'anon' AND rolsuper = true;"
# Erwartung: keine Zeilen

# Postgres lauscht NUR intern
ss -tlnp | grep 5432
# Erwartung: 10.0.1.10:5432, NICHT 0.0.0.0:5432
```

## B2 - Kong: API Gateway und Routing

### Was dieser Service macht

Kong ist der zentrale Einstiegspunkt für alle API-Requests. Er routet basierend auf dem URL-Pfad an die richtigen Services, handhabt JWT-Validierung und schützt das Studio-Dashboard mit Basic Auth.

### Sicherheitsrelevante Konfiguration

```yaml
kong:
  image: kong:2.8.1                       # Version pinnen
  restart: unless-stopped
  ports:
    - "127.0.0.1:8000:8000"              # NUR localhost (Reverse Proxy davor)
    - "127.0.0.1:8443:8443"              # HTTPS intern
  volumes:
    - ./volumes/api/kong.yml:/home/kong/temp.yml:ro,z
  environment:
    KONG_DATABASE: "off"                   # Deklarative Config, keine DB
    KONG_DECLARATIVE_CONFIG: /home/kong/kong.yml
    KONG_DNS_ORDER: LAST,A,CNAME
    KONG_PLUGINS: request-transformer,cors,key-auth,acl,basic-auth,request-termination,ip-restriction
    SUPABASE_ANON_KEY: ${ANON_KEY}
    SUPABASE_SERVICE_KEY: ${SERVICE_ROLE_KEY}
    DASHBOARD_USERNAME: ${DASHBOARD_USERNAME}
    DASHBOARD_PASSWORD: ${DASHBOARD_PASSWORD}
  entrypoint: bash -c 'eval "echo \"$$(cat ~/temp.yml)\"" > ~/kong.yml && /docker-entrypoint.sh kong docker-start'
```

**Die `kong.yml` definiert das Routing:**

```
/rest/v1/*        → PostgREST (port 3000)    + JWT Validation
/auth/v1/*        → GoTrue (port 9999)       + JWT Validation
/realtime/v1/*    → Realtime (port 4000)      + JWT Validation
/storage/v1/*     → Storage (port 5000)       + JWT Validation
/functions/v1/*   → Edge Functions (port 54321) + JWT Validation (optional)
/                 → Studio (port 3000)        + Basic Auth
```

### Was schiefgehen kann

Kong auf `0.0.0.0:8000` statt `127.0.0.1:8000` bedeutet, dass die API ohne Reverse Proxy (ohne TLS) direkt erreichbar ist. Ein schwaches Dashboard-Passwort gibt über Basic Auth Zugang zum Studio und damit zur gesamten Datenbank. Die `kong.yml` kann so konfiguriert werden, dass JWT-Validierung für bestimmte Routes deaktiviert ist.

### Prüfbare Bedingung

```bash
# Kong nur auf localhost?
ss -tlnp | grep 8000
# Erwartung: 127.0.0.1:8000

# Dashboard-Passwort stark genug?
DASH_PW_LEN=$(grep "DASHBOARD_PASSWORD" .env | cut -d= -f2 | wc -c)
[ "$DASH_PW_LEN" -lt 16 ] && echo "WARNUNG: Dashboard-Passwort zu kurz"

# kong.yml: JWT Validation aktiv auf allen API-Routes?
grep -A5 "key-auth" volumes/api/kong.yml | head -20
```

## B3 - GoTrue: Authentifizierung

### Was dieser Service macht

GoTrue handhabt User-Registrierung, Login, Magic Links, OAuth, MFA und Token-Ausgabe. Es ist der einzige Service der JWTs ausstellt und hat einen eigenen DB-User (`supabase_auth_admin`) mit Zugriff auf das `auth` Schema.

### Sicherheitsrelevante Konfiguration

```yaml
auth:
  image: supabase/gotrue:v2.184.0       # Version pinnen
  restart: unless-stopped
  environment:
    GOTRUE_API_HOST: 0.0.0.0
    GOTRUE_API_PORT: 9999
    API_EXTERNAL_URL: ${API_EXTERNAL_URL}    # https://app.example.com

    # Datenbank (eigener Admin-User)
    GOTRUE_DB_DATABASE_URL: postgres://supabase_auth_admin:${POSTGRES_PASSWORD}@${POSTGRES_HOST}:${POSTGRES_PORT}/${POSTGRES_DB}

    # JWT
    GOTRUE_JWT_SECRET: ${JWT_SECRET}
    GOTRUE_JWT_EXP: ${JWT_EXPIRY}            # MAXIMAL 3600 (1 Stunde)
    GOTRUE_JWT_AUD: authenticated
    GOTRUE_JWT_ADMIN_ROLES: service_role
    GOTRUE_JWT_DEFAULT_GROUP_NAME: authenticated

    # Registrierung
    GOTRUE_DISABLE_SIGNUP: ${DISABLE_SIGNUP}  # true wenn geschlossene App
    GOTRUE_EXTERNAL_EMAIL_ENABLED: ${ENABLE_EMAIL_SIGNUP}
    GOTRUE_MAILER_AUTOCONFIRM: false          # IMMER false in Produktion

    # SMTP (für Magic Links, E-Mail-Bestätigung)
    GOTRUE_SMTP_HOST: ${SMTP_HOST}
    GOTRUE_SMTP_PORT: ${SMTP_PORT}
    GOTRUE_SMTP_USER: ${SMTP_USER}
    GOTRUE_SMTP_PASS: ${SMTP_PASS}
    GOTRUE_SMTP_ADMIN_EMAIL: ${SMTP_ADMIN_EMAIL}
    GOTRUE_SMTP_SENDER_NAME: ${SMTP_SENDER_NAME}

    # Mailer URL-Pfade (müssen zum Kong-Routing passen)
    GOTRUE_MAILER_URLPATHS_CONFIRMATION: "/auth/v1/verify"
    GOTRUE_MAILER_URLPATHS_INVITE: "/auth/v1/verify"
    GOTRUE_MAILER_URLPATHS_RECOVERY: "/auth/v1/verify"
    GOTRUE_MAILER_URLPATHS_EMAIL_CHANGE: "/auth/v1/verify"

    # Site URL (Redirect nach Auth)
    GOTRUE_SITE_URL: ${SITE_URL}              # URL eurer Next.js App
    GOTRUE_URI_ALLOW_LIST: ${ADDITIONAL_REDIRECT_URLS}

    # Refresh Token Rotation (verhindert Token Reuse)
    GOTRUE_SECURITY_REFRESH_TOKEN_ROTATION_ENABLED: true
    GOTRUE_SECURITY_REFRESH_TOKEN_REUSE_INTERVAL: 10
```

### SMTP-Konfiguration: Warum sie sicherheitsrelevant ist

Ohne funktionierenden SMTP-Server können keine Bestätigungs-E-Mails versendet werden. Wenn `GOTRUE_MAILER_AUTOCONFIRM: true` gesetzt ist, um das zu umgehen, kann sich jeder mit einer beliebigen E-Mail-Adresse registrieren. Das bedeutet: keine Verifizierung der Identität.

### Prüfbare Bedingung

```bash
# GoTrue Health Check
docker compose exec -T auth wget --no-verbose --tries=1 --spider http://localhost:9999/health

# JWT Expiry nicht über 3600?
grep "JWT_EXPIRY\|JWT_EXP" .env | head -1
# Erwartung: 3600 oder weniger

# Autoconfirm deaktiviert?
grep "AUTOCONFIRM" .env
# Erwartung: false

# SMTP konfiguriert (nicht leer)?
for var in SMTP_HOST SMTP_PORT SMTP_USER SMTP_PASS; do
  VAL=$(grep "^${var}=" .env | cut -d= -f2)
  [ -z "$VAL" ] && echo "WARNUNG: $var ist leer"
done

# Refresh Token Rotation aktiv?
grep "REFRESH_TOKEN_ROTATION" .env docker-compose.yml 2>/dev/null
# Erwartung: true
```

### Failure Scenario

Mit `AUTOCONFIRM=true` und `DISABLE_SIGNUP=false` kann jeder einen Account erstellen und sofort nutzen, ohne die E-Mail-Adresse zu bestätigen. Ein Angreifer kann sich mit beliebigen Adressen registrieren und hat sofort die `authenticated` Rolle in der Datenbank. Ohne Refresh Token Rotation kann ein gestohlener Refresh Token dauerhaft verwendet werden.

## B4 - PostgREST: REST API

### Was dieser Service macht

PostgREST generiert automatisch eine REST API aus dem PostgreSQL-Schema. Es ist der Hauptzugangspunkt für Daten. Sicherheit liegt primär in den PostgreSQL-Rollen und RLS-Policies, nicht in PostgREST selbst.

### Sicherheitsrelevante Konfiguration

```yaml
rest:
  image: postgrest/postgrest:v14.1       # Version pinnen
  restart: unless-stopped
  environment:
    PGRST_DB_URI: postgres://authenticator:${POSTGRES_PASSWORD}@${POSTGRES_HOST}:${POSTGRES_PORT}/${POSTGRES_DB}
    PGRST_DB_SCHEMAS: ${PGRST_DB_SCHEMAS}   # public,storage,graphql_public
    PGRST_DB_ANON_ROLE: anon
    PGRST_JWT_SECRET: ${JWT_SECRET}
    PGRST_DB_USE_LEGACY_GUCS: "false"
    PGRST_APP_SETTINGS_JWT_SECRET: ${JWT_SECRET}
    PGRST_APP_SETTINGS_JWT_EXP: ${JWT_EXPIRY}
```

**Wie PostgREST mit den Rollen arbeitet:**

```
Request ohne JWT     → PostgREST nutzt Rolle "anon"
Request mit JWT      → PostgREST wechselt zu Rolle aus JWT (z.B. "authenticated")
Request mit service_role JWT → PostgREST nutzt "service_role" (umgeht RLS)
```

Der `authenticator`-User verbindet sich zur DB und wechselt per `SET ROLE` zur jeweiligen Rolle. Das bedeutet: Die Grants auf den Rollen `anon` und `authenticated` sind die eigentliche Sicherheitsschicht.

### Prüfbare Bedingung

```bash
# PostgREST nutzt authenticator-Rolle (nicht postgres)?
grep "PGRST_DB_URI" docker-compose.yml | grep "authenticator"
# Erwartung: Ja

# Schemas explizit definiert (nicht alle)?
grep "PGRST_DB_SCHEMAS" .env
# Erwartung: public,storage,graphql_public (nicht leer = alle Schemas)
```

### Failure Scenario

Wenn `PGRST_DB_URI` den `postgres` Superuser statt `authenticator` verwendet, hat jeder Request Superuser-Rechte, RLS ist wirkungslos. Wenn `PGRST_DB_SCHEMAS` leer ist, exponiert PostgREST alle Schemas inklusive interner Supabase-Schemas (`auth`, `_realtime`, `_analytics`).

## B5 - Realtime: WebSocket Subscriptions

### Was dieser Service macht

Realtime ermöglicht WebSocket-basierte Subscriptions auf Datenbankänderungen. Es nutzt den `supabase_admin` User und das `_realtime` Schema.

### Sicherheitsrelevante Konfiguration

```yaml
realtime:
  container_name: realtime-dev.supabase-realtime   # Name ist relevant für Tenant-ID
  image: supabase/realtime:v2.68.0
  restart: unless-stopped
  environment:
    PORT: 4000
    DB_HOST: ${POSTGRES_HOST}
    DB_PORT: ${POSTGRES_PORT}
    DB_USER: supabase_admin
    DB_PASSWORD: ${POSTGRES_PASSWORD}
    DB_NAME: ${POSTGRES_DB}
    DB_AFTER_CONNECT_QUERY: 'SET search_path TO _realtime'
    DB_ENC_KEY: supabaserealtime          # ÄNDERN in Produktion
    API_JWT_SECRET: ${JWT_SECRET}
    SECRET_KEY_BASE: ${SECRET_KEY_BASE}   # min. 64 Zeichen
    SEED_SELF_HOST: "true"
    RUN_JANITOR: "true"
```

### Was schiefgehen kann

`DB_ENC_KEY: supabaserealtime` ist ein Standardwert. In Produktion muss er geändert werden. `SECRET_KEY_BASE` muss mindestens 64 Zeichen haben, sonst startet der Service nicht oder ist unsicher. Realtime nutzt `supabase_admin`, was bedeutet, dass es intern vollen DB-Zugriff hat. Die Sicherheit liegt in der JWT-Validierung: Nur authentifizierte User können Subscriptions öffnen, und RLS bestimmt welche Rows sie sehen.

### Prüfbare Bedingung

```bash
# DB_ENC_KEY nicht auf Default?
grep "DB_ENC_KEY" docker-compose.yml
# NICHT "supabaserealtime"

# SECRET_KEY_BASE lang genug?
SKB_LEN=$(grep "SECRET_KEY_BASE" .env | cut -d= -f2 | wc -c)
[ "$SKB_LEN" -lt 64 ] && echo "KRITISCH: SECRET_KEY_BASE zu kurz ($SKB_LEN Zeichen)"

# Realtime Health Check
docker compose exec -T realtime-dev.supabase-realtime \
  curl -sSf -H "Authorization: Bearer ${ANON_KEY}" \
  http://localhost:4000/api/tenants/realtime-dev/health
```

## B6 - Storage API und MinIO (S3)

### Was dieser Service macht

Storage verwaltet Datei-Uploads und Downloads. Standardmässig speichert es Dateien lokal im Volume. Für Produktion empfiehlt sich ein S3-kompatibles Backend (MinIO self-hosted oder ein Cloud-Act-freier S3-Service).

### Lokales Storage (Standard)

```yaml
storage:
  image: supabase/storage-api:v1.33.0
  restart: unless-stopped
  volumes:
    - ./volumes/storage:/var/lib/storage:z
  environment:
    ANON_KEY: ${ANON_KEY}
    SERVICE_KEY: ${SERVICE_ROLE_KEY}
    POSTGREST_URL: http://rest:3000
    PGRST_JWT_SECRET: ${JWT_SECRET}
    DATABASE_URL: postgres://supabase_storage_admin:${POSTGRES_PASSWORD}@${POSTGRES_HOST}:${POSTGRES_PORT}/${POSTGRES_DB}
    STORAGE_BACKEND: file
    FILE_STORAGE_BACKEND_PATH: /var/lib/storage
    FILE_SIZE_LIMIT: 52428800              # 50MB, anpassen
    ENABLE_IMAGE_TRANSFORMATION: "true"
    IMGPROXY_URL: http://imgproxy:5001
```

### MinIO für S3-Backend (Produktion)

Wenn ihr MinIO nutzt, kommt ein zusätzlicher Service dazu:

```yaml
# docker-compose.s3.yml (zusätzlich zur Haupt-Compose)
minio:
  image: minio/minio:latest              # Version pinnen in Produktion
  restart: unless-stopped
  ports:
    - "127.0.0.1:9000:9000"              # API, NUR localhost
    - "127.0.0.1:9001:9001"              # Console, NUR localhost
  volumes:
    - minio-data:/data
  environment:
    MINIO_ROOT_USER: ${MINIO_ROOT_USER}
    MINIO_ROOT_PASSWORD: ${MINIO_ROOT_PASSWORD}   # min. 8 Zeichen
  command: server /data --console-address ":9001"
```

Dann in der Storage-Konfiguration:

```yaml
storage:
  environment:
    STORAGE_BACKEND: s3
    GLOBAL_S3_BUCKET: supabase-storage
    GLOBAL_S3_ENDPOINT: http://minio:9000
    GLOBAL_S3_FORCE_PATH_STYLE: "true"
    AWS_ACCESS_KEY_ID: ${MINIO_ACCESS_KEY}
    AWS_SECRET_ACCESS_KEY: ${MINIO_SECRET_KEY}
    REGION: eu-central-1
```

### Prüfbare Bedingung

```bash
# Storage Health Check
docker compose exec -T storage wget --no-verbose --tries=1 --spider http://localhost:5000/status

# MinIO nicht von aussen erreichbar (wenn genutzt)?
ss -tlnp | grep 9000
# Erwartung: 127.0.0.1:9000 (nicht 0.0.0.0)

# MinIO Default-Credentials?
grep "MINIO_ROOT" .env | grep -iE "minioadmin\|minio123\|admin"
# Erwartung: keine Treffer

# Storage Volume existiert und hat Daten?
ls -la volumes/storage/ 2>/dev/null | head -5

# Storage Bucket Policies (über MinIO Client)
# mc alias set local http://localhost:9000 $MINIO_ROOT_USER $MINIO_ROOT_PASSWORD
# mc admin policy ls local
```

### Failure Scenario

MinIO mit Default-Credentials (`minioadmin:minioadmin`) auf `0.0.0.0:9000` bedeutet: Jeder im Internet kann alle Dateien lesen und schreiben. Die MinIO Console auf Port 9001 gibt zusätzlich eine Web-UI für volle Verwaltung. Storage Bucket Policies können "public" gesetzt sein, was bedeutet, dass Dateien ohne Auth zugänglich sind.

## B7 - Analytics, Vector und Supavisor (interne Services)

### Was diese Services machen

Diese Services sind nicht direkt von aussen erreichbar, aber sie sind sicherheitsrelevant weil sie privilegierten Datenbankzugriff haben.

**Analytics (Logflare):** Sammelt und speichert Logs aller Services. Nutzt `supabase_admin` und das `_analytics` Schema.

**Vector:** Log-Pipeline die Docker-Logs an Logflare weiterleitet. Hat Zugriff auf den Docker Socket.

**Supavisor:** Connection Pooler für PostgreSQL. Verwaltet den Verbindungspool und hat `supabase_admin` Zugriff.

### Sicherheitsrelevante Konfiguration

```yaml
analytics:
  image: supabase/logflare:1.27.0
  ports:
    - "127.0.0.1:4000:4000"             # NUR localhost
  environment:
    DB_USERNAME: supabase_admin
    DB_PASSWORD: ${POSTGRES_PASSWORD}
    LOGFLARE_PUBLIC_ACCESS_TOKEN: ${LOGFLARE_PUBLIC_ACCESS_TOKEN}
    LOGFLARE_PRIVATE_ACCESS_TOKEN: ${LOGFLARE_PRIVATE_ACCESS_TOKEN}

vector:
  image: timberio/vector:0.28.1-alpine
  volumes:
    - ${DOCKER_SOCKET_LOCATION}:/var/run/docker.sock:ro,z   # Read-Only!
  security_opt:
    - "label=disable"

supavisor:
  image: supabase/supavisor:2.7.4
  ports:
    - "10.0.1.10:5432:5432"             # Pooler exponiert Postgres-Port
    - "127.0.0.1:6543:6543"             # Transaction Mode
  environment:
    DATABASE_URL: ecto://supabase_admin:${POSTGRES_PASSWORD}@${POSTGRES_HOST}:${POSTGRES_PORT}/_supabase
    SECRET_KEY_BASE: ${SECRET_KEY_BASE}
    VAULT_ENC_KEY: ${VAULT_ENC_KEY}
    POOLER_DEFAULT_POOL_SIZE: ${POOLER_DEFAULT_POOL_SIZE}
    POOLER_MAX_CLIENT_CONN: ${POOLER_MAX_CLIENT_CONN}
```

### Was schiefgehen kann

Vector mit Docker Socket Zugriff (`/var/run/docker.sock`) kann Container-Logs lesen. Der Socket sollte **Read-Only** gemountet sein (`:ro`). Analytics auf Port 4000 mit Default-Tokens exponiert Logs aller Services. Supavisor auf `0.0.0.0:5432` statt dem internen Interface macht den Connection Pooler (und damit PostgreSQL) von aussen erreichbar.

### Prüfbare Bedingung

```bash
# Analytics nur intern?
ss -tlnp | grep 4000
# Erwartung: 127.0.0.1:4000

# Vector Docker Socket Read-Only?
grep "docker.sock" docker-compose.yml | grep ":ro"
# Erwartung: :ro vorhanden

# Supavisor Port nur intern?
ss -tlnp | grep 5432
# Erwartung: 10.0.1.10:5432 (internes Interface)

# Logflare Tokens nicht auf Default?
grep "LOGFLARE.*TOKEN" .env | grep -iE "your-\|change\|example"
# Erwartung: keine Treffer
```

## B8 - Studio: Dashboard absichern

### Was dieser Service macht

Studio ist die Web-UI für Datenbankmanagement, User-Verwaltung und SQL-Abfragen. Es hat über den `SERVICE_ROLE_KEY` und direkten Postgres-Zugang **vollen Zugriff auf alles**.

### Sicherheitsrelevante Konfiguration

Studio wird über Kong mit Basic Auth geschützt (DASHBOARD_USERNAME/DASHBOARD_PASSWORD). Zusätzlich sollte Studio in Produktion entweder gar nicht laufen oder nur über SSH Tunnel erreichbar sein.

**Option 1: Studio nicht in Produktion starten (empfohlen)**

```yaml
# In docker-compose.override.yml oder Studio aus dem Compose entfernen
# Studio nur lokal mit supabase start für Entwicklung nutzen
```

**Option 2: Studio nur über SSH Tunnel**

```bash
# Von der Workstation aus:
ssh -L 3000:localhost:3000 deploy@supabase-prod

# Dann im Browser: http://localhost:3000
```

### Prüfbare Bedingung

```bash
# Studio Container läuft? (Sollte in Produktion nicht laufen)
docker compose ps | grep studio
# Empfehlung: nicht running in Produktion

# Wenn Studio läuft: nicht von aussen erreichbar?
curl -s -o /dev/null -w "%{http_code}" --connect-timeout 3 \
  "https://app.example.com:3000" 2>/dev/null
# Erwartung: Timeout oder Connection Refused

# Dashboard-Passwort stark?
DASH_LEN=$(grep "DASHBOARD_PASSWORD" .env | cut -d= -f2 | wc -c)
[ "$DASH_LEN" -lt 16 ] && echo "WARNUNG: Dashboard-Passwort zu kurz"
```

### Failure Scenario

Studio mit schwachem Dashboard-Passwort und öffentlichem Zugang gibt einem Angreifer eine vollständige Datenbank-Admin-UI. Er kann SQL-Queries ausführen, User löschen, RLS deaktivieren und Daten exportieren. Das ist der Worst Case für einen Self-Hosted Stack.

### Service-Checkliste

Nach dem Setup aller Services vor dem ersten produktiven Einsatz prüfen:

```
Secrets
  [ ] Alle Secrets generiert (keine Default-Werte)
  [ ] JWT_SECRET mindestens 32 Zeichen
  [ ] POSTGRES_PASSWORD mindestens 24 Zeichen
  [ ] DASHBOARD_PASSWORD mindestens 16 Zeichen
  [ ] SECRET_KEY_BASE mindestens 64 Zeichen
  [ ] MINIO_ROOT_PASSWORD mindestens 8 Zeichen (falls MinIO)
  [ ] DB_ENC_KEY geändert (nicht "supabaserealtime")

PostgreSQL
  [ ] Port nur auf internem Interface (10.0.1.10:5432)
  [ ] Init-Scripts unverändert (roles.sql, jwt.sql etc.)
  [ ] Rollen korrekt erstellt (anon nicht superuser)

Kong
  [ ] Port nur auf localhost (127.0.0.1:8000)
  [ ] JWT-Validation auf allen API-Routes aktiv
  [ ] Dashboard-Passwort stark

GoTrue (Auth)
  [ ] JWT_EXP maximal 3600
  [ ] AUTOCONFIRM false
  [ ] SMTP konfiguriert und getestet
  [ ] SITE_URL und API_EXTERNAL_URL korrekt
  [ ] Refresh Token Rotation aktiv
  [ ] DISABLE_SIGNUP gesetzt wenn geschlossene App

PostgREST
  [ ] Nutzt authenticator-Rolle (nicht postgres)
  [ ] DB_SCHEMAS explizit definiert

Realtime
  [ ] DB_ENC_KEY geändert
  [ ] SECRET_KEY_BASE mindestens 64 Zeichen

Storage / MinIO
  [ ] MinIO nicht von aussen erreichbar
  [ ] MinIO Default-Credentials geändert
  [ ] Storage Volume Permissions korrekt

Interne Services
  [ ] Analytics Port nur localhost
  [ ] Vector Docker Socket Read-Only
  [ ] Supavisor Port nur intern
  [ ] Logflare Tokens nicht auf Default

Studio
  [ ] In Produktion deaktiviert ODER nur über SSH Tunnel
  [ ] Dashboard-Passwort stark
```

## Teil C - Supabase-Stack konfigurieren

Diese Schritte betreffen die eigentliche Supabase-Installation und ihre sicherheitsrelevanten Einstellungen.

## C1 - Supabase Deployment versionieren

### Umsetzung

Alle Infrastrukturdateien gehören in ein Git-Repository. Deployments erfolgen nur über dieses Repository, nie durch manuelle Änderungen auf dem Server.

```
infra/
  docker-compose.yml
  .env.example            (Template, keine echten Secrets)
  caddy/
    Caddyfile
  postgres/
    migrations/
  scripts/
    backup.sh
    restore.sh
    health-check.sh
    security-check.sh
  runbooks/
    supabase-production.md
    security-baseline.md
```

### Deployment-Workflow

```bash
# Auf dem Server
cd /opt/supabase
git pull origin main

# Env Variablen laden (Datei liegt nur auf dem Server)
source .env

# Stack starten/updaten
docker compose up -d

# Health Check
./scripts/health-check.sh
```

### Prüfbare Bedingung

```bash
# Gibt es uncommitted Changes auf dem Server?
cd /opt/supabase && git status --porcelain

# Erwartung: leer (keine lokalen Änderungen)

# Ist der Server auf dem aktuellen Stand?
git log --oneline -1
# Vergleich mit Remote
git fetch origin && git diff HEAD origin/main --stat

# Erwartung: keine Differenz
```

### Failure Scenario

Manuelle Änderungen an der `docker-compose.yml` auf dem Server werden beim nächsten `git pull` überschrieben oder erzeugen Merge-Konflikte. Schlimmer: Niemand weiß, welche Änderung wann von wem gemacht wurde. Nach einem Server-Verlust ist die Konfiguration nicht reproduzierbar.

## C2 - docker-compose.yml: minimaler Produktions-Stack

### Umsetzung

Supabase liefert eine Referenz-Compose-Datei mit über 400 Zeilen und ca. 15 Services. Nicht alle werden für Produktion benötigt. Hier die sicherheitsrelevanten Entscheidungen:

**Minimaler Stack (diese Services braucht man):**

```
postgres          Datenbank
kong              API Gateway
gotrue            Auth
postgrest         REST API
realtime          WebSocket (falls benötigt)
storage           File Storage (falls benötigt)
meta              Metadaten für PostgREST
```

**Nicht in Produktion (weglassen oder nur intern):**

```
studio            Admin UI, nur über SSH Tunnel oder VPN
imgproxy          nur wenn Bild-Transformationen benötigt
inbucket          nur für lokale E-Mail-Tests
```

Auszug der sicherheitsrelevanten Konfiguration:

```yaml
# docker-compose.yml (Auszug, sicherheitsrelevante Teile)

services:
  postgres:
    image: supabase/postgres:15.6.1.143    # Version pinnen
    restart: unless-stopped
    ports:
      - "10.0.1.10:5432:5432"              # NUR internes Interface
    environment:
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    volumes:
      - postgres-data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 30s
      timeout: 10s
      retries: 3

  kong:
    image: kong:2.8.1                       # Version pinnen
    restart: unless-stopped
    ports:
      - "127.0.0.1:8000:8000"              # NUR localhost (Reverse Proxy davor)
    environment:
      KONG_DNS_ORDER: LAST,A,CNAME
      KONG_PLUGINS: request-transformer,cors,key-auth,acl
      KONG_NGINX_PROXY_PROXY_BUFFER_SIZE: 160k
      KONG_NGINX_PROXY_PROXY_BUFFERS: 64 160k

  gotrue:
    image: supabase/gotrue:v2.164.0         # Version pinnen
    restart: unless-stopped
    environment:
      GOTRUE_JWT_SECRET: ${JWT_SECRET}
      GOTRUE_JWT_EXP: 3600                  # 1 Stunde, nicht mehr
      GOTRUE_EXTERNAL_EMAIL_ENABLED: true
      GOTRUE_MAILER_AUTOCONFIRM: false      # E-Mail Bestätigung erzwingen
      GOTRUE_DISABLE_SIGNUP: false           # auf true setzen wenn Registrierung geschlossen
      GOTRUE_RATE_LIMIT_HEADER: X-Real-IP
      GOTRUE_SECURITY_REFRESH_TOKEN_ROTATION_ENABLED: true
      GOTRUE_SECURITY_REFRESH_TOKEN_REUSE_INTERVAL: 10
      API_EXTERNAL_URL: https://app.example.com

  postgrest:
    image: postgrest/postgrest:v12.2.3      # Version pinnen
    restart: unless-stopped
    environment:
      PGRST_DB_URI: postgres://authenticator:${POSTGRES_PASSWORD}@postgres:5432/postgres
      PGRST_DB_ANON_ROLE: anon
      PGRST_JWT_SECRET: ${JWT_SECRET}

volumes:
  postgres-data:

networks:
  default:
    driver: bridge
```

**Kritische Konfigurationspunkte:**

```
GOTRUE_JWT_EXP: 3600         nicht höher als 3600 (1h)
GOTRUE_MAILER_AUTOCONFIRM    false in Produktion
GOTRUE_DISABLE_SIGNUP         true wenn keine offene Registrierung
REFRESH_TOKEN_ROTATION        true (verhindert Token Reuse)
Image Versionen               immer pinnen, nie :latest
Postgres Port                 nur auf internem Interface binden
Kong Port                     nur auf localhost (Reverse Proxy davor)
```

### Prüfbare Bedingung

```bash
# Images gepinnt (kein :latest)?
grep "image:" docker-compose.yml | grep -c "latest"
# Erwartung: 0

# Postgres nur intern erreichbar?
docker compose exec postgres ss -tlnp | grep 5432
# Erwartung: nur 10.0.1.10:5432 oder 0.0.0.0:5432 (dann Firewall prüfen)

# Von außen Postgres nicht erreichbar?
nmap -p 5432 app.example.com
# Erwartung: filtered oder closed

# JWT Expiry korrekt?
grep "GOTRUE_JWT_EXP" .env
# Erwartung: 3600 oder weniger

# Supabase Studio nicht von außen erreichbar?
curl -s -o /dev/null -w "%{http_code}" https://app.example.com:3000
# Erwartung: Timeout oder Connection Refused
```

### Failure Scenario

Ungepinnte Images (`image: supabase/gotrue:latest`) können bei einem `docker compose pull` unbemerkt eine neue Version einführen, die Breaking Changes enthält oder eine bekannte Vulnerability hat. Wenn Postgres auf `0.0.0.0:5432` lauscht und die Firewall temporär ausfällt, ist die gesamte Datenbank im Internet erreichbar. Wenn `GOTRUE_JWT_EXP` auf 86400 (24h) steht, ist ein gestohlenes Token einen ganzen Tag lang gültig.

## C3 - Secrets vollständig und sicher verwalten

### Umsetzung

Ein Supabase-Stack hat mindestens diese Secrets:

```bash
# .env (nur auf dem Server, nie im Git)

# Kern-Secrets
JWT_SECRET=                    # min. 32 Zeichen, generiert mit openssl rand -base64 32
ANON_KEY=                      # JWT Token mit anon-Rolle
SERVICE_ROLE_KEY=              # JWT Token mit service_role, umgeht RLS
POSTGRES_PASSWORD=             # min. 24 Zeichen, generiert

# Dashboard
DASHBOARD_USERNAME=            # Supabase Studio Login
DASHBOARD_PASSWORD=            # min. 16 Zeichen

# E-Mail (GoTrue)
SMTP_HOST=
SMTP_PORT=
SMTP_USER=
SMTP_PASS=
SMTP_SENDER_NAME=

# Storage (falls S3-Backend)
S3_ACCESS_KEY=
S3_SECRET_KEY=
```

**Secrets generieren:**

```bash
# JWT Secret
openssl rand -base64 32

# Postgres Passwort
openssl rand -base64 24

# Anon und Service Role Keys generieren (Supabase CLI)
# Oder manuell JWT erstellen mit dem JWT_SECRET
```

**Secret-Management auf dem Server:**

```bash
# .env Datei mit restriktiven Rechten
chmod 600 /opt/supabase/.env
chown deploy:deploy /opt/supabase/.env

# Prüfen dass .env nicht im Git liegt
cat /opt/supabase/.gitignore | grep ".env"
```

**Im Repository liegt nur das Template:**

```bash
# .env.example (im Git)
JWT_SECRET=generate-with-openssl-rand-base64-32
ANON_KEY=generate-jwt-with-anon-role
SERVICE_ROLE_KEY=generate-jwt-with-service-role
POSTGRES_PASSWORD=generate-with-openssl-rand-base64-24
DASHBOARD_USERNAME=admin
DASHBOARD_PASSWORD=generate-min-16-chars
SMTP_HOST=
SMTP_PORT=587
SMTP_USER=
SMTP_PASS=
SMTP_SENDER_NAME=
```

Das gleiche Prinzip gilt für jede [Datensicherheit in der Enterprise-KI-Infrastruktur](/de/magazin/datensicherheit-ki-enterprise/).

### Prüfbare Bedingung

```bash
# .env nicht im Git?
cd /opt/supabase && git ls-files .env
# Erwartung: leer

# .env in .gitignore?
grep "^\.env$" .gitignore
# Erwartung: .env

# Dateirechte korrekt?
stat -c "%a %U" .env
# Erwartung: 600 deploy

# Secrets haben ausreichende Länge?
awk -F= '{if (length($2) < 16 && $2 != "" && $1 !~ /PORT|HOST|NAME/) print "ZU KURZ: "$1}' .env
# Erwartung: keine Ausgabe

# Keine Default-Passwörter?
grep -iE "password|secret" .env | grep -iE "change.me|default|example|your.*here"
# Erwartung: keine Treffer
```

### Failure Scenario

Das häufigste Sicherheitsproblem bei Supabase Self-Hosting ist nicht ein Server-Exploit, sondern ein geleakter Secret. Wenn `.env` ins Git committed wird und das Repository öffentlich ist (oder wird), liegen alle Secrets offen. Mit dem `SERVICE_ROLE_KEY` lässt sich die gesamte Datenbank ohne RLS lesen und schreiben.

## C4 - Datenbank-Policies prüfen

### Umsetzung

Bei Supabase liegt ein großer Teil der Sicherheit in PostgreSQL Row Level Security (RLS), nicht im Applikationsserver. Jede Tabelle im `public` Schema muss RLS aktiviert haben.

**Tabellen ohne RLS finden:**

```sql
-- Alle public-Tabellen ohne RLS
SELECT schemaname, tablename, rowsecurity
FROM pg_tables
WHERE schemaname = 'public'
  AND rowsecurity = false;
```

**Tabellen mit RLS aber ohne Policies finden:**

```sql
-- RLS aktiv aber keine Policy definiert = kein Zugriff möglich
-- (kann gewollt sein, aber prüfen)
SELECT t.tablename
FROM pg_tables t
LEFT JOIN pg_policies p ON t.tablename = p.tablename
WHERE t.schemaname = 'public'
  AND t.rowsecurity = true
  AND p.policyname IS NULL;
```

**Zu offene Policies finden:**

```sql
-- Policies die allen Rollen vollen Zugriff geben
SELECT tablename, policyname, permissive, roles, cmd, qual
FROM pg_policies
WHERE schemaname = 'public'
  AND (roles = '{public}' OR qual = 'true');
```

**Service Role Nutzung prüfen:**

```sql
-- Welche Rollen existieren und welche Rechte haben sie?
SELECT rolname, rolsuper, rolcreaterole, rolcreatedb
FROM pg_roles
WHERE rolname IN ('anon', 'authenticated', 'service_role', 'authenticator');
```

### Prüfbare Bedingung

```bash
# Als automatisiertes Script vom audit-runner
ssh supabase-prod "docker compose exec -T postgres psql -U postgres -c \"
  SELECT tablename FROM pg_tables
  WHERE schemaname = 'public' AND rowsecurity = false;
\""

# Erwartung: keine Tabellen (oder nur bewusst ausgenommene)
```

### Failure Scenario

Eine Tabelle `users` mit `rowsecurity = false` ist über die PostgREST API für jeden mit dem `anon` Key vollständig lesbar. Das betrifft alle Spalten, auch E-Mail-Adressen, Telefonnummern und andere personenbezogene Daten. Ein einfacher `curl` Befehl mit dem öffentlichen `anon` Key reicht.

## Teil D - Betrieb und Überwachung

Diese Schritte laufen regelmäßig und automatisiert.

## D1 - Backups automatisieren

### Umsetzung

Tägliche PostgreSQL-Dumps, verschlüsselt und extern gespeichert.

```bash
#!/bin/bash
# scripts/backup.sh

set -euo pipefail

BACKUP_DIR="/opt/backups"
DATE=$(date +%Y-%m-%d_%H%M)
RETENTION_DAYS=30
GPG_RECIPIENT="backup@example.com"   # GPG Key ID

# PostgreSQL Dump
docker compose exec -T postgres pg_dump \
  -U postgres \
  --format=custom \
  --compress=9 \
  postgres > "${BACKUP_DIR}/db_${DATE}.dump"

# Storage Buckets sichern (falls Supabase Storage genutzt)
docker compose exec -T storage tar -czf - /var/lib/storage \
  > "${BACKUP_DIR}/storage_${DATE}.tar.gz"

# Verschlüsseln
for file in "${BACKUP_DIR}"/*_${DATE}.*; do
  gpg --encrypt --recipient "${GPG_RECIPIENT}" "$file"
  rm "$file"   # Unverschlüsselte Version löschen
done

# Auf externen Server kopieren (audit-runner oder S3)
rsync -az "${BACKUP_DIR}/"*_${DATE}*.gpg \
  deploy@10.0.1.11:/opt/backup-archive/

# Alte Backups löschen (lokal)
find "${BACKUP_DIR}" -name "*.gpg" -mtime +${RETENTION_DAYS} -delete

# Auf dem Backup-Server ebenfalls aufräumen
ssh deploy@10.0.1.11 \
  "find /opt/backup-archive -name '*.gpg' -mtime +${RETENTION_DAYS} -delete"

echo "Backup ${DATE} abgeschlossen"
```

```bash
# Cron Job einrichten
# crontab -e
0 3 * * * /opt/supabase/scripts/backup.sh >> /var/log/backup.log 2>&1
```

### Prüfbare Bedingung

```bash
# Backup von heute vorhanden?
ls -la /opt/backups/*_$(date +%Y-%m-%d)*.gpg

# Backup auf externem Server angekommen?
ssh deploy@10.0.1.11 "ls -la /opt/backup-archive/*_$(date +%Y-%m-%d)*.gpg"

# Backup-Größe plausibel (nicht 0 Bytes)?
find /opt/backups -name "*.gpg" -size 0 -print
# Erwartung: keine Treffer
```

### Failure Scenario

Backups nur auf demselben Server zu speichern bedeutet: wenn der Server ausfällt oder verschlüsselt wird (Ransomware), sind auch die Backups weg. Unverschlüsselte Backups auf einem externen Server sind ein Datenleck, da der Dump alle Tabellendaten im Klartext enthält.

## D2 - Restore regelmäßig testen

### Umsetzung

Einmal pro Monat ein Backup auf einem Testsystem wiederherstellen.

```bash
#!/bin/bash
# scripts/restore-test.sh

set -euo pipefail

BACKUP_FILE=$1   # z.B. /opt/backup-archive/db_2026-03-01_0300.dump.gpg

# Entschlüsseln
gpg --decrypt "$BACKUP_FILE" > /tmp/restore-test.dump

# Test-Container starten
docker run -d --name restore-test \
  -e POSTGRES_PASSWORD=testpassword \
  supabase/postgres:15.6.1.143

sleep 10

# Restore
docker exec -i restore-test pg_restore \
  -U postgres \
  --dbname=postgres \
  --clean \
  --if-exists \
  < /tmp/restore-test.dump

# Tabellen prüfen
docker exec restore-test psql -U postgres -c \
  "SELECT schemaname, tablename FROM pg_tables WHERE schemaname = 'public';"

# Row Counts prüfen
docker exec restore-test psql -U postgres -c \
  "SELECT relname, n_live_tup FROM pg_stat_user_tables ORDER BY n_live_tup DESC LIMIT 10;"

# Aufräumen
docker rm -f restore-test
rm /tmp/restore-test.dump

echo "Restore-Test abgeschlossen"
```

### Prüfbare Bedingung

```bash
# Restore-Test Script ausführen und Exit Code prüfen
./scripts/restore-test.sh /opt/backup-archive/db_latest.dump.gpg
echo $?
# Erwartung: 0

# Log des letzten Restore-Tests prüfen
cat /var/log/restore-test.log | tail -20
```

### Failure Scenario

Viele Teams haben Backups die seit Monaten laufen, aber noch nie einen Restore getestet haben. Typische Probleme: falsches `pg_dump` Format (Plain Text statt Custom), fehlende Berechtigungen beim Restore, inkompatible PostgreSQL-Versionen zwischen Backup und Restore. All das fällt erst auf, wenn man den Restore wirklich braucht.

## D3 - Tägliche Infrastruktur-Checks

### Umsetzung

Ein Script auf dem audit-runner prüft täglich den Zustand des Produktionssystems.

```bash
#!/bin/bash
# scripts/security-check.sh (läuft auf audit-runner)

set -euo pipefail

PROD_HOST="10.0.1.10"
REPORT=""
CRITICAL=0

# 1. Container Status
STOPPED=$(ssh deploy@${PROD_HOST} "docker compose ps --format json" | \
  jq -r 'select(.State != "running") | .Name')
if [ -n "$STOPPED" ]; then
  REPORT+="KRITISCH: Container nicht running: ${STOPPED}\n"
  CRITICAL=1
fi

# 2. Offene Ports von außen
OPEN_PORTS=$(nmap -p 22,80,443,3000,5432,8000,9000 app.example.com \
  --open -oG - | grep "/open/" | grep -v "443/open")
if [ -n "$OPEN_PORTS" ]; then
  REPORT+="KRITISCH: Unerwartete offene Ports: ${OPEN_PORTS}\n"
  CRITICAL=1
fi

# 3. Zertifikat Ablaufdatum
CERT_EXPIRY=$(echo | openssl s_client -connect app.example.com:443 2>/dev/null | \
  openssl x509 -noout -enddate | cut -d= -f2)
CERT_EPOCH=$(date -d "$CERT_EXPIRY" +%s)
NOW_EPOCH=$(date +%s)
DAYS_LEFT=$(( (CERT_EPOCH - NOW_EPOCH) / 86400 ))
if [ "$DAYS_LEFT" -lt 14 ]; then
  REPORT+="WARNUNG: TLS Zertifikat läuft in ${DAYS_LEFT} Tagen ab\n"
fi

# 4. Firewall Drift
FIREWALL_DIFF=$(ssh deploy@${PROD_HOST} "iptables-save" | \
  diff /opt/baselines/firewall-baseline.txt - || true)
if [ -n "$FIREWALL_DIFF" ]; then
  REPORT+="WARNUNG: Firewall hat sich geändert:\n${FIREWALL_DIFF}\n"
fi

# 5. Docker Image Versionen (Drift gegen Baseline)
IMAGE_DIFF=$(ssh deploy@${PROD_HOST} \
  "docker compose images --format '{{.Repository}}:{{.Tag}}'" | \
  diff /opt/baselines/image-versions.txt - || true)
if [ -n "$IMAGE_DIFF" ]; then
  REPORT+="WARNUNG: Container-Versionen haben sich geändert:\n${IMAGE_DIFF}\n"
fi

# 6. Disk Space
DISK_USAGE=$(ssh deploy@${PROD_HOST} "df -h / | tail -1 | awk '{print \$5}' | tr -d '%'")
if [ "$DISK_USAGE" -gt 85 ]; then
  REPORT+="WARNUNG: Disk Usage bei ${DISK_USAGE}%\n"
fi

# 7. Backup Status
LAST_BACKUP=$(ssh deploy@${PROD_HOST} "ls -t /opt/backups/*.gpg 2>/dev/null | head -1")
if [ -z "$LAST_BACKUP" ]; then
  REPORT+="KRITISCH: Kein Backup gefunden\n"
  CRITICAL=1
else
  BACKUP_AGE=$(ssh deploy@${PROD_HOST} \
    "echo \$(( (\$(date +%s) - \$(stat -c %Y ${LAST_BACKUP})) / 3600 ))")
  if [ "$BACKUP_AGE" -gt 26 ]; then
    REPORT+="WARNUNG: Letztes Backup ist ${BACKUP_AGE} Stunden alt\n"
  fi
fi

# 8. RLS Check
UNPROTECTED=$(ssh deploy@${PROD_HOST} "docker compose exec -T postgres psql -U postgres -t -c \
  \"SELECT count(*) FROM pg_tables WHERE schemaname = 'public' AND rowsecurity = false;\"" | tr -d ' ')
if [ "$UNPROTECTED" -gt 0 ]; then
  REPORT+="WARNUNG: ${UNPROTECTED} Tabellen ohne RLS\n"
fi

# Ergebnis
echo "=== Security Check $(date) ==="
if [ -n "$REPORT" ]; then
  echo -e "$REPORT"
else
  echo "Alle Checks bestanden"
fi

# Bei kritischen Findings: Alert senden
if [ "$CRITICAL" -eq 1 ]; then
  echo -e "$REPORT" | mail -s "KRITISCH: Security Check $(date)" ops@example.com
fi
```

```bash
# Cron auf dem audit-runner
0 7 * * * /opt/audit/scripts/security-check.sh >> /var/log/security-check.log 2>&1
```

### Prüfbare Bedingung

```bash
# Check-Script lief heute?
grep "$(date +%Y-%m-%d)" /var/log/security-check.log | tail -1
# Erwartung: Eintrag von heute vorhanden

# Ergebnis?
grep "Alle Checks bestanden\|KRITISCH\|WARNUNG" /var/log/security-check.log | tail -5
```

## D4 - Claude Code als kontextuelle Analyse-Schicht

Claude Code analysiert die Ergebnisse der deterministischen Checks und erkennt Zusammenhänge, die Scripts nicht sehen. Das [Drei-Ebenen-Modell aus dem Claude Code Runbook](/de/magazin/claude-code-security-devops/#grundprinzip-drei-ebenen-der-sicherheitsprüfung) beschreibt diesen Ansatz im Detail.

### Architektur

```
Tägliche Checks (D3)
     |
     +-- Deterministische Findings
     |   (offene Ports, Firewall Drift, fehlende Backups)
     |
     +---> Wöchentlicher Claude Code Review
          |
          +-- Config Dateien (docker-compose.yml, Caddyfile, .env.example)
          +-- Security Check Logs der letzten 7 Tage
          +-- Git Diff der Infrastruktur-Änderungen
          +-- RLS Policy Export
          |
          +---> Priorisierter Bericht
               |
               +---> DevOps Entscheidung (Mensch)
```

### Konkretes Script

```bash
#!/bin/bash
# scripts/claude-review-prep.sh (läuft auf audit-runner)

REPORT_DIR="/opt/audit/weekly-reports"
DATE=$(date +%Y-%m-%d)
OUTPUT="${REPORT_DIR}/review-input-${DATE}.md"

mkdir -p "$REPORT_DIR"

cat > "$OUTPUT" << 'HEADER'
# Wöchentlicher Security Review Input

## Kontext
Self-hosted Supabase Stack auf Hetzner Cloud.
Architektur: Reverse Proxy -> Kong -> Supabase Services -> PostgreSQL
Audit-System auf separatem Server.
HEADER

# Security Check Logs der letzten 7 Tage
echo -e "\n## Security Check Ergebnisse (letzte 7 Tage)\n" >> "$OUTPUT"
echo '```' >> "$OUTPUT"
grep -A 20 "Security Check" /var/log/security-check.log | \
  tail -100 >> "$OUTPUT"
echo '```' >> "$OUTPUT"

# Aktuelle Docker Compose Config (ohne Secrets)
echo -e "\n## Aktuelle docker-compose.yml\n" >> "$OUTPUT"
echo '```yaml' >> "$OUTPUT"
ssh deploy@10.0.1.10 "cat /opt/supabase/docker-compose.yml" >> "$OUTPUT"
echo '```' >> "$OUTPUT"

# Git Diff der letzten Woche
echo -e "\n## Infrastruktur-Änderungen (letzte 7 Tage)\n" >> "$OUTPUT"
echo '```' >> "$OUTPUT"
ssh deploy@10.0.1.10 "cd /opt/supabase && git log --oneline --since='7 days ago'" >> "$OUTPUT"
ssh deploy@10.0.1.10 "cd /opt/supabase && git diff HEAD~5 --stat" >> "$OUTPUT" 2>/dev/null
echo '```' >> "$OUTPUT"

# RLS Status
echo -e "\n## RLS Status\n" >> "$OUTPUT"
echo '```' >> "$OUTPUT"
ssh deploy@10.0.1.10 "docker compose exec -T postgres psql -U postgres -c \"
  SELECT tablename, rowsecurity FROM pg_tables WHERE schemaname = 'public' ORDER BY tablename;
\"" >> "$OUTPUT"
echo '```' >> "$OUTPUT"

# Container Versionen
echo -e "\n## Container Versionen\n" >> "$OUTPUT"
echo '```' >> "$OUTPUT"
ssh deploy@10.0.1.10 "docker compose images --format '{{.Repository}}:{{.Tag}}'" >> "$OUTPUT"
echo '```' >> "$OUTPUT"

echo "Review-Input erstellt: $OUTPUT"
```

### Was Claude Code nicht tut

```
Claude führt KEINE automatischen Änderungen auf Production aus.
Claude deployed NICHT.
Claude rotiert KEINE Secrets.
Claude hat KEINEN direkten Zugriff auf den Produktionsserver.

Claude analysiert Daten die ihm übergeben werden
und erstellt Berichte für menschliche Entscheidungen.
```

## Deployment-Checkliste

Vor der ersten Inbetriebnahme und nach größeren Änderungen:

```
Teil A - Infrastruktur
  [ ] Zwei separate Server (prod + audit)
  [ ] Privates Netzwerk konfiguriert und getestet
  [ ] Cloud Firewall aktiv (nur 443, SSH von Admin-IP)
  [ ] Host Firewall aktiv (iptables)
  [ ] Firewall-Baseline gespeichert
  [ ] SSH: nur Keys, kein Root, kein Passwort
  [ ] Reverse Proxy konfiguriert (Caddy/Nginx)
  [ ] TLS aktiv mit automatischem Renewal
  [ ] Security Headers gesetzt (HSTS, CSP, X-Frame-Options)
  [ ] WebSocket Proxy für Realtime konfiguriert

Teil B - Supabase Services
  Secrets (B0)
    [ ] Alle Secrets generiert (keine Default-Werte)
    [ ] JWT_SECRET mindestens 32 Zeichen
    [ ] POSTGRES_PASSWORD mindestens 24 Zeichen
    [ ] DASHBOARD_PASSWORD mindestens 16 Zeichen
    [ ] SECRET_KEY_BASE mindestens 64 Zeichen
    [ ] MINIO_ROOT_PASSWORD mindestens 8 Zeichen (falls MinIO)
    [ ] DB_ENC_KEY geändert (nicht "supabaserealtime")
  PostgreSQL (B1)
    [ ] Port nur auf internem Interface (10.0.1.10:5432)
    [ ] Init-Scripts unverändert (roles.sql, jwt.sql etc.)
    [ ] Rollen korrekt erstellt (anon nicht superuser)
  Kong (B2)
    [ ] Port nur auf localhost (127.0.0.1:8000)
    [ ] JWT-Validation auf allen API-Routes aktiv
    [ ] Dashboard-Passwort stark
  GoTrue (B3)
    [ ] JWT_EXP maximal 3600
    [ ] AUTOCONFIRM false
    [ ] SMTP konfiguriert und getestet
    [ ] SITE_URL und API_EXTERNAL_URL korrekt
    [ ] Refresh Token Rotation aktiv
    [ ] DISABLE_SIGNUP gesetzt wenn geschlossene App
  PostgREST (B4)
    [ ] Nutzt authenticator-Rolle (nicht postgres)
    [ ] DB_SCHEMAS explizit definiert
  Realtime (B5)
    [ ] DB_ENC_KEY geändert
    [ ] SECRET_KEY_BASE mindestens 64 Zeichen
  Storage / MinIO (B6)
    [ ] MinIO nicht von aussen erreichbar
    [ ] MinIO Default-Credentials geändert
    [ ] Storage Volume Permissions korrekt
  Interne Services (B7)
    [ ] Analytics Port nur localhost
    [ ] Vector Docker Socket Read-Only
    [ ] Supavisor Port nur intern
    [ ] Logflare Tokens nicht auf Default
  Studio (B8)
    [ ] In Produktion deaktiviert ODER nur über SSH Tunnel
    [ ] Dashboard-Passwort stark

Teil C - Stack-Konfiguration
  [ ] docker-compose.yml versioniert im Git
  [ ] Alle Image Versionen gepinnt (kein :latest)
  [ ] .env nicht im Git
  [ ] .env Dateirechte 600
  [ ] .env.example im Git als Template
  [ ] Keine Default-Passwörter
  [ ] RLS auf allen public-Tabellen aktiv
  [ ] Keine Tabellen ohne Policies (außer bewusst)
  [ ] Keine zu offenen Policies (qual = 'true')

Teil D - Betrieb und Überwachung
  [ ] Täglicher Backup-Job aktiv
  [ ] Backups verschlüsselt
  [ ] Backups extern gespeichert (audit-runner oder S3)
  [ ] Restore-Test mindestens einmal durchgeführt
  [ ] Retention-Strategie konfiguriert
  [ ] Täglicher Security-Check-Job auf audit-runner
  [ ] Alerting bei kritischen Findings
  [ ] Wöchentlicher Claude Code Review eingerichtet

Teil E - Updates und Maintenance
  [ ] Unattended Upgrades installiert und aktiv
  [ ] Auto-Update-Intervall auf täglich konfiguriert
  [ ] Supabase Images gepinnt (kein :latest)
  [ ] Kein Supabase Image älter als 90 Tage
  [ ] Update-Commit innerhalb der letzten 45 Tage
  [ ] Auto-Patch Script für PostgreSQL Minor Patches aktiv
  [ ] Auto-Patch Cron NACH Backup-Cron (03:00 nach 02:00)
  [ ] Security Release Monitor auf audit-runner aktiv (täglich)
  [ ] Trivy installiert auf audit-runner
  [ ] Maintenance Check Cron auf audit-runner (wöchentlich Montag)
  [ ] TLS Zertifikat mindestens 14 Tage gültig
  [ ] Disk Usage unter 85%
```

## Teil E - Updates und Maintenance

Ein self-hosted Stack der nicht regelmässig aktualisiert wird, sammelt Sicherheitslücken an. Ungepatchte CVEs in PostgreSQL, Kong oder GoTrue sind reale Angriffsvektoren. Gleichzeitig können Updates Breaking Changes einführen die den Stack lahmlegen.

Deshalb braucht der Update-Prozess klare Regeln: Was wird wann aktualisiert, wie wird getestet, und wie wird sichergestellt dass nichts vergessen wird.

### E1 - Drei Update-Ebenen

Der Stack hat drei unabhängige Update-Ebenen mit unterschiedlichen Rhythmen und Risiken.

```
Ebene 1: OS-Level (Ubuntu)
   │  Was: Kernel, System-Packages, OpenSSL, Docker Engine
   │  Rhythmus: Wöchentlich Security Patches, monatlich Full Update
   │  Risiko: Gering (apt upgrade ist stabil)
   │  Methode: apt update && apt upgrade
   │
Ebene 2: Supabase Services (Docker Images)
   │  Was: PostgreSQL, Kong, GoTrue, PostgREST, Realtime, Storage, etc.
   │  Rhythmus: Monatlich (Supabase Release Cycle)
   │  Risiko: Mittel bis hoch (Breaking Changes zwischen Versionen)
   │  Methode: Image Tags in docker-compose.yml ändern, pull, restart
   │
Ebene 3: Reverse Proxy und Tools
   │  Was: Caddy, iptables, GPG, nmap, jq
   │  Rhythmus: Bei Security Advisories oder quartalsweise
   │  Risiko: Gering
   │  Methode: apt upgrade (Caddy über eigenes Repo)
```

**Prüfbare Bedingung:**

```bash
# OS: Wann war das letzte apt upgrade?
stat -c %y /var/cache/apt/pkgcache.bin
# Erwartung: weniger als 7 Tage alt

# Supabase: Welche Image-Versionen laufen?
cd /opt/supabase && docker compose images --format '{{.Repository}}:{{.Tag}}'

# Caddy Version
caddy version
```

**Failure Scenario:** Ein ungepatchter PostgreSQL mit einer bekannten Remote Code Execution Vulnerability (wie CVE-2023-5869) kann von einem Angreifer ausgenutzt werden, selbst wenn RLS korrekt konfiguriert ist. Ein veralteter Kong mit einer bekannten Auth-Bypass-Vulnerability kann JWT-Validation umgehen.

### E2 - OS-Level Updates

**Wöchentlich: Security Patches (automatisch)**

```bash
# Unattended Upgrades installieren und konfigurieren
sudo apt install -y unattended-upgrades

# Konfiguration: nur Security Updates automatisch
sudo tee /etc/apt/apt.conf.d/50unattended-upgrades > /dev/null << 'EOF'
Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
};

// Automatischer Reboot wenn nötig (z.B. Kernel Update)
// Nur aktivieren wenn ihr damit leben könnt dass der Server
// um 4:00 Uhr nachts kurz neustartet
Unattended-Upgrade::Automatic-Reboot "false";

// E-Mail Benachrichtigung bei Updates
Unattended-Upgrade::Mail "ops@example.com";
Unattended-Upgrade::MailReport "on-change";
EOF

# Automatische Updates aktivieren
sudo tee /etc/apt/apt.conf.d/20auto-upgrades > /dev/null << 'EOF'
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::AutocleanInterval "7";
EOF

sudo systemctl enable unattended-upgrades
sudo systemctl start unattended-upgrades
```

**Monatlich: Full System Update (manuell, mit Prüfung)**

```bash
# Zuerst prüfen was aktualisiert wird
apt list --upgradable

# Dann updaten
sudo apt update && sudo apt upgrade -y

# Docker Engine Update (separat, über Docker Repo)
sudo apt install --only-upgrade docker-ce docker-ce-cli containerd.io

# Nach Kernel-Updates: Reboot nötig?
if [ -f /var/run/reboot-required ]; then
  echo "REBOOT ERFORDERLICH"
fi
```

**Prüfbare Bedingung:**

```bash
# Unattended Upgrades aktiv?
systemctl is-active unattended-upgrades

# Letzte automatische Updates
cat /var/log/unattended-upgrades/unattended-upgrades.log | tail -20

# Ausstehende Security Updates?
apt list --upgradable 2>/dev/null | grep -i security | wc -l
# Erwartung: 0
```

### E3 - Supabase Service Updates

Supabase veröffentlicht ca. monatlich neue Docker Images. Der Update-Prozess muss kontrolliert ablaufen weil Breaking Changes zwischen Versionen möglich sind.

**Workflow:**

```
1. Release Notes lesen (github.com/supabase/supabase/releases)
2. Neue Image Tags in docker-compose.yml eintragen
3. Auf Staging/Test testen (oder: Backup + Rollback-Plan)
4. Backup erstellen
5. docker compose pull
6. docker compose down && docker compose up -d
7. Health Checks prüfen
8. Baselines aktualisieren
```

**Aktuelle Versionen prüfen vs. verfügbar:**

```bash
cd /opt/supabase

echo "=== Aktuelle Versionen ==="
docker compose images --format '{{.Repository}}:{{.Tag}}'

echo ""
echo "=== Verfügbare Updates ==="
# Die offiziellen Releases prüfen
echo "Supabase Releases: https://github.com/supabase/supabase/releases"
echo "GoTrue: https://github.com/supabase/gotrue/releases"
echo "PostgREST: https://github.com/PostgREST/postgrest/releases"
echo "Realtime: https://github.com/supabase/realtime/releases"
echo ""
echo "Oder den offiziellen docker-compose.yml vergleichen:"
echo "https://raw.githubusercontent.com/supabase/supabase/master/docker/docker-compose.yml"
```

**Sicherer Update-Ablauf:**

```bash
cd /opt/supabase

# 1. Backup VOR dem Update
./scripts/backup.sh

# 2. Aktuelle Versionen dokumentieren
docker compose images --format '{{.Repository}}:{{.Tag}}' > /opt/baselines/pre-update-versions.txt

# 3. Neue Versionen in docker-compose.yml eintragen
# MANUELL: Image Tags auf die neue Version ändern
# z.B. supabase/gotrue:v2.164.0 → supabase/gotrue:v2.184.0

# 4. Pull neue Images
docker compose pull

# 5. Stack neu starten
docker compose down
docker compose up -d

# 6. Warten und Health Checks
sleep 30
docker compose ps --format "table {{.Name}}\t{{.Status}}"

# 7. Alle Services prüfen
docker compose exec -T auth wget --no-verbose --tries=1 --spider http://localhost:9999/health
docker compose exec -T db pg_isready -U postgres -h localhost
curl -s -o /dev/null -w "Kong: %{http_code}\n" http://localhost:8000
curl -s -o /dev/null -w "Storage: %{http_code}\n" http://localhost:8000/storage/v1/

# 8. Baselines aktualisieren
docker compose images --format '{{.Repository}}:{{.Tag}}' > /opt/baselines/image-versions.txt

# 9. Git Commit
git add docker-compose.yml
git commit -m "Update Supabase images to [VERSION]"
```

**Rollback wenn etwas schiefgeht:**

```bash
cd /opt/supabase

# Alte Versionen wiederherstellen
git checkout HEAD~1 -- docker-compose.yml
docker compose pull
docker compose down
docker compose up -d

# Wenn Datenbank-Migration das Problem ist:
./scripts/restore.sh /opt/backups/[LETZTES_BACKUP].gpg
```

**Prüfbare Bedingung:**

```bash
# Image-Versionen älter als 3 Monate?
cd /opt/supabase
docker compose images --format '{{.Repository}}:{{.Tag}}' | while read image; do
  CREATED=$(docker inspect --format='{{.Created}}' "$image" 2>/dev/null | cut -dT -f1)
  if [ -n "$CREATED" ]; then
    AGE_DAYS=$(( ($(date +%s) - $(date -d "$CREATED" +%s)) / 86400 ))
    [ "$AGE_DAYS" -gt 90 ] && echo "WARNUNG: $image ist $AGE_DAYS Tage alt"
  fi
done
```

**Failure Scenario:** Supabase GoTrue v2.170.0 hatte eine Änderung im Refresh Token Handling die ältere Clients brach. Ohne vorheriges Lesen der Release Notes und ohne Backup wäre das ein Ausfall gewesen. PostgreSQL Major Version Updates (z.B. 15 -> 16) erfordern einen `pg_dump/pg_restore` Zyklus, ein einfacher Image-Tag-Wechsel reicht nicht.

### E3b - Automatisches Patching (Ebene 1)

Nicht alle Updates erfordern einen Menschen. PostgreSQL Minor Patches und Caddy Updates sind risikoarm und können nachts automatisch eingespielt werden.

**Zwei-Ebenen-Modell:**

```
EBENE 1 - AUTOMATISCH (auto-patch.sh, täglich 03:00):
  OS Security Patches (unattended-upgrades)
  PostgreSQL Minor Patches (15.8.1.x -> 15.8.1.y)
  Caddy Updates
  -> Info-Mail nach erfolgreichem Patch
  -> Alarm-Mail bei Health Check Fehler
  -> Automatischer Rollback bei Fehler

EBENE 2 - MANUELL (/supabase-update, innerhalb 24h nach Alert):
  GoTrue/Auth (Breaking Changes möglich)
  PostgREST (Query-Verhalten kann sich ändern)
  Kong (Routing kann sich ändern)
  Realtime, Storage, Supavisor
  PostgreSQL MAJOR (15 -> 16, braucht pg_dump/pg_restore)
```

Das Script `auto-patch.sh` läuft täglich um 03:00 (nach dem Backup um 02:00) und:

1. Prüft ob ein aktuelles Backup existiert (Abbruch wenn nicht)
2. Sichert den aktuellen Zustand (docker-compose.yml, Image Versionen)
3. Prüft ob ein neues PostgreSQL Minor Image verfügbar ist
4. Spielt es ein und macht einen Health Check
5. Bei Fehler: automatischer Rollback auf die vorherige Version
6. Sendet eine Info-Mail (Erfolg) oder Alarm-Mail (Fehler)

**Prüfbare Bedingung:**

```bash
# Auto-Patch Cron aktiv?
crontab -l | grep auto-patch
# Erwartung: 0 3 * * * /opt/supabase/scripts/auto-patch.sh

# Letzter Auto-Patch Lauf?
tail -20 /var/log/auto-patch.log

# Hat Auto-Patch jemals gepatcht?
grep "Patches eingespielt\|Keine Patches" /var/log/auto-patch.log | tail -5
```

**Cron-Zeitplan (prod-Server):**

```
02:00 täglich  -> Backup (DB + Storage + extern)
03:00 täglich  -> Auto-Patch (PostgreSQL Minor + Caddy)
04:00 monatl.  -> Restore-Test
```

### E4 - Update-Zeitplan und Verantwortlichkeiten

```
Wöchentlich (automatisch):
  [ ] OS Security Patches (unattended-upgrades)
  [ ] Audit-Runner prüft ob Patches angewendet wurden

Monatlich (manuell, geplant):
  [ ] Supabase Release Notes prüfen
  [ ] Neue Image Tags evaluieren
  [ ] Backup erstellen
  [ ] Update durchführen
  [ ] Health Checks
  [ ] Baselines aktualisieren

Quartalsweise (Review):
  [ ] Caddy Version prüfen
  [ ] Docker Engine Version prüfen
  [ ] Node.js Version prüfen (für Claude Code auf audit-runner)
  [ ] PostgreSQL Major Version evaluieren
  [ ] Gesamte Toolchain auf aktuellem Stand?

Bei Security Advisories (sofort):
  [ ] CVE betrifft unseren Stack?
  [ ] Betroffenes Image/Package identifizieren
  [ ] Patch verfügbar?
  [ ] Notfall-Update durchführen
```

**Prüfbare Bedingung:**

```bash
# Wann war das letzte Supabase Update?
cd /opt/supabase
git log --oneline --grep="Update\|update\|upgrade" | head -5

# Wie alt ist der letzte Update-Commit?
LAST_UPDATE=$(git log --format="%ai" --grep="Update\|update" -1 2>/dev/null | cut -d' ' -f1)
if [ -n "$LAST_UPDATE" ]; then
  AGE=$(( ($(date +%s) - $(date -d "$LAST_UPDATE" +%s)) / 86400 ))
  echo "Letztes Update: $LAST_UPDATE ($AGE Tage her)"
  [ "$AGE" -gt 45 ] && echo "WARNUNG: Letztes Update über 45 Tage her"
fi
```

### E5 - Security Release Monitor (täglich)

Der grösste Blindspot bei Self-Hosting ist nicht die initiale Konfiguration, sondern das Verpassen von Security Patches. Wenn Supabase GoTrue einen Auth-Bypass-Fix veröffentlicht, muss das Team innerhalb von 24 Stunden handeln, nicht nach einer Woche.

Auf dem audit-runner läuft **täglich** ein Script das die GitHub Releases aller Supabase-Komponenten prüft und bei Security Releases sofort per E-Mail alarmiert.

**Geprüfte Komponenten:**

```
supabase/auth (GoTrue)          -> häufige Security Patches
PostgREST/postgrest             -> API-Layer
supabase/realtime               -> WebSocket
supabase/storage-api            -> File Storage
Kong/kong                       -> API Gateway
supabase/edge-runtime           -> Edge Functions
supabase/postgres               -> Datenbank Image
supabase/supavisor              -> Connection Pooler
moby/moby (Docker Engine)       -> Container Runtime
```

**Drei Prüfschichten:**

```
Schicht 1: GitHub Releases
  -> Gibt es eine neue Version?
  -> Enthalten die Release Notes "security"/"CVE"?

Schicht 2: Trivy Container Scan
  -> Scannt jedes laufende Docker Image gegen NVD/GitHub Advisories
  -> Findet CVEs in allen Abhängigkeiten (OS-Packages, Libraries)

Schicht 3: OSV API
  -> Prüft Application-Level Vulnerabilities für GoTrue, PostgREST etc.
  -> Ergänzt Trivy um Package-spezifische CVEs
```

**Wie es funktioniert:**

```
Täglich 07:00 (audit-runner Cron)
   │
   ├── Aktuelle Versionen vom prod-Server holen
   ├── GitHub API: Neueste Releases für jede Komponente prüfen
   ├── Release Notes auf "security", "CVE", "vulnerability" scannen
   │
   ├── Security Release gefunden?
   │     -> SOFORT E-Mail an ops@
   │     -> "Handlung innerhalb 24h erforderlich"
   │
   └── Normales Release gefunden?
         -> Wöchentliche Zusammenfassung (Montag)
```

**Cache-Mechanismus:** Das Script merkt sich gemeldete Releases, sodass nicht jeden Tag dieselbe E-Mail kommt. Erst bei einem NEUEN Release wird wieder alarmiert.

**Prüfbare Bedingung:**

```bash
# Security Release Monitor aktiv auf audit-runner?
ssh deploy@10.0.1.11 "crontab -l | grep security-release"
# Erwartung: täglicher Cron Job

# Letzter Check-Log
ssh deploy@10.0.1.11 "tail -5 /var/log/security-releases.log"
# Erwartung: Eintrag von heute

# Cache vorhanden (Script hat schon gelaufen)?
ssh deploy@10.0.1.11 "ls /opt/audit/cache/*-last-seen.txt 2>/dev/null | wc -l"
```

**Failure Scenario:** Im Januar 2024 wurde CVE-2023-5869 für PostgreSQL veröffentlicht (Remote Code Execution). Wer keinen Release Monitor hatte und nur monatlich Updates prüfte, war 3-4 Wochen lang verwundbar. Mit dem täglichen Monitor wäre die E-Mail am Tag nach dem Release eingegangen.

### E6 - Audit-Runner als Update-Wächter

Der Audit-Runner überwacht ob Updates durchgeführt werden und informiert das Team wenn etwas überfällig ist.

Auf dem audit-runner läuft ein wöchentliches Script das folgendes prüft:

```bash
#!/bin/bash
# scripts/check-maintenance.sh (läuft auf audit-runner)

PROD_HOST="10.0.1.10"
REPORT=""

echo "=== Maintenance Check $(date) ==="

# 1. OS Updates überfällig?
LAST_APT=$(ssh deploy@${PROD_HOST} "stat -c %Y /var/cache/apt/pkgcache.bin")
APT_AGE=$(( ($(date +%s) - $LAST_APT) / 86400 ))
if [ "$APT_AGE" -gt 7 ]; then
  REPORT+="WARNUNG: apt update ist ${APT_AGE} Tage her (max. 7)\n"
fi

# 2. Unattended Upgrades aktiv?
UA_STATUS=$(ssh deploy@${PROD_HOST} "systemctl is-active unattended-upgrades 2>/dev/null")
if [ "$UA_STATUS" != "active" ]; then
  REPORT+="KRITISCH: Unattended Upgrades nicht aktiv\n"
fi

# 3. Ausstehende Security Updates?
SEC_UPDATES=$(ssh deploy@${PROD_HOST} "apt list --upgradable 2>/dev/null | grep -ci security")
if [ "$SEC_UPDATES" -gt 0 ]; then
  REPORT+="WARNUNG: ${SEC_UPDATES} ausstehende Security Updates\n"
fi

# 4. Reboot erforderlich?
REBOOT=$(ssh deploy@${PROD_HOST} "test -f /var/run/reboot-required && echo ja || echo nein")
if [ "$REBOOT" = "ja" ]; then
  REPORT+="WARNUNG: Server-Reboot erforderlich (Kernel Update)\n"
fi

# 5. Supabase Image Alter
ssh deploy@${PROD_HOST} "cd /opt/supabase && docker compose images --format '{{.Repository}}:{{.Tag}}'" | \
while read image; do
  CREATED=$(ssh deploy@${PROD_HOST} "docker inspect --format='{{.Created}}' '$image' 2>/dev/null" | cut -dT -f1)
  if [ -n "$CREATED" ]; then
    AGE_DAYS=$(( ($(date +%s) - $(date -d "$CREATED" +%s 2>/dev/null || echo 0)) / 86400 ))
    if [ "$AGE_DAYS" -gt 90 ]; then
      REPORT+="WARNUNG: $image ist ${AGE_DAYS} Tage alt (max. 90)\n"
    fi
  fi
done

# 6. Letztes Supabase Update?
LAST_UPDATE=$(ssh deploy@${PROD_HOST} "cd /opt/supabase && git log --format='%ai' --grep='Update\|update' -1 2>/dev/null" | cut -d' ' -f1)
if [ -n "$LAST_UPDATE" ]; then
  UPDATE_AGE=$(( ($(date +%s) - $(date -d "$LAST_UPDATE" +%s)) / 86400 ))
  if [ "$UPDATE_AGE" -gt 45 ]; then
    REPORT+="WARNUNG: Letztes Supabase Update vor ${UPDATE_AGE} Tagen (max. 45)\n"
  fi
else
  REPORT+="WARNUNG: Kein Update-Commit in Git gefunden\n"
fi

# 7. Docker Engine Version
DOCKER_VERSION=$(ssh deploy@${PROD_HOST} "docker version --format '{{.Server.Version}}' 2>/dev/null")
echo "Docker Engine: $DOCKER_VERSION"

# 8. Caddy Version
CADDY_VERSION=$(ssh deploy@${PROD_HOST} "caddy version 2>/dev/null")
echo "Caddy: $CADDY_VERSION"

# 9. TLS Zertifikat Restlaufzeit
CERT_DAYS=$(ssh deploy@${PROD_HOST} "echo | openssl s_client -connect localhost:443 2>/dev/null | openssl x509 -noout -enddate 2>/dev/null | cut -d= -f2")
if [ -n "$CERT_DAYS" ]; then
  DAYS_LEFT=$(( ($(date -d "$CERT_DAYS" +%s) - $(date +%s)) / 86400 ))
  [ "$DAYS_LEFT" -lt 14 ] && REPORT+="KRITISCH: TLS Zertifikat läuft in ${DAYS_LEFT} Tagen ab\n"
fi

# Ergebnis
if [ -n "$REPORT" ]; then
  echo -e "\n$REPORT"
  echo -e "$REPORT" | mail -s "Maintenance Check: Handlung nötig" ops@example.com
else
  echo "Alle Maintenance Checks bestanden"
fi
```

**Cron auf dem audit-runner:**

```bash
# Wöchentlich Montag 08:00 (nach dem Sonntag-Audit)
0 8 * * 1 /opt/audit/scripts/check-maintenance.sh >> /var/log/maintenance-check.log 2>&1
```

**Wann Claude informiert:**

Claude Code auf dem audit-runner sendet Benachrichtigungen in drei Fällen:

```
SOFORT (E-Mail an ops@):
  - Unattended Upgrades nicht aktiv
  - TLS Zertifikat < 14 Tage
  - Security Update ausstehend und > 3 Tage alt

WÖCHENTLICH (Maintenance Report):
  - Reboot erforderlich
  - apt update überfällig
  - Supabase Images > 60 Tage alt

MONATLICH (Update Reminder):
  - Supabase Release Notes nicht geprüft (kein Update-Commit > 45 Tage)
  - Quartalsreview fällig
```

## Fazit

Supabase selbst zu hosten ist relativ einfach. Supabase **sicher zu betreiben** erfordert klare Architekturregeln und automatisierte Kontrolle.

Dieses Runbook trennt zwischen Infrastruktur-Entscheidungen (Teil A), Service-Architektur und -Absicherung (Teil B), Stack-Konfiguration (Teil C), laufender Überwachung (Teil D) und Update-Prozessen (Teil E). Die Kombination aus deterministischen Checks und kontextueller Claude Code Analyse deckt sowohl bekannte Muster als auch unerwartete Risiken ab.

Wer diese Prinzipien von Anfang an verfolgt, baut eine [Cert-Ready-by-Design-Architektur](/de/magazin/cert-ready-by-design/) und spart sich nachträgliche Audit-Runden.

> **Zur Erinnerung:** Die Hetzner-spezifischen Konfigurationen (vSwitch, Cloud Firewall, Interface-Namen) lassen sich direkt auf andere EU-Hoster übertragen: OVH (FR), Netcup (DE), IONOS (DE), Scaleway (FR). Für Brasilien: Locaweb oder Magalu Cloud (BR). Die Architekturprinzipien gelten hosterunabhängig.

<div class="not-prose my-12 border border-gosign-border bg-gosign-light rounded-card p-6 lg:p-8">
<div class="flex items-start gap-4">
<div class="flex-shrink-0 w-12 h-12 bg-gosign-dark rounded-card flex items-center justify-center">
<svg width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="white" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 15v4a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2v-4"/><polyline points="7 10 12 15 17 10"/><line x1="12" y1="15" x2="12" y2="3"/></svg>
</div>
<div>
<h2 class="text-h3 font-bold text-gosign-dark mb-2" id="audit-checkliste-als-download">Audit-Checkliste als Download</h2>
<p class="text-body text-gosign-text mb-2">Vorbereiteter Prompt für Claude Code. Laden Sie die Datei auf Ihren Server und starten Sie Claude Code im Projektverzeichnis Ihres Supabase-Stacks. Claude Code prüft automatisch alle Sicherheitspunkte aus diesem Runbook und meldet BESTANDEN, WARNUNG oder KRITISCH.</p>
<p class="text-sm text-gosign-text mb-4 font-mono">claude -p "$(cat claude-check-artikel-1-supabase.md)" --allowedTools Read,Grep,Glob,Bash</p>
<a href="/downloads/claude-check-artikel-1-supabase.md" download class="inline-flex items-center px-6 py-3 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-small uppercase tracking-wider">Checkliste herunterladen</a>
</div>
</div>
</div>

## Serien-Inhaltsverzeichnis

Dieser Artikel ist Teil unserer DevOps-Serie für self-hosted App-Stacks.

1. [Supabase Self-Hosting Runbook](/de/magazin/supabase-self-hosting/) - dieser Artikel
2. [Next.js über Supabase sicher betreiben](/de/magazin/nextjs-supabase-sicher-betreiben/)
3. [Supabase Edge Functions sicher einsetzen](/de/magazin/supabase-edge-functions-sicher/)
4. [Trigger.dev Background Jobs sicher betreiben](/de/magazin/trigger-dev-background-jobs/)
5. [Claude Code als Sicherheitskontrolle im DevOps-Workflow](/de/magazin/claude-code-security-devops/)
6. [Security Baseline für den gesamten Stack](/de/magazin/security-baseline-stack/)

Im nächsten Artikel zeigen wir, wie [Next.js sicher über Supabase betrieben wird](/de/magazin/nextjs-supabase-sicher-betreiben/#a1---nextjs-als-eigenen-service-betreiben), ohne typische Fehler bei Server Actions, Auth-Handling und API-Zugriffen zu machen.

--- Trigger.dev Background Jobs sicher betreiben ---
> DevOps-Runbook für Trigger.dev v3: Self-Hosted Setup, Task-Definition, Idempotenz, Concurrency, Secrets und Claude-Code-Integration.

Sobald eine Anwendung über einfache CRUD-Operationen hinausgeht, entstehen Aufgaben, die **nicht synchron im Request-Response-Zyklus laufen sollten**: E-Mail-Versand, Webhook-Verarbeitung, Import/Export Jobs, AI-Tasks, PDF-Generierung, Datenmigration und periodische Aufgaben.

Diese Aufgaben gehören **nicht in Next.js Server Actions** (blockieren den Webserver), **nicht in Supabase Edge Functions** (Timeout-Limit, keine Langläufer) und auch nicht in Cron-Jobs auf dem Server (keine Retry-Logik, kein Monitoring).

Sie gehören in eine **dedizierte Job-Schicht**. Studien zeigen, dass 35% aller Background-Job-Ausfälle durch fehlende Idempotenz bei Retries verursacht werden (Temporal.io Reliability Report 2024). In unserem Stack übernimmt **Trigger.dev** diese Rolle.

Dieses Runbook beschreibt, wie Trigger.dev sicher im Stack betrieben wird. Jeder Schritt enthält eine konkrete Implementierung mit der aktuellen Trigger.dev v3 API, eine prüfbare Bedingung und ein Failure Scenario.

> **Hinweis zur Architektur:** Trigger.dev besteht aus zwei Teilen: der **Platform** (Webapp, Dashboard, Queue Management) und dem **Worker** (führt eure Tasks aus). Wir betreiben beides self-hosted auf unserer eigenen Infrastruktur. Dieses Runbook beschreibt ausschließlich das Self-Hosted Setup mit Trigger.dev v3.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Auf einen Blick - Artikel 4 von 6 der DevOps-Runbook-Serie</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Trigger.dev als eigener Docker-Stack mit separater PostgreSQL-Instanz</li>
<li>Jeder Task braucht maxDuration, concurrencyLimit und Retry-Konfiguration</li>
<li>Idempotency Keys bei allen externen API-Calls (Stripe, SendGrid, etc.)</li>
<li>Datenbankzugriff über service_role nur auf benötigte Felder einschränken</li>
<li>Trigger.dev logger statt console.log (Logs sind persistent im Dashboard)</li>
</ul>
</div>

## Serien-Inhaltsverzeichnis

Diese Anleitung ist Teil unserer DevOps-Runbook-Serie für self-hosted App-Stacks.

1. [Supabase Self-Hosting Runbook](/de/magazin/supabase-self-hosting/)
2. [Next.js über Supabase sicher betreiben](/de/magazin/nextjs-supabase-sicher-betreiben/)
3. [Supabase Edge Functions sicher einsetzen](/de/magazin/supabase-edge-functions-sicher/)
4. [Trigger.dev Background Jobs sicher betreiben](/de/magazin/trigger-dev-background-jobs/) - dieser Artikel
5. [Claude Code als Sicherheitskontrolle im DevOps-Workflow](/de/magazin/claude-code-security-devops/)
6. [Security Baseline für den gesamten Stack](/de/magazin/security-baseline-stack/)

[Artikel 1 beschreibt die Plattform](/de/magazin/supabase-self-hosting/#a1---infrastruktur-trennen-zwei-server) mit der Server-Infrastruktur. [Artikel 2 beschreibt die App-Schicht](/de/magazin/nextjs-supabase-sicher-betreiben/#b4---mutation-pattern) mit den Mutation-Patterns. [Artikel 3 beschreibt Integrationen](/de/magazin/supabase-edge-functions-sicher/#b5---timeouts-und-langläufer-vermeiden) und die Delegation von Langläufern. Dieser Artikel beschreibt **asynchrone Job-Verarbeitung**.

## Architekturüberblick

```
Browser
   |
Next.js (App-Schicht)
   |
   +-- tasks.trigger("send-email", payload)    <- Job starten
   |
Trigger.dev Platform
   |
   +-- Queue Management
   +-- Retry Logic
   +-- Dashboard / Monitoring
   |
Trigger.dev Worker
   |
   +-- send-email.ts           -> SMTP API
   +-- generate-report.ts      -> PDF + Supabase Storage
   +-- process-webhook.ts      -> Supabase DB (service_role)
   +-- sync-crm.ts             -> externe CRM API
   |
   +-- Supabase (via service_role oder direkte DB Connection)
       |
       PostgreSQL
```

Grundregeln:

```
User Request       -> Next.js Server Action / Route Handler
Kurzer Event       -> Supabase Edge Function
Langläufer         -> Trigger.dev Task
Periodisch         -> Trigger.dev Scheduled Task
```

### Kritischer Sicherheitspunkt

Trigger.dev Tasks haben typischerweise **vollen Datenbankzugriff ohne RLS**. Sie verbinden sich entweder über den `service_role` Key (via Supabase Client) oder über eine direkte PostgreSQL-Connection (via `DATABASE_URL`). In beiden Fällen greifen Row Level Security Policies nicht. Das ist der wichtigste Unterschied zu Requests, die über PostgREST mit dem `anon` Key laufen.

Wer die [Grundlagen der Secret-Verwaltung](/de/magazin/datensicherheit-ki-enterprise/) kennt, versteht warum diese Trennung essenziell ist.

### Richtwerte für Task-Konfiguration

| Task-Typ | maxDuration | concurrencyLimit | Retry-Strategie |
|----------|-------------|-----------------|-----------------|
| E-Mail senden | 30s | 5-10 | 3x, exponential |
| PDF generieren | 120s | 2-3 | 3x, exponential |
| AI-Inference (LLM) | 300s | 1-3 | 2x, exponential |
| Datenbank-Migration | 600s | 1 | 1x, kein Retry |
| Webhook verarbeiten | 30s | 10 | 3x, exponential |
| CRM-Sync | 60s | 3-5 | 5x, exponential |

## Teil A - Architekturentscheidungen

## A1 - Trigger.dev v3 self-hosted als eigenen Service betreiben

### Umsetzung

Trigger.dev läuft getrennt von Next.js und Supabase als eigener Docker-Stack. Die Self-Hosted v3 Architektur besteht aus drei Komponenten:

```
Next.js App (euer Hetzner Server)
   |
   +-- Trigger.dev Platform (Webapp + Queue + Dashboard)
           |
           +-- Trigger.dev Worker (führt eure Tasks aus)
           |
           +-- Trigger.dev PostgreSQL (eigene DB-Instanz)
```

```yaml
# docker-compose.trigger.yml
services:
  trigger-platform:
    image: ghcr.io/triggerdotdev/trigger.dev:v3    # Version pinnen
    restart: unless-stopped
    ports:
      - "127.0.0.1:3040:3040"        # NUR localhost, Reverse Proxy davor
    environment:
      DATABASE_URL: postgresql://postgres:${TRIGGER_DB_PASSWORD}@trigger-db:5433/trigger
      DIRECT_URL: postgresql://postgres:${TRIGGER_DB_PASSWORD}@trigger-db:5433/trigger
      LOGIN_ORIGIN: https://trigger.example.com
      APP_ORIGIN: https://trigger.example.com
      MAGIC_LINK_SECRET: ${MAGIC_LINK_SECRET}
      SESSION_SECRET: ${SESSION_SECRET}
      ENCRYPTION_KEY: ${ENCRYPTION_KEY}
      RUNTIME_PLATFORM: docker-compose
      # Worker-Konfiguration
      DOCKER_SOCKET_LOCATION: /var/run/docker.sock
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock   # Worker-Management
    depends_on:
      trigger-db:
        condition: service_healthy
    networks:
      - trigger-internal

  trigger-db:
    image: postgres:15
    restart: unless-stopped
    ports:
      - "127.0.0.1:5433:5432"        # Port 5433, NICHT 5432 (Supabase nutzt 5432)
    environment:
      POSTGRES_PASSWORD: ${TRIGGER_DB_PASSWORD}
      POSTGRES_DB: trigger
    volumes:
      - trigger-db-data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 10s
      timeout: 5s
      retries: 5
    networks:
      - trigger-internal

volumes:
  trigger-db-data:

networks:
  trigger-internal:
    driver: bridge
```

**Wichtig:** Trigger.dev braucht seine **eigene PostgreSQL-Instanz** auf Port 5433. Nicht die Supabase-Datenbank (Port 5432) mitnutzen. Trigger.dev speichert Queue-Status, Run-History, Worker-State und Metadata in seiner DB. Das sind andere Daten als eure Applikationsdaten.

**SDK im Next.js Projekt konfigurieren:**

```bash
# Trigger.dev SDK installieren
npm install @trigger.dev/sdk@3

# .env (Next.js)
TRIGGER_SECRET_KEY=tr_dev_...              # aus dem self-hosted Dashboard
TRIGGER_API_URL=http://localhost:3040      # lokale Platform URL
```

**Worker Deployment:**

Im self-hosted v3 Setup deployt ihr Tasks über die CLI, die mit eurer lokalen Platform kommuniziert:

```bash
# Tasks deployen (zeigt auf eure self-hosted Platform)
npx trigger.dev@latest deploy --self-hosted

# Lokale Entwicklung
npx trigger.dev@latest dev
```

> **Hinweis:** Der v3 Docker-Worker nutzt Docker-in-Docker (Socket Mounting). Das bedeutet, die Trigger.dev Platform braucht Zugriff auf den Docker Socket (`/var/run/docker.sock`). Das hat Sicherheitsimplikationen: Ein kompromittierter Trigger.dev Container könnte beliebige Docker-Container starten. Deshalb läuft Trigger.dev idealerweise auf einem eigenen Server oder in einem isolierten Docker-Netzwerk.

### Prüfbare Bedingung

```bash
# Container laufen?
docker compose -f docker-compose.trigger.yml ps
# Erwartung: trigger-platform und trigger-db running

# Platform erreichbar (intern)?
curl -s -o /dev/null -w "%{http_code}" http://localhost:3040
# Erwartung: 200 oder 302 (Redirect zu Login)

# Platform von außen NICHT direkt erreichbar?
curl -s -o /dev/null -w "%{http_code}" https://trigger.example.com:3040
# Erwartung: Connection refused (nur über Reverse Proxy)

# Trigger.dev DB auf eigenem Port?
ss -tlnp | grep 5433
# Erwartung: Listening auf 127.0.0.1:5433

# Supabase DB auf anderem Port?
ss -tlnp | grep 5432
# Erwartung: Listening auf 10.0.1.10:5432 (internes Interface)

# Docker Socket gemountet?
docker compose -f docker-compose.trigger.yml exec trigger-platform ls -la /var/run/docker.sock
# Erwartung: Socket vorhanden
```

### Failure Scenario

Wenn Trigger.dev im selben Prozess wie Next.js läuft, blockieren lang laufende Tasks den Webserver. Ein AI-Task der 5 Minuten braucht, hält einen Next.js Worker besetzt. Bei wenigen Worker-Threads (Standard: 1 pro CPU) wird die gesamte App für User unresponsive. Wenn Trigger.dev die Supabase-DB mitnutzt, konkurrieren Job-Queue-Queries mit User-Requests um Datenbankverbindungen. Wenn der Docker Socket ohne Netzwerk-Isolation gemountet wird, kann ein kompromittierter Task Container starten die auf das Host-Netzwerk zugreifen.

## A2 - Datenbankzugriff aus Tasks kontrollieren

### Umsetzung

Tasks brauchen Zugriff auf eure Applikationsdaten in Supabase. Es gibt zwei Wege:

**Weg 1: Supabase Client mit service_role (empfohlen)**

```typescript
// trigger/lib/supabase.ts
import { createClient } from '@supabase/supabase-js'

export function createTaskClient() {
  return createClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.SUPABASE_SERVICE_ROLE_KEY!
  )
}
```

Vorteil: Geht über PostgREST, nutzt die Supabase API-Schicht.
Nachteil: Umgeht RLS (service_role).

**Weg 2: Direkte DB-Connection (für komplexe Queries)**

```typescript
// trigger/lib/db.ts
import postgres from 'postgres'

const sql = postgres(process.env.DATABASE_URL!, {
  max: 5,                    // Connection Pool limitieren
  idle_timeout: 20,
  connect_timeout: 10,
})

export { sql }
```

Nachteil: Umgeht sowohl RLS als auch PostgREST. Voller DB-Zugang.

**Regel:** Egal welcher Weg, der Task hat mehr Rechte als ein normaler User-Request. Deshalb muss jeder Task seinen eigenen Scope klar definieren.

```typescript
// RICHTIG: Task greift nur auf das zu, was er braucht
const { data } = await supabase
  .from('invoices')
  .select('id, amount, user_id')
  .eq('id', payload.invoiceId)
  .single()

// FALSCH: Task liest alle Daten einer Tabelle
const { data } = await supabase
  .from('invoices')
  .select('*')
```

Wer die [RLS-Patterns aus dem Supabase Self-Hosting Runbook](/de/magazin/supabase-self-hosting/) kennt, versteht warum der Scope-Unterschied kritisch ist.

### Prüfbare Bedingung

```bash
# Welche Tasks nutzen service_role oder DATABASE_URL?
grep -rn "SERVICE_ROLE\|DATABASE_URL\|createTaskClient\|postgres(" \
  trigger/ --include="*.ts"

# Für jeden Treffer manuell prüfen:
# - Greift der Task nur auf die Daten zu, die er braucht?
# - Ist der Input validiert bevor er in die Query fließt?
# - Gibt es einen Grund für direkten DB-Zugriff statt Supabase Client?
```

### Failure Scenario

Ein Task mit direktem DB-Zugriff und unvalidiertem Input kann zu SQL-Injection führen. Ein Task der `SELECT *` auf große Tabellen macht, kann die Datenbank-Performance für alle User beeinträchtigen. Ein unkontrollierter Connection Pool (kein `max` Limit) kann alle verfügbaren PostgreSQL-Connections belegen und die gesamte Applikation lahmlegen.

## Teil B - Implementierungschecks

Diese Regeln gelten für jeden Task und müssen bei jedem Deployment geprüft werden.

## B1 - Tasks korrekt definieren (v3 API)

### Umsetzung

Trigger.dev v3 verwendet die `task()` Funktion aus `@trigger.dev/sdk/v3`. Jeder Task wird exportiert und hat eine eindeutige ID.

```typescript
// trigger/tasks/send-welcome-email.ts
import { task } from '@trigger.dev/sdk/v3'
import { z } from 'zod'
import { createTaskClient } from '../lib/supabase'

// 1. Payload Schema definieren
const payloadSchema = z.object({
  userId: z.string().uuid(),
  email: z.string().email(),
})

export const sendWelcomeEmail = task({
  id: 'send-welcome-email',

  // 2. Retry-Strategie
  retry: {
    maxAttempts: 3,
    factor: 2,
    minTimeoutInMs: 1_000,
    maxTimeoutInMs: 30_000,
  },

  // 3. Concurrency begrenzen
  queue: {
    concurrencyLimit: 5,
  },

  // 4. Maximum Laufzeit
  maxDuration: 60,   // 60 Sekunden

  // 5. Run-Funktion
  run: async (payload) => {
    // Input validieren
    const parsed = payloadSchema.safeParse(payload)
    if (!parsed.success) {
      throw new Error(`Invalid payload: ${parsed.error.message}`)
    }

    const { userId, email } = parsed.data
    const supabase = createTaskClient()

    // User-Daten holen (nur was nötig ist)
    const { data: user } = await supabase
      .from('profiles')
      .select('full_name, locale')
      .eq('id', userId)
      .single()

    if (!user) {
      throw new Error(`User not found: ${userId}`)
    }

    // E-Mail senden
    const response = await fetch('https://api.sendgrid.com/v3/mail/send', {
      method: 'POST',
      headers: {
        'Authorization': `Bearer ${process.env.SENDGRID_API_KEY}`,
        'Content-Type': 'application/json',
      },
      body: JSON.stringify({
        personalizations: [{ to: [{ email }] }],
        from: { email: 'hello@example.com' },
        subject: `Willkommen, ${user.full_name}!`,
        content: [{ type: 'text/plain', value: `...` }],
      }),
    })

    if (!response.ok) {
      // Fehler werfen, damit Retry greift
      throw new Error(`SendGrid error: ${response.status}`)
    }

    // Status in DB aktualisieren
    await supabase
      .from('profiles')
      .update({ welcome_email_sent: true })
      .eq('id', userId)

    return { success: true, userId }
  },
})
```

### Task aus Next.js triggern

```typescript
// app/actions/auth.ts
'use server'

import { tasks } from '@trigger.dev/sdk/v3'
import type { sendWelcomeEmail } from '@/trigger/tasks/send-welcome-email'

export async function onUserSignup(userId: string, email: string) {
  // Task triggern (kehrt sofort zurück)
  const handle = await tasks.trigger<typeof sendWelcomeEmail>(
    'send-welcome-email',
    { userId, email }
  )

  // handle.id enthält die Run-ID für Tracking
  return { triggered: true, runId: handle.id }
}
```

### Prüfbare Bedingung

```bash
# Alle Tasks müssen exportiert sein
for file in trigger/tasks/*.ts; do
  if ! grep -q "export const" "$file"; then
    echo "WARNUNG: $file hat keinen exportierten Task"
  fi
done

# Alle Tasks müssen eine ID haben
grep -rn "id:" trigger/tasks/ --include="*.ts" | grep "task({" -A1

# Tasks dürfen NICHT aus Client-Code getriggert werden
grep -rn "tasks.trigger\|\.trigger(" app/ --include="*.tsx" | grep -v "use server"
# Erwartung: keine Treffer (nur in Server-Kontext)
```

### Failure Scenario

Ein Task ohne `export` wird von Trigger.dev nicht erkannt und verschwindet beim Deployment ohne Fehlermeldung. Ein Task ohne `retry` Konfiguration nutzt den Default (kein Retry), sodass ein temporärer API-Fehler (z.B. SendGrid Timeout) zum permanenten Verlust der E-Mail führt.

## B2 - Idempotenz sicherstellen

### Umsetzung

Trigger.dev hat ein eingebautes Idempotency-System über `idempotencyKey`. Das ist dem selbstgebauten `findUnique` Check vorzuziehen.

**Beim Triggern (verhindert doppeltes Auslösen):**

```typescript
// Wenn derselbe User zweimal schnell "Signup" klickt,
// wird der Task nur einmal ausgeführt
await tasks.trigger<typeof sendWelcomeEmail>(
  'send-welcome-email',
  { userId, email },
  {
    idempotencyKey: `welcome-email-${userId}`,
    idempotencyKeyTTL: '24h',     // Key gilt 24 Stunden
  }
)
```

**Innerhalb des Tasks (verhindert doppelte Seiteneffekte bei Retries):**

```typescript
import { task, idempotencyKeys } from '@trigger.dev/sdk/v3'

export const processPayment = task({
  id: 'process-payment',
  retry: { maxAttempts: 3 },

  run: async (payload: { orderId: string; amount: number }) => {
    // Idempotency Key für den Stripe-Call
    // Bei Retry wird der Stripe-Call NICHT wiederholt
    const stripeKey = await idempotencyKeys.create(
      `stripe-charge-${payload.orderId}`
    )

    const charge = await stripe.charges.create(
      {
        amount: payload.amount,
        currency: 'eur',
        source: 'tok_...',
      },
      { idempotencyKey: stripeKey }
    )

    // DB-Update ist idempotent (upsert statt insert)
    await supabase
      .from('payments')
      .upsert({
        order_id: payload.orderId,
        stripe_charge_id: charge.id,
        status: 'completed',
      }, { onConflict: 'order_id' })

    return { chargeId: charge.id }
  },
})
```

### Prüfbare Bedingung

```bash
# Tasks mit externen API-Calls sollten Idempotency Keys haben
for file in trigger/tasks/*.ts; do
  if grep -qE "fetch\(|stripe\.|sendgrid\.|resend\." "$file"; then
    if ! grep -qE "idempotencyKey|idempotencyKeys" "$file"; then
      echo "WARNUNG: $file hat externe API-Calls ohne Idempotency Key"
    fi
  fi
done
```

### Failure Scenario

Ohne Idempotenz-Schutz beim Triggern kann ein doppelter Webhook (Stripe retried bei Timeout) denselben Task zweimal auslösen. Ohne Idempotenz innerhalb des Tasks kann ein Retry nach einem Teilfehler doppelte Zahlungen oder doppelte E-Mails verursachen.

## B3 - Timeouts und Concurrency korrekt konfigurieren

### Umsetzung

Trigger.dev v3 kennt `maxDuration` (Laufzeit-Limit pro Task) und `concurrencyLimit` (parallele Ausführungen). Beide müssen pro Task bewusst gesetzt werden.

```typescript
import { task, queue } from '@trigger.dev/sdk/v3'

// Shared Queue für E-Mail-Tasks (verhindert SMTP Rate Limiting)
const emailQueue = queue({
  name: 'email-processing',
  concurrencyLimit: 5,       // max. 5 parallele E-Mail-Tasks
})

export const sendEmail = task({
  id: 'send-email',
  queue: emailQueue,
  maxDuration: 30,            // 30 Sekunden max

  run: async (payload) => {
    // ...
  },
})

// AI-Tasks brauchen mehr Zeit, aber weniger Parallelität
export const analyzeDocument = task({
  id: 'analyze-document',
  queue: { concurrencyLimit: 2 },   // max. 2 parallele AI-Calls
  maxDuration: 300,                  // 5 Minuten max

  run: async (payload) => {
    // ...
  },
})

// Kritische Tasks die sequentiell laufen müssen
export const processInvoice = task({
  id: 'process-invoice',
  queue: { concurrencyLimit: 1 },    // strikt sequentiell
  maxDuration: 60,

  run: async (payload) => {
    // ...
  },
})
```

**Richtwerte:**

```
E-Mail senden:        maxDuration 30s,    concurrency 5-10
PDF generieren:       maxDuration 120s,   concurrency 2-3
AI-Inference (LLM):   maxDuration 300s,   concurrency 1-3
Datenbank-Migration:  maxDuration 600s,   concurrency 1
Webhook verarbeiten:  maxDuration 30s,    concurrency 10
```

### Prüfbare Bedingung

```bash
# Alle Tasks müssen maxDuration haben
for file in trigger/tasks/*.ts; do
  if ! grep -q "maxDuration" "$file"; then
    echo "WARNUNG: $file hat kein maxDuration"
  fi
done

# Alle Tasks müssen concurrencyLimit haben (oder eine shared Queue nutzen)
for file in trigger/tasks/*.ts; do
  if ! grep -qE "concurrencyLimit|queue:" "$file"; then
    echo "WARNUNG: $file hat kein Concurrency Limit"
  fi
done
```

### Failure Scenario

Ohne `maxDuration` kann ein Task bei einem hängenden API-Call unendlich laufen und einen Worker-Slot dauerhaft blockieren. Ohne `concurrencyLimit` können 100 gleichzeitig getriggerte E-Mail-Tasks den SMTP-Provider überlasten und zu Rate Limiting führen. Ohne Concurrency Limit auf DB-intensiven Tasks können alle PostgreSQL-Connections gleichzeitig belegt werden.

## B4 - Secrets und Environment Variables

### Umsetzung

Trigger.dev Tasks laufen in einer separaten Umgebung. Secrets müssen explizit über die Docker-Compose-Konfiguration übergeben werden.

```bash
# .env.trigger (nur auf dem Server, nicht im Git)
TRIGGER_DB_PASSWORD=...
MAGIC_LINK_SECRET=...
SESSION_SECRET=...
ENCRYPTION_KEY=...

# Secrets für eure Tasks (werden an Worker weitergereicht)
SUPABASE_SERVICE_ROLE_KEY=eyJ...
DATABASE_URL=postgresql://...
SENDGRID_API_KEY=SG.xxx
OPENAI_API_KEY=sk-xxx
STRIPE_SECRET_KEY=sk_live_xxx
```

Die Task-Secrets werden im self-hosted Setup über das Trigger.dev Dashboard (Environment Variables) oder über die Docker-Umgebung an die Worker-Container weitergegeben.

Im Code:

```typescript
// RICHTIG: Environment Variable
const apiKey = process.env.SENDGRID_API_KEY

// FALSCH: Hardcoded
const apiKey = 'SG.xxx...'
```

### Prüfbare Bedingung

```bash
# Hardcoded Secrets?
grep -rn "sk_live\|sk_test\|SG\.\|sk-\|Bearer ey" \
  trigger/ --include="*.ts"
# Erwartung: keine Treffer

# .env.trigger nicht im Git?
git ls-files .env.trigger
# Erwartung: leer

# Alle benötigten Env Vars gesetzt?
for var in SUPABASE_SERVICE_ROLE_KEY SENDGRID_API_KEY; do
  if [ -z "${!var}" ]; then
    echo "FEHLT: $var"
  fi
done
```

### Failure Scenario

Secrets in Task-Dateien landen im Git-Repository und im Build-Artifact (Worker Image). Im self-hosted Setup werden Worker-Images lokal gebaut und gespeichert. Hardcoded Secrets in diesen Images sind für jeden mit Zugang zum Docker-Host oder zur Registry sichtbar.

## B5 - Error Handling und Logging

### Umsetzung

Tasks müssen Fehler sauber behandeln und keine sensiblen Daten loggen.

```typescript
import { task, logger } from '@trigger.dev/sdk/v3'

export const processOrder = task({
  id: 'process-order',

  retry: {
    maxAttempts: 3,
    factor: 2,
    minTimeoutInMs: 1_000,
    maxTimeoutInMs: 30_000,
  },

  run: async (payload: { orderId: string }) => {
    // Trigger.dev Logger (strukturiert, im Dashboard sichtbar)
    logger.info('Processing order', { orderId: payload.orderId })

    try {
      const result = await processOrderInternal(payload.orderId)

      logger.info('Order processed', {
        orderId: payload.orderId,
        status: result.status,
      })

      return result

    } catch (error) {
      // Strukturiert loggen (ohne sensible Details)
      logger.error('Order processing failed', {
        orderId: payload.orderId,
        errorMessage: error instanceof Error ? error.message : 'Unknown error',
        // NICHT: error.stack, payload Details, User-Daten
      })

      // Fehler weiterwerfen, damit Retry greift
      throw error
    }
  },

  // onFailure Hook: wird nach allen Retries aufgerufen
  onFailure: async (payload, error, params) => {
    logger.error('Order permanently failed after all retries', {
      orderId: payload.orderId,
      attemptNumber: params.run.attemptNumber,
    })

    // Alert senden (z.B. Slack Notification)
    await sendAlertToOps({
      task: 'process-order',
      orderId: payload.orderId,
      error: error.message,
    })
  },
})
```

**Was NICHT geloggt werden darf:**

```typescript
// FALSCH
logger.info('Processing user', { user })             // vollständiges User-Objekt
logger.info('API call', { headers: req.headers })     // Auth-Header mit Token
logger.info('DB query', { connectionString })         // Datenbank-URL
console.log(process.env.SUPABASE_SERVICE_ROLE_KEY)    // Secret
```

### Prüfbare Bedingung

```bash
# console.log statt logger?
grep -rn "console\.log\|console\.error" trigger/tasks/ --include="*.ts"
# Erwartung: keine Treffer (immer logger von @trigger.dev/sdk verwenden)

# Sensible Daten in Logs?
grep -rn "logger\.\(info\|error\|warn\)" trigger/ --include="*.ts" | \
  grep -iE "password|secret|key|token|email.*:" | \
  grep -v "orderId\|taskId\|runId"
# Erwartung: keine Treffer
```

### Failure Scenario

Trigger.dev speichert alle Logs und zeigt sie im Dashboard. Wenn `console.log(user)` ein vollständiges User-Objekt mit E-Mail und Metadaten loggt, sind diese Daten im Trigger.dev Dashboard für jeden mit Dashboard-Zugang sichtbar, auch Monate später, da Run-History persistent ist.

## Teil C - Betrieb und Überwachung

## C1 - Monitoring und Alerting

### Umsetzung

Trigger.dev hat ein eingebautes Dashboard mit Run-History, Logs und Traces. Zusätzlich sollten diese Metriken aktiv überwacht werden:

```
Kritische Metriken:
  - Failed Runs (letzte 24h)        -> Alert wenn > 5
  - Queue Length                     -> Alert wenn > 100
  - Average Run Duration             -> Alert wenn > 2x Baseline
  - Runs in WAITING State            -> Info, kein sofortiger Alert
```

**Self-Hosted Dashboard absichern:**

```
# Das Trigger.dev Dashboard darf NICHT öffentlich erreichbar sein
# Zugang nur über:
# - Reverse Proxy mit Basic Auth
# - VPN / WireGuard
# - SSH Tunnel

# Beispiel: SSH Tunnel zum Dashboard
ssh -L 3040:localhost:3040 deploy@trigger-server

# Dann im Browser: http://localhost:3040
```

**Automatisierter Health Check:**

```bash
#!/bin/bash
# scripts/check-trigger-health.sh

# Trigger.dev Platform erreichbar?
HEALTH=$(curl -s -o /dev/null -w "%{http_code}" http://localhost:3040/healthcheck)
if [ "$HEALTH" != "200" ]; then
  echo "KRITISCH: Trigger.dev Platform nicht erreichbar"
fi

# Worker-Container läuft?
WORKER_STATUS=$(docker compose -f docker-compose.trigger.yml ps trigger-worker --format '{{.State}}')
if [ "$WORKER_STATUS" != "running" ]; then
  echo "KRITISCH: Trigger.dev Worker nicht running ($WORKER_STATUS)"
fi

# Failed Runs der letzten 24h (über Trigger.dev DB)
FAILED=$(docker compose -f docker-compose.trigger.yml exec -T trigger-db \
  psql -U postgres -d trigger -t -c \
  "SELECT count(*) FROM task_runs WHERE status = 'FAILED' AND created_at > now() - interval '24 hours';" 2>/dev/null)

if [ "${FAILED:-0}" -gt 5 ]; then
  echo "WARNUNG: $FAILED fehlgeschlagene Runs in den letzten 24h"
fi
```

### Prüfbare Bedingung

```bash
# Dashboard nur intern erreichbar?
curl -s -o /dev/null -w "%{http_code}" https://trigger.example.com:3040
# Erwartung: Connection refused oder 401

# Health Check Script läuft täglich?
crontab -l | grep "check-trigger-health"
# Erwartung: Eintrag vorhanden
```

## C2 - Dead Letter Handling

### Umsetzung

Tasks die nach allen Retries fehlschlagen, landen im `FAILED` Status. Diese müssen aktiv bearbeitet werden.

```typescript
import { task, logger } from '@trigger.dev/sdk/v3'
import { createTaskClient } from '../lib/supabase'

export const criticalTask = task({
  id: 'critical-task',

  retry: {
    maxAttempts: 5,
    factor: 2,
    minTimeoutInMs: 2_000,
    maxTimeoutInMs: 60_000,
  },

  run: async (payload: { orderId: string }) => {
    // ... Task-Logik
  },

  onFailure: async (payload, error, params) => {
    const supabase = createTaskClient()

    // Failed Job in eigene Tabelle schreiben
    await supabase
      .from('failed_jobs')
      .insert({
        task_id: 'critical-task',
        payload: JSON.stringify(payload),
        error_message: error.message,
        attempts: params.run.attemptNumber,
        failed_at: new Date().toISOString(),
        resolved: false,
      })

    // Alert
    logger.error('Critical task permanently failed', {
      orderId: payload.orderId,
      attempts: params.run.attemptNumber,
    })
  },
})
```

```sql
-- Migration: failed_jobs Tabelle
CREATE TABLE IF NOT EXISTS failed_jobs (
  id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
  task_id TEXT NOT NULL,
  payload JSONB NOT NULL,
  error_message TEXT,
  attempts INTEGER,
  failed_at TIMESTAMPTZ NOT NULL,
  resolved BOOLEAN DEFAULT false,
  resolved_at TIMESTAMPTZ,
  resolved_by TEXT
);

-- RLS: nur service_role darf zugreifen
ALTER TABLE failed_jobs ENABLE ROW LEVEL SECURITY;
-- Keine Policy für anon/authenticated = kein Zugriff über PostgREST
```

### Prüfbare Bedingung

```bash
# Gibt es unresolvierte Failed Jobs?
# Über Supabase Client oder direkte DB-Query
psql -c "SELECT count(*) FROM failed_jobs WHERE resolved = false;"
# Erwartung: 0 (oder aktiv in Bearbeitung)

# Haben alle kritischen Tasks einen onFailure Hook?
grep -L "onFailure" trigger/tasks/*.ts
# Erwartung: nur unkritische Tasks ohne onFailure
```

## C3 - Claude Code Integration

### Architektur

```
Git Push / PR
   |
   +-- Deterministische Checks (CI/CD)
   |   +-- Alle Tasks haben maxDuration?
   |   +-- Alle Tasks haben concurrencyLimit?
   |   +-- Externe API-Calls haben Idempotency Keys?
   |   +-- Keine hardcoded Secrets?
   |   +-- Kein console.log (nur logger)?
   |
   +-- Claude Code Analyse (wöchentlich oder bei PR)
       +-- Neue Tasks ohne Retry-Strategie?
       +-- DB-Zugriff korrekt eingeschränkt?
       +-- Idempotenz-Patterns konsistent?
       +-- onFailure für kritische Tasks vorhanden?
       +-- Concurrency Limits angemessen?
```

### CI-Script

```bash
#!/bin/bash
# scripts/check-trigger-tasks.sh

REPORT=""

# 1. Tasks ohne maxDuration
for file in trigger/tasks/*.ts; do
  name=$(basename "$file" .ts)
  if ! grep -q "maxDuration" "$file"; then
    REPORT+="WARNUNG: $name hat kein maxDuration\n"
  fi
done

# 2. Tasks ohne Concurrency
for file in trigger/tasks/*.ts; do
  name=$(basename "$file" .ts)
  if ! grep -qE "concurrencyLimit|queue:" "$file"; then
    REPORT+="WARNUNG: $name hat kein Concurrency Limit\n"
  fi
done

# 3. Externe API-Calls ohne Idempotency
for file in trigger/tasks/*.ts; do
  name=$(basename "$file" .ts)
  if grep -qE "fetch\(|stripe\.|resend\." "$file"; then
    if ! grep -qE "idempotencyKey|idempotencyKeys" "$file"; then
      REPORT+="WARNUNG: $name hat externe API-Calls ohne Idempotency\n"
    fi
  fi
done

# 4. Hardcoded Secrets
SECRETS=$(grep -rn "sk_live\|sk_test\|SG\.\|sk-" trigger/ --include="*.ts" 2>/dev/null)
if [ -n "$SECRETS" ]; then
  REPORT+="KRITISCH: Hardcoded Secrets:\n$SECRETS\n\n"
fi

# 5. console.log statt logger
CONSOLE=$(grep -rn "console\.\(log\|error\|warn\)" trigger/tasks/ --include="*.ts" 2>/dev/null)
if [ -n "$CONSOLE" ]; then
  REPORT+="WARNUNG: console.log statt Trigger.dev logger:\n$CONSOLE\n\n"
fi

# 6. Nicht exportierte Tasks
for file in trigger/tasks/*.ts; do
  name=$(basename "$file" .ts)
  if ! grep -q "export const" "$file"; then
    REPORT+="KRITISCH: $name Task ist nicht exportiert\n"
  fi
done

if [ -n "$REPORT" ]; then
  echo -e "=== Trigger.dev Task Security Check ===\n$REPORT"
else
  echo "Alle Trigger.dev Checks bestanden."
fi
```

Claude führt **keine automatischen Änderungen auf Production** aus.

## Deployment-Checkliste

Vor jedem Deployment von Trigger.dev Tasks prüfen:

```
Architektur
  [ ] Trigger.dev läuft als eigener Service (nicht im Next.js Prozess)
  [ ] Eigene PostgreSQL-Instanz (nicht Supabase DB)
  [ ] Dashboard nur intern erreichbar

Task-Definition
  [ ] Jeder Task ist exportiert
  [ ] Jeder Task hat eine eindeutige ID
  [ ] Jeder Task hat maxDuration
  [ ] Jeder Task hat concurrencyLimit oder shared Queue
  [ ] Jeder Task hat retry Konfiguration

Idempotenz
  [ ] Trigger-Aufrufe haben idempotencyKey wo nötig
  [ ] Externe API-Calls innerhalb von Tasks haben Idempotency
  [ ] DB-Operationen sind idempotent (upsert statt insert wo möglich)

Datenbankzugriff
  [ ] service_role nur über createTaskClient()
  [ ] Queries greifen nur auf benötigte Daten zu (kein SELECT *)
  [ ] Connection Pool limitiert (max: 5-10)

Secrets
  [ ] Keine hardcoded Secrets im Code
  [ ] Secrets über Environment Variables / Dashboard
  [ ] .env.trigger nicht im Git

Logging
  [ ] Trigger.dev logger statt console.log
  [ ] Keine sensiblen Daten in Logs (User-Objekte, Tokens, Keys)

Error Handling
  [ ] Kritische Tasks haben onFailure Hook
  [ ] Failed Jobs werden in failed_jobs Tabelle gespeichert
  [ ] Alerting bei dauerhaften Fehlern konfiguriert
```

## Fazit

Trigger.dev bildet die Background-Processing-Schicht im Stack. Richtig eingesetzt verarbeitet es asynchrone Jobs zuverlässig, mit Retries, Idempotenz und Monitoring.

Der kritischste Sicherheitspunkt ist der Datenbankzugriff: Tasks haben typischerweise mehr Rechte als normale User-Requests, weil sie mit `service_role` oder direkter DB-Connection arbeiten. Deshalb müssen Input Validation, Scope-Begrenzung und Idempotenz bei jedem Task bewusst implementiert werden.

Die Kombination aus der eingebauten Trigger.dev Retry-Logik, bewussten Concurrency Limits und kontextueller Claude Code Analyse führt zu stabilen Background-Workflows, die auch bei Teilausfällen korrekt funktionieren.

Wer diese Prinzipien zusammen mit einer [Cert-Ready-by-Design-Architektur](/de/magazin/cert-ready-by-design/) verfolgt, baut prüfbare Sicherheit statt nachträglicher Audits.

<div class="not-prose my-12 border border-gosign-border bg-gosign-light rounded-card p-6 lg:p-8">
<div class="flex items-start gap-4">
<div class="flex-shrink-0 w-12 h-12 bg-gosign-dark rounded-card flex items-center justify-center">
<svg width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="white" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 15v4a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2v-4"/><polyline points="7 10 12 15 17 10"/><line x1="12" y1="15" x2="12" y2="3"/></svg>
</div>
<div>
<h2 class="text-h3 font-bold text-gosign-dark mb-2" id="audit-checkliste-als-download">Audit-Checkliste als Download</h2>
<p class="text-body text-gosign-text mb-2">Vorbereiteter Prompt für Claude Code. Laden Sie die Datei auf Ihren Server und starten Sie Claude Code im Projektverzeichnis Ihres Trigger.dev-Setups. Claude Code prüft automatisch alle Sicherheitspunkte aus diesem Runbook und meldet BESTANDEN, WARNUNG oder KRITISCH.</p>
<p class="text-sm text-gosign-text mb-4 font-mono">claude -p "$(cat claude-check-artikel-4-trigger-dev.md)" --allowedTools Read,Grep,Glob,Bash</p>
<a href="/downloads/claude-check-artikel-4-trigger-dev.md" download class="inline-flex items-center px-6 py-3 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-small uppercase tracking-wider">Checkliste herunterladen</a>
</div>
</div>
</div>

## Serien-Inhaltsverzeichnis

1. [Supabase Self-Hosting Runbook](/de/magazin/supabase-self-hosting/)
2. [Next.js über Supabase sicher betreiben](/de/magazin/nextjs-supabase-sicher-betreiben/)
3. [Supabase Edge Functions sicher einsetzen](/de/magazin/supabase-edge-functions-sicher/)
4. [Trigger.dev Background Jobs sicher betreiben](/de/magazin/trigger-dev-background-jobs/) - dieser Artikel
5. [Claude Code als Sicherheitskontrolle im DevOps-Workflow](/de/magazin/claude-code-security-devops/)
6. [Security Baseline für den gesamten Stack](/de/magazin/security-baseline-stack/)

Der nächste Artikel beschreibt, wie [Claude Code als kontextuelle Analyse-Schicht im DevOps Workflow](/de/magazin/claude-code-security-devops/#grundprinzip-drei-ebenen-der-sicherheitsprüfung) eingesetzt wird - als die übergreifende Sicherheitskontrolle über alle bisherigen Artikel hinweg.

--- Warum KI-Projekte in HR scheitern ---
> KI-Projekte scheitern nicht an Technologie, sondern an fehlenden Spielregeln. Warum das Operating Model wichtiger ist als das Sprachmodell.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Auf einen Blick - Warum KI-Projekte scheitern</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Die meisten KI-Projekte scheitern nicht an der Technologie. Sie scheitern daran, dass niemand definiert hat, welche Entscheidungen die KI treffen darf und welche beim Menschen bleiben müssen.</li>
<li>Das AI-Paradox: Unternehmen setzen KI breit ein, aber nur ein Bruchteil erzielt messbare Ergebnisse - die Entscheidungsarchitektur fehlt.</li>
<li>MIT Sloan Management Review (2024) zeigt, dass 70 % der Enterprise-KI-Initiativen den Sprung vom Piloten in die Produktion nicht schaffen.</li>
<li>Investment-Ratio: Für jeden Euro in Technologie brauchen Unternehmen vier bis fünf Euro in Prozesse, Governance und Change Management. Technologie allein adressiert etwa 20 % des Problems.</li>
<li>Der Decision Layer zerlegt Geschäftsprozesse in dokumentierte Entscheidungsschritte - Mensch, Regelwerk oder KI - und macht aus KI-Experimenten produktive Systeme.</li>
</ul>
</div>

## Ein Pilotprojekt, das funktioniert hat - und dann verschwand

Eine HR-Abteilung startet ein KI-Projekt. Ein Agent verarbeitet Krankmeldungen: liest das Dokument, extrahiert die Daten, prüft gegen den Tarifvertrag, erstellt einen Vorschlag für SAP SuccessFactors. Im Piloten funktioniert alles. Die Trefferquote liegt bei 94%. Die Bearbeitungszeit sinkt von 45 Minuten auf 5 Minuten.

Sechs Monate später: Der Agent läuft immer noch im Piloten. Nicht weil die Technologie versagt hat. Sondern weil niemand die Fragen beantwortet hat, die nach dem Piloten kommen:

Wer genehmigt die Buchung die der Agent vorschlägt? Was passiert wenn der Agent falsch liegt - wer haftet? Gilt die Logik auch für Standort München, wo ein anderer Tarifvertrag gilt? Darf der Agent bei Langzeiterkrankungen automatisch ein BEM-Verfahren einleiten, oder muss das ein Mensch entscheiden? Was sagt der Betriebsrat?

Das sind keine technischen Fragen. Es sind Entscheidungsfragen. Und solange sie nicht beantwortet sind, bleibt jeder Agent ein Experiment.

## Das AI-Paradox: Hoher Einsatz, niedriger Nutzen

Was hier passiert, ist kein Einzelfall. Es ist ein Muster das sich durch Unternehmen jeder Größe zieht.

Die meisten Unternehmen setzen bereits KI ein - mindestens in Form von Chatbots, Copilot-Lizenzen oder ersten Piloten. Aber die wenigsten berichten, dass KI einen messbaren Beitrag zum Ergebnis leistet.

Das ist das AI-Paradox: Die Technologie funktioniert. Aber der Nutzen bleibt aus.

Die üblichen Erklärungen greifen zu kurz. "Die Daten sind nicht gut genug" - stimmt manchmal, aber Datenqualität ist ein lösbares Problem. "Das Modell ist nicht gut genug" - unwahrscheinlich, wenn man sieht was aktuelle Sprachmodelle leisten. "Die Mitarbeiter haben Angst vor KI" - Change Management ist wichtig, erklärt aber nicht warum auch gut begleitete Projekte stecken bleiben.

Die eigentliche Ursache ist eine andere: Es fehlt die Entscheidungsarchitektur.

## Was fehlt: Nicht bessere Technologie - sondern klare Spielregeln

Ein KI-Agent der Krankmeldungen verarbeitet, trifft bei jedem Beleg fünf bis zehn einzelne Entscheidungen: Ist das Dokument vollständig? Welcher Tarifvertrag gilt? Liegt eine Langzeiterkrankung vor? Muss ein BEM-Verfahren eingeleitet werden? In welches System wird gebucht?

Für jede einzelne dieser Entscheidungen muss vorab definiert sein:

**Entscheidet ein Mensch?** Die Architektur erzwingt menschliche Prüfung - zum Beispiel bei Langzeiterkrankungen, weil ein BEM-Verfahren Ermessensspielraum erfordert, Diskriminierungspotenzial besteht oder der Betriebsrat Mitbestimmung verlangt. Technisch erzwungen, nicht organisatorisch vereinbart.

**Entscheidet ein Regelwerk?** Die Entscheidung ist deterministisch - es gibt keinen Interpretationsspielraum. Tarifvertrag sagt X, also gilt X. Frist läuft ab, also greift die Regel. Das Regelwerk ist versioniert, jede Änderung nachvollziehbar.

**Entscheidet die KI eigenständig?** Der Agent trifft autonome Entscheidungen - weil er confident genug ist, die Erlaubnis hat, und die Aufgabe nachweislich besser erledigt als manuelle Bearbeitung. Er interpretiert Dokumente, klassifiziert Sachverhalte, bewertet Kontext. Das ist kein If-Then-Else - das ist Urteilsvermögen innerhalb definierter Leitplanken.

Ohne diese Zuordnung bleibt der Agent eine Blackbox. Er produziert Ergebnisse, aber niemand kann nachvollziehen auf welcher Grundlage. Kein Wirtschaftsprüfer akzeptiert das. Kein Betriebsrat stimmt dem zu. Keine Compliance-Abteilung gibt das frei.

## Die Investment-Ratio: Warum Technologie allein nicht reicht

Branchenerfahrung zeigt eine Faustregel die viele überrascht: Für jeden Euro in Technologie brauchen Unternehmen vier bis fünf Euro in Prozesse, Governance und Veränderungsmanagement.

Das bedeutet: Wer ein KI-Budget von 500.000 EUR hat und alles in Lizenzen und Modelle investiert, adressiert etwa 20% des Problems. Die restlichen 80% - Prozessdesign, Entscheidungsregeln, Betriebsvereinbarungen, Schulungen, Governance-Strukturen - bleiben unbearbeitet.

Das erklärt das AI-Paradox. Es ist kein Technologie-Problem. Es ist ein Investitions-Problem. Oder genauer: ein Investitions-Verteilungs-Problem.

## Was das für HR bedeutet

HR-Prozesse sind besonders anfällig für das AI-Paradox. Aus drei Gründen:

**Erstens: Hohe Regelkomplexität.** Tarifverträge, Betriebsvereinbarungen, länderspezifische Gesetze, interne Richtlinien. Ein einziger Prozess wie die Krankmeldungsverarbeitung kann fünf verschiedene Regelwerke berühren.

**Zweitens: Mitbestimmung.** In Deutschland hat der Betriebsrat bei KI-Systemen die Mitarbeiterdaten verarbeiten ein Mitspracherecht. Ohne nachvollziehbare Entscheidungslogik kann der Betriebsrat nicht prüfen, was der Agent tut.

**Drittens: Haftung.** Wenn ein Agent eine fehlerhafte Gehaltsabrechnung erzeugt, haftet nicht der Agent. Es haftet das Unternehmen. Ohne dokumentierten Entscheidungspfad ist unklar, wo der Fehler entstanden ist.

## Erst die Entscheidungen sichtbar machen, dann automatisieren

Die Lösung ist nicht weniger KI. Die Lösung ist mehr Struktur.

Bevor ein Agent einen Prozess automatisiert, muss der Prozess in einzelne Entscheidungsschritte zerlegt werden. Für jeden Schritt wird definiert: Mensch, Regelwerk oder KI. Diese Zuordnung ist nicht statisch - sie kann sich ändern, wenn ein Regelwerk sich ändert oder wenn der Agent mehr Erfahrung sammelt.

Der [Decision Layer](/de/decision-layer/) implementiert genau das. Er zerlegt jeden Geschäftsprozess in einzelne Entscheidungsschritte und definiert für jeden Schritt vorab: Mensch, Regelwerk oder KI eigenständig. Wo Ermessensspielraum oder Mitbestimmung eine Rolle spielen, erzwingt die Architektur menschliche Prüfung. Wo die Entscheidung deterministisch ist, wendet der Agent das Regelwerk konsistent an. Und wo der Agent confident genug ist: entscheidet er eigenständig - mit vollständigem Audit Trail.

Das Ergebnis: Aus einem KI-Experiment wird ein produktives System. Eines das der Betriebsrat prüfen kann, das der Wirtschaftsprüfer akzeptiert und das über Standorte hinweg konsistent funktioniert.

## KI-Projekt-Fehlermuster

| Fehlermuster | Ursache | Lösung |
|---|---|---|
| Pilot funktioniert, skaliert aber nie | Entscheidungsregeln nicht definiert - niemand beantwortet die Fragen nach dem Piloten | Decision Layer: Mensch/Regelwerk/KI-Zuordnung pro Schritt vor der Skalierung definieren |
| Hohe Nutzung, aber kein messbarer Nutzen | Investment auf Technologie konzentriert, Prozesse und Governance vernachlässigt | Umverteilen: 20 % Technologie, 80 % Prozesse, Governance, Change Management |
| Betriebsrat blockiert Rollout | KI-Entscheidungen nicht nachvollziehbar, kein Audit Trail | Transparenz auf Architekturebene: versionierte Regeln, vollständiger Audit Trail |
| Agent erzeugt Fehler, die niemand erklären kann | Blackbox-Entscheidungen ohne dokumentierten Entscheidungspfad | Confidence Routing: Eskalationsschwellen, Human-in-the-Loop bei Grenzfällen |
| Unterschiedliche Ergebnisse an verschiedenen Standorten | Regelwerke variieren, aber Agent-Logik ist einheitlich | Standortbezogene Regelwerk-Engine mit versionierten, testbaren Regelwerken |

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Kostenloses eBook: KI in HR</p>
<p class="text-body text-gosign-text mb-4">EU AI Act Checkliste, Decision-Framework, Betriebsrats-Perspektive und Readiness-Assessment - das Governance-Handbuch für HR-Verantwortliche.</p>
<a href="/de/ebook/ki-hr-governance-handbuch/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Jetzt kostenlos herunterladen</a>
</div>

## Fazit

Das AI-Paradox ist kein unvermeidliches Schicksal. Es ist die Konsequenz einer Fehlallokation: zu viel Investment in Technologie, zu wenig in die Spielregeln die bestimmen, was die Technologie tun darf.

Unternehmen die das verstehen, investieren nicht in das nächste Sprachmodell - sie investieren in ihre Entscheidungsarchitektur. Und genau dort liegt der Unterschied zwischen einem KI-Piloten der in der Schublade landet und einem System das in Produktion läuft.

→ [Decision Layer - Übersicht und Beispiele](/de/decision-layer/)

→ [Drei Arten von Entscheidungen: Wann der Mensch, wann die KI](/de/magazin/drei-arten-von-entscheidungen/)

--- Warum Pair Programming keine Option ist ---
> 15% Mehraufwand, 60% weniger Defekte, 40% schnelleres Onboarding. Die wissenschaftliche Evidenz für Pair Programming - mit allen KPIs und Quellenbelegen.

Zwei Entwickler, ein Bildschirm, ein Problem. Was nach Verschwendung klingt, ist die am besten belegte Methode der Softwareentwicklung - und trotzdem ignorieren die meisten Unternehmen sie. In diesem Artikel haben wir 25 Jahre Forschungsdaten zusammengetragen: von Williams' Pionierstudien an der University of Utah über Cockburns Feldexperimente bis zu Arisholms kontrollierten Studien bei Simula Research. Das Ergebnis ist eindeutig. Pair Programming kostet 15% mehr Zeit - und spart ein Vielfaches davon durch weniger Bugs, schnelleres Onboarding und Code, den mehr als eine Person versteht. Wer nach dem Lesen immer noch allein programmieren lässt, tut das nicht aus Überzeugung, sondern aus Gewohnheit.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Auf einen Blick - Pair Programming</p>
<ul class="text-body text-gosign-text space-y-2">
<li>15% mehr Entwicklungszeit, aber 15-60% weniger Defekte - das zeigen replizierte Studien mit Hunderten professioneller Entwickler (Williams & Kessler, 2000; Arisholm et al., 2007).</li>
<li>Paare berücksichtigen 40% mehr Randfälle als Solo-Entwickler, weil sich die kognitive Last auf zwei Arbeitsgedächtnisse verteilt (Cognitive Load Theory).</li>
<li>Onboarding beschleunigt sich um 30-50%, der Bus Factor steigt von 1 auf mindestens 2, und 96% der Teilnehmer würden Pairing weiterempfehlen.</li>
<li>Laut NIST verursachen Software-Defekte in den USA jährlich 59,5 Milliarden USD Kosten - 37% davon wären durch frühere Erkennung vermeidbar.</li>
<li>In der KI-Ära wird Pairing wichtiger: 68% der Entwickler sprechen an manchen Tagen mit niemandem fachlich (Microsoft Work Trend Index, 2024).</li>
</ul>
</div>

## Der Mythos vom einsamen Genie

Die romantische Vorstellung hält sich hartnäckig: Ein brillanter Entwickler sitzt allein vor dem Bildschirm, denkt scharf nach und produziert eleganten Code. Linus Torvalds schrieb Git an einem Wochenende. John Carmack baute Doom-Engines im Alleingang.

Diese Geschichten sind wahr. Sie sind auch irrelevant.

Enterprise-Software ist kein Wochenendprojekt. Sie besteht aus Hunderten von Integrationen, regulatorischen Anforderungen, Team-Übergaben und Systemen die seit Jahren gewachsen sind. In diesem Kontext ist allein arbeiten kein Zeichen von Produktivität. Es ist ein Risikofaktor.

Die Forschung der letzten 25 Jahre ist erstaunlich eindeutig. Die Zahlen:

- **15%** mehr Gesamtentwicklungszeit - nicht 100% <sup>[1]</sup>
- **15-60%** weniger Defekte im Code <sup>[1][4]</sup>
- **29%** schnellere Fertigstellung bei komplexen Aufgaben <sup>[2]</sup>
- **30-50%** schnelleres Onboarding neuer Teammitglieder <sup>[1]</sup>
- **95%** der Pairing-Teilnehmer berichten höhere Zufriedenheit <sup>[2]</sup>
- **48%** weniger Codezeilen bei gleicher Funktionalität <sup>[1]</sup>
- **30x** höhere Kosten wenn Fehler erst in Produktion gefunden werden <sup>[6]</sup>

Das ist kein Bauchgefühl. Das sind replizierte Studienergebnisse aus kontrollierten Experimenten mit Hunderten professioneller Entwickler.

## Die KPI-Sammlung: 25 Jahre Forschung in Zahlen

### Defektdichte und Codequalität

| Studie | n | KPI | Ergebnis |
|--------|---|-----|----------|
| Williams & Kessler (2000) <sup>[1]</sup> | 41 | Testfälle auf Anhieb bestanden | **+15%** vs. Solo |
| Williams & Kessler (2000) <sup>[1]</sup> | 41 | Defektdichte | **signifikant niedriger** |
| Nosek (1998) <sup>[2]</sup> | 15 | Funktionale Korrektheit | **höher** bei Paaren |
| Nosek (1998) <sup>[2]</sup> | 15 | Code-Lesbarkeit | **höher** bei Paaren |
| Arisholm et al. (2007) <sup>[4]</sup> | 295 | Fehlerrate (komplexe Aufgaben) | **-60%** vs. Solo |
| Arisholm et al. (2007) <sup>[4]</sup> | 295 | Fehlerrate (einfache Aufgaben) | **marginal** |
| Dybå et al. (2007) <sup>[5]</sup> | 18 Studien | Codequalität gesamt | **statistisch signifikant besser** |
| Jensen (2003) <sup>[16]</sup> | 120 | Defekte nach Abnahme | **-40%** |
| Padberg & Müller (2003) <sup>[17]</sup> | Simulation | Post-Release Defects | **-20 bis -40%** |

### Zeitaufwand und Produktivität

| Studie | n | KPI | Ergebnis |
|--------|---|-----|----------|
| Williams & Kessler (2000) <sup>[1]</sup> | 41 | Gesamtentwicklungszeit | **+15%** (nicht +100%) |
| Nosek (1998) <sup>[2]</sup> | 15 | Elapsed Time (komplexe Aufgabe) | **-29%** schneller |
| Arisholm et al. (2007) <sup>[4]</sup> | 295 | Aufwand (einfache Aufgaben) | **+84%** |
| Arisholm et al. (2007) <sup>[4]</sup> | 295 | Aufwand (komplexe Aufgaben) | **+18%** |
| Cockburn & Williams (2001) <sup>[3]</sup> | Review | Break-Even bei Defektreduktion | **ab 3-5%** |
| Lui & Chan (2006) <sup>[18]</sup> | 40 | Aufgaben-Durchsatz | **+43%** vs. Solo |

### Zufriedenheit und Teamdynamik

| Studie | n | KPI | Ergebnis |
|--------|---|-----|----------|
| Nosek (1998) <sup>[2]</sup> | 15 | Zufriedenheit mit Ergebnis | **+95%** bei Paaren |
| Williams et al. (2000) <sup>[1]</sup> | 41 | Empfehlung an Kollegen | **96%** würden wieder pairen |
| Begel & Nagappan (2008) <sup>[19]</sup> | 106 | Zufriedenheit mit Pairing (Microsoft) | **65%** zufrieden |
| Begel & Nagappan (2008) <sup>[19]</sup> | 106 | Sehen Qualitätsgewinn (Microsoft) | **74%** |

### Code-Effizienz

| Studie | KPI | Ergebnis |
|--------|-----|----------|
| Williams & Kessler (2000) <sup>[1]</sup> | Lines of Code (gleiche Funktionalität) | **-48%** weniger Zeilen |
| Müller (2004) <sup>[20]</sup> | Zyklomatische Komplexität | **niedriger** bei Paaren |

Die Kernaussage über alle Studien: Pair Programming kostet etwas mehr Zeit. Es produziert weniger Code, der weniger Fehler hat, einfacher zu warten ist und von mehr Personen verstanden wird.

## "Ich bin aber schneller allein" - Was Entwickler wirklich stört

Reden wir über den Elefanten im Raum. Die meisten Entwickler die Pair Programming ablehnen, haben keine Zahlen dagegen. Sie haben ein Gefühl. Und dieses Gefühl ist nicht irrational - es ist nur unvollständig.

### "Ich kann mich nicht konzentrieren wenn mir jemand zusieht"

Das ist real. Die Forschung zur Social Facilitation <sup>[10]</sup> zeigt allerdings: Anwesenheit eines Beobachters stört nur bei **neuen, ungeübten Aufgaben**. Bei Aufgaben die man beherrscht - also beim eigentlichen Programmieren - **verbessert** Anwesenheit die Leistung um 15-20%.

Was du als "Störung" erlebst, ist dein Gehirn das von System 1 (Autopilot) auf System 2 (analytisches Denken) umschaltet <sup>[9]</sup>. Das fühlt sich anstrengender an. Es produziert aber besseren Code. Jeder Entwickler kennt das Gefühl, um 23 Uhr allein "geniale" Lösung geschrieben zu haben - die am nächsten Morgen peinlich aussieht. Der Partner verhindert die 23-Uhr-Entscheidungen in Echtzeit.

### "Ich brauche erstmal allein nachdenken bevor ich coden kann"

Stimmt. Und genau deshalb funktioniert Pair Programming nicht so, dass zwei Menschen 8 Stunden nebeneinander sitzen. Die effektivste Praxis laut einer Studie von Chong und Hurlbutt (2007) <sup>[21]</sup>: **2-4 Stunden Sessions** mit Pausen für Solo-Exploration.

Das Modell: Solo nachdenken, pairen um zu bauen, solo nachdenken, pairen um zu reviewen. Die Studien die 15% Mehraufwand bei 60% weniger Defekten messen, basieren auf diesem Rhythmus - nicht auf 8-Stunden-Dauerpairing.

### "Mein Partner ist zu langsam / zu schnell"

Skill-Mismatch ist das häufigste Problem in der Praxis <sup>[19]</sup>. Begel und Nagappan (2008) fanden in ihrer Microsoft-Studie: **73% der Entwickler** die Pairing ablehnten, nannten Skill-Mismatch als Grund. Nicht Pairing selbst.

Die Lösung ist nicht kein Pairing. Die Lösung ist besseres Matching. Ihre Daten zeigten auch: Bei gut gematchten Paaren war die Zufriedenheit bei **90%** - und die wahrgenommene Produktivität stieg sogar über Solo-Arbeit <sup>[19]</sup>.

Und hier der Punkt den niemand gern hört: Wenn du immer der "Schnellere" bist, dann bist du auch der Wissensmonopolist. Du bist der Bus Factor 1. Dein Team ist von dir abhängig. Pairing mit jemandem der "langsamer" ist, ist keine Bremse - es ist Wissenstransfer. Es ist die billigste Versicherung die dein Team kaufen kann.

### "Ich verliere meinen Flow-State"

Csikszentmihalyis Flow-Theorie <sup>[22]</sup> beschreibt den Zustand vollständiger Absorption in eine Aufgabe. Solo-Programmieren kann Flow erzeugen. Aber Flow hat ein Problem: Er unterdrückt kritisches Denken. Im Flow-Zustand werden Warnzeichen ignoriert, Randfälle übersprungen, Abkürzungen genommen die sich "richtig anfühlen" <sup>[9]</sup>.

Was Entwickler als "Flow" erleben, ist oft System 1 auf Hochtouren - schnell, intuitiv und blind für eigene Fehler. Pair Programming ersetzt unkontrollierten Flow durch **produktiven Fokus**: hohe Konzentration bei gleichzeitiger Qualitätskontrolle.

Die Studien zeigen: Paare berichten **gleich hohe oder höhere Arbeitszufriedenheit** als Solo-Entwickler <sup>[2]</sup>. Flow ist nicht das einzige Rezept für gutes Arbeiten. Shared Focus ist die nachhaltigere Variante.

### "Code Reviews reichen doch"

Fagan (1976) <sup>[14]</sup> zeigte: Formale Code Reviews finden **60-70% der Defekte**. Das klingt gut. Pair Programming findet **85-95%** <sup>[1]</sup>. Aber der entscheidende Unterschied ist nicht die Quote - es ist der Zeitpunkt.

Ein Code Review findet Fehler Stunden oder Tage nachdem sie geschrieben wurden. Der Kontext ist weg. Der Reviewer muss den Denkprozess rekonstruieren - und tut das in **durchschnittlich 60% der Fälle falsch** (Bacchelli & Bird, 2013) <sup>[23]</sup>. Er genehmigt Code den er nicht vollständig versteht, weil der soziale Druck zu gross ist den Kollegen stundenlang auf ein Approve warten zu lassen.

Pair Programming hat dieses Problem nicht. Der Navigator war beim gesamten Denkprozess dabei. Kein Kontextverlust. Kein sozialer Druck. Und keine Warteschlange im PR-Review die das ganze Team ausbremst.

### "Es ist sozial anstrengend"

Ja. Für introvertierte Entwickler ist dauerhaftes Pairing erschöpfend. Das ist kein Argument gegen Pairing - es ist ein Argument für **dosiertes Pairing**. Die Studienlage <sup>[21]</sup> empfiehlt 50-70% Pairing-Anteil, nicht 100%. Kritische Aufgaben (Architektur, Integration, Sicherheit) im Paar. Routinearbeit (Konfiguration, einfache Bugs) solo.

Die Pointe: Entwickler die "nie" pairen wollen, haben in Studien nach **2 Wochen konsequentem Pairing** ihre Meinung geändert - 96% würden es weiter empfehlen <sup>[1]</sup>. Die initiale Ablehnung ist fast immer eine Komfortzone-Verteidigung, keine evidenzbasierte Position.

## Die kognitive Erklärung: Warum zwei Gehirne mehr leisten als eines

### Cognitive Load Theory (Sweller, 1988) <sup>[7]</sup>

Jeder Mensch hat eine begrenzte Kapazität für gleichzeitige Informationsverarbeitung im Arbeitsgedächtnis. Miller (1956) <sup>[8]</sup> bezifferte diese Kapazität auf **7 plus/minus 2 Einheiten**. Beim Programmieren konkurrieren bis zu **12-15 parallele Anforderungen** um diese Kapazität: Syntax, Logik, Systemarchitektur, Randfälle, Namenskonventionen, Testvorgaben, API-Verträge, Performance-Implikationen.

Beim Pair Programming verteilt sich diese Last auf zwei Arbeitsgedächtnisse. Der Driver konzentriert sich auf die taktische Ebene: Syntax, Variablennamen, aktuelle Funktion. Der Navigator behält die strategische Ebene im Blick: Passt die Lösung zur Gesamtarchitektur? Fehlt ein Randfall? Gibt es eine einfachere Variante?

Messbar: Paare berücksichtigen **40% mehr Randfälle** als Solo-Entwickler bei derselben Aufgabe <sup>[17]</sup>. Nicht weil sie klüger sind. Sondern weil ihre kognitive Gesamtkapazität höher ist.

### Verbalisierungszwang (Chi et al., 1989) <sup>[11]</sup>

Eines der mächtigsten Werkzeuge beim Debugging ist das Rubber Duck Debugging: das Problem laut erklären, selbst wenn nur eine Gummiente zuhört. Chi et al. zeigten den Self-Explanation Effect: Studierende die ihre Lösungsschritte laut erklärten, erzielten in Problemlösungs-Tests **Scores die 2,5x höher** lagen als bei stillen Problemlösern. Die Fehlerquote sank um **30%** <sup>[11]</sup>.

Pair Programming institutionalisiert diesen Effekt. Jede Entscheidung muss dem Partner erklärt werden. "Ich nehme hier einen HashMap statt einer ArrayList, weil..." - der Satz zwingt zur Begründung. Und Begründungen die nicht überzeugen, werden hinterfragt. Bevor der Code geschrieben ist, nicht Wochen später im Code Review.

### Dual Process Theory (Kahneman, 2011) <sup>[9]</sup>

Daniel Kahnemans Dual Process Theory unterscheidet zwei Denkmodi: System 1 (schnell, intuitiv, fehleranfällig) und System 2 (langsam, analytisch, präzise). Beim Solo-Programmieren dominiert System 1 - Entwickler kopieren bekannte Muster, überspringen Prüfungen weil "das hat immer funktioniert".

Der Partner aktiviert System 2. Nicht durch Kontrolle, sondern durch blosse Anwesenheit. Die Sozialpsychologie nennt das Social Facilitation <sup>[10]</sup>: Die Anwesenheit eines kompetenten Beobachters verbessert die Leistung bei gut beherrschten Aufgaben um **15-20%**.

### Working Memory Complement (Flor & Hutchins, 1991) <sup>[24]</sup>

Zwei Programmierer teilen sich nicht einfach die Arbeit. Sie ergänzen ihre Arbeitsgedächtnisse. Was Person A übersieht, bemerkt Person B - nicht weil B aufmerksamer ist, sondern weil Aufmerksamkeit statistisch streut.

Die mathematische Konsequenz: Wenn ein Solo-Entwickler eine bestimmte Fehlerklasse mit **90% Wahrscheinlichkeit** erkennt, erkennen zwei unabhängige Entwickler dieselbe Fehlerklasse mit **99% Wahrscheinlichkeit** (1 - 0.1 x 0.1). Bei einer Erkennungsrate von 80% steigt die Paar-Erkennungsrate auf **96%**. Dieser statistische Effekt allein erklärt einen Grossteil der beobachteten Defektreduktion.

## Die psychologische Dimension: Sicherheit, Wissen, Zugehörigkeit

### Psychological Safety (Edmondson, 1999) <sup>[12]</sup>

Amy Edmondson prägte den Begriff Psychological Safety: die Überzeugung, dass man in einem Team Fehler zugeben, Fragen stellen und Risiken eingehen kann ohne bestraft zu werden.

- **Google Project Aristotle (2015)** <sup>[13]</sup>: Psychological Safety war der **#1 Prädiktor** für Team-Performance - wichtiger als Struktur, Klarheit, Bedeutung oder Verlässlichkeit
- **Edmondson (1999)** <sup>[12]</sup>: Teams mit hoher Psychological Safety **meldeten 70% mehr Fehler** und konnten sie dadurch schneller beheben
- **Rozovsky (2015)** <sup>[13]</sup>: Teams im obersten Quartil der Psychological Safety hatten **17% höhere Produktivität** und **40% niedrigere Fluktuation**

Pair Programming schafft einen natürlichen Rahmen dafür. "Ich verstehe nicht was diese API zurückgibt" ist in einer Pairing-Session eine normale Aussage. In einem Solo-Setting bleibt dieselbe Unsicherheit oft unausgesprochen - und wird zum Bug.

### Wissensverteilung und Bus Factor

Die Kosten von Wissensverlust in Zahlen:

- **Bus Factor 1** (nur eine Person kennt den Code): Risiko eines **kompletten Projektausfalls** bei Personalwechsel
- **Wissensverlust durch Fluktuation**: Bei jedem Abgang gehen **42% des prozessrelevanten Wissens** verloren - davon sind **70% implizit**, also nicht dokumentiert <sup>[15]</sup>
- **Kosten der Neueinarbeitung**: **6-12 Monate** bis ein neuer Entwickler in einem Enterprise-Projekt produktiv ist, **3-6 Monate** mit Pair-Onboarding <sup>[1]</sup>
- **Fluktuationskosten**: 50-200% des Jahresgehalts pro Abgang (SHRM, 2019)

Pair Programming ist der zuverlässigste Mechanismus den wir kennen um [implizites Wissen von einzelnen Köpfen ins Team zu verteilen](/de/magazin/warum-ki-projekte-scheitern/).

### Onboarding-Beschleunigung

- **30-50% schnellere Produktivität** bei Pair-Onboarding vs. Self-Study <sup>[1]</sup>
- **75% der Onboarding-Paare** fühlen sich nach 2 Wochen "bereit für eigenständige Arbeit" vs. **25% bei Solo-Onboarding** <sup>[21]</sup>
- **Cognitive Apprenticeship** (Collins, Brown & Newman, 1989) <sup>[25]</sup>: Lernen durch Beobachten und schrittweises Übernehmen ist dem instruktionsbasierten Lernen bei komplexen Aufgaben um den **Faktor 2-3 effektiver**

## Der Business Case: Die vollständige Rechnung

### Fehler 1: Die 100%-Annahme

Paare brauchen nicht doppelt so lange:

- Einfache Aufgaben: **+84% Aufwand** <sup>[4]</sup> - hier lohnt Pairing selten
- Mittlere Aufgaben: **+15% Aufwand** <sup>[1]</sup>
- Komplexe Aufgaben: **+18% Aufwand** bei gleichzeitig **-60% Defekten** <sup>[4]</sup>
- Elapsed Time (komplexe Aufgabe): **-29%** schneller fertig <sup>[2]</sup>

Paare verwerfen schlechte Ansätze **4x schneller** weil der Navigator den Denkfehler früher erkennt <sup>[18]</sup>.

### Fehler 2: Die Defektkosten werden ignoriert

Die Cost Escalation Curve nach Boehm und Basili (2001) <sup>[6]</sup>:

| Phase | Behebungskosten (relativ) | Beispiel (bei 500 EUR Basiskosten) |
|-------|---------------------------|--------------------------------------|
| Codierung | 1x | 500 EUR |
| Code Review | 2x | 1.000 EUR |
| Integration/Test | 5x | 2.500 EUR |
| Systemtest | 10x | 5.000 EUR |
| Produktion | 30x | 15.000 EUR |
| Post-Release (Kunde betroffen) | 100x | 50.000 EUR |

Das **National Institute of Standards and Technology (NIST)** <sup>[26]</sup> bezifferte die jährlichen Kosten von Software-Defekten in den USA auf **59,5 Milliarden USD**. Davon wären **22,2 Milliarden USD** (37%) durch frühere Fehlererkennung vermeidbar gewesen.

### Fehler 3: Die Wissenskosten werden ignoriert

Wenn ein Entwickler kündigt und niemand seinen Code kennt:

- **Reverse Engineering**: 2-6 Monate Aufwand
- **Erhöhte Fehlerrate** in der Übergangsphase: +200-300%
- **Verzögerte Feature-Delivery**: 3-9 Monate bis zum Normalzustand
- **Fluktuationskosten gesamt**: 50-200% des Jahresgehalts (SHRM, 2019)

### Die Gesamtrechnung (Modellprojekt)

Für ein Enterprise-Projekt mit 10 Entwicklern, 12 Monaten Laufzeit:

| Posten | Solo | Pairing | Delta |
|--------|------|---------|-------|
| Entwicklungsaufwand | Basis | +15% | +105.000 EUR |
| Defektbehebung (Test) | Basis | -40% | -120.000 EUR |
| Defektbehebung (Produktion) | Basis | -50% | -225.000 EUR |
| Wissenstransfer/Onboarding | Basis | -40% | -80.000 EUR |
| Dokumentationsaufwand | Basis | -30% | -25.000 EUR |
| **Netto-Einsparung** | | | **-345.000 EUR** |

Die Zahlen variieren je nach Projekt. Die Richtung nicht. In der Enterprise-Entwicklung - wo ein Produktionsfehler in einem [Payroll-System](/de/leistungen/hr-agent/payroll-decision-layer/) oder einer Schnittstelle zu SAP Tausende Mitarbeiter betrifft - ist Solo-Entwicklung das teurere Modell.

## Real-Time Review vs. Post-Hoc Review

| KPI | Post-Hoc Code Review | Pair Programming | Quelle |
|-----|---------------------|-----------------|--------|
| Defekterkennung | 60-70% | 85-95% | <sup>[14]</sup> <sup>[1]</sup> |
| Time to Detection | Stunden bis Tage | Sekunden | Strukturell |
| Kontextverlust | Hoch | Null | <sup>[23]</sup> |
| Review-Missverständnisse | 60% (Reviewer versteht Intent falsch) | 0% | <sup>[23]</sup> |
| PR-Wartezeit | 4-24 Stunden (Team-Blocker) | 0 | Strukturell |
| Wissenstransfer | Gering (nur Code sichtbar) | Hoch (Entscheidungsprozess sichtbar) | <sup>[24]</sup> |

Bacchelli und Bird (2013) <sup>[23]</sup> analysierten Code Reviews bei Microsoft und fanden: In **60% der Fälle** verstand der Reviewer die Absicht des Autors nicht korrekt. Reviews die eigentlich Fehler finden sollten, degenerierten zu Style-Diskussionen. Der Hauptgrund: fehlender Kontext.

## Der menschliche Faktor: Warum Pairing in der KI-Ära wichtiger wird, nicht weniger

Es gibt ein Argument für Pair Programming das in keiner Studie aus den 2000ern auftaucht - weil das Problem damals nicht existierte.

2026 verbringen Entwickler einen wachsenden Teil ihres Arbeitstags im Dialog mit KI-Assistenten. Code wird mit Copilot generiert, Architektur-Fragen an Claude gestellt, Debugging mit ChatGPT durchgeführt. Die Produktivitätsgewinne sind real. Aber es entsteht ein Nebeneffekt den niemand eingeplant hat: **professionelle Isolation**.

Die Zahlen sind alarmierend:

- **Gallup State of the Global Workplace (2024)**: Nur **23% der Arbeitnehmer** weltweit fühlen sich bei der Arbeit engagiert. Bei Remote-Wissensarbeitern liegt der Wert bei **18%**
- **Microsoft Work Trend Index (2024)**: **68% der Entwickler** berichten, dass sie an manchen Tagen **mit niemandem aus ihrem Team** fachlich sprechen
- **Buffer State of Remote Work (2024)**: **23% der Remote-Arbeiter** nennen **Einsamkeit** als grösste Herausforderung - vor "Ablenkungen" und "Motivation"
- **Murthy (2023)**: Der US Surgeon General erklärte Einsamkeit am Arbeitsplatz zur **Public Health Crisis** mit messbaren Auswirkungen auf Produktivität, Kreativität und Fehleranfälligkeit

Ein Entwickler der 8 Stunden am Tag mit einem LLM spricht und mit niemandem aus seinem Team, trifft Entscheidungen in einem Vakuum. Das LLM widerspricht nicht aus Erfahrung. Es kennt die Teamdynamik nicht. Es weiss nicht dass der letzte Entwickler der "mal schnell" die Datenbankstruktur geändert hat, drei Wochen Aufräumarbeit verursacht hat. Es hat keine Meinung die auf Narben basiert.

### Soziale Kognition vs. Tool-Kognition

Die Neurowissenschaft unterscheidet zwei Netzwerke im Gehirn <sup>[27]</sup>: Das **Task-Positive Network** (aktiviert bei Problemlösung, Tool-Nutzung, fokussierter Arbeit) und das **Default Mode Network** (aktiviert bei sozialer Kognition, Perspektivwechsel, Empathie). Beim Solo-Programmieren mit KI-Assistenten ist fast ausschliesslich das Task-Positive Network aktiv. Das Default Mode Network - zuständig für "Wie würde mein Kollege das sehen?" - bleibt still.

Pair Programming aktiviert **beide Netzwerke gleichzeitig**: Problemlösung und soziale Kognition. Das Ergebnis sind Entscheidungen die nicht nur technisch korrekt sind, sondern auch den Team-Kontext berücksichtigen.

### Vertrauen entsteht durch gemeinsames Arbeiten, nicht durch Slack-Nachrichten

Dutton und Heaphy (2003) <sup>[28]</sup> untersuchten "High-Quality Connections" am Arbeitsplatz: kurze, intensive Interaktionen die Vertrauen, Energie und gegenseitige Wertschätzung erzeugen. Ihre Forschung zeigt:

- **Ein einziger Tag intensiver Zusammenarbeit** erzeugt mehr Vertrauen als **Wochen asynchroner Kommunikation**
- Teams mit regelmässigen High-Quality Connections haben **25% niedrigere Fluktuation** und **30% höheres Engagement** <sup>[28]</sup>
- Vertrauen das durch gemeinsame Problemlösung entsteht, ist **3x stabiler** als Vertrauen das durch soziale Events entsteht <sup>[12]</sup>

Pair Programming ist die dichteste Form professioneller Interaktion die es gibt. Zwei Menschen lösen gemeinsam ein Problem, teilen Frustration und Erfolg, lernen die Denkweise des anderen kennen. Das ist kein Soft-Skill-Bonus. Das ist der Klebstoff der funktionierende Teams zusammenhält.

### Die Gegenrechnung: Was passiert wenn Teams nicht mehr miteinander reden

- **Silo-Bildung**: Ohne regelmässigen fachlichen Austausch entstehen Wissensinseln. Jeder Entwickler baut sein eigenes mentales Modell des Systems - und diese Modelle divergieren mit der Zeit <sup>[15]</sup>
- **Doppelarbeit**: Ohne Sichtbarkeit in die Arbeit anderer werden **15-25% der Features redundant implementiert** (Herbsleb & Grinter, 1999) <sup>[29]</sup>
- **Qualitätsverlust**: Entwickler die sich sozial isoliert fühlen, zeigen **33% mehr Defekte** als eingebundene Teammitglieder (Begel & Nagappan, 2008) <sup>[19]</sup>
- **Burnout**: Professionelle Isolation ist einer der stärksten Prädiktoren für Burnout bei Wissensarbeitern (Maslach & Leiter, 2016) <sup>[30]</sup>

Die Ironie: KI-Assistenten machen individuelle Entwickler produktiver. Aber sie machen Teams fragiler - wenn Pairing als Gegengewicht fehlt. Die Lösung ist nicht weniger KI. Die Lösung ist bewusste menschliche Interaktion als Standardprozess. Pair Programming ist der einfachste und effektivste Weg dorthin.

## Was das für Enterprise-Entwicklung bedeutet

In der [Enterprise-Softwareentwicklung](/de/leistungen/softwareentwicklung/) potenzieren sich alle genannten Effekte:

**Integrationskomplexität.** Wenn ein Agent an SAP, DATEV und Microsoft Graph andocken muss, steigt die kognitive Last pro Aufgabe auf **15+ parallele Kontexte**. Genau die Situation in der Pair Programming den grössten Vorteil zeigt: +18% Aufwand bei -60% Defekten <sup>[4]</sup>.

**Regulatorische Anforderungen.** Compliance-relevanter Code erfordert Korrektheit. Die **99% Erkennungsrate** (vs. 90% bei Solo) bei kritischen Fehlerklassen ist kein Nice-to-Have. Sie ist eine Business-Anforderung.

**Vier-Augen-Prinzip.** In regulierten Branchen fordert die Compliance ein Vier-Augen-Prinzip (MaRisk, ISO 27001). Pair Programming erfüllt diese Anforderung nativ - **0 zusätzlicher Aufwand** für Compliance-Review.

**Co-Build als Modell.** Bei Gosign arbeiten wir im [Co-Build-Modell](/de/leistungen/ai-agents/): Kunden-Teams entwickeln mit uns, nicht neben uns. Das ist Pair Programming auf organisatorischer Ebene - **100% Wissenstransfer** an das Kundenteam, kein Vendor-Lock-in.

## Die Zusammenfassung in Zahlen

| KPI | Solo | Pair Programming | Quelle |
|-----|------|-----------------|--------|
| Entwicklungszeit | Basis | +15% | <sup>[1]</sup> |
| Elapsed Time (komplex) | Basis | -29% | <sup>[2]</sup> |
| Defektdichte | Basis | -15 bis -60% | <sup>[1]</sup> <sup>[4]</sup> |
| Codezeilen (gleiche Funktion) | Basis | -48% | <sup>[1]</sup> |
| Testfälle auf Anhieb bestanden | Basis | +15% | <sup>[1]</sup> |
| Onboarding-Dauer | 3-6 Monate | 1,5-3 Monate | <sup>[1]</sup> |
| Zufriedenheit | Basis | +95% | <sup>[2]</sup> |
| Würden wieder pairen | n/a | 96% | <sup>[1]</sup> |
| Bus Factor | 1 | mindestens 2 | Strukturell |
| Post-Release Defekte | Basis | -20 bis -40% | <sup>[17]</sup> |
| Defekterkennung (kritisch) | 90% | 99% | Statistisch |
| Kosten pro Defekt (Produktion) | 30x Codierung | Vermieden | <sup>[6]</sup> |
| PR-Review-Wartezeit | 4-24h | 0 | Strukturell |
| Code-Review-Missverständnisse | 60% | 0% | <sup>[23]</sup> |

## Fazit

Die Frage ist nicht ob sich ein Unternehmen Pair Programming leisten kann. Die Frage ist ob es sich leisten kann darauf zu verzichten.

**15% mehr Entwicklungszeit. 60% weniger Defekte. 40% schnelleres Onboarding. 48% weniger Code. 99% Erkennungsrate bei kritischen Fehlern. 345.000 EUR Netto-Einsparung pro Jahr im Modellprojekt.**

Und an die Entwickler die Pairing nervig finden: 96% eurer Kollegen haben nach zwei Wochen konsequentem Pairing ihre Meinung geändert <sup>[1]</sup>. Die Evidenz sagt nicht dass Pairing bequem ist. Sie sagt dass es besser funktioniert. Für den Code, für das Team und für euch selbst.

Pair Programming ist keine Präferenz. Es ist eine Engineering-Entscheidung mit messbarem ROI.

> [Softwareentwicklung bei Gosign - Co-Build statt Blackbox](/de/leistungen/softwareentwicklung/)

> [Warum KI-Projekte scheitern - und was Entscheidungsarchitektur damit zu tun hat](/de/magazin/warum-ki-projekte-scheitern/)

> [AI Agents - individuelle Lösung im Co-Build-Modell](/de/leistungen/ai-agents/)

---

## Quellenverzeichnis

<small>

**[1]** Williams, L. & Kessler, R. (2000). "All I Really Need to Know About Pair Programming I Learned in Kindergarten." *Communications of the ACM*, 43(5), 108-114. University of Utah.

**[2]** Nosek, J.T. (1998). "The Case for Collaborative Programming." *Communications of the ACM*, 41(3), 105-108.

**[3]** Cockburn, A. & Williams, L. (2001). "The Costs and Benefits of Pair Programming." *Proceedings of the First International Conference on Extreme Programming and Flexible Processes in Software Engineering (XP2000)*, 223-243.

**[4]** Arisholm, E., Gallis, H., Dybå, T. & Sjøberg, D.I.K. (2007). "Evaluating Pair Programming with Respect to System Complexity and Programmer Expertise." *IEEE Transactions on Software Engineering*, 33(2), 65-86.

**[5]** Dybå, T., Arisholm, E., Sjøberg, D.I.K., Hannay, J.E. & Shull, F. (2007). "Are Two Heads Better than One? On the Effectiveness of Pair Programming." *IEEE Software*, 24(6), 12-15.

**[6]** Boehm, B. & Basili, V. (2001). "Software Defect Reduction Top 10 List." *IEEE Computer*, 34(1), 135-137.

**[7]** Sweller, J. (1988). "Cognitive Load During Problem Solving: Effects on Learning." *Cognitive Science*, 12(2), 257-285.

**[8]** Miller, G.A. (1956). "The Magical Number Seven, Plus or Minus Two." *Psychological Review*, 63(2), 81-97.

**[9]** Kahneman, D. (2011). *Thinking, Fast and Slow.* Farrar, Straus and Giroux. New York.

**[10]** Zajonc, R.B. (1965). "Social Facilitation." *Science*, 149(3681), 269-274.

**[11]** Chi, M.T.H., Bassok, M., Lewis, M.W., Reimann, P. & Glaser, R. (1989). "Self-Explanations: How Students Study and Use Examples in Learning to Solve Problems." *Cognitive Science*, 13(2), 145-182.

**[12]** Edmondson, A. (1999). "Psychological Safety and Learning Behavior in Work Teams." *Administrative Science Quarterly*, 44(2), 350-383.

**[13]** Rozovsky, J. (2015). "The Five Keys to a Successful Google Team." *re:Work*, Google.

**[14]** Fagan, M.E. (1976). "Design and Code Inspections to Reduce Errors in Program Development." *IBM Systems Journal*, 15(3), 182-211.

**[15]** DeLong, D.W. (2004). *Lost Knowledge: Confronting the Threat of an Aging Workforce.* Oxford University Press.

**[16]** Jensen, R.W. (2003). "A Pair Programming Experience." *CrossTalk: The Journal of Defense Software Engineering*, 16(3), 22-24.

**[17]** Padberg, F. & Müller, M. (2003). "Analyzing the Cost and Benefit of Pair Programming." *Proceedings of the 9th International Software Metrics Symposium (METRICS 2003)*, IEEE, 166-177.

**[18]** Lui, K.M. & Chan, K.C.C. (2006). "Pair Programming Productivity: Novice-Novice vs. Expert-Expert." *International Journal of Human-Computer Studies*, 64(9), 915-925.

**[19]** Begel, A. & Nagappan, N. (2008). "Pair Programming: What's in it for Me?" *Proceedings of the Second ACM-IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM)*, 120-128.

**[20]** Müller, M. (2004). "Are Reviews an Alternative to Pair Programming?" *Empirical Software Engineering*, 9(4), 335-351.

**[21]** Chong, J. & Hurlbutt, T. (2007). "The Social Dynamics of Pair Programming." *Proceedings of the 29th International Conference on Software Engineering (ICSE)*, 354-363.

**[22]** Csikszentmihalyi, M. (1990). *Flow: The Psychology of Optimal Experience.* Harper & Row. New York.

**[23]** Bacchelli, A. & Bird, C. (2013). "Expectations, Outcomes, and Challenges of Modern Code Review." *Proceedings of the 35th International Conference on Software Engineering (ICSE)*, 712-721.

**[24]** Flor, N.V. & Hutchins, E.L. (1991). "Analyzing Distributed Cognition in Software Teams: A Case Study of Team Programming During Perfective Software Maintenance." *Proceedings of the Fourth Annual Workshop on Empirical Studies of Programmers*, 36-64. Ablex Publishing.

**[25]** Collins, A., Brown, J.S. & Newman, S.E. (1989). "Cognitive Apprenticeship: Teaching the Crafts of Reading, Writing, and Mathematics." In L.B. Resnick (Ed.), *Knowing, Learning, and Instruction: Essays in Honor of Robert Glaser*, 453-494. Lawrence Erlbaum Associates.

**[26]** National Institute of Standards and Technology (2002). "The Economic Impacts of Inadequate Infrastructure for Software Testing." *NIST Planning Report 02-3.*

**[27]** Fox, M.D. et al. (2005). "The Human Brain Is Intrinsically Organized into Dynamic, Anticorrelated Functional Networks." *Proceedings of the National Academy of Sciences*, 102(27), 9673-9678.

**[28]** Dutton, J.E. & Heaphy, E.D. (2003). "The Power of High-Quality Connections." In K.S. Cameron, J.E. Dutton & R.E. Quinn (Eds.), *Positive Organizational Scholarship*, 263-278. Berrett-Koehler Publishers.

**[29]** Herbsleb, J.D. & Grinter, R.E. (1999). "Architectures, Coordination, and Distance: Conway's Law and Beyond." *IEEE Software*, 16(5), 63-70.

**[30]** Maslach, C. & Leiter, M.P. (2016). "Understanding the Burnout Experience: Recent Research and Its Implications for Psychiatry." *World Psychiatry*, 15(2), 103-111.

</small>

--- Warum wir keine AI-Agenten mehr trainieren ---
> 92% Accuracy ohne Training. Der EU AI Act verlangt für Hochrisiko-KI erklärbare Einzelentscheidungen (Frist 2. August 2026, voraussichtlich verschoben auf Dezember 2027). Trainierte Modelle können das nicht.

## Training ist das neue Fax

2019 mussten wir AI-Modelle trainieren. Sie waren zu dumm für alles andere. GPT-2 konnte keinen kohärenten Absatz schreiben. BERT brauchte für jede Aufgabe tausende gelabelte Beispiele und einen GPU-Cluster für Tage.

Das war vor sechs Jahren. Sechs Jahre, in denen sich die Fähigkeiten von Language Models um Größenordnungen verbessert haben. Aber die Branche tut immer noch so, als sei "Training" der natürliche erste Schritt.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Auf einen Blick - Warum Training die falsche Architektur ist</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Ein LLM erreicht 92% korrekte Entscheidungen bei Rechnungsprüfung - ohne ein einziges Trainingsbeispiel. Erfahrene Juristen kommen auf 72%.<sup>[1]</sup></li>
<li>Der EU AI Act (Art. 13, 14, 86) verlangt für Hochrisiko-Systeme erklärbare Einzelentscheidungen - Frist 2. August 2026, voraussichtlich verschoben auf Dezember 2027. Trainierte Modelle können das nicht liefern.<sup>[10]</sup></li>
<li>Die Alternative: Regelwerk (versioniert), Kontext (pro Entscheidung), Decision Layer (Mensch/Regelwerk/KI pro Micro-Decision).</li>
<li>Konfigurierte Agenten sind modell-agnostisch: Foundation-Model-Wechsel ohne Regelwerk-Änderung. Kein Lock-in, kein Nachtraining.</li>
<li>Über 40% der Agentic-AI-Projekte scheitern bis 2027 - meist an fehlender Governance, nicht an fehlender Modellleistung.<sup>[9]</sup></li>
</ul>
</div>

Wenn jemand 2026 sagt "Wir trainieren unsere AI-Agenten", ist das wie 2010 zu sagen "Wir faxen unsere Bestellungen". Es funktioniert. Aber es zeigt, dass man die Architektur nicht verstanden hat.

<!-- Timeline: Von Training zu Konfiguration -->
<div class="not-prose my-12">
<div class="bg-gosign-dark rounded-card p-6 sm:p-8">
<p class="text-h3 font-bold text-white mb-6">Von Training zu Konfiguration</p>
<div class="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-4 gap-4">

<div class="border border-white/10 rounded-lg p-4 bg-white/5">
<p class="text-gosign-text-on-dark text-xs uppercase tracking-wider mb-1">2018 - 2020</p>
<p class="text-white font-bold text-lg mb-2">Training ist Pflicht</p>
<p class="text-gosign-text-on-dark text-sm mb-3">BERT, GPT-2. 110M - 1,5B Parameter.</p>
<div class="space-y-1 text-xs text-gosign-text-on-dark">
<p>Dauer: Wochen</p>
<p>Kosten: $10.000 - $100.000</p>
<p>Voraussetzung: GPU-Cluster</p>
</div>
</div>

<div class="border border-white/10 rounded-lg p-4 bg-white/5">
<p class="text-gosign-text-on-dark text-xs uppercase tracking-wider mb-1">2021 - 2023</p>
<p class="text-white font-bold text-lg mb-2">Training wird optional</p>
<p class="text-gosign-text-on-dark text-sm mb-3">GPT-3/3.5. 175B Parameter.</p>
<div class="space-y-1 text-xs text-gosign-text-on-dark">
<p>Dauer: Tage</p>
<p>Kosten: $1.000 - $10.000</p>
<p>Voraussetzung: GPU nötig</p>
</div>
</div>

<div class="border border-white/10 rounded-lg p-4 bg-white/5">
<p class="text-gosign-text-on-dark text-xs uppercase tracking-wider mb-1">2024</p>
<p class="text-white font-bold text-lg mb-2">Training oder Prompting?</p>
<p class="text-gosign-text-on-dark text-sm mb-3">GPT-4o, Claude 3.5. Multimodal.</p>
<div class="space-y-1 text-xs text-gosign-text-on-dark">
<p>Dauer: Stunden</p>
<p>Kosten: $10 - $100</p>
<p>Voraussetzung: API-Call</p>
</div>
</div>

<div class="border border-gosign-accent rounded-lg p-4 bg-gosign-accent/10">
<p class="text-gosign-accent-on-dark text-xs uppercase tracking-wider mb-1">2025 - 2026</p>
<p class="text-white font-bold text-lg mb-2">Konfiguration reicht</p>
<p class="text-gosign-text-on-dark text-sm mb-3">GPT-5.5, Claude Opus 4.7. Reasoning.</p>
<div class="space-y-1 text-xs text-gosign-text-on-dark">
<p>Dauer: Minuten</p>
<p>Kosten: $10 - $100</p>
<p>Voraussetzung: API-Call</p>
</div>
</div>

</div>
</div>
</div>

Kumar Gauraw bringt es auf den Punkt: "Die meisten greifen zu früh zum Fine-Tuning."<sup>[5]</sup> Nicht weil Fine-Tuning schlecht ist. Sondern weil es 2026 für die meisten Enterprise-Aufgaben nicht mehr nötig ist.

## Was ein trainiertes Modell nicht kann: eine Einzelentscheidung erklären

Ein Kandidat wird von Ihrem Recruiting-Agent abgelehnt. Er fragt: Warum?

Zwei Antworten. Zwei Architekturen.

**Trainiertes Modell:** "Unser Modell hat auf Basis von 50.000 historischen Einstellungsentscheidungen gelernt, dass Ihr Profil eine Erfolgswahrscheinlichkeit von 34% hat."

**Konfigurierter Agent:** "Ihre Qualifikation Maschinenbau erfüllt Anforderung 3 (Elektrotechnik oder vergleichbar) nicht. Regel: Stellenprofil v2026-03. Anfechtbar: Ja. Prozess: Fachbereich prüft, ob Maschinenbau als 'vergleichbar' gilt."

Die erste Antwort genügt den Hochrisiko-Pflichten des EU AI Act nicht - geltende Frist 2. August 2026, voraussichtlich verschoben auf Dezember 2027.

EU AI Act, Art. 13 (Transparenz), Art. 14 (menschliche Aufsicht), Art. 86 (Recht auf Erklärung).<sup>[10]</sup> Für Hochrisiko-Systeme - und Recruiting ist Hochrisiko, Annex III(4) - muss jede Einzelentscheidung nachvollziehbar, erklärbar und anfechtbar sein.

Nicht das Modell. Die einzelne Entscheidung. Für diesen Kandidaten. Mit dieser Begründung.

Ein trainiertes Modell kann das nicht. Es hat keine Entscheidungsakte. Es hat Gewichte. Und Gewichte erklären einem Betriebsrat nichts.

### Der Compliance-Test: Trainiert vs. Konfiguriert

<!-- Zwei-Spalten-Vergleich: Trainiert vs. Konfiguriert -->
<div class="not-prose my-10">
<div class="bg-gosign-dark rounded-card overflow-hidden">
<div class="grid grid-cols-1 md:grid-cols-2">

<!-- Linke Spalte: Trainiert -->
<div class="p-6 sm:p-8 border-b md:border-b-0 md:border-r border-white/10">
<p class="text-gosign-text-on-dark text-xs uppercase tracking-wider mb-1">Architektur A</p>
<p class="text-white font-bold text-xl mb-6">Trainiertes Modell</p>

<div class="space-y-5">
<div>
<p class="text-gosign-text-on-dark text-sm mb-1">"Warum diese Entscheidung?"</p>
<p class="text-white text-sm">"Modell hat gelernt" - Black Box</p>
<p class="text-red-400 text-xs mt-1">Nicht erklärbar</p>
</div>

<div>
<p class="text-gosign-text-on-dark text-sm mb-1">"Gesetz ändert sich?"</p>
<p class="text-white text-sm">Nachtrainieren. 2 - 4 Wochen, $5.000 - $20.000</p>
<p class="text-red-400 text-xs mt-1">Teuer und langsam</p>
</div>

<div>
<p class="text-gosign-text-on-dark text-sm mb-1">"Kann der Betroffene anfechten?"</p>
<p class="text-white text-sm">Gegen was? Gegen Gewichte?</p>
<p class="text-red-400 text-xs mt-1">Nicht anfechtbar</p>
</div>

<div>
<p class="text-gosign-text-on-dark text-sm mb-1">"Neues LLM-Modell verfügbar?"</p>
<p class="text-white text-sm">Neues Training nötig. Wochen, Lock-in.</p>
<p class="text-red-400 text-xs mt-1">Anbieter-Abhängigkeit</p>
</div>

<div>
<p class="text-gosign-text-on-dark text-sm mb-1">"EU AI Act konform?"</p>
<p class="text-white text-sm">Art. 13: Transparenz fehlt. Art. 14: Eingriff = Modell ersetzen. Art. 86: Erklärung nicht möglich.</p>
<p class="text-red-400 text-xs mt-1">Problematisch</p>
</div>

<div class="pt-4 border-t border-white/10">
<p class="text-red-400 font-bold text-sm">Lock-in: Ja | Audit: Schwierig | EU AI Act: Problematisch</p>
</div>
</div>
</div>

<!-- Rechte Spalte: Konfiguriert -->
<div class="p-6 sm:p-8">
<p class="text-gosign-accent-on-dark text-xs uppercase tracking-wider mb-1">Architektur B</p>
<p class="text-white font-bold text-xl mb-6">Konfigurierter Agent</p>

<div class="space-y-5">
<div>
<p class="text-gosign-text-on-dark text-sm mb-1">"Warum diese Entscheidung?"</p>
<p class="text-white text-sm">"§9 EStG v2026-01, Abwesenheit 14h15min"</p>
<p class="text-green-400 text-xs mt-1">Regel, Version, Kontext dokumentiert</p>
</div>

<div>
<p class="text-gosign-text-on-dark text-sm mb-1">"Gesetz ändert sich?"</p>
<p class="text-white text-sm">Regel aktualisieren. Sofort wirksam, $0.</p>
<p class="text-green-400 text-xs mt-1">Versioniert und auditierbar</p>
</div>

<div>
<p class="text-gosign-text-on-dark text-sm mb-1">"Kann der Betroffene anfechten?"</p>
<p class="text-white text-sm">"Frühstück war nicht inklusive." Sachbearbeiter prüft.</p>
<p class="text-green-400 text-xs mt-1">Anfechtbar mit Entscheidungsakte</p>
</div>

<div>
<p class="text-gosign-text-on-dark text-sm mb-1">"Neues LLM-Modell verfügbar?"</p>
<p class="text-white text-sm">Regelwerk bleibt. 0 Aufwand, kein Lock-in.</p>
<p class="text-green-400 text-xs mt-1">Modell-agnostisch</p>
</div>

<div>
<p class="text-gosign-text-on-dark text-sm mb-1">"EU AI Act konform?"</p>
<p class="text-white text-sm">Entscheidungsakte pro Micro-Decision. Regel übersteuern, nicht Modell ersetzen.</p>
<p class="text-green-400 text-xs mt-1">Konform by Design</p>
</div>

<div class="pt-4 border-t border-white/10">
<p class="text-green-400 font-bold text-sm">Lock-in: Nein | Audit: By Design | EU AI Act: Konform</p>
</div>
</div>
</div>

</div>
</div>
</div>

Das Compliance-Problem ist aber nur die Oberfläche. Darunter liegt ein Architekturproblem.

## 92% vs. 72%

Forscher haben 2025 getestet, wie gut ein LLM Anwaltsrechnungen gegen Billing Guidelines prüfen kann.<sup>[1]</sup> Kein Fine-Tuning. Kein Training. Nur das Regelwerk als Kontext.

Das Ergebnis:

<!-- 92% vs. 72% Balkenvergleich -->
<div class="not-prose my-10">
<div class="bg-gosign-dark rounded-card p-6 sm:p-8 text-white">
<p class="text-h3 font-bold mb-6">Anwaltsrechnung: regelkonform oder nicht?</p>
<p class="text-gosign-text-on-dark text-sm mb-8">Better Bill GPT, Whitehouse et al. (April 2025). Peer-reviewed. LLM erhielt Regelwerk als Kontext, kein Fine-Tuning.<sup>[1]</sup></p>

<!-- Gesamtgenauigkeit -->
<div class="mb-8">
<p class="text-gosign-text-on-dark text-xs uppercase tracking-wider mb-3">Gesamtgenauigkeit</p>

<div class="mb-4">
<div class="flex justify-between items-center mb-1">
<p class="text-sm font-medium">LLM (kein Training)</p>
<p class="text-gosign-accent-on-dark font-bold text-lg">92%</p>
</div>
<div class="w-full bg-white/10 rounded-full h-4">
<div class="bg-gosign-accent rounded-full h-4" style="width: 92%"></div>
</div>
</div>

<div class="mb-4">
<div class="flex justify-between items-center mb-1">
<p class="text-sm font-medium">Erfahrene Juristen</p>
<p class="text-gosign-text-on-dark font-bold text-lg">72%</p>
</div>
<div class="w-full bg-white/10 rounded-full h-4">
<div class="bg-white/30 rounded-full h-4" style="width: 72%"></div>
</div>
</div>
</div>

<!-- F-Score Einzelpositionen -->
<div class="mb-8">
<p class="text-gosign-text-on-dark text-xs uppercase tracking-wider mb-3">Einzelposition-Klassifikation (F-Score)</p>

<div class="mb-4">
<div class="flex justify-between items-center mb-1">
<p class="text-sm font-medium">LLM (kein Training)</p>
<p class="text-gosign-accent-on-dark font-bold text-lg">81%</p>
</div>
<div class="w-full bg-white/10 rounded-full h-4">
<div class="bg-gosign-accent rounded-full h-4" style="width: 81%"></div>
</div>
</div>

<div class="mb-4">
<div class="flex justify-between items-center mb-1">
<p class="text-sm font-medium">Beste menschliche Gruppe</p>
<p class="text-gosign-text-on-dark font-bold text-lg">43%</p>
</div>
<div class="w-full bg-white/10 rounded-full h-4">
<div class="bg-white/30 rounded-full h-4" style="width: 43%"></div>
</div>
</div>
</div>

<!-- Zeit und Kosten -->
<div class="grid grid-cols-1 sm:grid-cols-2 gap-6">

<div>
<p class="text-gosign-text-on-dark text-xs uppercase tracking-wider mb-3">Zeit pro Rechnung</p>
<div class="mb-3">
<div class="flex justify-between items-center mb-1">
<p class="text-sm font-medium">LLM</p>
<p class="text-gosign-accent-on-dark font-bold">3,6 Sek.</p>
</div>
<div class="w-full bg-white/10 rounded-full h-3">
<div class="bg-gosign-accent rounded-full h-3" style="width: 1.4%"></div>
</div>
</div>
<div>
<div class="flex justify-between items-center mb-1">
<p class="text-sm font-medium">Juristen</p>
<p class="text-gosign-text-on-dark font-bold">~250 Sek.</p>
</div>
<div class="w-full bg-white/10 rounded-full h-3">
<div class="bg-white/30 rounded-full h-3" style="width: 100%"></div>
</div>
</div>
</div>

<div>
<p class="text-gosign-text-on-dark text-xs uppercase tracking-wider mb-3">Kosten pro Rechnung</p>
<div class="mb-3">
<div class="flex justify-between items-center mb-1">
<p class="text-sm font-medium">LLM</p>
<p class="text-gosign-accent-on-dark font-bold">&lt; $0,01</p>
</div>
<div class="w-full bg-white/10 rounded-full h-3">
<div class="bg-gosign-accent rounded-full h-3" style="width: 0.2%"></div>
</div>
</div>
<div>
<div class="flex justify-between items-center mb-1">
<p class="text-sm font-medium">Juristen</p>
<p class="text-gosign-text-on-dark font-bold">$4,27</p>
</div>
<div class="w-full bg-white/10 rounded-full h-3">
<div class="bg-white/30 rounded-full h-3" style="width: 100%"></div>
</div>
</div>
</div>

</div>

<p class="text-gosign-text-on-dark text-xs mt-6 border-t border-white/10 pt-4">Kostenreduktion: 99,97%.<sup>[4]</sup> Mechanismus übertragbar auf jede regelbasierte Compliance-Aufgabe.</p>
</div>
</div>

Das LLM wurde nicht auf Rechnungen trainiert. Es hat die Billing Guidelines als Kontext erhalten. Und sofort entschieden.

### Warum das LLM besser war

Nicht weil es schlauer ist. Sondern weil es um 15 Uhr dieselbe Regel genauso anwendet wie um 9 Uhr. Inkonsistenz ist das Problem des Menschen, nicht Inkompetenz.<sup>[1]</sup>

Erfahrene Juristen treffen 72% korrekte Entscheidungen - aber jeder Jurist trifft andere falsche Entscheidungen. Die Fehler sind nicht systematisch, sondern zufällig. Ermüdung, Zeitdruck, persönliche Interpretation. Ein LLM kennt keine Ermüdung.

### Der übertragbare Mechanismus

Ob das Regelwerk "Billing Guideline", "§14 UStG" oder "BMF-Pauschalen 2026" heißt: Dokument gegen Regel prüfen, Abweichung identifizieren, Entscheidung dokumentieren. Der Mechanismus ist identisch.

<!-- Summary-Tabelle: Regelwerk-Anwendung -->
<div class="not-prose my-8">
<div class="overflow-x-auto">
<table class="w-full border-collapse text-sm">
<thead>
<tr class="bg-gosign-dark text-white">
<th class="p-3 text-left font-bold">Dimension</th>
<th class="p-3 text-left font-bold">Trainiertes Modell</th>
<th class="p-3 text-left font-bold">Konfigurierter Agent</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border bg-gosign-white">
<td class="p-3 font-medium text-gosign-dark">Regeländerung</td>
<td class="p-3 text-gosign-text">Nachtraining (Wochen, $5k - $20k)</td>
<td class="p-3 text-gosign-text">Regelwerk-Update (Minuten, $0)</td>
</tr>
<tr class="border-b border-gosign-border bg-gosign-light">
<td class="p-3 font-medium text-gosign-dark">Erklärbarkeit</td>
<td class="p-3 text-gosign-text">"Modell hat gelernt" (Black Box)</td>
<td class="p-3 text-gosign-text">Regel + Version + Kontext (Entscheidungsakte)</td>
</tr>
<tr class="border-b border-gosign-border bg-gosign-white">
<td class="p-3 font-medium text-gosign-dark">Anfechtbarkeit</td>
<td class="p-3 text-gosign-text">Nicht möglich (keine Entscheidungsakte)</td>
<td class="p-3 text-gosign-text">Ja (Betroffener sieht Regel und kann widersprechen)</td>
</tr>
<tr class="border-b border-gosign-border bg-gosign-light">
<td class="p-3 font-medium text-gosign-dark">Modellwechsel</td>
<td class="p-3 text-gosign-text">Neues Training nötig (Lock-in)</td>
<td class="p-3 text-gosign-text">0 Aufwand (modell-agnostisch)</td>
</tr>
<tr class="border-b border-gosign-border bg-gosign-white">
<td class="p-3 font-medium text-gosign-dark">Audit Trail</td>
<td class="p-3 text-gosign-text">Eingabe + Ausgabe (keine Begründung)</td>
<td class="p-3 text-gosign-text">Eingabe + Regel + Version + Konfidenz + Ergebnis</td>
</tr>
<tr class="border-b border-gosign-border bg-gosign-light">
<td class="p-3 font-medium text-gosign-dark">EU AI Act (Aug 2026)</td>
<td class="p-3 text-gosign-text">Art. 13, 14, 86: Problematisch</td>
<td class="p-3 text-gosign-text">Art. 13, 14, 86: Konform by Design</td>
</tr>
<tr class="bg-gosign-white">
<td class="p-3 font-medium text-gosign-dark">Break-Even Fine-Tuning</td>
<td class="p-3 text-gosign-text">Ab ~35.000 Queries/Monat<sup>[6]</sup></td>
<td class="p-3 text-gosign-text">Sofort wirtschaftlich</td>
</tr>
</tbody>
</table>
</div>
</div>

Eine Studie von Chauhan et al. (2025) beziffert den Break-Even-Punkt von Fine-Tuning gegenüber Prompting auf etwa 35.000 Queries pro Monat.<sup>[6]</sup> Die meisten Enterprise-HR- und Finance-Prozesse liegen weit darunter.

## Drei Dinge statt Training

Wenn kein Training, was dann? Drei Komponenten ersetzen das, was Fine-Tuning verspricht, aber strukturell nicht halten kann.

### 1. Regelwerk

Alles was ein Agent wissen muss, steht in einem Gesetz, einer Verordnung, einem Tarifvertrag oder einer Betriebsvereinbarung. Diese Regeln ändern sich. Steuerrecht ändert sich jährlich. BMF-Pauschalen ändern sich jährlich. EU-Verordnungen ändern sich.

Ein trainiertes Modell muss bei jeder Änderung nachtrainiert werden. Ein Regelwerk wird aktualisiert. Sofort wirksam, versioniert, auditierbar. Kein GPU-Cluster, kein Evaluierungszyklus, keine Regressionsrisiken.

RAG (Retrieval Augmented Generation) reduziert faktische Fehler um bis zu 50%.<sup>[11]</sup> Nicht weil das Modell schlauer wird. Sondern weil es die aktuelle Regel sieht statt eine veraltete Gewichtung abzurufen.

### 2. Kontext

Der Agent braucht nicht 10.000 historische Reisekostenabrechnungen. Er braucht diese eine Abrechnung: Reisedatum, Abfahrt, Rückkehr, Hotel, Frühstück inklusive oder nicht. Das ist der Kontext dieser Entscheidung.

Er wird über strukturierte Eingaben oder RAG zugeführt, nicht eintrainiert. Wenn sich der Kontext ändert - andere Reise, anderer Mitarbeiter - ändert sich die Entscheidung. Nicht das Modell.

Ein konkretes Beispiel: Die [Reisekosten-Engine](/de/leistungen/travel-decision-layer/) prüft Verpflegungspauschalen gegen §9 EStG. Der Kontext ist die einzelne Reise. Das Regelwerk ist das aktuelle Steuerrecht. Das Foundation Model ist austauschbar.

### 3. Entscheidungsrahmen

Wer entscheidet was? Nicht jede Entscheidung in einem Prozess ist gleich.

Die Verpflegungspauschale ist Regelwerk: §9 EStG, deterministisch, 100% Confidence. Die Frage, ob ein Bewirtungsaufwand "angemessen" ist, ist Ermessen: Mensch. Die Klassifikation eines unleserlichen Kassenbons ist KI: LLM-Extraktion, probabilistisch.

Diese Zerlegung in Micro-Decisions mit Zuordnung Mensch/Regelwerk/KI ist die eigentliche Architekturarbeit. Nicht das Training. Der [Decision Layer](/de/decision-layer/) formalisiert genau diese Zerlegung. Details zur Architektur: [Decision Layer erklärt](/de/magazin/decision-layer-erklaert/).

<!-- Micro-Decision Demo -->
<div class="not-prose my-10">
<div class="bg-gosign-light border border-gosign-border rounded-card overflow-hidden">
<div class="p-6 sm:p-8">
<p class="text-h3 font-bold text-gosign-dark mb-2">Micro-Decision in der Praxis</p>
<p class="text-gosign-text text-sm mb-6">Reisekostenabrechnung: 8-Stunden-Tag, Inlandsreise, Hotel mit Frühstück</p>

<div class="space-y-3">

<div class="bg-gosign-white border border-gosign-border rounded-lg p-4">
<div class="flex flex-wrap items-center gap-3">
<span class="text-xs font-mono bg-gosign-dark text-white px-2 py-0.5 rounded">#1</span>
<span class="font-medium text-gosign-dark text-sm">Reisedatum und Abwesenheitsdauer</span>
<span class="text-xs px-2 py-0.5 rounded bg-blue-100 text-blue-800 font-medium">Kontext</span>
<span class="text-xs text-gosign-text-light ml-auto">Input: Belege</span>
</div>
</div>

<div class="bg-gosign-white border border-gosign-border rounded-lg p-4">
<div class="flex flex-wrap items-center gap-3">
<span class="text-xs font-mono bg-gosign-dark text-white px-2 py-0.5 rounded">#2</span>
<span class="font-medium text-gosign-dark text-sm">Verpflegungspauschale berechnen</span>
<span class="text-xs px-2 py-0.5 rounded bg-green-100 text-green-800 font-medium">Regelwerk</span>
<span class="text-xs text-gosign-text-light ml-auto">§9 EStG v2026-01</span>
</div>
</div>

<div class="bg-gosign-white border border-gosign-border rounded-lg p-4">
<div class="flex flex-wrap items-center gap-3">
<span class="text-xs font-mono bg-gosign-dark text-white px-2 py-0.5 rounded">#3</span>
<span class="font-medium text-gosign-dark text-sm">Frühstückskürzung anwenden</span>
<span class="text-xs px-2 py-0.5 rounded bg-green-100 text-green-800 font-medium">Regelwerk</span>
<span class="text-xs text-gosign-text-light ml-auto">§9 Abs. 4a S. 8 EStG</span>
</div>
</div>

<div class="bg-gosign-white border border-gosign-border rounded-lg p-4">
<div class="flex flex-wrap items-center gap-3">
<span class="text-xs font-mono bg-gosign-dark text-white px-2 py-0.5 rounded">#4</span>
<span class="font-medium text-gosign-dark text-sm">Kassenbon klassifizieren</span>
<span class="text-xs px-2 py-0.5 rounded bg-gosign-accent/10 text-gosign-accent font-medium">KI</span>
<span class="text-xs text-gosign-text-light ml-auto">LLM-Extraktion, Confidence: 87%</span>
</div>
</div>

<div class="bg-gosign-white border border-gosign-border rounded-lg p-4">
<div class="flex flex-wrap items-center gap-3">
<span class="text-xs font-mono bg-gosign-dark text-white px-2 py-0.5 rounded">#5</span>
<span class="font-medium text-gosign-dark text-sm">Bewirtungsaufwand "angemessen"?</span>
<span class="text-xs px-2 py-0.5 rounded bg-yellow-100 text-yellow-800 font-medium">Mensch</span>
<span class="text-xs text-gosign-text-light ml-auto">Ermessen, Sachbearbeiter prüft</span>
</div>
</div>

<div class="bg-gosign-white border border-gosign-border rounded-lg p-4">
<div class="flex flex-wrap items-center gap-3">
<span class="text-xs font-mono bg-gosign-dark text-white px-2 py-0.5 rounded">#6</span>
<span class="font-medium text-gosign-dark text-sm">GoBD-konforme Buchung erstellen</span>
<span class="text-xs px-2 py-0.5 rounded bg-green-100 text-green-800 font-medium">Regelwerk</span>
<span class="text-xs text-gosign-text-light ml-auto">GoBD §146 AO, versioniert</span>
</div>
</div>

</div>

<div class="mt-6 p-4 bg-gosign-dark rounded-lg">
<p class="text-gosign-text-on-dark text-sm">Jeder dieser Schritte hat einen festen Typ: <span class="text-green-400">Regelwerk</span> (deterministisch), <span class="text-gosign-accent-on-dark">KI</span> (probabilistisch, mit Confidence-Schwelle) oder <span class="text-yellow-400">Mensch</span> (Ermessen). Wenn sich §9 EStG ändert, wird die Regel aktualisiert. Kein Nachtraining. Kein neues Modell.</p>
</div>
</div>
</div>
</div>

## Die drei Schichten: Architektur statt Training

Die Architektur hinter einem konfigurierten Agent besteht aus drei Schichten. Jede Schicht ist unabhängig austauschbar.

<!-- Drei-Schichten-Diagramm -->
<div class="not-prose my-10">
<div class="max-w-2xl mx-auto">

<div class="bg-gosign-dark border-2 border-gosign-accent rounded-t-card p-6">
<div class="flex items-center gap-3 mb-3">
<span class="text-gosign-accent-on-dark text-xs uppercase tracking-wider font-bold">Schicht 3</span>
<span class="text-white font-bold text-lg">Decision Layer</span>
</div>
<div class="flex flex-wrap gap-2">
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Micro-Decisions</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Mensch / Regelwerk / KI</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Entscheidungsakte</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Audit Trail</span>
</div>
</div>

<div class="bg-gosign-dark border-x-2 border-gosign-accent p-6 border-t border-white/10">
<div class="flex items-center gap-3 mb-3">
<span class="text-gosign-accent-on-dark text-xs uppercase tracking-wider font-bold">Schicht 2</span>
<span class="text-white font-bold text-lg">Regelwerk (versioniert, austauschbar)</span>
</div>
<div class="flex flex-wrap gap-2">
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">UStG</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">EStG</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">GoBD</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Tarifvertrag</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">BV</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">EU AI Act</span>
</div>
</div>

<div class="bg-gosign-darker border-2 border-white/20 rounded-b-card p-6">
<div class="flex items-center gap-3 mb-3">
<span class="text-gosign-text-on-dark text-xs uppercase tracking-wider font-bold">Schicht 1</span>
<span class="text-white font-bold text-lg">Foundation Model (austauschbar)</span>
</div>
<div class="flex flex-wrap gap-2">
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Claude</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">GPT</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Llama</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Mistral</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Gemini</span>
</div>
</div>

<div class="mt-4 flex items-start gap-3 p-4 bg-gosign-light border border-gosign-border rounded-card">
<span class="text-gosign-accent text-lg mt-0.5">&#x2191;</span>
<p class="text-gosign-text text-sm">Alles oberhalb von Schicht 1 bleibt, wenn das Modell wechselt. Regelwerk, Decision Layer, Entscheidungsakten, Audit Trail - alles modell-agnostisch. Kein Nachtraining. Kein Lock-in.</p>
</div>

</div>
</div>

Warum drei Schichten? Weil jede eine andere Verantwortung hat.

Das Foundation Model liefert Sprachverständnis und Reasoning. Es versteht den Kontext, extrahiert Informationen aus Dokumenten, klassifiziert Eingaben. Es muss nicht wissen, was §9 EStG sagt. Es muss verstehen, was ein Gesetzestext ist.

Das Regelwerk enthält die Geschäftslogik. Gesetze, Verordnungen, Tarifverträge, Betriebsvereinbarungen. Jede Regel hat eine Version. Jede Version hat ein Gültigkeitsdatum. Wenn sich das Gesetz ändert, wird die Regel aktualisiert. Nicht das Modell.

Der [Decision Layer](/de/decision-layer/) steuert, wer was entscheiden darf. Er zerlegt Prozesse in Entscheidungsschritte. Definiert für jeden: Mensch, Regelwerk oder KI. Dokumentiert jede Entscheidung mit Regel, Version, Kontext und Ergebnis.

## Was Training wirklich kostet

Nicht in Dollar. In Abhängigkeiten.

### Lock-in

Ein fine-getuntes Modell bindet Sie an diesen Anbieter. Das Trainingsset, die Gewichte, die Evaluierungspipeline: alles proprietär. Modellwechsel = neues Training = neue Kosten = neuer Zeitverlust.

Ein konfigurierter Agent wechselt das Foundation Model ohne eine einzige Regel zu ändern. Claude heute, GPT morgen, ein Open-Source-Modell nächste Woche. Das Regelwerk bleibt. Der Decision Layer bleibt. Die Entscheidungsakten bleiben.

### Wartung

Jede Gesetzesänderung erfordert Nachtraining. In Finance ändern sich Steuerrecht, BMF-Schreiben und SV-Beitragssätze jährlich. In HR ändern sich Tarifverträge, Betriebsvereinbarungen und EU-Regulatorik.

Ein trainierter Agent braucht kontinuierliche Pflege, die aussieht wie ein Softwareprojekt. Ein konfigurierter Agent braucht einen Regelwerk-Editor.

MIT und Stanford (Choi & Xie, 2025) zeigen: AI reduziert den Monatsabschluss um 7,5 Tage.<sup>[7]</sup> Aber 62% der Buchhalter sorgen sich über AI-Fehler.<sup>[8]</sup> Die Sorge ist berechtigt - bei trainierten Modellen. Bei konfigurierten Agenten mit Entscheidungsakte und Anfechtungsmöglichkeit ist jeder Fehler identifizierbar und korrigierbar.

### Erklärbarkeit

Ein trainiertes Modell kann Ihnen sagen, was es entschieden hat. Es kann nicht sagen, warum.

"Das Modell hat gelernt" ist keine Begründung, die ein Betriebsprüfer akzeptiert. Kein Betriebsrat akzeptiert sie. Kein abgelehnter Kandidat akzeptiert sie.

"Regel §9 EStG v2026-01, angewandt auf Abwesenheit 14h15min" ist eine Begründung.

Wenn Sie die Entscheidung nicht erklären können, können Sie sie nicht anfechten lassen. Und wenn Sie sie nicht anfechten lassen können, genügt ein Hochrisiko-System den Pflichten des EU AI Act nicht - geltende Frist 2. August 2026, voraussichtlich verschoben auf Dezember 2027.<sup>[10]</sup>

### Hat Fine-Tuning seinen Platz?

Ja. Ab etwa 35.000 Queries pro Monat mit stabilem Regelwerk wird Fine-Tuning wirtschaftlich.<sup>[6]</sup> Sprach-Adaption, domänenspezifischer Jargon, Latenz-Optimierung: dafür gibt es gute Gründe.

Aber dort, wo die Branche es heute verkauft - Enterprise HR und Finance mit jährlich wechselnden Gesetzen - ist es die falsche Architekturentscheidung. Gartner prognostiziert, dass über 40% der Agentic-AI-Projekte bis 2027 scheitern werden.<sup>[9]</sup> Nicht an der Modellleistung. An der Governance.

## Die Frage, die Ihr Board stellen sollte

Nicht: "Auf welchen Daten wurde euer Agent trainiert?"

Sondern:

**1. Welches Regelwerk liegt der Entscheidung zugrunde? Welche Version galt zum Entscheidungszeitpunkt?**

Wenn die Antwort "Das ist im Modell" lautet, gibt es keine Version. Keine Änderungshistorie. Keinen Audit Trail.

**2. Was passiert, wenn sich die Regel ändert? Retraining oder Update?**

Wenn die Antwort "Wir trainieren nach" lautet, bezahlen Sie für Wartung, die unnötig ist.

**3. Kann der Betroffene die Einzelentscheidung einsehen und anfechten?**

Wenn keine Antwort kommt, erfüllt ein Hochrisiko-System die Anforderungen nicht - geltende Frist 2. August 2026, voraussichtlich verschoben auf Dezember 2027. Art. 86 EU AI Act: Recht auf Erklärung. Nicht optional.<sup>[10]</sup>

## Gosigns Ansatz

Gosigns Decision Layer ist eine Implementierung dieser Architektur. Er zerlegt Prozesse in Entscheidungsschritte. Definiert für jeden: Mensch, Regelwerk oder KI. Regelwerke sind versioniert. Entscheidungen sind auditierbar. Ergebnisse sind anfechtbar.

[48 HR-Agenten](/de/hr-agent-katalog/) und [49 Finance-Agenten](/de/finance-agent-katalog/), jeder mit Micro-Decision-Tabelle. Kein Fine-Tuning. Kein Lock-in. Kein Nachtraining bei Gesetzesänderungen.

---

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Quellenangaben</p>
<ol class="text-sm text-gosign-text space-y-2 list-decimal list-inside">
<li id="fn1">Better Bill GPT, Whitehouse et al. (April 2025). Legal Invoice Review: LLM erreicht 92% Accuracy bei Prüfung von Anwaltshonoraren gegen Billing Guidelines. Peer-reviewed.</li>
<li id="fn2">Better Bill GPT, Whitehouse et al. (April 2025). F-Score bei Einzelposition-Klassifikation: LLM 81% vs. beste menschliche Gruppe 43%.</li>
<li id="fn3">Better Bill GPT, Whitehouse et al. (April 2025). Bearbeitungszeit pro Rechnung: LLM 3,6 Sekunden vs. erfahrene Juristen 194 bis 316 Sekunden.</li>
<li id="fn4">Better Bill GPT, Whitehouse et al. (April 2025). Kostenreduktion bei Legal Invoice Review: 99,97% ($4,27 vs. &lt;$0,01 pro Rechnung).</li>
<li id="fn5">Kumar Gauraw (März 2026). "Die meisten greifen zu früh zum Fine-Tuning."</li>
<li id="fn6">Chauhan et al., Journal of Information Systems Engineering (2025). Break-Even Fine-Tuning vs. Prompting: ~35.000 Queries pro Monat.</li>
<li id="fn7">MIT/Stanford, Choi & Xie (August 2025). AI reduziert den Monatsabschluss um durchschnittlich 7,5 Tage.</li>
<li id="fn8">MIT/Stanford, Choi & Xie (August 2025). 62% der Buchhalter äußern Bedenken über AI-Fehler in Finanzprozessen.</li>
<li id="fn9">Gartner (Juni 2025). Prognose: Über 40% der Agentic-AI-Projekte scheitern bis 2027.</li>
<li id="fn10">EU AI Act (VO 2024/1689), Crowell & Moring (Februar 2026). Hochrisiko-Pflichten nach aktuellem Recht ab 2. August 2026 (Verschiebung auf 2. Dezember 2027 am 7. Mai 2026 im Digital Omnibus vorläufig geeinigt, formale Verabschiedung ausstehend): Art. 13 (Transparenz), Art. 14 (menschliche Aufsicht), Art. 86 (Recht auf Erklärung). Annex III(4): Recruiting als Hochrisiko-System.</li>
<li id="fn11">IBM (2024). RAG reduziert faktische Fehler in LLM-Ausgaben um bis zu 50%.</li>
</ol>
</div>

--- Was sind KI-Agenten? Drei Typen für Unternehmen ---
> KI-Agenten: Document Agents, Workflow Agents, Knowledge Agents. Wie sie fachliche Aufgaben autonom ausführen und sich von Chatbots und RPA unterscheiden

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Auf einen Blick - KI-Agenten im Unternehmen</p>
<ul class="text-body text-gosign-text space-y-2">
<li>KI-Agenten sind spezialisierte Softwarekomponenten, die fachliche Aufgaben autonom ausführen - anders als Chatbots (nur Antworten) oder RPA (nur regelbasiert).</li>
<li>Drei Typen: Document Agents (Dokumente lesen und verarbeiten), Workflow Agents (Prozesse systemübergreifend orchestrieren), Knowledge Agents (kontextbasierte Antworten aus Unternehmenswissen).</li>
<li>McKinsey (2024) schätzt, dass KI-Agenten bis 2030 bis zu 30 % der Arbeitsstunden in den meisten Berufen automatisieren könnten.</li>
<li>Der Agent ist nicht das Modell - das Sprachmodell ist austauschbar, der Agent liefert Fachlogik, Systemintegration und Governance.</li>
<li>Enterprise-Einsatz erfordert einen Decision Layer zwischen Agent und Zielsystem - damit jede automatisierte Entscheidung nachvollziehbar, auditierbar und compliant ist.</li>
</ul>
</div>

## Was ist ein KI-Agent?

Ein KI-Agent ist eine spezialisierte Softwarekomponente, die auf Basis von Large Language Models (LLMs) fachliche Aufgaben autonom ausführt. Im Unterschied zu einem Chatbot, der auf Fragen antwortet, führt ein Agent Handlungen aus: Er liest ein Dokument, bewertet den Inhalt, trifft eine Entscheidung und löst eine Aktion in einem Zielsystem aus.

KI-Agenten im Enterprise-Kontext arbeiten nicht frei. Sie operieren innerhalb definierter Grenzen: Regelwerke, Geltungsbereiche, Konfidenzschwellen, Eskalationsregeln. Jede Agenten-Entscheidung ist nachvollziehbar und auditierbar.

Die Grundlage eines KI-Agenten ist ein Sprachmodell - Claude, ChatGPT, Gemini, Llama, Mistral, DeepSeek oder gpt-oss. Das Modell liefert das Sprachverständnis. Der Agent liefert die Fachlogik, die Systemintegration und die Governance.

## Abgrenzung: KI-Agent vs. Chatbot vs. RPA

Diese drei Konzepte werden häufig verwechselt. Sie lösen unterschiedliche Probleme.

**Chatbot:** Ein Chatbot beantwortet Fragen in natürlicher Sprache. Er hat keine Handlungskompetenz. Wenn ein Mitarbeiter fragt "Wie viele Urlaubstage habe ich noch?", antwortet der Chatbot. Er bucht keinen Urlaub, er prüft keine Regeln, er erzeugt keinen Audit Trail.

**RPA (Robotic Process Automation):** RPA automatisiert regelbasierte, repetitive Aufgaben über Benutzeroberflächen. Ein RPA-Bot klickt sich durch SAP, kopiert Daten von A nach B, füllt Formulare aus. RPA hat kein Sprachverständnis. Wenn sich das Formular ändert, bricht der Bot.

**KI-Agent:** Ein KI-Agent versteht Kontext, interpretiert unstrukturierte Daten und trifft Entscheidungen. Er liest eine Rechnung - unabhängig vom Format - versteht den Inhalt, wendet Regelwerke an und erzeugt einen Buchungsvorschlag. Wenn sich das Rechnungsformat ändert, funktioniert der Agent weiter, weil er den Inhalt versteht, nicht das Layout erkennt.

| Eigenschaft | Chatbot | RPA | KI-Agent |
|------------|---------|-----|----------|
| Sprachverständnis | Ja | Nein | Ja |
| Handlungskompetenz | Nein | Ja (regelbasiert) | Ja (kontextbasiert) |
| Unstrukturierte Daten | Ja | Nein | Ja |
| Governance/Audit | Nein | Teilweise | Ja (über Decision Layer) |
| Systemintegration | Oberflächlich | Über UI | Über API/Integration Layer |
| Anpassung bei Änderungen | Prompt ändern | Bot neu programmieren | Agent lernt Kontext |

## Drei Typen von Enterprise KI-Agenten

In der Gosign-Architektur gibt es drei Agent-Typen. Jeder Typ hat einen definierten Aufgabenbereich und arbeitet innerhalb der Grenzen, die der Decision Layer vorgibt.

### Document Agents

Document Agents lesen, verstehen und verarbeiten Dokumente. Rechnungen, Krankmeldungen, Verträge, Bescheinigungen, Belege, Gutschriften.

Der entscheidende Unterschied zu OCR oder Template-Erkennung: Document Agents haben echtes Sprachverständnis. Sie erkennen nicht Felder an bestimmten Positionen auf einer Seite, sondern verstehen den Inhalt des Dokuments. Eine Rechnung im PDF-Format, als gescanntes Bild oder als E-Mail-Anhang - der Document Agent versteht alle drei.

Ein Document Agent für Belegverarbeitung liest eine Eingangsrechnung und extrahiert: Rechnungssteller, Betrag, Leistungsbeschreibung, Datum, Steuersatz, Bankverbindung. Er erzeugt einen strukturierten Datensatz, der an den Decision Layer übergeben wird.

Document Agents arbeiten nicht isoliert. Sie sind der Eingangspunkt eines Workflows - nach dem Lesen des Dokuments übernimmt der Workflow Agent.

### Workflow Agents

Workflow Agents orchestrieren Prozesse systemübergreifend. Sie koordinieren den Ablauf zwischen Document Agent, Decision Layer und Zielsystem.

Ein Workflow Agent für die Rechnungsverarbeitung koordiniert: Der Document Agent liest die Rechnung → der Decision Layer prüft den Buchungsvorschlag → bei hoher Konfidenz geht die Buchung ins Zielsystem → bei niedriger Konfidenz wird an den Sachbearbeiter eskaliert → nach Freigabe wird die Buchung abgeschlossen → der gesamte Vorgang wird im Audit Trail dokumentiert.

Workflow Agents handhaben auch Ausnahmen: Was passiert, wenn das Zielsystem nicht erreichbar ist? Was passiert bei einem Timeout? Was passiert, wenn der Sachbearbeiter nicht reagiert? Der Workflow Agent hat Eskalationsregeln, Retry-Mechanismen und Timeout-Logik.

Die Workflow-Orchestrierung läuft über [Trigger.dev](https://trigger.dev/) oder [Camunda](https://camunda.com/) - je nach Komplexität und Compliance-Anforderungen des Kunden. Workflows sind versioniert, testbar und als Code definierbar.

### Knowledge Agents

Knowledge Agents liefern kontextbasierte Antworten aus dem Unternehmenswissen. Betriebsvereinbarungen, Richtlinien, Tarifverträge, Compliance-Regeln, interne Policies.

Der Unterschied zu einer Suchfunktion: Ein Knowledge Agent versteht die Frage, sucht im relevanten Kontext und liefert eine Antwort mit Quellenangabe und Regelversion. Wenn ein Sachbearbeiter fragt "Gilt die Nachtarbeitszulage auch für Teilzeitkräfte im Tarifgebiet West?", liefert der Knowledge Agent die Antwort mit Verweis auf die gültige Betriebsvereinbarung in der aktuellen Version.

Knowledge Agents nutzen RAG (Retrieval Augmented Generation): Das Unternehmenswissen wird in einer Vektordatenbank indexiert. Der Agent sucht die relevanten Passagen und generiert eine Antwort auf Basis dieser Quellen - nicht auf Basis seines Trainings.

Jede Antwort enthält: Die Quelle, die Regelversion, das Gültigkeitsdatum. Keine Halluzinationen, keine erfundenen Regelverweise.

## Wie KI-Agenten in der Enterprise-Architektur zusammenwirken

Die drei Agent-Typen arbeiten nicht isoliert. In einer typischen Enterprise-Implementierung orchestriert der Workflow Agent den Gesamtprozess und delegiert an spezialisierte Document und Knowledge Agents.

Ein Beispiel aus der HR-Sachbearbeitung: Eine Krankmeldung geht ein (E-Mail mit PDF-Anhang). Der Document Agent liest die Krankmeldung und extrahiert: Mitarbeiter, Zeitraum, ärztliche Bescheinigung, Folgebescheinigung. Der Knowledge Agent prüft: Welche Regeln gelten für diesen Mitarbeiter? Tarifvertrag, Betriebsvereinbarung, individuelle Zusatzvereinbarungen. Der Decision Layer bewertet: Ist die Entgeltfortzahlung korrekt berechnet? Stimmen die Fristen? Der Workflow Agent koordiniert den gesamten Ablauf und stellt sicher, dass alle Systeme aktualisiert werden.

Jeder Agent hat seinen definierten Aufgabenbereich. Kein Agent "entscheidet" allein über geschäftskritische Vorgänge. Der [Decision Layer](/de/decision-layer/) sitzt zwischen Agent und Zielsystem und stellt Governance sicher.

## Modell-Agnostik: Der Agent ist nicht das Modell

Eine häufige Verwechslung: Der Agent ist nicht das Sprachmodell. Das Modell (Claude, ChatGPT, Llama) liefert das Sprachverständnis. Der Agent liefert die Fachlogik, die Systemintegration, die Governance.

In der Gosign-Architektur ist der Model Layer austauschbar. Wenn ein neues Modell verfügbar wird - leistungsfähiger, günstiger, mit besserer Lizenz - kann es integriert werden, ohne die darüberliegenden Layer zu ändern. Die Geschäftslogik im Decision Layer, die Workflows, die Regelwerke bleiben unverändert.

Ein Agent kann auch mehrere Modelle nutzen: Ein kostengünstiges Open-Source-Modell für die Vorklassifizierung und ein leistungsfähigeres Modell für komplexe Entscheidungen. Das Routing zwischen Modellen ist konfigurierbar.

Diese Modell-Agnostik verhindert Vendor Lock-in. Kein Unternehmen ist auf einen einzelnen Modellanbieter angewiesen.

## Voraussetzungen für Enterprise KI-Agenten

KI-Agenten in Enterprise-Umgebungen brauchen mehr als ein Sprachmodell:

**Governance:** Jede Agenten-Entscheidung muss nachvollziehbar und auditierbar sein. Der Decision Layer stellt das sicher.

**Integration:** Agenten müssen in bestehende Systeme integriert werden - SAP, [DATEV](https://www.datev.de/), [Workday](https://www.workday.com/), [SuccessFactors](https://www.sap.com/products/hcm.html), SharePoint. Der Integration Layer entkoppelt die Agent-Logik vom Zielsystem.

**Infrastruktur:** Agenten brauchen eine Laufzeitumgebung: LLM-Hosting, Vektordatenbanken für RAG, Workflow-Engine, API-Gateway. Diese Infrastruktur kann in der Cloud, Self-Hosted oder hybrid betrieben werden.

**Mitbestimmung:** In Deutschland haben Betriebsräte Mitbestimmungsrechte bei der Einführung von KI-Systemen. Die Architektur muss das von Anfang an berücksichtigen.

Mehr dazu: [AI Agents im Detail](/de/leistungen/ai-agents/)

<a href="/de/kontakt/" target="_blank" rel="noopener noreferrer">Termin vereinbaren</a> - Wir zeigen Ihnen, welcher Agent-Typ für Ihren Prozess passt.

--- Workflow-Audit für Agent Readiness: Methodik ---
> HR-Prozesse in Entscheidungspunkte zerlegen, für Mensch, Regelwerk oder KI klassifizieren - und in eine Decision-Layer-Spezifikation übersetzen, die EU-AI-Act-Anfechtbarkeit erfüllt.

## "Welche HR-Prozesse sind KI-fähig?" ist die falsche Frage

Eine HR-Verantwortliche sitzt im Steuerkreis ihres KI-Programms. Auf der Folie steht: "Phase 1 - Krankmeldungsverarbeitung automatisieren." Sechs Wochen später ist der Pilot zurückgestellt. Die Begründung: "Funktioniert nicht zuverlässig genug." Was ist passiert? Das Projekt hat den Workflow als eine Einheit behandelt. Aber Krankmeldungsverarbeitung ist keine Einheit. Sie ist eine Sequenz aus zwölf Entscheidungspunkten - und zwei davon hätten beim Menschen bleiben müssen.

Das ist keine Anekdote. Es ist das Grundmuster. KI-Projekte in HR scheitern selten an der Modellqualität und fast immer an der Granularität der Frage. Wer fragt "Welche Workflows automatisieren wir?", bekommt unbrauchbare Antworten. Wer fragt "An welchen Entscheidungspunkten innerhalb eines Workflows?", bekommt eine umsetzbare Architektur.

Diese Methodik beschreibt, wie man die richtige Frage stellt. Sie ist technologie-agnostisch - keine Modellpräferenz, kein Anbieter, kein Stack. Sie produziert vier Artefakte aus einem Audit: ein Agent-Design, eine Betriebsvereinbarungs-Vorlage, eine Decision-Layer-Spezifikation und die [EU-AI-Act-Dokumentation für Hochrisiko-Systeme](/de/magazin/eu-ai-act-gilt-weltweit/) (Frist 2. August 2026, voraussichtlich verschoben auf Dezember 2027).

McKinsey [schätzt](https://www.mckinsey.com/capabilities/people-and-organizational-performance/our-insights/generative-ai-and-the-future-of-hr), dass 60 - 70 % der administrativen Tätigkeiten in HR mit existierender Technologie automatisierbar sind. Die Adoption liegt bei 3 %. Die Lücke entsteht nicht aus Skepsis. Sie entsteht aus dem Mangel an einer Methode, die Workflow-Ebene auf Entscheidungspunkt-Ebene herunterbricht.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Auf einen Blick</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Wer "den Workflow automatisiert", scheitert. Wer einzelne Entscheidungspunkte klassifiziert, baut eine prüfbare Architektur.</li>
<li>Ein typischer HR-Prozess hat 10 - 30 Entscheidungspunkte. Erfahrene Mitarbeiter treffen die meisten unbewusst - das ist der Grund, warum sie im Lastenheft fehlen.</li>
<li>Jeder Entscheidungspunkt ist Mensch, Regel oder KI - mit drei klaren Tests, nicht mit Bauchgefühl. Die Mehrdeutigkeit ist die häufigste Audit-Falle.</li>
<li>Das Audit-Ergebnis ist gleichzeitig Agent-Design, Betriebsvereinbarungs-Vorlage, Decision-Layer-Spezifikation und EU-AI-Act-Dokumentation. Vier Stakeholder, ein Dokument.</li>
<li>Anfechtbarkeit ist Architektur, nicht Compliance-Anhang. Wer sie nachträglich anflanscht, hat keine prüfbare KI - egal was das Modell kann.</li>
</ul>
</div>

## Ein typischer HR-Prozess hat zwölf Entscheidungspunkte, nicht einen

Vor der Klassifikation steht die Kartierung. Sie scheitert an einer Eigenheit erfahrener Mitarbeiter: Sie treffen viele Entscheidungen unbewusst. "Prüfen, ob die Krankmeldung ein Startdatum hat" wahrnehmen sie nicht als Entscheidung. Sie tun es einfach. Für einen Agenten ist jede solche Prüfung eine explizite Entscheidung, die spezifiziert werden muss.

Die Methode, die diese impliziten Entscheidungen sichtbar macht, ist die "Was könnte schiefgehen"-Technik: Für jeden Schritt im Workflow fragen, was hier fehlschlagen oder eine andere Aktion erfordern könnte. Jede Antwort offenbart einen Entscheidungspunkt.

Bevor man kartiert, muss man die Workflow-Grenze ziehen. Ein Workflow hat einen Auslöser, eine Sequenz von Verarbeitungsschritten und einen oder mehrere Endpunkte. Häufiger Fehler: Die Grenze zu weit fassen. "Onboarding" ist nicht ein Workflow - es ist eine Sammlung von fünf bis acht Teil-Workflows (Vertragserstellung, IT-Provisioning, Compliance-Dokumentation, Arbeitsplatzeinrichtung, Schulungsanmeldung, Buddy-Zuordnung, Probezeit-Tracking). Jeden Teil-Workflow separat auditieren.

Am Beispiel der Krankmeldungsverarbeitung - Auslöser: Mitarbeiter reicht eine Krankmeldung ein. Endpunkte: SAP-Datensatz aktualisiert, Vorgesetzter informiert, Payroll angepasst, Wiedereingliederungsaktion geplant falls Schwelle überschritten. Was die meisten Organisationen als einen Schritt beschreiben, ist eine Kette aus zwölf:

| # | Entscheidungspunkt | Frage die der Prozess beantwortet |
|---|-------------------|-----------------------------------|
| 1 | Dokumenteneingang | Krankmeldung, ärztliches Attest, Reha-Bescheinigung oder etwas anderes? |
| 2 | Vollständigkeitsprüfung | Mitarbeitername, Diagnoseperiode, Arztname, Arztunterschrift vorhanden? |
| 3 | Mitarbeiteridentifikation | Welchem Mitarbeiter gehört dieses Dokument? |
| 4 | Gesellschaftszuordnung | In welcher Gesellschaft ist der Mitarbeiter? |
| 5 | Tarifvertrags-Lookup | Welcher Tarifvertrag gilt? |
| 6 | Lohnfortzahlungsanspruch | 6-Wochen-Frist [§ 3 EFZG](https://www.gesetze-im-internet.de/entgfg/__3.html) erfüllt? Wartezeit? |
| 7 | Dauerbewertung | Einzeltag, Kurzabwesenheit oder längere Abwesenheit? |
| 8 | Mustererkennung | Schwelle für [BEM-Pflicht](https://www.gesetze-im-internet.de/sgb_9_2018/__167.html) überschritten? |
| 9 | Payroll-Auswirkung | Überstundenstornierung, Schichtzuschlag, Bonusanteilung? |
| 10 | Systemaktualisierung | Was ändert sich in SAP/SuccessFactors? |
| 11 | Benachrichtigungs-Routing | Wer wird informiert (Vorgesetzter, HR BP, Payroll, Betriebsrat)? |
| 12 | Folgeaktion-Planung | Rückkehrdatum, BEM-Einladung, betriebsärztliche Überweisung? |

Zwölf Entscheidungspunkte in einem Prozess, den die meisten Organisationen als "Mitarbeiter reicht Krankmeldung ein, wir verarbeiten sie" beschreiben. Die Lücke zwischen wahrgenommener Einfachheit und tatsächlicher Komplexität ist typisch - und sie ist der Grund, warum "Wir automatisieren Krankmeldungen" als Projektziel keine Architektur produziert.

## Drei Entscheidungs-Typen, drei Tests, eine Klassifikation

Jeder Entscheidungspunkt fällt in genau einen von drei Typen. Die Klassifikation ist binär. Mehrdeutigkeit deutet auf einen Audit-Fehler hin, nicht auf einen Spezialfall.

**Typ H - der Mensch entscheidet.** Empathie, individuelles Ermessen, rechtliches Risiko bei Automatisierung, Mitbestimmungsmandat des Betriebsrats oder ethische Sensibilität. Testfrage: "Würden zwei verschiedene erfahrene Fachleute denselben Fall zuverlässig identisch entscheiden?" Falls nein - Typ H. Der Mensch bleibt dort, wo Recht es verlangt. Nicht weil er es besser kann.

**Typ R - regelbasiert, deterministisch.** Die Regel existiert schriftlich (Gesetz, Tarifvertrag, Betriebsvereinbarung, dokumentierte Verfahrensanweisung). Die Eingabedaten sind strukturiert. Das Ergebnis ist deterministisch. Ausnahmen sind selbst regelbasiert - oder sie sind separate Typ-H-Entscheidungspunkte. Testfrage: "Könnte ich diese Entscheidung als Tabellenkalkulations-Formel schreiben?" Falls ja - Typ R.

**Typ A - KI-geeignet, probabilistisch mit Grenzen.** Die Aufgabe ist Klassifikation, Extraktion oder Abgleich - nicht Erstellung, Bewertung oder Beurteilung. Die Ergebnismenge ist bekannt und endlich. Das Ergebnis ist überprüfbar. Ein Konfidenzschwellenwert ist setzbar; unsichere Fälle eskalieren. Testfrage: "Interpretiere ich Information gegen bekannte Kategorien, oder beurteile ich eine einzigartige Situation?" Falls Kategorien - Typ A.

Die Krankmeldungs-Tabelle ergibt nach diesen Tests:

| # | Entscheidungspunkt | Typ | Begründung |
|---|-------------------|-----|-----------|
| 1 | Dokumentenklassifikation | A | Unstrukturierte Eingabe, klassifiziert in bekannte Kategorien, konfidenz-bewertbar |
| 2 | Vollständigkeitsprüfung | A | Feldextraktion mit bekannten Pflichtfeldern, überprüfbar |
| 3 | Mitarbeiteridentifikation | A | Namensabgleich mit Fuzzy Matching, konfidenz-bewertbar |
| 4 | Gesellschaftszuordnung | R | Personalnummer → Gesellschaft, deterministische Lookup-Tabelle |
| 5 | Tarifvertrags-Lookup | R | Gesellschaft + Mitarbeiterkategorie → Tarifvertrag, deterministisch |
| 6 | Lohnfortzahlungsanspruch | R | Startdatum + Abwesenheitshistorie + § 3 EFZG, reine Berechnung |
| 7 | Dauerbewertung | R | Kalenderberechnung |
| 8 | Mustererkennung | R | Schwellenwert-Berechnung (Reaktion auf Schwelle ist eigener H-Punkt) |
| 9 | Payroll-Auswirkung | R | Abwesenheitstyp + Vergütungsregeln |
| 10 | Systemaktualisierung | R | Ausführungsschritt aus 4 - 9 |
| 11 | Benachrichtigungs-Routing | R | Routing-Regeln aus Gesellschaft, Typ, Schwellenwert |
| 12 | Folgeaktion-Planung | R | Regelbasiert (Gespräch selbst ist H, separater Workflow) |

Acht Typ R, drei Typ A, kein Typ H. Die Folge-Aktionen, die menschliches Ermessen erfordern (BEM-Gespräch, Wiedereingliederungsplanung) sind separate Workflows mit eigener Klassifikation - sie liegen ausserhalb der Krankmeldungsverarbeitung.

## Der Score sagt nicht "ob", sondern "wo der Mensch bleibt"

Aus der Klassifikation ergibt sich ein einfacher Quotient: (Typ R + Typ A) ÷ Gesamtzahl × 100. Die Krankmeldung kommt auf 91,7 %. Das ist hoch. Es heisst nicht, dass 91,7 % "weniger Mensch" gebraucht wird. Es heisst, dass 91,7 % der Einzelentscheidungen architektonisch übernommen werden können - während die menschliche Aufsicht sich auf das konzentriert, wofür Recht und Empathie sie verlangen.

Die Score-Schwellen sind weniger Skala als Deployment-Logik:

| Score | Was er sagt | Was zu tun ist |
|-------|-------------|----------------|
| > 80 % | Hohe Agent Readiness | Sofort umsetzbar. Governance fokussiert sich auf die wenigen H-Übergaben. |
| 60 - 80 % | Moderate Readiness | Phasenweise. R und A zuerst, H bleibt manuell. Spürbare Human-in-the-Loop-Last. |
| 40 - 60 % | Gemischte Readiness | Nur regelbasierte Teilprozesse automatisieren. Voller Agent rechnet sich noch nicht. |
| < 40 % | Niedrige Readiness | Nicht empfohlen. Erst Prozessdokumentation und Standardisierung. |

Typische Scores nach HR-Domäne: Payroll & Compensation 85 - 95 %, Zeiterfassung 80 - 90 %, Belegverarbeitung 75 - 85 %, Onboarding-Administration 60 - 75 %, Benefits-Einschreibung 65 - 80 %, Recruiting-Screening 40 - 55 %, Performance Management 20 - 35 %, Employee Relations 15 - 30 %. Recruiting und Performance fallen ab nicht weil sie technisch unmöglich sind, sondern weil sie [Hochrisiko-Systeme nach Annex III des EU AI Act](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32024R1689#anx_3) sind und die menschliche Aufsicht mehr Gewicht bekommt.

## Ein Audit-Ergebnis, vier Stakeholder

Pro Entscheidungspunkt entsteht ein strukturierter Datensatz: ID und Beschreibung, Klassifikation mit Begründung, Regelquelle (für R) mit Version und Geltungszeitraum, Konfidenzschwellenwert (für A), Eskalationspfad mit Frist, Audit-Trail-Spezifikation und Anfechtungspfad. Dieser Datensatz hat vier Empfänger:

Das **Engineering-Team** liest die Klassifikation als Architektur-Spec. Wo R steht, kommt die Rules Engine zum Einsatz; wo A, ein Modellaufruf mit Confidence-Capture; wo H, eine Aufgabe in der Human-Queue. Der Datensatz spezifiziert direkt den [Decision Layer](/de/magazin/decision-layer-erklaert/) - die Schicht zwischen Agent und Zielsystem, die regelbasierte und KI-basierte Entscheidungen orchestriert, das Audit-Trail erzeugt und Eskalationen routet.

Der **Betriebsrat** liest dieselben Daten als Mitbestimmungsvorlage. Er sieht, welche Entscheidungen automatisiert werden, mit welcher Begründung, mit welcher Eskalation. Eine Rahmen-Betriebsvereinbarung kann direkt aus dem Audit abgeleitet werden, oft schneller als domänenspezifische Einzelvereinbarungen.

Der **Wirtschaftsprüfer** liest die Regelversionen und Audit-Trail-Spezifikationen als Revisionssicherheit. Welche Regel wurde wann angewandt, welche Daten lagen zugrunde, wer hat entschieden. Die Antwort steht im Audit-Datensatz, nicht in einem separaten Compliance-Dokument.

Die **Datenschutzbehörde** liest dieselben Daten als EU-AI-Act- und DSGVO-Dokumentation. [Art. 11 (Technische Dokumentation)](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32024R1689#art_11), [Art. 12 (Aufzeichnungspflichten)](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32024R1689#art_12), [Art. 86 (Recht auf Erläuterung)](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32024R1689#art_86) und [Art. 22 DSGVO](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32016R0679#art_22) verlangen genau diese Informationen.

Vier Funktionen aus einem Dokument. Das Audit erzeugt sie nicht als Nebenprodukt - es ist primär darauf konstruiert.

## Anfechtbarkeit ist Architektur, nicht Compliance-Anhang

Eine automatisierte Entscheidung über einen Menschen ist unter dem EU AI Act und der DSGVO nur dann zulässig, wenn die betroffene Person sie anfechten kann. Anfechtbarkeit ist keine Pflicht, die nachträglich angeflanscht wird - sie ist eine Architektur-Anforderung, die ab dem ersten Audit mitgeplant wird.

Pro Entscheidungspunkt liefert das Audit vier Antworten, die zusammen Anfechtbarkeit ermöglichen. Welche Regel oder welches Modell hat in welcher Version entschieden? Ohne Versionierung ist die spätere Reproduktion unmöglich. Welche Daten lagen der Entscheidung zugrunde - die exakten, zum Zeitpunkt der Entscheidung gültigen, nicht die heutigen? Wer hat entschieden - Mensch, Regelwerk oder KI - und mit welcher Konfidenz? Wie kann die Person Einspruch einlegen - mit konkreter Adresse, konkreter Frist, konkreter nächster Instanz?

Eine Konsequenz der Architektur: Der Agent selbst trifft keine "Entscheidungen" im rechtlichen Sinne. Er führt Operationen aus, die der Decision Layer freigegeben hat. Das ist nicht semantische Spitzfindigkeit. Es ist die Grundlage dafür, dass Entscheidungen prüfbar bleiben, wenn das KI-Modell ausgetauscht wird, der Anbieter wechselt oder ein Fehler im Modell entdeckt wird.

Die Hochrisiko-Klassifikation des EU AI Act trifft viele HR-Workflows direkt: Recruiting-Screening, Performance Management, Beförderungs- und Versetzungsentscheidungen, Schicht-Routing wenn es Personalvorteile beeinflusst (Annex III Nr. 4 lit. a und b). [Art. 26 Abs. 7](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32024R1689#art_26) verpflichtet zusätzlich, Arbeitnehmervertretungen und betroffene Arbeitnehmer **vor** der Inbetriebnahme zu informieren - nicht danach. Das Audit muss daher pro Workflow zusätzlich beantworten: Fällt dieser Workflow unter Annex III? Ja → die Pflichten aus Art. 11, Art. 14, Art. 15 und Art. 26 treten hinzu, und die Informationspflicht ist Voraussetzung für Inbetriebnahme.

Für Organisationen ausserhalb der EU: Die Anforderungen, die der EU AI Act explizit auflistet, sind in fast jedem Rechtssystem als Auslegung allgemeiner Sorgfaltspflichten bereits durchsetzbar - nur ohne klare Pflichtenliste. [Wer den Decision Layer EU-AI-Act-konform baut](/de/magazin/eu-ai-act-gilt-weltweit/), erfüllt damit auch das, was kalifornische, brasilianische und britische Datenschutzbehörden im Prüfungsfall verlangen.

## Vier Klassifikationsfehler verzerren jedes Audit

**Eine Regel mit ermessensbedürftigen Ausnahmen wird als Typ R klassifiziert.** "Überstunden zu 150 %" klingt regelbasiert. Aber: Feiertag mit 200 %? Schicht über Mitternacht in Feiertag? Individualvertrag, der den Tarifvertrag überlagert? Wenn Ausnahmen Ermessen verlangen, ist der Ausnahmepfad Typ H - auch wenn der Standardfall Typ R ist. Saubere Lösung: Standardfall als R, separater Entscheidungspunkt für die Ausnahmebehandlung als H oder A.

**Ein KI-Ergebnis ohne Verifizierbarkeit wird als Typ A klassifiziert.** "Die KI bewertet, ob der Kandidat kulturell passt." Das ist nicht Typ A - es gibt keine überprüfbare richtige Antwort. Kulturelle Passung ist subjektiv. Typ A erfordert, dass das Ergebnis prüfbar ist: "Die KI hat dieses Dokument als Krankmeldung klassifiziert" können zwei Menschen am gleichen Dokument validieren. Subjektive Bewertungen sind Typ H - immer.

**Die Auslöser-Entscheidung wird mit der Folge-Aktion verwechselt.** "Mustererkennung löst BEM-Prozess aus" - die Erkennung ist Typ R (Schwellenwert), aber der BEM-Prozess enthält Typ-H-Entscheidungen (Wiedereingliederungsplanung). Das Audit muss den Auslöser vom ausgelösten Workflow trennen.

**Implizite Entscheidungen werden ignoriert.** "Wir prüfen die Krankmeldung" klingt nach einem Schritt. Es enthält mindestens drei Entscheidungen: gültiges Dokument, vollständig, passt zum Mitarbeiter. Das Audit muss zerlegen, bis jeder Punkt genau eine Frage und eine Klassifikation hat.

## Was diese Methodik nicht löst

Das Audit liefert Agent Readiness auf Entscheidungspunkt-Ebene und die Decision-Layer-Spezifikation. Es liefert nicht: die Sequenzierung über Workflows hinweg (das hängt von Transaktionsvolumen, Governance-Komplexität und organisatorischer Bereitschaft ab; siehe die [H1-H4-Logik im HR-Agent-Katalog](/de/hr-agent-katalog/#sequencing-matrix)), die Technologieauswahl, den organisatorischen Wandel oder die Verhandlungsstrategie mit dem Betriebsrat. Auch die konkrete Implementierung des Decision Layers - Rules Engine, Confidence Capture, Anfechtungs-Endpunkt - ist ein eigenes Thema.

Das Audit liefert die Faktengrundlage. Strategie und Implementierung bauen darauf auf. Wer mit Strategie anfängt und sich die Faktengrundlage später ansieht, baut die Pyramide auf der Spitze.

## Weiterführende Artikel

- [Der EU AI Act gilt weltweit](/de/magazin/eu-ai-act-gilt-weltweit/) - warum die Anfechtbarkeitspflicht nicht erst mit dem August-2026-Termin entsteht
- [Drei Arten von Entscheidungen: Wann der Mensch, wann die KI](/de/magazin/drei-arten-von-entscheidungen/) - die konzeptionelle Grundlage der H/R/A-Klassifikation
- [Decision Layer als Architektur-Pattern](/de/magazin/decision-layer-erklaert/) - wie die Klassifikation in eine ausführbare Schicht überführt wird
- [EU AI Act und HR: Hochrisiko-Klassifikation](/de/magazin/eu-ai-act-hr-hochrisiko/) - welche HR-Workflows unter Annex III fallen

--- Decision Layer Methodologie ---
> Wie Gosign Agenten-Entscheidungen klassifiziert, Einsparungen berechnet und Quellen verifiziert - transparent und nachvollziehbar.

## Was ist der Decision Layer?

Der [Decision Layer](/de/decision-layer/) ist die Governance-Schicht zwischen KI-Agent und Zielsystem. Jede Entscheidung die ein Agent trifft oder vorbereitet wird als Entscheidungsakt dokumentiert: welche Regel in welcher Version wurde angewandt, welche Daten lagen zugrunde, wer (Mensch, Regelwerk oder KI) hat entschieden - und wie kann die betroffene Person Einspruch einlegen. Dieser Entscheidungsakt pro Mikroentscheidung ist die Architektur-Antwort auf das Recht auf Erläuterung der einzelnen Entscheidung nach Art. 86 EU AI Act.

Diese Seite erklärt die Methodik hinter den Zahlen die auf jeder Agent-Detailseite stehen.

## Decider-Klassifikation: R / A / H

Jeder Entscheidungsschritt wird genau einem von drei Decider-Typen zugeordnet:

```
R  Regelwerk     Deterministisch. Input rein, Output raus.
                  Kein Modell, kein Spielraum, kein Ermessen.
                  Beispiel: Berechtigungsmatrix, Fristenprüfung.

A  KI-Agent      Modellbasiert mit Confidence-Schwelle.
                  Ergebnis ist probabilistisch. Bei Confidence
                  unter Schwellenwert: Fallback auf R oder H.
                  Beispiel: Intent-Erkennung, Anomalie-Detektion.

H  Mensch        Explizit zugewiesen. Der Agent bereitet vor,
                  der Mensch entscheidet. Dokumentiert in der
                  Entscheidungsakte.
                  Beispiel: Kündigungsfreigabe, Härtefall-Beurteilung.
```

Die Abgrenzung basiert auf zwei Kriterien:

1. **Determinismus**: Ist das Ergebnis bei gleichem Input immer identisch? Ja = R. Nein (weil Modell) = A. Nein (weil Ermessen) = H.
2. **Verantwortungs-Zuordnung**: Wer haftet für das Ergebnis? Regelwerk (konfiguriert von HR/Finance) = R. Modell (trainiert, mit Audit-Trail) = A. Natürliche Person (namentlich) = H.

### Framework-Verortung

Die R/A/H-Klassifikation steht nicht isoliert. Sie bildet sich auf etablierte Governance-Taxonomien ab:

| Gosign R/A/H | Human-in-the-Loop-Taxonomie | EU AI Act Art. 14 | SAE-Level-Analogie |
|---|---|---|---|
| R (Regelwerk) | Human-out-of-the-Loop | Kein Human Oversight erforderlich | Level 4-5 (vollautomatisch) |
| A (KI-Agent) | Human-on-the-Loop | Human Oversight bei Hochrisiko (Art. 14) | Level 2-3 (assistiert/bedingt) |
| H (Mensch) | Human-in-the-Loop | Mensch als Entscheider | Level 0-1 (manuell/assistiert) |

Die SAE-Level-Analogie (aus dem Automotive-Bereich, SAE J3016) dient der intuitiven Einordnung, nicht der direkten Übertragung. Im Automotive-Kontext bezieht sich das Level auf Fahrautomatisierung, hier auf Entscheidungsautomatisierung in HR- und Finance-Prozessen.

## Wie wir Entscheidungsschritte zählen

Ein Entscheidungsschritt ist ein Punkt im Prozess an dem der Agent eine Weichenstellung vornimmt. Nicht jede Datenoperation ist ein Schritt - nur Punkte an denen das Ergebnis je nach Input unterschiedlich ausfallen kann.

Kriterien für einen Entscheidungsschritt:
- **Input variiert**: Nicht jeder Fall durchläuft denselben Pfad
- **Output hat Konsequenz**: Das Ergebnis beeinflusst den weiteren Prozess oder ein Zielsystem
- **Decider ist zuordenbar**: Es ist klar ob R, A oder H entscheidet

Beispiel: Beim Employee Self-Service Agent sind 6 Entscheidungsschritte identifiziert - von der Intent-Erkennung (A) über die Berechtigungsprüfung (R) bis zur Eskalation an die Fachstelle (R). Ein simpler Datenbank-Lookup ("Resturlaub abrufen") ist kein Entscheidungsschritt.

## Score-Berechnung

Jeder Agent wird in fünf Dimensionen bewertet:

| Score | Was er misst | Skala |
|---|---|---|
| **Readiness** | Wie bereit ist eine typische Organisation für diesen Agent? | 0-100 |
| **Governance** | Wie hoch ist der regulatorische Aufwand (EU AI Act, Betriebsrat, DSGVO)? | 0-100 (höher = aufwändiger) |
| **Economic** | Wie stark ist der wirtschaftliche Hebel (ROI, FTE-Ersparnis)? | 0-100 |
| **Lighthouse** | Wie stark ist die Signalwirkung nach innen und außen? | 0-100 |
| **Complexity** | Wie komplex ist die technische Implementierung? | 0-100 (höher = komplexer) |

Jeder Score wird als Range [n, n+7] angegeben - die Spannweite reflektiert die Varianz zwischen Branchen und Unternehmensgrößen. Der untere Wert ist das konservative Szenario (Mittelstand ohne Vorarbeit), der obere das optimistische (Enterprise mit bestehender Infrastruktur).

Die Scores basieren auf einer Kombination aus:
- **Branchenvergleich**: Wie vergleichbar sind die Prozesse zwischen Unternehmen? (höhere Standardisierung = höherer Readiness-Score)
- **Regulatorische Analyse**: EU AI Act Annex III, DSGVO Art. 22, BetrVG § 87 Abs. 1 Nr. 6 (Governance-Score)
- **Benchmark-Daten**: Externe Studien zu Automatisierungspotenzialen (Economic-Score)
- **Projekt-Erfahrung**: Gosign Decision Layer Assessments aus dokumentierten Kundenprojekten

## Einsparungs-Ranges im Impact-Statement

Jeder Agent hat ein Impact-Statement (pyramidOpener.impact) das eine quantitative Aussage zum Nutzen macht. Diese Aussagen fallen in drei Quellen-Kategorien:

### CAT-EXT - Externe Primärquelle

Zahl stammt aus einer verifizierten Industriestudie oder einem Benchmark-Report. Publisher, Titel, Jahr und URL sind im CITATION-CATALOG dokumentiert. Die Zahl wurde gegen die Primärquelle geprüft (WebFetch-Verifikation der URL + inhaltlicher Abgleich).

Beispiel: *"Laut Ardent Partners State of ePayables 2024 sinken die Kosten pro Rechnung von 12,88 auf 2,78 USD"* - Ardent Partners ist der Publisher, die Zahlen stehen im Report.

### CAT-LEGAL - Gesetzestext oder offizielle Statistik

Zahl stammt aus einem Gesetzestext, einer amtlichen Statistik oder einem Gerichtsurteil. URL verweist auf die offizielle Quelle (gesetze-im-internet.de, eur-lex.europa.eu, destatis.de).

Beispiel: *"EU AI Act Annex III Hochrisiko-System, Frist 2. August 2026 (Verschiebung auf 2. Dezember 2027 vorläufig geeinigt)"* - Verordnung (EU) 2024/1689.

### CAT-INT - Gosign Decision Layer Assessment

Zahl basiert auf dokumentierten Kundenprojekten. Typische Kennzahlen: Durchlaufzeiten (vorher/nachher), Auto-Match-Quoten, Fehlerreduktionen. Diese Zahlen sind Medianwerte aus mindestens 3 vergleichbaren Projekten im Zeitraum 2024-2026.

Wenn eine Impact-Zahl als CAT-INT klassifiziert ist, bedeutet das: Die Zahl ist eine Gosign-Erfahrung, nicht ein externer Benchmark. Sie ist belastbar im Kontext unserer Projektdaten, aber nicht extern unabhängig verifiziert.

## Quellen-Verifikation

Jede externe Quelle im CITATION-CATALOG wurde nach folgendem Prozess verifiziert:

1. **URL-Check**: Die Quellen-URL antwortet mit HTTP 200 (oder Redirect zu einer Landing-Page)
2. **Zahlen-Abgleich**: Die im Impact-Statement genannte Zahl steht tatsächlich in der Quelle (nicht nur "in der Nähe" oder "sinngemäß")
3. **Kontext-Prüfung**: Die Zahl wird im gleichen Kontext verwendet wie in der Quelle (z.B. "Value Erosion" nicht als "Management-Aufwand" umgedeutet)

Wenn eine Zahl diesen Dreifach-Check nicht besteht, wird sie entweder:
- Auf die korrekte Zahl aus der Quelle korrigiert
- Auf CAT-INT umklassifiziert (wenn die Quelle die Zahl nicht belegt)
- Aus dem Impact-Statement entfernt (wenn weder extern noch intern belegbar)

## Strukturierte Daten für LLMs

Jede Agent-Detailseite enthält ein JSON-LD-Schema (Schema.org SoftwareApplication) mit:

- **R/A/H-Verteilung** als `additionalProperty` (rulesEngineShare, aiAgentShare, humanDecisionShare in Prozent)
- **Anzahl Entscheidungsschritte** (totalDecisionSteps)
- **EU AI Act Hochrisiko-Flag** (euAiActHighRisk: true/false)
- **Impact-Statement** als Freitext-Property
- **citation[]** mit aufgelösten Quellen-URLs aus dem CITATION-CATALOG

LLMs können diese Daten direkt aus dem HTML-Quelltext extrahieren und mit der kanonischen URL der Agent-Seite zitieren.

## Versionierung

| Datum | Änderung |
|---|---|
| 2026-04-16 | Erstveröffentlichung: R/A/H-Klassifikation, Score-Methodik, Quellen-Verifikation, JSON-LD-Schema |

--- Link abgelaufen - Gosign GmbH ---
> Ihr Bestätigungslink für das AI Governance Briefing ist abgelaufen.

<h1>Bestätigungslink abgelaufen</h1>

<p class="text-lg text-gosign-text-light">
Ihr Bestätigungslink für das <strong>AI Governance Briefing</strong> ist leider abgelaufen. Links sind aus Sicherheitsgründen 7 Tage gültig.
</p>

<p>Kein Problem - melden Sie sich einfach erneut an. Sie erhalten sofort eine neue Bestätigungsmail.</p>

--- Newsletter abgemeldet - Gosign GmbH ---
> Sie wurden vom AI Governance Briefing abgemeldet.

<h1>Abmeldung bestätigt</h1>

<p class="text-lg text-gosign-text-light">
Sie wurden erfolgreich vom <strong>AI Governance Briefing</strong> abgemeldet und erhalten keine weiteren E-Mails.
</p>

<p>Falls Sie sich erneut anmelden möchten, können Sie dies jederzeit über unsere Website tun.</p>

<p class="mt-6">
<a href="/de/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Zur Startseite</a>
</p>

--- Newsletter bestätigt - Gosign GmbH ---
> Ihre Anmeldung zum AI Governance Briefing wurde bestätigt.

<h1>Anmeldung bestätigt</h1>

<p class="text-lg text-gosign-text-light">
Vielen Dank - Ihre Anmeldung zum <strong>AI Governance Briefing</strong> ist jetzt aktiv.
</p>

<p>Sie erhalten das Briefing einmal im Monat mit aktuellen Entwicklungen rund um AI Governance, Decision Layer und Enterprise AI-Infrastruktur.</p>

<p class="mt-6">
<a href="/de/magazin/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Zum Magazin</a>
<span class="mx-2 text-gosign-text-light">|</span>
<a href="/de/kontakt/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-medium" target="_blank" rel="noopener noreferrer">Beratungsgespräch buchen</a>
</p>

--- Recruiting Agent - KI im Recruiting mit Decision Layer ---
> Recruiting Agent mit Bias-Monitoring, EU AI Act Compliance und Betriebsrats-Transparenz. Besetzungsdauer reduzieren, ohne Diskriminierungsrisiko.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/de/warum-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Jede Entscheidung nachvollziehbar</p>
</div>
</a>
<a href="/de/warum-gosign/#infrastruktur" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Ihre Infrastruktur</p>
<p class="text-xs text-gosign-text-light">Kein SaaS. Kein Vendor-Lock-in.</p>
</div>
</a>
<a href="/de/warum-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Kein US-Cloud-Risiko</p>
</div>
</a>
</div>
</div>
</div>


<!-- Problem -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Warum dauert Recruiting so lange?</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
90 Tage durchschnittliche Besetzungsdauer. Hunderte Bewerbungen pro Stelle. Jede manuell gesichtet, bewertet, beantwortet. Recruiter verbringen den Großteil ihrer Zeit mit Routinearbeit statt mit Kandidatengesprächen.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Das Problem ist nicht mangelnde Kompetenz. Das Problem ist Volumen: Zu viele Bewerbungen, zu wenige Recruiter, zu viele manuelle Schritte. Und bei jedem manuellen Schritt das Risiko inkonsistenter Bewertung - was wiederum ein Compliance-Risiko ist.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Gleichzeitig steigen die regulatorischen Anforderungen: Der EU AI Act klassifiziert KI im Recruiting als Hochrisiko. Bias-Monitoring ist Pflicht. Und der Betriebsrat hat nach § 99 BetrVG ein Mitbestimmungsrecht bei jeder Einstellung.
</p>
</div>
</section>

<!-- Prozess-Diagramm -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-6">Der Recruiting-Prozess mit Decision Layer</h2>
<img
src="/images/diagrams/recruiting-decision-flow.svg"
alt="Recruiting-Prozess in 5 Phasen: Anforderung (Mensch prüft), Screening (Automatisch), Interview (Mensch entscheidet), Selektion (Mensch entscheidet), Onboarding (Regelwerk). Decision Layer dokumentiert jeden Schritt, Bias-Monitoring, EU AI Act compliant."
class="w-full"
width="1200"
height="400"
loading="lazy"
/>
</div>
</section>

<!-- Micro-Decision-Tabelle -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Wer entscheidet was? Micro-Decisions im Recruiting</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Der <a href="/de/decision-layer/" class="text-gosign-accent-text hover:underline">Decision Layer</a> zerlegt den Recruiting-Prozess in einzelne Entscheidungsschritte. Für jeden Schritt ist vorab definiert: Mensch, Regelwerk oder KI.
</p>
</div>
<div class="mt-8 overflow-x-auto">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-dark/20">
<th class="py-3 pr-4 text-body font-bold text-gosign-dark">Entscheidungsschritt</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Wer entscheidet</th>
<th class="py-3 pl-4 text-body font-bold text-gosign-dark">Warum</th>
</tr>
</thead>
<tbody class="text-body text-gosign-text-light">
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Anforderungsprofil erstellen</td>
<td class="py-3 px-4"><span class="inline-block px-2 py-0.5 text-xs font-bold rounded bg-amber-100 text-amber-800">Mensch prüft</span></td>
<td class="py-3 pl-4">KI erstellt Vorschlag aus Stellenbeschreibung und Abteilungsprofil. Führungskraft prüft und ergänzt.</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Stellenanzeige formulieren</td>
<td class="py-3 px-4"><span class="inline-block px-2 py-0.5 text-xs font-bold rounded bg-blue-100 text-blue-800">Automatisch</span></td>
<td class="py-3 pl-4">Agent generiert Text aus Anforderungsprofil. Bias-Check gegen diskriminierende Formulierungen.</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">CV-Parsing und Datenextraktion</td>
<td class="py-3 px-4"><span class="inline-block px-2 py-0.5 text-xs font-bold rounded bg-blue-100 text-blue-800">Automatisch</span></td>
<td class="py-3 pl-4">Strukturierte Daten aus Lebenslauf extrahieren. Standardfall, hohe Sicherheit.</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Anforderungsabgleich (Screening)</td>
<td class="py-3 px-4"><span class="inline-block px-2 py-0.5 text-xs font-bold rounded bg-emerald-100 text-emerald-800">Regelwerk</span></td>
<td class="py-3 pl-4">Abgleich gegen definierte Must-Have-Kriterien. Regelwerk, nicht KI-Einschätzung.</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Qualitative Bewertung (Shortlist)</td>
<td class="py-3 px-4"><span class="inline-block px-2 py-0.5 text-xs font-bold rounded bg-amber-100 text-amber-800">Mensch prüft</span></td>
<td class="py-3 pl-4">Agent erstellt Shortlist mit Begründung. Recruiter prüft, ergänzt, entscheidet über Einladung.</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Interviewtermine koordinieren</td>
<td class="py-3 px-4"><span class="inline-block px-2 py-0.5 text-xs font-bold rounded bg-blue-100 text-blue-800">Automatisch</span></td>
<td class="py-3 pl-4">Kalenderabgleich, Einladungen, Erinnerungen. Standardprozess.</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Interview führen</td>
<td class="py-3 px-4"><span class="inline-block px-2 py-0.5 text-xs font-bold rounded bg-red-100 text-red-800">Mensch entscheidet</span></td>
<td class="py-3 pl-4">Persönliches Gespräch. Kein automatisierbares Urteil.</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Einstellungsentscheidung</td>
<td class="py-3 px-4"><span class="inline-block px-2 py-0.5 text-xs font-bold rounded bg-red-100 text-red-800">Mensch entscheidet</span></td>
<td class="py-3 pl-4">Personalentscheidung. § 99 BetrVG: BR-Zustimmung erforderlich. Ermessensspielraum.</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Vertragsangebot erstellen</td>
<td class="py-3 px-4"><span class="inline-block px-2 py-0.5 text-xs font-bold rounded bg-emerald-100 text-emerald-800">Regelwerk</span></td>
<td class="py-3 pl-4">Eingruppierung nach Tarifvertrag/Gehaltsband. Deterministische Logik.</td>
</tr>
<tr>
<td class="py-3 pr-4 font-semibold text-gosign-dark">Absage formulieren</td>
<td class="py-3 px-4"><span class="inline-block px-2 py-0.5 text-xs font-bold rounded bg-blue-100 text-blue-800">Automatisch</span></td>
<td class="py-3 pl-4">Standardabsage bei eindeutiger Nichterfüllung der Must-Haves. Grenzfälle werden eskaliert.</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- EU AI Act Hochrisiko -->
<section class="py-section bg-gosign-dark text-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold">Warum KI im Recruiting Hochrisiko ist - und was das bedeutet</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4">
Der EU AI Act stuft KI-Systeme im Recruiting explizit als Hochrisiko ein (Anhang III, Nr. 4). Die Pflichten gelten nach aktuellem Recht ab dem 2. August 2026; das <a href="/de/magazin/eu-ai-act-2026-unternehmen/" class="text-gosign-accent-on-dark underline">Digital-Omnibus-Paket</a> verschiebt diese Frist nach vorläufiger Einigung vom 7. Mai 2026 voraussichtlich auf den 2. Dezember 2027 (formale Verabschiedung ausstehend). Das betrifft jedes Unternehmen das KI für Bewerbungsscreening, Kandidatenbewertung oder Einstellungsentscheidungen einsetzt.
</p>
<div class="mt-8 space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-body-lg font-semibold text-white">Bias-Monitoring ist Pflicht</p>
<p class="text-body text-gosign-text-on-dark/70 mt-1">Werden bestimmte Gruppen systematisch anders bewertet? Der Decision Layer überwacht alle Screening-Entscheidungen statistisch und meldet Auffälligkeiten.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-body-lg font-semibold text-white">Human Oversight erzwungen</p>
<p class="text-body text-gosign-text-on-dark/70 mt-1">Einstellungsentscheidungen können nicht vollautomatisiert werden. Der Decision Layer erzwingt Human-in-the-Loop bei allen Personalentscheidungen technisch.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-body-lg font-semibold text-white">Transparenz für Bewerber</p>
<p class="text-body text-gosign-text-on-dark/70 mt-1">Bewerber müssen informiert werden, dass KI eingesetzt wird. Der Audit Trail dokumentiert für jeden Bewerber den vollständigen Entscheidungspfad.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-body-lg font-semibold text-white">Audit Trail pro Entscheidung</p>
<p class="text-body text-gosign-text-on-dark/70 mt-1">Jede Screening-Entscheidung: Eingangsdaten, angewandtes Regelwerk, Konfidenzwert, Ergebnis, Zeitstempel. Nicht nachträglich erstellt, sondern automatisch erzeugt.</p>
</div>
</div>
<p class="text-body text-gosign-text-on-dark/60 mt-8">
→ <a href="/de/governance/eu-ai-act/" class="text-gosign-accent-on-dark hover:underline">EU AI Act Compliance im Detail</a>
</p>
</div>
</div>
</section>

<!-- Betriebsrat -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Was sagt der Betriebsrat zu KI im Recruiting?</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Der Betriebsrat hat bei Einstellungen ein Mitbestimmungsrecht (§ 99 BetrVG). Das bedeutet: Jede Einstellung braucht die Zustimmung des Betriebsrats. Wenn KI an der Vorauswahl beteiligt ist, will der Betriebsrat wissen: Nach welchen Kriterien wird gefiltert? Wer hat die Kriterien definiert? Wer trägt die Verantwortung?
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Der Decision Layer gibt dem Betriebsrat genau diese Transparenz:
</p>
<div class="mt-6 space-y-4">
<div class="flex items-start gap-3">
<span class="flex-shrink-0 w-6 h-6 rounded-full bg-gosign-accent text-white flex items-center justify-center text-sm font-bold">✓</span>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Kriterien sind einsehbar:</strong> Die Screening-Regeln sind versionierte, dokumentierte Regelwerke - keine Blackbox.</p>
</div>
<div class="flex items-start gap-3">
<span class="flex-shrink-0 w-6 h-6 rounded-full bg-gosign-accent text-white flex items-center justify-center text-sm font-bold">✓</span>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Einstellungsentscheidungen bleiben beim Menschen:</strong> Der Agent schlägt vor, der Mensch entscheidet. Technisch erzwungen, nicht optional.</p>
</div>
<div class="flex items-start gap-3">
<span class="flex-shrink-0 w-6 h-6 rounded-full bg-gosign-accent text-white flex items-center justify-center text-sm font-bold">✓</span>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Audit Trail für jede Bewerbung:</strong> Welches Kriterium hat zur Einladung oder Absage geführt? Nachvollziehbar im Auditor Portal.</p>
</div>
<div class="flex items-start gap-3">
<span class="flex-shrink-0 w-6 h-6 rounded-full bg-gosign-accent text-white flex items-center justify-center text-sm font-bold">✓</span>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Bias-Report für den Betriebsrat:</strong> Statistische Auswertung über alle Recruiting-Entscheidungen. Werden bestimmte Gruppen systematisch anders behandelt?</p>
</div>
</div>
<p class="text-body text-gosign-text-light mt-6">
→ <a href="/de/governance/mitbestimmung/" class="text-gosign-accent-text hover:underline">Mitbestimmung und AI Agents im Detail</a>
</p>
</div>
</div>
</section>

<!-- Potenzial -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Was bringt ein Recruiting Agent?</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Branchenstudien beziffern das Automatisierungspotenzial im Recruiting auf 70-75%. Das heißt nicht: 75% weniger Recruiter. Es heißt: 75% der Prozessschritte können durch Agents beschleunigt werden - CV-Parsing, Anforderungsabgleich, Terminierung, Standardkommunikation.
</p>
<div class="mt-6 space-y-4">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark">Besetzungsdauer reduzieren</p>
<p class="text-body-lg text-gosign-text-light mt-2">Von 90 auf 30-45 Tage. Nicht durch schnellere Entscheidungen, sondern durch Eliminierung von Wartezeiten: Screening in Stunden statt Wochen, automatische Terminkoordination, sofortige Standardkommunikation.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark">Konsistente Bewertung</p>
<p class="text-body-lg text-gosign-text-light mt-2">Jeder Bewerber wird gegen dasselbe Regelwerk bewertet. Unabhängig davon, welcher Recruiter die Stelle betreut oder ob es Montag morgen oder Freitag nachmittag ist.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark">Mehr Zeit für Kandidaten</p>
<p class="text-body-lg text-gosign-text-light mt-2">Recruiter verbringen Zeit mit Gesprächen statt mit Dateneingabe. Die Qualität der Candidate Experience steigt, weil der Mensch sich auf das konzentriert, was nur ein Mensch kann.</p>
</div>
</div>
</div>
</div>
</section>

<!-- Dieser Agent im Katalog -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark">Wann starten? Priorisierung und Governance-Readiness</h2>
<p class="text-body text-gosign-text mt-4">In welchem Quartal sollte dieser Agent starten? Welche Governance-Infrastruktur muss vorher stehen? Welche Agenten sind Voraussetzung? Der HR-Agent-Katalog ordnet diesen Agenten in die Q1-Q4 Sequenzierung ein und zeigt Readiness-Scores, Governance-Komplexität und Abhängigkeiten zu anderen Agenten.</p>
<a href="/de/hr-agent-katalog/candidate-screening-agent/" class="inline-flex items-center gap-2 mt-4 text-body font-semibold text-gosign-accent hover:underline">Sequenzierung und Scores ansehen &rarr;</a>
</div>
</section>

<!-- Vertiefung im Agent Briefing -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">Vertiefung im Agent Briefing (Gosign Magazin)</h2>
<div class="grid md:grid-cols-3 gap-6">
<a href="/de/magazin/eu-ai-act-hr/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<h3 class="text-h3 font-bold text-gosign-dark">EU AI Act und HR</h3>
</a>
<a href="/de/magazin/betriebsrat-ki-mitbestimmung/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<h3 class="text-h3 font-bold text-gosign-dark">Betriebsrat und KI - Mitbestimmung</h3>
</a>
<a href="/de/magazin/agent-governance-hr/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR</p>
<h3 class="text-h3 font-bold text-gosign-dark">Agent Governance für HR</h3>
</a>
</div>
</div>
</section>

<!-- FAQ -->

--- Referenzen Maschinenbau | Websites & Digitalisierung ---
> Gosign-Referenzen im Maschinenbau: B2B-Websites, Produkt-Konfiguratoren, digitale Vertriebstools. Projekte ansehen.

<!-- Gosign im Maschinenbau -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Gosign im Maschinenbau</h2>
<p class="text-body text-gosign-text leading-relaxed">
Gosign entwickelt digitale Lösungen für Maschinenbauunternehmen: B2B-Websites, Produkt-Konfiguratoren, Händlerportale, technische Dokumentations-Plattformen und digitale Vertriebstools. Die Branche stellt besondere Anforderungen: Komplexe Produktdaten, mehrsprachige Kataloge, Integration mit PIM/ERP-Systemen, lange Entscheidungszyklen.
</p>
</div>
</section>

<!-- Was Gosign baut -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Was Gosign für Maschinenbau-Kunden baut</h2>
<ul class="space-y-4">
<li class="flex items-start gap-3">
<span class="flex-shrink-0 mt-1.5 w-2 h-2 bg-gosign-accent rounded-full"></span>
<div>
<span class="font-bold text-gosign-dark">B2B-Websites</span>
<span class="text-body text-gosign-text">: Responsive, performant, mit Produkt-Finder und Kontakt-Routing an den richtigen Vertriebspartner</span>
</div>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 mt-1.5 w-2 h-2 bg-gosign-accent rounded-full"></span>
<div>
<span class="font-bold text-gosign-dark">Produkt-Konfiguratoren</span>
<span class="text-body text-gosign-text">: Interaktive Konfiguratoren, die technische Parameter abfragen und passende Produkte empfehlen</span>
</div>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 mt-1.5 w-2 h-2 bg-gosign-accent rounded-full"></span>
<div>
<span class="font-bold text-gosign-dark">Händlerportale</span>
<span class="text-body text-gosign-text">: Login-geschützte Bereiche für Vertriebspartner: Preislisten, technische Dokumentation, Bestelltools</span>
</div>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 mt-1.5 w-2 h-2 bg-gosign-accent rounded-full"></span>
<div>
<span class="font-bold text-gosign-dark">Mehrsprachige Kataloge</span>
<span class="text-body text-gosign-text">: TYPO3-basierte Produktkataloge mit PIM-Anbindung, automatischer Übersetzung und regionalen Varianten</span>
</div>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 mt-1.5 w-2 h-2 bg-gosign-accent rounded-full"></span>
<div>
<span class="font-bold text-gosign-dark">Digitale Vertriebstools</span>
<span class="text-body text-gosign-text">: iPad-fähige Produktpräsentationen, Offline-Kataloge, Angebotsgeneratoren</span>
</div>
</li>
</ul>
</div>
</section>

<!-- Technologien-Tabelle -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Technologien im Maschinenbau-Umfeld</h2>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Anforderung</th>
<th class="py-3 text-small font-bold text-gosign-dark">Gosign-Lösung</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">CMS</td>
<td class="py-3 text-body text-gosign-text">TYPO3 (Enterprise) oder WordPress (Content-fokussiert)</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">PIM-Integration</td>
<td class="py-3 text-body text-gosign-text">Akeneo, Pimcore, Custom-Anbindung</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">ERP-Anbindung</td>
<td class="py-3 text-body text-gosign-text">SAP, Microsoft Dynamics, Custom API</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Mehrsprachigkeit</td>
<td class="py-3 text-body text-gosign-text">TYPO3 native, bis zu 30+ Sprachen</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Performance</td>
<td class="py-3 text-body text-gosign-text">Cloudflare CDN, Edge Caching, statische Generierung</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Maschinenbau-Projekt besprechen, 30&nbsp;Minuten, kostenlos.</h3>
<p class="text-body text-gosign-text mb-6">Wir analysieren Ihr Projekt, schätzen Aufwand und Zeitrahmen, unverbindlich.</p>
<a
href="/de/kontakt/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Erstgespräch vereinbaren
</a>
<p class="text-small text-gosign-text-light mt-4">25 Jahre Erfahrung · 800+ Extensions · KI-beschleunigte Entwicklung</p>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
Gosign ist eine Hamburger Digitalagentur mit 25 Jahren Erfahrung in Webentwicklung, TYPO3 und KI-Integration.
Wir haben über 800 TYPO3 Extensions analysiert und entwickeln heute mit KI-Unterstützung
bis zu 70&nbsp;% schneller als mit klassischen Methoden. Unsere Kunden sind mittelständische
Unternehmen, Hochschulen und öffentliche Einrichtungen in Deutschland.
</p>
<p class="text-small text-gosign-text-light mt-2">Stand: Februar 2026</p>
</div>
</section>

--- Case Study: Pilot Gruppe - KI-Infrastruktur in Azure ---
> DSGVO-konforme, modell-agnostische KI-Infrastruktur mit Rechtemanagement und Human-in-the-Loop in der Azure-Umgebung der Pilot Gruppe.

<!-- Ausgangslage -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Ausgangslage</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Die Pilot Gruppe benötigte eine KI-Infrastruktur, die auf der bestehenden Microsoft Azure-Umgebung aufsetzt. Zentrale Anforderungen:
</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light">Datenhoheit muss im Unternehmen bleiben</li>
<li class="text-body-lg text-gosign-text-light">Authentifizierung über bestehendes Azure Entra ID (SSO)</li>
<li class="text-body-lg text-gosign-text-light">Abteilungsspezifische Zugriffssteuerung - HR-Daten nur für HR</li>
<li class="text-body-lg text-gosign-text-light">Mehrere KI-Modelle parallel nutzbar</li>
<li class="text-body-lg text-gosign-text-light">DSGVO-konform mit unabhängigem Gutachten vor Livegang</li>
</ul>
</div>
</section>

<!-- Umsetzung -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Umsetzung</h2>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">Multi-Modell-Architektur</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Statt Abhängigkeit von einem einzelnen Anbieter: modell-agnostische Architektur mit Auswahl pro Use Case. Implementierte Modelle: GPT-5.5, Gemini 3.1 Pro, Claude Opus 4.7 und Mistral Small 3.2 für Text/Reasoning, Flux für Bildgenerierung. Mitarbeiter wählen die Modellkombination selbst - je nach Aufgabe. Die modell-agnostische Architektur ermöglichte den nahtlosen Upgrade von GPT-4o auf GPT-5.5 ohne Code-Änderungen am Chat-Interface.
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">Rechtesteuerung über Azure Entra ID</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Bestehende Rechtegruppen in Azure Entra ID wurden direkt mit dem KI-Interface verknüpft. Keine neue Benutzerverwaltung, keine zusätzliche Authentifizierung.
</p>
<p class="text-body-lg text-gosign-text-light mt-2">
Ergebnis: Die Marketing-Abteilung sieht andere KI-Modelle und Agents als die HR-Abteilung. Sensible Daten wie Gehälter und Personaldaten bleiben innerhalb der HR-Rechtegruppe - unsichtbar für andere Abteilungen.
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">Progressive Web App (PWA)</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Das Interface wurde als PWA realisiert - läuft auf Windows und macOS ohne Installation. Tastatur-Shortcuts für Power-User. Drag & Drop für Datei-Upload.
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">DSGVO-Gutachten vor Livegang</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Die gesamte Architektur wurde vor dem Livegang vom Datenschutzbeauftragten der Pilot Gruppe und von Dr. Frank Eickmeier (unverzagt.law) analysiert. Positives DSGVO-Gutachten bestätigt die Konformität.
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">KI-Agenten auf n8n-Plattform</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Auf der in der Pilot-Infrastruktur eingerichteten n8n-Plattform laufen KI-Agenten, die über verschiedene Kanäle erreichbar sind: Interface, Microsoft Teams, weitere Kollaborationskanäle. Human-in-the-Loop ist implementiert: Bei Rückfragen interagieren Agenten gezielt mit den relevanten Fachabteilungen über den jeweiligen Kommunikationskanal.
</p>
</div>
</section>

<!-- Ergebnis -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Ergebnis</h2>
<ul class="mt-6 space-y-3">
<li class="text-body-lg text-gosign-text-light">Alle Daten bleiben in der Azure-Umgebung der Pilot Gruppe - DSGVO-konform</li>
<li class="text-body-lg text-gosign-text-light">Bestehende IT-Infrastruktur und Authentifizierung werden weiterverwendet</li>
<li class="text-body-lg text-gosign-text-light">Modell-agnostisch: neue Modelle integrierbar ohne Architekturänderung</li>
<li class="text-body-lg text-gosign-text-light">Abteilungsspezifische Workspaces mit Role-Based Access Control</li>
<li class="text-body-lg text-gosign-text-light">Mitarbeiter erstellen eigenständig KI-Assistenten und Agents</li>
<li class="text-body-lg text-gosign-text-light">Abteilungsübergreifendes Agent-Sharing durch die IT-Abteilung steuerbar</li>
<li class="text-body-lg text-gosign-text-light">Unabhängiges DSGVO-Gutachten vor Livegang</li>
</ul>
</div>
</section>

<!-- Technologie -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Technologie</h2>
<ul class="mt-6 space-y-2">
<li class="text-body-lg text-gosign-text-light">Microsoft Azure (Kundenumgebung)</li>
<li class="text-body-lg text-gosign-text-light">Azure Entra ID (SSO, RBAC)</li>
<li class="text-body-lg text-gosign-text-light">n8n (Agent-Orchestrierung)</li>
<li class="text-body-lg text-gosign-text-light">Multiple LLMs (GPT-5.5, Gemini 3.1 Pro, Claude Opus 4.7, Mistral Small 3.2, Flux)</li>
<li class="text-body-lg text-gosign-text-light">PWA (Progressive Web App)</li>
</ul>
</div>
</section>

<!-- Gosign-Leistung -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Gosign-Leistung</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Konzeption, Implementierung, Deployment, Schulung, laufender Support. Neben der KI-Infrastruktur hat Gosign eine vollständige Agentenplattform aufgebaut: Mitarbeiter erstellen eigenständig KI-Assistenten und Agents, die IT steuert das abteilungsübergreifende Agent-Sharing. Die IT-Abteilung der Pilot Gruppe betreut die gesamte Plattform mit bestehenden Azure-Kenntnissen - kein neues Tooling nötig.
</p>
</div>
</section>

--- pilot Agenturgruppe: DSGVO-konforme KI-Infrastruktur für 1.000 Mitarbeiter ---
> Wie Deutschlands zweitgrößte inhabergeführte Mediaagentur eine KI-Infrastruktur mit vollständiger EU-Datenresidenz aufgebaut hat.

## Ausgangslage

pilot ist eine der größten unabhängigen und inhabergeführten Agenturgruppen Deutschlands. Mit über 1.000 Mitarbeitern an sieben Standorten betreut pilot Kunden wie Dr. Oetker, OBI, Techniker Krankenkasse und GetYourGuide. Als Mediaagentur verarbeitet pilot täglich große Mengen an Kampagnendaten, Kundendaten und Mediastrategie-Dokumenten.

Die Herausforderung: pilot wollte KI-Werkzeuge unternehmensweit einsetzen - für Recherche, Dokumentenanalyse, Kampagnenplanung und interne Wissensbasis. Die Anforderung des Geschäftsführers für Technology & Operations, Bosse Küllenberg, war eindeutig: Keine Daten dürfen die EU verlassen. Keine Kompromisse bei der DSGVO. Und kein Vendor-Lock-in.

Zu diesem Zeitpunkt boten die meisten KI-Anbieter keine garantierte EU-Datenresidenz an. ChatGPT Enterprise war noch nicht verfügbar, und die verfügbaren Alternativen konnten die Anforderungen einer Mediaagentur mit sensiblen Kundendaten nicht erfüllen.


## Anforderungen

Bosse Küllenberg definierte vier nicht verhandelbare Anforderungen an die KI-Infrastruktur:

Erstens: Vollständige EU-Datenresidenz. Alle Daten - Prompts, Antworten, hochgeladene Dokumente - müssen in der EU bleiben. Keine US-Server, keine transatlantischen Datentransfers, keine Ausnahmen.

Zweitens: Mandantentrennung. pilot betreut Kunden aus unterschiedlichsten Branchen. Daten eines Kunden dürfen unter keinen Umständen in den Kontext eines anderen Kunden gelangen. Das erfordert strikte Datenisolation auf Infrastrukturebene.

Drittens: Modellunabhängigkeit. Die Infrastruktur darf nicht an ein einzelnes LLM gebunden sein. Wenn ein besseres Modell erscheint, muss ein Wechsel ohne Architekturumbau möglich sein.

Viertens: Nachvollziehbarkeit. Für interne Compliance und gegenüber Kunden muss dokumentiert sein, welche Daten verarbeitet werden und welches Modell zum Einsatz kommt.


## Lösung

Gosign implementierte eine [KI-Infrastruktur](/de/leistungen/infrastruktur/) mit folgenden Eigenschaften:

Die Infrastruktur läuft vollständig in einer EU-Region (Germany West Central in Azure). Kein Prompt, kein Dokument, keine Antwort verlässt die EU. Die Datenresidenz ist nicht nur vertraglich zugesichert, sondern architektonisch erzwungen: Es gibt schlicht keinen Pfad, über den Daten die EU verlassen könnten.

Die Mandantentrennung erfolgt auf Infrastrukturebene. Jedes Team arbeitet in einem isolierten Kontext. Hochgeladene Dokumente, Gesprächsverläufe und generierte Inhalte sind strikt getrennt.

Die Architektur ist [modell-agnostisch](/de/leistungen/infrastruktur/). Die Orchestrierungsschicht routet Anfragen an das jeweils optimale Modell - aktuell werden mehrere Modelle parallel betrieben. Ein Modellwechsel erfordert eine Konfigurationsänderung, keinen Architekturumbau.

Jede Interaktion wird protokolliert: Zeitstempel, verwendetes Modell, Kontext-Zuordnung. Nicht die Inhalte der Prompts werden gespeichert, sondern die Metadaten - ausreichend für Compliance-Nachweise, ohne die Vertraulichkeit zu verletzen.


## Ergebnis

pilot verfügt über eine KI-Infrastruktur, die DSGVO-Konformität nicht als Kompromiss, sondern als Designprinzip behandelt. Über 1.000 Mitarbeiter nutzen die Infrastruktur täglich - für Recherche, Dokumentenanalyse und Kampagnenarbeit.

Die EU-Datenresidenz ist vollständig gewährleistet. Die Mandantentrennung verhindert jede Form von Datenleakage zwischen Kundenteams. Die modell-agnostische Architektur hat bereits zwei Modellwechsel ohne Betriebsunterbrechung ermöglicht.

Bosse Küllenberg hatte von Anfang an eine klare Vorstellung davon, wie KI-Infrastruktur in einem regulierten Umfeld aussehen muss. Gosign hat diese Vorstellung technisch umgesetzt - sauber, auditierbar und zukunftssicher.


## Kennzahlen

| Metrik | Wert |
|--------|------|
| Mitarbeiter mit Zugang | 1.000+ |
| Standorte angebunden | 7 |
| EU-Datenresidenz | 100% |
| Modellwechsel ohne Umbau | 2 durchgeführt |
| Vendor-Lock-in | Keiner |

--- Referenzen - Gosign Enterprise AI Infrastructure ---
> Unternehmen die auf Gosign-Infrastruktur setzen. Case Studies aus Medien, Professional Services und Logistik.

<!-- Referenz 1: pilot -->
<section class="py-16 lg:py-24 bg-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid lg:grid-cols-2 gap-12 items-start">
<div>
<span class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider">Mediaagentur · 1.000 Mitarbeiter</span>
<h2 class="text-h2 font-bold text-gosign-dark mt-2 mb-4">pilot Agenturgruppe</h2>
<p class="text-body text-gosign-text leading-relaxed mb-4">
Deutschlands zweitgrößte inhabergeführte Mediaagentur brauchte eine KI-Infrastruktur, die DSGVO-Konformität nicht als Einschränkung, sondern als Architekturprinzip behandelt - für über 1.000 Mitarbeiter an sieben Standorten.
</p>
<p class="text-body text-gosign-text leading-relaxed mb-6">
Gosign lieferte eine Self-Hosted-Infrastruktur mit vollständiger EU-Datenresidenz, bevor andere Anbieter das Thema überhaupt priorisiert hatten.
</p>
<blockquote class="border-l-4 border-gosign-accent pl-4 italic text-gosign-text mb-6">
<div class="flex items-start gap-4 not-italic mb-3">
<img src="/images/logos/pilot-v2.svg" alt="pilot Agenturgruppe Logo" class="w-24 h-auto opacity-80" width="91" height="45" loading="lazy" />
</div>
„Für mich war von Anfang an klar: Keine Daten außerhalb der EU, keine Kompromisse bei der DSGVO. Gosign hat genau das geliefert - technisch sauber, ohne Wenn und Aber."
<footer class="mt-4 flex items-center gap-4 text-small not-italic text-gosign-dark">
<img src="/images/testimonials/t1.webp" alt="" class="w-14 h-14 rounded-full object-cover ring-2 ring-gray-100" width="56" height="56" loading="lazy" />
<div>
<p class="font-semibold leading-tight"><img src="/images/testimonials/t1-n.svg" alt="" width="140" height="17" style="height:1.15em;width:auto;max-width:none;display:block" loading="lazy" /></p>
<p class="font-normal text-gosign-text-light mt-0.5">Geschäftsführer Technology &amp; Operations, pilot</p>
</div>
</footer>
</blockquote>
<a href="/de/referenzen/pilot-ai/" class="text-gosign-accent-text font-semibold hover:underline">
Case Study lesen →
</a>
</div>
<div class="bg-gosign-light rounded-card p-8">
<dl class="space-y-4 text-body">
<div><dt class="font-semibold text-gosign-dark">Branche</dt><dd class="text-gosign-text">Medien &amp; Kommunikation</dd></div>
<div><dt class="font-semibold text-gosign-dark">Mitarbeiter</dt><dd class="text-gosign-text">1.000+</dd></div>
<div><dt class="font-semibold text-gosign-dark">Standorte</dt><dd class="text-gosign-text">Hamburg, Berlin, München, Stuttgart, Nürnberg, Mainz, Zürich</dd></div>
<div><dt class="font-semibold text-gosign-dark">Schwerpunkt</dt><dd class="text-gosign-text">DSGVO-konforme KI-Infrastruktur, EU-Datenresidenz</dd></div>
<div><dt class="font-semibold text-gosign-dark">Leistungen</dt><dd class="text-gosign-text"><a href="/de/leistungen/infrastruktur/" class="text-gosign-accent-text hover:underline">KI-Infrastruktur</a>, <a href="/de/leistungen/ai-agents/" class="text-gosign-accent-text hover:underline">Agentenplattform</a></dd></div>
</dl>
</div>
</div>
</div>
</section>

<!-- Referenz 2: Roser -->
<section class="py-16 lg:py-24 bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid lg:grid-cols-2 gap-12 items-start">
<div>
<span class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider">Rechtsberatung · Steuerberatung · Wirtschaftsprüfung · 100 Mitarbeiter</span>
<h2 class="text-h2 font-bold text-gosign-dark mt-2 mb-4">Roser Rechtsanwälte Wirtschaftsprüfer Steuerberater</h2>
<p class="text-body text-gosign-text leading-relaxed mb-4">
Eine multidisziplinäre Kanzlei mit 38 Berufsträgern, die andere auf Compliance prüft - und deshalb an die eigene KI-Infrastruktur die höchsten Anforderungen stellt: Berufsgeheimnis nach § 203 StGB, BRAO, StBerG und WPO.
</p>
<p class="text-body text-gosign-text leading-relaxed mb-6">
Gosign lieferte eine Self-Hosted-Infrastruktur mit kryptographischer Mandantentrennung, Decision Layer und lückenlosem Audit-Trail - kammer-prüfungsfähig dokumentiert.
</p>
<blockquote class="border-l-4 border-gosign-accent pl-4 italic text-gosign-text mb-6">
<div class="flex items-start gap-4 not-italic mb-3">
<img src="/images/logos/roser.svg" alt="Roser Rechtsanwälte Wirtschaftsprüfer Steuerberater Logo" class="h-12 w-auto opacity-80" width="947" height="138" loading="lazy" />
</div>
„Als Steuerberater und Wirtschaftsprüfer prüfen wir andere auf Compliance - da müssen unsere eigenen Systeme erst recht einwandfrei sein. Die Governance-Architektur von Gosign erfüllt genau die Standards, die wir bei unseren Mandanten anlegen."
<footer class="mt-4 flex items-center gap-4 text-small not-italic text-gosign-dark">
<img src="/images/testimonials/t2.webp" alt="" class="w-14 h-14 rounded-full object-cover ring-2 ring-gray-100" width="56" height="56" loading="lazy" />
<div>
<p class="font-semibold leading-tight"><img src="/images/testimonials/t2-n.svg" alt="" width="105" height="17" style="height:1.15em;width:auto;max-width:none;display:block" loading="lazy" /></p>
<p class="font-normal text-gosign-text-light mt-0.5">Geschäftsführer, Roser Rechtsanwaltsgesellschaft mbH</p>
</div>
</footer>
</blockquote>
</div>
<div class="bg-white rounded-card p-8">
<dl class="space-y-4 text-body">
<div><dt class="font-semibold text-gosign-dark">Branche</dt><dd class="text-gosign-text">Rechtsberatung, Steuerberatung, Wirtschaftsprüfung</dd></div>
<div><dt class="font-semibold text-gosign-dark">Mitarbeiter</dt><dd class="text-gosign-text">100 (davon 38 Berufsträger)</dd></div>
<div><dt class="font-semibold text-gosign-dark">Standorte</dt><dd class="text-gosign-text">Hamburg, Leipzig</dd></div>
<div><dt class="font-semibold text-gosign-dark">Schwerpunkt</dt><dd class="text-gosign-text">Berufsgeheimnis-konforme KI, Decision Layer, Audit-Trail</dd></div>
<div><dt class="font-semibold text-gosign-dark">Leistungen</dt><dd class="text-gosign-text"><a href="/de/finance-ai-agents/" class="text-gosign-accent-text hover:underline">Finance Agent</a>, <a href="/de/leistungen/infrastruktur/" class="text-gosign-accent-text hover:underline">KI-Infrastruktur</a></dd></div>
</dl>
</div>
</div>
</div>
</section>

<!-- Referenz 3: Anonymisiert (Handelslogistik) -->
<section class="py-16 lg:py-24 bg-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid lg:grid-cols-2 gap-12 items-start">
<div>
<span class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider">Handelslogistik · 500+ Mitarbeiter</span>
<h2 class="text-h2 font-bold text-gosign-dark mt-2 mb-4">Norddeutscher Handelslogistiker</h2>
<p class="text-body text-gosign-text leading-relaxed mb-4">
Ein etablierter Handelslogistiker mit über 500 Mitarbeitern und einer der effizientesten IT- und Logistik-Infrastrukturen seiner Branche setzt auf Gosign als strategischen Beratungspartner für KI-Integration.
</p>
<p class="text-body text-gosign-text leading-relaxed mb-6">
Im Fokus: Strategische Beratung zur Integration von AI-Agenten im Bereich Kundensupport. Die Zusammenarbeit konzentriert sich auf die Frage, wie KI-gestützter Support in eine komplexe, gewachsene IT-Landschaft eingebettet werden kann - ohne den laufenden Betrieb zu gefährden.
</p>
</div>
<div class="bg-gosign-light rounded-card p-8">
<dl class="space-y-4 text-body">
<div><dt class="font-semibold text-gosign-dark">Branche</dt><dd class="text-gosign-text">Handelslogistik</dd></div>
<div><dt class="font-semibold text-gosign-dark">Mitarbeiter</dt><dd class="text-gosign-text">500+</dd></div>
<div><dt class="font-semibold text-gosign-dark">Standort</dt><dd class="text-gosign-text">Norddeutschland</dd></div>
<div><dt class="font-semibold text-gosign-dark">Schwerpunkt</dt><dd class="text-gosign-text">Strategische Beratung, KI-gestützter Kundensupport</dd></div>
<div><dt class="font-semibold text-gosign-dark">Leistungen</dt><dd class="text-gosign-text"><a href="/de/leistungen/ai-agents/" class="text-gosign-accent-text hover:underline">AI-Agenten</a>, <a href="/de/leistungen/infrastruktur/" class="text-gosign-accent-text hover:underline">KI-Infrastruktur</a></dd></div>
</dl>
</div>
</div>
</div>
</section>

--- BV-KI-Drafter: Generator für KI-Betriebsvereinbarungen ---
> Für HR, Personalleitung & Geschäftsführung: in rund 60 Minuten zum verhandlungsreifen Entwurf der KI-Betriebsvereinbarung. Orientiert an BetrVG und EU AI Act. Mit BR-Memo und Verhandlungsleitfaden. Im Browser.

**Für HR, Personalleitung und Geschäftsführung.** Kurz gesagt: Sie geben in sieben Schritten die Eckdaten Ihres Unternehmens und Ihrer KI-Tools ein, der Drafter erzeugt einen fertig formulierten Erstentwurf einer Betriebsvereinbarung **zum KI-Einsatz** - den Sie anschließend mit dem Betriebsrat verhandeln und anwaltlich prüfen lassen.

In vielen Unternehmen wird KI eingeführt, ohne dass der KI-Einsatz per Betriebsvereinbarung geregelt ist. Wer keine BV hat, blockiert die spätere Agent-Einführung; wer eine schlecht formulierte BV hat, blockiert sich selbst.

Der BV-KI-Drafter gibt HR-Verantwortlichen drei aufeinander abgestimmte Dokumente, mit denen die Verhandlung in wenigen Sitzungen abschließbar ist:

- **Die Betriebsvereinbarung selbst**, formuliert nach BetrVG, EU AI Act, DSGVO und AGG. Ausgewogen, nicht maximalistisch. Geeignet als Rahmen-BV mit Anlagen für einzelne Tools.
- **Ein Erläuterungs-Memo für den Betriebsrat**, das die Klauseln in BR-Sprache übersetzt. Hebt die Rechte des BR hervor: Audit, Unterrichtung nach § 90 BetrVG, AGG-Schutz, DSFA-Pflicht.
- **Ein Verhandlungsleitfaden** für die HR-Verhandlungsführung. Bereitet auf typische Bedenken des Betriebsrats vor und liefert sachliche, konsensorientierte Antworten plus Verhandlungs-Korridor pro Klausel - als Grundlage für eine **einvernehmliche, haltbare** Vereinbarung - kein Konfrontationswerkzeug, sondern strukturierte Verhandlungsvorbereitung auf Augenhöhe.

## Sieben Schritte, wenige Minuten Eingabe

1. Branche und Tarifbindung
2. Unternehmensgröße und Struktur des Betriebsrats (lokaler BR, Gesamtbetriebsrat, Konzernbetriebsrat)
3. Bestehende Betriebsvereinbarungen (Freitext: was ist schon geregelt)
4. KI-Tool-Inventar (Multi-Select, plus Freitext für interne Systeme)
5. Risikoklassen der Tools nach EU AI Act (vorausgefüllt aus dem EU AI Act Risk Classifier)
6. Gewünschter Verhandlungs-Härtegrad (BR-konservativ, ausgewogen, arbeitgeberfreundlich)
7. Generierung

Die Ausgabe kommt als drei Dokumente, sofort verwendbar.

## Keine pauschalen Verbote, kein BR-Veto ohne Zeitlimit

Bestehende Mustertexte sind oft so restriktiv formuliert, dass danach faktisch keine KI mehr läuft. Der BV-KI-Drafter ist anders konzipiert:

- **Pauschale Verbote ganzer Anwendungsfelder** sind nicht im Drafter. Statt "Verbot der Leistungskontrolle" wird formuliert "Auswertung nur aggregiert, anonymisiert, mit Zweckbindung".
- **BR-Veto-Klauseln** ohne Zeitlimit werden ersetzt durch Konsultationsfristen mit Einigungsstellen-Eskalation nach § 76 BetrVG.
- **Strikte Inhouse-Server-Vorgaben** werden ersetzt durch Datenkategorie-Positivlisten mit Pseudonymisierungsregeln.
- **AGG-Diskriminierungstests** sind eingebaut, Audit-Rechte des BR sind Standard, DSFA-Pflicht ist abgedeckt.

## Was die KI-Betriebsvereinbarung abdecken muss

Folgende Regelwerke sind im Drafter berücksichtigt:

| Quelle | Was abgedeckt ist |
|---|---|
| BetrVG § 87 Abs. 1 Nr. 6 | Mitbestimmung bei technischen Einrichtungen, die zur Überwachung von Verhalten oder Leistung geeignet sind |
| BetrVG § 90 Abs. 1 Nr. 3 | Unterrichtung und Beratung bei Planung des KI-Einsatzes (seit Betriebsrätemodernisierungsgesetz 2021) |
| BetrVG § 80 Abs. 3 Satz 2 | Bei der Beurteilung von KI gilt die Erforderlichkeit der Sachverständigen-Hinzuziehung kraft Gesetzes als gegeben, soweit der Betriebsrat KI zu beurteilen hat |
| BetrVG § 95 Abs. 2a | Auswahlrichtlinien bei KI-gestützter Personalauswahl |
| EU AI Act Art. 26 Abs. 7 | Unterrichtungspflicht der Arbeitnehmervertreter vor Hochrisiko-Einsatz; Geltungsbeginn der Hochrisiko-Pflichten voraussichtlich Dezember 2027 (Digital-Omnibus-Verschiebung, formale Verabschiedung ausstehend) |
| EU AI Act Art. 26 Abs. 9 | Nutzung der Anbieter-Informationen für die DSFA-Pflicht (verzahnt mit Art. 35 DSGVO) |
| EU AI Act Art. 27 | Grundrechte-Folgenabschätzung (FRIA) |
| DSGVO Art. 35 | Datenschutz-Folgenabschätzung bei HR-KI |
| AGG §§ 7, 1 | Diskriminierungsfreiheit, AGG-Test im KI-System |
| BDSG § 26 | Beschäftigtendatenschutz |

Plus aktuelle Rechtsprechung, u. a. ArbG Hamburg 16.01.2024 (24 BVGa 1/24), LAG Köln 21.05.2021 (9 TaBV 28/20) und LAG Hessen 05.12.2024 (5 TaBV 4/24).

## Jede Klausel mit Control_ID

Der BV-KI-Drafter ist mehr als ein Textgenerator. Jede operative Klausel im Output erhält eine eindeutige Control_ID, etwa BV-AGG-001 oder BV-AUDIT-003. Diese Kennungen sind das Spec-Format für die Decision-Layer-Implementierung.

Der Decision Layer zerlegt jeden Prozess in einzelne Entscheidungsschritte und definiert für jeden Schritt: Mensch, Regelwerk oder KI. Aus jeder BV-Klausel wird eine technische Kontrolle mit Evidence Generator. Der Betriebsrat kann via Auditor-Portal nachvollziehen, ob die technisch implementierte KI die BV einhält.

Mehr dazu im Magazin-Artikel: [Betriebsrat und KI - Mitbestimmung als Architektur-Constraint](/de/magazin/betriebsrat-ki-mitbestimmung/).

## Klare Grenzen

- **Ausschließlich für den KI-Einsatz.** Der Drafter erstellt nur Betriebsvereinbarungen, die den Einsatz von KI-Systemen regeln - **nicht** für andere BV-Themen wie Arbeitszeit/Zeiterfassung, Urlaub oder allgemeinen Datenschutz. Sie brauchen eine BV zu einem anderen Thema? [Sprechen Sie uns an](/de/kontakt/) - wir helfen im Erstgespräch weiter.
- Keine Rechtsberatung. Vor Unterzeichnung ist eine fachanwaltliche Prüfung erforderlich.
- Kein Konzern-BV-Generator. Konzernbetriebsvereinbarungen mit Gesamt-BR und vielen Tochtergesellschaften brauchen ein anderes Werkzeug - [hier ist ein Erstgespräch der bessere Weg](/de/kontakt/).
- Konzipiert für die HR-/Arbeitgeberseite. **Sie sind im Betriebsrat?** Das Tool erstellt Entwürfe aus Arbeitgebersicht; für Ihre Perspektive auf KI-Mitbestimmung empfehlen wir den [Magazin-Beitrag „Betriebsrat und KI"](/de/magazin/betriebsrat-ki-mitbestimmung/).
- Kein Ersatz für das Gespräch mit dem Betriebsrat - aber eine wesentliche Verkürzung der Vorbereitungs- und Verhandlungszeit für beide Seiten.

--- Kostenlose AI Tools - Interaktive Entscheidungshilfen ---
> 8 kostenlose Browser-Tools für AI-Entscheidungen: Board Deck Generator, EU AI Act Risk Classifier, ROI Calculator, TCO Planner und mehr.

<section class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-12">

<p class="text-body text-gosign-text mb-10">Alle Tools laufen direkt im Browser. Keine Registrierung, keine Datenweitergabe, keine versteckten Kosten. Die Ergebnisse basieren auf öffentlichen Frameworks und Benchmarks.</p>

<div class="grid grid-cols-1 md:grid-cols-2 gap-6">

<div class="bg-gosign-dark rounded-card p-6 flex flex-col">
<span class="inline-block text-small font-medium text-gosign-accent-on-dark bg-white/10 rounded-full px-3 py-1 mb-4 w-fit">Kostenlos, im Browser, kein Login</span>
<h2 class="text-h3 font-bold text-white mb-2">Board Deck Generator</h2>
<p class="text-body text-white/70 mb-4 flex-1">9-Slide-Erstbewertung mit ROI-Analyse, Risikobewertung und 3-Szenarien-Vergleich. 7 Input-Felder, fertige Vorstandsvorlage als Ergebnis.</p>
<a href="/de/hr-agent-katalog/" class="inline-flex items-center gap-2 text-gosign-accent-on-dark hover:text-white font-medium">Zum HR-Katalog &rarr;</a>
</div>

<div class="bg-gosign-dark rounded-card p-6 flex flex-col">
<span class="inline-block text-small font-medium text-gosign-accent-on-dark bg-white/10 rounded-full px-3 py-1 mb-4 w-fit">Kostenlos, im Browser, kein Login</span>
<h2 class="text-h3 font-bold text-white mb-2">EU AI Act Risk Classifier</h2>
<p class="text-body text-white/70 mb-4 flex-1">Risikoklassifizierung nach Verordnung (EU) 2024/1689. 7 Fragen, klare Einordnung in Minimal, Limited, High oder Unacceptable Risk.</p>
<a href="/de/governance/eu-ai-act/" class="inline-flex items-center gap-2 text-gosign-accent-on-dark hover:text-white font-medium">Zum Risk Classifier &rarr;</a>
</div>

<div class="bg-gosign-dark rounded-card p-6 flex flex-col">
<span class="inline-block text-small font-medium text-gosign-accent-on-dark bg-white/10 rounded-full px-3 py-1 mb-4 w-fit">Kostenlos, im Browser, kein Login</span>
<h2 class="text-h3 font-bold text-white mb-2">Mitbestimmungs-Check</h2>
<p class="text-body text-white/70 mb-4 flex-1">Muss der Betriebsrat zustimmen? 5 Fragen nach BetrVG mit klarer Handlungsempfehlung. Für HR-Verantwortliche und Projektleiter.</p>
<a href="/de/governance/mitbestimmung/" class="inline-flex items-center gap-2 text-gosign-accent-on-dark hover:text-white font-medium">Zum Mitbestimmungs-Check &rarr;</a>
</div>

<div class="bg-gosign-dark rounded-card p-6 flex flex-col">
<span class="inline-block text-small font-medium text-gosign-accent-on-dark bg-white/10 rounded-full px-3 py-1 mb-4 w-fit">Kostenlos, im Browser, kein Login</span>
<h2 class="text-h3 font-bold text-white mb-2">Agent-Vergleichstool</h2>
<p class="text-body text-white/70 mb-4 flex-1">2-3 AI Agents side-by-side vergleichen. Kosten, Automatisierungsgrad, Governance-Anforderungen und Implementierungsaufwand auf einen Blick.</p>
<a href="/de/hr-agent-katalog/" class="inline-flex items-center gap-2 text-gosign-accent-on-dark hover:text-white font-medium">Zum HR-Katalog &rarr;</a>
</div>

<div class="bg-gosign-dark rounded-card p-6 flex flex-col">
<span class="inline-block text-small font-medium text-gosign-accent-on-dark bg-white/10 rounded-full px-3 py-1 mb-4 w-fit">Kostenlos, im Browser, kein Login</span>
<h2 class="text-h3 font-bold text-white mb-2">Workforce Planner</h2>
<p class="text-body text-white/70 mb-4 flex-1">Personalplanung mit vs. ohne KI-Agenten. Basierend auf SHRM- und Hackett-Benchmarks. Zeigt FTE-Einsparungen und Produktivitätsgewinne.</p>
<a href="/de/hr-agent-katalog/" class="inline-flex items-center gap-2 text-gosign-accent-on-dark hover:text-white font-medium">Zum HR-Katalog &rarr;</a>
</div>

<div class="bg-gosign-dark rounded-card p-6 flex flex-col">
<span class="inline-block text-small font-medium text-gosign-accent-on-dark bg-white/10 rounded-full px-3 py-1 mb-4 w-fit">Kostenlos, im Browser, kein Login</span>
<h2 class="text-h3 font-bold text-white mb-2">TCO Calculator</h2>
<p class="text-body text-white/70 mb-4 flex-1">3-Jahres-Kostenprojektion für KI-Infrastruktur. Build vs. Buy vs. Hybrid. Lizenzkosten, Implementierung, laufender Betrieb.</p>
<a href="/de/leistungen/infrastruktur/" class="inline-flex items-center gap-2 text-gosign-accent-on-dark hover:text-white font-medium">Zum Infrastruktur-Service &rarr;</a>
</div>

<div class="bg-gosign-dark rounded-card p-6 flex flex-col">
<span class="inline-block text-small font-medium text-gosign-accent-on-dark bg-white/10 rounded-full px-3 py-1 mb-4 w-fit">Kostenlos, im Browser, kein Login</span>
<h2 class="text-h3 font-bold text-white mb-2">ROI Quick Calculator</h2>
<p class="text-body text-white/70 mb-4 flex-1">Schnelle Einsparungsberechnung für HR-, Finance- und Travel-Prozesse. Eingabe: Fallvolumen, Zeitaufwand, Stundensatz. Ergebnis: jährliches Einsparpotenzial.</p>
<a href="/de/hr-agent-katalog/" class="inline-flex items-center gap-2 text-gosign-accent-on-dark hover:text-white font-medium">Zum HR-Katalog &rarr;</a>
</div>

<div class="bg-gosign-dark rounded-card p-6 flex flex-col">
<span class="inline-block text-small font-medium text-gosign-accent-on-dark bg-white/10 rounded-full px-3 py-1 mb-4 w-fit">Kostenlos, im Browser, kein Login</span>
<h2 class="text-h3 font-bold text-white mb-2">Readiness Assessment</h2>
<p class="text-body text-white/70 mb-4 flex-1">7-Fragen-Online-Check mit Radar-Chart. Bewerten Sie Ihre Organisation in den Dimensionen Prozessreife, Daten, Governance, IT und Change Management.</p>
<a href="/de/hr-agent-readiness/" class="inline-flex items-center gap-2 text-gosign-accent-on-dark hover:text-white font-medium">Zum Readiness Assessment &rarr;</a>
</div>

</div>
</section>

--- a21glossary TYPO3 - Fachbegriffe | Gosign ---
> Glossar-Extension für TYPO3: Begriffe definieren, automatisch im Content verlinken, als Tooltip anzeigen. SEO-Vorteil durch zusätzliche indexierbare.

## Wer ein Glossar braucht, hat meistens ein SEO-Problem

Fachbegriffe auf einer Website zu erklären klingt nach Service. In Wirklichkeit löst a21glossary ein handfestes technisches Problem: TYPO3-Seiten mit erklärungsbedürftigen Inhalten ranken besser, wenn die Begriffe intern verlinkt, als eigene Seiten indexierbar und per Tooltip sofort zugänglich sind. Die Extension erzeugt aus einer zentralen Begriffsdatenbank automatisch Verlinkungen im Content, ohne dass Redakteure jeden Link manuell setzen müssen.

Für Unternehmen mit Fachportalen, Wissensplattformen oder erklärungsbedürftigen Produkten schafft a21glossary genau die interne Verlinkungsstruktur, die Google als Themenautorität wertet. Statt 50 Begriffe in einer FAQ zu verstecken, entstehen 50 eigenständige, indexierbare Seiten mit Schema-Markup-Potenzial.

## Typische Einsatzszenarien

**Fachportale mit mehr als 100 Begriffen.** Branchenverbände, Hochschulen und Fachverlage pflegen Glossare mit hunderten Einträgen. a21glossary verlinkt jeden Begriff automatisch bei der ersten Erwähnung im Fließtext. Bei einem Kunden mit 340 Glossar-Einträgen stieg die interne Verlinkungsdichte um 28%, messbar über die Google Search Console.

**Produktseiten mit technischem Vokabular.** Maschinenbauer, Chemieunternehmen und Medizintechnik-Hersteller nutzen Fachsprache, die Einkäufer und Entscheider nicht immer kennen. Ein Tooltip mit 2-3 Sätzen Erklärung hält den Leser auf der Seite, statt ihn zu Google zu schicken. Die Verweildauer steigt, die Absprungrate sinkt.

**Mehrsprachige Wissensplattformen.** In Kombination mit TYPO3s Sprachhandling lassen sich Glossare pro Sprache pflegen. Deutsche Begriffe verlinken auf deutsche Erklärungen, englische auf englische. Das funktioniert sauber, solange die Sprachkonfiguration in TYPO3 korrekt aufgesetzt ist.

## Technische Architektur

a21glossary arbeitet als Content-Post-Processor. Nach dem Rendering einer TYPO3-Seite durchsucht die Extension den HTML-Output nach definierten Begriffen und ersetzt sie durch verlinkte Varianten. Die Begriffe selbst werden in einer eigenen Datenbanktabelle gespeichert und über ein Backend-Modul gepflegt.

Die Extension registriert sich über einen Content Object Post User Func Hook im TypoScript-Rendering-Prozess. Das bedeutet: Sie greift erst ein, nachdem TYPO3 den Content vollständig gerendert hat. Dadurch funktioniert sie unabhängig vom eingesetzten Content-Element-Typ, egal ob Textmedia, News oder Custom Content Elements.

Die Tooltip-Darstellung erfolgt über ein kleines JavaScript-Snippet und CSS. Beides ist anpassbar. In modernen TYPO3-Setups empfiehlt sich, das Standard-JavaScript durch eine CSS-only-Lösung zu ersetzen, um die Core Web Vitals nicht zu belasten. Mit dem `title`-Attribut und einem `:hover`-Selektor lassen sich einfache Tooltips ohne eine einzige Zeile JavaScript realisieren.

Die Glossar-Einträge selbst sind über TypoScript konfigurierbar: Welche Seiten sollen durchsucht werden, wie oft darf ein Begriff pro Seite verlinkt werden (empfohlen: einmal), und welche HTML-Bereiche sind ausgeschlossen (Navigation, Footer, andere Glossar-Einträge).

## Häufige Probleme und Lösungen

**Performance-Einbruch bei großen Glossaren.** Ab circa 500 Begriffen kann der Post-Processing-Schritt spürbar werden, besonders auf Seiten mit viel Text. Die Lösung: Caching aktivieren. TYPO3s Seiten-Cache speichert das Ergebnis nach dem ersten Rendering. Nur bei Cache-Leerung wird erneut verarbeitet. Zusätzlich hilft es, die Begriffsliste auf den tatsächlich genutzten Wortschatz zu reduzieren. 200 präzise Begriffe schlagen 800 inklusive Varianten.

**Falsche Verlinkungen in Überschriften und Links.** a21glossary verlinkt standardmäßig überall, auch innerhalb von H2-Tags oder bestehenden Hyperlinks. Das führt zu verschachtelten Links, die HTML-invalid sind. Über die TypoScript-Konfiguration lassen sich Tags ausschließen: `excludeTags = h1,h2,h3,a,script`. Diese Einstellung gehört in jede Erstinstallation.

**Konflikte mit RealURL und Routing.** In älteren TYPO3-Versionen (vor v9) kam es zu Problemen, wenn Glossar-Detailseiten über RealURL geroutet wurden. Mit TYPO3 v10+ und dem nativen Site-Routing existiert dieses Problem nicht mehr. Wer noch RealURL einsetzt, sollte ohnehin migrieren.

## Migration und Versions-Kompatibilität

a21glossary wurde ursprünglich für TYPO3 v4.x entwickelt und über die Jahre aktualisiert. Die letzte aktiv gepflegte Version im TER unterstützt TYPO3 v10 und v11. Für TYPO3 v12 existiert ein Community-Fork auf GitHub, der die Extension auf die neue TCA-Struktur und das geänderte Hook-System portiert. Für TYPO3 v13 ist zum aktuellen Zeitpunkt keine offizielle Version verfügbar.

Die Migration von v11 auf v12 erfordert drei Anpassungen: erstens die Umstellung von `$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']` auf das neue Event-Dispatcher-System, zweitens die Aktualisierung der TCA-Definitionen (Wizard-Konfiguration) und drittens die Anpassung des TypoScript-Setups an die neue Site-Konfiguration.

Wer auf TYPO3 v13 plant, steht vor einer Entscheidung: den Community-Fork weiterentwickeln oder auf eine alternative Lösung umsteigen. Als Alternative bietet sich an, die Glossar-Funktionalität direkt als Custom Content Element mit DataProcessor zu implementieren. Der Aufwand liegt bei circa 2-3 Entwicklertagen, das Ergebnis ist zukunftssicher und unabhängig von Drittanbieter-Pflege. Gosign hat diese Migration bei mehreren Projekten durchgeführt und kann den tatsächlichen Aufwand auf Basis einer Analyse der bestehenden Glossar-Daten realistisch einschätzen.

--- aimeos TYPO3 - E-Commerce Shop | Gosign ---
> aimeos: Professioneller Online-Shop in TYPO3. Setup, Customization & Migration , KI-beschleunigte Entwicklung.

## Wer einen Shop in TYPO3 braucht, kommt an aimeos kaum vorbei

Unternehmen, die bereits eine TYPO3-Website betreiben und E-Commerce ergänzen wollen, stehen vor einer Grundsatzfrage: separates Shopsystem (Shopware, Magento, WooCommerce) mit Schnittstelle zum CMS, oder ein natives E-Commerce-Framework innerhalb von TYPO3? aimeos ist die zweite Option und seit über 10 Jahren das etablierteste TYPO3-Shop-Framework. Über 200.000 Installationen weltweit (Stand: Packagist, 2026), aktive Entwicklung und Support für TYPO3 v12 und v13 sprechen für Stabilität.

Der entscheidende Vorteil: Content und Commerce laufen im selben System. Produktseiten nutzen TYPO3-Content-Elemente, Landingpages können Shop-Komponenten einbetten, Redakteure arbeiten in einer Oberfläche. Bei getrennten Systemen entstehen Synchronisationsprobleme, doppelte Pflege und inkonsistentes Design.

## Typische Einsatzszenarien

**B2B-Shops mit komplexer Preislogik.** Industrieunternehmen mit kundenspezifischen Preisen, Staffelrabatten, Mindestbestellmengen und Freigabe-Workflows. aimeos unterstützt Kundengruppen-Preise, Preis-Plugins und Regelwerke nativ. Ein Chemie-Distributor mit 8.000 Artikeln und 400 Kundengruppen lässt sich damit abbilden, ohne dass jede Preisregel hardcodiert wird.

**Marktplätze und Multi-Vendor-Szenarien.** aimeos kann als Marktplatz-Backend dienen, bei dem mehrere Lieferanten ihre Produkte einstellen. Jeder Vendor verwaltet sein Sortiment, die Plattform übernimmt Checkout, Payment und Versand-Routing. Das Framework unterstützt Multi-Shop-Setups, bei denen verschiedene Storefronts auf denselben Katalog zugreifen, aber unterschiedliche Sortimente und Preise zeigen.

**Internationalisierung ab Tag 1.** Unternehmen mit Websites in 5+ Sprachen und mehreren Währungen profitieren davon, dass aimeos Multi-Language und Multi-Currency nativ mitbringt. Produktnamen, Beschreibungen und SEO-Metadaten lassen sich pro Sprache pflegen. Preise können pro Währung definiert oder automatisch umgerechnet werden.

## Technische Architektur

aimeos basiert auf einer eigenen MVC-Architektur (Manager, Controller, Client), die in TYPO3 als Extension integriert wird. Der Kern ist Framework-agnostisch und läuft auch unter Laravel und Slim. Die TYPO3-Adapter-Schicht stellt sicher, dass aimeos-Plugins als TYPO3-Content-Elemente eingebettet werden.

Der Produktkatalog nutzt eine Baum-Struktur mit beliebig tiefer Verschachtelung. Attribute (Farbe, Grösse, Material) werden als eigene Entitäten verwaltet und über Facettenfilter ausgegeben. Die Suchfunktion basiert standardmässig auf SQL-Volltextsuche, lässt sich aber auf Elasticsearch oder Solr umstellen.

Payment-Integrationen laufen über Service-Provider: Stripe, PayPal, Mollie, Amazon Pay, Klarna und weitere sind als Plugins verfügbar. Jeder Payment-Provider wird über eine einheitliche API angesprochen. Der Checkout-Prozess ist als Step-Pipeline implementiert und um eigene Schritte erweiterbar (z.B. Altersverifikation, B2B-Freigabe).

Caching erfolgt auf mehreren Ebenen: TYPO3 Page Cache für statische Seiten, aimeos-internes Caching für Katalog-Abfragen und optional Varnish oder Cloudflare als Reverse Proxy. Bei Katalogen mit über 100.000 Artikeln ist das Index-Management entscheidend: aimeos erstellt Such- und Preis-Indizes, die bei Produkt-Updates inkrementell aktualisiert werden.

## Häufige Probleme und Lösungen

**Performance-Einbrüche bei grossen Katalogen.** Shops mit 50.000+ Artikeln werden langsam, wenn die Indizes nicht aktuell sind oder der Katalog-Cache deaktiviert wurde. Lösung: `php typo3/sysext/core/bin/typo3 aimeos:jobs` als Cronjob (alle 5 Minuten für Index-Updates, stündlich für Aufräumjobs). Den aimeos-Admin-Cache nach Massenimporten manuell leeren.

**Checkout-Abbrüche durch Payment-Fehler.** Häufige Ursache: veraltete API-Keys oder falsche Webhook-URLs nach Domain-Umzug. Jeder Payment-Provider braucht eine korrekte Notify-URL, über die Zahlungsbestätigungen asynchron eintreffen. Lösung: Webhook-URLs im Payment-Provider-Dashboard nach jedem Umzug prüfen, Testbestellungen im Sandbox-Modus durchführen.

**Konflikte mit TYPO3-Caching.** aimeos-Seiten mit Warenkorb oder Login dürfen nicht im TYPO3 Page Cache landen. Lösung: Die relevanten Seiten als USER_INT markieren oder aimeos im SPA-Modus (AJAX-basiert) betreiben. Seit aimeos 2024.x wird der SPA-Modus als Standard empfohlen.

## Migration und Versions-Kompatibilität

aimeos unterstützt TYPO3 v12 LTS vollständig und TYPO3 v13 seit aimeos 2024.x. Für TYPO3 v11 gibt es Maintenance-Releases, aber keine neuen Features.

Migration von anderen Shop-Systemen ist ein realistisches Szenario. Von Shopware, WooCommerce oder tt_products lassen sich Produkte, Kategorien, Kundenkonten und Bestellhistorie nach aimeos übertragen. Gosign nutzt dafür CSV/XML-Import-Pipelines, bei denen Produktdaten transformiert und in die aimeos-Struktur gemappt werden. Je nach Datenqualität dauert die Migration eines Shops mit 5.000 Produkten zwischen 3 und 10 Tagen.

Wer von tt_products kommt, sollte den Umstieg mit der nächsten TYPO3-Major-Version planen: tt_products wird seit Jahren nur noch minimal gepflegt und hat keine offizielle TYPO3 v13-Kompatibilität.

Ein weiterer Migrationspfad betrifft Unternehmen, die bisher einen separaten Shopware- oder Magento-Shop parallel zur TYPO3-Website betrieben haben. Die Zusammenführung in ein System eliminiert die Schnittstellen-Komplexität: keine REST-API-Synchronisation für Produktdaten, kein doppeltes Template-Management, keine getrennten Deployments. Der Nachteil: aimeos deckt nicht alle Features ab, die ein dediziertes Shopsystem bietet (z.B. Shopware Flow Builder, Magento Page Builder). Die Abwägung lohnt sich aber für Unternehmen, bei denen Content und Commerce gleichwertig sind, nicht nur der Shop zählt, sondern auch Magazin, Wissensdatenbank und Service-Seiten.

Gosign berät projektspezifisch, ob aimeos die richtige Wahl ist oder ob ein separates Shopsystem mit Headless-Anbindung an TYPO3 die bessere Architektur darstellt. Die Entscheidung hängt von drei Faktoren ab: Katalog-Komplexität (Varianten, Konfiguratoren, Bundles), Transaktionsvolumen (unter oder über 1.000 Bestellungen pro Tag) und vorhandene TYPO3-Infrastruktur (Extensions, Templates, Redaktions-Workflows).

Ein aimeos-Setup mit Produktkatalog, Warenkorb, Stripe- und PayPal-Payment, Versandkostenberechnung und Basis-Templates kalkuliert Gosign mit 15 bis 25 Entwicklungstagen. Custom-Themes, komplexe Preislogik oder Marktplatz-Features erhöhen den Aufwand entsprechend. Der laufende Betrieb erfordert regelmässige Updates (aimeos und Payment-Provider-Plugins) sowie Monitoring der Checkout-Performance und Conversion-Rate. Sicherheits-Patches für aimeos und die Payment-Plugins sollten innerhalb von 48 Stunden eingespielt werden, weil Shop-Systeme mit Zahlungsdaten ein bevorzugtes Angriffsziel sind.

--- Amazon Pay TYPO3 - Payment | Gosign ---
> Amazon Pay in TYPO3: Checkout mit Amazon-Konto. API-Integration, Zertifizierung, KI-beschleunigt.

## Amazon Pay reduziert Kaufabbrüche, weil Kunden kein neues Konto anlegen müssen

70 % der deutschen Online-Käufer haben ein Amazon-Konto. Wenn diese Nutzer in einem TYPO3-Shop auf "Kaufen" klicken und ein Registrierungsformular mit 12 Pflichtfeldern sehen, brechen viele ab. Amazon Pay löst dieses Problem: Der Kunde authentifiziert sich mit seinem Amazon-Konto, Lieferadresse und Zahlungsmittel werden automatisch übernommen. Kein Formular, keine Kreditkartennummer, kein neues Passwort. Laut Amazon-eigenen Case Studies steigt die Conversion Rate um 15 bis 30 %, je nach Branche und bestehender Checkout-Qualität.

Für TYPO3-Shop-Betreiber ist die Integration kein Plug-and-Play. Amazon Pay setzt eine API-Anbindung voraus (Login with Amazon, Amazon Pay API v2), eine zertifizierte Implementierung und regelmässige Sicherheitsupdates. Amazon prüft jede Integration vor dem Go-Live.

## Typische Einsatzszenarien

**Mittelständische B2C-Shops mit aimeos.** Online-Shops für Mode, Elektronik, Haushaltswaren, die neben PayPal und Kreditkarte eine dritte Zahlungsart anbieten wollen. Amazon Pay funktioniert besonders gut bei impulsgetriebenen Käufen unter 200 Euro, wo jede Hürde im Checkout direkt Umsatz kostet. Die Integration in aimeos erfolgt über einen eigenen Service-Provider, der in die Payment-Pipeline eingehängt wird.

**Spendenplattformen und Mitgliedsbeiträge.** Vereine und NGOs, die über ihre TYPO3-Website Spenden oder Mitgliedsbeiträge einziehen, profitieren von der niedrigen Einstiegshürde. Der Spender klickt "Mit Amazon bezahlen", bestätigt den Betrag und ist fertig. Kein IBAN-Eintippen, keine Lastschrift-Einrichtung. Für wiederkehrende Zahlungen unterstützt Amazon Pay Recurring Payments.

**Digitale Produkte und Downloads.** Software-Lizenzen, E-Books, Online-Kurse - Produkte ohne physischen Versand profitieren besonders, weil der gesamte Kaufprozess in unter 30 Sekunden abgeschlossen ist. Keine Versandadresse nötig, nur Authentifizierung und Zahlung.

## Technische Architektur

Amazon Pay v2 basiert auf einer REST-API mit JSON-Payloads. Der Ablauf in einem TYPO3-Shop: Der Kunde klickt den Amazon-Pay-Button, wird zu Amazon weitergeleitet (oder ein Popup öffnet sich), loggt sich ein und bestätigt Adresse und Zahlungsmittel. Amazon sendet ein Access Token zurück an den Shop. Der Shop erstellt eine Checkout-Session über die Amazon Pay API, in der Warenkorbdaten und Bestelldetails hinterlegt werden. Nach Bestätigung durch den Kunden wird die Zahlung ausgelöst.

Die Integration in TYPO3 erfordert drei Komponenten: einen API-Client (HTTP-Requests an die Amazon Pay API mit Signatur per RSA-Schlüssel), eine Frontend-Komponente (Amazon Pay Button als JavaScript-Widget) und einen Webhook-Handler für asynchrone Benachrichtigungen (Zahlungsbestätigung, Rückerstattung, Chargeback).

Für aimeos existiert ein Community-Plugin, das die Grundfunktionen abdeckt. Für tt_products oder Custom-Shops ist eine eigene Integration nötig. In beiden Fällen muss der TYPO3-Shop HTTPS verwenden (Pflicht seit Amazon Pay v2), und die Webhook-URL muss von aussen erreichbar sein.

Amazon stellt eine Sandbox-Umgebung bereit, in der alle Zahlungsflüsse ohne echtes Geld getestet werden können. Die Sandbox nutzt eigene API-Endpunkte und Test-Konten.

## Häufige Probleme und Lösungen

**Zertifizierung scheitert beim ersten Anlauf.** Amazon prüft vor dem Go-Live, ob die Integration korrekt funktioniert: Button-Platzierung, Error-Handling bei abgelehnten Zahlungen, Darstellung auf Mobilgeräten, korrekte Stornierung. Häufige Fehler: Der Amazon-Pay-Button erscheint nicht auf der Produktseite (nur im Warenkorb), Fehlermeldungen bei Zahlungsablehnung fehlen oder sind auf Englisch. Lösung: Amazons Integration Checklist vollständig abarbeiten, bevor die Prüfung beantragt wird.

**IPN-Benachrichtigungen (Instant Payment Notifications) gehen verloren.** Amazon sendet Zahlungsbestätigungen asynchron per POST an eine hinterlegte URL. Wenn TYPO3 diese Requests durch Caching, Redirect-Regeln oder fehlende CSRF-Ausnahmen blockiert, bleibt die Bestellung im Status "ausstehend". Lösung: Eine dedizierte eID-Route oder Middleware-Route für den Webhook einrichten, die ausserhalb der normalen TYPO3-Request-Verarbeitung läuft.

**Recurring Payments und Abo-Modelle.** Amazon Pay unterstützt wiederkehrende Zahlungen, aber die Einrichtung ist komplexer als bei Stripe Subscriptions. Der Kunde muss explizit einem Billing Agreement zustimmen, und der Shop muss regelmässig Authorize-Requests senden. Lösung: Billing Agreements als eigene Datenbank-Entität verwalten und einen Cronjob einrichten, der fällige Zahlungen auslöst.

## Migration und Versions-Kompatibilität

Amazon Pay v2 ist die aktuelle API-Version (seit 2021). Version 1 wird seit Ende 2023 nicht mehr für neue Integrationen akzeptiert. Bestehende v1-Implementierungen funktionieren noch, erhalten aber keine Updates und keine neuen Features. Die Migration von v1 auf v2 betrifft den kompletten API-Client: Andere Endpunkte, anderer Signatur-Mechanismus (RSA statt HMAC), andere Session-Verwaltung.

Für TYPO3 gibt es keine offizielle Amazon Pay Extension im TER mit aktivem v12/v13-Support. Die Integration erfolgt als Custom-Code oder über Community-Plugins für aimeos. Gosign implementiert Amazon Pay als eigenständiges Composer-Paket, das in beliebige TYPO3-Shop-Setups eingebunden werden kann. Dieses Paket kapselt den API-Client, den Button und den Webhook-Handler, sodass ein TYPO3-Major-Upgrade nur die TYPO3-spezifische Adapter-Schicht betrifft.

Für Shop-Betreiber, die neben Amazon Pay auch PayPal, Kreditkarte und Klarna anbieten, empfiehlt Gosign eine einheitliche Payment-Abstraktion. Statt jeden Provider einzeln zu integrieren, wird eine gemeinsame Schnittstelle implementiert, über die alle Payment-Provider angesteuert werden. aimeos bringt diese Abstraktion nativ mit (Service-Provider-Architektur). Für Custom-Shops baut Gosign eine vergleichbare Schicht, die den Checkout-Code von den Provider-spezifischen APIs entkoppelt. Das reduziert den Aufwand für neue Payment-Provider auf die Implementierung eines einzelnen Adapters statt einer Komplett-Integration.

Die Gesamtkosten einer Amazon Pay Integration in einem bestehenden TYPO3-Shop liegen bei 3 bis 8 Entwicklungstagen, je nachdem ob ein aimeos-Plugin genutzt werden kann oder eine Custom-Integration nötig ist. Die Amazon-Zertifizierung erfordert zusätzlich 1 bis 2 Tage für Vorbereitung und Korrekturrunden.

--- Angular & TYPO3 - Headless CMS | Gosign ---
> Angular-Frontend mit TYPO3: Headless CMS, JSON-API, SPA-Integration. KI-beschleunigte Entwicklung.

## Warum Angular mit TYPO3 funktioniert, aber die meisten Setups scheitern

Die Idee klingt überzeugend: TYPO3 liefert Content als JSON, Angular rendert das Frontend als Single Page Application. Redakteure arbeiten im gewohnten TYPO3-Backend, Entwickler bauen ein modernes Frontend ohne TypoScript-Zwänge. In der Praxis scheitern viele Angular-TYPO3-Projekte an der Architektur-Grenze zwischen CMS und SPA. Die offizielle TYPO3 Headless Extension (EXT:headless) löst das Content-Delivery-Problem. Aber Routing, Preview, SEO und Caching brauchen durchdachte Lösungen, die über ein `ng serve` hinausgehen.

Angular als Frontend für TYPO3 eignet sich für Unternehmen, die Multi-Channel-Content brauchen: eine Website, eine App, ein Intranet-Portal und Digital Signage aus einer Content-Quelle. Der Aufwand rechnet sich ab dem zweiten Kanal. Für reine Websites ohne App-Ambition ist ein klassisches TYPO3-Fluid-Setup fast immer effizienter.

## Typische Einsatzszenarien

**Multi-Channel-Plattformen mit App und Web.** Ein Automobilzulieferer pflegt Produktdaten, Serviceinformationen und News in TYPO3. Die Website läuft als Angular-SPA, die Service-App für Techniker nutzt dieselbe JSON-API. Änderungen in TYPO3 erscheinen auf beiden Kanälen gleichzeitig. Der Content wird einmal gepflegt, zweimal ausgeliefert.

**Intranet-Portale mit komplexer Interaktion.** HR-Dashboards, Wissensmanagement-Plattformen und interne Tools profitieren von Angulars komponentenbasiertem Ansatz. TYPO3 liefert strukturierten Content (Policies, Handbücher, Organigramme), Angular rendert interaktive Views mit Filtern, Suche und Echtzeit-Updates. Die Authentifizierung läuft über das bestehende LDAP/SSO, TYPO3 prüft Berechtigungen per fe_group.

**Konfiguratoren und interaktive Produktseiten.** Hersteller von konfigurierbaren Produkten nutzen Angular für die 3D-Ansicht oder den Konfigurator. Die Produktstammdaten kommen aus TYPO3, die Konfigurationslogik lebt im Angular-Frontend. Bei einem Kunden mit 1.200 konfigurierbaren Varianten reduzierte dieser Ansatz die Ladezeit der Konfiguratorseite von 4,2 auf 1,1 Sekunden.

## Technische Architektur

Die TYPO3 Headless Extension transformiert die Standard-Ausgabe von HTML in JSON. Jedes Content-Element, jede Navigation, jede Breadcrumb-Ebene wird als JSON-Objekt ausgeliefert. Angular konsumiert diese API über HttpClient-Services.

Die Architektur besteht aus drei Schichten. TYPO3 als Backend liefert Content über die Headless-API unter `/api/`. Angular als Frontend-Applikation wird als eigener Build-Prozess (`ng build --prod`) kompiliert und typischerweise über ein CDN oder einen separaten Webserver ausgeliefert. Dazwischen steht ein Node.js-basierter SSR-Server (Angular Universal), der Server-Side Rendering für SEO und soziale Netzwerke übernimmt.

Das Routing ist zweigeteilt: Angular Router übernimmt die Client-seitige Navigation, TYPO3 definiert die URL-Struktur über Site Configuration. Beide müssen synchron bleiben. In der Praxis bedeutet das: Wenn ein Redakteur in TYPO3 eine neue Seite anlegt, muss Angular diese URL kennen. Die Lösung ist ein dynamisches Routing im Angular-Frontend, das die Seitenstruktur bei jedem Build aus der TYPO3-API abfragt.

TypeScript-Services werden aus den TYPO3 Content-Typen generiert. Für jedes Content Element existiert ein Angular Component mit Typing. Diese Typen lassen sich per Script aus der TYPO3-API generieren, was den Gleichlauf zwischen Backend und Frontend sicherstellt.

## Häufige Probleme und Lösungen

**SEO-Defizite durch Client-Side-Only-Rendering.** Google rendert JavaScript, aber nicht zuverlässig und nicht sofort. Ohne Server-Side Rendering (Angular Universal oder Angular SSR seit v17) werden Seiten spät oder gar nicht indexiert. Die Lösung: Angular Universal als SSR-Layer einsetzen. Der initiale HTML-Response muss vollständig gerendert sein, bevor der Client-seitige Hydration-Prozess übernimmt.

**Content-Preview im TYPO3-Backend funktioniert nicht.** Redakteure klicken auf "Vorschau" und sehen JSON statt eine gerenderte Seite. Die Lösung: einen Preview-Proxy konfigurieren, der die JSON-Antwort an eine dedizierte Angular-Preview-Instanz weiterleitet. EXT:headless bietet dafür einen Preview-Modus, der Draft-Content über einen Token-Parameter ausliefert.

**CORS-Probleme zwischen TYPO3-API und Angular-Frontend.** Wenn TYPO3 und Angular auf unterschiedlichen Domains laufen, blockiert der Browser die API-Requests. Die Extension EXT:cors oder ein serverseitiger Reverse-Proxy löst dieses Problem. Empfohlen: Beide unter derselben Domain betreiben (TYPO3 unter `/api/`, Angular unter `/`).

## Migration und Versions-Kompatibilität

EXT:headless ist offiziell kompatibel mit TYPO3 v11, v12 und v13. Die Extension wird aktiv gepflegt und folgt dem TYPO3-Release-Zyklus. Angular selbst hat einen eigenen Release-Rhythmus: alle 6 Monate eine neue Major-Version. Seit Angular v17 ist SSR nativ integriert (kein separates Angular Universal Paket mehr nötig).

Für bestehende Angular-TYPO3-Projekte auf TYPO3 v10 oder älter empfiehlt sich eine stufenweise Migration: erst TYPO3 auf v12 oder v13 aktualisieren, dann Angular auf die aktuelle LTS-Version (v18). Die API-Schnittstelle von EXT:headless hat sich zwischen v2 und v4 an mehreren Stellen geändert, insbesondere bei der Behandlung von Sprach-Overlays und Workspace-Previews.

Der Aufwand für ein Angular-TYPO3-Projekt liegt typischerweise 30-50% über dem eines reinen Fluid-Projekts. Diesen Mehraufwand holt man durch den zweiten Kanal (App, Intranet) wieder ein. Gosign berät vor dem Projektstart, ob Headless der richtige Ansatz ist oder ob ein klassisches Setup mit gezielten JavaScript-Inseln den gleichen Zweck erfüllt.

--- Amazon S3 TYPO3 - Cloud Storage FAL | Gosign ---
> Amazon S3 als FAL-Treiber für TYPO3. Dateien in der Cloud speichern statt auf dem Webserver. Unverzichtbar für Multi-Server-Setups, CDN-Anbindung.

## aus_driver_amazon_s3 ist die Standard-Lösung, wenn TYPO3 Assets nicht mehr auf dem Webserver liegen dürfen - die Extension bringt S3-Buckets als vollwertigen FAL-Treiber in den TYPO3-Stack

Ein klassisches TYPO3-Setup speichert alle Mediendaten unter fileadmin auf dem Webserver. Das funktioniert, solange das Projekt auf einer einzigen Maschine läuft und der Speicher ausreicht. Sobald aber Multi-Server-Setups, Container-Cluster, Auto-Scaling oder Content Delivery Networks ins Spiel kommen, bricht dieses Modell. Jede Instanz bräuchte eine identische Kopie aller Dateien, Synchronisierung wird zur Dauerbaustelle, Deployments werden langsam. aus_driver_amazon_s3 löst das, indem es Amazon S3 als externe FAL-Storage einbindet. Dateien liegen im Bucket, TYPO3 liest und schreibt sie über die S3-API, und jede Server-Instanz greift auf denselben konsistenten Datenbestand zu. Für Projekte mit Hochverfügbarkeits-Anforderungen ist das der Standard-Weg.

Neben der technischen Notwendigkeit für Multi-Server-Setups gibt es einen zweiten wichtigen Treiber: Backup und Redundanz. S3 speichert jede Datei automatisch mehrfach über verschiedene Rechenzentren verteilt und erreicht damit eine Datenhaltung, die ein klassischer Webserver nicht garantieren kann. Für Unternehmen, deren Mediendaten geschäftskritisch sind, ist das allein ein Grund, auf S3 zu wechseln.

## Typische Einsatzszenarien

Der erste Fall sind Cloud-Native-Deployments auf AWS, Kubernetes oder Docker Swarm. TYPO3 läuft in mehreren Containern hinter einem Load Balancer, jeder Container ist zustandslos. fileadmin als lokales Verzeichnis würde bedeuten, dass Uploads nur auf einem Container landen und die anderen sie nicht sehen. aus_driver_amazon_s3 hält den Asset-Bestand zentral und macht Scale-out erst praktikabel.

Der zweite Fall sind Projekte mit sehr großen Datenmengen. Eine Medien-Plattform, ein Bild-Archiv oder ein Download-Portal wächst schnell auf mehrere hundert Gigabyte oder Terabyte. Lokaler Server-Speicher wird teuer und unflexibel, S3 skaliert transparent und kostet nur, was wirklich belegt ist. Die Anbindung über FAL erlaubt dabei, ohne Code-Änderungen in TYPO3 auf den neuen Storage zu wechseln.

Dritter Einsatz: CDN-Integration. Wer Bilder und Downloads über Cloudfront, Cloudflare oder ein eigenes CDN ausliefern will, nutzt S3 als Origin. aus_driver_amazon_s3 macht die Dateien direkt im Bucket verfügbar, TYPO3 generiert die korrekten URLs und das CDN cached sie global. Das verbessert Ladezeiten für internationale Besucher messbar.

## Technische Architektur

aus_driver_amazon_s3 implementiert das FAL-Driver-Interface von TYPO3 und nutzt das offizielle AWS SDK for PHP für die Kommunikation mit S3. Jeder Bucket wird als eigene "File Storage" im TYPO3-Backend eingerichtet, mit Angabe von Bucket-Name, Region, Access Key und Secret Key. Alternativ lassen sich IAM-Rollen verwenden, wenn TYPO3 auf einer EC2-Instanz oder in einem ECS-Task läuft - das ist sauberer, weil keine statischen Credentials in der Konfiguration stehen.

Die Extension unterstützt sowohl Amazon S3 als auch S3-kompatible Services wie MinIO, Backblaze B2, DigitalOcean Spaces oder Scaleway Object Storage. Für Projekte, die aus Datenschutz-Gründen nicht bei AWS liegen können, ist diese Flexibilität wichtig - ein europäischer S3-kompatibler Provider verhält sich aus TYPO3-Sicht genauso wie der AWS-Dienst.

Im laufenden Betrieb liest und schreibt TYPO3 direkt gegen S3. Die Processed Files - also die zugeschnittenen und optimierten Bildvarianten - werden standardmäßig ebenfalls im Bucket gespeichert. Alternativ kann ein lokales Verzeichnis für Processed Files konfiguriert werden, was die Bildverarbeitung beschleunigt, weil GIFBUILDER nicht jedes Quellbild erst aus S3 ziehen muss.

Die Konfiguration erfolgt über das Backend-Modul "File Storages" und ergänzende TypoScript-Einstellungen für die Bucket-URL und CDN-Präfixe. Entwickler müssen zusätzlich die AWS-SDK-Dependency per Composer installieren und die richtigen Berechtigungen am Bucket setzen.

## Häufige Probleme und Lösungen

Das erste Problem ist die Performance bei großen Bilderlisten. Wenn eine Seite dutzende Bilder gleichzeitig zuschneiden muss und die Quelldateien aus S3 gezogen werden, dauert der Seitenaufbau spürbar länger. Die Lösung liegt in einem lokalen Cache für Processed Files, eventuell kombiniert mit einem Pre-Warming-Skript, das nach neuen Uploads die gängigsten Varianten vorab erzeugt.

Zweites Problem: Berechtigungsfehler beim Upload. Wenn TYPO3 in den Bucket schreiben will, aber die IAM-Policy nur Lesezugriff erlaubt, bricht der Upload mit einer kryptischen Fehlermeldung ab. Die Lösung ist eine präzise Policy mit s3:GetObject, s3:PutObject, s3:DeleteObject und s3:ListBucket für genau den TYPO3-Bucket, idealerweise begrenzt auf einen Präfix, damit andere Anwendungen auf demselben Bucket nicht versehentlich betroffen sind.

Drittes Problem: Datenschutz und Regionen-Wahl. Projekte, die DSGVO-konform arbeiten müssen, sollten AWS-Regionen in der EU wählen - typischerweise eu-central-1 in Frankfurt oder eu-west-1 in Irland. Für höhere Anforderungen oder Kunden, die AWS grundsätzlich ausschließen, ist ein europäischer S3-kompatibler Provider wie Hetzner, IONOS oder Scaleway der passende Weg. Die Extension arbeitet mit all diesen Providern.

## Migration und Versions-Kompatibilität

aus_driver_amazon_s3 ist mit TYPO3 v11, v12 und v13 kompatibel und wird aktiv weiterentwickelt. Bei Upgrades ist die Version des AWS SDK zu beachten - neuere TYPO3-Versionen erfordern oft aktuelle SDK-Versionen, die wiederum PHP 8.1 oder höher voraussetzen.

Eine Migration von lokalem fileadmin zu S3 ist ein klar abgrenzbares Projekt: Dateien initial per aws s3 sync in den Bucket kopieren, im TYPO3-Backend eine neue File Storage einrichten, bestehende sys_file-Datensätze per Skript auf die neue Storage umbiegen, lokale Dateien nach erfolgreichem Test löschen. Die Extension bringt keine fertige Migrations-Routine mit, weil die genaue Vorgehensweise projektspezifisch ist.

Im Bestand gilt vor der Migration die Pflicht zur Inventarisierung. Wie viele Dateien liegen im fileadmin, wie groß ist der Datenbestand, welche davon sind verwaist und welche tatsächlich noch verlinkt? Oft stellt sich bei solchen Audits heraus, dass ein Großteil der Altdaten nie wieder aufgerufen wird und sich die Migration auf die aktiv genutzten Dateien beschränken lässt. Das reduziert Risiko, Aufwand und Bucket-Kosten.

Gosign begleitet S3-Migrationen für TYPO3-Projekte und konzipiert Multi-Cloud-Architekturen, die Datenschutz-Anforderungen und Performance-Ziele gleichzeitig erfüllen.

--- Azure Storage TYPO3 - Cloud FAL | Gosign ---
> Azure Blob Storage als TYPO3 FAL-Treiber. Dateien in der Microsoft Cloud speichern. Pendant zu aus_driver_amazon_s3 für Azure-Infrastrukturen.

## Unternehmen mit Microsoft-Stack brauchen Azure Storage statt lokaler Dateisysteme

Wenn die IT-Landschaft auf Azure läuft, Active Directory die Benutzer verwaltet und SharePoint die Dokumente hält, dann gehört auch das TYPO3-Dateisystem in die Azure Cloud. EXT:azurestorage bindet Azure Blob Storage als FAL-Treiber (File Abstraction Layer) in TYPO3 ein. Redakteure merken keinen Unterschied, die Dateien liegen aber statt auf dem Webserver in Microsofts Cloud-Infrastruktur mit CDN, Geo-Redundanz und praktisch unbegrenztem Speicher.

Diese Extension ist das Azure-Pendant zu EXT:aus_driver_amazon_s3. Die Entscheidung zwischen beiden fällt selten technisch, sondern entlang der bestehenden Cloud-Strategie. Wer bereits Azure nutzt, spart Komplexität, Verträge und Netzwerk-Kosten durch den Verbleib im Microsoft-Ökosystem.

## Typische Einsatzszenarien

**Enterprise-Websites mit Multi-Server-Setup.** Große TYPO3-Installationen laufen auf mehreren Webservern hinter einem Load Balancer. Ohne Cloud-Storage müssen Dateien zwischen den Servern synchronisiert werden, per rsync, NFS oder GlusterFS. Jede dieser Lösungen bringt eigene Probleme. Azure Blob Storage als FAL-Treiber macht die Dateisynchronisation überflüssig: Alle Server greifen auf denselben Blob Container zu. Bei einem Kunden mit 4 Webservern und 180.000 Dateien entfiel durch die Migration auf Azure die gesamte NFS-Infrastruktur.

**Medienintensive Portale mit globalem Publikum.** Unternehmen mit Kunden in Europa, Asien und Nordamerika brauchen schnelle Ladezeiten weltweit. Azure CDN liefert Bilder und Downloads über Edge-Server in über 130 Städten aus. Die Integration erfolgt über die CDN-Endpunkt-Konfiguration im Azure Portal, TYPO3 generiert automatisch die passenden CDN-URLs.

**Compliance-Anforderungen an Datenhaltung.** Manche Branchen verlangen, dass Dateien in einem bestimmten Land gespeichert werden. Azure bietet Rechenzentren in Frankfurt, Zürich und Wien. Über die Storage-Account-Konfiguration lässt sich exakt festlegen, wo die Daten physisch liegen. Das ist ein Vorteil gegenüber generischen S3-kompatiblen Anbietern, bei denen die Geo-Konfiguration oft undurchsichtig ist.

## Technische Architektur

EXT:azurestorage implementiert das TYPO3 FAL Driver Interface. Das bedeutet: Die Extension registriert sich als Treiber im File Abstraction Layer und überschreibt die Standard-Dateisystemoperationen (Lesen, Schreiben, Löschen, Auflisten) mit Azure Blob Storage API-Aufrufen.

Die Konfiguration erfolgt über die TYPO3 File Storage Einstellungen im Backend. Dort wird ein neues Storage-Objekt angelegt mit dem Treiber "Azure Blob Storage". Die Zugangsdaten (Storage Account Name, Access Key oder SAS Token) werden in der Storage-Konfiguration hinterlegt. Empfohlen: SAS Token mit begrenzter Gültigkeit und Lese-/Schreibrechten statt des Master Access Keys.

Die Kommunikation zwischen TYPO3 und Azure erfolgt über die Azure Storage REST API. Uploads werden als Block Blobs gespeichert, große Dateien (über 256 MB) automatisch in Blöcke aufgeteilt. Für die PHP-seitige Integration nutzt die Extension das Azure SDK for PHP oder eine leichtgewichtige REST-Client-Implementierung.

Bilder werden bei Bedarf von TYPO3s Image Processing (GraphicsMagick/ImageMagick) verarbeitet. Die verarbeiteten Varianten werden ebenfalls in Azure gespeichert, typischerweise in einem separaten Container (_processed_). Das Caching der Processed Files verkürzt die Verarbeitungszeit bei wiederholten Anfragen.

## Häufige Probleme und Lösungen

**Langsame Backend-Performance beim Durchsuchen großer Verzeichnisse.** Azure Blob Storage hat keine echte Verzeichnisstruktur, sondern emuliert sie über Pfad-Präfixe. Das Auflisten von 10.000 Dateien in einem "Ordner" erfordert API-Paginierung und dauert spürbar länger als auf einem lokalen Dateisystem. Die Lösung: TYPO3s FAL-Indexer korrekt konfigurieren und den Index regelmäßig aktualisieren, statt bei jedem Backend-Zugriff live gegen Azure zu prüfen.

**Image Processing schlägt fehl.** TYPO3 muss Bilder zum Verarbeiten herunterladen, verarbeiten und wieder hochladen. Bei instabiler Verbindung oder großen Bildern (TIFF-Dateien mit 200 MB) bricht der Prozess ab. Lösung: die Verarbeitung auf dem Server mit lokalem Temp-Verzeichnis durchführen und nur das Ergebnis hochladen. Die Konfiguration `processingFolder` sollte auf einen lokalen Pfad zeigen.

**Kosten-Explosion durch unnötige API-Calls.** Jeder Dateizugriff ist ein API-Call, und Azure rechnet pro 10.000 Transaktionen ab. Ein schlecht konfigurierter TYPO3-Indexer kann tausende Calls pro Minute erzeugen. Monitoring über Azure Cost Management einrichten und den FAL-Indexer auf Scheduler-basierte Intervalle (statt Echtzeit) umstellen.

## Migration und Versions-Kompatibilität

EXT:azurestorage ist ein Nischenprodukt mit begrenzter Community. Die verfügbaren Versionen im TER und auf Packagist unterstützen TYPO3 v10 und v11. Für v12 existieren Forks auf GitHub mit unterschiedlichem Reifegrad. Für TYPO3 v13 gibt es aktuell keine fertige Lösung.

Die Alternative für v12/v13: EXT:aus_driver_amazon_s3 mit einem S3-kompatiblen Azure-Endpunkt. Azure Blob Storage bietet seit 2020 eine S3-kompatible API-Schicht. Damit lässt sich die bewährtere und besser gepflegte S3-Extension auch mit Azure nutzen. Die Einrichtung erfordert einen Azure Storage Account mit aktiviertem "S3-Compatible API"-Feature und die Konfiguration der S3-Extension mit dem Azure-Endpunkt.

Wer von lokalem Dateisystem auf Azure migriert, sollte den Umzug in drei Phasen planen: erstens die bestehenden Dateien per AzCopy oder Storage Explorer in den Blob Container hochladen, zweitens die TYPO3 File Storage Konfiguration umstellen und drittens den FAL-Index neu aufbauen. Bei 50.000 Dateien dauert der gesamte Prozess typischerweise einen Arbeitstag. Gosign hat Azure-Migrationen für TYPO3-Projekte mit bis zu 400.000 Dateien durchgeführt und berät sowohl zur nativen Extension als auch zum S3-kompatiblen Workaround.

--- be_acl TYPO3 - Backend-Rechte | Gosign ---
> Backend Access Control Lists für TYPO3. Granulare Berechtigungen für Backend-Benutzer und -Gruppen. Essentiell für Multi-Redaktions-Setups: Wer darf.

## Sobald mehr als drei Redakteure arbeiten, reichen TYPO3s Standard-Rechte nicht mehr aus

TYPO3 bringt ein Berechtigungssystem mit: Backend-Gruppen, Seitenzugriffe, Tabellen-Rechte. Für kleine Teams mit einer Handvoll Redakteuren funktioniert das. Aber wenn eine Unternehmenswebsite von 15 Redakteuren aus 4 Abteilungen gepflegt wird, stößt das Standard-System an Grenzen. be_acl erweitert TYPO3 um granulare Access Control Lists, die regeln, wer auf welcher Seite welche Inhalte sehen, bearbeiten oder löschen darf - bis auf Feldebene.

Die Extension ist kein Nice-to-have, sondern Voraussetzung für jedes Multi-Redaktions-Setup mit mehr als einer Verantwortungszone. Ohne be_acl enden Berechtigungskonzepte in TYPO3 regelmäßig in einem Geflecht aus dutzenden Gruppen, die niemand mehr überblickt.

## Typische Einsatzszenarien

**Konzern-Websites mit Abteilungs-Verantwortung.** Marketing pflegt die Startseite und Kampagnenseiten, HR die Karriereseite, die Fachabteilungen ihre Produktseiten. Jede Abteilung soll nur ihre eigenen Seiten sehen und bearbeiten. Das Standard-TYPO3-System erlaubt Seitenzugriffe über Mount Points und Gruppenrechte, aber die Konfiguration wird bei 10+ Abteilungen unübersichtlich. be_acl vereinfacht das durch seitenbasierte ACLs: Auf jeder Seite im Seitenbaum lässt sich direkt definieren, welche Gruppe welche Rechte hat.

**Mandantenfähige TYPO3-Installationen.** Agenturen und Konzerne betreiben mehrere Websites in einer TYPO3-Instanz. Mandant A darf Mandant B nicht sehen, nicht einmal im Seitenbaum. be_acl setzt diese Trennung durch, ohne für jeden Mandanten eine eigene TYPO3-Installation zu betreiben. Bei einer Agentur mit 12 Mandanten in einer TYPO3-Instanz reduzierte be_acl die Administrationszeit für Berechtigungen um circa 60%.

**Freigabe-Workflows mit eingeschränkter Bearbeitungstiefe.** Externe Dienstleister oder Praktikanten sollen Content-Texte bearbeiten, aber keine Bilder hochladen, keine Seiten verschieben und keine Plugins konfigurieren. be_acl erlaubt Rechte auf Feldebene: Der Benutzer sieht das Textfeld, aber nicht die Layout-Einstellungen oder die Plugin-Konfiguration.

## Technische Architektur

be_acl erweitert TYPO3s Backend-Berechtigungssystem um ein ACL-Layer, das zwischen dem Core-Rechtesystem und der Benutzerinteraktion sitzt. Die Extension speichert Berechtigungsregeln in der Tabelle `tx_beacl_acl`, die pro Seite und pro Gruppe definiert, welche Operationen erlaubt sind.

Das System arbeitet mit drei Rechteebenen: Lesen (show), Bearbeiten (edit) und Löschen (delete). Diese Rechte werden pro Seite oder rekursiv für einen Seitenbaum vergeben. Die Konfiguration erfolgt über ein eigenes Tab im Seiteneigenschaften-Dialog: Dort wählt der Administrator eine Benutzergruppe und setzt die gewünschten Rechte per Checkbox.

Intern greift be_acl in TYPO3s `BackendUserAuthentication` ein und erweitert die `doesUserHaveAccess`-Prüfung. Bei jedem Seitenzugriff im Backend prüft TYPO3 zuerst die Standard-Rechte und anschließend die ACL-Regeln. Die ACL-Regeln können Standard-Rechte erweitern, aber nicht einschränken. Das ist ein wichtiges Architekturdetail: Wenn eine Gruppe über die Standard-Rechte bereits Zugriff hat, kann be_acl diesen nicht entziehen.

Die Rechte-Auflösung folgt einer Kaskade: Benutzer-Rechte schlagen Gruppen-Rechte, Gruppen-Rechte schlagen Untergruppen-Rechte, und seitenspezifische ACLs schlagen rekursiv vererbte ACLs. Diese Kaskade funktioniert zuverlässig, solange die Gruppenstruktur flach bleibt. Ab 4 verschachtelten Gruppenebenen wird das Verhalten schwer vorhersagbar.

## Häufige Probleme und Lösungen

**Berechtigungen greifen nicht wie erwartet.** Häufigste Ursache: Der Benutzer ist Mitglied in mehreren Gruppen, und die Rechte einer Gruppe überschreiben die ACL-Einschränkung einer anderen. TYPO3s Rechtesystem arbeitet additiv, das heißt, der Benutzer erhält die Summe aller Rechte seiner Gruppen. Lösung: Berechtigungsmatrix erstellen, alle Gruppen eines Benutzers dokumentieren und Überschneidungen eliminieren.

**Performance-Probleme bei großen Seitenbäumen.** Bei TYPO3-Installationen mit mehr als 5.000 Seiten und 20+ Benutzergruppen kann die ACL-Prüfung den Seitenbaum im Backend spürbar verlangsamen. Die Extension prüft bei jedem Seitenaufruf die ACL-Tabelle. Lösung: Caching der ACL-Prüfungen aktivieren und den Seitenbaum über `options.pageTree.excludeDoktypes` auf relevante Seitentypen einschränken.

**Rechte-Debugging ist schwierig.** TYPO3 bietet kein eingebautes Tool, das anzeigt, warum ein Benutzer auf eine bestimmte Seite zugreifen kann oder nicht. Der Admin-Bereich "Backend User" zeigt die simulierte Ansicht, aber nicht die Rechte-Kaskade. Lösung: Das TYPO3 System Log analysieren (bei aktiviertem Debug-Modus loggt TYPO3 Zugriffsversuche) oder die SQL-Tabelle `tx_beacl_acl` direkt abfragen.

## Migration und Versions-Kompatibilität

be_acl ist eine der am längsten gepflegten TYPO3-Extensions. Die aktuelle Version unterstützt TYPO3 v11 und v12. Für TYPO3 v13 existiert eine Beta-Version, die auf dem neuen Backend-Modul-System basiert. Die Extension wird aktiv auf GitHub entwickelt, die Maintainer reagieren auf Issues.

Bei der Migration von TYPO3 v11 auf v12 müssen die ACL-Regeln nicht manuell migriert werden, die Datenbanktabelle bleibt kompatibel. Allerdings hat sich die Backend-Modul-Registrierung in v12 geändert, weshalb das be_acl-Konfigurationsmodul ein Update der Extension-Version erfordert.

Für Unternehmen, die auf TYPO3 v13 migrieren, empfiehlt sich vor dem Upgrade ein Export der bestehenden ACL-Regeln. TYPO3 v13 bringt ein überarbeitetes Berechtigungssystem mit, das einige Funktionen von be_acl in den Core übernimmt. Ob die Extension langfristig noch nötig ist, hängt von der Komplexität des Berechtigungskonzepts ab. Gosign analysiert bei TYPO3-Upgrades das bestehende ACL-Setup und empfiehlt die optimale Lösung, ob be_acl, Core-native Rechte oder eine Kombination.

--- bernetshop TYPO3 - Einfacher Shop | Gosign ---
> Einfachere E-Commerce-Extension für TYPO3 als aimeos. Für kleinere Shops mit Basis-Anforderungen: Produktliste, Warenkorb, einfache Bezahlung.

## Nicht jeder TYPO3-Shop braucht ein vollständiges E-Commerce-Framework

Aimeos ist der Standard für E-Commerce in TYPO3. Aber Aimeos ist auch komplex: eigene Datenbank-Abstraktionsschicht, eigenes Template-System, über 30 Konfigurationstabellen. Für einen Verein, der 8 Merchandise-Artikel verkauft, oder ein mittelständisches Unternehmen mit 50 Ersatzteilen ist das Overkill. bernetshop bietet eine leichtgewichtige Alternative: Produktliste, Warenkorb, Bezahlung, fertig. Keine Warenwirtschaft, kein Lagermanagement, keine Multi-Store-Fähigkeit, aber auch kein monatelanger Setup-Aufwand.

Die Extension richtet sich an Organisationen, die wenige Produkte über ihre bestehende TYPO3-Website verkaufen wollen, ohne ein separates Shop-System zu betreiben. Der typische Einsatz: 10-200 Produkte, einfache Varianten (Größe, Farbe), Zahlung per Rechnung, PayPal oder Stripe.

## Typische Einsatzszenarien

**Vereine und gemeinnützige Organisationen.** Sportvereine verkaufen Trikots und Eintrittskarten, kulturelle Einrichtungen bieten Jahreskarten und Publikationen an. Der Shop muss einfach zu pflegen sein, weil ehrenamtliche Mitarbeiter ihn betreuen. bernetshop lässt sich über Standard-TYPO3-Inhaltselemente konfigurieren: Ein Produkt ist ein Datensatz mit Bild, Preis, Beschreibung und Varianten. Kein Schulungsbedarf jenseits der normalen TYPO3-Redaktion.

**Ersatzteil- und Zubehörverkauf.** Maschinenbauer und Gerätehersteller verkaufen Verschleißteile, Zubehör und Verbrauchsmaterial über die Firmenwebsite. Die Produktdaten existieren bereits in TYPO3 (Produktseiten, Datenblätter), bernetshop ergänzt Warenkorb und Bezahlfunktion. Die Produktpflege bleibt dort, wo die technischen Daten ohnehin liegen: im CMS.

**Interne Bestellportale.** Größere Unternehmen nutzen einfache Bestellsysteme für Bürobedarf, Werbematerial oder IT-Zubehör. bernetshop mit TYPO3 Frontend-Login ergibt ein passwortgeschütztes Bestellportal ohne externe Software. Die Bestellungen werden per E-Mail an den zuständigen Bereich weitergeleitet, eine ERP-Anbindung ist nicht vorgesehen und in diesem Kontext nicht nötig.

## Technische Architektur

bernetshop basiert auf Extbase/Fluid, dem Standard-Framework für TYPO3-Extensions. Die Produktdaten werden in einer eigenen Tabelle `tx_bernetshop_domain_model_product` gespeichert. Varianten (Größen, Farben) sind als Inline-Relationen modelliert. Der Warenkorb wird in der PHP-Session gehalten und bei registrierten Benutzern optional in der Datenbank persistiert.

Die Shop-Logik ist überschaubar: Es gibt Controller für Produktliste, Produktdetail, Warenkorb und Checkout. Die Templates sind Standard-Fluid und lassen sich wie jedes andere TYPO3-Template anpassen. Das Zahlungs-Handling erfolgt über einen Payment-Provider-Adapter: PayPal, Stripe und Rechnung sind standardmäßig implementiert. Weitere Anbieter lassen sich über ein PHP-Interface ergänzen.

Die Bestellungen werden in einer Datenbanktabelle gespeichert und lösen eine Bestätigungs-E-Mail an Kunde und Shop-Betreiber aus. Ein Backend-Modul zeigt alle Bestellungen mit Status (offen, bezahlt, versendet). Export als CSV ist integriert, eine direkte ERP-Schnittstelle nicht.

Die Extension nutzt TYPO3s Standard-Caching für Produktlisten. Der Warenkorb und Checkout-Bereich sind uncacheable (USER_INT). Das bedeutet: Produktlistenseiten profitieren vom TYPO3-Cache, der Checkout läuft ohne Cache, was bei hoher Last relevant wird.

## Häufige Probleme und Lösungen

**Skalierungsgrenzen ab 200 Produkten.** Die Produktliste wird bei steigender Produktzahl langsam, wenn keine Paginierung konfiguriert ist. bernetshop liefert eine einfache Paginierung mit, aber keine facettierte Suche oder Kategorie-Filter. Lösung: Ab 200 Produkten Kategorie-Seiten anlegen und die Produktliste pro Kategorie begrenzen. Ab 500 Produkten sollte man ernsthaft über Aimeos oder einen externen Shop nachdenken.

**Zahlungsintegration veraltet.** Die mitgelieferten Payment-Adapter nutzen teilweise ältere API-Versionen der Zahlungsanbieter. PayPals Classic API ist abgekündigt, Stripe hat seine API mehrfach aktualisiert. Lösung: Die Payment-Adapter prüfen und auf aktuelle API-Versionen aktualisieren. Der Aufwand pro Adapter liegt bei 1-2 Entwicklertagen.

**Rechtliche Anforderungen nicht vollständig abgedeckt.** Widerrufsrecht, Grundpreisangabe, Verpackungsverordnung und die ab 2024 verschärften Informationspflichten im E-Commerce erfordern Anpassungen, die bernetshop nicht out-of-the-box liefert. Lösung: Die Checkout-Templates um die rechtlich erforderlichen Informationen ergänzen. Das ist Template-Arbeit, keine Extension-Entwicklung.

## Migration und Versions-Kompatibilität

bernetshop ist eine Nischen-Extension mit begrenzter Pflege. Die letzte stabile Version unterstützt TYPO3 v10 und v11. Für TYPO3 v12 existiert kein offizielles Update, der Portierungsaufwand ist überschaubar (Extbase-API-Änderungen, TCA-Anpassungen), aber er muss manuell geleistet werden. Für TYPO3 v13 gibt es keine Planung.

Unternehmen, die auf TYPO3 v12 oder v13 migrieren, stehen vor der Entscheidung: bernetshop portieren oder auf eine Alternative wechseln. Die Optionen sind Aimeos (vollwertiges E-Commerce-Framework, deutlich höherer Aufwand), cart (Extbase-basierter Shop mit aktiver Pflege und v12-Kompatibilität) oder ein externer Shop (Shopify, WooCommerce) mit TYPO3-Integration über API.

Die Migration der Produktdaten ist in jedem Fall einfach: Die Tabelle hat eine klare Struktur, die sich per SQL-Script in jedes Zielsystem überführen lässt. Bei einem Kunden mit 85 Produkten dauerte die komplette Migration von bernetshop auf EXT:cart inklusive Template-Anpassung 4 Arbeitstage. Gosign berät zur wirtschaftlichsten Option und übernimmt bei Bedarf die Portierung oder Migration.

--- Bilddatenbank TYPO3 - Asset Management | Gosign ---
> Bilddatenbank in TYPO3: Digital Asset Management, Auto-Tagging, Suche. FAL-Erweiterung oder externe DAM-Anbindung.

## Ab 5.000 Bildern wird TYPO3s FAL zum Engpass

TYPO3s File Abstraction Layer verwaltet Dateien zuverlässig, solange die Menge überschaubar bleibt. Bei 500 Bildern funktioniert FAL einwandfrei. Bei 5.000 wird die Suche langsam. Bei 20.000 ist die Dateiliste im Backend kaum noch nutzbar. Unternehmen mit großen Bildbeständen brauchen mehr als ein Dateisystem: Sie brauchen ein Digital Asset Management. Die Frage ist, ob man TYPO3s FAL zum DAM ausbaut oder ein externes System anbindet.

Beide Wege funktionieren. Der interne Ausbau über FAL-Erweiterungen kostet weniger und bleibt im TYPO3-Ökosystem. Die externe Anbindung (Celum, Canto, Cloudinary, Bynder) bietet mehr Funktionen, erfordert aber Lizenzen, Schnittstellen-Pflege und doppelte Datenhaltungslogik.

## Typische Einsatzszenarien

**Produzierende Unternehmen mit Produktfotografie.** Ein Maschinenbauer hat 8.000 Produktfotos in verschiedenen Auflösungen, dazu CAD-Renderings, Anwendungsbilder und Datenblätter. Jedes Produkt existiert in 5-10 Bild-Varianten. Ohne systematische Verschlagwortung finden Redakteure das richtige Bild nicht, oder schlimmer, sie verwenden ein veraltetes. Auto-Tagging per KI analysiert Bildinhalte und vergibt Tags automatisch. Bei einem Kunden mit 12.000 Produktbildern reduzierte KI-basiertes Auto-Tagging die Verschlagwortungszeit von 3 Wochen auf 2 Tage.

**Medienunternehmen und Verlage.** Nachrichtenportale, Magazine und Corporate-Publishing-Abteilungen produzieren täglich neues Bildmaterial. Die Anforderungen: schnelle Suche, Rechteverwaltung (Lizenzablauf, Nutzungsrechte pro Kanal), automatische Formatkonvertierung und Metadaten-Vererbung. Ein erweitertes FAL mit Custom-Feldern deckt die Basisfunktionen ab. Für Rechteverwaltung und Workflow-Steuerung braucht es ein externes DAM.

**Hochschulen und Forschungseinrichtungen.** Universitäten verwalten Campusbilder, Veranstaltungsfotos, Forschungsgrafiken und Portraits der Mitarbeitenden. Die Herausforderung: dezentrale Zulieferung aus 30+ Fachbereichen in ein zentrales System. TYPO3 FAL mit Kategorie-basierter Ordnerstruktur und Zugriffsrechten pro Benutzergruppe löst das. Externe DAM-Systeme sind hier selten wirtschaftlich.

## Technische Architektur

TYPO3s FAL besteht aus drei Schichten: dem Storage Driver (lokales Dateisystem, S3, Azure), dem File Index (Datenbanktabelle `sys_file` mit Metadaten) und dem File Reference System (Verknüpfung zwischen Dateien und Content-Elementen). Eine Bilddatenbank in TYPO3 erweitert primär die mittlere Schicht, den File Index.

Die einfachste Erweiterung: Custom-Felder in der Tabelle `sys_file_metadata`. TYPO3 bringt bereits Felder wie `title`, `description`, `alternative` und `copyright` mit. Über TCA lassen sich beliebige weitere Felder ergänzen: `photographer`, `license_type`, `expiry_date`, `usage_rights`, `location`, `keywords_auto`. Diese Felder erscheinen im Datei-Metadaten-Dialog im Backend.

Für die Suche bietet TYPO3 standardmäßig nur eine Dateiname-Suche im File List Modul. Eine echte Volltextsuche über alle Metadaten erfordert entweder eine Solr-Integration (über EXT:solrfal) oder ein Custom Backend-Modul mit Elasticsearch-Anbindung. Solr durchsucht dann nicht nur Dateinamen, sondern alle Metadatenfelder, einschließlich automatisch generierter Tags.

Auto-Tagging per KI funktioniert über einen Scheduler-Task, der neue Dateien an einen Bilderkennungsdienst sendet (Google Cloud Vision, AWS Rekognition oder ein selbstgehostetes Modell) und die erkannten Tags in die Metadaten-Felder schreibt. Der Prozess ist asynchron und belastet das Backend nicht. Bei Erstimport großer Bestände rechnet man mit circa 1 Sekunde pro Bild für die API-Analyse.

## Häufige Probleme und Lösungen

**FAL-Index und Dateisystem laufen auseinander.** Wenn Dateien per FTP hochgeladen oder manuell gelöscht werden, stimmt der FAL-Index nicht mehr mit dem Dateisystem überein. TYPO3 zeigt Dateien an, die nicht existieren, oder kennt vorhandene Dateien nicht. Lösung: Den FAL-Indexer regelmäßig per Scheduler laufen lassen (empfohlen: täglich nachts). Der Indexer gleicht Dateisystem und Datenbank ab. Bei 50.000 Dateien dauert der Abgleich circa 10-15 Minuten.

**Metadaten gehen bei TYPO3-Upgrades verloren.** Custom-Felder in `sys_file_metadata` überleben TYPO3-Upgrades, wenn sie über eine eigene Extension definiert sind. Werden sie direkt in der TCA-Override-Datei des Sitepackages definiert, können sie bei strukturellen Änderungen der Metadaten-Tabelle verloren gehen. Lösung: Bilddatenbank-Felder immer in einer eigenen kleinen Extension kapseln, nicht im Sitepackage.

**Backend-Performance bei großen Dateibäumen.** Das File List Modul wird ab 1.000 Dateien pro Ordner träge, weil es Thumbnails für jedes Bild generiert. Lösung: Ordnerstruktur mit maximal 500 Dateien pro Verzeichnis anlegen und die Thumbnail-Generierung im File List auf "on demand" umstellen.

## Migration und Versions-Kompatibilität

TYPO3s FAL ist seit Version 6.0 (2012) Bestandteil des Core und wird mit jeder Major-Version weiterentwickelt. Die FAL-API ist stabil, Custom-Felder und Indexer funktionieren von TYPO3 v10 bis v13 ohne Anpassungen. Die Solr-FAL-Extension (EXT:solrfal) unterstützt TYPO3 v12, für v13 ist Kompatibilität angekündigt.

Wer von einem externen DAM-System auf TYPO3 FAL migriert, muss die Metadaten mappen. Jedes DAM-System hat ein eigenes Datenmodell. Die Migration selbst ist ein Datenbank-Job: Export aus dem DAM als CSV/JSON, Mapping der Felder auf `sys_file_metadata`, Import per TYPO3 DataHandler oder direktem SQL.

Die Entscheidung "FAL-Ausbau vs. externes DAM" hängt von zwei Faktoren ab: Bestandsgröße und Workflow-Komplexität. Bis circa 10.000 Assets und ohne Freigabe-Workflows reicht erweitertes FAL. Darüber hinaus oder bei Anforderungen wie automatischer Lizenzverwaltung und Multi-Channel-Distribution lohnt sich ein spezialisiertes DAM mit TYPO3-Connector. Gosign berät zu beiden Varianten und implementiert sowohl FAL-Erweiterungen als auch DAM-Integrationen.

--- Booking TYPO3 - Buchungssystem | Gosign ---
> Buchungssystem für TYPO3: Terminbuchung, Verfügbarkeit, Bezahlung. Custom-Entwicklung, KI-beschleunigt.

## Terminbuchung direkt auf der Website scheitert in TYPO3 oft an fehlender Extension-Reife

Unternehmen mit Beratungsterminen, Raumvermietung oder Kursangeboten wollen Online-Buchung direkt in ihre TYPO3-Website integrieren. Die Erwartung: Kalender, Verfügbarkeitsprüfung, Bezahlung, Bestätigungs-E-Mail, alles aus einem Guss. Die Realität: Es gibt im TYPO3-Extension-Repository (TER) keine einzelne Buchungs-Extension, die all diese Anforderungen produktionsreif abdeckt. Die vorhandenen Lösungen (jcc_appointment, cab_single_booking, diverse Eigenentwicklungen) bedienen Nischenfälle oder sind nicht aktiv gepflegt.

Deshalb ist ein TYPO3-Buchungssystem fast immer ein Hybrid: eine Basis-Extension oder Custom-Entwicklung für die Kernlogik, kombiniert mit Payment-Providern (Stripe, PayPal, Mollie) und Kalender-Schnittstellen (iCal, Google Calendar API). Gosign hat diesen Ansatz in über 15 Projekten umgesetzt.

## Typische Einsatzszenarien

**Beratungsunternehmen mit Terminvergabe.** Steuerberater, Rechtsanwälte, Unternehmensberater brauchen ein System, bei dem Kunden freie Slots sehen und buchen können. Der Kalender synchronisiert sich mit dem Outlook oder Google Calendar des Beraters. Bezahlung ist optional (oft wird erst nach der Beratung abgerechnet), aber Storno-Fristen und No-Show-Gebühren müssen abbildbar sein. Ein typisches Setup: 3 Berater, 4 Leistungsarten, 30-Minuten-Slots, 2 Standorte.

**Seminar- und Kursanbieter.** Bildungsträger, Volkshochschulen, Sportvereine bieten Kurse mit begrenzten Plätzen an. Das Buchungssystem braucht Teilnehmerlisten, Wartelisten, Gruppen-Preise, Frühbucher-Rabatte und Serien-Termine (z.B. 10 Yoga-Stunden als Block). Payment erfolgt bei Buchung, Storno mit Teilrückerstattung muss automatisiert sein.

**Raumvermietung und Ressourcen-Management.** Coworking Spaces, Tagungshotels, Sportanlagen vermieten Räume oder Plätze stundenweise. Hier zählt die Verfügbarkeitsanzeige in Echtzeit: Kein Raum darf doppelt gebucht werden, auch wenn zwei Nutzer gleichzeitig auf "Buchen" klicken. Race-Condition-Protection auf Datenbankebene ist kein Nice-to-have, sondern Pflicht.

## Technische Architektur

Ein produktionsreifes Buchungssystem in TYPO3 besteht aus vier Schichten. Die Datenbank-Schicht verwaltet Ressourcen (Räume, Personen, Geräte), Verfügbarkeiten (Zeitfenster, Sperrzeiten, Feiertage) und Buchungen (mit Status: angefragt, bestätigt, storniert, abgeschlossen). Die Logik-Schicht prüft Verfügbarkeit, verhindert Doppelbuchungen und berechnet Preise. Die Payment-Schicht kommuniziert mit externen Zahlungsanbietern über deren APIs. Die Benachrichtigungs-Schicht versendet Bestätigungen, Erinnerungen und Storno-Mails.

Für die Doppelbuchungs-Verhinderung gibt es drei Ansätze: pessimistisches Locking (SELECT ... FOR UPDATE), optimistisches Locking (Versionsnummer in der Buchungstabelle) oder Queue-basiert (Buchungsanfragen werden sequenziell abgearbeitet). Die Wahl hängt von der erwarteten Last ab. Bei unter 100 Buchungen pro Tag reicht optimistisches Locking, bei Events mit 1.000 gleichzeitigen Zugriffen ist eine Queue robuster.

iCal-Export ist Standard: Jede bestätigte Buchung generiert eine .ics-Datei, die als Anhang in der Bestätigungs-E-Mail mitgesendet wird. Für bidirektionalen Sync (Buchung im TYPO3 erscheint im Google Calendar und umgekehrt) ist die Google Calendar API oder CalDAV nötig.

## Häufige Probleme und Lösungen

**Doppelbuchungen trotz Verfügbarkeitsprüfung.** Die häufigste Ursache: die Prüfung "Ist der Slot frei?" und das Einfügen der Buchung laufen nicht in derselben Datenbank-Transaktion. Zwischen Prüfung und Insert können Millisekunden vergehen, in denen ein zweiter Nutzer denselben Slot bucht. Lösung: Prüfung und Insert in eine Transaktion mit Zeilensperre verpacken.

**Payment-Callbacks kommen nicht an.** Stripe und PayPal senden Zahlungsbestätigungen per Webhook. Wenn die TYPO3-Seite hinter einem Reverse Proxy oder einer Firewall liegt, erreichen die Callbacks den Server nicht. Lösung: Webhook-URL über eine dedizierte Route (z.B. `/api/payment/webhook`) bereitstellen, die nicht durch TYPO3-Caching oder .htaccess-Regeln blockiert wird. Testtools: Stripe CLI (`stripe listen --forward-to`), PayPal Sandbox Webhooks.

**Zeitzonen-Chaos bei internationalen Buchungen.** Wenn Buchende und Ressource in verschiedenen Zeitzonen sitzen, entstehen Fehler. Lösung: Alle Zeiten intern als UTC speichern, Anzeige im Frontend per JavaScript an die lokale Zeitzone des Nutzers anpassen.

## Migration und Versions-Kompatibilität

Es gibt keine einheitliche Buchungs-Extension mit offiziellem TYPO3 v12/v13-Support. Die meisten verfügbaren Extensions sind auf v10 oder v11 stehengeblieben. Wer ein bestehendes Buchungssystem auf TYPO3 v12+ migriert, hat zwei Optionen: Die Custom-Logik auf Extbase/Doctrine portieren (v12-kompatibel) oder die Buchungslogik als API-Microservice auslagern und nur das Frontend in TYPO3 rendern.

Für Neuentwicklungen empfiehlt sich ein API-first-Ansatz: Die Buchungs-Engine als REST-API (in TYPO3 oder als separater Service), das Frontend als Web-Komponente, die in jedes TYPO3-Template eingebettet werden kann. Damit bleibt das Buchungssystem unabhängig von TYPO3-Major-Upgrades. Gosign setzt diesen Ansatz seit 2024 als Standard um.

Wer ein externes Buchungssystem (Calendly, SimplyBook.me, Timify) nutzt und nur die Oberfläche in TYPO3 einbetten will, hat eine dritte Option: Das externe System per iframe oder JavaScript-Widget einbinden. Das funktioniert schnell, hat aber Nachteile: kein einheitliches Design, Datenschutz-Fragen (Drittanbieter-Cookies, Datenübertragung in die USA) und keine Kontrolle über den Buchungsablauf. Für DSGVO-sensible Branchen (Gesundheitswesen, Rechtsberatung, öffentliche Verwaltung) ist die Custom-Entwicklung innerhalb von TYPO3 oder als eigener Microservice die sauberere Lösung.

Gosign kalkuliert ein typisches Buchungssystem-Projekt (3 Ressourcentypen, Stripe-Payment, E-Mail-Workflows, iCal-Export) mit 15 bis 25 Entwicklungstagen. Davon entfallen etwa 40 % auf die Buchungslogik mit Verfügbarkeitsprüfung, 25 % auf die Payment-Integration, 20 % auf E-Mail-Templates und Benachrichtigungen und 15 % auf Frontend-Darstellung und Testing.

Für die Wartung nach Go-Live sind zwei Aspekte kritisch. Erstens: Payment-APIs ändern sich. Stripe und PayPal aktualisieren ihre APIs regelmässig, alte Versionen werden nach 12 bis 24 Monaten abgeschaltet. Ein Buchungssystem, das nicht gewartet wird, akzeptiert irgendwann keine Zahlungen mehr. Zweitens: Kalender-Sync muss überwacht werden. OAuth-Tokens für Google Calendar laufen nach 7 Tagen ab, wenn kein Refresh-Mechanismus implementiert ist. Gosign richtet Monitoring für beide Szenarien ein, damit Ausfälle innerhalb von Minuten erkannt und behoben werden.

--- bootstrap_grids TYPO3 - Grid-Layouts | Gosign ---
> Bootstrap Grid-Layouts als TYPO3 Content Elements. Spalten-Layouts ohne Gridelements-Overhead. Gosign migriert auch von bootstrap_grids.

## bootstrap_grids war lange die schnellste Abkürzung zu mehrspaltigen Layouts in TYPO3 - und ist heute ein Migrationskandidat

Jahrelang war bootstrap_grids in TYPO3-Projekten die pragmatische Antwort auf eine wiederkehrende Redaktions-Anforderung: Ich möchte auf einer Seite Spalten nebeneinander setzen, ohne dass Entwicklerinnen jedes Mal eigene Content-Elemente bauen müssen. Die Extension bringt eine Sammlung vordefinierter Bootstrap-Grid-Layouts als Content-Elemente ins Backend, sodass Redakteure Zwei-, Drei- oder Vierspalter direkt im Seiteninhalt anlegen können. Für Agenturen, die in kurzer Zeit viele Websites auf Basis von Bootstrap ausliefern, war das lange die effizienteste Lösung.

Heute ist die Lage differenzierter. Mit der Core-Extension EXT:container und den deutlich verbesserten Backend-Layouts in TYPO3 v11 bis v13 gibt es native Alternativen, die weniger Konfiguration benötigen und enger an den TYPO3-Standard andocken. bootstrap_grids bleibt in bestehenden Projekten relevant, aber Neuprojekte sollten es bewusst oder gar nicht mehr einsetzen.

## Typische Einsatzszenarien

Ein erstes Szenario ist die schnelle Bestandsaufnahme. Eine mittelständische Website mit rund 200 Seiten, die bereits auf Bootstrap basiert, nutzt bootstrap_grids, um ohne eigenes Site-Package-Setup mehrspaltige Layouts verfügbar zu machen. Redakteure wählen aus einem Dropdown Spalten-Layouts aus und füllen die Container mit Standard-Content-Elementen.

Ein zweites Szenario ist die Nachbesserung älterer Relaunches. Eine Verbandswebsite aus 2018 wurde ursprünglich mit bootstrap_grids gebaut und hat im Laufe der Zeit 600 Content-Elemente angesammelt, die in Grid-Containern liegen. Bei einem Upgrade von TYPO3 v9 auf v11 stellt sich die Frage: migrieren oder weiterführen. In der Regel wird bootstrap_grids zunächst weitergeführt, um das Upgrade nicht zu blockieren, und der Umstieg auf EXT:container folgt in einem zweiten Schritt.

Ein drittes Szenario ist die Übergangsphase zu einer modernen Frontend-Architektur. Ein Konzern migriert seinen Webauftritt von Bootstrap auf ein Tailwind-basiertes Design-System. Solange das Redaktionsteam noch nicht auf die neue Editor-Oberfläche umgestiegen ist, bleibt bootstrap_grids als Brücke im Einsatz - mit klarem Ablaufdatum.

Ein viertes Szenario ist die Notfall-Lösung in einem Audit. Wenn eine bestehende Website ohne Spalten-Layouts auskommt und nachträglich einzelne Seiten mehrspaltig dargestellt werden sollen, ist bootstrap_grids die schnellste Antwort: Installation, Aktivierung, erste Seite mit zweispaltigem Content-Bereich in unter einer Stunde. Für längerfristige Nutzung ist diese Abkürzung aber selten die richtige Wahl.

## Technische Architektur

bootstrap_grids registriert eigene Content-Elemente über TCA-Overrides und liefert Fluid-Templates für die Grid-Ausgabe. Im Kern sind die Elemente ein dünner Wrapper um die Bootstrap-Klassen `container`, `row` und `col-*`. Die Extension pflegt eigene Spalten-Container, die per Colpos im Backend-Layout sichtbar werden, und bindet bei Bedarf Bootstrap-CSS mit ein.

Die Installation erfolgt klassisch über Composer. In Kombination mit eigenen Site Packages gilt: bootstrap_grids bringt ein vollständiges Bootstrap-5-CSS und zugehöriges JavaScript mit, was bei Projekten mit eigenem Design-System schnell zu Konflikten und doppeltem CSS-Laden führt. In diesen Fällen werden die bootstrap_grids-Ressourcen deaktiviert und nur die Backend-Integration verwendet.

Die Konfiguration erfolgt über TsConfig: Hier legen Teams fest, welche Grid-Varianten Redakteuren angeboten werden, welche Spaltenzahlen zulässig sind und welche Bootstrap-Breakpoints abgebildet werden. Eine saubere Beschränkung auf wenige, klar benannte Varianten reduziert die Backend-Verwirrung erheblich.

## Häufige Probleme und Lösungen

Das erste Problem ist die Copy-Paste-Falle in der Redaktion. Ohne strikte Governance entstehen mit bootstrap_grids schnell Seiten mit acht verschachtelten Containern, die niemand mehr wartet. Die Lösung ist eine Begrenzung der erlaubten Varianten und eine Redaktionsrichtlinie, die die Nutzung von Spalten-Layouts an klare Inhaltstypen koppelt.

Das zweite Problem ist die Doppel-Ladung von Bootstrap-CSS. Projekte, die neben bootstrap_grids ein eigenes Bootstrap-Build pflegen, laden Bootstrap im schlimmsten Fall zweimal. Die Lösung ist, die von der Extension mitgelieferten Ressourcen über TsConfig komplett zu deaktivieren und ausschliesslich das projekteigene Build zu verwenden.

Das dritte Problem ist die Migration bei TYPO3-Upgrades. Wer von v9 auf v11 oder von v11 auf v12 wechselt, stellt fest, dass einige Grid-Varianten in älteren Bootstrap-Versionen anders heissen. Die Lösung ist ein Audit der verwendeten Grid-Typen vor dem Upgrade und ein gezielter SQL-Migrations-Lauf, der alte Varianten auf neue Bezeichnungen umschreibt.

Ein viertes Problem ist die inkonsistente Darstellung in der Editor-Vorschau. Das Backend zeigt Grid-Container oft leer oder in einer reduzierten Form, sodass Redakteurinnen nicht erkennen, was im Frontend tatsächlich ausgegeben wird. Die Lösung sind Preview-Renderings direkt im Backend-Modul, die die Bootstrap-Klassen nachbilden und die Spaltenbreiten visuell anzeigen. Der Aufwand dafür ist nicht trivial, zahlt sich aber bei grossen Redaktionsteams schnell aus.

## Migration und Versions-Kompatibilität

bootstrap_grids existiert für TYPO3 v9 bis v12 und wird weiter gepflegt, der offizielle Stand für TYPO3 v13 wurde 2025 nachgezogen. Wichtiger als die reine Versions-Kompatibilität ist jedoch die strategische Frage, ob bootstrap_grids im Projekt überhaupt noch die richtige Antwort ist. Für Neuprojekte empfiehlt sich EXT:container: leichter, näher am Core, einfacher zu pflegen. Für Bestandsprojekte ist ein schrittweiser Umstieg oft sinnvoll - insbesondere wenn das Design-System ohnehin überarbeitet wird.

Gosign migriert bestehende bootstrap_grids-Projekte auf EXT:container oder auf native Backend-Layouts mit Colpos. Die Migration läuft scriptgestützt: Die vorhandenen Grid-Container werden per SQL und Upgrade-Wizard in Container-Strukturen umgeschrieben, sodass Redakteurinnen nach dem Upgrade keine Seite neu anfassen müssen. Das ist der schnellste Weg, ein historisches Site Package in den modernen TYPO3-Standard zu überführen, ohne dass Inhalte verloren gehen.

--- cHash TYPO3 - Cache-Konfiguration | Gosign ---
> cHash-Konfiguration für TYPO3: Steuert, welche URL-Parameter den Seiten-Cache beeinflussen. Falsche cHash-Konfiguration führt zu „Page not.

## Die meisten "Page not found"-Fehler in TYPO3 sind cHash-Probleme

Ein Redakteur legt eine Nachricht mit Paginierung an, die Seite funktioniert. Ein Besucher klickt auf Seite 2, sieht "Page not found". Der Entwickler prüft das Routing, die Seitenkonfiguration, die .htaccess. Alles korrekt. Das Problem sitzt tiefer: TYPO3s cHash-Mechanismus hat den URL-Parameter der Paginierung nicht erwartet und verweigert die Auslieferung. Ein 5-Minuten-Problem, wenn man weiß, wo man suchen muss, ein 2-Tage-Problem, wenn nicht.

cHash (Cache Hash) ist TYPO3s Mechanismus zur Sicherung des Seiten-Caches. Er berechnet einen Hash aus allen URL-Parametern und vergleicht ihn mit dem gespeicherten Cache-Eintrag. Wenn ein unbekannter Parameter auftaucht, den TYPO3 nicht erwartet, wird die Seite nicht ausgeliefert. Das schützt vor Cache-Poisoning, verursacht aber bei fast jeder neuen Extension oder jedem Custom-Filter Probleme.

## Typische Einsatzszenarien

**Filter- und Facettensuche in Produktkatalogen.** Ein Produktkatalog mit 6 Filterkriterien (Kategorie, Preis, Farbe, Material, Verfügbarkeit, Bewertung) erzeugt URL-Parameter wie `&tx_catalog[color]=red&tx_catalog[price]=100-200`. Ohne cHash-Konfiguration zeigt TYPO3 bei jeder Filterkombination "Page not found". Die cHash-Konfiguration muss jeden dieser Parameter kennen, entweder als "required" (beeinflusst den Cache-Key) oder als "excluded" (wird ignoriert und nicht gehasht).

**Paginierung in News- und Event-Listen.** EXT:news und EXT:sf_event_mgt nutzen eigene URL-Parameter für Seitenzahlen (`&tx_news_pi1[@widget_0][currentPage]=2`). Diese Parameter müssen in der cHash-Konfiguration stehen, damit Seite 2 einen eigenen Cache-Eintrag erhält. Fehlt die Konfiguration, wird entweder immer Seite 1 aus dem Cache geliefert (Cache-Pollution) oder die Paginierung schlägt mit 404 fehl.

**Tracking-Parameter und UTM-Tags.** Marketing-Kampagnen hängen UTM-Parameter an URLs: `?utm_source=newsletter&utm_medium=email`. Ohne Ausschluss dieser Parameter erzeugt jeder Kampagnen-Link einen neuen Cache-Eintrag. Bei einer Website mit 500 Seiten und 10 Kampagnen entstehen statt 500 plötzlich 5.000 Cache-Einträge, die den Server belasten und den Cache-Warmup verlangsamen. UTM-Parameter gehören auf die Exclude-Liste.

## Technische Architektur

Die cHash-Berechnung findet in TYPO3s Core-Klasse `CacheHashCalculator` statt. Der Algorithmus nimmt alle URL-Parameter, sortiert sie alphabetisch, serialisiert sie und berechnet einen MD5-Hash. Dieser Hash wird als `cHash`-Parameter an die URL angehängt. Beim Seitenaufruf prüft TYPO3, ob der mitgelieferte cHash mit dem berechneten übereinstimmt.

Die Konfiguration erfolgt in `$GLOBALS['TYPO3_CONF_VARS']['FE']['cacheHash']` mit vier Listen:

`cachedParametersWhiteList`: Parameter, die in den Hash einfließen und eigene Cache-Einträge erzeugen. Typisch: Plugin-Parameter (`tx_news_pi1`, `tx_solr`).

`excludedParameters`: Parameter, die komplett ignoriert werden. Typisch: Tracking-Parameter (`utm_source`, `utm_medium`, `utm_campaign`, `utm_content`, `utm_term`, `gclid`, `fbclid`).

`requireCacheHashPresenceParameters`: Parameter, die einen cHash zwingend erfordern. Wenn dieser Parameter ohne cHash in der URL steht, zeigt TYPO3 einen 404-Fehler. Das ist der restriktivste Modus.

`excludedParametersIfEmpty`: Parameter, die nur ignoriert werden, wenn sie leer sind.

Seit TYPO3 v12 lässt sich die cHash-Konfiguration auch über die Site Configuration (config.yaml) steuern, was die Verwaltung in Multi-Site-Setups vereinfacht.

## Häufige Probleme und Lösungen

**"Page not found" nach Extension-Installation.** Neue Extensions bringen eigene URL-Parameter mit. Wenn diese nicht in der cHash-Konfiguration stehen, blockiert TYPO3 die Seite. Lösung: Die Extension-Dokumentation prüfen (gute Extensions liefern cHash-Konfiguration in `ext_localconf.php` mit). Falls nicht: die Parameter manuell in die cachedParametersWhiteList oder excludedParameters eintragen. Im TYPO3 Install Tool unter "Presets" bietet der cHash-Debug-Modus eine Hilfestellung.

**Cache-Pollution durch unkontrollierte Parameter.** Bots und Spam-Crawler hängen zufällige Parameter an URLs. Ohne Schutz erzeugt jeder dieser Aufrufe einen Cache-Eintrag. Der Cache wächst auf Millionen Einträge, die Datenbank wird langsam. Lösung: `excludeAllEmptyParameters = true` setzen und nur explizit bekannte Parameter in die WhiteList aufnehmen. Zusätzlich den Cache-Garbage-Collector auf kürzere Intervalle stellen (Standard: 86.400 Sekunden = 24 Stunden).

**cHash-Fehler schwer zu debuggen.** TYPO3 zeigt nur "Page not found", nicht warum. Im Production-Modus gibt es keine Fehlermeldung, die auf cHash hinweist. Lösung: In `LocalConfiguration.php` temporär `$GLOBALS['TYPO3_CONF_VARS']['FE']['pageNotFoundOnCHashError'] = false` setzen. Dann zeigt TYPO3 die Seite trotz cHash-Fehler an und loggt den Fehler. Nach der Diagnose wieder auf true setzen.

## Migration und Versions-Kompatibilität

cHash ist Core-Funktionalität, keine Extension, und existiert seit TYPO3 v4. Die Konfiguration hat sich über die Versionen verändert: In TYPO3 v8 und früher wurde sie über TypoScript gesteuert, ab v9 über PHP-Arrays in der LocalConfiguration, ab v12 zusätzlich über die Site Configuration.

Bei der Migration von TYPO3 v9/v10 auf v12/v13 müssen bestehende cHash-Konfigurationen geprüft werden. Die Parameter-Namen der Extensions können sich geändert haben (z.B. Extbase-Plugin-Namespace-Änderungen). Der sicherste Weg: Nach dem Upgrade alle Seiten mit Parametern systematisch testen (Paginierung, Filter, Suche) und das TYPO3 Error Log auf cHash-Einträge prüfen.

TYPO3 v13 verschärft die cHash-Prüfung weiter: Unbekannte Parameter führen standardmäßig zu einem 404, der Debug-Modus muss explizit aktiviert werden. Gosign prüft bei jedem TYPO3-Upgrade-Projekt die cHash-Konfiguration als Teil des Qualitätssicherungs-Prozesses.

--- calendarize_news TYPO3 - Kalender | Gosign ---
> Kalender-Ansicht für GeorgRinger/news: Wiederkehrende Events, Datumsfilter, Monats-/Wochen-/Tagesansicht. Verbindet die News-Extension.

## Events in tx_news gehören in einen Kalender, nicht in eine chronologische Liste

Die meisten TYPO3-Websites nutzen Georg Ringers tx_news für alles: Nachrichten, Blog-Artikel, Pressemitteilungen und Events. Für die ersten drei Typen funktioniert die chronologische Listendarstellung. Für Events nicht. Besucher erwarten eine Kalenderansicht mit Monats-, Wochen- und Tagesdarstellung. Sie wollen auf ein Datum klicken und sehen, was an diesem Tag stattfindet. calendarize_news baut genau diese Brücke: Es nimmt bestehende News-Datensätze mit Datumsfeldern und rendert sie als Kalender.

Die Extension spart den Umstieg auf ein eigenständiges Event-System. Wer tx_news bereits im Einsatz hat, behält seine Datenstruktur, seine Templates und seine Redaktionsprozesse. Statt einer zweiten Extension mit separater Datenhaltung gibt es eine Kalender-View auf bestehende Daten.

## Typische Einsatzszenarien

**Veranstaltungskalender auf Unternehmenswebsites.** Ein Bildungsträger veröffentlicht 150 Seminare pro Jahr über tx_news. Jedes Seminar hat ein Startdatum, ein Enddatum und eine Uhrzeit. Ohne calendarize_news sehen Besucher eine lange Liste, sortiert nach Datum. Mit calendarize_news sehen sie einen Monatskalender, klicken auf den 15. Mai und finden drei Seminare. Die Conversion von der Kalenderansicht zur Detailseite lag bei einem Kunden 40% höher als von der Listenansicht.

**Wiederkehrende Events ohne Daten-Duplikation.** Ein wöchentlicher Stammtisch, ein monatliches Webinar, ein jährliches Firmenfest: Ohne Recurrence-Funktionalität muss der Redakteur 52 Datensätze für den Stammtisch anlegen. calendarize_news unterstützt Wiederholungsregeln (täglich, wöchentlich, monatlich, jährlich) mit Ausnahmen. Ein Datensatz erzeugt 52 Kalendereinträge. Fällt ein Termin aus, wird er als Ausnahme markiert, nicht gelöscht.

**Kombinierte News- und Event-Seiten.** Viele Organisationen zeigen auf der Startseite "Aktuelles", eine Mischung aus Nachrichten und anstehenden Events. calendarize_news ermöglicht es, dieselben Datensätze in der News-Liste chronologisch und im Kalender datumbasiert darzustellen. Zwei Views, eine Datenquelle, kein Synchronisationsaufwand.

## Technische Architektur

calendarize_news erweitert tx_news um zusätzliche Datenbankfelder in der Tabelle `tx_news_domain_model_news`: Startdatum, Enddatum, Ganztags-Flag, Wiederholungsregel und Ausnahme-Daten. Die Wiederholungslogik ist in der Extension implementiert und generiert virtuelle Termine zur Laufzeit, ohne für jeden Einzeltermin einen Datensatz in der Datenbank anzulegen.

Die Kalenderdarstellung erfolgt über Fluid-Templates, die ein Monats-Grid rendern. Jede Zelle (Tag) enthält die Events dieses Tages. Die Templates sind vollständig anpassbar. Standardmäßig liefert die Extension Templates für Monats-, Wochen- und Tagesansicht. Die Navigation zwischen Monaten erfolgt per AJAX oder klassischem Seitenaufruf, konfigurierbar per TypoScript.

Die Integration mit tx_news ist tief: calendarize_news registriert sich als zusätzliches Plugin (list type) und nutzt tx_news' Repository-Pattern. Kategorien, Tags und Zugriffsbeschränkungen aus tx_news werden übernommen. Ein Event, das der Kategorie "Intern" zugeordnet ist und nur für eingeloggte Benutzer sichtbar sein soll, erscheint auch im Kalender nur nach Login.

Die iCal-Export-Funktion generiert .ics-Dateien für einzelne Events oder den gesamten Kalender. Besucher können Events direkt in Outlook, Apple Kalender oder Google Calendar importieren. Der Export nutzt das iCalendar-Format (RFC 5545) und berücksichtigt Wiederholungsregeln.

## Häufige Probleme und Lösungen

**Kalender zeigt keine Events, obwohl News vorhanden sind.** Häufigste Ursache: Die Datumsfelder der News-Datensätze sind nicht befüllt. tx_news hat ein `datetime`-Feld, aber calendarize_news nutzt eigene Felder für Start- und Enddatum. Nach der Installation müssen bestehende News-Datensätze um die calendarize-Felder ergänzt werden. Lösung: Ein Migrations-Script, das `datetime` in die calendarize-Felder kopiert, dauert 30 Minuten Entwicklungszeit.

**Performance-Probleme bei vielen wiederkehrenden Events.** Wenn 50 wiederkehrende Events jeweils 52 virtuelle Termine erzeugen, muss die Extension 2.600 Einträge für die Monatsansicht filtern. Das ist bei jedem uncached Seitenaufruf spürbar. Lösung: Die Recurrence-Berechnung cachen (calendarize_news unterstützt TYPO3s Caching Framework) und die Zeitspanne begrenzen. Events, die mehr als 12 Monate in der Zukunft liegen, müssen nicht bei jedem Request berechnet werden.

**Responsive Darstellung des Kalender-Grids.** Ein 7-Spalten-Grid für Wochentage funktioniert auf Desktop, aber nicht auf Smartphones. Die Standard-Templates von calendarize_news sind nicht mobil-optimiert. Lösung: Die Fluid-Templates anpassen und auf mobilen Geräten eine Listen-Darstellung statt des Grids rendern. Ein CSS-Breakpoint bei 768px reicht aus, um zwischen Grid und Liste zu wechseln.

## Migration und Versions-Kompatibilität

calendarize_news hängt direkt von tx_news ab und folgt dessen Versions-Zyklus mit Verzögerung. Die aktuelle stabile Version unterstützt TYPO3 v11 und v12 mit tx_news v10/v11. Für TYPO3 v13 existiert eine Beta-Version auf GitHub.

Die Alternative calendarize (ohne _news-Suffix) von lochmueller ist eine eigenständige Kalender-Extension, die nicht auf tx_news aufbaut, sondern ein eigenes Datenmodell mitbringt. Sie wird aktiver gepflegt und unterstützt TYPO3 v12 und v13 offiziell. Der Umstieg von calendarize_news auf calendarize erfordert eine Datenmigration: Die Event-Daten müssen aus der tx_news-Tabelle in die calendarize-Tabellen überführt werden.

Für Projekte, die auf TYPO3 v13 migrieren und tx_news behalten wollen, ist der pragmatischste Weg: die calendarize_news-Beta einsetzen oder die Kalenderdarstellung als Custom Fluid-Template direkt in tx_news bauen. Der Aufwand für ein Custom-Template liegt bei 2-3 Tagen, das Ergebnis ist unabhängig von Drittanbieter-Pflege. Gosign hat beide Wege umgesetzt und empfiehlt je nach Komplexität der Wiederholungsregeln die passende Variante.

--- camaliga TYPO3 - Flexible Listen | Gosign ---
> Flexibles Listen-Plugin für TYPO3: Produkte, Mitarbeiter, Referenzen, alles über eine Extension konfigurierbar. Alternative zu Custom Extensions.

## Für die meisten Listen in TYPO3 braucht man keine eigene Extension

Ein Unternehmen will Referenzen auf der Website zeigen: Logo, Kundenname, Branche, Kurzbeschreibung. Ein anderes will Mitarbeiter auflisten: Foto, Name, Abteilung, Telefon. Ein drittes braucht eine Produktübersicht: Bild, Titel, Preis, Link zur Detailseite. Drei verschiedene Anforderungen, ein gemeinsames Muster: strukturierte Listen mit konfigurierbaren Feldern. camaliga löst dieses Muster als generische Listen-Extension, statt für jeden Listentyp eine Custom Extension zu entwickeln.

Die Extension von quizpalme ist seit Jahren im TYPO3 Extension Repository verfügbar und wird aktiv gepflegt. Ihr Vorteil: Ein Datensatz-Typ mit flexiblen Feldern deckt 80% aller Listen-Anforderungen ab. Der Nachteil: Wer sehr spezifische Datenmodelle braucht (verschachtelte Relationen, Mehrsprachigkeit auf Feldebene, komplexe Validierung), stößt an Grenzen.

## Typische Einsatzszenarien

**Referenz- und Kundenlisten.** Der häufigste Einsatz: Logos und Beschreibungen von Kunden oder Projekten in einer Grid-Darstellung. camaliga bringt fertige Layouts mit: Grid, Karussell, Akkordeon, Tab-Darstellung. Die Daten werden im TYPO3-Backend als Datensätze gepflegt, die Darstellung über Fluid-Templates gesteuert. Bei einem Kunden mit 120 Referenzen war die camaliga-basierte Referenzseite in 3 Tagen live, inklusive Filterung nach Branche.

**Team- und Mitarbeiterseiten.** Foto, Name, Position, Kontaktdaten, optional ein Kurztext. camaliga bildet das über seine Standard-Felder ab: Titel, Untertitel, Bild, Beschreibung, Link. Für zusätzliche Felder (Telefonnummer, Abteilung) lassen sich Custom-Felder über TCA-Override ergänzen. Die Alternative wäre EXT:tt_address, die aber auf Adressdaten spezialisiert ist und für Teamseiten oft zu viel und gleichzeitig zu wenig bietet.

**Einfache Produktübersichten ohne Shop-Funktionalität.** Unternehmen, die Produkte darstellen, aber nicht verkaufen wollen, brauchen keinen Shop. camaliga liefert eine Produktliste mit Bild, Titel, Preis-Feld und Link zum Datenblatt. Filterung nach Kategorie ist über die integrierte Kategorie-Zuordnung möglich. Für 50-200 Produkte ohne Warenkorb ist das effizienter als Aimeos oder bernetshop.

## Technische Architektur

camaliga basiert auf Extbase/Fluid und folgt dem MVC-Pattern. Der zentrale Datensatz-Typ heißt `tx_camaliga_domain_model_content` und enthält Felder für Titel, Untertitel, Beschreibung, Kurzbeschreibung, Bild, Link, Kategorie und mehrere Custom-Felder. Die Felder sind im TCA definiert und lassen sich über TCA-Override im Sitepackage erweitern oder reduzieren.

Die Darstellung erfolgt über ein Frontend-Plugin mit konfigurierbarem Layout. Im Plugin-FlexForm wählt der Redakteur: Welche Kategorie anzeigen, welches Layout verwenden, wie viele Einträge pro Seite, ob Paginierung aktiv ist. Die Layouts sind Fluid-Templates, die im Sitepackage überschrieben werden. camaliga liefert circa 15 fertige Layouts mit, von der einfachen Liste bis zum gefilterten Grid mit Isotope-Animation.

Die Kategorie-Filterung nutzt TYPO3s System-Kategorien. Jeder camaliga-Datensatz kann einer oder mehreren Kategorien zugeordnet werden. Im Frontend wird ein Filter-Menü generiert, das per JavaScript (Isotope oder CSS-Filter) oder per Seitenaufruf filtert. Die JavaScript-Variante ist schneller, die Seitenaufruf-Variante SEO-freundlicher.

Für die Sortierung bietet camaliga mehrere Optionen: nach Titel, nach Erstellungsdatum, nach manueller Sortierung (Drag-and-Drop im Backend). Die manuelle Sortierung nutzt das `sorting`-Feld der Datenbank und funktioniert über TYPO3s Standard-Sortierungsmechanismus im List-Modul.

## Häufige Probleme und Lösungen

**Layouts sehen anders aus als erwartet.** camalias mitgelieferte Layouts setzen auf bestimmte CSS-Frameworks (Bootstrap 3/4) oder JavaScript-Libraries (Isotope, Masonry). Wenn die Website ein anderes Framework nutzt, kollidieren die Styles. Lösung: Nie die Standard-Templates verwenden, sondern eigene Fluid-Templates im Sitepackage anlegen. Der Aufwand für ein eigenes Template liegt bei 1-2 Stunden, danach ist die Darstellung vollständig kontrollierbar.

**Performance bei mehr als 500 Datensätzen.** camaliga lädt standardmäßig alle Datensätze einer Kategorie und filtert im Frontend per JavaScript. Bei 500+ Einträgen wird die initiale Ladezeit spürbar (3-5 Sekunden bei 1.000 Datensätzen mit Bildern). Lösung: Paginierung aktivieren und die Seitenanzahl auf 20-50 Einträge begrenzen. Für JavaScript-basierte Filterung: Lazy Loading der Bilder aktivieren und die Datenmenge per AJAX nachladen.

**Mehrsprachigkeit erfordert Workaround.** camaliga unterstützt TYPO3s Sprachhandling, aber die Übersetzung jedes einzelnen Datensatzes ist bei 200+ Einträgen aufwändig. Lösung: Für rein visuelle Listen (Logos ohne Text) reicht ein Datensatz pro Sprache. Für textlastige Listen die Übersetzung per TYPO3s Inline-Translation-Workflow beschleunigen oder ein Migrations-Script schreiben, das DeepL-API-Übersetzungen in die Sprachversionen importiert.

## Migration und Versions-Kompatibilität

camaliga wird aktiv gepflegt und unterstützt TYPO3 v11, v12 und nach aktueller Roadmap auch v13. Die Extension folgt dem TYPO3-Release-Zyklus mit kurzer Verzögerung. Composer-Installation über Packagist ist möglich, TER-Installation ebenfalls.

Wer von einer Custom Extension auf camaliga migriert, muss die Daten aus der Custom-Tabelle in `tx_camaliga_domain_model_content` überführen. Das ist ein SQL-Job, der sich in den meisten Fällen in unter einem Tag erledigen lässt. In die andere Richtung: Wer von camaliga auf eine eigene Extbase-Extension umsteigt, kann die Datenstruktur als Vorlage nutzen.

Für komplexere Anforderungen (verschachtelte Datensätze, Relationen zwischen Listen, Workflow-Steuerung) empfiehlt sich statt camaliga eine Custom Extbase Extension oder EXT:mask. Gosign berät zur passenden Lösung und implementiert sowohl camaliga-basierte Schnelllösungen als auch individuelle Extensions.

--- CAPTCHA TYPO3 - Spam-Schutz | Gosign ---
> Spam-Schutz für TYPO3-Formulare. Gosign berät zwischen sichtbaren CAPTCHAs (sr_freecap, hCaptcha), unsichtbaren (reCAPTCHA v3) und cookielosen.

## Warum die CAPTCHA-Entscheidung keine Technik-, sondern eine Datenschutzfrage ist

CAPTCHA klingt nach einer trivialen Entscheidung: Formular vor Bots schützen, Extension installieren, fertig. In der Praxis ist es die Frage, welchen Dienst man einbindet, welche Einwilligung man erzeugt und welche Conversion-Rate man akzeptiert. Für TYPO3 existieren ein Dutzend Ansätze, die sich in drei Gruppen teilen: sichtbare CAPTCHAs mit visueller Aufgabe, unsichtbare Verhaltensanalysen wie reCAPTCHA v3 und rein serverseitige Methoden ohne Nutzerinteraktion wie Honeypots oder Rate-Limiting. Die richtige Wahl hängt weniger von der Bot-Stärke ab als von der regulatorischen Ausgangslage und der Zielgruppe des Formulars.

## Typische Einsatzszenarien

Ein B2B-Softwareanbieter betreibt ein Kontaktformular mit rund 300 echten Anfragen pro Monat und etwa 8.000 Bot-Einreichungen. Der Anbieter nutzt bereits Google Analytics, hat eine Consent-Lösung laufen und verliert keine rechtliche Grundlage, wenn er reCAPTCHA v3 einbaut. In diesem Fall ist die unsichtbare Lösung effektiv: Bots werden hinter den Kulissen blockiert, echte Nutzer sehen nichts, die Conversion-Rate bleibt stabil. Die Einwilligung kommt ohnehin schon über den bestehenden Consent-Banner.

Eine kommunale Verwaltung mit Online-Formularen für Bürgeranliegen hat die gegenteilige Ausgangslage: Google darf nicht eingebunden werden, Consent-Banner sollen minimal sein, und das Formular muss auch ohne JavaScript funktionieren. Hier scheidet reCAPTCHA sofort aus. Die Kombination Honeypot plus Rate-Limiting auf dem Reverse-Proxy plus einer einfachen Rechenaufgabe im Formular fängt 95 Prozent der Bots, benötigt keine externe Ressource und erzeugt keine Einwilligungspflicht.

Ein dritter Fall ist eine Bildungseinrichtung mit stark variierender Nutzerschaft: Studierende, Lehrende, externe Bewerber, zum Teil mit Sehbehinderung. Hier ist Barrierefreiheit wichtiger als jeder Sicherheitsgewinn, und ein rein visuelles CAPTCHA ist problematisch. Die Lösung ist ein hCaptcha-Setup mit aktiviertem Accessibility-Modus oder eine sr_freecap-Instanz mit Audio-Alternative, ergänzt um eine vollständige BITV-konforme Beschriftung.

## Technische Architektur: Drei Kategorien, drei Integrations-Muster

Sichtbare CAPTCHAs wie sr_freecap oder hCaptcha arbeiten über einen Request-Response-Mechanismus: Die Extension generiert oder bezieht eine Aufgabe, zeigt sie dem Nutzer, und beim Absenden wird die Eingabe serverseitig validiert. In TYPO3 erfolgt die Einbindung über einen Validator im Form Framework, über eine Fluid-ViewHelper-Erweiterung oder bei Powermail über das Captcha-Feld-Plugin. Die technische Herausforderung ist die Session-Synchronisation und die Integration in bestehende Fluid-Templates.

Unsichtbare CAPTCHAs wie reCAPTCHA v3 berechnen einen Score zwischen 0 und 1, der die Wahrscheinlichkeit beschreibt, dass die Anfrage menschlich ist. Der Score kommt als zusätzliches Feld mit dem Formular-Submit, und die Extension entscheidet anhand eines konfigurierbaren Schwellwerts, ob die Einreichung akzeptiert oder verworfen wird. Der große Vorteil ist, dass der Nutzer nichts bemerkt, der Nachteil ist die unumgehbare Datenübertragung an Google.

Honeypot-basierte Lösungen arbeiten ohne clientseitige Logik: Ein unsichtbares Eingabefeld wird dem HTML-Formular hinzugefügt, versteckt per CSS oder tabindex=-1. Menschen füllen es nicht aus, Bots tun es sehr oft, und serverseitig wird jede Einreichung mit gefülltem Honeypot verworfen. Ergänzt um Rate-Limiting auf IP-Basis und eine prüfbare Zeitspanne zwischen Seitenaufruf und Submit blockiert das die Mehrheit einfacher Bots, ohne einen einzigen Nutzer zu belästigen.

## Häufige Probleme und Lösungen

Das erste Problem ist die Auswahl selbst: Teams greifen reflexartig zu reCAPTCHA, weil es bekannt und gratis ist, und übersehen die Einwilligungspflicht. Die saubere Entscheidung erfordert eine kurze Bewertung: Welche Consent-Infrastruktur besteht? Welcher Nutzerkreis soll das Formular bedienen? Wie hoch ist die tatsächliche Bot-Last? Gosign führt diese Bewertung im Rahmen eines kurzen Audits durch und empfiehlt je Formular die passende Methode, statt eine Einheitslösung zu forcieren.

Das zweite Problem ist die Kombination mehrerer Schutzmechanismen. Wer Honeypot, CAPTCHA und Rate-Limiting parallel einsetzt, schafft Redundanz, aber auch Fehlerquellen: Ein legitimer Nutzer scheitert an einem der drei Schritte und verliert das Vertrauen in das Formular. Die pragmatische Antwort ist, Methoden abzustufen und nur den aufwändigsten Schutz bei verdächtigem Verhalten zu aktivieren, zum Beispiel ein CAPTCHA erst dann zu zeigen, wenn die Honeypot-Erkennung bereits angeschlagen hat oder mehrere Einreichungen von derselben IP innerhalb kurzer Zeit eingegangen sind.

Das dritte Thema ist Monitoring. Teams installieren einen Schutz und vergessen, dass die Wirksamkeit nachlässt, sobald Bots angepasste Verhaltensmuster entwickeln. Ein effektives CAPTCHA-Setup loggt Spam-Rate und Falsch-Positive-Rate und aktualisiert die Schwellen, wenn die Zahlen sich verändern. Gosign richtet dieses Monitoring im Rahmen der Extension-Integration ein und liefert eine monatliche Auswertung, sodass sichtbar wird, wann ein Anbieter-Wechsel oder eine Anpassung notwendig wird.

## Migration und Versions-Kompatibilität

In TYPO3 v12 und v13 ist das Form Framework der zentrale Integrationspunkt für CAPTCHA-Lösungen. Extensions, die noch auf dem alten FormBuilder oder dem mailform-Typ aus Core-Zeiten aufsetzen, müssen beim Upgrade auf das neue Framework umgebaut werden, was in der Regel auch eine Neuwahl des CAPTCHA-Ansatzes erzwingt. Powermail bleibt eine beliebte Alternative und liefert eigene CAPTCHA-Feldtypen, die parallel gepflegt werden.

Wer von reCAPTCHA auf eine DSGVO-freundliche Lösung migriert, spart nicht nur eine Consent-Pflicht, sondern gewinnt oft auch Ladezeit: Das reCAPTCHA-Skript ist mehrere Hundert Kilobyte groß und wird von jeder Seite nachgeladen, die ein Formular enthält. Ein Honeypot-Setup kommt ohne externes Skript aus. Gosign hat solche Migrationen mehrfach begleitet und liefert je nach Betriebsmodell entweder ein reines Honeypot-Setup oder eine Kombination mit einer lokalen Rechenaufgabe, die für Menschen trivial, für Bots jedoch eine spürbare Hürde darstellt.

--- Cloudinary TYPO3 - CDN & Bilder | Gosign ---
> Cloudinary als TYPO3 FAL-Treiber. Bilder automatisch optimieren (WebP/AVIF), transformieren (Crop, Resize) und über CDN weltweit ausliefern.

## Bilder sind der größte Performance-Killer auf TYPO3-Websites, und Cloudinary löst das automatisch

Bei 90% der TYPO3-Websites, die schlecht bei Core Web Vitals abschneiden, sind Bilder das Problem. Zu groß, falsches Format, keine responsiven Varianten, kein CDN. TYPO3s internes Image Processing (GraphicsMagick/ImageMagick) erzeugt zwar Thumbnails, aber keine Format-Optimierung (WebP/AVIF), keine intelligente Crop-Erkennung und keine automatische Auslieferung über ein weltweites CDN. Cloudinary als TYPO3 FAL-Treiber löst alle drei Probleme in einem Schritt.

Cloudinary speichert die Originalbilder in seiner Cloud, erzeugt on-the-fly optimierte Varianten und liefert sie über 300+ Edge-Locations weltweit aus. Ein Bild, das als 4 MB JPEG hochgeladen wurde, kommt beim Besucher als 120 KB AVIF an, automatisch, ohne dass der Redakteur etwas tun muss.

## Typische Einsatzszenarien

**Medienintensive Unternehmenswebsites.** Ein Automobilzulieferer mit 3.000 Produktbildern, davon jedes in 5 Varianten (Thumbnail, Listenbild, Detailbild, Zoom, Download), hat ohne Cloudinary 15.000 Dateien auf dem Server. Mit Cloudinary werden 3.000 Originale gespeichert, die 15.000 Varianten erzeugt Cloudinary bei Bedarf. Der Server-Speicher sinkt um 80%, die Ladezeiten um 60%. Der Largest Contentful Paint (LCP) verbesserte sich bei einem Kunden von 4,1 auf 1,3 Sekunden.

**Internationale Websites mit globalem Publikum.** Wenn Besucher aus Brasilien, Japan und Deutschland dieselbe Seite aufrufen, liefert Cloudinary die Bilder jeweils vom nächstgelegenen Edge-Server. Ohne CDN dauert das Laden eines 500 KB Bildes von einem Server in Frankfurt für einen Besucher in Tokio 2-3 Sekunden. Mit Cloudinary unter 200 Millisekunden.

**Redaktionelle Portale mit hohem Bildvolumen.** News-Portale und Magazine laden täglich neue Bilder hoch. Cloudinary entlastet den Upload-Prozess: Bilder werden direkt an Cloudinary gesendet (Upload Widget oder API), verarbeitet und erst der Referenzpfad in TYPO3 gespeichert. Das spart Server-Last und beschleunigt den Redaktions-Workflow.

## Technische Architektur

Die Cloudinary-Integration in TYPO3 erfolgt über einen FAL-Treiber (File Abstraction Layer Driver). Die Extension registriert sich als Storage-Treiber und überschreibt die Standard-Dateioperationen: Upload, Download, Löschen, Auflisten. Redakteure arbeiten im gewohnten TYPO3-Backend, sehen Bilder in der Filelist und fügen sie wie gewohnt in Content-Elemente ein.

Die URL-Generierung ist der Kern der Integration. Statt einer lokalen Datei-URL (`/fileadmin/images/produkt.jpg`) generiert der Treiber eine Cloudinary-URL mit Transformations-Parametern: `https://res.cloudinary.com/[cloud-name]/image/upload/f_auto,q_auto,w_800/produkt.jpg`. Die Parameter `f_auto` (automatische Formaterkennung: WebP für Chrome, AVIF für Firefox, JPEG für alte Browser) und `q_auto` (automatische Qualitätsanpassung) sind der Standard.

Transformationen werden über URL-Parameter gesteuert: Breite (`w_`), Höhe (`h_`), Crop-Modus (`c_fill`, `c_fit`, `c_thumb`), Fokuspunkt-Erkennung (`g_auto` erkennt Gesichter und wichtige Bildbereiche), Overlay und Wasserzeichen. Jede Kombination erzeugt eine eigene Variante, die Cloudinary beim ersten Aufruf generiert und anschließend cachet.

Die responsive Breakpoint-Generierung ist besonders wertvoll: Cloudinary analysiert ein Bild und berechnet die optimalen Breakpoints basierend auf der tatsächlichen visuellen Änderung zwischen den Größen. Statt fester Breakpoints bei 320, 768 und 1024 Pixeln liefert Cloudinary beispielsweise 347, 691, 1024, weil dort die visuell größten Unterschiede liegen. Das spart Bandbreite ohne sichtbaren Qualitätsverlust.

## Häufige Probleme und Lösungen

**Kosten-Kontrolle bei hohem Traffic.** Cloudinary rechnet nach Credits ab: Transformationen, Speicher und Bandbreite verbrauchen Credits. Der kostenlose Plan reicht für circa 25.000 Transformationen pro Monat. Eine TYPO3-Website mit 500 Seiten und 3.000 Bildern kann das im ersten Monat überschreiten, wenn der Cache leer ist. Lösung: Cloudinary-Cache-Invalidierung nur bei tatsächlichen Bildänderungen auslösen, nicht bei jedem Deploy. Den Fetch-Format auf `auto` stellen, damit Cloudinary nur die nötigen Formate generiert.

**Bildersuche im TYPO3-Backend ist langsam.** Der FAL-Treiber muss bei jeder Suche die Cloudinary-API abfragen. Bei 10.000+ Bildern dauert das spürbar. Lösung: Den TYPO3 FAL-Index als primäre Suchquelle nutzen und nur bei Bedarf gegen Cloudinary synchronisieren. Der Indexer-Scheduler sollte nachts laufen, nicht bei jedem Backend-Zugriff.

**Bestehende Bild-URLs ändern sich.** Nach der Migration von lokalem Speicher auf Cloudinary ändern sich alle Bild-URLs. Das betrifft SEO (Google Image Search), externe Verlinkungen und gecachte Seiten. Lösung: Cloudinary-URLs generieren und gleichzeitig 301-Redirects von den alten Pfaden auf die neuen URLs einrichten. TYPO3s EXT:redirects kann das automatisiert.

## Migration und Versions-Kompatibilität

Die offizielle TYPO3-Cloudinary-Extension auf GitHub unterstützt TYPO3 v11 und v12. Für v13 ist Kompatibilität in Arbeit. Die Extension wird von der TYPO3-Community gepflegt, nicht von Cloudinary selbst.

Die Migration von lokalem Speicher auf Cloudinary erfolgt in vier Schritten: erstens einen Cloudinary-Account anlegen und den API-Key konfigurieren, zweitens die bestehenden Dateien per Bulk-Upload (Cloudinary CLI oder API) hochladen, drittens die TYPO3 File Storage Konfiguration auf den Cloudinary-Treiber umstellen und viertens den FAL-Index neu aufbauen. Bei 5.000 Dateien dauert der gesamte Prozess circa einen Arbeitstag.

Cloudinary bietet einen kostenlosen Plan (25 Credits/Monat), der für kleine Websites ausreicht. Für Unternehmenswebsites mit 10.000+ Bildern und hohem Traffic liegt der Plus-Plan bei circa 89 USD/Monat. Gosign hat Cloudinary-Integrationen für TYPO3-Projekte mit bis zu 100.000 Bildern umgesetzt und berät zu Kosten-Optimierung und Transformations-Strategien.

--- CORS TYPO3 - Cross-Origin Header | Gosign ---
> Konfiguration von Cross-Origin Resource Sharing Headern für TYPO3. Notwendig für API-Zugriffe, Headless-TYPO3 oder Microservice-Architekturen.

## Warum Headless-TYPO3-Projekte ohne korrekte CORS-Konfiguration sofort scheitern

Sobald ein TYPO3-System nicht mehr nur HTML rendert, sondern JSON-APIs an JavaScript-Clients auf anderen Domains ausliefert, stößt der Browser an die Same-Origin-Policy. Ohne explizite Cross-Origin-Resource-Sharing-Header (CORS) blockiert er jeden Fetch-Aufruf, der von einer anderen Origin stammt als der API selbst. Für jeden Headless-TYPO3-Ansatz, jede Microservice-Integration und jedes Setup, bei dem ein Frontend auf app.example.com mit einem Backend auf cms.example.com spricht, ist eine saubere CORS-Konfiguration die Grundvoraussetzung. Sie gehört nicht in eine Extension allein, sondern ist ein Zusammenspiel aus TYPO3-Middleware, Webserver-Konfiguration und Reverse-Proxy-Setup.

## Typische Einsatzszenarien

Ein Versandhandel mit 40.000 Bestellungen pro Monat betreibt einen Produktkatalog in TYPO3 und ein React-basiertes Storefront auf einer separaten Domain. Das Storefront fragt Produktdaten, Lagerbestand und Preisinformationen über eine JSON-API ab, die als TYPO3-Middleware implementiert ist. Ohne korrekte CORS-Header blockiert der Browser jeden AJAX-Call mit der Fehlermeldung "has been blocked by CORS policy", und das Storefront bleibt leer. Die Lösung ist eine Middleware, die Access-Control-Allow-Origin präzise auf die bekannten Frontend-Domains setzt und Preflight-OPTIONS-Requests korrekt beantwortet.

Ein zweiter Fall ist ein Unternehmen, das TYPO3 als Content-Hub für mehrere Marken-Websites betreibt. Jede Marke hat eine eigene Domain, rendert aber bestimmte Module wie News-Listings oder Produktbilder clientseitig aus der zentralen TYPO3-Instanz nach. CORS muss hier so konfiguriert sein, dass alle Marken-Domains zulässig sind, fremde Domains aber nicht. Eine dynamische Origin-Prüfung gegen eine Whitelist in der TYPO3-Site-Konfiguration ist der richtige Ansatz, statt eines pauschalen Wildcards.

Der dritte Kontext sind Wissenschafts-Konsortien, die eine Forschungsdatenbank in TYPO3 pflegen und über eine offene API Forschungseinrichtungen weltweit den Zugriff ermöglichen. Hier ist die CORS-Policy bewusst offen, muss aber mit einer Authentifizierungsschicht kombiniert werden, sodass zwar jede Origin die API aufrufen darf, aber nur mit einem gültigen Token Daten zurückkommen.

## Technische Architektur: Middleware, PSR-15 und Preflight

In TYPO3 v12 und v13 ist der korrekte Ort für CORS-Header eine PSR-15-Middleware, die in die Request-Pipeline eingehängt wird. Sie prüft den Origin-Header des eingehenden Requests, vergleicht ihn mit einer konfigurierten Whitelist und setzt die passenden Access-Control-Allow-Origin-, Access-Control-Allow-Methods- und Access-Control-Allow-Headers-Header in die Response. Für POST-, PUT- oder DELETE-Requests mit Custom-Headern sendet der Browser zunächst einen OPTIONS-Preflight-Request, den die Middleware ohne Authentifizierung beantworten muss, sonst scheitert die eigentliche Anfrage.

Die Konfiguration lässt sich über die Site-Konfiguration als YAML-Array pflegen, alternativ direkt im ext_localconf.php der eigenen Extension. Wichtig ist, dass Credentials-Handling (Cookies, Authorization-Header) nur funktioniert, wenn Access-Control-Allow-Credentials auf true gesetzt ist und Access-Control-Allow-Origin auf eine konkrete Origin zeigt, nicht auf ein Wildcard. Diese Kombination ist CORS-Standard und häufige Fehlerquelle bei Teams, die zuerst mit Wildcard testen und dann später Credentials nachrüsten wollen.

## Häufige Probleme und Lösungen

Das erste Problem ist die doppelte Header-Setzung. Wenn TYPO3 einen Header setzt und Apache oder Nginx zusätzlich denselben Header in der Webserver-Konfiguration setzt, landen zwei Werte beim Browser, der den Request als fehlerhaft ablehnt. Die Lösung ist, CORS an genau einer Stelle zu definieren, entweder in der TYPO3-Middleware oder im Webserver, und die jeweils andere Stelle bewusst leer zu halten. Bei Reverse-Proxies wie Traefik oder Cloudflare kommt noch eine dritte Schicht hinzu, die ebenfalls Header manipulieren kann.

Das zweite Problem sind Preflight-OPTIONS-Requests. Der Browser sendet einen OPTIONS-Request, um vor dem eigentlichen Aufruf zu prüfen, ob die Methode erlaubt ist. TYPO3-Middlewares, die erst eine Authentifizierung durchführen und dann CORS-Header setzen, lehnen den OPTIONS-Request ab, weil er keinen Authorization-Header mitbringt. Die Lösung ist, Preflight-Requests in der Middleware-Kette früh abzufangen und ohne Auth zu beantworten.

Das dritte Thema ist die Kombination aus CORS und Caching. Ein Reverse-Proxy wie Varnish cached eine Response mit bestimmten CORS-Headern, und beim nächsten Aufruf von einer anderen Origin bekommt dieser die alten Header. Die Konsequenz ist, dass legitime Nutzer plötzlich CORS-Fehler sehen, weil sie eine gecachte Antwort für eine andere Origin erhalten. Ein Vary-Header auf Origin löst das Problem, zwingt aber den Cache zu mehreren Varianten pro Ressource.

## Migration und Versions-Kompatibilität

TYPO3 v11 bot noch keine saubere Middleware-API für alle Kontexte, sodass CORS-Konfiguration häufig über Hooks oder direkt im Webserver abgewickelt wurde. Ab v12 ist die PSR-15-Middleware der vorgesehene Weg, und der Migrationspfad von älteren Installationen besteht darin, vorhandene Header-Manipulationen aus der Apache- oder Nginx-Config in die TYPO3-Middleware zu verlagern.

Für Headless-Setups in TYPO3 v13 in Kombination mit der EXT:headless von Macopedia ist CORS ein elementarer Baustein und wird in der Extension-Dokumentation explizit behandelt. Gosign hat mehrere solcher Headless-Projekte realisiert und betreut bei Bedarf auch die Abstimmung zwischen Entwicklungsteams, die Frontend und Backend getrennt verantworten, sodass CORS-Regeln eindeutig dokumentiert sind und bei jeder Deployment-Änderung synchronisiert werden. Eine falsche Regel öffnet einen Angriffsvektor, in dem bösartige Websites im Namen des eingeloggten Nutzers Aktionen ausführen können, weshalb eine saubere Whitelist kein Komfort-Thema ist, sondern Sicherheitsanforderung.

Zu beachten ist außerdem, dass CORS kein Ersatz für Authentifizierung ist. Viele Entwickler-Teams konfigurieren großzügige CORS-Regeln in der Annahme, damit sei die API sicher, und vergessen, dass jede Origin, die der Browser erlaubt, denselben Zugriff hat wie ein direkt aufgerufener Client. Authentifizierung muss unabhängig von CORS über Tokens, API-Keys oder Session-Cookies erfolgen, und CORS sorgt lediglich dafür, dass Browser legitime Aufrufe an diese authentifizierten Endpunkte überhaupt zulassen. Wer diese Trennung versteht, konfiguriert CORS-Regeln deutlich restriktiver und schließt viele unbeabsichtigte Lücken.

--- Countdown TYPO3 - Timer-Extension | Gosign ---
> TYPO3 Extension für Countdown-Timer: Event-Countdowns, Produktlaunches, Angebotsfristen. Gosign baut auch CSS-only Countdowns.

## Countdown-Extensions lösen ein Kommunikationsproblem, das reine Texte nicht schaffen

Wenn eine Messe in 23 Tagen beginnt, wenn das Frühbucher-Angebot um Mitternacht abläuft oder wenn der neue Shop am 1. Mai live geht, reicht ein Satz wie "Nur noch wenige Tage" nicht. Nutzer reagieren auf tickende Uhren deutlich stärker als auf statische Daten, und auf einer TYPO3-Seite ist die einfachste Variante, einen sichtbaren Countdown-Timer einzubauen. Mehrere TYPO3-Extensions aus dem TER bieten diese Funktionalität, die bekannteste ist schlicht "countdown". Für jede Unternehmenswebsite mit Event-Ankündigungen, Produktlaunches oder befristeten Aktionen ist das eine wiederkehrende Anforderung, die ohne Extension meist in individuellem JavaScript landet. Die Wahl zwischen Extension und eigener Lösung hängt selten an der Technik, sondern an der Frage, wer den Countdown in der Redaktion pflegen können soll.

## Typische Einsatzszenarien reichen von Messen bis zu E-Commerce-Aktionen

Das erste Szenario sind Messen und Konferenzen. Ein Verband kündigt seine Jahrestagung sechs Monate im Voraus an und will den verbleibenden Zeitraum sichtbar machen, idealerweise mit Tagen, Stunden, Minuten und Sekunden. Der Countdown läuft auf der Landing-Page, schaltet sich in den letzten 24 Stunden um und verschwindet nach Veranstaltungsende automatisch, ohne dass ein Redakteur die Seite anpassen muss. Das spart nicht nur Pflegeaufwand, sondern verhindert auch peinliche Situationen wie einen Counter, der nach dem Event weiterhin einen negativen Wert anzeigt.

Ein zweites Szenario sind Produktlaunches und Vorbestell-Fenster. E-Commerce-Projekte auf Basis von aimeos oder externen Shops nutzen Countdowns auf Landing-Pages, um Kunden an den Starttermin zu binden. Bei Vorbestellungen dient der Countdown als Dringlichkeits-Signal und steigert nachweislich die Conversion.

Ein drittes Szenario sind Bewerbungs- und Antragsfristen. Hochschulen zeigen auf der Bewerbungsseite einen Countdown bis zum Fristende, Verbände nutzen ihn für Frühbucher-Preise, öffentliche Einrichtungen für Einreichfristen öffentlicher Ausschreibungen. Hier geht es nicht um Marketing, sondern um Service: Besucher sollen auf einen Blick erkennen, wie viel Zeit ihnen bleibt. Für Antragsportale im Wissenschaftsbereich ist das praktisch Standard, weil Förderanträge mit fixer Deadline und harter Cut-off-Zeit arbeiten.

## Technische Architektur läuft über eine Kombination aus Fluid-Template und Minimal-JavaScript

Klassische Countdown-Extensions in TYPO3 bestehen aus zwei Teilen. Der Backend-Teil ist ein Content-Element oder Plugin, in dem der Redakteur Zieldatum, Zielzeit, Zeitzone, Label und optional eine Endzeit-Nachricht pflegt. Der Frontend-Teil rendert diese Daten in ein Fluid-Template und hängt ein kleines JavaScript an, das die Differenz zum aktuellen Zeitpunkt berechnet und im DOM aktualisiert.

Die meisten Extensions bringen zusätzlich eine Konfiguration für das Rendering mit: Anzahl der Stellen (Tage, Stunden, Minuten, Sekunden), Darstellung als Kreisgrafik oder als Flip-Clock, Farben und Animation. Das JavaScript läuft typischerweise mit einem setInterval von 1000 ms und rechnet client-seitig, sodass der Server-Cache unverändert bleibt. Wichtig ist, dass der Timer nicht bei einem negativen Wert endet, sondern per Event eine "Event gestartet" oder "Angebot abgelaufen"-Nachricht anzeigt.

Für DSGVO-kritische Projekte lohnt sich ein Blick auf die JavaScript-Abhängigkeiten. Einige Extensions laden jQuery oder MomentJS nach, was zusätzlichen Renderpath verursacht. Moderne Varianten kommen mit ein paar Zeilen vanilla-JS und einem CSS-Grid aus, das auch ohne Extension funktioniert.

## Häufige Probleme betreffen Zeitzonen, Caching und SEO

Das häufigste Supportthema ist die Zeitzone. Der Redakteur trägt ein Datum im Backend ein, der Server steht auf UTC, der Besucher lebt in MEZ - und der Countdown zeigt eine Stunde zuviel an. Die Extension muss sauber zwischen Server-Zeit, Backend-Redaktionszeit und Browser-Zeit unterscheiden. Wir empfehlen immer, das Zieldatum in ISO-8601 mit expliziter Zeitzone ("2026-05-01T12:00:00+02:00") an das JavaScript zu übergeben.

Das zweite Problem ist das Page-Cache. Wenn die gerenderte HTML-Seite für eine Stunde gecached ist, darf der Countdown kein server-seitig berechnetes "23 Tage 7 Stunden" enthalten, weil der Cache-Hit diesen Wert einfriert. Die Lösung: Der Fluid-Teil rendert nur das Zieldatum als data-Attribut, die Differenz-Berechnung läuft ausschliesslich im Browser.

Drittens ist SEO ein Punkt. Ein reiner JavaScript-Countdown zeigt Google weder das Zieldatum noch den Anlass. Für Suchmaschinen gehört ein schema:Event-JSON-LD in die Seite, mit startDate, endDate und name, damit Google-Ergebnisse die Veranstaltung als Rich Snippet ausgeben. Wer die Extension einbaut, sollte also das Zieldatum nicht nur an den Timer übergeben, sondern zusätzlich als strukturierte Daten in den Seiten-Header schreiben. Ohne diese Auszeichnung bleibt der Countdown für Google unsichtbar und verliert seine Marketing-Wirkung schon im Suchergebnis.

## TYPO3 v12 und v13: Extension oder schlankes Alternativkonstrukt

Ob eine Countdown-Extension auf TYPO3 v12 und v13 noch sinnvoll ist, hängt vom Umfang des Projekts ab. Bei einer einzigen Event-Seite reicht ein kleines Content-Element mit einem data-Attribut und 30 Zeilen JavaScript, komplett ohne Extension-Overhead. Für Redaktionen mit vielen Events, die den Timer regelmässig selbst pflegen wollen, rechtfertigt sich die Extension, weil Redakteure ein bekanntes UI-Element im Backend brauchen.

Gosign baut in der Praxis beides: Für Einmal-Launches liefern wir ein schlankes Content-Element ohne Extension, das nur aus einem Fluid-Template und Mini-JS besteht. Für wiederkehrende Use-Cases integrieren wir eine gepflegte Extension und überschreiben das Fluid-Template, um das Design an das restliche Projekt anzupassen. Beim Upgrade alter countdown-Extensions ist fast immer ein Wechsel auf die vanilla-Variante sinnvoll, weil jQuery-basierte Altversionen weder in TYPO3 v12 noch auf modernen Performance-Budgets mithalten können.

--- DCE TYPO3 - Dynamic Content Elements | Gosign ---
> DCE: Custom Content Elements ohne PHP. Setup, Migration auf Mask/Container. KI-beschleunigte Entwicklung.

## DCE war jahrelang die erste Wahl für Custom Content Elements, jetzt steht die Migration an

Zwischen 2013 und 2020 war DCE (Dynamic Content Elements) neben Mask die populärste Methode, um eigene Content-Elemente in TYPO3 zu bauen. Redakteure bekamen Backend-Formulare mit genau den Feldern, die sie brauchten, Entwickler definierten alles per GUI, ohne eine Zeile PHP oder TCA zu schreiben. Tausende TYPO3-Websites laufen noch heute mit DCE. Das Problem: Die Weiterentwicklung hat sich deutlich verlangsamt. Mask hat DCE in der Nutzung überholt, und ab TYPO3 v13 steht mit dem nativen Content Block API eine dritte Alternative bereit, die keinen Extension-Overhead mehr benötigt.

Wer DCE im Einsatz hat, muss nicht sofort migrieren. Aber wer ein TYPO3-Upgrade auf v12 oder v13 plant, sollte die Ablösung einplanen, weil der langfristige Support unsicher ist.

## Typische Einsatzszenarien

**Bestandsprojekte mit 10 bis 50 DCE-Elementen.** Mittelständische Unternehmenswebsites, die zwischen 2014 und 2020 mit TYPO3 v7 bis v10 aufgebaut wurden, nutzen DCE für alles: Teaser-Boxen, Tabs, Akkordeons, Bildergalerien, Zitat-Blöcke, Team-Karten. Die Elemente funktionieren, sind aber an DCE gebunden. Bei einem TYPO3-Upgrade muss geprüft werden, ob DCE in der Zielversion noch läuft.

**Agenturen mit mehreren TYPO3-Projekten.** Agenturen, die DCE standardmässig in ihren Projekten eingesetzt haben, stehen vor der Frage: Migrieren wir alle Projekte auf einmal (grosser Aufwand, sauberer Schnitt) oder projekt-für-projekt beim nächsten Upgrade (kleinere Schritte, längerer Zeitraum)? Die Antwort hängt von der Anzahl der betroffenen Projekte und der geplanten TYPO3-Zielversion ab.

**Rapid Prototyping für Content-Elemente.** DCE eignet sich für schnelle Prototypen: Ein neues Content-Element ist in 15 Minuten konfiguriert, inklusive Backend-Formular und Fluid-Template. Für Proof-of-Concepts oder Kundenpräsentationen kann das ausreichen. Für produktive Projekte empfiehlt Gosign allerdings Mask, weil der Export-Workflow (mask_export) und die aktive Pflege langfristige Vorteile bieten.

## Technische Architektur

DCE speichert Content-Element-Definitionen in der Datenbank (Tabelle tx_dce_domain_model_dce), nicht in Dateien. Jedes DCE-Element besteht aus einer Konfiguration (Felder, Typen, Validierung), einem Fluid-Template (direkt im Backend oder als Dateiverweis) und optionalen Backend-Layouts. Die Felder werden in der DCE-GUI definiert: Text, RichText, Integer, Float, Datum, Datei (FAL), Select, Checkbox, Gruppe (IRRE), Section (wiederholbare Fieldsets).

Beim Speichern generiert DCE die nötige TCA-Konfiguration und registriert das Element im Content Element Wizard. Die Daten der Content-Elemente liegen in der tt_content-Tabelle, erweitert um DCE-spezifische FlexForm-Felder. Diese FlexForm-Architektur ist einer der Hauptunterschiede zu Mask, das eigene Datenbank-Spalten in tt_content anlegt.

Abhängigkeiten: DCE benötigt nur den TYPO3 Core. Optional kann DCE Container-Elemente erstellen (verschachtelte Content-Bereiche), was aber seit der Einführung der Container-Extension (b13/container) als separater Ansatz empfohlen wird.

## Häufige Probleme und Lösungen

**FlexForm-Daten sind schwer zu migrieren.** Weil DCE Daten als XML-FlexForm in tt_content speichert, ist eine Migration auf Mask (das eigene Spalten nutzt) nicht trivial. Die FlexForm-XML muss geparst und die Werte in die neuen Mask-Spalten überführt werden. Lösung: Ein Migrations-Skript, das pro DCE-Element die FlexForm-Felder ausliest und in die entsprechenden Mask-Felder schreibt. Gosign hat dafür ein wiederverwendbares CLI-Command, das den Prozess pro Element automatisiert.

**DCE-Container und verschachtelte Elemente.** DCE bietet eine eigene Container-Logik, die Content-Elemente ineinander verschachtelt. Diese Logik ist proprietär und wird von keinem anderen System verstanden. Lösung bei Migration: Container-Strukturen auf b13/container umstellen und die Kind-Elemente als Mask-Elemente nachbauen.

**Performance bei vielen DCE-Definitionen.** Websites mit 40+ DCE-Elementen haben spürbare Backend-Ladezeiten, weil alle FlexForm-Konfigurationen bei jedem Aufruf aus der Datenbank gelesen und geparst werden. Lösung: DCE-Caching aktivieren (TypoScript-Setting `plugin.tx_dce.enableCache = 1`) oder auf dateibasierte Konfiguration umstellen (DCE-Export-Funktion).

## Migration und Versions-Kompatibilität

DCE unterstützt TYPO3 v11 und v12. Die Kompatibilität mit TYPO3 v13 ist eingeschränkt: Es gibt einen Entwicklungszweig, aber keinen offiziell als stabil markierten Release (Stand April 2026). Die Community-Pflege ist weniger aktiv als bei Mask, wo in2code als Hauptentwickler einen klaren Release-Zyklus verfolgt.

Für die Migration von DCE auf Mask hat Gosign einen standardisierten Prozess: DCE-Elemente inventarisieren (Felder, Typen, Templates), Mask-Elemente 1:1 nachbauen, Daten per SQL-Skript migrieren (FlexForm-XML zu Mask-Spalten), Fluid-Templates anpassen (ViewHelper-Aufrufe und Variable-Namen ändern sich teilweise), testen und DCE deinstallieren. Der Aufwand liegt bei 0,5 bis 2 Stunden pro Element, je nach Komplexität. Ein Projekt mit 25 DCE-Elementen ist in 3 bis 5 Tagen migriert.

Alternativ können Projekte auf TYPO3 v13 direkt auf das native Content Block API umsteigen. Das setzt allerdings voraus, dass die Zielversion v13 ist und keine Abwärtskompatibilität zu v11/v12 benötigt wird.

Gosign empfiehlt bei der Migrationsentscheidung eine pragmatische Kosten-Nutzen-Rechnung. Wenn das nächste TYPO3-Upgrade innerhalb von 12 Monaten ansteht und DCE auf der Zielversion nicht stabil läuft, ist die Migration alternativlos. Wenn das Projekt noch 2 bis 3 Jahre auf TYPO3 v11 oder v12 bleiben soll und DCE dort stabil funktioniert, kann die Migration auf den nächsten Relaunch verschoben werden. In jedem Fall sollte schon jetzt festgelegt werden, ob Mask oder das Content Block API das Ziel ist, damit neue Content-Elemente direkt im Ziel-System erstellt werden und nicht weitere DCE-Abhängigkeiten entstehen.

Die Gesamtkosten einer DCE-Migration hängen von der Anzahl und Komplexität der Elemente ab. Ein Projekt mit 15 einfachen DCE-Elementen (Text, Bild, Link) ist in 2 Tagen migriert. Ein Projekt mit 40 Elementen, davon 10 mit IRRE-Verschachtelung und 5 mit Container-Logik, braucht 8 bis 12 Tage.

--- TYPO3 Templates & Sitepackages | Gosign ---
> Template-Paket für TYPO3. Gosign empfiehlt statt fertiger Templates immer Custom Sitepackages, exakt auf Ihre Anforderungen zugeschnitten, wartbar,.

## Fertige TYPO3-Templates sparen kurzfristig Zeit und kosten langfristig mehr

Die Versuchung ist groß: Ein fertiges TYPO3-Template für 79 Euro kaufen, installieren, Logo austauschen, fertig. In Wirklichkeit beginnt damit ein Kreislauf aus Workarounds, Overrides und Versionskonflikten, der jedes Update erschwert und die Weiterentwicklung bremst. dmpr_template steht exemplarisch für diese Kategorie. Gosign empfiehlt stattdessen Custom Sitepackages: individuelle Template-Pakete, die exakt auf die Anforderungen zugeschnitten, wartbar und versionierbar sind.

Ein Sitepackage ist eine TYPO3-Extension, die das komplette Frontend-Setup enthält: TypoScript, Fluid-Templates, Partials, Layouts, CSS/SCSS, JavaScript und Backend-Layouts. Es ist die offizielle TYPO3-Best-Practice seit Version 8 und ersetzt die alte Methode, Templates im Dateisystem zu konfigurieren.

## Typische Einsatzszenarien

**Unternehmens-Relaunch mit individuellen Anforderungen.** Ein Unternehmen startet einen Website-Relaunch. Das Design steht als Figma-Datei, die Informationsarchitektur als Sitemap, die Content-Typen sind definiert. Ein Custom Sitepackage übersetzt diese Vorgaben 1:1 in TYPO3: Jeder Content-Typ wird als Backend-Layout oder Custom Content Element abgebildet, die Fluid-Templates entsprechen dem Design pixelgenau. Kein Template-Framework steht dazwischen, das Kompromisse erzwingt.

**Multi-Site-Setup mit geteilten Komponenten.** Ein Konzern betreibt 5 Markenwebsites in einer TYPO3-Instanz. Alle teilen ein Basis-Sitepackage mit Grid-System, Typografie und Basis-Komponenten. Jede Marke hat ein eigenes Sitepackage, das die Basis-Extension erweitert: Farben, Logo, markenspezifische Layouts. Änderungen an der Basis wirken sich auf alle 5 Seiten aus, ohne dass 5 separate Codebases gepflegt werden müssen.

**Migration von alten Template-Setups.** TYPO3-Installationen aus der Version 6 oder 7 nutzen oft TemplaVoilà, Fluid Styled Content mit umfangreichen TypoScript-Overrides oder sogar Marker-basierte Templates. Die Migration auf ein sauberes Sitepackage modernisiert den gesamten Frontend-Stack in einem Schritt: weg von globalen TypoScript-Konfigurationen, hin zu einer versionierbaren Extension mit klarer Verzeichnisstruktur.

## Technische Architektur

Ein Sitepackage ist eine reguläre TYPO3-Extension mit einer definierten Verzeichnisstruktur:

`Configuration/TypoScript/` enthält die TypoScript-Konfiguration: Constants, Setup, Page-TSconfig. Hier wird definiert, welche Templates für welche Seitentypen gelten, welche Inhaltselemente verfügbar sind und wie sie gerendert werden.

`Resources/Private/Templates/` enthält die Fluid-Templates für die Seitentypen (Page), Inhaltselemente (ContentElements) und Partials (wiederverwendbare Template-Fragmente). Die Trennung in Templates, Partials und Layouts folgt TYPO3s Fluid-Konvention.

`Resources/Public/` enthält CSS/SCSS, JavaScript, Bilder und Fonts. Alles, was der Browser direkt ausliefert. In modernen Setups wird SCSS per Build-Tool (Vite, Webpack) kompiliert und die generierten Dateien in `Resources/Public/Build/` abgelegt.

`Configuration/TCA/` definiert Backend-Layouts und Custom Content Elements. Backend-Layouts steuern, welche Spalten und Bereiche auf einer Seite im Backend verfügbar sind. Custom Content Elements werden über TCA, TypoScript und Fluid-Templates definiert.

Das Sitepackage wird per Composer installiert und über die Site Configuration (config.yaml) der jeweiligen TYPO3-Site zugewiesen. Mehrere Sites können dasselbe Sitepackage nutzen (Multi-Site) oder jeweils ein eigenes haben.

## Häufige Probleme und Lösungen

**Fertig-Templates kollidieren mit TYPO3-Updates.** Gekaufte Templates überschreiben oft Core-Konfigurationen und TCA-Definitionen auf eine Weise, die bei TYPO3-Updates bricht. Ein Template, das für TYPO3 v10 entwickelt wurde, funktioniert nach dem Update auf v12 häufig nicht mehr, weil TCA-Wizards, Backend-Layout-Registrierung und Fluid-ViewHelpers sich geändert haben. Mit einem Custom Sitepackage kontrolliert man selbst, welche Core-Features genutzt werden, und kann Updates schrittweise durchführen.

**Sitepackage-Struktur wächst unkontrolliert.** Über Jahre sammeln sich in einem Sitepackage dutzende Partials, verwaiste Templates und TypoScript-Fragmente an. Lösung: Regelmäßiges Refactoring. Ein sauberes Sitepackage hat maximal 20-30 Partials, klare Naming-Conventions (PascalCase für Templates, Ordner nach Funktion) und keine ungenutzten Dateien. Der Aufwand für ein Refactoring liegt bei 2-5 Tagen, abhängig von der Größe.

**CSS-Spezifität-Konflikte mit Fluid Styled Content.** TYPO3s Fluid Styled Content bringt eigene CSS-Klassen mit (`ce-`, `frame-`). Wenn das Sitepackage eigene Klassen nutzt, entstehen Spezifitäts-Konflikte. Lösung: Entweder Fluid Styled Content komplett durch eigene Content-Element-Definitionen ersetzen (sauberer, aber aufwändiger) oder die Fluid Styled Content Templates überschreiben und die Klassen anpassen.

## Migration und Versions-Kompatibilität

Das Sitepackage-Konzept ist seit TYPO3 v8 der Standard und wird in jeder neuen TYPO3-Version weiterentwickelt. Die grundlegende Struktur (Extension mit TypoScript, Fluid-Templates, TCA) bleibt stabil. Anpassungen bei Major-Updates betreffen typischerweise TCA-Syntax (Wizards, renderTypes), TypoScript-Bedingungen (neu: Symfony Expression Language) und Backend-Modul-Registrierung.

Die Migration von einem Fertig-Template (dmpr_template, j77_template, in2template) auf ein Custom Sitepackage ist ein Rewrite, keine Portierung. Man analysiert die bestehenden Templates, extrahiert die gewünschte Funktionalität und baut sie in einer sauberen Sitepackage-Struktur neu auf. Bei einem typischen Projekt mit 10 Seitentypen und 15 Content-Elementen liegt der Aufwand bei 2-3 Wochen.

TYPO3 v13 führt Content Blocks als neues Konzept für Content-Element-Definitionen ein. Content Blocks vereinfachen die Erstellung von Custom Content Elements erheblich und reduzieren den Boilerplate-Code. Sitepackages bleiben davon unberührt, sie können Content Blocks zusätzlich nutzen. Gosign baut seit Jahren ausschließlich Custom Sitepackages und hat die Erfahrung, bestehende Template-Setups effizient auf moderne Strukturen zu migrieren.

--- Doodle-Alternative TYPO3 | Gosign ---
> Terminabstimmung direkt in TYPO3, wie Doodle, aber ohne externen Dienst. Datenschutzfreundlich, in die eigene Website integriert. Für interne.

## Terminabstimmungen gehören auf die eigene Website, nicht zu einem US-Dienst

Doodle ist praktisch: Link versenden, Teilnehmer wählen ihre Zeitslots, der Termin steht. Aber Doodle ist ein Drittanbieter mit Servern in den USA, mit Tracking, mit Werbung im Free-Tier. Für Unternehmen mit DSGVO-Bewusstsein, für öffentliche Einrichtungen und für jede Organisation, die keine Nutzerdaten an externe Dienste weiterleiten will, ist das ein Problem. Eine Doodle-Alternative direkt in TYPO3 löst dieses Problem: Terminabstimmung auf der eigenen Infrastruktur, ohne Drittanbieter-Cookies, ohne Datenabfluss.

Die Zielgruppe ist klar: Organisationen, die regelmäßig Termine mit externen Teilnehmern abstimmen (Elternabende, Gremiensitzungen, Workshops, Schulungstermine) und dabei die Kontrolle über die Daten behalten wollen.

## Typische Einsatzszenarien

**Bildungseinrichtungen mit Elternabend-Koordination.** Schulen und Kitas stimmen mehrmals pro Jahr Elternabende ab. 30 Familien sollen aus 5 möglichen Terminen den besten wählen. Über ein TYPO3-Plugin auf der Schulwebsite erfolgt die Abstimmung ohne Account-Pflicht und ohne externe Dienste. Die Ergebnisse bleiben auf dem Server der Schule. Bei einem Schulträger mit 12 Schulen und zusammen 6.000 Familien entfiel durch die TYPO3-Integration das Doodle-Premium-Abo (480 EUR/Jahr) komplett.

**Behörden und öffentliche Einrichtungen.** Kommunalverwaltungen und Landesbehörden dürfen oft keine Cloud-Dienste nutzen, die Daten außerhalb der EU verarbeiten. Eine TYPO3-basierte Terminabstimmung erfüllt die behördlichen IT-Richtlinien, weil die Daten auf dem eigenen Server oder im kommunalen Rechenzentrum verbleiben.

**Unternehmens-interne Workshop-Planung.** Abteilungsübergreifende Workshops, Strategiemeetings oder Schulungen erfordern Terminabstimmungen mit 10-50 Teilnehmern. Über das Intranet (TYPO3-basiert) lässt sich die Abstimmung direkt einbetten, ohne einen externen Link zu versenden, der möglicherweise vom Unternehmens-Proxy blockiert wird.

## Technische Architektur

Eine Doodle-Alternative in TYPO3 basiert auf einem Extbase-Plugin mit drei Datenbank-Tabellen: Abstimmungen (Polls), Terminoptionen (Options) und Stimmen (Votes). Die Abstimmung wird als Content-Element auf einer TYPO3-Seite platziert. Teilnehmer öffnen die Seite, sehen die Terminoptionen und wählen ihre verfügbaren Zeitfenster aus.

Die Dateneingabe erfolgt über ein Fluid-basiertes Formular. Jede Terminoption wird als Zeile dargestellt, der Teilnehmer setzt Checkboxen (ja/nein/vielleicht). Optional wird der Name des Teilnehmers abgefragt. Für authentifizierte Benutzer (Frontend-Login) kann die Extension den Namen automatisch ausfüllen und doppelte Abstimmungen verhindern.

Die Ergebnisdarstellung zeigt eine Matrix: Spalten für Teilnehmer, Zeilen für Terminoptionen, farbcodierte Zellen. Der Termin mit den meisten Zusagen wird hervorgehoben. Ein Admin-View im TYPO3-Backend zeigt alle Abstimmungen mit Ergebnis und erlaubt das Schließen oder Archivieren abgeschlossener Polls.

E-Mail-Benachrichtigungen sind optional integrierbar: Neue Abstimmung erstellt, neuer Teilnehmer hat abgestimmt, Abstimmung geschlossen. Die E-Mails nutzen TYPO3s Mail-API und lassen sich über Fluid-Templates anpassen.

Die DSGVO-Konformität erfordert: automatische Löschung der Abstimmungsdaten nach einem konfigurierbaren Zeitraum (z.B. 30 Tage nach Abstimmungsende), keine Cookies für die Abstimmungsteilnahme (Session-basiert) und eine Datenschutzerklärung, die den Zweck und die Speicherdauer benennt.

## Häufige Probleme und Lösungen

**Spam-Abstimmungen.** Ohne Schutz können Bots oder Trolle hunderte Fake-Stimmen abgeben. Lösung: Honeypot-Feld (unsichtbares Formularfeld, das nur Bots ausfüllen), Rate-Limiting (maximal 3 Abstimmungen pro IP pro Stunde) und optional ein einfaches CAPTCHA. Frontend-Login als Pflicht eliminiert Spam vollständig, schränkt aber die Nutzbarkeit für externe Teilnehmer ein.

**Fehlende Kalender-Integration.** Teilnehmer wollen den festgelegten Termin direkt in ihren Kalender übernehmen. Die meisten TYPO3-Doodle-Alternativen bieten keinen iCal-Export. Lösung: Nach Abstimmungsende einen "Termin herunterladen"-Button anzeigen, der eine .ics-Datei generiert. Der Aufwand für die iCal-Generierung liegt bei circa 2 Stunden Entwicklungszeit.

**Mobile Darstellung der Abstimmungsmatrix.** Eine Matrix mit 10 Terminoptionen und 20 Teilnehmern ist auf dem Smartphone nicht lesbar. Lösung: Auf mobilen Geräten die Matrix in eine Listenansicht umwandeln, bei der jeder Termin einzeln mit Ja/Nein-Buttons dargestellt wird. Die Ergebnisübersicht wird ebenfalls als vertikale Liste statt als horizontale Tabelle angezeigt.

## Migration und Versions-Kompatibilität

Im TYPO3 Extension Repository existieren mehrere Doodle-ähnliche Extensions mit unterschiedlichem Funktionsumfang und Pflegestatus. Keine davon hat sich als Standard durchgesetzt. Für TYPO3 v12 und v13 empfiehlt sich daher eine Custom-Entwicklung auf Extbase-Basis, die exakt die benötigten Features abdeckt und langfristig wartbar bleibt.

Der Entwicklungsaufwand für eine Basis-Version (Abstimmung erstellen, Termine wählen, Ergebnis anzeigen) liegt bei 3-5 Tagen. Mit E-Mail-Benachrichtigung, iCal-Export und Admin-Backend bei 7-10 Tagen. Das ist weniger als ein Jahr Doodle-Premium-Abo für 15+ Benutzer (ab 6,95 EUR/Benutzer/Monat = circa 1.250 EUR/Jahr).

Für Unternehmen, die bereits Microsoft 365 oder Google Workspace nutzen, ist die TYPO3-Lösung primär für externe Teilnehmer relevant. Interne Terminabstimmungen laufen über Outlook oder Google Calendar effizienter. Die TYPO3-Lösung ergänzt das, wo externe Teilnehmer ohne Account mitmachen sollen. Gosign entwickelt solche Custom-Lösungen auf Extbase-Basis und integriert sie in bestehende TYPO3-Installationen.

--- downloadmanager TYPO3 - Datei-Downloads | Gosign ---
> downloadmanager: Datei-Downloads in TYPO3 organisieren, kategorisieren & tracken. KI-beschleunigte Umsetzung.

## downloadmanager bringt Ordnung in TYPO3-Download-Bereiche, wenn ein verschachteltes Dateiverzeichnis nicht mehr reicht - mit Kategorien, Tags, Suche und einem Download-Zähler, der ohne Cookies auskommt

Sobald ein TYPO3-Projekt mehr als zwanzig Datei-Downloads zu verwalten hat, bricht die Handpflege zusammen. Redakteure verlinken PDFs über den Link-Browser, das Verzeichnis wächst chaotisch, bestehende Dokumente werden versehentlich überschrieben und Besucher finden über die Suche nichts mehr. downloadmanager löst genau dieses Problem: Er stellt den Datei-Bestand als strukturiertes Repository dar, mit eigenen Datensätzen, Kategorien, Tags, Metadaten und einer Oberfläche, die Nutzer gezielt durchsuchen können. Für Unternehmen mit Produkt-Datenblättern, Verbände mit Formular-Sammlungen und Kommunen mit Download-Zentren ist das die Standard-Lösung.

Der Unterschied zur Verwaltung über reine FAL-Ordner ist fundamental. Während fileadmin ein Dateisystem abbildet, führt downloadmanager eine redaktionelle Ebene oben drauf ein: Ein Dokument kann in mehreren Kategorien gleichzeitig erscheinen, seinen Anzeige-Titel unabhängig vom Dateinamen führen und über eine Veröffentlichungs-Planung gesteuert werden. Für Redaktionen mit Compliance-Anforderungen ist das oft Voraussetzung.

## Typische Einsatzszenarien

Der klassische Fall ist der technische Produktkatalog. Ein Maschinenbauer pflegt zu jeder Maschine ein Datenblatt, eine Bedienungsanleitung, ein CE-Zertifikat und eine Ersatzteilliste. Jeder Download bekommt eine Produktkategorie, eine Typ-Zuordnung und optional ein Sprach-Tag. Besucher filtern nach Produktreihe und Dokument-Typ, bekommen sofort die passenden Dateien und der Shop muss nicht jedes PDF einzeln verlinken. Die Produktseite selbst kann einen Mini-Download-Bereich anzeigen, der automatisch alle zur Maschine gehörenden Dokumente listet - ganz ohne redaktionelle Doppelpflege.

Der zweite Fall sind Formular-Bereiche bei Kommunen, Behörden und Kammern. Antragsformulare, Merkblätter und Satzungen sind thematisch gruppiert, oft mehrsprachig, gelegentlich mit Zugriffsbeschränkung für interne Mitgliederbereiche. downloadmanager erlaubt genau diese Segmentierung über fe_groups und kategorisiert Dokumente nach Fachbereich. Für Öffentliche Verwaltungen ist zudem wichtig, dass Veröffentlichungsdaten und Gültigkeitsfristen pro Dokument verwaltet werden können.

Dritter Einsatz: Presse- und Investor-Relations-Bereiche. Geschäftsberichte, Pressemitteilungen und Bildmaterial werden zentral abgelegt, nach Jahr kategorisiert und mit Veröffentlichungsdatum versehen. Die Redaktion muss jedes Dokument nur einmal einpflegen, die Frontend-Listen werden automatisch generiert.

## Technische Architektur

downloadmanager ist eine Extbase-Extension und pflegt eigene Datensätze in tx_downloadmanager_domain_model_download. Jeder Download referenziert eine oder mehrere FAL-Dateien und trägt Meta-Felder wie Titel, Beschreibung, Kategorie, Tags, Veröffentlichungsdatum, Sprache und Zugriffsgruppen. Das Backend-Modul erlaubt Massenimport, Bulk-Edit und Veröffentlichungs-Workflows.

Im Frontend liefert die Extension vorgefertigte Listen- und Detail-Views als Fluid-Templates. Listen können nach Kategorie, Tag, Suchbegriff oder Sortierkriterium gefiltert werden, die Parameter werden per GET-Parameter übergeben und im Cache berücksichtigt. Für die Suche nutzt die Extension die MySQL-Volltextsuche oder, auf Wunsch, eine angebundene Solr-Installation.

Die Konfiguration erfolgt über TypoScript und FlexForm. Typische Einstellungen sind die Standard-Kategorie, die Anzahl der Einträge pro Seite, die Sortierreihenfolge und die Integration in ein eigenes Sitepackage-Template. Über EventListener können Entwickler eigene Logik einhängen, etwa eine Mail-Benachrichtigung bei neuen Uploads oder einen Export in andere Systeme.

Download-Tracking ist ein zentrales Feature. Statt externer Analytics mit Cookies erhöht downloadmanager bei jedem Klick einen serverseitigen Zähler, der als einfache Integer-Spalte im Datensatz liegt. Das ist DSGVO-freundlich, belastet keinen Cookie-Banner und liefert eine belastbare Aussage, welche Dokumente tatsächlich nachgefragt werden.

## Häufige Probleme und Lösungen

Das erste Problem ist die Migration aus einem Altbestand. Wer Jahre lang Downloads im Link-Browser gepflegt hat, muss sie zunächst in downloadmanager-Datensätze überführen. Die Lösung ist ein Skript, das die vorhandenen Fileadmin-Strukturen durchläuft, Metadaten aus Dateinamen extrahiert und Datensätze anlegt. Gosign nutzt dafür KI-gestützte Pipeline, die Kategorien und Tags aus Dateiinhalten und PDF-Metadaten vorschlägt und die Redaktion nur noch bestätigen muss.

Zweites Problem: Caching. Gefilterte Listen mit URL-Parametern erzeugen viele Cache-Varianten, was den TYPO3-Cache aufbläht. Die Lösung liegt im cHash-Handling und in einer sauberen Definition, welche Parameter cache-relevant sind. Für Seiten mit vielen Filtern kann ein Edge-Caching über Cloudflare oder Varnish mit parameter-bewusster Regel sinnvoller sein als serverseitiges Caching.

Drittes Problem: Mehrsprachigkeit. Ein Dokument existiert in fünf Sprachen, soll aber als ein logischer Eintrag geführt werden, damit die Metadaten synchron bleiben. Hier nutzt downloadmanager den TYPO3-Sprachmechanismus mit Übersetzungs-Datensätzen. Wichtig ist, dass die Redaktion versteht, welche Felder pro Sprache gepflegt werden und welche global gelten.

## Migration und Versions-Kompatibilität

downloadmanager wird aktiv gepflegt und ist mit TYPO3 v11, v12 und v13 kompatibel. Beim Upgrade von älteren TYPO3-Versionen ist vor allem auf Extbase-Änderungen zu achten: Die Repository-Methoden und die Persistenzschicht haben sich zwischen v9 und v12 mehrfach geändert, was eigene Erweiterungen der Extension brechen kann. Ein typisches Upgrade-Projekt umfasst daher auch die Anpassung eigener Controller und Templates.

Für Projekte, die heute starten, lohnt sich vorab die Entscheidung, ob downloadmanager oder eine Lösung über Extbase-eigene Datensätze der richtige Weg ist. Wenn die Redaktion ausschließlich Standard-Downloads mit Kategorien und Tags braucht, ist die Extension die pragmatische Wahl. Wenn darüber hinaus komplexe Workflows (Freigabe, mehrstufige Veröffentlichung, Versionierung) gefragt sind, kann eine maßgeschneiderte Lösung langfristig einfacher zu pflegen sein.

Gosign migriert downloadmanager auf neue TYPO3-Versionen, begleitet Altbestandsmigrationen und integriert die Extension in bestehende Sitepackages. KI-gestützte Analyse hilft dabei, Kategorien und Tags aus bestehenden Dateinamen und Verzeichnisstrukturen automatisch vorzuschlagen, sodass die manuelle Pflege-Arbeit auf ein Minimum schrumpft.

--- dp_cookieconsent TYPO3 - Cookie Consent | Gosign ---
> dp_cookieconsent für TYPO3: DSGVO-konformes Cookie-Management. Setup, Audit & Optimierung , KI-beschleunigte Analyse.

## Warum ein Cookie-Banner allein keine DSGVO-Konformität herstellt

Jede TYPO3-Installation, die Google Analytics, YouTube-Videos, Social-Media-Plugins oder externe Schriftarten einbindet, steht seit Inkrafttreten der DSGVO und des TTDSG vor derselben Aufgabe: Vor dem Laden eines Drittanbieter-Skripts muss eine aktive, informierte Einwilligung des Nutzers vorliegen. dp_cookieconsent ist die in der deutschen TYPO3-Community am weitesten verbreitete Extension, die genau diese Aufgabe übernimmt. Sie zielt auf Unternehmen, die ihre Website ohne externes Consent-Management-Tool DSGVO-konform betreiben wollen, und richtet sich damit an Mittelständler, Behörden und Bildungseinrichtungen, die keine laufenden Kosten für kommerzielle CMPs tragen wollen.

## Typische Einsatzszenarien

Ein Industrieunternehmen mit Produktkatalog und 45 Landingpages nutzt Google Analytics, einen YouTube-Erklärfilm, HubSpot-Formulare und Google Fonts. Ohne dp_cookieconsent würden alle diese Dienste Cookies setzen, sobald ein Nutzer die Seite öffnet, und damit eine Abmahnung nach TTDSG riskieren. Die Extension gruppiert die Dienste nach Kategorie, legt den HubSpot-Code erst nach Marketing-Consent nach und lädt Google Fonts alternativ self-hosted, wodurch die Consent-Anfrage dort komplett entfällt.

Ein zweites typisches Bild liefert eine Universität mit einem Hauptportal und mehreren dezentralen Fakultäts-Websites. Jede Fakultät pflegt eigene Inhalte und bindet eigene Dienste ein, manchmal ein eingebettetes Kartenmaterial von OpenStreetMap, manchmal ein YouTube-Video, manchmal ein Piwik-Tracking. dp_cookieconsent zentralisiert die Consent-Verwaltung in der Haupt-Installation, liefert den Banner über Fluid-Partials an alle Sub-Sites und speichert die Einwilligung domainübergreifend, sodass ein Nutzer nicht an jeder Fakultäts-Site erneut zustimmen muss.

Ein dritter Fall sind kommunale Verwaltungen mit Online-Formularen und Kartenanwendungen. Hier kommt erschwerend hinzu, dass die Datenschutzbeauftragten des Landes regelmäßig Audits durchführen und eine vollständige Dokumentation der eingesetzten Dienste verlangen. dp_cookieconsent liefert die Kategorisierung und den Privacy-Text direkt aus TypoScript, was die Pflege durch die Redaktion ohne Entwickler-Eingriff ermöglicht.

## Technische Architektur: Script-Blocking auf Template-Ebene

dp_cookieconsent arbeitet nach dem Prinzip "type-attribute swapping": Alle Drittanbieter-Skripte im Quelltext werden nicht mit type="text/javascript" ausgeliefert, sondern mit einem neutralen Typ wie type="text/plain" und einem zusätzlichen data-cookieconsent-Attribut. Der Browser ignoriert solche Tags und führt sie nicht aus. Erst wenn der Nutzer im Banner zustimmt, ersetzt ein kleiner JavaScript-Runner die Typ-Attribute und triggert die verzögerte Ausführung. Der gleiche Mechanismus greift für iframes, die bis zur Einwilligung als Platzhalter dargestellt werden.

Konfiguriert wird die Extension vollständig über TypoScript-Konstanten und Setup, ergänzt durch eine YAML-Datei für die Service-Definitionen. Jeder Service ist dort mit Name, Beschreibung, Kategorie, Cookie-Namen und Cookie-Laufzeit hinterlegt, was die spätere Dokumentation für den Datenschutzbeauftragten erheblich vereinfacht. Fluid-Partials definieren das Aussehen des Banners und der Einstellungs-Modal, wodurch sich das Design ohne Extension-Änderung an die Corporate Identity anpassen lässt.

## Häufige Probleme und Lösungen

Das erste und häufigste Problem: Trotz aktiviertem Banner laden Drittanbieter-Skripte trotzdem, weil sie über Include-Pfade eingebunden sind, die nicht durch TypoScript laufen. Typisch sind statische HTML-Blöcke, Fluid-Inhaltselemente mit hartcodierten Script-Tags oder Footer-Includes aus älteren Templates. Eine saubere Lösung erfordert einen vollständigen Site-Crawl mit Browser-Devtools oder einem automatisierten Tool, das alle ausgehenden Requests protokolliert und vergleicht, welche davon vor Consent ausgelöst werden.

Das zweite Problem ist die Consent-Speicherung. dp_cookieconsent speichert die Einwilligung in einem lokalen Cookie, was bei Nutzern mit strenger Browser-Konfiguration oder Inkognito-Modus zu wiederholten Banner-Einblendungen führt. Wer Consent-Quoten messen will, muss zusätzlich ein serverseitiges Logging aktivieren, das die Einwilligungen samt Zeitstempel und IP-Hash in einer Datenbanktabelle ablegt und damit eine belastbare Dokumentation für Audits liefert.

Das dritte Thema betrifft Performance. Der Banner lädt ein JavaScript-Bundle, das je nach Umfang der konfigurierten Services merklich groß werden kann und die First Contentful Paint verzögert. Gosign optimiert die Auslieferung über deferred Loading, reduziert unnötige Fluid-Partials und setzt wo möglich auf eine Kombination aus cookieless Analytics und self-hosted Assets, sodass der Banner nur noch für wenige Dienste notwendig ist.

Ein viertes Problem tritt bei Consent-Änderungen auf: Ein Nutzer gibt seine Einwilligung, nutzt die Seite, ändert später seine Meinung und widerruft die Zustimmung. dp_cookieconsent setzt das Cookie-Flag zurück, aber bereits geladene Skripte laufen im Hintergrund weiter, bis der Nutzer die Seite neu lädt. Eine saubere Lösung erfordert einen Reload-Trigger oder das gezielte Entfernen bereits gesetzter Cookies beim Widerruf, sodass der Datenschutz-Widerruf tatsächlich wirksam wird und nicht nur formal dokumentiert ist.

## Migration und Versions-Kompatibilität

dp_cookieconsent ist für TYPO3 v11, v12 und v13 verfügbar, wobei die v13-Kompatibilität regelmäßig aktualisiert wird und aktuell als produktionsreif gilt. Der Sprung von v11 auf v12 erfordert in der Regel ein Re-Mapping der TypoScript-Konstanten, da einige Konstantennamen umbenannt wurden. Für Nutzer älterer Versionen der Extension ist zu beachten, dass die Service-Definitionen früher ausschließlich über Backend-Formulare gepflegt wurden, während neuere Versionen YAML-basiert arbeiten und damit deutlich einfacher in Git-Workflows einbettbar sind.

Wer von einem anderen Consent-Tool wie Cookiebot, OneTrust oder Usercentrics migriert, spart damit laufende Lizenzkosten, muss aber die Service-Konfiguration neu aufbauen. Gosign führt solche Migrationen inklusive Consent-Rate-Analyse durch, sodass der Umstieg messbar keine Einbußen bei der Zustimmungsquote verursacht.

Zusätzlich lohnt sich ein strategischer Blick auf die Frage, ob ein Cookie-Banner überhaupt noch die richtige Antwort ist. Wer konsequent self-hosted Fonts einsetzt, auf cookielose Analytics wie Matomo mit deaktivierten Cookies oder Plausible wechselt und Video-Embeds durch statische Vorschau-Bilder mit Klick-Laden ersetzt, kann den Banner für viele Seiten komplett entfernen. Der rechtliche Vorteil ist erheblich, weil jede vermiedene Einwilligung auch ein vermiedenes Abmahn-Risiko bedeutet und gleichzeitig die Conversion-Rate nicht durch den Banner-Dialog ausgebremst wird.

--- dpn_glossary TYPO3 - Fachbegriffe | Gosign ---
> Glossar-Extension für TYPO3. Fachbegriffe definieren, automatisch im Content verlinken, als Tooltip anzeigen. Alphabetische Navigation. SEO-Boost.

## Ein Glossar bringt SEO-Wert, wenn die interne Verlinkung automatisiert läuft

Fachbegriffe auf einer Website manuell zu verlinken ist Sisyphusarbeit. Ein Unternehmen mit 200 Unterseiten und 80 Fachbegriffen müsste theoretisch jede Seite durchgehen und relevante Begriffe mit der Glossarseite verknüpfen. Das passiert in der Praxis nie vollständig, und bei neuen Inhalten wird es vergessen. dpn_glossary automatisiert diesen Prozess: Die Extension erkennt definierte Fachbegriffe im Content und verlinkt sie automatisch mit der jeweiligen Glossarseite oder zeigt eine Tooltip-Definition an.

Der SEO-Effekt ist messbar. Jeder Glossarbegriff erzeugt eine eigene indexierbare URL. Die automatische Verlinkung aus dem Content heraus schafft ein dichtes internes Linknetz, das Google hilft, die thematische Autorität der Website einzuordnen. Websites mit 50+ Glossarbegriffen generieren typischerweise 5 bis 15 % zusätzlichen organischen Traffic über Long-Tail-Keywords.

## Typische Einsatzszenarien

**Fachportale und Branchenwebsites.** Versicherungen, Finanzdienstleister, juristische Kanzleien, technische Unternehmen - überall dort, wo Fachsprache zum Alltag gehört, profitieren Besucher von verständlichen Definitionen. Ein Versicherer mit Begriffen wie "Deckungssumme", "Selbstbeteiligung", "Regressanspruch" kann diese im Fliesstext als Tooltip einblenden, ohne den Lesefluss zu stören. Gleichzeitig existiert eine alphabetische Glossarseite als Nachschlagewerk.

**Technische Dokumentation und Knowledge Bases.** Software-Unternehmen, die ihre Dokumentation in TYPO3 pflegen, nutzen dpn_glossary, um technische Begriffe (API, SDK, Webhook, OAuth) konsistent zu erklären. Neue Mitarbeitende und Kunden finden Definitionen direkt im Kontext, ohne in einem separaten Dokument nachschlagen zu müssen.

**Mehrsprachige Websites mit sprachspezifischen Fachbegriffen.** dpn_glossary unterstützt die TYPO3-Übersetzungsmechanismen. Begriffe können pro Sprache definiert werden, inklusive unterschiedlicher Definitionen und Abkürzungen. Ein deutscher Glossarbegriff "Betriebsrat" wird im englischen Content als "Works Council" erkannt und verlinkt.

## Technische Architektur

dpn_glossary speichert Glossarbegriffe in einer eigenen Tabelle (tx_dpnglossary_domain_model_term). Jeder Begriff hat einen Namen, eine Definition (RichText), optional eine Kurzform, Synonyme, Medien (Bilder, Dateien) und eine Detail-URL. Synonyme sind wichtig: Der Begriff "KI" kann als Synonym für "Künstliche Intelligenz" definiert werden, damit beide Schreibweisen im Content automatisch erkannt werden.

Die automatische Verlinkung arbeitet als Content-Post-Processor: Nachdem TYPO3 den Seiteninhalt gerendert hat, durchsucht dpn_glossary den HTML-Output nach bekannten Begriffen und ersetzt sie durch Links oder Tooltip-Markup. Dabei werden HTML-Tags, Attribute und bestehende Links ausgelassen, um fehlerhafte Verschachtelungen zu vermeiden. Die Ersetzung ist konfigurierbar: nur erste Nennung pro Seite, alle Nennungen, oder keine Ersetzung (nur Tooltip).

Die Glossarseite wird als TYPO3-Plugin-Seite eingerichtet. Die Standardansicht zeigt eine alphabetische Navigation (A-Z) mit allen Begriffen. Jeder Begriff hat eine Detailseite mit Definition, verwandten Begriffen und optional eingebetteten Medien. Die URLs folgen dem Muster /glossar/begriff-name/, was für SEO optimal ist.

Performance: Die automatische Verlinkung durchsucht jeden gerenderten Seiteninhalt. Bei 100+ Begriffen und langen Seiten kann das spürbar werden. dpn_glossary cacht die Term-Liste und nutzt reguläre Ausdrücke für die Suche, was bei aktiviertem TYPO3-Seitencache (cached_pages) kein Problem darstellt, weil die Ersetzung nur beim ersten Aufruf läuft.

## Häufige Probleme und Lösungen

**Begriffe werden in Überschriften, Menüs oder Formularen verlinkt.** Die automatische Verlinkung erfasst manchmal HTML-Bereiche, die nicht verlinkt werden sollen. Lösung: Die Extension bietet eine Konfiguration für Excluded Tags (z.B. h1, h2, h3, nav, form, a). Standardmässig sind Überschriften und Links ausgeschlossen, aber die Liste muss an das jeweilige Projekt angepasst werden.

**Tooltip-Darstellung kollidiert mit dem Layout.** Tooltips (Hover-Popups mit der Definition) können über den Seitenrand hinausragen oder andere Elemente überdecken. Lösung: Das Tooltip-CSS anpassen (max-width, z-index, Position). dpn_glossary liefert ein Standard-CSS mit, das über TypoScript überschrieben werden kann. Für mobile Geräte empfiehlt sich ein Tap-statt-Hover-Verhalten.

**Performance-Probleme bei vielen Begriffen.** Websites mit 500+ Glossarbegriffen spüren die Verlinkung bei nicht gecachten Seiten. Lösung: Die Term-Liste auf die aktiven Begriffe einschränken (veraltete deaktivieren), die Verlinkung auf bestimmte Seitenbereiche beschränken (nur Hauptinhalt, nicht Footer oder Sidebar) und den TYPO3-Seitencache konsequent nutzen.

## Migration und Versions-Kompatibilität

dpn_glossary unterstützt TYPO3 v11 und v12 in der aktuellen stabilen Version. TYPO3 v13-Kompatibilität ist in Entwicklung (Stand April 2026). Die Extension wird aktiv gepflegt, mit regelmässigen Releases und einem klaren Upgrade-Pfad.

Für Projekte, die von einer anderen Glossar-Lösung kommen (z.B. einem selbstgebauten Glossar-Plugin oder einer WordPress-Migration), ist die Datenmigration einfach: Begriffe als CSV exportieren und per Import-Skript in die dpn_glossary-Tabelle laden. Gosign hat dafür ein CLI-Tool, das CSV, JSON und XML-Quellen unterstützt.

Langfristig empfiehlt Gosign, Glossardaten zusätzlich als Schema.org DefinedTerm Markup auszugeben. dpn_glossary bietet dafür keine native Unterstützung, aber ein Fluid-Template-Override kann das Markup pro Glossarbegriff ergänzen. Das verbessert die Sichtbarkeit in Knowledge Panels und AI-generierten Antworten.

Ein weiterer Einsatzbereich, der oft übersehen wird: Glossare als Onboarding-Tool für neue Mitarbeitende. Unternehmen mit vielen internen Fachbegriffen (Versicherungen, Banken, Behörden) können dpn_glossary im Intranet-TYPO3 einsetzen, damit neue Kolleginnen und Kollegen unbekannte Begriffe direkt im Kontext nachschlagen können. Die Extension funktioniert im Intranet genauso wie auf öffentlichen Websites.

Gosign kalkuliert die Ersteinrichtung eines dpn_glossary-Projekts (Installation, Konfiguration, Template-Anpassung, Import von 50 Begriffen) mit 1 bis 2 Entwicklungstagen. Die laufende Pflege der Begriffe übernimmt die Redaktion über das TYPO3-Backend. Pro Begriff sind Name, Definition, Synonyme und ein optionales Bild zu pflegen, was in 5 bis 10 Minuten erledigt ist.

--- Link-Validator TYPO3 - SEO | Gosign ---
> Broken-Link-Checker für TYPO3: Interne und externe Links prüfen, kaputte Verlinkungen finden. Essentiell für SEO und Nutzererfahrung.

## Kaputte Links kosten Rankings und Vertrauen, und die meisten TYPO3-Websites haben davon mehr als erwartet

Eine TYPO3-Website mit 500 Seiten hat im Durchschnitt 3.000-5.000 Links. Davon sind erfahrungsgemäß 2-5% defekt: gelöschte Seiten, geänderte URLs externer Websites, Tippfehler in manuell eingegebenen Links. Das sind 60-250 Broken Links, die Besucher auf 404-Seiten schicken und Google signalisieren, dass die Website schlecht gepflegt ist. dreipc_linkvalidator prüft alle internen und externen Links automatisch und meldet Probleme, bevor sie sich auf Rankings und Nutzererfahrung auswirken.

TYPO3 bringt einen eigenen Linkvalidator im Core mit (EXT:linkvalidator). dreipc_linkvalidator erweitert diesen um zusätzliche Prüfungen, bessere Reports und eine intuitivere Backend-Oberfläche. Für Websites mit mehr als 200 Seiten ist ein automatisierter Link-Check kein Luxus, sondern Pflicht.

## Typische Einsatzszenarien

**Corporate Websites mit externen Verlinkungen.** Unternehmenswebsites verlinken auf Partner, Lieferanten, Fachverbände, Gesetzestexte und Presseartikel. Externe URLs ändern sich ohne Vorwarnung. Ein Link auf eine EU-Verordnung funktioniert heute, wird aber nächste Woche verschoben. dreipc_linkvalidator prüft externe Links per HTTP-Request und meldet 404, 301-Ketten (mehr als 2 Redirects) und Timeouts.

**Universitäten und Bildungseinrichtungen.** Hochschul-Websites gehören zu den link-intensivsten Seiten überhaupt: Studienordnungen, Formulare, Vorlesungsverzeichnisse, Personenverzeichnisse, Partnerhochschulen. Bei einer Hochschul-Website mit 12.000 Seiten fand der Link-Check 1.400 defekte Links, davon 800 interne (gelöschte Seiten, umstrukturierte Bereiche) und 600 externe.

**Redaktionelle Portale mit Archiv-Content.** News-Portale und Magazine mit tausenden Artikeln verlinken untereinander und auf externe Quellen. Über Jahre sammeln sich Broken Links an, besonders in älteren Artikeln. Ein monatlicher Link-Check identifiziert neue Probleme, bevor sie sich häufen.

## Technische Architektur

dreipc_linkvalidator erweitert TYPO3s Core-Linkvalidator um zusätzliche Prüfmechanismen. Der Core-Linkvalidator prüft Links auf Datenbankebene: Er analysiert die Felder `bodytext`, `header_link` und andere konfigurierte Felder in der Content-Tabelle und identifiziert Links auf gelöschte Seiten oder Dateien. dreipc_linkvalidator ergänzt HTTP-basierte Prüfungen für externe URLs.

Die Prüfung läuft als TYPO3 Scheduler-Task. Typische Konfiguration: einmal pro Woche nachts. Der Task durchsucht alle konfigurierten Tabellen und Felder nach Links, unterscheidet zwischen internen Links (t3://page?uid=123), Datei-Links (t3://file?uid=456) und externen Links (https://...), und prüft jeden Link auf Erreichbarkeit.

Interne Links werden gegen die TYPO3-Datenbank geprüft: Existiert die verlinkte Seite noch? Ist sie nicht versteckt, nicht gelöscht, nicht zeitlich abgelaufen? Datei-Links prüfen, ob die referenzierte Datei im FAL noch existiert. Externe Links werden per HTTP HEAD-Request geprüft (schneller als GET, da kein Body übertragen wird). Bei HEAD-Fehler folgt ein GET als Fallback.

Die Ergebnisse werden in einer Backend-Ansicht dargestellt: tabellarisch, filterbar nach Fehlertyp (404, 301, Timeout, SSL-Fehler), nach Seite und nach Redakteur. Jeder Eintrag enthält den Link, die Fehlerursache, die Seite auf der er vorkommt und einen direkten Link zum TYPO3-Backend-Editor.

## Häufige Probleme und Lösungen

**False Positives bei externen Links.** Manche Websites blockieren automatisierte Requests (Bot-Protection, Cloudflare Challenge). Der Link funktioniert im Browser, aber der Linkvalidator meldet 403 oder Timeout. Lösung: Einen realistischen User-Agent-Header setzen, Timeouts auf 15 Sekunden erhöhen und bekannte False-Positive-Domains auf eine Whitelist setzen. Bei einem Kunden reduzierten diese Anpassungen die False-Positive-Rate von 12% auf unter 2%.

**Prüfung dauert zu lange bei großen Websites.** 10.000 externe Links zu prüfen dauert bei sequentieller Abarbeitung mehrere Stunden. Lösung: Parallele Prüfung konfigurieren (5-10 gleichzeitige Requests), die Prüfung auf externe Links beschränken (interne Links sind schnell per DB-Query prüfbar) und die Prüffrequenz anpassen (externe Links wöchentlich, interne täglich).

**Redakteure ignorieren die Berichte.** Der häufigste Grund für wachsende Broken-Link-Listen: Niemand fühlt sich zuständig. Lösung: E-Mail-Benachrichtigungen an die zuständigen Redakteure aktivieren. dreipc_linkvalidator kann Reports per E-Mail versenden, aufgeschlüsselt nach Seitenbaum-Bereich. Der Redakteur erhält nur die Broken Links in "seinem" Bereich.

## Migration und Versions-Kompatibilität

TYPO3s Core-Linkvalidator (EXT:linkvalidator) ist seit v7 Bestandteil des Core und wird kontinuierlich weiterentwickelt. In TYPO3 v12 und v13 ist der Core-Linkvalidator deutlich verbessert: bessere Performance, neue UI im Backend, Scheduler-Integration überarbeitet. dreipc_linkvalidator als Erweiterung unterstützt TYPO3 v10 und v11. Für v12 und v13 existiert keine offizielle Version.

Für Projekte auf TYPO3 v12/v13 stellt sich die Frage, ob dreipc_linkvalidator noch nötig ist. Der Core-Linkvalidator in v12 deckt viele Features ab, die früher nur über dreipc verfügbar waren: HTTP-basierte Prüfung externer Links, Scheduler-Integration, Backend-Ansicht mit Filterung. Was fehlt: E-Mail-Reports und die Whitelist-Funktion für False Positives.

Die Alternative: den Core-Linkvalidator mit einem Custom Command ergänzen, der E-Mail-Reports generiert. Der Aufwand liegt bei circa einem Entwicklertag. Alternativ gibt es externe Tools (Screaming Frog, Ahrefs, Semrush), die Broken Links als Teil ihres SEO-Audits prüfen, aber nicht in TYPO3 integriert sind. Gosign empfiehlt den Core-Linkvalidator in Kombination mit einem monatlichen externen Crawl für maximale Abdeckung.

--- dreipc_pdf TYPO3 - PDF Export | Gosign ---
> PDF-Generierung von dreipc: TYPO3-Seiten als PDF exportieren mit Custom-Layout. Alternative zu web2pdf mit eigenem Rendering-Ansatz.

## Wenn Besucher TYPO3-Seiten als PDF herunterladen wollen, braucht das Ergebnis ein eigenes Layout

Besucher klicken auf "Als PDF speichern" und erwarten ein sauberes Dokument: Corporate Design, Logo, Seitenzahlen, kein Navigation-Overhead. Was die Browser-Druckfunktion liefert, ist das Gegenteil: abgeschnittene Spalten, überflüssige Header und Footer, fehlende Bilder. dreipc_pdf löst dieses Problem mit einem eigenen Rendering-Ansatz: Die Extension erzeugt PDFs aus TYPO3-Seiteninhalten mit einem dedizierten Print-Layout, unabhängig von der Browser-Darstellung.

Im Gegensatz zu EXT:web2pdf, das die gerenderte HTML-Seite als Screenshot in ein PDF umwandelt, arbeitet dreipc_pdf datengetrieben. Es rendert die Inhaltselemente einer TYPO3-Seite über eigene Templates und erzeugt daraus ein formatiertes PDF. Das erlaubt volle Kontrolle über Seitenränder, Kopf- und Fußzeilen, Schriftgrößen und Seitenumbrüche.

## Typische Einsatzszenarien

**Produktdatenblätter aus dem CMS.** Maschinenbauer, Chemieunternehmen und Medizintechnik-Hersteller pflegen Produktdaten in TYPO3. Vertriebsmitarbeiter brauchen diese Daten als druckbares PDF für Kundenbesuche. dreipc_pdf erzeugt aus der TYPO3-Produktseite ein PDF mit Corporate-Layout: Logo oben, technische Daten in Tabellen, Produktbild, Kontaktdaten unten. Bei einem Kunden mit 400 Produktseiten stehen die PDFs automatisch per Button auf jeder Seite bereit, ohne manuelle Erstellung.

**Pressemitteilungen und Geschäftsberichte.** Kommunikationsabteilungen veröffentlichen Pressemitteilungen auf der Website und bieten sie gleichzeitig als PDF zum Download an. dreipc_pdf generiert das PDF beim Klick auf den Download-Button, immer basierend auf dem aktuellen Content. Keine manuelle PDF-Erstellung, kein Risiko veralteter Downloadversionen.

**Behördliche Informationsblätter.** Öffentliche Einrichtungen stellen Formulare, Merkblätter und Informationsschreiben als PDF bereit. Die Inhalte werden in TYPO3 gepflegt und bei Änderungen automatisch als aktualisiertes PDF ausgeliefert. Die PDF-Version hat ein offizielles Layout mit Amtskopf und Aktenzeichen.

## Technische Architektur

dreipc_pdf nutzt eine PHP-PDF-Library (typischerweise mPDF oder TCPDF) zur Generierung. Die Extension registriert sich als Page-Type in TYPO3. Beim Aufruf einer Seite mit dem PDF-Type-Parameter (`?type=123`) wird statt des HTML-Outputs eine PDF-Datei generiert und zum Download angeboten.

Die Rendering-Pipeline arbeitet in drei Schritten. Erstens liest die Extension die Inhaltselemente der angeforderten TYPO3-Seite aus der Datenbank. Zweitens rendert sie jedes Element über ein dediziertes PDF-Fluid-Template (nicht das Standard-Web-Template). Drittens übergibt sie den gerenderten HTML-String an mPDF/TCPDF, die daraus das PDF mit den konfigurierten Seiteneinstellungen erzeugen.

Die PDF-Templates sind Fluid-Templates mit HTML/CSS, die mPDF versteht. mPDF unterstützt einen Subset von CSS2 und CSS3: Seitenränder (`@page`), Kopf-/Fußzeilen, Tabellen, Bilder, Schriftarten (einbettbare TTF-Fonts) und Seitenumbrüche (`page-break-before`, `page-break-after`). Flexbox und Grid werden nicht unterstützt, die Layout-Arbeit erfolgt über Tabellen oder Float.

Die Konfiguration umfasst: Seitenformat (A4, Letter, Custom), Seitenausrichtung (Hoch-/Querformat), Seitenränder, Standard-Schriftart, Kopf-/Fußzeilen-Templates und die Zuordnung von Content-Element-Typen zu PDF-Templates. Jedes Content-Element kann ein eigenes PDF-Template haben, das sich von der Web-Darstellung unterscheidet.

## Häufige Probleme und Lösungen

**Bilder fehlen im PDF.** mPDF lädt Bilder über HTTP nach. Wenn der Server hinter einem Reverse Proxy oder in einer Docker-Umgebung läuft, kann mPDF die eigenen Bild-URLs nicht auflösen. Lösung: Bilder über den lokalen Dateipfad statt über die URL einbinden. In den PDF-Fluid-Templates den absoluten Serverpfad (`/var/www/html/fileadmin/...`) statt der Webadresse verwenden.

**PDF-Erzeugung bei komplexen Seiten langsam.** Eine Seite mit 30 Inhaltselementen und 15 Bildern kann 5-10 Sekunden für die PDF-Generierung brauchen. Bei gleichzeitigen Anfragen belastet das den Server. Lösung: generierte PDFs cachen. Beim ersten Aufruf wird das PDF erzeugt und im Dateisystem gespeichert. Folgende Aufrufe liefern die gecachte Version. Der Cache wird bei Content-Änderungen invalidiert.

**Seitenumbrüche an falschen Stellen.** mPDF bricht Seiten dort um, wo der Inhalt die Seitenhöhe überschreitet, auch mitten in einer Tabelle oder einem Absatz. Lösung: In den PDF-Templates explizite Seitenumbrüche setzen (`<div style="page-break-before: always;">`) und Tabellen mit `<table style="page-break-inside: avoid;">` vor dem Umbrechen schützen.

## Migration und Versions-Kompatibilität

dreipc_pdf ist eine Nischen-Extension mit begrenzter Community. Die letzte stabile Version unterstützt TYPO3 v10 und v11. Für v12 existiert kein offizielles Update, der Portierungsaufwand ist moderat (Extbase-Anpassungen, TCA-Updates).

Die Alternativen für TYPO3 v12/v13: EXT:web2pdf (Screenshot-basiert, einfacher, weniger Kontrolle über das Layout), EXT:pdfviewhelpers (ViewHelper-basiert, arbeitet mit TCPDF), EXT:fluid_fpdf (Fluid-Templates mit FPDF-Backend) oder eine Custom-Lösung mit mPDF als Composer-Paket. Die Custom-Lösung hat den Vorteil der vollständigen Kontrolle und Unabhängigkeit von Drittanbieter-Extensions.

Wer von dreipc_pdf auf eine Custom-Lösung migriert, kann die bestehenden PDF-Fluid-Templates übernehmen, sofern sie mPDF-kompatibles HTML/CSS verwenden. Der Rendering-Wrapper muss neu geschrieben werden, aber die Templates bleiben. Bei einem typischen Projekt mit 5 PDF-Templates liegt der Migrationsaufwand bei 2-3 Tagen. Gosign hat PDF-Generierung in TYPO3 mit verschiedenen Libraries umgesetzt und empfiehlt je nach Anforderung die passende Lösung.

--- E-Paper TYPO3 - Online-Magazin | Gosign ---
> Online-Magazin-Darstellung in TYPO3. PDF-basiert oder HTML-basiert. Gosign berät zu modernen, performanten Lösungen statt veralteten.

## Die meisten E-Paper-Lösungen in TYPO3 sind Flash-Nachfolger, und genau so fühlen sie sich an

E-Paper-Extensions für TYPO3 stammen konzeptionell aus der Flash-Ära: ein PDF wird hochgeladen, eine JavaScript-Library simuliert Seitenblättern mit 3D-Animation. Das sieht auf dem ersten Blick beeindruckend aus. Auf dem zweiten Blick: nicht indexierbar (Google kann den Content nicht lesen), nicht responsiv (auf dem Smartphone eine Katastrophe), nicht barrierefrei und mit Ladezeiten jenseits der 5 Sekunden. Es gibt bessere Wege, Magazine und Kataloge in TYPO3 darzustellen.

Die zentrale Frage ist nicht "Welches E-Paper-Plugin?", sondern "Brauchen wir überhaupt ein E-Paper?". In den meisten Fällen ist die Antwort: Nein. Der Content gehört als HTML auf die Website, nicht als PDF in einen Blätterkatalog.

## Typische Einsatzszenarien

**Unternehmensmagazine und Kundenzeitschriften.** Marketingabteilungen produzieren quartalsweise Magazine im Print und wollen die digitale Version auf der Website anbieten. Klassischer Ansatz: PDF hochladen, Blätterkatalog-Widget einbetten. Besserer Ansatz: Die Artikel als einzelne TYPO3-Seiten (über tx_news) veröffentlichen, mit einer Magazin-Übersichtsseite als Hub. Jeder Artikel ist einzeln indexierbar, verlinkbar und teilbar. Das PDF bleibt als Download-Option für Offline-Leser.

**Produktkataloge für Handelspartner.** Großhandel und B2B-Unternehmen bieten ihren Händlern Produktkataloge an. Die Katalogdaten existieren oft als InDesign-Export (PDF). Ein E-Paper-Widget macht den Katalog durchblätterbar, aber nicht durchsuchbar. Der bessere Weg: Die Produktdaten strukturiert in TYPO3 pflegen und den Katalog als filtrierbare, durchsuchbare HTML-Seite darstellen. Das PDF dient als Print-Version zum Download.

**Geschäftsberichte und Nachhaltigkeitsreports.** Börsennotierte Unternehmen veröffentlichen Jahresberichte, die optisch dem Print-Layout entsprechen müssen. Hier ist ein PDF-basierter Viewer vertretbar, weil das Layout bindend ist und einzelne Seiten exakte Seitenumbrüche erfordern. Aber auch hier gilt: Die Kerndaten (Finanzkennzahlen, Management-Statements) sollten zusätzlich als HTML verfügbar sein.

## Technische Architektur

E-Paper-Lösungen in TYPO3 lassen sich in drei Kategorien einteilen:

**PDF-basierte Blätterkataloge.** Ein PDF wird hochgeladen, eine JavaScript-Library (Turn.js, FlipBook.js, pdf.js) rendert die Seiten im Browser. Die Library zerlegt das PDF in einzelne Seiten und zeigt sie als Canvas-Elemente an. Vorteile: Schnelle Einrichtung, Layout entspricht 1:1 dem Print. Nachteile: Kein SEO-Wert (Content ist im PDF versteckt), schlechte Performance bei großen PDFs (50+ Seiten), keine Responsiveness.

**HTML-basierte Magazin-Layouts.** Die Artikel werden als normale TYPO3-Inhaltselemente gepflegt und über ein Magazin-Template dargestellt. Das Layout simuliert Magazin-Ästhetik (großflächige Bilder, Textspalten, Pull-Quotes) über CSS Grid und Tailwind. Vorteile: Volle SEO-Indexierung, responsive, performant, barrierearm. Nachteile: Höherer initialer Aufwand, Layout weicht vom Print ab.

**Hybrid-Ansatz.** Die Artikel existieren als HTML, zusätzlich steht ein PDF-Download bereit. Auf der Übersichtsseite sieht der Besucher Artikel-Teaser, in der Seitenleiste den PDF-Download des gesamten Magazins. Dieser Ansatz vereint SEO-Wert und Print-Treue.

Für die PDF-Darstellung in TYPO3 eignet sich pdf.js (Mozilla), eine Open-Source-Library, die PDFs nativ im Browser rendert. pdf.js ist performanter als Turn.js-basierte Blätterkataloge, verzichtet auf Blätteranimationen und bietet stattdessen eine saubere, scrollbare Darstellung mit Zoom und Textsuche.

## Häufige Probleme und Lösungen

**PDF-Ladezeit über 5 Sekunden.** Ein 40-seitiges Magazin als PDF wiegt 20-40 MB. Ohne Optimierung lädt der Browser das gesamte PDF, bevor die erste Seite angezeigt wird. Lösung: pdf.js unterstützt Byte-Range-Requests, bei denen nur die angeforderte Seite geladen wird. Der Server muss `Accept-Ranges: bytes` unterstützen. Zusätzlich das PDF mit Ghostscript oder qpdf für Web optimieren (`linearize`), damit die erste Seite sofort angezeigt wird.

**Content nicht von Google indexiert.** Google crawlt PDFs und indexiert deren Text, aber nicht innerhalb eines JavaScript-Viewers. Wenn das PDF nur über ein Canvas-Element im Browser dargestellt wird, sieht Google keinen Content. Lösung: Den PDF-Inhalt zusätzlich als versteckten Text (aria-hidden, für Screenreader zugänglich) auf der HTML-Seite platzieren oder, besser, den Content als native HTML-Elemente darstellen und das PDF nur als Download anbieten.

**Veraltete Blätterkatalog-Libraries.** Viele E-Paper-Extensions nutzen Libraries, die seit Jahren nicht mehr aktualisiert werden. Turn.js (letztes Update 2013), FlipBook jQuery (jQuery-Abhängigkeit) oder kommerzielle Libraries mit ablaufenden Lizenzen. Lösung: Auf pdf.js oder eine HTML-basierte Darstellung migrieren. Beide sind zukunftssicher und unabhängig von Drittanbieter-Lizenzen.

## Migration und Versions-Kompatibilität

E-Paper-Extensions im TER sind überwiegend veraltet. Die meisten unterstützen maximal TYPO3 v10 oder v11. Für v12 und v13 gibt es keine gepflegten Blätterkatalog-Extensions.

Der empfohlene Weg für TYPO3 v12/v13: pdf.js als Standalone-Library einbinden (kein Extension nötig) für PDF-basierte Darstellungen. Für HTML-basierte Magazine: tx_news mit einem Magazin-Template und eigener Kategorie "Ausgaben". Der Aufwand für ein Custom-Magazin-Layout auf tx_news-Basis liegt bei 3-5 Tagen.

Wer von einer bestehenden E-Paper-Extension migriert, hat drei Optionen: pdf.js-Integration (1-2 Tage, behält das PDF-basierte Modell), HTML-Migration (5-10 Tage, überführt den Content in tx_news-Artikel) oder einen externen Dienst (Issuu, Yumpu) mit TYPO3-Embed. Gosign empfiehlt den HTML-Ansatz für maximalen SEO-Wert und berät bei der Entscheidung zwischen den Varianten.

--- Extension Builder TYPO3 - Erstellen | Gosign ---
> Das Standard-Tool zum Erstellen neuer TYPO3 Extensions. Visueller Editor für Extbase Models, Repositories und Controller. Der Startpunkt jeder.

## Der Extension Builder ist das Scaffolding-Werkzeug, ohne das kein TYPO3-Entwickler wirklich produktiv wird

Der Extension Builder ist seit über zehn Jahren das offizielle Werkzeug, mit dem Entwicklerinnen in TYPO3 neue Extensions aus dem Nichts erzeugen. Wer eine Extbase-Extension mit Domain-Model, Repository, Controller und Backend-Modul benötigt, bekommt über den Extension Builder einen visuellen Editor, der aus einem UML-ähnlichen Domain-Diagramm den kompletten Boilerplate-Code generiert: TCA-Konfiguration, SQL-Schema, ext_localconf, Controller-Stubs, Fluid-Templates, Language-Files. Für Agenturen und Produktteams, die regelmässig eigene Extensions ausliefern, bleibt das Tool der schnellste Weg vom Konzept zum ersten lauffähigen Prototyp.

Die Zielgruppe sind TYPO3-Entwicklungsteams in Agenturen und im Inhouse-Bereich, die über Site Packages hinaus eigene Business-Logik in TYPO3 abbilden. Typisch sind Extensions für Produktkataloge, Event-Management, Job-Portale, Kundenportale oder branchenspezifische Datenstrukturen. Ohne Extension Builder müsste jede dieser Extensions von Hand aus einem leeren Verzeichnis wachsen - mit dem Risiko, dass die Struktur vom TYPO3-Core-Schema abweicht und beim nächsten Upgrade bricht.

## Typische Einsatzszenarien

Ein erstes Szenario ist der Prototyp für ein Kundenportal. Ein Maschinenbauer mit 2.000 Ersatzteilen braucht eine Extension, die Produktfamilien, Produkte und Dokumentationen als eigene Datenstrukturen im Backend verfügbar macht. Der Extension Builder erzeugt in unter 30 Minuten das komplette Gerüst: TCA, Repositories, Controller, List- und Detail-Ansicht. Das Team beginnt sofort mit der Business-Logik statt mit Boilerplate.

Ein zweites Szenario ist die Schulungs- und Einarbeitungssituation. Ein Entwickler, der zum ersten Mal eine TYPO3-Extension baut, lernt durch das generierte Scaffold die Konventionen des Frameworks kennen, ohne sich in Dokumentationen zu verlieren. Der generierte Code ist nicht perfekt, aber er ist idiomatisch und zeigt, wie Extbase gedacht ist.

Ein drittes Szenario ist die Migration bestehender Datenstrukturen. Wer aus einem alten CSV-Export eine neue TYPO3-Extension mit zehn Entitäten aufsetzen muss, kann das Domain-Modell im Extension Builder zusammenklicken, exportieren und im Anschluss den generierten Code mit einem Import-Kommando befüllen. Das spart mehrere Personentage gegenüber einem Handaufbau.

Ein viertes Szenario ist die Standardisierung in einem Agentur-Pool. Ein Dienstleister mit 15 TYPO3-Entwicklern möchte sicherstellen, dass jede neue Extension denselben Grundaufbau hat. Der Extension Builder erzwingt diesen Aufbau durch die Generierung, und eigene Templates für den Code-Generator sorgen dafür, dass Code-Style, Lizenz-Header und Verzeichnisstruktur projektübergreifend identisch bleiben.

## Technische Architektur

Der Extension Builder ist eine klassische TYPO3-Backend-Extension mit eigener Benutzeroberfläche. Im Backend erscheint ein Modul, in dem das Domain-Modell über eine Drag-and-Drop-Oberfläche erstellt wird: Entitäten als Boxen, Properties als Felder, Beziehungen als Linien. Beim Export wird ein JSON-Schema persistiert, aus dem der Generator den kompletten Extension-Code schreibt.

Die Installation erfolgt klassisch über Composer (`friendsoftypo3/extension-builder`). Die Extension hat keine Produktionsrelevanz, sie gehört in die Development-Umgebung und sollte in Production gar nicht erst aktiviert sein. Beim Generieren greift der Builder auf Twig-ähnliche Templates zurück, die sich bei Bedarf projektspezifisch anpassen lassen - etwa um eigene Code-Styles oder abweichende Lizenz-Header zu erzwingen.

Wichtig ist, dass der Extension Builder keinen Roundtrip beherrscht: Wer einmal generiert und dann den Code von Hand erweitert, kann die Extension zwar im Builder öffnen, sollte aber auf keinen Fall erneut generieren - sonst überschreibt der Builder Teile der manuell ergänzten Logik. In der Praxis wird der Builder als einmaliger Scaffold-Schritt verwendet, danach lebt die Extension im Git-Repository.

## Häufige Probleme und Lösungen

Das erste Problem ist die Überschreibungsfalle nach dem ersten Generierungslauf. Teams, die den Builder zum zweiten Mal starten, um ein Feld nachzuziehen, verlieren eigene Code-Änderungen. Die Lösung ist eine klare Regel im Team: Der Extension Builder wird einmal benutzt, der Rest ist Handarbeit. Nachträgliche Feldänderungen erfolgen manuell in TCA, SQL und Model.

Das zweite Problem ist die Kompatibilität mit modernen PHP-Konventionen. Der Generator erzeugt immer noch Code, der an ältere PHP-Versionen und ältere Extbase-Konventionen angelehnt ist. Die Lösung ist ein Cleanup-Pass direkt nach der Generierung: Type-Declarations ergänzen, Return-Types setzen, readonly-Properties einführen, veraltete Annotation-Kommentare durch native Attribute ersetzen.

Das dritte Problem ist die unreflektierte Nutzung als Code-Wunder. Manche Teams erwarten, dass der Extension Builder eine produktionsreife Anwendung ausliefert. Das tut er nicht - er liefert ein Gerüst. Jede Business-Logik, jede Validierung, jedes Security-Konzept bleibt Aufgabe der Entwicklerin.

Ein viertes Problem sind veraltete Backend-Muster im generierten Code. Die mitgelieferten Controller verwenden manchmal noch deprecated Extbase-Patterns, die im aktuellen TYPO3 Deprecation-Warnings erzeugen. Die Lösung ist ein Lint-Schritt direkt nach der Generierung, der den Code gegen die aktuellen Coding Standards prüft und fehlende Type-Deklarationen oder veraltete Annotationen markiert. Moderne Pipelines kombinieren diesen Schritt mit automatischem Code-Rewriting durch Rector, um den Aufwand des Cleanups möglichst klein zu halten.

## Migration und Versions-Kompatibilität

Der Extension Builder ist offiziell für TYPO3 v11 und v12 verfügbar und wird von den Friends of TYPO3 weitergepflegt. Für TYPO3 v13 existiert eine aktualisierte Fassung, die den neuen Extbase-Konventionen folgt. Teams, die bestehende Extensions upgraden, benötigen den Builder dafür in der Regel nicht mehr - das Upgrade läuft über Upgrade-Wizards im Install Tool und manuelle Anpassungen.

Interessanter ist der strategische Blick: In einer Zeit, in der generative KI komplette Extension-Grundgerüste inklusive Business-Logik aus einem Prompt erzeugen kann, verliert der visuelle Builder einen Teil seines ursprünglichen Vorteils. Gosign kombiniert beide Welten: Für Standard-Scaffolds mit vielen Entitäten bleibt der Builder effizient, für anspruchsvolle Extensions mit Domain-spezifischer Logik generieren wir den Code direkt aus einem Fachbriefing mit KI-Unterstützung - und sparen im Vergleich zum klassischen Handaufbau bis zu 80 Prozent der Entwicklungszeit bei gleichzeitig höherer Code-Qualität.

--- FFH TYPO3 - Custom Extension | Gosign ---
> Branchenspezifische TYPO3 Extension. Gosign bietet Custom-Entwicklung und Support für spezielle Extensions, die nicht im TER verfügbar oder nicht.

## Branchenspezifische TYPO3-Extensions scheitern nicht an der Technik, sondern an der Pflege

FFH steht exemplarisch für eine Kategorie von TYPO3-Extensions, die für einen bestimmten Kunden oder eine bestimmte Branche entwickelt wurden: branchenspezifisch, funktional, aber nicht allgemein gepflegt. Im TER finden sich hunderte solcher Extensions. Manche haben 5 Downloads pro Jahr, keine Dokumentation und den letzten Commit vor 3 Jahren. Das bedeutet nicht, dass sie schlecht sind. Es bedeutet, dass sie Pflege brauchen, die der ursprüngliche Entwickler nicht mehr leistet.

Für Unternehmen, die auf solche Extensions angewiesen sind, stellt sich eine praktische Frage: Weiternutzen und selbst pflegen, auf eine Alternative migrieren oder neu entwickeln. Alle drei Wege sind gangbar. Die Entscheidung hängt von der Komplexität der Extension, der Verfügbarkeit von Alternativen und dem TYPO3-Versions-Druck ab.

## Typische Einsatzszenarien

**Branchenverbände mit Spezialanforderungen.** Handwerkskammern, Sportverbände und Berufsgenossenschaften betreiben TYPO3-Websites mit Funktionen, die kein Standard-Plugin abdeckt: Mitgliederverzeichnisse mit Suchradius, Veranstaltungsmanagement mit Qualifizierungspunkten, Branchenregister mit Zertifizierungsstatus. Dafür existieren Custom Extensions, die vor 5-8 Jahren entwickelt wurden und seitdem nur minimal aktualisiert werden. Die Funktion läuft, aber TYPO3-Updates werden zum Risiko.

**Medienunternehmen mit redaktionellen Workflows.** Radiosender, Verlage und Medienhäuser nutzen TYPO3 mit Extensions für Playlists, Programmplanung, Medienarchive oder Content-Syndication. Diese Extensions sind oft intern entwickelt oder von einer Agentur gebaut worden, die das Projekt nicht mehr betreut. Der Code funktioniert auf TYPO3 v9, aber die Migration auf v12 scheitert an veralteten APIs.

**Öffentliche Einrichtungen mit gesetzlichen Anforderungen.** Schulen, Museen und Bibliotheken nutzen Extensions für Öffnungszeiten-Verwaltung, Katalogsuche oder Veranstaltungsbuchung. Die Anforderungen sind spezifisch (z.B. Integration mit einer Bibliothekssoftware wie Koha oder Alma), die Extension wurde einmal gebaut und seitdem nicht aktualisiert.

## Technische Architektur

Branchenspezifische TYPO3-Extensions folgen typischerweise dem Extbase/Fluid-Pattern: Domain-Modell (PHP-Klassen), Repository (Datenbankzugriff), Controller (Geschäftslogik) und Fluid-Templates (Darstellung). Die Daten liegen in eigenen Datenbanktabellen mit `tx_extensionname_` Prefix.

Die häufigsten architekturellen Muster: Plugin-basierte Extensions mit Frontend-Ausgabe (Listendarstellung, Detailansicht, Filterung), Backend-Module für die Datenpflege und Scheduler-Tasks für Import/Export. Viele branchenspezifische Extensions integrieren externe Systeme über REST-APIs oder CSV-Import.

Die Codequalität variiert erheblich. Extensions von professionellen Agenturen folgen TYPO3-Coding-Standards, nutzen Dependency Injection und haben Unit Tests. Intern entwickelte Extensions oder schnell gebaute Auftragsarbeiten haben oft hartcodierte Konfigurationen, fehlende Typisierung und keine Tests. Beides lässt sich pflegen, aber der Aufwand unterscheidet sich um den Faktor 3-5.

Ein typisches Analyse-Muster für branchenspezifische Extensions: Umfang messen (Lines of Code, Anzahl der Klassen, Anzahl der Datenbanktabellen), Abhängigkeiten prüfen (welche TYPO3-APIs werden genutzt, welche sind in v12/v13 deprecated), Testbarkeit bewerten (gibt es Unit Tests, ist der Code testbar strukturiert) und Migration-Aufwand schätzen.

## Häufige Probleme und Lösungen

**Deprecated APIs blockieren das TYPO3-Update.** Die Extension nutzt `$GLOBALS['TSFE']`, `GeneralUtility::_GP()` oder `ObjectManager::get()`, alles APIs, die in TYPO3 v12 deprecated oder entfernt sind. Lösung: Systematisches Refactoring. Jede deprecated API hat einen dokumentierten Ersatz im TYPO3 Changelog. Bei einer Extension mit 5.000 Zeilen Code liegt der Refactoring-Aufwand bei 3-7 Tagen, abhängig von der Anzahl der Deprecations.

**Kein Maintainer verfügbar.** Der ursprüngliche Entwickler hat die Firma verlassen, die Agentur existiert nicht mehr, das TER-Paket ist verwaist. Lösung: Den Code auf GitHub forken, die Extension in das eigene Composer-Repository aufnehmen und selbst pflegen. Oder einen externen Dienstleister beauftragen. Der Fork ist rechtlich unproblematisch, wenn die Extension unter GPL steht (Standard für TYPO3-Extensions).

**Keine Dokumentation.** Weder Inline-Kommentare noch externe Docs. Neue Entwickler müssen den Code lesen, um die Funktion zu verstehen. Lösung: Vor dem Refactoring eine technische Dokumentation erstellen. 2-4 Stunden Analyse reichen für eine Extension mit 3.000-5.000 Zeilen Code, um Architektur, Datenmodell und Geschäftslogik zu dokumentieren.

## Migration und Versions-Kompatibilität

Branchenspezifische Extensions haben naturgemäß keinen offiziellen v12/v13-Support. Die Migration muss individuell geleistet werden. Der Aufwand hängt von drei Faktoren ab:

Erstens: Welche TYPO3-Version ist der Ausgangspunkt? Von v9 auf v12 ist deutlich mehr Arbeit als von v11 auf v12, weil v10 den Middleware-Stack eingeführt hat und v11 die Backend-Module-Registrierung geändert hat.

Zweitens: Wie viele deprecated APIs werden genutzt? TYPO3s Extension Scanner (im Install Tool) zeigt das automatisch. Eine Extension mit 5 Deprecations braucht einen Tag, eine mit 50 braucht eine Woche.

Drittens: Wie gut ist der Code strukturiert? Sauberer Extbase-Code lässt sich mechanisch migrieren. Prozeduraler Code mit direkten Datenbankaufrufen erfordert Umschreibung.

Die drei Optionen: Portierung (Extension auf neue TYPO3-Version anpassen, 3-10 Tage), Neuentwicklung (gleiche Funktion, saubere Architektur, 2-4 Wochen) oder Alternative finden (Standard-Extension, die 80% der Funktion abdeckt, plus Custom-Anpassung). Gosign hat hunderte branchenspezifische TYPO3-Extensions analysiert, portiert und neu entwickelt und berät zur wirtschaftlichsten Option.

--- filefill TYPO3 - Fehlende Dateien laden | Gosign ---
> filefill: Fehlende Dateien automatisch vom Live-Server nachladen. Für Dev- & Staging-Umgebungen. KI-beschleunigt.

## filefill spart Entwicklern und Agenturen Tage Synchronisierungsaufwand - die Extension lädt fehlende Dateien aus fileadmin automatisch vom Produktiv-Server nach, wenn sie tatsächlich gebraucht werden

Wer an einem bestehenden TYPO3-Projekt arbeitet, kennt das Ritual: Das lokale Setup steht, der Datenbank-Dump ist eingespielt, aber auf jeder zweiten Seite erscheinen Platzhalter statt Bilder. Der Grund ist banal: Das fileadmin-Verzeichnis des Live-Systems enthält Gigabyte an Assets, die lokal fehlen. Die klassische Lösung war rsync oder scp über Stunden. filefill schneidet diesen Schritt komplett heraus. Statt alle Dateien vorab zu kopieren, lädt die Extension beim ersten Zugriff genau die benötigte Datei vom konfigurierten Remote-Server nach - on demand, transparent, mit Caching. Für Agenturen, die dauerhaft an mehreren Projekten arbeiten, spart das nicht nur Speicher, sondern auch Stunden pro Setup.

Der Produktivitätsgewinn ist größer als er auf den ersten Blick aussieht. Ein neuer Entwickler ist nicht erst nach einer Stunde Download-Wartezeit arbeitsfähig, sondern nach wenigen Minuten. Ein Code-Review auf einem vergessenen Feature-Branch braucht keinen aktuellen File-Sync. Eine kurze Reproduktion eines Bug-Reports zieht sich nicht durch den halben Tag. Die kleine Extension adressiert damit einen echten Engpass in der täglichen Entwickler-Arbeit.

## Typische Einsatzszenarien

Der häufigste Fall ist das lokale Entwicklungs-Setup. Ein Entwickler klont das TYPO3-Projekt, richtet DDEV oder Docker ein und spielt den aktuellen Datenbank-Dump ein. Statt zusätzlich 30 GB fileadmin-Daten herunterzuladen, konfiguriert er filefill mit der Basis-URL des Live-Systems. Bei jedem Seitenaufruf, der ein Bild oder Dokument anfordert, prüft die Extension, ob die Datei lokal existiert, und lädt sie bei Bedarf nach. Nach ein paar Tagen Arbeit sind nur die tatsächlich benötigten Dateien lokal, der Rest bleibt auf dem Server.

Der zweite Fall sind Staging-Umgebungen. Eine Agentur pflegt für jedes Projekt ein Staging-System, auf dem Redakteure Inhalte vor dem Live-Gang testen. Diese Staging-Systeme müssen nicht alle Bilder vorhalten, sondern nur die der aktuellen Releases. filefill sorgt dafür, dass ältere Inhalte trotzdem funktionieren, weil die Dateien bei Bedarf vom Live-System gezogen werden.

Dritter Einsatz: Disaster Recovery und Hotfix-Szenarien. Wenn ein TYPO3-System schnell auf einer neuen Maschine hochgefahren werden muss - etwa nach einem Serverausfall oder bei einer dringenden Umgebungs-Migration - kann filefill während der ersten Stunden die Asset-Beschaffung überbrücken, bis der vollständige Backup-Restore durch ist.

## Technische Architektur

filefill klinkt sich in das FAL-System von TYPO3 ein, genauer in den Resource-Retrieval-Mechanismus. Sobald TYPO3 eine Datei aus der lokalen Storage anfordert und feststellt, dass sie nicht existiert, greift ein Event-Listener von filefill ein. Die Extension prüft eine Liste konfigurierter "Sources" in der Reihenfolge ihrer Priorität und versucht, die Datei von dort nachzuladen. Erfolgreich geladene Dateien werden lokal gespeichert, sodass der nächste Zugriff ohne Remote-Request auskommt.

Die Konfiguration erfolgt über die Extension-Einstellungen im Install-Tool. Typischerweise wird eine Remote-Source mit Basis-URL, optional mit HTTP-Basic-Auth-Credentials, hinterlegt. Für Setups mit CDN oder S3 kann auch dieser Pfad als Quelle dienen. Die Extension unterstützt mehrere Sources, was für komplexere Szenarien mit getrennten Asset-Servern hilfreich ist.

Wichtig ist, dass filefill nur passiv arbeitet. Die Extension lädt nichts vorab, sondern reagiert ausschließlich auf konkrete Datei-Anfragen. Das macht sie genügsam im Ressourcenverbrauch und unauffällig im Betrieb. Die Integration mit DDEV, Docker Compose oder Lando ist trivial, weil die Extension keine zusätzlichen Services braucht.

## Häufige Probleme und Lösungen

Das erste Problem sind Zugriffsbeschränkungen. Wenn der Live-Server Bilder nur für eingeloggte Nutzer ausliefert oder bestimmte Pfade per htaccess schützt, kann filefill sie nicht ohne weiteres nachladen. Die Lösung liegt in der korrekten Konfiguration der HTTP-Authentifizierung und gegebenenfalls in einer Whitelist-Regel auf dem Live-Server, die der Entwicklungsumgebung Zugriff auf den fileadmin-Pfad gibt.

Zweites Problem: versehentlicher Einsatz in Produktion. Wenn filefill in einer Live-Umgebung aktiv ist und die Remote-Source dieselbe Umgebung ist, entsteht eine gefährliche Rekursion. Die Extension sollte niemals in Produktion laufen. Die pragmatische Lösung ist, filefill nur im Composer-Block "require-dev" zu führen und über Environment-Variablen zu aktivieren, nicht über das Install-Tool.

Drittes Problem: inkonsistente Datei-Stände. Wenn das Live-System eine Datei austauscht, aber die lokale Kopie bereits gecached ist, sieht der Entwickler die alte Version. Die Lösung ist ein gelegentliches Leeren des lokalen fileadmin oder ein Cache-Busting über die Remote-Source. Für die tägliche Arbeit ist das selten ein Problem, weil Dateinamen bei Austausch normalerweise neu sind.

## Migration und Versions-Kompatibilität

filefill ist mit TYPO3 v11, v12 und v13 kompatibel und wird aktiv weiterentwickelt. Bei Upgrades sollte die Extension-Version zur TYPO3-Version passen, weil das FAL-Event-System zwischen v11 und v12 kleinere Änderungen erfahren hat. Wer die Extension in bestehenden Entwicklungsprozessen nutzt, muss bei größeren Upgrades kurz testen, ob alle Sources noch korrekt erreichbar sind.

Eine verwandte Lösung ist EXT:aus_driver_amazon_s3, die fileadmin direkt in einem S3-Bucket hält. Der Unterschied: aus_driver_amazon_s3 ist eine Produktions-Lösung, filefill eine Entwicklungs-Hilfe. Beide ergänzen sich - ein Projekt mit S3-Storage in Produktion kann filefill lokal einsetzen, um nur die aktuell bearbeiteten Dateien aus dem Bucket zu ziehen.

Für Agenturen, die filefill standardisiert einsetzen, bietet sich eine Dokumentation im Projektwiki an, die erklärt, wie die Extension aktiviert wird, welche Credentials nötig sind und wie man bei Problemen vorgeht. Das reduziert den Support-Aufwand im Team und macht das Onboarding neuer Entwickler verlässlich. Ergänzend lohnt sich ein kurzes Skript, das beim Setup einer neuen lokalen Umgebung die richtige Konfiguration automatisch einträgt.

Gosign installiert und konfiguriert filefill in Entwicklungsumgebungen und integriert die Extension in DDEV- und Docker-Setups, sodass neue Projektmitglieder innerhalb weniger Minuten einsatzfähig sind.

--- Find TYPO3 - Solr-Suche | Gosign ---
> Solr-basierte Such-Extension für TYPO3. Alternative zum Standard-EXT:solr-Stack. Flexible Such-Konfiguration, Faceted Search, Autocomplete. Gosign.

## TYPO3s eingebaute Suche reicht bis 500 Seiten, danach braucht man Solr

Die Standard-Suche in TYPO3 (EXT:indexed_search) durchsucht den gerenderten HTML-Output und speichert ihn in einer Datenbank-Tabelle. Für kleine Websites mit 50-500 Seiten funktioniert das. Ab 1.000 Seiten wird die Suche langsam (Antwortzeiten über 2 Sekunden), ab 5.000 Seiten unbrauchbar. EXT:find ist eine Solr-basierte Such-Extension, die eine Alternative zum etablierten EXT:solr-Stack bietet: flexiblere Konfiguration, eigene Query-Builder und eine andere Herangehensweise an Faceted Search.

Die Entscheidung zwischen EXT:find und EXT:solr ist keine Qualitätsfrage, sondern eine Architektur-Frage. EXT:solr hat die größere Community und mehr Features out-of-the-box. EXT:find bietet mehr Flexibilität bei der Query-Konfiguration und eignet sich für Projekte mit ungewöhnlichen Suchanforderungen.

## Typische Einsatzszenarien

**Fachportale mit domänenspezifischer Suche.** Ein Rechtsportal mit 15.000 Dokumenten braucht Suche nach Paragraphen, Aktenzeichen und Stichworten gleichzeitig. EXT:find erlaubt die Definition verschiedener Query-Typen pro Suchfeld: exakte Suche für Aktenzeichen, Fuzzy-Suche für Freitext, Range-Filter für Datumsfelder. Bei einem Fachverlag mit 22.000 Dokumenten lieferte EXT:find Suchergebnisse in unter 100 Millisekunden, unabhängig von der Komplexität der Filterung.

**E-Commerce-Suche mit Produktattributen.** Produkte haben Attribute (Farbe, Größe, Gewicht, Preis), die als Facetten in der Suche dienen. Ein Besucher sucht "Schraube M8", filtert nach Material "Edelstahl" und Preis "unter 5 EUR". EXT:find bildet diese Facetten direkt auf Solr-Felder ab und erzeugt die Filter-Navigation automatisch aus der Solr-Konfiguration.

**Mehrsprachige Volltextsuche.** Internationale Websites brauchen Suche, die sprachspezifische Besonderheiten berücksichtigt: deutsche Komposita (Donaudampfschifffahrt = Donau + Dampf + Schifffahrt), polnische Deklination, spanische Akzente. Solr bringt Sprachanalyzer für 30+ Sprachen mit. EXT:find konfiguriert pro Sprache den passenden Analyzer und erzeugt sprachspezifische Solr-Cores.

## Technische Architektur

EXT:find kommuniziert mit einem Apache Solr Server über HTTP/JSON. Die Architektur besteht aus drei Komponenten: dem Solr-Server (Indexierung und Suche), dem Indexer (schreibt TYPO3-Inhalte in Solr) und dem Frontend-Plugin (Sucheingabe, Ergebnisse, Facetten).

Der Indexer durchläuft die TYPO3-Seitenstruktur und sendet den Content jeder Seite als JSON-Dokument an Solr. Dabei werden nicht nur die sichtbaren Inhalte indexiert, sondern auch Metadaten: Seitentitel, Beschreibung, Kategorien, Keywords und Custom-Felder. Die Indexierung läuft als Scheduler-Task (empfohlen: nach jedem Content-Update oder nachts als Full-Index).

EXT:find unterscheidet sich von EXT:solr in der Query-Ebene. Statt einer festen Suchabfrage-Struktur bietet find einen konfigurierbaren Query-Builder: Über TypoScript oder FlexForm lässt sich definieren, welche Solr-Felder durchsucht werden, mit welcher Gewichtung (Boosting), welche Filter automatisch angewendet werden und wie die Ergebnisse sortiert werden.

Die Facetten-Konfiguration erfolgt über Solr-Feld-Definitionen. Jedes Feld, das als Facette dienen soll, muss in der Solr-Schema-Konfiguration als `facet`-Feld definiert sein. EXT:find liest die verfügbaren Facetten aus der Solr-Konfiguration und rendert sie als Filter-Menü im Frontend. Die Filter arbeiten per GET-Parameter, was SEO-freundliche URLs für gefilterte Ergebnisseiten ermöglicht.

## Häufige Probleme und Lösungen

**Solr-Server-Setup und Wartung.** Solr ist ein Java-basierter Server, der separat betrieben werden muss. Für TYPO3-Agenturen ohne Java-Erfahrung ist das Setup eine Hürde: JVM-Konfiguration, Solr-Core-Management, Schema-Aktualisierung, Monitoring. Lösung: Managed Solr nutzen (z.B. Websolr, SearchStax) oder Solr als Docker-Container betreiben. Das offizielle Solr-Docker-Image reduziert das Setup auf 3 Befehle.

**Suchqualität ist schlecht.** Besucher suchen "Kontakt" und finden 200 Ergebnisse, weil das Wort auf jeder Seite im Footer steht. Lösung: Feldgewichtung konfigurieren. Titel-Treffer werden 10x höher gewichtet als Body-Treffer, H2-Treffer 5x höher als Fließtext. EXT:find erlaubt diese Gewichtung per TypoScript: `plugin.tx_find.settings.boostFields.title = 10`.

**Index wird nicht aktualisiert.** Redakteure ändern Content, aber die Suche zeigt alte Ergebnisse. Ursache: Der Indexer-Scheduler läuft nicht oder ist fehlgeschlagen. Lösung: Den Scheduler-Task auf kurze Intervalle setzen (alle 15 Minuten für Delta-Index, nachts für Full-Index) und einen Monitoring-Alert einrichten, der bei Index-Fehlern benachrichtigt.

## Migration und Versions-Kompatibilität

EXT:find unterstützt TYPO3 v10 und v11 mit Solr 8 und 9. Für TYPO3 v12 existiert eine Beta-Version auf GitHub. Die Extension wird von der Stabsstelle Forschung und Entwicklung der SUB Göttingen gepflegt und hat eine akademische Nutzerbasis.

EXT:solr ist die populärere Alternative mit offizieller v12-Unterstützung und kommerziellen Support-Optionen (dkd Internet Service GmbH). Für die meisten TYPO3-Projekte ist EXT:solr die sichere Wahl. EXT:find empfiehlt sich für Projekte mit besonderen Query-Anforderungen (akademische Suche, Fachdatenbanken, Multi-Index-Szenarien).

Die Migration von EXT:indexed_search auf Solr (egal ob find oder solr) erfordert: Solr-Server aufsetzen, Schema konfigurieren, Content indexieren und Frontend-Templates anpassen. Der Aufwand liegt bei 3-5 Tagen für eine Standard-Website und 1-2 Wochen für komplexe Portale. Gosign berät zum passenden Such-Stack und übernimmt Setup, Konfiguration und Feintuning der Suchqualität.

--- FlexSlider TYPO3 - Migration | Gosign ---
> Legacy-Slider-Extension für TYPO3. Gosign migriert auf Swiper oder Splide: kein jQuery, bessere Performance, native Touch-Events, bessere Core Web.

## FlexSlider ist seit 2015 veraltet, aber immer noch auf tausenden TYPO3-Websites aktiv

FlexSlider war zwischen 2012 und 2015 einer der beliebtesten Slider für Websites: jQuery-basiert, responsive, mit Animations-Optionen. Die jQuery-Library FlexSlider.js hatte auf GitHub über 10.000 Stars. Das letzte Update erschien 2015. Seitdem hat sich die Web-Entwicklung fundamental verändert: jQuery ist nicht mehr nötig, Core Web Vitals bestrafen schwere JavaScript-Libraries, und Touch-Events funktionieren nativ ohne Library. Trotzdem läuft FlexSlider auf tausenden TYPO3-Websites, weil die Migration nie Priorität hatte.

Die TYPO3-Extension EXT:flexslider bindet die FlexSlider.js-Library ein und bietet ein Backend-Plugin zur Konfiguration von Slides (Bild, Text, Link, Animations-Effekt). Die Extension selbst ist nicht mehr gepflegt und unterstützt maximal TYPO3 v10. Jede TYPO3-Website mit FlexSlider hat ein Migrations-Thema.

## Typische Einsatzszenarien

**Startseiten-Slider mit wechselnden Kampagnenbildern.** Der klassische Einsatz: 3-5 großformatige Bilder auf der Startseite, die automatisch durchrotieren. Marketing wechselt die Slider-Inhalte saisonal. Diese Slider laden typischerweise 3-5 Bilder gleichzeitig (15-25 MB Daten), dazu jQuery (90 KB) und FlexSlider.js (30 KB). Das Ergebnis: 4+ Sekunden Ladezeit für den sichtbaren Bereich (LCP). Die moderne Alternative: Ein einzelnes Hero-Bild statt Slider (höhere Conversion laut A/B-Tests) oder ein CSS-basierter Slider ohne JavaScript.

**Produkt-Bildergalerien mit Thumbnails.** FlexSlider wurde oft als Thumbnail-Galerie auf Produktseiten eingesetzt: großes Hauptbild oben, Thumbnail-Leiste unten. Beim Klick auf ein Thumbnail wechselt das Hauptbild. Diese Funktion lässt sich heute mit 30 Zeilen CSS und 10 Zeilen Vanilla JavaScript umsetzen, ohne externe Library.

**Testimonial-Karussells.** Kundenstimmen als rootierende Zitate, oft mit Autoplay-Animation. FlexSlider bot dafür einen "Carousel"-Modus. Moderne Alternative: CSS Scroll Snap mit `scroll-behavior: smooth`. Kein JavaScript nötig, volle Touch-Unterstützung, unter 1 KB Code.

## Technische Architektur

EXT:flexslider besteht aus drei Teilen: einem Content-Element-Plugin (FlexForm mit Slide-Konfiguration), Fluid-Templates für die Frontend-Darstellung und der FlexSlider.js-Library mit jQuery als Abhängigkeit.

Im Backend konfiguriert der Redakteur: Anzahl der Slides, Bild, Überschrift, Text, Link, Animations-Effekt (slide, fade), Autoplay (ja/nein), Autoplay-Geschwindigkeit, Navigation (Pfeile, Punkte, Thumbnails) und Responsive-Breakpoints. Die Daten werden in der FlexForm-XML-Struktur des Content-Elements gespeichert.

Im Frontend lädt TYPO3 jQuery (falls nicht bereits vorhanden), flexslider.js und flexslider.css. Ein Initialisierungs-Script aktiviert den Slider mit den konfigurierten Optionen. Das Rendering erfolgt als `<div class="flexslider"><ul class="slides"><li>` Struktur.

Die Performance-Probleme sind architekturbedingt: FlexSlider lädt alle Slides beim Seitenaufruf (kein Lazy Loading), jQuery blockiert das Rendering (render-blocking Resource), die Animations-Engine nutzt JavaScript statt CSS-Transitions (höherer CPU-Verbrauch auf Mobilgeräten).

## Häufige Probleme und Lösungen

**Schlechte Core Web Vitals durch FlexSlider.** LCP über 4 Sekunden, CLS über 0.25 (Layout-Shift beim Laden), TBT über 300ms (JavaScript-Blocking). Das ist kein Tuning-Problem, das ist ein Architektur-Problem. Lösung: FlexSlider durch eine moderne Alternative ersetzen. Swiper (kein jQuery, Lazy Loading, CSS-Transitions) oder Splide (leichter als Swiper, 29 KB statt 140 KB) sind die Standardalternativen. Noch besser: keinen Slider verwenden und durch ein statisches Hero-Element ersetzen.

**jQuery-Konflikte.** TYPO3 v12 liefert kein jQuery mehr im Core. FlexSlider braucht jQuery. Wer jQuery nur für FlexSlider einbindet, lädt 90 KB für eine Library, die sonst nirgends genutzt wird. Lösung: Bei der Slider-Migration jQuery komplett entfernen und alle jQuery-abhängigen Komponenten gleichzeitig migrieren.

**Responsive Bilder funktionieren nicht.** FlexSlider kennt kein `<picture>`-Element und kein `srcset`. Jedes Gerät lädt dasselbe Bild, egal ob Desktop (1920px) oder Smartphone (375px). Lösung: Swiper und Splide unterstützen `srcset` und `<picture>` nativ. Bei der Migration werden die Bilder über TYPO3s Image-Processing in mehreren Größen erzeugt und per `srcset` ausgeliefert.

## Migration und Versions-Kompatibilität

FlexSlider hat keine TYPO3 v12- oder v13-Kompatibilität und wird keine bekommen. Die jQuery-Library ist End-of-Life. Jedes TYPO3-Projekt, das auf v12/v13 migriert, muss FlexSlider ersetzen.

Die Migration erfolgt in vier Schritten: erstens die bestehenden Slider-Daten exportieren (Bilder, Texte, Links aus der FlexForm-Konfiguration), zweitens ein neues Content-Element mit Swiper oder Splide aufsetzen (als Custom Content Element im Sitepackage), drittens die Slider-Daten in die neue Struktur importieren und viertens die alten FlexSlider-Referenzen auf das neue Element migrieren (SQL-Update der tt_content-Tabelle).

Der Migrationsaufwand liegt bei 1-2 Tagen für den technischen Umbau und 0,5-1 Tag für die Datenmigration bei 10-20 Slidern. Die Alternative ohne Slider (statisches Hero-Element) ist noch schneller: 0,5 Tage für das neue Template, die Daten des ersten Slides werden übernommen, die restlichen entfallen.

Gosign empfiehlt bei jeder FlexSlider-Migration die Grundsatzfrage: Brauchen Sie wirklich einen Slider? A/B-Tests zeigen konsistent, dass statische Hero-Elemente höhere Conversion-Raten erzielen als rotierende Slider. Falls doch ein Slider nötig ist, liefert Gosign die Migration auf Swiper oder Splide inklusive Performance-Optimierung.

--- Flipbook TYPO3 - PDF-Blätterbuch | Gosign ---
> Alternative Flipbook-Extension für TYPO3 (neben rflipbook). PDF-Blätterbuch-Darstellung mit Page-Flip-Effekt. Gosign empfiehlt.

## Flipbooks sahen 2012 beeindruckend aus, kosten heute Performance und Barrierefreiheit

Der Blättereffekt war eine der beliebtesten Darstellungsformen für Kataloge, Jahresberichte und Magazine auf Unternehmenswebsites. Ein PDF wird in einzelne Seiten zerlegt, im Browser als Buch dargestellt und per Mausklick oder Wischgeste umgeblättert. Die Technik stammt aus der Flash-Ära. Seit dem Ende von Flash (2020) basieren Flipbook-Lösungen auf JavaScript und Canvas. Die Grundidee hat sich aber nicht geändert: Es geht um die visuelle Simulation eines physischen Dokuments.

Das Problem: Flipbooks sind Performance-Killer. Ein 40-seitiges PDF wird in 40 Einzelbilder konvertiert (je 200 bis 500 KB), dazu kommt die JavaScript-Library (100 bis 300 KB minifiziert). Ergebnis: 10 bis 20 MB Payload für ein einzelnes Content-Element. Auf Mobilgeräten sind Flipbooks kaum bedienbar, Screenreader können die Inhalte nicht lesen, und Google indexiert den Text nicht, weil er in Bildern steckt.

## Typische Einsatzszenarien

**Unternehmensberichte und Jahresabschlüsse.** Vorstände wollen den Geschäftsbericht "wie gedruckt" auf der Website zeigen. Die Druckagentur liefert ein PDF, das Marketing-Team will es 1:1 online stellen. Flipbook scheint die einfachste Lösung. Gosign empfiehlt hier eine Alternative: den Bericht als HTML-Seite aufbereiten (suchbar, barrierefrei, responsive) und das PDF als Download-Link daneben stellen. Das erfordert mehr Aufwand, liefert aber SEO-Wert und Barrierefreiheit.

**Produktkataloge mit vielen Seiten.** Industrieunternehmen mit 200-Seiten-Katalogen nutzen Flipbooks als "Blätterkatalog" auf der Website. Die Realität: Nutzer blättern maximal 5 bis 10 Seiten, bevor sie abbrechen. Ein durchsuchbarer HTML-Katalog mit Filter und Produktdetailseiten konvertiert besser. Wenn der Blättereffekt gewünscht ist, reicht ein Lightbox-Slider mit den wichtigsten Seiten als Vorschau.

**Immobilien-Exposés und Broschüren.** Maklerbüros zeigen Exposés als Flipbook, damit Interessenten ein Gefühl für das gedruckte Dokument bekommen. Hier reicht oft ein eingebetteter PDF-Viewer (pdf.js) ohne Blättereffekt, der auf allen Geräten funktioniert und den Text durchsuchbar lässt.

## Technische Architektur

Die Flipbook-Extension für TYPO3 (wie auch rflipbook, die andere populäre Variante) arbeitet in drei Schritten. Erst wird das PDF serverseitig in Einzelbilder konvertiert (über ImageMagick, Ghostscript oder einen externen Service). Dann werden die Bilder in einer Canvas-basierten JavaScript-Bibliothek (turn.js, StPageFlip oder eine kommerzielle Lösung) gerendert. Der Blättereffekt wird per CSS3-Transform und JavaScript-Animation erzeugt.

Die TYPO3-Integration erfolgt als Content-Element: Redakteur lädt ein PDF hoch, wählt Optionen (Seitenbereich, Thumbnail-Grösse, Effekt-Geschwindigkeit), das Frontend rendert das Flipbook. Die konvertierten Bilder werden im fileadmin oder in einem Cache-Verzeichnis gespeichert.

Abhängigkeiten: ImageMagick oder Ghostscript muss auf dem Server installiert sein (für die PDF-Konvertierung). Die JavaScript-Bibliothek wird als Asset eingebunden. Bei turn.js (die bekannteste Library) muss jQuery geladen werden, was auf modernen Websites ein zusätzlicher Performance-Nachteil ist.

## Häufige Probleme und Lösungen

**Bilder werden nicht generiert.** Die PDF-Konvertierung scheitert, wenn Ghostscript nicht installiert ist, eine falsche Version läuft oder die Rechte für das Ausgabeverzeichnis fehlen. Lösung: `gs --version` auf dem Server prüfen (mindestens 9.50), Ausgabeverzeichnis mit Schreibrechten für den Webserver-User versehen, bei Shared Hosting den Provider kontaktieren.

**Ladezeit über 5 Sekunden.** Ein 80-Seiten-PDF erzeugt Dutzende hochauflösende Bilder. Lösung: Bildqualität reduzieren (72 dpi statt 150 dpi für Web-Darstellung), Lazy Loading für Seiten ausserhalb des sichtbaren Bereichs implementieren, WebP statt PNG/JPEG verwenden. Oder die grundsätzliche Frage stellen: Braucht es wirklich ein Flipbook?

**Mobilgeräte zeigen Darstellungsfehler.** Der Blättereffekt funktioniert auf Touch-Geräten nur eingeschränkt. Der 3D-Page-Turn-Effekt ist auf kleinen Bildschirmen kaum sichtbar, und die Wischgeste kollidiert mit dem Browser-Scroll. Lösung: Auf Mobilgeräten automatisch auf einen einfachen Slider oder den nativen PDF-Viewer zurückfallen.

## Migration und Versions-Kompatibilität

Die Flipbook-Extension hat eingeschränkten Support für aktuelle TYPO3-Versionen. Die letzte stabile Version unterstützt TYPO3 v10 und v11. Für v12 und v13 gibt es keinen offiziellen Release (Stand April 2026). rflipbook, die alternative Extension, ist in einer ähnlichen Situation.

Gosign empfiehlt bei einem TYPO3-Upgrade die Ablösung des Flipbooks durch eine der folgenden Alternativen: PDF-Viewer auf Basis von pdf.js (Open Source, keine Konvertierung nötig, Text bleibt suchbar), HTML-Aufbereitung des Inhalts (maximale SEO-Wirkung, volle Barrierefreiheit) oder ein Lightbox-Slider mit ausgewählten Seiten als Bilder (visueller Kompromiss, gute Performance). Die Migration ist in der Regel in 1 bis 2 Tagen abgeschlossen, weil der Inhalt bereits als PDF vorliegt und nur die Darstellungsform wechselt.

Für Unternehmen, die regelmässig neue Publikationen veröffentlichen (quartalsweise Kundenmagazine, jährliche Geschäftsberichte), lohnt sich ein automatisierter Workflow: PDF hochladen, serverseitig per pdf.js rendern, Vorschaubilder generieren, Volltext für die Suche extrahieren. TYPO3 kann diesen Prozess über einen Scheduler-Task automatisieren, sodass Redakteure nur noch das PDF hochladen und die Darstellung automatisch erfolgt. Der Initialaufwand für diesen Workflow liegt bei 3 bis 5 Entwicklungstagen, spart aber bei jeder neuen Publikation 2 bis 4 Stunden manueller Arbeit.

Ein weiterer Aspekt ist die Barrierefreiheit. Flipbooks sind für Screenreader-Nutzer vollständig unzugänglich, weil der Text in Bildern steckt. Das Barrierefreiheitsstärkungsgesetz (BFSG), das ab Juni 2025 gilt, betrifft auch digitale Publikationen auf Unternehmenswebsites. Die Umstellung auf HTML-basierte Darstellungen oder pdf.js (das den Originaltext rendert) ist damit nicht nur eine Performance-Frage, sondern auch eine rechtliche Notwendigkeit. Gosign prüft bei jedem Relaunch-Projekt, ob Flipbooks oder vergleichbare bildbasierte Darstellungen vorhanden sind und schlägt barrierefreie Alternativen vor, bevor das BFSG greift.

--- FlowFact TYPO3 - Immobilien-CRM | Gosign ---
> FlowFact in TYPO3: Immobilien-Listings, Objekt-Sync, Exposé. OpenImmo-Integration. KI-beschleunigt.

## Immobilienmakler verlieren Leads, wenn Objekte manuell auf die Website übertragen werden

Ein Makler pflegt sein Objektportfolio in FlowFact: Fotos, Grundrisse, Preise, Ausstattungsmerkmale, Exposé-Texte. Dieselben Daten sollen auf der eigenen Website erscheinen, auf ImmobilienScout24, auf Immowelt und in gedruckten Exposés. Ohne automatische Synchronisation tippt jemand die Daten doppelt ein, vergisst die Aktualisierung nach einer Preisänderung oder veröffentlicht ein bereits verkauftes Objekt. Die Folge: falsche Inserate, verärgerter Kundenkontakt, verlorene Leads.

FlowFact (seit 2019 Teil der Hypoport-Gruppe) ist eines der meistgenutzten CRM-Systeme in der deutschen Immobilienbranche. Über 10.000 Makler arbeiten damit. Die TYPO3-Anbindung synchronisiert Objekte automatisch von FlowFact auf die Makler-Website, ohne manuellen Eingriff. Gosign hat diese Integration für Maklerbüros mit 50 bis 2.000 aktiven Objekten umgesetzt.

## Typische Einsatzszenarien

**Regionale Maklerbüros mit eigener Website.** Ein Immobilienbüro mit 3 bis 10 Maklern pflegt 200 bis 500 aktive Objekte in FlowFact. Die Website zeigt Listings mit Suchfunktion (PLZ, Zimmeranzahl, Preisbereich, Objektart), Detailseiten mit Bildergalerie und Grundriss, Exposé-Download als PDF und ein Kontaktformular, das die Anfrage direkt an den zuständigen Makler in FlowFact routet. Neue Objekte erscheinen innerhalb von 15 Minuten auf der Website, Statusänderungen (verkauft, reserviert) werden automatisch übernommen.

**Projektentwickler und Bauträger.** Unternehmen, die Neubauprojekte vermarkten, brauchen neben der Objektsuche auch Projekt-Landingpages mit Baubeschreibung, Lageplan und Wohnungsübersicht als interaktive Tabelle. FlowFact liefert die Objekt-Daten, TYPO3 die redaktionelle Umgebung für Projekttexte und Marketing-Content. Beide Welten werden über die API verknüpft.

**Hausverwaltungen mit Mieter-Portal.** Hausverwaltungen nutzen FlowFact zur Verwaltung von Mietobjekten. Die TYPO3-Website zeigt freie Wohnungen, sammelt Bewerbungen über ein Formular und leitet sie als Kontakt in FlowFact weiter. Besonderheit: Die Objektliste filtert automatisch nach "zur Vermietung", nicht nach "zum Verkauf".

## Technische Architektur

Die Verbindung zwischen FlowFact und TYPO3 läuft über zwei mögliche Schnittstellen. Der klassische Weg ist OpenImmo, ein XML-basierter Branchenstandard für den Austausch von Immobiliendaten. FlowFact exportiert Objekte als OpenImmo-XML (manuell oder per Scheduler), ein TYPO3-Importer liest die Dateien ein und erstellt Datensätze. Extensions wie openimmo (von justimmo) oder Custom-Importer verarbeiten die XML-Struktur.

Der modernere Weg ist die FlowFact REST-API (seit FlowFact v3). Der TYPO3-Server ruft Objektdaten, Bilder und Kontakte per HTTP-Requests ab und synchronisiert sie in die lokale Datenbank. Vorteile gegenüber OpenImmo: Echtzeit-fähig (Polling alle 5 Minuten statt täglichem Export), granulare Updates (nur geänderte Felder) und Zugriff auf FlowFact-spezifische Daten, die im OpenImmo-Standard nicht enthalten sind (z.B. interne Notizen, Lead-Status).

Auf der TYPO3-Seite werden Objekte als Datensätze in einer eigenen Tabelle gespeichert (nicht als TYPO3-Seiten). Listing-Seiten nutzen Extbase-Repositories mit Filterfunktionen. Detailseiten werden über eine Show-Action gerendert, die Bilder aus FAL (File Abstraction Layer) lädt und Grundrisse als Overlay anzeigt. Die Karteneinbindung erfolgt über Leaflet oder Google Maps, wobei die Geokoordinaten aus FlowFact übernommen werden.

## Häufige Probleme und Lösungen

**Bilder fehlen nach dem Import.** OpenImmo-Exporte referenzieren Bilder als Dateinamen, liefern die Dateien aber nicht immer mit. Lösung: Den Export so konfigurieren, dass Bilder als Base64 im XML eingebettet oder per FTP parallel zum XML übertragen werden. Bei der REST-API werden Bilder über eigene Endpunkte heruntergeladen und müssen als FAL-Referenzen in TYPO3 importiert werden.

**Objekte verschwinden nach dem Sync.** Wenn FlowFact ein Objekt deaktiviert oder löscht, muss der TYPO3-Importer entscheiden: Datensatz löschen, ausblenden oder als "verkauft" markieren? Standard-Importer löschen oft rigoros. Lösung: Einen Soft-Delete implementieren, der Objekte zunächst als "inaktiv" markiert und erst nach 30 Tagen physisch entfernt. So bleiben SEO-relevante URLs erhalten und können per 301-Redirect auf die Übersichtsseite zeigen.

**Kontaktformular-Anfragen landen im Nirgendwo.** Das Kontaktformular sendet eine E-Mail, aber der Lead wird nicht in FlowFact als Kontakt angelegt. Lösung: Formular-Anfragen über die FlowFact-API als Kontakt mit Objekt-Bezug anlegen. Der zuständige Makler sieht den Lead direkt in seinem Dashboard. Dafür braucht das Formular die FlowFact-Objekt-ID als Hidden Field.

## Migration und Versions-Kompatibilität

FlowFact hat 2019 eine komplett neue Plattform (FlowFact v3) eingeführt. Die alte Version (FlowFact Classic) wird noch betrieben, erhält aber keine neuen Features. Die REST-API ist nur in v3 verfügbar. Bestehende OpenImmo-Integrationen funktionieren mit beiden Versionen, aber der API-basierte Ansatz ist nur mit v3 möglich.

Auf TYPO3-Seite gibt es keine offizielle FlowFact-Extension mit v12/v13-Support im TER. Die meisten Installationen nutzen Custom-Importer oder die openimmo-Extension (mit Anpassungen). Gosign empfiehlt bei TYPO3-Upgrades auf v12+, die Immobilien-Anbindung gleichzeitig auf die FlowFact-REST-API umzustellen, statt den OpenImmo-XML-Workflow zu portieren. Der API-basierte Ansatz ist wartungsärmer und ermöglicht Features wie Echtzeit-Verfügbarkeit, die mit XML-Export nicht umsetzbar sind.

Für Maklerbüros, die neben FlowFact auch ImmobilienScout24, Immowelt oder Immonet bespielen, ist die Multi-Portal-Synchronisation ein wichtiges Thema. FlowFact kann Objekte an alle grossen Portale gleichzeitig exportieren. Die TYPO3-Website wird dann zu einem weiteren Kanal, der aber den Vorteil hat, dass der Makler dort das Design und die Lead-Generierung vollständig kontrolliert. Gosign richtet die Synchronisation so ein, dass FlowFact als Single Source of Truth dient: Jede Objektänderung fliesst automatisch an die Website und an die Portale, ohne dass Daten manuell abgeglichen werden müssen.

Ein typisches FlowFact-TYPO3-Integrationsprojekt (Objektimport, Suchfunktion, Detailseiten, Kontaktformular mit Lead-Routing) kalkuliert Gosign mit 10 bis 15 Entwicklungstagen. Die laufende Wartung beschränkt sich auf API-Updates und gelegentliche Anpassungen bei Feld-Änderungen im FlowFact-Schema.

--- fluid_fpdf TYPO3 - PDF aus Templates | Gosign ---
> fluid_fpdf: PDFs aus Fluid Templates generieren. Rechnungen, Zertifikate, Reports. KI-beschleunigte Umsetzung.

## Wenn PDFs aus Daten entstehen statt aus Screenshots, braucht man fluid_fpdf

Es gibt zwei grundsätzlich verschiedene Ansätze, PDFs in TYPO3 zu erzeugen. Der Screenshot-Ansatz (web2pdf): Die gerenderte Webseite wird als Bild erfasst und in ein PDF gepackt. Einfach, aber das Ergebnis sieht wie eine gedruckte Webseite aus, mit Navigation, Footer und Responsive-Artefakten. Der datengetriebene Ansatz (fluid_fpdf): Ein Fluid-Template definiert das PDF-Layout, TYPO3-Daten füllen die Platzhalter, das Ergebnis ist ein sauberes Dokument mit Corporate Design. Rechnungen, Zertifikate, Angebote, Berichte, alles, was als Dokument existieren muss, braucht den datengetriebenen Ansatz.

fluid_fpdf nutzt die FPDF-Library (eine schlanke PHP-Klasse zur PDF-Erzeugung) und verbindet sie mit TYPO3s Fluid-Template-Engine. Das Ergebnis: Entwickler schreiben PDF-Layouts in derselben Template-Sprache, die sie für HTML-Templates nutzen.

## Typische Einsatzszenarien

**Automatisierte Rechnungserstellung.** Ein Online-Shop oder Buchungssystem in TYPO3 erzeugt bei jeder Bestellung eine Rechnung. Die Rechnungsdaten (Posten, Preise, Kundendaten, Steuern) kommen aus der Datenbank, das Layout aus einem Fluid-Template. Bei einem Veranstaltungsanbieter generiert fluid_fpdf 200-300 Rechnungen pro Monat ohne manuellen Eingriff. Jede Rechnung trägt Rechnungsnummer, Firmenlogo, Bankverbindung und gesetzlich vorgeschriebene Pflichtangaben.

**Teilnahmezertifikate und Bestätigungen.** Bildungsträger, Verbände und Unternehmen vergeben Zertifikate nach Schulungen, Workshops oder Prüfungen. Der Teilnehmername, das Datum, der Kursname und die Unterschrift des Trainers werden automatisch aus den TYPO3-Daten übernommen. Bei einem Bildungsträger mit 5.000 Teilnehmern pro Jahr spart die Automatisierung circa 250 Arbeitsstunden, die zuvor für die manuelle PDF-Erstellung in InDesign anfielen.

**Angebote und Exposés.** Immobilienmakler, Beratungsunternehmen und Agenturen erstellen Angebote mit variablen Inhalten: Kundendaten, ausgewählte Leistungen, individuelle Preise. Das PDF-Layout ist fest (Corporate Design), die Inhalte variieren. fluid_fpdf füllt das Template mit den Daten aus einem TYPO3-Formular oder einem Backend-Modul.

## Technische Architektur

fluid_fpdf verbindet zwei Systeme: TYPO3s Fluid-Template-Engine und die FPDF-Library. Die Architektur arbeitet in drei Schritten.

Erstens: Das Fluid-Template definiert die PDF-Struktur. Anstatt HTML-Tags verwendet das Template spezielle ViewHelpers für PDF-Elemente: `<fpdf:page>` für eine neue Seite, `<fpdf:cell>` für eine Textzelle, `<fpdf:image>` für ein Bild, `<fpdf:line>` für eine Linie. Die Syntax ist Fluid, die Ausgabe ist kein HTML, sondern FPDF-Befehle.

Zweitens: TYPO3 stellt die Daten bereit. Über einen Controller oder DataProcessor werden die benötigten Daten (Rechnungsposten, Kundendaten, Produktinformationen) an das Template übergeben. Das funktioniert identisch zum Daten-Handling in HTML-Fluid-Templates: `{invoice.items}`, `{customer.name}`, `{order.total}`.

Drittens: FPDF rendert das PDF. Die ViewHelpers übersetzen die Fluid-Logik in FPDF-Methodenaufrufe (SetFont, Cell, Image, Ln). FPDF erzeugt das PDF als Binärdatei, die entweder direkt zum Browser gesendet (Download) oder im Dateisystem gespeichert wird (z.B. für E-Mail-Versand).

Die Schriftarten-Unterstützung ist ein wichtiges Detail: FPDF unterstützt standardmäßig nur 14 Schriften (Helvetica, Times, Courier und Varianten). Für Corporate Fonts müssen TTF-Dateien als FPDF-Fontdateien konvertiert werden. Das Tool `MakeFont` von FPDF übernimmt die Konvertierung.

Die Tabellen-Darstellung erfordert manuelle Positionierung. FPDF hat kein HTML-Tabellen-Modell. Jede Zelle wird absolut positioniert (X/Y-Koordinaten) oder relativ zur vorherigen Zelle. Für komplexe Tabellen mit variablen Zeilenhöhen muss der Entwickler die Höhenberechnung selbst implementieren.

## Häufige Probleme und Lösungen

**UTF-8-Zeichen werden nicht korrekt dargestellt.** FPDF arbeitet intern mit Latin-1-Encoding. Umlaute (ä, ö, ü), polnische Zeichen (ą, ę, ł) oder kyrillische Buchstaben erfordern UTF-8-Support. Lösung: tFPDF (eine UTF-8-fähige FPDF-Variante) statt FPDF verwenden. fluid_fpdf unterstützt tFPDF als Backend. Alternativ: mPDF nutzen, das UTF-8 nativ unterstützt.

**Seitenumbrüche bei dynamischen Inhalten.** Eine Rechnung mit 5 Posten passt auf eine Seite, eine mit 50 Posten braucht 3 Seiten. FPDF bricht Seiten nicht automatisch um, wenn Inhalt über den Seitenrand hinausgeht. Lösung: Die verbleibende Seitenhöhe vor jedem Posten prüfen (GetY() + Zeilenhöhe > Seitenende) und bei Bedarf eine neue Seite einfügen. Kopf- und Fußzeilen werden über Header()/Footer()-Methoden automatisch auf jeder Seite wiederholt.

**Layout-Entwicklung ist aufwändig.** Ohne visuelle Preview muss der Entwickler nach jeder Änderung das PDF generieren, um das Ergebnis zu sehen. Lösung: Eine Preview-Route einrichten, die das PDF im Browser anzeigt (Output-Modus "Inline" statt "Download"). Bei jedem Refresh wird das PDF neu generiert. Das beschleunigt den Entwicklungszyklus erheblich.

## Migration und Versions-Kompatibilität

fluid_fpdf unterstützt TYPO3 v10 und v11. Für v12 existiert keine offizielle Version, der Portierungsaufwand ist moderat (Extbase-Anpassungen, ViewHelper-Registrierung).

Die Alternativen für TYPO3 v12/v13: EXT:pdfviewhelpers (nutzt TCPDF statt FPDF, mehr Features, aktive Pflege, v12-kompatibel), eine Custom-Lösung mit mPDF als Composer-Paket (HTML/CSS als Input, einfacheres Layout als mit FPDF) oder eine Headless-Lösung mit einem externen PDF-Dienst (Gotenberg, wkhtmltopdf als Docker-Container).

Die Migration von fluid_fpdf auf EXT:pdfviewhelpers ist überschaubar: Die Template-Struktur ist ähnlich (ViewHelper-basiert), aber die ViewHelper-Namen und Parameter unterscheiden sich. Bei einem Projekt mit 5 PDF-Templates liegt der Migrationsaufwand bei 2-4 Tagen. Gosign hat PDF-Generierung in TYPO3 mit allen gängigen Libraries umgesetzt und berät zur passenden Lösung basierend auf den konkreten Anforderungen.

--- focuspoint TYPO3 - Intelligentes Bild-Cropping | Gosign ---
> focuspoint für TYPO3: Automatisches Bild-Cropping mit intelligentem Fokuspunkt. Responsive-Optimierung, KI-beschleunigt.

## focuspoint verhindert, dass Bilder beim responsiven Zuschneiden wichtige Motivbereiche verlieren - die Extension setzt einen Fokuspunkt, an dem das Crop bei jedem Seitenverhältnis ausgerichtet bleibt

Wer Bilder auf einer responsiven Website verwendet, kennt das Problem: Ein Hochformat-Portrait, das im Teaser nur 200 Pixel hoch dargestellt wird, zeigt plötzlich nur den Hals oder die Stirn. Ein Landschaftsfoto, das im Hero-Bereich als schmaler Streifen erscheint, zeigt den Himmel statt der Berge. Pauschales Zentrieren führt dazu, dass Hauptmotive abgeschnitten werden, weil das mathematische Zentrum selten mit dem tatsächlichen Motiv-Zentrum übereinstimmt. focuspoint löst das, indem Redakteure im Backend einen Punkt auf dem Bild setzen, der bei jedem Crop in Sichtbereich bleiben muss. Die Ausgabe passt sich an alle Seitenverhältnisse an, ohne dass für jedes Format eine eigene Bildvariante erzeugt werden muss.

Der Unterschied zu einer klassischen Bildbearbeitungs-Pipeline mit festen Crops ist groß. Statt für Desktop, Tablet und Mobile je eine separat zugeschnittene Version zu pflegen, gibt es ein Originalbild mit einem Fokuspunkt und beliebig viele Ausgabeformate, die das System automatisch errechnet. Für Redaktionen mit vielen Bildern reduziert das die Pflegezeit dramatisch - und für das Marketing öffnet es die Möglichkeit, neue Bild-Seitenverhältnisse ohne Nacharbeit einzuführen.

## Typische Einsatzszenarien

Der erste klassische Fall sind Personen- und Teamseiten. Eine Unternehmens-Website zeigt Mitarbeiter-Portraits in verschiedenen Layouts - als rundes Avatar im Header, als quadratische Kachel in der Teamliste, als breites Format auf der Detailseite. Ohne Fokuspunkt muss der Fotograf exakt zentriert fotografieren oder die Redaktion legt für jedes Layout eine eigene Variante an. Mit focuspoint setzt die Redaktion einmal einen Punkt auf das Gesicht und das Bild funktioniert in allen Kontexten.

Der zweite Fall sind Produkt- und Raumfotos. Immobilienmakler, Hoteliers und Möbelhändler arbeiten mit Fotos, bei denen das eigentliche Motiv - ein Sofa, ein Zimmerblick, ein Produktdetail - nicht im Bildmittelpunkt liegt. focuspoint erlaubt, genau dieses Motiv auszuwählen und sorgt dafür, dass es auch auf Mobilgeräten nicht verloren geht.

Dritter Einsatz: Magazin- und Artikel-Teaser. Redaktionelle Artikelbilder haben oft einen klaren Blickfang, etwa einen Sprecher auf einer Bühne oder ein Produkt in einer Szene. Bei Teaser-Listen mit Hochkant-Thumbnails wäre dieser Blickfang ohne Fokuspunkt häufig außerhalb des Bildausschnitts.

## Technische Architektur

focuspoint ergänzt das TYPO3-FAL-System um zwei zusätzliche Metadatenfelder: focus_point_x und focus_point_y. Beide werden im Backend über ein Formularelement gepflegt, das das Originalbild als Auswahlfläche anzeigt. Der Redakteur klickt auf den relevanten Punkt, die relative Position wird gespeichert. Technisch sind das zwei Fließkommawerte zwischen null und eins, die den Anteil der Bildbreite beziehungsweise -höhe beschreiben.

Beim Rendern im Frontend wird der Fokuspunkt vom Fluid-ViewHelper ausgewertet. Statt des üblichen "f:image"-ViewHelpers nutzt die Extension einen eigenen ViewHelper, der die Crop-Berechnung unter Berücksichtigung des Fokuspunkts durchführt und das Bild über die TYPO3-GIFBUILDER-Pipeline in der gewünschten Zielgröße erzeugt. Das Ergebnis wird gecached und erneut nur bei Änderungen neu erzeugt.

Die Extension spielt mit allen gängigen Bildformaten zusammen - JPEG, PNG, WebP, AVIF - und nutzt für die eigentliche Bildverarbeitung ImageMagick oder GraphicsMagick, also denselben Stack, auf den TYPO3 ohnehin aufbaut. Für Lazy Loading und srcset-Integration gibt es keine Konflikte: Der ViewHelper kann in Picture-Elementen mit mehreren Sources verschachtelt werden und liefert für jeden Breakpoint den passenden Ausschnitt.

## Häufige Probleme und Lösungen

Das erste Problem ist die Reihenfolge der ViewHelper. Wer focuspoint in bestehende Templates einbaut, die bereits mit "f:image" und manuellen Crop-Argumenten arbeiten, muss den focuspoint-ViewHelper an die Stelle des Standards setzen, nicht darum herum. Sonst werden beide Logiken gegeneinander laufen und das Ergebnis ignoriert den Fokuspunkt. Die Lösung ist eine saubere Migration aller Bildreferenzen im Sitepackage auf den neuen ViewHelper.

Zweites Problem: Cache-Invalidierung. Wenn Redakteure den Fokuspunkt ändern, muss der Bildcache verworfen werden, sonst sehen sie immer noch den alten Ausschnitt. TYPO3 leert den Bildcache normalerweise bei Änderungen am Originalbild, nicht bei Metadaten-Änderungen. Die Lösung ist ein EventListener, der bei Änderungen an den Fokuspunkt-Feldern gezielt die betroffenen Processed-Files löscht.

Drittes Problem: Inkonsistente Ergebnisse zwischen Backend-Vorschau und Frontend. Die Vorschau im Backend nutzt einen anderen Renderpfad als das Frontend, was zu kleinen Abweichungen führen kann. Pragmatische Lösung: Im Backend nur eine ungefähre Vorschau zeigen und Redakteure auf das Frontend als verbindliche Referenz verweisen.

## Migration und Versions-Kompatibilität

TYPO3 bringt seit Version 9 einen nativen Crop-Editor im Backend mit, der einzelne Varianten pro Bild erlaubt. Für einfache Anwendungsfälle reicht das aus. focuspoint unterscheidet sich dadurch, dass der Fokuspunkt einmal gesetzt wird und automatisch in alle Crop-Varianten einfließt, statt jede Variante einzeln zu bearbeiten. Wer viele Bilder hat und wenig Redaktionszeit, fährt mit focuspoint langfristig besser.

Die Extension ist mit TYPO3 v11, v12 und v13 kompatibel. Beim Upgrade von älteren Versionen sollte die FAL-Metadatenstruktur und die verwendeten ViewHelper auf die aktuelle Syntax gebracht werden.

Eine neue Klasse von Alternativen sind KI-gestützte Saliency-Erkennungen, die den Fokuspunkt automatisch aus dem Bildinhalt ableiten. Diese Ansätze reduzieren die redaktionelle Arbeit zusätzlich, weil Redakteure den Punkt nicht mehr selbst setzen müssen, sondern nur in Ausnahmefällen korrigieren. Für TYPO3 gibt es erste Integrationen dieser Technik, sie sind aber noch nicht Standard und sollten projektbezogen bewertet werden.

Gosign konfiguriert focuspoint und integriert es in Fluid-Template-Architekturen. KI-gestützte Analyse der Design-Layouts schlägt optimale Crop-Presets für alle Breakpoints vor, sodass Redakteure bei der Bildpflege nicht jedes Format einzeln durchprobieren müssen.

--- Linked Checkbox TYPO3 - Form Element | Gosign ---
> Custom Checkbox-Element für das TYPO3 Form Framework mit verlinktem Label. Unverzichtbar für rechtskonformes Formular-Design: DSGVO-Einwilligungen,.

## form_element_linked_checkbox macht DSGVO-Einwilligungen wirklich klickbar

Das TYPO3-Core-Form-Framework kennt eine Checkbox, aber keine Checkbox mit verlinktem Label. Wer mit dem Standard-Element arbeitet, kann im Label keinen Link zur Datenschutzerklärung oder zu den AGB setzen - und genau das ist in der Praxis eine Anforderung, die bei jedem Formular auftaucht. Die Extension form_element_linked_checkbox schliesst diese Lücke mit einem sauberen Custom-Form-Element, das Text und Link sauber kombiniert. Für jede TYPO3-Installation, die mit dem nativen Form-Framework arbeitet, ist diese Erweiterung praktisch Pflicht. Ohne die Extension bleibt nur der Workaround, den Label-Text mit einem nebenstehenden Textblock zu erweitern, was nicht nur unsauber wirkt, sondern auch für Screenreader und Barrierefreiheit problematisch ist.

## Typische Einsatzszenarien liegen im Compliance-Umfeld jeder Unternehmensseite

Das erste und häufigste Szenario sind DSGVO-Einwilligungen unterhalb von Kontakt-, Newsletter- und Bewerbungsformularen. Der Text "Ich habe die Datenschutzerklärung gelesen und stimme der Verarbeitung meiner Daten zu" muss einen klickbaren Link auf /datenschutz enthalten, ohne dass der Besucher das Häkchen zum Öffnen setzen muss. form_element_linked_checkbox bildet diesen Fall exakt ab.

Ein zweites Szenario sind AGB-Bestätigungen bei Registrierungs- und Kaufformularen. Hochschulen nutzen das bei Kursanmeldungen, Vereine bei Mitgliedsanträgen, E-Commerce-Projekte mit dem TYPO3-Form-Framework bei Checkouts. Hier ist oft nicht nur ein Link gefragt, sondern mehrere (AGB, Widerrufsbelehrung, Datenschutz), die im selben Label untergebracht werden müssen.

Das dritte Szenario betrifft Double-Opt-In-Newsletter. Vor der Anmeldung muss der Empfänger explizit bestätigen, dass er den Newsletter abonniert, mit Link auf die Newsletter-spezifischen Datenschutzhinweise. form_element_linked_checkbox erlaubt es, mehrere Checkboxen mit je eigenem Link im selben Formular zu verwenden, sodass neben der Datenschutz-Einwilligung auch die explizite Newsletter-Zustimmung als separates Element abgefragt werden kann. Das ist wichtig, weil die DSGVO separate Einwilligungen verlangt und eine pauschale "Ich stimme allem zu"-Checkbox rechtlich nicht ausreicht.

## Technische Architektur steckt im Form-Framework-Pluginsystem

Das TYPO3-Form-Framework ist bewusst erweiterbar ausgelegt: Jede Extension kann eigene Form-Elemente registrieren, die im YAML-Editor auftauchen und im Backend per Drag-and-Drop verwendbar sind. form_element_linked_checkbox nutzt diesen Mechanismus und registriert ein neues Element "LinkedCheckbox" über die Form-Setup-YAML und den Form-Element-Definitions-Bereich. Redakteure ziehen das Element in ihr Formular, genau wie sie das mit einer Standard-Checkbox tun würden, und konfigurieren Label, Link-Text und Ziel im Detail-Panel.

Intern erweitert die Extension die Checkbox-Klasse und fügt Properties für linkTarget, linkText und wrapLabel hinzu. Das Rendering läuft über ein eigenes Fluid-Partial, das den Label-Text in "before", "linkText" und "after" zerlegt und einen klickbaren Bereich nur über den Link-Teil spannt. Der Klick auf den Link öffnet die Zielseite, ohne die Checkbox zu togglen. Für die Barrierefreiheit ist das wichtig, weil Screenreader den Link als separates Element vorlesen und die Checkbox unabhängig davon bedient werden kann.

Konfiguration erfolgt direkt im YAML-Editor des Form-Framework: Nach dem Ziehen des Elements in ein Formular erscheinen die Felder "Label vor Link", "Link-Text", "Label nach Link" und "Link-Ziel" in der rechten Detail-Spalte. Das Ziel kann eine interne Seite, ein Dateilink oder eine externe URL sein. Die Pflicht-Validierung wird wie beim Standard-Element über den Validators-Tab gesetzt.

## Häufige Probleme betreffen Mehrsprachigkeit, Styling und Validator-Meldungen

Das erste Supportthema ist die Übersetzung. Das Label besteht aus drei Teilen, und jeder Teil muss in jeder Sprache separat gepflegt werden. In der Praxis heisst das: Für eine zweisprachige Installation (DE/EN) verdoppelt sich die Pflege. Wer mit ext:l10nmgr arbeitet, sollte die LLL-Schlüssel explizit in der Form-Definition referenzieren, damit der Import/Export sauber funktioniert. Ein Trick aus grösseren Projekten: Die drei Label-Teile in einem einzigen LLL-Key mit Platzhaltern hinterlegen und bei der Ausgabe serverseitig zusammensetzen. Das reduziert die Zahl der zu übersetzenden Strings deutlich.

Das zweite Thema ist das Styling. Viele Design-Systeme arbeiten mit benutzerdefinierten Checkboxen, die per CSS aus einem span- oder label-Konstrukt nachgebildet werden. Das Default-Template der Extension liefert einen einfachen Wrapper, der mit einigen CSS-Frameworks kollidiert. Wir empfehlen, das Partial im Paket-Overlay zu überschreiben und den Aufbau an das restliche Formular-Styling anzupassen.

Drittens sind Validator-Fehlermeldungen ein häufiger Stolperstein. Wenn der Nutzer die Checkbox nicht anklickt, soll "Bitte stimmen Sie der Datenschutzerklärung zu" erscheinen, nicht die Default-Meldung "Pflichtfeld". Die Extension unterstützt benutzerdefinierte Error-Messages per formElementsDefinition in der Form-YAML; die Meldung kann pro Element angepasst werden. Für Barrierefreiheit ist das wichtig, weil Screenreader die Error-Message direkt vorlesen und unspezifische Meldungen keine Hilfestellung geben. Wir empfehlen, jede Error-Message so zu formulieren, dass sie unabhängig vom Kontext verständlich ist.

## TYPO3 v12 und v13 werden voll unterstützt, v10-Migration braucht YAML-Anpassung

form_element_linked_checkbox ist für TYPO3 v11, v12 und v13 verfügbar. Die YAML-Struktur des Form-Framework hat sich zwischen v10 und v12 in Details geändert, vor allem bei der Registrierung von Custom-Elementen. Beim Upgrade einer v10-Installation müssen Form-Definitionen, die das Element verwenden, auf die neue YAML-Syntax umgestellt werden.

In Gosign-Projekten migrieren wir die Extension als Teil des Form-Framework-Refactorings, nicht einzeln. Der Aufwand ist meist minimal, weil das Element in jedem Formular nur über seinen Typ-Bezeichner referenziert wird. Wir prüfen bei der Migration ausserdem, ob die DSGVO-Einwilligungstexte nach dem TYPO3-Upgrade in jeder Sprache korrekt gerendert werden, und aktualisieren die Datenschutzlinks, falls sie in URL-Struktur oder Text-Content verändert wurden.

--- Formlog TYPO3 - Formular-Logging | Gosign ---
> Formular-Logging-Extension für TYPO3: Alle Formular-Eingaben im Backend protokollieren. Backup für fehlgeschlagene E-Mails, Analyse des.

## Warum jede dritte Kontaktanfrage in TYPO3 ohne Logging verloren geht

Kontaktformulare sind der wichtigste Lead-Kanal auf Unternehmenswebsites. Aber TYPO3s Form Framework speichert Eingaben standardmässig nicht in der Datenbank - es versendet nur E-Mails. Wenn der Mailserver ausfällt, das SPF-Record falsch konfiguriert ist oder der SMTP-Timeout zuschlägt, ist die Anfrage verloren. Kein Backup, keine Nachverfolgung, keine Analyse. Formlog schliesst diese Lücke, indem es jede Formulareingabe in der TYPO3-Datenbank protokolliert - unabhängig davon, ob die E-Mail-Zustellung erfolgreich war.

In der Praxis betrifft das mehr Unternehmen als vermutet: E-Mail-Zustellraten von Webservern liegen laut Studien zwischen 85% und 95%. Bei 100 Kontaktanfragen pro Monat bedeutet das 5 bis 15 verlorene Leads. Bei einem durchschnittlichen Lead-Wert von 500 EUR im B2B-Bereich summiert sich das auf 2.500 bis 7.500 EUR entgangenen Umsatz pro Monat.

## Typische Einsatzszenarien

**Absicherung gegen E-Mail-Ausfälle.** Ein mittelständisches Unternehmen betreibt 3 Kontaktformulare auf seiner TYPO3-Website. Der SMTP-Server des Hosters hat am Wochenende für 6 Stunden einen Timeout. Ohne Formlog sind alle Anfragen in diesem Zeitraum verloren. Mit Formlog findet das Marketing-Team am Montag alle Eingaben im TYPO3-Backend vor und kann manuell nachfassen.

**Compliance-Nachweis für DSGVO und ISO 27001.** Unternehmen müssen nachweisen können, wann welche personenbezogenen Daten eingegangen sind und wann sie gelöscht wurden. Formlog speichert Eingaben mit Zeitstempel und bietet eine konfigurierbare automatische Löschung nach X Tagen. Für ISO-27001-Audits liefert das eine lückenlose Dokumentation der Datenverarbeitung.

**Analyse des Eingabeverhaltens.** Welche Felder werden häufig leer gelassen? Bei welchem Formular-Step brechen Nutzer ab? Formlog macht diese Daten im Backend sichtbar. Ein TYPO3-Integrator kann daraus Optimierungen ableiten, ohne ein externes Analytics-Tool für Formulare einzusetzen.

## Technische Architektur

Formlog integriert sich als Finisher in das TYPO3 Form Framework (EXT:form). Jedes Formular, das einen Formlog-Finisher konfiguriert hat, schreibt seine Eingaben nach dem Submit in eine eigene Datenbanktabelle (`tx_formlog_entries`).

Die Architektur im Detail:

- **Finisher-Integration**: Formlog registriert einen eigenen Finisher-Typ, der in der YAML-Konfiguration des Form Frameworks hinzugefügt wird. Der Finisher läuft nach der Validierung und vor dem E-Mail-Finisher.
- **Datenbank-Schema**: Jede Eingabe wird als JSON-serialisiertes Array gespeichert, zusammen mit Metadaten (Zeitstempel, Formular-Identifier, Sprache, Seite).
- **Backend-Modul**: Formlog stellt ein eigenes Backend-Modul bereit, in dem Redakteure und Administratoren die protokollierten Eingaben filtern, durchsuchen und als CSV exportieren können.
- **DSGVO-Löschung**: Über eine Scheduler-Task werden Einträge nach einer konfigurierbaren Anzahl von Tagen automatisch gelöscht. Standard: 90 Tage.

Abhängigkeiten: Formlog setzt das TYPO3 Form Framework (EXT:form) voraus, das seit TYPO3 v8 zum Core gehört. Ältere Formular-Extensions wie Powermail oder Formhandler werden nicht unterstützt - dort ist das Logging jeweils nativ integriert. Die Datenbanktabelle benötigt je nach Formularvolumen nur wenig Speicherplatz: 1.000 Einträge mit durchschnittlich 10 Feldern belegen etwa 5 MB. Die automatische Löschung verhindert unkontrolliertes Tabellenwachstum.

## Häufige Probleme und Lösungen

**Problem: Formlog protokolliert nicht alle Formularfelder.** Ursache: Der Formlog-Finisher muss nach dem Validierungs-Step konfiguriert sein, aber vor dem Redirect-Finisher. Wenn der Redirect zuerst greift, wird der Formlog-Finisher nicht mehr ausgeführt. Die Lösung: In der YAML-Konfiguration die Finisher-Reihenfolge prüfen - Formlog sollte an Position 1 stehen, vor E-Mail und Redirect.

**Problem: Backend-Modul zeigt keine Einträge.** Häufig ein Rechteproblem: Der Backend-User oder die Backend-Gruppe hat keinen Zugriff auf das Formlog-Modul. Die Lösung: In den Backend-Gruppen-Einstellungen das Modul `formlog` unter "Erlaubte Module" aktivieren. Zusätzlich muss der User Lesezugriff auf den Sys-Folder haben, in dem die Einträge gespeichert werden.

**Problem: Automatische Löschung funktioniert nicht.** Der TYPO3 Scheduler muss korrekt eingerichtet sein und regelmässig laufen (Cronjob alle 5 bis 15 Minuten). Ohne funktionierenden Scheduler wird die Lösch-Task nie ausgelöst. Auf Shared-Hosting-Umgebungen ist der Cronjob häufig nicht oder falsch konfiguriert. Prüfung im TYPO3-Backend unter System > Scheduler: Die Formlog-Cleanup-Task muss als aktiv gelistet sein und das "Letzte Ausführung"-Datum darf nicht älter als 24 Stunden sein.

## Migration und Versions-Kompatibilität

Formlog wurde von Pagemachine (jetzt Teil von Undkonsorten) entwickelt und ist als Composer-Paket (`pagemachine/typo3-formlog`) verfügbar. Die Extension unterstützt TYPO3 v10 bis v12 LTS. Für TYPO3 v13 gibt es zum aktuellen Zeitpunkt noch keinen offiziellen Release, aber die Codebase basiert auf stabilen TYPO3-APIs (Form Framework Finisher, Extbase Repository Pattern), sodass die Kompatibilität mit überschaubarem Aufwand herstellbar ist.

Bei einem TYPO3-Upgrade von v10 auf v12 muss die Formlog-Konfiguration in den YAML-Formulardefinitionen geprüft werden. Das Form Framework hat in v11 die Finisher-Konfiguration leicht verändert (strikte Typisierung der Optionen). Ein Datenbank-Update über den Install Tool Upgrade Wizard ist in der Regel nicht nötig, da das Schema stabil geblieben ist.

Wer von Powermail auf das TYPO3 Form Framework migriert, verliert dabei das in Powermail integrierte Logging. Formlog ist der empfohlene Ersatz. Gosign migriert Formulare inklusive Logging-Konfiguration und stellt sicher, dass bestehende Daten nicht verloren gehen.

Ein Aspekt, den viele Projektteams übersehen: Formlog ist nicht nur ein Backup-Tool, sondern auch ein Audit-Werkzeug. Wenn ein Kunde behauptet, er habe vor 3 Wochen eine Anfrage gesendet, die nie beantwortet wurde, liefert Formlog den Beweis - entweder die Anfrage existiert mit Zeitstempel, oder sie wurde nie abgesendet. Für Unternehmen mit Service-Level-Agreements und Beschwerdemanagement ist das ein messbarer Vorteil, der die Installation in 10 Minuten rechtfertigt.

--- gb_events TYPO3 - Events | Gosign ---
> Event-Extension für TYPO3: Einfache Event-Darstellung und Kalender-Ansicht. Leichter als sf_event_mgt, für Events ohne Registrierungsfunktion.

## Nicht jede Veranstaltung braucht eine Registrierung, aber jede braucht eine ordentliche Darstellung

sf_event_mgt ist der Standard für Event-Management in TYPO3: Registrierung, Warteliste, Bezahlung, Teilnehmerverwaltung. Aber viele Organisationen zeigen Veranstaltungen nur an, ohne Online-Registrierung. Ein Konzertkalender, ein Veranstaltungsprogramm einer Gemeinde, die Termine einer Volkshochschule, bei all diesen Szenarien wäre sf_event_mgt Overkill. gb_events füllt diese Lücke: einfache Event-Darstellung mit Kalenderansicht, ohne den Overhead eines vollständigen Event-Management-Systems.

Die Extension ist für Organisationen gemacht, die Termine veröffentlichen, aber nicht verwalten wollen. Kein Registrierungsformular, keine Teilnehmerliste, keine Zahlungsabwicklung. Dafür eine saubere Listendarstellung, eine Kalenderansicht und eine Detailseite pro Event.

## Typische Einsatzszenarien

**Gemeinde- und Kirchengemeinde-Websites.** Gottesdienste, Konzerte, Gemeindefeste, Seniorennachmittage, ein typischer Gemeinde-Kalender hat 20-40 Events pro Monat. Besucher wollen sehen, was wann stattfindet, und vielleicht die Termine in ihren persönlichen Kalender übernehmen. Eine Registrierung ist nicht nötig, die Veranstaltungen sind öffentlich. gb_events bildet das mit minimalem Konfigurationsaufwand ab.

**Volkshochschulen und Bildungseinrichtungen (Programmübersicht).** Die Kursanmeldung läuft über ein externes System (Kufer, WebOpac, Stufen), aber das Programm soll auf der TYPO3-Website durchsuchbar sein. gb_events zeigt die Kurse als Event-Liste, gefiltert nach Kategorie (Sprachen, Kreativität, IT, Gesundheit) und Zeitraum. Die Detailseite verlinkt auf das externe Anmeldesystem.

**Veranstaltungsreihen mit wiederkehrenden Terminen.** Ein Sportverein hat Training montags und mittwochs, ein Stammtisch jeden ersten Donnerstag. gb_events stellt wiederkehrende Termine dar, ohne dass jeder Einzeltermin manuell angelegt werden muss. Die Wiederholung wird konfiguriert, gb_events generiert die Termine automatisch.

## Technische Architektur

gb_events basiert auf Extbase/Fluid und nutzt eine eigene Datenbanktabelle `tx_gbevents_domain_model_event`. Jedes Event hat die Felder: Titel, Beschreibung, Startdatum, Enddatum, Ort, Bild, Kategorie und optional eine Wiederholungsregel. Die Kategorien nutzen TYPO3s System-Kategorien, was die Integration mit anderen Extensions vereinfacht.

Das Frontend besteht aus drei Views: Listenansicht (chronologisch, filterbar nach Kategorie und Zeitraum), Kalenderansicht (Monatsdarstellung mit klickbaren Tagen) und Detailansicht (vollständige Event-Informationen). Alle Views sind Fluid-Templates und lassen sich im Sitepackage überschreiben.

Die Kalenderansicht rendert ein HTML-Table-Grid mit 7 Spalten (Wochentage) und 4-6 Zeilen (Wochen). Jede Zelle enthält die Events des jeweiligen Tages als verlinkte Titel. Die Navigation zwischen Monaten erfolgt per Link-Parameter (GET), nicht per AJAX. Das ist SEO-freundlich, weil jeder Monat eine eigene URL hat und von Google indexiert werden kann.

Die Wiederholungslogik arbeitet ähnlich wie bei calendarize: Ein Datensatz mit Wiederholungsregel erzeugt virtuelle Events. Diese werden zur Laufzeit berechnet und nicht in der Datenbank materialisiert. Das spart Speicher, erfordert aber Rechenzeit bei jedem Seitenaufruf. TYPO3s Caching-Framework neutralisiert diesen Nachteil für cached Seiten.

## Häufige Probleme und Lösungen

**Events erscheinen nicht in der Listenansicht.** Häufige Ursache: Der Speicherordner (Storage PID) im Plugin stimmt nicht mit dem Ordner überein, in dem die Events angelegt wurden. gb_events filtert Events nach Storage PID. Lösung: Im Plugin-FlexForm den korrekten Speicherordner auswählen oder die Einschränkung per TypoScript aufheben (`persistence.storagePid = 0` zeigt Events aus allen Ordnern).

**Vergangene Events verschwinden sofort.** gb_events blendet Events standardmäßig aus, sobald das Enddatum überschritten ist. Für manche Anwendungsfälle (Veranstaltungsarchiv, Referenzen) sollen vergangene Events sichtbar bleiben. Lösung: Die Repository-Query im Controller anpassen (vergangene Events einschließen) oder einen separaten Listenansicht-Modus "Archiv" konfigurieren.

**Keine iCal-Export-Funktion.** Besucher wollen Events in ihren Kalender übernehmen. gb_events bietet standardmäßig keinen .ics-Download. Lösung: Einen eigenen Page-Type für den iCal-Export anlegen. Das Fluid-Template erzeugt iCalendar-konformen Output (VCALENDAR, VEVENT, DTSTART, DTEND, SUMMARY, LOCATION). Der Aufwand liegt bei circa 3 Stunden Entwicklungszeit.

## Migration und Versions-Kompatibilität

gb_events unterstützt TYPO3 v10 und v11. Für v12 existiert eine Community-Version auf GitHub, die Kompatibilität ist aber nicht vollständig verifiziert. Für v13 gibt es aktuell keine Planung.

Die Alternative für TYPO3 v12/v13 ist sf_event_mgt, die deutlich umfangreichere und besser gepflegte Event-Extension. sf_event_mgt unterstützt v12 und v13 offiziell. Wer keine Registrierungsfunktion braucht, kann sf_event_mgt ohne Registrierung konfigurieren und trotzdem die Event-Darstellung und Kalenderansicht nutzen. Der Funktionsumfang ist größer, die Komplexität aber auch.

Die Migration von gb_events auf sf_event_mgt erfordert eine Datenmigration: Die Events aus `tx_gbevents_domain_model_event` in `tx_sfeventmgt_domain_model_event` überführen. Die Felder sind ähnlich (Titel, Beschreibung, Datum, Ort), aber nicht identisch. Ein SQL-basiertes Migrations-Script erledigt das in 1-2 Stunden. Die Fluid-Templates müssen angepasst werden, da sf_event_mgt andere ViewHelpers und Variablen nutzt.

Für Projekte mit wenigen Events (unter 50 pro Jahr) ist auch eine Custom-Lösung auf Basis von tx_news denkbar: Events als News-Datensätze mit Datumsfeldern und einer Kalender-Darstellung im Template. Gosign berät zur wirtschaftlichsten Lösung und übernimmt bei Bedarf die Migration.

--- Geocoding TYPO3 - Koordinaten | Gosign ---
> Geocoding-Extension für TYPO3: Adressen automatisch in GPS-Koordinaten umwandeln. Basis für Filialfinder, Umkreissuche und Kartenanzeige.

## Warum jeder TYPO3-Filialfinder ohne Geocoding an der Datenqualität scheitert

Filialfinder, Händlersuche und Umkreissuche haben alle dasselbe Fundament: GPS-Koordinaten. Aber Unternehmen speichern Standortdaten als Adressen - Strasse, Hausnummer, PLZ, Stadt. Die Umrechnung von Adresse zu Koordinate (Geocoding) passiert nicht von allein. geocoordinates löst dieses Problem automatisiert: Die Extension überwacht Adressfelder in TYPO3-Records und berechnet bei jeder Änderung die zugehörigen GPS-Koordinaten über einen Geocoding-Service.

Ohne Geocoding-Extension müssten Redakteure für jeden Standort manuell Breiten- und Längengrad aus Google Maps herauskopieren. Bei 50 Standorten ist das eine Stunde Arbeit. Bei 500 Standorten ein ganzer Arbeitstag - und bei jeder Adressänderung beginnt der Prozess von vorn.

## Typische Einsatzszenarien

**Automatisches Geocoding für tt_address-Datensätze.** Ein Unternehmen mit 120 Standorten in Deutschland, Österreich und der Schweiz pflegt alle Adressen in der TYPO3-Extension tt_address. geocoordinates registriert einen DataHandler-Hook auf die tt_address-Tabelle. Sobald ein Redakteur eine Adresse ändert oder einen neuen Standort anlegt, wird im Hintergrund der Geocoding-Service aufgerufen. Die Koordinaten werden in die Datenbankfelder `latitude` und `longitude` geschrieben. Die Karten-Extension maps2 liest diese Felder und platziert den Marker an der richtigen Stelle.

**Batch-Geocoding bei Datenmigrationen.** Ein Unternehmen migriert 2.000 Adressen aus einem alten System nach TYPO3. Die importierten Datensätze haben Strasse und PLZ, aber keine Koordinaten. geocoordinates bietet einen CLI-Command, der alle Datensätze ohne Koordinaten in einem Batch-Lauf geocodiert. Bei der Google Geocoding API liegt das kostenlose Kontingent bei 40.000 Requests pro Monat - für eine einmalige Migration mehr als ausreichend.

**Umkreissuche auf Basis von Postleitzahlen.** Ein Handwerksbetrieb bietet Umkreissuche an: "Finde den nächsten Partner in deiner Nähe." Der Besucher gibt seine PLZ ein, geocoordinates wandelt die PLZ in Koordinaten um, und eine SQL-Distanz-Berechnung (Haversine-Formel) liefert alle Standorte im Radius von 25, 50 oder 100 km, sortiert nach Entfernung.

## Technische Architektur

geocoordinates integriert sich als DataHandler-Hook in den TYPO3 Core. Die Extension überwacht konfigurierbare Tabellen und Felder. Wenn sich ein überwachtes Adressfeld ändert, wird asynchron ein Geocoding-Request ausgelöst.

Die Extension unterstützt zwei Geocoding-Provider:

- **Google Geocoding API**: Hohe Genauigkeit, weltweit verfügbar, erfordert API-Key mit aktiviertem Billing. Kosten: 5 USD pro 1.000 Requests, kostenlos bis 40.000/Monat (mit 200 USD Guthaben). Vorteil: Verarbeitet auch unvollständige oder fehlerhafte Adressen intelligent.
- **OpenStreetMap Nominatim**: Kostenlos, keine Registrierung nötig. Einschränkungen: Maximale Abfragerate von 1 Request/Sekunde, Nutzungsbedingungen erfordern einen benutzerdefinierten User-Agent. Genauigkeit in ländlichen Gebieten teilweise geringer als Google.

Die Koordinaten werden in konfigurierbaren Datenbankfeldern gespeichert. Standard: `latitude` und `longitude` als `DOUBLE`-Felder. Die Extension kann über TCA-Konfiguration auf jede beliebige Tabelle angewendet werden, nicht nur auf tt_address.

Für die Umkreissuche stellt geocoordinates eine Haversine-Distanz-Funktion bereit, die in Extbase Repositories oder direkte QueryBuilder-Queries eingebunden werden kann. Die Berechnung erfolgt auf Datenbankebene (MySQL/MariaDB), nicht in PHP. Das ist performancekritisch: Eine PHP-basierte Distanzberechnung über 10.000 Standorte dauert Sekunden, eine SQL-basierte Berechnung mit Index Millisekunden. Für einen Index auf den Koordinatenfeldern empfiehlt sich ein Spatial Index, sofern die Datenbank MySQL 5.7+ oder MariaDB 10.2+ verwendet.

## Häufige Probleme und Lösungen

**Problem: Geocoding liefert falsche Koordinaten für deutsche Adressen.** Deutsche Adressen mit Umlauten (Nürnberger Strasse, Lübeck) können Probleme verursachen, wenn die API die Zeichenkodierung nicht korrekt verarbeitet. Die Lösung: Sicherstellen, dass die Adressdaten in UTF-8 an die API gesendet werden. geocoordinates kodiert standardmässig in UTF-8, aber Legacy-Datenbankfelder mit Latin1-Encoding können hier stören. Eine Datenbank-Konvertierung auf UTF-8mb4 löst das dauerhaft.

**Problem: Google Geocoding API gibt "OVER_QUERY_LIMIT" zurück.** Bei Batch-Geocoding mit mehr als 50 Requests pro Sekunde drosselt Google die API. Die Lösung: Rate-Limiting im Batch-Command aktivieren (max. 40 Requests/Sekunde für Standard-Accounts). Für grosse Batches den Import über Nacht laufen lassen oder auf einen Premium-Plan upgraden.

**Problem: Nominatim liefert bei gleicher Adresse unterschiedliche Ergebnisse.** OpenStreetMap-Daten werden von der Community gepflegt und können sich ändern. Eine Adresse, die gestern korrekt geocodiert wurde, kann morgen leicht abweichende Koordinaten liefern, wenn jemand die OSM-Daten bearbeitet hat. Die Lösung: Einmal geocodierte Koordinaten als "verifiziert" markieren und nur bei manueller Änderung der Adresse neu geocodieren. geocoordinates unterstützt dieses Pattern über ein zusätzliches Datenbankfeld.

## Migration und Versions-Kompatibilität

geocoordinates ist als Composer-Paket für TYPO3 v10 bis v12 verfügbar. Die Extension wird von Stefan Froemken gepflegt, der auch maps2 entwickelt. Die beiden Extensions sind aufeinander abgestimmt, können aber unabhängig voneinander eingesetzt werden.

Für TYPO3 v13 ist die Kompatibilität in der Regel zeitnah nach dem LTS-Release gegeben. Die Extension nutzt stabile TYPO3-APIs (DataHandler Hooks, Extbase Repositories), die sich zwischen Versionen wenig ändern.

Wer von einem manuellen Geocoding-Workflow (Google Maps aufrufen, Koordinaten kopieren, in TYPO3 eintragen) auf geocoordinates umsteigt, kann die bestehenden Koordinaten beibehalten. Die Extension schreibt nur in leere Koordinatenfelder oder bei Adressänderungen. Bereits vorhandene Koordinaten werden nicht überschrieben, es sei denn, der Administrator löst einen manuellen Re-Geocoding-Lauf aus.

Gosign kombiniert geocoordinates standardmässig mit maps2, um einen vollständigen Filialfinder-Stack zu liefern: Adresseingabe durch den Redakteur, automatisches Geocoding im Hintergrund, Kartenanzeige mit Marker und Popup im Frontend, Umkreissuche mit PLZ-Eingabe für den Besucher. Der Stack ist in 2 bis 3 Tagen aufgesetzt und deckt die Anforderungen von 90% aller Filialfinder-Projekte ab.

--- Gewinnspiel TYPO3 - Online-Verlosung | Gosign ---
> Gewinnspiel in TYPO3: Verlosungen, Teilnahme, Auslosung. DSGVO-konform, KI-beschleunigte Entwicklung.

## Online-Gewinnspiele in TYPO3 scheitern selten an der Technik, fast immer am Recht

Ein Gewinnspiel zu programmieren dauert 3-5 Tage: Formular, Validierung, Auslosung, E-Mail an Gewinner. Es rechtssicher zu machen dauert länger, weil die juristischen Anforderungen den technischen Aufwand übersteigen. Teilnahmebedingungen, separate Marketing-Einwilligung, Koppelungsverbot, automatische Datenlöschung nach Gewinnspielende, Altersprüfung, Ausschluss von Mitarbeitern, das sind keine optionalen Extras, sondern gesetzliche Pflichten. Ein TYPO3-Gewinnspiel ohne diese Absicherung riskiert Abmahnungen und Bußgelder.

TYPO3 bietet keine Standard-Extension für Gewinnspiele. Die Lösung ist immer eine Custom-Entwicklung, die genau die Anforderungen des konkreten Gewinnspiels abbildet. Gosign entwickelt solche Module als Extbase-basierte TYPO3-Extensions mit vollständigem DSGVO-Compliance-Layer.

## Typische Einsatzszenarien

**Marketing-Kampagnen mit Produktverlosung.** Ein Konsumgüter-Hersteller verlost 10 Produkte unter allen Teilnehmern, die ein Formular ausfüllen. Das Gewinnspiel läuft 4 Wochen, danach werden die Gewinner per Zufallsgenerator ermittelt und per E-Mail benachrichtigt. Die technischen Anforderungen: Formular mit Pflichtfeldern (Name, E-Mail, Alter), Einmal-Teilnahme pro E-Mail-Adresse (Double-Opt-In), Checkbox für Teilnahmebedingungen (nicht vorausgewählt), separate Checkbox für Newsletter-Einwilligung (optional, nicht gekoppelt an Teilnahme), automatische Datenlöschung 30 Tage nach Ende.

**Social-Media-verknüpfte Gewinnspiele.** Teilnehmer werden von Instagram oder Facebook auf die TYPO3-Website geleitet, füllen dort das Formular aus. Die Social-Media-Plattform darf nicht als Teilnahmemechanismus dienen (Plattform-AGBs verbieten das), sondern nur als Traffic-Quelle. Die TYPO3-Seite ist die offizielle Teilnahmeseite. Bei einem Kunden mit 50.000 Instagram-Followern generierten drei Gewinnspiele in einem Jahr 12.000 qualifizierte Kontakte, davon 4.800 mit Newsletter-Opt-In.

**Wiederkehrende Advents- oder Monats-Gewinnspiele.** Ein Adventskalender-Gewinnspiel mit 24 Türchen, jedes mit einem eigenen Preis. Technisch anspruchsvoller: 24 Gewinnspiele in einer Extension, zeitgesteuerte Freischaltung, separate Auslosung pro Tag, Gesamtteilnahme-Tracking (kein doppelter Gewinn). Bei einem Handelsunternehmen steigerte der Adventskalender den Dezember-Traffic um 300% gegenüber dem Vorjahresmonat.

## Technische Architektur

Ein TYPO3-Gewinnspielmodul besteht aus fünf Komponenten:

**Teilnahmeformular.** Extbase-Controller mit Fluid-Template. Die Formularfelder sind konfigurierbar: Pflichtfelder (Name, E-Mail), optionale Felder (Telefon, Adresse), Checkboxen (Teilnahmebedingungen, Marketing-Einwilligung). Das Formular nutzt TYPO3s CSRF-Protection (FormToken) und validiert serverseitig. Clientseitige Validierung ist ergänzend, aber nicht allein ausreichend.

**Duplikat-Prüfung.** Jede E-Mail-Adresse darf nur einmal teilnehmen. Die Prüfung erfolgt auf Datenbankebene (unique constraint auf E-Mail + Gewinnspiel-ID). Zusätzlich: Double-Opt-In per Bestätigungs-E-Mail. Erst nach Klick auf den Bestätigungslink gilt die Teilnahme.

**Auslosung.** Ein Scheduler-Task oder manueller Backend-Trigger wählt die Gewinner per kryptographischem Zufallsgenerator (`random_int()` in PHP, nicht `rand()` oder `mt_rand()`). Die Auslosung wird in der Datenbank protokolliert: Zeitpunkt, Seed, Gewinner-IDs. Bei regulatorischen Anfragen lässt sich die Auslosung nachvollziehen.

**Gewinner-Benachrichtigung.** Automatische E-Mail an die Gewinner mit Gratulation und nächsten Schritten (z.B. Adresseingabe für den Versand). Automatische E-Mail an die Nicht-Gewinner (optional, empfohlen für die Kundenbindung). Alle E-Mails über TYPO3s Mail-API mit Fluid-Templates.

**Daten-Lifecycle.** Automatische Löschung aller Teilnehmerdaten nach einem konfigurierbaren Zeitraum (Standard: 30 Tage nach Gewinnspielende). Ein Scheduler-Task prüft täglich, ob Gewinnspiele abgelaufen sind, und löscht die zugehörigen Datensätze. Gewinner-Daten (Name, Adresse) werden separat behandelt, weil sie für den Versand und steuerliche Dokumentation länger aufbewahrt werden müssen.

## Häufige Probleme und Lösungen

**Bot-Teilnahmen verfälschen die Ergebnisse.** Ohne Schutz registrieren Bots tausende Fake-Teilnahmen. Lösung: Honeypot-Feld, Rate-Limiting (maximal 3 Submissions pro IP pro Minute) und Double-Opt-In als dreifache Absicherung. Das Double-Opt-In ist der effektivste Schutz: Bots können Formulare ausfüllen, aber keine Bestätigungs-E-Mails anklicken.

**Koppelungsverbot verletzt.** Die Teilnahme am Gewinnspiel darf nicht an eine Marketing-Einwilligung geknüpft sein. Wenn die Newsletter-Checkbox Pflichtfeld ist, liegt ein Verstoß vor. Lösung: Marketing-Einwilligung immer als optionale, nicht vorausgewählte Checkbox implementieren. Im Formular-Validator prüfen, dass die Teilnahme auch ohne Marketing-Checkbox funktioniert.

**Performance bei hoher gleichzeitiger Last.** Ein virales Gewinnspiel mit 10.000 Teilnahmen in einer Stunde belastet den Server. Lösung: Das Formular-Submit als uncached Seite (USER_INT) konfigurieren, aber die Gewinnspielseite selbst cachen (USER). Für extreme Last: einen separaten Worker-Prozess für die Datenbank-Writes einsetzen und das Formular über eine Queue abarbeiten.

## Migration und Versions-Kompatibilität

Gewinnspiel-Module sind Custom-Entwicklungen und haben keinen Standard-Migrations-Pfad. Bei TYPO3-Upgrades müssen die Extbase-APIs angepasst werden: v9-v10 (Middleware-Stack), v10-v11 (Extbase-Änderungen), v11-v12 (TCA-Refactoring, Backend-Module). Der Aufwand pro Major-Upgrade liegt bei 1-2 Tagen für ein typisches Gewinnspielmodul.

Für wiederkehrende Gewinnspiele lohnt sich eine generische Extension, die über ein Backend-Modul konfiguriert wird: Gewinnspiel-Name, Zeitraum, Preise, Formularfelder, E-Mail-Templates. Diese einmalige Investition (5-8 Entwicklertage) spart bei jedem weiteren Gewinnspiel 80% des Aufwands. Gosign entwickelt solche Module als wiederverwendbare TYPO3-Extensions und übernimmt bei Bedarf den Entwurf der Teilnahmebedingungen, die juristische Freigabe liegt beim Kunden.

--- Hero-Slider TYPO3 - Performance | Gosign ---
> Hero-Slider Extension für TYPO3. Oft Performance-Killer: Große Bilder, schwere JS-Libraries. Gosign migriert auf CSS-only oder Swiper-basierte.

## Der Hero-Slider ist der teuerste Bereich einer TYPO3-Website, gemessen in Ladezeit

Der Hero-Bereich ist das erste, was Besucher sehen. Bei einem Slider ist es auch das langsamste, was sie sehen. Ein typischer Hero-Slider in TYPO3 lädt 3-5 großformatige Bilder (je 500 KB-2 MB), eine JavaScript-Library (jQuery + Slider-Plugin: 120-200 KB), CSS-Animationen und Initialisierungs-Scripts. Zusammen sind das 3-12 MB Daten, bevor der Besucher irgendwo klicken kann. Der Largest Contentful Paint (LCP) liegt bei solchen Setups routinemäßig über 4 Sekunden, was Google als "schlecht" einstuft und Rankings kostet.

Die Lösung ist nicht ein besserer Slider, sondern entweder kein Slider oder ein radikal leichtgewichtiger. CSS-only-Lösungen und moderne Slider-Libraries wie Swiper erreichen den gleichen visuellen Effekt bei einem Bruchteil der Ladezeit.

## Typische Einsatzszenarien

**Startseiten mit wechselnden Kampagnen.** Marketing will 3-5 Botschaften prominent platzieren: saisonale Kampagne, neues Produkt, Event-Ankündigung, Award-Nachricht. Der Slider rotiert automatisch, jede Slide hat Bild, Headline und CTA-Button. Das Problem: Studien zeigen konsistent, dass nur 1-2% der Besucher über die erste Slide hinaus interagieren. Die restlichen 4 Slides werden geladen, aber nicht gesehen. Ein statisches Hero-Bild mit einer klaren Botschaft performt in A/B-Tests regelmäßig besser als ein Slider.

**Bildergalerien im Header-Bereich.** Hotels, Restaurants und Eventtlocations zeigen Impressionen als Hero-Slider: Außenansicht, Innenraum, Terrasse, Speisen. Hier macht ein Slider inhaltlich Sinn, weil Besucher mehrere Eindrücke erwarten. Die Performance-Optimierung: Nur das erste Bild sofort laden, die restlichen per Lazy Loading nachladen. Mit Intersection Observer und `loading="lazy"` ist das ohne Slider-Library möglich.

**Produkt-Highlights mit Animation.** E-Commerce-Websites zeigen Produkt-Highlights als animierte Slides. Die Animation soll Aufmerksamkeit erzeugen. In der Praxis: CSS-Transitions (`transform`, `opacity`) sind performanter als JavaScript-Animationen und belasten die GPU statt der CPU. Ein CSS-only-Slider mit `scroll-snap-type` und `transition` erreicht 60 fps auf jedem Gerät.

## Technische Architektur

Hero-Slider in TYPO3 werden typischerweise als Content Element implementiert: ein FlexForm mit Slide-Konfiguration (Bild, Text, Link, Reihenfolge) und ein Fluid-Template, das die Slides rendert. Die Slider-Logik übernimmt eine JavaScript-Library.

Die verbreiteten Libraries in TYPO3-Projekten: FlexSlider (veraltet, jQuery), Slick (veraltet, jQuery), Owl Carousel (veraltet, jQuery), Swiper (modern, kein jQuery, 139 KB) und Splide (modern, kein jQuery, 29 KB). Die Wahl der Library bestimmt die Performance-Charakteristik des gesamten Hero-Bereichs.

Die optimale Architektur für einen Hero-Slider in 2026:

**Option 1: CSS-only (0 KB JavaScript).** `scroll-snap-type: x mandatory` auf dem Container, `scroll-snap-align: start` auf den Slides. Navigation per `scroll-behavior: smooth` und Anchor-Links. Autoplay per CSS-Animation (`@keyframes`). Kein JavaScript nötig. Funktioniert in allen modernen Browsern. Nachteile: Kein programmatisches Autoplay mit Pause-on-Hover, keine Swipe-Animationen.

**Option 2: Swiper/Splide (29-139 KB JavaScript).** Volle Slider-Funktionalität mit Touch, Swipe, Autoplay, Pagination, Lazy Loading. Tree-Shakeable, nur die genutzten Module werden geladen. Integration in TYPO3 über ein Custom Content Element mit FlexForm.

**Option 3: Statisches Hero (0 KB JavaScript, 1 Bild).** Ein Bild, eine Headline, ein CTA. Das schnellste und conversion-stärkste Setup. Das Bild wird als `<picture>` mit `srcset` ausgeliefert: 375px für Mobile, 768px für Tablet, 1440px für Desktop. Mit AVIF/WebP-Format unter 100 KB pro Variante.

## Häufige Probleme und Lösungen

**LCP über 4 Sekunden.** Das Hero-Bild ist das LCP-Element. Wenn es zu spät lädt, ist der LCP-Score schlecht. Lösung: Das erste Slide-Bild mit `fetchpriority="high"` und `loading="eager"` laden (nicht lazy). Die restlichen Slides mit `loading="lazy"`. Bildformat auf WebP/AVIF umstellen. Bildgröße auf die tatsächliche Darstellungsgröße begrenzen (kein 4000px-Bild für einen 1440px-Viewport).

**Cumulative Layout Shift (CLS) durch nachladende Slider.** Der Slider-Container hat zunächst keine Höhe, nach dem JavaScript-Init springt das Layout. Lösung: Die Höhe des Slider-Containers per CSS fixieren (z.B. `aspect-ratio: 16/9` oder `min-height: 60vh`). Damit reserviert der Browser den Platz, bevor das JavaScript geladen ist.

**Autoplay auf Mobilgeräten funktioniert nicht.** iOS Safari blockiert Autoplay-Videos und manche CSS-Animationen aus Energiespar-Gründen. Lösung: Autoplay auf Mobilgeräten deaktivieren und stattdessen Swipe-Navigation anbieten. Besucher auf Smartphones wissen, dass sie wischen können. Ein statischer Hinweis ("Wischen für mehr") ist unnötig.

## Migration und Versions-Kompatibilität

Die meisten Hero-Slider-Extensions im TER sind veraltet und unterstützen maximal TYPO3 v10 oder v11. Für v12/v13 empfiehlt sich ausnahmslos ein Custom Content Element im Sitepackage, das eine moderne Library einbindet oder komplett auf CSS setzt.

Die Migration bestehender Slider erfolgt in drei Schritten: Slide-Daten exportieren (Bilder, Texte, Links aus der FlexForm oder Datenbank), neues Content Element aufsetzen (FlexForm mit denselben Feldern, aber modernem Template) und die bestehenden Content-Elemente per SQL auf den neuen CType umstellen. Der Aufwand: 1-2 Tage für das technische Setup, plus 0,5 Tage pro 10 existierenden Slidern für die Datenmigration.

Gosign empfiehlt bei jedem Hero-Slider-Projekt zuerst die Frage: Braucht die Website wirklich einen Slider? In 70% der Fälle performt ein statisches Hero-Element besser. Für die restlichen 30% liefert Gosign eine Swiper- oder CSS-only-Lösung, die unter 1,5 Sekunden LCP bleibt.

--- Highcharts TYPO3 - Datenvisualisierung | Gosign ---
> Interaktive Highcharts-Diagramme in TYPO3 einbetten. Charts, Grafiken und Datenvisualisierungen direkt im CMS verwalten. Gosign implementiert auch.

## Highcharts bringt interaktive Datenvisualisierung ins TYPO3-Backend, wenn Redakteure Diagramme pflegen sollen, ohne in Excel oder externen Tools arbeiten zu müssen

Zahlen, Kennzahlen und Trends gehören auf Unternehmens-Websites - als Geschäftszahlen im Investor-Relations-Bereich, als Markt-Daten im Content-Marketing, als Evaluationsergebnisse bei Verbänden und Behörden. Die klassische Lösung sind statische Grafiken, die irgendwo in Excel erstellt, als PNG exportiert und manuell hochgeladen werden. Das ist mühsam und fehleranfällig: Wenn sich eine Zahl ändert, muss die ganze Grafik neu gemacht werden. Highcharts löst das Problem, indem Diagramme direkt aus strukturierten Daten erzeugt werden - und zwar interaktiv im Browser, mit Tooltips, Hover-Effekten und Zoom-Funktionen. Die TYPO3-Integration macht den Redaktionsprozess komplett backend-gestützt: Redakteure pflegen Datenreihen in einer Eingabemaske, die Extension generiert das Diagramm.

Der eigentliche Produktivitäts-Hebel entsteht, wenn Datenreihen nicht manuell gepflegt, sondern aus externen Quellen gezogen werden. Eine CSV aus dem Controlling, ein Export aus einem Data Warehouse oder ein API-Call an ein internes Dashboard liefert die Zahlen, TYPO3 rendert daraus die öffentliche Grafik. Diese Trennung zwischen Datenquelle und Darstellung macht das Pflegen von Kennzahlen zum Commit-Vorgang, nicht zum Screenshot-Austausch.

## Typische Einsatzszenarien

Der klassische Fall sind Investor-Relations- und Geschäftszahlen-Seiten. Ein börsennotiertes Unternehmen zeigt Umsatzentwicklung, Mitarbeiterzahlen und Marktanteile als interaktive Diagramme. Bei Quartalsmeldungen aktualisiert das IR-Team einfach die Datenreihe, das Diagramm erneuert sich automatisch, und Besucher können mit Mouse-Over die genauen Werte pro Jahr ablesen.

Der zweite Fall sind Evaluations- und Studien-Ergebnisse bei Verbänden, Stiftungen und Behörden. Eine Mitgliederbefragung, eine Umweltstudie oder eine Konjunkturerhebung wird als Balken-, Linien- oder Tortendiagramm präsentiert. Highcharts erlaubt es, komplexe Datensätze mit vielen Kategorien übersichtlich darzustellen und bietet Exportfunktionen, mit denen Besucher die Diagramme als Bild oder PDF mitnehmen können.

Dritter Einsatz: Content-Marketing und Data-Journalism. Unternehmensblogs und Fachmagazine nutzen interaktive Grafiken, um komplexe Zusammenhänge zu erklären - Preisentwicklungen, Marktanteile, Nutzungsstatistiken. Die Interaktivität erhöht die Verweildauer und macht die Inhalte zitierfähig für andere Medien.

## Technische Architektur

Highcharts als JavaScript-Bibliothek ist ein etabliertes Produkt der norwegischen Firma Highsoft, das unter kommerzieller Lizenz vertrieben wird, aber für nicht-kommerzielle Zwecke kostenfrei nutzbar ist. Die TYPO3-Integration fügt dem CMS Backend-Masken zur Pflege von Datenreihen hinzu und rendert im Frontend den passenden JavaScript-Code, der Highcharts initialisiert.

Typischerweise besteht die Extension aus einem Content-Element, in dem Redakteure Diagrammtyp (Linie, Balken, Torte, Area), Achsen-Beschriftung, Farben und Datenreihen konfigurieren. Jede Datenreihe lässt sich entweder manuell als Tabelle pflegen oder aus externen Quellen wie CSV-Dateien, Datenbank-Abfragen oder REST-APIs beziehen. Im Frontend gibt die Extension einen div-Container mit Konfigurations-JSON aus, ein Script-Block initialisiert Highcharts und rendert das Diagramm clientseitig.

Die Lizenzfrage ist zentral. Für kommerzielle TYPO3-Projekte muss eine Highcharts-Lizenz erworben werden - je nach Umfang zwischen einigen hundert und mehreren tausend Euro pro Jahr. Wer das vermeiden will, findet mit Chart.js, ApexCharts oder Plotly gute Alternativen, die MIT- oder Apache-lizenziert sind. Die Entscheidung hängt an Features: Highcharts bietet die umfangreichste Palette an Diagrammtypen und die beste Dokumentation, die Alternativen decken Standardfälle aber zuverlässig ab.

## Häufige Probleme und Lösungen

Das erste Problem ist Lizenzierung im Unklaren. Projekte werden gestartet mit der Annahme, Highcharts sei kostenfrei, und bei der kommerziellen Nutzung kommt die Rechnung. Die Lösung liegt in einer frühen Lizenz-Prüfung: Wenn das Projekt kommerziell ist, wird entweder die Highcharts-Lizenz budgetiert oder von vornherein auf eine freie Alternative gesetzt. Gosign klärt diese Frage im Kickoff.

Zweites Problem: Performance bei vielen Datenreihen. Ein Diagramm mit tausenden Datenpunkten blockiert den Browser beim Rendern. Die Lösung ist entweder Datenreduktion über serverseitige Aggregation oder der Einsatz von Highcharts-Modulen wie Boost, die große Datenmengen auf WebGL rendern. Für Standardfälle reicht es, die Rohdaten auf sinnvolle Granularität zu komprimieren, bevor sie in den Browser gelangen.

Drittes Problem: Barrierefreiheit. Interaktive Diagramme sind für Screenreader oft unzugänglich. Highcharts bietet ein Accessibility-Modul, das die Daten als strukturierte Tabelle parallel zum visuellen Diagramm bereitstellt. Die pragmatische Ergänzung ist, unter jedem Diagramm eine reguläre HTML-Tabelle mit denselben Daten anzuzeigen, die per CSS visuell verborgen, aber für Screenreader verfügbar bleibt.

## Migration und Versions-Kompatibilität

Die TYPO3-Integrationen für Highcharts existieren in mehreren Varianten unterschiedlicher Qualität und Aktualität. Für TYPO3 v11 gibt es aktiv gepflegte Extensions, für v12 und v13 ist die Auswahl kleiner, oft braucht es Anpassungen am ext_emconf und an Service-Konfigurationen. Wer heute neu startet, sollte nüchtern prüfen, ob eine bestehende Extension noch passt oder ob eine Sitepackage-Integration mit einer freien Library wie Chart.js der zukunftssicherere Weg ist.

Im Upgrade-Szenario ist die Highcharts-Version die kritische Größe. Neue Highcharts-Versionen brechen gelegentlich die API, besonders bei komplexen Diagrammtypen. Eine Migration sollte daher immer in einem Staging-System getestet werden, bevor Live-Dashboards angefasst werden.

Ein pragmatisches Vorgehen für Bestandsprojekte: Aktuelle Diagramme inventarisieren, die tatsächlich genutzten Features der eingesetzten Chart-Bibliothek auflisten und prüfen, ob eine Alternative dasselbe abdeckt. In vielen Fällen sind die Anforderungen überschaubar - Linien- und Balkendiagramme mit wenigen Datenreihen - und eine freie Library bedient sie ohne Qualitätsverlust. Das gesparte Lizenzbudget kann stattdessen in ein besseres Content-Management der Datenreihen fließen.

Gosign integriert Highcharts in TYPO3, begleitet Lizenz-Klärung und Migrations-Projekte, und implementiert bei Bedarf leichtgewichtige Alternativen wie Chart.js oder ApexCharts als Sitepackage-Komponente. Die richtige Wahl hängt davon ab, welche Diagrammtypen tatsächlich gebraucht werden und welches Budget für Lizenzen zur Verfügung steht.

--- Hotspot TYPO3 - Interaktive Bilder | Gosign ---
> TYPO3 Extension für interaktive Bild-Hotspots: Klickbare Bereiche auf Bildern mit Tooltip oder Overlay. Produktbilder, Gebäudepläne, Infografiken.

## Interaktive Bilder erklären komplexe Produkte besser als 1.000 Worte Text

Ein Gebäudeplan mit 12 markierten Räumen, ein Maschinenquerschnitt mit 8 beschrifteten Bauteilen, eine Europakarte mit 15 Standorten: All diese Anwendungsfälle brauchen klickbare Bereiche auf einem Bild. Der Besucher klickt auf ein Bauteil und sieht dessen Spezifikationen. Er klickt auf einen Standort und sieht Adresse und Kontakt. Hotspot-Extensions für TYPO3 machen Bilder interaktiv, indem sie definierte Bereiche mit Tooltips, Overlays oder Links verknüpfen.

Die spannendere Frage ist, ob man dafür überhaupt eine Extension braucht. SVG-basierte Hotspots funktionieren ohne Extension, sind leichter, barrierefreier und vollständig im Sitepackage kontrollierbar. Für einfache Anwendungsfälle ist SVG der bessere Weg. Für komplexe Setups mit vielen Hotspots und Backend-Pflege durch Redakteure rechtfertigt eine Extension den Einsatz.

## Typische Einsatzszenarien

**Produktbilder mit klickbaren Bauteilen.** Hersteller von Maschinen, Geräten und technischen Produkten nutzen Hotspots, um Bauteile auf einem Produktfoto zu beschriften. Ein Industriekompressor mit 8 Baugruppen: Klick auf den Motor zeigt Leistungsdaten, Klick auf den Filter zeigt Wechselintervalle. Statt einer langen Textbeschreibung erschließt sich die Information visuell. Bei einem Maschinenbauer steigerten interaktive Produktbilder die Verweildauer auf Produktseiten um 45%.

**Gebäude- und Campuspläne.** Hochschulen, Kliniken und große Unternehmen zeigen interaktive Lagepläne: Gebäude anklicken, Etage auswählen, Rauminformationen sehen. TYPO3 liefert die Raumdaten aus einer Extbase-Datenquelle, die Hotspots sind auf dem Grundriss positioniert. Bei einem Klinikum mit 14 Gebäuden ersetzten interaktive Pläne den gedruckten Wegweiser komplett.

**Infografiken mit Detailinformationen.** Marketing-Abteilungen produzieren Infografiken zu Prozessen, Wertschöpfungsketten oder Unternehmensstrukturen. Statt eine statische PNG-Datei zu zeigen, werden die Elemente der Infografik klickbar: Klick auf eine Prozessstufe öffnet die Detailbeschreibung. Das funktioniert besonders gut bei komplexen Themen, die nicht linear erklärt werden können.

## Technische Architektur

Hotspot-Extensions in TYPO3 bestehen aus drei Teilen: einem Backend-Editor zur Positionierung der Hotspots, einer Datenstruktur für Hotspot-Inhalte und einem Frontend-Renderer, der die Hotspots auf dem Bild darstellt.

Der Backend-Editor ist typischerweise ein visueller Punkt-Platzierungs-Editor: Der Redakteur sieht das Bild im TYPO3-Backend und klickt auf die Stellen, an denen Hotspots erscheinen sollen. Die Koordinaten werden als Prozentwerte (relativ zur Bildgröße) gespeichert, nicht als Pixel. Prozentwerte stellen sicher, dass die Hotspots bei responsiver Bilddarstellung an der richtigen Stelle bleiben.

Die Datenstruktur pro Hotspot: X-Position (%), Y-Position (%), Tooltip-Text, Detail-Content (HTML/Fluid), Icon-Typ und optional ein Link auf eine Detailseite. Die Daten werden als Inline-Relationen (IRRE) zum Content-Element gespeichert: Ein Content-Element hat 1:n Hotspots.

Im Frontend werden die Hotspots als absolut positionierte HTML-Elemente über dem Bild gerendert. Das Bild liegt in einem Container mit `position: relative`, die Hotspots haben `position: absolute` mit `left` und `top` in Prozent. Beim Klick oder Hover erscheint der Tooltip als Overlay, positioniert relativ zum Hotspot.

Die SVG-Alternative funktioniert ohne Extension: Das Bild wird als SVG angelegt (oder das Bild wird als `<image>` in ein SVG eingebettet), die Hotspots sind SVG-Elemente (`<circle>`, `<rect>`, `<polygon>`) mit `data-`Attributen und Event-Handlern. Die Tooltip-Inhalte werden per JavaScript aus einem `<script type="application/json">` Block gelesen.

## Häufige Probleme und Lösungen

**Hotspot-Positionen verschieben sich auf Mobilgeräten.** Das Bild wird auf dem Smartphone kleiner dargestellt, aber die Hotspots bleiben an der Desktop-Position. Ursache: Die Hotspots sind in Pixel statt in Prozent positioniert, oder der Container hat keine responsive Größenanpassung. Lösung: Alle Positionen in Prozent speichern und den Container mit `max-width: 100%` und `height: auto` responsiv machen. Zusätzlich: Hotspots auf Mobilgeräten als Liste unterhalb des Bildes anzeigen, weil Fingertipps auf kleine Hotspot-Punkte schwierig sind.

**Barrierefreiheit nicht gegeben.** Rein visuelle Hotspots ohne Tastatur-Navigation und ohne Screenreader-Text sind nicht barrierefrei. Lösung: Jeden Hotspot als `<button>` implementieren (nicht als `<div>`), mit `aria-label` für den Screenreader und `tabindex` für die Tastatur-Navigation. Der Tooltip-Inhalt muss als `aria-describedby` verknüpft sein.

**Performance bei vielen Hotspots.** 20+ Hotspots auf einem Bild erzeugen 20+ DOM-Elemente mit Event-Listenern. Auf älteren Mobilgeräten kann das zu Ruckeln führen. Lösung: Event Delegation statt individueller Listener. Ein einziger Listener auf dem Container statt 20 auf den Hotspots. Bei SVG-basierten Hotspots ist die Performance generell besser, weil SVG-Elemente nativ vom Browser gerendert werden.

## Migration und Versions-Kompatibilität

Hotspot-Extensions im TER unterstützen TYPO3 v10 und v11. Für v12 und v13 existieren keine breit gepflegten Hotspot-Extensions. Der Trend geht zu SVG-basierten Lösungen, die als Custom Content Element im Sitepackage implementiert werden und keine Drittanbieter-Extension erfordern.

Die Migration von einer Hotspot-Extension auf eine SVG-basierte Lösung erfordert: die Hotspot-Daten (Koordinaten, Texte) exportieren, ein SVG-Template erstellen, das die Punkte als SVG-Elemente rendert, und ein Custom Content Element aufsetzen, das die Daten per IRRE-Relation verwaltet. Der Aufwand liegt bei 3-5 Tagen, abhängig von der Anzahl der Hotspot-Bilder.

Die zukunftssicherste Lösung: CSS-basierte Hotspots mit `<map>` und `<area>` für einfache Szenarien, SVG mit JavaScript für komplexe Interaktionen. Gosign implementiert interaktive Bilder als Custom Content Elements und berät zur passenden Technologie basierend auf Komplexität, Barrierefreiheits-Anforderungen und Anzahl der Hotspot-Bilder.

--- Vereinsliste TYPO3 - Kommunal | Gosign ---
> Vereinslisten-Plugin für TYPO3: Vereine darstellen, filtern, sortieren. Typisch für Kommunal-Websites und Dachverbände. Kategorie-Filter,.

## Kommunen und Dachverbände brauchen eine strukturierte Vereinsdatenbank statt statischer Listen

Wer auf einer Gemeinde-Website oder dem Portal eines Landessportbundes nach dem lokalen Schachclub sucht, erwartet eine Filtermaske und keine 15-seitige PDF-Liste. Genau dieses Problem löst hwvereinsliste: Die Extension bildet Vereine als TYPO3-Records ab und macht sie über Kategorie-Filter, Volltextsuche und Detailansichten zugänglich. Für kommunale Webauftritte, Dachverbände und Kreissportbünde ist das Plugin seit Jahren ein bewährtes Werkzeug, das Redaktionen die Pflege ohne Entwickler-Eingriffe erlaubt.

Die Realität in deutschen Kommunen sieht allerdings so aus, dass Vereinsregister oft noch als Word-Dokumente in Amtsleitungen kursieren. hwvereinsliste ersetzt diesen Workflow durch eine zentrale Datenbank im TYPO3-Backend, die über Frontend-Plugins ausgesteuert wird. Bürger finden ihren Verein in Sekunden, Redakteure aktualisieren Kontaktdaten ohne FTP-Zugang.

## Typische Einsatzszenarien reichen von Gemeindeportalen bis zu Sportkreis-Datenbanken

Das häufigste Szenario ist die klassische Vereinsliste auf einer kommunalen Website. Eine Gemeinde mit 80 bis 120 eingetragenen Vereinen pflegt alle Einträge zentral im TYPO3-Backend. Bürger filtern im Frontend nach Kategorien wie Sport, Kultur, Soziales oder Jugend. Die Detailansicht zeigt Ansprechpartner, Trainingszeiten und Kontaktdaten. Die Redaktion der Gemeinde-Website aktualisiert Einträge selbstständig, ohne technische Hilfe.

Das zweite Szenario betrifft Dachverbände und Kreissportbünde. Ein Landessportbund verwaltet oft 500 bis 2.000 Mitgliedsvereine in dutzenden Sportarten. Hier wird die Filterfunktion zum Kernfeature: Nutzer kombinieren Sportart, Ort und Altersgruppe, um den passenden Verein in der Nachbarschaft zu finden. hwvereinsliste unterstützt diese Mehrfach-Filterung nativ.

Ein drittes Szenario sind Verzeichnisportale im Ehrenamts-Bereich. Freiwilligenagenturen nutzen die Extension, um Organisationen zu listen, die ehrenamtliche Unterstützung suchen. Die Kategorisierung läuft über TYPO3-Sys-Categories, was Überschneidungen mit anderen Content-Elementen auf der gleichen Seite erlaubt. In manchen Fällen wird die Extension auch als Branchenverzeichnis für lokale Wirtschaftsförderung eingesetzt, wobei Unternehmen statt Vereine gelistet werden.

## Technische Architektur basiert auf Extbase-Records und Fluid-Templates

hwvereinsliste nutzt das Extbase/Fluid-Framework von TYPO3. Vereine werden als eigene Domain-Records in einer dedizierten Tabelle gespeichert. Jeder Record enthält Felder für Name, Beschreibung, Adresse, Kontaktdaten, Website-URL, Logo und Kategorien. Die Kategorisierung verwendet TYPO3-Sys-Categories, was die Integration mit anderen Extensions vereinfacht.

Im Frontend stehen zwei Plugins zur Verfügung: eine Listenansicht mit Filter- und Suchfunktion sowie eine Detailansicht für einzelne Vereine. Die Templates sind Fluid-basiert und lassen sich über TypoScript-Pfade oder ein Site-Package überschreiben. Wer das Layout anpassen will, kopiert die Fluid-Templates ins eigene Package und passt HTML-Struktur und CSS-Klassen an, ohne die Extension selbst zu verändern.

Die Filterung arbeitet standardmässig clientseitig bei kleinen Datenmengen und serverseitig bei grösseren Beständen. Für Installationen mit mehr als 500 Vereinen empfiehlt sich die Kombination mit einer Suchindex-Lösung wie ke_search, um die Performance der Volltextsuche zu verbessern.

Ein Aspekt, der bei kommunalen Projekten oft vergessen wird: die Barrierefreiheit. Seit dem Barrierefreiheitsstärkungsgesetz (BFSG) müssen öffentliche Stellen ihre Webauftritte barrierefrei gestalten. Das betrifft auch die Vereinsliste: Filter-Elemente müssen per Tastatur bedienbar sein, Ergebnislisten brauchen ARIA-Labels, und die Suchfunktion muss Screenreader-kompatibel arbeiten. Die Standard-Templates der Extension erfüllen diese Anforderungen nicht vollständig und müssen angepasst werden.

## Häufige Probleme betreffen Import, Kategorisierung und responsive Darstellung

Das häufigste Problem bei der Ersteinrichtung ist der Datenimport. Kommunen haben ihre Vereinsdaten typischerweise in Excel-Listen mit inkonsistenten Formaten. Spaltennamen variieren, Kategorien sind als Freitext statt als standardisierte Taxonomie gepflegt, und Kontaktdaten enthalten veraltete Einträge. Gosign löst das über einen KI-gestützten Import-Workflow: Die Excel-Datei wird automatisch analysiert, Spalten werden gemappt, Kategorien normalisiert und Duplikate erkannt. Was früher einen halben Tag manuelle Nacharbeit kostete, läuft so in unter einer Stunde.

Das zweite Problem betrifft die Kategoriestruktur. Wenn Kategorien im Vorfeld nicht sauber definiert werden, entstehen Redundanzen wie "Fussball", "Fußball-Verein" und "Fussballclub" als drei separate Einträge. Wir empfehlen, vor dem Go-Live eine Kategorie-Taxonomie mit maximal 15 bis 20 Oberkategorien festzulegen und diese im TYPO3-Backend als Sys-Categories anzulegen.

Drittes Problem: Die responsive Darstellung der Listenansicht. Auf Mobilgeräten wird die Tabellen-Darstellung schnell unübersichtlich. Die Fluid-Templates sollten für mobile Viewports eine Karten-Darstellung statt einer Tabelle rendern, was über eine einfache Template-Anpassung im Site-Package realisierbar ist. Gosign liefert responsive Templates für Vereinslisten standardmässig mit, die auf Smartphones als Card-Grid und auf Desktops als Tabelle dargestellt werden.

## Migration auf v12 erfordert Extbase-Anpassungen, v13 ist noch nicht offiziell unterstützt

hwvereinsliste wurde primär für TYPO3 v9 und v10 entwickelt. Für TYPO3 v12 ist eine Anpassung der Extbase-Persistenz nötig, da sich die Query-Schnittstelle geändert hat. Konkret betrifft das die Repository-Klassen und die TypoScript-basierte Persistenz-Konfiguration, die seit v12 über Classes.php gelöst wird. Die Template-Pfade müssen ebenfalls auf die neue SiteSet-Struktur umgestellt werden.

Für TYPO3 v13 gibt es aktuell keine offizielle Unterstützung durch den Extension-Autor. Wer auf v13 migriert, muss die Extension entweder selbst anpassen oder eine alternative Lösung evaluieren. Gosign prüft in solchen Fällen, ob eine Migration der Extension oder ein Neubau auf Basis von Extbase mit aktueller API wirtschaftlicher ist. Bei kleinen Vereinsdatenbanken mit unter 200 Einträgen ist ein Custom-Plugin oft die bessere Wahl, weil es exakt auf die Anforderungen der Kommune zugeschnitten ist und keine Legacy-Abhängigkeiten mitbringt.

--- imagemap TYPO3 - Interaktive Grafiken | Gosign ---
> imagemap für TYPO3: Interaktive Grafiken mit klickbaren Bereichen. Responsive, barrierefrei, SVG-Alternativen.

## imagemap macht Bilder klickbar, ohne dass Redakteure HTML anfassen müssen - die richtige Wahl für Gebäudepläne, Organigramme und Produktgrafiken mit mehreren Hotspots

Manche Inhalte lassen sich mit Worten nicht so effizient erklären wie mit einem Bild, auf dem verschiedene Bereiche angeklickt werden können. Ein Gebäudeplan, auf dem jede Abteilung zur passenden Team-Seite führt. Ein Organigramm mit Links zu den einzelnen Personenprofilen. Ein Produktbild, bei dem ein Klick auf das Rad, den Motor oder das Cockpit jeweils technische Details zeigt. HTML bringt dafür seit den neunziger Jahren die Image-Map-Funktionalität mit, aber kein Redakteur will Koordinaten per Hand in ein Textfeld eintippen. imagemap rüstet diese Funktion in TYPO3 mit einem visuellen Editor nach: Redakteure klicken im Backend auf das Bild, markieren einen Bereich und verlinken ihn auf eine Zielseite.

Das eigentliche Versprechen der Extension ist, dass räumliche Orientierung und Navigation zusammengeführt werden. Statt Besucher zwischen einer grafischen Ansicht und einer separaten Linkliste springen zu lassen, wird die Grafik selbst zum Navigationselement. Für Content, der geografisch, hierarchisch oder technisch strukturiert ist, bietet das einen deutlich intuitiveren Zugang.

## Typische Einsatzszenarien

Der erste Fall sind Lagepläne und Campus-Übersichten. Kliniken, Hochschulen, Messegelände und Industrieparks arbeiten mit Übersichtskarten, auf denen einzelne Gebäude oder Bereiche direkt zu Informationsseiten verlinken. Die klassische Alternative wäre eine Liste mit Links, die aber den räumlichen Bezug verliert. imagemap kombiniert die grafische Orientierung mit der Linkstruktur.

Der zweite Anwendungsfall sind Organigramme und Hierarchien. Ein Unternehmen zeigt die Struktur seiner Abteilungen als Grafik, jeder Knoten führt zum Profil der jeweiligen Führungskraft oder zur Abteilungsseite. Für die Redaktion ist das einfacher zu pflegen als ein komplexes Tabellen-Layout mit verlinkten Zellen.

Dritter Fall: Produktgrafiken mit Feature-Hotspots. Technische Produkte - Maschinen, Fahrzeuge, Geräte - werden auf einer Explosionszeichnung oder einem Querschnitt gezeigt, auf dem die wichtigsten Komponenten per Klick erklärt werden. Das ersetzt eine lange Textliste und führt Besucher genau dorthin, wo ihr Interesse liegt.

## Technische Architektur

Die klassische imagemap-Extension für TYPO3 pflegt die Koordinaten als strukturierte Datensätze in der Datenbank und rendert im Frontend ein HTML-Map-Element mit den passenden Area-Tags. Im Backend steht ein visueller Editor zur Verfügung, der das Originalbild als Auswahlfläche anzeigt und Redakteuren erlaubt, Rechtecke, Kreise oder Polygone darauf zu zeichnen. Jeder Bereich bekommt eine Ziel-URL, einen Alternativtext und optional ein Tooltip.

Die technische Herausforderung liegt in der Responsivität. Die klassische HTML-Map arbeitet mit absoluten Pixel-Koordinaten, die bei skalierten Bildern nicht mehr passen. imagemap-Extensions lösen das über JavaScript, das die Koordinaten beim Resize relativ umrechnet, oder indem sie SVG als Output-Format nutzen. SVG ist dabei die saubere Lösung: Vektor-Koordinaten skalieren von Haus aus, Ereignisbehandlung und Styling über CSS funktionieren nativ, und Screenreader können die strukturierten Elemente lesen.

Die Integration erfolgt über ein Content-Element im Page-Modul. Redakteure wählen das Ausgangsbild aus FAL, definieren die Hotspots und konfigurieren optional globale Einstellungen wie Standardfarbe der Bereiche, Hover-Effekte und Tooltip-Verhalten. Die Ausgabe lässt sich über ein Fluid-Template im Sitepackage anpassen, um CI-Konformität zu gewährleisten.

## Häufige Probleme und Lösungen

Das erste Problem ist die Barrierefreiheit. HTML-Image-Maps sind für Screenreader nur dann sinnvoll lesbar, wenn jeder Area-Tag einen aussagekräftigen Alternativtext hat und die Map selbst als strukturierte Navigation erkannt wird. Viele Redakteure füllen den Alt-Text gedankenlos oder leer, was die Map für blinde Nutzer unbrauchbar macht. Die Lösung ist eine redaktionelle Pflicht, jeden Hotspot mit einem beschreibenden Alt-Text zu versehen, und eine technische Prüfung im Sitepackage, die leere Texte beim Speichern verhindert.

Zweites Problem: Mobile Bedienbarkeit. Ein Hotspot, der auf Desktop-Größe 30 mal 30 Pixel misst, ist auf einem Smartphone winzig. Die pragmatische Lösung ist eine mobile Alternative, die unterhalb eines bestimmten Breakpoints das Bild durch eine Liste mit denselben Zielen ersetzt. Das erfordert eine Fluid-Logik, die zwei Darstellungen ausspielt und per CSS umschaltet.

Drittes Problem: Pflegeaufwand bei Bild-Änderungen. Wenn das Grundbild - etwa ein Lageplan oder Produktfoto - ausgetauscht wird, müssen alle Koordinaten neu gesetzt werden, weil die Motive sich verschoben haben. Pragmatische Lösung: Redakteure arbeiten mit einem fixen, versionierten Bildformat und dokumentieren die Koordinaten-Raster, damit bei Updates nur minimale Korrekturen nötig sind. Alternativ kann eine SVG-basierte Lösung von vornherein relativ arbeiten.

## Migration und Versions-Kompatibilität

Für TYPO3 v11, v12 und v13 gibt es mehrere imagemap-Extensions, die aktiv gepflegt werden, oft unter leicht abweichenden Namen. Bei Upgrades lohnt sich der Blick, ob die ursprünglich eingesetzte Extension noch weiterentwickelt wird oder ob ein Wechsel auf eine modernere Alternative sinnvoller ist. SVG-basierte Ansätze werden mittelfristig die klassischen HTML-Maps verdrängen, weil sie sowohl responsiv als auch barrierefrei besser funktionieren.

Ein praktischer Hinweis für Migrationen: Wenn ein Bestandsprojekt dutzende Imagemaps enthält, lohnt sich ein Skript, das die bestehenden Koordinaten-Datensätze ausliest und in SVG-Pfade umwandelt. Die Umstellung kann dann in einem einzigen Deployment erfolgen und die Extension abgeschaltet werden. Das reduziert die technische Schuld und macht die Grafiken zukunftsfest.

Wer heute neu startet, sollte den SVG-Ansatz bevorzugen - entweder über eine Extension mit SVG-Output oder über ein eigenes Sitepackage-Pattern, das Redakteuren einen visuellen Editor bietet und im Frontend SVG ausgibt. Gosign implementiert beide Wege und berät bei der Auswahl der passenden Architektur für das jeweilige Projekt.

--- in2publish TYPO3 - Content Staging | Gosign ---
> in2publish: Content von Staging auf Live publizieren. Multi-Server-Setup & Workflows , KI-beschleunigt.

## Warum in2publish den Content-Workflow in Enterprise-TYPO3-Projekten definiert

In professionellen TYPO3-Installationen arbeiten Redakteure nicht direkt auf dem Live-System. Sie pflegen Inhalte auf einer Staging-Umgebung, stimmen Änderungen intern ab und veröffentlichen erst nach Freigabe. Aber wie kommen die Daten von Staging auf Live? Ohne in2publish bedeutet das: Datenbank-Dump auf Staging erstellen, auf Live einspielen, Dateien per FTP synchronisieren. Ein Prozess, der fehleranfällig ist, 30 bis 60 Minuten dauert und bei dem ein falscher Klick die gesamte Live-Datenbank überschreiben kann.

in2publish von in2code eliminiert diesen Prozess. Redakteure klicken im TYPO3-Backend auf "Publish", und die Extension synchronisiert genau die geänderten Datensätze und Dateien auf das Live-System. Keine FTP-Zugänge, keine Datenbank-Dumps, keine Downtime. Der Industriestandard für Content-Staging in TYPO3.

## Typische Einsatzszenarien

**Redaktioneller Freigabe-Workflow.** Ein Konzern betreibt seine Corporate Website auf TYPO3 mit 12 Redakteuren in 3 Abteilungen. Jede Abteilung pflegt ihren Bereich auf Staging. Die Teamleitung prüft die Änderungen und gibt sie frei. Der Redakteur klickt auf "Publish" und nur seine genehmigten Seiten gehen auf Live. Andere Bereiche der Website bleiben unberührt. in2publish zeigt dabei eine Differenzansicht: Welche Felder haben sich geändert, welche Bilder sind neu, welche Datensätze werden überschrieben.

**Multi-Language-Publishing.** Ein Unternehmen pflegt seine Website in 5 Sprachen. Die deutsche Redaktion veröffentlicht fertige Texte, während die englische Übersetzung noch in Arbeit ist. in2publish ermöglicht selektives Publishing pro Sprache: Der deutsche Content geht live, der englische bleibt auf Staging, bis die Übersetzung abgeschlossen ist.

**Kampagnen-Launches mit definierten Terminen.** Das Marketing-Team bereitet eine Produkt-Launch-Seite vor, die am 15. Oktober um 8:00 Uhr live gehen soll. Alle Inhalte - Texte, Bilder, Videos, Landingpages - werden auf Staging vorbereitet und getestet. Am Launch-Tag publiziert der verantwortliche Redakteur alles in einem Schritt. Bei Problemen kann in2publish die Änderungen rückgängig machen. Für zeitkritische Launches ist das ein entscheidender Vorteil gegenüber manuellen Deployment-Prozessen, bei denen ein Rollback 30 Minuten oder mehr dauern kann.

## Technische Architektur

in2publish arbeitet auf Datenbank- und Dateisystem-Ebene. Die Extension vergleicht den Zustand der Staging-Datenbank mit der Live-Datenbank und überträgt Differenzen.

Die Architektur besteht aus vier Kernkomponenten:

- **Record-Comparison**: in2publish vergleicht jeden Datensatz (uid, Tabelle, Felder) zwischen Staging und Live. Geänderte, neue und gelöschte Records werden identifiziert und in einer Baumstruktur dargestellt. Relationen (z.B. Seite hat Content-Elemente, Content-Element hat Bilder) werden aufgelöst, sodass beim Publishing einer Seite automatisch alle abhängigen Datensätze mitgenommen werden.
- **FAL-Synchronisation**: Bilder und Dokumente aus dem File Abstraction Layer werden über SSH/SFTP auf das Live-System übertragen. in2publish vergleicht Dateigrössen und Hashes, um nur geänderte Dateien zu übertragen.
- **Transport-Layer**: Die Kommunikation zwischen Staging und Live erfolgt über SSH. in2publish verbindet sich per Public-Key-Authentifizierung mit dem Live-Server und führt dort CLI-Commands aus. Alternativ unterstützt die Enterprise-Version eine HTTP-basierte Kommunikation über eine API.
- **Konfiguration**: Über eine YAML-Konfiguration wird definiert, welche Tabellen publiziert werden (Whitelist) und welche ausgeschlossen sind (z.B. sys_log, be_sessions, cache-Tabellen). Die Standard-Konfiguration deckt alle Content-relevanten Tabellen ab.

Abhängigkeiten: TYPO3 Core, SSH-Zugang zwischen Staging- und Live-Server, PHP-SSH2-Extension oder ssh2-Binaries auf dem Server. Die Netzwerk-Architektur erfordert, dass der Staging-Server eine ausgehende SSH-Verbindung zum Live-Server aufbauen kann. In Unternehmensnetzwerken mit restriktiven Firewall-Regeln muss dafür ein dedizierter SSH-Port freigeschaltet werden.

## Häufige Probleme und Lösungen

**Problem: Publishing bricht mit "SSH Connection Failed" ab.** Die häufigste Ursache: Der SSH-Key des Staging-Servers ist nicht auf dem Live-Server hinterlegt, oder die SSH-Konfiguration in in2publish zeigt auf den falschen Host/Port. Die Lösung: SSH-Verbindung manuell testen (`ssh -i /path/to/key user@live-server`), dann die Credentials in der in2publish-Konfiguration überprüfen. Bei Managed-Hosting-Umgebungen muss oft der Hoster SSH-Zugang zwischen den Instanzen freischalten.

**Problem: Datensätze auf Live werden nicht aktualisiert.** Die Tabelle ist nicht in der Whitelist der in2publish-Konfiguration enthalten. Das passiert häufig bei Custom-Tabellen aus eigenen Extensions. Die Lösung: Die Tabelle in der Konfiguration hinzufügen und die Relationen definieren (welches Feld verweist auf welche andere Tabelle). Ohne korrekte Relation-Konfiguration kann in2publish die Abhängigkeiten nicht auflösen.

**Problem: FAL-Dateien fehlen nach dem Publishing auf Live.** Der FAL-Storage auf dem Live-System hat einen anderen Pfad als auf Staging, oder die Berechtigungen auf dem Live-Server erlauben kein Schreiben in den Upload-Ordner. Die Lösung: Sicherstellen, dass der FAL-Storage-Basepath auf beiden Systemen identisch ist und der SSH-User Schreibrechte im Fileadmin hat.

## Migration und Versions-Kompatibilität

in2publish wird von in2code aktiv gepflegt und ist für TYPO3 v11 und v12 LTS als Composer-Paket verfügbar. Die Enterprise-Version bietet zusätzliche Features (HTTP-Transport, erweitertes Logging, Multi-Environment-Support) und ist kostenpflichtig lizenziert.

Für TYPO3 v13 arbeitet in2code an einer kompatiblen Version. Die Extension nutzt stabile TYPO3-APIs (DataHandler, FAL), sodass die Portierung in der Regel zeitnah nach dem LTS-Release erfolgt.

Bei einem TYPO3-Upgrade muss die in2publish-Konfiguration überprüft werden: Neue System-Tabellen, geänderte TCA-Definitionen und neue Content-Element-Typen erfordern eine Anpassung der Whitelist. Gosign empfiehlt nach jedem Core-Upgrade einen Test-Publish mit einer einzelnen Seite, um die Konfiguration zu validieren, bevor der volle Redaktionsbetrieb wieder aufgenommen wird. Der Test sollte eine Seite mit allen relevanten Content-Typen umfassen: Textelemente, Bilder, Datei-Downloads und mindestens eine Relation (z.B. News-Datensatz mit Kategorien). Nur so werden alle Synchronisationspfade abgedeckt.

--- in2studyfinder TYPO3 - Studiengänge | Gosign ---
> Studiengangfinder für Hochschul-TYPO3-Websites. Filter nach Fachbereich, Abschluss, Standort, Studienform. Hochschul-spezifische Extension.

## Studieninteressierte erwarten eine Suchmaschine, keine PDF-Broschüre

Hochschulen mit 50 bis 300 Studiengängen stehen vor einem konkreten Problem: Studieninteressierte wollen filtern, nicht scrollen. Sie suchen nach Abschlussart, Fachbereich, Studienform und Standort - gleichzeitig. in2studyfinder von in2code löst genau das innerhalb von TYPO3. Die Extension wurde speziell für den Hochschulbereich entwickelt und bildet die komplexe Struktur aus Bachelor, Master, Diplom, Vollzeit, Teilzeit, dual und berufsbegleitend in einer einzigen Filtermaske ab. Über 20 deutschsprachige Hochschulen setzen die Extension produktiv ein.

Für Hochschul-Webteams, die ihre Studiengangs-Informationen bisher über statische Seiten oder selbstgebaute Lösungen pflegen, ist der Wechsel auf in2studyfinder ein erheblicher Effizienzgewinn. Statt für jeden neuen Studiengang eine eigene Unterseite anzulegen, pflegen Redakteure einen Datensatz im Backend, und die Extension erzeugt Listenansicht, Detailseite und Filterfunktion automatisch. Das spart bei einer Fachhochschule mit 80 Studiengängen geschätzte 40 Stunden Ersteinrichtung gegenüber einer manuellen Seitenstruktur.

## Typische Einsatzszenarien reichen vom Studiengang-Verzeichnis bis zur Akkreditierungs-Übersicht

Das Standardszenario ist der zentrale Studiengangfinder auf der Hochschul-Homepage. Studieninteressierte landen auf einer Seite, wählen Fachbereich, Abschluss und Studienform und erhalten sofort eine gefilterte Liste. Ein Klick führt zur Detailseite mit Modulplan, Zulassungsvoraussetzungen, Bewerbungsfristen und Ansprechpartnern. Bei einer Fachhochschule mit 80 Studiengängen reduziert das die Seitenaufrufe bis zur gewünschten Information von durchschnittlich 6 auf 2.

Zweites Szenario: Standort-übergreifende Suche bei Hochschulen mit mehreren Campi. Eine Universität mit Standorten in drei Städten zeigt alle Studiengänge in einer Ansicht und lässt nach Campus filtern. Die Standort-Information wird als eigene Relation gepflegt, nicht als Freitext, was konsistente Filterung garantiert.

Drittes Szenario: Akkreditierungs-Übersichten für die Qualitätssicherung. Hochschulen müssen nachweisen, welche Studiengänge akkreditiert sind und bis wann. in2studyfinder kann diese Meta-Daten als Custom Fields abbilden und in der Listenansicht darstellen, was die Akkreditierungsabteilung als Arbeitsgrundlage nutzt. Ein Export der Studiengang-Daten als CSV oder PDF ermöglicht zusätzlich die Weitergabe an den Akkreditierungsrat oder andere externe Stellen.

## Technische Architektur setzt auf Extbase-Records mit konfigurierbaren Relationen

in2studyfinder ist eine Extbase/Fluid-Extension von in2code, dem TYPO3-Dienstleister hinter powermail und in2publish. Studiengänge werden als Domain-Records in einer eigenen Tabelle gespeichert. Jeder Record enthält Pflichtfelder wie Titel, Abschlussart, Regelstudienzeit, ECTS-Punkte und Fachbereich sowie optionale Felder für NC-Wert, Studiengebühren, Akkreditierungsstatus und Bewerbungslink.

Die Filterung im Frontend arbeitet über AJAX-Requests, sodass die Seite beim Filtern nicht neu geladen wird. Das verbessert die User Experience erheblich, besonders auf mobilen Geräten. Die Filter-Konfiguration ist über TypoScript steuerbar: Welche Felder als Filter angezeigt werden, welche Sortierung greift und wie viele Ergebnisse pro Seite erscheinen.

Templates sind Fluid-basiert und über Site-Packages überschreibbar. Die Extension liefert Standard-Templates mit, die für die meisten Hochschulen als Startpunkt funktionieren. Für Hochschulen mit eigenem Corporate Design passen wir die Templates an und integrieren sie ins bestehende Site-Package, sodass Studiengang-Seiten visuell nahtlos in den Webauftritt passen.

## Häufige Probleme betreffen Datenqualität, Performance und Mehrsprachigkeit

Das grösste Problem bei der Einführung ist die Datenqualität. Studiengang-Informationen existieren an Hochschulen oft in drei bis fünf verschiedenen Systemen: HIS/HISinOne, eigene Datenbanken der Fachbereiche, PDF-Broschüren und handgepflegte Website-Texte. Bevor in2studyfinder produktiv gehen kann, müssen diese Quellen konsolidiert werden. Gosign unterstützt diesen Prozess mit einem strukturierten Import-Template, das die Fachabteilungen ausfüllen und das wir automatisiert in TYPO3 importieren.

Zweites Problem: Performance bei grossen Datenmengen. Hochschulen mit über 200 Studiengängen und komplexen Relationen (Fachbereich, Standort, Studienform, Sprache) können bei der AJAX-Filterung Latenzen erleben, wenn die Datenbankabfragen nicht optimiert sind. Indizes auf den Relationen und ein sauber konfiguriertes Caching im TypoScript lösen das Problem in der Regel vollständig. Zusätzlich hilft ein Warm-Up des Caches nach jeder Datenänderung, damit der erste Besucher nach einem Update keine langsame Seite sieht.

Drittes Problem: Mehrsprachigkeit. Internationale Hochschulen mit englischsprachigen Studiengängen brauchen eine durchgängige Übersetzung der Filtermasken, Kategorien und Detailseiten. in2studyfinder nutzt das TYPO3-Übersetzungsframework, aber die Konfiguration der Fallback-Sprachen und der Übersetzungs-Overlays muss sorgfältig auf die Hochschul-Anforderungen abgestimmt werden. Besonders bei Studiengängen, die nur in einer Sprache angeboten werden (z.B. ein deutschsprachiger Bachelor, aber ein englischsprachiger Master), muss das Fallback-Verhalten so konfiguriert sein, dass die Filterung sprachspezifisch arbeitet und keine irreführenden Ergebnisse liefert.

Ein viertes Problem, das Gosign in Hochschul-Projekten regelmässig sieht: Studiengang-Bezeichnungen, die sich über die Jahre ändern. Ein "Diplom-Informatik" wird zum "B.Sc. Informatik", behält aber die gleiche Detail-URL. Die Extension muss so konfiguriert sein, dass Namensänderungen keine Broken Links erzeugen und alte URLs per Redirect auf die aktuelle Seite weiterleiten.

## TYPO3 v12 wird unterstützt, v13-Kompatibilität hängt vom in2code-Releaseplan ab

in2code pflegt in2studyfinder aktiv und liefert regelmässig Updates. Die aktuelle Version unterstützt TYPO3 v11 und v12. Da in2code ein kommerzieller TYPO3-Dienstleister mit langfristiger Produktstrategie ist, ist die v13-Kompatibilität zu erwarten, aber noch nicht offiziell freigegeben. Beim Upgrade von v10 oder v11 auf v12 betreffen Breaking Changes vor allem die TypoScript-Konfiguration (neue SiteSet-Syntax) und eventuelle Custom ViewHelpers in den Templates. Die Datenbankstruktur bleibt stabil, sodass eine Datenmigration in der Regel nicht nötig ist.

--- in2template TYPO3 - Template-Management | Gosign ---
> TYPO3 Template-Management-Extension von in2code. Vereinfacht die Verwaltung von Fluid Templates und Site Packages. Strukturierte.

## in2template bringt Struktur in Site Packages, bevor sie zur Wartungshölle werden

Wer in TYPO3 ein Site Package für eine grosse Website aufsetzt, steht jedes Mal vor derselben Frage: Wie organisiere ich Templates, Partials, Layouts und Content-Elemente so, dass sie in zwei Jahren noch wartbar sind? Die Extension in2template aus dem Haus in2code ist der Versuch, auf diese Frage eine strukturierte Antwort zu geben. Sie liefert ein Grundgerüst für moderne Site Packages: klare Verzeichnisstruktur, vordefinierte Content-Elemente, vorbereitete Konfiguration für TypoScript, Fluid Styled Content und Backend-Layouts. Für TYPO3-Teams, die regelmässig neue Projekte starten, ersetzt in2template die alte Copy-Paste-Praxis aus dem letzten Kundenprojekt durch ein dokumentiertes Muster.

Die Zielgruppe sind Agenturen mit mehreren parallelen TYPO3-Projekten und Inhouse-Teams, die Corporate-Templates für Konzern- oder Hochschul-Sites pflegen. Besonders dort, wo sich Entwicklerinnen und Redakteurinnen das Site Package teilen, ist eine konsistente Ordner- und Namenskonvention überlebenswichtig. in2template adressiert genau diese Lücke.

## Typische Einsatzszenarien

Ein erstes Szenario ist der saubere Projektstart. Eine Agentur mit acht Entwicklerinnen und drei laufenden TYPO3-Projekten führt in2template als internen Standard für Site Packages ein. Jedes neue Projekt beginnt mit demselben Skelett: identische Verzeichnisstruktur, identische Naming-Konventionen, identische TypoScript-Basis. Das Ergebnis: Ein Entwickler kann zwischen Projekten wechseln, ohne sich jedes Mal neu zu orientieren.

Ein zweites Szenario ist die Modernisierung eines alten Site Packages. Ein Hochschul-Portal mit 800 Seiten und einem seit TYPO3 v7 gewachsenen Template-Ordner wird im Rahmen eines Upgrades von v11 auf v12 neu strukturiert. Statt den alten Wildwuchs weiterzutragen, baut das Team das Site Package auf Basis von in2template neu auf und migriert die Inhalte schrittweise.

Ein drittes Szenario ist das Onboarding neuer Redakteure. Ein Verlag mit 30 Redakteuren erklärt auf Basis des in2template-Skeletts, welche Content-Elemente wofür gedacht sind. Die Konsistenz in Benennung und Struktur macht die Schulung kürzer, die Backend-Fehlerquote sinkt.

Ein viertes Szenario ist die interne Refactoring-Vorlage. Ein Unternehmen mit fünf TYPO3-Installationen aus unterschiedlichen Baujahren möchte die Site Packages langfristig in eine einheitliche Struktur überführen. in2template dient dabei als Referenz-Skelett, gegen das jedes Alt-Projekt schrittweise umgebaut wird - ohne dass das Team jedes Mal eine neue Zielstruktur diskutieren muss.

## Technische Architektur

in2template ist kein klassisches Add-on, sondern eher eine Vorlage für ein eigenes Site Package. Die Extension bringt eine Verzeichnisstruktur mit: Resources/Private/Templates, Resources/Private/Partials, Resources/Private/Layouts, Configuration/TypoScript, Configuration/TsConfig, Configuration/TCA/Overrides. Ergänzt wird das Gerüst um vorbereitete Content-Elemente (Text, Text mit Bild, Akkordeon, Teaser-Grid) und eine Konfiguration für Backend-Layouts.

Die Installation erfolgt als klassischer Composer-Download des Packages, das anschliessend in das eigene Site-Package-Repository kopiert und umbenannt wird. In der Praxis nutzen Teams in2template seltener als direkte Abhängigkeit - üblich ist ein initialer Klon, der dann projektspezifisch weiterwächst. Das macht die Extension zu einem Starter-Kit und nicht zu einem Framework, das über Versionen hinweg aktualisiert werden müsste.

Für die Integration mit Fluid Styled Content gibt es eigene Override-Mechanismen, die sicherstellen, dass die mitgelieferten Content-Elemente mit den Core-Elementen koexistieren. TypoScript-Pfade sind durchgängig namespaced, damit mehrere Site Packages auf derselben Installation parallel laufen können.

## Häufige Probleme und Lösungen

Das erste Problem ist die Verwechslung mit einem Framework. Teams, die in2template wie Bootstrap oder Tailwind einbinden und auf Updates hoffen, erleben eine Enttäuschung: Die Extension ist ein Template zum Abkupfern, kein Upstream-Stack. Die Lösung ist, in2template als einmalige Vorlage zu betrachten und das daraus entstehende eigene Site Package klar zu versionieren.

Das zweite Problem ist die Überfrachtung mit nicht genutzten Content-Elementen. Das Starter-Kit bringt mehr Elemente mit, als die meisten Projekte brauchen. Wer sie nicht nutzt, schleppt sie trotzdem durch die Wartung. Die Lösung ist ein Clean-up direkt nach dem initialen Import: Ungenutzte Content-Elemente löschen, nicht genutzte Backend-Layouts entfernen, nicht verwendete TypoScript-Blöcke streichen.

Das dritte Problem ist die Anpassung an individuelle Design-Systeme. in2template liefert Tailwind-nahes CSS mit eigenen Utility-Klassen. Wer ein bestehendes Design-System mit eigenen Token-Namen einsetzt, muss die gelieferten Stylings konsequent übersetzen, sonst entsteht Stil-Dopplung und widersprüchliche Cascade.

Ein viertes Problem sind Konflikte mit anderen Starter-Kits. Wer in2template teilweise übernimmt und parallel Bausteine aus einem anderen Skelett integriert, bekommt widersprüchliche TypoScript-Pfade und überlappende Fluid-Namespaces. Die Lösung ist, bei Projektbeginn eine Entscheidung für genau ein Skelett zu treffen und inkonsistente Zusatz-Komponenten in einer klar benannten Projekt-eigenen Layer zu halten.

## Migration und Versions-Kompatibilität

in2template wird von in2code für TYPO3 v11 und v12 gepflegt, die TYPO3-v13-Kompatibilität wird entlang der Release-Zyklen von TYPO3 selbst aktualisiert. Weil die Extension in Projekten fast immer geklont und angepasst wird, ist die Versions-Frage weniger eine Frage von Update-Pfaden und mehr eine Frage der Code-Disziplin: Teams sollten beim Upgrade ihres Site Packages einen Blick in das aktuelle in2template-Repository werfen, um strukturelle Verbesserungen (neue Backend-Layout-Konventionen, neue Fluid-Pattern) nachzuziehen.

Wichtig beim Upgrade eines auf in2template basierenden Site Packages ist der Blick auf veränderte TYPO3-Konventionen: TCA-Overrides, Backend-Layout-Definitionen, Content-Element-Registrierung und Fluid-Rendering haben sich zwischen v11 und v13 mehrfach bewegt. Wer diese Änderungen nicht im eigenen Site Package nachzieht, läuft Gefahr, dass Inhalte im Backend plötzlich leer wirken oder die Content-Element-Wizards nicht mehr erscheinen.

Gosign übernimmt in TYPO3-Projekten die Analyse, welche Teile des bestehenden Site Packages nach einem in2template-ähnlichen Muster aufgeräumt werden können und welche besser auf ein eigenes, minimalistisches Skelett migrieren. Das Ergebnis ist ein Site Package, das in Code-Reviews ohne Raunen durchgeht und beim nächsten TYPO3-Upgrade keine Überraschungen produziert.

--- Social Share Buttons TYPO3 | Gosign ---
> Social Share Buttons Extension für TYPO3. Gosign empfiehlt stattdessen lightweight Custom Share Links, kein Extension-Overhead, DSGVO-konform,.

## Social Share Buttons als Extension sind in den meisten TYPO3-Projekten überflüssig

Die Idee ist simpel: Besucher sollen Inhalte mit einem Klick auf LinkedIn, X oder Facebook teilen können. insign_share_buttons liefert genau das als TYPO3-Extension - Buttons für verschiedene Netzwerke, konfigurierbar im Backend. Doch die Realität zeigt: Für ein Feature, das im Kern aus fünf HTML-Links besteht, ist eine vollständige Extension mit eigener Konfiguration, TypoScript-Setup und Update-Pflicht in den meisten Fällen Overhead. Gosign empfiehlt stattdessen native Share-Links, die in 15 Minuten implementiert sind und keine Abhängigkeit erzeugen.

Das gilt besonders seit der DSGVO: Viele Social-Share-Extensions laden im Hintergrund JavaScript von den Netzwerken nach, was ohne Consent-Abfrage datenschutzwidrig ist. Reine URL-basierte Share-Links umgehen dieses Problem vollständig, weil sie erst beim Klick eine Verbindung zum jeweiligen Netzwerk aufbauen. Datenschutzbeauftragte prüfen Share-Buttons regelmässig bei Website-Audits, und eine Extension, die ungefragt externe Scripte lädt, fällt dabei als Befund auf.

## Typische Einsatzszenarien beschränken sich auf redaktionell gepflegte Inhalte

Das Standardszenario ist die Unternehmenswebsite mit Blog oder Magazin. Redakteure wollen unter jedem Artikel Buttons für LinkedIn, X, Facebook und E-Mail anzeigen. insign_share_buttons ermöglicht das über ein Content-Element, das in die Seitenvorlage eingebaut wird. Die Extension liest Titel und URL der aktuellen Seite aus und generiert daraus die Share-URLs.

Ein zweites Szenario betrifft Intranet-Portale, in denen Mitarbeitende interne News über Teams oder Slack teilen sollen. Hier ist die Extension tatsächlich nützlicher als bei öffentlichen Websites, weil die DSGVO-Problematik innerhalb eines Unternehmens anders bewertet wird und die Konfiguration der Share-Ziele über das Backend gepflegt werden kann.

Drittes Szenario: Websites mit Employer-Branding-Fokus, auf denen Stellenausschreibungen über Social Media verbreitet werden sollen. Die Share-Buttons werden gezielt auf Karriereseiten eingesetzt, damit Mitarbeitende offene Stellen in ihrem Netzwerk teilen können. Die Conversion-Rate dieser Buttons liegt nach Erfahrungswerten bei 0,5 bis 2% der Seitenbesucher. Bei LinkedIn sind die Klickraten auf geteilte Stellenausschreibungen dabei doppelt so hoch wie bei allgemeinen Unternehmens-News, was dieses Szenario zum effektivsten Einsatzfall für Social Share Buttons macht.

## Technische Architektur ist ein simples Content-Element mit TypoScript-Konfiguration

insign_share_buttons registriert ein Content-Element in TYPO3, das über die Seitenvorlage oder als Plugin eingefügt wird. Die Konfiguration definiert, welche Netzwerke angezeigt werden, ob Icons oder Text-Labels verwendet werden und ob Zähler eingeblendet werden sollen. Das Rendering erfolgt über Fluid-Templates, die im Site-Package überschreibbar sind.

Die Share-URLs werden serverseitig generiert und folgen dem Standard-Schema der jeweiligen Netzwerke: `https://www.linkedin.com/sharing/share-offsite/?url=` plus die encodierte Seiten-URL für LinkedIn, `https://twitter.com/intent/tweet?url=` für X. Meta-Daten wie Titel und Beschreibung werden aus den Seiteneigenschaften oder den OpenGraph-Tags ausgelesen.

Die Extension hat keine nennenswerten Abhängigkeiten ausser dem TYPO3-Core. Es gibt kein JavaScript-Laden von externen Domains, solange die Zähler-Funktion deaktiviert bleibt. Wird die Zähler-Funktion aktiviert, werden API-Calls zu den Netzwerken ausgelöst, was wiederum eine Consent-Abfrage erfordert.

Ein technisches Detail, das oft übersehen wird: Die Share-URL muss URL-encodiert sein, damit Sonderzeichen in Seitentiteln (Umlaute, kaufmännisches Und, Anführungszeichen) korrekt an die Netzwerke übergeben werden. Die Extension kümmert sich um dieses Encoding automatisch, was bei manuellen Share-Links ein häufiger Fehler ist.

## Häufige Probleme sind DSGVO-Verstösse, fehlende OpenGraph-Tags und Styling-Konflikte

Problem eins: Datenschutz. Viele Installationen haben die Zähler-Funktion aktiv, die ohne Cookie-Consent personenbezogene Daten an US-Server überträgt. Die Lösung: Zähler deaktivieren und ausschliesslich URL-basierte Share-Links verwenden, die erst beim Klick eine Verbindung aufbauen. Noch besser: Die Extension komplett durch native Share-Links ersetzen, die als Fluid-Partial im Site-Package liegen.

Problem zwei: Fehlende oder falsche OpenGraph-Tags. Wenn die TYPO3-Seite keine og:title und og:description meta-Tags liefert, zeigen LinkedIn und Facebook beim Teilen eine leere Vorschau oder ziehen sich zufällige Textfragmente. Die Lösung ist nicht in der Share-Extension, sondern in der SEO-Konfiguration der Seite: OpenGraph-Tags müssen in der Seitenvorlage korrekt gesetzt sein.

Problem drei: Styling-Konflikte zwischen den mitgelieferten CSS-Styles der Extension und dem Corporate Design. Die Extension bringt eigene Stylesheets mit, die mit bestehenden Button-Styles kollidieren können. Die saubere Lösung: Das Extension-CSS deaktivieren und die Buttons über das eigene Site-Package-Stylesheet stylen.

Ein weiteres Problem, das oft erst spät auffällt: fehlende WhatsApp-Share-Unterstützung. Auf Mobilgeräten ist WhatsApp der meistgenutzte Share-Kanal, aber nicht jede Extension unterstützt den WhatsApp-Share-Link nativ. Die manuelle Ergänzung ist trivial (https://api.whatsapp.com/send?text={url}), muss aber explizit eingebaut werden.

## Die Extension funktioniert unter TYPO3 v12, ein Neubau ist aber wirtschaftlicher

insign_share_buttons ist mit TYPO3 v12 kompatibel. Für TYPO3 v13 hängt die Verfügbarkeit vom Maintainer ab. Gosign empfiehlt bei einer Migration auf v12 oder v13, die Extension durch ein einfaches Fluid-Partial zu ersetzen. Fünf Zeilen HTML pro Netzwerk, keine Extension-Abhängigkeit, keine Update-Pflicht, volle DSGVO-Konformität. Der Aufwand für diese Umstellung liegt bei ein bis zwei Stunden inklusive Styling und Testing aller Netzwerk-Links. Bei Gosign setzen wir diesen Ansatz standardmässig in allen neuen TYPO3-Projekten ein und pflegen ein Partial-Template-Set für LinkedIn, X, Facebook, WhatsApp und E-Mail, das in jedes Sitepackage integrierbar ist.

--- Inxmail TYPO3 - Enterprise Newsletter | Gosign ---
> Inxmail Professional ist ein Enterprise-Newsletter-System aus Deutschland. TYPO3-Anbindung: Subscriber-Sync, Template-Synchronisation,.

## Inxmail ist die Enterprise-Newsletter-Plattform, die TYPO3-Redaktionen nativ anbindet

Unternehmen mit mehr als 50.000 Newsletter-Empfängern, strengen Compliance-Anforderungen und einem bestehenden TYPO3-Webauftritt stehen vor einer konkreten Entscheidung: Mailchimp mit US-Datenverarbeitung und DSGVO-Risiko oder eine deutsche Lösung, die sich direkt in die bestehende Content-Infrastruktur integriert. Inxmail Professional ist diese Lösung. Server in Deutschland, zertifizierte Datenverarbeitung, und eine TYPO3-Extension, die Subscriber-Listen, Templates und Kampagnen direkt aus dem CMS heraus steuert.

Die TYPO3-Extension synchronisiert Anmeldungen bidirektional: Neue Subscriber aus TYPO3-Formularen landen automatisch in Inxmail-Listen, Abmeldungen in Inxmail werden zurück nach TYPO3 gespiegelt. Für Marketing-Teams bedeutet das: Eine Datenquelle, keine manuellen Exporte, kein Risiko veralteter Listen. In der Praxis eliminiert das den häufigsten Fehler bei Newsletter-Versand: den Versand an eine veraltete Empfängerliste, die bereits abgemeldete Kontakte enthält.

## Typische Einsatzszenarien decken B2B-Newsletter, Transaktionsmails und Event-Kommunikation ab

Das Hauptszenario ist der klassische B2B-Newsletter für Unternehmen mit 10.000 bis 500.000 Empfängern. Die Redaktion pflegt Inhalte in TYPO3, die Extension überträgt Teaser und Links automatisch in Inxmail-Templates. Marketing-Verantwortliche segmentieren die Empfänger nach Branche, Region oder Interesse und versenden zielgruppenspezifische Varianten. Öffnungsraten und Klickdaten fliessen über die API zurück ins TYPO3-Backend, sodass die Redaktion die Performance einzelner Beiträge sehen kann.

Zweites Szenario: Transaktionsmails, die durch Nutzeraktionen auf der Website ausgelöst werden. Eine Registrierungsbestätigung, ein Download-Link oder eine Bestellbestätigung wird nicht über den lokalen Mailserver verschickt, sondern über die Inxmail-Infrastruktur mit garantierter Zustellrate. SPF, DKIM und DMARC sind in Inxmail vorkonfiguriert, was die Zustellbarkeit gegenüber einem Standard-PHP-Mailer deutlich verbessert.

Drittes Szenario: Event-Kommunikation für Unternehmen, die regelmässig Messen, Webinare oder Konferenzen veranstalten. Die Einladung, Reminder und Follow-up-Mails werden als Trigger-basierte Kampagnen in Inxmail konfiguriert und durch Events in TYPO3 ausgelöst, etwa durch eine Anmeldung über ein powermail-Formular. Die Trigger-Logik erlaubt auch komplexere Sequenzen: Einladung vier Wochen vorher, Erinnerung eine Woche vorher, Teilnahmebestätigung am Vortag und Feedback-Anfrage zwei Tage danach.

## Technische Architektur verbindet TYPO3-Frontend-Formulare mit der Inxmail-REST-API

Die Extension nutzt die Inxmail REST-API für die Kommunikation zwischen TYPO3 und Inxmail Professional. Im Kern besteht die Integration aus drei Modulen: einem Subscriber-Sync-Service, einem Template-Sync-Modul und einem Kampagnen-Trigger.

Der Subscriber-Sync läuft über einen Scheduler-Task, der in konfigurierbaren Intervallen (typisch: alle 5 bis 15 Minuten) neue Anmeldungen, Änderungen und Abmeldungen zwischen TYPO3 und Inxmail abgleicht. Die Sync-Richtung ist konfigurierbar: unidirektional (TYPO3 zu Inxmail) oder bidirektional. Bei bidirektionalem Sync werden Konflikte über Timestamps gelöst, wobei der neuere Datensatz gewinnt.

Das Template-Sync-Modul überträgt TYPO3-Seitenbereiche als Newsletter-Inhalte. Redakteure markieren Content-Elemente im TYPO3-Backend als "Newsletter-fähig", und die Extension rendert diese Elemente in ein Inxmail-kompatibles HTML-Template. Das erspart die doppelte Pflege von Website-Content und Newsletter-Content.

Die Authentifizierung erfolgt über API-Keys, die im TYPO3-Extension-Manager konfiguriert werden. Alle API-Calls laufen über HTTPS, und die Extension loggt jeden Sync-Vorgang in eine dedizierte Log-Tabelle, was für Compliance-Audits relevant ist. Die Log-Daten enthalten Zeitstempel, Anzahl synchronisierter Records, Fehler und Warnungen, sodass bei einem Audit nachgewiesen werden kann, wann welche Daten übertragen wurden.

## Häufige Probleme betreffen Sync-Konflikte, Template-Rendering und API-Rate-Limits

Das dominierende Supportthema ist der Sync-Konflikt bei bidirektionaler Synchronisation. Wenn ein Subscriber sowohl in TYPO3 als auch in Inxmail gleichzeitig geändert wird, kann es zu Dateninkonsistenzen kommen. Die Lösung: Klare Sync-Richtung definieren. In 90% der Fälle ist TYPO3 die führende Quelle für Stammdaten, Inxmail die führende Quelle für Engagement-Daten (Öffnungen, Klicks, Bounces).

Zweites Problem: HTML-Rendering-Unterschiede zwischen TYPO3-Frontend und E-Mail-Client. Ein Content-Element, das auf der Website korrekt dargestellt wird, kann in Outlook oder Gmail anders aussehen. Die Extension übersetzt zwar TYPO3-HTML in Inline-CSS für E-Mail-Kompatibilität, aber komplexe Layouts mit Flexbox oder Grid müssen für E-Mail-Clients vereinfacht werden. Wir empfehlen, Newsletter-Templates separat zu testen, idealerweise mit einem Tool wie Litmus oder Email on Acid.

Drittes Problem: API-Rate-Limits bei grossen Sync-Vorgängen. Wer 100.000 Subscriber auf einmal synchronisiert, kann das API-Limit von Inxmail erreichen. Die Lösung: Batch-basierter Sync mit konfigurierbarer Paketgrösse (empfohlen: 500 Records pro API-Call) und exponentielles Backoff bei Rate-Limit-Responses.

## TYPO3 v12 wird über die offizielle Extension unterstützt, v13 erfordert Prüfung

Inxmail pflegt die TYPO3-Extension aktiv, da der TYPO3-Markt ein relevanter Vertriebskanal für Inxmail Professional ist. Die aktuelle Version unterstützt TYPO3 v11 und v12. Beim Upgrade von v10 auf v12 müssen vor allem die Scheduler-Task-Konfigurationen angepasst werden, da TYPO3 v12 die Scheduler-API geändert hat. Die API-Authentifizierung und der Subscriber-Sync bleiben stabil.

Für TYPO3 v13 liegt noch kein offizielles Release vor. Unternehmen, die ein v13-Upgrade planen, sollten die Verfügbarkeit frühzeitig mit Inxmail abstimmen, da Enterprise-Newsletter-Integrationen zu den kritischsten Abhängigkeiten bei einem CMS-Upgrade gehören. Als Zwischenlösung kann die Integration über einen Custom Middleware-Layer realisiert werden, der die Inxmail-API direkt anspricht, ohne die Extension zu verwenden. Gosign hat diese Lösung für Kunden umgesetzt, die auf v13 migrieren wollten, bevor die offizielle Extension verfügbar war. Der Custom-Layer ist zudem wartungsärmer, weil er nur die tatsächlich genutzten API-Endpoints anspricht und keine ungenutzten Features mitschleppt.

--- iSpider TYPO3 - Web-Crawler | Gosign ---
> Web-Crawler/Spider für TYPO3: Interne Seiten crawlen, Broken Links finden, Sitemap generieren. QA-Tool für Quality Assurance und SEO-Analyse.

## Broken Links kosten Rankings und Vertrauen, aber kaum jemand prüft sie regelmässig

Jede TYPO3-Website mit mehr als 200 Seiten hat Broken Links. Redakteure löschen Seiten, verschieben Inhalte oder ändern URL-Slugs, ohne alle internen Verlinkungen zu prüfen. Das Ergebnis: 404-Fehler, die Google als Qualitätssignal wertet und die Besucher frustrieren. iSpider ist ein interner Web-Crawler für TYPO3, der das eigene Frontend crawlt, Broken Links identifiziert und eine Sitemap generiert. Das Werkzeug schliesst die Lücke zwischen manueller Prüfung und externen SEO-Tools, die keinen Zugriff auf geschützte Bereiche haben.

Für Redaktionen und technische Projektleiter ist iSpider ein QA-Instrument, das ohne externe Abhängigkeiten auskommt. Der Crawler läuft im TYPO3-Backend, kennt die Seitenstruktur und kann auch passwortgeschützte Bereiche prüfen, die externe Tools wie Screaming Frog nicht erreichen. Die Ergebnisse sind direkt im TYPO3-Backend verfügbar, was die Korrektur von Broken Links durch Redakteure beschleunigt, weil sie nicht zwischen verschiedenen Tools wechseln müssen.

## Typische Einsatzszenarien reichen von Pre-Launch-Checks bis zum laufenden Monitoring

Das häufigste Szenario ist der Pre-Launch-Check vor einem Relaunch oder TYPO3-Upgrade. Bevor eine neue Version live geht, crawlt iSpider die Staging-Umgebung und liefert eine vollständige Liste aller Broken Links, fehlenden Bilder und Redirect-Ketten. Ein typischer Relaunch einer mittelgrossen Website (500 bis 1.000 Seiten) produziert erfahrungsgemäss 30 bis 80 Broken Links, die ohne systematischen Crawl unentdeckt in Produktion gehen würden.

Zweites Szenario: Laufendes Monitoring im Redaktionsalltag. Ein wöchentlicher Scheduler-Task crawlt die Website und sendet einen Report an die Redaktion mit allen neuen 404-Fehlern seit dem letzten Durchlauf. So werden Probleme innerhalb von Tagen statt Monaten erkannt und behoben.

Drittes Szenario: SEO-Analyse für interne Verlinkungsstruktur. iSpider zeigt, welche Seiten keine eingehenden internen Links haben (verwaiste Seiten) und welche Seiten besonders viele eingehende Links besitzen. Diese Daten helfen bei der Content-Strategie und der internen Link-Optimierung. Eine typische Analyse deckt auf, dass 10 bis 15% aller Seiten verwaist sind und von Google folglich selten oder nie gecrawlt werden.

## Technische Architektur arbeitet als Backend-Modul mit Scheduler-Integration

iSpider registriert sich als Backend-Modul in TYPO3 und nutzt den TYPO3-Scheduler für automatisierte Crawl-Durchläufe. Der Crawler startet von einer konfigurierbaren Einstiegsseite (typischerweise die Root-Page) und folgt allen internen Links rekursiv bis zu einer einstellbaren Tiefe. Externe Links werden auf Erreichbarkeit geprüft, aber nicht weiterverfolgt.

Die Ergebnisse werden in einer eigenen Datenbanktabelle gespeichert: URL, HTTP-Statuscode, Antwortzeit, referenzierende Seite und Zeitstempel. Das Backend-Modul zeigt die Ergebnisse als filterbare Liste mit Sortierung nach Statuscode, was die Priorisierung von Fixes erleichtert.

Die Crawl-Geschwindigkeit ist über die Konfiguration steuerbar: Gleichzeitige Requests, Wartezeit zwischen Requests und maximale Crawl-Tiefe. Für grosse Installationen mit über 5.000 Seiten empfiehlt sich ein nächtlicher Crawl über den Scheduler, um die Server-Last tagsüber nicht zu beeinträchtigen. Die Ergebnisse bleiben in der Datenbank gespeichert und sind über das Backend-Modul jederzeit abrufbar, auch zwischen den Crawl-Durchläufen. Das erlaubt einen historischen Vergleich der Broken-Link-Entwicklung über Wochen und Monate.

## Häufige Probleme sind Server-Timeouts, unvollständige Crawls und false Positives

Das häufigste Problem: Der Crawl bricht bei grossen Websites ab, weil das PHP-Memory-Limit oder die max_execution_time erreicht wird. Die Lösung: Den Crawl über den Scheduler in Batches aufteilen und die PHP-Limits für den CLI-Kontext erhöhen (empfohlen: memory_limit 512M, max_execution_time 0 für CLI).

Zweites Problem: Unvollständige Crawls bei JavaScript-gerenderten Inhalten. iSpider ist ein serverseitiger Crawler, der kein JavaScript ausführt. Single-Page-Applications oder Inhalte, die erst per AJAX nachgeladen werden, erfasst der Crawler nicht. Die Lösung: Für JavaScript-lastige Bereiche einen externen Crawler wie Screaming Frog ergänzend einsetzen.

Drittes Problem: False Positives bei externen Links. Manche Websites blockieren Crawler per User-Agent-Erkennung und liefern einen 403-Statuscode, obwohl die URL für Browser erreichbar ist. iSpider meldet das als Fehler. Die Lösung: Eine Ausnahmeliste für bekannte False Positives konfigurieren und den User-Agent-String auf einen Browser-typischen Wert setzen. LinkedIn, Facebook und einige CDN-geschützte Websites sind typische Kandidaten für False Positives.

Ein weiteres Problem: Redirect-Ketten. iSpider folgt Redirects (301, 302), meldet aber nicht, wie viele Hops nötig waren. Dreifach- oder Vierfach-Redirects sind ein SEO-Problem, das ohne detaillierte Redirect-Analyse unsichtbar bleibt. Externe Crawler wie Screaming Frog zeigen die vollständige Redirect-Kette inklusive Zwischenstationen, was iSpider nicht leistet.

## iSpider ist ein Legacy-Tool, externe Crawler-Alternativen sind leistungsfähiger

iSpider wurde für TYPO3 v7 und v8 entwickelt und hat keine offizielle Unterstützung für v12 oder v13. Wer auf aktuelle TYPO3-Versionen migriert, sollte externe Alternativen evaluieren. Screaming Frog (Desktop-Tool, bis 500 URLs kostenlos), Sitebulb oder der integrierte TYPO3-Linkvalidator decken die Kernfunktionen ab. Gosign nutzt in eigenen Projekten eine Kombination aus dem TYPO3-Core-Linkvalidator für interne Prüfungen und automatisierten Screaming-Frog-Crawls für umfassende SEO-Analysen. Bei einer Migration von iSpider prüfen wir, welche Konfigurationen und Reports im bestehenden Setup kritisch sind, und bilden diese in der neuen Lösung ab.

--- iubenda TYPO3 - Datenschutz | Gosign ---
> iubenda bietet Cookie-Consent-Banner und automatisch generierte Privacy Policies. Die TYPO3-Integration bettet beides ein. Alternative.

## Cookie-Consent und Privacy Policy aus einer Hand klingt praktisch, hat aber Abhängigkeiten

Seit der DSGVO und dem TTDSG braucht jede Website ein Cookie-Consent-Banner und eine aktuelle Datenschutzerklärung. iubenda bietet beides als SaaS-Lösung: Ein JavaScript-Widget für das Consent-Banner und einen Generator für Datenschutz- und Cookie-Richtlinien, die sich automatisch aktualisieren, wenn sich Gesetze ändern. Die TYPO3-Extension bettet beides in den Seitenquellcode ein. Für Unternehmen, die weder einen Datenschutzbeauftragten noch eine Kanzlei mit der laufenden Pflege beauftragen wollen, ist iubenda eine pragmatische Lösung.

Der Trade-off ist klar: Komfort gegen Abhängigkeit. Das Consent-Banner und die Privacy Policy werden von iubenda-Servern geladen. Fällt der Service aus oder ändert sich die API, ist die Website betroffen. Alternativen wie dp_cookieconsent oder Usercentrics arbeiten nach dem gleichen Prinzip, aber mit unterschiedlichen Schwerpunkten in Konfigurierbarkeit und Preis.

## Typische Einsatzszenarien betreffen KMU-Websites, Portale und internationale Auftritte

Das Standardszenario ist die mittelständische Unternehmenswebsite mit 20 bis 100 Seiten, die Google Analytics, ein Kontaktformular und eingebettete YouTube-Videos nutzt. iubenda scannt die Website, erkennt die verwendeten Services automatisch und generiert eine passende Cookie-Richtlinie. Das Consent-Banner blockiert die erkannten Cookies, bis der Besucher einwilligt. Der Einrichtungsaufwand für dieses Szenario liegt bei ein bis zwei Stunden.

Zweites Szenario: Mehrsprachige Portale, die in verschiedenen Rechtsräumen operieren. iubenda unterstützt neben der DSGVO auch das kalifornische CCPA und das brasilianische LGPD. Die Datenschutzerklärung wird automatisch in der Sprache des Besuchers angezeigt und enthält die relevanten Rechtsgrundlagen für den jeweiligen Standort. Für Unternehmen mit Zielgruppen in Europa, den USA und Südamerika spart das die separate Erstellung von drei bis vier verschiedenen Policies.

Drittes Szenario: Websites mit häufig wechselnden Third-Party-Einbindungen. Wenn Marketing-Abteilungen regelmässig neue Tracking-Pixel, Chat-Widgets oder Social-Media-Embeds einbauen, aktualisiert iubenda die Cookie-Richtlinie automatisch beim nächsten Website-Scan. Das reduziert das Risiko, dass neue Dienste ohne Consent-Abfrage laufen. In der Praxis ist das besonders relevant für Unternehmen, die Marketing-Automation-Tools nutzen und monatlich neue A/B-Tests, Heatmap-Tracker oder Conversion-Pixel einbauen, ohne die IT-Abteilung zu informieren.

## Technische Architektur bettet ein externes JavaScript-Widget in TYPO3 ein

Die TYPO3-Extension integriert iubenda über zwei Code-Snippets: Ein JavaScript-Tag für das Consent-Banner und einen Embed-Code für die Privacy Policy. Beide Snippets werden im TYPO3-Extension-Manager konfiguriert und automatisch im HTML-Header bzw. auf der Datenschutzseite ausgegeben. Die Extension selbst ist minimal und enthält kaum eigene Logik.

Das Consent-Banner arbeitet nach dem TCF-2.0-Standard (Transparency and Consent Framework) und blockiert Cookies über eine Proxy-Technik: Externe Scripts werden erst geladen, wenn der Besucher eingewilligt hat. Die Blockierung funktioniert über das Umschreiben von Script-Tags (type="text/plain" statt type="text/javascript") und das Nachladen per JavaScript nach Consent.

Die automatische Policy-Generierung basiert auf einem Website-Scanner, der die Domain crawlt und verwendete Dienste erkennt. Die generierten Texte sind rechtlich geprüft und werden von iubendas Anwaltsteam bei Gesetzesänderungen aktualisiert. Die Policy wird entweder als iFrame oder als direkter HTML-Embed auf der Datenschutzseite eingebunden.

## Häufige Probleme sind Script-Blocking-Fehler, Performance-Einbussen und Content-Shift

Das häufigste Problem: Nicht alle Third-Party-Scripts werden korrekt blockiert. Wenn ein Script nicht über ein Standard-HTML-Tag, sondern dynamisch per JavaScript nachgeladen wird, erkennt die Proxy-Technik es möglicherweise nicht. Die Lösung: Manuelle Überprüfung aller eingebundenen Dienste und explizite Konfiguration im iubenda-Dashboard. Ein Browser-Plugin wie "CookieMetrix" hilft bei der Verifizierung.

Zweites Problem: Performance-Einbussen durch das zusätzliche JavaScript. Das iubenda-Widget ist 40 bis 80 KB gross (komprimiert) und wird von externen Servern geladen. Das kann den Largest Contentful Paint um 200 bis 400ms verschlechtern. Die Lösung: Das Widget asynchron laden und sicherstellen, dass es nicht render-blockierend ist.

Drittes Problem: Content Layout Shift durch das nachträglich eingeblendete Banner. Wenn das Banner über dem Seiteninhalt erscheint, verschiebt es den sichtbaren Bereich. Google misst das als Cumulative Layout Shift (CLS) und wertet es negativ. Die Lösung: Das Banner als Overlay (nicht als eingeschobenes Element) konfigurieren oder einen festen Platzhalter im CSS reservieren. Ein CLS-Wert unter 0,1 ist das Ziel, und ein schlecht konfiguriertes Consent-Banner kann diesen Wert allein auf 0,3 oder höher treiben.

Zusätzlich berichten manche Administratoren, dass das iubenda-Dashboard in der Konfiguration komplex ist. Die Unterscheidung zwischen "Cookie Solution" (Consent-Banner), "Privacy Controls and Cookie Solution" (erweitert) und "Consent Database" (für Compliance-Dokumentation) erfordert ein Verständnis der eigenen rechtlichen Anforderungen, das viele Webmaster nicht mitbringen. Gosign konfiguriert iubenda im Rahmen von TYPO3-Projekten gemeinsam mit dem Datenschutzbeauftragten des Kunden, damit die technische Konfiguration zur rechtlichen Bewertung passt.

## iubenda funktioniert TYPO3-versionsunabhängig, weil die Integration minimal ist

Da die Extension im Kern nur zwei JavaScript-Snippets einbindet, gibt es keine tiefe TYPO3-API-Abhängigkeit. Die Integration funktioniert mit TYPO3 v10, v11, v12 und voraussichtlich auch v13 ohne Anpassungen. Beim Upgrade muss lediglich geprüft werden, ob die Snippet-Einbindung im HTML-Header noch korrekt greift, was in der Regel der Fall ist. Gosign empfiehlt dennoch, bei jedem TYPO3-Upgrade einen Cookie-Consent-Test durchzuführen, um sicherzustellen, dass alle Blocking-Regeln noch funktionieren.

--- j77 Template TYPO3 | Gosign ---
> Template-Paket für TYPO3. Fertiges Layout als Startpunkt. Gosign empfiehlt Custom Sitepackages statt fertiger Templates für professionelle Projekte.

## Fertige TYPO3-Templates beschleunigen den Start, bremsen aber die Weiterentwicklung

j77_template ist ein vorkonfiguriertes Template-Paket für TYPO3, das ein fertiges Layout als Startpunkt liefert. Header, Footer, Navigation, Content-Bereiche und grundlegende Styling-Definitionen sind enthalten. Für Agenturen, die schnell einen TYPO3-Prototyp aufsetzen wollen, oder für interne IT-Abteilungen ohne Frontend-Entwickler ist das verlockend: Installation, Aktivierung, fertig. Die Realität zeigt allerdings, dass fertige Templates in professionellen Projekten nach 3 bis 6 Monaten mehr Arbeit verursachen als sie einsparen.

Der Grund: Jedes Template-Paket bringt eine eigene HTML-Struktur, CSS-Klassen und TypoScript-Konfiguration mit. Sobald das Design vom Standard abweichen soll, kämpft man gegen die Template-Logik statt mit ihr. Ein Custom Sitepackage, das von Anfang an auf die Anforderungen zugeschnitten ist, kostet initial mehr, spart aber bei jeder späteren Änderung Zeit.

## Typische Einsatzszenarien sind Prototypen, interne Portale und Vereinswebsites

Das häufigste Szenario ist der Schnellstart für Prototypen und Proof-of-Concepts. Eine Agentur will einem Kunden innerhalb von zwei Tagen zeigen, wie sein Content in TYPO3 aussehen könnte. j77_template liefert ein vorzeigbares Layout ohne Frontend-Entwicklung. Der Prototyp wird nach der Freigabe durch ein massgeschneidertes Sitepackage ersetzt.

Zweites Szenario: Interne Portale und Intranet-Anwendungen, bei denen das Design sekundär ist. Eine IT-Abteilung baut ein internes Wissensportal auf TYPO3 und braucht eine funktionale Oberfläche, kein Corporate Design. j77_template liefert Navigation, Breadcrumb und Content-Rendering out of the box.

Drittes Szenario: Vereinswebsites und kleine Non-Profit-Auftritte mit begrenztem Budget. Wenn das gesamte Webprojekt unter 5.000 Euro liegen muss, kann ein fertiges Template-Paket die Frontend-Entwicklungskosten eliminieren und das Budget für Content und Funktionalität freihalten. In der Praxis betrifft das Sportvereine, Musikschulen, Freiwilligeninitiativen und Elternvereine, die eine schlichte, funktionale Website brauchen und keine besonderen Design-Anforderungen haben.

## Technische Architektur ist ein Standard-Sitepackage mit vorkonfiguriertem TypoScript

j77_template ist technisch ein TYPO3-Sitepackage, das über den Extension-Manager installiert wird. Es bringt Fluid-Templates für Page-Layouts, Partial-Templates für Header, Footer und Navigation sowie TypoScript-Konfigurationen für Content-Rendering mit. Die CSS-Dateien basieren auf Bootstrap oder einer vergleichbaren Framework-Basis.

Die Template-Struktur folgt dem TYPO3-Standard: Resources/Private/Templates für Page-Layouts, Resources/Private/Partials für wiederverwendbare Bereiche und Resources/Private/Layouts für Fluid-Rahmen-Templates. Die TypoScript-Konfiguration setzt die Template-Pfade, konfiguriert das Content-Rendering über FLUIDTEMPLATE und definiert die Navigationsstruktur.

Anpassungen sind möglich, indem die Template-Pfade per TypoScript auf eigene Dateien umgelenkt werden. Das funktioniert für einzelne Templates, führt aber bei umfangreichen Änderungen dazu, dass man de facto ein paralleles Sitepackage pflegt, was den Vorteil des fertigen Templates zunichtemacht.

Ein typisches Problem bei Template-Paketen ist die Bootstrap-Abhängigkeit. j77_template setzt auf eine bestimmte Bootstrap-Version. Wenn das Projekt eine andere CSS-Framework-Version benötigt oder komplett auf Tailwind oder eigenes CSS umsteigen will, kollidiert das mit dem Template-Setup. Die mitgelieferten CSS-Dateien sind nicht modular aufgebaut, sondern als monolithischer Bundle ausgeliefert, der sich nur schwer partiell überschreiben lässt.

## Häufige Probleme sind Upgrade-Konflikte, CSS-Overrides und fehlende Dokumentation

Problem eins: Upgrade-Konflikte beim TYPO3-Update. Template-Pakete sind eng an eine TYPO3-Version gebunden. Wenn ein Upgrade Breaking Changes in Fluid oder TypoScript einführt, muss das Template-Paket aktualisiert werden. Wenn der Maintainer das nicht rechtzeitig tut, blockiert das Template das gesamte TYPO3-Upgrade. Bei eigenen Sitepackages hat man diese Kontrolle selbst.

Problem zwei: CSS-Overrides, die sich gegenseitig überschreiben. Das Template bringt eigene Styles mit, das Corporate Design erfordert Abweichungen, und zusätzliche Extensions haben ebenfalls CSS. Das Ergebnis ist eine Kaskade von Overrides, die bei jeder Änderung unvorhersehbare Seiteneffekte produziert. Die Lösung ist ein dediziertes Stylesheet, das die Template-Styles komplett überschreibt, was aber den Zweck des Templates untergraebt.

Problem drei: Fehlende oder veraltete Dokumentation. Community-Templates wie j77_template werden oft von Einzelpersonen gepflegt und haben keine professionelle Dokumentation. Welche TypoScript-Konstanten verfügbar sind, welche Fluid-Variablen in den Templates existieren und wie das Responsive-Verhalten konfiguriert wird, muss man durch Code-Analyse herausfinden. Ohne Dokumentation ist jeder Entwicklerwechsel ein Risiko, weil das Projekt-Wissen an eine Person gebunden ist, die das Template durchanalysiert hat.

## Für v12 und v13 empfiehlt Gosign den Wechsel auf ein eigenes Sitepackage

j77_template hat keine garantierte Unterstützung für TYPO3 v12 oder v13. Bei einer Migration ist der ideale Zeitpunkt, das Template-Paket durch ein eigenes Sitepackage zu ersetzen. Die Kosten für ein eigenes Sitepackage amortisieren sich bereits beim ersten grösseren Design-Change, der mit einem fremden Template stunden- oder tagelange Override-Arbeit bedeuten würde.

Gosign erstellt Sitepackages, die exakt auf das Corporate Design und die funktionalen Anforderungen des Projekts zugeschnitten sind. Der initiale Aufwand für ein einfaches Sitepackage liegt bei 2 bis 5 Arbeitstagen, abhängig von der Komplexität des Designs. KI-gestützte Template-Generierung beschleunigt den Prozess: Aus einem Design-Mockup generiert unser Tooling die Fluid-Templates, TypoScript-Konfiguration und CSS-Grundstruktur, die Senior-Entwickler dann finalisieren. Ein Sitepackage, das Gosign ausliefert, enthält neben den Templates auch eine Dokumentation der verfügbaren Content-Elemente, TypoScript-Konstanten und Page-Layouts, damit auch Entwickler, die das Projekt übernehmen, sofort produktiv arbeiten können.

--- jumpurl TYPO3 - Download-Tracking | Gosign ---
> jumpurl: Legacy Download-Tracking in TYPO3. Migration auf moderne Tracking-Lösungen. KI-beschleunigt.

## jumpurl ist seit TYPO3 v9 aus dem Core entfernt und sollte nicht mehr eingesetzt werden

jumpurl war jahrelang fester Bestandteil des TYPO3-Cores und tat eine simple Sache: Downloads und externe Links über eine Redirect-URL leiten, um Klicks zählbar zu machen. Ein PDF-Download ging nicht direkt an den Browser, sondern über eine jumpurl-Adresse, die den Klick in der Datenbank protokollierte und dann zum eigentlichen Download weiterleitete. In der Hochzeit der Extension nutzten geschätzt 40% aller TYPO3-Installationen jumpurl für Download-Tracking. Seit TYPO3 v9 ist jumpurl nicht mehr im Core enthalten. Als eigenständige Extension existiert sie zwar weiter, aber die Architektur ist veraltet und moderne Alternativen sind in jeder Hinsicht überlegen.

Wer jumpurl noch im Einsatz hat, arbeitet mit einer Technik aus der TYPO3-v4-Ära. Die Extension erzeugt kryptische URLs mit Hash-Parametern, die weder menschenlesbar noch SEO-freundlich sind. Das Tracking basiert auf Datenbank-Einträgen, die kein modernes Analytics-Tool nativ auswerten kann. Für ein Feature, das heute jedes Standard-Analytics-Setup über Events abbildet, ist eine eigene Extension mit Datenbank-Overhead nicht mehr zeitgemäss.

## Typische Einsatzszenarien waren Download-Tracking und Link-Monitoring

Das Hauptszenario war und ist Download-Tracking: Wie oft wurde das Whitepaper heruntergeladen, wie oft die Preisliste, wie oft der Produktkatalog? jumpurl protokolliert jeden Klick in einer Datenbanktabelle mit Zeitstempel, IP-Adresse und Referrer. Unternehmen mit 50 bis 200 Downloads pro Tag nutzen diese Daten für Content-Strategie und Lead-Qualifizierung.

Zweites Szenario: Tracking externer Links. Wenn eine Unternehmenswebsite auf Partner, Lieferanten oder Ressourcen verlinkt, zeigt jumpurl, welche externen Ziele die meisten Klicks erhalten. Das ist relevant für Affiliate-Programme, Partner-Reporting und die Analyse des Nutzerverhaltens.

Drittes Szenario: Secure Downloads mit Zugriffskontrolle. jumpurl kann Downloads an eine Benutzeranmeldung koppeln, sodass nur eingeloggte Nutzer Dateien herunterladen können. Das Token-System stellt sicher, dass direkte URLs zu geschützten Dateien nicht funktionieren. Für Unternehmen, die Whitepapers, technische Dokumentationen oder Preislisten nur nach Login bereitstellen wollen, war das in der TYPO3-v6- und v7-Ära die Standardlösung.

## Technische Architektur basiert auf URL-Rewriting und Datenbank-Logging

jumpurl registriert einen eID-Handler im TYPO3-Core, der eingehende Requests mit einem jumpurl-Parameter abfängt. Der Parameter enthält einen Hash, der auf die Ziel-URL oder den Dateipfad verweist. Der Handler loggt den Zugriff in eine Datenbanktabelle (tx_jumpurl_tracking), validiert den Hash und leitet den Browser per 302-Redirect an das eigentliche Ziel weiter.

Die Konfiguration erfolgt über TypoScript-Konstanten: Welche Dateitypen getrackt werden (typisch: PDF, DOCX, XLSX, ZIP), ob externe Links erfasst werden und ob das Tracking aktiviert ist. Die Extension modifiziert automatisch die generierten Links im Frontend, sodass Redakteure nichts manuell anpassen müssen. Die Integration ist transparent: Redakteure verlinken Dateien wie gewohnt, und jumpurl schiebt die Tracking-Ebene automatisch dazwischen.

Das Tracking-Log enthält: Zeitstempel, IP-Adresse (DSGVO-relevant), Ziel-URL, HTTP-Referrer und User-Agent. Für die Auswertung gibt es ein minimales Backend-Modul, das Klickzahlen pro URL anzeigt. Komplexere Analysen erfordern direkten Datenbankzugriff oder einen Export.

## Häufige Probleme betreffen SEO, DSGVO und Kompatibilität mit URL-Rewriting

Problem eins: SEO-Schaden durch Redirect-Ketten. jumpurl-URLs sind keine echten Seiten-URLs, sondern Redirect-Intermediäre. Wenn Google einen jumpurl-Link indexiert (was bei falscher Konfiguration passiert), entsteht eine Redirect-Kette, die Crawl-Budget verschwendet und Link-Juice verdünnt. Die Lösung: Sicherstellen, dass jumpurl-URLs ein noindex-Tag oder ein robots-Disallow haben.

Problem zwei: DSGVO-Konformität. jumpurl speichert IP-Adressen im Klartext. Ohne Pseudonymisierung oder Löschkonzept ist das ein Verstoss gegen die DSGVO. Die Datenbanktabelle muss regelmässig bereinigt oder die IP-Adressen vor dem Speichern anonymisiert werden.

Problem drei: Kompatibilität mit modernem URL-Routing. TYPO3 v12 nutzt Site-Handling und Symfony-basiertes Routing. Die eID-basierte jumpurl-Architektur kollidiert in manchen Konfigurationen mit dem neuen Routing und produziert 404-Fehler. Die Lösung ist die Migration auf eine moderne Alternative. Zusätzlich stören die kryptischen jumpurl-Parameter in der Browser-Adresszeile die User Experience: Nutzer sehen eine URL mit Hash-Werten statt eines lesbaren Dateipfads, was Misstrauen erzeugen kann.

## Migration auf eventbasiertes Tracking ist bei jedem TYPO3-Upgrade der empfohlene Weg

jumpurl hat keine offizielle Unterstützung für TYPO3 v12 oder v13. Bei einer Migration empfiehlt Gosign den Wechsel auf eventbasiertes Download-Tracking. Konkret bedeutet das: Ein data-Attribut auf Download-Links (z.B. data-track="download") und ein JavaScript-Event-Listener, der Klicks an Matomo, Google Analytics 4 oder ein Custom-Endpoint sendet. Für Secure Downloads ist die Kombination aus FAL-basiertem Dateizugriff und einem Token-System die moderne Alternative.

Der Migrationsaufwand hängt von der Menge der bestehenden jumpurl-Links ab. Wenn externe Quellen (Newsletter, Social Media, Print) auf jumpurl-URLs verweisen, müssen Redirects eingerichtet werden. Gosign analysiert die bestehenden jumpurl-Tracking-Daten, identifiziert die meistgenutzten Downloads und konfiguriert die neue Tracking-Lösung so, dass historische Vergleichbarkeit gewährleistet bleibt. Typischerweise sind 80% der bestehenden jumpurl-Links interne Verlinkungen, die automatisiert umgeschrieben werden können. Die verbleibenden 20% sind externe Referenzen, für die permanente 301-Redirects eingerichtet werden müssen, damit kein Link-Juice verloren geht.

--- k3n_dvemoji TYPO3 - Emoji & UTF-8mb4 | Gosign ---
> k3n_dvemoji: UTF-8mb4 Emoji-Support in TYPO3. Zeichensatz-Migration & Datenbank-Konfiguration. KI-beschleunigt.

## Emojis als Fragezeichen sind kein Darstellungsproblem, sondern ein Datenbank-Konfigurationsfehler

Wenn in einem TYPO3-Backend ein Redakteur ein Emoji eingibt und im Frontend stattdessen ein Fragezeichen oder ein leeres Kästchen erscheint, liegt das Problem nicht im Browser und nicht in TYPO3. Es liegt in der MySQL- oder MariaDB-Datenbank, die mit dem Zeichensatz utf8 statt utf8mb4 konfiguriert ist. Der Unterschied: utf8 speichert maximal 3 Bytes pro Zeichen, Emojis brauchen 4 Bytes. k3n_dvemoji ist eine TYPO3-Extension, die dieses Problem adressiert, indem sie die Datenbank-Konfiguration um UTF-8mb4-Support erweitert. Seit TYPO3 v10 ist der Core allerdings selbst auf utf8mb4 vorbereitet, sodass die Extension nur noch bei älteren oder falsch konfigurierten Installationen nötig ist.

Für TYPO3-Administratoren und Agenturen, die ältere Installationen betreuen, ist k3n_dvemoji ein Diagnosewerkzeug und ein Fix zugleich. Die Extension identifiziert Tabellen mit falschem Zeichensatz und konvertiert sie, was manuell ein fehleranfälliger Prozess ist.

## Typische Einsatzszenarien betreffen ältere Installationen, Migrationen und internationale Inhalte

Das häufigste Szenario ist eine TYPO3-v8- oder v9-Installation, die seit Jahren läuft und deren Datenbank noch auf utf8 (nicht utf8mb4) konfiguriert ist. Schätzungsweise 30% aller TYPO3-Installationen, die vor 2018 eingerichtet wurden, haben dieses Problem, weil die Installationsroutine damals utf8 als Standard setzte. Solange Redakteure nur lateinische Zeichen verwenden, fällt das nicht auf. Sobald ein Social-Media-Post mit Emoji auf der Website eingebettet wird oder ein Redakteur ein Emoji in eine Überschrift setzt, bricht die Darstellung. k3n_dvemoji konvertiert die betroffenen Tabellen und Spalten auf utf8mb4.

Zweites Szenario: Datenbank-Migrationen zwischen Servern. Beim Umzug einer TYPO3-Datenbank von einem alten Server auf einen neuen kann der Zeichensatz durch einen fehlerhaften mysqldump-Befehl verloren gehen. Ein Dump mit --default-character-set=utf8 statt utf8mb4 schneidet alle 4-Byte-Zeichen ab. k3n_dvemoji hilft bei der nachträglichen Reparatur.

Drittes Szenario: Internationale Websites mit asiatischen Sprachen. Chinesische, japanische und koreanische Schriftzeichen benötigen teilweise 4 Bytes. Ohne utf8mb4 werden einzelne Zeichen verstümmelt dargestellt, was bei CJK-Content-Seiten zu unlesbarem Text führt. Auch mathematische Symbole, Musiknoten und diverse Sonderzeichen aus dem Unicode-Bereich oberhalb von U+FFFF sind betroffen, was für Hochschul-Websites und wissenschaftliche Portale relevant ist.

## Technische Architektur analysiert und konvertiert Datenbank-Tabellen auf Spaltenebene

k3n_dvemoji arbeitet auf zwei Ebenen: Analyse und Konvertierung. Im Analyse-Modus scannt die Extension alle TYPO3-Tabellen und prüft den Zeichensatz jeder Spalte. Das Ergebnis ist ein Report, der zeigt, welche Tabellen und Spalten noch auf utf8 (3 Byte) statt utf8mb4 (4 Byte) stehen. Ein typisches TYPO3-System hat 100 bis 300 Tabellen, von denen oft 20 bis 50 einen falschen Zeichensatz aufweisen.

Im Konvertierungs-Modus generiert die Extension ALTER TABLE Statements für jede betroffene Spalte und führt sie aus. Das klingt trivial, hat aber Fallstricke: Indizes auf varchar-Spalten mit utf8mb4 können die maximale Index-Länge von MySQL überschreiten (767 Bytes bei InnoDB mit antique format). Die Extension prüft diese Limits und passt die Index-Definitionen an.

Zusätzlich muss die TYPO3-Konfiguration in LocalConfiguration.php den Zeichensatz utf8mb4 deklarieren: `['DB']['Connections']['Default']['charset'] = 'utf8mb4'` und `['DB']['Connections']['Default']['tableoptions']['collate'] = 'utf8mb4_unicode_ci'`. Ohne diese Konfiguration nutzt TYPO3 weiterhin utf8 für neue Tabellen.

## Häufige Probleme sind Index-Längenbeschränkungen, Backup-Fehler und inkonsistente Spalten

Problem eins: MySQL-Index-Längenbeschränkung. Bei InnoDB mit dem alten Compact-Format (Standard bis MySQL 5.6) ist die maximale Index-Länge 767 Bytes. Ein varchar(255) mit utf8mb4 braucht 1.020 Bytes Index-Platz. Die Konvertierung scheitert mit "Specified key was too long". Die Lösung: ROW_FORMAT auf DYNAMIC umstellen (Standard ab MySQL 5.7) oder die varchar-Länge in den betroffenen Spalten reduzieren.

Problem zwei: Backup vor der Konvertierung. Ein ALTER TABLE auf grossen Tabellen (100.000+ Zeilen) sperrt die Tabelle und kann bei Produktionsdatenbanken zu Ausfällen führen. Die Lösung: Konvertierung ausserhalb der Geschäftszeiten durchführen und vorher ein vollständiges Backup erstellen. Bei grossen Tabellen empfiehlt sich pt-online-schema-change von Percona für eine lockfreie Konvertierung.

Problem drei: Inkonsistente Spalten nach teilweiser Konvertierung. Wenn nur Teile der Datenbank konvertiert wurden, können JOINs zwischen utf8- und utf8mb4-Spalten zu Performance-Problemen führen, weil MySQL eine implizite Zeichensatz-Konvertierung durchführt. Gosign prüft nach jeder Konvertierung alle Tabellen auf Konsistenz.

## Ab TYPO3 v10 ist die Extension überflüssig, wenn die Datenbank korrekt konfiguriert ist

TYPO3 v10 und alle folgenden Versionen erwarten utf8mb4 als Standard-Zeichensatz. Bei einer Neuinstallation mit v10 oder höher wird die Datenbank automatisch korrekt konfiguriert, und k3n_dvemoji ist nicht nötig. Die Extension bleibt relevant für Installationen, die von v7, v8 oder v9 auf v12 oder v13 migriert werden und deren Datenbank noch nie konvertiert wurde. Gosign löst das im Rahmen jeder TYPO3-Migration automatisch mit: KI-gestützter Datenbank-Scan, vollständige Konvertierung und Konsistenz-Check als Teil des Standard-Upgrade-Prozesses. Der Scan analysiert alle Tabellen und Spalten in unter 5 Minuten, generiert die nötigen ALTER TABLE Statements und führt sie in einer Transaktion aus, sodass bei einem Fehler der vorherige Zustand wiederhergestellt werden kann. Das Ergebnis ist eine Datenbank, die utf8mb4 durchgängig unterstützt, ohne dass eine Extension im Betrieb nötig ist.

--- ke_search Premium TYPO3 - Suche | Gosign ---
> Premium-Version von ke_search: Autocomplete, Datei-Indexierung (PDF, DOCX), Custom Indexer. Enterprise-Suche ohne Solr-Server.

## Enterprise-Suche ohne Solr-Server ist mit ke_search Premium in TYPO3 möglich

Die interne Suche einer Website ist das Feature, das am meisten genutzt und am wenigsten gepflegt wird. Besucher erwarten Autocomplete, Tippfehler-Toleranz und die Fähigkeit, nicht nur Seiten, sondern auch PDFs und Office-Dokumente zu durchsuchen. ke_search Premium liefert genau das für TYPO3, ohne dass ein externer Solr- oder Elasticsearch-Server betrieben werden muss. Alle Daten liegen in der TYPO3-Datenbank, der Index wird über den Scheduler aktualisiert, und die Administration bleibt im TYPO3-Backend.

Für mittelgrosse Websites mit 500 bis 5.000 Seiten und einer Handvoll Datei-Downloads ist ke_search Premium die wirtschaftlichste Suchlösung im TYPO3-Ökosystem. Erst ab 10.000+ indexierten Dokumenten oder bei Sub-Sekunden-Anforderungen an die Antwortzeit wird Solr zur besseren Wahl.

## Typische Einsatzszenarien reichen von Unternehmenswebsites bis zu Wissensportalen

Das Standardszenario ist die Unternehmenswebsite mit Produktkatalog, Magazin, FAQ und Download-Bereich. Besucher suchen nach Produktnamen, Fachbegriffen oder Dokumenten und erwarten Ergebnisse aus allen Bereichen in einer einzigen Trefferliste. ke_search Premium indexiert Seiteninhalte, News-Artikel, Downloads (PDF, DOCX, XLSX) und Custom-Records wie Produkte oder Mitarbeiterprofile. Die Autocomplete-Funktion zeigt bereits beim Tippen Vorschläge an und reduziert die Suchabbruchrate um geschätzte 15 bis 25%.

Zweites Szenario: Wissensportale und Dokumentensammlungen. Hochschulen, Verbände und öffentliche Einrichtungen stellen oft hunderte PDFs zum Download bereit: Forschungsberichte, Satzungen, Formulare, Protokolle. Ohne Datei-Indexierung durchsucht die TYPO3-Suche nur die Seitentexte, nicht den Inhalt der PDFs. ke_search Premium extrahiert den Text aus PDF, DOCX und weiteren Formaten und macht ihn durchsuchbar.

Drittes Szenario: Custom Indexer für Drittsysteme. Unternehmen mit einem PIM, einem DAM oder einem externen Produktkatalog können über die Custom-Indexer-API beliebige Datenquellen in den Suchindex einbinden. Ein Indexer-Job holt Daten per API, transformiert sie in ke_search-Records und speichert sie im Index. Das ist besonders relevant für E-Commerce-Szenarien, in denen Produktdaten nicht in TYPO3 liegen.

## Technische Architektur nutzt die TYPO3-Datenbank als Suchindex

ke_search speichert den Index in einer dedizierten Tabelle (tx_kesearch_index) in der TYPO3-Datenbank. Jeder Index-Eintrag enthält Titel, Inhalt, Tags, Typ und Sortierungsinformationen. Die Indexierung läuft über Scheduler-Tasks, die in konfigurierbaren Intervallen (typisch: nächtlich) den Content neu indexieren. Die Premium-Version erweitert den Basis-Indexer um Datei-Indexierung, Autocomplete und Custom Indexer.

Die Datei-Indexierung nutzt Apache Tika oder pdftotext für die Text-Extraktion aus PDFs und catdoc für Office-Dokumente. Diese Tools müssen auf dem Server installiert sein, was auf Shared-Hosting-Umgebungen ein Problem sein kann. Auf dedizierten Servern und in Docker-Containern ist die Installation trivial.

Die Suchanfrage im Frontend arbeitet über eine LIKE-basierte Datenbanksuche mit optionalem Fulltext-Index. Bei kleineren Datenmengen ist die Performance ausreichend, bei grösseren Indexen (5.000+ Einträge) empfiehlt sich ein MySQL-Fulltext-Index auf den relevanten Spalten, um die Suchzeit unter 200ms zu halten.

Autocomplete wird über einen AJAX-Endpoint realisiert, der bei jedem Tastendruck eine PREFIX-Suche auf dem Index durchführt. Die Ergebnisse werden als JSON geliefert und im Frontend per JavaScript als Dropdown angezeigt. Die Konfiguration erlaubt, die Mindest-Zeichenanzahl (empfohlen: 3) und die maximale Anzahl der Vorschläge (empfohlen: 8) einzustellen.

## Häufige Probleme betreffen Indexierungszeit, fehlende Tika-Installation und Relevanz-Sortierung

Problem eins: Lange Indexierungszeiten bei grossen Datenmengen. Eine Website mit 3.000 Seiten und 500 PDFs kann 30 bis 60 Minuten für eine vollständige Neuindexierung benötigen. Die Lösung: Inkrementelle Indexierung aktivieren, die nur geänderte Inhalte neu indexiert. Bei ke_search Premium ist das über den Scheduler konfigurierbar.

Problem zwei: Fehlende Tika- oder pdftotext-Installation. Ohne diese Tools schlägt die Datei-Indexierung still fehl, ohne Fehlermeldung. Redakteure laden PDFs hoch, die nie im Suchindex landen. Die Lösung: Nach der Installation einen Test-Indexierungslauf starten und prüfen, ob PDF-Inhalte im Index erscheinen. Ein einfacher CLI-Befehl prüft die Verfügbarkeit: `which pdftotext` oder `java -jar tika-app.jar --version`.

Problem drei: Relevanz-Sortierung. Die Standard-Sortierung basiert auf einem einfachen Scoring-Algorithmus, der Treffer in Titeln höher gewichtet als Treffer im Body. Für komplexe Anforderungen (Boosting nach Aktualität, nach Seitentyp oder nach Custom-Feldern) muss das Scoring per TypoScript angepasst werden. Die Premium-Version bietet mehr Scoring-Parameter als die kostenlose Basisversion.

## TYPO3 v12 wird vollständig unterstützt, v13-Kompatibilität ist in Arbeit

ke_search wird von einem dedizierten Entwicklerteam gepflegt und ist bei jedem TYPO3-LTS-Release zeitnah kompatibel. Die aktuelle Premium-Version unterstützt TYPO3 v11 und v12. Für v13 ist die Kompatibilität in Entwicklung. Beim Upgrade von älteren TYPO3-Versionen betreffen Breaking Changes vor allem die TypoScript-Konfiguration der Indexer und die Scheduler-Task-Registrierung. Der Suchindex selbst muss nach einem Upgrade komplett neu aufgebaut werden, was je nach Datenmenge eine Stunde oder mehr dauern kann.

Gosign setzt ke_search Premium in TYPO3-Projekten ein, die eine interne Suche brauchen, aber den Betrieb eines Solr-Servers nicht rechtfertigen. Für die meisten mittelgrossen Websites mit unter 5.000 indexierten Dokumenten ist ke_search Premium die wirtschaftlich sinnvollste Lösung. Erst wenn Anforderungen wie Facettierung, Fuzzy-Matching oder Sub-Sekunden-Antwortzeiten bei grossen Datenmengen dazukommen, empfehlen wir den Umstieg auf Apache Solr mit der TYPO3-Solr-Extension.

--- Kleinanzeigen TYPO3 - Classifieds | Gosign ---
> Classifieds/Kleinanzeigen-Funktionalität für TYPO3: Anzeigen schalten, Kategorien, Suche, Nutzer-Self-Service. Community-Feature für Portale.

## Kleinanzeigen auf der eigenen Website sind eine Alternative zu Marktplatz-Plattformen

Vereine, regionale Portale und Community-Websites brauchen manchmal eine Kleinanzeigen-Funktion: Mitglieder stellen Gebrauchtwaren ein, Nachbarn bieten Dienstleistungen an, Organisationen vermitteln Sachspenden. Die kleinanzeigen-Extension bringt diese Funktionalität direkt in TYPO3, ohne auf externe Plattformen wie eBay Kleinanzeigen (jetzt Kleinanzeigen) auszuweichen. Nutzer erstellen Anzeigen im Frontend, andere Nutzer finden sie über Kategorien und Suche, und die Redaktion behält die Kontrolle über Freigabe und Moderation.

Der Anwendungsfall ist eng begrenzt: Wer eine vollwertige Marktplatz-Plattform mit Bezahlfunktion, Bewertungssystem und Käuferschutz braucht, ist mit einer spezialisierten Lösung besser bedient. Für Community-Portale mit 50 bis 500 aktiven Anzeigen gleichzeitig ist die Extension aber ein solides Werkzeug, das die Nutzer auf der eigenen Plattform hält.

## Typische Einsatzszenarien sind Vereinsportale, regionale Plattformen und interne Börsen

Das häufigste Szenario ist das Vereinsportal. Ein Sportverein, eine Kirchengemeinde oder eine Bürgerinitiative bietet Mitgliedern die Möglichkeit, Gebrauchtes zu verkaufen, zu verschenken oder zu tauschen. Die Kleinanzeigen-Funktion ist ein Community-Feature, das Besucher regelmässig auf die Website zurückbringt. Die Kategorien sind überschaubar: Sport-Ausrüstung, Kleidung, Möbel, Diverses.

Zweites Szenario: Regionale Plattformen und Stadtportale. Eine Gemeinde-Website oder ein lokales Nachrichtenportal bietet einen Kleinanzeigenbereich für die Region an. Bürger inserieren Mietwohnungen, Babysitter-Angebote oder Handwerkerleistungen. Die Moderation liegt bei der Redaktion, die Anzeigen vor der Veröffentlichung freigibt.

Drittes Szenario: Interne Börsen in Unternehmen oder Hochschulen. Im Intranet bieten Mitarbeitende Büromöbel, Fahrräder oder Wohnungen zur Zwischenmiete an. Die Kleinanzeigen-Extension läuft auf der internen TYPO3-Instanz und ist nur für angemeldete Nutzer sichtbar. Hochschulen nutzen das Feature auch für Bücherbörsen, in denen Studierende Fachliteratur untereinander verkaufen oder tauschen.

## Technische Architektur setzt auf Extbase-Records mit Frontend-Eingabe

Die Extension nutzt das Extbase/Fluid-Framework von TYPO3. Anzeigen werden als eigene Domain-Records in einer dedizierten Tabelle gespeichert. Jeder Record enthält Titel, Beschreibung, Preis (optional), Kategorie, Kontaktdaten und Bilder. Die Kategorisierung läuft über TYPO3-Sys-Categories oder ein eigenes Kategoriefeld.

Im Frontend stehen drei Plugins zur Verfügung: eine Listenansicht mit Filter und Suche, eine Detailansicht für einzelne Anzeigen und ein Eingabeformular für neue Anzeigen. Das Eingabeformular erfordert eine Frontend-Benutzeranmeldung (fe_users), sodass nur registrierte Nutzer Anzeigen erstellen können. Bilder werden über FAL (File Abstraction Layer) hochgeladen und serverseitig auf Grösse und Dateityp validiert.

Die Moderation erfolgt über ein Freigabe-Flag im Backend: Neue Anzeigen sind standardmässig unsichtbar, bis ein Redakteur sie freischaltet. Alternativ lässt sich die automatische Freigabe aktivieren, was für vertrauenswürdige Communities sinnvoll sein kann.

Die Suche arbeitet über eine einfache LIKE-basierte Datenbankabfrage auf Titel und Beschreibung. Für Portale mit mehr als 500 aktiven Anzeigen empfiehlt sich eine Erweiterung um ke_search oder einen eigenen Suchindex, um die Suchperformance und Relevanz zu verbessern. Die Sortierung ist nach Datum (neueste zuerst) und nach Preis (aufsteigend oder absteigend) konfigurierbar.

## Häufige Probleme sind Spam, Bildoptimierung und Ablauf-Management

Problem eins: Spam-Anzeigen. Jedes öffentliche Eingabeformular zieht Spam an. Ohne Schutzmechanismen füllt sich der Anzeigenbestand innerhalb von Wochen mit irrelevanten Einträgen. Die Lösung: Frontend-Login-Pflicht, Honeypot-Felder im Formular, optionales CAPTCHA und eine Freigabe-Moderation. Die Kombination reduziert Spam auf nahe Null.

Problem zwei: Bildoptimierung. Nutzer laden Fotos direkt vom Smartphone hoch, oft mit 4 bis 8 MB pro Bild. Ohne serverseitige Komprimierung und Grössenanpassung wird die Seite langsam und der Speicherplatz knapp. Die Lösung: In der Extension-Konfiguration eine maximale Bildgrösse definieren (empfohlen: 1.200px Breite, 80% JPEG-Qualität) und den Upload per PHP-Konfiguration auf 5 MB begrenzen.

Problem drei: Ablauf-Management. Veraltete Anzeigen, die seit Monaten online stehen, machen den Anzeigenbestand unbrauchbar. Die Lösung: Ein automatisches Ablaufdatum (empfohlen: 30 bis 90 Tage) und eine Erinnerungsmail an den Ersteller, bevor die Anzeige archiviert wird. Das erfordert eine Scheduler-Task-Konfiguration.

Ein weiteres Thema, das regelmässig auftaucht: Kontaktaufnahme zwischen Inserent und Interessent. Die einfachste Lösung zeigt die E-Mail-Adresse des Inserenten auf der Detailseite an. Das funktioniert, aber die E-Mail-Adresse ist dann für Spam-Crawler sichtbar. Die bessere Lösung ist ein Kontaktformular auf der Detailseite, das die Nachricht an den Inserenten weiterleitet, ohne seine E-Mail-Adresse offenzulegen.

## Die Extension hat keine gesicherte Unterstützung für aktuelle TYPO3-Versionen

kleinanzeigen wurde für ältere TYPO3-Versionen entwickelt und hat keine offizielle Unterstützung für v12 oder v13. Bei einer Migration stellt sich die Frage, ob die Extension angepasst oder durch eine massgeschneiderte Lösung ersetzt wird. Für Portale mit aktivem Kleinanzeigenbestand empfiehlt Gosign eine Neuentwicklung auf Basis der aktuellen Extbase-API, die die bestehenden Daten migriert und die Funktionalität an die spezifischen Anforderungen des Portals anpasst. Der Aufwand liegt typischerweise bei 5 bis 10 Arbeitstagen für eine Grundfunktionalität mit Listenansicht, Detailansicht, Frontend-Eingabe und Moderation.

Der Vorteil einer Neuentwicklung gegenüber dem Patchen der alten Extension: Die Datenbank-Struktur kann auf die tatsächlichen Anforderungen optimiert werden, die Frontend-Templates nutzen aktuelle Fluid-Features und das Responsive-Verhalten wird von Anfang an mitgedacht. Gosign migriert bestehende Anzeigen-Daten automatisiert in die neue Struktur, sodass kein aktiver Inhalt verloren geht.

--- Mailchimp Signup TYPO3 | Gosign ---
> Mailchimp-Anmeldeformular für TYPO3. Subscriber-Sync, Double-Opt-In, Audience-Segmente. DSGVO: US-Datenverarbeitung beachten,.

## Mailchimp-Anmeldeformulare in TYPO3 erfordern DSGVO-Absicherung, nicht nur ein Plugin

Newsletter-Anmeldungen gehören zu den wichtigsten Conversion-Zielen auf Unternehmenswebsites. koning_mailchimp_signup verbindet TYPO3-Frontend-Formulare direkt mit der Mailchimp-API: Ein Besucher gibt seine E-Mail-Adresse ein, die Extension überträgt sie an die konfigurierte Mailchimp-Audience, Mailchimp verschickt die Double-Opt-In-Mail. Technisch funktioniert das in 15 Minuten. Die eigentliche Herausforderung liegt nicht in der Technik, sondern in der DSGVO: Mailchimp verarbeitet personenbezogene Daten auf US-Servern, was einen Auftragsverarbeitungsvertrag (AVV) und einen dokumentierten Transfer-Mechanismus (aktuell: EU-US Data Privacy Framework) voraussetzt.

Für Marketing-Teams, die Mailchimp bereits als Newsletter-Plattform nutzen und ihren TYPO3-Webauftritt anbinden wollen, ist die Extension der kürzeste Weg. Wer noch keine Plattform gewählt hat, sollte allerdings europäische Alternativen wie Brevo, rapidmail oder mailingwork evaluieren.

## Typische Einsatzszenarien sind Blog-Newsletter, Lead-Magneten und Event-Registrierungen

Das Standardszenario ist der Blog- oder Magazin-Newsletter. Unter jedem Artikel erscheint ein kompaktes Anmeldeformular mit E-Mail-Feld und Einwilligungs-Checkbox. Die Extension überträgt die Adresse an eine Mailchimp-Audience und tagged den Subscriber mit der Quelle (z.B. "blog-sidebar" oder "article-footer"). Marketing kann so segmentspezifisch versenden.

Zweites Szenario: Lead-Magneten mit automatischem Download. Ein Besucher meldet sich an und erhält automatisch ein Whitepaper, eine Checkliste oder einen Rabattcode per Mailchimp-Welcome-Automation. Die Extension liefert den Subscriber, Mailchimp übernimmt die Automation. Die Conversion-Rate dieses Musters liegt bei B2B-Websites erfahrungsgemäss bei 2 bis 5% der Seitenbesucher.

Drittes Szenario: Event-Registrierungen. Ein Unternehmen lädt zu einem Webinar oder einer Konferenz ein. Die Anmeldung läuft über ein erweitertes Formular mit Name, E-Mail und Firmenname. Die Extension überträgt die Daten an eine dedizierte Mailchimp-Audience, die für Event-Kommunikation (Einladung, Reminder, Follow-up) konfiguriert ist. Nach dem Event kann die Audience für Follow-up-Kampagnen weiterverwendet werden, was den Customer Lifetime Value der Registrierung maximiert.

## Technische Architektur verbindet ein Fluid-Formular mit der Mailchimp-API v3

Die Extension registriert ein Content-Element in TYPO3, das ein Anmeldeformular rendert. Das Formular enthält mindestens ein E-Mail-Feld und eine Einwilligungs-Checkbox. Optionale Felder wie Vorname, Nachname und Firma können über die Backend-Konfiguration aktiviert werden. Die Fluid-Templates sind über ein Site-Package überschreibbar.

Nach dem Absenden sendet die Extension einen POST-Request an die Mailchimp-API v3. Der API-Key und die Audience-ID werden im TYPO3-Extension-Manager konfiguriert. Die Extension unterstützt Tags (zur Segmentierung), Merge Fields (für Custom-Daten) und die Steuerung des Double-Opt-In-Verhaltens (aktiviert oder deaktiviert, wobei die DSGVO in Europa Double-Opt-In verlangt).

Fehler-Handling: Wenn die Mailchimp-API einen Fehler zurückgibt (bereits abonniert, ungültige E-Mail, Rate Limit), zeigt die Extension eine konfigurierbare Fehlermeldung im Frontend an. Die Fehler werden zusätzlich ins TYPO3-Log geschrieben, was für die Analyse von Sync-Problemen relevant ist. Die häufigste Fehlermeldung im Produktivbetrieb ist "Member Exists" (Subscriber ist bereits in der Audience), was kein technischer Fehler ist, sondern eine Informationsmeldung, die dem Besucher als "Sie sind bereits angemeldet" angezeigt werden sollte.

## Häufige Probleme betreffen DSGVO-Dokumentation, Double-Opt-In und Formularstyling

Problem eins: Fehlende DSGVO-Dokumentation. Die Extension überträgt personenbezogene Daten an einen US-Dienstleister. Ohne Auftragsverarbeitungsvertrag mit Mailchimp (Intuit), Dokumentation des Transfer-Mechanismus in der Datenschutzerklärung und Einwilligungs-Checkbox im Formular ist die Integration rechtswidrig. Die Lösung: AVV mit Mailchimp abschliessen (verfügbar im Mailchimp-Account unter Account > Legal), Transfer-Mechanismus in der Datenschutzerklärung benennen und die Einwilligungs-Checkbox als Pflichtfeld konfigurieren.

Problem zwei: Double-Opt-In-Konfiguration. Mailchimp erlaubt es, Subscriber ohne Bestätigungs-Mail direkt in die Liste aufzunehmen (Single-Opt-In). In Deutschland ist das nach der Rechtsprechung des BGH problematisch. Die Extension muss so konfiguriert sein, dass Mailchimp eine Bestätigungs-Mail verschickt und den Subscriber erst nach Klick auf den Bestätigungslink aktiviert.

Problem drei: Formular-Styling passt nicht zum Corporate Design. Die Extension bringt minimale Standard-Styles mit, die in den wenigsten Projekten zum Design passen. Die Lösung: Das Fluid-Template im Site-Package überschreiben und die CSS-Klassen an das bestehende Design-System anpassen. Der Aufwand liegt bei 1 bis 2 Stunden.

Ein viertes Problem, das speziell bei Multi-Language-Websites auftaucht: Die Einwilligungstexte und Fehlermeldungen der Extension sind nicht für alle Sprachen vorkonfiguriert. Für TYPO3-Projekte mit 5 Sprachversionen müssen die Labels manuell in den XLF-Dateien oder über TypoScript-Overrides übersetzt werden, was bei 10 bis 15 Textbausteinen pro Sprache ein überschaubarer, aber nicht vernachlässigbarer Aufwand ist.

## Die Extension funktioniert mit TYPO3 v12, für v13 ist die Mailchimp-API der stabilere Weg

koning_mailchimp_signup unterstützt TYPO3 v11 und v12. Für TYPO3 v13 hängt die Verfügbarkeit vom Community-Maintainer ab. Da die Mailchimp-API v3 stabil ist und sich selten ändert, ist eine direkte API-Integration ohne Extension die wartungsärmere Alternative für v13-Projekte. Gosign implementiert in neuen Projekten bevorzugt einen Custom Finisher für das TYPO3 Form Framework oder für powermail, der die Mailchimp-API direkt anspricht. Das eliminiert die Abhängigkeit von der Extension und gibt volle Kontrolle über Fehler-Handling, Logging und DSGVO-Dokumentation.

Der Custom-Finisher-Ansatz hat einen weiteren Vorteil: Er lässt sich mit wenig Aufwand auf andere Newsletter-Plattformen umstellen. Wenn ein Unternehmen von Mailchimp auf Brevo, rapidmail oder mailingwork wechselt, muss nur der API-Client im Finisher ausgetauscht werden, nicht das gesamte Formular-Setup. Diese Flexibilität rechtfertigt den initialen Mehraufwand von 2 bis 4 Stunden gegenüber der Extension-Installation.

--- kuferweb TYPO3 - Kursverwaltung Kufer | Gosign ---
> kuferweb: Kufer-Kursverwaltung in TYPO3 integrieren. Kurskatalog, Anmeldung, Synchronisation. KI-beschleunigt.

## kuferweb ist die Brücke zwischen dem Kufer-Fachverfahren und der öffentlichen TYPO3-Website

Volkshochschulen, Bildungsträger und Akademien verwalten ihren Kursbetrieb seit Jahrzehnten in Fachsoftware, und in vielen Häusern heisst diese Software Kufer. Kufer bildet den vollständigen Kurs-Lebenszyklus ab: Dozentenverwaltung, Kursplanung, Raumbelegung, Teilnehmer, Abrechnung, Zertifikate. Für die Website bedeutet das eine Standardaufgabe: Der Kurskatalog, der im Backoffice gepflegt wird, soll auf der TYPO3-Website tagesaktuell sichtbar sein, inklusive Filtersuche, Detailansichten und Online-Anmeldung.

Die Zielgruppe ist klar umrissen: Weiterbildungseinrichtungen mit einem bestehenden Kufer-Mandanten, die ihre Website auf TYPO3 betreiben. Typisch ist eine Volkshochschule mit rund 2.500 Kursen pro Semester und einem halben Dutzend Dozenten, die ihre Kurse selbst in Kufer pflegen. Ohne eine saubere Integration bleibt der Website-Katalog veraltet, Doppelpflege wird zum Dauerzustand, und Anmeldungen landen in einem separaten System, das niemand mag.

## Typische Einsatzszenarien

Ein erstes Szenario ist der automatisch aktualisierte Kurskatalog. Eine Volkshochschule mit 2.500 Kursen pro Semester möchte, dass jede Kursanlage, jede Preisänderung und jede Dozentenänderung ohne manuellen Eingriff auf der Website sichtbar wird. Ein stündlicher Sync-Job holt die aktuellen Kursdaten aus Kufer, schreibt sie in eine TYPO3-Tabelle und aktualisiert die Suche. Der Redakteur pflegt keine Kurse mehr im TYPO3-Backend.

Ein zweites Szenario ist die direkte Online-Anmeldung. Ein Bildungsträger mit Förderprogrammen möchte Interessenten direkt von der Kursdetailseite in einen Anmeldeprozess führen, der im Hintergrund die Kufer-API aufruft und den Teilnehmer in Kufer registriert. TYPO3 dient als Frontend, Kufer bleibt die Quelle der Wahrheit, die Redaktion sieht den neuen Anmeldestatus in ihrer gewohnten Oberfläche.

Ein drittes Szenario ist die Filtersuche mit fachspezifischen Facetten. Eine Akademie mit 40 Fachbereichen und mehreren Tausend Kursen möchte Interessenten die Suche über Kategorien, Orte, Termine, Dozenten und Preisklassen erlauben. Die Suche läuft auf der TYPO3-Seite gegen einen lokalen Index, der aus dem Kufer-Export aufgebaut wird - performant und unabhängig von der Verfügbarkeit der Fachanwendung.

Ein viertes Szenario ist die mehrsprachige Kursausgabe. Eine Sprachschule mit Standorten in Deutschland, Österreich und der Schweiz pflegt Kurse in Kufer nur in deutscher Sprache und möchte auf der Website eine mehrsprachige Darstellung für Interessenten anbieten. Die Integration übernimmt das Mapping auf TYPO3-Sprachvarianten, ergänzt die deutschen Kufer-Felder um manuelle Übersetzungen in der CMS-Redaktion und stellt sicher, dass Änderungen in Kufer nicht die lokalen Übersetzungen überschreiben.

## Technische Architektur

kuferweb-Integrationen in TYPO3 sind fast immer Custom-Entwicklungen, weil die Datenstrukturen pro Kufer-Mandant variieren und die API-Versionen sich über die Jahre mehrfach geändert haben. Der Standard-Ansatz ist eine schlanke Extbase-Extension mit drei Säulen: Ein Service-Layer, der die Kufer-API kapselt, ein Persistenz-Layer, der Kurse in TYPO3-Tabellen spiegelt, und ein Präsentations-Layer, der Fluid-Templates für Liste, Filter und Detail bereitstellt.

Die Synchronisation läuft über einen TYPO3-Scheduler-Task. Für grosse Kataloge empfiehlt sich ein Delta-Import, der nur die seit dem letzten Lauf geänderten Kurse überträgt. Die Kufer-API liefert meist einen Timestamp oder eine Änderungskennung pro Kurs, die für die Delta-Erkennung genutzt wird.

Die Online-Anmeldung erfordert einen zusätzlichen API-Pfad und eine saubere Fehlerbehandlung. Die Kufer-API kann bei hoher Last langsam antworten, daher laufen Anmeldungen typischerweise asynchron: Das Formular legt den Anmelde-Request in einer Queue ab, ein Worker-Prozess überträgt ihn an Kufer, und der Teilnehmer erhält eine Bestätigungs-Mail, sobald Kufer die Registrierung quittiert hat.

## Häufige Probleme und Lösungen

Das erste Problem ist die Feldabweichung zwischen Kufer-Mandanten. Was in Mandant A "Veranstaltungsnummer" heisst, ist in Mandant B "Kurscode" und in Mandant C "Belegnummer". Die Lösung ist ein konfigurierbares Feld-Mapping in der TYPO3-Extension, das pro Installation angepasst wird und nicht hart im Code steht.

Das zweite Problem ist die Datenqualität im Kurskatalog. Redakteurinnen pflegen in Kufer nicht immer vollständige Texte - Kurzbeschreibungen fehlen, Bilder sind nicht hinterlegt, Zielgruppen nicht definiert. Auf der Website erscheinen diese Lücken dann als leere Felder. Die Lösung ist ein Validierungs-Layer bei der Synchronisation, der unvollständige Kurse im Backend markiert und die Redaktion zum Nachpflegen auffordert.

Das dritte Problem ist die Stornierungs- und Absagelogik. Wenn Kurse in Kufer abgesagt werden, sollen sie auf der Website verschwinden oder mindestens als abgesagt markiert werden. Die Lösung ist, abgesagte Kurse im Sync explizit auf einen Status zu setzen, der in der Liste ausgeblendet wird, und die Detailseite mit einem Redirect auf eine Kategorie-Übersicht zu versehen.

Ein viertes Problem ist die Belegungsanzeige in Echtzeit. Interessenten sehen auf der Website "noch 3 Plätze frei", obwohl die Buchung im Hintergrund bereits auf die Warteliste gewechselt ist. Die Lösung ist, die Belegungsanzeige nicht aus dem Sync-Cache zu lesen, sondern bei jedem Aufruf der Detailseite einen kleinen Live-Call an Kufer abzusetzen - mit aggressivem Caching (30-60 Sekunden) und einem Fallback auf den letzten bekannten Cache-Wert, falls die API nicht antwortet.

## Migration und Versions-Kompatibilität

kuferweb-Integrationen laufen in TYPO3 v11, v12 und v13, solange die API-Anbindung modern gebaut ist. Der häufigste Schmerzpunkt ist nicht die TYPO3-Version, sondern die Kufer-Version: Wenn die Volkshochschule ihren Kufer-Mandanten auf eine neue Version migriert, ändern sich gelegentlich API-Endpoints und Datenstrukturen, was eine Nachjustierung der TYPO3-Integration nötig macht.

Gosign baut kuferweb-Integrationen auf Basis der aktuellen Kufer-API, prüft vor Projektbeginn die Kompatibilität mit dem Kunden-Mandanten und setzt die Integration so modular auf, dass künftige API-Upgrades ohne grossflächigen Umbau funktionieren. KI-gestützt entsteht der API-Client-Code in Stunden statt Tagen, wodurch die Einführung auf den meisten Projekten in zwei bis drei Sprints realistisch wird.

--- LayerSlider TYPO3 - Slider-Migration | Gosign ---
> Premium-Slider/Animations-Plugin für TYPO3. Performance-kritisch: Große JS-Bundles, viele HTTP-Requests. Gosign migriert auf leichtgewichtige.

## LayerSlider lädt 400 KB JavaScript für etwas, das mit 20 KB CSS lösbar ist

LayerSlider war zwischen 2012 und 2018 einer der beliebtesten Premium-Slider für TYPO3 und WordPress. Animierte Banner mit Parallax-Effekten, Texteinblendungen, Übergängen und Video-Hintergründen. Das Ergebnis sah auf der Startseite beeindruckend aus. Das Problem: LayerSlider lädt eine JavaScript-Library von 300 bis 400 KB (minifiziert), benötigt jQuery als Abhängigkeit (weitere 90 KB) und erzeugt 15 bis 30 HTTP-Requests für Bilder, Fonts und Konfigurationsdateien. Auf einer ansonsten optimierten Website verdoppelt LayerSlider die Ladezeit der Startseite.

Google PageSpeed Insights bestraft das gnadenlos. Ein Largest Contentful Paint (LCP) von über 4 Sekunden durch den Slider allein bedeutet einen Score-Verlust von 20 bis 40 Punkten. Seit Google die Core Web Vitals als Ranking-Faktor nutzt (2021), ist ein schlechter LCP ein messbarer SEO-Nachteil.

## Typische Einsatzszenarien

**Bestandswebsites mit animierten Hero-Bannern.** Unternehmenswebsites aus den Jahren 2014 bis 2019, bei denen der Startseiten-Slider 3 bis 5 animierte Folien zeigt. Typischer Inhalt: Produktfotos mit animiertem Text-Overlay ("Jetzt entdecken"), Parallax-Scrolleffekte, Autoplay mit Fade-Transition. Der Slider wurde einmal eingerichtet und seitdem kaum geändert, verursacht aber bei jedem Seitenaufruf den vollen Performance-Overhead.

**Landingpages mit Produkt-Slideshows.** Marketing-Teams nutzen LayerSlider für Produkt-Präsentationen: Mehrere Bilder mit Overlay-Text und CTA-Buttons in einer automatisch durchlaufenden Slideshow. Die Conversion-Daten zeigen typischerweise, dass 80 % der Nutzer nur die erste Folie sehen. Der Slider ist also eine teure Darstellung für ein einziges Bild.

**Event-Seiten mit Countdown-Animationen.** LayerSlider kann Timer, Pop-ups und Scroll-getriggerte Animationen darstellen. Für Konferenzseiten oder Produktlaunches wurden solche Features genutzt. Heute gibt es dafür leichtgewichtige CSS-Lösungen ohne JavaScript-Overhead.

## Technische Architektur

LayerSlider ist ein kommerzielles Plugin (Lizenz ca. 25 USD einmalig für WordPress, TYPO3-Variante über CodeCanyon oder Drittanbieter). Die TYPO3-Integration läuft als Extension, die eine eigene Tabelle für Slider-Konfigurationen anlegt. Jeder Slider besteht aus Slides, jede Slide aus Layern (Text, Bild, Video, Shape, Button), und jeder Layer hat Animationseinstellungen (Timing, Easing, Effekt).

Die Frontend-Ausgabe lädt die LayerSlider-Kernbibliothek (kreaturamedia.js), jQuery (falls nicht global vorhanden), optionale Plugins (Parallax, Popup, Timeline) und die Slider-Konfiguration als JSON. Die Bilder werden als img-Tags mit data-Attributen für Lazy Loading eingebunden, aber viele Konfigurationen laden alle Bilder sofort (Autoplay startet den zweiten Slide nach 3 Sekunden, also muss Slide 2 schon geladen sein).

Die Animationsengine nutzt RequestAnimationFrame und CSS3-Transforms für die Darstellung. Auf modernen Browsern ist die Darstellung flüssig, aber die Parse-Zeit für das grosse JavaScript-Bundle bleibt. Auf Mobilgeräten (Mid-Range-Smartphones) dauert das Parsen allein 200 bis 500 ms, bevor die erste Animation startet.

## Häufige Probleme und Lösungen

**Core Web Vitals fallen nach Slider-Einbau.** LCP steigt von 1,5 auf 4+ Sekunden, weil der Slider das grösste sichtbare Element ist und erst nach dem JavaScript-Parse rendern kann. Lösung: LayerSlider durch einen statischen Hero mit CSS-Animation ersetzen. Das Hero-Bild lädt als normales img-Tag (sofort im HTML, kein JavaScript nötig), Text-Overlays werden per CSS positioniert. Ergebnis: LCP unter 2 Sekunden.

**LayerSlider-Lizenz läuft aus, Updates fehlen.** Die TYPO3-Variante von LayerSlider wird nicht über das TER verteilt und hat keinen automatischen Update-Mechanismus. Sicherheits-Patches müssen manuell eingespielt werden. LayerSlider hatte in der Vergangenheit kritische Sicherheitslücken (CVE-2014-0159 in der WordPress-Version). Lösung: Nicht patchen, sondern migrieren.

**Slider-Inhalte sind nicht indexierbar.** Text in LayerSlider-Layern wird als data-Attribut oder per JavaScript eingefügt. Google kann den Text lesen (JavaScript-Rendering), aber die Zuordnung zum Seitenkontext ist schwach. Bild-Alternativtexte fehlen oft komplett. Lösung: Den relevanten Text und die CTAs direkt im HTML der Seite platzieren, nicht im Slider.

## Migration und Versions-Kompatibilität

LayerSlider hat keine offizielle TYPO3 v12 oder v13-Kompatibilität. Die letzte TYPO3-kompatible Version unterstützt v10, mit Community-Patches teilweise v11. Für v12+ gibt es keinen Upgrade-Pfad. Das ist für viele Projekte der Auslöser, den Slider endgültig abzulösen.

Gosign migriert LayerSlider auf eine von drei Alternativen, je nach Anforderung. Swiper (Open Source, 40 KB minifiziert, kein jQuery, Touch-native) für Bild-Slider mit einfachen Übergängen. Splide (Open Source, 30 KB minifiziert, kein jQuery, volle ARIA-Unterstützung) für barrierefreie Slider. Oder ein reiner CSS/HTML-Hero ohne Slider-Library, wenn ohnehin nur ein Bild mit Text-Overlay gebraucht wird.

Die Migration dauert je nach Slider-Komplexität 0,5 bis 2 Tage pro Slider. Bei einer typischen Website mit 1 Startseiten-Slider und 3 Unterseiten-Slidern ist das Projekt in einer Woche abgeschlossen, inklusive responsiver Anpassung und Performance-Test.

Der messbare Effekt einer Slider-Migration: Eine Website, die von LayerSlider auf einen statischen Hero mit CSS-Animation umgestellt wird, verbessert ihren Google PageSpeed Score typischerweise um 15 bis 35 Punkte. Der LCP fällt von 3 bis 5 Sekunden auf unter 2 Sekunden. Der Total Blocking Time (TBT) sinkt um 200 bis 500 ms, weil das grosse JavaScript-Bundle entfällt. Für Unternehmen, die über Google Ads Traffic auf die Startseite leiten, bedeutet das direkt bessere Quality Scores und niedrigere Klickpreise.

Gosign führt vor jeder Slider-Migration einen Performance-Benchmark durch: PageSpeed Score, LCP, CLS und TBT werden vorher und nachher gemessen. Die Ergebnisse dokumentieren den ROI der Migration und helfen bei der Argumentation gegenüber Stakeholdern, die am gewohnten Slider-Design festhalten wollen.

--- Leaflet TYPO3 - OpenStreetMap Karten | Gosign ---
> Leaflet Maps in TYPO3: OpenStreetMap ohne Google-Kosten. Filialfinder, Clustering, Routing. KI-beschleunigt.

## OpenStreetMap-Karten über Leaflet ersetzen Google Maps ohne Lizenzkosten und DSGVO-Risiko

Google Maps kostet ab 28.000 Kartenaufrufen pro Monat Geld und überträgt Nutzerdaten an US-Server. Für Unternehmen mit Filialfinder, Store Locator oder Standortkarte auf der Website sind das zwei Probleme auf einmal: Budget und Datenschutz. Leaflet löst beides. Die Open-Source JavaScript-Bibliothek rendert interaktive Karten auf Basis von OpenStreetMap-Daten, läuft komplett clientseitig und hat keine Lizenzkosten. Die TYPO3-Extension integriert Leaflet als Content-Element: Redakteure pflegen Standorte im Backend, die Extension generiert die Karte im Frontend.

Für Unternehmen mit 5 bis 500 Standorten ist Leaflet die Standardempfehlung. Erst wenn Google-spezifische Features wie Street View, 3D-Gebäude oder Live-Verkehrsdaten benötigt werden, ist Google Maps die bessere Wahl. In allen anderen Fällen liefert Leaflet die gleiche Funktionalität bei null Lizenzkosten und ohne Datenschutz-Diskussion.

## Typische Einsatzszenarien sind Filialfinder, Immobilienkarten und Event-Standorte

Das häufigste Szenario ist der Filial- oder Standortfinder. Ein Unternehmen mit 20 bis 200 Filialen zeigt alle Standorte auf einer interaktiven Karte. Nutzer können zoomen, nach Postleitzahl suchen und auf Marker klicken, um Adresse, Öffnungszeiten und Kontaktdaten zu sehen. Bei dichter Marker-Verteilung gruppiert Clustering nahegelegene Standorte zu einem Sammel-Marker, der beim Zoomen in Einzelmarker aufgelöst wird. Ein typischer Filialfinder mit 100 Standorten und Clustering lädt in unter 500ms.

Zweites Szenario: Immobilien- und Objektkarten. Makler, Hausverwaltungen und Wohnungsbaugesellschaften zeigen verfügbare Objekte auf einer Karte an. Die Marker enthalten Basisinformationen (Preis, Zimmeranzahl, Wohnfläche) als Popup und verlinken auf die Detailseite. Die TYPO3-Extension kann Objekt-Datensätze aus einer Extbase-Tabelle als Marker rendern.

Drittes Szenario: Event-Standorte und Tourismus. Veranstalter, Tourismusverbände und Städte zeigen POIs (Points of Interest), Routen und Veranstaltungsorte auf einer Karte. Leaflet unterstützt neben Punkt-Markern auch Linien (für Wanderrouten) und Polygone (für Gebiete), was es zum flexiblen Werkzeug für touristische Anwendungen macht.

## Technische Architektur trennt Daten-Backend und Karten-Rendering sauber

Die TYPO3-Extension speichert Standort-Daten als Extbase-Records in einer eigenen Tabelle. Jeder Record enthält Name, Adresse, Koordinaten (Latitude/Longitude), Beschreibung und optionale Felder wie Öffnungszeiten, Telefonnummer und Bild. Die Koordinaten können manuell eingegeben oder über einen Geocoding-Service automatisch aus der Adresse ermittelt werden.

Im Frontend rendert die Extension ein Karten-Container-Element und initialisiert Leaflet per JavaScript. Die Karten-Tiles werden von einem konfigurierbaren Tile-Server geladen. Der Standard ist OpenStreetMap, aber auch Mapbox, Stamen und andere Tile-Provider sind per TypoScript umschaltbar. Die Marker werden als JSON-Array in das JavaScript übergeben, was auch bei 500+ Standorten performant bleibt.

Clustering wird über das Leaflet.markercluster-Plugin realisiert, das Marker auf niedrigen Zoomstufen zusammenfasst und beim Hineinzoomen auflöst. Die Cluster-Schwellwerte sind konfigurierbar. Für die Suche nach Postleitzahl oder Ort wird clientseitig gefiltert, was bei bis zu 1.000 Markern ohne serverseitige Unterstützung funktioniert.

Die Karten-Styles sind vollständig anpassbar: Farben, Schriftarten, Strassenbreiten und Kartendetails lassen sich über Tile-Layer-Konfiguration und Custom-CSS steuern. Im Vergleich zu Google Maps, dessen Styling eingeschränkt ist, bietet Leaflet volle Kontrolle über das Erscheinungsbild.

## Häufige Probleme betreffen Geocoding, Tile-Server-Verfügbarkeit und responsive Darstellung

Problem eins: Geocoding-Fehler bei ungenauen Adressen. Nicht jede Adresse wird vom Geocoding-Service korrekt aufgelöst. Besonders Gewerbegebiete, Neubaugebiete und Adressen in ländlichen Regionen liefern ungenaue oder falsche Koordinaten. Die Lösung: Automatisches Geocoding als Erstbefüllung nutzen und die Koordinaten manuell prüfen. Die Extension sollte ein Kartenfenster im Backend anzeigen, über das der Redakteur den Marker per Drag-and-Drop korrigieren kann.

Problem zwei: Tile-Server-Verfügbarkeit. Der Standard-Tile-Server von OpenStreetMap hat eine Fair-Use-Policy und kann bei hohem Traffic Rate-Limiting anwenden. Für produktive Websites mit mehr als 50.000 Kartenabrufen pro Monat empfiehlt sich ein eigener Tile-Server oder ein kommerzieller Provider wie Mapbox oder Maptiler. Die Kosten liegen bei 5 bis 50 Euro pro Monat, immer noch deutlich unter Google Maps.

Problem drei: Responsive Darstellung auf Mobilgeräten. Karten auf kleinen Bildschirmen sind schwer zu bedienen, weil das Zoomen mit dem Swipen der Seite kollidiert. Die Lösung: Touch-Gesten auf der Karte mit zwei Fingern einschränken (scrollWheelZoom und dragging auf Mobilgeräten deaktivieren) und einen "Karte vergrössern"-Button anbieten, der die Karte im Vollbildmodus öffnet.

## Leaflet ist zukunftssicher, die TYPO3-Extension muss bei v13 geprüft werden

Leaflet als JavaScript-Bibliothek ist vom TYPO3-Versionsstand unabhängig und wird aktiv weiterentwickelt. Die TYPO3-Extension, die die Backend-Integration und das Rendering übernimmt, muss bei einem Upgrade auf v12 oder v13 geprüft werden. Die Extbase-API-Änderungen in v12 betreffen Repository-Klassen und Persistenz-Konfiguration. Bei Gosign migrieren wir Leaflet-Integrationen typischerweise durch ein Custom-Plugin im eigenen Sitepackage, das die Leaflet-Bibliothek direkt einbindet und die Standort-Daten aus einer Extbase-Tabelle oder einem JSON-Endpoint bezieht. Das eliminiert die Abhängigkeit von der Extension und gibt volle Kontrolle über Updates. Die Leaflet-Bibliothek selbst wird per npm oder CDN eingebunden und ist mit einer Grösse von 39 KB (komprimiert) deutlich leichter als die Google Maps JavaScript API (185+ KB), was sich positiv auf die Ladezeit der Kartenseiten auswirkt.

--- LimeSurvey TYPO3 - Umfrage-Integration | Gosign ---
> LimeSurvey in TYPO3: Umfragen einbetten, SSO-Anbindung, Ergebnis-Dashboard. KI-beschleunigte Integration.

## LimeSurvey ist die DSGVO-konforme Antwort auf Enterprise-Umfragen, die nicht in Google Forms enden dürfen

Wer in Deutschland professionelle Umfragen durchführt - Mitarbeiterbefragungen, Marktforschung, Evaluationsstudien, wissenschaftliche Erhebungen - und dabei DSGVO-Konformität, volle Datenhoheit und eine saubere Audit-Spur braucht, landet an LimeSurvey fast zwangsläufig vorbei. Die Open-Source-Software läuft auf dem eigenen Server, speichert Antwortdaten ausschliesslich in der eigenen Datenbank und bietet alle Frage-Typen, die seriöse Forschung verlangt. Für TYPO3-Betreiber stellt sich die Frage nicht, ob sie LimeSurvey einsetzen, sondern wie sie es in ihre bestehende Website integrieren.

Die Zielgruppe sind typischerweise Hochschulen, Forschungseinrichtungen, öffentliche Verwaltungen, Krankenhäuser, Konzerne mit Betriebsratsmandat und NGOs mit sensibler Zielgruppenbefragung. Ein Beispiel: Eine Hochschule mit 18.000 Studierenden führt jedes Semester eine Lehrevaluation durch und will die Ergebnisse auf der eigenen TYPO3-Website zurückspielen, ohne dass die Studierenden zwischen zwei Systemen wechseln müssen.

## Typische Einsatzszenarien

Ein erstes Szenario ist die nahtlose Umfrage-Teilnahme auf der TYPO3-Seite. Statt die Studierenden auf eine separate LimeSurvey-Domain zu schicken, wird der Fragebogen direkt auf der Website-Seite angezeigt. Die Antworten fliessen per API in LimeSurvey, die Studierenden sehen die gewohnte Website-Navigation. Das senkt die Abbruchrate deutlich.

Ein zweites Szenario ist die SSO-basierte Teilnehmer-Identifikation. Eine Krankenhauskette mit 8.000 Mitarbeiterinnen führt eine Mitarbeiterbefragung durch. Die Teilnehmer melden sich im TYPO3-Intranet an, klicken auf den Umfrage-Link und landen in LimeSurvey, ohne sich erneut anmelden zu müssen. Die SSO-Bridge garantiert, dass jeder Mitarbeiter nur einmal teilnimmt und dass die Personendaten aus TYPO3 nicht in die Umfrage-Antworten fliessen.

Ein drittes Szenario ist die Darstellung von Ergebnissen direkt auf der Website. Eine kommunale Verwaltung führt eine Bürgerbefragung zu einem Bauvorhaben durch und möchte die Zwischenstände täglich als Balkendiagramm auf der Projektseite zeigen. Ein Sync-Job holt die anonymisierten Aggregate über die API ab und rendert sie in einem TYPO3-Content-Element - ohne dass Rohdaten die TYPO3-Installation berühren.

Ein viertes Szenario ist die Longitudinal-Studie in der Forschung. Ein Forschungsprojekt zur Arbeitsbelastung im Pflegesektor befragt die gleiche Kohorte viermal pro Jahr über zwei Jahre hinweg. Die TYPO3-Seite dient als Informations- und Einstiegspunkt, LimeSurvey hält die Erhebungen, und die Integration sorgt dafür, dass jeder Teilnehmer per personalisiertem Link seine Folgebefragungen erreicht, ohne dass die Forschenden Kontaktdaten in LimeSurvey pflegen müssen.

## Technische Architektur

LimeSurvey stellt zwei API-Zugänge bereit: die klassische RemoteControl2-Schnittstelle auf JSON-RPC-Basis und die neuere REST-API in aktuellen Versionen. Für TYPO3-Integrationen ist RemoteControl2 weiterhin der Stabilitätsanker, weil sie in älteren LimeSurvey-Installationen verfügbar ist und vollständige Authentifizierung, Teilnehmer-Management und Antwort-Abfragen abdeckt.

Die TYPO3-Integration läuft in der Regel als eigene Extension. Ein Service-Layer kapselt die API-Calls, ein Plugin liefert Content-Elemente für das Einbetten von Umfragen, und eine Middleware implementiert die SSO-Logik. Für das Einbetten gibt es zwei Varianten: Die Umfrage wird über einen signierten Token aufgerufen und per iFrame eingebunden, oder die Fragen werden über die API gelesen und direkt als Fluid-Template gerendert. Letzteres bietet das beste Nutzererlebnis, erfordert aber mehr Entwicklungsaufwand.

Die SSO-Bridge basiert auf einem signierten Token, das TYPO3 generiert und LimeSurvey validiert. In LimeSurvey wird dafür ein Plugin eingerichtet, das Token aus der URL ausliest und den Teilnehmer als anonymes Token in der Tabelle der Umfrage-Teilnehmer anlegt. Wichtig ist, dass das Token zeitbegrenzt ist und pro Teilnehmer nur einmalig gültig ist.

## Häufige Probleme und Lösungen

Das erste Problem ist die Session-Handhabung zwischen TYPO3 und LimeSurvey. Beide Systeme haben eigene Sessions, und wenn der iFrame-Ansatz gewählt wird, entstehen Probleme mit Third-Party-Cookies in modernen Browsern. Die Lösung ist, LimeSurvey unter einer Subdomain der TYPO3-Installation zu betreiben, damit Cookies als First-Party akzeptiert werden, oder die API-Variante mit serverseitigem Rendering einzusetzen.

Das zweite Problem ist die Performance-Krise bei der Ergebnis-Darstellung. Wer pro Seitenaufruf die API nach Aggregaten fragt, lastet den LimeSurvey-Server unnötig aus. Die Lösung ist ein Sync-Job, der Aggregate in regelmässigen Intervallen (z.B. stündlich) in eine TYPO3-Tabelle schreibt und das Content-Element aus dieser Cache-Tabelle rendert.

Das dritte Problem ist der DSGVO-konforme Umgang mit personenbezogenen Daten. Bei Mitarbeiterbefragungen darf der Arbeitgeber in der Regel nicht erkennen können, wer welche Antwort gegeben hat. Die Lösung ist ein sauberes Trennkonzept: TYPO3 stellt nur anonymisierte Token bereit, LimeSurvey speichert Antworten ohne Rückbezug, und die Aggregation erfolgt ausschliesslich über Kennzahlen, die keine Rückschlüsse auf Einzelpersonen erlauben.

Ein viertes Problem sind Mobile-Darstellungsschwächen im iFrame-Modus. LimeSurvey-Umfragen sind zwar responsiv, aber in einem TYPO3-iFrame kommt es zu doppelten Scrollbalken und abgeschnittenen Buttons auf kleinen Bildschirmen. Die Lösung ist, für mobile Nutzung auf das serverseitige Rendering umzusteigen oder den iFrame dynamisch an den Inhalt anzupassen, sodass der Seitenlayout-Container die volle Höhe übernimmt.

## Migration und Versions-Kompatibilität

LimeSurvey-Integrationen laufen auf TYPO3 v11, v12 und v13. Die grössere Herausforderung ist die LimeSurvey-Seite: Zwischen LimeSurvey 3.x, 5.x und 6.x haben sich API-Details und Authentifizierungsverfahren geändert. Wer eine bestehende Integration auf eine neue LimeSurvey-Version hebt, sollte die API-Calls gegen die jeweilige Versionsdokumentation verifizieren und idealerweise einen automatisierten Integrationstest gegen eine LimeSurvey-Staging-Instanz fahren.

Gosign implementiert LimeSurvey-Integrationen für Hochschulen, Kliniken und öffentliche Träger. Der API-Client entsteht KI-gestützt aus der RemoteControl2-Dokumentation, die SSO-Bridge wird individuell an das bestehende Identitätsmanagement angepasst, und die Umsetzung erfolgt entlang einer klaren DSGVO-Dokumentation, die dem Datenschutzbeauftragten Arbeit abnimmt.

--- linkhandler TYPO3 - Custom Record Links | Gosign ---
> linkhandler: Custom Record Links im TYPO3 RTE. News, Events, Produkte direkt verlinken. Setup & Migration.

## linkhandler verhindert tote Links, wenn sich URLs ändern

In TYPO3 bezieht sich eine Typolink-Angabe direkt auf eine Seite, eine Datei oder eine URL - nicht auf einen Datensatz. Sobald eine Redaktion im Fliesstext auf Events, News-Artikel, Produkte oder Adressen verlinken will, muss sie entweder die URL hart eintragen oder eine Extension dazwischen schalten, die aus einer Record-ID eine stabile URL erzeugt. Genau das ist die Aufgabe von linkhandler. Die Extension von Cobwebsters registriert neue Link-Typen im TYPO3-RTE und im Link-Browser und verbindet sie mit beliebigen Datenbank-Tabellen. Bei einem Redaktionsprojekt mit mehr als hundert internen Querverweisen ist das der Unterschied zwischen einer funktionierenden Content-Architektur und einer Friedhof-Seite voller 404-Links.

## Typische Einsatzszenarien treten bei jeder Redaktion mit mehr als einer Content-Domain auf

Sobald News, Events und Produkte im selben Projekt existieren, brauchen Redakteure ein sauberes Linking-System. Eine Hochschule verlinkt im Magazin-Artikel auf das Event in sf_event_mgt, im Event-Text auf den beteiligten Autor aus md_news_author und im Autor-Profil zurück auf alle seine Beiträge in GeorgRinger/news. Drei Extensions, drei Record-Typen, und ohne linkhandler wäre jede dieser Querverweise eine harte URL, die beim nächsten Slug-Refactoring bricht. Im Alltag heisst das: Ein einziges URL-Refactoring kann dann dutzende oder hunderte Broken Links erzeugen, die erst Wochen später im Google-Search-Console-Report auftauchen.

Ein zweites Szenario sind E-Commerce-Texte: Produktbeschreibungen, die auf Zubehör verweisen, oder Blog-Artikel, die auf Produkte aus aimeos verlinken. linkhandler erzeugt die URLs automatisch aus der Produkt-Routing-Konfiguration, und bei einem Kategorie-Refactoring wandern sämtliche Links mit.

Drittens tritt der Bedarf bei Standort-Listings auf. Wer eine Filialstruktur oder Ansprechpartner-Verzeichnisse mit tt_address oder einem eigenen Model pflegt, will aus Artikeln heraus auf die jeweilige Detailseite verlinken. Der linkhandler-Link bleibt stabil, selbst wenn der Standort umbenannt wird.

## Technische Architektur registriert Linktypen per YAML und Handler-Klasse

linkhandler nutzt den TYPO3-LinkHandler-Mechanismus aus dem Core, der seit v8 verfügbar ist. Jeder Linktyp wird über eine YAML-Datei im Config-Verzeichnis registriert. Die YAML definiert den Handler-Bezeichner, die Tabelle, das Extbase-Modell und die Routing-Konfiguration. Im RTE und im Link-Browser erscheint der Linktyp als neuer Tab: "News", "Event", "Produkt", "Adresse". Jeder Tab zeigt eine Liste der verfügbaren Datensätze mit Such- und Filterfunktion, sodass Redakteure auch bei tausenden News-Einträgen gezielt den gewünschten Beitrag finden.

Der eigentliche Resolver ist eine PHP-Klasse, die von AbstractLinkHandler erbt und die Methoden modifyLinkField und generateRelativeUrl implementiert. Die Methoden erzeugen aus der Record-ID eine sprechende URL über die Site-Config und den Router der jeweiligen Extension. Im Frontend wird der Typolink mit dem Parameter t3://record aufgerufen und vom Page-Rendering in die finale URL aufgelöst. Das bedeutet: Selbst wenn zehntausende Artikel auf denselben News-Datensatz verlinken, muss bei einer Slug-Änderung nur der Artikel-Datensatz selbst aktualisiert werden - alle Links lösen sich automatisch auf die neue URL auf.

Die Konfiguration greift tief in das TYPO3-Linking-System ein, bleibt aber deklarativ: Nach der YAML-Registrierung und dem Cache-Clear steht der neue Linktyp im gesamten Projekt zur Verfügung, einschliesslich Fluid-Templates und Menü-Komponenten. Wer linkhandler nicht explizit nutzt, bekommt den Mechanismus über das TYPO3-Core-Linking ebenfalls, allerdings ohne die YAML-Abstraktionsschicht und das komfortable Backend-Picker-UI der Extension.

## Häufige Probleme betreffen Cache, Sprachvarianten und Datei-Handler

Das häufigste Supportthema sind Cache-Inkonsistenzen nach dem Update eines Records. Wenn der Slug eines News-Artikels angepasst wird, muss der Page-Cache des Quell-Artikels, in dem der linkhandler-Link steht, ebenfalls geleert werden - sonst bleibt die alte URL in der Ausgabe stehen. Die Lösung ist ein Cache-Tag, das mit dem Typolink-Rendering gesetzt wird. Viele Installationen aktivieren das nicht und kämpfen dann mit vermeintlich defekten Links.

Das zweite Problem sind Sprachvarianten. Ein News-Artikel in DE verweist über linkhandler auf ein Event. Die englische Übersetzung des Artikels soll auf dieselbe Event-ID verweisen, aber die URL in der englischen Sprache erzeugen. linkhandler bietet diese Auflösung über den Language-Aspekt, aber die YAML-Konfiguration muss explizit auf die Routing-Varianten der Zielseiten zeigen. Wer Fallback-Sprachen verwendet, muss zusätzlich prüfen, wie sich der Handler bei fehlenden Übersetzungen verhält - er sollte in der Fallback-Sprache auflösen, nicht auf die Hauptsprache zurückfallen.

Drittens ist der Datei-Handler ein Sonderfall. Wer neben Record-Links auch auf TYPO3-FAL-Dateien verlinken will, muss den linkhandler-Datei-Handler separat konfigurieren oder auf den nativen TYPO3-File-Linker zurückgreifen. Die Kombination ist möglich, aber die Reihenfolge der Handler in der YAML entscheidet, welcher Tab zuerst erscheint.

## TYPO3 v12 und v13 nutzen den Core-LinkHandler, Migration lohnt sich

Ab TYPO3 v11 ist der Core-LinkHandler produktionsreif und kann viele der Aufgaben von linkhandler selbst übernehmen. Trotzdem wird die Cobwebsters-Extension weiter gepflegt, weil sie zusätzliche Komfort-Features wie den YAML-Editor, den verbesserten Record-Picker und die Schema-freundliche Ausgabe mitbringt. Für TYPO3 v12 und v13 existiert eine aktuelle Version im TER und auf Packagist.

Beim Migrations-Review prüft Gosign, wie viele linkhandler-Aufrufe in den RTE-Inhalten stecken. Bei weniger als 50 Vorkommen lohnt sich oft der Umstieg auf den Core-LinkHandler, bei mehr als 100 Vorkommen oder stark individualisierten Handlern bleibt linkhandler die pragmatischere Wahl. Die Migration auf eine neue Major-Version läuft in der Regel ohne Inhalts-Änderungen, weil die t3://record-Syntax im Content stabil bleibt. Für die Analyse nutzen wir einen Scan über tt_content-Felder, der alle Links-Typen aufschlüsselt und eine Empfehlung pro Installation generiert.

--- Liveticker TYPO3 - Echtzeit-Updates | Gosign ---
> Live-Ticker für Echtzeit-Events: Sport, Wahlen, Konferenzen. WebSocket- oder Polling-basiert, mit automatischem Nachladen neuer Einträge.

## Echtzeit-Updates auf TYPO3-Websites verlangen mehr als ein News-Plugin mit Auto-Refresh

Sportvereine, Nachrichtenportale, Kommunen bei Wahlergebnissen und Konferenzveranstalter brauchen eine Funktion, die es so im TYPO3-Core nicht gibt: chronologische Kurzmeldungen, die in Echtzeit auf der Seite erscheinen, ohne dass der Besucher die Seite neu laden muss. Die liveticker-Extension löst das mit einem Frontend-Plugin, das neue Einträge automatisch per AJAX-Polling oder WebSocket nachladen und oben in die Timeline einfügen kann. Redakteure tippen eine Meldung im Backend, klicken "Speichern", und die Meldung erscheint Sekunden später auf der Website.

Für Organisationen, die zwei- bis dreimal im Jahr Live-Events auf ihrer Website begleiten, ist die Extension eine pragmatische Lösung. Wer täglich live tickert, sollte allerdings spezialisierte Plattformen wie Tickaroo evaluieren, die Multimedia-Inhalte, Social-Media-Integration und Multi-Autoren-Workflows besser abdecken.

## Typische Einsatzszenarien sind Sportveranstaltungen, Kommunalwahlen und Konferenzen

Das häufigste Szenario ist der Sport-Liveticker. Ein Amateursportverein begleitet Heimspiele mit einem Ticker auf der Vereinswebsite. Ein Redakteur am Spielfeldrand tippt Tore, Karten und Wechsel ins TYPO3-Backend (idealerweise über das Mobile-Backend), und die Einträge erscheinen chronologisch auf der Seite. Bei einem Fussball-Regionalligaspiel mit 500 bis 2.000 gleichzeitigen Besuchern muss der Ticker stabil laufen, ohne den Server zu überlasten.

Zweites Szenario: Wahlabende bei Kommunen und Landkreisen. Am Wahlsonntag veröffentlichen Gemeinden Zwischenergebnisse über einen Liveticker. Die Meldungen enthalten Stimmanteile, Hochrechnungen und Kommentare des Wahlleiters. Die Herausforderung: Alle Besucher erwarten das gleiche Ergebnis gleichzeitig, was Peak-Traffic erzeugt.

Drittes Szenario: Konferenzen und Mitgliederversammlungen. Verbände und Vereine tickern Hauptversammlungen live, damit Mitglieder, die nicht vor Ort sind, den Verlauf verfolgen können. Die Einträge enthalten Abstimmungsergebnisse, Redebeiträge und Beschlüsse. Für Verbände mit 5.000 bis 50.000 Mitgliedern, die nicht alle an einer Präsenzveranstaltung teilnehmen können, ist ein Liveticker die einfachste Form der digitalen Teilhabe, die keine Video-Streaming-Infrastruktur erfordert.

## Technische Architektur setzt auf TYPO3-Records mit AJAX-Polling im Frontend

Die Extension speichert Ticker-Einträge als TYPO3-Records in einer eigenen Tabelle. Jeder Eintrag enthält Zeitstempel, Text, optionales Bild und eine Kategorisierung (z.B. "Tor", "Gelbe Karte", "Ergebnis"). Die Records gehören zu einem Ticker-Container, der einem Event zugeordnet ist. Ein Redakteur kann mehrere Ticker parallel betreiben, etwa für verschiedene Spiele oder Events am gleichen Tag.

Im Frontend rendert das Plugin die bestehenden Einträge als chronologische Liste (neueste oben) und startet einen JavaScript-Timer, der in konfigurierbaren Intervallen (typisch: 10 bis 30 Sekunden) einen AJAX-Request an einen TYPO3-Endpoint sendet. Der Endpoint liefert alle Einträge, die seit dem letzten Abruf hinzugekommen sind. Das JavaScript fügt diese Einträge mit einer Animation oben in die Liste ein.

Fortgeschrittene Implementierungen nutzen WebSockets statt Polling, was die Latenz von 10 bis 30 Sekunden auf unter 1 Sekunde reduziert. Das erfordert allerdings einen WebSocket-Server (z.B. Node.js mit Socket.io), der parallel zum TYPO3-Webserver läuft. Für die meisten Vereins- und Kommunal-Websites ist das Overkill, und AJAX-Polling mit 15-Sekunden-Intervall liefert ein ausreichend echtzeitnahes Erlebnis. Eine Zwischenlösung sind Server-Sent Events (SSE), die eine persistente HTTP-Verbindung nutzen und einfacher zu implementieren sind als WebSockets, aber ebenfalls serverseitige Unterstützung benötigen.

## Häufige Probleme sind Server-Last bei Peak-Traffic, fehlende Mobile-Eingabe und Caching-Konflikte

Problem eins: Server-Last bei Peak-Traffic. Wenn 2.000 Besucher alle 15 Sekunden einen AJAX-Request senden, sind das 8.000 Requests pro Minute. Ohne Caching-Strategie bricht ein normaler Shared-Hosting-Server zusammen. Die Lösung: Einen Reverse-Proxy (z.B. Varnish oder Cloudflare) vor den AJAX-Endpoint schalten, der die Response für 5 Sekunden cached. So reduzieren sich die tatsächlichen Zugriffe auf den Application-Server auf 12 pro Minute statt 8.000.

Problem zwei: Mobile-Eingabe für Redakteure. Das TYPO3-Backend ist auf Mobilgeräten nur eingeschränkt nutzbar. Ein Redakteur am Spielfeldrand, der bei Regen auf einem Smartphone tippt, braucht eine vereinfachte Eingabemaske. Die Lösung: Ein Custom-Endpoint mit einem reduzierten Formular (Textfeld, Kategorie-Dropdown, Absenden-Button), das für mobile Browser optimiert ist.

Problem drei: Caching-Konflikte mit dem TYPO3-Page-Cache. Wenn die Seite, auf der der Ticker eingebettet ist, vom TYPO3-Cache ausgeliefert wird, sehen Besucher veraltete Einträge. Die Lösung: Die Ticker-Seite vom Page-Cache ausschliessen (USER_INT) oder besser: Die Seite cachen und nur den Ticker-Bereich per AJAX nachladen, was die Kombination aus gecachter Seite und dynamischem Inhalt ermöglicht.

## Die Extension ist für ältere TYPO3-Versionen gebaut, Custom-Lösungen sind zukunftssicherer

liveticker hat keine offizielle Unterstützung für TYPO3 v12 oder v13. Die Kernfunktionalität ist aber so überschaubar, dass ein Neubau als Custom-Plugin in vielen Fällen wirtschaftlicher ist als die Migration der Extension. Gosign baut Liveticker-Funktionen als schlanke Extbase-Plugins mit einem JSON-API-Endpoint, der von einem einfachen JavaScript-Client im Frontend konsumiert wird. Der Aufwand für eine Grundimplementierung (Backend-Eingabe, Frontend-Anzeige, AJAX-Polling) liegt bei 3 bis 5 Arbeitstagen.

Der Vorteil einer Custom-Lösung: Die Mobile-Eingabe kann als Progressive Web App realisiert werden, sodass der Redakteur am Spielfeldrand eine optimierte Eingabeoberfläche hat. Zusätzlich lässt sich ein Cache-Layer (z.B. Redis oder Cloudflare Workers) zwischen Frontend und TYPO3 schalten, der die Server-Last bei Peak-Traffic auf ein Minimum reduziert. Diese Architektur skaliert für 10.000+ gleichzeitige Besucher ohne Performance-Probleme.

--- Mailchimp TYPO3 - Newsletter | Gosign ---
> Subscriber-Synchronisation zwischen TYPO3 und Mailchimp. Kampagnen-Statistiken, Template-Sync, Transaktionsmails. DSGVO:.

## Mailchimp-TYPO3-Integration geht über Formulare hinaus und synchronisiert Audiences bidirektional

Während koning_mailchimp_signup nur Anmeldeformulare abdeckt, geht die mailchimp-Extension einen Schritt weiter: Sie synchronisiert komplette Subscriber-Listen bidirektional zwischen TYPO3 und Mailchimp, überträgt Kampagnen-Statistiken ins Backend und kann Newsletter-Templates aus TYPO3-Content-Elementen generieren. Für Unternehmen, die Mailchimp nicht nur als Newsletter-Versand, sondern als zentrale Marketing-Automation-Plattform nutzen, schliesst die Extension die Lücke zwischen CMS und E-Mail-Marketing.

Der DSGVO-Aspekt ist bei dieser tieferen Integration noch relevanter: Nicht nur E-Mail-Adressen, sondern auch Engagement-Daten (Öffnungen, Klicks, Bounces), Tags und Custom Fields werden zwischen Systemen übertragen. Ohne Auftragsverarbeitungsvertrag mit Mailchimp und dokumentierten US-Transfer-Mechanismus ist das datenschutzrechtlich nicht zulässig.

## Typische Einsatzszenarien sind Marketing-Automation, Template-Sync und Reporting

Das Hauptszenario ist die bidirektionale Subscriber-Synchronisation für Marketing-Teams. TYPO3 ist die Quelle für neue Anmeldungen (über Formulare auf der Website), Mailchimp ist die Quelle für Engagement-Daten. Die Extension gleicht beide Systeme regelmässig ab, sodass Marketing in Mailchimp sehen kann, welche Subscriber über welche Website-Seite angemeldet wurden, und in TYPO3 sichtbar ist, welche Subscriber aktiv sind und welche als inaktiv markiert wurden.

Zweites Szenario: Template-Synchronisation. Die Redaktion pflegt Newsletter-Inhalte in TYPO3, und die Extension überträgt Content-Elemente (Teaser, Bilder, Links) in Mailchimp-Templates. So entfällt die doppelte Pflege: Der Teaser auf der Website und der Teaser im Newsletter stammen aus demselben Datensatz.

Drittes Szenario: Kampagnen-Reporting im TYPO3-Backend. Marketing-Verantwortliche, die keinen direkten Zugang zum Mailchimp-Dashboard haben, sehen Öffnungsraten, Klickraten und Bounce-Raten direkt im TYPO3-Backend. Das ist relevant für Unternehmen mit strikter Rechteverwaltung, bei denen nur ausgewählte Personen Zugang zu Mailchimp haben. Die Daten helfen der Redaktion zu verstehen, welche Website-Inhalte im Newsletter funktionieren und welche nicht, was wiederum die Content-Strategie der Website beeinflusst.

## Technische Architektur nutzt die Mailchimp-API v3 mit Scheduler-basiertem Sync

Die Extension kommuniziert über die Mailchimp Marketing API v3. Die Authentifizierung erfolgt über einen API-Key, der im TYPO3-Extension-Manager hinterlegt wird. Der Sync läuft über TYPO3-Scheduler-Tasks in konfigurierbaren Intervallen.

Der Subscriber-Sync arbeitet in zwei Richtungen: TYPO3-zu-Mailchimp überträgt neue Anmeldungen und Profiländerungen. Mailchimp-zu-TYPO3 importiert Engagement-Daten, Abmeldungen und Bounce-Status. Die Sync-Logik verwendet Mailchimp-Member-IDs (MD5-Hash der E-Mail-Adresse) als eindeutigen Schlüssel für den Abgleich.

Die Template-Synchronisation rendert TYPO3-Content-Elemente über Fluid-Templates in ein E-Mail-kompatibles HTML-Format. Das Template wird per API-Call an Mailchimp übertragen und steht dort als Campaign-Template zur Verfügung. Die Extension kümmert sich um die Konvertierung von CSS-Klassen in Inline-Styles, was für die E-Mail-Client-Kompatibilität zwingend nötig ist.

Kampagnen-Daten werden per GET-Request von der Mailchimp-API abgerufen und in einer TYPO3-Datenbanktabelle gespeichert. Das Backend-Modul zeigt die Daten als Dashboard mit Basis-KPIs: Empfänger, Öffnungsrate, Klickrate, Abmeldungen pro Kampagne.

## Häufige Probleme sind Sync-Konflikte, API-Rate-Limits und Template-Rendering-Unterschiede

Problem eins: Sync-Konflikte bei gleichzeitigen Änderungen. Wenn ein Subscriber sich über Mailchimp abmeldet und gleichzeitig ein Redakteur in TYPO3 dessen Profil ändert, entsteht ein Konflikt. Die Lösung: Klare Datenhoheit definieren. In der Praxis ist Mailchimp die führende Quelle für Engagement-Daten und Abmeldungen, TYPO3 für Stammdaten und neue Anmeldungen.

Problem zwei: API-Rate-Limits. Die Mailchimp-API erlaubt maximal 10 gleichzeitige Verbindungen und hat Throughput-Limits, die bei grossen Sync-Vorgängen greifen. Wer 50.000 Subscriber synchronisiert, muss den Sync in Batches aufteilen (empfohlen: 500 Records pro Request) und Backoff-Logik implementieren.

Problem drei: Template-Rendering-Unterschiede zwischen Website und E-Mail. Ein Content-Element, das auf der Website korrekt aussieht, kann in Outlook oder Gmail anders dargestellt werden. Besonders Flexbox-Layouts, Webfonts und SVG-Bilder funktionieren in E-Mails nicht. Die Lösung: Separate E-Mail-Templates mit Tabellen-basiertem Layout und System-Fonts. Gosign pflegt für solche Fälle ein dediziertes E-Mail-Template-Set, das die häufigsten Content-Elemente E-Mail-kompatibel rendert.

Ein viertes Problem betrifft die Listenhygiene. Mailchimp berechnet nach Audience-Grösse, und wenn die TYPO3-Synchronisation inaktive Subscriber nicht bereinigt, wächst die Liste mit Adressen, die nie öffnen oder längst ungültig sind. Die Extension sollte so konfiguriert sein, dass Bounce-Status und Unsubscribe-Events von Mailchimp zurück nach TYPO3 gespiegelt werden, damit inaktive Adressen aus der Synchronisation ausgeschlossen werden. Das spart Mailchimp-Kosten und verbessert die Zustellrate der verbleibenden Empfänger.

## TYPO3 v12 wird unterstützt, für v13 empfiehlt sich eine direkte API-Integration

Die mailchimp-Extension unterstützt TYPO3 v11 und v12. Beim Upgrade müssen vor allem die Scheduler-Task-Konfigurationen angepasst werden, da sich die Scheduler-API in TYPO3 v12 geändert hat. Die Extension-Konfiguration sollte gleichzeitig auf SiteSet-basierte Settings umgestellt werden, um zukunftssicher aufgestellt zu sein. Für TYPO3 v13 liegt noch kein offizielles Release vor. Da die Mailchimp-API v3 stabil und gut dokumentiert ist, empfiehlt Gosign für v13-Projekte eine direkte API-Integration ohne Extension-Abhängigkeit. Ein Custom-Service-Klasse in einem eigenen TYPO3-Package, die die Mailchimp-API direkt anspricht, ist wartungsärmer als eine Community-Extension und lässt sich exakt auf die Projektanforderungen zuschneiden.

Unternehmen, die langfristig bei Mailchimp bleiben wollen, sollten zusätzlich die Mailchimp-Webhook-Funktion evaluieren: Statt regelmässig Daten abzufragen, sendet Mailchimp Events (Anmeldung, Abmeldung, Bounce) aktiv an einen TYPO3-Endpoint. Das reduziert die Sync-Latenz von Minuten auf Sekunden und eliminiert die Belastung durch periodische API-Abfragen.

--- mailingwork TYPO3 - Newsletter | Gosign ---
> mailingwork ist ein deutsches E-Mail-Marketing-System. Die TYPO3-Integration synchronisiert Subscriber, Double-Opt-In und Segmentierung. Server.

## mailingwork ist die DSGVO-native Newsletter-Alternative zu Mailchimp für TYPO3-Projekte

Unternehmen, die einen professionellen Newsletter versenden, aber keine Daten in die USA übertragen wollen, landen fast zwangsläufig bei einem deutschen Anbieter. mailingwork gehört zu den etablierten deutschen E-Mail-Marketing-Plattformen mit Servern in Deutschland, deutscher Rechtsform und einem Support-Team, das DSGVO-Fragen auf Deutsch beantworten kann. Die TYPO3-Extension synchronisiert Subscriber-Listen, steuert Double-Opt-In und überträgt Segmentierungsdaten zwischen CMS und Newsletter-System. Für TYPO3-Projekte, die eine rechtlich unkomplizierte Newsletter-Lösung brauchen, ist die Kombination aus mailingwork und TYPO3 eine der wartungsärmsten Optionen im deutschsprachigen Markt.

Der Vergleich mit Mailchimp zeigt den Unterschied: Kein AVV mit einem US-Unternehmen nötig, kein Transfer-Mechanismus zu dokumentieren, kein Risiko bei Änderungen der transatlantischen Datenschutzabkommen. Die Kehrseite: mailingwork hat einen kleineren Feature-Set als Mailchimp und kein vergleichbares Ökosystem an Third-Party-Integrationen. Wer fortgeschrittene Marketing-Automation (Behavioral Trigger, Lead Scoring, Customer Journey Mapping) benötigt, stösst bei mailingwork eher an Grenzen als bei Mailchimp oder HubSpot.

## Typische Einsatzszenarien sind Unternehmens-Newsletter, Mitglieder-Kommunikation und Lead-Nurturing

Das Standardszenario ist der monatliche Unternehmens-Newsletter für 5.000 bis 50.000 Empfänger. Die Redaktion pflegt Inhalte in TYPO3, erstellt den Newsletter in mailingwork und verschickt ihn an segmentierte Listen. Die TYPO3-Extension sorgt dafür, dass neue Website-Anmeldungen automatisch in mailingwork landen und dass Abmeldungen in beide Richtungen synchronisiert werden.

Zweites Szenario: Mitglieder-Kommunikation bei Verbänden und Vereinen. Ein Berufsverband mit 10.000 Mitgliedern verschickt Rundschreiben, Einladungen und Jahresberichte. Die Mitglieder-Daten liegen in TYPO3 (über fe_users oder eine Custom-Tabelle), und mailingwork übernimmt den Versand. Die Segmentierung nach Mitgliedsart, Region oder Fachgruppe wird über Tags gesteuert, die die Extension aus TYPO3-Kategorien generiert.

Drittes Szenario: Lead-Nurturing für B2B-Unternehmen. Ein Maschinenbauer sammelt Leads über Whitepaper-Downloads und Kontaktformulare auf der TYPO3-Website. Die Extension überträgt die Leads mit Quell-Information (welches Formular, welche Seite) an mailingwork, das eine automatisierte E-Mail-Strecke startet: Welcome-Mail nach 1 Tag, Case-Study nach 7 Tagen, Angebots-Einladung nach 14 Tagen.

## Technische Architektur verbindet TYPO3-Formulare über die mailingwork-REST-API

Die Extension nutzt die mailingwork-REST-API für den Datenaustausch. Die Konfiguration im TYPO3-Extension-Manager umfasst API-Endpoint, API-Key und die Zuordnung von TYPO3-Feldern zu mailingwork-Kontaktfeldern. Der Sync läuft über Scheduler-Tasks in konfigurierbaren Intervallen.

Der Subscriber-Import folgt einem klaren Ablauf: Ein Besucher füllt ein Anmeldeformular auf der Website aus. TYPO3 speichert die Daten lokal und überträgt sie per API-Call an mailingwork. mailingwork verschickt die Double-Opt-In-Mail. Erst nach Bestätigung wird der Subscriber in der aktiven Liste geführt. Die Extension protokolliert jeden Schritt in einer Log-Tabelle, was für DSGVO-Audits relevant ist.

Die Segmentierung funktioniert über Tags und Custom Fields. Die Extension kann TYPO3-Kategorien (Sys-Categories) automatisch als Tags an mailingwork übergeben. So lassen sich Website-spezifische Segmente (z.B. "Interessiert an Produkt X") direkt für den Newsletter-Versand nutzen.

Die Templates in mailingwork werden unabhängig von TYPO3 gepflegt. Wer Content aus TYPO3 automatisch in Newsletter-Templates übernehmen will, muss das über die mailingwork-API und Custom-Code lösen, da die Standard-Extension diese Funktion nicht abdeckt.

## Häufige Probleme betreffen Feld-Mapping, Double-Opt-In-Timing und Fehler-Handling

Problem eins: Fehlerhaftes Feld-Mapping. Die Felder in TYPO3-Formularen stimmen selten 1:1 mit den Kontaktfeldern in mailingwork überein. Ein Formular hat "Firma", mailingwork erwartet "company". Ohne korrektes Mapping landen Daten in falschen Feldern oder gehen verloren. Die Lösung: Vor der Integration ein Feld-Mapping-Dokument erstellen, das alle TYPO3-Felder den mailingwork-Feldern zuordnet, und die Zuordnung in der Extension-Konfiguration hinterlegen.

Problem zwei: Timing des Double-Opt-In. Zwischen der Anmeldung auf der Website und dem Klick auf den Bestätigungslink vergehen oft Stunden oder Tage. Wenn der Sync-Job in der Zwischenzeit läuft und den noch nicht bestätigten Subscriber als "aktiv" an TYPO3 zurückmeldet, entstehen Inkonsistenzen. Die Lösung: Den Subscriber-Status in TYPO3 erst auf "aktiv" setzen, wenn mailingwork den Status "confirmed" zurückgibt.

Problem drei: Fehler-Handling bei API-Ausfällen. Wenn die mailingwork-API nicht erreichbar ist, muss die Extension die Anmeldung puffern und beim nächsten Sync-Lauf erneut versuchen. Ohne diese Retry-Logik gehen Anmeldungen verloren. Die Extension bietet eine Queue-Funktion, die fehlgeschlagene API-Calls speichert und automatisch wiederholt.

Ein viertes Problem, das bei grösseren Installationen auftaucht: Reporting-Granularität. mailingwork liefert Kampagnen-Statistiken auf Empfänger-Ebene, aber die TYPO3-Extension bildet nicht alle Metriken im Backend ab. Für detaillierte Analysen (Klick-Heatmaps, Öffnungszeitpunkte, Device-Verteilung) muss man ins mailingwork-Dashboard wechseln. Gosign empfiehlt, das TYPO3-Backend-Modul für Übersichtsdaten zu nutzen und für tiefe Analysen direkt in mailingwork zu arbeiten.

## mailingwork pflegt die TYPO3-Extension aktiv, v12 wird unterstützt

mailingwork als kommerzieller Anbieter hat ein geschäftliches Interesse daran, die TYPO3-Integration aktuell zu halten, weil der TYPO3-Markt ein relevanter Vertriebskanal ist. Die aktuelle Extension unterstützt TYPO3 v11 und v12. Für v13 ist die Kompatibilität zu erwarten, aber noch nicht offiziell bestätigt. Beim Upgrade von v10 auf v12 betreffen Änderungen vor allem die Scheduler-Task-Registrierung und die Extension-Konfiguration, die von ExtensionManager-Settings auf SiteSet-Konfiguration umgestellt werden sollte. Der Subscriber-Sync und die API-Kommunikation bleiben stabil.

--- maps2 TYPO3 - Karten-Extension | Gosign ---
> Die Standard-Karten-Extension für TYPO3. Unterstützt Google Maps, OpenStreetMap und Mapbox. Marker aus TYPO3-Records, Clustering, Routing,.

## Warum maps2 die Standardlösung für Karten in TYPO3 geworden ist

Jede zweite Unternehmenswebsite braucht eine Kartenanzeige - für Standorte, Filialen, Veranstaltungsorte oder Liefergebiete. In TYPO3 hat sich maps2 als die am weitesten verbreitete Karten-Extension etabliert, weil sie drei Map-Provider gleichzeitig unterstützt: Google Maps, OpenStreetMap und Mapbox. Das bedeutet für Unternehmen echte Wahlfreiheit. Wer Google Maps aus Datenschutzgründen vermeiden will, wechselt auf OpenStreetMap, ohne die Extension austauschen zu müssen.

maps2 geht dabei weit über eine einfache Karteneinbettung hinaus. Die Extension erzeugt Marker direkt aus TYPO3-Datensätzen, unterstützt Clustering bei grossen Markermengen und bietet Routing-Funktionen. Für Redakteure ist das Anlegen neuer Standorte so einfach wie das Erstellen eines normalen TYPO3-Content-Elements.

## Typische Einsatzszenarien

**Filialfinder für Unternehmen mit 10 bis 500 Standorten.** Ein Einzelhandelsunternehmen will auf seiner Website einen interaktiven Filialfinder anbieten. Jede Filiale ist als tt_address-Datensatz oder eigener Record in TYPO3 gespeichert. maps2 liest die Adressen, geocodiert sie (in Kombination mit der Extension geocoordinates) und zeigt sie als Marker auf der Karte. Bei einem Klick auf den Marker öffnet sich ein Popup mit Adresse, Öffnungszeiten und Kontaktdaten. Bei mehr als 50 Markern aktiviert maps2 automatisches Clustering, damit die Karte übersichtlich bleibt.

**Immobilien-Websites mit Objektkarten.** Makler-Websites auf TYPO3-Basis nutzen maps2 zusammen mit der OpenImmo-Extension. Jedes importierte Immobilienobjekt wird automatisch auf der Karte angezeigt. Nutzer können nach Region filtern und zwischen Karten- und Listenansicht wechseln.

**Event- und Veranstaltungsseiten.** Kultureinrichtungen, Messen oder Kommunen zeigen Veranstaltungsorte auf einer Karte. maps2 lässt sich mit jeder Extbase-Extension verknüpfen, die Adressdaten enthält - ob cal, tt_address oder eigene Extensions.

## Technische Architektur

maps2 ist als Extbase-Extension aufgebaut und nutzt das TYPO3 Plugin-System für die Frontend-Ausgabe. Die zentrale Architekturentscheidung ist die Provider-Abstraktion: Die Extension definiert ein einheitliches Interface für Map-Rendering, das von drei Providern implementiert wird.

- **Google Maps Provider**: Nutzt die Google Maps JavaScript API v3. Erfordert einen API-Key mit aktiviertem Maps JavaScript API und Geocoding API. Kosten: ca. 7 USD pro 1.000 Kartenaufrufe nach dem kostenlosen Kontingent (28.000/Monat).
- **OpenStreetMap Provider**: Nutzt Leaflet.js als Rendering-Library mit OSM-Tiles. Keine API-Kosten, keine Registrierung nötig. Einschränkung: Die OSM-Tile-Server haben ein Fair-Use-Limit. Für Websites mit mehr als 50.000 Seitenaufrufen pro Monat empfiehlt sich ein eigener Tile-Server oder ein kommerzieller Anbieter wie MapTiler.
- **Mapbox Provider**: Premium-Option mit eigenen Kartenstilen. Kosten: 50.000 kostenlose Kartenaufrufe pro Monat, danach 0,50 USD pro 1.000.

Die Extension speichert Kartenkonfigurationen (Zoom, Center, Style) in eigenen Datenbanktabellen. Marker werden über eine Relation zu beliebigen TYPO3-Records erzeugt - maps2 ist nicht auf einen bestimmten Record-Typ festgelegt. Über ein TCA-Override können Entwickler jede Tabelle mit Kartendaten verknüpfen.

Abhängigkeiten: TYPO3 Core (v11+), optional geocoordinates für automatisches Geocoding von Adressen. Für die Frontend-Darstellung benötigt maps2 die JavaScript-API des gewählten Providers. Bei Google Maps wird die API über einen externen Script-Tag geladen; bei OpenStreetMap wird Leaflet.js lokal als Dependency mitgeliefert.

## Häufige Probleme und Lösungen

**Problem: Karte wird nicht angezeigt, nur grauer Bereich.** Bei Google Maps ist in 90% der Fälle der API-Key das Problem. Entweder fehlt er, die Abrechnung ist nicht aktiviert (Google verlangt seit 2018 eine hinterlegte Kreditkarte), oder die erlaubten Domains im API-Key stimmen nicht mit der Website überein. Die Lösung: In der Google Cloud Console prüfen, ob Maps JavaScript API aktiviert ist und der Key für die richtige Domain freigeschaltet wurde.

**Problem: Marker erscheinen an falscher Position.** Ursache ist häufig ein fehlerhaftes oder fehlendes Geocoding. Wenn Adressen keine Koordinaten haben, versucht maps2 sie über den konfigurierten Geocoding-Service aufzulösen. Bei ungenauen Adressen (z.B. nur Postleitzahl ohne Strasse) landen Marker in der Stadtmitte statt am tatsächlichen Standort. Die Lösung: Koordinaten einmalig über einen Batch-Geocoding-Lauf korrigieren und im Datensatz als feste Werte speichern.

**Problem: Performance-Probleme bei mehr als 200 Markern.** Die JavaScript-Bibliothek rendert jeden Marker einzeln ins DOM. Ab 200 Markern wird das auf mobilen Geräten spürbar langsam. Die Lösung: Marker-Clustering aktivieren und bei Bedarf serverseitiges Filtering implementieren, sodass nur Marker im aktuellen Kartenausschnitt geladen werden.

## Migration und Versions-Kompatibilität

maps2 wird aktiv von Stefan Froemken gepflegt und ist für TYPO3 v11 und v12 LTS verfügbar. Die Kompatibilität mit TYPO3 v13 wird in der Regel zeitnah nach dem LTS-Release hergestellt. Die Extension hat eine stabile API und kaum Breaking Changes zwischen Major-Versionen.

Wer von einer älteren Karten-Extension migriert (z.B. wec_map, od_googlemaps oder ke_daysspecial_map), muss die Datenbankstruktur anpassen. maps2 nutzt eigene Tabellen für die Kartenkonfiguration, die nicht kompatibel mit älteren Extensions sind. Eine Migration umfasst typischerweise: Koordinaten-Export aus der alten Extension, Neuanlage der maps2-Records, Verknüpfung mit bestehenden TYPO3-Datensätzen.

Beim Wechsel von Google Maps auf OpenStreetMap (häufig aus DSGVO-Gründen) muss nur die Provider-Konfiguration in maps2 geändert werden. Templates und Marker-Daten bleiben identisch. Gosign hat diesen Wechsel bei mehreren Kunden in unter einem Tag umgesetzt. Die DSGVO-Motivation dahinter: Google Maps überträgt personenbezogene Daten (IP-Adresse, Browser-Fingerprint) an Google-Server in den USA. Mit OpenStreetMap bleiben die Daten in Europa, und ein Consent-Banner für Kartendienste wird überflüssig. Für Unternehmen, die Karten auf jeder Seite einbinden, verbessert das auch die User Experience, weil die Karte sofort sichtbar ist, ohne dass der Besucher erst dem Cookie-Banner zustimmen muss.

--- Marquee TYPO3 - Lauftext/Ticker | Gosign ---
> Lauftext/Ticker-Band: News-Ticker, Hinweis-Banner, Ankündigungen. Gosign implementiert CSS-basierte Marquees ohne Extension, leichtgewichtiger,.

## Lauftexte und Ticker-Bänder brauchen keine Extension, CSS löst das in 20 Zeilen

Das Marquee-Element kennt jeder aus den Anfängen des Webs: Scrollender Text, der von rechts nach links über die Seite läuft. Das HTML-`<marquee>`-Tag ist seit Jahren deprecated, aber der Effekt bleibt gefragt. News-Ticker, Hinweis-Banner ("Wartungsarbeiten am Samstag") und Event-Ankündigungen nutzen Lauftexte als Aufmerksamkeits-Mechanismus. Die marquee-Extension für TYPO3 liefert ein Content-Element, das diesen Effekt über JavaScript rendert. Gosign empfiehlt stattdessen eine rein CSS-basierte Lösung, die ohne Extension, ohne JavaScript und ohne Update-Pflicht auskommt.

Der Unterschied ist messbar: Die Extension lädt JavaScript, registriert ein Content-Element im TCA und braucht Fluid-Templates. Die CSS-Alternative ist eine einzige CSS-Animation (20 Zeilen) auf einem normalen Text-Content-Element. Performance, Barrierefreiheit und Wartungsaufwand sprechen klar für den CSS-Ansatz.

## Typische Einsatzszenarien sind Wartungshinweise, Aktions-Banner und Sportergebnisse

Das häufigste Szenario ist der Hinweis-Banner auf Unternehmenswebsites. "Unser Büro ist vom 24.12. bis 02.01. geschlossen" oder "Jetzt anmelden: Webinar am 15. März". Der scrollende Text zieht Aufmerksamkeit auf sich, ohne ein Popup zu sein. Redakteure pflegen den Text im TYPO3-Backend und aktivieren oder deaktivieren den Banner über ein Start- und Enddatum.

Zweites Szenario: News-Ticker auf Nachrichtenportalen und Intranet-Startseiten. Die letzten drei bis fünf Schlagzeilen laufen als Ticker über den oberen Seitenrand. Jede Schlagzeile ist ein Link zur vollständigen Meldung. Die Geschwindigkeit ist so eingestellt, dass der Text lesbar bleibt (empfohlen: 30 bis 50 Pixel pro Sekunde).

Drittes Szenario: Sportergebnisse auf Vereinswebsites. Am Spieltag zeigt ein Ticker die aktuellen Ergebnisse aller Mannschaften. Die Daten kommen aus einer TYPO3-Tabelle oder einem externen Feed und werden als scrollender Text dargestellt. Die Kombination aus Lauftext und automatischer Aktualisierung (per AJAX alle 60 Sekunden) macht den Ticker zum Echtzeit-Informationskanal ohne die Komplexität einer vollständigen Liveticker-Extension.

## Technische Architektur der Extension ist ein JavaScript-gesteuertes Content-Element

Die marquee-Extension registriert ein Content-Element im TYPO3-TCA, das Felder für Text, Geschwindigkeit, Richtung und Wiederholung enthält. Das Fluid-Template rendert ein Container-Element, und eine JavaScript-Datei initialisiert die Animation. Die Konfiguration (Geschwindigkeit, Pause bei Hover, Endlos-Wiederholung) wird über data-Attribute am Container-Element an das JavaScript übergeben.

Die CSS-Alternative funktioniert so: Ein normales Text-Content-Element bekommt eine CSS-Klasse (z.B. "marquee"), und die CSS-Animation @keyframes scroll verschiebt den Text von rechts nach links. Die Animation ist endlos, pausiert bei Hover (über :hover) und respektiert die prefers-reduced-motion-Einstellung des Betriebssystems, was für Barrierefreiheit relevant ist. Der gesamte Code:

```css
.marquee { overflow: hidden; white-space: nowrap; }
.marquee span { display: inline-block; animation: scroll 20s linear infinite; }
.marquee:hover span { animation-play-state: paused; }
@media (prefers-reduced-motion: reduce) { .marquee span { animation: none; } }
@keyframes scroll { from { transform: translateX(100%); } to { transform: translateX(-100%); } }
```

## Häufige Probleme sind Barrierefreiheit, mobile Darstellung und SEO-Relevanz

Problem eins: Barrierefreiheit. Bewegte Inhalte sind für Menschen mit kognitiven Einschränkungen oder Epilepsie problematisch. Die WCAG 2.1 verlangt, dass Animationen pausierbar, stoppbar oder ausblendbar sind. Die Extension bietet eine Pause-bei-Hover-Funktion, aber keinen Stop-Button. Die CSS-Lösung respektiert automatisch die prefers-reduced-motion-Einstellung, was die Extension nicht tut.

Problem zwei: Mobile Darstellung. Auf Smartphones ist der verfügbare Platz für scrollenden Text minimal. Ein Ticker, der auf dem Desktop gut lesbar ist, rauscht auf dem Handy so schnell vorbei, dass niemand mitlesen kann. Die Lösung: Auf Mobilgeräten den Ticker durch einen statischen Banner ersetzen, der die wichtigste Meldung zeigt, ohne Animation.

Problem drei: SEO-Relevanz. Scrollender Text wird von Suchmaschinen zwar indexiert, aber die UX-Signale (kurze Verweildauer auf dem Ticker, keine Klicks) können sich negativ auf die Seitenqualität auswirken. Ticker-Inhalte sollten immer auch als normale Seiteninhalte verfügbar sein, nicht ausschliesslich im Ticker.

Ein viertes Problem: Barrierefreiheits-Konformität bei öffentlichen Einrichtungen. Das BFSG und die EN 301 549 verlangen, dass Animationen pausierbar und stoppbar sind. Ein Marquee ohne Stopp-Button oder Pause-Mechanismus verstösst gegen WCAG 2.2.2 (Pause, Stop, Hide). Die CSS-Lösung mit prefers-reduced-motion und :hover-Pause erfüllt diese Anforderung teilweise, ein expliziter Pause-Button wäre für volle Konformität nötig.

## Die Extension ist für aktuelle TYPO3-Versionen überflüssig

Die marquee-Extension hat keine offizielle Unterstützung für TYPO3 v12 oder v13. Da die CSS-Alternative in 15 Minuten implementiert ist und keine Extension-Abhängigkeit erzeugt, empfiehlt Gosign bei jeder Migration den Wechsel. Der Redakteur nutzt ein normales Text-Content-Element mit einer speziellen CSS-Klasse, die im Site-Package definiert ist. Das ist wartungsfrei, performant und barrierefrei.

Für Projekte, die mehrere Meldungen im Ticker rotieren lassen wollen, reicht eine erweiterte CSS-Animation, die mehrere Textblöcke nacheinander durchlaufen lässt. Alternativ kann ein minimales JavaScript (unter 20 Zeilen) die Texte aus einer JSON-Quelle nachladen und die Animation steuern. Beides ist architektonisch sauberer als eine Extension, die für einen Effekt ein komplettes TCA-Feld, ein Fluid-Template und eine JavaScript-Datei mitbringt. Bei Gosign setzen wir den CSS-Ansatz in allen Projekten ein, die einen Ticker oder Lauftext benötigen.

--- Mask TYPO3 - Custom Content Elements | Gosign ---
> Mask ist das Standard-Tool für Custom Content Elements in TYPO3. Backend-Masken ohne PHP erstellen: Felder definieren, Fluid Template zuweisen,.

## Redakteure brauchen eigene Content-Elemente, nicht den nächsten Workaround mit Textfeldern

Jede TYPO3-Website erreicht den Punkt, an dem die mitgelieferten Content-Elemente nicht mehr reichen. Ein Team-Karussell, eine Preistabelle mit Toggles, ein Produkt-Teaser mit Bild, Text und CTA-Button - solche Anforderungen landen sonst im RTE als HTML-Brei oder in einem überfüllten Flexform-Container. Mask löst dieses Problem grundsätzlich: Redakteure bekommen eigene Backend-Masken mit genau den Feldern, die sie brauchen. Keine PHP-Klassen, kein TCA von Hand, kein ext_tables.sql.

Mask ist seit 2016 das meistgenutzte Framework für Custom Content Elements in TYPO3. Über 1.500 aktive Installationen (Stand: packagist, April 2026) und die Aufnahme in die offizielle TYPO3-Dokumentation als empfohlener Weg für individuelle Inhaltselemente belegen den Status als De-facto-Standard.

## Typische Einsatzszenarien

**Corporate Websites mit komplexen Seitenstrukturen.** Marketing-Teams brauchen 15 bis 30 verschiedene Content-Elemente: Hero-Banner, Testimonials, Akkordeons, Tabbed Content, Downloads mit Vorschaubild, Kontaktkarten. Mask bildet jedes davon als eigenes Backend-Formular ab. Redakteure sehen nur die Felder, die zum jeweiligen Element gehören, keine Verwirrung durch irrelevante Optionen.

**Mehrsprachige Projekte mit konsistenter Struktur.** Mask-Elemente unterstützen die TYPO3-Übersetzungsmechanismen vollständig. Felder lassen sich als l10n_mode exclude (nicht übersetzbar) oder prefixLangTitle (übersetzbar mit Hinweis) konfigurieren. Bei Websites in 5+ Sprachen spart das Redaktionszeit, weil die Struktur identisch bleibt und nur der Inhalt übersetzt wird.

**Relaunch-Projekte mit Bestandsdaten.** Wer von einem alten System (WordPress, TYPO3 mit Gridelements oder TemplaVoilà) migriert, braucht saubere Content-Strukturen. Mask-Elemente lassen sich per mask_export als eigenständige Extension exportieren. Damit werden Content-Definitionen versionierbar und über CI/CD-Pipelines deploybar.

## Technische Architektur

Mask speichert die Konfiguration aller Content-Elemente in einer einzigen JSON-Datei (`mask.json` oder `config/mask.json` seit Mask 8). Diese Datei beschreibt Felder, Typen, Paletten und die Zuordnung zu Fluid-Templates. Beim Aktivieren oder Aktualisieren generiert Mask daraus die nötigen TCA-Konfigurationen und Datenbank-Felder automatisch.

Die Feldtypen decken den TYPO3-Standard vollständig ab: String, Integer, Float, RichText, Date, DateTime, File (FAL), Inline (IRRE für verschachtelte Strukturen), Select, Checkbox, Radio, Link, Slug, Color Picker, Tab, Palette. Seit Mask 8 kommen JSON-native Felder und eine verbesserte API hinzu.

Fluid-Templates liegen standardmässig unter `fileadmin/templates/mask/` oder in einem konfigurierbaren Pfad. Jedes Content-Element hat ein eigenes Template, optional mit Partials und Layouts. Mask registriert die Elemente im New Content Element Wizard, inklusive Icon und Beschreibung.

Abhängigkeiten sind minimal: Mask benötigt nur den TYPO3 Core (v11, v12, v13 werden aktiv unterstützt). Keine weiteren Extensions nötig. Für den Export-Workflow kommt mask_export als optionale Ergänzung dazu.

## Häufige Probleme und Lösungen

**Feld-Änderungen auf Produktivsystemen.** Wird ein Mask-Feld auf dem Staging-System geändert (Typ, Feldname), aber die Datenbank auf Production nicht aktualisiert, entstehen Fehler. Lösung: mask_export nutzen, damit Konfigurationsänderungen über Git und Deployment-Pipelines laufen. Alternativ: Database Compare im Install Tool nach jedem Deployment.

**Performance bei vielen Content-Elementen.** Websites mit 40+ verschiedenen Mask-Elementen erzeugen eine grosse TCA-Konfiguration. TYPO3 lädt diese bei jedem Backend-Aufruf. Lösung: Elemente sinnvoll gruppieren, nicht genutzte deaktivieren, Backend-Cache aktiv halten. Ab Mask 8 ist die TCA-Generierung deutlich performanter als in früheren Versionen.

**Verschachtelte Elemente (IRRE) und Sortierung.** Inline-Relationen (z.B. Slider-Slides innerhalb eines Slider-Elements) verlieren bei Copy/Paste manchmal die Sortierung. Lösung: Sorting-Feld explizit definieren und im Fluid-Template `<f:for>` mit `sortBy` absichern. In Mask 8.x ist dieses Verhalten stabiler als in 7.x.

## Migration und Versions-Kompatibilität

Mask unterstützt TYPO3 v12 und v13 aktiv. Die aktuelle stabile Version (Mask 8.x) läuft auf beiden LTS-Releases. TYPO3 v11 wird durch Mask 7.x abgedeckt, erhält aber keine neuen Features mehr.

Für Projekte, die noch auf TemplaVoilà oder DCE setzen, bietet Mask einen klaren Migrationspfad. DCE-Elemente lassen sich manuell in Mask überführen: Felder in der Mask-GUI nachbauen, Fluid-Templates anpassen, Daten per SQL-Skript migrieren. Gosign hat diesen Prozess bei Projekten mit 20+ DCE-Elementen durchgeführt und den Aufwand je nach Komplexität auf 2 bis 5 Tage beziffert.

Ab TYPO3 v13 steht zusätzlich das native Content Block API zur Verfügung. Für bestehende Mask-Projekte bedeutet das keine Eile: Mask und Content Blocks koexistieren problemlos. Neue Projekte auf reinem TYPO3 v13 können abwägen, ob der native Ansatz ausreicht oder Mask durch seine GUI und den Export-Workflow Vorteile bietet. Gosign berät projektspezifisch, welcher Ansatz den geringsten Wartungsaufwand langfristig verursacht.

Ein häufig unterschätzter Aspekt ist die Dokumentation. Mask-Elemente sind für Entwickler selbsterklärend (Felder, Typen, Templates), aber Redakteure brauchen Hilfestellungen: Welche Felder sind Pflicht? Welche Bildgrösse ist optimal? Was passiert, wenn das Beschreibungsfeld leer bleibt? Mask unterstützt seit Version 7 Beschreibungstexte pro Feld, die im Backend als Tooltip erscheinen. Gosign erstellt zusätzlich ein internes Redaktionshandbuch pro Projekt, in dem jedes Mask-Element mit Screenshot, Feldbeschreibung und Best Practices dokumentiert ist. Der Aufwand liegt bei einer halben Stunde pro Element, spart aber Rückfragen im Betrieb.

Für die initiale Einrichtung eines Mask-Projekts mit 15 bis 20 Content-Elementen kalkuliert Gosign 3 bis 5 Entwicklungstage, inklusive Fluid-Templates, Backend-Preview und mask_export-Konfiguration. Einzelne neue Elemente im laufenden Betrieb sind in 1 bis 4 Stunden umgesetzt, je nach Komplexität der Verschachtelung und des Template-Designs. Für Agenturen, die Mask als Standard in allen Kundenprojekten einsetzen, lohnt sich eine Bibliothek wiederverwendbarer Mask-Elemente: Basis-Teaser, Akkordeon, Tab-Container und Hero-Banner, die per mask_export als Composer-Paket in neue Projekte eingebunden werden.

--- mask_export TYPO3 - Mask Deployment | Gosign ---
> Extension, die Mask-Content-Element-Konfigurationen als eigenständige TYPO3 Extension exportiert. Macht Mask-Elemente versionierbar und deploybar.

## Ohne mask_export sind Mask-Elemente nicht versionierbar und jedes Deployment ein Risiko

Mask ist der Standard für Custom Content Elements in TYPO3. Aber Mask speichert seine Konfiguration in einer JSON-Datei und generiert Datenbankfelder zur Laufzeit. In einem professionellen Entwicklungsprozess mit mehreren Umgebungen (Lokal, Staging, Production) entsteht dadurch ein Problem: Wie kommen neue Content-Elemente vom Entwicklungsrechner auf den Produktivserver? Manuell im Backend nachklicken? Die mask.json per FTP kopieren und Database Compare ausführen? Beides ist fehleranfällig und nicht reproduzierbar.

mask_export löst dieses Problem. Die Extension exportiert alle Mask-Definitionen als eigenständige TYPO3 Extension mit eigenem ext_tables.sql, TCA-Konfigurationen und Fluid-Templates. Diese Extension wird per Composer installiert, über Git versioniert und per CI/CD deployt, genau wie jede andere TYPO3-Extension. Damit wird Mask Enterprise-tauglich.

## Typische Einsatzszenarien

**Agenturen mit CI/CD-Pipeline.** Agenturen, die TYPO3-Projekte über GitLab CI, GitHub Actions oder Deployer ausrollen, brauchen versionierbare Artefakte. mask_export erzeugt eine Extension, die per `composer require` installiert wird. Jede Änderung an einem Content-Element erzeugt einen neuen Commit, der durch die Pipeline läuft: Lint, Tests, Staging-Deploy, Production-Deploy. Kein manueller Eingriff im Backend nötig.

**Multi-Site-Projekte mit gemeinsamen Elementen.** Konzerne mit 5 bis 20 TYPO3-Instanzen (Landesgesellschaften, Marken, Tochterunternehmen) wollen einheitliche Content-Elemente über alle Sites hinweg nutzen. mask_export erzeugt eine zentrale Extension, die in alle Instanzen eingebunden wird. Änderungen werden einmal gemacht und an alle Sites verteilt. Ohne mask_export müssten Mask-Elemente auf jeder Instanz manuell nachgebaut werden.

**Handoff zwischen Entwicklung und Redaktion.** Entwickler definieren Content-Elemente auf dem lokalen System, exportieren sie per mask_export und committen das Ergebnis. Redakteure arbeiten auf dem Staging- oder Produktivsystem und nutzen die Elemente, ohne die Mask-GUI zu benötigen. Die Mask-Extension selbst kann auf Produktivsystemen sogar deinstalliert werden, wenn nur die exportierte Extension benötigt wird.

## Technische Architektur

mask_export liest die mask.json (oder config/mask.json seit Mask 8) und generiert daraus eine vollständige TYPO3 Extension. Die generierte Struktur enthält: ext_emconf.php (Extension-Metadaten), ext_tables.sql (Datenbank-Definitionen für alle Mask-Felder), Configuration/TCA/Overrides/tt_content.php (TCA-Konfiguration), Resources/Private/Templates/ (Fluid-Templates, kopiert aus dem konfigurierten Mask-Template-Pfad) und optional TypoScript-Setup für Frontend-Rendering.

Der Export-Prozess läuft als TYPO3 CLI-Command: `php typo3/sysext/core/bin/typo3 mask:export`. Das Ergebnis ist ein Verzeichnis, das als Composer-Paket oder als lokale Extension in typo3conf/ext/ eingebunden werden kann. Die Mask-Extension selbst wird nach dem Export nicht mehr benötigt, solange keine neuen Elemente erstellt oder bestehende geändert werden.

Wichtig: mask_export exportiert nur die Definition (Felder, Templates, TCA), nicht die Inhalte (die eigentlichen Texte, Bilder etc. in tt_content). Die Daten bleiben in der Datenbank und werden unabhängig migriert.

## Häufige Probleme und Lösungen

**Export vergessen nach Änderung.** Ein Entwickler ändert ein Mask-Feld auf dem lokalen System, committet aber nur die mask.json, nicht den neuen Export. Auf Staging fehlt dann die TCA-Konfiguration. Lösung: Den mask_export-Befehl in einen Git-Hook (pre-commit) oder in die CI-Pipeline integrieren. Gosign nutzt einen Check in der Deployment-Pipeline, der vergleicht, ob mask.json und der letzte Export synchron sind.

**Fluid-Templates werden nicht mit exportiert.** mask_export kopiert standardmässig die Templates aus dem konfigurierten Pfad. Wenn Templates ausserhalb dieses Pfads liegen (z.B. in einem eigenen Theme-Package), werden sie nicht erfasst. Lösung: Alle Mask-Templates in einem einheitlichen Verzeichnis ablegen und dieses in der Mask-Konfiguration referenzieren.

**Konflikte bei gleichzeitiger Nutzung von Mask und exportierter Extension.** Wenn auf dem Produktivsystem sowohl Mask als auch die exportierte Extension installiert sind, kann es zu doppelten TCA-Registrierungen kommen. Lösung: Auf Systemen, wo Redakteure keine neuen Elemente erstellen, nur die exportierte Extension installieren und Mask deinstallieren. Auf Entwicklungssystemen laufen beide parallel, der Export überschreibt die bisherige Version.

## Migration und Versions-Kompatibilität

mask_export folgt dem Release-Zyklus von Mask: Wenn Mask eine neue TYPO3-Version unterstützt, wird mask_export zeitnah aktualisiert. Aktuell werden TYPO3 v11, v12 und v13 unterstützt. Die exportierte Extension ist mit derselben TYPO3-Version kompatibel wie die Mask-Version, aus der sie generiert wurde.

Für Projekte, die auf TYPO3 v13 mit dem nativen Content Block API wechseln wollen, kann mask_export als Zwischenschritt dienen: Erst Mask-Elemente exportieren (saubere, dateibasierte Struktur), dann die exportierten TCA-Konfigurationen in Content Block-Definitionen übersetzen. Der Aufwand pro Element ist gering (30 bis 60 Minuten), wenn die exportierte Extension als Referenz vorliegt. Gosign bietet diesen Migrationspfad als standardisierten Service an.

Ein oft übersehener Vorteil von mask_export ist die Testbarkeit. Wenn Content-Elemente als eigenständige Extension existieren, lassen sich automatisierte Tests schreiben: TCA-Konfiguration prüfen (sind alle Felder korrekt definiert?), Template-Rendering testen (produziert das Fluid-Template valides HTML?) und Datenbank-Schema validieren (stimmen die Spaltentypen?). In einer CI-Pipeline fangen solche Tests Fehler ab, bevor sie auf Staging oder Production landen. Ohne mask_export wäre diese Art von Testing nur über Integrationstests gegen eine laufende TYPO3-Instanz möglich.

Für Projekte mit 20+ Mask-Elementen empfiehlt Gosign, den Export-Prozess von Anfang an in den Entwicklungs-Workflow einzubauen. Der initiale Setup-Aufwand (CLI-Command in die CI-Pipeline integrieren, Git-Repository für die exportierte Extension anlegen, Composer-Konfiguration anpassen) beträgt etwa 2 bis 4 Stunden. Danach ist der Workflow vollständig automatisiert und jede Mask-Änderung fliesst ohne manuellen Schritt in das Deployment. Gosign liefert bei jedem neuen TYPO3-Projekt eine vorkonfigurierte CI-Pipeline mit mask_export-Integration als Teil des Projekt-Setups, damit der professionelle Workflow vom ersten Tag an steht.

--- Mask Twig TYPO3 - Templates | Gosign ---
> Twig- oder Nunjucks-Templates statt Fluid für Mask Content Elements. Für Frontend-Entwickler, die Twig-Syntax bevorzugen oder bestehende.

## Warum Frontend-Entwickler Twig gegenüber Fluid bevorzugen und wie Mask das ermöglicht

TYPO3 setzt mit Fluid auf eine Template-Engine, die in der PHP-Welt einzigartig ist. Das ist gleichzeitig ihre Stärke und ihr grösstes Problem: Frontend-Entwickler, die aus dem Symfony-, Laravel- oder Node.js-Umfeld kommen, kennen Twig oder Nunjucks. Fluid kennen sie nicht. Der mask_twig_nunjucks_connector schliesst diese Lücke, indem er Mask Content Elements mit Twig- oder Nunjucks-Templates statt Fluid-Templates rendern lässt.

Für Agenturen, deren Frontend-Team mit Twig arbeitet und keine Lust hat, für jedes TYPO3-Projekt eine neue Template-Sprache zu lernen, ist der Connector die pragmatische Lösung. Bestehende Twig-Partials aus Symfony-Projekten oder Nunjucks-Komponenten aus Pattern Libraries lassen sich direkt wiederverwenden.

## Typische Einsatzszenarien

**Agenturen mit Symfony-Backend und TYPO3-Frontend.** Eine Agentur entwickelt ihre Webanwendungen in Symfony und nutzt TYPO3 nur für Content-Management. Das Frontend-Team hat eine umfangreiche Twig-Component-Library aufgebaut. Statt alle Components für TYPO3 in Fluid neu zu schreiben, bindet der Connector die bestehenden Twig-Templates direkt in Mask Content Elements ein. Ein Header-Component, das in Symfony als `header.html.twig` existiert, funktioniert in TYPO3 ohne Änderung.

**Pattern-Library-Integration mit Nunjucks.** Ein Design-Team pflegt eine Pattern Library (z.B. auf Basis von Fractal oder Storybook), die Nunjucks als Template-Sprache nutzt. Der Connector erlaubt es, dieselben Nunjucks-Templates sowohl in der Pattern Library als auch in TYPO3 zu verwenden. Änderungen am Design werden einmal in der Pattern Library gemacht und sind automatisch auf der TYPO3-Website sichtbar.

**Frontend-Entwickler-Onboarding in TYPO3-Projekten.** Ein neuer Frontend-Entwickler startet in einem TYPO3-Projekt. Statt erst Fluid zu lernen (Syntax, Namespaces, ViewHelper-Konzept), schreibt er Twig-Templates, die er bereits beherrscht. Die Lernkurve für das Projekt reduziert sich von 2 bis 3 Tagen auf wenige Stunden.

## Technische Architektur

Der mask_twig_nunjucks_connector funktioniert als Rendering-Bridge zwischen der Mask-Extension und einer alternativen Template-Engine. Mask definiert Custom Content Elements mit Backend-Feldern (Text, Bilder, Relationen). Standardmässig rendert Mask diese Elemente mit Fluid-Templates. Der Connector ersetzt diesen Rendering-Schritt.

Die technische Umsetzung:

- **Twig-Integration**: Der Connector nutzt die PHP-Library `twig/twig` (die gleiche, die Symfony verwendet). Twig-Templates werden im Dateisystem abgelegt, typischerweise unter `Resources/Private/Twig/`. Die Mask-Felder stehen als Template-Variablen zur Verfügung (`{{ data.header }}`, `{{ data.bodytext }}`).
- **Nunjucks-Integration**: Nunjucks ist die JavaScript-Pendant zu Twig (nahezu identische Syntax). Der Connector kann Nunjucks-Templates serverseitig über eine Node.js-Bridge rendern oder clientseitig als JavaScript-Templates ausliefern. Die serverseitige Variante erfordert Node.js auf dem Server.
- **Variable-Mapping**: Mask-Felder werden automatisch auf Template-Variablen gemappt. Einfache Felder (Text, Integer, Float) werden direkt übergeben. FAL-Referenzen (Bilder, Dateien) werden als Objekte mit URL, Titel und Alternativtext übergeben. Relationen werden als Arrays aufgelöst.

Abhängigkeiten: TYPO3 Core, Mask Extension, Composer-Paket `twig/twig` (für Twig) oder Node.js (für serverseitiges Nunjucks). Die Extension ist nicht im offiziellen TER verfügbar, sondern wird über GitHub/Packagist installiert. Die Twig-Integration ist dabei deutlich ausgereifter als die Nunjucks-Variante, weil Twig nativ in PHP läuft und keinen externen Prozess benötigt. In der Praxis nutzen über 90% der Connector-Installationen Twig, nicht Nunjucks.

## Häufige Probleme und Lösungen

**Problem: Twig-Template hat keinen Zugriff auf TYPO3-spezifische Daten.** Fluid-ViewHelper wie `f:uri.page`, `f:translate` oder `f:cObject` existieren in Twig nicht. Ein Twig-Template kann nicht direkt auf den TYPO3-Seitenbaum, Übersetzungen oder andere Content-Elemente zugreifen. Die Lösung: Alle benötigten Daten müssen über das Variable-Mapping bereitgestellt werden. Der Connector kann über eine Konfiguration zusätzliche Daten (aktuelle Sprache, Seiten-URL, globale Settings) in den Template-Kontext injizieren. Für komplexe TYPO3-Funktionalität muss ein eigener Twig-Extension-Point geschrieben werden.

**Problem: Nunjucks-Rendering ist langsam.** Die Node.js-Bridge für serverseitiges Nunjucks-Rendering startet für jeden Request einen Node-Prozess. Das ist bei einzelnen Content-Elementen nicht spürbar, aber bei Seiten mit 10+ Mask-Elementen addieren sich die Rendering-Zeiten. Die Lösung: Einen persistenten Node.js-Worker-Prozess nutzen (statt pro Request einen neuen zu starten) oder auf Twig umsteigen, das nativ in PHP rendert und keinen externen Prozess benötigt.

**Problem: Mask-Update bricht die Template-Variable-Names.** Wenn Mask ein Feld umbenennt oder ein Feld-Typ geändert wird, ändern sich die Template-Variablen. Fluid-Templates zeigen dann leere Stellen, Twig-Templates werfen einen Fehler. Die Lösung: Twig im Strict-Mode betreiben (`strict_variables: true`) und nach jedem Mask-Update die Templates gegen die aktualisierten Variablen testen.

## Migration und Versions-Kompatibilität

Der mask_twig_nunjucks_connector ist ein Community-Projekt mit begrenzter Verbreitung. Die Kompatibilität hängt von der Mask-Extension ab: Mask selbst wird aktiv gepflegt und unterstützt TYPO3 v11 und v12. Der Connector muss bei jedem Mask-Update auf Kompatibilität geprüft werden, da er sich in interne Rendering-Prozesse einklinkt.

Für TYPO3 v13 ist die langfristige Perspektive unklar. Die TYPO3-Community investiert stark in die Weiterentwicklung von Fluid (Fluid 4.0, Standalone Fluid). Gleichzeitig wächst der Druck von Frontend-Entwicklern, die Twig als Template-Standard bevorzugen.

Gosign empfiehlt den Connector für Projekte, in denen das Frontend-Team ausschliesslich mit Twig arbeitet und eine bestehende Component Library mitbringt. Für reine TYPO3-Projekte ohne externe Template-Anforderung bleibt Fluid die bessere Wahl, weil es nativ unterstützt wird, keine zusätzlichen Abhängigkeiten hat und die gesamte TYPO3-ViewHelper-Bibliothek nutzen kann. Der Produktivitätsgewinn durch Twig-Wiederverwendung muss den Wartungsaufwand des Connectors übersteigen - eine Abwägung, die bei jedem Projektstart konkret beziffert werden sollte. Bei weniger als 10 Mask-Elementen lohnt sich der Connector selten; bei 30+ Elementen mit bestehender Twig-Library dagegen fast immer.

--- mathguard TYPO3 - Mathe-CAPTCHA | Gosign ---
> Mathematisches CAPTCHA für TYPO3: Einfache Rechenaufgaben statt Bild-CAPTCHAs. Barrierefrei (Screenreader-kompatibel), ohne externe Dienste,.

## Mathe-CAPTCHAs sind der barrierefreie Spam-Schutz, den die meisten Websites nicht kennen

Spam in Kontaktformularen ist ein Dauerthema. Die populärste Lösung ist Google reCAPTCHA, das aber Nutzerdaten an Google sendet und die DSGVO-Compliance verkompliziert. Bild-basierte CAPTCHAs ("Klicken Sie alle Ampeln an") frustrieren Nutzer und sind für Screenreader unzugänglich. mathguard geht einen anderen Weg: Die Extension zeigt eine einfache Rechenaufgabe ("Was ist 3 + 7?") im Formular an. Menschen lösen das in Sekunden, automatisierte Bots scheitern in der Mehrzahl. Kein externes JavaScript, keine Cookies, keine Datenübertragung an Dritte, vollständig Screenreader-kompatibel.

Für öffentliche Einrichtungen, Hochschulen und Unternehmen mit Barrierefreiheits-Anforderungen (BITV 2.0, WCAG 2.1) ist mathguard eine der wenigen CAPTCHA-Lösungen, die sowohl Spam-Schutz als auch Accessibility garantiert. Die Spam-Reduktion liegt bei 85 bis 95% des eingehenden Bot-Traffics. Im Vergleich: Google reCAPTCHA v3 erreicht ähnliche Werte, überträgt aber bei jedem Seitenaufruf Daten an Google-Server, auch ohne Formular-Interaktion.

## Typische Einsatzszenarien sind Kontaktformulare, Kommentarfunktionen und Registrierungen

Das Standardszenario ist das Kontaktformular auf einer Unternehmenswebsite. Ohne Spam-Schutz landen täglich 20 bis 200 Bot-Einreichungen im Postfach der Redaktion. mathguard fügt ein Rechenfeld hinzu, das im Formular zwischen E-Mail-Feld und Absende-Button platziert wird. Die Rechenaufgabe wird bei jedem Seitenaufruf zufällig generiert, sodass Bots die Lösung nicht vorberechnen können.

Zweites Szenario: Kommentarfunktionen auf Blogs und News-Seiten. Wenn Besucher Kommentare zu Artikeln hinterlassen können, ist Spam unvermeidlich. mathguard schützt das Kommentarformular, ohne dass Besucher ein Google-Account oder eine spezielle App brauchen.

Drittes Szenario: Benutzer-Registrierungen. Wenn eine Website Frontend-Accounts anbietet (z.B. für ein Kundenportal oder einen geschützten Download-Bereich), schützt mathguard das Registrierungsformular vor automatisierten Account-Erstellungen. Die Rechenaufgabe ist die letzte Hürde vor dem Absenden, zusätzlich zum Double-Opt-In.

## Technische Architektur generiert serverseitige Rechenaufgaben mit Session-Validierung

mathguard arbeitet komplett serverseitig. Bei jedem Formular-Aufruf generiert die Extension eine zufällige Rechenaufgabe (Addition, Subtraktion oder Multiplikation mit einstelligen Zahlen). Die korrekte Lösung wird in der PHP-Session gespeichert, nicht im HTML-Code. Das ist entscheidend: Wenn die Lösung als Hidden Field im Formular stehen würde, könnte jeder Bot sie auslesen.

Die Integration in TYPO3-Formulare funktioniert über einen ViewHelper oder ein Fluid-Partial, das in bestehende Formular-Templates eingefügt wird. Für powermail und das TYPO3 Form Framework gibt es Konfigurationsbeispiele, die die Einbindung in 10 bis 15 Minuten ermöglichen.

Die Rechenaufgabe wird als Text dargestellt ("Was ist 5 + 3?"), nicht als Bild. Das macht sie automatisch Screenreader-kompatibel: Vorlese-Software kann die Aufgabe vorlesen, und der Nutzer gibt die Lösung in ein normales Textfeld ein. Es gibt keine visuellen Verzerrungen, keine Farb-Kontrast-Probleme und keine Timeout-Limitierungen.

Für zusätzliche Sicherheit kann mathguard mit einem Honeypot-Feld kombiniert werden: Ein unsichtbares Formularfeld, das von Bots ausgefüllt wird, aber von echten Nutzern ignoriert. Ergänzend lässt sich eine Zeitstempel-Validierung einsetzen: Wenn ein Formular in unter 3 Sekunden ausgefüllt wird, ist es mit hoher Wahrscheinlichkeit ein Bot. Die Kombination aus Mathe-CAPTCHA, Honeypot und Zeitstempel-Check erreicht eine Spam-Reduktion von über 99%.

## Häufige Probleme sind clevere Bots, Session-Verlust und UX-Irritation

Problem eins: Fortgeschrittene Bots, die Rechenaufgaben lösen. Einfache Text-Parsing-Bots können "Was ist 3 + 7?" interpretieren und die richtige Antwort "10" eingeben. Die Lösung: Die Aufgabe als leicht obfuskierten Text darstellen ("Drei plus sieben ergibt?") oder die Aufgabe um einen Kontext erweitern ("Wie viele Beine hat ein Stuhl minus eins?"). mathguard in der Standardkonfiguration nutzt numerische Aufgaben, was für 85 bis 95% der Bots ausreicht.

Problem zwei: Session-Verlust. Wenn die PHP-Session zwischen Formular-Aufruf und Absenden verloren geht (z.B. durch Load-Balancer ohne Session-Stickiness), schlägt die Validierung fehl, obwohl der Nutzer die richtige Antwort eingegeben hat. Die Lösung: Session-Stickiness im Load-Balancer konfigurieren oder die Session-Daten in der Datenbank statt im Dateisystem speichern.

Problem drei: UX-Irritation bei Nutzern. Manche Besucher empfinden eine Rechenaufgabe als herablassend ("Muss ich beweisen, dass ich rechnen kann?"). Die Lösung: Einen freundlichen Hinweis über dem Feld platzieren ("Spam-Schutz: Bitte lösen Sie diese kurze Aufgabe") und die Aufgabe visuell unauffällig in das Formular-Design integrieren.

## mathguard funktioniert mit allen TYPO3-Versionen, weil die Technik minimal ist

Die Extension hat keine tiefen API-Abhängigkeiten zum TYPO3-Core. Session-Handling, Formular-Rendering und Validierung nutzen Standard-PHP- und TYPO3-Funktionen, die sich über Versionen hinweg kaum ändern. mathguard ist mit TYPO3 v10, v11 und v12 kompatibel und wird voraussichtlich auch unter v13 funktionieren, eventuell mit minimalen Anpassungen im ViewHelper. Für Projekte, die komplett ohne Extension auskommen wollen, lässt sich die gleiche Logik als Custom Validator im TYPO3 Form Framework oder als powermail-Finisher in unter einer Stunde nachbauen. Gosign implementiert in eigenen Projekten eine Kombination aus Honeypot, Zeitstempel-Validierung und optionalem Mathe-CAPTCHA als dreistufigen Spam-Schutz, der ohne externe Dienste auskommt und bei über 99% der automatisierten Angriffe wirksam ist. Die Entscheidung, ob das Mathe-CAPTCHA sichtbar ist oder nur als unsichtbarer Fallback greift, treffen wir projektspezifisch basierend auf dem erwarteten Spam-Volumen und den Barrierefreiheits-Anforderungen.

--- md_news_author TYPO3 - News-Autoren | Gosign ---
> Autoren-Extension für GeorgRinger/news. Autoren-Profile, Autoren-Archive und Schema.org Person-Markup. Für News-Sites mit mehreren Redakteuren.

## md_news_author gibt Redakteuren ein Gesicht und Suchmaschinen ein Schema

GeorgRinger/news ist die De-Facto-Standard-Extension für Redaktionssysteme in TYPO3, kennt aber nur ein einfaches Autoren-Textfeld. Für News-Sites mit mehreren Autoren reicht das nicht: Wer ein ernsthaftes Magazin betreibt, braucht Autoren-Profilseiten, strukturierte Biografien und Schema.org/Person-Auszeichnungen für E-E-A-T. Genau diese Lücke schliesst md_news_author von Mehrwert-Digital, und genau deshalb landet die Extension bei fast jedem mittelgrossen TYPO3-Redaktionsprojekt in der composer.json. Seit Google 2022 die E-E-A-T-Richtlinien verschärft hat und Autorenprofile als Rankingsignal bewertet, ist die Extension nicht mehr nur ein Komfort-Feature, sondern ein messbarer SEO-Faktor für jede Redaktion mit mehr als drei Autoren.

## Typische Einsatzszenarien sind Online-Magazine, Fachverlage und Hochschul-Newsrooms

Fachverlage sind die klassische Zielgruppe. Ein juristischer Verlag mit 40 Autoren will für jeden Autor eine eigene Detailseite mit Bild, Kurzbiografie, Fachgebieten, LinkedIn-Profil und einer Liste aller Artikel des Autors - aus SEO-Gründen und weil Google E-E-A-T belohnt. md_news_author liefert das aus einem Datensatz. Zusätzlich erlaubt die Extension, Autoren über Fachgebiete zu filtern, sodass Redakteure bei Themenrecherchen direkt passende Experten finden.

Hochschul-Newsrooms nutzen die Extension, um Mitteilungen aus der Kommunikationsstelle den tatsächlichen Forschern zuzuordnen. Die Pressemeldung erscheint unter dem Namen des jeweiligen Lehrstuhl-Inhabers, verlinkt auf dessen Institutsseite und wird per Person-Schema an Google signalisiert. Für Zitationen und Google Scholar ist das nicht nur Kosmetik, sondern Rankingfaktor. Wir haben md_news_author zum Beispiel in einem Institut für Medizinische Forschung mit 18 Forschungsgruppen implementiert, wo jede Pressemitteilung der beteiligten Arbeitsgruppe und ihren Mitgliedern zugeordnet wird. Die Extension verbindet News-Inhalte mit Forscher-Profilen und schafft damit eine strukturierte Grundlage für wissenschaftliche Reputation im Web.

Ein drittes Szenario sind Corporate-Blogs und Thought-Leadership-Formate, bei denen Vorstände und Führungskräfte als Autoren auftreten. Die Extension trennt sauber zwischen FE-User (Login) und Autor (Profil), sodass Biografien auch für Gastautoren ohne TYPO3-Account gepflegt werden können. Für Unternehmens-Newsrooms mit Ghostwriter-Setup ist diese Trennung entscheidend: Der Kommunikations-Redakteur schreibt den Text, veröffentlicht ihn aber unter dem Namen der Führungskraft, ohne dass diese einen Backend-Login braucht.

## Technische Architektur erweitert GeorgRinger/news per TCA-Overrides

md_news_author ist eine reine Ergänzung zu ext:news. Sie bringt keine eigene Ausgabe-Logik mit, sondern registriert per TCA-Override das Feld "authors" als Beziehung zu einer neuen Tabelle tx_mdnewsauthor_domain_model_author. Jeder Autor ist ein eigenständiger Datensatz mit Vorname, Nachname, Titel, Slug, Biografie, Bild, LinkedIn, X, E-Mail und internen Notizen. Die Relation ist MM-typisiert, sodass ein Artikel mehrere Autoren haben kann und umgekehrt ein Autor an beliebig vielen Artikeln beteiligt ist.

Die Integration in Fluid-Templates läuft über ViewHelper: {author.fullName}, {author.jobTitle}, {author.image} und {author.url}. Für Listen- und Detailansichten liefert die Extension fertige Partials, die sich über das TypoScript-Paket-System überschreiben lassen. Der Slug wird automatisch aus Vor- und Nachname generiert und ist editierbar. Das Routing für Autoren-Detailseiten erfolgt über ein Enhancer-Pattern in der Site-Config, das URLs wie /autor/max-mustermann/ ohne zusätzliche Seitenstruktur ermöglicht.

Schema.org/Person-Markup wird per JSON-LD-ViewHelper generiert und kann in das News-Article-Schema eingebettet werden. Damit erkennt Google-Search den Autor, verknüpft ihn über mehrere Artikel hinweg und fügt ihn ins Knowledge-Graph-Umfeld des Magazins ein. Die ViewHelper-Ausgabe ist kompatibel zum Google-Structured-Data-Testing-Tool und deckt die wichtigsten Person-Attribute ab: name, jobTitle, image, url, sameAs und worksFor.

## Häufige Probleme liegen bei Storage-Pages und Slug-Konflikten

Der klassische Stolperstein ist die Storage-Page-Konfiguration. md_news_author erwartet, dass die Autor-Datensätze auf einer expliziten Sysordner-Seite liegen, die im TypoScript des News-Plugins eingetragen ist. Fehlt der Eintrag, zeigt das Plugin keine Autoren, und die Editoren wundern sich. Beim Setup legen wir den Sysordner unter /Konfiguration/News-Autoren an und referenzieren ihn in der Plugin-Flex-Form. Bei Multi-Site-Installationen muss der Sysordner pro Site separat gepflegt werden, damit Autoren einer bestimmten Marke zugeordnet bleiben.

Ein zweiter häufiger Fehler sind Slug-Kollisionen mit anderen Tabellen. Wenn neben md_news_author auch ext:sf_register oder ein eigenes Personen-Modell verwendet wird, teilen sich beide oft dieselbe URL-Struktur. Wir empfehlen, den Routing-Präfix bewusst auf /autor/ zu setzen und die Slug-Generierung in den Site-Config-YAML einzutragen. Alternativ kann der Routing-Enhancer pro Sprache separat konfiguriert werden, was besonders in mehrsprachigen Installationen mit unterschiedlichen Pfad-Präfixen ("/author/" EN, "/autor/" DE) wichtig ist.

Drittens brauchen Bilder eine definierte Bildergrösse. md_news_author liefert zwar die FAL-Referenz, aber die Cropping-Varianten müssen im TSconfig unter TCEFORM.tx_mdnewsauthor_domain_model_author.image gepflegt werden. Ohne das fällt im Detail-Template der cropping-ViewHelper durch und zeigt unbearbeitete Originalbilder. Wir empfehlen, mindestens drei Cropping-Varianten (square, portrait, landscape) zu definieren und im Fluid-Template responsiv auszuliefern.

## Migration auf TYPO3 v12 verlangt Fluid-Update

Für TYPO3 v11 und v12 ist md_news_author stabil verfügbar. Beim Sprung nach v12 müssen eigene Fluid-Templates auf den neuen Namespace ({namespace md=Mehrwert\\MdNewsAuthor\\ViewHelpers}) und das überarbeitete ViewHelper-System umgestellt werden. Wer von einer alten 2.x-Version kommt, sollte ausserdem die TCA-Overrides prüfen, weil einige Feldnamen umbenannt wurden. Besonders das Biografie-Feld und die Social-Media-Links haben in neueren Versionen zusätzliche Properties bekommen, die in alten Templates ignoriert würden.

In laufenden Projekten migriert Gosign md_news_author typischerweise im selben Arbeitsschritt wie das News-Core-Upgrade und die Schema.org-Auszeichnung. So bleibt die Artikelseite während des Umstiegs konsistent, und die Person-Auszeichnung wird gleich auf die aktuelle Schema.org-Spezifikation gehoben. Im gleichen Zug prüfen wir, ob die Autoren-Profile eine vollständige sameAs-Liste mit verifizierten Social-Media-Accounts enthalten, weil Google diese Verknüpfung für das Knowledge-Graph-Matching nutzt.

--- Mega-Menu TYPO3 - Navigation | Gosign ---
> Mehrspaltige Dropdown-Navigation mit Bildern, Teasern und CTAs. Enterprise-Navigation für komplexe Sitestrukturen. Gosign baut responsive Mega-Menus.

## Komplexe Website-Strukturen mit 200+ Seiten brauchen eine Navigation, die mehr zeigt als Textlisten

Websites mit drei oder mehr Navigationsebenen und über 200 Seiten stossen mit einem Standard-Dropdown-Menü an Grenzen. Besucher klicken sich durch verschachtelte Listen, verlieren die Orientierung und brechen ab. Ein Mega-Menu löst das Problem: Beim Hover oder Klick auf einen Hauptpunkt öffnet sich ein mehrstufiges Panel mit Spalten, Bildern, Teasern und direkten CTAs. Die megamenu-Extension bringt dieses Navigationskonzept als konfigurierbares Content-Element in TYPO3. Redakteure pflegen die Menü-Inhalte (Bilder, Teaser-Texte, Links) im Backend, die Extension rendert das Mega-Menu im Frontend.

Für Enterprise-Websites mit komplexem Produktportfolio, Branchen-Portale mit regionalen Unterbereichen oder Hochschulen mit Fakultätsstrukturen ist ein Mega-Menu nicht optional, sondern Voraussetzung für brauchbare Navigation. Die Herausforderung liegt nicht in der Anzeige, sondern in Barrierefreiheit, Responsive-Verhalten und Performance.

## Typische Einsatzszenarien sind Unternehmenswebsites, E-Commerce und Hochschulportale

Das Standardszenario ist die Unternehmenswebsite mit 5 bis 8 Hauptkategorien und jeweils 10 bis 30 Unterpunkten. Ein Maschinenbauer zeigt unter "Produkte" fünf Produktlinien mit je sechs Produktgruppen, ergänzt durch ein Keyvisual und einen Link zum Produktkonfigurator. Unter "Branchen" erscheinen acht Branchenseiten mit Kurztext und Icon. Das Mega-Menu macht diese Struktur auf einen Blick erfassbar, ohne dass der Besucher sich durch Unterlisten klicken muss.

Zweites Szenario: E-Commerce-Websites mit breitem Sortiment. Ein Online-Shop mit 500+ Produkten in 20 Kategorien zeigt im Mega-Menu die Hauptkategorien mit Unterkategorien, Bestsellern und Aktionslinks. Die visuelle Darstellung mit Produktbildern im Menü steigert die Klickrate auf Kategorie-Seiten um geschätzte 10 bis 20% gegenüber reinen Textlisten.

Drittes Szenario: Hochschulportale mit Fakultäts- und Institutsstruktur. Eine Universität mit 12 Fakultäten und dutzenden Instituten braucht eine Navigation, die sowohl die organisatorische Struktur als auch funktionale Bereiche (Studium, Forschung, Karriere) abbildet. Das Mega-Menu zeigt unter "Studium" die Studiengangsuche, Bewerbungsinformationen und Fristen, unter "Fakultäten" die Institute mit direkten Links zu Mitarbeitern und Forschungsprojekten.

## Technische Architektur kombiniert TYPO3-Seitenbaum mit zusätzlichen Content-Elementen

Die megamenu-Extension erweitert die TYPO3-Navigation um ein Content-Element, das im Seitenbaum als Menü-Konfiguration angelegt wird. Jeder Hauptmenü-Punkt kann ein Mega-Menu-Panel zugeordnet bekommen, das aus Spalten besteht. Jede Spalte enthält Links, Bilder, Rich-Text-Blöcke oder benutzerdefinierte Content-Elemente.

Die Rendering-Logik erzeugt ein HTML-Konstrukt aus verschachtelten Listen und div-Containern, das per CSS als mehrstufiges Panel gestylt wird. Die JavaScript-Komponente steuert das Öffnen und Schliessen (Hover auf Desktop, Klick auf Touch-Geräten) und die Keyboard-Navigation (Tab, Enter, Escape, Pfeiltasten). ARIA-Attribute (aria-expanded, aria-haspopup, role="menu") machen das Menu für Screenreader navigierbar.

Die Performance-Implikation ist relevant: Ein Mega-Menu mit Bildern und Teasern für 8 Hauptpunkte generiert deutlich mehr HTML als ein Standard-Menü. Lazy Loading für Bilder im Mega-Menu ist Pflicht, damit die initiale Seitenladezeit nicht leidet. Gosign empfiehlt, Mega-Menu-Inhalte erst beim Hover per AJAX nachzuladen, wenn das Panel mehr als 5 Bilder pro Hauptpunkt enthält.

## Häufige Probleme betreffen Accessibility, Mobile-Verhalten und Redaktions-Komplexität

Problem eins: Accessibility-Mängel. Viele Mega-Menu-Implementierungen sind mit der Tastatur nicht navigierbar. Tab springt über das gesamte Panel, statt durch die Menüpunkte zu iterieren. Escape schliesst das Panel nicht. Focus-Styles fehlen. Die Lösung: WAI-ARIA Authoring Practices für Navigation Menus befolgen, Keyboard-Handling explizit implementieren und die Focus-Management-Logik mit einem Screenreader testen (NVDA, VoiceOver).

Problem zwei: Mobile-Verhalten. Auf Smartphones wird ein Mega-Menu zum Hindernis, weil das Panel den gesamten Bildschirm einnimmt und der Besucher nicht mehr zum Seiteninhalt zurückkehren kann. Die Lösung: Auf Mobilgeräten das Mega-Menu durch eine Akkordeon-Navigation ersetzen, die die gleichen Inhalte in einer vertikalen Struktur darstellt. Die Umschaltung erfolgt über CSS Media Queries und eine separate JavaScript-Logik für Touch-Geräte.

Problem drei: Redaktions-Komplexität. Redakteure müssen Bilder, Texte und Links für jedes Mega-Menu-Panel pflegen. Ohne klare Richtlinien entstehen inkonsistente Panels: Eins hat vier Spalten mit Bildern, das nächste eine Spalte mit 30 Links. Die Lösung: Eine Content-Guideline, die maximale Spaltenanzahl, Bildformate und Textlängen pro Panel definiert. Gosign liefert diese Guideline als Teil des Mega-Menu-Projekts mit und konfiguriert die Backend-Felder so, dass Redakteure innerhalb der definierten Grenzen arbeiten (z.B. maximal 4 Spalten, maximal 8 Links pro Spalte, Bildformat 16:9).

Ein weiteres Thema ist die SEO-Implikation: Mega-Menus mit vielen Links erhöhen die Gesamtzahl der internen Links pro Seite. Wenn jede Seite 200+ Links im Mega-Menu hat, verdünnt das den Link-Juice, der an einzelne Zielseiten fliesst. Die Lösung: Mega-Menu-Inhalte selektiv laden und nicht alle Panels gleichzeitig im HTML rendern, oder strategisch unwichtige Links mit tabindex="-1" von der Crawler-Navigation ausschliessen.

## TYPO3 v12 erfordert Anpassungen, Custom-Implementierungen sind langfristig wartbarer

Die megamenu-Extension muss bei einem Upgrade auf TYPO3 v12 angepasst werden, da sich die TCA-Konfiguration und das Content-Element-Handling geändert haben. Für v13 liegt noch keine offizielle Unterstützung vor. Gosign baut Mega-Menus in neuen Projekten als Custom-Komponente im Site-Package, die den TYPO3-Seitenbaum als Datenquelle nutzt und die Menü-Konfiguration über Page Properties oder Backend Layouts steuert. Das eliminiert die Abhängigkeit von der Extension und gibt volle Kontrolle über HTML-Struktur, Accessibility und Performance.

--- Microtemplate TYPO3 | Gosign ---
> Micro-Template-Engine für TYPO3: Kleine Textbausteine mit Variablen-Ersetzung. Einfacher als Fluid für simple String-Templating-Aufgaben.

## Fluid ist manchmal Overkill, wenn man nur einen String mit Variablen füllen will

Nicht jedes Template-Problem braucht die volle Fluid-Engine. Wenn eine E-Mail-Betreffzeile "Hallo {name}, Ihre Bestellung #{orderNumber}" lauten soll oder ein Snippet im Footer "Letzte Aktualisierung: {date}" anzeigen soll, ist Fluid mit ViewHelpers, Layouts und Partials architektonischer Overhead. microtemplate liefert eine minimale Template-Engine für TYPO3, die Variablen in Textbausteinen ersetzt. Kein Fluid, kein TypoScript-Objekt-Pfad, kein Template-File. Ein String mit Platzhaltern, ein Array mit Werten, fertig.

Die Extension ist ein Nischenwerkzeug für Entwickler, die in Extensions oder TypoScript-Konfigurationen einfache String-Substitutionen brauchen, ohne die Fluid-Rendering-Pipeline zu starten. Für Redakteure ist microtemplate nicht direkt sichtbar, es arbeitet im Hintergrund als Utility. Der Anwendungsbereich ist bewusst eng: Wo Fluid die richtige Wahl für komplexe Templates mit Schleifen, Bedingungen und Vererbung ist, deckt microtemplate den simplen Fall ab, in dem ein fertiger String an drei Stellen einen dynamischen Wert braucht.

## Typische Einsatzszenarien sind E-Mail-Texte, dynamische Snippets und Konfigurations-Templates

Das häufigste Szenario ist die Generierung von E-Mail-Texten in Extensions. Eine Custom-Extension verschickt Bestätigungs-Mails, und der Betreff und Body sollen konfigurierbar sein, ohne dass der Entwickler Fluid-Templates anlegen muss. microtemplate liest den Text aus einer TypoScript-Konstante ("Bestellung #{orderNumber} bestätigt") und ersetzt die Platzhalter mit den aktuellen Werten.

Zweites Szenario: Dynamische Text-Snippets in TypoScript-Konfigurationen. Ein Seitentitel-Pattern wie "{siteName} - {pageTitle} | {category}" wird über microtemplate aufgelöst. Das ist einfacher als ein COA mit mehreren TEXT-Objekten und stdWrap-Funktionen.

Drittes Szenario: Konfigurations-Templates für Third-Party-Integrationen. Wenn eine Extension einen API-Endpoint konfigurierbar macht ("https://api.example.com/{version}/users/{userId}"), kann microtemplate die Platzhalter vor dem API-Call ersetzen. Das ist besonders nützlich für Extensions, die mehrere API-Umgebungen (Staging, Production) unterstützen und die Endpoint-Struktur nicht im Code, sondern in der TypoScript-Konfiguration pflegen wollen.

Ein viertes Szenario, das in der Praxis gelegentlich auftaucht: Log-Nachrichten mit strukturiertem Format. Eine Extension schreibt "Import von {count} Datensätzen aus {source} abgeschlossen um {time}" ins TYPO3-Log. microtemplate macht den Log-Text konfigurierbar, ohne dass der Entwickler sprintf-Aufrufe mit positionsbasierten Argumenten pflegen muss.

## Technische Architektur ist eine einzige PHP-Klasse mit String-Replacement

microtemplate besteht im Kern aus einer einzigen PHP-Klasse, die str_replace oder preg_replace auf einem Template-String ausführt. Die Platzhalter folgen einer definierbaren Syntax (Standard: {variableName}). Ein assoziatives Array liefert die Werte. Die Klasse hat keine Abhängigkeiten ausser dem PHP-String-Handling.

Die Integration in TYPO3 erfolgt über einen Service oder eine statische Methode, die in anderen Extensions oder TypoScript-Konfigurationen aufgerufen wird. Es gibt kein Frontend-Plugin, kein Backend-Modul und kein Content-Element. microtemplate ist reine Infrastruktur für Entwickler.

Die Performance ist vernachlässigbar: Ein str_replace auf einem 500-Zeichen-String mit 5 Variablen dauert weniger als 0,01ms. Im Vergleich dazu startet die Fluid-Engine für das gleiche Ergebnis einen vollständigen Rendering-Zyklus mit Template-Parsing, ViewHelper-Instanziierung und Caching, was bei 1 bis 5ms liegt. In einem typischen Page-Rendering-Prozess fällt dieser Unterschied nicht auf, aber in Schleifen, die 1.000 E-Mails oder 500 Log-Einträge generieren, wird der Performance-Vorteil messbar.

Die Extension hat keine Datenbank-Tabellen, keine Backend-Module und keine Frontend-Plugins. Sie wird über Composer oder den Extension-Manager installiert und ist sofort einsetzbar. Das macht microtemplate zu einer der leichtgewichtigsten Extensions im gesamten TER (TYPO3 Extension Repository).

## Häufige Probleme sind fehlende Escaping-Logik, Syntax-Konflikte und mangelnde Dokumentation

Problem eins: Kein automatisches HTML-Escaping. microtemplate ersetzt Platzhalter 1:1, ohne den eingesetzten Wert zu escapen. Wenn ein Nutzername HTML-Tags enthält ("<script>alert('XSS')</script>"), wird das direkt in den Output geschrieben. Die Lösung: Werte vor dem Einsetzen manuell escapen (htmlspecialchars) oder microtemplate nur für interne, nicht nutzergenerierte Daten verwenden.

Problem zwei: Syntax-Konflikte mit Fluid. Wenn microtemplate-Platzhalter ({variable}) in einem Kontext verwendet werden, in dem auch Fluid rendert, versucht Fluid die Platzhalter aufzulösen und wirft einen Fehler. Die Lösung: Unterschiedliche Platzhalter-Syntax verwenden (z.B. {{variable}} oder %variable%) oder sicherstellen, dass microtemplate vor Fluid ausgeführt wird.

Problem drei: Mangelnde Dokumentation und Community-Support. microtemplate ist eine Nischen-Extension mit minimaler Nutzerbasis. Bei Problemen gibt es keine aktive Community, kein Issue-Tracking und keine Stack-Overflow-Antworten. Entwickler müssen den Quellcode lesen, um das Verhalten zu verstehen. In der Praxis führt das dazu, dass jeder Entwickler im Team die Extension anders nutzt, weil keine Konventionen dokumentiert sind.

Ein weiteres Thema: Debugging. Wenn ein Platzhalter nicht ersetzt wird, weil der Key im Array nicht exakt mit dem Platzhalter-Namen übereinstimmt (Gross-/Kleinschreibung, Leerzeichen), gibt microtemplate keine Warnung aus. Der Platzhalter bleibt einfach stehen, und der Entwickler sucht den Fehler an der falschen Stelle. Ein Debug-Modus, der nicht aufgelöste Platzhalter loggt, wäre hilfreich, fehlt aber.

## Die Extension ist TYPO3-versionsunabhängig, aber für moderne Projekte gibt es bessere Alternativen

Da microtemplate nur Standard-PHP-Funktionen nutzt, funktioniert die Extension prinzipiell mit jeder TYPO3-Version von v7 bis v13. Die Frage ist eher, ob sie noch nötig ist: Seit PHP 8.0 bietet Named Arguments in Kombination mit sprintf oder str_replace die gleiche Funktionalität ohne Extension. Für komplexere Templates ist Fluid trotz des Overheads die bessere Wahl, weil es Caching, Escaping und Template-Vererbung mitbringt. Gosign setzt microtemplate in Bestandsprojekten nicht aktiv ein und empfiehlt bei Neuimplementierungen, die Funktionalität direkt in der eigenen Extension oder im TypoScript über stdWrap abzubilden.

--- news TYPO3 - Blog & Nachrichten | Gosign ---
> Georg Ringers tx_news: Die meistgenutzte TYPO3-Extension. News, Blog, Pressemitteilungen. Update, Migration, Templating. KI-beschleunigt.

## tx_news ist die Extension, ohne die kein TYPO3-Projekt auskommt

Über 80% aller TYPO3-Installationen setzen tx_news von Georg Ringer ein. Das allein wäre eine beeindruckende Zahl, aber sie unterschätzt die Bedeutung der Extension: tx_news ist nicht nur ein News-Plugin, sondern das Fundament für Blogs, Magazine, Pressebereiche, Event-Listen, Mitarbeiterverzeichnisse und jede andere Art von strukturiertem, chronologischem Content in TYPO3. Die Extension liefert Kategorien, Tags, Media-Assets, SEO-Felder (Canonical, OpenGraph, Schema.org), Paginierung und Import/Export aus einer einzigen, aktiv gepflegten Codebasis. Wer in TYPO3 redaktionelle Inhalte veröffentlicht, kommt an tx_news nicht vorbei.

Gosign hat tx_news in hunderten Projekten konfiguriert, erweitert und migriert. Von Fluid-Templates über Custom ViewHelpers bis zur vollständigen Migration von tt_news. Die Extension ist fester Bestandteil jedes TYPO3-Setups, das wir ausliefern.

## Typische Einsatzszenarien reichen vom Unternehmens-Blog bis zur Pressedatenbank

Das häufigste Szenario ist der Unternehmens-Blog oder das Online-Magazin. Redakteure pflegen Artikel im TYPO3-Backend mit Titel, Teaser, Body, Kategorien, Tags und Medien. Die Listenansicht zeigt Teaser mit Bild, die Detailansicht den vollständigen Artikel. SEO-relevante Felder wie Meta-Description, Canonical URL und OpenGraph-Bild werden pro Artikel gepflegt. Eine typische Installation hat 100 bis 5.000 Artikel und wächst um 2 bis 10 Artikel pro Woche.

Zweites Szenario: Pressemitteilungen für Investor Relations und Unternehmenskommunikation. Börsennotierte Unternehmen und Konzerne veröffentlichen Pflichtmitteilungen über den Pressebereich ihrer Website. tx_news liefert die Chronologie, Kategorisierung (Ad-hoc-Meldung, Quartalsbericht, Personalie) und Download-Funktion für angehängte PDFs. Die Archivfunktion stellt sicher, dass auch Meldungen von vor zehn Jahren noch auffindbar sind.

Drittes Szenario: Event-Listen und Veranstaltungskalender. tx_news kann Start- und Enddaten für Einträge verwalten, was es zum einfachen Veranstaltungskalender macht. Für Vereine, Kultureinrichtungen und Bildungsträger reicht das oft aus, ohne dass eine spezialisierte Event-Extension wie sf_event_mgt nötig ist. Erst wenn Anmeldefunktionen, Teilnehmer-Management oder Ticketing gebraucht werden, stösst tx_news an seine Grenzen.

## Technische Architektur trennt Daten, Konfiguration und Darstellung konsequent

tx_news speichert Artikel als Extbase-Records in der Tabelle tx_news_domain_model_news. Jeder Record enthält Pflichtfelder (Titel, Datetime, Typ) und optionale Felder (Teaser, Body, Author, Tags, Categories, Media, Related News). Die Relationen zu Kategorien und Tags laufen über MM-Tabellen, was performante Filterung ermöglicht.

Die Konfiguration erfolgt über TypoScript: Template-Pfade, Sortierung, Paginierung, Kategorie-Filter, Detail-Seiten-PID und SEO-Einstellungen. Die Extension liefert ein umfangreiches Set an TypoScript-Konstanten, das die meisten Konfigurationen ohne eigenen Code abdeckt. Für Custom-Anforderungen (z.B. ein Slider auf der Startseite, der die drei neuesten News zeigt) gibt es ViewHelper, die in Fluid-Templates genutzt werden können.

Die Fluid-Templates für List, Detail, Category und Date-Menü sind über TypoScript-Pfade überschreibbar. In der Praxis kopiert man die Standard-Templates ins eigene Site-Package und passt HTML-Struktur und CSS-Klassen an das Corporate Design an. Diese Trennung ermöglicht Updates der Extension, ohne dass eigene Anpassungen überschrieben werden.

Die Performance ist bei korrekter Konfiguration gut: Die Listenansicht nutzt den TYPO3-Page-Cache, die Detailansicht cached pro Artikel-UID. Erst bei News-Beständen jenseits von 10.000 Artikeln mit komplexen Kategorie-Filtern und Volltextsuche wird die Performance zum Thema. In solchen Fällen empfiehlt sich ein Suchindex über ke_search oder Solr.

## Häufige Probleme betreffen SEO-Konfiguration, Performance und die tt_news-Migration

Problem eins: Fehlende oder falsche Canonical-URLs. Ohne korrekte Konfiguration ist derselbe Artikel über mehrere URLs erreichbar: über den Kategorie-Pfad, den Archiv-Pfad und den Direkt-Link. Google indexiert alle Varianten als separate Seiten, was zu Duplicate Content führt. Die Lösung: Die Detail-Seiten-PID explizit setzen und die Canonical-URL in den TypoScript-Settings auf die Detail-Seite konfigurieren. Die Extension newscanonical adressiert dieses Problem zusätzlich.

Problem zwei: Performance-Einbrüche bei grossen News-Beständen. Wenn die Listenansicht 5.000+ Artikel durchsuchen muss, steigen die Datenbankabfragezeiten. Die Lösung: Kategorie-basierte Einschränkungen in der TypoScript-Konfiguration, Paginierung mit maximal 20 Artikeln pro Seite und Datenbank-Indizes auf den Kategorie-Relationen.

Problem drei: Migration von tt_news. Die Legacy-Extension tt_news ist seit TYPO3 v8 nicht mehr kompatibel. Die Datenmigration auf tx_news erfordert ein Mapping der Felder (tt_news_cat auf sys_category, Marker-Templates auf Fluid-Templates) und eine URL-Redirect-Strategie, damit bestehende Google-Rankings erhalten bleiben. Gosign nutzt dafür KI-gestützte Template-Analyse: Unser Tooling liest die alten Marker-Templates, identifiziert die verwendeten Felder und generiert Fluid-Templates, die die gleiche Ausgabe produzieren.

## tx_news unterstützt TYPO3 v12 und v13 vollständig

Georg Ringer pflegt tx_news aktiv und stellt bei jedem TYPO3-LTS-Release zeitnah eine kompatible Version bereit. Die aktuelle Serie unterstützt TYPO3 v11, v12 und v13 parallel. Beim Upgrade von v10 oder v11 auf v12 betreffen Breaking Changes vor allem eigene ViewHelpers, die auf die aktuelle Fluid-API umgestellt werden müssen, sowie TypoScript-Konfigurationen, die auf die neue SiteSet-Syntax migriert werden sollten. Die Record-Struktur bleibt stabil, eine Datenmigration ist nicht nötig. Gosign führt tx_news-Upgrades typischerweise im Rahmen des TYPO3-Core-Upgrades durch und prüft dabei Custom-Templates, ViewHelpers und TypoScript-Overrides auf Kompatibilität. Bei Projekten mit umfangreichen Anpassungen (Custom Fields, eigene ViewHelpers, Integration mit Drittsystemen) erstellen wir vor dem Upgrade eine Kompatibilitätsmatrix, die alle Abhängigkeiten dokumentiert und den Migrationsaufwand realistisch einschätzt. KI-gestützte Code-Analyse beschleunigt diesen Prozess erheblich, indem sie alle Stellen im Projekt identifiziert, die von API-Änderungen betroffen sind.

--- news_podcast TYPO3 - Podcast Plugin | Gosign ---
> Podcast-Funktionalität für GeorgRinger/news. RSS-Feed mit iTunes-kompatiblen Tags, Audio-Player-Integration, Episoden-Management. Für Unternehmen.

## news_podcast macht aus einem News-System einen Podcast-Host

Wer in TYPO3 News-Beiträge pflegt und parallel einen Podcast produziert, steht vor einer Entscheidung: Entweder man nutzt einen externen Podcast-Host (Podigee, Podcaster, Anchor) und verlinkt in die Website, oder man liefert den Podcast-Feed direkt aus TYPO3 aus. news_podcast macht Option zwei möglich: Die Extension erweitert GeorgRinger/news um Felder und Fluid-Templates für Audio-Dateien und generiert einen iTunes-kompatiblen RSS-Feed, den Apple Podcasts, Spotify und Google Podcasts ohne Umwege importieren. Für Unternehmen, die ihre Hoheit über Content und Audio-Files behalten wollen, ist das die relevante Architektur-Option. Sie vermeidet Plattform-Abhängigkeit, behält die Nutzungsstatistiken im eigenen Haus und spielt den Content ausserdem im gleichen CMS-Kontext aus, in dem auch die News-Beiträge und das Magazin leben.

## Typische Einsatzszenarien liegen bei Corporate-Podcasts und Bildungsangeboten

Unternehmens-Podcasts sind das häufigste Szenario. Ein mittelständisches Industrieunternehmen produziert alle zwei Wochen eine Folge mit Gästen aus der Branche und will die Episoden im Corporate-Blog einbetten, bei Apple Podcasts einreichen und gleichzeitig SEO-wirksame News-Beiträge mit Transkript und Shownotes veröffentlichen. news_podcast deckt diese drei Bedürfnisse in einem einzigen Record ab, ohne dass die Redaktion in drei verschiedene Systeme pflegen muss. Ein gepflegter Podcast-Datensatz erzeugt automatisch den News-Beitrag, den RSS-Feed-Eintrag und die Schema.org/PodcastEpisode-Auszeichnung.

Ein zweites Szenario sind Hochschulen und Bildungsanbieter. Vorlesungen werden als Audio-Datei aufgezeichnet und auf dem Campus-Server gespeichert. Über news_podcast erscheinen sie als Folgen einer Vorlesungsreihe, mit Kapiteln, Transkript und Literaturhinweisen. Der Feed wird in Apple Podcasts und Spotify eingereicht, und der Zugriff erfolgt direkt über die TYPO3-Website, ohne dass Studierende ein zusätzliches Portal nutzen müssen. Besonders in Zeiten mit hohem E-Learning-Anteil ist das ein spürbarer Vorteil gegenüber Drittanbieter-Plattformen, die zusätzliche Accounts und Tracking mit sich bringen.

Ein drittes Szenario sind Verbände und politische Organisationen, die wöchentliche Interviews oder Pressegespräche als Podcast anbieten. Hier geht es vor allem um Souveränität: Alle Daten liegen in der eigenen Infrastruktur, und die Zielgruppen-Statistik stammt aus dem eigenen Serverlog, nicht aus einem Drittanbieter-Dashboard. Für Organisationen mit hoher Sensibilität gegenüber Tracking-Diensten ist das oft der ausschlaggebende Faktor gegen externe Podcast-Hosts.

## Technische Architektur erweitert das News-Model um Podcast-Attribute

news_podcast registriert einen neuen Feldsatz über ein TCA-Override für tx_news_domain_model_news. Pro Artikel stehen zusätzliche Felder zur Verfügung: Audio-Datei (FAL-Referenz), Dauer, Episode, Staffel, Typ (Full, Trailer, Bonus), Explicit-Flag und Transkript. Über einen weiteren Override wird die News-Kategorie um ein Podcast-Channel-Feld ergänzt, mit iTunes-Category, Cover-Art, Autor, Owner-E-Mail und Sprache.

Der RSS-Feed wird über einen eigenen TYPO3-Controller ausgeliefert. Die Route ist konfigurierbar und erzeugt einen RSS 2.0 mit iTunes-Namespace-Erweiterungen. Jede Folge enthält die Pflicht-Tags für enclosure, duration, episode, episodeType und explicit. Die Validierung erfolgt am Apple-Podcasts-Feed-Validator und am castfeedvalidator.com. Ohne gültige Validierung weigert sich Apple Podcasts, den Feed aufzunehmen, und Spotify zeigt den Kanal nicht in den Suchergebnissen.

Die Frontend-Ausgabe nutzt Fluid-Partials, die sich per Paket-Overlay überschreiben lassen. Die Standard-Ausgabe bettet einen HTML5-Audio-Player ein und rendert die Shownotes im Fliesstext des News-Detail-Templates. Für Transkript-Ausgabe wird ein separater Partial-Bereich verwendet, der über ein Reitersystem oder ein Akkordeon zugänglich gemacht wird. Wer Transkripte aus SEO-Gründen als Vollansicht im DOM halten möchte, überschreibt das Partial und rendert den kompletten Text inline.

## Häufige Probleme betreffen Feed-Validierung, Enclosures und Streaming

Das häufigste Supportthema ist die iTunes-Feed-Validierung. Apple Podcasts lehnt Feeds ab, wenn die Cover-Art nicht den Anforderungen (mindestens 1400x1400px, maximal 3000x3000px, JPEG oder PNG, sRGB) entspricht oder wenn das <enclosure>-Tag keine MIME-Type-Angabe enthält. In der Praxis scheitert die erste Einreichung oft am Cover-Art-Verhältnis, nicht an der eigentlichen Extension.

Das zweite Thema sind Dateigrössen und Streaming. Audio-Dateien in Podcast-Qualität (128 kbit MP3) liegen pro Folge bei 30 bis 60 MB. Wer diese Dateien direkt aus dem TYPO3-Storage ausliefert, überträgt die komplette Last auf den Webserver, was bei tausenden Hörern pro Folge zur Bremse wird. Wir empfehlen, die Audio-Dateien auf ein separates Storage (S3-kompatibel, CDN) auszulagern und per FAL-Remote-Storage einzubinden. Damit bleibt der TYPO3-Server für die Content-Auslieferung zuständig, während die Audio-Last auf der kostengünstigeren Storage-Schicht landet.

Drittens verlangt Google Podcasts eine sprechende, dauerhafte URL pro Folge. Die Extension generiert das automatisch aus dem News-Slug, aber das Routing muss in der Site-Config für den podcast-Controller freigegeben sein, sonst erzeugt TYPO3 Typolink-URLs mit Querystring, die Google Podcasts nicht akzeptiert.

## Migration auf TYPO3 v12 verlangt synchrones News-Core-Upgrade

news_podcast ist für TYPO3 v11, v12 und v13 verfügbar, erfordert jedoch eine kompatible GeorgRinger/news-Version. Beim Sprung auf TYPO3 v12 müssen beide Extensions synchron aktualisiert werden: news auf die v12-Serie und news_podcast auf die passende Major-Version. Die Datenbank-Struktur bleibt stabil, Audio-FAL-Referenzen wandern ohne Umwege mit.

Gosign migriert news_podcast typischerweise als Teil eines Content-Hub-Refactorings. Im gleichen Schritt prüfen wir, ob die Transkripte auf strukturierte Daten erweitert werden können, ob die Cover-Art den aktuellen Apple-Richtlinien entspricht und ob der Feed-Controller mit einem Rate-Limit geschützt ist. Für grössere Podcasts erweitern wir die Extension um ein eigenes Hosts-Modell, sodass Gäste mit Profilseite und Backlink verwaltet werden können. In Kombination mit md_news_author lassen sich so Podcaster und Gäste parallel als Autoren-Profile pflegen, was die Schema.org-Auszeichnung und die interne Verlinkung deutlich verbessert.

--- tt_news Migration TYPO3 | Gosign ---
> Migrations-Extension von tt_news auf GeorgRinger/news. Überträgt Daten, Kategorien, Bilder und Relationen. Der Standard-Migrationspfad.

## Wer noch tt_news nutzt, blockiert jedes TYPO3-Upgrade ab Version 10

tt_news war über ein Jahrzehnt die Standard-Extension für Neuigkeiten, Pressemitteilungen und Blog-Beiträge in TYPO3. Tausende Websites wurden damit gebaut, manche mit Hunderten oder Tausenden von Artikeln. Das Problem: tt_news wurde zuletzt für TYPO3 v7 offiziell unterstützt. Seit TYPO3 v8 (2017) gibt es keinen kompatiblen Release mehr. Wer tt_news noch im Einsatz hat, sitzt auf einer veralteten TYPO3-Version und kann weder Sicherheitsupdates noch neue Features nutzen.

Die offizielle Ablösung ist GeorgRinger/news (kurz: EXT:news), die seit 2012 als Nachfolger entwickelt wird. news ist die meistinstallierte TYPO3-Extension überhaupt (über 250.000 aktive Installationen, Stand 2026) und unterstützt TYPO3 v11, v12 und v13. news_ttnewsimport ist die Migrations-Extension, die den Übergang automatisiert: Artikel, Kategorien, Bilder, Related News und Seitenreferenzen werden von tt_news nach EXT:news übertragen.

## Typische Einsatzszenarien

**TYPO3-Upgrade von v7/v8/v9 auf v12 oder v13.** Der häufigste Fall: Ein Unternehmen betreibt eine TYPO3-Website auf v7 oder v9, mit 500 bis 5.000 News-Artikeln in tt_news. Das geplante Upgrade auf v12 LTS scheitert an tt_news, weil die Extension nicht kompatibel ist. news_ttnewsimport überträgt alle Daten in die EXT:news-Struktur, sodass das Upgrade fortgesetzt werden kann.

**Relaunch mit Bestandsdaten.** Bei einem Website-Relaunch soll das Design komplett neu, aber die bestehenden News-Artikel sollen erhalten bleiben. Die Artikel haben über Jahre SEO-Wert aufgebaut (Backlinks, Indexierung, Rankings). Ein Neuanfang ohne Migration würde diesen Wert vernichten. news_ttnewsimport erhält die Inhalte, EXT:news liefert die moderne Technik, das neue Design wird über Fluid-Templates umgesetzt.

**Multi-Site-Umgebungen mit geteilter News-Datenbank.** Konzerne mit 5 bis 20 TYPO3-Instanzen, die News zentral pflegen und auf allen Sites ausspielen. Die Migration muss koordiniert laufen: Erst die zentrale Datenbank migrieren, dann die Templates auf allen Sites anpassen, dann die alten tt_news-Plugins durch EXT:news-Plugins ersetzen.

## Technische Architektur

news_ttnewsimport ist eine CLI-basierte Extension, die über den TYPO3-Command-Controller läuft. Der Migrationsprozess arbeitet in fünf Schritten. Zuerst werden tt_news-Kategorien (tt_news_cat) in sys_category-Einträge überführt. Die Kategorie-Hierarchie (Parent-Child) wird beibehalten. Dann werden die News-Datensätze selbst migriert: Titel, Teaser, Bodytext, Autor, Datum, Typ (News, Interner Link, Externer Link), Archivdatum und Hidden/Deleted-Status. Im dritten Schritt werden Bilder und Medien von der alten Speicherstruktur (uploads/pics/ oder fileadmin/) in FAL-Referenzen konvertiert. Bildunterschriften und Alternativtexte werden übernommen, sofern vorhanden. Der vierte Schritt migriert Related News (Verknüpfungen zwischen Artikeln) als sys_category-Relationen oder als direkte News-Relationen. Im letzten Schritt werden Content-Elemente auf den News-Seiten aktualisiert: tt_news-Plugins werden durch EXT:news-Plugins ersetzt, TypoScript-Einstellungen werden angepasst.

Die Daten-Tabelle ändert sich von `tt_news` auf `tx_news_domain_model_news`. Die Felder-Zuordnung ist dokumentiert: tt_news.title wird zu tx_news.title, tt_news.short zu tx_news.teaser, tt_news.bodytext zu tx_news.bodytext, tt_news.datetime zu tx_news.datetime. Nicht alle Felder haben ein 1:1-Pendant (z.B. tt_news.image als Komma-separierte Dateiliste vs. EXT:news mit FAL-Referenzen).

## Häufige Probleme und Lösungen

**Bilder fehlen nach der Migration.** tt_news speicherte Bilder als Dateinamen in einem Textfeld (z.B. "bild1.jpg,bild2.jpg"), die Dateien lagen in uploads/pics/. EXT:news nutzt FAL. Wenn die physischen Dateien nicht mehr im erwarteten Verzeichnis liegen (z.B. nach einem Server-Umzug), schlägt die Bild-Migration fehl. Lösung: Vor der Migration prüfen, ob alle referenzierten Bilder physisch vorhanden sind. Fehlende Dateien aus Backups wiederherstellen oder als Platzhalter anlegen.

**Kategorie-Zuordnungen gehen verloren.** tt_news nutzte eigene Kategorie-Tabellen (tt_news_cat), EXT:news nutzt sys_category. Wenn die Migration die Kategorie-IDs nicht korrekt mappt, verlieren Artikel ihre Zuordnung. Lösung: news_ttnewsimport erstellt ein Mapping (alte ID zu neue ID) und aktualisiert alle Referenzen. Dieses Mapping sollte nach der Migration exportiert und archiviert werden, falls spätere Korrekturen nötig sind.

**URL-Struktur ändert sich, SEO-Rankings fallen.** tt_news-Artikel hatten URLs wie `/news/detail/artikeltitel/`. EXT:news erzeugt standardmässig `/news/artikeltitel/`. Lösung: 301-Redirects von den alten auf die neuen URLs einrichten. Bei 1.000 Artikeln ist das manuell nicht machbar. Gosign generiert die Redirect-Map automatisch aus den alten und neuen URL-Strukturen und importiert sie als RealURL/RouteEnhancer-Konfiguration oder als .htaccess-Regeln.

## Migration und Versions-Kompatibilität

news_ttnewsimport unterstützt die Migration nach EXT:news auf TYPO3 v11 und v12. Der empfohlene Ablauf: Erst TYPO3 auf v11 upgraden (falls von v7/v8/v9 kommend, stufenweise), dann news_ttnewsimport ausführen, dann auf v12 oder v13 upgraden. Die Migration auf einer v7-Instanz ist nicht empfohlen, weil EXT:news dort nicht die aktuelle Version nutzen kann.

Für sehr grosse Datenbestände (10.000+ Artikel) empfiehlt Gosign, die Migration auf einem Staging-System durchzuführen und das Ergebnis zu prüfen, bevor Production umgestellt wird. Die Migration selbst dauert je nach Datenmenge zwischen 30 Minuten (500 Artikel) und 4 Stunden (10.000 Artikel mit Bildern). Die Template-Anpassung (Fluid-Templates für die neue EXT:news-Ausgabe) kommt als separater Aufwand dazu und liegt typischerweise bei 2 bis 5 Tagen.

Ein oft unterschätzter Aspekt der tt_news-Migration ist die Suchmaschinen-Kommunikation. Google hat die alten URLs indexiert und bewertet. Wenn nach der Migration 500 URLs ins Leere zeigen (404), verliert die Website Ranking-Positionen. Gosign richtet deshalb nach jeder Migration ein Redirect-Monitoring ein: Eine Woche nach Go-Live werden die Google Search Console Daten auf 404-Fehler geprüft, fehlende Redirects werden nachgetragen und die Indexierung der neuen URLs wird per IndexNow oder manuellen Fetch-Requests beschleunigt.

Für Unternehmen, die die tt_news-Migration als Anlass für einen Content-Audit nutzen wollen, bietet Gosign einen kombinierten Ansatz: Während der technischen Migration werden alle Artikel auf Aktualität, SEO-Qualität und Relevanz geprüft. Veraltete Artikel werden auf die Startseite oder eine thematische Übersichtsseite umgeleitet statt migriert. Das reduziert den Datenbestand, verbessert die Content-Qualität und spart Migrationsaufwand für Artikel, die ohnehin keinen Traffic mehr generieren.

--- newscanonical TYPO3 - Canonical für News | Gosign ---
> newscanonical: Korrekte Canonical Tags für TYPO3 News. Duplicate Content vermeiden. SEO-Optimierung.

## Duplicate Content durch fehlende Canonical Tags kostet TYPO3-News-Seiten Rankings

Ein tx_news-Artikel ist häufig über drei oder mehr URLs erreichbar: über den Kategorie-Pfad (/news/marketing/artikel-titel), über das Archiv (/news/2025/03/artikel-titel) und über einen Direct-Link (/news/artikel-titel). Für Besucher macht das keinen Unterschied, für Google ist es ein Problem. Google sieht drei separate Seiten mit identischem Inhalt und muss entscheiden, welche die "richtige" ist. Ohne ein Canonical-Tag, das auf die bevorzugte URL zeigt, verteilt Google die Ranking-Signale auf alle Varianten und schwächt jede einzelne. newscanonical löst dieses Problem für tx_news, indem es auf jeder News-Detailseite ein Canonical-Tag generiert, das auf die definitive URL zeigt.

Die Extension ist ein fokussiertes SEO-Tool, das genau einen Job macht: Duplicate Content bei tx_news verhindern. Für Websites mit 100+ News-Artikeln kann das den Unterschied zwischen Seite 1 und Seite 3 bei Google bedeuten.

## Typische Einsatzszenarien betreffen News-Websites, Magazine und Pressebereiche

Das Standardszenario ist die Unternehmenswebsite mit einem News- oder Blog-Bereich. Ein Unternehmen veröffentlicht wöchentlich Artikel, die in Kategorien (Produkte, Branchen, Events) eingeordnet sind. Jeder Artikel erscheint in der Kategorieliste und im Gesamtarchiv. Ohne newscanonical indexiert Google jede URL-Variante separat, was bei 500 Artikeln zu 1.500 indexierten Seiten mit Duplicate Content führen kann. Die Google Search Console zeigt das als "Doppelte Seite, von Google gewählte kanonische URL weicht von der vom Nutzer bestimmten ab".

Zweites Szenario: Online-Magazine mit Tag- und Kategorie-basierten Listenansichten. Ein Magazin hat 20 Kategorien und 50 Tags. Jeder Artikel hat mindestens eine Kategorie und zwei bis drei Tags. Die Kombinatorik erzeugt dutzende mögliche URL-Pfade pro Artikel. newscanonical konsolidiert alle Varianten auf eine einzige Canonical-URL.

Drittes Szenario: Pressebereiche von börsennotierten Unternehmen. Pflichtmitteilungen müssen dauerhaft verfügbar sein und dürfen im Google-Index nicht durch Duplicate-Content-Probleme aus den Suchergebnissen fallen. Ein korrektes Canonical-Tag stellt sicher, dass Google die definitive Version indexiert.

## Technische Architektur setzt ein Link-Tag im HTML-Header pro News-Detailseite

newscanonical registriert sich in die Rendering-Pipeline von tx_news und fügt im HTML-Header der Detailseite ein `<link rel="canonical" href="...">` Tag ein. Die Canonical-URL wird aus der konfigurierten Detail-Seiten-PID und dem News-UID berechnet, unabhängig davon, über welchen Pfad der Besucher auf die Seite gelangt ist.

Die Konfiguration erfolgt über TypoScript: Die Detail-Seiten-PID wird als Basis für die Canonical-URL gesetzt. Optionale Parameter wie die URL-Struktur (RealURL oder TYPO3 Site Handling) und die Einbeziehung von Kategorie-Segmenten in die Canonical-URL werden über Konstanten gesteuert.

Die Extension arbeitet als Hook in der tx_news-Rendering-Pipeline, nicht als eigenständiges Plugin. Das bedeutet: Sie hat keine eigene Frontend-Ausgabe und kein eigenes Content-Element. Die einzige sichtbare Auswirkung ist das Canonical-Tag im HTML-Source, das Suchmaschinen lesen, aber Besucher nie sehen.

Für die korrekte Funktion muss die Detail-Seiten-PID in der tx_news-Konfiguration und in der newscanonical-Konfiguration übereinstimmen. Wenn tx_news mehrere Detail-Seiten nutzt (z.B. eine pro Kategorie), muss newscanonical entsprechend konfiguriert werden, damit die Canonical-URL auf die richtige Detail-Seite zeigt.

## Häufige Probleme sind falsche PID-Konfiguration, Konflikte mit dem Core-Canonical und Redirect-Loops

Problem eins: Falsche Detail-Seiten-PID. Wenn die PID in der newscanonical-Konfiguration nicht mit der tx_news-Konfiguration übereinstimmt, zeigt das Canonical-Tag auf eine Seite, die den Artikel gar nicht anzeigen kann. Google ignoriert das Canonical-Tag dann und wählt selbst eine Variante. Die Lösung: PID-Konsistenz prüfen und in der Google Search Console die indexierten Canonical-URLs gegen die konfigurierten URLs vergleichen.

Problem zwei: Konflikte mit dem TYPO3-Core-Canonical. Seit TYPO3 v10 hat der Core eine eigene Canonical-URL-Generierung über die SEO-Erweiterung (seo system extension). Wenn beide aktiv sind, können zwei konkurrierende Canonical-Tags im HTML-Header erscheinen. Die Lösung: Prüfen, ob der Core-Canonical für News-Detailseiten korrekt arbeitet. Wenn ja, ist newscanonical überflüssig und kann deaktiviert werden. Wenn der Core-Canonical die News-Parameter nicht korrekt in die URL aufnimmt, bleibt newscanonical nötig.

Problem drei: Redirect-Loops bei fehlerhafter URL-Konfiguration. Wenn die Canonical-URL auf eine Seite zeigt, die selbst einen Redirect auf eine andere URL enthält, entsteht ein Loop. Das passiert typischerweise nach einer URL-Umstrukturierung, wenn alte Redirects nicht bereinigt wurden. Die Lösung: Alle Redirects für News-URLs prüfen und inkonsistente Einträge entfernen.

## Ab TYPO3 v12 prüft Gosign, ob der Core-Canonical ausreicht

TYPO3 v12 hat den Canonical-Support im Core signifikant verbessert. Die seo system extension generiert Canonical-URLs auf Basis des Site Handling und berücksichtigt Query-Parameter. Für viele tx_news-Konfigurationen reicht der Core-Canonical seit v12 aus, sodass newscanonical nicht mehr nötig ist. Gosign prüft bei jedem TYPO3-Upgrade, ob die Core-Lösung die News-Canonical-URLs korrekt generiert. Wenn ja, empfehlen wir die Deaktivierung von newscanonical, um eine potenzielle Konfliktstelle zu eliminieren. Wenn die News-URLs komplexe Parameter oder Kategorie-Pfade enthalten, die der Core nicht auflöst, bleibt die Extension eine valide Lösung. In jedem Fall empfehlen wir nach dem Upgrade einen systematischen Crawl mit Screaming Frog oder einem vergleichbaren Tool, um alle News-Detailseiten auf korrektes Canonical-Verhalten zu prüfen. Ein einziger falsch konfigurierter Canonical-Tag kann dutzende Seiten aus dem Google-Index verdrängen, was bei Presseseiten oder SEO-relevanten Blog-Artikeln direkten Traffic-Verlust bedeutet.

--- News-Sync TYPO3 | Gosign ---
> News-Synchronisation zwischen TYPO3-Instanzen oder externen Quellen. RSS-Import, API-basierter Content-Sync mit Duplikat-Erkennung.

## Wenn News-Content auf mehreren TYPO3-Instanzen erscheinen soll, reicht Copy-Paste nicht

Organisationen mit mehreren Websites stehen vor einem konkreten Problem: Ein Dachverband veröffentlicht eine Pressemitteilung, und 15 Landesverbände sollen sie auf ihren eigenen TYPO3-Installationen anzeigen. Oder ein Konzern betreibt eine Corporate-Website und fünf Marken-Websites, und bestimmte News sollen auf allen sechs Seiten erscheinen. Manuelles Kopieren ist fehleranfällig, zeitaufwändig und erzeugt Inkonsistenzen. newssync löst das Problem, indem es News-Artikel zwischen TYPO3-Instanzen oder aus externen Quellen automatisch synchronisiert. RSS-Import, API-basierter Sync und Duplikat-Erkennung sind die Kernfunktionen.

Für Organisationen mit einer Multi-Site-Strategie ist Content-Syndication kein Nice-to-have, sondern operativ notwendig. Ohne automatisierten Sync entstehen Content-Silos, die die Redaktion in der Zentrale nicht kontrollieren kann.

## Typische Einsatzszenarien sind Verbands-Netzwerke, Konzern-Websites und News-Aggregation

Das häufigste Szenario ist das Verbandsnetzwerk. Ein Bundesverband veröffentlicht Branchennews, regulatorische Updates und Pressemitteilungen auf seiner TYPO3-Website. Die 16 Landesverbände betreiben eigene TYPO3-Installationen und wollen ausgewählte Artikel automatisch übernehmen. newssync importiert die markierten Artikel per RSS-Feed oder API, erstellt lokale tx_news-Records und ermöglicht den Landesverbänden, Teaser und Kategorien lokal anzupassen.

Zweites Szenario: Konzern-Websites mit einer Content-Hub-Strategie. Die Konzern-Zentrale pflegt einen News-Hub, aus dem Marken-Websites und Länder-Websites selektiv Content beziehen. Die Synchronisation läuft kategorie-basiert: Eine Marken-Website abonniert nur Artikel der Kategorien "Produkt X" und "Innovation", nicht den gesamten News-Feed.

Drittes Szenario: News-Aggregation aus externen Quellen. Ein Branchenportal importiert Pressemitteilungen von Mitgliedsunternehmen automatisch über deren RSS-Feeds. newssync prüft die Feeds in konfigurierbaren Intervallen, importiert neue Artikel und erkennt Duplikate anhand von Titel und Veröffentlichungsdatum.

## Technische Architektur nutzt RSS-Parsing und die TYPO3-Scheduler-Pipeline

newssync arbeitet mit zwei Import-Modi: RSS/Atom-Feed-Import und API-basierter Sync. Im RSS-Modus konfiguriert der Administrator eine Feed-URL, und der Scheduler-Task parst den Feed, extrahiert Titel, Teaser, Body, Datum und Medien-URLs und erstellt tx_news-Records in der lokalen Datenbank. Bilder werden heruntergeladen und als FAL-Dateien lokal gespeichert, damit die Quelle nicht dauerhaft erreichbar sein muss.

Im API-Modus kommuniziert newssync mit einem REST-Endpoint auf der Quell-Instanz. Das ermöglicht selektiveren Import: Statt den gesamten Feed zu importieren, können Artikel nach Kategorien, Tags oder Datum gefiltert werden. Der API-Modus überträgt auch Custom Fields, die im RSS-Format nicht abbildbar sind.

Die Duplikat-Erkennung basiert auf einem konfigurierbaren Schlüssel: standardmässig ein Hash aus Titel und Veröffentlichungsdatum. Wenn ein Artikel mit dem gleichen Schlüssel bereits existiert, wird er übersprungen oder aktualisiert, je nach Konfiguration. Das verhindert, dass derselbe Artikel mehrfach importiert wird, wenn der Sync-Job häufiger läuft als der Feed aktualisiert wird.

Der Sync läuft als TYPO3-Scheduler-Task, typischerweise alle 15 bis 60 Minuten. Die Ergebnisse jedes Laufs werden protokolliert: Anzahl importierter, aktualisierter und übersprungener Artikel. Bei Fehlern (Feed nicht erreichbar, Parser-Fehler) wird eine Warnung ins TYPO3-Log geschrieben.

## Häufige Probleme sind Medien-Import, HTML-Bereinigung und Kategorie-Mapping

Problem eins: Medien-Import schlägt fehl. Bilder und Dokumente, die im Quell-Feed referenziert werden, sind nicht immer direkt downloadbar. Hotlink-Schutz, Authentifizierung oder CDN-basierte URLs können den Download verhindern. Die Lösung: Medien-URLs vor dem Import testen und einen Fallback-Mechanismus implementieren, der fehlende Bilder durch ein Platzhalter-Bild ersetzt.

Problem zwei: Unsauberes HTML im importierten Content. RSS-Feeds enthalten oft HTML, das nicht dem Standard des Ziel-Systems entspricht: Inline-Styles, veraltete Tags, fehlende Absätze. Die Lösung: Eine HTML-Bereinigung (Sanitizing) nach dem Import, die überflüssige Tags und Styles entfernt und den Content in das erwartete Format bringt. TYPO3 bietet dafür die RteHtmlParser-Klasse.

Problem drei: Kategorie-Mapping zwischen Quell- und Ziel-System. Die Kategorien im Quell-Feed stimmen nicht mit den lokalen Kategorien überein. "Pressemitteilung" in der Zentrale heisst "Presse" beim Landesverband. Die Lösung: Ein Mapping-Table in der newssync-Konfiguration, der Quell-Kategorien auf lokale TYPO3-Sys-Categories abbildet.

Ein viertes Problem betrifft die Content-Hoheit: Wenn ein Landesverband einen synchronisierten Artikel lokal ändert und die Zentrale den Originalartikel ebenfalls aktualisiert, überschreibt der nächste Sync die lokale Änderung. Die Lösung: Synchronisierte Artikel als "read-only" markieren und lokale Anpassungen nur in dedizierten Feldern (z.B. lokaler Teaser, regionale Ergänzung) zulassen, die vom Sync nicht betroffen sind.

## Die Extension hat keine gesicherte v12-Unterstützung, Custom-Lösungen sind robuster

newssync wurde für ältere TYPO3-Versionen entwickelt und hat keine offizielle Unterstützung für v12 oder v13. Für Organisationen, die Content-Syndication als Kernfunktion benötigen, empfiehlt Gosign eine massgeschneiderte Lösung: Ein Custom-Importer als Scheduler-Task, der RSS-Feeds oder eine REST-API konsumiert und tx_news-Records erstellt. Der Aufwand für eine Grundimplementierung mit Feed-Import, Duplikat-Erkennung und Medien-Download liegt bei 3 bis 5 Arbeitstagen. KI-gestützte Code-Generierung beschleunigt die Entwicklung des Feed-Parsers und des Mapping-Layers erheblich.

Der Vorteil einer Custom-Lösung: Das Mapping zwischen Quell- und Ziel-Kategorien, die Medien-Verarbeitung und das Fehler-Handling können exakt auf die Anforderungen der Organisation zugeschnitten werden. Ein Bundesverband mit 16 Landesverbänden hat andere Sync-Anforderungen als ein Konzern mit 5 Marken-Websites. Gosign implementiert Content-Syndication-Lösungen auf Basis moderner TYPO3-APIs (PSR-14 Events, Symfony Messenger für Queue-basierte Verarbeitung), die auch bei v13-Upgrades kompatibel bleiben.

--- Audio Player TYPO3 - HTML5 | Gosign ---
> HTML5 Audio Player für TYPO3. Podcasts, Audioguides, Musikstreaming. Custom Player mit Playlist-Support, Fortschrittsanzeige,.

## Podcasts und Audioguides brauchen einen Player, der ohne externe Dienste auskommt

Wer Audio-Inhalte auf einer TYPO3-Website bereitstellen will, steht vor einer unangenehmen Wahl: Entweder ein externer Dienst wie SoundCloud oder Spotify, der Nutzerdaten an Drittserver sendet und die Gestaltung diktiert, oder ein nativer HTML5-Player, der im Browser-Default kaum benutzbar ist. nim_html5audioplayer schliesst diese Lücke. Die Extension liefert einen vollständig in TYPO3 integrierten Audio-Player mit Playlist-Support, Fortschrittsanzeige und Geschwindigkeitssteuerung. Alle Audiodateien bleiben auf dem eigenen Server, kein externer Request verlässt die Seite.

Für Museen, Bildungseinrichtungen und Verlage mit Podcast-Formaten ist das eine harte Anforderung: Audioguides dürfen keine Tracking-Cookies setzen, Schulungsinhalte müssen ohne Internetverbindung im Intranet laufen, und Corporate Podcasts sollen im CI der Organisation erscheinen. nim_html5audioplayer erfüllt alle drei Szenarien mit einem einzigen Content-Element.

## Typische Einsatzszenarien reichen vom Museum bis zum internen Schulungsportal

Das häufigste Szenario sind Audioguides in Museen und Ausstellungen. Besucher scannen einen QR-Code, landen auf einer TYPO3-Seite und hören den Kommentar zu einem Exponat. Der Player startet ohne Autoplay, zeigt die Fortschrittsleiste und erlaubt Geschwindigkeitsanpassung zwischen 0,5x und 2x. Bei einer typischen Ausstellung mit 30 bis 50 Stationen liefert die Playlist-Funktion eine durchgängige Tour, ohne dass Besucher manuell zwischen Seiten navigieren müssen.

Das zweite grosse Einsatzfeld sind Corporate Podcasts. Unternehmen, die ihr internes Wissen als Audio-Serie aufbereiten, brauchen einen Player, der in die bestehende TYPO3-Website eingebettet ist, nicht auf einer externen Plattform lebt. nim_html5audioplayer liefert dafür einen gebrandeten Player mit Episodenliste, Kapitelmarken und Download-Option. Die Redaktion pflegt Episoden wie reguläre TYPO3-Inhalte über das Backend.

Ein drittes Szenario sind Sprachlernportale und E-Learning-Plattformen. Hier kommt die Geschwindigkeitssteuerung besonders zum Tragen: Lernende können Dialoge verlangsamen oder Wiederholungen in erhöhtem Tempo abspielen. In Kombination mit fe_login lassen sich Premium-Audioinhalte hinter einer Anmeldung schützen.

## Technische Architektur setzt auf native HTML5-APIs ohne JavaScript-Framework

nim_html5audioplayer nutzt die HTML5 Audio API des Browsers und rendert die Player-Oberfläche über Fluid-Templates. Es gibt keine Abhängigkeit zu jQuery, React oder einem anderen Framework. Das hält die Ladezeit minimal: Der Player selbst wiegt unter 15 KB (CSS + JS), die Audiodateien werden über FAL (File Abstraction Layer) verwaltet und per Streaming ausgeliefert.

Die Extension registriert ein eigenes Content-Element im TYPO3-Backend. Redakteure wählen Audiodateien aus der FAL-Mediathek, setzen Titel, Beschreibung und optionales Vorschaubild. Die Playlist-Funktion gruppiert mehrere Audio-Einträge in einer sortierbaren Liste. Das Rendering übernehmen Fluid-Templates, die per SiteSet oder eigenes Sitepackage überschrieben werden können.

Für die Fortschrittsanzeige speichert der Player den aktuellen Wiedergabestand im LocalStorage des Browsers. Kehrt ein Besucher zurück, springt der Player an die letzte Position. Das funktioniert ohne Cookies und ohne serverseitige Session.

## Häufige Probleme betreffen Audio-Formate und mobile Browser

Das dominierende Supportthema ist die Audio-Format-Kompatibilität. MP3 funktioniert in allen Browsern, OGG Vorbis nur in Firefox und Chrome, AAC nur in Safari und Chrome. Wer maximale Kompatibilität will, hinterlegt jede Datei als MP3. Wer bessere Qualität bei geringerer Dateigrösse braucht, liefert MP3 als Fallback und Opus als primäres Format aus.

Zweites Problem: Autoplay-Blockierung auf mobilen Geräten. iOS und Android verhindern seit 2018 die automatische Wiedergabe von Audio ohne Nutzerinteraktion. nim_html5audioplayer respektiert diese Browser-Policy und startet Audio ausschliesslich nach einem expliziten Klick. Wer dennoch Autoplay für Hintergrundmusik konfiguriert, erhält auf Mobilgeräten Stille ohne Fehlermeldung.

Drittes Thema ist die Performance bei grossen Playlists. Ab 100 Einträgen in einer einzelnen Playlist wird die DOM-Renderzeit spürbar. Die Lösung: Playlists in thematische Blöcke von 20 bis 30 Einträgen aufteilen und über Kategorien im Backend organisieren.

## Die Extension funktioniert unter TYPO3 v11 und v12, der v13-Status hängt vom Maintainer ab

nim_html5audioplayer wurde ursprünglich für TYPO3 v8 und v9 entwickelt. Die Basis-Funktionalität (HTML5 Audio API, FAL-Integration) ist technisch stabil und läuft unter v11 und v12 ohne grössere Anpassungen. Für TYPO3 v13 existiert aktuell keine offizielle Kompatibilitätserklärung des Maintainers. Die Extension nutzt jedoch keine der in v13 entfernten APIs, sodass eine Migration in den meisten Fällen mit geringem Aufwand möglich ist.

Gosign prüft bei TYPO3-Upgrades, ob die eingesetzten Audio-Extensions noch kompatibel sind, und empfiehlt bei Bedarf Alternativen. Wenn die Extension nicht mehr weiterentwickelt wird, lässt sich die gleiche Funktionalität über ein Custom Content Element mit nativer HTML5 Audio API und Fluid-Templates nachbauen, typischerweise innerhalb von zwei bis drei Entwicklertagen.

--- nimcore TYPO3 - Core Framework | Gosign ---
> NIM Core Framework: Basis-Library für Custom TYPO3 Extensions der NIM-Familie. Abstrakte Klassen, Utility-Funktionen, gemeinsame Konfiguration.

## Ohne zentrale Basis-Library erzeugen Extension-Familien doppelten Code und doppelte Fehler

TYPO3-Agenturen, die mehrere zusammengehörige Extensions entwickeln, stehen vor einem Architekturproblem: Jede Extension reimplementiert Utility-Funktionen wie Konfigurationsauslese, Backend-Module-Registrierung, FAL-Handling und Logging. Bei fünf Extensions bedeutet das fünf Kopien derselben Hilfsfunktionen, fünf Stellen für denselben Bug. nimcore löst dieses Problem als zentrale Basis-Library der NIM-Extension-Familie. Abstrakte Klassen, Utility-Funktionen und gemeinsame Konfiguration liegen an einer einzigen Stelle. Alle abhängigen NIM-Extensions erben von nimcore und müssen nur ihre fachliche Logik implementieren.

Dieses Pattern ist im TYPO3-Ökosystem selten, aber in der Software-Architektur etabliert: Ein Shared Kernel, der horizontale Concerns (Logging, Configuration, Base Models) kapselt, während vertikale Extensions (Audio Player, Galerie, Slider) die Fachlogik übernehmen.

## Typische Einsatzszenarien betreffen Agenturen mit eigenen Extension-Portfolios

Das primäre Szenario ist die Agentur, die ein Set von vier bis zehn eigenen TYPO3-Extensions pflegt. Ohne eine gemeinsame Basis-Library wachsen die Extensions auseinander: Die eine nutzt GeneralUtility::makeInstance, die andere den DI-Container, die dritte hat eine eigene Logger-Konfiguration. nimcore erzwingt einen einheitlichen Standard. Alle NIM-Extensions nutzen dieselben abstrakten Controller-Klassen, dasselbe Exception-Handling und dieselbe Konfigurationsstruktur.

Ein zweites Szenario sind Inhouse-Entwicklungsteams, die ihre TYPO3-Instanz mit mehreren Custom-Extensions erweitern. Statt jede Extension als isoliertes Paket zu behandeln, können Teams eine eigene Core-Library nach dem nimcore-Muster aufbauen: gemeinsame Base-Models, gemeinsame Backend-Module-Klassen, gemeinsame Test-Fixtures. Das reduziert den Wartungsaufwand und senkt die Einstiegshürde für neue Entwickler, die nur eine Architektur lernen müssen.

Ein drittes Szenario ist die Versionierung bei Upgrades. Wenn der TYPO3-Core eine API ändert, die in fünf Extensions genutzt wird, genügt ein einziges Update in nimcore. Alle abhängigen Extensions profitieren sofort, ohne dass jede einzeln angepasst werden muss. Bei einem TYPO3-v12-Upgrade mit sieben NIM-Extensions spart das typischerweise zwei bis drei Entwicklertage.

## Technische Architektur folgt dem Shared-Kernel-Prinzip

nimcore registriert sich als normale TYPO3-Extension und wird über Composer als Dependency in den abhängigen Extensions deklariert. Die ext_emconf.php der NIM-Extensions listet nimcore als required constraint. Beim Installieren einer NIM-Extension wird nimcore automatisch mitgeladen.

Intern liefert nimcore abstrakte Klassen für Controller, Repositories und Models, die das TYPO3-Extbase-Framework korrekt initialisieren. Utility-Klassen kapseln wiederkehrende Aufgaben: TypoScript-Konfiguration auslesen, FAL-Referenzen auflösen, Backend-Toolbars registrieren, Flash-Messages standardisiert ausgeben. Eine zentrale Configuration-Registry ermöglicht es, Extension-spezifische Einstellungen in einem einheitlichen Format zu definieren, das im TYPO3-Backend über ein Settings-Modul zugänglich ist.

Die Test-Infrastruktur ist ebenfalls in nimcore gebündelt: Base-TestCase-Klassen, Fixture-Loader und Mocking-Utilities, die funktionale Tests für Extbase-Extensions vereinfachen. Das senkt die Hürde, Tests zu schreiben, weil das Setup nicht in jeder Extension neu konfiguriert werden muss.

## Häufige Probleme entstehen bei Versions-Konflikten und zirkulären Abhängigkeiten

Das grösste Risiko einer Shared-Kernel-Architektur ist der Lock-Step-Release-Zwang: Wenn nimcore ein Breaking Change einführt, müssen alle abhängigen Extensions gleichzeitig aktualisiert werden. In der Praxis bedeutet das, dass nimcore semantic versioning strikt einhalten muss. Minor-Versionen dürfen keine öffentlichen Interfaces ändern, und Major-Releases brauchen eine Migrationsanleitung.

Zweites Problem: zirkuläre Abhängigkeiten. Wenn Extension A von nimcore abhängt und nimcore einen Service nutzt, der eigentlich in Extension A definiert ist, entsteht ein Zirkel. Die Lösung ist ein sauberes Dependency-Inversion-Prinzip: nimcore definiert Interfaces, die abhängige Extensions implementieren. nimcore selbst kennt keine konkreten Implementierungen.

Drittes Thema ist die Composer-Autoload-Reihenfolge. Bei grossen Installationen mit 30 oder mehr Extensions kann die Reihenfolge des Autoloadings dazu führen, dass nimcore-Klassen noch nicht verfügbar sind, wenn eine abhängige Extension geladen wird. Die Lösung: In der composer.json der Root-Installation nimcore als erstes in der install-order definieren.

## TYPO3 v12 funktioniert, v13-Kompatibilität hängt von der Extbase-Abstraktionsschicht ab

nimcore basiert auf dem Extbase-Framework und ist damit eng an dessen API-Stabilität gekoppelt. Unter TYPO3 v12 läuft die aktuelle Version stabil. Für v13 sind Anpassungen nötig, wenn der TYPO3-Core Extbase-Interfaces ändert oder die Dependency-Injection-Konfiguration umstrukturiert.

Da nimcore ein Nischen-Produkt für die NIM-Extension-Familie ist, hängt die Weiterentwicklung direkt vom Maintainer ab. Teams, die auf nimcore setzen, sollten den Quellcode forken und in einem eigenen Repository pflegen, um nicht von externen Release-Zyklen abhängig zu sein. Gosign empfiehlt bei Custom-Extension-Portfolios generell, die Shared-Kernel-Architektur intern aufzubauen und unter eigener Kontrolle zu halten, statt auf externe Core-Libraries zu vertrauen.

--- OIDC TYPO3 - OpenID Connect SSO | Gosign ---
> OpenID Connect für TYPO3: Azure AD, Keycloak, Okta SSO. Setup, Claim-Mapping & Troubleshooting. KI-beschleunigt.

## Wie TYPO3-Projekte ohne eigenen Identity-Stack an Azure AD, Keycloak oder Okta anschließen

In jedem Unternehmen, das Microsoft 365, Google Workspace oder einen zentralen Keycloak betreibt, ist die Benutzerverwaltung längst entschieden: Alle Mitarbeiter-Accounts leben im IdP, und jede neue Anwendung soll sich dort anbinden, nicht eigene Passwörter verwalten. Die OIDC-Extension für TYPO3 bedient genau dieses Muster, indem sie OpenID Connect als Auth-Protokoll in TYPO3 einbettet und damit Azure AD, Keycloak, Okta, Google Workspace oder Auth0 als IdP nutzbar macht, ohne einen eigenen Shibboleth SP betreiben zu müssen. Zielgruppe sind Unternehmens-Portale, Intranets, Kunden-Login-Bereiche und alle TYPO3-Setups, die in bestehende Enterprise-Identitätslandschaften hineingehören.

## Typische Einsatzszenarien

Ein Maschinenbau-Konzern mit 14.000 Mitarbeitern betreibt sein Mitarbeiter-Intranet auf TYPO3. Der IT-Betrieb hat längst entschieden, dass jede neue Anwendung gegen Azure AD authentifiziert und Multi-Factor-Authentication dort durchsetzt. Die OIDC-Extension holt sich die ID-Tokens aus Azure AD, liest die im Claim enthaltenen Gruppenzuordnungen und erzeugt daraus fe_user-Gruppen. Das Intranet bekommt Single Sign-On, MFA und Conditional Access ohne zusätzliche Infrastruktur, allein durch saubere Konfiguration.

Ein zweites Szenario kommt aus dem Mittelstand: Ein Softwareanbieter mit einem Kunden-Portal auf TYPO3 setzt Keycloak als zentralen Broker ein, weil die eigenen Kunden mit Usernames oder mit Social-Logins wie Google oder GitHub ankommen. Keycloak vereinheitlicht das und spricht nach außen OIDC. TYPO3 nutzt die OIDC-Extension und bekommt Zugriff auf alle Login-Varianten, ohne selbst zu wissen, dass es im Hintergrund Social-Login ist.

Der dritte Fall sind Behörden und Landesverwaltungen, die auf Keycloak-basierte Bürgerkonten wechseln. Ein TYPO3-Portal, über das Bürgerinnen und Bürger Antragsformulare einreichen, kann sich über die OIDC-Extension an den Landes-Keycloak anschließen. Das eID-Attribut aus dem Broker landet direkt im fe_user, und die Authentifizierungsstufe lässt sich über den acr-Claim auswerten.

## Technische Architektur: Authorization-Code-Flow in TYPO3

OpenID Connect ist eine Authentifizierungs-Schicht auf OAuth 2.0, und die OIDC-Extension implementiert genau den Authorization-Code-Flow. Der Ablauf ist einfacher als SAML: TYPO3 leitet den Nutzer mit einem Authorization Request an den IdP um, erhält nach erfolgreicher Anmeldung einen Code zurück, tauscht diesen serverseitig gegen ein ID-Token und validiert die Signatur über die JSON Web Key Set (JWKS) des Providers. Die Claims aus dem ID-Token, typischerweise sub, email, name, groups und roles, werden auf TYPO3-User-Felder gemappt.

Konfiguriert wird die Extension über die TYPO3-Extension-Konfiguration und einen Discovery-Endpunkt, den jeder OIDC-konforme Provider unter /.well-known/openid-configuration anbietet. Die Extension liest aus dieser URL die Token-Endpunkte, die JWKS-URL und die unterstützten Flows automatisch, was manuelle Fehler reduziert. Claim-Mapping erfolgt über eine YAML- oder TypoScript-Konfiguration, die lokale Feldnamen auf Claim-Pfade abbildet.

## Häufige Probleme und Lösungen

Das erste Problem betrifft Claim-Formate: Azure AD liefert Gruppen als Objekt-IDs (GUIDs), nicht als lesbare Namen. Wer einen Claim group_ids erwartet und group_names bekommt, sieht leere Benutzergruppen in TYPO3. Die saubere Lösung liegt in der Azure-AD-Applikation selbst: Im Token-Configuration-Blade lässt sich festlegen, welche Attribute als Claims ausgegeben werden, und zusätzlich kann ein Claim-Transformation-Regelwerk GUIDs auf lesbare Namen übersetzen.

Das zweite Problem ist die Redirect-URI. Jeder OIDC-Client muss beim IdP genau die Redirect-URI registrieren, zu der er nach dem Login geschickt wird. Unterschiede in Groß- und Kleinschreibung, vergessene Trailing-Slashes oder ein Wechsel von HTTP auf HTTPS verursachen sofortige Login-Fehler, die im TYPO3-Log nicht sichtbar sind, weil der Fehler beim IdP auftritt. Gosign konfiguriert für Staging und Production getrennte Clients mit sauberen Redirect-URIs und dokumentiert jede Änderung im Deployment-Prozess.

Das dritte Thema ist Token-Refresh. Wer längere Sessions wünscht, braucht Refresh-Tokens, die der IdP nur ausstellt, wenn der offline_access-Scope beim Login angefordert wurde. Ohne dieses Scope endet die TYPO3-Session, sobald das ID-Token abläuft, meist nach einer Stunde. Die Konfiguration im Extension-Backend muss daher den offline_access-Scope mitgeben und die Token-Refresh-Logik aktivieren.

Ein viertes Problem betrifft das Abmelden. OIDC kennt Front-Channel- und Back-Channel-Logout, und beide sind in der Extension nicht zwangsläufig aktiviert. Wer echtes Single Logout über mehrere Anwendungen hinweg erwartet, muss den entsprechenden End-Session-Endpunkt des Providers konfigurieren und sicherstellen, dass TYPO3 die Logout-URL des IdP beim Session-Ende aufruft. Ohne diese Konfiguration bleibt der Nutzer beim IdP weiter angemeldet, obwohl er sich in TYPO3 ausgeloggt hat.

## Migration und Versions-Kompatibilität

Die OIDC-Extension ist aktuell der empfohlene Standard für TYPO3 v12 und v13, während ältere v11-Projekte häufig noch auf selbstgebaute OAuth-Implementierungen oder shibboleth_auth setzen. Der Migrationspfad von Shibboleth zu OIDC ist gut etabliert, sofern der IdP beides spricht: Keycloak, ADFS und Azure AD können SAML und OIDC parallel bedienen, sodass ein Übergang ohne Big-Bang möglich ist.

Wer von einer rein datenbankgestützten fe_user-Verwaltung migriert, muss die bestehenden Accounts mit einer Matching-Strategie auf die OIDC-Claims abbilden. Die E-Mail-Adresse ist dabei der übliche Anker, reicht aber nicht immer aus, weil sich Mail-Adressen ändern können. Ein Sub-Claim, der als eindeutige persistente Kennung im fe_user hinterlegt wird, ist die robustere Lösung. Gosign übernimmt diese Migrationen inklusive Abgleich bestehender Accounts und einer Übergangsphase, in der beide Auth-Wege parallel funktionieren.

Für Teams, die gerade ein neues TYPO3-Projekt aufsetzen, ist OIDC in den allermeisten Fällen die erste Wahl. Die Konfiguration ist schlanker als bei SAML, der Client-Aufwand geringer, und jeder moderne IdP unterstützt das Protokoll nativ. Ausnahmen sind nur dort gerechtfertigt, wo regulatorische oder föderative Vorgaben explizit SAML erfordern, wie in den bereits genannten Hochschul-Föderationen. In allen anderen Szenarien, insbesondere bei Cloud-basierten IdPs und Enterprise-Integrationen, liefert OIDC den besseren Kompromiss aus Einfachheit, Sicherheit und Wartbarkeit.

--- OpenImmo TYPO3 - Immobilien-Import | Gosign ---
> OpenImmo in TYPO3: Immobilien-XML importieren, darstellen, filtern. Makler-Websites, KI-beschleunigt.

## Warum Makler-Websites ohne OpenImmo-Integration doppelte Arbeit verursachen

Immobilienmakler pflegen ihre Objekte in Verwaltungssoftware wie FlowFact, onOffice, ImmoTool oder JustImmo. Jedes Objekt mit Bildern, Preisen, Flächen und Lagebeschreibungen. Diese Daten sollen auch auf der Website erscheinen - aber ohne manuelle Doppeleingabe. OpenImmo ist der deutsche XML-Standard, der genau diese Brücke schlägt: Die Makler-Software exportiert Objekte als XML, TYPO3 importiert sie automatisch und stellt sie auf der Website dar.

Ohne OpenImmo-Integration pflegt ein Büro mit 40 aktiven Objekten jedes Exposé doppelt - einmal in der Verwaltungssoftware und einmal auf der Website. Bei einer durchschnittlichen Bearbeitungszeit von 15 Minuten pro Objekt sind das 10 Stunden pro Monat allein für Datenpflege, die eine automatisierte Pipeline komplett eliminiert.

## Typische Einsatzszenarien

**Automatisierter Import für Makler-Websites.** Ein Immobilienbüro mit 30 bis 100 aktiven Objekten betreibt seine Website auf TYPO3. Jede Nacht exportiert onOffice alle Objekte als OpenImmo-XML auf einen FTP-Server. Ein TYPO3-Scheduler-Task holt die XML-Datei, parst sie und aktualisiert die Objekte in der Datenbank - neue Objekte werden angelegt, geänderte aktualisiert, verkaufte archiviert. Morgens ist die Website automatisch aktuell.

**Immobilienportale mit Multi-Anbieter-Aggregation.** Eine regionale Immobilien-Plattform aggregiert Objekte von 10 bis 30 Maklern. Jeder Makler liefert seine Objekte im OpenImmo-Format. TYPO3 importiert alle Feeds, ordnet die Objekte den jeweiligen Anbietern zu und zeigt sie auf einer gemeinsamen Plattform mit einheitlicher Suche und Filterung an.

**Bauträger-Websites mit Wohnungsübersicht.** Ein Bauträger verkauft 50 Wohneinheiten in einem Neubauprojekt. Die Verfügbarkeiten und Preise werden in der Verwaltungssoftware gepflegt. Über OpenImmo-Import aktualisiert die TYPO3-Website den Status jeder Einheit automatisch: verfügbar, reserviert oder verkauft. Interessenten sehen in Echtzeit, welche Wohnungen noch frei sind.

## Technische Architektur

Die OpenImmo-Integration in TYPO3 besteht aus vier Komponenten:

- **XML-Parser**: Liest die OpenImmo-XML-Datei und wandelt sie in PHP-Objekte um. Das OpenImmo-Schema definiert über 200 Felder pro Objekt: Kaufpreis, Kaltmiete, Wohnfläche, Grundstücksfläche, Zimmerzahl, Baujahr, Energieausweis, Lagebeschreibung, bis zu 30 Bilder und Grundrisse. Der Parser muss alle Feldvarianten und Versionen des OpenImmo-Schemas unterstützen (1.2.7 bis 1.2.8).
- **Import-Pipeline**: Ein Scheduler-Task oder CLI-Command führt den Import regelmässig aus. Die Pipeline verarbeitet: Datei-Download (FTP, SFTP, lokales Verzeichnis), XML-Validierung, Objekt-Mapping (OpenImmo-Felder auf TYPO3-Datenbankfelder), Bild-Import (Bilder werden in das FAL übertragen), Differenz-Abgleich (nur geänderte Objekte werden aktualisiert).
- **Frontend-Darstellung**: Ein Extbase-Plugin zeigt die Objekte als Liste mit Filterung (Kaufen/Mieten, Preisspanne, Fläche, Zimmerzahl, PLZ-Umkreis) und als Detailansicht mit Bildergalerie, Lagekarte (über maps2 oder leaflet) und Kontaktformular.
- **Exposé-Generierung**: Optional können Objekt-Detailseiten als PDF-Exposé heruntergeladen werden (über web2pdf oder eine eigene PDF-Template-Engine).

Abhängigkeiten: TYPO3 Core, optional maps2/geocoordinates für Kartenanzeige und Umkreissuche, optional web2pdf für PDF-Exposés. Die Datenmenge pro Import kann erheblich sein: Ein Maklerbüro mit 100 aktiven Objekten und je 20 Bildern erzeugt eine XML-Datei von 5 bis 15 MB und einen Bildordner von 500 MB bis 2 GB. Der Import-Prozess muss diese Datenmengen effizient verarbeiten, um die Server-Ressourcen nicht zu blockieren.

## Häufige Probleme und Lösungen

**Problem: Import bricht mit XML-Parsing-Fehlern ab.** Makler-Software exportiert teilweise nicht schema-konformes XML. Fehlende Pflichtfelder, ungültige Zeichenkodierung (ISO-8859-1 statt UTF-8) oder nicht geschlossene Tags führen zum Abbruch. Die Lösung: Einen XML-Preprocessing-Step einbauen, der die Datei vor dem Import validiert, Encoding-Probleme korrigiert und fehlende Pflichtfelder mit Standardwerten füllt. Gosign implementiert diesen Step als eigenständigen Service, der Fehler loggt und den Makler benachrichtigt.

**Problem: Bilder werden nicht korrekt importiert.** OpenImmo-XML referenziert Bilder über relative Pfade oder URLs. Wenn der FTP-Upload die Bilder in einem anderen Verzeichnis ablegt als die XML erwartet, bleiben die Bild-Referenzen leer. Die Lösung: Den Import so konfigurieren, dass Bilder relativ zum XML-Verzeichnis gesucht werden, und einen Fallback auf Dateinamen-Matching implementieren, falls die Pfade nicht stimmen.

**Problem: Gelöschte Objekte bleiben auf der Website sichtbar.** OpenImmo kennt zwei Wege, Objekte als verkauft/gelöscht zu markieren: Über ein Status-Feld im XML oder durch Weglassen des Objekts im nächsten Export. Nicht alle Import-Extensions unterstützen beide Varianten. Die Lösung: Den Import auf Voll-Abgleich konfigurieren - Objekte, die im aktuellen XML-Export fehlen, werden automatisch als "verkauft" markiert oder archiviert.

## Migration und Versions-Kompatibilität

Für OpenImmo in TYPO3 existieren mehrere Extensions: openimmo (TER), femanager_openimmo, und diverse proprietäre Lösungen. Die meisten sind für TYPO3 v10 und v11 verfügbar. Für TYPO3 v12 und v13 ist die Auswahl eingeschränkter, da einige Extensions nicht mehr aktiv gepflegt werden.

Das OpenImmo-Format selbst ist stabil. Version 1.2.7 ist seit Jahren der De-facto-Standard, und alle relevanten Makler-Softwarepakete unterstützen es. Ein Wechsel auf die neuere Version 1.2.8 erfordert Anpassungen am Parser, bringt aber zusätzliche Felder (Energieausweis nach GEG 2024, erweiterte Lagebeschreibungen).

Gosign empfiehlt bei einem TYPO3-Upgrade von v10/v11 auf v12 eine Evaluation der bestehenden OpenImmo-Extension. Falls der Maintainer nicht mehr aktiv ist, lohnt sich der Umstieg auf eine eigenentwickelte Import-Pipeline mit modernem PHP (Typed Properties, Enums für Objekttypen, Event-basierte Architektur). Der Initialaufwand beträgt 5 bis 8 Tage, dafür ist die Pipeline unabhängig von Drittanbieter-Extensions und langfristig wartbar. Die Pipeline kann zudem einfach um zusätzliche Datenquellen erweitert werden: IS24-Schnittstelle, Immowelt-API oder proprietäre XML-Formate von Bauträgern lassen sich als weitere Import-Adapter integrieren, ohne die Gesamtarchitektur zu ändern.

--- Paywall TYPO3 - Content-Monetarisierung | Gosign ---
> Paywall für TYPO3: Bezahlte Inhalte, Abo-Modelle, Zugriffssteuerung. Custom-Entwicklung mit KI, Enterprise-Grade.

## Eine Paywall in TYPO3 ist kein Plug-in-Thema, sondern eine Architektur-Entscheidung

Paid Content in TYPO3 scheint auf den ersten Blick eine banale Frage zu sein: Ein paar Seiten hinter Login, ein Zahlungsdienstleister davor, fertig. In der Praxis entpuppt sich die Aufgabe als eine der anspruchsvollsten im TYPO3-Umfeld. Der Core kennt keinen nativen Paid-Content-Begriff, und die wenigen frei verfügbaren Extensions decken bestenfalls einfache Login-Szenarien ab. Wer ernsthaft Inhalte monetarisieren will - Metered Paywall, Hard Paywall, Freemium, Staffelabos - landet bei einer massgeschneiderten Entwicklung.

Die Zielgruppe sind typischerweise Verlage, Fach-Portale und B2B-Content-Anbieter. Ein Fachverlag mit 4.000 Premium-Artikeln pro Jahr braucht nicht nur eine Zugriffsprüfung, sondern auch einen Abo-Lebenszyklus, einen Kündigungsprozess, eine rechtssichere Darstellung von Widerrufsrechten, eine Schnittstelle zur Finanzbuchhaltung und ein Reporting für die Redaktion. All das will in einer bestehenden TYPO3-Installation abgebildet werden - ohne dass die Redaktion eine neue CMS-Oberfläche lernen muss.

## Typische Einsatzszenarien

Ein erstes Szenario ist die Metered Paywall eines regionalen Verlagshauses. Das Haus veröffentlicht 500 kostenpflichtige Artikel pro Monat und möchte anonymen Leserinnen drei Artikel pro Kalendermonat frei anbieten, bevor die Paywall greift. Die Zählung erfolgt über einen signierten Cookie, der auch ohne Login funktioniert, und die Entsperrung läuft über ein bestehendes Shop-System mit monatlichem Abo-Bezug.

Ein zweites Szenario ist die Hard Paywall im B2B-Fachverlag. Hier gibt es keine Gratis-Artikel, jeder Zugriff setzt einen aktiven Vertrag voraus. Die Herausforderung liegt in der Kombination aus Einzelabo, Firmenabo und IP-basiertem Campus-Zugang. Die TYPO3-Integration muss in Echtzeit prüfen, ob eine Leserin über einen gültigen Vertrag verfügt, und die Ergebnisse performant für die Navigation, die Suche und die RSS-Feeds bereitstellen.

Ein drittes Szenario ist das Freemium-Modell eines Branchen-Portals. Anmelden ist kostenlos, bestimmte Premium-Tools (Whitepaper-Download, Benchmark-Report, interaktiver Rechner) erfordern ein bezahltes Abo. Die Paywall muss pro Content-Element entscheiden, ob Zugriff besteht, und die Zahlungsabwicklung inklusive Rechnungserstellung anbinden.

Ein viertes Szenario ist die Werbekunden-Seite eines Medienhauses. Hier geht es weniger um Endkunden als um Agenturen, die einen Mediadaten-Bereich einsehen wollen. Der Zugang wird typischerweise über Einmalregistrierung plus manuelle Freigabe durch den Anzeigen-Vertrieb gesteuert. TYPO3 bildet den Status der Freigabe im Benutzerprofil ab und schaltet den geschützten Bereich frei, sobald der Status auf "freigegeben" steht.

## Technische Architektur

Eine produktionsreife Paywall in TYPO3 besteht aus mehreren Schichten. An der Front steht eine Middleware, die jede Content-Anfrage daraufhin prüft, ob der Zugriff erlaubt ist. Diese Middleware greift auf eine Zugriffs-Policy zurück, die Abonnements, Einzelkäufe und Freikontingente zusammenführt. Darunter liegt eine Persistenz-Schicht mit Abo-Stammdaten, Zahlungshistorie und Vertragsstatus, die mit dem externen Payment-Provider (Stripe, PayPal, Mollie, Adyen) synchronisiert wird.

Für die Content-Seite gibt es zwei Varianten: Either wird der Content serverseitig getrimmt und nur der für die Leserin zulässige Anteil gerendert, oder der Volltext wird ausgeliefert und die Paywall-Overlay-Schicht per serverseitigem Markup kontrolliert. Die zweite Variante ist gefährlich, weil Browser-Tools den Overlay umgehen können. Professionelle Paywalls arbeiten immer serverseitig.

Die TYPO3-Integration erfolgt über Extbase-Extensions mit eigenen Frontend-Middlewares, TCA-Overrides für den Paywall-Status pro Content-Element und REST-Endpunkten für die Payment-Webhooks. PSR-15-Middlewares sind seit TYPO3 v9 der saubere Platz für Request-Interception.

## Häufige Probleme und Lösungen

Das erste Problem ist die Umgehbarkeit durch Caching. Wer pauschal Page-Cache aktiviert, liefert den Volltext eines kostenpflichtigen Artikels an einen Proxy und ab dann an jeden nicht-autorisierten Leser. Die Lösung ist ein klar getrenntes Caching pro Benutzerrolle oder eine Ausnahme des Paywall-Contents vom Page-Cache.

Das zweite Problem sind Race Conditions im Abo-Lebenszyklus. Beim gleichzeitigen Kündigen und Rechnungslauf entstehen inkonsistente Zustände, wenn die Schreib-Reihenfolge zwischen TYPO3 und Zahlungsdienstleister nicht sauber serialisiert ist. Die Lösung ist ein Event-Store für Abo-Ereignisse mit definierter Quelle der Wahrheit (meist der Payment-Provider) und einem idempotenten Importprozess.

Das dritte Problem ist der Conversion-Knick durch langsame Paywall-Checks. Jede Millisekunde Latenz kostet Abschlüsse. Die Lösung sind asynchrone Zugriffsprüfungen mit einem signierten Session-Token, das teure Datenbankabfragen vermeidet.

Ein viertes Problem sind steuerliche und rechtliche Randbedingungen. Abo-Erlöse sind umsatzsteuerpflichtig, Widerrufsbelehrungen müssen bei Dauerschuldverhältnissen korrekt formuliert werden, und bei grenzüberschreitenden Abonnements greifen unterschiedliche Mehrwertsteuer-Regimes. Die Lösung ist, die Paywall-Architektur von Anfang an mit Finanzbuchhaltung und Rechtsabteilung abzustimmen und die Zahlungsabwicklung auf einen Provider zu stützen, der Steuer- und Rechnungserstellung übernimmt.

## Migration und Versions-Kompatibilität

Weil Paywalls in TYPO3 als Custom-Entwicklungen entstehen, hängt die Versions-Kompatibilität vollständig vom Entwicklungsteam ab. Eine sauber gebaute Paywall-Extension läuft auf TYPO3 v11 bis v13, wenn sie auf PSR-Middlewares, Dependency Injection und moderne Extbase-Konventionen setzt. Probleme entstehen bei Altlasten, die noch auf Hook-basierte Integrationen aus TYPO3 v7/v8 setzen.

Bei Upgrades einer bestehenden Paywall empfiehlt sich eine zweistufige Migration. Im ersten Schritt werden die Payment-API-Clients und die Zugriffs-Middlewares auf moderne TYPO3-Konventionen gehoben, ohne die Business-Logik zu verändern. Im zweiten Schritt folgen die inhaltlichen Anpassungen wie neue Abo-Modelle, veränderte Metered-Zählung oder zusätzliche Zahlungsprovider. Diese Trennung reduziert das Risiko eines Regression-Bruchs deutlich und ermöglicht ein sauberes Testen jedes Schritts in einer Staging-Umgebung.

Gosign baut und modernisiert Paywall-Systeme für Verlage und Content-Anbieter. Die Kombination aus KI-gestützter Code-Generierung für die Payment-API-Anbindung und Senior-Review für Sicherheit, PCI-Compliance und Race-Condition-Vermeidung verkürzt die Time-to-Market spürbar, ohne dass die Architektur-Qualität leidet.

--- PDF.js TYPO3 - PDF-Viewer | Gosign ---
> PDF.js Viewer-Integration für TYPO3. PDFs im Browser anzeigen ohne Plugin, ohne Download. Leichtgewichtiger als pdfviewhelpers, ideal für einzelne.

## PDF.js bettet Mozillas erprobten PDF-Renderer direkt in TYPO3-Seiten ein - die leichtgewichtige Lösung, wenn Redakteure PDFs im Browser zeigen wollen, ohne Download-Zwang und ohne schweres Flipbook-Drumherum

Wenn Besucher ein PDF anklicken, öffnet der Browser es entweder in einem neuen Tab, lädt es herunter oder zeigt ihn an einen externen Viewer weiter. Keine dieser Varianten ist für Redakteure befriedigend, die ein Dokument im Kontext einer Seite präsentieren wollen. PDF.js löst das, indem der Viewer, den Firefox und Chrome intern nutzen, als eigenständiges JavaScript-Modul direkt in die TYPO3-Seite eingebunden wird. Das Ergebnis ist eine konsistente Darstellung auf allen Browsern und Geräten, ohne dass Nutzer ein Plugin installieren oder das Dokument verlassen müssen.

Ein oft übersehener Vorteil: Der Nutzer verlässt die Seite nicht. Während ein geöffnetes PDF im neuen Tab in der Regel das Ende der Session bedeutet, bleibt die Analytics-Verbindung beim eingebetteten Viewer bestehen. Wer misst, wie lange Besucher sich ein Dokument tatsächlich ansehen, kann die Zeit direkt der Content-Seite zurechnen und sieht, welche Dokumente wirklich gelesen werden.

## Typische Einsatzszenarien

Der häufigste Anwendungsfall ist die Einbettung einzelner Dokumente auf Content-Seiten - etwa ein Whitepaper auf einer Produktseite, ein Antragsformular auf einer Service-Seite oder ein Veranstaltungsprogramm neben der Event-Beschreibung. Die Redaktion lädt das PDF in FAL hoch und referenziert es über ein Content-Element, PDF.js rendert es inline. Dabei bleibt das gestalterische CI der Seite erhalten, weil Rahmen, Schatten und Steuerelemente über das eigene Sitepackage-Template gestylt werden.

Der zweite Fall sind Download-Zentren, in denen mehrere PDFs über eine Vorschau präsentiert werden. Statt blinder Datei-Icons sehen Nutzer die erste Seite des Dokuments und können mit einem Klick entscheiden, ob sie weiterlesen oder den vollständigen Download starten. Für Kataloge, Formulare und Merkblätter ist diese Vorschau oft der entscheidende Faktor, warum ein Dokument überhaupt angeklickt wird.

Drittens: barrierearme Bereitstellung von Behörden- und Hochschul-Dokumenten. PDF.js stellt den Textlayer des PDFs zur Verfügung, sodass Screenreader den Inhalt vorlesen können, sofern das PDF korrekt als "Tagged PDF" exportiert wurde.

## Technische Architektur

Für TYPO3 existiert PDF.js in zwei Ausprägungen: als klassische TYPO3-Extension, die die JavaScript-Library ausliefert und ein Content-Element im Backend ergänzt, oder als reine Sitepackage-Integration, bei der die PDF.js-Assets direkt im eigenen Frontend-Build landen. Die Extension-Variante ist für Redakteure komfortabler, weil sie Auswahl, Standard-Zoom und Vorschau-Parameter über das TYPO3-Backend konfigurieren können. Die Sitepackage-Variante ist für Entwickler sauberer, weil sie die Version kontrolliert und in den bestehenden Build-Prozess integriert.

Technisch besteht PDF.js aus zwei Teilen: einem Parser, der die PDF-Datei lädt und in einen internen Objektgraphen zerlegt, und einem Viewer, der diese Objekte in einem Canvas-Element rendert. Beide Teile laufen komplett clientseitig. Der Worker-Ansatz sorgt dafür, dass das Parsen in einem separaten Thread passiert und den Main-Thread nicht blockiert - wichtig für flüssiges Scrollen in umfangreichen Dokumenten.

Die Integration erfolgt über einen TypoScript-Block und ein Fluid-Partial, das ein iframe oder einen Container mit dem Viewer einbindet. Die URL des PDFs wird als Query-Parameter übergeben, die Konfiguration der UI-Elemente (Zoom-Buttons, Seiten-Navigation, Download-Link) erfolgt über den Viewer-Konfigurationsblock von PDF.js.

## Häufige Probleme und Lösungen

Das erste Problem ist Cross-Origin. Wenn das PDF von einer anderen Domain oder einem S3-Bucket geladen wird, blockt der Browser aus Sicherheitsgründen den Zugriff. Die Lösung ist entweder eine korrekte CORS-Konfiguration auf dem File-Server oder ein serverseitiger Proxy über eine TYPO3-Middleware, die das PDF unter derselben Domain ausliefert.

Zweites Problem: Performance bei großen Dokumenten. Ein 200-seitiges Handbuch lädt schnell - der Viewer zeigt auch nur die sichtbaren Seiten. Problematisch wird es, wenn das PDF selbst nicht für das Web optimiert ist und jedes einzelne Bild in voller Druckauflösung eingebettet wurde. Hier hilft nur, das Quelldokument vorab mit Ghostscript oder einem vergleichbaren Tool herunterzurechnen, bevor es ins FAL geht.

Drittes Problem: Barrierefreiheit ohne Textlayer. Wenn das PDF ein reiner Scan ohne OCR ist, bekommen Screenreader keinen Text. Dann bringt PDF.js allein nichts - das PDF muss vorher durch einen OCR-Durchlauf. Für Behörden und öffentliche Stellen ist das keine Option, sondern eine Pflicht nach BITV 2.0 und EN 301 549.

## Migration und Versions-Kompatibilität

PDF.js als Library wird kontinuierlich von Mozilla gepflegt und ist grundsätzlich unabhängig von der TYPO3-Version. Die TYPO3-Extension-Hüllen, die PDF.js integrieren, hinken der Library-Version jedoch häufig hinterher. Wer auf TYPO3 v12 oder v13 aktualisiert, sollte prüfen, ob die verwendete Extension eine kompatible Version hat oder ob ein Umstieg auf die Sitepackage-Integration der bessere Weg ist.

Im direkten Vergleich zu pdfviewhelpers (serverseitige PDF-Generierung) und rflipbook (Flipbook-Effekt) ist PDF.js die Option mit dem geringsten Overhead und der höchsten Browser-Kompatibilität. Für einzelne PDF-Einbettungen ist es fast immer die bessere Wahl als eine schwere Flipbook-Lösung.

Wer PDF.js selbst im Sitepackage einbaut, sollte eine klare Versions-Strategie festlegen. Die Library erhält regelmäßige Sicherheits-Updates, weil PDF-Parser ein historisch beliebtes Angriffsziel sind. Ein jährlicher Update-Rhythmus ist das Minimum, für Behörden und kritische Infrastrukturen eher quartalsweise. Die Integration über npm und einen Frontend-Build-Prozess macht das wesentlich einfacher als die klassische Kopie ins Projektverzeichnis.

Gosign integriert PDF.js als Sitepackage-Komponente oder als TYPO3-Extension, je nachdem, wie viel Kontrolle Redakteure brauchen. Bei Bestandsprojekten mit Legacy-Viewern begleitet Gosign die Migration und sorgt dafür, dass Barrierefreiheit und Ladezeit nicht dem Komfort geopfert werden.

--- pdfviewhelpers TYPO3 - PDF im Browser | Gosign ---
> pdfviewhelpers: PDFs direkt im Browser anzeigen. Setup, Performance & Alternativen , KI-beschleunigt.

## pdfviewhelpers ist die Standard-Antwort, wenn TYPO3 PDFs serverseitig aus Fluid-Templates erzeugen soll - von Rechnungen über Tickets bis zu vollständigen Reports

Hinter dem Namen "pdfviewhelpers" steckt eine häufige Verwechslung. Die Extension rendert keine PDFs im Browser - sie erzeugt PDFs serverseitig aus Fluid-Templates. Redakteure und Entwickler, die eine Lösung für dynamische PDF-Generierung in TYPO3 suchen, landen hier richtig: Rechnungen, Tickets, Bestätigungen, Zertifikate oder Reports werden über dieselben Fluid-ViewHelper gebaut, die auch das Frontend liefern. Das Ziel ist, PDF-Generierung ohne externes Tooling und ohne separaten Layout-Workflow im TYPO3-Stack zu halten.

Dass die Extension damit ein ganz anderes Problem löst als PDF.js oder rflipbook, wird in der Praxis oft erst spät klar. Wer nach "TYPO3 PDF" sucht, landet schnell bei pdfviewhelpers und sollte sich früh fragen, ob Darstellung oder Generierung gebraucht wird. Für die Generierung ist die Extension die technisch solideste Lösung im TYPO3-Umfeld, weil sie auf dem Fluid-Paradigma aufbaut, das Entwickler ohnehin beherrschen.

## Typische Einsatzszenarien

Der klassische Fall sind Formular-Bestätigungen. Ein Kunde füllt auf einer TYPO3-Seite ein Kontaktformular, eine Event-Anmeldung oder ein Angebotsformular aus - pdfviewhelpers generiert aus den Eingaben ein personalisiertes PDF, das per Mail verschickt oder zum Download angeboten wird. Die Vorlage liegt als Fluid-Template im Sitepackage, Redakteure passen Text und Platzhalter an, ohne den Code anfassen zu müssen. Der Vorteil gegenüber einer externen PDF-Dienstleistung ist, dass alle Daten die TYPO3-Umgebung nie verlassen - relevant für Datenschutz und DSGVO-Compliance.

Der zweite typische Einsatz sind automatisch erzeugte Bescheinigungen. Schulungsanbieter, Kammern und Verbände lassen Teilnahmebescheinigungen, Zertifikate oder Mitgliedsausweise aus Datenbankinhalten generieren. Die Extension kombiniert Extbase-Daten mit Layoutvorlagen und liefert ein fertiges Dokument aus. Ein großer Vorteil: Die Vorlage ist versioniert, im Git nachvollziehbar und nicht an eine einzelne Person gebunden, die das letzte Word-Template besitzt.

Dritter Fall: Reports und Listen. Controlling-Abteilungen exportieren aus einer TYPO3-gepflegten Datenbank einen monatlichen Bericht - etwa als Export eines internen Dashboards, einer Produktliste oder einer Lagerliste - und erhalten ein formatiertes PDF mit Kopf, Fuß und Paginierung.

## Technische Architektur

pdfviewhelpers basiert auf TCPDF, der etablierten PHP-Library für PDF-Erzeugung, und setzt deren Funktionen in Fluid-ViewHelper um. Entwickler schreiben statt TCPDF-PHP-Code ein Template, in dem Elemente wie "pdf:document", "pdf:page", "pdf:text" und "pdf:image" als Tags erscheinen. Das entspricht exakt der Denkweise, die Fluid-Entwickler aus dem Frontend kennen.

Die Extension wird per Composer installiert, TCPDF wird als Dependency mitgezogen. Die Templates liegen im Sitepackage unter Resources/Private/Templates/Pdf und werden über einen eigenen Controller oder direkt aus einem Extbase-Action aufgerufen. Für Variablen-Injection nutzt pdfviewhelpers dieselben Mechanismen wie reguläre Fluid-Views, wodurch sich Datenquellen und Business-Logik sauber trennen lassen.

Die Konfiguration erfolgt über TypoScript und über die Extension-Konfiguration im Install-Tool, wo Defaults für Papierformat, Schriftarten und Ränder hinterlegt werden. Wer eigene TrueType-Schriften einsetzen will, muss sie nach dem TCPDF-Verfahren konvertieren und in Resources/Private/Fonts/ ablegen.

## Häufige Probleme und Lösungen

Das häufigste Problem ist die Schrift-Darstellung. TCPDF unterstützt nicht jede Schriftdatei out-of-the-box, besonders nicht die aktuellen Variable Fonts oder Web-Fonts im WOFF2-Format. Umlaute, Sonderzeichen und Diakritika werden dann durch Fragezeichen oder Kästchen ersetzt. Die Lösung: Font vorab mit dem TCPDF-Tool "tcpdf_addfont.php" konvertieren und die Unicode-Range prüfen. Für mehrsprachige Dokumente mit kyrillischen oder asiatischen Zeichen lohnt sich der Einsatz einer Font-Familie mit umfassender Glyph-Abdeckung wie Noto Sans.

Zweites Problem: komplexe Layouts. Sobald ein Dokument mehrspaltige Inhalte, schwebende Grafiken oder dynamische Umbrüche braucht, stößt TCPDF an Grenzen. Paginierung und Footer laufen unter Umständen nicht korrekt synchron. Pragmatische Lösung: Layout auf einen einfachen, Report-artigen Aufbau reduzieren und komplexe Grafiken als vorgefertigte Bilder einbinden. Wenn die Anforderungen wirklich typographisch hoch sind, ist eine Alternative wie Headless Chrome mit HTML-zu-PDF-Konvertierung oft die bessere Wahl.

Drittes Problem: Performance bei großen Dokumenten. Ein 100-Seiten-Bericht mit vielen Bildern kann den PHP-Prozess mehrere Sekunden blockieren. Die Lösung liegt in der Queue-Verarbeitung: PDF-Generierung aus dem Request-Lifecycle herauslösen, als Background-Job mit EXT:scheduler oder einer Queue-Extension ausführen und dem Nutzer einen Download-Link per Mail zuschicken.

## Migration und Versions-Kompatibilität

pdfviewhelpers wird kontinuierlich gepflegt und ist mit TYPO3 v11, v12 und v13 kompatibel. Bei Upgrades ist vor allem auf den PHP-Versionssprung zu achten: Ältere TCPDF-Versionen haben mit PHP 8.2 und 8.3 Kompatibilitätsprobleme, insbesondere bei deprecated-Warnings. Die Lösung ist meist ein Update der pdfviewhelpers-Version, die die kompatible TCPDF-Version nachzieht.

Wer noch ein selbstgeschriebenes TCPDF-Setup aus TYPO3-Zeiten vor v9 betreibt, hat mit der Migration auf pdfviewhelpers die Chance, PDF-Layouts aus PHP-Code in wartbare Fluid-Templates zu überführen. Das zahlt sich mittelfristig aus, weil Redakteure einfache Anpassungen selbst machen können, statt immer Entwickler-Zeit zu blockieren.

Für Neueinstiege lohnt sich ein Blick auf die Kombination aus pdfviewhelpers und Headless-Chrome-Alternativen wie wkhtmltopdf oder Gotenberg. Für reine Formular-PDFs und einfache Reports ist pdfviewhelpers die schnellste und stabilste Wahl. Sobald aber typographisch anspruchsvolle Layouts mit Web-Fonts, Spalten und Hintergrund-Grafiken ins Spiel kommen, spielt eine HTML-basierte Pipeline ihre Stärken aus. Die Entscheidung sollte früh im Projekt fallen, weil ein späterer Wechsel der Pipeline einen kompletten Template-Neubau erfordert.

Gosign implementiert pdfviewhelpers, migriert Legacy-TCPDF-Setups und berät zu Alternativen für komplexe Layouts. Die Kombination aus TYPO3-Erfahrung und KI-gestützter Template-Generierung verkürzt die Umsetzung in der Regel um mehr als die Hälfte.

--- personnel TYPO3 - Mitarbeiter-Verzeichnis | Gosign ---
> TYPO3 Extension für Mitarbeiter-Verzeichnisse. Teams, Abteilungen, Kontaktdaten, Profilbilder. Gosign baut daraus professionelle Team-Seiten.

## personnel organisiert Mitarbeiter-Verzeichnisse als eigenes Datenmodell

Team-Seiten, Ansprechpartner-Listen und Abteilungs-Verzeichnisse sind auf Unternehmenswebseiten Standard, lassen sich aber nicht sinnvoll als Content-Element pflegen. Wer 50 Mitarbeiter mit Name, Funktion, Foto, Telefon, E-Mail, LinkedIn, Abteilung und Standort verwaltet, braucht ein eigenes Datenmodell. Die Extension personnel bringt genau das: Eine saubere Tabelle für Personen, verbunden mit Abteilungen und Standorten, ausgeliefert über konfigurierbare Fluid-Templates. Auf jedem mittelgrossen TYPO3-Projekt mit Unternehmensauftritt taucht diese Anforderung wiederholt auf, und personnel ist eine der etablierten Lösungen dafür. Alternativen wie tt_address greifen oft zu kurz, weil ihnen die Abteilungs-Struktur, die Filter-Logik und die saubere FE-Integration fehlen.

## Typische Einsatzszenarien sind Kanzleien, Agenturen und Hochschulen

Anwaltskanzleien sind ein klassischer Use Case. Eine Kanzlei mit 30 Rechtsanwälten und 10 Paralegals braucht eine Team-Seite mit Filterung nach Fachgebieten (Arbeitsrecht, Steuerrecht, Erbrecht), nach Standorten (Berlin, München, Frankfurt) und nach Funktion (Partner, Associate, Referendar). personnel liefert das Datenmodell, und die Extension lässt sich mit wenigen Fluid-Anpassungen zu einem vollwertigen Kanzlei-Verzeichnis ausbauen. Jedes Anwalts-Profil enthält zusätzlich die Zulassung, die Mitgliedschaften und die publizierten Fachartikel, sodass Mandanten auf einen Blick die passende Ansprechperson finden.

Agenturen und Beratungshäuser nutzen personnel für Team-Seiten mit Kurzbiografien, Fachgebieten und Kontaktlinks. Hier ist weniger die Filterung entscheidend als die Darstellung: Grosse Portraits, Zitate, LinkedIn-Buttons und interne Verlinkung auf Case-Studies, an denen die Person beteiligt war. Die Team-Seite wird zum Schaufenster, und personnel liefert das Datenmodell, ohne dass jeder Mitarbeiter ein eigenes Content-Element bekommt.

Hochschulen und Forschungseinrichtungen haben eine andere Anforderung: Mitarbeiter sind oft mit Instituten, Lehrstühlen und Forschungsprojekten verknüpft. personnel wird dann zum Stamm-Datenmodell, das von News-Artikeln, Publikationslisten und Veranstaltungen referenziert wird. Die Person erscheint nicht nur auf einer Team-Seite, sondern auch als Autor in Publikationen und als Ansprechpartner an Forschungsprojekten. Damit wird die Extension zur zentralen Personen-Datenbank, die von mehreren Sub-Extensions gleichzeitig genutzt wird und über Jahre hinweg konsistente Profile liefert.

## Technische Architektur ist Extbase-basiert mit Relationen zu Abteilung und Standort

personnel definiert drei zentrale Tabellen: tx_personnel_domain_model_personnel, tx_personnel_domain_model_department und tx_personnel_domain_model_location. Eine Person ist über foreign_field oder MM-Relation mit einer oder mehreren Abteilungen verbunden, zusätzlich mit einem Standort. Das Datenbankschema bildet damit eine typische Matrix-Organisation ab.

Die Felder einer Person decken die Standard-Attribute ab: Titel, Vorname, Nachname, Funktion, Kurzbeschreibung, Telefon, Mobil, Fax, E-Mail, Adresse, Profilbild (FAL), Social-Media-Links. Über TCA-Overrides lassen sich zusätzliche Felder wie Fachgebiete, Zertifikate oder Sprachen ergänzen, ohne die Extension zu forken.

Das Plugin rendert über Fluid-Templates aus dem EXT-Verzeichnis. Die Standard-Varianten sind Liste, Detail und Filter-Ansicht. Wer auf Gridsystemen wie CSS-Grid oder Flexbox aufbaut, überschreibt das Listen-Template im eigenen Paket. Für Filterung und Suche nutzt die Extension Extbase-Repositories mit Querybuilder-Filtern, die sich in TypoScript konfigurieren lassen. Eine typische Gosign-Implementierung bietet im Frontend eine Volltextsuche über Name und Funktion kombiniert mit Select-Filtern für Abteilung und Standort, sodass Nutzer aus 200 Mitarbeitern den richtigen Ansprechpartner in wenigen Klicks finden.

## Häufige Probleme betreffen DSGVO, Bildrechte und Mehrsprachigkeit

Das erste und wichtigste Supportthema ist die DSGVO. Mitarbeiterdaten sind personenbezogen, und die Veröffentlichung erfordert entweder eine Einwilligung oder ein berechtigtes Interesse. Wer mit Fotos, Durchwahlen und privaten Mobilnummern arbeitet, braucht einen sauberen Prozess: Einwilligung dokumentieren, On-Off-Schalter pro Person, automatisches Entfernen nach Ausscheiden. personnel liefert dafür kein Auditlog ab Werk, aber der Workflow lässt sich mit eigenen Formularen und einem zusätzlichen Consent-Feld abbilden. Beim Austritt aus dem Unternehmen sollte der Datensatz nicht einfach gelöscht werden, sondern über einen Soft-Delete-Mechanismus deaktiviert bleiben, damit alte News-Beiträge weiterhin korrekt auflösen.

Das zweite Thema sind Bildrechte. Profilbilder liegen im FAL und werden über Varianten pro Darstellung ausgeliefert. Wichtig ist, dass die Copyright-Angabe und die Einwilligung des Mitarbeiters dokumentiert sind, besonders wenn das Bild auch als Teaser in News oder auf Social Media verwendet wird. Wir empfehlen, das FAL-Feld "Fotografin/Fotograf" und "Lizenz" konsequent zu pflegen.

Drittens ist Mehrsprachigkeit ein praktisches Problem. Eine Person hat einen Namen, aber ihre Funktion und die Kurzbiografie unterscheiden sich in Deutsch und Englisch. personnel unterstützt den TYPO3-Standard für Übersetzungen, aber viele Projekte vergessen, die Abteilungs- und Standort-Records ebenfalls zu lokalisieren, was zu gemischten Sprach-Ausgaben führt.

## Migration auf TYPO3 v12 verlangt Extbase-Update und TCA-Review

personnel ist für verschiedene TYPO3-Versionen im TER verfügbar. Beim Upgrade einer v10- oder v11-Installation müssen die Extbase-Repositories auf die aktuelle Persistence-API umgestellt werden, und die TCA-Struktur sollte auf Typ-Inkompatibilitäten geprüft werden (speziell bei "passthrough"- und "none"-Feldern, die in v12 strenger validiert werden).

Gosign migriert personnel-Installationen oft im Zuge eines Team-Seiten-Refactorings. Im gleichen Schritt prüfen wir, ob der Datenbestand auf ein moderneres Person-Schema gehoben werden kann (mit JSON-LD-Auszeichnung), ob Filter und Suche performant mit grossen Datensätzen umgehen, und ob die Team-Seite responsiv und barrierefrei ausgespielt wird. Für Projekte mit extrem grossen Datensätzen (mehrere tausend Personen) lohnt sich ausserdem ein Blick auf Indexierung und Lazy-Loading, damit die Listenansicht auf mobilen Geräten nicht zur Bremse wird. Bei besonders komplexen Team-Strukturen ersetzen wir personnel gelegentlich durch ein Custom-Extbase-Modell, wenn die Standard-Feldstruktur nicht ausreicht oder ein Anschluss an ein externes HR-System gefordert ist.

--- PhotoSwipe TYPO3 - Lightbox | Gosign ---
> PhotoSwipe ist eine touch-optimierte Lightbox-Library. Die TYPO3-Extension integriert PhotoSwipe als Bildergalerie: Zoom, Swipe-Gesten,.

## Bildergalerien auf mobilen Geräten funktionieren nur mit touch-optimierten Lightboxen

Die meisten TYPO3-Websites nutzen Lightboxen, die für Desktop-Browser entwickelt wurden: Fancybox, Colorbox, Magnific Popup. Auf Smartphones und Tablets fühlen sich diese Lösungen fremd an, weil Zoom und Navigation nicht auf Touch-Gesten reagieren, sondern auf Mausklicks. PhotoSwipe ist eine JavaScript-Library, die von Grund auf für Touch gebaut wurde. Die TYPO3-Extension integriert PhotoSwipe als vollständige Bildergalerie mit Pinch-to-Zoom, Swipe-Navigation, Deep-Linking und responsivem Layout. Bei unter 30 KB (minified + gzip) ist PhotoSwipe gleichzeitig eine der leichtgewichtigsten Lightbox-Lösungen am Markt.

Für Websites mit hohem Mobile-Anteil, also heute praktisch alle, ist das keine optionale Verbesserung, sondern eine funktionale Anforderung. Besucher erwarten die gleichen Gesten, die sie von der nativen Foto-App ihres Smartphones kennen.

## Typische Einsatzszenarien umfassen Portfolio-Galerien, Produktbilder und Medienarchive

Das häufigste Szenario sind Portfolio-Galerien auf Agentur-, Architektur- oder Fotografie-Websites. Ein Fotograf zeigt 20 bis 40 Bilder pro Projekt. Besucher klicken ein Thumbnail, sehen das Bild in voller Auflösung, zoomen per Pinch und wischen zum nächsten Bild. Deep-Linking bedeutet, dass jedes Bild eine eigene URL hat, die geteilt oder verlinkt werden kann. Das ist für SEO relevant, weil Google die Bilder über die Deep-Link-URLs indexieren kann.

Ein zweites Szenario sind Produktdetailseiten in E-Commerce-nahen TYPO3-Installationen. Ein Möbelhersteller zeigt fünf Perspektiven pro Produkt. PhotoSwipe rendert diese als Galerie mit High-Resolution-Zoom, der auf Desktop per Mausrad und auf Touch per Doppeltipp aktiviert wird. Die Zoom-Qualität hängt direkt von der Auflösung des Quellbilds ab. Wir empfehlen mindestens 2000 Pixel Breite für Produktbilder, die per Zoom betrachtet werden sollen.

Drittes Szenario: Medienarchive und Pressebereiche. Eine Universität stellt 500 Eventfotos bereit. PhotoSwipe rendert die Galerie performant, weil Bilder erst beim Aufblättern geladen werden (Lazy Loading). Die Thumbnail-Übersicht zeigt 50 Bilder pro Seite ohne spürbare Ladezeit.

## Technische Architektur bindet PhotoSwipe als TYPO3 Content Element ein

Die Extension registriert ein eigenes Content-Element im TYPO3-Backend. Redakteure wählen Bilder aus der FAL-Mediathek, definieren die Sortierung und setzen optionale Bildunterschriften. Das Rendering übernehmen Fluid-Templates, die die PhotoSwipe-JavaScript-Library initialisieren und die Bild-URLs als JSON-Array übergeben.

PhotoSwipe selbst hat keine Abhängigkeiten, kein jQuery, kein Framework. Die Library besteht aus einer CSS-Datei und einer JS-Datei. Die TYPO3-Extension lädt beide über TypoScript-AssetCollector, sodass sie nur auf Seiten eingebunden werden, die tatsächlich eine Galerie enthalten. Das vermeidet unnötige Requests auf Seiten ohne Galerie.

Für responsive Bilder unterstützt die Extension srcset-Attribute: Der Browser lädt je nach Viewport die passende Bildgrösse. Das TYPO3-Bild-Processing erzeugt die Varianten automatisch. In Kombination mit WebP-Konvertierung (siehe webp-Extension) erreichen PhotoSwipe-Galerien optimale Ladezeiten.

## Häufige Probleme betreffen Konflikte mit anderen Lightbox-Extensions und fehlende Bildgrössen

Das häufigste Problem ist der Konflikt mit einer bereits installierten Lightbox-Extension. Wenn Fancybox und PhotoSwipe gleichzeitig aktiv sind, reagieren beide auf Bild-Klicks und erzeugen doppelte Overlays. Die Lösung: Die alte Lightbox-Extension deaktivieren und deren CSS/JS-Includes aus dem TypoScript-Setup entfernen. Ein grep nach "fancybox" oder "colorbox" in den TypoScript-Dateien zeigt, ob Reste der alten Library noch geladen werden.

Zweites Problem: Fehlende Bildgrössen. PhotoSwipe braucht für den Zoom die tatsächlichen Pixel-Dimensionen des Bildes. Wenn die Extension diese nicht aus den FAL-Metadaten lesen kann, funktioniert der Zoom nicht oder springt auf eine falsche Grösse. Die Lösung: Die FAL-Metadaten aller Galerie-Bilder prüfen. TYPO3 liest width und height beim Upload automatisch aus, aber importierte oder per CLI eingefügte Bilder haben manchmal leere Metadaten.

## PhotoSwipe v5 läuft unter TYPO3 v12, die v13-Kompatibilität erfordert ein Template-Update

Die aktuelle PhotoSwipe-Library ist in Version 5. Die TYPO3-Extension wurde für verschiedene TYPO3-Versionen angepasst und läuft unter v12 stabil. Für TYPO3 v13 ist ein Update der Fluid-Templates und der TypoScript-Konfiguration nötig, weil v13 den AssetCollector-Workflow leicht verändert hat. Gosign aktualisiert bei TYPO3-Upgrades alle Frontend-Extensions inklusive Lightbox und prüft, ob die Touch-Gesten auf aktuellen iOS- und Android-Versionen korrekt funktionieren.

--- powermail TYPO3 - Formulare & CRM | Gosign ---
> Das meistgenutzte Formular-Plugin für TYPO3. Kontaktformulare, mehrstufige Formulare, Bedingungslogik, PDF-Export, CRM-Anbindung. Gosign hat.

## powermail ist das produktionsreife Formular-System für TYPO3

Zwischen dem TYPO3-Core-Form-Framework und kompletten Marketing-Automation-Tools klafft in der Praxis eine Lücke: Redaktionen wollen Formulare ohne Code bauen, mit Bedingungslogik, Datei-Upload, DSGVO-Einwilligung, Weiterleitung an CRM und sauberem PDF-Export. Genau dafür ist powermail gebaut. Die Extension von in2code ist das meistinstallierte Formular-Plugin im TYPO3-Ökosystem und läuft auf dem Grossteil aller mittleren und grossen TYPO3-Projekte, die Gosign betreut. Seit der ersten Version vor über einem Jahrzehnt hat sich powermail zum Schweizer Taschenmesser der TYPO3-Formularentwicklung entwickelt und ist auch dann eine valide Wahl, wenn der TYPO3-Core-Form-Framework theoretisch ausreichen würde.

## Typische Einsatzszenarien gehen von Kontaktformularen bis zu Bewerbungsportalen

Das häufigste Szenario ist trivial, aber unvermeidlich: Kontaktformulare auf Unternehmenswebseiten, die E-Mails an verschiedene Abteilungen verschicken. powermail erlaubt das über bedingte Empfänger-Routen, ohne dass ein Entwickler eingreifen muss. Redakteure pflegen die Felder im Backend wie ein Seiteninhalt, inklusive Reihenfolge, Pflichtfelder und Validierung. Eine typische Unternehmens-Installation hat drei bis fünf Formular-Varianten: allgemeine Kontaktanfrage, Presse-Kontakt, Karriere, Support und Produktberatung. Jede Variante landet über einen eigenen Empfänger-Filter in der richtigen Abteilungs-Inbox.

Deutlich anspruchsvoller sind mehrstufige Bewerbungsformulare, wie sie bei öffentlichen Einrichtungen und Hochschulen üblich sind. Ein Bewerbungsportal fragt in Schritt 1 Stammdaten ab, in Schritt 2 den gewünschten Studiengang, in Schritt 3 Zeugnisse per Upload und in Schritt 4 eine DSGVO-Einwilligung mit Verlinkung auf die Datenschutzerklärung. powermail rendert alle vier Schritte aus einem einzigen Formular-Datensatz und speichert den Fortschritt zwischen den Schritten in einer Session, sodass der Bewerber bei Bedarf zurückspringen kann. Bedingungen blenden Felder abhängig von vorherigen Antworten ein oder aus, was bei komplexen Formularen wie Stipendien-Anträgen oder Habilitations-Anmeldungen eine dreistellige Anzahl Feldkombinationen übersichtlich macht.

Ein drittes Szenario, das powermail von einfacheren Extensions abhebt, ist die Integration in CRM- und Marketing-Tools. Die Finisher-Architektur erlaubt es, Daten parallel an HubSpot, Salesforce, Brevo oder einen eigenen Webhook zu senden, bevor die Bestätigungsmail an den Absender rausgeht. Bei Gosign ist powermail deshalb auch das Standard-Tool für Lead-Formulare, die direkt in den Vertriebsprozess einspeisen. In einem Enterprise-Projekt haben wir powermail an Salesforce Marketing Cloud angebunden und gleichzeitig über einen Webhook an das interne Ticket-System weitergeleitet, sodass Sales- und Support-Teams parallel auf die Anfrage zugreifen können.

## Technische Architektur trennt Formular-Definition, Finisher und Template

powermail besteht aus drei konzeptionellen Ebenen: der Formular-Definition im Backend, den Finishern, die nach dem Absenden ausgeführt werden, und den Fluid-Templates, die das Rendering übernehmen. Jede Ebene ist erweiterbar, ohne die Extension zu forken. Diese klare Trennung macht powermail zum robusten Werkzeug für langlebige TYPO3-Projekte, in denen Formulare über Jahre hinweg gepflegt und erweitert werden.

Formulare werden als Records in tx_powermail_domain_model_form angelegt. Jedes Formular enthält Pages (Schritte), jede Page enthält Felder. Die Feld-Typen reichen von Text, E-Mail, Select, Radio, File-Upload bis zu HTML-Content und Consent-Checkboxen. Bedingungslogik wird über das Conditions-Modul gepflegt: "Zeige Feld B nur, wenn Feld A den Wert X hat".

Finisher sind die eigentliche Stärke der Extension. Der Standard-Finisher verschickt E-Mails, speichert Einträge in der Datenbank und erzeugt PDF-Exports. Weitere Finisher lassen sich per FinisherInterface implementieren: Webhook-Versand, CRM-Sync, Salesforce, SAP-Übergabe. Die Reihenfolge der Finisher ist konfigurierbar, und jeder Finisher kann den Prozess bei einem Fehler abbrechen.

Templates liegen als Fluid-Dateien im EXT-Pfad und werden typischerweise per SiteSet oder eigenem Paket überschrieben. Das bedeutet: Ein einziges globales Template-Overlay reicht, um alle Formulare einer Website einheitlich zu gestalten. Wer stattdessen pro Formular eigene Templates braucht, kann die Template-Pfade per TypoScript umkonfigurieren und ein Template-Set pro Formular-Typ pflegen.

## Häufige Probleme betreffen Spam, GDPR und Mail-Zustellbarkeit

Das dominierende Supportthema bei öffentlichen powermail-Formularen ist Spam. Out of the box bringt die Extension Honeypot-Felder, Zeitstempel-Prüfung und ein optionales ReCaptcha v3 über ext:powermailrecaptcha mit. Trotzdem landet Spam im Backend, wenn die Administration die Prüfmechanismen nicht aktiviert hat. Wir empfehlen, in jedem Formular Honeypot UND ReCaptcha zu kombinieren und zusätzlich einen IP-basierten Rate-Limit-Finisher zu verwenden.

Das zweite Problem ist die DSGVO-Konformität. Formular-Einwilligungen müssen revisionssicher dokumentiert sein: Datum, Version der Datenschutzerklärung, IP und User-Agent. Die Extension bietet dafür den Consent-Storage, der Einwilligungen separat protokolliert und für Audits exportierbar macht.

Drittens ist die Mail-Zustellbarkeit ein Dauerthema. Bestätigungsmails landen im Spam, weil der Absender nicht authentifiziert ist. SPF, DKIM und DMARC müssen auf Ebene des Mail-Servers korrekt eingerichtet sein, und die powermail-Konfiguration sollte einen Return-Path und einen validen Reply-To setzen. Bei grossen Installationen empfehlen wir zusätzlich einen dedizierten Transaktionsmail-Service wie Brevo, Mailgun oder Amazon SES, damit die Zustellrate nicht unter der allgemeinen Server-Reputation leidet.

## TYPO3 v12 und v13 werden vollständig unterstützt

powermail ist bei jedem TYPO3-LTS-Release zeitnah verfügbar, weil in2code die Extension aktiv pflegt. Die aktuelle Serie unterstützt TYPO3 v11, v12 und v13 parallel. Beim Upgrade älterer Installationen betreffen Breaking Changes vor allem eigene Finisher-Klassen, die auf die aktuelle Interface-Signatur umgestellt werden müssen, sowie Fluid-Templates, die auf ViewHelper-Änderungen reagieren.

Gosign migriert powermail-Installationen typischerweise zusammen mit dem TYPO3-Core-Upgrade. Dabei prüfen wir vor dem Sprung, welche eigenen Finisher und Templates existieren, welche Drittanbieter-Integrationen angebunden sind und ob veraltete Plugin-Varianten noch im Einsatz sind. Die Migration läuft meist ohne Datenmigration, weil die Record-Struktur der Formular-Definition stabil bleibt.

--- powermailrecaptcha TYPO3 - reCAPTCHA | Gosign ---
> Google reCAPTCHA-Anbindung für Powermail. Spam-Schutz für das meistgenutzte TYPO3-Formular-Plugin. Gosign berät zu datenschutzfreundlicheren.

## Powermail ohne Spam-Schutz wird innerhalb von Wochen zur Müllhalde

Powermail ist mit Abstand die meistgenutzte Formular-Extension für TYPO3. Über 150.000 aktive Installationen (Stand: TER, 2026), von Kontaktformularen über Bewerbungsformulare bis zu komplexen mehrstufigen Anfragestrecken. Das Problem: Jedes öffentlich erreichbare Formular ohne CAPTCHA wird früher oder später von Bots gefunden. Typische Folge: 200 bis 500 Spam-Einträge pro Tag, volle Postfächer, verrauschte Statistiken und Formulare, die Mitarbeitende irgendwann ignorieren, auch die echten Anfragen darin.

powermailrecaptcha ist die offizielle Ergänzung zu Powermail, die Google reCAPTCHA v2 oder v3 in Powermail-Formulare integriert. Die Extension wird von in2code (dem Powermail-Entwickler) selbst gepflegt, was kurze Update-Zyklen und hohe Kompatibilität garantiert.

## Typische Einsatzszenarien

**Kontaktformulare auf Unternehmenswebsites.** Das Standard-Szenario: ein Formular mit Name, E-Mail, Nachricht und Absenden-Button. Ohne CAPTCHA kommen täglich 50 bis 300 Spam-Nachrichten rein, meist mit Links zu Pharma- oder Casino-Seiten. reCAPTCHA v3 (unsichtbar, Score-basiert) ist hier ideal: kein zusätzlicher Klick für den Nutzer, Bots werden im Hintergrund erkannt. Ein Score unter 0.5 (auf einer Skala von 0 bis 1) wird als Bot gewertet und die Absendung blockiert.

**Bewerbungsformulare mit Dateiupload.** Karriereseiten, auf denen Bewerber Lebenslauf und Anschreiben hochladen, sind besonders Spam-anfällig, weil Bots über die Upload-Funktion Malware verteilen. reCAPTCHA filtert die automatisierten Anfragen. Zusätzlich sollte eine serverseitige Dateityp-Prüfung (nur PDF, DOCX) und eine Grössenbeschränkung (max. 10 MB) aktiv sein.

**Mehrstufige Formulare mit Conditional Logic.** Powermail kann Formulare mit Bedingungen bauen: Wenn "Branche = Immobilien" gewählt wird, erscheinen zusätzliche Felder. Bei solchen Formularen reicht ein CAPTCHA auf der letzten Seite vor dem Absenden. powermailrecaptcha bindet den Check standardmässig an den Submit-Button, funktioniert also auch bei Multi-Step-Formularen.

## Technische Architektur

powermailrecaptcha erweitert Powermail über ein TYPO3-Signal/Slot (v11) oder PSR-14 Event (v12+). Beim Rendern des Formulars wird das reCAPTCHA-JavaScript eingebunden (von google.com/recaptcha/api.js). Beim Absenden wird das reCAPTCHA-Token serverseitig validiert: TYPO3 sendet einen POST-Request an `https://www.google.com/recaptcha/api/siteverify` mit dem Token und dem Secret Key. Google antwortet mit einem Score (v3) oder einer Bestätigung (v2).

Die Konfiguration erfolgt über TypoScript-Konstanten: Site Key und Secret Key (aus der Google reCAPTCHA Admin Console), Threshold-Score für v3 (Standard: 0.5), reCAPTCHA-Version (v2 Checkbox, v2 Invisible oder v3). Die Keys werden im TYPO3-Backend unter Constants gepflegt, idealerweise über Environment-Variablen, damit sie nicht im Git-Repository landen.

Für v3 (unsichtbar) wird kein sichtbares Widget gerendert. Der Score wird im Hintergrund berechnet und in einem Hidden Field gespeichert. Für v2 Checkbox erscheint das bekannte "Ich bin kein Roboter"-Widget. Für v2 Invisible erscheint nichts, bis das System einen verdächtigen Nutzer erkennt und dann eine Challenge (Bildauswahl) anzeigt.

## Häufige Probleme und Lösungen

**DSGVO-Bedenken wegen Google-Verbindung.** reCAPTCHA lädt JavaScript von Google-Servern und überträgt die IP-Adresse des Nutzers an Google. Seit dem Schrems-II-Urteil und der zunehmend strengen Auslegung durch Datenschutzbehörden ist das ein reales Risiko. Lösung: reCAPTCHA nur laden, wenn der Nutzer per Cookie-Banner zugestimmt hat (Consent-Integration). Oder komplett auf europäische Alternativen umsteigen: Friendly Captcha (Server in der EU, kein Tracking), hCaptcha (DSGVO-konformer als reCAPTCHA, aber Server in den USA) oder eine reine Honeypot-Strategie ohne externe Dienste.

**reCAPTCHA v3 blockiert echte Nutzer.** Der Score-Algorithmus ist eine Blackbox. Manche echte Nutzer (z.B. hinter VPN, mit Adblocker, auf älteren Geräten) erhalten niedrige Scores und werden fälschlich blockiert. Lösung: Den Threshold nicht auf 0.5 setzen, sondern auf 0.3, und zusätzlich ein Honeypot-Feld einbauen. Alternativ: Bei niedrigem Score ein Fallback auf reCAPTCHA v2 Checkbox anzeigen, statt direkt zu blockieren.

**Extension-Konflikt mit Content Security Policy.** Seit TYPO3 v12 unterstützt der Core Content Security Policies (CSP). reCAPTCHA-JavaScript von google.com muss in der CSP erlaubt werden, sonst wird es blockiert. Lösung: In der CSP-Konfiguration `script-src` und `frame-src` für `https://www.google.com/recaptcha/` und `https://www.gstatic.com/recaptcha/` ergänzen.

## Migration und Versions-Kompatibilität

powermailrecaptcha unterstützt TYPO3 v11, v12 und v13 (letzteres seit Q1 2026). Die Extension folgt dem Release-Zyklus von Powermail: wenn Powermail eine neue TYPO3-Version unterstützt, zieht powermailrecaptcha innerhalb weniger Wochen nach.

Für Projekte, die von reCAPTCHA auf eine DSGVO-freundlichere Alternative wechseln wollen, ist der Umbau überschaubar. Friendly Captcha bietet ein eigenes Powermail-Plugin (powermail_friendlycaptcha), das als Drop-in-Ersatz funktioniert: Extension installieren, Keys eintragen, powermailrecaptcha deaktivieren. Die Formular-Konfiguration in Powermail selbst bleibt unverändert. Gosign empfiehlt Friendly Captcha als Standard für neue Projekte und bietet die Umstellung bestehender Formulare als Pauschalleistung an.

Ein oft übersehener Aspekt ist die Spam-Prävention jenseits von CAPTCHAs. Powermail bietet nativ ein Honeypot-Feld (ein unsichtbares Formularfeld, das nur Bots ausfüllen). In Kombination mit einer Zeitprüfung (Formular muss mindestens 3 Sekunden geöffnet sein, bevor es abgesendet werden kann) lässt sich ein Grossteil des automatisierten Spams ohne externe Dienste filtern. Gosign setzt in Projekten, bei denen DSGVO-Konformität Priorität hat, eine dreistufige Strategie ein: Honeypot und Zeitprüfung als erste Schicht (0 externe Requests), Friendly Captcha als zweite Schicht (EU-Server) und serverseitige Inhaltsanalyse als dritte Schicht (Link-Dichte, Sprache, bekannte Spam-Muster). Diese Kombination erreicht eine Spam-Erkennungsrate von über 99 % ohne Google-Dienste.

Für den Umstieg von powermailrecaptcha auf Friendly Captcha rechnet Gosign mit 2 bis 4 Stunden pro Website, inklusive Installation, Konfiguration, Test aller Formulare und Deaktivierung der alten Extension.

--- Preisrechner TYPO3 - Kalkulator | Gosign ---
> Konfiguratoren, Kostenrechner, Angebotsgeneratoren direkt in TYPO3. Custom-Entwicklung für spezifische Kalkulationslogik mit interaktivem Frontend.

## Preisrechner im Web generieren qualifizierte Leads, aber nur wenn die Kalkulation stimmt

Besucher, die auf einer Website einen Preis berechnen, sind die wertvollsten Leads im B2B-Vertrieb. Sie haben ein konkretes Vorhaben, kennen ihre Anforderungen und erwarten eine belastbare Zahl. Trotzdem arbeiten die meisten TYPO3-Websites mit statischen Preistabellen oder einem "Preis auf Anfrage"-Button, der den Besucher in ein generisches Kontaktformular schickt. pricecal schliesst diese Lücke: Die Extension ermöglicht Konfiguratoren, Kostenrechner und Angebotsgeneratoren direkt in TYPO3, mit spezifischer Kalkulationslogik und einem interaktiven Frontend, das in Echtzeit reagiert.

Der Unterschied zu externen Tools wie Calconic oder Outgrow: Die Daten bleiben auf dem eigenen Server, die Kalkulation ist unter voller Kontrolle, und das Design fügt sich nahtlos in die bestehende Website ein.

## Typische Einsatzszenarien gehen vom Umzugsrechner bis zum Industriekonfigurator

Das zugänglichste Szenario ist der Kostenrechner für Dienstleistungen. Ein Umzugsunternehmen fragt Wohnungsgrösse, Stockwerk, Entfernung und Sonderwünsche (Klavier, Aquarium) ab und zeigt einen Richtpreis. Der Besucher sieht sofort, ob der Service im Budget liegt, und kann direkt ein verbindliches Angebot anfordern. In der Praxis steigern solche Rechner die Anfragequote um 40 bis 70 Prozent gegenüber einem statischen Kontaktformular, weil der Besucher bereits eine Preiserwartung hat.

Ein zweites Szenario sind Produktkonfiguratoren im verarbeitenden Gewerbe. Ein Fensterhersteller bietet 12 Rahmentypen, 8 Glasarten, 4 Beschlagvarianten und 20 Farben. pricecal berechnet den Preis aus der Kombination und zeigt ihn live an, während der Besucher konfiguriert. Bei 12 x 8 x 4 x 20 = 7.680 möglichen Kombinationen ist eine statische Preisliste unmöglich. Der Konfigurator ersetzt sie durch eine dynamische Berechnung, die der Redakteur über Preis-Matrizen im Backend pflegt.

Drittes Szenario: ROI-Rechner für Software-Produkte. Ein SaaS-Anbieter lässt Besucher Mitarbeiteranzahl, aktuellen Zeitaufwand und Stundensatz eingeben. Der Rechner zeigt die jährliche Ersparnis durch das Produkt. Das ist kein Verkaufstrick, sondern ein Werkzeug, das dem Besucher hilft, die Investition intern zu begründen.

## Technische Architektur trennt Kalkulationslogik, Eingabefelder und Ergebnisdarstellung

pricecal ist als Custom Content Element in TYPO3 implementiert. Im Backend definiert der Administrator die Eingabefelder (Slider, Dropdown, Number Input, Checkbox), die Kalkulationsformel und die Ergebnisdarstellung. Die Formel kann einfache Arithmetik (Preis = Menge x Einzelpreis x Faktor) oder komplexere Logik mit Bedingungen (wenn Stockwerk > 3, dann Zuschlag 15%) abbilden.

Das Frontend rendert die Eingabefelder über Fluid-Templates und berechnet den Preis per JavaScript im Browser. Kein Server-Roundtrip bei jedem Slider-Schritt, das Ergebnis aktualisiert sich in Echtzeit. Für komplexere Kalkulationen, etwa wenn Preis-Matrizen oder externe Datenquellen (ERP, Lagerverfügbarkeit) eingebunden werden müssen, kann die Berechnung über einen AJAX-Endpoint an den Server delegiert werden.

Die Ergebnisse lassen sich optional als PDF generieren und per E-Mail versenden. In Kombination mit powermail kann das Kalkulationsergebnis als Hidden Field in ein Kontaktformular übergeben werden, sodass der Vertrieb die exakte Konfiguration des Interessenten sieht.

## Häufige Probleme betreffen Rundungsfehler und die Pflege komplexer Preislogiken

Das häufigste Problem bei Preisrechnern ist die korrekte Rundung. JavaScript-Fliesskomma-Arithmetik liefert bei 0,1 + 0,2 den Wert 0,30000000000000004. Bei Preisen mit zwei Nachkommastellen führt das zu sichtbaren Fehlern. Die Lösung: Alle Berechnungen intern in Cent (Integer) durchführen und erst bei der Anzeige in Euro umrechnen.

Zweites Problem: Die Pflege der Kalkulationslogik. Wenn ein Produktmanager die Preise vierteljährlich anpasst, muss er die Formeln im Backend verstehen. Bei einfachen Kalkulationen (Menge x Preis) ist das trivial. Bei Konfiguratoren mit 50 Parametern und gestaffelten Rabatten wird die Pflege zum Risiko. Wir empfehlen, komplexe Preislogik als TypoScript-Konfiguration oder YAML-Datei auszulagern und versioniert in Git zu pflegen, statt sie im Backend zu bearbeiten.

Drittes Thema: Mobile Bedienbarkeit. Slider sind auf Touchscreens unpräzise, weil der Finger einen grösseren Bereich abdeckt als ein Mauszeiger. Bei Preisrechnern mit feiner Granularität (z.B. Quadratmeter von 10 bis 500) sollten Slider durch Eingabefelder mit Plus/Minus-Buttons ersetzt werden.

## pricecal ist Custom-Entwicklung und damit versionsunabhängig

Da pricecal keine Community-Extension aus dem TER ist, sondern eine Custom-Entwicklung, gibt es keinen externen Release-Zyklus. Die TYPO3-Kompatibilität hängt davon ab, wie die Extension intern implementiert ist. Installationen, die auf Extbase und Fluid basieren, laufen unter TYPO3 v12 und v13 nach Anpassung der Namespace-Deklarationen und der Content-Element-Registrierung. Gosign setzt bei neuen Preisrechner-Projekten auf eine Framework-unabhängige Architektur: Die Kalkulationslogik läuft als eigenständiges JavaScript-Modul, das TYPO3 nur als Content-Element einbindet, aber keine Extbase-Abhängigkeit hat.

--- Social Feed TYPO3 - Instagram & Co | Gosign ---
> Social Media Feeds (Instagram, Facebook, Twitter/X) in TYPO3 einbinden. API-basiert, gecacht, DSGVO-konform darstellbar ohne Tracking-Pixel. Gosign.

## Social Media Feeds auf der Website sehen gut aus, brechen aber regelmässig durch API-Änderungen

Marketing-Teams wollen Instagram-Posts, Facebook-Beiträge oder Twitter/X-Tweets auf der Firmenwebsite anzeigen. Die Idee dahinter ist nachvollziehbar: aktuelle Inhalte ohne redaktionellen Aufwand, Social Proof durch echte Posts, visuelle Aufwertung durch Bildmaterial. Die Praxis sieht anders aus. Meta, Twitter/X und TikTok ändern ihre APIs regelmässig, schränken Zugriffsrechte ein oder stellen kostenlose Endpunkte komplett ein. Twitter/X hat 2023 den freien API-Zugang abgeschafft und verlangt seitdem mindestens 100 USD/Monat für Leserechte. Die Instagram Basic Display API wurde 2024 durch die Instagram Graph API ersetzt. Wer eine Social-Feed-Integration betreibt, muss diese Änderungen nachziehen oder der Feed bleibt leer.

pxa_social_feed (entwickelt von Pixelant) ist die bekannteste TYPO3-Extension für Social Media Feeds. Sie unterstützt Instagram, Facebook und Twitter/X, speichert Feed-Daten lokal (gecacht) und rendert sie als TYPO3-Content-Element. Die Extension ist Open Source und wird Community-getrieben gepflegt.

## Typische Einsatzszenarien

**Corporate Websites mit Instagram-Feed auf der Startseite.** Ein Unternehmen postet 3 bis 5 Mal pro Woche auf Instagram und will die neuesten 6 bis 12 Posts als Bildergalerie auf der Startseite zeigen. pxa_social_feed holt die Posts per Cron-Job (z.B. alle 30 Minuten), speichert Bilder, Captions und Links lokal und rendert sie in einem konfigurierbaren Grid. Der Vorteil gegenüber einem Embed (iframe): keine externen Requests beim Seitenaufruf, keine Tracking-Pixel, schnellere Ladezeit.

**Eventseiten mit Live-Feed.** Konferenzen, Messen oder Firmenfeiern nutzen einen Hashtag (z.B. #GosignSummit2026). Der Feed zeigt alle öffentlichen Posts mit diesem Hashtag in Echtzeit (oder nahezu Echtzeit mit 5-Minuten-Caching). Die Moderation erfolgt im TYPO3-Backend: Einzelne Posts können ausgeblendet werden, bevor sie auf der Website erscheinen.

**Employer-Branding-Seiten.** HR-Abteilungen zeigen auf der Karriereseite Einblicke aus dem Arbeitsalltag, die Mitarbeitende auf Instagram oder LinkedIn posten. Die Integration sammelt Posts von einem oder mehreren Accounts und kuratiert sie redaktionell. Besonderheit: LinkedIn bietet keine offene API für Feed-Integration, daher beschränkt sich die Automatisierung auf Instagram und Facebook.

## Technische Architektur

pxa_social_feed nutzt die APIs der jeweiligen Plattformen: Instagram Graph API (über einen Facebook-App-Token), Facebook Graph API und Twitter/X API v2. Jede Plattform erfordert eigene Authentifizierung: Facebook und Instagram brauchen einen Long-Lived User Token (gültig 60 Tage, muss regelmässig erneuert werden), Twitter/X braucht einen Bearer Token (Application-only Auth).

Die Extension speichert Feed-Daten in einer lokalen TYPO3-Tabelle (tx_pxasocialfeed_domain_model_feed). Bilder werden heruntergeladen und als FAL-Referenzen gespeichert. Beim Seitenaufruf werden nur lokale Daten gerendert, keine externen API-Calls. Ein Scheduler-Task holt neue Posts und löscht alte (konfigurierbar: letzte 50 Posts behalten, ältere entfernen).

Die Ausgabe erfolgt über Fluid-Templates, die per TypoScript konfiguriert werden. Standard-Layouts: Grid (3-4 Spalten), Masonry, Slider (per eigener JavaScript-Einbindung). Das HTML/CSS kann vollständig angepasst werden, ohne den Extension-Code zu ändern.

Für DSGVO-Konformität ist der lokale Cache entscheidend: Weil Bilder und Texte auf dem eigenen Server liegen, werden beim Seitenaufruf keine Daten an Meta oder Twitter/X übermittelt. Kein Tracking-Pixel, kein Cookie-Consent nötig für den Feed selbst. Ausnahme: Wenn der "Zum Original-Post"-Link eingebaut wird, findet beim Klick eine Weiterleitung statt.

## Häufige Probleme und Lösungen

**Instagram Token läuft ab, Feed bleibt leer.** Der Long-Lived Token hat eine Lebensdauer von 60 Tagen. Wenn niemand ihn erneuert, stoppt der Import. Lösung: Einen Cronjob einrichten, der den Token automatisch per API-Call verlängert (der Endpunkt `GET /oauth/access_token?grant_type=fb_exchange_token` gibt einen neuen Token zurück). pxa_social_feed bietet seit Version 4.x eine Token-Refresh-Funktion im Backend.

**Twitter/X-Feed funktioniert nach API-Umstellung nicht mehr.** Seit 2023 ist die Twitter/X API kostenpflichtig. Der Basic-Tarif (100 USD/Monat) erlaubt 10.000 Tweets/Monat lesen. Für die meisten Unternehmenswebsites reicht das, aber die Kosten-Nutzen-Rechnung muss stimmen. Lösung: Prüfen, ob der Twitter/X-Feed wirklich Traffic oder Engagement bringt. Wenn nicht, den Kanal entfernen und nur Instagram/Facebook beibehalten.

**Bilder werden nicht geladen oder sind verpixelt.** Die Instagram Graph API liefert Bilder in verschiedenen Grössen. pxa_social_feed speichert standardmässig die von der API gelieferte Version. Lösung: In der Extension-Konfiguration die Bildgrösse auf "original" setzen und im Fluid-Template per `<f:image>` responsive Varianten erzeugen.

## Migration und Versions-Kompatibilität

pxa_social_feed unterstützt TYPO3 v11 und v12. Die Kompatibilität mit TYPO3 v13 ist in der Community-Entwicklung (Stand April 2026), aber noch nicht offiziell freigegeben. Für Projekte auf TYPO3 v13 gibt es zwei Optionen: auf das offizielle Update warten oder eine eigene Feed-Integration als Middleware bauen, die unabhängig von der TYPO3-Version läuft.

Grundsätzlich empfiehlt Gosign, Social-Feed-Integrationen als entkoppelte Komponente zu denken: Ein Microservice oder Cloudflare Worker holt die Feeds, speichert sie als JSON, TYPO3 liest das JSON und rendert es. Damit entfällt die Abhängigkeit von einer TYPO3-Extension und jede API-Änderung wird an einer Stelle gefixt, unabhängig vom CMS.

Bei der Entscheidung, welche Social-Media-Kanäle auf der Website eingebunden werden sollen, empfiehlt Gosign eine datengetriebene Bewertung: Welcher Kanal bringt tatsächlich Engagement? Instagram-Feeds mit hochwertigen Bildern funktionieren auf Corporate Websites gut, Twitter/X-Feeds sind seit der API-Kostenpflicht für die meisten Unternehmen den Aufwand nicht wert, und Facebook-Feeds haben sinkende Relevanz, weil die organische Reichweite seit Jahren fällt. LinkedIn wäre für B2B-Unternehmen der relevanteste Kanal, bietet aber keine offene Feed-API. Die pragmatische Lösung: Instagram als Hauptkanal einbinden, LinkedIn-Beiträge manuell als TYPO3-Content kuratieren und auf Twitter/X verzichten, sofern der Kanal nicht geschäftskritisch ist.

Der Gesamtaufwand für eine Social-Feed-Integration (Instagram, gecacht, DSGVO-konform, mit Moderation im Backend) liegt bei 2 bis 5 Entwicklungstagen, je nachdem ob pxa_social_feed ausreicht oder eine Custom-Lösung nötig ist.

--- RaiseNow TYPO3 - Spenden | Gosign ---
> RaiseNow ist eine Schweizer Spenden-Plattform. Die TYPO3-Integration ermöglicht Online-Spenden, Recurring Donations und Kampagnen. Für NPOs, Vereine.

## Non-Profit-Organisationen verlieren Spenden, wenn der Spendenprozess die Website verlässt

Jeder Medienbruch kostet Conversion. Wenn ein Besucher auf "Jetzt spenden" klickt und auf eine externe Plattform weitergeleitet wird, brechen je nach Studie 30 bis 50 Prozent ab. RaiseNow ist eine Schweizer Spenden-Plattform, die genau dieses Problem löst: Die TYPO3-Integration bettet den gesamten Spendenprozess direkt in die Website ein. Spendenbetrag, Zahlungsmethode, Adressdaten und Bestätigung laufen in einem eingebetteten Widget, ohne dass der Besucher die Seite verlässt. Für NPOs, Vereine und Stiftungen, die auf TYPO3 setzen, ist das die sauberste Integration zwischen CMS und Spenden-Plattform.

RaiseNow verarbeitet jährlich über 300 Millionen Franken an Spenden und ist in der Schweiz der Marktführer für digitales Fundraising. Die TYPO3-Extension bringt dieses Ökosystem direkt ins Backend.

## Typische Einsatzszenarien reichen von Einmalspenden bis zu Dauerspender-Kampagnen

Das Basisszenario ist die Einmalspende auf der Startseite oder einer Kampagnenseite. Ein Hilfswerk startet eine Spendenkampagne nach einer Naturkatastrophe. Die Landingpage zeigt den Fortschrittsbalken (gesammelt / Ziel) und ein Spendenformular mit vorgeschlagenen Beträgen (25, 50, 100, frei wählbar). Der Besucher spendet per Kreditkarte, TWINT, PostFinance oder PayPal, erhält eine sofortige Bestätigung und eine Spendenquittung per E-Mail. Die gesamte Transaktion dauert unter 60 Sekunden.

Ein zweites, wirtschaftlich wichtigeres Szenario sind Recurring Donations (Dauerspenden). Eine Tierschutzorganisation bietet monatliche Patenschaften: 15 Franken pro Monat für die Pflege eines Tieres. RaiseNow verwaltet die wiederkehrenden Zahlungen, benachrichtigt bei fehlgeschlagenen Lastschriften und bietet dem Spender ein Self-Service-Portal zur Anpassung. Dauerspenden machen bei erfolgreichen NPOs 40 bis 60 Prozent des Gesamtvolumens aus, weil sie planbare Einnahmen erzeugen.

Drittes Szenario: Peer-to-Peer-Fundraising. Ein Sportverein organisiert einen Spendenlauf. Jeder Läufer erstellt eine persönliche Spendenseite, teilt sie in sozialen Netzwerken und sammelt Spenden für den Verein. RaiseNow aggregiert die Beträge, ordnet sie den Läufern zu und zeigt ein Live-Ranking. Die TYPO3-Extension stellt die Kampagnen-Übersicht und die persönlichen Spendenprofile als Content-Elemente bereit.

## Technische Architektur nutzt RaiseNow-Widgets per iFrame und API-Callback

Die TYPO3-Extension integriert RaiseNow über ein JavaScript-Widget, das als iFrame in die Seite eingebettet wird. Die Konfiguration (API-Key, Kampagnen-ID, Zahlungsmethoden, Vorschlags-Beträge) wird im TYPO3-Backend als Plugin-Konfiguration gesetzt und per TypoScript an das Widget übergeben.

Nach einer erfolgreichen Spende sendet RaiseNow einen Webhook an einen konfigurierbaren Endpoint. Dieser Webhook kann in TYPO3 verarbeitet werden, um Spenden in einer lokalen Datenbank zu protokollieren, Fortschrittsbalken zu aktualisieren oder Dankes-E-Mails über den TYPO3-eigenen Mailversand auszulösen. Die Zahlungsabwicklung selbst läuft vollständig auf RaiseNow-Infrastruktur, was PCI-DSS-Konformität ohne eigene Zertifizierung ermöglicht.

Die Spendenquittung wird von RaiseNow generiert und enthält alle steuerlich relevanten Angaben. Für Organisationen, die in Deutschland als gemeinnützig anerkannt sind, lässt sich die Quittung mit der Vereins-Steuernummer und dem Freistellungsbescheid versehen.

## Häufige Probleme betreffen DSGVO-Konformität und Widget-Styling

Das grösste Thema für deutsche Organisationen ist die DSGVO-Konformität. RaiseNow ist ein Schweizer Unternehmen und verarbeitet Zahlungsdaten auf Schweizer Servern. Seit dem Angemessenheitsbeschluss der EU-Kommission gilt die Schweiz als sicheres Drittland, aber die Datenschutzerklärung muss dennoch transparent ausweisen, welche Daten an RaiseNow übermittelt werden. Organisationen, die auf Nummer sicher gehen wollen, holen eine explizite Einwilligung über einen Consent-Layer ein, bevor das RaiseNow-Widget geladen wird.

Zweites Problem: Das Widget-Styling. RaiseNow-Widgets haben ein eigenes CSS, das sich nicht vollständig von aussen überschreiben lässt. Farben, Schriftarten und Button-Styles können über die RaiseNow-Konfiguration angepasst werden, aber das Layout des Formulars ist fixiert. Für Organisationen mit strengen CI-Vorgaben kann das ein Kompromiss sein. Die Alternative ist ein Custom-Spendenformular, das die RaiseNow-API direkt anspricht, was allerdings PCI-DSS-Anforderungen an die eigene Infrastruktur stellt.

## RaiseNow wird aktiv weiterentwickelt, die TYPO3-Extension braucht manuelle Pflege

RaiseNow selbst wird kontinuierlich weiterentwickelt. Neue Zahlungsmethoden (Apple Pay, Google Pay) und Features (QR-Rechnungen) werden regelmässig ergänzt. Die TYPO3-Extension ist jedoch ein Community-Projekt und wird nicht von RaiseNow offiziell gepflegt. Das bedeutet: Wenn TYPO3 v13 eine Änderung in der Plugin-Registrierung einführt, muss die Extension manuell angepasst werden. Organisationen, die RaiseNow langfristig in TYPO3 einsetzen, sollten die Extension in ihrem eigenen Repository forken und bei TYPO3-Upgrades mitpflegen. Gosign übernimmt diese Pflege im Rahmen von Wartungsverträgen und prüft bei jedem TYPO3-Update die RaiseNow-Kompatibilität.

--- rapidmail TYPO3 - Newsletter-Anbindung | Gosign ---
> rapidmail in TYPO3 integrieren: Subscriber-Sync, Double-Opt-In, Segmentierung. KI-beschleunigt, DSGVO-konform.

## rapidmail ist die pragmatische Newsletter-Antwort für DSGVO-sensible TYPO3-Projekte

Wer in Deutschland einen Newsletter rechtssicher betreibt, landet früher oder später bei deutschen Anbietern. rapidmail ist einer der meistgenutzten: deutsche Serverstandorte, deutscher Support, klare Preismodelle, solide API. Für TYPO3-Websites, die Newsletter-Anmeldungen direkt im Frontend sammeln und die Empfänger automatisch in Listen und Segmenten landen sollen, ist die Integration dieses Dienstes eine Standardaufgabe. Die Ergebnisse sind jedoch oft ernüchternd, weil die offizielle TYPO3-Extension nur Basisfunktionen abdeckt und Projekte mit echten Anforderungen schnell an Grenzen stossen.

Die Zielgruppe sind mittelständische Unternehmen, Verbände, Stadtwerke, Hochschulen, NGOs und Verlage, die ihre Bestandskundenkommunikation auf einer DSGVO-konformen Plattform aufbauen wollen. Ein typischer Anwendungsfall: Ein regionales Energieversorgungsunternehmen mit 80.000 Haushaltskundinnen möchte mit vier Segmenten (Privatkunden, Geschäftskunden, Förderkunden, Pressekontakte) zielgerichtete Newsletter verschicken und die Segmentierung automatisch aus TYPO3-Benutzergruppen beziehen.

## Typische Einsatzszenarien

Ein erstes Szenario ist die einfache Anmeldestrecke über Powermail. Ein Verein möchte Besucher seiner TYPO3-Website in den Newsletter eintragen. Der Powermail-Finisher übergibt Name, E-Mail und eine Segment-Kennzeichnung an die rapidmail-API, rapidmail verschickt die Bestätigungsmail, und nach dem Klick auf den Bestätigungs-Link wird der Kontakt in der passenden Empfängerliste aktiviert.

Ein zweites Szenario ist die Synchronisation von Benutzergruppen aus TYPO3 in rapidmail-Segmente. Eine Hochschule pflegt im TYPO3-Intranet Rollen wie Studierende, Alumni, Beschäftigte. Jeder Rollenwechsel soll automatisch in rapidmail die Segment-Zuordnung nachziehen, damit Aussendungen an genau die richtige Zielgruppe gehen - ohne doppelte Datenpflege.

Ein drittes Szenario ist die Event-Teilnehmerpflege. Ein Verlagshaus organisiert zehn Branchenkonferenzen pro Jahr und möchte Teilnehmer automatisch in eine nachgelagerte Kommunikationsstrecke übergeben. Die Registrierung erfolgt in einem TYPO3-Formular, die API schreibt den Teilnehmer in eine Event-Liste, rapidmail triggert eine automatische Drip-Kampagne mit drei Mails.

Ein viertes Szenario ist die Abmelde-Synchronisation. Wenn ein Leser über den Newsletter-Link in rapidmail austritt, muss das TYPO3-Profil-Center den Status übernehmen, damit der Benutzer beim nächsten Login nicht erneut "Newsletter aktiv" sieht. Das erfordert einen Rückkanal: rapidmail meldet die Abmeldung per Webhook, TYPO3 quittiert und aktualisiert die Benutzergruppe.

## Technische Architektur

rapidmail stellt eine REST-API mit OAuth-Authentifizierung bereit. Die TYPO3-Integration erfolgt entweder über einen Powermail-Finisher, eine Form-Framework-Erweiterung oder einen eigenen Extbase-Service, der auf die API zugreift. Gosign setzt in der Regel auf eine schlanke Service-Klasse, die die API-Calls kapselt und per Dependency Injection in Controllern, Finishern und Scheduler-Tasks verfügbar ist.

Für die Dauersynchronisation von Benutzergruppen wird typischerweise ein Scheduler-Task eingerichtet, der alle 15 Minuten Delta-Updates an rapidmail überträgt. Die Delta-Erkennung läuft über ein TYPO3-internes Audit-Feld (letzte Änderung pro Benutzer) oder über einen Hash-Vergleich auf Basis der API-Response. Wichtig ist, dass jede Übertragung idempotent gestaltet ist, damit ein erneuter Lauf nach einem Fehler keine Duplikate erzeugt.

Das Double-Opt-In wird vollständig auf rapidmail-Seite abgewickelt: TYPO3 meldet einen Kontakt an, rapidmail schickt die Bestätigungs-Mail, der Leser bestätigt, rapidmail aktiviert den Kontakt. TYPO3 muss dafür nichts eigenes bereitstellen - wichtig ist nur, dass die TYPO3-Seite dem Nutzer eine verständliche Zwischenseite anzeigt ("Bitte bestätigen Sie die Anmeldung in Ihrem Posteingang").

## Häufige Probleme und Lösungen

Das erste Problem ist das fehlende Bounce-Handling. Wer die API-Antworten nicht auswertet, bemerkt nicht, dass rapidmail bestimmte E-Mail-Adressen dauerhaft ablehnt. Die Lösung ist ein Logging der API-Responses in einer eigenen TYPO3-Tabelle plus ein periodischer Abgleich der Bounce-Listen, die rapidmail über die API bereitstellt.

Das zweite Problem sind Segmentierungs-Fehlzuordnungen. Wenn ein Kontakt in mehrere Benutzergruppen fällt, die jeweils auf unterschiedliche rapidmail-Listen zeigen, entstehen inkonsistente Zustände. Die Lösung ist eine klare 1:1- oder 1:n-Mapping-Logik, die vor der Implementierung sauber definiert und im Service-Layer hart kodiert wird.

Das dritte Problem ist die API-Rate-Limit-Verletzung. rapidmail limitiert die API-Nutzung. Bei einer Initial-Migration von 20.000 Kontakten in einem einzigen Scheduler-Lauf läuft der Job unweigerlich in die Sperre. Die Lösung ist ein Chunk-basierter Import mit 100 Kontakten pro Batch und einer Pausen-Steuerung zwischen den Batches.

Ein viertes Problem ist die Abgleich-Unschärfe bei doppelten Profilen. Wenn ein Benutzer sich mehrfach mit unterschiedlichen E-Mail-Schreibweisen (mit/ohne Punkt, Gross-/Kleinschreibung) einträgt, entstehen Duplikate in rapidmail und inkonsistente Zustände zwischen TYPO3 und Newsletter-System. Die Lösung ist eine Normalisierung der E-Mail-Adresse vor jedem API-Call (Lowercase, Whitespace-Trim, Punkt-Regel für Gmail-Adressen bewusst ignorieren oder konsequent anwenden).

## Migration und Versions-Kompatibilität

Die Integration ist als Custom-Extension von der TYPO3-Version weitgehend unabhängig: Sie läuft sauber auf TYPO3 v11, v12 und v13, sofern der API-Client-Code auf moderne HTTP-Clients (Guzzle) und Dependency Injection setzt. Beim Upgrade einer bestehenden Integration ist der häufigste Schmerzpunkt die Migration von TYPO3-Hooks zu PSR-15-Middlewares - ein Aufwand, den Gosign in der Regel mit KI-gestützter Code-Analyse in wenigen Tagen absolviert.

Auf der rapidmail-Seite ändert sich die API langsam, aber nicht bruchfrei: Zwischen den Major-Versionen wurden einzelne Endpunkte umbenannt, Felder neu strukturiert oder Authentifizierungsverfahren modernisiert. Wer eine ältere Integration aus 2018 oder 2020 auf den aktuellen Stand bringt, sollte mit einem halben Sprint für die API-Aktualisierung rechnen und die Tests gegen eine Staging-Liste in rapidmail fahren, bevor die Produktion angefasst wird. Gosign pflegt für diese Refresh-Aufgaben einen Standard-Prüfkatalog, der die üblichen Stolperstellen (Authentifizierung, Pagination, Error-Response-Format) abdeckt und die Migration reproduzierbar macht.

--- Rezepte Plugin TYPO3 | Gosign ---
> Rezepte-Extension für TYPO3: Zutaten, Zubereitungsschritte, Nährwerte, Portionen. Mit Schema.org Recipe-Markup für Google Rich Snippets (Sterne,.

## Rezepte ohne Schema.org-Markup verschenken die wertvollsten Positionen in den Google-Suchergebnissen

Rezept-Suchanfragen gehören zu den wenigen Bereichen, in denen Google Rich Snippets mit Bild, Bewertung, Kochzeit und Kalorien anzeigt. Websites ohne korrektes Schema.org-Recipe-Markup erscheinen als einfacher blauer Link unter den visuell dominanten Rich Results. Die TYPO3 Recipe-Extension strukturiert Rezepte mit allen Feldern, die Google für Rich Snippets erwartet: Zutaten, Zubereitungsschritte, Nährwerte, Portionen, Zubereitungszeit, Schwierigkeitsgrad. Das Schema.org-Markup wird automatisch im JSON-LD-Format ausgegeben, ohne dass Redakteure HTML bearbeiten müssen.

Für Food-Blogs, Verlage mit Rezeptrubriken und Lebensmittelhersteller mit Rezeptdatenbanken ist das der Unterschied zwischen Sichtbarkeit und Unsichtbarkeit in der Google-Suche.

## Typische Einsatzszenarien umfassen Food-Blogs, Produktwebsites und Gesundheitsportale

Das häufigste Szenario ist der Food-Blog oder das Online-Magazin mit Rezeptrubrik. Ein Verlag publiziert wöchentlich fünf neue Rezepte. Jedes Rezept wird im TYPO3-Backend als strukturierter Datensatz angelegt: Titel, Beschreibung, Zutatenliste mit Mengenangaben, Zubereitungsschritte als nummerierte Liste, Zeitangaben (Vorbereitung, Kochzeit, Gesamtzeit), Nährwerte pro Portion und ein Titelbild. Die Extension generiert daraus eine Detailseite mit korrektem Schema.org-Markup. Google zeigt in den Suchergebnissen das Bild, die Sterne-Bewertung, die Gesamtzeit und die Kalorienzahl.

Ein zweites Szenario sind Produktwebsites von Lebensmittelherstellern. Ein Olivenöl-Produzent zeigt zu jedem Produkt passende Rezepte. Die Rezepte verlinken auf das Produkt, das Produkt verlinkt auf die Rezepte. Diese bidirektionale Verknüpfung stärkt sowohl die Produktseite als auch die Rezeptseite in der Google-Bewertung.

Drittes Szenario: Gesundheitsportale und Ernährungsberatungen. Hier stehen die Nährwertangaben im Vordergrund. Ein Diabetes-Portal zeigt Rezepte mit Broteinheiten, glykämischem Index und Kohlenhydraten pro Portion. Die Extension erlaubt Custom Fields, sodass diese medizinisch relevanten Werte als strukturierte Daten erfasst und im Frontend prominent angezeigt werden.

## Technische Architektur nutzt Extbase-Records mit automatischem JSON-LD-Output

Die Extension registriert einen eigenen Record-Typ für Rezepte in der TYPO3-Datenbank. Jeder Record enthält Felder für Titel, Beschreibung, Zutaten (als Inline-Relational-Records), Schritte (als sortierbare Liste), Zeiten (prepTime, cookTime, totalTime im ISO-8601-Format), Nährwerte (Kalorien, Fett, Kohlenhydrate, Protein) und Bilder über FAL.

Das Frontend-Rendering läuft über Fluid-Templates, die das Rezept als HTML-Seite darstellen und gleichzeitig ein JSON-LD-Script-Tag mit dem Schema.org/Recipe-Markup in den Head der Seite schreiben. Das Markup folgt der Google-Spezifikation: name, image, author, datePublished, description, prepTime, cookTime, totalTime, recipeYield, recipeIngredient, recipeInstructions und nutrition.

Die Listenansicht zeigt Rezepte als Kacheln mit Bild, Titel, Gesamtzeit und Bewertung. Filter nach Kategorie (Vorspeise, Hauptgericht, Dessert), Diätform (vegetarisch, vegan, glutenfrei) und Zubereitungszeit sind über TypoScript konfigurierbar.

## Häufige Probleme betreffen fehlende Pflichtfelder und ungültige Zeitformate

Das grösste Problem für die Rich-Snippet-Darstellung sind fehlende Pflichtfelder. Google verlangt mindestens name, image und recipeInstructions. Wenn ein Redakteur ein Rezept ohne Bild oder ohne Zubereitungsschritte anlegt, wird das Schema.org-Markup zwar ausgegeben, aber Google ignoriert es und zeigt keinen Rich Snippet. Die Lösung: Im TYPO3-Backend Pflichtfeld-Validierung aktivieren, sodass Rezepte ohne Bild und ohne mindestens einen Zubereitungsschritt nicht gespeichert werden können.

Zweites Problem: Ungültige Zeitformate. Schema.org erwartet ISO-8601-Duration (PT30M für 30 Minuten, PT1H15M für 1 Stunde 15 Minuten). Wenn die Extension die Redakteur-Eingabe "30 min" nicht korrekt in PT30M umwandelt, scheitert die Validierung im Google Rich Results Test. Die meisten Recipe-Extensions bieten dafür separate Eingabefelder für Stunden und Minuten, die intern in ISO-8601 konvertiert werden.

Drittes Thema: Duplicate Content bei Rezepten, die auf mehreren Seiten eingebettet sind. Wenn dasselbe Rezept auf der Kategorieseite und der Detailseite vollständig angezeigt wird, erzeugt das zwei Seiten mit identischem Schema.org-Markup. Google wertet das als Duplicate. Die Lösung: Auf Kategorieseiten nur Teaser zeigen und das vollständige Schema.org-Markup ausschliesslich auf der Detailseite ausgeben.

## Die Extension läuft unter TYPO3 v11 und v12, für v13 ist ein Extbase-Update nötig

Recipe-Extensions im TYPO3-Ökosystem werden von verschiedenen Anbietern gepflegt. Die Kompatibilität mit TYPO3 v12 ist bei aktiv gewarteten Extensions gegeben. Für TYPO3 v13 sind typischerweise Anpassungen an der Extbase-Model-Konfiguration und den TCA-Definitionen nötig, weil v13 einige veraltete TCA-Typen entfernt hat. Gosign empfiehlt bei Rezept-Websites, die Schema.org-Ausgabe nach jedem TYPO3-Update mit dem Google Rich Results Test zu validieren, um sicherzustellen, dass die Markup-Qualität erhalten bleibt.

--- registeraddress TYPO3 - Newsletter-Abo | Gosign ---
> Newsletter-Registrierung über tt_address in TYPO3. Subscriber-Management direkt im CMS ohne externen Newsletter-Dienst. Double-Opt-In, Abmelde-Link,.

## Newsletter-Registrierung ohne externe Dienste spart Kosten und hält Daten unter eigener Kontrolle

Mailchimp, Brevo, Rapidmail: Für jede Newsletter-Registrierung zahlen Organisationen pro Subscriber und pro versendeter E-Mail. Bei 10.000 Abonnenten summiert sich das auf 100 bis 300 Euro monatlich, nur für die Verwaltung der Adressen. registeraddress bietet eine Alternative: Newsletter-Registrierung direkt in TYPO3 über die bewährte tt_address-Tabelle. Subscriber-Management, Double-Opt-In, Abmelde-Link und DSGVO-konforme Einwilligungsdokumentation laufen vollständig im CMS, ohne dass ein externer Dienst Zugriff auf die Abonnentendaten bekommt.

Für Vereine, kleine Verlage und öffentliche Einrichtungen mit Budgetrestriktionen ist das eine valide Architektur, vor allem dann, wenn der Newsletter-Versand über einen günstigen SMTP-Relay-Dienst wie Amazon SES (0,10 Dollar pro 1.000 E-Mails) oder den eigenen Mailserver läuft.

## Typische Einsatzszenarien umfassen Vereins-Newsletter, Intranet-Verteiler und Event-Anmeldungen

Das häufigste Szenario ist der klassische Vereins-Newsletter. Ein Sportverein mit 2.000 Mitgliedern bietet auf seiner TYPO3-Website ein Anmeldeformular. Besucher tragen ihre E-Mail-Adresse ein, erhalten eine Double-Opt-In-Mail, bestätigen und werden in die tt_address-Tabelle eingetragen. Der Verein versendet monatlich einen Newsletter über die direct_mail-Extension oder einen externen Versanddienst, der die Adressen aus tt_address importiert. registeraddress kümmert sich ausschliesslich um die Registrierung und Abmeldung, nicht um den Versand selbst.

Ein zweites Szenario sind Intranet-Verteiler in Unternehmen. Mitarbeiter melden sich für interne Informations-Newsletter an, etwa "Standort München - Kantinen-Menü" oder "IT-Wartungsfenster". Da die Daten das Unternehmensnetzwerk nicht verlassen dürfen, ist ein externer Newsletter-Dienst ausgeschlossen. registeraddress verwaltet die Anmeldungen lokal in der TYPO3-Datenbank.

Drittes Szenario: Event-Anmeldungen mit E-Mail-Bestätigung. Eine Bibliothek bietet Veranstaltungen an und nutzt registeraddress als leichtgewichtiges Anmeldeformular. Die Bestätigungsmail nach dem Double-Opt-In enthält Datum, Uhrzeit und Ort der Veranstaltung. Das ist keine vollwertige Event-Management-Lösung, aber für Einrichtungen mit fünf bis zehn Veranstaltungen pro Monat ausreichend.

## Technische Architektur baut auf tt_address und dem Double-Opt-In-Workflow

registeraddress ist als Extbase-Plugin implementiert und nutzt die tt_address-Tabelle als Datenbank. Jede Registrierung durchläuft einen dreistufigen Prozess: Formular-Eingabe, Double-Opt-In-Mail mit Bestätigungslink, Aktivierung des Eintrags nach Klick auf den Link. Der Bestätigungslink enthält einen kryptographisch signierten Token, der nach einer konfigurierbaren Zeitspanne (Standard: 48 Stunden) abläuft.

Die Extension registriert ein Frontend-Plugin, das über TypoScript konfiguriert wird: Pflichtfelder, optionale Felder (Name, Firma, Anrede), Bestätigungstext, E-Mail-Templates für Double-Opt-In und Willkommensmail. Die Fluid-Templates sind per SiteSet überschreibbar, sodass das Formular ins Design der Website passt.

Für die DSGVO-Konformität speichert registeraddress den Zeitpunkt der Einwilligung, die IP-Adresse, den User-Agent und die Version der Datenschutzerklärung, auf die im Formular verlinkt wurde. Bei einer Behördenanfrage lässt sich nachweisen, wann und unter welchen Bedingungen der Subscriber zugestimmt hat.

Abmeldungen laufen über einen Link im Newsletter-Footer, der den tt_address-Eintrag deaktiviert (nicht löscht), sodass die Einwilligungshistorie erhalten bleibt. Endgültige Löschungen gemäss Art. 17 DSGVO (Recht auf Löschung) können über ein separates Löschformular oder manuell im Backend erfolgen.

## Häufige Probleme betreffen Double-Opt-In-Mails im Spam und veraltete tt_address-Versionen

Das dominierende Problem ist die Zustellbarkeit der Double-Opt-In-Mail. Wenn die Bestätigungsmail im Spam-Ordner landet, schliesst der Subscriber die Registrierung nie ab. Die Ursachen sind fast immer server-seitig: fehlender SPF-Record, kein DKIM-Signatur, kein DMARC-Policy. registeraddress selbst kann die Zustellbarkeit nicht verbessern, weil das ein Mailserver-Thema ist. Wir empfehlen, vor dem Launch eines Newsletter-Formulars die E-Mail-Authentifizierung mit mail-tester.com zu prüfen.

Zweites Problem: Inkompatibilität mit älteren tt_address-Versionen. registeraddress setzt auf bestimmte Felder in der tt_address-Tabelle. Wenn tt_address ein Major-Update veröffentlicht und Felder umbenennt oder entfernt, kann registeraddress die Einträge nicht mehr korrekt schreiben. Die Lösung: tt_address und registeraddress immer gemeinsam aktualisieren und nach dem Update einen Testdurchlauf des gesamten Registrierungsprozesses machen.

Drittes Thema: Bot-Registrierungen. Ohne Schutzmechanismus füllen Bots das Formular mit Fake-Adressen und erzeugen Tausende von Double-Opt-In-Mails, die den Mailserver belasten und die Sender-Reputation schädigen. registeraddress unterstützt Honeypot-Felder und kann mit sr_freecap oder hcaptcha kombiniert werden, um Bots abzuwehren.

## TYPO3 v12 wird unterstützt, v13-Kompatibilität erfordert ein tt_address-Alignment

registeraddress läuft unter TYPO3 v11 und v12 stabil, vorausgesetzt tt_address ist in einer kompatiblen Version installiert. Für TYPO3 v13 hängt die Kompatibilität sowohl von registeraddress als auch von tt_address ab, da beide Extensions unabhängig gepflegt werden. Gosign prüft bei TYPO3-Upgrades die gesamte Newsletter-Kette (Registrierung, Adressverwaltung, Versand) auf Kompatibilität und empfiehlt bei Bedarf den Umstieg auf einen externen Newsletter-Dienst mit API-Anbindung, wenn die TYPO3-native Lösung nicht mehr gepflegt wird.

--- rflipbook TYPO3 - Digitales Blätterbuch | Gosign ---
> rflipbook für TYPO3: PDFs als interaktive Flipbooks. Setup, Performance-Optimierung & moderne Alternativen.

## rflipbook verwandelt Kataloge und Broschüren in eine Blätterbuch-Erfahrung - und ist für Content-Teams die pragmatischste Lösung, wenn PDFs nicht nur verlinkt, sondern im Kontext der Website erlebbar bleiben sollen

Wer einen mehrseitigen Katalog, einen Jahresbericht oder ein Kundenmagazin als PDF pflegt, steht vor einem Dilemma: Als Download liegt das Dokument in einer Sackgasse, der Nutzer verlässt die Seite und kommt selten zurück. rflipbook löst das, indem es jede PDF-Seite als Canvas rendert und den klassischen Blätter-Effekt aus der Print-Welt im Browser nachbildet. Die Extension adressiert ein konkretes Publishing-Problem: Marketing-, Presse- und Investor-Relations-Teams wollen bestehende Print-Assets digital zweitverwerten, ohne sie in HTML zu übersetzen. rflipbook macht diesen Umweg unnötig.

Zu beachten ist, dass rflipbook nicht nur Darstellungstechnik ist, sondern auch ein Content-Signal. Eine Website, die aktuelle Kataloge und Berichte als Flipbook führt, wirkt auf potenzielle Kunden gepflegt - im Gegensatz zu verwaisten Download-Verzeichnissen mit Dokumenten aus unterschiedlichen Jahren. Redaktionell gehört zur Einführung daher auch eine Klärung, wer welches PDF wann aktualisiert.

## Typische Einsatzszenarien

Der häufigste Fall ist der B2B-Produktkatalog. Ein Maschinenbauer pflegt seinen Gesamtkatalog in InDesign, exportiert ein 80-seitiges PDF und bindet es über rflipbook auf der Produktseite ein. Für die Redaktion ändert sich nichts, für den Besucher wird aus einem trockenen Download ein Blätter-Erlebnis mit Vorschauseite und Suchfunktion.

Der zweite Anwendungsfall sind Geschäfts- und Nachhaltigkeitsberichte. Börsennotierte Unternehmen, Stiftungen und Verbände veröffentlichen jährlich umfangreiche Berichte, die nicht neu getextet werden. rflipbook bettet das fertige PDF direkt in die IR-Seite ein und schlägt die Brücke zwischen der klassischen Redaktion und dem Web-Team.

Dritter Fall: Kunden- und Mitarbeitermagazine. Hochschulen, Kommunen oder Mittelständler nutzen rflipbook, um ihr Print-Magazin als digitale Ausgabe bereitzustellen, oft mit Archiv-Funktion und mehrsprachigen Ausgaben pro Jahrgang.

## Technische Architektur

rflipbook integriert sich als klassische TYPO3-Extension über ein Content-Element im Page-Modul. Redakteure laden das PDF in den FAL-Dateispeicher, verknüpfen es mit dem Content-Element und legen im Backend Parameter wie Hintergrundfarbe, Startseite und Download-Button fest. Im Frontend übernimmt eine JavaScript-Library wie Turn.js oder eine vergleichbare Canvas-Rendering-Bibliothek das eigentliche Darstellen. PDF.js wird dabei häufig als Parser eingesetzt, um die PDF-Seiten in einzelne Bitmaps zu zerlegen.

Die Dependency-Kette ist überschaubar: rflipbook bringt die JavaScript-Libraries im Extension-Paket mit, die Extension selbst benötigt keine zusätzlichen PHP-Pakete. Die Konfiguration erfolgt über TypoScript für globale Defaults und über die Flexform des Content-Elements für seitenspezifische Anpassungen. Wer mit EXT:fluid_styled_content arbeitet, kann das Template über Fluid-Overrides in den eigenen Sitepackage ziehen und an das CI anpassen.

Kritisch ist das Zusammenspiel mit dem Asset-Handling. Große PDFs sollten serverseitig in einzelne JPGs vorgerendert werden, sonst lädt der Browser beim ersten Aufruf alles synchron. Lazy Page Loading ist keine Standardfunktion, lässt sich aber über eine eigene Render-Pipeline nachrüsten.

## Häufige Probleme und Lösungen

Das häufigste Problem ist die Ladezeit. Ein 40-seitiger Katalog mit hochauflösenden Fotos erzeugt leicht eine Initial-Payload von mehreren Megabyte, was Lighthouse-Scores im roten Bereich und schlechte Core Web Vitals bedeutet. Die Lösung liegt nicht in der Extension selbst, sondern davor: PDFs vor dem Upload auf die tatsächlich benötigte Bildschirm-Auflösung herunterrechnen, idealerweise über Ghostscript oder eine serverseitige Build-Pipeline, und nur die ersten zwei bis drei Seiten beim Erstaufruf laden.

Zweites Problem: Darstellung auf Mobilgeräten. Der Blättereffekt funktioniert auf Touchscreens unter 400 Pixel Breite schlecht, Redakteure beschweren sich über unlesbare Seiten. Pragmatische Lösung: per CSS-Media-Query auf Mobilgeräten vom Flipbook auf einen einfachen PDF.js-Viewer mit vertikaler Scroll-Ansicht umschalten. Die User Experience wird dadurch ehrlicher, die Ladezeit besser.

Drittes Problem: Barrierefreiheit. Screenreader können Canvas-gerenderte PDFs nicht lesen, was bei Behörden und öffentlichen Einrichtungen zum Compliance-Problem wird. Hier hilft nur ein zweigleisiger Ansatz - das Flipbook als visuelle Ergänzung, daneben zwingend ein direkter Link zum Original-PDF und idealerweise eine HTML-Version der Kerninhalte. Die BITV 2.0 und die EN 301 549 verlangen das ausdrücklich.

## Migration und Versions-Kompatibilität

rflipbook ist eine etablierte, aber nicht mehr aktiv weiterentwickelte Extension. Für TYPO3 v11 gibt es eine lauffähige Version, unter v12 und v13 läuft sie nur noch mit manuellen Anpassungen an der ext_emconf.php und dem Service-Konfigurationsschema. Wer heute neu startet, sollte sich die Frage stellen, ob eine leichtgewichtige Alternative nicht die bessere Wahl ist: ein schlanker PDF.js-Viewer, statische HTML-Seiten aus dem PDF-Inhalt oder ein Headless-Flipbook-Service, der als iframe eingebunden wird. Die Entscheidung hängt davon ab, wie oft sich das Dokument ändert und wie wichtig der visuelle Blätter-Effekt für die Marke ist.

Wer auf TYPO3 v11 bleibt, sollte rflipbook nicht als dauerhafte Lösung sehen. Spätestens beim Upgrade auf v12 ist eine Entscheidung nötig, und die Vorlaufzeit dafür sollte früh eingeplant werden. Ein typisches Migrations-Projekt umfasst die Analyse aller Flipbook-Einsätze im Bestand, die Entscheidung pro Fall (statische HTML-Version, leichter PDF-Viewer oder Beibehaltung als Flipbook), die Umsetzung und die redaktionelle Schulung. Wer das Projekt strategisch angeht, nutzt die Migration zugleich für ein Asset-Aufräumen: veraltete Kataloge werden archiviert, Dokumente in den aktuellen Versionen neu eingebunden und Metadaten vereinheitlicht.

Gosign begleitet beide Wege - Weiterbetrieb von rflipbook auf modernen TYPO3-Versionen und die Migration zu performanteren Alternativen. KI-gestützte Analyse hilft dabei, die richtige Architektur für den konkreten Content-Case zu finden, statt eine Standardantwort zu geben.

--- FontAwesome CKEditor TYPO3 | Gosign ---
> FontAwesome Icons direkt im CKEditor-Richtext einfügen. Gosign berät auch zu SVG-Icon-Systemen als performantere Alternative, kein 300KB Font-File.

## Warum FontAwesome im CKEditor Redakteuren nützt, aber 300 KB Performance kostet

Redakteure wollen Icons neben Überschriften, in Tabellen und zwischen Textabsätzen platzieren. Ohne technische Hilfe kopieren sie Icon-Bilder als Inline-Images in den RTE - mit kaputtem Layout und inkonsistenter Grösse als Ergebnis. rte_ckeditor_fontawesome löst das Problem sauber: Redakteure wählen Icons aus dem FontAwesome-Katalog direkt im CKEditor per Dialog-Button aus und fügen sie als `<i>`-Tag in den Richtext ein. Die Icons skalieren automatisch mit der Textgrösse, sind farblich anpassbar und funktionieren in jedem Content-Element.

Der Preis dafür: Die gesamte FontAwesome-Library (ca. 300 KB als Webfont oder 180 KB als SVG-Sprite) wird auf jeder Seite geladen, auch wenn nur 3 Icons verwendet werden. Für performancekritische Websites ist das ein spürbarer Overhead.

## Typische Einsatzszenarien

**Icon-Listen in Service-Beschreibungen.** Ein Dienstleister beschreibt seine Leistungen mit Icon-Listen: Häkchen vor jedem Vorteil, Zahnrad vor jedem Prozessschritt, Telefon-Icon vor der Kontaktnummer. Der Redakteur fügt die Icons direkt im CKEditor ein, ohne einen Entwickler bitten zu müssen. Das funktioniert in Textfeldern, Tabellen und Listen gleichermassen.

**Feature-Vergleichstabellen.** Produktmanager pflegen Vergleichstabellen im CKEditor. Statt "Ja" und "Nein" verwenden sie grüne Häkchen- und rote Kreuz-Icons. rte_ckeditor_fontawesome stellt diese Icons über den FontAwesome-Katalog bereit. Die Tabelle wird visuell sofort verständlich.

**Newsletter-Vorlagen mit Icons.** Unternehmen, die Newsletter-Inhalte im TYPO3-Backend pflegen und über eine Newsletter-Extension versenden, nutzen FontAwesome-Icons für visuelle Auflockerung. Da die Icons als `<i>`-Tags eingefügt werden, funktionieren sie in E-Mail-Clients, die Webfonts unterstützen.

## Technische Architektur

rte_ckeditor_fontawesome erweitert den CKEditor im TYPO3-Backend um ein zusätzliches Plugin. Das Plugin registriert einen Button in der CKEditor-Toolbar, der einen Auswahl-Dialog öffnet.

Die Integration funktioniert auf drei Ebenen:

- **CKEditor-Plugin**: Ein JavaScript-Plugin für CKEditor 4 (TYPO3 v10/v11) bzw. CKEditor 5 (TYPO3 v12+). Das Plugin rendert den Icon-Auswahl-Dialog mit Suchfunktion und Kategorie-Filter. Die verfügbaren Icons werden aus einer JSON-Datei geladen, die den FontAwesome-Katalog abbildet.
- **HTML-Ausgabe**: Beim Einfügen wird ein `<i>`-Tag mit den entsprechenden CSS-Klassen in den Richtext geschrieben: `<i class="fas fa-check"></i>` für ein Solid-Häkchen, `<i class="far fa-envelope"></i>` für ein Outline-Briefumschlag. Der RTE speichert das Tag als normalen HTML-Inhalt in der Datenbank.
- **Frontend-Rendering**: Damit die Icons im Frontend sichtbar sind, muss die FontAwesome-CSS-Library auf der Website geladen werden. Das kann als Webfont (CSS + Font-Dateien, ca. 300 KB) oder als SVG-Framework (JavaScript + SVG-Sprite, ca. 180 KB) geschehen. Die Extension liefert die Frontend-Assets nicht mit - die Integration in das Frontend-Template obliegt dem Entwickler.

Abhängigkeiten: TYPO3 Core mit CKEditor (seit v8 im Core), FontAwesome Frontend-Assets (separat einzubinden).

Wichtiger Hinweis zur CKEditor-Version: TYPO3 v12 wechselt von CKEditor 4 auf CKEditor 5. Die Plugin-Architektur hat sich grundlegend geändert. rte_ckeditor_fontawesome-Plugins für CKEditor 4 funktionieren nicht in CKEditor 5. Ein Upgrade erfordert ein komplett neues Plugin.

## Häufige Probleme und Lösungen

**Problem: Icons werden im Frontend nicht angezeigt.** Die häufigste Ursache: FontAwesome-CSS ist nicht im Frontend-Template eingebunden. Die Extension kümmert sich nur um den Backend-Teil (Icon-Auswahl im CKEditor). Die Frontend-Darstellung erfordert, dass `fontawesome.min.css` und die zugehörigen Font-Dateien (woff2) im Template geladen werden. Die Lösung: FontAwesome über TypoScript als CSS-Include hinzufügen oder über das Asset-Management der TYPO3-Site-Configuration einbinden.

**Problem: Icons erscheinen als leere Kästchen.** Die Font-Dateien (woff2, woff) werden nicht korrekt geladen. Häufig ist der Pfad in der CSS-Datei falsch konfiguriert, oder der Webserver blockiert Font-Dateien (fehlende CORS-Header bei CDN-Einbindung). Die Lösung: FontAwesome lokal hosten statt per CDN einzubinden. Das vermeidet CORS-Probleme und ist DSGVO-konformer, weil keine Drittanbieter-Requests stattfinden.

**Problem: Performance-Impact durch FontAwesome.** Eine vollständige FontAwesome-Installation lädt 300+ KB (alle Icon-Kategorien: Solid, Regular, Brands). Wenn die Website nur 10 Icons nutzt, sind 290 KB verschwendet. Die Lösung: FontAwesome Subsetting einsetzen - nur die verwendeten Icons in eine Custom-Font-Datei kompilieren. Alternativ: Auf ein SVG-Icon-System umsteigen, das nur die tatsächlich verwendeten Icons als Inline-SVG einbettet.

## Migration und Versions-Kompatibilität

rte_ckeditor_fontawesome ist für TYPO3 v10 und v11 (CKEditor 4) als stabile Extension verfügbar. Für TYPO3 v12 (CKEditor 5) existieren Anpassungen, da die Plugin-Architektur komplett neu ist. CKEditor 5 verwendet ein modernes JavaScript-Module-System statt der CKEditor-4-Plugin-API.

Für TYPO3 v13 und darüber hinaus empfiehlt Gosign eine grundsätzliche Neubewertung des Ansatzes. Statt FontAwesome als Webfont zu laden, setzen moderne Websites auf SVG-Icon-Systeme: Jedes Icon wird als Inline-SVG eingebettet, nur die genutzten Icons werden geladen, die Dateigrösse sinkt von 300 KB auf unter 10 KB. Für Redakteure kann ein Custom CKEditor-Widget entwickelt werden, das Icons aus einem SVG-Sprite auswählen lässt.

Der Migrationsaufwand von FontAwesome auf SVG-Icons beträgt typischerweise 2 bis 3 Tage: SVG-Sprite erstellen, CKEditor-Widget anpassen, bestehende `<i>`-Tags im Content durch `<svg>`-Referenzen ersetzen. Gosign automatisiert den letzten Schritt über ein Migrationsskript, das alle `<i class="fa-*">`-Tags in der Datenbank identifiziert und umschreibt.

Bei der Entscheidung zwischen FontAwesome und SVG-Icons lohnt ein Blick auf die Zahlen: FontAwesome Free enthält über 2.000 Icons, FontAwesome Pro über 7.000. Eine typische Unternehmenswebsite nutzt davon 15 bis 30. Den Rest zahlen alle Besucher als Ladezeit. Ein massgeschneidertes SVG-Sprite mit 30 Icons wiegt 8 bis 15 KB - ein Fünfzigstel der vollständigen FontAwesome-Library. Für Websites, die auf Core Web Vitals und PageSpeed optimiert sind, ist die Entscheidung eindeutig.

--- rte_ckeditor_image TYPO3 - Bilder im RTE | Gosign ---
> rte_ckeditor_image: Bilder im CKEditor einfügen und bearbeiten. Responsive-Ausgabe, Fehlerbehebung, Alternativen.

## rte_ckeditor_image bringt professionelle Bildverwaltung in den Rich Text Editor

Der TYPO3-CKEditor erlaubt nur einfache Bild-Einbindungen per img-Tag, ohne Verbindung zum File Abstraction Layer und ohne responsive Varianten. Für Redaktionen, die regelmässig Bilder in Artikel, News-Beiträge oder Magazin-Texte einfügen, reicht das nicht: Sie brauchen Zuschnitt, Skalierung, Alt-Text, Copyright, Linkziel und vor allem srcset-Ausgabe. rte_ckeditor_image von Netresearch ergänzt den CKEditor um genau diese Funktionen und integriert ihn sauber in den FAL. Auf jedem TYPO3-Projekt mit redaktionell gepflegten Fliesstext-Bildern ist die Extension seit Jahren das Standard-Tool und zählt zu den am häufigsten installierten Redaktions-Helfern im Ökosystem.

## Typische Einsatzszenarien liegen in Redaktionen mit hohem Bildaufkommen

Online-Magazine und Corporate-News-Seiten sind die klassische Zielgruppe. Ein Magazin mit 200 Artikeln pro Jahr bindet pro Beitrag zwei bis fünf Bilder im Fliesstext ein, zusätzlich zu Teaser- und Header-Bildern. Ohne rte_ckeditor_image müsste die Redaktion für jedes Inline-Bild einen Content-Element-Wechsel akzeptieren und den Textfluss unterbrechen. Mit der Extension fügt sie das Bild direkt über einen Toolbar-Button ein, wählt die FAL-Referenz, setzt Alt-Text und Bildunterschrift und kehrt ohne Kontextwechsel zum Schreiben zurück. Der Effizienzgewinn lässt sich in der Praxis messen: Bei einer Redaktion mit 200 Beiträgen pro Jahr und durchschnittlich vier Bildern pro Beitrag sparen wir pro Artikel etwa zwei Minuten Setup-Zeit, was aufs Jahr gerechnet knapp 30 Arbeitsstunden ausmacht.

Ein zweites Szenario sind Produktkataloge und Technische Dokumentation. Wer in einem TYPO3-Katalog Schritt-für-Schritt-Anleitungen mit Inline-Screenshots pflegt, braucht die Bilder direkt im Text. rte_ckeditor_image erlaubt das mit den gleichen FAL-Referenzen, die auch im restlichen Projekt verwendet werden - Bild-Updates erfolgen an einer Stelle und wirken sich überall aus.

Ein drittes Szenario ist die Migration von TYPO3-Installationen aus der htmlArea-Ära. Wer bisher den RTEhtmlArea im Einsatz hatte, fand dort eine ähnliche Bildverwaltung. Beim Umstieg auf CKEditor ist rte_ckeditor_image die direkte Ersatz-Extension, damit Redakteure den gewohnten Workflow weiternutzen können. Ohne die Extension fällt der Redaktion beim Upgrade nicht nur eine Funktion weg, sondern ein kompletter Arbeitsschritt, der sich nur mühsam durch zusätzliche Content-Elemente ersetzen lässt.

## Technische Architektur erweitert den CKEditor-Toolbar per Plugin

Die Extension besteht aus einem CKEditor-Plugin, das den Image-Button und den Image-Dialog registriert, sowie einem serverseitigen Rendering, das den Marker im gespeicherten HTML in eine Fluid-Ausgabe übersetzt. Das Plugin kommuniziert mit einem AJAX-Endpunkt, der die FAL-Referenz, das Cropping und die Alt-Texte verarbeitet.

Im Datenbank-Content steht das Bild als HTML-Markierung mit den data-Attributen data-htmlarea-file-uid und data-htmlarea-file-table, begleitet von weiteren Attributen für Cropping, Zoom und Height. Beim Rendering ersetzt ein Pre-Processor den Markierungs-Tag durch einen vollen Image-ViewHelper-Call, der srcset, webp-Varianten und Lazy-Loading-Attribute erzeugt. Die verfügbaren Bildbreiten werden per YAML in der RTE-Konfiguration definiert. Ein typisches Magazin-Setup arbeitet mit drei bis fünf Bildbreiten (480, 768, 1024, 1440, 2048) und erzeugt daraus automatisch ein responsive srcset, das auf mobilen Geräten nur die kleinste Variante lädt.

Das Cropping nutzt das TYPO3-Core-Cropping-Werkzeug: Im Bild-Dialog erscheint der Crop-Editor aus dem Backend, mit denselben Varianten-Presets wie beim regulären Bild-Content-Element. Cropping wird pro Bild-Instanz gespeichert, sodass dasselbe FAL-Bild in verschiedenen Artikeln unterschiedlich zugeschnitten sein kann. Das ist besonders wichtig, wenn ein Bild sowohl im Magazin-Teaser (quadratisch) als auch im Fliesstext (landscape) verwendet wird, ohne dass die Redaktion zwei separate Dateien pflegen muss.

## Häufige Probleme betreffen responsive Ausgabe, WebP und CKEditor-5-Kompatibilität

Das häufigste Supportthema ist die fehlende srcset-Ausgabe. Der Default-Rendering-Pfad erzeugt kein srcset, wenn die RTE-YAML keine Bildbreiten-Definition enthält. Viele Installationen haben die YAML vom TYPO3-Core kopiert und dabei den Abschnitt "proc.entryHTMLparser_db.allowedAttribs" oder "config.additionalAttributes" ausgelassen. Die Lösung ist eine vollständige YAML mit explizit definierten srcset-Breiten.

Das zweite Problem ist WebP. Wer moderne Bildformate ausliefern will, muss den TYPO3-ImageMagick-Provider oder einen GraphicsMagick-Setup mit WebP-Unterstützung einrichten. rte_ckeditor_image selbst erzeugt keine WebP-Konvertierung, sondern greift auf den Core-Image-Processor zurück. Ohne korrekte Provider-Konfiguration bleiben die Bilder als JPEG in der Ausgabe.

Drittens stellt CKEditor 5 einen Architektur-Wechsel dar. TYPO3 v12 bringt CKEditor 5 mit, der ein anderes Plugin-Modell verwendet. Die rte_ckeditor_image-Versionen 10.x und 11.x sind auf CKEditor 5 portiert und funktionieren in v12 out of the box. Eigene Anpassungen, die auf CKEditor 4 basieren, müssen beim Upgrade angepasst werden. Wer Custom-Plugins oder eigene Toolbar-Buttons gebaut hat, sollte für die Migration mindestens ein bis zwei Entwicklertage einplanen.

## Migration auf TYPO3 v12 und v13 verlangt Versionssprung der Extension

rte_ckeditor_image wird von Netresearch aktiv gepflegt und ist für TYPO3 v11, v12 und v13 verfügbar. Der grössere Sprung liegt zwischen den Extension-Versionen 9.x (CKEditor 4) und 10.x/11.x (CKEditor 5). Wer eine TYPO3-v10- oder v11-Installation mit Extension 9.x auf TYPO3 v12 hebt, muss gleichzeitig auf die 10.x-Serie der Extension wechseln. Die Datenbank-Repräsentation der Inline-Bilder bleibt dabei kompatibel, sodass bestehende Artikel ohne Inhalts-Migration funktionieren.

Bei Gosign prüfen wir vor jedem TYPO3-Upgrade, ob die Projekt-RTE-YAML an die Extension-Version angepasst werden muss und ob eigene Plugin-Anpassungen oder überschriebene ViewHelper existieren. In vielen Projekten mit TYPO3 v12 lässt sich ausserdem prüfen, ob die nativen CKEditor-5-Bildfunktionen ausreichen und die Extension mittelfristig abgebaut werden kann. Für Redaktionen mit Cropping- und srcset-Bedarf bleibt rte_ckeditor_image allerdings die pragmatischste Option. Die Alternative wäre ein eigener Bild-Toolbar-Button mit custom CKEditor-Plugin, was deutlich aufwändiger ist und die Pflege dauerhaft in den Projektverantwortung holt.

--- rx_shariff TYPO3 - Datenschutz-Sharing | Gosign ---
> rx_shariff: Social Sharing ohne Tracking. DSGVO-konforme Buttons für TYPO3. Setup & Alternativen.

## Warum Standard-Social-Buttons ein DSGVO-Problem sind und rx_shariff die Lösung war

Jeder Facebook-Like-Button, jeder Twitter-Share-Widget und jedes LinkedIn-Embed überträgt personenbezogene Daten an die Plattform - und zwar beim Seitenaufruf, nicht erst beim Klick. IP-Adresse, Browser-Fingerprint und Referrer fliessen an Facebook, bevor der Besucher auch nur die Möglichkeit hat, zuzustimmen. Das ist seit Inkrafttreten der DSGVO 2018 rechtlich problematisch und führte bereits zu Abmahnungen gegen Website-Betreiber.

rx_shariff implementiert das Shariff-Prinzip, das der Heise-Verlag 2014 als Antwort auf dieses Problem entwickelt hat: Statt die Original-Widgets der Plattformen einzubinden, rendert rx_shariff eigene, datenschutzkonforme Buttons. Erst wenn ein Besucher auf den Button klickt, wird eine Verbindung zur Plattform hergestellt. Kein Tracking, kein Third-Party-Request, keine Cookies ohne Interaktion.

## Typische Einsatzszenarien

**Unternehmenswebsites mit DSGVO-Compliance-Anforderung.** Ein mittelständisches Unternehmen will auf seinen Blog-Artikeln Social-Share-Buttons anbieten, ohne gegen die DSGVO zu verstossen. Der Datenschutzbeauftragte hat die Standard-Widgets von Facebook und Twitter explizit untersagt. rx_shariff liefert Buttons, die erst bei Klick eine Verbindung herstellen. Die Datenschutzerklärung kann korrekt formuliert werden: "Erst bei aktiver Nutzung der Share-Buttons werden Daten an Dritte übertragen."

**Medien-Websites mit Share-Counter.** Ein Fachverlag will unter jedem Artikel anzeigen, wie oft er auf Facebook und LinkedIn geteilt wurde. rx_shariff bietet diese Funktion über ein optionales Backend-Proxy: Der TYPO3-Server fragt regelmässig die Share-Counts bei den Plattformen ab und cached die Ergebnisse. Die Plattformen sehen nur den Server, nie den einzelnen Besucher.

**Intranet-Portale mit kontrolliertem Sharing.** Ein Unternehmen betreibt ein TYPO3-Intranet und will bestimmte Artikel gezielt über LinkedIn teilbar machen, aber Facebook und Twitter ausschliessen. rx_shariff lässt sich so konfigurieren, dass nur ausgewählte Plattformen als Buttons erscheinen. Die Konfiguration erfolgt pro Seitenbaum oder pro Content-Element. Im Intranet-Kontext ist das besonders relevant, weil versehentliches Teilen interner Informationen auf öffentlichen Plattformen verhindert werden muss.

## Technische Architektur

rx_shariff besteht aus zwei Komponenten: einem Frontend-Widget und einem optionalen Backend-Service.

**Frontend-Widget:** Das TYPO3-Plugin rendert für jede konfigurierte Plattform einen HTML-Button. Dieser Button ist ein einfacher Anchor-Link (`<a href="...">`) mit einem Share-URL als Ziel. Beim Klick öffnet sich die Share-Dialog-Seite der Plattform in einem neuen Fenster. Kein JavaScript wird beim Seitenaufruf geladen, keine Cookies gesetzt, keine externe Ressource angefragt.

**Backend-Service (optional):** Für Share-Counter betreibt rx_shariff einen Server-seitigen Proxy. Ein PHP-Script fragt die APIs der Plattformen ab (Facebook Graph API, LinkedIn Share API) und cached die Ergebnisse in einer Datenbanktabelle. Das Frontend zeigt den gecachten Counter an. Der Proxy aktualisiert die Counter per Scheduler-Task alle 15 bis 60 Minuten. Die Plattform-APIs sehen nur die Server-IP, nie die IP des Website-Besuchers.

Die Konfiguration erfolgt über TypoScript und Extension-Einstellungen:

- Auswahl der Plattformen (Facebook, Twitter/X, LinkedIn, Xing, Pinterest, WhatsApp, Telegram, E-Mail)
- Darstellungsvariante (Icons, Buttons mit Text, kompakte Variante)
- Theme-Anpassung über CSS-Klassen
- Share-Counter aktivieren/deaktivieren
- Backend-Service-URL für Counter

Abhängigkeiten: TYPO3 Core. Für den Share-Counter: PHP mit cURL-Unterstützung, gültige API-Keys für die Plattformen (Facebook Graph API erfordert App-Registrierung).

## Häufige Probleme und Lösungen

**Problem: Share-Counter zeigen immer 0 an.** Die Plattform-APIs erfordern Authentifizierung. Ohne gültigen API-Key liefern Facebook und LinkedIn keine Counter. Twitter/X hat seine Share-Count-API 2015 komplett abgeschaltet - ein Counter für Twitter ist technisch nicht mehr möglich. Die Lösung: Facebook-App im Meta Developer Portal anlegen und den App-Token in rx_shariff konfigurieren. Für Twitter den Counter deaktivieren oder auf X-API v2 mit OAuth 2.0 umsteigen, die aber keinen Share-Counter bietet.

**Problem: Buttons sind nach TYPO3-Update nicht mehr sichtbar.** rx_shariff nutzt ein TYPO3-Plugin mit eigenem Content-Element. Wenn das Plugin nach einem Update nicht mehr registriert ist (z.B. durch geänderte Composer-Abhängigkeiten), verschwindet das Content-Element aus dem Frontend. Die Lösung: Extension im Extension Manager prüfen, Composer-Abhängigkeiten aktualisieren, `vendor/bin/typo3 cache:flush` ausführen.

**Problem: WhatsApp-Share funktioniert nur auf Mobilgeräten.** WhatsApp Web und die Desktop-App unterstützen den `whatsapp://`-URL-Scheme nicht einheitlich. Auf Desktop-Browsern führt der Klick auf den WhatsApp-Button ins Leere. Die Lösung: Auf Desktop die Web-URL `https://api.whatsapp.com/send?text=...` verwenden, auf Mobilgeräten das App-Scheme. rx_shariff erkennt den User-Agent und wählt den richtigen Link automatisch.

## Migration und Versions-Kompatibilität

rx_shariff ist für TYPO3 v10 und v11 als stabiles Composer-Paket verfügbar. Für TYPO3 v12 existieren Community-Forks, da die ursprüngliche Extension nicht mehr aktiv gepflegt wird. Das Shariff-JavaScript-Projekt von Heise selbst wurde 2022 in den Maintenance-Modus versetzt.

Für neue Projekte ab TYPO3 v12 empfiehlt Gosign eine Neubewertung: Einfache Share-Links (`href="https://www.facebook.com/sharer/sharer.php?u=..."`) sind leichtgewichtiger als rx_shariff, DSGVO-konform und benötigen keine Extension. Der Nachteil: Kein Share-Counter. Wer Counter braucht, muss die API-Abfrage selbst implementieren oder auf einen Dienst wie ShareThis mit Consent-Management ausweichen.

Die Migration von rx_shariff auf einfache Share-Links beträgt typischerweise einen halben Tag: Altes Plugin entfernen, neue Fluid-Partials für Share-Links erstellen, CSS anpassen. Gosign hat diesen Wechsel bei mehreren Kunden durchgeführt und dabei die Seitenladezeit um 150 bis 300ms verbessert, weil das Shariff-JavaScript und die Counter-Abfragen entfallen.

Der einfache Share-Link-Ansatz deckt die gängigen Plattformen ab: Facebook (`https://www.facebook.com/sharer/sharer.php?u={url}`), LinkedIn (`https://www.linkedin.com/sharing/share-offsite/?url={url}`), X/Twitter (`https://twitter.com/intent/tweet?url={url}&text={title}`), E-Mail (`mailto:?subject={title}&body={url}`) und WhatsApp (`https://api.whatsapp.com/send?text={url}`). Alle Links sind datenschutzkonform, weil kein JavaScript geladen und kein Third-Party-Cookie gesetzt wird. Die Links können als Fluid-Partial in jedes Template eingebunden und über CSS-Klassen gestylt werden.

--- SAML2 TYPO3 - SSO Integration | Gosign ---
> SAML 2.0 Single Sign-On direkt in TYPO3, ohne Shibboleth SP auf dem Server. Alternative zu shibboleth_auth für IdPs, die kein OIDC unterstützen.

## SAML 2.0 ermöglicht Single Sign-On in TYPO3 ohne Shibboleth-Installation auf dem Server

Hochschulen, Behörden und Konzerne betreiben Identity Provider (IdP), die auf SAML 2.0 basieren: Microsoft ADFS, Okta, Keycloak, PingFederate. Wer diese Identitäten in TYPO3 nutzen will, brauchte bisher einen Shibboleth Service Provider auf dem Webserver, eine zusätzliche Softwareschicht mit eigener Konfiguration, eigenen Zertifikaten und eigener Wartung. Die TYPO3-Extension saml2 macht den Shibboleth SP überflüssig. Sie implementiert den SAML 2.0 SP direkt in PHP und kommuniziert ohne Middleware mit dem IdP. Das vereinfacht die Server-Architektur erheblich, besonders auf Shared-Hosting-Umgebungen oder in Container-Deployments, wo ein Shibboleth SP schwer zu installieren ist.

Für Organisationen, deren IdP kein OIDC (OpenID Connect) unterstützt, ist SAML 2.0 der einzige standardisierte Weg zum Single Sign-On. Die Extension schliesst genau diese Lücke im TYPO3-Ökosystem.

## Typische Einsatzszenarien betreffen Hochschul-Intranets, Behörden-Portale und Konzern-Extranets

Das häufigste Szenario ist das Hochschul-Intranet. Eine Universität betreibt einen Shibboleth IdP im DFN-AAI-Verbund (Deutsches Forschungsnetz). Studierende und Mitarbeitende melden sich mit ihrer Hochschulkennung an und erhalten Zugang zu geschützten TYPO3-Seiten: Skripte, interne Nachrichten, Prüfungsergebnisse. Die saml2-Extension prüft das SAML-Assertion-Token, legt bei Bedarf einen TYPO3-Frontend-User an und weist Gruppen basierend auf den IdP-Attributen zu (z.B. Studierende = Gruppe "student", Dozierende = Gruppe "staff").

Ein zweites Szenario sind Behörden-Portale mit BundID-Anbindung. Seit 2023 ist BundID der zentrale Identitätsdienst des Bundes. SAML 2.0 ist eines der unterstützten Protokolle. Eine Kommune kann ihre TYPO3-Website über saml2 an BundID anbinden, sodass Bürger sich mit ihrem Personalausweis (eID) oder Elster-Zertifikat anmelden und auf personalisierte Dienstleistungen zugreifen.

Drittes Szenario: Konzern-Extranets. Ein Automobilhersteller betreibt ein Händlerportal auf TYPO3. Händler melden sich über den Konzern-IdP (Microsoft ADFS) an und sehen Preislisten, Schulungsunterlagen und Bestellformulare, die ihrer Händlergruppe zugeordnet sind. Die saml2-Extension mappt die ADFS-Gruppen auf TYPO3-Frontend-Gruppen und steuert damit den Zugang zu geschützten Inhaltsbereichen.

## Technische Architektur implementiert den SAML 2.0 SP als PHP-Library in TYPO3

saml2 basiert auf der PHP-Library onelogin/php-saml (oder einer vergleichbaren Implementation), die den SAML 2.0 Web Browser SSO Profile vollständig abdeckt: AuthnRequest, Response-Validierung, Assertion-Parsing, Signaturprüfung, Logout. Die Library wird als Composer-Dependency eingebunden und von der Extension als TYPO3-Authentication-Service registriert.

Die Konfiguration erfolgt im TYPO3-Backend oder per TypoScript: IdP-Metadata-URL (oder manuell: Entity ID, SSO-URL, SLO-URL, Zertifikat), SP-Entity-ID, Attribute-Mapping (welches IdP-Attribut auf welches TYPO3-Feld: email, username, firstname, lastname, groups). Die Extension unterstützt sowohl SP-initiated SSO (User klickt "Login" auf der TYPO3-Seite) als auch IdP-initiated SSO (User kommt direkt vom IdP-Portal).

Frontend-User werden bei der ersten Anmeldung automatisch angelegt und bei jeder weiteren Anmeldung aktualisiert. Die Gruppenzuordnung kann statisch (alle SAML-User in Gruppe X) oder dynamisch (IdP-Attribut "role" = "admin" wird zu TYPO3-Gruppe "admin") konfiguriert werden.

Für das Backend-Login (BE-User) ist SAML ebenfalls konfigurierbar, allerdings mit höherem Risiko: Wenn der IdP ausfällt, ist kein Backend-Zugang mehr möglich. Wir empfehlen, mindestens einen lokalen Admin-Account als Fallback beizubehalten.

## Häufige Probleme betreffen Zertifikate, Zeitabweichungen und Attribut-Mapping

Das häufigste Problem bei SAML-Integrationen sind abgelaufene oder falsch konfigurierte Zertifikate. Der IdP signiert die SAML-Response mit seinem Zertifikat. Wenn das Zertifikat auf dem SP nicht aktualisiert wird, nachdem der IdP es rotiert hat, scheitert die Signaturprüfung und der Login bricht mit einer kryptischen Fehlermeldung ab. Die Lösung: Zertifikats-Rotation in den Wartungskalender aufnehmen. Die meisten IdPs geben 30 Tage Vorlauf vor der Rotation.

Zweites Problem: Zeitabweichungen zwischen IdP und SP. SAML-Assertions haben ein Zeitfenster (NotBefore / NotOnOrAfter). Wenn die Systemuhren von IdP-Server und TYPO3-Server mehr als 120 Sekunden auseinanderlaufen, wird die Assertion als ungültig abgelehnt. Die Lösung: NTP auf beiden Servern konfigurieren.

Drittes Thema: Falsches Attribut-Mapping. Jeder IdP benennt die Attribute anders. Microsoft ADFS liefert "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", Keycloak liefert "email", Shibboleth liefert "urn:oid:0.9.2342.19200300.100.1.3". Die Extension muss wissen, unter welchem Namen das E-Mail-Attribut im SAML-Token steht. Falsches Mapping führt zu leeren Feldern im TYPO3-User-Profil. Debug-Logging der empfangenen Attribute hilft, die richtigen Mapping-Keys zu identifizieren.

## TYPO3 v12 wird unterstützt, v13-Kompatibilität hängt von der Authentication-Service-API ab

Die saml2-Extension registriert sich als TYPO3 Authentication Service. Diese API ist im TYPO3-Core seit Jahren stabil, wurde aber in v12 und v13 an einzelnen Stellen angepasst. Die aktuelle Version der Extension läuft unter v12 stabil. Für v13 muss die Authentication-Service-Registrierung an die neue Service-Konfiguration angepasst werden. Gosign prüft bei SSO-Projekten, ob die PHP-SAML-Library auf aktuellem Stand ist (Sicherheitspatches) und ob die Extension mit der eingesetzten TYPO3-Version kompatibel ist. Wenn die Community-Extension nicht mehr gepflegt wird, empfehlen wir als Alternative die oidc-Extension, sofern der IdP OpenID Connect unterstützt.

--- Schemaker TYPO3 - ViewHelper-Schema | Gosign ---
> ViewHelper-Schema-Generator für Fluid. Generiert Dokumentation und Autovervollständigung für eigene ViewHelper. Entwickler-Tool für professionelle.

## Warum fehlende ViewHelper-Dokumentation TYPO3-Projekte ausbremst

Fluid ViewHelper sind das Rückgrat jeder TYPO3-Template-Entwicklung. Aber sobald ein Projekt eigene ViewHelper mitbringt, beginnt das Problem: Kein Entwickler kennt alle Parameter, keine IDE bietet Autovervollständigung, und die Dokumentation existiert bestenfalls als Kommentar im PHP-Code. Schemaker löst dieses Problem, indem es aus PHP-Klassen automatisch XSD-Schema-Dateien generiert. Diese Schemata liefern IDEs die nötigen Informationen für Autovervollständigung, Validierung und Inline-Dokumentation direkt im Fluid-Template.

Für Teams mit mehr als einem TYPO3-Entwickler ist das keine Komfortfrage, sondern eine Produktivitätsfrage. Ohne Schema-Dateien verbringt jeder Entwickler täglich 15 bis 30 Minuten damit, ViewHelper-Parameter im Quellcode nachzuschlagen.

## Typische Einsatzszenarien

**Enterprise-Projekte mit 20+ eigenen ViewHelpers.** Grosse TYPO3-Installationen bringen häufig spezialisierte ViewHelper mit - für Preisformatierung, Berechtigungsprüfungen, API-Aufrufe oder branchenspezifische Logik. Ohne Schemaker muss jeder neue Entwickler im Projekt den Quellcode lesen, um die verfügbaren Parameter zu verstehen. Mit Schemaker öffnet er das Fluid-Template in PhpStorm oder VS Code und bekommt sofort Vorschläge. Bei einem Projekt mit 25 eigenen ViewHelpers und durchschnittlich 4 Parametern pro ViewHelper spart das pro Entwicklertag geschätzt 30 bis 45 Minuten Quellcode-Suche.

**Extension-Entwicklung für den TYPO3 Extension Repository (TER).** Wer Extensions veröffentlicht, die eigene ViewHelper enthalten, kann mit Schemaker XSD-Dateien mitliefern. Das reduziert Support-Anfragen erheblich und verbessert die Developer Experience für jeden Nutzer der Extension. Im TER als auch auf Packagist signalisiert eine mitgelieferte XSD-Datei professionelle Extension-Entwicklung.

**Onboarding neuer Entwickler.** In einer TYPO3-Agentur wechseln Entwickler regelmässig zwischen Projekten. Schemaker-generierte Schemata funktionieren wie eine lebende Dokumentation: Sie sind immer aktuell, weil sie direkt aus dem Code generiert werden. Kein Wiki, das veraltet. Kein Confluence, das niemand pflegt. Ein neuer Entwickler installiert das Projekt, öffnet ein Fluid-Template und sieht sofort, welche ViewHelper mit welchen Parametern verfügbar sind. Statt 2 Tage Einarbeitung sind es 2 Stunden.

## Technische Architektur

Schemaker analysiert PHP-Klassen, die von `AbstractViewHelper` erben. Es liest die `@param`-Annotations, die `registerArgument()`-Aufrufe und die Klassen-DocBlocks aus. Daraus generiert es XSD-Schema-Dateien (XML Schema Definition), die dem Fluid-Namespace zugeordnet werden.

Die Integration funktioniert über die TYPO3-CLI:

- `vendor/bin/typo3 schemaker:generate` erzeugt XSD-Dateien für alle registrierten ViewHelper-Namespaces
- Die generierten XSD-Dateien werden im Projekt abgelegt (typisch: `Resources/Private/Schemas/`)
- In jedem Fluid-Template wird der Namespace mit Schema-Location deklariert
- Die IDE (PhpStorm, VS Code mit entsprechender Extension) liest die XSD und bietet Autovervollständigung

Schemaker hat als Abhängigkeit nur den TYPO3 Core und das Fluid-Template-Engine-Paket. Es greift nicht in den Rendering-Prozess ein und hat keinen Performance-Impact auf die Live-Website - die Schema-Generierung läuft ausschliesslich auf der CLI im Entwicklungskontext. In Produktivumgebungen muss Schemaker nicht einmal installiert sein; die generierten XSD-Dateien werden über das Versionskontrollsystem (Git) verteilt und funktionieren unabhängig von der Extension.

Wichtig: Schemaker analysiert nur ViewHelper, die korrekt registriert sind. ViewHelper, die über `$this->registerArgument()` im `initializeArguments()`-Method arbeiten, werden vollständig erkannt. Ältere ViewHelper, die Parameter über `render()`-Method-Signaturen definieren (Pre-TYPO3-v8-Pattern), werden teilweise nicht korrekt erfasst.

## Häufige Probleme und Lösungen

**Problem: IDE zeigt trotz XSD keine Autovervollständigung.** Häufigste Ursache: Der Namespace im Fluid-Template stimmt nicht mit dem XSD-Namespace überein. Schemaker generiert Schemata basierend auf dem PHP-Namespace der ViewHelper-Klassen. Wenn im Fluid-Template ein abweichender Alias verwendet wird, findet die IDE keine Zuordnung. Die Lösung: `xmlns:custom="http://typo3.org/ns/Vendor/Extension/ViewHelpers"` muss exakt dem generierten Schema entsprechen.

**Problem: Generierte XSD enthält nicht alle ViewHelper.** Schemaker findet nur ViewHelper, die über Composer Autoloading erreichbar sind. Extensions, die nur über das Classic-Mode-Verzeichnis (ohne Composer) installiert sind, werden nicht vollständig gescannt. Die Lösung: Auf Composer-basierte Installation umstellen oder den Autoload-Pfad manuell konfigurieren.

**Problem: Schema veraltet nach Code-Änderungen.** XSD-Dateien werden nicht automatisch aktualisiert, wenn sich ViewHelper-Parameter ändern. Die Lösung: Schema-Generierung in die CI/CD-Pipeline integrieren. Ein `composer post-install-cmd`-Hook oder ein Build-Step in GitLab CI sorgt dafür, dass Schemata nach jedem Dependency-Update neu generiert werden. In GitLab CI sieht der Step typischerweise so aus: `vendor/bin/typo3 schemaker:generate --output Resources/Private/Schemas/` als eigener Job im Build-Stage. Das automatische Update verhindert, dass Entwickler mit veralteten Schemata arbeiten und Fehler erst zur Laufzeit bemerken.

## Migration und Versions-Kompatibilität

Schemaker wurde ursprünglich von Claus Due (FluidTYPO3-Team) entwickelt und war bis TYPO3 v9 aktiv gepflegt. Für TYPO3 v10 und v11 existieren Community-Forks mit eingeschränkter Funktionalität. Die Fluid-Template-Engine hat sich in v11 und v12 intern verändert (neuer ExpressionParser, geändertes Argument-Handling), was die Schema-Generierung teilweise beeinflusst.

Für TYPO3 v12 und v13 empfiehlt sich als Alternative der in PhpStorm integrierte TYPO3-Plugin-Support, der ViewHelper-Informationen direkt aus dem PHP-Code liest, ohne separate XSD-Dateien zu benötigen. Das TYPO3 Core Team stellt zudem offizielle XSD-Schemata für die Core-ViewHelper bereit.

Wer Schemaker produktiv im Einsatz hat und auf TYPO3 v12 migriert, sollte prüfen, ob der bestehende Workflow durch IDE-native Funktionen ersetzt werden kann. Der PhpStorm-Plugin für TYPO3 (Stand 2026) bietet ViewHelper-Autovervollständigung für Core-ViewHelper und Extensions, die korrekte DocBlocks verwenden. Für eigene ViewHelper greift der Plugin auf dieselben PHP-Informationen zu, die auch Schemaker nutzt - nur ohne den Umweg über XSD-Dateien.

Gosign unterstützt bei der Evaluierung und migriert bestehende Schema-Workflows auf moderne Toolchains. Typischer Aufwand für die Migration: 4 bis 8 Stunden pro Projekt, inklusive IDE-Konfiguration für alle Entwickler im Team und Dokumentation der verfügbaren ViewHelper-Namespaces.

--- sf_event_mgt TYPO3 - Event-Management | Gosign ---
> sf_event_mgt: Events verwalten, Anmeldungen steuern, Bezahlung. Setup & Custom-Entwicklung , KI-beschleunigt.

## sf_event_mgt löst das Problem, dass Events ohne Registrierung kein Event sind

Sobald eine TYPO3-Website mehr als zwei Termine pro Jahr verwaltet und Teilnehmer aufnehmen muss, stösst jede improvisierte Lösung aus Seiten-Listen, Kalender-Plugins und Powermail-Formularen an ihre Grenzen. sf_event_mgt ist die Extension, die diese Bausteine zu einem echten Event-System zusammenfasst: Teilnehmerverwaltung mit Statusübergängen, Wartelisten mit automatischem Nachrücken, Bezahlung über mehrere Provider und automatisierte E-Mail-Kommunikation über den gesamten Teilnahme-Lifecycle. Wer in TYPO3 regelmässig Veranstaltungen mit festen Plätzen organisiert, kommt an dieser Extension kaum vorbei. Torben Hansen hat sf_event_mgt von Anfang an als "Extbase-natives" Tool gebaut, das sich nahtlos in bestehende TYPO3-Installationen einfügt und sich an jeder Stelle überschreiben lässt, ohne die Kern-Extension zu forken.

## Typische Einsatzszenarien reichen von Messen bis zu akademischen Programmen

Hochschulen nutzen sf_event_mgt für Informationstage, Schnuppervorlesungen und Weiterbildungsprogramme. In der Praxis heisst das oft: 30 parallele Kurse mit jeweils eigener Kapazität, Preisstaffel und E-Mail-Kette an Interessent, Teilnehmer und Organisator. Die Extension verwaltet das über eine einzige Datenstruktur, inklusive Mehrsprachigkeit für internationale Studierende. An einer typischen Fachhochschule haben wir sf_event_mgt mit rund 400 Einzel-Events pro Jahr eingesetzt, darunter Vorkurse, Offene Labortage und Alumni-Treffen.

Verbände und Kammern organisieren damit Fachtagungen und Seminare, bei denen Teilnehmer nach Mitgliederstatus unterschiedliche Preise zahlen. Eine typische IHK-Installation arbeitet mit 40 bis 80 Veranstaltungen pro Jahr, viele davon kostenpflichtig und mit mehreren Preisklassen. Mitglieder zahlen den regulären Preis, Nicht-Mitglieder einen Aufschlag, Frühbucher einen Rabatt. Die Extension bildet das über Preis-Kategorien ab, die pro Event konfigurierbar sind, ohne dass ein Entwickler eingreifen muss.

Unternehmen wiederum setzen sf_event_mgt für interne Schulungen, Kunden-Events und Webinare ein. Besonders im B2B-Bereich ist die CSV-Exportfunktion wichtig: Die Teilnehmerliste wandert anschliessend ins CRM oder in den Badge-Drucker vor Ort. Bei einem Industriekonzern mit 12.000 Mitarbeitern haben wir die Extension an das interne Learning-Management-System angebunden, sodass Schulungsbuchungen automatisch im Personalsystem landen und die Teilnahme als Weiterbildungs-Nachweis dokumentiert wird.

## Technische Architektur baut auf Extbase und FAL auf

sf_event_mgt ist eine klassische Extbase-Extension und folgt dem MVC-Muster von TYPO3. Die zentralen Models sind Event, Registration, Location und Organisator, die Konfiguration läuft über TypoScript und Fluid-Templates. Fast alles lässt sich per constants.typoscript oder TSconfig anpassen, ohne die Extension zu forken. Die Plugin-Variante bietet gut ein Dutzend Controller-Aktionen, von der Listen- und Detailansicht über den Registration-Flow bis zum Suche- und Kategorie-Filter.

Für Bezahlung bringt die Extension eine Payment-Abstraktion mit, die Stripe, PayPal, Invoice und Klarna über Handler-Klassen unterstützt. Eigene Payment-Provider lassen sich anbinden, indem eine PaymentServiceInterface-Klasse implementiert wird. Die Abrechnung landet in einem eigenen Payment-Log und kann mit dem TYPO3-Scheduler verarbeitet werden. Fehlgeschlagene Zahlungen werden dokumentiert und können über das Backend nachverfolgt werden, ohne dass Redakteure in die Payment-Provider-Konsole wechseln müssen.

Das E-Mail-System baut auf Fluid-Templates im EXT-Verzeichnis auf. Für jede Registrierung werden mehrere Nachrichten ausgelöst: Bestätigung an Teilnehmer, Benachrichtigung an Organisator, Erinnerungen vor dem Event, Folge-Mail nach dem Event. Jede dieser Mails ist ein Fluid-Template, das per SiteSet oder PageTS überschrieben werden kann. Die Mails werden über den TYPO3-Mailer verschickt und respektieren die globalen SMTP-Einstellungen, inklusive SPF und DKIM. Für Teilnehmer mit reservierten Wartelisten-Plätzen gibt es separate Templates, die bei Nachrücken ausgelöst werden.

## Häufige Probleme betreffen Wartelisten, iCal-Export und ReCaptcha

Das häufigste Supportthema ist die Wartelisten-Logik. Wenn ein Teilnehmer absagt, rückt der erste Wartelisten-Eintrag nach - aber nur, wenn der Admin den Kommando-Controller "moveUpWaitlistRegistrations" per Scheduler aktiviert hat. Viele Installationen haben das Kommando vergessen und wundern sich, warum Plätze leer bleiben. Die Konfiguration dauert fünf Minuten, aber ohne den Scheduler-Task bleibt die Extension im manuellen Modus stehen.

Ein zweites Dauerthema ist der iCal-Export. Teilnehmer wollen einen Klick auf "Zum Kalender hinzufügen", der in Outlook, Apple Calendar und Google Kalender funktioniert. sf_event_mgt liefert eine ICS-Datei, aber die korrekten Zeitzonen und VTIMEZONE-Blöcke müssen per Konfiguration gesetzt werden. Sonst erscheint das Event in Outlook mit einer Stunde Versatz, besonders kritisch bei der Sommerzeitumstellung. Wir empfehlen, bei internationalen Events sowohl die lokale Zeitzone als auch UTC im ICS zu hinterlegen.

Das dritte Thema ist Spam-Schutz. Öffentliche Anmeldeformulare ziehen Bots an, die Wartelisten fluten. sf_event_mgt unterstützt Honeypot-Felder und lässt sich mit ext:kestura_recaptcha oder dem nativen TYPO3-Captcha koppeln. In produktiven Installationen empfehlen wir, beide Mechanismen zu kombinieren und zusätzlich einen Rate-Limit pro IP-Adresse einzubauen, damit einzelne Bots nicht hunderte Fake-Registrierungen anlegen können.

## Migration auf TYPO3 v12 und v13 ist unkritisch

sf_event_mgt wird von Torben Hansen kontinuierlich gepflegt und ist für TYPO3 v11, v12 und v13 verfügbar. Der Sprung von v10 auf v12 bringt keine Breaking Changes an der Datenbankstruktur mit sich, alle Felder bleiben kompatibel. Extension-eigene ViewHelper wurden auf die neue Fluid-Version umgestellt, eigene Templates benötigen nach dem Update ein kurzes Review. Besonders der Registration-Finisher und die E-Mail-Templates müssen geprüft werden, weil TYPO3 v12 strengere Regeln für das Error-Handling eingeführt hat.

Bei älteren Versionen (sf_event_mgt 4.x und früher) lohnt sich ein Blick auf die Payment-Konfiguration, weil die Stripe-API mehrere Generationen übersprungen hat. Die aktuelle Extension unterstützt Stripe Elements und 3D Secure 2, ältere Versionen arbeiteten noch mit Stripe Sources, die inzwischen deprecated sind. Gosign migriert bestehende sf_event_mgt-Installationen typischerweise in einem Arbeitsschritt zusammen mit dem TYPO3-Core-Upgrade. Fluid-Templates werden dabei auf konsistente Bezeichner vereinheitlicht, und veraltete ViewHelper-Aufrufe werden automatisch erkannt und ersetzt. Im gleichen Zug prüfen wir, ob die Schema.org/Event-Auszeichnung im JSON-LD aktuell ist und ob das Event-Detail-Template alle Felder für Google-Event-Rich-Snippets enthält.

--- Gallery TYPO3 - Bildergalerie | Gosign ---
> Bildergalerie-Extension basierend auf TYPO3 File Collections. Lightbox, Masonry-Layout, Lazy Loading. Gosign baut Custom Gallery Templates im.

## Warum sf_filecollection_gallery Bildergalerien in TYPO3 richtig löst

Bildergalerien gehören zu den häufigsten Anforderungen auf Unternehmenswebsites - Produktfotos, Team-Bilder, Eventdokumentation, Referenzprojekte. TYPO3 selbst bringt kein natives Galerie-Element mit. Das Standard-Content-Element "Bilder" zeigt Bilder untereinander oder in Spalten, aber ohne Lightbox, ohne Filterung und ohne flexible Layout-Optionen. sf_filecollection_gallery schliesst diese Lücke, indem es TYPO3 File Collections als Datenquelle für Galerien nutzt und dabei Lightbox-Integration, verschiedene Layouts und Lazy Loading mitliefert.

Der entscheidende Vorteil gegenüber anderen Galerie-Extensions: Redakteure arbeiten mit dem FAL-System, das sie bereits kennen. Bilder werden in File Collections organisiert, und die Galerie zeigt automatisch alle Bilder der zugewiesenen Collection. Neue Bilder hinzufügen bedeutet: Bild in die Collection ziehen, fertig.

## Typische Einsatzszenarien

**Referenzprojekte und Portfolios.** Eine Architektur-Agentur zeigt auf jeder Projektseite 15 bis 40 Bilder in einer Galerie. Der Redakteur pflegt eine File Collection pro Projekt. sf_filecollection_gallery rendert die Galerie als Grid mit Lightbox. Beim Klick auf ein Bild öffnet sich die Vollansicht mit Navigation zum nächsten und vorherigen Bild. Die Bildbeschreibungen aus den FAL-Metadaten (Titel, Alternative, Description) werden automatisch als Bildunterschriften angezeigt.

**Event-Dokumentation und Pressefotografie.** Ein Messeveranstalter dokumentiert jedes Event mit 50 bis 200 Fotos. Die Bilder werden batch-weise in eine File Collection hochgeladen. sf_filecollection_gallery erzeugt automatisch Thumbnails, optimiert die Ladezeit durch Lazy Loading und zeigt die Galerie im Masonry-Layout, das unterschiedliche Seitenverhältnisse elegant verarbeitet.

**Produktkataloge mit visueller Darstellung.** Ein Möbelhersteller zeigt pro Produktkategorie eine Galerie mit Ambiente-Aufnahmen. Über mehrere File Collections (eine pro Kategorie) und ein Frontend-Plugin mit Kategorie-Filter können Besucher zwischen den Galerien wechseln, ohne die Seite neu zu laden.

## Technische Architektur

sf_filecollection_gallery ist eine Extbase-Extension, die als TYPO3-Plugin in Content-Elemente eingebunden wird. Die Datenquelle sind TYPO3 File Collections aus dem File Abstraction Layer (FAL).

Die Architektur gliedert sich in drei Schichten:

- **Datenquelle**: Die Extension liest File Collections über die TYPO3 FAL API. Unterstützt werden statische Collections (manuell zugewiesene Dateien), Folder-basierte Collections (alle Dateien eines Ordners) und Kategorie-basierte Collections.
- **Rendering-Engine**: Fluid-Templates steuern die Ausgabe. Die Extension liefert Templates für Grid-Layout, Masonry-Layout und einfache Listen mit. Alle Templates sind überschreibbar - über die Standard-TYPO3-Mechanismen (TypoScript Template-Pfade) können eigene Fluid-Templates eingebunden werden.
- **Lightbox-Integration**: sf_filecollection_gallery unterstützt mehrere Lightbox-Bibliotheken: Fancybox, PhotoSwipe und Lightcase. Die Wahl wird über TypoScript-Konfiguration gesteuert. Gosign empfiehlt PhotoSwipe wegen der besseren Touch-Unterstützung und der fehlenden jQuery-Abhängigkeit.

Lazy Loading ist nativ integriert: Bilder unterhalb des sichtbaren Bereichs werden erst geladen, wenn der Nutzer scrollt. Das verwendet das native `loading="lazy"`-Attribut und optional Intersection Observer für ältere Browser.

Abhängigkeiten: TYPO3 Core (v10+), FAL. Lightbox-Libraries werden als Frontend-Assets mitgeliefert oder können über die eigene Asset-Pipeline eingebunden werden. Ein Vorteil der File-Collection-Architektur: Bilder können in mehreren Galerien gleichzeitig erscheinen, ohne dupliziert zu werden. Eine Referenz auf dasselbe FAL-Objekt in verschiedenen Collections reicht aus. Das spart Speicherplatz und stellt sicher, dass Metadaten (Alt-Text, Titel, Copyright) zentral gepflegt werden.

## Häufige Probleme und Lösungen

**Problem: Galerie zeigt keine Bilder, obwohl die File Collection gefüllt ist.** Ursache ist häufig eine falsche Storage-Konfiguration. Die File Collection referenziert einen Storage, auf den das Frontend keinen Zugriff hat (z.B. ein nicht-öffentlicher Storage oder ein Storage mit falscher Base-URL). Die Lösung: Im TYPO3 Backend unter Dateiliste prüfen, ob die Bilder im richtigen Storage liegen und ob der Storage als "public" konfiguriert ist. Zusätzlich muss das Plugin-Content-Element den korrekten Startpunkt (Sys-Folder oder Seite) konfiguriert haben, in dem die File Collection angelegt ist.

**Problem: Lightbox funktioniert nicht, Bilder öffnen als neue Seite.** Die Lightbox-JavaScript-Bibliothek wird nicht geladen. Häufig liegt das an einem TypoScript-Include, das fehlt, oder an einem Konflikt mit einer anderen JavaScript-Bibliothek auf der Seite. Die Lösung: Im Browser-Dev-Tool prüfen, ob die Lightbox-JS-Datei geladen wird und ob JavaScript-Fehler in der Konsole erscheinen. Bei jQuery-basierten Lightboxen (Fancybox) kann ein jQuery-Versionskonflikt die Ursache sein.

**Problem: Ladezeit zu hoch bei grossen Galerien.** Eine Galerie mit 100+ Bildern in hoher Auflösung kann trotz Lazy Loading langsam laden, weil die Thumbnails nicht ausreichend komprimiert sind. Die Lösung: TYPO3 Image Processing konfigurieren, um Thumbnails in fester Grösse (z.B. 400x300px) und optimierter Qualität (75-80%) zu generieren. Zusätzlich WebP-Format über die TYPO3 Image-Processing-Konfiguration aktivieren.

## Migration und Versions-Kompatibilität

sf_filecollection_gallery wird aktiv gepflegt und ist für TYPO3 v11 und v12 LTS verfügbar. Die Extension hat eine stabile API und kaum Breaking Changes zwischen Versionen. Für TYPO3 v13 ist die Kompatibilität typischerweise zeitnah nach dem LTS-Release gegeben.

Wer von einer älteren Galerie-Extension migriert (z.B. tt_products_gallery, ws_flexslider als Galerie-Ersatz oder eigenentwickelte Galerie-Plugins), muss lediglich die Datenquelle umstellen: Bilder in File Collections organisieren und das sf_filecollection_gallery-Plugin auf den Seiten platzieren. Die Bilder selbst bleiben im FAL und müssen nicht verschoben werden.

Beim TYPO3-Upgrade von v10 auf v12 sollte die Lightbox-Konfiguration geprüft werden. Fancybox 2 ist nicht mehr kompatibel mit aktuellen jQuery-Versionen. Gosign empfiehlt den Wechsel auf PhotoSwipe, das ohne jQuery auskommt und bessere Performance auf mobilen Geräten liefert. PhotoSwipe unterstützt zudem Touch-Gesten (Pinch-to-Zoom, Swipe), die auf Smartphone-Bildschirmen die Nutzererwartung erfüllen. Die Migration von Fancybox auf PhotoSwipe erfordert typischerweise 4 bis 8 Stunden: neue JavaScript-Initialisierung, angepasstes Lightbox-Template und CSS-Feintuning für die Übergangsanimationen.

--- sf_register TYPO3 - Frontend-Registrierung | Gosign ---
> sf_register: Frontend-Benutzerregistrierung in TYPO3. Profilverwaltung, Double-Opt-In. KI-beschleunigt.

## Warum TYPO3 ohne Registrierungs-Extension kein Nutzer-Portal werden kann

Der TYPO3-Core kennt fe_users als Datenbanktabelle und eine Standard-Login-Maske, aber keinen Weg, wie sich ein neuer Nutzer selbstständig registriert, seine Daten pflegt oder sein Passwort zurücksetzt. Jede Website, die mehr ist als ein reines Publikationsorgan, braucht diese Funktion: Communities, Mitgliederbereiche, geschützte Downloads, personalisierte Newsletter, kostenpflichtige Inhalte. sf_register schließt diese Lücke mit einem schlanken Extbase-basierten Ansatz, der sich genau auf Registrierung, Profil und Passwort-Reset konzentriert und bewusst auf Features verzichtet, die in der Komplettlösung femanager mitgeliefert werden.

## Typische Einsatzszenarien

Ein Fachverlag mit 3.500 Abonnenten bietet Online-Zugriff auf Fachartikel und Studien. Jeder Abonnent erhält ein Konto, das an seine Abo-Nummer gekoppelt ist. sf_register übernimmt die initiale Registrierung mit Double-Opt-In-Bestätigung per E-Mail, legt den Nutzer automatisch in der Gruppe "Abonnent" an und aktiviert den Zugriff auf die geschützten Seiten. Wenn das Abo abläuft, entfernt ein TYPO3-Scheduler-Task die Gruppenzugehörigkeit, ohne den Account zu löschen, sodass der Nutzer nach einer Vertragsverlängerung wieder Zugriff hat.

Ein zweiter Fall ist ein Fachverband mit rund 7.000 Mitgliedsunternehmen, der ein geschütztes Mitgliederportal mit Tagungsdokumentation, Normenvorschauen und Diskussionsforen betreibt. sf_register erlaubt die Erstregistrierung, löst aber gleichzeitig einen manuellen Freischaltprozess aus, bei dem ein Verbandsmitarbeiter die Zugehörigkeit zur Mitgliedsfirma prüft, bevor der Account aktiviert wird. Der Workflow kombiniert Double-Opt-In mit einer Admin-Genehmigung und nutzt dafür die Event-Hooks der Extension.

Der dritte Kontext sind öffentliche Einrichtungen wie Volkshochschulen oder Stadtbibliotheken, die Kursanmeldungen oder Katalog-Merklisten an einen Nutzer-Account koppeln wollen. Hier zählt vor allem die einfache Einrichtung und die geringe Komplexität: Die Extension muss keine zwanzig Profilfelder verwalten, sondern Name, E-Mail, Passwort und eine Bibliotheks-Kundennummer, mehr braucht es nicht, und sf_register liefert genau das.

## Technische Architektur: Extbase, TCA und Finisher

sf_register ist sauber nach dem Extbase-Modell aufgebaut. Ein eigener FrontendUser-Model erweitert den Core-User, Controller-Actions behandeln Create, Edit, Confirm und ResetPassword, und das Templating läuft über Fluid-Layouts. Die Pflichtfelder werden über TCA-Konfiguration gesteuert und lassen sich über eine Extension-eigene Konfigurationsdatei erweitern. Custom-Felder wie Firma, Position oder Mitgliedsnummer benötigen einen kleinen TCA-Eintrag, eine Model-Property und eine Ergänzung im Fluid-Template, was Entwicklern eine klare Struktur gibt, aber auch bedeutet, dass jede Anpassung Code-Arbeit ist.

Der Double-Opt-In-Prozess basiert auf Hash-basierten Confirmation-Links, die in der fe_users-Tabelle als temporärer Token gespeichert werden und nach Klick den disable-Flag zurücksetzen. E-Mails versendet die Extension über das TYPO3-Mailer-Interface, das intern auf Symfony Mailer aufsetzt, wodurch auch komplexere Setups mit SMTP-Proxies oder Mailing-Services wie SendGrid problemlos funktionieren. Passwort-Hashing nutzt die TYPO3-eigenen Password-Hash-Services und ist damit automatisch mit jedem Core-Update synchron.

## Häufige Probleme und Lösungen

Das erste Problem sind Spam-Registrierungen. Jede öffentliche Registrierungs-Seite zieht Bots an, die automatisiert Accounts anlegen, um über das Passwort-Reset-Formular E-Mails an Dritte zu senden oder Trackback-Spam in Community-Features zu platzieren. Eine saubere Lösung kombiniert sf_register mit einer CAPTCHA-Extension wie sr_freecap oder einem Honeypot-Feld, ergänzt um ein Rate-Limiting auf der Registrierungs-URL im Reverse-Proxy.

Das zweite Problem betrifft die E-Mail-Zustellung. Bestätigungsmails landen regelmäßig im Spam-Ordner, wenn der TYPO3-Server ohne SPF-Eintrag, DKIM-Signatur oder Reverse-DNS betrieben wird. Die Extension versendet die Mail korrekt, aber der Empfänger-Server verwirft sie stumm. Die Lösung liegt nicht in sf_register, sondern in der Mail-Infrastruktur: Ein dedizierter Sendedienst mit etablierter Domain-Reputation senkt die Bounce-Rate spürbar.

Das dritte Thema ist Datenschutz. Registrierte Nutzer müssen jederzeit ihre Daten einsehen, korrigieren und löschen können, und die Löschung muss tatsächlich kaskadierend greifen, also auch Bestellungen, Downloads und andere verknüpfte Datensätze umfassen. sf_register liefert Edit-Formulare, aber keinen DSGVO-konformen Löschprozess. Dieser muss als eigener Workflow ergänzt werden, bei dem die Account-Löschung entweder sofort oder nach einer Übergangsfrist die abhängigen Daten anonymisiert.

Ein viertes typisches Problem betrifft Passwort-Richtlinien. sf_register akzeptiert per Default auch schwache Passwörter, und Nutzer neigen dazu, kurze oder triviale Kombinationen zu verwenden. Die TYPO3-Password-Policies lassen sich über die System-Konfiguration aktivieren, sodass sf_register automatisch Mindestlänge, Zeichenklassen und Blacklist-Prüfungen anwendet, ohne dass die Extension selbst angepasst werden muss.

## Migration und Versions-Kompatibilität

sf_register ist für TYPO3 v11 und v12 stabil und hat in der Community den Ruf einer soliden, wartbaren Alternative zu femanager. Die v13-Unterstützung ist in der Regel zeitnah nach Release eines neuen TYPO3-Cores verfügbar, erfordert bei Custom-Extensions jedoch ein Review der Extbase-Annotation-Syntax, die zwischen den Versionen kleinere Anpassungen gesehen hat.

Wer von femanager auf sf_register migriert, spart Komplexität, muss aber prüfen, welche Features tatsächlich verwendet wurden: femanager bietet Admin-Bestätigung, Profilbild-Upload und Backend-Moderation out-of-the-box, während sf_register diese Funktionen nur über zusätzlichen Code oder Event-Listener nachbaut. Umgekehrt ist der Migrationspfad von sf_register zu femanager einfacher, weil die Datenstruktur weitgehend kompatibel ist. Gosign übernimmt solche Migrationen inklusive Mail-Template-Portierung und Abgleich der Benutzergruppen, sodass bestehende Nutzer sich auch nach dem Wechsel problemlos anmelden.

Wer ein Projekt neu aufsetzt, sollte vor der Auswahl die realen Anforderungen des Portals durchdenken: Braucht der Betreiber manuelle Freischaltungen, Profilbilder, komplexe Rollen-Zuordnungen? Dann ist femanager der schnellere Weg. Genügt eine schlanke Self-Service-Registrierung mit sauberem Extbase-Fundament und wenig Overhead? Dann ist sf_register die passende Wahl. Die Entscheidung fällt selten knapp aus, sobald man den Katalog an benötigten Funktionen einmal durchgegangen ist, und sie spart später erheblichen Nachbau-Aufwand.

--- sg_forms TYPO3 - Formulare | Gosign ---
> Formular-Extension von SGalinski. Alternative zu Powermail und dem nativen TYPO3 Form Framework. Gosign berät zum optimalen Formular-Stack für Ihre.

## Drei Formular-Systeme in TYPO3 erzeugen mehr Verwirrung als Auswahl

TYPO3-Projekte stehen bei der Formular-Implementierung vor einem ungewöhnlichen Luxusproblem: Es gibt drei ernst zu nehmende Optionen. Das native TYPO3 Form Framework (ext:form), powermail von in2code und sg_forms von SGalinski. Jede Lösung hat eigene Stärken und eigene Limits. sg_forms positioniert sich als Mittelweg: leichtgewichtiger als powermail, aber mit mehr Backend-Komfort als ext:form. Die Extension stammt vom TYPO3-Dienstleister SGalinski und wird in dessen Kundenprojekten aktiv eingesetzt.

Wer bereits SGalinski-Extensions im Einsatz hat (sgalinski_base, sg_cookie_optin), findet in sg_forms eine Lösung, die sich nahtlos ins SGalinski-Ökosystem einfügt.

## Typische Einsatzszenarien sind Kontaktformulare, Anfragen und einfache Bewerbungsformulare

Das Standard-Szenario ist das Kontaktformular auf einer Unternehmenswebsite. Name, E-Mail, Betreff, Nachricht, DSGVO-Checkbox, Absenden. sg_forms liefert dieses Setup als vorkonfiguriertes Template, das Redakteure im Backend aktivieren und anpassen können. Felder lassen sich hinzufügen, entfernen und umsortieren, Pflichtfelder markieren, Validierungen setzen. Die E-Mail geht an eine oder mehrere konfigurierbare Empfänger-Adressen.

Ein zweites Szenario sind mehrseitige Anfrage-Formulare. Ein Handwerksbetrieb fragt auf Seite 1 die Kontaktdaten, auf Seite 2 die Art der Dienstleistung (Dropdown) und auf Seite 3 Fotos des Objekts (Datei-Upload). sg_forms unterstützt mehrstufige Formulare mit Fortschrittsanzeige und Zurück-Navigation. Die Daten werden nach dem Absenden als E-Mail und optional als Datenbank-Eintrag gespeichert.

Drittes Szenario: Einfache Bewerbungsformulare. Ein KMU mit drei offenen Stellen braucht kein Bewerbermanagement-System, aber ein Formular, das Lebenslauf und Anschreiben als PDF-Upload entgegennimmt und an die Personalabteilung weiterleitet. sg_forms bietet dafür den Datei-Upload mit Typen- und Grössenvalidierung, kombiniert mit einer Bestätigungsmail an den Bewerber.

## Technische Architektur basiert auf Extbase mit YAML-basierter Formulardefinition

sg_forms registriert ein Extbase-Plugin, das Formulare aus einer Konfiguration rendert. Die Formulardefinition wird im Backend über ein grafisches Interface erstellt oder alternativ als YAML-Datei definiert. Jedes Feld hat einen Typ (Text, E-Mail, Textarea, Select, Radio, Checkbox, File, Hidden), Validierungsregeln und optionale Bedingungen.

Die Finisher-Architektur folgt dem gleichen Pattern wie bei powermail: Nach dem Absenden werden nacheinander Aktionen ausgeführt. Die Standard-Finisher sind E-Mail-Versand, Datenbank-Speicherung und Redirect auf eine Dankes-Seite. Custom Finisher lassen sich als PHP-Klassen implementieren, etwa für CRM-Anbindungen oder Webhook-Aufrufe.

Das Frontend-Rendering läuft über Fluid-Templates, die per SiteSet oder TypoScript überschrieben werden können. Die Extension liefert ein Default-Template mit, das ohne Anpassung funktioniert, aber für produktive Websites typischerweise an das CI angepasst wird. Spam-Schutz ist über Honeypot-Felder und optionale CAPTCHA-Integration verfügbar.

## Häufige Probleme betreffen die Abgrenzung zu powermail und die SGalinski-Lizenz

Die häufigste Frage ist: sg_forms oder powermail? Die Antwort hängt von der Projektgrösse ab. powermail hat die grössere Community, mehr Dokumentation, mehr Drittanbieter-Finisher und eine breitere Feature-Palette (PDF-Export, mehrstufige Logik mit beliebiger Komplexität). sg_forms ist schlanker, hat weniger Overhead und ist in SGalinski-Projekten der Standard. Für die meisten Unternehmenswebsites ist powermail die sicherere Wahl. Für SGalinski-Kunden, die bereits im Ökosystem sind, ist sg_forms die konsistentere.

Zweites Thema: Die Lizenzierung. sg_forms ist nicht im TER (TYPO3 Extension Repository) als Free-Extension verfügbar, sondern wird über SGalinski-Projekte ausgeliefert. Das bedeutet, dass Teams, die die Extension ohne SGalinski-Beziehung nutzen wollen, die Verfügbarkeit und Lizenzbedingungen direkt mit SGalinski klären müssen.

Drittes Problem: Migration. Wer von powermail zu sg_forms wechselt (oder umgekehrt), muss alle bestehenden Formulardefinitionen neu anlegen, weil die Datenstrukturen inkompatibel sind. Bestehende Formular-Einträge in der Datenbank können nicht automatisch migriert werden.

## TYPO3 v12 wird unterstützt, v13 folgt dem SGalinski-Release-Zyklus

SGalinski pflegt sg_forms im eigenen Release-Zyklus, der an die TYPO3-LTS-Versionen gekoppelt ist. TYPO3 v12 wird aktiv unterstützt. Für v13 ist mit einem Update zu rechnen, sobald SGalinski die eigene Extension-Suite aktualisiert. Gosign empfiehlt bei der Wahl des Formular-Systems, die langfristige Pflege und die Community-Grösse als Entscheidungsfaktor zu gewichten: powermail mit über 500.000 Installationen hat eine breitere Basis als sg_forms, was bei TYPO3-Upgrades kürzere Wartezeiten auf kompatible Versionen bedeutet.

--- Shibboleth TYPO3 - SSO Basis | Gosign ---
> Shibboleth-Basis-Extension für TYPO3 (Schwester von shibboleth_auth). Service Provider Integration für Backend und Frontend. Standard-SSO.

## Hochschulen und Forschungseinrichtungen brauchen Shibboleth-SSO direkt in TYPO3

Im akademischen Sektor ist Shibboleth der De-facto-Standard für Single Sign-On. Über 3.000 Einrichtungen weltweit sind in Shibboleth-Föderationen organisiert, in Deutschland über den DFN-AAI-Verbund mit über 700 teilnehmenden Organisationen. Die Shibboleth-Extension für TYPO3 integriert den Service Provider direkt ins CMS. Studierende, Dozierende und Mitarbeitende melden sich mit ihrer Hochschulkennung an und erhalten Zugang zu geschützten Frontend-Bereichen und bei Bedarf zum TYPO3-Backend. Die Extension ist die Schwester von shibboleth_auth und bietet die Basis-Integration für den Shibboleth SP, der auf dem Webserver installiert sein muss.

Im Gegensatz zur saml2-Extension, die einen eigenen SP in PHP implementiert, setzt die shibboleth-Extension auf den nativen Shibboleth Service Provider (C++ oder Java), der als Apache-Modul oder ISAPI-Filter läuft. Das ist die robustere Architektur für Hochverfügbarkeitsumgebungen.

## Typische Einsatzszenarien betreffen DFN-AAI, Bibliothekssysteme und Forschungsportale

Das primäre Szenario ist die DFN-AAI-Integration an deutschen Hochschulen. Eine Universität betreibt ihr Webportal auf TYPO3. Studierende klicken auf "Login", werden zum IdP der Hochschule weitergeleitet, authentifizieren sich und landen zurück auf der TYPO3-Seite mit einer aktiven Session. Die Extension liest die Shibboleth-Attribute aus den Server-Umgebungsvariablen (REMOTE_USER, eppn, mail, affiliation) und erstellt oder aktualisiert den TYPO3-Frontend-User.

Ein zweites Szenario sind Bibliotheks-Zugänge. Hochschulbibliotheken bieten Online-Datenbanken, E-Journals und Forschungsdokumente über ihre TYPO3-Website an. Der Zugang ist auf Hochschulangehörige beschränkt. Die Shibboleth-Extension prüft das Attribut "eduPersonEntitlement" und gewährt nur Nutzern mit dem Wert "urn:mace:dir:entitlement:common-lib-terms" Zugang zu lizenzierten Inhalten.

Drittes Szenario: Föderierte Forschungsportale. Ein Forschungskonsortium mit Partnern aus fünf Universitäten betreibt ein gemeinsames Portal auf TYPO3. Jeder Partner hat seinen eigenen IdP. Über die DFN-AAI-Föderation können alle Partner-Mitarbeitenden sich anmelden, ohne dass das Portal eigene Accounts verwalten muss. Die Extension ordnet die Nutzer basierend auf dem Attribut "schacHomeOrganization" der richtigen Partner-Gruppe zu.

## Technische Architektur setzt einen installierten Shibboleth SP auf dem Webserver voraus

Die Extension selbst enthält keinen SAML-Stack. Sie liest die Attribute, die der Shibboleth SP nach erfolgreicher Authentifizierung als Server-Umgebungsvariablen oder HTTP-Header bereitstellt. Der SP muss als Apache-Modul (mod_shib) oder als FastCGI-Authorizer konfiguriert sein. Für nginx-Setups ist ein Shibboleth SP als FastCGI-Backend oder ein lua-basierter Proxy nötig.

Die TYPO3-Extension registriert einen Authentication Service, der bei jedem Frontend- oder Backend-Login prüft, ob Shibboleth-Attribute vorhanden sind. Wenn ja, werden die Attribute auf TYPO3-User-Felder gemappt: REMOTE_USER auf username, mail auf email, givenName und sn auf first_name und last_name. Die Gruppenzuordnung erfolgt über das Attribut "eduPersonAffiliation": student, faculty, staff, employee werden auf TYPO3-Frontend-Gruppen gemappt.

Die Session-Verwaltung folgt dem Shibboleth-Lifecycle: Wenn die Shibboleth-Session abläuft, wird der TYPO3-User automatisch ausgeloggt. Single Logout (SLO) wird über den Shibboleth SP abgewickelt, die TYPO3-Extension reagiert auf das Logout-Event und zerstört die TYPO3-Session.

## Häufige Probleme betreffen die Apache-Konfiguration und fehlende Attribute

Das grösste Problem ist die korrekte Apache-Konfiguration. Der Shibboleth SP muss wissen, welche URLs er schützen soll. Eine falsche Location-Direktive führt dazu, dass der SP entweder alle Seiten schützt (auch öffentliche) oder gar keine. Die Standard-Konfiguration schützt /Shibboleth.sso/* für den SP selbst und /typo3/ für das Backend. Frontend-Bereiche werden per Lazy Session geschützt: Der SP setzt Attribute, wenn eine Shibboleth-Session existiert, erzwingt aber keine Authentifizierung. Die Extension prüft dann im TYPO3-Frontend, ob Attribute vorhanden sind, und zeigt geschützte Inhalte nur angemeldeten Nutzern.

Zweites Problem: Fehlende oder leere Attribute. Nicht jeder IdP liefert alle Attribute. Wenn der IdP das Attribut "mail" nicht freigibt, kann die Extension keine E-Mail-Adresse in den TYPO3-User schreiben. Die Lösung: Mit dem IdP-Betreiber (Rechenzentrum) klären, welche Attribute für den SP freigegeben sind, und das Attribute-Mapping in der Extension entsprechend konfigurieren.

Drittes Thema: Container-Deployments. Docker-basierte TYPO3-Installationen haben oft keinen Apache mit mod_shib. Die Alternative ist ein Shibboleth SP als Reverse Proxy vor dem TYPO3-Container, der die Attribute als HTTP-Header weiterleitet. Die Extension muss dann so konfiguriert werden, dass sie Attribute aus Headern statt aus Umgebungsvariablen liest. Wichtig: Die Header müssen vor Spoofing geschützt werden, indem der Reverse Proxy eingehende Header mit Shibboleth-Attributnamen entfernt.

## TYPO3 v12 funktioniert, v13-Kompatibilität erfordert eine Prüfung der Authentication-Service-API

Die shibboleth-Extension nutzt die TYPO3 Authentication Service API, die seit Jahren stabil ist, aber in v13 Anpassungen erfahren hat. Unter TYPO3 v12 läuft die aktuelle Version ohne Probleme. Für v13 ist ein Update der Service-Registrierung und der Middleware-Konfiguration nötig. Hochschulen, die TYPO3-Upgrades planen, sollten die SSO-Integration als eigenen Testblock in die Upgrade-Planung aufnehmen. Gosign empfiehlt, parallel zur shibboleth-Extension die oidc-Extension zu evaluieren, weil viele IdPs inzwischen sowohl SAML als auch OIDC unterstützen und OIDC die einfachere Architektur ohne Shibboleth SP auf dem Server ermöglicht.

--- shibboleth_auth TYPO3 - SSO Integration | Gosign ---
> Shibboleth SSO in TYPO3: Setup, Attribut-Mapping & Troubleshooting. Enterprise-Auth mit KI-beschleunigter Entwicklung.

## Wie DFN-AAI-Hochschulen ihre TYPO3-Portale an die zentrale Identitätsverwaltung anschließen

Wer an einer deutschen Universität ein TYPO3-Portal betreibt, kommt an Shibboleth nicht vorbei. Das DFN-Verein-Projekt AAI betreibt die größte Identity-Federation im deutschsprachigen Hochschulraum, und jede Hochschule, die Forschungsdaten, Lehrmaterialien oder Verwaltungsdienste nach außen anbieten will, muss ihre Nutzer gegen einen Shibboleth Identity Provider authentifizieren. shibboleth_auth ist die Extension, die TYPO3 in diese Landschaft einfügt: Sie liest die SAML-Assertions eines vorgeschalteten Shibboleth Service Providers aus und legt auf dieser Basis fe_users und be_users an.

## Typische Einsatzszenarien

Eine medizinische Fakultät mit 8.000 Studierenden betreibt ein TYPO3-Portal für klinische Curricula. Studierende sollen ihre Lehrmaterialien nach Login sehen, Dozenten zusätzlich eine Redaktionsoberfläche. Der zentrale Shibboleth-IdP der Universität liefert die Attribute eduPersonAffiliation, schacHomeOrganization und eine eindeutige Kennung. shibboleth_auth übernimmt das Mapping dieser Attribute auf TYPO3-Gruppen und sorgt dafür, dass ein Student nie ins Backend kommt, während ein Dozent automatisch in der Redakteursgruppe landet.

Ein zweiter typischer Fall sind außeruniversitäre Forschungseinrichtungen wie Max-Planck-Institute oder Fraunhofer-Gesellschaften. Ihre Mitarbeiter stammen aus Dutzenden Partnerhochschulen, und jeder soll sich mit seiner Heimat-Kennung an zentralen Projektportalen anmelden können. shibboleth_auth in Verbindung mit einem eduGAIN-angebundenen SP macht genau das möglich: Ein Gastforscher aus Zürich meldet sich mit seinem SWITCHaai-Account an einem deutschen Portal an, ohne dass ein lokaler Account existieren muss.

Der dritte Kontext ist die öffentliche Verwaltung, wo Bundesländer zunehmend landesweite IdPs betreiben, um Bürgerkonten und Mitarbeiter-Zugänge zu bündeln. Eine Landesbehörde mit mehreren TYPO3-Portalen für verschiedene Fachbereiche kann über shibboleth_auth alle Portale an den zentralen IdP des Landes anbinden und spart sich separate Benutzerverwaltungen je Portal.

## Technische Architektur zwischen SP, SAML und fe_user

shibboleth_auth ist anders gebaut als klassische TYPO3-Auth-Services: Die Extension spricht nicht direkt SAML, sondern delegiert das gesamte Protokoll an einen lokal installierten Shibboleth Service Provider. Der SP, typischerweise der shibd-Daemon mit mod_shib im Apache oder dem entsprechenden Nginx-Modul, verarbeitet die SAML-Assertion, validiert Signaturen und Zertifikate und stellt die extrahierten Attribute als HTTP-Umgebungsvariablen bereit. shibboleth_auth liest diese Variablen, erzeugt oder aktualisiert den fe_user und loggt ihn in die TYPO3-Session ein.

Konfiguriert wird die Extension über die TYPO3-Extension-Konfiguration und das Extbase-Service-Pattern für Auth-Provider. Das Attribut-Mapping liegt in einer TypoScript-Datei oder direkt im Extension-Backend: HTTP-Variable links, TYPO3-Feldname rechts, optional mit Transformationen für Gruppen-IDs. Wichtig ist die Reihenfolge in der $TYPO3_CONF_VARS['SVCONF']['auth']['setup']-Konfiguration, damit shibboleth_auth vor dem Standard-Login-Service greift.

## Häufige Probleme und Lösungen

Der häufigste Fehler ist ein Redirect-Loop: Der Nutzer wird zum IdP geschickt, kommt zurück, wird erneut zum IdP geschickt, und so weiter. Ursache ist fast immer eine Diskrepanz zwischen der Session-Domain des SP und der von TYPO3, oder ein fehlendes Cookie, weil der SP seine Session unter einem anderen Pfad schreibt als TYPO3 erwartet. Die Lösung ist eine saubere Trennung: SP-Session im Pfad /Shibboleth.sso, TYPO3-Session unter / und beide unter derselben Top-Level-Domain.

Das zweite Problem betrifft Attribute: Der IdP liefert einen anderen Attributnamen, als die Extension erwartet. Besonders bei DFN-AAI ändern sich Attribut-Namensräume zwischen OID- und URN-Schreibweisen. Ohne saubere Normalisierung landet der Nutzer in keiner Gruppe oder bekommt einen leeren Namen ins Profil geschrieben. Eine Attribute-Map-Datei im SP, die alte und neue Namen auf einen einheitlichen lokalen Namen zusammenführt, löst das Problem dauerhaft.

Das dritte Thema ist Zertifikats-Rollover. Jeder IdP tauscht seine Signing- und Encryption-Zertifikate regelmäßig aus, typischerweise alle zwei Jahre. Der SP muss die neuen Zertifikate über den Metadaten-Feed ziehen, sonst bricht die Assertion-Validierung plötzlich ab. Die Metadaten-Provider-Konfiguration im shibboleth2.xml sollte daher immer mit einem automatischen Refresh-Intervall von wenigen Stunden und einer Signatur-Prüfung gegen den Federation-Signer laufen.

Ein viertes Problemfeld sind Session-Lifetimes. Shibboleth- und TYPO3-Sessions haben voneinander unabhängige Timeouts: Läuft die SP-Session ab, während die TYPO3-Session noch aktiv ist, sieht der Nutzer zwar seine geschützten Inhalte, aber ein Neu-Login schlägt fehl, weil der SP keine gültige Assertion mehr hat. Die saubere Lösung ist, beide Session-Dauern auf denselben Wert zu setzen und ein paralleles Logout-Verhalten zu konfigurieren, sodass Single Logout tatsächlich beide Sessions beendet.

## Migration und Versions-Kompatibilität

shibboleth_auth hat die TYPO3-Versionen v9, v10 und v11 über Community-Forks lange Zeit begleitet, die Situation in v12 und v13 ist jedoch unterschiedlich je nach Fork-Zweig. Einige Forks haben den Sprung auf Symfony-basierte Auth-Services vollzogen, andere sind auf v11 stehen geblieben. Wer aktuell auf v12 migriert, sollte vor dem Upgrade prüfen, ob der eigene Extension-Zweig noch gepflegt wird oder ein Wechsel auf die OIDC-Extension die bessere Wahl ist.

Der Migrationspfad von Shibboleth zu OIDC ist für viele Hochschulen relevant geworden, seit Keycloak und vergleichbare Identity-Broker SAML- und OIDC-Clients parallel anbinden können. Gosign hat solche Übergänge mehrfach begleitet und betreibt während der Umstellungsphase in der Regel beide Auth-Pfade parallel, sodass Legacy-Systeme weiter über Shibboleth anmelden, während neue Portale direkt OIDC sprechen.

Wer dauerhaft bei shibboleth_auth bleibt, sollte den Wartungs-Aufwand realistisch einschätzen. Die Extension selbst ändert sich selten, die umgebende Infrastruktur aber regelmäßig: Shibboleth SP veröffentlicht Security-Updates, DFN-AAI aktualisiert Metadaten und Zertifikate, Apache- oder Nginx-Versionen werden ausgetauscht, und jede dieser Änderungen kann den Login-Fluss brechen. Eine saubere Überwachung der Auth-Pipeline mit synthetischen Logins und Alerts bei fehlgeschlagenen Assertions ist daher kein Nice-to-have, sondern Teil des Betriebskonzepts für eine stabile SSO-Integration.

--- Slick Carousel TYPO3 - Slider | Gosign ---
> Slick Slider Integration für TYPO3. jQuery-basiert. Gosign migriert auf Swiper oder Splide: kein jQuery nötig, bessere Performance, native.

## Slick Carousel zwingt TYPO3-Websites, jQuery zu laden, obwohl es seit Jahren Alternativen ohne gibt

Slick (von Ken Wheeler) war zwischen 2014 und 2020 der populärste JavaScript-Slider. "The last carousel you'll ever need" versprach die Dokumentation. Responsive, Touch-fähig, Lazy Loading, Autoplay, Infinite Scroll, Variable Width. Für TYPO3 gibt es mit slickcarousel eine Extension, die Slick als Content-Element einbindet. Das Problem in 2026: Slick hängt an jQuery. Das letzte Slick-Release stammt von 2017 (v1.8.1). Keine Updates seit über 8 Jahren, keine Bug-Fixes, keine Sicherheitspatches.

jQuery selbst wird von immer weniger TYPO3-Projekten benötigt. TYPO3 v12 und v13 liefern jQuery nicht mehr standardmässig aus. Wer Slick Carousel nutzt, muss jQuery (90 KB minifiziert) als zusätzliche Abhängigkeit laden, nur für den Slider. Das ist technische Schuld, die bei jedem Seitenaufruf Performance kostet.

## Typische Einsatzszenarien

**Bild-Karussells auf Unterseiten.** Produktseiten, Referenzseiten oder Galerie-Seiten mit 5 bis 20 Bildern, die als horizontaler Slider durchblätterbar sind. Slick rendert die Bilder mit Navigations-Pfeilen und optionalen Dots. Autoplay lässt die Bilder automatisch durchlaufen. In der Praxis zeigen Analytics-Daten, dass Nutzer selten über das dritte Bild hinaus klicken.

**Testimonial-Slider.** Kundenzitate, die als Karussell rotieren. Jede Slide zeigt ein Zitat, den Namen und optional ein Foto. Slick wird hier oft mit centerMode (das aktive Element ist grösser als die Nachbarn) und adaptiveHeight (die Slider-Höhe passt sich an den Inhalt an) konfiguriert.

**Logo-Slider für Kundenreferenzen.** Eine horizontale Leiste mit 10 bis 30 Kundenlogos, die automatisch durchlaufen. Slick im variableWidth-Modus (verschiedene Logo-Breiten) mit infinite Scroll (nahtloses Durchlaufen). Dieses Szenario ist besonders einfach durch CSS-only-Lösungen (CSS-Animation mit @keyframes) ersetzbar, völlig ohne JavaScript.

## Technische Architektur

Die slickcarousel-Extension für TYPO3 bindet die Slick-Library (slick.min.js, 43 KB) und das zugehörige CSS (slick.css + slick-theme.css, 8 KB) ein. jQuery (90 KB) wird als Abhängigkeit geladen, sofern nicht bereits global vorhanden. Das Content-Element erlaubt Redakteuren, Bilder hochzuladen und Slider-Optionen zu konfigurieren: Slides to Show (1 bis 6), Slides to Scroll, Autoplay (ja/nein), Autoplay Speed (ms), Dots, Arrows, Fade-Effekt, Responsive Breakpoints.

Die Konfiguration wird als data-Attribut am Slider-Container gespeichert. Das Initialisierungsskript liest die Optionen und ruft `$('.slick-element').slick(options)` auf. Für mehrere Slider auf einer Seite wird jeder separat initialisiert.

Die TYPO3-Integration nutzt ein Fluid-Template, das die Bilder als `<div>`-Elemente innerhalb des Slider-Containers rendert. Jede Slide kann neben dem Bild auch Text, Links und CTA-Buttons enthalten, je nach Template-Konfiguration.

## Häufige Probleme und Lösungen

**Slider springt beim Laden (Layout Shift).** Slick initialisiert den Slider per JavaScript. Bis das Script geladen und ausgeführt ist, werden alle Bilder untereinander angezeigt. Dann springt das Layout, wenn Slick die Bilder horizontal anordnet. Das erzeugt einen messbaren Cumulative Layout Shift (CLS), einen Core Web Vital. Lösung kurzfristig: CSS-Regeln definieren, die den Slider-Container vor der JavaScript-Initialisierung bereits korrekt dimensionieren (feste Höhe, overflow:hidden). Lösung langfristig: Auf eine Library umsteigen, die CLS nativ vermeidet.

**Touch-Events funktionieren nicht konsistent.** Slick's Touch-Handling basiert auf einer eigenen Event-Implementierung, die auf aktuellen iOS- und Android-Versionen teilweise nicht mehr korrekt funktioniert. Besonders betroffen: Swipe-Geste wird als Scroll interpretiert, Slider reagiert nur auf sehr schnelle Wischbewegungen. Lösung: Es gibt keinen Fix, weil Slick nicht mehr gewartet wird. Migration ist die einzige Option.

**Accessibility-Mängel.** Slick erzeugt Markup, das nicht WCAG-konform ist: fehlende ARIA-Labels, keine Tastaturnavigation für Dots, Autoplay ohne Pause-Button. Für Unternehmen, die WCAG 2.1 AA einhalten müssen (öffentliche Einrichtungen, Barrierefreiheitsstärkungsgesetz ab 2025), ist Slick ohne umfangreiche Anpassungen nicht nutzbar. Lösung: Splide als Alternative (vollständige ARIA-Unterstützung, Tastaturnavigation, Autoplay-Pause nativ).

## Migration und Versions-Kompatibilität

Die slickcarousel-Extension unterstützt TYPO3 v10 und v11. Für TYPO3 v12 und v13 gibt es keinen offiziellen Release (Stand April 2026). Die Slick-Library selbst ist seit 2017 auf v1.8.1 eingefroren und wird nicht weiterentwickelt.

Gosign migriert Slick-basierte Slider auf Swiper (175+ Features, Touch-native, kein jQuery, 40 KB) oder Splide (WCAG-konform, kein jQuery, 30 KB). Die Migration umfasst drei Schritte: Slider-Konfigurationen inventarisieren (welche Optionen werden genutzt), die neue Library einbinden und konfigurieren, Fluid-Templates anpassen (Markup-Struktur und CSS-Klassen ändern sich). Pro Slider dauert die Migration 2 bis 4 Stunden. Bei einer Website mit 5 verschiedenen Slider-Typen ist das Projekt in 2 bis 3 Tagen abgeschlossen.

Für Logo-Slider empfiehlt Gosign eine reine CSS-Lösung ohne JavaScript: Eine CSS-Animation (`@keyframes scroll`) bewegt die Logos horizontal, `animation-play-state: paused` bei Hover stoppt die Bewegung. Das Ergebnis ist 0 KB JavaScript-Overhead und funktioniert auf allen Browsern ab IE 11.

Für Testimonial- und Content-Slider empfiehlt Gosign Splide, weil die Extension volle ARIA-Unterstützung und Tastaturnavigation mitbringt. Seit dem Barrierefreiheitsstärkungsgesetz (BFSG, ab Juni 2025 wirksam) müssen neue Websites WCAG 2.1 AA erfüllen. Slick Carousel besteht diesen Test nicht, Splide schon. Die Migration von Slick auf Splide lohnt sich also nicht nur für Performance, sondern auch für Compliance.

Gosign dokumentiert nach jeder Slider-Migration die Performance-Verbesserung: PageSpeed Score vorher/nachher, jQuery-Entfernung (falls Slick die einzige jQuery-Abhängigkeit war), Core Web Vitals Delta. Bei Projekten, die von Slick auf Splide umgestellt wurden, lag die durchschnittliche PageSpeed-Verbesserung bei 12 bis 25 Punkten, primär durch den Wegfall von jQuery und die kleinere Library-Grösse.

--- Öffnungszeiten TYPO3 | Gosign ---
> Öffnungszeiten-Verwaltung für TYPO3: Reguläre Zeiten, Feiertage, Sonderöffnungszeiten. Zeigt aktuellen Status an (Offen/Geschlossen).

## Besucher wollen wissen, ob eine Einrichtung gerade geöffnet hat, nicht die regulären Zeiten nachschlagen

Die häufigste Frage, die Besucher auf der Website einer Bibliothek, eines Museums oder einer Behörde haben, ist simpel: Haben Sie gerade offen? Trotzdem zeigen die meisten TYPO3-Websites eine statische Tabelle mit den regulären Öffnungszeiten, die an Feiertagen, Brückentagen und Sonderschliessungen falsch ist. slub_web_openhours löst genau dieses Problem. Die Extension verwaltet reguläre Öffnungszeiten, Feiertage und Sonderöffnungszeiten in einer einzigen Datenstruktur und zeigt im Frontend den aktuellen Status in Echtzeit an: Geöffnet (grün) oder Geschlossen (rot), inklusive der nächsten Öffnungszeit. Entwickelt wurde die Extension von der SLUB Dresden (Sächsische Landesbibliothek, Staats- und Universitätsbibliothek), die das Problem aus der Praxis kennt.

## Typische Einsatzszenarien betreffen Bibliotheken, Museen und kommunale Einrichtungen

Das primäre Szenario sind Hochschulbibliotheken mit mehreren Standorten. Die SLUB Dresden betreibt vier Standorte mit unterschiedlichen Öffnungszeiten. Der Hauptstandort hat andere Zeiten als die Zweigbibliothek, und während der Semesterferien gelten verkürzte Öffnungszeiten. slub_web_openhours verwaltet jeden Standort als eigenen Datensatz mit eigenen Zeiten. Auf der Website sieht ein Student sofort, welcher Standort gerade geöffnet ist und bis wann.

Ein zweites Szenario sind Museen und Galerien. Ein Kunstmuseum hat reguläre Öffnungszeiten (Di-So 10-18 Uhr, Mo geschlossen), aber verlängerte Öffnungszeiten während einer Sonderausstellung (täglich bis 21 Uhr) und Schliessungen an Feiertagen. Die Extension erlaubt, diese Ausnahmen für definierte Zeiträume zu hinterlegen, ohne die regulären Zeiten zu ändern. Nach Ablauf des Sonderzeitraums gelten automatisch wieder die Standardzeiten.

Drittes Szenario: Kommunale Einrichtungen wie Bürgerbüros, Schwimmbäder und Jugendzentren. Eine Stadt mit 20 öffentlichen Einrichtungen pflegt die Öffnungszeiten zentral im TYPO3-Backend. Auf jeder Einrichtungsseite zeigt ein Widget den aktuellen Status. Im Sommer gelten für das Freibad andere Zeiten als im Winter, und an Brückentagen ist das Bürgerbüro geschlossen. All das wird über die Extension abgebildet.

## Technische Architektur speichert Regeln und Ausnahmen in einer kalendarischen Datenstruktur

Die Extension definiert drei Datenebenen: reguläre Zeiten (Montag bis Sonntag, Stunde:Minute bis Stunde:Minute), periodische Ausnahmen (Feiertage, die jährlich wiederkehren) und einmalige Ausnahmen (Sonderschliessung am 15. März, verlängerte Öffnung am 24. Dezember). Reguläre Zeiten bilden die Basis, Ausnahmen überschreiben sie. Die Logik ist einfach: Gibt es für das aktuelle Datum eine Ausnahme? Wenn ja, gelten die Ausnahme-Zeiten. Wenn nein, gelten die regulären Zeiten für den aktuellen Wochentag.

Das Frontend-Plugin rendert den Status über Fluid-Templates. Der aktuelle Zustand (offen/geschlossen) wird serverseitig berechnet und als CSS-Klasse ausgegeben, sodass die Farbgebung per Tailwind oder Custom CSS steuerbar ist. Optional zeigt das Widget die nächste Öffnungszeit an: "Aktuell geschlossen. Nächste Öffnung: Montag, 08:00 Uhr."

Für die Schema.org-Integration kann die Extension OpeningHoursSpecification als JSON-LD ausgeben, was Google in den Knowledge-Panel-Einträgen der Organisation anzeigt. Das ist besonders für Einrichtungen relevant, die in Google Maps erscheinen und dort korrekte Öffnungszeiten zeigen wollen.

## Häufige Probleme betreffen Zeitzonen, fehlende Feiertage und Caching

Das häufigste Problem ist das Caching. Wenn TYPO3 die Seite cached und der Cache erst nach zwei Stunden abläuft, zeigt das Widget bis zu zwei Stunden lang den falschen Status. Die Lösung: Das Öffnungszeiten-Widget per USER_INT als uncached Plugin einbinden. Das kostet minimal Performance (eine Datenbankabfrage pro Request), garantiert aber korrekten Status.

Zweites Problem: Fehlende Feiertage. Die Extension liefert keine vorkonfigurierte Feiertagsliste. Jede Einrichtung muss ihre Feiertage manuell eintragen oder über einen Import befüllen. Für bundeslandspezifische Feiertage (Fronleichnam gilt in Bayern, nicht in Berlin) ist manuelle Pflege oder ein Skript nötig, das Feiertage aus einer API (z.B. feiertage-api.de) importiert.

Drittes Thema: Zeitzonen bei internationalen Einrichtungen. Die Extension arbeitet mit der Server-Zeitzone. Wenn der TYPO3-Server in UTC läuft, aber die Einrichtung in MEZ, stimmen die angezeigten Zeiten nicht. Die Lösung: Die PHP-Zeitzone in der TYPO3-Konfiguration auf die Zeitzone der Einrichtung setzen, oder bei Einrichtungen in mehreren Zeitzonen die Berechnung per UTC+Offset im Fluid-Template anpassen.

## Die Extension läuft unter TYPO3 v11 und v12, v13-Support ist vom SLUB-Team abhängig

slub_web_openhours wird von der SLUB Dresden als Open-Source-Projekt gepflegt. Updates folgen dem internen Release-Zyklus der Bibliothek. TYPO3 v12 wird unterstützt. Für v13 hängt die Kompatibilität davon ab, ob das SLUB-Entwicklungsteam die Extension aktualisiert. Da die Extension technisch schlank ist (keine komplexen API-Abhängigkeiten), ist die Migration auf v13 mit geringem Aufwand möglich. Gosign empfiehlt bei Öffnungszeiten-Projekten, die Extension parallel zur Schema.org-Ausgabe auf der Google-Seite zu validieren, damit die Öffnungszeiten in Google Maps und im Knowledge Panel korrekt erscheinen.

--- solrfal TYPO3 - Solr File Indexing | Gosign ---
> solrfal für TYPO3: Dateien in Apache Solr indexieren. Setup, Tuning & Migration , KI-beschleunigt. 25 Jahre Erfahrung.

## Warum TYPO3-Standardsuche bei großen Dokumentbeständen kapituliert

Sobald eine TYPO3-Installation mehr als ein paar hundert PDF-Dokumente verwaltet, scheitert die eingebaute Suche an zwei Grenzen: Sie findet nur Inhalte in Datenbank-Feldern, nicht in Dateien, und ihre Ranking-Logik ignoriert die Relevanz-Signale, die Redakteure brauchen. solrfal schließt genau diese Lücke, indem es den File Abstraction Layer (FAL) von TYPO3 direkt an Apache Solr koppelt und jede Datei inklusive ihrer Metadaten durchsuchbar macht. Die Extension richtet sich an Organisationen, die Dokumente als Kern ihrer Wissensarbeit betrachten: Behörden mit Formularen, Verlage mit Fachliteratur, Hochschulen mit Lehrmaterial.

## Typische Einsatzszenarien

In einer technischen Hochschule mit rund 40.000 Studierenden liegt die Studienordnung in 180 PDF-Dateien vor, verteilt über zwölf Fakultäten. Ohne solrfal findet ein Studierender den Passus zur Prüfungsanmeldung nur, wenn ein Redakteur den Text zusätzlich als Meta-Beschreibung hinterlegt hat. Mit solrfal indexiert Apache Tika jede Seite, und die Suchanfrage liefert den richtigen Absatz samt Zitat.

Ein zweites Szenario kennen Bundesbehörden, die Gesetzestexte, Richtlinien und Formulare über ein TYPO3-CMS ausliefern. Die Dokumente ändern sich häufig, und Zugriffsrechte sind an Organisationseinheiten geknüpft. solrfal synchronisiert die fe_groups-Zugehörigkeit der Dateien automatisch in den Solr-Index, sodass ein Mitarbeiter aus dem Referat V nur Treffer sieht, für die er Leseberechtigung besitzt.

Der dritte Fall tritt bei Fachverlagen auf: Ein Verlag mit 12.000 Zeitschriftenartikeln als PDF möchte den Archivbestand über eine Facettensuche nach Jahrgang, Autor und Rubrik durchsuchbar machen. solrfal extrahiert die Metadaten, befüllt die Solr-Felder und liefert die Datenbasis für eine Facette, die klassische TYPO3-Extensions wie ke_search in dieser Größenordnung nicht mehr bedienen können.

## Technische Architektur unter Apache Tika und EXT:solr

solrfal ist eine Erweiterung der Kern-Extension EXT:solr von dkd Internet Service und setzt zwingend einen laufenden Apache Solr Server voraus, typischerweise in Version 8 oder 9. Die eigentliche Textextraktion übernimmt Apache Tika, entweder als eingebetteter Service im Solr-Container oder als eigenständiger Tika-Server. solrfal klinkt sich über die TYPO3-Event-API in den FAL-Lebenszyklus ein: Jede hochgeladene, verschobene oder gelöschte Datei löst einen Indexierungs-Job aus, der asynchron im TYPO3-Scheduler abgearbeitet wird.

Konfiguriert wird solrfal über TypoScript und die Extension-Konfiguration. Das Solr-Schema lässt sich per Managed Schema API anpassen, sodass zusätzliche Felder wie Dokumenttyp, Abteilung oder Sprache ohne Solr-Restart hinzugefügt werden können. Relevanz-Tuning erfolgt über Boosting-Queries und Function Queries, die in der Query-Konfiguration der EXT:solr definiert werden. solrfal erbt dabei alle Sprach-Features der EXT:solr, inklusive der mehrsprachigen Analyzer für Deutsch, Englisch, Französisch und weitere Standardsprachen.

## Häufige Probleme und Lösungen

Das erste Problem taucht meist beim Erstindex auf: Apache Tika bricht bei kaputten oder verschlüsselten PDFs mit einem OutOfMemoryError ab und reißt den gesamten Indexer mit. Die Extension markiert die Datei dann als fehlerhaft und überspringt sie beim nächsten Lauf nicht automatisch. Wir analysieren die Tika-Logs, trennen die verschlüsselten von den wirklich defekten Dateien und richten einen Pre-Check ein, der problematische Dateien aussortiert, bevor sie den Indexer erreichen.

Das zweite wiederkehrende Thema ist Relevanz. Teams berichten, dass die Suche zwar alle Dokumente findet, aber irrelevante Treffer ganz oben stehen. Der Grund liegt fast immer in der Default-Feldgewichtung: solrfal indexiert den gesamten Dateiinhalt in ein einziges Feld, ohne zwischen Titel, Überschriften und Fließtext zu unterscheiden. Eine saubere Lösung erfordert ein angepasstes Schema mit getrennten Feldern für Titel, Metadaten und Body sowie Boosting-Regeln, die Titeltreffer höher gewichten.

Das dritte Problem betrifft Performance bei großen Beständen. Ab etwa 50.000 indexierten Dateien wird der Scheduler zum Flaschenhals, weil solrfal jeden Job einzeln verarbeitet. Die Lösung ist Batch-Indexierung in Kombination mit einem dedizierten Worker-Prozess, der parallel zu den normalen Scheduler-Tasks läuft und solrfal-Jobs priorisiert abarbeitet. Zusätzlich lohnt sich eine differenzielle Indexierung, die bei jedem Durchlauf nur neue oder geänderte Dateien neu verarbeitet, was den Wartungs-Aufwand bei stabilen Dokumentbeständen deutlich reduziert.

Ein viertes, selteneres Thema tritt bei mehrsprachigen Installationen auf: solrfal indexiert Dateien sprachunabhängig in einen gemeinsamen Index, sodass eine französische Studie in der deutschen Trefferliste auftaucht, wenn das Suchwort international verbreitet ist. Eine saubere Sprach-Trennung erfordert mehrere Solr-Cores oder eine zusätzliche Sprach-Facette, die sich über die EXT:solr-Konfiguration pro Site-Root separat steuern lässt.

## Migration und Versions-Kompatibilität

solrfal folgt dem Release-Zyklus der EXT:solr, die aktuell TYPO3 v12 und v13 unterstützt. Der Sprung von TYPO3 v9 auf v12 ist der häufigste Migrationspfad und bedeutet fast immer auch einen Sprung von Solr 6 auf Solr 9. Dabei ändern sich das Schema-Format, die Managed-Schema-API und einige Analyzer-Klassen, was einen vollständigen Reindex erforderlich macht. Bestehende Boosting-Regeln müssen gegen das neue Query-Parser-Verhalten validiert werden, da Solr 9 bestimmte Default-Operatoren anders auswertet als Solr 6.

Wer von ke_search oder einer rein datenbankgestützten Suche migriert, muss berücksichtigen, dass solrfal einen eigenen Solr-Server voraussetzt und damit Hosting-Anforderungen erweitert. Gosign begleitet diese Migrationen seit Jahren und übernimmt bei Bedarf auch den Wechsel auf ein containerbasiertes Solr-Setup, das sich in bestehende Deployment-Pipelines einfügt.

Zu beachten ist außerdem, dass die Wartungslast von solrfal nicht zu unterschätzen ist: Solr selbst erhält regelmäßige Security-Updates, und das Schema muss bei jedem größeren Upgrade gegen neue Analyzer-Klassen geprüft werden. Ein Projekt, das sich einmal für solrfal entscheidet, übernimmt damit die Verantwortung für einen eigenen Search-Stack und sollte das beim initialen Sizing und bei der Planung der Betriebsressourcen einkalkulieren.

--- sr_freecap TYPO3 - Selbstgehosteter CAPTCHA | Gosign ---
> TYPO3 CAPTCHA-Extension ohne externe Dienste. Selbstgehosteter Spam-Schutz, DSGVO-konform, keine Daten an Google. Alternative zu reCAPTCHA.

## Warum deutsche Behörden und Kliniken auf selbstgehosteten CAPTCHA-Schutz angewiesen sind

reCAPTCHA von Google ist technisch effektiv, aber für viele Betreiber in Deutschland rechtlich problematisch: Jede Einbindung führt zu einer Übermittlung personenbezogener Daten an Google in die USA, erfordert eine aktive Einwilligung nach TTDSG und wird von mehreren Landesdatenschutzbeauftragten kritisch gesehen. sr_freecap ist die Antwort auf dieses Problem: Eine komplett selbstgehostete CAPTCHA-Extension für TYPO3, die keine externen Requests auslöst, keine Nutzerdaten an Dritte überträgt und damit ohne Consent-Banner-Blockade arbeitet. Zielgruppe sind Behörden, Kliniken, Hochschulen und datenschutzbewusste Unternehmen, die Formulare gegen Bot-Spam schützen müssen, ohne eine neue Abhängigkeit zu einem US-Dienst einzugehen.

## Typische Einsatzszenarien

Eine Universitätsklinik betreibt ein Kontaktformular für Patientenanfragen, ein Bewerbungsformular für Pflegepersonal und ein Presseanfrage-Formular. Alle drei werden regelmäßig von Bots angegriffen, die generische Werbebotschaften oder Phishing-Versuche absenden. Die Klinik-IT hat entschieden, keine Google-Dienste einzubinden, weil der Datenschutzbeauftragte die Einwilligungspflicht vermeiden will. sr_freecap generiert serverseitig Bildgrafiken mit Buchstabenkombinationen, prüft die Eingabe auf dem eigenen Server und sendet zu keinem Zeitpunkt eine Information nach außen.

Ein zweiter Fall ist eine Stadtverwaltung mit etwa 15 Online-Formularen für Bürgeranliegen, von der Umzugsmeldung bis zur Beantragung eines Bewohnerparkausweises. Der Landesdatenschutzbeauftragte hat bei einem Audit explizit empfohlen, keine externen CAPTCHAs einzusetzen. sr_freecap integriert sich in die TYPO3-Formular-API (Powermail oder das Form Framework) und schützt damit alle Formulare ohne zusätzliche Einwilligung.

Der dritte Kontext sind Kammern und Verbände, die Mitgliederlisten, Adressen oder öffentliche Register verwalten. Jede dieser Organisationen betreibt ein Suchformular oder ein Kontaktformular, das Bot-geschützt sein muss, aber gleichzeitig die Datenschutzgrundhaltung wahrt. sr_freecap liefert einen einfachen visuellen Test, der für Menschen lösbar und für einfache OCR-Bots eine spürbare Hürde darstellt.

## Technische Architektur: GD-Library, Session und Form-API

sr_freecap erzeugt die CAPTCHA-Bilder serverseitig mit der GD-Library oder ImageMagick, wobei GD die Standardoption ist und in nahezu jeder PHP-Installation ohne Zusatzaufwand verfügbar ist. Die Buchstaben werden aus einem konfigurierbaren Alphabet zufällig gezogen, in ein Bild mit Hintergrundrauschen und Verzerrung gezeichnet und an den Browser ausgeliefert. Der erwartete Klartext wird in der TYPO3-Session abgelegt und beim Absenden des Formulars mit der Nutzereingabe verglichen.

Die Integration in Formulare erfolgt über einen Validator für das TYPO3 Form Framework und über die Powermail-API, wobei das Feld als zusätzliches Element in der Form-Definition eingebunden wird. Audio-CAPTCHAs als Barrierefreiheits-Alternative sind in der Extension verfügbar, aber deaktiviert per Default, und sollten bei Formularen mit breiter Zielgruppe aktiviert werden, um Nutzer mit Sehbehinderung nicht auszuschließen. Konfiguriert wird sr_freecap über TypoScript, das die Länge des CAPTCHA-Strings, die verwendeten Schriftarten und das Rauschlevel steuert.

## Häufige Probleme und Lösungen

Das erste Problem ist Lesbarkeit versus Sicherheit. Wird das CAPTCHA zu stark verrauscht, scheitern auch menschliche Nutzer und brechen das Formular ab, was die Conversion-Rate spürbar drückt. Ist es zu schwach verrauscht, lesen moderne OCR-Engines den Klartext in Sekunden aus. Die praktikable Lösung liegt in einer moderaten Verzerrung kombiniert mit einem Honeypot-Feld, das als unsichtbares Eingabefeld im Formular liegt. Menschen füllen es nicht aus, Bots oft doch, und diese Einreichungen werden still verworfen.

Das zweite Problem betrifft Barrierefreiheit. Ein rein visuelles CAPTCHA schließt blinde und sehbehinderte Nutzer aus, was bei öffentlichen Einrichtungen ein Verstoß gegen das Behindertengleichstellungsgesetz und die BITV sein kann. Die Aktivierung des Audio-Modus und zusätzlich eine einfache Rechenaufgabe als Alternative schaffen zugängliche Wege, die Anforderung zu erfüllen, ohne auf Schutz zu verzichten.

Das dritte Thema ist Session-Handling. sr_freecap speichert die erwartete Lösung in der PHP-Session, was bei Load-Balancern ohne Session-Affinity oder bei stateless gehosteten TYPO3-Installationen zu Fehlern führt. Die Lösung ist entweder Sticky Sessions auf dem Load-Balancer oder ein Shared-Session-Backend wie Redis, das alle Nodes gemeinsam nutzen.

Ein viertes Problem ist die Wirksamkeit gegen moderne Bot-Frameworks. Einfache Headless-Browser wie Puppeteer können visuelle CAPTCHAs zwar nicht selbst lösen, aber die Aufgabe an einen externen Lösungsdienst weitergeben, der binnen Sekunden die korrekte Antwort liefert. Gegen solche Angriffe reicht ein reines Bilderkennungs-CAPTCHA nicht aus, und eine Kombination mit verhaltensbasierten Checks wie Mausbewegungs-Analyse oder dem erwähnten Honeypot ist die effektivere Verteidigung.

## Migration und Versions-Kompatibilität

sr_freecap ist eine der ältesten CAPTCHA-Extensions für TYPO3 und hat eine bewegte Versions-Geschichte: Für TYPO3 v11 und v12 existieren gepflegte Community-Forks, die v13-Kompatibilität ist von Fork zu Fork unterschiedlich. Wer aktuell auf v12 oder v13 migriert, sollte vor dem Upgrade prüfen, ob der eigene Extension-Zweig aktiv gewartet wird, und im Zweifel auf einen anderen CAPTCHA-Ansatz wechseln.

Alternativen zu sr_freecap innerhalb des datenschutzfreundlichen Spektrums sind hCaptcha (selbstgehostete Variante möglich), Friendly Captcha aus deutscher Entwicklung und Honeypot-Felder kombiniert mit serverseitigem Rate-Limiting. Gosign berät bei der Auswahl je nach Formular-Volumen, Nutzergruppe und regulatorischer Anforderung und baut bei Bedarf eine hybride Lösung, die Bot-Traffic zuerst mit Honeypot filtert und nur verdächtige Einreichungen an den CAPTCHA-Schritt schickt.

Für Einrichtungen, die aus regulatorischen Gründen keine externen Dienste einbinden dürfen, bleibt eine selbstgehostete Lösung wie sr_freecap häufig die einzige praktikable Wahl, und der Wartungs-Aufwand ist überschaubar. Wichtig ist, den CAPTCHA-Schutz regelmäßig mit aktuellen Spam-Mustern abzugleichen und die Statistik der Fehlversuche auszuwerten, um zu erkennen, wann ein Upgrade der Verzerrung oder eine Kombination mit anderen Schutzmaßnahmen sinnvoll wird.

--- Storytelling TYPO3 - Scrollytelling | Gosign ---
> Scrollytelling-Extension für TYPO3: Parallax-Scrolling, animierte Inhaltsblöcke, Scroll-Trigger-Animationen. Für immersive Content-Erlebnisse,.

## Jahresberichte und Produktpräsentationen brauchen mehr als Text und Bild

Statische Seiten mit langen Textblöcken funktionieren für Dokumentation und Blog-Artikel. Aber Jahresberichte, Produktlaunches und Unternehmensgeschichten brauchen ein Format, das den Besucher durch eine Erzählung führt. Scrollytelling, also Storytelling über Scroll-Interaktion, hat sich als das Format etabliert, das zwischen statischem Text und aufwändigem Video liegt. Die TYPO3 Storytelling-Extension bringt Parallax-Scrolling, animierte Inhaltsblöcke und Scroll-Trigger-Animationen direkt ins CMS, ohne dass ein externer Dienst oder eine Agentur pro Seite ein Unikat programmieren muss.

Der Vorteil gegenüber einer Custom-Entwicklung: Redakteure können Inhalte im TYPO3-Backend pflegen, Blöcke umsortieren und Animationen konfigurieren, ohne den Entwickler zu involvieren.

## Typische Einsatzszenarien sind Jahresberichte, Produktlaunches und Kampagnen-Landingpages

Das prominenteste Szenario sind digitale Jahresberichte. Unternehmen, Stiftungen und NGOs veröffentlichen ihre Geschäftszahlen zunehmend als interaktive Web-Story statt als PDF. Ein Scrollytelling-Jahresbericht zeigt im ersten Abschnitt die Headline-Zahl (Umsatz, Spendenvolumen, Mitgliederzahl), die beim Scrollen animiert hochzählt. Im zweiten Abschnitt erscheinen Diagramme mit Vergleichszahlen zum Vorjahr. Im dritten Abschnitt erzählen Porträtfotos und Zitate die Geschichte hinter den Zahlen. Die gesamte Story ist eine einzige Seite, die der Besucher durchscrollt.

Ein zweites Szenario sind Produktpräsentationen im B2B-Bereich. Ein Maschinenbauer stellt eine neue Fertigungsanlage vor. Beim Scrollen dreht sich das 3D-Rendering der Maschine, technische Daten blenden sich ein, Animationen zeigen den Produktionsprozess. Das ist kein Video (kein Laden, kein Buffering), sondern eine Scroll-gesteuerte Animation, die der Besucher in seinem eigenen Tempo durchgeht.

Drittes Szenario: Kampagnen-Landingpages. Eine Hilfsorganisation zeigt den Weg einer Spende: vom Klick auf den Spendenbutton über die Projektauswahl bis zum Bericht aus dem Zielland. Jeder Scroll-Abschnitt enthält ein Foto, einen kurzen Text und eine Animation, die den Fortschritt visualisiert.

## Technische Architektur rendert Sektionen als Scroll-gesteuerte Content-Blöcke

Die Extension definiert einen eigenen Content-Element-Typ "Storytelling", der aus Sektionen besteht. Jede Sektion ist ein Backend-Record mit Feldern für Headline, Text, Bild/Video (FAL), Hintergrundfarbe, Animationstyp und Scroll-Trigger. Die Sektionen werden im Backend sortiert und bilden zusammen die Scroll-Story.

Im Frontend rendert jede Sektion einen eigenen Viewport-füllenden Abschnitt. Animationen werden über CSS-Transitions und den IntersectionObserver ausgelöst: Wenn eine Sektion in den sichtbaren Bereich scrollt, startet die konfigurierte Animation (Fade-In, Slide-Left, Zoom, Counter). Parallax-Effekte verschieben Hintergrundbilder langsamer als den Vordergrund, was Tiefenwirkung erzeugt.

Die Extension liefert ein Set von vordefinierten Animationen mit. Custom Animationen lassen sich über CSS-Klassen ergänzen, die im Backend als Animationstyp auswählbar sind. Die JavaScript-Basis ist minimal: kein Framework, nur native IntersectionObserver und requestAnimationFrame. Das hält die Bundle-Grösse unter 20 KB.

Für die Performance ist entscheidend, dass Bilder lazy geladen werden. Ein Scrollytelling-Bericht mit 15 Sektionen und je einem hochauflösenden Bild erzeugt ohne Lazy Loading 30 bis 50 MB an Requests. Mit Lazy Loading lädt der Browser nur die sichtbare und die nächste Sektion.

## Häufige Probleme betreffen mobile Performance und die Barrierefreiheit

Das grösste Problem bei Scrollytelling auf Mobilgeräten ist die Performance. Parallax-Effekte, die auf Desktop flüssig laufen, ruckeln auf älteren Smartphones. Der Grund: Mobile Browser rendern Scroll-Events anders als Desktop-Browser und drosseln requestAnimationFrame im Hintergrund. Die Lösung: Parallax auf mobilen Viewports deaktivieren und durch einfache Fade-In-Animationen ersetzen. Die Extension sollte über TypoScript konfigurierbar sein, welche Animationen auf welchen Breakpoints aktiv sind.

Zweites Problem: Barrierefreiheit (WCAG 2.1). Scroll-gesteuerte Animationen sind für Nutzer mit vestibulären Störungen (Schwindel, Übelkeit bei Bewegung) problematisch. CSS prefers-reduced-motion muss respektiert werden. Die Extension sollte bei aktivierter Reduce-Motion-Einstellung alle Animationen deaktivieren und die Inhalte als statische Blöcke anzeigen. Nicht alle Storytelling-Extensions implementieren das korrekt.

Drittes Thema: SEO. Google kann JavaScript-basierte Animationen crawlen, aber der Inhalt muss auch ohne JavaScript zugänglich sein. Die Sektionen müssen als reguläre HTML-Blöcke gerendert werden, nicht als leere Container, die erst per JavaScript befüllt werden. Die Extension sollte Progressive Enhancement verfolgen: Erst der Inhalt, dann die Animation.

## TYPO3 v12 wird unterstützt, v13 erfordert ein Update der Content-Element-Registrierung

Scrollytelling-Extensions für TYPO3 gibt es in verschiedenen Varianten von verschiedenen Anbietern. Die Kompatibilität mit v12 ist bei aktiv gepflegten Extensions gegeben. Für v13 ist ein Update der Content-Element-Registrierung (NewContentElementWizard) und der TCA-Konfiguration nötig, weil v13 die FlexForm-basierte Content-Element-Konfiguration angepasst hat. Gosign setzt bei neuen Scrollytelling-Projekten auf eine Architektur, die die Animationslogik als eigenständiges JavaScript-Modul von der TYPO3-Integration trennt, um bei zukünftigen Upgrades nur die TYPO3-Schicht anpassen zu müssen.

--- Stundenplan TYPO3 - Schulen | Gosign ---
> Tabellarische Stundenplan-Darstellung für Schulen und Bildungseinrichtungen. Tages-/Wochenansicht, Filter nach Fach/Lehrer/Klasse. Responsive,.

## Schulen publizieren Stundenpläne als PDF, obwohl eine digitale Lösung allen Beteiligten Zeit spart

Die meisten Schulen in Deutschland erstellen ihren Stundenplan mit Software wie Untis, exportieren ihn als PDF und laden ihn auf die Website. Eltern, Schüler und Lehrkräfte scrollen durch eine unleserliche Tabelle, die auf dem Smartphone nicht skaliert. Änderungen (Vertretung, Raumtausch, Ausfall) erfordern einen neuen PDF-Upload. Die TYPO3 Stundenplan-Extension ersetzt diesen Workflow durch eine digitale Darstellung direkt auf der Website: Tages- und Wochenansicht, Filter nach Fach, Lehrer und Klasse, responsive Darstellung auf allen Geräten, druckbare Ansicht für das Lehrerzimmer.

Für Schulträger, die ihre Schulwebsites zentral auf TYPO3 betreiben, ist das eine skalierbare Lösung für zehn, zwanzig oder fünfzig Schulen gleichzeitig.

## Typische Einsatzszenarien reichen von der einzelnen Grundschule bis zum Schulverbund

Das Basisszenario ist die einzelne Schule mit 20 Klassen, 40 Lehrkräften und einem Stundenplan, der sich wöchentlich ändert. Die Verwaltung pflegt den Stundenplan im TYPO3-Backend oder importiert ihn aus Untis. Auf der Website sehen Eltern die Wochenansicht der Klasse ihres Kindes. Der Filter reduziert die Ansicht auf eine Klasse, ein Fach oder eine Lehrkraft. Vertretungen werden als farblich markierte Änderungen angezeigt, sodass Eltern morgens auf einen Blick sehen, ob der Unterricht regulär stattfindet.

Ein zweites Szenario sind Schulverbünde und Schulträger mit zentraler TYPO3-Installation. Eine Stadt betreibt 15 Schulwebsites auf einer Multi-Site-TYPO3-Instanz. Jede Schule hat eigene Stundenpläne, aber die Darstellung ist einheitlich. Die Extension wird einmal konfiguriert und per TypoScript-Vererbung auf alle Schulseiten ausgerollt. Neue Schulen werden mit derselben Konfiguration aufgesetzt.

Drittes Szenario: Volkshochschulen und Weiterbildungseinrichtungen. Eine VHS bietet 200 Kurse pro Semester an. Der Stundenplan zeigt, welcher Kurs an welchem Wochentag in welchem Raum stattfindet. Teilnehmer filtern nach Kursbereich (Sprachen, IT, Gesundheit) und sehen ihre persönliche Wochenansicht. In Kombination mit einem Login können registrierte Teilnehmer nur ihre gebuchten Kurse sehen.

## Technische Architektur speichert Stundenplandaten als strukturierte Records

Die Extension definiert mehrere Tabellen: Klassen, Lehrkräfte, Fächer, Räume und Stunden. Jede Stunde ist ein Record mit Verknüpfungen zu Klasse, Lehrkraft, Fach, Raum, Wochentag und Zeitfenster. Die Daten werden entweder manuell im Backend gepflegt oder über einen CSV/XML-Import aus Stundenplan-Software importiert.

Das Frontend-Plugin rendert die Daten als HTML-Tabelle mit der Wochentag-Zeitfenster-Matrix. Filter (Klasse, Lehrkraft, Fach) werden per GET-Parameter übergeben und serverseitig verarbeitet. Die Tabelle ist per CSS responsive: Auf Desktop zeigt sie die volle Wochenansicht, auf Mobilgeräten wird auf eine Tagesansicht umgeschaltet oder horizontal scrollbar gemacht.

Die Druckansicht erzeugt eine optimierte Darstellung ohne Navigation und Footer, mit Seitenumbrüchen zwischen den Wochentagen. Per Print-CSS wird die Tabelle auf A4-Querformat optimiert.

Für den Import aus Untis existieren Community-Lösungen, die den Untis-XML-Export parsen und in die TYPO3-Datenbankstruktur schreiben. Der Import kann als Scheduler-Task konfiguriert werden, sodass Änderungen in Untis automatisch auf der Website erscheinen.

## Häufige Probleme betreffen die Datenpflege und die mobile Darstellung

Das grösste Problem ist die laufende Datenpflege. Stundenpläne ändern sich wöchentlich, Vertretungen täglich. Wenn die Daten manuell im TYPO3-Backend gepflegt werden, ist der Aufwand bei 20 Klassen mit je 30 Wochenstunden erheblich. Die Lösung: Einen automatisierten Import aus der Stundenplan-Software einrichten. Ohne diesen Import ist die Extension nur für kleine Einrichtungen mit wenigen Klassen praktikabel.

Zweites Problem: Die mobile Darstellung. Eine Stundenplan-Tabelle mit fünf Spalten (Mo-Fr) und zehn Zeilen (Stunden) passt nicht auf einen 375 Pixel breiten Smartphone-Bildschirm. Horizontales Scrollen ist die pragmatische Lösung, aber Eltern finden es unintuativ. Besser: Auf mobilen Viewports automatisch auf die Tagesansicht umschalten (nur der aktuelle Tag), mit Wisch-Gesten für den Tageswechsel.

Drittes Thema: Datenschutz. Wenn Lehrkräfte namentlich im öffentlichen Stundenplan erscheinen, kann das datenschutzrechtlich problematisch sein. Manche Schulen zeigen deshalb nur Fach und Klasse, nicht den Lehrernamen. Die Extension sollte per Konfiguration steuern, welche Felder im Frontend angezeigt werden.

## Die Extension ist eine Nischenlösung ohne aktive Community-Pflege

Stundenplan-Extensions für TYPO3 sind Nischenprodukte mit kleiner Community. TYPO3 v12-Kompatibilität ist bei neueren Versionen gegeben, aber eine aktive Weiterentwicklung für v13 ist nicht garantiert. Schulen und Schulträger, die langfristig planen, sollten evaluieren, ob eine Custom-Entwicklung auf Basis von Standard-TYPO3-Content-Elementen (Extbase-Records + Fluid-Templates) nicht nachhaltiger ist als eine Community-Extension mit ungewissem Wartungshorizont. Gosign berät Bildungseinrichtungen und Schulträger bei der Wahl zwischen Community-Extension, Custom-Entwicklung und dedizierten Stundenplan-SaaS-Lösungen mit TYPO3-Anbindung.

--- Styleguide TYPO3 - QA-Extension | Gosign ---
> TYPO3 Core Extension, die alle Content-Elemente auf einer Seite visualisiert. Qualitätssicherung für Template-Entwicklung: Jedes CE in jeder.

## Warum Styleguide die wichtigste QA-Extension für TYPO3-Template-Entwickler ist

Template-Entwicklung in TYPO3 hat ein systematisches Qualitätsproblem: Entwickler testen ihre Fluid-Templates mit den Daten, die gerade auf der Website existieren. Aber Content-Elemente haben Dutzende Varianten - Headlines mit und ohne Subheadline, Textblöcke mit 3 Wörtern oder 3 Absätzen, Bilder im Hoch- und Querformat, Tabellen mit 2 oder 20 Spalten. Wer nur die aktuelle Seite prüft, verpasst die Edge Cases, die erst nach dem Launch auffallen.

Die Styleguide-Extension löst dieses Problem, indem sie automatisch alle Content-Elemente des TYPO3-Systems in jeder verfügbaren Konfiguration auf einer einzigen Seite darstellt. Damit sieht der Entwickler sofort, ob sein CSS und seine Templates alle Varianten korrekt abbilden.

## Typische Einsatzszenarien

**Template-Entwicklung bei Relaunch-Projekten.** Ein Unternehmen beauftragt einen TYPO3-Relaunch mit neuem Corporate Design. Der Frontend-Entwickler erstellt Fluid-Templates für alle Content-Elemente. Ohne Styleguide muss er für jedes Element Testdaten im Backend anlegen - ein Prozess, der bei 30+ Content-Elementen Stunden dauert. Styleguide generiert alle Testdaten automatisch: Text-Elemente in verschiedenen Längen, Bilder in verschiedenen Seitenverhältnissen, Listen, Tabellen, Uploads, Formulare. Der Entwickler öffnet eine URL und sieht alles auf einen Blick.

**Regressionstests nach TYPO3-Updates.** Ein TYPO3-Update von v11 auf v12 ändert das Rendering einzelner Content-Elemente subtil. Ein Textmedia-Element rendert plötzlich ein zusätzliches Wrapper-Div, das das CSS-Layout bricht. Ohne Styleguide fällt das erst auf, wenn ein Redakteur den Fehler auf einer Live-Seite meldet. Mit Styleguide sieht der Entwickler nach dem Update sofort, welche Elemente sich verändert haben.

**Abstimmung zwischen Design- und Entwicklungs-Team.** Designer liefern Figma-Mockups für 10 Content-Elemente. Aber wie sehen die restlichen 25 Standard-Elemente im neuen Design aus? Styleguide macht diese Lücke sichtbar: Alle Elemente sind auf einer Seite dargestellt, fehlende Gestaltungen fallen sofort auf. Gosign nutzt Styleguide in jedem Relaunch-Projekt als Abnahme-Tool für das Design-Team.

## Technische Architektur

Styleguide ist eine offizielle TYPO3 Core System Extension, die mit dem TYPO3-Quellcode ausgeliefert wird. Sie muss lediglich im Extension Manager aktiviert werden, eine separate Installation ist nicht nötig.

Die Extension arbeitet auf zwei Ebenen:

- **TCA-Generator**: Styleguide analysiert die Table Configuration Array (TCA) Definitionen aller registrierten Content-Elemente und generiert daraus Testdatensätze. Für jedes Feld wird ein sinnvoller Testwert erzeugt - Texte in verschiedenen Längen, Bilder aus dem FAL, Relationen zu anderen Records.
- **Backend-Modul**: Über das Backend-Modul kann der Administrator die Testdaten generieren, aktualisieren und wieder löschen. Die Daten werden in einem eigenen Sys-Folder gespeichert und beeinflussen den regulären Content nicht.
- **Frontend-Rendering**: Eine spezielle Seite im Seitenbaum zeigt alle generierten Content-Elemente im Frontend-Layout an. Der Entwickler sieht die Elemente genau so, wie sie auf der Live-Website erscheinen würden.

Styleguide hat keine externen Abhängigkeiten. Da es eine Core-Extension ist, wird es automatisch mit jedem TYPO3-Update aktualisiert und ist immer kompatibel mit der jeweiligen TYPO3-Version.

Wichtig: Styleguide generiert keine Testdaten für Custom Content Elements (z.B. Mask oder DCE). Es deckt nur die Core-Content-Elemente ab. Für Custom Elements muss der Entwickler eigene Testdaten anlegen oder ein ergänzendes Tool verwenden.

## Häufige Probleme und Lösungen

**Problem: Styleguide-Seite zeigt leere Bereiche.** Die Testdaten wurden generiert, aber die Frontend-Seite zeigt nicht alle Elemente. Ursache: Der Sys-Folder mit den Testdaten ist nicht korrekt als Startpunkt konfiguriert, oder das TypoScript-Setup für die Styleguide-Seite fehlt. Die Lösung: Im Backend-Modul prüfen, ob der Seitenbaum korrekt angelegt wurde, und sicherstellen, dass das Root-Template der Styleguide-Seite das gleiche TypoScript wie die reguläre Website verwendet.

**Problem: Bilder fehlen in den generierten Testdaten.** Styleguide versucht, Testbilder über das FAL (File Abstraction Layer) einzubinden. Wenn der Fileadmin-Ordner leer ist oder die Default-Storage-Konfiguration nicht stimmt, bleiben Bildfelder leer. Die Lösung: Mindestens ein Bild manuell in den Fileadmin hochladen, bevor die Testdaten generiert werden.

**Problem: Performance-Probleme bei der Styleguide-Seite.** Wenn alle Content-Elemente auf einer Seite gerendert werden, kann die Ladezeit bei komplexen Templates 10 bis 15 Sekunden betragen. Das ist für QA akzeptabel, kann aber den Server bei gleichzeitigem Zugriff belasten. Die Lösung: Styleguide nur auf der Entwicklungs- oder Staging-Umgebung aktivieren, nie auf dem Live-System.

## Migration und Versions-Kompatibilität

Styleguide ist seit TYPO3 v8 als Core System Extension verfügbar und wird mit jeder TYPO3-Version automatisch aktualisiert. Es gibt keine separaten Versionsnummern oder Kompatibilitätsprobleme, da die Extension Teil des Core-Release-Prozesses ist.

Bei einem TYPO3-Upgrade sollten die Styleguide-Testdaten nach dem Update neu generiert werden. Die alten Testdaten können auf dem neuen System inkonsistent sein, weil sich TCA-Definitionen zwischen TYPO3-Versionen ändern. Das Backend-Modul bietet dafür eine "Reset"-Funktion, die alle Testdaten löscht und neu anlegt.

Für TYPO3 v12 und v13 ist Styleguide ohne Einschränkungen verfügbar. Die Extension profitiert sogar von neuen Core-Features: In v12 wurden zusätzliche Content-Elemente (z.B. verbesserte Textmedia-Varianten) eingeführt, die Styleguide automatisch abdeckt.

Gosign integriert Styleguide in jeden TYPO3-Relaunch als festen Bestandteil des QA-Prozesses. Die Styleguide-Seite wird auf der Staging-Umgebung als permanente Referenz angelegt und dient dem Design-Team als Abnahme-URL. Änderungen an Fluid-Templates oder CSS werden dort sofort sichtbar, ohne dass jemand Testcontent auf einzelnen Seiten anlegen muss. Für Enterprise-Kunden mit mehreren Marken oder Mandanten wird pro Mandant eine eigene Styleguide-Seite generiert, um markenspezifische Template-Varianten zu vergleichen.

--- t3skin TYPO3 - Backend-Styling | Gosign ---
> Legacy Backend Skin für ältere TYPO3-Versionen. Ab TYPO3 v7+ nicht mehr relevant. Moderne TYPO3-Versionen haben eigenes Backend-Styling. Gosign.

## t3skin ist seit TYPO3 v7 obsolet, aber viele Installationen laufen noch auf Versionen, die es brauchen

t3skin war das Backend-Styling-Paket für TYPO3 v4 und v6. Es definierte Icons, Farben, Abstände und das gesamte Look-and-Feel des TYPO3-Backends. Ab TYPO3 v7 wurde das Backend-Styling in den Core integriert, t3skin als separate Extension wurde überflüssig. Trotzdem taucht t3skin in Bestandsanalysen regelmässig auf, weil es in alten Installationen installiert ist und beim Upgrade auf aktuelle TYPO3-Versionen Fehler verursacht. Wer t3skin in seiner Extension-Liste findet, hat ein klares Signal: Diese Installation ist entweder veraltet oder wurde bei einem früheren Upgrade nicht vollständig aufgeräumt.

## Typische Einsatzszenarien betreffen ausschliesslich Legacy-Installationen

Das einzige legitime Szenario für t3skin ist eine TYPO3-Installation auf Version 4.5 bis 6.2, die aus technischen oder organisatorischen Gründen nicht aktualisiert werden kann. In solchen Installationen liefert t3skin das Backend-Design. Ohne t3skin wäre das Backend visuell unbrauchbar: fehlende Icons, kaputte Layouts, unlesbare Formulare.

Ein zweites Szenario ist die Übergangsphase während einer Migration. Wenn eine Agentur eine TYPO3-v6-Installation auf v12 migriert, existiert t3skin während des Upgrade-Prozesses noch in der Extension-Liste, wird aber nach dem Upgrade deaktiviert und entfernt. In dieser Phase kann t3skin Konflikte mit dem neuen Backend-Styling verursachen, wenn es nicht rechtzeitig deinstalliert wird.

Ein drittes (Anti-)Szenario: Manche Administratoren haben t3skin in TYPO3 v7 oder v8 manuell installiert, weil sie das alte Backend-Design bevorzugten. Das funktionierte kurzfristig, erzeugte aber Darstellungsfehler, weil t3skin-CSS und Core-CSS sich widersprachen. Spätestens ab TYPO3 v9 ist das keine Option mehr.

## Technische Architektur war ein CSS/Icon-Paket ohne Geschäftslogik

t3skin war keine Extension im klassischen Sinne (kein Controller, kein Model, kein Repository). Es bestand aus CSS-Dateien, Icon-Sprites, ein paar JavaScript-Snippets für die Backend-Oberfläche und einer ext_emconf.php, die es als System-Extension registrierte. Die gesamte Logik war visuell: Farben, Schriften, Abstände, Icons. Der TYPO3-Core renderte die Backend-Module, t3skin bestimmte nur, wie sie aussahen.

Ab TYPO3 v7 übernahm der Core diese Aufgabe selbst. Das Backend-Styling wurde in das System-Extension-Paket backend integriert. Icons wurden auf ein SVG-basiertes Icon-System umgestellt (IconFactory), CSS wurde auf Less und später auf SCSS migriert. t3skin konnte diese Änderungen nicht abbilden, weil es auf dem alten Sprite-basierten Icon-System basierte.

## Häufige Probleme entstehen, wenn t3skin bei einem Upgrade nicht entfernt wird

Das häufigste Problem ist ein weisses oder kaputtes Backend nach einem TYPO3-Upgrade. Wenn t3skin in einer v12-Installation noch installiert ist, überschreibt es Core-CSS-Dateien mit veralteten Regeln. Das Ergebnis: Buttons ohne Hintergrund, Icons die nicht laden, Modul-Navigationen die nicht klickbar sind. Die Lösung: t3skin über den Extension Manager deinstallieren und die Tabellen-Einträge in sys_registry bereinigen. Wenn das Backend so kaput ist, dass der Extension Manager nicht erreichbar ist, hilft die Deaktivierung über die Kommandozeile: typo3/sysext/core/bin/typo3 extension:deactivate t3skin.

Zweites Problem: Verwaiste CSS-Dateien. Auch nach der Deinstallation von t3skin können CSS-Dateien in fileadmin/ oder typo3temp/ zurückbleiben, die der Browser cached. Ein vollständiger Cache-Clear (Browser-Cache, TYPO3-Cache, CDN-Cache) ist nach der Entfernung nötig.

Drittes Thema: Backend-Anpassungen, die auf t3skin aufbauen. Manche Agenturen haben in TYPO3 v6 Custom Backend CSS geschrieben, das t3skin-Klassen als Basis nutzt. Nach der Entfernung von t3skin brechen diese Anpassungen. Die Lösung: Custom Backend CSS auf die aktuellen Core-CSS-Klassen migrieren.

## t3skin hat keinen Upgrade-Pfad, die Migration bedeutet Entfernung

Es gibt kein Update von t3skin auf eine aktuelle Version, weil die Extension keinen Nachfolger hat. Der Nachfolger ist der TYPO3-Core selbst. Die Migration bedeutet: t3skin deinstallieren, alle Referenzen auf t3skin-CSS-Klassen in Custom Backend Modulen entfernen, und die IconFactory für Custom Icons nutzen. Gosign führt diese Bereinigung im Rahmen jeder TYPO3-Migration durch und prüft dabei, ob weitere Legacy-Extensions (css_styled_content, rtehtmlarea, adodb) in der Installation verblieben sind, die ebenfalls entfernt werden müssen.

--- Copyright Bilder TYPO3 | Gosign ---
> Copyright-Hinweise automatisch zu Bildern hinzufügen. IPTC/EXIF-Metadaten auslesen, als Overlay oder Fußzeile anzeigen. Rechtskonformer Umgang.

## Fehlende Bild-Copyrights kosten Unternehmen jedes Jahr Tausende Euro in Abmahnungen

Stockfoto-Agenturen wie Getty Images, Adobe Stock und Mauritius setzen systematisch Webcrawler ein, die das Internet nach unlizenziert oder falsch attributierten Bildern durchsuchen. Fehlende Copyright-Hinweise sind der häufigste Grund für Abmahnungen. Je nach Agentur und Bild liegen die Forderungen zwischen 500 und 5.000 Euro pro Bild. Bei einer Website mit 200 Stockfotos kann ein einziger Audit-Durchlauf der Agentur fünfstellige Nachforderungen erzeugen. tgm_copyright automatisiert die Copyright-Kennzeichnung in TYPO3: Die Extension liest IPTC- und EXIF-Metadaten aus Bilddateien aus und zeigt den Copyright-Hinweis automatisch als Overlay oder Fusszeile an. Jedes Bild, das über FAL (File Abstraction Layer) verwaltet wird, bekommt seinen Rechtehinweis, ohne dass Redakteure manuell eingreifen müssen.

## Typische Einsatzszenarien umfassen Unternehmenswebsites, Verlage und öffentliche Einrichtungen

Das häufigste Szenario ist die Unternehmenswebsite mit 100 bis 500 Bildern aus verschiedenen Quellen: eigene Fotos, Stockbilder von Adobe Stock, Pressefotos von Kunden, Illustrationen von Freelancern. Jedes Bild hat andere Lizenzanforderungen. Manche verlangen eine Namensnennung ("Foto: Max Mustermann"), andere eine Quellenangabe ("Quelle: Adobe Stock"), wieder andere nur ein Copyright-Zeichen. tgm_copyright liest die Informationen aus den IPTC-Feldern (Creator, Copyright Notice, Source) und zeigt sie im konfigurierten Format an.

Ein zweites Szenario sind Verlage und Medienhäuser. Eine Regionalzeitung publiziert täglich 30 bis 50 Bilder. Die Fotografen liefern ihre Bilder mit eingebetteten IPTC-Daten. Die Extension zeigt automatisch "Foto: [Fotografenname]" unter jedem Bild an. Das spart der Redaktion fünf bis zehn Minuten pro Artikel, weil der Copyright-Hinweis nicht manuell eingetippt werden muss.

Drittes Szenario: Öffentliche Einrichtungen, die Creative-Commons-Bilder nutzen. CC-Lizenzen erfordern eine korrekte Attribution (Urheber, Lizenztyp, Link zur Lizenz). tgm_copyright kann diese Informationen aus den Metadaten lesen und als formatierte Fusszeile mit Lizenz-Link ausgeben.

## Technische Architektur nutzt die FAL-Metadaten und ein Fluid-ViewHelper-System

tgm_copyright registriert sich als TYPO3-Extension und greift auf die sys_file_metadata-Tabelle zu. Wenn ein Bild über FAL in TYPO3 hochgeladen wird, extrahiert die Extension automatisch die IPTC- und EXIF-Felder und schreibt sie in die Metadaten-Felder der FAL-Tabelle. Die relevanten IPTC-Felder sind: Creator (Fotograf), Copyright Notice (Rechteinhaber), Source (Quelle), Description (Bildunterschrift) und Credit (Agentur).

Im Frontend stellt die Extension einen Fluid-ViewHelper bereit, der den Copyright-Hinweis zu jedem Bild rendert. Der ViewHelper kann als Overlay (halbtransparente Leiste am unteren Bildrand), als Fusszeile (Text unter dem Bild) oder als Tooltip (Hover-Effekt) konfiguriert werden. Das Styling ist über CSS-Klassen steuerbar, sodass der Copyright-Hinweis zum Design der Website passt.

Für Bilder ohne eingebettete Metadaten bietet die Extension ein Fallback: Redakteure können im FAL-Metadaten-Dialog den Copyright-Hinweis manuell eintragen. Die Extension priorisiert manuelle Einträge über automatisch ausgelesene Metadaten, sodass fehlerhafte IPTC-Daten überschrieben werden können.

## Häufige Probleme betreffen fehlende Metadaten und Overlay-Platzierung

Das dominierende Problem sind Bilder ohne eingebettete IPTC-Daten. Viele Stockfoto-Downloads werden vor dem Upload in Photoshop bearbeitet, wobei die Metadaten verloren gehen. Wenn kein IPTC-Creator-Feld vorhanden ist, kann die Extension keinen Copyright-Hinweis generieren. Die Lösung: Einen Workflow etablieren, bei dem Bilder vor dem Upload auf vorhandene Metadaten geprüft werden. Alternativ: Ein TYPO3-Backend-Modul, das alle Bilder ohne Copyright-Eintrag auflistet und zur manuellen Nachpflege auffordert.

Zweites Problem: Das Overlay verdeckt wichtige Bildinhalte. Bei Porträtfotos kann ein Copyright-Overlay am unteren Bildrand das Gesicht oder den Produktnamen verdecken. Die Lösung: Per Bild konfigurierbar machen, ob das Copyright als Overlay oder als Fusszeile angezeigt wird. Standardmässig ist die Fusszeile die sichere Wahl.

Drittes Thema: Performance bei grossen Bildbeständen. Wenn die Extension bei jedem Bild-Request die IPTC-Daten aus der Datei liest statt aus der Datenbank, wird das bei Seiten mit 20 Bildern spürbar. Die Lösung: IPTC-Daten einmalig beim Upload auslesen und in der Datenbank cachen, nicht bei jedem Frontend-Request.

## TYPO3 v12 wird unterstützt, v13 erfordert ein Update der ViewHelper-Registrierung

tgm_copyright nutzt die FAL-API, die im TYPO3-Core stabil ist. Die Extension läuft unter v12 ohne Probleme. Für v13 sind Anpassungen an der ViewHelper-Namespace-Registrierung und den TCA-Konfigurationen nötig, weil v13 die Namespace-Konventionen für ViewHelper geändert hat. Gosign empfiehlt, bei jedem TYPO3-Upgrade einen Bild-Audit durchzuführen: Alle Bilder der Website prüfen, ob Copyright-Hinweise korrekt angezeigt werden, und fehlende Zuordnungen nachpflegen.

--- Ticketshop TYPO3 - Online-Tickets | Gosign ---
> Online-Ticketverkauf für Veranstaltungen: Sitzplatzwahl, Kontingente, Bezahlung, E-Ticket-Generierung, QR-Code-Validierung.

## Veranstalter zahlen 5 bis 15 Prozent Provision an externe Ticketplattformen, obwohl die eigene Website der bessere Vertriebskanal wäre

Eventim, Ticketmaster und Eventbrite nehmen Gebühren pro Ticket: zwischen 5 und 15 Prozent des Ticketpreises plus Festbetrag. Bei einem Theater mit 50.000 verkauften Tickets pro Jahr und einem Durchschnittspreis von 30 Euro sind das 75.000 bis 225.000 Euro Provision jährlich. Ein Ticketshop direkt auf der TYPO3-Website eliminiert diese Provision. Die Extension ermöglicht Online-Ticketverkauf mit Sitzplatzwahl, Kontingent-Verwaltung, Bezahlung über gängige Payment-Provider, E-Ticket-Generierung als PDF und QR-Code-Validierung am Einlass. Für Theater, Konzerthäuser, Konferenzen und kommunale Veranstaltungshäuser, die ihre Tickets überwiegend an ein bekanntes Stammpublikum verkaufen, ist das eine wirtschaftlich attraktive Alternative.

## Typische Einsatzszenarien reichen vom Stadttheater bis zur Fachkonferenz

Das prominenteste Szenario ist das Theater oder Konzerthaus mit festem Saalplan. 400 nummerierte Sitzplätze, davon 50 in der Kategorie Premium, 200 im Parkett und 150 auf dem Balkon. Der Besucher wählt im interaktiven Saalplan seinen Platz, sieht den Preis und legt das Ticket in den Warenkorb. Nach der Bezahlung erhält er ein E-Ticket als PDF mit QR-Code per E-Mail. Am Abend der Vorstellung scannt das Personal den QR-Code mit einem Smartphone. Der gesamte Prozess läuft über die TYPO3-Website, ohne Drittanbieter.

Ein zweites Szenario sind Konferenzen und Messen. Eine Fachkonferenz bietet drei Ticketkategorien: Early Bird (bis 8 Wochen vor der Veranstaltung), Regular und VIP. Kontingente begrenzen jede Kategorie auf eine feste Anzahl. Der Ticketshop zeigt die Verfügbarkeit in Echtzeit: "Early Bird: 12 von 100 verfügbar". Nach Ablauf des Early-Bird-Zeitraums wird die Kategorie automatisch deaktiviert.

Drittes Szenario: Kommunale Veranstaltungen. Eine Stadtbibliothek bietet Lesungen, Workshops und Kinderveranstaltungen an. Die Tickets sind gratis, aber die Plätze begrenzt. Der Ticketshop dient hier als Reservierungssystem. Besucher reservieren online, erhalten eine Bestätigung und werden bei Überbuchung auf eine Warteliste gesetzt.

## Technische Architektur verbindet Veranstaltungs-Records, Saalplan und Payment-Gateway

Der Ticketshop besteht aus vier Komponenten: Veranstaltungsverwaltung, Sitzplan-Editor, Checkout mit Payment-Integration und Ticket-Generierung. Veranstaltungen werden als Extbase-Records im TYPO3-Backend angelegt: Titel, Datum, Uhrzeit, Ort, Kategorien, Preise, Kontingente. Der Sitzplan wird als interaktive SVG-Grafik hinterlegt, in der jeder Platz eine eindeutige ID hat, die mit dem Kontingent-System verknüpft ist.

Der Checkout-Prozess sammelt die ausgewählten Tickets, fragt Kontaktdaten ab und leitet an ein Payment-Gateway weiter. Gängige Integrationen sind Stripe, PayPal, Mollie und SIX Payment Services. Nach erfolgreicher Zahlung erzeugt die Extension ein PDF-Ticket mit QR-Code (basierend auf einer eindeutigen Ticket-ID) und versendet es per E-Mail. Der QR-Code enthält eine URL oder einen Hashwert, der am Einlass validiert wird.

Die QR-Code-Validierung am Einlass kann über eine einfache Web-App laufen, die die Ticket-ID gegen die TYPO3-Datenbank prüft und den Status auf "eingelöst" setzt. Ein Ticket kann nur einmal eingelöst werden, Duplikate werden abgewiesen.

## Häufige Probleme betreffen Bezahlung, Stornierung und den Saalplan-Editor

Das grösste Problem ist die Zahlungsabwicklung. PCI-DSS-Konformität verlangt, dass Kreditkartendaten niemals den eigenen Server berühren. Deshalb muss die Zahlung über einen zertifizierten Payment Provider laufen, der ein Hosted Payment Form bereitstellt. Die Extension leitet den Nutzer zur Bezahlung an den Provider weiter und empfängt das Ergebnis per Callback. Wenn der Callback fehlschlägt (Timeout, Server-Restart), ist das Ticket bezahlt, aber nicht als bezahlt markiert. Die Lösung: Ein Reconciliation-Job, der offene Transaktionen beim Payment Provider nachprüft.

Zweites Problem: Stornierungen und Erstattungen. Wenn ein Besucher ein Ticket storniert, muss die Zahlung erstattet und der Platz wieder freigegeben werden. Das erfordert sowohl eine Refund-Anfrage an den Payment Provider als auch eine Statusänderung in der TYPO3-Datenbank. Ohne automatisierten Storno-Workflow ist das ein manueller Prozess.

Drittes Thema: Der Saalplan-Editor. Interaktive SVG-Saalpläne mit 400 oder mehr Plätzen sind aufwändig zu erstellen. Jeder Platz braucht eine ID, eine Kategorie und Koordinaten. Änderungen am Saalplan (neuer Block, geänderte Reihenfolge) erfordern eine Aktualisierung der SVG-Datei und der Verknüpfungen in der Datenbank.

## Ticketshop-Extensions sind Custom-Entwicklungen ohne TER-Standard

Es gibt keine Standard-Ticketshop-Extension im TYPO3 TER, die alle beschriebenen Funktionen abdeckt. Ticketshops sind fast immer Custom-Entwicklungen, die auf die spezifischen Anforderungen der Veranstaltungsstätte zugeschnitten sind. Die TYPO3-Kompatibilität hängt deshalb vom Auftragnehmer ab, nicht von einem Community-Release-Zyklus. Gosign empfiehlt bei neuen Ticketshop-Projekten zu evaluieren, ob eine headless TYPO3-Architektur mit einem spezialisierten Frontend (React, Vue) nicht langfristig wartbarer ist als eine monolithische Extbase-Lösung.

--- Tournament TYPO3 - Turniere | Gosign ---
> Turnier-/Wettbewerbsverwaltung für TYPO3: Gruppen, Spielpaarungen, Ergebnisse, Tabellen. Sportvereine, E-Sport, interne Firmenwettbewerbe.

## Sportvereine verwalten Turniere in Excel, obwohl ihre Website der logische Ort für Ergebnisse und Tabellen wäre

Jedes Wochenende finden in Deutschland Tausende Vereinsturniere statt. Die Ergebnisse werden in Excel-Tabellen eingetippt, als PDF auf die Website geladen oder im besten Fall per Hand in eine HTML-Tabelle geschrieben. Besucher der Vereinswebsite sehen veraltete Daten, weil niemand die Seite aktualisiert. Die TYPO3 Tournament-Extension ersetzt diesen Workflow: Gruppen, Spielpaarungen, Ergebnisse und Tabellen werden direkt im CMS verwaltet. Ergebnisse werden eingegeben, die Tabelle aktualisiert sich automatisch. Für Sportvereine, E-Sport-Organisationen und Firmen, die interne Wettbewerbe veranstalten, ist das eine professionelle Darstellung ohne Programmieraufwand.

## Typische Einsatzszenarien umfassen Fussballturniere, E-Sport-Ligen und Firmenwettbewerbe

Das häufigste Szenario ist das Fussballturnier eines Sportvereins. 16 Mannschaften treten in 4 Gruppen an. Jede Gruppe spielt eine Vorrunde (jeder gegen jeden), die besten zwei qualifizieren sich für die K.o.-Runde. Die Extension bildet diesen Modus vollständig ab: Gruppenphase mit Punkten, Tordifferenz und Direktvergleich, K.o.-Runde mit Viertelfinale, Halbfinale und Finale. Ergebnisse werden im Backend eingegeben, die Tabellen und der Turnierplan im Frontend aktualisieren sich automatisch.

Ein zweites Szenario sind E-Sport-Ligen. Ein Gaming-Verein organisiert eine Counter-Strike-Liga mit 12 Teams und einer Saison über 20 Spieltage. Die Extension verwaltet die Liga-Tabelle, den Spielplan und die Ergebnishistorie. Jedes Team hat eine Profilseite mit Kader, Statistiken und vergangenen Ergebnissen. Die Darstellung ist an das Vereins-CI angepasst, nicht an das Layout einer Drittplattform.

Drittes Szenario: Interne Firmenwettbewerbe. Ein Unternehmen mit fünf Standorten veranstaltet ein jährliches Schachturnier. Mitarbeitende melden sich über die Intranet-TYPO3-Seite an, die Extension lost die Paarungen aus und zeigt den Turnierfortschritt live. Das ist eine Nischenanwendung, aber für Unternehmen, die Engagement und Standort-übergreifenden Austausch fördern wollen, ein realer Use Case.

## Technische Architektur modelliert Turniere als verschachtelte Record-Struktur

Die Extension definiert mehrere Extbase-Modelle: Tournament (Turnier), Team, Group, Match, Result. Ein Turnier enthält Gruppen, jede Gruppe enthält Teams. Matches werden entweder automatisch generiert (Jeder-gegen-Jeden) oder manuell definiert (K.o.-Runde). Ergebnisse werden als Result-Records mit Match-Verknüpfung gespeichert.

Die Tabellenberechnung erfolgt serverseitig: Punkte (3-1-0 oder konfigurierbar), Tordifferenz, erzielte Tore, Direktvergleich. Die Sortierlogik ist über TypoScript konfigurierbar, weil verschiedene Sportarten unterschiedliche Kriterien priorisieren (Fussball: Tordifferenz vor Toren; Handball: Torquotient).

Das Frontend rendert zwei Hauptansichten: die Gruppenphase als Tabelle (Teams, Punkte, Siege, Niederlagen, Tordifferenz) und den K.o.-Turnierbaum als verschachtelte Bracket-Darstellung. Die Bracket-Darstellung ist per CSS als Baumstruktur umgesetzt, die auf Desktop horizontal und auf Mobilgeräten vertikal läuft.

Für grössere Turniere mit Livestream-Integration lässt sich die Extension per AJAX erweitern: Ergebnisse werden im Backend eingetragen und das Frontend aktualisiert den Spielstand per Polling alle 30 Sekunden, ohne dass die Seite neu geladen wird.

## Häufige Probleme betreffen die Turniermodus-Logik und die Bracket-Darstellung

Das grösste Problem ist die Vielfalt der Turniermodi. Ein einfaches K.o.-Turnier mit 8 Teams ist trivial. Aber ein Swiss-System-Turnier mit 40 Teams, ein Doppel-K.o.-Format oder eine Liga mit Auf- und Abstiegsrunden erfordern komplexe Logik, die nicht jede Extension abbildet. Vor der Entscheidung für eine Extension muss der Turniermodus klar definiert sein. Wenn die Extension den gewünschten Modus nicht unterstützt, ist eine Custom-Erweiterung nötig.

Zweites Problem: Die Bracket-Darstellung auf mobilen Geräten. Ein K.o.-Turnierbaum mit 16 Teams hat vier Runden (Achtelfinale bis Finale). Diese Baumstruktur passt nicht auf einen 375 Pixel breiten Bildschirm. Horizontales Scrollen oder eine vereinfachte Listenansicht sind die pragmatischen Lösungen.

Drittes Thema: Teamfotos und Wappen. Vereine wollen Logos neben den Teamnamen in der Tabelle. Die Extension muss FAL-Integration für Team-Bilder bieten, sonst müssen Redakteure Bildpfade manuell eintippen.

## Tournament-Extensions sind Nischenprodukte mit begrenzter Community

Turnier-Extensions für TYPO3 sind Nischenlösungen mit kleiner Community. Unter TYPO3 v12 laufen aktuelle Versionen stabil. Für v13 ist die Weiterentwicklung nicht garantiert, weil der Pflege-Aufwand für den Maintainer bei einer Nischen-Extension wirtschaftlich schwer zu rechtfertigen ist. Vereine, die langfristig planen, sollten evaluieren, ob eine spezialisierte Turnier-Plattform (Challengermode, Toornament) mit API-Anbindung an die TYPO3-Website nicht nachhaltiger ist als eine monolithische Extension. Gosign berät Vereine und Organisationen bei der Wahl zwischen Community-Extension, Custom-Entwicklung und SaaS-Integration.

--- tt_address TYPO3 - Adressverwaltung | Gosign ---
> Der Klassiker für Adressverwaltung in TYPO3. Kontakte, Mitarbeiter, Standorte verwalten und ausgeben. Basis für Kontaktlisten, Filialfinder,.

## Mitarbeiterverzeichnisse, Filialfinder und Kontaktlisten laufen in TYPO3 seit 20 Jahren über tt_address

Jedes Unternehmen mit mehreren Standorten, Abteilungen oder Ansprechpartnern braucht eine strukturierte Darstellung auf der Website. Wer ist zuständig für welche Region? Wo ist die nächste Filiale? Welche Kontaktdaten hat die Personalabteilung? Solche Informationen manuell als Textblöcke im CMS zu pflegen führt zu Inkonsistenzen: unterschiedliche Formate, vergessene Aktualisierungen, keine Filtermöglichkeit.

tt_address ist die älteste und am weitesten verbreitete Adressverwaltungs-Extension für TYPO3. Seit TYPO3 v4 (2006) im Einsatz, über 50.000 aktive Installationen (TER, 2026), aktiv gepflegt von der TYPO3-Community. Die Extension speichert Kontakte, Personen und Standorte als strukturierte Datensätze und gibt sie über Fluid-Templates als Listen, Karten oder Detailseiten aus.

## Typische Einsatzszenarien

**Mitarbeiterverzeichnisse für Unternehmenswebsites.** Ein Unternehmen mit 50 bis 500 Mitarbeitenden will auf der Website zeigen, wer für welches Thema zuständig ist. tt_address speichert pro Person: Name, Titel, Abteilung, Foto, E-Mail, Telefon, Standort. Die Ausgabe erfolgt als filterbare Liste (nach Abteilung, Standort) oder als Detailseite mit vCard-Download. Für Unternehmen mit Datenschutzbedenken lässt sich pro Feld steuern, ob es im Frontend sichtbar ist.

**Filialfinder und Standortübersichten.** Unternehmen mit 10 bis 500 Standorten (Filialen, Niederlassungen, Partner) nutzen tt_address als Datenbasis für einen Standortfinder. Jeder Standort hat Adresse, Geokoordinaten, Öffnungszeiten und Kontaktdaten. Die Karteneinbindung erfolgt über eine separate Extension (maps2 oder Leaflet), die die Geokoordinaten aus tt_address liest. Nutzer suchen per PLZ oder Ort und bekommen die nächstgelegenen Standorte angezeigt.

**Kontaktlisten für Behörden und Vereine.** Kommunen, Kammern und Vereine listen Ansprechpartner nach Zuständigkeit: Bauamt, Jugendamt, Ordnungsamt oder Vorstand, Kassierer, Schriftführer. tt_address bildet die Organisationsstruktur über Kategorien oder SysFolder ab. Die Ausgabe lässt sich nach Kategorie filtern und alphabetisch oder nach Position sortieren.

## Technische Architektur

tt_address speichert Datensätze in der Tabelle `tt_address`. Die Felder umfassen: Anrede, Titel, Vorname, Nachname, Firma, Abteilung, Strasse, PLZ, Ort, Land, Telefon, Fax, Mobil, E-Mail, Website, Geokoordinaten (Latitude, Longitude), Bild (FAL-Referenz), Kategorien und ein Beschreibungsfeld (RichText).

Die Ausgabe erfolgt über ein Extbase-Plugin mit List- und Detail-Action. Fluid-Templates sind vollständig anpassbar. Standardmässig liefert tt_address vier Layouts: einfache Liste, gruppierte Liste (nach Kategorie oder Ort), Detail-Ansicht und vCard-Download (RFC 6350). Eigene Templates können ohne PHP-Änderung per TypoScript konfiguriert werden.

tt_address integriert sich mit anderen Extensions: maps2 und ext:leaflet für Karteneinbindung, direct_mail und mail für Newsletter-Versand (tt_address als Empfängerliste), ke_search und indexed_search für die Volltextsuche über Adressdaten. Die Geokoordinaten können automatisch über einen Geocoding-Service (Google Maps API, Nominatim) aus der Postadresse ermittelt werden.

Kategorien (sys_category) sind der primäre Mechanismus für die Strukturierung. Ein Mitarbeiter kann mehreren Kategorien zugeordnet werden (z.B. "Vertrieb" und "Standort München"). Die Frontend-Ausgabe filtert nach Kategorie, was die Darstellung von Abteilungslisten, Standort-Teams oder thematischen Kontaktgruppen ermöglicht.

## Häufige Probleme und Lösungen

**Bilder werden nicht angezeigt.** Seit TYPO3 v10 nutzt tt_address FAL (File Abstraction Layer) für Bilder. Ältere Installationen haben Bilder als Dateinamen in einem Feld gespeichert (nicht als FAL-Referenz). Lösung: Das Upgrade-Skript von tt_address ausführen, das alte Bildverweise in FAL-Referenzen konvertiert. Bei manueller Migration: Bilder in fileadmin/ ablegen und als sys_file_reference verknüpfen.

**Geokoordinaten fehlen für den Standortfinder.** Adressen ohne Latitude/Longitude erscheinen nicht auf der Karte. Manuelles Eintragen für 200 Standorte ist nicht praktikabel. Lösung: Geocoding per Scheduler-Task automatisieren. Die Extension tt_address selbst bietet kein Geocoding, aber Gosign setzt einen Cronjob ein, der über die Nominatim-API (OpenStreetMap, kostenlos, DSGVO-konform) fehlende Koordinaten nachträgt.

**Datenimport aus externen Systemen.** HR-Abteilungen pflegen Mitarbeiterdaten in SAP, Personio oder einem anderen HR-System. Die Daten sollen automatisch auf der Website erscheinen. Lösung: Einen Sync-Mechanismus bauen, der CSV oder JSON aus dem HR-System importiert und tt_address-Datensätze anlegt oder aktualisiert. Gosign implementiert das als Scheduler-Task mit Mapping-Konfiguration (welches Quellfeld auf welches tt_address-Feld).

## Migration und Versions-Kompatibilität

tt_address unterstützt TYPO3 v11, v12 und v13 aktiv. Die Extension wird von Georg Ringer (dem Entwickler der News-Extension) mitgepflegt und folgt einem klaren Release-Zyklus. Updates auf neue TYPO3-Major-Versionen erscheinen in der Regel innerhalb weniger Wochen nach dem LTS-Release.

Für Projekte, die von einer Custom-Adressverwaltung auf tt_address umsteigen, ist die Datenmigration unkompliziert: Bestehende Daten per SQL oder CSV in die tt_address-Tabelle importieren, FAL-Referenzen für Bilder anlegen, Kategorien zuordnen. Der Aufwand für 200 Datensätze liegt bei einem halben bis einem Tag, inklusive Template-Anpassung.

Wer von einem älteren TYPO3 (v8, v9) mit tt_address v4 oder v5 upgradet, sollte das Extension-Upgrade in einem Schritt mitmachen. Die Feldstruktur hat sich zwischen den Major-Versionen leicht verändert (v5 auf v6: Umstellung auf FAL-Bilder, v7: neue Felder), aber tt_address liefert Upgrade-Wizards mit, die den Übergang automatisieren.

Für Unternehmen, die keine bestehende Adressverwaltung haben und vor der Wahl stehen, empfiehlt Gosign tt_address als Startpunkt für alle Szenarien unter 5.000 Datensätzen. Die Extension ist stabil, gut dokumentiert, hat eine grosse Community und integriert sich nahtlos mit anderen TYPO3-Extensions. Für grössere Datenmengen oder komplexe Sync-Anforderungen (Echtzeit-Abgleich mit SAP HR, Active Directory oder CRM-Systemen) baut Gosign eine Custom-Synchronisationsschicht, die tt_address als Frontend-Ausgabe nutzt, aber die Datenhoheit beim Quellsystem belässt.

Die Ersteinrichtung eines tt_address-Projekts (Installation, Template-Anpassung, Kategorie-Struktur, Geocoding-Einrichtung) liegt bei 2 bis 4 Entwicklungstagen. Ein Filialfinder mit Karteneinbindung und PLZ-Suche kommt auf 5 bis 8 Tage, inklusive der Leaflet- oder maps2-Integration.

--- typo3db_legacy TYPO3 - DB-Migration | Gosign ---
> Kompatibilitäts-Layer für die alte TYPO3 Database API (`$GLOBALS['TYPO3_DB']`). Überbrückung für Extensions, die noch nicht auf Doctrine DBAL.

## Warum typo3db_legacy seit TYPO3 v12 ein Sicherheitsrisiko für jede Extension ist

TYPO3 hat mit Version 8 die Datenbankabstraktion komplett auf Doctrine DBAL umgestellt. Die alte API über `$GLOBALS['TYPO3_DB']` wurde ab v9 als deprecated markiert und ist seit v12 vollständig entfernt. Trotzdem laufen in der Praxis tausende TYPO3-Installationen mit Extensions, die noch auf der Legacy-API basieren. typo3db_legacy hält diese Extensions am Leben, indem es die alte API als Kompatibilitäts-Layer nachbildet.

Das Problem dabei: Die Extension ist kein Dauerlösung, sondern eine Brücke. Jede weitere TYPO3-Version erhöht das Risiko, dass der Kompatibilitäts-Layer selbst bricht. Wer heute noch typo3db_legacy im Einsatz hat, steht vor einer klaren Entscheidung - migrieren oder das Upgrade auf v13 riskieren.

## Typische Einsatzszenarien

**Eigenentwickelte Extensions mit direkten Datenbankzugriffen.** Viele Agenturen haben zwischen 2012 und 2018 Extensions geschrieben, die `$GLOBALS['TYPO3_DB']->exec_SELECTquery()` direkt aufrufen. In einer typischen Mittelstands-Installation finden sich 3 bis 8 solcher Extensions. Ohne typo3db_legacy würden sie nach einem Update auf v10+ sofort mit Fatal Errors ausfallen.

**Third-Party-Extensions ohne aktiven Maintainer.** Extensions wie ältere Versionen von tt_address-Addons, Branchenverzeichnisse oder spezialisierte Import-Tools wurden oft von Solo-Entwicklern gepflegt. Wenn der Maintainer nicht mehr aktiv ist, bleibt typo3db_legacy die einzige Option, um die Funktionalität beim Upgrade zu erhalten.

**Stufenweise Migration grosser Installationen.** Unternehmen mit 50+ Extensions können nicht alles gleichzeitig migrieren. typo3db_legacy erlaubt ein schrittweises Vorgehen: Zuerst das Core-Upgrade durchführen, dann Extension für Extension auf Doctrine DBAL umstellen. Gosign plant solche Migrationen in Sprints von je 3 bis 5 Extensions und priorisiert nach Business-Kritikalität und Abhängigkeiten.

## Technische Architektur

typo3db_legacy registriert sich als TYPO3-Extension und stellt die Klasse `TYPO3\CMS\Typo3DbLegacy\Database\DatabaseConnection` bereit. Diese Klasse implementiert dieselben Methoden wie die alte `DatabaseConnection` aus dem TYPO3 Core: `exec_SELECTquery()`, `exec_INSERTquery()`, `exec_UPDATEquery()`, `exec_DELETEquery()` und die zugehörigen Prepared-Statement-Varianten.

Intern leitet der Layer alle Aufrufe an Doctrine DBAL weiter. Das funktioniert für Standard-Queries zuverlässig. Problematisch wird es bei:

- **Direkten MySQL-Funktionen** in Queries (z.B. `GROUP_CONCAT`, datenbank-spezifische Syntax)
- **Prepared Statements** mit benannten Parametern im alten Format
- **Transaction Handling** über die alte API, das nicht 1:1 auf Doctrine mappt
- **Performance**: Jeder Query durchläuft eine zusätzliche Abstraktionsschicht mit 5-15% Overhead

Die Extension hat keine eigenen Abhängigkeiten ausser dem TYPO3 Core selbst. Sie muss lediglich über Composer (`typo3/cms-typo3db-legacy`) oder das Extension Repository installiert werden.

Ein wichtiger Architektur-Aspekt: typo3db_legacy wurde als temporäre Massnahme konzipiert. Der Code enthält bewusst keine Optimierungen, die ihn langlebiger machen würden. Es gibt kein Query-Caching auf der Kompatibilitätsschicht, keine Connection-Pooling-Integration und keine Unterstützung für die erweiterten Doctrine-DBAL-Features wie Expression Builder oder Custom-Type-Mappings. Das Design-Ziel war: Die alten Queries am Laufen halten, bis sie migriert werden.

## Häufige Probleme und Lösungen

**Problem: Extension funktioniert trotz typo3db_legacy nicht nach dem Upgrade.** Ursache ist meist, dass die Extension nicht nur `$GLOBALS['TYPO3_DB']` nutzt, sondern auch andere entfernte APIs wie `$GLOBALS['TSFE']->sys_page` in alter Form oder deprecated Hook-Registrierungen. Die Lösung erfordert eine vollständige Code-Analyse der Extension, nicht nur der Datenbank-Aufrufe. Ein Scan mit dem TYPO3 Extension Scanner liefert eine priorisierte Liste aller Stellen. Gosign führt solche Scans als Bestandsaufnahme durch, bevor das eigentliche Upgrade beginnt - typischer Aufwand: 2 bis 4 Stunden pro Installation mit Bericht über alle betroffenen Extensions und geschätztem Migrationsaufwand.

**Problem: Queries liefern andere Ergebnisse als vor dem Upgrade.** Doctrine DBAL behandelt Typen strenger als die alte `mysqli`-basierte API. Ein `WHERE uid = '5'` (String statt Integer) kann in Edge Cases zu unerwartetem Verhalten führen. Die Lösung: Alle Queries auf korrekte PHP-Typen prüfen und Casts explizit setzen.

**Problem: Performance-Einbruch nach Installation.** Installationen mit mehr als 100.000 Datensätzen und häufigen Queries spüren den Overhead der doppelten Abstraktion messbar. Hier hilft nur die vollständige Migration auf Doctrine DBAL mit QueryBuilder, die den Layer überflüssig macht.

## Migration und Versions-Kompatibilität

typo3db_legacy war offizieller Bestandteil des TYPO3 Core bis Version 9.5 LTS. Für TYPO3 v10 und v11 existierte die Extension als separates Composer-Paket. Für TYPO3 v12 LTS gibt es keinen offiziell unterstützten Release mehr. Inoffizielle Forks auf GitHub versuchen die Kompatibilität herzustellen, sind aber weder vom Core-Team noch von der Extension-Owners-Gruppe getestet.

Für TYPO3 v13 ist kein Kompatibilitäts-Layer geplant oder realistisch. Die Datenbankschicht hat sich mit dem Upgrade auf Doctrine DBAL 4.0 zu stark verändert. Wer typo3db_legacy nutzt und auf v13 upgraden will, kommt an einer vollständigen Migration nicht vorbei.

Der empfohlene Migrationsweg: Jede `exec_SELECTquery()`-Stelle wird auf den Doctrine DBAL QueryBuilder umgeschrieben. Eine typische Extension mit 10 bis 20 Query-Aufrufen lässt sich in 4 bis 8 Stunden migrieren. Gosign setzt dabei auf automatisierte Code-Analyse, die alle Legacy-API-Aufrufe identifiziert und Migrationscode vorschlägt. Bei komplexen Extensions mit dynamisch zusammengebauten Queries steigt der Aufwand auf 2 bis 3 Tage pro Extension.

Die häufigsten Umschreibungen im Detail: `exec_SELECTquery()` wird zu `$queryBuilder->select()->from()->where()->executeQuery()`. `exec_INSERTquery()` wird zu `$connection->insert()`. `exec_UPDATEquery()` wird zu `$connection->update()`. Das Pattern ist konsistent, aber jede Query muss individuell geprüft werden, weil der alte Code häufig Strings zusammenkettet, die der QueryBuilder als separate Parameter erwartet. Besonders tückisch: Queries mit dynamischem WHERE-Clause-Aufbau, bei denen Bedingungen über Schleifen angehängt werden. Diese erfordern eine komplette Neustrukturierung der Logik.

--- DSGVO iFrame TYPO3 - Consent | Gosign ---
> DSGVO-konforme iFrame-Einbettung für TYPO3: Videos, Karten, Social Media erst nach Einwilligung laden. Zwei-Klick-Lösung. Platzhalter zeigen an,.

## YouTube-Videos und Google Maps ohne Einwilligung einzubetten, ist ein DSGVO-Verstoss mit Abmahnrisiko

Jede iFrame-Einbettung eines externen Dienstes überträgt die IP-Adresse des Besuchers an den Dienstanbieter, noch bevor der Besucher interagiert. Ein YouTube-Video auf der Startseite sendet beim Seitenaufruf die IP an Google, eine Google-Maps-Karte an Google, ein Facebook-Widget an Meta. Ohne vorherige Einwilligung des Besuchers ist das ein Verstoss gegen die DSGVO (Art. 6 Abs. 1 lit. a). Seit dem EuGH-Urteil Planet49 (2019) und dem BGH-Urteil zu Cookie-Bannern ist die Rechtslage klar: Technisch nicht notwendige Datenübertragungen an Dritte erfordern eine informierte Einwilligung. udg_gdpr_iframe implementiert die Zwei-Klick-Lösung für TYPO3: iFrames werden erst nach explizitem Klick des Besuchers geladen. Ein Platzhalter zeigt an, welcher Dienst geladen wird und welche Daten übertragen werden.

## Typische Einsatzszenarien betreffen YouTube, Google Maps und Social-Media-Embeds

Das häufigste Szenario sind YouTube-Videos auf Unternehmenswebsites. Eine Firma zeigt auf ihrer Karriereseite ein Recruiting-Video. Ohne Consent-Lösung sendet die Seite bei jedem Aufruf die Besucher-IP an Google. Mit udg_gdpr_iframe sieht der Besucher statt des Videos einen Platzhalter mit Vorschaubild, dem Hinweis "Dieses Video wird von YouTube bereitgestellt. Beim Abspielen werden Daten an Google übertragen." und einem Button "Video laden". Erst nach Klick wird der iFrame geladen und das Video abgespielt.

Ein zweites Szenario ist die Google-Maps-Karte auf der Kontaktseite. Die Anfahrtskarte ist ein Standardelement, aber ein datenschutzrechtliches Risiko. udg_gdpr_iframe zeigt stattdessen ein statisches Kartenbild (Screenshot) als Platzhalter. Besucher, die die interaktive Karte brauchen, klicken auf "Karte laden" und akzeptieren damit die Datenübertragung an Google.

Drittes Szenario: Social-Media-Embeds. Ein Blog-Artikel zitiert einen Tweet oder einen Instagram-Post. Auch diese Embeds laden externe Ressourcen und übertragen Nutzerdaten. udg_gdpr_iframe blockiert den Embed und zeigt einen Platzhalter, der den Dienst benennt und einen Vorschautext anzeigt.

## Technische Architektur ersetzt iFrames durch Platzhalter mit JavaScript-Loader

Die Extension registriert ein Content-Element oder modifiziert bestehende TYPO3-Content-Elemente, die iFrames enthalten. Im HTML wird der iFrame-src-Attribut durch ein data-src-Attribut ersetzt. Der Browser lädt den iFrame nicht, weil das src-Attribut fehlt. Stattdessen zeigt ein Platzhalter-Div den Dienst-Namen, den Datenschutzhinweis und einen Aktivierungs-Button.

Beim Klick auf den Button kopiert ein JavaScript-Snippet das data-src in das src-Attribut und der Browser lädt den iFrame. Optional kann der Besucher eine "Immer laden"-Checkbox aktivieren, die seine Entscheidung im LocalStorage speichert. Bei späteren Besuchen wird der iFrame dann ohne erneute Interaktion geladen.

Die Platzhalter-Darstellung ist per Fluid-Template konfigurierbar: Vorschaubild (z.B. YouTube-Thumbnail), Text, Button-Label, Link zur Datenschutzerklärung. Für YouTube-Videos kann die Extension das Thumbnail automatisch von der YouTube-API abrufen (ohne iFrame, nur ein Bild-Request).

Die Integration mit bestehenden Consent-Management-Plattformen (CookieBot, OneTrust, Borlabs Cookie) ist über die JavaScript-API möglich: Wenn der Besucher im Cookie-Banner der Kategorie "Marketing" zugestimmt hat, werden alle Marketing-iFrames automatisch geladen, ohne Zwei-Klick.

## Häufige Probleme betreffen die Erkennung aller iFrames und die CMP-Integration

Das grösste Problem ist die vollständige Erkennung aller iFrames auf der Website. Redakteure betten iFrames nicht nur über Content-Elemente ein, sondern auch direkt im RTE (Rich Text Editor), in Fluid-Templates und in TypoScript. Die Extension muss alle Quellen abdecken. Ein häufiger Fehler: Die Content-Elemente sind geschützt, aber ein YouTube-iFrame im Footer-Template lädt weiterhin ohne Einwilligung. Die Lösung: Nach der Installation einen vollständigen Crawl der Website durchführen und alle iFrame-Quellen identifizieren.

Zweites Problem: Die Integration mit dem Consent-Management. Wenn die Website bereits Borlabs Cookie oder CookieBot einsetzt, kann es Konflikte geben: Das CMP blockiert den iFrame per eigenem Mechanismus, udg_gdpr_iframe blockiert ihn nochmals. Das Ergebnis: Doppelte Platzhalter oder ein iFrame, der nach der CMP-Einwilligung trotzdem nicht lädt. Die Lösung: Entweder udg_gdpr_iframe oder das CMP für iFrame-Blockierung nutzen, nicht beides.

Drittes Thema: Barrierefreiheit. Der Platzhalter muss per Screenreader zugänglich sein: Der Button braucht ein aria-label, der Datenschutzhinweis muss als Text (nicht als Bild) vorliegen, und die Tastaturnavigation muss funktionieren.

## TYPO3 v12 wird unterstützt, die Extension bleibt relevant solange iFrames existieren

udg_gdpr_iframe löst ein Problem, das mit jeder neuen DSGVO-Auslegung relevanter wird. Die Extension läuft unter TYPO3 v12 stabil. Für v13 ist ein Update der Content-Element-Registrierung und des JavaScript-Loaders nötig. Da die Kernfunktionalität (iFrame-src durch data-src ersetzen) technisch trivial ist, lässt sich die Extension bei Bedarf mit geringem Aufwand auf jede TYPO3-Version portieren. Gosign prüft bei Datenschutz-Audits die vollständige iFrame-Abdeckung und empfiehlt die Lösung, die zum bestehenden Consent-Management der Website passt.

--- Umfrage TYPO3 - Survey Plugin | Gosign ---
> Einfache Umfrage/Poll-Extension für TYPO3. Quick Polls direkt im CMS. Für komplexere Surveys: LimeSurvey-Integration.

## Schnelle Meinungsumfragen direkt auf der Website erzeugen Engagement, das Kommentarfelder nicht liefern

Blog-Artikel mit Kommentarfunktion erzeugen in der Praxis weniger als 1 Prozent Interaktion. Eine Umfrage ("Stimmen Sie zu?", "Welche Option bevorzugen Sie?") schafft 5 bis 15 Prozent, weil die Hürde niedriger ist: ein Klick statt einer Texteingabe. Das TYPO3-Umfragetool bringt einfache Polls direkt ins CMS. Redakteure erstellen Umfragen im Backend (Frage, Antwortoptionen, Mehrfachauswahl ja/nein, Ergebnis-Anzeige), betten sie als Content-Element ein und sehen die Ergebnisse in Echtzeit. Für schnelle Meinungsbilder ist das ausreichend. Für wissenschaftliche oder komplexe Befragungen empfehlen wir die LimeSurvey-Integration, die deutlich mächtigere Fragetypen und Auswertungen bietet.

## Typische Einsatzszenarien umfassen Leser-Polls, Event-Feedback und Abstimmungen

Das häufigste Szenario ist der Leser-Poll auf einer News- oder Blog-Seite. Ein Fachmagazin fragt: "Welches Feature wünschen Sie sich in TYPO3 v14 am meisten?" mit fünf Antwortoptionen. Leser klicken auf ihre Wahl und sehen sofort die prozentuale Verteilung. Das erzeugt Engagement, liefert der Redaktion ein Stimmungsbild und gibt dem Artikel eine interaktive Komponente, die die Verweildauer erhöht.

Ein zweites Szenario ist Event-Feedback. Nach einer Konferenz oder einem Webinar sehen Teilnehmer auf der TYPO3-Website eine Umfrage: "Wie bewerten Sie die Veranstaltung?" (sehr gut / gut / befriedigend / schlecht). Das ist kein Ersatz für einen ausführlichen Feedback-Fragebogen, aber eine schnelle Zufriedenheitsmessung, die deutlich mehr Teilnehmer ausfüllen als eine E-Mail-Survey.

Drittes Szenario: Abstimmungen in Vereinen und Gremien. Ein Fachverband lässt seine Mitglieder über das Logo-Redesign abstimmen. Drei Entwürfe stehen zur Wahl, jedes Mitglied hat eine Stimme. In Kombination mit fe_login ist sichergestellt, dass nur registrierte Mitglieder abstimmen und jedes Mitglied nur einmal teilnimmt.

## Technische Architektur speichert Umfragen als Extbase-Records mit Ergebniszählung

Das Umfragetool definiert zwei Extbase-Modelle: Poll (Frage, Beschreibung, Start-/Enddatum, Mehrfachauswahl-Flag) und Option (Antworttext, Stimmenanzahl). Ein Poll enthält mehrere Options. Stimmen werden als Zähler (Integer-Inkrement) in der Option gespeichert, nicht als einzelne Records pro Teilnehmer. Das hält die Datenbank schlank und die Performance hoch, bedeutet aber auch, dass individuelle Antworten nicht nachvollziehbar sind.

Im Frontend rendert die Extension ein Formular mit Radio-Buttons (Einfachauswahl) oder Checkboxen (Mehrfachauswahl). Nach dem Absenden wird der Zähler der gewählten Option inkrementiert und die Ergebnisdarstellung als horizontales Balkendiagramm mit Prozentwerten angezeigt.

Gegen Mehrfachstimmen setzt die Extension auf Cookie-basierte Duplikat-Erkennung: Nach der Teilnahme wird ein Cookie gesetzt, das eine erneute Stimmabgabe verhindert. Das ist kein sicherer Schutz (Cookies lassen sich löschen), aber für Meinungsumfragen ohne formale Anforderungen ausreichend. Für verbindliche Abstimmungen ist die Kombination mit fe_login nötig, die eine Prüfung gegen die fe_users-Tabelle ermöglicht.

## Häufige Probleme betreffen Manipulationssicherheit und fehlende Analysefunktionen

Das grösste Problem bei offenen Polls ist die Manipulierbarkeit. Ohne Login kann ein Besucher den Cookie löschen und erneut abstimmen. Im Inkognito-Modus funktioniert die Cookie-Sperre gar nicht. Wer belastbare Ergebnisse braucht, muss die Umfrage an den fe_login koppeln. Für niederschwellige Meinungsbilder ("Was interessiert Sie?") ist die Cookie-Lösung hingegen akzeptabel.

Zweites Problem: Fehlende Analysefunktionen. Das Umfragetool speichert nur Gesamtzahlen, keine Zeitverläufe, keine Segmentierung nach Nutzergruppen, keine Kreuztabellen. Wenn die Auswertung über "63% wählen Option A" hinausgehen soll, ist LimeSurvey oder ein dediziertes Survey-Tool die bessere Wahl.

Drittes Thema: Design-Anpassung. Die mitgelieferten Templates sind funktional, aber nicht auf moderne UI-Anforderungen ausgelegt. Wer Umfragen in einem aufgeräumten Design mit Animationen (Balken füllen sich, Prozentzahlen zählen hoch) darstellen will, muss die Fluid-Templates überschreiben und eigenes CSS/JS hinzufügen.

## TYPO3 v12 wird unterstützt, für komplexere Umfragen ist LimeSurvey die bessere Wahl

Das Umfragetool läuft unter TYPO3 v12 stabil. Für v13 ist ein Update der Plugin-Registrierung nötig. Da die Extension technisch schlank ist (zwei Extbase-Modelle, ein Controller, ein Fluid-Template), ist die Migration unkompliziert. Gosign empfiehlt die Extension für einfache Polls mit drei bis fünf Antwortoptionen. Sobald Fragetypen wie Likert-Skalen, offene Textfelder, Matrixfragen oder bedingte Logik benötigt werden, ist eine LimeSurvey-Integration die professionellere Lösung.

--- VHS Development TYPO3 | Gosign ---
> Entwickler-Version der VHS ViewHelper-Sammlung. Neueste Features vor dem offiziellen Release testen. Für TYPO3-Entwickler, die an der Bleeding Edge.

## Warum die VHS Development-Version für TYPO3-Agenturen ein zweischneidiges Schwert ist

VHS (ViewHelpers Supplementary) ist mit über 300 ViewHelpers die umfangreichste Fluid-Erweiterung für TYPO3. Die Development-Version liefert neue ViewHelper und Bugfixes, bevor sie in einen stabilen Release fliessen. Für Entwickler, die an aktuellen Projekten arbeiten und auf eine bestimmte Bugfix oder ein neues Feature warten, ist das ein Vorteil. Für Produktiv-Websites ist es ein Risiko: Development-Versionen sind nicht vollständig getestet und können sich zwischen Commits inkompatibel ändern.

Die Entscheidung, ob VHS Development im Projekt eingesetzt wird, ist deshalb keine technische, sondern eine organisatorische: Hat das Team die Kapazität, Änderungen an der Library zeitnah zu testen und zu reagieren, wenn etwas bricht? Und ist die organisatorische Disziplin vorhanden, die Development-Version vor dem Go-Live wieder durch einen Stable-Release zu ersetzen?

## Typische Einsatzszenarien

**Bugfix-Zugriff vor dem nächsten Stable-Release.** Ein Projekt nutzt den VHS ViewHelper `v:format.trim`, der in der stabilen Version einen Bug hat - Whitespace in Multiline-Strings wird nicht korrekt behandelt. Der Fix existiert bereits im Development-Branch, aber der nächste Stable-Release ist erst in 4 Wochen geplant. Das Team wechselt temporär auf VHS Development, um den Bugfix sofort zu nutzen, und kehrt nach dem Stable-Release zurück.

**Evaluierung neuer ViewHelper für ein Relaunch-Projekt.** Ein TYPO3-Relaunch beginnt in 3 Monaten. Das Entwicklerteam evaluiert, ob neue VHS-ViewHelper (z.B. für responsive Image-Handling oder JSON-LD-Ausgabe) den Template-Code vereinfachen können. Die Development-Version wird in einer lokalen Entwicklungsumgebung installiert, getestet und die Ergebnisse fliessen in die Architekturentscheidung ein. Falls ein neuer ViewHelper im Stable-Release noch fehlt, kann das Team rechtzeitig eine eigene Implementierung als Fallback planen.

**Beitrag zur VHS-Entwicklung.** Agenturen, die eigene ViewHelper zu VHS beitragen oder Bugs melden, arbeiten mit der Development-Version, um ihre Patches gegen den aktuellen Codestand zu testen. Ohne Development-Version ist kein sinnvolles Contributing möglich. Pull Requests werden gegen den Development-Branch geöffnet, und nur dort kann der Contributor verifizieren, dass sein Fix keine Seiteneffekte hat.

## Technische Architektur

VHS Development ist keine separate Extension, sondern der aktuelle Entwicklungsstand des VHS-Repositories auf GitHub (FluidTYPO3/vhs). Die Installation erfolgt über Composer mit dem `dev-main` oder einem spezifischen Branch:

- `composer require fluidtypo3/vhs:dev-main` installiert den aktuellen Entwicklungsstand
- `composer require fluidtypo3/vhs:dev-feature-xyz` installiert einen spezifischen Feature-Branch
- Die `minimum-stability`-Einstellung in `composer.json` muss auf `dev` gesetzt werden, was sich auf alle Pakete auswirkt

VHS selbst hat als einzige harte Abhängigkeit den TYPO3 Core (Fluid Template Engine). Die über 300 ViewHelper decken Bereiche ab wie:

- **Content**: Rendering von Content-Elementen, FAL-Zugriff, Media-Handling
- **Format**: String-Manipulation, Datum, Zahlen, JSON, Markdown
- **Iterator**: Array-Operationen, Sortierung, Filterung, Paginierung
- **Page**: Seitenbaum-Navigation, Breadcrumb, Sitemap
- **Media**: Bild-Manipulation, Video-Embedding, Audio
- **Security**: Zugriffsprüfungen, Login-Status, FE-User-Gruppen

Die Development-Version kann ViewHelper enthalten, deren API sich noch ändert. Parameter können umbenannt, Rückgabewerte geändert oder ViewHelper komplett entfernt werden. Im Stable-Release ist die API eingefroren. Zwischen zwei Stable-Releases ändert sich im Development-Branch erfahrungsgemäss die Signatur von 5 bis 15 ViewHelpers. Wer diese in Produktiv-Templates nutzt, riskiert Fehler nach einem Composer-Update.

## Häufige Probleme und Lösungen

**Problem: Composer-Update bricht bestehende Templates.** Ein `composer update` holt die neueste Development-Version, in der ein ViewHelper-Parameter umbenannt wurde. Alle Templates, die diesen Parameter nutzen, werfen Fehler. Die Lösung: Composer-Lock-File konsequent committen und VHS Development mit einer festen Commit-Referenz installieren: `composer require fluidtypo3/vhs:dev-main#abc1234`. So wird nicht automatisch die neueste Version gezogen.

**Problem: minimum-stability dev beeinflusst andere Pakete.** Wenn `minimum-stability` in `composer.json` auf `dev` gesetzt ist, können auch andere Pakete instabile Versionen installieren. Die Lösung: `"minimum-stability": "stable"` beibehalten und VHS Development explizit als Ausnahme definieren: `"fluidtypo3/vhs": "dev-main as 6.99.0"`. Das Alias-Pattern erlaubt die Installation ohne globale Stabilitätsänderung.

**Problem: CI/CD-Pipeline schlägt mit Development-Version fehl.** Automatische Tests und Deployments, die auf Composer-Installationen basieren, können bei der Development-Version fehlschlagen, wenn GitHub temporär nicht erreichbar ist oder der Branch Force-Pushed wurde. Die Lösung: Für CI/CD-Pipelines einen lokalen Composer-Mirror (Satis) verwenden oder auf den Stable-Release wechseln.

## Migration und Versions-Kompatibilität

Die VHS Stable-Releases folgen den TYPO3 LTS-Zyklen: VHS 6.x unterstützt TYPO3 v11, VHS 7.x unterstützt TYPO3 v12. Der Development-Branch zielt jeweils auf die nächste Major-Version ab.

Der Wechsel von VHS Development zurück auf Stable ist in der Regel unkompliziert, solange keine ViewHelper genutzt werden, die nur in der Development-Version existieren. Gosign empfiehlt folgendes Vorgehen: Vor dem Wechsel auf Stable alle verwendeten VHS-ViewHelper gegen die Stable-Dokumentation abgleichen. Der VHS-Changelog auf GitHub listet alle Änderungen zwischen Development und Release.

Für TYPO3 v13 ist ein VHS 8.x-Release geplant. Teams, die heute mit der Development-Version arbeiten, sollten ihre Templates auf deprecated ViewHelper prüfen. Claus Due und das FluidTYPO3-Team kündigen Breaking Changes in der Regel im GitHub-Milestone an.

Gosign empfiehlt folgende Strategie für den Umgang mit VHS Development: Auf Entwicklungsumgebungen und in Feature-Branches die Development-Version nutzen, um neue ViewHelper zu evaluieren. Auf Staging und Produktion ausschliesslich Stable-Releases einsetzen. Wenn ein kritischer Bugfix nur in Development verfügbar ist, den spezifischen Commit als Composer-Referenz pinnen und im Code einen TODO-Kommentar hinterlassen, der bei der nächsten Stable-Release-Prüfung auffällt. Dieses Pattern verhindert, dass Development-Abhängigkeiten unbemerkt in die Produktion gelangen.

--- VHS TYPO3 - Fluid ViewHelper | Gosign ---
> Die ViewHelper-Sammlung für TYPO3 Fluid Templates von FluidTYPO3. Hunderte zusätzliche ViewHelper für Media, Content, Page, Iterator, Math, String.

## EXT:vhs ist der unsichtbare Werkzeugkasten jedes professionellen TYPO3-Templates

Wer in TYPO3 mit Fluid arbeitet und über das reine Ausgeben von Inhalten hinausgeht, landet früher oder später bei EXT:vhs. Die Extension aus dem FluidTYPO3-Ökosystem liefert mehrere hundert zusätzliche ViewHelper für Aufgaben, die der Core bewusst nicht abdeckt: Bild-Manipulation, Iterator-Logik, Math-Operationen, String-Handling, Content-Abfragen, Page-Navigation. Für Frontend-Entwicklerinnen in Agenturen und Inhouse-Teams ist vhs kein optionales Nice-to-have, sondern die Basis, auf der komplexe Template-Strukturen ohne PHP-Umwege entstehen.

Die Zielgruppe sind typischerweise Teams, die aufwendige Site Packages pflegen: Verlage mit heterogenen Content-Typen, Hochschulen mit verschachtelten Navigationen, Konzerne mit mehrsprachigen Portalen. Ohne vhs müsste jede zweite Sonderanforderung in einen eigenen ViewHelper oder in TypoScript ausgelagert werden. Mit vhs bleibt die Logik dort, wo sie hingehört: im Template.

## Typische Einsatzszenarien

Ein erstes Szenario ist die Content-Abfrage aus fremden Seitenbäumen. Ein Kundenportal eines Maschinenbauers mit 3.000 Produktseiten benötigt auf jeder Seite einen Teaser-Block mit aktuellen News aus einem separaten News-Rootline-Zweig. Der ViewHelper `v:content.get` holt Inhalte aus beliebigen Seiten und ermöglicht so modulare Seitenkompositionen, ohne TypoScript-CONTENT-Objekte bauen zu müssen.

Ein zweites Szenario ist die Iterator-Verarbeitung. Ein Verlagshaus pflegt Artikel mit Kategorien, Tags und Autoren als ObjectStorage. In Fluid allein sind Filterungen, Gruppierungen und Sortierungen über verschachtelte Objekte umständlich. Mit `v:iterator.filter`, `v:iterator.sort` oder `v:iterator.groupBy` lassen sich solche Operationen direkt im Template lesen und warten.

Ein drittes Szenario ist die Image-Verarbeitung. Ein E-Commerce-Shop mit 500 Produkten pro Saison braucht responsive Bildvarianten mit picture-Tag, WebP-Fallback und LQIP-Platzhalter. Mit vhs-Media-ViewHelpern wird dieser Block einmal im Partial definiert und anschliessend überall wiederverwendet.

Ein viertes Szenario ist die mathematische Aufbereitung von Kennzahlen in Reporting-Seiten. Wer Preise mit Zwischensummen, Prozentanteilen oder gewichteten Mittelwerten ausgeben will, greift auf `v:math.sum`, `v:math.percentage` oder `v:math.division` zurück, ohne für jede Berechnung einen eigenen Controller bauen zu müssen.

## Technische Architektur

EXT:vhs ist eine reine Library-Extension ohne Backend-Module und ohne Datenbank-Tabellen. Sie registriert Namespaces in Fluid (`{namespace v=FluidTYPO3\Vhs\ViewHelpers}`) und stellt damit die ViewHelper über den Präfix `v:` zur Verfügung. Die Extension hat keine harten Abhängigkeiten zum restlichen FluidTYPO3-Stack (Flux, Fluidcontent), auch wenn sie oft gemeinsam mit diesen eingesetzt wird.

Die Installation erfolgt über Composer mit `fluidtypo3/vhs`. In einem Site Package wird vhs üblicherweise als Dependency der eigenen Provider-Extension geführt, sodass die Namespace-Registrierung im Layout-Template oder global über das TypoScript-Konfigurationsarray erfolgt. Wer die Namespaces in jedem Template einzeln deklarieren muss, hat meistens den globalen Registrierungs-Pfad übersehen.

Für die Performance relevant ist, dass vhs keine eigenen Datenbankabfragen cached. Wer `v:content.get` oder `v:page.menu` ohne Fluid-Caching einsetzt, erzeugt im schlimmsten Fall dieselbe Abfrage bei jedem Seitenaufruf. Die Lösung liegt in sauber konfiguriertem Fluid-Caching über Page- und Content-Cache sowie der bewussten Nutzung des CacheStatic-Mechanismus im TYPO3-Core.

Das Extension-Paket ist modular aufgebaut. Einzelne ViewHelper-Gruppen (Asset, Condition, Format, Iterator, Math, Media, Page, Resource, System, Variable) können gezielt eingesetzt werden, ohne dass der gesamte Stack ins Projekt kommt. In der Praxis wird jedoch die ganze Sammlung installiert, weil die Abhängigkeiten zwischen den Gruppen schwer zu kapseln sind und der Footprint der Extension insgesamt vertretbar bleibt.

## Häufige Probleme und Lösungen

Das erste Problem ist die berüchtigte Namespace-Kollision. Wer EXT:vhs parallel zu eigenen ViewHelpern unter dem Präfix `v:` einsetzt, bekommt unvorhersehbare Überlagerungen. Die Lösung ist, eigene ViewHelper konsequent unter einem eigenen Präfix (z.B. `my:`) zu registrieren und vhs-Aufrufe auf Core-ViewHelper umzustellen, wo der TYPO3-Core inzwischen eine Alternative bietet (`f:format.padding` ersetzt `v:format.padding`).

Das zweite Problem ist die Versions-Kompatibilität mit neueren Fluid-Versionen. In TYPO3 v12 und v13 wurde Fluid mehrfach überarbeitet, was bei einigen vhs-ViewHelpern zu Deprecation-Warnings oder Typfehlern führt. Die Lösung ist ein Audit der eingesetzten ViewHelper gegen die Compatibility-Matrix im GitHub-Repository und der selektive Ersatz durch Core-Alternativen oder eigene, schlanke Implementierungen.

Das dritte Problem ist Performance unter Last. `v:iterator.filter` und `v:iterator.sort` sind bequem, aber rechenintensiv bei grossen Datenmengen. Wer ein Template mit 10.000 Produkten pro Seite rendert, sollte die Filterlogik in das Repository verschieben und nur das bereits gefilterte Ergebnis an das Template übergeben.

Ein viertes, oft übersehenes Problem sind undokumentierte Verhaltensänderungen zwischen vhs-Versionen. Ein ViewHelper, der in Version 6.x einen String zurückgab, liefert in Version 7.x plötzlich ein Array oder umgekehrt. Die Lösung ist, die vhs-Version im Composer-Lock-File zu fixieren und bei jedem Upgrade das Changelog sorgfältig gegen den eigenen Template-Bestand zu prüfen - idealerweise mit einem Lint-Schritt in der CI-Pipeline, der unbekannte ViewHelper-Signaturen sofort meldet.

## Migration und Versions-Kompatibilität

EXT:vhs ist offiziell für TYPO3 v11 und v12 freigegeben. Für v13 existiert ein Entwicklungszweig, der aktiv gepflegt wird, aber noch nicht in allen ViewHelpern produktionsreif ist. Teams, die aktuell ein Upgrade von v11 auf v12 planen, können vhs in der Regel ohne grössere Eingriffe mitnehmen. Der Upgrade-Pfad zu v13 ist für Template-intensive Projekte der kritische Punkt: Hier lohnt ein Kosten-Nutzen-Vergleich zwischen dem Beibehalten von vhs und dem schrittweisen Umbau auf Core-Fluid plus eigene ViewHelper.

Die strategische Antwort hängt vom Ausmass der vhs-Nutzung ab. Projekte, die nur eine Handvoll vhs-ViewHelper einsetzen, sollten diese beim nächsten Upgrade gezielt durch Core-Konstrukte oder projektspezifische ViewHelper ersetzen. Projekte mit hunderten vhs-Aufrufen quer durch alle Templates profitieren hingegen davon, vhs weiterzuführen und bei jedem Upgrade einen gezielten Kompatibilitätstest zu fahren. Der Ersatz lohnt sich nur dort, wo die Altlast die Wartung stärker belastet als ein kontrolliertes Mitführen.

Gosign begleitet TYPO3-Upgrades mit vhs-Altlast und entscheidet gemeinsam mit dem Team, welche vhs-ViewHelper durch Core-Konstrukte ersetzt werden und welche als schlanke Projekt-ViewHelper neu entstehen. Damit bleibt das Template-Erbe wartbar, ohne dass man sich für weitere Jahre an einen externen Library-Stack bindet.

--- Cache Warmup TYPO3 - Performance | Gosign ---
> Cache Warmup für TYPO3: Seiten-Cache nach Deployment vorheizen. CI/CD-Integration. KI-beschleunigt.

## Warum die ersten 5 Minuten nach einem TYPO3-Deployment über die User Experience entscheiden

Nach jedem Deployment wird der TYPO3-Cache geleert. Das ist technisch notwendig, hat aber eine spürbare Konsequenz: Die ersten Besucher nach dem Deployment sehen ungecachte Seiten. Statt 200ms Ladezeit warten sie 2 bis 5 Sekunden, bei komplexen Seiten auch länger. Bei einem Deployment um 9:00 Uhr morgens trifft das genau die Besucher mit der höchsten Conversion-Wahrscheinlichkeit.

warmup löst dieses Problem, indem es den Cache proaktiv füllt, bevor der erste echte Besucher die Seite aufruft. Die Extension crawlt alle Seiten der Website im Hintergrund, basierend auf der Sitemap, und priorisiert dabei die meistbesuchten Seiten. Nach 2 bis 10 Minuten (abhängig von der Seitenzahl) ist der gesamte Cache gefüllt, und jeder Besucher bekommt die volle Performance.

## Typische Einsatzszenarien

**Automatisiertes Cache-Warming nach CI/CD-Deployments.** Ein Unternehmen deployt seine TYPO3-Website 2 bis 3 Mal pro Woche über eine CI/CD-Pipeline (GitLab CI, GitHub Actions, Deployer). Nach jedem Deployment leert Deployer den Cache. warmup wird als letzter Schritt in der Pipeline aufgerufen und füllt den Cache, bevor das Deployment als "erfolgreich" gilt. Die Pipeline wartet, bis warmup fertig ist, und gibt erst dann den Traffic auf die neue Version frei.

**Cache-Rebuild nach manuellen Änderungen.** Redakteure leeren manchmal den gesamten Cache über das TYPO3-Backend, weil eine einzelne Seite nicht aktuell angezeigt wird. Das betrifft dann alle Seiten. warmup registriert sich als Hook auf das Cache-Clear-Event und startet automatisch den Warmup-Prozess. Der Redakteur merkt davon nichts, aber die Besucher spüren keinen Performance-Einbruch.

**Geplantes Warming für High-Traffic-Zeitfenster.** Ein Online-Shop auf TYPO3-Basis hat seine Spitzenzeiten zwischen 10:00 und 12:00 Uhr. Ein Scheduler-Task startet warmup täglich um 9:30 Uhr, damit der Cache pünktlich zum Traffic-Peak vollständig gefüllt ist. Das ist besonders relevant, wenn der TYPO3-Cache eine begrenzte TTL (Time-to-Live) hat und über Nacht teilweise abläuft.

## Technische Architektur

warmup arbeitet als TYPO3-CLI-Command und als Scheduler-Task. Der Warmup-Prozess läuft in drei Phasen:

- **URL-Sammlung**: warmup liest die Sitemap der Website (`sitemap.xml`) und extrahiert alle URLs. Alternativ kann ein Crawler die Sitemap aus dem TYPO3-Seitenbaum generieren, falls keine Sitemap-Extension konfiguriert ist. Die URL-Liste kann über Konfiguration gefiltert werden (z.B. nur bestimmte Seitenbäume oder Sprachen).
- **Priorisierung**: URLs werden nach Priorität sortiert. Die Priorität kann aus der Sitemap (`<priority>`-Tag), aus Matomo/Analytics-Daten oder aus einer manuellen Konfiguration stammen. Die Startseite und die Top-10-Landingpages werden zuerst gecacht.
- **Crawling**: warmup ruft jede URL per HTTP-Request auf. Der TYPO3-Caching-Framework speichert das Rendering-Ergebnis. warmup unterstützt paralleles Crawling (konfigurierbar, Standard: 4 gleichzeitige Requests), um den Prozess zu beschleunigen, ohne den Server zu überlasten.

Der CLI-Command lautet `vendor/bin/typo3 warmup:execute`. Für die CI/CD-Integration wird er typischerweise als Post-Deploy-Hook aufgerufen.

Abhängigkeiten: TYPO3 Core, Caching Framework. warmup arbeitet mit jedem Cache-Backend zusammen - Dateisystem, Redis, Memcached, APCu. In Kombination mit staticfilecache erzeugt warmup vorab statische HTML-Dateien, die vom Webserver direkt ausgeliefert werden. Die Extension bietet zudem einen Dry-Run-Modus, der die URL-Liste anzeigt, ohne Requests auszuführen. Das ist nützlich, um die Warmup-Konfiguration zu überprüfen, bevor der erste produktive Lauf startet.

## Häufige Probleme und Lösungen

**Problem: warmup-Prozess dauert über 30 Minuten.** Bei Websites mit mehr als 5.000 Seiten und Multi-Language-Setup (z.B. 1.000 Seiten x 5 Sprachen = 5.000 URLs) kann der Warmup-Prozess lang dauern. Die Lösung: Parallelität erhöhen (z.B. auf 8 gleichzeitige Requests), unwichtige Seiten ausschliessen (z.B. Paginierungsseiten, Tag-Archive) und den Prozess auf die Top-500-Seiten beschränken. Die restlichen Seiten werden beim ersten Besuch gecacht.

**Problem: Server-Load steigt während des Warmups auf 100%.** warmup erzeugt reale HTTP-Requests gegen den eigenen Server. Ohne Rate-Limiting kann das die Serverlast auf ein Niveau treiben, das echte Besucher ausbremst. Die Lösung: Parallelität reduzieren und ein Delay zwischen Requests konfigurieren (z.B. 100ms). Auf dedizierten Servern mit ausreichend Ressourcen ist das kein Problem; auf Shared Hosting kann warmup den Server des Providers triggern.

**Problem: Gecachte Seiten sind nach dem Warmup nicht aktuell.** warmup cached die Seite so, wie sie zum Zeitpunkt des Aufrufs existiert. Wenn Redakteure während des Warmup-Prozesses Content ändern, stimmt der Cache nicht mit dem aktuellen Stand überein. Die Lösung: Warmup erst starten, nachdem alle Content-Änderungen abgeschlossen sind. In CI/CD-Pipelines ist das automatisch der Fall, bei manuellen Cache-Clears sollte der Warmup mit 30 Sekunden Verzögerung starten.

## Migration und Versions-Kompatibilität

Die warmup-Extension (eliashaeussler/typo3-warming) ist für TYPO3 v11 und v12 LTS verfügbar und wird aktiv gepflegt. Für TYPO3 v13 wird die Kompatibilität zeitnah nach dem Release erwartet.

Wer bisher manuelle Warmup-Scripte nutzt (curl-Schleifen, wget-Crawler), kann diese durch warmup ersetzen. Der Vorteil: warmup kennt die TYPO3-Sitemap-Struktur, priorisiert nach Traffic und integriert sich in den Scheduler. Ein manuelles Script crawlt blind, warmup crawlt intelligent.

Die Kombination warmup + staticfilecache + Redis ist der Performance-Stack, den Gosign für Enterprise-TYPO3-Installationen empfiehlt. warmup füllt den Cache, staticfilecache serviert statische HTML-Dateien ohne PHP, Redis speichert Datenbank-Queries. Zusammen erreichen TYPO3-Websites damit Ladezeiten unter 100ms. Für Websites mit weniger als 500 Seiten und moderatem Traffic reicht warmup allein ohne staticfilecache aus. Der einfache TYPO3-Page-Cache liefert bereits Ladezeiten unter 300ms, wenn er korrekt gefüllt ist. warmup stellt sicher, dass dieses Niveau von der ersten Sekunde nach dem Deployment an gehalten wird.

--- Wetter-Widget TYPO3 | Gosign ---
> Wetter-Widget für TYPO3: Aktuelle Wetterdaten von OpenWeatherMap oder anderen APIs. Tourismus-Websites, Outdoor-Events, regionale Portale.

## Tourismus-Websites, die kein aktuelles Wetter zeigen, verschenken eine der meistgesuchten Informationen

Wenn jemand "Mallorca Wetter" oder "Zugspitze aktuell" googelt, erwartet er auf der Destinations-Website eine Wetter-Anzeige. Fehlt sie, verlässt der Besucher die Seite und nutzt eine Wetter-App. Das ist eine verpasste Chance, weil der Besucher bereits auf der richtigen Website war. weather2 integriert aktuelle Wetterdaten in TYPO3: Temperatur, Wetterlage, Niederschlag, Wind, Luftfeuchtigkeit und eine Mehrtagesprognose. Die Daten kommen von OpenWeatherMap oder vergleichbaren APIs und werden im konfigurierbaren Intervall aktualisiert. Für Tourismus-Websites, Outdoor-Event-Portale und regionale Nachrichtenportale ist das eine Standardfunktion, die Besucher erwarten.

## Typische Einsatzszenarien umfassen Destinations-Portale, Campingplätze und Skigebiete

Das häufigste Szenario ist das Tourismus-Portal einer Region. Der Tourismusverband einer Bodensee-Gemeinde zeigt auf seiner Startseite das aktuelle Wetter: 22 Grad, sonnig, Wassertemperatur 19 Grad. Daneben eine 5-Tage-Vorhersage. Besucher, die einen Tagesausflug planen, bekommen sofort die relevante Information und bleiben auf der Seite, um Aktivitäten zu buchen. Die Wassertemperatur kommt über einen separaten API-Endpunkt oder wird manuell gepflegt.

Ein zweites Szenario sind Campingplätze und Ferienparks. Ein Campingplatz im Schwarzwald zeigt auf seiner Buchungsseite das Wetter der nächsten Woche. Besucher, die zwischen zwei Reisewochen schwanken, können die Vorhersage als Entscheidungshilfe nutzen. Für den Campingplatz-Betreiber ist das ein Conversion-Argument: "Die Sonne scheint, buchen Sie jetzt."

Drittes Szenario: Skigebiete und Outdoor-Events. Ein Skigebiet zeigt Temperatur am Berg und im Tal, Schneehöhe (aus einer separaten Datenquelle) und Windgeschwindigkeit. Ein Outdoor-Festival zeigt die Wettervorhersage für das Festival-Wochenende. In beiden Fällen liefert die Wetter-Anzeige einen konkreten Mehrwert, der Besucher auf der Website hält.

## Technische Architektur ruft Wetterdaten per API ab und cached sie lokal

weather2 kommuniziert mit der OpenWeatherMap-API (oder alternativ mit API-Anbietern wie WeatherAPI, Visual Crossing, Meteostat). Die Konfiguration im TYPO3-Backend definiert: API-Key, Standort (Koordinaten oder Ortsname), Einheiten (metrisch/imperial), Sprache und Update-Intervall. Der Standard-Intervall ist 30 Minuten, das heisst alle 30 Minuten wird ein API-Request an OpenWeatherMap gesendet und die Antwort in der TYPO3-Datenbank gecached.

Das Frontend-Plugin rendert die Wetterdaten über Fluid-Templates: aktuelle Temperatur, Wetter-Icon (Sonne, Wolken, Regen), Textbeschreibung, Wind, Luftfeuchtigkeit. Die Mehrtagesprognose zeigt Tagesminimum und -maximum für drei bis sieben Tage. Icons werden als SVG ausgeliefert, nicht als externe Bild-URLs, damit keine zusätzlichen Requests an Dritt-Server gehen.

Für den API-Key bietet OpenWeatherMap einen kostenlosen Plan mit 1.000 Calls pro Tag, was bei einem 30-Minuten-Intervall (48 Calls pro Tag) mehr als ausreicht. Für Websites mit mehreren Standorten (z.B. ein Tourismusverband mit 10 Orten) werden 480 Calls pro Tag benötigt, was immer noch im Free-Tier liegt. Pro-Pläne (ab 40 Dollar/Monat) bieten stündliche Updates und erweiterte Daten wie UV-Index und Pollenflug.

## Häufige Probleme betreffen API-Limits, Caching und veraltete Daten

Das häufigste Problem ist die Überschreitung des API-Limits. Wenn das TYPO3-Caching nicht korrekt konfiguriert ist und jeder Seiten-Request einen API-Call auslöst, ist das Free-Tier-Limit von 1.000 Calls nach wenigen Stunden erreicht. Die Extension zeigt dann keine Daten mehr oder einen Fehler. Die Lösung: Sicherstellen, dass die Wetterdaten im TYPO3-Cache gespeichert und nicht bei jedem Frontend-Request neu abgerufen werden. Das Caching muss unabhängig vom Seiten-Cache funktionieren (Scheduler-Task oder eigener Cache-Eintrag).

Zweites Problem: Veraltete Wetterdaten. Wenn der Scheduler-Task nicht läuft (Cronjob deaktiviert, Server-Migration), zeigt die Website Tage oder Wochen alte Wetterdaten. Das ist schlimmer als keine Anzeige. Die Lösung: Im Fluid-Template ein Fallback einbauen, das prüft, ob die gecachten Daten älter als zwei Stunden sind, und bei veralteten Daten das Widget ausblendet statt falsche Daten anzuzeigen.

Drittes Thema: Datenschutz. Wenn die Wetterdaten per JavaScript direkt vom Client an die API abgerufen werden, überträgt der Browser die IP des Besuchers an den API-Anbieter. Das ist eine Drittanbieter-Datenübertragung, die DSGVO-relevant ist. Die serverseitige Lösung (TYPO3-Server ruft die API ab, nicht der Browser) vermeidet dieses Problem.

## TYPO3 v12 wird unterstützt, die API-Integration bleibt versionsunabhängig stabil

weather2 nutzt die TYPO3-HTTP-Client-Library für API-Requests und Fluid-Templates für das Rendering. Beides ist im TYPO3-Core stabil. Unter v12 läuft die Extension ohne Probleme. Für v13 sind minimale Anpassungen nötig (Scheduler-Task-Registrierung, Plugin-Konfiguration). Da die Kernlogik (HTTP-Request, JSON-Parsing, Datenbank-Speicherung) standardisiert ist, bleibt die Extension bei TYPO3-Upgrades wartungsarm. Gosign konfiguriert Wetter-Widgets als Teil von Tourismus-Website-Projekten und stellt sicher, dass API-Caching, Fallback und Datenschutz korrekt implementiert sind.

--- web2pdf TYPO3 - Seiten als PDF | Gosign ---
> web2pdf: TYPO3-Seiten als PDF exportieren. Setup, Performance & moderne Alternativen (Puppeteer). KI-beschleunigt.

## Warum web2pdf für TYPO3-Websites mit Preislisten und Produktseiten unverzichtbar ist

Vertriebsteams brauchen druckbare PDFs. Kunden erwarten auf Produktseiten einen "Als PDF speichern"-Button. Und Einkäufer in der Industrie laden Preislisten herunter, um sie intern weiterzuleiten. web2pdf löst genau dieses Problem: Die Extension rendert beliebige TYPO3-Seiten als PDF - mit korrektem Layout, eingebetteten Bildern und sauberer Typografie. Statt jede Seite manuell als PDF zu erstellen und bei Änderungen zu aktualisieren, generiert web2pdf das PDF live aus dem aktuellen Seiteninhalt.

Das spart nicht nur Redaktionszeit, sondern verhindert auch veraltete PDF-Versionen. Wenn der Preis eines Produkts im CMS geändert wird, liefert web2pdf beim nächsten Download automatisch die aktuelle Version.

## Typische Einsatzszenarien

**Produktkataloge und Preislisten im B2B.** Ein Maschinenbauunternehmen pflegt 200 Produktseiten in TYPO3. Der Aussendienst braucht zu jedem Produkt ein druckbares Datenblatt. web2pdf generiert aus jeder Produktseite ein PDF mit Logo, technischen Daten und Kontaktinformationen im Corporate Design. Der Redakteur pflegt nur eine Quelle - die Webseite - und das PDF aktualisiert sich automatisch.

**Artikel und Whitepaper als Download.** Medienunternehmen und Fachverlage bieten Magazin-Artikel als PDF-Download an. web2pdf wandelt den Artikel inklusive Bilder und Formatierung in ein druckoptimiertes PDF um. Ein Print-CSS steuert dabei, welche Elemente im PDF erscheinen (Content) und welche nicht (Navigation, Footer, Cookie-Banner).

**Angebote und Konfigurationen.** Konfigurator-Ergebnisse, Angebotszusammenfassungen oder Warenkorb-Übersichten lassen sich über web2pdf als PDF exportieren. Der Nutzer klickt auf "Angebot als PDF" und erhält ein druckreifes Dokument mit allen gewählten Optionen. Ein Automobilkonfigurator, der die gewählte Ausstattung als PDF ausgibt, ein Versicherungsrechner, der das Angebot zum Download bereitstellt - die Einsatzfelder sind breit und der Nutzen für den Vertrieb unmittelbar messbar.

## Technische Architektur

web2pdf funktioniert als TYPO3-Extension mit einem Frontend-Plugin, das auf jeder Seite einen PDF-Download-Button einblendet. Beim Klick ruft die Extension intern die aktuelle Seite auf und übergibt den HTML-Output an ein PDF-Rendering-Backend.

Die Extension unterstützt zwei Rendering-Engines:

- **wkhtmltopdf**: Die klassische Lösung, basierend auf einer älteren WebKit-Version. Vorteile: Einfache Installation als einzelne Binary, geringer Ressourcenverbrauch. Nachteile: CSS Flexbox und Grid werden nicht unterstützt, Webfonts funktionieren nur eingeschränkt, das Projekt wird seit 2022 nicht mehr aktiv gepflegt.
- **Puppeteer/Chromium**: Die moderne Alternative. Puppeteer steuert einen headless Chromium-Browser, der die Seite wie ein normaler Browser rendert und als PDF exportiert. Volle CSS-Unterstützung (Flexbox, Grid, Custom Properties), korrekte Webfont-Einbettung, JavaScript-Ausführung. Nachteil: Höherer Ressourcenverbrauch (Chromium benötigt ca. 100-200 MB RAM pro Rendering-Prozess).

Die Extension selbst konfiguriert sich über TypoScript und Extension-Einstellungen im TYPO3 Install Tool. Wichtige Parameter: PDF-Seitengrösse (A4, Letter, Custom), Ränder, Header/Footer-Templates, Cookie-Handling für authentifizierte Inhalte.

Ein separates Print-CSS (`@media print`) steuert, welche Elemente im PDF sichtbar sind. Gosign empfiehlt, Navigation, Footer, Cookie-Banner und interaktive Elemente im Print-CSS auszublenden und stattdessen Logo, Kontaktdaten und eine URL-Angabe einzufügen. Ein gut konfiguriertes Print-CSS macht den Unterschied zwischen einem professionellen Datenblatt und einem Screenshot der Webseite. Typische Anpassungen: Schriftgrösse auf 11pt für Leserlichkeit im Druck, Seitenumbrüche vor H2-Überschriften, QR-Code mit der Quell-URL in der Fusszeile.

## Häufige Probleme und Lösungen

**Problem: PDF zeigt falsches Layout, fehlende Bilder oder Schriften.** Häufigste Ursache: wkhtmltopdf kann modernes CSS nicht rendern. Websites, die Flexbox oder CSS Grid verwenden, sehen im PDF komplett anders aus als im Browser. Die Lösung: Auf Puppeteer als Rendering-Engine wechseln. Alternativ ein separates Print-CSS erstellen, das Layout-Fallbacks für ältere Rendering-Engines enthält.

**Problem: PDF-Generierung dauert 10+ Sekunden.** Puppeteer startet für jedes PDF einen Chromium-Prozess. Bei gleichzeitigen Anfragen multipliziert sich die Serverlast. Die Lösung: PDF-Caching implementieren. Das generierte PDF wird für eine definierte Zeit (z.B. 60 Minuten) im Dateisystem gecacht. Erst wenn sich der Seiteninhalt ändert, wird das PDF neu generiert. Auf Servern mit wenig RAM (unter 2 GB) ist wkhtmltopdf trotz CSS-Einschränkungen die pragmatischere Wahl.

**Problem: Authentifizierte Seiten liefern leeres PDF.** web2pdf ruft die Seite intern per HTTP auf. Wenn die Seite hinter einem Login liegt, fehlen die Session-Cookies, und der Rendering-Prozess sieht nur die Login-Seite. Die Lösung: Einen speziellen PDF-Rendering-Endpoint konfigurieren, der die Authentifizierung über einen Token statt über Session-Cookies löst.

## Migration und Versions-Kompatibilität

web2pdf ist für TYPO3 v10 und v11 stabil verfügbar. Für TYPO3 v12 LTS existieren Community-Forks, die die Kompatibilität herstellen. Das ursprüngliche Paket wird nicht mehr aktiv gepflegt.

Für TYPO3 v13 und darüber hinaus empfiehlt Gosign einen architekturellen Wechsel: Statt web2pdf als TYPO3-Extension zu betreiben, wird die PDF-Generierung als separater Microservice implementiert. Ein Node.js-Service mit Puppeteer nimmt URLs entgegen und liefert PDFs zurück. Das entkoppelt die PDF-Generierung vom TYPO3-Server, reduziert die Serverlast und macht die Lösung TYPO3-versionsunabhängig.

Der Migrationsaufwand von web2pdf auf eine Puppeteer-basierte Lösung beträgt typischerweise 2 bis 4 Tage. Die bestehenden Print-CSS-Dateien können 1:1 übernommen werden. Nur der Aufruf-Mechanismus (Button-Klick, URL-Handling) muss angepasst werden.

Ein häufig unterschätzter Aspekt bei der PDF-Generierung: Barrierefreiheit. PDFs, die aus HTML generiert werden, sind nicht automatisch barrierefrei. Für Unternehmen, die dem Barrierefreiheitsstärkungsgesetz (BFSG, ab Juni 2025) unterliegen, müssen die generierten PDFs Tagged PDF-Strukturen enthalten. Weder wkhtmltopdf noch Puppeteer erzeugen standardmässig barrierefreie PDFs. Gosign empfiehlt für diesen Anwendungsfall eine nachgelagerte Verarbeitung mit einer spezialisierten PDF-Library (z.B. TCPDF oder mPDF mit Tag-Support), die die HTML-Semantik in PDF-Tags überträgt.

--- Webflow zu TYPO3 - Migration | Gosign ---
> Migration von Webflow-Websites auf TYPO3: Mehr Kontrolle, keine Plattform-Abhängigkeit, Enterprise-Features. Gosign konvertiert Webflow-HTML/CSS.

## Webflow-Websites stossen bei Enterprise-Anforderungen an harte Grenzen

Webflow ist hervorragend für Prototypen, Landingpages und Startups mit drei bis fünf Mitarbeitenden. Aber ab einem gewissen Punkt wird die Plattform zum Problem: keine Multi-Language-Unterstützung auf Enterprise-Niveau, kein feingranulares Rechtemanagement, keine Custom-Backend-Workflows, keine On-Premise-Option, und Hosting ausschliesslich auf Webflow-Servern in den USA. Für Unternehmen, die in der EU gehostet werden müssen (DSGVO, Schrems II), mehrere hundert Seiten verwalten und ein CMS mit Redakteurs-Workflows brauchen, ist TYPO3 die logische Weiterentwicklung. Gosign migriert Webflow-Websites auf TYPO3: Das bestehende Design (HTML/CSS) wird in Fluid Templates konvertiert, der Content wird strukturiert übernommen, und die Funktionalität wird durch TYPO3-Extensions ergänzt.

## Typische Einsatzszenarien betreffen wachsende Unternehmen, regulierte Branchen und internationale Rollouts

Das häufigste Szenario ist das schnell gewachsene Startup, das seine Webflow-Seite nicht mehr skaliert bekommt. Mit 20 Mitarbeitenden und einer Website in einer Sprache funktioniert Webflow. Mit 200 Mitarbeitenden, fünf Sprachen und einem Blog mit 500 Artikeln nicht mehr. Die Webflow-Preisstruktur skaliert nicht: CMS-Pläne sind auf 10.000 Items begrenzt, Custom Code ist limitiert, API-Zugriffe gedrosselt. Der Wechsel auf TYPO3 gibt dem Unternehmen volle Kontrolle über Hosting, Performance und Erweiterbarkeit.

Ein zweites Szenario sind regulierte Branchen. Ein Finanzdienstleister hat seine Marketing-Website auf Webflow aufgebaut, aber die Compliance-Abteilung verlangt EU-Hosting, Audit-Logs für Content-Änderungen und ein Freigabe-Workflow, bei dem vier Augen jeden Seiteninhalt genehmigen. Webflow bietet keinen dieser Punkte nativ. TYPO3 schon: Workspaces für Staging und Freigabe, ext:belog für Audit-Logs, und Hosting auf einem Server in Frankfurt.

Drittes Szenario: Internationaler Rollout. Ein Industrieunternehmen hat seine Hauptseite auf Webflow in Englisch. Jetzt sollen Landeswebsites in 12 Sprachen entstehen. Webflow Localization ist teuer und limitiert. TYPO3 bietet native Multi-Site- und Multi-Language-Unterstützung, bei der jede Sprache eine eigene Seitenstruktur haben kann, inklusive lokaler Inhalte, die nicht in allen Sprachen existieren.

## Technische Architektur konvertiert Webflow-Export in TYPO3-Fluid-Templates

Die Migration folgt einem definierten Prozess: Export des Webflow-Projekts als HTML/CSS/JS, Analyse der Seitenstruktur und der eingesetzten Interaktionen, Konvertierung des HTML in Fluid-Templates, Import der Inhalte in TYPO3-Content-Elemente. Der Webflow-Export liefert sauberes, semantisches HTML, das sich gut in Fluid übersetzen lässt. CSS wird als Sass/SCSS-Datei übernommen oder in Tailwind-Utility-Klassen umgeschrieben, je nach TYPO3-Setup.

Webflow-Interaktionen (Scroll-Animationen, Hover-Effekte, Modals) basieren auf einer proprietären JavaScript-Engine. Diese 1:1 zu übernehmen ist nicht möglich. Stattdessen werden die Interaktionen mit nativem CSS (transitions, animations) oder leichtgewichtigem JavaScript (IntersectionObserver, Dialog-Element) nachgebaut. In den meisten Fällen reduziert das die JavaScript-Dateigrösse von 200-300 KB (Webflow Runtime) auf unter 20 KB.

Der Content-Import läuft über die Webflow-API oder den HTML-Export. Jede Webflow Collection wird auf ein TYPO3-Content-Element oder einen Extbase-Record gemappt. Blog-Artikel werden in tx_news importiert, Team-Mitglieder in Custom Records, Testimonials in die bestehende TYPO3-Datenstruktur.

## Häufige Probleme betreffen Webflow-spezifische Features und URL-Redirects

Das grösste Problem bei der Migration sind Webflow-Features ohne TYPO3-Äquivalent. Webflow Forms laufen über einen integrierten Form-Handler. In TYPO3 muss ein Formular-System (powermail, Form Framework) konfiguriert werden. Webflow E-Commerce läuft auf der Plattform. In TYPO3 muss ein Shopsystem (TYPO3-native oder Shopware/Magento-Integration) eingerichtet werden. Diese Funktionslücken müssen vor der Migration identifiziert und im TYPO3-Projekt geplant werden.

Zweites Problem: URL-Redirects. Webflow-URLs folgen einem eigenen Schema. Nach der Migration müssen alle alten URLs auf die neuen TYPO3-URLs umgeleitet werden, damit Google die Seiten nicht als 404 indexiert und bestehende Backlinks erhalten bleiben. Bei 200 Seiten sind das 200 Redirects, die in der TYPO3-Redirect-Tabelle oder per .htaccess konfiguriert werden.

Drittes Thema: Design-Differenzen. Webflow rendert CSS-Layouts mit einer eigenen Engine, die von Browser-Standardverhalten abweichen kann. Ein Layout, das in Webflow pixel-perfekt aussieht, kann in TYPO3 minimal anders rendern, weil der CSS-Reset oder die Schriftart-Einbindung abweicht. Ein visueller QA-Pass nach der Migration ist deshalb Pflicht.

## Die Migration ist kein Upgrade, sondern ein Plattformwechsel

Es gibt keinen automatisierten Migrationspfad von Webflow zu TYPO3. Jede Migration ist ein Projekt mit Analyse, Konvertierung, Import und QA. Die Dauer hängt von der Komplexität ab: Eine einfache Website mit 20 Seiten und einem Blog ist in zwei bis drei Wochen migriert. Eine komplexe Website mit 500 Seiten, E-Commerce und fünf Sprachen braucht zwei bis drei Monate. Gosign hat Webflow-Migrationen für Unternehmen von 50 bis 2.000 Seiten durchgeführt und setzt dabei auf KI-gestützte Template-Konvertierung, die den Fluid-Code aus dem Webflow-HTML generiert und die manuelle Anpassung auf ein Minimum reduziert.

--- WebP TYPO3 - Bildoptimierung | Gosign ---
> Automatische Konvertierung von JPG/PNG zu WebP. 25–35% kleinere Bilddateien, schnellere Ladezeiten. Gosign konfiguriert auch AVIF-Support für noch.

## Bilder machen 50 bis 70 Prozent des Seitengewichts aus, und WebP reduziert sie um ein Drittel

Die durchschnittliche TYPO3-Website lädt pro Seite 2 bis 5 MB an Bilddaten. Das ist der grösste einzelne Faktor für die Ladezeit und damit für den Google PageSpeed Score. WebP ist ein von Google entwickeltes Bildformat, das bei vergleichbarer Qualität 25 bis 35 Prozent kleiner ist als JPEG und bis zu 80 Prozent kleiner als PNG. Die TYPO3 WebP-Extension konvertiert vorhandene JPG- und PNG-Bilder automatisch in WebP, ohne dass Redakteure ihr Verhalten ändern müssen. Bilder werden wie gewohnt im FAL-Backend hochgeladen, die Extension erzeugt die WebP-Variante im Hintergrund und liefert sie an Browser aus, die das Format unterstützen. Alle modernen Browser unterstützen WebP seit 2020: Chrome, Firefox, Safari, Edge.

Für Websites, die bereits PageSpeed-optimiert sind, ist die WebP-Konvertierung oft der letzte Schritt, der den Score von 85 auf 95 oder höher hebt.

## Typische Einsatzszenarien betreffen bildlastige Websites, E-Commerce und Mobile-First-Projekte

Das häufigste Szenario sind bildlastige Unternehmenswebsites. Ein Immobilienportal zeigt pro Objekt 15 bis 25 Fotos. Bei 500 Objekten sind das 10.000 Bilder. Ohne WebP wiegen die Bilder im Schnitt 250 KB (JPEG), mit WebP 170 KB. Auf einer Listenansicht mit 20 Objekten und je einem Titelbild spart WebP 1,6 MB pro Seitenaufruf. Bei 50.000 Seitenaufrufen pro Monat sind das 80 GB weniger Traffic, was sich direkt auf die Hosting-Kosten auswirkt.

Ein zweites Szenario sind E-Commerce-Integrationen. Ein Shopsystem zeigt Produktbilder in verschiedenen Grössen: Thumbnail, Listenansicht, Detailansicht, Zoom. Jede Grösse wird als WebP-Variante generiert. Bei einem Shop mit 2.000 Produkten und je fünf Bildvarianten entstehen 10.000 WebP-Dateien, die den Seitenaufbau in der Listenansicht messbar beschleunigen.

Drittes Szenario: Mobile-First-Websites für Zielgruppen mit schlechter Netzanbindung. Ein NGO-Portal, das in Regionen mit 3G-Netzen genutzt wird, profitiert überproportional von kleineren Bilddateien. Der Unterschied zwischen 5 Sekunden und 15 Sekunden Ladezeit entscheidet, ob der Besucher die Seite sieht oder abbricht.

## Technische Architektur konvertiert Bilder im TYPO3-Processing-Pipeline

Die Extension klinkt sich in die TYPO3-Bild-Processing-Pipeline ein. Wenn TYPO3 ein Bild verarbeitet (Resize, Crop), erzeugt die Extension zusätzlich eine WebP-Variante im selben Verzeichnis. Die Auslieferung erfolgt über Content Negotiation: Der Server prüft den Accept-Header des Browsers. Wenn der Browser "image/webp" akzeptiert, liefert er die WebP-Datei. Andernfalls das Original-JPEG/PNG.

Technisch gibt es zwei Implementierungsvarianten: Die erste nutzt mod_rewrite-Regeln im Apache oder nginx, die Bild-Requests auf die WebP-Variante umleiten, wenn sie existiert. Die zweite nutzt ein TYPO3-Middleware, das den Response-Header manipuliert. Die mod_rewrite-Variante ist performanter, weil sie vor PHP ausgeführt wird.

Die Konvertierung selbst läuft über libwebp (Kommandozeilen-Tool cwebp), ImageMagick mit WebP-Support oder die PHP-Extension GD (wenn mit WebP-Support kompiliert). Die Qualität ist konfigurierbar: Standard 80 (von 100), was einen guten Kompromiss zwischen Dateigrösse und visueller Qualität bietet. Für fotografische Inhalte empfehlen wir 82 bis 85, für Screenshots und Illustrationen 75 bis 78.

Für noch bessere Kompression unterstützen neuere Versionen der Extension das AVIF-Format, das weitere 20 bis 30 Prozent Einsparung gegenüber WebP bietet. AVIF-Support ist in Chrome und Firefox verfügbar, Safari seit Version 16.

## Häufige Probleme betreffen fehlende Server-Libraries und CDN-Konfiguration

Das häufigste Problem ist die fehlende cwebp-Binary auf dem Server. Shared-Hosting-Umgebungen haben oft kein libwebp installiert, und der Hoster erlaubt keine Installation von Binaries. Die Lösung: PHP GD mit WebP-Support nutzen (in den meisten PHP-Versionen ab 7.1 verfügbar) oder einen Hosting-Provider wählen, der cwebp bereitstellt. Auf Managed-Servern und in Docker-Containern ist die Installation trivial: apt-get install webp.

Zweites Problem: CDN-Konfiguration. Wenn ein CDN (Cloudflare, Fastly, AWS CloudFront) vor der Website liegt, muss es WebP korrekt handhaben. Zwei Ansätze: Das CDN kennt Content Negotiation und cached WebP und JPEG als separate Varianten (Vary: Accept). Oder die TYPO3-Website liefert direkt WebP-URLs aus (ohne Content Negotiation), und das CDN cached nur eine Version. Cloudflare bietet automatische WebP-Konvertierung über Polish, was die TYPO3-Extension teilweise überflüssig macht.

Drittes Thema: Qualitätskontrolle. Bei zu niedriger Qualitätseinstellung (unter 70) werden Artefakte sichtbar, besonders bei Farbverläufen und feinen Texturen. Ein A/B-Vergleich (Original vs. WebP) sollte nach der Konfiguration durchgeführt werden, um sicherzustellen, dass die Qualität für den Anwendungsfall akzeptabel ist.

## TYPO3 v12 und v13 werden unterstützt, die Extension ist eine der stabilsten im Ökosystem

Die WebP-Extension gehört zu den am häufigsten installierten Performance-Extensions im TYPO3-Ökosystem. Sie wird aktiv gepflegt und ist mit TYPO3 v12 und v13 kompatibel. Da die Kernfunktionalität (Bild-Processing-Hook, Datei-Konvertierung) auf stabilen TYPO3-APIs basiert, sind Breaking Changes bei Upgrades selten. Gosign konfiguriert WebP als Standard in jedem neuen TYPO3-Projekt und aktiviert bei Verfügbarkeit zusätzlich AVIF für maximale Kompression.

--- Bootstrap TYPO3 - T3Bootstrap | Gosign ---
> Bootstrap Framework als TYPO3-Sitepackage. Responsive Templates, Grid-System, Bootstrap-Komponenten als Content-Elemente.

## Bootstrap-basierte TYPO3-Projekte brauchen ein Sitepackage, das die Brücke zwischen Framework und CMS schlägt

Bootstrap ist das meistgenutzte CSS-Framework der Welt. Über 25 Prozent aller Websites setzen Bootstrap ein. Für TYPO3-Projekte bedeutet das: Designer liefern Entwürfe in Bootstrap, Entwickler kennen die Klassen und Komponenten, und Kunden erwarten responsive Layouts, die auf Bootstrap aufbauen. ws_t3bootstrap bringt Bootstrap als Sitepackage direkt in TYPO3: Responsive Templates, das Grid-System, Bootstrap-Komponenten (Accordion, Cards, Carousel, Tabs, Alerts) als Content-Elemente und eine vorkonfigurierte TypoScript-Basis. Statt Bootstrap manuell in ein leeres TYPO3-Projekt zu integrieren, liefert ws_t3bootstrap einen funktionsfähigen Startpunkt, der sofort produktionsfähig ist.

## Typische Einsatzszenarien sind Unternehmenswebsites, Portale und Rapid-Prototyping

Das häufigste Szenario ist die mittelständische Unternehmenswebsite. Ein Unternehmen mit 50 bis 500 Mitarbeitenden braucht eine Website mit 30 bis 80 Seiten: Startseite, Über uns, Leistungen, Referenzen, Karriere, Kontakt. Der Designer erstellt ein Mockup auf Basis von Bootstrap 5. ws_t3bootstrap liefert die Templates, das Grid-System und die Content-Elemente, sodass der Entwickler nur das Custom CSS (Farben, Schriften, Abstände) und projektspezifische Komponenten ergänzen muss. Typische Entwicklungszeit: zwei bis drei Wochen vom Mockup zur fertigen Website, statt vier bis sechs Wochen bei einem Custom-Setup.

Ein zweites Szenario sind Intranet-Portale. Ein Unternehmen betreibt ein TYPO3-Intranet für 2.000 Mitarbeitende. Das Design muss nicht einzigartig sein, aber konsistent und responsive. ws_t3bootstrap liefert ein professionelles Standard-Layout, das ohne grossen Design-Aufwand eingesetzt werden kann. Content-Elemente wie Akkordeons für FAQs, Tabs für Abteilungsinformationen und Cards für News-Teaser sind sofort verfügbar.

Drittes Szenario: Rapid Prototyping. Eine Agentur baut in zwei Tagen einen funktionierenden Website-Prototyp, den der Kunde freigeben kann. ws_t3bootstrap reduziert die Setup-Zeit auf Stunden statt Tage, weil die Grundstruktur (Header, Footer, Navigation, Grid) bereits steht.

## Technische Architektur registriert Bootstrap-Komponenten als TYPO3 Content Elements

ws_t3bootstrap installiert sich als TYPO3-Sitepackage und konfiguriert: TypoScript-Setup mit Bootstrap-CSS/JS-Includes, Fluid-Templates für Header, Footer und Seitenlayouts, Backend-Layouts (1-Spalter, 2-Spalter, 3-Spalter mit Sidebar) und Content-Elemente, die Bootstrap-Komponenten abbilden.

Die Content-Elemente werden über TCA-Konfigurationen und Fluid-Templates definiert. Ein Accordion-Element erstellt beispielsweise ein Bootstrap-Accordion mit n Panels, jedes Panel mit Titel und Body-Text. Ein Card-Element erzeugt eine Bootstrap-Card mit Bild, Titel, Text und Link. Ein Grid-Element ermöglicht verschachtelte Spalten-Layouts innerhalb einer Seite.

Das Bootstrap-CSS wird entweder als kompilierte CSS-Datei eingebunden (schnell, keine Build-Tools nötig) oder als Sass-Quellcode, der über ein Build-System (Webpack, Vite) kompiliert wird. Die Sass-Variante erlaubt, Bootstrap-Variablen (Farben, Breakpoints, Schriftgrössen) zu überschreiben und nur die benötigten Bootstrap-Module einzubinden, was die CSS-Dateigrösse von 230 KB auf 80 bis 120 KB reduziert.

Die JavaScript-Komponenten (Accordion, Collapse, Dropdown, Modal, Tab, Toast) werden über Bootstrap 5 eingebunden, das ohne jQuery auskommt. Das reduziert die JavaScript-Dateigrösse gegenüber Bootstrap 4 um rund 85 KB (jQuery-Wegfall).

## Häufige Probleme betreffen Bootstrap-Versions-Konflikte und CSS-Spezifitäts-Kämpfe

Das grösste Problem bei Bootstrap-Sitepackages ist der Versions-Konflikt. Wenn ws_t3bootstrap Bootstrap 5.2 einbindet, aber eine andere Extension (z.B. ein Slider-Plugin) Bootstrap 4.6 oder 3.x mitbringt, kollidieren die CSS-Klassen. Bootstrap 4 nutzt "col-md-4", Bootstrap 5 ebenfalls, aber mit unterschiedlichem Verhalten bei bestimmten Utilities. Die Lösung: Alle Extensions auf dieselbe Bootstrap-Version vereinheitlichen oder Extension-eigenes Bootstrap per CSS-Scoping isolieren.

Zweites Problem: CSS-Spezifität. Wenn Custom CSS die Bootstrap-Klassen überschreiben muss, entsteht ein Spezifitäts-Wettlauf: !important-Deklarationen häufen sich, weil Bootstrap-Utilities hohe Spezifität haben. Die Lösung: Bootstrap-Variablen statt CSS-Overrides nutzen und das Custom-Stylesheet nach dem Bootstrap-CSS laden.

Drittes Thema: Performance. Bootstrap als Framework lädt alle Komponenten, auch wenn die Website nur fünf davon nutzt. Bei einer Website, die nur Grid, Cards und Navbar braucht, werden 80 Prozent des Bootstrap-CSS nie genutzt. PurgeCSS oder ein selektiver Sass-Import reduziert die CSS-Dateigrösse auf das Nötige.

## TYPO3 v12 und v13 werden unterstützt, Bootstrap 5 ist der aktuelle Standard

ws_t3bootstrap wird aktiv gepflegt und unterstützt TYPO3 v12 und v13. Die aktuelle Version basiert auf Bootstrap 5.3. Beim Upgrade von Bootstrap 4 auf 5 sind Breaking Changes zu beachten: jQuery-Abhängigkeit entfällt, einige CSS-Klassen wurden umbenannt (z.B. ml-/mr- zu ms-/me-), und die JavaScript-API hat sich geändert. Gosign führt Bootstrap-Upgrades zusammen mit TYPO3-Upgrades durch und prüft dabei alle Content-Elemente auf korrekte Darstellung. Bei neuen Projekten empfehlen wir ws_t3bootstrap als Startpunkt und ergänzen das Sitepackage um projektspezifische Komponenten, statt Bootstrap von Grund auf in TYPO3 zu integrieren.

--- wwt3_encryption TYPO3 - E-Mail-Schutz | Gosign ---
> TYPO3 Extension für automatische E-Mail-Verschlüsselung auf der Website. Schützt E-Mail-Adressen gegen Harvester und Spam-Bots durch JavaScript-.

## Warum E-Mail-Verschleierung nach wie vor Pflicht für jede öffentliche Website ist

Jede Firmen-Website, jede Hochschul-Seite und jeder Behörden-Auftritt veröffentlicht E-Mail-Adressen: Ansprechpartner im Impressum, Kontaktpersonen in Teams, Presse-Kontakte in Newsrooms, Rechtsabteilung in Datenschutzhinweisen. Ohne Schutz sammeln Harvester-Bots diese Adressen innerhalb weniger Tage nach der Veröffentlichung und verkaufen sie an Spam-Versender. wwt3_encryption ist eine klassische TYPO3-Extension für dieses Problem und verschlüsselt E-Mail-Adressen serverseitig, sodass Bots beim HTML-Parsing nur unbrauchbaren Code sehen, während echte Nutzer auf die korrekte Adresse klicken können. Die Extension richtet sich an Betreiber, die aus rechtlichen Gründen Kontaktdaten prominent zeigen müssen, aber nicht bereit sind, die resultierende Spam-Flut in Kauf zu nehmen.

## Typische Einsatzszenarien

Eine Anwaltskanzlei mit 60 Partnern und Associates veröffentlicht alle Anwalts-Profile inklusive direkter E-Mail-Adressen, weil die Berufsordnung eine erreichbare Kontaktangabe fordert. Ohne Verschleierung erhalten alle 60 Adressen binnen Wochen Phishing-Mails, Werbung und zum Teil gezielte Angriffe. wwt3_encryption rendert die Adressen so, dass der Quelltext keinen lesbaren @-String enthält, während der Browser beim Nutzer die korrekte mailto-Link-Adresse anzeigt.

Ein zweites Szenario ist eine Hochschule, die Fachbereichs-Seiten mit Lehrstuhl-Kontakten pflegt. Jeder Lehrstuhl hat eine Webseite mit Telefon- und E-Mail-Angaben, die über das TYPO3-Content-Management redaktionell gepflegt werden. Redakteure tragen die Adressen als normalen Text in RichText-Elementen oder Kontaktfelder ein, ohne sich um Verschleierung kümmern zu müssen. wwt3_encryption greift automatisch in den Rendering-Prozess ein und schützt alle mailto-Links ohne redaktionelle Mehrarbeit.

Der dritte Fall sind öffentliche Verwaltungen mit Impressum, Kontaktformularen und Fachabteilungs-Listen. Hier ist die Anforderung oft noch strenger, weil ein Barrierefreiheits-Anspruch besteht: Die geschützte Adresse muss von Screenreadern korrekt vorgelesen werden, und ein Klick muss den Mail-Client öffnen, genau wie bei einer unverschleierten Adresse. Eine Kombination aus JavaScript-Dekodierung und semantisch sauberen href-Attributen ist der einzige Weg, beides zu erfüllen.

## Technische Architektur: Content-Post-Processing im TYPO3-Rendering

wwt3_encryption klinkt sich in den Rendering-Prozess von TYPO3 ein, typischerweise über einen Content-Post-Processor-Hook oder ein TypoScript-Userfunc. Nach dem Zusammenbau des HTML-Outputs durch den Page-Renderer durchläuft die Extension das fertige Markup, findet alle mailto-Links und alle einfachen E-Mail-Adressen im Fließtext per Regex und ersetzt sie durch verschleierte Varianten. Die Verschleierung kann über verschiedene Methoden laufen: ROT13-Kodierung des Link-Ziels mit JavaScript-Dekodierung, Base64-Kodierung, Zeichenweise-Fragmentierung mit CSS-Pseudo-Elementen oder eine Kombination.

Der Vorteil der Post-Processing-Variante ist, dass sie ohne Änderungen an Content-Elementen oder Templates funktioniert. Redakteure arbeiten weiter mit normalen mailto-Links im RichText, und die Extension übernimmt die Absicherung automatisch. Konfiguriert wird die Extension über TypoScript-Konstanten, die zwischen den verschiedenen Verschleierungsmethoden wählen und Ausnahmen für bestimmte Seiten- oder Content-Bereiche definieren lassen.

## Häufige Probleme und Lösungen

Das erste Problem ist Barrierefreiheit. Reine JavaScript-Lösungen scheitern bei Nutzern mit deaktiviertem JavaScript, und einige Screenreader haben Probleme mit CSS-basierter Zeichenfragmentierung. Ein pragmatischer Ansatz kombiniert eine leicht brechbare Client-Verschleierung mit einem zusätzlichen semantischen aria-label auf dem Link, sodass Screenreader die Adresse korrekt vorlesen, während Harvester an der syntaktischen Unterschiedlichkeit scheitern. Absolute Sicherheit ist mit öffentlich zugänglichen Adressen nicht erreichbar, aber schon moderate Hürden reduzieren die Spam-Last messbar.

Das zweite Problem sind Caching-Schichten. Wenn die Post-Processing-Verschleierung vor dem Page-Cache ausgeführt wird, liefert der Cache die verschleierten Daten aus und alles funktioniert. Liegt sie dagegen nach dem Cache, wird jedes gecachte Seite bei jeder Anfrage erneut durch den Post-Processor geschickt, was die Performance deutlich drückt. Die richtige Reihenfolge im TypoScript-Rendering-Chain ist daher kritisch und sollte bei jeder größeren Änderung am Caching-Verhalten überprüft werden.

Das dritte Thema betrifft dynamische Inhalte. E-Mail-Adressen, die erst per AJAX nachgeladen werden oder aus externen APIs stammen, laufen nicht durch den TYPO3-Renderer und damit auch nicht durch wwt3_encryption. Solche Stellen müssen separat geschützt werden, entweder indem die API selbst verschleierte Varianten liefert oder indem ein clientseitiges JavaScript den nachgeladenen Content nachbearbeitet.

## Migration und Versions-Kompatibilität

wwt3_encryption hat wie viele ältere TYPO3-Extensions eine uneinheitliche Versions-Geschichte: Für v9 und v10 gab es gepflegte Releases, für v11 und v12 existieren Community-Forks, deren Aktivität unterschiedlich ist. Wer auf TYPO3 v13 migriert, sollte vor dem Upgrade prüfen, ob der eigene Fork noch funktioniert oder ob ein Wechsel auf eine alternative Verschleierungsmethode notwendig wird.

Der TYPO3-Core bringt selbst eine einfache E-Mail-Verschleierung mit, die über config.spamProtectEmailAddresses im TypoScript aktiviert wird und im Kern-Renderer ROT13 anwendet. Für einfache Setups reicht diese Core-Variante und macht eine eigene Extension überflüssig. Wer stärkere oder flexiblere Verschleierung braucht, etwa mit mehreren parallelen Methoden oder Ausnahmen pro Content-Element, greift zu einer Extension wie wwt3_encryption. Gosign bewertet im Einzelfall, ob die Core-Funktion ausreicht oder eine dedizierte Extension sinnvoll ist, und unterstützt bei Bedarf auch den Umbau auf eine eigene, schlanke Post-Processing-Implementierung, die sich direkt an das jeweilige Projekt anpasst.

Die Effektivität jeder E-Mail-Verschleierung nimmt im Laufe der Zeit ab, weil Harvester-Techniken sich weiterentwickeln. ROT13 gilt heute als nahezu wirkungslos gegen spezialisierte Bots, während zeichenweise Fragmentierung mit CSS oder Unicode-Tricks noch moderate Hürden aufbaut. Die wirklich belastbare Verteidigung ist daher eine Kombination: Verschleierung im HTML-Output, ergänzt um einen guten Spam-Filter auf der Empfänger-Seite und idealerweise eine Kontakt-Option per Formular statt einer direkt veröffentlichten Adresse. Wer die rechtlichen Anforderungen erfüllen muss, wird um die Veröffentlichung nicht herumkommen, sollte aber das Kontakt-Formular als primären Weg anbieten und die Adresse nur sekundär zeigen.

Für Betreiber von TYPO3 v13 empfiehlt sich zusätzlich, die Content-Rendering-Pipeline regelmäßig gegen Breaking Changes im Core zu prüfen. Einige Hook-Punkte, die in früheren Versionen für Post-Processing verfügbar waren, wurden in v13 deprecated oder durch PSR-14-Events ersetzt. Extensions, die sich noch auf alte Hooks verlassen, laufen nach dem Upgrade zwar technisch, bearbeiten aber keine Inhalte mehr. Eine kurze Prüfung der Log-Einträge nach einem Upgrade zeigt solche stillen Ausfälle frühzeitig und verhindert, dass über Wochen unbemerkt unverschleierte Adressen ausgeliefert werden.

--- TYPO3 Extensions | Entwicklung & Monitoring ---
> 800+ TYPO3 Extensions überwacht. Entwicklung, Audit & Security-Monitoring. Alle Extensions auf einen Blick.

<!-- Was bietet Gosign? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Was bietet Gosign für TYPO3 Extensions?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Gosign überwacht über 800 TYPO3 Extensions auf Sicherheitslücken, Kompatibilität und Performance. Für jede Extension bietet Gosign: Neuentwicklung, Update &amp; Migration, Code-Audit und Wartung. Seit 25&nbsp;Jahren in der TYPO3-Entwicklung, seit 2023 mit KI-beschleunigter Entwicklung: 60 - 80&nbsp;% schneller als klassische Methoden.
</p>
</div>
</section>

<!-- Extension-Kategorien -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">Extension-Kategorien</h2>
<div class="space-y-8">

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Suche & Indexierung</h3>
<p class="text-body text-gosign-text mb-4">Apache Solr, ke_search, Faceted Search. Enterprise-Suche über tausende Dokumente und Dateien.</p>
<div class="flex flex-wrap gap-2">
<a href="/de/typo3/solrfal/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">solrfal</a>
<a href="/de/typo3/ke_search_premium/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">ke_search_premium</a>
<a href="/de/typo3/find/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">find</a>
<a href="/de/typo3/in2studyfinder/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">in2studyfinder</a>
</div>
</div>

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Sicherheit & Authentifizierung</h3>
<p class="text-body text-gosign-text mb-4">SSO, SAML, OIDC, Cookie-Consent, CAPTCHA, CORS. Enterprise-Security für TYPO3.</p>
<div class="flex flex-wrap gap-2">
<a href="/de/typo3/shibboleth_auth/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">shibboleth_auth</a>
<a href="/de/typo3/oidc/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">oidc</a>
<a href="/de/typo3/dp_cookieconsent/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">dp_cookieconsent</a>
<a href="/de/typo3/saml2/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">saml2</a>
<a href="/de/typo3/be_acl/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">be_acl</a>
</div>
</div>

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Formulare & Events</h3>
<p class="text-body text-gosign-text mb-4">Powermail, Event-Management, Buchungssysteme, Umfragen, Newsletter-Integration.</p>
<div class="flex flex-wrap gap-2">
<a href="/de/typo3/powermail/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">powermail</a>
<a href="/de/typo3/sf_event_mgt/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">sf_event_mgt</a>
<a href="/de/typo3/booking/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">booking</a>
<a href="/de/typo3/rapidmail/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">rapidmail</a>
</div>
</div>

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Content & Templates</h3>
<p class="text-body text-gosign-text mb-4">Mask, DCE, VHS ViewHelper, Bootstrap Grids. Custom Content Elements und Template-Entwicklung.</p>
<div class="flex flex-wrap gap-2">
<a href="/de/typo3/mask/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">mask</a>
<a href="/de/typo3/dce/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">dce</a>
<a href="/de/typo3/vhs/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">vhs</a>
<a href="/de/typo3/bootstrap_grids/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">bootstrap_grids</a>
</div>
</div>

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">PDF & Dokumente</h3>
<p class="text-body text-gosign-text mb-4">PDF-Generierung, PDF-Viewer, Flipbooks, Download-Management.</p>
<div class="flex flex-wrap gap-2">
<a href="/de/typo3/pdfviewhelpers/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">pdfviewhelpers</a>
<a href="/de/typo3/web2pdf/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">web2pdf</a>
<a href="/de/typo3/rflipbook/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">rflipbook</a>
<a href="/de/typo3/downloadmanager/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">downloadmanager</a>
</div>
</div>

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Medien & Bilder</h3>
<p class="text-body text-gosign-text mb-4">Bildbearbeitung, Galerien, Slider, Focuspoint, Cloudinary CDN.</p>
<div class="flex flex-wrap gap-2">
<a href="/de/typo3/focuspoint/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">focuspoint</a>
<a href="/de/typo3/imagemap/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">imagemap</a>
<a href="/de/typo3/sf_filecollection_gallery/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">sf_filecollection_gallery</a>
</div>
</div>

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Karten & Standorte</h3>
<p class="text-body text-gosign-text mb-4">Leaflet, Google Maps, OpenStreetMap. Filialfinder und Umkreissuche.</p>
<div class="flex flex-wrap gap-2">
<a href="/de/typo3/leaflet/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">leaflet</a>
<a href="/de/typo3/maps2/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">maps2</a>
<a href="/de/typo3/geocoordinates/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">geocoordinates</a>
</div>
</div>

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">E-Commerce</h3>
<p class="text-body text-gosign-text mb-4">aimeos, Payment-Integration, Paywall, Preisrechner.</p>
<div class="flex flex-wrap gap-2">
<a href="/de/typo3/aimeos/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">aimeos</a>
<a href="/de/typo3/amazon_payment/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">amazon_payment</a>
<a href="/de/typo3/paywall/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">paywall</a>
</div>
</div>

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Performance & SEO</h3>
<p class="text-body text-gosign-text mb-4">Cache Warmup, staticfilecache, WebP-Konvertierung, Canonical-Management.</p>
<div class="flex flex-wrap gap-2">
<a href="/de/typo3/warmup/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">warmup</a>
<a href="/de/typo3/webp/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">webp</a>
<a href="/de/typo3/newscanonical/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">newscanonical</a>
<a href="/de/typo3/cache_hash/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">cache_hash</a>
</div>
</div>

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">DevTools & Deployment</h3>
<p class="text-body text-gosign-text mb-4">Extension Builder, in2publish, Styleguide, Deployer.</p>
<div class="flex flex-wrap gap-2">
<a href="/de/typo3/extension_builder/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">extension_builder</a>
<a href="/de/typo3/in2publish/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">in2publish</a>
<a href="/de/typo3/styleguide/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">styleguide</a>
</div>
</div>

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Branchenlösungen</h3>
<p class="text-body text-gosign-text mb-4">Immobilien (OpenImmo, FlowFact), Hochschulen (in2studyfinder), Vereine (hwvereinsliste), Bildung (kuferweb).</p>
<div class="flex flex-wrap gap-2">
<a href="/de/typo3/openimmo/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">openimmo</a>
<a href="/de/typo3/flowfact/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">flowfact</a>
<a href="/de/typo3/kuferweb/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">kuferweb</a>
</div>
</div>

</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Sie suchen Support für eine TYPO3 Extension?</h3>
<p class="text-body text-gosign-text mb-6">30&nbsp;Minuten Erstgespräch, kostenlos und unverbindlich.</p>
<a
href="/de/kontakt/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Extension-Beratung buchen
</a>
<p class="text-small text-gosign-text-light mt-4">25 Jahre Erfahrung · 800+ Extensions · KI-beschleunigte Entwicklung</p>
</div>
</section>

<!-- KI Table -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">KI-beschleunigte Extension-Entwicklung</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
Gosign setzt seit 2023 KI-gestützte Entwicklung ein. Das bedeutet konkret:
</p>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Aufgabe</th>
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Klassisch</th>
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Mit KI</th>
<th class="py-3 text-small font-bold text-gosign-dark">Ersparnis</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Neue Extension (Extbase)</td>
<td class="py-3 pr-4 text-body text-gosign-text">2 - 4 Wochen</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">4 - 8 Tage</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">70&nbsp;%</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Extension-Update (v9 &rarr; v12)</td>
<td class="py-3 pr-4 text-body text-gosign-text">1 - 2 Wochen</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">2 - 4 Tage</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">65&nbsp;%</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Security-Audit</td>
<td class="py-3 pr-4 text-body text-gosign-text">3 - 5 Tage</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">1 Tag</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">75&nbsp;%</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Code-Review + Refactoring</td>
<td class="py-3 pr-4 text-body text-gosign-text">1 Woche</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">2 Tage</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">60&nbsp;%</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- TYPO3 Update -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">TYPO3 Update auf die aktuelle Version</h2>
<p class="text-body text-gosign-text leading-relaxed mb-8">
Wir aktualisieren Ihre TYPO3-Installation kostengünstig auf die aktuelle LTS-Version - inklusive aller Extensions, auch veralteter und nicht mehr gewarteter.
</p>
<div class="grid md:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<div class="flex items-start gap-4">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-1" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75M21 12a9 9 0 1 1-18 0 9 9 0 0 1 18 0Z" /></svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Alle Extensions migriert</h3>
<p class="text-body text-gosign-text">Auch veraltete, nicht gewartete oder Eigenentwicklungen.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-6">
<div class="flex items-start gap-4">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-1" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 18.75a60.07 60.07 0 0 1 15.797 2.101c.727.198 1.453-.342 1.453-1.096V18.75M3.75 4.5v.75A.75.75 0 0 1 3 6h-.75m0 0v-.375c0-.621.504-1.125 1.125-1.125H20.25M2.25 6v9m18-10.5v.75c0 .414.336.75.75.75h.75m-1.5-1.5h.375c.621 0 1.125.504 1.125 1.125v9.75c0 .621-.504 1.125-1.125 1.125h-.375m1.5-1.5H21a.75.75 0 0 0-.75.75v.75m0 0H3.75m0 0h-.375a1.125 1.125 0 0 1-1.125-1.125V15m1.5 1.5v-.75A.75.75 0 0 0 3 15h-.75M15 10.5a3 3 0 1 1-6 0 3 3 0 0 1 6 0Zm3 0h.008v.008H18V10.5Zm-12 0h.008v.008H6V10.5Z" /></svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Festpreis-Angebot</h3>
<p class="text-body text-gosign-text">Transparente Kosten, keine versteckten Nacharbeiten.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-6">
<div class="flex items-start gap-4">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-1" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M3.75 13.5l10.5-11.25L12 10.5h8.25L9.75 21.75 12 13.5H3.75Z" /></svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">KI-beschleunigt</h3>
<p class="text-body text-gosign-text">30-50 % günstiger als marktüblich durch KI-gestützte Code-Analyse.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-6">
<div class="flex items-start gap-4">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-1" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M20.25 6.375c0 2.278-3.694 4.125-8.25 4.125S3.75 8.653 3.75 6.375m16.5 0c0-2.278-3.694-4.125-8.25-4.125S3.75 4.097 3.75 6.375m16.5 0v11.25c0 2.278-3.694 4.125-8.25 4.125s-8.25-1.847-8.25-4.125V6.375m16.5 0v3.75m-16.5-3.75v3.75m16.5 0v3.75C20.25 16.153 16.556 18 12 18s-8.25-1.847-8.25-4.125v-3.75m16.5 0c0 2.278-3.694 4.125-8.25 4.125s-8.25-1.847-8.25-4.125" /></svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Null Datenverlust</h3>
<p class="text-body text-gosign-text">Komplette Datenmigration mit Rollback-Sicherung.</p>
</div>
</div>
</div>
</div>
<div class="mt-8 text-center">
<a
href="/de/kontakt/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
TYPO3 Update anfragen
</a>
</div>
</div>
</section>

<!-- DSGVO-Audit -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">TYPO3 DSGVO-Audit &amp; Compliance</h2>
<p class="text-body text-gosign-text leading-relaxed mb-8">
Wir prüfen Ihre TYPO3-Installation auf DSGVO-Konformität und setzen alle Maßnahmen kostengünstig um.
</p>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse bg-white rounded-card">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Prüfbereich</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Was wird geprüft</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Ergebnis</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Cookie-Consent</td>
<td class="py-3 px-4 text-body text-gosign-text">Banner, Opt-in/Opt-out, Consent-Protokollierung</td>
<td class="py-3 px-4 text-body text-gosign-text">Rechtskonformer Consent-Flow</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Tracking &amp; Analytics</td>
<td class="py-3 px-4 text-body text-gosign-text">Google Analytics, Matomo, Tag Manager, Drittanbieter-Pixel</td>
<td class="py-3 px-4 text-body text-gosign-text">Datenschutzkonforme Konfiguration</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Extensions</td>
<td class="py-3 px-4 text-body text-gosign-text">Datenweitergabe an Dritte, externe Requests, CDN-Einbindungen</td>
<td class="py-3 px-4 text-body text-gosign-text">Bereinigung oder DSGVO-konforme Alternativen</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Formulare</td>
<td class="py-3 px-4 text-body text-gosign-text">Verarbeitungsverzeichnis, Einwilligungen, Speicherfristen</td>
<td class="py-3 px-4 text-body text-gosign-text">Vollständige Dokumentation</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Hosting &amp; SSL</td>
<td class="py-3 px-4 text-body text-gosign-text">Serverstandort, Auftragsverarbeitung, Verschlüsselung</td>
<td class="py-3 px-4 text-body text-gosign-text">EU-konformes Hosting</td>
</tr>
</tbody>
</table>
</div>
<div class="mt-8 text-center">
<a
href="/de/kontakt/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
DSGVO-Audit anfragen
</a>
</div>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
Gosign ist eine Hamburger Digitalagentur mit 25 Jahren Erfahrung in Webentwicklung, TYPO3 und KI-Integration.
Wir haben über 800 TYPO3 Extensions analysiert und entwickeln heute mit KI-Unterstützung
bis zu 70&nbsp;% schneller als mit klassischen Methoden. Unsere Kunden sind mittelständische
Unternehmen, Hochschulen und öffentliche Einrichtungen in Deutschland.
</p>
<p class="text-small text-gosign-text-light mt-2">Stand: Februar 2026</p>
</div>
</section>

<!-- Verwandte Themen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Verwandte Themen</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/de/typo3-sicherheitsmonitor/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Security</p>
<p class="text-body font-semibold text-gosign-dark">TYPO3 Sicherheitsmonitor</p>
</a>
<a href="/de/digitalagentur-hamburg/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Agentur</p>
<p class="text-body font-semibold text-gosign-dark">Digitalagentur Hamburg</p>
</a>
<a href="/de/website-sicherheit-bsi/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Compliance</p>
<p class="text-body font-semibold text-gosign-dark">Website-Sicherheit nach BSI-Gesetz</p>
</a>
</div>
</div>
</section>

--- TYPO3 Sicherheitsmonitor | Security Monitoring ---
> TYPO3 Sicherheitsmonitor: 800+ Extensions überwachen, Sicherheitslücken erkennen. Kostenloser Check verfügbar.

<!-- Was ist der Monitor? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Was ist der TYPO3 Sicherheitsmonitor?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Der Gosign TYPO3 Sicherheitsmonitor überwacht über 800 TYPO3 Extensions automatisch auf Sicherheitslücken, veraltete Versionen und bekannte Schwachstellen. Wenn eine Extension ein Security-Advisory erhält, wissen Gosign-Kunden es sofort, nicht erst beim nächsten manuellen Check. Der Monitor ist ein eigenentwickeltes Tool von Gosign, das TYPO3-Security-Bulletins, Extension-Changelogs und CVE-Datenbanken kontinuierlich auswertet.
</p>
</div>
</section>

<!-- Warum Security-Monitoring? -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Warum brauchen TYPO3-Betreiber Security-Monitoring?</h2>
<p class="text-body text-gosign-text leading-relaxed">
TYPO3-Installationen nutzen durchschnittlich 30 - 50 Extensions. Jede einzelne ist ein potenzielles Einfallstor. Das TYPO3 Security Team veröffentlicht regelmäßig Advisories, aber wer liest sie alle? Gosigns Monitor tut genau das. Automatisch und in Echtzeit.
</p>
</div>
</section>

<!-- Monitor-Tabelle -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Was der Monitor überwacht</h2>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Prüfbereich</th>
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Was wird geprüft</th>
<th class="py-3 text-small font-bold text-gosign-dark">Frequenz</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Extension-Versionen</td>
<td class="py-3 pr-4 text-body text-gosign-text">Installierte vs. aktuelle Version</td>
<td class="py-3 text-body text-gosign-text">Täglich</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Security Advisories</td>
<td class="py-3 pr-4 text-body text-gosign-text">TYPO3 Security Bulletins, CVE-Datenbanken</td>
<td class="py-3 text-body text-gosign-accent-text font-semibold">Echtzeit</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">End-of-Life</td>
<td class="py-3 pr-4 text-body text-gosign-text">Extensions ohne Maintainer oder Updates</td>
<td class="py-3 text-body text-gosign-text">Wöchentlich</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">TYPO3 Core</td>
<td class="py-3 pr-4 text-body text-gosign-text">Core-Version vs. aktuelle Stable/LTS</td>
<td class="py-3 text-body text-gosign-text">Täglich</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">PHP-Version</td>
<td class="py-3 pr-4 text-body text-gosign-text">Kompatibilität und Security-Status</td>
<td class="py-3 text-body text-gosign-text">Wöchentlich</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Leistungen -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">Leistungen rund um TYPO3-Sicherheit</h2>
<div class="grid md:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Security-Monitoring</h3>
<p class="text-body text-gosign-text">
Kontinuierliche Überwachung aller Extensions und des TYPO3 Core. Sofortige Benachrichtigung bei kritischen Schwachstellen.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Security-Audit</h3>
<p class="text-body text-gosign-text">
Einmalige Tiefenprüfung: Extension-Inventar, Versionsstand, bekannte Schwachstellen, Code-Qualität. KI-gestützte Analyse in Stunden statt Tagen.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Incident Response</h3>
<p class="text-body text-gosign-text">
Website gehackt? Gosign analysiert den Angriffsvektor, bereinigt die Installation und schließt die Lücke. Notfall-Support verfügbar.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Wartung &amp; Patching</h3>
<p class="text-body text-gosign-text">
Regelmäßige Security-Updates, Extension-Upgrades, PHP-Version-Management. Proaktiv, nicht reaktiv.
</p>
</div>
</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">TYPO3-Security-Check anfragen, 30&nbsp;Minuten, kostenlos.</h3>
<p class="text-body text-gosign-text mb-6">Wir prüfen Ihre TYPO3-Installation auf bekannte Schwachstellen, unverbindlich.</p>
<a
href="/de/kontakt/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Erstgespräch vereinbaren
</a>
<p class="text-small text-gosign-text-light mt-4">25 Jahre Erfahrung · 800+ Extensions · KI-beschleunigte Entwicklung</p>
</div>
</section>

<!-- KI Table -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">KI-beschleunigte Security-Analyse: 75&nbsp;% schneller</h2>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Aufgabe</th>
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Klassisch</th>
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Mit KI</th>
<th class="py-3 text-small font-bold text-gosign-dark">Ersparnis</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Extension-Inventar + Versionsvergleich</td>
<td class="py-3 pr-4 text-body text-gosign-text">1 Tag</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">30 Minuten</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">90&nbsp;%</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Schwachstellen-Analyse (50 Extensions)</td>
<td class="py-3 pr-4 text-body text-gosign-text">2 Tage</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">4 Stunden</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">75&nbsp;%</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Code-Audit einer Extension</td>
<td class="py-3 pr-4 text-body text-gosign-text">1 Woche</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">2 Tage</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">60&nbsp;%</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Incident-Analyse nach Hack</td>
<td class="py-3 pr-4 text-body text-gosign-text">2 Tage</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">6 Stunden</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">65&nbsp;%</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- TYPO3 Update -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">TYPO3 Update auf die aktuelle Version</h2>
<p class="text-body text-gosign-text leading-relaxed mb-8">
Wir aktualisieren Ihre TYPO3-Installation kostengünstig auf die aktuelle LTS-Version - inklusive aller Extensions, auch veralteter und nicht mehr gewarteter.
</p>
<div class="grid md:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<div class="flex items-start gap-4">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-1" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75M21 12a9 9 0 1 1-18 0 9 9 0 0 1 18 0Z" /></svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Alle Extensions migriert</h3>
<p class="text-body text-gosign-text">Auch veraltete, nicht gewartete oder Eigenentwicklungen.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-6">
<div class="flex items-start gap-4">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-1" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 18.75a60.07 60.07 0 0 1 15.797 2.101c.727.198 1.453-.342 1.453-1.096V18.75M3.75 4.5v.75A.75.75 0 0 1 3 6h-.75m0 0v-.375c0-.621.504-1.125 1.125-1.125H20.25M2.25 6v9m18-10.5v.75c0 .414.336.75.75.75h.75m-1.5-1.5h.375c.621 0 1.125.504 1.125 1.125v9.75c0 .621-.504 1.125-1.125 1.125h-.375m1.5-1.5H21a.75.75 0 0 0-.75.75v.75m0 0H3.75m0 0h-.375a1.125 1.125 0 0 1-1.125-1.125V15m1.5 1.5v-.75A.75.75 0 0 0 3 15h-.75M15 10.5a3 3 0 1 1-6 0 3 3 0 0 1 6 0Zm3 0h.008v.008H18V10.5Zm-12 0h.008v.008H6V10.5Z" /></svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Festpreis-Angebot</h3>
<p class="text-body text-gosign-text">Transparente Kosten, keine versteckten Nacharbeiten.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-6">
<div class="flex items-start gap-4">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-1" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M3.75 13.5l10.5-11.25L12 10.5h8.25L9.75 21.75 12 13.5H3.75Z" /></svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">KI-beschleunigt</h3>
<p class="text-body text-gosign-text">30-50 % günstiger als marktüblich durch KI-gestützte Code-Analyse.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-6">
<div class="flex items-start gap-4">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-1" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M20.25 6.375c0 2.278-3.694 4.125-8.25 4.125S3.75 8.653 3.75 6.375m16.5 0c0-2.278-3.694-4.125-8.25-4.125S3.75 4.097 3.75 6.375m16.5 0v11.25c0 2.278-3.694 4.125-8.25 4.125s-8.25-1.847-8.25-4.125V6.375m16.5 0v3.75m-16.5-3.75v3.75m16.5 0v3.75C20.25 16.153 16.556 18 12 18s-8.25-1.847-8.25-4.125v-3.75m16.5 0c0 2.278-3.694 4.125-8.25 4.125s-8.25-1.847-8.25-4.125" /></svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Null Datenverlust</h3>
<p class="text-body text-gosign-text">Komplette Datenmigration mit Rollback-Sicherung.</p>
</div>
</div>
</div>
</div>
<div class="mt-8 text-center">
<a
href="/de/kontakt/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
TYPO3 Update anfragen
</a>
</div>
</div>
</section>

<!-- DSGVO-Audit -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">TYPO3 DSGVO-Audit &amp; Compliance</h2>
<p class="text-body text-gosign-text leading-relaxed mb-8">
Wir prüfen Ihre TYPO3-Installation auf DSGVO-Konformität und setzen alle Maßnahmen kostengünstig um.
</p>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse bg-white rounded-card">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Prüfbereich</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Was wird geprüft</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Ergebnis</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Cookie-Consent</td>
<td class="py-3 px-4 text-body text-gosign-text">Banner, Opt-in/Opt-out, Consent-Protokollierung</td>
<td class="py-3 px-4 text-body text-gosign-text">Rechtskonformer Consent-Flow</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Tracking &amp; Analytics</td>
<td class="py-3 px-4 text-body text-gosign-text">Google Analytics, Matomo, Tag Manager, Drittanbieter-Pixel</td>
<td class="py-3 px-4 text-body text-gosign-text">Datenschutzkonforme Konfiguration</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Extensions</td>
<td class="py-3 px-4 text-body text-gosign-text">Datenweitergabe an Dritte, externe Requests, CDN-Einbindungen</td>
<td class="py-3 px-4 text-body text-gosign-text">Bereinigung oder DSGVO-konforme Alternativen</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Formulare</td>
<td class="py-3 px-4 text-body text-gosign-text">Verarbeitungsverzeichnis, Einwilligungen, Speicherfristen</td>
<td class="py-3 px-4 text-body text-gosign-text">Vollständige Dokumentation</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Hosting &amp; SSL</td>
<td class="py-3 px-4 text-body text-gosign-text">Serverstandort, Auftragsverarbeitung, Verschlüsselung</td>
<td class="py-3 px-4 text-body text-gosign-text">EU-konformes Hosting</td>
</tr>
</tbody>
</table>
</div>
<div class="mt-8 text-center">
<a
href="/de/kontakt/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
DSGVO-Audit anfragen
</a>
</div>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
Gosign ist eine Hamburger Digitalagentur mit 25 Jahren Erfahrung in Webentwicklung, TYPO3 und KI-Integration.
Wir haben über 800 TYPO3 Extensions analysiert und entwickeln heute mit KI-Unterstützung
bis zu 70&nbsp;% schneller als mit klassischen Methoden. Unsere Kunden sind mittelständische
Unternehmen, Hochschulen und öffentliche Einrichtungen in Deutschland.
</p>
<p class="text-small text-gosign-text-light mt-2">Stand: Februar 2026</p>
</div>
</section>

<!-- Verwandte Themen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Verwandte Themen</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/de/typo3-extensions/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">TYPO3</p>
<p class="text-body font-semibold text-gosign-dark">TYPO3 Extensions: Entwicklung & Monitoring</p>
</a>
<a href="/de/website-gehackt-10-gruende/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Notfall</p>
<p class="text-body font-semibold text-gosign-dark">Website gehackt: 10 Gründe & Soforthilfe</p>
</a>
<a href="/de/website-sicherheit-bsi/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Compliance</p>
<p class="text-body font-semibold text-gosign-dark">Website-Sicherheit nach BSI-Gesetz</p>
</a>
</div>
</div>
</section>

--- Über uns - Enterprise AI Infrastructure seit 2001 ---
> Gosign entwickelt Enterprise AI Agents und KI-Infrastruktur. Inhabergeführt seit 2001. 108 Mitarbeiter. Über 5.000 Projekte für Airbus, VW, Shell.

<article class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<div class="prose prose-lg prose-headings:text-gosign-dark prose-headings:font-bold prose-h2:text-h2 prose-h2:mt-12 prose-h2:mb-4 prose-h3:text-h3 prose-h3:mt-8 prose-h3:mb-3 prose-p:text-gosign-text prose-p:leading-relaxed prose-a:text-gosign-accent-text prose-a:underline prose-a:decoration-gosign-accent-text/30 hover:prose-a:decoration-gosign-accent-text prose-strong:text-gosign-dark prose-ul:text-gosign-text prose-ol:text-gosign-text">

## Von Softwareprojekten zu Entscheidungsarchitektur

Gosign wurde 2001 in Hamburg gegründet. Seit über 25 Jahren entwickeln wir komplexe Softwaresysteme für mittelständische Unternehmen und Konzerne - in über 5.000 Projekten für Unternehmen wie Airbus, Volkswagen, Shell.

Was sich verändert hat, ist nicht unser Anspruch - sondern die Technologie.

Unsere Wurzeln liegen in klassischer Enterprise-Software: Systemintegration, individuelle Plattformen, ERP-nahe Entwicklung und sicherheitsgetriebene Architekturen. Mit dem Aufkommen generativer KI haben wir begonnen, LLM-basierte Workflows in realen Unternehmensumgebungen zu testen - zunächst experimentell, dann produktiv in Azure-basierten Enterprise-Setups.

Heute bauen wir Enterprise AI Agents und die Infrastruktur, die sie verantwortbar macht: den [Decision Layer](/de/decision-layer/), der jeden Prozess in einzelne Entscheidungsschritte zerlegt und für jeden Schritt definiert: Mensch, Regelwerk oder KI.


## Wofür wir stehen

### Entscheidungsqualität vor Automatisierung

Unternehmen scheitern selten an fehlenden Tools. Sie scheitern an inkonsistenter Entscheidungslogik.

HR- und Finance-Entscheidungen sind in vielen Organisationen nicht versioniert, nicht reproduzierbar und abhängig vom Wissen einzelner Personen. Unsere Architektur macht Entscheidungslogik explizit, nachvollziehbar und auditierbar - als technische Schicht, nicht als Organisationsberatung.

### Governance by Design

Compliance ist bei uns kein nachgelagerter Prozess. Unsere Agenten werden so gebaut, dass Entscheidungslogik versioniert ist, [Human-in-the-Loop](/de/governance/) architektonisch verankert ist, Audit-Trails automatisch entstehen und Controls als Datenobjekte existieren. Wenn eine Zertifizierung erforderlich ist, ist das System strukturell darauf vorbereitet.

Mehr dazu auf unseren [Governance-Seiten](/de/governance/).

### Integration statt Ersatz

Wir ersetzen keine bestehenden Systeme. SAP bleibt ERP. Workday bleibt HR-Plattform. SuccessFactors bleibt führend. Wir ergänzen diese Systeme um eine Entscheidungs- und Governance-Schicht - den Decision Layer, der Agenten auditierbar und steuerbar macht.


## Wie wir arbeiten

### Co-Build mit Fachbereichen

Jedes Unternehmen hat eigene Compensation-Logik, eigene Tarifverträge, eigene Governance-Vorgaben und eigene ERP-Strukturen. Deshalb entwickeln wir [AI-Agenten](/de/leistungen/ai-agents/) im Co-Build mit HR, Finance und IT - nicht als fertiges Produkt, sondern konfiguriert auf die spezifischen Prozesse und Regeln des Unternehmens.

### Voller Quellcode-Zugang

Unsere Lösungen laufen in der [Infrastruktur des Kunden](/de/leistungen/infrastruktur/) - in Azure, GCP, AWS oder Self-Hosted. Kein proprietäres SaaS-Modell, kein Vendor-Lock-in. Voller Zugang zu Quellcode, Konfigurationen und Regelwerken. Übergabe in den Eigenbetrieb nach 12-18 Monaten ist Teil des Modells.

Gosign ist bewusst kein Abhängigkeitsmodell.


## Technologien

<div class="not-prose text-body text-gosign-text leading-relaxed">
<a href="https://www.python.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Python</a>, <a href="https://www.typescriptlang.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">TypeScript</a>/<a href="https://nodejs.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Node.js</a>, <a href="https://go.dev/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Go (Golang)</a> - Frontend: <a href="https://react.dev/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">React</a>, <a href="https://nextjs.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Next.js</a>, <a href="https://vuejs.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Vue</a> - Datenbank: <a href="https://www.postgresql.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">PostgreSQL</a>, <a href="https://supabase.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Supabase</a> - Orchestrierung: <a href="https://trigger.dev" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Trigger.dev</a>, <a href="https://camunda.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Camunda</a>, <a href="https://airflow.apache.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Airflow</a> - Container: <a href="https://www.docker.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Docker</a>, <a href="https://kubernetes.io/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Kubernetes</a> - Cloud: <a href="https://azure.microsoft.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Azure</a>, <a href="https://cloud.google.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">GCP</a>, <a href="https://aws.amazon.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">AWS</a> - On-Premise: <a href="https://github.com/vllm-project/vllm" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">vLLM</a>, <a href="https://ollama.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Ollama</a>
</div>


## Zertifizierungen und Kompetenzen

Unser Team vereint über 25 Jahre Enterprise-Erfahrung mit aktuellen Cloud- und AI-Zertifizierungen. Unsere AI Engineers sind Microsoft Azure AI zertifiziert und arbeiten täglich mit LLM-APIs, Orchestrierungsframeworks und Enterprise-Integrationssystemen.

<a href="https://www.bvdw.org/themen/kuenstliche-intelligenz/" target="_blank" rel="noopener noreferrer" class="not-prose flex items-center gap-4 group mt-6">
<img src="/images/badges/bvdw-mitglied.png" alt="BVDW Mitglied" width="349" height="428" class="w-16 h-16 object-contain opacity-60 group-hover:opacity-100 transition-opacity" loading="lazy" />
<span class="text-body text-gosign-text-light group-hover:text-gosign-accent transition-colors">Mitglied im Bundesverband Digitale Wirtschaft (BVDW)</span>
</a>



## Wer wir sind

Gosign ist inhabergeführt. 108 Mitarbeiter an Standorten in Hamburg, Berlin, Krakau, Barcelona, Lissabon und São Paulo. Unser größtes Entwicklungszentrum betreiben wir seit 2002 in Pakistan - gegründet als Programmierschule, heute ein etablierter Engineering-Hub mit enger Anbindung an die Informatik-Fakultäten der Universitäten in Karachi, Lahore und Islamabad.

<div class="flex flex-col md:flex-row gap-12 not-prose my-8">
<div class="flex-1 text-center">
<img src="/images/team/bert-gogolin.webp" alt="Bert Gogolin, Geschäftsführer Gosign GmbH" width="400" height="400" class="w-48 h-48 lg:w-56 lg:h-56 rounded-full object-cover mx-auto mb-6 border-4 border-gosign-light" />
<h3 class="text-h3 font-bold text-gosign-dark">Bert Gogolin</h3>
<p class="text-body text-gosign-text-light">Geschäftsführer</p>
<a href="https://www.linkedin.com/in/bert-gogolin/" class="inline-flex items-center gap-1 text-small text-gosign-text-light hover:text-gosign-accent mt-2 transition-colors" target="_blank" rel="noopener noreferrer">
<svg class="w-4 h-4" fill="currentColor" viewBox="0 0 24 24"><path d="M20.447 20.452h-3.554v-5.569c0-1.328-.027-3.037-1.852-3.037-1.853 0-2.136 1.445-2.136 2.939v5.667H9.351V9h3.414v1.561h.046c.477-.9 1.637-1.85 3.37-1.85 3.601 0 4.267 2.37 4.267 5.455v6.286zM5.337 7.433a2.062 2.062 0 01-2.063-2.065 2.064 2.064 0 112.063 2.065zm1.782 13.019H3.555V9h3.564v11.452zM22.225 0H1.771C.792 0 0 .774 0 1.729v20.542C0 23.227.792 24 1.771 24h20.451C23.2 24 24 23.227 24 22.271V1.729C24 .774 23.2 0 22.222 0h.003z"/></svg>
LinkedIn
</a>
</div>
<div class="flex-1 text-center">
<img src="/images/team/dieter-gogolin.webp" alt="Dieter Gogolin, Geschäftsführer Gosign GmbH" width="400" height="400" class="w-48 h-48 lg:w-56 lg:h-56 rounded-full object-cover mx-auto mb-6 border-4 border-gosign-light" />
<h3 class="text-h3 font-bold text-gosign-dark">Dieter Gogolin</h3>
<p class="text-body text-gosign-text-light">Geschäftsführer</p>
</div>
</div>

Bert leitet die Zusammenarbeit mit Kunden: von der Erstanalyse über die Prozessaufnahme bis zur Architekturentscheidung. Dieter verantwortet die operative und strategische Unternehmensentwicklung - von der Infrastruktur über die internationalen Entwicklungsteams bis zur Partnerschaftsstrategie.


## Warum wir das tun

Generative KI verändert, wie Entscheidungen vorbereitet, dokumentiert und verantwortet werden. Wir sind überzeugt, dass AI-Agenten nur dann produktiv skalieren, wenn Governance strukturell integriert ist, Entscheidungslogik explizit wird und Menschen bewusst eingebunden bleiben.

Dafür bauen wir die Infrastruktur.

Alle Unternehmensdaten auf einen Blick: [Fakten & Zahlen](/de/fakten/)

</div>
</div>
</article>

--- Warum Gosign - EU AI Act, Self-Hosting, EU-first ---
> Drei Architektur-Entscheidungen: EU AI Act ready, Ihre Infrastruktur, EU-first. Keine SaaS-Abhängigkeit, kein US-Cloud-Risiko.

<!-- USP 1: EU AI Act ready -->
<section id="eu-ai-act" class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<div class="flex items-center gap-3 mb-6">
<svg class="w-10 h-10 text-gosign-accent-text" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<h2 class="text-h1 font-bold text-gosign-dark">EU AI Act ready</h2>
</div>
<p class="text-body-lg text-gosign-dark font-semibold">Jede Agent-Entscheidung nachvollziehbar. Für den Betriebsrat. Für die Aufsicht. Für Sie.</p>
<p class="text-body text-gosign-text-light mt-4">HR-Agents fallen unter Artikel 6 des EU AI Act: Beschäftigungskontext bedeutet Hochrisiko-Einstufung. Die zentrale Frage ist nicht ob, sondern wie jede Entscheidung dokumentiert wird - wer hat entschieden, warum, mit welchem Confidence-Score.</p>
<p class="text-body text-gosign-text-light mt-4">Gosign-Agents machen jede Entscheidung transparent - architektonisch, nicht nachträglich:</p>
<ul class="mt-4 space-y-3">
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text mt-0.5 flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" /></svg>
<span class="text-body text-gosign-text-light"><strong class="text-gosign-dark">Art. 9 Risikomanagement</strong> - Der Decision Layer definiert für jeden Prozessschritt vorab: Mensch, Regelwerk oder KI. Risikobewertung ist kein Audit-Projekt, sondern Architektur.</span>
</li>
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text mt-0.5 flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" /></svg>
<span class="text-body text-gosign-text-light"><strong class="text-gosign-dark">Art. 12 Aufzeichnungspflichten</strong> - Jede Agent-Entscheidung als Entscheidungsakt im Audit Trail: Input, angewandte Regel samt Version, Confidence-Score, Ergebnis und Anfechtungspfad - der Nachweis pro Mikroentscheidung.</span>
</li>
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text mt-0.5 flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" /></svg>
<span class="text-body text-gosign-text-light"><strong class="text-gosign-dark">Art. 13 Transparenz</strong> - Der Betriebsrat kann über das Auditor-Portal jede Entscheidung nachvollziehen - ohne IT-Abteilung, ohne Datenbankzugriff.</span>
</li>
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text mt-0.5 flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" /></svg>
<span class="text-body text-gosign-text-light"><strong class="text-gosign-dark">Art. 14 Menschliche Aufsicht</strong> - Human-in-the-Loop als Architekturprinzip, nicht als optionales Feature. Der Mensch bleibt dort im Prozess, wo Betriebsrat, Arbeitsrecht oder Diskriminierungsrisiko es verlangen.</span>
</li>
</ul>
<p class="text-body text-gosign-text-light mt-6">Entscheidungstransparenz ist kein nachträgliches Compliance-Projekt. Sie ist im Decision Layer eingebaut - ab dem ersten Pilot.</p>
<p class="text-body text-gosign-text-light mt-4">Vertiefung: <a href="/de/magazin/eu-ai-act-gilt-weltweit/" class="text-gosign-accent-text hover:underline">Warum der EU AI Act weltweit gilt - und was das für Ihr Unternehmen bedeutet</a></p>
</div>
</div>
</section>

<!-- USP 2: Ihre Infrastruktur -->
<section id="infrastruktur" class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<div class="flex items-center gap-3 mb-6">
<svg class="w-10 h-10 text-gosign-accent-text" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<h2 class="text-h1 font-bold text-gosign-dark">Ihre Infrastruktur</h2>
</div>
<p class="text-body-lg text-gosign-dark font-semibold">In Ihrem Rechenzentrum. Unter Ihrer Kontrolle.</p>
<p class="text-body text-gosign-text-light mt-4">Gosign AI Agents sind kein SaaS-Produkt. Sie laufen in Ihrer Infrastruktur - ob On-Premises, Private Cloud oder Hybrid. Daten verlassen Ihre Systeme nicht.</p>
<p class="text-body text-gosign-text-light mt-4">Das ist keine Philosophie-Frage. Es ist eine Betriebsrats-Frage: Kein Betriebsrat in Deutschland wird einer Lösung zustimmen, bei der Mitarbeiterdaten auf US-Servern verarbeitet werden. Self-Hosting ist die Voraussetzung für die Betriebsvereinbarung.</p>
<div class="grid grid-cols-1 md:grid-cols-3 gap-6 mt-8">
<div class="border border-gosign-border rounded-card p-6 bg-gosign-white">
<p class="text-sm font-bold text-gosign-accent-text uppercase tracking-wider">Quellcode</p>
<p class="text-body text-gosign-text-light mt-2">Voller Zugang. Sie können den Agent jederzeit ohne Gosign weiterbetreiben. Kein Vendor-Lock-in.</p>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-gosign-white">
<p class="text-sm font-bold text-gosign-accent-text uppercase tracking-wider">Modell-agnostisch</p>
<p class="text-body text-gosign-text-light mt-2">Sie wählen das LLM - nicht wir. OpenAI, Anthropic, lokale Modelle. Kein Lock-in auf einen Anbieter.</p>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-gosign-white">
<p class="text-sm font-bold text-gosign-accent-text uppercase tracking-wider">DSGVO nativ</p>
<p class="text-body text-gosign-text-light mt-2">Datenresidenz als Architekturentscheidung. Nicht als nachträgliches Feature. Keine Daten verlassen Ihre Infrastruktur.</p>
</div>
</div>
</div>
</div>
</section>

<!-- USP 3: EU-first -->
<section id="eu-first" class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<div class="flex items-center gap-3 mb-6">
<svg class="w-10 h-10 text-gosign-accent-text" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<h2 class="text-h1 font-bold text-gosign-dark">EU-first</h2>
</div>
<p class="text-body-lg text-gosign-dark font-semibold">Kein US-Produkt mit EU-Patch. EU-Regulierung ist die Baseline.</p>
<p class="text-body text-gosign-text-light mt-4">Die meisten AI-Produkte werden für den US-Markt gebaut und nachträglich an EU-Regulierung angepasst. DSGVO als Checkbox, Mitbestimmung als kulturelles Kuriosum, Datenresidenz als optionales Feature.</p>
<p class="text-body text-gosign-text-light mt-4">Gosign-Agents sind umgekehrt gebaut: Daten bleiben in Ihrer Infrastruktur - keine US-Cloud-Abhängigkeit. DSGVO ist Architekturprinzip, nicht Checkbox. Wer das härteste Regulierungsumfeld erfüllt, erfüllt jedes andere auch - ob AT, CH oder weitere EU-Länder.</p>
<p class="text-body text-gosign-text-light mt-4">Das bedeutet konkret:</p>
<ul class="mt-4 space-y-3">
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text mt-0.5 flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" /></svg>
<span class="text-body text-gosign-text-light"><strong class="text-gosign-dark">Keine US-Cloud-Abhängigkeit</strong>. Daten bleiben in Ihrer Infrastruktur - kein CLOUD Act, kein Schrems-III-Risiko, keine Transferproblematik.</span>
</li>
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text mt-0.5 flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" /></svg>
<span class="text-body text-gosign-text-light"><strong class="text-gosign-dark">DSGVO als Architekturprinzip</strong>, nicht als nachträgliche Anpassung. Datenresidenz, Löschkonzepte und Zugriffskontrollen sind in der Architektur verankert.</span>
</li>
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text mt-0.5 flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" /></svg>
<span class="text-body text-gosign-text-light"><strong class="text-gosign-dark">Tarifverträge als deterministische Regeln</strong> im Decision Layer. IG Metall, IG BCE, ver.di, TVöD - jeder Tarifvertrag wird als Regelwerk implementiert, nicht als Freitextfeld.</span>
</li>
</ul>
<p class="text-body text-gosign-text-light mt-6">Vertiefung: <a href="/de/magazin/shadow-ai-governance/" class="text-gosign-accent-text hover:underline">Shadow AI im Unternehmen - Governance statt Verbot</a></p>
</div>
</div>
</section>

<!-- Vertiefung im Agent Briefing -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">Vertiefung im Agent Briefing (Gosign Magazin)</h2>
<div class="grid grid-cols-1 md:grid-cols-3 gap-6">
<a href="/de/magazin/eu-ai-act-gilt-weltweit/" class="block border border-gosign-border rounded-card p-6 bg-gosign-white hover:border-gosign-accent transition-colors">
<p class="text-xs font-bold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<p class="text-h3 font-bold text-gosign-dark">EU AI Act gilt weltweit</p>
</a>
<a href="/de/magazin/eu-ai-act-hr/" class="block border border-gosign-border rounded-card p-6 bg-gosign-white hover:border-gosign-accent transition-colors">
<p class="text-xs font-bold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<p class="text-h3 font-bold text-gosign-dark">EU AI Act und HR</p>
</a>
<a href="/de/magazin/agent-governance-hr/" class="block border border-gosign-border rounded-card p-6 bg-gosign-white hover:border-gosign-accent transition-colors">
<p class="text-xs font-bold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<p class="text-h3 font-bold text-gosign-dark">Agent Governance für HR</p>
</a>
</div>
</div>
</section>

--- Website gehackt? 10 Gründe & Soforthilfe ---
> Warum Websites gehackt werden: Die 10 häufigsten Ursachen und was Sie sofort tun können. Notfall-Hilfe von Gosign.

<!-- Was tun wenn gehackt? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Was tun, wenn die Website gehackt wurde?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Wenn Ihre Website gehackt wurde, zählt Geschwindigkeit: Malware entfernen, Einfallstor finden, Lücke schließen, Google über die Bereinigung informieren. Gosign bietet Notfall-Support für gehackte Websites, WordPress, TYPO3 und andere CMS. Dieser Artikel erklärt die 10 häufigsten Ursachen für Website-Hacks und wie Sie sich schützen.
</p>
</div>
</section>

<!-- 10 Gründe -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">Die 10 häufigsten Gründe, warum Websites gehackt werden</h2>

<div class="space-y-8">
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">1. Veraltete CMS-Version</h3>
<p class="text-body text-gosign-text leading-relaxed">
WordPress 5.x, TYPO3 v9, Joomla 3: Alte CMS-Versionen haben bekannte, dokumentierte Sicherheitslücken. Angreifer scannen automatisch nach veralteten Installationen. Lösung: Immer aktuelle LTS-Version, automatische Security-Updates.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">2. Unsichere Plugins/Extensions</h3>
<p class="text-body text-gosign-text leading-relaxed">
Ein einziges veraltetes Plugin reicht. Gosign überwacht über 800 TYPO3 Extensions und kennt die Risiko-Kandidaten. Bei WordPress: Nur Plugins aus vertrauenswürdigen Quellen, regelmäßige Updates, nicht genutzte Plugins löschen (nicht nur deaktivieren).
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">3. Schwache Passwörter</h3>
<p class="text-body text-gosign-text leading-relaxed">
"admin/admin123" ist immer noch erschreckend häufig. Brute-Force-Angriffe probieren tausende Kombinationen pro Minute. Lösung: Starke Passwörter + 2-Faktor-Authentifizierung + Login-Rate-Limiting.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">4. Fehlendes SSL/HTTPS</h3>
<p class="text-body text-gosign-text leading-relaxed">
Ohne HTTPS werden Login-Daten im Klartext übertragen. Jede Website braucht ein SSL-Zertifikat. 2026 gibt es keine Ausrede mehr.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">5. Unsicheres Hosting</h3>
<p class="text-body text-gosign-text leading-relaxed">
Shared Hosting mit hunderten Sites auf einem Server: Wird eine gehackt, sind alle gefährdet. Lösung: Managed Hosting mit Isolation, automatischen Backups und Web Application Firewall.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">6. Kein Web Application Firewall (WAF)</h3>
<p class="text-body text-gosign-text leading-relaxed">
Eine WAF blockiert bekannte Angriffsmuster (SQL Injection, XSS, File Inclusion), bevor sie Ihre Anwendung erreichen. Cloudflare WAF, ModSecurity oder kommerzielle Lösungen.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">7. Fehlende Backups</h3>
<p class="text-body text-gosign-text leading-relaxed">
Kein Backup = kein Rettungsanker. Tägliche Backups, getrennt vom Webserver gespeichert, regelmäßig getestet. Ein Backup, das sich nicht wiederherstellen lässt, ist kein Backup.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">8. Unsichere Datei-Uploads</h3>
<p class="text-body text-gosign-text leading-relaxed">
Upload-Formulare ohne Validierung erlauben Angreifern, PHP-Shells hochzuladen. Lösung: Strenge Dateityp-Prüfung, Uploads außerhalb des Webroot speichern, Dateinamen randomisieren.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">9. SQL Injection</h3>
<p class="text-body text-gosign-text leading-relaxed">
Ungefilterte Nutzereingaben in Datenbankabfragen erlauben Angreifern, die gesamte Datenbank auszulesen oder zu manipulieren. Lösung: Prepared Statements, Input-Validation, ORM-Nutzung.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">10. Kein Monitoring</h3>
<p class="text-body text-gosign-text leading-relaxed">
Wenn niemand hinschaut, bemerkt niemand den Einbruch. Manche Hacks bleiben monatelang unentdeckt (Spam-Injection, Crypto-Mining, Redirect-Hacks). Lösung: Uptime-Monitoring, File-Integrity-Monitoring, regelmäßige Malware-Scans.
</p>
</div>
</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Website gehackt? Gosign hilft. Notfall-Beratung verfügbar.</h3>
<p class="text-body text-gosign-text mb-6">Schnelle Analyse, Bereinigung und Absicherung Ihrer Website.</p>
<a
href="/de/kontakt/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Soforthilfe anfragen
</a>
<p class="text-small text-gosign-text-light mt-4">25 Jahre Erfahrung · 800+ Extensions · KI-beschleunigte Entwicklung</p>
</div>
</section>

<!-- Checkliste -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Checkliste: Sofortmaßnahmen nach einem Hack</h2>
<ol class="space-y-3">
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 flex items-center justify-center bg-gosign-accent text-white font-bold rounded-full text-small">1</span>
<span class="text-body text-gosign-text pt-1">Website offline nehmen (Maintenance Mode)</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 flex items-center justify-center bg-gosign-accent text-white font-bold rounded-full text-small">2</span>
<span class="text-body text-gosign-text pt-1">Passwörter ändern (CMS, FTP, Datenbank, Hosting)</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 flex items-center justify-center bg-gosign-accent text-white font-bold rounded-full text-small">3</span>
<span class="text-body text-gosign-text pt-1">Backup sichern (aktuellen Zustand für Forensik)</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 flex items-center justify-center bg-gosign-accent text-white font-bold rounded-full text-small">4</span>
<span class="text-body text-gosign-text pt-1">Letztes sauberes Backup identifizieren</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 flex items-center justify-center bg-gosign-accent text-white font-bold rounded-full text-small">5</span>
<span class="text-body text-gosign-text pt-1">Malware-Scan durchführen</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 flex items-center justify-center bg-gosign-accent text-white font-bold rounded-full text-small">6</span>
<span class="text-body text-gosign-text pt-1">Einfallstor identifizieren (Logs prüfen)</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 flex items-center justify-center bg-gosign-accent text-white font-bold rounded-full text-small">7</span>
<span class="text-body text-gosign-text pt-1">Bereinigen und Lücke schließen</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 flex items-center justify-center bg-gosign-accent text-white font-bold rounded-full text-small">8</span>
<span class="text-body text-gosign-text pt-1">Website wieder online nehmen</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 flex items-center justify-center bg-gosign-accent text-white font-bold rounded-full text-small">9</span>
<span class="text-body text-gosign-text pt-1">Google Search Console: Antrag auf Überprüfung</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 flex items-center justify-center bg-gosign-accent text-white font-bold rounded-full text-small">10</span>
<span class="text-body text-gosign-text pt-1">Monitoring einrichten, damit es nicht wieder passiert</span>
</li>
</ol>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
Gosign ist eine Hamburger Digitalagentur mit 25 Jahren Erfahrung in Webentwicklung, TYPO3 und KI-Integration.
Wir haben über 800 TYPO3 Extensions analysiert und entwickeln heute mit KI-Unterstützung
bis zu 70&nbsp;% schneller als mit klassischen Methoden. Unsere Kunden sind mittelständische
Unternehmen, Hochschulen und öffentliche Einrichtungen in Deutschland.
</p>
<p class="text-small text-gosign-text-light mt-2">Stand: Februar 2026</p>
</div>
</section>

<!-- Verwandte Themen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Verwandte Themen</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/de/website-sicherheit-bsi/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Compliance</p>
<p class="text-body font-semibold text-gosign-dark">Website-Sicherheit nach BSI-Gesetz</p>
</a>
<a href="/de/typo3-sicherheitsmonitor/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Security</p>
<p class="text-body font-semibold text-gosign-dark">TYPO3 Sicherheitsmonitor</p>
</a>
<a href="/de/wordpress-agentur/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Webentwicklung</p>
<p class="text-body font-semibold text-gosign-dark">WordPress Agentur: Wartung & Security</p>
</a>
</div>
</div>
</section>

--- Website-Sicherheit nach BSI-Gesetz | Check | Gosign ---
> Ist Ihre Website BSI-konform? Sicherheits-Check für Unternehmen. Schwachstellen finden, KRITIS-Anforderungen erfüllen.

<!-- Was fordert BSI? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Was fordert das BSI-Gesetz für Websites?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Das BSI-Gesetz (Gesetz über das Bundesamt für Sicherheit in der Informationstechnik) verpflichtet Betreiber kritischer Infrastrukturen (KRITIS) zu angemessenen IT-Sicherheitsmaßnahmen. Aber auch Unternehmen außerhalb von KRITIS sollten sich an BSI-Standards orientieren. Spätestens seit NIS-2 (2024) gelten erweiterte Pflichten für viele Branchen. Gosign prüft Ihre Website auf BSI-relevante Schwachstellen.
</p>
</div>
</section>

<!-- Check-Tabelle -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Was Gosign bei einem Website-Security-Check prüft</h2>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse bg-white rounded-card">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Prüfbereich</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Was wird geprüft</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">BSI-Relevanz</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">HTTPS/TLS-Konfiguration</td>
<td class="py-3 px-4 text-body text-gosign-text">Zertifikat, Protokoll-Version, Cipher Suites</td>
<td class="py-3 px-4 text-body text-gosign-text">Grundschutz</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Content Security Policy</td>
<td class="py-3 px-4 text-body text-gosign-text">CSP-Header, XSS-Schutz</td>
<td class="py-3 px-4 text-body text-gosign-text">Grundschutz</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Server-Header</td>
<td class="py-3 px-4 text-body text-gosign-text">X-Frame-Options, HSTS, Referrer-Policy</td>
<td class="py-3 px-4 text-body text-gosign-text">Grundschutz</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">CMS-Version &amp; Extensions</td>
<td class="py-3 px-4 text-body text-gosign-text">Bekannte Schwachstellen, EOL-Software</td>
<td class="py-3 px-4 text-body text-gosign-text">BSI IT-Grundschutz</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Cookie-Konfiguration</td>
<td class="py-3 px-4 text-body text-gosign-text">Secure-Flag, HttpOnly, SameSite</td>
<td class="py-3 px-4 text-body text-gosign-text">DSGVO + BSI</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Authentifizierung</td>
<td class="py-3 px-4 text-body text-gosign-text">Login-Schutz, Brute-Force-Prevention, 2FA</td>
<td class="py-3 px-4 text-body text-gosign-text">BSI IT-Grundschutz</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Datensicherung</td>
<td class="py-3 px-4 text-body text-gosign-text">Backup-Strategie, Recovery-Testung</td>
<td class="py-3 px-4 text-body text-gosign-text">BSI IT-Grundschutz</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Leistungen -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">Leistungen</h2>
<div class="grid md:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Einmaliger Security-Check</h3>
<p class="text-body text-gosign-text">
Automatisierte + manuelle Prüfung. Ergebnisbericht mit Handlungsempfehlungen, priorisiert nach Risiko. KI-beschleunigt: Ergebnisse in Stunden, nicht Wochen.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Kontinuierliches Monitoring</h3>
<p class="text-body text-gosign-text">
Laufende Überwachung von CMS, Extensions, Server-Konfiguration. Sofortige Benachrichtigung bei neuen Schwachstellen.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Härtung &amp; Implementierung</h3>
<p class="text-body text-gosign-text">
Gosign setzt die empfohlenen Maßnahmen um: CSP-Header, TLS-Konfiguration, WAF-Setup, CMS-Härtung.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Dokumentation für Audits</h3>
<p class="text-body text-gosign-text">
BSI IT-Grundschutz-konforme Dokumentation Ihrer Website-Sicherheitsmaßnahmen. Für interne Audits und externe Prüfer.
</p>
</div>
</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Website-Sicherheit prüfen lassen, 30&nbsp;Minuten, kostenlos.</h3>
<p class="text-body text-gosign-text mb-6">Wir analysieren Ihre Website auf BSI-relevante Schwachstellen, unverbindlich.</p>
<a
href="/de/kontakt/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Security-Check anfragen
</a>
<p class="text-small text-gosign-text-light mt-4">25 Jahre Erfahrung · 800+ Extensions · KI-beschleunigte Entwicklung</p>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
Gosign ist eine Hamburger Digitalagentur mit 25 Jahren Erfahrung in Webentwicklung, TYPO3 und KI-Integration.
Wir haben über 800 TYPO3 Extensions analysiert und entwickeln heute mit KI-Unterstützung
bis zu 70&nbsp;% schneller als mit klassischen Methoden. Unsere Kunden sind mittelständische
Unternehmen, Hochschulen und öffentliche Einrichtungen in Deutschland.
</p>
<p class="text-small text-gosign-text-light mt-2">Stand: Februar 2026</p>
</div>
</section>

<!-- Verwandte Themen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Verwandte Themen</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/de/website-gehackt-10-gruende/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Notfall</p>
<p class="text-body font-semibold text-gosign-dark">Website gehackt: 10 Gründe & Soforthilfe</p>
</a>
<a href="/de/typo3-sicherheitsmonitor/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Security</p>
<p class="text-body font-semibold text-gosign-dark">TYPO3 Sicherheitsmonitor</p>
</a>
<a href="/de/typo3-extensions/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">TYPO3</p>
<p class="text-body font-semibold text-gosign-dark">TYPO3 Extensions: Entwicklung & Monitoring</p>
</a>
</div>
</div>
</section>

--- Website mit KI erstellen | Whitepaper ---
> Whitepaper: Vom Webdesign zum funktionierenden WordPress-Theme mit KI. Praxisleitfaden von Gosign.

<!-- Was behandelt dieses Whitepaper? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Was behandelt dieses Whitepaper?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Dieses Whitepaper von Gosign zeigt den kompletten Workflow einer Website-Erstellung mit KI-Unterstützung: Von der Konzeption über das Webdesign bis zum funktionierenden WordPress-Theme. Kein theoretischer Überblick, sondern ein Praxisleitfaden mit konkreten Tools, Prompts und Ergebnissen aus realen Kundenprojekten.
</p>
</div>
</section>

<!-- Inhaltsübersicht -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">Inhaltsübersicht</h2>

<div class="space-y-8">
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">1. KI im Webdesign-Prozess</h3>
<p class="text-body text-gosign-text leading-relaxed">
Layout-Generierung, Moodboard-Erstellung, Wireframe-zu-Design mit KI-Tools. Was funktioniert, was nicht, wo menschliches Design-Urteil unverzichtbar bleibt.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">2. Vom Design zum Code</h3>
<p class="text-body text-gosign-text leading-relaxed">
KI-gestützte Umsetzung von Figma/Sketch-Designs in HTML/CSS/PHP. Wie Gosign mit KI Theme-Grundgerüste generiert und Senior-Entwickler den Output veredeln.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">3. WordPress-Theme-Entwicklung mit KI</h3>
<p class="text-body text-gosign-text leading-relaxed">
Custom Gutenberg Blocks, Full Site Editing Templates, functions.php-Logik, was KI in Minuten generiert, was vorher Tage brauchte. Konkreter Vorher-Nachher-Vergleich.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">4. Qualitätssicherung</h3>
<p class="text-body text-gosign-text leading-relaxed">
KI generiert Code, aber wer prüft die Qualität? Gosigns QA-Prozess: Automatisierte Tests, Accessibility-Checks, Performance-Audits, manuelles Code-Review.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">5. Ergebnisse aus der Praxis</h3>
<p class="text-body text-gosign-text leading-relaxed">
Zeitersparnis-Daten aus echten Gosign-Projekten: 60 - 80&nbsp;% schneller. Wo genau die Zeit gespart wird und wo nicht.
</p>
</div>
</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Sie wollen KI in Ihrem nächsten Web-Projekt einsetzen?</h3>
<p class="text-body text-gosign-text mb-6">30 Minuten Erstgespräch, kostenlos und unverbindlich.</p>
<a
href="/de/kontakt/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Erstgespräch buchen
</a>
<p class="text-small text-gosign-text-light mt-4">25 Jahre Erfahrung · 800+ Extensions · KI-beschleunigte Entwicklung</p>
</div>
</section>

<!-- Für wen? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Für wen ist dieses Whitepaper?</h2>
<ul class="space-y-3">
<li class="flex items-start gap-3">
<span class="flex-shrink-0 mt-1.5 w-2 h-2 bg-gosign-accent rounded-full"></span>
<span class="text-body text-gosign-text">Projektleiter und Product Owner, die Web-Projekte schneller und günstiger umsetzen wollen</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 mt-1.5 w-2 h-2 bg-gosign-accent rounded-full"></span>
<span class="text-body text-gosign-text">Marketing-Verantwortliche, die KI-gestützte Website-Erstellung evaluieren</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 mt-1.5 w-2 h-2 bg-gosign-accent rounded-full"></span>
<span class="text-body text-gosign-text">Entwickler, die KI in ihren Workflow integrieren wollen</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 mt-1.5 w-2 h-2 bg-gosign-accent rounded-full"></span>
<span class="text-body text-gosign-text">Geschäftsführer, die ROI von KI-Investitionen in der Webentwicklung verstehen wollen</span>
</li>
</ul>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
Gosign ist eine Hamburger Digitalagentur mit 25 Jahren Erfahrung in Webentwicklung, TYPO3 und KI-Integration.
Wir haben über 800 TYPO3 Extensions analysiert und entwickeln heute mit KI-Unterstützung
bis zu 70&nbsp;% schneller als mit klassischen Methoden. Unsere Kunden sind mittelständische
Unternehmen, Hochschulen und öffentliche Einrichtungen in Deutschland.
</p>
<p class="text-small text-gosign-text-light mt-2">Stand: Februar 2026</p>
</div>
</section>

<!-- Verwandte Themen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Verwandte Themen</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/de/digitalagentur-hamburg/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Agentur</p>
<p class="text-body font-semibold text-gosign-dark">Digitalagentur Hamburg</p>
</a>
<a href="/de/wordpress-agentur/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Webentwicklung</p>
<p class="text-body font-semibold text-gosign-dark">WordPress Agentur Hamburg</p>
</a>
<a href="/de/website-sicherheit-bsi/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Sicherheit</p>
<p class="text-body font-semibold text-gosign-dark">Website-Sicherheit nach BSI-Gesetz</p>
</a>
</div>
</div>
</section>

--- Barrierefreiheit & BFSG 2025 ---
> BFSG seit Juni 2025 in Kraft. Wer ist betroffen, was bedeutet barrierefreie Website und welche Bußgelder drohen? Verständlich erklärt.

<!-- Was ist das BFSG? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Was ist das BFSG und warum gibt es dieses Gesetz?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Das Barrierefreiheitsstärkungsgesetz (BFSG) setzt die europäische Richtlinie 2019/882 - den European Accessibility Act - in deutsches Recht um. Die EU hat damit einen einheitlichen Rahmen geschaffen: Produkte und Dienstleistungen, die Verbrauchern angeboten werden, müssen für Menschen mit Behinderungen zugänglich sein.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Das betrifft unter anderem Websites und Online-Shops. Das Ziel ist einfach: Wer im Internet etwas kaufen, buchen oder sich informieren will, soll das unabhängig von einer Seh-, Hör- oder Motorik-Einschränkung tun können. Seit dem <strong>28. Juni 2025</strong> ist das BFSG geltendes Recht - Verstöße können mit Bußgeldern geahndet werden.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Für Unternehmen bedeutet das: Barrierefreiheit ist keine freiwillige Leistung mehr, sondern eine Pflicht. Vergleichbar mit der <a href="/de/wissen/dsgvo-pflichten-websites/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">DSGVO bei Datenschutz</a> - wer die Regeln nicht kennt, riskiert Strafen.
</p>
</div>
</section>

<!-- Wer ist betroffen? -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Betrifft mich das BFSG? Entscheidungshilfe nach Rechtsform</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
Das BFSG gilt für <strong>Wirtschaftsakteure</strong>, die Produkte oder Dienstleistungen für Verbraucher auf den Markt bringen. Ob Sie betroffen sind, hängt weniger von der Rechtsform ab und mehr davon, was Sie tun.
</p>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse bg-white rounded-card">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Rechtsform / Situation</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">BFSG-Pflicht?</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Erklärung</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">GmbH / AG mit Online-Shop</td>
<td class="py-3 px-4 text-body text-gosign-accent-text font-semibold">Ja</td>
<td class="py-3 px-4 text-body text-gosign-text">Online-Handel ist eine Dienstleistung für Verbraucher. Volle BFSG-Pflicht.</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">GmbH / AG mit reiner B2B-Website</td>
<td class="py-3 px-4 text-body text-gosign-text font-semibold">Nein (formal)</td>
<td class="py-3 px-4 text-body text-gosign-text">Das BFSG erfasst nur Verbraucher-Dienstleistungen. Rein geschäftliche Portale sind ausgenommen - Barrierefreiheit bleibt dennoch empfehlenswert.</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Gemeinnützige Stiftung</td>
<td class="py-3 px-4 text-body text-gosign-text font-semibold">In der Regel nein</td>
<td class="py-3 px-4 text-body text-gosign-text">Gemeinnützige Stiftungen sind meist nicht erfasst. Aber: Fördergeber verlangen zunehmend Barrierefreiheit, und Stiftungen mit kommerziellem Angebot (Tickets, Shop) können betroffen sein.</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Kleinstunternehmen (< 10 MA, < 2 Mio. EUR)</td>
<td class="py-3 px-4 text-body text-gosign-text font-semibold">Ausnahme möglich</td>
<td class="py-3 px-4 text-body text-gosign-text">Kleinstunternehmen mit weniger als 10 Beschäftigten und unter 2 Mio. EUR Jahresumsatz sind bei Dienstleistungen vom BFSG ausgenommen.</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Verein / Verband mit Website</td>
<td class="py-3 px-4 text-body text-gosign-text font-semibold">Kommt darauf an</td>
<td class="py-3 px-4 text-body text-gosign-text">Nicht-wirtschaftliche Vereine sind meist nicht erfasst. Bietet der Verein aber kostenpflichtige Online-Dienstleistungen an, greift das BFSG.</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Öffentliche Stelle / Behörde</td>
<td class="py-3 px-4 text-body text-gosign-accent-text font-semibold">Ja (über BITV)</td>
<td class="py-3 px-4 text-body text-gosign-text">Behörden fallen nicht unter das BFSG, aber unter die BITV 2.0 - mit ähnlichen Anforderungen, bereits seit 2019 verpflichtend.</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Kleinstunternehmer-Ausnahme -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Die Kleinstunternehmer-Ausnahme: Wann greift sie?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Das BFSG sieht eine Ausnahme für Kleinstunternehmen vor: Unternehmen mit <strong>weniger als 10 Beschäftigten</strong> und einem <strong>Jahresumsatz oder einer Bilanzsumme unter 2 Millionen Euro</strong> sind bei Dienstleistungen von der Pflicht ausgenommen.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Aber Vorsicht: Diese Ausnahme gilt nur für <em>Dienstleistungen</em>, nicht für Produkte. Wer als Kleinstunternehmen physische Produkte verkauft (z.B. einen Online-Shop für Elektronik betreibt), ist trotzdem an die BFSG-Produktanforderungen gebunden.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Außerdem ist Barrierefreiheit unabhängig von der gesetzlichen Pflicht oft wirtschaftlich sinnvoll. Eine Website, die schwer zu bedienen ist, verliert Kunden - nicht nur solche mit Behinderung. Klare Struktur, gute Kontraste und lesbare Schrift helfen allen Besuchern.
</p>
</div>
</section>

<!-- Was bedeutet barrierefrei? -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Was bedeutet "barrierefreie Website" konkret?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Barrierefreiheit klingt abstrakt - ist aber sehr praktisch. Es geht darum, dass alle Menschen Ihre Website nutzen können. Drei einfache Beispiele:
</p>
<ul class="mt-4 space-y-3">
<li class="flex items-start gap-3">
<span class="text-gosign-accent-text font-bold mt-0.5">1.</span>
<p class="text-body text-gosign-text">
<strong>Ein blinder Mensch nutzt einen Screenreader</strong> - ein Programm, das den Bildschirminhalt vorliest. Wenn Ihre Bilder keine Beschreibungstexte (Alt-Texte) haben, hört die Person nur "Grafik, Grafik, Grafik" - und versteht nichts.
</p>
</li>
<li class="flex items-start gap-3">
<span class="text-gosign-accent-text font-bold mt-0.5">2.</span>
<p class="text-body text-gosign-text">
<strong>Ein Mensch mit Sehschwäche braucht gute Kontraste.</strong> Hellgrauer Text auf weißem Hintergrund ist für 7 Millionen Deutsche mit Sehbeeinträchtigung kaum lesbar. Die WCAG fordert ein Kontrastverhältnis von mindestens 4,5:1.
</p>
</li>
<li class="flex items-start gap-3">
<span class="text-gosign-accent-text font-bold mt-0.5">3.</span>
<p class="text-body text-gosign-text">
<strong>Ein Mensch mit motorischer Einschränkung kann keine Maus bedienen.</strong> Wenn Ihre Website nur per Mausklick funktioniert, ist sie für diese Person gesperrt. Alles muss auch per Tastatur erreichbar sein.
</p>
</li>
</ul>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Gute Barrierefreiheit verbessert gleichzeitig die <a href="/de/wissen/schema-org-seo-grundlagen/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">Suchmaschinenoptimierung</a>: Alt-Texte, klare Überschriften und sauberer Code helfen Google genauso wie einem Screenreader.
</p>
</div>
</section>

<!-- WCAG 2.2 AA: Die vier Prinzipien -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">WCAG 2.2 AA: Die vier Prinzipien in einfacher Sprache</h2>
<p class="text-body text-gosign-text leading-relaxed mb-8">
Die WCAG (Web Content Accessibility Guidelines) sind der internationale Standard für Barrierefreiheit im Web. Das BFSG verlangt die Einhaltung der Stufe AA. Die WCAG basiert auf vier Grundprinzipien:
</p>
<div class="grid md:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<div class="flex items-center gap-3 mb-3">
<svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor">
<path stroke-linecap="round" stroke-linejoin="round" d="M2.036 12.322a1.012 1.012 0 0 1 0-.639C3.423 7.51 7.36 4.5 12 4.5c4.638 0 8.573 3.007 9.963 7.178.07.207.07.431 0 .639C20.577 16.49 16.64 19.5 12 19.5c-4.638 0-8.573-3.007-9.963-7.178Z" />
<path stroke-linecap="round" stroke-linejoin="round" d="M15 12a3 3 0 1 1-6 0 3 3 0 0 1 6 0Z" />
</svg>
<h3 class="text-h3 font-bold text-gosign-dark">Wahrnehmbar</h3>
</div>
<p class="text-body text-gosign-text">
Inhalte müssen für alle Sinne verfügbar sein. Bilder brauchen Beschreibungen, Videos brauchen Untertitel. Kontraste müssen ausreichend sein. Wer nicht sehen kann, muss Inhalte hören oder ertasten können.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<div class="flex items-center gap-3 mb-3">
<svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor">
<path stroke-linecap="round" stroke-linejoin="round" d="M3.75 3.75v4.5m0-4.5h4.5m-4.5 0L9 9M3.75 20.25v-4.5m0 4.5h4.5m-4.5 0L9 15M20.25 3.75h-4.5m4.5 0v4.5m0-4.5L15 9m5.25 11.25h-4.5m4.5 0v-4.5m0 4.5L15 15" />
</svg>
<h3 class="text-h3 font-bold text-gosign-dark">Bedienbar</h3>
</div>
<p class="text-body text-gosign-text">
Alle Funktionen müssen per Tastatur erreichbar sein - nicht nur per Maus. Navigation muss logisch sein. Nutzer brauchen genug Zeit zum Lesen und Bedienen. Keine blinkenden Inhalte, die Anfälle auslösen können.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<div class="flex items-center gap-3 mb-3">
<svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor">
<path stroke-linecap="round" stroke-linejoin="round" d="M12 6.042A8.967 8.967 0 0 0 6 3.75c-1.052 0-2.062.18-3 .512v14.25A8.987 8.987 0 0 1 6 18c2.305 0 4.408.867 6 2.292m0-14.25a8.966 8.966 0 0 1 6-2.292c1.052 0 2.062.18 3 .512v14.25A8.987 8.987 0 0 0 18 18a8.967 8.967 0 0 0-6 2.292m0-14.25v14.25" />
</svg>
<h3 class="text-h3 font-bold text-gosign-dark">Verständlich</h3>
</div>
<p class="text-body text-gosign-text">
Texte müssen lesbar sein. Formulare müssen verständliche Beschriftungen haben. Fehlermeldungen müssen erklären, was schief ging. Die Website darf sich nicht unerwartet verhalten (z.B. plötzlich neue Fenster öffnen).
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<div class="flex items-center gap-3 mb-3">
<svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor">
<path stroke-linecap="round" stroke-linejoin="round" d="M9 17.25v1.007a3 3 0 0 1-.879 2.122L7.5 21h9l-.621-.621A3 3 0 0 1 15 18.257V17.25m6-12V15a2.25 2.25 0 0 1-2.25 2.25H5.25A2.25 2.25 0 0 1 3 15V5.25m18 0A2.25 2.25 0 0 0 18.75 3H5.25A2.25 2.25 0 0 0 3 5.25m18 0V12a2.25 2.25 0 0 1-2.25 2.25H5.25A2.25 2.25 0 0 1 3 12V5.25" />
</svg>
<h3 class="text-h3 font-bold text-gosign-dark">Robust</h3>
</div>
<p class="text-body text-gosign-text">
Der Code muss sauber sein, damit unterschiedliche Browser und Hilfstechnologien (Screenreader, Braillezeile, Sprachsteuerung) den Inhalt korrekt interpretieren können. Standards-konformes HTML ist die Grundlage.
</p>
</div>
</div>
</div>
</section>

<!-- Barrierefreiheitserklärung -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Barrierefreiheitserklärung: Was muss drinstehen?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Das BFSG verlangt eine öffentlich zugängliche Barrierefreiheitserklärung auf Ihrer Website. Diese Erklärung ist vergleichbar mit der Datenschutzerklärung - sie informiert Besucher über den aktuellen Stand der Barrierefreiheit. Folgende Angaben sind Pflicht:
</p>
<ul class="mt-4 space-y-2">
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text flex-shrink-0 mt-0.5" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor">
<path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" />
</svg>
<p class="text-body text-gosign-text">Welche Teile der Website barrierefrei sind und welche nicht</p>
</li>
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text flex-shrink-0 mt-0.5" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor">
<path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" />
</svg>
<p class="text-body text-gosign-text">Begründung für noch bestehende Einschränkungen</p>
</li>
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text flex-shrink-0 mt-0.5" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor">
<path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" />
</svg>
<p class="text-body text-gosign-text">Kontaktmöglichkeit für Feedback (E-Mail, Telefon oder Formular)</p>
</li>
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text flex-shrink-0 mt-0.5" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor">
<path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" />
</svg>
<p class="text-body text-gosign-text">Verweis auf die zuständige Marktüberwachungsbehörde</p>
</li>
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text flex-shrink-0 mt-0.5" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor">
<path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" />
</svg>
<p class="text-body text-gosign-text">Datum der letzten Prüfung</p>
</li>
</ul>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Die Erklärung sollte leicht auffindbar sein - idealerweise im Footer verlinkt, ähnlich wie Impressum und Datenschutzerklärung.
</p>
</div>
</section>

<!-- Warum lohnt sich Barrierefreiheit? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Warum sich Barrierefreiheit auch ohne Pflicht lohnt</h2>
<p class="text-body text-gosign-text leading-relaxed">
Selbst wenn Ihr Unternehmen formal nicht unter das BFSG fällt, gibt es gute Gründe für barrierefreie Websites:
</p>
<div class="grid md:grid-cols-2 gap-6 mt-6">
<div class="border border-gosign-border rounded-card p-6">
<div class="flex items-center gap-3 mb-3">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor">
<path stroke-linecap="round" stroke-linejoin="round" d="M18 18.72a9.094 9.094 0 0 0 3.741-.479 3 3 0 0 0-4.682-2.72m.94 3.198.001.031c0 .225-.012.447-.037.666A11.944 11.944 0 0 1 12 21c-2.17 0-4.207-.576-5.963-1.584A6.062 6.062 0 0 1 6 18.719m12 0a5.971 5.971 0 0 0-.941-3.197m0 0A5.995 5.995 0 0 0 12 12.75a5.995 5.995 0 0 0-5.058 2.772m0 0a3 3 0 0 0-4.681 2.72 8.986 8.986 0 0 0 3.74.477m.94-3.197a5.971 5.971 0 0 0-.94 3.197M15 6.75a3 3 0 1 1-6 0 3 3 0 0 1 6 0Zm6 3a2.25 2.25 0 1 1-4.5 0 2.25 2.25 0 0 1 4.5 0Zm-13.5 0a2.25 2.25 0 1 1-4.5 0 2.25 2.25 0 0 1 4.5 0Z" />
</svg>
<h3 class="text-h3 font-bold text-gosign-dark">Mehr Reichweite</h3>
</div>
<p class="text-body text-gosign-text">
10 Millionen Menschen in Deutschland leben mit einer Behinderung. Dazu kommen Millionen älterer Menschen mit nachlassender Sehkraft oder Motorik. Barrierefreie Websites erreichen mehr Menschen.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<div class="flex items-center gap-3 mb-3">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor">
<path stroke-linecap="round" stroke-linejoin="round" d="m21 21-5.197-5.197m0 0A7.5 7.5 0 1 0 5.196 5.196a7.5 7.5 0 0 0 10.607 10.607Z" />
</svg>
<h3 class="text-h3 font-bold text-gosign-dark">Besseres SEO</h3>
</div>
<p class="text-body text-gosign-text">
Google bewertet barrierefreie Websites besser. Alt-Texte, saubere Überschriftenstruktur und schnelle Ladezeiten sind sowohl Barrierefreiheits- als auch SEO-Faktoren.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<div class="flex items-center gap-3 mb-3">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor">
<path stroke-linecap="round" stroke-linejoin="round" d="M12 6v12m-3-2.818.879.659c1.171.879 3.07.879 4.242 0 1.172-.879 1.172-2.303 0-3.182C13.536 12.219 12.768 12 12 12c-.725 0-1.45-.22-2.003-.659-1.106-.879-1.106-2.303 0-3.182s2.9-.879 4.006 0l.415.33M21 12a9 9 0 1 1-18 0 9 9 0 0 1 18 0Z" />
</svg>
<h3 class="text-h3 font-bold text-gosign-dark">Fördergeber-Anforderungen</h3>
</div>
<p class="text-body text-gosign-text">
Viele öffentliche Förderprogramme und Stiftungen verlangen barrierefreie Kommunikation. Wer Fördermittel beantragt oder öffentliche Aufträge annimmt, wird zunehmend nach Barrierefreiheit gefragt.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<div class="flex items-center gap-3 mb-3">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor">
<path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75M21 12c0 1.268-.63 2.39-1.593 3.068a3.745 3.745 0 0 1-1.043 3.296 3.745 3.745 0 0 1-3.296 1.043A3.745 3.745 0 0 1 12 21c-1.268 0-2.39-.63-3.068-1.593a3.746 3.746 0 0 1-3.296-1.043 3.745 3.745 0 0 1-1.043-3.296A3.745 3.745 0 0 1 3 12c0-1.268.63-2.39 1.593-3.068a3.745 3.745 0 0 1 1.043-3.296 3.746 3.746 0 0 1 3.296-1.043A3.746 3.746 0 0 1 12 3c1.268 0 2.39.63 3.068 1.593a3.746 3.746 0 0 1 3.296 1.043 3.745 3.745 0 0 1 1.043 3.296A3.745 3.745 0 0 1 21 12Z" />
</svg>
<h3 class="text-h3 font-bold text-gosign-dark">Image und Vertrauen</h3>
</div>
<p class="text-body text-gosign-text">
Barrierefreiheit zeigt gesellschaftliche Verantwortung. Für Stiftungen, NGOs und Unternehmen mit ESG-Zielen ist das ein echtes Argument bei Stakeholdern und in der Öffentlichkeit.
</p>
</div>
</div>
</div>
</section>

<!-- Bußgelder -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Bußgelder bis 100.000 EUR - was droht bei Verstößen?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Das BFSG sieht Bußgelder von bis zu <strong>100.000 Euro</strong> vor. Die Marktüberwachungsbehörden der Bundesländer sind für die Durchsetzung zuständig. Konkret drohen Sanktionen bei:
</p>
<ul class="mt-4 space-y-2">
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text flex-shrink-0 mt-0.5" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor">
<path stroke-linecap="round" stroke-linejoin="round" d="M12 9v3.75m-9.303 3.376c-.866 1.5.217 3.374 1.948 3.374h14.71c1.73 0 2.813-1.874 1.948-3.374L13.949 3.378c-.866-1.5-3.032-1.5-3.898 0L2.697 16.126ZM12 15.75h.007v.008H12v-.008Z" />
</svg>
<p class="text-body text-gosign-text">Fehlender oder unzureichender Barrierefreiheit bei BFSG-pflichtigen Dienstleistungen</p>
</li>
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text flex-shrink-0 mt-0.5" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor">
<path stroke-linecap="round" stroke-linejoin="round" d="M12 9v3.75m-9.303 3.376c-.866 1.5.217 3.374 1.948 3.374h14.71c1.73 0 2.813-1.874 1.948-3.374L13.949 3.378c-.866-1.5-3.032-1.5-3.898 0L2.697 16.126ZM12 15.75h.007v.008H12v-.008Z" />
</svg>
<p class="text-body text-gosign-text">Fehlender Barrierefreiheitserklärung auf der Website</p>
</li>
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text flex-shrink-0 mt-0.5" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor">
<path stroke-linecap="round" stroke-linejoin="round" d="M12 9v3.75m-9.303 3.376c-.866 1.5.217 3.374 1.948 3.374h14.71c1.73 0 2.813-1.874 1.948-3.374L13.949 3.378c-.866-1.5-3.032-1.5-3.898 0L2.697 16.126ZM12 15.75h.007v.008H12v-.008Z" />
</svg>
<p class="text-body text-gosign-text">Nichtbeachtung von Anordnungen der Marktüberwachungsbehörde</p>
</li>
</ul>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Zusätzlich können Verbraucherschutzverbände Unterlassungsklagen erheben. Das Risiko beschränkt sich also nicht auf Bußgelder - auch Abmahnungen und negative Öffentlichkeit sind möglich. Ähnlich wie bei der <a href="/de/website-sicherheit-bsi/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">BSI-konformen Website-Sicherheit</a> gilt: Vorsorge ist günstiger als Nachsorge.
</p>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Barrierefreiheits-Check: 30&nbsp;Minuten, kostenlos.</h3>
<p class="text-body text-gosign-text mb-6">Wir prüfen Ihre Website auf die wichtigsten WCAG-Kriterien - unverbindlich und verständlich erklärt.</p>
<a
href="/de/kontakt/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Barrierefreiheits-Check anfragen
</a>
<p class="text-small text-gosign-text-light mt-4">25 Jahre Erfahrung · Lighthouse 100/100 · WCAG 2.2 AA</p>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
Gosign ist eine Hamburger Digitalagentur mit 25 Jahren Erfahrung in Webentwicklung und KI-Integration.
Unsere eigene Website erreicht in allen vier Lighthouse-Kategorien den Wert 100/100 - einschließlich
Accessibility. Wir helfen mittelständischen Unternehmen, Stiftungen und öffentlichen Einrichtungen
dabei, ihre Websites barrierefrei und gesetzeskonform zu gestalten.
</p>
<p class="text-small text-gosign-text-light mt-2">Stand: März 2026</p>
</div>
</section>

<!-- Verwandte Themen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Verwandte Themen</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/de/wissen/dsgvo-pflichten-websites/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Recht</p>
<p class="text-body font-semibold text-gosign-dark">DSGVO-Pflichten für Websites</p>
</a>
<a href="/de/wissen/website-ohne-cookie-banner/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Datenschutz</p>
<p class="text-body font-semibold text-gosign-dark">Website ohne Cookie-Banner</p>
</a>
<a href="/de/wissen/typo3-updates-sicherheit/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">TYPO3</p>
<p class="text-body font-semibold text-gosign-dark">TYPO3-Updates & Sicherheit</p>
</a>
</div>
</div>
</section>

--- DSGVO-Pflichten für Websites ---
> Was müssen Websites datenschutzrechtlich erfüllen? DSGVO, Cookie-Consent, Datenschutzerklärung - verständlich erklärt für Geschäftsführer.

<!-- Was ist eine Datenschutzerklärung? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Was ist eine Datenschutzerklärung - und warum braucht jede Website eine?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Eine Datenschutzerklärung informiert Besucher Ihrer Website darüber, welche personenbezogenen Daten erhoben werden, warum das geschieht und welche Rechte die Betroffenen haben. Das klingt abstrakt, ist aber konkret: Schon wenn jemand Ihre Website aufruft, speichert der Server eine IP-Adresse. Das ist ein personenbezogenes Datum. Damit fällt jede Website unter die DSGVO.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Die Datenschutz-Grundverordnung (DSGVO) gilt seit Mai 2018 in der gesamten EU. Sie verpflichtet jeden Website-Betreiber - ob Konzern, Mittelständler, Verein oder Stiftung - zu einer vollständigen Datenschutzerklärung. Fehlt sie oder ist sie veraltet, drohen Abmahnungen und Bußgelder.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Wichtig: Eine Datenschutzerklärung ist nicht dasselbe wie ein Impressum. Das Impressum regelt, wer für die Website verantwortlich ist (nach dem Digitale-Dienste-Gesetz, DDG). Die Datenschutzerklärung regelt, wie mit Daten umgegangen wird (nach der DSGVO). Beides ist Pflicht, beides muss separat vorhanden sein.
</p>
</div>
</section>

<!-- Häufigste Fehler -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Die häufigsten Fehler bei Datenschutzerklärungen</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
In unserer Praxis sehen wir immer wieder dieselben Probleme. Viele davon sind leicht vermeidbar - wenn man weiß, worauf es ankommt.
</p>
<div class="grid md:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Veraltete Vorlagen</h3>
<p class="text-body text-gosign-text">
Viele Websites nutzen noch Datenschutzerklärungen von 2018 oder früher. Seitdem haben sich Gesetze geändert (TTDSG wurde zum TDDDG, neue Urteile zu Google Fonts und Analytics). Eine Vorlage von vor drei Jahren ist fast sicher nicht mehr rechtskonform.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Fehlende Angaben</h3>
<p class="text-body text-gosign-text">
Die DSGVO verlangt konkrete Informationen: Name des Verantwortlichen, Kontakt des Datenschutzbeauftragten (falls vorhanden), Rechtsgrundlagen für jede Datenverarbeitung, Speicherdauer und Betroffenenrechte. Fehlt eines davon, ist die Erklärung unvollständig.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Copy-Paste ohne Anpassung</h3>
<p class="text-body text-gosign-text">
Eine Datenschutzerklärung muss zur eigenen Website passen. Wer Google Analytics einsetzt, aber nur Facebook Pixel erwähnt, hat ein Problem. Wer gar keine Analyse-Tools nutzt, aber trotzdem drei Absätze darüber schreibt, ebenfalls.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Leere oder versteckte Seiten</h3>
<p class="text-body text-gosign-text">
Manche Websites haben zwar einen Link zur Datenschutzerklärung im Footer, aber die Seite dahinter ist leer oder führt ins Nichts. Aufsichtsbehörden prüfen das systematisch - und Abmahnanwälte erst recht.
</p>
</div>
</div>
</div>
</section>

<!-- Cookie-Consent -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Cookie-Consent: Warum ein einfacher Hinweis nicht reicht</h2>
<p class="text-body text-gosign-text leading-relaxed">
Cookies sind kleine Textdateien, die Websites auf dem Gerät des Besuchers speichern. Manche sind technisch notwendig (zum Beispiel für den Warenkorb in einem Online-Shop). Andere dienen der Analyse oder dem Marketing - und genau hier wird es rechtlich relevant.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Das Telekommunikation-Digitale-Dienste-Datenschutz-Gesetz (TDDDG, früher TTDSG) schreibt vor: Bevor nicht-essentielle Cookies gesetzt werden, muss der Besucher aktiv einwilligen. Das bedeutet: Ein Banner mit dem Text "Diese Website verwendet Cookies - OK" genügt nicht. Der Besucher muss eine echte Wahl haben - mit der Möglichkeit, einzelne Kategorien abzulehnen.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
In der Praxis brauchen Sie ein sogenanntes Consent Management Tool (CMP). Dieses Tool zeigt beim ersten Besuch ein Cookie-Banner mit mindestens zwei Optionen: "Alle akzeptieren" und "Nur notwendige". Erst nach der Einwilligung dürfen Tracking-Cookies gesetzt werden. Ohne funktionierendes CMP ist jedes Tracking auf Ihrer Website rechtswidrig.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Übrigens: Auch eingebettete YouTube-Videos, Google Maps oder Social-Media-Buttons setzen Cookies. Wer solche Inhalte einbindet, braucht entweder eine Einwilligung oder eine Zwei-Klick-Lösung, die erst nach Zustimmung lädt. Das Thema <a href="/de/website-sicherheit-bsi/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">Website-Sicherheit</a> hängt direkt damit zusammen - denn unsichere Einbindungen können auch Datenschutzprobleme verursachen.
</p>
</div>
</section>

<!-- Cookie-Banner vermeiden -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<div class="border-2 border-gosign-accent/20 rounded-card p-6 bg-white">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Die bessere Lösung: Gar kein Cookie-Banner brauchen</h2>
<p class="text-body text-gosign-text leading-relaxed">
Es gibt eine Alternative zum Cookie-Banner-Dilemma: Bauen Sie Ihre Website so, dass sie <strong>gar keine nicht-essentiellen Cookies setzt</strong>. Kein Tracking, keine externen Fonts, keine Third-Party-Embeds - dann brauchen Sie weder Banner noch CMP. Das spart Geld (CMP-Tools kosten 50-500 EUR/Monat), verbessert die Ladezeit und macht die DSGVO-Konformität trivial.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Klingt unrealistisch? gosign.de selbst ist der Beweis: Null Cookies, null Banner, Lighthouse 100/100, volle Analyse über cookielose Tools. Was dahinter steckt und wie das auch für Ihre Website funktioniert, erklären wir im Detail:
</p>
<a
href="/de/wissen/website-ohne-cookie-banner/"
class="inline-flex items-center gap-2 mt-4 text-gosign-accent-text font-semibold hover:text-gosign-accent transition-colors"
>
<span>Website ohne Cookie-Banner - so geht's</span>
<svg class="w-5 h-5" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M13.5 4.5 21 12m0 0-7.5 7.5M21 12H3" /></svg>
</a>
</div>
</div>
</section>

<!-- DSGVO vs. TDDDG vs. DDG -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">DSGVO, TDDDG, DDG - welches Gesetz gilt wofür?</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
Drei Gesetze, drei Zuständigkeiten. Für Website-Betreiber ist es wichtig, den Unterschied zu kennen - denn Verstöße gegen jedes einzelne können separat geahndet werden.
</p>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse bg-white rounded-card">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Gesetz</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Regelt</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Pflicht für Websites</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">DSGVO</td>
<td class="py-3 px-4 text-body text-gosign-text">Verarbeitung personenbezogener Daten</td>
<td class="py-3 px-4 text-body text-gosign-text">Datenschutzerklärung, Verarbeitungsverzeichnis, Betroffenenrechte</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">TDDDG</td>
<td class="py-3 px-4 text-body text-gosign-text">Zugriff auf Endgeräte (Cookies, Fingerprinting)</td>
<td class="py-3 px-4 text-body text-gosign-text">Cookie-Consent vor nicht-essentiellen Cookies</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">DDG</td>
<td class="py-3 px-4 text-body text-gosign-text">Informationspflichten digitaler Dienste</td>
<td class="py-3 px-4 text-body text-gosign-text">Impressum mit vollständigen Anbieterangaben</td>
</tr>
</tbody>
</table>
</div>
<p class="text-body text-gosign-text leading-relaxed mt-6">
Die DSGVO ist eine EU-Verordnung und gilt unmittelbar. Das TDDDG (Telekommunikation-Digitale-Dienste-Datenschutz-Gesetz, bis 2024 noch TTDSG) ist ein deutsches Gesetz und regelt speziell den Zugriff auf Endgeräte. Das DDG (Digitale-Dienste-Gesetz) ersetzt seit 2024 das alte TMG und regelt unter anderem die Impressumspflicht. Alle drei Gesetze gelten parallel - und alle drei müssen erfüllt sein.
</p>
</div>
</section>

<!-- Sonderfall Stiftungen -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Sonderfall Stiftungen und gemeinnützige Organisationen</h2>
<p class="text-body text-gosign-text leading-relaxed">
Ein verbreiteter Irrtum: Stiftungen, Vereine und gemeinnützige Organisationen seien von der DSGVO ausgenommen. Das stimmt nicht. Die DSGVO gilt für jede Organisation, die personenbezogene Daten verarbeitet - unabhängig von der Rechtsform oder dem Zweck.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
In der Praxis bedeutet das: Auch die Website einer Bürgerstiftung, eines Fördervereins oder einer kirchlichen Einrichtung braucht eine vollständige Datenschutzerklärung, ein rechtskonformes Cookie-Banner und ein korrektes Impressum. Die Anforderungen sind identisch mit denen eines Wirtschaftsunternehmens.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Es gibt allerdings Erleichterungen bei der internen Organisation: Organisationen mit weniger als 20 Mitarbeitern, die regelmäßig personenbezogene Daten verarbeiten, müssen keinen Datenschutzbeauftragten benennen. Die Pflichten gegenüber Website-Besuchern bleiben davon aber unberührt.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Gerade bei Stiftungen sehen wir häufig Websites mit Kontaktformularen, Newsletter-Anmeldungen und Spendenformularen - alles Bereiche, in denen besonders sensible Daten verarbeitet werden. Hier ist eine saubere Datenschutzerklärung nicht nur Pflicht, sondern auch Vertrauenssache gegenüber Spendern und Förderern. Auch die technische Basis der Website spielt eine Rolle - grundlegende Informationen zu <a href="/de/wissen/schema-org-seo-grundlagen/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">Schema.org und SEO-Grundlagen</a> helfen, die Website insgesamt professionell aufzustellen.
</p>
</div>
</section>

<!-- Checkliste -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Checkliste: 8 Punkte, die jede Website erfüllen muss</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
Unabhängig von Branche, Größe oder Rechtsform - diese acht Punkte sind das Minimum für jede Website in Deutschland.
</p>
<div class="space-y-4">
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">1</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Datenschutzerklärung vorhanden und aktuell</h3>
<p class="text-body text-gosign-text mt-1">Vollständige Erklärung mit allen DSGVO-Pflichtangaben. Mindestens jährlich prüfen und nach Gesetzesänderungen aktualisieren.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">2</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Impressum vollständig nach DDG</h3>
<p class="text-body text-gosign-text mt-1">Name, Anschrift, E-Mail, Telefon, Vertretungsberechtigte, Handelsregisternummer (falls vorhanden), USt-IdNr. Auf einer separaten Seite, mit maximal zwei Klicks erreichbar.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">3</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Cookie-Consent-Banner mit echtem Opt-in</h3>
<p class="text-body text-gosign-text mt-1">Kein vorausgewähltes "Alle akzeptieren". Gleichwertige Optionen für Zustimmung und Ablehnung. Erst nach Einwilligung dürfen nicht-essentielle Cookies gesetzt werden.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">4</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">SSL/TLS-Verschlüsselung aktiv</h3>
<p class="text-body text-gosign-text mt-1">Die gesamte Website muss über HTTPS erreichbar sein. Ohne Verschlüsselung werden Formulardaten im Klartext übertragen - ein klarer DSGVO-Verstoß.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">5</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Kontaktformulare mit Datenschutzhinweis</h3>
<p class="text-body text-gosign-text mt-1">Jedes Formular braucht einen Hinweis auf die Datenverarbeitung und einen Link zur Datenschutzerklärung. Bei sensiblen Daten (Bewerbungen, Gesundheit) ist eine separate Einwilligung nötig.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">6</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Auftragsverarbeitungsverträge (AVV) geschlossen</h3>
<p class="text-body text-gosign-text mt-1">Für jeden externen Dienstleister, der Zugriff auf personenbezogene Daten hat (Hoster, E-Mail-Anbieter, Analyse-Tools), muss ein AVV vorliegen. Ohne AVV ist die Datenverarbeitung rechtswidrig.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">7</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Keine unkontrollierten Drittanbieter-Einbindungen</h3>
<p class="text-body text-gosign-text mt-1">Google Fonts lokal hosten (nicht von Google-Servern laden). YouTube-Videos nur mit Zwei-Klick-Lösung einbetten. Keine externen Tracking-Pixel ohne Einwilligung. Jede Drittanbieter-Verbindung muss in der Datenschutzerklärung dokumentiert sein.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">8</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Barrierefreier Zugang zu Rechtsinformationen</h3>
<p class="text-body text-gosign-text mt-1">Datenschutzerklärung und Impressum müssen für alle zugänglich sein - auch für Menschen mit Einschränkungen. Ab Juni 2025 fordert das <a href="/de/wissen/barrierefreiheit-bfsg-2025/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">Barrierefreiheitsstärkungsgesetz (BFSG)</a> digitale Barrierefreiheit für viele Websites.</p>
</div>
</div>
</div>
</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Website-Datenschutz prüfen lassen, 30&nbsp;Minuten, kostenlos.</h3>
<p class="text-body text-gosign-text mb-6">Wir prüfen Ihre Website auf DSGVO-Konformität und zeigen Ihnen, wo Handlungsbedarf besteht.</p>
<a
href="/de/kontakt/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Datenschutz-Check anfragen
</a>
<p class="text-small text-gosign-text-light mt-4">25 Jahre Erfahrung &middot; 800+ Projekte &middot; Hamburger Datenschutz-Praxis</p>
</div>
</section>

<!-- Was passiert bei Verstößen -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Was passiert bei Verstößen?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Die Konsequenzen eines DSGVO-Verstoßes sind real und können existenzbedrohend sein. Die DSGVO sieht Bußgelder von bis zu 20 Millionen Euro oder 4 Prozent des weltweiten Jahresumsatzes vor - je nachdem, welcher Betrag höher ist. In der Praxis bewegen sich die meisten Bußgelder für Website-Verstöße im Bereich von 5.000 bis 50.000 Euro, aber die Tendenz ist steigend.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Neben Bußgeldern gibt es zwei weitere Risiken, die in der Praxis häufiger zuschlagen:
</p>
<div class="grid md:grid-cols-2 gap-6 mt-6">
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Abmahnungen</h3>
<p class="text-body text-gosign-text">
Seit dem EuGH-Urteil zu Google Fonts (2022) hat die Zahl der Abmahnungen deutlich zugenommen. Spezialisierte Anwälte und Verbraucherschutzorganisationen prüfen systematisch Websites auf DSGVO-Verstöße. Kosten pro Abmahnung: 500 bis 5.000 Euro - zuzüglich eigener Anwaltskosten.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Aufsichtsbehörden-Verfahren</h3>
<p class="text-body text-gosign-text">
Die Datenschutzaufsichtsbehörden der Länder prüfen zunehmend proaktiv. Eine Beschwerde bei der Behörde ist für jeden Besucher kostenlos und führt zu einer formellen Prüfung. Das bindet interne Ressourcen und kann zu Auflagen führen, die innerhalb kurzer Fristen umgesetzt werden müssen.
</p>
</div>
</div>
<p class="text-body text-gosign-text leading-relaxed mt-6">
Der wichtigste Punkt: Die meisten Website-Verstöße sind leicht vermeidbar. Eine aktuelle Datenschutzerklärung, ein funktionierendes Cookie-Banner und ein korrektes Impressum kosten einen Bruchteil dessen, was eine Abmahnung oder ein Bußgeld kostet. Prävention ist hier keine Frage des Budgets, sondern der Priorität.
</p>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
Gosign ist eine Hamburger Digitalagentur mit 25 Jahren Erfahrung in Webentwicklung, TYPO3 und KI-Integration.
Wir prüfen Websites auf DSGVO-Konformität, implementieren datenschutzkonforme Lösungen und begleiten
Unternehmen, Stiftungen und öffentliche Einrichtungen bei der Umsetzung aller gesetzlichen Anforderungen.
</p>
<p class="text-small text-gosign-text-light mt-2">Stand: März 2026</p>
</div>
</section>

<!-- Verwandte Themen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Verwandte Themen</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/de/wissen/barrierefreiheit-bfsg-2025/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Recht</p>
<p class="text-body font-semibold text-gosign-dark">Barrierefreiheit & BFSG 2025</p>
</a>
<a href="/de/wissen/website-ohne-cookie-banner/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Datenschutz</p>
<p class="text-body font-semibold text-gosign-dark">Website ohne Cookie-Banner</p>
</a>
<a href="/de/wissen/typo3-updates-sicherheit/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">TYPO3</p>
<p class="text-body font-semibold text-gosign-dark">TYPO3-Updates & Sicherheit</p>
</a>
</div>
</div>
</section>

--- Schema.org & SEO-Grundlagen erklärt ---
> Was sind strukturierte Daten? Wie verbessern Schema.org, Meta-Tags und Open Graph Ihre Google-Sichtbarkeit? SEO-Grundlagen einfach erklärt.

<!-- Was sind strukturierte Daten? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Was sind "strukturierte Daten"?</h2>
<p class="text-body text-gosign-text leading-relaxed">Stellen Sie sich vor, Sie geben jemandem Ihre Visitenkarte. Darauf steht Ihr Name, Ihre Telefonnummer, Ihre Adresse. Der Empfänger versteht sofort, wer Sie sind und wie er Sie erreichen kann. Genau das tun strukturierte Daten für Suchmaschinen.</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">Schema.org ist eine standardisierte Sprache, die Google, Bing und andere Suchmaschinen verstehen. Sie sagen damit: "Das hier ist ein Unternehmen, das ist die Adresse, das sind die Öffnungszeiten, und das ist der Preis des Produkts." Ohne diese Markierungen muss Google raten - und raten führt oft zu falschen oder unvollständigen Suchergebnissen.</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">Das Prinzip: Sie ergänzen Ihren bestehenden HTML-Code um unsichtbare Zusatzinformationen. Besucher sehen keinen Unterschied, aber Suchmaschinen lesen eine klar strukturierte "Visitenkarte" Ihres Unternehmens.</p>
</div>
</section>

<!-- Vorher/Nachher -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Vorher und Nachher: So verändert Schema.org Ihr Suchergebnis</h2>
<p class="text-body text-gosign-text leading-relaxed mb-8">Der Unterschied ist sofort sichtbar. Hier ein Vergleich, wie Ihr Unternehmen in den Google-Suchergebnissen erscheinen kann:</p>
<div class="grid md:grid-cols-2 gap-6">
<div class="bg-white border border-gosign-border rounded-card p-6">
<p class="text-small font-semibold text-red-600 uppercase tracking-wider mb-4">Ohne Schema.org</p>
<div class="border border-gosign-border rounded-card p-4 bg-gosign-light">
<p class="text-body text-blue-700 font-semibold">Musterfirma GmbH - Startseite</p>
<p class="text-small text-green-700 mb-1">www.musterfirma.de</p>
<p class="text-small text-gosign-text-light">Willkommen bei Musterfirma. Wir bieten Dienstleistungen im Bereich...</p>
</div>
<p class="text-small text-gosign-text-light mt-3">Nur ein blauer Link mit generischem Text. Keine Adresse, keine Bewertungen, keine Zusatzinfos. Der Suchende hat keinen Grund, genau hier zu klicken.</p>
</div>
<div class="bg-white border border-gosign-border rounded-card p-6">
<p class="text-small font-semibold text-green-700 uppercase tracking-wider mb-4">Mit Schema.org</p>
<div class="border border-gosign-border rounded-card p-4 bg-gosign-light">
<p class="text-body text-blue-700 font-semibold">Musterfirma GmbH - IT-Dienstleister Hamburg</p>
<p class="text-small text-green-700 mb-1">www.musterfirma.de</p>
<p class="text-small text-amber-700 mb-1">&#9733;&#9733;&#9733;&#9733;&#9733; 4,8 (127 Bewertungen)</p>
<p class="text-small text-gosign-text-light mb-1">Musterstraße 12, 20095 Hamburg - Tel. 040 123456</p>
<p class="text-small text-gosign-text-light">IT-Dienstleister für Mittelstand. Server, Cloud, Support.</p>
</div>
<p class="text-small text-gosign-text-light mt-3">Rich Snippet mit Bewertungssternen, Adresse und Telefonnummer. Nimmt mehr Platz ein, wirkt vertrauenswürdiger - und wird häufiger angeklickt.</p>
</div>
</div>
<p class="text-body text-gosign-text leading-relaxed mt-6">Studien zeigen: Rich Snippets mit Bewertungen und Zusatzinformationen erzielen bis zu 30 % höhere Klickraten als einfache blaue Links. Und das ohne Werbebudget - allein durch korrekt hinterlegte Daten.</p>
</div>
</section>

<!-- Die wichtigsten Schema-Typen -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">Die drei wichtigsten Schema-Typen für Unternehmen</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<div class="mb-4"><svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M3.75 21h16.5M4.5 3h15M5.25 3v18m13.5-18v18M9 6.75h1.5m-1.5 3h1.5m-1.5 3h1.5m3-6H15m-1.5 3H15m-1.5 3H15M9 21v-3.375c0-.621.504-1.125 1.125-1.125h3.75c.621 0 1.125.504 1.125 1.125V21" /></svg></div>
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Organization</h3>
<p class="text-body text-gosign-text">Grunddaten Ihres Unternehmens: Name, Logo, Adresse, Gründungsjahr, Social-Media-Profile. Google nutzt diese Daten für den Knowledge Panel - den Infokasten rechts neben den Suchergebnissen.</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<div class="mb-4"><svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M15 10.5a3 3 0 11-6 0 3 3 0 016 0z" /><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M19.5 10.5c0 7.142-7.5 11.25-7.5 11.25S4.5 17.642 4.5 10.5a7.5 7.5 0 1115 0z" /></svg></div>
<h3 class="text-h3 font-bold text-gosign-dark mb-3">LocalBusiness</h3>
<p class="text-body text-gosign-text">Erweitert Organization um standortspezifische Daten: Öffnungszeiten, Preisspanne, Bewertungen, Koordinaten. Besonders wichtig für Unternehmen mit lokalem Einzugsgebiet - die Basis für Google Maps-Einträge.</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<div class="mb-4"><svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M13.19 8.688a4.5 4.5 0 011.242 7.244l-4.5 4.5a4.5 4.5 0 01-6.364-6.364l1.757-1.757m9.86-2.813a4.5 4.5 0 00-1.242-7.244l4.5-4.5a4.5 4.5 0 016.364 6.364l-1.757 1.757" /></svg></div>
<h3 class="text-h3 font-bold text-gosign-dark mb-3">BreadcrumbList</h3>
<p class="text-body text-gosign-text">Zeigt Google die Navigationsstruktur Ihrer Website. Statt "www.example.de/produkte/kategorie/artikel" zeigt Google in den Suchergebnissen: "Startseite > Produkte > Kategorie" - übersichtlich und klickbar.</p>
</div>
</div>
</div>
</section>

<!-- Meta-Description -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Meta-Description: 160 Zeichen, die über den Klick entscheiden</h2>
<p class="text-body text-gosign-text leading-relaxed">Die Meta-Description ist der kurze Beschreibungstext, der in den Google-Suchergebnissen unter Ihrem Seitentitel erscheint. Sie ist kein direkter Ranking-Faktor, aber sie entscheidet, ob jemand auf Ihr Ergebnis klickt - oder auf das der Konkurrenz.</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">Eine gute Meta-Description beantwortet die Frage des Suchenden in maximal 155-160 Zeichen. Sie enthält das Hauptkeyword, einen klaren Nutzen und idealerweise eine Handlungsaufforderung. Fehlt die Meta-Description, wählt Google selbst einen Textausschnitt - oft nicht den besten.</p>
<h3 class="text-h3 font-bold text-gosign-dark mt-8 mb-4">Canonical Tags und hreflang: Klare Signale für Suchmaschinen</h3>
<p class="text-body text-gosign-text leading-relaxed">Wenn Ihre Website in mehreren Sprachen existiert oder ähnliche Inhalte unter verschiedenen URLs erreichbar sind, brauchen Suchmaschinen eindeutige Signale. Dafür gibt es zwei wichtige Tags:</p>
<ul class="mt-4 space-y-3">
<li class="text-body text-gosign-text leading-relaxed"><strong class="text-gosign-dark">Canonical Tag:</strong> Sagt Google, welche URL die "Original-Version" einer Seite ist. Verhindert, dass identische Inhalte unter verschiedenen Adressen als Duplikate gewertet werden. Beispiel: Ob jemand über example.de/seite oder example.de/seite/ kommt - der Canonical Tag zeigt auf eine einzige URL.</li>
<li class="text-body text-gosign-text leading-relaxed"><strong class="text-gosign-dark">Hreflang:</strong> Teilt Suchmaschinen mit, welche Sprachversionen einer Seite existieren. So zeigt Google deutschen Nutzern die deutsche Version und englischen Nutzern die englische - statt einer zufälligen. Für <a href="/de/wissen/dsgvo-pflichten-websites/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">DSGVO-konforme mehrsprachige Websites</a> besonders relevant.</li>
</ul>
</div>
</section>

<!-- Open Graph -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Open Graph Tags: So sehen Ihre Links bei WhatsApp und LinkedIn gut aus</h2>
<p class="text-body text-gosign-text leading-relaxed">Kennen Sie das? Sie teilen einen Link bei WhatsApp oder LinkedIn und es erscheint nur eine trockene URL - kein Bild, kein Titel, keine Beschreibung. Das passiert, wenn Open Graph Tags fehlen.</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">Open Graph (OG) Tags sind Meta-Angaben im HTML-Code, die sozialen Netzwerken sagen, wie ein geteilter Link dargestellt werden soll. Die vier wichtigsten:</p>
<ul class="mt-4 space-y-2">
<li class="text-body text-gosign-text"><strong class="text-gosign-dark">og:title</strong> - Der Titel, der in der Vorschau erscheint</li>
<li class="text-body text-gosign-text"><strong class="text-gosign-dark">og:description</strong> - Die Beschreibung unter dem Titel</li>
<li class="text-body text-gosign-text"><strong class="text-gosign-dark">og:image</strong> - Das Vorschaubild (ideal: 1200 x 630 Pixel)</li>
<li class="text-body text-gosign-text"><strong class="text-gosign-dark">og:url</strong> - Die kanonische URL der Seite</li>
</ul>
<p class="text-body text-gosign-text leading-relaxed mt-4">Ohne OG-Tags entscheidet jede Plattform selbst, was sie anzeigt. Mit OG-Tags kontrollieren Sie das Bild, das Ihr Unternehmen abgibt - auf LinkedIn, WhatsApp, Facebook, Twitter und überall, wo Links geteilt werden.</p>
</div>
</section>

<!-- SEO-Checkliste -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Checkliste: 6 SEO-Grundlagen für jede Unternehmenswebsite</h2>
<p class="text-body text-gosign-text leading-relaxed mb-8">Diese sechs Punkte bilden das technische Fundament für gute Google-Sichtbarkeit. Prüfen Sie, ob Ihre Website sie erfüllt:</p>
<div class="space-y-4">
<div class="bg-white border border-gosign-border rounded-card p-5"><div class="flex items-start gap-4"><span class="flex-shrink-0 w-8 h-8 bg-gosign-accent text-white rounded-full flex items-center justify-center font-bold text-small">1</span><div><h3 class="text-h3 font-bold text-gosign-dark mb-1">Schema.org-Markup hinterlegen</h3><p class="text-body text-gosign-text">Prüfen Sie, ob Ihre Website mindestens Organization- oder LocalBusiness-Schema hat. Test: Geben Sie Ihre URL im Rich Results Test ein (search.google.com/test/rich-results).</p></div></div></div>
<div class="bg-white border border-gosign-border rounded-card p-5"><div class="flex items-start gap-4"><span class="flex-shrink-0 w-8 h-8 bg-gosign-accent text-white rounded-full flex items-center justify-center font-bold text-small">2</span><div><h3 class="text-h3 font-bold text-gosign-dark mb-1">Meta-Descriptions für alle wichtigen Seiten</h3><p class="text-body text-gosign-text">Prüfen Sie, ob jede Seite eine eigene Meta-Description hat - nicht leer, nicht doppelt, maximal 155-160 Zeichen. Jede Description soll den Nutzen der Seite in einem Satz zusammenfassen.</p></div></div></div>
<div class="bg-white border border-gosign-border rounded-card p-5"><div class="flex items-start gap-4"><span class="flex-shrink-0 w-8 h-8 bg-gosign-accent text-white rounded-full flex items-center justify-center font-bold text-small">3</span><div><h3 class="text-h3 font-bold text-gosign-dark mb-1">Canonical Tags setzen</h3><p class="text-body text-gosign-text">Prüfen Sie, ob jede Seite einen Canonical Tag hat. Besonders wichtig bei Online-Shops, Filterseiten oder Websites mit www- und Nicht-www-Variante.</p></div></div></div>
<div class="bg-white border border-gosign-border rounded-card p-5"><div class="flex items-start gap-4"><span class="flex-shrink-0 w-8 h-8 bg-gosign-accent text-white rounded-full flex items-center justify-center font-bold text-small">4</span><div><h3 class="text-h3 font-bold text-gosign-dark mb-1">Open Graph Tags einrichten</h3><p class="text-body text-gosign-text">Prüfen Sie, ob Ihre Seiten og:title, og:description und og:image haben. Test: Teilen Sie einen Link Ihrer Website in einer WhatsApp-Gruppe - erscheint eine ansprechende Vorschau?</p></div></div></div>
<div class="bg-white border border-gosign-border rounded-card p-5"><div class="flex items-start gap-4"><span class="flex-shrink-0 w-8 h-8 bg-gosign-accent text-white rounded-full flex items-center justify-center font-bold text-small">5</span><div><h3 class="text-h3 font-bold text-gosign-dark mb-1">HTTPS und Ladezeit optimieren</h3><p class="text-body text-gosign-text">Prüfen Sie, ob Ihre Website über HTTPS erreichbar ist (Pflicht seit 2018) und in unter 3 Sekunden lädt. Beides sind direkte Google-Ranking-Faktoren. Eine <a href="/de/website-sicherheit-bsi/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">sichere Website nach BSI-Standards</a> erfüllt diese Anforderung.</p></div></div></div>
<div class="bg-white border border-gosign-border rounded-card p-5"><div class="flex items-start gap-4"><span class="flex-shrink-0 w-8 h-8 bg-gosign-accent text-white rounded-full flex items-center justify-center font-bold text-small">6</span><div><h3 class="text-h3 font-bold text-gosign-dark mb-1">Barrierefreiheit sicherstellen</h3><p class="text-body text-gosign-text">Prüfen Sie, ob Ihre Website <a href="/de/wissen/barrierefreiheit-bfsg-2025/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">barrierefrei nach BFSG 2025</a> ist. Alt-Texte bei Bildern, saubere Überschriften-Hierarchie und Tastatur-Bedienbarkeit verbessern nicht nur die Zugänglichkeit, sondern auch die Auffindbarkeit bei Google.</p></div></div></div>
</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">SEO-Potenzial Ihrer Website prüfen lassen - 30&nbsp;Minuten, kostenlos.</h3>
<p class="text-body text-gosign-text mb-6">Wir analysieren Ihre Website auf die wichtigsten SEO-Grundlagen und zeigen konkrete Verbesserungsmöglichkeiten.</p>
<a href="/de/kontakt/" target="_blank" rel="noopener noreferrer" class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider">SEO-Check anfragen</a>
<p class="text-small text-gosign-text-light mt-4">25 Jahre Erfahrung · 800+ Projekte · KI-beschleunigte Analyse</p>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">Gosign ist eine Hamburger Digitalagentur mit 25 Jahren Erfahrung in Webentwicklung, TYPO3 und KI-Integration. Wir betreuen Unternehmenswebsites von der technischen SEO-Optimierung bis zur Barrierefreiheit. Unsere Kunden sind mittelständische Unternehmen, Hochschulen und öffentliche Einrichtungen in Deutschland.</p>
<p class="text-small text-gosign-text-light mt-2">Stand: März 2026</p>
</div>
</section>

<!-- Verwandte Themen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Verwandte Themen</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/de/wissen/dsgvo-pflichten-websites/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors"><p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Recht</p><p class="text-body font-semibold text-gosign-dark">DSGVO-Pflichten für Websites</p></a>
<a href="/de/wissen/barrierefreiheit-bfsg-2025/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors"><p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Recht</p><p class="text-body font-semibold text-gosign-dark">Barrierefreiheit & BFSG 2025</p></a>
<a href="/de/wissen/typo3-updates-sicherheit/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors"><p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">TYPO3</p><p class="text-body font-semibold text-gosign-dark">TYPO3-Updates & Sicherheit</p></a>
</div>
</div>
</section>

--- TYPO3-Updates: Warum sie wichtig sind ---
> Warum TYPO3-Updates wichtig sind, welche Versionen noch Support haben und was ein Upgrade auf v13 bringt. Verständlich erklärt.

<!-- Was bedeutet LTS? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Was bedeutet "LTS" - und warum ist das für Sie wichtig?</h2>
<p class="text-body text-gosign-text leading-relaxed">LTS steht für <strong>Long Term Support</strong>. Das bedeutet: Der Hersteller liefert für diese Version über einen längeren Zeitraum Sicherheitsupdates. Wenn eine Sicherheitslücke entdeckt wird, wird sie geschlossen - aber nur für Versionen, die noch im Support sind.</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">Stellen Sie sich das wie ein Auto vor: Solange Ihr Modell noch produziert wird, bekommen Sie Ersatzteile und Rückrufaktionen. Läuft das Modell aus, sind Sie auf sich allein gestellt. Bei TYPO3 ist es genauso: Ohne Support gibt es keine Sicherheitspatches - und bekannte Schwachstellen bleiben offen.</p>
</div>
</section>

<!-- Versions-Tabelle -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Welche TYPO3-Versionen werden noch unterstützt?</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">TYPO3 veröffentlicht regelmäßig neue Versionen. Ältere Versionen erhalten irgendwann keine Sicherheitspatches mehr. Die folgende Tabelle zeigt den aktuellen Stand:</p>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse bg-white rounded-card">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Version</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Support bis</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Status</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">TYPO3 v13 LTS</td>
<td class="py-3 px-4 text-body text-gosign-text">Dezember 2027</td>
<td class="py-3 px-4"><span class="inline-flex items-center px-3 py-1 rounded-full text-small font-semibold bg-green-100 text-green-800">Aktuell - empfohlen</span></td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">TYPO3 v12 LTS</td>
<td class="py-3 px-4 text-body text-gosign-text">Oktober 2025 (Extended bis März 2028)</td>
<td class="py-3 px-4"><span class="inline-flex items-center px-3 py-1 rounded-full text-small font-semibold bg-yellow-100 text-yellow-800">Support läuft aus</span></td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">TYPO3 v11 und älter</td>
<td class="py-3 px-4 text-body text-gosign-text">Bereits abgelaufen</td>
<td class="py-3 px-4"><span class="inline-flex items-center px-3 py-1 rounded-full text-small font-semibold bg-red-100 text-red-800">Kein Support - Sicherheitsrisiko</span></td>
</tr>
</tbody>
</table>
</div>
<p class="text-body text-gosign-text leading-relaxed mt-6"><strong>Fazit:</strong> Wenn Ihre Website auf TYPO3 v11 oder älter läuft, erhalten Sie <strong>keine Sicherheitspatches mehr</strong>. Bekannte Schwachstellen werden nicht mehr geschlossen. Ein Upgrade ist dringend empfohlen.</p>
</div>
</section>

<!-- Was passiert bei veralteter Version? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Was passiert, wenn Sie eine veraltete Version nutzen?</h2>
<p class="text-body text-gosign-text leading-relaxed">Sicherheitslücken werden regelmäßig entdeckt - das ist normal und betrifft jede Software. Entscheidend ist, ob der Hersteller sie schließt. Bei Versionen ohne Support passiert das nicht mehr. Die Schwachstellen werden trotzdem öffentlich bekannt - und genau das machen sich Angreifer zunutze.</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">Konkret bedeutet das: Ihre Website kann für Phishing-Weiterleitungen, Spam-Versand oder Datendiebstahl missbraucht werden - oft ohne dass Sie es sofort merken. Die Folgen reichen von Reputationsschaden über DSGVO-Verstöße bis zu Blacklisting durch Suchmaschinen. Mehr zum Thema Datenschutzpflichten erfahren Sie in unserem Beitrag zu <a href="/de/wissen/dsgvo-pflichten-websites/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">DSGVO-Pflichten für Websites</a>.</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">Mit dem <a href="/de/typo3-sicherheitsmonitor/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">Gosign TYPO3-Sicherheitsmonitor</a> prüfen wir Ihre Installation auf bekannte Schwachstellen - unabhängig von der Version.</p>
</div>
</section>

<!-- Was bringt v13.4 -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">Was bringt TYPO3 v13.4 konkret?</h2>
<p class="text-body text-gosign-text leading-relaxed mb-8">Ein Update ist nicht nur eine Pflichtmaßnahme für die Sicherheit. TYPO3 v13.4 bringt echte Verbesserungen, die Sie im Alltag spüren:</p>
<div class="grid md:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6 bg-white">
<div class="flex items-start gap-3">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M3.75 13.5l10.5-11.25L12 10.5h8.25L9.75 21.75 12 13.5H3.75z" /></svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Schnellere Ladezeiten</h3>
<p class="text-body text-gosign-text">Automatische Bildkompression mit WebP und AVIF. Ihre Bilder werden kleiner, die Seiten laden schneller - ohne dass Sie etwas ändern müssen.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-white">
<div class="flex items-start gap-3">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9.594 3.94c.09-.542.56-.94 1.11-.94h2.593c.55 0 1.02.398 1.11.94l.213 1.281c.063.374.313.686.645.87.074.04.147.083.22.127.325.196.72.257 1.075.124l1.217-.456a1.125 1.125 0 011.37.49l1.296 2.247a1.125 1.125 0 01-.26 1.431l-1.003.827c-.293.241-.438.613-.43.992a7.723 7.723 0 010 .255c-.008.378.137.75.43.991l1.004.827c.424.35.534.955.26 1.43l-1.298 2.247a1.125 1.125 0 01-1.369.491l-1.217-.456c-.355-.133-.75-.072-1.076.124a6.47 6.47 0 01-.22.128c-.331.183-.581.495-.644.869l-.213 1.281c-.09.543-.56.941-1.11.941h-2.594c-.55 0-1.019-.398-1.11-.94l-.213-1.281c-.062-.374-.312-.686-.644-.87a6.52 6.52 0 01-.22-.127c-.325-.196-.72-.257-1.076-.124l-1.217.456a1.125 1.125 0 01-1.369-.49l-1.297-2.247a1.125 1.125 0 01.26-1.431l1.004-.827c.292-.24.437-.613.43-.991a6.932 6.932 0 010-.255c.007-.38-.138-.751-.43-.992l-1.004-.827a1.125 1.125 0 01-.26-1.43l1.297-2.247a1.125 1.125 0 011.37-.491l1.216.456c.356.133.751.072 1.076-.124.072-.044.146-.086.22-.128.332-.183.582-.495.644-.869l.214-1.28z" /><path stroke-linecap="round" stroke-linejoin="round" d="M15 12a3 3 0 11-6 0 3 3 0 016 0z" /></svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Moderneres Backend</h3>
<p class="text-body text-gosign-text">Die Oberfläche, in der Sie Inhalte pflegen, wurde überarbeitet. Klarere Struktur, bessere Übersicht, einfachere Bedienung - auch für Gelegenheitsnutzer.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-white">
<div class="flex items-start gap-3">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75L11.25 15 15 9.75m-3-7.036A11.959 11.959 0 013.598 6 11.99 11.99 0 003 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285z" /></svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Aktuelle Sicherheit</h3>
<p class="text-body text-gosign-text">PHP 8.2+ Unterstützung und regelmäßige Sicherheitsupdates. Ihre Website bleibt gegen aktuelle Bedrohungen geschützt.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-white">
<div class="flex items-start gap-3">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M3.75 6A2.25 2.25 0 016 3.75h2.25A2.25 2.25 0 0110.5 6v2.25a2.25 2.25 0 01-2.25 2.25H6a2.25 2.25 0 01-2.25-2.25V6zM3.75 15.75A2.25 2.25 0 016 13.5h2.25a2.25 2.25 0 012.25 2.25V18a2.25 2.25 0 01-2.25 2.25H6A2.25 2.25 0 013.75 18v-2.25zM13.5 6a2.25 2.25 0 012.25-2.25H18A2.25 2.25 0 0120.25 6v2.25A2.25 2.25 0 0118 10.5h-2.25a2.25 2.25 0 01-2.25-2.25V6zM13.5 15.75a2.25 2.25 0 012.25-2.25H18a2.25 2.25 0 012.25 2.25V18A2.25 2.25 0 0118 20.25h-2.25A2.25 2.25 0 0113.5 18v-2.25z" /></svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Content Blocks</h3>
<p class="text-body text-gosign-text">Neue Content Blocks ermöglichen flexiblere Seitengestaltung. Layouts und Inhaltselemente lassen sich einfacher kombinieren - weniger Abhängigkeit von Extensions.</p>
</div>
</div>
</div>
</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">TYPO3-Version prüfen lassen, 30&nbsp;Minuten, kostenlos.</h3>
<p class="text-body text-gosign-text mb-6">Wir prüfen Ihre TYPO3-Version, installierte Extensions und offene Sicherheitslücken - unverbindlich.</p>
<a href="/de/kontakt/" target="_blank" rel="noopener noreferrer" class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider">TYPO3-Check anfragen</a>
<p class="text-small text-gosign-text-light mt-4">25 Jahre Erfahrung &middot; 800+ Extensions &middot; KI-beschleunigte Entwicklung</p>
</div>
</section>

<!-- Upgrade-Prozess -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Der Upgrade-Prozess: Was kommt auf Sie zu?</h2>
<p class="text-body text-gosign-text leading-relaxed">Ein TYPO3-Update muss kein Großprojekt sein. Der typische Ablauf:</p>
<ol class="mt-6 space-y-4">
<li class="flex items-start gap-3"><span class="flex-shrink-0 w-8 h-8 bg-gosign-accent text-white rounded-full flex items-center justify-center text-small font-bold">1</span><div><p class="text-body font-semibold text-gosign-dark">Analyse</p><p class="text-body text-gosign-text">Welche Version läuft aktuell? Welche Extensions sind installiert? Gibt es individuelle Anpassungen? Gosign erstellt eine Bestandsaufnahme.</p></div></li>
<li class="flex items-start gap-3"><span class="flex-shrink-0 w-8 h-8 bg-gosign-accent text-white rounded-full flex items-center justify-center text-small font-bold">2</span><div><p class="text-body font-semibold text-gosign-dark">Staging-Update</p><p class="text-body text-gosign-text">Das Update wird auf einer Testumgebung durchgeführt. Ihre Live-Website läuft währenddessen ganz normal weiter.</p></div></li>
<li class="flex items-start gap-3"><span class="flex-shrink-0 w-8 h-8 bg-gosign-accent text-white rounded-full flex items-center justify-center text-small font-bold">3</span><div><p class="text-body font-semibold text-gosign-dark">Test und Freigabe</p><p class="text-body text-gosign-text">Sie prüfen die Staging-Version. Funktioniert alles wie erwartet? Erst nach Ihrer Freigabe geht es weiter.</p></div></li>
<li class="flex items-start gap-3"><span class="flex-shrink-0 w-8 h-8 bg-gosign-accent text-white rounded-full flex items-center justify-center text-small font-bold">4</span><div><p class="text-body font-semibold text-gosign-dark">Go-Live</p><p class="text-body text-gosign-text">Die aktualisierte Version wird live geschaltet. Die Ausfallzeit beträgt in der Regel unter 30 Minuten.</p></div></li>
</ol>
<p class="text-body text-gosign-text leading-relaxed mt-6"><strong>Zeitaufwand:</strong> Ein Minor-Update (z.B. 12.4 auf 12.6) dauert wenige Stunden. Ein Major-Upgrade (z.B. v10 auf v13) kann je nach <a href="/de/typo3-extensions/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">Extensions</a> und Anpassungen einige Tage in Anspruch nehmen.</p>
</div>
</section>

<!-- Hosting und CMS-Betreuung -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Warum Hosting und CMS-Betreuung zusammengehören</h2>
<p class="text-body text-gosign-text leading-relaxed">TYPO3-Updates betreffen nicht nur die Software selbst. Neue Versionen erfordern oft aktuellere PHP-Versionen, angepasste Datenbank-Konfigurationen oder aktualisierte Server-Einstellungen. Wenn CMS-Betreuung und Hosting bei unterschiedlichen Anbietern liegen, entsteht ein Koordinationsaufwand - und im schlimmsten Fall eine Sicherheitslücke, weil niemand sich zuständig fühlt.</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">Gosign bietet beides aus einer Hand: CMS-Betreuung inklusive Updates, Extensions-Monitoring und Hosting auf deutschen Servern. So ist sichergestellt, dass Server-Umgebung und CMS-Version immer zueinander passen.</p>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">Gosign ist eine Hamburger Digitalagentur mit 25 Jahren Erfahrung in Webentwicklung, TYPO3 und KI-Integration. Wir haben über 800 TYPO3 Extensions analysiert und entwickeln heute mit KI-Unterstützung bis zu 70&nbsp;% schneller als mit klassischen Methoden. Unsere Kunden sind mittelständische Unternehmen, Hochschulen und öffentliche Einrichtungen in Deutschland.</p>
<p class="text-small text-gosign-text-light mt-2">Stand: März 2026</p>
</div>
</section>

<!-- Verwandte Themen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Verwandte Themen</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/de/typo3-extensions/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors"><p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">TYPO3</p><p class="text-body font-semibold text-gosign-dark">TYPO3 Extensions: Entwicklung & Monitoring</p></a>
<a href="/de/typo3-sicherheitsmonitor/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors"><p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Security</p><p class="text-body font-semibold text-gosign-dark">TYPO3 Sicherheitsmonitor</p></a>
<a href="/de/website-sicherheit-bsi/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors"><p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Security</p><p class="text-body font-semibold text-gosign-dark">Website-Sicherheit nach BSI-Gesetz</p></a>
</div>
</div>
</section>

--- Website ohne Cookie-Banner ---
> Websites ohne Cookie-Banner sind legal, schneller und DSGVO-konform. So eliminieren Sie Cookies und sparen CMP-Kosten.

<!-- Das Problem: Cookie-Banner nerven alle -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Das Problem: Cookie-Banner nerven alle</h2>
<p class="text-body text-gosign-text leading-relaxed">
Rund 80 Prozent der Website-Besucher klicken auf "Alle ablehnen" oder schließen das Cookie-Banner sofort. Das Ergebnis: Das Erste, was ein potenzieller Kunde von Ihrer Website sieht, ist eine Barriere. Kein Content, kein Produkt, keine Botschaft - sondern ein Popup, das nach Einwilligung fragt.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Cookie-Banner sind nicht nur lästig, sie kosten auch Geld. Consent-Management-Plattformen (CMPs) wie Cookiebot, Usercentrics oder OneTrust berechnen 50 bis 500 Euro pro Monat - je nach Seitenaufrufen. Dazu kommt: Das CMP-JavaScript verlangsamt die Seitenladung, verschlechtert Core Web Vitals und kann <a href="/de/wissen/schema-org-seo-grundlagen/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">SEO-Rankings negativ beeinflussen</a>.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Trotzdem brauchen die meisten Websites ein Cookie-Banner - weil sie Cookies setzen. Google Analytics, Facebook Pixel, eingebettete YouTube-Videos, Google Fonts von externen Servern: All das setzt Cookies oder überträgt personenbezogene Daten. Und das <a href="/de/wissen/dsgvo-pflichten-websites/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">TDDDG schreibt vor</a>, dass vor dem Setzen nicht-essentieller Cookies eine Einwilligung eingeholt werden muss.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Aber was, wenn eine Website gar keine Cookies setzt?
</p>
</div>
</section>

<!-- Die Alternative: Gar keine Cookies setzen -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Die Alternative: Gar keine Cookies setzen</h2>
<p class="text-body text-gosign-text leading-relaxed">
Wenn eine Website keine nicht-essentiellen Cookies setzt, braucht sie kein Cookie-Banner. Das ist kein Trick und keine Grauzone - es ist schlichte Logik. Das TDDDG verlangt eine Einwilligung nur vor dem Setzen von Cookies. Keine Cookies, keine Einwilligung nötig, kein Banner erforderlich.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Technisch ist das absolut machbar. Es erfordert bewusste Entscheidungen bei der Website-Architektur:
</p>
<div class="grid md:grid-cols-2 gap-6 mt-6">
<div class="border border-gosign-border rounded-card p-6 bg-white">
<div class="flex items-start gap-3">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor">
<path stroke-linecap="round" stroke-linejoin="round" d="M3.75 13.5l10.5-11.25L12 10.5h8.25L9.75 21.75 12 13.5H3.75z" />
</svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Selbst gehostete Fonts</h3>
<p class="text-body text-gosign-text">Google Fonts lokal einbinden statt von Google-Servern laden. Keine Verbindung zu Google, keine IP-Übertragung, kein Cookie-Bedarf.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-white">
<div class="flex items-start gap-3">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor">
<path stroke-linecap="round" stroke-linejoin="round" d="M3 13.125C3 12.504 3.504 12 4.125 12h2.25c.621 0 1.125.504 1.125 1.125v6.75C7.5 20.496 6.996 21 6.375 21h-2.25A1.125 1.125 0 013 19.875v-6.75zM9.75 8.625c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125v11.25c0 .621-.504 1.125-1.125 1.125h-2.25a1.125 1.125 0 01-1.125-1.125V8.625zM16.5 4.125c0-.621.504-1.125 1.125-1.125h2.25C20.496 3 21 3.504 21 4.125v15.75c0 .621-.504 1.125-1.125 1.125h-2.25a1.125 1.125 0 01-1.125-1.125V4.125z" />
</svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Cookielose Analyse</h3>
<p class="text-body text-gosign-text">Cloudflare Web Analytics statt Google Analytics. Keine Cookies, keine IP-Speicherung, trotzdem Seitenaufrufe, Referrer und Top-Seiten.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-white">
<div class="flex items-start gap-3">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor">
<path stroke-linecap="round" stroke-linejoin="round" d="M18.364 18.364A9 9 0 005.636 5.636m12.728 12.728A9 9 0 015.636 5.636m12.728 12.728L5.636 5.636" />
</svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Keine Third-Party-Embeds</h3>
<p class="text-body text-gosign-text">Kein YouTube, kein Google Maps, keine Social-Media-Buttons, die Cookies setzen. Wenn nötig: datenschutzkonforme Alternativen oder Zwei-Klick-Lösungen.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-white">
<div class="flex items-start gap-3">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor">
<path stroke-linecap="round" stroke-linejoin="round" d="M5.25 14.25h13.5m-13.5 0a3 3 0 01-3-3m3 3a3 3 0 100 6h13.5a3 3 0 100-6m-16.5-3a3 3 0 013-3h13.5a3 3 0 013 3m-19.5 0a4.5 4.5 0 01.9-2.7L5.737 5.1a3.375 3.375 0 012.7-1.35h7.126c1.062 0 2.062.5 2.7 1.35l2.587 3.45a4.5 4.5 0 01.9 2.7m0 0a3 3 0 01-3 3m0 3h.008v.008h-.008V17.25zm-3 0h.008v.008h-.008V17.25z" />
</svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">SSG + CDN-Edge-Delivery</h3>
<p class="text-body text-gosign-text">Statische Website-Generierung statt dynamischer CMS-Auslieferung. Kein serverseitiger Session-Cookie, keine dynamischen Tracking-Header.</p>
</div>
</div>
</div>
</div>
</div>
</section>

<!-- Was Sie gewinnen: 6-Card-Grid -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Was Sie gewinnen</h2>
<div class="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-3 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<div class="flex items-start gap-3">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75L11.25 15 15 9.75M21 12a9 9 0 11-18 0 9 9 0 0118 0z" /></svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Kein Cookie-Banner</h3>
<p class="text-body text-gosign-text">Sauberer erster Eindruck. Kein Popup, kein "Akzeptieren"-Dialog. Besucher sehen sofort Ihren Content.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-6">
<div class="flex items-start gap-3">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor"><path stroke-linecap="round" stroke-linejoin="round" d="M3.75 13.5l10.5-11.25L12 10.5h8.25L9.75 21.75 12 13.5H3.75z" /></svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Bessere Performance</h3>
<p class="text-body text-gosign-text">Kein CMP-JavaScript, kein Consent-Check vor jedem Script. Weniger Code, schnellere Ladezeiten.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-6">
<div class="flex items-start gap-3">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75L11.25 15 15 9.75m-3-7.036A11.959 11.959 0 013.598 6 11.99 11.99 0 003 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285z" /></svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Volle DSGVO-Konformität</h3>
<p class="text-body text-gosign-text">Nicht "compliant genug", sondern: Es gibt nichts zu regulieren. Keine Cookies, keine Einwilligung nötig.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-6">
<div class="flex items-start gap-3">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 18.75a60.07 60.07 0 0115.797 2.101c.727.198 1.453-.342 1.453-1.096V18.75M3.75 4.5v.75A.75.75 0 013 6h-.75m0 0v-.375c0-.621.504-1.125 1.125-1.125H20.25M2.25 6v9m18-10.5v.75c0 .414.336.75.75.75h.75m-1.5-1.5h.375c.621 0 1.125.504 1.125 1.125v9.75c0 .621-.504 1.125-1.125 1.125h-.375m1.5-1.5H21a.75.75 0 00-.75.75v.75m0 0H3.75m0 0h-.375a1.125 1.125 0 01-1.125-1.125V15m1.5 1.5v-.75A.75.75 0 003 15h-.75M15 10.5a3 3 0 11-6 0 3 3 0 016 0zm3 0h.008v.008H18V10.5zm-12 0h.008v.008H6V10.5z" /></svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Keine CMP-Kosten</h3>
<p class="text-body text-gosign-text">Kein Cookiebot, Usercentrics oder OneTrust. Das spart 600 bis 6.000 Euro pro Jahr.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-6">
<div class="flex items-start gap-3">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 18L9 11.25l4.306 4.307a11.95 11.95 0 015.814-5.519l2.74-1.22m0 0l-5.94-2.28m5.94 2.28l-2.28 5.941" /></svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Bessere SEO</h3>
<p class="text-body text-gosign-text">Google Core Web Vitals profitieren direkt von fehlenden Consent-Skripten. Schnellere Seiten ranken besser.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-6">
<div class="flex items-start gap-3">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor"><path stroke-linecap="round" stroke-linejoin="round" d="M16.5 10.5V6.75a4.5 4.5 0 10-9 0v3.75m-.75 11.25h10.5a2.25 2.25 0 002.25-2.25v-6.75a2.25 2.25 0 00-2.25-2.25H6.75a2.25 2.25 0 00-2.25 2.25v6.75a2.25 2.25 0 002.25 2.25z" /></svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Zukunftssicher</h3>
<p class="text-body text-gosign-text">Cookie-Regulierung wird strenger. Wer keine Cookies braucht, ist davon schlicht nicht betroffen.</p>
</div>
</div>
</div>
</div>
</div>
</section>

<!-- "Aber ich brauche doch Analytics!" -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">"Aber ich brauche doch Analytics!"</h2>
<p class="text-body text-gosign-text leading-relaxed">
Das ist der häufigste Einwand. Und er ist berechtigt - aber lösbar. Analytics ohne Cookies ist längst Realität. Die Frage ist nicht ob, sondern wie.
</p>
<div class="space-y-6 mt-6">
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Cloudflare Web Analytics</h3>
<p class="text-body text-gosign-text leading-relaxed">Cookielos, datenschutzkonform und kostenlos. Liefert Seitenaufrufe, Top-Seiten, Referrer, Länder und Gerätetypen. Keine IP-Speicherung, kein Consent erforderlich, keine Einbindung eines CMP nötig.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Serverseitige Analyse</h3>
<p class="text-body text-gosign-text leading-relaxed">Logfile-Auswertung direkt auf dem Server. Keine Cookies, keine externe Datenübertragung. Tools wie GoAccess oder AWStats werten Server-Logs aus und liefern Besucherzahlen, ohne jemals den Browser des Besuchers zu berühren.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Conversion-Tracking ohne Cookies</h3>
<p class="text-body text-gosign-text leading-relaxed">Serverseitige Events statt clientseitige Pixel. Wenn ein Besucher ein Kontaktformular absendet, wird das Ereignis serverseitig erfasst - ohne Cookie, ohne Pixel, ohne Drittanbieter.</p>
</div>
</div>
<p class="text-body text-gosign-text leading-relaxed mt-6">
Die ehrliche Frage lautet: Brauchen Sie wirklich 200 Datenpunkte pro Besucher, oder reichen Seitenaufrufe, Referrer und Conversion-Events? Für die meisten Unternehmenswebsites ist die Antwort klar. Wer weniger externe Abhängigkeiten hat, verbessert gleichzeitig die <a href="/de/website-sicherheit-bsi/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">Website-Sicherheit</a> - weniger Drittanbieter-Skripte bedeuten weniger Angriffsfläche.
</p>
</div>
</section>

<!-- Praxisbeispiel: gosign.de -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Praxisbeispiel: gosign.de</h2>
<p class="text-body text-gosign-text leading-relaxed">
Diese Website setzt keine Cookies. Null Cookie-Banner, null externe Fonts, null Tracking-Pixel. Die Analyse läuft über Cloudflare Web Analytics (cookielos, keine IP-Speicherung). Fonts sind selbst gehostet, es gibt keine YouTube-Embeds, kein Google Maps, keine Social-Media-Buttons. Das Ergebnis: Lighthouse 100/100 in allen vier Kategorien (Performance, Accessibility, Best Practices, SEO), volle DSGVO-Konformität ohne laufende CMP-Kosten und eine Datenschutzerklärung, die auf das Wesentliche beschränkt ist. Auch das Thema <a href="/de/wissen/barrierefreiheit-bfsg-2025/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">Barrierefreiheit</a> profitiert direkt von dieser Architektur: Ohne CMP-Overlay gibt es keine Barriere zwischen Nutzer und Inhalt.
</p>
</div>
</section>

<!-- Checkliste: So wird Ihre Website cookie-frei -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Checkliste: So wird Ihre Website cookie-frei</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">Fünf Schritte, in dieser Reihenfolge. Erst wenn die ersten vier Punkte erledigt sind, darf das Banner entfernt werden.</p>
<div class="space-y-4">
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">1</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Externe Fonts entfernen oder lokal hosten</h3>
<p class="text-body text-gosign-text mt-1">Google Fonts von Google-Servern laden ist der häufigste Grund für ungewollte Datenübertragungen. Fonts herunterladen, auf dem eigenen Server hosten, fertig. Das EuGH-Urteil von 2022 hat klargestellt: Remote-Einbindung von Google Fonts ohne Einwilligung ist rechtswidrig.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">2</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Google Analytics durch cookielose Alternative ersetzen</h3>
<p class="text-body text-gosign-text mt-1">Cloudflare Web Analytics, Plausible oder Fathom liefern die Daten, die für Unternehmenswebsites relevant sind - ohne Cookies und ohne Einwilligungspflicht. Die Migration dauert in der Regel weniger als eine Stunde.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">3</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Third-Party-Embeds ersetzen oder absichern</h3>
<p class="text-body text-gosign-text mt-1">YouTube-Videos, Google Maps und Social-Media-Buttons setzen Cookies, sobald sie geladen werden. Zwei Optionen: Komplett entfernen oder durch Zwei-Klick-Lösungen ersetzen, die erst nach Zustimmung laden.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">4</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Marketing-Pixel entfernen oder serverseitig umstellen</h3>
<p class="text-body text-gosign-text mt-1">Facebook Pixel, LinkedIn Insight Tag, Google Ads Conversion - all das setzt Cookies. Entweder komplett entfernen oder auf serverseitiges Tracking umstellen, das ohne Cookies auf dem Endgerät auskommt.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">5</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Cookie-Banner entfernen</h3>
<p class="text-body text-gosign-text mt-1">Erst jetzt. Wenn keine nicht-essentiellen Cookies mehr gesetzt werden, kann das CMP deinstalliert und das Banner entfernt werden. Die Datenschutzerklärung bleibt Pflicht, wird aber deutlich kürzer.</p>
</div>
</div>
</div>
</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Cookie-freie Website anfragen, 30&nbsp;Minuten, kostenlos.</h3>
<p class="text-body text-gosign-text mb-6">Wir prüfen Ihre Website und zeigen Ihnen, welche Cookies Sie loswerden können - und welche Sie gar nicht brauchen.</p>
<a href="/de/kontakt/" target="_blank" rel="noopener noreferrer" class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider">Cookie-freie Website anfragen</a>
<p class="text-small text-gosign-text-light mt-4">25 Jahre Erfahrung &middot; 800+ Projekte &middot; Hamburger Datenschutz-Praxis</p>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">Gosign ist eine Hamburger Digitalagentur mit 25 Jahren Erfahrung in Webentwicklung, TYPO3 und KI-Integration. Wir entwickeln Websites ohne Cookies, ohne externe Abhängigkeiten und mit voller DSGVO-Konformität - ohne Kompromisse bei Analyse, Performance oder Funktionalität.</p>
<p class="text-small text-gosign-text-light mt-2">Stand: März 2026</p>
</div>
</section>

<!-- Verwandte Themen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Verwandte Themen</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/de/wissen/dsgvo-pflichten-websites/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Recht</p>
<p class="text-body font-semibold text-gosign-dark">DSGVO-Pflichten für Websites</p>
</a>
<a href="/de/wissen/schema-org-seo-grundlagen/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">SEO</p>
<p class="text-body font-semibold text-gosign-dark">Schema.org & SEO-Grundlagen</p>
</a>
<a href="/de/website-sicherheit-bsi/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Security</p>
<p class="text-body font-semibold text-gosign-dark">Website-Sicherheit nach BSI</p>
</a>
</div>
</div>
</section>

--- WordPress Agentur Hamburg | Gosign | Seit 1999 ---
> WordPress Agentur in Hamburg: Entwicklung, Wartung & KI-beschleunigte Projekte. Seit 25 Jahren. Kostenlose Erstberatung.

<!-- Was bietet Gosign? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Was bietet Gosign als WordPress-Agentur?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Gosign ist eine Hamburger WordPress-Agentur mit 25&nbsp;Jahren Erfahrung in Webentwicklung. Gosign entwickelt WordPress-Websites für B2B-Unternehmen: Custom Themes, Plugin-Entwicklung, WooCommerce-Shops, Headless WordPress mit modernen Frontends. Seit 2023 setzt Gosign KI-gestützte Entwicklung ein. WordPress-Projekte entstehen 60 - 80&nbsp;% schneller bei gleichbleibender Qualität.
</p>
</div>
</section>

<!-- Warum Gosign -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Warum Gosign statt einer reinen WordPress-Agentur?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Weil WordPress nur ein Teil des Bildes ist. Gosign kennt TYPO3, Headless-Architekturen und KI-Infrastrukturen und berät ehrlich, ob WordPress die richtige Wahl ist. Für Content-Sites: fast immer ja. Für Enterprise-Portale mit komplexen Berechtigungen: vielleicht TYPO3.
</p>
</div>
</section>

<!-- WordPress-Leistungen -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">WordPress-Leistungen</h2>
<div class="grid md:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Custom Theme-Entwicklung</h3>
<p class="text-body text-gosign-text">
Keine fertigen Templates. Gosign entwickelt WordPress-Themes exakt nach Designvorgabe, responsive, performant, barrierefrei. Gutenberg-optimiert, Full Site Editing ready. KI generiert Theme-Grundgerüste, Senior-Entwickler verfeinern.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Plugin-Entwicklung &amp; Customization</h3>
<p class="text-body text-gosign-text">
Custom Plugins für Ihre Geschäftslogik. Bestehende Plugins erweitern, anpassen oder durch sicherere Eigenentwicklungen ersetzen. KI beschleunigt die Plugin-Entwicklung um 70&nbsp;%.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">WooCommerce &amp; E-Commerce</h3>
<p class="text-body text-gosign-text">
Online-Shops mit WooCommerce: Produktkataloge, Payment-Integration, Versandlogik, Gutschein-Systeme. Für Shops bis ~50.000 Produkte die richtige Plattform.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">WordPress-Wartung &amp; Security</h3>
<p class="text-body text-gosign-text">
Updates, Backups, Security-Monitoring, Performance-Optimierung. Proaktive Wartung statt reaktiver Reparatur. Gosign überwacht über 800 Extensions und kennt Sicherheitslücken, bevor sie ausgenutzt werden.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6 md:col-span-2">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">WordPress-Migration</h3>
<p class="text-body text-gosign-text">
Von TYPO3, Joomla, Drupal oder Webflow auf WordPress migrieren. Content-Übernahme, SEO-Redirect-Mapping, Design-Neugestaltung. KI-gestützte Content-Migration spart Wochen.
</p>
</div>
</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">WordPress-Projekt besprechen, 30&nbsp;Minuten, kostenlos.</h3>
<p class="text-body text-gosign-text mb-6">Wir analysieren Ihr Projekt, schätzen Aufwand und Zeitrahmen, unverbindlich.</p>
<a
href="/de/kontakt/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Erstgespräch vereinbaren
</a>
<p class="text-small text-gosign-text-light mt-4">25 Jahre Erfahrung · 800+ Extensions · KI-beschleunigte Entwicklung</p>
</div>
</section>

<!-- KI Table -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">KI-beschleunigte WordPress-Entwicklung: 70&nbsp;% schneller</h2>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Aufgabe</th>
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Klassisch</th>
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Mit KI</th>
<th class="py-3 text-small font-bold text-gosign-dark">Ersparnis</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Custom Theme (10 Templates)</td>
<td class="py-3 pr-4 text-body text-gosign-text">3 - 4 Wochen</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">1 - 1,5 Wochen</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">65&nbsp;%</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Custom Plugin</td>
<td class="py-3 pr-4 text-body text-gosign-text">2 - 3 Wochen</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">4 - 6 Tage</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">70&nbsp;%</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">WooCommerce-Shop Setup</td>
<td class="py-3 pr-4 text-body text-gosign-text">2 - 3 Wochen</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">5 - 7 Tage</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">65&nbsp;%</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Content-Migration (500 Seiten)</td>
<td class="py-3 pr-4 text-body text-gosign-text">2 Wochen</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">3 Tage</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">80&nbsp;%</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Security Audit</td>
<td class="py-3 pr-4 text-body text-gosign-text">3 Tage</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">1 Tag</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">70&nbsp;%</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Comparison Table -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">WordPress vs. TYPO3 vs. Headless: ehrliche Beratung</h2>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse bg-white rounded-card">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Kriterium</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">WordPress</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">TYPO3</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Headless (Astro, Next.js)</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Content-Fokus</td>
<td class="py-3 px-4 text-body text-gosign-text">Ideal</td>
<td class="py-3 px-4 text-body text-gosign-text">Gut</td>
<td class="py-3 px-4 text-body text-gosign-text">Komplexer</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Enterprise-Rechte</td>
<td class="py-3 px-4 text-body text-gosign-text">Limitiert</td>
<td class="py-3 px-4 text-body text-gosign-text">Granular</td>
<td class="py-3 px-4 text-body text-gosign-text">Custom</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">E-Commerce</td>
<td class="py-3 px-4 text-body text-gosign-text">WooCommerce</td>
<td class="py-3 px-4 text-body text-gosign-text">aimeos</td>
<td class="py-3 px-4 text-body text-gosign-text">Shopify API</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Performance</td>
<td class="py-3 px-4 text-body text-gosign-text">Plugin-abhängig</td>
<td class="py-3 px-4 text-body text-gosign-text">Caching nötig</td>
<td class="py-3 px-4 text-body text-gosign-accent-text font-semibold">Static = schnell</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Redakteur-Freundlichkeit</td>
<td class="py-3 px-4 text-body text-gosign-text">Exzellent</td>
<td class="py-3 px-4 text-body text-gosign-text">Gut</td>
<td class="py-3 px-4 text-body text-gosign-text">Eingeschränkt</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Gosign-Empfehlung</td>
<td class="py-3 px-4 text-body text-gosign-accent-text font-semibold">Content-Sites, Blogs, KMU</td>
<td class="py-3 px-4 text-body text-gosign-accent-text font-semibold">Enterprise, Hochschulen</td>
<td class="py-3 px-4 text-body text-gosign-accent-text font-semibold">Performance-kritisch</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
Gosign ist eine Hamburger Digitalagentur mit 25 Jahren Erfahrung in Webentwicklung, TYPO3 und KI-Integration.
Wir haben über 800 TYPO3 Extensions analysiert und entwickeln heute mit KI-Unterstützung
bis zu 70&nbsp;% schneller als mit klassischen Methoden. Unsere Kunden sind mittelständische
Unternehmen, Hochschulen und öffentliche Einrichtungen in Deutschland.
</p>
<p class="text-small text-gosign-text-light mt-2">Stand: Februar 2026</p>
</div>
</section>

<!-- Verwandte Themen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Verwandte Themen</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/de/digitalagentur-hamburg/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Agentur</p>
<p class="text-body font-semibold text-gosign-dark">Digitalagentur Hamburg</p>
</a>
<a href="/de/website-gehackt-10-gruende/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Sicherheit</p>
<p class="text-body font-semibold text-gosign-dark">Website gehackt: 10 Gründe & Soforthilfe</p>
</a>
<a href="/de/website-sicherheit-bsi/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Compliance</p>
<p class="text-body font-semibold text-gosign-dark">Website-Sicherheit nach BSI-Gesetz</p>
</a>
</div>
</div>
</section>


============================================================
LANGUAGE: DE: "/DE/HR-AGENT-KATALOG/TRAINING-EFFECTIVENESS-AGENT/
============================================================

--- Trainings-Wirksamkeits-Agent ---
> Misst die Wirksamkeit betrieblicher Weiterbildung prüfbar nach Kirkpatrick und Phillips - mit Betriebsrat-Freigabe und CSRD-festen Kennzahlen.

Die wirksamste Kennzahl im Trainingsbericht ist die Angabe, wer sie verantwortet. Deutsche Unternehmen geben jährlich rund 1.347 Euro je Beschäftigtem und in Summe 46,4 Milliarden Euro für Weiterbildung aus, doch nur die wenigsten Personalbereiche können dem Vorstand belastbar belegen, was dieses Geld bewirkt hat (Quelle: IW-Weiterbildungserhebung 2023, https://www.iwkoeln.de/studien/susanne-seyda-sabine-koehne-finster-thomas-schleiermacher-investitionsvolumen-auf-hoechststand.html). Der Trainings-Wirksamkeits-Agent schließt diese Lücke nicht mit einem weiteren Dashboard, sondern mit einer prüfbaren Antwort auf die Frage, wie jede einzelne Zahl entstanden ist und ob das Mess-System überhaupt so messen darf.

## Das eigentliche Hindernis ist die Mitbestimmung, nicht die Berechnung

Die Formeln zur Wirksamkeitsmessung sind seit Jahrzehnten etabliert; das Risiko liegt woanders. Jedes System, das geeignet ist, Leistungsdaten von Beschäftigten bereitzustellen, löst die Mitbestimmung nach Paragraph 87 Absatz 1 Nummer 6 BetrVG aus, und zwar bereits durch seine Eignung, nicht erst durch eine tatsächliche Auswertung. Ohne Betriebsvereinbarung ist der Betrieb des Mess-Systems mitbestimmungswidrig, und der Betriebsrat kann per einstweiliger Verfügung dessen Abschaltung erzwingen, während die Einigungsstelle entscheidet. Eine Wirksamkeitsmessung scheitert deshalb in der Praxis nicht an der Mathematik, sondern an der fehlenden Freigabe des Mess-Instruments. Der Agent ist von Beginn an so gebaut, dass er diese Freigabe ermöglicht: Er bewertet keine Personen, sondern rechnet und kennzeichnet.

## Anonymisierung ist eine harte Regel, kein Bericht-Filter

Wirksamkeits-Reports verarbeiten Beschäftigtendaten und dürfen nur so aggregiert erscheinen, dass kein Rückschluss auf Einzelne möglich ist. Der Agent erzwingt dafür technisch eine Mindest-Gruppengröße und fasst zu kleine Gruppen zusammen, bevor überhaupt eine Kennzahl ausgegeben wird. Das ist kein nachgelagerter Filter, sondern Teil der Berechnung selbst. Der Hebel dahinter ist erheblich: Verstöße gegen die Verarbeitungsgrundsätze bewegen sich nach Artikel 83 Absatz 5 DSGVO im Rahmen von bis zu 20 Millionen Euro oder 4 Prozent des weltweiten Konzern-Jahresumsatzes, je nachdem welcher Betrag höher ist (Quelle: Artikel 83 DSGVO, https://dsgvo-gesetz.de/art-83-dsgvo/). Genau deshalb gehört die Anonymität in die deterministische Regelschicht und nicht in eine optionale Einstellung.

## Wirksamkeit messen, ohne Mitarbeitende zu bewerten

Die Arbeitsteilung zwischen Mensch, Regelwerk und KI ist bei diesem Agenten bewusst klar geschnitten und folgt dem Prinzip des [Decision Layer](/de/decision-layer/). Der dominante Anteil ist Regelwerk: Die Synchronisation der Quelldaten, die Anonymisierung, die Stufen eins, zwei und vier nach Kirkpatrick sowie die ROI-Formel nach Phillips sind reine, nachvollziehbare Berechnungen. Künstliche Intelligenz kommt nur an zwei Rändern zum Einsatz, bei der Anomalie-Prüfung der Rohdaten und bei den Verhaltens-Indikatoren der dritten Kirkpatrick-Stufe, und liefert dort ausschließlich Hinweise, die ein Mensch validieren muss. Damit bleibt der Agent außerhalb des Hochrisiko-Bereichs des EU AI Act, dessen einschlägiger Anhang auf Einstellungs- und Vergütungsentscheidungen zielt, und wahrt das Verbot rein automatisierter Einzelentscheidungen nach Artikel 22 DSGVO. Die wenigen echten Entscheidungen, die Interpretation des Bildungsbedarfs und die Freigabe des Reports im Vier-Augen-Prinzip, bleiben beim Menschen.

## Der Prüfpfad entsteht aus der Architektur, nicht als Folgeprojekt

Belastbarkeit zeigt sich erst, wenn jemand nachfragt. Der Agent hinterlegt zu jeder Kennzahl die verwendete Quelldaten-Version, die Mapping-Version, die handelnde Person, den Zeitstempel und den Vorher-Nachher-Stand. Dadurch ist die Nachweisbarkeit für den Wirtschaftsprüfer nach IDW PS 470, für das Auskunftsrecht des Betriebsrats und für die Datenschutz-Aufsicht ein Nebenprodukt der Berechnung statt eines zusätzlichen Dokumentations-Projekts. Wo eine herkömmliche Lernplattform eine Zahl zeigt, zeigt der Agent die Zahl samt ihrer Entscheidungs-Herkunft: gerechnet, KI-Indikator mit menschlicher Validierung oder menschliche Entscheidung. Das ist die Antwort auf die Aufforderung, nicht das Dashboard, sondern den Audit-Trail zu sehen.

## CSRD-Kennzahlen müssen den aktuellen Anwendungsbereich treffen

Wer Trainings-Kennzahlen in den Nachhaltigkeitsbericht übernimmt, braucht zweierlei: belastbare Daten und den richtigen Anwendungsbereich. Der Agent mappt Kennzahlen wie Trainings-Stunden pro Kopf und die geforderten Aufschlüsselungen auf den Standard ESRS S1 und liefert sie wirtschaftsprüferfest. Beim Anwendungsbereich ist Vorsicht geboten: Die häufig genannte Schwelle ab 250 Mitarbeitenden gilt nicht mehr unverändert. Das Omnibus-Paket, in Kraft seit dem 18. März 2026, hebt die Pflicht auf mehr als 1.000 Mitarbeitende und mehr als 450 Millionen Euro Umsatz an (Quelle: Rat und Parlament der EU, https://www.consilium.europa.eu/en/press/press-releases/2025/12/09/council-and-parliament-strike-a-deal-to-simplify-sustainability-reporting-and-due-diligence-requirements-and-boost-eu-competitiveness/). Welche Schwelle für ein Unternehmen gilt, ist daher Teil der fachlichen Prüfung und keine pauschale Annahme.

## Eine Schicht über Ihren Systemen, kein Ersatz

Volumen erzwingt Struktur: Die höchste je gemessene Teilnahmequote an betrieblicher Weiterbildung lag bei 52 Prozent, mit durchschnittlich 28 Stunden je Teilnehmer in Lehrveranstaltungen (Quelle: Statistisches Bundesamt, Pressemitteilung Nr. 505 von 2022, https://www.destatis.de/DE/Presse/Pressemitteilungen/2022/12/PD22_505_215.html). Diese Datenmengen liegen verstreut in Lern- und Personalsystemen wie SAP SuccessFactors, Workday, Cornerstone, Docebo oder Degreed. Der Agent setzt als Entscheidungs- und Nachweis-Schicht darauf auf, liest die Daten über Standard-Schnittstellen, führt sie anonymisiert zusammen und gibt geprüft beschriftete Kennzahlen zurück an Vorstand, Nachhaltigkeitsbericht und Betriebsrat. So wird aus vielen Einzelquellen eine prüfbare Wahrheit. Wie sich diese Wirksamkeitsmessung konkret in Ihren bestehenden Weiterbildungs-Prozess einfügt, zeigt die anschließende Prozess-Analyse Schritt für Schritt.

## Auf einen Blick

- **Was er tut:** Er misst die Wirksamkeit betrieblicher Weiterbildung nachvollziehbar nach Kirkpatrick und Phillips und liefert zu jeder Kennzahl deren Entscheidungs-Herkunft mit.
- **Klassifikation:** Mess- und Analyse-Agent, kein Hochrisiko-System nach dem EU AI Act, da er Personen weder bewertet noch über sie entscheidet.
- **Entscheidungslogik:** Berechnung und Anonymisierung laufen als deterministisches Regelwerk; KI liefert nur Hinweise bei Anomalie-Prüfung und Verhaltens-Indikatoren; Interpretation und Freigabe bleiben beim Menschen.
- **Compliance-Anker:** Betriebsvereinbarung nach Paragraph 87 BetrVG, anonymisierte Auswertung im Rahmen von Artikel 88 DSGVO und Artikel 22 DSGVO, Wahrung der Bußgeldgrenze nach Artikel 83 DSGVO.
- **Integration:** Lese-Schicht über bestehenden Lern- und Personalsystemen wie SAP SuccessFactors, Workday, Cornerstone, Docebo oder Degreed, kein Ersatz für sie.
- **Prüfungsfall:** Prüfpfad für den Wirtschaftsprüfer nach IDW PS 470 und das Auskunftsrecht des Betriebsrats entsteht als Nebenprodukt jeder Berechnung, plus wirtschaftsprüferfeste ESRS-S1-Kennzahlen für den Nachhaltigkeitsbericht.


============================================================
LANGUAGE: EN
============================================================

--- About Us - Enterprise AI Infrastructure since 2001 ---
> Gosign builds Enterprise AI Agents and AI infrastructure. Owner-managed since 2001. 108 employees. Over 5,000 projects for Airbus, VW, Shell.

<article class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<div class="prose prose-lg prose-headings:text-gosign-dark prose-headings:font-bold prose-h2:text-h2 prose-h2:mt-12 prose-h2:mb-4 prose-h3:text-h3 prose-h3:mt-8 prose-h3:mb-3 prose-p:text-gosign-text prose-p:leading-relaxed prose-a:text-gosign-accent-text prose-a:underline prose-a:decoration-gosign-accent-text/30 hover:prose-a:decoration-gosign-accent-text prose-strong:text-gosign-dark prose-ul:text-gosign-text prose-ol:text-gosign-text">

## From Software Projects to Decision Architecture

Gosign was founded in Hamburg in 2001. For over 25 years, we have built complex software systems for mid-market companies and large enterprises - across more than 5,000 projects for organisations including Airbus, Volkswagen, Shell.

What has changed is not our standards - but the technology.

Our roots are in classical enterprise software: system integration, bespoke platforms, ERP-adjacent development and security-driven architectures. As generative AI emerged, we began testing LLM-based workflows in real enterprise environments - initially experimental, then productive in Azure-based enterprise setups.

Today, we build Enterprise AI Agents and the infrastructure that makes them accountable: the [Decision Layer](/en/decision-layer/), which breaks every process into individual decision steps and defines for each step: human, ruleset, or AI.


## What We Stand For

### Decision Quality Over Automation

Enterprises rarely fail because of missing tools. They fail because of inconsistent decision logic.

HR and finance decisions in many organisations are not versioned, not reproducible and dependent on the knowledge of individual employees. Our architecture makes decision logic explicit, traceable and auditable - as a technical layer, not as organisational consulting.

### Governance by Design

Compliance is not an afterthought in our work. Our agents are built so that decision logic is versioned, [Human-in-the-Loop](/en/governance/) is architecturally embedded, audit trails are generated automatically and controls exist as data objects. When certification is required, the system is structurally prepared.

More on our [Governance pages](/en/governance/).

### Integration, Not Replacement

We do not replace existing systems. SAP remains ERP. Workday remains the HR platform. SuccessFactors remains the system of record. We add a decision and governance layer - the Decision Layer that makes agents auditable and controllable.


## How We Work

### Co-Build with Business Functions

Every enterprise has its own compensation logic, its own collective agreements, its own governance requirements and its own ERP structures. That is why we develop [AI agents](/en/services/ai-agents/) in a Co-Build model with HR, finance and IT - not as a finished product, but configured to the specific processes and rules of the organisation.

### Full Source Code Access

Our solutions run in the [client's infrastructure](/en/services/infrastructure/) - on Azure, GCP, AWS or self-hosted. No proprietary SaaS model, no vendor lock-in. Full access to source code, configurations, and rule sets. Handover to independent operation after 12-18 months is part of the model.

Gosign is deliberately not a dependency model.


## Technologies

<div class="not-prose text-body text-gosign-text leading-relaxed">
<a href="https://www.python.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Python</a>, <a href="https://www.typescriptlang.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">TypeScript</a>/<a href="https://nodejs.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Node.js</a>, <a href="https://go.dev/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Go (Golang)</a> - Frontend: <a href="https://react.dev/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">React</a>, <a href="https://nextjs.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Next.js</a>, <a href="https://vuejs.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Vue</a> - Database: <a href="https://www.postgresql.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">PostgreSQL</a>, <a href="https://supabase.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Supabase</a> - Orchestration: <a href="https://trigger.dev" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Trigger.dev</a>, <a href="https://camunda.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Camunda</a>, <a href="https://airflow.apache.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Airflow</a> - Containers: <a href="https://www.docker.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Docker</a>, <a href="https://kubernetes.io/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Kubernetes</a> - Cloud: <a href="https://azure.microsoft.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Azure</a>, <a href="https://cloud.google.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">GCP</a>, <a href="https://aws.amazon.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">AWS</a> - On-Premise: <a href="https://github.com/vllm-project/vllm" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">vLLM</a>, <a href="https://ollama.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Ollama</a>
</div>


## Certifications and Competencies

Our team combines over 25 years of enterprise experience with current cloud and AI certifications. Our AI engineers hold Microsoft Azure AI certifications and work daily with LLM APIs, orchestration frameworks and enterprise integration systems.

<a href="https://www.bvdw.org/en/committees/artificial-intelligence/" target="_blank" rel="noopener noreferrer" class="not-prose flex items-center gap-4 group mt-6">
<img src="/images/badges/bvdw-mitglied.png" alt="BVDW Member" width="349" height="428" class="w-16 h-16 object-contain opacity-60 group-hover:opacity-100 transition-opacity" loading="lazy" />
<span class="text-body text-gosign-text-light group-hover:text-gosign-accent transition-colors">Member of the German Federal Association for the Digital Economy (BVDW)</span>
</a>



## Who We Are

Gosign is owner-managed. 108 employees across offices in Hamburg, Berlin, Kraków, Barcelona, Lisbon and São Paulo. Our largest development centre has been operating in Pakistan since 2002 - founded as a programming school, today an established engineering hub with close ties to the computer science departments at universities in Karachi, Lahore and Islamabad.

<div class="flex flex-col md:flex-row gap-12 not-prose my-8">
<div class="flex-1 text-center">
<img src="/images/team/bert-gogolin.webp" alt="Bert Gogolin, Managing Director Gosign GmbH" width="400" height="400" class="w-48 h-48 lg:w-56 lg:h-56 rounded-full object-cover mx-auto mb-6 border-4 border-gosign-light" />
<h3 class="text-h3 font-bold text-gosign-dark">Bert Gogolin</h3>
<p class="text-body text-gosign-text-light">Managing Director</p>
<a href="https://www.linkedin.com/in/bert-gogolin/" class="inline-flex items-center gap-1 text-small text-gosign-text-light hover:text-gosign-accent mt-2 transition-colors" target="_blank" rel="noopener noreferrer">
<svg class="w-4 h-4" fill="currentColor" viewBox="0 0 24 24"><path d="M20.447 20.452h-3.554v-5.569c0-1.328-.027-3.037-1.852-3.037-1.853 0-2.136 1.445-2.136 2.939v5.667H9.351V9h3.414v1.561h.046c.477-.9 1.637-1.85 3.37-1.85 3.601 0 4.267 2.37 4.267 5.455v6.286zM5.337 7.433a2.062 2.062 0 01-2.063-2.065 2.064 2.064 0 112.063 2.065zm1.782 13.019H3.555V9h3.564v11.452zM22.225 0H1.771C.792 0 0 .774 0 1.729v20.542C0 23.227.792 24 1.771 24h20.451C23.2 24 24 23.227 24 22.271V1.729C24 .774 23.2 0 22.222 0h.003z"/></svg>
LinkedIn
</a>
</div>
<div class="flex-1 text-center">
<img src="/images/team/dieter-gogolin.webp" alt="Dieter Gogolin, Managing Director Gosign GmbH" width="400" height="400" class="w-48 h-48 lg:w-56 lg:h-56 rounded-full object-cover mx-auto mb-6 border-4 border-gosign-light" />
<h3 class="text-h3 font-bold text-gosign-dark">Dieter Gogolin</h3>
<p class="text-body text-gosign-text-light">Managing Director</p>
</div>
</div>

Bert leads client engagements: from initial analysis through process mapping to architecture decisions. Dieter is responsible for operational and strategic business development - from infrastructure and international development teams to partnership strategy.


## Why We Do This

Generative AI is changing how decisions are prepared, documented and accounted for. We believe that AI agents only scale productively when governance is structurally integrated, decision logic becomes explicit and humans remain deliberately involved.

That is what we build the infrastructure for.

All company data at a glance: [Facts & Figures](/en/facts/)

</div>
</div>
</article>

--- AI Agents for Enterprises in Amsterdam | Gosign ---
> Enterprise AI Agents for Amsterdam and the Netherlands. GDPR compliant, EU AI Act ready, Dutch AI Coalition aligned. Auditable AI for Europe's tech hub.

## Amsterdam is the only market where hyperscale tech and systemically important banking share the same postcode

Few European cities combine global tech and systemically relevant banking as densely as Amsterdam. ING, ABN AMRO and Rabobank operate their corporate headquarters here, while Adyen, Booking.com, TomTom and Prosus have made the city the second-largest tech capital market in Europe after London. The wider region adds Philips in Eindhoven and ASML in Veldhoven - the Brainport region complements the Amsterdam financial centre with industrial high-tech competence. Heineken, Shell Netherlands and KLM form the traditional industrial core, while challenger banks such as Bunq and payment players like Mollie shape the FinTech picture. Anyone introducing AI here is building for an audience that understands both PSD2 complaint pathways and ISO/IEC 42001. That mix makes Amsterdam one of the toughest acceptance tests for Enterprise AI in Europe.

## The three regulatory hurdles for AI in the Amsterdam market

The first is the Autoriteit Persoonsgegevens (AP), the Dutch Data Protection Authority. The AP is one of the most enforcement-active regulators in the EU and has made algorithmic audits a standard tool. Since 2023 it has run a dedicated "Algoritmes" supervisory department, regularly publishing guidelines on AI under GDPR. Anyone going productive here has to make every automated decision explainable to data subjects.

The second is De Nederlandsche Bank (DNB) and the Autoriteit Financiele Markten (AFM). Together they set the standard for banks, insurers and pension funds with their joint discussion paper on the use of artificial intelligence in the financial sector - the SAFEST principles. Soundness, Accountability, Fairness, Ethics, Skills and Transparency are the non-negotiable requirements: every AI decision has to stand up to all six.

The third is the national interpretation of the EU AI Act in preparation. The Netherlands is working on its own implementation logic that interlocks the AI Act high-risk categories with the existing DNB and AP regimes. Concretely: an AI system classified as high-risk under the AI Act in Amsterdam additionally falls under the DNB/AFM SAFEST logic. [EU AI Act compliance](/en/governance/eu-ai-act/) has to work twice over.

## Typical deployment scenarios in Amsterdam

ING and ABN AMRO use transaction monitoring to detect money laundering - models that have to remain explainable to DNB examiners, with every single alert reproducible. Adyen processes billions of payments globally and needs fraud detection models that decide in seconds but supply a complete Audit Trail to AFM for every block. Booking.com sits with its dynamic pricing algorithms in the direct collision zone between Article 5 of the EU AI Act (prohibition of manipulative practices) and the Dutch competition authority ACM. ASML in Veldhoven documents patent portfolios and IP disputes in which every AI-supported search has to be evidenced in audit-grade form.

In all four scenarios the question is not "does the model work" - it is "can we defend the model in front of a regulator". That is exactly what the [Decision Layer](/en/decision-layer/) is for: an architecture that persists every decision as a trace, enforces escalation paths for Human-in-the-Loop and exposes Audit Trails directly at SQL level.

Add the ondernemingsraad - the Dutch works council has substantive co-determination rights under the Works Councils Act (WOR) when introducing AI systems. We design the Decision Layer architecture so that the consultation duties towards the OR are not bolted on later but live as integrated parts of the governance.

## How Gosign serves Amsterdam from Hamburg

Hamburg is just over four hours by train or one flight hour from Schiphol. We work remote-first with teams in Amsterdam, Eindhoven and Rotterdam - stand-ups in CET, asynchronous reviews via Linear, monthly on-site workshops in the first three project months. Dutch compliance culture is German-pragmatic enough that the collaboration runs without major translation losses. Discovery workshops are in English, technical documentation we deliver in English and Dutch (reviewed by native speakers), the internal steering rounds with our Hamburg architects run in German.

We have no Amsterdam office. Honestly, for most projects you do not need one. What you need is someone who holds the DNB SAFEST principles and the EU AI Act in the same head - and who can be on site within 24 hours of an AP audit. Both we deliver from Hamburg. Concretely: architects and compliance leads in the Hamburg team, travel budget for quarterly on-site sessions, an escalation SLA of 24 hours for regulatory enquiries.

## Why Amsterdam is a strong starting point for Enterprise AI

Amsterdam forces you to think about AI as regulated infrastructure from day one - not as an innovation experiment. Anyone who builds a pilot here with Cert-Ready by Design has a reference case that is immediately defensible in any other EU market. Clusters such as Amsterdam Smart City, the AMS-Institute and the Brainport ecosystem in Eindhoven supply talent, research and pilot partners. At the same time the distribution is clear: anyone who satisfies DNB, AFM and AP has compliance arguments that work in Frankfurt, Paris or Madrid - usually with less overhead than the Amsterdam version.

We have rolled out Decision Layers with Governance by Design for banks, payment providers and travel-tech businesses across Western Europe. In Amsterdam the bar is high enough that any AI agent that goes productive here is automatically exportable into the rest of Europe. And for German enterprises with Dutch subsidiaries, Amsterdam is the market in which the group AI strategy has to prove itself first - before it scales in Munich or Frankfurt.

--- AI Agents for Enterprises in Barcelona | Gosign ---
> Enterprise AI Agents in Barcelona. Local project management, EU AI Act compliant by design, GDPR compliant. From PoC to independent operation.

## Barcelona is Spain's tech capital - but Spanish AI supervision decides in La Coruna

Anyone building Enterprise AI in Barcelona works inside one of the densest innovation corridors in Southern Europe and at the same time in a market where the regulatory decisions fall 1,100 kilometres further north. The 22@Barcelona district concentrates CaixaBank, Cellnex Telecom, Mango, Desigual, Damm and pharma giant Grifols with its plasma business. In the industrial belt, Seat builds the Cupra range in Martorell, Naturgy runs its port logistics, and Banco Sabadell serves mid-market clients across Catalonia. Pier01 and ESADE Creapolis pull talent into the city - Barcelona is Spain's innovation laboratory. The regulatory reality, however, is shaped at AESIA headquarters in La Coruna and sharpened in Madrid. That split between where engineering happens and where supervision is defined is the single most important fact for any organisation building auditable AI on the Mediterranean coast.

## The three regulatory hurdles for AI in the Catalan market

First, AESIA (Agencia Espanola de Supervision de la Inteligencia Artificial). Spain is the first EU country to stand up a dedicated AI supervisor, with headquarters in La Coruna, and it intends to set the benchmark for national EU AI Act enforcement across the Union. From 2026, AESIA systematically audits high-risk systems and can issue operating bans. Anyone shipping models in Barcelona has to document for an AESIA audit from day one - to the standards set out in the Sandbox programme.

Second, AEPD (Agencia Espanola de Proteccion de Datos) together with the LOPDGDD (Ley Organica 3/2018), Spain's GDPR transposition law with a stricter overlay. The AEPD is known EU-wide for the toughest reading of Article 22 GDPR - fully automated decisions are effectively only admissible in Spain with a documented human final decision. For any AI system touching personal data this means: the [Decision Layer](/en/decision-layer/) with Human-in-the-Loop is not optional, it is a compliance prerequisite.

Third, the CNMV (Comision Nacional del Mercado de Valores) and Banco de Espana for every financial institution. Since 2024 the CNMV has required a complete Audit Trail for AI-driven investment recommendations and reviews model explainability. Alongside this, the Comite de Empresa enforces consultation rights under Article 64 of the Workers' Statute whenever AI systems make decisions affecting employees.

## Typical deployment scenarios in Barcelona

CaixaBank runs one of the largest branch networks in Spain and needs SME credit assessment models that remain reproducible under AEPD supervision - every rejection must be explainable within 14 days. Grifols documents plasma donation chains across hundreds of US and EU centres, where the FDA requires an unbroken Audit Trail and the EMA mirrors the requirement. AI-supported plausibility checks here are not innovation, they are compliance. Cellnex Telecom operates tens of thousands of telecommunications towers across Europe and uses predictive maintenance to prioritise field interventions - every automated triage decision has to remain defensible towards the tower owners, who are frequently institutional investors. Seat plans the Cupra production runs in Martorell and needs AI for capacity planning across multiple plants - the models must withstand VW group audits.

In each of these cases the Decision Layer sits as a governance layer between model and business process, enforcing Audit Trail, escalation paths and Governance by Design - exactly what AESIA, AEPD and CNMV want to see at the same time. Sector-specific requirements add further pressure: pharmaceutical firms like Grifols operate under EMA supervision and must document AI-assisted quality decisions in a GMP-compliant way. Telecoms operators like Cellnex sit under CNMC oversight and must be able to disclose market-power implications of their algorithms. In the automotive sector, the VW group expects a risk assessment on every AI tool running in Seat plants, to the same standard applied in Wolfsburg or Ingolstadt.

## How Gosign serves Catalonia and Spain from Barcelona

Gosign operates its own office in Barcelona (gosign.es) with a Spanish and Catalan team - native speakers, local project management, direct contact with AESIA, AEPD and CNMV. The Barcelona office is the regional hub for the entire Iberian Peninsula: discovery workshops, sprint reviews and steering meetings happen on site at client premises in the 22@ district, at Pier01, or inside the corporate headquarters of CaixaBank, Cellnex, Mango, Damm and Grifols. For Banco Sabadell, Seat in Martorell and Naturgy, workshops in Spanish or Catalan are standard, compliance documentation is delivered bilingually (ES and CA), and the Comite de Empresa sits at the table from the outset. Escalations up to Hamburg only happen for core architectural questions or for connections into German or Swiss parent groups - day-to-day operations, client communication and regulator contact run inside the Barcelona team. The Catalan engineering ecosystem is deep enough to recruit talent directly and anchor it inside the project.

## Why Barcelona is a strong starting point for Enterprise AI

Spain is riding a double wave: AESIA supervision and EU AI Act enforcement move into live operation at the same time. An organisation that builds a Cert-Ready by Design pilot in Barcelona has a reference case that will hold up under both AEPD and AESIA standards - and that will then be immediately defensible in Madrid, Bilbao, Valencia and Milan. The 22@Barcelona cluster, Pier01 and the BStartup programme run by Banco Sabadell deliver talent, pilot partners and investor access. The city is close enough to Madrid and Brussels to react quickly to regulatory developments, and far enough away to hold its own technological character. We bring from the German market the experience of building AI systems that remain productive under strict supervisory regimes - with [EU AI Act compliance](/en/governance/eu-ai-act/) as the baseline and an Audit Trail down to SQL level. Barcelona is the right market in which to scale that discipline across Southern Europe.

--- AI Agents for Enterprises in Belo Horizonte | Gosign ---
> Enterprise AI Agents for Belo Horizonte and Minas Gerais. LGPD-compliant, CLT-compatible. Mining, steel, energy. Management from Sao Paulo.

## Belo Horizonte is the market where Brazilian mining defends its ESG credibility

Minas Gerais produces half of Brazil's iron ore and a large share of the country's steel, gold and aluminium. Belo Horizonte and its surroundings host Vale (with central sites in Nova Lima and Itabira, coordinated from BH), Usiminas (steel, with plants in Ipatinga), AngloGold Ashanti, Magnesita Refratarios, Localiza (Latin America's largest car-rental operator, with its global HQ in BH) and Fiat Chrysler Brasil in the Betim plant. This is the industrial corridor through which every global steel price signal and every ESG investor decision on Brazilian mining passes. It is also the corridor where the Mariana (2015) and Brumadinho (2019) dam collapses have reshaped every risk-based decision-making process for the next 20 years. What passed for operational risk modelling before 2019 is today a legally sensitive domain in which every algorithmic recommendation must be defensible before civil courts and the Federal Public Prosecutor (MPF).

## The three regulatory hurdles for AI in the Belo Horizonte market

ANM documentation duties after Brumadinho: the Agencia Nacional de Mineracao has dramatically tightened dam documentation, stability evidence and risk-reporting obligations since 2019 (Resolucao ANM 95/2022 and subsequent resolutions). Any algorithmic component in dam monitoring, sensor data analysis or risk classification has to be explainable to ANM auditors with a full decision path - Audit Trail down to sensor level.

IBAMA and SEMAD environmental permits: the federal environmental authority IBAMA and the state agency SEMAD MG require detailed environmental impact studies (EIA/RIMA) and continuous monitoring for mining and industrial operations. AI that estimates emissions, optimises process parameters or classifies safety incidents falls inside concrete environmental conditions, with documented explainability available on request of the environmental auditor.

LGPD and co-determination through Sindicatos: the metal and mining Sindicatos (Sindiextra, Sticcer) are historically strong in BH. AI systems that drive shift planning, safety alerting or HR decisioning must be negotiated with Sindicato representatives - LGPD-compliant, with a Decision Layer that renders co-determination workflows in the architecture. The Brazilian CLT (Consolidacao das Leis do Trabalho) and regional collective bargaining agreements (CCT/ACT) make Sindicato consultation a legal prerequisite for any HR agent in the region. The EU AI Act (UK: UK AI regulatory framework) does not apply directly in Brazil; the reference frame is PL 2338/2023 (in preparation) and LGPD.

## Typical deployment scenarios in Belo Horizonte

Vale dam safety monitoring: Workflow Agents watch sensor data on tailings dams in Itabira, Brucutu and other Minas Gerais sites, cross-reference weather data and inspection reports, and the [Decision Layer](/en/decision-layer/) escalates critical risk patterns with Human-in-the-Loop into the geotechnical teams. Every decision is logged for ANM, MPF and internal compliance - the difference between a defensible position and a criminal filing.

Localiza fleet management: Document and Workflow Agents process maintenance logs, damage reports and insurance data for Latin America's largest car-rental fleet. The Decision Layer routes escalations to workshop partners and prioritises critical vehicles for inspection, with an auditable lifecycle per vehicle. After the Unidas merger, Localiza became the world's third-largest rental operator, with matching data volumes and a corresponding demand for algorithmic consistency across regional fleets.

Usiminas steelworks planning: Document Agents read order books, logistics data and energy consumption profiles, and produce production recommendations for the Ipatinga and Cubatao works. The Decision Layer escalates when ANM safety conditions or ANEEL energy contracts conflict with the plan, sending the case to human planners. Workflow Agents proactively flag impending downtime or supply chain breaks and log every recommendation with an Audit Trail.

Fiat Chrysler Brasil Betim quality control: Document Agents process inspection records, quality metrics and supplier audit reports from the largest Fiat plant outside Italy. The Decision Layer escalates critical quality deviations with Human-in-the-Loop to shop-floor leads - the Audit Trail satisfies Stellantis group standards and INMETRO requirements for Brazilian vehicle certification alike.

## How Gosign serves Belo Horizonte from Sao Paulo

Our office in [Sao Paulo](/en/ai-agents-sao-paulo/) is one flight hour from BH. Discovery workshops with Vale, Usiminas or Localiza happen on site in BH or at the plant locations - in Itabira, Ipatinga, Betim. Compliance reviews with ANM or IBAMA exposure are run jointly with your legal team and external environmental counsel, because in mining projects the detailed regulatory reading is often more important than the model architecture. Sindicato consultations, whenever HR or shift-planning agents are in scope, go through local labour-law firms in BH and lean on the historically strong Sindiextra structures. Build phases run distributed between Hamburg and Sao Paulo - stand-ups in SP morning time, joint sprint reviews with plant owners on site. On-site meetings in BH can be arranged within 24 hours, including at remote mining sites in Itabira or Brucutu. After go-live, the Sao Paulo office is your operational contact with a Portuguese-language escalation hotline.

## Why Belo Horizonte is a strong starting point for Enterprise AI

BH is the only market in Brazil where industrial reality (mining, steel, automotive), permanent regulatory pressure (ANM after Brumadinho) and an innovation cluster (San Pedro Valley, P7 Creative Hub) coexist. An organisation that builds a productive agent here for dam safety, production optimisation or ESG reporting builds it against the sharpest audit bar in Brazilian industry - which makes it portable into any other global mining or steel market, from Chile to Western Australia. The Universidade Federal de Minas Gerais (UFMG) and the Universidade Federal de Ouro Preto (UFOP) supply talent in geotechnics, metallurgy and industrial IT at a concentration unmatched anywhere else in Brazil. Gosign's Cert-Ready by Design architecture ensures that an agent proven in BH will also pass European LGPD-equivalent and emerging PL 2338/2023 audits - a prerequisite for ESG investors and for the supply-chain requirements of European buyers from ArcelorMittal to Volkswagen. See also [Rio de Janeiro](/en/ai-agents-rio-de-janeiro/) and [Brazil as a whole](/en/ai-agents-brazil/).

--- AI Agents for Enterprises in Berlin | Gosign ---
> Enterprise AI Agents in Berlin. On-site project management, GDPR-compliant, EU AI Act compliant. From startups to federal ministries - PoC to production.

## Berlin is the only German market in which a federal ministry and a Series-B startup need the same AI provider

No other location in the German-speaking region brings this range together. The government quarter hosts the Federal Chancellery, the Federal Ministry of the Interior (BMI) and the Federal Ministry for Economic Affairs (BMWK) with their IT consolidation programmes and an investment volume that will shape public sector digitalisation for years to come. Three U-Bahn stops away, N26, Solaris, Zalando and Delivery Hero work on scaling questions that have nothing to do with classic banking IT. Cariad runs a software hub in Berlin developing the platform for Volkswagen Group vehicles. Deutsche Bahn operates one of Germany's largest corporate data offices from Potsdamer Platz, SAP has anchored its Data Spaces work here, and IBM and Microsoft maintain research and sales sites in the city. That mix forces an architecture that can model both an administrative procedure with statutory file-keeping duties and a KYC model at N26 cleanly - same Decision Layer, same Audit Trail requirements, but with jurisdiction- and process-specific rule sets layered on top.

## The three regulatory hurdles that define every Berlin AI case

The first hurdle is BaFin (Germany's financial supervisor) oversight of the city's FinTechs. N26 and Solaris are licensed CRR institutions, BaFin circulars on MaRisk and BAIT (Banking Supervisory Requirements for IT) apply in full strictness, and both houses have been through several special audits with conditions in recent years that have shaped the market's understanding of supervisory expectations. Anyone building an AML model or a fraud detection layer with AI here needs a model governance that BaFin special examiners accept as an auditable evidence chain - including versioning, threshold justification and reproducible decisions. The second hurdle is the public sector: the BSI (Federal Office for Information Security) defines the framework with IT-Grundschutz and its AI minimum standards, and the BMI's follow-up programmes to the Online Access Act (OZG) define how automated decisions in administrative procedures must be logged. Both authorities require an Audit Trail that connects to statutory file-keeping. The third hurdle is the EU AI Act itself, which now applies to high-risk classifications - personnel decisions, credit scoring and administrative determinations all fall into at least three application areas in Berlin at once. More background under [Governance EU AI Act](/en/governance/eu-ai-act/).

## Typical deployment scenarios in Berlin

In the public sector the work is around structured intake of applications - funding decisions, file reactivations, citizen enquiries - with clear routing to clerks and a complete file note for every AI step. We see pilot projects where Document Agents classify incoming administrative documents, extract mandatory fields and hand cases to the responsible clerk with a flag for completeness or missing attachments. At N26 and comparable licensed banks we see AML triage agents that enrich transaction monitoring hits with customer history, KYC data and external sources, produce a reasoned plausibility assessment and prepare the Suspicious Activity Report for the compliance officer - the officer decides, the agent documents without gaps. Deutsche Bahn works on predictive maintenance for trainsets and track infrastructure, where a certified maintainer makes the final call but the agent supplies the sensor history and comparable component data as a structured proposal. Cariad and similar OEM software houses need code review agents that understand ASPICE and ISO 26262 and flag critical changes for architecture review. At Zalando and Delivery Hero we see customer service and logistics agents that structure recurring cases and prioritise escalations. What every scenario shares: no fully automated decision, but a [Decision Layer](/en/decision-layer/) with enforced Human-in-the-Loop at the right points.

## How Gosign serves Berlin from Hamburg

We run our own office in Berlin at Nogatstrasse 46 in Neukoelln - not a mailbox, but a base for project management, discovery workshops and the support of public sector clients. The headquarters stays in Hamburg, where engineering and governance architecture come from; in Berlin we keep the operational support for capital region projects. In practice that means: a discovery starts with a two- or three-day workshop at your Berlin offices or in our Berlin office, in the build phase we work remote with two fixed weekly slots on site, and go-live happens on site again. Model validation workshops with BaFin special examiners or with internal audit at licensed banks always happen in person, because that is where the trust relationship with the supervisor is built. On-site sessions between Tiergarten, Mitte and Adlershof are doable inside one day - the Hamburg-Berlin connection via Hauptbahnhof is under two hours by ICE, which keeps the engineering layer in Hamburg flexibly available. Communities and clusters such as Silicon Allee, Factory Berlin and CUBE we use actively to remain technically visible outside of client meetings and to build auditor contacts that later help in conformity assessments.

## Why Berlin is a strong starting point for Enterprise AI

The capital is the only place in Germany where you can combine political framework conditions, supervisory practice and entrepreneurial speed inside a single working day. Anyone who puts a first agent into production in Berlin has typically defended it against three stakeholder groups simultaneously: corporate audit, data protection and the works council. That triple hardening is the best preparation for scaling into other regions. Add data and compute availability via BerlinIX and Telehouse sites with direct interconnects to the major hyperscaler regions, a growing ML engineering talent pool fed by TU Berlin, the Hasso Plattner Institute and the Berlin School of Business and Innovation, and a dense network of AI communities and meetups that makes good practice exchange the default. The physical proximity of policymakers, supervisory practitioners and tech founders inside one urban area shortens stakeholder alignment in a way that no other German market can match. Anyone who has a Decision Layer with Audit Trail in production within 4-6 weeks here meets Cert-Ready by Design for exactly those stakeholders that otherwise create the longest blocking effect inside large groups. More on the approach under [AI Agents Services](/en/services/ai-agents/).

--- AI Agents for Enterprises in Bilbao | Gosign ---
> Enterprise AI Agents for Bilbao and the Basque Country. Industry, energy, banking. EU AI Act compliant. Project management from Barcelona.

## Bilbao is the only Spanish city where heavy industry and energy infrastructure demand AI compliance at the same time

The Basque Country is the industrial antithesis to the tourism-driven south of Spain. In Bilbao and the Bizkaia region sit Iberdrola - the global energy major with group headquarters at Torre Iberdrola - along with Petronor (the Repsol refinery in Muskiz), CAF (Construcciones y Auxiliar de Ferrocarriles) as a rail manufacturer, Tubacex and Sidenor in steel processing, and the Kutxabank group. BBVA has a historic Bilbao site and still runs significant operational functions there, and Euskaltel is the regional telecoms spine. Building AI in Bilbao means building for power grids, blast furnaces, train fleets and platforms whose downtime is counted in millions per hour, not for service industries.

## The three regulatory hurdles for AI in the Basque market

First, the dual data protection regime. Spain is the only EU country with a regional data protection authority operating alongside a national one: the AVPD (Agencia Vasca de Proteccion de Datos) has jurisdiction over public bodies and some regionally anchored organisations in the Basque Country, while the AEPD (Agencia Espanola de Proteccion de Datos) covers the rest. Both authorities implement the LOPDGDD (Ley Organica 3/2018) and examine automated decisions with unusual rigour. Any work with personal data in the region has to consider both authorities inside the compliance architecture.

Second, the CNMV and Banco de Espana for the financial logic inside BBVA and Kutxabank. Both banks have relied on AI-supported risk models for years, but since 2024 the CNMV has required complete explainability for any model contributing to investment recommendations. Audit Trail, reproducibility and escalation paths for risk decisions are no longer negotiable.

Third, the EU AI Act together with industrial safety regimes. Iberdrola operates high-voltage infrastructure, CAF builds rolling stock - in both domains the EU AI Act's high-risk categories (energy infrastructure, critical transport) combine with sector-specific safety standards (UNE-EN, IEC 61508). [EU AI Act compliance](/en/governance/eu-ai-act/) here does not mean "check the data protection box", it means "certify the AI model as a safety-critical component".

## Typical deployment scenarios in Bilbao

Iberdrola optimises smart-grid operations across multiple markets, with models determining which generators take which loads at any moment. Every decision is documented towards the regional grid operator; Audit Trails are a condition for market participation. BBVA develops risk-scoring models for credit decisions in the Basque mid-market, which must be justifiable to customers under Article 22 GDPR. CAF maintains train fleets in multiple European countries and uses telemetry data for predictive maintenance, with recommendations that must remain explainable to supervisory bodies in each operating country. Tubacex relies on AI-supported quality control in specialty steel production, where every automatic rejection decision must be defensible before major customers such as Aramco or Equinor.

Across all four scenarios, the topic is industrial AI with consequences for physical assets. The [Decision Layer](/en/decision-layer/) provides the architecture that wraps these decisions in an Audit Trail, Human-in-the-Loop escalation and Cert-Ready by Design. A Basque specificity matters: the cooperative tradition around Mondragon shapes even the non-cooperative enterprises in the region. Worker participation in technology decisions is not a compliance item here but part of the business culture. We build the Decision Layer so that the co-determination duties of the Comite de Empresa and the cooperative governance structures are met architecturally - not as an after-the-fact consultation but as an integrated workflow inside the system itself.

## How Gosign serves Bilbao from Barcelona

Gosign handles Basque projects out of the Barcelona office (gosign.es) with Spanish-speaking project managers and engineers. The direct Barcelona-Bilbao flight takes around an hour, putting on-site meetings at Torre Iberdrola, the BBVA site, CAF in Beasain, Tubacex and the BEAZ cluster within one working day. The Spanish team supports Basque industry under the regional particulars: the dual data-protection regime of AVPD and AEPD, the cooperative Mondragon tradition with its co-determination structures, and the multilingual reality where Spanish and Euskara sit side by side in technical discussions. Where helpful we bring Basque-speaking stakeholders directly into workshops. Hamburg handles EU-wide compliance topics, architectural principle questions and the interface into German industrial compliance standards; operational delivery, the engineering language of Basque heavy industry and the shorter decision paths of the region stay with the Barcelona team.

## Why Bilbao is a strong starting point for Enterprise AI

Anyone who takes an industrial AI pilot productive in Bilbao holds a reference case that has passed under dual data-protection supervision (AEPD plus AVPD), under CNMV standards and under EU AI Act high-risk logic - the bar is not higher anywhere else in Spain. The BEAZ cluster, Bizkaia Startup Bay and the Mondragon Innovation Hub provide the ecosystem, talent and pilot partners. Basque enterprises also come with a long-term temperament: AI projects are not planned as quarterly pilots here but as multi-year investments.

We bring the experience of building AI systems that not only function but remain defensible under audit conditions - with Governance by Design, an Audit Trail and the discipline that industrial compliance demands. Bilbao is the right market in which to scale that discipline across Northern Spain. There is also a geographic edge: from the Basque Country you reach both the south-French industrial belt (aerospace in Toulouse, pharma in Lyon) and northern Portugal (tech and industry around Porto). An AI architecture that goes productive under Bilbao conditions becomes a reference case for the whole Western European Atlantic arc.

--- AI Agents for Enterprises in Brasilia | Gosign ---
> Enterprise AI Agents for Brasilia. LGPD-compliant, public sector compatible. ANPD in the same city. Auditable AI for government and finance.

## Brasilia is the market where Brazilian AI regulation is actually decided

Brasilia has no corporate headquarters on Sao Paulo's scale and no industrial clusters like Belo Horizonte - but it has something neither of those cities has: every national regulator on a single plateau. ANPD (Autoridade Nacional de Protecao de Dados) sits in the Setor Comercial Sul. BACEN (Banco Central do Brasil) operates from the Setor Bancario Sul. CADE, ANATEL, ANVISA and ANM all sit within a 5-kilometre radius. Alongside them, the federal banks Caixa Economica Federal and Banco do Brasil hold their headquarters on the Setor Bancario, the Ministerio da Fazenda, STF and STJ sit nearby. Building AI in Brasilia for a federal authority, a federal bank or a regulated conglomerate means building it in line of sight of the regulator itself. That makes Brasilia the single most strategically important market for anyone serious about running public-sector AI or regulated banking AI in Brazil - here the rules are not only written, the budget is also signed.

## The three regulatory hurdles for AI in the Brasilia market

ANPD is not an abstract authority here - it is the regulator in whose city you operate. LGPD oversight for federal banks, federal agencies and government data is run out of Brasilia. Building AI that processes citizen data (social benefits, taxes, health) means complying with LGPD Article 23 (public sector) and ANPD Resolution CD/ANPD 02/2022 on DPIAs - auditable, documented, reviewable at any time.

TCU auditability for federal expenditure: the Tribunal de Contas da Uniao audits all federal spending for economic efficiency and legality. Algorithmic components inside Caixa loans, Banco do Brasil risk scoring or Correios route planning must be explainable to TCU auditors with a complete decision path. The [Audit Trail](/en/decision-layer/) is not a best-practice item here, it is the condition on which the authority is permitted to keep working with the vendor at all.

PL 2338/2023 is negotiated here: the Brazilian AI bill is in discussion in the Camara dos Deputados and the Senado Federal - both located in Brasilia. Building in this city means building inside a regulatory conversation where draft language changes between session weeks. The EU AI Act (UK: UK AI regulatory framework) does not apply directly in Brazil; PL 2338/2023 is the local instrument in preparation. Cert-Ready by Design is the only strategy that survives this volatility: architect the system so that high-risk classification, human oversight and explainability duties can be activated after the fact without replatforming.

## Typical deployment scenarios in Brasilia

Caixa Economica Federal credit decisioning: Document Agents review loan applications in social housing (Programa Minha Casa Minha Vida), cross-check them against CadUnico data and external credit bureau data, and the Decision Layer routes decisions to case officers with Human-in-the-Loop - every approval backed by an auditable rationale file for TCU inspections.

ANPD policy analysis for government advisory: Document Agents process ANPD resolutions, LGPD interpretations and consultation papers, producing daily regulatory situation reports for compliance teams inside federal agencies. Workflow Agents raise alerts on new PL 2338/2023 drafts before they reach press cycles.

Banco do Brasil fraud detection: Document and Workflow Agents monitor transaction patterns in real time, escalate anomalies to compliance officers and log every detection with a complete Audit Trail - including confidence scores and model versioning for Coaf filings and BACEN audits. For federal banks the regulatory reporting density exceeds private peers, because CGU (Controladoria-Geral da Uniao) and TCU can raise their own independent queries on top.

Correios route optimisation: Document and Workflow Agents process parcel volumes, postcode clusters and delivery capacity, and suggest optimised routes for Brazil's largest postal logistics operation. The Decision Layer enforces ANATEL delivery-deadline requirements and CLT working-time rules for postal workers architecturally - each recommendation backed by an auditable rationale file for the TCU.

## How Gosign serves Brasilia from Sao Paulo

Our office in [Sao Paulo](/en/ai-agents-sao-paulo/) is 90 flight minutes from Brasilia. Discovery workshops with Caixa, Banco do Brasil or a federal agency happen on site in the Setor Bancario and Setor Comercial. Compliance reviews with ANPD or TCU exposure are run jointly with your in-house legal team in Brasilia, because proximity to the regulator is an operational advantage here - clarification meetings with ANPD staff come together faster for regulated actors than for pure remote vendors. Technical build phases run distributed across Hamburg and Sao Paulo: stand-ups in the SP morning, sprint reviews with your team in Brasilia. On-site meetings can be arranged within 24 hours. On government projects we partner with local law firms for the public-law framework - procurement law, public-sector contracting and LGPD specifics for the public sector are a dedicated specialism that we do not cover in-house but integrate as a partner network.

## Why Brasilia is a strong starting point for Enterprise AI

Brasilia is the only market in Brazil where the regulators and the regulated federal institutions sit in the same city. Building a productive agent here for Caixa credit review, BACEN reporting or government advisory means building in a context where regulatory feedback does not arrive "in six months at audit time" but in the next parliamentary session week. The clusters - Sebrae HQ, BioTIC Park, Universidade de Brasilia - add talent and research partners. Brasilia as a public-sector market works for international providers especially when the architecture combines European-depth audit discipline with Brazilian LGPD and PL 2338 readiness - Governance by Design rather than retrofit compliance patches. Any agent built for a federal authority or a federal bank effectively operates inside a public procurement framework, and in that framework the difference between a retrofitted auditable model and a Cert-Ready by Design architecture is the difference between contract renewal and contract termination. More in the [Brazil overview](/en/ai-agents-brazil/) or in the [Sao Paulo profile](/en/ai-agents-sao-paulo/) for the operational connection.

--- AI Agents for Enterprises in Brazil | Gosign ---
> Enterprise AI Agents for Brazil. LGPD-compliant, CLT-compatible, prepared for PL 2338/2023. Office in Sao Paulo, projects across Brazil.

## Brazil is the only LATAM market where Gosign operates with genuine local presence

Brazil is not "one Latin American market among many". With over 215 million inhabitants, the ninth-largest economy in the world, and a regulatory frame (LGPD, BACEN Resolucao 4893, PL 2338/2023) that stands on its own next to EU law, Brazil is its own compliance universe. Gosign therefore runs an office in Sao Paulo that operationally covers not just the SP metropolitan area but the entire Brazilian market - from Petrobras in Rio to Caixa in Brasilia to Vale in Minas Gerais to Volvo in Curitiba. That is the precondition for making international Enterprise AI standards (Audit Trail, Cert-Ready by Design, Decision Layer with Human-in-the-Loop) work in a market that is related to the EU AI Act but not identical to it.

## The three regulatory hurdles for AI in the Brazilian market

LGPD (Lei Geral de Protecao de Dados) is Brazil's answer to GDPR, not its translation: it has its own legal bases, its own DPO requirements, its own sanctions, and its own supervisory authority in the ANPD (Autoridade Nacional de Protecao de Dados), headquartered in Brasilia. Anyone expanding from Europe into Brazil cannot treat LGPD as a "GDPR variant" - the interpretation of Article 7 (legal bases) and Article 11 (sensitive data) diverges materially in practice. AI architectures must be able to meet LGPD and GDPR in parallel, not in the alternative.

BACEN Resolucao 4893 is Brazil's answer in the DORA space: cyber resilience requirements for regulated financial institutions (Itau, Bradesco, Santander Brasil, Banco do Brasil, Caixa, Nubank, Stone, XP) are developed independently of EU law. Any algorithmic component in credit decisioning, fraud scoring, AML/KYC or capital-markets operations must be BACEN-audit-ready - with reporting duties that differ from European DORA implementations.

PL 2338/2023 is the Brazilian AI bill in preparation: it is inspired by the EU AI Act but not identical - not yet in force in 2026 but expected within the next 18-24 months. Risk classes, human oversight obligations and explainability standards are similar but carry their own Brazilian accents (particularly in the relationship with Sindicatos and CREs on work-related systems). The EU AI Act does not apply directly in Brazil. Cert-Ready by Design in Brazil means: architect the system so that LGPD today, PL 2338 from 2027 and the EU AI Act for DACH operations can be served at the same time.

## Typical deployment scenarios in Brazil

Banking and fintech: KYC/AML at Itau, Bradesco, Santander Brasil and Banco do Brasil - Document Agents parse CPF/CNPJ records, cross-check them with Coaf sanctions lists, and the [Decision Layer](/en/decision-layer/) escalates high-risk hits with a complete Audit Trail. The same pattern at Nubank, Stone, PagSeguro and XP Inc., with fraud detection and BACEN reporting in real time.

Mining and energy: Vale dam safety in [Minas Gerais](/en/ai-agents-belo-horizonte/) and Petrobras asset documentation in [Rio](/en/ai-agents-rio-de-janeiro/) - Workflow Agents watch sensor data, inspection reports and external risk indicators. The Decision Layer escalates critical risk patterns with Human-in-the-Loop, and the Audit Trail is defensible before ANM, MPF, ANP and ANEEL.

Industry and automotive: Volvo, Renault, VW and Klabin in [Curitiba](/en/ai-agents-curitiba/) - Document Agents for supply chain, Mercosul compliance and ESG reporting; Workflow Agents for quality control and maintenance planning. Cert-Ready for GDPR audits in European parent groups.

Public sector: Caixa credit review and ANPD policy analysis in [Brasilia](/en/ai-agents-brasilia/) - Document Agents for social-benefit applications, Workflow Agents for regulatory monitoring. Audit Trail to TCU standards, with a rationale file for every algorithmic recommendation. Public-sector projects in Brazil run under dedicated procurement frameworks and dedicated data-protection standards for citizen data - meeting those frames is a condition for every contract renewal.

## How Gosign serves all of Brazil from Sao Paulo

Our [Sao Paulo](/en/ai-agents-sao-paulo/) office is the operational hub for Brazil - with local project managers who run discovery workshops on site, attend compliance reviews with the DPO and legal team, and accompany Sindicato consultations. From SP, Rio (1 h flight), Belo Horizonte (1 h), Curitiba (1 h), Brasilia (1.5 h) and Porto Alegre (1.5 h) are all reachable within the same day - on-site meetings within 24 hours. The technical build phase is distributed across Hamburg and Sao Paulo, with joint stand-ups in the SP morning. After go-live, the SP office is your operational contact with a Portuguese-language escalation hotline. For Brazilian clients with European operations (for example Natura into the EU, JBS into the EU), this is the only constellation that covers LGPD and GDPR compliance under one roof.

What makes this constellation attractive for German and European mid-market and large corporates: an organisation expanding from DACH into Brazil has a counterpart that covers both worlds operationally - the German corporate parent keeps speaking to the Hamburg team, the Brazilian subsidiary to the Sao Paulo team. Discovery and compliance workshops happen in both languages. An architecture built in Sao Paulo can be taken productive in Lisbon, Madrid or Berlin with minimal adjustment, because the Audit, Decision Layer and Cert-Ready by Design components already serve both regulatory worlds.

## Why Brazil is a strong starting point for Enterprise AI

Brazil is the only Latin American market where banking compliance, industrial operations, public sector and consumer-goods supply chains converge within a single regulatory frame. Building productive agents here for KYC, ESG reporting or dam safety yields a blueprint for Mexico, Argentina, Chile, Colombia and Peru. The SP office positions Gosign as a European provider with real LATAM presence - a combination few competitors in the DACH arena can offer. Gosign's Governance by Design architecture ensures that an agent built in Brazil passes European GDPR and EU AI Act audits as cleanly as it passes BACEN, ANPD or TCU. More in our [contact section](/en/contact/) or in the city overviews for [Sao Paulo](/en/ai-agents-sao-paulo/), [Rio](/en/ai-agents-rio-de-janeiro/) and [Brasilia](/en/ai-agents-brasilia/).

--- AI Agents for Enterprises in Cologne | Gosign ---
> Enterprise AI Agents for Cologne. Media, retail, insurance - auditable AI for document-intensive industries. EU AI Act compliant by design.

## Cologne is the only German location where European aviation supervision, the federal food authority and private media corporations sit inside daily commuting distance

In the corridor between Cologne-Bonn airport, the city centre and the Mediapark you find RTL Deutschland as Europe's largest private TV group, the Ford-Werke in Niehl with the second-largest Ford plant in Europe, the REWE Group with its corporate headquarters, DEVK and Gothaer as two large Cologne-based insurers, and Toyota Germany in Cologne-Marsdorf. TUV Rheinland sits in Cologne and is one of the most important certification bodies in Europe. Just down the road in Cologne-Bonn is EASA, the European Union Aviation Safety Agency; in Bonn sits the BLE (Federal Office for Agriculture and Food). Lufthansa has its registered headquarters in Cologne-Deutz. That combination of industry, media, insurance and several regulatory actors creates a market in which document-intensive processes and auditable decisions are a normal part of daily business.

## The three regulatory hurdles that shape every AI initiative in the Cologne market

The first hurdle is insurance supervision for DEVK, Gothaer and the reinsurance subsidiaries in the area. BaFin (Germany's financial supervisor) requirements on model risk and Solvency II reporting apply to every AI component in claims handling, pricing or reserving. The second hurdle is the media and data compliance block at RTL and comparable houses - the German Interstate Media Treaty (Medienstaatsvertrag), the GDPR specifics for ad-funded platforms, and the Digital Services Act set clear limits on what AI may do in recommendation and moderation logic. The third hurdle is EASA-relevant for Lufthansa and its MRO partners: continuing airworthiness, Part-145 maintenance and Part-M obligations have to be documented for AI components in the maintenance environment in an auditable model history. Add TUV Rheinland itself as a certification body that, for many EU AI Act conformity assessments, is the natural address - a relationship that Cologne enterprises should build early, because the conformity assessment of high-risk AI systems sits with notified bodies like TUV. The BLE in Bonn also matters for REWE and similar food retailers when AI components are used in assortment steering or supplier evaluation. Anyone building an AI architecture in Cologne plans [Cert-Ready by Design](/en/governance/eu-ai-act/) as the standard.

## Typical deployment scenarios in Cologne

At the REWE Group and across the wider food retail sector we see assortment and supply chain agents that distil regional sales data, seasonality and supplier records into a proposal for the category manager - with clear documentation, because food retail sits under EU food information rules and the German Supply Chain Act simultaneously. At the Ford-Werke, agents work on production planning and quality data use cases, with a production engineer making the final call. In the insurance environment at DEVK and Gothaer, agents support claims handling with structured enrichment of the claim notification by policy data, history and expert reports. RTL Deutschland and Lanxess (for plastics and specialty chemicals compliance) need Document Agents for contract analysis and safety data sheets. At TUV Rheinland itself, knowledge agents are relevant for managing testing documentation and standards texts - with clear versioning and Audit Trail. Lufthansa and its MRO subsidiary Lufthansa Technik (headquartered in Hamburg, with strong Cologne ties) work with Document Agents on the preparation of maintenance documentation, where a continuing airworthiness manager makes the final call. At Toyota Germany in Cologne-Marsdorf we see service ticket agents and, in recall management, an enrichment logic that combines VIN data, workshop history and supplier compliance. At DEVK as a major motor insurer, claims handling agents are particularly relevant, because the volume of motor third-party liability cases drives the demand for processing efficiency. The final decision in every case is taken by a qualified technical owner; the [Decision Layer](/en/decision-layer/) holds the rationale and the path.

## How Gosign serves Cologne from Hamburg

Gosign has no permanent location in Cologne - we organise the on-site work from Hamburg and Berlin. The direct ICE Hamburg-Cologne is one of the fastest in the country, on-site meetings are doable inside a single day. Concretely: discovery workshops with engineering, compliance and co-determination owners we run on site in Cologne-Mediapark, on the Rhine waterfront or directly at the client - usually as a two- to three-day block. In the engineering phase we combine remote work with bi-weekly on-site days for architecture reviews and stakeholder updates. TUV Rheinland briefings for EU AI Act conformity assessment always happen in person, because that is where the auditor relationships are built that later help during conformity assessment. Clusters such as the Mediapark, Startplatz Cologne and the AI network of the Cologne Chamber of Commerce (Germany's largest IHK) are active spaces for technical networking, auditor sessions and contacts into the Rhineland Mittelstand. The distance Cologne-Bonn is small enough that EASA-relevant meetings can be picked up on the same day - a logistics that gives a clear advantage for aviation-adjacent use cases.

## Why Cologne is a strong starting point for Enterprise AI

Anyone who puts an AI use case into production in Cologne has the advantage of defending it next to one of the most important certification locations in Europe - TUV Rheinland sits in town and is the natural address for many EU AI Act conformity assessments. That accelerates later scaling significantly, because the audit relationship is built early. Add the sector mix - media, retail, insurance, chemicals, automotive - which serves as a real test for how transferable an AI architecture is across different compliance regimes. Cologne is geographically close to Dusseldorf, Bonn and the Rhine-Main region, which simplifies multi-regional stakeholder meetings. Anyone who has a first Document Agent with a complete Audit Trail in production at a Cologne-based corporate inside 4-6 weeks has a reference that TUV Rheinland already knows - which simplifies the later conformity assessment. More on the approach under [AI Agents Services](/en/services/ai-agents/).

--- AI Agents for Enterprises in Curitiba | Gosign ---
> Enterprise AI Agents for Curitiba and Parana. LGPD-compliant, CLT-compatible. Southern Brazil's tech hub. Management from Sao Paulo.

## Curitiba is the only Brazilian tech hub where European automotive groups cluster denser than German mid-market firms do in a DACH region

Looking at the industrial corridors around Curitiba feels like reading a map of Wolfsburg-Stuttgart-Munich in a tropical edition. Volvo do Brasil builds trucks and buses here. Renault Brasil runs the plant in the Complexo Ayrton Senna in Sao Jose dos Pinhais. Volkswagen Curitiba (also in Sao Jose dos Pinhais) and Audi sit next door. Klabin (Brazil's largest paper maker) has its head office and cluster plants in Telemaco Borba. The Boticario Group (the country's second-largest cosmetics retailer) is based in Sao Jose dos Pinhais. Positivo Tecnologia and Bematech make up the tech cluster. Curitiba is Brazil's most orderly, most planned, most "European" city - which makes it the natural docking point for German and European industrial standards.

## The three regulatory hurdles for AI in the Curitiba market

ANTT (Agencia Nacional de Transportes Terrestres) for logistics and trucking: Volvo, Renault, VW and the Parana logistics industry operate under ANTT supervision for heavy transport, toll systems and driver documentation. AI components in route optimisation, toll reconciliation or driver compliance must support ANTT reporting - with an Audit Trail that records the complete decision path from sensor to CONTRAN violation report. On heavy-freight operations with cross-border Mercosul routes (Argentina, Uruguay, Paraguay), additional customs and documentation duties push every logistics agent into a multi-jurisdictional architecture.

LGPD at Boticario scale: the Boticario Group runs one of the largest CRM and loyalty programmes in Brazil. Any AI component in customer segmentation, personalisation engines or influencer routing must satisfy LGPD Article 7 (legal basis), Article 11 (sensitive data) and the ANPD Resolution on DPIAs (Data Protection Impact Assessments) - including a traceable model version for every decision.

IBAMA and ESG reporting for Klabin: Klabin is considered an ESG flagship, and precisely for that reason the demands on automated reporting (FSC, GRI, SASB) are high. AI that aggregates timber origin, water use or carbon balances must be explainable and hold up before IBAMA, external auditors and ESG investors - Cert-Ready by Design is not a marketing line here but a prerequisite for investor relations.

## Typical deployment scenarios in Curitiba

Volvo Brasil and Renault Brasil supply chain: Document Agents read supplier documentation, customs declarations, Mercosul origin certificates and quality certifications. The [Decision Layer](/en/decision-layer/) escalates Mercosul quota conflicts or compliance gaps to procurement and logistics, while Workflow Agents proactively flag impending supply shortages with an Audit Trail down to the supplier master record. In plants whose upstream suppliers sit in Argentina, Uruguay and Paraguay, Mercosul origin documentation is one of the most customs-critical topics at all.

Boticario CRM and personalisation: Document and Workflow Agents process customer contacts from stores, the app and direct sales (through the Revendedoras structure), LGPD-reconciled against consent status, and the Decision Layer routes campaign recommendations with Human-in-the-Loop to marketing owners. In a direct-sales model with over a million consultants, per-contact consent management is one of the most LGPD-critical topics at all - the Audit Trail must reach back to the individual opt-in receipt.

Klabin sustainability reporting: Document Agents aggregate forest inventory, sawmill logs and energy data into auditable ESG reports in FSC, GRI and SASB formats. The Decision Layer marks data gaps or plausibility conflicts for human validation, with every aggregation carrying a traceable data origin and model version. For listed companies with European ESG investors, this audit depth is a prerequisite for any CSRD reporting.

Positivo Tecnologia supplier compliance: Document Agents vet semiconductor sources, RoHS conformity and Mercosul origin certificates for Brazil's largest local IT hardware manufacturer. Workflow Agents raise alerts on shortages and log every recommendation with an Audit Trail back to the original supplier certificate.

## How Gosign serves Curitiba from Sao Paulo

Our office in [Sao Paulo](/en/ai-agents-sao-paulo/) is one flight hour from Curitiba. Discovery workshops with Volvo, Renault, Klabin or Boticario happen on site - in Curitiba, Sao Jose dos Pinhais or directly at the plant locations. Compliance reviews with LGPD, ANTT or IBAMA exposure are run jointly with your legal team and local outside counsel. Sindicato consultations for HR agents are coordinated with the Parana-based representatives - union structures in the Parana automotive industry are less confrontational than those in Sao Paulo and more technically detailed in discussing algorithmic decisions. Build phases run distributed between Hamburg and Sao Paulo, a 4-hour time offset with stand-ups in the SP morning. On-site meetings in Curitiba can be organised within 24 hours. For German and European parent groups (Volkswagen, Renault, Volvo, Stellantis) we report in parallel in German, English and Portuguese.

## Why Curitiba is a strong starting point for Enterprise AI

Curitiba is the only Brazilian market where German and European industrial groups sit at a density operationally comparable to DACH industrial regions. An organisation that builds a productive agent here for supply chain, quality control or ESG reporting builds it in a setting where the owners have already internalised European standards, which radically shortens the transition from a Parana PoC to a production rollout in Wolfsburg, Stuttgart or Gothenburg. The clusters - Tecpar, Curitiba Smart City, the innovation corridor around the Universidade Federal do Parana - add talent and research partners. Curitiba's reputation as Brazil's "most European" city (urban planning oriented on European models in the 1970s, a strong German- and Italian-descended population, an established German chamber of commerce in Parana) also shows up in daily operations: fewer translation losses in discovery workshops, less cultural friction in sprint planning, and stronger docking into European corporate governance. Gosign's Governance by Design architecture is Cert-Ready for GDPR and EU AI Act from day one - in Curitiba that is not only a regulatory advantage but an operational one. More in the [Brazil overview](/en/ai-agents-brazil/) or in the profile of the [Sao Paulo operations](/en/ai-agents-sao-paulo/).

--- AI Agents for Enterprises in Dublin | Gosign ---
> Enterprise AI Agents for Dublin. EU-headquartered tech companies, DPC oversight, EU AI Act directly applicable. Auditable AI for Ireland's enterprise hub.

## In Dublin a single EU supervisor effectively decides what counts as GDPR-compliant for 450 million Europeans

Dublin is not just another European capital - it is the regulatory capital for US tech in Europe. Google EU, Meta EU, LinkedIn EU, Microsoft EU, Stripe EU and Apple have their European headquarters here, because Ireland offers a combination of tax regime, English language and political stability. Add the Irish heavyweights: AIB (Allied Irish Banks), Bank of Ireland, Accenture (with its global headquarters in Dublin), Ryanair, Kerry Group and CRH (one of the world's largest building materials groups). The Silicon Docks at Grand Canal concentrate more engineering talent for trust and safety, compliance engineering and AI governance into a few square kilometres than any other European city - because the supervisor for exactly those topics sits here.

## The three regulatory hurdles for AI in the Dublin market

The first is the Data Protection Commission (DPC). Because of the GDPR one-stop-shop principle, the DPC is the lead supervisor for almost all US tech corporates with EU headquarters in Ireland - and therefore in practice the most important GDPR authority in the entire union. The DPC has issued several billion-euro fines against Meta, Google and WhatsApp in recent years and has by now extended its scrutiny to AI modelling and training data under the GDPR regime. Anyone building AI in Dublin is building for an authority that examines every training data source, every automated decision and every cross-border transfer in detail.

The second is the EU AI Act, which is directly applicable in Ireland. The Irish government has named the Department of Enterprise, Trade and Employment as the competent body for national implementation and works closely with the DPC. High-risk AI systems from tech corporates with EU headquarters in Dublin will in future be certified here - and the expectation is that the standards will be applied above average strictly, because Dublin politically has to prove that it is not a supervisory loophole.

The third is the Central Bank of Ireland for all financial services firms. Stripe, Mastercard EU, Citi EU, Goldman Sachs EU - they are all under CBI supervision and have to document AI-driven compliance and risk models against the CBI Innovation Hub standards. The CBI requires full explainability, Audit Trails and continuous model monitoring. [EU AI Act compliance](/en/governance/eu-ai-act/) and financial supervision have to interlock here.

## Typical deployment scenarios in Dublin

Google uses Dublin as a global hub for AI model governance and works here on compliance tooling that has to make every model decision explainable to the DPC. Meta documents the Digital Services Act (DSA) here and audits content moderation models for systemic risks - every algorithmic decision needs an Audit Trail. Stripe builds global payment risk models that block or release transactions in seconds - the models have to remain traceable for the CBI. AIB modernises credit decisions and needs models that are defensible under Article 22 GDPR and the Central Bank Code of Conduct in equal measure.

In every case the decisions have global reach but the supervision happens in Dublin - often with short reaction times and tough questions on model behaviour, training data and bias mitigation. The [Decision Layer](/en/decision-layer/) addresses exactly that: it persists every AI decision as a trace, enforces Human-in-the-Loop on critical paths and supplies Audit Trails that hold up to DPC and CBI examiners.

The Irish particularity is the DPC's posture: unlike some EU supervisors that act mostly on complaint, the DPC runs proactive inquiries on a regular basis. Anyone who runs an AI application in production in Dublin has to expect that the DPC will, without warning, ask to see documentation, training data provenance and model decisions. Cert-Ready by Design here does not mean "when the audit comes" - it means permanently audit-ready.

## How Gosign serves Dublin from Hamburg

Hamburg-Dublin is a direct flight of around two hours, with several daily connections. We work remote-first with clients in Dublin and Cork, with on-site workshops for discovery and architecture decisions. The working language is English, the steering rounds with our Hamburg architects run in German. The time zone (Ireland WET, one hour behind CET) is manageable, the Irish business style is pragmatic and decision-friendly.

What we bring from the German market is the discipline of engineering under strict supervision. The German banks we serve have compliance demands from BaFin and MaRisk that are comparable to what Irish tech corporates face from the DPC and CBI - the regulatory tonality is familiar, the technical answers transfer directly. We know the Irish tech supervisory regimes well enough not to have to translate every term first, and can offer concrete architecture decisions in the discovery workshop.

## Why Dublin is a strong starting point for Enterprise AI

Dublin has the highest regulatory bar for AI in Europe - and at the same time the largest concentration of engineering competence for AI governance. Anyone who builds a Cert-Ready by Design pilot here has a reference case that is immediately defensible in any other EU market and that holds up to the DPC. The Silicon Docks cluster, Dublin Tech Cluster and the Enterprise Ireland AI programme supply talent, ecosystem and pilot partners.

The second advantage: anyone building AI in Dublin learns by default how pan-European compliance works. Most Irish tech corporates operate across all 27 member states at the same time - any architecture has to handle jurisdiction-specific rule sets without fragmenting the Audit Trail. That is exactly what Governance by Design delivers. Hamburg supplies the German engineering discipline, Dublin supplies the EU-wide rollout.

--- AI Agents for Enterprises in Dusseldorf | Gosign ---
> Enterprise AI Agents for Dusseldorf and the Rhine-Ruhr region. Works council compatible, GDPR-compliant, EU AI Act compliant. Shared service automation.

## Dusseldorf is the German location where consumer goods, energy, telecoms and industrial Mittelstand all ask the same shared service question on the same urban footprint

In the corridor between Koenigsallee, Oberkassel and the Dusseldorf trade fair grounds you find Henkel, Vodafone Germany's headquarters, E.ON, Metro AG and Uniper - alongside Ergo Insurance as part of the Munich Re group, Rheinmetall as a defence corporation, L'Oreal Germany, and Trivago as Dusseldorf's largest tech employer. Add the entire Rhineland with Bayer and LANXESS in Leverkusen, Henkel sites in Dusseldorf-Holthausen, and a dense Mittelstand between Krefeld, Wuppertal and Duisburg. That concentration creates a specific architectural need: most of these corporates run shared service centres for finance, HR and IT that orchestrate processes across ten to a hundred legal entities at once - each in different jurisdictions, collective bargaining agreements and tax regimes. An AI architecture that works here has to be multi-tenant capable and carry governance rules per entity.

## The three regulatory hurdles that shape every AI initiative in the Dusseldorf market

The first hurdle is NRW-specific energy regulation - the Bundesnetzagentur (BNetzA, Germany's federal network agency) in Bonn is the central regulator for electricity and gas networks, and most of Germany's largest utilities have market operations in Dusseldorf or Essen. E.ON, Uniper and their sales companies work day-to-day with BNetzA data formats and BDEW specifications. An AI component in load forecasting, balancing group management or customer acquisition has to know and use these formats in a traceable way. The second hurdle is the strong co-determination culture in the NRW corporates with works councils experienced in IG Metall, IGBCE and ver.di negotiations - a shared service AI has to architect the Decision Layer so that decisions subject to co-determination must be presented to a qualified employee, and the works agreements have to be planned in from the start. The third hurdle is the German Supply Chain Due Diligence Act (LkSG) and the EU CSDDD - Henkel, L'Oreal, Metro and Rheinmetall have to document risks across their global supply chains and prepare BAFA (Federal Office for Economic Affairs and Export Control) reporting. More background under [Governance EU AI Act](/en/governance/eu-ai-act/).

## Typical deployment scenarios in Dusseldorf

At Henkel and comparable consumer goods groups we see supply chain compliance agents that process incoming supplier documentation in a structured way and escalate risk indicators to a sustainability manager - with a complete Audit Trail for the BAFA report under the German Supply Chain Act. At E.ON and across the wider energy environment the work is around smart meter rollout support and the structured handling of grid connection applications, with case officers making the final call. Metro AG works on assortment steering and product distribution use cases where an agent assesses regional customer data and seasonality and hands a proposal to the category manager. At Ergo and comparable insurers, agents support contract review in life insurance and the analysis of claims accumulations. At Vodafone Germany we see customer service agents that structure customer issues, prioritise call-backs, and for regulated complaint cases under BNetzA rules pass the complete file to a case officer with complaint management responsibility. At L'Oreal Germany and similar consumer goods manufacturers, Document Agents support ingredient compliance and the EU Cosmetics Regulation. At Trivago and across the Dusseldorf tech scene we see agentic support in customer service and content moderation, falling under the Digital Services Act - with a clear escalation to human moderators on sensitive cases. At Rheinmetall in the defence space we see Document Agents in contract analysis and supplier screening that have to meet special audit requirements driven by export controls. In every case the qualified specialist decides, the agent documents, and the [Decision Layer](/en/decision-layer/) holds the rationale as an Audit Trail.

## How Gosign serves Dusseldorf from Hamburg

Gosign has no Dusseldorf location - the on-site work runs from Hamburg and from the Berlin office. The direct ICE Hamburg-Dusseldorf takes just under four hours, a direct flight is significantly faster. Concretely we organise the collaboration like this: kick-off and discovery workshops happen on site in Dusseldorf, usually as a two-day block with engineering, compliance and works council parts. In the build phase we combine remote engineering with bi-weekly on-site days for architecture reviews, model validation and stakeholder updates. When a corporate runs shared services across multiple NRW sites, we visit the relevant locations in turn - Dusseldorf-Holthausen for Henkel, Essen for E.ON, Leverkusen for LANXESS or Bayer. This distributed on-site logic is a particular feature of the Rhineland market, because corporate headquarters in NRW are often physically scattered and stakeholder meetings have to be planned accordingly. Experience from the Rhineland market shows: pragmatism counts more than presence, as long as on-site frequency is right at the decisive stakeholder moments. Clusters such as NRW.Energy4Climate in Dusseldorf we use for networking and technical discussions.

## Why Dusseldorf is a strong starting point for Enterprise AI

Anyone who puts an AI agent into production in a Dusseldorf shared service centre has defended it against at least three jurisdictions, several collective bargaining agreements and an experienced group works council - an architecture that achieves that is then scalable to any other multi-entity constellation in Europe. Add the NRW-specific funding landscape: the State of NRW supports AI projects through several innovation programmes, and the discovery phase typically identifies at least one suitable funding line. Clusters such as the Digital Hub Dusseldorf-Rheinland and the life sciences network in the Rhineland provide technical exchange and co-innovation partners. Add Hochschule Duesseldorf and the nearby universities of Cologne, Bonn and Aachen with their ML engineering programmes, and Forschungszentrum Juelich as an anchor for high-performance computing. Anyone who has a first Workflow Agent in production in an NRW shared service in 4-6 weeks is building on an architecture that is multi-tenant and [Governance by Design](/en/governance/eu-ai-act/) capable. More on the approach under [AI Agents Services](/en/services/ai-agents/).

--- AI Agents for Enterprises in Frankfurt | Gosign ---
> Enterprise AI Agents for Frankfurt's financial centre. BaFin-ready, MaRisk-compliant, EU AI Act compliant. Finance Agents with complete Audit Trail.

## Frankfurt is the only European AI market where the supervisor sits in the same district as the supervised

The banking quarter between Taunusanlage and the Main waterfront contains three regulatory layers at once: the European Central Bank as a central bank and supervisor, BaFin (Germany's financial supervisor) with intensive Frankfurt presence, and the licensed market participants - Deutsche Bank, Commerzbank, DZ Bank, KfW, Helaba, DekaBank, Deutsche Boerse, ING-DiBa, BNP Paribas Germany. Add the market infrastructure specialists like Clearstream and Eurex. When a Frankfurt AI model fails, the next BaFin special examiner has it on the desk inside the same week. That is exactly the strength of the location: nobody can launch a PoC here that is not [Cert-Ready by Design](/en/governance/eu-ai-act/) from the start. The ECB, through the Single Supervisory Mechanism, holds direct supervisory authority over the systemically relevant institutions, which forces Frankfurt-headquartered banks into a dual supervisory logic - European and national. AI components in these houses must be demonstrable to both authorities at the same time.

## The three regulatory hurdles every Frankfurt AI initiative has to clear

The first hurdle is MaRisk and BAIT (Banking Supervisory Requirements for IT) as banking supervisory expectations. Every model that touches risk management, credit decisioning or anti-money-laundering has to be documented with a model validation that holds up to internal audit and BaFin special inspection equally - including backtesting, sensitivity analysis and a reproducible training run. The second hurdle is the MiFID (UK: retained MiFIR/MiFID II under UK law) II block: transaction reporting under Article 26 MiFIR, best execution evidence and the obligations from ESMA Q&A all touch any automated order or advisory component. The EBA Guidelines on ICT Risk Management complete the picture with clear expectations on outsourcing and third-party providers (DORA reinforces this further). The third hurdle is BaFin's own regulatory reporting regime - FinaRisikoV, FinanzInformatikV, ECB stress test data submissions - in which supporting AI components are also part of the supervisory perimeter. Anyone targeting Frankfurt's financial centre plans model governance, Audit Trail and validation as the main work from day one, not as a documentation appendix.

## Typical deployment scenarios in Frankfurt

In anti-money-laundering we see triage agents for AML hits from transaction monitoring systems - the agent enriches the hit with customer history, KYC data and external sources such as sanctions lists and PEP databases, assesses plausibility and hands a proposal to the compliance officer, who decides whether to file a Suspicious Activity Report with the FIU. At the larger securities-services houses, agents help with pre-settlement matching and exception handling - the burdensome reconciliations that today run manually. In MiFID II reporting, agents check the completeness and plausibility of ARM submissions before they are sent. In corporate credit they support the preparation of the credit analysis by structured processing of annual reports, balance sheets and contractual documents - the credit analyst receives a prepared data room with plausibility checks, not an automated rating. At KfW and comparable promotional banks we see Document Agents in application pre-qualification, checking incoming funding applications for completeness and providing case officers with a structured overview of supporting documents. At Deutsche Boerse and in the wider market infrastructure environment, knowledge agents support the management of market standards, ISIN data and listing documentation. In the BAIT-relevant ICT areas, agents help with structured preparation of incident reports and the analysis of penetration test results. What every case shares: the final decision is always made by a human, the agent supplies the reasoned proposal, and the [Decision Layer](/en/decision-layer/) holds the complete chain of input, assessment, confidence and rationale as an Audit Trail.

## How Gosign serves Frankfurt from Hamburg

Gosign has no permanent location in Frankfurt - that is a deliberate choice. We run the headquarters in Hamburg and an office in Berlin; we reach Frankfurt by ICE in under four hours. Concretely: discovery and kick-off sessions and the major risk-and-compliance stakeholder meetings happen on site in Frankfurt - typically as a two-day visit combining workshop, architecture review and auditor briefing. The engineering phase runs remote from Hamburg with bi-weekly on-site days and fixed slots in your compliance office. Model validation workshops with internal audit always happen in person, because that is where the technical discussion with risk and compliance owners shapes the architecture. Experience from the Finance Agent Catalog over recent years shows: this on-site cadence is enough for most BaFin-relevant projects, because the bulk of the work sits in the documented model governance - and that work is no less rigorous when it runs remote.

## Why Frankfurt is a strong starting point for Enterprise AI

The financial centre has a property that makes it stand out as the first step in an AI strategy: anyone who clears a use case here has defended it against the strictest supervisory expectations in Europe. The same model validation then carries in Munich, Stuttgart or Duesseldorf, because no other German supervisor applies tougher standards. Clusters such as the Frankfurt Main Incubator (Commerzbank's innovation arm), TechQuartier at Pollux with its FinTech focus, and the House of Finance at Goethe University deliver the ecosystem context - including the chance to engage directly with BaFin representatives and supervisory practitioners at events. The Eurex and Clearstream structures at the location additionally bring the market infrastructure perspective, where AI components have to meet particularly strict latency and audit requirements. The ECB sits at the centre of regulatory discussion. Anyone who has a Finance Agent with a Cert-Ready Audit Trail in production in 4-6 weeks in Frankfurt has the toughest compliance reference in the country in their portfolio. More on the approach under [AI Agents Services](/en/services/ai-agents/).

--- AI Agents for Enterprises in Gdansk | Gosign ---
> Enterprise AI Agents for Gdansk and the Tri-City. Logistics, energy, IT. EU AI Act compliant, GDPR-compliant.

## Gdansk combines the largest Baltic container port with a rapidly growing tech cluster

Gdansk and the Tri-City (Gdansk, Gdynia, Sopot) are the only place in Poland where large-scale maritime logistics, refinery industry and tech outsourcing operate in direct proximity to one another. The Port of Gdansk is by some distance the largest container port on the Baltic, with connections to Asia, Scandinavia and Western Europe. Lotos (now part of the Orlen group) runs one of the largest refineries in Central Europe here. At the same time, Gdansk hosts Intel Gdansk, Amazon Development Center Gdansk, DNV GL, Schibsted Media Group, Kainos and Asseco. The Gdansk Science & Technology Park and the Alchemia complex form the tech-physical cluster. This blend of heavy industry, port logistics and software engineering creates regulatory demands that do not exist in this combination in any other Polish city.

## The three regulatory hurdles for AI in the Gdansk market

First, the Urzad Morski and maritime regulation: the Port of Gdansk operates under the authority of the Polish maritime administration, under the EU Port Regulation and under a stack of international conventions (SOLAS, MARPOL, ISPS Code). AI that classifies container movements, reviews customs documentation or optimises freight routes must be able to justify every decision against these frameworks. A mis-classification of a hazardous-goods container is not only a compliance incident but is reportable to the EU Commission and can halt port operations.

Second, UODO and KNF for banking and insurance operations in Gdansk: PKO BP, Bank Pekao and several insurers run regional operations centres in the Tri-City. For automated applications and claims handling, KNF and UODO expect the same evidence as in Warsaw - documented model foundations, a complete Audit Trail and a demonstrable human final decision on every risk case. At Amazon Development Center Gdansk, the EU AI Act (UK: UK AI regulatory framework) additionally applies to model training on consumer-relevant datasets.

Third, the EU AI Act in combination with Polish data protection law and sector-specific requirements: DNV GL as a global classification services provider issues certificates that have to be accepted across the shipping industry. AI-supported certificate reviews fall inside the conformity assessment regime of the EU AI Act, and under the specific requirements of the International Maritime Organization. Productive AI in classification in Gdansk needs an architecture that can serve several supervisory bodies at once.

## Typical deployment scenarios in Gdansk

Port of Gdansk container tracking: across millions of container movements per year, every classification - contents, origin, destination, hazardous-goods status - has to be correct and traceable. Document Agents extract structured data from freight papers and customs documentation, and the Decision Layer routes suspicious cases to human customs inspectors with an enforced final decision on hazardous goods.

Lotos refinery logs: the Lotos refinery in Gdansk generates millions of sensor data points and maintenance reports per day. Workflow Agents classify anomalies by safety relevance, the Decision Layer enforces Human-in-the-Loop on safety-critical findings and logs every decision in the Audit Trail - an explicit requirement from the Wojewodzki Inspektorat Ochrony Srodowiska.

Amazon Development Center model-training compliance: Amazon's Gdansk site develops models for consumer applications. Document Agents check training datasets against UODO and EU AI Act requirements, document the data provenance and automatically block the use of datasets without a sufficient legal basis.

DNV GL certificate review: DNV's classification function in Gdansk assesses ships, platforms and components against international standards. Document Agents extract technical specifications, reconcile them against the applicable norms and route conformity decisions to human auditors - the whole process documented audit-firm.

## How Gosign serves Gdansk from Krakow

Gosign handles Gdansk projects out of the Krakow office (gosign.pl) with Polish-speaking engineers and project managers. The Krakow team covers the Trojmiasto region (Gdansk, Gdynia, Sopot) with regular on-site presence - in the Gdansk Science & Technology Park, inside the Alchemia cluster, and directly with stakeholders at the Port of Gdansk, Lotos, Intel Gdansk, Amazon Development Center and DNV GL. Discovery runs as a two-day on-site session, with Polish-speaking domain owners, a compliance function and a Rada Zakladowa representative at the table. Build and sprint reviews then run with the Krakow team, in Polish and English, with monthly on-site steering in the Tri-City and short-notice travel for escalations with Urzad Morski or customs. The Krakow team's maritime logistics experience meets the Hamburg team's architecture and port compliance expertise - Hamburg handles the interface to HPA, German customs and the EU Port Regulation; Krakow handles operational delivery inside the Polish port reality.

## Why Gdansk is a strong starting point for Enterprise AI

Gdansk is the hardest Polish AI market because the regulatory landscape is the most complex - port authority, KNF, UODO, EU AI Act and international shipping regulation all interlock. That is exactly what makes Gdansk the ideal stress test. An AI agent that meets the requirements of the Port of Gdansk has been built on an architecture that functions in practically every other logistics-intensive EU market. The Gdansk Science & Technology Park and the Alchemia cluster offer engineers with this multi-domain experience, and the Politechnika Gdanska delivers a continuous pipeline of talent.

For German mid-market firms with Baltic logistics, Gdansk is often the first foreign location where Enterprise AI is genuinely needed - and therefore the place where the architecture first has to prove itself in a real regulatory wind. The Hamburg-Gdansk axis connects two of Europe's most important Baltic ports; what exists in Hamburg in terms of compliance experience with HPA, German customs and the EU Port Regulation transfers directly to Gdansk. A successful deployment in Gdansk therefore not only opens the Polish market but also provides an architectural blueprint that can be rolled out with minimal adjustment in [Warsaw](/en/ai-agents-warsaw/), [Krakow](/en/ai-agents-krakow/) and [Wroclaw](/en/ai-agents-wroclaw/). Cert-Ready by Design here means in concrete terms: a platform that has proven its fitness under Poland's tightest regulatory pressure. More context on our approach in Poland is available in the [Poland overview](/en/ai-agents-poland/).

--- AI Agents for Enterprises in Germany | Gosign ---
> Enterprise AI Agents for German enterprises. GDPR-compliant, EU AI Act compliant, works council compatible. Headquarters Hamburg, office in Berlin.

## Germany is Gosign's home market - and the EU market with the highest compliance density

Germany combines three properties that exist together in no other EU country: maximum corporate density across multiple sectors, a binding works council co-determination right under Section 87(1) No. 6 of the Works Constitution Act, and a federal supervisory structure with BaFin, BSI, BfDI and sixteen additional state data protection authorities. The corporate landscape reaches from automotive (VW, BMW, Daimler, Porsche, Continental, Bosch, ZF) to chemicals (BASF, Bayer, Evonik, Merck, Covestro), machinery (Siemens, Trumpf, Durr, Kuka, Festo), banking (Deutsche Bank, Commerzbank, the Sparkassen, the cooperative Volks- und Raiffeisenbanken), insurance (Allianz, Munich Re, Ergo, HDI, R+V), energy (RWE, E.ON, EnBW) and retail (Otto, Zalando, Lidl/Kaufland, Rewe, Edeka). Gosign is part of this market with headquarters in [Hamburg](/en/ai-agents-hamburg/) and an office in [Berlin](/en/ai-agents-berlin/) - and the architecture is built precisely for it.

## The three regulatory hurdles for AI in the German market

First, the Works Constitution Act: Section 87(1) No. 6 BetrVG gives the works council a co-determination right over the deployment of technical systems that can monitor employee behaviour or performance. AI systems in HR, in shift planning, in performance analytics, in service-desk routing - all fall inside its scope. A productive deployment without a works agreement is not legally defensible in German corporate groups. The [Decision Layer](/en/decision-layer/) with enforced Human-in-the-Loop is therefore not an architectural feature here, but the precondition for works council approval.

Second, GDPR together with the BDSG and the federal data protection supervision: BfDI at federal level, plus sixteen state data protection commissioners, plus the specifics of the Federal Data Protection Act. For automated decision-making in the sense of Article 22 GDPR, German data protection authorities expect documented legal bases, retrievable explanations, and a complete Audit Trail. The German specificity: the Data Protection Impact Assessment must be completed before go-live for high-risk applications, not in parallel with the rollout.

Third, BaFin, BSI, BNetzA and the EU AI Act: BaFin supervises the financial sector and expects a demonstrable human final decision on risk cases in AML, KYC, credit scoring and claims handling. BSI defines the minimum IT security requirements for KRITIS enterprises. The EU AI Act is being implemented in Germany through the forthcoming Act on the Execution of the AI Regulation - with a focus on high-risk applications in HR, banking, insurance and critical infrastructure. Starting without Cert-Ready by Design means building on an architecture that will need to be retrofitted no later than the first BaFin audit.

## Typical deployment scenarios in Germany

Allianz and Munich Re claims handling: the German insurance leaders process thousands of claims a day. Workflow Agents classify inbound cases by tariff, region and complexity, the Decision Layer routes risk cases to human case managers, and the Audit Trail documents every decision for internal audit and BaFin inspections.

Commerzbank and the Sparkassen AML operations: across millions of transactions per day, Document Agents check identification markers, the Decision Layer routes suspicious cases along the BaFin thresholds, with Human-in-the-Loop on every final escalation.

VW, BMW and Daimler HR operations: German automotive groups have hundreds of thousands of employees and correspondingly complex HR processes. Workflow Agents support recruiting and internal mobility, with enforced human final decisions on personnel measures - a mandatory precondition for works council acceptance under Section 87 BetrVG.

BASF and Bayer production documentation: German chemicals groups generate enormous volumes of safety and quality documentation daily. Document Agents extract regulatorily relevant specifications and reconcile them against REACH, CLP and CE requirements, with a complete Audit Trail back to the source record.

## How Gosign serves Germany from Hamburg and Berlin

Gosign is headquartered in Hamburg (Hallerstrasse 8) with an office in Berlin (Nogatstrasse 46) and a training centre in Hamburg at Grindelberg 77. Discovery workshops happen on site at client locations - in [Munich](/en/ai-agents-munich/), [Frankfurt](/en/ai-agents-frankfurt/), [Stuttgart](/en/ai-agents-stuttgart/), [Dusseldorf](/en/ai-agents-dusseldorf/), [Cologne](/en/ai-agents-cologne/), [Hanover](/en/ai-agents-hanover/) or directly in Hamburg and Berlin. The build then runs remote with German-language documentation, weekly sprint reviews over video, a dedicated point of contact, and on-site visits every four to six weeks. Meetings with the works council, data protection officer and compliance functions are standing items in every project. On-site meetings with BaFin, BSI or state data protection authorities are supported on request jointly with internal legal.

## Why Germany is a strong starting point for Enterprise AI

Germany is not the easiest but the hardest EU market for Enterprise AI compliance. That is precisely what makes it the best starting point. An AI agent that satisfies GDPR, BDSG, BetrVG, BaFin and BSI requirements plus the EU AI Act has been built on an architecture that is only a configuration change away from any other EU country. German compliance culture and works council co-determination enforce Governance by Design - no other EU country demands this with the same consistency.

For DAX groups, MDAX companies and the German Mittelstand with 200 or more employees, this discipline is not a burden but a competitive advantage: what goes productive in Germany goes productive in the EU. An architecture that satisfies BaFin also satisfies the Dutch DNB, the Austrian FMA and the French ACPR. A solution aligned with the works council of a German industrial group can be negotiated with the Rada Zakladowa in Poland, the Comite de Empresa in Spain and the CSE in France without a fundamental re-build. As a Hamburg company, Gosign is part of this market - the architecture is not born from a textbook but from projects inside German corporate groups whose audit expectations shaped every first productive day. Cert-Ready by Design is not a sales argument here but a structural necessity. More context on the [EU AI Act](/en/governance/eu-ai-act/) and the German implementation is in the Governance area.

--- AI Agents for Enterprises in Hanover | Gosign ---
> Enterprise AI Agents for Hanover and Lower Saxony. Industry and mid-market - auditable, works council compatible, EU AI Act compliant. 90 minutes from Hamburg.

## Hanover is the location where the world's second-largest reinsurer, the largest German automotive supplier and the global trade fair business all share the same main station

In the corridor between Hauptbahnhof, the trade fair grounds and List-Sued you find Continental as Germany's second-largest automotive supplier with corporate headquarters, Hannover Re as the world's second-largest reinsurer behind Munich Re, HDI as the primary insurance arm of the Talanx group, TUI as Europe's largest travel group, and VW Commercial Vehicles with its largest plant in Stoecken. Add Sennheiser in Wedemark, Enercon in Aurich (Germany's largest wind turbine manufacturer) and Deutsche Messe AG with the Hannover Messe and the CeBIT legacy. That mix creates a specific AI market structure: corporates with high compliance loads meet a broad technical Mittelstand with concrete automation potential but a need for enterprise-grade governance. Lower Saxony is Germany's third-largest industrial state after NRW and Bavaria.

## The three regulatory hurdles that shape every AI initiative in the Hanover market

The first hurdle is insurance supervision for the Talanx group and Hannover Re. BaFin (Germany's financial supervisor) requirements on model risk, Solvency II reporting and the specific ORSA (Own Risk and Solvency Assessment) obligations for reinsurers touch every AI component in underwriting, reserving and catastrophe modelling. Hannover Re works day-to-day with models for natural catastrophe portfolios and pandemic scenarios, whose validation sits at the highest standard and whose AI components have to be defended against internal model risk frameworks. The second hurdle is the German Federal Immission Control Act (BImSchG), which is relevant day-to-day for Continental as a major industrial producer and for Enercon as a wind power operator - any AI component in emissions monitoring or plant control has to be demonstrable in BImSchG permitting logic. The third hurdle is the strong IG Metall co-determination culture in the Continental and VW plants and at Sennheiser - an AI application that touches personal data or performance measurement only passes the works councils when the [Decision Layer](/en/decision-layer/) enforces a human final call and the Audit Trail documents the rationale. More on the framework under [Governance EU AI Act (UK: UK AI regulatory framework)](/en/governance/eu-ai-act/).

## Typical deployment scenarios in Hanover

At Continental we see quality data agents in tyre production that consolidate measurement data across multiple plants and escalate anomalies to quality engineers - with a traceable assessment. At the VW Commercial Vehicles plant in Stoecken, agents work on production planning and supplier management use cases, with a production steering function making the final call. At HDI and Hannover Re, agents support claims handling and catastrophe modelling - the agent enriches the model results with policy data and external sources, and the underwriters decide. At TUI, customer service agents help with the structuring of customer issues and the prioritisation of call-backs. At Sennheiser and across the wider Mittelstand we see Document Agents for incoming invoices, contract analysis and supplier communication - the typical entry point when a concrete bottleneck in the accounting back office is to be automated. At Enercon, agents work on predictive maintenance preparation for wind turbines, with service technicians deciding when a component is replaced - the agent structures the sensor data, the service manager decides the maintenance window. At Deutsche Messe AG we see knowledge agents in exhibitor and visitor support that structure recurring queries and pass them to fair planning. The Lower Saxony state development bank NBank works with Document Agents in the application review of AI funding projects - here an agent helps with the structured preparation of application files for case officers. In every case the Audit Trail holds the chain of reasoning.

## How Gosign serves Hanover from Hamburg

Hanover is the closest large German market to our Hamburg headquarters - the direct ICE Hamburg-Hanover takes just under 90 minutes. On-site sessions are doable on the same day. Concretely: discovery workshops with engineering, compliance and co-determination owners we run on site, often as a one- or two-day block. In the engineering phase we combine remote work with weekly on-site days, because the short journey makes that possible without logistical friction. Architecture reviews, model validation for Solvency II and co-determination negotiations happen in person. For Continental and Hannover Re with their corporate headquarters in central Hanover, we are often on site several times per month - the proximity removes the on-site frequency from the logistics conversation. Clusters such as Hannover Impuls (the city's economic development agency) and the Innovation Network Lower Saxony we use for technical discussion and for contacts to NBank, which supports many AI projects in the Lower Saxony Mittelstand. The Hannover Messe as the world's largest industrial trade fair delivers a compact annual market overview and is for many of our client projects a natural anchor for product decisions.

## Why Hanover is a strong starting point for Enterprise AI

Hanover has a property no other German market shares: the combination of corporate headquarters with high compliance loads and a broad technical Mittelstand that not only acts as a supply chain to the corporates but serves its own global markets. Anyone who puts a first AI agent into production here typically has it tested against insurance compliance, industrial co-determination and Mittelstand pragmatism - the three toughest stress tests the German market has to offer. Add the geography: 90 minutes to Hamburg, two hours to Berlin, three hours to Frankfurt. Hanover is therefore a natural anchor for multi-regional scaling in the DACH region. The ML engineering talent comes from Leibniz University Hanover with its strong computer science faculty, from the L3S research centre with a focus on web science and ML, and from the DFKI site as an anchor for applied AI research. Anyone who has an agent in production in a Hanover-based corporate or Mittelstand business in 4-6 weeks benefits from the proximity to Hamburg engineering and can later transfer the use case across the entire Northern Germany network. More on the approach under [AI Agents Services](/en/services/ai-agents/).

--- AI Agents for Enterprises in Krakow | Gosign ---
> Enterprise AI Agents in Krakow. Local project management, EU AI Act compliant by design, GDPR-compliant. From PoC to independent operation.

## Krakow is Poland's shared-service capital - and exactly for that reason the hardest AI location

Krakow hosts the largest concentration of Global Capability Centres in Central Europe. ABB Krakow runs its global engineering documentation here, Cisco Krakow operates one of the largest software development units outside the US, IBM Krakow is a delivery centre with thousands of consultants, and alongside them sit ING Hubs Krakow, Capgemini, Motorola Solutions, EY GDS and the Polish IT group Comarch. What these sites have in common: they process data from several EU jurisdictions, their outputs end up in the books of Western European parent groups, and every AI decision has to withstand Polish UODO, Polish RODO implementation and the regulators of the parent countries at the same time. Krakow is not just a Polish city - it is the engine room for many European corporates.

## The three regulatory hurdles for AI in the Krakow market

First, RODO and the Polish Personal Data Protection Act (ustawa o ochronie danych osobowych): UODO (Urzad Ochrony Danych Osobowych) expects documented foundations, retrievable explanations and a complete Audit Trail for automated decision-making. Because Krakow GCCs process data from Germany, France, the Netherlands and Scandinavia, every AI decision must also hold up before the relevant national supervisory authority in the parent country. An architecture that only meets RODO is insufficient for group-wide shared services.

Second, KNF supervision for the growing number of banking and insurance operations in Krakow: ING Hubs Krakow, Aon, Brown Brothers Harriman and other financial services firms sit under direct or indirect Komisja Nadzoru Finansowego oversight. For transaction monitoring, AML screening and underwriting recommendations, KNF expects the same evidence as BaFin or the Dutch DNB - including traceable model foundations and a logged human final decision.

Third, the EU AI Act (UK: UK AI regulatory framework), which applies in Poland from February 2025 for prohibited practices and, for high-risk systems, from 2 August 2026 under current law (with a postponement to 2 December 2027 provisionally agreed under the Digital Omnibus of 7 May 2026, formal adoption still pending): HR screening, creditworthiness assessment and biometric identification fall into the high-risk category. Krakow sites that develop or operate such systems for parent groups must be able to evidence conformity assessments, risk management and post-market monitoring - a technical debt that is hard to pay down retrospectively.

## Typical deployment scenarios in Krakow

Comarch banking software QA: Comarch's banking suite is used by hundreds of Polish and Central European financial institutions. Document Agents check release notes, regulatory updates and patch documentation against KNF requirements before a release ships, with a complete Audit Trail back to the source PR.

ABB Krakow engineering documentation: ABB's global engineering centre in Krakow generates thousands of technical documents per day in multiple languages. Workflow Agents extract regulatorily relevant specifications, reconcile them against country-specific norms and automatically route conflicts to human reviewers.

ING Hubs transaction monitoring: in an ING shared service with millions of transactions per day, every second of delay determines regulatory reporting duties. The [Decision Layer](/en/decision-layer/) routes suspicious cases inside the KNF and DNB thresholds, with enforced Human-in-the-Loop on every final escalation.

Capgemini delivery operations: Krakow delivery teams serve large clients across multiple EU countries. Service-desk routing agents classify tickets by language, tenant and escalation path - every decision auditable against the relevant regulatory standard.

## How Gosign serves Poland from Krakow

Gosign operates its own office in Krakow (gosign.pl) with Polish-speaking project managers, engineers and compliance owners - native Polish and English speakers who work directly on site with clients at Krakow Technology Park, Hub:raum or inside the premises of the parent group. Discovery workshops, sprint reviews and steering happen without a language barrier or travel overhead, with the Rada Zakladowa representative in the same room. Krakow acts as the regional hub for the whole of Poland: most ABB, Cisco, Capgemini and IBM sites are reachable inside the same city, and Warsaw, Wroclaw and Gdansk are all same-day reachable. Hamburg contributes architectural reviews, DACH compliance expertise and the interface into German or Swiss parent groups; delivery, day-to-day operations and direct client contact sit with the Krakow team. For an outsourcing country with more than 350,000 IT engineers, this is the only set-up that really works: locally anchored, EU-wide connectable.

## Why Krakow is a strong starting point for Enterprise AI

Krakow has three properties that make it unique as an entry point. First, the density of talent: Krakow Technology Park, Hub:raum and the Krakow Startups Cluster form the largest technology ecosystem between Berlin and Vienna, with thousands of engineers trained multilingually on corporate processes. Second, the multi-jurisdictional reality: an AI agent built in Krakow to be compliance-ready for ABB, Cisco or ING has implicitly been built for the whole EU West. An architecture that holds up in a Krakow GCC before Polish UODO, the Dutch DNB and German BaFin at the same time is only a configuration exercise away in any other EU country. Third, operational maturity: Krakow GCCs have worked with Western European groups for more than fifteen years, and the internal processes for change management, ITIL, ISO 27001 and SOX compliance are mature. Introducing a new Decision Layer component here does not mean learning a new compliance discipline but extending an existing one with an additional control layer.

Cert-Ready by Design in this environment is not marketing but a precondition for day one of operations. Starting in Krakow puts the hardest test behind you before the first Western European subsidiary goes live - and an agent that is production-ready in Krakow can be rolled out in [Warsaw](/en/ai-agents-warsaw/), [Wroclaw](/en/ai-agents-wroclaw/) or [Gdansk](/en/ai-agents-gdansk/) inside a few weeks, because the technical foundation stays identical and only the regulatory configuration files change. More context on the [EU AI Act](/en/governance/eu-ai-act/) and the Polish application is in the Governance area.

--- AI Agents for Enterprises in Lisbon | Gosign ---
> Enterprise AI Agents in Lisbon. Local project management, EU AI Act directly applicable, GDPR compliant. From PoC to independent operation.

## Lisbon is Europe's fastest-growing tech capital - with a surprisingly strict data protection regime in the background

Over the past decade Lisbon has moved from tourist secret to tech hub for Western Europe. EDP (Energias de Portugal) and Galp Energia form the energy core, Millennium BCP and Caixa Geral de Depositos the banking spine, Jeronimo Martins (Pingo Doce, Recheio, Biedronka in Poland) is the country's largest food retailer. NOS and Altice Portugal dominate the telecoms landscape. Add the Portuguese tech champions: Farfetch (the luxury fashion marketplace), OutSystems (the low-code platform with global scale) and Feedzai (AI-driven fraud detection for banks worldwide). The Beato Innovation District and the Hub Criativo do Beato host hundreds of startups - the city pulls talent from across Europe because the cost of living is lower than in Berlin or Amsterdam and the tech ecosystem keeps getting denser.

## The three regulatory hurdles for AI in the Portuguese market

The first is the CNPD (Comissao Nacional de Proteccao de Dados) together with Lei 58/2019, the Portuguese GDPR implementation law. The CNPD is one of the most consistent data protection authorities in Southern Europe and has imposed several high-profile fines on telecoms operators, banks and public bodies in recent years. The CNPD examines AI systems in particular for transparency, data minimisation and the right to a human decision under Article 22 GDPR. Anyone building AI in Lisbon is building for an authority that takes algorithmic audits seriously.

The second is the EU AI Act, which is directly applicable in Portugal. The Portuguese government has named ANACOM (the national communications authority) and the CNPD as coordinating bodies for the EU AI Act implementation, with the plan to build its own market surveillance authority. High-risk systems - especially in energy and finance - will be systematically reviewed from 2026 onwards.

The third is Banco de Portugal and the CMVM (Comissao do Mercado de Valores Mobiliarios) for all financial services firms. Both authorities have set out joint expectations on AI model governance: explainability, Audit Trail, reproducibility and bias mitigation. Banks such as Millennium BCP and Caixa Geral de Depositos are already working on frameworks of this kind. [EU AI Act compliance](/en/governance/eu-ai-act/) and financial supervision interlock here.

## Typical deployment scenarios in Lisbon

Millennium BCP uses AI in credit analysis for SME customers and needs models that remain reproducible under CNPD and Banco de Portugal supervision - every refusal has to be justifiable inside the legal time window. EDP operates smart meter infrastructure in Portugal, Spain and Brazil and uses AI for load forecasting and anomaly detection in the grid - the models have to be documented for the energy regulator ERSE. Feedzai develops fraud detection models for banks worldwide, headquartered in Lisbon - every model update has to remain traceable in an Audit Trail because the customers run in regulated markets. Farfetch uses recommendation algorithms for luxury products in more than 190 countries - here CNPD requirements collide with the data protection regimes of the UK, the US and China.

In every scenario the question is about AI models that do not live in the lab but in regulated business logic with measurable consequences. The [Decision Layer](/en/decision-layer/) addresses the architecture question: Audit Trail down to SQL level, Human-in-the-Loop on escalation-relevant cases, Cert-Ready by Design.

A Portuguese particularity is the Comissao de Trabalhadores - the Workers' Committee with information and consultation rights when AI systems are introduced. We design the Decision Layer so that these duties do not have to be retrofitted but live inside the governance. That is particularly relevant for groups like Jeronimo Martins, whose headcount is in the five-figure range and whose AI decisions have direct effects on staffing and shift planning.

## How Gosign serves Portugal from Lisbon

Gosign has its own office in Lisbon (gosign.pt) with a Portuguese team - native speakers, local project management, direct contact to the CNPD, Banco de Portugal and CMVM. The Lisbon office is the regional hub for the Portuguese market: discovery workshops, sprint reviews and steering happen on site at the client in the Beato Innovation District, in the Hub Criativo do Beato or directly at the corporate headquarters of Galp Energia, EDP, Millennium BCP, Caixa Geral de Depositos and Jeronimo Martins. For the Portuguese tech champions Feedzai, OutSystems and Farfetch we work as peers in the local engineering culture, with workshops and code reviews in Portuguese, compliance documentation in Portuguese and English, and the Comissao de Trabalhadores at the table from the start. We cooperate closely with Startup Lisboa and the local talent pool. For LATAM projects the Lisbon team additionally pairs with the Sao Paulo office (gosign.com.br) - Brazil and Portugal as one connected lusophone market with a shared language, a shared business culture and an architecture that serves LGPD and GDPR in parallel. The Hamburg headquarters takes care of architectural questions of principle and the link to German and Northern European parent companies.

## Why Lisbon is a strong starting point for Enterprise AI

Portugal is small enough to bring several industry stakeholders directly into the same AI project, and large enough to carry real compliance demands. Anyone who builds a Cert-Ready by Design pilot in Lisbon has a reference case that has passed under CNPD and EU AI Act standards and is then defensible in Brazil (LGPD), Spain (LOPDGDD) and the rest of Europe. The Lisbon Tech Hub, Startup Lisboa and the Beato Innovation District supply talent, investor access and pilot partners.

We bring the experience of building AI systems that stay productive even under strict CNPD supervision - with Governance by Design and the discipline shaped by German data protection practice. Lisbon is the right market in which to scale that discipline across the Iberian peninsula. And for enterprises that use the Portuguese market as a springboard into the lusophone space (Brazil, Angola, Mozambique), Lisbon is the only European location from which that bridge can be built architecturally cleanly.

--- AI Agents for Enterprises in London | Gosign ---
> Enterprise AI Agents for London. Post-Brexit UK GDPR compliant, EU AI Act ready for EU operations, FCA-aware. Auditable AI for the City and beyond.

## In London every AI decision has to satisfy two data protection regimes at once - and that is the most expensive compliance gap in Europe

Since Brexit, London is no longer the EU financial centre but Europe's compliance double-header. HSBC, Barclays, Lloyds Banking Group, NatWest, Standard Chartered and Prudential operate their corporate headquarters here. BP and Shell have their global HQs in London, AstraZeneca coordinates clinical trials worldwide from here, and on the tech side sit Revolut, DeepMind and Arm Holdings. The Square Mile is still the largest financial centre in Europe and probably the only market where a single firm has to comply with UK regulation, EU regulation and US sanctions regimes at the same time - often in the same system. Anyone building Enterprise AI here is not building for one jurisdiction, but for an intersection.

## The three regulatory hurdles for AI in the London market

The first is the dual data protection regime: UK GDPR plus EU GDPR. Since Brexit, UK firms operate under UK GDPR, but as soon as a firm has business with EU customers - which practically every London-based corporate does - EU GDPR also applies in parallel under the adequacy mechanism. The ICO (Information Commissioner's Office) supervises the UK side, and a different EU supervisor handles the EU side depending on which subsidiary is involved. Both regimes are diverging on detail points - on automated decision-making under Article 22, on data transfer mechanisms - and any AI architecture built here has to be dual-compliant.

The second is the UK approach to AI governance, which is sector-based rather than horizontal like the EU AI Act. The FCA (Financial Conduct Authority), the PRA (Prudential Regulation Authority), the ICO and the CMA (Competition and Markets Authority) each develop their own AI guidance for their sector. The FCA, through the AI Public-Private Forum, has already articulated concrete expectations on model governance, explainability and board accountability. Anyone building banking AI in London is building for at least four supervisors at the same time - in different depth.

The third is the DSA and DMA for London-based platforms with EU business. Anyone reaching European consumers from London falls under EU platform regulation regardless of UK law. [EU AI Act compliance](/en/governance/eu-ai-act/) becomes the interface here: UK firms with substantial EU business have to behave in practice like EU firms without the protection of EU membership.

## Typical deployment scenarios in London

HSBC operates global fraud detection with AI models live in more than 60 countries that have to stand up to the FCA, the ICO, EU supervision and the US OCC at the same time. Lloyd's of London uses AI for underwriting decisions in specialty insurance - every automated risk assessment has to be documented to Lloyd's Performance Management Directorate and remain reproducible in the event of a claim. The FCA itself expects its regulated firms to apply Conduct Rule compliance to AI tools in a way that makes board accountability traceable. AstraZeneca documents clinical trials for the MHRA and in parallel for the EMA - every AI-assisted analysis has to be evidenceable in both regimes.

In every scenario the central question is not "does the model work" but "can we defend the decision across jurisdictions". The [Decision Layer](/en/decision-layer/) does exactly that: it routes every decision through jurisdiction-specific rule sets, persists the Audit Trail with full metadata, and enforces Human-in-the-Loop on decisions that are audit-relevant in more than one regime.

Add the personal accountability supervisors: the UK Senior Managers and Certification Regime (SMCR) makes individual board members personally accountable for AI decisions in their areas. A director of a UK financial firm who introduces AI without being able to evidence the model governance risks a personal industry ban. That is one notch sharper than continental GDPR fines - and it is the reason UK banks have been taking Cert-Ready by Design seriously for years.

## How Gosign serves London from Hamburg

Hamburg-London is a direct flight of around 90 minutes, with several daily connections via LH, BA and EasyJet. We work remote-first with clients in the City and Canary Wharf, with on-site workshops for discovery, architecture decisions and critical compliance reviews. The working language is English, the steering rounds with our Hamburg architects run in German. The time zone (London GMT/BST, one hour behind CET) is manageable and overlaps fully with the Hamburg working day.

What we bring from the German market is experience with dual regulation. German banks routinely work with BaFin, the ECB and the FCA simultaneously - the cross-jurisdictional compliance logic is familiar to us. We know the FCA expectations on model governance well enough to take concrete architecture decisions in the first workshop, instead of having to translate regulators first.

## Why London is a strong starting point for Enterprise AI

London has the highest regulatory pressure for AI in Europe, because two diverging data protection regimes meet here. Anyone who builds a Cert-Ready by Design pilot in London that is dual-compliant has a reference case that is defensible in any other market - including the US, Switzerland and APAC. The Silicon Roundabout cluster, Canary Wharf, the London Tech City programme and the Tech Nation network supply talent, ecosystem and pilot partners.

The second advantage: London forces an architecture that is not built for a single jurisdiction but for jurisdiction-specific rule sets over the same Audit Trail. That is Governance by Design - and if it works in London, it works anywhere. Hamburg supplies the German engineering discipline; London supplies the global compliance stress test.

--- AI Agents for Enterprises in Madrid | Gosign ---
> Enterprise AI Agents for Madrid. AESIA headquarters, EU AI Act regulation, GDPR compliant. Auditable AI for Spain's business capital.

## Madrid is the only European capital where the national data protection and financial regulators sit within walking distance of one another

Building Enterprise AI in Madrid means literally building on the doorstep of Spanish supervision. AEPD (Agencia Espanola de Proteccion de Datos), CNMV (Comision Nacional del Mercado de Valores), Banco de Espana and CNMC (Comision Nacional de los Mercados y la Competencia) - all four are headquartered in Madrid. On top of that, the political apparatus: the Ministerio de Asuntos Economicos and the Ministerio de Industria, Comercio y Turismo decide here on the EU AI Act implementation. In the corporate sector, Banco Santander, BBVA, Telefonica, Repsol, Iberdrola (HQ Bilbao, but Madrid is operationally strong), Mapfre, Ferrovial, ACS, Naturgy, Red Electrica and Amadeus IT sit in the city. Building an AI architecture here means building for a concentration of big corporates and supervisors only Frankfurt and Paris match in Europe.

## The three regulatory hurdles for AI in the Madrid market

First, the AEPD and the LOPDGDD (Ley Organica 3/2018), Spain's GDPR transposition law with a stricter overlay. The AEPD is known EU-wide for its strict reading of Article 22 GDPR - fully automated decisions are effectively only admissible in Spain with a documented human final decision. The authority has issued several fines in the eight- and nine-figure euro range in recent years, often against banks and telecoms. The Decision Layer with Human-in-the-Loop is not optional here, it is a compliance prerequisite.

Second, the AESIA (Agencia Espanola de Supervision de la Inteligencia Artificial). Spain is the first EU country to stand up a dedicated AI supervisor. The headquarters is in La Coruna, but operationally and politically much is decided in Madrid. From 2026, AESIA systematically audits high-risk systems under the EU AI Act and can issue operating bans. Anyone shipping models in Madrid has to document for an AESIA audit from day one.

Third, CNMV and Banco de Espana for the entire financial sector. Both authorities have articulated joint expectations for AI model governance and review banks, insurers and asset managers on explainability, Audit Trail and reproducibility. Since 2024 the CNMV has required a complete Audit Trail for AI-driven investment recommendations. [EU AI Act compliance](/en/governance/eu-ai-act/) and financial supervision interlock here.

## Typical deployment scenarios in Madrid

Banco Santander runs credit decisioning in more than ten countries and needs AI models that remain reproducible under AEPD, CNMV and Banco de Espana supervision - every rejection must be explainable within the statutory deadline. Telefonica analyses Call Detail Records for fraud detection and network optimisation across more than twelve markets - the models must remain auditable towards AEPD and ANACOM. Mapfre uses AI in claims settlement and needs models that can justify every automated loss estimate towards the policyholder. Iberdrola plans power-grid operations in Madrid that fall into high-risk categories of the EU AI Act - the models must be documented for Red Electrica and the national energy regulator CNMC.

In each of these cases the [Decision Layer](/en/decision-layer/) is the architecture that brings Audit Trail down to SQL level, Human-in-the-Loop escalation and Cert-Ready by Design into one place - exactly what the Madrid supervisors want to see at the same time. A Madrid specificity is the group complexity: most large Spanish companies are woven through Ibero-America and beyond - Santander in more than ten countries, BBVA in Mexico and Turkey, Telefonica in Brazil and Germany. An AI architecture in Madrid must be capable of enforcing jurisdiction-specific rule sets for GDPR, LGPD, the Mexican LFPDPPP and the Turkish KVKK simultaneously - all over the same Audit Trail. Building that in Madrid produces an architecture for the entire Spanish-speaking world.

## How Gosign serves Madrid from Barcelona

Gosign handles Madrid projects out of the Barcelona office (gosign.es) with Spanish-speaking project managers and engineers. The AVE high-speed connection Barcelona-Madrid runs in just under two and a half hours - weekly on-site meetings at Santander, BBVA, Telefonica, Mapfre, Iberdrola and Repsol are not a logistical lift but routine. Discovery workshops, sprint reviews and steering rounds happen on site on Paseo de la Castellana, in Las Tablas or directly at corporate headquarters, with Spanish-speaking domain owners and Comite de Empresa representatives at the same table. Madrid hosts the main Spanish regulators - AEPD, CNMV, Banco de Espana and CNMC are within walking distance of each other - and the Spanish team is regularly on site to run regulatory alignment, audit preparation and sandbox meetings directly. Hamburg handles DACH and international coordination plus architectural reviews; operational day-to-day work, Madrid corporate culture and regulator contact sit with the Barcelona team.

## Why Madrid is a strong starting point for Enterprise AI

Madrid is the only city in Europe in which all four Spanish supervisory authorities are reachable on foot - and in which most regulatory answers come within days rather than weeks. An organisation that builds a Cert-Ready by Design pilot here holds a reference case that has passed under AEPD, AESIA, CNMV and Banco de Espana standards. The Madrid in Motion cluster, Impact Hub Madrid and Wayra Madrid (Telefonica) provide talent, pilot partners and investor access.

We bring from the German market the experience of building AI systems that do not only function under strict supervisory regimes but remain productive - with Governance by Design and an Audit Trail. Madrid is the right market in which to carry that discipline into the heart of the Spanish economy.

--- AI Agents for Enterprises in Poland | Gosign ---
> Enterprise AI Agents for Polish enterprises. EU AI Act compliant, GDPR-compliant, Works Council compatible. Office in Krakow, projects across Poland.

## Poland is simultaneously Europe's largest IT outsourcing country and a stand-alone digital economy

Poland is the only EU market in which two structurally different tech economies sit side by side. On one side, the Global Capability Centres of Western European corporates in [Krakow](/en/ai-agents-krakow/), [Wroclaw](/en/ai-agents-wroclaw/) and [Gdansk](/en/ai-agents-gdansk/) - ABB, Cisco, IBM, Capgemini, UBS, Bosch, LG Electronics, Amazon Development Center, Volvo, Toyota Motor Manufacturing Poland. On the other side, the genuinely Polish corporates headquartered in [Warsaw](/en/ai-agents-warsaw/) and Krakow: PKO BP, Pekao, Santander Bank Polska, ING Bank Slaski, mBank, BNP Paribas Polska, PZU, Warta, Allegro, LPP, Dino Polska, Biedronka (Jeronimo Martins), CCC, Ciech, Grupa Azoty, JSW, KGHM, CD Projekt, Asseco, Comarch. This dual structure creates an AI market that simultaneously has to serve the corporate compliance of the parent countries and meet Poland's own regulation.

## The three regulatory hurdles for AI in the Polish market

First, KSeF and electronic invoicing: KSeF (Krajowy System e-Faktur) is being rolled out as mandatory for all companies in Poland. Hundreds of thousands of inbound and outbound invoices per day must be structured, validated and archived - every AI-supported extraction or classification has to be KSeF-conformant. Groups like Orlen, Allegro, LPP and PGE are currently rebuilding their document pipelines. Anyone working without traceable model foundations here risks tax audits with unclear evidence responsibility.

Second, UODO, RODO and the Polish Personal Data Protection Act: UODO (Urzad Ochrony Danych Osobowych) has become one of the more active EU data protection regulators in recent years. For automated profiling and decision-making in the sense of Article 22 GDPR, UODO expects documented legal bases, retrievable explanations and a complete Audit Trail. The Polish specificity: for HR-relevant decisions, the Rada Zakladowa has information and consultation rights that must be enforced through the architecture.

Third, KNF, NBP and the EU AI Act: the Komisja Nadzoru Finansowego, headquartered in Warsaw, supervises Poland's financial sector and expects a demonstrable human final decision in risk cases for AML, KYC, credit scoring and claims handling. The EU AI Act has applied to prohibited practices since February 2025; the Annex III high-risk obligations apply from 2 August 2026 under current law, but following the provisional Digital Omnibus agreement of 7 May 2026 they are set to be postponed to 2 December 2027 (formal adoption still pending, as of June 2026) - in Poland without a separate national implementing act, so directly applicable. Operating high-risk AI in HR, banking or insurance requires conformity assessments, risk management and post-market monitoring at a standard that withstands a KNF or UODO inspection.

## Typical deployment scenarios in Poland

PKO BP and mBank AML operations: Polish banks process millions of transactions per day. Document Agents extract identification markers, the Decision Layer routes suspicious cases along the KNF thresholds, with Human-in-the-Loop on every final escalation and a complete Audit Trail for supervision.

Allegro, LPP and Dino Polska KSeF pipeline: Poland's largest retailers and the e-commerce market leader sit under KSeF pressure. Document Agents extract structured invoice data, validate against the KSeF schema and route deviations to human reviewers in accounting.

JSW and KGHM operations: Poland's mining and heavy-metals groups generate enormous volumes of sensor data and safety notifications per day. Workflow Agents classify anomalies, escalate safety incidents to shift leads and log every decision for the Wojewodzki Inspektorat Ochrony Srodowiska and KNF-relevant analyses.

Comarch and Asseco software operations: the two Polish software groups develop banking and insurance software for all of Central Europe. [Document Agents](/en/services/ai-agents/) check release documentation against KNF, BaFin and FINMA requirements before a release ships.

## How Gosign serves all of Poland from Krakow

Gosign operates its own office in Krakow (gosign.pl) as the regional hub for the Polish market. The Polish team of project managers and engineers - Polish native speakers, fluent English - covers all four large tech clusters in the country: [Warsaw](/en/ai-agents-warsaw/) as the corporate and regulator capital, [Krakow](/en/ai-agents-krakow/) itself as the shared-service hub, [Wroclaw](/en/ai-agents-wroclaw/) as the industry-IT hybrid and [Gdansk](/en/ai-agents-gdansk/) as the port and tech location. On-site workshops, sprint reviews and steering run in Polish, without a language barrier and without cross-border travel overhead. Hamburg contributes architectural standards, DACH compliance expertise and the interface into German, Swiss and Dutch parent groups; delivery, day-to-day operations and the direct client contact sit with the Krakow team. This structure is decisive for Polish mid-market firms and corporate subsidiaries that want a DE-oriented quality standard without importing a language barrier.

## Why Poland is a strong starting point for Enterprise AI

For German, Swiss and Dutch groups, Poland is the closest AI stress test. Taking an AI agent productive in Poland that simultaneously meets KSeF, UODO, KNF and the EU AI Act produces an architecture that is only a configuration change away from any Western European market. Poland combines maximum talent availability (Krakow, Wroclaw, Warsaw, Gdansk) with maximum regulatory pressure (KNF, UODO, KSeF, EU AI Act, RODO). The cluster of Krakow Technology Park, Warsaw Spire Tech, Wroclaw Technology Park and Gdansk Science & Technology Park is the largest contiguous tech landscape in Central and Eastern Europe.

On top of that, Poland has a property that makes it unusually predictable for Enterprise AI deployments: operational proximity to Germany. Polish groups have worked with German parent companies for decades, Polish banks maintain correspondent relationships with Frankfurt and Munich, and Polish industrial sites are embedded in German supply chains. The compliance language is established, the expectations around Audit Trail, explainability and Governance by Design are not new. A successful deployment in Poland is therefore not only a market entry but also yields an architectural reference that is accepted directly inside the DACH region. Cert-Ready by Design is not a marketing phrase here but a precondition for day one of operations - and at the same time the quickest route to an Enterprise AI platform that later goes productive in fifteen more EU countries. More context on the [EU AI Act](/en/governance/eu-ai-act/) and the Polish application is in the Governance area.

--- AI Agents for Enterprises in Rio de Janeiro | Gosign ---
> Enterprise AI Agents for Rio de Janeiro. LGPD-compliant, CLT-compatible. Auditable AI for energy, mining, and public sector. Gosign.

## Rio de Janeiro is the compliance bottleneck of Brazil's energy and commodities sectors

The groups whose operational risks end up in the world's ESG reports every day are headquartered in Rio: Petrobras (head office on Avenida Republica do Chile), Vale (head office on Praia de Botafogo, operationally anchored in Minas Gerais), Eletrobras, Light SA, Americanas and Oi. Alongside them, the regulators: CVM (Comissao de Valores Mobiliarios, head office in downtown Rio), BNDES as the national development bank, ANP (Agencia Nacional do Petroleo) and ANEEL (Agencia Nacional de Energia Eletrica) with branches in the city centre. Running AI agents in productive compliance loops here means running them under the eyes of four supervisory authorities simultaneously - and at least one of them has been hypersensitive to every form of algorithmic decision-making since Brumadinho. Unlike Sao Paulo, where industrial concentration is horizontally distributed, in Rio it is vertically deep: an organisation targeting energy and commodities in Brazil gets the densest market access here.

## The three regulatory hurdles for AI in the Rio de Janeiro market

CVM supervision of capital-market groups is denser in Rio than anywhere else in Brazil. Petrobras, Vale, Eletrobras and Americanas are listed; every algorithmic component in investor relations, quarterly reporting or insider-trading prevention has to be explainable to a CVM auditor. The CVM head office downtown means short distances and intensive inspections.

ANP and ANEEL for regulated infrastructure: Petrobras facilities and Eletrobras networks are documented to ANP and ANEEL requirements. AI that suggests maintenance windows, builds production plans or prioritises network outages falls inside concrete sector regulation - not just LGPD. ANP requires traceability down to the wellbore, ANEEL down to the substation.

LGPD and post-Brumadinho transparency pressure: Vale has been under observation by the Federal Public Prosecutor (MPF) and the Justica Federal since 2019 (Brumadinho) and 2015 (Mariana). Every algorithmic decision in dam safety, risk scoring or tailings monitoring must be explainable in court. The Audit Trail is not a "nice to have" here but the difference between a criminal filing and a defensible position. The EU AI Act does not apply directly in Brazil; the local frame is LGPD today and PL 2338/2023 in preparation.

## Typical deployment scenarios in Rio de Janeiro

Petrobras asset documentation: Document Agents read maintenance logs, drilling reports and ANP filings from 30 years of asset history and consolidate them into auditable decision records. When an inspector asks for the history of a weld-seam crack, the answer is a query rather than a multi-week project, with a full [Audit Trail](/en/decision-layer/) back to the original file. For a group with 60,000 employees, offshore pre-salt drilling and a refinery network across Brazil, that is not a "nice to have" but an operational bottleneck.

Vale mining safety monitoring: Workflow Agents monitor sensor data, inspection reports and external weather data at tailings dam sites in Minas Gerais (operationally steered from Rio). The Decision Layer escalates critical risk patterns with Human-in-the-Loop to the geotechnical teams, with every decision logged for ANM, MPF and internal compliance.

BNDES loan approval: Document Agents review funding applications for completeness, plausibility and conflicts with ESG exclusion criteria. The Decision Layer flags critical applications for human decision and produces a full rationale file for every recommendation - including source citations and data provenance. At three-digit-million-reais funding, the depth of justification per decision is a prerequisite for every TCU inspection.

Globo content moderation and rights management: Document Agents process licence documents, exploitation rights and contract clauses for Latin America's largest media group. The Decision Layer escalates conflicts between broadcaster licences, streaming rights and international exploitation contracts with an Audit Trail back to the original file - critical in the streaming age in which Globoplay rights are renegotiated daily.

## How Gosign serves Rio from Sao Paulo

Our office in [Sao Paulo](/en/ai-agents-sao-paulo/) is one flight hour from Rio - closer to Petrobras HQ than most international AI vendors are to any client. Discovery workshops with Petrobras, Vale or BNDES happen on site in Rio, at the corporate headquarters in Botafogo or downtown. Compliance reviews with CVM, ANP or ANEEL exposure are run jointly with your legal team in Rio - proximity to the CVM head office means that regulatory clarifications happen in a meeting on the 25th floor of Avenida Rio Branco rather than as a six-week paper exchange. Technical build phases run distributed across our teams in Hamburg and Sao Paulo, with stand-ups in the SP morning and joint sprint reviews. On-site meetings in Rio are available within 24 hours, also at Petrobras facilities outside the city (Macae, the Campos Basin). After go-live, the Sao Paulo office is your operational contact with a Portuguese and English escalation hotline; for international clients, parallel communication with your European parent HQ stays available in German or English.

## Why Rio de Janeiro is a strong starting point for Enterprise AI

Rio is the only Brazilian city in which four regulators (CVM, ANP, ANEEL and the ANPD branch) and four of the ten largest Brazilian groups sit within a 15-kilometre radius. Building a productive agent here for CVM reporting, ANP compliance or tailings monitoring produces a blueprint for every Latin American energy and commodities market - from Buenos Aires through Lima to Bogota. The clusters - BNDES Inovacao, Rio+, the Porto Maravilha tech corridor - add the bridge into the academic world (PUC-Rio, UFRJ). What sets Rio apart beyond that: the concentration of listed groups with global ESG investors means that demands on algorithmic explainability are denser than anywhere else in Latin America, which sets the bar high but exactly for that reason turns every successful agent here into a Cert-Ready blueprint for global parent houses. Gosign's Governance by Design architecture is directly connectable to GDPR operations in Lisbon and EU audits - a model that holds in Rio holds in Frankfurt. See also [Sao Paulo](/en/ai-agents-sao-paulo/) and [Brazil as a whole](/en/ai-agents-brazil/).

--- AI Agents for Enterprises in Sao Paulo | Gosign ---
> Enterprise AI Agents in Sao Paulo. Local project management, LGPD-compliant, compatible with CLT and collective agreements. PoC to independent operation.

## Sao Paulo is the only LATAM metropolis where an international AI provider has to work with real local presence

Winning Itau Unibanco, Bradesco, Santander Brasil, Natura &Co or Ambev as clients cannot be done from Hamburg alone. Avenida Paulista, Faria Lima and Pinheiros are their own regulatory microcosms, with their own compliance processes, their own data protection cultures and their own expectations on vendor proximity. That applies equally to the banking clusters around Cubo Itau and to the consumer-goods worlds of JBS, BTG Pactual and XP Inc. Gosign therefore runs its own office in Sao Paulo - with local project managers sitting directly on site in discussions with compliance officers, Data Protection Officers (DPOs) and Sindicato representatives.

## The three regulatory hurdles for AI in the Sao Paulo market

LGPD (Lei Geral de Protecao de Dados) is Brazil's answer to European data protection - but it is not identical with GDPR. ANPD (Autoridade Nacional de Protecao de Dados, formally in Brasilia but operationally heavily SP-focused) requires a legal basis, purpose limitation and a DPO. Anyone working with personal data in Pinheiros must meet LGPD Articles 7 and 11 (sensitive data, health and financial data) - including an Audit Trail. The EU AI Act does not apply directly in Brazil; the local reference is LGPD today and PL 2338/2023 in preparation.

BACEN Resolucao 4893 defines the cyber resilience requirements for regulated financial institutions and is effectively the Brazilian counterpart to DORA. Itau, Bradesco, Banco do Brasil, Santander Brasil and the fintechs (Nubank, Stone, PagSeguro, XP Inc.) have to document every algorithmic intervention in credit decisioning, fraud scoring or anti-money-laundering - not only at audit time but productively and live.

PL 2338/2023 is the Brazilian AI bill, loosely modelled on the EU AI Act but not identical. It is not yet in force in 2026, but is expected within the next two years. Building today means architecting the system so that high-risk classification, human oversight and transparency duties can be activated later. Cert-Ready by Design rather than cert retrofit.

## Typical deployment scenarios in Sao Paulo

Banco KYC and AML screening at Itau, Bradesco and Santander Brasil: Document Agents read Cadastro de Pessoas Fisicas, Cadastro Nacional da Pessoa Juridica, proof-of-address and external sanctions lists. The [Decision Layer](/en/decision-layer/) marks high-risk hits (PEPs, sanctions matches) and routes them to compliance officers with rationale, confidence score and a complete Audit Trail. Banco Central and Coaf audits go from a multi-week project to a button press.

Supply chain compliance at Natura &Co and JBS: Workflow Agents monitor supplier certificates (FSC, Rainforest Alliance, GRSB for beef), reconcile them with IBAMA sanctions lists and raise alerts on anomalies. At JBS and Marfrig, the question "does this ranch supply from deforestation areas?" is now just as survival-critical as ESG reporting is for Natura.

Investment compliance at XP Inc. and BTG Pactual: Document Agents review investment contracts, risk profiles and CVM reporting duties. The Decision Layer automatically escalates suitability breaches to compliance, with Human-in-the-Loop on every regulatorily relevant step. At investment banks, per-trade audit depth is not a "nice to have" but a precondition for every CVM proceeding - Workflow Agents log suitability reviews, investor disclosure and the model versioning of the risk score in parallel.

Fraud detection at Nubank, Stone and PagSeguro: Brazil has the world's highest Pix adoption (over 90 per cent of the population), and with it its own fraud landscape. Workflow Agents monitor transaction patterns in real time, match them with behaviour profiles and escalate anomalies to anti-fraud teams with confidence scores and a rationale file. The Audit Trail satisfies Coaf reporting duties and BACEN security standards alike.

## How Gosign serves Brazil from Sao Paulo

We run an office in Sao Paulo with local project managers - this is not a "sales office" but real operational presence. Concretely: discovery workshops happen on site, not over video from Europe. Compliance reviews with your DPO and legal team happen in person in Faria Lima or Pinheiros. Sindicato consultations, when HR agents take work-relevant decisions, are run jointly with your labour-law firm. Technical implementation runs remote across our teams in Hamburg and Sao Paulo, a four-hour time offset, joint stand-ups in the SP morning. After go-live, the Sao Paulo office stays your operational contact - including a Portuguese-language escalation hotline and counterparts who know Brazilian labour law (CLT) and collective agreements (CCT/ACT) operationally, not only from a translated PDF.

The first question Brazilian compliance owners ask us is not "can you do this technically?" but "will you be there when the ANPD or the auditor calls?". The honest answer: yes, because our project managers live, work and reside in Sao Paulo. Discovery, build, go-live and aftercare are not four different teams in four different countries but one team with a hub in Sao Paulo and one in Hamburg, sharing common sprint cycles, common architecture boards and common escalation paths.

## Why Sao Paulo is a strong starting point for Enterprise AI

Sao Paulo is the only point in Latin America where banking compliance, consumer-goods supply chains, fintech innovation and industrial operations converge in a single city. Building a productive AI agent here for KYC, AML or ESG produces, inside 18 months, a blueprint for Mexico City, Bogota, Santiago or Buenos Aires. The clusters - Cubo Itau, ACE Startups, the Pinheiros-Vila Olimpia tech corridor - provide access to talent, investors and regulatory pilot programmes. Gosign's Governance by Design architecture combines this with European-depth audit discipline: a model that works in Sao Paulo under LGPD and BACEN connects directly into GDPR operations in Lisbon, Madrid or Hamburg. More in the [Brazil overview](/en/ai-agents-brazil/).

--- AI Agents for Enterprises in Spain | Gosign ---
> Enterprise AI Agents for Spain. AESIA-ready, GDPR compliant, EU AI Act compliant. Office in Barcelona, projects across Spain.

## Spain is the first EU country with a dedicated AI supervisor - and that changes the implementation plan

Spain is the only EU state with a fully operational national AI supervisor in AESIA (Agencia Espanola de Supervision de la Inteligencia Artificial). Headquartered in La Coruna, AESIA is Spain's answer to the EU AI Act and takes on a role that is still distributed or unfilled in most other EU countries. For groups like Santander, BBVA, CaixaBank, Sabadell, Telefonica, Iberdrola, Repsol, Inditex, Mercadona, Ferrovial, ACS, Mapfre, Amadeus IT Group, Grifols and Naturgy this means: regulatory clarity earlier than anywhere else. The metropolitan areas of Madrid, Barcelona, Valencia, Bilbao, Seville and Malaga form the country's main tech hubs - and all of them sit under the same unified AI supervisor. Building Enterprise AI in Spain means dealing with a regulator that knows what it expects and communicates it clearly.

## The three regulatory hurdles for AI in the Spanish market

First, AESIA and the EU AI Act: AESIA has been operational since 2024 and is actively developing guidance on high-risk AI systems in the sense of EU AI Act Annex III. For HR decisions, credit scoring, biometric identification and critical infrastructure, AESIA expects documented conformity assessments, risk management, post-market monitoring and a complete Audit Trail. The Spanish advantage over other EU countries: Spanish groups already know today what will be expected of them in 2026 and 2027, while groups in Germany or France still wait for national implementation legislation.

Second, AEPD and LOPDGDD: the Agencia Espanola de Proteccion de Datos supervises GDPR in Spain, complemented by the Spanish Ley Organica de Proteccion de Datos y Garantia de los Derechos Digitales (LOPDGDD) and the LGICTE on AI transparency in consumer contact. For Santander credit scoring, BBVA AML operations or Telefonica recommendation systems, the AEPD expects documented legal bases, retrievable explanations and a traceable human final decision. The Spanish specificity: for algorithmic decisions in consumer contact, the LGICTE explicitly requires a transparency duty that does not exist in this form in any other EU jurisdiction.

Third, CNMV, Banco de Espana and CNMC for sector-specific supervision: Santander, BBVA, CaixaBank and Sabadell sit under CNMV (securities regulator) and Banco de Espana (bank supervisor). For MiFID-relevant recommendations, AML screening and underwriting, both authorities expect the same explainability and audit standards as BaFin or the FCA. The CNMC additionally oversees competition-relevant algorithmic decisions - a dimension that is becoming increasingly visible at Mercadona, Inditex and across the Spanish e-commerce landscape. Spanish groups with LATAM operations must additionally consider LGPD in Brazil and Argentine Data Protection Law 25.326.

## Typical deployment scenarios in Spain

Santander and BBVA credit scoring: the large Spanish banks process millions of credit applications per year across Spain and LATAM. Document Agents extract structured data from application forms, the [Decision Layer](/en/decision-layer/) routes risk cases along the Banco de Espana thresholds, with Human-in-the-Loop on every final risk decision and an Audit Trail that holds up simultaneously for CNMV, AEPD and AESIA.

Telefonica consumer recommendation: Telefonica operates recommendation systems for tariffs, content and value-added services across several Spanish- and Portuguese-speaking markets. Decision Agents review every recommendation against LOPDGDD, LGICTE transparency requirements and LGPD rules in Brazil - every served decision backed by a traceable rationale.

Inditex and Mercadona supply chain operations: Spain's market leaders in fashion and food retail run highly complex supply chains. Workflow Agents classify orders, returns and supplier incidents, the Decision Layer routes escalations to human owners and logs every decision for internal audit and CNMC-relevant competition reviews.

Iberdrola and Naturgy grid operations: Spain's energy majors use AI for grid optimisation, predictive maintenance and consumption forecasts. Document Agents extract safety and maintenance notifications, Workflow Agents classify anomalies by severity, with an enforced human final decision on safety-relevant findings - a requirement that AESIA explicitly imposes for KRITIS-relevant AI.

## How Gosign serves all of Spain from Barcelona

Gosign operates its own office in Barcelona (gosign.es) as the regional hub for the Iberian Peninsula. The Spanish-Catalan team of project managers and engineers - native speakers, comfortable in every stakeholder language - covers all four main market regions in the country: [Madrid](/en/ai-agents-madrid/) as the corporate and regulator capital, [Barcelona](/en/ai-agents-barcelona/) itself as the tech hub, [Valencia](/en/ai-agents-valencia/) as the industrial and logistics centre, and [Bilbao](/en/ai-agents-bilbao/) as the Basque industrial heartland. On-site workshops, sprint reviews and steering run in Spanish, in Catalonia additionally in Catalan, in the Basque Country with Euskara-speaking stakeholders where helpful. Direct contacts with AESIA in La Coruna, AEPD and CNMV in Madrid run through the Barcelona team, and compliance documentation is delivered bilingually. Hamburg supplies technical architecture standards and the international coordination with German, Swiss and Dutch parent groups. For Spanish groups with LATAM operations - Santander, Telefonica, BBVA, Mapfre - the Barcelona team additionally couples with the Sao Paulo office (gosign.com.br), so that GDPR, LGPD and the Mexican LFPDPPP can all run on the same architecture.

## Why Spain is a strong starting point for Enterprise AI

Spain has a structural advantage no other large EU market currently offers: regulatory clarity from a single central source. An AI agent built for a Spanish enterprise that withstands AESIA expectations today rests on an architecture that is already EU AI Act conformant - before other EU countries even have their national supervisors operational. For German, Swiss and Nordic groups with Spanish or LATAM subsidiaries, Spain is therefore often the first productive AI market - and Spanish AESIA conformity becomes the blueprint for the subsequent rollout wave into other EU countries. Cert-Ready by Design here means: an architecture that already meets today what the rest of the EU will only make binding from 2027. Spain's pioneering role is not coincidental but deliberate - and a considerable location advantage for anyone starting now. More context on the [EU AI Act](/en/governance/eu-ai-act/) and the Spanish implementation is available in the Governance area.

--- AI Agents for Enterprises in Stockholm | Gosign ---
> Enterprise AI Agents for Stockholm. EU AI Act directly applicable, Swedish IMY oversight. Auditable AI for the Nordics tech hub.

## Stockholm is the tech capital of Scandinavia - with one of the most consistent data protection regulators in the EU in the background

Anyone building Enterprise AI in Stockholm is building for an unusual mix: industrial heavyweights such as Ericsson, ABB, Atlas Copco, Volvo Cars (operationally in Gothenburg, group functions in Stockholm) and Electrolux meet one of the densest unicorn concentrations in Europe - Spotify, Klarna, King Digital, iZettle, Truecaller, Northvolt. H&M and IKEA (via the Ikano group) form the retail core. The banking spine is Skandinaviska Enskilda Banken (SEB), Handelsbanken and Swedbank, the insurance landscape is dominated by Skandia and Folksam. The Kista Science City quarter hosts more than a thousand tech firms, and the Stockholm Unicorn Factory programme grows the next generation. What makes Stockholm distinctive: Swedish business culture combines Nordic efficiency with long-term engineering thinking - and accepts compliance investments that other markets would consider a brake.

## The three regulatory hurdles for AI in the Stockholm market

The first is the IMY (Integritetsskyddsmyndigheten), the Swedish Authority for Privacy Protection. The IMY is known across the EU for its consistent reading of GDPR and has issued several high-profile fines against tech firms, banks and public bodies in recent years - often on the basis of insufficient explainability of automated decisions. For AI systems that means: Article 22 GDPR is applied as strictly in Sweden as in the Netherlands or Spain. A Decision Layer with Human-in-the-Loop is not optional but a compliance prerequisite.

The second is the EU AI Act, which is directly applicable in Sweden. The Swedish government has announced its own market surveillance authority that coordinates with the IMY and Finansinspektionen. High-risk systems in banking, energy infrastructure and personnel administration will be systematically supervised from 2026 onwards. [EU AI Act compliance](/en/governance/eu-ai-act/) is here not abstract but operational.

The third is Finansinspektionen for the financial sector and PTS (Post- och telestyrelsen) for telecoms. Since 2023 Finansinspektionen has required documented AI model governance, explainability and continuous model monitoring from banks and payment service providers. Klarna, SEB and Handelsbanken are already running with frameworks of this kind. PTS supervises AI in telecoms networks and reviews Ericsson's network slicing models for bias and fairness.

## Typical deployment scenarios in Stockholm

Spotify develops recommendation algorithms that are live in more than 180 markets simultaneously and have to remain defensible under the EU AI Act, the IMY and several national supervisory regimes - every algorithmic push for an album has regulatory implications. Klarna uses AI for buy-now-pay-later risk models in 17+ markets - the models decide whether a consumer gets a micro-credit and have to be explainable to Finansinspektionen, BaFin, the FCA and several other supervisors at the same time. SEB runs transaction monitoring for AML detection with AI models that have to remain reproducible for Finansinspektionen - every single alert is subject to audit. Ericsson configures 5G networks for mobile operators worldwide with AI tools whose decisions have to be documentable for the relevant national telecoms supervisors.

In every scenario it is not the model alone that matters but the requirement that every decision remains traceable, can be routed through jurisdiction-specific rule sets and enforces Human-in-the-Loop on escalation paths. That is [Decision Layer](/en/decision-layer/) architecture in pure form.

A Swedish particularity is the handling of public authority data: the Swedish principle of public access to information (Offentlighetsprincipen) requires that authority documents are in principle public - which means for AI applications in the public sector and for contractors of the administration that even training data and model decisions may have to be disclosed. Anyone building AI in Stockholm for public sector clients has to design the architecture from day one to meet that transparency standard.

## How Gosign serves Stockholm from Hamburg

Hamburg-Stockholm is a direct flight of just under two hours, with daily connections via LH and SAS. We work remote-first with our Swedish clients, with on-site workshops in the first project months and quarterly visits in the operating phase. The working language is English, the steering rounds with our Hamburg architects run in German. The time zone is identical with Central Europe.

What makes the collaboration easier: Swedish business culture is consensus-oriented but technically highly competent - workshop participants are usually engineering leads or product owners who understand our architectural decisions directly. We know the Swedish co-determination logic (MBL, Medbestaemmande), which obliges employers to consult unions before introducing new systems, and design the Decision Layer accordingly so that co-determination duties are met architecturally - not as a retrofitted compliance layer but as integrated workflow.

## Why Stockholm is a strong starting point for Enterprise AI

Stockholm is the only market in Europe where you can test an AI architecture against IMY data protection, Finansinspektionen financial supervision and Nordic co-determination logic at the same time - and where stakeholders are willing to invest the time and engineering for it. Anyone who builds a Cert-Ready by Design pilot in Stockholm has a reference case that has passed under the strictest EU data protection conditions and is then defensible in Helsinki, Copenhagen, Oslo and the rest of Europe. The Kista Science City cluster, the Stockholm Unicorn Factory and the Stockholm School of Economics network supply talent, pilot partners and investor access.

We bring out of the Northern German engineering context a discipline that fits Swedish tech culture - Governance by Design, Audit Trail, and the ability to satisfy compliance demands from multiple jurisdictions over the same system. Stockholm is the right market to scale that discipline across the Nordics. And for German enterprises with Nordic subsidiaries, Stockholm is often the first market where a new AI architecture has to prove itself in production - before it is rolled out in Munich, Frankfurt or Hamburg.

--- AI Agents for Enterprises in Stuttgart | Gosign ---
> Enterprise AI Agents for Stuttgart and Baden-Wuerttemberg. Document Agents for invoices, Workflow Agents for procurement. Auditable, works council compatible.

## Stuttgart is the only European market where a corporate OEM and a Mittelstand hidden champion sit in the same supply chain under the same compliance obligations

In the corridor between Untertuerkheim, Zuffenhausen and Sindelfingen sit Mercedes-Benz and Porsche with their home plants. In Gerlingen sits Bosch as the largest automotive supplier in the world. Daimler Truck steers its global truck division from Leinfelden-Echterdingen. Add Duerr in Bietigheim, Trumpf in Ditzingen, Festo in Esslingen, Stihl in Waiblingen, Mahle and Kaercher - the list of hidden champions stretches well past the city limits. The location is not defined by the OEMs alone but by the chain of manufacturer, Tier-1 supplier and specialised mid-market firms. Anyone introducing an AI component here has to document it across multiple layers of an ASPICE and ISO 26262 supply chain at the same time - the Mercedes supplier standard forces every supplier into the same auditable model evidence. That interlock makes the Stuttgart market one of the toughest compliance environments in Europe: every supplier is automatically pulled into a strict model governance regime by the requirements of its OEM, whether it wants to be or not.

## The three regulatory hurdles that shape every AI initiative in the Stuttgart market

The first hurdle is automotive type approval. The KBA in Flensburg issues the approvals, but the technical standards are set by UNECE in Geneva - above all UN R155 on Cybersecurity Management and UN R156 on Software Updates. Anyone using an AI component in a vehicle, or in a production process that influences the software in the vehicle, needs an unbroken chain of evidence from model governance, training data provenance and reproducible builds. The second hurdle is the Cyber Resilience Act for the industrial equipment of the hidden champions - Trumpf, Duerr, Festo and Stihl ship machines with digital components into regulated markets and have to demonstrate vulnerability management and model updates. The third hurdle is the strong co-determination culture in the IG Metall-influenced plants: an AI application that touches personal data or performance measurement only passes the works councils at Mercedes, Bosch or Porsche when the [Decision Layer](/en/decision-layer/) architecturally enforces a human final decision. More on the regulatory frame under [Governance EU AI Act (UK: UK AI regulatory framework)](/en/governance/eu-ai-act/).

## Typical deployment scenarios in Stuttgart

At Bosch and comparable Tier-1 suppliers we see quality data agents that consolidate manufacturing and inspection data across multiple plants and escalate anomalies to a quality engineer - with a traceable assessment and references to the underlying measurement data. At Daimler Truck a compliance agent helps with fleet documentation, for example with the preparation of market approval files for different jurisdictions. In the Porsche Financial Services environment, agents support the preparation of credit decisions for leasing customers - the case officer decides, the agent enriches with documents, consumer credit history and plausibility checks. At Duerr, Festo and Trumpf we see service ticket agents that classify incoming customer tickets, enrich them with machine data and hand them with a proposal to a service technician. Mahle and Mahle Behr work on HR document agents for applicant pre-qualification - with a clear Audit Trail, because recruiting sits under the AGG (German anti-discrimination law) and falls into the EU AI Act high-risk classification. At Stihl and Kaercher as family-owned mid-market firms we see Document Agents in procurement and contract analysis, because the corporate audit teams in these houses expect a lean but unbroken audit logic. The Mercedes-Benz HQ in Untertuerkheim runs a strict ASPICE workflow day-to-day, in which AI components only enter productive chains when their model provenance and training data set are documented and versioned.

## How Gosign serves Stuttgart from Hamburg

Gosign has no Stuttgart location - the on-site work runs remote from Hamburg and Berlin. The advantage: we can be in Untertuerkheim by ICE in under six hours, a direct flight Hamburg-Stuttgart takes about one hour plus airport transfers. Concretely: discovery workshops with engineering, compliance and the works council we run as two- to three-day on-site blocks. The engineering phase is organised remote with two fixed weekly slots in the client calendar and defined on-site days for architecture reviews and critical stakeholder sessions. Model validation with internal audit, ASPICE audit preparation and co-determination negotiations always happen in person. The Swabian market accepts remote work pragmatically, as long as delivery is reliable, on-site presence is there at the right key moments and the model validation remains documented and reproducible. Clusters such as ARENA2036 (the future-mobility research campus on the Stuttgart university grounds) and Cyber Valley Tuebingen-Stuttgart (Europe's largest ML research centre) we use for technical discussion, auditor training and access to academic model validation experts.

## Why Stuttgart is a strong starting point for Enterprise AI

Anyone who puts an AI agent into production in a Stuttgart OEM or Tier-1 environment has defended it against ASPICE, ISO 26262, the Cyber Resilience Act, an IG Metall-experienced works council and internal audit at the same time. The same architecture then fits into any other production-driven sector in Europe, because the Stuttgart supply chain discipline defines the highest European standard for model provenance and Audit Trail. Add the ML and engineering talent pool around the University of Stuttgart with its strong mechanical engineering and computer science profile, KIT in Karlsruhe as Germany's largest technical university, the Esslingen University of Applied Sciences with its automotive specialisation, and the Tuebingen ML clusters with the Max Planck Institute for Intelligent Systems. The Mittelstand in Baden-Wuerttemberg is at the same time a market for scaled AI architecture - the roughly 1,500 hidden champions in the state show that it is not only DAX corporates that need AI as a production factor. Anyone who has a first agent in production at a Tier-1 supplier in 4-6 weeks has a reference set-up the market understands. More on the approach under [AI Agents Services](/en/services/ai-agents/).

--- AI Agents for Enterprises in the UK | Gosign ---
> Enterprise AI Agents for UK enterprises. UK GDPR compliant, EU AI Act ready for EU operations. Auditable AI that satisfies both UK and EU regulatory regimes.

## The United Kingdom is the only EU-adjacent market with mandatory dual regulation

The United Kingdom is the only major European economic area in which every medium-sized or large business with continental European operations has to make its AI systems auditable against two independent regulatory regimes at the same time. On the UK side, the stack includes UK GDPR, the ICO as data protection supervisor, FCA and PRA for financial services, Ofcom for telecoms and media, and the CMA for competition. On the EU side, GDPR and the EU AI Act continue to apply to any data touching EU customers, EU employees or EU subsidiaries. HSBC, Barclays, Lloyds and NatWest run group functions that serve both worlds in parallel. BP, Shell, AstraZeneca, GSK and Unilever process data daily that sometimes lands in UK jurisdiction and sometimes in EU jurisdiction. Tesco, Sainsbury's, BT, Vodafone, ITV and the BBC face the same reality at domestic scale. The physical footprint is distributed across London, Manchester, Edinburgh, Glasgow, Birmingham, Leeds and Bristol - but the regulatory problem is the same everywhere.

## The three regulatory hurdles for AI in the UK market

First, UK GDPR and ICO oversight: after Brexit, UK GDPR operates as the UK's domestic data protection law, supervised by the Information Commissioner's Office. For automated decision-making, the ICO expects documented model foundations, a responsive rights regime towards data subjects, and a complete Audit Trail. The planned Data Protection and Digital Information Bill will introduce some UK-specific relaxations without touching the core requirements. Moving data between the UK and the EU additionally requires a matching adequacy or SCC framework - a compliance layer no other European jurisdiction demands in this form.

Second, FCA, PRA and the Bank of England for financial services: HSBC, Barclays, Lloyds and NatWest all sit under direct FCA and PRA supervision. The FCA has made clear in multiple publications that it expects the same explainability and oversight standards for AI-supported decisions in lending, underwriting, AML and conduct risk as for human decisions. The UK-specific approach: instead of a single AI act like the EU's, the UK relies on sector-specific regulation - the FCA sets standards for finance, the ICO for data protection, Ofcom for communications. A UK group running AI across multiple sectors deals with different expectations per regulator.

Third, the EU AI Act for any UK enterprise with EU operations: the EU AI Act does not only apply to EU companies. Every UK enterprise that delivers AI outputs into the EU - whether through a German subsidiary, a Dutch branch or direct sales to EU customers - falls inside the extraterritorial scope of the Act. This means HSBC needs EU AI Act compliance for its German retail business. Unilever needs it for every consumer algorithm served into the EU. AstraZeneca needs it for clinical decision support in EU trial centres. A UK-only architecture is insufficient for any of these groups.

## Typical deployment scenarios in the UK

HSBC and Barclays conduct-risk monitoring: the UK's large banks sit under dual FCA and ESMA oversight. Document Agents extract compliance-relevant statements from customer interactions, the [Decision Layer](/en/decision-layer/) routes suspicious cases along the respective jurisdiction-specific thresholds, with Human-in-the-Loop on every escalation and an Audit Trail that can be presented to both the FCA and ESMA.

BP and Shell HSE operations: the global energy majors produce thousands of safety and environmental reports per day. Workflow Agents classify incidents by severity, region and reportable characteristics - with different escalation paths depending on location (UK HSE, US EPA, German BNetzA, Polish OUG).

AstraZeneca and GSK pharmacovigilance: the UK pharma groups run EU-wide clinical trials. Document Agents review adverse-event reports, classify them against MHRA and EMA requirements and route critical findings to human pharmacovigilance owners - every decision auditable against the regulatory standard applicable at the origin.

Unilever and Tesco consumer algorithms: the global consumer goods and retail groups use AI in recommendation, pricing and promotion. Decision Agents review every served decision against UK consumer protection standards and the EU AI Act simultaneously, with traceable reasoning available to the ICO and consumer regulators.

## How Gosign serves the UK from Hamburg

Gosign handles UK projects from the Hamburg headquarters. The combination of EU regulatory expertise and a Hamburg base is not a disadvantage for UK groups with EU operations but a precondition - precisely the dual regulation can only be built cleanly when both worlds are understood by the same team at the same time. Discovery takes place on site in London, Manchester or Edinburgh depending on the group's location. The build then runs remote with English-language documentation, weekly sprint reviews over video and a dedicated contact in Hamburg. On-site meetings happen every four to six weeks, with the direct Hamburg-London flight taking just over an hour and a quarter. On-site meetings with the FCA, PRA or ICO are supported on request jointly with the client's internal legal team.

## Why the UK is a strong starting point for Enterprise AI

No other country in Europe forces groups with the same consistency into a jurisdiction-specific rule architecture. An AI agent that satisfies UK GDPR, FCA standards and the EU AI Act at the same time has been built on an architecture that in practice is only a configuration change away from any Western market. This is exactly where Gosign's Decision Layer with jurisdiction-specific rule sets comes in: instead of running two parallel systems, one platform carries two rulebooks - UK for domestic routing, EU for EU routing - and a single Audit Trail that documents the relevant ruleset depending on the recipient. For UK groups with EU operations this is the only architecture that does not turn into a dead end at the first ICO or ESMA audit. Cert-Ready by Design here means literally: ready for two certifications on a single codebase. More context on the [EU AI Act](/en/governance/eu-ai-act/) and its extraterritorial reach is in the Governance area.

--- AI Agents for Enterprises in Valencia | Gosign ---
> Enterprise AI Agents for Valencia. Mediterranean tech hub. EU AI Act compliant, GDPR compliant. Project management from Barcelona.

## Valencia is Spain's third economic zone - shaped by food logistics, automotive and Mediterranean trade

Building Enterprise AI in Valencia means building for a city in which the tone is set not by banks or tech groups but by supply chains, production planning and logistics. Mercadona, with more than 1,700 stores, is Spain's largest supermarket chain and runs one of the densest private-label supply chains in Europe from its head office in Tavernes Blanques. Ford Valencia has been producing in Almussafes since the 1970s - the plant is one of the largest Ford sites in Europe. Porcelanosa (ceramics), Lladro (porcelain manufactory) and Consum (cooperative supermarket chain) are further industrial heavyweights. Air Nostrum runs Iberian regional air traffic from Valencia, BP operates one of Spain's largest refineries in Castellon, and Iberdrola Energia coordinates a substantial share of Spanish solar generation from the greater Valencia area. In recent years the city has additionally grown as a tech location through Marina Valencia and the Lanzadera programme, financed by Mercadona founder Juan Roig.

## The three regulatory hurdles for AI in the Valencian market

First, the AEPD and the LOPDGDD (Ley Organica 3/2018) for any processing with personal data. The AEPD enforces particularly strictly at logistics and retail companies, because the volume of customer and employee data is enormous. Mercadona alone moves data from millions of customers and more than 100,000 employees every day - any AI-supported workforce planning must be justifiable under Article 22 GDPR.

Second, AESIA (Agencia Espanola de Supervision de la Inteligencia Artificial) and the EU AI Act, which is directly applicable in Spain. High-risk systems - especially in workforce management, supply chain optimisation and energy generation - will be systematically reviewed from 2026. Building an AI pipeline for workforce management in Valencia means building for a high-risk category and documenting for an AESIA audit from day one.

Third, the CNMV and Banco de Espana for the financing chains between industry and banks. Valencia is not Spain's banking centre, but the large industrial players sit inside complex working-capital structures. AI-driven cashflow forecasting, credit-risk models and hedging strategies fall under both supervisors. [EU AI Act compliance](/en/governance/eu-ai-act/) meets financial supervision here.

## Typical deployment scenarios in Valencia

Mercadona optimises supply chains between hundreds of suppliers, multiple logistics centres and more than 1,700 stores - every AI-supported ordering recommendation directly affects food waste, freshness and margin. The models must remain traceable because supplier and employee compensation depends on them. Ford Valencia plans production of several model ranges in Almussafes with complex supply chains across the Iberian Peninsula - AI models for capacity planning must withstand group audits. Porcelanosa uses computer vision for ceramic quality assurance - every automated rejection decision must be defensible before major customers and suppliers. Iberdrola Energia monitors large-scale solar PV installations across the Valencia and Castilla-La Mancha regions - AI anomaly detection in module performance must be logged in an Audit Trail that stays reviewable for owners and insurers.

Every scenario concerns industrial AI with physical consequences. The [Decision Layer](/en/decision-layer/) provides the architecture that bundles Audit Trail, escalation and Cert-Ready by Design - exactly what the Spanish supervisors want to see at the same time. A Valencian specificity is the Port of Valencia - the largest container port on the Mediterranean and a strategic node for European-Asian trade. Building AI here for freight documentation, customs processing and logistics optimisation means operating under the additional supervisory regime of the Agencia Tributaria and the Aduanas authority. The Audit Trail must be not only GDPR-compliant but also customs-traceable, often across several languages and jurisdictions.

## How Gosign serves Valencia from Barcelona

Gosign handles Valencian projects out of the Barcelona office (gosign.es) with Spanish-speaking project managers and engineers. The AVE Barcelona-Valencia connection runs in roughly three and a half hours, similar by car depending on traffic - monthly on-site meetings at Mercadona in Tavernes Blanques, at Ford Valencia in Almussafes, at Porcelanosa and inside Marina Valencia are a standard part of every project. Discovery takes place on site with Spanish-speaking domain owners, the compliance function and the Comite de Empresa at the same table. Where needed we bring in Valencian-speaking stakeholders. The local industrial clusters - Agri-Food around Mercadona and Consum, automotive around Ford and its suppliers, ceramics in Castellon - require sector understanding that the Spanish team brings from years of mid-market work on the Iberian Peninsula. Hamburg supplies architectural reviews and the interface into German industrial compliance standards; delivery, direct client contact and the family-business negotiation culture of Valencia sit with the Barcelona team.

## Why Valencia is a strong starting point for Enterprise AI

Valencia is the ideal market in which to validate industrial AI at full compliance depth without carrying the regulatory friction and cost structure of Madrid. A Cert-Ready by Design pilot built in Valencia produces a reference case that has passed under AEPD, AESIA and EU AI Act standards, and that is then defensible in Madrid, Barcelona and beyond the Pyrenees. Marina Valencia, the Lanzadera programme and the Universitat Politecnica de Valencia supply talent, pilot partners and research linkage.

We bring from the German industrial belt the experience of operating AI in complex supply chains and production systems - with Governance by Design, an Audit Trail and Human-in-the-Loop. Valencia is the right market in which to scale that discipline productively on the Iberian Peninsula. An organisation starting here has a blueprint for any European industrial region with a similar profile - from the Ruhr valley and Lombardy to the Basque Country.

--- AI Agents for Enterprises in Warsaw | Gosign ---
> Enterprise AI Agents for Warsaw. EU AI Act compliant, GDPR-compliant, auditable. AI governance for Poland's corporate headquarters.

## Warsaw is Poland's corporate capital with the densest regulator concentration in Central and Eastern Europe

Warsaw is home to the headquarters of PKO BP, PZU, Orlen, PGE, Santander Bank Polska, mBank, Allegro, CD Projekt RED and LPP - Polish sector leaders with hundreds of thousands of customers, employees and business events per day. Warsaw also hosts the most important supervisory authorities in the country: UODO, KNF, NBP and ZUS all operate within a few kilometres of one another. That proximity between corporates and regulators produces a supervisory density that does not exist in any other Polish city. AI systems that go productive in Warsaw corporate headquarters do not only have to work - they have to withstand a supervisor that sits, geographically, one metro stop away.

## The three regulatory hurdles for AI in the Warsaw market

First, KNF supervision of the Polish financial sector: PKO BP, mBank, Pekao, Santander Bank Polska and PZU all sit under direct KNF oversight. For AML and KYC processes, credit scoring and claims handling, the Komisja Nadzoru Finansowego expects documented model foundations, a complete Audit Trail and a demonstrable human final decision on risk cases. KNF has sharpened its expectations on automated decision-making in recent years - a Warsaw bank deploying AI without solid conformity documentation risks not only complaints but intervention into live operations.

Second, KSeF, the Polish system for electronic invoicing: KSeF is being rolled out as mandatory for every company in Poland. Groups like Orlen, Allegro, LPP and PGE have to extract, validate and archive hundreds of thousands of inbound and outbound invoices per day in KSeF-conformant form. AI that processes invoice data must match the KSeF structural requirements and make clear, in the case of a conflict, why a booking was executed as it was - a classic use case for Document Agents with enforced Human-in-the-Loop on deviations.

Third, UODO and the specifics of the Polish Personal Data Protection Act: UODO sits in Warsaw and reviews Polish corporates with particular attention to automated profiling under Article 22 GDPR. For Allegro recommendation systems, PZU claims classification or PKO BP credit scoring, UODO expects clear transparency and traceable rationales - every affected individual must be able to understand why a decision was made, and KNF and UODO must be able to inspect it.

## Typical deployment scenarios in Warsaw

PKO BP AML and KYC operations: Poland's largest bank processes millions of transactions daily. Document Agents extract identification markers, Workflow Agents route suspicious cases along KNF thresholds, and the [Decision Layer](/en/decision-layer/) logs every escalation for the internal AML committee and external auditors.

Allegro fraud detection: Poland's largest e-commerce marketplace competes with Amazon. Across millions of orders per day, Decision Agents check risk patterns in real time - always with the possibility of tracing individual decisions back for UODO audits.

PZU claims settlement: Poland's insurance leader processes thousands of claims per day. Workflow Agents classify incoming notifications by tariff, region and complexity, with enforced human review at threshold breaches - an explicit KNF expectation.

KSeF invoice extraction for Orlen and PGE: both groups sit under KSeF pressure. Document Agents extract structured invoice data, validate it against the KSeF schema and route deviations to human reviewers in accounting.

## How Gosign serves Warsaw from Krakow

Gosign handles Warsaw projects from the Krakow office (gosign.pl) with Polish-speaking project managers and engineers. The Krakow-Warsaw distance is bridged by the Express Intercity Premium in just under three hours, similar by car depending on traffic - regular on-site presence in Warsaw Spire Tech, at Rondo Daszynskiego or directly inside the corporate headquarters of PKO BP, Allegro, Orlen, PZU and mBank is the norm rather than the exception. Discovery workshops happen on site with Polish-speaking domain owners, the compliance function and a Rada Zakladowa representative at the same table. Build and sprint reviews then run weekly in Polish or English, with monthly on-site steering in Warsaw and short-notice travel for UODO or KNF escalations. Hamburg contributes architectural principle reviews and the interface into German or Swiss parent groups - delivery, day-to-day operations and client contact sit with the Krakow team at eye level with Warsaw stakeholders.

## Why Warsaw is a strong starting point for Enterprise AI

Warsaw is the only market in Central and Eastern Europe in which all three conditions for a successful Enterprise AI implementation coincide: maximum corporate density, maximum regulator density and a tech ecosystem with Google for Startups Warsaw, Campus Warsaw and the Warsaw Spire Tech Cluster. An AI agent that goes productive for a Warsaw bank, a Warsaw insurer or a Warsaw e-commerce group has passed the hardest regulatory stress test in Central and Eastern Europe. Scaling into other Polish locations - [Krakow](/en/ai-agents-krakow/), [Wroclaw](/en/ai-agents-wroclaw/), [Gdansk](/en/ai-agents-gdansk/) - is then a configuration change rather than a second build.

Alongside that, there is a property that makes Warsaw unusually attractive for German, Swiss and Dutch parent groups: Warsaw corporates have been used to Western European compliance standards for years. PKO BP works with German correspondent banks, mBank has been part of the Commerzbank group for decades, Santander Bank Polska sits inside the Spanish Santander structure. These groups know what BaFin, FINMA or DNB expectations on AI look like, and their internal compliance functions are designed for it. A Decision Layer implementation in Warsaw rarely meets resistance to the requirement to make every decision auditable - that has been operational reality for years. Governance by Design is not a sales line in Warsaw but a condition of entry. Passing Warsaw means passing the rest of Poland and most EU markets along with it. More context on the [EU AI Act](/en/governance/eu-ai-act/) and the Polish implementation is in the Governance area.

--- AI Agents for Enterprises in Wroclaw | Gosign ---
> Enterprise AI Agents for Wroclaw. Poland's second IT hub. EU AI Act compliant, GDPR-compliant. Project management from Krakow.

## Wroclaw is Poland's industrial-IT hybrid - where automotive suppliers meet banking operations

Bosch Wroclaw, LG Electronics, 3M, Volvo Wroclaw, Whirlpool and Toyota Motor Manufacturing Poland all run production and engineering sites in Wroclaw with thousands of employees each. Sitting alongside them are UBS Wroclaw (created out of the former Credit Suisse centre), HP, Nokia Wroclaw and multiple banking shared services. The mix is unique in Poland: the same hour of work in this city can go into engineering documentation for a car plant and into research reports for a Swiss investment bank. The Wroclaw Technology Park and Capital Park form the physical cluster, and the Politechnika Wroclawska feeds engineers into both worlds. Building Enterprise AI in Wroclaw means serving two industrial logics at the same time.

## The three regulatory hurdles for AI in the Wroclaw market

First, UODO and RODO in a multi-entity context: Wroclaw sites frequently process data from their Western European parent groups. A UBS operation in Wroclaw is simultaneously subject to FINMA, ESMA and UODO requirements. A Bosch engineering function in Wroclaw produces product documentation that lands in Stuttgart, Shanghai and Detroit. The Polish Data Protection Act requires automated profiling and decision-making to remain traceable - even when the models are trained at the German or Swiss parent headquarters. AI architectures without a gapless Audit Trail are not implementable here.

Second, KNF supervision for the growing banking-outsourcing function: UBS, several mid-market investment operations and credit-servicing providers work in Wroclaw under the regulatory roof of the Komisja Nadzoru Finansowego as well as their respective home supervisors. For research tools, automatic document classification and compliance screening, KNF expects every model decision to be traceable back to a human final responsible party - including the underlying data version at the time of the decision.

Third, the EU AI Act (UK: UK AI regulatory framework) with a focus on high-risk applications in HR and industry: Wroclaw production sites increasingly use AI for quality inspection, predictive maintenance and shift planning. Shift-planning algorithms fall under Annex III of the EU AI Act (HR-relevant high-risk systems); quality inspection via vision models touches product liability and CE conformity. NBP and UODO expect full conformity documentation in both cases. Cert-Ready by Design is not a sales pitch at Wroclaw production plants but a precondition for parent-group and certifier audits.

## Typical deployment scenarios in Wroclaw

LG Electronics quality inspection: LG's Wroclaw plant produces display components at high volume. Vision-based Decision Agents check surface defects in real time, with enforced human escalation on borderline cases. Every decision is logged in the Audit Trail with model version, training dataset reference and reviewer ID.

UBS Wroclaw research operations: the former Credit Suisse operation, now part of UBS, runs one of the largest research functions outside Zurich. Document Agents extract core data from annual reports, classify earnings calls and route compliance-relevant statements to human analysts - every step logged for FINMA and KNF audits.

HP service-desk routing: HP's Wroclaw service centre serves customers in multiple languages and time zones. Workflow Agents classify inbound tickets by language, tenant and escalation level. The [Decision Layer](/en/decision-layer/) routes automatically, with Human-in-the-Loop on VIP customers and tickets that would breach SLAs.

Bosch production documentation: Bosch's Wroclaw site generates thousands of technical documents per day. Document Agents extract regulatorily relevant specifications, reconcile them against country-specific norms and route conflicts automatically to engineering leadership in Stuttgart or Wroclaw.

## How Gosign serves Wroclaw from Krakow

Gosign handles Wroclaw projects from the Krakow office (gosign.pl) with Polish-speaking engineers and project managers. Krakow-Wroclaw is bridged by car or train in about three hours - regular on-site meetings in the Wroclaw Technology Park, Capital Park or directly inside the engineering rooms of Bosch, LG Electronics, UBS Wroclaw and HP are a standing part of every project phase rather than an exception. Discovery runs as a two-day on-site session, with Polish-speaking domain owners, a compliance function and a Rada Zakladowa representative at the same table. Build and sprint reviews then run with the Krakow team in Polish and English, with monthly on-site steering in Wroclaw. Polish engineers understand the Wroclaw dual world - traditional industry and banking outsourcing - from their own working lives and adapt documentation, workshop language and escalation paths without cultural translation. Hamburg contributes architecture reviews and the interface into German and Swiss parent groups in Stuttgart, Munich or Zurich.

## Why Wroclaw is a strong starting point for Enterprise AI

Wroclaw is the most unusual Enterprise AI market in Poland because two worlds collide here: traditional industry and banking outsourcing. Building an AI agent that works at the same time inside a Bosch plant and a UBS operation produces an architecture that is only a configuration change away from any other Polish location. The Politechnika Wroclawska supplies engineers who understand this dual world, and after [Krakow](/en/ai-agents-krakow/), Wroclaw's tech ecosystem is the second-largest in the country.

For German mid-market firms with Polish subsidiaries, Wroclaw is often the first foreign location where productive AI is actually needed - and a successful Wroclaw implementation therefore becomes the blueprint for the subsequent scale-up. On top of that, the proximity to the German border: the train from Berlin to Wroclaw takes just under four hours, an on-site meeting fits inside a single working day. The combination of Western European reachability, Central European talent costs and strict EU regulation makes Wroclaw a location that should not be missing from any German group portfolio. Governance by Design is not a marketing phrase here but a precondition for parent-group acceptance - and exactly the precondition that a successfully implemented Decision Layer meets from day one. More on our approach in Poland is in the [Poland overview](/en/ai-agents-poland/).

--- AI Agents for Enterprises in Zurich | Gosign ---
> Enterprise AI Agents for Zurich. Swiss FADP compliant, EU AI Act ready for EU operations. Auditable AI for Switzerland's financial centre.

## Zurich is the only European financial centre where AI architecture has to be planned without the EU AI Act - and that is exactly the strategic advantage

Switzerland is not in the EU. Anyone who wants to understand Zurich as a market starts with that fact: the EU AI Act does not apply directly here, EU GDPR is not the governing data protection law, and BaFin has no jurisdiction. Instead the revised Swiss Federal Act on Data Protection (FADP, in force since September 2023) and FINMA, the Swiss Financial Market Supervisory Authority, set the rules. Around Paradeplatz sit UBS - now by far the largest Swiss bank after the 2023 Credit Suisse takeover - alongside Zurich Insurance Group and Swiss Re as two of the world's largest reinsurers. ABB has its corporate headquarters in Oerlikon, Sika in Baar, Holcim in Jona. Google operates one of its largest engineering centres outside the US in Zurich. That mix produces an AI market with high technical maturity inside a regulatory frame that is more pragmatic and more sector-specific than EU regulation.

## The three regulatory hurdles that shape every AI initiative in the Zurich market

The first hurdle is FINMA as the financial supervisor. In 2024 it set out its expectations on AI model governance in banks and insurers in a dedicated supervisory paper - with clear obligations on model risk, explainability and auditability. UBS, Zurich Insurance, Swiss Re and the private banks based here have to validate every AI component in risk management, underwriting or wealth management against these FINMA expectations. The second hurdle is the FDPIC (Federal Data Protection and Information Commissioner) and the revised FADP - the new Swiss data protection law in force since 2023. It is broadly compatible with EU GDPR but has its own obligations on privacy by design, profiling and automated decision-making that have to be evidenced separately. The third hurdle is the Swiss AI regulatory discourse itself: the Federal Council decided in 2024 that Switzerland will not create a comprehensive AI Act of its own but will regulate sector by sector - which means FINMA, Swissmedic and OFCOM each formulate their own AI obligations in their domains. Anyone planning in Zurich has to know the relevant sector regulator in detail. More background under [Governance EU AI Act](/en/governance/eu-ai-act/) - the EU logic remains a second compliance vector for Swiss enterprises with EU operations.

## Typical deployment scenarios in Zurich

At UBS and across the wider Swiss banking environment we see wealth management reporting agents that prepare structured client communication and performance reports - the relationship manager decides, the agent structures. At Zurich Insurance, agents support claims handling in property and life lines, with structured enrichment of the claim notification by policy data, expert reports and plausibility checks - the final call sits with a case officer with insurance background. At Swiss Re the work is around reinsurance modelling and catastrophe modelling, where underwriters receive the results as a proposal and own the final acceptance. ABB works on industrial control system use cases where industrial operators make the final call. Google Zurich uses its own engineering tooling and is less relevant as a market for external agent architecture - but the technical talent environment in Zurich is shaped by it. At Sika and Holcim we see Document Agents for contract analysis and safety data sheets in the construction chemistry environment. In every case the [Decision Layer](/en/decision-layer/) holds the chain of reasoning as an Audit Trail - in a form that satisfies both FINMA expectations and FADP obligations simultaneously.

## How Gosign serves Zurich from Hamburg

Gosign has no Swiss subsidiary. The Swiss market accepts German service providers without a local entity, as long as data residency, engineering and contractual structure are clearly arranged. Concretely: we work as a German GmbH headquartered in Hamburg, the contract structure follows Swiss law or a dual model, data residency runs either on Swiss cloud infrastructure (Swisscom, Exoscale) or on an EU set-up operated to FADP standards with the corresponding safeguards. Discovery workshops we run on site in Zurich - the direct flight Hamburg-Zurich takes one hour of flight time, the ICE via Basel is a sensible alternative. In the engineering phase we work remote with bi-weekly on-site days and a focus on the FINMA-relevant validation sessions. The crucial point is the explicit separation between rule sets for Swiss data and rule sets for EU data - the Decision Layer carries both logics in parallel, because many Swiss corporates have EU operations and have to satisfy both regimes at once. Clusters such as the ETH AI Center, Impact Hub Zurich and the Zurich Insurance Innovation hub we use for technical exchange.

## Why Zurich is a strong starting point for Enterprise AI

Switzerland has a structural advantage that EU markets do not share: regulation is sector-specific, pragmatic and as a rule less formalistic than the EU AI Act. Anyone who puts a first AI agent into production in a regulated Zurich environment has defended it against FINMA expectations, against the revised FADP and against the Swiss demand for technical cleanliness. That architecture is then prepared for scaling into the EU, because the underlying model governance already meets the highest standard. Add the technical environment: ETH Zurich is one of the world's leading ML research institutions, the ETH AI Center brings together around 100 research groups, and Google Zurich, IBM Research Zurich and the CERN environment in western Switzerland make the market one of the most technically mature locations in Europe. Anyone who has a first AI agent in production at a Swiss corporate inside 4-6 weeks is building on a market that rewards pragmatic architecture and avoids unnecessary bureaucracy. More on the approach under [AI Agents Services](/en/services/ai-agents/).

--- Contact ---
> Talk to us about a specific process. Contact form and appointment booking.

<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">

<div id="hq" class="scroll-mt-24">
<h2 class="text-h2 font-bold text-gosign-dark">Headquarters & Governance</h2>
<p class="text-body-lg text-gosign-text-light mt-2">Executive leadership, governance architecture, DACH client projects.</p>
<div class="mt-6 grid grid-cols-1 sm:grid-cols-2 gap-6">
<div>
<h3 class="text-body font-bold text-gosign-dark">Hamburg</h3>
<div class="text-body text-gosign-text-light mt-1 space-y-0.5">
<p>Gosign GmbH</p>
<p>Hallerstraße 8</p>
<p>20146 Hamburg, Germany</p>
</div>
</div>
<div>
<h3 class="text-body font-bold text-gosign-dark">Training Centre Hamburg</h3>
<div class="text-body text-gosign-text-light mt-1 space-y-0.5">
<p>Grindelberg 77</p>
<p>20144 Hamburg</p>
</div>
</div>
</div>
</div>

<div id="market" class="mt-12 pt-8 border-t border-gosign-border scroll-mt-24">
<h2 class="text-h2 font-bold text-gosign-dark">Project Management & Market Presence</h2>
<p class="text-body-lg text-gosign-text-light mt-2">Local project managers work with you directly - from discovery through to independent operation.</p>
<div class="mt-6 grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-3 gap-6">
<div>
<h3 class="text-body font-bold text-gosign-dark">Berlin</h3>
<div class="text-body text-gosign-text-light mt-1 space-y-0.5">
<p>Gosign GmbH - Berlin Office</p>
<p>Nogatstraße 46</p>
<p>12051 Berlin, Germany</p>
</div>
</div>
<div>
<h3 class="text-body font-bold text-gosign-dark">Kraków</h3>
<div class="text-body text-gosign-text-light mt-1 space-y-0.5">
<p>Gosign - Kraków Office</p>
<p><a href="https://www.gosign.pl" target="_blank" rel="noopener noreferrer" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">gosign.pl</a></p>
</div>
</div>
<div>
<h3 class="text-body font-bold text-gosign-dark">Barcelona</h3>
<div class="text-body text-gosign-text-light mt-1 space-y-0.5">
<p>Gosign - Barcelona Office</p>
<p><a href="https://www.gosign.es" target="_blank" rel="noopener noreferrer" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">gosign.es</a></p>
</div>
</div>
<div>
<h3 class="text-body font-bold text-gosign-dark">Lisbon</h3>
<div class="text-body text-gosign-text-light mt-1 space-y-0.5">
<p>Gosign - Lisbon Office</p>
<p><a href="https://www.gosign.pt" target="_blank" rel="noopener noreferrer" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">gosign.pt</a></p>
</div>
</div>
<div>
<h3 class="text-body font-bold text-gosign-dark">São Paulo <span class="text-gosign-text-light font-normal">(LATAM Office)</span></h3>
<div class="text-body text-gosign-text-light mt-1 space-y-0.5">
<p>Gosign - São Paulo Office</p>
<p><a href="https://www.gosign.pt" target="_blank" rel="noopener noreferrer" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">gosign.pt</a></p>
</div>
</div>
</div>
</div>

<div id="engineering" class="mt-12 pt-8 border-t border-gosign-border scroll-mt-24">
<h2 class="text-h2 font-bold text-gosign-dark">Engineering & Research</h2>
<p class="text-body-lg text-gosign-text-light mt-2">60+ engineers. University partnerships for research and talent development.</p>
<div class="mt-6">
<h3 class="text-body font-bold text-gosign-dark">Lahore · Islamabad, Pakistan</h3>
<div class="text-body text-gosign-text-light mt-1 space-y-0.5">
<p>Development centres with university partnerships:</p>
<p><a href="https://pu.edu.pk/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-text-light transition-colors underline decoration-dotted">University of the Punjab</a> · <a href="https://www.comsats.edu.pk/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-text-light transition-colors underline decoration-dotted">COMSATS University</a></p>
<p><a href="https://www.gosign.pk" target="_blank" rel="noopener noreferrer" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">gosign.pk</a></p>
</div>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark">What We Cover in the First Conversation</h2>
<ul class="mt-4 space-y-2 text-body-lg text-gosign-text-light list-disc list-inside">
<li>Which process should be automated?</li>
<li>Which systems are involved (SAP, DATEV, Workday, etc.)?</li>
<li>Which governance requirements apply (employee oversight, audit, compliance)?</li>
<li>Cloud, self-hosted, or hybrid?</li>
<li>Timeline and next steps</li>
</ul>
</div>
</section>

--- Decision Layer - Traceable AI Decisions for HR and Finance ---
> The Decision Layer makes every AI decision auditable and traceable. For HR, Finance, and document-driven processes.

<!-- Why AI projects fail -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Why AI Projects in HR Fail</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
HR processes depend on the knowledge of individual employees. Who knows which special leave policy applies at which location? Who remembers the difference between the company agreement from 2019 and the updated version from 2024? Who checks whether sick leave was correctly validated against the collective agreement?
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
This knowledge lives in people's heads, in email threads, in folders nobody can find. When someone leaves the team, the knowledge leaves too.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
AI can help - but only when it's clear which rules apply. And who is ultimately responsible.
</p>
</div>
</section>

<!-- LLM Definition Block -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">What Is the Decision Layer?</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
The Decision Layer decomposes every business process into individual decision steps and defines upfront for each: Does a human decide, does a rule set apply, or does the AI decide autonomously?
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong class="text-gosign-dark">HUMAN:</strong> The architecture enforces human review. For discretionary decisions, discrimination risk, employee representation matters, and value thresholds above defined limits. The agent provides full context and a recommendation - but a human decides. This escalation is technically enforced, not organisationally agreed.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong class="text-gosign-dark">RULE SET:</strong> The decision is deterministic - there is no room for interpretation. The collective agreement states X, so X applies. A deadline expires on date Y, so rule Z triggers. Rule sets are versioned: every change creates a new version, previous versions remain traceable. Here, the agent is an executor - not because it cannot do more, but because there is nothing to interpret.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong class="text-gosign-dark">AI AUTONOMOUS:</strong> The agent makes independent decisions - because it is confident enough, has permission, and demonstrably performs the task better than manual processing. It interprets documents, classifies situations, evaluates context, and recognises patterns. This is not if-then-else - this is judgment within defined guardrails. Confidence Routing controls: high confidence and low risk leads to autonomous decision. Low confidence or high risk leads to escalation to a human. This Confidence Routing is precisely what distinguishes the Decision Layer from RPA.
</p>
<p class="text-body text-gosign-text-light mt-4 italic">
(US: In the US, where works councils do not exist, the human review tier maps to internal compliance review, EEOC-aligned anti-discrimination checks, and management approval workflows. The architecture is jurisdiction-agnostic - the governance rules adapt to your regulatory environment.)
(UK: In the UK, the human review tier maps to obligations under the Equality Act 2010 and ICE Regulations 2004, plus internal governance frameworks.)
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
The Decision Layer is not an AI agent - it's the governance layer above. It complements existing systems like SAP SuccessFactors, Workday, or DATEV and controls what an AI agent may do with these systems. Every decision is automatically documented - for auditors, employee representation bodies, and internal audit. This documentation is the <strong class="text-gosign-dark">decision act</strong>: one immutable record per micro-decision with input, business rule including version, confidence, model version, result, and contestation path - the artefact that makes the explanation of the individual decision under Art. 86 of the EU AI Act answerable.
</p>
<p class="text-body text-gosign-text-light mt-4">
How the Decision Layer addresses shadow AI and technically enforces company agreements is detailed in
<a href="/en/magazine/decision-layer-shadow-ai/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Article 6 of the Blueprint 2026</a>.
</p>

<!-- Comparison Table -->
<div class="mt-8 overflow-x-auto">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-dark/20">
<th class="py-3 pr-4 text-body font-bold text-gosign-dark"></th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Without Decision Layer</th>
<th class="py-3 pl-4 text-body font-bold text-gosign-accent-text">With Decision Layer</th>
</tr>
</thead>
<tbody class="text-body-lg text-gosign-text-light">
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Who decides?</td>
<td class="py-3 px-4">Unclear - the agent delivers a result</td>
<td class="py-3 pl-4">Defined per step: human, rule set, or AI</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Company agreements</td>
<td class="py-3 px-4">Manually followed - or forgotten</td>
<td class="py-3 pl-4">Stored as fixed rules, technically enforced</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Traceability</td>
<td class="py-3 px-4">Result visible, decision path not</td>
<td class="py-3 pl-4">Complete documentation per decision</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Auditor</td>
<td class="py-3 px-4">Must manually review each case</td>
<td class="py-3 pl-4">Direct access to decision documentation</td>
</tr>
<tr>
<td class="py-3 pr-4 font-semibold text-gosign-dark">Employee oversight</td>
<td class="py-3 px-4">Blocks - no transparency</td>
<td class="py-3 pl-4">Supports - every decision traceable</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Example -->
<section id="example" class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-2">How Does the Decision Layer Work in Practice?</h2>
<p class="text-body-lg text-gosign-text-light mb-8">
Sick leave example: 6 steps, clear accountability at each step. The Decision Layer defines for each: rule set, human, or automatic.
</p>
<img
src="/images/diagrams/decision-layer-krankmeldung-en.svg"
alt="Process example: sick leave processing with Decision Layer in 6 steps. Steps 1-2 automatic (read document, load employee data), steps 3-4 rule-based (validate against collective agreement, calculate continued pay), step 5 human decision (long-term illness over 6 weeks, duty of care), step 6 automatic SAP booking."
class="w-full"
loading="lazy"
width="1200"
height="600"
/>
</div>
</section>

<!-- Employee Oversight -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Why Do AI Projects Fail at Employee Oversight?</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
A common reason AI projects stall in enterprises: employee representation bodies block them. Not because they oppose technology - but because they lack transparency. In Germany specifically, works councils frequently halt AI deployments for this reason. The Decision Layer solves this:
</p>
<div class="mt-8 space-y-4">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent/10 rounded-full flex items-center justify-center text-gosign-accent font-bold text-small before:content-['✓']" aria-hidden="true"></span>
<p class="text-body-lg text-gosign-text-light">Every governance framework - collective agreements, works agreements, or company policies - is stored as a fixed rule. The agent cannot bypass it.</p>
</div>
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent/10 rounded-full flex items-center justify-center text-gosign-accent font-bold text-small before:content-['✓']" aria-hidden="true"></span>
<p class="text-body-lg text-gosign-text-light">For decisions affecting employees, a human always decides. Technically enforced, not just agreed upon.</p>
</div>
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent/10 rounded-full flex items-center justify-center text-gosign-accent font-bold text-small before:content-['✓']" aria-hidden="true"></span>
<p class="text-body-lg text-gosign-text-light">Every AI decision is documented: What was checked, which rule applied, what was the result.</p>
</div>
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent/10 rounded-full flex items-center justify-center text-gosign-accent font-bold text-small before:content-['✓']" aria-hidden="true"></span>
<p class="text-body-lg text-gosign-text-light">Employee representation bodies can trace how any decision was made, at any time.</p>
</div>
</div>
<p class="text-body-lg text-gosign-text-light mt-6">
<strong class="text-gosign-dark">The difference:</strong> Others promise transparency. The Decision Layer enforces it technically.
</p>
<p class="mt-4">
<a href="/en/governance/co-determination/" class="text-gosign-accent-text hover:underline font-semibold">Employee Oversight & Co-determination →</a>
</p>
</div>
</section>

<!-- Audit-Proof -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">How Does an AI Decision Become Audit-Proof?</h2>
<p class="text-body-lg text-gosign-accent-text font-semibold mt-4">Your auditor sees exactly what happened.</p>
<ul class="mt-6 space-y-3">
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-6 h-6 bg-gosign-accent/10 rounded-full flex items-center justify-center text-gosign-accent font-bold text-xs mt-0.5 before:content-['✓']" aria-hidden="true"></span>
<span class="text-body-lg text-gosign-text-light">Which document was processed - and when?</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-6 h-6 bg-gosign-accent/10 rounded-full flex items-center justify-center text-gosign-accent font-bold text-xs mt-0.5 before:content-['✓']" aria-hidden="true"></span>
<span class="text-body-lg text-gosign-text-light">Which rule was applied - and in which version?</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-6 h-6 bg-gosign-accent/10 rounded-full flex items-center justify-center text-gosign-accent font-bold text-xs mt-0.5 before:content-['✓']" aria-hidden="true"></span>
<span class="text-body-lg text-gosign-text-light">How confident was the agent in its assessment?</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-6 h-6 bg-gosign-accent/10 rounded-full flex items-center justify-center text-gosign-accent font-bold text-xs mt-0.5 before:content-['✓']" aria-hidden="true"></span>
<span class="text-body-lg text-gosign-text-light">Did a human review - and if so, who?</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-6 h-6 bg-gosign-accent/10 rounded-full flex items-center justify-center text-gosign-accent font-bold text-xs mt-0.5 before:content-['✓']" aria-hidden="true"></span>
<span class="text-body-lg text-gosign-text-light">What was the result and when was it booked?</span>
</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-6">Every one of these answers lives in a decision act - here is what it looks like:</p>
<div class="not-prose mt-4 bg-surface-raised border border-base rounded-soft overflow-hidden shadow-sm">
  <div class="px-5 py-3 border-b border-base bg-surface-dim">
    <div class="flex items-center gap-3">
      <div class="flex gap-1.5" aria-hidden="true">
        <span class="w-2.5 h-2.5 rounded-full bg-[#FF5F56]"></span>
        <span class="w-2.5 h-2.5 rounded-full bg-[#FFBD2E]"></span>
        <span class="w-2.5 h-2.5 rounded-full bg-[#27C93F]"></span>
      </div>
      <span class="font-code text-xs text-muted">decision-record / sick-leave / 2026-05-14 / EMP_0x52a8</span>
    </div>
  </div>
  <ol class="divide-y divide-base">
    <li class="p-5">
      <div class="flex items-start gap-4">
        <div class="flex-shrink-0 w-9 h-9 rounded-full flex items-center justify-center font-code text-xs font-bold border" style="background: rgba(3,105,161,0.08); border-color: rgba(3,105,161,0.3); color: #0369A1;">02</div>
        <div class="flex-1 min-w-0">
          <div class="flex flex-wrap items-center gap-2 mb-1.5">
            <span class="text-body font-semibold text-primary">Calculate continued pay under &#167;3, &#167;4 EFZG</span>
            <span class="inline-flex px-2 py-0.5 text-xs font-bold uppercase tracking-wider rounded text-white" style="background: #0369A1;">Rule</span>
          </div>
          <p class="text-small text-primary font-medium mb-2">6 weeks from 14 May 2026, 100% gross</p>
          <div class="font-code text-xs text-muted"><span>rule:</span> <span class="text-primary">EFZG-&#167;3+&#167;4 &#183; v2026-01</span></div>
        </div>
      </div>
    </li>
    <li class="p-5">
      <div class="flex items-start gap-4">
        <div class="flex-shrink-0 w-9 h-9 rounded-full flex items-center justify-center font-code text-xs font-bold border" style="background: rgba(109,78,216,0.08); border-color: rgba(109,78,216,0.3); color: #6D4ED8;">09</div>
        <div class="flex-1 min-w-0">
          <div class="flex flex-wrap items-center gap-2 mb-1.5">
            <span class="text-body font-semibold text-primary">Flag absence pattern</span>
            <span class="inline-flex items-center gap-1 px-2 py-0.5 text-xs font-bold uppercase tracking-wider rounded text-white" style="background: #6D4ED8;">AI <span class="font-mono opacity-90">91%</span></span>
          </div>
          <p class="text-small text-primary font-medium mb-2">Notice to HR operations: third short-term absence in six months</p>
          <div class="font-code text-xs text-muted"><span>model-reason:</span> <span class="text-primary">pattern match &#183; indicator, not a personnel decision</span></div>
          <div class="mt-3"><span class="inline-flex items-center px-3 py-1.5 text-xs font-semibold rounded border-2" style="border-color: #6D4ED8; color: #6D4ED8; background: rgba(109,78,216,0.08);">formally contestable &#183; Art. 14 EU AI Act</span></div>
        </div>
      </div>
    </li>
  </ol>
</div>
<p class="text-body text-gosign-text-light mt-4">Two of 13 micro-decisions in one case - each with rule version, confidence, and contestation path. <a href="/en/magazine/decision-act-contestable-ai-decisions/" class="text-gosign-accent-text hover:underline font-semibold">The complete decision act in detail &#8594;</a></p>
</div>
</section>

<!-- Three Types -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-2">Which Decisions Can AI Make on Its Own?</h2>
<p class="text-body-lg text-gosign-text-light mb-8">
Some decisions an AI agent can make on its own. Others need human review. And for strategic questions, the agent only provides data. The Decision Layer defines this - per step, not per process.
</p>
<img
src="/images/diagrams/decision-layer-drei-arten-en.svg"
alt="Three types of decisions in the Decision Layer: Left - human decides for people strategy, performance reviews, compensation policy (about one third). Center - agent works, human reviews for document processing, contract review, onboarding (about 40%). Right - agent autonomous for FAQ, standard certificates, deadline checks (about one quarter)."
class="w-full"
loading="lazy"
width="1200"
height="600"
/>
</div>
</section>

<!-- For Whom -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Who Is the Decision Layer For?</h2>
<div class="mt-8 space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Head of HR / CHRO</p>
<p class="text-body-lg text-gosign-text-light mt-1">You want to use AI in HR - without losing control. The Decision Layer ensures governance frameworks are enforced, employee representation bodies have transparency, and every decision is traceable.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">CFO / Head of Finance</p>
<p class="text-body-lg text-gosign-text-light mt-1">Every AI-assisted booking is audit-proof. Your auditor sees the complete decision path. Correction bookings are reduced because deterministic rule sets leave no room for interpretation - and where the agent decides autonomously, Confidence Routing ensures escalation when needed.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Employee Representatives</p>
<p class="text-body-lg text-gosign-text-light mt-1">No black box. Governance frameworks are technically stored and cannot be bypassed. For personnel decisions, a human always intervenes. In Germany: full co-determination transparency for works councils.</p>
</div>
<div class="border-l-4 border-gosign-dark/20 pl-6">
<p class="text-h3 font-bold text-gosign-text-light">IT / CTO</p>
<p class="text-body-lg text-gosign-text-light mt-1">Model-agnostic, infrastructure-agnostic, no vendor lock-in. <a href="/en/governance/reference-architecture/" class="text-gosign-accent-text hover:underline">Technical details in the Reference Architecture →</a></p>
</div>
</div>
</div>
</div>
</section>

<!-- Domain Cards -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">The Decision Layer for Your Processes</h2>
<div class="grid grid-cols-1 md:grid-cols-3 gap-6">
<a href="/en/hr-ai-agents/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<h3 class="text-h3 font-bold text-gosign-dark">HR & People Operations</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Sick leave, onboarding, employment references, contract review, policy queries. Compliant with employee representation requirements, EU AI Act compliant.</p>
<span class="inline-block mt-4 text-gosign-accent-text font-semibold text-body">View HR Agent →</span>
</a>
<a href="/en/finance-ai-agents/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<h3 class="text-h3 font-bold text-gosign-dark">Finance & Payroll</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Document processing, account assignment, payroll, closing entries. Audit-proof. DATEV and SAP integration.</p>
<span class="inline-block mt-4 text-gosign-accent-text font-semibold text-body">View Finance Agent →</span>
</a>
<a href="/en/services/ai-agents/document-agents/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<h3 class="text-h3 font-bold text-gosign-dark">Document Processing</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Invoices, contracts, certificates. Automatic classification and data extraction with rule-based validation.</p>
<span class="inline-block mt-4 text-gosign-accent-text font-semibold text-body">View Document Agents →</span>
</a>
</div>
</div>
</section>

<!-- EU AI Act -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Is the Decision Layer EU AI Act Compliant?</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
The EU AI Act sets requirements for transparency (Art. 13), human oversight (Art. 14), and record-keeping (Art. 12) - and, with Art. 86, gives affected persons a right to an explanation of the individual decision. The Decision Layer addresses these requirements as an architectural principle - not as an afterthought compliance project: the decision act per micro-decision is the answer to the individual-case question that chat logs and model cards cannot answer.
</p>
<p class="mt-4">
<a href="/en/governance/eu-ai-act/" class="text-gosign-accent-text hover:underline font-semibold">EU AI Act and HR in Detail →</a>
<span class="mx-2 text-gosign-text-light">·</span>
<a href="/en/magazine/decision-act-contestable-ai-decisions/" class="text-gosign-accent-text hover:underline font-semibold">The Decision Act: Why Every AI Decision Must Be Contestable →</a>
</p>
</div>
</section>

<!-- Entity Information -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Who Builds the Decision Layer?</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
The Decision Layer is developed and implemented by <strong class="text-gosign-dark">Gosign GmbH</strong>. Gosign is an Enterprise AI Infrastructure & Agent Engineering company based in Hamburg, Germany, with over 20 years of experience building complex systems for enterprises including Airbus, Volkswagen, Shell.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
4-6 weeks to the first productive process. Full source code access, no vendor lock-in. Goal: After 12-18 months, you operate your agents independently.
</p>
<p class="mt-4">
<a href="/en/about/" class="text-gosign-accent-text hover:underline font-semibold">About Gosign →</a>
<span class="mx-2 text-gosign-text-light">·</span>
<a href="/en/references/" class="text-gosign-accent-text hover:underline font-semibold">References →</a>
</p>
</div>
</section>

<!-- HR Agent Catalog -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark">Decision Layer in Practice: 48 HR Agents</h2>
<p class="text-body text-gosign-text mt-4">The HR Agent Catalog shows for each of the 48 agents how the Decision Layer splits decisions across human, rule set, and AI agent - with complete micro-decision tables and decision records.</p>
<a href="/en/hr-agent-catalog/" class="inline-flex items-center gap-2 mt-4 text-body font-semibold text-gosign-accent hover:underline">Explore the HR Agent Catalog &rarr;</a>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">Deep Dive in the Agent Briefing (Gosign Magazine)</h2>
<div class="grid md:grid-cols-3 gap-6">
<a href="/en/magazine/decision-act-contestable-ai-decisions/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<h3 class="text-h3 font-bold text-gosign-dark">The Decision Act: Contestable AI Decisions</h3>
</a>
<a href="/en/magazine/agent-governance-hr/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR</p>
<h3 class="text-h3 font-bold text-gosign-dark">Agent Governance for HR</h3>
</a>
<a href="/en/magazine/works-council-ai-co-determination/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<h3 class="text-h3 font-bold text-gosign-dark">Works Council and AI - Co-determination</h3>
</a>
</div>
</div>
</section>

--- Digital Agency Hamburg | Gosign | Web, AI, TYPO3 ---
> Gosign is a Hamburg-based digital agency for web development, AI integration and TYPO3. 25 years of experience. B2B focus.

<!-- What is Gosign? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">What is Gosign?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Gosign is a Hamburg-based digital agency with 25&nbsp;years of experience in web development, TYPO3 systems and AI integration for enterprises. Founded in 1999, today specialised in B2B websites, enterprise CMS projects and AI infrastructures. Gosign serves mid-market enterprises, universities and public sector organisations across the EU.
</p>
</div>
</section>

<!-- Why Gosign? -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Why Gosign?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Because we do not just build websites - we build digital infrastructure. Three core areas, one team:
</p>
</div>
</section>

<!-- Web Development & CMS -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Web Development &amp; CMS</h2>
<p class="text-body text-gosign-text leading-relaxed">
Websites that perform - technically and commercially. TYPO3, WordPress, Astro, headless architectures. From concept to go-live, from 10&nbsp;pages to 10,000. Gosign has analysed over 800 TYPO3 extensions and has been delivering enterprise CMS projects for two decades.
</p>
</div>
</section>

<!-- AI Integration -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">AI Integration for Enterprises</h2>
<p class="text-body text-gosign-text leading-relaxed">
AI infrastructure deployed directly within your enterprise environment: AI assistants, AI agents, model hosting (DeepSeek, Llama, Mistral) on your own infrastructure. GDPR-compliant, aligned with NIS2 and NIST Cybersecurity Framework standards, with no data leaving your environment. Gosign builds AI solutions that integrate into existing IT landscapes.
</p>
</div>
</section>

<!-- TYPO3 Specialisation -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">TYPO3 Specialisation</h2>
<p class="text-body text-gosign-text leading-relaxed">
Over 800 TYPO3 extensions monitored, more than 500 successfully implemented. From Solr enterprise search and SSO integration to e-commerce with aimeos. Gosign is one of the most experienced TYPO3 service providers in Europe.
</p>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Let us talk about your project - 30&nbsp;minutes, free of charge.</h3>
<p class="text-body text-gosign-text mb-6">We analyse your project, estimate effort and timeline, no obligation.</p>
<a
href="/en/contact/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Book a call
</a>
<p class="text-small text-gosign-text-light mt-4">25 years of experience · 800+ extensions · AI-accelerated development</p>
</div>
</section>

<!-- Comparison Table -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">What sets Gosign apart from other digital agencies</h2>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Criterion</th>
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Typical agency</th>
<th class="py-3 text-small font-bold text-gosign-dark">Gosign</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">CMS depth</td>
<td class="py-3 pr-4 text-body text-gosign-text">WordPress basics</td>
<td class="py-3 text-body text-gosign-text">TYPO3 Enterprise + WordPress + Headless</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">AI competence</td>
<td class="py-3 pr-4 text-body text-gosign-text">ChatGPT prompts</td>
<td class="py-3 text-body text-gosign-text">Custom AI infrastructure, model hosting</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Development speed</td>
<td class="py-3 pr-4 text-body text-gosign-text">Traditional</td>
<td class="py-3 text-body text-gosign-accent-text font-semibold">AI-accelerated: 60-80% faster</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Industry focus</td>
<td class="py-3 pr-4 text-body text-gosign-text">Everything for everyone</td>
<td class="py-3 text-body text-gosign-text">B2B, mid-market enterprises, universities, public sector</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Security</td>
<td class="py-3 pr-4 text-body text-gosign-text">Standard hosting</td>
<td class="py-3 text-body text-gosign-text">NIS2-aligned infrastructure, security monitoring</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Location</td>
<td class="py-3 pr-4 text-body text-gosign-text">Remote/Global</td>
<td class="py-3 text-body text-gosign-text">Hamburg, EU-based, personal support</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Industries -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Industries</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
Gosign works for organisations that take digital infrastructure seriously:
</p>
<div class="grid md:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Manufacturing &amp; Industry</h3>
<p class="text-body text-gosign-text">B2B websites with product configurators, dealer portals, technical documentation</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Automotive</h3>
<p class="text-body text-gosign-text">Brand portals, dealer networks, digital showrooms</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Health &amp; Pharma</h3>
<p class="text-body text-gosign-text">Compliance-ready websites, patient portals</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Education &amp; Universities</h3>
<p class="text-body text-gosign-text">Shibboleth SSO, programme finders, accessible web presences</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Associations &amp; Public Sector</h3>
<p class="text-body text-gosign-text">Member management, multilingual portals, accessibility</p>
</div>
</div>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
Gosign is a Hamburg-based digital agency with 25 years of experience in web development, TYPO3 and AI integration.
We have analysed over 800 TYPO3 extensions and today develop with AI assistance
up to 70&nbsp;% faster than with traditional methods. Our clients include mid-market
enterprises, universities and public sector organisations across the EU.
</p>
<p class="text-small text-gosign-text-light mt-2">As of: February 2026</p>
</div>
</section>

<!-- Related Topics -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Related Topics</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/en/wordpress-agency/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Web Development</p>
<p class="text-body font-semibold text-gosign-dark">WordPress Agency Hamburg</p>
</a>
<a href="/en/typo3-extensions/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">CMS</p>
<p class="text-body font-semibold text-gosign-dark">TYPO3 Extensions</p>
</a>
<a href="/en/website-security-standards/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Security</p>
<p class="text-body font-semibold text-gosign-dark">Website Security Standards</p>
</a>
</div>
</div>
</section>

--- eBook: AI in Finance - Governance Handbook for the CFO ---
> Free eBook: EU AI Act, external auditors, and Decision Layer - the governance handbook for finance leaders. High-risk deadline 2 August 2026, postponement to December 2027 provisionally agreed (Digital Omnibus, May 2026).

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">

<div class="grid md:grid-cols-5 gap-12 items-start">

<div class="md:col-span-3">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">What You Will Find in This Handbook</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
The EU AI Act (UK: UK AI regulatory framework) classifies AI-assisted credit decisions as high-risk (Annex III No. 5b). 73% of organizations still lack a governance framework (ISACA 2024). This handbook closes the gap - with finance-specific frameworks, checklists, and a Readiness Assessment.
</p>

<div class="space-y-4 mb-8">
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">1</span>
<div>
<p class="font-semibold text-gosign-dark">Why the CFO must lead AI governance in Finance - not IT</p>
<p class="text-small text-gosign-text-light">Governance ownership, role model, and CFO checklist.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">2</span>
<div>
<p class="font-semibold text-gosign-dark">Three types of financial decisions: Human, Rule-based, AI</p>
<p class="text-small text-gosign-text-light">The H/R/A framework with an Agent Readiness Score for each finance process.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">3</span>
<div>
<p class="font-semibold text-gosign-dark">EU AI Act: Requirements for the financial sector</p>
<p class="text-small text-gosign-text-light">High-risk delineation (Annex III No. 5b) with compliance checklist.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">4</span>
<div>
<p class="font-semibold text-gosign-dark">External auditors as governance partners</p>
<p class="text-small text-gosign-text-light">ISA 315, Auditor Portal, AI Literacy obligation since February 2025.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">5</span>
<div>
<p class="font-semibold text-gosign-dark">4 Finance processes in the Decision Layer</p>
<p class="text-small text-gosign-text-light">Accounts Payable, Travel Expenses, Financial Close, Fraud Detection - with Zero-Touch rates.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">6</span>
<div>
<p class="font-semibold text-gosign-dark">Finance Readiness Assessment (10 questions)</p>
<p class="text-small text-gosign-text-light">Where does your organization stand? Self-assessment with score and action recommendations.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">7</span>
<div>
<p class="font-semibold text-gosign-dark">90-day plan to get started</p>
<p class="text-small text-gosign-text-light">Inventory, Design, Pilot - structured path to the Decision Layer in three months.</p>
</div>
</div>
</div>
</div>

<div class="md:col-span-2">
<div class="bg-gosign-light border border-gosign-border rounded-card p-6 sticky top-8">
<p class="text-h3 font-bold text-gosign-dark mb-2">Download for free</p>
<p class="text-small text-gosign-text-light mb-4">PDF, 28 pages. Delivered instantly by email.</p>

<div class="space-y-3 mb-6">
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>EU AI Act Compliance Checklist (Finance)</span>
</div>
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>H/R/A Decision Framework</span>
</div>
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>Finance Readiness Assessment to fill in</span>
</div>
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>90-day implementation plan</span>
</div>
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>External Auditor Checklist (ISA 315)</span>
</div>
</div>

<button data-ebook-download class="w-full px-6 py-3 bg-gosign-accent-btn text-white font-semibold rounded-md hover:bg-gosign-accent-btn-hover transition-colors text-sm flex items-center justify-center gap-2 cursor-pointer">
<svg class="w-5 h-5" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M4 16v1a3 3 0 003 3h10a3 3 0 003-3v-1m-4-4l-4 4m0 0l-4-4m4 4V4"/></svg>
Download PDF
</button>
</div>
</div>

</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">5 Key Figures from the Handbook</h2>

<div class="grid sm:grid-cols-2 lg:grid-cols-3 gap-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">5%</p>
<p class="text-small text-gosign-text">of annual revenue is lost to fraud worldwide</p>
<p class="text-xs text-gosign-text-light mt-1">ACFE 2024</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">42%</p>
<p class="text-small text-gosign-text">of all invoices in accounts payable are still processed manually</p>
<p class="text-xs text-gosign-text-light mt-1">Institute of Finance & Management 2024</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">88-95%</p>
<p class="text-small text-gosign-text">Zero-Touch rate with Decision Layer in finance processes</p>
<p class="text-xs text-gosign-text-light mt-1">Gosign client projects</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">1:4-5</p>
<p class="text-small text-gosign-text">Investment ratio: 1 EUR technology = 4-5 EUR governance</p>
<p class="text-xs text-gosign-text-light mt-1">McKinsey 2024</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">EUR 15M</p>
<p class="text-small text-gosign-text">Maximum penalty for violating high-risk obligations</p>
<p class="text-xs text-gosign-text-light mt-1">EU AI Act, Art. 99</p>
</div>
</div>

</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Who Is This Handbook For?</h2>

<div class="grid sm:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">CFO / VP Finance</p>
<p class="text-small text-gosign-text-light">You are responsible for the AI strategy in finance and need a framework that convinces external auditors, legal, and the board at the same time.</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">Head of Finance / Accounting Manager</p>
<p class="text-small text-gosign-text-light">You implement AI-powered processes and need clear decision rules: What to automate, what not? How do you maintain audit assurance?</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">External Auditor / Internal Audit</p>
<p class="text-small text-gosign-text-light">You audit AI-powered financial processes and need transparency: Which postings does the agent process, which does a human? How does the audit trail work?</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">Finance Compliance / Legal</p>
<p class="text-small text-gosign-text-light">You need to implement EU AI Act requirements for financial processes and need a compliance checklist with concrete measures and ICS integration.</p>
</div>
</div>

</div>
</section>

<section class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-12 border-t border-gosign-border">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">More eBooks</h2>
<div class="grid grid-cols-1 md:grid-cols-2 gap-6">

<div class="bg-white border border-gosign-border rounded-card p-5">
<p class="font-semibold text-gosign-dark mb-1">AI in HR - Governance Handbook</p>
<p class="text-small text-gosign-text-light mb-3">For CHROs & HR Leaders</p>
<a href="/en/ebook/ai-hr-governance-handbook/" class="text-sm text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Download for free</a>
</div>

<div class="bg-white border border-gosign-border rounded-card p-5">
<p class="font-semibold text-gosign-dark mb-1">AI Infrastructure - Governance Handbook</p>
<p class="text-small text-gosign-text-light mb-3">For CTOs & IT Leaders</p>
<a href="/en/ebook/ai-infrastructure-governance-handbook/" class="text-sm text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Download for free</a>
</div>

<a href="/en/ebook/finance-agent-readiness-assessment/" class="block border border-gosign-border rounded-card p-4 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-1">Finance Assessment</p>
<p class="text-body font-semibold text-gosign-dark">Finance Agent Readiness Assessment</p>
<p class="text-small text-gosign-text-light mt-1">15 questions for CFO and external auditors</p>
</a>

</div>
</section>

--- eBook: AI in HR - The CHRO's Governance Handbook ---
> Free eBook: EU AI Act, works council, and Decision Layer - the governance handbook for HR leaders. High-risk deadline 2 August 2026, postponement to December 2027 provisionally agreed (Digital Omnibus, May 2026).

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">

<div class="grid md:grid-cols-5 gap-12 items-start">

<div class="md:col-span-3">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">What you'll find in this handbook</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
The EU AI Act classifies AI systems in HR as high-risk; under current law the obligations apply from 2 August 2026, but following the provisional Digital Omnibus agreement of 7 May 2026 they are set to be postponed to 2 December 2027 (formal adoption still pending, as of June 2026). 73% of organisations still lack a governance framework (ISACA 2024). This handbook bridges the gap - with concrete frameworks, checklists, and a readiness assessment.
</p>

<div class="space-y-4 mb-8">
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">1</span>
<div>
<p class="font-semibold text-gosign-dark">Why the CHRO must lead AI governance in HR - not IT</p>
<p class="text-small text-gosign-text-light">Governance ownership, role concepts, and the CHRO checklist.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">2</span>
<div>
<p class="font-semibold text-gosign-dark">Three types of decisions: Human, Rules Engine, AI</p>
<p class="text-small text-gosign-text-light">The Decision Framework with Agent Readiness Score for every HR process.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">3</span>
<div>
<p class="font-semibold text-gosign-dark">EU AI Act: 6 mandatory requirements in detail</p>
<p class="text-small text-gosign-text-light">Art. 9-15 with a compliance checklist you can tick off.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">4</span>
<div>
<p class="font-semibold text-gosign-dark">works council as design partner</p>
<p class="text-small text-gosign-text-light">Co-determination rights, works council agreement as technical constraint, AI literacy.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">5</span>
<div>
<p class="font-semibold text-gosign-dark">4 HR processes in the Decision Layer</p>
<p class="text-small text-gosign-text-light">Payroll, travel expenses, recruiting, leave & absence - with zero-touch rates.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">6</span>
<div>
<p class="font-semibold text-gosign-dark">Readiness assessment (10 questions)</p>
<p class="text-small text-gosign-text-light">Where does your organisation stand? Self-assessment with score and recommendations.</p>
</div>
</div>
</div>
</div>

<div class="md:col-span-2">
<div class="bg-gosign-light border border-gosign-border rounded-card p-6 sticky top-8">
<p class="text-h3 font-bold text-gosign-dark mb-2">Download for free</p>
<p class="text-small text-gosign-text-light mb-4">PDF, 25 pages. Delivered instantly by email.</p>

<div class="space-y-3 mb-6">
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>EU AI Act compliance checklist</span>
</div>
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>Decision Framework (H/R/A)</span>
</div>
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>Hands-on readiness assessment</span>
</div>
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>90-day implementation plan</span>
</div>
</div>
<button data-ebook-download class="w-full px-6 py-3 bg-gosign-accent-btn text-white font-semibold rounded-md hover:bg-gosign-accent-btn-hover transition-colors text-sm flex items-center justify-center gap-2 cursor-pointer">
<svg class="w-5 h-5" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M4 16v1a3 3 0 003 3h10a3 3 0 003-3v-1m-4-4l-4 4m0 0l-4-4m4 4V4"/></svg>
Download PDF
</button>
</div>
</div>

</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">5 key numbers from the handbook</h2>

<div class="grid sm:grid-cols-2 lg:grid-cols-3 gap-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">73%</p>
<p class="text-small text-gosign-text">of organisations without a formal AI governance framework</p>
<p class="text-xs text-gosign-text-light mt-1">ISACA 2024</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">6</p>
<p class="text-small text-gosign-text">mandatory requirements for high-risk HR AI from 2 August 2026 (postponement to Dec 2027 provisionally agreed - Digital Omnibus, May 2026)</p>
<p class="text-xs text-gosign-text-light mt-1">EU AI Act, Art. 9-15</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">85-92%</p>
<p class="text-small text-gosign-text">zero-touch rate with Decision Layer in HR processes</p>
<p class="text-xs text-gosign-text-light mt-1">Gosign client projects</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">1:4-5</p>
<p class="text-small text-gosign-text">investment ratio: 1 EUR technology = 4-5 EUR governance</p>
<p class="text-xs text-gosign-text-light mt-1">McKinsey 2024</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">60-80%</p>
<p class="text-small text-gosign-text">fewer correction postings through explicit rule sets</p>
<p class="text-xs text-gosign-text-light mt-1">Hackett Group 2024</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">15M</p>
<p class="text-small text-gosign-text">EUR maximum penalty for high-risk violations</p>
<p class="text-xs text-gosign-text-light mt-1">EU AI Act, Art. 99</p>
</div>
</div>

</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Who is this handbook for?</h2>

<div class="grid sm:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">CHRO / VP HR</p>
<p class="text-small text-gosign-text-light">You are responsible for the AI strategy in HR and need a framework that convinces the works council, legal, and the board at the same time.</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">Head of People Operations</p>
<p class="text-small text-gosign-text-light">You implement AI-powered processes and need clear decision rules: what to automate, what not.</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">Works Council / Staff Representatives</p>
<p class="text-small text-gosign-text-light">You review AI use in HR and need transparency: which decisions does the agent make, which are made by humans?</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">HR Compliance / Legal</p>
<p class="text-small text-gosign-text-light">You need to implement EU AI Act requirements and need a compliance checklist with concrete measures.</p>
</div>
</div>

</div>
</section>

<section class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-12 border-t border-gosign-border">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">More eBooks</h2>
<div class="grid grid-cols-1 md:grid-cols-2 gap-6">

<div class="bg-white border border-gosign-border rounded-card p-5">
<p class="font-semibold text-gosign-dark mb-1">AI in Finance - Governance Handbook</p>
<p class="text-small text-gosign-text-light mb-3">For CFOs & Finance Leaders</p>
<a href="/en/ebook/ai-finance-governance-handbook/" class="text-sm text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Download for free</a>
</div>

<div class="bg-white border border-gosign-border rounded-card p-5">
<p class="font-semibold text-gosign-dark mb-1">AI Infrastructure - Governance Handbook</p>
<p class="text-small text-gosign-text-light mb-3">For CTOs & IT Leaders</p>
<a href="/en/ebook/ai-infrastructure-governance-handbook/" class="text-sm text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Download for free</a>
</div>

<a href="/en/ebook/hr-agent-readiness-assessment/" class="block border border-gosign-border rounded-card p-4 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-1">HR Assessment</p>
<p class="text-body font-semibold text-gosign-dark">HR Agent Readiness Assessment</p>
<p class="text-small text-gosign-text-light mt-1">15 questions for your leadership team</p>
</a>

</div>
</section>

--- eBook: AI Infrastructure - Governance Handbook for the CTO ---
> Free eBook: Build, Buy, Hybrid - EU AI Act-compliant AI infrastructure. The governance handbook for CTOs and Heads of Infrastructure.

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">

<div class="grid md:grid-cols-5 gap-12 items-start">

<div class="md:col-span-3">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">What you will find in this handbook</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
According to Gartner (2024), enterprises will spend over USD 644 billion on AI infrastructure by 2027. At the same time, they waste 28% of cloud spending (Flexera 2024). This handbook shows how to build AI infrastructure that is governance-compliant, cost-efficient and EU AI Act-ready.
</p>

<div class="space-y-4 mb-8">
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">1</span>
<div>
<p class="font-semibold text-gosign-dark">Why the CTO must lead AI Infrastructure Governance</p>
<p class="text-small text-gosign-text-light">Shadow AI, the governance gap and the CTO checklist to get started.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">2</span>
<div>
<p class="font-semibold text-gosign-dark">Build, Buy, Hybrid: the B/B/H framework</p>
<p class="text-small text-gosign-text-light">Decision matrix by workload type with hidden costs and hidden risks.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">3</span>
<div>
<p class="font-semibold text-gosign-dark">EU AI Act: 6 technical requirements (Art. 9-15)</p>
<p class="text-small text-gosign-text-light">Compliance obligations as infrastructure decisions with a technical checklist.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">4</span>
<div>
<p class="font-semibold text-gosign-dark">Security & Data Sovereignty</p>
<p class="text-small text-gosign-text-light">Data Residency, Encryption, Zero Trust Architecture and GDPR compliance for LLM usage.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">5</span>
<div>
<p class="font-semibold text-gosign-dark">4 infrastructure patterns in production</p>
<p class="text-small text-gosign-text-light">Agent Orchestration, Document Intelligence, Model Gateway, Monitoring & Observability.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">6</span>
<div>
<p class="font-semibold text-gosign-dark">Infrastructure Readiness Assessment (10 questions)</p>
<p class="text-small text-gosign-text-light">Where does your infrastructure stand? Self-assessment with score and 90-day plan.</p>
</div>
</div>
</div>
</div>

<div class="md:col-span-2">
<div class="bg-gosign-light border border-gosign-border rounded-card p-6 sticky top-8">
<p class="text-h3 font-bold text-gosign-dark mb-2">Download for free</p>
<p class="text-small text-gosign-text-light mb-4">PDF, 28 pages. Delivered instantly via email.</p>

<div class="space-y-3 mb-6">
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>Build/Buy/Hybrid decision matrix</span>
</div>
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>EU AI Act compliance checklist (technical)</span>
</div>
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>4 production-ready infrastructure patterns</span>
</div>
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>Infrastructure Readiness Assessment + 90-day plan</span>
</div>
</div>

<button data-ebook-download class="w-full px-6 py-3 bg-gosign-accent-btn text-white font-semibold rounded-md hover:bg-gosign-accent-btn-hover transition-colors text-sm flex items-center justify-center gap-2 cursor-pointer">
<svg class="w-5 h-5" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M4 16v1a3 3 0 003 3h10a3 3 0 003-3v-1m-4-4l-4 4m0 0l-4-4m4 4V4"/></svg>
Download PDF
</button>
</div>
</div>

</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">5 key figures from the handbook</h2>

<div class="grid sm:grid-cols-2 lg:grid-cols-3 gap-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">644 bn</p>
<p class="text-small text-gosign-text">USD global AI infrastructure spending by 2027</p>
<p class="text-xs text-gosign-text-light mt-1">Gartner 2024</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">28%</p>
<p class="text-small text-gosign-text">of cloud spending wasted due to lack of governance</p>
<p class="text-xs text-gosign-text-light mt-1">Flexera 2024</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">82%</p>
<p class="text-small text-gosign-text">run multi-cloud without centralized AI governance</p>
<p class="text-xs text-gosign-text-light mt-1">HashiCorp 2024</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">40%</p>
<p class="text-small text-gosign-text">of security incidents caused by misconfigured cloud services</p>
<p class="text-xs text-gosign-text-light mt-1">ENISA 2024</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">15 M</p>
<p class="text-small text-gosign-text">EUR maximum fine for violating high-risk obligations</p>
<p class="text-xs text-gosign-text-light mt-1">EU AI Act, Art. 99</p>
</div>
</div>

</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Who is this handbook for?</h2>

<div class="grid sm:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">CTO / VP Engineering</p>
<p class="text-small text-gosign-text-light">You are responsible for the AI infrastructure strategy and need a framework that combines scalability, compliance and cost governance.</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">Head of Infrastructure / Platform</p>
<p class="text-small text-gosign-text-light">You build the platform for AI workloads and need production-ready patterns: Agent Orchestration, Model Gateway, Document Intelligence.</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">Cloud Architect / DevOps Lead</p>
<p class="text-small text-gosign-text-light">You decide build vs. buy and need the decision matrix: which workload to self-host, which to run as a managed service?</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">CISO / Head of Security</p>
<p class="text-small text-gosign-text-light">You must ensure data sovereignty and need the security stack: Zero Trust, PII screening, encryption, supply chain security.</p>
</div>
</div>

</div>
</section>

<section class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-12 border-t border-gosign-border">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">More eBooks</h2>
<div class="grid grid-cols-1 md:grid-cols-2 gap-6">

<div class="bg-white border border-gosign-border rounded-card p-5">
<p class="font-semibold text-gosign-dark mb-1">AI in HR - Governance Handbook</p>
<p class="text-small text-gosign-text-light mb-3">For CHROs & HR Leaders</p>
<a href="/en/ebook/ai-hr-governance-handbook/" class="text-sm text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Download for free</a>
</div>

<div class="bg-white border border-gosign-border rounded-card p-5">
<p class="font-semibold text-gosign-dark mb-1">AI in Finance - Governance Handbook</p>
<p class="text-small text-gosign-text-light mb-3">For CFOs & Finance Leaders</p>
<a href="/en/ebook/ai-finance-governance-handbook/" class="text-sm text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Download for free</a>
</div>

<a href="/en/ebook/hr-agent-readiness-assessment/" class="block border border-gosign-border rounded-card p-4 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-1">HR Assessment</p>
<p class="text-body font-semibold text-gosign-dark">HR Agent Readiness Assessment</p>
<p class="text-small text-gosign-text-light mt-1">15 questions for your leadership team</p>
</a>

<a href="/en/ebook/finance-agent-readiness-assessment/" class="block border border-gosign-border rounded-card p-4 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-1">Finance Assessment</p>
<p class="text-body font-semibold text-gosign-dark">Finance Agent Readiness Assessment</p>
<p class="text-small text-gosign-text-light mt-1">15 questions for CFO and external auditors</p>
</a>

</div>
</section>

--- eBook: Finance Agent Readiness Assessment - 15 Questions for CFO and Auditors ---
> Free assessment eBook: 15 questions on Finance Agent Readiness. Compliance check, audit readiness evaluation, team assessment with gap analysis.

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">

<div class="grid md:grid-cols-5 gap-12 items-start">

<div class="md:col-span-3">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">What you will find in this assessment</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
42% of all invoices in accounts payable are still processed manually (IFM 2024). At an average cost of EUR 11.50 per invoice, this is a measurable cost factor. This assessment shows where your finance organisation stands - and which agents deliver the greatest impact.
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8 mb-3">15 questions across 5 dimensions</h3>
<ul class="space-y-2 text-body text-gosign-text">
<li class="flex items-start gap-2"><span class="text-gosign-accent-text font-bold">1.</span> Audit readiness - How audit-ready are your processes?</li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text font-bold">2.</span> Professional secrecy - Regulatory compliance status and data separation</li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text font-bold">3.</span> ERP landscape - How integrated are your finance systems?</li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text font-bold">4.</span> Close speed - How fast is your month-end close?</li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text font-bold">5.</span> Process maturity - How formalised are your accounting rules?</li>
</ul>

<h3 class="text-h3 font-bold text-gosign-dark mt-8 mb-3">How the eBook differs from the online tool</h3>
<div class="overflow-x-auto">
<table class="w-full text-body text-gosign-text border-collapse mt-4">
<thead><tr class="border-b-2 border-gosign-border"><th class="text-left py-2 pr-4 font-bold text-gosign-dark">Feature</th><th class="text-left py-2 pr-4 font-bold text-gosign-dark">Online (3 min.)</th><th class="text-left py-2 font-bold text-gosign-dark">eBook (PDF)</th></tr></thead>
<tbody>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Questions</td><td class="py-2 pr-4">7</td><td class="py-2">15</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Compliance check</td><td class="py-2 pr-4">Basic</td><td class="py-2">In-depth (6 questions)</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Team assessment</td><td class="py-2 pr-4">No</td><td class="py-2">Yes (CFO + Auditor + IT)</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Gap analysis</td><td class="py-2 pr-4">No</td><td class="py-2">Yes</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Printable</td><td class="py-2 pr-4">No</td><td class="py-2">Yes (A4 optimised)</td></tr>
</tbody>
</table>
</div>
</div>

<div class="md:col-span-2">
<div class="sticky top-24 bg-gosign-light border border-gosign-border rounded-card p-6">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-3">Free PDF</p>
<p class="text-h3 font-bold text-gosign-dark mb-2">Download the assessment</p>
<p class="text-small text-gosign-text-light mb-4">14 pages, compliance check, audit readiness evaluation, team assessment with gap analysis.</p>
<a href="#download" class="block w-full text-center px-6 py-3 bg-gosign-accent-btn text-white font-semibold rounded-lg hover:bg-gosign-accent-btn-hover transition-colors" data-ebook-download>Download assessment</a>
<p class="text-xs text-gosign-text-light mt-3">Only email address required. Instant PDF delivery.</p>
</div>
</div>

</div>
</div>
</section>

<!-- Quick Check Reference -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<div class="border-2 border-gosign-accent/20 rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Quick check: Online assessment</p>
<p class="text-body text-gosign-text mb-4">No time for the full assessment? Start with the 3-minute quick check with 7 questions and an automatic radar chart.</p>
<a href="/en/finance-agent-readiness/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Start online assessment &rarr;</a>
</div>
</div>
</section>

<!-- More eBooks -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">More eBooks</h2>
<div class="grid grid-cols-1 sm:grid-cols-2 gap-4">
<a href="/en/ebook/ai-finance-governance-handbook/" class="block border border-gosign-border rounded-card p-4 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-1">Finance Governance</p>
<p class="text-body font-semibold text-gosign-dark">AI in Finance: Governance Handbook</p>
</a>
<a href="/en/ebook/hr-agent-readiness-assessment/" class="block border border-gosign-border rounded-card p-4 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-1">HR Assessment</p>
<p class="text-body font-semibold text-gosign-dark">HR Agent Readiness Assessment</p>
</a>
</div>
</div>
</section>

--- eBook: HR Agent Readiness Assessment - 15 Questions for the Leadership Team ---
> Free assessment eBook: 15 questions on HR Agent Readiness. Printable worksheets, radar chart template, team assessment with gap analysis.

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">

<div class="grid md:grid-cols-5 gap-12 items-start">

<div class="md:col-span-3">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">What you will find in this assessment</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
73% of organisations have no AI governance framework yet (ISACA 2024). This assessment shows you where your HR organisation stands - not as a theoretical model, but as a working document for your team.
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8 mb-3">15 questions across 5 dimensions</h3>
<ul class="space-y-2 text-body text-gosign-text">
<li class="flex items-start gap-2"><span class="text-gosign-accent-text font-bold">1.</span> Process maturity - How documented and consistent are your HR processes?</li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text font-bold">2.</span> Governance - Who is responsible for AI in HR?</li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text font-bold">3.</span> Data landscape - How good is your HR data quality?</li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text font-bold">4.</span> Employee representation - How involved are employee representatives in AI decisions?</li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text font-bold">5.</span> IT infrastructure - How integrated is your HR system landscape?</li>
</ul>

<h3 class="text-h3 font-bold text-gosign-dark mt-8 mb-3">How the eBook differs from the online tool</h3>
<div class="overflow-x-auto">
<table class="w-full text-body text-gosign-text border-collapse mt-4">
<thead><tr class="border-b-2 border-gosign-border"><th class="text-left py-2 pr-4 font-bold text-gosign-dark">Feature</th><th class="text-left py-2 pr-4 font-bold text-gosign-dark">Online (3 min.)</th><th class="text-left py-2 font-bold text-gosign-dark">eBook (PDF)</th></tr></thead>
<tbody>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Questions</td><td class="py-2 pr-4">7</td><td class="py-2">15</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Radar chart</td><td class="py-2 pr-4">Automatic</td><td class="py-2">Self-draw template</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Team assessment</td><td class="py-2 pr-4">No</td><td class="py-2">Yes (4-5 participants)</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Gap analysis</td><td class="py-2 pr-4">No</td><td class="py-2">Yes</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Printable</td><td class="py-2 pr-4">No</td><td class="py-2">Yes (A4 optimised)</td></tr>
</tbody>
</table>
</div>
</div>

<div class="md:col-span-2">
<div class="sticky top-24 bg-gosign-light border border-gosign-border rounded-card p-6">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-3">Free PDF</p>
<p class="text-h3 font-bold text-gosign-dark mb-2">Download the assessment</p>
<p class="text-small text-gosign-text-light mb-4">14 pages, printable worksheets, team assessment with gap analysis.</p>
<a href="#download" class="block w-full text-center px-6 py-3 bg-gosign-accent-btn text-white font-semibold rounded-lg hover:bg-gosign-accent-btn-hover transition-colors" data-ebook-download>Download assessment</a>
<p class="text-xs text-gosign-text-light mt-3">Only email address required. Instant PDF delivery.</p>
</div>
</div>

</div>
</div>
</section>

<!-- Quick Check Reference -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<div class="border-2 border-gosign-accent/20 rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Quick check: Online assessment</p>
<p class="text-body text-gosign-text mb-4">No time for the full assessment? Start with the 3-minute quick check with 7 questions and an automatic radar chart.</p>
<a href="/en/hr-agent-readiness/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Start online assessment &rarr;</a>
</div>
</div>
</section>

<!-- More eBooks -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">More eBooks</h2>
<div class="grid grid-cols-1 sm:grid-cols-2 gap-4">
<a href="/en/ebook/ai-hr-governance-handbook/" class="block border border-gosign-border rounded-card p-4 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-1">HR Governance</p>
<p class="text-body font-semibold text-gosign-dark">AI in HR: Governance Handbook for the CHRO</p>
</a>
<a href="/en/ebook/finance-agent-readiness-assessment/" class="block border border-gosign-border rounded-card p-4 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-1">Finance Assessment</p>
<p class="text-body font-semibold text-gosign-dark">Finance Agent Readiness Assessment</p>
</a>
</div>
</div>
</section>

--- Free eBooks - AI Governance Handbooks ---
> Download free governance handbooks for HR, Finance, and Infrastructure. EU AI Act compliance, Decision Layer architecture, readiness assessments.

<section class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-12">
<div class="grid grid-cols-1 md:grid-cols-3 gap-8">

<div class="bg-white border border-gosign-border rounded-card p-6 flex flex-col">
<div class="w-12 h-12 rounded-full bg-orange-50 flex items-center justify-center mb-4">
<svg class="w-6 h-6 text-gosign-accent" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M17 20h5v-2a3 3 0 00-5.356-1.857M17 20H7m10 0v-2c0-.656-.126-1.283-.356-1.857M7 20H2v-2a3 3 0 015.356-1.857M7 20v-2c0-.656.126-1.283.356-1.857m0 0a5.002 5.002 0 019.288 0M15 7a3 3 0 11-6 0 3 3 0 016 0z"></path></svg>
</div>
<h2 class="text-h3 font-bold text-gosign-dark mb-2">AI in HR</h2>
<p class="text-body text-gosign-text mb-3 flex-1">EU AI Act checklist, Decision Framework, works council perspective, and Readiness Assessment - the governance handbook for the CHRO.</p>
<p class="text-small text-gosign-text-light mb-4">For CHROs & HR Leaders - 25 pages</p>
<a href="/en/ebook/ai-hr-governance-handbook/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Download for free</a>
</div>

<div class="bg-white border border-gosign-border rounded-card p-6 flex flex-col">
<div class="w-12 h-12 rounded-full bg-orange-50 flex items-center justify-center mb-4">
<svg class="w-6 h-6 text-gosign-accent" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 7h6m0 10v-3m-3 3h.01M9 17h.01M9 14h.01M12 14h.01M15 11h.01M12 11h.01M9 11h.01M7 21h10a2 2 0 002-2V5a2 2 0 00-2-2H7a2 2 0 00-2 2v14a2 2 0 002 2z"></path></svg>
</div>
<h2 class="text-h3 font-bold text-gosign-dark mb-2">AI in Finance</h2>
<p class="text-body text-gosign-text mb-3 flex-1">Compliance, auditors, and Decision Layer - the governance handbook for the CFO. With H/R/A Framework and finance-specific Readiness Assessment.</p>
<p class="text-small text-gosign-text-light mb-4">For CFOs & Finance Leaders - 28 pages</p>
<a href="/en/ebook/ai-finance-governance-handbook/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Download for free</a>
</div>

<div class="bg-white border border-gosign-border rounded-card p-6 flex flex-col">
<div class="w-12 h-12 rounded-full bg-orange-50 flex items-center justify-center mb-4">
<svg class="w-6 h-6 text-gosign-accent" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M5 12h14M5 12a2 2 0 01-2-2V6a2 2 0 012-2h14a2 2 0 012 2v4a2 2 0 01-2 2M5 12a2 2 0 00-2 2v4a2 2 0 002 2h14a2 2 0 002-2v-4a2 2 0 00-2-2m-2-4h.01M17 16h.01"></path></svg>
</div>
<h2 class="text-h3 font-bold text-gosign-dark mb-2">AI Infrastructure</h2>
<p class="text-body text-gosign-text mb-3 flex-1">Build, Buy, Hybrid - EU AI Act-compliant infrastructure. With B/B/H Framework, 7-Layer Reference Architecture, and CTO checklist.</p>
<p class="text-small text-gosign-text-light mb-4">For CTOs & IT Leaders - 28 pages</p>
<a href="/en/ebook/ai-infrastructure-governance-handbook/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Download for free</a>
</div>

</div>

<h2 class="text-h2 font-bold text-gosign-dark mt-12 mb-6">Readiness Assessments</h2>
<p class="text-body text-gosign-text-light mb-8">How ready is your organisation for AI Agents? 15 questions, worksheets to fill in, team assessment with delta analysis.</p>

<div class="grid grid-cols-1 md:grid-cols-2 gap-8">

<div class="bg-white border-2 border-gosign-accent/20 rounded-card p-6 flex flex-col">
<div class="w-12 h-12 rounded-full bg-orange-50 flex items-center justify-center mb-4">
<svg class="w-6 h-6 text-gosign-accent" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 5H7a2 2 0 00-2 2v12a2 2 0 002 2h10a2 2 0 002-2V7a2 2 0 00-2-2h-2M9 5a2 2 0 002 2h2a2 2 0 002-2M9 5a2 2 0 012-2h2a2 2 0 012 2m-6 9l2 2 4-4"></path></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">HR Agent Readiness</h3>
<p class="text-body text-gosign-text mb-3 flex-1">15 questions for your leadership team. Process maturity, governance, data landscape, worker representation, IT infrastructure.</p>
<p class="text-small text-gosign-text-light mb-4">For CHROs & HR leadership team - 14 pages</p>
<a href="/en/ebook/hr-agent-readiness-assessment/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Download assessment</a>
</div>

<div class="bg-white border-2 border-gosign-accent/20 rounded-card p-6 flex flex-col">
<div class="w-12 h-12 rounded-full bg-orange-50 flex items-center justify-center mb-4">
<svg class="w-6 h-6 text-gosign-accent" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 5H7a2 2 0 00-2 2v12a2 2 0 002 2h10a2 2 0 002-2V7a2 2 0 00-2-2h-2M9 5a2 2 0 002 2h2a2 2 0 002-2M9 5a2 2 0 012-2h2a2 2 0 012 2m-6 9l2 2 4-4"></path></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Finance Agent Readiness</h3>
<p class="text-body text-gosign-text mb-3 flex-1">15 questions for CFO and external auditors. Compliance check, ERP landscape, close speed, fraud detection maturity.</p>
<p class="text-small text-gosign-text-light mb-4">For CFOs & Finance leadership team - 14 pages</p>
<a href="/en/ebook/finance-agent-readiness-assessment/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Download assessment</a>
</div>

</div>

<h2 class="text-h2 font-bold text-gosign-dark mt-12 mb-6">Online Quick Check</h2>
<p class="text-body text-gosign-text-light mb-8">No time for the full 15-question assessment? The online quick check takes 3 minutes - with automatic radar chart and agent recommendations.</p>

<div class="grid grid-cols-1 md:grid-cols-2 gap-8">
<a href="/en/hr-agent-readiness/" class="block bg-gosign-dark rounded-card p-6 hover:bg-gosign-dark/90 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">3 minutes, 7 questions</p>
<p class="text-h3 font-bold text-white">HR Agent Readiness</p>
<p class="text-body text-white/70 mt-2">Maturity level, radar chart and recommendations from the 48-agent catalog.</p>
</a>
<a href="/en/finance-agent-readiness/" class="block bg-gosign-dark rounded-card p-6 hover:bg-gosign-dark/90 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">3 minutes, 7 questions</p>
<p class="text-h3 font-bold text-white">Finance Agent Readiness</p>
<p class="text-body text-white/70 mt-2">Maturity level, radar chart and recommendations from the 49-agent catalog.</p>
</a>
</div>

</section>

--- Facts - Gosign at a Glance ---
> Citation-ready facts about Gosign GmbH. Company data, locations, certifications, and compliance standards.

<article class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<div class="prose prose-lg prose-headings:text-gosign-dark prose-headings:font-bold prose-h2:text-h2 prose-h2:mt-12 prose-h2:mb-4 prose-h3:text-h3 prose-h3:mt-8 prose-h3:mb-3 prose-p:text-gosign-text prose-p:leading-relaxed prose-a:text-gosign-accent-text prose-a:underline prose-a:decoration-gosign-accent-text/30 hover:prose-a:decoration-gosign-accent-text prose-strong:text-gosign-dark prose-ul:text-gosign-text prose-ol:text-gosign-text">

## Company

Gosign GmbH. Software development company, founded in Hamburg in 2001. Owner-managed. Managing Directors: Bert Gogolin and Dieter Gogolin. Hallerstraße 8, 20146 Hamburg, Germany. Commercial Register Hamburg HRB 112197. VAT ID: DE215891388.

## Key Figures

108 employees. Over 5,000 projects since 2001. 25 years in software development. Since 2023 focused on Enterprise AI Infrastructure and Agent Engineering. Reference clients: Airbus, Volkswagen, Shell, Evonik, Sony.

## Locations

Hamburg (headquarters), Kraków, Barcelona, Lisbon, São Paulo. Development centre in Pakistan since 2002.

## Languages

German, English, Polish, Spanish, Portuguese, Urdu.

## Memberships and Certifications

Member of BVDW (German Federal Association for the Digital Economy). AI engineers hold Microsoft Azure AI certifications.

## Compliance Standards

Cert-Ready by Design: ISA, PS 951, IDW, GoB/GoBD (German record-keeping standard). EU AI Act Readiness: Risk classification and documentation obligations integrated into the agent architecture. Data Residency: Data processing in the client's infrastructure - Azure EU, GCP EU, AWS EU, self-hosted, or hybrid. The client decides on region and hosting model. DPAs with all sub-processors. For complete Cloud Act independence: self-hosted in an EU data center or on your own servers. GDPR: No cookies, no trackers, no external embeds on gosign.de. Web analytics cookieless and aggregated.

## Contact

Gosign GmbH · Hallerstraße 8 · 20146 Hamburg, Germany
→ [Get in touch](/en/contact/)

</div>
</div>
</article>

--- Account Coding Agent ---
> Assigns incoming invoices to the correct GL account (SKR03/04 or custom), cost centre and tax code.

## Incorrect coding costs five figures at every tax audit

Small and mid-sized businesses pay an average of EUR 24,000 (USD 26,000) in back taxes after a standard audit. For VAT-focused audits the figure rises to around EUR 25,000 per company, and more than half of all audits result in additional assessments. The most frequent cause: incorrect account coding. Wrong GL account means wrong tax treatment. Wrong tax treatment means denied input VAT recovery. Denied input VAT across several years adds up quickly into six-figure territory.

The problem is not negligence. A company processing 10,000 incoming invoices per month makes 10,000 coding decisions - every month. With manual processing, the Institute of Finance and Management (IOFM) puts the error rate at roughly 2%. That is 200 invoices every month where GL account, cost centre or tax code is wrong. Every single one is a finding a tax auditor can pick up.

## Ten decisions per invoice - each with tax consequences

Account coding is often treated as a data-entry step. In reality it is a chain of ten individual decisions, each triggering different legal consequences.

A real-world example: an invoice for consulting services from an EU service provider arrives. The accounting team must decide: Which GL account? Which cost centre? Which profit centre? Reverse charge under (US: the customer-accounts-for-VAT mechanism) or standard VAT? Is input VAT deductible? Is the amount above the low-value asset threshold? Does it need period-based accrual? Only when every sub-decision is correct does the final journal entry hold.

Each of these decisions follows its own logic. GL account assignment flows from the service description and the chart of accounts. The tax code follows VAT law. Capitalisation follows commercial and tax accounting rules. Anyone looking at a single decision in isolation misses the interactions. Anyone making all ten manually needs experience, concentration and time - for every single invoice.

## Rule-based coding, human review only for interpretation cases

The [Decision Layer](/en/decision-layer/) breaks every coding process into those ten decision steps and defines for each one: rule engine, AI, or human. For account coding the split is clear. Nine out of ten steps are solvable by rules. Tax code determination under VAT law, input VAT deduction checks, low-value asset thresholds, period-end accrual rules - these are deterministic decisions with a single correct answer.

The one step that needs AI support is interpretation. When a service description on an invoice reads "H3 project support" and the chart of accounts offers fifteen possible GL accounts, a rule engine is not enough. Here the language model evaluates, based on historical codings, which account fits - and returns a confidence score. If the score falls below the defined threshold, the agent escalates to a clerk. Above the threshold, it posts automatically.

The result: the accounts team no longer processes 10,000 invoices. It processes the 300 where the agent is not confident enough. The rest flows through - checked, coded, documented.

## Every coding becomes audit evidence

A tax auditor does not ask whether a coding is correct. The auditor asks why it was made this way rather than another. That is where manual accounting is weakest: the justification exists only in the head of the clerk who processed the invoice eight months ago.

The agent documents the full decision path for every coding: GL account applied with rationale, tax code with statutory reference, cost centre, confidence score and whether the decision was automatic or manual. That satisfies German GoBD (German record-keeping standard) bookkeeping principles for procedural documentation. The auditor does not see a result - the auditor sees the path to that result, for every one of the 120,000 invoices in a year.

## The chart of accounts engine as the foundation for all posting agents

Account coding is the first step in accounts payable, but not the only one. Travel expenses, entertainment costs, asset additions, provisions, accruals - every one of these processes needs the same core logic: service to GL account to tax code. Anyone who builds this mapping cleanly for coding is already building the infrastructure for every subsequent posting agent.

The mapping framework the Account Coding Agent uses becomes the standard building block. The confidence scoring and the escalation pattern - post automatically or hand over to a human - become the blueprint. Not every Finance agent has to answer the question of how to handle uncertainty again. The Account Coding Agent answers it once, and all the others build on it.

--- Accruals Agent ---
> Identifies prepaid expenses and deferred income from payments and service periods, calculates proportional amounts.

When month-end close delivers a distorted period result, the executive team makes decisions on the wrong foundation. The most common cause: missing or incorrect accruals. Ninety-four percent of finance teams still create their accruals in spreadsheets - and half of them take more than six working days for the full close. At its core, period-end accrual is not a matter of judgement. It is arithmetic with a calendar.

## Every forgotten prepaid expense distorts management reporting

An annual insurance premium of EUR 120,000 (USD 130,000) is paid in January. Without accrual, the full EUR 120,000 burdens January while February through December look too good. Multiplied across dozens of such items - software licences, maintenance contracts, prepaid rent - the result is a monthly P&L that says more about payment timing than about the actual state of the business.

The consequences go beyond presentation. Flawed period results distort forecasts, corrupt variance analysis and erode the trust of auditors and supervisory boards. According to a Center for Audit Quality analysis, errors in accruals, provisions and estimates are the most frequently cited cause of financial restatements. Every correction costs not just money but, more importantly, credibility.

## Eight of ten decision steps are pure arithmetic

The [Decision Layer](/en/decision-layer/) breaks every accrual process into ten decision steps. Eight of them are fully rule-based: Is this a prepaid expense? Is this income received before the reporting date that represents revenue for a period after it (deferred income)? Is it a provision rather than an accrual? Which period does the expense economically belong to? What is the proportional amount? Is the recognised amount prudently valued? Which journal entry applies? And exactly when does the reversal happen?

None of these steps requires human judgement. The date comparison between payment date and service period is unambiguous. The proportional calculation follows a fixed formula. The posting logic for prepaid expenses or deferred income is defined in every chart of accounts. And the reversal in the following month is an automatic consequence of the original entry.

This is exactly what makes the Accruals Agent a textbook case for automation in the general ledger: high volume, low complexity, zero discretion. The audit-ready documentation - source, service period, calculation path, reversal date - is a by-product of every posting, not a retrospective obligation.

## Two steps are where AI makes the difference

The real weakness in manual accruals is not the calculation. It is recognition. Who spots the new framework contract with quarterly payment and monthly service period? Who finds the December invoice whose service period runs through March?

Two of the ten decision steps use AI: estimating the accrual amount when no invoice amount is available yet, and detecting cross-period events in contracts and invoices. The agent scans new contracts for service periods, reconciles invoice data against contract durations and identifies situations that require an accrual - before they are missed at month-end. This detection is why the agent not only works faster than a human, but more completely.

Human intervention stays where it belongs: with the statutory auditor. Every single accrual - rule-based or AI-detected - is auditable and challengeable.

## Concrete impact: month-end loses its bottleneck

An industrial company with 200 active accrual items per month - software licences, insurance, lease payments, maintenance contracts, prepaid services - typically burns two to three person-days purely on period-end accruals. Excel lists with service periods, manual postings, reviews of prior-month reversals.

The agent reduces this workload to reviewing exceptions. Recurring accruals are created and reversed automatically. New situations are detected and presented for release. Documentation is immediately audit-ready. What remains is an approval list instead of a creation list.

The accrual infrastructure the agent builds has impact beyond its own process. The reversal logic is reused by the Provisions Agent. The cross-period recognition feeds data into the Lease Accounting Agent and Contract Compliance Agent. Period-end accrual is not the most dramatic process in finance. But it is the foundation on which every other period result stands.

--- Annual Statement Preparation Agent ---
> Orchestrates the annual close checklist, consolidates reconciliations, reviews valuation options, drafts notes and management report.

No annual financial statement fails because of missing expertise. It fails because of orchestration: reconciliations that never reach completion, queries about the asset register that sit in an inbox for three days, notes disclosures that materialise at the last minute. The finance team knows every single step - and still loses weeks coordinating between them.

## The closing weeks consume the entire team on routine work

According to APQC Open Standards Benchmarking, the cross-industry median for the monthly close sits in the higher single-digit days range - most finance teams need longer than five working days for the monthly close alone. The annual statement multiplies that effort: the asset register, provisions schedule, equity schedule, cash flow statement, tax reconciliation, notes, management report, auditor documentation and regulatory filing all come on top.

A concrete scenario illustrates the problem. A mid-sized manufacturer with EUR 200 million (USD 220 million) in revenue closes the fiscal year. The Head of Finance coordinates a team of six over four weeks. Three of them spend most of their time building schedules - arithmetic derivations from data that already exists in the system. One person assembles documents for the statutory auditor. Valuation decisions - the actual expert work - fill perhaps 20 percent of total closing time.

Meanwhile, late filings carry penalties. In Germany, the Federal Office of Justice imposes a minimum of EUR 2,500 (USD 2,750) per offence, rising to EUR 25,000 (USD 27,500) in repeat cases. For capital-market-oriented companies, the reputational risk can outweigh the fine itself. (UK: Companies House late filing penalties follow a similar tiered structure.)

## Fifteen decision steps separate routine from judgement

The [Decision Layer](/en/decision-layer/) decomposes the entire annual statement process into fifteen individual decision steps - and assigns each to a clear tier. The result is a map showing where automation adds value and where human judgement remains essential.

Tier 1 (rule engine) covers nine steps: the close checklist, consolidation of reconciliations, the tax reconciliation for standard items, deferred tax calculations based on temporary differences, the filing preparation, and the four schedules (provisions, assets, equity, cash flow). All of these follow defined rules and existing data.

Tier 2 (AI draft with human approval) covers three steps: the notes disclosures draft, the management report draft and the preparation of auditor documentation based on the PBC (Prepared by Client) list. The agent produces structured drafts - content responsibility stays with the specialist team.

Three steps remain exclusively with the human: valuation options (an accounting policy decision), the subsequent events review (a materiality assessment) and the balance sheet oath (personal attestation by management). No automation replaces the judgement these steps require.

## The agent orchestrates - the human decides

What changes in practice? The agent takes over sequencing. It checks whether all reconciliations are complete before triggering the next step. It builds the four schedules directly from the outputs of upstream agents. It prepares notes disclosures as a structured draft the team revises rather than writes from scratch. It assembles the auditor package according to the PBC list.

The team shifts its time: away from coordination, toward valuation decisions. The question is no longer "Is the asset register finished?" but "Which valuation method do we apply to pension provisions?" - the question a CFO is actually paid to answer.

For the statutory auditor, a side effect emerges: every decision step is documented, every data source traceable. The audit does not become less rigorous - but it starts from a complete, structured foundation.

## Every upstream agent improves closing quality

The Annual Statement Preparation Agent is not an isolated tool. It is the integration point of the entire finance infrastructure. The asset register draws on the Depreciation Agent. The provisions schedule relies on the Provisions Agent. Account reconciliations come from the Reconciliation Agent, tax data from the VAT Agent, write-downs from the Receivables Management Agent.

The implication: organisations that run the upstream agents cleanly have better data at annual close - automatically. Those that define the annual statement as the goal build the entire agent infrastructure backwards from that point. The annual statement is not the beginning - it is the proof that the infrastructure works.

--- Asset Capitalisation Agent ---
> Identifies assets requiring capitalisation from invoices, determines acquisition and production costs per HGB Paragraph 255.

Incorrect capitalisation decisions rank among the costliest avoidable errors in fixed asset accounting. Expensing a capital asset depresses profit in the wrong year. Capitalising a recurring cost inflates the balance sheet. In both cases, depreciation, the tax burden and the asset register are wrong for years to come. The Asset Capitalisation Agent prevents exactly this misallocation - not by automating all of accounting, but by structurally decomposing every single capitalisation decision.

## Nearly one in three tax audits flags the asset register

The numbers are clear. According to a PwC survey, every second company must pay additional taxes after a tax audit. In 29 percent of affected companies, the findings relate to fixed asset classification (source: PwC Tax Audit Study, 2024). The most common reason: assets were misclassified, ancillary acquisition costs were not correctly allocated, or useful lives were set without traceable justification.

Germany's Federal Ministry of Finance reports total additional tax revenue from audits in 2024 at EUR 10.9 billion (USD 12 billion) across 140,764 audited businesses. A significant share falls on asset register corrections - because the original capitalisation decision was undocumented or based on flawed assumptions.

For CFOs, that means: the capitalisation decision is not a bookkeeping detail. It is an audit risk with measurable financial consequences.

## The capitalisation decision takes seconds - and carries consequences for years

Picture a typical week in accounts payable at a mid-sized company. Forty incoming invoices, six of them above EUR 800 (USD 880) net. Each of those invoices demands the same sequence of decisions: Is this a standalone asset or an ongoing service? Is the amount above the low-value asset threshold? Which asset class? Which useful life per the depreciation table? Do transport costs count as ancillary acquisition costs?

A clerk often makes these decisions in minutes - under time pressure, with incomplete information, sometimes relying on experience rather than the current official depreciation table. The consequences surface years later: during the physical inventory, when assets in the register do not match reality. Or during a tax audit, when the auditor questions the useful life of a special-purpose machine and finds no documentation.

The error source is not a lack of competence. It is structural: every capitalisation decision contains deterministic elements (threshold, asset class, cost calculation) and discretionary elements (useful life for custom equipment, delineation of composite assets). When both merge in a single manual step, traceability disappears.

## Nine decision steps separate rules from judgement

The [Decision Layer](/en/decision-layer/) breaks every asset addition into nine discrete steps. Each step has a defined decision-maker: rule engine, AI model, or human.

The identification of the asset from the invoice description uses a language model. An invoice for "assembly and commissioning of production line - Hall 7" contains no EAN number and no asset master record - but enough context to recognise the asset.

The capitalisation check is purely rule-based: net amount above EUR 800 (USD 880), therefore mandatory capitalisation. Below that, low-value asset treatment or pooling applies. The same holds for the cost basis calculation, inventory number assignment and recording in the asset register. These steps are deterministic. They benefit not from human judgement but from consistency and completeness.

Borderline cases are different: assigning a CNC milling machine with custom configuration to the correct asset class can be rule-prepared but not conclusively decided by rules alone. The useful life of a special-purpose machine does not appear in the standard depreciation table. Here the human decides - but on the basis of a pre-structured decision template, not a blank sheet.

## The human decides where discretion is required

The Asset Capitalisation Agent operates at Decision Layer tiers 1 and 2. Rule-based steps run automatically with a full audit trail. AI-assisted steps provide suggestions with confidence scores. No step modifies the balance sheet without a documented decision basis.

In practice: when the agent processes a EUR 12,000 (USD 13,200) invoice for a laboratory scale, the capitalisation check runs rule-based. The asset class "technical plant and machinery" is assigned by rule. The useful life of ten years comes from the official depreciation table, source reference documented. Ancillary acquisition costs for calibration and installation are added to the cost basis - per the statutory cost definition.

For a tax audit, the result is a complete decision trail: why capitalised, how classified, which cost components, which useful life with which legal basis. This documentation is not produced after the fact for the auditor. It arises as a natural by-product of every single capitalisation decision.

That does not reduce the CFO's responsibility for the accuracy of the balance sheet. It gives them the foundation to exercise that responsibility on an informed basis - instead of trusting that nobody in accounts payable made an error.

--- Inventory Agent ---
> Generates inventory lists from fixed asset accounting, reconciles target and actual balances.

Between 10 and 30 percent of all entries in asset registers are so-called ghost assets - items that exist only on paper (source: CPCON Group, Fixed Asset Register Guide 2026). The annual physical inventory is meant to prevent exactly that. In practice, it often fails at the process level: manual counting across sites, spreadsheet-based reconciliation, weeks of follow-up. The Inventory Agent solves this problem by taking over the rule-based portion of the inventory entirely and stopping only where human judgement is required.

## One in three assets on the register exists only on paper

Ghost assets accumulate gradually. A printer is replaced, but the disposal is never posted. A machine moves to another site without a master data update. After five years without a physical check, the asset register has drifted far enough from reality that the inventory becomes a clean-up project. The consequences are measurable: inflated insurance premiums calculated on overstated book values, unnecessary depreciation on assets long since scrapped, and in the worst case a qualified audit opinion because the statutory auditor cannot accept the gap between register and reality.

## Manual inventory does not scale across locations

A mid-sized machinery manufacturer with four production sites and 8,000 assets knows the pattern: three weeks before the count date, coordination begins. Inventory teams are assigned, count sheets printed, scanners distributed. Each site counts at its own pace. Results come back by email - as spreadsheets in different formats. Central consolidation takes another two weeks. Shortfalls surface late, recounts delay the close. The result: the inventory consumes four to six weeks of labour, and doubts about completeness persist.

## The agent separates counting from valuing

The [Decision Layer](/en/decision-layer/) divides the asset inventory into two categories of decisions. Rule-based steps - generating the inventory list from the ERP, capturing the actual count, performing the target/actual reconciliation, identifying shortfalls, preparing correction postings - run automatically. The agent matches book balances against physical counts and produces difference lists by site, cost centre and asset class.

Two decisions remain with the human: Has an asset lost value? Should it be disposed of? These valuation questions require inspection and judgement. The agent supplies the decision basis - age, remaining useful life, condition from the last capture - but the sign-off rests with the specialist department. The process stays audit-compliant without tying up human capacity on counting work.

## RFID-based capture lifts accuracy above 95 percent

Manual inventory with barcode scanners typically achieves accuracy rates of 85 to 95 percent. RFID-based capture improves accuracy further and significantly shortens capture time. The Inventory Agent supports both technologies: where RFID tags are present, it captures the actual balance of a room in seconds rather than hours. Where only barcodes are available, it orchestrates the manual capture with site-specific lists and real-time progress tracking. The RFID infrastructure investment pays back in practice within a few years - not only through faster inventory, but also through better asset location tracking in daily operations.

## Correction postings are ready on inventory day

The real goal of the inventory is not the count but a clean asset register. The Inventory Agent prepares correction postings as soon as a discrepancy is confirmed: disposal entries for missing assets, unscheduled depreciation for impaired assets, location corrections for relocated items. At the end stands an inventory report documenting the entire process - from the target list through the actual capture to the sign-off on every single correction. The statutory auditor receives not just a result but the complete decision trail. That accelerates the financial audit and reduces follow-up queries to the essentials.

--- Bank Reconciliation Agent ---
> Cross-jurisdictional cash reconciliation pipeline: US BAI2, EU CAMT.053 ISO 20022, SWIFT MT940 historical, Open Banking PSD2 real-time, SOX 404 evidence chain.

Cross-border cash reconciliation at a multinational does not run on one bank-statement format - it runs on several in parallel. A US-listed parent with European subsidiaries and UK operations receives BAI2 (the dominant US fixed-width format, used by every major US bank for ACH, wire, lockbox, and concentration-account reporting) for its US accounts, CAMT.053 (the EU ISO 20022 standard with structured remittance and counterparty data) for euro accounts, MT940 (the legacy SWIFT format with its 25-character /MREF/ field) for cross-border and historical relationships still on SWIFT MT, and BACS/CHAPS reporting from Pay.UK and the Bank of England for sterling accounts. Layer real-time Open Banking over the top - PSD2 XS2A in the EU, OBIE in the UK, and FDX in the US - and the cash position can be reconciled to a true intra-day balance every 15 minutes during business hours rather than waiting for T+1 statement delivery. Add the SOX 404 internal-controls regime with its bank-confirmation requirements under PCAOB AS 2310, the IFRS 9 and ASC 305 derecognition and classification rules, and the COSO 2013 substantive-procedure framework, and cash reconciliation becomes the most-tested and most-scrutinised process on the SOX 404 controls map.

## A cash-control weakness erodes 4-7% of share price, and IFRS 9 and ASC 305 errors compound the exposure

Cash is the most-tested balance-sheet line under PCAOB AS 1105 because it carries low inherent risk - it is either there or it is not - but high fraud-vulnerability, since it is the asset most easily misappropriated. PCAOB inspection findings consistently cite cash-reconciliation weaknesses among the more frequent SOX 404 deficiencies. A material-weakness disclosure on cash controls typically erodes 4-7% of share price in the trading week after the 10-K filing; for a Russell-3000 mid-cap with a USD 1.2B market cap, a 5% impact is USD 60M of shareholder value destroyed by a control that an automated platform and documented review would have caught. The PCAOB AS 2310 update on bank confirmations, effective for fiscal years beginning on or after June 15, 2025, raised the bar further: positive confirmation is now mandatory for material balances with auditor-direct electronic delivery.

IFRS 9 and ASC 305 errors compound the exposure. Derecognition under IFRS 9 ties to the transfer of economic substance, so posting at the wrong moment misstates the close cash position by the size of the pending-versus-cleared population. Errors in the ASC 305-10 cash-equivalents classification (the 90-day original-maturity criterion) misclassify investment positions as cash. A Big-4 qualification on the cash balance draws SEC enforcement letters and FRC, FCA, or ECB inspections, and the CFO certification under SOX 302 puts personal liability on the line for the accuracy of the cash position.

## The international cash reconciliation pipeline runs 16 deterministic steps across five formats

Domestic single-bank cash reconciliation can be modelled in 7-8 steps. International multi-format, multi-bank reconciliation cannot. The Agent splits the pipeline into 16 steps because every transaction has to be checked at each stage: the source format is identified and validated against its own schema, balance continuity is verified across the statement chain, and the intra-day position is cross-checked through Open Banking. Transactions are then matched against the AR/AP subledger by ISO 20022 EndToEndIdentification or invoice number, with fuzzy matching for partial payments and consolidated transfers. Bank fees are mapped to the correct GL account, interest is classified by signed amount and account type, duplicates are detected against 90-day GL history, foreign currency is translated under IAS 21 and ASC 830, and intercompany sweeps are eliminated per cash-pooling structure. Unassignable items escalate to a clerk with structured context, material balances get a PCAOB AS 2310 bank confirmation, and the cycle ends with the monthly close consolidation and the audit-evidence packet.

A concrete scenario: a SEC-listed mid-cap with USD 1.2B revenue, EU operations across Germany, France, and the Netherlands plus the UK, running daily reconciliation across 12 bank accounts in 3 currencies at 6 banks. On a typical day the Agent ingests 12 statement files (5 BAI2, 4 CAMT.053, 1 MT940, 2 BACS/CHAPS) and parses each against its schema with zero errors. It cross-checks intra-day positions through PSD2 XS2A on EU accounts, OBIE on UK accounts, and FDX on US accounts with no mismatches. Exact matching clears 1,540 of 1,800 transactions (85.5%); fuzzy matching clears 198 of the residual 260 (76% of that population, total auto-clear 96.5%). It maps 84 bank-fee transactions to expense GL across 12 categories, classifies 23 interest transactions to credit and debit GL, finds no duplicate-payment patterns against 90-day history, translates 380 EUR and GBP transactions to USD at ECB and Bank of England period-end rates (posting an FX gain of USD 12,400), and eliminates 14 intercompany sweeps totalling USD 8.4M against the consolidated position. It escalates 62 unassignable items (3.5%) to the cash-application clerk with full counterparty, amount-range, and similar-transaction context, and packages the evidence chain for SOX 404 and PCAOB AS 2310 inspection.

In the [Decision Layer](/en/decision-layer/), 14 of the 16 steps are rule-based (R), one is an LLM suggestion (A) for fuzzy matching with confidence scoring and an auto-clear threshold, and one is human (H) for unassignable-item disposition. No generative AI touches any posting decision, derecognition trigger, or fee classification. The LLM stage works only on partial-payment matching, where pattern recognition adds genuine value over rigid rules, and even then it never posts to the GL without either an auto-clear at high confidence or a human override.

## Open Banking real-time cross-check kills the T+1 reconciliation surprise

The classical T+1 statement-only reconciliation pattern accumulates surprise. A duplicate debit, a misrouted direct debit, an incoming wire from an unfamiliar counterparty - all of it stays invisible until the next-day BAI2 or CAMT.053 file arrives, and by then the cash position on the balance sheet is already wrong by the size of the unreconciled population. Open Banking inverts the timing. Under PSD2 XS2A in the EU, OBIE in the UK, and FDX in the US, the Agent reads intra-day balance and transaction data over OAuth 2.0 access tokens every 15 minutes during business hours, cross-checked against the start-of-day intra-day report where the bank delivers one and against the prior end-of-day balance plus expected payment-run releases. Discrepancies surface in real time, not at T+1. The Agent flags any unexpected balance change to treasury for investigation before the position flows downstream into cash forecasting, and reconciliation confidence at month-end close moves from a typical 96-97% on statements alone to above 98% once the Open Banking cross-check is applied.

## Bank confirmation under PCAOB AS 2310 is the audit substantive procedure with highest evidentiary weight

Big-4 audits and SEC and FRC inspections focus heavily on the bank-confirmation evidence chain. PCAOB AS 2310 (effective for fiscal years beginning on or after June 15, 2025) requires positive confirmation for material balances: the auditor asks the bank to confirm the balance, signed authorities, outstanding loans, collateral, and lines of credit at a specific date, and the bank responds directly to the auditor without client intermediation. The 2025 update sharpened the focus on auditor-direct electronic confirmations through platforms such as Confirmation.com and Capitalent, so paper is now the exception. AICPA AU-C 505 applies to US private-company audits and ISA UK 505 to UK statutory audits. The Agent prepares the request packets per standard and tracks non-responses for follow-up at 14 and 28 days, typically cutting cash substantive-testing hours by 40-60% versus the manual paper cycle while raising the response rate from a typical 70-80% on paper to 92-97% electronically.

## Integration ecosystem: SAP, Oracle, and Workday cash management alongside BlackLine, HighRadius, and Trintech

The Agent integrates natively with the major international ERPs. On [SAP S/4HANA](https://www.sap.com/products/erp/s4hana.html) it uses Cash Application, Bank Communication Management, and Cash Management with intra-day position monitoring; on [Oracle Fusion Cloud Financials](https://www.oracle.com/erp/financials/) the Cash Management autoreconciliation engine and bank-statement processing; on [Workday Financial Management](https://www.workday.com/en-us/products/financial-management/) Cash Management with multi-bank consolidation and book-to-bank matching. It also covers Microsoft Dynamics 365 Finance (cash and bank management, reconciliation worksheet, ISO 20022 electronic reporting), Oracle NetSuite SuiteCloud Bank Reconciliation, and Sage Intacct Cash Management. For high-volume, multi-entity reconciliation it works with [BlackLine](https://www.blackline.com/) Account Reconciliations and Transaction Matching, [HighRadius](https://www.highradius.com/) Autonomous Treasury, and [Trintech](https://www.trintech.com/) Cadency and Adra Suite. For a multi-bank cash-management hub it connects to [Kyriba](https://www.kyriba.com/) Cash and Liquidity Management, FIS Quantum, GTreasury, or ION Treasury with multi-format ingestion. Bank connectivity runs over SWIFT FIN and the MX migration, EBICS for German and EU corporate banking, SFTP-PGP or bank-direct API for US BAI2/BAI3 files, BACS and CHAPS reporting from Pay.UK and the Bank of England, and the Open Banking schemes for real time. Audit evidence exports to Deloitte ASM, PwC Halo, EY Helix, and KPMG Clara with PCAOB AS 1215-compliant metadata, and WORM archiving runs on Amazon S3 Object Lock, Azure Blob Immutable Storage, or Google Cloud Storage Bucket Lock, tagged by retention class per the applicable rules - all generated as deterministic templates with the audit-trail metadata SOX 404 evidence packs and PCAOB substantive testing need.

--- Budget Variance Agent ---
> FP&A budget variance with price-volume-mix-FX driver decomposition, closed-loop action items, SOX 404 ICFR audit trail. Anaplan, Workday Adaptive, Oracle EPM.

International FP&A budget variance analysis operates within an interlocking regulatory regime spanning six major frameworks: SEC Item 303 of Regulation S-K (the MD&A) with the PSLRA forward-looking-statements safe harbor for US-listed entities, UK FRC Strategic Report Guidance 2018 and Companies Act 2006 Section 414C for UK-listed companies, the ESMA Guidelines on Alternative Performance Measures (ESMA/2015/1415) for EU-listed entities, IAS 1, IAS 8, and IAS 36 for IFRS-reporting groups, ASC 270 and ASC 280 for US GAAP-reporting groups, and SEC Regulation G governing non-GAAP variance reconciliation. A public company operating across the UK, EU, and US must coordinate plan-versus-actual variance decomposition, root-cause attribution with budget-owner accountability, closed-loop action items, FX isolation under IAS 21 and ASC 830, reforecast-trigger detection feeding EPS guidance, and Big-4 substantive testing under PCAOB AS 2110 and ISA UK 540 - all with a full audit trail to support SOX 404, UK FRC Provision 29, and Audit Committee oversight.

## Five regulatory pressure points put variance analysis beyond a spreadsheet

SEC Item 303 of Regulation S-K mandates Management Discussion and Analysis covering period-over-period variance with quantitative analysis of contributing factors. The 2021 SEC amendments expanded variance attribution requirements with critical accounting estimates section. PSLRA Section 27A and Section 21E provide safe harbor for forward-looking statements - but selective disclosure under Reg FD prohibits sharing internal variance analysis with sell-side analysts ahead of Form 10-Q filing. SEC Division of Corporation Finance comment letters frequently target inconsistent variance attribution between MD&A narrative and reconciliation tables.

UK FRC Strategic Report Guidance 2018 and Companies Act 2006 Section 414C require UK-listed companies to provide a fair, balanced, and comprehensive analysis of business development, with variance commentary aligned with the audited financials. UK FCA Listing Rule 4.2.7 mandates a half-year Strategic Report with a variance narrative consistent with full-year disclosure. UK Corporate Governance Code Provision 29, effective 1 January 2026, introduces a board declaration of ICFR effectiveness for the FTSE 350, aligning UK practice with US SOX 404 and pulling budget-variance-analysis controls into the scope of board attestation.

ESMA APM Guidelines (ESMA/2015/1415) for EU-listed entities require non-GAAP/APM variance measures (constant currency growth, organic growth, adjusted EBITDA variance) to be defined, reconciled to IFRS, applied consistently over time, presented with no greater prominence than IFRS metrics, and compared with prior period. Notable enforcement: ESMA peer review 2020 found 47 percent of EU-listed companies non-compliant on APM consistency over time - frequently caused by variance attribution methodology drifting between periods.

An EPS-guidance miss, a non-GAAP restatement, a goodwill-impairment trigger under IAS 36 or ASC 350, and a Big-4 ICFR material-weakness disclosure rarely arrive alone, and together they typically trigger a securities class action under Section 10b-5 in the US or FSMA 2000 Section 90A in the UK. Notable cases include GE (2018-2020), where SEC accounting fraud and variance-attribution failures accompanied a USD 22 billion goodwill impairment and a PCAOB investigation; Carillion (2018), a four-firm audit failure with budget variance manipulation; Wells Fargo (2020), an SEC consent order with variance disclosure deficiencies; and Patisserie Valerie (2018), Grant Thornton ICFR failures with budget variance fraud.

## 15 deterministic decision points with two human escalations

The Agent processes budget variance analysis through a pipeline of 15 decision points: thirteen regulatory and methodological classifications, all deterministic or ML-pattern-matched, and two human escalations - strategic interpretation (a controller's judgement on signal versus noise, competitive context, and supplier negotiations) and reforecast-trigger judgement (CFO and Head of FP&A approval before any EPS-guidance revision under the PSLRA safe harbor). It ingests the budget baseline across the approved budget and rolling reforecast versions on the ASC 280 and IFRS 8 CODM segment view, then ingests actuals under IFRS and US GAAP with IAS 21 and ASC 830 multi-currency translation that isolates FX from operational variance. Materiality filtering combines quantitative per-segment thresholds with qualitative SAB 99 factors under PCAOB AS 2105. Volume, price, mix, FX, and timing variances are then computed deterministically under the IMA SMA 4D and ICAEW Tech 02/17 standard cost methodology, fully reconciled to the total revenue and cost variances.

Consider an international group: a US headquarters with UK and EU subsidiaries, USD 8 billion revenue, 35,000 employees, listed on the NYSE with a secondary LSE listing. At the Q3 2026 close, revenue came in at USD 2.04 billion against a USD 2.10 billion budget, a total variance of minus USD 60 million (-2.9 percent). The Agent decomposes it into a volume variance of minus USD 78 million (lower unit shipments in EMEA from channel destocking), a favourable price variance of USD 32 million (price realisation in the Americas), a mix variance of minus USD 12 million (a shift toward the lower-margin enterprise tier in cloud services), an FX variance of minus USD 18 million (EUR/USD weaker than the budget rate), and a favourable timing variance of USD 16 million (Q4 contracts pulled into Q3 under IFRS 15 over-time recognition). On accountability, the EMEA segment lead owns the volume variance with closed-loop action items, the Americas lead owns the favourable price surprise, and the cloud-services lead owns the mix variance with a margin-recovery plan. The volume variance flags an annualised impact of USD 312 million, above the 10 percent threshold, so the CFO and Head of FP&A approve an outlook revision that feeds the Financial Forecast Agent for an EPS-guidance update from $5.85-$6.15 to $5.65-$5.95 with PSLRA cautionary language.

## Driver decomposition into volume, price, mix, FX, and timing

The five-component decomposition is the heart of professional variance analysis under the IMA SMA 4D and ICAEW Tech 02/17 standard cost methodology. Volume variance isolates the effect of unit-quantity differences at budgeted prices, and price variance isolates per-unit-price differentials at actual quantities. Mix variance is the residual that appears when the actual product, customer, or channel composition shifts from the budget composition at constant total volume - it matters most for multi-product enterprises, where margin erosion can hide behind apparent revenue growth. FX variance is isolated using the IAS 21 and ASC 830 translation rules: the actual P&L is translated twice, first at the actual-period average rate and then at the budget rate, with the difference being FX and the remainder operational. Timing variance flags revenue-recognition cut-offs under IFRS 15 and ASC 606 - over-time versus point-in-time - distinguishing genuine performance variance from period-end accruals.

Hackett Group's 2024 FP&A benchmarks show a best-in-class variance-commentary cycle of 2.5 working days against a typical five, achieved through deterministic decomposition combined with ML root-cause attribution. The AFP 2025 survey found that 67 percent of S&P 500 and FTSE 350 companies implement five-component decomposition, while 23 percent rely on simpler total-variance reporting that fails Big-4 substantive testing under PCAOB AS 2110 and ISA UK 540 for lack of causal evidence. The Agent supports both granularities but defaults to the five-component decomposition with a full reconciliation audit trail.

## Closed-loop action items, budget-owner accountability, and MAPE tracking

Variance reporting without closed-loop action items is documentation theatre - the observation changes nothing in future periods. ICAEW Tech 02/17 and the IMA Statement on Management Accounting require accountability mapping aligned with the CODM structure: each significant variance is assigned to the responsible cost-centre manager, segment lead, or regional CFO, with a hypothesis, due date, expected resolution, and tracking link in the EPM workflow. The Agent drafts the action items through ML pattern matching against historical variance-action-resolution chains, but action ownership stays a human responsibility under SOX 404 ICFR.

Tracking MAPE (Mean Absolute Percentage Error) and bias at segment, account, and budget-owner level over a rolling 12 quarters surfaces systematic accuracy issues. The AFP FP&A standard thresholds are under 5 percent next-quarter, 10 percent at 12 months, and 20 percent at 24 months. Bias above 3 percent flags systematic optimism (budget owners sandbagging) or pessimism (excessive conservatism) and triggers a driver-tree review and assumption recalibration. Hackett Group benchmarks put the median 12-month MAPE at S&P 500 and FTSE 350 entities at 8.4 percent, with best-in-class at 4.2 percent achieved through a driver-based methodology with a rolling reforecast.

## Integration with Anaplan, Workday Adaptive, Oracle EPM, OneStream, and SAP Analytics, plus Big-4 substantive testing

The Agent integrates by API with all the major EPM platforms: [Anaplan Connected Planning](https://www.anaplan.com/) with PlanIQ ML (the Hyperblock engine, a default at S&P 500 and FTSE 100 companies), [Workday Adaptive Planning](https://www.workday.com/en-us/products/adaptive-planning/overview.html), [Oracle EPM Cloud](https://www.oracle.com/performance-management/), [OneStream Software](https://www.onestream.com/), SAP Analytics Cloud Planning with SAP S/4HANA Group Reporting, IBM Planning Analytics with Cognos Controller, Vena Solutions, Pigment, Cube Software, Mosaic.tech, Tagetik, Jedox, Board International, Prophix, and Longview Solutions. ERP integration runs over SAP S/4HANA RFC/OData, Oracle Cloud REST, Workday SOAP/REST, Microsoft Dynamics 365 Finance Dataverse, and NetSuite SuiteScript. Variance pattern matching uses a time-series database (TimescaleDB or InfluxDB) and an ML stack of TensorFlow, scikit-learn, and Prophet retrained monthly. Big-4 substantive testing exports directly to Deloitte ASM, PwC Halo, EY Helix, and KPMG Clara, carrying the PCAOB AS 2110, ISA UK 540, and AICPA AU-C 540 audit-trail metadata in WORM immutable storage with eIDAS QSEAL and QWAC timestamps and the SOX 404 and UK FRC Provision 29 evidence repository.

--- Cash Application Agent ---
> Reads bank statements (CAMT.053, MT940), assigns payments to debtors and open invoices.

Between an incoming payment and a cleared receivable sit hours of manual assignment work in many companies. Clerks match bank statements against open items, parse payment references, identify deviating payers and clarify differences. For organisations with several hundred incoming payments per day, this process ties up specialists whose skills should really be used for disputed cases and customer relationships. At the same time, every hour without assignment delays the liquidity impact of the payment - and worsens Days Sales Outstanding.

## Every day without assignment worsens working capital

The cross-industry average DSO sits at 57 days, even though most companies agree on 28-day payment terms (source: Kapittx, 2025). That gap of almost 30 days is not only the fault of late-paying customers. A significant share comes from internal delays: payments that have arrived but are not yet assigned, and therefore not yet recognised as a clearance of receivables.

For a company with EUR 50 million (USD 54 million) in annual revenue, every day of DSO reduction releases roughly EUR 137,000 (USD 148,000) in working capital. Cash application is therefore not an administrative side-process but a direct lever on balance sheet quality.

## 80 percent of assignments follow a fixed rule set

Manual matching suggests a complexity that does not exist in most cases. An analysis of typical incoming payments shows: around 80 percent can be uniquely assigned using the invoice number in the payment reference, the amount and customer master data. Companies with automated cash application reach match accuracies of 95 to 98 percent and cut manual processing time by 80 to 90 percent (Emagia, 2025).

The important point: this high rate is not the result of AI in the narrow sense. It is based on deterministic rules - parse the bank statement, match the reference, check the amount, generate the journal entry. The rule engine produces reproducible, auditable results. That is precisely what makes the process automatable in a way that satisfies audit-compliant bookkeeping standards.

## Deviating payers and partial payments need a layered decision model

The remaining 20 percent are why full automation fails without a decision architecture. Typical scenarios: a corporate group pays through a central payment office whose name does not match the debtor. A customer settles three invoices in one transfer but deducts early payment discount on one invoice even though the deadline has passed. Or a payment is EUR 47 short of the invoice amount - rounding, justified deduction, or error?

The [Decision Layer](/en/decision-layer/) handles these cases through escalation stages. Stage 1 - the rule engine - solves exact matching: CAMT.053 parsing, invoice number matching, early payment discount deadline checks against contract data. Stage 2 - fuzzy matching - kicks in for deviating payers, combining bank details from master data, historical payment patterns and name similarity. Only when both stages fail to produce a unique match does the agent escalate to a clerk - with all the context already gathered to support the decision.

## The clerk becomes a clarification specialist

In the manual world, a clerk spends most of the day on routine assignments that require no specialist judgement. The real expertise - assessing customer history, interpreting payment behaviour, making commercial decisions on differences - is squeezed out because the mass of standard cases dominates the day.

After introducing the Cash Application Agent, this ratio flips. The agent handles the rule-based assignments and prepares the disputed cases so that the clerk is immediately ready to decide: which debtors are candidates, which open items match the amount, which matching methods were attempted, why none of them worked. The role shifts from assignment clerk to clarification specialist.

For the company this creates a double effect. Throughput time from incoming payment to cleared receivable drops from hours to minutes for standard cases. And the clarification rate on problem cases rises, because specialists can focus their time on the cases that genuinely need human judgement.

--- Cash Forecasting Agent ---
> A 13-week rolling cash forecast fed by real-time Open Banking, with stress scenarios and covenant alerts under IAS 7 and ASC 230.

International cash flow forecasting operates across an interlocking regulatory regime of six major frameworks: IAS 7 for IFRS-reporting entities, ASC 230 for US GAAP-reporting entities (with key differences in interest and dividend classification), the AFP 13-week rolling standard adopted globally for tactical liquidity management, going concern under AICPA AU-C 570 and ISA UK 570 with its 12-month forward look-through, climate-related cash flow disclosures under EU CSRD ESRS E1, UK SDR, and UK TCFD using the NGFS Phase IV scenarios, and SOX 404 and UK FRC Provision 29 ICFR controls evidence for Big-4 substantive testing under PCAOB AS 2110 and ISA UK 540. A public company operating across the UK, EU, and US must coordinate a deterministic dual-standard forecast across the 13-week tactical, 52-week operational, and 5-year strategic horizons, run climate stress scenarios and DSCR/ICR covenant tracking, support Big-4 substantive testing, and produce the Board memo and Investor Relations briefing.

## Five cumulative pain points: SOX 404, going concern, covenant breach, MAC triggers, and a Big-4 qualification

SOX Section 404 requires the CEO and CFO to certify ICFR effectiveness, including liquidity controls, each quarter in the 10-Q and each year in the 10-K, with personal liability for material misstatements under Sections 302 and 906. A material-weakness disclosure typically erodes 4-7% of market capitalisation in the first trading week, and PCAOB inspection findings from 2020 to 2024 place ICFR liquidity among the top three audit areas with deficiencies. Going concern under AICPA AU-C 570, ISA UK 570, and IAS 1.25-26 requires management and the auditor to evaluate a 12-month forward look-through, and crossing the substantial-doubt threshold modifies the auditor's opinion (emphasis-of-matter, qualified, or adverse). Notable cases include Wirecard (2020, an EY qualified opinion before the fraud surfaced), Carillion (2018, KPMG ICFR failures), General Electric (2018, a PCAOB investigation), and SVB (2023, KPMG ICFR liquidity controls).

UK FRC Provision 29, effective 1 January 2026, requires a FTSE 350 board declaration of ICFR effectiveness in the Annual Report, aligning the UK with US SOX 404. EU CSRD ESRS E1, UK SDR, and UK TCFD require disclosure of climate-related cash flow impacts under the NGFS Phase IV scenarios (Net Zero 2050, Disorderly Transition, Hot House World). A covenant breach below 1.2x DSCR or 2.5x ICR triggers technical default, acceleration clauses, Material Adverse Change provisions, and cross-default clauses. A Big-4 qualification on going concern erodes investor confidence, bond covenant ratings, insurance and reinsurance availability, and working-capital facilities.

## 15 deterministic decision points with three human escalations

The Agent processes cash flow forecasting through a pipeline of 15 decision points: twelve regulatory classifications, one LLM-assisted ML forecast for the 52-week and 5-year horizons, one anomaly detection step, and three human escalations for the NGFS Phase IV climate scenarios, the AICPA AU-C 570 going-concern call, and the multi-shock stress combinations. Open Banking aggregation over PSD2 XS2A in the EU and UK and FDX 6.0 in the US covers all bank accounts in real time with eIDAS QSEAL and QWAC certificates. The cash flow statement is classified under both IAS 7 and ASC 230 with proper interest and dividend treatment, and the operating, investing, and financing activities follow the same dual standard (IAS 7 permits either treatment for interest paid, while ASC 230 always treats it as operating). The 13-week rolling forecast follows the AFP standard at weekly granularity, the 52-week uses Prophet with seasonality, and the 5-year uses System Dynamics with scenarios. The DSCR and ICR engine reads the bank covenant clauses and alerts four weeks ahead.

Consider an international group with US, UK, and EU subsidiaries, USD 5 billion revenue, 50,000 employees, and 12 banks across 8 countries. The Agent aggregates all 12 accounts in real time over PSD2 and FDX (lag of 30 seconds to 2 minutes) and updates the 13-week, 52-week, and 5-year forecasts weekly. The next 13-week DSCR is projected at 1.42x against a Citi covenant of 1.30x, a margin of 9 percent, with an ICR of 3.4x against a 3.0x covenant, a margin of 13 percent. The NGFS Phase IV Disorderly Transition stress test reduces DSCR to 1.21x in weeks 11-13, alerting the CFO and Board and escalating to the Audit Committee. On going concern, cash and facilities cover 14 months of operations, above the 12-month threshold. Backtested weekly accuracy is a 4-week MAPE of 7.1 percent and a 13-week MAPE of 16.3 percent, both within the AFP thresholds.

## Real-time Open Banking across PSD2 and FDX with multi-jurisdiction support

The PSD2 RTS XS2A standard (Berlin Group NextGenPSD2 and the UK Open Banking Standard) gives standardised access to EU and UK bank accounts with eIDAS QSEAL and QWAC certificates, and the FDX 6.0 standard, effective 2024, provides US Open Banking with similar certificate-based authentication. The Agent aggregates all bank accounts into a single consolidated view across the UK, EU, and US. Legacy formats - SWIFT MT940, CAMT.053, BAI2, BAI3, Spain's AEB Norma 43, and Poland's ELIXIR-O - are retained as a backup for accounts not yet enabled for Open Banking. ML anomaly detection (Isolation Forest, LSTM Autoencoder, DBSCAN, Bollinger Bands) runs on international features such as FX rates, interest rates, inflation, commodity prices, and sector indices. An anomaly score above three standard deviations triggers a drill-down and hands off to the Fraud Detection Agent for AML under the BSA, UK MLR 2017, and EU 6AMLD.

## Integration with SAP Treasury, Oracle Treasury Cloud, Kyriba, and GTreasury, plus Big-4 substantive testing

The Agent integrates by API with the major treasury management systems: [SAP S/4HANA Treasury](https://www.sap.com/products/treasury-management.html) with SAP Cash Management (a default at DAX 40, FTSE 350, and S&P 500 companies), Oracle Treasury Cloud with Oracle Cash Management, [Kyriba Treasury](https://www.kyriba.com/) with Kyriba Cash Forecasting, [GTreasury](https://gtreasury.com/) with GTreasury ClearConnect, Coupa Treasury, FIS Quantum, ION Treasury with the ION Wallstreet Suite, Workday Adaptive Planning with Workday Treasury, and BlackLine Cash Management. It reads Open Banking over PSD2 XS2A and FDX 6.0, with SWIFT MT940, CAMT.053, BAI2, and BAI3 as backup. Forecasting runs on a time-series database (TimescaleDB or InfluxDB) and an ML stack of TensorFlow, Prophet, ARIMA, the LSTM Autoencoder, and VAR. Big-4 substantive testing exports directly to Deloitte ASM, PwC Halo, EY Helix, and KPMG Clara, carrying the PCAOB AS 1215 and ISA UK 240 and 540 audit-trail metadata in WORM immutable storage with eIDAS QSEAL and QWAC timestamps and the SOX 404 and UK FRC Provision 29 evidence repository.

--- Close Checklist Agent ---
> Orchestrates the month-end close as a structured workflow with task dependencies, deadline monitoring, completeness check and automatic protocol creation.

The month-end close is not a posting problem. Every individual posting, reconciliation and consolidation is manageable on its own. What stretches the close to six, eight or ten working days is the coordination between these steps - who is waiting for whom, which task blocks the next, and where is a delay that nobody has noticed yet. The Close Checklist Agent solves exactly this orchestration problem. Rule-based, without its own posting logic, without AI.

## Half of all finance teams need more than a week for the close

The figures are clear: APQC puts the cross-industry median for the monthly close at 6.4 days. A large share of finance teams regularly require more than six working days, and only a minority complete the close in three days or fewer.

The cause rarely lies in the complexity of individual tasks. Most teams still use spreadsheet checklists during the close, where dependencies between tasks are not mapped. A forgotten intercompany reconciliation blocks the consolidation. A late accrual holds up the completeness check. The delay only becomes visible when the deadline has already passed.

## Orchestration beats individual automation

Many organisations automate individual close steps - reconciliations, journal entries, provisions. Each step becomes faster. Yet the overall process barely shortens, because between the automated islands lie manual handovers, unclear sequences and waiting times without escalation.

CFO surveys confirm this finding: in 2025, the focus shifted from isolated automation to process orchestration. Companies that introduced integrated steering report better working capital, reduced risk and faster decisions (source: Esker, Rise of the Strategic CFO, 2025). The decisive lever lies not in faster posting but in eliminating the dead time between postings.

For the month-end close, the practical implication is straightforward: as long as no system knows and enforces the task sequence, the close remains as slow as its slowest manual handover.

## Ten rule-based decisions control the entire workflow

The [Decision Layer](/en/decision-layer/) decomposes close orchestration into ten decision steps - all at tier R (rule engine), no AI involvement. A concrete scenario makes the logic tangible.

Friday afternoon, day three of the close. The agent checks the dependency chain: the intercompany reconciliation for entity DE03 is still "open". The downstream consolidation cannot start. The rule engine detects the blockage automatically, compares the planned completion date against the current date and classifies the task as overdue. The configured escalation matrix fires: first a notification to the owner, then after four hours without a status change to the Head of Accounting.

In parallel, the agent tracks the status of all other tasks. Completed steps release their dependent follow-on tasks. The completeness check at the end compares finished tasks against the configured mandatory list. If a step is missing, the close stays open - no exceptions, no manual override without a documented reason.

Crucially: the agent posts nothing, calculates nothing, values nothing. It controls only sequence and completeness. This clear boundary makes it robust and auditable.

## The close protocol arises as a by-product

Every close cycle produces a complete protocol - not as an additional documentation task but as an automatic result of the orchestration. Every status change, every escalation, every timestamp is recorded: who completed which task when, which dependencies were checked, where delays occurred.

For statutory auditors and internal governance, this protocol serves as evidence of an orderly closing process. No retrospective assembly of emails and spreadsheets. No reconstruction from memory. The close process documents itself while it runs.

Companies aiming to move from a six-day close to two or three days do not need faster accountants. They need a system that knows the dependencies between 30, 50 or 80 close tasks, detects blockages in real time and involves the responsible parties without delay. That is exactly what rule-based orchestration in the Decision Layer delivers.

--- Consolidation Agent ---
> Group consolidation across IFRS-vs-USGAAP: IFRS 10 control, ASC 810 VIE, IAS 21 FX translation, IAS 36 goodwill impairment, equity method pickup, SEC 10-K ready.

International group consolidation operates within an interlocking regulatory regime of six major frameworks: the IFRS 10, 11, and 12 control and joint-arrangements model, the ASC 810 dual voting-interest and VIE model, the UK Companies Act 2006 Sections 399-408 group-accounts requirements with the FRS 102 Section 9 alternative, goodwill impairment testing under IAS 36 and ASC 350 with cash-generating-unit identification, internal control over financial reporting under US SOX 404 and UK FRC Provision 29, and the OECD Pillar Two GloBE Rules effective 2024 for groups exceeding EUR 750 million in consolidated revenue. A multinational operating across the UK, EU, and US must coordinate the IFRS 10 control assessment, reporting-package validation, chart-of-accounts mapping, FX translation under IAS 21 and ASC 830, capital consolidation with goodwill recognition under ASC 805 and IFRS 3, intercompany debt, revenue, and expense eliminations, deferred tax on unrealised intra-group profit under IAS 12 and ASC 740, the IAS 28 equity-method pickup, NCI computation under IFRS 10.B94 and ASC 810-10-45-15, goodwill impairment under IAS 36 and ASC 350, the multi-GAAP IFRS-versus-US-GAAP bridge, ESEF iXBRL tagging under Regulation 2018/815, and a complete PCAOB AS 2110 and AU-C 600 group-audit substantive-testing audit trail.

## Six regulatory pressure points put consolidation beyond a spreadsheet

IFRS 10 unified the control concept across IFRS reporters with a three-element test: power over the investee through substantive rights, exposure to variable returns, and the ability to use that power to affect those returns. ASC 810 keeps a dual model - a voting-interest test with an over-50-percent ownership presumption, and a Variable Interest Entity test with a primary-beneficiary determination under ASC 810-10-25-38 combining quantitative and qualitative analysis. De facto control, kick-out rights held by non-controlling parties, protective rights, and silos within structured entities all require careful judgement. Notable control-assessment failures include Lehman Brothers Repo 105 before IFRS 10, the timing of Carillion's SPV consolidation in 2018, which contributed to GBP 7 billion in taxpayer losses, and Wirecard's Asian operations in 2020, which contributed to a EUR 1.9 billion fraud loss.

UK Companies Act 2006 Sections 399-408 require parent companies to prepare group accounts unless the Section 400 small-group exemption applies (turnover under GBP 36 million, balance sheet under GBP 18 million, and fewer than 250 employees), the Section 401 EEA-parent exemption, or the Section 402 medium-sized exemption. The UK framework choice spans IFRS as adopted by the UK (the post-Brexit divergence path), FRS 102 Section 9 for non-IFRS preparers, the FRS 101 Reduced Disclosure Framework, and the FRS 105 Micro-entities Regime. FRS 102 Section 19 business combinations require goodwill amortisation over its useful life (presumed not to exceed 10 years, amended in 2024). UK FRC Provision 29, effective 1 January 2026, introduces a board declaration of ICFR effectiveness for the FTSE 350, parallel to US SOX 404.

Goodwill impairment testing under IAS 36 and ASC 350 is the highest-frequency restatement and SEC, FRC, and ESMA enforcement area. Under IAS 36 the recoverable amount is the higher of fair value less costs of disposal and value in use, and computing value in use requires a multi-period DCF with a terminal value, a growth rate consistent with long-run GDP, and a WACC derived from CAPM. The ASC 350 single-step test (post ASU 2017-04) compares the reporting unit's carrying amount to its fair value, capping impairment at the goodwill carrying amount. Cumulative goodwill impairments across the S&P 500, FTSE 350, and EuroStoxx 600 from 2018 to 2024 exceed USD 1.8 trillion. Notable impairments include Verizon-Yahoo (USD 4.6 billion, 2017), Kraft Heinz (USD 15 billion, 2019), AT&T-DirecTV (USD 18 billion, 2020), and GE Power (USD 22 billion, 2018).

## 15 deterministic decision points with five ML-assisted escalations

The Agent processes group consolidation through 15 decision points: ten deterministic operations - reporting-package validation, chart-of-accounts mapping, FX translation, capital consolidation, debt elimination, revenue and expense elimination, equity-method pickup, NCI computation, ESEF iXBRL tagging, and audit-trail generation - plus five ML-assisted escalations for IFRS 10 control assessment, functional-currency determination under IAS 21 and ASC 830, unrealised intercompany inventory-profit valuation cases, goodwill impairment under IAS 36 and ASC 350 with CGU identification, and the multi-GAAP IFRS-versus-US-GAAP bridge. FX translation runs deterministically under IAS 21.39 - the closing rate for the balance sheet, the average rate for the P&L, and the historical rate for equity - with the CTA isolated in OCI under IAS 21.32 and ASC 830-30-45-12.

Consider an international industrial group: a US headquarters with UK and EU subsidiaries, USD 18 billion consolidated revenue, 47 legal entities across 24 jurisdictions, and dual IFRS and US GAAP reporting. At the Q4 2026 fiscal year close, the IFRS 10 control assessment covers 47 in-scope entities, 6 equity-method investees, 3 joint ventures, and 2 structured entities (one consolidated as a silo, one excluded after a kick-out-rights review). Reporting-package validation finishes in 2 days against a typical 7, with 6 packages flagged on the day of receipt. The FX translation isolates a CTA of USD 247 million net debit in OCI. The eliminations remove USD 2.8 billion of gross intercompany revenue and expense, USD 1.2 billion of reciprocal AR/AP, and USD 187 million of unrealised inventory profit, deferred with a USD 44 million deferred-tax asset under IAS 12 and ASC 740. The equity-method pickup adds USD 89 million of associate net income under IAS 28, and NCI totals USD 312 million across 11 partially owned entities. Of 14 CGUs tested for goodwill impairment, 12 pass the Step 0 qualitative test with headroom above 30 percent and 2 require sensitivity analysis, one of which indicates a potential USD 67 million impairment pending Big-4 valuation-specialist review. The multi-GAAP bridge posts 8 quarterly entries totalling a USD 142 million net difference. ESEF iXBRL tagging finishes in 5 days on Workiva Wdesk with the ESMA taxonomy. The total close cycle is 9 working days against a typical 14.

## IFRS 10 control assessment with three-element test and structured entity analysis

The IFRS 10 control assessment is the foundation of consolidation scope and the highest-judgement decision in the close cycle. The Agent applies the three-element test deterministically where possible: power over the investee through substantive rights, exposure to variable returns, and the ability to use that power to affect those returns. Structured entities require additional analysis per IFRS 10.B41-B53 covering purpose and design, returns variability, related-party considerations, and silos. The ASC 810-10-25-38 VIE primary-beneficiary determination follows parallel logic - the party with power to direct the most significant activities, together with the obligation to absorb losses or the right to receive benefits. The Agent maintains a control checklist per material entity with annual reassessment triggers, and the final control conclusion stays with the group accountant and audit committee under PCAOB AS 2110.

## Capital consolidation with ASC 805/IFRS 3 acquisition accounting and measurement period

Capital consolidation eliminates the parent's investment carrying value against subsidiary equity at the acquisition date, recognising goodwill or a bargain purchase under ASC 805-30 and IFRS 3.32. The Agent maintains a purchase-accounting database with acquisition-date balance sheets, fair-value adjustments, contingent-consideration measurement, and intangible-asset recognition and useful-life determination. Measurement-period adjustments under ASC 805-10-25-13 (up to 12 months) are tracked separately, with retroactive restatement of the comparative period. Notable acquisition-accounting reviews include the SEC pre-filing review of the USD 75.4 billion Microsoft-Activision deal in 2023 and the USD 63 billion Bayer-Monsanto combination with its subsequent litigation reserve. Big-4 PCAOB AS 2110 substantive testing requires capital-consolidation evidence with a clear acquisition-accounting reconciliation under [Decision Layer](/en/decision-layer/) governance.

## IAS 36 goodwill impairment testing with CGU identification and DCF assumption tracking

Goodwill impairment testing under IAS 36 and ASC 350 is the highest-stakes consolidation activity. The Agent runs the annual impairment test, and indicator-driven tests under IAS 36.12, at the cash-generating-unit level - typically aligned with operating segments under IFRS 8 and ASC 280 or one level below. Under IAS 36 the recoverable amount is the higher of fair value less costs of disposal and value in use, and computing value in use requires a multi-period DCF with a terminal value, a growth rate consistent with long-run GDP, and a WACC derived from CAPM. The ASC 350 Step 0 qualitative test is optional; the Step 1 quantitative test (post ASU 2017-04) compares carrying amount to fair value, capping impairment at the goodwill carrying amount. SEC, FRC, and ESMA pre-filing review focuses on the WACC derivation and beta selection, the terminal growth rate against long-run GDP, the management forecast track record, the sensitivity-analysis disclosure under IAS 36.134-137, and the stability of CGU identification. Big-4 valuation specialists are routinely engaged, at 80-200 hours and a USD 30,000 to USD 200,000 fee per CGU.

## Integration with SAP S/4HANA Group Reporting, OneStream, Oracle FCCS, IBM Cognos Controller and Workiva

The Agent integrates by API with the major consolidation and financial-reporting platforms: [SAP S/4HANA Group Reporting](https://www.sap.com/products/financial-management/group-reporting.html) (a DAX 40 and EuroStoxx 50 default with native Universal Journal integration), [OneStream Software](https://www.onestream.com/) (a Unified Platform with native consolidation, intercompany eliminations, and Pillar Two), [Oracle Financial Consolidation and Close (FCCS)](https://www.oracle.com/erp/financial-consolidation-close-cloud/) with Hyperion Financial Management and the Oracle Tax Reporting Cloud, [IBM Cognos Controller](https://www.ibm.com/products/cognos-controller) (a FTSE 100 installed base) with IBM Planning Analytics, [Wolters Kluwer CCH Tagetik](https://www.wolterskluwer.com/en/solutions/cch-tagetik) (a mid-cap European default covering Pillar Two and ESEF tagging), LucaNet (the DACH mid-cap default), [Workiva Wdesk](https://www.workiva.com/) (the S&P 500 and FTSE 350 standard for financial reporting, ESEF iXBRL tagging, SOX 404 evidence, and the 10-K/10-Q EDGAR workflow), and Anaplan, Vena, Board International, Trintech Cadency, and BlackLine. ERP integration runs over SAP S/4HANA RFC/OData, Oracle Cloud REST, Workday SOAP/REST, Microsoft D365 Dataverse, and NetSuite SuiteScript. ESEF tagging uses Workiva Wdesk, IRIS Carbon, ParsePort, and CoreFiling Seahorse with the ESMA, IFRS Foundation, and US GAAP FASB taxonomies. Big-4 substantive testing exports directly to Deloitte ASM, PwC Halo, EY Helix, and KPMG Clara with the PCAOB AS 2110, AICPA AU-C 600, and ISA 600 group-audit trail in WORM immutable storage, alongside eIDAS QSEAL timestamps and the SOX 404 and UK FRC Provision 29 evidence repository.

--- Contract Compliance Agent ---
> Screens suppliers and contracts for anti-bribery, sanctions and export-control risk, with CSDDD value-chain due diligence in one deterministic pipeline.

International contract compliance runs on several cross-jurisdictional regimes at once: the US Foreign Corrupt Practices Act 1977 with the DOJ Corporate Enforcement Policy and the ECCP March 2023 five-pillar evaluation, the UK Bribery Act 2010 with its Section 7 corporate-failure offence and the UK MoJ six-principle adequate-procedures defence, the EU CSRD ESRS G1 Business Conduct standard and the CSDDD chain-of-activities mapping, OFAC sanctions screening with 50% Rule entity tracing, ITAR and EAR dual-use export controls with deemed-export analysis, and SOX 404 contract-cycle internal controls under PCAOB AS 2401. A US-headquartered multinational with EU subsidiaries, a UK Main Market entity with FCA SMCR accountability, and a federal contractor under FAR Part 3 must run parallel determinations across all of these while applying seven judgement-intensive decisions: scope identification with chain-of-activities classification, third-party-intermediary risk classification (intermediaries feature in 90 percent of FCPA enforcement), ITAR and EAR export-control determination with deemed-export analysis, modern-slavery and human-rights due diligence covering upstream and downstream partners, side-letter modification assessment under the PCAOB AS 2401 fraud-risk presumption, and finalising the DOJ ECCP, UKBA Section 7, and ISO 37001 evidence package. Over the top sit OFAC strict-liability enforcement with maximum civil penalties of USD 368,136 per violation, SFO Section 7 prosecutions running to hundreds of millions in DPAs, and CSDDD civil liability with administrative fines up to 5 percent of net worldwide turnover.

## DOJ FCPA enforcement, SFO Section 7 prosecutions, and CSDDD civil liability cascade into a Big-4 audit qualification

DOJ FCPA settlements averaged over USD 100 million per corporate resolution in the FCPA Year-In-Review 2024 reporting, with 90 percent of cases involving third-party intermediaries acting for the company. SFO UK Bribery Act enforcement produced the Rolls-Royce DPA of GBP 671 million in 2017, the Airbus DPA of GBP 991 million globally in 2020, and the Glencore DPA of GBP 280 million in 2022. The EU CSDDD, effective 25 July 2024, imposes civil liability for damages and administrative fines up to 5 percent of net worldwide turnover, phased in by company size from 2027 to 2029. PCAOB AS 2401 contract completeness consistently appears in the top-5 inspection findings at every Big-4 firm, with side-letter detection and procurement-to-balance reconciliation the most-cited deficiencies. For an SEC-registered multinational, a single contract-compliance failure compounds into an uncertain-position disclosure under ASC 740-10 and IAS 12, a Big-4 auditor-concurrence challenge under PCAOB AS 2201 and AS 2401, an SEC Division of Corporation Finance comment letter, and a class-action lawsuit - cumulative downside exposure typically exceeds USD 50 million for a material enforcement action.

## The international contract compliance pipeline runs 16 deterministic and judgement-supported steps

Cross-jurisdictional contract compliance with full judgement-intensive decision support requires 16 steps because every contract has to pass through each one: scope identification (the CSDDD chain-of-activities classification, the FCPA accounting scope, UKBA Section 7 corporate liability, and SOX 404 contract-cycle materiality), LLM clause extraction, counterparty due diligence with beneficial ownership and adverse media, deterministic sanctions screening with 50% Rule entity tracing, ITAR and EAR deemed-export analysis, third-party-intermediary classification, anti-bribery red-flag detection, gift-and-hospitality threshold monitoring, modern-slavery and human-rights due diligence under the UK MSA and EU CSDDD, ESG-taxonomy substantiation under the EU Taxonomy and CSRD ESRS, whistleblower-channel operation under EU Directive 2019/1937, obligation, SLA, KPI, and deadline tracking, modification and side-letter assessment under PCAOB AS 2401, the DOJ ECCP, UKBA Section 7, and ISO 37001 evidence packaging, and the CSRD ESRS G1, UK Section 172, and UK MSA Section 54 disclosure drafting.

Consider a US-headquartered industrial manufacturer with USD 12 billion revenue, dual-reporting under SOX 404 for the SEC-listed parent and CSRD ESRS G1 for an EU subsidiary, with a UK Section 172 statement for a UK subsidiary and a UK MSA Section 54 statement for a UK trading entity. It runs 4,200 active commercial contracts: 1,800 supplier contracts (including 320 third-party intermediaries across high-risk geographies), 1,600 customer contracts, 600 distributor agreements, and 200 IT and SaaS contracts. Per quarter the Agent processes 180 new contracts and 420 modifications, performs counterparty due diligence with beneficial-ownership extraction and PEP, sanctions, and adverse-media screening on 600 new counterparties, applies sanctions screening with 50% Rule entity tracing across all 4,200 active counterparties, classifies the 320 third-party intermediaries with enhanced FCPA and UKBA due diligence, monitors gifts and hospitality against thresholds, runs the PCAOB AS 2401 contract-completeness procurement-to-balance reconciliation, and drafts the CSRD ESRS G1, UK Section 172, UK MSA Section 54, and UK Procurement Act 2023 disclosures.

In the [Decision Layer](/en/decision-layer/), 4 of the 16 steps are rule-based (R), 7 are human judgement (H) reflecting compliance reality, and 5 are LLM suggestions (A) for clause extraction, third-party adverse-media review, anti-bribery red-flag detection, ESG substantiation, and disclosure drafting. No generative AI touches scope identification, sanctions screening, export-control determination, or third-party-intermediary classification - the LLM never determines a compliance outcome without human acceptance.

## Third-party-intermediary risk classification carries 90 percent of FCPA enforcement and is the most-cited DOJ ECCP gap

Third-party intermediaries - agents, distributors, consultants, and joint-venture partners - acting for the company in interactions with foreign officials carry elevated risk under the FCPA and UKBA Sections 6 and 7, and 90 percent of FCPA enforcement actions involve them per the DOJ and SEC FCPA Year-In-Review reporting. The DOJ ECCP March 2023 update requires data-analytics-driven third-party risk management with documented criteria covering government-touchpoint frequency, payment structure (success fees, lump sums, or offshore accounts), geographic risk on the Transparency International CPI, referral source, business justification, training and certification, and audit rights. UK MoJ adequate-procedures Principle 4 requires proportionate, risk-based due diligence with documented criteria. The Agent operationalises the classification with policy-driven risk tiers (Standard, Enhanced, or Specialised), documented criteria applied by a named compliance officer, a periodic refresh cadence, and preservation of the PCAOB AS 2401 and ISA UK 240 substantive-testing evidence. F500 enforcement examples include the Goldman Sachs settlement of USD 2.9 billion in 2020 (the Malaysia 1MDB agent), the Walmart settlement of USD 282 million in 2019 (intermediaries in Mexico, India, Brazil, and China), and the Embraer settlement of USD 205 million in 2016 (agents in Saudi Arabia, the Dominican Republic, and Mozambique).

## Sanctions screening with 50% Rule entity tracing becomes a zero-defect deterministic engine

OFAC strict-liability enforcement, with maximum civil penalties of USD 368,136 per violation and criminal exposure up to USD 1 million and 20 years' imprisonment, demands zero-defect screening. The 50% Rule extends sanctions to entities owned 50 percent or more, in aggregate and directly or indirectly, by SDN parties regardless of separate listing. The expanded Russia and Belarus sanctions since 2022 are especially complex, layered through Executive Orders 14024, 14039, 14066, 14068, and 14071 and implementing OFAC Directives 1A through 4, with oligarch ownership often disguised through nominees, offshore structures, and family-member registrations. The Agent's deterministic five-phase screening runs a direct match against the SDN, SSI, and sectoral lists with fuzzy logic, traces beneficial ownership through corporate structures to the fifth tier, aggregates ownership across multiple SDN parties for the 50% Rule, checks geographic risk against comprehensive country sanctions, and reviews adverse media and PEP status. The EU Consolidated Sanctions List, UN Sanctions, and UK HMT OFSI screening run in parallel, since EU and UK sanctions diverge from US sanctions on certain Russian entities post-2022 and need jurisdiction-specific application. The Agent generates OFAC SDN screening evidence against the five components of the OFAC Compliance Commitments framework, plus equivalent EU, UK, and UN evidence packs, for cross-jurisdictional audit defence under PCAOB AS 2401 and ISA UK 240.

## Integration ecosystem: Coupa, SAP Ariba, Oracle Procurement Cloud, Icertis, DocuSign CLM, and Ironclad, plus Big-4 compliance tools

The Agent integrates with the major contract-lifecycle-management platforms: [Coupa Business Spend Management](https://www.coupa.com/products/contract-lifecycle-management), cloud-native with FCPA, UK Bribery Act, and OFAC sanctions screening; [SAP Ariba](https://www.sap.com/products/spend-management/ariba.html), integrated with SAP S/4HANA Finance and SAP GRC; [Oracle Procurement Cloud and Oracle CLM](https://www.oracle.com/scm/procurement/contracts/); [Icertis Contract Intelligence](https://www.icertis.com/), with FCPA representation and warranty extraction and CSDDD chain-of-activities mapping; [DocuSign CLM](https://www.docusign.com/products/clm); Ironclad Contract AI; and Agiloft. For compliance program management it uses NAVEX Global, GAN Integrity, Diligent Compliance, and Workiva Compliance Suite, and for whistleblower channels NAVEX Global EthicsPoint, EQS Integrity Line, Convercent (OneTrust), and WhistleB, all supporting the EU Whistleblower Directive 2019/1937 three-month feedback workflow. Third-party screening runs through Refinitiv World-Check One, Dow Jones Risk Center, and LexisNexis Bridger Insight XG, and audit evidence integrates with Deloitte Compliance Risk Sensing, PwC Risk Detect, EY Compliance Reporting Engine, and KPMG Clara Compliance with PCAOB AS 1215 metadata. Submission runs via SEC EDGAR for the Form 10-K and 10-Q anti-corruption disclosures, UK Companies House for the Section 172 and Modern Slavery Act statements, and the EU Member State portals (Bundesanzeiger, INPI, Registro Mercantil) for the CSRD ESRS G1 disclosures.

--- Credit Note / Reversal Agent ---
> Classifies incoming documents as credit note or reversal invoice, identifies the reference invoice.

Misclassified credit notes and reversal invoices rank among the most frequent VAT findings in tax audits. The cause is almost always the same: suppliers use the terms incorrectly, the ERP adopts the label without verification, and accounts payable posts based on a wrong document class. The Credit Note / Reversal Agent eliminates this risk by classifying every incoming correction document on its content - regardless of what the document header says.

## VAT corrections cost billions at audit time

The scale of the problem is measurable. In 2024, German tax authorities collected an additional EUR 1.63 billion (USD 1.79 billion) through VAT-specific audits across 63,733 examinations (source: Federal Ministry of Finance, published June 2025). That averages roughly EUR 25,600 (USD 28,200) per audit. VAT accounted for 12.8 percent of the total audit yield of EUR 10.9 billion (USD 12 billion).

Confusion between credit notes and reversal invoices drives these numbers. A credit note in the VAT sense is a standalone billing document issued by the recipient of the service. A reversal invoice corrects a faulty invoice issued by the supplier. Both document types carry different legal consequences for input tax deduction. Mixing them up risks the tax authority denying the deduction - retroactively, with interest. (US: The IRS treats credit memos and corrected invoices differently under sales and use tax; HMRC requires distinct treatment under the VAT credit note rules.)

## Suppliers use the terms incorrectly - and the ERP passes the error on

The problem does not originate in in-house accounting. It originates with the supplier. In practice, suppliers routinely label documents as "credit note" when they are, in tax law terms, reversal invoices. Since 2013 legislation in Germany clarified the distinction, but many suppliers never updated their document templates.

A concrete scenario: a chemical company receives approximately 200 correction documents per month from 80 suppliers. Around 35 percent of these documents carry the label "credit note" although they are substantively reversal invoices. The AP clerk must check the substantive characteristics of every single document, locate the reference invoice and determine the correct tax treatment. For manual invoice processing, the error rate sits at around 2 percent (source: IOFM/Ardent Partners AP Benchmark Report). For correction documents that arrive with the wrong label, experience suggests the rate is significantly higher.

## Content-based classification replaces the document header

The [Decision Layer](/en/decision-layer/) solves this problem with a clear separation: the first decision - credit note or reversal invoice - is the only one that uses AI assistance. The language model analyses the document content, not the header. It checks who issued the document, whether an original invoice is being corrected and which legal consequences the content triggers.

This classification is deliberately placed at tier 2 in the Decision Layer: AI-assisted with human review capability. The statutory auditor can trace every single classification decision because the agent documents on which features it classified the document. The six subsequent steps - identify the reference invoice, validate the amount, calculate the VAT correction, create the offsetting entry, ensure audit-compliant linking and verify the tax treatment - run fully rule-based at tier 1 without AI involvement.

## The document chain becomes audit evidence

Audit-compliant archiving is not achieved by a document management system alone. It is achieved by the unbroken link between every correction document and its original invoice. The agent establishes this link during every processing run - via reference number matching and, when the supplier provides no reference number, via fuzzy matching on amount, date and supplier.

During a tax audit, the difference shows: instead of manually matching individual credit notes and reversals to their source documents, a complete decision file is available. For every document, it is traceable why it was classified as a credit note or reversal, which original invoice is affected, how the VAT correction was calculated and how the offsetting entry was derived. That reduces audit effort - for the in-house team as much as for the auditor.

--- Depreciation Agent ---
> Determines depreciation method and useful life from the BMF table, calculates monthly depreciation amounts.

Depreciation belongs to the most heavily regulated processes in financial accounting. The method, useful life, cost basis and journal entry - every step is defined by statute, official table or accounting election. Yet in most organisations, fixed asset accounting still absorbs considerable manual capacity. The reason: clerks navigate between depreciation tables, low-value asset thresholds and special rules without a central logic ensuring consistency. That changes when a rule-based agent takes over the entire depreciation chain.

## Tax auditors correct depreciation errors that should never occur

Tax audits across Germany produced additional assessments of EUR 10.9 billion (USD 12 billion) in 2024 - from only 140,764 audited businesses out of 8.8 million on file (Federal Ministry of Finance, November 2025). Depreciation is a standard audit focus because typical errors cascade through the entire asset register: incorrectly assigned useful lives, overlooked low-value asset thresholds, unapplied special depreciation for digital assets.

The error sources are not knowledge gaps. They arise because a clerk managing 2,000 or 5,000 assets does not look up the correct asset class, verify the useful life and check the low-value threshold for every single item. Volume produces errors - not complexity.

## Every decision step follows a rule set with zero room for interpretation

The [Decision Layer](/en/decision-layer/) decomposes depreciation into seven steps. All seven are fully rule-based (Horizont 1 - no AI, no human discretion on individual items):

The depreciation method derives from the asset master record and the elected tax option. The useful life comes from the official depreciation table. The cost basis is calculated from acquisition or production costs under the statutory definition. The monthly amount is a quotient. The special depreciation entitlement for digital assets is a threshold check. The journal entry follows a fixed posting logic. The low-value asset check compares the net amount against the statutory limit of EUR 800 (USD 880). (US: Section 179 and bonus depreciation rules apply instead; Annual Investment Allowance thresholds differ.)

Not a single one of these steps requires an estimate, a valuation or a weighing of alternatives. That makes the depreciation process the ideal candidate for automation at the lowest Decision Layer tier.

## A manufacturer with 3,200 assets illustrates the leverage

A mid-sized manufacturer manages a portfolio of 3,200 assets - production equipment, IT hardware, vehicle fleet, office furniture. Every month, fixed asset accounting calculates the depreciation amount for every active asset and creates the journal entry. For new additions, the initial valuation is added: determine asset class, look up the depreciation table, check the low-value threshold, set the method.

Without the agent, a clerk handles this in the ERP - asset by asset, field by field. At an average processing time of three minutes per new addition and 40 additions per month, that alone is two hours of routine work containing zero discretion. The monthly depreciation runs come on top.

With the Depreciation Agent, the system reads the asset class from the master record, looks up the useful life in the centrally stored depreciation table, calculates the monthly amount, checks the low-value threshold and creates the journal entry. The entire operation runs in seconds, not minutes - and every single calculation is documented with the applied rule and table version.

## The depreciation table becomes centrally versioned infrastructure

The real value lies not in accelerating individual postings. It lies in the infrastructure that emerges. The official depreciation table exists in most organisations as a PDF or as a manually maintained master data table in the ERP. When the authorities update the table - most recently for computer hardware and software - someone must manually propagate the change.

In the Decision Layer, the depreciation table becomes a centrally versioned rule set. An update takes immediate effect on all new calculations. The previous version remains documented for existing assets. And during a tax audit, it is traceable for every single asset which table version applied at the time of initial valuation.

This infrastructure serves more than just the Depreciation Agent. The Asset Capitalisation Agent, the Inventory Agent and the Annual Statement Agent all access the same versioned table. The low-value asset logic is reused by the Account Coding Agent. What starts as a single depreciation process becomes the foundation of the entire fixed asset accounting stack.

## The audit trail arises as a by-product

For the CFO, the decisive question is not whether the depreciation run finishes faster. The decisive question is whether it withstands the next tax audit. At audit rates of nearly 30 percent for large enterprises, that is not a theoretical consideration.

A rule-based agent produces the audit trail as a by-product of every calculation: applied method, depreciation table version, acquisition cost, calculation path, low-value asset check, special depreciation check. The asset register for the annual financial statements builds itself from these documented individual decisions - not from a retrospective reconstruction.

--- Dunning Agent ---
> Turns overdue invoices into court-ready claims, applying UK, EU and US collections law deterministically with IFRS 9 ECL provisioning.

International collections is not one process - it is three regimes operating in parallel with sharply different rules. UK debtors fall under the Late Payment of Commercial Debts (Interest) Act 1998 (statutory 8% above Bank of England base rate plus fixed compensation per invoice) and the Pre-Action Protocol for Debt Claims (mandatory 30-day Letter of Claim before any court action since 1 October 2017). EU debtors trigger Directive 2011/7/EU with its 30-day default and 60-day maximum B2B payment terms, ECB reference rate plus 8 percentage points statutory interest, and EUR 40 minimum compensation per invoice. US debtors split immediately into commercial (free of FDCPA) versus consumer (where Fair Debt Collection Practices Act and CFPB Regulation F impose hour-of-day restrictions, communication caps, and validation-notice obligations). Layer over this the IFRS 9 Expected Credit Loss model versus US ASC 326 CECL provisioning regime, SOX 404 internal-controls testing for SEC filers, and state-by-state limitation periods in the US, and the result is a pipeline that no single human credit manager can run consistently at scale.

## SOX 404 ECL provisioning errors trigger material-weakness disclosure - PCAOB inspections cite AR provisioning as the most common Big-4 audit deficiency

Allowance for doubtful accounts is one of the largest single estimates on the balance sheet of any commercial enterprise - and one of the most subjective. Under IFRS 9 the auditor must test (a) the appropriateness of stage 1 / stage 2 / stage 3 classification, (b) the reasonableness of the 30-day and 90-day rebuttable presumptions, (c) the inputs to 12-month versus lifetime ECL calculation, and (d) the consistency with macroeconomic forecasts. Under US ASC 326 CECL (mandatory for SEC filers from 1 January 2020) the auditor tests the historical loss data, the current conditions overlay, and the reasonable supportable forecast - all of which are management estimates with material judgement.

PCAOB's 2023 Annual Report inspection findings cite estimate-based allowance accounts among the top-3 most common Big-4 audit deficiencies year after year. A material weakness disclosure under SOX 404 typically erodes 4-7% of share price in the trading week following the 10-K filing - and triggers SEC enforcement scrutiny under SEC Rule 13a-15. For a Russell-3000 mid-cap with USD 800M market cap, a 5% share-price impact equals USD 40M of shareholder value destroyed by an AR provisioning failure that an automated Decision Log would have prevented. Add the audit-fee uplift (Big-4 firms charge a 30-50% premium on remediation engagements), the management distraction (CFO, Controller, and audit-committee time), and the carrying cost in a higher cost of capital, and the practical exposure on a single AR provisioning failure runs to USD 50-100M for a typical mid-cap multinational.

## The international collections pipeline runs 13 deterministic steps - not 8

Domestic UK or single-country dunning processes can be modelled in 8 steps. International cross-jurisdictional collections cannot. The Agent splits the pipeline into 13 steps because every escalation decision requires checking the jurisdiction, the debtor classification (B2B versus B2C under three different consumer-protection regimes), the applicable interest rate (UK statutory, EU Directive, or US contractual), the aging-bucket transition (IFRS 9 stage 1 to stage 2 at 30 days past due, stage 3 at 90 days), the credit-bureau filing rules (UK GDPR with ICO guidance, US FCRA, and EU GDPR with national rules), the limitation period (6 years for a simple contract in the UK, 3-15 years state-by-state in the US, and member-state-by-member-state in the EU), and the pre-litigation requirements (the UK Pre-Action Protocol, the US Reg F validation notice, or EU national procedures).

Consider a global mid-cap with USD 800M revenue and USD 80M of average outstanding receivables, split 40% UK, 35% continental EU (Germany, France, Netherlands), and 25% US. On a typical Tuesday batch run the Agent identifies 2,400 invoices overdue by at least one business day, classifies each by jurisdiction and debtor type, calculates 1,800 statutory-interest accruals (under the UK Late Payment Act and the EU Directive separately), checks 380 dunning holds (open disputes, credit notes, and payment plans), sends 920 first reminders, prepares 340 UK Pre-Action Protocol Letters of Claim and 180 US Reg F validation notices, files 520 records with the credit reference agencies (Experian, Equifax, TransUnion, Creditreform, and Dun & Bradstreet), provisions 280 receivables to IFRS 9 stage 2 and 95 to stage 3, updates 45 ASC 326 CECL pools for the US-listed parent's SEC filing, flags 22 receivables approaching limitation (at the 5y9m mark on the UK 6-year horizon, for early action), prepares 8 statutory demands under the Insolvency Act 1986 for UK corporate debtors over GBP 750, and routes 3 cases to Treasury and Legal for a human decision on MCOL filing versus solicitor escalation.

In the [Decision Layer](/en/decision-layer/), 12 of the 13 steps are rule-based (R). The single human decision is the formal escalation - whether to file a UK Statutory Demand under Insolvency Act 1986 s. 123, route to MCOL or High Court, or pursue US state court action. That decision involves trade-offs between recovery probability, customer relationship, court fees (UK MCOL: GBP 35-10,000 sliding scale, US small claims USD 25-200), legal costs, and reputational risk that no rule should resolve unilaterally. Every other step - interest calculation, validation notice, credit-bureau filing, ECL provisioning, limitation tracking - is a deterministic application of statute, regulation, or accounting standard.

## Reconciliation before any escalation step prevents wrongful collection - and Reg F violations

Automated dunning without real-time payment reconciliation is a Regulation F violation waiting to happen. Reg F Sec. 1006.30 prohibits misleading representations including any communication that misrepresents the amount or status of a debt. A consumer pays via Faster Payments at 5pm Friday, the Agent sends a dunning notice at 7am Monday before the bank-statement reconciliation has run - the consumer immediately has a CFPB complaint pathway with statutory damages USD 100-1,000 per violation under FDCPA Sec. 1692k. UK equivalent: ICO can find a UK GDPR Art. 5(1)(d) accuracy violation. EU equivalent: national consumer protection authorities can act under Directive 2011/83/EU.

The Agent therefore runs reconciliation as the 13th decision-point gate before any new dunning step. Bank-statement formats are pulled in real time: SEPA and CAMT.053 for the EU, BACS, Faster Payments, and CHAPS notifications for the UK, and NACHA ACH and FedWire for the US. Open Banking PSD3 (EU implementation date pending) and PSD2 (still in force in the UK post-Brexit) provide payment-initiation and account-information services with a full consent trail. FDX (Financial Data Exchange) standardises US Open Banking. Partial payments are recognised with proportional allocation across principal, interest, and fixed compensation per the contractual or statutory order of imputation (UK common-law rule in Clayton's Case 1816 for current accounts, otherwise contract-driven). Only receivables genuinely outstanding after reconciliation continue through the escalation pipeline.

## Limitation periods, statutory demands, and cross-border enforcement need precision without margin

Limitation is jurisdiction-by-jurisdiction. UK: simple contract debt 6 years from accrual under Limitation Act 1980 s. 5, specialty debt 12 years under s. 8. US: state-by-state - New York 6 years (CPLR 213), California 4 years (CCP 337), Texas 4 years (Tex. Civ. Prac. and Rem. Code 16.004) for written contracts. EU: Germany 3 years (BGB Sec. 195/199), France 5 years (Code civil Art. 2224), Spain 5 years (Codigo Civil Art. 1964 amended 2015), Italy 10 years (Codice civile Art. 2946). Restart triggers vary - acknowledgement in writing, part-payment, court action, or arbitration notice can each restart the clock under different rules.

The Agent monitors limitation daily and flags receivables approaching 90 days from limitation expiry, recommending interruption tactics: a UK Statutory Demand under Insolvency Act 1986 s. 123 (corporate debtor over GBP 750, individual over GBP 5,000, 21-day expiry triggers winding-up petition presumption), a US written acknowledgement request, or an EU member-state-specific extrajudicial interruption (e.g., German requirement of either acknowledgement or court action under BGB Sec. 212-213). For genuinely cross-border claims, the Agent prepares the European Account Preservation Order (EAPO) packet under EU Regulation 655/2014 - a unilateral pre-judgment freeze on debtor accounts in another EU member state. Brussels Regulation Recast (Regulation 1215/2012) provides recognition and enforcement of judgments across EU members; the UK exited this regime post-Brexit, so UK-EU cross-border enforcement now relies on the Hague 2005 Choice of Court Convention or bilateral treaties.

## Integration ecosystem: SAP, Oracle, Workday, Sage Intacct, plus credit bureaus and court systems

The Agent integrates natively with the major international ERPs: [SAP S/4HANA Cloud](https://www.sap.com/products/erp/s4hana.html) FI-AR and Credit Management via OData, [Oracle Fusion Cloud Financials](https://www.oracle.com/erp/financials/) Receivables and Advanced Collections via REST, [Workday Financial Management](https://www.workday.com/en-us/products/financial-management/) Customer Accounts via WSDL/SOAP, [Sage Intacct](https://www.sage.com/en-us/products/sage-intacct/) Collections Automation via REST, Microsoft Dynamics 365 Finance Credit and Collections via OData, and Oracle NetSuite SuiteCloud Receivables Management. For specialist AR automation it integrates with BlackLine Cash Application and Collections (Big-4 audit-friendly with PCAOB-aligned controls) and HighRadius Collections Cloud (IFRS 9 and CECL ready). The credit-bureau APIs cover Experian Business and Consumer, Equifax Commercial and Consumer, and TransUnion across the UK and US, the Creditreform Verband API for Germany and Central Europe, CRIF for Italy and Central Europe, and Dun & Bradstreet D-U-N-S Direct and DataBlocks. UK court integration runs through County Court Money Claim Online for claims up to GBP 100,000, with electronic filing and fee payment by debit card; US court integration varies state by state, typically through state-court e-filing systems or third-party filers such as One Legal and File & ServeXpress. Outbound dunning communications honour the Reg F time restrictions (8 a.m. to 9 p.m. local debtor time, with a 7-in-7 communication cap), the UK Pre-Action Protocol templates, and EU member-state-specific notice requirements - all generated as deterministic templates with audit-trail metadata for SOX 404 evidence packs and PCAOB substantive testing.

--- Entertainment Expense Tax Agent ---
> Entertainment expense tax check: IRC Section 274(n) 50% meals deduction, IRS Publication 463 substantiation limits, EU VAT recovery and four-eye validation of the receipt.

Entertainment receipts do not fail tax audits because of incorrect amounts. They fail because of missing mandatory fields - a formality error that destroys the entire business expense deduction. With EUR 10.9 billion (USD 12 billion) in additional tax assessments from audits in 2024 (source: Federal Ministry of Finance, November 2025), entertainment expenses are among the items auditors systematically target. Every receipt without complete information is a hit.

## Form errors wipe out the entire deduction

The arithmetic is simple: 70 percent deductible, 30 percent not. Nobody fails at that. The problem lies in the five mandatory fields required under German tax law: location, date, attendees, business purpose and amount. If one is missing, the tax authority does not strike 30 percent - it strikes everything. Location and date appear on the restaurant receipt. Attendees and purpose are where it gets critical. In practice, the most common gap is an incomplete attendee list or a business purpose so vague - "business dinner" without further detail - that the tax authority does not accept it. (US: The IRS requires similar substantiation under IRC Section 274; HMRC applies the "wholly and exclusively" test for business entertainment.)

A concrete scenario: a sales director entertains four clients after a product presentation. The EUR 480 (USD 530) receipt is correct, the restaurant included all information on the till receipt. But the entertainment form lists only "client meeting" as the purpose and one attendee name is missing. During a tax audit three years later, the full EUR 480 is disallowed - not because the amount was unreasonable, but because two lines were incomplete.

## Tightened documentation requirements raise the bar further

Updated guidance from the German tax authority in November 2025 tightened the documentation rules for entertainment expenses. Restaurants with electronic point-of-sale systems must produce machine-generated receipts secured by a certified technical security device. Handwritten receipts or simple printouts without security markings are no longer accepted. For companies, this means: even a substantively correct entertainment receipt can fail if the underlying restaurant receipt does not meet the formal requirements. A compliant receipt is recognisable by its transaction number, the till system's serial number or a printed QR code.

## Nine decision steps between receipt and posting

The [Decision Layer](/en/decision-layer/) breaks entertainment receipt verification into nine steps with clear assignment: who decides - rule engine, AI, or human?

Receipt classification uses the LLM to recognise whether the document is an entertainment receipt at all. Then the rule engine checks the five mandatory fields and the completeness of the attendee list deterministically. These are binary questions - present or not. There is no room for discretion and no reason for human intervention.

The plausibility of the business purpose is assessed by the LLM. "Project meeting - logistics digitalisation with Company X" is plausible. "Dinner" is not. The model recognises patterns and prompts the submitter to add detail before the receipt reaches accounting.

The deductibility split (70/30), input tax deduction and account coding run rule-based. Audit-compliant archiving with a timestamp closes the process. All nine steps are documented and traceable for a subsequent tax audit.

## Reasonableness remains a human decision

One decision step is deliberately handled by no algorithm: the reasonableness check. Whether EUR 120 (USD 132) per person at a business dinner with three clients is reasonable depends on industry, context and the business relationship. A dinner during contract negotiations follows different standards than a lunch after an introductory meeting. The agent gives the decision-maker the facts - amount per person, comparison with historical values, ratio to the business volume involved. The approval or escalation is the human's call.

This boundary is not a technical limitation. It is governance. An entertainment expense agent that independently judges reasonableness would automate discretionary decisions that a tax auditor would challenge. Responsibility stays where it belongs.

--- ESG Reporting Agent ---
> Cross-jurisdictional ESG pipeline: EU CSRD with ESRS E1-S1-G1, IFRS S1+S2 ISSB climate, SEC Climate Rules, California SB 253/261, UK TCFD, EU Taxonomy, GRI, TNFD.

International sustainability reporting runs on a layered framework of cross-jurisdictional regimes. The EU CSRD (Directive 2022/2464) phases in over Waves 1-4 from FY2024 to FY2028, with ESRS Set 1 covering roughly 1,144 datapoints across the cross-cutting, environmental, social, and governance standards; the EU Taxonomy Regulation 2020/852 adds substantial-contribution, DNSH, and minimum-safeguards screening; EU SFDR 2019/2088 adds entity- and product-level disclosures with Principal Adverse Impacts; and the EU CSDDD 2024/1760 phases in from 26 July 2027. The ISSB's IFRS S1 and S2, effective 1 January 2024, are being adopted across the UK, Australia, Japan, Canada, Brazil, and Singapore. The US SEC Climate-Related Disclosures Final Rule (March 2024, Subpart 1500) is under the Eighth Circuit stay, yet EU and UK subsidiaries continue parallel adoption; California SB 253 and SB 261 reach first reports in 2026 for roughly 5,300 companies; and the FTC Green Guides police anti-greenwashing. In the UK, SECR and the Climate-related Financial Disclosure Regulations 2022 are mandatory for the FTSE 350 and listed entities, the SDR under FCA PS23/16 and PS24/3 adds the anti-greenwashing rule and product labels, FRC Provision 29 takes effect from 1 January 2026, and GRI Standards 2021 and TNFD Recommendations v1.0 round out the picture. A US-headquartered multinational with EU subsidiaries facing CSRD Wave 1 FY2024, a UK FTSE 350 entity preparing for FRC Provision 29 with UK TCFD and SDR product labels, and a California-doing-business entity with USD 1.2 billion revenue facing SB 253 and SB 261 first reports in 2026 must run parallel determinations while applying six judgement-intensive decisions: cross-jurisdictional reporting scope, the double materiality assessment, EU Taxonomy alignment screening, SEC Climate preparedness despite the stay, Big-4 assurance coordination, and the cross-jurisdictional filing submission. Over the top sit Big-4 assurance under ISAE 3000 Revised moving to reasonable assurance by 2028 (with IAASB ISSA 5000 effective 15 December 2026), the ESMA 2024 Common Enforcement Priorities, and FTC Green Guides enforcement, as in the Walmart-Kohl's 2022 bamboo-textile case and Volkswagen's 2016 dieselgate.

## Roughly 1,144 ESRS datapoints: 281 mandatory regardless of materiality, 863 conditional on double materiality

ESRS Set 1, adopted via Commission Delegated Regulation (EU) 2023/2772, covers 12 standards organised across cross-cutting topics (ESRS 1 General Requirements and ESRS 2 General Disclosures), environmental topics (E1 Climate Change, E2 Pollution, E3 Water and Marine Resources, E4 Biodiversity and Ecosystems, E5 Circular Economy), social topics (S1 Own Workforce, S2 Workers in the Value Chain, S3 Affected Communities, S4 Consumers and End-Users), and governance (G1 Business Conduct). The mandatory-versus-conditional split reflects the double materiality logic: 281 datapoints, in ESRS 2 General Disclosures and selected ESRS E1 climate datapoints, apply regardless of the materiality outcome, while 863 datapoints across the topical standards apply only if the relevant matter is material under the assessment. EFRAG IG 1 Materiality Assessment Implementation Guidance 2024 and the ESMA Public Statement on the First Application of ESRS (October 2024) set the methodology standard. A typical industrial group running its first CSRD Wave 1 cycle for FY2024 (filed 2025) faces around 375 hours of manual datapoint collection spread across its sustainability, finance, HR, procurement, EHS, and facilities teams, while it simultaneously prepares the annual financial statement under IFRS or local GAAP with the audit committee. Without systematic data infrastructure and a Big-4 assurance evidence trail, the cycle compounds into ESMA enforcement exposure, an assurance qualification, and greenwashing litigation under the FTC Green Guides, the UK FCA anti-greenwashing rule, and state-level CLRA and UCL claims.

## AI-supported Scope 3 estimation across 15 categories shifts the burden under PCAF and the GHG Protocol

Scope 3 indirect value-chain emissions across 15 categories, under the GHG Protocol Corporate Value Chain Standard and, for financial services, the PCAF Global GHG Accounting and Reporting Standard for Financed Emissions, are the materiality bottleneck for most CSRD, IFRS S2, SEC Climate, and California SB 253 reporters. Scope 1 and 2 emissions are deterministic - activity data times an emission factor with operational and financial control consolidation - but Scope 3 estimation requires choosing a methodology per category, from supplier-specific (primary data preferred) through hybrid and average-data to spend-based using EEIO factors. ML-supported estimation that combines procurement spend, supplier engagement, and industry averages cuts the manual work from quarter-cycles to weeks, but the LLM never finalises a Scope 3 disclosure: the sustainability owners and Big-4 assurance review under ISAE 3000 Revised and IAASB ISSA 5000 apply the disposition with a documented methodology, boundary, and uncertainty assessment. This matters most for the CSRD ESRS E1 climate transition plan, the IFRS S2 climate-related metrics, the SEC Climate phased Scope 3 (subject to the stay), and the California SB 253 Scope 3 first reports in 2027 (FY2026).

## The international ESG reporting pipeline runs 14 deterministic and judgement-supported steps

Cross-jurisdictional CSRD, ESRS, IFRS S1 and S2, SEC Climate, California SB 253/261, UK TCFD and SDR, GRI, and TNFD reporting with full judgement-intensive decision support requires 14 steps, because every reporting cycle has to pass through each one: cross-jurisdictional scope determination across the CSRD waves, IFRS adopting jurisdictions, the SEC Climate stay, California, and the UK; the double materiality assessment under ESRS 1 and 2 (versus single financial materiality under IFRS S1); the Scope 1 and 2 GHG-emissions calculation under the GHG Protocol Corporate Standard; the Scope 3 estimation across 15 categories under the GHG Protocol Scope 3 Standard and PCAF; EU Taxonomy alignment screening with substantial contribution, DNSH, and minimum safeguards; ESRS datapoint collection across roughly 1,144 datapoints; the IFRS S1 and S2 TCFD-aligned governance, strategy, risk management, and metrics; SEC Climate Subpart 1500 and California SB 253/261 preparedness despite the stay; the UK TCFD, SDR, SECR, and FRC Provision 29 disclosures; FTC Green Guides screening of environmental marketing claims; the ESRS, IFRS, TCFD, and GRI report drafting with cross-framework reconciliation; the iXBRL ESEF and EFRAG Digital Reporting taxonomy tagging; the Big-4 assurance coordination under ISAE 3000 Revised and IAASB ISSA 5000; and the cross-jurisdictional filing submission via SEC EDGAR, ESMA and the Member State NCAs, UK Companies House, the FCA, and CARB.

Consider a US-headquartered industrial group with EUR 8 billion revenue, dual-reporting under CSRD Wave 1 FY2024 (its EU subsidiaries filed in 2025), with parallel IFRS S2 in the UK (the SRS endorsement consultation 2024-2025) and Brazil (CVM Resolution 193 mandatory 2026), SEC Climate preparedness despite the stay, California SB 253 and SB 261 (its USD 1.2 billion California revenue triggering first reports in 2026), and UK TCFD, SDR, SECR, and FRC Provision 29 obligations. Per reporting cycle the Agent collects the roughly 1,144 ESRS datapoints (281 mandatory, 863 conditional), calculates Scope 1 and 2 emissions under the GHG Protocol by the location- and market-based methods, estimates Scope 3 across 15 categories with a supplier-engagement program covering 4,800 Tier-1 suppliers via CDP Supply Chain, screens roughly 320 economic activities for EU Taxonomy alignment with NACE-code mapping and the screening criteria, DNSH, and minimum safeguards, drafts the IFRS S2 TCFD-aligned narrative with climate scenario analysis (the 1.5°C, 2°C, and 4°C cases plus delayed- and disorderly-transition variants), screens 240 environmental marketing claims under the FTC Green Guides, applies iXBRL ESEF tagging across the roughly 1,144 datapoints under the EFRAG ESRS XBRL Taxonomy, and coordinates Big-4 limited assurance under ISAE 3000 Revised transitioning to reasonable assurance by 2028.

In the [Decision Layer](/en/decision-layer/), 3 of the 14 steps are rule-based (R) - the Scope 1 and 2 emissions calculation, ESRS datapoint collection, and iXBRL ESEF tagging - 6 are human judgement (H) reflecting sustainability-reporting reality, and 5 are LLM suggestions (A) - Scope 3 estimation, the IFRS S1 and S2 TCFD narrative, the UK TCFD, SDR, and SECR disclosures, FTC Green Guides screening, and report drafting. No generative AI touches materiality determination, taxonomy alignment, or the assurance opinion - the LLM never determines a materiality outcome or assurance opinion without human acceptance.

## Big-4 assurance moves from limited to reasonable by 2028 under ISAE 3000 Revised and IAASB ISSA 5000

CSRD Article 34a establishes transitional limited assurance moving to reasonable assurance by 2028, with amendments to the EU Audit Directive. ISAE 3000 Revised and the IAASB's ISSA 5000 General Requirements for Sustainability Assurance Engagements (approved 2024, effective 15 December 2026) set the practitioner requirements. Limited assurance gives a negative-form conclusion (engagement risk acceptable but greater than for reasonable assurance); reasonable assurance gives a positive-form conclusion. The Big-4, Tier-2 firms, and member-state-permitted independent assurance service providers compete - Deloitte ESG Assurance, PwC Sustainability Assurance, EY CCaSS, and KPMG IMPACT, alongside BDO, Grant Thornton, Mazars, and RSM. The assurance scope covers the ESRS materiality assessment, datapoint completeness, Scope 1, 2, and 3 GHG-emissions verification, the EU Taxonomy Article 8 KPIs, the iXBRL tagging review, and the management-report integration. The Agent's Decision Log preserves the complete evidence - stakeholder-engagement records, the materiality reconciliation, GHG Protocol verification, Taxonomy alignment, iXBRL validation, and the management representation letter - under the ESMA Sustainability Reporting Enforcement Convergence Action Plan.

## Integration ecosystem: Workiva, Persefoni, Sweep, Watershed, Plan A, and AuditBoard ESG, plus Big-4 sustainability assurance

The Agent integrates with the major sustainability platforms: [Workiva](https://www.workiva.com/) for disclosure management with CSRD ESRS, IFRS S1 and S2, and iXBRL ESEF tagging; [Persefoni](https://www.persefoni.com/) for climate management with GHG Protocol Scope 1, 2, and 3, PCAF, TCFD, ISSB, and CSRD ESRS E1; [Sweep](https://www.sweep.net/) for CSRD ESRS, IFRS S2, and supplier engagement; [Watershed](https://watershed.com/) for measurement, reduction, reporting, and SBTi; [Plan A](https://plana.earth/) for full CSRD ESRS coverage and decarbonization; and [AuditBoard ESG](https://www.auditboard.com/) for ESG controls integrated with SOX 404, along with the SAP Sustainability Control Tower, Microsoft Cloud for Sustainability, Salesforce Net Zero Cloud, Cority, Sphera, Position Green, and Greenstone. For Big-4 sustainability assurance it works with Deloitte ESG Assurance, PwC Sustainability Assurance, EY CCaSS, and KPMG IMPACT using the ISAE 3000 Revised and IAASB ISSA 5000 evidence templates. Submission runs via SEC EDGAR for Item 1500 (subject to the stay), the ESMA and Member State NCA portals for the CSRD ESRS sustainability statement as a single iXBRL ESEF document, UK Companies House for the SECR, Section 414CB, and UK FRC Provision 29 board declaration, the FCA for the TCFD and SDR product labels, and CARB for the California SB 253 verified report and the SB 261 biennial report.

--- Financial Forecast Agent ---
> Driver-based rolling FP&A forecasts with scenario planning and EPS guidance, kept audit-ready for SEC, ESMA and Big-4 testing.

International FP&A forecasting operates within an interlocking regulatory regime spanning six major frameworks: SEC Item 303 of Regulation S-K (MD&A) with the PSLRA safe harbor for US-listed entities, the UK FRC Strategic Report Guidance and Companies Act Section 414C for UK-listed companies, the ESMA Guidelines on Alternative Performance Measures for EU-listed entities, IFRS (chiefly IAS 1, IAS 8 and IAS 36) for IFRS-reporting groups, US GAAP (chiefly ASC 205, ASC 270 and ASC 280 on segment reporting) for US GAAP-reporting groups, and SEC Regulation G governing non-GAAP financial measures. Each public company operating across the UK, EU and US must coordinate a driver-based rolling forecast, four-scenario modelling, non-GAAP and APM reconciliation with consistent definitions over time, EPS guidance under safe harbor cautionary language, IAS 36 and ASC 350 impairment trigger detection, and Big-4 substantive testing under PCAOB AS 2501 and ISA UK 540, all with a full audit trail to support SOX 404, UK FRC Provision 29 and Audit Committee oversight.

## Five regulatory pressure points where FP&A forecasting cannot run on a spreadsheet

SEC Item 303 of Regulation S-K mandates Management Discussion and Analysis covering known trends, demands, commitments, events and uncertainties reasonably likely to have material impact on financial condition, results of operations or liquidity. The 2021 SEC amendments expanded forward-looking discussion requirements with critical accounting estimates section and material cash requirements. PSLRA Section 27A and Section 21E provide safe harbor for forward-looking statements accompanied by meaningful cautionary language - but the safe harbor evaporates if statements are made with actual knowledge of falsity, under the reckless disregard standard from the Supreme Court rulings in Janus Capital (2011) and Lorenzo (2019).

The UK FRC Strategic Report Guidance and Companies Act Section 414C require UK-listed companies to provide a fair, balanced and comprehensive analysis of business development, performance and position. UK Corporate Governance Code Provision 31 mandates a viability statement covering typically 3 to 5 years with stress scenarios; Provision 28 requires going concern minimum 12 months. UK FRC Provision 29 effective 1 January 2026 introduces board declaration of ICFR effectiveness for FTSE 350 - aligning UK practice with US SOX 404.

ESMA APM Guidelines (ESMA/2015/1415) for EU-listed entities require non-GAAP/APM measures to be defined, reconciled to IFRS, applied consistently over time, presented with no greater prominence than IFRS metrics, and compared with prior period. Notable enforcement cases: ESMA peer review 2020 found 47 percent of EU-listed companies non-compliant on APM consistency. SEC Division of Corporation Finance comment letters frequently target non-GAAP measures with individually tailored accounting principles, recurring non-recurring items, and equal prominence violations.

An EPS guidance miss, a non-GAAP restatement, an IAS 36 or ASC 350 goodwill impairment and a Big-4 ICFR material weakness disclosure can compound into a securities class action - under SEC Rule 10b-5 in the US, or under FSMA 2000 Section 90A in the UK - with shareholder remedies. Well-known cases include GE between 2018 and 2020 (an SEC accounting fraud matter, a USD 22 billion goodwill impairment and a PCAOB investigation), Wirecard in 2020 (an EY qualified opinion before the fraud was disclosed), Carillion in 2018 (a UK FRC investigation into four-firm audit failures) and Kraft Heinz in 2019 (a USD 15.4 billion goodwill impairment).

## 16 deterministic decision points with three human escalations

The agent processes FP&A forecasting through a pipeline of 16 decision points: thirteen regulatory and methodological classifications, all deterministic, plus three human escalations. Those escalations cover macro assumption approval (FX, rates, inflation and GDP, all matters of management judgement under the PSLRA safe harbor), EPS guidance generation (forward-looking statements requiring General Counsel review), and the going-concern and viability statement (a 12-month horizon under IAS 1 and a three-to-five-year horizon under UK FRC Provisions 28 and 31). Historical data is ingested across IFRS and US GAAP with segment-level granularity per ASC 280 and IFRS 8. A driver tree maps operational drivers (volume, price, ARPU, churn, headcount, productivity) deterministically to GAAP and IFRS account lines. A rolling 18-month operational forecast and a 5-year strategic plan replace annual budget cycles, and a zero-based budgeting overlay on discretionary opex avoids roll-forward inflation anchoring. Four scenarios carry documented assumptions: base, upside P75, downside P25 and stress P10. Sensitivity combines a tornado chart with a 10,000-iteration Monte Carlo run and a correlation matrix.

Concrete example: international group (US headquarters with UK and EU subsidiaries, USD 8 billion revenue, 35,000 employees, listed on NYSE with secondary listing on LSE). Agent ingests 36 months actuals across IFRS and US GAAP. Driver tree: 12 operational drivers per business segment (3 reportable segments per CODM view). Rolling 18-month forecast updated quarterly; 5-year strategic plan refreshed annually with quarterly check-ins. Four scenarios: base case revenue +6.2 percent, upside +9.1 percent, downside +2.4 percent, stress -3.8 percent. Adjusted EBITDA reconciliation to GAAP Operating Income per SEC Reg G. EPS guidance range $5.85-$6.15 with PSLRA cautionary language reviewed by General Counsel. Sensitivity tornado chart shows EPS sensitivity ranking: 1) FX EUR/USD (+/- $0.18 per 5% FX move), 2) gross margin (+/- $0.14 per 100bp), 3) volume growth (+/- $0.11 per 200bp). Backtesting MAPE: next-quarter 3.2 percent, 12-month 7.8 percent, 24-month 15.4 percent (all within AFP thresholds). A goodwill impairment test under IAS 36 and ASC 350 on three reporting units found two with value-in-use above carrying amount and one flagged as an impairment trigger requiring a detailed DCF.

## Driver-based rolling forecast versus traditional annual budget

AFP (Association Financial Professionals) FP&A standards adopted globally favour rolling forecast over static annual budget. Hackett Group benchmarks show 25 percent improvement in MAPE for companies using rolling forecast versus annual budget. AFP Survey 2024 finds 67 percent of S&P 500, FTSE 350 and DAX 40 use rolling forecast methodology. Agent supports both: rolling 18-month operational forecast with quarterly re-baselining for management decisions, plus annual budget snapshot at fiscal year-start with frozen assumptions for Board approval and incentive compensation targets. Driver tree library maps operational drivers to GAAP and IFRS account lines: volume and price feed revenue, headcount and productivity feed operating expense, capex feeds depreciation and PP&E, working capital days feed cash flow. Zero-based budgeting overlay on discretionary opex (marketing, travel, consulting, IT projects) requires line-item justification each cycle - methodology adopted by Kraft Heinz, ABInBev and Unilever for cost discipline.

## Non-GAAP and APM reconciliation under SEC Regulation G and ESMA, with a full audit trail

Agent maintains library of approved non-GAAP and APM adjustments per company with consistency tracking over time. Standard reconciliations include: Adjusted EBITDA bridging to Operating Income via depreciation, amortisation, restructuring charges, share-based compensation, M&A transaction costs and asset impairments. Adjusted EPS bridging to GAAP EPS via the same adjustments tax-effected. Free Cash Flow bridging to Cash from Operations via capital expenditures. Constant Currency Growth using prior-year FX rates. Each adjustment carries SEC Regulation G compliance flags: not individually tailored, not a recurring non-recurring item, equal prominence to GAAP, and a visible reconciliation. ESMA APM compliance is tracked the same way: defined, reconciled, consistent, compared with the prior period and given no greater prominence. The Big-4 audit trail under PCAOB AS 2501, ISA UK 540 and AICPA AU-C 540 is retained with eIDAS QSEAL timestamps in WORM immutable storage.

## Integration with Anaplan, Workday Adaptive, Oracle EPM and SAP Analytics, plus Big-4 substantive testing

The agent integrates with all major EPM platforms via API: [Anaplan Connected Planning](https://www.anaplan.com/) with Anaplan PlanIQ ML (the S&P 500 and FTSE 100 default), [Workday Adaptive Planning](https://www.workday.com/en-us/products/adaptive-planning/overview.html) with Workday Financial Management, [Oracle EPM Cloud](https://www.oracle.com/performance-management/) (Planning, Narrative Reporting, Tax Reporting, Account Reconciliation, FCCS), SAP Analytics Cloud Planning with SAP S/4HANA Group Reporting, IBM Planning Analytics with Cognos Controller, Vena Solutions (Excel-native, mid-market), [Pigment](https://www.pigment.com/) with Cube Software and Mosaic.tech, OneStream, Board International, Jedox, Prophix, Tagetik and Longview Solutions. ERP integration runs over SAP S/4HANA RFC and OData, Oracle Cloud REST, Workday SOAP and REST, Microsoft Dynamics 365 Finance Dataverse and NetSuite SuiteScript. The time-series stack uses TimescaleDB and InfluxDB, and the machine-learning platform combines TensorFlow, Prophet, ARIMA, an LSTM Autoencoder and VAR. Big-4 substantive testing exports directly to Deloitte ASM, PwC Halo, EY Helix and KPMG Clara, carrying PCAOB AS 2501, ISA UK 540 and AICPA AU-C 540 audit-trail metadata in WORM immutable storage with eIDAS QSEAL and QWAC certificate timestamps and a SOX 404 and UK FRC Provision 29 evidence repository.

--- Fraud Detection Agent ---
> Cross-jurisdictional fraud pipeline: SOX 404 ICFR, PCAOB AS 2401 management override, AICPA AU-C 240, UK Bribery Act 2010, UK MLR 2017, EU AMLD6, AMLA 2025, ACFE.

International fraud detection runs against several cross-jurisdictional regimes at once. In the US, that means Sarbanes-Oxley Section 404 ICFR with the fraud-risk presumption under PCAOB AS 2401 management override testing and AICPA AU-C 240, the ACFE Report to the Nations 2024 benchmark (a five percent median annual revenue loss across 1,921 cases, with a USD 145,000 median loss), the FCPA anti-bribery and accounting provisions enforced under the DOJ Corporate Enforcement Policy and the March 2023 ECCP, the Bank Secrecy Act and Anti-Money Laundering Act with the FinCEN Beneficial Ownership Reporting Rule, and the SEC Whistleblower Program with record awards of USD 279 million. In the UK, it means the Bribery Act Section 7 corporate offence with its strict liability and adequate procedures defence, the Money Laundering Regulations 2017 with SFO and DPA enforcement, and the Proceeds of Crime Act 2002 with NCA SAR processing. In the EU, it means the Sixth Anti-Money Laundering Directive with corporate criminal liability and the new Anti-Money Laundering Authority in Frankfurt, operational from mid-2025, directly supervising around 40 of the largest cross-border financial institutions. A US-headquartered multinational with EU subsidiaries, a UK premium-listed entity preparing for the FRC Provision 29 declaration, and an SEC accelerated filer needing both 404(a) management assessment and 404(b) auditor attestation must run these determinations in parallel while applying four judgement-intensive decisions: fraud risk scope identification, alert escalation routing under AS 2401 paragraph 80-85, management certification under Section 302, 404 and 906, and false positive assessment. Over this sit PCAOB deficiency rates of 25-30 percent on AS 2401 substantive testing, recent UK SFO DPAs (Rolls-Royce GBP 497M, Tesco GBP 129M, Airbus GBP 991M coordinated with the DOJ and France's PNF), and AMLA enforcement powers of up to 10 percent of annual turnover.

## Sampling-based audits fail against deliberate concealment under PCAOB AS 2401 fraud risk presumption

PCAOB AS 2401, with AICPA AU-C 240 and ISA UK 240 as the non-issuer and UK equivalents, establishes a fraud-risk presumption requiring consideration of revenue recognition fraud risk (paragraph 41-43), management override of controls (paragraph 58-67) and related-party fraud risk under AS 2410. Sampling-based auditing rests on a core assumption: if a sufficiently large share of transactions is correct, you may infer the same for the whole. Fraud invalidates that. A phantom vendor posting amounts just below the approval threshold for 18 months never shows up in any sample. Threshold splitting - an invoice for USD 9,950 instead of USD 10,000 - looks unremarkable in isolation. Only full-population analysis makes these patterns visible. PCAOB Inspection Reports consistently identify 25-30 percent deficiency rates on AS 2401 substantive testing across Big-4 firms, with management override testing and journal entry analytics deficiencies a recurring theme. For SEC-registered multinationals, UK premium-listed entities and EU CSRD-scoped entities, a single fraud failure compounds into an Item 9A material weakness disclosure under SOX 404, FCPA accounting provisions enforcement, UK Bribery Act Section 7 prosecution by the SFO, EU AMLD6 corporate criminal liability of up to five percent of annual turnover, and class-action exposure - a cumulative downside that typically exceeds USD 100 million for material enforcement actions.

## AI-generated documents shift the threat landscape

Until 2024, forged invoices were detectable by craftsmanship. That has fundamentally changed. AI-generated documents are now visually indistinguishable from real ones, and anti-fraud professionals report a marked increase in GenAI-generated forgeries since 2024. Chris Juneau, SVP at SAP Concur, put it plainly: do not trust your eyes. These fakes survive visual review and often pass rule-based validation. What gives them away are metadata inconsistencies (PDF creation tool fingerprinting, font embedding analysis, colour profile anomalies), structural anomalies (atypical layouts, anomalous tax ID formats), contextual statistical anomalies (a new vendor whose first invoice exactly matches an existing vendor's amount pattern) and provenance signals (PDF/A non-compliance, no digital signature, an image-based PDF with no OCR text layer). This analysis requires AI trained on document authenticity. The LLM never auto-rejects a document; it flags it for vendor and AP disposition with rationale, supporting AS 2401 substantive procedures, the UK Bribery Act adequate procedures defence and the EU AMLA harmonised rulebook.

## The international fraud detection pipeline runs 16 deterministic and judgement-supported steps

Spanning SOX 404, PCAOB AS 2401, the UK Bribery Act Section 7 and MLR 2017, EU AMLD6 and AMLA, and ACFE Fraud Risk Management takes 16 steps because every cycle has to cover fraud risk scope identification (significant accounts, revenue recognition, management override and related parties under AS 2401 and AS 2110), duplicate invoice detection with exact and fuzzy matching, phantom vendor analysis with beneficial ownership lookups, unusual posting detection with Benford's Law and temporal and threshold analysis, AI-generated fake invoice detection from metadata, structural and provenance signals, expense fraud detection across duplicates, inflation, policy and receipt forgery, round-tripping detection from payment network, counterparty and time-series analysis, segregation-of-duties analysis across procure-to-pay, order-to-cash and record-to-report, UK Bribery Act Section 7 third-party due diligence and FCPA red-flag screening, AML/BSA suspicious activity detection against FinCEN CTR and SAR thresholds and the UK NCA and EU AMLA rules, aggregate fraud risk scoring against the ACFE benchmark, alert escalation under AS 2401 paragraph 80-85, management certification under Section 302, 404 and 906, false positive assessment with model retraining, and disclosure submission for Form 10-K Item 9A, UK FRC Provision 29 and EU CSRD ESRS G1.

Consider a US-headquartered industrial manufacturer with USD 12 billion in revenue, reporting under SOX 404 as an SEC-listed accelerated filer (with both 404(a) management assessment and 404(b) auditor attestation), under the UK Bribery Act Section 7 through a UK subsidiary, and under EU AMLD6 and AMLA through an EU financial subsidiary subject to direct AMLA supervision. Each quarter the Agent processes 22 million transactions through continuous fraud detection, runs segregation-of-duties analysis on 18,000 user authorisations across 12 ERPs, performs journal entry analytics on 480,000 manual entries under AS 2401 management override testing, identifies related-party transactions under AS 2410, runs third-party due diligence on 4,800 vendors against Refinitiv World-Check, LexisNexis Risk Solutions and Dow Jones Risk and Compliance, monitors AML/BSA thresholds for FinCEN CTR and SAR filings, and drafts the UK Bribery Act Section 7 adequate procedures evidence, the EU AMLA compliance evidence, the CSRD ESRS G1 disclosure and the Section 302 and 906 management certifications.

In the [Decision Layer](/en/decision-layer/), 5 of the 16 steps are rule-based (R), 4 are human judgement (H) reflecting fraud detection reality, and 7 are LLM-suggestion (A) for phantom vendor analysis, posting anomaly detection, AI-generated fake invoice detection, round-tripping detection, third-party due diligence, aggregate risk scoring, plus disclosure drafting. There is no generative AI in fraud determination, escalation decision, management certification, or SAR/STR filing decision - the LLM never auto-determines compliance outcomes without human review acceptance.

## Material weakness classification for fraud-related deficiencies carries Item 9A disclosure and restatement risk

Fraud-related control deficiency severity classification under PCAOB AS 2201 paragraph A2-A8, AS 2401 and AICPA AU-C 940 establishes three categories with cascading disclosure consequences. A material weakness is the highest severity - a deficiency, or combination, such that there is a reasonable possibility a material misstatement will not be prevented or detected on a timely basis because of fraud - and it requires Item 9A SEC disclosure under SOX 404, a restatement assessment and an auditor adverse opinion on ICFR effectiveness. A significant deficiency is middle severity, requiring written audit committee communication. A control deficiency is the lowest severity, requiring internal communication only. The fraud-specific classification factors are magnitude (material under SAB 99 quantitative and qualitative considerations with an SEC fraud lens), likelihood (a reasonable possibility per AS 2201 paragraph A6-A7 and the AS 2401 fraud-risk presumption), the effectiveness of compensating controls (for example management override mitigated by audit committee oversight), prior-period fraud incidents and remediation history, integration with COSO 2013 Principle 8, and the management override testing results under AS 2401 paragraph 58-67. The Agent supports classification through documented severity criteria, fraud-deficiency aggregation, compensating control evaluation, rolling-baseline comparison and audit committee coordination evidence, preserved under PCAOB AS 1215 seven-year retention and SOX Section 802 records preservation.

## Integration ecosystem: AuditBoard, Diligent HighBond, SAS Fraud Management, NICE Actimize, FICO Falcon and Big-4 audit tools

The Agent integrates with the major fraud and AML platforms: [AuditBoard](https://www.auditboard.com/) for cloud-native SOX 404, ICFR and fraud risk management with PCAOB AS 2401 evidence templates; [Diligent HighBond](https://www.diligent.com/products/highbond) (formerly Galvanize ACL Robotics) for fraud risk monitoring, journal entry analytics and segregation of duties; [SAS Fraud Management](https://www.sas.com/en_us/software/fraud-management.html), SAS Anti-Money Laundering and SAS Visual Investigator for ML-based anomaly detection with network and link analysis; [NICE Actimize](https://www.niceactimize.com/) Xceed, SAM and CDD-X for AML transaction monitoring; [FICO Falcon Fraud Manager](https://www.fico.com/en/products/fico-falcon-platform) and FICO Siron AML; and AppZen Expense Audit and Mastermind. Sanctions, PEP and adverse-media screening run against Refinitiv World-Check One, LexisNexis Risk Solutions and Dow Jones Risk and Compliance with beneficial ownership data. Audit evidence loads into Deloitte Aura, PwC Halo, EY Helix and KPMG Clara, carrying PCAOB AS 2401 and AS 2410, AICPA AU-C 240 and ISA UK 240 templates with journal entry surveillance. Filing runs via SEC EDGAR for Form 10-K Item 9A and Form 10-Q Item 4, UK Companies House for Section 414CB and UK FRC Provision 29 (effective for fiscal years from 1 January 2026), and EU Member State portals for the CSRD ESRS G1 disclosures with iXBRL tagging under the SEC and ESEF requirements.

--- GoBD Compliance Agent ---
> German GoBD bookkeeping compliance: AO Paragraph 147 plus HGB Paragraph 257 retention (BEG IV 8 years), GoBD 2025 e-invoice XML/PDF archiving, procedural documentation, Z1/Z2/Z3 data access.

Missing or outdated procedural documentation is the most common formal deficiency that tax auditors flag. Organisations that cannot present current documentation during an audit risk tax-base estimations of up to ten percent of annual revenue on taxable profit. The problem is not a lack of knowledge - it is a lack of continuity.

## Procedural Documentation Ages Faster Than Any Compliance Team Can Maintain It

German GoBD (German record-keeping standard) bookkeeping principles require that every change to tax-relevant processes be documented - new software versions, modified posting logic, additional interfaces. In a typical Finance function with ERP, treasury, travel expense processing and bank connections, dozens of documentation-relevant changes arise each quarter. (US: the Sarbanes-Oxley Section 404 requirement for documented internal controls over financial reporting follows a similar logic. UK: HMRC's Making Tax Digital programme imposes comparable digital record-keeping obligations.)

The reality in most organisations: the procedural documentation was created once, sits as a PDF on a shared drive and has not been touched since the last audit. The actual processes have long since evolved. This gap between documented state and operational reality grows with every system update.

Since January 2025, Germany's Bureaucracy Relief Act IV has shortened the retention period for posting documents from ten to eight years. At the same time, GDPR requires deletion of personal data once the retention purpose expires. Deleting too early violates the fiscal code. Deleting too late violates GDPR. Without ongoing deadline monitoring, both are nearly unavoidable.

## Tax Auditors Use Formal Deficiencies as Leverage for Tax-Base Estimations

Since the tax authorities began using digital audit techniques, the focus of tax audits has shifted. Auditors increasingly request the procedural documentation first, before reviewing the actual posting data. The reason: formal documentation deficiencies are easier to prove than substantive errors in the books.

Missing log files documenting changes to posting processes and software versions already suffice under current case law as a basis for tax-base estimation. The auditor argues that without these records, the completeness and immutability of the bookkeeping cannot be verified. Safety surcharges of up to ten percent of revenue on taxable profit are not uncommon - for a mid-sized company with EUR 50 million (USD 54 million) in revenue, that can mean EUR 5 million in additional taxable income.

## The E-Invoice Mandate Tightens Archiving Requirements

Since 1 January 2025, all businesses in B2B transactions must be able to receive e-invoices. The German Federal Ministry of Finance published the second amendment to GoBD in July 2025, explicitly regulating the archiving of hybrid formats such as ZUGFeRD and Factur-X. The key change: for e-invoices, at least the structured XML portion must be archived. The human-readable PDF part is only additionally subject to retention if it contains deviating or tax-relevant supplementary information.

For audit-compliant bookkeeping, this means: every incoming invoice must be checked for format, the correct component archived, and immutability ensured via timestamp and hash value. This is a rule-based decision that cannot be performed reliably by hand at hundreds of invoices per week.

## A Rule-Based Agent Keeps Compliance Current Without Binding Staff Capacity

The Bookkeeping Compliance Agent operates predominantly at [Decision Layer](/en/decision-layer/) tier 1 - rule-based, following clear requirements from fiscal code, commercial code and GoBD bookkeeping principles. Archiving obligations, retention periods, immutability and data access follow defined audit logic. No discretion, no interpretation needed.

For procedural documentation, the agent steps up to tier 2: it compares documented processes with actually executed processes and proposes updates. A human reviews and approves. The overall assessment of compliance risks remains entirely with the human.

A concrete scenario: the ERP system receives an update that changes the posting logic for advance invoices. The agent detects the divergence between the documented and actual process, drafts the updated section of the procedural documentation and ensures the affected archiving rules are adjusted. The tax adviser or tax manager approves the change. The entire history - who changed what, when and why - is automatically logged. Precisely this logging is the first thing tax auditors request.

## Compliance Emerges as a By-Product, Not an Additional Burden

The real value lies not in automating individual checks but in the paradigm shift: audit-compliant bookkeeping is no longer established at the next tax audit but continuously assured. The procedural documentation is always current because it is automatically maintained with every process change. Deadlines are monitored before they expire. And when the tax auditor requests Z1, Z2 or Z3 data access, the answer is immediately available - not after three weeks of hectic preparation.

--- ICS Monitoring Agent ---
> Cross-jurisdictional ICFR pipeline: SOX 404 + 302 + 906, PCAOB AS 2201, COSO 2013, UK FRC Corporate Governance Code 2024, EU CSRD ESRS G1, ISO 31000, IIA 2024.

International ICFR monitoring runs against several cross-jurisdictional regimes at once. In the US, that means Sarbanes-Oxley Section 404(a) management assessment and 404(b) auditor attestation under the PCAOB AS 2201 integrated audit, plus the quarterly and annual Section 302 and 906 certifications and the COSO 2013 Internal Control Integrated Framework (17 principles, 87 points of focus) with COSO ERM 2017. In the UK, it means the FRC Corporate Governance Code 2024 Provision 29 board declaration on internal control effectiveness, effective for fiscal years from 1 January 2026. In the EU, it means the CSRD ESRS G1 Business Conduct disclosure, with mandatory limited assurance moving to reasonable assurance by 2028. Across all three, the IIA Global Internal Audit Standards 2024 and the Three Lines Model apply. A US-headquartered multinational with EU subsidiaries, a UK premium-listed entity preparing for the Provision 29 declaration, and an SEC accelerated filer needing both 404(a) and 404(b) must run these determinations in parallel while applying four judgement-intensive decisions: SOX 404 scope identification (significant accounts, disclosures, assertions and locations under PCAOB AS 2201 paragraph 10-12 and AS 2110), control deficiency severity classification under AS 2201 paragraph A2-A8, the UK FRC Provision 29 board declaration across financial, operational, compliance and reporting controls, and finalisation of the Section 302, 404 and 906 management certification package. Over this sit PCAOB deficiency rates of 25-30 percent on ICFR substantive testing across Big-4 firms, SEC restatement enforcement targeting material weakness disclosures, UK FRC Audit Quality Review and Sanctions Tribunal action against firms and individual auditors, and EU ESMA enforcement priorities on ESRS G1 disclosure quality.

## SOX 404, UK FRC Provision 29 and EU CSRD ESRS G1 all trigger Big-4 substantive testing

PCAOB Inspection Reports consistently identify 25-30 percent deficiency rates on ICFR substantive testing across Big-4 firms, with material weakness identification and auditor attestation deficiencies a recurring theme. SEC restatement enforcement under an Item 9A material weakness disclosure typically produces a multi-year SEC Division of Corporation Finance review and class-action plaintiff exposure. UK FRC Corporate Governance Code 2024 Provision 29, effective for fiscal years from 1 January 2026, introduces a new board declaration on internal control effectiveness across financial, operational, compliance and reporting controls - a material expansion from prior provisions. EU CSRD ESRS G1 Business Conduct, effective for fiscal years from 1 January 2024 with mandatory limited assurance moving to reasonable assurance by 2028 and an ESMA enforcement priority since 2025, requires structured corporate-conduct reporting subject to substantive scrutiny. For SEC-registered multinationals, UK premium-listed entities and EU CSRD-scoped entities, a single ICFR failure compounds into an Item 9A material weakness disclosure under SOX 404, a FIN 48 or IFRIC 23 uncertain-position disclosure under ASC 740-10 and IAS 12, a Big-4 auditor concurrence challenge under PCAOB AS 2201 and AS 2401, an SEC comment letter and a class-action lawsuit - a cumulative downside that typically exceeds USD 50 million for material enforcement actions.

## The international ICFR continuous monitoring pipeline runs 15 deterministic and judgement-supported steps

Spanning SOX 404, UK FRC Provision 29, EU CSRD ESRS G1 and IIA Standards 2024 takes 15 steps because every ICFR cycle has to cover SOX 404 scope identification (significant accounts, disclosures, assertions and locations under PCAOB AS 2201 and AS 2110), COSO 2013 five-component mapping across 17 principles and 87 points of focus, control activity testing for design and operating effectiveness under AS 2201, segregation-of-duties analysis across procure-to-pay, order-to-cash, record-to-report and hire-to-retire, IT general controls testing under AS 2201 paragraph 36 across access management, change management and IT operations, continuous transaction monitoring with statistical and machine-learning anomaly detection, journal entry analytics under AS 2401 management override testing, related-party identification under AS 2410, control deficiency severity classification under AS 2201 paragraph A2-A8, UK FRC Provision 29 board declaration evidence, EU CSRD ESRS G1 disclosure drafting, IIA Standards 2024 risk-based audit planning, the Section 302, 404 and 906 management certification package, remediation tracking under AS 2201 paragraph 71, and disclosure submission for Form 10-K Item 9A, Form 10-Q Item 4, UK Section 414CB and EU CSRD ESRS G1.

Consider a US-headquartered industrial manufacturer with USD 12 billion in revenue, reporting under SOX 404 as an SEC-listed accelerated filer (with both 404(a) management assessment and 404(b) auditor attestation), under UK FRC Provision 29 through a premium-listed UK subsidiary for fiscal years from 1 January 2026, and under CSRD ESRS G1 through an EU subsidiary. It runs 4,200 in-scope key controls: 1,600 control activities (four-eyes, approvals, reconciliations and segregation), 800 IT general controls (access management, change management and IT operations) and 1,800 entity-level controls (control environment, risk assessment, information and communication, and monitoring activities). Each quarter the Agent processes 22 million transactions through continuous control activity testing, runs segregation-of-duties analysis on 18,000 user authorisations across 12 ERPs, performs journal entry analytics on 480,000 manual entries under AS 2401 management override testing, identifies related-party transactions under AS 2410, classifies deficiency severity under AS 2201 paragraph A2-A8, and drafts the UK FRC Provision 29 board declaration evidence, the CSRD ESRS G1 disclosure and the Section 302 and 906 management certifications.

In the [Decision Layer](/en/decision-layer/), 6 of the 15 steps are rule-based (R), 4 are human judgement (H) reflecting audit reality, and 5 are LLM-suggestion (A) for transaction anomaly detection, journal entry analytics under AS 2401, related-party transaction identification under AS 2410, ESRS G1 disclosure drafting, plus IIA Standards 2024 risk-based audit planning. There is no generative AI in deficiency severity classification, scope determination, board declaration, or management certification - the LLM never auto-determines compliance outcomes without human review acceptance.

## Material weakness classification carries Item 9A disclosure and restatement risk

Control deficiency severity classification under PCAOB AS 2201 paragraph A2-A8 and AICPA AU-C 940 establishes three categories with cascading disclosure consequences. A material weakness is the highest severity - a deficiency, or combination, such that there is a reasonable possibility a material misstatement will not be prevented or detected on a timely basis - and it requires Item 9A SEC disclosure under SOX 404, a restatement assessment and an auditor adverse opinion on ICFR effectiveness. A significant deficiency is middle severity, less severe than a material weakness but important enough to merit oversight attention, and requires written audit committee communication under AS 2201. A control deficiency is the lowest severity, requiring internal communication only. The classification factors are magnitude (material under SAB 99 quantitative and qualitative considerations), likelihood (a reasonable possibility per AS 2201 paragraph A6-A7), the effectiveness of compensating controls, prior-period remediation history, and aggregation analysis across deficiencies. The Agent supports classification through documented severity criteria, deficiency aggregation, compensating control evaluation, rolling-baseline comparison and audit committee coordination evidence, preserved under PCAOB AS 1215 seven-year retention. PCAOB 2024 inspection findings consistently identify deficiency severity classification as a focus area, with management and external auditor disagreements a recurring theme.

## Management override testing and related-party identification turn the fraud-risk presumption into a deterministic engine

PCAOB AS 2401 paragraph 58-67 management override testing and AS 2410 related-party identification address the fraud-risk presumption through substantive procedures: journal entry analytics, related-party disclosure assessment and revenue recognition fraud risk. Typical fraud patterns include round-amount entries without commercial justification, simple offsetting entries between unrelated balance sheet accounts, entries posted by unusual users, entries near period close, entries to seldom-used accounts, manual descriptions matching fraud patterns (suspense, rounding, adjustments, accruals, reserves and top-side consolidation entries) and round-trip transactions with the same counterparty. The Agent's three-phase analytics extracts the complete journal entry population from ERP audit logs (SAP BKPF and BSEG, Oracle journal entries, Workday journal source data), applies LLM and statistical pattern matching with confidence scoring, and routes flagged entries to internal and external audit. Related-party identification under AS 2410, IAS 24 and ASC 850 covers parent, subsidiary and sister-company transfers, equity-method investee transactions, key management compensation, joint venture partner transactions and immediate family member entities, detected through vendor master, customer master and chart-of-accounts patterns with beneficial ownership extraction. This is critical for reducing SEC restatement risk, for AS 2401 substantive testing evidence and for audit committee reporting under 8th Company Law Directive Article 39.

## Integration ecosystem: AuditBoard, Workiva, ServiceNow GRC, LogicGate, SAP GRC, Oracle Risk Management Cloud and Big-4 audit tools

The Agent integrates with the major GRC platforms: [AuditBoard](https://www.auditboard.com/) for cloud-native SOX 404 and ICFR with a control library, testing workflow, deficiency tracking and PCAOB AS 2201 and AS 2110 evidence templates; [Workiva](https://www.workiva.com/) for cloud-native disclosure management and financial reporting with SOX 404, CSRD ESRS, iXBRL tagging and ESEF compliance; [ServiceNow GRC](https://www.servicenow.com/products/governance-risk-and-compliance.html) and IRM for enterprise GRC with policy, risk, compliance and audit management; [LogicGate Risk Cloud](https://www.logicgate.com/) for no-code cloud GRC with SOX 404, ISO 31000 and ISO 37301 support; SAP GRC (Process Control, Risk Management, Audit Management and Access Control) for SAP-native integration with SAP S/4HANA Finance; and Oracle Risk Management Cloud and Oracle Advanced Controls for Oracle Fusion Cloud. Internal audit management runs on TeamMate+, AutoAudit, Diligent HighBond or AuditBoard, with risk-based audit planning, working paper management and audit issue tracking. Disclosure management runs on Workiva, Certent CDM, CCH Tagetik or the OneStream MarketPlace SOX Application, with an audit-ready evidence trail and a disclosure committee workflow. Audit evidence loads into Deloitte ConnectMe, PwC Aura, EY Canvas and KPMG Clara, carrying PCAOB AS 1215 metadata with continuous audit capability and journal entry surveillance under AS 2401. Filing runs via SEC EDGAR for Form 10-K Item 9A and Form 10-Q Item 4, UK Companies House for the Section 414CB strategic report and Section 414CZA Section 172 statement, and EU Member State portals for the CSRD ESRS G1 disclosures (Bundesanzeiger, INPI, Registro Mercantil) with iXBRL tagging under the SEC and ESEF requirements.

--- Intercompany Agent ---
> International intercompany reconciliation and transfer pricing: OECD TPG 2022, BEPS Action 13 CbCR, IRC Section 482, UK TIOPA 2010, Pillar Two GloBE, IAS 24.

International intercompany reconciliation and transfer pricing sits within an interlocking regulatory regime that spans seven major frameworks. The OECD Transfer Pricing Guidelines 2022 set the Chapter V three-tier documentation (Master File, Local File and Country-by-Country Report). IRC Section 482, the Treasury Regulations and IRC 6662(e) penalty protection apply to US-controlled groups; UK TIOPA 2010 Part 4 and the Diverted Profits Tax apply to UK-listed entities; ATAD I and II and DAC6 reportable cross-border arrangements apply to EU operations. IFRS (chiefly IFRS 10, 11 and 12, IAS 24 and IAS 21) applies to IFRS-reporting groups, US GAAP (chiefly ASC 810, 850 and 830) applies to US GAAP-reporting groups, and the OECD Pillar Two GloBE Rules apply to groups above EUR 750 million in consolidated revenue. A multinational operating across the UK, EU and US must coordinate reciprocal AR/AP matching, FX translation isolation, arm's length verification, Master File and Local File documentation, CbCR aggregation, the Pillar Two ETR computation, IFRS 9 expected credit loss on intercompany loans, consolidation eliminations, related party disclosures, DAC6 hallmark assessment and Schedule UTP support, all with a full audit trail to support SOX 404, UK FRC Provision 29, Big-4 PCAOB AS 2410 substantive testing and OECD MAP and APA proceedings.

## Five regulatory pressure points where intercompany cannot run on a spreadsheet

OECD Transfer Pricing Guidelines 2022 Chapter V mandates the three-tier documentation framework adopted in more than 90 jurisdictions through BEPS Action 13: a Master File covering group-level organisational structure, business description, intangibles, intercompany financial activities and financial and tax positions per Annex I; a Local File covering jurisdiction-specific entity description, controlled transactions and financial information per Annex II; and a Country-by-Country Report for groups with consolidated revenue above the EUR 750 million OECD threshold. Well-known transfer pricing adjustments show the scale of exposure: Coca-Cola (a USD 9.4 billion IRS adjustment, Tax Court 2020-2024), Medtronic (a USD 1.4 billion IRS adjustment over multi-year litigation), Glencore (a GBP 1.2 billion HMRC settlement in 2020) and Apple (the EUR 14.3 billion EU State Aid case, CJEU 2024). The Big-4 Global Transfer Pricing Survey 2024 found 67 percent of multinationals cite Master File and Local File inconsistency as their top documentation pain point, typically triggering 25-40 percent IRC 6662(e) penalty exposure on adjustments.

UK TIOPA 2010 Part 4 and the Diverted Profits Tax under Finance Act 2015 Sections 80-94 impose a 25 percent DPT rate on diverted profits, with HMRC enforcement through Code of Practice 9 enquiries and the Profit Diversion Compliance Facility voluntary disclosure regime. The UK Master File, Local File and CbCR requirements apply for accounting periods commencing on or after 1 April 2023, aligning UK practice with EU and US documentation standards. UK FRC Provision 29, effective 1 January 2026, introduces a FTSE 350 board declaration of ICFR effectiveness, pulling intercompany controls and transfer pricing documentation into board attestation scope alongside the US SOX 404 obligations.

The OECD Pillar Two GloBE Rules, effective from 1 January 2024 across the EU, UK, South Korea, Japan, Switzerland and Canada, require an Income Inclusion Rule computation of the jurisdictional Effective Tax Rate against a 15 percent minimum threshold. Where the ETR falls below 15 percent, top-up tax applies through the Qualified Domestic Minimum Top-up Tax collected by the source jurisdiction, the IIR collected by the ultimate parent jurisdiction, or the Undertaxed Profits Rule as a backstop. The Transitional CbCR Safe Harbour through fiscal year 2026 simplifies the analysis. US implementation is partial: the 15 percent Corporate Alternative Minimum Tax is distinct from QDMTT and creates interplay complexity with the GILTI, BEAT and FDII regimes.

## 15 deterministic decision points with three ML-assisted escalations

The agent processes intercompany reconciliation through a pipeline of 15 decision points: twelve deterministic operations covering legal entity register reconciliation, reciprocal AR/AP matching, FX translation isolation, timing classification, BEPS Action 13 documentation generation, CbCR aggregation, Pillar Two ETR computation, consolidation elimination generation, related party disclosure preparation, Schedule UTP support and audit trail generation; plus three ML-assisted escalations. The first is OECD TPG most appropriate method selection (CUP, Resale Price, Cost Plus, TNMM or Profit Split, with Bureau van Dijk Orbis, S&P Capital IQ and Royaltystat comparables); the second is IFRS 9 expected credit loss on intercompany loans (12-month and lifetime ECL based on the borrower entity's standalone creditworthiness); the third is DAC6 hallmark detection (hallmarks A through E across cross-border EU arrangements). Reciprocal matching runs at original transaction currency before FX translation under IAS 21 and ASC 830, to keep currency volatility from contaminating the equality testing, and timing differences are classified deterministically against the monthly close lag with subsequent-period clearing tracking.

Concrete example: international group (US headquarters with UK and EU subsidiaries plus emerging markets entities, USD 12 billion consolidated revenue, 42,000 employees, listed on NYSE with secondary listing on LSE, 38 legal entities across 22 tax jurisdictions). Q3 2026 quarterly close: 287 active intercompany counterparty pairs identified from legal entity register reconciliation; 264 pairs reconcile bilaterally on first pass with reciprocal AR/AP matching at original currency. 23 pairs flagged: 14 timing differences (subsequent-period clearing within close lag), 6 FX translation differences (isolated to OCI per IAS 21.32), 3 transfer pricing variances flagged for OECD TPG arm's length verification. TP analysis: tested party EMEA distribution entity with TNMM operating margin 3.2 percent versus interquartile range of 2.8-5.4 percent on 18 comparables - within arm's length range, no adjustment required. CbCR aggregation: 22 jurisdictional rows with revenue, profit before tax, taxes accrued/paid, stated capital, accumulated earnings, employees, tangible assets - reconciled to audited consolidated financial statements. Pillar Two GloBE ETR: 22 jurisdictions tested, 18 above 15 percent (including Transitional CbCR Safe Harbour exemption for 12), 4 jurisdictions with ETR between 12.4 and 14.8 percent triggering top-up tax computation - QDMTT applicable in 2 source jurisdictions, IIR in 2. Total Pillar Two top-up tax: USD 18.6 million. IFRS 9 expected credit loss on intercompany loans: 12-month ECL allowance USD 2.1 million across 14 intercompany loan facilities. Consolidation elimination entries generated automatically: USD 1.42 billion gross intercompany revenue and expense, USD 387 million reciprocal AR/AP, USD 124 million unrealised inventory profit deferred. Total reconciliation cycle: 4 hours versus typical 5 working days.

## Reciprocal AR/AP matching - bilateral mirror at original currency

The reciprocal matching of intercompany AR and AP balances is the foundation of intercompany reconciliation and the primary substantive testing focus under PCAOB AS 2410. The agent performs a deterministic equality check at original transaction currency before FX translation - critical because currency conversion introduces variance that is not a control deficiency. IFRS 10.B86(c) and ASC 810-10-45-1 require complete elimination of reciprocal balances, and bilateral confirmation is mandatory under Big-4 substantive testing. Where balances diverge after currency-level matching, the agent sorts them into three categories: timing (date-based and deterministic), FX translation (isolated to OCI under IAS 21 and ASC 830), or unexplained variance (escalated to the controller for investigation). Timing ageing buckets are tracked as standard in OneStream, BlackLine Intercompany Hub and Trintech Cadency.

## OECD TPG arm's length verification - five method framework with comparables analysis

OECD Transfer Pricing Guidelines 2022 Chapter II mandates the most appropriate method from five alternatives: the Comparable Uncontrolled Price, preferred where reliable comparables exist; the Resale Price Method for distribution entities; the Cost Plus Method for routine manufacturing or services; the Transactional Net Margin Method, most commonly applied for intangibles-light entities; and the Profit Split Method for highly integrated operations or unique intangibles. IRC Section 482 imposes a parallel best method rule for US-controlled groups. The agent supports a comparables search across Bureau van Dijk Orbis, S&P Capital IQ, Royaltystat and Aibidia, with ML-assisted filtering flagging entities that match the tested party's industry, function profile, geographic market and size; the final method selection and benchmark range remain expert judgement under Big-4 controversy practice. Documentation under IRC 6662(e)(3) provides 20 percent penalty protection (40 percent under 6662(h) for gross valuation misstatement), and auto-populated Master File and Local File templates cut drafting from 4-6 months to 4-6 weeks under [Decision Layer](/en/decision-layer/) governance.

## Pillar Two GloBE ETR computation - jurisdictional minimum tax with top-up tax tracing

The OECD Pillar Two GloBE Rules, effective from 1 January 2024, represent the most significant international tax reform in a generation. The agent computes the jurisdictional Effective Tax Rate under Article 5.1, identifying jurisdictions where the ETR falls below the 15 percent minimum and computing the top-up tax. Three collection mechanisms apply: the Qualified Domestic Minimum Top-up Tax collected by the source jurisdiction, the Income Inclusion Rule collected by the ultimate parent jurisdiction, or the Undertaxed Profits Rule as a backstop. The Transitional CbCR Safe Harbour through fiscal year 2026 reduces the compliance burden where the simplified ETR exceeds 15 percent or the jurisdiction's profit margin is below 1 percent. A Big-4 Pillar Two implementation typically takes 6-12 months and costs EUR 800,000 to EUR 4 million; the agent supports SAP S/4HANA Tax Compliance, OneStream Pillar Two, Tagetik and the Thomson Reuters ONESOURCE BEPS Action Manager.

## Integration with SAP S/4HANA Group Reporting, OneStream, BlackLine, Workiva and Thomson Reuters ONESOURCE

The agent integrates with all major intercompany and tax platforms via API: [SAP S/4HANA Group Reporting](https://www.sap.com/products/financial-management/group-reporting.html) with SAP Profitability and Performance Management, SAP Tax Compliance and SAP BPC (the DAX 40 and EuroStoxx 50 default); [OneStream Software](https://www.onestream.com/) (a unified platform with native intercompany matching, eliminations and Pillar Two reporting); [BlackLine Intercompany Hub](https://www.blackline.com/products/intercompany-hub/) with BlackLine Account Reconciliations and Transaction Matching (the S&P 500 and FTSE 350 standard for IC reconciliation); Trintech Cadency; [Workiva Wdesk](https://www.workiva.com/) (CbCR, Master File and Local File documentation and SOX 404 evidence); Oracle Financial Consolidation and Close with Oracle Tax Reporting Cloud; IBM Cognos Controller and Planning Analytics; Tagetik with its Pillar Two module; the [Thomson Reuters ONESOURCE Transfer Pricing](https://tax.thomsonreuters.com/en/onesource/transfer-pricing), BEPS Action Manager and Operational TP suite; Aibidia; and Longview Tax with CCH Integrator. ERP integration runs over SAP S/4HANA RFC and OData, Oracle Cloud REST, Workday SOAP and REST, Microsoft D365 Dataverse and NetSuite SuiteScript, and the comparables databases (Bureau van Dijk Orbis, S&P Capital IQ, Royaltystat) connect by API with quarterly refresh. Big-4 substantive testing exports directly to Deloitte ASM, PwC Halo, EY Helix and KPMG Clara, carrying PCAOB AS 2410, AICPA AU-C 550, IRS LB&I and HMRC Code of Practice 9 audit-trail metadata in WORM immutable storage with eIDAS QSEAL and QWAC certificate timestamps and a SOX 404 and UK FRC Provision 29 evidence repository.

--- Invoice Approval Agent ---
> Determines the correct approver per approval matrix, checks budgets and vendor blocks, validates payment terms and escalates overdue approvals.

Every invoice approved a day too late is a missed decision. Not because someone forgot about it, but because routing to the right approver is, in most companies, a manual process - dependent on knowledge in individual heads, not clear rules in a system. The Invoice Approval Agent turns this bottleneck into a predictable track.

## Late approvals silently destroy early payment discounts

A typical early payment discount window is ten days. Ten days in which an invoice must be captured, verified, assigned, approved and released for payment. A Nanonets analysis puts the average invoice processing time at 9.2 days - and that is the average. For companies without structured approval processes, the figure rises above 17 days (Nanonets, 2025).

The result: on a purchasing volume of EUR 50 million (USD 54 million) and a 2% early payment discount on half of the invoices, EUR 500,000 (USD 540,000) is left on the table every year - not because the terms are missing, but because the approval process is too slow. The money does not disappear in a single incident. It leaks out through hundreds of individual cases that no one aggregates.

## The approval matrix is a rule set, not a judgement call

The question "Who may approve this invoice?" sounds like judgement. In practice it is the opposite. The answer follows a fixed combination of amount thresholds, cost centre, project and vendor. A rule set that, in most ERP systems, is already configured - but applied manually.

The agent takes over exactly this routing. It reads the approval matrix, assigns the invoice to the responsible approver, and in parallel checks whether budget is available on the cost centre and whether the vendor is blocked. Three decisions that together take less than a second - and in manual processes often consume hours or days because they are spread across different systems and inboxes.

[Decision Layer](/en/decision-layer/) stage 1: all three checks follow deterministic rules. There is no room for interpretation, no grey zone, no exception that cannot be defined in advance.

## Escalation logic protects deadlines before they expire

The most common problem in invoice approval is not the wrong decision. It is no decision at all. An invoice sits in the inbox of the responsible approver, who is in a meeting, on a business trip, or simply overloaded.

The agent monitors every open approval against configured deadlines. When an early payment discount deadline approaches, it escalates to the defined deputy - not after three reminder emails, but by a clear rule: if approval has not happened within X hours, route to hierarchy level Y.

A concrete scenario: a supplier issues an invoice for EUR 85,000 (USD 92,000) on Tuesday with 2% discount for payment within ten days. The responsible department head is at a conference until Friday. The agent detects the absence, routes to the deputy, and approval happens on Wednesday. Without escalation logic, the invoice would not be processed until the following Monday - four days after the discount deadline expired. EUR 1,700 (USD 1,840) lost on a single transaction.

## Batch approval accelerates the standard case

Not every invoice deserves individual attention. Recurring invoices from the same vendor, for the same amount, on the same cost centre - they follow a pattern the agent recognises. These cases qualify for batch approval: the approver gets a bundled overview instead of individual items.

This does more than relieve approvers. It changes the capacity distribution across the entire accounts payable process. HighRadius data shows best-in-class AP teams processing invoices in an average of 3.1 days, compared to 17.4 days for teams without structured processes (HighRadius, 2025). Batch approval is one of the levers that explains this gap.

## The human decides where rules are not enough

Six of seven decision steps in invoice approval are fully rule-based. The seventh is not: approval despite budget overrun.

When an invoice exceeds the available cost centre budget, no algorithm can decide whether the expense is still justified. Maybe the budget is stale. Maybe a supplementary order was agreed verbally. Maybe the delivery is business-critical and the budget process is lagging reality.

Decision Layer stage 2: the agent supplies the decision-maker with all the facts - invoice amount, remaining budget, spend to date on the cost centre, vendor history - and holds the decision open. No suggestion, no recommendation, only a structured decision brief. Responsibility stays with the human, but preparation takes seconds instead of hours.

--- Invoice Capture Agent ---
> Receives invoices in PEPPOL BIS 3.0, UK MTD, XRechnung, ZUGFeRD, and PDF formats. Validates EN 16931 schema, applies SOX 404 controls, archives per IRS / HMRC retention rules. Output: ERP posting (SAP, Oracle, Workday, Sage Intacct).

Invoice processing remains one of the largest cost centers in international finance operations. A typical multinational enterprise receiving 10,000 invoices per month allocates 3-5 full-time equivalents to opening documents, keying data, validating mandatory fields, and chasing exceptions. The Ardent Partners 2024 State of ePayables benchmark puts best-in-class cost at USD 2.78 per invoice versus an industry average of USD 12.88 - that gap represents 78% of process cost still on the table for most CFOs. Meanwhile EU's e-invoicing mandate cascade (PEPPOL BIS 3.0, XRechnung Pflicht 2025-2028 in Germany, KSeF mandatory 1 July 2026 in Poland, Verifactu phased 2025-2026 in Spain, FacturaE-only in Spanish public sector since 2015), UK's Making Tax Digital for VAT, and US SOX 404 audit testing pressure all converge on the same operational fact: manual AP no longer scales.

## Manual AP costs $12.88 per invoice - benchmark gap to best-in-class is 78%

Ardent Partners' annual State of ePayables benchmark surveys 500+ AP organisations globally. The 2024 edition shows a stark performance distribution: best-in-class organisations process invoices at USD 2.78 fully-loaded cost, while the industry average sits at USD 12.88. Multiplied across a 10,000-invoice monthly run, that gap represents USD 1.21 million per year in unnecessary process cost - before accounting for late-payment penalties, missed early-payment discounts, or audit findings.

For SOX-listed US companies the cost penalty compounds: PCAOB inspections increasingly target AP control failures as material weaknesses, and a single material weakness disclosure typically erodes 4-7% of share price in the trading week following the 10-K filing. UK-domiciled entities face HMRC penalties for late VAT submission of GBP 200 plus 2-15% of unpaid tax depending on persistence. EU operators dealing with cross-border B2B miss PEPPOL deadlines and find themselves blocked from public sector contracting (EU Directive 2014/55/EU is fully in force).

## E-invoicing mandates are converging - and the Agent handles all of them

The European Commission's ViDA (VAT in the Digital Age) initiative, adopted in 2025, mandates real-time digital reporting for cross-border B2B transactions in the EU from 1 July 2030. Member states are racing ahead: Italy's SDI (Sistema di Interscambio) since 2019, France's Chorus Pro since 2020, Germany's XRechnung since November 2020 (B2G) with B2B receipt mandate from 1 January 2025 and full B2B sending mandate by 1 January 2028, Spain's phased Verifactu system 2025-2026, Poland's KSeF effective 1 July 2026. The UK's Making Tax Digital for VAT has been mandatory since April 2019 and is the de-facto digital baseline for UK accounting software.

The Agent is built around the EN 16931 European semantic model. PEPPOL BIS Billing 3.0, XRechnung 3.0, ZUGFeRD 2.3, FacturaE 3.2.2 - all are CIUS or extensions of EN 16931, so the same validation engine handles all of them. For UK MTD, the Agent normalises to the same internal model and pushes VAT-relevant fields to HMRC-compatible accounting platforms (Xero, QuickBooks Online, FreshBooks, Sage Business Cloud). For US-only companies on Sage Intacct or NetSuite, the Agent runs the same validation logic and produces ERP-native posting records without the e-invoicing layer.

## SOX 404 controls are the unique pain for US-listed multinationals

For SEC-listed companies and their EU subsidiaries (e.g., German Mittelstand acquired by US PE firms, UK FTSE 250 with US ADR listings), SOX 404 imposes audit-testable controls on every key process - including AP. The Agent enforces SoD (segregation of duties) at the workflow layer: same user cannot submit AND approve invoices above the configurable cost-center threshold. Every decision is logged with submitter ID, approver ID, timestamp, role, IP address, and decision rationale. This Decision Log feeds directly into the SOX 404 controls testing pack used by Big-4 auditors during interim and year-end testing.

Practical impact: a German Mittelstand subsidiary of a US Russell-3000 parent processing 4,500 invoices monthly historically required 50-80 hours of audit testing time per year for AP controls alone. With the Agent's automated Decision Log, controls testing time drops to 8-15 hours - the auditor traces any invoice from receipt to GL posting in under 30 seconds, with full evidence chain pre-assembled.

## Multi-jurisdiction operations: most-stringent retention rule wins

For an enterprise operating across EU + UK + US, the Agent applies the most-stringent retention rule globally: 10 years (EU VAT Directive Art. 246) covers most cases, except where German GoBD (8 years per AO §147 + BEG IV) or US IRS Sec. 1.6001-1 (7 years) might require shorter or longer specifically. Default storage is 10 years on WORM (Write Once Read Many) infrastructure - Amazon S3 Object Lock, Azure Blob Immutable Storage, or compliant on-prem solutions. PII handling follows GDPR Art. 6(1)(c) (legal obligation as basis), UK GDPR equivalent post-Brexit, and US sectoral laws where they apply (SOX, GLBA for financial institutions, HIPAA for healthcare).

## Integration ecosystem: SAP, Oracle, Workday, Sage Intacct, plus PEPPOL Access Point

The Agent connects to the major international ERPs via native APIs: [SAP S/4HANA Cloud](https://www.sap.com/products/erp/s4hana.html) (Public + Private Edition) via OData and IDOC INVOIC02, [Oracle Fusion Cloud Financials](https://www.oracle.com/erp/financials/) via REST API, [Workday Financials](https://www.workday.com/en-us/products/financial-management/) via WSDL/SOAP, [Sage Intacct](https://www.sage.com/en-us/products/sage-intacct/) via REST, Microsoft Dynamics 365 Finance via OData. For PEPPOL routing, the Agent connects to a certified PEPPOL Access Point (e.g., Pagero, Tungsten, Basware) for EU cross-border invoice exchange. For multi-country groups with parent in US (NYSE/NASDAQ-listed) and subsidiaries in DE/PL/ES/BR, the Agent generates parallel reports: country-specific tax filings (UStVA Germany, JPK Poland, SII Spain, SPED Brazil) plus IFRS / US GAAP consolidation reporting. The same invoice posts once at the local level and feeds upward through the group consolidation hierarchy with an audit trail across all jurisdictions.

--- Invoice Generation Agent ---
> Creates outgoing invoices from service data, determines VAT rates, selects the e-invoice format.

Invoice generation ties up capacity that is missing elsewhere in the finance function. At the same time, regulatory pressure is rising with the European e-invoicing mandate. The Invoice Generation Agent solves both: it generates outgoing invoices entirely rule-based - with no AI component, no manual intervention, and gap-free audit compliance from the first document.

## Faulty invoices cost more than rework alone

A substantial share of all manually generated invoices contain errors. Correcting a single faulty document costs into the double-digit USD range when personnel effort, system corrections and payment delays are included. For a company processing 500 outgoing invoices per month, that adds up to a four-digit euro correction effort - every month, before the actual damage from delayed incoming payments is even considered.

Errors in outgoing invoices are rarely random. Wrong VAT (US: sales tax equivalent) rates on intra-community deliveries, missing mandatory fields under VAT law, inconsistent payment terms - these are systematic weaknesses that keep emerging from the same manual process. And that same systematic nature is what makes them solvable with rules.

## The European e-invoicing mandate sharpens the pressure

Since 1 January 2025, every company in Germany must be able to receive e-invoices in B2B traffic. The transition period for sending runs out at the end of 2026. After that, every outgoing invoice must exist as a structured data record in XRechnung or ZUGFeRD format - not as a PDF, not as a scan.

Behind this mandate sits a concrete goal of European governments: closing the VAT gap, which in Germany alone is estimated at EUR 22 billion (USD 24 billion) (source: DATEV Magazin / EU Commission). For finance functions this means a format shift that reaches far beyond invoice creation. Every document must be machine-readable, the mandatory fields must exactly match the schema, and the chosen format must remain configurable per customer.

Anyone managing this shift manually builds new error sources into an already error-prone process. Anyone who automates it eliminates the format problem as a decision point.

## Eight decision steps replace the manual process

A concrete scenario: a project services provider issues 400 outgoing invoices per month to customers in Germany, the EU and Switzerland. Until now, a clerk has been checking the VAT rate, adding mandatory fields, selecting the format and assigning the invoice number manually for every document.

The [Decision Layer](/en/decision-layer/) breaks this process into eight deterministic steps. Service data is retrieved from the source system. Mandatory fields under VAT law are assembled automatically. The VAT rate is derived from customer location and service type - 19% domestic, intra-community exempt, third country without VAT. The e-invoice format comes from customer master data. Payment terms come from the contract. The invoice number is assigned atomically - no gaps, no duplicates. Dispatch and archiving happen simultaneously.

All eight steps are rule-based. No step requires an assessment, a trade-off or a forecast. That is why the AI share is exactly zero percent - and the readiness 89 to 96 points, the highest score in the entire catalog.

## Audit compliance emerges in the process, not in retrospective review

German GoBD (German record-keeping standard) bookkeeping principles require three things from every outgoing invoice: gap-free number assignment, immutable archiving and full traceability. In manual processes, these requirements are typically enforced through downstream controls - a review at month-end, a reconciliation of number ranges, a manual archiving run.

The Invoice Generation Agent inverts this logic. Number assignment is atomically integrated into the creation process. Archiving happens at the same time as dispatch, not afterwards. And every decision - which tax rate, which format, which dispatch channel - is logged with timestamp and rationale. At a tax audit, the full decision path is available for every individual document.

For CFOs this means: audit compliance is no longer an audit risk but a system property. Decision Layer stage 1 - pure rule set - makes outgoing invoicing the most reliable process in the entire accounts receivable function.

--- Journal Entry Agent ---
> Drives sub-ledger balances to a signed, audit-ready period-end close, deterministic under SOX 404, IAS 8 and ASC 250.

Period-end close at a multinational does not run on one accounting framework - it runs on three operating in parallel. A US-listed parent with European subsidiaries reports IFRS to its European statutory authorities, US GAAP to the SEC for consolidation, and UK FRS 102 (or FRS 101) for any UK entity below the IFRS threshold. Each framework has different revenue recognition rules (IFRS 15 versus ASC 606 with contract-cost capitalisation differences and disclosure carve-outs), different lease accounting (IFRS 16 single-model lessee versus ASC 842 retaining the operating-finance distinction), different financial instrument provisioning (IFRS 9 ECL stages versus ASC 326 CECL day-one), and different prior-period error correction regimes (IAS 8 retrospective restatement with disclosure versus ASC 250 plus an Item 4.02 Form 8-K within 4 business days for SEC registrants). Layer over this the SOX 404 internal controls regime with PCAOB AS 2201 design and operating-effectiveness testing, AS 2401 mandatory journal entry fraud-risk testing, and the ISA 320 materiality framework for non-issuer audits in jurisdictions outside SEC scope, and the close becomes a coordination problem that no single accountant can run consistently at month-end velocity.

## SOX 404 material-weakness disclosure on JE controls erodes 4-7% of share price - PCAOB inspections cite manual top-side entries as the most-tested fraud-risk indicator

Manual journal entries are the highest-risk component of the financial close. PCAOB AS 2401 (Consideration of Fraud in a Financial Statement Audit) and AICPA AU-C 240 explicitly require auditors to test entries with unusual characteristics, unusual preparers, period-end timing, and top-side consolidation booking. The reason is empirical: virtually every major financial fraud case in the last twenty-five years - WorldCom USD 11B in 2002, HealthSouth USD 2.7B in 2003, Enron through special-purpose entities, Wirecard EUR 1.9B in 2020 - involved manual top-side entries that bypassed sub-ledger controls. PCAOB inspection findings cite JE controls among the top-3 most common Big-4 audit deficiencies year after year, with the dominant pattern being insufficient evidence of the four-eyes review (a digital sign-off without documented review scope counts as an operating-effectiveness gap under PCAOB AS 2201).

A material-weakness disclosure under SOX 404 typically erodes 4-7% of share price in the trading week following the 10-K filing - for a Russell-3000 mid-cap with USD 800M market cap, a 5% impact equals USD 40M of shareholder value destroyed by a JE controls failure that an automated Decision Log would have prevented. Add the audit-fee uplift (Big-4 firms typically charge a 30-50% premium on remediation engagements), the management distraction (CFO, Controller and audit committee time), the SEC enforcement scrutiny under Rule 13a-15, and the carrying cost of a higher cost of capital, and the practical exposure on a single JE controls weakness runs to USD 50-100M for a typical mid-cap multinational.

## The international close pipeline runs 14 deterministic steps - not 8

Domestic single-framework close processes can be modelled in 8 steps. International multi-framework close cannot. The Agent splits the pipeline into 14 steps because every entry decision requires checking the accounting framework (IFRS versus US GAAP versus UK FRS 102), the entry type (recurring versus non-recurring versus top-side), the materiality threshold (clearly-trivial versus below performance versus above performance versus material per ISA 320), the preparer-versus-approver segregation under SOX 404, the IAS 8 versus ASC 250 classification for any error or estimate change, the intercompany matched-pair status under IFRS 10 / ASC 810, and the WORM-archive retention class for PCAOB AS 1215 (7 years for issuer audits), SEC Rule 17a-4, IRS Sec. 6001, HMRC, and EU VAT Directive Art. 246 (default 10 years).

A concrete scenario: a SEC-listed mid-cap with USD 800M in revenue, parallel IFRS, US GAAP and UK FRS 102 ledgers, 30 legal entities across the UK, continental EU and US, and 8,000 monthly JEs. On a typical period-end close run, the Agent identifies 6,400 system-generated entries (FX revaluation, IFRS 16 lease interest, scheduled depreciation, AR / AP cut-off accruals, intercompany elimination), classifies 1,600 manual entries by type, applies LLM-pattern recognition to suggest 1,100 recurring-template instantiations for human review, calculates 280 IFRS 15 revenue cut-off accruals deterministically (with parallel ASC 606 entries for the US ledger), processes 220 IFRS 16 lease entries (with parallel ASC 842 entries), runs 4,200 FX revaluations on monetary items at IAS 21 / ASC 830 closing rates, applies ISA 320 materiality routing on 380 entries above performance materiality (auto-routed to senior controller), flags 12 top-side entries for audit-committee visibility under PCAOB AS 2401, identifies 3 entries requiring IAS 8 versus ASC 250 classification by CFO (estimate change versus error correction), and routes 1 case to external auditor consultation before the close-certification dossier is assembled for CFO sign-off.

In the [Decision Layer](/en/decision-layer/), 11 of the 14 steps are rule-based (R), 1 is LLM-suggestion (A) for recurring-pattern recognition only (never auto-post), and 2 are human (H) - the IAS 8 versus ASC 250 classification and the four-eyes review approval. Every other step - FX revaluation, lease interest, materiality routing, intercompany matching, SoD check, evidence packet generation - is a deterministic application of accounting standard, audit standard, or controls framework.

## Manual versus system-generated entry classification is the audit linchpin

Big-4 firms run their JE audit through proprietary data analytics tools - Deloitte ASM, PwC Halo, EY Helix, KPMG Clara - that extract the entire manual-JE population for the audit period and apply pattern-recognition algorithms to identify entries warranting substantive testing. The auditor cannot test all 96,000 annual entries individually; the analytics narrow the population to several hundred high-risk entries through filters on preparer characteristics, account combinations, time-of-day posting, period-end clustering, and amount thresholds. The audit timeline therefore depends critically on the speed and accuracy of the manual-JE population extraction.

The Agent classifies each entry as system-generated or manual at posting time, captures preparer attributes (role, frequency of similar postings, peer comparison), and pre-extracts the manual-JE population in audit-ready format with full supporting evidence per entry. Big-4 audits that previously required 200-400 hours of data acquisition and analytics setup typically complete this phase in 30-60 hours with the Agent's pre-classified population, freeing audit hours for substantive testing on the genuinely judgement-heavy entries (revaluations, provisions, error corrections, top-side adjustments) where auditor experience matters most.

## Cross-framework parallel posting prevents reconciliation drift

A US-listed parent with European subsidiaries must reconcile three sets of books continuously. IFRS 15 and ASC 606 are largely converged on revenue recognition but diverge on contract-cost capitalisation (ASC 606 allows a practical expedient for short contracts, IFRS 15 requires the same treatment but documentation differs) and disclosure (ASC 606 has more granular disaggregation requirements). IFRS 16 and ASC 842 diverged sharply on lessee accounting: IFRS 16 puts every lease on-balance-sheet under a single right-of-use model; ASC 842 retains the operating-versus-finance lease distinction with finance leases on-balance-sheet and operating leases producing a single straight-line expense. IAS 19 and ASC 715 differ on pension actuarial gain-loss recycling (IAS 19 prohibits recycling through P&L, ASC 715 allows amortisation through P&L with a corridor approach). IFRS 9 and ASC 326 differ on credit-loss provisioning (three-stage ECL versus single-stage CECL day-one).

The Agent operates against multi-book ERPs (NetSuite Multi-Book Accounting, SAP S/4HANA Multi-GAAP with parallel ledgers, Oracle Fusion Cloud Financials Multi-GAAP, Workday Financial Management with secondary ledgers) and posts parallel entries with framework-specific calculations at the source. Reconciliation walks between frameworks are auto-generated at every period-end and stored in the close-certification dossier for Big-4 audit review. The alternative - separate manual reconciliation walks built in spreadsheets after the close - is exactly the pattern that produces the IAS 8 / ASC 250 error corrections that trigger Item 4.02 Form 8-K filings and subsequent securities-class-action exposure.

## Integration ecosystem: SAP S/4HANA, Oracle Fusion, Workday, NetSuite, plus close orchestration platforms

The Agent integrates natively with the major international ERPs: [SAP S/4HANA](https://www.sap.com/products/erp/s4hana.html) Universal Journal (table ACDOCA) via OData and the SAP Cloud Application Programming Model; [Oracle Fusion Cloud Financials](https://www.oracle.com/erp/financials/) General Ledger and Subledger Accounting Engine via REST; [Workday Financial Management](https://www.workday.com/en-us/products/financial-management/) General Ledger and Adaptive Planning Close Manager via WSDL/SOAP and Workday Studio; Microsoft Dynamics 365 Finance and Operations General Journals via OData; Oracle NetSuite Multi-Book Accounting via SuiteScript and SuiteCloud REST; and Sage Intacct dimensional GL with multi-entity consolidation via REST. For close orchestration it integrates with BlackLine Account Reconciliations and Journal Entry (Big-4 audit-friendly, with PCAOB-aligned controls and built-in evidence packets), Trintech Cadency, FloQast Close and Workday Adaptive Planning Close Manager. Audit-evidence integration: Deloitte ASM, PwC Halo, EY Helix, KPMG Clara via standardised JE export formats (XML, CSV, JSON) with PCAOB AS 1215-compliant metadata. WORM-archive integration: Amazon S3 Object Lock, Azure Blob Immutable Storage, Google Cloud Storage Bucket Lock with retention-class tagging per PCAOB AS 1215, SEC Rule 17a-4, IRS Sec. 6001, HMRC, and EU VAT Directive Art. 246 - all generated as deterministic templates with audit-trail metadata for SOX 404 evidence packs and PCAOB substantive testing.

--- Lease Accounting Agent ---
> Cross-jurisdictional lease pipeline: IFRS 16 single ROU plus ASC 842 dual operating-versus-finance, IBR judgement, sale-and-leaseback, SOX 404, PCAOB AS 2401.

International lease accounting runs on two converged but materially different standards at once: IFRS 16, in 144 jurisdictions including all 27 EU Member States, the UK, Australia, Canada and Singapore, with single-model lessee accounting that recognises a right-of-use asset and lease liability for all leases; and ASC 842 (US GAAP), which retains the operating-versus-finance lessee classification distinction and produces materially different income statement geography. A US-headquartered multinational whose EU subsidiaries report IFRS 16 while the US parent reports ASC 842, a UK Main Market entity with FRS 102 statutory accounts after the March 2024 IFRS 16 alignment, and a dual-listed group must run parallel calculations across both standards while applying seven judgement-intensive determinations: lease identification under the three-criteria test (identified asset, economic benefits and direction of use) per IFRS 16.9 and ASC 842-10-15-3; the lease term reasonably certain assessment per IFRS 16.18 and ASC 842-10-30-1; incremental borrowing rate derivation (reference rate, credit spread, security adjustment and term matching) per IFRS 16.26 and ASC 842-20-30-3; the variable lease payment in-substance fixed assessment per IFRS 16.27 and ASC 842-10-15-30; the separate-lease versus remeasurement determination for contract modifications per IFRS 16.44 and ASC 842-10-25-8; the sale-and-leaseback control transfer judgement per IFRS 16.98 and ASC 842-40, with the unique finance-leaseback failed-sale rule; and sublease classification, which references the ROU asset under IFRS 16.67 but the underlying asset under ASC 842-10-25-25, producing different classifications for the same transaction. Over this sit the PCAOB AS 2201 SOX 404 internal control attestation, where the lease cycle is consistently a top-five material weakness area, the AS 2401 fraud-risk presumption on lease completeness, the AS 3101 Critical Audit Matter disclosure (lease accounting appears as a CAM in roughly 22 percent of S&P 500 audits), and FRC and ESMA enforcement priorities every year since IFRS 16 took effect in 2019 - which makes international lease accounting one of the most judgement-intensive compliance processes in the multinational finance function.

## SEC restatement defence, material weakness prevention and the IFRS 16 versus ASC 842 reconciliation all converge on the lease cycle

Lease accounting moved from off-balance-sheet operating leases under IAS 17 and ASC 840 to ROU asset and lease liability balance sheet recognition under IFRS 16 (effective 2019) and ASC 842 (effective for public companies in 2019 and private companies in 2022), bringing roughly USD 3 trillion in lease obligations onto corporate balance sheets per the IFRS Foundation Effects Analysis 2016. The lease cycle is consistently a top-five SOX 404 material weakness area per 2024 PCAOB inspection findings, with completeness controls (omitted leases and embedded leases in supply contracts) and IBR derivation the most-cited deficiencies. PCAOB inspections cite the lease cycle in the top-five deficiency areas across all four firms (Deloitte, PwC, EY, KPMG) every year since 2019, with IBR derivation and the lease term assessment specifically cited as a Critical Audit Matter under AS 3101 in roughly 22 percent of S&P 500 audits. For SEC-registered multinationals, a single lease accounting error compounds into a FIN 48 or IFRIC 23 uncertain tax position disclosure under ASC 740-10 and IAS 12, a Big-4 auditor concurrence challenge under PCAOB AS 2201 and AS 2401, an SEC comment letter and a class-action lawsuit - a cumulative downside that typically exceeds USD 30 million for material restatements.

## The international lease accounting pipeline runs 16 deterministic and judgement-supported steps

Spanning IFRS 16 and ASC 842 with full judgement support takes 16 steps because every lease requires three-criteria identification (identified asset, economic benefits and direction of use) per IFRS 16.9 and ASC 842-10-15-3, recognition exemption application (short-term under both, low-value under IFRS 16 only), LLM contract extraction, the lease term reasonably certain assessment with a five-factor economic incentive analysis, IBR derivation with a four-component analysis (reference rate, credit spread, security adjustment and term matching), ASC 842 lessee classification with five finance lease criteria (not applicable under the IFRS 16 single model), ROU asset initial measurement, the amortisation schedule via the effective interest method, the variable payment in-substance fixed assessment (CPI versus market-rent versus usage versus performance), monthly journal entries differentiated between the IFRS 16 single model and the ASC 842 operating-versus-finance treatment, modification accounting with the separate-lease versus remeasurement determination, sale-and-leaseback with the control transfer judgement and the unique ASC 842 finance-leaseback failed-sale rule, sublease classification with the IFRS 16 ROU-asset versus ASC 842 underlying-asset reference asymmetry, CPI remeasurement under IFRS 16.42 (not under ASC 842 mid-term), ROU impairment monitoring under IAS 36 versus ASC 360 with its reversal asymmetry, and disclosure notes per IFRS 16.51-60 and ASC 842-20-50.

A concrete scenario: a US-headquartered specialty retailer with USD 8 billion in revenue, reporting under ASC 842 as an SEC-listed parent and under IFRS 16 through a UK subsidiary's statutory accounts, runs 1,400 active leases - 850 retail real estate leases (with CPI escalation on 620), 320 distribution centre leases, 180 vehicle fleet leases and 50 IT equipment leases. In a typical month the Agent processes 20 new leases and 60 modifications, derives the IBR per Treasury Committee approval, performs CPI index remeasurement under IFRS 16.42 on 620 CPI-linked retail leases (creating IFRS 16 versus ASC 842 balance sheet divergence at every CPI cycle), monitors ROU impairment indicators on 40 underperforming locations, drafts disclosure notes covering ROU asset and lease liability balances of USD 2.8 billion and future cash outflows of USD 4.2 billion, runs the PCAOB AS 2401 lease completeness procurement-to-balance reconciliation, and supplies the IFRS 16 versus ASC 842 reconciliation report covering all six differences.

In the [Decision Layer](/en/decision-layer/), 7 of the 16 steps are rule-based, 7 are human judgement reflecting the reality of IFRS 16 and ASC 842, and 2 are LLM-suggestion (contract data extraction, ROU impairment indicator monitoring and disclosure note drafting). There is no generative AI in lease identification, the lease term, IBR derivation, classification or the sale-and-leaseback determination; the LLM never determines accounting outcomes without human accountant acceptance.

## IBR derivation is the most-judgement-intensive parameter and the most-cited PCAOB inspection finding

The incremental borrowing rate is the single most sensitive parameter in all of lease accounting. It determines the present value of every lease and thus the size of right-of-use asset and lease liability on the balance sheet. A 50 basis-point deviation on a ten-year property portfolio of USD 200 million can shift recognised ROU asset and lease liability by approximately USD 8 million - far above quantitative materiality thresholds. Substantive testing of IBR derivation under PCAOB AS 2401 and ISA UK 540 is consistently a top-three PCAOB inspection finding between 2020 and 2024, because the four-component derivation combines reference rate selection (a corporate bond yield curve from Moody's or S&P, a swap rate curve or a bank reference rate), a credit spread adjustment (entity-specific credit risk, sector adjustments and country risk for a non-headquarters currency), a security adjustment (typically a 50-100 basis point reduction for the secured ROU asset versus an unsecured corporate bond) and term matching (yield curve interpolation to the lease term rather than the instrument tenor). ASC 842 permits private companies, not-for-profit organisations and employee benefit plans to elect the risk-free rate as a practical expedient under ASC 842-20-30-3, but public business entities and SEC registrants must use the IBR. The risk-free rate election removes the four-component derivation but produces different lease values: the IBR-derived ROU asset and liability are typically 3-5 percent lower than their risk-free-rate equivalents. The Agent operationalises IBR derivation with policy-driven reference rate curve selection, credit spread calculation with an effective date, a security adjustment benchmarked against industry, term matching via yield curve interpolation, and Treasury Committee approval by class of underlying asset and lease term band; PCAOB AS 2401 and ISA UK 540 substantive testing recalculates each component and tests historical accuracy.

## IFRS 16 versus ASC 842 reconciliation transforms lease accounting into dual-standard parallel calculation engine

The IASB-FASB convergence diverged on six material differences. On lessee classification, the IFRS 16 single model recognises a ROU asset and liability for all leases, while ASC 842 retains the operating-versus-finance distinction. On low-value assets, IFRS 16.B5 offers a roughly USD 5,000 exemption that ASC 842 has no equivalent for. On CPI remeasurement, IFRS 16.42 remeasures on each CPI change while ASC 842 does not. On sale-and-leaseback, ASC 842-40-25 fails the sale if the leaseback qualifies as a finance lease, where IFRS 16 differs. On sublease classification, IFRS 16.67 references the ROU asset while ASC 842-10-25-25 references the underlying asset. On impairment reversal, IAS 36 permits it while ASC 360 does not. The Agent's dual-standard engine produces both results with a reconciliation, a required PCAOB AS 2110 and ISA UK 540 substantive testing artefact. The UK FRS 102 March 2024 amendments (effective 1 January 2026) align Section 20 with IFRS 16, so the Agent supports all four standards - FRS 102, FRS 101, IFRS 16 and ASC 842 - for UK groups with a US SEC parent.

## Integration ecosystem: Workday Lease, SAP S/4HANA Lease Administration, Oracle Lease Accounting, LeaseAccelerator, Visual Lease and Big-4 audit tools

The Agent integrates with the major lease platforms: [Workday Lease Management](https://www.workday.com/en-us/products/financial-management/lease-management.html) (cloud-native, dual-model ASC 842 and IFRS 16); [SAP S/4HANA Lease Administration](https://www.sap.com/products/financial-management/lease-management.html) (integrated with SAP Asset Accounting and Treasury); [Oracle Lease Accounting](https://www.oracle.com/erp/lease-accounting/); [LeaseAccelerator](https://leaseaccelerator.com/); [Visual Lease](https://visuallease.com/) (a tri-model ASC 842, IFRS 16 and GASB 87 engine); MRI ProLease; and Nakisa Lease Administration. Audit evidence loads into Deloitte Lease Audit, PwC Halo, EY Helix Lease and KPMG Clara with PCAOB AS 1215 metadata. Filing runs via SEC EDGAR, UK Companies House and EU Member State portals (Bundesanzeiger, INPI, Registro Mercantil) under PCAOB AS 2201 and AS 2401, ISA UK 240 and AICPA AU-C 240.

--- Management Reporting Agent ---
> Calculates key KPIs (EBITDA, working capital, DSO, DPO), consolidates data from multiple sources, detects anomalies.

Finance teams spend around 300 hours per year on manual reporting work - time that flows into neither analysis nor decision preparation (source: Float Financial, 2025). The bottleneck in management reporting is not the interpretation of key figures. It is the consolidation that precedes every interpretation.

## Consolidation Consumes the Time That Analysis Needs

A typical month-end close in the upper mid-market takes six to ten working days. After that, the controller's real work begins: merging data from general ledger, controlling, treasury and operational systems, performing eliminations, calculating KPIs, building prior-month and prior-year comparisons. Only once this foundation stands can the CFO cockpit be updated.

In practice this means: the numbers are technically correct by working day five - but the board deck is not ready until day eight or nine. Not because the analysis is complex, but because three days disappear in manual consolidation of spreadsheet exports, ERP extracts and controlling reports. Every reporting cycle repeats the same effort because the consolidation logic exists nowhere as a reusable process.

## Rule-Based KPI Calculation Shortens the Cycle by Days

EBITDA, working capital, DSO, DPO and cash conversion cycle follow defined formulas. There is no interpretation in how DSO is calculated - only in what a rising DSO means for the business. Precisely here the [Decision Layer](/en/decision-layer/) draws the line.

The Management Reporting Agent handles the first category completely: it pulls consolidated values from general ledger and controlling, applies the stored calculation formulas and updates the dashboard automatically once the month-end close is marked complete. The data source, the formula applied and the result are documented for every KPI - reproducible and audit-ready.

Companies that automate their consolidation report a 50 percent reduction in the close-to-report cycle (source: Deloitte CFO Signals Survey, H4 2025). Eight days become four. A reactive reporting process becomes a rhythm the board can rely on.

## Anomaly Detection Makes Reporting Proactive Instead of Reactive

The most valuable information in a monthly report is not the confirmation that everything is on plan. It is the early identification of deviations before they become a talking point in the next quarterly report.

The agent compares every calculated KPI with historical ranges and statistical expectations. When DSO rises by 12 days or working capital shows a jump outside the seasonal norm, it is flagged - not as an alarm, but as a commentary suggestion with context data. The controller receives a draft that names the anomaly, places it in historical context and derives potential causes from the source data.

This fundamentally changes the controller's role: instead of searching for figures that might need explanation, they start with a prioritised list and invest their time in root-cause analysis.

## The Strategic Narrative Stays with the CFO

What a rising cash conversion cycle means for supplier negotiations next quarter, which KPI trends require special commentary in the management report, how the figures should be framed for the supervisory board - these are decisions that require business knowledge, industry experience and strategic judgement.

The Decision Layer draws a clear boundary. Seven of eight decision steps in the reporting process run rule-based or AI-assisted. The eighth - strategic interpretation - stays with the human. Not as a concession, but as an architectural decision: a CFO who builds a board deck from a prepared draft with documented KPIs and flagged anomalies makes better decisions than one who spends the first half of the available time on data consolidation.

## Consolidated KPIs arrive on working day three instead of day eight

A concrete scenario: an industrial company with four business units, consolidated reporting to the holding and a monthly board meeting on working day ten. Before automation, the finished board deck was ready at the earliest on working day eight - with regular last-minute corrections until the evening before the meeting.

After implementing the Management Reporting Agent, consolidated KPIs are available on working day three. Anomalies are flagged and pre-commented. The head of controlling uses days four and five for strategic contextualisation and narrative - not for consolidation. On day six, the deck goes to the CFO. Four days of buffer instead of two days of pressure.

--- Payment Run Agent ---
> Cross-jurisdictional disbursement pipeline: US ACH NACHA, Fedwire, RTP, FedNow, UK BACS, CHAPS, FPS, EU SEPA SCT Inst, ISO 20022 PAIN.001, SOX 404 four-eyes.

Cross-border disbursement at a multinational does not run on one payment rail - it runs on nine in parallel. A US-listed parent with European subsidiaries and UK operations releases payments through ACH (NACHA Operating Rules) for batched US supplier payments, Fedwire (Federal Reserve Regulation J) for US high-value over the USD 1M Same-Day ACH cap, RTP (The Clearing House) and FedNow (Federal Reserve, launched July 2023) for US instant payments, BACS (Pay.UK Standard 18) for batched UK supplier payments, CHAPS (Bank of England RTGS) for UK same-day high-value, Faster Payments (Pay.UK FPS) for UK instant under GBP 1M, SEPA Credit Transfer (EPC scheme) for batched euro-denominated payments, and SEPA Instant Credit Transfer (Regulation 2024/886, mandatory receive 9 January 2025 and mandatory send 9 October 2025) for euro-denominated instant. Cross-border non-EU continues on SWIFT MT103 transitioning to ISO 20022 MX (PACS.008) by 22 November 2025 under the coordinated central-bank cutover. Layer over this the OFAC strict-liability sanctions regime, which averages a USD 1.5M penalty per violation, the BSA and EU AML monitoring rules, and the SOX 404 internal-controls regime with its PCAOB AS 2201 design and operating-effectiveness testing, and the payment run becomes a coordination problem that no single AP clerk can run consistently at weekly or daily velocity.

## An OFAC violation, a SOX 404 material weakness, and the SEPA SCT Inst deadline each carry seven-figure consequences

OFAC operates under strict liability. Civil penalties under IEEPA 50 USC 1705 do not require intent - the fact of the prohibited transaction is sufficient for liability. The current per-violation average penalty is approximately USD 1.5M, with cumulative annual OFAC enforcement actions exceeding USD 1.5B in 2024 across all sanctions programs. UK enforcement under the Sanctions and Anti-Money Laundering Act 2018 (administered by OFSI) and EU enforcement under Regulation 2580/2001 plus national criminal-code implementations operate on similar principles. The exposure compounds when an enforcement action also triggers SOX 404 material-weakness disclosure - a sanctions breach that bypassed disbursement controls is, by definition, a controls failure - producing the typical 4-7% share-price erosion in the trading week following the 10-K filing. For a Russell-3000 mid-cap with USD 800M market cap, a 5% impact equals USD 40M of shareholder value destroyed by a payment-release that an automated screening engine plus four-eyes log would have prevented.

The SEPA SCT Inst mandate adds a third deadline-driven exposure. Regulation 2024/886 imposes mandatory receive of SCT Inst from 9 January 2025 and mandatory send from 9 October 2025 on every euro-area Payment Service Provider offering SCT. National competent authorities under Article 5d enforce against non-compliant PSPs with administrative penalties. Corporates that depend on non-compliant banking partners face operational disruption when partner banks lose the ability to send instant payments. The Agent's deterministic rail selection embeds the SCT Inst default into the payment policy - euro-denominated payments under EUR 100,000 default to SCT Inst from 9 October 2025 onward, with documented fallback only where the receiving bank explicitly does not support Inst (now rare).

## The international payment pipeline runs 16 deterministic steps - not 8

Domestic single-rail payment runs can be modelled in 8 steps. International multi-rail payment runs cannot. The Agent splits the pipeline into 16 steps because every payment-line decision requires checking the destination corridor (US versus UK versus EU versus cross-border non-EU), the rail selection across the nine US, UK and EU schemes, the amount-and-urgency thresholds (NACHA Same-Day USD 1M cap, Fedwire over that, RTP USD 10M cap, FedNow USD 10M cap, CHAPS over GBP 1M, SEPA SCT Inst EUR 100,000 cap), the sanctions screening against the OFAC, UK, EU and UN lists with fuzzy transliteration, the AML transaction-monitoring rules under the BSA, UK MLR 2017 and EU AML frameworks, the format validation of IBANs, ABA routing numbers and UK sort codes with Confirmation of Payee where available, the SOX 404 segregation-of-duties between initiator and releaser, the PSD2 Strong Customer Authentication challenge for online release, the WORM-archive retention class (PCAOB AS 1215 at 7 years for issuer audits, FinCEN BSA and OFAC at 5 years, UK MLR 2017 and EU AMLD 2024 at 5 years), and the IFRS 9 Para 3.3.1 versus ASC 405-20 derecognition trigger.

A concrete scenario: a SEC-listed mid-cap with USD 800M revenue, EU operations across Germany, France and the Netherlands alongside the UK, and weekly payment-run cycles with 1,200 supplier payments across USD, GBP and EUR. On a typical run, the Agent identifies 1,200 due open-items, screens them against the OFAC, UK, EU and UN sanctions lists producing 4 fuzzy-match positives for AML-officer review (3 cleared as transliteration false-positives, 1 confirmed and blocked with SAR filing), runs AML transaction monitoring producing 2 structuring-pattern alerts (both cleared), validates 1,200 payee records across IBAN, ABA and sort-code formats with 6 format errors flagged for vendor correction, selects 480 ACH, 18 Fedwire, 2 RTP, 320 BACS, 8 CHAPS, 12 FPS, 320 SEPA SCT Inst, 36 SEPA SCT, and 8 SWIFT MT103 transitioning to PACS.008, generates 9 ISO 20022 PAIN.001 batches alongside the NACHA, BACS Standard 18 and CHAPS messages, runs duplicate-payment detection finding 0 duplicates against 90-day history, verifies liquidity across 4 debtor accounts in 3 currencies, enforces segregation of duties with 2 different releasers per debtor account, captures four-eyes release with PSD2 SCA challenges, transmits via SWIFT FIN, EBICS and SFTP-with-PGP per bank contract, captures bank ACK on all submissions within 30 minutes, and reconciles next-day BAI2, CAMT.053 and MT940 confirmations - 1,196 matched, 4 returned by beneficiary banks and routed to AP for re-issuance.

In the [Decision Layer](/en/decision-layer/), 14 of the 16 steps are rule-based (R), 0 are LLM-suggestion (A), and 1 is human (H) for four-eyes release approval. The remaining step (sanctions match disposition) routes deterministically to the AML officer for human investigation when a fuzzy-match flag triggers - the Agent never silently clears a sanctions match. Every other step - duplicate detection, format validation, rail selection, liquidity check, SCA challenge, transmission, reconciliation - is a deterministic application of accounting standard, scheme rule, or compliance regulation.

## Sanctions and AML clearance is the regulatory linchpin

Big-4 audits and FinCEN and OFAC examinations focus heavily on the sanctions and AML clearance evidence chain. The Agent operates against the union of the OFAC lists (the SDN List, the Sectoral Sanctions Identifications List and the Foreign Sanctions Evaders List), the UK FCO Consolidated Sanctions List, the EU Restrictive Measures List, and the UN Security Council Consolidated List - all updated daily from the source authorities. Fuzzy-matching covers exact name match plus transliteration variants (Cyrillic-to-Latin, Arabic-to-Latin, Chinese pinyin), abbreviation variants, and corporate-structure variants (subsidiary identification through ultimate-beneficial-owner registries where available). False-positives are managed under a documented investigation procedure - the AML officer reviews the match evidence, performs Customer Due Diligence and Enhanced Due Diligence under UK MLR 2017 Reg 28-35 and BSA 31 CFR 1020.220, and clears only with documented rationale. False-negatives are the strict-liability exposure - hence the cross-list union and the daily list pull.

AML transaction monitoring runs against patterns in vendor, amount, corridor, frequency and timing. Structuring (multiple sub-threshold payments to evade BSA CTR USD 10,000 reporting), unusual-volume thresholds versus the 90-day vendor baseline, high-risk corridor flags (FATF grey-list and black-list jurisdictions plus internal corporate risk-rating), and timing-cluster patterns all trigger alerts that route to the AML officer for a SAR or SAR-equivalent decision under BSA 31 CFR 1020.320, UK MLR 2017 Reg 28 and EU AMLD 2024. The Agent's Decision Log captures every alert with the rule that triggered it and the officer's disposition - producing the FinCEN-inspection-ready evidence chain that compliance officers spent decades assembling manually.

## Cross-rail finality and derecognition timing prevents reconciliation drift

Payment finality varies sharply by rail and matters for both operational recovery and accounting derecognition under IFRS 9 Para 3.3.1, with ASC 405-20 as the US GAAP equivalent. ACH supports returns up to 60 days for consumer R10 unauthorised-debit and up to 2 banking days for most return reasons. Fedwire is final and irrevocable on confirmation. RTP and FedNow are final and irrevocable on confirmation per The Clearing House and Federal Reserve scheme rules. SEPA SCT supports R-transactions for up to 5 business days. SEPA SCT Inst is final and irrevocable on confirmation. CHAPS is final on confirmation. BACS supports recall under limited conditions for up to 2 working days. The Agent records expected-finality at release time and posts derecognition only on confirmed payment under IFRS 9 (and ASC 405-20 in US GAAP) - never on file initiation. Returns within the same accounting period reverse cleanly. Returns crossing period-end flag for IAS 8 or ASC 250 evaluation by the Journal Entry Agent for prior-period error-correction analysis.

## Integration ecosystem: SAP S/4HANA F110, Oracle Fusion Payments, Workday Settle Payment, plus payment-factory platforms

The Agent integrates natively with the major international ERPs: [SAP S/4HANA](https://www.sap.com/products/erp/s4hana.html) brings the F110 Automatic Payment Run together with Bank Communication Management and Multi-Bank Connectivity (MBC); [Oracle Fusion Cloud Financials](https://www.oracle.com/erp/financials/) combines Payments, Cash Management and iPayment for ISO 20022 message generation; [Workday Financial Management](https://www.workday.com/en-us/products/financial-management/) pairs the Settle Payment business process with Bank Account integration and secondary-ledger postings; Microsoft Dynamics 365 Finance uses the Vendor payment journal with Electronic reporting (ER) for ISO 20022 PAIN.001; Oracle NetSuite runs SuitePayments across the Vendor Bills and Bill Payment workflows; and Sage Intacct AP Payment Services covers US ACH and check with multi-entity disbursement. For payment-factory architecture, [Kyriba](https://www.kyriba.com/) treasury management combines a bank-connectivity hub with sanctions screening and a payment workflow; FIS Quantum, GTreasury and ION Treasury cover corporate treasury; and Bottomline PTX (Payments Transaction Exchange) adds integrated Cyber-Crime detection. Bank connectivity per relevant rails runs through SWIFT FIN with the MX migration via SWIFT direct connectivity or a Service Bureau (Bottomline, Broadridge, AccessPay), Federal Reserve FedLine for Fedwire and FedNow, a NACHA-certified ODFI for ACH, a BACS-approved Service User for the UK, EBICS with T-version and H006 keys for German and EU corporate banking, or a bank-direct API (US Open Banking through FDX, EU and UK Open Banking through PSD2 XS2A). Audit-evidence integration covers Deloitte ASM, PwC Halo, EY Helix and KPMG Clara via standardised payment-run export formats with PCAOB AS 1215-compliant metadata. WORM-archive integration covers Amazon S3 Object Lock, Azure Blob Immutable Storage and Google Cloud Storage Bucket Lock with retention-class tagging per PCAOB AS 1215 (7 years for issuer audits), SEC Rule 17a-4 (6 years for broker-dealers), FinCEN BSA and OFAC (5 years), and UK MLR 2017 and EU AMLD 2024 (5 years) - all generated as deterministic templates with audit-trail metadata for SOX 404 evidence packs and PCAOB substantive testing.

--- Payment Traffic Agent ---
> Determines the payment format (SEPA, SWIFT), creates SEPA XML files, transmits to the bank.

A payment is approved, the IBAN is wrong, the file is rejected. Three days later the supplier asks about their money. This scenario costs not just liquidity but trust. In European payment traffic, transfer fraud totalled EUR 2.2 billion (approx. USD 2.4 billion) in 2024 according to EBA and ECB - and format errors, incorrect recipient data or delayed escalation on rejects come on top. The last mile between approval and bank transmission deserves the same process discipline as the approval itself.

## The Costliest Errors Arise Between Approval and Bank Transmission

The Payment Run Agent decides what gets paid when. But the question of how the payment technically reaches the bank remains open. This is precisely where the Payment Traffic Agent operates. It determines the format - SEPA, SWIFT or cheque - from the recipient master data, generates the pain.001 file and transmits via EBICS or API. (US: for ACH payments, the NACHA file format applies instead of SEPA.) That sounds like pure technology. In practice, payments fail not at approval but at incorrect BIC codes, missing mandatory fields or expired certificates. A treasury team processing 400 payments daily cannot check these errors individually. A rule-based agent can.

## Ten Decision Steps Replace the Manual Workaround

The [Decision Layer](/en/decision-layer/) breaks the payment path into ten steps: format selection, IBAN and payee validation, duplicate payment check, sanctions list screening, AWV reporting obligation check, XML generation, bank transmission, acknowledgement processing, escalation on failure and four-eyes approval for high one-off payments. Nine of these steps are fully rule-based. The payment format follows from recipient master data, pain.001 validation follows the SEPA standard, bank transmission is a technical handshake, and error messages are automatically analysed and escalated to the responsible clerk. Only for one-off payments above the configured threshold does the human intervene. This pattern - rule engine for the mass, human control for the risk - is the signature of a Decision Layer tier 1.

## Verification of Payee Fundamentally Changes the Requirements

Since October 2025, all credit institutions in the EEA are required to perform a payee verification before every SEPA transfer. The stated name is matched against the actual account holder. For the Payment Traffic Agent, this means: every outgoing payment passes through an additional validation step before it reaches the bank. Discrepancies between master data and account holder are detected and documented before money flows. Banks report that enhanced sanctions screening under SEPA Instant leads to 30 to 50 percent more flagged transactions. An agent that processes these acknowledgements in real time prevents valid payments from getting stuck in the review backlog.

## The Human Decides Where Automation Would Create Risk

The four-eyes approval for high one-off payments is not a concession to lack of trust in technology. It is an internal control system requirement that the Decision Layer deliberately preserves as a human decision. For an unusual one-off payment of EUR 50,000 or EUR 100,000 (USD 54,000 to 108,000), rule compliance alone is not enough - commercial judgement is needed. Audit-compliant bookkeeping principles require that every payment be traceably documented as a business transaction. The agent delivers this documentation automatically: payment format, transmission timestamp, bank acknowledgement, and for one-off payments the approval timestamp with the approving person. The payment traffic log arises as a by-product of the process, not as an after-the-fact compliance exercise.

--- Payroll Calculation Agent ---
> Gross-to-net math per employee: UK PAYE RTI, US FLSA + IRC Sec 3401 withholding, FICA/Medicare/401(k), statutory deductions and garnishments - SOX-404-auditable calculation chain.

International gross-to-net does not run on one regulatory standard; it runs on several overlapping regimes at once across the UK, EU and US. Consider a US-headquartered multinational that pays employees in 12 US states, sends UK PAYE through HMRC RTI for its British staff, applies FLSA overtime for non-exempt US employees, processes equity vest events under IRC Section 83 and Section 423, runs 401(k) deferrals against the annual limit, withholds for child support under CCPA Title III, and accrues IAS 19 employee benefits per jurisdiction. It is operating concurrently under UK PAYE income tax and Class 1 NIC; US federal income-tax withholding under IRC Sections 3401-3405 with FICA, state income tax and local payroll tax; UK statutory leave and auto-enrolment pension; the EU Working Time and Posted Workers Directives; and IAS 19 benefits accrual - all in a single monthly cycle.

## A payroll error costs USD 281 per incident before the IRS, HMRC RTI and Pensions Regulator penalties stack on top

Every payroll correction incurs direct costs - the American Payroll Association puts a typical incident at around USD 281. But the real damage runs deeper across all three jurisdictions. In the US, IRS penalties under IRC Section 6651 (failure to file plus failure to pay) plus IRC Section 6656 (failure to deposit) compound at 5% per month up to 25% maximum, with willful failure under IRC Section 7202 carrying criminal penalties up to USD 10,000 plus 5 years imprisonment. SOX 404 material-weakness scenarios for SEC registrants typically arise from Form 941 reconciliation failures or W-2 to W-3 to four-quarter Form 941 cross-foot variances - cited as Internal Control Deficiencies (ICDs) by the auditor.

In the UK, HMRC RTI Late Filing Penalty applies GBP 100-400 per missed FPS submission depending on PAYE scheme size (1-9 employees GBP 100, 10-49 GBP 200, 50-249 GBP 300, 250+ GBP 400) - accumulating across multiple periods compounds rapidly. The Pensions Regulator (TPR) imposes escalating fines for auto-enrolment non-compliance: GBP 400 fixed plus GBP 50-10,000 daily depending on employer size. Failure to apply UK National Minimum Wage triggers HMRC enforcement notice plus naming-and-shaming list publication plus 200% penalty up to GBP 20,000 per worker.

In the EU, Posted Workers Directive non-compliance triggers host-state labour inspectorate fines up to EUR 50,000 per worker per violation, with cumulative exposure across 27 Member State enforcement regimes. EU Regulation 883/2004 A1 certificate non-compliance creates dual social security contributions plus interest plus penalties when host-state authority charges contributions in absence of valid A1.

For the CFO, every post-correction triggers a domino effect: amended IRS Form 941 plus W-2c, corrected UK RTI Earlier Year Update (EYU), adjusted journal entries in the general ledger under IFRS IAS 19 plus ASC 715. With retroactive corrections, the problem intensifies - employers typically have only a limited window to file contribution corrections without additional penalties.

## The gross-to-net pipeline runs 16 deterministic steps, not the 12-15 of a single jurisdiction

Cross-jurisdictional gross-to-net needs 16 deterministic steps rather than the 12-15 of single-jurisdiction payroll, because the regimes overlap. Each employee may carry UK PAYE income tax across three bands with Class 1 NIC and auto-enrolment; US FLSA overtime, federal income-tax withholding, the three FICA components, and state and local taxes; pre-tax 401(k), cafeteria-plan and HSA deductions; equity events under IRC Section 83 and Section 423; UK and US statutory leave and state paid family leave; garnishments by priority under CCPA Title III; and IAS 19 short-term, post-employment and other long-term benefits accrual.

A concrete cross-border scenario: a US-headquartered S&P 500 manufacturer with 5,000 employees, of whom 3,200 in 14 US states (CA 800, NY 600, TX 500, IL 400, plus 10 others), 1,200 in the UK (London, Manchester and Edinburgh), and 600 in the EU (Germany 250, France 200, Spain 150). 800 US employees on shifts with night-and-weekend premiums under FLSA. 200 UK employees in auto-enrolled workplace pension. 150 senior executives across all three jurisdictions with quarterly RSU vest under IRC Section 83 plus annual ISO exercise. 80 employees with active garnishment orders. 40 UK employees on SSP/SMP. For payroll: 5,000 individual gross-to-net calculations, 800 with FLSA overtime, 200 with UK auto-enrolment, 150 with quarterly equity vest valuation, 80 with garnishment priority sequencing, 40 with statutory payment plus reclaim - all in the same monthly cycle.

In the [Decision Layer](/en/decision-layer/), 15 of 16 steps are rule-engine decisions (tier R) - base salary application from contract, FLSA overtime per 29 CFR 778.115 weighted average, NI category assignment, 401(k) deferral limit monitoring, equity vest valuation at FMV, garnishment priority per CCPA Title III plus state-specific overlay, net pay calculation. Only the plausibility deviation assessment (10% rolling baseline variance) is human-judgement (tier H) - the payroll manager assesses cause for significant variances, but never adjusts the deterministic calculation itself.

## Cross-system integration across the global payroll stack

The Agent integrates with the full global payroll stack: [ADP Workforce Now and ADP GlobalView](https://www.adp.com/) (US service bureau across 140+ jurisdictions), [Workday Payroll](https://www.workday.com/) (US plus international through CloudPay or Strada), [Paychex Flex](https://www.paychex.com/) (SMB through mid-market US), [UKG Pro](https://www.ukg.com/) (HCM with time-and-attendance), SAP SuccessFactors Employee Central Payroll (enterprise HRIS with 50+ country localisations), Ceridian Dayforce (continuous calculation engine), Sage People and Sage Payroll (UK SMB and mid-market), and Xero Payroll and QuickBooks Online Payroll (UK and US SMB). For UK PAYE it submits the RTI Full Payment Submission on or before each pay date through HMRC Government Gateway, with the monthly EPS, year-end RTI and P11D returns. For US filings it connects to IRS e-Services and IRIS for the Form 941, 940, W-2 and 1099-NEC series, SSA Business Services Online for W-2/W-3, and the state portals for SUTA across all 50 states. For equity events it integrates with Shareworks, Carta, Computershare, AST and E*TRADE Stock Plan Services; for benefits with bswift, Benefitfocus, Workday Benefits, ADP TotalSource and Paylocity through standard deduction codes; and for garnishments with ADP SmartCompliance, Ceridian Tax Compliance and Wage Garnishment Solutions, handling the CCPA Title III calculation, state overlays, child-support priority and IRS levy.

--- Payroll Correction Agent ---
> Retroactive payroll corrections: void filings (941-X, RTI YTD), back-payments and FICA/NIC corrections with tax recalculation - posted with four-eyes approval and audit trail.

payroll (UK: PAYE) corrections cost companies real money - not because of the underlying difference, but because of the effort to recalculate them correctly. According to an EY analysis, a company with 1,000 employees averages 15 corrections per payroll period, adding up to over USD 900,000 (approx. EUR 830,000) annually. The Payroll Correction Agent handles the rule-based calculation including tax and social insurance implications. The approval stays with the human.

## One in Five Payslips Contains Errors

The causes are diverse and often systemic: retroactive collective agreement increases, belatedly reported overtime, late-submitted expense claims, erroneous tax bracket changes. Industry analyses show an average error rate of around 20 percent in non-automated payroll processes (EY, HR Dive). Every single error triggers a chain of downstream calculations - gross difference, payroll tax, solidarity surcharge, church tax, health, pension, long-term care and unemployment insurance.

A concrete scenario: a collective agreement increase is agreed retroactively to January, and the information reaches payroll in April. For three months, all pay components must be recalculated - for each affected employee individually, because tax brackets, allowances and social insurance obligations differ. With 200 affected employees, that creates 200 individual corrections each requiring ten calculation steps.

## Manual Recalculation Binds the Most Expensive Resources

The real problem is not the correction itself. The arithmetic is unambiguous: new calculation minus old calculation yields the gross difference. Tax and social insurance impacts follow fixed rules from income tax and social security law. What actually burdens companies is the time required from qualified specialists.

Payroll accountants with specialised tax and social insurance knowledge spend hours performing calculations that a rule engine can deliver in seconds. Average direct costs per individual correction are USD 281 (EUR 260). For complex cases such as unrecorded sick leave, the amount rises above USD 700. Meanwhile, these specialists are unavailable for tasks that genuinely require judgement - such as assessing disputed cases or communicating with affected employees.

## The Agent Calculates - The Human Decides

The [Decision Layer](/en/decision-layer/) breaks every payroll correction into its decision steps and assigns each the appropriate decider. Seven of ten steps are rule-based: difference identification, retroactive period, correction calculation, tax impact, social insurance correction, net difference and journal entry. These follow statutory calculation rules - no discretion, no interpretation needed.

Two steps use AI support at tier 1: cause classification categorises the context - is it a collective agreement change, an input error or a late report? Employee communication prepares an understandable explanation of the correction so the affected person can trace why their net pay changed.

The tenth step stays with the human: approval under the four-eyes principle. No correction journal entry leaves the system without human review and confirmation.

## Audit-Compliant Documentation Emerges Automatically

Payroll corrections are business transactions. German GoBD (German record-keeping standard) bookkeeping principles require that the original payslip remain immutable. Corrections are executed exclusively via reversal of the old and creation of a new payslip. The agent generates this document chain automatically: original payslip, reversal document, corrected payslip - linked without gaps and documented in an audit-proof manner.

For every correction, the Decision Layer logs the complete decision chain: cause with classification, affected period, gross difference, tax difference, social insurance difference, net difference, resulting journal entry, plus approval timestamp and approving person. During an audit, the entire calculation path is transparent - not as retrospective documentation but as a by-product of the process itself.

--- Payroll Tax Agent ---
> Payroll tax filings: US IRS Form 941/940 quarterly + W-2/1099-NEC annual, UK PAYE RTI FPS, EU country-specific filings and year-end W-2/P60 - prevents IRS Trust Fund Recovery Penalty.

International payroll tax does not run on one regulatory standard; it runs on several overlapping regimes at once across the US, UK, EU and the OECD treaty network. Consider a US-headquartered multinational that pays employees in 12 US states, sends UK PAYE through HMRC RTI for its British staff, posts Spanish engineers to Germany under EU A1 certificates, pays the UK Apprenticeship Levy above the GBP 3 million pay-bill threshold, and supplies the per-jurisdiction Pillar Two GloBE payroll-substance data. It is operating concurrently under the US Form 941, 940, W-2/W-3 and 1099-NEC series with FICA, FUTA (0.6% net after the SUTA credit) and state SUTA; UK PAYE income tax, Class 1 NIC and the Apprenticeship Levy; the EU A1 document for posted workers and the Posted Workers Directive equal-pay rules; and the Pillar Two GloBE substance exclusion. Layer over this SOX 404 control attestation on the payroll cycle, ISA UK 240 and AICPA AU-C 240 fraud-risk procedures around ghost employees, contractor misclassification and garnishment overlaps, and the FIN 48 / IFRIC 23 uncertain-tax-position frameworks, and international payroll becomes one of the most fragmented and consequential processes in the multinational finance function.

## A Form 941 mismatch, a UK RTI lapse, an EU A1 failure or a SOX 404 weakness can cascade into a Big-4 uncertain-tax-position disclosure

IRS Form 941 reconciliation failures are the most common payroll-cycle SOX 404 finding for SEC registrants. When the four quarterly Form 941 totals do not reconcile to Form W-3 transmittal aggregating all W-2s, the discrepancy generates an Internal Control Deficiency that auditors must escalate to material weakness if material to the financial statements - and payroll expense plus payroll tax accrual are routinely material at SEC-registered multinationals. Late deposits under the IRS Look-back Rule trigger penalties under IRC Section 6656 (2% / 5% / 10% / 15% based on lateness) compounding rapidly across pay periods. UK RTI penalties for missed Full Payment Submission start at GBP 100 for the smallest schemes and escalate to GBP 400 per missed submission for 250+ employee schemes - across 12 monthly periods this compounds into mid-five-figure exposure for a single missed compliance step. EU A1 cross-border posting non-compliance triggers dual social security contributions in both home and host states plus interest plus penalties, and the host-state competent authority can audit retroactively for 4-10 years. OECD Pillar Two GloBE 15% top-up tax for MNE groups at or above EUR 750 million consolidated revenue depends directly on the SBIE 5% payroll component per jurisdiction - missing or misallocated payroll data inflates Excess Profit and creates top-up tax that did not need to be incurred. For SEC-registered S&P 500 multinationals, the cumulative exposure from these four failure modes typically lands as a FIN 48 uncertain tax position requiring ASC 740-10 disclosure plus Big-4 auditor concurrence under PCAOB AS 2201, AS 2310 and AS 2501.

## The international payroll-tax pipeline runs 16 deterministic steps, not the 6-8 of a single jurisdiction

US-only payroll can be modelled in 6-8 steps; cross-jurisdictional payroll cannot. The Agent splits the pipeline into 16 steps because every employee needs checking on worker classification (employee or contractor under the IRS, DOL and UK IR35 tests), state nexus and SUTA registration, FICA with wage-base tracking, FUTA with the SUTA credit and any credit-reduction-state adjustment, state SUTA by experience rating, UK PAYE income tax and Class 1 NIC, the UK Apprenticeship Levy threshold, the EU A1 certificate and Posted Workers Directive rules, benefits-in-kind valuation per jurisdiction, garnishment priority, the US Form 941, 940, W-2 and 1099-NEC series, the UK RTI submissions, plausibility and ghost-employee detection, and submission through the relevant US, UK and EU channels.

A concrete scenario: a US-headquartered enterprise SaaS company with USD 1.8B ARR, 4,200 US W-2 employees across 28 states, 380 UK PAYE employees, 240 EU employees across 8 Member States including 64 posted workers requiring A1 certificates, plus 320 US-based 1099 contractors. On a typical month, the Agent processes 4,200 US payrolls with FICA wage-base tracking on 380 employees crossing the USD 168,600 threshold, applies multi-state SUTA across 28 states with experience-rating updates from State Workforce Agencies, generates 380 UK PAYE payslips with FPS submission on or before each pay date, calculates UK Apprenticeship Levy 0.5% on the GBP 14M pay bill, issues 64 EU A1 certificates with PWD declarations to host-state authorities in 8 Member States, applies host-state minimum wage for 12 postings exceeding 12 months, calculates benefits in kind (company car, private medical, beneficial loans, equity awards) per jurisdiction, files Form 941 quarterly plus Form 940 annually, generates 4,200 W-2s plus 320 1099-NECs by 31 January, supplies Pillar Two GloBE SBIE 5% payroll component to the Withholding Tax Agent and Tax Provision Agent across 12 jurisdictions, and packages the evidence chain for SOX 404 inspection under PCAOB AS 2201, AS 2310, AICPA AU-C 240 and ISA UK 240.

In the [Decision Layer](/en/decision-layer/), 14 of the 16 steps are rule-based (R), 2 are LLM-suggestion (A) for worker classification and ghost-employee plausibility detection. There is no generative AI in any tax-rate determination, FICA-classification, PAYE-deduction, A1-issuance, or filing decision - the LLM never auto-files a return without payroll-team review acceptance.

## OECD Pillar Two GloBE 5% payroll SBIE changes payroll from cycle expense to per-quarter MNE-tax data layer

OECD Pillar Two GloBE Rules transform payroll into a per-jurisdiction tax-data substrate under ASC 740-10 / IAS 12 with continuous monitoring of the Substance-based Income Exclusion (SBIE). GloBE Rules Article 9.2 defines SBIE as 5% of payroll cost plus 5% of tangible asset value per jurisdiction (transitioning from 10%/8% in early years), and Excess Profit (GloBE Income minus SBIE) drives the top-up tax calculation. For MNE groups in scope (consolidated revenue at or above EUR 750 million), payroll directly determines top-up tax exposure - missing or misallocated payroll inflates Excess Profit and creates top-up tax that did not need to be incurred. The EU Pillar Two Directive (EU) 2022/2523 entered into force for fiscal years from 31 December 2023, with all 27 Member States transposing into national law; UK Multinational Top-up Tax and Domestic Top-up Tax under Finance (No. 2) Act 2023 apply IIR at UK UPE level plus QDMTT for UK Constituent Entities. The Agent aggregates per-jurisdiction payroll cost (base salary plus employer payroll taxes plus pension contributions plus equity compensation plus employee benefits, excluding capitalised payroll), applies the eligible-employee definition (excludes contractors plus certain seconded employees), allocates geographically with A1 plus PWD data feeding nuanced cross-border allocation, and supplies the SBIE payroll component to the Tax Provision Agent and Withholding Tax Agent. Pillar Two SBIE payroll data is now a primary PCAOB AS 2501 substantive-testing focus.

## Integration ecosystem: ADP, Workday, Paychex, Gusto, SAP SuccessFactors, Ceridian and Oracle HCM, with Mercans and CloudPay for global aggregation

The Agent integrates natively with the major payroll platforms: [ADP Workforce Now](https://www.adp.com/) plus ADP GlobalView with US Form 941/940/W-2/1099 plus 140+ country payroll service bureau aggregation; [Workday Payroll](https://www.workday.com/en-us/products/payroll/) with cloud-native US payroll plus Workday Financial Management integration for SOX 404; [Paychex Flex](https://www.paychex.com/) plus Paychex Enterprise with US payroll service bureau plus 401(k) plus ACA reporting; [Gusto](https://gusto.com/) plus Justworks plus [Rippling](https://www.rippling.com/) plus Trinet for SMB and mid-market US plus state nexus tracking; [SAP SuccessFactors Employee Central Payroll](https://www.sap.com/products/hcm/employee-central-payroll.html) plus SAP S/4HANA HCM for enterprise HRIS plus 50+ country localisations; [Oracle Fusion Cloud HCM](https://www.oracle.com/human-capital-management/) plus Oracle Payroll Cloud with US plus UK plus international payroll; [Ceridian Dayforce](https://www.ceridian.com/) with continuous calculation engine plus US plus Canada plus UK plus Australia; UKG Pro plus UKG Ready with US payroll service bureau model. For global multi-country aggregation: Mercans plus CloudPay plus ADP Celergo plus SafeGuard Global running 30+ country payroll through unified portals. For SOX 404 evidence chain: BlackLine Account Reconciliation plus BlackLine Tax Reporting for payroll tax accrual reconciliation plus Form 941 cycle close certification. Audit-evidence integration: Deloitte ASM, PwC Halo, EY Helix, KPMG Clara via standardised export formats with PCAOB AS 1215-compliant metadata. Submission channels: IRS e-Services Tax Pro plus IRIS for the Form 941, 940, W-2/W-3, 1099-NEC and 1095-C series, SSA Business Services Online for W-2/W-3 transmittal, HMRC RTI Government Gateway for FPS plus EPS plus P45/P60/P11D, EU Member State competent-authority portals for A1 issuance plus Posted Workers Directive declarations - all generated as deterministic templates with audit-trail metadata for IRS plus HMRC plus EU competent authority compliance plus PCAOB substantive testing under AS 2201, AS 2310, AICPA AU-C 240 and ISA UK 240.

--- Petty Cash Agent ---
> Captures cash receipts via AI extraction, checks small-amount invoices per Paragraph 33 UStDV.

The petty cash costs organisations disproportionately at tax audits - not because the amounts are large but because cash-handling deficiencies can devalue the entire bookkeeping. When the auditor finds gaps in the daily recording, they are entitled to estimate. In 2024, tax audits yielded roughly EUR 10.9 billion (approx. USD 11.8 billion) in additional tax assessments according to the Federal Ministry of Finance. Cash handling is among the first audit points because it is most frequently vulnerable.

## Cash Handling Determines the Outcome of the Tax Audit

Tax authorities scrutinise cash transactions more strictly than cashless ones. The legal basis is clear: fiscal code provisions require daily recording of all cash transactions, audit-compliant bookkeeping principles demand immutability and complete documentation, and since 2020, a technical security device (TSE) is mandatory for electronic cash registers. Since January 2025, electronic cash systems and their TSE must even be actively registered with the tax office. Violations of the TSE requirement can carry fines up to EUR 25,000 (USD 27,000).

The problem is not rule complexity. It is the time lag between receipt arrival and cash book entry. Anyone who retroactively enters Friday's cash receipts for the entire week violates the daily recording obligation - and gives the auditor leverage for tax-base estimations.

## Daily Recording Fails Against Day-to-Day Reality

In practice, the workflow rarely matches what audit-compliant bookkeeping principles prescribe. An office manager buys printer cartridges for EUR 47 (USD 51) in the morning, a colleague pays for a client lunch at EUR 189 in the afternoon, and a taxi receipt for EUR 23 arrives later. Three receipts, three different people, three different account codes. The handwritten cash book entry happens - if at all - at the end of the day from memory.

Every CFO who has been through a tax audit knows the result: receipts without dates in the cash book, incorrect running totals, missing daily reconciliations. For small-amount invoices up to EUR 250 (USD 270) gross, an additional risk applies. Simplified mandatory field requirements allow dispensing with a recipient - but if a recipient is named and the entry is incorrect, it can jeopardise the input tax deduction. Employees regularly overlook this subtlety.

## Seven Decision Steps Separate Routine from Judgement

The [Decision Layer](/en/decision-layer/) breaks the cash process into exactly the steps that distinguish a proper cash book from a challenged one. Of the seven decision steps, only one uses AI: receipt capture, where an LLM extracts relevant data from unstructured cash receipts - photos of slips, handwritten notes, faded thermal prints.

The next five steps are fully rule-based. The threshold check against the EUR 250 limit, the validation of mandatory fields, account coding by receipt type and amount, the cash book entry with audit-compliant timestamp and the numerical reconciliation of book versus actual balance - all follow deterministic rules with no discretion.

The seventh step stays with the human: when the cash balance diverges from the book balance, a person must clarify the cause. No algorithm can decide whether a EUR 14.50 difference traces back to a forgotten receipt, a counting error or something more serious. This boundary is deliberately drawn.

## Rule-Based Verification Closes the Gap Between Receipt and Cash Book

Picture Monday morning at a branch office with its own petty cash. The office manager photographs a weekend fuel receipt - EUR 62. Within seconds, the agent extracts amount, date and tax rate, recognises the receipt as a small-amount invoice, checks the simplified mandatory fields, posts to the correct account and enters the transaction with a timestamp in the cash book. Before lunch, the daily reconciliation shows: book balance EUR 843.50, counted balance EUR 843.50, no difference.

When on Wednesday the actual balance is EUR 12 below the book balance, the agent documents the discrepancy and escalates to the cash custodian. Not to an algorithm. Cause clarification for cash differences is a tier 1 decision - it demands human judgement because the possible reasons are too varied to capture in rules.

The outcome for the next tax audit: every cash transaction is recorded on the day of the business event, linked to a receipt and chronologically documented. The procedural documentation the tax authority demands is not created after the fact for the auditor - it emerges as a by-product of the daily process.

--- Posting QA Agent ---
> Checks every posting for formal completeness, plausibility, account consistency and tax code correctness.

## One Third of Accountants Report Multiple Errors Per Week

A 2024 Gartner survey shows: 33 percent of accountants surveyed report making multiple posting errors per week. The primary reason is not carelessness but capacity constraints. Rising regulatory requirements and volatile business conditions increase posting volume while team sizes stagnate.

Picture a Finance department with 4,000 postings per day. At an error rate of three to five percent - the typical range for manual entry processes - that produces 120 to 200 incorrect entries daily. Not every one is material. But each can become a correction posting at month-end if nobody catches it first.

## Errors in the General Ledger Cost Multiples at Close Time

An incorrect VAT (US: sales tax equivalent) code on an incoming invoice takes seconds to fix at entry. If that same posting reaches the general ledger, a cascade begins: reconciliation variance in the VAT verification, query to the clerk, receipt research, reversal posting, re-posting, renewed approval. One second of correction becomes 15 to 30 minutes of effort.

Multiplied across hundreds of correction postings per month-end close, the entire closing window shifts. Controllers wait for cleaned balances. Statutory auditors flag recurring patterns. And Finance leadership loses confidence in the numbers they report weekly to the board.

The economic lever therefore lies not in accelerating the close but in the quality of the individual posting. What enters the general ledger cleanly needs no correction.

## Eight Check Steps Replace the Manual Sample

The [Decision Layer](/en/decision-layer/) breaks posting quality assurance into eight discrete decisions. Six are fully rule-based: formal completeness (document, account, amount, date present?), account consistency (debit and credit accounts compatible?), VAT code consistency (does the tax code match the posted account?), period cut-off (document date and posting period align?), duplicate detection (amount, account and date already captured?) and the final routing decision.

The two remaining steps use historical patterns: the plausibility check compares every amount with the typical ranges of the respective account group. The anomaly score aggregates all individual checks into an overall assessment and prioritises escalation.

The sequence matters. Rule-based checks run in milliseconds. Only postings that pass all formal checks reach the more computationally intensive pattern analysis. In practice this means: over 95 percent of all postings pass the complete check chain without human intervention.

## The Normal Case Passes Without Escalation

With well-maintained master data, two to five percent of postings are escalated. The anomaly score determines the order - the most conspicuous entries appear first on the clerk's screen. Instead of spot-checking 4,000 postings daily, the team focuses on 80 to 200 prioritised cases.

Every escalation that proves harmless improves the model. Plausibility thresholds calibrate through feedback: mean plus standard deviations per account group as the starting basis, refined through daily practice. After three to six months, the false positive rate drops measurably.

For the tax audit, the Decision Layer documents every decision: which checks were performed, which passed, which failed, the anomaly score, and whether the posting was auto-approved or escalated. The ICS becomes not only more effective but demonstrably so - to statutory auditors, supervisory bodies and the board.

## Posting Quality Determines Close Speed

Companies that systematise their posting quality assurance consistently report shorter closing cycles and fewer correction postings at month-end. EY estimates that over 70 percent of all journal entries are automatable. The question is not whether the check is automated but how transparent the decision logic remains.

The Posting QA Agent operates at Decision Layer tier 1 to 2: rule engine for formal checks, AI support for plausibility and anomaly detection, human decision only for escalated anomalies. No posting error stays invisible, no check step goes undocumented - and the month-end close begins with balances that Finance leadership can rely on.

--- Procedural Documentation Agent ---
> Detects process changes automatically, checks existing documentation for currency.

Procedural documentation exists in most organisations. Rarely is it current. Precisely this gap between documentation state and process reality becomes a problem at tax audits - because the auditor does not ask whether documentation exists, but whether it reflects the actual state.

## Tax Auditors Request the Documentation First

In 2023, tax auditors assessed EUR 13.2 billion (approx. USD 14.3 billion) in additional tax across 146,516 audited entities (Federal Ministry of Finance monthly report, October 2024). At the start of an audit, auditors increasingly request the procedural documentation before they begin the substantive review. The reason is pragmatic: outdated or incomplete documentation signals inadequate process controls - and justifies deeper audit procedures.

The legal consequence is clearly regulated. When missing or deficient procedural documentation impairs the traceability of the bookkeeping, this constitutes a formal deficiency with substantive weight. The auditor can then reject the bookkeeping and estimate the tax base. In practice: a documentary deficiency becomes a financial risk before any substantive error has been found.

## Every Process Change Creates a Documentation Gap

The real problem is not the initial creation. Most Finance departments have built a procedural documentation at some point - often as part of a project, often with external consultants. The problem begins the day after completion.

A new ERP module goes live. An approval workflow is adjusted. Another agent takes over a validation task. Each of these changes should be reflected in the procedural documentation - in the general description, the technical system documentation, the authorisation concept and the ICS description. In practice, this does not happen promptly because nobody has the trigger. The change goes to production, the documentation stays. Over months and years, a growing gap emerges between what is documented and what actually happens.

## Automated Monitoring Closes the Gap in Real Time

The Procedural Documentation Agent continuously monitors the configurations of tax-relevant systems. When a process changes - a new rule, a new agent, a changed authorisation - it detects the divergence between documented target and actual state. It checks the existing documentation against an audit-compliance checklist, identifies the affected sections and generates an update draft.

The decision logic separates cleanly by complexity. Whether something changed - the agent detects independently. Whether the documentation still matches reality - it checks automatically. Which regulatory requirements apply and how authorisations are documented follows a fixed rule set. But whether the overall documentation is complete and whether a draft is approved - that is the human's decision. The agent delivers the draft, not the signature.

## The Documentation Documents Itself

The Procedural Documentation Agent has a unique property within the [Decision Layer](/en/decision-layer/): it is simultaneously tool and subject of the documentation. Every change it detects and documents is logged with timestamp, change type and processing status. This creates a complete change log - not as a separate requirement but as a by-product of normal operations.

For the tax audit, this concretely means: the procedural documentation is not only current but its currency is provable. The auditor sees not just today's state but the entire change history - when which process was adjusted, when the documentation followed, who approved. The most frequent point of objection loses its basis.

## Procedural Documentation Becomes Ongoing Infrastructure

Classic procedural documentation is a project deliverable - created once, rarely updated, hastily revised for the audit. The Procedural Documentation Agent turns it into part of the operational infrastructure. Changes are detected before they become gaps. Drafts are ready before anyone asks. Audit compliance is not established at the audit but continuously assured - with human approval as the final gate.

--- Provisions Agent ---
> Identifies provision types, calculates leave and bonus provisions deterministically.

Provisions are the perennial focus of every financial audit because recognition and measurement rest on assumptions and estimates. The Provisions Agent cleanly separates what can be calculated from what requires human judgement - and makes both parts audit-proof.

## Provisions Are the Perennial Focus of Every Financial Audit

No other balance sheet item attracts such regular scrutiny from statutory and tax auditors. Professional accounting bodies describe provisions explicitly as a "perennial topic" of audit season, because both recognition and measurement under commercial law and IAS 37 rely on assumptions that management must make. Enforcement authorities have repeatedly placed asset impairments and related valuation questions among their national audit priorities.

The reason is structural. A leave provision follows a clear formula. A litigation cost provision depends on the legal assessment of success probability. A warranty provision rests on historical claims experience. Three provisions, three entirely different origination logics - and in many Finance departments they still end up in the same spreadsheet template, manually carried forward each year. The statutory auditor sees a result at the end, but not which portion was calculation and which was judgement.

## Leave and Bonus Provisions Can Be Formed Fully Deterministically

The [Decision Layer](/en/decision-layer/) breaks provision formation into eight steps. Three are pure calculation rules that require no estimation. The leave provision derives from outstanding leave days multiplied by the average daily rate including employer social insurance contributions. The bonus provision follows the contractual basis and the current earnings forecast. The journal entry derives deterministically from the provision type.

For a mid-sized industrial company with 800 employees that previously spent three working days in January transferring leave data from HR time tracking into a spreadsheet, the agent takes over this run monthly. Data comes directly from the ERP and personnel master data. The result is not an estimate but a traceable per-employee calculation. For the statutory auditor, the question is no longer whether the amount is plausible but only whether the calculation inputs are correct. This shortens the audit from sample testing with follow-up queries to a pure methodology check.

## Warranty and Litigation Costs Remain Human Decisions

Two steps in the pyramid are deliberately not automated. Warranty provisions rest on historical claims experience and company-specific judgement that no rule engine can fully replicate. Litigation cost provisions depend on legal assessments of success probabilities that require evaluation by in-house counsel or external law firms.

Here the agent delivers not the result but the decision basis. For warranties, it aggregates claims and goodwill data from the past three years, calculates rates by product group and provides the foundation for the rate estimate. For litigation, it pulls claim amounts, prior legal costs and court instance from the legal department and hands the template to the human decision-maker. The final rate and the final provision amount stay with the human - but they are made from a structured data set, not from memory.

## The Decision Layer Documents Every Valuation Audit-Ready

What matters for the statutory auditor is not whether a provision was calculated or estimated. What matters is whether the basis is documented. The Provisions Agent records per provision: type, calculation method, input data, result, the label deterministic or judgement-based, prior-year comparison and rationale for every deviation. At year-end, this produces a provisions schedule that can be submitted as an annex to the annual financial statements.

Notes disclosures under commercial law or IAS 37 are prepared as LLM drafts. This does not mean the accountant accepts them unchanged. They review whether the wording fits the valuation and approve. For Finance teams that need every hour twice during closing season, the work shifts from writing to reviewing - and above all away from the recurring auditor question of how a particular figure was derived.

--- Purchase Requisition Agent ---
> Detects procurement demand from consumption data, checks cost centre budgets, suggests preferred vendors.

The purchase requisition is the most expensive decision in the entire purchase-to-pay process - not because of its own value, but because it determines whether negotiated conditions ever take effect. Anyone who selects the wrong vendor here, orders outside the framework agreement or overlooks budget limits destroys savings before the first invoice enters the system. The Purchase Requisition Agent anchors framework agreements, budget authority and approval matrices directly in the ordering process - and releases human judgement only where it makes a difference: above the threshold.

## Maverick Buying Costs Finance Organisations Up to 16 Percent of Negotiated Savings

The data is clear: according to APQC, organisations with high maverick buying rates need a median of 16 hours longer to issue a purchase order, and lose between 10 and 16 percent of savings between the negotiated framework and actual procurement. Hackett Group reports in its Digital World Class Benchmark 2025 that top performers lose 60 percent fewer savings through consistent contract compliance and reduced maverick buying compared to the average. The lever is not in procurement - it is at the moment of the purchase requisition. Whoever decides here decides on the margin.

In mid-sized Finance organisations, the reality looks like this: hundreds of requisitions per day flow through departments that neither know the framework agreements nor the remaining cost-centre budgets. The result: orders placed with the wrong vendor, call-offs without framework agreement reference, overruns that only surface at month-end. Each one is a lost negotiation.

## The [Decision Layer](/en/decision-layer/) Breaks the Requisition into Seven Traceable Steps

The Purchase Requisition Agent cleanly separates the seven decisions in every requisition by responsibility. Demand detection from consumption data runs as ML-supported forecasting, for instance when minimum stock levels for consumables are breached. Budget check, vendor suggestion, framework contract conditions, approval workflow and order generation are fully rule-based - numerical comparisons and master data logic, no discretion.

Concretely: a department triggers a requirement for EUR 8,400 (USD 9,100) in maintenance material. The agent checks in under one second whether the cost centre has sufficient remaining budget, identifies the preferred vendor from master data, pulls framework contract conditions (price, minimum quantity, lead time), determines the approver via the approval matrix and generates the order. Contract compliance here is not the result of good intentions but the default.

The effect on cycle time: APQC benchmarks show that top performers achieve a requisition-to-order time of five hours while weak processes take around 48 hours. A rule-based Decision Layer brings routine orders into the minutes range - without sacrificing documentation.

## Human Judgement Stays Where It Matters Commercially

Not every order can be processed rule-based. Individual orders above a defined threshold - say EUR 25,000 (USD 27,000) or a cost-centre-specific limit - require deliberate judgement: market conditions, strategic supplier relationships, extraordinary urgency. Here the agent steps back. It prepares the decision completely (budget status, contract availability, alternative vendors, approval chain), presents it to the authorised decision-maker and documents the human approval as an explicit step in the audit trail.

This principle is not a safety net - it is governance architecture: the human approval is an internal control element and part of the audit-compliant documentation obligation. Every purchase requisition - whether rule-based or human-approved - is fully traceable as a business transaction.

## Framework Agreements Move from Paper to Infrastructure

The real gain lies beyond the individual order: the framework agreement engine the agent uses becomes shared infrastructure in the Decision Layer. The Contract Compliance Agent accesses the same contract logic. The approval matrix is reused by the Invoice Approval Agent and Payment Run Agent. The generated order becomes the reference for three-way matching between order, goods receipt and invoice. What begins as automation of a single task progressively builds the decision infrastructure on which the entire P2P process rests.

--- Receivables Management Agent ---
> Calculates receivables ageing structures, assesses default risks via ML model, determines bad debt allowance requirements and monitors credit limits.

Receivables management is not a diligence exercise for accounts receivable clerks - it is a balance sheet question for the CFO. Anyone who merely administers open items instead of evaluating them discovers defaults only at year-end - and by then they are expensive. The Receivables Management Agent shifts detection forward: ageing structure, default risk and bad debt allowance requirements are calculated continuously so strategic decisions can be made in time.

## Default Risk Has Become a Balance Sheet Question in 2025

The figures from Creditreform make the urgency clear: in 2025, 23,900 companies filed for insolvency in Germany, an 8.3 percent increase over the prior year and the highest level in more than a decade. The estimated damage stands at approximately EUR 57 billion (USD 62 billion), averaging more than EUR 2 million per insolvency case. For mid-sized creditors, this means: every open item is potentially a balance sheet risk, not just a liquidity question.

In this environment, optimising the dunning run is not enough. What matters is which receivables are realistically collectible, which require bad debt allowances and which are better sold or legally pursued. This assessment needs reliable data on payment behaviour, ageing structure and external creditworthiness - not once per quarter, but continuously.

## The [Decision Layer](/en/decision-layer/) Separates Calculation from Valuation

The Receivables Management Agent breaks the process into eight decision steps along the Decision Layer. The separation is clear: arithmetic and rule checks run automated, discretionary decisions stay with the human.

The receivables ageing structure is a calculation from due dates - rule-based, no discretion. The same applies to credit limit monitoring: a threshold check against configured limits. Default risk scoring uses an ML model combining payment behaviour, industry risk and external credit data. With 24 months of clean history, such models typically achieve 80 to 85 percent accuracy in predicting payment defaults.

Strategic decisions stay with the CFO or head of Finance. General bad debt allowances can be proposed rule-based; specific allowances require individual judgement because they carry immediate tax consequences under commercial and tax law. Payment arrangements, factoring assessments and legal escalation weigh customer relationships, costs and risk - not rules, but negotiation.

## A Concrete Scenario: Industrial Customer with EUR 7 Million in Receivables

A mid-sized machine builder with approximately EUR 180 million (USD 195 million) in revenue carries around EUR 7 million in open receivables. Accounts receivable diligently maintains ageing structures and dunning runs, but the risk picture emerges only at month-end - too late for an operational response.

With the Receivables Management Agent, the assessment runs daily: ML scoring flags a major customer whose payment behaviour has deteriorated over the past six weeks, even though the credit limit has not yet been breached. The agent documents the risk score, the contributing factors and the current ageing structure. The CFO sees the warning the same day and decides: reduce the credit limit, switch delivery to prepayment, inform sales. The decision remains human; the data basis arrives in minutes instead of weeks.

At quarter-end, the agent delivers the data foundation for bad debt allowance requirements: general allowance by ageing structure, candidates for specific allowance with documented scoring. The statutory auditor receives a traceable record per valuation - risk score, method, calculation basis. Audit-compliant, audit-proof, reproducible.

## The agent owns ageing and risk scoring, humans keep instalments and escalations

The agent is not a collections tool and not a substitute for the customer relationship. It delivers three things: a continuously current receivables ageing structure, a risk-weighted picture of the debtor portfolio and a documented basis for bad debt allowance decisions. Reporting covers DSO, ageing report, default risk heatmap and credit limit utilisation, configurable to the CFO cockpit's KPIs.

What the agent deliberately does not do: it does not decide on instalment plans, does not sell receivables, does not autonomously escalate to the legal department. These steps remain strategic and human - precisely where negotiation skill, customer knowledge and cost-benefit analysis matter. The Decision Layer makes transparent who decided what and when, and delivers the evidence on which the decision rested.

--- Reconciliation Agent ---
> Matches subledgers against the general ledger, assigns open items, flags unexplainable differences and creates reconciliation reports.

Account reconciliation is the bottleneck of the month-end close - and it becomes a bottleneck because it happens at the cut-off date. The [Decision Layer](/en/decision-layer/) shifts it into the running month, separates rule-based matching from human judgement and makes every reconciliation provable for the statutory auditor at any time.

## The Cut-Off Date Is the Actual Flaw in the System

Hundreds of accounts, thousands of open items, five working days: that is what reconciliation week looks like in most Finance departments. Half of finance teams take longer than a week for the month-end close according to APQC benchmarks, and only a minority close in three days or fewer. Meanwhile, The Hackett Group shows that accountants spend a substantial share of their working time on manual low-value processes like account reconciliation.

The problem is not the volume of postings but the timing. Anyone who posts for three weeks and begins comparing balances on the 30th has self-created the clarification backlog. Every difference that surfaces on the cut-off date is at least 15 days old. Documents are scattered, clerks have lost context, and the statutory auditor is waiting. The bottleneck arises not from volume but from simultaneity.

## Continuous Reconciliation Dissolves the Deadline Pressure

The Reconciliation Agent checks at every posting against the configured account list whether subledger and general ledger still agree. Receivables, payables, bank, fixed assets, clearing accounts: balances are continuously compared, not monthly frozen. Differences appear the moment they arise - not three weeks later when nobody remembers which posting caused them.

This fundamentally changes the accountant's task. Instead of clarifying hundreds of accounts simultaneously at the cut-off date, the team works daily worklists with a handful of open points. The load distributes across the month; the close itself becomes confirmation of an already reconciled state. For the CFO, this means shorter close cycles without additional headcount - and for the department, a working routine without the recurring month-end crunch.

## The Decision Layer Separates Computation from Judgement

Reconciliation breaks into eight clearly defined decision steps. Seven are computation: which accounts belong on the list, do balances agree, which open items explain the difference, what approval status has been reached. These steps run rule-based, deterministically and logged. Open-item assignment combines exact matching with fuzzy matching for partial payments and rounded amounts. Unusual residual differences are flagged by the agent via pattern matching for review.

A single decision stays with the human: the materiality assessment. Is a residual difference of EUR 340 (USD 370) on a clearing account material or not? This question depends on context, trend and judgement, and is deliberately not automated. The agent presents the difference with all relevant information; the clerk decides. This is tier 1 to 2 in the Decision Layer: high automation in execution, clear human reservation on assessment. Every decision is written to the reconciliation report with timestamp, author and rationale - the foundation for every financial audit.

## The Close Becomes Routine Instead of a Sprint

Implementing continuous reconciliation changes not just the workflow but the expectation profile of the month-end close. The reconciliation report is available at any time, not only at cut-off. The statutory auditor can review during the running month which accounts are reconciled and with what evidence level. Open points are no longer last-minute surprises but a maintained worklist.

For leadership, this means three things: predictable close dates instead of overtime cycles, a reliable number basis for forecasts and reporting during the month, and an audit trail that does not merely comply with proper bookkeeping standards but visibly demonstrates compliance.

--- Revenue Recognition Agent ---
> Cross-jurisdictional revenue pipeline: IFRS 15 plus ASC 606 five-step model, variable consideration, significant financing component, principal-vs-agent, SOX 404.

International revenue recognition runs on two converged but materially different standards at once: IFRS 15, used across 144 jurisdictions including all 27 EU Member States and the UK, and ASC 606 under US GAAP, with five reconciling differences in the collectability threshold, the variable-consideration constraint, licence accounting, sales-tax presentation, and shipping and handling. A US-headquartered group with EU subsidiaries on IFRS 15 and a US parent on ASC 606, a UK listed entity moving its FRS 102 accounts towards IFRS 15, and a dual-listed group must run parallel calculations across both standards while applying seven judgement-intensive determinations: the performance-obligation distinct test, the transaction price with its variable-consideration estimation, the constraint (highly probable under IFRS 15, probable under ASC 606), the significant financing component, the principal-versus-agent assessment, the over-time-versus-point-in-time test, and contract-modification accounting. Layer over this SOX 404 control attestation where revenue is the most-frequent material-weakness area, the AS 2401 fraud-risk presumption, AS 3101 Critical-Audit-Matter disclosure (performance-obligation identification is a CAM in roughly 38 percent of S&P 500 audits), and the FRC and ESMA enforcement priorities that have applied every year since IFRS 15 took effect in 2018, and revenue recognition becomes the most judgement-intensive process in the multinational finance function.

## A single revenue error can cascade into an uncertain-tax-position disclosure and class-action exposure

Revenue recognition is the most-frequent SEC restatement area, accounting for approximately 63 percent of all SEC enforcement actions related to restatements per Cooley PubCo on SEC Enforcement, and the most-frequent SOX 404 material weakness area for SEC registrants per 2024 PCAOB inspection findings. SEC AAER (Accounting and Auditing Enforcement Releases) targeting revenue recognition account for 50-67 percent of all AAERs since 2018 per Cornerstone Research analysis - the dominant pattern is variable consideration overestimation that subsequently does not materialise (approximately 50% of revenue AAERs), followed by performance obligation identification errors leading to premature recognition, and principal-versus-agent presentation errors leading to revenue overstatement. PCAOB inspection findings cite revenue cycle in top-3 deficiency areas across all four firms (Deloitte, PwC, EY, KPMG) every year since 2018, with performance obligation identification specifically cited as Critical Audit Matter under AS 3101 in approximately 38 percent of S&P 500 audits per 2024 inspection cycle. KPMG updated its IFRS 15 handbook again in July 2025 because IASB reviews confirmed the complexity lies not in calculation logic but in the need for end-to-end judgement documentation - the seven judgement-intensive decisions (performance obligation distinct test, transaction price including variable consideration, variable consideration constraint, allocation methodology, principal versus agent assessment, over-time versus point-in-time, contract modification accounting) each require structured human accounting expertise with documented criteria. For SEC-registered S&P 500 multinationals, a single revenue recognition error compounds into an uncertain tax position disclosure under ASC 740-10 and IAS 12, a Big-4 auditor concurrence challenge under the PCAOB revenue and fraud standards, the SEC Division of Corporation Finance comment letter process, and a class-action plaintiff lawsuit alleging securities fraud - the cumulative downside exposure from these four cascade modes typically exceeds USD 50 million for material restatements.

## The revenue-recognition pipeline runs 16 steps, not the 8-10 of a single standard

Single-standard revenue recognition can be modelled in 8-10 steps; running IFRS 15 and ASC 606 together with full judgement support cannot. The Agent splits the pipeline into 16 steps because every contract needs the five contract criteria checked (approval, identifiable rights, payment terms, commercial substance, collectability), the contract data LLM-extracted and performance obligations proposed, the distinct test applied with its two criteria and three integration indicators, the transaction price determined with variable-consideration method selection and a significant-financing-component assessment, the constraint applied through a five-factor susceptibility analysis, allocation made on observable standalone selling prices or one of three estimation approaches, the principal-versus-agent call made on three control indicators, the over-time-versus-point-in-time test applied, progress measured by output or input method, modifications resolved into one of three outcomes, sales returns and the assurance-versus-service warranty distinction handled, the journal entries and contract balances posted, the disclosure notes drafted, and the PCAOB AS 2401 fraud-risk patterns (channel stuffing, bill-and-hold without substance, side letters, unusual cut-off entries) detected.

A concrete scenario: a US-headquartered enterprise software vendor with USD 2.4 billion ARR, dual-reporting under ASC 606 at the parent and IFRS 15 across the EU and UK subsidiaries, running 8,400 enterprise customer contracts including 3,200 multi-element arrangements (licence plus implementation plus support), 4,800 SaaS subscriptions with variable consideration triggers, plus 320 reseller arrangements. On a typical month, the Agent processes 280 new contracts plus 920 modifications, applies the IFRS 15.27 and ASC 606-10-25-19 distinct test with human accountant judgement on whether implementation modifies the licence sufficiently to constitute a single performance obligation, estimates variable consideration on 480 contracts using expected value method and 60 using most likely amount, applies the IFRS 15.56 and ASC 606-10-32-11 constraint with reassessment trail, calculates significant financing component on 24 contracts exceeding the one-year practical expedient threshold, assesses principal-versus-agent on 320 reseller contracts with three-indicator control analysis, determines over-time versus point-in-time, calculates progress using cost-to-cost on 240 implementation contracts and time-elapsed on 4,800 subscriptions, accounts for 920 modifications with three-outcome determination (separate contract for 540, termination-and-new for 240, cumulative catch-up for 140), drafts disclosure notes covering disaggregation plus contract balances plus remaining performance obligations of USD 4.8 billion, runs PCAOB AS 2401 fraud risk pattern analysis plus cut-off testing plus channel-stuffing signals plus bill-and-hold legitimacy checks, and supplies IFRS 15 versus ASC 606 reconciliation report covering all five reconciling differences for dual-reporting purposes.

In the [Decision Layer](/en/decision-layer/), 6 of the 16 steps are rule-based (R) for deterministic calculation steps, 7 are human judgement (H) for accounting decisions reflecting the reality of IFRS 15 and ASC 606 (the standards are intentionally judgement-intensive at seven points), and 3 are LLM-suggestion (A) for contract data extraction, disclosure note drafting and fraud risk pattern detection. There is no generative AI in performance obligation distinct determination, transaction price calculation, variable consideration constraint, principal versus agent assessment, or revenue recognition timing decision - the LLM never auto-determines accounting outcomes without human accountant review acceptance. The Decision Layer pattern is software prepares judgement; software does not delegate judgement.

## IFRS 15 versus ASC 606 reconciliation transforms revenue recognition into dual-standard parallel calculation engine for SEC-registered IFRS-reporting multinationals

The IASB and FASB joint convergence project produced IFRS 15 and ASC 606 with substantively identical five-step models, but five reconciling differences require parallel calculation for dual-reporting entities. Difference 1 (Collectability Threshold): IFRS 15.9(e) requires consideration to be 'expected' (>50% likelihood); ASC 606-10-25-1(e) requires it to be 'probable' (75-80% per US auditor convention) - this can result in IFRS 15 contract identification before ASC 606 contract identification, creating timing differences. Difference 2 (Variable Consideration Constraint): IFRS 15.56 requires 'highly probable'; ASC 606-10-32-11 requires 'probable' - the thresholds are not identical and dual-reporting entities reconcile and disclose. Difference 3 (Licence Accounting): IFRS 15 distinguishes between right-to-use (point-in-time) and right-to-access licences (over-time) based on entity continued involvement; ASC 606 has substantively similar but operationally different test. Difference 4 (Sales Tax Presentation): IFRS 15 allows policy choice on gross versus net; ASC 606-10-32-2A explicitly permits net presentation. Difference 5 (Shipping and Handling): IFRS 15 requires separate performance obligation assessment; ASC 606-10-25-18B provides practical expedient for fulfilment activity treatment. The Agent's dual-standard parallel calculation engine produces both IFRS 15 and ASC 606 results with a reconciliation report - a required Big-4 audit substantive testing artefact under PCAOB AS 2110 and ISA UK 540 for dual-reporting entities. UK FRS 102 March 2024 amendments effective for fiscal years beginning 1 January 2026 align FRS 102 Section 23 Revenue with the IFRS 15 five-step model - the Agent supports quad-standard reporting across FRS 102, FRS 101, IFRS 15 and ASC 606 for UK groups with a US SEC parent.

## Integration ecosystem: Workday Revenue, SAP S/4HANA RAR, Oracle Revenue Management Cloud, Zuora RevPro, NetSuite, Aptitude, plus Big-4 proprietary audit tools

The Agent integrates natively with the major revenue recognition platforms. [Workday Revenue Management](https://www.workday.com/en-us/products/revenue-management/) provides a cloud-native ASC 606 and IFRS 15 five-step engine, with Workday Financial Management supplying the SOX 404 evidence chain. [SAP S/4HANA Revenue Accounting and Reporting (RAR)](https://www.sap.com/products/financial-management/revenue-accounting-reporting.html) integrates tightly with SAP S/4HANA Sales, SAP CPQ and SAP Subscription Billing. [Oracle Revenue Management Cloud Service](https://www.oracle.com/erp/revenue-management/) connects to Oracle CPQ and Oracle Subscription Management, with Oracle EPM Cloud for forecasting. [Zuora RevPro](https://www.zuora.com/products/revpro/) serves the subscription economy alongside Zuora Billing and Zuora CPQ. [NetSuite Advanced Revenue Management](https://www.netsuite.com/portal/products/erp/financial-management/revenue-recognition.shtml) and [Sage Intacct Contract and Revenue Management](https://www.sageintacct.com/financial-management-software/revenue-recognition-software) cover the mid-market, and Aptitude Software RevStream covers enterprise telecom and life sciences. The contract repository can sit on Conga CLM, Salesforce Revenue Cloud, DocuSign CLM or Ironclad. Close certification and contract-balance roll-forward run through the BlackLine reconciliation, variance-analysis and journal-entry modules. Audit-evidence integration spans Deloitte ASM, PwC Halo, EY Helix and KPMG Clara with PCAOB AS 1215-compliant metadata. Submission flows to SEC EDGAR for the 10-K, 10-Q and 8-K, to UK Companies House for statutory accounts, and to the EU Member State filing portals (Bundesanzeiger, INPI, Registro Mercantil) - all with audit-trail metadata for SEC, FCA, ESMA and competent-authority compliance, and for PCAOB, AICPA and ISA UK substantive testing.

--- Social Insurance Reporting Agent ---
> Determines reporting occasions, creates DEUEV-compliant reports, transmits electronically to health insurance funds and processes return messages.

Social insurance reporting is the most heavily regulated routine process in payroll accounting. Every registration, de-registration, annual report, interruption and contribution change is reportable, deadline-bound and liability-critical. Germany's pension authority collects more than half a billion EUR annually in back-payments from audits; in roughly 800,000 audited businesses, auditors flag incorrect or missing reports in about one third of cases. For CFOs, this is not a payroll topic but a personal liability risk.

The Social Insurance Reporting Agent resolves precisely this risk by mapping the ten decisions of a social insurance report fully rule-based: determine the reporting occasion, check the submission reason, assemble report data, assign the contribution group key, create the DEUEV file, validate the data record, check the deadline, transmit on time, process the return message, and cancel and resubmit faulty reports. Zero AI component, zero discretion, zero hallucination. This is the reason for the highest readiness score in the entire Finance catalogue.

## The Liability Reality Behind the Routine

The figures from social insurance audits show how costly negligence becomes: according to DRV statistics, several hundred million euros in back-contribution demands are levied each year, with roughly 30 percent of audited employers having reporting deficiencies. On top come penalty surcharges of one percent per month commenced on every overdue contribution, assessment periods of up to 30 years, and a burden-of-proof reversal: the employer must credibly demonstrate that the reporting omission was not at fault.

In practice, errors rarely arise from intent. They arise because a personnel change causes a "de-registration on departure" to collide with the wrong contribution group key, because an annual report formally fails and nobody checks the health fund's return message, because a mini-job exceeds the earnings limit and jurisdiction shifts from the mini-job centre to the health fund. Each of these cases is a rule-based decision tree - and each can be mapped deterministically.

## Ten Decisions, Zero AI Component

The [Decision Layer](/en/decision-layer/) breaks the social insurance report into ten micro-decisions that all share the same character: input from the payroll system, rule from social insurance code or DEUEV, unambiguous output. The reporting occasion follows from the personnel master data change. The contribution group key follows from insurance status, employment type and earnings. The DEUEV format is technically specified. Transmission runs via the standardised interface to the responsible fund. The return message is parsed and on rejection matched against a rule set that knows the most common error constellations.

This architecture makes the agent the counter-example to every discussion about AI compliance. Where no AI operates, there are no AI risks. The EU AI Act (UK: UK AI regulatory framework) is not applicable because no probabilistic decision is made. Social insurance audits accept the Decision Layer as payroll documentation because every report is documented audit-proof with reporting occasion, timestamp, rule path and transmission receipt.

## Scenario: 1,200 Employees, Twelve Months, Zero Findings

A group with 1,200 socially insured employees across three entities generates between 40 and 80 DEUEV reports per month: joiners, leavers, interruptions, changes, special reports. Before the agent, the January reporting week (annual reports) regularly took ten days, the error rate on return messages was four to six percent, and the 2022 social insurance audit ended with a back-payment demand of EUR 180,000 (USD 195,000) plus penalty surcharges.

After implementing the Social Insurance Reporting Agent, every master data change is immediately translated into a reporting decision. Annual reports for 1,200 employees are created and transmitted in 90 minutes. Health fund return messages are machine-parsed. Rejected reports that are rule-correctible run automatically; the rest lands in the clerk's cockpit with error code, rule reference and resolution suggestion. The 2026 audit is a two-day appointment because the auditors can self-serve every report via the process documentation interface.

## Audit-Proof Documentation as a By-Product

The real effect arises not in report creation but in documentation. Every decision is stored with input data, rule path, output dataset and return message. The social insurance audit finds a complete reporting history in which every individual report can be reconstructed - including the exact rule state at the time of reporting. Questions like "Why was Mr Smith reported with contribution group 1111 instead of 6100 in March 2024?" are answered in under a minute, with citation of the applied rule.

--- Tax Audit Preparation Agent ---
> Tax audit readiness: audit-order analysis, IDEA-format export per GDPdU, Z1/Z2/Z3 access setup, risk-area identification, auditor-question routing - shortens prep from weeks to hours.

A tax audit is not an exceptional event for large enterprises - it is a permanent condition. Anyone who treats the audit period as an emergency loses. Anyone who organises it as a continuous discipline reduces provisions, shortens audit duration and gains negotiation confidence. The Tax Audit Preparation Agent shifts Finance from reactive file production to permanently audit-ready.

## Why Classic Audit Preparation Costs CFOs Money

The Federal Ministry of Finance reported additional assessments of approximately EUR 10.9 billion (approx. USD 11.8 billion) from 140,764 tax audits in 2024 - with 12,359 auditors nationwide and an audit rate of 1.6 percent. Large enterprises and groups are subject to continuous audits, meaning they are audited seamlessly and on a rotating basis. For CFOs, the question is not whether the next audit comes but when. (US: IRS examination rates for large corporations are considerably higher; UK: HMRC's Business Risk Review achieves similar continuous coverage for large businesses.)

Classic preparation starts with the audit order. From that moment, the company typically has two to three weeks to prepare data in IDEA format and provide all three access modes (Z1 direct system access, Z2 indirect access via evaluations, Z3 data carrier provision). During these weeks, the tax department, IT and external advisors rotate in crisis mode. Answers to auditor questions are produced under time pressure. Historical decisions are reconstructed from files whose authors have long since left the company. The result is predictable: higher provisions, weaker negotiation position, longer audit cycles.

The problem is not the audit itself - it is the structural break between ongoing operations and audit preparation. Every decision that was not documented at the time of the business transaction must later be reconstructed. That is where the additional assessments originate.

## What the [Decision Layer](/en/decision-layer/) Changes

The Tax Audit Preparation Agent is not a tool switched on in an emergency. It is the integration point for all other Finance agents. Bookkeeping compliance, account coding, VAT, withholding tax, transfer pricing - each of these decisions is made where it originates and documented in machine-readable form. The agent condenses this documentation at any time into an audit-ready data set.

The work splits into three clearly separated roles. Rule-based steps are handled by automation without discretion: database queries by audit period and tax type, IDEA export per GDPdU standard, preparation of Z1/Z2/Z3 access. Hours instead of weeks. AI-supported steps contribute pattern recognition: the audit order is interpreted, historical audit focus areas are compared, auditor questions are routed to the responsible department. Human decisions remain where they belong: argumentation strategy, tax structuring risk assessment and provision estimation. These steps are explicitly Human-in-the-Loop because they require professional judgement and negotiation experience.

## Scenario: How a Continuous Audit Runs in the Decision Layer

A group headquartered in Germany receives an audit order for the years 2022 to 2024. The audit covers corporate income tax, trade tax, VAT and a separate transfer pricing documentation request. The agent analyses the order within minutes, maps requirements to the responsible agents and creates a preparation plan with estimated effort and open risk clusters.

Data compilation - typically the most expensive phase - runs in the background. IDEA exports are immediately available because posting data already exists in the required format. The risk-area analysis flags two clusters: a series of intra-community supplies with changing destination countries, and a group-internal licence structure whose transfer pricing documentation was adjusted multiple times since 2023. Both clusters go to the tax department with a prepared data basis and argumentation outline. The provision is set by the head of tax using judgement - the agent delivers the data range, not the verdict.

The result: no crisis weeks. No external consultants for data preparation. The head of tax concentrates on argumentation and negotiation, not on evidence gathering.

## Permanent audit readiness turns the tax department from archivist into negotiator

Being permanently audit-ready is not additional effort - it is a redistribution of existing effort. Instead of mounting an audit project every three to five years, every decision documents itself at the moment of its creation. The tax department evolves from archivist to negotiator. The CFO reduces uncertainty in provision planning and can evaluate tax structuring risks with a reliable data foundation before the auditor finds them.

--- Three-Way Matching Agent ---
> Compares incoming invoices with purchase orders and goods receipts. Checks quantities, prices and tolerances.

Three-Way Matching is the decision bottleneck in accounts payable because every single incoming invoice must be checked against its purchase order and goods receipt before it gets paid. The Three-Way Matching Agent replaces manual checking with eleven deterministic rules and achieves an enterprise-grade straight-through rate - with no AI component, no EU AI Act (UK: UK AI regulatory framework) classification, no room for interpretation. It is the ideal starting point for CFOs who want to establish the [Decision Layer](/en/decision-layer/) in the finance organisation, because it combines high volume, low risk and directly measurable cash impact.

## Why manual matching dominates the P2P throughput time

In a typical enterprise accounts payable function, between 10 and 20 percent of all incoming invoices end up in an exception - quantity mismatch, price variance, missing goods receipt, wrong PO reference. Well-run enterprise AP teams reach straight-through rates in the high double digits once tolerance rules are tuned. The remaining exceptions tie up most of the working time, because every variance must be researched, discussed with procurement and approved manually.

Reality in the mid-market and across the broader enterprise segment sits well below that. Even with ongoing investment in AP automation, the share of invoices processed fully without human intervention often remains in the low third of total volume. The gap between investment and impact appears wherever matching logic is hidden in ERP screens rather than running as a dedicated decision agent with a clear approval matrix.

For the CFO this means two concrete problems: discount losses from late approvals, and unreliable liquidity planning because the stock of open, unmatched invoices is not controllable.

## How the Decision Layer breaks down matching

The Three-Way Matching Agent splits the review into eleven micro-decisions, all rule-based: check mandatory invoice fields, screen for duplicates, find the PO, find the goods receipt, match quantities, match prices, check variance against tolerance, route approval via matrix, assign company code and cost centre, calculate the cash discount, create the posting record. Every step is a field check or a numerical comparison. Every tolerance threshold is configurable. Every routing decision follows an amount-by-variance matrix that has been aligned with management and internal audit.

This shape is why the agent carries 0% AI content. It makes no judgement calls, interprets no text, learns nothing. It executes rules that a human would apply the same way - only in milliseconds and without fatigue. For the EU AI Act the agent is therefore irrelevant, for audit-compliant bookkeeping standards it is a standard step, and for internal audit it is a gap-free decision path.

## Concrete scenario: industrial holding with 12,000 invoices per month

An industrial holding with six plants processes around 12,000 incoming invoices per month. Starting point: 78 percent of invoices match on the first pass, 22 percent end up in the exception queue. The AP team of nine full-time staff works primarily on these exceptions and handles an average of 140 clarifications per day. Discount utilisation: 61 percent. Average throughput time from invoice receipt to payment: 9.4 days.

After introducing the Three-Way Matching Agent with tuned tolerances (2 percent price, 5 percent quantity, tiered approval matrix from EUR 2,500 / USD 2,700 upwards), the picture shifts: the straight-through rate rises to 88 percent, the manual clarification backlog drops from 2,640 to 1,440 invoices per month. The AP team no longer works on routine matching but only on genuine discrepancies with procurement and suppliers. Discount utilisation: 84 percent. Throughput time: 2.1 days. Cash impact from the first discount effect alone: around EUR 430,000 (USD 464,000) per year at an invoice volume of EUR 380 million (USD 410 million).

## Why this agent is the starting point for the Decision Layer

The Three-Way Matching Agent is the most rational entry decision for a CFO because it delivers four properties simultaneously that rarely align in other finance agents: high readiness (data already sits in the ERP), daily volume (immediately measurable), low governance burden (rule-based, not AI) and high economic impact (discounts, liquidity, capacity).

On top of that, it lays the infrastructure for all downstream workflow agents. The tolerance threshold system is later used by the Cash Application Agent for matching incoming payments against open items. The approval matrix becomes the standard building block for every workflow agent with amount-based escalation. The process documentation supplies the audit trail that later AI-supported agents (such as Invoice Coding) can align with.

Anyone establishing the Decision Layer in the finance organisation starts here - with an agent that needs no discussion with the data protection officer, no training data, and whose impact is visible in the discount report after the first week.

--- Transfer Pricing Documentation Agent ---
> Creates the transaction matrix from posting data, conducts benchmark studies, calculates the interquartile range and generates transfer pricing documentation.

Transfer pricing documentation is the process where CFOs either produce or prevent the most expensive audit finding of their tax audit. In 2024, tax audits yielded approximately EUR 10.9 billion (USD 11.8 billion) in additional assessments, and TP corrections are systematically among the heaviest individual items (source: Federal Ministry of Finance monthly report, November 2025). The [Decision Layer](/en/decision-layer/) breaks the documentation into eight clearly assigned steps - creating an audit-proof process in which every decision is justified and every figure traceable to a source.

## The Rule: Arm's Length, and the Burden of Proof Is on You

Tax law requires that intercompany prices be set as they would be between unrelated third parties. On violations, the tax authority adjusts the result upward, and for missing or deficient documentation, penalty surcharges of at least five percent and up to ten percent of the additional assessment apply, with a minimum of EUR 5,000 and a maximum of EUR 1,000,000 (USD 5,400 to 1,080,000). The OECD Transfer Pricing Guidelines set the international standard that most jurisdictions follow. (US: Section 482 IRC and the corresponding Treasury regulations impose comparable arm's-length requirements. UK: HMRC's Diverted Profits Tax adds an additional layer for large multinationals.)

A practical case: a group with a German parent and a Polish production subsidiary ships semi-finished goods to Germany. The selling price is EUR 100 per unit. The tax audit demands proof that this price meets the arm's-length standard. Without documentation, the auditor estimates - systematically to the company's disadvantage. Country-by-Country Reporting additionally applies for groups above EUR 750 million (USD 810 million) in revenue, and Pillar Two affects approximately 8,000 groups across Europe.

## The Decision Layer: Eight Steps, Three Decider Types

TP documentation splits into data-driven work, rule-based calculation and human judgement. The transaction matrix is generated automatically from IC posting data. The benchmark study runs as a structured database query against Amadeus or Orbis, and the interquartile range is an arithmetic operation with no discretion. These steps the agent handles reliably and traceably.

Three steps stay with the human. The functional and risk analysis requires qualitative assessment of the value chain - only the head of tax can judge which entity bears which function. The choice of TP method between CUP, resale price, cost plus, TNMM and profit split is an interpretation decision per OECD guidelines. The final approval is strategic because it defines the defence line in the next tax audit. The agent documents each of these human steps with decision-maker, timestamp and rationale.

In between stands one AI-supported step: the initial draft of master file, local file and CbCR as an LLM draft based on the upstream data. The draft is the starting point for revision by the tax adviser, never the final product.

## What the CFO Gets

Consistency between posting and documentation. The agent continuously matches the transfer prices stated in the TP documentation against the actual IC postings. Discrepancies outside the interquartile range escalate immediately to the tax adviser. This eliminates the classic gap where the documentation dates from last year and the postings have long since diverged.

Defensibility in the tax audit. Every entry in master file, local file and CbCR is linked to its data source, every method choice to its rationale, every benchmark to its database snapshot. The auditor receives not a finished file but a reproducible process. That is the difference between estimation at the taxpayer's expense and acceptance of the documented prices.

Predictable annual cycle. The benchmark study is fully renewed every three years per OECD recommendations and updated in the interim years. The agent monitors the cycle, flags renewal needs and provides the tax adviser with a prepared foundation rather than an empty template.

## Pillar Two Changes the Starting Position

Since 1 January 2025, the global minimum tax of 15 percent operates in parallel with classic transfer pricing audits. For TP departments this means: transfer prices must not only withstand the arm's-length test but additionally be Pillar Two-consistent. A TP correction in one country can push the effective tax rate in another country below the 15 percent threshold and trigger a top-up tax there. The simplified ETR test rises above 16 percent in 2026, and TP documentation must be consistent with GloBE data. The agent provides the structure in which both systems are fed from the same primary data - reducing the risk that the tax department and group tax function maintain two contradictory number sets.

--- Travel Expense Tax Agent ---
> Travel expense tax calculation: IRS Pub 463 per diem CONUS/OCONUS, HMRC EIM scale rates, EU/DE BMF Reisekosten per diem and EU 8th/13th Directive VAT recovery cross-border.

Travel expense processing is the most expensive rule-based process in Finance - and precisely therefore the most profitable automation lever. A manually processed claim costs approximately USD 58 (EUR 53) according to the GBTA benchmark and takes an average of 8.8 days until posted. The Travel Expense Agent reduces both figures by over 70 percent without a single tax decision leaving the house.

## Why Manual Travel Expenses Cost More Than the Trip Itself

The rule sets behind a business trip are fully documented but distributed: annual per diem tables for international destinations, unchanged domestic rates of EUR 14 for absences over 8 hours and EUR 28 for over 24 hours, meal deductions of 20/40/40 percent, non-cash benefit rates, receipt requirements under VAT law. No single employee masters this combinatorics in daily business. (US: the IRS per diem rates under Rev. Proc. and the accountable plan rules under IRC Section 62 follow a comparable structure. UK: HMRC's benchmark scale rates apply a simplified flat-rate system.)

The consequence is familiar: employees enter the wrong per diems, forget meal deductions, submit illegible receipts. Accounting corrects, queries, waits for answers. Every claim passes through three to five pairs of hands before posting. At 2,000 claims per year - a realistic volume for a company with 500 employees - that amounts to over EUR 100,000 (USD 108,000) in pure process costs on top of the actual travel budget.

## What the [Decision Layer](/en/decision-layer/) Makes of 15 Decision Steps

The Travel Expense Agent decomposes the process into 15 discrete decisions. Thirteen are fully rule-based: calculate absence duration, derive per diem rate from country and hours, apply meal deductions of 20, 40 or 40 percent, determine travel costs by mileage rate or receipt, check receipt formalities against VAT law, assign cost centre, create journal entry. One decision is agentic: the plausibility check against historical benchmarks. Exactly one decision stays with the human: assessing unclear trip purposes, meaning whether a trip was genuinely business-related.

This distribution is not coincidence but the result of clean tax-law analysis. Everything conclusively regulated in statutes, tables or federal ministry guidelines runs rule-based. The human decides only where discretion is required - and there with the full decision record as a basis.

## Scenario: Frankfurt to Madrid, Three Days, Two Provided Meals

A project manager travels Monday morning from Frankfurt to Madrid, returns late Wednesday. On Tuesday, a client meeting includes a provided lunch; on Wednesday, the hotel includes breakfast. Manually, this claim typically takes 25 to 40 minutes - including follow-up queries.

The agent completes it in under one minute. It reads departure and return from the travel request, identifies three absence days, pulls the Madrid per diem from the 2026 federal ministry rate table and calculates EUR 32 for the arrival day, EUR 48 for the full day, EUR 32 for the departure day. The meal deduction reduces Tuesday by 40 percent to EUR 28.80 and Wednesday by 20 percent to EUR 25.60. Hotel invoice, flight ticket and taxi receipts are checked for mandatory fields, input tax is deducted, the posting goes to the stored cost centre. The employee sees every line with its rationale, every statute, every rule version. They can challenge every item - every rule is documented, not asserted.

## What the CFO Concretely Gains

Four effects hit the income statement and tax resilience directly. First, processing costs per claim drop by over 70 percent - from USD 58 to under USD 15. Second, cycle time drops from 8.8 days to hours, measurably improving employee satisfaction and eliminating accounting follow-up queries. Third, the agent closes the most frequent error sources in payroll tax audits: wrong per diems, forgotten deductions, input tax deductions without proper receipts. Fourth, a versioned per diem engine emerges that the Entertainment Expense Agent and Payroll Tax Agent share - the infrastructure investment pays off threefold.

The strategic point for the CFO: travel expenses are not just a cost block but a risk process. Every wrong per diem becomes a back-payment demand at the next payroll tax audit. The Decision Layer makes this process not only faster but audit-proof documented - with exact traceability of which rate version applied at the time of travel.

--- VAT / Sales Tax Return Agent ---
> Cross-jurisdictional indirect tax: UK HMRC MTD, EU OSS + IOSS, US Sales Tax post-Wayfair nexus, ViDA 2030, SAF-T - PCAOB AS 2310 substantive procedures and Big-4 audit evidence chain.

Cross-border indirect-tax compliance at a multinational does not run on one filing standard; it runs on three regulatory worlds in parallel. A UK-headquartered e-commerce business with EU customers and US sales operates at once under HMRC Making Tax Digital for VAT (mandatory digital records and unbroken digital links under VAT Notice 700/22 since April 2019, extended to all VAT-registered businesses in April 2022), the EU VAT Directive with its One-Stop-Shop for cross-border B2C and Import-One-Stop-Shop for imports up to EUR 150, and US state-level Sales Tax under the post-Wayfair economic-nexus standard across 45 states with 12,000+ local jurisdictions and Marketplace Facilitator Laws. Layer over this the EU ViDA Directive, which mandates cross-border B2B real-time reporting from 1 July 2030, the SAF-T regimes in Portugal, Romania, Norway, Poland and others, and the PCAOB AS 2310, AICPA AU-C 240 and ISA UK 240 substantive procedures, and indirect-tax filing becomes the most fragmented and consequential process across the international finance function.

## HMRC MTD penalty points, the EUR 30 billion EU VAT gap, and post-Wayfair US nexus exposure each end in assessment notices

HMRC Making Tax Digital for VAT introduced a points-based penalty regime under Finance Act 2021 for late submission and late payment - separate from the existing default surcharge regime - and the digital-link requirement under VAT Notice 700/22 is enforced through HMRC inspection of the recordkeeping chain from source data through API submission. Manual transcription, spreadsheet copy-paste, or non-digital file transfer breaks the digital link and constitutes non-compliance independent of return accuracy. The EU annual VAT gap (the difference between expected and actual VAT revenues across the 27 Member States) is consistently estimated at EUR 30 billion per year by the Commission's VAT Gap Report - a structural compliance shortfall that the ViDA Directive (EU) 2025/516 is designed to close through real-time digital reporting from 2030. EU OSS misreporting exposes sellers to assessment by destination Member State tax authorities with penalties varying by Member State (typically 10-50% of underreported tax plus interest 5-12% per annum). US Sales Tax economic nexus exposure post-Wayfair is the most pernicious - back-tax assessment from each missed registration state stretches back to the 2018 nexus-trigger date, plus penalties typically 10-25% of tax due plus interest 8-12% per annum, and the assessment is per state with no federal coordination. A mid-cap e-commerce seller missing economic nexus registration in 8 states for 3 years can face USD 4-8 million back-tax exposure plus reputational impact of serial state DOR notices.

## The indirect-tax return pipeline runs 16 deterministic steps, not the 7-9 of a single jurisdiction

Single-jurisdiction VAT filing can be modelled in 7-9 steps; filing across the UK, EU and US cannot. The Agent splits the pipeline into 16 steps because every transaction needs the source jurisdiction checked, the counterparty validated through VIES, the HMRC VRN API or a US resale certificate, the rate determined across 12,000+ US local rates and the EU and UK categories, the OSS-or-local-registration routing decided against the EUR 10,000 threshold, the IOSS routing applied for sub-EUR-150 imports, the Marketplace Facilitator responsibility and the US economic-nexus thresholds monitored per state, the MTD digital-link integrity preserved, the return lines aggregated per format, the GL reconciliation run, ViDA readiness maintained, SAF-T generated where required, plausibility deviation detected, variance flags escalated, the return submitted, and the evidence archived per jurisdiction.

A concrete scenario: a UK-headquartered SaaS multinational with USD 280M ARR, EU customers in 18 Member States, US customers across 35 states. On a typical month, the Agent processes 240,000 transactions, determines jurisdictional treatment per transaction, validates 8,400 EU VAT IDs through VIES and 12,200 US Resale Certificates, applies Avalara rates across the full stream with 0 errors, routes 124,800 EU B2C supplies through OSS Union scheme via Irish Revenue portal (UK no longer eligible as home Member State post-Brexit), monitors economic nexus across the 45 states and DC (registrations stable at 14 states), applies Marketplace Facilitator exclusion to 18,400 Amazon-channeled US sales, generates HMRC MTD digital records with unbroken hash-chain integrity, aggregates UK VAT Return 9-box totals with 0 reconciliation breaks against GL, files individual state Sales Tax returns to 14 US state DORs, generates SAF-T-PT and Polish JPK_V7M for EU subsidiaries, flags 7 variances above 18% rolling-baseline threshold escalating 4 to the tax team, and packages the evidence chain for SOX 404 inspection plus PCAOB AS 2310, AICPA AU-C 240 and ISA UK 240 substantive testing.

In the [Decision Layer](/en/decision-layer/), 14 of the 16 steps are rule-based (R), 1 is LLM-suggestion (A) for plausibility deviation detection with confidence scoring and rolling-baseline comparison, and 1 is human (H) for variance flag disposition. There is no generative AI in any rate-determination, jurisdiction-routing, nexus-classification, OSS/IOSS-eligibility, MTD-digital-link, or filing decision - the LLM stage operates only on plausibility variance detection where pattern recognition adds genuine value over rigid rules, and even then the LLM never auto-files a return without tax-team review acceptance.

## ViDA 2030 changes the EU indirect-tax timing model from monthly batch to real-time per transaction

ViDA Directive (EU) 2025/516 is the most consequential VAT reform since the original 1967 framework, designed to close the structural EUR 30 billion annual EU VAT gap through real-time tax authority transmission. The Digital Reporting Requirements (DRR) phase mandates cross-border B2B e-invoicing with EN 16931 structured format from 1 July 2030, replacing the EC Sales List with per-transaction reporting to destination Member State authorities. National systems (Italy SDI 2019, Spain SII 2017, Poland KSeF mandatory July 2026, France 2026, Germany 2026-2028) continue with ViDA-alignment migration. The Agent's invoice generation already supports EN 16931 schema and the Decision Log captures transaction-level tax determination with timestamp and audit trail, ready for real-time API transmission as ViDA scope phases in 2027-2032. The Single VAT Registration pillar (Pillar 2 from 2027) expands OSS to cover all B2C cross-border supplies including services and certain B2B. Pillar 3 (Platform Economy from 2027) makes marketplaces deemed suppliers for short-term accommodation and passenger transport. Multinationals preparing for ViDA in 2026 are already investing in transaction-level instrumentation - the Agent's deterministic Decision Log is the pre-built ViDA-readiness foundation, eliminating the typical USD 2-4 million compliance-platform overhaul that late-movers face in 2029.

## US Sales Tax economic nexus monitoring is the post-Wayfair compliance trap with stretching back-tax exposure

The 2018 South Dakota v. Wayfair Supreme Court decision (No. 17-494) overturned the Quill physical-presence test that had stood since 1992, ruling that economic activity alone (sales and transaction count) creates Sales Tax obligations without physical presence. Each of the 45 states and DC implemented its own economic nexus statute with different thresholds (typically USD 100,000 OR 200 transactions, with California, New York, Texas at USD 500,000), different effective dates, and different return forms. The 24 member states and 4 associates of the Streamlined Sales and Use Tax Agreement (SSUTA) offer single-registration via SSTRS plus a Certified Service Provider (CSP) framework that simplifies multi-state compliance significantly - the 21 non-SSUTA states and DC require direct registration and direct DOR portal submission. The Agent maintains rolling 12-month counters per state with daily refresh and alerts at the 80% and 100% thresholds, plus integration with SSTRS for the 24 SSUTA states. Marketplace Facilitator Laws (all 45 states and DC, effective 2018-2021) shift collection responsibility for marketplace-channeled sales (Amazon, eBay, Etsy, Walmart, Shopify) to the platform - the Agent maps platform-channeled sales per state per platform to avoid double-collection while still counting toward nexus thresholds where state law specifies inclusion. Voluntary Disclosure Agreement (VDA) programmes in most states allow capped lookback (typically 3-4 years) plus penalty waiver in exchange for proactive disclosure - the Agent surfaces VDA strategic options to the tax team when retroactive nexus is detected from rolling-counter analysis.

## Integration ecosystem: SAP S/4HANA, Oracle Tax, Workday and MS Dynamics, with Avalara, Vertex, Sovos and ONESOURCE

The Agent integrates natively with the major international ERPs. [SAP S/4HANA](https://www.sap.com/products/erp/s4hana.html) Tax Compliance and Advanced Compliance Reporting (ACR) handles country-specific VAT determination, OSS and IOSS routing, the MTD digital link and SAF-T export. [Oracle Fusion Cloud Financials](https://www.oracle.com/erp/financials/) Tax and Tax Reporting Cloud covers multi-jurisdiction reporting and US Sales Tax economic nexus monitoring. [Workday Financial Management](https://www.workday.com/en-us/products/financial-management/) provides an integrated tax engine with MTD-compatible API submission to HMRC. Microsoft Dynamics 365 Finance with Tax Calculation Service offers an electronic reporting framework spanning MTD, OSS, IOSS, SAF-T and EU country-specific filings. For specialist global tax determination, [Avalara](https://www.avalara.com/) AvaTax, Returns and MTD Cert reaches across 12,000+ US tax jurisdictions and 100+ countries as HMRC MTD-recognised software with OSS and IOSS automation; [Vertex](https://www.vertexinc.com/) O Series and Indirect Tax Returns integrate deeply with SAP, Oracle, Workday and MS Dynamics; [Sovos](https://sovos.com/) Indirect Tax Suite and VAT Reporting lead in mandatory e-invoicing connections (IT SDI, ES SII, PT QR-codes, PL KSeF, BR NF-e, MX CFDI); and [Thomson Reuters ONESOURCE](https://tax.thomsonreuters.com/en/onesource) Indirect Tax and Determination add OSS and IOSS portal integration with US Sales Tax marketplace facilitator handling. For SaaS-native tax automation, Stripe Tax, Quaderno and Taxually cover OSS and IOSS-ready EU B2C plus US economic nexus monitoring, and TaxJar (Stripe-owned) handles SMB-focused US Sales Tax with marketplace facilitator detection and AutoFile. Audit-evidence integration spans Deloitte ASM, PwC Halo, EY Helix and KPMG Clara through standardised return export formats with PCAOB AS 1215-compliant metadata. Submission flows through the HMRC MTD VAT API with OAuth 2.0 software identifier, the EU OSS portal via home Member State authentication, the EU IOSS via the designated Member State portal, the US state DOR portals for the 21 non-SSUTA states and DC, and the SSTRS aggregator for the 24 SSUTA states; SAF-T is submitted to Portugal's AT, Romania's ANAF, Norway's Skatteetaten and Poland's JPK, with France planned for 2026 - all generated as deterministic templates with audit-trail metadata for HMRC, EU and US compliance, and for PCAOB, AICPA and ISA UK substantive testing.

--- Vendor Onboarding Agent ---
> Extracts master data from vendor self-disclosure, validates VAT ID, checks sanctions lists, assesses risks and creates the vendor in the ERP.

Every new vendor is a risk entry point into the accounts payable master data. Anyone who creates one unchecked amplifies the error with every subsequent posting - from input VAT to the payment run. The Vendor Onboarding Agent turns screening into a mandatory step before the first invoice lands in the system.

## The problem is not the onboarding, it is the blind flight afterwards

Most finance organisations check new vendors at first creation. After that comes the blind flight. While a large share of companies check master data at onboarding, the share of systematic checks before the payment run drops drastically. Vendor impersonation attacks operate exactly in this gap: a changed bank detail, an expired sanctions list entry, an invalid VAT ID - and money flows to the wrong account or the input VAT deduction gets clawed back at the next audit.

On top of that sits the structural data flaw. Many procurement leaders have no clear overview of their organisation's entire vendor network, and purchase-to-pay teams regularly report missing end-to-end alignment and missing ownership of master data. Anyone entering the process under these conditions finds duplicates, outdated bank details and unclear risk profiles only after the damage is already booked.

## A scenario CFOs recognise

A mid-sized chemical manufacturer is approached by a new raw-material supplier from Eastern Europe. Initial order: EUR 240,000 (USD 260,000). Procurement sends the self-disclosure to accounting, the vendor is created. Two weeks later the first invoice arrives and is paid. Three months later the internal auditor establishes: the VAT ID was invalid from the start. The input VAT deduction must be reversed, the tax audit additionally questions the due diligence performed. At the same time the vendor appears on an updated sanctions list - and the compliance officer has no process in place to check existing master records against list updates.

With the Vendor Onboarding Agent this case is stopped before the first payment. The EU VIES validation catches the invalid VAT ID in seconds. The sanctions list check against EU, OFAC and UN lists runs automatically and is applied to the master data on every list update. The bank details are validated algorithmically, the duplicate check protects against accidental double creation, and the risk scoring combines industry, country and credit data into a metric that a human must approve when it exceeds the threshold.

## How the [Decision Layer](/en/decision-layer/) breaks down the process

The agent covers nine decision steps, each clearly mapped to rule, AI or human. Master data extraction from the self-disclosure and reading payment terms from contracts use LLM-based document processing. VAT ID validation, sanctions screening, IBAN check, duplicate matching and ERP creation run rule-based via API integrations. Risk assessment is a hybrid: rule-based factors combined with AI scoring. Only one decision remains with the human - approval when the risk score is elevated. Where judgement is genuinely needed, the compliance officer decides, documented in the audit trail.

## Every vendor is validated before the first invoice posts, and the infrastructure feeds four further agents

The business impact is twofold. First, the structural weakness disappears: every vendor is validated before the first invoice is booked. Second, the foundation emerges on which additional finance agents can build. VAT ID validation is reused by the Invoice Capture Agent and Withholding Tax Agent. The sanctions list check feeds the Payment Run Agent. The risk scoring pattern becomes the template for the Fraud Detection Agent. Once built, the infrastructure pays off across multiple processes simultaneously.

For the CFO this means: solid due diligence documentation for the tax audit, reduced vendor fraud exposure, and an accounts payable master file the payment run can trust. (US: from 22 June 2026, expanded Nacha rules on ACH fraud monitoring also take effect - anyone who builds a clean validation infrastructure today meets these requirements without having to retrofit.)

--- Withholding Tax Agent ---
> Non-payroll withholding: capital gains, construction (UK CIS), foreign-payee (US 1042-S, DE Sec 50a EStG), treaty relief - W-8BEN/W-9 TIN validation, audit-grade chain.

International withholding tax does not run on one regulatory standard; it runs on several overlapping regimes at once across the US, UK, EU and the OECD treaty network. Consider a US-headquartered multinational paying royalties to a UK affiliate, interest to a Dutch financing subsidiary, dividends to an Irish holding, consulting fees to a Swiss partnership and construction services to UK subcontractors. It is operating concurrently under US Chapter 3 NRA withholding at the 30% statutory rate, the FATCA Chapter 4 stack, the OECD-MLI-modified treaty network with its PPT and LOB anti-abuse standards, the EU Interest and Royalties and Parent-Subsidiary Directives with their ownership and holding-period tests, and the OECD Pillar Two GloBE 15% global minimum. Layer over this UK CIS with its 0%, 20% and 30% subcontractor rates and monthly CIS300 returns, IRS 1099-NEC reporting with 24% backup withholding under IRC Section 3406, ATAD hybrid-mismatch countermeasures, and the PCAOB AS 2310, AS 2501, AICPA AU-C 240 and ISA UK 240 substantive procedures, and international withholding becomes the most fragmented and consequential process across the multinational finance function.

## A 1099 mismatch, an unverified CIS subcontractor, an EU IRD assessment or a Pillar Two charge can cascade into a Big-4 uncertain-tax-position disclosure

IRS backup withholding under IRC Section 3406 imposes 24% on payments to US payees with missing or invalid TINs - a TIN mismatch generates a B-Notice (CP2100 or CP2100A) from the IRS to the payer, and failure to cure within 30 days of the second B-Notice in three calendar years triggers backup withholding from the next payment forward. Failure to file 1099 information returns or filing with incorrect TIN exposes the payer to penalties under IRC Section 6721 starting at USD 60 per return up to USD 660 for intentional disregard, with annual aggregate caps reaching USD 4 million for large filers. The UK Construction Industry Scheme imposes 30% deduction on payments to unverified subcontractors and 20% on registered subcontractors without Gross Payment Status - missing the verification step before the first payment exposes the contractor to recovery from HMRC of the unwithheld amount plus penalties under FA 2004 Schedule 11. EU Interest and Royalties Directive non-compliance assessments by Member State competent authorities for failures of the 25% ownership, 24-month holding, or beneficial-owner tests typically range EUR 800k-2M annually for material multinational financing structures. OECD Pillar Two GloBE 15% top-up tax exposure post-2024 for MNE groups at or above EUR 750 million consolidated revenue creates a per-jurisdiction effective minimum, and the cascade through IIR (UPE level) plus UTPR (backstop) plus QDMTT (source-jurisdiction first) means a single low-taxed jurisdiction can trigger top-up obligations across multiple jurisdictions simultaneously. For SEC-registered multinationals the cumulative exposure typically lands as a FIN 48 uncertain tax position requiring ASC 740-10 disclosure with Big-4 auditor concurrence under PCAOB AS 2310 and AS 2501.

## The withholding pipeline runs 17 deterministic steps, not the 7-9 of a single jurisdiction

Single-jurisdiction withholding can be modelled in 7-9 steps; cross-jurisdictional withholding cannot. The Agent splits the pipeline into 17 steps because every payment needs the source jurisdiction checked under IRC Section 861 and the UK and EU rules, the payee status read from the W-9 or W-8 series, the TIN validated through IRS TIN Matching or W-8 completeness, UK CIS verification applied where relevant, the Chapter 3 NRA withholding determined with the FATCA Chapter 4 stack, the DTA treaty rate applied with LOB and PPT checks under the OECD MLI, the EU IRD zero-rate and PSD dividend exemption qualified, ATAD hybrid mismatches detected, the Pillar Two GloBE top-up tax calculated, the withholding amount computed with any gross-up, the IRS 1099, 1042-S, 8966 and 8975 forms generated, plausibility detected, complex cases escalated, the filing submitted, and the evidence archived per jurisdiction.

A concrete scenario: a US-headquartered SaaS multinational with USD 1.2B ARR, EU subsidiaries in 12 Member States, UK construction-sector contractor activity, foreign vendor base across 38 countries. On a typical month, the Agent processes 18,400 cross-border payments, validates 14,200 W-9 TINs with 47 mismatches escalating to B-Notice cure, verifies 280 UK CIS subcontractors with 12 routing to 30%, applies Chapter 3 and Chapter 4 stacking to 4,200 foreign-payee payments with 38 routing to 30% FATCA non-compliant, applies DTA treaty rates with PPT analysis to 2,800 treaty-claim payments, qualifies 480 intra-EU royalty payments under IRD zero-rate plus 120 dividends under PSD, detects 4 ATAD Article 9 hybrid mismatches, calculates Pillar Two GloBE ETR across 18 in-scope jurisdictions with 2 triggering top-up tax under IIR (EUR 740k accrual), generates 14,200 IRS Form 1099 plus 4,200 Form 1042-S and Form 8966 plus monthly UK CIS300 plus EU treaty-relief filings to 12 competent authorities, and packages the evidence chain for SOX 404 inspection plus PCAOB AS 2310 and AS 2501, AICPA AU-C 240 and ISA UK 240 substantive testing.

In the [Decision Layer](/en/decision-layer/), 14 of the 17 steps are rule-based (R), 2 are LLM-suggestion (A) for payment-type classification and treaty-shopping plausibility detection, and 1 is human (H) for complex-case escalation. There is no generative AI in any rate-determination, treaty-application, FATCA-classification, IRD-eligibility, Pillar Two GloBE, or filing decision - the LLM never auto-files an information return without tax-team review acceptance.

## OECD Pillar Two GloBE 15% global minimum changes the timing model from year-end calculation to per-quarter accrual

OECD Pillar Two GloBE Rules transform international tax compliance from year-end calculation to per-quarter accrual under ASC 740-10 / IAS 12 with continuous monitoring of per-jurisdiction Effective Tax Rate (ETR), Substance-based Income Exclusion (SBIE), and top-up tax exposure. The EU Pillar Two Directive 2022/2523 entered into force for fiscal years from 31 December 2023, with all 27 Member States transposing into national law - Germany via Mindeststeuergesetz, France via Loi de finances 2024, Netherlands via Wet minimumbelasting 2024. The UK Multinational Top-up Tax and Domestic Top-up Tax under Finance (No. 2) Act 2023 apply IIR at the UK UPE level plus QDMTT for UK-resident Constituent Entities. The US has not formally adopted Pillar Two but the analogous Corporate Alternative Minimum Tax under Inflation Reduction Act 2022 imposes 15% AMT on adjusted financial statement income for corporations above USD 1 billion. The Agent calculates per-jurisdiction ETR by aggregating Covered Taxes divided by GloBE Income, applies the Substance-based Income Exclusion (5% payroll plus 5% tangible assets, transitioning from 10%/8%), calculates top-up rate and top-up amount, and allocates between the IIR, UTPR and QDMTT per OECD priority order. For the typical SEC-registered S&P 500 multinational, Pillar Two implementation requires USD 4-8 million in tax-engine investment plus 18-24 months of jurisdiction-by-jurisdiction data preparation - the Agent's deterministic GloBE engine eliminates the typical late-mover compliance scramble.

## US Chapter 3 and Chapter 4 FATCA stacking is the most operationally complex withholding regime globally

The US framework combines two parallel withholding regimes that stack on the same payment. Chapter 3 NRA withholding under IRC Sections 1441-1446 imposes 30% on US-source FDAP income paid to foreign persons (royalties, dividends, interest with portfolio exception, rents, compensation for US-rendered services), reducible by treaty where the payee provides Form W-8BEN/BEN-E with treaty claim plus certificate of residence plus LOB/PPT compliance per OECD MLI. Chapter 4 FATCA withholding under IRC Sections 1471-1474 imposes a separate 30% rate on withholdable payments to non-compliant FFIs and NFFEs with substantial undocumented US owners - the FATCA classification matrix on W-8BEN-E Part I distinguishes Participating FFI, Reporting Model 1/2 FFI, Deemed-Compliant FFI, Active NFFE, Passive NFFE with documented owners (all 0% Chapter 4), Passive NFFE with substantial US owners or Non-Participating FFI (both 30%). Coordination rules per Reg 1.1474-6 prevent double 30% withholding where Chapter 4 has already withheld. The Agent integrates with the IRS FFI List for GIIN verification plus IRS TIN Matching plus the Sovos / ONESOURCE / Avalara / CCH Axcess engine for e-filing the 1099, 1042-S and 8966 forms. Forms 1042, 1042-S and 8966 are due 15 March / 31 March following calendar year via FIRE or IRIS, with B-Notice CP2100 plus C-Notice processing and W-8 expiry tracking on a 3-year validity window.

## Integration ecosystem: SAP S/4HANA, Oracle Tax, Workday and MS Dynamics, with ONESOURCE, Sovos, Avalara and CCH Axcess

The Agent integrates natively with the major international ERPs. [SAP S/4HANA](https://www.sap.com/products/erp/s4hana.html) Tax Compliance, Global Trade Services and PaPM handle country-specific withholding determination, treaty-rate lookup, FATCA and CRS reporting, and the Pillar Two GloBE calculation. [Oracle Fusion Cloud Financials](https://www.oracle.com/erp/financials/) Tax, Tax Reporting Cloud and EPM cover multi-jurisdiction reporting, 1099 and 1042-S generation, CbCR and Pillar Two. [Workday Financial Management](https://www.workday.com/en-us/products/financial-management/) provides an integrated cross-border tax engine with treaty-rate application and US 1099 generation. Microsoft Dynamics 365 Finance with Tax Calculation Service and Electronic Reporting covers US 1099 and 1042-S, UK CIS and EU IRD checks. For specialist withholding determination, [Thomson Reuters ONESOURCE](https://tax.thomsonreuters.com/en/onesource) Withholding Tax and TIR provide market-leading enterprise determination and e-filing with FATCA, CRS and Pillar Two; [Sovos](https://sovos.com/) Withholding Tax, 1099 Reporting and GloBE add cross-jurisdictional compliance, the IRS Combined Federal/State Filing programme, FATCA and Pillar Two; CCH Axcess TIR and CCH Wolters Kluwer Withholding handle 1099-series e-filing, B-Notice processing and IRS TIN matching; and [Avalara](https://www.avalara.com/) 1099 and Withholding cover SaaS-native US 1099 e-filing, marketplace facilitator handling and vendor TIN management. Audit-evidence integration spans Deloitte ASM, PwC Halo, EY Helix and KPMG Clara through standardised export formats with PCAOB AS 1215-compliant metadata. Submission flows through IRS FIRE TCC or IRIS for the 1099, 1042-S, 8966 and 8975 forms per Pub 1220, the HMRC RTI Government Gateway for PAYE FPS, the HMRC CIS API for the monthly CIS300 and Payment and Deduction Statement, and the EU Member State competent-authority portals for treaty-relief and IRD/PSD certifications - all generated as deterministic templates with audit-trail metadata for IRS, HMRC and EU compliance, and for PCAOB, AICPA and ISA UK substantive testing.

--- Finance Agent - Document Processing & Bookkeeping ---
> Finance Agent with Decision Layer: document processing, depreciation logic, expense receipts. Versioned rule sets, audit trail, Cert-Ready

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/en/why-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act (UK: UK AI regulatory framework) ready</p>
<p class="text-xs text-gosign-text-light">Every decision traceable</p>
</div>
</a>
<a href="/en/why-gosign/#infrastructure" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Your infrastructure</p>
<p class="text-xs text-gosign-text-light">No SaaS. No vendor lock-in.</p>
</div>
</a>
<a href="/en/why-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">No US cloud risk</p>
</div>
</a>
</div>
</div>
</div>

<div class="not-prose my-8 bg-gosign-dark rounded-card p-6 sm:p-8">
<div class="flex flex-col sm:flex-row sm:items-center gap-4">
<div class="flex-1">
<p class="text-h3 font-bold text-white mb-2">Free eBook: AI in Finance</p>
<p class="text-body text-white/80">Compliance, external auditors, and Decision Layer - the governance handbook for finance leaders.</p>
</div>
<a href="/en/ebook/ai-finance-governance-handbook/" class="inline-flex items-center gap-2 px-6 py-3 bg-gosign-accent-btn text-white font-semibold rounded-lg hover:bg-gosign-accent-btn-hover transition-colors whitespace-nowrap">Download now</a>
</div>
</div>

<!-- Problem -->
<section class="py-section bg-gosign-white"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow"><h2 class="text-h1 font-bold text-gosign-dark">The Problem: Posting Logic in Heads, Not in Systems</h2><p class="text-body-lg text-gosign-text-light mt-4">Finance decisions in enterprises depend on individual expertise. Depreciation classifications, expense receipts, correction postings, tax assessments - the domain ruleset is complex and application varies by person, location, and interpretation.</p><p class="text-body-lg text-gosign-text-light mt-4">The consequences hit the balance sheet directly: Correction postings that could have been avoided. Depreciation classifications that only the auditor challenges. Expense receipts treated differently across offices. Tax assessments that aren't reproducible.</p><p class="text-body-lg text-gosign-text-light mt-4">For auditors, internal revision, and shared service centers, this is a systematic risk: Every undocumented decision is a potential audit finding. Every rule interpretation that varies is a consistency risk.</p></div></div></section>

<!-- Definition -->
<section class="py-section bg-gosign-light"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow"><h2 class="text-h1 font-bold text-gosign-dark">What Is a Finance Agent?</h2><p class="text-body-lg text-gosign-text-light mt-4">A Finance Agent is a specialised AI agent for document processing and bookkeeping. It reads documents with contextual language understanding, assesses them against versioned rule sets (tax law, accounting standards, internal policies), and produces documented posting proposals. The <a href="/en/decision-layer/" class="text-gosign-accent-text hover:text-gosign-accent-hover">Decision Layer</a> routes every micro-decision: autonomous at high confidence and clear rules, to a specialist at edge cases.</p><p class="text-body-lg text-gosign-text-light mt-4">DATEV and SAP remain your leading systems. The Finance Agent sits in front - it delivers decision-ready outputs including a complete chain of reasoning. Every decision produces a full decision record: input, applied rule, rule version, confidence, decision path, outcome. This is not retroactive documentation - it is the technical proof of how each decision was made.</p></div></div></section>

<!-- Use Cases -->
<section class="py-section bg-gosign-light"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><h2 class="text-h1 font-bold text-gosign-dark mb-8">Specific Use Cases</h2><div class="grid grid-cols-1 md:grid-cols-2 gap-6"><div class="border border-gosign-border rounded-card p-6 bg-gosign-white"><h3 class="text-h3 font-bold text-gosign-dark">Document Processing & Classification</h3><p class="text-body text-gosign-text-light mt-2">The Document Agent reads, understands, and assesses documents with real language understanding - no rigid rule chains, no template matching. Invoices, credit notes, cancellations, expense receipts, travel expense reports. The Decision Layer checks completeness, plausibility, and tax classification. At high confidence: automatic posting proposal. At edge cases: escalation to the specialist.</p></div><div class="border border-gosign-border rounded-card p-6 bg-gosign-white"><h3 class="text-h3 font-bold text-gosign-dark">Depreciation Logic</h3><p class="text-body text-gosign-text-light mt-2">Depreciation logic varies by asset type, tax classification, and region. The Decision Layer makes the logic explicit: asset type classification, tax classification check, application of depreciation table per current version, documentation of reasoning, handoff as structured posting proposal. Reduced misclassifications and auditable depreciation logic.</p></div><div class="border border-gosign-border rounded-card p-6 bg-gosign-white"><h3 class="text-h3 font-bold text-gosign-dark">Expense Receipts</h3><p class="text-body text-gosign-text-light mt-2">Varying interpretation of deductibility is one of the most common audit points. The Decision Layer standardizes: receipt completeness check, attendee list verification, purpose and business relevance check, application of deductibility rules per current version. Reproducible, rule-compliant treatment instead of situational interpretation.</p></div><div class="border border-gosign-border rounded-card p-6 bg-gosign-white"><h3 class="text-h3 font-bold text-gosign-dark">Correction Postings & Quality Assurance</h3><p class="text-body text-gosign-text-light mt-2">Eliminate correction postings before they happen. The Workflow Agent orchestrates the quality assurance process: automatic plausibility check before posting, comparison against reference values and historical patterns, escalation for anomalies, documentation of every check in the audit trail.</p></div></div></div></section>

<!-- Target Groups -->
<section class="py-section bg-gosign-white"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><h2 class="text-h1 font-bold text-gosign-dark mb-8">Target Groups</h2><div class="grid grid-cols-1 md:grid-cols-3 gap-6"><div class="border border-gosign-border rounded-card p-6 bg-gosign-white"><h3 class="text-h3 font-bold text-gosign-dark">Audit Firms & Tax Advisory Practices</h3><p class="text-body text-gosign-text-light mt-2">Hundreds of clients, thousands of receipts per month. The Finance Agent brings consistency to processing across all clients. Junior staff currently spend 60% of their time on data entry instead of advisory work. The Finance Agent handles routine capture - your specialists focus on what they were trained for.</p></div><div class="border border-gosign-border rounded-card p-6 bg-gosign-white"><h3 class="text-h3 font-bold text-gosign-dark">Shared Service Centres</h3><p class="text-body text-gosign-text-light mt-2">Multiple entities, different countries, different rule sets. The Finance Agent applies client-specific rules consistently.</p></div><div class="border border-gosign-border rounded-card p-6 bg-gosign-white"><h3 class="text-h3 font-bold text-gosign-dark">Enterprises with In-House Accounting</h3><p class="text-body text-gosign-text-light mt-2">Month-end closings, quarterly reports, tax audits. Fewer correction postings, consistent account assignments, complete documentation.</p></div></div></div></section>

<!-- Four Steps -->
<section class="py-section bg-gosign-white"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow"><h2 class="text-h1 font-bold text-gosign-dark">Four Steps: From Document to Audit-Ready Posting</h2><p class="text-body-lg text-gosign-text-light mt-4"><strong>1. Read and Understand</strong> - The agent reads documents with contextual language understanding. Vendor, amount, service description, tax-relevant features. No rigid template matching - real document comprehension.</p><p class="text-body-lg text-gosign-text-light mt-4"><strong>2. Assess</strong> - Account, cost centre, tax classification, depreciation start, expense receipt criteria. Every assessment is based on a versioned rule set - not on the experience of individual accountants.</p><p class="text-body-lg text-gosign-text-light mt-4"><strong>3. Decide</strong> - The Decision Layer routes: autonomous at high confidence and clear rules, to a specialist at edge cases or low confidence. You define the thresholds - not the AI.</p><p class="text-body-lg text-gosign-text-light mt-4"><strong>4. Document</strong> - Every micro-decision produces a decision record: input, applied rule, rule version, confidence, decision path, outcome, timestamp. This is not retroactive documentation - it is the technical proof of how each decision was made.</p></div></div></section>

<!-- Decision Flow -->
<section class="py-section bg-gosign-light"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><h2 class="text-h1 font-bold text-gosign-dark mb-6">Decision Flow</h2><div class="mt-8 bg-gosign-dark rounded-card p-6 sm:p-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-4">Incoming document → Agent extracts → Decision Layer decomposes into steps</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-4">
<div class="bg-white/5 rounded-card p-4">
<p class="text-xs font-bold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Rule Engine</p>
<p class="text-small text-white/90 font-semibold">Clear-cut cases</p>
<p class="text-small text-white/60 mt-2">Tax rate per regulation. Deterministic calculation.</p>
</div>
<div class="bg-white/5 rounded-card p-4">
<p class="text-xs font-bold uppercase tracking-wider text-gosign-accent-on-dark mb-2">AI Agent</p>
<p class="text-small text-white/90 font-semibold">Confidence decision</p>
<p class="text-small text-white/60 mt-2">Account suggestion with score. Autonomous above threshold.</p>
</div>
<div class="bg-white/5 rounded-card p-4">
<p class="text-xs font-bold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Human</p>
<p class="text-small text-white/90 font-semibold">Exception</p>
<p class="text-small text-white/60 mt-2">Specialist reviews and decides with context.</p>
</div>
</div>
<p class="text-xs text-white/60 mt-4 text-center">Audit trail per step: Rule · Version · Decision maker</p>
</div></div></section>

<!-- Decision Layer Detail -->
<section class="py-section bg-gosign-white"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow"><h2 class="text-h1 font-bold text-gosign-dark"><a href="/en/decision-layer/" class="hover:text-gosign-accent transition-colors">The Decision Layer</a>: How Finance Decisions Become Audit-Ready</h2><p class="text-body-lg text-gosign-text-light mt-4">The <a href="/en/decision-layer/" class="text-gosign-accent-text hover:underline">Decision Layer</a> decomposes the booking process into individual decision steps. For each step, it defines: Does the agent decide, a ruleset, or a human?</p><p class="text-body-lg text-gosign-text-light mt-4">The agent reads, understands, and assesses documents with real language understanding. The Decision Layer routes each assessment:</p><div class="mt-6 bg-gosign-light border border-gosign-border rounded-card p-6"><p class="text-body font-mono text-gosign-dark">Document &rarr; Extraction &rarr; Classification &rarr; Domain Assessment &rarr; Confidence Score &rarr; Posting Proposal or Human Escalation</p></div><p class="text-body-lg text-gosign-text-light mt-4">Every decision produces a complete, immutable record: input, model, assessment, confidence score, applied rule with version, decision path, outcome. This is not retroactive documentation - it is the technical proof of how each decision was made.</p><p class="text-body text-gosign-text-light mt-4">What cost models for enterprise AI look like and what self-hosting vs. cloud really costs is detailed in the <a href="/en/magazine/ai-costs-tco-comparison/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">TCO comparison in the Blueprint 2026</a>.</p></div></div></section>

<!-- Cert-Ready -->
<section class="py-section bg-gosign-light"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow"><h2 class="text-h1 font-bold text-gosign-dark">Cert-Ready by Design</h2><p class="text-body text-gosign-text-light mt-2 italic">Not "we have ISO." Not "we don't need ISO." Rather: Every agent is technically built to be certifiable and auditable at any time.</p><p class="text-body-lg text-gosign-text-light mt-4">Controls are first-class data objects in the system - not documents in a folder. Every control has: a technical implementation (RLS policy, trigger, API check), an automatic evidence generator, an evidence history with timestamp, status, and version, and an auditor view with drill-down to the concrete implementation.</p><p class="text-body-lg text-gosign-text-light mt-4">What this means concretely: Controls live in the database, not in Confluence. Evidence is generated automatically - no human collects screenshots. Drill-down from traffic-light status to the concrete RLS policy name and test SQL. The system proves itself.</p><p class="text-body-lg text-gosign-text-light mt-4">Auditors see live status in the Auditor Portal. No Excel package, no PDF report, no "ask the developer."</p></div></div></section>

<!-- EU AI Act -->
<section class="py-section-sm bg-gosign-dark text-white"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow"><h2 class="text-h1 font-bold">EU AI Act compliant by design</h2><p class="text-body-lg text-gosign-text-on-dark/80 mt-4">Finance Agents that make automated decisions about postings, amounts, and tax matters are subject to the transparency and oversight requirements of the EU AI Act. Our architecture addresses these requirements as a design principle:</p><div class="mt-6 space-y-4"><p class="text-body-lg text-gosign-text-on-dark/80"><strong class="text-white">Transparency (Art. 13):</strong> Decision Layer documents every decision path. Audit trail shows input &rarr; model &rarr; assessment &rarr; outcome.</p><p class="text-body-lg text-gosign-text-on-dark/80"><strong class="text-white">Human Oversight (Art. 14):</strong> Human-in-the-Loop architecturally enforced for risk decisions. Decision Layer routes automatically.</p><p class="text-body-lg text-gosign-text-on-dark/80"><strong class="text-white">Recording Obligations (Art. 12):</strong> Complete audit trail with timestamps, input hashes, model versions, decision paths. Immutable, exportable.</p><p class="text-body-lg text-gosign-text-on-dark/80"><strong class="text-white">Risk Management (Art. 9):</strong> Governance Layer with bias monitoring, confidence tracking, anomaly detection. Cert-Ready Controls with automatic evidence generation.</p></div><p class="text-body text-gosign-text-on-dark/60 mt-6 italic">Our architecture is designed from the ground up for EU AI Act requirements. This is an architecture statement, not a compliance certificate.</p></div></div></section>

<!-- Integration -->
<section class="py-section bg-gosign-white"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow"><h2 class="text-h1 font-bold text-gosign-dark">Integration into Your Existing System Landscape</h2><p class="text-body-lg text-gosign-text-light mt-4">AI Agents don't replace systems. <a href="https://www.sap.com/products/erp/s4hana.html" target="_blank" rel="noopener noreferrer">SAP FI/CO</a> stays your ERP, <a href="https://www.datev.de" target="_blank" rel="noopener noreferrer">DATEV</a> stays your tax system. Agent logic is decoupled from the target system - posting logic is separated from export.</p><div class="mt-6 flex flex-wrap gap-3"><span class="bg-gosign-light border border-gosign-border rounded-card px-4 py-2 text-body font-medium text-gosign-dark">SAP FI/CO</span><span class="bg-gosign-light border border-gosign-border rounded-card px-4 py-2 text-body font-medium text-gosign-dark">DATEV</span><span class="bg-gosign-light border border-gosign-border rounded-card px-4 py-2 text-body font-medium text-gosign-dark">SAP S/4HANA</span><span class="bg-gosign-light border border-gosign-border rounded-card px-4 py-2 text-body font-medium text-gosign-dark">SharePoint</span><span class="bg-gosign-light border border-gosign-border rounded-card px-4 py-2 text-body font-medium text-gosign-dark">Microsoft Teams</span><span class="bg-gosign-light border border-gosign-border rounded-card px-4 py-2 text-body font-medium text-gosign-dark">REST/SOAP</span></div></div></div></section>

<!-- Professional Secrecy - §203 StGB (German criminal-code provision on professional secrecy) -->
<section class="py-section bg-gosign-dark text-white"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow">
<h2 class="text-h1 font-bold">Professional Secrecy - §203 StGB</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4">For audit firms and tax advisory practices, §203 StGB is non-negotiable. Client data must never leave the control sphere of the professional secret holder. This is not a compliance checkbox - it is criminal liability.</p>
<h3 class="text-h3 font-bold mt-8">Architecture, not promises</h3>
<p class="text-body text-gosign-text-on-dark/80 mt-3">The Finance Agent processes client data exclusively in your infrastructure. Three architectural guarantees:</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-4 mt-6">
<div class="p-4 bg-white/5 rounded-card"><p class="text-body font-semibold text-white">Client separation</p><p class="text-small text-white/70 mt-1">Separate data spaces per client. No cross-client inference.</p></div>
<div class="p-4 bg-white/5 rounded-card"><p class="text-body font-semibold text-white">EU-only inference</p><p class="text-small text-white/70 mt-1">LLM processing in EU data centres. Optionally self-hosted with open-weight models.</p></div>
<div class="p-4 bg-white/5 rounded-card"><p class="text-body font-semibold text-white">No SaaS</p><p class="text-small text-white/70 mt-1">Full source code access. No data leaves your infrastructure. CLOUD Act-safe on request.</p></div>
</div>

<!-- Multi-Tenant Architecture Diagram -->
<div class="mt-8 border border-white/20 rounded-card p-6 sm:p-8">
<p class="text-xs font-bold uppercase tracking-wider text-gosign-accent-on-dark mb-6">Data flow: Professional-secrecy-compliant multi-tenant setup</p>
<div class="border border-white/30 rounded-card p-4 sm:p-6">
<p class="text-small font-semibold text-white/90 mb-4">Firm infrastructure (professional secrecy control domain)</p>
<div class="grid grid-cols-3 gap-3 sm:gap-4">
<div class="border border-white/20 rounded-card p-3 text-center"><p class="text-small font-semibold text-white">Client A</p><p class="text-xs text-white/60 mt-1">Data</p></div>
<div class="border border-white/20 rounded-card p-3 text-center"><p class="text-small font-semibold text-white">Client B</p><p class="text-xs text-white/60 mt-1">Data</p></div>
<div class="border border-white/20 rounded-card p-3 text-center"><p class="text-small font-semibold text-white">Client C</p><p class="text-xs text-white/60 mt-1">Data</p></div>
</div>
<div class="flex justify-center my-3"><svg class="w-5 h-5 text-white/60" fill="none" viewBox="0 0 24 24" stroke-width="2" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M19.5 13.5 12 21m0 0-7.5-7.5M12 21V3" /></svg></div>
<div class="border border-gosign-accent/40 bg-white/5 rounded-card p-4 text-center">
<p class="text-small font-semibold text-white">Finance Agent (Decision Layer)</p>
<p class="text-xs text-white/60 mt-1">Rule sets versioned per client</p>
</div>
<div class="flex justify-center my-3"><svg class="w-5 h-5 text-white/60" fill="none" viewBox="0 0 24 24" stroke-width="2" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M19.5 13.5 12 21m0 0-7.5-7.5M12 21V3" /></svg></div>
<div class="border border-white/20 bg-white/5 rounded-card p-4 text-center">
<p class="text-small font-semibold text-white">LLM (Self-Hosted / EU-only Cloud)</p>
<p class="text-xs text-white/60 mt-1">No client data in prompts</p>
</div>
<div class="mt-4 border border-white/20 bg-white/5 rounded-card p-4 text-center">
<p class="text-small font-semibold text-white">DATEV / SAP (Client-separated)</p>
</div>
</div>
<p class="text-xs text-white/50 mt-4 text-center italic">No data leaves this control domain</p>
</div>

</div></div></section>

<!-- Process -->
<section class="py-section bg-gosign-dark text-white"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><h2 class="text-h1 font-bold">From First Agent to Finance Platform</h2><div class="grid md:grid-cols-3 gap-8 mt-8"><div><p class="text-xs font-bold uppercase tracking-wider text-gosign-accent-on-dark">Discover - 1 week</p><p class="text-body-lg text-gosign-text-on-dark/80 mt-2">Process analysis with your finance team. Map posting logic, document rule sets, understand system landscape. Prioritize use cases - typically: document processing or depreciation logic as entry point.</p></div><div><p class="text-xs font-bold uppercase tracking-wider text-gosign-accent-on-dark">Build - 3-4 weeks</p><p class="text-body-lg text-gosign-text-on-dark/80 mt-2">Production PoC. One agent, one finance process, live in your infrastructure. Decision Layer, governance, audit trail - from day one. Cert-Ready from the start, not retrofitted.</p></div><div><p class="text-xs font-bold uppercase tracking-wider text-gosign-accent-on-dark">Scale - Ongoing</p><p class="text-body-lg text-gosign-text-on-dark/80 mt-2">More agents for more finance processes. Correction postings, expense receipts, tax assessments, intercompany. The architecture grows - same governance, same auditability.</p></div></div><p class="text-body text-gosign-text-on-dark/60 mt-6 italic">After 12-18 months, you operate your Finance Agents independently. Full access to source code, prompts, and rule versions. No vendor lock-in.</p><p class="text-body text-gosign-text-on-dark/80 mt-4">Model-agnostic: Whether Azure OpenAI, Claude, Llama, or Mistral - the rule sets and decision logic remain identical. Switching models requires no changes to your posting rules.</p></div></section>

<!-- Business Impact -->
<section class="py-section bg-gosign-light"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow"><h2 class="text-h1 font-bold text-gosign-dark">Business Impact</h2><div class="grid grid-cols-1 sm:grid-cols-3 gap-4 mt-6"><div class="border border-gosign-border rounded-card p-4 bg-gosign-white text-center"><p class="text-h1 font-bold text-gosign-accent-text">2-4 EUR</p><p class="text-body text-gosign-text-light mt-1">Processing cost per invoice (best-in-class) vs. ~12 EUR on average (Ardent State of ePayables 2024)</p></div><div class="border border-gosign-border rounded-card p-4 bg-gosign-white text-center"><p class="text-h1 font-bold text-gosign-accent-text">30-40%</p><p class="text-body text-gosign-text-light mt-1">fewer correction postings through consistent rule application (experience value; industry benchmark: exception rate 9% vs. 22%, Ardent 2024)</p></div><div class="border border-gosign-border rounded-card p-4 bg-gosign-white text-center"><p class="text-h1 font-bold text-gosign-accent-text">7.5 days</p><p class="text-body text-gosign-text-light mt-1">faster month-end close on average (MIT Sloan / Stanford GSB 2025)</p></div></div><div class="mt-6 space-y-4"><p class="text-body-lg text-gosign-text-light">Auditable decision logic for external audit and internal revision.</p><p class="text-body-lg text-gosign-text-light">Consistent posting logic across all locations and entities.</p><p class="text-body-lg text-gosign-text-light">Cert-Ready by Design - structurally audit-ready, not documented retroactively.</p><p class="text-body-lg text-gosign-text-light">Reduced audit effort through complete decision records per document.</p></div></div></div></section>

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Finance Agent Readiness Assessment</p>
<p class="text-body text-gosign-text mb-4">7 questions, 3 minutes: How ready is your finance organisation for AI Agents?</p>
<a href="/en/finance-agent-readiness/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Start assessment &rarr;</a>
</div>

<!-- Finance Agent Assessment -->
<section class="py-section bg-gosign-dark text-white"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow">
<h2 class="text-h1 font-bold">Finance Agent Assessment: 49 agents assessed and prioritised</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4">Which finance agents exist, what governance do they need, and where should you start? The assessment evaluates 49 agents across 6 dimensions - from Agent Readiness to GoBD (German record-keeping standard) classification. Interactive quadrant analysis, micro-decision tables, and decision records per agent.</p>
<a href="/en/finance-agent-catalog/" class="inline-flex items-center gap-2 mt-4 text-body font-semibold text-gosign-accent-on-dark hover:underline">Go to Finance Agent Assessment &rarr;</a>
</div></div></section>

<!-- Deep Dive -->
<section class="py-section bg-gosign-white"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><h2 class="text-h2 font-bold text-gosign-dark mb-2">Deep Dive in the Agent Briefing</h2><p class="text-body text-gosign-text-light mb-6">Our article series for decision-makers automating finance processes with AI Agents.</p><div class="grid grid-cols-1 sm:grid-cols-3 gap-6"><a href="/en/magazine/ai-costs-tco-comparison/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors"><p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Finance</p><p class="text-body font-semibold text-gosign-dark">AI Costs Compared: TCO Analysis for Enterprise</p></a><a href="/en/magazine/decision-layer-shadow-ai/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors"><p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p><p class="text-body font-semibold text-gosign-dark">Decision Layer vs. Shadow AI: Why Governance Comes Before Speed</p></a><a href="/en/magazine/ai-hosting-strategies-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors"><p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p><p class="text-body font-semibold text-gosign-dark">AI Hosting: EU SaaS, German Data Centre, or Self-Hosted?</p></a></div></div></section>

--- Glossary - Enterprise AI Terms ---
> Key terms from enterprise AI. From Agent to Zero-Trust - clearly defined, consistently used across all Gosign documentation.

<article class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<div class="prose prose-lg prose-headings:text-gosign-dark prose-headings:font-bold prose-h2:text-h2 prose-h2:mt-12 prose-h2:mb-4 prose-h3:text-h3 prose-h3:mt-8 prose-h3:mb-3 prose-p:text-gosign-text prose-p:leading-relaxed prose-a:text-gosign-accent-text prose-a:underline prose-a:decoration-gosign-accent-text/30 hover:prose-a:decoration-gosign-accent-text prose-strong:text-gosign-dark prose-ul:text-gosign-text prose-ol:text-gosign-text prose-hr:border-gosign-border">

## Agent Types

### Document Agent

A specialized AI agent that reads, understands, and processes documents. No template recognition, no rigid OCR - contextual language understanding. Document Agents process invoices, sick leave certificates, contracts, certificates, and receipts. Every decision is documented via the Decision Layer.

→ [Document Agents in detail](/en/services/ai-agents/)

### Workflow Agent

An AI agent that orchestrates business processes across systems. From incoming mail through approval to booking. Every step is logged. When queries arise or information is missing, the workflow pauses - it does not abort.

→ [Workflow Agents in detail](/en/services/ai-agents/)

### Knowledge Agent

An AI agent that provides contextual answers from enterprise knowledge. Company agreements, policies, collective bargaining agreements. Every answer includes source reference and rule version. Without a source, no answer is given.

→ [Knowledge Agents in detail](/en/services/ai-agents/)

---

## Governance Terms

### Decision Layer

The Decision Layer decomposes every business process into individual decision steps and defines upfront for each: Does a human decide, does a rule set apply, or does the AI decide autonomously?

Where discretion, discrimination risk, or employee representation requirements are involved, the architecture enforces human review. Where a decision is deterministic - collective agreement terms, deadline checks, booking logic - the agent applies the rule set consistently. And where the agent is confident enough and has permission: it decides independently. It interprets documents, classifies situations, evaluates context - demonstrably more consistent and legally sound than manual processing. Confidence Routing controls when the agent acts autonomously and when it escalates.

Every decision is documented - who decided what, when, on what basis, with what outcome. Auditable for external auditors, employee representation bodies, and internal compliance.

Technically, the Decision Layer sits between AI Agent and target system (e.g., SAP, [DATEV](https://www.datev.de/), [Sage](https://www.sage.com/), [Workday](https://www.workday.com/)). It evaluates every agent decision by confidence and risk category and routes automatically. Every decision generates a complete, immutable decision record: input, model, applied rule set with version, confidence score, decision path, outcome, timestamp.

→ [Decision Layer at Gosign](/en/decision-layer/)

### Human-in-the-Loop

An architectural principle where final decision authority remains with humans. Not added retroactively, but integrated into the agent architecture from the start. At low confidence or exceptions, the agent automatically escalates to the responsible specialist - with complete context and recommendation.

### Governance by Design

Governance requirements are not added after the fact but are an integral part of the agent architecture. Audit trail, role concept, Decision Layer, and Human-in-the-Loop are present from day 1. The opposite of Shadow IT.

→ [Governance by Design](/en/governance/)

### Audit Trail

The complete documentation of every agent decision: input data, applied rule, rule version, confidence score, result, timestamp. Not just for internal traceability - but for auditors, works councils, and certification audits.

### Cert-Ready by Design

An architectural approach where all controls and documentation mechanisms are built to meet the requirements of common audit standards (ISA, PS 951, IDW, GoB/GoBD (German record-keeping standard)) during normal operations. No retroactive audit preparation.

→ [Cert-Ready by Design](/en/governance/cert-ready/)

### Co-determination (Mitbestimmung)

The German right to workplace co-determination through the works council (BetrVG). For AI agents that process employee data or prepare personnel decisions, involving the works council is legally required. Gosign agents are designed to be works-council-ready from the start.

→ [Co-determination & AI Agents](/en/governance/co-determination/)

### Micro-Decision

A micro-decision is a single, defined decision step within a business process. The Decision Layer decomposes every process into micro-decisions and defines for each one: does a human decide, does a rule set apply, or does the AI decide autonomously? Where discretion, discrimination risk, or employee representation requirements are involved, the architecture enforces human review. Where the decision is deterministic, the agent applies the rule set. Where the agent is confident enough and has permission, it decides independently - interpreting documents, classifying situations, evaluating context. This is not if-then-else - this is judgment within defined guardrails. Each micro-decision generates its own audit trail entry.

### Confidence Routing

Confidence Routing is the mechanism in the Decision Layer that automatically evaluates every agent decision by confidence and risk category and controls the decision path. High confidence with low risk leads to autonomous processing. Low confidence or high risk leads to escalation to a human. Thresholds are configurable and tenant-specific.

### Works Council Agreement as System Constraint (Betriebsvereinbarung)

In Gosign's architecture, works council agreements (Betriebsvereinbarungen) are implemented as technical constraints in the Decision Layer. Each works council agreement is translated into a versioned rule set. If the works council agreement specifies, for example, that performance evaluations may not be fully automated, this is technically enforced as a Human-in-the-Loop rule - the agent cannot bypass it. The works council can verify in the Auditor Portal whether its requirements are technically implemented.

### Shadow IT

IT systems operated without the knowledge or approval of the IT department. Particularly critical for AI agents, as uncontrolled LLM usage creates data privacy, compliance, and security risks. Gosign agents are integrated into existing IT governance - not as a parallel system.

---

## Infrastructure Terms

### Retrieval Augmented Generation (RAG)

An architecture where an LLM doesn't just respond from its training corpus but additionally retrieves relevant documents from a knowledge base. In enterprise RAG: semantic chunking, metadata enrichment, hybrid search, source citation, and regular re-indexing.

→ [RAG Infrastructure](/en/services/infrastructure/)

### LLM Hosting

Operating Large Language Models. Cloud (Azure OpenAI, Google Vertex AI - EU regions with DPAs), Self-Hosted ([Llama](https://llama.meta.com/), [Mistral](https://mistral.ai/), [DeepSeek](https://www.deepseek.com/) - open source, own hardware), or Hybrid (sensitive data self-hosted, non-critical loads in the cloud).

### Model-Agnostic

The property of an agent architecture not being bound to a specific LLM. Gosign agents work with Claude, ChatGPT, Gemini, Llama, Mistral, DeepSeek, and gpt-oss. Switching models does not change business logic, rule sets, or the audit trail.

### Co-Build

Gosign's model for client enablement. The agent is developed jointly, the client's team is built up in parallel. After 12-18 months, the client operates their agents independently. No vendor lock-in, no permanent consulting model.

---

## Regulatory

### EU AI Act

The EU Artificial Intelligence Act (Regulation (EU) 2024/1689). Classifies AI systems by risk level and defines requirements for transparency, documentation, human oversight, and risk management. Particularly relevant for AI agents in HR and finance.

→ [EU AI Act Readiness](/en/governance/eu-ai-act/)

### PII (Personally Identifiable Information)

Personal data that can directly or indirectly identify a natural person. In the context of Document Intelligence: name, address, date of birth, social security number, salary, bank details, biometric data. PII detection is the prerequisite for pseudonymization and redaction.

### Roundtrip Pseudonymization

Three-stage process for GDPR-compliant document processing with language models. Step 1: Personal data is replaced with consistent pseudonyms. Step 2: The pseudonymized document is processed by the language model. Step 3: In the result, pseudonyms are replaced with real data. The model never sees personal data at any point. The mapping table never leaves the pre-processing layer.

### Document Intelligence

The Document Agent's capability to not only read and process documents, but also protect them: PII anonymization for LLM input, rule-based contract redaction for different recipients, and automated signature detection. All three capabilities are governed by the Decision Layer - for each decision step, it defines: human, ruleset, or AI.

→ [Document Intelligence](/en/services/document-intelligence/)

### Data Residency

Control over where data is physically stored and processed. In enterprise AI infrastructure: EU regions (Azure West Europe, GCP europe-west3), DPAs with all sub-processors, no data transfer outside the defined scope.

→ [Data Residency at Gosign](/en/governance/data-residency/)

</div>
</div>
</article>

--- Cert-Ready by Design ---
> Controls as first-class data objects. Automatic evidence generation. Live Auditor Portal. Structurally audit-ready - not retroactively documented.

<!-- The Principle -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">The Principle</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
In traditional compliance approaches, controls are described in documents, evidence is collected manually, and audits are conducted as periodic projects. An auditor asks for proof, an employee searches for a screenshot, someone creates a spreadsheet.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Cert-Ready by Design reverses this: controls are technical data objects in the system. Evidence is generated automatically. The auditor sees the live status - not a snapshot from last week.
</p>
</div>
</section>

<!-- Three Differentiators -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">What Cert-Ready by Design Differentiates</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Controls Live in the System</h3>
<p class="text-body text-gosign-text-light mt-2">Not in Confluence. Not in a Word document. Not in a GRC tool updated once a year. Controls are data objects in the database - live, versioned, testable.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Evidence Is Generated Automatically</h3>
<p class="text-body text-gosign-text-light mt-2">No human collects evidence. No human creates screenshots. No human copies logs. The evidence generator runs automatically - periodically or on change. If a control cannot generate its evidence, that itself is a finding.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Complete Drill-Down</h3>
<p class="text-body text-gosign-text-light mt-2">From the traffic light on the dashboard to the concrete RLS policy with its name and the test SQL that verifies its effectiveness. No 'ask the developer.' Everything in one path.</p>
</div>
</div>
</div>
</section>

<!-- Controls as First-Class Data Objects -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Controls as First-Class Data Objects</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Every control in the Gosign architecture is a data object with four properties:
</p>

<div class="mt-8 space-y-8">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">1. Technical Implementation</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
The control is not just documented - it is implemented. Examples: an RLS policy that enforces tenant isolation at database level, an API check that validates the rule version before every agent decision, a trigger that automatically writes an audit entry on configuration changes. The implementation is the truth - not a document claiming the implementation exists.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">2. Automatic Evidence Generator</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Every control has an assigned evidence generator. It runs periodically or event-based and produces evidence automatically: RLS policy active? Test query against the policy, result documented. Audit trail complete? Automatic integrity check, gaps detected. Encryption active? Certificate status checked, algorithm documented.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
The smallest unit of evidence is the <a href="/en/magazine/decision-act-contestable-ai-decisions/" class="text-gosign-accent-text hover:underline">decision act</a> per micro-decision: an immutable record with input, applied business rule including version, confidence, model version, result, timestamp, and contestation path - the foundation the controls build on.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">3. Evidence History</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Every evidence record is stored with: timestamp of collection, status (passed, failed, warning), version number of the control, version number of the test logic, raw data for drill-down. The history is immutable. An auditor can verify for any point in time whether a control was active and effective.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">4. Auditor View with Drill-Down</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
The auditor sees in the Auditor Portal: traffic-light status per control (green / yellow / red), last evidence timestamp, trend over time (control stability), drill-down from the status indicator to the concrete RLS policy, to the test SQL, to the test result. The drill-down is the decisive difference. A green dot on a dashboard is worthless if the auditor cannot verify what lies behind it.
</p>
</div>
</div>
</div>
</div>
</section>

<!-- Control Object Structure -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Cert-Ready Control Object - Structure</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Every control is a structured data object with framework mapping, technical implementation, automatic evidence generator, and audit view.
</p>
</div>
<div class="mt-8">
<pre class="bg-gosign-dark text-white p-6 rounded-card overflow-x-auto text-small font-mono leading-relaxed"><code>Control Object {
id:                 "ctrl-rbac-001"
name:               "Tenant isolation at database level"
category:           "Access Control"

implementation: {
type:             "RLS Policy"
reference:        "policies/tenant_isolation.sql"
deployed:         true
last_verified:    "2026-02-20T09:14:00Z"
}

evidence_generator: {
type:             "automated_test"
schedule:         "every_6h"
test_reference:   "tests/tenant_isolation_test.sql"
}

evidence_history: [
{
timestamp:      "2026-02-20T09:14:00Z"
status:         "passed"
control_version: "1.3"
test_version:   "2.1"
raw_data:       { ... }
},
...
]

framework_mapping: {
iso_27001:        "A.9.4.1"
soc2:             "CC6.1"
eu_ai_act:        "Art. 12"
}

owner:              "security-team"
last_change:        "2026-02-18T14:22:00Z"
change_reason:      "Policy update for new entity"
}</code></pre>
</div>
</div>
</section>

<!-- Auditor Portal -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Auditor Portal</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
The Auditor Portal is the interface between the technical system and the auditor. It provides:
</p>
</div>
<div class="mt-8 grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-3 gap-6">
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Dashboard</h3>
<p class="text-body text-gosign-text-light mt-2">Overview of all controls with traffic-light status, grouped by framework category.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Control Detail</h3>
<p class="text-body text-gosign-text-light mt-2">Description, technical implementation, evidence history, last change, assigned owner.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Drill-Down</h3>
<p class="text-body text-gosign-text-light mt-2">From the overview to the concrete test result, including test logic and raw data.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Export</h3>
<p class="text-body text-gosign-text-light mt-2">Evidence packages for external auditors, machine-readable (JSON) or as PDF report.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Change History</h3>
<p class="text-body text-gosign-text-light mt-2">When was a control changed, by whom, why. Every change documented.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Override History</h3>
<p class="text-body text-gosign-text-light mt-2">When a human override overruled an agent decision - documented with reason, person, timestamp.</p>
</div>
</div>
</div>
</section>

<!-- Framework Mapping -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Framework Mapping</h2>
<p class="text-body-lg font-semibold text-gosign-dark mt-4">Structurally prepared for every framework.</p>
<ul class="mt-4 space-y-2 text-body-lg text-gosign-text-light">
<li><a href="https://www.iso.org/isoiec-27001-information-security.html" target="_blank" rel="noopener noreferrer">ISO 27001</a>: Controls are mapped to Annex A measures. Evidence is generated automatically.</li>
<li>SOC2: Trust Service Criteria (CC6, CC7, CC8) are represented as control categories.</li>
<li>PS 951 / ISAE 3402: Audit standards for IT service providers. Controls and evidence are prepared for auditors.</li>
<li>EU AI Act (UK: UK AI regulatory framework): Articles 9, 12, 13, 14 are implemented as controls in the system.</li>
<li>IDW PS 880: Software audit standards. In Germany specifically, GoB / GoBD (German record-keeping standard) principles of proper bookkeeping apply.</li>
<li>The mapping changes. The control structure remains identical. When a new framework becomes relevant, it is mapped - the controls already exist.</li>
</ul>
</div>
</div>
</section>

<!-- What Cert-Ready Is Not -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">What Cert-Ready by Design Is Not</h2>
<div class="mt-6 space-y-4">
<p class="text-body-lg text-gosign-text-light">
<strong class="text-gosign-dark">Not a certification promise.</strong> Cert-Ready by Design does not mean the system is certified. It means the architecture is structurally prepared to be audited and certified at any time.
</p>
<p class="text-body-lg text-gosign-text-light">
<strong class="text-gosign-dark">Not a GRC tool.</strong> Cert-Ready by Design does not replace a GRC platform. It complements it - through technical controls that live in the system, not only in a separate compliance database.
</p>
<p class="text-body-lg text-gosign-text-light">
<strong class="text-gosign-dark">Not a one-time audit.</strong> Cert-Ready by Design is continuous. Evidence is generated continuously, controls are tested continuously. There is no "audit mode" - the system is always in audit mode.
</p>
</div>
</div>
</section>

<!-- Deep Dive -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Deep Dive in the Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Our article series for decision-makers implementing AI agents in the enterprise.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/en/magazine/cert-ready-by-design/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Cert-Ready by Design - Audit-Proof AI from the Start</p>
</a>
<a href="/en/magazine/eu-ai-act-hr/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">EU AI Act: What HR Departments Must Do Now</p>
</a>
<a href="/en/magazine/ai-governance-dashboard/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">AI Governance Dashboard: Agent Monitoring for Enterprises</p>
</a>
</div>
</div>
</section>

--- Employee Oversight & Co-determination for AI Systems ---
> AI agents compliant with employee oversight. Human-in-the-Loop, governance frameworks as system constraints, audit trail as architecture

<!-- Why Employee Oversight Is Architecture -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Why Employee Oversight Is an Architecture Topic</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
AI agents deployed in HR processes, personnel decisions, or employee-relevant workflows require oversight by employee representation bodies in most jurisdictions. In Germany specifically, this is a strict legal requirement under the Works Constitution Act (Betriebsverfassungsgesetz) - the most demanding co-determination framework globally.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Most AI deployments treat employee oversight as an organizational problem: a workshop with employee representatives, a governance agreement, a protocol. That is not enough. When the agent makes decisions affecting employees, oversight must be technically enforced - not just agreed upon.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Gosign treats employee oversight as an architectural principle. The Decision Layer technically enforces compliance with governance frameworks (collective agreements, works agreements, or company policies). The audit trail documents every decision. Employee representation bodies can trace what the agent does, why it does it, and when a human intervenes.
</p>
</div>
</section>

<!-- Regulatory Landscape -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Employee Oversight Rights for AI Systems</h2>
<div class="mt-8 space-y-8">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">EU Standard: Co-determination and AI Transparency</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Across the EU, employee representation bodies have rights regarding the introduction and use of AI systems that process employee data or influence personnel decisions. In Germany specifically, &sect;87 of the Works Constitution Act grants the works council co-determination rights over "technical facilities designed to monitor the behavior or performance of employees." AI agents that automate HR processes fall under this regulation. Under German law, &sect;90 BetrVG further requires early involvement during the planning phase of new technical systems - not just at go-live.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark"> US Standard: No Statutory Co-determination</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
The US has no statutory equivalent to works councils or co-determination law. Employee oversight for AI typically relies on EEOC anti-discrimination requirements, state-level AI employment laws (e.g., NYC Local Law 144 for automated employment decision tools), and internal corporate governance policies. The Gosign architecture provides the transparency and audit infrastructure that US employers need to demonstrate compliance with these evolving requirements.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark"> UK Standard: Post-Brexit Framework</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
The UK retains employee consultation rights under the Information and Consultation of Employees Regulations but does not follow EU co-determination directives post-Brexit. UK GDPR Article 22 provides employee rights regarding automated decision-making. The Gosign architecture satisfies these requirements through its Decision Layer and audit trail.
</p>
</div>
</div>
</div>
</section>

<!-- Architectural Implementation -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Architectural Implementation</h2>
</div>
<div class="mt-8 grid grid-cols-1 sm:grid-cols-3 gap-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Governance Frameworks as System Constraints</h3>
<p class="text-body text-gosign-text-light mt-2">Every governance framework - collective agreements, works agreements, or company policies - is translated into a rule set in the Decision Layer with version ID, validity date, and scope. The agent automatically checks every decision against stored constraints. If a constraint would be violated, the decision is not executed autonomously.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Human-in-the-Loop as Architecture</h3>
<p class="text-body text-gosign-text-light mt-2">Not a blanket approval process but architecturally controlled routing. Autonomous decision when: high confidence, low risk, no constraint affected. Human-in-the-Loop when: bias risk, employee oversight topics, low confidence. The routing cannot be bypassed.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Audit Trail for Employee Representatives</h3>
<p class="text-body text-gosign-text-light mt-2">Every agent decision generates a complete audit trail entry: timestamp, agent, input, applied rules (with versions), assessment with confidence and risk score, decision path, output, and status. Employee representation bodies - such as works councils, trade unions, or staff committees - can view and filter all decisions.</p>
</div>
</div>
</div>
</section>

<!-- Audit Trail Example -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Audit Trail - Example</h2>
</div>
<div class="mt-8">
<pre class="bg-gosign-dark text-white p-6 rounded-card overflow-x-auto text-small font-mono leading-relaxed"><code>Audit Trail Entry:
&#x251C;&#x2500;&#x2500; Timestamp:          2026-02-20T09:14:22Z
&#x251C;&#x2500;&#x2500; Agent:              hr-merit-cycle-agent
&#x251C;&#x2500;&#x2500; Input:              Salary adjustment employee #4711
&#x251C;&#x2500;&#x2500; Applied Rules:
&#x2502;   &#x251C;&#x2500;&#x2500; Collective agr.: TV-V, Version 2025.2
&#x2502;   &#x251C;&#x2500;&#x2500; Governance:      Policy-2024-003, &sect; 4 Para. 2
&#x2502;   &#x2514;&#x2500;&#x2500; Salary Band:    Band E3, Range 52,000-68,000 EUR
&#x251C;&#x2500;&#x2500; Assessment:
&#x2502;   &#x251C;&#x2500;&#x2500; Confidence:     0.94
&#x2502;   &#x251C;&#x2500;&#x2500; Risk Score:     low
&#x2502;   &#x2514;&#x2500;&#x2500; Result:         Within band, within policy constraint
&#x251C;&#x2500;&#x2500; Decision Path:      autonomous (no constraint violated)
&#x251C;&#x2500;&#x2500; Output:             Booking proposal: adjustment +3.2%
&#x2514;&#x2500;&#x2500; Status:             approved</code></pre>
</div>
</div>
</section>

<!-- RBAC -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Role-Based Access Control (RBAC)</h2>
<div class="mt-6 space-y-4">
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Agent Operator:</strong> Configures agents, changes rule sets (versioned, documented)</p>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">HR Specialist:</strong> Views agent decisions within their area of responsibility</p>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Employee Representative:</strong> Insight into decision patterns, constraint status, audit trail (anonymized where necessary)</p>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Auditor / Internal Audit:</strong> Full access to audit trail, evidence, control status</p>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Admin:</strong> System configuration, no access to professional decision data</p>
</div>
<p class="text-body-lg text-gosign-text-light mt-4">RBAC is enforced at database level via Row-Level Security.</p>
</div>
</section>

<!-- Templates -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Templates and Documentation</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Gosign provides templates for: governance agreements for AI deployment, technical descriptions for employee representatives, logging concepts, and escalation matrices. These are starting points - every governance framework must be individually negotiated to fit your jurisdiction and organizational structure. Gosign provides the technical foundation, not legal advice.
</p>
</div>
</section>

<!-- What We Do Not Do -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">What We Do Not Do</h2>
<div class="mt-6 space-y-2">
<p class="text-body-lg text-gosign-text-light">We do not replace governance frameworks. We map them technically.</p>
<p class="text-body-lg text-gosign-text-light">We do not provide legal advice. We deliver the technical infrastructure.</p>
<p class="text-body-lg text-gosign-text-light">We do not automate decisions subject to employee oversight without Human-in-the-Loop.</p>
<p class="text-body-lg text-gosign-text-light">We do not "train" agents on oversight decisions. Agents do not learn uncontrolled.</p>
</div>
</div>
</section>

<!-- Legal Framework Trust -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Employee Oversight Is Architecture</h2>
<p class="text-body-lg font-semibold text-gosign-dark mt-4">Built for the most demanding regulatory environment globally - German co-determination law, EU AI Act, and GDPR. This means the Decision Layer meets or exceeds compliance requirements in virtually any jurisdiction.</p>
<ul class="mt-4 space-y-2 text-body-lg text-gosign-text-light">
<li>The Gosign architecture technically ensures that governance frameworks - collective agreements, works agreements, or company policies - are respected.</li>
<li>Employee representation bodies - whether works councils, trade unions, staff committees, or other authorized oversight bodies - can verify every agent decision through the Auditor Portal.</li>
<li>Human-in-the-Loop is enforced where required - architecturally, not optionally.</li>
<li>Agents become part of your existing IT governance - not a parallel universe.</li>
</ul>
</div>
</div>
</section>

<!-- Deep Dive -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Deep Dive in the Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Our article series for decision-makers implementing AI agents in the enterprise.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/en/magazine/works-council-ai-co-determination/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Works Council and AI, Co-Determination as Architecture Constraint</p>
</a>
<a href="/en/magazine/agent-governance-hr/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Why HR Departments Need to Build Agent Governance Now</p>
</a>
<a href="/en/magazine/human-in-the-loop-architecture/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Human-in-the-Loop - Architectural Principle, Not Checkbox</p>
</a>
</div>
</div>
</section>

--- Data Residency & GDPR ---
> Data sovereignty for enterprise AI agents. EU-only processing, Row-Level Security, tenant isolation, no third-party data flows.

<!-- Core Principle -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Core Principle</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
AI agents process business-critical data: personnel data, financial data, contract data. The question of where this data is processed and who has access is non-negotiable for enterprise clients. The <a href="/en/magazine/decision-layer-explained/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Decision Layer</a> breaks every process into individual decision steps and defines for each step whether a human, a rule set, or an AI decides - including which data may be processed.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
The Gosign architecture is based on one core principle: all data remains in the client's infrastructure. Gosign does not operate its own cloud, does not store client data, and has no permanent access to production systems. The complete <a href="/en/governance/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">governance architecture</a> ensures that every data processing activity is documented and traceable.
</p>
</div>
</div>
</section>

<!-- Deployment Options -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">Deployment Options</h2>
<div class="grid grid-cols-1 md:grid-cols-2 gap-6 lg:gap-8">
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 15a4.5 4.5 0 0 0 4.5 4.5H18a3.75 3.75 0 0 0 .75-7.425A4.502 4.502 0 0 0 14.25 7.5a5.25 5.25 0 0 0-10.233 2.033A4.5 4.5 0 0 0 2.25 15Z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Azure (EU)</h3>
<p class="text-body text-gosign-text-light mt-3">
<a href="https://azure.microsoft.com/en-us/explore/global-infrastructure/geographies/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Azure</a> regions: West Europe (Amsterdam), North Europe (Dublin), Germany West Central (Frankfurt). Azure OpenAI for LLM processing within Azure EU. Microsoft's DPA and EU Data Processing Addendum.
</p>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">GCP (EU)</h3>
<p class="text-body text-gosign-text-light mt-3">
<a href="https://cloud.google.com/about/locations" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">GCP</a> regions: europe-west1 (Belgium), europe-west3 (Frankfurt), europe-west4 (Netherlands). Vertex AI for LLM processing within GCP EU. Google's DPA and EU Standard Contractual Clauses.
</p>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M5.25 14.25h13.5m-13.5 0a3 3 0 0 1-3-3m3 3a3 3 0 1 0 0 6h13.5a3 3 0 1 0 0-6m-16.5-3a3 3 0 0 1 3-3h13.5a3 3 0 0 1 3 3m-19.5 0a4.5 4.5 0 0 1 .9-2.7L5.737 5.1a3.375 3.375 0 0 1 2.7-1.35h7.126c1.062 0 2.062.5 2.7 1.35l2.587 3.45a4.5 4.5 0 0 1 .9 2.7m0 0a3 3 0 0 1-3 3m0 3h.008v.008h-.008v-.008Zm0-6h.008v.008h-.008v-.008Zm-3 6h.008v.008h-.008v-.008Zm0-6h.008v.008h-.008v-.008Z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">AWS (EU)</h3>
<p class="text-body text-gosign-text-light mt-3">
<a href="https://aws.amazon.com/about-aws/global-infrastructure/regions_az/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">AWS</a> regions: eu-central-1 (Frankfurt), eu-west-1 (Ireland), eu-west-3 (Paris). Amazon Bedrock for LLM hosting (Claude, Llama, Mistral) within AWS EU. Amazon EKS for container orchestration, Aurora PostgreSQL for data. AWS DPA and EU Data Processing Addendum.
</p>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 17.25v1.007a3 3 0 0 1-.879 2.122L7.5 21h9l-.621-.621A3 3 0 0 1 15 18.257V17.25m6-12V15a2.25 2.25 0 0 1-2.25 2.25H5.25A2.25 2.25 0 0 1 3 15V5.25A2.25 2.25 0 0 1 5.25 3h13.5A2.25 2.25 0 0 1 21 5.25Z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Self-Hosted</h3>
<p class="text-body text-gosign-text-light mt-3">
Own data center or own servers. Open-source models: <a href="https://llama.meta.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Llama</a>, <a href="https://mistral.ai/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Mistral</a>, <a href="https://www.deepseek.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">DeepSeek</a> - operated locally. No data leaves the corporate network. Full control over hardware, software, and network.
</p>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M7.5 21 3 16.5m0 0L7.5 12M3 16.5h13.5m0-13.5L21 7.5m0 0L16.5 12M21 7.5H7.5" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Hybrid</h3>
<p class="text-body text-gosign-text-light mt-3">
Combination of cloud and self-hosted. Example: Self-hosted for sensitive HR data, Azure EU for document processing. The architecture supports different deployment options per agent.
</p>
</article>
</div>
</div>
</section>

<!-- Technical Data Protection -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Technical Data Protection Measures</h2>

<div class="mt-8 space-y-8">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Row-Level Security (RLS)</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Tenant isolation is enforced at database level - not at application level. A SQL query can physically only access records the executing context is authorized for. Isolation cannot be bypassed through application logic.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Encryption</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
At rest: All data encrypted (AES-256). In transit: All data transfers over TLS 1.3. Key management: Customer-owned keys (Bring Your Own Key) or platform-managed.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Access Control</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
RBAC (Role-Based Access Control) at all levels. No shared credentials, no service account with full access. Access is logged and traceable in the audit trail. Gosign has no permanent access to production data.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Data Deletion</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Deletion concept per GDPR Art. 17. Retention periods configurable per data type. Deletion covers all copies - database, audit trail, backups (after backup retention expires). Deletion protocols documented in audit trail.
</p>
</div>
</div>
</div>
</section>

<!-- LLM-Specific Data Protection -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">LLM-Specific Data Protection</h2>

<div class="mt-8 space-y-8">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Cloud LLMs (Azure OpenAI, Vertex AI, Amazon Bedrock)</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
When cloud LLMs are used, data to be processed is sent to the LLM service. Measures: Azure OpenAI data is not used for training OpenAI models. DPA/SCCs with the respective provider. Data minimization: only data necessary for processing is sent to the model. <a href="/en/magazine/pii-anonymization-llm-enterprise/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">PII anonymization</a> ensures that personal data is removed before LLM processing.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Self-Hosted Models (Llama, Mistral, DeepSeek)</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
With self-hosted models, no data leaves the client's infrastructure. The model runs locally, processing occurs on own hardware. Trade-off: self-hosted models are generally less capable than the latest proprietary models. More on hosting strategies in our article <a href="/en/magazine/ai-hosting-strategies-enterprise/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">AI Hosting: EU SaaS, German Data Center, or Self-Hosted?</a>
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">No Training on Client Data</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Gosign AI agents are not trained on client data. No fine-tuning, no re-training, no uncontrolled learning from production data. Agents use LLMs with prompts and rule sets - the models themselves are not modified.
</p>
</div>
</div>
</div>
</section>

<!-- GDPR Mapping -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">GDPR Mapping</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Each architectural component maps to a specific GDPR article. Details on implementation in the context of the <a href="/en/governance/eu-ai-act/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">EU AI Act</a>.
</p>
</div>
<div class="mt-8 overflow-x-auto">
<table class="w-full text-left text-small border-collapse min-w-[40rem]">
<thead>
<tr>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">GDPR Article</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Architectural Measure</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Art. 5 - Data minimization</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Only required data is processed. No stockpiling.</td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Art. 6 - Legal basis</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Data processing agreement (Art. 28) or legitimate interest, depending on context.</td>
</tr>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Art. 17 - Right to erasure</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Deletion concept with configurable periods, documented deletion.</td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Art. 25 - Privacy by Design</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">RLS, encryption, RBAC as architectural components.</td>
</tr>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Art. 28 - Data processing</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">DPA between client and Gosign, DPA between client and cloud provider.</td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Art. 30 - Records of processing</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Audit trail documents all processing activities.</td>
</tr>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Art. 32 - Security of processing</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Encryption, access control, regular review.</td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Art. 33/34 - Notification obligations</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Incident response process, audit trail for forensics.</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Distinction -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Distinction</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
This page describes technical architectural measures for data protection and data residency. The data protection legal assessment and formal GDPR conformity declaration are the responsibility of the controller (the client) and their data protection officers.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Gosign delivers the technical infrastructure. Legal responsibility lies with the operator.
</p>
</div>
</section>

<!-- Deep Dive -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Deep Dive in the Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Our article series for decision-makers implementing AI agents in the enterprise.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/en/magazine/pii-anonymization-llm-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">PII Anonymization for Enterprise AI</p>
</a>
<a href="/en/magazine/data-security-ai-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Data Security in Enterprise AI - Data Residency, GDPR and EU AI Act</p>
</a>
<a href="/en/magazine/ai-hosting-strategies-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">AI Hosting: EU SaaS, German Data Center, or Self-Hosted?</p>
</a>
</div>
</div>
</section>

--- DPA Checklist for AI Infrastructure - 25 Verification Questions ---
> Requirements checklist for data processing agreements in enterprise AI. 25 verification questions for legal, IT security, and employee representatives.

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-body-lg text-gosign-text-light">
A Data Processing Agreement (DPA) for AI infrastructure must address ten areas that standard SaaS DPAs do not cover: prompt logging policies, environment separation (dev/staging/production), model provider chains, in-flight vs. at-rest data processing, RAG embedding data protection, <a href="/en/governance/data-residency/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">third-country access to production data</a>, professional privilege compliance, PII tokenization, Decision Layer audit trails, and verifiability of technical measures. This checklist translates the ten gaps into 25 concrete verification questions.
</p>
<p class="text-body text-gosign-text-light mt-4">
The detailed analysis of the ten gaps is available in the magazine article: <a href="/en/magazine/dpa-ai-infrastructure-checklist/" class="text-gosign-accent-text hover:underline">Data Processing Agreements for AI Agents: What Your Standard Contract Misses</a>.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">A - Data Categories and Processing Purposes</h2>
<div class="space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">1</p>
<p class="text-body-lg text-gosign-text-light mt-1">Are prompt contents and model responses listed as distinct data categories in the DPA?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">2</p>
<p class="text-body-lg text-gosign-text-light mt-1">Is it established that content classification responsibility lies with the organization, not the provider?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">3</p>
<p class="text-body-lg text-gosign-text-light mt-1">Are embeddings/vectors classified as potentially personal data?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">4</p>
<p class="text-body-lg text-gosign-text-light mt-1">Does the DPA address special categories under Article 9 GDPR that may arise through user inputs?</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">B - Logging and Monitoring</h2>
<div class="space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">5</p>
<p class="text-body-lg text-gosign-text-light mt-1">Is request/response body logging disabled in the production environment?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">6</p>
<p class="text-body-lg text-gosign-text-light mt-1">What metadata is recorded (status codes, latencies, request IDs)?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">7</p>
<p class="text-body-lg text-gosign-text-light mt-1">Is debug logging verifiably disabled in production?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">8</p>
<p class="text-body-lg text-gosign-text-light mt-1">Are stack traces and error messages configured to exclude content data from logs?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">9</p>
<p class="text-body-lg text-gosign-text-light mt-1">Is verification of logging settings part of the release process?</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">C - Environment Separation and Access</h2>
<div class="space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">10</p>
<p class="text-body-lg text-gosign-text-light mt-1">Do separate environments exist (dev, staging, production) with distinct data policies?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">11</p>
<p class="text-body-lg text-gosign-text-light mt-1">Do dev/staging environments contain exclusively synthetic or anonymized data?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">12</p>
<p class="text-body-lg text-gosign-text-light mt-1">Is production access restricted to authorized roles within the EU/EEA? (See also: <a href="/en/governance/cert-ready/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Cert-Ready requirements</a>)</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">13</p>
<p class="text-body-lg text-gosign-text-light mt-1">Does a documented exception procedure exist for support cases involving data?</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">D - Model Providers and Sub-processors</h2>
<div class="space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">14</p>
<p class="text-body-lg text-gosign-text-light mt-1">Is the delineation clear: Which providers are sub-processors of the provider, and which operate in the organization's tenant?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">15</p>
<p class="text-body-lg text-gosign-text-light mt-1">Is content retention at model providers disabled?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">16</p>
<p class="text-body-lg text-gosign-text-light mt-1">Is the exclusion of training data usage contractually documented?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">17</p>
<p class="text-body-lg text-gosign-text-light mt-1">Where are the model endpoints located (EU region, US, other)?</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">E - Data Storage and Deletion</h2>
<div class="space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">18</p>
<p class="text-body-lg text-gosign-text-light mt-1">Is it established where persistent content data is stored (database, region, provider)?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">19</p>
<p class="text-body-lg text-gosign-text-light mt-1">What backup retention applies, and how are deleted data handled within backups?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">20</p>
<p class="text-body-lg text-gosign-text-light mt-1">Can individual users delete their own data within the application?</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">F - Regulated Industries</h2>
<div class="space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">21</p>
<p class="text-body-lg text-gosign-text-light mt-1">Does the DPA contain provisions for professional privilege compliance (&sect; 203 StGB or jurisdiction-specific equivalent)?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">22</p>
<p class="text-body-lg text-gosign-text-light mt-1">Are confidentiality commitments in place for all personnel with access?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">23</p>
<p class="text-body-lg text-gosign-text-light mt-1">Is PII tokenization available as an optional module?</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">G - <a href="/en/governance/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Governance</a> and Verifiability</h2>
<div class="space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">24</p>
<p class="text-body-lg text-gosign-text-light mt-1">Is an audit trail for agent decisions anchored as a contractual component?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">25</p>
<p class="text-body-lg text-gosign-text-light mt-1">Can technical and organizational measures be evidenced on request (configuration documentation, redacted log excerpts)?</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-body text-gosign-text-light">
This checklist is a requirements catalog from an architecture and governance perspective. It does not constitute legal advice. Legal review and formal assessment of the DPA is the responsibility of the controller's legal department or external counsel.
</p>
</div>
</section>

--- EU AI Act Readiness ---
> How the Gosign architecture addresses EU AI Act requirements for transparency, human oversight, record-keeping, and risk management as design principles.

<!-- Intro -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Architecture, Not Checklist</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
The <a href="https://eur-lex.europa.eu/eli/reg/2024/1689/oj" target="_blank" rel="noopener noreferrer">EU AI Act (Regulation (EU) 2024/1689)</a> regulates AI systems in the European Union. For enterprise AI agents making automated or semi-automated decisions in business-critical processes, four areas are particularly relevant.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
The Gosign architecture addresses these areas as design principles - not as a retroactive compliance layer.
</p>
</div>
</section>

<!-- EU AI Act Mapping Table -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">EU AI Act Architecture Mapping</h2>
<div class="overflow-x-auto -mx-4 sm:mx-0">
<table class="w-full text-left text-small border-collapse min-w-[48rem]">
<thead>
<tr>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Requirement</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Article</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Gosign Implementation</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Transparency</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Art. 13</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Decision Layer documents every decision path. Audit trail shows input &rarr; model &rarr; assessment &rarr; outcome.</td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Human Oversight</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Art. 14</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Human-in-the-Loop architecturally enforced. For risk decisions, the human decides. Not optional, but a design decision.</td>
</tr>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Explainability</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Art. 13(1)</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Every decision includes reasoning: which data, which model, which assessment logic, which result, which alternatives.</td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Risk Management</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Art. 9</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Governance Layer with bias monitoring, confidence tracking, anomaly detection. Cert-Ready Controls with automatic evidence generation.</td>
</tr>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Data Quality</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Art. 10</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Input validation in Agent Layer. Data provenance documented in audit trail.</td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Record-Keeping</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Art. 12</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Complete audit trail with timestamps, input hashes, model versions, decision paths. Immutable, exportable.</td>
</tr>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Technical Robustness</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Art. 15</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Multi-model capability (no single point of failure). Fallback strategies. Versioned models with rollback.</td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Right to Explanation of Individual Decisions</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Art. 86</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Every micro-decision produces a <a href="/en/magazine/decision-act-contestable-ai-decisions/" class="text-gosign-accent-text hover:underline">decision act</a>: input, applied rule with version and source, confidence, model version, result, contestation path. An Art. 86 request becomes a query, not a forensics project.</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Four Architectural Answers -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 space-y-12">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">How the Architecture Enforces Compliance</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Compliance is not a subsequent audit, but a result of the architecture. The following mechanisms ensure that EU AI Act requirements are technically met.
</p>
</div>
<div class="max-w-narrow">
<div class="flex items-start gap-4">
<span class="text-h1 font-bold text-gosign-accent-text leading-none">1</span>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Decision Layer: Transparency and Explainability</h3>
<p class="text-body-lg text-gosign-text-light mt-2">The Decision Layer documents every decision path completely. For every agent decision: input data, model used, model version, confidence score, assessment logic, result, and rejected alternatives. This documentation is created automatically as a byproduct of the decision, not as a retroactive record.</p>
</div>
</div>
</div>
<div class="max-w-narrow">
<div class="flex items-start gap-4">
<span class="text-h1 font-bold text-gosign-accent-text leading-none">2</span>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Human-in-the-Loop: Human Oversight</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Human-in-the-Loop is architecturally enforced, not optionally configured. The Decision Layer routes decisions automatically based on confidence score and risk category. For risk decisions, a human must review and approve. The agent cannot bypass this step. Escalation criteria are transparent and stored in the system.</p>
</div>
</div>
</div>
<div class="max-w-narrow">
<div class="flex items-start gap-4">
<span class="text-h1 font-bold text-gosign-accent-text leading-none">3</span>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Governance Layer: Risk Management and Monitoring</h3>
<p class="text-body-lg text-gosign-text-light mt-2">The Governance Layer continuously monitors all agent activities. Bias monitoring detects systematic biases. Confidence tracking identifies model degradation. Anomaly detection reports unexpected decision patterns. Cert-Ready Controls with automatic evidence generation ensure all audit evidence is available at any time.</p>
</div>
</div>
</div>
<div class="max-w-narrow">
<div class="flex items-start gap-4">
<span class="text-h1 font-bold text-gosign-accent-text leading-none">4</span>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Audit Trail: Record-Keeping</h3>
<p class="text-body-lg text-gosign-text-light mt-2">The audit trail captures every decision with timestamps, input hashes, model versions, and complete decision paths. The record is immutable and exportable in JSON, PDF, and CSV. System metadata such as models, versions, and deployment purpose are structured and available for registration obligations.</p>
</div>
</div>
</div>
</div>
</section>

<!-- Risk Classification -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Risk Classification</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Classification of an AI system into an EU AI Act risk class depends on the specific use case:
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong class="text-gosign-dark">Potentially High-Risk</strong> (depending on context): AI agents preparing or influencing personnel decisions (Art. 6, Annex III No. 4), AI agents used in creditworthiness assessment, AI agents influencing access to essential services.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong class="text-gosign-dark">Not High-Risk</strong> (typically): Document Agents classifying documents without making personnel decisions, Knowledge Agents providing information without making decisions.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
The Gosign architecture is designed for the strictest requirements. When an agent is deployed in a high-risk context, the architectural prerequisites are already in place.
</p>
</div>
</section>

<!-- Compliance Position -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Compliance Position</h2>
<p class="text-body-lg font-semibold text-gosign-dark mt-4">EU AI Act compliant by design.</p>
<ul class="mt-4 space-y-2 text-body-lg text-gosign-text-light">
<li>Our architecture is designed from the ground up for EU AI Act requirements.</li>
<li>Transparency, explainability, and human oversight are structurally unavoidable, not optionally configurable.</li>
<li>Every decision is automatically documented, not retroactively reconstructed.</li>
<li>The system is prepared for high-risk requirements, regardless of the specific use case classification.</li>
<li>Cert-Ready Controls ensure that audit evidence is available and exportable at any time.</li>
</ul>
</div>
</div>
</section>

<!-- Distinction -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Distinction</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong class="text-gosign-dark">This page describes architectural measures, not legal conformity.</strong> Actual EU AI Act compliance depends on the specific deployment context, risk classification, and legal assessment on a case-by-case basis.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Gosign delivers the technical architecture addressing EU AI Act requirements. Legal assessment and formal conformity declaration are the responsibility of the operator and their legal advisors.
</p>
</div>
</section>

<!-- Deep Dive -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Deep Dive in the Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Our article series for decision-makers implementing AI agents in the enterprise.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/en/magazine/eu-ai-act-hr/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">EU AI Act: What HR Departments Must Do Now</p>
</a>
<a href="/en/magazine/eu-ai-act-hr-high-risk/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">EU AI Act and HR: What Applies to AI in Personnel Decisions from 2 August 2026 (postponement to Dec 2027 provisionally agreed - Digital Omnibus, May 2026)</p>
</a>
<a href="/en/magazine/cert-ready-by-design/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Cert-Ready by Design - Audit-Proof AI from the Start</p>
</a>
</div>
</div>
</section>

--- Reference Architecture: 7 Layers for Enterprise AI ---
> 7-layer architecture for enterprise AI agents. Governance by Design, model-agnostic, infrastructure-agnostic. For CTOs and engineering decision-makers.

<!-- Overview -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Why Seven Layers</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
A monolithic AI system is not auditable, not scalable, and not maintainable. The 7-layer architecture separates responsibilities: each layer has a defined purpose and clear interfaces. Changing the model does not affect business logic. A new target system does not change the agent. A new compliance requirement does not change the infrastructure.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
This architecture is the result of enterprise requirements: tenant isolation, Audit Trail, transparency for employee representation bodies, EU AI Act conformity, model-agnostic deployment. Standard LLM APIs deliver none of this.
</p>
</div>
<img src="/images/diagrams/reference-architecture.svg" alt="Reference Architecture: 7 layers with Governance as cross-cutting concern - Presentation, Orchestration, Agent, Decision Layer, Model, Integration, Infrastructure" class="w-full rounded-card mt-8" width="1200" height="600" loading="lazy" />
</div>
</section>

<!-- Layer 1: Presentation -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">1. Presentation Layer</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
The interface between system and user. No business logic, no decisions - only display and input.
</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light"><strong>Chat UI:</strong> Web-based interface for end users (HR staff, accountants). PWA-capable, responsive.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Dashboard:</strong> Status overview for agents, running workflows, open escalations. Role-based: case workers see their cases, managers see KPIs.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Auditor Portal:</strong> Auditor access to Audit Trail, controls, and evidence. Read-only. For external auditors, employee representation bodies, and internal audit teams.</li>
<li class="text-body-lg text-gosign-text-light"><strong>REST API:</strong> Machine-readable interface for integration into existing systems. Versioned, documented, authenticated.</li>
</ul>
</div>
</div>
</section>

<!-- Layer 2: Orchestration -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">2. Orchestration Layer</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Coordinates data flow between agents, systems, and users. Manages workflows, queues, and API routing.
</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light"><strong>Workflow Engine:</strong> Open-source engines (Trigger.dev, Camunda) for complex, multi-step processes. Visual workflows, API integration, webhooks.</li>
<li class="text-body-lg text-gosign-text-light"><strong>API Gateway:</strong> Unified entry point with rate limiting, authentication, logging, monitoring.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Queue System:</strong> Asynchronous processing for batch operations (month-end closing, bulk import).</li>
<li class="text-body-lg text-gosign-text-light"><strong>Event System:</strong> Real-time response to incoming documents, status changes, escalations.</li>
</ul>
</div>
</div>
</section>

<!-- Layer 3: Agent -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">3. Agent Layer</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Specialized AI agents performing domain-specific tasks. Each agent has a defined scope and operates within the boundaries set by the Decision Layer.
</p>
<h3 class="text-h3 font-bold text-gosign-dark mt-8"><a href="/en/services/ai-agents/document-agents/" class="text-gosign-dark hover:text-gosign-accent-text transition-colors">Document Agents</a></h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Read, understand, and process documents with genuine language comprehension. Invoices, medical certificates, contracts, compliance documents, receipts. No template matching, no rigid rules - contextual understanding.
</p>
<h3 class="text-h3 font-bold text-gosign-dark mt-8"><a href="/en/services/ai-agents/workflow-agents/" class="text-gosign-dark hover:text-gosign-accent-text transition-colors">Workflow Agents</a></h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Orchestrate processes across systems. When a document needs to be read, a decision made, and an action triggered in a target system - the Workflow Agent coordinates the sequence.
</p>
<h3 class="text-h3 font-bold text-gosign-dark mt-8"><a href="/en/services/ai-agents/knowledge-agents/" class="text-gosign-dark hover:text-gosign-accent-text transition-colors">Knowledge Agents</a></h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Deliver context-based answers from enterprise knowledge. Governance frameworks, company policies, collective bargaining agreements, compliance rules. Every answer includes the source reference and the rule version.
</p>
</div>
</div>
</section>

<!-- Layer 4: Decision Layer -->
<section class="py-section bg-gosign-dark text-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold"><a href="/en/decision-layer/" class="hover:text-gosign-accent-on-dark transition-colors">4. Decision Layer</a></h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4">
Decomposes every business process into individual decision steps and defines for each step: human, rule engine, or AI. Every decision is documented - auditable for external auditors, employee representation bodies, and internal audit teams.
</p>
<div class="mt-6 space-y-4">
<p class="text-body-lg text-gosign-text-on-dark/80"><strong>Rules Engine:</strong> Versioned, traceable business rule sets. Collective bargaining agreements, company policies, posting logic, compliance rules. Each rule has a version, an effective date, and a scope.</p>
<p class="text-body-lg text-gosign-text-on-dark/80"><strong>Confidence Routing:</strong> Automatic assessment of decision certainty. High confidence and low risk: autonomous decision. Low confidence or high risk: escalation to a human.</p>
<p class="text-body-lg text-gosign-text-on-dark/80"><strong>Human-in-the-Loop:</strong> Architecturally enforced human review for defined decision types. Bias risk, discrimination potential, employee representation requirements.</p>
<p class="text-body-lg text-gosign-text-on-dark/80"><strong>Audit Trail - the decision act:</strong> Complete, immutable documentation of every decision. One decision act per micro-decision: input, model, assessment, rule including version, result, timestamp, and contestation path. Append-only - and thereby the architectural answer to the affected person's right to an explanation of the individual decision under Art. 86 of the EU AI Act.</p>
</div>
<p class="text-body text-gosign-text-on-dark/60 mt-4">
Deep dive: <a href="/en/magazine/decision-layer-explained/" class="text-gosign-text-on-dark/80 underline decoration-white/20 hover:text-white transition-colors">Decision Layer in Detail</a> · <a href="/en/magazine/three-types-of-decisions/" class="text-gosign-text-on-dark/80 underline decoration-white/20 hover:text-white transition-colors">Three Types of AI Decisions</a> · <a href="/en/magazine/decision-act-contestable-ai-decisions/" class="text-gosign-text-on-dark/80 underline decoration-white/20 hover:text-white transition-colors">The Decision Act</a>
</p>
</div>
</div>
</section>

<!-- Layer 5: Model -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">5. Model Layer</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
The LLM layer. Interchangeable, model-agnostic, decoupled from business logic.
</p>
<h3 class="text-h3 font-bold text-gosign-dark mt-6">Cloud LLMs</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Claude (Anthropic), ChatGPT (OpenAI), Gemini (Google) - via EU regions of the respective cloud providers.</p>
<h3 class="text-h3 font-bold text-gosign-dark mt-6">Open-Source / Open-Weight LLMs</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Llama (Meta), Mistral, DeepSeek, <a href="https://openai.com/open-models/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">gpt-oss</a> (OpenAI, Apache 2.0) - fully self-hostable on your own hardware. gpt-oss-120B runs on a single H100 GPU, gpt-oss-20B on 16 GB consumer hardware.</p>
<h3 class="text-h3 font-bold text-gosign-dark mt-6">Hybrid</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Cloud LLMs for standard workloads, self-hosted LLMs for sensitive data. Automatic routing based on data classification.</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Model choice is a trade-off between performance, cost, data residency, and latency. The Model Layer is interchangeable - switching models does not affect the business logic above.
</p>
<p class="text-body text-gosign-text-light mt-4">
Concrete hosting options, hardware requirements, and technology stack: <a href="/en/services/infrastructure/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">AI Infrastructure in Detail</a>
</p>
</div>
</div>
</section>

<!-- PII Gateway: Redaction in Front of the Model Layer -->
<section id="pii-gateway" class="py-section bg-gosign-dark text-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold">The PII Gateway: Redaction in Front of the Model Layer</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4">
Between the business logic and the Model Layer, the architecture provides for a redaction gateway (PII Gateway): every model call - cloud LLM or self-hosted - passes through it. Its design goal: personal data does not leave the operator's trust boundary in plaintext. For professional-secrecy workloads - legal, tax, healthcare - the gateway is one building block of data minimization under GDPR; it complements organizational and contractual safeguards rather than replacing them.
</p>
<div class="mt-6 space-y-4">
<p class="text-body-lg text-gosign-text-on-dark/80"><strong>Redaction and re-insertion:</strong> Before every model call, the gateway replaces names, identifiers, and other personal attributes with placeholders (pseudonymization). The model operates on redacted text only. The original values are re-inserted after the response - inside the trust boundary, never at the model provider.</p>
<p class="text-body-lg text-gosign-text-on-dark/80"><strong>Plaintext-free Audit Trail:</strong> Every model call is logged append-only and hash-chained: hash values of prompt and raw response instead of plaintext, plus model ID, API version, and the version of the redaction rule set. The evidence of what passed through the gateway, and when, remains complete - without the log itself becoming a sensitive data store.</p>
<p class="text-body-lg text-gosign-text-on-dark/80"><strong>Break-glass rules:</strong> Exceptional access for incident response and audits is part of the design - never silent: dual authorization (four-eyes principle), documented justification, time-boxed scope, and every break-glass event is fully recorded in the Audit Trail.</p>
<p class="text-body-lg text-gosign-text-on-dark/80"><strong>User-side low-confidence approval:</strong> When redaction confidence is low for a passage, the decision is escalated to the user in the UI - never to Gosign staff. Escalation stays within the sphere where the data is already known.</p>
</div>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-6">
API modes that cannot be redacted - such as external embedding calls whose vectors cannot be pseudonymized - are blocked for redaction-required content instead of being passed through silently. Mapping tables between placeholders and original values are ephemeral or tenant-encrypted with a defined time-to-live (TTL); provider keys live exclusively in the key management system (KMS).
</p>
<p class="text-body text-gosign-text-on-dark/60 mt-4">
Deep dive: <a href="/en/magazine/pii-anonymization-llm-enterprise/" class="text-gosign-text-on-dark/80 underline decoration-white/20 hover:text-white transition-colors">PII Anonymization for Enterprise AI</a>
</p>
</div>
</div>
</section>

<!-- Layer 6: Integration -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">6. Integration Layer</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Connection to existing enterprise systems. The agent does not replace systems - it extends them.
</p>
<div class="mt-6 overflow-x-auto">
<table class="w-full text-left text-small border-collapse">
<thead>
<tr>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">System Category</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Integration</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">ERP / Finance</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">SAP FI/CO, SAP S/4HANA, DATEV, Oracle Financials</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">HR / Payroll</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">SAP SuccessFactors, Workday, Personio</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Collaboration</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">SharePoint, Microsoft Teams (via Microsoft Graph)</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">DMS / ECM</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">SharePoint, d.velop, ELO, nscale</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Other</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Any system with a REST or SOAP interface</td></tr>
</tbody>
</table>
</div>
<p class="text-body-lg text-gosign-text-light mt-4">
Agent logic is decoupled from the target system. Posting logic is separated from export. When the target system changes (e.g. from DATEV to SAP), the export layer changes - not the agent.
</p>
</div>
</div>
</section>

<!-- Layer 7: Infrastructure -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">7. Infrastructure Layer</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
The deployment foundation. The entire architecture runs in the client's infrastructure - not at Gosign, not at a third-party provider.
</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light"><strong>Cloud (EU):</strong> Azure, AWS, or GCP - EU regions exclusively. Managed Kubernetes, managed databases, LLM hosting. (US: US-region deployment available for organizations without EU data residency requirements.)</li>
<li class="text-body-lg text-gosign-text-light"><strong>Managed EU:</strong> Vercel EU + Supabase EU. Lightweight EU option without dedicated Kubernetes infrastructure.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Self-Hosted:</strong> Own servers, own data center. Docker/Kubernetes, open-source LLMs on your own GPUs. Complete Cloud Act independence.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Hybrid:</strong> Combination based on data classification. Sensitive workloads self-hosted, standard workloads in the cloud.</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-4">
All layers above Infrastructure remain identical - regardless of deployment model.
</p>
<p class="text-body text-gosign-text-light mt-4">
Cloud regions, hardware sizing, technology stack: <a href="/en/services/infrastructure/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">AI Infrastructure in Detail</a>
</p>
</div>
</div>
</section>

<!-- Governance as Cross-Cutting Concern -->
<section class="py-section bg-gosign-dark text-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold">Governance as Cross-Cutting Concern</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4">
Governance is not a single layer - it spans the entire architecture. Every layer produces governance data, and every layer is controlled by governance rules.
</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-on-dark/80"><strong>Presentation:</strong> Role-based access, Auditor Portal</li>
<li class="text-body-lg text-gosign-text-on-dark/80"><strong>Orchestration:</strong> Workflow logging, escalation documentation</li>
<li class="text-body-lg text-gosign-text-on-dark/80"><strong>Agent:</strong> Agent decisions generate Audit Trail entries</li>
<li class="text-body-lg text-gosign-text-on-dark/80"><strong>Decision Layer:</strong> Rules Engine, Confidence Routing, Human-in-the-Loop</li>
<li class="text-body-lg text-gosign-text-on-dark/80"><strong>Model:</strong> Model version tracking, input hashing, reproducibility, PII redaction and plaintext-free logging (PII Gateway)</li>
<li class="text-body-lg text-gosign-text-on-dark/80"><strong>Integration:</strong> Interface logging, data flow documentation</li>
<li class="text-body-lg text-gosign-text-on-dark/80"><strong>Infrastructure:</strong> Encryption, Row-Level Security, tenant isolation</li>
</ul>
<p class="text-body text-gosign-text-on-dark/60 mt-6">
<a href="/en/governance/eu-ai-act/" class="text-gosign-text-on-dark/80 underline decoration-white/20 hover:text-white transition-colors">EU AI Act</a> · <a href="/en/governance/cert-ready/" class="text-gosign-text-on-dark/80 underline decoration-white/20 hover:text-white transition-colors">Cert-Ready by Design</a> · <a href="/en/governance/co-determination/" class="text-gosign-text-on-dark/80 underline decoration-white/20 hover:text-white transition-colors">Co-Determination</a> · <a href="/en/governance/data-residency/" class="text-gosign-text-on-dark/80 underline decoration-white/20 hover:text-white transition-colors">Data Residency</a>
</p>
</div>
</div>
</section>

<!-- Runtime & Scaling -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Runtime and Scaling</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Production operation is not an afterthought - it is an architectural component. The 7-layer architecture is designed for operation under load.
</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light"><strong>Container Orchestration:</strong> Kubernetes-based deployment. Each layer runs in its own containers, independently scalable.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Horizontal Scaling:</strong> Agent Layer and Model Layer scale horizontally based on utilization. A new agent means more pods, not more architecture.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Health Checks and Self-Healing:</strong> Liveness and readiness probes on all containers. Automatic restart on failure, automatic rerouting under overload.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Monitoring and Alerting:</strong> Prometheus metrics across all layers. Grafana dashboards for latency, throughput, error rates, queue depth. Alerting on threshold violations.</li>
<li class="text-body-lg text-gosign-text-light"><strong>CI/CD:</strong> GitOps-based deployments. Infrastructure as Code (Terraform/Pulumi). Automated tests, blue-green or canary deployments.</li>
</ul>
</div>
</div>
</section>

<!-- Data Architecture -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Data Architecture</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Data flows through all seven layers. The architecture defines where data originates, how it is stored, and who has access.
</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light"><strong>Data Flow:</strong> Input (document, query) &gt; Agent (analysis) &gt; Decision Layer (decision) &gt; Integration (target system export). Every step generates an Audit Trail entry.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Vector Store:</strong> PostgreSQL with pgvector for semantic search (RAG). Enterprise knowledge is stored as embeddings - never transmitted to external services.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Tenant Isolation:</strong> Row-Level Security (RLS) at the database level. Enforced architecturally, not through application logic alone. Each tenant is fully isolated.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Encryption:</strong> At rest (AES-256) and in transit (TLS 1.3). Key management via the client's identity provider or Hardware Security Modules (HSM).</li>
<li class="text-body-lg text-gosign-text-light"><strong>Data Retention:</strong> Configurable per requirement. Regulatory retention periods and GDPR Art. 17 (right to erasure) are reconciled through anonymization rather than deletion.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Backup and Recovery:</strong> Automated backups, point-in-time recovery. Recovery Point Objective (RPO) and Recovery Time Objective (RTO) are configured per tenant.</li>
</ul>
</div>
</div>
</section>

<!-- Interface Architecture -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Interface Architecture</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
The architecture communicates through defined interfaces - internally between layers and externally with source and target systems.
</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light"><strong>REST API:</strong> Versioned APIs (v1, v2) with OpenAPI documentation. Breaking changes only in new versions; legacy versions are operated in parallel.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Event-Driven:</strong> Webhook-based event processing for real-time responses. Incoming document &gt; event &gt; agent processes. No polling, no batch delay.</li>
<li class="text-body-lg text-gosign-text-light"><strong>MCP (Model Context Protocol):</strong> Standardized protocol for tool integration in LLM agents. Agents access external tools via MCP - typed, documented, auditable.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Batch Processing:</strong> For bulk operations (month-end closing, annual accounts, mass import). Queue-based with progress tracking and error handling.</li>
<li class="text-body-lg text-gosign-text-light"><strong>API Gateway:</strong> Central entry point. Authentication (SSO/OIDC), rate limiting, request logging, monitoring. Decouples internal architecture from external consumers.</li>
</ul>
</div>
</div>
</section>

<!-- Design Principles -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Design Principles</h2>
<div class="mt-6 space-y-4">
<p class="text-body-lg text-gosign-text-light"><strong>Model-agnostic:</strong> No vendor lock-in to a single LLM. Models are interchangeable. Claude today, gpt-oss tomorrow, a model that does not exist yet the day after.</p>
<p class="text-body-lg text-gosign-text-light"><strong>Infrastructure-agnostic:</strong> Same architecture on Azure, AWS, GCP, self-hosted, or hybrid. The infrastructure choice belongs to the client, not to the architecture.</p>
<p class="text-body-lg text-gosign-text-light"><strong>System-agnostic:</strong> Agent logic is decoupled from the target system. Posting logic separated from export. A system migration changes the Integration Layer, not the agent.</p>
<p class="text-body-lg text-gosign-text-light"><strong>Governance by Design:</strong> Audit Trail, RBAC, Decision Layer, and Human-in-the-Loop are architectural components - not optional features retrofitted after launch.</p>
<p class="text-body-lg text-gosign-text-light"><strong>Cert-Ready by Design:</strong> Controls are first-class data objects with automatic evidence generation. ISO 27001, SOC 2, EU AI Act - the architecture produces the audit evidence. (US: Aligned with NIST AI RMF and SOC 2 Type II requirements.)</p>
<p class="text-body-lg text-gosign-text-light"><strong>Source Code Access:</strong> Full access to source code, all prompts, and all rule sets. Configurations and rule sets remain with the client. Open-source stack where possible. After 12-18 months, the client operates the agents independently.</p>
</div>
</div>
</div>
</section>

<!-- Decision Layer - Decision Flow -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-6">Decision Layer - Decision Flow</h2>
<figure role="img" aria-label="Decision flow: Input is analyzed by the AI Agent, the Decision Layer checks rules and confidence, routes to autonomous decision or Human-in-the-Loop, documents everything in the Audit Trail, and exports to the target system.">
<pre class="bg-gosign-dark text-white p-6 rounded-card overflow-x-auto text-small font-mono leading-relaxed"><code>&#x250C;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2510;    &#x250C;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2510;    &#x250C;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2510;
&#x2502;  Input   &#x2502;&#x2500;&#x2500;&#x2500;&gt;&#x2502;  AI Agent    &#x2502;&#x2500;&#x2500;&#x2500;&gt;&#x2502; Decision Layer &#x2502;
&#x2502;(document,&#x2502;    &#x2502;  analyzes,   &#x2502;    &#x2502;                &#x2502;
&#x2502; query)   &#x2502;    &#x2502;  understands,&#x2502;    &#x2502;  Check rules   &#x2502;
&#x2514;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2518;    &#x2502;  evaluates   &#x2502;    &#x2502;                &#x2502;
&#x2514;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2518;    &#x2502;  Assess        &#x2502;
&#x2502;  confidence    &#x2502;
&#x2502;                &#x2502;
&#x2502;  Route         &#x2502;
&#x2502;  decision      &#x2502;
&#x2514;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x252C;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2518;
&#x2502;
&#x250C;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2534;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2510;
&#x2502;                            &#x2502;
&#x250C;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2534;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2510;        &#x250C;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2534;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2510;
&#x2502; Autonomous      &#x2502;        &#x2502; Human-in-the-Loop   &#x2502;
&#x2502;                 &#x2502;        &#x2502;                     &#x2502;
&#x2502; High confidence &#x2502;        &#x2502; Bias risk           &#x2502;
&#x2502; Low risk        &#x2502;        &#x2502; Low confidence      &#x2502;
&#x2502; No governance   &#x2502;        &#x2502; Governance          &#x2502;
&#x2502; constraint      &#x2502;        &#x2502; constraint active   &#x2502;
&#x2514;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x252C;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2518;        &#x2514;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x252C;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2518;
&#x2502;                            &#x2502;
&#x2502;         &#x250C;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2510;   &#x2502;
&#x2502;         &#x2502;  Human       &#x2502;   &#x2502;
&#x2502;         &#x2502;  decides     &#x2502;&#x25C4;&#x2500;&#x2500;&#x2518;
&#x2502;         &#x2514;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x252C;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2518;
&#x2502;                &#x2502;
&#x250C;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2534;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2534;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2510;
&#x2502;         Audit Trail              &#x2502;
&#x2502;  Input · Model · Rule ·          &#x2502;
&#x2502;  Assessment · Result ·           &#x2502;
&#x2502;  Timestamp                       &#x2502;
&#x2514;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2518;
&#x2502;
&#x250C;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2534;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2510;
&#x2502;  Target System  &#x2502;
&#x2502;  (ERP, HR,      &#x2502;
&#x2502;   Payroll)      &#x2502;
&#x2514;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2518;</code></pre>
<figcaption class="text-small text-gosign-text-light mt-3">Schematic decision flow through the Decision Layer. In production, every step is documented as an Audit Trail entry.</figcaption>
</figure>
</div>
</section>

<!-- Deep Dives -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Deep Dives</h2>
<div class="mt-6 grid gap-6 sm:grid-cols-2">
<div class="border-l-4 border-gosign-dark pl-6 py-4">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Implementation</p>
<h3 class="text-h3 font-bold text-gosign-dark">AI Infrastructure</h3>
<p class="text-body text-gosign-text-light mt-2">Concrete technologies, cloud regions, hardware sizing, full tech stack breakdown.</p>
<a href="/en/services/infrastructure/" class="text-small font-semibold text-gosign-accent-text hover:text-gosign-accent-hover mt-3 inline-block whitespace-nowrap">Infrastructure in Detail &gt;</a>
</div>
<div class="border-l-4 border-gosign-dark pl-6 py-4">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Knowledge Resource</p>
<h3 class="text-h3 font-bold text-gosign-dark">Blueprint 2026</h3>
<p class="text-body text-gosign-text-light mt-2">Eleven in-depth articles on the infrastructure decisions that matter in 2026.</p>
<a href="/en/magazine/ai-infrastructure-blueprint-2026/" class="text-small font-semibold text-gosign-accent-text hover:text-gosign-accent-hover mt-3 inline-block whitespace-nowrap">Read the Series &gt;</a>
</div>
<div class="border-l-4 border-gosign-dark pl-6 py-4">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Agents</p>
<h3 class="text-h3 font-bold text-gosign-dark">AI Agents Overview</h3>
<p class="text-body text-gosign-text-light mt-2">Document Agents, Workflow Agents, Knowledge Agents - three agent types for enterprise processes.</p>
<a href="/en/services/ai-agents/" class="text-small font-semibold text-gosign-accent-text hover:text-gosign-accent-hover mt-3 inline-block whitespace-nowrap">Explore AI Agents &gt;</a>
</div>
<div class="border-l-4 border-gosign-dark pl-6 py-4">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<h3 class="text-h3 font-bold text-gosign-dark">Governance Framework</h3>
<p class="text-body text-gosign-text-light mt-2">EU AI Act, Cert-Ready, Co-Determination, Data Residency - all governance topics at a glance.</p>
<a href="/en/governance/" class="text-small font-semibold text-gosign-accent-text hover:text-gosign-accent-hover mt-3 inline-block whitespace-nowrap">Governance Overview &gt;</a>
</div>
</div>
</div>
</div>
</section>

<!-- Deep Dive -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Deep Dive in the Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Our article series for decision-makers implementing AI agents in the enterprise.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/en/magazine/ai-infrastructure-blueprint-2026/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">Enterprise AI Infrastructure Blueprint 2026</p>
</a>
<a href="/en/magazine/decision-layer-explained/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - What It Is and Why Every Enterprise AI Agent Needs One</p>
</a>
<a href="/en/magazine/agent-orchestration-platforms/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">Agent Orchestration: Trigger.dev, n8n, Camunda, and Alternatives</p>
</a>
</div>
</div>
</section>

--- Governance, Security & Audit ---
> How Gosign makes AI agents auditable, audit-ready, and compliant with employee representation requirements. Governance by Design as an architectural principle.

<!-- Governance by Design -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Governance by Design</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Gosign builds AI agents for enterprise environments. These environments have requirements for traceability, auditability, and control that go beyond what a standard LLM deployment provides.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Governance by Design means: every agent is built from the ground up with the mechanisms that auditors, employee representation bodies, and compliance teams expect. This is not an optional layer added after the fact. It is an architectural principle.
</p>
<p class="text-body text-gosign-text-light mt-4">
What the EU AI Act specifically requires and how enterprises can achieve high-risk compliance by the deadline (2 August 2026 under current law, provisionally set to move to 2 December 2027 under the Digital Omnibus of 7 May 2026, formal adoption still pending) is covered in our
<a href="/en/magazine/eu-ai-act-2026-enterprises/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">EU AI Act Guide</a>.
</p>
</div>
</div>
</section>

<!-- Five Governance Dimensions -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Five Governance Dimensions</h2>

<div class="mt-8 space-y-10">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">1. Audit Trail & Traceability</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Every AI agent decision generates a complete, immutable decision act: input (document, query, data point), model and model version, professional assessment and confidence score, applied rule with rule version, decision path (autonomous or Human-in-the-Loop), result, timestamp, and contestation path. It is the architectural answer to the affected person's right to an explanation of the individual decision under <a href="/en/magazine/decision-act-contestable-ai-decisions/" class="text-gosign-accent-text hover:underline">Art. 86 of the EU AI Act</a>.
</p>
<p class="text-body-lg text-gosign-text-light mt-2">
The audit trail is immutable, exportable, and machine-readable. Auditors can trace every agent decision from input to outcome.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark">2. <a href="/en/decision-layer/" class="hover:text-gosign-accent transition-colors">Decision Layer</a></h3>
<p class="text-body-lg text-gosign-text-light mt-2">
The <a href="/en/decision-layer/" class="text-gosign-accent-text hover:underline">Decision Layer</a> is the architectural layer between AI agent and target system. It makes every LLM decision transparent, auditable, and traceable. The agent analyzes, understands, and evaluates. The Decision Layer documents the decision path and controls routing:
</p>
<p class="text-body-lg text-gosign-text-light mt-2">
<strong class="text-gosign-dark">Autonomous decision:</strong> Where the model can decide securely and in compliance with rules.
</p>
<p class="text-body-lg text-gosign-text-light mt-2">
<strong class="text-gosign-dark">Human-in-the-Loop:</strong> Where bias risk, discrimination potential, or co-determination issues exist - architecturally enforced, not optional.
</p>
<p class="text-body-lg text-gosign-text-light mt-2">
Every human override is documented. Every rule version is assigned. Every decision is reproducible.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark">3. Cert-Ready by Design</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Controls are first-class data objects in the system - not documents in a folder. Every control has: technical implementation (RLS policy, trigger, API check), automatic evidence generator, evidence history with timestamp, status, version, auditor view with drill-down to the concrete implementation.
</p>
<p class="text-body-lg text-gosign-text-light mt-2">
The system proves itself. Auditors see the live status in the Auditor Portal.
</p>
<p class="mt-4">
<a href="/en/governance/cert-ready/" class="text-gosign-accent-text font-semibold hover:text-gosign-accent-hover">Cert-Ready by Design &rarr;</a>
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark">4. Employee Oversight & Co-determination</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
AI agents in enterprise environments require oversight by employee representation bodies. Built for the most demanding standard globally - German co-determination law - the Gosign architecture addresses this as a design principle: governance frameworks (collective agreements, works agreements, or company policies) as explicit constraints in the Decision Layer. Employee representatives can trace what the agent does, why, and when a human intervenes. Templates, logging, role concepts, and audit trail are part of the architecture.
</p>
<p class="mt-4">
<a href="/en/governance/co-determination/" class="text-gosign-accent-text font-semibold hover:text-gosign-accent-hover">Employee Oversight & Co-determination &rarr;</a>
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark">5. EU AI Act</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
The Gosign architecture addresses the central requirements of the EU AI Act as a design principle: Transparency (Art. 13) - Decision Layer documents every decision path. Human oversight (Art. 14) - Human-in-the-Loop architecturally enforced. Record-keeping (Art. 12) - complete audit trail with timestamps, input hashes, model versions. Risk management (Art. 9) - Governance layer with bias monitoring, confidence tracking, anomaly detection.
</p>
<p class="mt-4">
<a href="/en/governance/eu-ai-act/" class="text-gosign-accent-text font-semibold hover:text-gosign-accent-hover">EU AI Act Readiness &rarr;</a>
</p>
</div>
</div>
</div>
</div>
</section>

<!-- Architecture Overview -->
<section class="py-section bg-gosign-dark text-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold mb-6">Architecture Overview</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mb-6">
The governance layer is not a separate component. It spans all layers of the agent architecture:
</p>
<pre class="bg-gosign-dark border border-white/10 text-white font-mono text-sm p-6 rounded-card overflow-x-auto leading-relaxed">┌─────────────────────────────────────────────────┐
│  Presentation Layer    Chat UI, Dashboard, API  │
├─────────────────────────────────────────────────┤
│  Orchestration Layer   Trigger.dev/Camunda, API GW      │
├─────────────────────────────────────────────────┤
│  Agent Layer           Document, Workflow,       │
│                        Knowledge Agents          │
├─────────────────────┬───────────────────────────┤
│  GOVERNANCE LAYER   │ Audit Trail, RBAC,        │
│  (Cross-cutting)    │ Decision Layer,           │
│                     │ Cert-Ready Controls       │
├─────────────────────┴───────────────────────────┤
│  Model Layer           Claude, ChatGPT, Llama,  │
│                        Mistral, DeepSeek        │
├─────────────────────────────────────────────────┤
│  Integration Layer     SAP, DATEV, MS Graph     │
├─────────────────────────────────────────────────┤
│  Infrastructure Layer  Azure, GCP, AWS, Self-Hosted  │
└─────────────────────────────────────────────────┘</pre>
<p class="mt-6">
<a href="/en/governance/reference-architecture/" class="inline-flex items-center text-body-lg font-semibold text-gosign-accent-on-dark hover:text-gosign-accent-on-dark transition-colors">
View Full Reference Architecture
<svg class="w-5 h-5 ml-2" fill="none" stroke="currentColor" viewBox="0 0 24 24">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" />
</svg>
</a>
</p>
</div>
</section>

<!-- Six Governance Dimensions -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">Six Governance Dimensions</h2>
<div class="grid grid-cols-1 lg:grid-cols-3 gap-6 lg:gap-8">
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75L11.25 15 15 9.75m-3-7.036A11.959 11.959 0 013.598 6 11.99 11.99 0 003 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Cert-Ready by Design</h3>
<p class="text-body text-gosign-text-light mt-3">Controls as data objects, evidence automated, auditor portal live. Certification readiness is not a project but an architectural state.</p>
<a href="/en/governance/cert-ready/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
View Cert-Ready Controls
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M18 18.72a9.094 9.094 0 003.741-.479 3 3 0 00-4.682-2.72m.94 3.198l.001.031c0 .225-.012.447-.037.666A11.944 11.944 0 0112 21c-2.17 0-4.207-.576-5.963-1.584A6.062 6.062 0 016 18.719m12 0a5.971 5.971 0 00-.941-3.197m0 0A5.995 5.995 0 0012 12.75a5.995 5.995 0 00-5.058 2.772m0 0a3 3 0 00-4.681 2.72 8.986 8.986 0 003.74.477m.94-3.197a5.971 5.971 0 00-.94 3.197M15 6.75a3 3 0 11-6 0 3 3 0 016 0zm6 3a2.25 2.25 0 11-4.5 0 2.25 2.25 0 014.5 0zm-13.5 0a2.25 2.25 0 11-4.5 0 2.25 2.25 0 014.5 0z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Employee Oversight</h3>
<p class="text-body text-gosign-text-light mt-3">Governance frameworks - collective agreements, works agreements, or company policies - as constraints. Human-in-the-Loop for employee oversight decisions. Technically enforced, not just organizationally agreed.</p>
<a href="/en/governance/co-determination/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
View Employee Oversight
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 3v17.25m0 0c-1.472 0-2.882.265-4.185.75M12 20.25c1.472 0 2.882.265 4.185.75M18.75 4.97A48.416 48.416 0 0012 4.5c-2.291 0-4.545.16-6.75.47m13.5 0c1.01.143 2.01.317 3 .52m-3-.52l2.62 10.726c.122.499-.106 1.028-.589 1.202a5.988 5.988 0 01-2.031.352 5.988 5.988 0 01-2.031-.352c-.483-.174-.711-.703-.59-1.202L18.75 4.971zm-16.5.52c.99-.203 1.99-.377 3-.52m0 0l2.62 10.726c.122.499-.106 1.028-.589 1.202a5.989 5.989 0 01-2.031.352 5.989 5.989 0 01-2.031-.352c-.483-.174-.711-.703-.59-1.202L5.25 4.971z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">EU AI Act</h3>
<p class="text-body text-gosign-text-light mt-3">EU AI Act compliant by design. Architecture mapping to Art. 9-14 and the right to an explanation of the individual decision (Art. 86). Transparency, explainability and human oversight as fundamental architecture.</p>
<a href="/en/governance/eu-ai-act/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
EU AI Act Readiness
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M21 7.5l-2.25-1.313M21 7.5v2.25m0-2.25l-2.25 1.313M3 7.5l2.25-1.313M3 7.5l2.25 1.313M3 7.5v2.25m9 3l2.25-1.313M12 12.75l-2.25-1.313M12 12.75V15m0 6.75l2.25-1.313M12 21.75V19.5m0 2.25l-2.25-1.313m0-16.875L12 2.25l2.25 1.313M21 14.25v2.25l-2.25 1.313m-13.5 0L3 16.5v-2.25" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Reference Architecture</h3>
<p class="text-body text-gosign-text-light mt-3">7-Layer Enterprise AI Architecture. Governance as cross-cutting concern. Presentation, Orchestration, Agent, Governance, Model, Integration, Infrastructure.</p>
<a href="/en/governance/reference-architecture/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
View Architecture
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M16.5 10.5V6.75a4.5 4.5 0 10-9 0v3.75m-.75 11.25h10.5a2.25 2.25 0 002.25-2.25v-6.75a2.25 2.25 0 00-2.25-2.25H6.75a2.25 2.25 0 00-2.25 2.25v6.75a2.25 2.25 0 002.25 2.25z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Data Residency & GDPR</h3>
<p class="text-body text-gosign-text-light mt-3">All data remains in the client's infrastructure. EU-only processing, Row-Level Security, tenant isolation, complete data sovereignty.</p>
<a href="/en/governance/data-residency/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
View Data Residency
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12h3.75M9 15h3.75M9 18h3.75m3 .75H18a2.25 2.25 0 002.25-2.25V6.108c0-1.135-.845-2.098-1.976-2.192a48.424 48.424 0 00-1.123-.08m-5.801 0c-.065.21-.1.433-.1.664 0 .414.336.75.75.75h4.5a.75.75 0 00.75-.75 2.25 2.25 0 00-.1-.664m-5.8 0A2.251 2.251 0 0113.5 2.25H15a2.25 2.25 0 012.15 1.586m-5.8 0c-.376.023-.75.05-1.124.08C9.095 4.01 8.25 4.973 8.25 6.108V8.25m0 0H4.875c-.621 0-1.125.504-1.125 1.125v11.25c0 .621.504 1.125 1.125 1.125h9.75c.621 0 1.125-.504 1.125-1.125V9.375c0-.621-.504-1.125-1.125-1.125H8.25zM6.75 12h.008v.008H6.75V12zm0 3h.008v.008H6.75V15zm0 3h.008v.008H6.75V18z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">DPA for AI Infrastructure</h3>
<p class="text-body text-gosign-text-light mt-3">Why standard Data Processing Agreements fall short for enterprise AI. Requirements checklist with 25 verification questions for legal, IT security, and employee representatives.</p>
<a href="/en/governance/dpa-checklist/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
DPA Checklist
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</article>
</div>
</div>
</section>

<!-- Closing -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Governance Applies to Every Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Governance by Design is not a feature of a single product. It is an architectural principle that applies to every AI agent Gosign builds - whether HR Agent, Finance Agent, Document Agent, or Knowledge Agent.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Same governance. Same auditability. Same infrastructure.
</p>
</div>
</div>
</section>

<!-- Deep Dive in the Agent Briefing -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">Deep Dive in the Agent Briefing (Gosign Magazine)</h2>
<div class="grid md:grid-cols-3 gap-6">
<a href="/en/magazine/decision-layer-shadow-ai/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<h3 class="text-h3 font-bold text-gosign-dark">Decision Layer & Shadow AI</h3>
</a>
<a href="/en/magazine/eu-ai-act-2026-enterprises/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<h3 class="text-h3 font-bold text-gosign-dark">EU AI Act 2026</h3>
</a>
<a href="/en/magazine/ai-infrastructure-blueprint-2026/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Infrastructure</p>
<h3 class="text-h3 font-bold text-gosign-dark">AI Infrastructure Blueprint 2026</h3>
</a>
</div>
</div>
</section>

<!-- FAQ -->

--- Enterprise AI Agents - In Your Infrastructure. Under Your Control. ---
> Enterprise AI Agent Infrastructure for HR, Finance, and IT. Auditable LLM decisions, Governance by Design, model-agnostic.

<!-- Enterprise AI Infrastructure & Agent Engineering -->
<section class="scroll-reveal py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex flex-col lg:flex-row lg:items-start lg:gap-12">
<div class="lg:w-[55%]">
<h2 class="text-h1 font-bold text-gosign-dark">
Enterprise AI Infrastructure & Agent Engineering
</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Gosign is an Enterprise AI Infrastructure & Agent Engineering Company. We develop and operate the infrastructure that makes AI Agents production-ready in enterprises: orchestration, governance, <a href="/en/decision-layer/" class="text-gosign-accent-text hover:underline">Decision Layer</a>, and audit.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
25 years of software engineering. 108 employees. Over 5,000 projects for e.g. Airbus, Volkswagen, Shell. Since 2023 focused on Enterprise AI Agent Engineering.
</p>
</div>
<div class="lg:w-[45%] mt-8 lg:mt-0 flex justify-center">
<img
src="/images/7-layer-architecture-v2.svg"
alt="Gosign 7-layer architecture for Enterprise AI: Presentation Layer (Chat UI, Dashboard, API), Orchestration Layer (Trigger.dev, Camunda), Agent Layer (Document, Workflow, Knowledge Agents), Governance Layer as cross-cutting concern (Audit Trail, RBAC, Decision Layer, Cert-Ready Controls), Model Layer (Claude, GPT, Gemini, Llama, Mistral, DeepSeek - model-agnostic), Integration Layer (SAP, DATEV, Microsoft Graph), Infrastructure Layer (Azure EU, GCP EU, AWS EU, Self-Hosted, Hybrid)"
width="500"
height="400"
class="w-full max-w-md"
loading="lazy"
/>
</div>
</div>
</div>
</section>

<!-- Why Most AI Projects Don't Deliver Measurable Results -->
<section class="scroll-reveal py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Why Most AI Projects Don't Deliver Measurable Results</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Most enterprises are already using AI. Very few achieve measurable results. Not because the technology doesn't work - but because nobody has defined which decisions AI may make and which must stay with humans.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Industry experience shows: For every euro invested in technology, you need four to five euros in processes, governance, and change management. Investing only in technology means investing past the problem.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
The <a href="/en/decision-layer/" class="text-gosign-accent-text hover:underline font-semibold">Decision Layer</a> is the layer that makes the difference: It decomposes every business process into individual decision steps and defines for each - human, rule set, or AI. That's how an AI experiment becomes a production system.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
The EU AI Act (UK: UK AI regulatory framework) high-risk classification for AI systems in employment and financial services stands. Under current law the obligations apply from 2 August 2026, but following the provisional Digital Omnibus agreement of 7 May 2026 they are set to be postponed to 2 December 2027 (formal adoption still pending, as of June 2026). The classification is not changing, so the time should be used to build auditable governance infrastructure now.
</p>
</div>
</div>
</section>

<!-- AI Agents for Your Department -->
<section class="scroll-reveal py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">AI Agents for Your Department</h2>
<div class="grid grid-cols-1 gap-6 lg:gap-8 lg:grid-cols-3">
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 hover:shadow-lg hover:-translate-y-0.5 transition-all duration-200">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<img src="/images/icon-finance.svg" alt="" class="w-10 h-10" width="40" height="40" />
</div>
<h3 class="text-h3 font-bold text-gosign-dark">AI Agents for Finance & Accounting</h3>
<p class="text-body text-gosign-text-light mt-3">Decision automation for document processing, posting and audit preparation. Versioned rulesets, complete audit trail, Cert-Ready by Design. The Decision Layer makes every posting decision traceable.</p>
<a href="/en/finance-ai-agents/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
Finance AI Agents
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 hover:shadow-lg hover:-translate-y-0.5 transition-all duration-200">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<img src="/images/icon-hr.svg" alt="" class="w-10 h-10" width="40" height="40" />
</div>
<h3 class="text-h3 font-bold text-gosign-dark">AI Agents for HR & People Operations</h3>
<p class="text-body text-gosign-text-light mt-3">Auditable AI Agents for HR decisions. Compliant with employee representation requirements. Decision Layer with Human-in-the-Loop. Payroll, Onboarding, Document Processing, Compensation & Merit, Policy & Knowledge.</p>
<a href="/en/hr-ai-agents/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
HR AI Agents
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 hover:shadow-lg hover:-translate-y-0.5 transition-all duration-200">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<img src="/images/icon-infrastructure.svg" alt="" class="w-10 h-10" width="40" height="40" />
</div>
<h3 class="text-h3 font-bold text-gosign-dark">AI Infrastructure for IT & Enterprise</h3>
<p class="text-body text-gosign-text-light mt-3">LLM hosting, RAG, orchestration. Self-hosted, cloud, or hybrid. Model-agnostic, Governance by Design, Cert-Ready by Design. The platform your agents run on in production.</p>
<a href="/en/services/infrastructure/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
Infrastructure
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</article>
</div>
</div>
</section>

<!-- Three Agent Types -->
<section class="scroll-reveal py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 space-y-12">
<h2 class="text-h1 font-bold text-gosign-dark">Specialized Agents for Enterprise Processes</h2>
<article class="flex flex-col lg:flex-row gap-8 lg:gap-12 items-start">
<div class="flex-shrink-0 w-16 h-16 lg:w-20 lg:h-20 rounded-full bg-gosign-accent/10 flex items-center justify-center">
<span class="text-h1 lg:text-hero font-bold text-gosign-accent-text">01</span>
</div>
<div class="flex-1 lg:w-[55%]">
<h3 class="text-h2 font-bold text-gosign-dark">Document Agents</h3>
<p class="text-body-lg text-gosign-text-light mt-3">The specialist: understands documents. A medical leave certificate arrives. The agent identifies the document type, extracts name, period, and diagnosis code, checks whether all required fields are present, and assigns the document to the correct employee. In Finance: The Document Agent reads an incoming invoice, extracts invoice number, amount, and service period, and validates against mandatory field requirements. Result: a structured data set with a posting proposal. Not template matching - real language comprehension. The Decision Layer evaluates every extraction: deterministic? Rule set. Confident enough? Agent decides independently. Discretion needed? Human reviews.</p>
<a href="/en/services/ai-agents/document-agents/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
Document Agents in Detail
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</div>
<div class="lg:w-[40%] mt-4 lg:mt-11">
<img src="/images/flow-document-agent-v10-en.svg" alt="Document Agent - The Specialist: One document arrives, the agent understands type, content, and context, Decision Layer routes through three tiers (rule set, AI autonomy, human review), structured data comes out." class="w-full" width="480" height="620" loading="lazy" />
</div>
</article>
<article class="flex flex-col lg:flex-row gap-8 lg:gap-12 items-start">
<div class="flex-shrink-0 w-16 h-16 lg:w-20 lg:h-20 rounded-full bg-gosign-accent/10 flex items-center justify-center">
<span class="text-h1 lg:text-hero font-bold text-gosign-accent-text">02</span>
</div>
<div class="flex-1 lg:w-[55%]">
<h3 class="text-h2 font-bold text-gosign-dark">Workflow Agents</h3>
<p class="text-body-lg text-gosign-text-light mt-3">The coordinator: steers the entire process. The medical leave certificate is understood - now what? The Workflow Agent takes over: checks the HR system whether this is the third notification in six months, verifies against the collective agreement whether the return-to-work threshold has been reached, creates a task for the HR manager in SAP SuccessFactors, notifies employee representatives, and schedules a follow-up. Five systems, three decision points, one agent coordinating the entire process - including independent routing decisions where confidence is sufficient. Every step in the audit trail.</p>
<a href="/en/services/ai-agents/workflow-agents/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
Workflow Agents in Detail
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</div>
<div class="lg:w-[40%] mt-4 lg:mt-11">
<img src="/images/flow-workflow-agent-v10-en.svg" alt="Workflow Agent - The Coordinator: Steers a multi-step process across systems. Calls Document Agents, checks against rule sets, creates tasks in SAP, notifies representatives, schedules follow-ups. Every step in the audit trail." class="w-full" width="480" height="542" loading="lazy" />
</div>
</article>
<article class="flex flex-col lg:flex-row gap-8 lg:gap-12 items-start">
<div class="flex-shrink-0 w-16 h-16 lg:w-20 lg:h-20 rounded-full bg-gosign-accent/10 flex items-center justify-center">
<span class="text-h1 lg:text-hero font-bold text-gosign-accent-text">03</span>
</div>
<div class="flex-1 lg:w-[55%]">
<h3 class="text-h2 font-bold text-gosign-dark">Knowledge Agents</h3>
<p class="text-body-lg text-gosign-text-light mt-3">The knowledge carrier: answers questions from enterprise knowledge. An HR manager asks: 'When does a return-to-work process need to be initiated after extended leave?' The agent doesn't just search - it interprets company policies, collective agreements, and regulatory requirements in the context of the question, delivering a specific answer with source reference, rule version, and validity date. When uncertain, it flags uncertainty explicitly. Without a verified source, the agent does not answer - no hallucination.</p>
<a href="/en/services/ai-agents/knowledge-agents/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
Knowledge Agents in Detail
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</div>
<div class="lg:w-[40%] mt-4 lg:mt-11">
<img src="/images/flow-knowledge-agent-v10-en.svg" alt="Knowledge Agent - The Knowledge Carrier: Question with context in, agent interprets verified sources, specific answer with source and version out. Uncertain: flags it. No source: no answer." class="w-full" width="480" height="628" loading="lazy" />
</div>
</article>
</div>
</section>

<!-- Architecture Comparison -->
<section class="scroll-reveal py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Architecture Comparison: Copilot, SaaS Agent, Gosign</h2>
<p class="text-body-lg text-gosign-text-light mb-8">Three approaches to enterprise AI - different architectures, different consequences.</p>
<div class="overflow-x-auto -mx-4 sm:mx-0">
<table class="w-full min-w-[36rem] border-collapse text-small">
<thead>
<tr>
<th class="px-4 py-3 text-left font-semibold bg-gosign-dark text-white">Dimension</th>
<th class="px-4 py-3 text-left font-semibold bg-gosign-dark text-white border-t-[3px] border-t-gosign-accent">Gosign Agent Architecture</th>
<th class="px-4 py-3 text-left font-semibold bg-gosign-dark text-white">Microsoft Copilot</th>
<th class="px-4 py-3 text-left font-semibold bg-gosign-dark text-white">SaaS AI Agent</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Decision Depth</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border bg-gosign-accent/5">Domain decisions with Decision Layer</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Assistance and suggestions</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Preconfigured workflows</td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Auditability</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border bg-gosign-accent/5">Complete audit trail down to SQL level</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Basic logging</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Platform logging</td>
</tr>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Source Code Access</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border bg-gosign-accent/5">Full source code access · Configurations remain with client · No vendor lock-in</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Microsoft owns code</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Platform owns code</td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Model Choice</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border bg-gosign-accent/5">Model-agnostic (GPT, Claude, Gemini, Llama, Mistral)</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">GPT (Microsoft-bound)</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Platform-bound</td>
</tr>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Governance</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border bg-gosign-accent/5">Own Governance Layer, Cert-Ready Controls, Auditor Portal</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Azure governance</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Platform governance</td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Human-in-the-Loop</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border bg-gosign-accent/5">Architecturally enforced for risk decisions</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Optional</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Configurable</td>
</tr>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">EU AI Act</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border bg-gosign-accent/5">Compliant by design - transparency, explainability, oversight built in</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Microsoft roadmap</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Provider-dependent</td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Employee Oversight</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border bg-gosign-accent/5">Templates, logging, role concepts for employee representation bodies</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">No specific support</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">No specific support</td>
</tr>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Audit Readiness</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border bg-gosign-accent/5">GoBD (German record-keeping standard), ISA, IDW - audit documentation as architecture</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Platform compliance</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Platform compliance</td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Infrastructure</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border bg-gosign-accent/5">Client infrastructure (Azure, GCP, AWS, self-hosted, hybrid)</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Microsoft Cloud</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Provider cloud</td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Exit Strategy</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border bg-gosign-accent/5">Independent operation after 12-18 months</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Platform migration</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Platform migration</td>
</tr>
</tbody>
</table>
</div>
<p class="text-small text-gosign-text-light italic mt-4">
This table shows architectural differences, not quality judgments. Copilot and SaaS agents have different strengths - speed, ecosystem, simplicity. Gosign's strength is governance, ownership, and auditability in regulated environments.
</p>
</div>
</section>

<!-- Governance by Design -->
<section class="scroll-reveal bg-gosign-dark text-white py-section">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold">Governance by Design</h2>
<p class="text-h3 text-gosign-accent-on-dark font-semibold mt-4">
Agents only scale with infrastructure. Without governance, AI stays a pilot - with infrastructure, it becomes scalable.
</p>
<div class="mt-8 space-y-4">
<p class="text-body-lg text-gosign-text-on-dark/80 flex items-start gap-3">
<svg class="w-5 h-5 mt-1 flex-shrink-0 text-gosign-accent-on-dark" fill="currentColor" viewBox="0 0 20 20"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span>Human-in-the-Loop: Every process is decomposed into decision steps. For each step: Does a human decide, does a rule set apply, or does the AI decide autonomously? Where the agent is confident enough and has permission, it decides independently - this is not if-then-else, this is judgment within defined guardrails. Bias risk, discrimination potential, or employee oversight requirements: the architecture enforces human review. The Decision Layer enforces this routing - technically, not organizationally.</span>
</p>
<p class="text-body-lg text-gosign-text-on-dark/80 flex items-start gap-3">
<svg class="w-5 h-5 mt-1 flex-shrink-0 text-gosign-accent-on-dark" fill="currentColor" viewBox="0 0 20 20"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span>Auditable: Every agent decision produces a complete record: input, model, assessment, confidence score, reasoning, decision path, outcome. Immutable, exportable, audit-ready.</span>
</p>
<p class="text-body-lg text-gosign-text-on-dark/80 flex items-start gap-3">
<svg class="w-5 h-5 mt-1 flex-shrink-0 text-gosign-accent-on-dark" fill="currentColor" viewBox="0 0 20 20"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span>Employee Oversight: Governance frameworks - collective agreements, works agreements, or company policies - as explicit constraints in the Decision Layer. Employee representation bodies can trace: what the agent does, why, and when a human intervenes. Role concepts and templates included.</span>
</p>
<p class="text-body-lg text-gosign-text-on-dark/80 flex items-start gap-3">
<svg class="w-5 h-5 mt-1 flex-shrink-0 text-gosign-accent-on-dark" fill="currentColor" viewBox="0 0 20 20"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span>Cert-Ready by Design: Controls are first-class data objects in the system. Every control has a technical implementation, an automatic evidence generator, and an evidence history. Auditors see live status in the Auditor Portal.</span>
</p>
<p class="text-body-lg text-gosign-text-on-dark/80 flex items-start gap-3">
<svg class="w-5 h-5 mt-1 flex-shrink-0 text-gosign-accent-on-dark" fill="currentColor" viewBox="0 0 20 20"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span>EU AI Act compliant by design: Transparency, explainability, and human oversight are architecturally built in - not retrofitted.</span>
</p>
<p class="text-body-lg text-gosign-text-on-dark/80 flex items-start gap-3">
<svg class="w-5 h-5 mt-1 flex-shrink-0 text-gosign-accent-on-dark" fill="currentColor" viewBox="0 0 20 20"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span>We work alongside your internal IT, security, and compliance teams. Agents become part of your existing IT governance - not a parallel universe.</span>
</p>
</div>
</div>
<div class="mt-12 overflow-x-auto -mx-4 sm:mx-0 px-4 sm:px-0">
<img src="/images/diagrams/decision-layer-drei-arten-en.svg" alt="Three autonomy levels in the Gosign Decision Layer: (1) Human decides - agent provides data for salary adjustments, terminations, transfers, bias-relevant decisions, employee oversight matters (approx. 35% of HR processes). (2) Agent works, human reviews - for document processing, contract review, onboarding steps, reference letter creation, recruiting screening (approx. 40% of HR processes). (3) Agent autonomous - for FAQ answers, standard certificates, deadline checks, data validation, routine notifications (approx. 25% of HR processes). Every decision documented, every step auditable." width="900" height="360" class="w-full min-w-[600px] max-w-4xl mx-auto rounded-lg" loading="lazy" />
</div>
</div>
</section>

<!-- Definition: Decision Layer -->
<section class="scroll-reveal py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h3 class="text-h3 font-bold text-gosign-dark">Definition: Decision Layer</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
The Decision Layer decomposes every business process into individual decision steps and defines upfront for each: Does a human decide, does a rule set apply, or does the AI decide autonomously?
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Where discretion, discrimination risk, or employee representation requirements are involved, the architecture enforces human review. Where a decision is deterministic - collective agreement terms, deadline checks, booking logic - the agent applies the rule set consistently. And where the agent is confident enough and has permission: it decides independently. It interprets documents, classifies situations, evaluates context - demonstrably more consistent and legally sound than manual processing. Confidence Routing controls when the agent acts autonomously and when it escalates.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Every decision is documented - who decided what, when, on what basis, with what outcome. Auditable for external auditors, employee representation bodies, and internal compliance.
</p>
<p class="mt-4">
<a href="/en/governance/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Governance, Security & Audit</a>
</p>
</div>
</div>
</section>

<!-- From PoC to Platform -->
<section class="scroll-reveal py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark text-center">From PoC to Platform</h2>
<div class="mt-12 grid grid-cols-1 md:grid-cols-3 gap-8 relative">
<div class="text-center">
<div class="w-14 h-14 mx-auto rounded-full bg-gosign-accent flex items-center justify-center">
<span class="text-h3 font-bold text-white">1</span>
</div>
<h3 class="text-h3 font-bold text-gosign-dark mt-4">Discover</h3>
<p class="text-small font-semibold text-gosign-accent-text mt-1">1 week</p>
<p class="text-body text-gosign-text-light mt-2">Process analysis, rule mapping, system landscape assessment, use case prioritization. Outcome: a concrete plan for your first agent.</p>
</div>
<div class="text-center">
<div class="w-14 h-14 mx-auto rounded-full bg-gosign-accent flex items-center justify-center">
<span class="text-h3 font-bold text-white">2</span>
</div>
<h3 class="text-h3 font-bold text-gosign-dark mt-4">Build</h3>
<p class="text-small font-semibold text-gosign-accent-text mt-1">3-4 weeks</p>
<p class="text-body text-gosign-text-light mt-2">Production PoC. One agent, one process, live in your infrastructure. Decision Layer, governance, audit trail - from day one, not retrofitted.</p>
</div>
<div class="text-center">
<div class="w-14 h-14 mx-auto rounded-full bg-gosign-accent flex items-center justify-center">
<span class="text-h3 font-bold text-white">3</span>
</div>
<h3 class="text-h3 font-bold text-gosign-dark mt-4">Scale</h3>
<p class="text-small font-semibold text-gosign-accent-text mt-1">Ongoing</p>
<p class="text-body text-gosign-text-light mt-2">More agents, more departments, more locations. The architecture grows with your requirements. Same governance, same infrastructure.</p>
</div>
</div>
<p class="text-body-lg text-center text-gosign-text-light mt-8 max-w-narrow mx-auto">
After 12-18 months, you operate your agents independently. Full access to source code, prompts, and configurations. No vendor lock-in - even without a maintenance contract.
</p>
</div>
</section>

--- HR Audit Compliance Agent ---
> Event-driven HR audit preparation: IDW PS 980 plus SOX 404 audit-readiness pack, works-council co-determination evidence, GDPR Article 30 ROPA export, AGG plus EEO disparate-impact heatmap.

International HR audit and compliance does not run on one regulatory standard - it runs on five overlapping regimes at once across the UK, EU and US. A US-headquartered group with 5,000 employees might, in a single year, publish UK gender pay gap figures by the April deadline, file the US EEO-1 demographic return with the EEOC, run quarterly pay-equity regression, operate a whistleblower channel under the EU Directive, conduct GDPR impact assessments on its analytics, and tag CSRD own-workforce datapoints - each obligation sitting under a different statute, regulator and deadline. No single team can hold all of that in a spreadsheet.

## What an HR audit failure costs

Every HR audit failure carries direct costs that compound fast across all three jurisdictions. In the US, IBM puts the average employee-data breach at USD 4.45 million, and that is before enforcement: EEOC consent decrees for systemic discrimination regularly run into the tens of millions (a USD 175 million Bank of America wage-discrimination settlement, a USD 17.5 million Walmart pay-equity settlement), OFCCP findings can mean debarment from federal contracts, and SEC whistleblower matters have included a USD 36 million JP Morgan retaliation settlement.

In the UK, the ICO can fine up to GBP 17.5 million or 4% of global turnover - Marriott and British Airways are recent precedents. EHRC investigations under the Equality Act 2010 carry uncapped Employment Tribunal claims and reputational exposure on the published-employers list, and failure to publish gender pay gap figures on time triggers a compliance investigation.

In the EU, GDPR enforcement reaches EUR 20 million or 4% of global turnover, with headline cases against Meta, Amazon and WhatsApp. Whistleblower Directive breaches trigger Member State sanctions including, in some countries, criminal liability for retaliation. CSRD assurance tightens from limited to reasonable from 2028, and an unjustified pay gap above 5% forces a joint pay assessment and corrective measures under the Pay Transparency Directive.

For the CHRO and the Audit Committee, recurring findings carry particular weight. Auditors and regulators treat a repeat finding as a material-weakness signal, because it points to an absence of effective remediation - itself a control deficiency. The ICAEW guidance, AICPA SOC 2 and PCAOB AS 2201 all require evidence of remediation effectiveness before a prior-period finding can be closed.

## Why cross-jurisdictional audit needs sixteen steps, not eight

A single-jurisdiction HR audit takes eight to twelve steps; a cross-jurisdictional one needs sixteen, because the regimes overlap. The pipeline runs the UK gender pay gap calculation, the US EEO-1 return, pay-equity regression, disparate-impact testing, whistleblower intake with its statutory deadlines, the GDPR impact assessment and data-minimisation audit, the ISO 30414 metric set and the CSRD ESRS S1 datapoints - end to end.

A concrete cross-border example: a US-headquartered S&P 500 manufacturer with 5,000 employees - 3,200 across 14 US states, 1,200 in the UK and 600 in the EU. Its quarterly cycle includes a UK gender pay gap report, the US EEO-1 return, the OFCCP affirmative-action update, SOX 404 control testing across all four quarters, a twelve-month SOC 2 audit, CSRD reporting with the annual filing, a quarterly whistleblower summary to the Audit Committee and quarterly pay-equity regression. That produces twelve EEO-1 establishment reports, one consolidated UK gender pay gap report, four pay-equity regressions, a handful of whistleblower disclosures, the seventeen ESRS S1 datapoints and over sixty ISO 30414 metrics.

In the [Decision Layer](/en/decision-layer/), twelve of the sixteen steps are rule-engine decisions - scope inventory, evidence-source mapping, the gender pay gap calculation, EEO-1 categorisation, impact-assessment triggers, ISO 30414 metrics, CSRD datapoint mapping and finding tracking. Two steps are AI-augmented: pay-equity regression and disparate-impact analysis, which surface patterns for human review without making any employment decision. The last two require human judgement - whistleblower substantiveness and remediation effectiveness, both decided by a Compliance Officer or Internal Auditor.

## What sets HR audit apart from financial audit

Five HR-specific dimensions distinguish this Agent from generalised SOX-cycle audit support. First, pay-equity regression under the Equal Pay Act, Title VII, the UK Equality Act and the EU Pay Transparency Directive's 5% threshold. Second, disparate-impact analysis using the EEOC four-fifths rule and chi-square testing across hiring, promotion, termination and performance ratings. Third, whistleblower-channel operation under the EU Directive, with its acknowledgement and feedback deadlines and reversed burden of proof. Fourth, GDPR employee-data privacy with national derogations such as German works-council co-determination and French CSE consultation. Fifth, the CSRD ESRS S1 own-workforce disclosures, with assurance rising from limited to reasonable.

Pay equity has become the highest-stakes area precisely because the EU Pay Transparency Directive changes its character: an unjustified gap above 5% forces a mandatory joint pay assessment with employee representatives within six months, so residual gaps are no longer a private internal matter but a regulated obligation with employee-side leverage. Tools such as Trusaic, Syndio and OpenComp, alongside the established consultancies, now run regression quarterly rather than as an annual snapshot.

## Edge cases: posted workers, multi-state employees, works councils, federal contractors

Posted workers under the EU Posted Workers Directive fall under host-state minimum-wage, working-time and paid-leave rules for postings beyond twelve months, so their gender pay gap attribution and pay-equity grouping depend on host-state status. US multi-state employees sit under federal Title VII and a patchwork of state agencies with differing protected-class definitions - California adds military and veteran status, New York adds domestic-violence victims - which means disparate-impact testing has to run per state, not just on a federal aggregate.

Works-council co-determination under the German Works Constitution Act, the French CSE rules, the Italian Statuto dei Lavoratori and the Dutch COR adds a layer above GDPR: any change to HR-monitoring or analytics technology requires works-council consultation before deployment. OFCCP federal-contractor obligations under Executive Order 11246, Section 503 and VEVRAA add an affirmative-action plan, protected-class statistical analysis and a Compliance Evaluation, including one-to-two-year applicant-data retention under the Internet Applicant rule.

## Cross-system integration

The Agent integrates with the full global HR audit stack: [Workday with Peakon Engagement](https://www.workday.com/) for cloud-native HCM with EEO-1 cohorts and gender pay gap calculation, [SAP SuccessFactors](https://www.sap.com/products/hcm.html) as an enterprise HRIS tied into S/4HANA Finance for SOX 404, [Oracle Fusion Cloud HCM](https://www.oracle.com/human-capital-management/) integrated with Oracle ERP for SOX evidence and ISO 30414 reporting, and [ADP](https://www.adp.com/) for market-leading payroll with benchmark-based pay equity. BambooHR, Lattice and Culture Amp serve the 100-to-2,500-employee mid-market; Personio Europe brings GDPR national-derogation rules pre-configured; Ceridian Dayforce, UKG, Sage People and Cornerstone OnDemand round out the HCM layer. For applicant tracking, Greenhouse, Lever and iCIMS handle EEO-1 self-identification and Internet Applicant retention. For whistleblower channels, NAVEX EthicsPoint, Convercent (now OneTrust), Whispli, WhistleB, SpeakUp and FaceUp provide confidential intake and case management. For audit case management, AuditBoard, Hyperproof, Drata, Vanta and Secureframe cover SOC 2, ISO 27001, the GDPR impact-assessment library and SOX 404 control testing. For pay-equity analytics, Visier, ChartHop, Crunchr, Syndio, OpenComp and Trusaic, alongside the established consultancies, run the regression and flag gaps above the 5% threshold.

--- Benefits Enrollment Agent ---
> Benefits enrolment: US ERISA + IRC 401(k)/403(b), UK Pensions Act 2008 auto-enrolment 8% contribution, EU IORP II Directive and IAS 19 - GDPR Art. 88-compliant open enrolment.

International benefits enrolment does not run on one regulatory standard - it runs on five overlapping regimes at once across the UK, EU and US. A US-headquartered group with 5,000 employees might, in one cycle, run open enrolment with 401(k) deferrals and HSA and FSA contributions under the IRC, file the ACA Form 1095-C return with the IRS, operate UK auto-enrolment under the Pensions Act 2008, generate EU cross-border member benefit statements under IORP II, and complete an IAS 19 actuarial valuation for its defined-benefit obligations. Each of those sits under a different statute, regulator and deadline, and they all have to reconcile to the same payroll.

## What a benefits-enrolment failure costs

Every benefits-enrolment failure carries direct costs that compound fast across all three jurisdictions. In the US, ACA Employer Shared Responsibility creates a dual penalty - one for failing to offer minimum-essential coverage to enough full-time employees, another for each employee whose coverage is unaffordable - and a 401(k) plan disqualification retroactively taxes every deferral, match and dollar of earnings with interest. ERISA fiduciary-breach claims expose plan fiduciaries personally, a PBGC distress termination triggers a restoration funding obligation, and a COBRA notice failure carries a daily excise tax of up to USD 500,000 per plan year.

In the UK, the Pensions Regulator can escalate to a penalty notice of up to GBP 50,000 a day for serious non-compliance, on top of criminal prosecution. Failure to assess workers, make contributions, provide opt-out information or keep records creates employer liability and member compensation, and HMRC can recover tax relief on incorrectly claimed contributions.

In the EU, IORP II enforces home-state authorisation under host-state oversight: failing to authorise a cross-border scheme triggers restrictions, and missing member benefit statements trigger sanctions. The Mobility Directive bars vesting beyond three years, and the Posted Workers Directive's host-state pay rules force wage adjustments and social-security coordination.

For the CHRO and the Audit Committee, recurring findings carry particular weight. The IRS, the DOL, the PBGC and auditors treat a repeat finding as a material-weakness signal, because it points to an absence of effective remediation - itself a control deficiency. PCAOB AS 2201, AICPA SOC 2 and the ICAEW guidance all require evidence of remediation effectiveness before a prior-period finding can be closed, and ongoing Form 5500, PBGC and Pensions Regulator friction can materially impede corporate transactions and M&A.

## Why cross-jurisdictional enrolment needs sixteen steps, not eight

A single-jurisdiction benefits enrolment takes eight to twelve steps; a cross-jurisdictional one needs sixteen, because the regimes overlap. The pipeline runs the US 401(k), HSA, FSA and dependent-care calculations, ACA eligibility and Form 1095-C generation, COBRA continuation, FMLA and state paid-leave coordination, UK auto-enrolment with its opt-out and re-enrolment cycle, the EU cross-border pension and vesting rules, and the IAS 19 and ASC 715 actuarial valuation - end to end.

A concrete cross-border example: a US-headquartered S&P 500 manufacturer with 5,000 employees - 3,200 across 14 US states, 1,200 in the UK and 600 in the EU. Its annual cycle covers US open enrolment for a 1 January effective date, the ACA return, the UK auto-enrolment declaration of compliance, EU member benefit statements and the IAS 19 valuation. That produces around 1,500 US Form 1095-Cs, 1,200 UK auto-enrolment assessments, 600 EU benefit statements, one actuarial valuation and a steady stream of life-event status changes each quarter.

In the [Decision Layer](/en/decision-layer/), twelve of the sixteen steps are rule-engine decisions - trigger classification, eligibility, plan-compatibility, cost-impact calculation, mandatory-election completeness, deadline monitoring, UK auto-enrolment, Form 1095-C generation, COBRA, FMLA, the EU cross-border pension and the actuarial valuation. Two steps are AI-augmented: the personalised benefit-options dashboard and downstream synchronisation, which surface recommendations and failures for human review without auto-correcting an election. The last two require human consent - enrolment confirmation with electronic signature and dependent verification, both governed by the ERISA fiduciary duty and the IRS plan-document terms.

## What sets benefits enrolment apart from audit and compliance

Six dimensions distinguish this Agent from generalised HR audit support. First, orchestrating the annual open-enrolment window across 401(k), HSA, FSA, medical, dental, vision, life and disability elections. Second, life-event status changes under the Section 125 cafeteria-plan rules, with their 30-day window and dependent-eligibility checks. Third, US 401(k), 403(b) and 457 auto-enrolment under the EACA or QACA safe-harbor, with catch-up contributions, the Roth-versus-traditional split and the employer-match formula. Fourth, ACA Employer Shared Responsibility, Section 6055/6056 reporting and COBRA continuation. Fifth, UK auto-enrolment with its opt-out, re-enrolment and salary-sacrifice rules. Sixth, the EU cross-border pension governance under IORP II, with the Mobility Directive's vesting cap and the Posted Workers Directive's host-state coordination.

US 401(k) administration has become the highest-volume area precisely because Section 401(k) covers roughly 700,000 plans holding over USD 7 trillion across more than 100 million participants - and the SECURE 2.0 Act added the age-60-to-63 super catch-up, mandatory automatic enrolment and escalation for new plans, and expanded eligibility for long-term part-time workers. The major record-keepers now run continuous eligibility assessment, deferral elections, the Roth split, catch-up handling, auto-escalation, and loan and hardship-withdrawal workflows.

## Edge cases: posted workers, multi-state employees, works councils, UK salary sacrifice

Posted workers under the EU Posted Workers Directive trigger host-state benefits eligibility and pension-contribution changes for postings beyond twelve months, and the social-security coordination rules require single-state coverage with an A1 certificate. US multi-state employees sit under federal ACA alongside a patchwork of state paid-family-leave, short-term-disability and state-retirement programmes. Works-council co-determination under the German, French, Italian and Dutch frameworks requires consultation before any benefits-system change, and UK salary-sacrifice rules restrict most tax advantages except pensions, childcare, cycle-to-work and ultra-low-emission vehicles.

## Cross-system integration

The Agent integrates with the full global benefits-enrolment stack: Workday HCM and Benefits; SAP SuccessFactors Benefits tied into S/4HANA for IAS 19 and ASC 715; Oracle Fusion Cloud HCM with Oracle EPM for IAS 19 reporting; and ADP with carrier connectivity and Smart Compliance for ACA reporting. BambooHR, Lattice and Hibob serve the mid-market; Personio Europe, Sage People, IRIS HR and PayFit cover European HRIS with UK auto-enrolment, salary sacrifice and the Pension Dashboard; Paylocity, Paycom, UKG and Ceridian Dayforce serve the US. For 401(k) record-keeping it connects to Empower, Fidelity, Vanguard, T. Rowe Price, Voya, Principal and Charles Schwab; for private exchanges to Empyrean, Mercer Marketplace, Aon Active Health Exchange and WTW OneExchange; for dedicated benefits administration to Benefitfocus, Bswift, PlanSource and Businessolver with EDI 834, ACA reporting and COBRA; and for actuarial work to Mercer, Aon, WTW, Buck and Lockton for IAS 19 and ASC 715 disclosures, PBGC premium calculations and funded-status reporting.

--- Candidate Screening Agent ---
> AI-bias-audited CV screening: Title VII/EEOC Four-Fifths Rule, EU AI Act 2024 Annex III(4)(a) high-risk AI conformity, NYC Local Law 144 AEDT and UK Equality Act 2010 - Article 14 human oversight.

International candidate screening does not run on one regulatory standard - it runs on six overlapping regimes at once across the UK, EU and US. Every AI system that filters job applications in the EU is already a high-risk system under Annex III(4)(a) of the EU AI Act; the high-risk obligations attach from 2 August 2026 under current law, provisionally postponed to 2 December 2027 under the Digital Omnibus of 7 May 2026 (formal adoption still pending, as of June 2026). An organisation that cannot show its conformity assessment, declaration of conformity, CE marking, worker-representative information, fundamental-rights impact assessment, human oversight and record-keeping by that deadline has to take the automation offline until it can. The classification is not changing, so the time should be used to put that documentation in place.

A US-headquartered group with 5,000 employees running 200 to 800 applications per role concurrently faces, all at once: US Title VII, ADEA, ADA, the Equal Pay Act and GINA, with the EEOC four-fifths rule; the OFCCP Internet Applicant Rule and affirmative-action obligations; the NYC Local Law 144 bias audit alongside the Illinois, Maryland and California AI hiring laws; the UK Equality Act with the EHRC Code and the Section 60 health-enquiry prohibition; the GDPR's automated-decision and impact-assessment rules as read by the CJEU SCHUFA judgment; the EU AI Act itself; and the EU Pay Transparency Directive.

## One auditable candidate-screening pipeline

This Agent follows the [Decision Layer](/en/decision-layer/) principle: each decision is either rule-based, AI-assisted, or explicitly assigned to a human - with per-criterion explainability replacing black-box scoring.

The obvious challenge is familiar: 200, 400, sometimes 800 applications per role. Recruiters who, after the fiftieth CV, no longer apply the same standards as for the first. Hiring managers who ask after three weeks why the shortlist is not ready.

The real problem runs deeper. Most organisations using AI in screening do not know how their algorithms evaluate. They do not know the weighting. They cannot explain why Candidate A is on the shortlist and Candidate B is not. That is precisely where risk accumulates - and where each jurisdiction now demands documented architecture.

The Mobley v. Workday case makes this tangible. An applicant sues not the prospective employer but the software vendor whose AI screened him out. The US federal court certifies the claim as a class action - alleging systematic discrimination by age, ethnicity, and disability. A University of Washington study shows: in AI-driven CV screenings, names associated with white ethnicity were preferred in 85% of cases. In some occupational groups, Black male applicants were disadvantaged in 100% of test cases. In the US this exposes both vendors and deployers under the Title VII Section 703(k) burden-shifting test; in the UK the equivalent exposure arises under the Equality Act 2010 indirect-discrimination test.

Every screening failure carries direct cost. In the US, an EEOC charge can run through conciliation to litigation and a consent decree with monetary relief, injunctive relief and ongoing monitoring; an OFCCP notice of violation can mean a conciliation agreement or debarment from federal contracts; NYC Local Law 144 carries daily-accruing penalties; and the Illinois, Maryland, California and Colorado AI laws add overlapping state-level liability. In the UK, Equality Act tribunal awards are uncapped, including aggravated and exemplary damages, and the ICO can fine up to GBP 17.5 million or 4% of global turnover. In the EU, AI Act penalties reach EUR 35 million or 7% of worldwide turnover for prohibited practices, on top of GDPR penalties of up to EUR 20 million or 4% and the CJEU SCHUFA line of Article 22 enforcement.

## Why cross-jurisdictional screening needs thirteen steps, not eight

A single-jurisdiction screening takes eight to ten steps; a cross-jurisdictional one needs thirteen, because the regimes overlap. The pipeline runs the EU AI Act conformity gate, GDPR lawful-basis validation, document parsing with protected-characteristic redaction, rule-based knockout, per-criterion AI matching with explainability, continuous bias monitoring, adverse-impact escalation, the per-candidate decision record, recruiter shortlist review, documented decisions, downstream synchronisation, EU pay-transparency handling and periodic AEDT bias-audit reporting - end to end.

A concrete cross-border example: a US-headquartered S&P 500 manufacturer with 5,000 employees - 3,200 across 14 US states (including 250 NYC roles), 1,200 in the UK and 600 in the EU - with 280 open requisitions and 65,000 applications a year. That produces 65,000 EU AI Act decision records, 250 NYC Local Law 144 audit submissions, 3,200 EEO-1 entries, 280 OFCCP Internet Applicant logs, 1,200 UK tribunal-defence dossiers, 600 GDPR challenge-mechanism records, and the quarterly bias-monitoring reports and annual conformity-assessment refresh.

In the [Decision Layer](/en/decision-layer/), seven of the thirteen steps are rule-engine decisions - the conformity gate, lawful-basis validation, knockout criteria, adverse-impact escalation, decision-record generation, pay-transparency handling and periodic audit reporting. Four are AI-augmented: document parsing with redaction, per-criterion matching, bias monitoring and downstream synchronisation. Two require human judgement - recruiter shortlist review with the structured-interview kit, and documented decisions with a protected-characteristic neutrality attestation. Every step carries a timestamp, decider type, rationale and challenge mechanism.

## What sets screening apart from audit and compliance

Six dimensions distinguish this Agent from generalised HR audit support. First, CV parsing with provenance tracking and protected-characteristic redaction - name, photo, age, gendered pronouns and alma-mater proxies. Second, rule-based knockout criteria for work authorisation, regulated-profession licensure and security clearance. Third, per-criterion AI matching with individually justified scores, never one composite black-box figure. Fourth, continuous bias monitoring against the EEOC four-fifths rule with statistical-significance testing and Hazelwood standard-deviation analysis. Fifth, the EU AI Act high-risk conformity assessment, CE marking, fundamental-rights impact assessment, human oversight and record-keeping. Sixth, the NYC Local Law 144 annual independent bias audit, with its ten-business-day candidate notice and public posting.

The architecture satisfies the EU AI Act's record-keeping, transparency and human-oversight requirements by construction, not retrofit. Human oversight is real: no committee can manually review 400 applications and exercise oversight at the same time, but it can review a shortlist with documented per-criterion assessments and trace why one candidate scored 89 on competence fit and another scored 61. Transparency is real: a rejected applicant learns which named requirement the application failed on, not an aggregate score that explains nothing. And the records that enable later evaluation are the Decision Log itself - every step with its timestamp, decider type and rationale, captured as a core function rather than a by-product.

## Cross-system integration

The Agent integrates with the full global recruiting stack: Workday Recruiting, SAP SuccessFactors Recruiting, Oracle Recruiting Cloud and ADP Recruiting Management for HCM-embedded ATS. For dedicated applicant tracking it connects to Greenhouse and Greenhouse Inclusion, Lever, iCIMS, SmartRecruiters, Workable, Recruitee, JazzHR, BreezyHR, Bullhorn, Avature, Lattice Recruiting, Personio Recruiting and BambooHR. For AI talent intelligence it connects to Eightfold, Beamery, HiringSolved, Hiretual and Pymetrics; for video interviewing and assessment to HireVue, Modern Hire and Plum; and for executive search and RPO to Korn Ferry, Heidrick & Struggles, Russell Reynolds and the major consultancies. The Candidate Screening Agent is the litmus test for high-risk governance readiness - an organisation that can deploy it in full EU AI Act compliance can deploy any Annex III high-risk agent.

--- Certification Tracking Agent ---
> Mandatory-training and certification renewal: US OSHA 29 CFR 1910/1926, UK Health and Safety at Work Act 1974, EU Directive 89/391/EEC and ISO 45001 - automated expiry tracking and renewal.

International certification tracking does not run on one regulatory standard - it runs on twelve overlapping regimes at once across the UK, EU and US. Mandatory-training compliance, expiring certificates and renewal intersect with US OSHA, BSA/AML, HIPAA and the FAA and FMCSA rules, with UK health-and-safety, CQC and FCA conduct rules, and with the EU Framework Directive, GDPR and the ISO standards - and every one of them imposes recordkeeping, retention and inspection-readiness obligations.

A US-headquartered group of 5,000 employees managing 20,000 to 30,000 individual certifications faces exposure on several axes at once. An OSHA inspection carries five- and six-figure penalties per violation; an FFIEC examination finding can mean a consent order, a look-back analysis and higher capital requirements; HIPAA enforcement carries civil penalties up to USD 1.5 million a year per provision. A lapsed pilot medical grounds the aircraft, a deficient driver-qualification file triggers an Out of Service order, a UK HSE prosecution carries unlimited fines and up to two years' imprisonment, an FCA conduct breach can mean a prohibition order, and an ISO surveillance finding can suspend the certification and disrupt the recertification cycle.

## One auditable certification-tracking pipeline

This Agent follows the [Decision Layer](/en/decision-layer/) principle: each decision is either rule-based, AI-assisted, or explicitly assigned to a human - with per-certification regulatory-mandate flag replacing spreadsheet management.

The obvious challenge is familiar: at 800 employees and four to six mandatory certifications each, depending on role, location and regulatory framework, an organisation tracks 3,200 to 4,800 individual certificates, each with its own expiry date, renewal requirement and escalation rule. At 5,000 employees that scales to 20,000-30,000 certifications. An HR department managing this in spreadsheets knows two states: an overview at 50 employees, and blind flight at 500.

The real problem runs deeper. Most organisations using spreadsheet-based certification management cannot reliably say at any point how many of their employees currently hold all mandatory qualifications with documented proof. They do not know which certifications were renewed late and which were missed entirely. They cannot trace which deployment-stop should have been invoked but was not. That is precisely where regulatory exposure accumulates - and where each jurisdiction now demands documented architecture.

A pharmaceutical company in southern Germany discovers that its Qualified Person - the only one on site - has not renewed her GMP certificate for three weeks. Without a valid qualification, she cannot issue batch releases. Production stops. Not because of a quality problem. Because of a missed deadline in a spreadsheet. EASA Part-66 licensed engineers lose their certification privileges if the experience requirements are not met: six months of practice within the last two years. Without a valid licence, no Certificate of Release to Service. The aircraft stays grounded until a qualified engineer signs off the work. The equivalent applies in the US under the FAA's training-record retention rules, and in the UK under the CAA Part-66 and Part-145 organisation requirements. The FCA Senior Managers and Certification Regime imposes personal accountability that makes an expired qualification a direct regulatory breach.

The common denominator: it is not about a fine. It is about operational capability.

## Why cross-jurisdictional tracking needs fourteen steps, not eight

A single-jurisdiction certification tracking takes eight to ten steps; a cross-jurisdictional one needs fourteen, because the regimes overlap. The pipeline runs requirement identification by role and location, issuing-body verification, role-requirement mapping, expiry calculation, graduated alerts, gap detection, critical-expiration escalation, renewal verification, audit-ready reporting, downstream synchronisation, privacy compliance, Decision Record generation and a quarterly health-check - end to end.

A concrete cross-border example: a US-headquartered S&P 500 manufacturer with 5,000 employees - 3,200 across 14 US states, 1,200 in the UK and 600 in the EU - holding 25,000 individual certifications with 8,000 renewals a year. That produces 25,000 certification Decision Records, the OSHA recordkeeping, an FFIEC annual board report covering 800 customer-facing employees, HIPAA workforce-training records for 1,200 PHI-access employees, FAA retention files for 50 pilots, FMCSA driver-qualification files for 200 commercial drivers, the UK HSE and CQC notifications, the FCA attestation, the EU Framework Directive training records and the ISO management-review evidence.

In the [Decision Layer](/en/decision-layer/), eight of the fourteen steps are rule-engine decisions - requirement identification, role-requirement mapping, expiry calculation, graduated alerts, gap detection, critical-expiration escalation with deployment-stop, privacy compliance and Decision Record generation. Six are AI-augmented: issuing-body verification, renewal verification, audit-ready reporting, downstream synchronisation and the quarterly health-check. Every step carries a timestamp, decider type, rationale and challenge mechanism.

## What sets certification tracking apart from compliance training

Six dimensions distinguish this Agent from a generalised compliance-training rollout. First, deriving the requirement from the role, location and regulatory framework - OSHA general industry versus construction, the FFIEC training tier per banking licence, HIPAA for a covered entity versus a business associate, the FAA part, the FMCSA endorsement. Second, per-certification expiry tracking with the regulatory grace period, pre-booking lead time and the graduated alerts. Third, the regulatory-mandate flag that drives escalation and the deployment-stop for safety-critical roles. Fourth, issuing-body verification through an API where available, with a deterministic manual route otherwise. Fifth, retention for the longest applicable jurisdiction. Sixth, integrated management-system support across the ISO standards, with their surveillance and recertification cycles.

The architecture satisfies cross-jurisdictional recordkeeping by construction, not retrofit. OSHA requires injury-and-illness recordkeeping with five-year retention; the Decision Log captures every step as a core function rather than a by-product. The FFIEC manual requires annual training documentation and a board-approved AML programme; the consolidated completion and board-approval evidence closes that automatically. HIPAA requires workforce training within a reasonable period and on material change; the role-requirement matrix and material-change trigger satisfy it. The FAA and FMCSA retention files, the UK HSE and CQC notifications, the FCA attestation, the EU training records and the ISO surveillance and management-review evidence are all produced as outputs of the standard pipeline, not as separate compliance reporting.

## Cross-system integration

The Agent integrates with the full global learning-and-compliance stack: Workday Learning, SAP SuccessFactors Learning, Cornerstone OnDemand and Oracle Learning Cloud at the enterprise tier. For dedicated mid-market LMS it connects to Litmos, Docebo, Absorb, TalentLMS, 360Learning, Skillsoft Percipio, Saba Cloud, BambooHR Learning and others. For security-awareness training it connects to KnowBe4, Proofpoint, Mimecast, Hoxhunt and Cofense PhishMe; for external content libraries to Coursera for Business, LinkedIn Learning, Pluralsight and Udemy Business; and for specialised compliance to Cegid Talentsoft, IBM Kenexa, Meridian KSI and eFront. The Certification Tracking Agent acts as the upstream regulatory-mandate, expiry-tracking and deployment-stop layer feeding the downstream LMS workflow, or as the orchestration layer running parallel deployments where different business units use different LMS systems after an acquisition.

--- Compensation Benchmarking Agent ---
> Pay-equity analysis and disclosure: US Equal Pay Act + California SB 1162, UK Gender Pay Gap Regulations 2017, EU Pay Transparency Directive 2023/970 and CSRD ESRS S1-10/S1-13 reporting.

International compensation benchmarking does not run on one regulatory standard - it runs on twelve overlapping regimes at once across the UK, EU and US. Pay-equity analysis, pay-range disclosure, pay-gap reporting, the CEO Pay Ratio and equity-compensation valuation intersect with the US Equal Pay Act, Title VII and the EEOC and OFCCP guidance, the California, Colorado, NYC and New York State pay-transparency laws, the UK Equality Act and gender pay gap regulations, the EU Pay Transparency Directive and CSRD, the Dodd-Frank disclosures and the IFRS 2 and ASC 718 accounting standards - and every one of them imposes recordkeeping, retention and disclosure obligations.

A US-headquartered group of 5,000 employees across the UK, EU and US faces exposure on several axes at once. An EEOC Title VII or Equal Pay Act claim carries compensatory and punitive damages and class-action exposure; an OFCCP finding carries civil penalties and debarment from federal contracts; a California, Colorado or NYC pay-transparency breach carries per-posting penalties and PAGA exposure in California. A UK EHRC enforcement action carries uncapped tribunal awards, the EU Pay Transparency Directive reverses the burden of proof and forces a joint pay assessment, a CSRD failure carries ESMA sanctions and Say-on-Pay consequences, and a Dodd-Frank material misstatement triggers SEC enforcement and shareholder securities litigation.

## One auditable compensation-benchmarking pipeline

This Agent follows the [Decision Layer](/en/decision-layer/) principle: each decision is either rule-based, AI-assisted, or explicitly assigned to a human - with per-disclosure regulatory-mandate flag replacing spreadsheet management.

The obvious challenge is familiar: at 800 employees and 80 to 200 distinct roles across job families, levels and locations, an organisation tracks over 25,000 individual compensation records, each carrying base pay, variable pay, equity, pension, benefits and protected-class data. A Comp&Ben department managing this in spreadsheets knows two states: an overview at 50 employees, and blind flight at 500.

The real problem runs deeper. Most organisations using spreadsheet-based compensation management cannot reliably say at any point how their compensation distributes across protected classes within comparable employee groups. They do not know which roles were paid below market for how long. They cannot trace which pay decisions were grounded in market data and which were grounded in budget pressure. That is precisely where regulatory exposure accumulates - and where each jurisdiction now demands documented architecture.

By 7 June 2026, EU Member States must have transposed the Pay Transparency Directive 2023/970. Where a report shows an unexplained gap of 5 percent or more within a category of worker, the employer has six months to remediate - or must initiate a joint pay assessment with employee representatives. The burden of proof reverses: employees no longer need to demonstrate discrimination; the employer must demonstrate its absence. California SB 1162 already requires pay-scale disclosure in job postings for employers with 15 or more employees since 1 January 2023. The Colorado Equal Pay for Equal Work Act requires the same, with an advancement-opportunity notification on top. NYC Local Law 32 imposes USD 250 to 2,500 per posting. And the Dodd-Frank CEO Pay Ratio and Pay vs Performance disclosures require annual proxy disclosure, with material-misstatement exposure under the securities laws.

The common denominator: it is not about a fine. It is about board-level disclosure integrity, shareholder Say-on-Pay confidence and tribunal-defence readiness.

## Why cross-jurisdictional benchmarking needs fifteen steps, not eight

A single-jurisdiction benchmarking takes eight to ten steps; a cross-jurisdictional one needs fifteen, because the regimes overlap. The pipeline runs requirement identification by jurisdiction and threshold, survey-portfolio validation, job-to-benchmark mapping with human validation, compa-ratio calculation, regression-based pay-equity analysis, outlier identification, pay-range disclosure, the CEO Pay Ratio calculation, jurisdictional pay-gap reporting, the joint-pay-assessment trigger, equity-compensation valuation, privacy compliance and Decision Record generation - end to end.

A concrete cross-border example: a US-headquartered S&P 500 manufacturer with 5,000 employees - 3,200 across 14 US states (including NYC, California and Colorado roles), 1,200 in the UK and 600 in the EU - holding 25,000 individual compensation records across 80 to 200 distinct roles. That produces 25,000 Decision Records, the EEOC EEO-1 and US state pay-data reporting, the OFCCP compensation analysis, UK gender pay gap reporting on the gov.uk methodology, the EU Pay Transparency Directive reporting at each headcount threshold, the CSRD own-workforce disclosures, and the Dodd-Frank CEO Pay Ratio and Pay vs Performance filings.

In the [Decision Layer](/en/decision-layer/), nine of the fifteen steps are rule-engine decisions - requirement identification, compa-ratio calculation, pay-range disclosure, the joint-pay-assessment trigger, equity valuation, privacy compliance and Decision Record generation among them. Five are AI-augmented: survey-portfolio validation, job-to-benchmark mapping, regression-based pay-equity analysis, outlier identification, the CEO Pay Ratio calculation and jurisdictional pay-gap reporting. One requires human Comp&Ben validation - confirming an AI-suggested job-to-benchmark mapping. Every step carries a timestamp, decider type, rationale and challenge mechanism.

## What sets compensation benchmarking apart from merit-cycle administration

Six dimensions distinguish this Agent from generalised merit-cycle or bonus-plan administration. First, deriving the pay-equity requirement from the jurisdiction, headcount threshold and regulatory framework. Second, regression-based pay-equity testing with cohort and tainted-variable analysis under the OFCCP and EEOC guidance. Third, the regulatory-mandate flag that triggers a joint pay assessment at the EU Pay Transparency Directive's 5% threshold. Fourth, pay-range disclosure for job postings and employee inquiries with state-specific architecture. Fifth, retention for the longest applicable jurisdiction. Sixth, the integrated SEC executive-compensation disclosure combining the Dodd-Frank CEO Pay Ratio and Pay vs Performance with the IFRS 2 and ASC 718 equity-compensation valuation.

The architecture satisfies cross-jurisdictional disclosure by construction, not retrofit. The EEOC EEO-1 and US state pay-data reporting, the OFCCP compensation analysis, UK gender pay gap reporting, the EU Pay Transparency Directive reporting, the CSRD own-workforce disclosures and the Dodd-Frank filings are all produced as outputs of the standard pipeline, not as separate compliance reporting.

## Cross-system integration

The Agent integrates with the full global compensation-management, survey-data and equity-administration stack: Workday Compensation, SAP SuccessFactors Compensation and Oracle HCM Compensation for HCM-embedded compensation; Mercer, Willis Towers Watson, Aon McLagan and Radford, Korn Ferry Hay Group, Pearl Meyer and Compensia for survey data and job-evaluation methodology; Pave, Beqom, Compa Offers, Payfactors and PayScale for cloud-native compensation analytics; and ADP, BambooHR, Lattice, Greenhouse, Gusto, Rippling, HRSoft CompXL and Cornerstone Compensation for the mid-market. The Compensation Benchmarking Agent acts as the upstream regulatory-mandate, pay-equity-analysis and disclosure-reporting layer feeding the downstream compensation-management workflow, or as the orchestration layer running parallel deployments where different business units use different compensation systems after an acquisition.

--- HR Compliance Monitoring Agent ---
> Real-time HR compliance monitoring: continuous Equal-Pay-Index, EU Whistleblower Directive 2019/1937 hotline, CSDDD plus LkSG supply-chain HR diligence and EU AI Act bias-drift alerts.

International HR-compliance monitoring does not run on one regulatory standard - it runs on twelve overlapping regimes at once across the UK, EU and US. Continuous policy monitoring, the whistleblower channel, the AI bias audit, impact assessments and supply-chain due diligence intersect with the US anti-discrimination, SOX, FCPA and DOJ compliance-program regimes, the UK Equality, Bribery and Modern Slavery Acts and the SM&CR, the EU GDPR and Whistleblower Directive, the EU AI Act, CSDDD and CSRD, and ISO 37301 - and every one of them imposes recordkeeping, retention and disclosure obligations.

A US-headquartered group of 5,000 employees across the UK, EU and US faces exposure on several axes at once. An EEOC Title VII or Equal Pay Act claim carries compensatory and punitive damages and class-action exposure; an OFCCP finding carries civil penalties and debarment; a SOX 404 material misstatement triggers SEC enforcement, shareholder litigation and officer-and-director liability; an FCPA violation carries civil and criminal penalties, disgorgement and a monitor. A UK EHRC enforcement action carries uncapped tribunal awards, the FCA SM&CR brings personal prohibition and criminal liability for senior managers, a GDPR breach carries fines of up to EUR 20 million or 4% of turnover, an EU AI Act deployer breach reaches EUR 35 million or 7%, and CSDDD civil liability reaches 5% of turnover on top of damages.

## One auditable HR-compliance-monitoring pipeline

This Agent follows the [Decision Layer](/en/decision-layer/) principle: each decision is either rule-based, AI-assisted, or explicitly assigned to a human - with per-framework regulatory-mandate flag replacing periodic spot-checks.

The obvious challenge is familiar: at 5,000 employees across the UK, EU and US, an organisation falls at once under the Working Time and EU Pay Transparency Directives, GDPR, the EU AI Act, at least one collective agreement and 30 to 60 internal policies. Each framework changes independently. Thomson Reuters Regulatory Intelligence counted over 61,000 regulatory events globally in 2022 - 234 a day. The HR, Compliance, Legal and DPO functions managing this in spreadsheets and periodic spot-checks know two states: an overview at 50 employees, and blind flight at 500.

The real problem runs deeper. Compliance violations rarely stem from intent. They stem from the time-lag gap between the moment a rule changes and the moment operational practice catches up. A collectively agreed pay increase takes effect on 1 April - but the April payroll still runs on the old rates because HR entered the adjustment on 5 April. A new policy on AI-system deployment applies immediately - but the recruitment team learns about it two weeks later. The check on whether all these rules are being followed happens sporadically: once a year during the external audit, every few years during regulatory inspection, ad-hoc after complaints. Between checkpoints, months can pass in which deviations exist without anyone noticing.

Under current law, by 2 August 2026 the EU AI Act's high-risk obligations apply to HR AI systems used for recruitment screening, performance evaluation, promotion decisioning and termination recommendation, and deployers must meet the obligations, the fundamental-rights impact assessment, the record-keeping and the serious-incident reporting; following the provisional Digital Omnibus agreement of 7 May 2026 that deadline is set to be postponed to 2 December 2027 (formal adoption still pending, as of June 2026). By 2027, the CSDDD applies to companies with 5,000-plus employees, requiring due diligence on adverse human-rights impacts across their own operations and value chain. The EU Whistleblower Protection Directive already requires channels for employers with 50-plus employees, with a seven-day acknowledgement, three-month feedback and a retaliation prohibition. And the US DOJ's compliance-program guidance asks whether the programme is well-designed, adequately resourced and working in practice.

The common denominator: it is not about a fine. It is about board-level disclosure integrity, shareholder confidence, tribunal-defence readiness, DOJ self-disclosure cooperation credit and FCA SM&CR personal accountability.

## Why continuous monitoring needs fourteen steps, not a sample

A single-jurisdiction periodic audit samples at a point in time; continuous cross-jurisdictional monitoring needs fourteen deterministic steps, because the regimes overlap. The pipeline runs requirement identification by jurisdiction and threshold, rulebook translation, operational-data integration, continuous compliance evaluation, deviation classification, the AI bias audit, whistleblower-channel validation, the impact-assessment trigger, supply-chain due diligence, the escalation chain, remediation tracking with closure-evidence verification, reporting and the regulatory-content refresh - end to end.

A concrete cross-border example: a US-headquartered S&P 500 manufacturer with 5,000 employees - 3,200 across 14 US states, 1,200 in the UK and 600 in the EU - with 60-plus collective agreements, 30 to 60 internal policies and daily transactions across time-recording, payroll, access control, AI-system logs, the whistleblower channel, expense management and supplier engagement. That produces continuous-monitoring Decision Records, the EEOC EEO-1 and OFCCP analysis, UK gender pay gap reporting, the UK Modern Slavery statement, the CSRD own-workforce disclosures, the EU AI Act conformity declaration, the GDPR records of processing and the EU Whistleblower Directive annual report.

In the [Decision Layer](/en/decision-layer/), seven of the fourteen steps are rule-engine decisions - requirement identification, continuous compliance evaluation, deviation classification, the impact-assessment trigger, the escalation chain and the regulatory-mandate flag among them. Five are AI-augmented: operational-data integration, the AI bias audit, whistleblower-channel validation, supply-chain due diligence, remediation tracking, report generation and the regulatory-content refresh. Two require human Compliance, HR and Legal validation - rulebook version control and remediation-effectiveness verification. Every step carries a timestamp, decider type, rationale and challenge mechanism.

## What sets compliance monitoring apart from periodic audit

Six dimensions distinguish this Agent from a generalised internal audit or periodic review. First, continuous monitoring against a versioned rulebook, with rule application logged per transaction rather than per sample. Second, four-tier deviation classification - Information, Warning, Critical and Reportable - with a deterministic escalation chain. Third, the AI bias audit with disparate-impact testing and the four-fifths rule under the EEOC Uniform Guidelines, NYC Local Law 144 and the EU AI Act. Fourth, whistleblower-channel validation with retaliation-pattern detection under the EU Directive, SOX 806 and PIDA. Fifth, supply-chain due diligence with risk-rating under the CSDDD, Modern Slavery, UFLPA and LkSG regimes. Sixth, a re-check that verifies remediation effectiveness with closure-evidence, root-cause analysis and a preventive-control update.

The architecture satisfies cross-jurisdictional disclosure by construction, not retrofit. The EEOC EEO-1 and OFCCP analysis, UK gender pay gap reporting, the UK Modern Slavery statement, the CSRD own-workforce disclosures, the EU AI Act conformity declaration, the GDPR records of processing and the EU Whistleblower Directive annual report are all produced as outputs of the standard pipeline, not as separate compliance reporting. The Audit Trail that monitoring generates as a by-product - when a deviation was detected, who was notified, what action was taken and when the re-check happened - is exactly the documentation external auditors and regulatory inspectors expect as evidence. Audit preparation shrinks from weeks to hours because the evidence already exists.

## Where Accountability Stays - Why the Agent is Not High-Risk

The Agent detects deviations. It classifies them. It escalates them. It documents them. It re-checks whether the correction worked. What it does not do: decide what happens next. Whether a working-time violation leads to a formal warning, whether an FCPA gift-and-hospitality breach leads to disciplinary, whether an incident must be reported to a regulator - those are human decisions. Accountability for the root cause lies with the line manager or responsible department, not with the individual employee.

This separation is not just a governance choice. It is the reason the system is not high-risk under EU AI Act Annex III point 4. Monitoring and flagging, without decisions that affect the employment relationship, is the architecture that lets the system deploy without a conformity assessment holding up the rollout. If the scope expanded to individual-level performance evaluation, disciplinary recommendations or termination decisions, it would become high-risk under the Act's deployer obligations and fundamental-rights impact assessment. Works-council co-determination under the UK and EU consultation rules and the German and French frameworks applies to the introduction of monitoring systems, with a documented monitoring purpose, data, retention and access.

## Cross-system integration

The Agent integrates with the full global GRC, whistleblower-channel, training and audit-management stack: Workday Security & Risk, SAP GRC and Oracle Risk Management Cloud for HCM-embedded compliance; ServiceNow GRC and IRM, RSA Archer, MetricStream, AuditBoard, Galvanize, Resolver, LogicGate, Convercent, GAN Integrity and Vault Compliance for dedicated GRC; NAVEX EthicsPoint, OneTrust, EQS Group, Whistlelink, Speakup and Vault Platform for the whistleblower channel; and KnowBe4, Cornerstone OnDemand, SAI360, Skillsoft, Compliance Wave and Traliant for training. The Compliance Monitoring Agent acts as the upstream regulatory-mandate, continuous-monitoring, whistleblower-validation, AI bias audit, impact-assessment and supply-chain due-diligence layer feeding the downstream HR, risk and audit workflow, or as the orchestration layer running parallel deployments where different business units use different compliance systems after an acquisition.

--- Compliance Training Agent ---
> Mandatory training assignment and tracking: Title VII Faragher-Ellerth affirmative defence, CA AB 1825/NY Stop Sexual Harassment Act, UK Bribery Act Section 7 and EU AI Act Article 4 AI literacy.

International mandatory training does not run on one regulatory standard - it runs on twelve overlapping regimes at once across the UK, EU and US. Anti-harassment, anti-bribery, AML, AI-literacy, cybersecurity, whistleblower and modern-slavery training intersect with the US Title VII Faragher-Ellerth defence and the state harassment-training mandates, the SOX, Dodd-Frank, FCPA and DOJ compliance-program regimes and OSHA, the UK Bribery and Modern Slavery Acts and the SM&CR, and the EU GDPR, Whistleblower Directive, AI Act AI literacy, NIS2 and ISO 37301 - and every one of them imposes recordkeeping, retention and completion-evidence obligations.

A US-headquartered group of 5,000 employees across the UK, EU and US faces exposure on several axes at once. Without documented anti-harassment training, an employer forfeits the Faragher-Ellerth affirmative defence against vicarious liability for supervisor harassment, exposing it to compensatory and punitive damages, uncapped Section 1981 race claims and class-action exposure. A California AB 1825 breach triggers Civil Rights Department enforcement and loss of state contracting eligibility. Without adequate-procedures training, the UK Bribery Act Section 7 strict-liability defence falls away, exposing the organisation to uncapped tribunal awards and imprisonment for individuals. An EU AI Act AI-literacy breach reaches EUR 35 million or 7% of turnover, and a NIS2 cybersecurity breach reaches EUR 10 million or 2% for an essential entity.

## One auditable mandatory-training pipeline

This Agent follows the [Decision Layer](/en/decision-layer/) principle: each decision is rule-based, AI-assisted or explicitly assigned to a human, with a per-framework regulatory-mandate flag replacing spreadsheet-based tracking. The obvious challenge is familiar: at 5,000 employees across the UK, EU and US, an organisation falls at once under the federal Title VII floor, six state harassment-training statutes, the UK Bribery Act, GDPR, the EU AI Act, NIS2, at least one collective agreement and 30 to 60 internal policies. Each framework changes independently. Even at 1,500 employees across three sites, this matrix easily generates 8,000 to 12,000 individual training obligations a year - each with its own due date, target group and documentation requirement.

## Why cross-jurisdictional training needs fifteen steps, not a sample

A single-jurisdiction periodic training samples at a point in time; continuous cross-jurisdictional training needs fifteen deterministic steps, because the regimes overlap. The pipeline runs requirement identification by jurisdiction, role and threshold, curriculum translation, employee master-data integration, gap analysis, auto-enrolment, tiered reminders, completion verification, the Faragher-Ellerth affirmative-defense package, AI-literacy validation, UK Bribery Act adequate-procedures tracking, the state-specific harassment-training matrix, regulatory-content monitoring, pattern detection, non-completion remediation and completeness reporting - end to end.

A concrete cross-border example: a US-headquartered S&P 500 manufacturer with 5,000 employees - 3,200 across 14 US states (concentrated in the six harassment-training states), 1,200 in the UK and 600 in the EU - with 30 to 60 mandatory-training categories and 8,000 to 12,000 individual obligations a year, driven by new hires, role changes, location changes, regulatory amendments and M&A integration. That produces completion-tracking Decision Records, Faragher-Ellerth evidence packages per supervisor and location, the EEOC EEO-1 and state-agency reports, the UK Modern Slavery statement, the CSRD training disclosure, the EU AI Act deployer evidence, the GDPR records of processing, the EU Whistleblower Directive annual report and the NIS2 attestation.

In the [Decision Layer](/en/decision-layer/), eight of the fifteen steps are rule-engine decisions - requirement identification, gap analysis, the tiered reminder schedule, completion verification, UK Bribery Act tracking, the state harassment-training matrix and the regulatory-mandate flag among them. Five are AI-augmented: employee master-data integration, auto-enrolment and delivery, the Faragher-Ellerth package, AI-literacy validation, the regulatory-content refresh, pattern detection and completeness reporting. Two require human Compliance, L&D and Legal validation - curriculum version control and non-completion remediation with disciplinary input. Every step carries a timestamp, decider type, rationale and challenge mechanism.

## What sets compliance training apart from compliance monitoring

Six dimensions distinguish this Agent from compliance monitoring. First, a role-based curriculum with a version-controlled catalogue and auto-enrolment through the LMS API. Second, a tiered reminder schedule with deterministic escalation and access-suspension for safety-critical training. Third, the Faragher-Ellerth affirmative-defense evidence package per supervisor, location and reporting period. Fourth, UK Bribery Act adequate-procedures tracking mapped principle by principle to the MoJ Guidance. Fifth, EU AI Act AI-literacy validation with a role-tailored curriculum and persons-affected mapping. Sixth, the state-specific harassment-training matrix, with each state's cadence, content and delivery requirements.

The architecture satisfies cross-jurisdictional disclosure by construction, not retrofit. The EEOC EEO-1 and state-agency reports, the UK Modern Slavery statement, the CSRD training disclosure, the EU AI Act deployer evidence, the GDPR records of processing, the EU Whistleblower Directive annual report and the NIS2 attestation are all produced as outputs of the standard pipeline, not as separate compliance reporting. The Audit Trail that training generates as a by-product - when a course was assigned, when reminders went out, when completion was verified, what the assessment score was and when the retention quiz was passed - is exactly the documentation that EEOC charges, state-agency examinations, DOJ compliance-program evaluations, FCA SM&CR reviews and EU AI Office investigations expect as evidence. Audit preparation shrinks from weeks to hours because the evidence already exists.

## Where Accountability Stays - Why the Agent is Not High-Risk

The Agent assigns training. It tracks completion. It escalates non-completion. It documents Faragher-Ellerth evidence. It generates completeness reports. What it does not do: decide who gets disciplined. Whether non-completion leads to a formal warning, whether a supervisor's training gap leads to performance management, whether contract renewal is blocked - those are human decisions. Accountability for the root cause lies with the line manager or responsible department, not with the individual learner.

This separation is not just a governance choice. It is the reason the system is not high-risk under EU AI Act Annex III point 4. Training administration and completion tracking, without decisions that affect the employment relationship, is the architecture that lets the system deploy without a conformity assessment holding up the rollout. If the access-suspension or disciplinary-input automation expanded to autonomous performance evaluation or termination recommendation, it would become high-risk under the Act's deployer obligations and fundamental-rights impact assessment. Works-council co-determination under the UK and EU consultation rules and the German and French frameworks applies to the introduction of training-tracking systems, with a documented training purpose, data, retention and access.

## Cross-system integration

The Agent integrates with the full global learning, compliance-content, security-awareness and immersive-VR stack: Workday Learning, SAP SuccessFactors Learning and Oracle Learning Cloud for HCM-embedded learning; Cornerstone OnDemand, Litmos, Docebo, Absorb, TalentLMS, Bridge LMS and Saba Cloud for dedicated LMS; Skillsoft Percipio, NAVEX EthicsPoint Training, GAN Integrity, EVERFI Workplace Training and Veritas Compliance Training for compliance-content libraries; KnowBe4 Security Awareness, Compliance Plus and KMSAT for security awareness, phishing simulation and NIS2 cybersecurity; Mursion VR Training and EVERFI for immersive harassment and de-escalation training; and Coursera for Business, LinkedIn Learning Hub and Pluralsight for large-scale curated content. The Compliance Training Agent acts as the upstream regulatory-mandate, role-based-curriculum, completion-tracking, Faragher-Ellerth affirmative-defense, AI-literacy-validation, state-specific-harassment-training and access-suspension layer feeding the downstream HR, compliance, risk and audit workflow, or as the orchestration layer running parallel deployments where different business units use different LMS systems after an acquisition.

--- Contract Offer Generation Agent ---
> Rule-based employment contracts: US FLSA exempt/non-exempt classification, UK Section 1 Written Particulars, EU Directive 2019/1152 and Pay Transparency 2023/970 - DocuSign eIDAS e-signature.

Drafting an employment contract that works in the US, the UK and the EU at once means satisfying four bodies of law that pull in different directions. In the US, the FLSA decides whether a role is exempt or non-exempt under 29 CFR Part 541, and misclassification carries back-pay and liquidated damages. In the UK, Section 1 of the Employment Rights Act 1996 has required fifteen written particulars on the first day since the 2018 amendment, and failing to provide them costs up to four weeks' pay at Tribunal. EU Directive 2019/1152 sets the mandatory information, a six-month probation cap and the right to parallel employment. And the EU Pay Transparency Directive 2023/970, in force from 7 June 2026, bans the pay-history question and requires a pay range in the job posting. For a large or upper-mid-market employer, a single contract can engage all four at once.

## Where the penalties add up

The exposure stacks across jurisdictions. FLSA misclassification carries per-employee penalties and double back-pay, and the limitations period runs two years - three for wilful violations. Title VII, ADEA and ADA discrimination claims carry back-pay damages and class-action risk. State pay-disclosure laws impose per-posting penalties with a private right of action. UK Section 1 non-compliance costs up to four weeks' pay at Tribunal, and the ICO can fine up to GBP 17.5M or 4 percent of global turnover. GDPR Article 83(5) reaches the same 4 percent ceiling if the drafting algorithms run without a DPIA or make a fully automated decision. EEOC charges rose sharply between 2020 and 2024, with serious harassment cases against senior executives settling in the millions. Word templates leave all of this to chance; the agent checks each contract against the relevant statute as it is written.

## Twelve rule-based decisions, two AI indicators, one human escalation

The agent breaks contract generation into fifteen micro-decisions, each one recording its step, its question, who decides (a rule, an AI indicator, or a human), the statutory reasoning, an audit trail and an appeal path. Twelve are rule-based: pulling candidate data from the applicant-tracking system and checking the lawful basis; FLSA exempt classification; the UK first-day written particulars; EU Directive 2019/1152 compliance; pay-range generation; the FCRA background-check sequence; EEO-1 and OFCCP reporting; the eIDAS signing workflow; the onboarding trigger; background-check vendor compliance; and the Joint Pay Assessment trigger. Two are AI-assisted indicators where the model flags and a human decides: the discrimination check on contract clauses, and the non-compete enforceability check. The single human escalation is C-suite contracts, which go to the Audit Committee under SOX 404, the UK SM&CR and the Dodd-Frank pay-governance rules.

## Checking against current enforcement priorities

The agent measures each contract against the EEOC's enforcement priorities for 2024 to 2026. Contract clauses and the job posting are screened for discrimination under Title VII, ADEA and ADA against the EEOC's McDonnell Douglas burden-shifting framework. Pay ranges are checked against the state disclosure laws and their per-posting penalties. The UK first-day particulars are validated against ACAS guidance, the EU mandatory information against Directive 2019/1152, and exempt classifications against the DOL Field Operations Handbook and opinion letters. Everything is documented so that, if a charge is filed, the compliance record is ready for General Counsel rather than reconstructed after the fact.

## The harder cases

The harder scenarios are handled explicitly. C-suite contracts engage SOX internal-control certification, the Dodd-Frank CEO Pay Ratio, the Section 162(m) deduction limit, the Say-on-Pay vote and, in the UK, the SM&CR. Where employees are covered by a collective bargaining agreement, the agreement takes precedence and the NLRA duty to bargain in good faith applies. Posted workers fall under the EU Posted Workers Directive, which extends host-state minimum wage, working time and paid-leave conditions to longer postings, alongside the A1 certificate for social-security coordination. Multi-state US employees pick up state paid-family-leave, short-term-disability and auto-enrolment retirement programmes that vary by state. And independent-contractor classification has to satisfy the FLSA and stricter state tests such as California's ABC test, where getting it wrong carries a substantial per-worker reclassification cost.

## How it connects to your systems

The agent works through the recruiting, onboarding and e-signature platforms companies already run. It connects via API to the major HCM suites - Workday, SAP SuccessFactors, Oracle HCM and ADP - and to the mid-market systems such as BambooHR and Personio. Candidate data comes from applicant-tracking systems like Greenhouse, Lever and iCIMS. Signing runs through DocuSign or eIDAS-accredited European alternatives such as Yousign and Adobe Sign, with the data-processing agreement that GDPR Article 28 requires. Background checks are handled through FCRA-compliant providers, and dedicated contract-lifecycle tools add clause-level checking. The agent passes work on to the compensation, compliance-training and audit agents where their input is needed.

--- Employee Data Management Agent ---
> Centralised employee data: EU GDPR Art. 5/9/22/88, UK GDPR + DPA 2018, US CCPA/CPRA + 12 state privacy laws and HIPAA - Master Data Management with pseudonymisation and DPIA.

Managing employee data across borders means answering to four privacy regimes that overlap but do not align. The GDPR sets the core European duties - data minimisation, lawful basis, the special-category prohibition, the right to erasure, breach notification, the DPIA - with fines reaching 4 percent of group revenue. UK GDPR and the ICO Employment Practices Code carry the same weight in Britain. California's CCPA/CPRA gives employees the right to know, delete, correct and opt out, and since the employee exemption lapsed in 2023 it backs breaches with a private right of action and statutory damages. And a growing set of US state laws - Virginia, Colorado, Connecticut, Texas, Oregon and more - add parallel rights with their own variations and a universal opt-out. For a large or upper-mid-market employer, a single data operation can trigger obligations under all four at once.

## Where the penalties add up

The exposure stacks across regimes. GDPR Article 83 reaches 4 percent of group revenue for serious violations, and the ICO can match it at up to GBP 17.5M or 4 percent of global turnover. California's CCPA carries statutory damages per consumer for breaches without reasonable security, alongside class-action exposure and administrative penalties from the CPPA. HIPAA penalties run per violation up to an annual cap, with criminal liability in the worst cases. The state privacy laws add their own per-violation penalties, and where an HR system is AI-augmented the EU AI Act can reach 7 percent of global turnover. A breach of segregated medical files draws EEOC charges; an ERISA or IRS confidentiality lapse draws Treasury penalties. Fragmented HR systems multiply the chances of each; a single governed platform reduces them.

## Thirteen rule-based decisions, one AI indicator, one human escalation

The agent breaks data management into fifteen micro-decisions, each recording its step, its question, who decides, the statutory reasoning, an audit trail and an appeal path. Thirteen are rule-based: ingesting master data and fixing its lawful basis; classifying special-category data; synchronising records for accuracy; pseudonymisation and encryption; the right to erasure; subject access requests; detecting fully automated decisions; triggering a DPIA; generating the records of processing; assessing cross-border transfers; validating data-processing agreements; breach notification; and the retention and deletion schedule. One is an AI-assisted indicator: the data-minimisation audit, where the model flags over-collection and the DPO decides. The single human escalation covers breaches, high-risk DPIA findings and failed transfer assessments, which go to the Audit Committee.

## Checking against current enforcement priorities

The agent measures the company's privacy posture against where the regulators are actually looking in 2024 to 2026. The EDPB has prioritised employee-data guidelines, DPIA criteria and consent in the employment context. The ICO is focused on the Employment Practices Code, subject access requests and monitoring at work. California's CPPA is testing the right to know, delete and opt out now that the employee exemption has lapsed, while state attorneys general coordinate enforcement of breach notification and the new state laws. The HHS Office for Civil Rights enforces the HIPAA rules. The agent documents compliance against each of these priorities, with the validation workflow ready for the DPO and privacy counsel, so the record is prepared rather than reconstructed under scrutiny.

## The harder cases

The harder scenarios are handled explicitly. A transfer of data to the US requires, after Schrems II, either the EU-US Data Privacy Framework or Standard Contractual Clauses, together with a transfer-impact assessment, supplementary encryption and - where a works council exists - consultation. An AI-augmented HR system tips into the EU AI Act's high-risk category, bringing deployer obligations, a Fundamental Rights Impact Assessment and mandatory human oversight on top of the GDPR Article 22 prohibition. For union employees, NLRA Section 7 rights and the limits on workplace surveillance apply, and data processing may itself be a subject of collective bargaining. Whistleblower data falls under the EU Whistleblower Directive's confidentiality and five-year retention rules. And an employee who works across jurisdictions can file a data-subject request under several regimes at once, with conflicting response windows and verification rules that the agent reconciles.

## How it connects to your systems

The agent works through the HR, master-data and privacy platforms companies already run. It connects via API to the major HCM suites - Workday, SAP SuccessFactors, Oracle HCM and ADP - and to mid-market systems such as BambooHR, Personio and Sage People. Dedicated privacy platforms like OneTrust and BigID handle data discovery and subject-rights automation, while master-data and governance tools such as Collibra, Informatica and IBM keep records consistent and tracked. Enterprise GRC suites tie the controls together across GDPR, UK GDPR, CCPA, HIPAA and the state laws. Signing runs through eIDAS-accredited European providers under the data-processing agreement that GDPR Article 28 requires. The agent passes work to the audit, compliance-monitoring, compensation and contract agents where their input is needed.

--- Employee Relations Case Agent ---
> Structured ER case management: US Title VII Faragher-Ellerth defence, UK Equality Act Section 109 + ACAS Code, EU Whistleblower Directive 2019/1937 - harassment, discipline and PIP workflows.

Handling employee-relations cases across borders means answering to four bodies of law at once. In the US, Title VII, the ADEA and the ADA govern discrimination, an EEOC charge must be filed within 300 days, and cases turn on the McDonnell Douglas burden-shifting framework and the Faragher-Ellerth defence; damages are capped by employer size federally but uncapped under state laws such as California's FEHA. In the UK, the Equality Act 2010 covers harassment, victimisation and employer liability, the Employment Rights Act sets the grounds for fair dismissal, and following the ACAS Code can move compensation by up to 25 percent either way. The EU Equal Treatment and Whistleblower Directives add protected reporting channels, a reverse burden of proof and five-year retention. And GDPR governs the case data throughout. For a large or upper-mid-market employer, a single case can engage all four regimes - with exposure that runs well into the millions once class-action risk is added.

## Where the litigation exposure adds up

The exposure stacks across regimes. US Title VII damages are capped by employer size, but back pay is uncapped, Section 1981 race claims and state laws such as California's FEHA carry no cap, and the prevailing party can recover attorney's fees. ADEA violations can double the back pay where wilful. UK Tribunals award uncapped compensation in discrimination and whistleblower cases, on top of an injury-to-feelings award and an ACAS uplift of up to 25 percent, and a Group Litigation Order opens multi-claimant exposure. GDPR fines and ICO penalties reach 4 percent of turnover. SOX and Dodd-Frank give whistleblowers a private right of action and, at the SEC, a bounty. And a pattern of discrimination, harassment or retaliation invites an EEOC systemic case or a collective action. Fragmented case files let these risks grow unnoticed; structured case management with limitations control, burden-shifting documentation and a complete Faragher-Ellerth file keeps them in check.

## Ten rule-based decisions, one AI indicator, five human escalations

The agent breaks case management into sixteen micro-decisions, each recording its step, its question, who decides, the statutory reasoning, an investigation audit trail and an appeal path. Ten are rule-based: classifying the case and mapping the statute; assigning a conflict-free investigator; setting the confidentiality controls; calculating the deadlines; running the notification workflow; generating a performance plan; assessing mediation; producing a compliant severance agreement; activating whistleblower protections; and coordinating a cross-border investigation. Five are human escalations - the judgement calls: taking the intake and triaging a whistleblower disclosure, documenting the investigation, deciding the disciplinary action, preparing a termination with its defence file, and escalating SOX, Dodd-Frank or class-action matters to the Audit Committee. The single AI-assisted indicator is the pattern-and-practice analysis, where the model clusters cases and General Counsel decides what it means.

## Why checklists are not enough at four parallel jurisdictions

A checklist is static. It models the ideal case, not the branches. A US harassment complaint where the employee filed an EEOC charge follows a different path than one where they did not. A UK grievance where the employee invokes ACAS Early Conciliation differs from one where the Tribunal claim filed directly - both differ from cross-border whistleblower disclosure under EU Whistleblower Directive 2019/1937 Article 13. Every branch creates new deadlines, new documentation requirements, new participants, new burden-shifting triggers. In an organisation with 1,500 employees, between 15 and 40 employee relations cases run in parallel at any given time, each in a different phase with different burden-of-proof thresholds. When an EEOC Right-to-Sue letter surfaces three days before the 90-day filing deadline, the scramble begins. Scrambling produces exactly the errors that tip proceedings: incomplete investigation file, missing Faragher-Ellerth defense documentation, premature action before ACAS Code response period expires, retaliation indicators ignored, reverse burden documentation gaps.

## The harder cases

The harder scenarios are handled explicitly. A cross-border whistleblower disclosure under Article 13 of the EU Whistleblower Directive requires coordinated protected channels, the reverse burden of proof, five-year retention and a GDPR transfer assessment for the case data. If an HR system runs risk-scoring or a recommendation engine over disciplinary cases, it tips into the EU AI Act's high-risk category, bringing deployer obligations, a Fundamental Rights Impact Assessment and mandatory human oversight on top of the GDPR Article 22 prohibition. Union employees carry NLRA Section 7 rights and Weingarten representation, and disciplinary procedures may be a matter for collective bargaining. Public employees add Garrity and Loudermill due-process protections. An employee who works across jurisdictions can have a case running under several regimes at once, with conflicting limitations periods that the agent reconciles. And a SOX whistleblower at a listed company triggers mandatory notice to the Audit Committee, General Counsel and outside counsel.

## How it connects to your systems

The agent works through the HR, whistleblower and case-management platforms companies already run. It connects via API to the major HCM suites - Workday, SAP SuccessFactors, Oracle HCM and ADP - and to mid-market systems such as BambooHR, Personio and ServiceNow. Dedicated whistleblower and ethics-hotline platforms like NAVEX, EQS and Convercent handle protected reporting under the EU Whistleblower Directive, UK PIDA and the US SOX and Dodd-Frank regimes. Enterprise GRC suites tie investigation tracking and the audit trail together. The agent passes work to the employee-data, audit and compliance-monitoring agents where their input is needed.

--- Employee Self-Service Agent ---
> Self-service HR portal: GDPR Art. 12-17 Subject Access Request, UK GDPR/DPA 2018, CCPA/CPRA, ADA Title III + WCAG 2.1 AA accessibility - leave/sickness/payslip with eIDAS e-signature.

Running an employee self-service portal across borders means meeting four bodies of law at once. Under the GDPR the portal has to serve subject access, erasure and portability requests, and never make a fully automated decision, with fines reaching 4 percent of group revenue; UK GDPR and the ICO carry the same weight, including a 30-day deadline for access requests. California's CCPA/CPRA and the other US state privacy laws add a parallel right to know, delete and correct, backed by state attorneys general and a private right of action. Accessibility law - the ADA Title III rule, the UK Equality Act and the EU European Accessibility Act - requires the portal to meet WCAG 2.1 AA. And the EU AI Act requires the chatbot to identify itself as AI. For a large or upper-mid-market employer, a single self-service interaction can engage all four regimes at once.

## Where the exposure adds up

The exposure stacks across regimes. GDPR fines and ICO penalties reach 4 percent of turnover, and a missed 30-day access-request deadline draws a complaint to the relevant data-protection authority. California's CCPA carries per-violation penalties, state attorney-general enforcement and a private right of action for breaches, with the other state laws adding their own variations. ADA Title III accessibility failures carry civil penalties and, as the Domino's Pizza and Winn-Dixie cases showed, class-action exposure. The EU AI Act can fine a transparency breach by the chatbot. And a contested electronic signature can put a transaction's validity in dispute. Fragmented forms let each of these risks grow unnoticed; automating the access-request clock, the erasure cascade, WCAG conformance and the chatbot's self-identification closes them.

## Twelve rule-based decisions, two AI indicators

The agent breaks self-service into fourteen micro-decisions, each recording its step, its question, who decides, the statutory reasoning, an audit trail and an appeal path. Twelve are rule-based: verifying identity; setting the access scope by role; running subject access requests against the 30-day clock; handling rectification, erasure and portability; selecting the right electronic-signature level; delivering payslips and pay-information rights; calculating leave; processing sickness; running transactional changes such as address and bank details; keeping the chatbot transparent under Article 50; holding the portal to WCAG 2.1 AA; and logging everything for the records of processing. Two are AI-assisted indicators: classifying the inquiry to route it, and detecting sensitive topics. There is no mandatory human gate for routine operation, but a grievance, harassment, retaliation or whistleblower disclosure is routed to a specialist - the model classifies, it does not decide.

## Why document portals are not enough at four parallel jurisdictions

Most organisations already have document portals. Yet ticket volume remains high. The reason is almost always the same: the portal does not answer questions - it offers forms. Anyone wanting to know whether special leave for a move also applies to an intra-city move finds a PDF of the company policy on the portal. But no answer. Anyone wanting to know their accrued holiday balance finds a leave request form but not the actual balance. Anyone wanting to exercise their GDPR Art. 15 right of access finds a generic privacy policy but no DSAR workflow with 30-day response calendar. The difference between a document portal and a self-service agent is the difference between a library and an advisor. Both have the same knowledge. But only one understands the question and gives an answer that fits the specific situation. Anyone who receives a correct, source-referenced answer within seconds no longer opens a ticket. In projects with genuine answer-capable self-service systems, HR ticket volume regularly drops by more than half. The remaining inquiries are those that require human judgement - and they finally get the attention they deserve.

## The harder cases

The harder scenarios are handled explicitly. A cross-border access request is consolidated under GDPR Article 15, UK GDPR and CCPA's Right to Know, with third-party data and privileged communications redacted and the 30-day clock running. Mobile accessibility is held to WCAG 2.1 AA across native iOS and Android apps, tested with screen readers and keyboard navigation. The chatbot operates under the EU AI Act's transparency rules, grounding its answers in verified policy documents, citing sources and escalating below a confidence threshold. A self-service whistleblower channel meets the EU Whistleblower Directive, UK PIDA and the US SOX regime, with protected reporting and five-year retention. And an employee who works across jurisdictions can fall under several privacy regimes at once, which the agent reconciles, including the cross-border transfer safeguards GDPR Chapter V requires.

## How it connects to your systems

The agent works through the HR, self-service and chatbot platforms companies already run. It connects via API to the major HCM suites - Workday, SAP SuccessFactors, Oracle HCM and ADP - and to mid-market systems such as BambooHR, Personio, ServiceNow and Microsoft Viva. Where a company runs an LLM-powered HR assistant - ChatGPT Enterprise, Glean, Claude Enterprise or a Slack bot - the agent grounds it in policy documents and holds it to the EU AI Act's transparency rules. Specialised self-service and engagement tools round out the mix. The agent passes work to the employee-data, employee-relations and audit agents where their input is needed.

--- Equipment Provisioning Agent ---
> IT hardware onboarding and offboarding: OSHA 29 CFR 1910 ergonomics, UK DSE 1992 + PUWER, EU NIS2 cybersecurity and GDPR Art. 88 MDM - Intune/Apple DEP with eIDAS handover signature.

Provisioning equipment across borders engages four bodies of law that most onboarding processes never see. On workplace safety, OSHA and the US ANSI/HFES standard govern workstation ergonomics in the US, with penalties per violation, while the UK Health and Safety at Work Act and DSE Regulations carry an HSE notice and, in the worst case, an unlimited fine. The EU adds its Display Screen Equipment Directive and, on cybersecurity, the NIS2 Directive, which fines essential entities up to 2 percent of global turnover. GDPR governs any tracking of the device, with fines reaching 4 percent of turnover. And accessibility law - the ADA, the UK Equality Act and the EU Equal Treatment Directive - requires reasonable accommodation. For a large or upper-mid-market employer, a single provisioning event can engage all four, on top of the lost productivity that a missing workstation already costs.

## Coordination fails not competence

This agent follows the [Decision Layer](/en/decision-layer/) principle: each decision is either rule-based, AI-assisted, or explicitly assigned to a human.

The provisioning workflow in most organisations between 500 and 5,000 employees looks like this: HR records the new hire in the personnel system. IT receives an email with the start date. Procurement receives a separate ticket. Facilities receives a third email. Each department works in its own system. Coordination runs through email chains and personal reminders. If one link breaks - holiday, sick leave, postponed start date - the chain breaks. Nobody has the overall status because there is no overall status.

The result: 43 percent of new hires wait more than a week for their workstation. 18 percent still lack required equipment after two months. 39 percent begin questioning their decision to join during this period. A single hire generates IT-side costs of USD 2,000 to USD 8,800; one-third lost in back-and-forth queries, duplicate orders, rework. On top of the delay sit the compliance failures: a non-compliant workstation can draw an HSE prosecution in the UK or an OSHA penalty in the US, a failure to provide assistive technology invites an EEOC charge, and a cybersecurity lapse triggers NIS2 enforcement.

## How the agent takes over orchestration

The Equipment Provisioning Agent does not solve one department's problem. It solves the coordination problem between all involved departments.

**Profile derivation instead of individual requests.** As soon as a hire is recorded in the HR system, the agent derives the complete equipment profile from position, department, and location. The profile carries the ergonomic baseline required by the UK DSE Regulations and the EU Display Screen Equipment Directive, any accessibility flag for a reasonable adjustment under the ADA or the UK Equality Act, and the cybersecurity baseline the EU NIS2 Directive requires. Not as a recommendation that someone must read and act on - but as a machine-readable requirement list that flows directly into the target systems.

**Parallel routing instead of sequential email chains.** The agent generates parallel requests to IT, procurement, and facilities from the profile - simultaneously, not sequentially. Each request lands in the respective system as a structured order: laptop model and configuration to procurement, account creation and Microsoft Intune MDM enrolment to IT, access badge and ergonomic workstation to facilities management. No interpretation needed, no specification queries.

**Inventory check and shortage management.** Before every order, the agent checks current stock. If the standard model is available, it is reserved. If it is not, the agent proposes compatible alternatives and escalates to a human only when no rule-based solution is possible. This reduces waiting times during supply shortages from weeks to hours.

**Zero-touch device provisioning with cybersecurity baseline.** The agent triggers Microsoft Autopilot for Windows, Apple's enrolment programme for iOS and macOS, and Android Enterprise for Android. The cybersecurity baseline is applied automatically - full-disk encryption, multi-factor authentication, endpoint detection and a remote-wipe capability - in line with the ISO 27001 controls and the risk-management measures the EU NIS2 Directive requires.

**End-to-end status tracking.** From the moment of the request through complete provisioning, the agent monitors every sub-order. HR and the hiring manager see a single status instead of five separate ticket systems. Delays are detected before they jeopardise the start date.

## Why this agent makes a strong starting point

IT equipment is the most visible moment in onboarding - and simultaneously the lowest-risk entry point for agent-based automation. Three reasons.

First: no high-risk classification under the EU AI Act. The agent makes no decisions about people, only coordinates logistics. EU AI Act 2024/1689 Article 26 deployer obligations apply but Annex III HR-Recruitment Point 4 not applicable to logistics coordination. No works council co-determination rights for logistics. That reduces governance effort to a minimum.

Second: high visibility at low stakes. When everything is ready on day one - laptop configured, accounts active, access badge programmed, ergonomic workstation set up - every new hire notices. And every hiring manager. That builds acceptance for further automation before more politically sensitive processes are on the agenda.

Third: the technical patterns built here - order routing, inventory integration, MDM zero-touch provisioning, status tracking, eIDAS qualified signature equipment handover, ISO 27001 cybersecurity baseline - are reused by subsequent agents. The Transfer-Relocation-Agent for relocations, the Offboarding-Agent for returns, the Vendor-Management-Agent for framework agreements. Starting with the Equipment Provisioning Agent means building infrastructure, not just a point solution.

## Eleven rule-based decisions, three AI indicators

The agent breaks provisioning into fourteen micro-decisions: eleven rule-based, three AI-assisted intent indicators, and no mandatory human gate for routine operation. The three AI-assisted decisions are the inventory check, where the model finds a compatible alternative by specification and predicts lead time; the procurement request, where it drafts the order and suggests a supplier; and delivery tracking, where it monitors carriers and flags delays. In each, the model proposes and a human acts - and high-value or cross-border equipment, or an accommodation request, is escalated to a person.

## The harder cases

The harder scenarios are handled explicitly. Cross-border equipment movement brings customs handling, and where the device carries metadata across a border it is assessed under the Schrems II transfer rules. A reasonable-accommodation request runs the interactive process the ADA and the UK Equality Act require, providing assistive technology or an adjusted workstation. A bring-your-own-device arrangement separates personal from business use through a container approach, keeping the monitoring within the ICO's proportionality limits. And high-value equipment is handed over with a qualified eIDAS signature to secure the chain of custody.

## How it connects to your systems

The agent works through the HR, asset-management and device-management platforms companies already run. It connects via API to the major HCM and onboarding suites - SAP SuccessFactors, Workday, Oracle HCM, Personio and ADP - and to IT asset-management tools such as ServiceNow, Lansweeper and Snipe-IT. Device configuration runs through Microsoft Intune and Autopilot for Windows and Android, and Jamf for Apple hardware, with VMware Workspace ONE for mixed fleets. The agent passes work to the onboarding, offboarding, transfer, vendor-management and audit agents where their input is needed.

--- Executive Recruiting Agent ---
> C-suite search with say-on-pay: SOX 404, Dodd-Frank Section 953(b) CEO Pay Ratio, UK SM&CR + Companies Act 2006, EU Pay Transparency 2023/970 and AI Act Annex III high-risk recruitment.

Recruiting a senior executive across borders engages four bodies of law at once. In the US, SOX requires internal-control and financial certifications backed by criminal liability, and Dodd-Frank governs the pay: the CEO Pay Ratio disclosure, the Say-on-Pay vote, Compensation Committee independence and the clawback rule, with the executive tax provisions adding the Section 162(m) deduction limit, the Section 280G parachute-payment excise tax and Section 409A. In the UK, the Companies Act governs director removal and remuneration approval, the FCA's SM&CR makes reckless misconduct a criminal offence, and the Listing Rules set the disclosure. The EU adds SRD II, the Pay Transparency Directive and, crucially, the AI Act, which classifies executive recruiting as high-risk under Annex III with fines reaching 7 percent of global turnover. Pay equity sits across all three under Title VII, the UK Equality Act and the EU directives. For a large or upper-mid-market employer, a single search engages all four - on top of the cost of a failed hire.

## Coordination Fails Not Competence

This agent follows the [Decision Layer](/en/decision-layer/) principle: each decision is either rule-based, AI-assisted, or explicitly assigned to a human - and human assignment is heavy here.

A significant share of externally hired executives fail within the first two years. According to the Russell Reynolds Global CEO Turnover Index 2025, early CEO departures within the first 30 to 36 months rose by 79 percent year over year - with the second year in office being the most critical risk point, where CEOs are pushed out roughly three times as often as in the first year.

For a company with 2,000 employees that fills two to three C-Suite or divisional leadership positions per year, this means: statistically, at least one fails annually. The direct costs - severance, renewed search, headhunter fees - run to USD 220,000-440,000 per failed placement. The indirect costs - lost strategic continuity, unsettled leadership teams, departing high performers - are many times higher.

Executive recruiting is the only HR process where five independent parties must coordinate simultaneously - and none may know what the others are doing until necessary. The CHRO manages two or three search firms in parallel without them knowing about each other. The Board sets search parameters but only wants involvement at shortlist stage. Candidates are often in active employment and must not learn who else is in the process. Compliance must check sanctions lists and conflicts of interest without unnecessarily expanding the circle of people with access. The Audit, Compensation and Nomination Committees each have independent fiduciary duties. This works as long as an experienced CHRO holds the entire process in their head. It fails reliably when the coordinator changes, when the process stretches over six months, or when the Board requests a status update and nobody can present current state in defensible format.

## How the Agent Takes Over Orchestration

The Executive Recruiting Agent does not solve one party's problem. It solves the coordination problem between the Audit, Compensation and Nomination Committees, the Board, the search firms and the candidates, while satisfying the SOX, Dodd-Frank, SM&CR, AI-Act and pay-equity regimes at the same time. **Confidential search workflow with role-based access control.** The agent sets the confidentiality classification, establishes role-based access, opens an insider list under the UK and EU Market Abuse Regulations, and activates Regulation FD selective-disclosure controls. Each committee receives access scoped to its charter, and search firms receive an engagement letter with an off-limits clause and a replacement guarantee. **EU AI Act high-risk conformity built in.** Executive recruiting falls under Annex III regardless of seniority, so the agent operates with the Act's risk-management, transparency, human-oversight and Fundamental Rights Impact Assessment obligations, with the bias audit automated. **Pay equity and disparate-impact analysis.** Before the shortlist, the agent runs a regression against similarly situated peers, controlling for tenure, experience and role complexity; a selection rate below 0.80 under the four-fifths rule triggers a human escalation. This conforms to Title VII, the UK Equality Act and the EU Pay Transparency Directive.

## Why This Agent Is High-Risk Plus High-Stakes

Executive recruiting is the regulatory worst case. On one hand it is a high-risk system under Annex III of the EU AI Act, carrying the full obligation cascade - a risk-management system, technical documentation, transparency, human oversight and a fundamental rights impact assessment. On the other, senior executives are excluded from employee-representation bodies in most European jurisdictions, so the works council has no co-determination right over the hire.

That sounds like less effort. In practice, more. Without works-council oversight, internal quality assurance falls entirely on the Audit, Compensation and Nomination Committees and the Board. No body questions the selection criteria; no institutionalised countervoice highlights the blind spots. The documentation has to be more rigorous - not because the law demands it, but because executive decisions are challenged far more often than operational hires, through a negative proxy-adviser recommendation, a Say-on-Pay rejection, a shareholder lawsuit or a clawback under SEC Rule 10D-1.

The [Decision Layer](/en/decision-layer/) produces this documentation as a by-product of orchestrating the process. Every step, every decision-maker and every rationale is logged with timestamps and signatures - the AI-system logs the EU AI Act requires for a high-risk system, the records of processing under GDPR Article 30, and the company records the UK Companies Act requires.

## 6 Deterministic Procedural Decisions Plus 5 ML-Augmented Intent Indicators Plus 4 Mandatory Human Escalations

The agent breaks executive recruiting into fifteen micro-decisions: six rule-based, five AI-assisted intent indicators, and four mandatory human escalations to the committees and the Board. The four human decisions are the heart of the process: classifying the search trigger, defining the role profile with the Compensation Committee's preliminary approval, the final selection with sign-off from all three committees and the Board, and the contract negotiation with General Counsel and tax counsel. Escalation is mandatory where a parachute payment exceeds the safe-harbour multiple, where Section 409A exposure arises, where the four-fifths rule flags a pay-equity gap, or where a proxy adviser recommends against.

## Edge Cases with Cross-Border Plus Insider Trading Plus Section 280G Plus Pay Equity

The harder scenarios are handled explicitly. A cross-border executive move requires national tax and treaty analysis - the US substantial-presence test, the UK statutory residence test and the tie-breaker rules. An insider-trading blackout under Regulation FD and the UK and EU Market Abuse Regulations closes the window before financial results. A parachute payment above the safe-harbour multiple needs a shareholder-vote exception, and a gross-up, though common, is disfavoured by proxy advisers. And a pay-equity gap below the four-fifths threshold can draw an EEOC investigation, a Title VII class action and parallel state enforcement.

## How it connects to your systems

The agent works through the search firms, HR systems and board tools companies already use. It connects via API to the global retained search firms - Korn Ferry, Heidrick & Struggles, Russell Reynolds, Spencer Stuart and Egon Zehnder - and to the HCM suites that hold executive data, Workday, SAP SuccessFactors and Oracle. Compensation consultants and benchmarking databases feed the pay modelling, assessment platforms feed the evaluations, and proxy advisers inform the Say-on-Pay view. Confidential board materials flow through board-portal tools, and contracts are signed through eIDAS-compliant platforms or, in the US, under the ESIGN Act. The agent passes work to the compensation, succession, onboarding and audit agents where their input is needed.

--- HR Expense Self-Service Agent ---
> HR expense workflow for employee self-service: receipt OCR capture, multi-step manager hierarchy approval and mandatory field validation before finance handover.

Processing expenses across borders engages four bodies of law at once. US tax law sets the rules for each claim: the IRC Section 274 50 percent meal limitation and four-element substantiation requirements, the per-diem rates, and the accountable-plan test that decides whether a reimbursement is tax-free or taxable. The UK applies its own travel and mileage rules under ITEPA, including the approved mileage rates and the temporary-workplace test. The EU governs cross-border VAT recovery, with separate refund procedures for EU and non-EU businesses. And a financial-controls layer - SOX internal controls, the FCPA accounting provisions, the UK Bribery Act and the EU AI Act's deployer obligations for fraud detection - sits over all of it. For a large or upper-mid-market employer, a single expense submission can engage all four, against a backdrop where the average report already costs USD 58 to process and one in five contains an error.

## Coordination Fails Not Competence

This agent follows the [Decision Layer](/en/decision-layer/) principle: each decision is either rule-based, AI-assisted, or explicitly assigned to a human - and the human spot is reserved for the manager's business judgement.

GBTA Global Business Travel Association puts the average cost of processing a single expense report at USD 58 (EUR 53) and 20 minutes of handling time, with 19 percent of all submitted reports containing errors or missing information. For an organisation processing 500 reports per month, that translates to 95 correction cycles, nearly USD 5,000 (EUR 4,600) in avoidable costs - on top of USD 29,000 (EUR 26,500) for routine processing.

The problem is not employee negligence. A sales director submitting entertainment receipts after a client dinner does not know IRC Section 274 entertainment limitation 50 percent meal deduction, Section 274(d) four-element substantiation requirements, or whether the receipt requires an attendee list. A UK consultant claiming mileage does not check whether their journey qualifies as Section 337 travel in performance of duties or Section 339 ordinary commuting under the temporary workplace 24-month / 40 percent threshold. An EU manager submitting hotel receipts from Italy does not file an 8th Directive 79/1072/EEC cross-border VAT refund worth EUR 50-200 per trip. Employees answer these questions by instinct - and get it wrong 19 percent of the time.

## How the Agent Takes Over Orchestration

The Expense Processing Agent does not solve one party's problem. It solves the coordination problem between the traveller, the manager, accounts payable, the controller, internal audit and the tax authorities, while satisfying the US, UK and EU tax rules and the financial-controls regimes at the same time. **Receipt OCR with multi-currency capture.** The agent extracts vendor, amount, date, tax and currency from each receipt via AI OCR, converts foreign currency at the IAS 21 spot rate, and detects duplicate or altered receipts across employees and time periods. **Per-diem and mileage automation.** US per-diem rates are applied automatically by location and date, and the UK approved mileage rate - 45p for the first 10,000 business miles and 25p thereafter - is tracked against the annual threshold, with mileage allowance relief computed where the employer pays less. **AI fraud detection.** Expense fraud accounts for 21 percent of occupational fraud, with a median loss of USD 33,000. The agent detects duplicate receipts, altered images, outlier amounts, suspicious vendors and split transactions under the EU AI Act's Article 26 deployer obligations - with human oversight and transparency - even though expense processing is not itself a high-risk system.

## Why This Agent Is Operationally High-Stakes Despite Not Being Annex III

Expense processing is the regulatory hidden case. Volume is high - hundreds of receipts a month - and individual amounts are low, but the cumulative exposure is severe. A weak internal control over reimbursements is a SOX material weakness, and an inaccurate-books violation triggers FCPA accounting-provisions enforcement by the DOJ and SEC. The UK Bribery Act's corporate offence is strict liability, with an unlimited fine and only an adequate-procedures defence available. A substantiation failure under IRC Section 274(d) triggers an IRS audit with interest and accuracy penalties. And a failed accountable plan reclassifies every reimbursement as taxable compensation, subject to withholding and FICA.

That sounds like operational risk. In practice, governance risk. The Audit Committee, internal audit and the controller all depend on accurate books and records, segregation of duties, a clear approval matrix and an audit trail - and expense fraud takes a median of 18 months to detect. The [Decision Layer](/en/decision-layer/) produces this audit trail as a by-product of orchestrating the process. Every step, every decision-maker and every rationale is logged with timestamps and signatures - the AI-system logs the EU AI Act requires, the records of processing under GDPR Article 30, the company records under the UK Companies Act, and the seven-year tax records under the IRC.

## 7 Deterministic Procedural Decisions Plus 6 ML-Augmented Intent Indicators Plus 1 Mandatory Human Escalation

The agent breaks expense processing into fourteen micro-decisions: seven rule-based, six AI-assisted intent indicators, and one mandatory human escalation to the manager's approval. That human decision is the business-judgement call - that the expense is a legitimate business cost with a genuine business connection, within budget and authority - and a review of any flagged items. Escalation is mandatory where the fraud detection raises a signal, a policy violation exceeds the threshold, a receipt above a set value is missing, or a claim exceeds the per-diem rate.

## Edge Cases with Cross-Border Plus IRC Section 274 Plus EU VAT Refund Plus UK Bribery Act

The harder scenarios are handled explicitly. Cross-border travel needs national tax and treaty analysis - the US substantial-presence test, the UK statutory residence test and the tie-breaker rules under the double-taxation conventions. An EU cross-border VAT refund has minimum amounts, a filing deadline and a decision period that the agent tracks. Client entertainment with foreign nationals is held to the UK Bribery Act's reasonable, proportionate hospitality test. The IRC Section 274 meal limitation now sits alongside a full disallowance of entertainment. And a failed accountable plan reclassifies reimbursements as wages, with the reporting and employer FICA match that follow.

## How it connects to your systems

The agent works through the expense, corporate-card and travel platforms companies already run. It connects via API to the major expense suites - SAP Concur, Workday, Oracle and Coupa - and to Expensify, with their built-in OCR and fraud-detection tools. Smart corporate cards such as Spendesk, Pleo, Brex and Ramp feed transactions directly, business-travel platforms supply trip data, and dedicated audit AI adds a fraud layer. Mid-market HR and accounting systems are covered too. The agent passes work to the travel-expense, invoice, payroll, audit and tax agents where their input is needed.

--- HR Document Management Agent ---
> An electronic personnel file where every document carries its own retention clock and access trail, answering GDPR access and erasure requests on time.

Cross-jurisdictional HR document management sits under several parallel regimes at once, each with very different consequences. GDPR and the UK Data Protection Act govern storage limitation, the 30-day access request and the right to erasure. US recordkeeping law sets retention from one year (Title VII) to six (IRS, ERISA), with medical records segregated under HIPAA and ADA confidentiality. eIDAS, the ESIGN Act and UETA govern electronic signatures, and SOX Section 802 prohibits destroying records during a federal investigation. For a single HR document in a large or upper-mid-market employer, several of these obligations can apply at the same time - on top of a 30-day access-request clock, roughly 30,000 documents per 1,000 employees, and records still scattered across a legacy DMS, paper folders and a departed colleague's network drive.

## Three Hours Hunting for a 2019 Payroll-Tax File

This agent follows the [Decision Layer](/en/decision-layer/) principle: each decision is either rule-based, AI-assisted, or explicitly assigned to a human - and the human spots are reserved for content approval and deletion authorisation.

A US tax audit requests the payroll tax filing for an employee from 2019. HR searches the document management system, the paper archive, an old network drive. After three hours, the document is found - in a folder assigned to a colleague who left the company years ago. The auditor notes the incident. No fine this time, but a remark that will play out differently next time. The same scenario unfolds when an ICO Subject Access Request lands and the 30-day clock starts: across a legacy DMS, departed colleagues' network drives and paper folders, HR teams cannot reliably locate every document on one employee within the statutory deadline.

The problem is not employee negligence. It describes the normal state in HR departments that maintain personnel files across legacy structures: one DMS for contracts, a network drive for references, a paper folder for return-to-work documentation, an HRIS for onboarding records. Each system has its own logic, its own permissions, its own gaps. A UK HR generalist responding to an ICO Subject Access Request does not know whether the legacy DMS in archive mode contains documents pertaining to the requester. A US HR director facing an OFCCP audit does not know whether departed colleagues' network drives still hold Affirmative Action Plan supporting documentation, which must be kept for the life of the plan and one further year. An EU compliance officer fielding a Right to Erasure request does not know whether the paper archive in the basement contains records subject to Article 17 deletion.

## How the Agent Systematises Document Lifecycle

The HR Document Management Agent does not solve one party's problem. It solves the coordination problem between the HR generalist, line manager, DPO, Records Manager, Internal Audit and regulators while satisfying GDPR, US recordkeeping and discrimination law, eIDAS and the EU AI Act at the same time.

**AI document classification with metadata extraction.** The agent classifies incoming documents by content, structure and context - employment contract, offer letter, termination, payroll record, performance review, medical certificate, an I-9 or W-2, an EEO-1, an ADEA or Title VII charge, an access or erasure request - and extracts structured metadata through vector similarity and named-entity recognition. Identity resolution matches each document to the right personnel file across rehires, name changes and acquired entities.

**Centralised retention catalogue with jurisdiction-specific application.** Every classified document type receives its retention period from a maintainable catalogue: US tax records under IRS recordkeeping, discrimination records under Title VII (one year) and ADEA (three years), the GDPR storage-limitation principle for EU data, and the UK Employment Rights Act. The retention clock start - creation, last action, termination or benefit cessation - is applied automatically.

**Subject Access Request fulfilment under the 30-day deadline.** ICO figures show a 230 percent rise in access-request complaints from 2018 to 2024 and a median fulfilment cost of GBP 4,500 per request. The agent runs cross-system document discovery and named-entity recognition, proposes redaction of third-party data and identifies exemptions (legal privilege, management forecasts, negotiation records) within the statutory deadline.

**Qualified electronic signature with cross-border legal equivalence.** The agent applies an eIDAS qualified electronic signature for EU legal equivalence with a handwritten signature, ESIGN Act or UETA signatures for US transactions, and the UK eIDAS regime for the UK.

## Why This Agent Is Operationally High-Stakes Despite Not Being Annex III

HR document management does not fall under EU AI Act 2024/1689 Annex III high-risk classification because document operations do not directly affect employment relationship decisions. Volume is high (25,000-40,000 retention deadlines per 1,000 employees), individual stakes are low per document, but cumulative exposure is severe. An ICO access-request enforcement carries a GBP 17.5M fine and reputational damage. Storing data past its retention period breaches GDPR Article 5(1)(e), with fines up to 4 percent of global turnover. A CCPA right-to-delete failure exposes the employer to private statutory damages. A three-year ADEA retention failure removes the evidentiary basis for a disparate-impact defence, and destroying records during a federal investigation carries 20 years in prison under SOX Section 802.

That sounds like operational risk. In practice it is governance risk. The CHRO, DPO, Records Manager and Compliance Officer all depend on accurate classification, jurisdiction-specific retention, access control, access-request fulfilment and an audit trail. The [Decision Layer](/en/decision-layer/) produces that audit trail as a by-product: every document, classification, access event, retention assignment and deletion authorisation is logged with timestamps and signatures, under GDPR Article 30 and retained six years under the UK Companies Act and seven under SOX Section 802.

## Nine rule-based decisions, four ML indicators, two human escalations

The agent breaks the document lifecycle into 15 decisions: 9 rule-based, 4 ML-augmented indicators and 2 mandatory human escalations - manager content approval and Records Manager deletion authorisation. The two human decisions are the legal-sufficiency review at document approval and the four-eyes deletion authorisation by the Records Manager, DPO, General Counsel or Compliance Officer. Escalation is mandatory for a retention conflict, a litigation hold, a pending access request, a cross-jurisdictional template deviation or special-category data under GDPR Article 9.

## Edge cases: cross-border records, access requests, erasure, eIDAS signatures

Complex scenarios are documented explicitly. Cross-border record consolidation needs treaty analysis and residence determination across the US, UK and EU. An ICO access request must be answered within 30 days across a legacy DMS, a paper archive and a departed colleague's network drive through cross-system discovery. A Right to Erasure request runs through Article 17(3) exemption analysis - legal obligation, defence of legal claims, employment retention duties. A US-originated electronic signature may need reissuance through a qualified Trust Service Provider for EU enforceability. Medical records stay in a separate file under ADA confidentiality, HIPAA, GINA and FMLA.

## Integration with Workday, SAP SuccessFactors, Oracle, ServiceNow, OnBase, DocuWare and DocuSign

The agent connects through APIs to global document platforms, privacy-management tools, contract-lifecycle systems and qualified-signature providers: Workday HCM and Document Management; SAP SuccessFactors Document Management and Employee Central; Oracle HCM Cloud, Document Cloud and Records Management; ServiceNow HR Service Delivery; BambooHR and Personio for the mid-market; OnBase by Hyland, DocuWare, d.velop and ELO for ECM; Microsoft Dynamics 365 HR, SharePoint, Purview and the Microsoft 365 Compliance Center; OneTrust, BigID, Privacera and Collibra for privacy management; Box, Dropbox Business and Google Workspace; and DocuSign, Adobe Sign, Yousign, Ironclad and LinkSquares for signatures. It works alongside the Contract Offer Generation, Performance Review Documentation, Employee Data Management, Audit and Compliance, and Compliance Monitoring agents.

--- Interview Scheduling Agent ---
> Bias-audited interview scheduling: Title VII + EEOC Forbidden Questions, ADA Title I accommodation, EU AI Act Annex III(4)(a) + Pay Transparency 2023/970 and NYC Local Law 144 AEDT audit.

Cross-jurisdictional interview scheduling sits under several parallel regimes at once, each with very different consequences. US anti-discrimination law (Title VII, ADEA, ADA Title I) sets the EEOC forbidden-questions filter and the Four-Fifths Rule. State pay-transparency laws require a pay range in the posting or before the interview. NYC Local Law 144 mandates a bias audit for automated hiring tools, the territory of the Mobley v. Workday precedent. The UK Equality Act and GDPR add reasonable-adjustment and access duties, and the EU adds the Pay Transparency Directive and the EU AI Act, which classes recruitment AI as high-risk with fines up to EUR 35M or 7 percent of global turnover. For a single scheduling decision in a large or upper-mid-market employer, several of these can apply together - on top of recruiters losing about 35 percent of their time to calendar coordination and roughly 42 percent of applicants withdrawing over delay.

## The Problem Is Not the Interview - It Is the Week Before It

This agent follows the [Decision Layer](/en/decision-layer/) principle: each decision is either rule-based, AI-assisted, or explicitly assigned to a human - and the human spots are reserved for DPIA execution and EEO Officer final approval.

Recruiting teams in companies with 500 to 5,000 employees know the routine. A position is open. A strong candidate is waiting for an interview slot. And then the calendar Tetris begins. The recruiter emails the hiring manager, waits for a response, checks with the department head, receives a counter-proposal, discovers the candidate is unavailable on that day, and starts over. Five days later the slot is confirmed. Or the candidate has already signed elsewhere.

This is not an isolated incident. Current surveys show 35 percent of recruiter working time goes into scheduling coordination - not into conversations, not into candidate assessment, not into relationship building, but into logistics. For panel interviews with three to five participants, the problem compounds: when each participant has 60 percent of their calendar free, the statistical probability of everyone being available simultaneously falls below 8 percent per hourly slot. In practice, roughly three realistic options remain per week - before accounting for time zones, room availability, accommodation requirements, or visa-dependent participants.

The cost is asymmetric. 42 percent of applicants withdraw because scheduling takes too long. 61 percent of candidates accept the first offer they receive. Average cost per hire across Europe ranges from EUR 4,000 to EUR 6,000 (USD 4,400-6,600). Every day of delay raises the vacancy cost, the eventual replacement cost and the effort of re-engaging dropped candidates. A single short-notice cancellation in a panel interview triggers a chain reaction: four more calendars have to be re-coordinated, and rescheduling usually takes longer than the original planning because new blockers have built up.

## Why EU AI Act Annex III(4)(a) Reclassifies This as High-Risk

EU AI Act 2024/1689 Annex III(4)(a) classifies AI systems for recruitment or selection of natural persons including analysis and filtering of job applications and evaluation of candidates as high-risk. Interview scheduling AI falls within this scope because scheduling decisions form part of the recruitment pipeline - which slot proposal a candidate receives, which interviewers review the candidate, whether reasonable accommodation is provided, whether visa-dependent timing is honoured, all materially influence which candidates progress to offer.

Mobley v. Workday (2024, N.D. Cal.) confirmed this reading under US law. The class action established that algorithmic discrimination in recruitment AI is actionable under the disparate-impact framework of Title VII, ADEA and the ADA, and that the framework reaches across the recruitment pipeline - including scheduling decisions that disparately affect protected groups.

The compliance stakes change accordingly. The high-risk regime under Articles 9 to 15 covers risk management, data governance, technical documentation, record-keeping of the AI system logs, transparency, human oversight, accuracy and cybersecurity, with deployer obligations under Article 26 and a mandatory Fundamental Rights Impact Assessment before deployment under Article 27. Fines reach EUR 35M or 7 percent of global turnover for prohibited practices, and EUR 15M or 3 percent for high-risk non-compliance.

## How the Agent Systematises Title VII Compliant Scheduling

The Interview Scheduling Agent solves the coordination problem between the recruiter, hiring manager, candidate, EEO Officer, DPO and regulators while satisfying US anti-discrimination law, the GDPR DPIA, the EU AI Act high-risk regime, the UK Equality Act, the state pay-transparency laws and the NYC Local Law 144 bias audit at the same time.

**Multi-calendar conflict resolution with bias audit.** The agent reads calendars across Outlook, Google Calendar and Apple Calendar through their APIs, identifies open slots by vector matching, applies time-zone handling, balances interviewer load and integrates with Calendly, Cronofy, GoodTime Hire and ScheduleOnce. Selection-rate, impact-ratio and Four-Fifths Rule monitoring runs continuously under the EEOC Uniform Guidelines and the NYC Local Law 144 bias-audit requirement.

**Pay-range disclosure verification.** Every invitation cross-checks the applicable pay-range disclosure under the US state laws and the EU Pay Transparency Directive. A missing disclosure is flagged for human escalation before the invitation is sent.

**ADA Title I reasonable accommodation.** Each slot proposal verifies accommodation availability - interpreter, assistive technology, accessible venue, alternative format, extra time, a private quiet room, remote attendance - under ADA Title I, the UK Equality Act, the EU European Accessibility Act and WCAG 2.1 AA.

**EEOC forbidden-questions filter.** The interviewer brief applies the prohibited-inquiry filter (age, national origin, religion, marital status, pregnancy, disability, genetic information) and provides a structured-interview kit with a scorecard and competency-based questions under the EEOC Compliance Manual and the Title VII protected categories.

**Visa eligibility verification.** Right-to-work is checked before the interview offer: US Form I-9 and E-Verify, the UK Skilled Worker visa, and the EU Blue Card Directive with Member State work permits.

## Why This Agent Is Operationally High-Stakes

Interview scheduling looks like an administrative task. In reality it is the gateway between application and offer, and the legal exposure is cumulative. NYC Local Law 144 non-compliance carries USD 500 to 1,500 per violation, and a Title VII documentation gap opens the door to an EEOC class action, ADEA disparate-impact litigation and an ADA pre-employment inquiry claim. A missing pay-range disclosure breaches the state pay-transparency laws, with civil penalties of USD 100 to 10,000. High-risk non-compliance under the EU AI Act draws fines up to EUR 35M or 7 percent of global turnover, and a GDPR Article 35 DPIA failure draws ICO and EU fines.

That sounds like operational risk. In practice it is governance risk. The Talent Acquisition Director, EEO Officer, DPO and Compliance Officer all depend on an accurate bias audit, accommodation availability, pay-range disclosure, and DPIA and FRIA execution. The [Decision Layer](/en/decision-layer/) produces the audit trail as a by-product: every slot proposal, bias audit, accommodation request, pay-range disclosure and DPIA finding is logged with timestamps and signatures, under GDPR Article 30 and the EU AI Act Article 12, with US records kept one year under Title VII and three under ADEA.

## Eight rule-based decisions, four ML indicators, two human escalations

The agent breaks interview scheduling into 14 decisions: 8 rule-based, 4 ML-augmented indicators and 2 mandatory human escalations - the DPIA and the EEO Officer's final approval. The two human decisions are the DPIA and FRIA under GDPR Article 35 and EU AI Act Article 27, and the disparate-impact analysis at deployment. Escalation is mandatory for a missing pay-range disclosure, an accommodation gap, a visa risk, a bias indicator or a cross-jurisdictional template deviation.

## Edge cases: cross-border panels, visas, accommodation, pay range

Complex scenarios are documented. Cross-border panel interviews with US, UK and EU participants need time-zone handling, accommodation and visa verification before a sponsor-licence offer. NYC Local Law 144 requires a 10-business-day candidate notice with the option of an alternative selection process. ADA Title I accommodation may mean a sign language interpreter through the Teams or Zoom accessibility features. The EU Pay Transparency Directive transposes differently across Member States from 7 June 2026, and the UK Equality Act Section 60 restricts pre-employment health questions in the interviewer brief.

## Integration with Greenhouse, Lever, Workday, SAP, Calendly, GoodTime Hire, Microsoft and Google

The agent connects through APIs to recruiting platforms, calendar-AI schedulers and video conferencing: Greenhouse, Lever, Workday Recruiting and Interview Hub, SAP SuccessFactors Recruiting and Interview Central, iCIMS, Smartrecruiters, Workable, JazzHR and ServiceNow; Personio and BambooHR for the mid-market; ADP Workforce Now; Outlook, Teams and Bookings; Google Calendar and Meet; Zoom; and GoodTime Hire, Cronofy, ScheduleOnce, Calendly and Paradox Olivia for AI-driven scheduling. AI assessment tools such as HireVue, Pymetrics, Eightfold and Plum fall under NYC Local Law 144, EU AI Act Annex III(4)(a) and the Mobley v. Workday standard. It works alongside the Candidate Screening, Executive Recruiting, HR Document Management, Audit and Compliance, and Compliance Monitoring agents.

--- HR Vendor Invoice Agent ---
> HR vendor invoice workflow: recruiting (LinkedIn Recruiter, Indeed, headhunters), training providers and benefits brokers (401(k), health insurance) with personnel cost-center allocation.

## Manual Invoice Processing Costs EUR 10-15 per Transaction - and Forfeits Early Payment Discounts on Top

Processing a single incoming invoice manually costs between EUR 10 and EUR 15 (USD 11-16). At 500 invoices per week, that exceeds EUR 300,000 (USD 330,000) in process costs per year - before a single invoice is miscoded or an early payment discount is missed. According to Ardent Partners, only 21 percent of organisations without automation achieve acceptable discount capture rates. The remaining 79 percent pay full price because the invoice was still in the approval cycle when the discount window closed.

The real damage is not in the obvious processing costs. It is in the downstream effects: miscoded invoices generate correction entries, missing purchase order references trigger queries to procurement, late payments erode supplier terms. Each of these rework items consumes accounts payable capacity that is needed for period-end closing and analysis.

## Automated Three-Way Matching Reduces the Error Rate from 12% to Near Zero

The three-way match - invoice against purchase order against goods receipt - is the core of any proper invoice verification. Performed manually, it is error-prone: 10 to 15 percent of all invoices contain discrepancies in quantities, prices, or terms that a human reviewer under time pressure overlooks or misjudges. Automated systems perform this match in seconds, applying defined tolerance rules consistently to every single line item.

In concrete terms: an invoice for EUR 4,780 is checked against a purchase order of EUR 4,800. The 0.4 percent variance falls within the defined 2 percent tolerance - the agent approves. A second invoice deviates by 8 percent - the agent escalates to the responsible cost centre owner. No discretion, no inconsistency between clerks, no forgotten review on a Friday afternoon.

GL coding follows the same principle. Instead of a clerk looking up the account, a rule engine derives the coding from the purchase order. For invoices without a PO reference, the agent proposes a code based on historical booking patterns - the final confirmation stays with a human.

## The [Decision Layer](/en/decision-layer/) Separates Routine Approvals from Decisions Requiring Judgement

The Decision Layer decomposes the invoice process into individual decision steps and defines for each: human, rules engine, or AI agent. This decomposition is the difference between an automation that covers 60 percent of invoices and one that reaches 95 percent.

Data extraction - supplier, amount, invoice number, line items - is an AI task. Recognition rates for structured invoices (PDF, EDI, UBL, Peppol) range from 92 to 98 percent. Three-way matching and GL coding are rules-engine tasks with defined thresholds. Approval routing follows an authority matrix: invoices below EUR 5,000 (USD 5,500) to the team lead, above EUR 50,000 (USD 55,000) to senior management.

The human stays where law requires it - not because humans do it better. (UK: Making Tax Digital requirements apply; US: SOX compliance mandates segregation of duties.) Compliant bookkeeping requires the traceability of every decision. The agent logs every step with reasoning and timestamp. For tax-relevant discrepancies - such as an invoice without a valid VAT registration number - it escalates to a qualified reviewer rather than deciding itself.

## Invoice Processing Delivers the Fastest ROI Across the Entire Agent Portfolio

No other agent combines such high throughput with such low governance complexity. Invoice processing is not a high-risk system under the EU AI Act, requires no works council involvement, and does not process employee personal data. At the same time, a mid-sized company with 200 employees easily processes 300 to 800 invoices per month - each one a measurable cost saving.

The maths is straightforward: if process costs per invoice drop from EUR 12 to EUR 3 and discount capture rises from 20 percent to 75 percent, the agent pays for itself within months at 500 invoices per month. Highradius quantifies the average cost reduction through AP automation at 78 percent - from USD 13.54 to USD 2.98 per invoice.

The EU e-invoicing mandates amplify this effect. Since 2024-2025, B2B companies across the EU must be capable of receiving structured electronic invoices. Structured formats like Peppol and national e-invoicing standards deliver machine-readable data that further increases recognition rates and reduces manual re-entry to exceptional cases. Organisations that automate now use the regulatory shift as an accelerator rather than an additional burden.

--- Job Posting Agent ---
> Creates compliant job postings from requirement profiles and coordinates multi-channel publication. EU AI Act high-risk classification applies.

Three recruiters, three phrasings, three risk levels. That is the reality of job postings when twenty positions need to be filled simultaneously. One posting speaks of a "young, dynamic team" - an anti-discrimination violation that can cost up to three months' gross salary in compensation before a labour tribunal. The next omits the salary range that becomes mandatory under the EU Pay Transparency Directive by June 2026. The third is technically correct but so generic it disappears among thousands of listings. And all three were manually posted on three different channels because nobody knows which channel delivers the best return for which position.

This is not a quality problem of individual recruiters. It is a system problem.

## The Triple Risk of Every Single Posting

Job postings are the most vulnerable artefact in the entire recruiting process. They are simultaneously a legal document, a budget item, and a calling card - and in most organisations, none of these three is systematically managed.

**Legal risk: anti-discrimination law today, pay transparency tomorrow.** Every discriminatory phrase opens a liability case. "Native-level German" instead of "excellent command of German" - the difference is an anti-discrimination claim. With fifty open positions per year and an average of twenty applications per position, a single systematic phrasing error can trigger five-figure damages. From June 2026, the EU Pay Transparency Directive tightens requirements further: every job posting must include a concrete salary range. Omitting this information or handling it inconsistently risks sanctions and erodes candidate trust before the first conversation takes place. (US: state-level pay transparency laws in Colorado, New York, California, and Washington already mandate salary ranges in postings.)

**Cost problem: scatter without control.** The average cost per hire across Europe ranges from EUR 4,700 to EUR 5,500 (USD 5,200-6,000) - depending on source and industry. A significant portion flows into job postings running on the wrong channels. Single listings on job boards cost EUR 1,000 to EUR 1,300 per posting. Anyone running five channels simultaneously easily spends over EUR 5,000 per position on publishing alone - without knowing which channel delivers qualified applications and which only generates clicks.

**Quality problem: inconsistency as an employer brand killer.** When the same position appears on the market in three variants - once with bullet points, once as flowing text, once with outdated benefits - it signals organisational randomness. With an average vacancy duration of 164 days for specialist positions in parts of Europe, every day counts when a poorly worded posting attracts the wrong candidates or repels the right ones.

## Where Manual Processes Fail

The typical process chain for a job posting looks like this:

```
Hiring department         Recruiting              Approval
-----------------         ----------              --------
Requirement       ──>     Write text       ──>    Review
(often informal)          (varies by              (usually content
                           recruiter)              only, not legal)
                              |
                              v
                         Manual posting
                         (3-5 portals,
                          copy & paste)
```

Every arrow in this diagram is an error source. The requirement arrives as an unstructured email. The text is written under time pressure without consulting the employer brand guidelines. The review covers content but not legal compliance. The posting is published manually - and performance is never systematically evaluated.

## Three validation layers gate every posting before a recruiter sees it

A Job Posting Agent does not replace the recruiter. It replaces the randomness. From a structured requirement profile, a posting draft is generated that passes through three validation layers before a human sees it:

First layer: anti-discrimination compliance. Every formulation is checked against a compliance catalogue - gender-neutral language, no age discrimination, no indirect discrimination through language requirements. This is not a stylistic suggestion but a hard rule. What does not pass does not proceed.

Second layer: pay transparency. Salary ranges are drawn from the stored compensation bands and formatted to the prescribed standard. Consistent across all postings, all channels, all languages. No deviation, no omission.

Third layer: channel optimisation. Which portals deliver the best conversion rates for which position, region, and seniority level is decided by rules - not by gut feeling. Performance data flows back and improves channel selection for the next posting.

Only then does the recruiter see the draft. And reviews what only a human can review: does the tone fit? Does the description match the actual team culture? Are there technical nuances that only someone who has spoken with the hiring department knows?

## What This Means for Recruiting Leadership

The question is not whether job postings will be automated. The question is whether they will be treated as infrastructure - with governance, version control, and an Audit Trail - or whether they remain random products that become a liability at the next anti-discrimination claim or the first pay transparency audit.

The difference between an organisation that has solved this and one that has not shows itself not in the individual posting text. It shows itself in the ability to answer the question "How do you ensure all your job postings comply with the Pay Transparency Directive?" with a systemic response rather than "Each recruiter checks for themselves."

A [Decision Layer](/en/decision-layer/) makes every step traceable: which rules were applied, which checks passed or failed, who approved. Not as retrospective documentation, but as an integral part of the process. For a high-risk system under the EU AI Act - and that is precisely what an agent is that influences who sees job postings - this traceability is not optional. It is mandatory.

--- Learning Event Management Agent ---
> Coordinates training event logistics: room booking, trainer scheduling, participant management, and materials procurement - on time.

An L&D department coordinating 30 training events per month is not solving a learning problem. It is solving a logistics problem. Matching rooms to participant numbers, checking trainer availability, ordering materials on time, managing waitlists, processing cancellations, sending reminders, chasing evaluations. Each individual task is trivial. In aggregate, they consume 40 to 60 percent of operational L&D capacity - capacity that flows into neither programme design nor impact measurement.

And the problem does not improve as the organisation grows. It gets proportionally worse.

## Why Spreadsheets Are Not the Solution - They Are the Problem

In most organisations between 500 and 5,000 employees, event coordination looks like this: one Excel spreadsheet with dates, a second with trainer availability, a third with room bookings. Between them, emails, calendar invitations, and verbal agreements. This system has three structural weaknesses that no amount of better spreadsheet formatting can fix.

**First: multi-resource conflicts.** Every training event links at least four resources - room, trainer, participant group, materials. When a workshop for 20 needs a room with a projector but the only suitable room is booked for a leadership seminar that day, a rescheduling chain begins. Trainer calendars shift, participants must be re-invited, material orders no longer match. In a spreadsheet, you see the conflict only after it has occurred. Not before.

**Second: cancellation cascades.** The average cancellation rate for classroom training is 17 percent. For a workshop with 20 seats, that means three to four participants are typically missing. If a waitlist exists, someone must manually promote a replacement, notify the new participant, check that materials suffice, and inform the trainer about the changed group composition. If no waitlist exists, seats remain empty - and the cost per head rises because the room and trainer are already booked.

**Third: invisible costs.** A full-day in-person training for 20 participants costs between EUR 5,000 and EUR 15,000 (USD 5,500-16,500) - trainer, room, materials, participant working time included. At 30 events per month, the L&D department steers a six-figure monthly budget. Yet it often does not know which events were fully utilised, which are chronically underbooked, and which trainers receive the best evaluations. Because that data sits in different spreadsheets, and nobody has time to consolidate it.

## Seven of nine coordination steps run on deterministic rules, only two need agent logic

The key insight for training logistics: almost every coordination step follows clear rules. Format follows from training type and participant count. Reminders go out at fixed intervals. Cancellation rules depend on lead time. Waitlist promotions follow a defined order. Evaluations are sent the day after the event.

That is not coincidence. It is the reason this agent sits in the H2 quadrant: high transaction frequency, low decision complexity.

```
Step                        Decision-maker   Rationale
--------------------------  ---------------  ----------------------------------
Set event format            Rules engine     Type + capacity determine format
Identify trainer            Agent            Qualification match + calendar check
Assign room                 Agent            Capacity, equipment, availability
Invite participants         Rules engine     List from needs analysis or open enrolment
Order materials             Rules engine     Checklist by event type
Send reminders              Rules engine     7 days + 1 day before event
Promote from waitlist       Rules engine     Order of priority on cancellation
Trigger evaluation          Rules engine     Day after event
Process cancellation        Rules engine     Lead-time-dependent cancellation rules
```

Seven of nine steps are deterministic rules-engine decisions. Only two - trainer identification and room assignment - require agent logic that optimises multiple variables simultaneously: qualifications against availability, capacity against equipment. No step requires a human case-by-case decision.

## How L&D's Daily Work Changes

Once the systems are in place - LMS with event functionality, room management, trainer pool with calendar data - the operational work shifts at three points.

Planning time per event drops from hours to minutes. Instead of manually reconciling calendars, checking rooms, and contacting trainers, the L&D lead enters training type, target group, and timeframe. The agent delivers a complete proposal: trainer, room, time slot, materials list. If the proposal works, it is confirmed with one click. If not, constraints are adjusted and a new proposal is generated.

Cancellations and rescheduling lose their operational force. When a trainer cancels, the agent immediately searches for qualified replacements with available calendars. When participants cancel, the waitlist promotes automatically - including notification, material adjustment, and an updated participant list. The manual cascade of queries, counter-proposals, and revised invitations disappears.

The L&D department gains management data that did not previously exist. Utilisation rates by training format, cancellation patterns by department and day of week, trainer evaluations over time, average costs per participant and training type. Not as an elaborate quarterly report but as continuous reporting generated automatically from booking data. This data is the difference between an L&D department that administers events and one that actively manages its portfolio.

## The Infrastructure Effect

The event coordination engine - optimising rooms, people, materials, and schedules against availability - is not a one-off. The same mechanism that plans a workshop can orchestrate an onboarding event, schedule an assessment centre, or coordinate a company meeting. The waitlist management pattern becomes a building block for every agent with capacity-constrained resources.

And every booking, every cancellation, every rescheduling is logged in the Decision Log. The works council, which in many jurisdictions has information or co-determination rights over training delivery, sees not a summarised annual plan but the documented decision basis for every individual event. Transparency that makes co-determination simpler - because the data is already structured.

Anyone coordinating 30 events per month manually is administering. Anyone having them coordinated automatically is managing.

--- Learning Path Recommendation Agent ---
> Recommends individual learning paths based on skill profiles, career goals, and available content. Recommendations are non-binding.

## The Core Problem: Full Catalogues, Empty Classrooms

Most organisations do not have a supply deficit. They have a matching problem. A typical LMS in a mid-sized company contains several hundred courses, modules, and certification paths. At the same time, average completion rates for self-paced formats sit between 5 and 15 percent. 44 percent of companies are dissatisfied with their LMS, 37 percent are actively looking for alternatives. The learning catalogue grows; utilisation stagnates.

The bottleneck is not the content. The bottleneck is the question: which course delivers the greatest development impact for exactly this person in exactly this role?

Answering that question manually overwhelms any L&D department. A manager with twelve direct reports would need to reconcile skill profile, career goal, completed training, and available offerings per person. At 800 employees and 400 course offerings, that produces hundreds of thousands of possible combinations. No human navigates that reliably. The result: recommendations by intuition, development by scatter, budgets without proof of impact.

## What a Recommendation Agent Structurally Changes

A Learning Path Recommendation Agent does not solve this matching problem through more technology. It solves it through better decision architecture. The flow follows a clear chain:

```
Current profile     Target profile      Gap              Content
+----------+      +----------+      +----------+    +----------+
| Skills,  |      | Target   |      | Gap      |    | Matching |
| courses, |----->| role or  |----->| analysis |---->| against  |
| role     |      | next     |      | current  |    | catalogue|
|          |      | step     |      | vs.      |    |          |
+----------+      +----------+      | target   |    +----------+
     A                 H            +----------+         A
                                        A

A = Agent decides    H = Human decides
```

The decisive point: the target role stays with the human. The employee defines the direction in the development conversation. Everything before and after - profile analysis, target-role profile lookup, gap calculation, content filtering, format and provider selection, budget and time check, prioritisation - an agent can do faster, more completely, and more consistently than any manual search.

Personalised learning paths demonstrably increase completion rates by around 30 percent. Not because the content improves, but because the fit is right. Anyone who sees exactly the modules that address their specific skill gap invests learning time with visible return.

## Why This Is Especially Relevant for Mid-Sized Organisations

In organisations between 500 and 5,000 employees, two realities collide. On one hand: 81.8 percent of companies report that employees have too little time for professional development. On the other: 42.9 percent identify insufficient personalisation as the core problem of their L&D strategy.

Little time and poor hit rates - that is the toxic combination. If an employee has four hours per quarter for development, not a single one may be wasted on an irrelevant course. Every recommendation must land.

Large enterprises solve this with dedicated L&D teams that create individual development plans. Mid-sized organisations lack that capacity. Three talent development specialists for 2,000 employees cannot curate 2,000 individual learning paths. But an agent can - updated weekly, not once a year during the annual review.

## Traceability Instead of Black Box

A frequent concern with algorithmic recommendations: why this particular offering? The [Decision Layer](/en/decision-layer/) logs every decision step. Which data fed in, which weighting was applied, why Course A was prioritised over Course B. This transparency is not a regulatory obligation - learning path recommendations are not a high-risk system under the EU AI Act as long as they remain non-binding. But it is operationally decisive.

When a works council asks by which criteria recommendations are generated, there is a documented answer. When a manager questions a recommendation, the reasoning is available. And when an employee declines a recommendation, there are no consequences - it is a suggestion, not an assignment.

## The Infrastructure Effect

The recommendation framework does not operate in isolation. Profile analysis, gap calculation, and content matching form a reusable foundation. The same mechanism that recommends learning paths can assess career paths, identify succession candidates, or surface strategic skill gaps at the organisational level.

Every recommendation also generates data: which gaps occur repeatedly? Which offerings are accepted, which are ignored? Which departments develop faster than others? This data flows back into planning - not as a control instrument over individuals, but as a strategic steering measure for development investment.

The difference from a better LMS filter: a filter shows courses that might fit. A recommendation agent explains why exactly this course has the greatest leverage right now - and delivers the Audit Trail alongside it.

--- Leave of Absence Agent ---
> Processes parental leave, sabbatical, and special leave requests - verifies entitlements, calculates deadlines, and coordinates cover arrangements.

Every month, leave-of-absence requests land on desks that cannot wait. Parental leave under the EU Work-Life Balance Directive and national transposition laws. Carer's leave. Sabbaticals under company policy. Special leave under collective agreements. Four legal bases, four different deadline regimes, four sets of eligibility requirements - and every single request consumes HR capacity that is needed for strategic work.

The problem is not the individual request. The problem is their simultaneity.

## Why Right Now

Across the EU, parental leave take-up continues to rise as member states strengthen entitlements under the Work-Life Balance Directive (2019/1158). Shared parental leave, part-time parental leave combinations, and flexible start dates multiply the complexity per case. Several countries now accept parental leave applications by electronic means rather than requiring wet signatures - lowering the barrier for applicants but increasing the volume HR must process.

Meanwhile, carer's leave obligations are expanding. The Directive guarantees five working days of carer's leave per year. National implementations vary widely: some offer paid leave, others unpaid. Some require medical certification, others do not. Each variant has its own eligibility conditions, deadlines, and impacts on pay and social insurance.

Add the routine cases: special leave for relocation, marriage, bereavement. Accrued leave carry-over - across the EU, employees commonly start the new year with significant untaken days. Unpaid leave by individual agreement.

For HR, this produces a calculation with many unknowns. And the consequences of errors are not trivial: missed deadlines on parental leave applications shift the start date. Incorrect eligibility calculations for carer's leave create employment law risks. Missing cover arrangements hit operational delivery.

## What the Agent Changes

The [Decision Layer](/en/decision-layer/) separates two worlds in this process.

The first world is rules. Eligibility checks, deadline calculations, pay implications - these are deterministic operations. Whether someone is entitled to parental leave is defined by statute. Whether the application deadline has been met follows from the child's date of birth and the requested start date. How a six-month carer's leave affects occupational pension contributions is written in the pension scheme rules. These checks do not need a human. They need a rule engine that is correctly and completely configured.

The second world is decisions. Who takes over during the absence? Is a sabbatical approved when there is no statutory entitlement? How is the return structured after 14 months of parental leave? These questions require context, judgement, and accountability. They stay with the line manager and HR.

Between these two worlds lies a narrow strip where AI contributes: cover suggestions based on competency profiles and availability. Not a decision - a proposal that narrows the search space.

```
Request arrives
    |
    v
[Rules] Classification --> Parental | Carer's | Sabbatical | Special leave
    |
    v
[Rules] Eligibility check --> Statute | Collective agreement | Company policy
    |
    v
[Rules] Deadline calculation + Pay implications
    |
    v
[AI] Cover suggestion (skills + availability)
    |
    v
[Human] Confirm cover + Approve request
    |
    v
[Rules] Return planning + Automatic reminders
```

## What This Changes in Practice

The difference does not show in a single request. It shows in the aggregate over a year.

A company with 2,000 employees typically processes several hundred absence cases per year beyond regular annual leave: parental leave, carer's leave, special leave, sabbaticals, unpaid leave. Every case has a verification phase (eligibility, deadline, pay impact), a coordination phase (cover, handover), and a return phase (re-onboarding, system reactivation).

When the verification phase is automated, two things happen simultaneously: turnaround time drops because no request sits on a desk waiting. And the error rate drops because the rule engine misses no deadlines and confuses no legal bases.

Cover coordination no longer begins two weeks before the absence starts, but immediately upon receipt of the request. That gives teams time for orderly handovers instead of emergency workarounds.

The return is not forgotten. Four weeks before the documented return date, the line manager and HR receive a reminder. For longer absences, it includes a re-onboarding checklist tailored to the type and duration of absence.

## The Infrastructure Contribution

The eligibility engine built here for parental leave and carer's leave is reusable. The same logic - statutory entitlement, contractual entitlement, deadline calculation - is needed in probation management and contract generation. The cover suggestion pattern forms the foundation for workforce planning. The automated return planning is a template for every agent that triggers time-dependent follow-up actions.

That is the real point: every agent built cleanly generates infrastructure for the next.

--- Legal Contract Review Agent ---
> Analyses contracts against defined standards, identifies risk clauses, and prepares structured summaries for the legal department.

## Lawyers spend half their time on work that does not require legal expertise

According to Gartner, up to 50 percent of a legal department's capacity goes into contract management. Most of that is not legal thinking - it is reading, comparing, sorting. A service agreement is measured against the in-house clause template. An NDA is checked for deviations in term and jurisdiction. A master agreement is compared clause by clause against the standard.

This work demands diligence. But in most cases, it does not demand legal judgement. The question is not whether a lawyer can read a liability clause - it is whether a lawyer is the right person to confirm that it is identical to the standard version.

This is exactly where the automatable pattern sits: matching contract text against defined standards, extracting known risk clauses, and classifying by contract type. For a legal department reviewing 200 contracts per quarter, this is the difference between a team that reacts and a team that shapes.

## 92 minutes per contract is not a quality standard - it is a bottleneck

The average review time for a standard contract is 92 minutes. For an NDA - the simplest contract type - current AI systems complete the same comparison in 26 seconds at 94 percent accuracy ([Sirion, 2026](https://www.sirion.ai/library/contract-insights/ai-playbook-redlining-vs-manual-contract-review/)). The missing 6 percent is not an argument against automation. It is an argument for the right split: the agent reviews standard clauses, the lawyer reviews deviations.

Consider a typical week in a legal department handling procurement contracts. Monday brings three new vendor agreements. Wednesday, a renewed master agreement with modified liability terms. Friday, an NDA for a due-diligence exercise. Each contract goes through the same process: identify type, compare standard clauses, flag deviations, assess risk. Only then does the real legal work begin - judging whether a deviation is acceptable or must be renegotiated.

The Legal Contract Review Agent takes over the first six steps of this process. The final three - risk assessment by the lawyer, negotiation recommendation, and approval - stay where the law requires them: with humans.

## Six decision steps automated, three stay with the lawyer

The [Decision Layer](/en/decision-layer/) decomposes every contract review process into individual decision steps and defines for each step: human, rules engine, or AI. For contract analysis, this decomposition produces a clear picture.

The automatable steps follow a pattern: they compare the actual state against the target state. Is this contract an NDA or a service agreement? Does the liability clause match the standard, or does it deviate? Does the contract contain a penalty clause? These questions can be answered reliably by a well-maintained clause library.

The human steps follow a different pattern: they require judgement under uncertainty. Is the deviating liability cap acceptable for this specific vendor? Does the business value of the contract outweigh the risk of a missing warranty clause? Can the contract be approved under these terms? These are decisions that need context the agent does not have - business relationship, negotiation history, strategic priorities.

The governance score for this agent sits at 55-62, noticeably higher than pure process automations. That reflects the fact that contract analysis operates closer to legally significant decisions than, say, payroll (UK: PAYE) or time tracking. The agent is allowed to analyse and flag. It is not allowed to judge or decide.

## The clause library determines success - and it does not exist yet

This is a H3 agent. That means higher complexity and lower readiness than established process automations. Current AI systems lose 10 to 20 percent accuracy on contracts exceeding 1,000 characters of prompt length ([WorldCC / KPMG, 2025](https://kpmg.com/us/en/articles/2025/agentic-ai-in-clm-balancing-human-and-machine-expertise.html)). For a 30-page master agreement, that matters.

The most important prerequisite is not technology - it is a maintained clause library with company standards for each contract type. Without this reference point, the agent has nothing to compare against. The library defines what "standard" means. Only then can the agent identify what counts as a "deviation".

Organisations that already run a Contract Lifecycle Management system and have documented their standard clauses can deploy this agent faster. Organisations without that foundation build it while building the agent - which slows the rollout but creates independent value. A structured clause library improves contract review even without an agent, because it establishes a consistent benchmark for the first time.

The honest timeline: not productive next month, but after the clause library is built and a calibration phase with the legal department has run. The payoff after that: lawyers who spend their time on the cases where legal judgement is actually needed.

--- Merit-Cycle-Governance Agent ---
> Annual merit cycle with bias audit: Title VII/Equal Pay Act, EU AI Act Annex III(4)(b) high-risk compensation, EU Pay Transparency 2023/970 5% gap threshold and 25+ US Pay Transparency Laws.

## Five months from budget approval to first payout

This agent follows the [Decision Layer](/en/decision-layer/) principle: each decision is either rule-based, AI-assisted, or explicitly assigned to a human. It is classified per [EU AI Act 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) Annex III(4)(b) as high-risk system and is therefore subject to enhanced obligations on Risk Management System, Data Governance, Transparency, Human Oversight, and Bias-Audit from 2.8.2026.

A typical merit cycle takes five months. Not because the decisions are difficult, but because the process is. Budget approval in September. Data preparation in October. Spreadsheet distribution to 30, 50, 80 managers in November. Returns over weeks. Calibration rounds in January. Corrections. Payroll handover in February. First payout earliest in March.

The problem is not the time it takes. It is what happens between the steps - or rather what does not: systematic equity analysis, documentable rationales for the reversed burden of proof under Title VII and the Equal Pay Act, Compa-Ratio validation, and consistency across business units and hierarchy levels.

## What stays invisible in spreadsheet rounds

When 60 managers fill in compensation proposals in parallel Excel files, no consistent process emerges. A collection of individual assessments emerges that no one can aggregate, validate, or compare in real time. The typical consequences:

**Band violations without warning.** A manager recommends an increase that pushes the employee above the upper end of the compensation band. In the spreadsheet, this only becomes apparent when Comp&Ben manually reviews the file - often weeks later, often not at all. Companies regularly report that employees are paid outside their defined salary bands without it being systematically noticed.

**Equity gaps stay hidden.** When 60 Excel files are filled in parallel, a calibration round in January does not notice that female sales managers systematically receive 4 percent lower adjustments than male - or that the pay gap between 50+ and mid-career employees in a certain function is 7 percent.

**A reversed burden of proof with no audit trail.** In a lawsuit the burden of proof reverses under Title VII, the Equal Pay Act, ADEA and the UK Equality Act: if employees can show indicators of discrimination - a statistical anomaly, a missing rationale, suspicious timing - it falls to the employer to prove none occurred. Without a documented, reproducible rationale for each adjustment, that burden is practically unmeetable, as the Mobley v. Workday class action illustrates.

## The sanctions stack up: Equal Pay, EU AI Act, GDPR, Mobley v. Workday

A Title VII or Equal Pay Act class action carries back pay, double liquidated damages for a willful violation and attorney fees per employee where indicators of compensation discrimination exist - and with multiple plaintiffs from one comparator group it can quickly reach seven figures in USD. The Lilly Ledbetter Act restarts the limitation period with each new pay event. The EU AI Act adds fines up to EUR 35M or 7 percent of global group revenue, and GDPR up to 4 percent or EUR 20M. In the UK, Section 78 brings EHRC enforcement and public disclosure at Companies House, and a CSRD ESRS S1-10 breach leads to an auditor finding and board liability under SOX 404. Mobley v. Workday shapes the regulator line and auditor standards.

## EU Pay Transparency Directive 2023/970 as compliance pressure

Effective 6 June 2026 [EU Pay Transparency Directive 2023/970](https://eur-lex.europa.eu/eli/dir/2023/970/oj) (national transposition) obliges documentable rationales for each adjustment. At gender pay gap deviations of 5 percent unexplained pay gap (Article 9), Joint Pay Assessment obligations and remediation procedures within 6 months (Article 10) apply. Employees receive right of access to comparator group median pay (Article 7), in job postings the pay-range disclosure is mandatory (Article 6), and the question of compensation history from previous employers is prohibited (Article 5).

The burden of proof in pay discrimination claims reverses (Article 18): It is up to the employer to show no discrimination occurred. Reporting obligations gender pay gap stagger from 250 employees (from 2027) to 100 employees (from 2031). Sanctions: minimum standards Article 20 with fines and damages.

More than 25 US state and city pay-transparency laws run alongside the EU rules - among them California SB 1162, Colorado's Equal Pay for Equal Work Act, the New York State law, NYC Local Law 32 and the Washington, Connecticut, Maryland, Hawaii and Illinois statutes - each requiring a good-faith pay range in job postings. In the UK, Section 78 makes gender pay gap reporting mandatory each year for employers over 250, by 4 April in the private sector, under EHRC enforcement.

## EU AI Act Annex III(4)(b): high-risk classification, DPIA and FRIA

The Merit-Cycle-Governance Agent falls under EU AI Act Annex III(4)(b) as a high-risk system for HR compensation decisions. The obligations apply from 2 August 2026 under current law (provisionally postponed to 2 December 2027 under the Digital Omnibus of 7 May 2026, formal adoption still pending) and include:

- **Article 9 risk-management system**: identifying, analysing and mitigating bias risks across the gender, age, ethnicity and disability pay gaps
- **Article 10 data governance**: training-data quality, bias detection, demographic-parity and equal-opportunity testing
- **Article 13 transparency**: documentation of how the system works, its accuracy and robustness, and the bias-audit results
- **Article 14 human oversight**: a person in the loop on every recommendation
- **Article 26 deployer obligations**: the DPIA, consultation with the supervisory authority, post-market monitoring and incident reporting
- **Article 27 Fundamental Rights Impact Assessment**: before deployment, in consultation with the EEOC, the DPO and the works council or union

Fines run to EUR 35M or 7 percent of global group revenue, and GDPR Article 35 separately requires a DPIA for systematic automated assessment with significant impact. The [Mobley v. Workday class action](https://www.courtlistener.com/docket/67476007/mobley-v-workday-inc/) (N.D. Cal., 2023) - alleging AI bias in HR software against candidates over 40 - serves as the US precedent and shapes the EU regulator line.

## Equity audit as advantage over manual process

The Equity Analysis Engine checks statistically across all protected characteristics under Title VII, the Equal Pay Act, ADEA, the UK Equality Act and GDPR Article 9. For each one it measures demographic parity (equal adjustment frequency across groups) and equal opportunity (equal adjustment magnitude for comparable performance). A statistically significant deviation escalates automatically to the HR Lead, with a Title VII and Equal Pay Act-compliant audit trail.

This is not just compliance protection: studies (e.g., McKinsey Diversity Wins, BCG Closing the Gap, Gallup Pay Equity Reports) show 4-6 percent equity gaps in mid-market and 2-4 percent in S&P 500 companies that remain manually undetected. The agent makes them visible and creates the data foundation for targeted correction adjustments.

## Cross-reference to Compensation-Benchmarking, Performance-Review, and Payroll

The Merit-Cycle-Governance Agent sits in a pipeline of specialised HR agents. The [Compensation-Benchmarking Agent](/en/hr-agent-catalog/compensation-benchmarking-agent/) provides the compensation bands, Compa-Ratios and pay-range data. The Performance-Review Agent provides the performance ratings used for eligibility. The [Payroll-Calculation Agent](/en/hr-agent-catalog/payroll-calculation-agent/) receives approved adjustments with the correct effective date. The [Payroll-Reporting Agent](/en/hr-agent-catalog/payroll-reporting-agent/) generates the CSRD ESRS S1-10, SEC Pay Ratio and UK Section 78 reports. The [HR-Document-Management Agent](/en/hr-agent-catalog/hr-document-management-agent/) archives the adjustment rationales for seven years under IRS recordkeeping. The [Audit-Compliance Agent](/en/hr-agent-catalog/audit-compliance-agent/) verifies EU AI Act Article 26 deployer obligations and DPIA consistency, and the [Interview-Scheduling Agent](/en/hr-agent-catalog/interview-scheduling-agent/) applies the pay-range disclosure in job postings under the EU Pay Transparency Directive and the US state laws.

## At a glance

- **Classification**: EU AI Act 2024/1689 Annex III(4)(b) high-risk HR Compensation Decisions from 2.8.2026
- **Compliance anchors**: Title VII, the Equal Pay Act, ADEA, the UK Equality Act with Section 78 reporting, the EU Pay Transparency Directive, GDPR Articles 22, 35 and 88, CSRD ESRS S1-10, the SEC Pay Ratio Disclosure, and the US state pay-transparency laws
- **Co-determination**: mandatory where works councils or unions apply, for the introduction of the IT system
- **Equity threshold**: an unexplained gender pay gap above 5 percent (EU Pay Transparency Directive Article 9) triggers a Joint Pay Assessment and a six-month remediation duty (Article 10)
- **Fines**: up to EUR 35M or 7 percent of global group revenue under the EU AI Act, up to 4 percent or EUR 20M under GDPR, alongside Title VII and Equal Pay Act class-action damages and UK Section 78 enforcement
- **Audit obligation**: DPIA, FRIA and a quarterly bias audit, with CSRD auditor verification from 250 employees, the SEC annual filing for US public companies, and the UK Section 78 annual report
- **US precedent**: Mobley v. Workday Northern District California 2023 class action AI bias HR software

### Decision-Maker Distribution Merit-Cycle-Governance

| Step | Decider | Rationale |
|------|---------|-----------|
| Budget setting | H | Executive leadership strategy, with CSRD and SEC preparation |
| Eligibility check | R | Tenure, performance and suspensions, rule-based |
| Benchmark provision | R | Compa-Ratio calculation, deterministic |
| Manager recommendation | H | Individual performance and retention risk |
| Pay-band validation | R | Min-max pay range, automatic |
| Budget compliance | R | Real-time tracking, deterministic |
| Equity analysis | A | ML statistical bias detection with human validation |
| Equity escalation | R | Threshold above 5 percent, EU Pay Transparency Directive |
| Approval workflow | R | Approval matrix by hierarchy and Compa-Ratio position |
| HR Lead approval | H | Final approval, Title VII-compliant |
| GDPR information | R | Articles 13, 14 and 22(3) standard workflow |
| Compensation conversation | H | Personal conversation, relational dimension |
| Payroll handover | R | Effective date and tax correction, deterministic |
| CSRD/SEC reporting | R | ESRS S1-10 and Pay Ratio Disclosure, deterministic |

--- Offboarding Agent ---
> Orchestrates the exit process: knowledge transfer, IT returns, system deactivation, reference letters - no step forgotten.

This agent follows the [Decision Layer](/en/decision-layer/) principle: each decision is either rule-based, AI-assisted, or explicitly assigned to a human.

A significant share of former employees retain active access credentials after exit - in many organisations, these inactive accounts reach measurable percentages of all users in the identity provider. A sizeable fraction of accounts marked inactive still hold live permissions in core applications. And many organisations take longer than three days to revoke all system access after a departure. Some never fully manage it.

This is not a fringe problem. It is the admission ticket for any attacker who prefers using valid credentials to bypassing firewalls.

## Five streams, no conductor

An offboarding process touches at least five areas of responsibility simultaneously. None of them waits for the others. All have their own deadlines, their own systems, and their own blind spots.

```
Termination / separation agreement
    |
    +-- HR: close personnel file, notifications, reference letter
    +-- IT: return hardware, revoke access, release licences
    +-- Business unit: knowledge transfer, project handover
    +-- Manager: exit conversation, document feedback
    +-- Data protection: start retention clocks, check preservation rules
    |
Last working day (everything must be done)
    |
Post-exit phase: reference letter, data deletion, boomerang tracking
```

In practice, HR coordinates this via a checklist and reminder emails. At three departures per quarter, that works. At thirty, it collapses - quietly. No one notices the VPN access that stays active for another two months. No one asks about the SharePoint folder with customer data that the former employee can still reach.

## Why offboarding costs more than it looks

The visible costs of a poorly managed exit are manageable: a forgotten laptop, a delayed deregistration. The invisible ones are not.

A substantial share of HR leaders estimate that inconsistent offboarding costs their company annual six-figure sums - through knowledge loss, security risk, and replacement effort. Only a minority of organisations ensure an adequate knowledge transfer during the exit. A large share of a role's specialist knowledge exists only in the head of the incumbent and cannot be easily replaced by a successor.

Three cost drivers stand out:

**Security risk.** Orphaned accounts are the simplest attack vector. No brute force, no phishing needed - the credentials already exist. In a world where the average organisation runs 275 SaaS applications, manual deprovisioning is an illusion.

**Knowledge loss.** The cost of losing a subject matter expert can reach twenty times normal recruiting and onboarding costs. Not because the person is irreplaceable, but because their undocumented knowledge is.

**Boomerang potential.** 35 percent of all new hires are now returning employees. Their retention rate is 44 percent higher than that of entirely new hires. A chaotic exit destroys exactly the relationship that would have enabled a rehire.

## Three time windows, three different problems

Offboarding is not a single event. It breaks into three phases with fundamentally different requirements.

**Before the last day:** organise knowledge transfer, hand over projects, brief the successor. This is where the manager decides which knowledge is critical - no rule set can automate that because it requires context about team dynamics and project dependencies.

**On the last day:** return hardware, revoke access, collect the badge. This is entirely rule-based. Which devices must come back is in the provisioning list from onboarding. Which accesses get disabled follows from the permission profile. Timing and order follow a revocation plan - critical systems immediately, email forwarding after a defined transition period.

**After the exit:** issue the reference letter, meet data retention deadlines, finalise payroll. The right to a reference letter does not lapse for years, but contractual exclusion periods may kick in much sooner. GDPR deletion obligations run alongside commercial and tax retention periods of six to ten years - a tension that regularly leads to breaches without clear orchestration.

```
Phase           Typical failure                    Consequence
──────────────  ──────────────────────────────     ────────────────────────
Before exit     No knowledge transfer planned      42% of expert knowledge lost
Last day        VPN / cloud access not revoked     Security incident
Post-exit       Reference letter after 4 months    Legal threat
Post-exit       GDPR deletion forgotten            Fine up to EUR 20m (USD 22m)
```

## What the agent actually orchestrates

The Offboarding Agent is the mirror of the Onboarding Workflow Agent. Same orchestration engine, same architecture of templates, task distribution, and deadline tracking - only running in reverse.

As soon as an exit is recorded in the HR system, three things happen in parallel: the rule set determines the offboarding type from the reason for leaving - employer termination, voluntary resignation, separation agreement, and retirement each produce different checklists. The full task list is generated from the template and routed to the responsible parties. From that moment on, the agent tracks deadlines and escalates on delays.

The decision architecture is deliberately restrictive. Of ten process steps, six are rule-based, one is AI-supported, and three stay with humans. AI is used only for the reference letter draft - generating text from role description, tenure, and performance rating. Whether the letter is released, whether the exit interview happens, and which knowledge counts as critical - those decisions stay with the manager and HR personally.

## GDPR deletion as an architectural problem

Most organisations treat deletion obligations as a task for the data protection officer. That works as long as someone remembers. With 50 exits a year across systems without centralised deletion routines, eventually no one remembers.

The tension is real: payroll records must be kept for six to ten years. Application documents must be deleted within six months at the latest. Personnel files fall under multi-year limitation periods for employment claims. For breaches, European data protection authorities can impose fines from EUR 10,000 to EUR 50,000 (USD 10,900 to USD 54,500) per case - open-ended up to EUR 20 million (USD 22 million) or 4 percent of global annual revenue.

An offboarding agent does not solve this through deletion but through deadline management. Every record gets a retention category with a concrete deletion date at the point of exit. The agent monitors the deadlines and escalates when one is approaching. The actual deletion remains a manual step with four-eyes principle - but the reminder is systematic rather than accidental.

## Infrastructure value: the onboarding engine in reverse

The strongest economic lever of this agent is not in process automation itself, but in reuse. The checklist engine, task distribution, deadline tracking, and escalation logic are identical to the Onboarding Workflow Agent. Whoever built one gets the other as a configuration rather than a project.

The access revocation logic also builds the foundation for access management across all lifecycle phases - from transfer to parental leave to rehire. And the reference letter generation pattern is reused by the HR Document Management Agent for confirmations, statements, and reference letters.

Every offboarding run produces a complete audit trail: which task was completed when, which deadline was met or missed, who escalated. From 100 documented runs emerges a picture of where the process systematically stalls - not because someone requested a report, but because the architecture produces this data as a by-product. (US: state-specific final-pay timelines in California, Massachusetts, and New York create additional triggers the agent handles via jurisdiction-specific rules.)

--- Onboarding Workflow Agent ---
> Orchestrates onboarding from offer acceptance to day one: IT setup, compliance training, buddy assignment - ensuring no step is missed.

## One in three new hires leaves within 90 days

This agent follows the [Decision Layer](/en/decision-layer/) principle: each decision is either rule-based, AI-assisted, or explicitly assigned to a human.

One in three new hires leaves the company within the first 90 days. Not because of the job. Not because of the salary. Because on day one, the laptop is missing, the accounts are not set up, and no one knows who was supposed to handle the safety briefing. Surveys of European employers show more than a third record resignations before day one. The average cost per failed onboarding sits around EUR 15,000 (USD 16,400) - not counting the lost productivity of the rest of the team.

The problem is not a lack of knowledge about what needs to be done. The problem is that no one is conducting.

## Eight departments, no conductor

A single onboarding process involves at least eight organisational units: HR creates the contract, IT provisions hardware and access, Facility Management prepares the workstation, the business unit plans the ramp-up, Compliance assembles mandatory training, the manager selects a buddy, Finance sets up payroll, and reception needs the name for the badge.

```
Signed offer
    |
    +-- HR: personnel file, notifications, welcome package
    +-- IT: hardware, access, email, VPN
    +-- Facility: workstation, key, parking
    +-- Business unit: ramp-up plan, buddy selection
    +-- Compliance: mandatory training, data protection, safety
    +-- Finance: payroll, expense setup
    +-- Manager: confirm buddy, set goals
    +-- Reception: badge, access card
    |
First working day (everything must be ready)
```

Each of these streams has its own deadlines, its own systems, and its own contacts. None of them reliably knows where the others stand. HR usually coordinates it via an Excel checklist and reminder emails - a method that works at five hires a month but collapses at fifty per quarter.

## Why checklists do not scale

A checklist says: "order IT equipment." It does not say which equipment is needed for a Sales Lead in Munich versus a developer in Wroclaw. It does not say that the order needs three weeks of lead time and therefore has to go out on the day of the offer acceptance - not when HR finishes the personnel file. It does not say who escalates if no laptop arrives after ten days.

The real complexity sits in the configuration: every combination of role, location, unit, and contract type produces a different onboarding path. A company with three sites, four business units, and ten role types has, in theory, 120 different onboarding variants. In practice, maybe five exist as documented processes - the rest is improvised.

## The agent orchestrates 14 decision steps from signed offer to 30-day feedback check

The Onboarding Workflow Agent is not a chatbot that answers questions. It is an orchestration engine that runs a defined process from the signed offer to the 30-day feedback check.

As soon as a contract is signed, three things happen in parallel: the agent determines the onboarding type through a rule set, generates the full checklist from the matching template, and distributes each task to the responsible party with a concrete deadline. From that moment on, it monitors progress. Not passively like a dashboard, but actively - with reminders as deadlines approach and escalations when they pass.

The decision architecture is deliberately conservative. Of 14 decision steps in the process, nine are rule-based, three are AI-supported, and two stay with humans. AI is used only where patterns must be detected - for example in buddy matching or personalising the welcome package. Whether a buddy is accepted and whether onboarding ultimately counts as successful is decided by the manager in person.

## The hidden costs of improvisation

Early attrition is the visible metric. The less visible one: time to productivity. Studies show new hires need 8 to 12 months to reach full productivity. With chaotic onboarding, that phase stretches significantly. If someone waits three days for access in the first week, those are not just three lost days - they are three days in which a wrong first impression hardens.

90 percent of new hires decide within the first 100 days whether they stay or go. That is not a guess - it is the central finding of current onboarding research. The decision does not fall in a single big moment but in small ones: does my email work? Does my team know I am coming? Has anyone put thought into my first day?

## Infrastructure value beyond onboarding

The orchestration engine built by the onboarding agent is not a one-time investment. The same architecture of checklist templates, task distribution, deadline tracking, and escalation logic is reused directly by the Transfer, Offboarding, and Probation agents. The permission profile framework forms the foundation for access management across all lifecycle phases.

More importantly: every onboarding run produces a complete audit trail. Which task was done when, who escalated, where delays happened. Over time, this data builds a picture of where the process systematically stalls - not based on gut feel, but on 200 documented runs.

## When the agent pays off

The arithmetic is simple. At 100 hires per year and a 30 percent early-attrition rate, a company loses 30 employees during probation. At EUR 15,000 (USD 16,400) per case, that is EUR 450,000 (USD 490,500). If structured onboarding improves retention by 44 percent - a conservative estimate based on SHRM data - early attrition drops to 17 cases. The savings: just under EUR 200,000 (USD 218,000) per year.

Not counted: the higher productivity of the 83 people who stay and become effective faster. Not counted: the relief for HR, which no longer coordinates 100 processes through email chains. Not counted: the reputation effect when new hires tell others about a professional onboarding. (UK: similar dynamics apply under employment law, where the probation-period decision window frames the same economic lever.)

--- Payroll Accounting Agent ---
> Payroll-to-GL posting: SOX 404 ICFR, GAAP ASC 715, IFRS 19/IAS 19, 7-year IRS retention and ledger reconciliation - Workday/SAP HCM integration without manual journal entry.

Posting payroll to the general ledger across jurisdictions sits under several parallel regimes at once. US tax law (IRS Section 6001) sets recordkeeping and filing duties; SOX Section 404 governs internal controls over financial reporting; GAAP, UK FRS and IFRS govern how compensation is recognised; the UK Companies Act, HMRC PAYE and the Pensions Act add their own. For a Fortune 500, FTSE 350 or upper-mid-market employer of 5,000 people, every payroll cycle produces roughly 60,000 transactions and 720,000 ledger line items - and a single control failure can mean a material-weakness disclosure, an auditor adverse opinion and a restatement, with criminal exposure under SOX Section 906 of up to USD 5M and 25 years in prison.

## From payroll to journal entry - 80 percent automatic

This agent follows the [Decision Layer](/en/decision-layer/) principle: each decision is either rule-based, AI-assisted, or explicitly human - and the human spots are reserved for management certification under SOX Section 302 and Section 906 and for the auditor walkthrough.

A US Fortune 500 controller closes July payroll. Net pay computed, taxes filed, employees paid. Then comes the second job: posting the results to the general ledger - wages to debit, tax liability to credit, accrued vacation, bonus and pension, employer taxes, stock compensation under ASC 718, cost centre by department, segment by geography. Twelve hours of manual Excel, import files and GL uploads. The auditor will request walkthrough documentation in October. The same scenario unfolds when a UK plc closes monthly payroll: PAYE RTI submitted, NIC calculated, but the ledger posting still demands manual mapping under the Companies Act and IAS 19. Eighty percent of these postings are deterministic - rule-based - yet most organisations treat them as discretionary work.

The problem is not controller negligence. It is the normal state in finance departments maintaining payroll-to-GL posting across legacy structures: one ERP for general ledger, a payroll system for gross-to-net, a spreadsheet for accruals, a separate Black-Scholes calculator, an email thread for approval. A US controller facing PCAOB walkthrough does not know whether Q1 accrual was approved by the prior controller. A UK CAO facing ICAEW review does not know whether cost centre allocation was consistent. An EU IAS 19 reporter does not know whether PUCM reconciles to GL pension liability.

## SOX 404 ICFR effectiveness as auditor attestation

The agent solves the coordination problem between the Controller, Chief Accounting Officer, Internal Audit, External Auditor and Payroll Director while satisfying IRS, SOX, GAAP, IFRS and the UK regimes at the same time.

**Deterministic chart-of-accounts mapping.** Every payroll element maps to the correct ledger account through a maintainable chart of accounts - gross wages, employer taxes, pension, benefits, workers' comp and accruals. Assignment is jurisdiction-specific and subject to auditor walkthrough.

**Cost-centre allocation.** Compensation cost is allocated by cost centre, profit centre and segment under ASC 280 and IFRS 8. Cross-border assignments trigger transfer-pricing rules under Section 482.

**Accrual posting.** Accrued vacation follows ASC 712, defined-benefit pension follows ASC 715 under the Projected Unit Credit Method, and stock compensation follows ASC 718 and IFRS 2 at grant-date fair value over the vesting period. UK and IFRS reporting follow IAS 19.

**Sub-ledger to ledger reconciliation.** Control accounts are reconciled with variance materiality judged under ASC 250, producing the reports used for SOX Section 404 testing and the PCAOB walkthrough.

## IRS Section 6001 and the recordkeeping clock

US tax law requires employers to keep records for at least four years from the later of the due date or the date paid, with seven years recommended to cover the longer statute of limitations for substantial understatement, and indefinitely in cases of fraud. The records include the W-2, W-3, 941, 940 and 945 forms, employee personnel files, benefits and retirement-plan records. The agent applies these retention periods deterministically and monitors them continuously from a central catalogue.

## GAAP ASC 710 and IAS 19 employee benefits

Compensation has to be recognised under several frameworks at once. US GAAP covers pension and OPEB (ASC 715), compensated absences (ASC 712) and stock compensation (ASC 718); UK FRS and IFRS - IFRS 19 and IAS 19 - cover short-term and post-employment benefits under the Projected Unit Credit Method, with IFRS 2 for share-based payment. A single accounting-policy taxonomy centralises the framework, recognition and measurement rules so they can be maintained in one place.

## US ERISA and the UK Pensions Act

US ERISA governs retirement plans and fiduciary duties, with the Form 5500 due seven months after plan year-end and a six-year recordkeeping rule. The UK Pensions Act 2008 requires employers to auto-enrol eligible jobholders aged 22 to State Pension age earning over GBP 10,000, with a minimum total contribution of 8 percent (3 percent employer, 5 percent employee); failures draw Pensions Regulator penalties. The agent automates pension-liability accounting under ASC 715, IAS 19 and these reporting obligations together.

## How it connects to the other payroll agents

The agent works alongside the Payroll Calculation Agent (gross-to-net, tax and benefits), the Payroll Reporting Agent (W-2, 941, 940, UK RTI and ESRS S1), the Tax and Social Insurance Agent (ASC 740 and transfer pricing) and the Audit and Compliance Agent (SOX Section 404 and the auditor walkthrough). The Decision Layer produces the audit trail as a by-product: every journal entry, reconciliation, variance and certification is logged with timestamps and signatures, retained seven years under SOX Section 802, IRS Section 6001 and the UK Companies Act.

## At a glance

- 12 deterministic procedural decisions covering payroll close, reconciliation, chart-of-accounts mapping, cost-centre allocation, accruals, stock compensation, journal entry, approval, ledger posting, inter-company allocation and audit trail
- 1 ML-augmented indicator for management reporting and variance commentary
- 1 mandatory human escalation: Controller, Chief Accounting Officer and CFO certification under SOX Section 302 and 906, alongside the auditor walkthrough
- Retention of seven years under SOX Section 802, IRS Section 6001 and the UK Companies Act Section 388
- Deterministic-rules profile: not high-risk under EU AI Act Annex III, subject to the general duties (Articles 4, 13, 14, 26)

## Decision-Maker Distribution Payroll-Accounting

| Decision Type | Count | Examples | Statutory Basis |
|---------------|-------|----------|-----------------|
| R Rule-based | 12 | Payroll close, reconciliation, account mapping, cost-centre allocation, accruals, stock comp, journal entry, approval, ledger posting, inter-company, audit trail | IRS Section 6001, SOX 404, GAAP ASC 710-718, UK Companies Act 388, IFRS 19 / IAS 19 |
| A AI-augmented | 1 | Management reporting and variance commentary | EU AI Act Articles 13, 14, 26; ESRS S1 |
| H Human | 1 | Management certification and auditor walkthrough | SOX 302 / 906; PCAOB AS 2201 |

## Why this agent is operationally high-stakes

Payroll-to-ledger posting does not fall under EU AI Act Annex III, because rule-based posting does not directly affect employment decisions. Volume is high - around 60,000 transactions per 5,000 employees - and the stakes per posting are low, but the cumulative exposure is severe. Ineffective controls under SOX Section 404 trigger a material-weakness disclosure, an auditor adverse opinion, a restatement and criminal exposure under Section 906. A retention failure under IRS Section 6001 brings audit findings, interest and accuracy penalties. A missed UK PAYE RTI filing draws monthly HMRC penalties, and auto-enrolment failures draw Pensions Regulator penalties. The CFO, Controller, Chief Accounting Officer and Internal Audit all depend on accurate mapping, accruals, allocation, reconciliation and certification, and the [Decision Layer](/en/decision-layer/) produces that audit trail as a by-product.

## Edge cases: cross-border assignments, stock compensation, pension liability

Cross-border employee assignments need treaty analysis, residence determination and permanent-establishment review, with transfer pricing under Section 482. Stock compensation is valued under ASC 718 and IFRS 2 at grant-date fair value over the vesting period, with forfeiture estimates and Section 409A treatment. Pension liability follows ASC 715 and IAS 19 under the Projected Unit Credit Method, with actuarial gains and losses, curtailments and settlements. Inter-company allocations carry management charges and transfer pricing for secondments.

## Integration with Workday, SAP, Oracle, ADP and Ceridian

The agent connects to global payroll and ERP systems through their APIs: Workday Payroll, HCM and Financial Management; SAP S/4HANA HCM Payroll and SuccessFactors Employee Central with FI and CO; Oracle Cloud HCM Payroll, PeopleSoft and Cloud ERP; ADP Workforce Now; Ceridian Dayforce, UKG Pro, Paychex, Gusto and QuickBooks for smaller employers; BambooHR, Personio, Sage Intacct, NetSuite and Microsoft Dynamics 365 for the mid-market; Power BI, Tableau and Snowflake for analytics; and Workiva, AuditBoard and Hyperproof for SOX Section 404. It works alongside the Payroll Calculation, Payroll Reporting, Tax and Social Insurance, and Audit and Compliance agents.

--- Payroll HR Process Agent ---
> HR payroll process: employee master data, RTI/HMRC updates, payroll workflow co-ordination and works council co-determination - auditable HR pipeline without gross-to-net math.

## Gross-to-net in seconds, not Excel marathon

This agent follows the [Decision Layer](/en/decision-layer/) principle: each decision is rule-based, AI-assisted or explicitly assigned to a human. It is not high-risk under the [EU AI Act](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) - it runs on deterministic rules and makes no HR decision - but it is bound by strict obligations from [US IRC Section 3401-3405](https://www.irs.gov/), UK HMRC PAYE, SOX 404, AICPA SOC 1 Type II, ISO 30414 and GDPR Article 88, with seven-year IRS and six-year HMRC retention and an auditor-attestation requirement.

A typical payroll runs hundreds to thousands of earnings-code calculations a month - timesheets, variable pay, bonuses, commissions, overtime and benefits in kind. Done manually in Excel it takes days and is error-prone. The agent computes gross-to-net deterministically in seconds from earnings codes, tax tables and benefit deductions, covering federal and state withholding, UK PAYE, FICA, Medicare, UK National Insurance, 401(k), UK auto-enrolment, garnishment, ACA, FMLA, UK statutory pay and the RTI submissions.

The problem is not the volume. It is the SOX-404-compliant audit trail: effective internal controls, a four-eyes review by the Payroll Manager and CPA, a record of user, timestamp and before/after values, seven-year IRS retention, AICPA SOC 1 Type II criteria, external auditor sampling and Audit Committee oversight.

## US IRC Section 3401-3405 and UK HMRC PAYE

[US IRC Section 3401-3405](https://www.law.cornell.edu/uscode/text/26/subtitle-C/chapter-24) sets the federal income-tax withholding framework, from wage definitions through to employer liability for unpaid taxes (Section 3403). It works together with the FICA Social Security and Medicare contributions under 26 USC 3101-3128, including the 0.9 percent Additional Medicare Tax over the threshold, and the FUTA unemployment tax under 26 USC 3301-3311.

The federal filings are Form 941 quarterly, Form 940 annual, and the W-2 and W-3 by 31 January, with mandatory EFTPS deposits on a semi-weekly or monthly schedule.

An IRC violation is costly. Unpaid taxes draw employer liability under Section 3403 and the Trust Fund Recovery Penalty of up to 100 percent under Section 6672 against the responsible person, with criminal penalties for tax evasion under Section 7201. On top of the federal layer, 41 states and DC operate their own income-tax withholding and SUTA, with multistate apportionment and reciprocal agreements for remote workers.

[UK HMRC PAYE Regulations 2003](https://www.legislation.gov.uk/uksi/2003/2682) require RTI submissions: the Full Payment Submission on or before payday, a monthly Employer Payment Summary, the P11D for benefits in kind by 6 July, the P60 by 31 May and the P45 on leaving. Schedule 24 penalties run to 100 percent for a deliberate error. Tax follows the ITEPA bands, with the Scottish five-band system in Scotland.

## US 401(k) and UK auto-enrolment

US ERISA governs the 401(k) qualified plan, with nondiscrimination under Section 401(a)(4) and the Section 415 contribution limits - the elective deferral, the age-50 catch-up and the total annual addition - alongside 403(b) and 457 plans, and the Form 5500 filed annually with the DOL.

The UK Pensions Act 2008 requires auto-enrolment with a minimum total contribution of 8 percent (3 percent employer, 5 percent employee) across the qualifying earnings band, an opt-out window of 30 days and re-enrolment every three years, under The Pensions Regulator.

The DOL safe harbor remits 401(k) contributions within seven business days; UK contributions are due monthly by the 19th of the following month. Pension expense accrual and defined-benefit valuation follow IFRS 19, IAS 19 and IAS 26.

## US FLSA, UK Equality Act and garnishment

The [Fair Labor Standards Act](https://www.dol.gov/agencies/whd/flsa) sets the federal minimum wage, with many states higher, 1.5x overtime over 40 hours a week (and state daily overtime in places like California), and the exempt/non-exempt classification under 29 CFR Part 541. DOL Wage and Hour enforcement brings back wages, double liquidated damages for a willful violation, civil penalties and criminal prosecution for willful repeat offenders.

US federal garnishment under Title III of the Consumer Credit Protection Act caps deductions at 25 percent of disposable earnings with a 30-times-minimum-wage exemption, alongside IRS levies, child support up to 50 to 65 percent, and state garnishment laws that vary widely - from no consumer-debt garnishment in Texas to a head-of-household exemption in Florida.

The UK Equality Act 2010 makes Section 78 gender pay gap reporting mandatory each year for employers over 250, under EHRC enforcement. UK deductions follow the Attachment of Earnings Order, the Direct Earnings Attachment and the bankruptcy Income Payments Order, in the priority order: Council Tax, then child maintenance, then civil debts, then consumer credit.

## US Form 941 and UK RTI

US tax filing runs Form 941 quarterly, Form 940 annually, and the W-2 and W-3 to the SSA by 31 January, with state returns and SUTA filed quarterly and EFTPS deposits semi-weekly or monthly. UK RTI runs the Full Payment Submission on or before payday, a monthly Employer Payment Summary covering statutory payments and the apprenticeship levy, and the P11D, P60 and P45 to their deadlines. ACA reporting under Section 4980H covers Applicable Large Employers on Forms 1094-C and 1095-C, against the minimum-essential-coverage, minimum-value and affordability tests.

## Cross-reference to Payroll-Accounting and Payroll-Reporting

The Payroll Processing Agent sits in a pipeline of specialised HR agents. The [Payroll-Accounting-Agent](/en/hr-agent-catalog/payroll-accounting-agent/) generates the general-ledger postings from finished payroll. The [Payroll-Reporting-Agent](/en/hr-agent-catalog/payroll-reporting-agent/) produces the statutory filings and the CSRD, SEC Pay Ratio and UK Section 78 reports. The [Payroll-Tax-Agent](/en/hr-agent-catalog/payroll-tax-agent/) verifies federal, state and UK tax compliance. The [Compensation-Benchmarking-Agent](/en/hr-agent-catalog/compensation-benchmarking-agent/) provides the compensation bands, and the [Merit-Cycle-Governance-Agent](/en/hr-agent-catalog/merit-cycle-governance-agent/) hands over approved adjustments. The [Audit-Compliance-Agent](/en/hr-agent-catalog/audit-compliance-agent/) verifies SOX 404 controls, the [HR-Document-Management-Agent](/en/hr-agent-catalog/hr-document-management-agent/) archives the pay slips, W-2s and P60s under the statutory retention periods, and the [Expense-Processing-Agent](/en/hr-agent-catalog/expense-processing-agent/) supplies reportable expenses.

## At a glance

- **Classification**: Compliance-Support, NOT EU AI Act high-risk (deterministic-rules)
- **Compliance anchors**: IRC Section 3401-3405, UK HMRC PAYE, SOX 404, AICPA SOC 1 Type II, FICA, UK National Insurance, the UK Pensions Act 2008, ACA, ERISA, FLSA, Title III of the CCPA, the UK Equality Act Section 78, and GDPR Article 88
- **Retention**: seven years under IRS Section 6001, six years under UK HMRC and ERISA, longer where state wage-theft-prevention laws apply
- **Approval**: four-eyes review by the Payroll Manager and CPA, with Audit Committee oversight
- **Penalties**: the Trust Fund Recovery Penalty of up to 100 percent under Section 6672, DOL back wages and double liquidated damages, UK HMRC Schedule 24 penalties of up to 100 percent for a deliberate error, SOX 906 (USD 5M or 20 years), and GDPR fines up to 4 percent of group revenue
- **Audit obligation**: SOX 404 with AICPA SOC 1 Type II, CSRD auditor verification from 250 employees, the UK Section 78 annual report, and the SEC Pay Ratio Disclosure for US public companies
- **Related agents**: Payroll Accounting, Payroll Reporting, and the IFRS 19 / IAS 19 pension modules

### Decision-Maker Distribution Payroll-Processing

| Step | Decider | Rationale |
|------|---------|-----------|
| Earnings-code classification | R | Earnings-code lookup and tax-table mapping, deterministic |
| Federal, state and UK tax | R | Pub 15, state tables and UK PAYE, deterministic |
| FICA, Medicare and UK NIC | R | Wage base and the Class 1, 1A and 1B rules, deterministic |
| 401(k) and UK pensions | R | ERISA Section 415 and the Pensions Act 2008, deterministic |
| Garnishment and UK AEO | R | Title III CCPA cap and AEO priority, deterministic |
| ACA compliance | R | Section 4980H, minimum value and affordability, deterministic |
| FLSA validation | R | Minimum wage, overtime and exempt status, deterministic |
| Statutory leave | R | FMLA, UK statutory pay and state paid family leave, deterministic |
| Anomaly detection | A | ML anomaly detection with human validation |
| Payroll Manager approval | H | Four-eyes SOX 404 review, mandatory |
| Form 941 and RTI submission | R | EFTPS and UK RTI, deterministic |
| Pay slip, W-2 and P60 | R | IRS and UK HMRC delivery, deterministic |
| 401(k) and UK pension remittance | R | DOL safe harbor and monthly UK contribution, deterministic |
| SOX 404 audit trail | R | Internal controls and AICPA SOC 1 Type II, deterministic |
| Retention lifecycle | R | IRS Section 6001, UK HMRC and GDPR, deterministic |

--- HR Reporting Agent ---
> HR management reports: CSRD ESRS S1-9 diversity, S1-10 equal-pay, S1-13 compensation, FTE statistics and people-cost dashboards - automatic from payroll without Excel tennis.

## From payroll to report - 90 percent automatic

This agent follows the [Decision Layer](/en/decision-layer/) principle: each decision is rule-based, AI-assisted or explicitly assigned to a human. It is not high-risk under the [EU AI Act](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) - it aggregates and files data and makes no HR decision - but it is bound by strict obligations from [US IRS Form 941](https://www.irs.gov/forms-pubs/about-form-941) and the W-2, UK HMRC RTI, SOX 404, AICPA SOC 1 Type II, ISO 30414 and GDPR Article 88, with seven-year IRS and six-year HMRC retention.

A typical reporting cycle produces dozens of statutory filings, management dashboards and ad-hoc reports a year from finished payroll data, aggregation rules and filing templates. Done manually in Excel it takes days and is error-prone. The agent generates the reports deterministically in minutes - across cost-centre, entity, pay-grade and period dimensions, with multi-entity rollup and multi-currency conversion - covering all the US and UK statutory filings, the CSRD ESRS S1-13 metrics and ISO 30414.

The problem is not the volume. It is the SOX-404-compliant audit trail: effective controls, a four-eyes review by the HR Controller, CFO and Audit Committee, a record of user, timestamp, before/after values, report-run ID and data lineage, seven-year IRS retention, AICPA SOC 1 Type II criteria, external auditor sampling and PCAOB standards.

The familiar three-day cycle for a headcount-cost report comes not from the analysis but from manual aggregation across three to eight source systems - payroll, finance, time management, a manual cleanup and a spreadsheet consolidation. Each step is trivial on its own; together they consume hours to days per cycle and breed errors.

## US W-2, Form 941 and UK RTI year-end

The US federal filings run [Form 941](https://www.irs.gov/forms-pubs/about-form-941) quarterly, Form 940 annually for FUTA, the W-2 by 31 January, the W-3 to the SSA, and the 1099-NEC for contractors. A wrong or missing form draws IRS penalties under Sections 6721 and 6722 and a failure-to-file penalty under Section 6651, with mandatory EFTPS deposits on a semi-weekly or monthly schedule.

At state level, 41 states and DC operate their own returns and quarterly SUTA, with annual income-tax reconciliation, multistate apportionment and reciprocal agreements for remote workers, alongside state disability and family-leave insurance.

The [UK HMRC RTI year-end](https://www.gov.uk/payroll-annual-reporting) requires the final Full Payment Submission marked final by 5 April, the P60 by 31 May to everyone employed on that date, and the P11D and P11D(b) for benefits in kind by 6 July, with the P45 issued on leaving. Class 1A National Insurance applies to benefits in kind, and Schedule 24 penalties run to 100 percent for a deliberate error.

## ACA Form 1094-C, ERISA Form 5500 and EEO-1 Component 2

The ACA reporting runs Form 1094-C (the ALE transmittal) and Form 1095-C (the employee statement) under Section 6056, for Applicable Large Employers, against the minimum-essential-coverage, minimum-value and affordability tests under Section 4980H, due 28 February on paper or 31 March electronically.

The ERISA Form 5500 annual return is due the last day of the seventh month after plan year-end, with the short and one-participant variants, Form 8955-SSA for terminated participants, and the actuarial schedules, all filed electronically through EFAST2 with the DOL.

For federal contractors, the OFCCP requires the Affirmative Action Plan under Executive Order 11246, and the EEO-1 Component 2 demographic-pay report - 10 categories and 12 pay bands, due 31 March - applies under Title VII, the Equal Pay Act and ADEA, with EEOC enforcement.

## CSRD ESRS S1-13 reporting and UK Section 78 gender pay gap

CSRD mandates ESRS reporting from 250 employees with limited-assurance auditor verification. ESRS S1 Own Workforce covers diversity (S1-1), equal pay (S1-10), compensation (S1-13, with mean, median and the highest-to-median ratio) and workers in the value chain (S1-3), aligned with the EFRAG and ISSB standards.

[UK Equality Act 2010 Section 78](https://www.legislation.gov.uk/uksi/2017/172) makes gender pay gap reporting mandatory each year for employers over 250, by 4 April in the private sector. Six figures are required: the median and mean hourly pay gap, the median and mean bonus gap, the bonus proportions and the quartile distribution, published under EHRC enforcement at Companies House.

The US SEC Pay Ratio Disclosure under Item 402(u) and Dodd-Frank Section 953(b) requires the median employee compensation, the CEO total compensation and the ratio between them, with a reasonable methodology, in the annual Form DEF 14A proxy.

## SOX 404, AICPA SOC 1 Type II and ISO 30414

[US Sarbanes-Oxley Section 404](https://www.sec.gov/about/laws/soa2002.pdf) governs internal controls over financial reporting, with CEO and CFO certification under Section 302 and a criminal penalty under Section 906 of up to USD 5M or 20 years. AICPA SOC 1 Type II and ISO 30414 human-capital reporting cover the workforce metrics - composition, diversity, costs, skills, retention, productivity and succession planning - with the PCAOB and the Big Four auditing SOX 404.

The ML-supported trend and anomaly indicators - period-over-period comparison, outlier detection and budget-variance classification for overtime spikes, new hires and bonus cycles - provide indicators only, with no automated report correction. The HR Controller, CFO and Audit Committee interpret the trends, and the agent does not replace the board commentary, which stays with people who know the context.

## How it connects to Payroll Processing and Payroll Accounting

The [Payroll-Processing-Agent](/en/hr-agent-catalog/payroll-processing-agent/) generates the gross-to-net calculation that feeds reporting, and the [Payroll-Accounting-Agent](/en/hr-agent-catalog/payroll-accounting-agent/) generates the general-ledger postings. The [Payroll-Tax-Agent](/en/hr-agent-catalog/payroll-tax-agent/) verifies federal, state and UK tax compliance. The [Compensation-Benchmarking-Agent](/en/hr-agent-catalog/compensation-benchmarking-agent/) provides the compensation bands and Compa-Ratios used for the SEC Pay Ratio, UK Section 78 and ESRS S1-13 reports, and the [Merit-Cycle-Governance-Agent](/en/hr-agent-catalog/merit-cycle-governance-agent/) hands over approved adjustments. The [Audit-Compliance-Agent](/en/hr-agent-catalog/audit-compliance-agent/) verifies SOX 404 controls, and the [HR-Document-Management-Agent](/en/hr-agent-catalog/hr-document-management-agent/) archives the reports, W-2s and P60s under the statutory retention periods. The Strategic HR Analytics and People Analytics agents build on the reporting infrastructure, and the ESG Reporting Agent extends ESRS S1-13 and ISO 30414 to full sustainability reporting.

## At a glance

- **Classification**: Compliance-Support, NOT EU AI Act high-risk (reporting-aggregation)
- **Compliance anchors**: the US federal filings (Form 941, 940, W-2, W-3, 1099-NEC), state returns, the ACA and ERISA forms, UK HMRC RTI year-end with the P60 and P11D, the UK Section 78 report, the SEC Pay Ratio Disclosure, EEO-1 Component 2, the OFCCP AAP, CSRD ESRS S1-13, ISO 30414, SOX 404 with AICPA SOC 1 Type II, and GDPR Article 88
- **Retention**: seven years under IRS Section 6001, six years under UK HMRC and ERISA, longer where state wage-theft-prevention laws apply
- **Approval**: four-eyes review by the HR Controller and CFO, with Audit Committee oversight
- **Penalties**: IRS penalties under Sections 6721, 6722 and 6651, UK HMRC Schedule 24 penalties of up to 100 percent for a deliberate error, SOX 906 (USD 5M or 20 years), EHRC Section 78 and SEC Pay Ratio enforcement, and GDPR fines up to 4 percent of group revenue
- **Audit obligation**: SOX 404 with AICPA SOC 1 Type II, CSRD limited-assurance verification from 250 employees, the UK Section 78 annual report, the SEC Pay Ratio Disclosure for US public companies, and EEO-1 Component 2 due 31 March
- **Related agents**: Payroll Processing, Payroll Accounting, Compensation Benchmarking, ESG Reporting and CFO Reporting

### Decision-Maker Distribution Payroll-Reporting

| Step | Decider | Rationale |
|------|---------|-----------|
| Payroll data extraction and consolidation | R | ETL extraction with deterministic source-to-target mapping |
| Aggregation by cost centre, entity and period | R | Aggregation rules deterministic per report type |
| US Form 941, 940, W-2 and W-3 | R | IRS form templates and EFTPS, deterministic |
| UK RTI year-end, P60, P11D and P11D(b) | R | UK RTI, P60 and P11D generation, deterministic |
| ACA Form 1094-C and 1095-C | R | ALE, minimum essential coverage and affordability, deterministic |
| ERISA Form 5500 and 8955-SSA via EFAST2 | R | Form 5500 and its schedules, deterministic |
| EEO-1 Component 2 and OFCCP AAP | R | 10 EEO-1 categories and 12 pay bands, deterministic |
| UK Section 78 gender pay gap | R | Median, mean, quartile and bonus proportion, deterministic |
| CSRD ESRS S1-13, S1-10, S1-1 and ISO 30414 | R | ESRS and ISO 30414 metrics with auditor verification, deterministic |
| SEC Pay Ratio Disclosure (Item 402(u)) | R | Median employee, CEO total compensation and ratio, deterministic |
| Trend and anomaly indicators | A | ML trend detection with human validation |
| Audit Committee and board commentary approval | H | Four-eyes SOX 404 review and interpretation, mandatory |
| Distribution and secure delivery | R | Recipient authorisation matrix and secure channels, deterministic |
| SOX 404 audit trail with AICPA SOC 1 Type II | R | Internal controls and data lineage, deterministic |
| Retention lifecycle | R | IRS Section 6001, UK HMRC and GDPR, deterministic |

--- People Analytics Agent ---
> Analyses attrition, engagement, diversity, and productivity patterns and trends. EU AI Act high-risk classification applies.

HR owns the data that could underpin strategic workforce decisions. Attrition by business unit, engagement by location, diversity by hierarchy level. Yet only 8 percent of organisations report that their HR data is actually usable (Deloitte, Human Capital Trends). The rest export tables, build presentations over weeks, and deliver answers that arrive too late, stay on the surface, and miss the actual question.

The problem is not a lack of data. It is a lack of architecture. Anyone running people analytics without structurally separating analysis from surveillance gets neither acceptance from worker representatives nor conformity with the EU AI Act.

## Why people analytics stalls in practice

76 percent of all organisations run some form of people analytics. But only 9 percent understand which talent dimensions actually drive performance (Deloitte, 2024). Between what HR owns as data and what reaches strategic decisions lies a chasm. Three causes keep it open.

**Fragmented data foundation.** Personnel records live in SAP or Workday, engagement scores in a survey tool, attrition reasons in managers' Excel lists. 60 percent of HR leaders name data integration as the biggest obstacle (EY, 2024). The hidden damage: organisations lose up to USD 15 million (EUR 13.7 million) per year in productivity through faulty HR data - not because of wrong analyses, but because of the correction work that poor data quality forces.

**No translation into decision language.** HR reports headcount, sickness rates, training days. Executive leadership thinks in revenue per head, time-to-market, customer churn. As long as attrition is not linked to its economic consequences, people analytics remains an administrative report. Best Buy quantified the connection: 0.1 points more engagement correlated with USD 100,000 (EUR 91,500) additional revenue per store. Most HR departments cannot make such a link - not because the data is missing, but because no one has defined which links are strategically relevant.

**Blurring analysis with surveillance.** People analytics should detect patterns in aggregated data. Without clear technical boundaries, the analysis imperceptibly slides into performance monitoring of individual employees. Worker representatives block. The workforce loses trust. The project does not die because of the technology but because of the loss of trust.

## High-risk: deadline 2 August 2026 (postponement to Dec 2027 provisionally agreed) - the regulatory reality

The EU AI Act classifies people analytics systems as high-risk under Annex III, category 4(b): AI systems for monitoring and evaluating workplace behaviour. Even if the agent analyses only in aggregate, the results can influence employment decisions. That is enough for the classification.

Under current law, from 2 August 2026 - provisionally postponed to 2 December 2027 under the Digital Omnibus of 7 May 2026 (formal adoption still pending, as of June 2026) - high-risk systems must meet the following requirements:

- Risk management system with documented impact assessment
- Data quality requirements and technical documentation
- Transparency toward affected employees
- Human oversight by technically competent persons
- CE marking and registration in the EU database

National law runs in parallel. Works council co-determination rights in most EU member states require involvement for technical systems suitable for performance and behaviour monitoring. European labour courts have made clear that the employer's subjective intent is irrelevant. What matters is the objective suitability of the system. A people analytics tool is, by definition, suitable.

GDPR Article 35 requires a Data Protection Impact Assessment when processing is likely to result in high risk to the rights of natural persons. Systematic analysis of employee data meets this criterion.

Anyone who does not think these three legal frameworks together builds a system that works technically and cannot hold up legally.

## What architecture solves that technology alone cannot

The central question is not: which tool analyses the data? It is: who defines the question, who interprets the result, who decides?

The [Decision Layer](/en/decision-layer/) decomposes the analytics process into discrete decision steps. Each step has a defined owner: human, rules engine, or AI agent.

```
Define the            Data protection       Aggregate           Identify
question         -->  check            -->  data           -->  patterns
(Human)               (Rules)               (Rules)             (Agent)

Validate              Derive actions        Present
findings         -->  and recommen-    -->  results
(Human)               dations (Agent)       (Agent)
```

The separation is not formalism. It solves the core problem that makes people analytics fail in practice.

**Step 1: Define the question (human).** Analytics without a strategic question produces reports no one asked for. The process only begins when HR leadership or the executive team is preparing a concrete decision: do we need a retention programme in sales? Is the engagement gap between sites widening?

**Step 2: Data protection check (rules engine).** Before a single data point is aggregated, the rule set checks the planned analysis against GDPR, works council agreements, and internal policies. Analyses without a legal basis do not start.

**Step 3: Aggregate data (rules engine).** Core HR data, engagement scores, and attrition data are combined and anonymised. Groups below a defined minimum size are merged. This is not a policy but a technical barrier: inferences about individuals are not possible, because the architecture prevents them.

**Step 4: Identify patterns (agent).** The agent recognises correlations, trends, and outliers in the aggregated data. Where is attrition rising faster than the company average? Which units show declining engagement with rising overtime? Predictive models identify at-risk areas 60 to 90 days before terminations occur.

**Step 5: Validate findings (human).** A statistical pattern is not a cause. Does declining satisfaction in unit X correlate with last quarter's restructuring - or with the leadership change? The HR analytics specialist checks significance, plausibility, and context. The agent provides the evidence. The interpretation belongs to a human with domain knowledge.

**Steps 6-7: Recommendations and presentation (agent).** The agent formulates evidence-based recommendations with confidence indicators and prepares them for management. Not 40 metrics on a dashboard, but three to five insights connected to business impact and concrete action options.

## The boundary between analysis and surveillance is an architecture decision

No trust problem can be solved by a better dashboard. Acceptance of people analytics depends on whether the boundary between pattern detection in aggregated data and evaluation of individual employees is not merely promised but technically enforced.

Three architectural principles secure this:

**Aggregation as a technical barrier.** Minimum group sizes are not defined as policy but implemented as system parameters. An analysis with too small a population returns no result - not a warning, no output.

**No re-identification of individuals.** The anonymisation logic prevents combinations of several aggregated analyses from identifying individuals. This is mathematically solvable and technically implementable - but only if it is anchored in the architecture from the start.

**Complete decision record.** Every analysis is documented: question, legal basis, aggregation level, result, derived action. Worker representatives have inspection rights. Affected employees can understand which analyses have been run and which decisions are based on them.

This framework is simultaneously the works council agreement. Whoever documents the architecture cleanly has already structured the negotiation outcome with worker representatives. Clear boundaries increase acceptance and reduce governance risk - that is not a compromise but a strategic advantage.

## Infrastructure that extends beyond the single agent

The analysis engine built here - attrition, engagement, equity - is reused by the Strategic HR Analytics Agent for board reporting and by the Merit Cycle Governance Agent for compensation analyses. The anonymisation and minimum-group-size logic becomes the standard for every agent processing personal data. The governance framework - what may be analysed, what may not, under what conditions - becomes the foundation for all high-risk agents in the H4 quadrant.

The real value is not in the analytics results of a single quarter. It is in the infrastructure that turns people analytics from a governance risk into a governance tool: traceable, contestable, repeatable. Organisations that reach this maturity make data-driven decisions five times faster and outperform competitors in business outcomes three times more often (Deloitte, Human Capital Trends). (US: under NLRA guidance and state-level worker-surveillance laws in New York and California, the same boundary discipline is becoming a legal requirement, not just a European one.)

--- Performance Review Documentation Agent ---
> Structures the review process and documents outcomes in an audit-proof format. EU AI Act high-risk system under Annex III.

## The assessment is rarely the problem. The documentation is.

This agent follows the [Decision Layer](/en/decision-layer/) principle: each decision is either rule-based, AI-assisted, or explicitly assigned to a human.

Managers can judge performance. What they cannot do: convert a year of observations into a consistent, evidenced, legally defensible record. The result is a documentation process that systematically produces contradictions - between rating and justification, between self-assessment and manager view, between what was said in the conversation and what sits in the file.

This is not a quality problem of individual managers. It is a structural problem. And it becomes a legal risk the moment a termination, a denied promotion, or an employment tribunal proceeding reaches into exactly this file.

## Three patterns that stay invisible in the manual process

**Rating-text divergence.** A manager selects "exceeds expectations" but writes three paragraphs about areas for improvement. Or the reverse: "partially meets expectations" with a justification that names only strengths. Research shows that over 60 percent of variance in performance ratings comes from the rater, not the person being rated. In individual cases, the discrepancy is visible. Across 200, 500, or 1,000 reviews per cycle, it goes unnoticed because no one reads every document.

**Recency bias as a documentation gap.** Recency bias is the most common rating error in organisations. Managers who do not keep ongoing notes - and the great majority do not - reconstruct twelve months of performance from the last six weeks. The project that ran brilliantly in February does not exist in December. The mistake in November dominates the entire review. The documentation does not reflect performance. It reflects memory.

**Rating bias that disappears in individual data.** When a manager gives four women on the team "meets expectations" and four men "exceeds expectations", that is inconspicuous on its own. It may even be correct in the individual case. But when this pattern repeats across 30 teams, it is no longer accidental. HBR research shows that 61 percent of women receive feedback on their communication style - compared with 1 percent of men. Such patterns are not detectable manually because they only emerge through aggregation.

## Why better forms do not solve the problem

The obvious reflex: more structured templates, mandatory fields, pre-written text blocks. But a form cannot check whether the justification matches the rating. It cannot detect whether an employee's self-assessment systematically diverges from the manager view. It cannot spot that a manager has been copying the same phrasings for three cycles. And it cannot analyse across 40 teams whether rating patterns differ by gender, age, or part-time status.

The task is not to improve the form. It is to decompose the review process so that each step has a clear assignment: who decides? By what rule? With what check?

## Eleven steps, three decision principles

```
Start the           Distribute          Self-               Manager
cycle          -->  forms          -->  assessment     -->  rates
(R: calendar)       (R: routing)        (R: rules)          (H: observation)

Consistency         Support              Bias                Escalate
check          -->  calibration    -->  analysis       -->  finding
(A: rating/text)    (A: distribution)   (A: statistics)     (R: threshold)

Schedule            Document             Trigger follow-
conversation   -->  outcome         -->  up actions
(A: calendar)       (R: archival)        (R: rule-based)
```

The decisive difference from the manual process: steps 5, 6, and 7 run in parallel with the rating, not afterwards. When a manager enters a rating and fills in the justification, it is immediately checked for internal consistency. The calibration view updates in real time. The bias analysis continuously checks whether patterns are emerging.

This changes the character of the calibration round. Instead of comparing ratings after the fact, managers see where their rating sits in context as they enter it: distribution within the team, deviation from the department average, consistency with prior cycles. The conversation shifts from "are we voting on grades?" to "where are we deliberately departing from the pattern, and why?"

## Consistency checking as a structural advantage

The automatic check of whether rating and written justification align is not a comfort feature. It is the main reason a rule-based orchestration is superior to the manual process. A human reading 400 review forms cannot systematically detect where word and number diverge. The agent detects the contradiction immediately and flags it - not in a report that lands on a desk weeks later, but while the manager is still in the rating process and can correct it.

For organisations covered by the EU AI Act high-risk regime - whose obligations attach from 2 August 2026 under current law, provisionally postponed to 2 December 2027 under the Digital Omnibus of 7 May 2026 (formal adoption still pending, as of June 2026), for systems that evaluate workplace performance and behaviour - traceability is not optional. It is a legal requirement. Annex III(4)(b) requires a risk management system, transparency toward affected persons, and human oversight. These requirements are not bolted on after the fact here. They are built into the architecture: the evaluation stays with the human. The agent documents, checks, and analyses.

## What remains at the end

The agent does not make a single performance judgement. It ensures that every assessment is consistently justified, completely documented, and checked for systematic patterns. The rating is assigned by the manager. The conversation is led by a human. Calibration is owned by HR leadership.

The infrastructure that emerges - consistency engine, bias analysis, calibration framework, audit-proof archival - is not built for a single review cycle. The bias analysis is reused by the Merit Cycle Governance Agent and the Promotion Process Agent. The consistency checking pattern becomes the standard for every agent that checks human judgements for coherence. The decision record created per review makes every single assessment traceable and contestable - for the affected person just as much as for worker representatives. (US: similar documentation requirements are emerging under the Illinois AI Video Interview Act and NYC Local Law 144, which treat automated performance systems as audit-relevant.)

--- Policy Document Agent ---
> HR policy lifecycle: Title VII + Equal Pay Act, UK Equality Act 2010 + ACAS Code, GDPR Art. 88, SOX 404 ICFR and ISO 30414 - versioning, acknowledgement tracking and CSRD S1-1 reporting.

Cross-jurisdictional HR policy management answers to four parallel statutory regimes. In the US, Title VII and related anti-discrimination law set the floor, reinforced by the Bostock v. Clayton County (2020) precedent. In the UK, the Equality Act 2010 and its Section 78 Gender Pay Gap reporting apply. Across the EU, GDPR Article 88 governs employee data and CSRD ESRS S1 the workforce-policy disclosures. And at public companies, SOX Section 404 controls compensation policy. A single policy in a large or upper-mid-market employer can trigger all four at once, with penalty exposure into the tens of millions. Yet in a typical 1,500-employee company, 60 percent of policies are non-versioned, 70 percent of employees have never read the current handbook, and acknowledgement evidence is missing for 40 to 60 percent of distributions.

## From 60 PDF versions to one Single-Source-of-Truth

This agent follows the [Decision Layer](/en/decision-layer/) principle: each decision is either rule-based, AI-assisted, or explicitly assigned to a human - and the human spots are reserved for content approval and works council co-determination.

A line manager asks HR which travel-expense rule applied for a trip in January when the claim is submitted in March under a revised policy. HR searches SharePoint and finds three PDF versions - travel-policy-v3-NEW, travel-policy-final-Jan, travel-policy-2025 - none carrying an effective date or a supersedes note. The HR generalist guesses from the file modification timestamp, applies the wrong version, and the employee receives a denial letter that is overturned six weeks later when the works council escalates. The same thing happens when an EEOC charge of disparate impact lands and the 180-day clock starts: spread across SharePoint folders, email archives and departed colleagues' drives, HR cannot consistently prove which policy version applied at the time of the alleged action.

The problem is not employee negligence. It describes the normal state in HR departments that maintain policy libraries across legacy structures: a SharePoint folder for handbook PDFs, a Confluence space for procedures, an email distribution list for amendments, a paper binder in the works council office, an HRIS for digital onboarding consents. Each system has its own logic, its own permissions, its own gaps. A US HR director facing a Title VII charge does not know whether the SharePoint folder still holds the policy version under which the alleged discrimination occurred. A UK HR generalist responding to an Employment Tribunal claim does not know whether the email-attachment archive contains the policy version distributed to the claimant. An EU compliance officer fielding a GDPR Article 15 Subject Access Request does not know whether the paper binder contains the records subject to disclosure.

## Discrimination check across US and UK

The agent checks every policy text against the EEOC Compliance Manual, the Bostock v. Clayton County (2020) precedent on sexual orientation and gender identity, the UK EHRC Code of Practice and Employment Tribunal precedent. That flagging is an indicator, not a final decision: flagged policies route to General Counsel, the DPO and the Compliance Officer for human review. Against US law it checks the Title VII protected classes alongside ADEA age protection, ADA reasonable accommodation and equal-pay rules; against UK law it checks the Equality Act 2010 protected characteristics alongside the harassment, victimisation and Gender Pay Gap provisions.

In practice the agent surfaces potentially discriminatory language, missing accommodation provisions and disparate-impact risk. Compensation policies are additionally checked against US state pay-transparency laws, and parental-leave and lactation policies against the Pregnant Workers Fairness Act and the PUMP Act.

## SOX 404 controls and ISO 30414 reporting

SOX Section 404 requires management assessment and auditor attestation of internal controls, including segregation of duties for compensation-policy approval. The agent executes those controls and captures the audit evidence automatically. Records are retained 7 years under Section 802.

A SOC 2 Type II report attests the security, availability and processing-integrity controls around the policy library. ISO 30414 human capital metrics - workforce composition, diversity, leadership, productivity - are drawn from the policy library and its acknowledgement evidence, and ISO 27001 governs the access-control matrix and audit trail.

## EU and UK data protection

GDPR Article 88 lets each Member State set more specific rules for employee data through law or collective agreement, and the EDPB guidelines clarify the lawful-basis hierarchy: in employment, consent is generally invalid because of the power imbalance, so processing rests on the employment contract, a legal obligation or a balanced legitimate interest, with works council agreement supplementing - never replacing - that basis. Special categories such as health or trade-union data need an employment-law derogation under Article 9, and Article 35 makes a Data Protection Impact Assessment mandatory for systematic monitoring or AI-driven evaluation.

UK GDPR mirrors this, with the DPA 2018 employment derogation and the ICO Employment Practices Code. The agent identifies policies that process employee data, applies the Article 35 DPIA criteria and routes the required works council co-determination.

## Retention and the versioning lifecycle

Every policy version is archived with its effective date, expiry date and the version it supersedes, then held for the longest applicable retention period - 7 years under SOX Section 802, 6 years under UK Companies Act 2006, and the AI system log lifetime under EU AI Act Article 12. Employees always see the current version by default; historical versions stay available for audit but are clearly marked as superseded.

For every employee question the agent searches the policy library, selects the version valid at the time of the question, separates factual from interpretive cases and returns the answer with its source reference - section, version and effective date - routing interpretive cases to HR. As EU AI Act transparency rules require, each response is marked as AI-generated and carries that source reference.

## Cross-reference to HR-Document-Management and Audit-Compliance

The Policy Document Agent is the authoritative policy repository for the Audit Compliance, Training Compliance, Employee Self-Service and HR Document Management agents, and it triggers the Audit Compliance Agent on a SOX 404 control deficiency or a discrimination-law finding. Two of its three core components - the versioning engine and the approval workflow - are generic infrastructure. Every agent in the [Decision Layer](/en/decision-layer/) that applies rule sets needs versioned documents with validity periods. Every agent that orchestrates multi-level approvals needs a workflow engine with deadline tracking. The Compliance Monitoring Agent checks operational data against rule sets that must be versioned. The Works Council Coordination Agent manages participation processes following the same approval logic. The Audit Agent needs proof - the acknowledgement tracking provides it.

## At a glance

- 13 deterministic procedural decisions, 4 AI-augmented indicators and 1 mandatory human escalation
- Discrimination check on every policy text against Title VII, the UK Equality Act 2010 and GDPR Article 88
- Works council co-determination orchestrated per EU Member State and under the UK consultation regulations
- CSRD ESRS S1 disclosure mapping, drawing on ISO 30414 human capital reporting categories
- Acknowledgement evidence captured to defend an Employment Tribunal claim or EEOC charge
- The version valid on the request date returned for retroactive employee inquiries

## Decision-Maker Distribution Policy-Document

| Decision Type | Count | Example | Challengeable |
|---|---|---|---|
| R Rule-based | 9 | Policy intake classification, retention assignment, approval routing, acknowledgement deadline tracking, audit-trail logging | not applicable |
| A AI-augmented | 4 | Discrimination check, reviewer feedback aggregation, employee inquiry semantic search | auditor, employee |
| H Human escalation | 1 | Manager review, content approval, works council co-determination | not applicable |

--- Pre-Hire Due Diligence Agent ---
> An auditable background-check pipeline that verifies references, credentials and criminal records before the hire, with every consent and notice proven.

Cross-jurisdictional pre-employment due diligence answers to five parallel statutory regimes. US anti-discrimination law sets the disparate-impact rules through the EEOC's 2012 guidance. The FCRA governs consent and adverse-action notices. Form I-9 verification exposes the employer to ICE audit. The UK runs criminal checks through DBS under the Rehabilitation of Offenders Act 1974. And the EU adds the GDPR Article 9 and 10 limits alongside the EU AI Act high-risk regime, with fines up to EUR 35M or 7 percent of global turnover. A single pre-hire decision at a large or upper-mid-market employer can trigger all five at once.

## Background check between compliance obligation and Title VII trap

This agent follows the [Decision Layer](/en/decision-layer/) principle: each decision is either rule-based, AI-assisted, or explicitly assigned to a human - and the human spots are reserved for the DPIA and the EEO Officer's final hiring approval.

The hire is signed, the candidate starts - and six months later it turns out that the stated university degree never existed. The reference letter was manipulated. The criminal conviction was never disclosed. The Form I-9 was completed but the documents were never properly reviewed.

Cross-industry surveys show approximately one-third of all applications contain false information. A Resume Builder survey from January 2025 reports 44 percent of respondents admitted to lying during the hiring process - 24 percent directly in the CV. Since generative AI produces letters of reference and certificates in minutes, the rate keeps rising.

The legal side is asymmetric. Under Title VII, criminal-record screening that correlates with protected categories creates disparate-impact exposure unless an individualised assessment is done, as the EEOC's 2012 guidance requires. FCRA statutory damages of USD 100 to 1,000 per violation, aggregated across the candidate pool, drive eight-figure class-action settlements. The UK Rehabilitation of Offenders Act 1974 protects against discrimination over a spent conviction. And unauthorised processing of special-category or criminal data under GDPR reaches up to 4 percent of global turnover.

## EU AI Act high-risk classification, DPIA and FRIA

EU AI Act 2024/1689 Annex III(4)(a) classes AI systems for recruitment or selection as high-risk, and pre-employment due-diligence AI falls within scope because its verification decisions materially influence which candidates reach a final hire. Mobley v. Workday (2023) confirmed the same under US law: algorithmic discrimination in HR software is actionable on disparate-impact grounds across the whole pipeline.

The high-risk classification brings the full Chapter III conformity obligations - risk management, data governance, technical documentation, AI system logging, human oversight, accuracy and cybersecurity - together with a CE marking and a Fundamental Rights Impact Assessment by the deployer before first use. Fines reach EUR 35M or 7 percent of global turnover.

On top of this, GDPR Article 35 makes a DPIA mandatory for high-risk processing involving special-category or criminal data. The CJEU SCHUFA judgment (C-634/21, 2023) confirmed that scoring and profiling outputs which substantially shape a later decision count as automated decision-making, even when a nominal human review takes place.

## US FCRA, Ban-the-Box and adverse-action notice

The FCRA Section 604(b)(2) requires a clear, standalone written disclosure before a consumer report is obtained - the document may contain nothing but the disclosure, with no liability waivers attached. Section 604(b)(3) requires the candidate's written authorisation, and before any adverse action the employer must serve a Pre-Adverse Action Notice with a copy of the report, a Summary of Consumer Rights, and a 5-business-day window to dispute.

The Adverse Action Notice then follows under Section 615(a). Wilful non-compliance carries statutory damages of USD 100 to 1,000 per violation, which aggregate across the candidate pool into class-action exposure; Spokeo v. Robins (2016) confirmed that the procedural harm alone establishes standing.

More than 38 states delay any criminal-record inquiry until after a conditional offer is made. The EEOC's 2012 arrest-and-conviction guidance sets the Title VII framework: blanket exclusions risk disparate-treatment liability, and disparate-impact liability requires an individualised assessment weighing the nature and gravity of the offence, the time elapsed and its relevance to the job. In California, the ICRAA adds a 7-year lookback and punitive damages of USD 10,000 for wilful non-compliance.

## US Form I-9 employment eligibility verification

Form I-9, under Immigration and Nationality Act Section 274A, obliges the employer to verify each new hire's identity and work authorisation. The candidate self-attests in Section 1 by the first day of employment, and the employer reviews the original documents in Section 2 within three business days, drawing on the List A, B and C categories of acceptable documents.

E-Verify, run jointly by USCIS and the Social Security Administration, confirms authorisation against federal databases. An ICE Form I-9 audit creates significant exposure: civil penalties of USD 281 to 2,789 per paperwork violation, USD 698 to 27,894 per knowing-hire violation, and criminal penalties for a pattern of violations. A Notice of Inspection typically gives only a three-day response window, and Section 274B bars discrimination on citizenship or national origin during the process.

## UK DBS checks and ROA spent convictions

The UK runs criminal checks through a three-tier DBS framework: a basic check (with consent, unspent convictions only), a standard check for the regulated workforce (spent and unspent convictions, with cautions), and an enhanced check for roles with children or vulnerable adults (adding barred-list checks under the Safeguarding Vulnerable Groups Act 2006). The Rehabilitation of Offenders Act 1974 protects against discrimination over a spent conviction and limits when one must be disclosed. Under the DBS Filtering Rules, a single conviction is filtered after 11 years where no custodial sentence was imposed. Separately, the Modern Slavery Act 2015 requires supply-chain due diligence above GBP 36M turnover, and a Right to Work Check carries civil penalties up to GBP 20,000 per illegal worker.

## Cross-reference to Candidate-Screening, Interview-Scheduling and Contract-Offer-Generation

The agent picks up from the Candidate-Screening Agent's shortlist, runs after interview scheduling, feeds verified candidates into the Contract-Offer-Generation Agent, and triggers the Audit-Compliance Agent for the bias audit, DPIA and FRIA.

It integrates over API with the major ATS and HCM platforms (Workday, ADP, SAP SuccessFactors, Oracle Cloud HCM, Greenhouse, Lever, iCIMS, BambooHR) and the leading background-screening vendors (Sterling, HireRight, Checkr and others). Consent is sealed with a qualified electronic signature under eIDAS in the EU and ESIGN/UETA in the US.

## At a glance

- **High-risk under EU AI Act 2024/1689 Annex III(4)(a)** with full conformity duties, a deployer FRIA, fines up to EUR 35M or 7 percent of global turnover, and the Mobley v. Workday (2023) precedent
- **FCRA Section 604(b) standalone disclosure and authorisation** with the Pre-Adverse Action Notice, the 5-business-day window, and statutory damages of USD 100 to 1,000 per violation
- **State Ban-the-Box laws** applying the EEOC's 2012 individualised-assessment framework, with a 7-year lookback and USD 10,000 punitive damages in California
- **Form I-9 verification with E-Verify**, where an ICE audit carries USD 281 to 2,789 per paperwork violation and far more per knowing hire
- **UK DBS basic, standard and enhanced checks** with ROA 1974 spent-conviction filtering, Modern Slavery Act due diligence, and the Right to Work Check
- **GDPR limits on special-category and criminal data** under Articles 9 and 10, with a mandatory Article 35 DPIA and the SCHUFA judgment
- **ADA Title I medical-inquiry restrictions**, barring disability inquiries before a conditional offer
- **Decision Layer audit trail** retained per the longest applicable rule, from the AI system log lifetime under the EU AI Act to 5 years under the FCRA

## Decision-Maker Distribution Pre-Hire-Due-Diligence

| Decision Type | Count | Decider | Examples |
|---|---|---|---|
| Rule-based deterministic | 9 | R | Jurisdiction routing, verification matrix, FCRA Section 604(b) consent, Form I-9 review, result validation, Pre-Adverse Action Notice, dispute handling, audit trail |
| ML-augmented intent indicator | 3 | A | Parallel verification orchestration, EU AI Act bias monitoring, SLA progress tracking |
| Mandatory human escalation | 2 | H | DPIA and FRIA, with EEOC individualised assessment at final hiring approval |

The 9 rule-based decisions handle deterministic procedural routing, where a statute citation determines the outcome. The 3 AI-augmented decisions provide indicators - the model output is an indicator, not a final decision. The 2 human escalations are the DPIA and FRIA, required by GDPR Article 35 and EU AI Act Article 27, and the EEOC individualised assessment at final hiring approval.

An escalation is triggered by a missing FCRA disclosure or Pre-Adverse Action Notice, a criminal-record discrepancy needing an individualised assessment, a Form I-9 gap, a spent-conviction discrepancy under the ROA 1974, a visa risk, or a bias indicator. Each one produces signed reasoning from the Talent Acquisition Director, DPO, EEO Officer, Hiring Manager and Compliance Officer, logged to the Decision Records as the basis for a later regulatory audit or class-action defence.

--- Probation Management Agent ---
> Probation deadline tracking: US at-will employment, UK Section 94 ERA 1996 + ACAS Code, Title VII discrimination check and EU GDPR Art. 88 - 30/60/90-day feedback and extension workflow.

Cross-jurisdictional probation management answers to four parallel statutory regimes. In the US, at-will employment governs probation, but full Title VII and related anti-discrimination protection applies throughout. In the UK, the Section 94 right not to be unfairly dismissed normally needs two years' service, though the automatically-unfair reasons apply from day one. Across the EU, GDPR Article 88 governs probation data and Member State works council rules - the German Section 102 hearing among them - constrain any termination. And ISO 30414 supplies the human capital reporting baseline. A 2,000-employee company hiring at 8 percent a year carries about 13 active probation periods at once - more than 150 deadlines, feedback dates and decision points over a year - and IAB research finds roughly a quarter of new hires leave within six months.

## Probation deadline monitoring as compliance obligation

This agent follows the [Decision Layer](/en/decision-layer/) principle: each decision is either rule-based, AI-assisted, or explicitly assigned to a human - and the human spots are reserved for retention decision and works council co-determination.

A line manager forgets that an employee reaches probation end on day 178 of a 180-day window. HR notices on day 175 and sends an urgent reminder, the manager rushes a feedback form on day 177, and the retention decision is made under time pressure on day 178. In Germany the Section 102 works council hearing alone needs a week, so termination is effectively impossible and the employee becomes permanent by default - a poor performer who should have been let go now holds full unfair-dismissal or discrimination protection. The same thing happens when a disparate-impact charge lands: spread across spreadsheet trackers, calendar reminders and departed managers' drives, HR cannot prove which milestone reviews were completed at the time of the alleged action.

The problem is not manager negligence. It describes the normal state in HR departments that maintain probation oversight across legacy structures: a spreadsheet for probation end dates, a calendar reminder system for milestones, an email distribution list for feedback forms, a paper folder in the line manager office, an HRIS for digital onboarding consents. Each system has its own logic, its own permissions, its own gaps.

## At-will in the US, Section 94 in the UK, six months across the EU

In the US, at-will employment governs probation in 49 of 50 states (Montana excepted): either side may end it at any time, except where anti-discrimination law forbids it. The 90-day period is customary, not statutory, and the employee keeps full Title VII, ADEA, ADA and equal-pay protection throughout, with an EEOC charge open for 180 days.

In the UK, the Section 94 right not to be unfairly dismissed normally needs two years' continuous service, but the automatically-unfair reasons - pregnancy, trade union, whistleblowing, health and safety - carry no qualifying period. A three-to-six-month probation is customary, the ACAS Code applies, and Section 86 sets a one-week minimum notice after a month's service.

Across the EU the period and protections vary: a six-month Probezeit in Germany with the binding Section 102 works council hearing, a two-to-four-month periode d'essai in France, a six-month periodo di prova in Italy, a three-month okres probny in Poland and a two-to-six-month periodo de prueba in Spain.

## Discrimination check on manager feedback

The agent checks every manager feedback text against the EEOC Compliance Manual, the Bostock v. Clayton County (2020) precedent on sexual orientation and gender identity, the UK EHRC Code of Practice and Employment Tribunal precedent. That flagging is an indicator, not a final decision: flagged feedback routes to General Counsel, the DPO and the HR Director for human review. Against US law it checks the Title VII protected classes alongside ADEA age protection, ADA reasonable accommodation and equal-pay rules; against UK law it checks the Equality Act 2010 protected characteristics alongside the harassment and victimisation provisions.

In practice the agent surfaces potentially discriminatory language, missing accommodation considerations and disparate-impact risk. Compensation remarks are additionally checked against US state pay-transparency laws, and any comment touching parental leave or lactation against the Pregnant Workers Fairness Act and the PUMP Act.

## GDPR Article 88 and works council co-determination

GDPR Article 88 lets each Member State set more specific rules for employee data through law or collective agreement, and the EDPB guidelines clarify the lawful basis for probation tracking: in employment, consent is generally invalid because of the power imbalance, so processing rests on the contract, a legal obligation or a balanced legitimate interest, with a works council agreement supplementing - never replacing - that basis. Health records during sickness absence are special-category data needing an Article 9 employment-law derogation. Because Article 22 bars fully automated decisions with legal effect, the probation termination decision must stay with a person, and Article 35 makes a DPIA mandatory for systematic monitoring.

Works council co-determination varies sharply across the EU. In Germany it is binding on technical monitoring and personnel measures, and the Section 102 hearing is required before a dismissal - without it the termination is invalid. France runs CSE consultation, Italy and Spain their works-council equivalents, and the UK applies the Information and Consultation of Employees Regulations 2004. The agent identifies terminations subject to co-determination, orchestrates the consultation timeline, tracks the works council's position and escalates blocking objections to General Counsel.

## Cross-reference to Onboarding-Workflow and Performance-Review-Documentation

The Probation Management Agent takes the probation start date from the Onboarding-Workflow Agent, hands a confirmed employee to the Performance-Review-Documentation Agent for the standard review cycle, and routes a termination to the Offboarding Agent. It draws jurisdiction-specific policies from the Policy-Document Agent, retention from the HR-Document-Management Agent, and SOX 404 and DPIA checks from the Audit-Compliance Agent. Two of its three core components - the milestone scheduling engine and manager feedback collection - are generic infrastructure: the Performance Review Documentation Agent reuses the milestone tracking, the Compliance Monitoring Agent reuses the DPIA trigger detection, and the Audit Agent relies on the acknowledgement evidence for proof.

## At a glance

- 9 deterministic procedural decisions, 5 AI-augmented indicators and 1 mandatory human escalation
- Jurisdiction-specific probation duration, from a US 90-day standard to a German six-month Probezeit
- Discrimination check on every manager feedback against Title VII, the UK Equality Act 2010 and GDPR Article 88
- Works council consultation orchestrated per EU Member State and under the UK consultation regulations
- The retention decision kept with a person, as GDPR Article 22 requires
- Acknowledgement evidence captured to defend an Employment Tribunal claim or EEOC charge
- ISO 30414 human capital metrics: early-attrition rate, probation pass rate, time-to-productivity

## Decision-Maker Distribution Probation-Management

| Decision Type | Count | Example | Challengeable |
|---|---|---|---|
| R Rule-based | 9 | Probation end-date calculation, milestone scheduling, reminder notification, submission tracking, end-date alert, DPIA trigger detection, works council consultation, downstream actions, audit-trail logging | not applicable |
| A AI-augmented | 5 | Feedback question generation, manager feedback sentiment analysis, discrimination check, archival metadata extraction | auditor |
| H Human escalation | 1 | Probation outcome decision (continue, extend, terminate) and works council co-determination | not applicable |

--- Promotion-Process Agent ---
> Promotion decisions with bias audit: Title VII/Equal Pay Act, EU AI Act Annex III(4)(b) high-risk, EU Pay Transparency 2023/970 5% gap threshold and 25+ US State/City Pay Transparency Laws.

## Promotion as compliance trap between Title VII and EU AI Act

This agent follows the [Decision Layer](/en/decision-layer/) principle: each decision is either rule-based, AI-assisted, or explicitly assigned to a human. It is classified per [EU AI Act 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) Annex III(4)(b) as high-risk system - and promotion decisions are explicitly named in the regulation among the high-risk HR use cases. From 2.8.2026 the agent is therefore subject to enhanced obligations on Risk Management System, Data Governance, Transparency, Human Oversight, and Bias-Audit on promotion patterns.

A typical promotion cycle takes eight months. Manager nomination in March. Documentation collection in April. HR business partner review in May. Calibration round in June. Compensation Committee review in July. Approval finalization in August. Communication to employees in September. Effective date in October. First payout with new band in November. The McKinsey Women in the Workplace study has documented this for a decade: for every 100 men who receive their first promotion to manager, 81 women do.

The problem is not the time it takes. It is what happens between the steps - or rather what does not: no systematic equity analysis across protected classes, no documented rationale for a Title VII challenge, no band-jump consistency check, and no defensible audit trail when an EEOC or EHRC pattern-and-practice investigation arrives.

## EU AI Act high-risk classification, DPIA and FRIA

The Promotion-Process Agent falls under EU AI Act 2024/1689 Annex III Point 4 Letter b - the regulation explicitly lists promotion decisions as high-risk HR AI use cases alongside performance evaluation and compensation recommendations. The obligations from 2.8.2026 include:

- **Article 9 Risk Management System**: identifying, assessing and mitigating bias risks in promotion patterns across gender, age, ethnicity and disability
- **Article 10 Data Governance**: training-data quality and bias detection through demographic-parity and equal-opportunity tests
- **Article 13 Transparency Obligations**: documentation of how the system works, its accuracy and robustness, and its bias-audit results
- **Article 14 Human Oversight**: mandatory human-in-the-loop on every promotion recommendation
- **Article 26 Deployer Obligations**: a DPIA, supervisory-authority consultation, post-market monitoring and incident reporting on promotion-bias incidents
- **Article 27 FRIA Fundamental Rights Impact Assessment**: before deployment, in consultation with the DPO and the works council or union

Fines up to 35M EUR or 7 percent global group revenue. Cross-Reference EU GDPR Article 35 DPIA obligation in systematic automated assessment with significant impact on the employment relationship. The [Mobley v. Workday class action](https://www.courtlistener.com/docket/67476007/mobley-v-workday-inc/) (Northern District California 2023) - allegation AI bias in HR recruitment software against 40+ candidates ADEA - serves as US precedent and shapes EU regulator line on promotion software because the same statistical-discrimination reasoning extends to internal promotion candidate ranking.

## US Title VII, the Equal Pay Act and state pay transparency

Title VII (42 USC 2000e) prohibits promotion discrimination on the basis of race, colour, religion, sex or national origin, and the Equal Pay Act (29 USC 206(d)) applies to the resulting pay change. The Lilly Ledbetter Fair Pay Act of 2009 restarts the statute of limitations with each new paycheck, so a missed promotion or an undervalued band-entry decision can be litigated years later, once subsequent paychecks reveal the pattern.

ADEA Age Discrimination in Employment Act 1967 (40+ years protected) applies at promotion eligibility screening - the Mobley v. Workday class action precedent extends directly to internal promotion candidate ranking when AI software systematically deprioritizes 40+ candidates. ADA Americans with Disabilities Act applies to promotion accommodation. GINA Genetic Information Nondiscrimination Act prohibits genetic-information-based screening at promotion.

More than 25 US state and city pay-transparency laws now reach internal promotion postings. California SB 1162 requires a pay range on the posting and three years of records for promotion candidates. Colorado's Equal Pay for Equal Work Act goes furthest, requiring proactive notice of every internal promotion opportunity to all employees. EEOC enforcement of EEO-1 Component 2 demographic-pay reporting now covers promotion-driven changes as well.

## UK Equality Act 2010 and Section 78 Gender Pay Gap

The UK Equality Act 2010 protected characteristics apply at every promotion decision, and the equal-pay provisions consolidated into Sections 64 to 66 apply to the comparator analysis behind the resulting pay change.

Section 78 makes gender pay gap reporting mandatory each year for employers of 250 or more, due by 4 April. The EHRC has increasingly focused on promotion-gap indicators within that report, because promotion patterns drive much of the structural pay gap, and the ACAS Code sets out fair promotion procedure. The Mobley v. Workday precedent applies by analogy here, since UK courts have consistently followed US reasoning on age bias in HR software, and Companies House publishes the gender pay gap data so that missing or non-compliant figures invite EHRC enforcement.

## Mobley v. Workday class action precedent for promotion software

Mobley v. Workday (Northern District of California, 2023, certified in 2024) concerns AI bias in HR recruitment software against candidates over 40 under the ADEA. It matters for promotion software because the same statistical-discrimination reasoning extends to internal promotion ranking: when a model systematically deprioritises older employees in promotion screening, the same class-action exposure follows.

The risk vectors are familiar - training data that underrepresents older employees in senior bands, proxy variables for age driving the ranking, feedback loops where AI-suggested rankings shape future training data, and opacity when employees cannot challenge an automated ranking under GDPR Article 22(3). The mitigations are a quarterly bias audit with demographic-parity and equal-opportunity tests, a documented rationale for the Title VII audit trail, and a FRIA before deployment. The EEOC's Algorithmic Discrimination Initiative targets exactly this, and the EU AI Act naming of promotion decisions reflects the same regulatory awareness.

## Cross-reference to Merit-Cycle-Governance, Compensation-Benchmarking, and Performance-Review-Documentation

The Promotion-Process Agent sits in a pipeline of specialised HR agents. The [Merit-Cycle-Governance Agent](/en/hr-agent-catalog/merit-cycle-governance-agent/) reuses the Promotion Equity Analysis Engine for the annual compensation cycle. The [Compensation-Benchmarking Agent](/en/hr-agent-catalog/compensation-benchmarking-agent/) provides the bands, Compa-Ratios and pay-range entry data for the target band. The [Performance-Review-Documentation Agent](/en/hr-agent-catalog/performance-review-documentation-agent/) supplies the ratings and 360 feedback used as an eligibility prerequisite. The [Payroll-Calculation Agent](/en/hr-agent-catalog/payroll-calculation-agent/) receives the approved promotion with its effective date, new band and pay. The [Payroll-Reporting Agent](/en/hr-agent-catalog/payroll-reporting-agent/) generates the CSRD, SEC Pay Ratio and UK Section 78 figures. The [HR-Document-Management Agent](/en/hr-agent-catalog/hr-document-management-agent/) archives the Title VII rationales and contract amendments, and the [Audit-Compliance Agent](/en/hr-agent-catalog/audit-compliance-agent/) verifies the EU AI Act deployer obligations and DPIA consistency.

## At a glance

- **Classification**: EU AI Act 2024/1689 Annex III(4)(b) high-risk HR Promotion Decisions explicitly named in the regulation, applicable from 2.8.2026
- **Compliance anchors**: Title VII and the Equal Pay Act in the US, the UK Equality Act and Section 78, and the EU Pay Transparency Directive 2023/970, with GDPR Article 22 and CSRD ESRS S1-13 reporting
- **Codetermination**: German Section 99 works council co-determination for personnel measures, with the UK ACAS Code applying
- **Equity threshold**: an unexplained gender promotion gap above 5 percent triggers a Joint Pay Assessment and a six-month remediation duty
- **Fines**: up to 35M EUR or 7 percent of global group revenue under the EU AI Act, up to 4 percent under GDPR, on top of Title VII class-action damages and UK EHRC enforcement
- **Audit obligation**: a DPIA, a FRIA and a quarterly bias audit, with CSRD auditor verification from 250 employees and the UK Section 78 annual report
- **US precedent**: Mobley v. Workday Northern District California 2023 class action AI bias HR software applied analogously to internal promotion candidate ranking

### Decision-Maker Distribution Promotion-Process

| Step | Decider | Rationale |
|------|---------|-----------|
| Manager nomination | H | Individual assessment, business need, retention rationale |
| Eligibility validation | R | Tenure, performance and disciplinary rules |
| Band-jump validation | R | Role architecture and Hay Points |
| Headcount validation | R | Headcount plan and open requisitions |
| Pay-band entry check | R | Min-max range and Compa-Ratio entry position |
| Documentation assembly | A | LLM-supported summarization with human validation |
| Promotion equity analysis | A | ML-statistical bias detection across protected classes |
| Budget tracking | R | Real-time business-unit budget deterministic |
| Equity escalation | R | Threshold >5 percent EU Pay Transparency 2023/970 |
| Approval workflow | R | Approval matrix by band-jump magnitude, hierarchy and pay-change impact |
| Works council notification | R | German Section 99 co-determination workflow |
| HR Lead approval | H | Final approval Title VII-compliant |
| EU GDPR information | R | Article 13+14+22 (3) standard workflow |
| Promotion documentation | A | Model-drafted letter and contract amendment |
| CSRD/SEC reporting | R | ESRS S1-13 and Pay Ratio disclosure |

--- Sick Leave Processing Agent ---
> Processes sick certificates in 60 seconds, hiding the diagnosis from the line manager by design and meeting every FMLA and statutory-pay deadline.

Cross-jurisdictional sick leave processing answers to four parallel statutory regimes. In the US, ADA Title I governs medical confidentiality and accommodation, FMLA the leave entitlement, and the HIPAA Privacy Rule the handling of health data, layered with state Paid Family Leave and workers compensation. In the UK, Statutory Sick Pay runs at 116.75 GBP per week for up to 28 weeks, with the Equality Act 2010 Section 20 reasonable-adjustments duty and RIDDOR reporting. Across the EU, GDPR Articles 9 and 88 govern the health data, and ISO 30414 supplies the occupational-health reporting baseline. A single sick certificate can trigger all four at once. Yet in a typical 2,000-employee organisation half of return-to-work-eligible employees never receive a formal offer because the threshold crossing is missed, and medical confidentiality is breached on 15 to 20 percent of manager notifications.

## Sick leave in 60 seconds instead of three weeks postal delay

This agent follows the [Decision Layer](/en/decision-layer/) principle: each decision is either rule-based, AI-assisted, or explicitly assigned to a human - and the human spots are reserved for ADA reasonable accommodation interactive process and the return-to-work conversation.

Every morning new sick leave notifications arrive, and on Mondays after a flu wave there can be dozens. Each one triggers a cascade: match it to the right employee, determine whether it is an initial or follow-up certificate, calculate the pay entitlement, check the absence history, send the FMLA Notice of Eligibility and Designation Notice within 5 business days, report to the state PFL and disability carriers, adjust payroll, notify the line manager without the diagnosis, and monitor the return-to-work threshold.

The UK average is 5.7 sick days per employee per year; the US average is 7 to 11. In a 2,000-employee organisation that means 11,400 to 22,000 absence days a year. The problem is not the complexity of any individual sick note - it is the volume combined with zero error tolerance. A SharePoint folder, a PDF email attachment, a paper handbook and a three-week postal delay together create the conditions for missed FMLA deadlines, state PFL reporting failures, HIPAA breaches and ADA accommodation gaps.

## US ADA Title I and reasonable accommodation

ADA Title I (42 USC 12112(d)) prohibits medical inquiries beyond what is job-related and necessary, and requires medical confidentiality: separate medical files, restricted access, and supervisors told only of restrictions and accommodations, never the diagnosis. The 2008 amendments broadened the disability definition and put the reasonable-accommodation interactive process at the centre, weighing essential functions and undue hardship.

The agent identifies a potential ADA accommodation trigger - or a UK Equality Act 2010 Section 20 reasonable-adjustments trigger - against the EEOC guidance, the EHRC Code and Employment Tribunal precedent. That flagging is an indicator, not a final decision: flagged cases route to HR for determination. The agent makes no accommodation decision, interprets no medical condition, and does not start the interactive process itself.

## US FMLA, state Paid Family Leave and disability insurance

FMLA (29 USC 2601, 29 CFR Part 825) provides 12 weeks of unpaid, job-protected leave for a serious health condition, with eligibility at 1,250 hours over 12 months in a 50-employee location, healthcare-provider certification, and intermittent or military-caregiver variants. The Notice of Eligibility and Designation Notice are each due within 5 business days, and a missed deadline brings DOL Wage and Hour enforcement, back pay and doubled liquidated damages.

State Paid Family Leave operates independently of FMLA - the New York programme, for example, gives 12 weeks at 67 percent wage replacement - and several states add short-term disability insurance up to 52 weeks. Workers compensation runs in all 50 states with its own waiting periods and return-to-work programmes.

The agent applies the state-by-state designation rules, identifies stacking opportunities, tracks the remaining entitlement balance, flags concurrent-leave designations for HR review, and ensures the FMLA notices go out within 5 business days.

## UK Statutory Sick Pay and Med 3 fit notes

Statutory Sick Pay, under the Social Security Contributions and Benefits Act 1992, runs at 116.75 GBP per week for the 2024-25 tax year, up to a maximum of 28 weeks. It covers a Period of Incapacity for Work of four or more consecutive days, with linked periods within 8 weeks treated as one, three waiting days, and HMRC enforcement through PAYE. When entitlement is exhausted the employer issues an SSP1 form and the employee moves to Employment and Support Allowance.

The fit note (Med 3) can now be signed by a range of healthcare professionals since the 2022 Health and Care Act, may state "fit for work with adjustments" or "not fit for work", and runs to a maximum of six months. RIDDOR requires reporting of over-7-day incapacity from a work-related injury within 15 days, under HSE enforcement with an unlimited fine on indictment.

The Equality Act 2010 also bears on sick leave through the Section 20 reasonable-adjustments duty. The agent calculates SSP automatically, tracks linked periods within 8 weeks, monitors the 28-week threshold, generates the SSP1 form, and tracks RIDDOR-reportable cases.

## GDPR Article 88, the HIPAA Privacy Rule and medical confidentiality

Sick leave records are special-category data under GDPR Article 9, which demands more than access controls and encryption - it requires an architecture that enforces data minimisation by design. Processing rests on the employment and occupational-medicine derogations under Article 9(2)(b) and (h), with a mandatory Article 35 DPIA, and Article 22 keeps any decision with legal effect out of full automation.

The EDPB guidelines confirm that health data needs the employment derogation, works council consultation per Member State, and minimum-necessary processing. Germany applies this through BDSG Section 26 and works council co-determination, and the UK mirrors it through the DPA 2018 employment derogation and the ICO Employment Practices Code.

In the US, the HIPAA Privacy Rule sets the minimum-necessary standard with a Business Associate Agreement and group-health-plan separation, and ADA medical confidentiality requires separate medical files with supervisors told only of restrictions and accommodations, never the diagnosis.

The agent processes absence periods only where strictly necessary for deadline calculations. The diagnosis is never forwarded to the line manager, stored in the notification text, or written to the Decision Log. Forwarding a sick note as a PDF by email creates a data-protection problem even when no one intends it; a rule-based agent avoids that structurally, because the information architecture prescribes which data reaches which recipient.

## Cross-reference to Payroll-Processing, Leave-of-Absence and HR-Document-Management

The Sick Leave Processing Agent supplies the medical certification and entitlement calculation to the Payroll Processing, Leave of Absence and Performance Improvement agents, draws retention and audit trail from the HR Document Management Agent, and triggers the Performance Improvement Agent for the ADA interactive process and return-to-work conversation. Payroll uses its pay-basis output, Leave of Absence its concurrent-leave designation rules, and Audit Compliance its deadline tracking and HIPAA breach detection.

The agent handles the volume, the deadlines and the statutory notifications, while the person retains the decisions that need judgement. In the return-to-work context only about half of eligible employees actually receive a formal offer - not because organisations ignore the obligation, but because the threshold crossing is missed in manual processes. An agent that reliably counts cumulative absence days ensures HR learns about every single case.

## At a glance

- 11 deterministic procedural decisions, 3 AI-augmented indicators and 1 mandatory human escalation
- US ADA Title I and FMLA, with state Paid Family Leave, disability insurance, the HIPAA Privacy Rule and workers compensation
- UK Statutory Sick Pay at 116.75 GBP per week for 28 weeks, Med 3 fit notes, the Equality Act Section 20 duty and RIDDOR reporting
- GDPR Articles 9 and 88, a mandatory Article 35 DPIA, and Member State works council co-determination
- ISO 30414 occupational-health-and-safety metrics, backed by a SOC 2 Type II report
- Medical confidentiality minimum necessary standard - line managers learn an employee is absent without learning the diagnosis

## Decision-Maker Distribution Sick-Leave-Processing

| Decision Type | Count | Example | Challengeable |
|---|---|---|---|
| R Rule-based | 11 | Certificate validation, employee match, overlap detection, entitlement calculation, statutory notifications, manager notification, threshold detection, audit trail | not applicable |
| A AI-augmented | 3 | Document classification, ADA and UK reasonable-adjustment flagging, payroll sync, pattern-recognition routing | auditor, employee |
| H Human escalation | 1 | Manager review, ADA interactive process, UK reasonable adjustments, return-to-work conversation | not applicable |

--- Skills-Career-Profile Agent ---
> Skills-based talent classification: Title VII/Equal Pay Act, EU AI Act Annex III(4)(b) high-risk task assignment, ESCO European Skills + O*NET + Lightcast - GDPR Art. 22 human-in-the-loop.

## Skills-matching as compliance trap between Title VII and EU AI Act

This agent follows the [Decision Layer](/en/decision-layer/) principle: each decision is either rule-based, AI-assisted, or explicitly assigned to a human. It is classified per [EU AI Act 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) Annex III(4)(b) as high-risk system - and AI systems for task-assignment based on individual behavior or personal traits are explicitly named in the regulation among the high-risk HR use cases. From 2.8.2026 the agent is therefore subject to enhanced obligations on Risk Management System, Data Governance, Transparency, Human Oversight, and Bias-Audit on skills-ranking patterns.

A typical skills-classification cycle takes six months from skill extraction to internal-mobility communication. The lag between skill emergence on the job and recognized skills-tag in the HRIS is typically 9-14 months - a 40+ employee who acquires a new skill is systematically late in being matched to internal-mobility opportunities versus a younger peer with the same actual skill.

The problem is not the time it takes. It is what happens between the steps: no systematic equity analysis across protected classes, no documented rationale for a Title VII challenge, no competency-cluster consistency check, no auditable taxonomy reference, and no defensible audit trail when an EEOC or EHRC pattern-and-practice investigation arrives.

## EU AI Act Annex III(4)(b) task-assignment-personal-traits high-risk

The Skills-Career-Profile Agent falls under EU AI Act 2024/1689 Annex III Point 4 Letter b - the regulation explicitly lists AI systems for task-assignment based on individual behavior or personal traits as high-risk HR AI use cases. The obligations from 2.8.2026 include:

- **Article 9 Risk Management System**: identifying, assessing and mitigating bias risks in skills-ranking patterns across gender, age, ethnicity and disability
- **Article 10 Data Governance**: training-data quality and bias detection through demographic-parity and equal-opportunity tests, anchored in the public ESCO, O*NET, Lightcast and UK NQF taxonomies
- **Article 13 Transparency Obligations**: documentation of how the system works, its accuracy and robustness, and its bias-audit results
- **Article 14 Human Oversight**: mandatory human-in-the-loop on every skills-classification recommendation
- **Article 26 Deployer Obligations**: a DPIA, supervisory-authority consultation, post-market monitoring and incident reporting on skills-bias incidents
- **Article 27 FRIA Fundamental Rights Impact Assessment**: before deployment, in consultation with the DPO and the works council or union

Fines up to 35M EUR or 7 percent global group revenue. Cross-Reference EU GDPR Article 35 DPIA obligation in systematic automated assessment with significant impact on the employment relationship. The [Mobley v. Workday class action](https://www.courtlistener.com/docket/67476007/mobley-v-workday-inc/) (Northern District California 2023) serves as US precedent and shapes EU regulator line on skills-classification software because the same statistical-discrimination reasoning extends to internal-mobility ranking based on AI-extracted skills profiles.

## US Title VII, the Equal Pay Act and the UK Equality Act

Title VII (42 USC 2000e) prohibits skills-based assignment discrimination on the basis of race, colour, religion, sex or national origin, and the Equal Pay Act (29 USC 206(d)) applies to the resulting pay change when skills-classification drives compensation banding. The Lilly Ledbetter Fair Pay Act of 2009 restarts the statute of limitations with each new paycheck, so an undervalued classification or a missed skill tag can be litigated years later, once subsequent paychecks reveal the pattern.

ADEA Age Discrimination in Employment Act 1967 (40+ years protected) applies at skills-based internal-mobility screening - the Mobley v. Workday class action precedent extends directly to skills-classification ranking when AI software systematically deprioritizes 40+ candidates in emerging skills clusters. ADA Americans with Disabilities Act applies to competency-profile accommodation. GINA Genetic Information Nondiscrimination Act prohibits genetic-information-based skills-tagging. EEOC Algorithmic Discrimination Initiative 2021-2026 explicitly targets AI-driven skills-classification screening as a top enforcement priority.

The UK Equality Act 2010 protected characteristics apply at every skills-classification decision, and the equal-pay provisions consolidated into Sections 64 to 66 apply to the comparator analysis behind the resulting pay change. The Mobley v. Workday precedent applies by analogy here, since UK courts have consistently followed US reasoning on age bias in HR software.

## US state pay transparency and UK Section 78 Gender Pay Gap

More than 25 US state and city pay-transparency laws now reach skills-driven internal-mobility postings. California SB 1162 requires a pay range on the posting and three years of records for the candidates. Colorado goes furthest, requiring proactive notice of every internal-mobility opportunity to all employees. EEOC enforcement of EEO-1 Component 2 demographic-pay reporting now covers these skills-driven changes as well, and UK Section 78 makes gender pay gap reporting mandatory each year above 250 employees.

UK Section 78 Gender Pay Gap Reporting Regulations 2017 require mandatory annual reporting >250 UK employees by 4 April - EHRC has been increasingly focused on skills-based internal-mobility gap indicators because skills-classification patterns drive much of the structural pay gap. ACAS Code of Practice provides procedural guidance. UK ICO enforces UK GDPR Article 22 automated decision-making prohibition. UK Companies House publishes gender pay gap data publicly - non-compliant skills-classification audit data triggers EHRC enforcement.

## The ESCO, Lightcast and O*NET taxonomies, and Mobley v. Workday

The skills-taxonomy backbone rests on four publicly maintained classifications. ESCO, from the European Commission, provides 13,944 skills and 3,008 occupations crosswalked to ISCO-08 across 27 EU languages. O*NET, from the US Department of Labor, provides over 1,000 occupations with their skills, abilities and knowledge. The Lightcast Open Skills Library provides over 32,000 open skills with machine-readable definitions, and the UK NQF supplies eight qualification levels under Ofqual regulation. Stable concept URIs make cross-system referencing auditable.

Mobley v. Workday (Northern District of California, 2023, certified in 2024) concerns AI bias in HR software against candidates over 40 under the ADEA. It extends to internal-mobility skills-fit ranking when a model systematically deprioritises older employees in emerging skills clusters. The risk vectors are familiar - training data that underrepresents older employees, proxy variables for age such as LMS recency driving the ranking, feedback loops, and opacity when an employee cannot challenge a ranking under GDPR Article 22(3). The mitigations are a quarterly bias audit with demographic-parity and equal-opportunity tests, a documented rationale for the Title VII audit trail, and a FRIA before deployment.

## Cross-reference to Promotion-Process, Performance-Review-Documentation and Succession-Planning

The Skills-Career-Profile Agent sits in a pipeline of specialised HR agents. The [Performance-Review-Documentation Agent](/en/hr-agent-catalog/performance-review-documentation-agent/) supplies the ratings and 360 feedback used as skills-extraction input. The [Promotion-Process Agent](/en/hr-agent-catalog/promotion-process-agent/) reuses the Skills Equity Analysis Engine for promotion equity analysis. The [Compensation-Benchmarking Agent](/en/hr-agent-catalog/compensation-benchmarking-agent/) receives the validated competency profiles for compensation banding, and the [Payroll-Reporting Agent](/en/hr-agent-catalog/payroll-reporting-agent/) generates the CSRD and ISO 30414 figures. The [HR-Document-Management Agent](/en/hr-agent-catalog/hr-document-management-agent/) archives the Title VII rationales, and the [Audit-Compliance Agent](/en/hr-agent-catalog/audit-compliance-agent/) verifies the EU AI Act deployer obligations on the skills-classification software.

## At a glance

- **Classification**: EU AI Act 2024/1689 Annex III(4)(b) high-risk HR Task-Assignment-Personal-Traits explicitly named in the regulation, applicable from 2.8.2026
- **Compliance anchors**: Title VII and the Equal Pay Act in the US, the UK Equality Act and Section 78, and the EU AI Act, with GDPR Article 22 and CSRD ESRS S1-13 reporting
- **Taxonomy reference**: ESCO (13,944 skills across 27 EU languages), O*NET (over 1,000 occupations), the Lightcast Open Skills Library (over 32,000 open skills) and the UK NQF (8 levels)
- **Codetermination**: German Section 87(1) No. 6 works council co-determination for the IT system, with the UK ACAS Code applying
- **Equity threshold**: an unexplained gender or age skills-classification gap above 5 percent triggers a Joint Pay Assessment and a six-month remediation duty
- **Fines**: up to 35M EUR or 7 percent of global group revenue under the EU AI Act, up to 4 percent under GDPR, on top of Title VII class-action damages and UK EHRC enforcement
- **Audit obligation**: a DPIA, a FRIA and a quarterly bias audit, with CSRD auditor verification from 250 employees and the UK Section 78 annual report
- **US precedent**: Mobley v. Workday Northern District California 2023 class action AI bias HR software applied analogously to skills-based internal-mobility candidate ranking

### Decision-Maker Distribution Skills-Career-Profile

| Step | Decider | Rationale |
|------|---------|-----------|
| Skill extraction | A | NLP extraction from reviews, projects and LMS records |
| Taxonomy mapping | R | ESCO, O*NET, Lightcast and UK NQF |
| Competency-cluster validation | R | Role architecture and Hay Points |
| Self-assessment intake | H | Individual employee claim with evidence |
| Manager validation | H | Line manager evidence review and proficiency confirmation |
| Skills equity analysis | A | ML-statistical bias detection across protected classes |
| Career-path simulation | A | Model-suggested next role and skills gap |
| Internal-mobility match | A | ML-supported skills-fit ranking against requisitions |
| Equity escalation | R | Threshold >5 percent EU Pay Transparency 2023/970 |
| Works council notification | R | German Section 87(1) No. 6 IT-system co-determination |
| HR Lead approval | H | Final approval Title VII-compliant |
| EU GDPR information | R | Article 13+14+22 (3) standard workflow |
| Skills-profile documentation | A | Model-drafted profile and career-development plan |
| CSRD/ISO reporting | R | ESRS S1-13 and ISO 30414 |

--- Strategic HR Analytics Agent ---
> Strategic HR analytics: turnover, CSRD ESRS S1-1/S1-9/S1-13 diversity reporting, Dodd-Frank 953(b) CEO Pay Ratio and board reporting for audit committee - GDPR Art. 88 aggregate analytics.

## From HR data to strategic insights

This agent follows the [Decision Layer](/en/decision-layer/) principle: each decision is either rule-based, AI-assisted, or explicitly assigned to a human. It is not a high-risk system under [EU AI Act 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) - it is aggregate analytics with no decision about an individual - but it answers to strict reporting and audit obligations: the CSRD ESRS S1 disclosures, the UK Section 78 gender pay gap, the SEC Pay Ratio, the EEO-1 report, ISO 30414, SOX 404 and GDPR Article 88.

A typical analytics cycle produces Board reports, audit committee briefings and ESG disclosures each quarter, the UK Section 78 and SEC Pay Ratio figures annually, and the EEO-1 Component 2 report by 31 March. Manual aggregation in Excel takes weeks; the agent generates the deterministic KPIs in hours from finished HR data across cost centre, entity, period and diversity dimensions, with multi-entity rollup.

The problem is not the volume. It is the audit-ready chain behind the numbers: the SOC 2 controls, the CSRD limited-assurance scope, the four-eyes sign-off by the CHRO, CFO and audit committee, the full audit trail with data lineage, the 7-year SOX retention, and works council co-determination over the analytics.

## CSRD ESRS S1, ISSB IFRS S1/S2 and the Dodd-Frank Pay Ratio

[EU CSRD 2022/2464](https://eur-lex.europa.eu/eli/dir/2022/2464/oj) mandates ESRS reporting from 250 employees with limited-assurance auditor verification. ESRS S1 Own Workforce covers the characteristics of the workforce, diversity metrics by gender, age, nationality and disability, compensation as a mean, median and highest-to-median ratio, and health and safety. The EFRAG datapoint reference maps each KPI back to its source data with full lineage.

ISSB IFRS S1 and S2 complement this for IOSCO-endorsed cross-border reporting, with a required structure of materiality assessment, governance, strategy, risk management and metrics.

The US SEC Pay Ratio Disclosure Rule (Item 402(u), Dodd-Frank Section 953(b)) requires the annual proxy to report the median employee's compensation, the CEO's total compensation and the ratio between them, with a reasonable methodology.

## Turnover, diversity and the UK Section 78 Gender Pay Gap

Turnover analysis breaks attrition into its components - voluntary, involuntary, regrettable, first-year and high-performer - by tenure cohort, with the cost to replace, against SHRM benchmarks. The agent calculates the rates deterministically per cohort with a full audit trail.

Diversity reporting covers the protected characteristics where they are lawfully collected, with intersectional cuts, representation rates, leadership diversity and promotion rates by cohort. Collection observes the GDPR Article 9 limits on special-category data and the UK Equality Act 2010 characteristics.

[UK Equality Act 2010 Section 78](https://www.legislation.gov.uk/uksi/2017/172) mandates annual gender pay gap reporting for employers of 250 or more, due by 4 April. Six figures are required: the median and mean hourly pay gap, the median and mean bonus gap, the bonus proportion, and the quartile distribution. The figures are enforced by the EHRC and published openly by Companies House.

## GDPR Article 88 and works council co-determination

GDPR Article 88 lets each Member State set more specific rules for employee data, and Article 9 governs the special-category data behind diversity metrics. The agent pseudonymises at extraction under Article 4(5), and aggregation thresholds of at least five employees per cohort prevent re-identification.

Works council co-determination is mandatory before the analytics go live in EU operations: a works council can block deployment, so consultation and agreement come first. A DPIA under Article 35 is also required before deployment, with an EU AI Act Article 27 FRIA where the ML indicators would trigger classification.

## Predictive analytics and HR ROI

The predictive layer - turnover prediction, flight-risk indicators, HR ROI, cost-per-hire, revenue-per-employee and leadership-pipeline strength - operates at the aggregate cohort level, not as individual scoring with HR consequences. The agent provides these as indicators with confidence scores for the Board dashboards.

Classifying them as AI-augmented, with mandatory human validation by the CHRO, CFO and Board and a challengeable auditor pathway, keeps the agent from drifting into automated individual decisions. No HR decision is automated - hiring, firing, promotion and compensation stay with people, reflecting the GDPR Article 22 right not to be subject to a solely automated decision.

The correlation engine over the engagement-survey platforms provides indicators only, and the ISO 30414 human capital metrics complement the ESRS reporting.

## Cross-reference to Performance-Review, Workforce-Planning and Succession-Planning

The [Performance-Review Agent](/en/hr-agent-catalog/performance-review-agent/) feeds individual ratings into the aggregate analytics for high-performer turnover analysis. The [Workforce-Planning Agent](/en/hr-agent-catalog/workforce-planning-agent/) uses the turnover predictions and flight-risk indicators for headcount planning and scenario modelling. The [Succession-Planning Agent](/en/hr-agent-catalog/succession-planning-agent/) uses the leadership-pipeline strength for board-level talent reviews. The [Payroll-Reporting Agent](/en/hr-agent-catalog/payroll-reporting-agent/) shares the reporting infrastructure for its statutory filings, and the [Compensation-Benchmarking Agent](/en/hr-agent-catalog/compensation-benchmarking-agent/) supplies the bands and Compa-Ratios for the UK Section 78, SEC Pay Ratio and ESRS S1-13 figures. The [Audit-Compliance Agent](/en/hr-agent-catalog/audit-compliance-agent/) verifies the SOX 404 and SOC 2 controls. The ESG-Reporting Agent extends the ESRS S1 and ISSB disclosures to full sustainability reporting, and the CFO-Reporting Agent integrates the HR analytics into the CFO dashboards.

## At a glance

- **Classification**: Compliance-Support, NOT EU AI Act high-risk (aggregate-analytics)
- **Compliance anchors**: CSRD ESRS S1 and ISSB IFRS S1/S2, the UK Section 78 gender pay gap, the SEC Pay Ratio and EEO-1 reports, ISO 30414, SOX 404 and GDPR Article 88
- **Retention**: 7 years for SOX records, 6 in the UK, with secure deletion afterwards
- **Approval**: a four-eyes sign-off by the CHRO, CFO and audit committee, with Board commentary kept human-only
- **Penalties**: a Big-4 limited-assurance qualification, EHRC and SEC enforcement, a SOX 906 criminal penalty of USD 5M or 20 years, and a GDPR fine up to 4 percent of group revenue
- **Audit obligation**: SOX 404 and SOC 2 controls, CSRD limited assurance from 250 employees, the UK Section 78 report by 4 April, the EEO-1 by 31 March, and EU works council co-determination
- **Cross-reference**: the Performance-Review, Workforce-Planning, Succession-Planning, Payroll-Reporting, Compensation-Benchmarking, ESG-Reporting, CFO-Reporting and Audit-Compliance agents

### Decision-Maker Distribution Strategic-HR-Analytics

| Step | Decider | Rationale |
|------|---------|-----------|
| HR data extraction, consolidation and pseudonymisation | R | Deterministic ETL mapping with GDPR Article 4(5) pseudonymisation |
| Aggregation by cost centre, entity, period and diversity | R | Deterministic aggregation rules per KPI type |
| CSRD ESRS S1 datapoint calculation | R | EFRAG ESRS datapoints, deterministic |
| ISSB IFRS S1 and S2 disclosure | R | Deterministic materiality assessment |
| SEC Pay Ratio (Item 402(u)) | R | Median employee, CEO total and ratio, deterministic |
| UK Section 78 Gender Pay Gap | R | Median, mean, quartile and bonus proportion, deterministic |
| EEO-1 Component 2 and OFCCP AAP | R | 10 categories and 12 pay bands, deterministic |
| ISO 30414 human capital metrics | R | 11 reporting categories, deterministic |
| Turnover analysis | R | Cohort-based turnover calculation, deterministic |
| Diversity reporting | R | Protected characteristics with intersectional cuts, deterministic |
| Employee-satisfaction correlations and eNPS | A | ML correlation indicators with human validation |
| Predictive analytics and HR ROI | A | ML predictive indicators with human validation |
| Audit committee and Board commentary approval | H | Four-eyes SOX 404 sign-off, interpretation mandatory |
| Distribution and retention | R | SOX 404 audit trail and retention, deterministic |

--- Succession Planning Agent ---
> Key-position succession: readiness assessment, high-potential identification, US SEC Item 401 director disclosure, UK Senior Managers Regime and ISO 30414 - CSRD ESRS S1-13 governance.

## Succession planning as strategic compliance obligation

This agent follows the [Decision Layer](/en/decision-layer/) principle: each decision is either rule-based, AI-assisted, or explicitly assigned to a human. It is not a high-risk system under the [EU AI Act 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) - it is strategic-planning aggregate analytics without automated nomination decisions - but it carries strict obligations from SEC Item 401, the UK Senior Managers Regime, CQC registered-manager rules, US and UK anti-discrimination law, GDPR, and the ESG and SOX reporting regimes.

A typical cycle produces annual board-level talent reviews and Nomination Committee briefings, keeps the UK Statement of Responsibilities current, and prepares SEC Item 401 disclosure for the annual filing. Manual readiness assessment in Excel takes weeks; the agent scores readiness in hours from HR data, standardised role profiles, competence-gap analysis, 9-box placement, tenure, and performance history.

The hard part is not volume. It is the auditable chain a regulator will pull on: an ESG limited-assurance scope, four-eye sign-off, a full audit-trail with data lineage, multi-year SOX retention, works-council co-determination, and an EEOC four-fifths disparate-impact check on every Hi-Po classification.

## US SEC Item 401, the UK Senior Managers Regime, and Audit Committee oversight

[US SEC Item 401](https://www.sec.gov/divisions/corpfin/guidance/regs-kinterp.htm) of Regulation S-K requires director and executive-officer disclosure in the annual filing, covering business experience, family relationships, legal proceedings, and succession-plan readiness. Dodd-Frank and the NYSE and Nasdaq listing standards layer on the broader governance framework and Nomination Committee oversight.

The [UK Senior Managers Regime](https://www.fca.org.uk/firms/senior-managers-certification-regime) applies individual accountability to FCA-authorised firms: every Senior Management Function holder has a documented Statement of Responsibilities, so the succession plan must name designated successors with an FCA approval pathway. The PRA's equivalent regime covers insurers.

For healthcare providers, the CQC registered-manager succession regime under the Health and Social Care Act 2008 mandates a fit-and-proper-person test, with the clinical professional bodies (NMC, GMC, HCPC) relevant for clinical roles.

## Title VII, the UK Equality Act, and Hi-Po classification discrimination

High-Potential classification carries a known disparate-impact risk. In the US, Title VII and the related anti-discrimination statutes govern protected characteristics; in the UK, the Equality Act 2010 and the Public Sector Equality Duty do.

The agent runs a mandatory disparate-impact analysis - the EEOC four-fifths rule - across protected characteristics (gender, age, race, ethnicity, disability where lawfully collected) before any Hi-Po classification, recording a rationale per decision. This is why Hi-Po decisions here always carry documented reasoning.

The Mobley v. Workday precedent shapes the safeguards: Hi-Po classification is rule-based with the four-fifths check and human approval by the CHRO and Nomination Committee. ML outputs are development indicators, not classification decisions.

## GDPR Article 22 and works-council aggregate-analytics

GDPR governs the data side of succession planning - Article 6 lawful basis, Article 9 special categories, Article 22 automated individual decision-making, and Article 88 Member State employment law. The agent pseudonymises at extraction (Article 4(5)) and applies aggregation thresholds (a minimum of five candidates per cohort for diversity-gap indicators) to prevent re-identification.

Works-council co-determination under the EU Information and Consultation Directive and national co-determination acts is mandatory before any aggregate-analytics go-live in the EU; a works-council objection blocks it. The EDPB HR-AI guidelines and the national supervisory authorities are the reference points here.

A GDPR Article 35 DPIA and an EU AI Act Article 27 FRIA are required before deployment. Development recommendations and pipeline-gap, retirement-risk, and flight-risk signals are not individual decisions under Article 22 - they are dashboard indicators with human validation.

## Skills taxonomies, Mobley v. Workday, and AI considerations

Role profiles for key positions are built from standardised skills taxonomies: ESCO (maintained by the European Commission and Cedefop), the UK National and Regulated Qualifications Frameworks (Ofqual, QAA), the Lightcast skills taxonomy, and O*NET (US DOL BLS). Each profile carries skills, competences, qualifications, and experience levels, cross-walked across taxonomies for international portability.

Readiness scoring then runs a deterministic competence-gap analysis against the profile, combined with tenure thresholds, performance history, and 9-box placement.

Development recommendations and pipeline-gap, retirement-risk, and diversity-gap indicators all operate at the aggregate cohort level, not on individual nominations. They reach the Board as dashboard signals with confidence scores. The Decision-Type A classification - mandatory human validation by the CHRO, CEO, and committees, with a challengeable auditor pathway - keeps them from drifting into automated individual decisions.

No nomination is ever automated: hiring, firing, promotion, and nomination stay human. This follows EU AI Act Annex III(4), GDPR Article 22, and the Mobley v. Workday precedent.

## Cross-reference to Skills-Career-Profile, Promotion-Process, and Workforce-Planning

[Skills-Career-Profile-Agent](/en/hr-agent-catalog/skills-career-profile-agent/) supplies the individual skills and career profiles that this agent matches to key-position role profiles. [Promotion-Process-Agent](/en/hr-agent-catalog/promotion-process-agent/) provides eligibility data used for Ready-Now classification. [Workforce-Planning-Agent](/en/hr-agent-catalog/workforce-planning-agent/) consumes bench strength and retirement risk for headcount scenarios. [Performance-Review-Agent](/en/hr-agent-catalog/performance-review-agent/) feeds ratings into 9-box placement. [Strategic-HR-Analytics-Agent](/en/hr-agent-catalog/strategic-hr-analytics-agent/) draws on leadership-pipeline strength for board-level reviews and ESG reporting. [Compensation-Benchmarking-Agent](/en/hr-agent-catalog/compensation-benchmarking-agent/) provides bands for retention plans. [Audit-Compliance-Agent](/en/hr-agent-catalog/audit-compliance-agent/) verifies SOX 404, SOC 2, and disclosure readiness for SEC Item 401 and the UK regimes. The Diversity-Equity-Inclusion-Agent supplies the protected-characteristic data for the four-fifths check.

## At a glance

- **Classification**: Compliance-Support, not EU AI Act high-risk (strategic-planning aggregate analytics)
- **Compliance anchors**: SEC Item 401, the UK Senior Managers Regime and CQC registered-manager rules, US and UK anti-discrimination law, GDPR, and the ESG, ISO 30414, and SOX 404 reporting regimes
- **Retention**: 7 years for SOX records, 6 years in the UK, then GDPR Article 17 erasure and secure deletion
- **Approval**: four-eye principle (CHRO, CEO, Nomination and Audit Committees); interpretation and nomination decisions human-only
- **Penalties**: enforcement under SEC Item 401, the UK Senior Managers Regime, CQC, and anti-discrimination law, GDPR fines up to 4 percent of group revenue, and SOX criminal exposure
- **Audit obligation**: SOX 404 and SOC 2, ESG limited assurance from 250 employees, a continuous UK Statement of Responsibilities, annual CQC fit-and-proper review, and works-council co-determination in the EU
- **Cross-Reference**: Skills-Career-Profile, Promotion-Process, Workforce-Planning, Performance-Review, Strategic-HR-Analytics, Compensation-Benchmarking, Audit-Compliance, ESG-Reporting, and Diversity-Equity-Inclusion agents

### Decision-Maker Distribution Succession-Planning

| Step | Decider | Rationale |
|------|---------|-----------|
| Key position identification + criticality + regulatory designation | R | Classification matrix deterministic + SEC Item 401 + UK SMR + UK CQC |
| Role profile generation ESCO + UK NQF + Lightcast + O*NET | R | Skills taxonomy mapping deterministic |
| Readiness assessment + tenure + performance + 9-box grid | R | Competence gap analysis + scoring rules deterministic |
| Hi-Po identification + EEOC 4/5ths disparate impact | R | EEOC + Title VII + UK Equality Act check deterministic |
| Risk mapping + retirement + flight-risk + regulatory pipeline | R | Heat map criteria deterministic |
| Cross-agent integration Skills + Promotion + Workforce-Planning | R | Master data mapping + reconciliation deterministic |
| Bench strength + ISO 30414 succession planning category | R | Pipeline depth + leadership coverage ratio deterministic |
| ESG/CSRD ESRS S1-13 + ISSB IFRS S1 + ISO 30414 reporting | R | EFRAG ESRS datapoints + ISO 30414 deterministic |
| Development plan recommendations + learning + stretch + mentoring | A | ML development indicators with human validation |
| Pipeline gap + retirement risk + diversity gap + leadership coverage | A | ML pattern detection with human validation |
| Works council + DPIA + EU AI Act FRIA + Article 22 check | R | Compliance check deterministic |
| Nomination Committee + Audit Committee + four-eye approval | H | SEC Item 401 + UK SMR + SOX 404 mandatory human |
| Distribution + secure delivery + 7-year retention | R | SOX 404 audit-trail + AICPA SOC 2 deterministic |

--- Talent Pool Management Agent ---
> Candidate pool segmentation and engagement: Title VII/EEOC Uniform Guidelines, GDPR Art. 17 erasure + Art. 22 automated-decision prohibition, UK Equality Act 2010 and EU AI Act 4/13/14/26.

Cross-jurisdictional talent-pool management faces five parallel statutory regimes: US anti-discrimination law (Title VII and the EEOC four-fifths rule, with the Mobley v. Workday case and NYC Local Law 144 on AI hiring tools); the UK Equality Act 2010 with its Section 60 health-enquiries restriction; GDPR on lawful basis, consent, erasure, and automated decisions; the EU AI Act on recruitment AI; and the 25-plus US state pay-transparency laws. A single candidate record at a large multinational can trigger several of these at once, and the typical organisation keeps over 100,000 dormant records with no documented consent.

## Talent pool as compliance trap between EU GDPR and Title VII

This agent follows the [Decision Layer](/en/decision-layer/) principle: each decision is either rule-based, AI-assisted, or explicitly assigned to a human - and the human spots are reserved for engagement campaign approval and diverse slate review.

A Talent Acquisition Director discovers in a routine ICO audit that the LinkedIn Recruiter Talent Pipeline holds 47,000 candidate records harvested over four years from cold outreach, recruitment events, speculative applications, and silver medallists. Fewer than 12 percent carry documented consent under GDPR. The rest were imported with no lawful-basis classification, no retention boundary, and no transparency notice. The same week, the head of sourcing receives an EEOC charge alleging that an AI skill-matching tool systematically suppresses applications from candidates over 50. EEOC counsel cites Mobley v. Workday and demands a four-fifths-rule analysis of pool-to-requisition progression by protected class.

The problem is not negligence by individual recruiters. It describes the normal state of talent pool infrastructure built between 2018 and 2024: LinkedIn Recruiter saved searches, iCIMS CRM nurture campaigns, Beamery employer brand engagement, Greenhouse Talent Pool for silver medallists, Phenom Career Site captures, Gem cold outreach, Eightfold AI Skill Cloud recommendations. Each platform has its own consent capture, its own retention default, its own segmentation logic, its own audit trail (or none).

## GDPR consent and the right to erasure

The agent classifies every talent-pool entry by source-specific lawful basis: consent (Article 6(1)(a)) for proactive sourcing and speculative applications, contract performance (Article 6(1)(b)) for active-requisition candidates, and a legitimate-interest balancing test (Article 6(1)(f)) for silver medallists, alumni, and employee referrals. Article 7 requires consent that is freely given, specific, informed, and unambiguous, with a right to withdraw as easy as giving.

Default retention is six months for general candidate records under the ICO recruitment code, extended to twelve months for silver medallists with documented justification and twenty-four months for critical-skill pools with explicit consent renewal. US record-keeping rules set their own minimums - one year under EEOC rules, two for federal contractors under the OFCCP Internet Applicant Rule.

Erasure under Article 17 fires on consent withdrawal, retention expiry, a sustained objection, or unlawful processing, and cascades across the ATS, CRM, and sourcing tools with chain-of-deletion verification. The Article 17(3)(e) legal-claims exception keeps the minimum needed for anti-discrimination defence. Every deletion is logged and confirmed to the data subject within 30 days under Article 12.

## US Title VII, the EEOC, and the UK Equality Act

The agent runs ML-augmented disparate-impact analysis on pool composition, sourcing-channel performance, and candidate progression against Title VII protected classes, ADEA age protection, and the disability rules, applying the EEOC four-fifths (80 percent) threshold. The flagging is an indicator, not a final decision - flagged patterns route to the Talent Acquisition Director, DPO, and Compliance Officer for human review.

UK Equality Act 2010 protected characteristics are checked alongside the Section 60 pre-offer health-enquiry restriction and the positive-action provisions, drawing on the EHRC and ACAS codes. The agent flags illegitimate filtering criteria, indirect discrimination, missing accommodation, and missing diverse-slate documentation for OFCCP good-faith effort.

On retention, the agent holds records to the EEOC one-year and OFCCP two-year minimums and maintains chain-of-custody for charge defence and EEO-1 and Affirmative Action reporting.

## AI talent matching and Mobley v. Workday

The EU AI Act classifies recruitment AI used for screening, ranking, or matching as high-risk (Annex III(4)(a)). The agent assesses each AI matching deployment, and where AI is the primary screening basis the deployment triggers provider and deployer obligations, a Fundamental Rights Impact Assessment, and fines up to EUR 15M or 3 percent of global turnover.

The Mobley v. Workday case set a vendor-liability precedent: the AI vendor was named as an agent of the employer-customer for Title VII purposes, so the vendor can be held liable when its product affects protected classes. NYC Local Law 144 adds an independent bias audit, candidate notification at least 10 business days before use, and publication of the audit summary. The EEOC has named AI hiring tools an enforcement priority and confirmed that algorithmic decision-making is subject to anti-discrimination law.

## Engagement workflows and re-activation sequences

The agent designs an engagement cadence per persona, role priority, and last interaction - newsletters, role-specific job alerts, thought-leadership, event invitations, targeted InMail, email nurture, and consented SMS, all UTM-tracked and engagement-scored. Every channel respects the Article 7(3) right to withdraw and the relevant marketing-communication rules, and every message carries an unsubscribe link, sender identification, a physical address, and a privacy-policy link.

A re-activation sequence triggers when the engagement score drops below threshold, the last interaction passes 90 or 180 days, and a current vacancy refreshes role relevance. Consent is re-confirmed before the sequence starts, and candidates nearing the six-month retention boundary are flagged for a renewal-or-deletion decision. The agent also maps entries to current vacancy pay bands under the 25-plus state pay-transparency laws, flagging missing pay ranges and prohibited salary-history collection.

## Cross-reference to Candidate-Screening, Pre-Hire-Due-Diligence, and Interview-Scheduling

The Talent Pool Management Agent feeds the Candidate Screening Agent (silver-medallist and alumni auto-suggest), the Pre-Hire Due Diligence Agent (background-check consent verified at pool entry), the Interview Scheduling Agent (slot prep on shortlist), and the Executive Recruiting Agent (executive talent map for succession). When a requisition opens, it cross-references the pool, applies skill, experience, location, and visa matching with diverse-slate balance, suggests the top 10-25 candidates, and keeps an audit trail of suggestions and recruiter selections.

Two of the three core components - the lawful-basis classification engine and retention orchestration - are generic infrastructure that every candidate-data agent in the [Decision Layer](/en/decision-layer/) needs. The Audit Compliance Agent draws its proof from the resulting audit trail, and the Employee Data Management Agent reuses the chain-of-deletion verification.

## At a glance

- Nine rule-based decisions, five ML-augmented indicators, and one mandatory human escalation
- GDPR lawful-basis classification per source, with consent capture and Article 17 erasure orchestration
- Disparate-impact analysis under US Title VII, the EEOC four-fifths rule, and the UK Equality Act 2010
- EU AI Act recruitment classification with Mobley v. Workday vendor-liability mitigation
- Pay-band mapping under the 25-plus state pay-transparency laws and salary-history bans
- Six-month default retention, longer for silver medallists, with chain-of-deletion verification

## Decision-Maker Distribution Talent-Pool-Management

| Decision Type | Count | Example | Challengeable |
|---|---|---|---|
| R Rule-based | 9 | Intake classification, lawful-basis assignment, retention orchestration, engagement-workflow design, Article 17 erasure, EU AI Act classification, pay-transparency mapping, audit logging | not applicable |
| A AI-augmented | 5 | Disparate-impact analysis, UK Equality Act check, segmentation persona build, dormant-candidate scoring, requisition matching | auditor, candidate |
| H Human escalation | 1 | Manager review, engagement-campaign approval, diverse-slate review | not applicable |

--- HR Social Security & Tax Master Data Agent ---
> HR social security workflow: master data (health insurance, religious denomination, tax class), W-4/P46 onboarding, A1 posting certificates - audit trail per change.

## Tax filings, social-security reporting, and certificates on time

This agent follows the [Decision Layer](/en/decision-layer/) principle: each decision is either rule-based or explicitly assigned to a human. It is not a high-risk system under the [EU AI Act 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) - it is deterministic rules, with no HR decisions - but it carries strict obligations from [US IRC Section 3401-3405](https://www.law.cornell.edu/uscode/text/26/subtitle-C/chapter-24), UK HMRC PAYE under the 2003 ITEPA, SOX 404, GDPR Article 88, and multi-year US and UK retention rules.

A typical cycle produces dozens of statutory submissions per jurisdiction - the quarterly Form 941 and annual Form 940, W-2s by 31 January, state filings across 41 states, ACA and ERISA returns, the UK RTI submissions, P60s and P11Ds, and the triennial auto-enrolment declaration.

The problem is the deadline matrix. Miss one filing and the penalties stack: the IRS failure-to-file penalty reaches 25 percent, failure-to-deposit 15 percent, UK HMRC late-filing penalties escalate by day, and a late Form 5500 costs 250 USD per day.

Manual deadline tracking in Excel fails at scale - a multi-jurisdictional employer has hundreds of statutory deadlines a year. The agent generates a deterministic deadline calendar from the statutory due dates, escalation rules, and a filing-template library.

## US federal withholding, Form 941/940, W-2, and state returns

[US IRC Section 3401-3405](https://www.law.cornell.edu/uscode/text/26/subtitle-C/chapter-24) governs federal income-tax withholding, and IRS Publication 15 and its supplements specify the withholding tables.

[US IRS Form 941](https://www.irs.gov/forms-pubs/about-form-941), the Employer's Quarterly Federal Tax Return, reports federal income tax withheld together with FICA and Medicare; Form 940 covers annual FUTA, and W-2s are due by 31 January with the W-3 transmittal to the SSA.

The EFTPS mandates electronic deposits under Treasury Regulation 31.6302-1, with the deposit frequency - semi-weekly, monthly, or next-day for liabilities over 100,000 USD - set by a lookback period ending 30 June of the prior year.

Forty-one states and DC levy income tax, each with its own withholding reconciliation and quarterly SUTA return, alongside multistate apportionment for remote workers and state disability insurance in a handful of states.

## UK PAYE, RTI, P60/P45, and National Insurance

[UK HMRC PAYE under the Income Tax (Earnings and Pensions) Act 2003](https://www.legislation.gov.uk/ukpga/2003/1) (ITEPA), with the PAYE Regulations 2003, sets the framework, alongside the IR35 off-payroll-working rules.

Real Time Information requires a Full Payment Submission on or before payday, a Final FPS by 5 April, and a monthly Employer Payment Summary carrying adjustments such as statutory-payment recovery and the apprenticeship levy.

The statutory certificates follow a fixed calendar: P60s by 31 May, P11D and the P11D(b) Class 1A NIC return by 6 July, and a P45 on the day an employee leaves.

National Insurance is layered: Class 1 primary on the employee, Class 1 secondary on the employer at 13.8 percent above the threshold, Class 1A at 13.8 percent on benefits in kind, and the apprenticeship levy at 0.5 percent on pay bills over 3M GBP, all under the Social Security Contributions and Benefits Act 1992.

Missed RTI submissions draw penalties that escalate by day, and deliberate errors can reach 100 percent under HMRC Schedule 24.

## ACA Form 1094-C, ERISA Form 5500, and DOL EBSA

The Affordable Care Act requires Form 1094-C and the employee-level Form 1095-C from Applicable Large Employers (50 or more FTEs), tracking minimum essential coverage against a 60 percent minimum-value test and an affordability threshold, with electronic filing once 250 or more forms are due.

ERISA's Form 5500 annual return is due on the last day of the seventh month after the plan-year end, with the relevant schedules and Form 8955-SSA for terminated participants, filed electronically via EFAST2. A late return carries a DOL penalty of 250 USD per day.

UK auto-enrolment under the Pensions Act 2008 requires every employer to enrol eligible jobholders in a qualifying scheme, with minimum contributions of 8 percent of qualifying earnings (3 percent employer, 5 percent employee), a Declaration of Compliance to the Pensions Regulator every three years, and NEST as a default option.

The agent monitors every deadline deterministically and escalates a late submission to the HR Tax Specialist, Tax Director, and external auditor 14 days before the due date, writing each step to a SOX-404-grade audit-trail with EFTPS confirmations, HMRC submission IDs, and data lineage.

## Cross-reference to Payroll-Processing, Payroll-Accounting, and Payroll-Reporting

[Payroll-Processing-Agent](/en/hr-agent-catalog/payroll-processing-agent/) produces the gross-to-net calculation that feeds the tax-filing data. [Payroll-Accounting-Agent](/en/hr-agent-catalog/payroll-accounting-agent/) posts the resulting entries to the general ledger. [Payroll-Reporting-Agent](/en/hr-agent-catalog/payroll-reporting-agent/) builds the reports, dashboards, and statutory disclosures. [Audit-Compliance-Agent](/en/hr-agent-catalog/audit-compliance-agent/) verifies SOX 404 and SOC 2. [HR-Document-Management-Agent](/en/hr-agent-catalog/hr-document-management-agent/) archives the W-2s, P60s, P11Ds, and ACA forms on their statutory retention clocks. [Compensation-Benchmarking-Agent](/en/hr-agent-catalog/compensation-benchmarking-agent/) supplies the bands used to validate the tax base, and [Merit-Cycle-Governance-Agent](/en/hr-agent-catalog/merit-cycle-governance-agent/) hands over approved adjustments that flow into it.

## At a glance

- **Classification**: Compliance-Support, not EU AI Act high-risk (deterministic rules)
- **Compliance anchors**: US IRC Section 3401-3405 and the federal filings, state tax across 41 states, ACA and ERISA returns, UK PAYE/RTI and National Insurance, the UK Pensions Act 2008, SOX 404, SOC 2, and GDPR Article 88
- **Retention**: 7 years for US employer tax records, 6 years for UK HMRC and ERISA
- **Approval**: four-eye principle (HR Tax Specialist, Tax Director, Audit Committee)
- **Penalties**: IRS failure-to-file up to 25 percent and failure-to-deposit up to 15 percent, escalating UK HMRC late-filing penalties, a late Form 5500 at 250 USD per day, SOX criminal exposure, and GDPR fines up to 4 percent of group revenue
- **Audit obligation**: SOX 404 and SOC 2, with the UK auto-enrolment Declaration of Compliance every three years
- **Cross-Reference**: Payroll-Processing, Payroll-Accounting, Payroll-Reporting, Audit-Compliance, and HR-Document-Management agents

### Decision-Maker Distribution Tax-Social-Insurance

| Step | Decider | Rationale |
|------|---------|-----------|
| Payroll output extraction, tax-base validation | R | Deterministic source-to-target mapping with reconciliation |
| Statutory deadline calendar, jurisdiction matrix | R | Deadline calendar per filing type, deterministic |
| US Form 941, 940, W-2, W-3 | R | IRS templates and IRC Section 3401-3405, deterministic |
| EFTPS deposit scheduling | R | Treasury Regulation 31.6302-1 lookback, deterministic |
| State tax filings, SUTA | R | State Department of Revenue templates, deterministic |
| ACA Form 1094-C and 1095-C | R | ALE, minimum-value, and affordability tests, deterministic |
| ERISA Form 5500 and 8955-SSA via EFAST2 | R | Form 5500 and schedules, deterministic |
| UK PAYE, RTI FPS and EPS | R | RTI generation, deterministic |
| UK P60, P11D, P11D(b) Class 1A NIC | R | Statutory certificate generation, deterministic |
| UK NIC and apprenticeship levy | R | NIC calculation per the 1992 Act, deterministic |
| UK Pensions Act 2008, TPR Declaration | R | Auto-enrolment monitoring, deterministic |
| Exception handling, auditor coordination | H | Four-eye SOX 404, interpretation mandatory |
| SOX 404 audit-trail, SOC 2 | R | ICFR with EFTPS and HMRC IDs, deterministic |
| Retention lifecycle | R | IRS, UK HMRC, then GDPR erasure, deterministic |

--- Time and Attendance Agent ---
> Time tracking with overtime calculation: US FLSA + 29 CFR Part 778, UK Working Time Regulations 1998 48-hour week, EU Directive 2003/88 + CJEU CCOO objective tracking and GDPR Art. 88.

Cross-jurisdictional time and attendance faces four parallel statutory regimes: the US FLSA with its regular-rate, exemption, and hours-worked rules and state daily-overtime laws; the UK Working Time Regulations 1998 with the Employment Rights and National Minimum Wage Acts; the EU Working Time Directive as interpreted by the CJEU; and GDPR. A single time entry can trigger several at once, and the typical 2,000-employee organisation logs 4 to 7 million entries a year - with overtime calculations wrong in 35 to 50 percent of cases when done manually.

## Time tracking as an obligation under CJEU CCOO and the Working Time Directive

This agent follows the [Decision Layer](/en/decision-layer/) principle: each decision is rule-based, and the human spot is reserved for manager review and exception approval.

In the CCOO judgment of 14 May 2019, the CJEU held that Member States must require employers to set up an objective, reliable, and accessible system that measures the daily working time of each worker, interpreting the Working Time Directive in light of Article 31(2) of the EU Charter of Fundamental Rights.

Member State implementation followed: Germany's Federal Labour Court read an employer time-recording duty into the occupational-safety act, Spain mandated time tracking with four-year retention, and France, Italy, and Poland enforce their own transpositions.

The agent provides objective, reliable, and accessible time tracking through deterministic rules, an audit trail, and Member State routing. It applies data minimisation so records hold only what the statutes require, and it does not enable employer surveillance beyond what working-time law demands.

## US FLSA, state daily overtime, and the white-collar exemptions

The FLSA sets a federal minimum wage and overtime at time and one-half over 40 hours a workweek, with the regular-rate rules of 29 CFR Part 778, the white-collar exemptions of Part 541, and a three-year record-keeping requirement.

The regular-rate calculation must fold in all remuneration - non-discretionary bonuses, commissions, shift differentials, and on-call pay. Leaving non-discretionary bonuses out of it underpays overtime systematically.

The Part 541 exemptions (executive, administrative, professional, computer, outside sales) turn on a salary-basis test and a duties test, with the salary threshold raised under the 2024 DOL Final Rule. Misclassification brings back wages, doubled liquidated damages, and a statute of limitations that extends to three years for wilful violations.

State daily overtime runs independently of the FLSA workweek: California, for instance, pays overtime after eight hours in a day and double time after twelve, and adds meal-and-rest-break rules with premium pay for missed breaks. The agent applies the state-by-state stacking and uses whichever calculation pays more. This stacking is missed in 60 to 80 percent of California cases done manually, because a worker can pass the daily eight-hour threshold without passing the weekly 40.

## UK Working Time Regulations: the 48-hour week and rest periods

The UK Working Time Regulations 1998 implement the EU Directive with a 48-hour weekly limit averaged over a 17-week reference period, an 11-hour daily and 24-hour weekly rest, a 20-minute break for shifts over six hours, and 5.6 weeks of annual leave, alongside the individual opt-out and night-worker limits.

Case law shapes the holiday-pay calculation - Bear Scotland held that holiday pay must reflect normal remuneration including overtime, with Williams, Lock, and Harpur Trust building on it. The National Minimum Wage Act adds six-year record-keeping and HMRC enforcement, with a 200 percent underpayment penalty.

The agent calculates the 17-week reference period, tracks the opt-out, monitors the daily and weekly rest, the break, and the annual-leave entitlement, flags breaches, and applies the ACAS and ICO codes.

## GDPR Article 88 and works-council codetermination

Time-tracking data is personal data under GDPR; a fingerprint or facial-recognition clock-in is special-category biometric data under Article 9, and geolocation and RFID are location data. Processing rests on legal obligation (the working-time statutes) and contract performance, under the Article 88 employment rules, with data minimisation by design, a mandatory DPIA for systematic monitoring, and the Article 22 bar on fully automated decisions.

Member State law adds co-determination: in Germany, the Works Constitution Act requires works-council agreement for any system that monitors employee behaviour - biometric clock-in, facial recognition, GPS, or RFID - with equivalent consultation duties in France, Italy, Spain, and Poland.

The CJEU's Matzak ruling held that on-call time at home with an eight-minute response constraint is working time, and Stadt Offenbach added that stand-by counts only when the constraints significantly affect the worker's ability to manage free time. The EDPB employment-data guidelines clarify the lawful-basis hierarchy and the DPIA criteria.

The agent runs the works-council codetermination workflow before any biometric or geolocation feature is switched on, keeps monitoring features off by default, requires a DPIA before deployment, and enforces data minimisation by design rather than through access controls alone.

## Cross-reference to Payroll-Processing, Sick-Leave-Processing, and Leave-of-Absence

The Time and Attendance Agent supplies the regular rate, overtime hours, and premium pay to the Payroll Processing Agent, tracks scheduled versus actual hours for the Sick Leave Processing and Leave of Absence agents, uses the HR Document Management Agent for retention and audit trail, and works with the Audit Compliance Agent on FLSA misclassification, state premium-pay claims, and works-council disputes.

Payroll consumes the regular-rate and overtime output. Sick Leave reconciles scheduled against actual hours. Leave of Absence uses scheduled hours for accrual. Audit Compliance draws on the FLSA, UK 48-hour, and CJEU CCOO compliance evidence the agent records.

The agent handles the volume, the deterministic calculation, and the statutory thresholds; the human keeps exception approval and works-council consultation. Tracking every threshold reliably is what keeps compliance from slipping in a manual reconciliation.

## At a glance

- 13 rule-based decisions and one mandatory human escalation to manager review and exception approval
- US FLSA, with the regular-rate, white-collar-exemption, and hours-worked rules
- US state daily overtime (California and others) and state meal-and-rest-break rules
- UK Working Time Regulations 1998: the 48-hour week, daily and weekly rest, the 20-minute break, 5.6 weeks of leave, and the opt-out
- EU Working Time Directive with the CJEU CCOO, Matzak, and Stadt Offenbach rulings on objective tracking and on-call time
- GDPR Articles 6, 88, 22, and 35, with Member State works-council codetermination for biometric or geolocation monitoring
- SOC 1 and SOC 2, ISO 27001, and ISO 30414 productivity metrics

### Decision-Maker Distribution Time-Attendance

| Decision Type | Count | Example | Challengeable |
|---|---|---|---|
| R Rule-based | 13 | Channel classification, entry validation, FLSA and state overtime, exempt-status check, UK 48-hour week, EU Working Time Directive and CJEU on-call time, anomaly detection, schedule match, regular rate of pay, meal and rest breaks, statutory notifications, payroll update, audit trail | not applicable |
| A AI-augmented | 0 | none - deterministic rules | not applicable |
| H Human escalation | 1 | Manager review, exception approval, works-council consultation | not applicable |

--- Training Effectiveness Agent ---
> Training measurement: Kirkpatrick 4-Levels + Phillips ROI 5-Levels, US WIOA + DOL Apprenticeship, UK Apprenticeship Levy and ESCO/ISCED - CSRD ESRS S1-13 skills reporting and ISO 30414.

## Training-effectiveness measurement with Kirkpatrick and Phillips ROI

This agent follows the [Decision Layer](/en/decision-layer/) principle: each decision is either rule-based, AI-assisted, or explicitly assigned to a human. It is not a high-risk system under the [EU AI Act 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) - it is measurement aggregation without individual learning consequences - but it carries obligations from US WIOA, the UK Apprenticeship Levy and its regulators, the EU skills frameworks, the CSRD ESRS S1-13 standard, ISO 30414, SOC 2, and GDPR.

The measurement decomposes into the four Kirkpatrick levels - reaction (post-training satisfaction and content relevance), learning (pre- and post-test scores and certification pass rates), behaviour (90-day on-the-job application from manager and peer feedback), and results (business KPIs such as revenue, quality, and retention) - and Phillips ROI extends it with a fifth, monetary benefit-cost level using isolation-of-effects methods.

The challenge is not the framework. It is the auditable chain around it: a SOC-2-grade audit-trail with xAPI lineage, the ESG limited-assurance scope, four-eye sign-off, and works-council co-determination on the aggregate measurement.

## US WIOA, the UK Apprenticeship Levy, ESFA, and Ofqual

The [US Workforce Innovation and Opportunity Act](https://www.dol.gov/agencies/eta/wioa) mandates six Joint Performance Indicators across its four titles: employment in the second and fourth quarters after exit, median earnings, credential attainment, measurable skill gains, and effectiveness in serving employers. The state workforce boards and DOL ETA aggregate the reports.

US registered apprenticeships under 29 CFR 29, with the 29 CFR 30 equal-employment rules, submit data to the RAPIDS database, complemented by the Industry Recognized Apprenticeship Programs and the Work Opportunity Tax Credit.

The [UK Apprenticeship Levy](https://www.gov.uk/guidance/pay-apprenticeship-levy) charges 0.5 percent of pay bills over 3M GBP, collected through PAYE into an Apprenticeship Service Account with a 24-month fund expiry and a 10 percent government top-up. The ESFA oversees the funding rules and audit, Ofqual governs End-Point Assessment, and IfATE manages the standards.

EEOC training requirements under Title VII and the related anti-discrimination statutes, with the Uniform Guidelines four-fifths rule, require disparate-impact analysis on training selection to prevent discrimination claims.

## ESCO, ISCED, and CSRD ESRS S1-13 skills reporting

The [EU ESCO](https://esco.ec.europa.eu/en) classification covers roughly 14,000 occupations and 13,000 skills and competences, aligned with the European Qualifications Framework. UNESCO's ISCED 2011 provides nine education levels from early childhood through doctoral, complemented by Eurostat and OECD education statistics.

The CSRD's ESRS S1-13 requires training-and-skills-development data - average training hours per employee, the share of employees receiving regular development reviews, and training participation across diversity dimensions - with each KPI mapped to source data through the EFRAG datapoints. Limited assurance applies from 250 employees, performed by the Big-4 firms.

ISO 30414 adds human-capital metrics for training-and-skills-development, leadership, organisational culture, and productivity, and ISO 9001's competence, awareness, and documented-information clauses ensure the underlying records hold up.

## GDPR Article 88 and works-council training codetermination

GDPR governs the training data: Article 6 lawful basis, Article 9 special categories, the Article 22 bar on automated individual decisions, and the Article 88 employment rules. The agent pseudonymises at extraction (Article 4(5)) and applies aggregation thresholds - a minimum of five employees per cohort - to prevent re-identification.

Works-council co-determination under the EU Information and Consultation Directive and national co-determination acts is mandatory before any aggregate-measurement go-live in the EU; a works-council objection blocks it. The EDPB HR-AI guidelines and the national supervisory authorities are the reference points.

A GDPR Article 35 DPIA is required before deployment, with an EU AI Act Article 27 FRIA where the ML transfer indicators would trigger classification.

## Cross-reference to Skills-Career-Profile, Performance-Review-Documentation, and Learning-Path-Recommendation

[Skills-Career-Profile-Agent](/en/hr-agent-catalog/skills-career-profile-agent/) feeds individual skills assessments into the aggregate measurement for gap analysis. [Performance-Review-Documentation-Agent](/en/hr-agent-catalog/performance-review-documentation-agent/) uses the Level 3 behaviour observations as evidence in reviews. [Learning-Path-Recommendation-Agent](/en/hr-agent-catalog/learning-path-recommendation-agent/) uses the skill-gap detection and content recommendations for individual paths. [Strategic-HR-Analytics-Agent](/en/hr-agent-catalog/strategic-hr-analytics-agent/) folds the measurements into board reporting and ESG disclosure. [Workforce-Planning-Agent](/en/hr-agent-catalog/workforce-planning-agent/) uses the skills-framework mappings for headcount scenarios. [Succession-Planning-Agent](/en/hr-agent-catalog/succession-planning-agent/) uses leadership-development effectiveness for board-level talent reviews, and [Compensation-Benchmarking-Agent](/en/hr-agent-catalog/compensation-benchmarking-agent/) folds skills-certification effects into compensation bands. The ESG-Reporting-Agent extends the ESRS S1-13 data to full sustainability reporting, and the Audit-Compliance-Agent verifies SOC 2.

## At a glance

- **Classification**: Compliance-Support, not EU AI Act high-risk (measurement aggregation)
- **Compliance anchors**: US WIOA and registered apprenticeships, EEOC disparate-impact rules, the UK Apprenticeship Levy and its regulators, the EU ESCO and ISCED frameworks, CSRD ESRS S1-13, ISO 30414 and 9001, SOC 2, and GDPR
- **Measurement framework**: the four Kirkpatrick levels and the Phillips ROI fifth, monetary benefit-cost level with isolation-of-effects methodology
- **Approval**: four-eye principle (L&D Director, business sponsor, CHRO, ESG Officer) with works-council consultation; interpretation and commentary human-only
- **Penalties**: ESG limited-assurance qualifications, ESFA audit findings and 24-month fund expiry, WIOA performance failures, EEOC disparate-impact claims, and GDPR fines up to 4 percent of group revenue
- **Audit obligation**: SOC 2, ESG limited assurance from 250 employees, the annual ESFA funding audit, WIOA performance accountability, RAPIDS apprenticeship submission, and EEOC disparate-impact verification
- **Cross-Reference**: Skills-Career-Profile, Performance-Review-Documentation, Learning-Path-Recommendation, Strategic-HR-Analytics, Workforce-Planning, Succession-Planning, Compensation-Benchmarking, ESG-Reporting, and Audit-Compliance agents

### Decision-Maker Distribution Training-Effectiveness

| Step | Decider | Rationale |
|------|---------|-----------|
| LMS data extraction, xAPI/SCORM, pseudonymisation | R | Deterministic source-to-target mapping, GDPR Article 4(5) |
| Kirkpatrick Level 1 reaction aggregation | R | Survey-response computation, deterministic |
| Kirkpatrick Level 2 learning pre/post tests | R | Score deltas with statistical significance, deterministic |
| Kirkpatrick Level 3 behaviour, 90-day on-the-job | R | Manager and peer feedback aggregation, deterministic |
| Kirkpatrick Level 4 and Phillips ROI Level 5 | R | Isolation-of-effects and monetary benefit, deterministic |
| Knowledge transfer, skill gap, content recommendation | A | ML transfer indicators with human validation |
| CSRD ESRS S1-13 training-and-skills-development | R | EFRAG datapoints, deterministic |
| ISO 30414 skills, leadership, culture metrics | R | Human-capital reporting categories, deterministic |
| US WIOA Joint Performance Indicators, Titles I-IV | R | Six indicators per title, deterministic |
| Registered apprenticeship 29 CFR 29 and RAPIDS | R | Apprentice progression and EEO, deterministic |
| UK Apprenticeship Levy and Service Account | R | Levy expenditure and funding rules, deterministic |
| ESCO and ISCED qualification-level mapping | R | Skills classification and alignment, deterministic |
| EEOC disparate impact, four-fifths rule | R | Statistical test across protected characteristics, deterministic |
| L&D Director and business sponsor approval | H | Four-eye SOC 2, interpretation mandatory |

--- Training Needs Analysis Agent ---
> Rule-based skills-gap analysis against standardised frameworks, so training spend follows real gaps and the CSRD skills disclosure stands up to audit.

## Training needs analysis instead of training proliferation

This agent follows the [Decision Layer](/en/decision-layer/) principle: each decision is either rule-based, AI-assisted, or explicitly assigned to a human. It is not a high-risk system under the [EU AI Act 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) - it is gap-analysis aggregation without individual training-assignment consequences - but it carries obligations from US WIOA, the UK Apprenticeship Levy, the UK Equality Act, the EU skills frameworks, the CSRD ESRS S1-13 standard, ISO 30414, SOC 2, and GDPR.

Most enterprises run training proliferation: catalogue offerings with no evidence-based gap mapping, 30 to 50 percent budget waste, and ESFA apprenticeship funds expiring unused at 24 months. Needs analysis replaces that with evidence-based aggregation: mapping the current-state skills inventory against target-state role profiles, identifying competency gaps, aggregating performance-review data, cascading business-strategy goals into capability requirements, and prioritising the result through a multi-criteria matrix.

The challenge is not the framework. It is the auditable chain around it: the SOC-2-grade audit-trail, the skills-framework lineage, the ESG limited-assurance scope, four-eye sign-off, and works-council co-determination on the aggregate skills profiling.

## Skills-gap analysis on the ESCO, UK NQF, and Lightcast taxonomies

The [EU ESCO](https://esco.ec.europa.eu/en) classification covers roughly 14,000 occupations and 13,000 skills and competences, aligned with the European Qualifications Framework, and UNESCO's ISCED 2011 provides nine education levels.

The [Lightcast Open Skills Library](https://lightcast.io/open-skills) covers over 32,000 skills and 1,100 certifications and provides labour-market signals for detecting emerging skills from job-posting analytics.

[US O*NET](https://www.onetonline.org/) covers over 900 occupations with their skills, abilities, and work activities, maintained by the DOL and BLS. It gives US-anchored occupational profiles that complement ESCO for organisations operating across jurisdictions.

The [UK National Qualifications Framework](https://www.gov.uk/what-different-qualification-levels-mean) and its regulated counterpart provide nine levels from entry to doctoral, governed by Ofqual. The agent cross-walks these frameworks for organisations spanning the US, UK, and EU.

The gap aggregation itself is deterministic: the current-state inventory minus the target-state role-profile competencies, with critical-shortage alerts per role family, business unit, and cohort, mapped to ISO 30414 and underpinned by the ISO 9001 records clauses. It never produces individual training-assignment recommendations - only cohort-level gap signals that L&D Directors turn into programme decisions.

## US Title VII training requirements and the UK Equality Act

EEOC training requirements under Title VII and the related anti-discrimination statutes mandate disparate-impact analysis on identified training needs. The Uniform Guidelines four-fifths rule prescribes statistical-significance testing across protected characteristics, with enforcement through the EEOC and the state fair-employment agencies.

The [UK Equality Act 2010](https://www.legislation.gov.uk/ukpga/2010/15/contents) covers nine protected characteristics, the Section 19 indirect-discrimination test, and reasonable-adjustment duties, enforced by the EHRC with the ACAS code and the Employment Tribunal, and the Public Sector Equality Duty applies to public bodies.

The [US WIOA](https://www.dol.gov/agencies/eta/wioa) mandates needs assessment across its four titles, with the state workforce boards and DOL ETA aggregating the data for federal-funding accountability.

The [UK Apprenticeship Levy](https://www.gov.uk/guidance/pay-apprenticeship-levy) charges 0.5 percent of pay bills over 3M GBP into a Service Account with a 24-month fund expiry, and the ESFA's funding rules require evidence-based needs analysis to prevent that funding going to waste.

## GDPR Article 88 and works-council training codetermination

GDPR governs the skills-profiling data: Article 6 lawful basis, Article 9 special categories, the Article 22 bar on automated individual decisions, and the Article 88 employment rules. The agent pseudonymises at extraction (Article 4(5)) and applies aggregation thresholds - a minimum of five employees per cohort - to prevent re-identification.

Works-council co-determination under the EU Information and Consultation Directive and national co-determination acts is mandatory before any aggregate skills-profiling go-live in the EU; a works-council objection blocks it. The EDPB HR-AI guidelines and the national supervisory authorities are the reference points.

A GDPR Article 35 DPIA is required before deployment, with an EU AI Act Article 27 FRIA where the ML prioritisation indicators would trigger classification. Because skills profiling can become sensitive when it correlates with protected characteristics, the four-fifths rule and the UK Equality Act indirect-discrimination test are built into the needs analysis to head off legal exposure.

## Cross-reference to Skills-Career-Profile, Performance-Review, and Workforce-Planning

[Skills-Career-Profile-Agent](/en/hr-agent-catalog/skills-career-profile-agent/) feeds individual skills assessments into the aggregate analysis for gap calculation. [Performance-Review-Documentation-Agent](/en/hr-agent-catalog/performance-review-documentation-agent/) provides development-plan items and 360-degree feedback themes as input to needs identification. [Training-Effectiveness-Agent](/en/hr-agent-catalog/training-effectiveness-agent/) measures the impact of needs-driven training to close the loop. [Learning-Path-Recommendation-Agent](/en/hr-agent-catalog/learning-path-recommendation-agent/) turns the prioritised needs into individual learning paths. [Strategic-HR-Analytics-Agent](/en/hr-agent-catalog/strategic-hr-analytics-agent/) folds the analysis into board reporting and ESG disclosure. [Workforce-Planning-Agent](/en/hr-agent-catalog/workforce-planning-agent/) uses the skills-framework mappings and capability forecasts for headcount scenarios. [Succession-Planning-Agent](/en/hr-agent-catalog/succession-planning-agent/) uses leadership-development gaps for board-level talent reviews, and [Compensation-Benchmarking-Agent](/en/hr-agent-catalog/compensation-benchmarking-agent/) folds skills-certification effects into compensation bands. The ESG-Reporting-Agent extends the ESRS S1-13 needs data to full sustainability reporting, and the Audit-Compliance-Agent verifies SOC 2.

## At a glance

- **Classification**: Compliance-Support, not EU AI Act high-risk (gap-analysis aggregation without individual training-assignment consequences)
- **Compliance anchors**: US WIOA, EEOC disparate-impact rules and the Uniform Guidelines, the UK Apprenticeship Levy, NQF, and Equality Act, the EU ESCO, Lightcast, O*NET, and ISCED frameworks, CSRD ESRS S1-13, ISO 30414 and 9001, SOC 2, and GDPR
- **Analysis framework**: skills-gap and competency-gap analysis, performance-data aggregation, a business-goals cascade, and needs prioritisation through a multi-criteria matrix with emerging-skill detection
- **Approval**: four-eye principle (L&D Director, business sponsor, CHRO, ESG Officer) with works-council consultation; interpretation and commentary human-only
- **Penalties**: 30 to 50 percent training-budget waste, ESG limited-assurance qualifications, ESFA audit findings and 24-month fund expiry, WIOA performance failures, EEOC disparate-impact and UK Equality Act claims, and GDPR fines up to 4 percent of group revenue
- **Audit obligation**: SOC 2, ESG limited assurance from 250 employees, the annual ESFA funding audit, WIOA performance accountability, and EEOC and Equality Act disparate-impact verification
- **Cross-Reference**: Skills-Career-Profile, Performance-Review-Documentation, Training-Effectiveness, Learning-Path-Recommendation, Strategic-HR-Analytics, Workforce-Planning, Succession-Planning, Compensation-Benchmarking, ESG-Reporting, and Audit-Compliance agents

### Decision-Maker Distribution Training-Needs-Analysis

| Step | Decider | Rationale |
|------|---------|-----------|
| HRIS, skills inventory, role-profile extraction, pseudonymisation | R | Deterministic source-to-target mapping, GDPR Article 4(5) |
| ESCO, Lightcast, O*NET, UK NQF, ISCED taxonomy mapping | R | Multi-framework cross-walk with level alignment, deterministic |
| Skills-gap aggregation per role family and business unit | R | Current-state versus target-state delta, deterministic |
| Performance-review data, rating distribution, plan aggregation | R | Aggregation with theme extraction, deterministic |
| Business-strategy goals cascade, capability derivation | R | Strategy cascade and competency deduction, deterministic |
| Critical-skills and emerging-skill ML indicators | A | ML prioritisation indicators with human validation |
| CSRD ESRS S1-13 training-and-skills-development needs | R | EFRAG datapoints, deterministic |
| ISO 30414 skills, leadership, culture metrics | R | Human-capital reporting categories, deterministic |
| US WIOA needs assessment, Titles I-IV | R | Title I-IV planning data, deterministic |
| UK Apprenticeship Levy needs analysis, Service Account | R | Levy allocation and funding rules, deterministic |
| EEOC disparate impact, four-fifths rule | R | Statistical test across protected characteristics, deterministic |
| Needs prioritisation, business-impact ranking | R | Multi-criteria matrix with cost-benefit projections, deterministic |
| L&D Director and business sponsor approval | H | Four-eye SOC 2, interpretation mandatory |

--- Transfer & Relocation Agent ---
> Runs the deterministic parts of a cross-border assignment, immigration pathway, cost projection and assignment letters, leaving sign-off to a human.

Cross-border employee transfer runs into three parallel statutory regimes, on top of tax compliance and social-security coordination. The US INA governs the H-1B and L-1 routes, the EB immigrant petitions and Form I-9 verification. The UK Skilled Worker route (under Immigration Rules HC 1779) requires a sponsor licence, a certificate of sponsorship and the GBP 38,700 minimum salary. The EU Posting Workers Directive 96/71/EC sets host-country conditions while Regulation 883/2004 governs the A1 social-security certificate. On top sits tax compliance - the IRS Section 911 exclusion and the UK Statutory Residence Test, reconciled through a double-taxation agreement. Every international assignment in a large or upper-mid-market corporation triggers cumulative obligations across both jurisdictions, with penalty exposure above USD 30M.

## The international assignment as a compliance trap

This agent follows the [Decision Layer](/en/decision-layer/) principle: each decision is either rule-based, AI-assisted, or explicitly assigned to a human - and the human spots are reserved for assignment approval and works council co-determination.

A line manager nominates an engineer for a 3-year assignment from London to Frankfurt to lead a project team. HR generalist sends an email-attachment assignment letter, the cost projection lives in a spreadsheet on a departed colleague's drive, immigration filing happens via a personal contact with an immigration lawyer who emails forms back and forth. Three months later the engineer arrives in Frankfurt without an A1 certificate, the German tax authorities open an investigation, the works council escalates because they were not consulted, and the project loses 6 weeks while the team rebuilds the assignment properly under the EU Posting Workers Directive and Regulation 883/2004, with the IMI declaration filed. The same scenario unfolds when a US assignee arrives in London without a Certificate of Sponsorship under the UK Skilled Worker visa: the sponsor licence enters compliance review and 80 sponsored workers across 12 sponsor entities face revocation risk.

The problem is not HR negligence. It describes the normal state in mid-market organisations that maintain international assignment programmes across legacy structures: a spreadsheet for cost projection, an email-attachment archive for assignment letters, a paper folder for immigration filings, a separate tax provider for tax equalisation, a relocation services provider for logistics. Each system has its own logic, its own permissions, its own gaps. A US Global Mobility Director facing a USCIS Request for Evidence does not know whether the LCA public access file contains the prevailing wage determination from the time of filing. A UK HR generalist responding to a UKVI sponsor compliance check does not know whether the Sponsor Management System reflects the actual deployment of sponsored workers. An EU compliance officer fielding an EU Posting Workers Directive enforcement does not know whether the IMI declaration was filed for every posted worker.

## The US: H-1B, L-1 and the I-9

The agent runs US visa pathway determination deterministically, filing the LCA and preparing the I-129 and I-140 petitions across the H-1B, L-1 and EB categories. An H-1B turns on a degree-level speciality occupation, a prevailing-wage determination via DOL OES, and the LCA public-access file 30 days after filing, with premium processing available for a 15-day adjudication. An L-1 requires a qualifying organisation and one year of continuous employment in the three years before transfer, in either the L-1A executive-manager or L-1B specialised-knowledge form.

The EB immigrant petitions cover extraordinary ability, outstanding researchers, multinational managers and advanced-degree workers, filed on Form I-140 with PERM labour certification where required. Separately, Form I-9 verifies employment eligibility under IRCA: the ICE worksite-enforcement unit audits it, with civil penalties up to USD 2,789 per violation and criminal exposure for a pattern of violations.

## The UK: Skilled Worker and the sponsor licence

The UK Skilled Worker route operates under Immigration Rules HC 1779. The employer needs an A-rated sponsor licence from UKVI, and the Sponsor Management System is where certificates of sponsorship are allocated and assigned. The sponsor carries reporting, record-keeping and cooperation duties - including right-to-work checks and UKVI compliance visits. The salary must meet GBP 38,700 from April 2024 or the higher going rate, with the immigration health surcharge and a biometric residence permit on top.

Beyond the main route, the Senior or Specialist Worker visa covers intra-corporate transfers after 12 months' prior employment, and the Innovator Founder, Graduate and Global Talent routes serve other cases. The agent verifies the sponsor licence, assigns the certificate of sponsorship through the Sponsor Management System, checks the minimum salary and manages the sponsor's compliance duties.

## The EU: posting rules and the A1 certificate

The Posting Workers Directive 96/71/EC, with its 2018 revision, governs intra-EU and inbound postings. A posting runs up to 12 months (extendable to 18) and must meet the host Member State's minimum conditions - working time, rest, paid holiday, minimum pay and equal treatment. The IMI Internal Market Information system requires a posting declaration with a designated contact person.

Regulation 883/2004 coordinates social security: the A1 certificate, issued by the sending Member State, confirms that home-country social security still applies. Article 12 covers a posting of up to 24 months, Article 13 covers multi-state activity in two or more Member States, and Article 16 lets the competent authorities agree an extension. Where the case fits, the ICT-Card route handles intra-group transfers and the Blue Card route handles highly qualified employment above 1.5 times the national average salary. The agent obtains the A1 certificate, files the IMI declaration and applies the ICT-Card or Blue Card pathway as applicable.

## Where it connects to the other agents

The Transfer Relocation Agent feeds immigration pathway, tax equalisation and cost projection to the Onboarding, Payroll Processing, HR Document Management and Compensation Benefits agents, and it triggers the Audit Compliance Agent on sponsor-licence compliance, a USCIS Request for Evidence or EU posting non-compliance. Two of its three core components - the assignment lifecycle engine and the immigration filing engine - are generic infrastructure. Any Decision Layer agent that orchestrates cross-border workforce flows needs versioned assignment documentation with validity periods, and any agent that totals assignment cost needs the AIRINC, Mercer and ECA International benchmarks. The Payroll Processing Agent reuses the host-country payroll configuration this agent produces, the HR Document Management Agent reuses its signed assignment letters, and the Audit Compliance Agent needs its proof of the A1 certificate, the IMI declaration, the LCA public-access file, the certificate of sponsorship and the tax filing.

## At a glance

- 13 deterministic decisions, 3 ML-augmented indicators and 1 mandatory human escalation
- US immigration pathway determination across the H-1B, L-1 and EB routes, with the I-9, I-129 and I-140
- UK Skilled Worker route via the Sponsor Management System and certificate of sponsorship, at the GBP 38,700 minimum salary
- EU posting orchestration under Directive 96/71 and Regulation 883/2004, with the A1 certificate and IMI declaration
- Tax equalisation across IRS Section 911, UK HMRC PAYE and the Statutory Residence Test, reconciled by treaty
- Cross-border data transfer under GDPR Article 88 and the Articles 44-50 safeguards, including Schrems II and the EU-US Data Privacy Framework

### Decision-Maker Distribution Transfer-Relocation

| Decision Type | Count | Example | Challengeable |
|---|---|---|---|
| R Rule-based | 10 | Transfer intake and pathway determination, the EU A1 certificate, the US H-1B LCA, the UK certificate of sponsorship, assignment-letter generation, visa coordination, relocation logistics, payroll configuration and audit-trail logging | not applicable |
| A AI-augmented | 3 | Cost projection, tax-equalisation calculation and assignment lifecycle tracking | auditor |
| H Human escalation | 1 | Manager review, assignment approval and works-council consultation | not applicable |

--- HR Travel Approval Agent ---
> HR pre-trip approval workflow: trip request submission, works-council travel policy compliance, manager approval hierarchy and mandatory field validation before booking.

Cross-jurisdictional travel expense reporting faces three parallel statutory regimes. On the US side: IRS Publication 463, the Treasury Reg 1.274-5 substantiation standard, the GSA per diem rates, the IRS mileage rate and the accountable-plan rules under Section 62(c), with seven-year retention. On the UK side: the HMRC Approved Mileage Allowance Payments, the Section 336 ITEPA deduction test and the benchmark subsistence scale rates, with six-year retention. Across the EU: each Member State's own per diems and tax-free thresholds, with works-council co-determination and GDPR Article 88 on employee data. Every business trip in a large or upper-mid-market company adds cumulative exposure - IRS audit penalties, a UK HMRC employer compliance review, SOX 404 - against the sheer volume of 25,000 expense reports a year per 5,000 employees still moving through paper receipts and legacy spreadsheets.

## Travel expense reporting in seconds instead of weeks postal delay

This agent follows the [Decision Layer](/en/decision-layer/) principle: each decision is either rule-based, AI-assisted, or explicitly human - and human spots are reserved for high-value approvals where business judgement matters.

A US Fortune 500 sales director returns from a five-day client visit to London. Hotel receipts, taxi fares, three client dinners, mileage to airport, GBP 320 corporate card FX fee. The traveller submits eleven receipts. Three weeks later the report is still pending: policy engine flagged a USD 87 dinner above per diem cap, corporate card transaction does not match booking, manager is on PTO. Cash advance EUR 500 outstanding. Same scenario for UK plc consultant submitting AMAP mileage over 10,000 miles at GBP 0.25 per mile - HMRC compliance review demands proof of business purpose. Eighty percent of these decisions are deterministic, yet most organisations treat them as discretionary clerical tasks.

The problem is not traveller dishonesty. It is the normal state of travel expense departments running on paper receipts, spreadsheet reimbursement, manual per diem lookups and email approval threads. A US Travel Manager facing an IRS audit does not know whether last quarter's per diem claims met the Section 62(c) accountable-plan and Treasury Reg 1.274-5 tests. A UK CFO facing an HMRC review does not know whether an AMAP excess triggered Class 1A NIC and a P11D. An EU compliance officer does not know whether the Member State per diem thresholds line up with the works council's co-determination rights under Section 87(1) No 8 BetrVG.

## The US rules: per diem, accountable plan, substantiation

The agent solves the coordination problem across the Travel Manager, Finance Operations, the Controller, Internal Audit and the external auditor while satisfying IRS Publication 463, the GSA per diem rates, the IRS mileage rate, the Section 62(c) accountable plan and the Treasury Reg 1.274-5 substantiation standard at the same time.

**Deterministic GSA per diem calculation.** Every travel day maps to the correct CONUS, non-standard-area or city-specific rate for lodging and meals under the Federal Travel Regulation, with the first-and-last-day 75 per cent rule applied automatically and the high-low method available where it is simpler.

**IRS accountable-plan verification.** Section 62(c) requires a business connection, substantiation and return of excess within a reasonable time (the 60-day rule). A per diem at or below the GSA federal rate is deemed substantiated; a non-accountable plan turns reimbursements into wages subject to FICA, FUTA and withholding, with retroactive payroll-tax liability.

**Treasury Reg 1.274-5 substantiation.** Each expense needs adequate records covering the amount, time, place and business purpose, with a receipt for lodging over USD 75, the USD 25 business-gift limit and the 50 per cent meals limitation.

**IRS mileage reimbursement.** The standard rate is USD 0.67 per mile for 2024, with a first-year election between the standard rate and the actual-expense method, and a record of the odometer reading and business purpose.

## The UK rules: AMAP, Section 336 and subsistence

The HMRC Approved Mileage Allowance Payments under Section 230 ITEPA govern employer mileage reimbursement: 45p per mile for the first 10,000 business miles in cars and vans, then 25p, with lower rates for motorcycles and bicycles. Pay above the AMAP rate and the excess attracts employer Class 1A NIC at 13.8 per cent, a reportable P11D benefit and the risk of an employer compliance review.

Section 336 ITEPA allows a deduction only where the expense is necessarily incurred, wholly and exclusively, in the performance of the duties. Sections 337 and 338 cover travel in the performance of duties and travel to a temporary workplace, and Section 339 defines the workplace - the 24-month rule turning a temporary workplace permanent. Travel between workplaces qualifies; ordinary commuting does not.

The HMRC benchmark subsistence scale rates run from GBP 5 for breakfast to GBP 15 for a late evening meal, and Section 289A ITEPA exempts payments at those rates from tax and NIC where the travel qualifies, with a bespoke scale rate available by agreement with HMRC.

The agent applies the AMAP rates, the Section 336-338 deduction tests and the benchmark subsistence rates deterministically, and integrates with payroll for the P11D and Class 1A NIC.

## SOX 404, SOC 2 and seven-year retention

SOX Section 404 requires management to assess the effectiveness of internal controls over financial reporting each fiscal year, disclose it in the Form 10-K and obtain the auditor's attestation under Section 404(b), with the COSO framework, a Risk and Control Matrix, walkthrough documentation and independent testing under PCAOB AS 2201.

The travel-expense controls usually within AS 2201 scope are receipt validation, the policy check, per diem calculation, corporate-card reconciliation, accountable-plan verification, the approval workflow, duplicate detection and journal-entry approval.

SOC 1 Type II covers the controls over financial reporting and SOC 2 Type II the security, availability, processing-integrity, confidentiality and privacy criteria, alongside ISO 27001 for information security.

IRS Section 6001 and Treasury Reg 1.274-5 require seven years' general retention of the underlying records - receipts, per diem claims, mileage logs, card transactions, policy assignments, approvals and reimbursement confirmations - with the statute of limitations running to six years for a substantial understatement.

The GDPR governs the employee data: a lawful basis under Article 6, special-category handling under Article 9 where a receipt carries health data, the Article 88 employee-data rules and the Article 22 ban on solely automated decisions. The EU AI Act adds AI literacy, transparency, human oversight and deployer obligations, with fines up to EUR 15M or 3 per cent of global turnover.

## Where it connects to the other agents

The agent integrates with the Payroll-Accounting Agent for journal-entry posting and accruals, the Payroll-Calculation Agent for non-accountable W-2 inclusion and the UK P11D and Class 1A NIC, the Expense-Processing Agent for non-travel spend and AP automation, the HR-Document-Management Agent for receipt retention, and the Audit-Compliance Agent for SOX 404 and the auditor walkthrough.

The Decision Layer produces the audit trail as a by-product: every receipt validation, policy check, per diem calculation, card reconciliation, accountable-plan verification, approval and reimbursement is logged with timestamps and signatures, retained under the EU AI Act Article 12 record-keeping duty and the seven-year US and six-year UK retention rules.

## At a glance

- 12 deterministic decisions covering submission, policy check, GSA per diem, UK AMAP and subsistence, EU per diem, card reconciliation, accountable-plan verification, approval, duplicate detection, journal entry, reimbursement and the audit trail
- 2 ML-augmented indicators for receipt OCR and fraud detection
- 1 mandatory human escalation through the approval workflow and compliance review for high-risk items
- Seven-year retention under IRS Section 6001 and US SOX, six under UK HMRC PAYE and the Companies Act, with the EU AI Act Article 12 record-keeping duty
- Financial-process profile under the EU AI Act, not Annex III

### Decision-Maker Distribution Travel-Expense

| Decision Type | Count | Examples | Statutory Basis |
|---------------|-------|----------|-----------------|
| R Rule-based | 12 | Submission, policy check, GSA per diem, UK AMAP and subsistence, EU per diem, card reconciliation, accountable plan, approval, journal entry, reimbursement and audit trail | IRS Pub 463, Treasury Reg 1.274-5, Section 62(c), UK Section 336 ITEPA, AMAP and subsistence scale rates, EU per diem, SOX 404 |
| A AI-augmented | 2 | Receipt OCR, fraud detection and anomaly scoring | EU AI Act Articles 13-26, AICPA SOC 2, ACFE red flags |
| H Human | Implicit | Approval workflow and compliance review for high-risk items | SOX 302 and 906, COSO, the four-eyes principle |

--- HR Vendor Management Agent ---
> HR vendor lifecycle: contract milestones, KPI/SLA monitoring, CSDDD 2024/1760 due diligence, GDPR Art. 28 processor agreements and ESRS S2 reporting for payroll, benefits and HR BPO suppliers.

A company with 1,500 employees typically maintains 60-100 HR vendors: payroll providers (ADP, Paychex, Workday Payroll, Ceridian Dayforce), benefits providers (group health insurance, 401(k) administrators, FSA/HSA), training providers (LMS Workday Learning, RPO Recruitment Process Outsourcing), HR SaaS (HRIS Workday, BambooHR, Personio, ATS Greenhouse, Lever), staffing providers, occupational health and safety providers. Each relationship must have a current GDPR Art. 28 processor agreement, compliant SLA, KPI monitoring, CSDDD due diligence and ESRS S2 reporting. In practice at least one of these five conditions is almost always breached.

## HR vendor management in CSDDD context

HR vendors are not just contractual relationships but fragments of the company value chain. The EU CSDDD 2024/1760 of 13.06.2024 introduces mandatory value-chain due diligence from 26.07.2027 for firms with 5,000+ employees and 1.5 billion EUR global turnover, with Member State transposition by 26.07.2026.

The system managing vendors comes from the previous decade. A SharePoint folder with 200 contracts, 40 of which have incomplete GDPR Art. 28 clauses. An Excel spreadsheet monitoring notice periods, where 15 contracts have already auto-renewed despite SLA breaches.

The result: the firm operates in a value chain with vendors from high-risk human-rights jurisdictions without audits, signs SCC 2021/914 contracts for USA without Transfer Impact Assessment per Schrems II, loses control of market consolidation (Workday acquisition of Peakon, ADP acquisition of Celergo reducing alternatives below 3 vendors). Big 4 auditor review of ESRS S2 reporting discovers the firm has no CSDDD due-diligence policy - audit qualification, exclusion from sustainability indices.

## The UK: Modern Slavery Act and Procurement Act 2023

UK Modern Slavery Act 2015 Section 54 mandates annual transparency statements for organisations with global turnover above 36 million GBP carrying on business in the UK. Statement covers organisation structure, supply-chain mapping including HR vendors, slavery and human-trafficking policies, due-diligence processes, supplier risk assessment, KPIs and training. Statement signed by director, approved by board, published on website homepage prominently, and from FY 2026 in annual report under Companies Act 2006 Section 414C.

UK Procurement Act 2023 from 24.02.2025 replaces PCR 2015 for new procurements with central digital platform single sign-on, simplified competitive tendering, mandatory Schedule 6 exclusion grounds for modern slavery convictions and tax evasion, supplier debarment list, KPI publication for contracts above 5 million GBP, 30-day payment terms in public-sector supply chains. Thresholds 2026: 138,760 GBP central government services, 213,477 GBP sub-central government services, 5,336,937 GBP works.

PCR 2015 procedures continue for ongoing procurements: Reg 26 open procedure, Reg 28 restricted procedure, Reg 30 competitive procedure with negotiation, Reg 32 innovation partnership. Vendor selection criteria weight price (typically below 60 percent for quality preservation), quality, experience, ESG/CSDDD compliance, GDPR Art. 28 readiness.

The agent automates Modern Slavery and Procurement compliance through (a) HR vendor classification by Modern Slavery risk based on industry and country of operation, (b) Self-Assessment Questionnaire SAQ distribution for high-risk vendors, (c) integration with Sedex SMETA, EcoVadis, IntegrityNext for third-party audits, (d) automatic Section 54 statement generation, (e) UK Find a Tender Service FTS publication for public-sector procurement.

## The EU: CSDDD due diligence and ESRS S2 reporting

EU CSRD Corporate Sustainability Reporting Directive 2022/2464 mandates sustainability reporting through 12 ESRS European Sustainability Reporting Standards. ESRS S2 Workers in the Value Chain covers vendor and sub-supplier workers - the key standard for Vendor Management Agent. Requirements:

- S2-1: human-rights policies aligned with UNGP UN Guiding Principles and OECD Guidelines for Multinational Enterprises, CSDDD due-diligence policy, supplier code of conduct with 11 worker-rights standards (aligned with ILO Conventions 29 forced labour, 138 minimum age, 105 abolition of forced labour, 87 freedom of association, 98 collective bargaining, 100 equal pay, 111 anti-discrimination, 155 OHS)
- S2-2: engagement processes - on-site audits SMETA Sedex Members Ethical Trade Audit, employee surveys, vendor visits, BAFA reporting for German LkSG-bound parents
- S2-3: grievance mechanisms - a channel for vendor employees and local communities, integrated with the EU Whistleblower Directive and the UK PIDA, whose scope reaches vendor employees as well as the company's own
- S2-4: corrective actions - violation correction identified by due diligence, corrective plan with vendor, monitoring progress, in extreme cases contract termination
- S2-5: targets - human-rights risk reduction, SA8000 certification, EcoVadis Gold/Silver, Scope 3 GHG reduction per GHG Protocol

Reporting timeline: FY 2024 for large public-interest entities (5,000+ employees, listed in EU regulated markets), FY 2025 for large companies 500+ employees, FY 2026 for listed SMEs. Big 4 auditor (Deloitte, EY, KPMG, PwC) provides limited assurance from FY 2024, reasonable assurance from FY 2028. Misreporting generates audit qualification (modified opinion), CSRD non-compliance penalty up to 5 percent of turnover under Member State implementation.

## GDPR Article 28 and the Schrems II transfer rules

GDPR Art. 28 mandates processor agreement with every HR vendor with access to employee personal data - 35 mandatory clauses:

- subject matter, duration, nature, purpose of processing
- data categories (employee personal data, special-category data Art. 9 health/biometric/union-membership)
- data subject categories (employees, candidates, former employees, dependents)
- processor obligations Art. 28(3) a-h - documented instructions, personnel confidentiality, TOM Technical and Organisational Measures Art. 32, sub-processors with prior consent, audit rights, data return/deletion after termination

Standard Contractual Clauses SCC 2021/914 of 04.06.2021 mandatory from 27.12.2022 for third-country transfers - Module 2 controller-to-processor, Module 3 processor-to-sub-processor. Schrems II Court of Justice EU C-311/18 of 16.07.2020 requires Transfer Impact Assessment TIA with national-law assessment (FISA 702 for USA), technical measures (end-to-end encryption, fragmentation, HSM keys separated). EU-US Data Privacy Framework DPF from 10.07.2023 partially replaces SCC for USA for certified firms.

UK post-Brexit applies UK ICO Transfer Risk Assessment TRA, UK International Data Transfer Agreement IDTA, UK Addendum to EU SCC.

Violations generate ICO sanctions up to 17.5 million GBP or 4 percent of global turnover, EU DPA up to 20 million EUR per Art. 83(4) GDPR.

## Where it connects to the other agents

The agent collaborates with Payroll-Processing Agent through ratification of payroll providers (ADP, Paychex, Ceridian, Workday Payroll, BPO Payroll) with GDPR Art. 28 processor agreement, KPI monitoring of calculation (period-close time, accuracy of IRS Form 941/HMRC RTI FPS submissions, payroll error rate).

Cooperation with Compensation-Benchmarking Agent covers ratification of benchmark data vendors (Mercer, Korn Ferry, WTW Willis Towers Watson, Radford, Aon McLagan) with verification of methodological independence, transparency of measurement methods per EU Pay Transparency Directive 2023/970, ESG/CSRD ESRS S1-9.

HR-Document-Management Agent archives vendor contracts in vendor folder per SOX 404 (7-year retention for US public companies) for standard contracts and 10+ years for strategic board-level contracts. Vendor Management manages contract creation, KPI monitoring and termination, HR Document Management archives as HR documents with metadata and eIDAS qualified electronic signature.

The four agents share the infrastructure of eIDAS qualified electronic signature (DocuSign, Adobe Sign), GDPR Art. 30+32 audit trail, integration with Workday, SAP SuccessFactors, Oracle HCM as central HRIS systems.

## The [Decision Layer](/en/decision-layer/) turns vendor management into a verifiable process

The Decision Layer decomposes the vendor lifecycle into individual decision steps and defines for each: human, rules engine or AI. Vendor type classification, FAR validation, GDPR Art. 28 validation, KPI monitoring and contract milestone monitoring fall under the rules engine. SCC and Schrems II validation, CSDDD due diligence and performance-feedback aggregation are taken by AI with confidence scoring of 80-92 per cent. GDPR Art. 22 excludes full automation - AI classification below threshold escalates to ESG Lead or DPO, contracting decision for high-risk vendor always remains with board.

Humans remain where the decision is genuinely needed: strategic contract approval by board with SOX 302/906 (US) or Companies Act 2006 Section 172/174 (UK) liability, vendor selection in competitive tender, controversial CSDDD risk assessment, contract termination after SLA breaches. The board sees a verified package - FAR validation, GDPR Art. 28 validation, SCC validation, CSDDD due diligence, KPI monitoring, eIDAS qualified electronic signature - and authorises the decision.

## At a glance

- 60-100 HR vendors in a typical 1,500-employee company, one of five conditions always breached
- US FAR 48 CFR thresholds 250,000 USD for federal procurement with full and open competition under Part 15
- UK Procurement Act 2023 from 24.02.2025 replaces PCR 2015, mandatory exclusion grounds Schedule 6, KPI publication above 5 million GBP
- UK Modern Slavery Act 2015 Section 54 above 36 million GBP global turnover, statement signed by director, board approval
- EU CSDDD 2024/1760 value-chain due diligence from 26.07.2027 (5,000+), Member State transposition by 26.07.2026
- EU GDPR Art. 28 processor agreement with 35 mandatory clauses, sanction ICO up to 17.5 million GBP / EU DPA 20 million EUR
- SCC 2021/914 with Schrems II safeguards, the EU-US Data Privacy Framework and the UK ICO TRA and IDTA for third-country transfers
- EU CSRD ESRS S2 Workers in Value Chain S2-1+S2-2+S2-3+S2-4+S2-5 reporting Big 4 auditor and CSRD register
- AICPA SOC 2 Type II, ISO 27001:2022 and ISO 27036, with DFARS 252.204-7012 for US federal IT vendors
- 7-year retention SOX 404 (US public companies), 3-year Section 388 (UK), 10+ years for strategic board-level contracts

### Decision-Maker Distribution Vendor-Management

| Decision                                 | Decider | Legal basis                    |
| ---------------------------------------- | ------- | ------------------------------ |
| Vendor type classification | Rule | Vendor category matrix |
| FAR 48 CFR validation | Rule | Federal thresholds, SAM.gov |
| UK Procurement Act 2023 validation | Rule | FTS thresholds, Schedule 6 |
| GDPR Art. 28 processor agreement | Rule | 35-clause checklist |
| SCC 2021/914 and Schrems II | AI | GDPR Art. 22, EU-US DPF |
| CSDDD 2024/1760 due diligence | AI | GDPR Art. 22, UNGP/OECD |
| Modern Slavery Act Section 54 | Rule | Section 54, SAQ, SMETA |
| SLA and KPI validation | Rule | Liquidated damages |
| Approval workflow | Rule | Board matrix, SOX 302 |
| KYV/AML and sanctions screening | Rule | BOI, OFAC, OFSI, EU list |
| Continuous KPI monitoring | AI | GDPR Art. 22 |
| Contract milestone monitoring | Rule | SOX 404, Section 388 |
| Periodic competitive tender | Human | SOX 302/906, Section 172/174 |
| ESRS S2 report generation | AI | ESRS S2, CSRD audit |

--- Workforce Planning Agent ---
> Deterministic capacity forecasting: UK TULRCA Section 188 collective consultation, UK Equality Act Section 19 indirect-discrimination audit, GDPR Art. 22 and EU AI Act Annex III(4)(b).

## Workforce planning as operational forecasting discipline

Workforce planning is treated as a strategic black box in many companies. The board sets a headcount target, HR calculates cost-centre budgets, the trade union representatives find out too late, and ultimately a restructuring plan lands on the table where nobody can explain why exactly these 47 positions are being cut. The Workforce Planning Agent disassembles this black box into deterministic forecasting models, rule-based consultation workflows and clearly separated human decision points.

In default mode, the agent is not an EU AI Act high-risk system. It calculates headcount requirements from the order book, seasonality and attrition history, reconciles them with the skills inventory and delivers a capacity-planning view per cost centre. That is operational forecasting and does not fall under Annex III(4)(b) of the EU AI Act 2024/1689. Only when the optional redundancy recommendation module is activated does the classification switch to high-risk with DPIA mandatory under Article 35 UK GDPR, prohibition on solely automated decisions under Article 22, and the affected employee's right to challenge. Most companies deliberately do not activate this module.

## UK TULRCA Section 188 collective consultation as hard compliance gate

Workforce planning involving 20-plus redundancies in a 90-day period triggers UK TULRCA Section 188 collective consultation obligations. The employer must inform employee representatives or recognised trade union in good time, consult meaningfully on ways to avoid or reduce redundancies, and follow the 30-day minimum for 20-99 redundancies or 45-day minimum for 100-plus. This consultation is not negotiable - Employment Tribunals have repeatedly confirmed that workforce decisions without meaningful Section 188 consultation are vulnerable to Section 189 protective award of up to 90 days gross pay per affected employee.

The agent triggers Section 188 consultation workflow automatically when 20-plus redundancies are proposed within a 90-day period. Employee representatives or trade union representatives receive written information with proposal data, an agreed consultation window, and the consultation status is documented in the Decision Record. Without documented meaningful consultation, the agent blocks plan approval. The HR1 form to Department for Business and Trade is prepared and submitted electronically as Section 193 mandates.

For multi-site UK groups, the ICE Regulations 2004 add a complication: undertakings with 50-plus employees may have I and C agreements requiring consultation at group level. The agent manages this hierarchy and triggers the appropriate body. Cross-border consultations under the European Works Council Directive (still relevant for UK groups operating EU subsidiaries) also enter the workflow.

## Redundancy selection as rule-based human-in-loop process

Redundancy selection is rule-based following UK Employment Tribunal case law and the ACAS Guide to Redundancy. The agreed selection criteria - capability, skills, experience, length of service, disciplinary record and attendance - are weighted in advance with employee representatives and applied deterministically. Employment Tribunals have clarified in numerous cases that the employer has discretion in setting the selection matrix, but the matrix must be documented in advance and ideally agreed with the workforce.

The agent calculates selection scores deterministically using the agreed matrix and delivers a sorted selection list. The final decision is made by HR leadership together with trade union or employee representatives - the agent calculates, does not recommend. ML-based selection is not recognised by Employment Tribunals and would regularly fail at Section 98 fair reason challenge. Equality Act Section 20-22 reasonable adjustments for disability are automatically applied as score adjustments, and Section 19 indirect discrimination is monitored statistically.

When fewer than 20 redundancies are proposed, individual consultation under ACAS Code of Practice applies instead of Section 188 collective consultation - but the selection rules and discrimination protections remain.

## Equality Act discrimination audit as statistical obligation

Workforce planning is discrimination-prone. When a restructuring plan disproportionately affects older employees, women in maternity periods, or disabled workers, Equality Act Section 19 indirect discrimination and Section 136 reverse burden of proof apply. The employer must then prove that the selection was not based on protected characteristics - a proof that is practically impossible without documented statistical audits.

The agent performs quarterly Equality Act Section 19 audits, checking workforce planning for disparate impact across the protected characteristics - age, sex, race, disability, pregnancy, religion and sexual orientation. Disparate impact thresholds (e.g. 80 per cent rule used by EHRC for evidence purposes) trigger Section 19 audit report with statistical justification. EHRC has documented hundreds of formal investigations in their 2024 Annual Report - each one represents uncapped compensation risk at Employment Tribunal.

## EU AI Act and the high-risk switch

The Workforce Planning Agent is not a high-risk system in default mode. It becomes one only when the optional redundancy recommendation module is activated. This separation is deliberate: EU AI Act Annex III(4)(b) classifies AI systems in the employment domain as high-risk when they decide or contribute to the termination of employment relationships. Headcount forecasting and capacity planning do not fall under this; redundancy recommendations do.

When a company activates the module, the following immediately apply: DPIA mandatory under Article 35 UK GDPR, conformity assessment under EU AI Act Article 43, registration in the EU database under Article 49, technical documentation under Annex IV, risk management system under Article 9, data governance under Article 10 and human oversight under Article 14. UK GDPR Article 22 additionally prohibits solely automated decisions with legal effects - the redundancy recommendation can never be implemented without human final decision, and the employee has the right to explanation, challenge and human review.

In practice, most companies deliberately do not activate this module. The additional compliance burden regularly exceeds the benefit because human final decision is mandatory anyway and the ML model only delivers a second opinion.

## Board reporting and ESG disclosure

For UK-listed and large private companies subject to Section 414C strategic report obligations, Companies Act 2006 Section 172 requires the strategic report to address employee engagement, consultation outcomes, restructuring impact, training investment and stakeholder considerations. The agent generates the Section 172 statement automatically and tracks UK Corporate Governance Code Principle E workforce engagement compliance. The final board approval remains human - the board is a human body, not a decision engine. FRC monitors compliance through audit quality reviews and the upcoming ARGA transition.

ESG CSRD ESRS S1 Own Workforce reporting is mandatory for 250-plus employee entities with auditor verification mandatory from 2024. The agent delivers the quantitative data points - headcount, attrition, diversity metrics, training hours and injury rate - through an auditor interface. The qualitative data points - strategy, the materiality assessment and stakeholder engagement - remain human; the agent delivers only the data foundation.

## Cross-references in the HR Decision Layer

The Workforce Planning Agent does not stand alone. It delivers capacity forecasting to the [Succession-Planning-Agent](/en/hr-agent-catalog/succession-planning-agent/) Cluster #28 for succession pipelines on critical positions, to the [Talent-Pool-Agent](/en/hr-agent-catalog/talent-pool-management-agent/) Cluster #29 for recruiting requirements per skill cluster, to the [Compensation-Benchmarking-Agent](/en/hr-agent-catalog/compensation-benchmarking-agent/) Cluster #26 for cost-centre budgets and to the Performance-Review-Agent for calibration cohorts. The Decision Layer is shared and exchanges TULRCA consultation status, Equality Act audit results and UK GDPR legal basis.

This interlocking turns isolated forecasting silos into a consistent workforce governance system in which every plan change automatically triggers consultation, discrimination and data protection obligations. When trade union representatives block the restructuring plan because the redundancy selection lacks plausibility, the system delivers the rule-based selection matrix with justification within hours - instead of a black-box recommendation that nobody can explain.

--- Works Council Coordination Agent ---
> Works council coordination: UK ICE Regulations 2004 classification, TULRCA Section 188 + ACAS Code deadlines, GDPR Art. 22 and AI Act Annex III(4)(b) - audit-trail-secured consultation.

## Works council coordination as compliance obligation

A dismissal without proper consultation with employee representatives is not automatically void in UK law as it is in Germany. But the consequences are severe: TULRCA Section 189 protective award up to 90 days gross pay per affected employee at Employment Tribunal, Section 124A ACAS Code 25 per cent uplift, and uncapped Equality Act discrimination compensation if the redundancy selection is challenged. UK Employment Tribunals receive hundreds of thousands of claims annually. A substantial proportion of these challenge formal defects in consultation procedures - because these defects are the most reliable route to higher tribunal awards.

The problem is not a knowledge problem. HR departments know the rules. The problem is a coordination problem.

## Multiple consultation levels with different deadlines

UK employment law has multiple consultation levels with different deadlines and different consequences for breaches:

```
Level                       Statute              Deadline           Consequence for breach
─────────────────────────────────────────────────────────────────────────────────────────
Individual consultation     ACAS Code            Reasonable          Section 124A 25% uplift
Section 188 (20-99)         TULRCA              30 days minimum     90 days gross pay per employee
Section 188 (100+)          TULRCA              45 days minimum     90 days gross pay per employee
TUPE Regulation 14          TUPE 2006           28 days before      Tribunal claim
ICE Regulations             ICE 2004            Negotiated period    Unlawful act
EWC (cross-border)          Dir 2009/38/EC      Negotiated period    EU enforcement
```

The challenge is not to know this table. The challenge is, with every individual HR measure - dismissal, recruitment, transfer, grading, working time change - to identify the correct level within seconds, gather the correct documents, and start the correct deadline. In a 1,500-employee company, a dozen consultation procedures may run simultaneously in a single week.

Each of these procedures has a different trigger, different documents, different deadlines, and different escalation paths. And each individual procedure is coordinated in most companies by email, paper, or oral arrangement. There is no central deadline calendar. There is no automatic completeness check of documents. There is no system that recognises whether the intended transfer of an employee triggers a Section 188 consultation obligation or only individual ACAS Code consultation.

## Why formal defects upset dismissals

Section 188 TULRCA is the critical touchpoint between HR and Trade Union representatives or elected employee representatives. The requirements are clearly formulated: When 20-plus redundancies are proposed within a 90-day period, the employer must consult meaningfully with appropriate representatives about ways to avoid the dismissals, ways to reduce the number, and ways to mitigate the consequences. The minimum consultation period is 30 days for 20-99 redundancies and 45 days for 100-plus.

In practice, it fails at three points.

First: incomplete information. The employer must provide all reasons that lead to the proposed redundancies. Skeleton or outline-only descriptions are not sufficient under Employment Tribunal case law. The representatives must be able to form an opinion without their own research. If a relevant detail is missing - such as the dependants of the affected when discussing selection criteria - the entire consultation is defective.

Second: incorrect deadline calculation. The 30/45-day minimum starts with receipt of complete information by representatives. Not with sending. Not with the invitation to meeting. With receipt of the complete documents. A dismissal pronounced one day too early is vulnerable to protective award.

Third: post-event reasons. Reasons for which representatives were not consulted cannot be added later in the Employment Tribunal proceeding. What is missing from consultation, is missing in the Tribunal.

Each of these errors is avoidable. None of them requires legal judgment. All three are coordination errors: The correct information was available but not completely passed on. The deadline was known but incorrectly calculated. The reason existed but was not documented.

## ICE Regulations 2004 bottleneck for 50-plus undertakings

Section 188 is the visible scene, but not the most common. ICE Regulations 2004 govern employee representative involvement for undertakings with 50-plus employees. Regulation 7 negotiation rights, Regulation 8 default I and C agreement, Regulation 16 information requirements. In undertakings with active I and C agreements, every workplace change requires consultation.

The representatives have a negotiated consultation period. If they raise concerns, the employer must consider them. If consultation is exhausted without agreement, the employer can proceed - but the consultation outcome is recorded. The agent triggers ICE Regulations consultation workflow automatically, manages the negotiated consultation period, and documents the consultation outcome.

For UK groups operating EU subsidiaries, the European Works Council Directive 2009/38/EC adds additional cross-border consultation obligations. The agent manages this hierarchy and triggers the appropriate body.

## The rule engine finds the correct UK statute

The [Decision Layer](/en/decision-layer/) decomposes every consultation procedure into individual decision steps and defines for each step: Human, Rule, or AI. The assignment of the consultation level - which statute applies, which documents are needed, which deadline runs - is Rule. The completeness check of documents against a checklist is AI-assisted. The deadline monitoring is Rule. The decision on how to deal with employee representative objection remains with the Human.

Specifically, the procedure changes in four places.

Consultation classification happens automatically. Every planned HR measure is checked against UK statutes. The system detects whether ACAS Code individual consultation, TULRCA Section 188 collective consultation, TUPE Regulation 14, ICE Regulations 2004, or European Works Council Directive applies. Not the HR officer must find the correct statute. The rule engine finds it.

Documents are checked against a checklist. For each consultation level and each measure type, a defined list exists: What information must employee representatives receive? Are the social data of the affected complete? Is the dismissal reason correctly specified? Are the reasons fully drafted instead of only outlined? The check happens before transmission to representatives, not after.

Deadlines are tracked from the moment of transmission. The 30-day minimum for Section 188, the 45-day minimum for 100-plus, the 28-day TUPE notice - each deadline runs with documented start time and automatic escalation on expiry. Representatives have allowed their deadline to expire? The system documents the assumption of consent. Representatives have objected? The HR responsible is immediately informed, with next steps and relevant deadlines for ACAS Early Conciliation.

The entire procedure is documented audit-trail-secure. Every step, every document, every deadline, every statement, every decision. When an employee challenges the dismissal six months later and the solicitor disputes proper consultation, the complete procedural evidence is available. Not as reconstructed chronology from email trails, but as audit trail containing every individual step with timestamp and proof. HMRC PAYE retention requires 6 years, ICO Records Management Code applies.

## The agent that serves both sides

Most agents in HR work for one side. The Works Council Coordination Agent is different. It professionalises the formal framework - and both sides benefit.

HR benefits because no procedures fail on formal defects. Because document preparation takes hours instead of days. Because the risk of an unfavourable Employment Tribunal protective award due to defective consultation goes to zero.

Employee representatives benefit because they receive complete documents. Because their deadlines are correctly calculated and not unilaterally interpreted by the employer. Because the documentation creates transparency they previously had to demand. Cross-reference UK ICE Regulations 2004 negotiated I and C agreement with audit-trail access for employee representatives is standard.

The consultation classification engine - which statute for which measure, which documents, which deadline - is not an isolated function. Every agent in the Decision Layer that triggers a measure with consultation relevance uses the same logic. [Workforce-Planning-Agent](/en/hr-agent-catalog/workforce-planning-agent/) Cluster #58 triggers Section 188 on redundancy. The Onboarding-Agent triggers consultation on recruitment. The [Compensation-Benchmarking-Agent](/en/hr-agent-catalog/compensation-benchmarking-agent/) Cluster #26 triggers consultation on remuneration changes. The deadline calendar, the checklists, and the audit trail become shared infrastructure.

--- HR Agent - AI Agents for HR & People Operations ---
> 6 AI Agent products for HR: Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Decision Layer with Audit Trail. Employee representation ready.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/en/why-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Every decision traceable</p>
</div>
</a>
<a href="/en/why-gosign/#infrastructure" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Your infrastructure</p>
<p class="text-xs text-gosign-text-light">No SaaS. No vendor lock-in.</p>
</div>
</a>
<a href="/en/why-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">No US cloud risk</p>
</div>
</a>
</div>
</div>
</div>

<!-- Product Portfolio -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">HR Agent Portfolio</h2>
<p class="text-body-lg text-gosign-text-light mt-4 mb-8 max-w-narrow">
An HR Agent does not automate wholesale - it decomposes processes into micro-decisions. For each decision, the <a href="/en/decision-layer/" class="text-gosign-accent-text hover:text-gosign-accent-hover">Decision Layer</a> defines: human, rule set, or AI.
</p>
<div class="grid grid-cols-1 md:grid-cols-2 lg:grid-cols-3 gap-6">
<a href="/en/services/hr-agent/payroll-decision-layer/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<div class="flex items-center justify-between mb-3">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 18.75a60.07 60.07 0 0115.797 2.101c.727.198 1.453-.342 1.453-1.096V18.75M3.75 4.5v.75A.75.75 0 013 6h-.75m0 0v-.375c0-.621.504-1.125 1.125-1.125H20.25M2.25 6v9m18-10.5v.75c0 .414.336.75.75.75h.75m-1.5-1.5h.375c.621 0 1.125.504 1.125 1.125v9.75c0 .621-.504 1.125-1.125 1.125h-.375m1.5-1.5H21a.75.75 0 00-.75.75v.75m0 0H3.75m0 0h-.375a1.125 1.125 0 01-1.125-1.125V15m1.5 1.5v-.75A.75.75 0 003 15h-.75M15 10.5a3 3 0 11-6 0 3 3 0 016 0zm3 0h.008v.008H18V10.5zm-12 0h.008v.008H6V10.5z"/></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Payroll Decision Layer</h3>
<p class="text-body text-gosign-text-light mt-2">Collective agreements, shift allowances, special payments. 4 industry simulations.</p>
<p class="text-body font-semibold text-gosign-dark mt-3">82-92% Zero-Touch</p>
</a>
<a href="/en/services/travel-decision-layer/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<div class="flex items-center justify-between mb-3">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M6 12L3.269 3.126A59.768 59.768 0 0121.485 12 59.77 59.77 0 013.27 20.876L5.999 12zm0 0h7.5"/></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Travel Decision Layer</h3>
<p class="text-body text-gosign-text-light mt-2">Every expense report decomposed into 5-12 auditable decision steps.</p>
<p class="text-body font-semibold text-gosign-dark mt-3">>80% cost reduction per receipt</p>
</a>
<a href="/en/recruiting-agent/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<div class="flex items-center justify-between mb-3">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M18 18.72a9.094 9.094 0 003.741-.479 3 3 0 00-4.682-2.72m.94 3.198l.001.031c0 .225-.012.447-.037.666A11.944 11.944 0 0112 21c-2.17 0-4.207-.576-5.963-1.584A6.062 6.062 0 016 18.719m12 0a5.971 5.971 0 00-.941-3.197m0 0A5.995 5.995 0 0012 12.75a5.995 5.995 0 00-5.058 2.772m0 0a3 3 0 00-4.681 2.72 8.986 8.986 0 003.74.477m.94-3.197a5.971 5.971 0 00-.94 3.197M15 6.75a3 3 0 11-6 0 3 3 0 016 0zm6 3a2.25 2.25 0 11-4.5 0 2.25 2.25 0 014.5 0zm-13.5 0a2.25 2.25 0 11-4.5 0 2.25 2.25 0 014.5 0z"/></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Recruiting Agent</h3>
<p class="text-body text-gosign-text-light mt-2">Screening, scheduling, standard communication. EU AI Act high-risk.</p>
<p class="text-body font-semibold text-gosign-dark mt-3">70-75% automation</p>
</a>
<a href="/en/services/hr-agent/leave-absence-decision-layer/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<div class="flex items-center justify-between mb-3">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M6.75 3v2.25M17.25 3v2.25M3 18.75V7.5a2.25 2.25 0 012.25-2.25h13.5A2.25 2.25 0 0121 7.5v11.25m-18 0A2.25 2.25 0 005.25 21h13.5A2.25 2.25 0 0021 18.75m-18 0v-7.5A2.25 2.25 0 015.25 9h13.5A2.25 2.25 0 0121 11.25v7.5"/></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Leave & Absence Decision Layer</h3>
<p class="text-body text-gosign-text-light mt-2">Leave entitlements, absence rules, return-to-work obligations. 4 industry simulations.</p>
<p class="text-body font-semibold text-gosign-dark mt-3">78-87% Zero-Touch</p>
</a>
<div class="border border-gosign-border rounded-card p-6 bg-gosign-light/50">
<div class="flex items-center justify-between mb-3">
<svg class="w-8 h-8 text-gosign-text-light" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M16.023 9.348h4.992v-.001M2.985 19.644v-4.992m0 0h4.992m-4.993 0l3.181 3.183a8.25 8.25 0 0013.803-3.7M4.031 9.865a8.25 8.25 0 0113.803-3.7l3.181 3.182"/></svg>
<span class="inline-flex items-center px-2.5 py-0.5 text-xs font-bold text-white bg-gosign-accent rounded-full">Coming</span>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Employee Lifecycle Decision Layer</h3>
<p class="text-body text-gosign-text-light mt-2">Onboarding, internal transfers, offboarding in one auditable pipeline.</p>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-gosign-light/50">
<div class="flex items-center justify-between mb-3">
<svg class="w-8 h-8 text-gosign-text-light" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 3c2.755 0 5.455.232 8.083.678.533.09.917.556.917 1.096v1.044a2.25 2.25 0 01-.659 1.591l-5.432 5.432a2.25 2.25 0 00-.659 1.591v2.927a2.25 2.25 0 01-1.244 2.013L9.75 21v-6.568a2.25 2.25 0 00-.659-1.591L3.659 7.409A2.25 2.25 0 013 5.818V4.774c0-.54.384-1.006.917-1.096A48.32 48.32 0 0112 3z"/></svg>
<span class="inline-flex items-center px-2.5 py-0.5 text-xs font-bold text-white bg-gosign-accent rounded-full">Coming</span>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Candidate Screening Decision Layer</h3>
<p class="text-body text-gosign-text-light mt-2">EU AI Act high-risk. Bias monitoring. Co-determination (Mitbestimmung) for selection criteria.</p>
</div>
</div>
</div>
</section>

<!-- Start Boring -->
<section class="py-section bg-gosign-light"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Why you should start with boring processes</h2>
<p class="text-body-lg text-gosign-text-light mt-4">The most effective HR agents don't automate the most spectacular processes - but the most repetitive ones. Payroll, time tracking, standard absences: high rule density, low risk, measurable ROI from day 1. The governance infrastructure you build along the way is the prerequisite for more complex agents.</p>
<p class="text-body-lg text-gosign-text-light mt-4">The EU AI Act high-risk classification for HR AI systems stands. Under current law the obligations apply from 2 August 2026, but following the provisional Digital Omnibus agreement of 7 May 2026 they are set to be postponed to 2 December 2027 (formal adoption still pending, as of June 2026). The classification is not changing, so the time should be used to prepare. Starting with boring processes is the fastest path to building that governance infrastructure in production.</p>
</div></div></section>

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Free eBook: AI in HR</p>
<p class="text-body text-gosign-text mb-4">EU AI Act checklist, Decision Framework, works council perspective, and readiness assessment - the governance handbook for HR leaders.</p>
<a href="/en/ebook/ai-hr-governance-handbook/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Download for free</a>
</div>

<!-- Micro-Decisions: 3 HR Processes Compact -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">How an HR Agent Works</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Every HR process consists of dozens of individual decisions. The agent checks against all collective agreement criteria - more consistently than any specialist. Where employee representation bodies, employment law, or discrimination risk require it, a human decides.
</p>
<h3 class="text-h3 font-bold text-gosign-dark mt-10">Sick Leave Processing</h3>
<div class="mt-4 overflow-x-auto">
<table class="w-full text-left text-body">
<thead><tr class="border-b-2 border-gosign-dark"><th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Micro-Decision</th><th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Who Decides</th><th scope="col" class="py-3 font-bold text-gosign-dark">Why</th></tr></thead>
<tbody class="text-gosign-text-light">
<tr class="border-b border-gosign-border"><td class="py-3 pr-4">Check continued pay period</td><td class="py-3 pr-4 font-medium">AI autonomous</td><td class="py-3">Checks against ALL collective agreement criteria - more consistent than any specialist, even on Friday at 4 PM</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4">Assess return-to-work obligation (&gt; 6 weeks in 12 months)</td><td class="py-3 pr-4 font-medium">Human</td><td class="py-3">Employee representation rights require human-in-the-loop (in Germany: works council co-determination), discrimination risk with health data</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4">Inform line manager about absence</td><td class="py-3 pr-4 font-medium">AI autonomous</td><td class="py-3">Consistent information - absence and duration only, no diagnosis</td></tr>
</tbody>
</table>
</div>
<h3 class="text-h3 font-bold text-gosign-dark mt-10">Onboarding</h3>
<div class="mt-4 overflow-x-auto">
<table class="w-full text-left text-body">
<thead><tr class="border-b-2 border-gosign-dark"><th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Micro-Decision</th><th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Who Decides</th><th scope="col" class="py-3 font-bold text-gosign-dark">Why</th></tr></thead>
<tbody class="text-gosign-text-light">
<tr class="border-b border-gosign-border"><td class="py-3 pr-4">Pay grade classification</td><td class="py-3 pr-4 font-medium">Human</td><td class="py-3">Employee representation bodies have oversight rights (in Germany: co-determination (Mitbestimmung) under Works Constitution Act)</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4">IT access and permissions</td><td class="py-3 pr-4 font-medium">Rule set + AI</td><td class="py-3">Standard permissions automatic, special access escalated</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4">Create onboarding plan</td><td class="py-3 pr-4 font-medium">AI + Human</td><td class="py-3">AI creates proposal, hiring manager reviews and adjusts</td></tr>
</tbody>
</table>
</div>
<h3 class="text-h3 font-bold text-gosign-dark mt-10">Employment References</h3>
<div class="mt-4 overflow-x-auto">
<table class="w-full text-left text-body">
<thead><tr class="border-b-2 border-gosign-dark"><th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Micro-Decision</th><th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Who Decides</th><th scope="col" class="py-3 font-bold text-gosign-dark">Why</th></tr></thead>
<tbody class="text-gosign-text-light">
<tr class="border-b border-gosign-border"><td class="py-3 pr-4">Generate role description</td><td class="py-3 pr-4 font-medium">AI</td><td class="py-3">Based on job description, proposal for review</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4">Formulate performance assessment</td><td class="py-3 pr-4 font-medium">Human</td><td class="py-3">Individual assessment, manager is accountable</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4">Check legal compliance of language</td><td class="py-3 pr-4 font-medium">AI + Human</td><td class="py-3">AI checks against known patterns and flags risks, human decides final</td></tr>
</tbody>
</table>
</div>
<p class="text-body-lg text-gosign-text-light mt-8">
<strong>The pattern:</strong> Routine and rules are automated by the agent. Discretionary and legally sensitive decisions stay with humans. Every step is documented.
</p>
<p class="mt-4">
<a href="/en/decision-layer/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">More about the Decision Layer &rarr;</a>
</p>
</div>
</div>
</section>

<!-- Decision Layer Compact -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Decision Layer: Every Decision Auditable</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
The <a href="/en/decision-layer/" class="text-gosign-accent-text hover:text-gosign-accent-hover">Decision Layer</a> decomposes every HR process into individual decision steps and defines for each step: does a human decide, a rule set, or the AI? Where the model can decide with confidence, it decides autonomously. Where bias risk, discrimination potential, or co-determination (Mitbestimmung) is involved, the architecture enforces human review.
</p>
<div class="mt-6 bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-body font-mono text-gosign-dark">
Input &rarr; Model &rarr; Assessment &rarr; Confidence Score &rarr; Reasoning &rarr; Decision Path &rarr; Outcome
</p>
</div>
<p class="text-body-lg text-gosign-text-light mt-4">
Every decision produces a complete data record: input, rule, version, confidence, outcome, timestamp. Auditable for employee representation bodies, external auditors, and internal compliance.
</p>
</div>
</div>
</section>

<!-- Governance & Employee Representation -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Governance & Employee Representation</h2>
<h3 class="text-h3 font-bold text-gosign-dark mt-8">Human-in-the-Loop as Architectural Principle</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Not as an optional approval loop, but as architecturally enforced routing. Autonomous decision at high confidence and low risk. Human-in-the-Loop for bias risk, discrimination potential, and employee oversight matters. Works agreements and collective agreements are mapped as explicit constraints in the Decision Layer - the agent cannot bypass them.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
<a href="/en/governance/co-determination/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Co-determination in detail &rarr;</a>
</p>
<h3 class="text-h3 font-bold text-gosign-dark mt-8">Audit Trail</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Every agent decision produces a complete decision record: input, rule, version, confidence, decision path, outcome, timestamp. Employee representation bodies can trace all decisions through the Auditor Portal. How employee representation bodies shift from blockers to enablers is covered in <a href="/en/magazine/works-council-ai-literacy/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Article 9 of the Blueprint 2026</a>.
</p>
<h3 class="text-h3 font-bold text-gosign-dark mt-8">EU AI Act Readiness</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
The architecture addresses transparency (Art. 13), human oversight (Art. 14), recording obligations (Art. 12), and risk management (Art. 9) as a design principle - no retroactive compliance project needed. (UK: Post-Brexit, the UK pursues a sector-specific approach rather than a single AI Act.)
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
<a href="/en/governance/eu-ai-act/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">EU AI Act Readiness &rarr;</a>
</p>
</div>
</div>
</section>

<!-- Integration -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Integration into Your Existing System Landscape</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
AI Agents do not replace systems. SAP SuccessFactors stays your HCM, Workday stays your HR platform, SAP FI/CO stays your ERP. Agent logic is decoupled from the target system - via standardised interfaces. No migration project, no system change. One process, one system, one agent.
</p>
</div>
</div>
</section>

<!-- ProcessSteps -->
<section class="py-section bg-gosign-dark text-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold">From PoC to Platform</h2>
<div class="grid md:grid-cols-3 gap-8 mt-8">
<div>
<p class="text-xs font-bold uppercase tracking-wider text-gosign-accent-on-dark">Discover - 1 week</p>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-2">Process analysis, understand rule sets, prioritise use cases. Which process has the highest error potential?</p>
</div>
<div>
<p class="text-xs font-bold uppercase tracking-wider text-gosign-accent-on-dark">Build - 3-4 weeks</p>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-2">Production PoC. One agent, one process, live in your infrastructure with Decision Layer and Audit Trail.</p>
</div>
<div>
<p class="text-xs font-bold uppercase tracking-wider text-gosign-accent-on-dark">Scale - Ongoing</p>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-2">More agents, more processes. Same governance, same auditability. After 12-18 months, you operate your agents independently.</p>
</div>
</div>
</div>
</section>

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">HR Agent Readiness Assessment</p>
<p class="text-body text-gosign-text mb-4">7 questions, 3 minutes: How ready is your HR organisation for AI Agents?</p>
<a href="/en/hr-agent-readiness/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Start assessment &rarr;</a>
</div>

<!-- HR Agent Catalog -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex flex-col md:flex-row items-start gap-8">
<div class="flex-1">
<h2 class="text-h2 font-bold text-gosign-dark">HR Agent Catalog: 48 Agents Assessed and Prioritized</h2>
<p class="text-body-lg text-gosign-text mt-4">Which HR agents exist, what governance do they need, and in what order should you start? The catalog assesses 48 agents across 6 dimensions - from Agent Readiness to EU AI Act classification.</p>
<p class="text-body text-gosign-text-light mt-3">11 domains, 3 interactive prioritization quadrants, micro-decision tables for every agent.</p>
<a href="/en/hr-agent-catalog/" class="inline-flex items-center gap-2 mt-4 text-body font-semibold text-gosign-accent hover:underline">Explore the HR Agent Catalog &rarr;</a>
</div>
</div>
</div>
</section>

<!-- Deep Dive in the Agent Briefing -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">Deep Dive in the Agent Briefing (Gosign Magazine)</h2>
<div class="grid md:grid-cols-3 gap-6">
<a href="/en/magazine/works-council-ai-literacy/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<h3 class="text-h3 font-bold text-gosign-dark">Works Council & AI Literacy</h3>
</a>
<a href="/en/magazine/decision-layer-shadow-ai/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<h3 class="text-h3 font-bold text-gosign-dark">Decision Layer & Shadow AI</h3>
</a>
<a href="/en/magazine/eu-ai-act-2026-enterprises/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<h3 class="text-h3 font-bold text-gosign-dark">EU AI Act 2026</h3>
</a>
</div>
</div>
</section>

--- Imprint - Gosign GmbH ---
> Legal notice of Gosign GmbH, Hamburg. Managing directors, contact details, trade register and legal information.

<h1>Imprint</h1>

<h2>Information pursuant to § 5 DDG (German Digital Services Act)</h2>
<p>
Gosign GmbH<br/>
Hallerstraße 8<br/>
20146 Hamburg, Germany
</p>

<h2>Represented by</h2>

<div class="grid grid-cols-1 sm:grid-cols-2 gap-8 not-prose my-8">
<div class="flex items-start gap-4">
<img
src="/images/team/bert-gogolin.webp"
alt="Bert Gogolin, Managing Director of Gosign GmbH"
width="80"
height="80"
class="rounded-full w-20 h-20 object-cover flex-shrink-0"
loading="lazy"
/>
<div>
<p class="font-semibold text-gosign-dark text-body">Bert Gogolin</p>
<p class="text-small text-gosign-text-light">Managing Director</p>
<a
href="https://www.linkedin.com/in/bertgogolin/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center gap-1 text-small text-gosign-text-light hover:text-gosign-accent transition-colors mt-1"
aria-label="Bert Gogolin on LinkedIn"
>
<svg class="w-4 h-4" fill="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path d="M20.447 20.452h-3.554v-5.569c0-1.328-.027-3.037-1.852-3.037-1.853 0-2.136 1.445-2.136 2.939v5.667H9.351V9h3.414v1.561h.046c.477-.9 1.637-1.85 3.37-1.85 3.601 0 4.267 2.37 4.267 5.455v6.286zM5.337 7.433a2.062 2.062 0 01-2.063-2.065 2.064 2.064 0 112.063 2.065zm1.782 13.019H3.555V9h3.564v11.452zM22.225 0H1.771C.792 0 0 .774 0 1.729v20.542C0 23.227.792 24 1.771 24h20.451C23.2 24 24 23.227 24 22.271V1.729C24 .774 23.2 0 22.222 0h.003z"/>
</svg>
LinkedIn
</a>
</div>
</div>

<div class="flex items-start gap-4">
<img
src="/images/team/dieter-gogolin.webp"
alt="Dieter Gogolin, Managing Director of Gosign GmbH"
width="80"
height="80"
class="rounded-full w-20 h-20 object-cover flex-shrink-0"
loading="lazy"
/>
<div>
<p class="font-semibold text-gosign-dark text-body">Dieter Gogolin</p>
<p class="text-small text-gosign-text-light">Managing Director</p>
</div>
</div>
</div>

<h2>Contact</h2>
<p>
Email: web26 [at] gosign.de<br/>
Contact: Via our <a href="/en/contact/" class="text-gosign-accent-text hover:text-gosign-accent-hover">contact form</a> or <a href="/en/contact/#booking" class="text-gosign-accent-text hover:text-gosign-accent-hover">appointment booking</a><br/>
More company data: <a href="/en/facts/" class="text-gosign-accent-text hover:text-gosign-accent-hover">Facts &amp; Figures</a>
</p>

<h2>Trade Register</h2>
<p>
Registration court: Hamburg District Court (Amtsgericht Hamburg)<br/>
Registration number: HRB 112197
</p>

<h2>VAT (US: sales tax equivalent) ID</h2>
<p>
VAT identification number pursuant to § 27a of the German VAT Act (Umsatzsteuergesetz):<br/>
DE215891388
</p>

<h2>Responsible for content pursuant to § 18 (2) MStV</h2>
<p>
Gosign GmbH<br/>
Bert Gogolin<br/>
Hallerstraße 8<br/>
20146 Hamburg, Germany
</p>

<h2>Liability for content</h2>
<p>
As a service provider, we are responsible for our own content on these pages in accordance with § 7 (1) DDG and general legislation. However, pursuant to §§ 8 to 10 DDG, we are not obligated to monitor transmitted or stored third-party information or to investigate circumstances indicating unlawful activity.
</p>
<p>
Obligations to remove or block the use of information under general law remain unaffected. However, liability in this regard is only possible from the time of knowledge of a specific infringement. Upon becoming aware of such violations, we will remove the content immediately.
</p>

<h2>Liability for links</h2>
<p>
Our website contains links to external third-party websites over whose content we have no influence. Therefore, we cannot accept any liability for this external content. The respective provider or operator of the linked pages is always responsible for their content. The linked pages were checked for possible legal violations at the time of linking. Illegal content was not recognisable at the time of linking.
</p>
<p>
Permanent content monitoring of linked pages is unreasonable without concrete indications of a legal violation. Upon becoming aware of legal violations, we will remove such links immediately.
</p>

<h2>Copyright</h2>
<p>
The content and works created by the site operators on these pages are subject to German copyright law. Reproduction, editing, distribution and any kind of use beyond the limits of copyright law require written consent of the respective author or creator. Downloads and copies of this site are permitted for private, non-commercial use only.
</p>
<p>
Where content on this site was not created by the operator, the copyrights of third parties are respected. In particular, third-party content is identified as such. Should you become aware of a copyright infringement, please notify us accordingly. Upon becoming aware of legal violations, we will remove such content immediately.
</p>

<h2>Image credits</h2>
<p>
Management portraits: © Gosign GmbH.<br/>
Graphics and diagrams: Created by Gosign GmbH, partially using AI-assisted tools.<br/>
Unless otherwise noted: © Gosign GmbH. All rights reserved.
</p>

<h2>Dispute resolution</h2>
<p>
The European Commission provides a platform for online dispute resolution (ODR):
<a href="https://ec.europa.eu/consumers/odr/" target="_blank" rel="noopener noreferrer" class="text-gosign-accent-text hover:text-gosign-accent-hover">https://ec.europa.eu/consumers/odr/</a>
</p>
<p>
We are neither willing nor obliged to participate in dispute resolution proceedings before a consumer arbitration board.
</p>

<h2>Trademark notice</h2>
<p>
<a href="https://www.sap.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text hover:text-gosign-accent transition-colors">SAP</a>, SAP S/4HANA, SAP SuccessFactors, SAP Business Technology Platform and SAP Joule are registered trademarks or trademarks of SAP SE, Walldorf, Germany.
</p>
<p>
<a href="https://www.microsoft.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text hover:text-gosign-accent transition-colors">Microsoft</a>, Microsoft Azure, Microsoft Copilot, Microsoft Teams, SharePoint, Active Directory and Microsoft Graph are registered trademarks or trademarks of Microsoft Corporation, Redmond, USA.
</p>
<p>
<a href="https://www.datev.de/" target="_blank" rel="noopener noreferrer" class="text-gosign-text hover:text-gosign-accent transition-colors">DATEV</a> is a registered trademark of DATEV eG, Nuremberg, Germany.
</p>
<p>
<a href="https://www.sage.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text hover:text-gosign-accent transition-colors">Sage</a> is a registered trademark of The Sage Group plc, Newcastle upon Tyne, United Kingdom.
</p>
<p>
<a href="https://www.workday.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text hover:text-gosign-accent transition-colors">Workday</a> is a registered trademark of Workday, Inc., Pleasanton, USA.
</p>
<p>
<a href="https://www.personio.de/" target="_blank" rel="noopener noreferrer" class="text-gosign-text hover:text-gosign-accent transition-colors">Personio</a> is a trademark of Personio SE & Co. KG, Munich, Germany.
</p>
<p>
<a href="https://about.google/" target="_blank" rel="noopener noreferrer" class="text-gosign-text hover:text-gosign-accent transition-colors">Google</a> and Google Calendar are trademarks of Google LLC, Mountain View, USA.
</p>
<p>
All other product and company names mentioned are trademarks or registered trademarks of their respective holders.
</p>
<p>
The use of trademarks on this website is solely for product identification purposes and does not imply affiliation, certification or endorsement by the respective trademark holders.
</p>

--- Accessibility & European Accessibility Act 2025 ---
> The European Accessibility Act is now in force. Who is affected, what does an accessible website mean, and what penalties apply? Clearly explained.

<!-- What is the EAA? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">What is the European Accessibility Act and why does it exist?</h2>
<p class="text-body text-gosign-text leading-relaxed">
The European Accessibility Act (EAA) implements EU Directive 2019/882 across all member states. The EU has created a unified framework: products and services offered to consumers must be accessible to people with disabilities.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
This includes websites and online shops. The goal is straightforward: anyone who wants to buy, book, or find information online should be able to do so regardless of a visual, hearing, or motor impairment. Since <strong>28 June 2025</strong>, the EAA is enforceable law - violations can result in penalties.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
For businesses, this means accessibility is no longer voluntary - it is an obligation. Comparable to the <a href="/en/knowledge/gdpr-obligations-websites/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">GDPR for data protection</a> - if you don't know the rules, you risk fines.
</p>
</div>
</section>

<!-- Who is affected? -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Does the EAA affect my business? A quick guide by organisation type</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
The EAA applies to <strong>economic operators</strong> that place products or services on the market for consumers. Whether you are affected depends less on your legal form and more on what you do.
</p>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse bg-white rounded-card">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Organisation type</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">EAA obligation?</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Explanation</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Company with online shop</td>
<td class="py-3 px-4 text-body text-gosign-accent-text font-semibold">Yes</td>
<td class="py-3 px-4 text-body text-gosign-text">E-commerce is a consumer service. Full EAA obligation applies.</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Company with B2B-only website</td>
<td class="py-3 px-4 text-body text-gosign-text font-semibold">No (formally)</td>
<td class="py-3 px-4 text-body text-gosign-text">The EAA covers only consumer services. Purely business portals are exempt - though accessibility remains advisable.</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Charity / Non-profit</td>
<td class="py-3 px-4 text-body text-gosign-text font-semibold">Usually no</td>
<td class="py-3 px-4 text-body text-gosign-text">Non-profit organisations are generally not covered. However, funders increasingly require accessibility, and charities with commercial offerings (tickets, shop) may be affected.</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Micro-enterprise (&lt; 10 staff, &lt; EUR 2m)</td>
<td class="py-3 px-4 text-body text-gosign-text font-semibold">Exemption possible</td>
<td class="py-3 px-4 text-body text-gosign-text">Micro-enterprises with fewer than 10 employees and under EUR 2 million annual turnover are exempt for services under the EAA.</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Association / Membership body</td>
<td class="py-3 px-4 text-body text-gosign-text font-semibold">It depends</td>
<td class="py-3 px-4 text-body text-gosign-text">Non-commercial associations are usually not covered. But if the body offers paid online services, the EAA applies.</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Public body / Government</td>
<td class="py-3 px-4 text-body text-gosign-accent-text font-semibold">Yes (under EN 301 549)</td>
<td class="py-3 px-4 text-body text-gosign-text">Public bodies do not fall under the EAA but under EN 301 549 and national transpositions - with similar requirements, already mandatory since 2019.</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Micro-enterprise exemption -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">The micro-enterprise exemption: when does it apply?</h2>
<p class="text-body text-gosign-text leading-relaxed">
The EAA provides an exemption for micro-enterprises: businesses with <strong>fewer than 10 employees</strong> and an <strong>annual turnover or balance sheet total under EUR 2 million</strong> are exempt from the service obligations.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
But note: this exemption applies only to <em>services</em>, not to products. A micro-enterprise selling physical products (e.g. running an electronics online shop) is still bound by the EAA product requirements.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Beyond legal obligations, accessibility often makes good business sense. A website that is hard to use loses customers - not just those with disabilities. Clear structure, good contrast, and readable typography help all visitors.
</p>
</div>
</section>

<!-- What does accessible mean? -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">What does "accessible website" actually mean?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Accessibility sounds abstract - but it is very practical. It means that all people can use your website. Three simple examples:
</p>
<ul class="mt-4 space-y-3">
<li class="flex items-start gap-3">
<span class="text-gosign-accent-text font-bold mt-0.5">1.</span>
<p class="text-body text-gosign-text">
<strong>A blind person uses a screen reader</strong> - software that reads screen content aloud. If your images lack alt text, the person hears only "image, image, image" - and understands nothing.
</p>
</li>
<li class="flex items-start gap-3">
<span class="text-gosign-accent-text font-bold mt-0.5">2.</span>
<p class="text-body text-gosign-text">
<strong>A person with low vision needs good contrast.</strong> Light grey text on a white background is barely readable for millions of people with visual impairments. WCAG requires a contrast ratio of at least 4.5:1.
</p>
</li>
<li class="flex items-start gap-3">
<span class="text-gosign-accent-text font-bold mt-0.5">3.</span>
<p class="text-body text-gosign-text">
<strong>A person with a motor impairment cannot use a mouse.</strong> If your website only works via mouse clicks, it is locked for this person. Everything must also be reachable via keyboard.
</p>
</li>
</ul>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Good accessibility also improves <a href="/en/knowledge/schema-org-seo-basics/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">search engine optimisation</a>: alt text, clear headings, and clean code help Google just as much as they help a screen reader.
</p>
</div>
</section>

<!-- WCAG 2.2 AA: The four principles -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">WCAG 2.2 AA: The four principles in plain language</h2>
<p class="text-body text-gosign-text leading-relaxed mb-8">
The WCAG (Web Content Accessibility Guidelines) is the international standard for web accessibility. The EAA requires compliance with level AA. WCAG is built on four core principles:
</p>
<div class="grid md:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Perceivable</h3>
<p class="text-body text-gosign-text">
Content must be available to all senses. Images need descriptions, videos need captions. Contrast must be sufficient. Anyone who cannot see must be able to hear or feel the content.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Operable</h3>
<p class="text-body text-gosign-text">
All functions must be reachable via keyboard - not just via mouse. Navigation must be logical. Users need enough time to read and interact. No flashing content that could trigger seizures.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Understandable</h3>
<p class="text-body text-gosign-text">
Text must be readable. Forms need clear labels. Error messages must explain what went wrong. The website must not behave unexpectedly (e.g. opening new windows without warning).
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Robust</h3>
<p class="text-body text-gosign-text">
Code must be clean so that different browsers and assistive technologies (screen readers, braille displays, voice control) can interpret the content correctly. Standards-compliant HTML is the foundation.
</p>
</div>
</div>
</div>
</section>

<!-- Accessibility statement -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Accessibility statement: what must it include?</h2>
<p class="text-body text-gosign-text leading-relaxed">
The EAA requires a publicly available accessibility statement on your website. This statement is comparable to a privacy policy - it informs visitors about the current state of accessibility. Required information includes:
</p>
<ul class="mt-4 space-y-2">
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text flex-shrink-0 mt-0.5" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor">
<path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" />
</svg>
<p class="text-body text-gosign-text">Which parts of the website are accessible and which are not</p>
</li>
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text flex-shrink-0 mt-0.5" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor">
<path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" />
</svg>
<p class="text-body text-gosign-text">Justification for any remaining limitations</p>
</li>
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text flex-shrink-0 mt-0.5" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor">
<path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" />
</svg>
<p class="text-body text-gosign-text">Contact option for feedback (email, phone, or form)</p>
</li>
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text flex-shrink-0 mt-0.5" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor">
<path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" />
</svg>
<p class="text-body text-gosign-text">Reference to the responsible market surveillance authority</p>
</li>
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text flex-shrink-0 mt-0.5" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor">
<path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" />
</svg>
<p class="text-body text-gosign-text">Date of last review</p>
</li>
</ul>
<p class="text-body text-gosign-text leading-relaxed mt-4">
The statement should be easy to find - ideally linked in the footer, similar to the imprint and privacy policy.
</p>
</div>
</section>

<!-- Why accessibility pays off -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Why accessibility pays off even without a legal obligation</h2>
<p class="text-body text-gosign-text leading-relaxed">
Even if your organisation is not formally covered by the EAA, there are strong reasons for an accessible website:
</p>
<div class="grid md:grid-cols-2 gap-6 mt-6">
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Greater reach</h3>
<p class="text-body text-gosign-text">
87 million people in the EU live with a disability. Millions more are older adults with declining vision or dexterity. Accessible websites reach more people.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Better SEO</h3>
<p class="text-body text-gosign-text">
Google ranks accessible websites higher. Alt text, clean heading structures, and fast load times are both accessibility and SEO factors.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Funder requirements</h3>
<p class="text-body text-gosign-text">
Many public funding programmes and foundations require accessible communication. Organisations seeking grants or public contracts are increasingly asked about accessibility.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Reputation and trust</h3>
<p class="text-body text-gosign-text">
Accessibility demonstrates social responsibility. For charities, NGOs, and companies with ESG goals, it is a genuine argument with stakeholders and the public.
</p>
</div>
</div>
</div>
</section>

<!-- Penalties -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Penalties up to EUR 100,000 - what are the risks?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Under the EAA, member states must establish effective, proportionate, and dissuasive penalties. In Germany, fines of up to <strong>EUR 100,000</strong> apply. National market surveillance authorities enforce the rules. Sanctions can be imposed for:
</p>
<ul class="mt-4 space-y-2">
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text flex-shrink-0 mt-0.5" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor">
<path stroke-linecap="round" stroke-linejoin="round" d="M12 9v3.75m-9.303 3.376c-.866 1.5.217 3.374 1.948 3.374h14.71c1.73 0 2.813-1.874 1.948-3.374L13.949 3.378c-.866-1.5-3.032-1.5-3.898 0L2.697 16.126ZM12 15.75h.007v.008H12v-.008Z" />
</svg>
<p class="text-body text-gosign-text">Missing or inadequate accessibility for EAA-covered services</p>
</li>
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text flex-shrink-0 mt-0.5" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor">
<path stroke-linecap="round" stroke-linejoin="round" d="M12 9v3.75m-9.303 3.376c-.866 1.5.217 3.374 1.948 3.374h14.71c1.73 0 2.813-1.874 1.948-3.374L13.949 3.378c-.866-1.5-3.032-1.5-3.898 0L2.697 16.126ZM12 15.75h.007v.008H12v-.008Z" />
</svg>
<p class="text-body text-gosign-text">Missing accessibility statement on the website</p>
</li>
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text flex-shrink-0 mt-0.5" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor">
<path stroke-linecap="round" stroke-linejoin="round" d="M12 9v3.75m-9.303 3.376c-.866 1.5.217 3.374 1.948 3.374h14.71c1.73 0 2.813-1.874 1.948-3.374L13.949 3.378c-.866-1.5-3.032-1.5-3.898 0L2.697 16.126ZM12 15.75h.007v.008H12v-.008Z" />
</svg>
<p class="text-body text-gosign-text">Non-compliance with orders from the market surveillance authority</p>
</li>
</ul>
<p class="text-body text-gosign-text leading-relaxed mt-4">
In addition, consumer protection organisations can file injunctions. The risk is not limited to fines - cease-and-desist letters and negative publicity are also possible. As with <a href="/en/website-security-standards/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">website security compliance</a>, prevention is cheaper than remediation.
</p>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Accessibility check: 30&nbsp;minutes, free of charge.</h3>
<p class="text-body text-gosign-text mb-6">We review your website against the most important WCAG criteria - no obligation, clearly explained.</p>
<a
href="/en/contact/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Request an accessibility check
</a>
<p class="text-small text-gosign-text-light mt-4">25 years of experience - Lighthouse 100/100 - WCAG 2.2 AA</p>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
Gosign is a Hamburg-based digital agency with 25 years of experience in web development and AI integration.
Our own website achieves Lighthouse 100/100 across all four categories - including Accessibility.
We help mid-market companies, foundations, and public-sector organisations make their websites accessible and legally compliant.
</p>
<p class="text-small text-gosign-text-light mt-2">Last updated: March 2026</p>
</div>
</section>

<!-- Related topics -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Related topics</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/en/knowledge/gdpr-obligations-websites/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Law</p>
<p class="text-body font-semibold text-gosign-dark">GDPR Obligations for Websites</p>
</a>
<a href="/en/knowledge/website-without-cookie-banner/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Privacy</p>
<p class="text-body font-semibold text-gosign-dark">Website Without Cookie Banner</p>
</a>
<a href="/en/knowledge/typo3-updates-security/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">TYPO3</p>
<p class="text-body font-semibold text-gosign-dark">TYPO3 Updates & Security</p>
</a>
</div>
</div>
</section>

--- GDPR Obligations for Websites ---
> What must websites comply with in terms of data protection? GDPR, cookie consent, privacy policy - clearly explained for business leaders.

<!-- What is a privacy policy? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">What is a privacy policy - and why does every website need one?</h2>
<p class="text-body text-gosign-text leading-relaxed">
A privacy policy informs visitors to your website about which personal data is collected, why this happens, and what rights they have. This sounds abstract but is very concrete: as soon as someone visits your website, the server stores an IP address. That is personal data. This alone brings every website under the GDPR.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
The General Data Protection Regulation (GDPR) has been in force across the entire EU since May 2018. It obliges every website operator - whether corporation, SME, association, or charity - to maintain a complete privacy policy. If it is missing or outdated, warnings and fines can follow.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Important: a privacy policy is not the same as a legal notice (imprint). The imprint identifies who is responsible for the website (required under national digital services legislation). The privacy policy governs how data is handled (under the GDPR). Both are mandatory and must exist as separate pages.
</p>
</div>
</section>

<!-- Most common mistakes -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">The most common privacy policy mistakes</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
In practice, we see the same problems again and again. Many are easily avoidable - if you know what to look for.
</p>
<div class="grid md:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Outdated templates</h3>
<p class="text-body text-gosign-text">
Many websites still use privacy policies from 2018 or earlier. Since then, laws have changed (new rulings on Google Fonts, Analytics, and updated national ePrivacy legislation). A template from three years ago is almost certainly no longer compliant.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Missing details</h3>
<p class="text-body text-gosign-text">
The GDPR requires specific information: name of the controller, contact details for the data protection officer (if applicable), legal basis for each processing activity, retention periods, and data subject rights. If any of these are missing, the policy is incomplete.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Copy-paste without customisation</h3>
<p class="text-body text-gosign-text">
A privacy policy must match your actual website. If you use Google Analytics but only mention Facebook Pixel, that is a problem. If you use no analytics tools at all but include three paragraphs about them, that is equally problematic.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Empty or hidden pages</h3>
<p class="text-body text-gosign-text">
Some websites have a link to the privacy policy in the footer, but the page behind it is empty or leads nowhere. Supervisory authorities check this systematically - and specialist lawyers even more so.
</p>
</div>
</div>
</div>
</section>

<!-- Cookie consent -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Cookie consent: why a simple notice is not enough</h2>
<p class="text-body text-gosign-text leading-relaxed">
Cookies are small text files that websites store on a visitor's device. Some are technically necessary (e.g. for the shopping cart in an online shop). Others serve analytics or marketing - and this is where it becomes legally relevant.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
The ePrivacy Directive (implemented nationally in each EU member state - as TDDDG in Germany, PECR in the UK, etc.) requires that before non-essential cookies are set, the visitor must actively consent. This means: a banner reading "This website uses cookies - OK" is not sufficient. The visitor must have a genuine choice - with the ability to reject individual categories.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
In practice, you need a Consent Management Platform (CMP). This tool displays a cookie banner on the first visit with at least two options: "Accept all" and "Necessary only". Only after consent may tracking cookies be set. Without a functioning CMP, any tracking on your website is unlawful.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Note: embedded YouTube videos, Google Maps, and social media buttons also set cookies. If you embed such content, you need either consent or a two-click solution that loads only after approval. The topic of <a href="/en/website-security-standards/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">website security</a> is directly connected - insecure integrations can also cause data protection issues.
</p>
</div>
</section>

<!-- Cookie-banner-free alternative -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<div class="border-2 border-gosign-accent/20 rounded-card p-6 bg-white">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">The better solution: not needing a cookie banner at all</h2>
<p class="text-body text-gosign-text leading-relaxed">
There is an alternative to the cookie banner dilemma: build your website so that it <strong>sets no non-essential cookies at all</strong>. No tracking, no external fonts, no third-party embeds - then you need neither a banner nor a CMP. This saves money (CMP tools cost EUR 50-500 per month), improves load times, and makes GDPR compliance trivial.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Sounds unrealistic? gosign.de itself is the proof: zero cookies, zero banners, Lighthouse 100/100, full analytics via cookieless tools. What is behind it and how it can work for your website too - we explain in detail:
</p>
<a
href="/en/knowledge/website-without-cookie-banner/"
class="inline-flex items-center gap-2 mt-4 text-gosign-accent-text font-semibold hover:text-gosign-accent transition-colors"
>
<span>Website without cookie banner - here is how</span>
<svg class="w-5 h-5" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M13.5 4.5 21 12m0 0-7.5 7.5M21 12H3" /></svg>
</a>
</div>
</div>
</section>

<!-- GDPR vs ePrivacy vs Digital Services -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">GDPR, ePrivacy Directive, Digital Services Act - which law governs what?</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
Three regulatory layers, three areas of responsibility. For website operators, it is important to understand the differences - because violations of each can be sanctioned separately.
</p>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse bg-white rounded-card">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Regulation</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Governs</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Website obligation</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">GDPR</td>
<td class="py-3 px-4 text-body text-gosign-text">Processing of personal data</td>
<td class="py-3 px-4 text-body text-gosign-text">Privacy policy, processing records, data subject rights</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">ePrivacy Directive</td>
<td class="py-3 px-4 text-body text-gosign-text">Access to end devices (cookies, fingerprinting)</td>
<td class="py-3 px-4 text-body text-gosign-text">Cookie consent before non-essential cookies</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Digital Services Act</td>
<td class="py-3 px-4 text-body text-gosign-text">Information obligations for digital services</td>
<td class="py-3 px-4 text-body text-gosign-text">Legal notice with full provider details</td>
</tr>
</tbody>
</table>
</div>
<p class="text-body text-gosign-text leading-relaxed mt-6">
The GDPR is an EU regulation and applies directly. The ePrivacy Directive is transposed into national law in each member state (as TDDDG in Germany, PECR in the UK) and specifically regulates access to end devices. The Digital Services Act (DSA) updates platform and information obligations. All three apply in parallel - and all three must be satisfied.
</p>
</div>
</section>

<!-- Special case: charities -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Special case: charities and non-profit organisations</h2>
<p class="text-body text-gosign-text leading-relaxed">
A common misconception: charities, associations, and non-profit organisations are exempt from the GDPR. This is not true. The GDPR applies to every organisation that processes personal data - regardless of legal form or purpose.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
In practice, this means: the website of a community foundation, a charity, or a religious institution also needs a complete privacy policy, a compliant cookie banner, and a correct legal notice. The requirements are identical to those for commercial businesses.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
There are, however, some organisational simplifications: organisations with fewer than 250 employees are not required to maintain complete processing records in certain cases. The obligations towards website visitors remain unaffected regardless of organisation size.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Charities often have websites with contact forms, newsletter sign-ups, and donation forms - all areas where particularly sensitive data is processed. A sound privacy policy is not just an obligation here but also a matter of trust with donors and funders. The technical foundation of the website also matters - a solid understanding of <a href="/en/knowledge/schema-org-seo-basics/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">Schema.org and SEO basics</a> helps to set up the website professionally.
</p>
</div>
</section>

<!-- Checklist -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Checklist: 8 points every website must satisfy</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
Regardless of industry, size, or legal form - these eight points are the minimum for every website operating in the EU.
</p>
<div class="space-y-4">
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">1</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Privacy policy present and up to date</h3>
<p class="text-body text-gosign-text mt-1">Complete policy with all GDPR-mandated details. Review at least annually and update after legislative changes.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">2</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Legal notice (imprint) complete</h3>
<p class="text-body text-gosign-text mt-1">Name, address, email, phone, authorised representatives, registration number (if applicable), VAT ID. On a separate page, reachable within two clicks.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">3</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Cookie consent banner with genuine opt-in</h3>
<p class="text-body text-gosign-text mt-1">No pre-selected "Accept all". Equal options for consent and rejection. Non-essential cookies may only be set after consent.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">4</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">SSL/TLS encryption active</h3>
<p class="text-body text-gosign-text mt-1">The entire website must be reachable via HTTPS. Without encryption, form data is transmitted in plain text - a clear GDPR violation.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">5</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Contact forms with privacy notice</h3>
<p class="text-body text-gosign-text mt-1">Every form needs a note about data processing and a link to the privacy policy. For sensitive data (job applications, health), a separate consent is required.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">6</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Data processing agreements (DPAs) in place</h3>
<p class="text-body text-gosign-text mt-1">For every external service provider with access to personal data (host, email provider, analytics tools), a DPA must be in place. Without a DPA, the data processing is unlawful.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">7</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">No uncontrolled third-party integrations</h3>
<p class="text-body text-gosign-text mt-1">Host Google Fonts locally (not from Google servers). Embed YouTube videos only with a two-click solution. No external tracking pixels without consent. Every third-party connection must be documented in the privacy policy.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">8</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Accessible access to legal information</h3>
<p class="text-body text-gosign-text mt-1">Privacy policy and legal notice must be accessible to everyone - including people with disabilities. Since June 2025, the <a href="/en/knowledge/accessibility-bfsg-2025/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">European Accessibility Act</a> requires digital accessibility for many websites.</p>
</div>
</div>
</div>
</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Get your website privacy checked - 30&nbsp;minutes, free of charge.</h3>
<p class="text-body text-gosign-text mb-6">We review your website for GDPR compliance and show you where action is needed.</p>
<a
href="/en/contact/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Request a privacy check
</a>
<p class="text-small text-gosign-text-light mt-4">25 years of experience - 800+ projects - Hamburg-based data protection practice</p>
</div>
</section>

<!-- What happens with violations -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">What happens if you violate the GDPR?</h2>
<p class="text-body text-gosign-text leading-relaxed">
The consequences of a GDPR violation are real and can be existential. The GDPR provides for fines of up to EUR 20 million or 4 percent of global annual turnover - whichever is higher. In practice, most fines for website violations range from EUR 5,000 to EUR 50,000, but the trend is upward.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
In addition to fines, there are two other risks that occur more frequently in practice:
</p>
<div class="grid md:grid-cols-2 gap-6 mt-6">
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Cease-and-desist letters</h3>
<p class="text-body text-gosign-text">
Since the CJEU ruling on Google Fonts (2022), the number of cease-and-desist letters has increased significantly. Specialist lawyers and consumer protection organisations systematically review websites for GDPR violations. Cost per letter: EUR 500 to EUR 5,000 - plus your own legal costs.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Supervisory authority proceedings</h3>
<p class="text-body text-gosign-text">
Data protection supervisory authorities are increasingly proactive. A complaint to the authority is free for any visitor and triggers a formal review. This ties up internal resources and can lead to orders that must be implemented within tight deadlines.
</p>
</div>
</div>
<p class="text-body text-gosign-text leading-relaxed mt-6">
The most important point: most website violations are easily avoidable. An up-to-date privacy policy, a functioning cookie banner, and a correct legal notice cost a fraction of what a cease-and-desist letter or fine costs. Prevention is not a question of budget but of priority.
</p>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
Gosign is a Hamburg-based digital agency with 25 years of experience in web development, TYPO3, and AI integration.
We review websites for GDPR compliance, implement privacy-compliant solutions, and support
companies, foundations, and public-sector organisations in meeting all legal requirements.
</p>
<p class="text-small text-gosign-text-light mt-2">Last updated: March 2026</p>
</div>
</section>

<!-- Related topics -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Related topics</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/en/knowledge/accessibility-bfsg-2025/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Law</p>
<p class="text-body font-semibold text-gosign-dark">Accessibility & EAA 2025</p>
</a>
<a href="/en/knowledge/website-without-cookie-banner/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Privacy</p>
<p class="text-body font-semibold text-gosign-dark">Website Without Cookie Banner</p>
</a>
<a href="/en/knowledge/typo3-updates-security/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">TYPO3</p>
<p class="text-body font-semibold text-gosign-dark">TYPO3 Updates & Security</p>
</a>
</div>
</div>
</section>

--- Schema.org & SEO Basics Explained ---
> What is structured data? How do Schema.org, meta tags, and Open Graph improve your Google visibility? SEO fundamentals explained simply.

<!-- What is structured data? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">What is "structured data"?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Imagine handing someone your business card. It shows your name, phone number, and address. The recipient immediately understands who you are and how to reach you. That is exactly what structured data does for search engines.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Schema.org is a standardised language that Google, Bing, and other search engines understand. It tells them: "This is a company, this is the address, these are the opening hours, and this is the product price." Without these annotations, Google has to guess - and guessing often leads to incorrect or incomplete search results.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
The principle: you add invisible supplementary information to your existing HTML code. Visitors see no difference, but search engines read a clearly structured "business card" for your organisation.
</p>
</div>
</section>

<!-- Before/After -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Before and after: how Schema.org transforms your search result</h2>
<p class="text-body text-gosign-text leading-relaxed mb-8">
The difference is immediately visible. Here is a comparison of how your business can appear in Google search results:
</p>
<div class="grid md:grid-cols-2 gap-6">
<div class="bg-white border border-gosign-border rounded-card p-6">
<p class="text-small font-semibold text-red-600 uppercase tracking-wider mb-4">Without Schema.org</p>
<div class="border border-gosign-border rounded-card p-4 bg-gosign-light">
<p class="text-body text-blue-700 font-semibold">Sample Company Ltd - Home</p>
<p class="text-small text-green-700 mb-1">www.samplecompany.com</p>
<p class="text-small text-gosign-text-light">Welcome to Sample Company. We offer services in the area of...</p>
</div>
<p class="text-small text-gosign-text-light mt-3">Just a blue link with generic text. No address, no ratings, no additional info. The searcher has no reason to click specifically here.</p>
</div>
<div class="bg-white border border-gosign-border rounded-card p-6">
<p class="text-small font-semibold text-green-700 uppercase tracking-wider mb-4">With Schema.org</p>
<div class="border border-gosign-border rounded-card p-4 bg-gosign-light">
<p class="text-body text-blue-700 font-semibold">Sample Company Ltd - IT Services London</p>
<p class="text-small text-green-700 mb-1">www.samplecompany.com</p>
<p class="text-small text-amber-700 mb-1">&#9733;&#9733;&#9733;&#9733;&#9733; 4.8 (127 reviews)</p>
<p class="text-small text-gosign-text-light mb-1">123 High Street, London EC2 - Tel. 020 1234 5678</p>
<p class="text-small text-gosign-text-light">IT services for mid-market. Servers, cloud, support.</p>
</div>
<p class="text-small text-gosign-text-light mt-3">Rich snippet with rating stars, address, and phone number. Takes up more space, appears more trustworthy - and gets clicked more often.</p>
</div>
</div>
<p class="text-body text-gosign-text leading-relaxed mt-6">
Studies show: rich snippets with ratings and additional information achieve up to 30% higher click-through rates than plain blue links. And that is without any advertising budget - purely through correctly implemented data.
</p>
</div>
</section>

<!-- The most important schema types -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">The three most important schema types for businesses</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Organization</h3>
<p class="text-body text-gosign-text">
Core data about your business: name, logo, address, founding year, social media profiles. Google uses this data for the Knowledge Panel - the info box on the right side of search results.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">LocalBusiness</h3>
<p class="text-body text-gosign-text">
Extends Organization with location-specific data: opening hours, price range, reviews, coordinates. Particularly important for businesses with a local catchment area - the foundation for Google Maps listings.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">BreadcrumbList</h3>
<p class="text-body text-gosign-text">
Shows Google the navigation structure of your website. Instead of "www.example.com/products/category/article", Google displays: "Home > Products > Category" - clear and clickable.
</p>
</div>
</div>
</div>
</section>

<!-- Meta description -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Meta description: 160 characters that decide the click</h2>
<p class="text-body text-gosign-text leading-relaxed">
The meta description is the short text that appears in Google search results below your page title. It is not a direct ranking factor, but it determines whether someone clicks on your result - or on the competition's.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
A good meta description answers the searcher's question in a maximum of 155-160 characters. It contains the main keyword, a clear benefit, and ideally a call to action. If the meta description is missing, Google picks a text excerpt itself - often not the best one.
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8 mb-4">Canonical tags and hreflang: clear signals for search engines</h3>
<p class="text-body text-gosign-text leading-relaxed">
If your website exists in multiple languages or similar content is reachable under different URLs, search engines need unambiguous signals. Two important tags serve this purpose:
</p>
<ul class="mt-4 space-y-3">
<li class="text-body text-gosign-text leading-relaxed">
<strong class="text-gosign-dark">Canonical tag:</strong> Tells Google which URL is the "original version" of a page. Prevents identical content under different addresses from being counted as duplicates. Example: whether someone visits example.com/page or example.com/page/ - the canonical tag points to a single URL.
</li>
<li class="text-body text-gosign-text leading-relaxed">
<strong class="text-gosign-dark">Hreflang:</strong> Tells search engines which language versions of a page exist. This way, Google shows German users the German version and English users the English version - rather than a random one. Particularly relevant for <a href="/en/knowledge/gdpr-obligations-websites/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">GDPR-compliant multilingual websites</a>.
</li>
</ul>
</div>
</section>

<!-- Open Graph -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Open Graph tags: how your links look great on WhatsApp and LinkedIn</h2>
<p class="text-body text-gosign-text leading-relaxed">
Have you noticed this? You share a link on WhatsApp or LinkedIn and only a bare URL appears - no image, no title, no description. That happens when Open Graph tags are missing.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Open Graph (OG) tags are meta elements in the HTML code that tell social networks how a shared link should be displayed. The four most important:
</p>
<ul class="mt-4 space-y-2">
<li class="text-body text-gosign-text"><strong class="text-gosign-dark">og:title</strong> - The title that appears in the preview</li>
<li class="text-body text-gosign-text"><strong class="text-gosign-dark">og:description</strong> - The description below the title</li>
<li class="text-body text-gosign-text"><strong class="text-gosign-dark">og:image</strong> - The preview image (ideal: 1200 x 630 pixels)</li>
<li class="text-body text-gosign-text"><strong class="text-gosign-dark">og:url</strong> - The canonical URL of the page</li>
</ul>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Without OG tags, each platform decides what to display. With OG tags, you control the image your business presents - on LinkedIn, WhatsApp, Facebook, Twitter, and everywhere links are shared.
</p>
</div>
</section>

<!-- SEO checklist -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Checklist: 6 SEO fundamentals for every business website</h2>
<p class="text-body text-gosign-text leading-relaxed mb-8">
These six points form the technical foundation for good Google visibility. Check whether your website meets them:
</p>
<div class="space-y-4">
<div class="bg-white border border-gosign-border rounded-card p-5">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent text-white rounded-full flex items-center justify-center font-bold text-small">1</span>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-1">Implement Schema.org markup</h3>
<p class="text-body text-gosign-text">Check whether your website has at least Organization or LocalBusiness schema. Test: enter your URL in the Rich Results Test (search.google.com/test/rich-results).</p>
</div>
</div>
</div>
<div class="bg-white border border-gosign-border rounded-card p-5">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent text-white rounded-full flex items-center justify-center font-bold text-small">2</span>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-1">Meta descriptions for all key pages</h3>
<p class="text-body text-gosign-text">Check whether every page has its own meta description - not empty, not duplicated, maximum 155-160 characters. Each description should summarise the page's benefit in one sentence.</p>
</div>
</div>
</div>
<div class="bg-white border border-gosign-border rounded-card p-5">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent text-white rounded-full flex items-center justify-center font-bold text-small">3</span>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-1">Set canonical tags</h3>
<p class="text-body text-gosign-text">Check whether every page has a canonical tag. Especially important for online shops, filter pages, or websites with www and non-www variants.</p>
</div>
</div>
</div>
<div class="bg-white border border-gosign-border rounded-card p-5">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent text-white rounded-full flex items-center justify-center font-bold text-small">4</span>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-1">Set up Open Graph tags</h3>
<p class="text-body text-gosign-text">Check whether your pages have og:title, og:description, and og:image. Test: share a link from your website in a WhatsApp group - does an attractive preview appear?</p>
</div>
</div>
</div>
<div class="bg-white border border-gosign-border rounded-card p-5">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent text-white rounded-full flex items-center justify-center font-bold text-small">5</span>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-1">Optimise HTTPS and load time</h3>
<p class="text-body text-gosign-text">Check whether your website is reachable via HTTPS and loads in under 3 seconds. Both are direct Google ranking factors. A <a href="/en/website-security-standards/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">secure website meeting industry standards</a> fulfils this requirement.</p>
</div>
</div>
</div>
<div class="bg-white border border-gosign-border rounded-card p-5">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent text-white rounded-full flex items-center justify-center font-bold text-small">6</span>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-1">Ensure accessibility</h3>
<p class="text-body text-gosign-text">Check whether your website is <a href="/en/knowledge/accessibility-bfsg-2025/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">accessible under the EAA 2025</a>. Alt text on images, clean heading hierarchy, and keyboard operability improve not only accessibility but also discoverability on Google.</p>
</div>
</div>
</div>
</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Get your website's SEO potential checked - 30&nbsp;minutes, free of charge.</h3>
<p class="text-body text-gosign-text mb-6">We analyse your website for the most important SEO fundamentals and show concrete improvements.</p>
<a
href="/en/contact/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Request an SEO check
</a>
<p class="text-small text-gosign-text-light mt-4">25 years of experience - 800+ projects - AI-accelerated analysis</p>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
Gosign is a Hamburg-based digital agency with 25 years of experience in web development, TYPO3, and AI integration.
We support business websites from technical SEO optimisation to accessibility.
Our clients include mid-market companies, universities, and public-sector organisations across Europe.
</p>
<p class="text-small text-gosign-text-light mt-2">Last updated: March 2026</p>
</div>
</section>

<!-- Related topics -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Related topics</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/en/knowledge/gdpr-obligations-websites/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Law</p>
<p class="text-body font-semibold text-gosign-dark">GDPR Obligations for Websites</p>
</a>
<a href="/en/knowledge/accessibility-bfsg-2025/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Law</p>
<p class="text-body font-semibold text-gosign-dark">Accessibility & EAA 2025</p>
</a>
<a href="/en/knowledge/typo3-updates-security/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">TYPO3</p>
<p class="text-body font-semibold text-gosign-dark">TYPO3 Updates & Security</p>
</a>
</div>
</div>
</section>

--- TYPO3 Updates: Why They Matter ---
> Why TYPO3 updates are important, which versions still have support, and what an upgrade to v13 brings. Clearly explained.

<!-- What does LTS mean? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">What does "LTS" mean - and why is it important for you?</h2>
<p class="text-body text-gosign-text leading-relaxed">
LTS stands for <strong>Long Term Support</strong>. It means the vendor provides security updates for this version over an extended period. When a security vulnerability is discovered, it is patched - but only for versions that are still supported.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Think of it like a car: as long as your model is still in production, you get spare parts and recall notices. Once the model is discontinued, you are on your own. With TYPO3 it is exactly the same: without support, there are no security patches - and known vulnerabilities remain open.
</p>
</div>
</section>

<!-- Version table -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Which TYPO3 versions are still supported?</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
TYPO3 regularly releases new versions. Older versions eventually stop receiving security patches. The following table shows the current status:
</p>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse bg-white rounded-card">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Version</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Support until</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Status</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">TYPO3 v13 LTS</td>
<td class="py-3 px-4 text-body text-gosign-text">December 2027</td>
<td class="py-3 px-4">
<span class="inline-flex items-center px-3 py-1 rounded-full text-small font-semibold bg-green-100 text-green-800">Current - recommended</span>
</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">TYPO3 v12 LTS</td>
<td class="py-3 px-4 text-body text-gosign-text">October 2025 (Extended until March 2028)</td>
<td class="py-3 px-4">
<span class="inline-flex items-center px-3 py-1 rounded-full text-small font-semibold bg-yellow-100 text-yellow-800">Support ending</span>
</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">TYPO3 v11 and older</td>
<td class="py-3 px-4 text-body text-gosign-text">Already expired</td>
<td class="py-3 px-4">
<span class="inline-flex items-center px-3 py-1 rounded-full text-small font-semibold bg-red-100 text-red-800">No support - security risk</span>
</td>
</tr>
</tbody>
</table>
</div>
<p class="text-body text-gosign-text leading-relaxed mt-6">
<strong>Conclusion:</strong> If your website runs on TYPO3 v11 or older, you receive <strong>no more security patches</strong>. Known vulnerabilities are no longer closed. An upgrade is strongly recommended.
</p>
</div>
</section>

<!-- What happens with an outdated version? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">What happens if you use an outdated version?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Security vulnerabilities are discovered regularly - this is normal and affects all software. What matters is whether the vendor patches them. For versions without support, this no longer happens. The vulnerabilities still become publicly known - and that is exactly what attackers exploit.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Specifically, this means: your website can be abused for phishing redirects, spam distribution, or data theft - often without you noticing immediately. The consequences range from reputational damage and GDPR violations to blacklisting by search engines. More on data protection obligations in our article on <a href="/en/knowledge/gdpr-obligations-websites/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">GDPR obligations for websites</a>.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
With the <a href="/en/typo3-security-monitor/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">Gosign TYPO3 Security Monitor</a>, we check your installation for known vulnerabilities - regardless of the version.
</p>
</div>
</section>

<!-- What does v13.4 bring? -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">What does TYPO3 v13.4 actually bring?</h2>
<p class="text-body text-gosign-text leading-relaxed mb-8">
An update is not just a mandatory security measure. TYPO3 v13.4 brings real improvements that you will notice in daily use:
</p>
<div class="grid md:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Faster load times</h3>
<p class="text-body text-gosign-text">
Automatic image compression with WebP and AVIF. Your images become smaller, pages load faster - without you having to change anything.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Modernised backend</h3>
<p class="text-body text-gosign-text">
The interface where you manage content has been redesigned. Clearer structure, better overview, simpler operation - even for occasional users.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Up-to-date security</h3>
<p class="text-body text-gosign-text">
PHP 8.2+ support and regular security updates. Your website stays protected against current threats.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Content Blocks</h3>
<p class="text-body text-gosign-text">
New Content Blocks enable more flexible page design. Layouts and content elements can be combined more easily - less dependency on extensions.
</p>
</div>
</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Get your TYPO3 version checked - 30&nbsp;minutes, free of charge.</h3>
<p class="text-body text-gosign-text mb-6">We check your TYPO3 version, installed extensions, and open security vulnerabilities - no obligation.</p>
<a
href="/en/contact/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Request a TYPO3 check
</a>
<p class="text-small text-gosign-text-light mt-4">25 years of experience - 800+ extensions - AI-accelerated development</p>
</div>
</section>

<!-- Upgrade process -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">The upgrade process: what to expect</h2>
<p class="text-body text-gosign-text leading-relaxed">
A TYPO3 update does not have to be a major project. The typical process:
</p>
<ol class="mt-6 space-y-4">
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent text-white rounded-full flex items-center justify-center text-small font-bold">1</span>
<div>
<p class="text-body font-semibold text-gosign-dark">Analysis</p>
<p class="text-body text-gosign-text">Which version is currently running? Which extensions are installed? Are there custom modifications? Gosign creates an inventory.</p>
</div>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent text-white rounded-full flex items-center justify-center text-small font-bold">2</span>
<div>
<p class="text-body font-semibold text-gosign-dark">Staging update</p>
<p class="text-body text-gosign-text">The update is performed on a test environment. Your live website continues to run normally throughout.</p>
</div>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent text-white rounded-full flex items-center justify-center text-small font-bold">3</span>
<div>
<p class="text-body font-semibold text-gosign-dark">Test and approval</p>
<p class="text-body text-gosign-text">You review the staging version. Does everything work as expected? Only after your approval do we proceed.</p>
</div>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent text-white rounded-full flex items-center justify-center text-small font-bold">4</span>
<div>
<p class="text-body font-semibold text-gosign-dark">Go-live</p>
<p class="text-body text-gosign-text">The updated version goes live. Downtime is typically under 30 minutes.</p>
</div>
</li>
</ol>
<p class="text-body text-gosign-text leading-relaxed mt-6">
<strong>Time required:</strong> A minor update (e.g. 12.4 to 12.6) takes a few hours. A major upgrade (e.g. v10 to v13) can take several days depending on <a href="/en/typo3-extensions/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">extensions</a> and customisations.
</p>
</div>
</section>

<!-- Hosting and CMS maintenance -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Why hosting and CMS maintenance belong together</h2>
<p class="text-body text-gosign-text leading-relaxed">
TYPO3 updates do not just affect the software itself. New versions often require more recent PHP versions, adjusted database configurations, or updated server settings. When CMS maintenance and hosting are with different providers, coordination overhead arises - and in the worst case, a security gap because nobody feels responsible.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Gosign offers both from a single source: CMS maintenance including updates, extension monitoring, and hosting on European servers. This ensures that the server environment and CMS version always match.
</p>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
Gosign is a Hamburg-based digital agency with 25 years of experience in web development, TYPO3, and AI integration.
We have analysed over 800 TYPO3 extensions and today develop with AI assistance
up to 70% faster than with traditional methods. Our clients include mid-market
companies, universities, and public-sector organisations across Europe.
</p>
<p class="text-small text-gosign-text-light mt-2">Last updated: March 2026</p>
</div>
</section>

<!-- Related topics -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Related topics</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/en/typo3-extensions/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">TYPO3</p>
<p class="text-body font-semibold text-gosign-dark">TYPO3 Extensions: Development & Monitoring</p>
</a>
<a href="/en/typo3-security-monitor/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Security</p>
<p class="text-body font-semibold text-gosign-dark">TYPO3 Security Monitor</p>
</a>
<a href="/en/website-security-standards/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Security</p>
<p class="text-body font-semibold text-gosign-dark">Website Security Standards</p>
</a>
</div>
</div>
</section>

--- Website Without Cookie Banner ---
> Websites without cookie banners are legal, faster, and GDPR-compliant. Here is how to eliminate cookies and save CMP costs.

<!-- The problem: cookie banners annoy everyone -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">The problem: cookie banners annoy everyone</h2>
<p class="text-body text-gosign-text leading-relaxed">
Around 80 percent of website visitors click "Reject all" or close the cookie banner immediately. The result: the first thing a potential customer sees on your website is a barrier. No content, no product, no message - just a popup asking for consent.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Cookie banners are not just annoying, they also cost money. Consent Management Platforms (CMPs) like Cookiebot, Usercentrics, or OneTrust charge EUR 50 to EUR 500 per month depending on page views. On top of that: the CMP JavaScript slows page loading, worsens Core Web Vitals, and can <a href="/en/knowledge/schema-org-seo-basics/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">negatively affect SEO rankings</a>.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Yet most websites need a cookie banner - because they set cookies. Google Analytics, Facebook Pixel, embedded YouTube videos, Google Fonts loaded from external servers: all of these set cookies or transfer personal data. And the <a href="/en/knowledge/gdpr-obligations-websites/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">ePrivacy Directive requires</a> that consent is obtained before non-essential cookies are set.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
But what if a website sets no cookies at all?
</p>
</div>
</section>

<!-- The alternative: set no cookies at all -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">The alternative: set no cookies at all</h2>
<p class="text-body text-gosign-text leading-relaxed">
If a website sets no non-essential cookies, it does not need a cookie banner. This is not a trick and not a grey area - it is simple logic. The ePrivacy Directive requires consent only before setting cookies. No cookies, no consent needed, no banner required.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Technically, this is entirely feasible. It requires deliberate decisions in the website architecture:
</p>
<div class="grid md:grid-cols-2 gap-6 mt-6">
<div class="border border-gosign-border rounded-card p-6 bg-white">
<div class="flex items-start gap-3">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor">
<path stroke-linecap="round" stroke-linejoin="round" d="M3.75 13.5l10.5-11.25L12 10.5h8.25L9.75 21.75 12 13.5H3.75z" />
</svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Self-hosted fonts</h3>
<p class="text-body text-gosign-text">
Host Google Fonts locally instead of loading them from Google servers. No connection to Google, no IP transfer, no cookie requirement.
</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-white">
<div class="flex items-start gap-3">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor">
<path stroke-linecap="round" stroke-linejoin="round" d="M3 13.125C3 12.504 3.504 12 4.125 12h2.25c.621 0 1.125.504 1.125 1.125v6.75C7.5 20.496 6.996 21 6.375 21h-2.25A1.125 1.125 0 013 19.875v-6.75zM9.75 8.625c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125v11.25c0 .621-.504 1.125-1.125 1.125h-2.25a1.125 1.125 0 01-1.125-1.125V8.625zM16.5 4.125c0-.621.504-1.125 1.125-1.125h2.25C20.496 3 21 3.504 21 4.125v15.75c0 .621-.504 1.125-1.125 1.125h-2.25a1.125 1.125 0 01-1.125-1.125V4.125z" />
</svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Cookieless analytics</h3>
<p class="text-body text-gosign-text">
Cloudflare Web Analytics instead of Google Analytics. No cookies, no IP storage, yet page views, referrers, and top pages are still available.
</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-white">
<div class="flex items-start gap-3">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor">
<path stroke-linecap="round" stroke-linejoin="round" d="M18.364 18.364A9 9 0 005.636 5.636m12.728 12.728A9 9 0 015.636 5.636m12.728 12.728L5.636 5.636" />
</svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">No third-party embeds</h3>
<p class="text-body text-gosign-text">
No YouTube, no Google Maps, no social media buttons that set cookies. If needed: privacy-compliant alternatives or two-click solutions.
</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-white">
<div class="flex items-start gap-3">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor">
<path stroke-linecap="round" stroke-linejoin="round" d="M5.25 14.25h13.5m-13.5 0a3 3 0 01-3-3m3 3a3 3 0 100 6h13.5a3 3 0 100-6m-16.5-3a3 3 0 013-3h13.5a3 3 0 013 3m-19.5 0a4.5 4.5 0 01.9-2.7L5.737 5.1a3.375 3.375 0 012.7-1.35h7.126c1.062 0 2.062.5 2.7 1.35l2.587 3.45a4.5 4.5 0 01.9 2.7m0 0a3 3 0 01-3 3m0 3h.008v.008h-.008V17.25zm-3 0h.008v.008h-.008V17.25z" />
</svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">SSG + CDN edge delivery</h3>
<p class="text-body text-gosign-text">
Static site generation instead of dynamic CMS delivery. No server-side session cookies, no dynamic tracking headers.
</p>
</div>
</div>
</div>
</div>
</div>
</section>

<!-- What you gain -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">What you gain</h2>
<div class="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-3 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">No cookie banner</h3>
<p class="text-body text-gosign-text">Clean first impression. No popup, no "Accept" dialogue. Visitors see your content immediately.</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Better performance</h3>
<p class="text-body text-gosign-text">No CMP JavaScript, no consent check before every script. Less code, faster load times.</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Full GDPR compliance</h3>
<p class="text-body text-gosign-text">Not "compliant enough" but: there is nothing to regulate. No cookies, no consent needed.</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">No CMP costs</h3>
<p class="text-body text-gosign-text">No Cookiebot, Usercentrics, or OneTrust. That saves EUR 600 to EUR 6,000 per year.</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Better SEO</h3>
<p class="text-body text-gosign-text">Google Core Web Vitals benefit directly from the absence of consent scripts. Faster pages rank higher.</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Future-proof</h3>
<p class="text-body text-gosign-text">Cookie regulation is getting stricter. If you do not need cookies, you are simply not affected.</p>
</div>
</div>
</div>
</section>

<!-- "But I need analytics!" -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">"But I need analytics!"</h2>
<p class="text-body text-gosign-text leading-relaxed">
This is the most common objection. And it is valid - but solvable. Analytics without cookies is already a reality. The question is not whether but how.
</p>
<div class="space-y-6 mt-6">
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Cloudflare Web Analytics</h3>
<p class="text-body text-gosign-text leading-relaxed">
Cookieless, privacy-compliant, and free. Provides page views, top pages, referrers, countries, and device types. No IP storage, no consent required, no CMP integration needed.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Server-side analytics</h3>
<p class="text-body text-gosign-text leading-relaxed">
Log file analysis directly on the server. No cookies, no external data transfer. Tools like GoAccess or AWStats evaluate server logs and provide visitor numbers without ever touching the visitor's browser.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Conversion tracking without cookies</h3>
<p class="text-body text-gosign-text leading-relaxed">
Server-side events instead of client-side pixels. When a visitor submits a contact form, the event is captured server-side - without a cookie, without a pixel, without a third party.
</p>
</div>
</div>
<p class="text-body text-gosign-text leading-relaxed mt-6">
The honest question is: do you really need 200 data points per visitor, or are page views, referrers, and conversion events enough? For most business websites, the answer is clear. Having fewer external dependencies also improves <a href="/en/website-security-standards/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">website security</a> - fewer third-party scripts mean a smaller attack surface.
</p>
</div>
</section>

<!-- Practical example: gosign.de -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Practical example: gosign.de</h2>
<p class="text-body text-gosign-text leading-relaxed">
This website sets no cookies. Zero cookie banners, zero external fonts, zero tracking pixels. Analytics runs via Cloudflare Web Analytics (cookieless, no IP storage). Fonts are self-hosted, there are no YouTube embeds, no Google Maps, no social media buttons. The result: Lighthouse 100/100 in all four categories (Performance, Accessibility, Best Practices, SEO), full GDPR compliance without ongoing CMP costs, and a privacy policy reduced to the essentials. The topic of <a href="/en/knowledge/accessibility-bfsg-2025/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">accessibility</a> also benefits directly from this architecture: without a CMP overlay, there is no barrier between the user and the content.
</p>
</div>
</section>

<!-- Checklist -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Checklist: how to make your website cookie-free</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
Five steps, in this order. Only when the first four points are complete may the banner be removed.
</p>
<div class="space-y-4">
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">1</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Remove or self-host external fonts</h3>
<p class="text-body text-gosign-text mt-1">Loading Google Fonts from Google servers is the most common reason for unwanted data transfers. Download fonts, host them on your own server, done. The CJEU ruling of 2022 confirmed: remote loading of Google Fonts without consent is unlawful.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">2</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Replace Google Analytics with a cookieless alternative</h3>
<p class="text-body text-gosign-text mt-1">Cloudflare Web Analytics, Plausible, or Fathom deliver the data relevant for business websites - without cookies and without consent requirements. Migration typically takes less than one hour.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">3</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Replace or secure third-party embeds</h3>
<p class="text-body text-gosign-text mt-1">YouTube videos, Google Maps, and social media buttons set cookies as soon as they load. Two options: remove entirely or replace with two-click solutions that load only after approval.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">4</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Remove or convert marketing pixels to server-side</h3>
<p class="text-body text-gosign-text mt-1">Facebook Pixel, LinkedIn Insight Tag, Google Ads Conversion - all of these set cookies. Either remove entirely or switch to server-side tracking that works without cookies on the end device.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">5</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Remove the cookie banner</h3>
<p class="text-body text-gosign-text mt-1">Only now. Once no non-essential cookies are set, the CMP can be uninstalled and the banner removed. The privacy policy remains mandatory but will be significantly shorter.</p>
</div>
</div>
</div>
</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Request a cookie-free website - 30&nbsp;minutes, free of charge.</h3>
<p class="text-body text-gosign-text mb-6">We review your website and show you which cookies you can eliminate - and which you never needed.</p>
<a
href="/en/contact/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Request a cookie-free website
</a>
<p class="text-small text-gosign-text-light mt-4">25 years of experience - 800+ projects - Hamburg-based data protection practice</p>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
Gosign is a Hamburg-based digital agency with 25 years of experience in web development, TYPO3, and AI integration.
We build websites without cookies, without external dependencies, and with full GDPR compliance -
without compromises on analytics, performance, or functionality.
</p>
<p class="text-small text-gosign-text-light mt-2">Last updated: March 2026</p>
</div>
</section>

<!-- Related topics -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Related topics</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/en/knowledge/gdpr-obligations-websites/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Law</p>
<p class="text-body font-semibold text-gosign-dark">GDPR Obligations for Websites</p>
</a>
<a href="/en/knowledge/schema-org-seo-basics/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">SEO</p>
<p class="text-body font-semibold text-gosign-dark">Schema.org & SEO Basics</p>
</a>
<a href="/en/website-security-standards/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Security</p>
<p class="text-body font-semibold text-gosign-dark">Website Security Standards</p>
</a>
</div>
</div>
</section>

--- Why HR Departments Need to Build Agent Governance Now ---
> Agent governance is not an IT topic. It's an HR leadership topic. What CHROs need to know before AI agents enter core HR processes.

## The Reality in Most HR Departments

In most companies, the following is happening simultaneously: IT is testing AI tools, individual teams are experimenting with ChatGPT, and somewhere a PoC for document processing is running. What none of these initiatives has clarified: Who defines the rules under which AI agents may operate in HR processes?

This is not an IT problem. This is an HR leadership problem.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">At a Glance - Agent Governance for HR</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Agent governance defines which decisions agents may make, how actions are documented, and how rules are versioned.</li>
<li>HR must lead governance - not IT - because escalation thresholds, bias definitions and rule ownership require domain expertise.</li>
<li>ISACA (2024) reports that 73% of organizations lack a formal AI governance framework, leaving critical HR processes uncontrolled.</li>
<li>The EU AI Act classifies AI systems that influence employment decisions as high-risk, mandating human oversight and bias monitoring.</li>
<li>Start now: inventory existing AI usage, assign governance ownership in HR, involve the works council before the first agent goes live.</li>
</ul>
</div>

## Agent Governance Is Not a Technical Gimmick

Agent governance defines three things. First, which decisions an agent may make and which remain with humans. Second, how every agent action is documented - for internal audit, works council (Betriebsrat) and external review. Third, how rules are versioned, tested and updated.

For HR processes, this means concretely: When a Document Agent processes a sick leave certificate, it must be traceable which rules were applied, which decision was made, and why. Not because engineers want it that way, but because the next payroll tax audit will ask.

## Why Now - Not in Two Years

Three developments make this urgent.

The EU AI Act is in force. AI systems that influence decisions about employees fall under elevated requirements: risk classification, bias monitoring, human oversight, transparency. Building this into the architecture from the start is far cheaper than retrofitting later.

Works councils (Betriebsräte) are demanding co-determination (Mitbestimmung). And rightly so. AI agents in HR processes are subject to co-determination requirements. The earlier you involve the works council, the faster you can scale. Bypassing the works council blocks your own progress.

Shadow IT is growing exponentially. Every week, more employees use AI tools without IT or HR knowledge. Without a governance framework, you have no control over where data flows.

## What an Agent Governance Framework for HR Must Contain

A robust framework needs five elements:

| Element | Purpose | Owner |
|---------|---------|-------|
| Decision matrix | Defines what the agent may decide and what stays with humans | HR + Legal |
| Audit Trail | Every action logged, versioned, reproducible | IT (technical), HR (review) |
| Role concept | Who monitors, who approves, who escalates | HR |
| Works council templates | Ready documentation for the works agreement | HR + Works council |
| Escalation path | What happens when the agent is uncertain or confidence is low | HR (thresholds), IT (routing) |

## Human-in-the-Loop Is an Architectural Principle

[Human-in-the-loop](/en/governance/) does not mean a human approves every single action. It means the architecture is built so that critical decisions always land with a human. The agent prepares, the human decides. This is not an add-on, it is the foundation.

For HR this means: An agent can read a sick leave certificate, calculate deadlines and make a recommendation. The decision - book it, escalate, request clarification - is made by the human. With a complete chain of reasoning.

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Free eBook: AI in HR</p>
<p class="text-body text-gosign-text mb-4">EU AI Act checklist, Decision Framework, works council perspective, and readiness assessment - the governance handbook for HR leaders.</p>
<a href="/en/ebook/ai-hr-governance-handbook/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Download for free</a>
</div>

## What CHROs Should Do Now

First: Take inventory. Where are AI tools already being used in HR today - officially and unofficially? Second: Clarify governance ownership. Agent governance does not belong in IT alone, it needs an HR owner. Third: Involve the works council before the first agent goes into production. Fourth: Start with a concrete process - not a strategy PowerPoint.

At Gosign, we build [AI agents for HR processes](/en/hr-ai-agents/) with Governance by Design: Human-in-the-loop, complete audit trail, works council templates, EU AI Act readiness. From process to productive agent in 4 - 6 weeks.

--- Agent Orchestration Platforms Compared (2026) ---
> Where do your AI agents run? Trigger.dev, n8n, Camunda, Temporal, Make and Activepieces compared for enterprise use. With recommendation logic.

## You Know What Agents Are. Now: Where Do They Run?

You understand what [AI agents](/en/services/ai-agents/) are, how they communicate with your systems via MCP and A2A, and how the [Decision Layer](/en/magazine/decision-layer-shadow-ai/) controls which decisions they may make. The next question is concrete: on which platform do you orchestrate these agents? Where do you define the workflows that connect a language model with your business processes?

The answer depends on where your organization stands. Do you need fast results with visual workflow automation, or do you have complex, long-running business processes that require BPMN-compliant control and audit-ready documentation?

This article compares the six most relevant platforms, explains the fundamental architectural distinction between visual workflow tools and process orchestration engines, and provides a practical recommendation for getting started.

Gartner (2024) predicts that by 2028, 33% of enterprise software applications will include agentic AI, up from less than 1% in 2024. The orchestration platform you choose today determines whether your organization is ready for that shift.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">At a Glance - Agent Orchestration Platforms</p>
<ul class="text-body text-gosign-text space-y-2">
<li>The market splits into visual workflow tools (n8n, Make, Activepieces) for fast prototyping and process orchestration engines (Camunda, Temporal, Trigger.dev) for production-grade execution.</li>
<li>Trigger.dev is the recommended default: TypeScript-native, durable execution, Apache 2.0 license, self-hostable, productive in two weeks.</li>
<li>Camunda complements when formal BPMN diagrams are required for works councils or auditors.</li>
<li>Five of six platforms support self-hosting - Make (SaaS-only) is the exception.</li>
<li>Platform choice is an architecture decision affecting governance, compliance, and time-to-production.</li>
</ul>
</div>

## Two Worlds of Orchestration

The market for workflow orchestration in 2026 divides into two categories that solve different problems.

### Visual Workflow Automation

Platforms like n8n, Make, and Activepieces follow the visual workflow paradigm. Workflows are assembled by clicking nodes together in a canvas editor. A trigger, a new email, a new document, a webhook, starts a chain of actions, including calls to AI models. The advantage: fast results, low barrier to entry, usable even by non-developers. The disadvantage: when processes involve dozens of decision points, parallel paths, human approval loops spanning multiple days, or compliance requirements for versioning and audit, visual tools reach their limits.

Visual workflow tools are optimized for sequences: trigger, action, action, action, done. They handle simple branching well. What they handle less well is the concept of a process that waits, for days or weeks, at a defined point for a human to approve a step before continuing.

### Process Orchestration Engines

Platforms like Camunda and Temporal take a fundamentally different approach. Processes are defined as formal models, BPMN diagrams in Camunda's case, code in Temporal's. Every step is versioned and auditable. Human tasks, points in the process where a human must review, approve, or decide, are a core part of the architecture, not an afterthought.

The advantage: enterprise-grade compliance, native audit trail, processes that run for weeks or months with full traceability. The disadvantage: higher entry barrier, requires developer expertise, and more upfront design effort.

The distinction is not about quality. It is about fit. A visual tool that produces results in two days is superior to a BPMN engine that produces results in two months, if the use case does not require audit-grade compliance. Conversely, a BPMN engine that provides full traceability is non-negotiable when the works council (Betriebsrat), auditors, or regulators need to trace every decision.

## Platforms Compared

The following table provides a structured comparison of the six most relevant orchestration platforms for AI agent workflows in 2026.

| Property | n8n | Camunda | Make | Temporal | Activepieces |
|---|---|---|---|---|---|
| **Type** | Visual Workflow | BPMN Process Engine | Visual Workflow | Code-first Orchestration | Visual Workflow |
| **Self-Hosted** | Yes (Docker, k8s) | Yes (Self-Managed) or Cloud | No (SaaS only) | Yes (Docker, k8s) | Yes (Docker) |
| **AI/LLM Integration** | Native AI nodes (Ollama, LangChain) | Connectors for LLM APIs, custom workers | AI modules | Any LLM in worker code | AI pieces |
| **Key Strength** | 400+ integrations, visual editor, fast prototypes | BPMN 2.0, human tasks, audit trail, long-running processes | Simplest entry, intuitive visual builder | Durable execution, retry/timeout native, maximum reliability | Open-source alternative to n8n/Make |
| **Enterprise Fit** | Medium--High | Very High | Low--Medium | High | Medium |
| **License** | Fair Source (free <3 instances) | Community (Apache 2.0) + Enterprise | Proprietary (SaaS) | MIT (Core) + Commercial (Cloud) | MIT |
| **Trigger.dev** | Code-first (TypeScript) | Yes (Docker, k8s) | Any LLM in task code | TypeScript-native, durable execution, retry native, developer-first | High | Apache 2.0 |

Each platform has a distinct profile. The choice is not about finding the "best" platform but about matching the platform to your requirements.

## When to Use Which Platform?

### n8n: When You Need Fast Results

You need a functioning agent in two weeks that extracts invoices from an email inbox, classifies them via a language model, and books them into your ERP system? n8n is your choice.

The visual editor enables building workflows without traditional programming. AI nodes are natively integrated. You can embed a language model into the workflow like any other service. Self-hosting with Docker means your data does not leave your network. The community is active, and with over 400 integrations, connections to most enterprise systems are available out of the box.

**The trade-off:** n8n workflows excel at sequential automations and simple branching. For processes with parallel paths, human approval loops spanning multiple days, or compliance requirements for versioning and formal audit, n8n reaches its limits. It was designed as a workflow automation tool, not as a process engine. For many AI agent use cases, particularly those in the proof-of-concept phase, that distinction does not matter. For production processes with regulatory requirements, it does.

**Best for:** Rapid prototyping, internal automations, PoC agents, teams that want visible results quickly.

### Camunda: When Compliance Is Non-Negotiable

Your works council (Betriebsrat) wants to trace which agent made which decision? Your auditors need a complete audit trail? The process runs for weeks, onboarding, contract approval, regulatory submissions? Then you need a BPMN engine.

Camunda models processes as formal BPMN 2.0 diagrams that any business stakeholder can read, including the works council. Human tasks are a core concept: at defined points, the process waits for human approval. Every decision is versioned and traceable. AI agents are integrated as service tasks. The language model becomes a step in the business process, not a black box.

The BPMN standard is an international norm (ISO 19510). Diagrams are portable, readable by external auditors, and serve as documentation that satisfies both technical and organizational requirements. When a company agreement (Betriebsvereinbarung) defines that certain agent decisions require human oversight, Camunda enforces this architecturally.

**Best for:** Compliance-critical processes, long-running workflows, regulated industries, organizations with works council requirements.

### Temporal: When Your Developers Need Maximum Control

Temporal is code-first. Workflows are written in Go, Java, TypeScript, or Python. No visual editor, but maximum control over retry logic, timeouts, and error handling. For AI agents that execute complex, multi-step tasks with unpredictable runtimes, document analysis with follow-up queries, multi-system orchestration with conditional branching, Temporal is the most robust choice.

Temporal's concept of durable execution means that a workflow survives infrastructure failures. If a server goes down mid-process, Temporal resumes exactly where it stopped, without data loss, without duplicate actions. For AI agent workflows where a single execution may involve multiple LLM calls, each with variable latency, this reliability is architecturally significant.

**The trade-off:** Temporal requires developers. There is no visual designer, no drag-and-drop interface. Non-technical stakeholders cannot read or modify workflows directly. For organizations with strong engineering teams, this is acceptable. For organizations that need business users to participate in workflow design, it is not.

**Best for:** Engineering-led organizations, complex multi-step agent workflows, scenarios requiring maximum reliability and fine-grained error handling.

### Trigger.dev: The Rising Standard for Agent Orchestration

Trigger.dev has established itself in 2025/2026 as one of the fastest-growing orchestration platforms. The reason: workflows are written in TypeScript - the language that already dominates the majority of modern web development. No visual editor, no additional language. If you already have TypeScript in your stack, you orchestrate agents in the same language, the same IDE, the same CI/CD system.

The platform is used by a growing number of organizations - from AI startups to SaaS companies to enterprise teams running production agent workflows. The active open-source community on GitHub, regular releases, and a developer experience aligned with modern standards make Trigger.dev the natural choice for teams already working in TypeScript.

Durable execution is built in: every task survives server failures, network issues, and model timeouts. Retry logic, timeouts, and error handling are defined in code, not configured in a UI. The full execution history is inspectable, every step is traceable. This makes Trigger.dev suitable not just for prototypes, but for production workflows - from email classification to document processing to multi-step agent chains.

Self-hosting with Docker or Kubernetes is fully supported. The Apache 2.0 license ensures no usage limits. No Java dependencies (like Temporal), no BPMN overhead (like Camunda), no visual editor that slows down at complexity (like n8n).

**The trade-off:** Trigger.dev requires TypeScript developers. Business users cannot modify workflows in an editor. For Go or Java teams, Temporal is the better choice. When formal BPMN diagrams are required by works councils or auditors, Camunda complements the architecture.

## Practical Recommendation: Trigger.dev as Standard, Camunda for BPMN Requirements

Trigger.dev is suitable as the primary orchestration platform - from the first agent to production operations. TypeScript-based workflows integrate directly into existing development processes: versioned in Git, testable in CI, deployable with the same tools as the rest of your stack. A working agent in two weeks convinces the board more than an architecture concept in two months.

Trigger.dev scales beyond the first use case. Durable execution, complete execution histories, and an Apache 2.0 license without instance limits make the platform suitable for production enterprise workflows. Many organizations run their entire agent orchestration on Trigger.dev - from email classification to document processing to multi-step agent chains with dozens of tasks.

Camunda comes into play when formal BPMN diagrams are required - typically for processes that need to be read by works councils, auditors, or external compliance reviewers. Not because Trigger.dev is not production-ready, but because BPMN is a communication format that non-developers understand.

The key distinction: compliance capability is not a question of the platform, but of the implementation. Audit trails, [Decision Layer](/en/magazine/decision-layer-shadow-ai/), Human-in-the-Loop, and full traceability can be built directly into Trigger.dev workflows - as versioned, testable TypeScript code. Gosign implements this governance layer by default in every agent solution: every decision is logged, every human approval documented, every process step is traceable in the audit trail. The only reason for Camunda is not technical compliance - Trigger.dev delivers that - but organizational readability: a works council or auditor can read a BPMN diagram, but not TypeScript code. When your engineering team or a specialized partner like Gosign builds the compliance layer in code, Trigger.dev covers all requirements.

Both can coexist: Trigger.dev as the standard for all types of agent workflows - email classification, data extraction, multi-step agent chains, internal automations. Camunda for BPMN-modeled core processes where formal diagrams are a compliance requirement: onboarding, contract approval, procurement authorization. The separation follows the question: Does this process need to exist as a formal BPMN diagram? If yes, add Camunda. If no, Trigger.dev.

For organizations that need an open-source alternative without licensing concerns, Activepieces (MIT license) offers a viable starting point for visual workflows. For engineering teams that want full code-level control, Temporal fills the gap between visual tools and BPMN engines.

## Integration with the Agent Architecture

The orchestration platform is the execution layer in the [agent architecture](/en/magazine/ai-agents-enterprise-guide/). It connects the components that together form a functioning AI agent system:

```
┌─────────────────────────────────────────────┐
│         Enterprise AI Portal                │
│  (LobeChat / OpenWebUI / LibreChat /        │
│   chatbot-ui / very-ai)                     │
└──────────────────┬──────────────────────────┘
│
┌──────────────────▼──────────────────────────┐
│       Orchestration Platform                │
│    (Trigger.dev / Camunda / Temporal)         │
│                                             │
│  ┌─────┐  ┌─────────┐  ┌────────────┐      │
│  │Step │→ │  LLM    │→ │ Decision   │→ ... │
│  │  1  │  │ Analysis│  │   Layer    │      │
│  └─────┘  └─────────┘  └────────────┘      │
└──────────────────┬──────────────────────────┘
│
┌──────────────┼──────────────┐
▼              ▼              ▼
┌────────┐  ┌──────────┐  ┌──────────┐
│  RAG / │  │  ERP /   │  │ Email /  │
│ Vector │  │  CRM     │  │ Calendar │
│   DB   │  │          │  │          │
└────────┘  └──────────┘  └──────────┘
```

The [Enterprise AI Portal](/en/magazine/enterprise-ai-chat-interface/) is the interface through which users start agents. The connection is particularly seamless when the portal includes native workflow integration. very-ai (→ [Article 3](/en/magazine/enterprise-ai-chat-interface/)) can trigger Trigger.dev workflows directly from the chat - the user types a request, the agent analyzes, and Trigger.dev executes the follow-up process. With other portals, this connection needs to be established via webhooks or API middleware. The **orchestration platform** defines the workflow: which steps, in which order, under which conditions. The **AI model** performs the analysis: understanding text, extracting documents, preparing decisions. The **[Decision Layer](/en/magazine/decision-layer-shadow-ai/)** controls which decisions are made automatically and which require human approval. **RAG** provides the model with context from your enterprise documents.

The orchestration platform sits at the center. It is the layer that turns an AI model from a question-answering tool into a process-executing agent. Without it, the agent has no structure. With it, the agent has a defined workflow, error handling, escalation paths, and a traceable execution history.

Choosing the right orchestration platform is not a technology decision alone. It is an architecture decision that affects governance, compliance, and the speed at which you can move from pilot to production. Get this layer right, and every subsequent agent builds on a solid foundation. Get it wrong, and you will rebuild when the first compliance audit arrives.

Gosign uses Trigger.dev as its primary orchestration platform and builds [AI agent infrastructure](/en/services/ai-agents/) with the architecture that matches your requirements - from Trigger.dev-based agent workflows to fully audited Camunda BPMN processes. The [infrastructure](/en/services/infrastructure/) is designed so that the first agent is simultaneously the foundation for every agent that follows.

---

**📘 Enterprise AI Infrastructure Blueprint 2026 - Article Series**

| ← Previous | Overview | Next → |
|:---|:---:|---:|
| [Works Council & AI Literacy: The Organizational Questions](/en/magazine/works-council-ai-literacy/) | [Overview](/en/magazine/ai-infrastructure-blueprint-2026/) | - |

*All articles in this series: [Enterprise AI Infrastructure Blueprint 2026](/en/magazine/ai-infrastructure-blueprint-2026/)*

---

Which process should your first agent handle? → <a href="/en/contact/" target="_blank" rel="noopener noreferrer">Book a consultation</a>

--- From Chatbots to AI Agents: MCP, A2A and Multi-Agent Systems ---
> What sets AI agents apart from chatbots. MCP and A2A protocols, agent architecture, multi-agent orchestration for enterprises.

## A Chatbot Answers. An Agent Acts.

This distinction determines the value of AI in enterprises in 2026. A chatbot answers questions, "How many vacation days do I have left?" An agent executes processes. The difference is not incremental; it is fundamental.

A concrete example: An employee reports in sick. The HR agent receives the sick leave notification, checks the form for completeness, reconciles the absence period with the shift schedule, notifies the team lead, adjusts capacity planning, and documents the entire process in the personnel file. Four systems, one agent, zero manual inputs. Every step traceable, every step in the audit trail.

This is not a future scenario. This is the state of the art in 2026. And it is the reason why AI agent architecture is a strategic decision, not a task for the IT department alone.

This article describes the agent architecture for enterprise environments, explains the new MCP and A2A standards, presents five concrete business use cases with measurable savings potential, and defines the governance requirements without which no agent should go into production.

Gartner (2024) predicts that by 2028, 33% of enterprise software applications will include agentic AI, up from less than 1% in 2024. The architecture you choose today determines whether those agents deliver value or create risk.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">At a Glance - AI Agents for Enterprise</p>
<ul class="text-body text-gosign-text space-y-2">
<li>AI agents execute processes, not just answer questions. The difference between chatbot and agent is architectural, not incremental.</li>
<li>The enterprise agent architecture has five layers: user interface, orchestration, AI model, tool integration (MCP), and governance.</li>
<li>MCP standardizes tool access (agent-to-system), A2A standardizes agent communication (agent-to-agent). Both reduce integration effort by an order of magnitude.</li>
<li>Four governance requirements are non-negotiable before production: Decision Layer, Human-in-the-Loop, Audit Trail, and Rollback.</li>
<li>Start with one agent for one process. The infrastructure built for the first agent is the platform for every subsequent one.</li>
</ul>
</div>

## The Agent Architecture: Five Layers

An AI agent is not a monolithic system. The enterprise architecture consists of five layers, each with a clearly defined responsibility:

```
┌─────────────────────────────────────────┐
│           User Interface                │
│     (very-ai / Teams / Custom)          │
├─────────────────────────────────────────┤
│        Orchestration Layer              │
│    (Routing, Rule Engine, Escalation)   │
├─────────────────────────────────────────┤
│          AI Model Layer                 │
│  (Claude / GPT / Llama / gpt-oss - per task)    │
├─────────────────────────────────────────┤
│       Tool Integration (MCP)            │
│  (ERP, CRM, DMS, Email, Calendar...)    │
├─────────────────────────────────────────┤
│      Governance & Audit Layer           │
│  (Logging, Policies, Human-in-the-Loop) │
└─────────────────────────────────────────┘
```

**User Interface.** The layer through which employees interact with the agent. This can be a dedicated AI portal (as described in [Enterprise AI Portal: Four Open-Source Interfaces Compared](/en/magazine/enterprise-ai-chat-interface/)), an integration into Microsoft Teams, or a custom interface for specific departments.

**Orchestration Layer.** This is where decisions are made about which agent handles a task, which model is used, and when to escalate. The orchestration layer knows the rule sets, the responsibilities, and the escalation paths. It is the control center.

**AI Model Layer.** The language model that performs the actual processing: understanding text, recognizing patterns, generating responses. In a model-agnostic architecture, this layer is interchangeable. A cost-efficient model for standard requests, a more powerful one for complex analyses. Routing happens automatically.

**Tool Integration (MCP).** The connection to your existing systems: ERP, CRM, document management, email, calendar, ticketing. Through the Model Context Protocol (MCP), agents access these systems in a standardized way.

**Governance & Audit Layer.** Every agent action is logged. Policies define what an agent may and may not do. Human-in-the-loop is enforced where required. This layer is not optional. It is the prerequisite for production deployment. The [Decision Layer](/en/decision-layer/) forms the architectural foundation of this governance.

## MCP and A2A: the New Standards

Two protocols have changed the way AI agents communicate with the outside world and with each other in 2025/2026: MCP (Model Context Protocol) and A2A (Agent-to-Agent).

### MCP: The USB Port for AI

MCP is an open standard that enables AI models to access external data sources and tools. The analogy is apt: just as USB created a universal interface for hardware, MCP creates a universal interface for AI integrations.

Before MCP, every combination of AI model and target system required a custom connector. Agent A accesses the ERP system, one connector. Agent B accesses the DMS, another connector. Agent C accesses the calendar, yet another connector. With ten systems and three models, that amounts to thirty individual integrations.

With MCP, each system defines its capabilities once in a standardized format: What data can it provide? What actions can it execute? What parameters are required? Any MCP-compatible model can use these capabilities without system-specific code.

For enterprises, this means: New systems can be connected faster. Models can be swapped without rebuilding integrations. Dependency on individual model providers decreases.

### A2A: Agents Talking to Each Other

A2A (Agent-to-Agent) is the counterpart to MCP for communication between agents. While MCP governs the connection between agent and system, A2A governs the connection between agent and agent.

Why does this matter? Because complex business processes are rarely covered by a single agent. A sick leave notification affects HR, capacity planning, payroll, and potentially project management. Each area has a specialized agent. A2A enables these agents to delegate tasks and exchange results, with defined permissions.

Critically: A2A does not mean shared data access. The HR agent passes the Finance agent the information "Employee X is absent from date Y", not the complete personnel file. Each agent sees only what it needs for its task. Permission boundaries remain intact.

## Five Business Use Cases with Measurable Savings

The question decision makers ask is not "What can an agent do?" but "What does an agent deliver?" Here are five use cases with quantifiable savings potential:

| Area | Use Case | What the Agent Does | Savings Potential |
|---|---|---|---|
| HR | Onboarding | Create accounts, assign training, schedule introductions, send welcome email | 4--6 hours per hire |
| Finance | Invoice verification | Read invoice, verify against purchase order, check account assignment, trigger approval workflow | 70--80% reduction in processing time |
| Legal | Contract analysis | Extract clauses, compare against standard contracts, flag deviations | Hours instead of days |
| IT | Incident triage | Analyze error report, match against known issues, create prioritized ticket | Faster first response |
| Operations | Supplier monitoring | Track delivery dates, reconcile with production plan, proactive alert on delays | Early warning instead of rework |

Each of these use cases follows the same pattern: the agent handles the structured, rule-based part of a process. The human handles exceptions, judgment calls, and approvals. The time savings come not from eliminating human work, but from eliminating manual routine tasks.

**HR Onboarding in Detail.** Today, an HR administrator manually coordinates each new hire: create IT accounts, configure access rights, assign mandatory training, prepare an onboarding plan, draft a welcome email, set up payroll. Every step a separate system, every step a manual entry. An onboarding agent orchestrates these steps automatically: it reads the employment contract, identifies position, location, and department, and executes the steps in the respective systems. The HR administrator approves the overall process, not every individual step.

**Invoice Verification in Detail.** An incoming invoice is read by the Document Agent. The agent extracts vendor, amount, line items, and purchase order number. It verifies automatically: Does a matching purchase order exist? Do line items and amounts match? Is the account assignment correct? Is the amount within approval thresholds? On a positive outcome, the booking is prepared. On deviations, the case is escalated to the responsible clerk, with the specific reason for the deviation, not a generic "please review" message.

## Governance Requirements for Agents

An agent without governance is a liability. Four requirements must be met before production deployment:

**1. Decision Layer.** Every agent decision passes through the [Decision Layer](/en/decision-layer/). For each micro-decision, it is defined: May the agent act autonomously, does a rule set apply, or must a human approve? These rules are versioned, traceable, and cannot be modified by the agent itself.

**2. Human-in-the-Loop.** For defined decision types, the architecture enforces human review. This is not a feature that can be activated. It is an architectural principle. The agent cannot bypass the human-in-the-loop requirement because it is technically enforced, not organizationally agreed upon.

**3. Audit Trail.** Every agent action generates an immutable log entry: What was the input? Which model was used? Which rule was applied? What was the outcome? When was the action executed? The audit trail is the foundation for financial audits, internal reviews, and works council (Betriebsrat) oversight.

**4. Rollback.** Every agent action must be reversible. If an agent generates an erroneous booking or sends an incorrect notification, the process must be correctable, technically, not just organizationally. Rollback capability is an architectural requirement, not an afterthought.

These four requirements are non-negotiable. Without them, no works council (Betriebsrat) will consent, no auditor will sign off, and no CIO will accept responsibility. More on governance architecture in the next article: [Decision Layer & Shadow AI](/en/magazine/decision-layer-shadow-ai/).

## Multi-Agent Systems: Specialization Over Universal Agents

The next level beyond the individual agent: multiple specialized agents working together. Not one universal agent that does everything, but specialists who each master a single domain.

The sick leave example as a multi-agent system:

```
Sick leave notification received
│
Document Agent  →  Reads and classifies the sick leave notification
│
HR Agent      →  Checks rules: sick pay, return-to-work programs, deadlines
│
Workflow Agent  →  Notifies team lead, adjusts shift schedule
│
Finance Agent   →  Updates payroll
```

Each agent has its own permissions. The Document Agent can read documents but cannot create bookings. The Finance Agent can adjust payroll but cannot access personnel files. Permission boundaries are architecturally enforced. Via the A2A protocol, agents communicate only the information the receiving agent needs for its task.

The Orchestrator Agent coordinates the overall flow. It knows which agent executes which step, in which sequence, and what happens when errors occur. The Orchestrator has oversight but no operational permissions. It delegates; it does not execute.

Multi-agent systems are powerful but complex. The number of interactions grows quadratically with the number of agents. Debugging becomes more involved. Governance requirements increase.

## Practical Recommendation: Start Small

The temptation to begin with a multi-agent system is understandable. The recommendation is clear: start with a single agent for a clearly defined process.

**Step 1:** Identify a process that is structured, rule-based, and frequent enough to justify the effort. Invoice verification, onboarding, contract analysis, pick one.

**Step 2:** Deploy a single [AI agent](/en/services/ai-agents/) for that process. With a Decision Layer, with human-in-the-loop, with an audit trail. Not as a prototype, but as a production system.

**Step 3:** Measure. Throughput time before and after. Error rate. Cost per transaction. Satisfaction of the processing staff.

**Step 4:** Only when the first agent runs stably, plan the second. And only when multiple agents run stably, consider multi-agent orchestration.

This approach is not conservative. It is pragmatic. A functioning agent with proven value delivers more than an ambitious multi-agent concept stuck in the pilot phase.

The [infrastructure](/en/services/infrastructure/), model hosting, vector databases, orchestration engine, API gateway, is built with the first agent and then available for every subsequent one. The investment in the first agent is simultaneously the investment in the platform.

A concrete example: In the enterprise AI portal [very-ai](/en/magazine/enterprise-ai-chat-interface/) users can trigger Trigger.dev workflows directly from the chat. The agent becomes the trigger for a process chain - not just a conversation partner. The orchestration platform (→ [Article 10](/en/magazine/agent-orchestration-platforms/)) handles execution.

Where these agents actually run, on which platform, is covered in [Article 10: Agent Orchestration](/en/magazine/agent-orchestration-platforms/).

---

**📘 Enterprise AI Infrastructure Blueprint 2026 - Article Series**

| ← Previous | Overview | Next → |
|:---|:---:|---:|
| [RAG & Document Intelligence: How AI Understands Your Documents](/en/magazine/rag-document-intelligence-enterprise/) | [Overview](/en/magazine/ai-infrastructure-blueprint-2026/) | [Decision Layer & Shadow AI: Control Instead of Chaos](/en/magazine/decision-layer-shadow-ai/) |

*All articles in this series: [Enterprise AI Infrastructure Blueprint 2026](/en/magazine/ai-infrastructure-blueprint-2026/)*

---

**Ready to deploy the first AI agent for a concrete business process?** Gosign partners with enterprise clients from process analysis to production agent, model-agnostic, with a Decision Layer and a complete audit trail.

<a href="/en/contact/" target="_blank" rel="noopener noreferrer">Book a consultation</a>. 30 minutes to identify the right first use case for your organization.

--- What AI Really Costs: TCO Comparison for Enterprises ---
> Token prices are misleading. The four cost categories of enterprise AI - with three scenarios from €26K to €410K.

## Token Prices Are Not Your AI Costs

When organizations discuss AI costs, the conversation almost always begins with token prices. That is understandable: providers market their models with input and output prices per million tokens, and these numbers are easy to compare. A flagship model costs $5 per million input tokens, a budget model $0.25. The difference appears dramatic.

Yet token prices account for only 20 to 35 percent of actual costs in practice. Anyone who reduces their AI budget planning to token prices underestimates the total costs by a factor of three to five. The real question is not: "What does a token cost?" The question is: "What does it cost to operate AI productively, securely, and compliantly in my organization?"

This article presents the four cost categories that every enterprise AI deployment encompasses, compares three scenarios from 26,000 to 410,000 euros in the first year, and explains how model switching can reduce token costs by 40 to 60 percent.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">At a Glance - True Costs of Enterprise AI</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Token prices represent only 20 - 35% of actual costs. Infrastructure, governance and personnel make up the remaining 65 - 80%.</li>
<li>Three scenarios: entry at ~26,000 EUR (1 chatbot, 50 users), standard at ~148,000 EUR (3 agents, hybrid), enterprise at ~410,000 EUR (10+ agents, dedicated GPUs).</li>
<li>According to Deloitte (2024), enterprises that plan AI budgets based on token prices alone underestimate total deployment costs by 3x to 5x on average.</li>
<li>Model Switching reduces token costs by 40 - 60% by routing simple requests to budget models and complex tasks to flagship models.</li>
<li>Infrastructure costs are front-loaded (months 1 - 6); from year two, model and personnel costs dominate the TCO mix.</li>
</ul>
</div>

## The Four Cost Categories

Every enterprise AI deployment distributes across four cost categories. The relative weighting varies by scenario, but the structure remains the same.

### 1. Model Costs: Tokens and Hosting (20--35%)

The most visible category: API fees for cloud models or hosting costs for self-hosted models. With cloud APIs, you pay per token, input and output separately. With self-hosting, you pay GPU rental, electricity, and maintenance. Costs depend directly on usage volume: a chatbot with 50 users generates different token volumes than ten specialized agents with 1,000 users.

What is frequently overlooked: self-hosting is cheaper than cloud APIs above a certain volume, but the entry costs are higher. A single GPU with 80 GB VRAM costs approximately 1,200 euros per month from a European hosting provider, regardless of whether it is fully utilized or not. For details on the hosting decision, see [AI Hosting Strategies for Enterprise](/en/magazine/ai-hosting-strategies-enterprise/).

### 2. Infrastructure and Integration (25--35%)

The largest and most frequently underestimated category. It encompasses everything required to integrate a language model into your existing IT landscape:

- **API gateway and routing layer:** A central component that routes requests to the appropriate model, enforces rate limits, and tracks costs.
- **RAG pipeline:** If your AI is to access internal knowledge, you need a Retrieval-Augmented Generation pipeline: vector database, embedding model, chunking strategy, indexing.
- **System integration:** Integration with existing systems, ERP, CRM, document management, ticketing. Each interface requires development effort.
- **Enterprise AI portal:** An interface through which employees actually use the AI, with SSO, permissions management, and audit trail.

These costs are largely one-time. They occur primarily in the first three to six months and amortize over the operating period. But they must be planned and budgeted. Otherwise hidden costs arise from workarounds and rework.

### 3. Governance and Compliance (15--20%)

Since the [EU AI Act](/en/magazine/eu-ai-act-2026-enterprises/), governance is no longer an optional luxury. The costs in this category include:

- **Risk classification:** Assessment of all AI systems according to EU AI Act categories. For high-risk systems, a formal conformity assessment is required.
- **Technical documentation:** The EU AI Act requires comprehensive documentation of data provenance, training procedures, performance metrics, and risk mitigation measures.
- **Audit trail and monitoring:** Ongoing logging of all AI decisions, particularly in automated decision-making processes.
- **Data protection:** GDPR-compliant data processing, data processing agreements, data protection impact assessments for processing personal data.
- **External advisory:** Legal counsel for regulatory questions, data protection officer, and where applicable a conformity assessment body.

The governance share increases with the complexity of the AI deployment. A single chatbot for general knowledge queries has lower governance requirements than an AI system that pre-screens job applications.

### 4. Personnel and Capability Building (20--30%)

AI systems must be operated, maintained, and further developed. Simultaneously, employees must be equipped to use the systems. This category includes:

- **ML Ops / AI engineering:** At minimum one person responsible for model management, prompt optimization, monitoring, and troubleshooting. In the enterprise scenario, a dedicated team.
- **AI literacy:** Training for all users, legally mandated since February 2025 under the EU AI Act. Includes initial training and regular refreshers.
- **Change management:** Supporting the organization through the transition. New processes, new roles, new responsibilities.

In smaller scenarios, capability building can happen internally, without additional personnel costs, but with opportunity costs. In larger scenarios, you need dedicated staff or external support.

### Cost Distribution at a Glance

```
Model Costs (Tokens/Hosting)          ████████░░░░░░░░░░░░  20 - 35%
Infrastructure & Integration          ██████████░░░░░░░░░░  25 - 35%
Governance & Compliance               ██████░░░░░░░░░░░░░░  15 - 20%
Personnel & Capability Building       ████████░░░░░░░░░░░░  20 - 30%
```

The distribution shifts over time: in the first year, infrastructure and integration dominate. From the second year onward, the relative shares of model costs and personnel increase as the one-time integration costs drop away.

## Three Scenarios Compared

The following three scenarios represent typical entry points. The figures are reference values based on project experience with organizations of varying sizes. Your actual costs depend on your existing [IT infrastructure](/en/services/infrastructure/), your integration requirements, and your chosen operating model.

| Scenario | Model Setup | Monthly Token/Hosting | Integration | Governance | Personnel | Total 12 Months |
|---|---|---|---|---|---|---|
| **Entry:** 1 chatbot, 50 users | Sonnet API | ~€500 | €15,000 | €5,000 | €0 (internal) | **~€26,000** |
| **Standard:** 3 agents, 200 users | Sonnet + Llama self-hosted | ~€4,000 | €60,000 | €20,000 | 1 ML Ops (partial) | **~€148,000** |
| **Enterprise:** 10+ agents, 1,000+ users | Multi-model, dedicated GPU | ~€12,000 | €150,000 | €50,000 | 2 FTE | **~€410,000** |

### Scenario 1: Entry (approx. €26,000 / 12 months)

A clearly defined use case: an internal knowledge chatbot for a single department, based on a cloud API. 50 users, moderate query volume, no system integration beyond document upload. Governance is limited to GDPR-compliant data processing and basic documentation. Personnel costs are zero because the internal IT team manages operations alongside their day-to-day responsibilities.

This scenario is the typical proof of concept. It demonstrates value, validates the technology, and delivers empirical data for scaling. A clean PoC with a clearly defined use case typically costs 15,000 to 30,000 euros and is achievable in four to six weeks.

### Scenario 2: Standard (approx. €148,000 / 12 months)

Three specialized agents for different processes, for example, document analysis, customer communication, and internal knowledge management. 200 users, hybrid hosting: non-sensitive requests via cloud API, sensitive data via a self-hosted model. Integration with at least one existing system. Governance includes EU AI Act risk classification and formal documentation. One ML Ops engineer handles model management and monitoring on a part-time basis.

This scenario represents the productive entry point. The organization has completed the PoC and is scaling across multiple departments. The infrastructure is designed for growth.

### Scenario 3: Enterprise (approx. €410,000 / 12 months)

Ten or more specialized agents across multiple business units. Over 1,000 users. Multi-model architecture with dedicated GPUs. Deep integration into ERP, CRM, HR systems, and document management. Enterprise-grade governance: formal conformity assessment for high-risk systems, audit trail, governance dashboard. Two full-time ML Ops engineers for operations and ongoing development.

This scenario assumes the organization has completed the experimentation phase and operates AI as strategic infrastructure. The 410,000 euros sounds like a significant investment, and it is. But it distributes across a system that accelerates hundreds of processes, reduces error rates, and improves the quality of decision-making.

### Context: What Do the Alternatives Cost?

The cost of an AI system should never be evaluated in isolation. The relevant comparison is: What do the processes cost without AI? If three clerks each spend two hours per day on document classification, that amounts to approximately 180,000 euros per year at fully loaded cost, for a task a trained agent handles in seconds. ROI is rarely the question. The question is how quickly it materializes.

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Free eBook: AI in Finance</p>
<p class="text-body text-gosign-text mb-4">Compliance, external auditors, and Decision Layer - the governance handbook for finance leaders.</p>
<a href="/en/ebook/ai-finance-governance-handbook/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Download for free</a>
</div>

## Cost Optimization Through Model Switching

The most effective lever for model costs is not choosing a cheaper model, but the differentiated use of multiple models. This principle is called model switching or model routing.

### The Principle

Not every request requires a flagship model. The majority of enterprise requests, standard responses, simple classification, data extraction from structured documents, can be answered at sufficient quality by budget models. Only for complex tasks, multi-step reasoning, contract analysis, decision preparation, is a flagship model necessary.

A routing logic automatically determines which model handles a request. The criteria are configurable:

- **Complexity:** Simple requests to budget models, complex ones to flagship models.
- **Data sensitivity:** Requests containing personal data to self-hosted models, non-sensitive requests to cloud APIs.
- **Latency requirements:** Real-time applications to fast, small models. Batch processing to powerful models without time pressure.
- **Cost limits:** Automatic throttling when a team or department budget is reached.

### Savings Potential

In practice, enterprise requests typically distribute as follows:

- **60--70% standard requests:** Simple classification, FAQ, data extraction. Budget models suffice.
- **20--30% medium complexity:** Summaries, structured analysis, drafts. Price-performance models.
- **5--15% high complexity:** Multi-step reasoning, contract analysis, strategic documents. Flagship models.

When 65 percent of requests use a budget model costing one-twentieth of a flagship model instead, token costs drop by 40 to 60 percent, with equivalent result quality for overall usage. Details on [model selection and the performance profiles of current models](/en/magazine/ai-models-comparison-2026/) can be found in the corresponding article in this series.

### Implementation

Model switching requires three components:

1. **Routing engine:** A central logic that analyzes incoming requests and forwards them to the appropriate model. This can be implemented rule-based (keyword detection, user role, data classification) or model-based (a small classification model evaluates complexity).
2. **Model registry:** A central directory of all available models with their performance profiles, costs, and availability.
3. **Cost monitoring:** A dashboard that makes token consumption transparent per model, per team, and per use case. Without transparency, there is no optimization.

The implementation effort for model switching is manageable, typically two to four weeks. The savings begin immediately.

## Budget Planning: Three Recommendations

**First: Plan with TCO, not with token prices.** When a provider presents token costs, at least 65 percent of the budget is missing. Demand a TCO calculation that covers all four categories.

**Second: Start with a PoC, but plan for scaling.** A PoC for 15,000 to 30,000 euros demonstrates value. But the PoC architecture must be built so that it scales without requiring a rebuild. Otherwise, you pay the integration costs twice.

**Third: Implement model switching from the start.** The routing layer has a low one-time cost and saves substantially over time. Anyone who routes differentially from the beginning avoids lock-in to a single model and retains cost control.

---

**📘 Enterprise AI Infrastructure Blueprint 2026 - Article Series**

| ← Previous | Overview | Next → |
|:---|:---:|---:|
| [Decision Layer & Shadow AI: Control Instead of Chaos](/en/magazine/decision-layer-shadow-ai/) | [Overview](/en/magazine/ai-infrastructure-blueprint-2026/) | [EU AI Act 2026: What Applies Now, What's Coming, What You Must Do](/en/magazine/eu-ai-act-2026-enterprises/) |

*All articles in this series: [Enterprise AI Infrastructure Blueprint 2026](/en/magazine/ai-infrastructure-blueprint-2026/)*

---

Gosign builds AI infrastructure with a transparent cost structure, from TCO analysis to production operations. If you want to know what AI costs in your specific setup, talk to us.

<a href="/en/contact/" target="_blank" rel="noopener noreferrer">Book a consultation</a>. 30 minutes to realistically calculate your costs.

--- AI Governance Dashboard: Agent Monitoring for Enterprises ---
> How an AI governance dashboard makes agent activities transparent for IT, works councils and internal audit. Audit trail, model monitoring.

## Why a Dashboard Is Not Enough - but Nothing Works Without One

AI governance is not a dashboard problem. Governance is an architectural principle. But without a presentation layer that makes agent activities transparent, governance remains abstract. Nobody in the organisation - not IT, not the works council (Betriebsrat), not internal audit - can assess what agents are actually doing.

An AI governance dashboard is the interface between the technical governance architecture and the people who bear responsibility. It makes visible what the [Decision Layer](/en/finance-ai-agents/) documents behind the scenes.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">At a Glance - AI Governance Dashboard</p>
<ul class="text-body text-gosign-text space-y-2">
<li>An AI governance dashboard is the presentation layer for Decision Layer data - not a standalone monitoring tool.</li>
<li>It shows agent activities, audit trails, model performance and rule versions in real time.</li>
<li>Three role-based views (IT, management, works council) are required for governance to function in practice.</li>
<li>Gartner (2024) predicts that by 2026, organizations using AI governance frameworks will experience 40% fewer AI-related compliance incidents.</li>
<li>Without a dashboard, nobody in the organization can verify what AI agents actually do.</li>
</ul>
</div>


## What an AI Governance Dashboard Must Show

### Agent Activities: Who Does What

Every agent generates a protocol entry for every action: timestamp, input, rule applied, output, status (automatically processed, submitted for approval, escalated). The dashboard aggregates these entries and makes them filterable by period, department, agent type and status.

This is not traditional IT monitoring. It is a decision protocol - built for people who need to understand what agents are doing within their area of responsibility.

### Audit Trail: Complete Traceability

For every individual agent decision, a complete data record exists: which document was presented? What data was extracted? Against which rule (in which version) was it checked? What recommendation did the agent make? Who approved or escalated?

The dashboard makes this [audit trail](/en/governance/) searchable and exportable - for internal audit, external auditors or regulatory review.

### Model Monitoring: Which LLM Delivers What

In a [model-agnostic architecture](/en/services/infrastructure/), multiple models run in parallel. The dashboard shows per model: response times, token consumption, costs, error rates. This enables informed decisions about model selection and routing - based on real operational data, not intuition.

### Rule Versions: What Changed

Agents operate on the basis of decision rules. When a rule changes - because a collective agreement is updated or a new works council agreement takes effect - it must be traceable: what was the old rule? What is the new one? From when does it apply? Who approved it?

The dashboard shows rule versions as a timeline. Every change is assigned to a responsible person and linked to the audit trail.

<table class="w-full text-left text-sm">
<thead><tr class="border-b border-gosign-border">
<th class="py-2 pr-4 font-semibold">Component</th>
<th class="py-2 pr-4 font-semibold">Purpose</th>
<th class="py-2 pr-4 font-semibold">Data Source</th>
</tr></thead>
<tbody>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Agent Activity Log</td><td class="py-2 pr-4">Track every agent action in real time</td><td class="py-2 pr-4">Decision Layer protocol entries</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Audit Trail Viewer</td><td class="py-2 pr-4">Searchable, exportable decision records</td><td class="py-2 pr-4">Decision Layer audit records</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Model Monitor</td><td class="py-2 pr-4">Compare LLM performance and cost</td><td class="py-2 pr-4">Inference metrics per model</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Rule Version Timeline</td><td class="py-2 pr-4">Track rule changes with accountability</td><td class="py-2 pr-4">Versioned rule repository</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Escalation Dashboard</td><td class="py-2 pr-4">Monitor Human-in-the-Loop rates</td><td class="py-2 pr-4">HITL escalation events</td></tr>
</tbody>
</table>

## Three Views for Three Audiences

A single dashboard, but different access levels depending on role.

The IT view shows technical performance: agent uptime, model latency, API error rates, resource utilisation. It serves operational management and capacity planning.

The management view shows business metrics: cases processed per day, automation rate, escalation rate, throughput times. It serves ROI evaluation and board reporting.

The works council view shows aggregated usage data: in which departments are agents deployed? How frequently are decisions automated versus submitted for human approval? Which rule changes were made? This view deliberately contains no personal data at the individual level - it creates transparency about AI usage as a whole.

This three-way split is not a nice-to-have. It is the prerequisite for AI governance working in practice. Without the IT view, no stable operations. Without the management view, no budget. Without the works council view, no [works council agreement](/en/governance/co-determination/).


## Governance Dashboard as Architecture Component

The dashboard is not a separate tool bolted onto the AI infrastructure after the fact. It is a presentation layer that operates directly on [Decision Layer](/en/finance-ai-agents/) data.

Every audit trail entry, every rule version, every model metric is generated automatically by the Decision Layer - as a by-product of normal operations, not as additional effort. The dashboard makes this data accessible, filterable and exportable.

This is [Governance by Design](/en/governance/): transparency arises not from retrospective reporting but as an integral part of the architecture.

At Gosign, we build [AI infrastructure](/en/services/infrastructure/) with an integrated governance layer. The dashboard is not an option - it is part of every agent infrastructure we deliver.

--- AI Hosting: EU SaaS, German Data Center, or Self-Hosted? ---
> Three hosting strategies for enterprise AI. Decision matrix by data sensitivity, cost, and control.

## "Where Does It Run?": The Decisive Question

Before you select a model, before you build agents, before you roll out an interface, there is one question: where do your AI models run? This decision determines the data protection guarantees you can offer, the regulatory requirements you can meet, how high your ongoing costs are, and how dependent you become on third-party providers.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">At a Glance - AI Hosting Strategy for Enterprise</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Three tiers: EU SaaS (cloud APIs), European IaaS (self-hosted GPU), and on-premises (own hardware) - plus the hybrid combination.</li>
<li>The hybrid architecture routes requests by data sensitivity: 60-70% cloud, 25-35% European IaaS, 5-10% on-premises.</li>
<li>Gartner (2025) estimates that 40% of large enterprises will operate hybrid AI hosting architectures by 2027, up from under 10% in 2024.</li>
<li>Self-hosted open-source models (gpt-oss-120b) run on a single GPU for approximately EUR 1,200 per month at European providers.</li>
<li>Total costs with hybrid strategy are 30-40% below a pure cloud-API approach while delivering higher data sovereignty.</li>
</ul>
</div>

There are three fundamental strategies, and a fourth that has become the standard in practice: the hybrid architecture that combines all three.

## Tier 1: EU SaaS, Cloud APIs with EU Data Residency

The simplest and fastest option: you use the model providers' APIs directly. Claude via the Anthropic API (EU region), GPT-5.5 via Azure OpenAI (EU data center), Gemini via Google Cloud Platform (EU region). Data leaves your network but is processed in EU data centers.

### Advantages

**Fastest start:** No infrastructure to build, no GPU servers to provision, no ML-Ops expertise required. Set up an API key, sign a data processing agreement, go live in hours.

**Automatic updates:** Model updates, security patches, and performance improvements are rolled out by the provider. No maintenance effort on your side.

**Scalability:** No capacity management. During load spikes, the cloud provider scales automatically. No over-provisioning, no under-capacity.

**Model variety:** Access to all model variants from the provider, flagship, balanced, and budget, through the same API.

### Risks and Limitations

**Data leaves the corporate network.** Even with EU data residency, your requests are processed on infrastructure you do not control. The provider has technical access to data during processing.

**CLOUD Act.** US-based providers, including Anthropic, OpenAI, and Google, are subject to the US CLOUD Act. Under certain conditions, US authorities can request access to data even when it is stored in EU data centers. For most corporate data, this risk is assessable and acceptable. For trade secrets, classified data, or critical infrastructure information, it is not.

**Vendor dependency.** With a single-provider strategy, you are dependent on one provider's pricing, API changes, and availability. A model-agnostic architecture (see [AI Models Comparison 2026](/en/magazine/ai-models-comparison-2026/)) reduces this risk.

**DPA required.** GDPR-compliant use requires a data processing agreement (DPA) with the provider. All three major providers offer standard DPAs. Review them with your legal department. Note: Standard SaaS DPAs do not cover AI-specific topics such as prompt logging, environment separation, and model provider chains. Our [DPA requirements checklist for AI infrastructure](/en/magazine/dpa-ai-infrastructure-checklist/) identifies the ten gaps and provides 25 verification questions.

### Suited For

- Standard tasks with non-sensitive data: summaries, translations, general question answering
- Proof of concepts and pilot projects
- Tasks with variable volume where dedicated GPU infrastructure would be uneconomical
- Organizations without ML-Ops expertise that want to go live quickly

## Tier 2: European IaaS, GPU Hosting at European Providers

The middle ground: you rent GPU servers from a European Infrastructure-as-a-Service provider, such as Hetzner, IONOS, or a specialized GPU cloud provider. On these servers, you operate open-source models like gpt-oss, Llama 4, or Mistral Medium 3.1 yourself.

### Specific Hardware Requirements and Costs

| Model | GPU Requirement | Estimated Cost/Month |
|---|---|---|
| gpt-oss-120b | 1x A100/H100 (80 GB) | approx. EUR 1,200 |
| gpt-oss-20b | CPU/16 GB RAM (or small GPU) | approx. EUR 200--400 |
| Llama 4 Scout | 1x A100 (80 GB) | approx. EUR 1,200 |
| Llama 4 Maverick | 4x A100 (80 GB) | approx. EUR 3,500 |
| Mistral Medium 3.1 | 4x A100 (80 GB) | approx. EUR 3,500 |

### Advantages

**Data stays in Europe.** The server sits in a European data center, operated by a European provider. No CLOUD Act, no transatlantic data transfer. For GDPR compliance, this is the most secure cloud option.

**No vendor lock-in.** You operate open-source models under Apache 2.0 or the Meta Llama License. If you want to switch hosting providers, you migrate the model. No license questions, no contract negotiations.

**Full model control.** You decide which model in which version runs. You can fine-tune, quantize, or replace models with newer versions without waiting for the provider.

**Predictable costs.** GPU servers have fixed monthly costs. No variable token charges, no surprises during load spikes. For organizations with high, constant volume, this is often more economical than cloud APIs.

### Requirements

**ML-Ops competency.** You need someone to deploy, monitor, update, and troubleshoot the model. This can be an internal ML engineer or an external service provider, but it is not zero effort.

**Capacity planning.** A GPU server has a defined capacity. If you have 500 concurrent requests, a single GPU will not suffice. You must understand load profiles and plan capacity accordingly.

**No automatic updates.** When a new model is released, you deploy it yourself. When a security issue arises, you patch it yourself.

### Suited For

- Confidential corporate data (sensitivity level 2--3)
- Organizations that must eliminate CLOUD Act risks
- Use cases with constant, high volume (cost advantage over cloud APIs)
- Organizations with existing DevOps/ML-Ops competency

## Tier 3: On-Premises, AI on Your Own Hardware

The maximum-control option: you operate GPU servers in your own data center or in a colocation rack. No data leaves your network, under any circumstances.

### Advantages

**Maximum data sovereignty.** No external access, no external provider, no external dependency. The hardware is yours, the model is yours, the data never leaves your network.

**Regulatory certainty.** For critical infrastructure operators, government agencies, defense, and organizations with classified data, on-premises is often the only option that meets compliance requirements.

**No recurring license or API costs.** After the initial investment, only electricity, cooling, and maintenance remain. Over long-term operation at high volume, on-premises can be the most economical option.

### Challenges

**High initial investment.** A production GPU server with an NVIDIA H100 (80 GB) costs EUR 25,000--40,000. For more capable setups (multi-GPU, redundancy), costs range from EUR 60,000 to EUR 120,000 or more.

**ML-Ops team required.** On-premises means you are responsible for everything: hardware maintenance, model deployment, monitoring, updates, security. This requires a dedicated team or an experienced service provider.

**Scaling is not trivial.** When demand increases, you cannot add another GPU at the push of a button. Hardware procurement takes weeks to months.

### Suited For

- Critical infrastructure operators and government agencies
- Classified data and highest confidentiality levels
- Organizations with their own data center and ML-Ops competency
- Long-term investment willingness at very high volume

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Free eBook: AI Infrastructure</p>
<p class="text-body text-gosign-text mb-4">Build, Buy, Hybrid - EU AI Act (UK: UK AI regulatory framework)-compliant infrastructure with B/B/H Framework and 7-Layer Reference Architecture.</p>
<a href="/en/ebook/ai-infrastructure-governance-handbook/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Download for free</a>
</div>

## The Decision Tree

The following decision logic helps with the assignment:

```
Does your data contain PII or trade secrets?
├── NO → EU SaaS (Tier 1)
└── YES → Critical infrastructure or classified data?
├── YES → On-Premises (Tier 3)
└── NO → European IaaS (Tier 2) or Hybrid
```

In practice, the answer is rarely a single tier. Most organizations have data of varying sensitivity and therefore need an architecture that covers all tiers.

## Hybrid as the Standard: The Routing Architecture

The hybrid strategy combines all three tiers in a single architecture. A routing layer automatically decides which request goes through which channel, based on data sensitivity, not on individual employee decisions.

### How the Routing Works

**Data sensitivity level 1--2 (public, internal):** Requests go through cloud APIs. Fast, affordable, scalable. Example: summarizing a public whitepaper, translating a press release, drafting a general email.

**Data sensitivity level 3 (confidential):** Requests are routed to self-hosted models in the European data center. No data egress, no CLOUD Act. Example: analyzing internal contracts, processing HR data, evaluating confidential financial data.

**Data sensitivity level 4 (strictly confidential / regulated):** Requests run exclusively on on-premises infrastructure. Example: classified documents, critical infrastructure systems, data under special confidentiality obligations.

### Prerequisite: Data Classification

For routing to work, the organization must classify its data. This sounds onerous but is already in place at many organizations, for example, as part of existing Information Security Management Systems (ISMS) or national security classification frameworks. The routing rules map this existing classification to the AI infrastructure.

### Technical Implementation

The routing layer sits between the [Enterprise AI Portal](/en/magazine/enterprise-ai-chat-interface/) (the interface employees use) and the model endpoints. It consists of three components:

1. **Classifier:** Automatically detects the data sensitivity of a request, based on keywords, source system, or explicit user marking.
2. **Routing Engine:** Assigns the request to the appropriate model endpoint: cloud API, European IaaS, or on-premises.
3. **Audit Log:** Records every routing decision: which request, which sensitivity level, which endpoint. Traceable and exportable.

### Cost Effect

The hybrid architecture optimizes not only data security but also costs. Cloud APIs are inexpensive per request but variable. Self-hosted models have fixed costs that amortize at high volume. The combination leverages both: affordable cloud APIs for the bulk of non-sensitive requests, fixed-cost self-hosted models for confidential volume.

In practice, we see the following distribution at organizations with 1,000+ employees: 60--70% of requests go through cloud APIs (tier 1--2), 25--35% through European IaaS (tier 3), and 5--10% through on-premises (tier 4). Total costs are 30--40% below a pure cloud-API strategy while delivering higher data sovereignty.

## Summary: The Three Tiers at a Glance

| Criterion | EU SaaS (Tier 1) | European IaaS (Tier 2) | On-Premises (Tier 3) |
|---|---|---|---|
| Data Sovereignty | EU region, DPA | Europe, no CLOUD Act | Maximum |
| Initial Cost | None | Low (rental) | High (EUR 60--120K+) |
| Ongoing Cost | Variable (token) | Fixed (GPU rental) | Fixed (power, maintenance) |
| ML-Ops Effort | None | Medium | High |
| Scalability | Automatic | Manual | Manual, slow |
| Suited For | Level 1--2 data | Level 2--3 data | Level 3--4 data |

The right strategy is almost always a combination. Gosign implements the routing layer that connects all three tiers, so your employees use a single interface and the system automatically selects the right path.

Further reading: [AI Infrastructure](/en/services/infrastructure/) | [Decision Layer & Shadow AI](/en/magazine/decision-layer-shadow-ai/)

---

**📘 Enterprise AI Infrastructure Blueprint 2026 - Article Series**

| ← Previous | Overview | Next → |
|:---|:---:|---:|
| [AI Models 2026: Which Model for Which Use Case?](/en/magazine/ai-models-comparison-2026/) | [Overview](/en/magazine/ai-infrastructure-blueprint-2026/) | [Enterprise AI Portal: Four Open-Source Interfaces Compared](/en/magazine/enterprise-ai-chat-interface/) |

*All articles in this series: [Enterprise AI Infrastructure Blueprint 2026](/en/magazine/ai-infrastructure-blueprint-2026/)*

---

**Want to know which hosting strategy is right for your data landscape?** Gosign analyzes your data classification and designs the appropriate hybrid architecture.

<a href="/en/contact/" target="_blank" rel="noopener noreferrer">Book a consultation</a>. We clarify in 30 minutes which hosting tiers you need.

--- Enterprise AI Infrastructure Blueprint 2026 ---
> Eight strategic decisions for your AI infrastructure. Models, hosting, interfaces, agents, orchestration, governance, costs, and regulation.

## Why This Blueprint

Deploying AI in enterprise operations has moved from innovation project to operational necessity. In 2026, organizations without a concrete plan are not merely falling behind competitors. They are falling out of the market. At the same time, the decision landscape has grown more complex: more models, more hosting options, more regulation, more vendors, and an entirely new class of AI agents that act autonomously within your business processes.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">At a Glance - Enterprise AI Infrastructure in 2026</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Eight strategic decisions every CTO or CIO must make within 90 days to deploy AI at enterprise scale.</li>
<li>Model selection, hosting tier, AI portal, RAG, agents, Decision Layer, compliance, and orchestration form the complete stack.</li>
<li>The hybrid hosting architecture - routing requests by data sensitivity across cloud, European IaaS, and on-premises - has become the standard.</li>
<li>IDC (2025) projects worldwide spending on AI infrastructure to reach $154 billion by 2027, up from $76 billion in 2024.</li>
<li>A concrete 90-day roadmap turns pilot projects into production infrastructure with governance built in from the start.</li>
</ul>
</div>

This blueprint reduces that complexity to eight concrete decisions every technical leader must make within the next 90 days. Each decision is covered in a dedicated article, with comparison tables, decision trees, and actionable recommendations. No marketing, no buzzwords. Facts, architecture, guidance.

## The Eight Decisions

### Decision 1: Which AI Model?

The model market has fundamentally shifted in 2025/2026. With gpt-oss, Llama 4, and Mistral Medium 3.1, open-source models now match proprietary ones in many benchmarks. Meanwhile, Claude Opus 4.7, GPT-5.5, and Gemini 3.1 Pro compete in a tight race among the flagship tier. The right answer is not one model. It is a model-agnostic architecture that routes each task to the most appropriate model.

**[Read: AI Models 2026, Which Model for Which Use Case?](/en/magazine/ai-models-comparison-2026/)**

### Decision 2: Where Do Your Models Run?

EU SaaS, European data center, or self-hosted. This decision determines your data protection guarantees, your cost structure, and your dependency on third-party providers. The hybrid strategy, in which a routing layer automatically distributes requests by data sensitivity, has emerged as the standard.

**[Read: AI Hosting, EU SaaS, German Data Center, or Self-Hosted?](/en/magazine/ai-hosting-strategies-enterprise/)**

Once the hosting decision is made, contractual safeguards follow. A standard DPA is not sufficient for AI infrastructure - [our requirements checklist](/en/magazine/dpa-ai-infrastructure-checklist/) identifies the ten gaps and provides 25 verification questions for legal and compliance.

### Decision 3: How Do You Make AI Usable Without Losing Control?

A language model without a controlled interface is like a server without a frontend. Employees will turn to public AI services, uncontrolled, unlogged, non-compliant with GDPR. An enterprise AI portal provides the better alternative: multi-model routing, assistant sharing, agent integration, SSO, and a complete audit trail.

→ **Article 3: Enterprise AI Portals** - Five open-source interfaces compared: LobeChat, OpenWebUI, LibreChat, chatbot-ui and very-ai. Which portal has SSO, PII protection and audit trail? (Transparency note: very-ai is developed by Gosign.)

**[Read: Enterprise AI Portals, Five Open-Source Interfaces Compared](/en/magazine/enterprise-ai-chat-interface/)**

### Decision 4: How Does Your Corporate Knowledge Become AI-Accessible?

Retrieval-Augmented Generation (RAG) connects language models with your internal knowledge: contracts, manuals, policies, project documentation. The challenge lies not in the technology itself but in data quality, chunking strategy, and access control. Poorly implemented, RAG delivers hallucinated answers with source citations.

**[Read: RAG & Document Intelligence for Enterprise](/en/magazine/rag-document-intelligence-enterprise/)**

### Decision 5: From Chatbot to Real Agent?

AI agents are not improved chatbots. They are specialized software units that autonomously execute multi-step tasks: analyzing documents, preparing decisions, triggering workflows. The transition from chat to agent requires a different [infrastructure](/en/services/infrastructure/), with agent orchestration, tool use, and human-in-the-loop.

**[Read: From Chatbots to AI Agents: MCP, A2A and Multi-Agent Systems](/en/magazine/ai-agents-enterprise-guide/)**

### Decision 6: How Do You Separate Analysis from Decision?

The Decision Layer is the architectural component that determines which decisions AI may prepare, which a rule engine handles, and which require human approval. Without this layer, shadow AI emerges. Employees use AI for decisions it was never intended to make.

**[Read: Decision Layer & Shadow AI](/en/magazine/decision-layer-shadow-ai/)**

### Decision 7: What Does It Actually Cost, and What Does the EU AI Act Require?

Since August 2025, the transparency obligations of the EU AI Act have been in force. Under current law the high-risk rules take effect on 2 August 2026, but following the provisional Digital Omnibus agreement of 7 May 2026 that deadline is set to be postponed to 2 December 2027 (formal adoption still pending, as of June 2026). Meanwhile, token prices account for only 20 to 35 percent of actual AI costs. Understanding total cost of ownership and regulatory obligations together is essential for sound investment decisions.

**[Read: What AI Really Costs, TCO Comparison](/en/magazine/ai-costs-tco-comparison/)** | **[Read: EU AI Act 2026](/en/magazine/eu-ai-act-2026-enterprises/)**

### Decision 8: Where Do Your Agents Run?

You know what agents are. Now: where do they execute? The orchestration platform defines the workflows that connect a language model with your business processes. The choice between visual workflow tools like n8n and process engines like Camunda depends on your compliance requirements, process complexity, and speed-to-value targets.

**[Read: Agent Orchestration, n8n, Camunda, and Alternatives Compared](/en/magazine/agent-orchestration-platforms/)**

## The Eight Decisions at a Glance

<table>
<thead>
<tr><th>Decision</th><th>Topic</th><th>Key Question</th></tr>
</thead>
<tbody>
<tr><td>1</td><td>AI Model Selection</td><td>Which model for which task? Model-agnostic routing.</td></tr>
<tr><td>2</td><td>Hosting Strategy</td><td>EU SaaS, European data center, or self-hosted?</td></tr>
<tr><td>3</td><td>Enterprise AI Portal</td><td>Controlled interface with SSO, audit trail, PII protection.</td></tr>
<tr><td>4</td><td>RAG & Document Intelligence</td><td>How does corporate knowledge become AI-accessible?</td></tr>
<tr><td>5</td><td>AI Agents</td><td>From chatbot to autonomous multi-step agent.</td></tr>
<tr><td>6</td><td>Decision Layer</td><td>Separating AI analysis from business decisions.</td></tr>
<tr><td>7</td><td>Costs & EU AI Act</td><td>TCO and regulatory obligations since August 2025.</td></tr>
<tr><td>8</td><td>Agent Orchestration</td><td>n8n, Camunda, or Temporal for production workflows.</td></tr>
</tbody>
</table>

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Free eBook: AI Infrastructure</p>
<p class="text-body text-gosign-text mb-4">Build, Buy, Hybrid - EU AI Act-compliant infrastructure with B/B/H Framework and 7-Layer Reference Architecture.</p>
<a href="/en/ebook/ai-infrastructure-governance-handbook/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Download for free</a>
</div>

## Who This Blueprint Is Written For

This blueprint is designed for technical decision makers in organizations with 500 or more employees:

- **CTOs and VPs of Engineering** who need to build or consolidate an AI architecture
- **CIOs** who must align AI strategy with IT governance and the existing technology landscape
- **Heads of HR and COOs** who are integrating AI into operational processes, from document processing to knowledge management
- **Technically oriented C-level executives** who want to make informed decisions rather than collect pilot projects

The blueprint assumes you have moved past the experimentation phase. The question is no longer whether to deploy AI, but how, with which architecture, which [governance](/en/governance/) framework, and which operating model.

## 90-Day Roadmap

The blueprint culminates in a concrete roadmap with three phases:

### Phase 1: Foundation (Weeks 1--4)

- Create an AI system inventory (what is already in use?)
- Conduct data classification
- Identify one use case (highest ROI at lowest risk)
- Make the hosting decision (Tier 1, 2, or 3)
- Roll out an internal AI portal (LobeChat, OpenWebUI, very-ai, or LibreChat)

The presentation layer - the enterprise AI portal - has five open-source options in 2026. Gosign has developed very-ai, a portal that adds PII protection and Entra ID group sync as enterprise features (→ Article 3). As with all recommendations in this series: evaluate multiple options for your specific context.

Result: your employees have a controlled AI tool instead of shadow AI.

### Phase 2: First Agent (Weeks 5--8)

- Implement the use case as an [AI agent](/en/services/ai-agents/)
- Connect to one or two existing systems via MCP
- Define rule sets for decisions
- Set up human-in-the-loop for critical steps
- Define a pilot group of 10--20 users

Result: a functioning agent that improves a real business process.

### Phase 3: Governance and Scaling (Weeks 9--12)

- Validate the audit trail and logging
- Begin EU AI Act documentation (risk assessment, technical documentation)
- Measure pilot results (time saved, error rate, user satisfaction)
- Create a scaling plan: which three to five use cases come next?

Result: a validated business case and a clear path to scaling.

The roadmap is deliberately compact. In 90 days, you will not achieve a complete AI transformation, but you will have a production [infrastructure](/en/services/infrastructure/), a running agent, and the governance foundation to scale securely.

---

**Further reading:** [AI Infrastructure, Services Overview](/en/services/infrastructure/) | [Decision Layer Explained](/en/decision-layer/)

---

**📘 Enterprise AI Infrastructure Blueprint 2026 - Article Series**

| ← Previous | Overview | Next → |
|:---|:---:|---:|
| - | You are on the overview | [AI Models 2026: Which Model for Which Use Case?](/en/magazine/ai-models-comparison-2026/) |

*All articles in this series: [Enterprise AI Infrastructure Blueprint 2026](/en/magazine/ai-infrastructure-blueprint-2026/)*

---

**Prefer not to make these eight decisions alone?** Gosign partners with enterprise clients from architecture to production operations, model-agnostic, vendor-neutral, with full source code access.

Which process should your first agent handle? → <a href="/en/contact/" target="_blank" rel="noopener noreferrer">Book a consultation</a>

--- AI Infrastructure in Your Existing IT Landscape ---
> How AI agents and LLMs integrate into SAP, Workday and cloud landscapes - no greenfield, no shadow IT, no platform migration.

## The Integration Problem

Most enterprises do not have an empty IT landscape. They have SAP, [Workday](https://www.workday.com/), [SuccessFactors](https://www.sap.com/products/hcm.html), [DATEV](https://www.datev.de/), [Sage](https://www.sage.com/), SharePoint, industry-specific systems, established middleware and proven security architectures. This is not an obstacle to AI - it is the reality into which AI must fit.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">At a Glance - AI Integration into Existing IT</p>
<ul class="text-body text-gosign-text space-y-2">
<li>AI infrastructure is an integration layer on top of existing systems - SAP, Workday, and cloud landscapes remain unchanged.</li>
<li>Four architectural layers: system connectivity, orchestration, Decision Layer, and user interface.</li>
<li>Agents communicate via standard APIs (RFC, OData, REST) - no direct database access, no proprietary interfaces.</li>
<li>McKinsey (2024) reports that 74% of enterprise AI projects fail to move beyond pilot stage, primarily due to integration gaps.</li>
<li>Existing security policies, authentication, and audit processes remain fully valid - the agent is an additional participant, not a parallel system.</li>
</ul>
</div>

The most common cause of failed AI projects in enterprises is not technology. It is that AI is introduced as an isolated system - alongside existing IT, not within it. This creates shadow IT, data silos and governance gaps.

The correct approach: AI infrastructure as an integration layer that connects existing systems rather than replacing them.


## Architecture Principle: Integration Layer, Not Platform Migration

An enterprise AI infrastructure consists of four layers that fit into any existing IT landscape.

The lowest layer is system connectivity. Connectors to SAP (via RFC, OData, BAPIs), to Workday (via REST APIs), to DATEV, Sage, SharePoint, email systems and industry-specific applications. These connectors read and write data - source systems remain unchanged.

Above it sits the orchestration layer. This is where [AI agents](/en/services/ai-agents/) run: Document Agents that read and classify incoming documents. Workflow Agents that manage processes across systems. Knowledge Agents that answer questions based on enterprise knowledge.

The third layer is the [Decision Layer](/en/finance-ai-agents/). It separates AI analysis from business decisions. The model recommends, the human decides. Every decision is documented, versioned and auditable.

The top layer is the interface: a unified chat interface for employees or direct system-to-system integration without human interaction.


## In Practice: How an AI Agent Integrates into an SAP Landscape

A real-world example: sick leave processing.

An employee submits a sick note via email or a portal. A Document Agent identifies the document type, extracts relevant fields (name, period, diagnosis group) and validates the data against the collective agreement. Via the SAP connector, it checks personnel master data, calculates continued pay and prepares the booking.

At this point, the Decision Layer intervenes: if the case falls within automatable rules (standard case, no anomalies), the booking is presented to the responsible clerk for approval. If an anomaly is detected (frequency, deadline breach, missing data), the case is escalated.

The SAP instance was not modified at any point. The agent operates as an external integration layer communicating via standard APIs. Existing authorisation concepts, network zones and audit processes remain unchanged.


## What the IT Architecture Must Deliver

For clean integration, AI infrastructure requires four properties.

First: API-first. All communication between agent and source system runs via documented APIs. No direct database access, no proprietary interfaces.

Second: multi-tenancy. In group structures, agents must be configurable per entity - different rules, different systems, different compliance requirements per subsidiary.

Third: logging and audit. Every interaction between agent and source system is logged - who read, wrote or decided what, and when. This is not optional; it is the foundation of [Governance by Design](/en/governance/).

Fourth: rollback capability. If an agent makes an error, every action must be reversible. This requires transaction-oriented communication with source systems.


## Integration Layer Overview

<table>
<thead>
<tr><th>Layer</th><th>Function</th><th>Technology</th></tr>
</thead>
<tbody>
<tr><td>System Connectivity</td><td>Read/write to source systems</td><td>SAP RFC/OData, Workday REST, DATEV API, Microsoft Graph</td></tr>
<tr><td>Orchestration</td><td>Coordinate agents and workflows</td><td>Trigger.dev, Camunda, n8n</td></tr>
<tr><td>Decision Layer</td><td>Separate AI analysis from business decisions</td><td>Rules Engine, Confidence Routing, Human-in-the-Loop</td></tr>
<tr><td>Interface</td><td>Employee access or system-to-system</td><td>Enterprise AI Portal, REST API</td></tr>
</tbody>
</table>

## No Greenfield, No Platform Migration

The most common objection from CIOs: "We cannot introduce another system." And this objection is valid.

This is why AI infrastructure is not a new system in the traditional sense. It is a layer that fits into the existing architecture. SAP remains SAP. Workday remains Workday. The network architecture remains in place. Security policies remain valid. The agent is an additional participant in the existing ecosystem - subject to the same rules, the same controls, the same audit requirements.

At Gosign, we build [AI infrastructure](/en/services/infrastructure/) as an integration layer: on Azure, GCP or self-hosted, connected to the systems already in place. No shadow IT. Agents become part of the existing [IT governance](/en/governance/) - not a new parallel world.

--- AI Infrastructure, Not Tool Hype: Enterprise Stack ---
> AI tools vs. AI infrastructure: orchestration, governance, model-agnosticism, audit trail. Why enterprises need their own infrastructure layer

## Tool vs. Infrastructure

ChatGPT, Microsoft CoPilot, Google Gemini - these are AI tools. You enter a question, you get an answer. For individual productivity, that works. For enterprise processes, it does not.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">At a Glance - AI Infrastructure vs. Tool Hype</p>
<ul class="text-body text-gosign-text space-y-2">
<li>ChatGPT, CoPilot, and Gemini are AI tools - not enterprise infrastructure. They lack audit trails, tenant isolation, and system integration.</li>
<li>Enterprise AI infrastructure consists of seven layers: Presentation, Orchestration, Agent, Decision, Model, Integration, and Infrastructure.</li>
<li>Gartner (2024) reports that over 55% of organizations that deployed AI tools without governance had to rebuild their approach within 18 months.</li>
<li>A model-agnostic architecture prevents vendor lock-in and keeps models interchangeable across Claude, GPT, Gemini, Llama, and Mistral.</li>
<li>After 12 to 18 months, the client operates the infrastructure independently with full source code access and no recurring vendor dependency.</li>
</ul>
</div>

The difference between an AI tool and AI infrastructure is comparable to the difference between a spreadsheet and an ERP system. The spreadsheet solves a specific problem for a single user. The ERP system is the infrastructure on which the entire organization's business processes run.

AI infrastructure is the architectural layer between the language model and the enterprise system. It encompasses: model hosting, orchestration, Decision Layer, governance, integration with existing systems. The language model is one component of this infrastructure, not the infrastructure itself.

## What an AI Tool Lacks

When an organization uses ChatGPT for invoice processing, the following is missing:

**Audit Trail:** No documentation of which decision was made on what basis. During an audit, nothing is traceable.

**Versioned Rule Sets:** ChatGPT has no awareness of client-specific booking rules in version 4.2. It has general knowledge about accounting, but no concrete rule sets belonging to the client.

**Tenant Isolation:** Data from all tenants flows into the same system. No row-level security, no workspace separation.

**Integration:** ChatGPT cannot create a booking entry in SAP, trigger a workflow in [Trigger.dev](https://trigger.dev/), or escalate a case to a case worker.

**Human-in-the-Loop:** No architecturally enforced human review. No escalation rules. No confidence thresholds.

**Model-Agnosticism:** Building on ChatGPT means being locked into OpenAI. If OpenAI raises prices, changes the API, or discontinues the service, the organization is left without an alternative.

## The Seven Layers of Enterprise AI Infrastructure

The Gosign reference architecture describes seven layers:

**Presentation Layer:** Chat interface, dashboard, Auditor Portal, REST API. The interface between the system and the user.

**Orchestration Layer:** Workflow engine ([Trigger.dev](https://trigger.dev/) or [Camunda](https://camunda.com/)), API gateway, queue management. Coordinates data flow between all components.

**Agent Layer:** The specialized agents - Document Agents, Workflow Agents, Knowledge Agents. Each agent has a defined scope of responsibility.

**[Decision Layer](/en/decision-layer/):** Decomposes every process into decision steps. For each step it defines: human, rule set, or AI. It includes a Rules Engine (versioned rule sets), Confidence Routing (automatic risk assessment), Human-in-the-Loop (technically enforced), and Audit Trail (immutable decision log).

**Model Layer:** The language models. Interchangeable, model-agnostic. Claude, ChatGPT, Gemini, Llama, Mistral, DeepSeek, gpt-oss.

**Integration Layer:** The connection to existing systems. SAP, [DATEV](https://www.datev.de/), [Sage](https://www.sage.com/), [Workday](https://www.workday.com/), [SuccessFactors](https://www.sap.com/products/hcm.html), SharePoint.

**Infrastructure Layer:** The deployment. Azure, GCP, self-hosted, hybrid.

The Governance layer runs as a cross-cutting concern through all seven layers.

## AI Tool vs. AI Infrastructure

<table>
<thead>
<tr><th>Capability</th><th>AI Tool (ChatGPT)</th><th>AI Infrastructure</th></tr>
</thead>
<tbody>
<tr><td>Audit Trail</td><td>No</td><td>Immutable decision log</td></tr>
<tr><td>Tenant Isolation</td><td>No</td><td>Row-Level Security, workspace separation</td></tr>
<tr><td>ERP Integration</td><td>No</td><td>SAP, DATEV, Workday via APIs</td></tr>
<tr><td>Versioned Rule Sets</td><td>No</td><td>Client-specific, versioned</td></tr>
<tr><td>Human-in-the-Loop</td><td>No</td><td>Architecturally enforced</td></tr>
<tr><td>Model Independence</td><td>Locked to one vendor</td><td>Model-agnostic routing</td></tr>
<tr><td>Governance Layer</td><td>Not available</td><td>Cross-cutting through all layers</td></tr>
</tbody>
</table>

## The Infrastructure Advantage

With its own AI infrastructure, the organization gains:

**Control:** Data stays within the organization's own infrastructure. Models are interchangeable. Full access to rule sets and configurations.

**Scalability:** One agent for one process is a PoC. The infrastructure enables deploying additional agents for additional processes, with the same governance.

**Independence:** After 12-18 months, the client operates the infrastructure autonomously. Full access to source code, all prompts, and all rule sets. No vendor lock-in.

More on this: [AI Infrastructure](/en/services/infrastructure/)

<a href="/en/contact/" target="_blank" rel="noopener noreferrer">Book a consultation</a> - We will show you what an AI infrastructure for your organization looks like.

--- AI Integration Into IT Landscapes: SAP, DATEV, Workday ---
> How AI agents integrate into SAP, DATEV, Workday via Integration Layer and API decoupling. Booking logic separated from export. No parallel system.

## The Principle: Extend, Not Replace

AI agents do not replace existing systems. They extend them. SAP remains SAP. DATEV remains DATEV. Workday remains Workday. The agent sits in between: It reads data, makes decisions, and writes results back.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">At a Glance - AI Integration into Enterprise Systems</p>
<ul class="text-body text-gosign-text space-y-2">
<li>AI agents extend existing systems (SAP, DATEV, Workday) rather than replacing them - the agent is an external integration layer.</li>
<li>The Integration Layer decouples agent logic from the target system: when the ERP changes, only the export layer changes.</li>
<li>Booking logic (Decision Layer) is architecturally separated from the export format (Integration Layer), reducing migration effort.</li>
<li>Forrester (2024) finds that enterprises with API-first integration strategies deploy AI 2.4 times faster than those relying on custom connectors.</li>
<li>Agents use existing authentication, cloud environments, security policies, and monitoring - no parallel system required.</li>
</ul>
</div>

This principle is critical for adoption in enterprise environments. CIOs do not invest in a parallel world. They invest in a layer that makes their existing IT landscape smarter.

## The Integration Layer

The Integration Layer in the Gosign reference architecture decouples agent logic from the target system. This has a concrete advantage: When the target system changes, only the export layer changes, not the agent.

**[SAP FI/CO and S/4HANA](https://www.sap.com/products/erp/s4hana.html):** Booking proposals in SAP format. Cost center and profit center logic. Integration via RFC, REST API, or SAP BTP.

**[DATEV](https://www.datev.de/):** Booking proposals in DATEV format. SKR03 and SKR04. Tenant-specific charts of accounts. Export via DATEV interface.

**[Workday](https://www.workday.com/):** HR data, payroll (UK: PAYE) information, organizational structure. Integration via Workday REST API.

**[SuccessFactors](https://www.sap.com/products/hcm.html):** Employee data, performance data, compensation. Integration via SAP SuccessFactors API.

**[Microsoft Graph](https://learn.microsoft.com/en-us/graph/overview):** SharePoint, Teams, Outlook. For Knowledge Agents that access company documents.

## Decoupling: Booking Logic vs. Export Layer

The separation of booking logic and export layer is a central architectural principle. The booking logic, which account, which cost center, which tax rate, is implemented in the [Decision Layer](/en/decision-layer/). The export layer, how the result is passed to DATEV or SAP, is in the Integration Layer.

When a client migrates from DATEV to SAP, the export layer changes. The booking logic, the rule sets, the agent, everything else stays the same. This significantly reduces migration effort.

## Integration Layer by Target System

<table>
<thead>
<tr><th>Target System</th><th>Integration Method</th><th>Data Scope</th></tr>
</thead>
<tbody>
<tr><td>SAP FI/CO, S/4HANA</td><td>RFC, REST API, SAP BTP</td><td>Booking proposals, cost center logic</td></tr>
<tr><td>DATEV</td><td>DATEV interface, SKR03/SKR04</td><td>Booking proposals, charts of accounts</td></tr>
<tr><td>Workday</td><td>Workday REST API</td><td>HR data, payroll, org structure</td></tr>
<tr><td>SuccessFactors</td><td>SAP SuccessFactors API</td><td>Employee, performance, compensation</td></tr>
<tr><td>Microsoft Graph</td><td>Graph API</td><td>SharePoint, Teams, Outlook</td></tr>
</tbody>
</table>

## No Parallel System

Agents become part of the existing IT governance, not a new parallel world. This means:

- Agents use existing authentication (Azure Entra ID, LDAP)
- Agents run in the existing cloud environment (Azure, GCP)
- Agents are subject to existing security policies
- Agents are integrated into existing monitoring systems

For the CIO, an AI agent is another component in the existing architecture, not a separate system with its own rules.

More on this: [Reference Architecture](/en/governance/reference-architecture/)

<a href="/en/contact/" target="_blank" rel="noopener noreferrer">Book a consultation</a> - We will show you the integration into your existing IT landscape.

--- When Mistral, When Claude Opus? Decision Routing for Agentic EU-Enterprise 2026 ---
> Decomposed agentic decisions: Mistral Small on EU on-prem handles 70%, Claude Opus stays for the 10% with real reasoning load. Decision Records ready for EU AI Act Art. 13.

The model market matured faster than most enterprise architectures. Claude Opus 4.7, GPT-5.5 and Gemini 3.1 Pro converge in quality. Mistral La Plateforme operates from a French data center under EU jurisdiction. OpenAI released gpt-oss under Apache 2.0 in August 2025. Meta and Mistral ship open-weight models that run on a single GPU and reach production quality.

Most enterprise AI projects still pick one model and route every workload through it. That choice quietly determines three other things: your cloud sovereignty position, your audit cost under the EU AI Act, and the headroom for cost optimization. Picking a model is not a model decision. It is an architecture decision.

<div class="not-prose my-12 border border-gosign-border bg-gosign-light rounded-card p-6 lg:p-8">
<p class="text-h3 font-bold text-gosign-dark mb-3">At a Glance - Agentic AI Stack for EU-Enterprise 2026</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Around 70% of agentic decisions in a well-decomposed enterprise workflow are rule application or structured extraction. In typical EU hosting setups, Mistral Small 3.2 on a single GPU handles these at roughly 1/30 of the Claude Opus list price.</li>
<li>Mistral has two distinct deployment surfaces: La Plateforme (EU-hosted API, French infrastructure, Q2 2026 dedicated data center at Bruyères-le-Châtel) and Mistral Small 3.2 (Apache 2.0, fully self-hostable, 24B parameters).</li>
<li>The remaining 8 to 10% of decisions, complex reasoning, cross-jurisdictional analysis, edge-case escalation, justify Claude Opus 4.7 or GPT-5.5. That is where token spend is earned, not wasted.</li>
<li>US CLOUD Act exposure applies even to EU-region deployments of US providers. Schrems II made this concrete. Self-hosted Mistral Small, gpt-oss-120b or DeepSeek V4-Flash (April 2026 preview, MIT, 284B/13B active MoE) are the only architectures with zero CLOUD Act surface.</li>
<li>EU AI Act Article 13 requires transparent operation of high-risk systems. A Decision Routing layer produces the audit artifact: per-decision record with input, rule version, model, confidence, and human approver where escalated.</li>
</ul>
</div>

## You evaluate Mistral - what you actually evaluate is your EU cloud strategy

A typical search trail in 2026 looks like this. Compliance asks for an EU alternative to OpenAI. Procurement compiles vendor pitches. Architecture starts evaluating Mistral. Within a week the conversation has moved from "which model" to "what is our position on US CLOUD Act exposure" and "how do we operationalize EU AI Act Article 13 for high-risk systems."

The CLOUD Act follows provider control, not data location. A US provider with EU data centers - Azure OpenAI EU, AWS Bedrock Frankfurt, GCP Vertex europe-west - can still be compelled to hand over data under a US warrant. The European Commission is expected to release a [Tech Sovereignty Package](https://www.kiteworks.com/cybersecurity-risk-management/eu-tech-sovereignty-package-cloud-act/) in Q2 2026, restricting public-sector use of US providers for sensitive workloads in healthcare, finance and judicial systems. Private-sector procurement is reading those signals.

Mistral matters because it occupies a position no US provider can occupy: a frontier-class European provider with [dedicated EU infrastructure](https://help.mistral.ai/en/articles/347629-where-do-you-store-my-data-or-my-organization-s-data) and a fully open-weight model line under Apache 2.0. The leaderboard comparison against Claude is secondary; the sovereignty position is what changes the procurement math. From Q2 2026 the company runs its own data center near Paris with [13,800 NVIDIA GB300 GPUs](https://ioplus.nl/en/posts/why-mistrals-830m-raise-is-a-win-for-european-autonomy) and 44 megawatts of capacity. That makes Mistral the only frontier provider that can offer end-to-end EU residency on infrastructure owned and operated under EU jurisdiction.

But that frames the question wrong. The real question is not "Mistral or OpenAI". It is "which decisions go where, and how do you prove it to an auditor."

## Mistral is two worlds: La Plateforme in France or Mistral Small Apache 2.0

The confusion starts with treating "Mistral" as one product. It is two product families with different deployment surfaces and different compliance implications.

| Mistral product | Deployment | License / cost | EU-sovereign |
|---|---|---|---|
| Mistral Medium 3.1 | La Plateforme (FR-hosted API) or Azure AI Foundry | Token-based, proprietary | Yes via La Plateforme |
| Mistral Small 3.2 | Self-hosted on-prem | Apache 2.0, GPU-cost only | Yes if EU hardware |
| Mixtral 8x22B | Self-hosted on-prem | Apache 2.0, GPU-cost only | Yes if EU hardware |
| Codestral | La Plateforme | Token-based, proprietary | Yes via La Plateforme |

*"EU-sovereign" means: outside US CLOUD Act reach. Both La Plateforme (French jurisdiction) and self-hosted on EU hardware qualify. Azure AI Foundry does not, even with EU data residency, because Microsoft remains subject to CLOUD Act orders.*

Mistral Medium 3.1 is the proprietary frontier-class flagship. It runs on Mistral's own French infrastructure, accessed by API on token-based billing under EU jurisdiction by default. From Q2 2026 the dedicated Bruyères-le-Châtel data center handles inference for customers requiring guaranteed French residency.

[Mistral Small 3.2](https://mistral.ai/news/mistral-small-3-1) is the open-weight workhorse. 24 billion parameters. 128K token context. Vision understanding included. Released March 2025 under Apache 2.0. Runs on a single NVIDIA RTX 4090 or a Mac with 32 GB RAM. Throughput around 150 tokens per second on consumer hardware.

The two are not redundant. La Plateforme makes sense when you want EU sovereignty without operating GPU infrastructure. Mistral Small 3.2 makes sense when the decision is so high-volume that token billing becomes the cost driver, or when the data is so sensitive that even EU API traffic is too much surface.

The architecture question is which deployment surface for which decision, not which provider for which leaderboard.

<figure class="not-prose my-12">
<svg viewBox="0 0 800 600" xmlns="http://www.w3.org/2000/svg" role="img" aria-labelledby="radar-title radar-desc" class="w-full h-auto max-w-3xl mx-auto">
<title id="radar-title">Model profile comparison on six enterprise dimensions (May 2026)</title>
<desc id="radar-desc">Spider chart comparing four representative models on six enterprise-relevant dimensions, each scored 0 to 10. Claude Opus 4.7 (cloud, Anthropic): Reasoning 10, Coding 10, Multimodal 7, Cost-Efficiency 3, Latency 6, EU-Sovereignty 4. GPT-5.5 (cloud, OpenAI): Reasoning 10, Coding 10, Multimodal 9, Cost-Efficiency 3, Latency 7, EU-Sovereignty 4. Mistral Small 3.2 (self-hostable, Apache 2.0): Reasoning 6, Coding 7, Multimodal 8, Cost-Efficiency 10, Latency 9, EU-Sovereignty 10. DeepSeek V4-Pro (self-hostable, MIT): Reasoning 9, Coding 8, Multimodal 5, Cost-Efficiency 7, Latency 7, EU-Sovereignty 9. Cloud flagships dominate Reasoning, Coding, and Multimodal but lose on Cost-Efficiency and Sovereignty. Self-hostable models invert that pattern. The decision routing layer combines both shapes per micro-decision rather than picking one champion.</desc>
<defs>
<style>
.axis { stroke: #d4d0cb; stroke-width: 1; fill: none; }
.grid { stroke: #d4d0cb; stroke-width: 0.5; fill: none; opacity: 0.5; }
.label { font-family: -apple-system, system-ui, sans-serif; font-size: 12px; fill: #1a2e4d; text-anchor: middle; font-weight: 600; }
.scale { font-family: -apple-system, system-ui, sans-serif; font-size: 9px; fill: #94a3b8; text-anchor: middle; }
.legend { font-family: -apple-system, system-ui, sans-serif; font-size: 12px; fill: #1a2e4d; font-weight: 500; }
.legend-sub { font-family: -apple-system, system-ui, sans-serif; font-size: 10px; fill: #64748b; }
</style>
</defs>
<circle cx="400" cy="300" r="50" class="grid"/>
<circle cx="400" cy="300" r="100" class="grid"/>
<circle cx="400" cy="300" r="150" class="grid"/>
<circle cx="400" cy="300" r="200" class="grid"/>
<circle cx="400" cy="300" r="250" class="grid"/>
<text x="408" y="100" class="scale">10</text>
<text x="408" y="150" class="scale">8</text>
<text x="408" y="200" class="scale">6</text>
<text x="408" y="250" class="scale">4</text>
<text x="408" y="300" class="scale">2</text>
<line x1="400" y1="300" x2="400" y2="50" class="axis"/>
<line x1="400" y1="300" x2="616.5" y2="175" class="axis"/>
<line x1="400" y1="300" x2="616.5" y2="425" class="axis"/>
<line x1="400" y1="300" x2="400" y2="550" class="axis"/>
<line x1="400" y1="300" x2="183.5" y2="425" class="axis"/>
<line x1="400" y1="300" x2="183.5" y2="175" class="axis"/>
<text x="400" y="38" class="label">Reasoning Quality</text>
<text x="630" y="165" class="label">Coding Performance</text>
<text x="630" y="438" class="label">Multimodal</text>
<text x="400" y="572" class="label">Cost-Efficiency</text>
<text x="170" y="438" class="label">Inference Latency</text>
<text x="170" y="165" class="label">EU-Sovereignty</text>
<polygon points="400,50 616.5,175 562,387 400,375 335,338 313,225" fill="#fcd34d" fill-opacity="0.25" stroke="#b8941f" stroke-width="2"/>
<polygon points="400,50 616.5,175 595,413 400,375 313,363 313,225" fill="#3a6090" fill-opacity="0.20" stroke="#3a6090" stroke-width="2" stroke-dasharray="6 3"/>
<polygon points="400,150 551.5,213 579,400 400,550 205,425 183.5,175" fill="#1a2e4d" fill-opacity="0.20" stroke="#1a2e4d" stroke-width="2"/>
<polygon points="400,75 595,188 508,363 400,475 248,400 205,200" fill="#9a5a5a" fill-opacity="0.18" stroke="#9a5a5a" stroke-width="2" stroke-dasharray="3 3"/>
<g transform="translate(40, 590)">
<rect x="0" y="-15" width="15" height="3" fill="#b8941f"/>
<text x="22" y="-9" class="legend">Claude Opus 4.7</text>
<text x="22" y="3" class="legend-sub">cloud, Anthropic</text>
</g>
<g transform="translate(195, 590)">
<rect x="0" y="-15" width="15" height="3" fill="#3a6090"/>
<text x="22" y="-9" class="legend">GPT-5.5</text>
<text x="22" y="3" class="legend-sub">cloud, OpenAI/Azure</text>
</g>
<g transform="translate(370, 590)">
<rect x="0" y="-15" width="15" height="3" fill="#1a2e4d"/>
<text x="22" y="-9" class="legend">Mistral Small 3.2</text>
<text x="22" y="3" class="legend-sub">self-host, Apache 2.0</text>
</g>
<g transform="translate(560, 590)">
<rect x="0" y="-15" width="15" height="3" fill="#9a5a5a"/>
<text x="22" y="-9" class="legend">DeepSeek V4-Pro</text>
<text x="22" y="3" class="legend-sub">self-host, MIT</text>
</g>
</svg>
<figcaption class="text-sm text-gosign-text-light text-center mt-4 max-w-2xl mx-auto">
<strong>Model profile on six enterprise dimensions</strong> - the c't-style comparison view, scored 0 to 10 per dimension. Cloud flagships (Claude Opus 4.7, GPT-5.5) dominate Reasoning, Coding, Multimodal but lose on Cost-Efficiency and EU-Sovereignty. Self-hostable models (Mistral Small 3.2, DeepSeek V4-Pro) invert that shape. There is no single "best" model - the routing layer picks the right shape per micro-decision.
</figcaption>
</figure>

## Why Mistral Small as default, not gpt-oss or DeepSeek

A fair question once you commit to self-hosting: why does Mistral Small 3.2 win the workhorse slot over [gpt-oss-120b](https://openai.com/index/introducing-gpt-oss/) (Apache 2.0, 117B params MoE, August 5, 2025) or [DeepSeek V4](https://api-docs.deepseek.com/news/news260424) (MIT, April 24, 2026 preview; V4-Flash 284B/13B active, V4-Pro 1.6T/49B active, 1M context)? All three are legitimately self-hostable in some configuration. The differentiation is hardware floor, language coverage, and modality.

| Open-source model | Hardware floor | Strength | Weakness | Sweet spot |
|---|---|---|---|---|
| Mistral Small 3.2 (24B, Apache 2.0) | 1× RTX 4090 (~1,500 EUR one-time) or Mac M2/M3 32GB | Volume, multilingual (DE/EN/PL/ES/BR), vision-capable, ~150 tok/s | Not top-tier reasoning | **Default workhorse for the 70% volume band** |
| gpt-oss-120b (117B MoE, Apache 2.0) | 1× H100/A100 80GB (~30k EUR or ~1,200 EUR/month hosted) | Reasoning at o4-mini level, MoE-efficient | No vision, datacenter-grade hardware required | **Heavy-reasoning alternative to Claude Opus, when even that must stay on-prem** |
| DeepSeek V4-Flash (MIT, Apr 2026 preview) | 1-2× H100/A100 80GB with quant (~30-60k EUR or ~1,500-5,000 EUR/month hosted) | Frontier-class reasoning at moderate hardware, 1M context, native multimodal | Preview status - benchmarks should be re-verified before production | **Math/logic specialist + 1M-context portfolio analysis** |
| DeepSeek V4-Pro (MIT, Apr 2026 preview) | 8× H100 cluster (~240,000 EUR CAPEX or ~10,000 EUR/month hosted) | Approaches GPT-5.5/Gemini 3.1 Pro performance, agent-tool optimized | DAX-Konzern feasible from day one, upper Mittelstand budget-fit, KMU via API/hosted (Together.ai, Fireworks) | **Frontier reasoning under open license - on-prem for Konzern, API for KMU** |
| Llama 4 Scout (Meta Llama License) | 1× GPU | 10M token context | License restriction at >700M MAU | **Ultra-long-context for entire contract portfolios** |

Three concrete reasons Mistral Small earns the default slot:

**Hardware threshold.** Mistral Small runs on consumer-grade silicon. gpt-oss-120b needs a datacenter GPU. For an enterprise pipeline with five to ten worker nodes, the per-node hardware delta is significant. When 70% of decisions are classification or extraction, gpt-oss-grade reasoning capacity is overkill for the volume work.

**Multilingual training corpus.** Mistral was trained on French, German, Spanish and Italian data from the start. gpt-oss is US-centric with English-dominant training. For an EU-Enterprise pipeline processing Polish, Spanish or Portuguese documents, Mistral Small is the better workhorse on day one.

**Vision included.** Mistral Small 3.2 has native vision capability. gpt-oss does not. For HR onboarding (passport scans, certificates, tax forms) or AP (PDF invoices with layout), this is a hard knockout.

gpt-oss-120b or DeepSeek V4-Flash enter the stack as on-prem heavy-reasoning options when Claude Opus 4.7 API cannot be used for compliance reasons. DeepSeek V4-Pro approaches frontier-closed-source performance under MIT license; for DAX-Konzerne and upper Mittelstand the 8× H100 cluster (~240,000 EUR CAPEX or ~10,000 EUR/month hosted) is a standard IT-budget line item, for KMU under 500 employees the realistic path is API/hosted (Together.ai, Fireworks, DeepSeek API). None of them replace Mistral Small as the volume workhorse - they complement it for the harder decisions. The detailed self-hosted comparison is covered in [Self-hosted Open-Source AI 2026: Mistral, gpt-oss, DeepSeek V4, Llama 4 in the Enterprise Stack](/en/magazine/self-hosted-open-source-ai-2026/) (separate article).

## Which model for what? The complexity distribution of agentic decisions

A typical enterprise agent decomposes into 14 to 50 micro-decisions. The complexity is not evenly distributed. In a well-instrumented HR or Finance pipeline, it follows a pattern we measure consistently:

| Decision type | Share of decisions | Complexity | Best model | Real cost per 1M tokens |
|---|---|---|---|---|
| Rule application (tax class from master data, contract type classification, threshold checks) | 50% | Low | Often no LLM needed; otherwise Mistral Small 3.2, Llama 4 Scout, gpt-oss-20b | ~0 to ~0.50 USD |
| Structured extraction (pulling fields from PDFs, normalizing tables, OCR-corrected line items) | 25% | Medium | Mistral Small 3.2, Mistral Medium 3.1, gpt-oss-120b | ~0.50 to ~2 USD |
| Contextual classification (BetrVG §87 clause review, anomaly detection in expense reports, vendor risk flags) | 15% | Medium-high | Mistral Medium 3.1, Claude Haiku 4.5, GPT-5 mini | ~1 to ~5 USD |
| Complex reasoning (cross-jurisdictional anti-discrimination check under AGG/Equality Act, multi-step argument synthesis, escalation drafting) | 8% | High | Claude Opus 4.7, GPT-5.5 | ~15 to ~25 USD |
| Multimodal (image plus text correlation, video segments, technical drawing review) | 2% | High | Gemini 3.1 Pro | ~5 to ~10 USD |

The implication is straightforward. If you route every decision through Claude Opus, you pay flagship token rates for the 75% of work that does not need flagship reasoning. If you route every decision through Mistral Small, you save token cost but fail on the 8% where Opus-class reasoning actually matters - and you pay the cost in audit findings, not in tokens.

<figure class="not-prose my-12">
<svg viewBox="0 0 800 560" xmlns="http://www.w3.org/2000/svg" role="img" aria-labelledby="routing-title routing-desc" class="w-full h-auto max-w-3xl mx-auto">
<title id="routing-title">Decision Routing Flow for Agentic Enterprise AI 2026</title>
<desc id="routing-desc">An incoming decision is classified by complexity into three tiers - RULES (50% of decisions, deterministic rule engine, no LLM), AI AUTONOMOUS (40% of decisions, routed to Mistral Small 3.2, gpt-oss-120b, or DeepSeek V4-Flash based on workload), and HUMAN (10% of decisions, prepared by Claude Opus 4.7 or GPT-5.5, signed by a human approver). All three paths emit a Decision Record into a unified audit log with GDPR Article 22 challenge button, satisfying EU AI Act Article 13 transparency requirements.</desc>
<defs>
<style>
.box { fill: #f5f5f0; stroke: #d4d0cb; stroke-width: 1.5; }
.box-dark { fill: #1a2e4d; stroke: #1a2e4d; }
.box-rules { fill: #e8f0e8; stroke: #5a8a5a; stroke-width: 1.5; }
.box-ai { fill: #e8eef5; stroke: #3a6090; stroke-width: 1.5; }
.box-human { fill: #f5e8e8; stroke: #9a5a5a; stroke-width: 1.5; }
.box-record { fill: #fcd34d; stroke: #b8941f; stroke-width: 2; }
.txt { font-family: -apple-system, system-ui, sans-serif; font-size: 14px; fill: #1a2e4d; text-anchor: middle; font-weight: 500; }
.txt-sm { font-family: -apple-system, system-ui, sans-serif; font-size: 11px; fill: #4a5568; text-anchor: middle; }
.txt-white { fill: #ffffff; }
.txt-bold { font-weight: 700; font-size: 13px; }
.arrow { fill: none; stroke: #4a5568; stroke-width: 1.5; }
.pct { font-family: -apple-system, system-ui, sans-serif; font-size: 18px; font-weight: 700; text-anchor: middle; }
</style>
<marker id="arrowhead" markerWidth="10" markerHeight="10" refX="9" refY="3" orient="auto"><polygon points="0 0, 10 3, 0 6" fill="#4a5568"/></marker>
</defs>
<rect x="300" y="10" width="200" height="48" rx="6" class="box-dark"/>
<text x="400" y="32" class="txt txt-white txt-bold">Incoming Decision</text>
<text x="400" y="48" class="txt txt-white" font-size="11">(any agentic step)</text>
<line x1="400" y1="58" x2="400" y2="88" class="arrow" marker-end="url(#arrowhead)"/>
<rect x="240" y="92" width="320" height="48" rx="6" class="box"/>
<text x="400" y="114" class="txt txt-bold">Complexity Classifier</text>
<text x="400" y="130" class="txt-sm">Decision Layer routes by type, not by model preference</text>
<line x1="400" y1="140" x2="160" y2="180" class="arrow" marker-end="url(#arrowhead)"/>
<line x1="400" y1="140" x2="400" y2="180" class="arrow" marker-end="url(#arrowhead)"/>
<line x1="400" y1="140" x2="640" y2="180" class="arrow" marker-end="url(#arrowhead)"/>
<rect x="40" y="184" width="240" height="56" rx="6" class="box-rules"/>
<text x="160" y="206" class="txt txt-bold">RULES</text>
<text x="160" y="228" class="pct" fill="#5a8a5a">~50%</text>
<rect x="40" y="252" width="240" height="92" rx="6" class="box"/>
<text x="160" y="272" class="txt txt-bold">Rule Engine (no LLM)</text>
<text x="160" y="294" class="txt-sm">Tax ID checksum, IBAN format,</text>
<text x="160" y="310" class="txt-sm">deterministic threshold checks</text>
<text x="160" y="332" class="txt-sm" font-style="italic">Cost: ~0 EUR per 1M decisions</text>
<rect x="280" y="184" width="240" height="56" rx="6" class="box-ai"/>
<text x="400" y="206" class="txt txt-bold">AI AUTONOMOUS</text>
<text x="400" y="228" class="pct" fill="#3a6090">~40%</text>
<rect x="280" y="252" width="240" height="148" rx="6" class="box"/>
<text x="400" y="272" class="txt txt-bold">Workhorse Models</text>
<text x="400" y="294" class="txt-sm">Mistral Small 3.2 (on-prem, Apache 2.0)</text>
<text x="400" y="312" class="txt-sm">gpt-oss-120b (heavy reasoning on-prem)</text>
<text x="400" y="330" class="txt-sm">DeepSeek V4-Flash (1M context)</text>
<text x="400" y="352" class="txt-sm" font-style="italic">Document extraction,</text>
<text x="400" y="368" class="txt-sm" font-style="italic">classification, structured output</text>
<text x="400" y="390" class="txt-sm" font-style="italic">Cost: ~0.50-5 USD per 1M tokens</text>
<rect x="520" y="184" width="240" height="56" rx="6" class="box-human"/>
<text x="640" y="206" class="txt txt-bold">HUMAN</text>
<text x="640" y="228" class="pct" fill="#9a5a5a">~10%</text>
<rect x="520" y="252" width="240" height="148" rx="6" class="box"/>
<text x="640" y="272" class="txt txt-bold">Reasoning + Human Sign-Off</text>
<text x="640" y="294" class="txt-sm">Claude Opus 4.7 / GPT-5.5 prepares</text>
<text x="640" y="312" class="txt-sm">analysis, human approver signs</text>
<text x="640" y="334" class="txt-sm" font-style="italic">AGG anti-discrimination (DE),</text>
<text x="640" y="350" class="txt-sm" font-style="italic">FCA SS1/23 model risk (UK),</text>
<text x="640" y="366" class="txt-sm" font-style="italic">BetrVG sec 99 co-determination</text>
<text x="640" y="390" class="txt-sm" font-style="italic">Cost: ~15-25 USD per 1M tokens</text>
<line x1="160" y1="344" x2="160" y2="420" class="arrow"/>
<line x1="160" y1="420" x2="400" y2="420" class="arrow"/>
<line x1="400" y1="400" x2="400" y2="440" class="arrow" marker-end="url(#arrowhead)"/>
<line x1="640" y1="400" x2="640" y2="420" class="arrow"/>
<line x1="640" y1="420" x2="400" y2="420" class="arrow"/>
<rect x="200" y="444" width="400" height="56" rx="6" class="box-record"/>
<text x="400" y="466" class="txt txt-bold">Decision Record</text>
<text x="400" y="486" class="txt-sm" font-style="italic">input + rule version + model + confidence + reasoning + approver</text>
<line x1="400" y1="500" x2="400" y2="528" class="arrow" marker-end="url(#arrowhead)"/>
<rect x="120" y="532" width="560" height="22" rx="4" class="box"/>
<text x="400" y="548" class="txt txt-sm">Audit log + GDPR Art. 22 challenge button → EU AI Act Art. 13 ready</text>
</svg>
<figcaption class="text-sm text-gosign-text-light text-center mt-4 max-w-2xl mx-auto">
<strong>Decision Routing Flow</strong> - the architecture pattern behind the 70/40/10 distribution. Every incoming agentic decision passes through a complexity classifier and routes to RULES (deterministic), AI AUTONOMOUS (workhorse models like Mistral Small 3.2), or HUMAN (Claude Opus 4.7 prepares, human signs). All three paths emit a Decision Record into a unified audit log - this is what an EU AI Act Article 13 auditor reads on inspection day.
</figcaption>
</figure>

[Stanford HAI's 2025 AI Index](https://hai.stanford.edu/ai-index/2025-ai-index-report) records 65.7% of newly released foundation models in 2023 were open-source, up from 33.3% in 2021. Enterprise AI adoption crossed 78%. The market is no longer choosing between proprietary and open. It is choosing how to compose them.

## Mistral Small as the workhorse: an HR onboarding agent with 14 micro-decisions

Concrete example. An HR onboarding agent receives a new hire's signed contract plus supporting documents (passport copy, tax declaration, bank details, qualification certificates). Its job: produce the personnel master record, run pre-employment compliance checks, schedule onboarding, file social security registration. Fourteen micro-decisions in total, ranging from regex validation to AGG anti-discrimination analysis.

A naive implementation sends every step to Claude Opus 4.7. A decomposed implementation routes per step. The Decision Layer holds the routing rules: every step is classified as RULES, AI AUTONOMOUS, or HUMAN before it executes.

**RULES:** The decision is deterministic. Tax ID format follows a checksum rule, IBAN follows ISO 13616. No interpretation, no model needed. Here the agent is executor, not reasoner.

**AI AUTONOMOUS:** The decision is classification or extraction with sufficient confidence. Document type detection, contract type classification, structured field extraction. A small model with a clear schema beats a flagship model with a vague prompt.

**HUMAN:** The decision touches discretion, discrimination risk, co-determination scope, or threshold violations. Anti-discrimination check under AGG (Equality Act - does this clause discriminate on age, gender, origin, religion, disability, sexual orientation?), works council notification under BetrVG sec. 99 (does this hire trigger co-determination?), salary anomaly above the agreed limit. The model prepares the case; the human signs the decision.

The following eight steps are the representative routing pattern from a typical 14-step pipeline. The full 14-step routing rules table lives in the Decision Layer configuration of the customer.

| Step | Decision | Layer | Routing target |
|---|---|---|---|
| 1 | Detect document types in the upload | AI AUTONOMOUS | Mistral Small 3.2 on-prem |
| 2 | Extract personal data (name, address, DOB, tax ID) | AI AUTONOMOUS | Mistral Small 3.2 on-prem |
| 3 | Validate tax ID format (DE ELStAM, ES NIF, BR CPF, PL PESEL) and IBAN | RULES | Rule engine, no LLM |
| 4 | Classify contract type (fixed-term, indefinite, probationary) | AI AUTONOMOUS | Mistral Small 3.2 |
| 5 | Check contract clauses against works council framework v2024-3 | AI AUTONOMOUS | Mistral Medium 3.1 (La Plateforme) |
| 6 | Anti-discrimination check (does the clause discriminate by age, gender, origin, religion, disability, sexual orientation - AGG/Equality Act) | HUMAN (prepared by AI) | Claude Opus 4.7 drafts the analysis, HR Manager signs |
| 7 | Detect salary anomalies relative to role/location/seniority | AI AUTONOMOUS | Mistral Medium 3.1 |
| 8 | Decide whether works council notification under BetrVG §99 applies | HUMAN (prepared by AI) | Mistral Medium 3.1 pre-classifies, works council liaison signs |

Of the full 14 steps, six are RULES (no LLM needed: IBAN check, document completeness checks, deterministic registration filings). Six are AI AUTONOMOUS (Mistral Small or Medium). Two are HUMAN-with-AI-preparation (Claude Opus for the anti-discrimination clause review, Mistral Medium for the works council notification pre-classification under BetrVG sec. 99).

In typical EU hosting setups, this distribution translates to roughly 1 to 3 USD per onboarding on inference. A flagship-only architecture (every step through Claude Opus) lands closer to 25 to 40 USD per onboarding - and processes step 1 and step 2 on US infrastructure under CLOUD Act exposure. Same business outcome. Different audit trail. Different cost curve. Different sovereignty position.

## What the auditor sees: Decision Records under EU AI Act Article 13

[EU AI Act Article 13](https://artificialintelligenceact.eu/article/13/) requires high-risk AI systems to operate transparently enough that deployers can interpret outputs and use them appropriately. The system must come with instructions specifying accuracy metrics, robustness, cybersecurity tested levels, human oversight measures under Article 14, and required hardware resources.

The auditor's question on inspection day is not "which model did you use" but "show me the decision record for personnel case 2026-01-1873, step 8."

A Decision Record produced by a routing layer contains, per micro-decision:

- **Input snapshot** (the relevant fields from upstream context, with PII handling applied)
- **Rule version** (which version of the works council framework was used; v2024-3)
- **Decision type** (rule application, AI classification, AI reasoning, human approval)
- **Model used** (if AI: Mistral-Small-3.1-Instruct-2503, deployed on cluster A04, region eu-de-fra)
- **Confidence score** (if AI: 0.94)
- **Reasoning chain** (if applicable: the model's intermediate reasoning, captured verbatim)
- **Outcome** (classification label, extracted value, or escalation flag)
- **Human approver** (if escalated: name, role, timestamp)
- **Challenge button** for AI decisions (the affected subject can contest an automated decision, which triggers a re-decision under human review - the mechanism required by GDPR Art. 22)

A pipeline that produces these records turns the model question into a routing question. The auditor does not ask "is Mistral as good as Claude". The auditor asks "is the decision documented end-to-end and can it be reproduced." The board question goes one step further: who signs the decision when a discriminatory employment clause (AGG/Equality Act violation) slipped past a routing target that should have escalated to a human? The routing layer makes that signature traceable.

For UK firms, the same Decision Records satisfy FCA SS1/23 model risk inventory and the challenger-model documentation requirement. For EU FS firms, they map to DORA Article 28-30 ICT third-party risk register. For customs/logistics operations, they satisfy UCC Article 22 documentation requirements for automated customs decisions.

## The architecture question: Decision Layer or vendor lock-in

A model-agnostic Decision Layer is not a feature. It is the precondition for almost everything else listed in this article. Without it, the routing patterns above are abstract.

| Without Decision Layer | With Decision Layer |
|---|---|
| The choice of model is sticky. Switching providers means re-implementing the entire agent. | Provider switching takes one configuration change. Models are interchangeable per decision step. |
| Cost optimization happens after the fact, in renegotiation with one vendor. | Cost optimization is built in: low-complexity decisions automatically route to the cheapest viable model. |
| Sovereignty is binary: either you accept US CLOUD Act exposure, or you self-host everything. | Sovereignty is per decision: sensitive steps run on EU on-prem, non-sensitive steps can use cloud APIs. |
| Audit trail exists in scattered logs and is reconstructed on demand. | Audit trail is the routing log. EU AI Act Article 13 compliance is a query, not a project. |
| Adding a new model means a new integration. | Adding a new model means adding it to the router. Routing rules already exist. |

*This table shows architectural differences, not quality judgments.*

The Decision Layer is where the model choice gets operationalized. The model market changes monthly. Prices drop. New flagships ship. Open-weight quality catches up. A Decision Layer architecture absorbs that change. A vendor-bound architecture pays the migration cost every time.

## Bottom line

The interesting question for an EU-Enterprise CTO in 2026 is not "Mistral or OpenAI." It is "what percentage of my agentic decisions need flagship reasoning, and how do I prove that to my auditor."

In a well-decomposed agent, Mistral Small 3.2 on a single EU GPU does the majority of the work for negligible per-token cost. Mistral Medium 3.1 on La Plateforme handles the middle band with EU sovereignty preserved. Claude Opus 4.7 or GPT-5.5 handle the genuinely hard cases. Routing is the architecture, and the same routing log that drives the per-decision model choice produces the compliance artifact that an Article 13 auditor accepts - the Decision Layer is where both get specified together.

Others publish model comparison tables. We build the routing layer that operationalizes them. The model market changes monthly; the routing architecture survives five model generations. Source code stays with the customer. Models stay interchangeable. EU AI Act Article 13 compliance is a property of the architecture, not a project at the end.

If you want to know what your agent's complexity distribution actually looks like, [book a consultation](/en/contact/).

---

**📘 Enterprise AI Infrastructure Blueprint 2026 - Article Series**

| ← Previous | Overview | Next → |
|:---|:---:|---:|
| [Enterprise AI Infrastructure Blueprint 2026](/en/magazine/ai-infrastructure-blueprint-2026/) | [Overview](/en/magazine/ai-infrastructure-blueprint-2026/) | [AI Hosting: EU SaaS, German Data Center, or Self-Hosted?](/en/magazine/ai-hosting-strategies-enterprise/) |

*All articles in this series: [Enterprise AI Infrastructure Blueprint 2026](/en/magazine/ai-infrastructure-blueprint-2026/)*

---

## Sources

Primary sources used in this article:

- **EU AI Act Article 13** - Transparency and provision of information to deployers. Final text, Regulation (EU) 2024/1689. [artificialintelligenceact.eu/article/13](https://artificialintelligenceact.eu/article/13/) | [EU AI Act Service Desk](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-13)
- **Mistral La Plateforme data residency** - "Where do you store my data". Mistral AI Help Center. [help.mistral.ai](https://help.mistral.ai/en/articles/347629-where-do-you-store-my-data-or-my-organization-s-data)
- **Mistral Bruyères-le-Châtel data center** - $830M debt financing, 13,800 NVIDIA GB300 GPUs, 44 MW, Q2 2026 operational. [IO+, March 2026](https://ioplus.nl/en/posts/why-mistrals-830m-raise-is-a-win-for-european-autonomy)
- **Mistral Small 3.2** - Apache 2.0, 24B parameters, 128K context, March 2025 release. [Mistral AI announcement](https://mistral.ai/news/mistral-small-3-1) | [Hugging Face model card](https://huggingface.co/mistralai/Mistral-Small-3.1-24B-Instruct-2503)
- **gpt-oss release** - 120b and 20b open-weight models under Apache 2.0, OpenAI's first since GPT-2, released August 5, 2025. [OpenAI announcement](https://openai.com/index/introducing-gpt-oss/) | [GitHub repo](https://github.com/openai/gpt-oss) | [Model card PDF](https://cdn.openai.com/pdf/419b6906-9da6-406c-a19d-1bb078ac7637/oai_gpt-oss_model_card.pdf)
- **US CLOUD Act vs EU sovereignty** - Schrems II ruling, CLOUD Act follows provider control not data location, EU Tech Sovereignty Package expected Q2 2026. [Kiteworks analysis](https://www.kiteworks.com/cybersecurity-risk-management/eu-tech-sovereignty-package-cloud-act/) | [GDPR Article 48 conflict](https://www.kiteworks.com/gdpr-compliance/eu-data-act-gdpr-cloud-conflict/)
- **Stanford HAI AI Index 2025** - Open-source model release rates, enterprise adoption metrics. [hai.stanford.edu/ai-index/2025-ai-index-report](https://hai.stanford.edu/ai-index/2025-ai-index-report) | [PDF download](https://hai.stanford.edu/assets/files/hai_ai_index_report_2025.pdf)

---

[Book a consultation](/en/contact/). We analyze your decision-complexity distribution and recommend the routing architecture that matches it.

--- Cert-Ready by Design - Audit-Proof AI from the Start ---
> Cert-Ready by Design: controls as first-class data objects, automatic evidence generation, live auditor status. Architecture for ISA and SOC 2

## The Problem: Audit Readiness as a Project

In most organizations, preparing for an audit - annual financial audit, tax audit, SOC 2 audit - is a project. Weeks before the audit, documents are compiled, screenshots are taken, evidence is exported from various systems and sorted into folders.

This approach has three problems: it is labor-intensive, it is error-prone, and it shows a snapshot rather than a state. The auditor sees what the system looked like at the time of documentation, not how it actually runs.

When AI agents make business-critical decisions, the problem intensifies. Every single agent decision must be traceable. With thousands of decisions per month, manual documentation is no longer feasible.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">At a Glance - Cert-Ready by Design</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Cert-Ready by Design means audit readiness is an architectural principle, not a retroactive documentation project.</li>
<li>Controls are first-class data objects with automatic evidence generation, rule versioning and live auditor status.</li>
<li>ISACA (2023) reports that organizations with continuous control monitoring reduce audit preparation time by up to 65%.</li>
<li>Framework mapping covers ISA, SOC 2, ISAE 3402 and GAAP/IFRS - evidence speaks the language auditors understand.</li>
<li>Result: auditing AI-supported processing takes hours instead of weeks, with complete, tamper-proof evidence.</li>
</ul>
</div>

## What Cert-Ready by Design Means

Cert-Ready by Design reverses the approach: [audit readiness](/en/governance/) is not a retroactive process but an architectural principle. Controls are technical data objects within the system. Evidence is generated automatically. Auditors see live status, not snapshots.

### Controls as First-Class Data Objects

In the Cert-Ready architecture, every control is a technical data object with defined attributes:

| Element | Function |
|---------|----------|
| Control_ID | Unique identification of the control |
| Technical_Implementation | Concrete technical implementation (e.g., RLS policy, API check, confidence threshold) |
| Rule_Version | Version of the underlying decision logic |
| Evidence_Generator | Automated verification mechanism that produces evidence |
| Evidence_History | Historicized verification results with timestamps |
| Auditor_View | Drill-down-capable view down to the implementation |

Controls are not Word documents in a SharePoint folder. They are technical objects that live within the system, are verified automatically, and reflect their status in real time.

### Automatic Evidence Generation

Evidence is not assembled after the fact. It is generated automatically, with every agent decision, with every rule change, with every system event.

An example: the agent processes an incoming invoice. The Decision Layer applies rule SKR03-7890 in version 4.2. Confidence: 97%. Result: booking proposal to account 4400, cost center 1200. No escalation (confidence above threshold, amount below value limit).

The evidence for this operation is generated automatically: input data, applied rule with version, confidence score, routing decision, result, timestamp. This evidence is immutable and linked to the booking record.

### Auditor Portal

Auditors see the live status of all controls in the Auditor Portal. No PDF export, no snapshot - the current state of the system.

The Auditor Portal offers drill-down capability: from the control overview (traffic-light dashboard: green/yellow/red) through the individual control down to the concrete technical implementation and the evidence history.

### Framework Mapping

Controls are mapped to established audit standards:

**ISA (International Standards on Auditing):** For annual financial audits. The controls represent the internal controls that the financial auditor assesses as part of the audit.

**SOC 2 / ISAE 3402:** For IT audits and third-party assurance. The technical implementations of the controls are mapped to the requirements of SOC 2 trust service criteria and ISAE 3402.

**GAAP/IFRS Compliance:** For the integrity of financial reporting. The versioning of rule sets, the immutability of the audit trail, and the traceability of every booking decision fulfill the requirements of generally accepted accounting principles.

This framework mapping ensures that automatically generated evidence speaks the language auditors understand.

## Cert-Ready in Practice

An audit firm conducts the annual financial audit for a client. The client uses AI agents for invoice processing.

The auditor opens the Auditor Portal. They see: 12 controls for invoice processing, all green. They click on control "BV-003: Completeness of booking records." They see: the technical implementation (API check against invoice intake), the current rule version, the evidence from the last 12 months (all automated verifications passed), the average confidence score, and the escalation rate.

They can drill down: spot-check individual records, trace the decision path, view the applied rule in the version that was valid at the time of the decision.

The result: auditing the IT-supported processing takes hours instead of weeks. The evidence is complete, automatically generated, and tamper-proof.

More on this: [Cert-Ready by Design in Detail](/en/governance/cert-ready/)

<a href="/en/contact/" target="_blank" rel="noopener noreferrer">Book a consultation</a> - We will show you the Auditor Portal live.

--- ChatGPT Without Login at Work: From Risk to Infrastructure ---
> Uncontrolled ChatGPT usage creates shadow AI at scale. How a GDPR-compliant, model-agnostic chat infrastructure with agent integration solves the problem.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">At a Glance - ChatGPT Without Login: Enterprise Risk</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Employees using public AI tools without IT oversight is shadow AI - prompts are processed on uncontrolled servers, potentially used for model training, with zero audit trail.</li>
<li>Banning AI does not work. The solution is a model-agnostic chat infrastructure under corporate control that is better than the public alternative.</li>
<li>Verizon DBIR (2024) found that 74% of data breaches involve a human element - uncontrolled AI usage creates an entirely new category of data exposure.</li>
<li>The real value emerges when the chat interface evolves into an agent platform - processing documents, orchestrating workflows, answering knowledge queries.</li>
<li>Three architecture decisions are due now: hosting model, model strategy, and agent roadmap. Delaying means more shadow AI exposure every day.</li>
</ul>
</div>

## The Problem Is Not ChatGPT. The Problem Is Loss of Control.

In virtually every enterprise today, employees secretly use public AI tools. With private ChatGPT accounts, via dubious websites promising "ChatGPT without login", through copy-paste into Claude.ai or Gemini - without IT's knowledge, without approval, without any governance. The barrier is zero, the productivity gain is immediate. The result: shadow IT at scale.

The risk is not theoretical. Prompts sent to public AI services are processed on servers outside enterprise control. Without an enterprise contract, input data may be used for model training. Particularly dangerous are the numerous third-party sites offering "free ChatGPT without registration": these lack even the minimal protection that a direct OpenAI account provides. Confidential information - salary data, contract drafts, strategy papers - ends up in systems over which the enterprise has no access, no deletion rights and no audit capability.

IT departments face a dilemma: banning does not work because the benefit is too obvious and employees find workarounds. Tolerating is not an option because GDPR, works councils (Betriebsrat) and internal audit will eventually ask questions.

The answer is neither prohibition nor tolerance. The answer is infrastructure.


## What Employees Actually Need - and Why They Secretly Use ChatGPT

When employees reach for ChatGPT despite a ban, it reveals one thing above all: the enterprise offers no alternative. What employees are looking for is a simple interface that works immediately, understands natural language and helps with daily work. Summarising documents, drafting emails, analysing files, answering questions about internal policies.

This requirement is legitimate. But it must be fulfilled in an environment the enterprise controls - not on servers of third-party providers advertising "ChatGPT without login" whose business model is data collection.

An enterprise chat infrastructure gives every employee exactly this interface - with one critical difference: data stays within the enterprise infrastructure. Prompts are not transmitted to third parties. Usage is logged and auditable. Access rights follow the existing role-based model. And most importantly: employees no longer need to secretly resort to external tools because they have a better, official alternative.


## Why Model-Agnostic Is the Only Sensible Approach

The most common mistake when introducing enterprise AI: making a single model from a single vendor the standard. ChatGPT Enterprise for everyone, Copilot across the board, or a fixed Claude contract.

The problem: LLMs evolve faster than any enterprise procurement cycle. What is the best model for text analysis today may be superseded by a cheaper or more capable model in six months. Anyone who builds their entire infrastructure on one vendor has vendor lock-in on the most critical technology decision of the coming years.

A model-agnostic architecture solves this: a unified chat interface for all employees. Behind it, an orchestration layer that routes between models - Claude, ChatGPT, Gemini, [Llama](https://llama.meta.com/), [Mistral](https://mistral.ai/), [DeepSeek](https://www.deepseek.com/), gpt-oss. Depending on use case, cost or data protection requirements, the appropriate model is selected automatically. Model switches happen without changes to the interface and without retraining employees.

Gosign builds this [AI infrastructure](/en/services/infrastructure/) as model-agnostic and platform-open - as a cloud deployment on Azure or GCP, or fully self-hosted in the client's own infrastructure.


## From Chat Interface to Agent Platform

A GDPR-compliant chat interface is the entry point. But the real value creation begins when the interface does not merely answer questions but initiates processes.

This is the transition from chat to agent infrastructure.

In practice: an employee uploads a sick note in the chat. A [Document Agent](/en/services/ai-agents/) reads the document, extracts relevant data, checks deadlines against the collective agreement and prepares the booking in SAP. A [Workflow Agent](/en/services/ai-agents/) orchestrates the follow-up process: notify the line manager, check for a stand-in, calculate continued pay. A Knowledge Agent answers the employee's follow-up questions based on current company policies.

The chat interface becomes the unified entry point for all three agent types. The employee sees a simple conversation. Behind the scenes, the infrastructure orchestrates document-based, workflow-based and knowledge-based agents - with a complete audit trail and [Human-in-the-Loop](/en/governance/) for critical decisions.


## Governance Is Not a Feature. Governance Is the Architecture.

Every uncontrolled ChatGPT interaction creates a blind spot: what data was entered? What responses were used for decisions? Who asked what, and when?

In an enterprise chat infrastructure with [Governance by Design](/en/governance/), these blind spots do not exist.

Every interaction is logged - prompt, response, model used, timestamp, user role. Decision-relevant actions pass through the [Decision Layer](/en/finance-ai-agents/), which separates analysis from decision-making. Critical processes require human approval, architecturally embedded as Human-in-the-Loop.

For works councils (Betriebsrat): transparency over AI usage in the enterprise, documented and auditable at any time. For internal audit: a complete audit trail. For data protection officers: data processing in a controlled environment, no transmission to third parties, GDPR-compliant documentation.


## Risk Assessment: Public AI vs. Enterprise Infrastructure

| Risk Category | Public ChatGPT / Third-Party Sites | Enterprise Chat Infrastructure |
|---|---|---|
| Data sovereignty | No control - data on external servers | Full control - self-hosted or EU cloud |
| Model training | Data may be used for training | No training on corporate data |
| Audit trail | None | Complete - prompt, response, user, model |
| GDPR compliance | Not guaranteed | Enforced by architecture |
| Access control | Personal accounts, no RBAC | SSO with role-based access |
| Agent integration | Not possible | Document, Workflow, Knowledge agents |
| Vendor lock-in | Tied to single provider | Model-agnostic - swap models without retraining |

## What IT Departments Need to Decide Now

The question is no longer whether employees use AI. The question is whether they do so in a controlled or uncontrolled environment.

Three architecture decisions are due.

First: hosting. Should the chat infrastructure run on Azure, GCP or fully self-hosted? The answer depends on the existing IT landscape and data protection requirements. All three options are technically equivalent - there are no architectural compromises with self-hosting.

Second: model strategy. Which models should be available and how is routing governed? A model-agnostic architecture keeps all options open and avoids vendor lock-in.

Third: agent roadmap. Should the chat interface eventually connect agents that process documents and orchestrate workflows? If so - and the answer is almost always yes - then the infrastructure must be designed for this from the start.

At Gosign, we build precisely this infrastructure: model-agnostic, GDPR-compliant, with agent integration and Governance by Design. From concept to productive chat interface in 4 - 6 weeks. In the [client's infrastructure](/en/services/infrastructure/), under full client control. No SaaS, no vendor lock-in.

--- Claude Code as a Security Control in the DevOps Workflow ---
> DevOps runbook for automated security reviews with Claude Code: installation, custom commands, audit scripts, and CI integration.

Modern self-hosted app stacks consist of many components: Supabase platform, Next.js app layer, Edge Functions, background jobs, and external APIs. With each component, the likelihood of configuration errors, secret leaks, missing policies, and unsecured endpoints increases.

Traditional security scanners check static rules. They find `service_role` in an `.env` file, but they do not recognize that a new Server Action is missing the same ownership check that exists in all other Server Actions. They report open ports, but they do not recognize that a firewall change last week, combined with a new container, opened an unintended access path.

**Claude Code closes this gap as a contextual analysis layer across the entire stack.**

Claude Code does not replace deterministic checks. It supplements them by interpreting results, identifying connections, and prioritizing recommendations.

This runbook describes how Claude Code is concretely installed, configured, and integrated into the DevOps workflow.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">At a Glance - Part 5 of 6 in the DevOps Runbook Series</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Claude Code runs exclusively on the audit server (never on production)</li>
<li>Three-layer model: deterministic checks, runbook rules, Claude contextual analysis</li>
<li>Custom commands in .claude/commands/ define the review scope</li>
<li>Headless mode with --allowedTools restricted to Read, Grep, Glob (no Bash)</li>
<li>Weekly cron audit plus ad-hoc reviews on pull requests</li>
</ul>
</div>

## Series Table of Contents

This guide is part of our DevOps runbook series for self-hosted app stacks.

1. [Supabase Self-Hosting Runbook](/en/magazine/supabase-self-hosting/)
2. [Running Next.js on Supabase Securely](/en/magazine/nextjs-supabase-secure-setup/)
3. [Deploying Supabase Edge Functions Securely](/en/magazine/supabase-edge-functions-secure/)
4. [Running Trigger.dev Background Jobs Securely](/en/magazine/trigger-dev-background-jobs/)
5. [Claude Code as a Security Control in the DevOps Workflow](/en/magazine/claude-code-security-devops/) - this article
6. [Security Baseline for the Entire Stack](/en/magazine/security-baseline-stack/)

The first four articles describe the individual components. This article describes the **security control layer on top of them**.

## Architecture Overview

Claude Code does **not run on the production server** but on the audit server (see [Article 1](/en/magazine/supabase-self-hosting/)). It has read-only access to the data it analyzes.

```
Production Server (supabase-prod)
   |
   +-- Supabase Stack
   +-- Next.js App
   +-- Edge Functions
   +-- Trigger.dev
   |
   +---- SSH (read-only) ----> Audit Server (audit-runner)
                                   |
                                   +-- Deterministic Checks
                                   |   +-- Port Scans (nmap)
                                   |   +-- Firewall Diff (iptables-save)
                                   |   +-- Container Versions (docker images)
                                   |   +-- RLS Status (psql)
                                   |   +-- npm audit
                                   |   +-- grep-based Code Checks
                                   |
                                   +-- Claude Code (headless)
                                   |   +-- Analyzes check results
                                   |   +-- Reads Git diffs
                                   |   +-- Validates configs against runbooks
                                   |   +-- Creates prioritized report
                                   |
                                   +-- Report -> DevOps Team (human decides)
```

**Claude Code does not execute changes on the production system. No deployments, no secret rotation, no container stops.**

## Core Principle: Three Layers of Security Review

```
Layer 1: Deterministic Checks (Scripts)
   -> Objective, repeatable results
   -> Example: "Port 5432 is reachable from outside" = fact

Layer 2: Runbook Rules (Markdown files)
   -> Defined target state of the stack
   -> Example: "Postgres must only listen on 10.0.1.10"

Layer 3: Claude Code Contextual Analysis (headless)
   -> Interprets results, identifies connections
   -> Example: "Port 5432 is open AND the new container
     has a direct DB connection. This is a problem."
```

The layers build on each other. Claude receives the results from Layer 1 and the rules from Layer 2 as input and creates its contextual review from them.

Research shows that contextual code reviews identify up to 31% more security issues than purely rule-based scanners (GitHub Security Lab 2024).

### Comparison: Three Layers of Security Review

| Property | Deterministic Checks | Runbook Rules | Claude Code Analysis |
|----------|---------------------|---------------|---------------------|
| Execution | Automated (scripts) | Reference document | Headless mode (CLI) |
| Result | Fact (yes/no) | Desired state | Interpretation + priority |
| Frequency | Daily | Static (on change) | Weekly / on PR |
| Strength | Reliable for known patterns | Defined standards | Detects unknown patterns |
| Weakness | Cannot see relationships | Not self-checking | Non-deterministic |
| Example | "Port 5432 open" | "Postgres only on 10.0.1.10" | "Port open AND new container = problem" |

## Part A - Setting Up Claude Code

## A1 - Installation and Configuration on the Audit Server

### Implementation

Claude Code is installed on the audit server, not on the production server.

```bash
# Auf dem audit-runner Server

# Node.js installieren (falls nicht vorhanden)
curl -fsSL https://deb.nodesource.com/setup_20.x | sudo bash -
apt-get install -y nodejs

# Claude Code installieren
npm install -g @anthropic-ai/claude-code

# API Key konfigurieren
# Eigener API Key mit Budget-Limit für CI/CD
export ANTHROPIC_API_KEY="sk-ant-..."

# In .bashrc oder .env für den audit-user persistieren
echo 'export ANTHROPIC_API_KEY="sk-ant-..."' >> /home/audit/.bashrc
```

**Testing headless mode:**

```bash
# Einfacher Test: funktioniert Claude Code non-interaktiv?
echo "Hello" | claude -p "Antworte mit OK wenn du das lesen kannst" \
  --output-format text

# Erwartung: "OK" oder ähnliche Bestätigung
```

### Verifiable Condition

```bash
# Claude Code installiert?
claude --version
# Erwartung: Versionsnummer

# API Key gesetzt?
test -n "$ANTHROPIC_API_KEY" && echo "OK" || echo "FEHLT"

# Headless Mode funktioniert?
claude -p "Sage nur: OK" --output-format text --max-turns 1 2>/dev/null
# Erwartung: "OK"
```

### Failure Scenario

If Claude Code runs on the production server and has Bash access there, a faulty prompt could theoretically execute commands on the production system. On the audit server, Claude Code only has access to the collected reports and config copies, not to the live system.

## A2 - Setting Up a Custom Security Review Command

### Implementation

Claude Code supports custom commands via Markdown files in `.claude/commands/`. These commands define the context and the review rules for the security review.

```bash
# Im Infrastruktur-Repository
mkdir -p .claude/commands
```

```markdown
# .claude/commands/security-review.md

Du bist Security Reviewer für einen self-hosted Stack bestehend aus:
- Supabase (PostgreSQL, PostgREST, GoTrue, Kong, Edge Functions)
- Next.js (App-Schicht, Server Actions, Route Handler)
- Trigger.dev v3 (Background Jobs, self-hosted)
- All on EU-based infrastructure (e.g. Hetzner, OVH)

Du erhältst den Output der deterministischen Security Checks und die
aktuellen Konfigurationsdateien.

Prüfe folgendes:

## Infrastruktur (Artikel 1)
- Sind unerwartete Ports von aussen erreichbar?
- Hat sich die Firewall gegenüber der Baseline geändert?
- Sind Container-Versionen gepinnt und aktuell?
- Ist das TLS-Zertifikat noch mindestens 14 Tage gültig?
- Liegt das letzte Backup weniger als 26 Stunden zurück?

## Next.js (Artikel 2)
- Taucht service_role in NEXT_PUBLIC Variablen oder im Client-Bundle auf?
- Haben alle Server Actions einen getUser() Auth Check?
- Haben alle Route Handler einen getUser() Auth Check?
- Existiert middleware.ts mit getUser() (nicht getSession())?
- Sind Security Headers in next.config.js gesetzt?

## Edge Functions (Artikel 3)
- Haben alle Webhook-Functions eine Signaturprüfung?
- Gibt es Functions mit Business-Logik statt Integrations-Logik?
- Ist CORS korrekt konfiguriert (kein Wildcard in Produktion)?
- Gibt es hardcoded Secrets im Function-Code?

## Trigger.dev (Artikel 4)
- Haben alle Tasks maxDuration und concurrencyLimit?
- Haben Tasks mit externen API-Calls Idempotency Keys?
- Nutzen Tasks nur die DB-Felder die sie brauchen (kein SELECT *)?
- Gibt es console.log statt dem Trigger.dev logger?

## Stackübergreifend
- Gibt es Architektur-Drift? (Business-Logik in Edge Functions,
  Langläufer in Server Actions, etc.)
- Sind die Änderungen der letzten Woche konsistent mit der
  bestehenden Architektur?
- Gibt es neue Tabellen ohne RLS?
- Gibt es Muster die auf systematische Probleme hindeuten?

Erstelle einen priorisierten Bericht:
- KRITISCH: sofort handeln (Daten-Leak möglich, Port offen, Secret exponiert)
- WARNUNG: diese Woche lösen (fehlende Checks, Drift, veraltete Packages)
- INFO: bei Gelegenheit verbessern (Code-Qualität, fehlende Tests)

Für jedes Finding: Was ist das Problem, warum ist es ein Risiko,
was ist die konkrete Lösung.
```

### Verifiable Condition

```bash
# Custom Command existiert?
test -f .claude/commands/security-review.md && echo "OK" || echo "FEHLT"

# Command wird von Claude Code erkannt?
claude -p "/security-review" --max-turns 1 2>/dev/null | head -5
# Erwartung: Claude beginnt mit der Analyse
```

## A3 - CLAUDE.md as Project Context

### Implementation

Claude Code automatically reads the `CLAUDE.md` file in the project directory. This file gives Claude the permanent context about your stack.

```markdown
# CLAUDE.md (im Root des Infrastruktur-Repos)

## Stack-Überblick
Self-hosted Supabase + Next.js + Edge Functions + Trigger.dev v3
on EU-based infrastructure (e.g. Hetzner, OVH).

## Server
- supabase-prod: 10.0.1.10 (Supabase, Next.js, Edge Functions)
- audit-runner: 10.0.1.11 (Security Checks, Claude Code, Monitoring)
- trigger-server: separater Docker-Stack für Trigger.dev v3

## Sicherheitsregeln
- service_role Key darf NUR in: lib/supabase/admin.ts und trigger/lib/supabase.ts
- NEXT_PUBLIC_* darf NUR enthalten: SUPABASE_URL und SUPABASE_ANON_KEY
- Alle public-Tabellen müssen RLS aktiviert haben
- Alle Server Actions und Route Handler müssen getUser() aufrufen
- Alle Webhook Edge Functions müssen Signaturen prüfen
- Alle Trigger.dev Tasks müssen maxDuration und concurrencyLimit haben
- PostgreSQL nur auf 10.0.1.10:5432 (internes Interface)
- Supabase Studio nicht von aussen erreichbar
- Trigger.dev Dashboard nicht von aussen erreichbar

## Deployment
- Infrastruktur wird nur über Git deployed (kein manuelles SSH-Editing)
- Edge Functions werden als Dateien in volumes/functions/ abgelegt
- Trigger.dev Tasks werden über npx trigger.dev deploy --self-hosted deployed

## Verzeichnisstruktur
- app/ = Next.js App (Server Actions, Route Handler, Pages)
- lib/supabase/ = Supabase Client Konfiguration
- middleware.ts = Auth Middleware
- volumes/functions/ = Supabase Edge Functions
- trigger/tasks/ = Trigger.dev Tasks
- infra/ = docker-compose, nginx/caddy, Firewall Configs
- scripts/ = Audit Scripts, Backup, Restore
- runbooks/ = Sicherheits-Runbooks
```

Combining the [CLAUDE.md approach with the security rules from Article 2](/en/magazine/nextjs-supabase-secure-setup/) creates a seamless context base for automated reviews.

## Part B - The Full Audit Workflow

This is where everything the Articles 1 through 4 prepared comes together - from the [Supabase infrastructure checks](/en/magazine/supabase-self-hosting/) to the [Trigger.dev task audits](/en/magazine/trigger-dev-background-jobs/). Each article has its own check scripts. Article 5 combines them and passes the output to Claude Code.

## B1 - The Full Audit Script

### Implementation

This script collects all results from the deterministic checks and passes them to Claude Code in headless mode.

```bash
#!/bin/bash
# scripts/full-security-audit.sh
# Läuft auf dem audit-runner Server

set -euo pipefail

PROD_HOST="10.0.1.10"
REPORT_DIR="/opt/audit/reports"
DATE=$(date +%Y-%m-%d)
REPORT_FILE="${REPORT_DIR}/audit-input-${DATE}.md"

mkdir -p "$REPORT_DIR"

echo "=== Gesamt-Security-Audit ${DATE} ===" | tee "$REPORT_FILE"

# -------------------------------------------
# EBENE 1: Deterministische Checks
# -------------------------------------------

echo -e "\n# Deterministische Check-Ergebnisse\n" >> "$REPORT_FILE"

# --- Infrastruktur (Artikel 1) ---
echo "## Infrastruktur" >> "$REPORT_FILE"

echo "### Offene Ports (extern)" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
nmap -p 22,80,443,3000,3040,5432,5433,8000,9000 app.example.com \
  --open -oG - 2>/dev/null >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"

echo "### Firewall Diff gegen Baseline" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "iptables-save" | \
  diff /opt/baselines/firewall-baseline.txt - >> "$REPORT_FILE" 2>&1 || true
echo '```' >> "$REPORT_FILE"

echo "### Container Status" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "docker compose ps --format 'table {{.Name}}\t{{.Status}}\t{{.Image}}'" \
  >> "$REPORT_FILE" 2>&1
echo '```' >> "$REPORT_FILE"

echo "### TLS Zertifikat" >> "$REPORT_FILE"
CERT_EXPIRY=$(echo | openssl s_client -connect app.example.com:443 2>/dev/null | \
  openssl x509 -noout -enddate 2>/dev/null | cut -d= -f2)
CERT_EPOCH=$(date -d "$CERT_EXPIRY" +%s 2>/dev/null || echo 0)
NOW_EPOCH=$(date +%s)
DAYS_LEFT=$(( (CERT_EPOCH - NOW_EPOCH) / 86400 ))
echo "Ablauf: ${CERT_EXPIRY} (${DAYS_LEFT} Tage)" >> "$REPORT_FILE"

echo "### Backup Status" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "ls -lh /opt/backups/*.gpg 2>/dev/null | tail -3" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"

echo "### RLS Status" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "docker compose exec -T postgres psql -U postgres -c \
  \"SELECT tablename, rowsecurity FROM pg_tables WHERE schemaname = 'public' ORDER BY tablename;\"" \
  >> "$REPORT_FILE" 2>&1
echo '```' >> "$REPORT_FILE"

echo "### Disk Usage" >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "df -h / | tail -1" >> "$REPORT_FILE"

# --- Next.js (Artikel 2) ---
echo -e "\n## Next.js App-Schicht" >> "$REPORT_FILE"

echo "### service_role im Client Code" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "cd /opt/app && grep -rn 'SERVICE_ROLE\|service_role' app/ \
  --include='*.ts' --include='*.tsx' | grep -v 'lib/supabase/admin.ts' | grep -v node_modules" \
  >> "$REPORT_FILE" 2>&1 || echo "Keine Treffer" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"

echo "### NEXT_PUBLIC mit Secrets" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "cd /opt/app && grep 'NEXT_PUBLIC_' .env* 2>/dev/null | \
  grep -iE 'service_role|secret|private|database'" \
  >> "$REPORT_FILE" 2>&1 || echo "Keine Treffer" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"

echo "### Server Actions ohne Auth" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "cd /opt/app && for file in \$(grep -rl \"'use server'\" app/ --include='*.ts'); do
  if ! grep -q 'getUser' \"\$file\"; then
    echo \"WARNUNG: \$file\"
  fi
done" >> "$REPORT_FILE" 2>&1 || echo "Keine Treffer" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"

echo "### Route Handler ohne Auth" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "cd /opt/app && for file in \$(find app/api -name 'route.ts' 2>/dev/null); do
  if ! grep -q 'getUser' \"\$file\"; then
    echo \"WARNUNG: \$file\"
  fi
done" >> "$REPORT_FILE" 2>&1 || echo "Keine Treffer" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"

echo "### npm audit" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "cd /opt/app && npm audit --audit-level=high 2>&1 | tail -20" \
  >> "$REPORT_FILE" 2>&1
echo '```' >> "$REPORT_FILE"

# --- Edge Functions (Artikel 3) ---
echo -e "\n## Edge Functions" >> "$REPORT_FILE"

echo "### Webhook Functions ohne Signaturprüfung" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "for dir in /opt/supabase/volumes/functions/*-webhook/; do
  [ -d \"\$dir\" ] || continue
  name=\$(basename \"\$dir\")
  if ! grep -qE 'signature|verify|hmac|crypto' \"\$dir/index.ts\" 2>/dev/null; then
    echo \"KRITISCH: \$name hat keine Signaturprüfung\"
  else
    echo \"OK: \$name\"
  fi
done" >> "$REPORT_FILE" 2>&1
echo '```' >> "$REPORT_FILE"

echo "### Hardcoded Secrets in Functions" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "grep -rn 'sk_live\|sk_test\|whsec_\|Bearer ey' \
  /opt/supabase/volumes/functions/ --include='*.ts' 2>/dev/null" \
  >> "$REPORT_FILE" 2>&1 || echo "Keine Treffer" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"

# --- Trigger.dev (Artikel 4) ---
echo -e "\n## Trigger.dev Tasks" >> "$REPORT_FILE"

echo "### Tasks ohne maxDuration" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "cd /opt/app && for file in trigger/tasks/*.ts; do
  name=\$(basename \"\$file\" .ts)
  if ! grep -q 'maxDuration' \"\$file\" 2>/dev/null; then
    echo \"WARNUNG: \$name\"
  fi
done" >> "$REPORT_FILE" 2>&1
echo '```' >> "$REPORT_FILE"

echo "### Tasks ohne Concurrency Limit" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "cd /opt/app && for file in trigger/tasks/*.ts; do
  name=\$(basename \"\$file\" .ts)
  if ! grep -qE 'concurrencyLimit|queue:' \"\$file\" 2>/dev/null; then
    echo \"WARNUNG: \$name\"
  fi
done" >> "$REPORT_FILE" 2>&1
echo '```' >> "$REPORT_FILE"

# --- Git Änderungen ---
echo -e "\n## Code-Änderungen (letzte 7 Tage)" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "cd /opt/app && git log --oneline --since='7 days ago'" \
  >> "$REPORT_FILE" 2>&1
ssh deploy@${PROD_HOST} "cd /opt/app && git diff HEAD~10 --stat 2>/dev/null" \
  >> "$REPORT_FILE" 2>&1
echo '```' >> "$REPORT_FILE"

# -------------------------------------------
# EBENE 2: Runbook-Regeln (als Kontext)
# -------------------------------------------

echo -e "\n# Aktive Runbook-Regeln\n" >> "$REPORT_FILE"
cat runbooks/security-baseline.md >> "$REPORT_FILE" 2>/dev/null || \
  echo "security-baseline.md nicht gefunden" >> "$REPORT_FILE"

# -------------------------------------------
# EBENE 3: Claude Code Analyse
# -------------------------------------------

echo ""
echo "=== Deterministische Checks abgeschlossen ==="
echo "=== Starte Claude Code Analyse ==="
echo ""

# Claude Code im Headless Mode aufrufen
# --allowedTools einschränken: nur Lesen, kein Bash, kein Schreiben
CLAUDE_OUTPUT=$(cat "$REPORT_FILE" | claude -p \
  "Du erhältst den vollständigen Security-Audit-Report unseres self-hosted Stacks.
Analysiere ihn gemäss den Regeln in .claude/commands/security-review.md.
Erstelle einen priorisierten Bericht mit KRITISCH / WARNUNG / INFO.
Für jedes Finding: Problem, Risiko, konkrete Lösung." \
  --allowedTools "Read,Grep,Glob" \
  --append-system-prompt "Du bist ein Senior Security Engineer. Antworte auf Deutsch. Sei konkret und priorisiere strikt." \
  --output-format text \
  --max-turns 5 \
  2>/dev/null)

# Report speichern
CLAUDE_REPORT="${REPORT_DIR}/claude-review-${DATE}.md"
echo "$CLAUDE_OUTPUT" > "$CLAUDE_REPORT"

echo ""
echo "=== Claude Code Review abgeschlossen ==="
echo "Report: $CLAUDE_REPORT"

# Bei kritischen Findings: Alert
if echo "$CLAUDE_OUTPUT" | grep -qi "KRITISCH"; then
  echo "$CLAUDE_OUTPUT" | mail -s "KRITISCH: Security Review ${DATE}" ops@example.com
  echo "Alert gesendet an ops@example.com"
fi
```

### Verifiable Condition

```bash
# Script ausführbar?
test -x scripts/full-security-audit.sh && echo "OK" || echo "NICHT AUSFÜHRBAR"

# Letzter Audit-Report vorhanden?
ls -la /opt/audit/reports/claude-review-$(date +%Y-%m-%d).md 2>/dev/null
# Erwartung: Datei von heute

# Report enthält die erwarteten Sektionen?
grep -c "KRITISCH\|WARNUNG\|INFO" /opt/audit/reports/claude-review-$(date +%Y-%m-%d).md
# Erwartung: mindestens 1
```

## B2 - When the Audit Runs

### Three Trigger Points

```
1. Weekly Cron (Sunday 6:00 AM)
   -> Full audit across the entire stack
   -> Result: Prioritized report for the week

2. On Pull Requests (CI/CD)
   -> Only the changed files
   -> Result: Review comment on the PR

3. Ad-hoc (manual)
   -> After incidents, major deployments, infrastructure changes
   -> Result: Immediate analysis
```

**Weekly cron:**

```bash
# crontab auf dem audit-runner
0 6 * * 0 /opt/audit/scripts/full-security-audit.sh >> /var/log/security-audit.log 2>&1
```

**PR review (piping Git diff to Claude):**

```bash
#!/bin/bash
# scripts/pr-security-review.sh
# Wird vom CI bei jedem PR aufgerufen

DIFF=$(git diff origin/main...HEAD)

if [ -z "$DIFF" ]; then
  echo "Kein Diff, kein Review nötig"
  exit 0
fi

echo "$DIFF" | claude -p \
  "Review diesen Git Diff auf Sicherheitsprobleme.
Prüfe insbesondere:
- service_role Nutzung in Client-Code
- Server Actions ohne Auth Check
- Edge Functions ohne Signaturprüfung
- Trigger.dev Tasks ohne maxDuration
- Hardcoded Secrets
- Neue API Endpoints ohne Rate Limiting

Antworte NUR wenn du ein konkretes Problem findest.
Wenn alles in Ordnung ist, sage: Keine Sicherheitsprobleme gefunden." \
  --allowedTools "Read,Grep,Glob" \
  --output-format text \
  --max-turns 3
```

**Ad-hoc review:**

```bash
# Manuell nach einem Incident
cd /opt/infra-repo
claude -p "Prüfe den aktuellen Zustand des Repositories auf Sicherheitsprobleme. \
Fokus auf die letzten 5 Commits." \
  --allowedTools "Read,Grep,Glob,Bash(git log*),Bash(git diff*)" \
  --max-turns 10
```

### Verifiable Condition

```bash
# Cron Job aktiv?
crontab -l | grep "full-security-audit"
# Erwartung: Eintrag vorhanden

# Letzter Audit weniger als 8 Tage her?
LAST_REPORT=$(ls -t /opt/audit/reports/claude-review-*.md 2>/dev/null | head -1)
if [ -n "$LAST_REPORT" ]; then
  AGE=$(( ($(date +%s) - $(stat -c %Y "$LAST_REPORT")) / 86400 ))
  echo "Letzter Report: $AGE Tage alt"
  [ "$AGE" -gt 8 ] && echo "WARNUNG: Audit überfällig"
fi
```

## Part C - What Claude Can and Cannot Do

## C1 - Where Claude Code Excels

Claude identifies connections that deterministic checks cannot see:

**Detecting architecture drift:**
The deterministic checks find that a new Edge Function exists. Claude recognizes that this function contains business logic that belongs in [Next.js](/en/magazine/nextjs-supabase-secure-setup/) because it processes user input and transforms data rather than receiving an external event.

**Patterns across file boundaries:**
A `grep` finds that `getUser()` is missing in a Server Action. Claude recognizes that this action is the only one of 15 actions missing the check, and that it was added last week in a commit that also changed three other files, all of which are correct. This points to an oversight, not a systematic problem.

**Prioritization:**
The deterministic checks produce a flat list of 30 findings. Claude groups them: "The 5 service-role findings are all in the admin library and correct. The 2 missing auth checks in the route handlers are the real risk because they affect public API endpoints."

**Configuration context:**
A port scan shows that port 8000 is open. Claude knows from the stack context (CLAUDE.md) that port 8000 is the internal Kong port and checks whether it should only be listening on localhost.

## C2 - What Claude Code Cannot Do and Must Not Do

**Claude cannot actively scan.** It cannot perform network scans, check running processes, or test ports from outside. The deterministic tools do that (nmap, ss, docker ps). Claude analyzes their output.

**Claude must not write to production.** The `--allowedTools` restriction in headless mode ensures that Claude can only read:

```bash
# RICHTIG: Nur Lese-Tools erlaubt
claude -p "..." --allowedTools "Read,Grep,Glob"

# FALSCH: Bash erlaubt = Claude kann beliebige Befehle ausführen
claude -p "..." --allowedTools "Read,Grep,Glob,Bash"
```

When Bash is needed (e.g., for `git log`), only allow specific commands:

```bash
--allowedTools "Read,Grep,Glob,Bash(git log*),Bash(git diff*)"
```

**Claude is not deterministic.** The same input can produce slightly different reports. That is why Claude does not replace deterministic checks. It interprets their results.

**Claude does not know real-time data.** It works with the snapshots provided at the time of the audit. Between the audit and reading the review, the state may have changed.

## C3 - Security Rules for Claude Code in CI

```bash
# Auf dem Audit-Server: Claude Code Konfiguration

# 1. Eigener API Key mit Budget-Limit
#    Separater Key, nicht der Entwickler-Key
#    Budget: max. 50 USD/Monat für CI Reviews

# 2. --allowedTools immer einschränken
#    Niemals unbeschränkten Bash-Zugriff in automatisierten Scripts

# 3. --max-turns begrenzen
#    Verhindert Endlosschleifen bei verwirrenden Inputs
#    Empfehlung: 3-5 für PR Reviews, 5-10 für Full Audits

# 4. Output immer in Datei speichern
#    Nicht nur auf stdout, damit der Report nachvollziehbar bleibt

# 5. Claude Code hat keinen SSH-Zugriff auf Produktion
#    Die deterministischen Scripts sammeln die Daten
#    Claude bekommt nur den Text-Output zur Analyse
```

## Deployment Checklist

```
Installation
  [ ] Claude Code installed on audit-runner
  [ ] API key configured (separate CI key with budget limit)
  [ ] Headless mode works (test with claude -p)

Configuration
  [ ] .claude/commands/security-review.md created
  [ ] CLAUDE.md present in the infrastructure repo
  [ ] --allowedTools restricted to Read,Grep,Glob
  [ ] --max-turns limited to 5-10

Automation
  [ ] Full audit script present and executable
  [ ] Weekly cron job active
  [ ] PR review script integrated in CI
  [ ] Alert on critical findings configured

Security
  [ ] Claude Code runs ONLY on the audit-runner
  [ ] Claude Code has NO SSH access to production
  [ ] No unrestricted Bash access in --allowedTools
  [ ] Reports are saved and archived
  [ ] Budget limit set on the API key
```

## Conclusion

Claude Code is not an automatic security scanner and not a replacement for deterministic checks. It is a **contextual analyst** that interprets the results of scanners and grep checks, identifies connections, and prioritizes recommendations.

The workflow is always the same: deterministic tools collect facts, Claude Code interprets them, a human decides. This works because each layer does what it does best. Scripts are reliable with known patterns. Claude identifies unknown patterns. Humans make decisions.

The combination of the check scripts from Articles 1-4, the custom security review command, and the weekly audit cron creates a security control that uncovers both known and unexpected risks.

Those who pursue these principles together with a [Cert-Ready-by-Design architecture](/en/magazine/cert-ready-by-design/) build verifiable security instead of retroactive audits.

<div class="not-prose my-12 border border-gosign-border bg-gosign-light rounded-card p-6 lg:p-8">
<div class="flex items-start gap-4">
<div class="flex-shrink-0 w-12 h-12 bg-gosign-dark rounded-card flex items-center justify-center">
<svg width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="white" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 15v4a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2v-4"/><polyline points="7 10 12 15 17 10"/><line x1="12" y1="15" x2="12" y2="3"/></svg>
</div>
<div>
<h2 class="text-h3 font-bold text-gosign-dark mb-2" id="series-audit-checklists">Series Audit Checklists</h2>
<p class="text-body text-gosign-text mb-4">Prepared prompts for Claude Code. Each checklist automatically verifies the security points from its respective runbook and reports PASS, WARNING, or CRITICAL.</p>
<div class="flex flex-wrap gap-3">
<a href="/downloads/claude-check-artikel-1-supabase-en.md" download class="inline-flex items-center px-4 py-2 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-sm">Supabase Infrastructure</a>
<a href="/downloads/claude-check-artikel-2-nextjs-en.md" download class="inline-flex items-center px-4 py-2 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-sm">Next.js Security</a>
<a href="/downloads/claude-check-artikel-3-edge-functions-en.md" download class="inline-flex items-center px-4 py-2 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-sm">Edge Functions</a>
<a href="/downloads/claude-check-artikel-4-trigger-dev-en.md" download class="inline-flex items-center px-4 py-2 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-sm">Trigger.dev</a>
</div>
</div>
</div>
</div>

## Series Table of Contents

1. [Supabase Self-Hosting Runbook](/en/magazine/supabase-self-hosting/)
2. [Running Next.js on Supabase Securely](/en/magazine/nextjs-supabase-secure-setup/)
3. [Deploying Supabase Edge Functions Securely](/en/magazine/supabase-edge-functions-secure/)
4. [Running Trigger.dev Background Jobs Securely](/en/magazine/trigger-dev-background-jobs/)
5. [Claude Code as a Security Control in the DevOps Workflow](/en/magazine/claude-code-security-devops/) - this article
6. [Security Baseline for the Entire Stack](/en/magazine/security-baseline-stack/)

The next and final article describes the [Security Baseline for the full stack](/en/magazine/security-baseline-stack/), which consolidates all rules from Articles 1-5 into a single verifiable YAML file.

--- Data Security in Enterprise AI: Residency and GDPR ---
> Data security in enterprise AI: Data Residency, EU-only processing, Row-Level Security, tenant isolation. Architecture decisions for CISOs and DPOs.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">At a Glance - Data Security in Enterprise AI</p>
<ul class="text-body text-gosign-text space-y-2">
<li>The first question for every CISO and DPO: where is the data processed, who has access, and how long is it stored? With public AI tools, the answer is unacceptable for regulated organizations.</li>
<li>Three deployment models: self-hosted (no data leaves the network), EU-only cloud (processing in EU data centers), or hybrid (sensitive data self-hosted, non-critical via cloud).</li>
<li>IBM Cost of a Data Breach Report (2024) found the average cost of a data breach reached USD 4.88 million - the highest ever recorded.</li>
<li>Tenant isolation through Row-Level Security, workspace separation, and prompt isolation is business-critical for audit firms, tax advisors, and shared service centers.</li>
<li>Data security in enterprise AI is an architecture decision, not a policy question - the right infrastructure makes compliance verifiable rather than promissory.</li>
</ul>
</div>

## The Central Question: Where Is the Data?

When an AI agent reads an invoice, processes a sick leave notification, or answers a compliance question, it processes organizational data. Invoice data, personnel data, trade secrets. The first question every CISO and DPO asks: Where is this data processed? Who has access? How long is it stored?

When using ChatGPT, Gemini, or Copilot, the answer is: Data is transmitted to external servers, processed by a third-party provider, and potentially used for training purposes. For regulated organizations, that is not an acceptable answer.

## Three Deployment Models

The Gosign architecture supports three deployment models. The choice depends on the protection requirements of the data.

**Self-Hosted:** All components - models, agents, databases - run in the customer's own infrastructure. No data leaves the corporate network. This includes the language models: open-source models such as [Llama](https://llama.meta.com/), [Mistral](https://mistral.ai/), [DeepSeek](https://www.deepseek.com/), or gpt-oss can be operated locally.

**Cloud (EU-only):** Processing in EU data centers on Azure, GCP, or AWS. Data Processing Agreements, Standard Contractual Clauses. The models are cloud models (Claude, ChatGPT, Gemini), but processing remains within the EU.

**Hybrid:** Sensitive data (personnel data, financial data) is processed self-hosted. Non-critical data can run through cloud models. Routing between self-hosted and cloud is rule-based and automatic.

## Data Residency in Detail

Data Residency goes beyond the location of the servers. It encompasses:

**Processing location:** Where is the language model executed? For self-hosted: in the organization's own data center. For cloud: in a defined EU data center.

**Storage location:** Where is the processed data stored? Audit trails, decision records, documents. All in the same region as the processing.

**Transit path:** How does data reach the model and return? For self-hosted: internal network. For cloud: encrypted connection to the EU data center. No transit through third countries.

**Backups:** Where are backups stored? Backups must meet the same Data Residency requirements as the primary data.

## Tenant Isolation

For audit firms, tax advisory practices, and shared service centers, tenant isolation is business-critical. Data from one tenant must not be visible to other tenants - including to the AI system itself.

Isolation is implemented in multiple layers:

**Workspace separation:** Each tenant has its own workspace with separate API keys, separate document storage, and separate model configurations.

**Row-Level Security:** At the database level, Row-Level Security ensures that queries only return data belonging to the current tenant. Even if an agent inadvertently issues a cross-tenant query, the database returns only results for the authorized tenant.

**Prompt isolation:** Prompts and rule sets are tenant-specific. One tenant's agent has no access to prompts or rule sets of other tenants.

## GDPR Compliance

The GDPR (General Data Protection Regulation) sets requirements for processing personal data. In the AI context:

**Legal basis:** Processing personal data through AI agents requires a legal basis. In the employment context, this is typically: performance of a contract (Art. 6(1)(b) GDPR) or legitimate interest (Art. 6(1)(f) GDPR). In Germany, the Federal Data Protection Act (BDSG) adds sector-specific requirements, particularly for employee data under Section 26 BDSG.

**Data minimization:** The agent processes only the data required for the specific purpose. No permanent storage of documents in the model. No use of customer data for training purposes.

**Right of access:** Data subjects can request information about which data was processed. The audit trail documents every processing of personal data.

**Erasure:** Data is deleted after the retention period expires. Deletion includes the audit trail after the statutory retention periods have elapsed.

## The EU AI Act Dimension

Since the [EU AI Act](/en/magazine/eu-ai-act-hr/) entered into force, data security in enterprise AI has a second regulatory layer. The EU AI Act requires:

**Data governance for high-risk systems:** AI systems used in HR, finance, or legal processes must implement data governance measures - including data quality checks, bias monitoring, and documentation of training data provenance.

**Transparency obligations:** Organizations must document which data their AI systems process, how decisions are made, and which safeguards are in place. The [Decision Layer](/en/magazine/decision-layer-explained/) provides this documentation through its Audit Trail.

**Human oversight:** For high-risk applications, the EU AI Act requires effective human oversight. This intersects directly with data security: the Human-in-the-Loop mechanism must have access to the relevant data without creating new data security risks.

## Employee Representation and Data Security

In Germany, works councils (Betriebsrat) have co-determination rights over the introduction of AI systems under the Works Constitution Act (BetrVG). Across the EU more broadly, employee representation bodies play a key role in ensuring that AI deployments respect employee data rights.

Employee representation bodies typically require transparency about:

- Which employee data is processed by AI agents
- Where this data is stored and for how long
- Who has access to AI-generated decisions about employees
- How employees can contest automated decisions

These requirements align with GDPR's transparency obligations and the EU AI Act's human oversight requirements. The technical implementation - tenant isolation, audit trails, Data Residency - provides the evidence base that employee representatives need.

## Data Security Checklist by Deployment Model

| Security Requirement | Self-Hosted | EU-Only Cloud | Hybrid |
|---|---|---|---|
| Data leaves corporate network | No | Yes (to EU data center) | Sensitive: No / Non-critical: Yes |
| Model training on corporate data | Not possible | Excluded via DPA | Excluded via DPA |
| GDPR compliance mechanism | Full control by design | DPA + SCCs + EU processing zones | Per-data-class routing |
| Tenant isolation | Workspace + RLS + prompt isolation | Workspace + RLS + prompt isolation | Workspace + RLS + prompt isolation |
| Audit trail location | On-premises | EU data center | Split: on-prem + EU cloud |
| Backup residency | Same as primary | Same EU region | Per data classification |
| Latency | Lowest (local network) | EU network latency | Varies by data class |

## Architecture Decisions for CISOs

Data security in enterprise AI is not a policy question. It is an architecture question. The decisions are made at the infrastructure level:

- Self-hosted vs. cloud vs. hybrid - based on data classification
- EU-only processing zones - enforced by infrastructure, not by contract alone
- Tenant isolation - enforced by Row-Level Security, not by application logic alone
- Audit trails - immutable, time-stamped, accessible for auditors and employee representatives

The right architecture makes compliance verifiable rather than promissory.

More on this: [LLM Self-Hosting](/en/magazine/llm-self-hosting-enterprise/)

<a href="/en/contact/" target="_blank" rel="noopener noreferrer">Book a consultation</a> - We will show you the Data Residency options for your requirements.

--- The Decision Act: Why Every AI Decision Must Be Contestable ---
> Art. 86 EU AI Act: a right to an explanation of the individual decision. Chat logs and model cards cannot deliver it. The decision act can.

A candidate is rejected. A special payment is denied. A salary-grade classification comes out lower than expected. In all three cases an AI agent was involved - and in all three cases the affected person can soon say a sentence that used to be reserved for lawyers: "Explain to me the role of the AI system and the main elements of this decision."

That is not a hypothetical scenario. It is the core wording of Article 86 of [Regulation (EU) 2024/1689](https://artificialintelligenceact.eu/article/86/) - the most underestimated article of the EU AI Act. The industry debates model documentation, risk classes, and deadlines. Article 86 asks a different question: can you explain one single, specific decision? Not your system. This one decision.

Most companies cannot. Not because their AI is bad - but because their architecture documents the wrong unit. They record conversations, tokens, and system behaviour. Yet only what was captured as a decision can be contested. This article describes the missing artefact: the decision act.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">At a Glance - The Decision Act</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Only what was captured as a decision can be contested. The decision act is the atomic, immutable record of a single micro-decision: input, applied business rule with version and source, result, confidence, model version, timestamp, contestation path. Logs answer "What happened?" - the decision act answers "Why was it decided this way?".</li>
<li>Art. 86 of the EU AI Act gives affected persons a right to an explanation of the individual decision - and the European Court of Justice already demands the same case-level justification under the GDPR today. A system description is not enough.</li>
<li>Chat logs, observability traces, and model cards document interaction, infrastructure, and system - but not the substantive justification. Microsoft's own documentation confirms that the Copilot audit log captures neither prompt content nor model version. And according to Anthropic's research, reasoning text from language models reflects the actual basis of a decision in only about a quarter of cases.</li>
<li>An AI agent never makes "one decision" - it makes dozens of micro-decisions per case. Each one can be legally relevant: the ECJ treats the automated score itself as a decision, not just the final outcome.</li>
<li>Contestability cannot be retrofitted: a decision that was never modelled as a decision cannot be justified as one afterwards. That is why the decision act is an architectural principle of the Decision Layer - not a compliance feature.</li>
</ul>
</div>

## Agentic AI means transferring decision rights

The numbers from the major consultancies tell one consistent story in 2026. [McKinsey](https://www.mckinsey.com/capabilities/quantumblack/our-insights/seizing-the-agentic-ai-advantage) calls it the gen AI paradox: nearly eight in ten companies use generative AI, while almost as many see no measurable bottom-line effect - because horizontal copilots are rolled out broadly while the value-creating vertical use cases remain stuck in pilot mode. [Gartner](https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027) predicts that over 40 percent of agentic AI projects will be cancelled by the end of 2027 - explicitly including inadequate risk controls among the causes. The same forecast expects at least 15 percent of day-to-day work decisions to be made autonomously by AI agents by 2028.

Taken together, those two statements define the real tension: companies are transferring decision rights to machines without owning the infrastructure to answer for those decisions. McKinsey frames the agentic era in exactly those terms in its 2026 trust study - the governing question shifts from "Is the model accurate?" to "Who is accountable when the system acts?" ([State of AI trust in 2026](https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/tech-forward/state-of-ai-trust-in-2026-shifting-to-the-agentic-era)).

The governance gap is quantified across every source:

| Finding | Figure | Source |
|---|---|---|
| Agentic AI projects cancelled by end of 2027 - including for inadequate risk controls | over 40% | [Gartner, 2025](https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027) |
| Enterprises with mature governance for autonomous agents | only 21% | [Deloitte, 2025](https://www.deloitte.com/us/en/insights/topics/emerging-technologies/ai-agents-scaling-faster.html) |
| Technology executives whose AI adoption is already outpacing their governance capability | 77% | [IBM IBV, 2026](https://www.cio.com/article/4182288/cios-are-being-held-accountable-for-ai-they-dont-fully-control-ibm-study-finds.html) |
| CIOs/CTOs held accountable for AI systems they do not fully control | around two thirds | [IBM IBV, 2026](https://www.cio.com/article/4182288/cios-are-being-held-accountable-for-ai-they-dont-fully-control-ibm-study-finds.html) |
| Reported AI incidents in 2024 - a record high, +56.4% year over year | 233 | [Stanford HAI AI Index, 2025](https://hai.stanford.edu/ai-index/2025-ai-index-report/responsible-ai) |
| Fewer AI incidents where governance is embedded directly in the system rather than enforced by manual oversight | 25% | [IBM IBV, 2026](https://www.ibm.com/thought-leadership/institute-business-value/en-us/report/ai-governance-trends) |

The last row is the most important one: embedded governance measurably outperforms after-the-fact control. Which raises the concrete question of what "embedded" means technically. And it is sharpest in HR: transferring decision rights to agents shifts the operating model - and every one of those decisions lands on a specific person: their sick note, their pay, their grading. The answer starts with the law.

## What Article 86 requires - and why system documentation cannot satisfy it

The EU AI Act distinguishes two fundamentally different transparency levels that compliance debates constantly conflate:

| Level | Legal basis | Addressee | Point in time | Answers the question |
|---|---|---|---|---|
| System transparency | Art. 11 (technical documentation), Art. 13 (instructions for use) | authority, deployer | before operation | "How does the system work in general?" |
| Individual-case explanation | Art. 86 AI Act, Art. 15(1)(h) and Art. 22 GDPR | the affected person | after the decision | "Why did this one decision come out this way?" |

[Article 86](https://artificialintelligenceact.eu/article/86/) gives any person subject to a decision based on a high-risk AI system listed in Annex III, with legal or similarly significant effect, a claim against the deployer: to "clear and meaningful explanations of the role of the AI system in the decision-making procedure and the main elements of the decision taken". That is case-specific language, not system-specific language. A model card describes the model. Article 86 asks about the case.

The European Court of Justice has already spelled out the same principle for the GDPR - in two rulings that anyone responsible for AI decisions should know:

**[SCHUFA, C-634/21](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:62021CJ0634) (December 2023):** the automated calculation of a score is itself an automated individual decision within the meaning of Art. 22 GDPR, as soon as a third party draws strongly on it. The consequence reaches far beyond credit scoring: the traceability obligation attaches to the machine evaluation itself - not only to the downstream final decision that a human signs.

**[Dun & Bradstreet Austria, C-203/22](https://www.dpcuria.eu/case?reference=C-203%2F22) (February 2025):** the controller must explain the procedure actually applied in a way that lets the person understand which of their data was used, and how, in the decision. A counterfactual explanation can suffice - for instance: which variation in the input data would have changed the result? And trade secrets do not justify blanket refusal; in case of conflict, the information must be disclosed to the competent authority or court, which then weighs the interests.

A counterfactual explanation per individual case presupposes that the actually used inputs and the applied rule are stored, structured, per decision. It cannot be reconstructed from a global system description.

Add to this a point that compliance debates routinely miss: [Art. 12](https://artificialintelligenceact.eu/article/12/) obliges high-risk systems to log automatically over their lifetime, and [Art. 26(6)](https://artificialintelligenceact.eu/article/26/) obliges deployers to retain those logs for at least six months. But the law defines the required log content only for biometric systems. For HR and finance systems, the AI Act mandates the logging capability - and leaves the content schema open. What gets recorded per decision is a design responsibility of the deployer. Logging token counts and timestamps satisfies the letter of Art. 12 and fails Art. 86.

On timing: under current law the high-risk obligations apply from 2 August 2026; the postponement to 2 December 2027 provisionally agreed in the Digital Omnibus on 7 May 2026 has not yet been formally adopted. It changes nothing about the high-risk classification of HR processes ([Annex III No. 4](https://artificialintelligenceact.eu/annex/3/)) - nor about the civil-law duty to explain decisions, which [applies worldwide already](/en/magazine/eu-ai-act-applies-worldwide/). For UK readers: Article 86 does not apply domestically - but UK GDPR Art. 22 and the ICO's guidance on automated decision-making impose the equivalent duty to explain, and Art. 86 applies in full to UK companies deploying high-risk AI in the EU. Deadlines and obligations in detail: [EU AI Act 2026: status, deadlines, what to do](/en/magazine/eu-ai-act-2026-enterprises/).

## There is no such thing as "an AI decision" - there are dozens of micro-decisions

Anyone taking Article 86 seriously in operations immediately hits a granularity problem: what exactly is "the decision"?

<div class="not-prose my-10 grid grid-cols-1 md:grid-cols-2 gap-4">
  <div class="border border-base rounded-soft overflow-hidden bg-surface-dim opacity-90">
    <div class="px-4 py-2.5 border-b border-base font-code text-xs uppercase tracking-wider text-muted">ONE &#8220;AI DECISION&#8221;</div>
    <div class="p-5">
      <div class="font-code text-xs text-muted mb-3">input: request MA-4711</div>
      <div class="flex items-center justify-center h-20 rounded bg-[#2e2e3e] border border-[#555]">
        <span class="font-display text-3xl text-white/40">?</span>
      </div>
      <div class="mt-3 font-code text-xs text-primary">result: rejected</div>
      <div class="mt-4 pt-3 border-t border-base font-code text-xs text-muted">1 result &#183; 0 justifications &#183; not contestable <span aria-hidden="true">&#10007;</span></div>
    </div>
  </div>
  <div class="border-2 rounded-soft overflow-hidden bg-surface-raised" style="border-color: var(--accent-primary);">
    <div class="px-4 py-2.5 border-b border-base font-code text-xs uppercase tracking-wider text-accent">13 MICRO-DECISIONS</div>
    <div class="p-5">
      <div class="font-code text-xs text-muted mb-3">input: request MA-4711</div>
      <div class="flex flex-wrap gap-1.5">
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #0369A1;">01</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #0369A1;">02</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #0369A1;">03</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #0369A1;">04</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #0369A1;">05</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #0369A1;">06</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #0369A1;">07</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #0369A1;">08</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #6D4ED8;">09</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #0369A1;">10</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #0369A1;">11</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #B45309;">12</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #B45309;">13</span>
      </div>
      <div class="mt-3 flex flex-wrap gap-3 font-code text-[11px] text-muted">
        <span><span class="inline-block w-2.5 h-2.5 rounded-full align-middle mr-1" style="background:#0369A1;"></span>Rule (10)</span>
        <span><span class="inline-block w-2.5 h-2.5 rounded-full align-middle mr-1" style="background:#6D4ED8;"></span>AI (1)</span>
        <span><span class="inline-block w-2.5 h-2.5 rounded-full align-middle mr-1" style="background:#B45309;"></span>Human (2)</span>
      </div>
      <div class="mt-4 pt-3 border-t border-base font-code text-xs text-primary">13 acts &#183; 13 justifications &#183; individually contestable <span class="text-accent" aria-hidden="true">&#10003;</span></div>
    </div>
  </div>
</div>

This decomposition is not tied to any jurisdiction. A credit decision breaks down by the same mechanics: identity check (rulebook), income extraction from documents (AI, with confidence), score calculation (rulebook, versioned), threshold routing (rulebook), borderline vote (human). Which law binds the individual micro-decision - GDPR Art. 22, UK GDPR, LGPD Art. 20 or the US Equal Credit Opportunity Act - depends on the market. The decomposition itself is the same everywhere. How deep it reaches in a regulated process is shown by the example that keeps European HR departments busy every day:

Processing a sick note - that sounds like one transaction. In fact it contains more than a dozen separate decisions: Was the electronic certificate retrieved correctly under §109 SGB IV (German Social Code)? Does continued pay apply under §3 EFZG (Continued Remuneration Act) - and at what amount under §4? Is this a repeat illness with offsetting under §3(1) sentence 2? Has the six-week threshold been reached that triggers the mandatory reintegration-management invitation under §167 SGB IX? Must the representative body for severely disabled employees be involved under §178 SGB IX? Who gets informed about what - and what, explicitly, not?

The [Decision Layer](/en/decision-layer/) decomposes every business process into exactly these micro-decisions and assigns each one, in advance, to one of [three decider types](/en/magazine/three-types-of-decisions/) - human, rulebook, or AI:

| Micro-decision (sick note) | Decider | Why |
|---|---|---|
| eAU retrieval under §109 SGB IV incl. blocking period | Rulebook | deterministic, no room for interpretation |
| Calculate continued pay under §3, §4 EFZG | Rulebook | fixed deadline and amount arithmetic |
| Check offsetting for repeat illness | Rulebook | deterministic 12-month rule |
| Trigger reintegration (BEM) invitation at six weeks, §167 SGB IX | Rulebook | statutory threshold |
| Flag unusual absence patterns statistically | AI (indicator) | anomaly detection; output is a review hint, not a personnel decision |
| Conduct the reintegration meeting | Human | relationship of trust, §167 procedure |
| Illness-related termination | Human | three-step test under dismissal-protection law, reversed burden of proof under AGG §22 |

This decomposition is not an academic exercise - it is the precondition for contestability. The ECJ's SCHUFA logic applies at every level: if an automated score is already a decision in the legal sense, then the machine deadline check, the machine document classification, the machine grading recommendation are each a potentially contestable act - not just the final outcome. A company that documents only the final outcome can answer the question "Why was my application rejected?" only with: "That is what the process produced." Which is precisely the black-box answer no employment court accepts.

How deep this decomposition goes in practice is documented in the [HR agent catalog](/en/hr-agent-catalog/): 48 agents, each with a complete micro-decision table - decider type, justification, legal basis, and contestation path per step.

## Why logs, traces, and model cards do not answer the question

The industry has responded to the documentation need - but on three levels that all miss the individual decision:

| Level | Tooling | Documents | Does NOT answer |
|---|---|---|---|
| Interaction | chat logs, conversation history, Copilot audit events | who talked to the system when, which resources were touched | which business rule carried the decision |
| Infrastructure | LLM observability (traces, spans), OpenTelemetry GenAI | prompts, tool calls, tokens, latency along the execution | why the result came out this way - and whether it is correct |
| System | model cards, technical documentation, governance platforms (model inventory, risk register) | how the model works in general, what risks the system has | any specific individual case |

This is not a polemic - it is what the vendor documentation says. [Microsoft's Purview documentation](https://learn.microsoft.com/en-us/purview/audit-copilot) states that the Copilot audit log does not record the actual user prompts and responses, and that model name and model version are not available in Microsoft 365 Copilot scenarios. Within the Salesforce ecosystem the gap is named openly: classic audit trails were built for humans clicking buttons - you can see that something changed, [but not why](https://www.sweep.io/blog/the-audit-trail-of-an-ai-agent). And governance platforms such as IBM watsonx.governance or Credo AI answer the question "Is this system inventoried, risk-assessed, and policy-compliant?" - an important question, but a different one from "What was Ms M.'s grading on 14 June at 10:42 based on?".

That leaves the seemingly obvious way out: let the model justify itself. Reasoning models produce justification chains - why not archive those as evidence? Because they demonstrably fail to reflect what the decision was actually based on. [Anthropic's research](https://www.anthropic.com/research/reasoning-models-dont-say-think) on chain-of-thought faithfulness shows that even under favourable conditions, reasoning models verbalise the decision cues they actually used in only about a quarter of cases - relevant influences stay hidden even from someone who reads the entire reasoning chain. A generated justification is text about the decision. It is not the basis of the decision.

Contestability research draws the decisive conclusion: explainability and contestability are two means to the same end - and explanation alone, without a path to contest, misses it ([Schmude et al., 2025](https://arxiv.org/abs/2504.18236)). Contestability presumes a decision may be incorrect, and demands the evidence to overturn it. Post-hoc explanation methods show, at best, that errors may exist somewhere in the neighbourhood of a decision; they do not prove that this one decision was flawed. And [Moreira et al. (2025)](https://arxiv.org/html/2506.01662v1) shift the standard from mere comprehension to agency: an explanation must enable affected stakeholders to actively challenge, scrutinise, and influence an outcome - not merely understand why it was reached.

Nobody can do that with a token trace. With a decision act, they can.

## The decision act: the piece of evidence per decision

The decision act is the atomic, immutable, structured record of a single substantive micro-decision. It is created at the moment of decision - not as an after-the-fact reconstruction - and contains everything that Art. 86, Art. 12, and the ECJ case law require per individual case:

| Field | Content | What it serves legally |
|---|---|---|
| Input | which data, which document, which hash | C-203/22: "which data was used, and how" |
| Business rule + version + source | e.g. collective agreement §12(3), version 2024-Q3, effective 2024-07-01 | the carrying justification - the field logs and traces do not have |
| Decider type | human, rulebook, or AI - with routing justification | Art. 14: proof of effective human oversight |
| Confidence | confidence value and threshold at decision time | evidence of risk management (Art. 9), escalation traceability |
| Model and prompt version | which language model, which prompt template, which version | reproducibility; the field missing from the Copilot audit log |
| Result + timestamp | what was decided, when (UTC) | retention under Art. 26(6), GoBD-style write-once requirements |
| Human-in-the-loop note | who reviewed, whether they confirmed or deviated | Art. 14(4): override, reverse, stop - documented |
| Contestation path | who can contest this decision, and where | makes the Art. 86 claim operationally answerable |

This is what it looks like in the record of a real case - four of 13 micro-decisions of a sick-note process (German example):

<div class="not-prose my-10 bg-surface-raised border border-base rounded-soft overflow-hidden shadow-sm">
  <div class="px-5 py-4 border-b border-base bg-surface-dim">
    <div class="flex items-center gap-3 mb-2">
      <div class="flex gap-1.5" aria-hidden="true">
        <span class="w-2.5 h-2.5 rounded-full bg-[#FF5F56]"></span>
        <span class="w-2.5 h-2.5 rounded-full bg-[#FFBD2E]"></span>
        <span class="w-2.5 h-2.5 rounded-full bg-[#27C93F]"></span>
      </div>
      <span class="font-code text-xs text-muted">decision-record / sick-leave / 2026-05-14 / EMP_0x52a8</span>
    </div>
    <p class="text-small text-primary">eAU received 14 May 2026, 07:12. Case processed in 54 seconds - decomposed into 13 documented micro-decisions.</p>
    <div class="mt-3 flex h-7 rounded overflow-hidden text-xs font-bold text-white" aria-label="Decider distribution: 10 rulebook, 1 AI, 2 human">
      <div class="flex items-center justify-center" style="width: 77%; background: #0369A1;">10 Rule</div>
      <div class="flex items-center justify-center" style="width: 8%; background: #6D4ED8;">1</div>
      <div class="flex items-center justify-center" style="width: 15%; background: #B45309;">2 Human</div>
    </div>
  </div>
  <ol class="divide-y divide-base">
    <li class="p-5">
      <div class="flex items-start gap-4">
        <div class="flex-shrink-0 w-9 h-9 rounded-full flex items-center justify-center font-code text-xs font-bold border" style="background: rgba(3,105,161,0.08); border-color: rgba(3,105,161,0.3); color: #0369A1;">02</div>
        <div class="flex-1 min-w-0">
          <div class="flex flex-wrap items-center gap-2 mb-1.5">
            <span class="text-body font-semibold text-primary">Calculate continued pay under §3, §4 EFZG</span>
            <span class="inline-flex items-center gap-1 px-2 py-0.5 text-xs font-bold uppercase tracking-wider rounded text-white" style="background: #0369A1;">Rule</span>
          </div>
          <p class="text-small text-primary font-medium mb-2">6 weeks from 14 May 2026, 100% gross</p>
          <div class="px-3 py-2 bg-surface border border-base rounded font-code text-xs text-primary/80"><span class="text-muted">input:</span> eAU period 14-27 May · master data EMP_0x52a8</div>
          <div class="mt-2 font-code text-xs text-muted"><span>rule:</span> <span class="text-primary">EFZG-§3+§4 · v2026-01</span></div>
        </div>
      </div>
    </li>
    <li class="p-5">
      <div class="flex items-start gap-4">
        <div class="flex-shrink-0 w-9 h-9 rounded-full flex items-center justify-center font-code text-xs font-bold border" style="background: rgba(3,105,161,0.08); border-color: rgba(3,105,161,0.3); color: #0369A1;">06</div>
        <div class="flex-1 min-w-0">
          <div class="flex flex-wrap items-center gap-2 mb-1.5">
            <span class="text-body font-semibold text-primary">Check reintegration threshold (§167 SGB IX)</span>
            <span class="inline-flex items-center gap-1 px-2 py-0.5 text-xs font-bold uppercase tracking-wider rounded text-white" style="background: #0369A1;">Rule</span>
          </div>
          <p class="text-small text-primary font-medium mb-2">42 sick days within 12 months reached - invitation triggered</p>
          <div class="px-3 py-2 bg-surface border border-base rounded font-code text-xs text-primary/80"><span class="text-muted">input:</span> absence history, 12 months (3 periods)</div>
          <div class="mt-2 font-code text-xs text-muted"><span>rule:</span> <span class="text-primary">SGB-IX-§167 · v2025-07</span></div>
        </div>
      </div>
    </li>
    <li class="p-5">
      <div class="flex items-start gap-4">
        <div class="flex-shrink-0 w-9 h-9 rounded-full flex items-center justify-center font-code text-xs font-bold border" style="background: rgba(109,78,216,0.08); border-color: rgba(109,78,216,0.3); color: #6D4ED8;">09</div>
        <div class="flex-1 min-w-0">
          <div class="flex flex-wrap items-center gap-2 mb-1.5">
            <span class="text-body font-semibold text-primary">Flag absence pattern</span>
            <span class="inline-flex items-center gap-1 px-2 py-0.5 text-xs font-bold uppercase tracking-wider rounded text-white" style="background: #6D4ED8;">AI <span class="font-mono opacity-90">91%</span></span>
          </div>
          <p class="text-small text-primary font-medium mb-2">Notice to HR operations: third short-term absence in six months</p>
          <div class="px-3 py-2 bg-surface border border-base rounded font-code text-xs text-primary/80"><span class="text-muted">input:</span> anonymised absence metadata - no diagnosis (GDPR Art. 9)</div>
          <div class="mt-2 font-code text-xs text-muted"><span>model-reason:</span> <span class="text-primary">pattern match short-term repeat absence · indicator, not a personnel decision</span></div>
          <div class="mt-3"><span class="inline-flex items-center px-3 py-1.5 text-xs font-semibold rounded border-2" style="border-color: #6D4ED8; color: #6D4ED8; background: rgba(109,78,216,0.08);">formally contestable · Art. 14 EU AI Act</span></div>
        </div>
      </div>
    </li>
    <li class="p-5">
      <div class="flex items-start gap-4">
        <div class="flex-shrink-0 w-9 h-9 rounded-full flex items-center justify-center font-code text-xs font-bold border" style="background: rgba(180,83,9,0.08); border-color: rgba(180,83,9,0.3); color: #B45309;">13</div>
        <div class="flex-1 min-w-0">
          <div class="flex flex-wrap items-center gap-2 mb-1.5">
            <span class="text-body font-semibold text-primary">Conduct reintegration meeting</span>
            <span class="inline-flex items-center gap-1 px-2 py-0.5 text-xs font-bold uppercase tracking-wider rounded text-white" style="background: #B45309;">Human</span>
          </div>
          <p class="text-small text-primary font-medium mb-2">Return-to-work plan agreed</p>
          <div class="mt-2 font-code text-xs text-muted"><span>decided-by:</span> <span class="text-primary">reintegration officer</span> <span class="text-muted">- 17 May 2026, 14:10</span></div>
        </div>
      </div>
    </li>
  </ol>
</div>

German administrative law offers a precise analogy for this artefact: the Verwaltungsakt, the formal administrative act. An authority deciding about a citizen does not issue "output" - it issues an act: individually addressed, justified, with legal basis and instructions on appeal, individually contestable. Nobody would accept an agency answering an appeal with: "Unfortunately we only have the server log." The decision act transfers exactly this standard of form to machine decisions. A trail is a track you leave behind. An act is a document you issue - and against which an appeal is possible.

Accounting has known the same logic for centuries: no auditor accepts a total without journal entries and supporting documents. German GoBD rules require individual records, immutability, and traceability per business transaction - with retention periods of six to ten years under §147 AO and §257 HGB, far beyond the six months of Art. 26(6). The decision act is nothing other than double-entry bookkeeping for decisions: one document per transaction, one act per decision.

That no standard term exists yet for this unit is evident in the market itself: "decision trail", "decision provenance", "decision trace", "accountability record" all circulate - [TechTarget](https://www.techtarget.com/searcherp/feature/AI-decision-trails-are-the-new-audit-trail) declares AI decision trails the new audit trail, the [FINOS AI Governance Framework](https://air-governance-framework.finos.org/mitigations/mi-21_agent-decision-audit-and-explainability.html) calls for "Agent Decision Audit and Explainability". The requirement has arrived in the discourse. The artefact has no name yet. We have called it, since the beginning of the Decision Layer: the decision act.

Where the act is created becomes clear in the seven layers of a production agent stack - the decision act is the artefact of layer 04:

<div class="not-prose my-10 border-y border-base">
  <ol class="divide-y divide-base">
    <li class="grid grid-cols-[3rem_1fr] gap-4 items-start py-4">
      <span class="font-display text-h2 leading-none text-muted">01</span>
      <div><span class="text-body font-semibold text-primary">Presentation Layer</span><p class="mt-1 text-small text-primary/80">User interfaces, prompt gateways, access portals for business units and employee representation.</p></div>
    </li>
    <li class="grid grid-cols-[3rem_1fr] gap-4 items-start py-4">
      <span class="font-display text-h2 leading-none text-muted">02</span>
      <div><span class="text-body font-semibold text-primary">Orchestration Layer</span><p class="mt-1 text-small text-primary/80">Multi-agent coordination, event routing, state management across process boundaries.</p></div>
    </li>
    <li class="grid grid-cols-[3rem_1fr] gap-4 items-start py-4 bg-[color:var(--accent-primary)]/5">
      <span class="font-display text-h2 leading-none text-accent">03</span>
      <div><span class="text-body font-semibold text-primary">Agent Layer <span class="ml-2 font-code text-xs uppercase tracking-wider text-accent">Gosign core</span></span><p class="mt-1 text-small text-primary/80">Document, workflow and knowledge agents - the executing layer with AI judgement.</p></div>
    </li>
    <li class="grid grid-cols-[3rem_1fr] gap-4 items-start py-4 bg-[color:var(--accent-primary)]/5">
      <span class="font-display text-h2 leading-none text-accent">04</span>
      <div><span class="text-body font-semibold text-primary">Decision Layer <span class="ml-2 font-code text-xs uppercase tracking-wider text-accent">Gosign core</span></span><p class="mt-1 text-small text-primary/80">This is where the decision act is created: one act per micro-decision, versioned rulebooks, human-in-the-loop routing for discretion, contestability under Art. 14.</p></div>
    </li>
    <li class="grid grid-cols-[3rem_1fr] gap-4 items-start py-4">
      <span class="font-display text-h2 leading-none text-muted">05</span>
      <div><span class="text-body font-semibold text-primary">Governance Layer</span><p class="mt-1 text-small text-primary/80">Audit trail, signed records, cert-ready controls for EU AI Act Art. 9/12/13/14, ISO 27001, ISA.</p></div>
    </li>
    <li class="grid grid-cols-[3rem_1fr] gap-4 items-start py-4">
      <span class="font-display text-h2 leading-none text-muted">06</span>
      <div><span class="text-body font-semibold text-primary">Model Layer</span><p class="mt-1 text-small text-primary/80">Model registry, versioning, confidence calibration - model-agnostic.</p></div>
    </li>
    <li class="grid grid-cols-[3rem_1fr] gap-4 items-start py-4">
      <span class="font-display text-h2 leading-none text-muted">07</span>
      <div><span class="text-body font-semibold text-primary">Integration Layer</span><p class="mt-1 text-small text-primary/80">Connectors to SAP, DATEV, Workday - posting-ready outputs into the target systems.</p></div>
    </li>
  </ol>
</div>

## Contestability is an architecture decision - not a feature

The uncomfortable consequence of all this: contestability cannot be retrofitted. Three reasons why an after-the-fact compliance tool structurally fails:

**First: what was never modelled as a decision cannot be justified as one.** An agent that processes a case "in one go" produces a result without structure. The decomposition into micro-decisions must happen before execution - it defines where an act is created, which rule applies there, and who decides there. No decision structure can be extracted from a conversation log afterwards, any more than a cost-centre accounting can be extracted from a bank statement.

**Second: effective human oversight needs the decision context - per case.** [Art. 14(4)](https://artificialintelligenceact.eu/article/14/) requires that the overseeing person can correctly interpret the output, disregard or reverse it, and stop the system - while remaining aware of the tendency to rely automatically on machine output. The legislator names automation bias explicitly. The US NIST warns in the same spirit against ceremonial human-in-the-loop: an approval button without context, authority, and time protects nobody. Whoever is supposed to override needs the input, the applied rule, the confidence, and the escalation reason in front of them - precisely the fields of the decision act. That is why [human-in-the-loop in the Decision Layer is an enforced routing](/en/magazine/human-in-the-loop-architecture/), not an optional click: for defined decision types the workflow pauses, the target system remains untouched, and the human decision is itself documented as an act - including whether it followed the recommendation or deviated from it.

**Third: correction needs the rule reference.** Contestation is not an end in itself - it is meant to fix errors. When a decision is successfully contested, the immediate question is: was it an individual error or a rule error? A decision act that carries the applied rule version answers that with a query: all acts under the same rule version are identifiable, the rule is corrected in a new version, the affected cases are re-decided in a targeted way. A contested individual case becomes a fixed error class. Without the rule reference, the only option is manually reviewing every case - the opposite of scaling.

Research calls this principle [contestability by design](https://research.tudelft.nl/en/publications/contestable-ai-by-design-towards-a-framework/) (Alfrink et al., 2022): systems must remain open to human intervention across their lifecycle - as a procedural relationship between decision subjects and human controllers, built in rather than bolted on. And [Deloitte (2025)](https://www.deloitte.com/us/en/insights/topics/emerging-technologies/ai-agents-scaling-faster.html) names the three governance building blocks enterprises lack for agents almost verbatim to this architecture: clear boundaries defining which decisions agents may take independently versus which require human approval; real-time monitoring that tracks agent behaviour and flags anomalies; and audit trails that capture the full chain of agent actions to ensure accountability. The three-decider framework, confidence routing, and the decision act are the technical answer to exactly that list - as a design principle, [not as a retrofitted compliance layer](/en/governance/eu-ai-act/).

## Who contests - and what happens next

Contestability sounds abstract but has four very concrete faces. The Decision Layer defines, for every micro-decision, to whom it must justify itself:

| Who contests | Legal basis | What they see | What follows |
|---|---|---|---|
| The affected person | Art. 86 AI Act, Art. 15, 22 GDPR | the explanation of their own decision: role of the AI system, main elements, counterfactual on request | correction of the individual case; on a rule error, re-run of all affected cases |
| The works council | §87(1) No. 6 BetrVG (German Works Constitution Act), works agreements | acts of personnel-relevant decisions, proof that works-agreement rules were technically enforced | co-determination based on evidence instead of distrust |
| The auditor | GoBD, IDW PS, ISA | complete acts per posting: document, rule, version, confidence, approval | system audit instead of case-by-case reconstruction; any sample directly evidenced |
| The supervisory authority | Art. 26(6), Art. 12 AI Act; market surveillance | exportable, machine-readable logs across the required retention period | ability to respond within days instead of a forensics project |

Note what this table does to an organisation: it reverses the burden-of-proof dynamic. Without decision acts, every contestation is a forensics project with an open outcome - and under AGG §22, in discrimination cases the employer carries the burden of proof as soon as indications exist. With decision acts, the answer is a query. The works council that blocks AI projects today because it gets no transparency becomes the beneficiary of the same infrastructure that serves the auditor. Others promise transparency. The decision act enforces it technically.

The table has a quiet flip side: who may contest is set by law and agreement - but no norm by itself ensures that decision acts come into existence, are complete and endure. That responsibility needs a clear owner in the organisation; it does not happen as a by-product of operations.

## Context: a principle is taking hold

An honest look at the 2026 market: the insight that agent decisions must be individually provable is not exclusive. Gartner has created a market category of its own for control layers that monitor and block agent actions - [guardian agents](https://www.gartner.com/en/newsroom/press-releases/2025-06-11-gartner-predicts-that-guardian-agents-will-capture-10-15-percent-of-the-agentic-ai-market-by-2030) - and predicts they will account for 10 to 15 percent of the agentic AI market by 2030. The [decision intelligence field](https://www.gartner.com/en/information-technology/glossary/decision-intelligence) - explicitly modelling, evaluating, and improving decisions - got its first Magic Quadrant in January 2026. The WEF calls for [progressive governance](https://www.weforum.org/publications/ai-agents-in-action-foundations-for-evaluation-and-governance/): oversight intensity coupled to the agent's autonomy level. Research is working on decision provenance. The direction is unambiguous - and it is exactly the direction of the Decision Layer.

What these approaches do not deliver is the binding to the business substance. A guardian agent blocks at runtime; it leaves no act that holds up in an employment court three years later. Observability preserves the execution chain; it does not decompose decisions into individually justified, rule-bound artefacts. The defensible difference of the decision act lies in three properties: the attribution of every micro-decision to a versioned business rule with its source - collective agreement, works agreement, tax law - rather than to a generated reasoning chain; architecturally enforced human-in-the-loop per decision type rather than a configurable setting; and the mapping of acts onto the audit standards that auditors and internal audit actually work with - ISA, IDW PS, GoBD. To our knowledge, no horizontal vendor documents the first field; it is also the field on which contestability hinges.

Precision also requires the disclaimer: the decision act is an architecture statement, not a certificate of conformity. Whether a specific system meets the legal requirements remains a case-by-case assessment by the deployer and its legal advisers. What the architecture delivers is something else - and more valuable: it makes the requirements satisfiable. A company with decision acts can answer the Article 86 question. A company with chat logs cannot, however well-documented its intentions.

## The real question

The EU AI Act did not invent the explainability of individual decisions - it codified it for AI systems and armed it with a right of the affected person. The ECJ set the standard before the first high-risk deadline even bites. And the consultancies have quantified what happens when companies transfer decision rights without being able to prove decisions: cancelled projects, blocked rollouts, personally accountable CIOs.

The question for any company deploying AI agents is therefore not "Are we compliant?". It is: if tomorrow an employee, a works council, an auditor, or an authority contests one single decision made today - can you produce the act? Input, rule, version, confidence, result, approval?

Whoever can answer that with yes no longer has an AI risk problem. They have a decision infrastructure.

→ [Decision Layer - overview and examples](/en/decision-layer/)

→ [Decision Layer explained: the four components](/en/magazine/decision-layer-explained/)

→ [EU AI Act: HR AI remains high-risk - deadline 2026/2027](/en/magazine/eu-ai-act-hr-high-risk/)

<a href="/en/contact/" target="_blank" rel="noopener noreferrer">Book a meeting</a> - We will show you, on one of your processes, what micro-decisions, decision acts, and contestation paths look like in practice.

--- Decision Layer Explained: Governance for AI Agents ---
> The Decision Layer: Rules Engine, Confidence Routing, Human-in-the-Loop, Audit Trail. Governance between AI agent and target system

## The Problem: AI Decisions Without Traceability

When an AI agent posts an invoice, processes a sick leave notification, or answers a compliance question, it makes a decision. That decision is based on a language model that operates on probabilities, not on deterministic rules.

For an internal chatbot, that is acceptable. For business-critical processes, it is not. When an agent proposes a booking, it must be traceable: Which rule was applied? In which version? With what confidence? Was a human involved?

Without this traceability, AI decisions cannot be deployed in regulated environments. Auditors cannot verify them. Works councils cannot evaluate them. Internal audit cannot reconstruct them.

The Decision Layer solves this problem.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">At a Glance - Decision Layer</p>
<ul class="text-body text-gosign-text space-y-2">
<li>The Decision Layer is the governance component between AI agent and target system - every agent decision passes through it before taking effect.</li>
<li>It decomposes processes into micro-decisions and defines for each: human decides, rule set applies, or AI decides autonomously.</li>
<li>Four components - Rules Engine, Confidence Routing, Human-in-the-Loop, Audit Trail - ensure traceability, compliance, and audit readiness.</li>
<li>For rule-based, repetitive decisions, AI demonstrably outperforms humans on consistency, fatigue resistance, and completeness.</li>
<li>Without a Decision Layer, enterprise AI agents cannot pass audits, satisfy works council requirements, or scale beyond pilot projects.</li>
</ul>
</div>

[Gartner (2026)](https://www.gartner.com/en/newsroom/press-releases/2026-05-26-gartner-says-applying-uniform-governance-across-ai-agents-will-lead-to-enterprise-ai-agent-failure) predicts that by 2027, 40 percent of organizations will downgrade or decommission autonomous AI agents due to governance gaps.

## What Is a Decision Layer?

The Decision Layer is the central governance component between AI agent and target system. Architecturally, it sits between the agent that issues a recommendation and the system where the decision takes effect, such as SAP, [DATEV](https://www.datev.de/), [Sage](https://www.sage.com/), or [Workday](https://www.workday.com/).

The Decision Layer is not a retroactive compliance add-on. It is an architectural principle. Every agent decision passes through the Decision Layer before reaching the target system.

## Decision Layer - Explained for Process Owners

The technical description above is precise. But for day-to-day understanding, there is a simpler explanation:

The Decision Layer works like a standard process description with clearly defined decision stages, except that it is technically enforced rather than written on paper.

In concrete terms: Every business process that an AI agent is meant to execute is broken down into individual micro-decisions. For each individual decision, the following is defined in advance, by humans, not by the AI:

**HUMAN:** Does a human need to decide here? The architecture enforces human review for discretionary decisions, discrimination risk, employee representation matters, and value thresholds above defined limits. The agent provides full context and a recommendation - but a human decides. This escalation is technically enforced, not organisationally agreed.

**RULE SET:** Is the decision deterministic - is there no room for interpretation? The collective agreement states X, so X applies. A deadline expires on date Y, so rule Z triggers. Rule sets are versioned: every change creates a new version, previous versions remain traceable. Here, the agent is an executor - not because it cannot do more, but because there is nothing to interpret.

**AI AUTONOMOUS:** Does the agent make the decision independently - because it is confident enough, has permission, and demonstrably performs the task better than manual processing? It interprets documents, classifies situations, evaluates context, and recognises patterns. This is not if-then-else - this is judgment within defined guardrails. Confidence Routing controls: high confidence and low risk leads to autonomous decision. Low confidence or high risk leads to escalation to a human.

Each of these steps is documented: Who decided, on what basis, with what outcome. That is the Audit Trail, the evidence that auditors, works councils, and internal audit require.

The result: Processes become faster and more consistent without losing control. And when someone asks "How was this decision made?", there is an answer.

<table class="w-full text-left text-sm">
<thead><tr class="border-b border-gosign-border">
<th class="py-2 pr-4 font-semibold">Decision Type</th>
<th class="py-2 pr-4 font-semibold">Speed</th>
<th class="py-2 pr-4 font-semibold">Auditability</th>
<th class="py-2 pr-4 font-semibold">Risk Level</th>
<th class="py-2 pr-4 font-semibold">Example</th>
</tr></thead>
<tbody>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Human Decision</td><td class="py-2 pr-4">Low (minutes to days)</td><td class="py-2 pr-4">High (documented review)</td><td class="py-2 pr-4">Low (human judgment)</td><td class="py-2 pr-4">Return-to-work planning</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Rule-Based</td><td class="py-2 pr-4">High (instant)</td><td class="py-2 pr-4">High (versioned rules)</td><td class="py-2 pr-4">Low (deterministic)</td><td class="py-2 pr-4">Pay grade classification</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">AI Autonomous</td><td class="py-2 pr-4">High (instant)</td><td class="py-2 pr-4">High (Audit Trail)</td><td class="py-2 pr-4">Medium (Confidence Routing)</td><td class="py-2 pr-4">Document classification</td></tr>
</tbody>
</table>

The technical implementation of this logic consists of four components:

### The Four Components

**1. Rules Engine**

Business rule sets, versioned and traceable. Collective agreements, works council agreements, booking logic, tax legislation, compliance rules. Every rule has a version, an effective date, and a scope.

When a rule changes, for example a new collective agreement or an updated booking policy, a new rule version is created. The previous version remains in the system. During an audit, it is traceable which rule, in which version, was in effect at the time of the decision.

**2. Confidence Routing**

Not every agent decision carries the same level of certainty. The Decision Layer automatically evaluates every decision:

- High confidence + low risk = autonomous processing. The agent decides, the result goes to the target system.
- Low confidence or high risk = escalation to a human. The workflow pauses, a clerk reviews and decides.
- Edge case or unknown pattern = blocking. No output, human clarification required.

The thresholds for confidence and risk are configurable and tenant-specific. An auditing firm will set different thresholds than an internal shared service center.

**3. Human-in-the-Loop**

Human-in-the-Loop in the Decision Layer is an architectural principle, not an optional checkbox. For defined decision types, the architecture enforces human review:

- Decisions with potential for discrimination
- Decisions that affect co-determination matters
- Decisions above defined value thresholds
- First-time application of a new rule

The Human-in-the-Loop requirement is technically enforced, not organizationally. An agent cannot bypass this review.

**4. Audit Trail - the decision act**

Every decision generates a complete, immutable decision act:

- Input: What was provided to the agent?
- Model: Which language model in which version was used (e.g. `claude-opus-4-7-2026-04-12`, `gpt-5.5-2026-03-pro`, `mistral-medium-3.1-eu`, `deepseek-v4-pro-on-prem`)?
- Rule set: Which rule, in which version, was applied?
- Confidence: How certain was the agent?
- Routing: Was the decision made autonomously or escalated?
- Outcome: What was the decision?
- Timestamp: When was the decision made?
- Contestation path: Who can contest this decision - the affected person, employee representation, the auditor?

This decision act is what auditors see in the Auditor Portal. Not retroactive documentation, but the technical proof of the decision-making process. And it is the architectural answer to Art. 86 of the EU AI Act - the right of affected persons to an explanation of the individual decision.

## How the Decision Layer Works in Practice

A concrete example from document processing:

A document arrives, an incoming invoice. The Document Agent reads the document and extracts the relevant information: vendor, amount, service description, date.

The agent creates a booking proposal: account, cost center, input tax deduction, depreciation start date. This proposal goes to the Decision Layer.

The Decision Layer checks: Is the booking proposal consistent with the versioned rule sets? Is the cost center correct? Is the input tax deduction correct for this invoice type? Is the amount within the limits for autonomous processing?

If yes: The booking proposal goes to the target system (DATEV, SAP). The complete decision path is stored in the Audit Trail.

If no: A query is sent to the clerk. The workflow pauses. The clerk sees the proposal, the applied rule, the confidence score, and the reason for escalation. They decide. This human decision is also documented in the Audit Trail.

## Which Models the Decision Layer Currently Routes

The Decision Layer is model-agnostic - each micro-decision is routed to the model that fits best in terms of capability and cost. As of May 2026, the routing layer dispatches production traffic to, among others:

- **Claude Opus 4.7** and **Claude Sonnet 4.6** (Anthropic, Cloud API) - for reasoning quality on compliance escalations, long case files, and Decision Record synthesis
- **GPT-5.5** (OpenAI, Cloud API or Azure OpenAI with EU data residency) - for structured extraction and tool use
- **Gemini 3.1 Pro** (Google, Cloud API) - for multimodal document processing (PDF + scan + table)
- **Mistral Small 3.2** (Apache 2.0, self-host or La Plateforme) - for high-volume, cost-sensitive classification
- **Mistral Medium 3.1** (La Plateforme, EU region) - when EU data residency must be contractually guaranteed but no in-house cluster is available
- **DeepSeek V4-Pro** and **V4-Flash** (MIT licence, self-host or API) - for deep research and mathematically rigorous decision paths
- **Llama 4 Scout** (Meta licence, self-host, 10M-token context) - for long case files and full personnel-record context
- **gpt-oss-120b** (OpenAI, Apache 2.0, self-host) - when an OpenAI model is needed without cloud dependency
- **Qwen 3 Coder 110B**, **DeepSeek Coder V4**, **Codestral Mamba 32B** - for code and ABAP/SQL micro-decisions in the backend

Which model is selected for each micro-decision (selection criteria, current benchmark landscape, TCO comparison for FTSE 100 and upper mid-market) is covered in the master article [AI Models 2026 - Which Language Model for Which Task](/en/magazine/ai-models-comparison-2026/). What of this can be self-hosted on-prem - including GPU sizing, licence terms, and the self-hosting stack - is covered in the spinoff [Self-Hosted Open-Source AI 2026](/en/magazine/self-hosted-open-source-ai-2026/).

## Why AI Makes Certain Decisions Better Than Humans

In the discussion about AI agents, one question gets overlooked: Are there decisions where AI is not just faster, but demonstrably better? The answer is yes. And the Decision Layer makes exactly these cases identifiable.

There are three categories where autonomous AI decisions outperform humans, not because AI is smarter, but because it does not have the structural weaknesses of humans:

**Consistency across locations and individuals.** 50 clerks at 12 locations apply the same collective agreement. Each interprets edge cases slightly differently. At Location A, a special payment is approved; at Location B, the same case is rejected. This is not a training issue, it is the natural variance of human decisions. An AI operating on a versioned rule set decides identically. Every time, at every location.

**Freedom from fatigue in repetitive decisions.** A recruiter screens differently on Monday morning than on Friday afternoon. After the 50th application, attention drops. The last candidate was strong, so the next one seems weaker by comparison (anchoring bias). An AI evaluates Application #1 with the same diligence as Application #200. It does not have a bad day.

**Completeness in rule checking.** An HR clerk checks a sick leave notification against three or four criteria that come to mind: duration of illness, continued pay period, perhaps the return-to-work threshold. But do they also check the waiting period rule? The special provision for part-time employees in the company-specific collective agreement? The reporting obligation to the occupational insurance association for certain types of illness? Every time? Even on Friday at 4 pm? An AI checks against all applicable rules, in the current version, completely and documented. Not because it is smarter, but because it does not forget.

This does not mean AI is better everywhere. Judgment calls, individual case assessments, cultural fit, ethical considerations, these are and remain human domains. But for rule-based, repetitive decisions with a high need for consistency, autonomous AI is not a compromise. It is the better solution.

The Decision Layer makes this distinction operational: For each micro-decision, it is defined whether the human, the rule set, or the AI decides, and for AI decisions, it is documented *why* AI is the right choice here.

## Why No Agent Should Go Into Production Without a Decision Layer

Without a Decision Layer, an AI agent is a black box. It produces results, but nobody can trace how. This has concrete consequences:

**Auditing:** Auditors and internal audit require traceability. Without an Audit Trail, every agent decision is an audit risk. The auditor must manually reconstruct each individual case, which is more effort than operating without an agent.

**Co-determination:** Works councils have co-determination rights when AI systems are introduced. Without traceable decision logic, they cannot fulfill their role. The Decision Layer transforms works council agreements into technical constraints.

**Liability:** If an agent generates an erroneous booking and there is no decision path, it is unclear who is responsible. The Decision Layer documents the chain of responsibility.

**Scaling:** An agent that works in a pilot project does not necessarily work in production. Without governance infrastructure, every agent remains an isolated case. The Decision Layer enables consistent governance across all agents.

## Decision Layer and Cert-Ready by Design

The Decision Layer is the technical foundation for Cert-Ready by Design. Controls are first-class data objects in the Decision Layer with defined attributes: Control_ID, Technical_Implementation, Rule_Version, Evidence_Generator, Evidence_History, Auditor_View.

Evidence is generated automatically, not compiled retroactively. Auditors see the live status of all controls in the Auditor Portal, with drill-down to the specific rule implementation.

The framework mapping maps controls to established audit standards: ISA, PS 951, IDW, GoB/GoBD (German record-keeping standard). A tax audit or year-end audit can be conducted on the basis of automatically generated evidence.

More on this: [Cert-Ready by Design](/en/governance/cert-ready/)

> [Decision Layer - Overview and Examples](/en/decision-layer/)

→ [The Decision Act: Why Every AI Decision Must Be Contestable](/en/magazine/decision-act-contestable-ai-decisions/)

<a href="/en/contact/" target="_blank" rel="noopener noreferrer">Book a consultation</a> - We will show you what a Decision Layer looks like for your specific process.

--- Decision Layer: Eliminating Payroll Errors ---
> Payroll errors don't come from carelessness - they come from implicit expertise. The Decision Layer makes decision logic explicit and auditable.

## The Real Problem with payroll Errors

Payroll errors don't just cost money. They cost trust, create audit risks and tie up qualified staff in correction cycles. But the real problem isn't carelessness. It's implicit knowledge.

In every finance department, there are employees who have known for 15 years which collective agreement applies in which constellation, when a sick note triggers a recalculation, and where the edge cases are. This knowledge exists in heads, not in systems.

When these employees get sick, retire or leave the company, the knowledge leaves with them. Their successors make errors - not from incompetence, but because the rules are nowhere explicitly documented.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">At a Glance - Decision Layer for Payroll</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Payroll errors stem from implicit expertise - rules exist in heads, not in systems. When staff leave, knowledge leaves with them.</li>
<li>According to the Hackett Group (2024), enterprises with explicit, versioned payroll rules reduce correction postings by 60 - 80% within the first year.</li>
<li>The Decision Layer makes rule application explicit, versioned and auditable - every posting decision is traceable to a defined rule.</li>
<li>Routine cases are processed autonomously; exceptions are escalated to specialists with full context and confidence scores.</li>
<li>Audit readiness becomes structural: every decision path is automatically documented from source document to applied rule.</li>
</ul>
</div>

## What the Decision Layer Does Differently

The [Decision Layer](/en/finance-ai-agents/) replaces implicit expertise with explicit, versioned decision architecture. That sounds technical, but it's a business concept.

Concretely: documents, payments and master data are consolidated, checked against defined rules, and handed over as documented decision acts. Not as raw data, but as verified, reasoned decision proposals.

Your target systems - [DATEV](https://www.datev.de/), SAP, whatever they may be - remain the leading systems. The Decision Layer sits in front of them and ensures that only verified, reasoned decisions reach the target system.

## Three Concrete Impacts

First: Preventive elimination of professional errors. The agent doesn't just check formally (amount, date, account number), but substantively (collective agreement, tax class, social security obligation). Errors are caught before they are posted.

Second: Consistent application of rule sets across locations. When a corporation runs payroll in five cities, there are five slightly different interpretations of the same rules. The Decision Layer eliminates this variance.

Third: Traceable reasoning for every decision. The basis is the decision act per posting - the immutable record with input/document, applied business rule including version, confidence, result, timestamp, and contestation path. At the next payroll tax audit, you can show for every posting: what input data was available, which rules were applied, why this decision was made. This is not reporting - this is structural audit readiness.

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Free eBook: AI in Finance</p>
<p class="text-body text-gosign-text mb-4">Compliance, external auditors, and Decision Layer - the governance handbook for finance leaders.</p>
<a href="/en/ebook/ai-finance-governance-handbook/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Download for free</a>
</div>

## Why This Is Not a Chatbot

The Decision Layer is not a chatbot that answers payroll questions. It is an architectural layer that sits between input data and the booking system. It processes documents, checks against rules, and produces reasoned decision proposals.

[Human-in-the-loop](/en/governance/) means: Final approval stays with the human. But the preparation - consolidating data, applying rules, documenting reasoning - that's what the agent does. Faster, more consistently, and without knowledge loss.

<div class="overflow-x-auto">

| Aspect | Without Decision Layer | With Decision Layer |
|--------|----------------------|---------------------|
| Rule application | Implicit, person-dependent | Explicit, versioned |
| Consistency across locations | Variable | Identical |
| Correction postings | 3 - 8% of all postings | < 1% |
| Audit preparation | Manual reconstruction | Automatic documentation |
| Knowledge transfer | Months of onboarding | Rule sets are self-documenting |
| Compliance evidence | Sample-based | Complete decision trail |

</div>

## The Same Architecture for Any Document-Driven Process

The Decision Layer is not limited to payroll. The same architecture works for any process where documents must be checked against rules and decisions must be documented: contract management, compliance review, certificate generation, invoice processing.

At Gosign, we build the [Decision Layer as part of our AI agent infrastructure](/en/services/ai-agents/). From concrete process to productive agent in 4 - 6 weeks - with complete audit trail and Governance by Design.

→ [The Decision Act: Why Every AI Decision Must Be Contestable](/en/magazine/decision-act-contestable-ai-decisions/)

--- Decision Layer & Shadow AI: Control Instead of Chaos ---
> How the Decision Layer separates analysis from decision - and why that solves shadow AI, convinces works councils, and enables scaling.

## Two Problems. One Architecture.

Shadow AI and inadequate governance are the two largest obstacles to scaling AI in enterprises in 2026. The first problem: employees use public AI tools without oversight because the organization offers no alternative. The second problem: even when the organization does provide AI, the architecture that separates analysis from decision is missing.

The Decision Layer solves both problems. It is the governance layer that defines who may decide what: human, rule engine, or AI. And it is simultaneously the foundation for providing employees with a controlled AI offering that surpasses the public alternatives.

This article explains why shadow AI is the risk of the hour, how the Decision Layer works, the role data classification plays, and why without this architecture neither works councils (Betriebsrat), nor auditors, nor the board will approve AI scaling.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">At a Glance - Shadow AI and the Decision Layer</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Shadow AI - uncontrolled use of public AI tools by employees - is the shadow IT of 2026, causing data leakage, GDPR risk, and zero traceability.</li>
<li>Banning AI fails. The solution is a governed internal AI portal that surpasses public alternatives in functionality and security.</li>
<li>The Decision Layer separates analysis from decision: AI can analyze, but who acts on it is defined per micro-decision (human, rule set, or AI).</li>
<li>A four-tier data classification scheme controls model routing - confidential data never reaches a public model.</li>
<li>Without governance-first architecture, neither works councils, auditors, nor the board will approve AI scaling.</li>
</ul>
</div>

## Shadow AI: the Underestimated Risk

Shadow AI is the shadow IT of 2026. The term describes the uncontrolled use of public AI services by employees, without IT knowledge, without governance, without an audit trail.

The reality in most organizations: employees use public AI tools for their daily work. They draft emails, summarize reports, analyze contracts, create presentations. Not out of malice, but because these tools make them more productive. And because their employer offers no equivalent alternative.

The problem is not the usage itself. The problem is what happens in the process:

**Data leakage.** Every input into a public AI tool leaves the corporate network. Contract terms, financial data, personnel information, strategic plans. Everything entered into a prompt is beyond your control.

**No traceability.** Which employee submitted which data to which tool? Nobody knows. There is no audit trail, no logging, no possibility of retrospective review.

**No quality control.** Results from public AI tools feed into business decisions without any visibility into the basis on which they were generated. A contract draft partially produced by AI. Who reviews the clauses?

**GDPR risk.** Personal data transmitted to public AI services may constitute a reportable data protection incident. Not theoretically, but under current legal interpretation.

The solution is not prohibition. Bans fail in practice. They get circumvented, ignored, or undermined. The solution is a better offering: an internal AI portal that is functionally at least equivalent, but equipped with governance, data protection, and an audit trail. What such a portal looks like is described in the article [Enterprise AI Portal: Four Open-Source Interfaces Compared](/en/magazine/enterprise-ai-chat-interface/).

## The Decision Layer: Analysis Is Not Decision

The Decision Layer is the architectural principle that separates analysis from decision. An AI model can analyze: summarize data, detect patterns, calculate probabilities, issue recommendations. But the decision of whether and how to act on that analysis is a separate question. The Decision Layer answers it.

The principle: every business process is decomposed into micro-decisions. For each individual micro-decision, it is defined in advance who decides:

```
Incoming transaction
│
┌──────────┐
│ Decision  │
│  Layer    │
└──────────┘
┌────┼────────────┐
▼    ▼            ▼
RULE   AI        HUMAN
```

**HUMAN:** The architecture enforces human review. For discretionary decisions, discrimination risk, employee representation matters, and value thresholds above defined limits. The agent provides full context and a recommendation - but a human decides. This escalation is technically enforced, not organisationally agreed.

**RULE SET:** The decision is deterministic - there is no room for interpretation. The collective agreement states X, so X applies. A deadline expires on date Y, so rule Z triggers. Rule sets are versioned: every change creates a new version, the previous one remains traceable. Here, the agent is an executor - not because it cannot do more, but because there is nothing to interpret.

**AI AUTONOMOUS:** The agent makes independent decisions - because it is confident enough, has permission, and demonstrably performs the task better than manual processing. It interprets documents, classifies situations, evaluates context, and recognises patterns. This is not if-then-else - this is judgment within defined guardrails. Confidence Routing controls: high confidence and low risk leads to autonomous decision. Low confidence or high risk leads to escalation to a human. This Confidence Routing is precisely what distinguishes the Decision Layer from RPA.

Four principles make the Decision Layer effective:

**Explicit, versioned rules.** Every decision rule has an ID, a version, a validity date, and a scope. When a company agreement (Betriebsvereinbarung) changes, a new rule version is created. During an audit, it is traceable which rule was in effect at the time of the decision.

**Architecturally enforced human-in-the-loop.** For defined decision types, the system cannot proceed without human approval. This is technically enforced, not organizationally agreed upon. An agent cannot bypass this review because the architecture does not permit it, not because a policy prohibits it.

**Audit trail per micro-decision - the decision act.** Every individual micro-decision generates an immutable decision act: input, applied business rule including version, confidence score, model version, routing decision, outcome, timestamp, and contestation path. This is not retrospective documentation. It is the technical record of the decision process - and it makes the explanation of the individual decision under Art. 86 of the EU AI Act answerable.

**Company agreements as system constraints.** Works council requirements are not implemented as organizational guidelines, but as technical rules in the Decision Layer. The system cannot bypass the company agreement (Betriebsvereinbarung) because it is part of the system logic. The works council can trace every decision in the audit trail.

## Data Classification as the Foundation

Before the Decision Layer can take effect, a fundamental question must be answered: Which data may be processed by which AI model? The answer is provided by a four-tier classification scheme:

| Tier | Label | Examples | Permitted AI Processing |
|---|---|---|---|
| 1 | Public | Press releases, website content | All models, including public APIs |
| 2 | Internal | Presentations, process documents, internal policies | EU cloud or self-hosted models |
| 3 | Confidential | HR data, financial data, contracts, customer data | Self-hosted only or with PII anonymization |
| 4 | Strictly confidential | M&A documents, patents, board communications | On-premises only, no cloud model |

The classification automatically determines model routing. When an employee asks a question about a contract (tier 3), the system automatically routes the request to a self-hosted model or anonymizes the data before handoff. A public model is not an option for tier-3 data. The architecture ensures this is technically impossible, not merely organizationally prohibited.

Data classification is not a one-time task. It must be integrated into existing processes: every new document, every new data source, every new process receives a classification. Ideally, this happens automatically, based on document type, content recognition, and organizational assignment.

Without data classification, the foundation for every subsequent governance measure is missing. It is the first decision that must be made, before model selection, before building the [infrastructure](/en/services/infrastructure/).

## The Five Pillars of AI Governance

Data classification is the foundation. Five pillars build on it to form a complete AI governance framework:

**1. Access control.** Who may use which AI functions? Which assistants, which knowledge bases, which agents are available to which roles? Access control mirrors the existing organizational structure: HR sees HR assistants, Finance sees Finance assistants. SSO integration ensures no separate credentials need to be managed.

**2. Audit and logging.** Every interaction with the AI system is logged. Not to monitor employees, but to ensure traceability of business decisions. Who asked which question, when? Which model responded? Based on which sources? The audit trail is the foundation for internal audit, financial review, and compliance evidence. The [governance reference architecture](/en/governance/reference-architecture/) describes the technical implementation in detail.

**3. Human oversight.** The architecture defines where human review is required. This is not a generic requirement. It is a differentiated decision per micro-decision. Routine classifications do not need a human reviewer. Personnel decisions with discrimination potential always do. The granularity of this differentiation distinguishes effective governance from bureaucratic governance.

**4. Quality assurance.** AI results must be verified, not every single one, but systematically. Spot checks, user feedback, automated evaluation. Does the model hallucinate? Are source references correct? Are rule applications accurate? Quality assurance is an ongoing process, not a one-time test.

**5. Compliance and reporting.** The [EU AI Act](/en/magazine/eu-ai-act-2026-enterprises/) requires technical documentation, risk classification, and conformity assessment for high-risk AI systems from 2 August 2026 under current law (with a postponement to 2 December 2027 provisionally agreed under the Digital Omnibus of 7 May 2026, formal adoption still pending). AI governance must incorporate these requirements from the outset, not retroactively. Regular reports on usage, model performance, decision quality, and compliance status form the basis for management oversight.

## Why the Decision Layer Is the Key to Scaling

Organizations that want to scale AI, from one pilot project to ten production agents, from one department to the entire organization, hit a hard limit without a Decision Layer. Not a technical limit, but an organizational one.

**The works council (Betriebsrat) will not consent.** In Germany, works councils have co-determination rights (Mitbestimmungsrechte) for any AI deployment that monitors employee behavior or makes decisions affecting employees. Without traceable decision logic, without documented human-in-the-loop, without company agreements (Betriebsvereinbarungen) as system constraints, no works council will give its approval. The Decision Layer delivers exactly the transparency and controllability the works council requires. For organizations operating across multiple European jurisdictions, similar employee representation bodies exist with comparable requirements.

**Internal audit will not sign off.** Auditors and internal reviewers need traceability. When an AI agent generates bookings, evaluates contracts, or prepares personnel decisions, the decision path must be auditable. Without an audit trail, every agent decision is an audit risk. The Decision Layer automatically generates the evidence auditors need.

**The board will not approve the budget.** Pilot projects are funded from innovation budgets. Scaling requires capital investment, and that demands a business case with defensible figures. The Decision Layer delivers the data: throughput times, error rates, cost per transaction, escalation rates. Without these data points, AI remains a cost line without demonstrable return.

The sequence is non-negotiable: governance first, then scaling. Not the other way around.

## Cookieless and Privacy by Design

An enterprise AI portal should protect not only the data in user queries, but also the usage itself. This means: no tracking, no analytics cookies, no behavioral analysis.

**SSO instead of separate accounts.** Employees authenticate via the organization's existing identity management. No separate passwords, no separate user profiles with a third-party provider.

**No tracking cookies.** The internal AI portal uses no cookies for behavioral analysis. Usage data is collected exclusively for the audit trail, not for marketing, not for product optimization by third parties, not for profiling.

**Usage data for audit purposes only.** Which employee submitted which request is logged, but exclusively for governance purposes: traceability, compliance, quality assurance. Access to these data is restricted to authorized roles (IT security, data protection officer, internal audit). Line managers do not see individual queries from their employees.

**Privacy by design.** Data protection requirements are built into the architecture, not bolted on afterward. PII anonymization, data classification, model routing, all these mechanisms operate automatically, based on the classification of the data, not on the discipline of the users.

This approach satisfies not only the data protection officer but also the works council (Betriebsrat): the system does not monitor employees. It documents business decisions.

---

**📘 Enterprise AI Infrastructure Blueprint 2026 - Article Series**

| ← Previous | Overview | Next → |
|:---|:---:|---:|
| [From Chatbots to AI Agents: MCP, A2A and Multi-Agent Systems](/en/magazine/ai-agents-enterprise-guide/) | [Overview](/en/magazine/ai-infrastructure-blueprint-2026/) | [What AI Really Costs: TCO Comparison for Enterprises](/en/magazine/ai-costs-tco-comparison/) |

*All articles in this series: [Enterprise AI Infrastructure Blueprint 2026](/en/magazine/ai-infrastructure-blueprint-2026/)*

---

[Decision Layer](/en/decision-layer/) is Gosign's central governance component. Model-agnostic, works-council-compatible, with a complete audit trail and a decision act per micro-decision - contestable under [Art. 86 of the EU AI Act](/en/magazine/decision-act-contestable-ai-decisions/). More on the [governance architecture](/en/governance/).

<a href="/en/contact/" target="_blank" rel="noopener noreferrer">Book a consultation</a>. 30 minutes to determine how a Decision Layer for your processes should look and how shadow AI in your organization can be addressed in a controlled manner.

--- Decision Layer vs. SAP Joule vs. Copilot ---
> SAP Joule and Microsoft Copilot are AI agents. The Decision Layer is the governance layer above them. Why enterprise organizations need both.

## The Confusion

Enterprise decision-makers hear about SAP Joule, Microsoft Copilot, Google Gemini, internal GPT deployments - and wonder: Which one do I need, and where does a Decision Layer fit in?

The answer is simpler than it seems: Joule, Copilot, and others are AI agents - they execute tasks. The [Decision Layer](/en/decision-layer/) is not an alternative to these agents. It is the governance layer that sits above them and controls what these agents are allowed to do.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">At a Glance - Decision Layer vs. Enterprise Agents</p>
<ul class="text-body text-gosign-text space-y-2">
<li>SAP Joule and Microsoft Copilot are AI agents that execute tasks. The Decision Layer is the governance layer above them that controls what they may do.</li>
<li>Neither Joule nor Copilot offer built-in mechanisms for works council agreements, EU AI Act (UK: UK AI regulatory framework) compliance, or audit-ready decision trails.</li>
<li>The Decision Layer is model- and agent-agnostic - it works with any agent, including open-source models.</li>
<li>Enterprise organizations in regulated environments need both: an agent for execution and a Decision Layer for governance.</li>
<li>Agents are interchangeable. Governance is infrastructure.</li>
</ul>
</div>

## Agent vs. Governance Layer

An AI agent can execute a task: summarize a document, create a booking proposal, answer a policy question. What the agent cannot do: decide whether it may execute this task autonomously or whether a human must intervene.

SAP Joule can propose a salary adjustment in SuccessFactors. But Joule does not decide whether this proposal may go directly into the system or whether the works council (Betriebsrat) has co-determination rights. Joule has no concept of works council agreements. And Joule's audit logging records actions and source citations - but not a decision act at the business-rule level that captures which collective agreement clause, in which version, carried the decision.

Microsoft Copilot can create an onboarding document. But Copilot does not decide which pay grade the collective agreement requires, whether the works council must approve, or whether the data protection requirements of the specific location are met.

The Decision Layer handles exactly this governance.

## How the Decision Layer and Enterprise Agents Work Together

The Decision Layer decomposes every business process into individual decision steps and defines for each step: human, ruleset, or AI. When SAP Joule makes a booking proposal, that proposal passes through the Decision Layer before it takes effect in the target system.

The Decision Layer checks: Is the proposal consistent with versioned rule sets? Is the confidence above the threshold? Does the decision touch an area subject to co-determination (Mitbestimmung)? Is human-in-the-loop required?

If everything checks out: The proposal goes to the target system. The audit trail documents the decision.

If not: The workflow pauses. A human receives the proposal, the applied rule, the confidence score, and the reason for escalation. They decide. Their decision is also documented.

## Why Enterprise Organizations in Germany Need Both

SAP Joule and Microsoft Copilot are increasingly being rolled out in German enterprises. But deployment encounters three hurdles that the agent alone cannot solve:

First: Works councils demand transparency and co-determination rights over AI decisions. Neither Joule nor Copilot offer built-in mechanisms for works council agreements as technical constraints.

Second: The EU AI Act requires documented governance for high-risk AI systems from 2 August 2026 under current law (with a postponement to 2 December 2027 provisionally agreed under the Digital Omnibus of 7 May 2026, formal adoption still pending) - and HR processes fall under this category. The obligations cover risk analysis, documentation, transparency, and human oversight - and, under Art. 86, the right of affected persons to an explanation of the individual decision, answerable only through a decision act per micro-decision. Enterprise agents alone do not fulfill this.

Third: External auditors and internal compliance need traceable decision paths. An agent that "makes a suggestion" without a documented decision trail is an audit risk.

The Decision Layer complements SAP Joule and Microsoft Copilot with exactly these three dimensions: works council readiness, AI Act compliance, and audit readiness.

## The Distinction at a Glance

| Capability | SAP Joule | Microsoft Copilot | Decision Layer |
|---|---|---|---|
| Task execution | Yes | Yes | No (governance only) |
| Works council agreements as technical constraints | No | No | Yes |
| EU AI Act compliance documentation | No | No | Yes |
| Audit-ready decision trail | No | No | Yes |
| Decision act per micro-decision (business rule + version) | No | No | Yes |
| Confidence Routing with escalation | No | No | Yes |
| Human-in-the-Loop (architecturally enforced) | No | No | Yes |
| Model-agnostic | No (SAP ecosystem) | No (Microsoft ecosystem) | Yes |

SAP Joule is the agent within the SAP ecosystem. Microsoft Copilot is the agent within the Microsoft ecosystem. The Decision Layer is the model- and agent-agnostic governance layer that sits above both.

Agents are interchangeable. Governance is infrastructure.

→ [Decision Layer in detail](/en/magazine/decision-layer-explained/)

→ [The Decision Act: Why Every AI Decision Must Be Contestable](/en/magazine/decision-act-contestable-ai-decisions/)

→ [Reference Architecture](/en/governance/reference-architecture/)

<a href="/en/contact/" target="_blank" rel="noopener noreferrer">Schedule a consultation</a> - We'll show you how the Decision Layer works within your existing system landscape.

--- Hosting DeepSeek in Your Own Infrastructure ---
> How enterprises deploy the DeepSeek family (R1, V4-Flash, V4-Pro) and other LLMs GDPR-compliant on Azure, GCP or self-hosted. Architecture, data sovereignty, decision-routing over single-champion.

## Why DeepSeek Matters for Enterprises

DeepSeek's open-source models demonstrated that capable LLMs need not come exclusively from OpenAI or Google. The DeepSeek family spans **R1 (January 2025, MIT licence)** through **V4-Flash (April 2026, 284B/13B active MoE, MIT)** to **V4-Pro (1.6T/49B active, 1M context, MIT)** and reaches **GPT-5.5 / Claude Opus 4.7 territory** in benchmarks - V4-Pro approaches frontier closed-source performance under MIT licence, at significantly lower operating costs and with full transparency over the model code.

**Update May 2026:** DeepSeek V4-Pro (1.6T total / 49B active MoE) and V4-Flash (284B total / 13B active) were released as preview on April 24, 2026 under MIT license. For new deployments, V4-Flash is the typical workhorse, while V4-Pro fits hyperscaler-class setups or runs via API/hosted for smaller deployments. The R1 architecture remains mature and production-ready but is being replaced by V4-Flash for new deployments. Details in the [Self-hosted Open-Source AI 2026 article](/en/magazine/self-hosted-open-source-ai-2026/).

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">At a Glance - Enterprise DeepSeek Hosting</p>
<ul class="text-body text-gosign-text space-y-2">
<li>DeepSeek R1 is open-source (MIT license) and can run fully self-hosted in Azure, GCP, or on-premise with zero data egress.</li>
<li>Self-hosting eliminates the GDPR compliance risk of API-based use, where data flows to China. The model itself is not the risk - the API is.</li>
<li>Three hosting options (Azure, GCP, self-hosted) are technically equivalent; the choice depends on existing IT landscape and compliance requirements.</li>
<li>A model-agnostic architecture prevents DeepSeek vendor lock-in: when a better model appears, it slots in without rebuilding.</li>
<li>IDC (2024) estimates that 42% of large enterprises in Europe plan to deploy at least one open-weight LLM on private infrastructure by end of 2026.</li>
</ul>
</div>

For enterprises, this matters because it creates genuine choice: rather than committing to a single LLM vendor, organisations can run multiple models in parallel, compare them and deploy the best fit for each use case.

The real question is not whether DeepSeek is good enough. The question is how an enterprise operates LLMs in a way that ensures data sovereignty, compliance and future-proofing - regardless of which model is currently leading.


## Three Hosting Options Compared

### Azure: Enterprise Integration as Strength

Azure AI Foundry offers DeepSeek as a managed deployment. The advantage for organisations with existing Microsoft environments: integration with Azure Entra ID (formerly Azure AD), established network and security configurations, and region selection for EU data residency. GPU instances (A100, H100) are available as pay-as-you-go or provisioned throughput.

The drawback: vendor lock-in at the Azure level. Switching to GCP or self-hosted later requires rebuilding the deployment layer - unless the architecture is designed to be model- and platform-agnostic from the start.

### GCP: Flexibility and Kubernetes-Native

Google Cloud Platform offers managed deployments for open-source models via Vertex AI. The strength lies in its Kubernetes-native architecture: organisations already using GKE (Google Kubernetes Engine) can run LLMs as container workloads alongside existing services. TPU options provide an alternative to NVIDIA GPUs.

### Self-Hosted: Maximum Control

For enterprises with the strictest data protection requirements - in financial services or healthcare, for instance - self-hosting is the consistent choice. DeepSeek models run on dedicated servers or in a private data centre with zero cloud dependency. The trade-off: higher operational effort for hardware management, updates and scaling.

| Criterion | Azure | GCP | Self-Hosted |
|---|---|---|---|
| Setup | Managed (AI Foundry) | Managed (Vertex AI) | Manual (bare-metal/VM) |
| EU Data Residency | Germany West Central | europe-west3 | Own data center |
| GPU Availability | A100, H100 (pay-as-you-go) | A100, H100, TPU | A100, H100 (purchase/lease) |
| Vendor Lock-in Risk | High (Azure-specific) | Medium (Kubernetes-portable) | None |
| Operational Effort | Low | Low-Medium | High |
| Best For | Microsoft-centric orgs | Kubernetes-native orgs | Maximum data sovereignty |

All three options are technically equivalent. There are no architectural compromises with self-hosting. The decision depends on the existing IT landscape, compliance requirements and internal operating model.


## Why the Hosting Decision Is Not the Most Important One

Most articles about LLM hosting end at the hosting decision. But for enterprises, hosting is merely the foundation - the real questions come after.

How is it governed which model serves which use case? How are prompts and responses logged without compromising employee data? How is the works council (Betriebsrat) given transparency over AI usage? How is a model switch executed without changing the interface for 5,000 employees?

These are not hosting questions. These are architecture and governance questions. And this is precisely where an enterprise AI infrastructure differs from a hosted model.


## Model-Agnostic Architecture as Strategy

The LLM landscape shifts faster than any enterprise procurement cycle. What is state-of-the-art today may be superseded by a new model in six months. Anyone who builds their entire infrastructure on a single frontier model - whether DeepSeek V4-Pro, GPT-5.5 or Claude Opus 4.7 - carries a strategic risk. A model-agnostic decision-routing layer (see [When which model?](/en/magazine/ai-models-comparison-2026/)) absorbs the next generational shift as a configuration change rather than a re-engineering effort.

A [model-agnostic architecture](/en/services/infrastructure/) decouples the usage layer from the model layer. Employees use a unified chat interface. Behind it, an orchestration layer routes per micro-decision rather than committing to a champion model: **Mistral Small 3.2** (24B, Apache 2.0, RTX 4090) as the volume workhorse for 50-70% of decisions (classification, extraction); **DeepSeek V4-Flash / V4-Pro** (MIT) or **gpt-oss-120b** (Apache 2.0) for on-prem reasoning; **Claude Opus 4.7 / GPT-5.5** (cloud) for frontier reasoning and agentic workflows; **Gemini 3.1 Pro** (cloud) for multimodal applications; **Qwen 3 Coder / DeepSeek Coder V4** for on-prem code generation. [Llama](https://llama.meta.com/) and [Mistral](https://mistral.ai/) round out the stack for specialised domains.

Model switches, model comparisons and A/B testing happen in the orchestration layer - transparent to users, auditable for IT, traceable for the works council (Betriebsrat).


## DeepSeek as a Building Block, Not a Platform

DeepSeek is a capable model. But no model alone solves the enterprise problem. What organisations need is not a hosted LLM but an infrastructure in which LLMs operate as components - embedded in [Governance by Design](/en/governance/), integrated with existing systems, extensible with [AI agents](/en/services/ai-agents/) that process documents and orchestrate workflows.

The [Decision Layer](/en/finance-ai-agents/) separates LLM analysis from business decisions. The model prepares, the human decides - with a complete audit trail.

At Gosign, we build this [AI infrastructure](/en/services/infrastructure/): model-agnostic, GDPR-compliant, on Azure, GCP or self-hosted. DeepSeek is one of many building blocks. The architecture makes the difference.

--- DevOps Runbook Series: Security for the Self-Hosted Stack ---
> Six-part DevOps runbook series: Supabase, Next.js, Edge Functions, Trigger.dev, Claude Code audits and security baseline.

This series provides six hands-on runbooks for operating a self-hosted app stack securely. It is written for DevOps teams running Supabase, Next.js and related technologies in production who want to secure their infrastructure systematically.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">At a Glance - DevOps Runbook Series</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Six runbooks cover the full self-hosted stack: Supabase, Next.js, Edge Functions, Trigger.dev, Claude Code audits and Security Baseline.</li>
<li>Each article contains concrete implementations with real code, verifiable conditions and downloadable Claude Code checklists.</li>
<li>The series builds layer by layer - from the platform foundation (Supabase) to a machine-readable YAML baseline for the entire stack.</li>
<li>Target audience: DevOps engineers, CTOs, security engineers and developers building on Supabase and Next.js.</li>
<li>According to the SANS Institute (2024), organizations with a machine-readable security baseline detect configuration drift 14 times faster.</li>
</ul>
</div>

## Why a systematic approach matters

Self-hosting gives you control over data and infrastructure. That control comes with responsibility: every component has its own security requirements, and dependencies between layers stay invisible when reviewed in isolation.

A systematic, machine-readable security approach across all layers makes the difference. According to the SANS Institute (2024), organizations with a machine-readable security baseline detect configuration drift on average **14 times faster** than teams without a baseline.

This series walks you through the stack layer by layer and concludes with a YAML-based baseline that consolidates all rules from the individual runbooks.

## Series overview

| Part | Article | Focus area | Key deliverable |
|------|---------|------------|-----------------|
| 1 | [Supabase Self-Hosting Runbook](/en/magazine/supabase-self-hosting/) | Platform foundation | Server architecture, Docker Compose, RLS |
| 2 | [Running Next.js on Supabase Securely](/en/magazine/nextjs-supabase-secure-setup/) | App layer | Auth, Middleware, environment separation |
| 3 | [Deploying Supabase Edge Functions Securely](/en/magazine/supabase-edge-functions-secure/) | Integrations | Webhooks, signatures, CORS |
| 4 | [Running Trigger.dev Background Jobs Securely](/en/magazine/trigger-dev-background-jobs/) | Async processing | Tasks, idempotency, concurrency |
| 5 | [Claude Code as Security Control in DevOps Workflows](/en/magazine/claude-code-security-devops/) | Automated audits | Custom commands, headless mode |
| 6 | [Security Baseline for the Entire Stack](/en/magazine/security-baseline-stack/) | Full-stack baseline | YAML, automated checks |

## The articles in detail

**Part 1 - Supabase Self-Hosting Runbook.** Describes a two-server architecture (production and audit), Docker Compose with version-pinned images, service configuration for seven components, and Row Level Security as a requirement on all public tables.

**Part 2 - Running Next.js securely.** Covers the app layer on top of Supabase: auth flow with PKCE, middleware for route protection, strict environment separation between server and client, and secure API route patterns.

**Part 3 - Deploying Edge Functions securely.** Focuses on webhook processing with signature verification, CORS configuration, input validation in the Deno runtime, and secure secret management for third-party integrations.

**Part 4 - Trigger.dev Background Jobs.** Describes the self-hosted setup of Trigger.dev v3, idempotent task definition, concurrency control, retry strategies, and secrets isolation between tasks.

**Part 5 - Claude Code as security control.** Shows how to use Claude Code as an automated audit tool in DevOps workflows: custom commands, headless audit runs, and CI pipeline integration.

**Part 6 - Security Baseline.** Consolidates all rules from articles 1 through 5 into a machine-readable `security-baseline.yml`. Includes deterministic check scripts and integration with the Claude Code audit.

## Who this series is for

- DevOps engineers running self-hosted infrastructure
- CTOs and technical leads evaluating self-hosting vs. managed services
- Security engineers auditing app stacks
- Developers building on Supabase and Next.js

## How to use this series

- Read the articles in order from 1 to 6, as they build on each other
- Download the Claude Code checklists at the end of each article
- Implement the recommendations layer by layer in your environment
- Use the security baseline from article 6 as a daily monitoring gate

--- DPA for AI Agents: What Standard Contracts Miss ---
> Why standard DPAs fall short for enterprise AI infrastructure. With a requirements checklist for HR and compliance teams.

A Data Processing Agreement (DPA) for AI infrastructure must address ten areas that standard SaaS DPAs do not cover: prompt logging policies, environment separation (dev/staging/production), model provider chains, in-flight vs. at-rest data processing, RAG embedding data protection, third-country access to production data, professional privilege compliance, PII tokenization, Decision Layer audit trails, and verifiability of technical measures.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">At a Glance - DPA for AI Infrastructure</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Standard SaaS DPAs do not cover prompt logging, model provider chains, environment separation, or PII tokenization required for AI infrastructure.</li>
<li>Ten specific gaps exist between standard contracts and AI reality - from new data categories to Decision Layer audit trails.</li>
<li>BSI (2024) notes that 68% of organizations using generative AI have not updated their data processing agreements to reflect AI-specific data flows.</li>
<li>A 25-question checklist helps HR and compliance leaders verify AI vendor readiness across seven categories.</li>
<li>This is not legal advice - it is an architecture compass that reveals infrastructure gaps behind contract gaps.</li>
</ul>
</div>

## Why Standard DPAs Fail for AI Infrastructure

A standard Data Processing Agreement governs how a service provider handles personal data on behalf of a controller. It defines purpose, data categories, technical and organizational measures, sub-processors, and retention periods. For a CRM system or HR software, that is sufficient.

Enterprise AI infrastructure creates constellations that no standard DPA covers. A language model processes prompts  - free-text inputs that can contain anything: personnel data, client information, trade secrets, even special category data under Article 9 GDPR when an employee asks a health-related question. The data flows through a chain of systems: from the frontend through an orchestration layer to the model provider, back into a database, potentially through a RAG pipeline with embedding vectors. At every station, different questions about storage, access, and deletion arise.

When you ask your AI vendor for their DPA and receive a standard document, that should raise a flag. Not because the vendor is untrustworthy, but because the specific risks of AI infrastructure require different provisions than a conventional SaaS application.

## Ten Gaps Between Standard DPAs and AI Reality

### 1. Prompt Content as a New Data Category

Standard DPAs list data categories: name, email, employee number. With AI agents, a new category emerges that cannot be predefined  - the prompt. A prompt can be a harmless question about holiday policy or a complete client letter containing personal data. The DPA must establish that the responsibility for content classification lies with the organization, not the AI provider, while the provider must demonstrate technical measures that protect all input content regardless of sensitivity.

### 2. Logging Policy: What May Appear in Logs?

With conventional software, logging covers technical necessities. With AI infrastructure, logging takes on a different dimension: Are prompt contents logged? Are model responses stored? Are uploaded documents written into error logs?

A robust DPA for AI infrastructure must explicitly establish that production environments have request/response body logging disabled, that only technical metadata is recorded (status codes, latencies, request IDs), that debug logging is deactivated in production, and that stack traces contain no prompt or document content. This sounds obvious  - it is not. Ask your vendor about their production logging policy. If they do not have one, that is a warning sign.

### 3. Environment Separation: Dev, Staging, Production

Every enterprise setup has development, testing, and production environments. With AI infrastructure, separation is security-critical because real data can be misused as test data during development. An AI-specific DPA must establish that dev and staging environments use exclusively synthetic or anonymized data, that production access is restricted to defined roles within the EU/EEA (or your jurisdiction), and that support cases are handled only with test data approved by the organization.

### 4. Model Provider Chain Instead of Classic Sub-processors

With conventional software, a provider has sub-processors: a hosting provider, perhaps an email service. With AI infrastructure, a three-tier chain emerges: the AI infrastructure provider operates the platform, the model providers (Azure OpenAI, Google Vertex AI, Anthropic) process the prompts, and the platform providers (Supabase, Vercel) host database and frontend.

The critical point: Who is the contractual partner of the model providers? Do the models run in the AI provider's tenant or in the organization's tenant? This distinction determines whether the model provider is a sub-processor of the provider or whether the organization manages vendor relationships directly. A strong DPA clarifies this delineation explicitly.

| Component | In Client Tenant | In Provider Tenant |
|---|---|---|
| Azure Entra ID (SSO) | ✓ Client | - |
| Azure OpenAI / Vertex AI | ✓ Client | - |
| Supabase (Database) | ✓ Client | - |
| Vercel (Hosting) | ✓ Client | - |
| Plane (Ticket System) | - | ✓ Provider |
| GitHub (Code Hosting) | - | ✓ Provider |
| Google Workspace (Communication) | - | ✓ Provider |

*Components in the client tenant are managed by the client in their own vendor registry. Components in the provider tenant are subject to the sub-processor list in the DPA.*

### 5. In-flight vs. At-rest: Where Does Data Reside?

With conventional software, the question is simple: data resides in a database. With AI infrastructure, two processing modes exist. In-flight processing: the prompt is sent to the model provider, processed, and the response returned  - no persistent storage at the provider. At-rest storage: chats, uploads, and embeddings are stored in a database (e.g., Supabase)  - persistent and associated with the user.

The DPA must establish separate provisions for both modes. For in-flight: Is content retention at the provider disabled? Is data used for training purposes? For at-rest: Where is the database located? Who has access? How does deletion work?

### 6. RAG and Embeddings: Vector Data as a New Challenge

Retrieval Augmented Generation (RAG) makes enterprise documents searchable by AI. Documents are converted into embedding vectors and stored in a vector database. These vectors are a new data category: they contain no readable text but can, under certain circumstances, allow inferences about original content. The DPA must treat embeddings as personal data when generated from documents containing personal information. Access control, deletion, and tenant separation must also apply to the vector database.

### 7. Third-Country Access to Production Data

Many AI providers work with distributed teams. When a developer from a third country has access to the production environment, this constitutes a data transfer under GDPR  - even if no data is physically transmitted. An AI-specific DPA must define that production access is restricted to the EU/EEA (or an adequate jurisdiction), that dev/staging access from third countries is permissible (because only synthetic data is present), that RBAC provides separate admin groups for production and dev/staging, and that an exception procedure exists requiring written authorization from the controller.

**(UK:** Post-Brexit, the UK operates its own data protection framework (UK GDPR). The adequacy decision from the EU covers most scenarios, but organizations should verify whether their specific AI provider setup requires additional provisions.**)**

**(US:** Organizations subject to US state privacy laws (CCPA/CPRA, Colorado Privacy Act, etc.) should map these DPA requirements against their applicable framework. The concept of "processor" vs. "service provider" varies by jurisdiction.**)**

### 8. Professional Privilege in AI Platforms

For regulated industries  - law firms, tax advisors, auditors, healthcare organizations, and enterprises with processes subject to professional secrecy  - AI processing requires explicit DPA provisions. In Germany, § 203 StGB (professional secrecy) requires written confidentiality commitments for all personnel with access. The EU-wide equivalent is the professional privilege doctrine combined with sector-specific regulations. **(UK:** Legal Professional Privilege and medical confidentiality apply.**)** Standard confidentiality clauses are not sufficient for these contexts.

### 9. PII Tokenization as an Optional Module

Input and output filters that detect personal data and pseudonymize it before forwarding to the model provider add an additional layer of protection. This PII tokenization is not necessary in every setup, but the DPA should provide for it as an optional module. Important: if reversible re-identification is possible, the DPA must govern who has access to the mapping table, how mapping keys are stored and encrypted, and that re-identification only occurs for a defined purpose after documented authorization.

### 10. Audit Trail and Decision Layer

AI agents make or prepare decisions. Every one of these decisions must be traceable  - not only for data protection, but also for internal audit, external auditors, and employee representative bodies. The [Decision Layer](/en/decision-layer/) decomposes every process into individual decision steps and defines for each step: human, rule engine, or AI. The DPA must anchor the audit trail as a contractual component: What data is logged per decision? How long is it retained? Who has access?

## The Checklist: 25 Questions for Your AI Vendor

The following checklist translates the ten gaps into concrete verification questions.

**[View requirements checklist: 25 verification questions for AI DPAs →](/en/governance/dpa-checklist/)**

### A  - Data Categories and Processing Purposes

1. Are prompt contents and model responses listed as distinct data categories in the DPA?
2. Is it established that content classification responsibility lies with the organization, not the provider?
3. Are embeddings/vectors classified as potentially personal data?
4. Does the DPA address special categories under Article 9 GDPR that may arise through user inputs?

### B  - Logging and Monitoring

5. Is request/response body logging disabled in the production environment?
6. What metadata is recorded (status codes, latencies, request IDs)?
7. Is debug logging verifiably disabled in production?
8. Are stack traces and error messages configured to exclude content data from logs?
9. Is verification of logging settings part of the release process?

### C  - Environment Separation and Access

10. Do separate environments exist (dev, staging, production) with distinct data policies?
11. Do dev/staging environments contain exclusively synthetic or anonymized data?
12. Is production access restricted to authorized roles within the EU/EEA?
13. Does a documented exception procedure exist for support cases involving data?

### D  - Model Providers and Sub-processors

14. Is the delineation clear: Which providers are sub-processors of the provider, and which operate in the organization's tenant?
15. Is content retention at model providers disabled?
16. Is the exclusion of training data usage contractually documented?
17. Where are the model endpoints located (EU region, US, other)?

### E  - Data Storage and Deletion

18. Is it established where persistent content data is stored (database, region, provider)?
19. What backup retention applies, and how are deleted data handled within backups?
20. Can individual users delete their own data within the application?

### F  - Regulated Industries

21. Does the DPA contain provisions for professional privilege compliance (§ 203 StGB or jurisdiction-specific equivalent)?
22. Are confidentiality commitments in place for all personnel with access?
23. Is PII tokenization available as an optional module?

### G  - Governance and Verifiability

24. Is an audit trail for agent decisions anchored as a contractual component?
25. Can technical and organizational measures be evidenced on request (configuration documentation, redacted log excerpts)?

## From Checklist to Architecture

These 25 questions are not a legal tool. They are an architecture compass. Every question your AI vendor cannot answer reveals a gap in their infrastructure  - not just in their contract.

At Gosign, we have built these requirements into the architecture: [environment separation with production lockdown](/en/magazine/ai-hosting-strategies-enterprise/), logging without content data, model providers in the client tenant, [Decision Layer](/en/decision-layer/) with complete audit trail. Not because a client demanded it, but because enterprise AI without these foundations is not auditable.

If you want to assess how your current AI infrastructure scores against these 25 points  - or if you are evaluating a new platform  - we are happy to discuss.

**[Schedule a conversation →](/en/contact/)**

--- Enterprise AI Portals: Five Open-Source Interfaces Compared ---
> LobeChat, OpenWebUI, LibreChat, chatbot-ui and very-ai - five enterprise AI portals compared. Features, SSO, PII protection, governance, self-hosting.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">At a Glance - Enterprise AI Portals</p>
<ul class="text-body text-gosign-text space-y-2">
<li>A chat interface alone is not enough - enterprises need portals with SSO, audit trails, assistant sharing, and agent integration to prevent shadow AI.</li>
<li>Five open-source options exist: LobeChat, OpenWebUI, LibreChat, chatbot-ui, and very-ai - each suited for different governance requirements.</li>
<li>PII detection and anonymization is the critical differentiator for regulated environments where employee data enters AI prompts.</li>
<li>Gartner (2024) reports that 55% of organizations with generative AI have no governance framework in place for its use.</li>
<li>The decisive factor for adoption is not technology but user experience - the internal portal must match or exceed public AI services from day one.</li>
</ul>
</div>

## The Problem: A Model Without an Interface

An AI model without a controlled interface is like a server without a frontend. The technology is there, but nobody can use it in an orderly way. What happens next is predictable: employees turn to public AI services, ChatGPT, Gemini, Claude.ai, with their personal accounts. They enter corporate data into systems that are outside IT's control. There is no audit trail, no data classification, no access control.

That is shadow AI. The question is not whether it is happening in your organization. The question is how pervasive it is.

The solution is not to ban AI usage. The solution is to provide an internal system that works better than the public alternatives, while running under corporate control. A simple chat interface is not enough for that. What you need is an enterprise AI portal.

## What an Enterprise AI Portal Must Deliver

An enterprise AI portal is more than a chat window. It is the central platform through which all employees interact with AI, controlled, logged, and integrated into the existing technology landscape. Six requirements distinguish an enterprise portal from a consumer chat:

### 1. Multi-Model Routing

The portal must connect multiple models simultaneously, proprietary cloud APIs and self-hosted models. The routing logic automatically decides which model serves which request: by task type, data sensitivity, and cost parameters. Employees see a unified interface. Which model operates in the background is transparent to them but traceable.

### 2. Assistant Sharing

Departments create specialized assistants, with their own system prompt, their own documents, and their own rule set. An assistant for the legal department that prepares contract reviews. An assistant for HR that summarizes application materials. An assistant for procurement that compares supplier proposals. These assistants are shared within the department, versioned, and centrally managed.

This is the critical difference from a plain chat interface: not every employee has to write prompts from scratch. Instead, they use an assistant configured and optimized by domain colleagues. This lowers the barrier to entry and raises output quality.

### 3. Agent Integration

An enterprise portal must go beyond chat. It must integrate [AI agents](/en/services/ai-agents/), specialized workflows that process documents, extract data, prepare decisions, or call external systems. The agent is triggered through the portal, its progress is displayed, and its result is documented in the portal.

### 4. SSO and Role-Based Access Control (RBAC)

Employees sign in through the existing identity management system, Azure AD, Okta, Google Workspace. No separate accounts, no separate passwords. Access control is role-based: who may use which models? Who may create assistants? Who may access which document sources? Who has access to agent workflows?

### 5. Audit Trail

Every interaction is logged. Who submitted which request and when? Which model responded? Which documents were referenced? What costs were incurred? The audit trail is exportable, for internal audit, for compliance reviews, for EU AI Act documentation.

### 6. Deployment Flexibility

The portal must be deployable in different environments: as a cloud service (Supabase, Vercel), as a container in a European data center, or on-premises. The hosting decision for the portal follows the same criteria as the hosting decision for the models (see [Hosting Strategies](/en/magazine/ai-hosting-strategies-enterprise/)).

## Open-Source Interfaces Compared

Five open-source projects have positioned themselves as candidates for enterprise AI portals: LobeChat, OpenWebUI, LibreChat, chatbot-ui and very-ai. All five are self-hosted, model-agnostic and provide a chat interface for language models. The differences lie in SSO integration, governance capabilities, PII protection and works council compatibility.

**Transparency note:** very-ai is developed by Gosign GmbH - the publisher of this article series. We present the strengths and limitations of all five portals equally. very-ai is based on a fork of chatbot-ui (MIT license) and has evolved into a standalone product through 16 enterprise extensions.

## Comparison: Five Enterprise AI Portals

| Criterion | LobeChat | OpenWebUI | LibreChat | chatbot-ui | very-ai |
|-----------|----------|-----------|-----------|------------|---------|
| **License** | Apache 2.0 | MIT | MIT | MIT | Apache 2.0 |
| **Origin** | Original project | Original project | Original project | Original project | Fork of chatbot-ui |
| **Model-Agnostic** | ✅ OpenAI, Anthropic, Google, Ollama | ✅ OpenAI, Ollama, LiteLLM | ✅ OpenAI, Anthropic, Google, Mistral | ✅ OpenAI, Anthropic, Google, Ollama | ✅ OpenAI, Anthropic, Google (Vertex AI), Ollama |
| **SSO** | ❌ Not native | OAuth 2.0 (no native Entra ID) | OAuth 2.0, OpenID Connect | ❌ Not native | ✅ Azure Entra ID native with group & permission sync |
| **PII Protection** | ❌ | ❌ | ❌ | ❌ | ✅ Detection, anonymization and re-anonymization |
| **PII per Assistant/Model** | - | - | - | - | ✅ Configurable per assistant AND per model |
| **Group Assistants** | ❌ | Community models (limited) | Shared conversations | ❌ | ✅ Controlled via Entra ID groups |
| **Audit Trail** | ❌ | Basic logging | Basic logging | ❌ | ✅ Complete, exportable (CSV/JSON) |
| **GDPR Statistics** | ❌ | ❌ | ❌ | ❌ | ✅ Anonymized usage statistics |
| **Trigger.dev Integration** | ❌ | ❌ | ❌ | ❌ | ✅ Workflow trigger from chat |
| **Thinking Level** | ❌ | ❌ | ❌ | ❌ | ✅ Extended thinking / reasoning control |
| **Web/Maps Search** | Plugin system | Web search (RAG) | Plugin system | ❌ | ✅ Integrated |
| **Docker Self-Hosted** | ✅ | ✅ | ✅ | ✅ | ✅ |
| **GitHub Stars (Feb 2026)** | ~50k | ~60k | ~20k | ~28k | New (open-source launch) |
| **Works Council Compatibility** | ⚠️ Limited (no audit, no RBAC) | ⚠️ Basic RBAC | ⚠️ Basic RBAC | ❌ No governance | ✅ Audit trail + RBAC + PII + Entra ID |

### LobeChat

LobeChat is a visually polished chat interface with a plugin architecture. Its strength lies in its plugin ecosystem and cloud API variety. For enterprise, it lacks robust RBAC, an exportable audit trail, and native agent integration. Suitable as a quick prototype or for small teams; too limited for organization-wide rollout.

### OpenWebUI

OpenWebUI is the de facto standard for Ollama-based self-hosting setups. Integration with locally running models is excellent. SSO and basic logging are available. It also includes a built-in RAG pipeline. What is missing: assistant sharing, enterprise agent integration, and centralized management for several hundred users.

### LibreChat

LibreChat is an open-source clone of the ChatGPT interface with multi-model support. SSO and basic RBAC are implemented. For organizations that want to replicate a ChatGPT-like experience internally, LibreChat is a solid starting point. The limits lie in agent integration and assistant sharing.

## very-ai - Enterprise Portal with PII Protection and Governance

very-ai is an enterprise AI portal based on chatbot-ui (MIT) that adds 16 enterprise features not found in any of the other four portals. It is developed by Gosign GmbH and available under Apache 2.0 on GitHub.

**Origin and differentiation:**
chatbot-ui provides a solid chat interface but lacks SSO integration, audit trail and PII protection. very-ai addresses exactly that: the codebase has been extended with enterprise features required for productive use in regulated environments. Attribution to the original project is documented in the NOTICES file.

**PII detection and re-anonymization:**
The core differentiator. very-ai detects personal data (names, email addresses, phone numbers, IBANs) in user prompts, replaces them with placeholders ([PERSON_1], [EMAIL_1]), sends the anonymized text to the language model and re-inserts the original data into the response. The user sees real names, the language model never did.

This PII behavior is configurable per assistant and per model: Assistant A may allow PII, Assistant B anonymizes automatically. Model X receives anonymized data, Model Y (a locally hosted model) receives raw data.

**Azure Entra ID with group sync:**
Not just authentication but automatic synchronization of Entra ID groups and roles. Employees in the Entra ID group "HR" automatically see HR assistants. Employees in "Finance" see finance assistants. No manual permission management in the portal required. When group membership changes in Entra ID, portal access changes on next login.

**Group assistants:**
Administrators create assistants and assign them to Entra ID groups. These assistants are only visible and usable by members of the respective group. This enables department-specific AI tools without a separate permission management system.

**Audit trail and GDPR statistics:**
Every interaction is logged: user, model, assistant, prompt, response, timestamp, token usage, PII mode. The audit trail is exportable (CSV, JSON) and filterable by time range and user. Usage statistics are GDPR-compliant anonymized - they show model and assistant usage without user-identifying data.

**Trigger.dev workflow integration:**
Users can trigger Trigger.dev workflows from within the chat. This connects the AI portal with the automation layer (→ Article 10: Agent Orchestration Platforms).

**Limitations (honest):**
very-ai is a new open-source project. The community is small compared to LobeChat (50k stars) or OpenWebUI (60k stars). The plugin ecosystems of the established portals are more extensive. Those looking for a portal with maximum community support and plugin variety are better served by LobeChat or OpenWebUI. Those who need PII protection, Entra ID group sync and works-council-compatible logging will currently find this combination only in very-ai.

Live demo: [veryai.de](https://www.veryai.de/)

### Which portal for which use case?

**Maximum model variety and plugin ecosystem:** LobeChat - the largest plugin system, the most active community, broad model support. Ideal for teams that prioritize flexibility and rapid innovation.

**Easiest start with Ollama:** OpenWebUI - native Ollama integration, quick installation, intuitive interface. Ideal for local LLM hosting and teams starting with open-source models.

**Maximum configurability:** LibreChat - finest control over model endpoints and parameters. Ideal for technical teams operating multiple providers with different configurations.

**Enterprise governance with PII protection:** very-ai - the only option with native PII anonymization, Entra ID group sync and complete audit trail. Ideal for regulated environments where works councils, data protection and compliance have a seat at the table.

**Evaluation and development:** chatbot-ui - clean codebase, good starting point for custom development. Note: chatbot-ui has no active enterprise development; very-ai is the enterprise evolution of this codebase.

*Most enterprises evaluate 2-3 portals in parallel using Docker containers - achievable in an afternoon. What matters is not the interface but governance capability: SSO, audit trail, PII protection and works council compatibility determine which portal makes it to production.*

## Why "Just a Chat" Is Not Enough

The difference between a chat interface and an enterprise AI portal becomes clear in operation. A comparison:

| Aspect | Chat Interface | Enterprise AI Portal |
|---|---|---|
| Usage | Individual Q&A | Organization-wide tool |
| Knowledge | Every user starts from zero | Assistants bundle domain expertise |
| Control | The user decides what to input | Routing and RBAC manage data flow |
| Traceability | None or limited | Complete audit trail |
| Integration | Standalone | Connected to SSO, agents, document systems |
| Scaling | Per user | Per organization |
| Shadow AI Risk | High (inadequate internal offering) | Low (superior internal offering) |

The central insight: shadow AI does not arise because employees act maliciously. It arises because the internal offering is worse than the public alternative. When the internal portal is as intuitive as ChatGPT but additionally offers specialized assistants, access to corporate documents, and agent workflows, there is no reason to resort to external services.

## In Practice: A Mid-Sized Organization with 2,000 Employees

A concrete example illustrates the impact. A manufacturing company with 2,000 employees faced the following starting position:

**Before the portal:** An internal survey revealed that 340 employees regularly used public AI services for work tasks. Of these, 180 with free accounts (no DPA in place), 120 with personal pro accounts (corporate data in personal accounts), and 40 with company-provided accounts (but without audit trail or access control). IT had no visibility into which data was flowing into which systems.

**Portal rollout:** Within four weeks, very-ai was deployed, connected to Azure AD for SSO, with three initial assistants (legal, HR, procurement) and a gpt-oss-120b endpoint for confidential data.

**After 90 days:**

- 15 specialized assistants created by departments
- 1,200 active users per month (out of 2,000 employees)
- Shadow AI usage down by 85% (follow-up survey)
- Complete audit trail: 47,000 logged interactions
- Identification of three processes suited for dedicated agent workflows
- Total cost (portal + hosting + cloud APIs): approximately EUR 4,800 per month

The decisive factor was not technology but adoption. The portal was embraced because it was better than the alternative, not because it was mandated.

## Five Success Factors for Rollout

From practical experience, five factors determine whether an enterprise AI portal succeeds or fails:

**1. First impressions count.** If the internal portal is slower, more cumbersome, or less capable than ChatGPT, employees will not use it again after the first attempt. Answer quality must match public services from day one.

**2. Assistants over prompts.** Most employees are not prompt engineers. They want to use a tool, not configure one. Specialized assistants prepared by domain colleagues significantly lower the barrier to entry.

**3. Visible added value.** The portal must offer something public services cannot: access to internal documents (via RAG), specialized assistants for company-specific tasks, integration into existing workflows.

**4. IT ownership, not IT control.** IT operates the portal and sets governance rules. But departments create their own assistants. This division, infrastructure centrally, content decentrally, has proven to be the most successful model.

**5. Measure and communicate.** Usage numbers, time saved, reduced shadow AI, these metrics must be collected and communicated to leadership. Without measurable results, there is no basis for the next expansion phase.

## Next Step: From Portal to Agent

The enterprise AI portal is the foundation. It gives employees access to AI, controlled and logged. The next step is integrating agents, specialized workflows that go beyond simple question-and-answer interactions. How to deploy [AI agents in an enterprise context](/en/magazine/ai-agents-enterprise-guide/), which architecture is required, and where the limits lie is covered in another article of this series.

---

Further reading: [AI Infrastructure](/en/services/infrastructure/) | [Decision Layer & Shadow AI](/en/magazine/decision-layer-shadow-ai/)

---

**📘 Enterprise AI Infrastructure Blueprint 2026 - Article Series**

| ← Previous | Overview | Next → |
|:---|:---:|---:|
| [AI Hosting: EU SaaS, German Data Center, or Self-Hosted?](/en/magazine/ai-hosting-strategies-enterprise/) | [Overview](/en/magazine/ai-infrastructure-blueprint-2026/) | [RAG & Document Intelligence: How AI Understands Your Documents](/en/magazine/rag-document-intelligence-enterprise/) |

*All articles in this series: [Enterprise AI Infrastructure Blueprint 2026](/en/magazine/ai-infrastructure-blueprint-2026/)*

---

Gosign supports organizations in selecting and deploying [Enterprise AI Portals](/en/services/infrastructure/), vendor-neutral.

<a href="/en/contact/" target="_blank" rel="noopener noreferrer">Book a consultation</a>. We show you very-ai in a live demo and discuss your rollout plan.

--- EU AI Act 2026: Status, Deadlines, Action Items ---
> EU AI Act 2026: prohibitions active, AI literacy mandatory, high-risk deadline 2 August 2026 (postponement to Dec 2027 provisionally agreed, Digital Omnibus, May 2026). Timeline, obligations, and action items.

The EU AI Act is in force. Two deadlines have passed; under current law the critical high-risk deadline falls on 2 August 2026, though following the provisional Digital Omnibus agreement of 7 May 2026 it is set to be postponed to 2 December 2027 (formal adoption still pending, as of June 2026). Here is the current status, obligations, and what enterprises should do now.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">At a Glance - EU AI Act 2026 Status for Enterprises</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Prohibited AI practices (social scoring, manipulation, emotion recognition at work) and AI literacy obligations have been legally binding since February 2025.</li>
<li>GPAI transparency and documentation obligations for deployers of general-purpose AI models are in force since August 2025.</li>
<li>The critical deadline: under current law all high-risk AI systems (including nearly all HR AI) must be fully compliant by 2 August 2026. Fines: up to 15 million euros or 3% of global turnover.</li>
<li>The Digital Omnibus package is set to postpone the high-risk deadline to 2 December 2027: the Council and Parliament reached a provisional political agreement on 7 May 2026. It is not yet formally adopted (publication in the EU Official Journal expected before 2 August 2026). The high-risk classification itself is unchanged - use the time to prepare.</li>
<li>First step for every organization: complete an AI system inventory covering all officially deployed and shadow AI systems within four to eight weeks.</li>
</ul>
</div>

According to Gartner (2025), fewer than 10% of organizations subject to the EU AI Act have completed their AI system inventory, the foundational step for compliance. The European Commission estimates that over 300,000 enterprises across the EU deploy AI systems that may fall under regulatory scope.

<table>
<thead>
<tr><th>Milestone</th><th>Date</th><th>Status</th><th>Key Obligations</th></tr>
</thead>
<tbody>
<tr><td>Entry into Force</td><td>August 2024</td><td>Active</td><td>Framework established</td></tr>
<tr><td>Prohibited Practices + AI Literacy</td><td>February 2025</td><td>Active</td><td>Bans on social scoring, manipulation; training obligation</td></tr>
<tr><td>GPAI Obligations</td><td>August 2025</td><td>Active</td><td>Transparency, labeling, governance inventory</td></tr>
<tr><td>High-Risk Systems</td><td>2 Aug 2026 (Dec 2027 prov.)</td><td>Postponement provisionally agreed</td><td>Full compliance: risk mgmt, data gov, human oversight</td></tr>
<tr><td>Remaining Provisions</td><td>August 2027</td><td>2027</td><td>Sector-specific rules, remaining categories</td></tr>
</tbody>
</table>

## The World's First Comprehensive AI Law

The EU AI Act has been in force since August 2024. It is the world's first comprehensive legislation for regulating artificial intelligence, and it applies to every organization that develops, deploys, or provides AI systems. As of June 2026, we are in the middle of the implementation phase: two deadlines have already passed, and the high-risk deadline falls on 2 August 2026 under current law (provisionally set to move to 2 December 2027 under the Digital Omnibus of 7 May 2026, formal adoption still pending). The high-risk classification is unchanged, so organizations that prepare now have time on their side.

This article provides a sober overview of the current state: what already applies, what is coming when, which obligations affect your organization, and what you should do in the next 90 days.

## Timeline: Five Milestones

The phased implementation of the EU AI Act spans three years. Each milestone activates different obligations.

```
August 2024          February 2025         August 2025         August 2026          August 2027
│                    │                    │                   │                    │
▼                    ▼                    ▼                   ▼                    ▼
Entry into Force   Prohibited AI        GPAI Obligations    High-Risk Systems    Remaining
Practices +          Take Effect         Must Be Compliant    (Dec 2027 prov.)     Provisions
AI Literacy
ACTIVE                ACTIVE              ACTIVE               2 AUG 2026 /         AUG 2027
                                                              DEC 2027 PROV.
```

For organizations, this means: two stages are already legally binding. The third, and for many enterprises the most critical, has its deadline on 2 August 2026 under current law - provisionally set to move to 2 December 2027 under the Digital Omnibus of 7 May 2026 (formal adoption still pending). The classification is unchanged, and preparation typically requires four to six months, so the lead time is best used now.

## What Applies Now

### Prohibited AI Practices (since February 2025)

Since February 2, 2025, certain AI applications have been fully prohibited in the EU. This covers:

- **Social scoring:** AI systems that evaluate individuals based on their social behavior and derive disadvantages in unrelated contexts.
- **Manipulative AI:** Systems that manipulate human behavior through subliminal techniques, such as dark patterns that coerce purchasing decisions or consent.
- **Real-time biometrics in public spaces:** Real-time biometric identification is fundamentally prohibited. Narrowly defined exceptions exist for law enforcement in cases involving serious crimes, counterterrorism, and missing persons searches, each requiring judicial authorization.
- **Emotion recognition in the workplace and educational institutions:** AI systems that detect emotions of employees or learners are impermissible.
- **Predictive policing based on individual characteristics:** Risk assessments for criminal behavior based solely on personal attributes.

**Penalties:** Violations of the prohibition provisions are punishable by fines of up to 35 million euros or 7 percent of global annual turnover, whichever amount is higher.

For most enterprises, these prohibitions are not directly action-relevant because the described applications rarely occur in a business context. But the review is mandatory: ensure that none of your AI systems falls under these categories.

### AI Literacy (since February 2025)

In parallel with the prohibitions, the AI literacy obligation under Article 4 has been in effect since February 2025: all persons who operate, deploy, or use AI systems must possess a sufficient level of AI competence. The competence must be appropriate to the respective context. A developer requires deeper knowledge than an end user who uses a chatbot.

What this means in practice:

- **Training obligation:** Organizations must be able to demonstrate that their employees have been trained.
- **Documentation obligation:** Training content, participant lists, and refresh intervals must be documented.
- **Context appropriateness:** Training must match the role. A generic 30-minute e-learning module is insufficient for decision makers who select and take responsibility for AI systems.

The AI literacy obligation is frequently underestimated because it does not impose high technical requirements. But it is already enforceable. And it applies to every organization that uses AI, regardless of the risk class of the system. More on the organizational implications can be found in the article [works council & AI Literacy: The Organizational Questions](/en/magazine/works-council-ai-literacy/).

### GPAI Obligations (since August 2025)

Since August 2025, the transparency and documentation obligations for General-Purpose AI models (GPAI) are in effect. These primarily concern the providers of language models, not the organizations that use them. But as a deployer, an organization that uses a GPAI model in its own applications, you have obligations:

- **Usage notices:** If your application generates content that could be mistaken for human-created, you must label it accordingly.
- **Transparency toward users:** Individuals interacting with an AI system must be informed of that fact.
- **Governance infrastructure:** You must be able to document which GPAI models you deploy, in which context, and with which safeguards.

The GPAI obligations require a clean inventory: Which AI models do you deploy? From which provider? In which application? With which risk classification? This information forms the foundation for the high-risk compliance whose deadline is 2 August 2026 under current law (provisionally set to move to 2 December 2027).

## The High-Risk Deadline: 2 August 2026 (Provisionally Postponed to December 2027)

The high-risk deadline of 2 August 2026 is the most critical deadline in the EU AI Act for most organizations. From that date, under current law, all AI systems falling under Annex III must be fully compliant; following the provisional Digital Omnibus agreement of 7 May 2026 that date is set to be postponed to 2 December 2027 (formal adoption still pending, as of June 2026). The requirements are extensive, and the classification is unchanged.

### Which Systems Fall Under High Risk?

Annex III of the EU AI Act defines eight areas in which AI systems are classified as high-risk. The most relevant for enterprises:

- **Employment, personnel management, and access to self-employment:** AI systems for job postings, candidate selection, performance evaluation, promotion decisions, and terminations.
- **Creditworthiness and insurance:** Automated credit scoring, risk scoring.
- **Biometric identification:** Facial recognition, voice identification, including in non-public spaces.
- **Critical infrastructure:** AI systems in energy, water, transportation, telecommunications.
- **Education and vocational training:** Automated exam grading, access control to educational institutions.

### Requirements for High-Risk Systems

If any of your AI systems is classified as high-risk, you must meet the following requirements by the high-risk deadline (2 August 2026 under current law, provisionally set to move to 2 December 2027 under the Digital Omnibus of 7 May 2026):

1. **Risk management system:** A documented system for identifying, analyzing, and mitigating risks throughout the entire lifecycle of the AI system.
2. **Data governance:** Requirements for quality, representativeness, and accuracy of training data. When using pre-trained models: documentation of data provenance and fine-tuning.
3. **Technical documentation:** Comprehensive documentation of the system prior to deployment: architecture, training procedures, performance metrics, testing procedures, limitations.
4. **Record-keeping obligations:** Automatic logging of all relevant events to ensure the traceability of decisions.
5. **Transparency:** Instructions for deployers that enable proper use.
6. **Human oversight:** Technical measures that enable effective human monitoring. The [Decision Layer](/en/decision-layer/) is an architecture that implements precisely this requirement.
7. **Accuracy, robustness, cybersecurity:** The system must reliably deliver its declared performance and be protected against manipulation.
8. **Conformity assessment:** For certain categories, an assessment by a notified body (conformity assessment body) is required. For others, a self-assessment is sufficient.

**Penalties:** Violations of the high-risk obligations are punishable by fines of up to 15 million euros or 3 percent of global annual turnover.

## Particular Relevance for HR

The HR department is the business area where AI applications most frequently fall under the high-risk category. This is due to Annex III, Number 4, Employment and Personnel Management. The classification covers:

**Automated screening of applications: high-risk.** Any AI system that pre-sorts, evaluates, or filters job applications falls under the high-risk category. Regardless of whether the final decision is made by a human. The pre-selection alone is regulated.

**AI-assisted performance evaluations: high-risk.** When AI systems analyze performance data and derive evaluations or prepare evaluations from them, that is high-risk. This applies even to systems that only issue recommendations.

**Predictive attrition: high-risk.** AI systems that predict which employees are likely to leave the organization process personal data to derive employment decisions. That is high-risk.

**Automated shift optimization: potentially high-risk.** If an AI system creates shift schedules while processing individual preferences, performance data, or health information, it may fall under high-risk. The classification depends on the specific scope of data involved.

For HR departments, this means: inventory all AI systems used in employment contexts. Review the classification. Begin compliance preparation. The high-risk deadline is 2 August 2026 under current law and provisionally set to move to 2 December 2027 - either way, the classification stands, so the lead time is best used to reach full high-risk conformity. Further information on the interplay of AI and HR can be found at [HR & AI Agents](/en/hr-ai-agents/).

## Digital Omnibus: Postponement Provisionally Agreed, Adoption Pending

The European Commission proposed a Digital Omnibus package at the end of 2025 that would, among other things, defer the high-risk deadlines of the EU AI Act to December 2027 at the latest. The package also addresses a simplification of reporting obligations and a raising of thresholds for SMEs. The deferral is conditional: it only takes effect once harmonised standards are available. After confirmation, six months apply for Annex III systems and twelve months for Annex I systems. The backstop date is December 2, 2027.

**Current status (June 2026):** On 7 May 2026, the Council and Parliament reached a provisional political agreement on the Digital Omnibus package, postponing the high-risk deadline from 2 August 2026 to 2 December 2027. The agreement is not yet in force: formal adoption and publication in the EU Official Journal are still pending, expected before the 2 August 2026 deadline it replaces. Until that publication, the current-law deadline of 2 August 2026 stands.

**The recommendation:** Treat 2 August 2026 as the deadline still in force while the postponement is only provisionally agreed and not yet adopted. The likelihood of the deferral to 2 December 2027 is now high - it has a provisional political agreement - but until publication in the Official Journal it is not law. Either way, the high-risk classification is unchanged, so use the lead time to prepare: if the postponement is adopted you gain additional time, and if it is not you are already compliant. Betting compliance on an extension that is not yet in force remains an avoidable risk.

## Practical Recommendation: Start an AI System Inventory

Regardless of whether your AI systems fall under high-risk or not: the first step is always the same. You need a complete inventory of all AI systems in your organization.

### What Must Be Captured

For each AI system, document:

- **System designation and description:** What does the system do? Which process does it support?
- **Provider and model:** Which AI model is being used? From which provider? Cloud API or self-hosted?
- **Your organization's role:** Are you the provider, deployer, or both?
- **Risk classification:** Does the system fall under one of the categories in Annex III (high-risk)? Under the prohibition provisions in Article 5? Or is it a system with limited risk?
- **Affected individuals:** Which persons are affected by the system's decisions or outputs?
- **Data processing:** What data does the system process? Personal data? Trade secrets?
- **Safeguards:** What technical and organizational measures are implemented? Human oversight? Audit trail?

### Timeline

An AI system inventory for a mid-sized organization is achievable in four to eight weeks. The effort depends on the number of systems, the state of documentation, and internal coordination. Start with the obvious systems, the officially procured AI tools, and then expand to [shadow AI](/en/magazine/decision-layer-shadow-ai/): AI systems that employees use independently without IT knowledge.

The inventory is not a one-time task. It must be continuously updated as new systems are added, existing systems are modified, and regulatory assessments evolve. The [governance infrastructure](/en/governance/) must be designed so that the inventory remains a living document.

## Summary: What You Should Do Now

1. **Review the prohibition provisions.** Ensure that none of your AI systems falls under the practices prohibited since February 2025.
2. **Fulfill the AI literacy obligation.** Document training for all AI users in your organization. The obligation is in effect now.
3. **Create an AI system inventory.** Capture all AI systems, their providers, deployment context, and risk classification. Timeframe: four to eight weeks.
4. **Identify high-risk systems.** Review the HR area, credit decisions, and automated processes with direct impact on individuals in particular.
5. **Begin high-risk compliance.** For systems falling under Annex III: establish risk management system, data governance, technical documentation, and human oversight. Deadline: 2 August 2026 under current law, provisionally set to move to 2 December 2027 under the Digital Omnibus of 7 May 2026.
6. **Do not bet on the Digital Omnibus being in force.** The deferral to 2 December 2027 has a provisional political agreement (7 May 2026) but is not yet formally adopted. Treat the extra time as a bonus, not a planning basis - the high-risk classification is unchanged either way.

---

**📘 Enterprise AI Infrastructure Blueprint 2026 - Article Series**

| ← Previous | Overview | Next → |
|:---|:---:|---:|
| [What AI Really Costs: TCO Comparison for Enterprises](/en/magazine/ai-costs-tco-comparison/) | [Overview](/en/magazine/ai-infrastructure-blueprint-2026/) | [Works Council & AI Literacy: The Organizational Questions](/en/magazine/works-council-ai-literacy/) |

*All articles in this series: [Enterprise AI Infrastructure Blueprint 2026](/en/magazine/ai-infrastructure-blueprint-2026/)*

---

Gosign supports organizations with EU AI Act compliance, from system inventory to conformity assessment. If you want to know where your organization stands, talk to us.

<a href="/en/contact/" target="_blank" rel="noopener noreferrer">Book a consultation</a>. 30 minutes to assess your compliance status.

--- The EU AI Act Applies Worldwide. ---
> The EU AI Act isn't European overregulation. It simply writes down what every legal system already demands: Explain your decision.

*Somalia. South Sudan. Yemen. Libya. Syria. - Those are the only exceptions.*

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">At a Glance - AI Accountability Is Universal</p>
<ul class="text-body text-gosign-text space-y-2">
<li>The EU AI Act did not invent explainable AI decisions - it was the first to codify the principle specifically for AI systems. The obligation to explain decisions exists in virtually every legal system worldwide.</li>
<li>HR is the highest-risk area because AI decisions about people create the largest legal attack surface - from CV screening bias to automated performance evaluations.</li>
<li>A biased algorithm scales discrimination to 50,000 decisions simultaneously, compared to roughly 50 per year from a biased human manager.</li>
<li>Every company using AI for decisions about people needs two layers: a Decision Layer (evidence trail for every decision) and a Governance Layer (rules of engagement).</li>
<li>Shadow AI - employees using ChatGPT, Copilot, and other tools without governance - is the most urgent and underestimated risk for most organizations today.</li>
</ul>
</div>

According to the European Commission (2024), AI systems classified as high-risk under the EU AI Act will directly affect employment decisions in over 6,000 organizations across EU member states, with HR identified as the most frequently affected business area under Annex III.

## The $3 Million Question

A company in Texas uses an AI tool to screen job applicants. 500 applications in, 20 out. One of the 480 rejected candidates sues. Not under the EU AI Act. Under Title VII of the Civil Rights Act - a law that's been on the books since 1964.

The judge's question: "Explain how this decision was made."

Silence.

Not because the company acted in bad faith. Because nobody in the company can explain how the AI tool produced those 480 rejections. HR bought the tool. IT installed it. And the decision logic sits inside a black box that nobody can open.

This isn't hypothetical. This is happening right now. In courtrooms across the United States. And across the world.

## Accountability Is Not a European Invention

Most executives have mentally filed the EU AI Act under "European regulation." That's an expensive mistake. The EU AI Act didn't invent the principle of explainable decisions. It was simply the first to write it down specifically for AI systems.

The principle itself is universal.

**United States:** Title VII of the Civil Rights Act prohibits discrimination in employment decisions - since 1964. The EEOC can demand at any time that a company explains why a candidate was rejected. The ADA covers disability discrimination. ADEA covers age. And in New York City, Local Law 144 has required mandatory bias audits for AI hiring tools since 2023.

**Brazil:** LGPD Article 20 grants an explicit right to explanation for automated decisions. Brazilian labor courts process over 3.5 million new cases per year - the most active labor judiciary on the planet.

**China:** Algorithmic Recommendation Management Provisions have been in effect since 2022. Even China demands transparency in algorithmic decisions.

**United Kingdom:** Post-Brexit, the UK is building its own AI regulatory framework. But the ICO has been clear: automated decisions must be explainable under UK GDPR and the Equality Act 2010.

**India:** The IT Act 2000 combined with the Industrial Disputes Act gives employees tools to challenge automated decisions.

**Everywhere else:** In every country with a functioning civil legal system, a person affected by an AI decision can challenge that decision in court. The question "Why?" is universal - and a black box is an acceptable answer nowhere.

Of the 193 UN member states, there are exactly 5 where a company cannot be held legally accountable for an unexplainable AI decision. Not because those countries allow it - but because they have no functioning court system.

The EU AI Act isn't European overregulation. It's the first honest answer to a universal question.

<table class="w-full text-left text-sm">
<thead><tr class="border-b border-gosign-border">
<th class="py-2 pr-4 font-semibold">Region</th>
<th class="py-2 pr-4 font-semibold">Key Legislation</th>
<th class="py-2 pr-4 font-semibold">Explainability Required</th>
<th class="py-2 pr-4 font-semibold">HR Decisions Covered</th>
</tr></thead>
<tbody>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">EU</td><td class="py-2 pr-4">EU AI Act, GDPR Art. 22</td><td class="py-2 pr-4">Yes (legally binding)</td><td class="py-2 pr-4">Yes (Annex III high-risk)</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">USA</td><td class="py-2 pr-4">Title VII, NYC Local Law 144</td><td class="py-2 pr-4">Yes (via anti-discrimination)</td><td class="py-2 pr-4">Yes (employment decisions)</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Brazil</td><td class="py-2 pr-4">LGPD Art. 20, CLT</td><td class="py-2 pr-4">Yes (right to explanation)</td><td class="py-2 pr-4">Yes (labour courts active)</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">China</td><td class="py-2 pr-4">Algorithmic Provisions 2022</td><td class="py-2 pr-4">Yes (transparency required)</td><td class="py-2 pr-4">Yes (algorithmic decisions)</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">UK</td><td class="py-2 pr-4">UK GDPR, Equality Act 2010</td><td class="py-2 pr-4">Yes (ICO guidance)</td><td class="py-2 pr-4">Yes (automated decisions)</td></tr>
</tbody>
</table>

## Why HR Is Ground Zero

<img src="/images/magazin/risk-pyramid-en.svg" alt="Risk pyramid: HR decisions about people carry the highest risk, process decisions medium, product decisions the lowest" width="800" height="480" loading="lazy" />

Wrong AI decisions about products are annoying. Wrong AI decisions about processes are expensive. Wrong AI decisions about people are existential - for the affected individuals and for the company.

HR is where AI decisions create the largest attack surface. Three scenarios that are already happening today:

AI-powered CV screening systematically filters out candidates with career gaps. Affected: parents, people with chronic illness, career changers. In most jurisdictions, this constitutes disparate impact discrimination.

Sentiment analysis in video interviews misreads cultural differences in expression and body language as negative signals. Affected: candidates from different cultural backgrounds. This is potentially ethnic discrimination.

A performance prediction tool trained on historical promotion data reproduces past patterns. If men were promoted more frequently in the past, the tool replicates that pattern. That's systematic gender discrimination - automated and scaled.

Every one of these scenarios is already actionable in most countries. Not starting with the EU AI Act high-risk deadline (2 August 2026 under current law, provisionally set to move to 2 December 2027 under the Digital Omnibus of 7 May 2026, formal adoption still pending). Right now. The difference: the EU AI Act turns this from reactive liability into proactive obligation.

And the real problem with AI discrimination compared to human discrimination: a biased manager might make 50 questionable decisions per year. A biased algorithm makes 50,000. Simultaneously. Consistently. Provably.

## The Two Layers Every Company Needs

<img src="/images/magazin/decision-governance-layers-en.svg" alt="Governance Layer and Decision Layer: Two-layer architecture for explainable AI decisions" width="800" height="440" loading="lazy" />

The solution isn't complex - but it requires architectural thinking. Every company that uses AI for decisions about people needs two layers.

**The [Decision Layer](/en/magazine/decision-layer-shadow-ai/) - the evidence.** The Decision Layer breaks down every process into individual decision steps and defines for each step: human, ruleset, or AI. Every AI-assisted decision answers: What data went in? Which model decided, in which version? What was the result and at what confidence level? Did a human review the result before it took effect? Is the decision reproducible?

This isn't a technical nice-to-have. It's the digital equivalent of bookkeeping. And just as no company can operate without bookkeeping, no company will soon be able to operate without a Decision Layer.

**The Governance Layer - the rules of engagement.** Before the first AI decision is made: What AI applications even exist in the company? Most companies don't know. How risky is each application - not by regulatory categories, but by real impact on people? Who bears responsibility? Spoiler: "IT" is not an answer. When must a human intervene? And how is all of this audited?

In Germany, there's an additional dimension: co-determination (Mitbestimmung). Under the Works Constitution Act (BetrVG § 87), works councils (Betriebsräte) have co-determination rights when AI systems are introduced that make decisions about employees or monitor their behavior. Without traceable decision logic, without documented Human-in-the-Loop processes, without works agreements as system constraints, no works council will give its approval.

## The Elephant in the Room: Shadow AI

<img src="/images/magazin/shadow-ai-eisberg-en.svg" alt="Shadow AI iceberg: Above the waterline official AI tools with governance, below the waterline uncontrolled AI use without audit trail" width="800" height="600" loading="lazy" />

And now the most uncomfortable point. Most companies are debating governance for AI tools they've officially deployed. Meanwhile, their employees are already using ChatGPT, Claude, Copilot, and other tools for decision support - without anyone knowing.

Recruiters are using ChatGPT to summarize applications. Team leads are having Copilot draft promotion recommendations. L&D is generating performance reviews with AI.

All of this is happening. Now. Without a Decision Layer. Without a Governance Layer. Without any traceability.

And when someone sues, the answer won't be "the AI decided" - it'll be worse: "We didn't even know AI was deciding."

## The Real Question

The question isn't: "Are we [EU AI Act compliant](/en/magazine/eu-ai-act-hr-high-risk/)?"

The question is: Can we explain tomorrow - in every country where we operate - why we decided the way we did today?

If you can answer yes, you're automatically compliant. With the EU AI Act. With GDPR. With EEOC requirements. With LGPD. With whatever comes next.

If you can't, you don't have a regulation problem. You have a governance problem.

--- EU AI Act: HR AI Is High-Risk - Deadline 2 August 2026 (Postponement to Dec 2027 Provisionally Agreed) ---
> HR AI is high-risk under EU AI Act Annex III. Six mandatory obligations, deadlines, and how the Decision Layer meets each requirement.

The EU AI Act places almost every AI system used in HR processes into the high-risk category. Under current law these systems must meet strict requirements for risk management, transparency, and human oversight from 2 August 2026, though following the provisional Digital Omnibus agreement of 7 May 2026 that deadline is set to be postponed to 2 December 2027 (formal adoption still pending, as of June 2026).

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">At a Glance - HR AI Is High-Risk Under the EU AI Act</p>
<ul class="text-body text-gosign-text space-y-2">
<li>AI systems for recruiting, performance reviews, promotions, and terminations are classified as high-risk under Annex III, No. 4 of the EU AI Act.</li>
<li>Prohibited AI practices (social scoring, manipulation) have been in force since 2 February 2025. Under current law the full high-risk obligations apply from 2 August 2026, but the provisional Digital Omnibus agreement of 7 May 2026 is set to postpone this to 2 December 2027 (formal adoption still pending, as of June 2026).</li>
<li>Six mandatory requirements: risk management, data governance, record-keeping, transparency, human oversight, and accuracy/robustness.</li>
<li>The Decision Layer maps each requirement architecturally: Confidence Routing for risk, versioned rule sets for data governance, audit trail for records, Human-in-the-Loop for oversight.</li>
<li>Penalties reach up to 15 million euros or 3% of global annual turnover for violations of the high-risk obligations (Art. 99(4)) - up to 35 million euros or 7% for prohibited AI practices (Art. 5).</li>
</ul>
</div>

According to a PwC survey (2024), only 24% of enterprises using AI in HR processes have begun formal EU AI Act compliance preparation, despite the current-law 2 August 2026 deadline for high-risk systems (provisionally set to move to 2 December 2027 under the Digital Omnibus of 7 May 2026, formal adoption still pending).

<table>
<thead>
<tr><th>EU AI Act Article</th><th>Requirement</th><th>Decision Layer Implementation</th></tr>
</thead>
<tbody>
<tr><td>Art. 9</td><td>Risk Management System</td><td>Confidence Routing with configurable thresholds</td></tr>
<tr><td>Art. 10</td><td>Data Governance</td><td>Versioned rule sets with validity dates</td></tr>
<tr><td>Art. 12</td><td>Record-Keeping</td><td>Immutable audit trail per decision</td></tr>
<tr><td>Art. 13</td><td>Transparency</td><td>Auditor Portal with full decision path</td></tr>
<tr><td>Art. 14</td><td>Human Oversight</td><td>Enforced Human-in-the-Loop for defined types</td></tr>
<tr><td>Art. 15</td><td>Accuracy and Robustness</td><td>Bias monitoring and model-agnostic design</td></tr>
<tr><td>Art. 86</td><td>Right to an explanation of the individual decision</td><td>Decision act per micro-decision with contestation path</td></tr>
</tbody>
</table>

## The Classification: HR AI is High-Risk

The EU AI Act classifies AI systems used in employment, worker management, and access to self-employment as high-risk (Annex III, No. 4). This specifically covers:

AI systems for recruiting and candidate selection. AI systems that influence promotion, termination, task assignment, or performance monitoring. AI systems that affect working conditions - including salary adjustments, classifications, and shift planning.

In short: almost every AI agent that prepares, supports, or makes decisions in HR processes falls under the high-risk category.

## The Deadlines

Since 2 February 2025, prohibitions on unacceptable AI practices have been in force - including social scoring and manipulative techniques. Under current law the full obligations for high-risk AI systems take effect on 2 August 2026, but following the provisional Digital Omnibus agreement of 7 May 2026 that date is set to move to 2 December 2027 (formal adoption still pending, as of June 2026). The high-risk classification itself is not changing: the additional lead time is best used to build governance structures now, so that compliance is in place whichever date applies.

## What Is Specifically Required - and How the Decision Layer Fulfils It

The following requirements apply to every operator of a high-risk AI system in the HR domain:

**Article 9 - Risk Management System:**
The EU AI Act requires a continuous risk management system that identifies, assesses, and mitigates risks. In the Decision Layer, this is implemented through Confidence Routing: every agent decision is automatically evaluated by confidence and risk category. High risk or low confidence leads to escalation to a human. Thresholds are configurable and documented.

**Article 10 - Data Governance:**
Versioned rule sets in the Decision Layer ensure that the data basis of every decision is traceable. Collective agreements, works council agreements (Betriebsvereinbarungen), and compliance rules have versions, validity dates, and scopes. During an audit, it is traceable which rule set in which version applied at the time of the decision.

**Article 12 - Record-Keeping Obligations:**
The audit trail in the Decision Layer generates a complete, immutable data record for every decision: input, model, rule set, confidence, routing decision, result, timestamp. Automatically, not compiled after the fact.

**Article 13 - Transparency:**
Every agent decision is traceable in the Auditor Portal. Works councils, data protection officers, and auditors can view the decision path. No black box.

**Article 14 - Human Oversight:**
Human-in-the-Loop is an architectural principle in the Decision Layer, not an optional setting. For defined decision types - discrimination potential, co-determination topics, value thresholds - the architecture enforces human review. An agent cannot bypass this review.

**Article 15 - Accuracy, Robustness, and Cybersecurity:**
Bias monitoring systematically checks for discriminatory patterns. Confidence thresholds ensure that the agent only decides autonomously with sufficient certainty. Model-agnostic design enables switching the language model without changing the governance logic.

**Article 86 - Right to an Explanation:**
Beyond the six operator obligations, Art. 86 gives every affected person a claim to an explanation of the individual decision - not of the system in general, but of this one case. That question can be answered only through a decision act per micro-decision: input, applied business rule including version, confidence, result, and contestation path. The Decision Layer creates this act at the moment of the decision, making the Art. 86 claim satisfiable per individual case.

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Free eBook: AI in HR</p>
<p class="text-body text-gosign-text mb-4">EU AI Act checklist, Decision Framework, works council perspective, and readiness assessment - the governance handbook for HR leaders.</p>
<a href="/en/ebook/ai-hr-governance-handbook/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Download for free</a>
</div>

## What This Means for HR Departments

Companies that use or plan to use AI in HR processes today should build governance structures in time for the high-risk deadline - 2 August 2026 under current law, provisionally set to move to 2 December 2027 under the Digital Omnibus of 7 May 2026 (formal adoption still pending, as of June 2026). This specifically means:

Documented decision logic for every AI-supported HR process. Technically enforced Human-in-the-Loop mechanisms for decisions with personnel impact. Audit-proof audit trails that make traceable how every decision was made. Bias monitoring that detects and reports discriminatory patterns.

In Germany, the requirements of the Works Constitution Act (Betriebsverfassungsgesetz) add to this: works councils have a co-determination right for technical facilities that monitor the behaviour or performance of employees (§ 87(1) No. 6 BetrVG). AI agents in HR processes fall under this category.

The Decision Layer addresses both requirement blocks - EU AI Act and German co-determination law (Mitbestimmungsrecht) - in one architecture.

→ [Decision Layer in detail](/en/magazine/decision-layer-explained/)

→ [The Decision Act: Why Every AI Decision Must Be Contestable](/en/magazine/decision-act-contestable-ai-decisions/)

→ [Co-determination and works council](/en/governance/co-determination/)

→ [HR Agent](/en/hr-ai-agents/)

<a href="/en/contact/" target="_blank" rel="noopener noreferrer">Schedule a call</a> - We'll show you which of your HR processes fall under the high-risk category and how the Decision Layer meets the requirements.

--- EU AI Act: What HR Departments Must Do Now ---
> The EU AI Act directly affects HR processes. Risk classification, bias monitoring, human oversight - what is now mandatory and how to prepare.

The EU AI Act classifies AI used in HR decisions as high-risk. From risk classification to bias monitoring to human oversight - these are now legal requirements, not optional features.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">At a Glance - EU AI Act Obligations for HR</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Every AI system influencing HR decisions - recruiting, performance reviews, payroll, promotions - is classified as high-risk under Annex III of the EU AI Act.</li>
<li>Four core requirements: risk classification of every AI system, mandatory bias monitoring, enforced human oversight, and full transparency with documentation.</li>
<li>Common mistakes: retroactive compliance instead of Governance by Design, declaring AI tools as "merely supportive," and informing works councils too late.</li>
<li>The right approach is architecture-first: the Decision Layer decomposes every HR process into individual decision steps with logging, versioning, and Human-in-the-Loop from day one.</li>
<li>Fines up to 35 million euros or 7% of global annual revenue. Under current law the high-risk obligations apply from 2 August 2026, but following the provisional Digital Omnibus agreement of 7 May 2026 they are set to be postponed to 2 December 2027 (formal adoption still pending, as of June 2026).</li>
</ul>
</div>

The European Parliament (2024) estimates that HR and employment represent the single largest category of high-risk AI applications under the EU AI Act, affecting an estimated 85% of large enterprises that use AI in recruitment or workforce management.

<table>
<thead>
<tr><th>HR Process</th><th>EU AI Act Classification</th><th>Key Requirement</th></tr>
</thead>
<tbody>
<tr><td>CV Screening / Recruiting</td><td>High-Risk (Annex III)</td><td>Bias monitoring, audit trail</td></tr>
<tr><td>Performance Evaluation</td><td>High-Risk (Annex III)</td><td>Human oversight, transparency</td></tr>
<tr><td>Promotion Decisions</td><td>High-Risk (Annex III)</td><td>Explainability, Human-in-the-Loop</td></tr>
<tr><td>Shift Planning (with personal data)</td><td>Potentially High-Risk</td><td>Risk assessment, data governance</td></tr>
<tr><td>Compliance Knowledge Agent</td><td>Limited Risk</td><td>Transparency obligation</td></tr>
</tbody>
</table>

## What the EU AI Act Means for HR

The EU AI Act classifies AI systems by risk. AI systems used in human resources - recruiting, performance management, payroll decisions, time tracking - fall under the high-risk category. This is not interpretation, it's in the law.

For HR departments, this means: Every AI tool that influences decisions about employees must meet specific requirements. Not eventually, but now.

## The Four Requirements That Affect HR

### Risk Classification

Every AI system must be classified: minimal, limited, high or unacceptable risk. HR systems that prepare or influence decisions are typically high-risk. This doesn't just apply to recruiting AI, but also to Document Agents processing sick leave certificates or Knowledge Agents answering compliance questions.

### Bias Monitoring

High-risk AI systems must be tested for bias. For HR this means: Does the agent treat part-time employees differently than full-time? Are there systematic differences by location, gender, age? This must be documented and regularly reviewed.

### Human Oversight

Human oversight is not optional, it is mandatory. Every high-risk AI system must be designed so that a human can monitor, intervene and override it. In practice this means: [Human-in-the-loop](/en/governance/) must be built into the architecture, not bolted on afterwards.

### Transparency and Documentation

Affected employees must be informed that AI systems are being used. Technical documentation must be comprehensive: what data is processed, what logic is applied, what decisions are prepared. An audit trail is mandatory.

## What Most Companies Get Wrong

Three typical mistakes. First, the legal department evaluates tools retroactively instead of building the architecture to be compliant from the start. Second, AI tools are declared as "merely supportive" even though they de facto prepare decisions. Third, works councils (Betriebsräte) are informed only when the system is running, instead of being integrated into the governance structure.

## Governance by Design Instead of Retroactive Compliance

The right approach is not: build first, audit later. It's: [Governance by Design](/en/governance/). The Decision Layer decomposes every HR process into individual decision steps and defines for each step: human, ruleset, or AI. This means compliance requirements flow into the architecture from day 1. Logging, versioning, explainability, Human-in-the-loop - these are not features, they are architectural principles.

For collaboration with the works council, this means: When you build a [works council-ready architecture](/en/governance/co-determination/) from the start, the works agreement becomes an accelerator, not a blocker.

## Concrete Next Steps for HR

First: Inventory all AI systems used in HR - officially and unofficially. Second: Risk-classify each system according to EU AI Act categories. Third: Gap analysis - where is logging, bias monitoring, human oversight missing? Fourth: Architecture decision - retrofit or rebuild? Fifth: Involve the works council.

At Gosign, [EU AI Act readiness is part of every agent development](/en/hr-ai-agents/). Risk classification, bias testing, complete logging and Human-in-the-loop are not add-ons but the foundation of our architecture.

--- Human-in-the-Loop - Architectural Principle, Not Checkbox ---
> Human-in-the-Loop for AI agents means architecturally enforced human review, not optional approval. Confidence Routing, escalation rules, bias checks.

## The Problem: HITL as a Marketing Claim

Nearly every AI vendor claims their solution has "Human-in-the-Loop." In practice, this often means: Somewhere in the process there is an approval button. A human can click it. But does not have to.

That is not Human-in-the-Loop. That is optional approval that falls away under time pressure. When a clerk processes 200 documents per day and 195 of them are correct, they will eventually approve all of them without review.

Real Human-in-the-Loop is an architectural principle. It means: For defined decision types, the agent physically cannot act autonomously. The workflow pauses. The target system is not contacted. Only after human review and documented approval does the process continue.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">At a Glance - Human-in-the-Loop Architecture</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Real HITL is an architectural principle, not an optional approval button - the agent physically cannot bypass human review for defined decision types.</li>
<li>Three triggers: low confidence score, high-risk classification (discrimination, co-determination), and first-time application of new rules.</li>
<li>The EU AI Act requires effective human oversight for high-risk AI systems - HR processes explicitly fall under this category.</li>
<li>works council agreements become technical constraints in the Decision Layer that the system cannot circumvent.</li>
<li>HITL does not solve bias in training data and does not scale linearly - it is one building block alongside Audit Trail, bias monitoring, and Cert-Ready Controls.</li>
</ul>
</div>

According to the European Commission (2024), human oversight is required for all high-risk AI systems under the EU AI Act, and HR processes are explicitly listed under Annex III - making architecturally enforced Human-in-the-Loop a legal necessity, not a design choice.

| HITL Trigger | Description | Configurable |
|---|---|---|
| Low confidence score | Agent uncertainty below defined threshold | Yes, per tenant |
| Discrimination risk | Decisions with potential for discriminatory outcomes | Always escalated |
| Co-determination matters | Decisions subject to works council oversight | Always escalated |
| Value threshold breach | Amount exceeds defined limit for autonomous processing | Yes, per tenant |
| New rule introduction | First-time application of a newly deployed rule set | During learning phase |

## HITL as a Technical Architectural Principle

In the Gosign architecture, Human-in-the-Loop is implemented in the Decision Layer. The decision about when a human is involved is based on three criteria:

**Confidence Routing:** Every agent decision has a confidence score. If the confidence falls below the defined threshold, escalation happens automatically. The threshold is configurable per tenant.

**Risk Classification:** Certain decision types are always escalated regardless of confidence. Decisions with potential for discrimination, co-determination matters, value threshold breaches.

**Rule-Based Mandatory Escalation:** New rule sets being applied for the first time always go through human review during the introduction phase. Only after a validated learning phase does the agent switch to autonomous mode, for that specific rule.

The Human-in-the-Loop requirement is technically enforced. There is no workaround, no shortcut, no admin override. The agent cannot bypass the escalation.

## What HITL Looks Like in Practice

An HR agent processes a request for a special payment. The Document Agent reads the request. The Knowledge Agent checks the applicable works council agreement. The Decision Layer evaluates:

Result: Special payment eligible for approval per works council agreement Section 12, Paragraph 3. Confidence: 94%. Risk: low.

However: The decision involves a compensation component. In the HITL configuration, it is defined: Compensation decisions are always escalated, regardless of confidence. The workflow pauses.

The responsible clerk sees in the dashboard: The request, the agent's proposal, the applied rule in its current version, the confidence score, the escalation reason. They review, confirm, or correct. Their decision is documented in the Audit Trail, including the information that this was a Human-in-the-Loop decision.

## HITL and the Works Council

Human-in-the-Loop is the technical answer to an organizational requirement: co-determination. Works councils have co-determination rights when AI systems are introduced, covering technical monitoring systems and workplace design.

The Decision Layer transforms works council agreements into technical constraints. When a works council agreement states: "Decisions about performance reviews may not be made fully automatically," this is implemented as a HITL rule in the Decision Layer. The agent cannot bypass this rule.

The result: The works council can verify that its requirements are technically enforced, not merely organizationally promised.

## HITL and the EU AI Act

The EU AI Act requires human oversight for high-risk AI systems (Art. 14). HR processes explicitly fall under the high-risk category: recruiting, performance reviews, promotion decisions, compensation, termination.

Human-in-the-Loop as an architectural principle fulfills the EU AI Act's requirements for human oversight. It is not sufficient to have a human in the process who could theoretically intervene. The EU AI Act demands effective human oversight, meaning: The human must be able to understand the decision, must be able to stop it, and their intervention must be documented.

The Decision Layer documents for every HITL decision: Who reviewed? When? What was the agent's proposal? What was the human decision? Do they align or diverge?

## The Limits: What HITL Does Not Solve

Human-in-the-Loop is not a solution for all governance problems. Specifically:

HITL does not solve the problem of bias in training data. If the language model is systematically biased, a clerk will not detect this from individual cases. That requires statistical bias monitoring across all agent decisions.

HITL does not scale linearly. If the agent makes 10,000 decisions per day and 20% are escalated, you need resources for 2,000 manual reviews. HITL thresholds must be calibrated so that the escalation rate remains manageable without compromising governance.

HITL is one building block of the [governance architecture](/en/governance/), alongside Audit Trail, bias monitoring, rule set versioning, and Cert-Ready Controls.

More on this: [Co-Determination and AI](/en/governance/co-determination/)

<a href="/en/contact/" target="_blank" rel="noopener noreferrer">Book a consultation</a> - We will show you what Human-in-the-Loop looks like in your architecture.

--- LLM Self-Hosting for Enterprise - Azure, GCP, On-Premise ---
> Self-host language models: DeepSeek, Llama, Mistral in your own infrastructure. Deployment options: Azure, GCP, on-premise, hybrid

## Why Self-Hosting?

For many enterprise clients, the question is not whether AI will be deployed, but where the data is processed. When using cloud APIs (OpenAI, Anthropic, Google), data leaves the organization's own infrastructure. For regulated industries - finance, healthcare, public sector - [data residency](/en/governance/data-residency/) can be a disqualifying factor.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">At a Glance - LLM Self-Hosting for Enterprise</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Self-hosting keeps all data within the corporate network - no third-party processing, full control over model, data, and inference.</li>
<li>Open-source models (Llama, Mistral, DeepSeek, gpt-oss) can be deployed on Azure ML, GCP Vertex AI, on-premise GPU servers, or hybrid setups.</li>
<li>GPU sizing is the primary cost driver: a 7B model runs on one GPU, a 70B model requires multiple GPUs or quantization.</li>
<li>Model-agnostic routing allows agents to use self-hosted models for sensitive data and cloud APIs for non-critical tasks.</li>
<li>Gartner (2024) finds that 45% of enterprise AI deployments in regulated industries will run on private infrastructure by 2027, up from 20% in 2023.</li>
</ul>
</div>

Self-hosting means: the language model runs in the client's infrastructure. No data leaves the corporate network. No third party processes the requests. Full control over model, data, and processing.

## Which Models Can You Self-Host?

Open-source models can be operated in your own infrastructure:

**Volume workhorse - [Mistral](https://mistral.ai/) Small 3.2 (24B, Apache 2.0, EU-built):** European model, runs on a single RTX 4090 with 4-bit quantization. Ideal for batch inference on non-critical workloads. Mixtral 8x22B and Codestral Mamba 32B (coding-specialised) complete the Mistral portfolio.

**Reasoning OSS - gpt-oss-120b (OpenAI, Apache 2.0):** 117B parameters, MoE architecture, runs on a single H100 (80 GB). OpenAI's first open-source model; gpt-oss-20b for edge scenarios.

**Frontier OSS - [DeepSeek](https://www.deepseek.com/) V4-Flash and V4-Pro (MIT):** DeepSeek V4-Flash (April 2026, 284B/13B active MoE) runs on a single H100 with quantization. V4-Pro (1.6T/49B) requires an 8x H100 cluster and delivers frontier-grade reasoning. DeepSeek R1 (Jan 2025) remains production-ready for mature deployments - V4 does not retire R1 overnight.

**Long context - [Llama](https://llama.meta.com/) 4 Scout (Meta License):** 10M-token context window for document analysis across entire case files. Llama 4 Maverick handles shorter contexts with higher token throughput.

**Coding OSS - Qwen 3 Coder 110B (Apache 2.0, Alibaba) and DeepSeek Coder V4 (MIT):** Specialised for code generation and repository understanding. Codestral Mamba 32B (Mistral, EU-built) as the European alternative.

Proprietary models (Claude Opus 4.7, GPT-5.5, Gemini 3.1 Pro) are not available for self-hosting but can be used via API with EU-based processing.

In a model-agnostic architecture, an agent can use multiple models: self-hosted for sensitive data, cloud API for non-critical tasks. The routing is rule-based and configured in the Decision Layer.

## Deployment Options

**Azure:** LLMs can be deployed on Azure ML or operated on dedicated GPU VMs (NC-Series, ND-Series). Integration with Azure Entra ID for authentication and access control. Processing in EU data centers (West Europe, North Europe).

**GCP:** Deployment via Vertex AI or on dedicated GPU VMs (A2, G2). Integration with Google Cloud IAM. Processing in EU data centers (europe-west1, europe-west4).

**On-Premise:** Dedicated servers with NVIDIA GPUs (A100, H100, RTX 4000 Ada). Operation in certified data centers. Maximum control, no cloud dependency.

**Hybrid:** Combination of self-hosted and cloud. Sensitive workloads run locally, non-critical workloads in the cloud. Unified governance across both environments.

<table class="w-full text-left text-sm">
<thead><tr class="border-b border-gosign-border">
<th class="py-2 pr-4 font-semibold">Criterion</th>
<th class="py-2 pr-4 font-semibold">Self-Hosted</th>
<th class="py-2 pr-4 font-semibold">Cloud API</th>
</tr></thead>
<tbody>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Data Residency</td><td class="py-2 pr-4">Full control, data stays on-premise</td><td class="py-2 pr-4">Provider-dependent, EU regions available</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Model Choice</td><td class="py-2 pr-4">Open-source only (Llama, Mistral, DeepSeek)</td><td class="py-2 pr-4">Proprietary + open-source via API</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Cost at Scale</td><td class="py-2 pr-4">Lower (fixed GPU cost, no per-token fees)</td><td class="py-2 pr-4">Higher (per-token pricing scales linearly)</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Operational Effort</td><td class="py-2 pr-4">High (GPU management, updates, HA)</td><td class="py-2 pr-4">Low (managed by provider)</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Latency</td><td class="py-2 pr-4">Low (local network)</td><td class="py-2 pr-4">Variable (network-dependent)</td></tr>
</tbody>
</table>

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Free eBook: AI Infrastructure</p>
<p class="text-body text-gosign-text mb-4">Build, Buy, Hybrid - EU AI Act (UK: UK AI regulatory framework)-compliant infrastructure with B/B/H Framework and 7-Layer Reference Architecture.</p>
<a href="/en/ebook/ai-infrastructure-governance-handbook/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Download for free</a>
</div>

## Architecture Considerations

**GPU Sizing:** Model size determines GPU requirements. A 7B model runs on a single GPU. A 70B model requires multiple GPUs or quantization. The right sizing depends on the use case.

**Inference Optimization:** Techniques such as quantization (4-bit, 8-bit), batching, and KV cache optimization reduce resource requirements with acceptable quality trade-offs.

**High Availability:** For production systems: redundant GPU servers, load balancing, automatic failover. No single point of failure.

**Model Updates:** New model versions must be tested before going into production. A staging environment for model testing is part of the infrastructure.

**TCO crossover - self-host vs Cloud API:** The threshold sits at roughly 50-100M tokens/month sustained. Below that line, Cloud APIs win on cost; above it, a dedicated H100 amortises in 12-18 months. See [Self-hosted Open-Source AI 2026](/en/magazine/self-hosted-open-source-ai-2026/) for the full model matrix and cost calculation.

More on this: [AI Infrastructure](/en/services/infrastructure/)

<a href="/en/contact/" target="_blank" rel="noopener noreferrer">Book a consultation</a> - We will show you the optimal hosting strategy for your requirements.

--- Model-Agnostic Architecture: Avoiding LLM Lock-In ---
> Decouple business logic from the language model. Agents, Decision Layer, and rule sets stay unchanged when models switch. No vendor lock-in.

## The Risk: One Model, One Vendor

Many companies build their AI strategy on a single model. "We use ChatGPT" or "We run on Claude." Prompts are optimized for that model. Integrations are built for that vendor's API. Workflows are tailored to that model's characteristics.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">At a Glance - Model-Agnostic Architecture</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Building on a single LLM vendor creates dangerous dependency: prices shift, APIs change, models get deprecated on short notice.</li>
<li>A model-agnostic architecture decouples business logic from the language model - agents, Decision Layer, and workflows remain untouched during model switches.</li>
<li>Multi-model routing assigns budget models to simple tasks and flagships to complex reasoning, saving 40-60% on token costs.</li>
<li>Self-hosted models handle sensitive data while cloud APIs serve non-critical requests - governed by the Decision Layer.</li>
<li>Forrester (2024) reports that organizations with model-agnostic architectures reduce LLM migration costs by up to 70% compared to single-vendor setups.</li>
</ul>
</div>

Then one of three things happens: The vendor raises prices. The vendor changes the API. A new model appears that is significantly better or cheaper. In every case: The entire implementation needs to be adapted.

In the LLM market, this happens fast. Over the past 18 months, prices have halved, new vendors have entered the market, open-source models have surpassed proprietary models in benchmarks. Anyone locked into a single vendor cannot capitalize on these developments.

## Model-Agnostic as an Architectural Principle

In the Gosign [reference architecture](/en/governance/reference-architecture/), the Model Layer is an interchangeable layer. Business logic, including rule sets, decision logic, and workflows, is implemented in the Decision Layer and Agent Layer, not in the model.

When a new model becomes available, it can be integrated without changing the layers above it. The agent does not know which model it is using. It sends a request to the Model Layer and receives a response. Which model delivers the response is irrelevant to the agent.

## Multi-Model Routing

An agent can use multiple models simultaneously. The routing is rule-based:

**Cost optimization:** Simple tasks (document classification, data extraction) run on a cost-efficient model. Complex tasks (decision support, rule interpretation) run on a more powerful model.

**Data residency:** Sensitive data goes to self-hosted models ([Llama](https://llama.meta.com/), [Mistral](https://mistral.ai/), [DeepSeek](https://www.deepseek.com/)). Non-critical data can be routed through cloud APIs.

**Failover:** If a model provider goes down, the system can automatically switch to an alternative model.

The routing rules are configured in the Decision Layer and fully traceable.

## Supported Models

The Gosign architecture currently supports (as of 2026):
- Claude Opus 4.7 / Sonnet 4.6 / Haiku 4.5 (Anthropic) - Cloud API
- GPT-5.5 / GPT-5.5-mini (OpenAI) - Cloud API
- Gemini 3.1 Pro / 3.1 Flash (Google) - Cloud API
- Llama 4 Scout / Llama 4 Maverick (Meta) - Self-Hosted or Cloud
- Mistral Small 3.2 / Mistral Large (Mistral AI) - Self-Hosted or Cloud
- DeepSeek V4-Pro / V4-Flash / R1 (DeepSeek) - Self-Hosted or Cloud
- gpt-oss (OpenAI) - Self-Hosted or Cloud

New models can be integrated as soon as they are accessible via a standard API. Which of these models is the right one for which micro-decision is covered in the companion piece: [When which model? Decision Routing for agentic workflows](/en/magazine/ai-models-comparison-2026/).

| Aspect | Single-Vendor Setup | Model-Agnostic Architecture |
|---|---|---|
| Model Switch | Full rebuild of prompts, integrations, workflows | Routing rule change, no rebuild |
| Cost Control | Locked to one pricing model | Budget models for simple tasks, flagships for complex |
| Data Sovereignty | Depends on vendor | Self-hosted for sensitive, cloud for non-critical |
| Failover | No alternative if provider is down | Automatic switch to alternative model |
| Migration Cost | High (Forrester: up to 70% higher) | Low (configuration change only) |
| Future-Proofing | Risk of deprecation | New models slot in without changes |

More on this: [AI Infrastructure](/en/services/infrastructure/)

## Model-Agnostic Plus Decision Routing

Model-agnostic architecture is the precondition; Decision Routing per micro-decision is the application. Build the routing layer once, and model choice becomes a configuration setting, while a model upgrade becomes a config diff rather than a re-engineering effort. Which model fits which decision type - classification, tool-use, reasoning, long-context - is laid out in the master comparison: [When which model? Decision Routing for agentic workflows](/en/magazine/ai-models-comparison-2026/).

<a href="/en/contact/" target="_blank" rel="noopener noreferrer">Book a consultation</a> - We will show you the model-agnostic architecture in detail.

--- Running Next.js on Supabase Securely ---
> DevOps runbook for Next.js on Supabase: architecture, middleware, auth patterns, rate limiting, and Claude Code integration.

Once Supabase is [running reliably as a self-hosted backend platform](/en/magazine/supabase-self-hosting/), the actual application stack is built on top of it.

In many modern projects, **Next.js** takes on the role of the app layer:

- Frontend Rendering
- Server Side Rendering
- Server Actions
- Route Handlers
- API Proxy
- Session Handling

This makes Next.js effectively a **backend gateway between browser and Supabase**.

The most common mistake is treating this layer as a "frontend" when it actually contains **server-side logic with elevated privileges**.

This runbook describes how to run Next.js securely on top of a self-hosted Supabase platform.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">At a Glance - Part 2 of 6 in the DevOps Runbook Series</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Next.js runs as a separate container, physically isolated from Supabase</li>
<li>service_role key allowed in exactly one file only (lib/supabase/admin.ts)</li>
<li>Middleware with getUser() on every request (not getSession())</li>
<li>Ownership checks in all server actions before data mutations</li>
<li>Rate limiting with Upstash Redis on all auth endpoints</li>
</ul>
</div>

Each section contains:

- Implementation
- Verifiable condition
- Failure scenario

## Series Table of Contents

This guide is part of our DevOps runbook series for self-hosted app stacks.

1. [Supabase Self-Hosting Runbook](/en/magazine/supabase-self-hosting/)
2. Running Next.js on Supabase Securely - this article
3. [Deploying Supabase Edge Functions Securely](/en/magazine/supabase-edge-functions-secure/)
4. [Running Trigger.dev Background Jobs Securely](/en/magazine/trigger-dev-background-jobs/)
5. [Claude Code as Security Control in DevOps Workflows](/en/magazine/claude-code-security-devops/)
6. [Security Baseline for the Entire Stack](/en/magazine/security-baseline-stack/)

Article 1 describes the platform foundation. This article covers the **app layer on top**.

## Architecture Overview

```
Browser (Client)
     |
     | HTTPS
     |
Next.js App Layer
     |
     +-- @supabase/ssr
     |
     +-- service_role client
           (isolated admin contexts only)
     |
Supabase Platform Layer
     |
     +-- Kong API Gateway
     +-- GoTrue Auth
     +-- PostgREST API
     +-- Realtime
     |
PostgreSQL Data Layer
     |
     +-- Row Level Security
```

Ground rules:

```
Browser    -> talks only to Next.js
Next.js    -> talks to Supabase
Supabase   -> controls access via RLS
```

When the browser talks to multiple backend services directly, uncontrollable security boundaries emerge.

## Part A - Architecture Decisions

These decisions are rarely changed and form the foundation.

## A1 - Run Next.js as Its Own Service

### Implementation

Next.js runs as its own container.

```
services

nextjs-app
supabase-stack
postgres
```

Example docker-compose:

```yaml
services:

  nextjs-app:
    build: ./app
    ports:
      - "3000:3000"
    environment:
      - NEXT_PUBLIC_SUPABASE_URL=http://kong:8000
      - NEXT_PUBLIC_SUPABASE_ANON_KEY=${ANON_KEY}
      - SUPABASE_SERVICE_ROLE_KEY=${SERVICE_ROLE_KEY}
    networks:
      - internal
```

Next.js must **not run inside the Supabase stack**.

### Verifiable Condition

```
docker ps --format '{{.Names}}'
```

Expected:

```
nextjs-app
supabase-kong
supabase-postgres
supabase-auth
```

### Failure Scenario

If Next.js runs in the same container as Supabase:

- Process space is shared
- Secrets live in the same environment
- A compromised Next.js server has direct access to all backend services

## A2 - Browser Talks Only to Next.js

### Implementation

The browser must only see a single public URL.

```
https://app.example.com
```

Not allowed:

```
https://app.example.com:8000
https://app.example.com:5432
https://app.example.com:9000
```

Firewall example:

```
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -p tcp --dport 8000 -j DROP
iptables -A INPUT -p tcp --dport 5432 -j DROP
iptables -A INPUT -p tcp --dport 9000 -j DROP
```

### Verifiable Condition

```
nmap -p 443,3000,5432,8000,9000 app.example.com
```

Expected:

```
443 open
all others filtered
```

### Failure Scenario

If Supabase Studio is publicly accessible:

- Full database access
- Schema manipulation
- Access to storage buckets

## A3 - Set Security Headers

Next.js acts as a gateway and must set HTTP security headers.

### Implementation

```
next.config.js
```

```javascript
const securityHeaders = [
  { key: "X-Frame-Options", value: "DENY" },
  { key: "X-Content-Type-Options", value: "nosniff" },
  { key: "Referrer-Policy", value: "strict-origin-when-cross-origin" },
  { key: "Permissions-Policy", value: "camera=(), microphone=()" },
  { key: "Strict-Transport-Security", value: "max-age=63072000; includeSubDomains" },
  {
    key: "Content-Security-Policy",
    value: "default-src 'self'; img-src 'self' data: blob:; frame-ancestors 'none'"
  }
]
```

### Verifiable Condition

```
curl -I https://app.example.com
```

Expected headers:

```
X-Frame-Options
Content-Security-Policy
Strict-Transport-Security
```

### Failure Scenario

Without CSP:

- XSS attacks can load external scripts
- Tokens can be exfiltrated

## Part B - Implementation Checks

These rules apply to every code change.

## B1 - Separate Environment Variables

An analysis of over 500 Next.js deployments shows that 23% of production Next.js instances expose at least one server-side environment variable in the client bundle (Snyk State of Open Source Security 2024).

### Environment Variables Overview

| Variable | Visibility | Allowed Location | Risk if Leaked |
|----------|-----------|-----------------|---------------|
| NEXT_PUBLIC_SUPABASE_URL | Client | .env, code | Low (public) |
| NEXT_PUBLIC_SUPABASE_ANON_KEY | Client | .env, code | Medium (RLS protects) |
| SUPABASE_SERVICE_ROLE_KEY | Server-only | .env, lib/supabase/admin.ts | Critical (bypasses RLS) |
| DATABASE_URL | Server-only | .env | Critical (full DB access) |
| TRIGGER_API_KEY | Server-only | .env | High (job execution) |

Client-visible:

```
NEXT_PUBLIC_SUPABASE_URL
NEXT_PUBLIC_SUPABASE_ANON_KEY
```

Server-only:

```
SUPABASE_SERVICE_ROLE_KEY
DATABASE_URL
TRIGGER_API_KEY
```

### Verifiable Condition

```
grep -r "NEXT_PUBLIC_" .env*
```

Secrets must not appear there.

### Build Leak Check

```
grep -r "SERVICE_ROLE" .next/
```

Expected:

```
no matches
```

### Failure Scenario

`service_role` in the client bundle means:

- Full database access
- RLS completely ineffective

Anyone familiar with [the fundamentals of secret management](/en/magazine/data-security-ai-enterprise/) understands why this separation is essential.

## B2 - Configure the Supabase SSR Client Correctly

Server client:

```typescript
import { createServerClient } from "@supabase/ssr"
```

The server uses the **anon key**, not service_role.

Admin client:

```typescript
createClient(url, SERVICE_ROLE_KEY)
```

For administrative tasks only.

### Verifiable Condition

```
grep -rn "SERVICE_ROLE" app/
```

Expected: only in

```
lib/supabase/admin.ts
```

### Failure Scenario

Server client with service_role:

- RLS is completely bypassed
- All requests have admin privileges

## B3 - Middleware for Auth and Token Refresh

Middleware runs **before every request**.

```
middleware.ts
```

### Implementation

```typescript
const { data: { user } } = await supabase.auth.getUser()
```

Not:

```
getSession()
```

### Verifiable Condition

```
grep getUser middleware.ts
```

### Failure Scenario

Without middleware:

- Token refresh does not work
- Session breaks after 1h

## B4 - Mutation Pattern

All mutations follow the same flow.

```
Auth
Input Validation
Ownership Check
Mutation
Logging
```

### Example

```typescript
const { user } = await supabase.auth.getUser()

if (!user) return

const post = await supabase
  .from("posts")
  .select("user_id")
  .eq("id", postId)

if (post.user_id !== user.id)
  throw new Error("forbidden")
```

### Failure Scenario

Without ownership check:

```
deletePost(id)
```

A user can delete other users' data.

## B5 - Rate Limiting

Next.js has no built-in rate limiting.

Recommended solution:

```
Upstash Redis
```

### Example

```
10 requests / minute / IP
```

### Verifiable Condition

```
for i in {1..20}
do curl -X POST /api/login
done
```

Expected:

```
HTTP 429
```

## B6 - Logging Without Secrets

Logs must not contain:

```
JWT Tokens
service_role keys
emails
passwords
```

### Verifiable Condition

```
grep console.log app/
```

## Part C - Operations

## C1 - Dependency Updates

Next.js releases are frequent.

Check weekly:

```
npm audit
npm outdated
```

Recommended:

```
Renovate / Dependabot
```

## C2 - Claude Code Integration

Architecture:

```
Git Push
   |
Deterministic Checks
   |
Security Report
   |
Claude Analysis
   |
DevOps Decision
```

### Deterministic Checks

```
grep service_role
grep NEXT_PUBLIC
npm audit
```

### Claude Analysis

Claude checks:

- New server actions
- New API routes
- Ownership patterns
- Input validation
- Architecture drift

Claude does **not execute changes on production**. The full audit workflow is described in [Claude Code as a Security Control in DevOps Workflows](/en/magazine/claude-code-security-devops/).

## Deployment Checklist

Check before every deployment:

```
[ ] Next.js runs as its own service
[ ] Supabase ports closed externally
[ ] Security headers active

[ ] No service_role in client bundle
[ ] service_role only in admin client

[ ] middleware.ts present
[ ] Server actions check auth
[ ] Ownership checks implemented

[ ] Login rate limit active

[ ] npm audit without critical findings
```

## Conclusion

In the modern stack, Next.js is not a frontend - it is a privileged server layer.

Security comes from three levels:

```
Architecture
Implementation checks
Ongoing audits
```

The combination of CI security checks and Claude Code analysis catches both known patterns and emerging risks.

Anyone pursuing these principles together with a [Cert-Ready-by-Design architecture](/en/magazine/cert-ready-by-design/) builds verifiable security instead of retroactive audits.

<div class="not-prose my-12 border border-gosign-border bg-gosign-light rounded-card p-6 lg:p-8">
<div class="flex items-start gap-4">
<div class="flex-shrink-0 w-12 h-12 bg-gosign-dark rounded-card flex items-center justify-center">
<svg width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="white" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 15v4a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2v-4"/><polyline points="7 10 12 15 17 10"/><line x1="12" y1="15" x2="12" y2="3"/></svg>
</div>
<div>
<h2 class="text-h3 font-bold text-gosign-dark mb-2" id="audit-checklist-download">Audit Checklist Download</h2>
<p class="text-body text-gosign-text mb-2">Prepared prompt for Claude Code. Upload the file to your server and start Claude Code in your Next.js application's project directory. Claude Code will automatically check all security points from this runbook and report PASS, WARNING, or CRITICAL.</p>
<p class="text-sm text-gosign-text mb-4 font-mono">claude -p "$(cat claude-check-artikel-2-nextjs-en.md)" --allowedTools Read,Grep,Glob,Bash</p>
<a href="/downloads/claude-check-artikel-2-nextjs-en.md" download class="inline-flex items-center px-6 py-3 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-small uppercase tracking-wider">Download checklist</a>
</div>
</div>
</div>

## Series Table of Contents

1. [Supabase Self-Hosting Runbook](/en/magazine/supabase-self-hosting/)
2. Running Next.js on Supabase Securely - this article
3. [Deploying Supabase Edge Functions Securely](/en/magazine/supabase-edge-functions-secure/)
4. [Running Trigger.dev Background Jobs Securely](/en/magazine/trigger-dev-background-jobs/)
5. [Claude Code as Security Control in DevOps Workflows](/en/magazine/claude-code-security-devops/)
6. [Security Baseline for the Entire Stack](/en/magazine/security-baseline-stack/)

The next article describes how to [deploy Supabase Edge Functions securely](/en/magazine/supabase-edge-functions-secure/) - without building a second backend architecture.

--- PII Anonymization for Enterprise AI ---
> How to process documents containing personal data with AI while maintaining GDPR compliance. Roundtrip pseudonymization, Decision Layer, audit trail.

## Why Personal Data Is a Problem for AI Processing

When an AI agent analyzes an employment contract, reviews a payroll statement, or processes a sick note, it works with personal data. Name, address, date of birth, social security number, salary, diagnosis.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">At a Glance - PII Anonymization for Enterprise AI</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Roundtrip pseudonymization replaces PII with consistent pseudonyms before LLM processing, then re-inserts real data in the output.</li>
<li>The Decision Layer governs which PII categories are detected per process (HR, finance, compliance) through versioned rulesets.</li>
<li>Pseudonymization preserves document structure and context - unlike redaction, which renders documents unusable for AI analysis.</li>
<li>Confidence Routing escalates ambiguous entities to a human; implicit identifiers require context rules in the ruleset.</li>
<li>IAPP (2024) finds that 58% of organizations processing documents with AI have no systematic PII detection in place, exposing them to GDPR enforcement risk.</li>
</ul>
</div>

Sending this data to a language model - even a self-hosted one - creates [GDPR compliance](/en/governance/data-residency/) risk. The regulation requires data minimization (Art. 5(1)(c)): only data necessary for the purpose may be processed. Classifying a document type does not require an employee's name. Checking salary band compliance does not require a date of birth.

Yet the model needs context. A contract stripped of all personal information is useless for AI analysis - the references, relations, and connections are missing.

The solution is not redaction, but pseudonymization.

## Roundtrip Pseudonymization: The Principle

Roundtrip pseudonymization is a three-stage process:

**Step 1: Detect and Replace.** The pre-processing layer identifies all personal data in the document. Each PII instance is replaced with a consistent pseudonym: "John Smith" becomes "Person_A", "£85,000" becomes "Salary_A", "10 Downing Street" becomes "Address_A". Critically, pseudonyms are consistent - if "John Smith" appears again on page 3, he remains "Person_A". This preserves document structure.

**Step 2: Process.** The pseudonymized document is sent to the language model. The model sees: "Person_A has Salary_A at Address_A. The contract runs until 2027." It can perform contract analysis, salary band checks, clause classification - without ever seeing a real name or salary.

**Step 3: Re-anonymize.** The model's output contains pseudonyms: "Person_A falls within salary band E3." The re-anonymization layer replaces pseudonyms with real data: "John Smith falls within salary band E3." The mapping table is deleted after processing.

## What the Decision Layer Controls

Not every data field requires pseudonymization. The Decision Layer defines which PII categories are detected and replaced - governed by versioned rulesets:

For an HR process: pseudonymize names, salaries, addresses, social security numbers. Job titles and departments can remain - they are relevant for analysis and not personally identifiable.

For a finance process: company names remain, contact persons are pseudonymized, amounts remain (required for booking decisions), bank details are pseudonymized.

For a compliance process: pseudonymize everything - including company names, if the analysis should be cross-organizational.

These rules are tenant-specific and versioned. When a works council agreement (Betriebsvereinbarung) changes, a new rule version is created. During an audit, it is traceable which PII rule in which version was applied at the time of processing.

## Limitations and Honest Assessment

PII detection is not perfect. Named Entity Recognition (NER) makes errors - particularly with:

Ambiguous names: "Baker" can be a surname or an occupation. "London" can be a city or a surname. The Decision Layer addresses this through confidence routing: high confidence triggers automatic pseudonymization. Low confidence escalates to a human.

Implicit identifiers: "The only female developer in the Hamburg office" contains no explicit PII but identifies a person. Such indirect identifiers are difficult to detect automatically. The approach: context rules in the ruleset define which combinations of attributes enable identification.

New document types: When a new document type enters processing, the PII ruleset must be reviewed and potentially extended. This is not a one-time setup but an ongoing process.

| PII Category | HR Process | Finance Process | Compliance Process |
|---|---|---|---|
| Names | Pseudonymized | Contacts pseudonymized | All pseudonymized |
| Salaries / Amounts | Pseudonymized | Remain (booking decisions) | Pseudonymized |
| Addresses | Pseudonymized | Remain | Pseudonymized |
| ID Numbers (SSN) | Pseudonymized | Pseudonymized | Pseudonymized |
| Company Names | Remain | Remain | Pseudonymized |
| Job Titles | Remain | Remain | Context-dependent |
| Bank Details | Pseudonymized | Pseudonymized | Pseudonymized |

More on Document Intelligence: [Document Intelligence - PII, Contract Redaction, Signature Detection](/en/services/document-intelligence/)

<a href="/en/contact/" target="_blank" rel="noopener noreferrer">Schedule a consultation</a> - We demonstrate roundtrip pseudonymization with your documents.

--- RAG & Document Intelligence for Enterprise (2026) ---
> RAG makes enterprise documents AI-accessible - without training, without data egress. Plus: PII anonymization and contract redaction.

## The Central Question: Can AI Understand Our Own Documents?

"Can we have AI answer questions from our own documents?" This question arises in virtually every enterprise. The answer is yes, with RAG (Retrieval Augmented Generation). The principle: your documents stay in your infrastructure. The language model is not trained on your data. Instead, relevant document sections are provided to the model as context with each query. The model answers based on those sections, with source citations.

No data egress to third parties. No retraining. No loss of control. And yet answers in natural language that are grounded directly in your corporate knowledge.

RAG is now the standard approach for connecting language models with organization-specific knowledge. This article explains how RAG works, when it is the right choice, and why Document Intelligence goes far beyond a better search function, including PII anonymization, contract redaction, and signature detection.

IDC (2025) estimates that 90% of all new enterprise data is unstructured - documents, emails, contracts, meeting notes. RAG is the standard method to make this data AI-accessible without retraining the model.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">At a Glance - RAG & Document Intelligence</p>
<ul class="text-body text-gosign-text space-y-2">
<li>RAG connects language models with your enterprise documents - without training, without data egress. Documents stay in your infrastructure.</li>
<li>For 90% of enterprise use cases, RAG beats fine-tuning: lower cost, immediate updates via re-indexing, built-in source citations.</li>
<li>Document Intelligence goes beyond search: PII anonymization, contract redaction, and signature detection are production-ready capabilities.</li>
<li>Indexing quality determines answer quality. Chunking strategy, metadata enrichment, and access control are non-negotiable.</li>
<li>RAG integrates into the Enterprise AI Portal so every department accesses only its authorized knowledge base.</li>
</ul>
</div>

## How RAG Works

RAG consists of two phases: indexing your documents and answering queries. The flow can be illustrated in a diagram:

```
Documents → Chunking → Embedding → Vector Database
│
User Query → Query Embedding → Similarity Search
│
Relevant Sections + Query → LLM → Answer with Source Citation
```

**Phase 1: Indexing.** Your documents, PDFs, Word files, HTML pages, scanned records, are split into meaningful sections (chunking). Each section is converted by an embedding model into a mathematical vector. These vectors are stored in a vector database. The vector represents the meaning of the section, not its wording. "Remote work policy" and "home office agreement" lie close together in vector space, even though they use different words.

**Phase 2: Query.** When a user asks a question, it too is converted into a vector. The vector database finds the sections that are semantically closest to the question, not by keyword search but by similarity calculation. These relevant sections are passed to the language model together with the original question. The model generates an answer based on these specific sources.

The result: an answer in natural language grounded in your documents, with references to the source passages the information came from.

The quality of indexing is decisive. Chunks that are too large dilute relevance. Chunks that are too small lose context. The chunking strategy, size, overlap, metadata enrichment, largely determines answer quality. A good RAG pipeline is not about the technology itself but about its configuration for your specific document landscape.

## RAG vs. Fine-Tuning vs. Prompting

RAG is not the only way to give a language model domain knowledge. There are three fundamental approaches, differing in effort, cost, and suitability:

| Approach | What Happens | When Suitable | Cost | Currency |
|---|---|---|---|---|
| Prompting | Context supplied directly in the prompt | Small data volumes | Low | Immediate |
| RAG | Relevant documents found automatically | Large knowledge bases | Medium | Re-indexing |
| Fine-Tuning | Model retrained | Specialized language/domain | High | Only via retraining |

**Prompting** works when the relevant context fits within the model's context window, typically a few dozen pages. For a single workplace agreement, that is sufficient. For a knowledge base with hundreds of documents, it is not.

**RAG** scales to large document collections. The vector database can hold hundreds of thousands of sections. With each query, only the relevant sections are retrieved and passed to the model. Documents can be updated at any time. A re-indexing step is all that is needed. The model does not need to be retrained.

**Fine-Tuning** alters the model's weights themselves. This is appropriate when the model needs to learn entirely new domain language, such as medical terminology or a proprietary nomenclature, or when a very specific output format is required. Fine-tuning is costly, complex, and requires retraining with every update.

For 90% of enterprise use cases, RAG is the right approach. The combination of large knowledge bases, frequent updates, and the need for source citations makes RAG the standard for corporate knowledge.

## Document Intelligence: More Than Search

RAG answers questions based on documents. Document Intelligence goes further: it encompasses all methods by which AI not only reads documents but understands, classifies, and processes them, including the protection of sensitive information.

The three most important application areas in the enterprise context: PII anonymization, contract redaction, and signature detection.

### PII Anonymization: Roundtrip Pseudonymization

Personal data (PII, Personally Identifiable Information) must not be passed to a language model in many use cases. Salaries, real names, employee IDs, health data. GDPR and internal data protection policies set clear boundaries.

The solution is roundtrip pseudonymization. A concrete example:

**Original document:**
"John Smith, Finance Department, salary EUR 85,000, enrolls in the flexible working hours agreement."

**After pseudonymization (input to the model):**
"Person_A, Department_X, Salary_Y, enrolls in the flexible working hours agreement."

The language model processes the query with pseudonymized data. It never sees the real name, the department, or the salary.

**After re-identification (output to the user):**
The placeholders in the result are replaced with the original data. The user sees the complete answer. The model never saw it.

This roundtrip happens automatically. For the user, the process is transparent. For the model, the data is inaccessible at all times. For the [infrastructure](/en/services/infrastructure/), this means: the pseudonymization layer sits between user and model and is technically enforced, not optional.

PII anonymization is especially relevant for HR use cases where personnel files, payroll records, or performance reviews are to be processed with AI support. Without anonymization, such use cases are not GDPR-compliant in the EU.

### Contract Redaction

Contract redaction goes beyond pseudonymization. While pseudonymization replaces data and restores it at the end, redaction physically removes content from the document, irrevocably for the given recipient.

The use case: different departments need different views of the same contract. The legal department sees the full contract. Procurement sees a version without liability clauses. The executive board sees a summary without operational details.

Redaction works on a rule basis. For each document category and each recipient group, rules define which sections are visible and which are redacted. The rules are configured and versioned in the [Decision Layer](/en/decision-layer/), not applied manually.

The result: each role sees exactly the information that is relevant and authorized for them. No manual redaction. No forgotten passages. No versions accidentally forwarded in full.

### Signature Detection

Enterprise contract archives frequently contain thousands of documents. The question of whether a specific contract is fully signed often requires manual page-by-page review. For hundreds of contracts, this is not practical.

Document Intelligence solves this through automated signature detection. The system checks scanned contracts for the presence of signatures at the designated locations. Missing signatures are automatically flagged. The result: an overview of all contracts in the archive that are not yet fully executed, in minutes rather than weeks.

The use case extends beyond mere detection. In combination with a RAG pipeline, the system can also answer questions like: "Which framework agreements with a term exceeding three years were renewed last quarter without a board-level signature?"

## Practical Example: The Works Agreement Assistant

A concrete scenario from HR practice. An HR department at a mid-sized company manages over 100 active works council agreements (Betriebsvereinbarungen): working hours, remote work, business travel, professional development, retirement benefits, workplace reintegration management, data protection, IT usage, and more. Each agreement has amendments, annexes, and cross-references to other agreements.

When a case worker needs to answer the question "What is the remote work policy for part-time employees in production?", today that means: find the right works council agreement, locate the relevant passage, check whether an amendment exists, cross-reference with the collective bargaining agreement, account for site-specific provisions. Result: 30 to 45 minutes of research time. In case of uncertainty, a query to the legal department. Another few days of waiting.

With a RAG-based works agreement assistant: all works council agreements are indexed, including amendments, annexes, and cross-references. The case worker asks the question in natural language. The system finds the relevant passages from the correct documents, accounts for the March 2025 amendment, references the special provision for production employees, and delivers the answer in 10 seconds. With source citation. With rule version.

This is not a theoretical scenario. It is the standard use case with which organizations set up their first RAG pipeline. The effort is manageable: provide documents, configure the chunking strategy, define access rights, test. The [infrastructure](/en/services/infrastructure/), vector database, embedding model, language model, retrieval pipeline, is built once and then available for additional use cases.

## Quality Assurance: Why RAG Results Are Only as Good as the Indexing

RAG is not a self-runner. The most common sources of error in practice:

**Poor chunking strategy.** Chunks that are too large (entire chapters) deliver too much irrelevant context. Chunks that are too small (individual paragraphs) lose coherence. The right chunk size depends on the document type. A technical specification requires different chunks than a works council agreement.

**Missing metadata.** Without metadata (document type, effective date, version, scope), the retrieval pipeline cannot distinguish between a current and an outdated regulation. Metadata enrichment during indexing is not optional. It is essential.

**No access control.** In an enterprise environment, not every user should be able to access all documents. The RAG pipeline must reflect the existing permissions structure: HR documents only for HR, financial data only for Finance, board communications only for authorized individuals.

**No source verification.** RAG provides source citations. But are they correct? Quality assurance, spot-checking source references, feedback mechanisms for users, regular evaluation, is necessary to detect hallucinations and improve the pipeline.

This quality assurance is part of ongoing operations, not a one-time setup. Documents change. New ones are added. Old ones become invalid. The RAG pipeline must evolve, through regular re-indexing, metadata updates, and user feedback.

## Integration into the Enterprise AI Portal

RAG is not an isolated system. In a well-designed architecture, the RAG pipeline is integrated into the [Enterprise AI Portal](/en/magazine/enterprise-ai-chat-interface/). Employees ask questions through a unified interface, the same one through which they also interact with [AI agents](/en/services/ai-agents/).

The portal manages access rights: who may query which knowledge base? HR employees see the works agreement assistant. The legal department sees the contract assistant. Procurement sees the supplier policy assistant. Each user sees only what they are authorized to access.

The combination of RAG and AI agents opens up extended possibilities: an agent can not only answer a question but, based on RAG results, trigger an action, such as generating a deadline alert when a contract is about to expire, or producing a checklist when a new works council agreement takes effect.

---

**📘 Enterprise AI Infrastructure Blueprint 2026 - Article Series**

| ← Previous | Overview | Next → |
|:---|:---:|---:|
| [Enterprise AI Portal: Four Open-Source Interfaces Compared](/en/magazine/enterprise-ai-chat-interface/) | [Overview](/en/magazine/ai-infrastructure-blueprint-2026/) | [From Chatbots to AI Agents: MCP, A2A and Multi-Agent Systems](/en/magazine/ai-agents-enterprise-guide/) |

*All articles in this series: [Enterprise AI Infrastructure Blueprint 2026](/en/magazine/ai-infrastructure-blueprint-2026/)*

---

**Want to make your corporate knowledge AI-accessible?** Gosign builds RAG pipelines and Document Intelligence solutions for enterprise clients, model-agnostic, with PII anonymization and full access control.

<a href="/en/contact/" target="_blank" rel="noopener noreferrer">Book a consultation</a>. 30 minutes to determine which documents should become AI-accessible first.

--- Measuring the ROI of AI Investments ---
> How CFOs evaluate the ROI of enterprise AI. Process costs, error rates, audit effort as measurable KPIs instead of vague productivity promises.

## The Problem with AI ROI

Most ROI calculations for AI investments fail due to imprecision. "30% more productive" sounds convincing in a presentation but cannot be substantiated when nobody has defined what "more productive" means in a specific process.

CFOs know this problem. They see pilot projects that deliver impressive demos but no defensible numbers for the board. They see AI budgets approved as innovation projects without a traceable business case.

This is not because AI lacks ROI. It is because AI is measured at the wrong point.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">At a Glance - Measuring the ROI of Enterprise AI</p>
<ul class="text-body text-gosign-text space-y-2">
<li>AI ROI comes from process efficiency, not individual productivity. One automated document process can save 200+ hours per month.</li>
<li>Five KPIs make ROI measurable: process cost per case, error rate, throughput time, audit effort and scaling costs.</li>
<li>According to McKinsey (2024), enterprises using AI in finance operations achieve 30 - 50% cost reduction in document-intensive processes within the first year.</li>
<li>The Decision Layer separates AI analysis from business decisions and creates an automatic Audit Trail - ROI metrics emerge as a by-product.</li>
<li>Start with one process, one agent, and measure KPIs after 4 - 6 weeks. The difference is the ROI - no slide deck needed.</li>
</ul>
</div>

## Where ROI Actually Originates

The ROI of enterprise AI does not arise from individual employee productivity. It arises from process efficiency across entire workflows.

An example: in an HR shared services organisation, a team of 8 clerks processes 1,200 sick notes monthly. Each case takes an average of 12 minutes: open document, verify data, calculate deadlines, book in SAP, inform line manager. That is 240 hours per month for a single document type.

A [Document Agent](/en/services/ai-agents/) reduces manual processing time per case to under 2 minutes - for standard cases to zero, because the agent automates the entire process through to the approval stage. Clerks only review exceptions and escalations.

This is not a vague productivity promise. It is a measurable reduction from 240 to 40 hours per month - for a single process. Multiplied across 5 - 10 processes, the result is a business case any CFO understands.


## The Right KPIs

Five KPIs make the ROI of AI agents measurable and internally communicable.

First: process cost per case. What does it cost to process a sick note, an invoice, a contract today? What does it cost after agent deployment? The difference is the direct ROI.

Second: error rate. Manual processes typically have error rates of 2 - 5%. A rule-based agent makes errors only when rules are flawed - and rules are versioned and correctable. Every avoided error has a quantifiable consequential cost.

Third: throughput time. How long does a case take from receipt to completion? Agents reduce idle time to near zero - the case is processed as soon as it arrives, not when a clerk picks it up.

Fourth: audit effort. In regulated processes (payroll (UK: PAYE) tax, external audit, SOX), significant effort goes into manual documentation and evidence management. An agent with a [Decision Layer](/en/finance-ai-agents/) documents automatically: which rule was applied, what data was available, what decision was made, who approved. The audit trail is a by-product of the process itself.

Fifth: scaling costs. What does it cost to increase current volume by 50%? With manual processes: more headcount. With agent infrastructure: more compute capacity. The cost curves diverge radically.

<div class="overflow-x-auto">

| KPI | Manual Process | With AI Agent | Measurement Method |
|-----|---------------|---------------|-------------------|
| Process cost per case | $15 - $60 | $2 - $8 | Before/after comparison |
| Error rate | 2 - 5% | < 0.5% | Sample audit |
| Throughput time | 1 - 5 days | Minutes | Timestamp delta |
| Audit effort | 40 - 80 h/month | < 5 h/month | Hours logged |
| Scaling cost (+50% volume) | +50% headcount | +10% compute | Cost tracking |

</div>

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Free eBook: AI in Finance</p>
<p class="text-body text-gosign-text mb-4">Compliance, external auditors, and Decision Layer - the governance handbook for finance leaders.</p>
<a href="/en/ebook/ai-finance-governance-handbook/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Download for free</a>
</div>

## The Decision Layer as ROI Lever

The [Decision Layer](/en/finance-ai-agents/) is the point where ROI becomes measurable. It separates AI analysis from business decisions and documents both as auditable records.

This means: for every case, a complete data record exists - input, rule applied, agent recommendation, human decision, timestamp. ROI metrics can be derived automatically from these records, without manual data collection.

It also follows that ROI improves over time. Because rule adjustments are versioned and their impact on error rates and throughput times is measurable, a continuous optimisation cycle emerges - documented and traceable.


## How Enterprises Should Start

Not with an AI strategy. With a specific process.

Identify the process with the highest volume and highest manual costs. Measure the baseline: current process costs, error rate, throughput time. Build an agent for it and measure the same KPIs after 4 - 6 weeks.

The difference is the ROI. No slide deck, no estimate - hard numbers from a productive process.

At Gosign, we build [AI agents](/en/services/ai-agents/) with precisely this approach: one process, one agent, measurable KPIs after 4 - 6 weeks. The [Decision Layer](/en/finance-ai-agents/) automatically delivers the data foundation for the business case.

--- Security Baseline for the Full Stack ---
> DevOps runbook: A YAML-based security baseline for Supabase, Next.js, Edge Functions, and Trigger.dev with automated checks and Claude Code integration.

The previous runbooks described the individual components: [Supabase Platform](/en/magazine/supabase-self-hosting/) (Article 1), [Next.js App Layer](/en/magazine/nextjs-supabase-secure-setup/) (Article 2), [Edge Functions](/en/magazine/supabase-edge-functions-secure/) (Article 3), [Trigger.dev Jobs](/en/magazine/trigger-dev-background-jobs/) (Article 4), and [Claude Code as a Security Control](/en/magazine/claude-code-security-devops/) (Article 5).

This final article consolidates all rules into a **single, machine-readable file**: the `security-baseline.yml`. This file defines the target state of the entire stack. All deployments, reviews, and audits are checked against this baseline, both by deterministic scripts and by Claude Code.

The article delivers three things:
1. The complete `security-baseline.yml`
2. The script that checks it automatically
3. The integration with the Claude Code audit from Article 5

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">At a Glance - Part 6 of 6 in the DevOps Runbook Series</p>
<ul class="text-body text-gosign-text space-y-2">
<li>A single YAML file (security-baseline.yml) defines the desired state of the entire stack</li>
<li>Daily automated check validates all rules deterministically</li>
<li>Weekly Claude Code analysis interprets results and prioritizes findings</li>
<li>Deployment gate blocks releases on critical baseline violations</li>
<li>Living document: baseline updated with every stack change</li>
</ul>
</div>

## Series Table of Contents

This guide is part of our DevOps runbook series for self-hosted app stacks.

1. [Supabase Self-Hosting Runbook](/en/magazine/supabase-self-hosting/)
2. [Running Next.js on Supabase Securely](/en/magazine/nextjs-supabase-secure-setup/)
3. [Deploying Supabase Edge Functions Securely](/en/magazine/supabase-edge-functions-secure/)
4. [Running Trigger.dev Background Jobs Securely](/en/magazine/trigger-dev-background-jobs/)
5. [Claude Code as a Security Control in the DevOps Workflow](/en/magazine/claude-code-security-devops/)
6. [Security Baseline for the Full Stack](/en/magazine/security-baseline-stack/) - this article

This article connects all previous runbooks - from [Supabase infrastructure](/en/magazine/supabase-self-hosting/) to [Edge Function webhook security](/en/magazine/supabase-edge-functions-secure/) - into a **verifiable security strategy**.

## Architecture Overview

```
security-baseline.yml
   |
   +---> scripts/check-baseline.sh     (deterministic, daily)
   |       |
   |       +---> baseline-report.md    (facts: passed/failed)
   |
   +---> Claude Code Audit             (contextual, weekly)
   |       |
   |       +---> claude-review.md      (interpretation + priorities)
   |
   +---> Deployment Gate               (CI/CD, on every deploy)
           |
           +---> Deploy blocked when critical rules are violated
```

The baseline is the **Single Source of Truth** for the security state. Everything else - the check scripts, the [Claude Code contextual analysis layer](/en/magazine/claude-code-security-devops/), the deployment checklists from Articles 1-5 - derives from it.

## The security-baseline.yml

This file belongs in the root of the infrastructure repository. It is machine-readable (YAML), human-readable (comments), and interpretable by Claude Code (context).

Organizations with a machine-readable security baseline detect configuration drift on average 14x faster than teams without a baseline (SANS Institute 2024).

### Baseline Category Overview

| Category | Rule Count | Check Frequency | Escalation on Violation |
|----------|-----------|----------------|----------------------|
| Infrastructure (Network, Firewall, SSH) | 8 | Daily | CRITICAL: immediate |
| Supabase (Containers, RLS, Secrets) | 7 | Daily | CRITICAL: immediate |
| Next.js (Auth, Headers, Env Vars) | 6 | Daily | WARNING: this week |
| Edge Functions (Signatures, CORS, Secrets) | 5 | Daily | CRITICAL: immediate |
| Trigger.dev (Tasks, Concurrency, Secrets) | 6 | Daily | WARNING: this week |
| Compliance (Git, Data Residency) | 3 | Weekly | WARNING: this week |

```yaml
# security-baseline.yml
# Security Baseline für den self-hosted Stack
# Letzte Aktualisierung: 2026-03-12
# Verantwortlich: DevOps Team
#
# Diese Datei definiert den Soll-Zustand des gesamten Stacks.
# Sie wird täglich automatisch geprüft (scripts/check-baseline.sh)
# und wöchentlich von Claude Code kontextuell analysiert.

version: "1.0"
stack: "supabase-nextjs-trigger"
last_reviewed: "2026-03-12"

# =============================================
# INFRASTRUKTUR (Artikel 1)
# =============================================

infrastructure:
  servers:
    production:
      host: "10.0.1.10"
      external_hostname: "app.example.com"
      provider: "hetzner"    # CLOUD-Act-frei
    audit:
      host: "10.0.1.11"
      purpose: "security checks, monitoring, claude code"

  network:
    private_subnet: "10.0.1.0/24"
    # Nur diese Ports dürfen von aussen erreichbar sein
    allowed_external_ports:
      - 443    # HTTPS (über Reverse Proxy)
    # Diese Ports dürfen NUR intern erreichbar sein
    internal_only_ports:
      - 5432   # PostgreSQL (Supabase)
      - 5433   # PostgreSQL (Trigger.dev)
      - 8000   # Kong API Gateway
      - 3000   # Next.js (hinter Reverse Proxy)
      - 3040   # Trigger.dev Dashboard
      - 9000   # Supabase Studio

  firewall:
    layers: 2    # Cloud Firewall + Host Firewall
    baseline_file: "/opt/baselines/firewall-baseline.txt"
    drift_check: "daily"

  tls:
    provider: "letsencrypt"
    min_days_before_expiry: 14
    headers_required:
      - "Strict-Transport-Security"
      - "X-Frame-Options"
      - "X-Content-Type-Options"
      - "Content-Security-Policy"

  ssh:
    password_auth: false
    root_login: false
    pubkey_only: true
    allowed_users: ["deploy"]

  backups:
    frequency: "daily"
    max_age_hours: 26
    encryption: "gpg"
    external_storage: true    # auf audit-runner, nicht nur lokal
    restore_test: "monthly"

# =============================================
# SUPABASE PLATFORM (Artikel 1)
# =============================================

supabase:
  images:
    pinned: true              # kein :latest
    # Erwartete Images und Versionen (aktualisieren bei Updates)
    postgres: "supabase/postgres:15.6.1.143"
    kong: "kong:2.8.1"
    gotrue: "supabase/gotrue:v2.164.0"

  postgres:
    listen_address: "10.0.1.10"    # NUR internes Interface
    rls:
      required_on_all_public_tables: true
      # Tabellen die bewusst ohne RLS sind (mit Begründung)
      exceptions: []

  gotrue:
    jwt_exp: 3600               # max. 1 Stunde
    mailer_autoconfirm: false
    refresh_token_rotation: true

  studio:
    external_access: false      # nur über SSH Tunnel oder VPN

  secrets:
    env_file: ".env"
    env_file_permissions: "600"
    in_git: false
    min_length: 16
    # Erwartete Secrets (ohne Werte)
    required:
      - "JWT_SECRET"
      - "ANON_KEY"
      - "SERVICE_ROLE_KEY"
      - "POSTGRES_PASSWORD"
      - "DASHBOARD_USERNAME"
      - "DASHBOARD_PASSWORD"

# =============================================
# NEXT.JS APP LAYER (Artikel 2)
# =============================================

nextjs:
  service_role:
    # Dateien in denen service_role erlaubt ist
    allowed_files:
      - "lib/supabase/admin.ts"
    # Darf NIEMALS erscheinen in:
    forbidden_patterns:
      - "NEXT_PUBLIC_*"
      - "app/**/*.tsx"           # Client Components
      - ".next/static/**"        # Client Bundle

  auth:
    middleware_required: true
    middleware_file: "middleware.ts"
    middleware_uses: "getUser"     # NICHT getSession
    server_actions_require_auth: true
    route_handlers_require_auth: true

  security_headers:
    required:
      - "Strict-Transport-Security"
      - "X-Frame-Options"
      - "Content-Security-Policy"
      - "X-Content-Type-Options"

  env_vars:
    # Nur diese dürfen NEXT_PUBLIC sein
    allowed_public:
      - "NEXT_PUBLIC_SUPABASE_URL"
      - "NEXT_PUBLIC_SUPABASE_ANON_KEY"

  rate_limiting:
    required_endpoints:
      - "/api/auth/login"
      - "/api/auth/signup"
      - "/api/auth/reset"

# =============================================
# EDGE FUNCTIONS (Artikel 3)
# =============================================

edge_functions:
  purpose: "integrations_only"     # NICHT für Business-Logik
  runtime: "deno"

  requirements:
    webhook_signature_check: true
    input_validation: true
    cors_no_wildcard_in_production: true
    no_hardcoded_secrets: true
    max_duration_seconds: 60

  secrets:
    env_file: ".env.functions"
    in_git: false

  deployment:
    method: "volume_copy"          # Dateien ins Volume, Container restart

# =============================================
# TRIGGER.DEV (Artikel 4)
# =============================================

trigger_dev:
  version: "v3"
  hosting: "self-hosted"
  separate_database: true           # eigene PostgreSQL, nicht Supabase DB

  dashboard:
    external_access: false          # nur SSH Tunnel oder VPN

  task_requirements:
    max_duration_required: true
    concurrency_limit_required: true
    retry_config_required: true
    idempotency_on_external_calls: true
    exported: true                  # alle Tasks müssen exportiert sein

  logging:
    use_trigger_logger: true        # nicht console.log
    no_sensitive_data: true

  db_access:
    # Dateien in denen service_role / DATABASE_URL erlaubt ist
    allowed_files:
      - "trigger/lib/supabase.ts"
      - "trigger/lib/db.ts"
    connection_pool_max: 10

# =============================================
# CLAUDE CODE AUDIT (Artikel 5)
# =============================================

claude_code:
  runs_on: "audit-runner"           # NICHT auf Produktion
  allowed_tools: "Read,Grep,Glob"   # kein Bash
  max_turns: 10
  schedule: "weekly"                # Sonntag 06:00
  alert_on: "KRITISCH"

  api_key:
    separate_ci_key: true
    budget_limit_monthly_usd: 50

# =============================================
# COMPLIANCE
# =============================================

compliance:
  cloud_act:
    us_providers_allowed: false
    reason: "CLOUD Act Risiko: US-Behörden können Datenzugriff erzwingen"
    allowed_jurisdictions:
      - "EU"
      - "BR"

  data_residency:
    required: true
    allowed_countries:
      - "DE"     # Deutschland (Hetzner)
      - "BR"     # Brasilien

  git:
    no_secrets_in_repo: true
    infrastructure_as_code: true
    no_manual_server_changes: true
```

## The Baseline Check Script

This script reads the `security-baseline.yml` and checks every rule automatically. It runs daily on the audit server.

```bash
#!/bin/bash
# scripts/check-baseline.sh
# Prüft den Produktionsserver gegen die security-baseline.yml
# Läuft auf dem audit-runner (10.0.1.11)

set -euo pipefail

PROD_HOST="10.0.1.10"
EXTERNAL_HOST="app.example.com"
REPORT=""
CRITICAL=0
WARNING=0
PASS=0

check() {
  local level="$1"    # KRITISCH, WARNUNG, INFO
  local name="$2"
  local result="$3"   # PASS oder FAIL
  local detail="$4"

  if [ "$result" = "PASS" ]; then
    REPORT+="  OK ${name}\n"
    ((PASS++))
  else
    REPORT+="  FAIL [${level}] ${name}: ${detail}\n"
    [ "$level" = "KRITISCH" ] && ((CRITICAL++))
    [ "$level" = "WARNUNG" ] && ((WARNING++))
  fi
}

echo "=== Security Baseline Check $(date +%Y-%m-%d) ==="

# -------------------------------------------
# INFRASTRUKTUR
# -------------------------------------------
REPORT+="\n## Infrastruktur\n\n"

# Ports von aussen
OPEN_PORTS=$(nmap -p 22,80,443,3000,3040,5432,5433,8000,9000 "$EXTERNAL_HOST" \
  -oG - 2>/dev/null | grep -oP '\d+/open' | grep -v "443" || true)
if [ -z "$OPEN_PORTS" ]; then
  check "KRITISCH" "Nur Port 443 extern offen" "PASS" ""
else
  check "KRITISCH" "Nur Port 443 extern offen" "FAIL" "Offen: $OPEN_PORTS"
fi

# Firewall Drift
FW_DIFF=$(ssh deploy@${PROD_HOST} "iptables-save" 2>/dev/null | \
  diff /opt/baselines/firewall-baseline.txt - 2>&1 || true)
if [ -z "$FW_DIFF" ]; then
  check "WARNUNG" "Firewall unverändert" "PASS" ""
else
  check "WARNUNG" "Firewall unverändert" "FAIL" "Firewall hat sich geändert"
fi

# SSH Konfiguration
SSH_PW=$(ssh deploy@${PROD_HOST} "sshd -T 2>/dev/null | grep passwordauthentication" || true)
if echo "$SSH_PW" | grep -q "no"; then
  check "KRITISCH" "SSH Passwort-Login deaktiviert" "PASS" ""
else
  check "KRITISCH" "SSH Passwort-Login deaktiviert" "FAIL" "Passwort-Auth noch aktiv"
fi

SSH_ROOT=$(ssh deploy@${PROD_HOST} "sshd -T 2>/dev/null | grep permitrootlogin" || true)
if echo "$SSH_ROOT" | grep -q "no"; then
  check "KRITISCH" "SSH Root-Login deaktiviert" "PASS" ""
else
  check "KRITISCH" "SSH Root-Login deaktiviert" "FAIL" "Root-Login noch möglich"
fi

# TLS Zertifikat
CERT_DAYS=$(echo | openssl s_client -connect ${EXTERNAL_HOST}:443 2>/dev/null | \
  openssl x509 -noout -enddate 2>/dev/null | cut -d= -f2)
if [ -n "$CERT_DAYS" ]; then
  EPOCH_CERT=$(date -d "$CERT_DAYS" +%s 2>/dev/null || echo 0)
  EPOCH_NOW=$(date +%s)
  DAYS_LEFT=$(( (EPOCH_CERT - EPOCH_NOW) / 86400 ))
  if [ "$DAYS_LEFT" -ge 14 ]; then
    check "WARNUNG" "TLS Zertifikat gültig (${DAYS_LEFT} Tage)" "PASS" ""
  else
    check "WARNUNG" "TLS Zertifikat gültig" "FAIL" "Nur noch ${DAYS_LEFT} Tage"
  fi
fi

# Security Headers
for HEADER in "Strict-Transport-Security" "X-Frame-Options" "X-Content-Type-Options"; do
  if curl -sI "https://${EXTERNAL_HOST}" | grep -qi "$HEADER"; then
    check "WARNUNG" "Header: ${HEADER}" "PASS" ""
  else
    check "WARNUNG" "Header: ${HEADER}" "FAIL" "Header fehlt"
  fi
done

# Backup
LAST_BACKUP=$(ssh deploy@${PROD_HOST} "ls -t /opt/backups/*.gpg 2>/dev/null | head -1" || true)
if [ -n "$LAST_BACKUP" ]; then
  BACKUP_AGE=$(ssh deploy@${PROD_HOST} \
    "echo \$(( (\$(date +%s) - \$(stat -c %Y ${LAST_BACKUP})) / 3600 ))" 2>/dev/null || echo 999)
  if [ "$BACKUP_AGE" -le 26 ]; then
    check "KRITISCH" "Backup aktuell (${BACKUP_AGE}h alt)" "PASS" ""
  else
    check "KRITISCH" "Backup aktuell" "FAIL" "${BACKUP_AGE} Stunden alt"
  fi
else
  check "KRITISCH" "Backup aktuell" "FAIL" "Kein Backup gefunden"
fi

# Disk Space
DISK=$(ssh deploy@${PROD_HOST} "df -h / | tail -1 | awk '{print \$5}' | tr -d '%'" 2>/dev/null || echo 99)
if [ "$DISK" -le 85 ]; then
  check "WARNUNG" "Disk Usage (${DISK}%)" "PASS" ""
else
  check "WARNUNG" "Disk Usage" "FAIL" "${DISK}% belegt"
fi

# -------------------------------------------
# SUPABASE
# -------------------------------------------
REPORT+="\n## Supabase\n\n"

# Container laufen
STOPPED=$(ssh deploy@${PROD_HOST} "cd /opt/supabase && docker compose ps --format json 2>/dev/null" | \
  jq -r 'select(.State != "running") | .Name' 2>/dev/null || true)
if [ -z "$STOPPED" ]; then
  check "KRITISCH" "Alle Supabase Container running" "PASS" ""
else
  check "KRITISCH" "Alle Supabase Container running" "FAIL" "Gestoppt: $STOPPED"
fi

# Images gepinnt (kein :latest)
LATEST_IMAGES=$(ssh deploy@${PROD_HOST} "cd /opt/supabase && grep 'image:' docker-compose.yml | grep 'latest'" 2>/dev/null || true)
if [ -z "$LATEST_IMAGES" ]; then
  check "WARNUNG" "Alle Images versioniert (kein :latest)" "PASS" ""
else
  check "WARNUNG" "Alle Images versioniert" "FAIL" "latest gefunden"
fi

# RLS auf allen public-Tabellen
UNPROTECTED=$(ssh deploy@${PROD_HOST} "cd /opt/supabase && docker compose exec -T postgres psql -U postgres -t -c \
  \"SELECT count(*) FROM pg_tables WHERE schemaname = 'public' AND rowsecurity = false;\"" 2>/dev/null | tr -d ' ' || echo "?")
if [ "$UNPROTECTED" = "0" ]; then
  check "KRITISCH" "RLS auf allen public-Tabellen aktiv" "PASS" ""
elif [ "$UNPROTECTED" != "?" ]; then
  check "KRITISCH" "RLS auf allen public-Tabellen aktiv" "FAIL" "${UNPROTECTED} Tabellen ohne RLS"
fi

# Postgres nur intern
PG_LISTEN=$(ssh deploy@${PROD_HOST} "ss -tlnp | grep 5432" 2>/dev/null || true)
if echo "$PG_LISTEN" | grep -q "0.0.0.0:5432"; then
  check "KRITISCH" "Postgres nur auf internem Interface" "FAIL" "Lauscht auf 0.0.0.0"
else
  check "KRITISCH" "Postgres nur auf internem Interface" "PASS" ""
fi

# Studio nicht extern erreichbar
STUDIO=$(curl -s -o /dev/null -w "%{http_code}" --connect-timeout 3 "https://${EXTERNAL_HOST}:9000" 2>/dev/null || echo "000")
if [ "$STUDIO" = "000" ]; then
  check "KRITISCH" "Supabase Studio nicht extern erreichbar" "PASS" ""
else
  check "KRITISCH" "Supabase Studio nicht extern erreichbar" "FAIL" "Status: $STUDIO"
fi

# -------------------------------------------
# NEXT.JS
# -------------------------------------------
REPORT+="\n## Next.js\n\n"

# service_role im Client Code
SR_LEAK=$(ssh deploy@${PROD_HOST} "cd /opt/app && grep -rn 'SERVICE_ROLE\|service_role' app/ \
  --include='*.ts' --include='*.tsx' 2>/dev/null | grep -v 'lib/supabase/admin.ts' | grep -v node_modules" 2>/dev/null || true)
if [ -z "$SR_LEAK" ]; then
  check "KRITISCH" "service_role nicht im Client Code" "PASS" ""
else
  check "KRITISCH" "service_role nicht im Client Code" "FAIL" "Gefunden in: $(echo "$SR_LEAK" | head -3)"
fi

# NEXT_PUBLIC mit Secrets
PUB_SECRET=$(ssh deploy@${PROD_HOST} "cd /opt/app && grep 'NEXT_PUBLIC_' .env* 2>/dev/null | \
  grep -iE 'service_role|secret|private|database'" 2>/dev/null || true)
if [ -z "$PUB_SECRET" ]; then
  check "KRITISCH" "Keine Secrets in NEXT_PUBLIC Variablen" "PASS" ""
else
  check "KRITISCH" "Keine Secrets in NEXT_PUBLIC Variablen" "FAIL" "$PUB_SECRET"
fi

# middleware.ts existiert und nutzt getUser
MW_EXISTS=$(ssh deploy@${PROD_HOST} "test -f /opt/app/middleware.ts && echo yes || echo no" 2>/dev/null || echo "no")
if [ "$MW_EXISTS" = "yes" ]; then
  MW_GETUSER=$(ssh deploy@${PROD_HOST} "grep -c 'getUser' /opt/app/middleware.ts" 2>/dev/null || echo "0")
  if [ "$MW_GETUSER" -gt 0 ]; then
    check "KRITISCH" "middleware.ts existiert mit getUser()" "PASS" ""
  else
    check "KRITISCH" "middleware.ts mit getUser()" "FAIL" "getUser() fehlt"
  fi
else
  check "KRITISCH" "middleware.ts existiert" "FAIL" "Datei fehlt"
fi

# Server Actions ohne Auth
SA_NO_AUTH=$(ssh deploy@${PROD_HOST} "cd /opt/app && for file in \$(grep -rl \"'use server'\" app/ --include='*.ts' 2>/dev/null); do
  if ! grep -q 'getUser' \"\$file\"; then echo \"\$file\"; fi
done" 2>/dev/null || true)
if [ -z "$SA_NO_AUTH" ]; then
  check "WARNUNG" "Alle Server Actions haben Auth Check" "PASS" ""
else
  check "WARNUNG" "Server Actions ohne Auth" "FAIL" "$SA_NO_AUTH"
fi

# npm audit
NPM_HIGH=$(ssh deploy@${PROD_HOST} "cd /opt/app && npm audit --audit-level=high 2>&1 | \
  grep -c 'high\|critical'" 2>/dev/null || echo "0")
if [ "$NPM_HIGH" = "0" ]; then
  check "WARNUNG" "npm audit: keine high/critical" "PASS" ""
else
  check "WARNUNG" "npm audit" "FAIL" "${NPM_HIGH} high/critical Findings"
fi

# -------------------------------------------
# EDGE FUNCTIONS
# -------------------------------------------
REPORT+="\n## Edge Functions\n\n"

# Webhook Functions ohne Signaturprüfung
WH_NO_SIG=$(ssh deploy@${PROD_HOST} "for dir in /opt/supabase/volumes/functions/*-webhook/; do
  [ -d \"\$dir\" ] || continue
  name=\$(basename \"\$dir\")
  if ! grep -qE 'signature|verify|hmac|crypto' \"\$dir/index.ts\" 2>/dev/null; then
    echo \"\$name\"
  fi
done" 2>/dev/null || true)
if [ -z "$WH_NO_SIG" ]; then
  check "KRITISCH" "Alle Webhooks prüfen Signaturen" "PASS" ""
else
  check "KRITISCH" "Webhooks ohne Signaturprüfung" "FAIL" "$WH_NO_SIG"
fi

# Hardcoded Secrets
FN_SECRETS=$(ssh deploy@${PROD_HOST} "grep -rn 'sk_live\|sk_test\|whsec_\|Bearer ey' \
  /opt/supabase/volumes/functions/ --include='*.ts' 2>/dev/null" || true)
if [ -z "$FN_SECRETS" ]; then
  check "KRITISCH" "Keine hardcoded Secrets in Functions" "PASS" ""
else
  check "KRITISCH" "Hardcoded Secrets in Functions" "FAIL" "$FN_SECRETS"
fi

# -------------------------------------------
# TRIGGER.DEV
# -------------------------------------------
REPORT+="\n## Trigger.dev\n\n"

# Tasks ohne maxDuration
TD_NO_DUR=$(ssh deploy@${PROD_HOST} "cd /opt/app && for file in trigger/tasks/*.ts 2>/dev/null; do
  [ -f \"\$file\" ] || continue
  name=\$(basename \"\$file\" .ts)
  if ! grep -q 'maxDuration' \"\$file\"; then echo \"\$name\"; fi
done" 2>/dev/null || true)
if [ -z "$TD_NO_DUR" ]; then
  check "WARNUNG" "Alle Tasks haben maxDuration" "PASS" ""
else
  check "WARNUNG" "Tasks ohne maxDuration" "FAIL" "$TD_NO_DUR"
fi

# Tasks ohne Concurrency
TD_NO_CC=$(ssh deploy@${PROD_HOST} "cd /opt/app && for file in trigger/tasks/*.ts 2>/dev/null; do
  [ -f \"\$file\" ] || continue
  name=\$(basename \"\$file\" .ts)
  if ! grep -qE 'concurrencyLimit|queue:' \"\$file\"; then echo \"\$name\"; fi
done" 2>/dev/null || true)
if [ -z "$TD_NO_CC" ]; then
  check "WARNUNG" "Alle Tasks haben Concurrency Limit" "PASS" ""
else
  check "WARNUNG" "Tasks ohne Concurrency" "FAIL" "$TD_NO_CC"
fi

# Hardcoded Secrets in Tasks
TD_SECRETS=$(ssh deploy@${PROD_HOST} "grep -rn 'sk_live\|sk_test\|SG\.\|sk-' \
  /opt/app/trigger/ --include='*.ts' 2>/dev/null" || true)
if [ -z "$TD_SECRETS" ]; then
  check "KRITISCH" "Keine hardcoded Secrets in Tasks" "PASS" ""
else
  check "KRITISCH" "Hardcoded Secrets in Tasks" "FAIL" "$TD_SECRETS"
fi

# Trigger.dev Dashboard nicht extern
TD_DASH=$(curl -s -o /dev/null -w "%{http_code}" --connect-timeout 3 "https://${EXTERNAL_HOST}:3040" 2>/dev/null || echo "000")
if [ "$TD_DASH" = "000" ]; then
  check "KRITISCH" "Trigger.dev Dashboard nicht extern" "PASS" ""
else
  check "KRITISCH" "Trigger.dev Dashboard nicht extern" "FAIL" "Status: $TD_DASH"
fi

# -------------------------------------------
# COMPLIANCE
# -------------------------------------------
REPORT+="\n## Compliance\n\n"

# Git: keine Secrets im Repo
GIT_SECRETS=$(ssh deploy@${PROD_HOST} "cd /opt/app && git ls-files .env .env.functions .env.trigger 2>/dev/null" || true)
if [ -z "$GIT_SECRETS" ]; then
  check "KRITISCH" ".env Dateien nicht im Git" "PASS" ""
else
  check "KRITISCH" ".env Dateien im Git" "FAIL" "Committed: $GIT_SECRETS"
fi

# Git: keine uncommitted Changes auf dem Server
GIT_DIRTY=$(ssh deploy@${PROD_HOST} "cd /opt/app && git status --porcelain 2>/dev/null" || true)
if [ -z "$GIT_DIRTY" ]; then
  check "WARNUNG" "Keine manuellen Änderungen auf Server" "PASS" ""
else
  check "WARNUNG" "Manuelle Änderungen auf Server" "FAIL" "$(echo "$GIT_DIRTY" | wc -l) Dateien"
fi

# -------------------------------------------
# ZUSAMMENFASSUNG
# -------------------------------------------

SUMMARY="\n## Zusammenfassung\n\n"
SUMMARY+="Bestanden: ${PASS}\n"
SUMMARY+="Warnungen: ${WARNING}\n"
SUMMARY+="Kritisch:  ${CRITICAL}\n"

TOTAL_REPORT="${SUMMARY}\n${REPORT}"

# Report speichern
REPORT_FILE="/opt/audit/reports/baseline-$(date +%Y-%m-%d).md"
echo -e "# Security Baseline Check $(date +%Y-%m-%d)\n${TOTAL_REPORT}" > "$REPORT_FILE"

echo -e "$TOTAL_REPORT"

# Alert bei kritischen Findings
if [ "$CRITICAL" -gt 0 ]; then
  echo ""
  echo "!!! ${CRITICAL} KRITISCHE FINDINGS !!!"
  echo -e "$TOTAL_REPORT" | mail -s "KRITISCH: Baseline Check $(date)" ops@example.com
  exit 1
fi

exit 0
```

## Integration with Claude Code (Article 5)

The baseline check script delivers facts. Claude Code interprets them. The weekly audit from [Article 5](/en/magazine/claude-code-security-devops/) uses the baseline report as input:

```bash
# Im Gesamt-Audit-Script (scripts/full-security-audit.sh aus Artikel 5)
# Nach den deterministischen Checks:

# Baseline-Report des heutigen Tages einlesen
BASELINE_REPORT=$(cat /opt/audit/reports/baseline-$(date +%Y-%m-%d).md 2>/dev/null || echo "Kein Baseline-Report vorhanden")

# An Claude Code übergeben
echo "$BASELINE_REPORT" | claude -p \
  "Du erhältst den Baseline-Check-Report unseres self-hosted Stacks.
Die Baseline ist definiert in security-baseline.yml.

Analysiere:
1. Welche KRITISCHEN Findings brauchen sofortige Aufmerksamkeit?
2. Gibt es Muster in den WARNUNGEN die auf systematische Probleme hindeuten?
3. Haben sich Findings gegenüber der Vorwoche verändert? (Vergleiche mit letztem Report)
4. Welche Prioritäten empfiehlst du für diese Woche?

Antworte auf Deutsch. Sei konkret." \
  --allowedTools "Read,Grep,Glob" \
  --output-format text \
  --max-turns 5
```

## Maintaining the Baseline

The `security-baseline.yml` is not a static document. It evolves with the stack.

**When to update:**

```
New table in Supabase               -> check rls.exceptions
New service in Docker stack          -> extend internal_only_ports
New NEXT_PUBLIC env var              -> extend allowed_public
New secret                           -> extend required secrets
New Edge Function                    -> check rules apply automatically
New Trigger.dev task                 -> check rules apply automatically
Hosting provider change              -> update server/provider
```

**Workflow for baseline changes:**

```
1. Change security-baseline.yml in Git
2. PR review (including justification for why the rule changes)
3. Claude Code reviews the baseline diff itself:
   "Is this relaxation of the rules justified?"
4. Merge after approval
5. Next baseline check uses the new rules
```

## Cron Configuration

```bash
# crontab auf dem audit-runner

# Täglicher Baseline-Check (06:00 Uhr)
0 6 * * * /opt/audit/scripts/check-baseline.sh >> /var/log/baseline-check.log 2>&1

# Wöchentlicher Claude Code Audit (Sonntag 07:00 Uhr, nach dem Baseline-Check)
0 7 * * 0 /opt/audit/scripts/full-security-audit.sh >> /var/log/security-audit.log 2>&1
```

## Deployment Checklist

```
Baseline File
  [ ] security-baseline.yml present in the repository
  [ ] All server IPs and hostnames up to date
  [ ] All expected secrets listed (without values)
  [ ] All allowed NEXT_PUBLIC variables listed
  [ ] All service_role-permitted files listed
  [ ] RLS exceptions documented (with justification)
  [ ] Compliance rules (CLOUD Act, data residency) defined

Check Script
  [ ] check-baseline.sh executable on audit-runner
  [ ] SSH key from audit-runner to prod server configured
  [ ] Firewall baseline saved (/opt/baselines/)
  [ ] Daily cron job active
  [ ] Alert delivery configured (email on CRITICAL)

Integration
  [ ] Claude Code installed on audit-runner
  [ ] Weekly audit cron active
  [ ] CLAUDE.md present in the repository (Article 5)
  [ ] .claude/commands/security-review.md present (Article 5)
  [ ] Reports are archived (/opt/audit/reports/)
```

## Conclusion

The security baseline is the connecting element of the entire runbook series. Articles 1-4 define what needs to be securely configured. Article 5 defines how Claude Code checks those rules. Article 6 consolidates everything into a single YAML file that can be read by both scripts and Claude Code.

The daily baseline check delivers facts: passed or failed. The weekly [Claude Code audit](/en/magazine/claude-code-security-devops/) interprets those facts in context. A human decides what gets prioritized. This three-layer model covers both known and unexpected risks without any single layer being solely responsible for security.

Those who pursue this baseline together with a [Cert-Ready-by-Design architecture](/en/magazine/cert-ready-by-design/) build verifiable security instead of retroactive audits.

With this, the **DevOps runbook series is complete**.

<div class="not-prose my-12 border border-gosign-border bg-gosign-light rounded-card p-6 lg:p-8">
<div class="flex items-start gap-4">
<div class="flex-shrink-0 w-12 h-12 bg-gosign-dark rounded-card flex items-center justify-center">
<svg width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="white" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 15v4a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2v-4"/><polyline points="7 10 12 15 17 10"/><line x1="12" y1="15" x2="12" y2="3"/></svg>
</div>
<div>
<h2 class="text-h3 font-bold text-gosign-dark mb-2" id="series-audit-checklists">Series Audit Checklists</h2>
<p class="text-body text-gosign-text mb-4">Prepared prompts for Claude Code. Each checklist automatically verifies the security points from its respective runbook and reports PASS, WARNING, or CRITICAL.</p>
<div class="flex flex-wrap gap-3">
<a href="/downloads/claude-check-artikel-1-supabase-en.md" download class="inline-flex items-center px-4 py-2 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-sm">Supabase Infrastructure</a>
<a href="/downloads/claude-check-artikel-2-nextjs-en.md" download class="inline-flex items-center px-4 py-2 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-sm">Next.js Security</a>
<a href="/downloads/claude-check-artikel-3-edge-functions-en.md" download class="inline-flex items-center px-4 py-2 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-sm">Edge Functions</a>
<a href="/downloads/claude-check-artikel-4-trigger-dev-en.md" download class="inline-flex items-center px-4 py-2 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-sm">Trigger.dev</a>
</div>
</div>
</div>
</div>

## Series Table of Contents

1. [Supabase Self-Hosting Runbook](/en/magazine/supabase-self-hosting/)
2. [Running Next.js on Supabase Securely](/en/magazine/nextjs-supabase-secure-setup/)
3. [Deploying Supabase Edge Functions Securely](/en/magazine/supabase-edge-functions-secure/)
4. [Running Trigger.dev Background Jobs Securely](/en/magazine/trigger-dev-background-jobs/)
5. [Claude Code as a Security Control in the DevOps Workflow](/en/magazine/claude-code-security-devops/)
6. [Security Baseline for the Full Stack](/en/magazine/security-baseline-stack/) - this article

--- Self-hosted Open-Source AI 2026: Enterprise Stack ---
> Self-hosting open-source LLMs in 2026: Mistral, gpt-oss, DeepSeek, Llama 4. Hardware floor, TCO, EU GPU hosting, decision matrix per workload.

The model market gave EU-Enterprise procurement a choice it never had before. Open-weight models match proprietary models on most enterprise workloads. Three frontier-class open-source models shipped under Apache 2.0 in 2025 alone. EU GPU hosting providers offer H100 capacity at predictable hourly rates from Paris and Frankfurt data centers. The Schrems II ruling combined with the US CLOUD Act made self-hosting the only architecture with zero foreign-provider exposure.

And yet the conversation in procurement still treats "self-hosted open-source AI" as one product. It is not. It is a stack decision with four credible models, three deployment patterns, and a real total-cost-of-ownership math problem. This article is the detailed companion to [When Mistral, When Claude Opus? Decision Routing for Agentic EU-Enterprise 2026](/en/magazine/ai-models-comparison-2026/) - if you have decided to self-host, here is how the model selection actually plays out.

<div class="not-prose my-12 border border-gosign-border bg-gosign-light rounded-card p-6 lg:p-8">
<p class="text-h3 font-bold text-gosign-dark mb-3">At a Glance - Self-hosted Open-Source AI for EU-Enterprise 2026</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Five credible self-hostable models in 2026: Mistral Small 3.2 (Apache 2.0, 24B, single consumer GPU), gpt-oss-120b (Apache 2.0, MoE, single H100), DeepSeek V4-Flash (MIT, 284B/13B active MoE, April 2026 preview), DeepSeek V4-Pro (MIT, 1.6T/49B active, preview, cluster-grade), Llama 4 Scout (Meta License, 10M context).</li>
<li>Mistral Small 3.2 wins the workhorse slot because it runs on consumer hardware (single RTX 4090), ships with multilingual training, and has native vision capability for document workloads.</li>
<li>DeepSeek V4-Pro (preview, April 24, 2026) approaches frontier closed-source performance under MIT license but needs multi-GPU cluster - realistic self-hosting starts with V4-Flash for most enterprises.</li>
<li>EU GPU hosting is no longer the bottleneck: Scaleway offers H100 SXM at ~3.50 EUR/h, OVHcloud has a sovereign tier, Hetzner provides dedicated RTX servers, IONOS and T-Systems serve regulated industries.</li>
<li>TCO crossover from cloud API to self-hosted: typically around 50-100 million tokens per month sustained. Below that, EU-Cloud-API beats self-hosted. Above that, dedicated hardware amortizes within 12-18 months.</li>
<li>The architecture is multi-model, not single-model: Mistral Small for volume, gpt-oss-120b or DeepSeek V4-Flash for on-prem heavy reasoning, V4-Pro or R1 for math/logic specialists, Llama 4 Scout for ultra-long context. Routing decides which model handles which decision.</li>
</ul>
</div>

## You decided to self-host - the model question begins here

The choice to self-host an LLM stack is rarely a model decision. It is a compliance decision: data classified above a certain threshold cannot leave the company network. It is an architecture decision: the inference layer must be a controlled dependency, not an external API. It is a procurement decision: capital expenditure on hardware vs. operating expenditure on hosted GPU instances.

Once that decision is made, the model question opens. Which open-source model on which hardware floor for which workload mix? Five models have credible Q2 2026 production-readiness: Mistral Small 3.2, gpt-oss-120b, DeepSeek V4-Flash, DeepSeek V4-Pro (preview), and Llama 4 Scout. DeepSeek R1 from January 2025 is still production-ready but largely superseded by the V4 line for new deployments. Each model has a different cost-quality curve and a different operational profile.

This article skips the leaderboard discussion. Benchmark scores converge enough that workload fit matters more than nominal points on MMLU or HumanEval. The question is which model survives 18 months in your stack, which one earns its hardware, and which combination produces the audit trail that the EU AI Act requires.

## The credible self-hosted models, side by side

| Model | Parameters | License | Hardware (CAPEX one-time / OPEX hosted) | Key strength | Key weakness |
|---|---|---|---|---|---|
| Mistral Small 3.2 | 24B dense, GQA (32Q/8KV) | Apache 2.0 | ~55 GB VRAM. **CAPEX:** 1× RTX 4090 ~1,500 EUR (pilot, 4-bit quant) or 1× H100 80GB ~30,000 EUR (production). **OPEX:** ~1,500-2,500 EUR/month on Scaleway/OVHcloud | Multilingual, vision, fast (~150 tok/s consumer GPU), volume-friendly | Not top-tier reasoning |
| gpt-oss-120b | 117B total / 5.1B active (MoE) | Apache 2.0 | 1× H100/A100 80GB. **CAPEX:** ~30,000 EUR. **OPEX:** ~1,200-2,500 EUR/month hosted | Reasoning at o4-mini level, MoE-efficient inference | No vision, datacenter-grade hardware only |
| DeepSeek V4-Flash *(preview, Apr 2026)* | 284B total / 13B active (MoE), 1M context | MIT | 1-2× H100/A100 80GB with quant, 4× H100 full precision. **CAPEX:** ~30,000-120,000 EUR. **OPEX:** ~1,500-5,000 EUR/month hosted | Frontier-class reasoning at moderate hardware cost, native multimodal, agent-optimized | Preview status - benchmarks should be re-verified before production |
| DeepSeek V4-Pro *(preview, Apr 2026)* | 1.6T total / 49B active (MoE), 1M context | MIT (open-source on Hugging Face) | 8× H100 minimum cluster. **CAPEX:** ~240,000 EUR. **OPEX:** ~10,000-12,000 EUR/month hosted. **For DAX-Konzern and upper Mittelstand: feasible. For KMU under 500 employees: API/hosted variant (Together.ai, Fireworks, DeepSeek API) more realistic** | Approaches GPT-5.5 and Gemini 3.1 Pro performance under open license, agent-tool optimized (Claude Code, OpenClaw) | Preview status; for KMU, hardware floor pushes to API path |
| DeepSeek R1 *(Jan 2025, mature)* | 671B total / 37B active (MoE) | MIT | 4-8× H100 minimum. **CAPEX:** ~120,000-240,000 EUR. **OPEX:** ~5,000-10,000 EUR/month hosted | Mature math/logic specialist, broad framework support | Largely superseded by V4-Flash for new deployments |
| Llama 4 Scout | 17B active (MoE) | Meta Llama Community License | 1× GPU. **CAPEX:** ~30,000 EUR. **OPEX:** ~1,500 EUR/month hosted | 10 million token context window | License restriction at >700M MAU; license review needed |

Three clarifications matter here.

**Mistral Small 3.2 hardware floor.** The official Mistral guidance lists ~55 GB GPU RAM for bf16/fp16 inference, which puts it on an H100 or A100 80GB in production. With 4-bit quantization (GPTQ, AWQ), it runs on a single 24 GB RTX 4090 at slight quality cost. For pilot deployments or single-tenant inference, the RTX 4090 path is real. For multi-tenant production with concurrent requests, the H100 path is the correct sizing.

**DeepSeek V4 preview status.** DeepSeek-V4-Pro and V4-Flash launched as preview on April 24, 2026 under MIT license, both with a 1M token context window via the new Hybrid Attention architecture (Compressed Sparse Attention + Heavily Compressed Attention). In the 1M-token context setting, V4-Pro reportedly requires only 27% of single-token inference FLOPs and 10% of the KV cache compared with V3.2 - significant efficiency gains for long-context workloads. Both variants are optimized for agent tooling (Claude Code, OpenClaw integration). However: preview means benchmark claims are not independently verified at scale yet. For production decisions in regulated industries, wait for the general-availability release or run your own representative benchmarks before committing.

**License review for Llama 4 Scout.** The Meta Llama Community License permits commercial use but contains two restrictions enterprise procurement should review: a 700-million-MAU threshold above which a separate Meta license is required, and a restriction on using model outputs to train competing models. For most enterprises both are irrelevant in practice, but the procurement note should be made explicit.

## TCO: when does self-hosted beat cloud API?

The economics flip at a token volume threshold. Below it, hosted APIs win because hardware idle time dominates. Above it, dedicated GPUs win because incremental token cost approaches the cost of electricity plus depreciation.

A representative calculation for Mistral Small 3.2 in EU hosting:

| Cost element | Value (EU hosting) |
|---|---|
| H100 80GB instance, EU provider (Scaleway-class) | ~2,500 EUR/month dedicated, or ~3.50 EUR/h on-demand |
| Mistral Small 3.2 throughput (single H100) | ~150 tokens/sec sustained, ~390M tokens/month at 100% utilization |
| Effective cost per 1M tokens at 60% utilization | ~10-12 EUR per 1M tokens |
| Mistral La Plateforme API equivalent (Mistral Small via API) | ~0.40 USD per 1M input tokens; volume-dependent |
| Claude Sonnet 4.6 API equivalent | ~3 USD per 1M input tokens; ~15 USD output |
| Claude Opus 4.7 API equivalent | ~5 USD per 1M input tokens; ~25 USD output |

The crossover for Mistral Small lands between 50 and 100 million tokens per month sustained, depending on whether the workload is input-heavy or output-heavy. A 24/7 enterprise pipeline running 5 to 10 worker nodes typically crosses that threshold within the first quarter.

For gpt-oss-120b the math is similar but starts higher: a single H100 supports lower throughput than Mistral Small at the same hardware cost, so the per-token amortization is roughly 2× Mistral Small. The crossover vs. Claude Opus 4.7 sits around 30-50 million tokens per month - which is exactly the range where heavy-reasoning workloads land in enterprise AI systems.

A clarification on DeepSeek V4-Pro: the weights are open-source under MIT license and available on Hugging Face - the model is fully self-hostable. The question is enterprise size, not legality. V4-Pro's 1.6T/49B-active architecture requires an 8× H100 cluster (~240,000 EUR CAPEX or ~10,000-12,000 EUR/month hosted). **For DAX-Konzerne and upper Mittelstand (typical 2,500+ employees with established AI infrastructure budgets) those numbers fit a standard IT capex line item.** For KMU under 500 employees, the same numbers push the realistic path to API access (DeepSeek API directly) or a hosted variant (Together.ai, Fireworks) at per-token economics. V4-Flash (284B/13B active) sits in between: 1-4× H100 footprint (30,000-120,000 EUR CAPEX), realistic for upper Mittelstand from day one. Self-hosted TCO for V4-Flash is justified when frontier-class reasoning is a sustained workload at sovereignty-critical data classifications; for occasional reasoning, the V4-Flash API or Mistral La Plateforme is cheaper.

These numbers are based on public EU hosting pricing from Scaleway and OVHcloud and on public model throughput data. They are illustrative, not contractual.

<figure class="not-prose my-12">
<svg viewBox="0 0 800 480" xmlns="http://www.w3.org/2000/svg" role="img" aria-labelledby="tco-title tco-desc" class="w-full h-auto max-w-3xl mx-auto">
<title id="tco-title">TCO crossover: self-hosted vs cloud API by monthly token volume (May 2026)</title>
<desc id="tco-desc">Cost comparison chart showing monthly USD spend on the Y-axis (log scale 100 to 100,000 USD) against monthly token volume on the X-axis (log scale 1M to 10B tokens per month). Four cost curves are plotted: Claude Opus 4.7 API at 15 USD per 1M tokens (linear), Mistral La Plateforme API at 0.40 USD per 1M tokens (linear), Mistral Small 3.2 self-hosted on a single H100 at ~2,500 EUR/month flat plus marginal electricity, and gpt-oss-120b self-hosted on a single H100 at ~3,000 EUR/month flat. Crossover points: Mistral Small 3.2 self-hosted beats Claude Opus 4.7 API at around 200 million tokens per month. gpt-oss-120b self-hosted beats Claude Opus 4.7 API at around 250 million tokens per month. Below 50 million tokens per month, cloud API economics dominate. Above 500 million tokens per month, self-hosted dominates regardless of model choice.</desc>
<defs>
<style>
.axis-line { stroke: #1a2e4d; stroke-width: 1.5; }
.grid-line { stroke: #d4d0cb; stroke-width: 0.5; stroke-dasharray: 2 3; }
.axis-label { font-family: -apple-system, system-ui, sans-serif; font-size: 11px; fill: #4a5568; }
.title-text { font-family: -apple-system, system-ui, sans-serif; font-size: 13px; fill: #1a2e4d; font-weight: 700; }
.legend-text { font-family: -apple-system, system-ui, sans-serif; font-size: 11px; fill: #1a2e4d; font-weight: 500; }
.annotation { font-family: -apple-system, system-ui, sans-serif; font-size: 10px; fill: #1a2e4d; font-style: italic; }
.crossover-marker { fill: #fcd34d; stroke: #b8941f; stroke-width: 1.5; }
</style>
</defs>
<text x="400" y="25" class="title-text" text-anchor="middle">Monthly cost (USD, log scale)</text>
<line x1="80" y1="380" x2="740" y2="380" class="grid-line"/>
<line x1="80" y1="300" x2="740" y2="300" class="grid-line"/>
<line x1="80" y1="220" x2="740" y2="220" class="grid-line"/>
<line x1="80" y1="140" x2="740" y2="140" class="grid-line"/>
<line x1="80" y1="60" x2="740" y2="60" class="grid-line"/>
<line x1="212" y1="60" x2="212" y2="380" class="grid-line"/>
<line x1="344" y1="60" x2="344" y2="380" class="grid-line"/>
<line x1="476" y1="60" x2="476" y2="380" class="grid-line"/>
<line x1="608" y1="60" x2="608" y2="380" class="grid-line"/>
<text x="72" y="384" class="axis-label" text-anchor="end">$100</text>
<text x="72" y="304" class="axis-label" text-anchor="end">$1,000</text>
<text x="72" y="224" class="axis-label" text-anchor="end">$10,000</text>
<text x="72" y="144" class="axis-label" text-anchor="end">$100,000</text>
<text x="72" y="64" class="axis-label" text-anchor="end">$1,000,000</text>
<text x="80" y="400" class="axis-label" text-anchor="middle">1M</text>
<text x="212" y="400" class="axis-label" text-anchor="middle">10M</text>
<text x="344" y="400" class="axis-label" text-anchor="middle">100M</text>
<text x="476" y="400" class="axis-label" text-anchor="middle">1B</text>
<text x="608" y="400" class="axis-label" text-anchor="middle">10B</text>
<text x="400" y="420" class="title-text" text-anchor="middle">Monthly token volume (log scale)</text>
<line x1="80" y1="60" x2="80" y2="380" class="axis-line"/>
<line x1="80" y1="380" x2="740" y2="380" class="axis-line"/>
<polyline points="80,420 212,366 344,286 476,206 608,126" fill="none" stroke="#b8941f" stroke-width="2.5"/>
<text x="615" y="120" class="legend-text" fill="#b8941f">Claude Opus 4.7 API</text>
<text x="615" y="132" class="annotation" fill="#b8941f">$15 per 1M tokens</text>
<polyline points="80,572 212,508 344,412 476,332 608,252" fill="none" stroke="#3a6090" stroke-width="2.5" stroke-dasharray="4 3"/>
<text x="615" y="246" class="legend-text" fill="#3a6090">Mistral La Plateforme API</text>
<text x="615" y="258" class="annotation" fill="#3a6090">$0.40 per 1M tokens</text>
<polyline points="80,266 740,266" fill="none" stroke="#1a2e4d" stroke-width="2.5"/>
<text x="86" y="258" class="legend-text" fill="#1a2e4d">Mistral Small 3.2 self-host (~$2,700/mo flat)</text>
<polyline points="80,256 740,256" fill="none" stroke="#5a8a5a" stroke-width="2.5" stroke-dasharray="6 4"/>
<text x="86" y="248" class="legend-text" fill="#5a8a5a">gpt-oss-120b self-host (~$3,200/mo flat)</text>
<circle cx="377" cy="266" r="6" class="crossover-marker"/>
<text x="377" y="248" class="annotation" text-anchor="middle">crossover ~180M tok/mo</text>
<text x="377" y="284" class="annotation" text-anchor="middle">Mistral OSS vs Opus API</text>
<rect x="80" y="60" width="660" height="320" fill="none" stroke="none"/>
<text x="400" y="455" class="annotation" text-anchor="middle">Hosting: EU GPU providers (Scaleway, OVHcloud) - figures illustrative, not contractual</text>
</svg>
<figcaption class="text-sm text-gosign-text-light text-center mt-4 max-w-2xl mx-auto">
<strong>TCO crossover: self-hosted vs cloud API</strong> - linear cloud-API curves (per-token pricing) versus flat self-hosted curves (CAPEX amortized). Mistral La Plateforme API stays cheapest below ~10B tokens/month - the relevant decision is Mistral OSS self-host vs Claude Opus 4.7 API, which crosses around 180 million tokens per month for sovereignty-critical workloads. Below 50M tokens/month, cloud API economics dominate. Above 500M tokens/month, self-host dominates regardless.
</figcaption>
</figure>

## EU GPU hosting in 2026: who actually has H100 capacity?

The EU GPU hosting market matured significantly in 2025-2026. Three providers cover most enterprise self-hosting use cases:

**Scaleway** (France, GDPR-native). The most aggressive on price-performance for AI workloads. H100 SXM at ~3.50 EUR/h, A100 at ~2.50 EUR/h, plus the newer NVIDIA Blackwell B300-SXM (288 GB VRAM) for frontier workloads. French data centers, full GDPR compliance, no CLOUD Act exposure. Reserved-instance contracts available for predictable workloads.

**OVHcloud** (France, sovereign tier). The largest European cloud provider, with a "Sovereign Cloud" tier explicitly built for government and regulated-industry use. Portfolio includes H100, RTX 5000, A10, plus an "AI Deploy" service for pay-as-you-go notebook and inference. Good fit when procurement requires a sovereign-cloud sign-off.

**Hetzner** (Germany). The cost-leader for dedicated GPU servers, not on-demand instances. Current GPU options include RTX 4000 SFF Ada and RTX 6000 Ada paired with modern CPUs. The path for Mistral Small 3.2 with quantization or for development environments. Less suited to peak elastic scaling.

For regulated industries (financial services, healthcare, public sector) with strict sovereignty requirements:

**IONOS** (Germany). Sovereign-cloud-grade hosting with GPU instances. The compliance fit for German BaFin-regulated workloads.

**T-Systems** (Germany). Deutsche Telekom subsidiary. Sovereign cloud explicitly designed for public-sector and critical-infrastructure customers. The procurement-comfortable choice when board-level sovereignty is the requirement.

For an enterprise deciding on a self-hosted stack, the practical sequence is: pilot on Scaleway or Hetzner for cost-efficient validation, move to OVHcloud or T-Systems for production if regulatory sign-off requires sovereign-cloud certification, retain reserved-instance contracts to control cost predictability.

## Deployment patterns: single worker, cluster, hybrid

Three deployment patterns cover almost all enterprise self-hosted scenarios.

**Single-worker pattern.** One model, one GPU instance, deployed behind a load balancer with health checks. Suitable for: Mistral Small 3.2 on an RTX 4090 or H100 for the 70% volume workload. Llama 4 Scout on a single GPU for long-context document analysis. Operational complexity: low. Failure mode: single point of failure unless replicated.

**Multi-model cluster pattern.** Multiple models on multiple GPUs behind a routing layer. Suitable for: Mistral Small for volume + gpt-oss-120b or DeepSeek V4-Flash for heavy reasoning + (optional) DeepSeek V4-Pro on dedicated cluster for math-grade workloads, all behind a single routing layer. The routing layer decides per request which model handles it. Operational complexity: medium. Requires a model server (vLLM, TGI, llama.cpp-server) and a routing rules engine. This is the typical production pattern for agentic workloads with mixed decision complexity.

**Hybrid edge-cloud pattern.** Sensitive workloads (HR onboarding, contract review, customer data extraction) on self-hosted models; non-sensitive workloads (marketing copy generation, knowledge base Q&A on public information) on EU-cloud APIs like Mistral La Plateforme. The routing layer enforces the data classification before model selection. Operational complexity: high (two stacks to maintain) but the lowest sovereignty exposure and the best cost-per-decision ratio.

The pattern choice depends on the data classification taxonomy, not the model selection. If everything is classified as "internal" or higher, the multi-model cluster pattern dominates. If a meaningful percentage of work is on public-facing or non-sensitive data, the hybrid pattern is cheaper.

## Decision matrix: which model for which workload

| Workload category | Recommended model | Why |
|---|---|---|
| Document classification, structured extraction, OCR field parsing | Mistral Small 3.2 (self-hosted) | Vision-capable, fast on consumer GPU, multilingual coverage |
| High-volume text generation (emails, notifications, templates) | Mistral Small 3.2 (self-hosted) | Throughput, template-friendly, lowest cost per token |
| Contract clause classification, vendor risk flags, anomaly detection | Mistral Small 3.2 or Mistral Medium 3.1 (La Plateforme) | Medium reasoning at moderate cost, EU-sovereign |
| Anti-discrimination analysis under AGG/Equality Act, cross-statute compliance reasoning | gpt-oss-120b (on-prem) or Claude Opus 4.7 (cloud) | Tier-1 reasoning, audit-grade output for HR/Legal use cases |
| Code generation, code review (cloud flagships) | Claude Opus 4.7 or GPT-5.5 | Both benchmark-leading; Claude Opus 4.7 ahead on long agentic loops (Claude Code), GPT-5.5 ahead in IDE integrations (Cursor, Copilot) |
| Code generation (self-hosted, sovereignty-critical) | Qwen 3 Coder 110B (Apache 2.0, Alibaba), DeepSeek Coder V4 (MIT), or Codestral Mamba 32B (Mistral, EU-built) | Tier-1 coding benchmarks on-prem; Qwen 3 Coder leads HumanEval/SWE-Bench among OSS, DeepSeek Coder V4 strongest on agentic multi-file tasks, Codestral Mamba lowest latency on consumer GPU |
| Microsoft 365 / Copilot deep integration | GPT-5.5 via Azure OpenAI | Native stack, lowest integration effort for organisations on Microsoft data plane |
| Agentic workflows with heavy function-calling / tool-use | GPT-5.5 or Claude Opus 4.7 | Both top-tier for structured outputs and tool orchestration; GPT-5.5 has broader ecosystem of pre-built tools |
| Financial risk modeling, stress testing, optimization | DeepSeek V4-Flash (current) or V4-Pro via API; R1 still production-ready | Top-tier math/logic; V4 line adds 1M context for cross-portfolio analysis |
| Document analysis of large corpora (entire contract portfolios, annual reports) | Llama 4 Scout | 10M token context window - unique in this band |
| Multimodal (image + text correlation, technical drawings, video segments) | Gemini 3.1 Pro (cloud, no self-hosted equivalent) | Native multimodal training, 1M context |
| Conversational AI / customer-facing chatbots | Mistral Small 3.2 (self-hosted) for volume; GPT-5.5 (Azure) when MS-stack-native | Production-grade quality at lowest hardware cost; GPT-5.5 if integrated into Dynamics/Copilot |
| SaaS feature gating (per-customer model tiers, per-region routing) | Hybrid pattern: Mistral Small + Claude Opus 4.7 / GPT-5.5 | Sensitive customer data on self-hosted, premium features on cloud flagship |

The matrix is not a prescription. It is a starting point that gets refined per organization. A finance-heavy enterprise weights DeepSeek V4 higher. A multimedia-heavy operation may need a cloud Gemini hop. A high-document-volume HR pipeline puts Mistral Small at 80% of decisions, not 70%.

The routing layer makes the matrix operational. Without it, every workload runs against whatever model is configured as the default, and the matrix becomes a slideware artifact.

## Building the routing layer: where Decision Layer fits

Self-hosted multi-model architectures break down without a routing layer for a simple reason: no human operator wants to remember 14 decision-to-model mappings while also writing the agent's business logic. The routing has to be configuration, not code.

A Decision Layer holds:

- The data classification taxonomy (which data types require self-hosted? Which can route to EU-cloud-API? Which can route to US-cloud-API?)
- The decision-to-model routing rules per workflow step
- The fallback chain (if Mistral Small fails or saturates, route to which alternative?)
- The audit log: every decision recorded with input snapshot, rule version, model used, confidence score, reasoning chain, outcome, and human approver where applicable
- The Challenge button: any affected subject can contest an automated decision, triggering re-decision under human review - the mechanism required by GDPR Art. 22

This is the artifact that an EU AI Act Article 13 auditor inspects. It is the artifact that a Betriebsrat reviews when classifying which agents fall under BetrVG §87 Absatz 1 Nummer 6 co-determination scope. It is the artifact that satisfies the procurement question "what happens when your AI vendor changes a model?" - because the routing rule changes, not the business logic.

Building this layer in-house is doable but rarely faster than 6-9 months for an enterprise team starting from scratch. Buying it as a configuration framework typically shortens the path to 4-6 weeks for the first production agent.

## Bottom line

Self-hosted open-source AI is a credible production choice for EU-Enterprise in 2026 - but only as a multi-model architecture with a routing layer, not as a single-model bet. Mistral Small 3.2 covers the volume band. gpt-oss-120b or DeepSeek V4-Flash covers heavy reasoning on-prem. DeepSeek V4-Pro (currently in preview) approaches Claude Opus territory if you have hyperscaler-class hardware - or you wait for the GA release and use it via API in the meantime. Llama 4 Scout covers ultra-long context. The cloud-API tier (Claude Opus 4.7, GPT-5.5, Gemini 3.1 Pro) stays available for the workloads where the regulatory framework permits it.

The routing decision is the architecture. The TCO crossover (around 50-100 million tokens per month sustained) sets the economic threshold for self-hosting. The compliance taxonomy (which data classification cannot leave the network) sets the sovereignty threshold. Both thresholds shape the routing rules.

Others publish hardware buying guides. We size the GPU footprint against your actual decision-complexity mix and the TCO crossover that matters for your token volume. The model market reprices itself every quarter; an H100 cluster that pays back in 14 months under DeepSeek V4-Flash today is the same cluster that runs whichever open-weight model wins the next benchmark generation. Hardware investment outlives any single model release. The routing rules absorb the model churn so the CAPEX line item stays defensible across three procurement cycles.

If you want to know what your self-hosted stack should look like based on your actual workload mix and data classification, [book a consultation](/en/contact/).

---

**📘 Enterprise AI Infrastructure Blueprint 2026 - Article Series**

| ← Previous | Overview | Next → |
|:---|:---:|---:|
| [When Mistral, When Claude Opus? Decision Routing for Agentic EU-Enterprise 2026](/en/magazine/ai-models-comparison-2026/) | [Enterprise AI Infrastructure Blueprint 2026](/en/magazine/ai-infrastructure-blueprint-2026/) | [AI Hosting: EU SaaS, German Data Center, or Self-Hosted?](/en/magazine/ai-hosting-strategies-enterprise/) |

*All articles in this series: [Enterprise AI Infrastructure Blueprint 2026](/en/magazine/ai-infrastructure-blueprint-2026/)*

---

## Sources

Primary sources used in this article:

- **Mistral Small 3.2 release and specifications** - 24B dense, Apache 2.0, ~55 GB GPU RAM in bf16/fp16, June 2025 release. [Mistral AI announcement](https://mistral.ai/news/mistral-small-3-1) (3.1 baseline) | [VentureBeat coverage 3.1 to 3.2](https://venturebeat.com/ai/mistral-just-updated-its-open-source-small-model-from-3-1-to-3-2-heres-why) | [Hugging Face model page](https://huggingface.co/mistralai/Mistral-Small-3.1-24B-Instruct-2503) | [Spec comparison](https://chatforest.com/reviews/mistral-small-3-2-24b-instruct-refinement-llm-review/)
- **gpt-oss-120b release** - 117B parameters total, 5.1B active per token (MoE), Apache 2.0, August 5, 2025 release, single 80 GB GPU. [OpenAI announcement](https://openai.com/index/introducing-gpt-oss/) | [GitHub repository](https://github.com/openai/gpt-oss) | [Model card PDF](https://cdn.openai.com/pdf/419b6906-9da6-406c-a19d-1bb078ac7637/oai_gpt-oss_model_card.pdf)
- **DeepSeek V4-Pro and V4-Flash** - Preview released April 24, 2026. V4-Pro: 1.6T total / 49B active MoE; V4-Flash: 284B / 13B active. MIT license. 1M token context via Hybrid Attention (Compressed Sparse Attention + Heavily Compressed Attention). [DeepSeek API Docs - V4 Preview](https://api-docs.deepseek.com/news/news260424) | [Hugging Face V4-Pro](https://huggingface.co/deepseek-ai/DeepSeek-V4-Pro) | [Hugging Face V4-Flash](https://huggingface.co/deepseek-ai/DeepSeek-V4-Flash) | [Simon Willison analysis](https://simonwillison.net/2026/Apr/24/deepseek-v4/)
- **DeepSeek R1** *(prior generation, Jan 2025)* - MIT license, mature math/logic specialist, 671B total / 37B active MoE. [Hugging Face model page](https://huggingface.co/deepseek-ai/DeepSeek-R1)
- **Llama 4 Scout** - 17B active MoE, 10M token context, Meta Llama Community License. [Meta AI announcement](https://ai.meta.com/blog/llama-4-multimodal-intelligence/)
- **Claude Opus 4.7** - Released April 16, 2026, $5/$25 per million tokens, available on Anthropic API, Amazon Bedrock, Google Vertex AI, Microsoft Foundry. [Anthropic announcement](https://www.anthropic.com/news/claude-opus-4-7)
- **GPT-5.5** - Released April 23-24, 2026, latest GPT-5 series model. [OpenAI announcement](https://openai.com/index/introducing-gpt-5-5/)
- **Gemini 3.1 Pro** - Released February 19, 2026, current Gemini flagship. [Google AI for Developers](https://ai.google.dev/gemini-api/docs/models) | [Vertex AI documentation](https://docs.cloud.google.com/vertex-ai/generative-ai/docs/learn/model-versions)
- **EU GPU hosting providers** - Scaleway H100 SXM ~3.50 EUR/h, A100 ~2.50 EUR/h with full GDPR compliance. OVHcloud sovereign tier. Hetzner dedicated RTX servers. [Cloud GPU Tracker Europe](https://cloudgputracker.com/cloud-gpu-europe/) | [Scaleway H100 page](https://www.scaleway.com/en/h100/) | [OVHcloud H100 page](https://www.ovhcloud.com/en/public-cloud/gpu/h100/)
- **EU AI Act Article 13** - Transparency obligations for high-risk AI systems. Regulation (EU) 2024/1689. [artificialintelligenceact.eu/article/13](https://artificialintelligenceact.eu/article/13/) | [EU AI Act Service Desk](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-13)
- **US CLOUD Act vs EU sovereignty** - CLOUD Act follows provider control not data location, EU Tech Sovereignty Package expected Q2 2026. [Kiteworks analysis](https://www.kiteworks.com/cybersecurity-risk-management/eu-tech-sovereignty-package-cloud-act/)

---

[Book a consultation](/en/contact/). We analyze your workload mix, your data classification, and your sovereignty requirements - and recommend the multi-model self-hosted stack that matches.

--- Shadow AI in the Enterprise - Governance Not Bans ---
> Uncontrolled AI usage (Shadow AI) is a governance problem. The solution is controlled infrastructure with Audit Trail and Model Routing.

## What Is Shadow AI?

Shadow AI is the AI equivalent of Shadow IT. Employees use ChatGPT, Google Gemini, Microsoft Copilot, or other AI tools for their work, without the knowledge, approval, or oversight of the IT department.

The clerk who enters a customer complaint into ChatGPT to draft a response. The HR specialist who writes a reference letter using Copilot. The controller who analyzes quarterly figures in Gemini. Each of these uses sends company data to an external service.

Shadow AI is not malicious. Employees use AI tools because they become more productive. But without [governance](/en/governance/), the organization has no control over which data leaves the company, which models are used, and whether the results are traceable.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">At a Glance - Shadow AI Governance</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Shadow AI means employees use external AI tools without IT knowledge, sending company data to uncontrolled systems.</li>
<li>Bans do not work - employees use personal devices and alternative tools. Prohibition creates uncontrolled circumvention.</li>
<li>PwC (2024) found that 54% of companies have employees using generative AI tools without formal organizational approval.</li>
<li>The solution is controlled infrastructure: company-owned AI interface, Model Routing, usage logging and Audit Trail.</li>
<li>Three phases: assessment of current usage, controlled infrastructure rollout, then specialized agents for frequent use cases.</li>
</ul>
</div>

## Why Bans Do Not Work

The obvious response to Shadow AI is a ban. Many companies have blocked ChatGPT and similar tools, via firewall rules, policies, or works council agreements.

The problem: Bans do not work. Employees use their personal smartphones. They use browser extensions. They use alternative tools that are not yet on the blocklist. The ban does not create compliance, it creates uncontrolled circumvention.

At the same time, the company loses the productivity advantage that AI can offer. While employees hide their AI usage, IT can neither support, nor steer, nor optimize it.

## The Alternative: Controlled AI Infrastructure

The solution is not prohibition but infrastructure. A company-owned AI infrastructure gives employees powerful AI tools, under the organization's control.

**Company-owned AI interface:** Instead of ChatGPT, employees use an internal chat interface that accesses company-owned models. The user experience is identical. The difference: All data stays in the company's own infrastructure.

**Model Routing:** IT decides which models are used for which use cases. Sensitive data goes to self-hosted models. Non-critical requests can be routed to cloud models. The decision is rule-based and traceable.

**Usage logging:** Every AI interaction is logged, not to monitor employees, but to steer AI usage. Which departments use AI the most? For which tasks? With which models? This data forms the foundation for the next step: specialized agents for the most common use cases.

**Audit Trail:** In regulated areas, including finance, HR, and compliance, every AI-assisted decision is documented in the Audit Trail. The Decision Layer ensures that business-critical processes are not based on uncontrolled AI outputs.

## From Shadow AI to Governance by Design

Shadow AI is a symptom. The root cause is missing infrastructure. When employees have no controlled AI tools, they use uncontrolled ones.

| Phase | Focus | Key Deliverables |
|-------|-------|-----------------|
| 1 - Assessment | Map current AI usage across departments | Tool inventory, data flow analysis, risk classification |
| 2 - Controlled infrastructure | Company-owned AI platform with governance | LLM hosting, chat interface, Model Routing, usage logging |
| 3 - Specialized agents | Purpose-built agents for frequent use cases | Document Agent, Knowledge Agent, Workflow Agent - each with Decision Layer |

The path from Shadow AI to Governance by Design:

**Phase 1: Assessment.** Which AI tools are being used in the company? For which tasks? With which data? This assessment is often sobering, as actual AI usage significantly exceeds official usage.

**Phase 2: Controlled infrastructure.** Build a company-owned AI infrastructure. LLM hosting, chat interface, Model Routing, usage logging. Employees get a tool that is at least as capable as ChatGPT, but under IT's control.

**Phase 3: Specialized agents.** The most common use cases become specialized agents. Instead of a generic chat, there is a Document Agent for document processing, a Knowledge Agent for HR questions, a Workflow Agent for invoice processing. Each agent with a Decision Layer and governance.

## The Risk of Inaction

Shadow AI will not disappear. AI tools are getting better, more accessible, more deeply integrated into existing software. Every Office update brings new AI features. Every browser has AI capabilities.

Companies that do not build controlled AI infrastructure will find that their employees have long been using AI, without governance, without an Audit Trail, without GDPR compliance. The question is not whether it becomes a problem, but when. At the next tax audit. At the next GDPR request. At the next data breach.

More on this: [AI Infrastructure](/en/services/infrastructure/)

<a href="/en/contact/" target="_blank" rel="noopener noreferrer">Book a consultation</a> - We will show you how to transition Shadow AI into controlled AI infrastructure.

--- Deploying Supabase Edge Functions Securely ---
> DevOps runbook for Supabase Edge Functions: webhooks, signatures, CORS, Deno runtime, input validation, and Claude Code integration.

Supabase Edge Functions are server-side TypeScript functions that run on the Deno runtime and are accessible through the Kong API Gateway.

They are particularly well suited for webhooks, integrations with external APIs, signed event endpoints, and lightweight server-side logic.

The most common mistake is using Edge Functions as a **second backend system**. This leads to duplicated business logic, unclear security boundaries, and architectures that are difficult to debug.

This runbook describes how to deploy Edge Functions securely in a [self-hosted setup](/en/magazine/supabase-self-hosting/). Every step contains a concrete implementation with real Deno code, a verifiable condition, and a failure scenario.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">At a Glance - Part 3 of 6 in the DevOps Runbook Series</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Edge Functions serve as integration points only (webhooks, events), not as a second backend</li>
<li>Every webhook endpoint must verify the sender's signature</li>
<li>CORS explicitly configured (no wildcard in production)</li>
<li>Input validation with Zod on every incoming payload</li>
<li>Long-running tasks delegated to Trigger.dev instead of blocking Edge Functions</li>
</ul>
</div>

> **Note on the runtime:** Supabase Edge Functions are based on **Deno**, not Node.js. This affects import syntax, the module system, and available APIs. All code examples in this article are Deno-compatible. Self-hosted Edge Functions run in the `supabase/edge-runtime` container and are currently still marked as beta.

## Series Table of Contents

This guide is part of our DevOps runbook series for self-hosted app stacks.

1. [Supabase Self-Hosting Runbook](/en/magazine/supabase-self-hosting/)
2. [Running Next.js on Supabase Securely](/en/magazine/nextjs-supabase-secure-setup/)
3. Deploying Supabase Edge Functions Securely - this article
4. [Running Trigger.dev Background Jobs Securely](/en/magazine/trigger-dev-background-jobs/)
5. [Claude Code as Security Control in DevOps Workflows](/en/magazine/claude-code-security-devops/)
6. [Security Baseline for the Entire Stack](/en/magazine/security-baseline-stack/)

Article 1 covers the platform.
Article 2 covers the Next.js app layer.
This article covers **integrations and webhooks**.

## Architecture Overview

```
Browser
   |
Next.js (App Layer)
   |
   +-- Supabase Client (anon key)     -> for user requests
   |
Kong API Gateway
   |
   +-- PostgREST                       -> REST API with RLS
   +-- GoTrue                          -> Auth
   +-- Edge Runtime                    -> Edge Functions
   |     |
   |     +-- stripe-webhook
   |     +-- github-webhook
   |     +-- trigger-webhook
   |
PostgreSQL + RLS Policies

External Services
   |
   +-- Stripe / GitHub / Trigger.dev   -> call webhooks
```

Ground rule:

```
Edge Functions are integration points for external events.
Business logic belongs in Next.js (Server Actions / Route Handlers).
Long-running tasks belong in Trigger.dev.
```

### Decision Criteria

If a function reacts to an **external event** (Stripe payment, GitHub push, Trigger.dev callback), it is an Edge Function. If it reacts to **user input** and transforms data, it belongs in Next.js. If it **runs longer than 30 seconds**, it belongs in Trigger.dev.

More than 40% of all webhook security incidents result from missing signature verification (GitGuardian State of Secrets Sprawl 2024).

### Decision Table: Where Does Logic Belong?

| Criterion | Edge Function | Next.js Server Action | Trigger.dev Task |
|-----------|-------------|---------------------|-----------------|
| Trigger | External event (webhook) | User input (browser) | Programmatic / cron |
| Runtime | Under 30 seconds | Under 10 seconds | Up to 5+ minutes |
| User context | No (no JWT) | Yes (session) | No (service_role) |
| RLS active | No (service_role) | Yes (anon key) | No (service_role) |
| Retry logic | None (provider retries) | None | Built-in (configurable) |
| Example | Stripe webhook | Save form data | PDF generation |

## How Edge Functions Run in a Self-Hosted Setup

In a self-hosted Docker Compose stack, the Edge Functions configuration looks like this:

```yaml
# docker-compose.yml (excerpt)
functions:
  container_name: supabase-edge-functions
  image: supabase/edge-runtime:v1.66.4    # Version pinnen
  restart: unless-stopped
  depends_on:
    - analytics
  environment:
    JWT_SECRET: ${JWT_SECRET}
    SUPABASE_URL: http://kong:8000                    # interner Docker-Hostname
    SUPABASE_ANON_KEY: ${ANON_KEY}
    SUPABASE_SERVICE_ROLE_KEY: ${SERVICE_ROLE_KEY}
    SUPABASE_DB_URL: postgresql://postgres:${POSTGRES_PASSWORD}@${POSTGRES_HOST}:${POSTGRES_PORT}/${POSTGRES_DB}
    VERIFY_JWT: "${FUNCTIONS_VERIFY_JWT}"
  volumes:
    - ./volumes/functions:/home/deno/functions:Z
  command:
    - start
    - --main-service
    - /home/deno/functions/main
```

Edge Functions are stored as TypeScript files in the volume:

```
volumes/functions/
  main/
    index.ts              <- Router / Main Service
  _shared/
    cors.ts               <- CORS Headers (shared)
    supabase-client.ts    <- Supabase Client Factory (shared)
  stripe-webhook/
    index.ts
  github-webhook/
    index.ts
```

**Deployment in a self-hosted setup:** Functions are placed as files into the volume, and the container is restarted:

```bash
# Copy functions into the volume
cp -r supabase/functions/* /opt/supabase/volumes/functions/

# Restart the container
docker compose restart functions --no-deps
```

## Part A - Architecture Decisions

These decisions are made once and rarely changed.

## A1 - Edge Functions for Integrations Only, Not as a Second Backend

### Implementation

Clear assignment of which logic belongs where:

```
Edge Functions (Deno):
  Webhook reception (Stripe, GitHub, external APIs)
  Event-based sync (DB webhook -> external service)
  Signature verification of incoming events
  Lightweight transformations (< 30 seconds)

Next.js (Server Actions / Route Handlers):
  User-facing mutations (CRUD)
  Session-based operations
  Business logic
  Input validation with user context

Trigger.dev (Background Jobs):
  PDF generation
  AI tasks
  Bulk email delivery
  Anything running longer than 30 seconds
```

### Verifiable Condition

```bash
# How many Edge Functions exist?
ls -d volumes/functions/*/ | grep -v "main\|_shared" | wc -l

# For each function, check: is it an integration?
for dir in volumes/functions/*/; do
  name=$(basename "$dir")
  [[ "$name" == "main" || "$name" == "_shared" ]] && continue
  echo "--- $name ---"
  # Does it contain webhook/integration patterns?
  grep -l "signature\|webhook\|stripe\|github\|trigger" "$dir"*.ts 2>/dev/null || \
    echo "WARNING: no webhook/integration patterns found"
done
```

### Failure Scenario

If business logic is implemented in Edge Functions, a shadow architecture emerges: the same validation exists in Next.js Server Actions AND in Edge Functions, with subtle differences. Bugs become hard to reproduce because it is unclear which code path was active. Auth logic must be maintained in two places.

## A2 - Isolate Webhook Endpoints: One Function per Webhook

### Implementation

Each webhook provider gets its own function in its own directory:

```
volumes/functions/
  stripe-webhook/
    index.ts
  github-webhook/
    index.ts
  trigger-webhook/
    index.ts
```

**Not like this:**

```
volumes/functions/
  webhooks/
    index.ts     <- handles Stripe, GitHub, and Trigger in a single file
```

### Verifiable Condition

```bash
# Each webhook function should serve exactly one provider
for dir in volumes/functions/*-webhook/; do
  name=$(basename "$dir")
  providers=$(grep -ciE "stripe|github|trigger|slack|sendgrid" "$dir/index.ts")
  if [ "$providers" -gt 1 ]; then
    echo "WARNING: $name serves multiple providers ($providers)"
  fi
done
```

### Failure Scenario

When multiple webhooks are handled in a single function, they share the same error handler. A malformed Stripe payload can block the GitHub webhook. Retry strategies differ per provider (Stripe retries with exponential backoff, GitHub only 3 times), and this is nearly impossible to handle cleanly in a shared function.

## A3 - Configure CORS Correctly

### Implementation

Edge Functions that are called from the browser (even indirectly) need CORS headers. Supabase does not provide automatic CORS configuration for Edge Functions.

Shared CORS config:

```typescript
// volumes/functions/_shared/cors.ts

const allowedOrigins = [
  'https://app.example.com',
  ...(Deno.env.get('ENVIRONMENT') === 'development'
    ? ['http://localhost:3000']
    : [])
]

export function getCorsHeaders(req: Request) {
  const origin = req.headers.get('origin') ?? ''
  const corsOrigin = allowedOrigins.includes(origin) ? origin : ''

  return {
    'Access-Control-Allow-Origin': corsOrigin,
    'Access-Control-Allow-Headers':
      'authorization, x-client-info, apikey, content-type',
    'Access-Control-Allow-Methods': 'POST, GET, OPTIONS',
  }
}
```

**Every Edge Function** must handle CORS at the beginning:

```typescript
import { getCorsHeaders } from '../_shared/cors.ts'

Deno.serve(async (req) => {
  const corsHeaders = getCorsHeaders(req)

  // CORS preflight must be the FIRST check
  if (req.method === 'OPTIONS') {
    return new Response('ok', { headers: corsHeaders })
  }

  // ... actual logic

  return new Response(JSON.stringify(data), {
    headers: { ...corsHeaders, 'Content-Type': 'application/json' },
  })
})
```

### Verifiable Condition

```bash
# All functions must handle CORS
for dir in volumes/functions/*/; do
  name=$(basename "$dir")
  [[ "$name" == "main" || "$name" == "_shared" ]] && continue
  if ! grep -q "OPTIONS" "$dir/index.ts" 2>/dev/null; then
    echo "WARNING: $name has no OPTIONS handler"
  fi
done

# No wildcard CORS in production
grep -r "'\\*'" volumes/functions/ --include="*.ts" | grep -i "allow-origin"
# Expected: no matches (except in development branches)
```

### Failure Scenario

Without CORS headers, all browser requests to Edge Functions fail. The browser blocks the response even if the function responds correctly. This manifests as a cryptic CORS error in the console. With wildcard CORS (`'*'`) in production, any website can send requests to your Edge Functions and read the responses.

## Part B - Implementation Checks

These checks apply to every Edge Function and must be verified with each deployment.

## B1 - Verify Webhook Signatures

### Implementation

Every webhook endpoint must verify the signature of the sending service. Without signature verification, anyone can send arbitrary payloads to the function.

**Complete Stripe webhook example:**

```typescript
// volumes/functions/stripe-webhook/index.ts

import { getCorsHeaders } from '../_shared/cors.ts'

const STRIPE_WEBHOOK_SECRET = Deno.env.get('STRIPE_WEBHOOK_SECRET')

Deno.serve(async (req) => {
  const corsHeaders = getCorsHeaders(req)

  if (req.method === 'OPTIONS') {
    return new Response('ok', { headers: corsHeaders })
  }

  // 1. Only allow POST
  if (req.method !== 'POST') {
    return new Response(
      JSON.stringify({ error: 'Method not allowed' }),
      { status: 405, headers: { ...corsHeaders, 'Content-Type': 'application/json' } }
    )
  }

  // 2. Verify signature
  const signature = req.headers.get('stripe-signature')
  if (!signature) {
    return new Response(
      JSON.stringify({ error: 'Missing signature' }),
      { status: 401, headers: { ...corsHeaders, 'Content-Type': 'application/json' } }
    )
  }

  const body = await req.text()

  const isValid = await verifyStripeSignature(body, signature, STRIPE_WEBHOOK_SECRET!)
  if (!isValid) {
    return new Response(
      JSON.stringify({ error: 'Invalid signature' }),
      { status: 401, headers: { ...corsHeaders, 'Content-Type': 'application/json' } }
    )
  }

  // 3. Process the event
  const event = JSON.parse(body)

  switch (event.type) {
    case 'checkout.session.completed':
      await handleCheckoutCompleted(event.data.object)
      break
    case 'invoice.payment_failed':
      await handlePaymentFailed(event.data.object)
      break
    default:
      // Ignore unknown events, do not fail
      console.log(`Unhandled event type: ${event.type}`)
  }

  // 4. Always return 200 (Stripe retries otherwise)
  return new Response(
    JSON.stringify({ received: true }),
    { status: 200, headers: { ...corsHeaders, 'Content-Type': 'application/json' } }
  )
})

// Stripe signature verification using the Deno Crypto API
async function verifyStripeSignature(
  payload: string,
  header: string,
  secret: string
): Promise<boolean> {
  const parts = header.split(',')
  const timestamp = parts.find(p => p.startsWith('t='))?.split('=')[1]
  const signature = parts.find(p => p.startsWith('v1='))?.split('=')[1]

  if (!timestamp || !signature) return false

  // Timing check: reject events older than 5 minutes
  const now = Math.floor(Date.now() / 1000)
  if (now - parseInt(timestamp) > 300) return false

  const signedPayload = `${timestamp}.${payload}`
  const key = await crypto.subtle.importKey(
    'raw',
    new TextEncoder().encode(secret),
    { name: 'HMAC', hash: 'SHA-256' },
    false,
    ['sign']
  )

  const sig = await crypto.subtle.sign(
    'HMAC',
    key,
    new TextEncoder().encode(signedPayload)
  )

  const expectedSig = Array.from(new Uint8Array(sig))
    .map(b => b.toString(16).padStart(2, '0'))
    .join('')

  return expectedSig === signature
}

async function handleCheckoutCompleted(session: Record<string, unknown>) {
  console.log(`Checkout completed: ${session.id}`)
}

async function handlePaymentFailed(invoice: Record<string, unknown>) {
  console.log(`Payment failed: ${invoice.id}`)
}
```

**GitHub webhook signature verification (different method):**

```typescript
// volumes/functions/github-webhook/index.ts

const GITHUB_WEBHOOK_SECRET = Deno.env.get('GITHUB_WEBHOOK_SECRET')

async function verifyGitHubSignature(
  payload: string,
  signatureHeader: string,
  secret: string
): Promise<boolean> {
  // GitHub uses sha256=<hex>
  const expected = signatureHeader.replace('sha256=', '')

  const key = await crypto.subtle.importKey(
    'raw',
    new TextEncoder().encode(secret),
    { name: 'HMAC', hash: 'SHA-256' },
    false,
    ['sign']
  )

  const sig = await crypto.subtle.sign(
    'HMAC',
    key,
    new TextEncoder().encode(payload)
  )

  const computed = Array.from(new Uint8Array(sig))
    .map(b => b.toString(16).padStart(2, '0'))
    .join('')

  return computed === expected
}
```

### Verifiable Condition

```bash
# Every webhook function must have signature verification
for dir in volumes/functions/*-webhook/; do
  name=$(basename "$dir")
  if ! grep -qE "signature|verify|hmac" "$dir/index.ts" 2>/dev/null; then
    echo "CRITICAL: $name has no signature verification"
  else
    echo "OK: $name verifies signatures"
  fi
done

# Check the VERIFY_JWT setting
# Webhooks need VERIFY_JWT=false because external services do not send a Supabase JWT
grep "VERIFY_JWT" .env
```

### Failure Scenario

Without signature verification, an attacker can send arbitrary events to the webhook:

```bash
curl -X POST https://app.example.com/functions/v1/stripe-webhook \
  -H "Content-Type: application/json" \
  -d '{"type":"checkout.session.completed","data":{"object":{"customer":"cus_fake"}}}'
```

This request would trigger a forged checkout confirmation. The function would update the user status even though no payment was ever made.

## B2 - Initialize the Supabase Client Correctly (anon vs. service_role)

### Implementation

Edge Functions have access to all Supabase environment variables. Choosing between the `anon` key and the `service_role` key is the most important security decision per function.

**Shared client factory:**

```typescript
// volumes/functions/_shared/supabase-client.ts

import { createClient, SupabaseClient } from 'npm:@supabase/supabase-js@2'

// Client WITH RLS (for user-context operations)
export function createAnonClient(authHeader?: string): SupabaseClient {
  const client = createClient(
    Deno.env.get('SUPABASE_URL')!,
    Deno.env.get('SUPABASE_ANON_KEY')!,
    {
      global: {
        headers: authHeader ? { Authorization: authHeader } : {},
      },
    }
  )
  return client
}

// Client WITHOUT RLS (for webhook processing, admin tasks)
// WARNING: Bypasses all Row Level Security policies
export function createAdminClient(): SupabaseClient {
  return createClient(
    Deno.env.get('SUPABASE_URL')!,
    Deno.env.get('SUPABASE_SERVICE_ROLE_KEY')!
  )
}
```

**When to use which client:**

```
createAnonClient(authHeader):
  User-facing functions (rare, usually belong in Next.js)
  When RLS should control access

createAdminClient():
  Webhook processing (Stripe, GitHub)
  Internal sync tasks
  When the function has NO user context

Rule of thumb: Webhooks have no user context,
so they need service_role.
But: Execute only the minimal required operations.
```

### Verifiable Condition

```bash
# Where is service_role / admin client used?
grep -rn "SERVICE_ROLE\|createAdminClient\|service_role" \
  volumes/functions/ --include="*.ts" | grep -v "_shared/"

# Expected: only in webhook functions, not in user-facing functions

# Is the admin client fed with unchecked user input?
# Manual review: in every function that uses createAdminClient,
# check whether input is validated before the DB operation
```

### Failure Scenario

If an Edge Function runs with `service_role` and passes user input directly into queries, it bypasses RLS entirely. A manipulated webhook payload could then read or write arbitrary data in any table, because the `service_role` key has no restrictions.

## B3 - Input Validation

### Implementation

Every Edge Function must validate incoming data before processing it. In Deno, Zod works via npm import:

```typescript
// volumes/functions/stripe-webhook/index.ts (excerpt)

import { z } from 'npm:zod@3'

// Schema for the expected Stripe event
const stripeEventSchema = z.object({
  id: z.string().startsWith('evt_'),
  type: z.string(),
  data: z.object({
    object: z.record(z.unknown()),
  }),
})

// In the main function after signature verification:
const parsed = stripeEventSchema.safeParse(JSON.parse(body))

if (!parsed.success) {
  return new Response(
    JSON.stringify({ error: 'Invalid payload structure' }),
    { status: 400, headers: { ...corsHeaders, 'Content-Type': 'application/json' } }
  )
}

// From here, work with parsed.data (type-safe)
const event = parsed.data
```

### Verifiable Condition

```bash
# Every function should have input validation
for dir in volumes/functions/*/; do
  name=$(basename "$dir")
  [[ "$name" == "main" || "$name" == "_shared" ]] && continue
  if grep -qE "zod|safeParse|z\.object|z\.string" "$dir/index.ts" 2>/dev/null; then
    echo "OK: $name has schema validation"
  elif grep -qE "JSON\.parse" "$dir/index.ts" 2>/dev/null; then
    echo "WARNING: $name parses JSON without schema validation"
  fi
done
```

### Failure Scenario

Without input validation, the function accepts any payload that has a valid signature. A compromised API key at the webhook provider could then send unexpected data structures that lead to undefined database operations - for example, `undefined` as a user ID in an insert.

## B4 - Secrets in Environment Variables, Never in Code

### Implementation

In a self-hosted setup, secrets are passed to Edge Functions through the Docker Compose configuration:

```yaml
# docker-compose.yml (excerpt)
functions:
  environment:
    JWT_SECRET: ${JWT_SECRET}
    SUPABASE_URL: http://kong:8000
    SUPABASE_ANON_KEY: ${ANON_KEY}
    SUPABASE_SERVICE_ROLE_KEY: ${SERVICE_ROLE_KEY}
  env_file:
    - .env.functions    # additional secrets for functions
```

```bash
# .env.functions (only on the server, not in Git)
STRIPE_WEBHOOK_SECRET=whsec_...
STRIPE_SECRET_KEY=sk_live_...
GITHUB_WEBHOOK_SECRET=ghsec_...
TRIGGER_DEV_API_KEY=tr_...
```

Accessing secrets in code:

```typescript
// Correct: environment variable
const secret = Deno.env.get('STRIPE_WEBHOOK_SECRET')

// NEVER do this: hardcoded
const secret = 'whsec_abc123...'
```

For the general fundamentals of secrets management, see [Data Security in Enterprise AI Infrastructure](/en/magazine/data-security-ai-enterprise/).

### Verifiable Condition

```bash
# Hardcoded secrets in the code?
grep -rn "sk_live\|sk_test\|whsec_\|ghsec_\|Bearer ey" \
  volumes/functions/ --include="*.ts"
# Expected: no matches

# .env.functions not in Git?
git ls-files .env.functions
# Expected: empty

# File permissions correct?
stat -c "%a" .env.functions
# Expected: 600
```

### Failure Scenario

Hardcoded secrets in source code end up in the Git repository. Even if the repo is private, every developer with repo access also has access to production secrets. In the event of an accidental public push, the secrets are immediately compromised.

## B5 - Avoid Timeouts and Long-Running Tasks

### Implementation

Edge Functions are designed for short, idempotent operations. The self-hosted Edge Runtime has a default timeout (configurable, typically 60 seconds for self-hosted). Long-running tasks block worker slots.

```
Suitable (< 30 seconds):
  Receive webhook and update DB
  Verify signature and forward event
  Short API calls to external services

NOT suitable (use Trigger.dev):
  PDF generation
  AI inference (LLM calls)
  Video/image processing
  Bulk database operations
  Email delivery to many recipients
```

**Pattern for long-running tasks: Edge Function as trigger, job in Trigger.dev:**

```typescript
// volumes/functions/process-document/index.ts

// CORRECT: Edge Function only triggers the job
Deno.serve(async (req) => {
  // ... verify signature, validate input ...

  // Delegate long-running job to Trigger.dev
  const triggerResponse = await fetch(
    `${Deno.env.get('TRIGGER_DEV_URL')}/api/v1/tasks/process-document/trigger`,
    {
      method: 'POST',
      headers: {
        'Authorization': `Bearer ${Deno.env.get('TRIGGER_DEV_API_KEY')}`,
        'Content-Type': 'application/json',
      },
      body: JSON.stringify({
        payload: { documentId: parsed.data.documentId },
      }),
    }
  )

  // Respond immediately, the job runs in the background
  return new Response(
    JSON.stringify({ queued: true }),
    { status: 202, headers: { 'Content-Type': 'application/json' } }
  )
})
```

### Verifiable Condition

```bash
# Search for patterns indicating long-running tasks
grep -rn "await.*fetch.*openai\|pdf\|sharp\|ffmpeg\|sleep\|setTimeout" \
  volumes/functions/ --include="*.ts" | grep -v "trigger"
# Expected: no matches (except short API calls)

# Are there timeouts in the code?
grep -rn "AbortSignal.timeout\|setTimeout" \
  volumes/functions/ --include="*.ts"
# Every external fetch should have a timeout
```

### Failure Scenario

An Edge Function that waits 2 minutes for an AI API call blocks a worker slot in the Edge Runtime container. With multiple concurrent requests, the workers fill up and subsequent webhook calls (e.g., from Stripe) fail with timeouts. Stripe interprets this as an error and retries, which makes the situation worse. The correct pattern is to delegate these jobs to [Trigger.dev with proper retry and concurrency configuration](/en/magazine/trigger-dev-background-jobs/).

## B6 - Error Handling and Safe Responses

### Implementation

Edge Functions must not leak internal details to the caller on errors.

```typescript
// Pattern for safe error handling

Deno.serve(async (req) => {
  const corsHeaders = getCorsHeaders(req)

  if (req.method === 'OPTIONS') {
    return new Response('ok', { headers: corsHeaders })
  }

  try {
    // ... actual logic ...

    return new Response(
      JSON.stringify({ success: true }),
      { status: 200, headers: { ...corsHeaders, 'Content-Type': 'application/json' } }
    )

  } catch (error) {
    // Log internally (details)
    console.error(`Function error: ${error.message}`, {
      stack: error.stack,
      // DO NOT log secrets or user data
    })

    // Respond externally (generic)
    return new Response(
      JSON.stringify({ error: 'Internal server error' }),
      { status: 500, headers: { ...corsHeaders, 'Content-Type': 'application/json' } }
    )
  }
})
```

**What does NOT belong in responses or logs:**

```typescript
// WRONG: sending stack trace to the client
return new Response(JSON.stringify({ error: error.stack }), { status: 500 })

// WRONG: logging secrets
console.log(`Connecting with key: ${Deno.env.get('SERVICE_ROLE_KEY')}`)

// WRONG: logging complete user data
console.log(`Processing user: ${JSON.stringify(user)}`)
```

### Verifiable Condition

```bash
# Are error details sent to the client?
grep -rn "error\.stack\|error\.message" volumes/functions/ --include="*.ts" | \
  grep "Response"
# Expected: no matches (stack/message only in console.error)

# Are secrets logged?
grep -rn "console\.log.*KEY\|console\.log.*SECRET\|console\.log.*token" \
  volumes/functions/ --include="*.ts"
# Expected: no matches
```

### Failure Scenario

If an error stack trace is sent to the client, an attacker sees internal paths, module names, and database connection details. This significantly simplifies targeted attacks. If secrets end up in logs, they are visible to anyone with monitoring access.

## Part C - Operations and Monitoring

## C1 - Deployment Workflow

### Implementation

In a self-hosted setup, there is no `supabase functions deploy` command. The workflow is file-based:

```bash
#!/bin/bash
# scripts/deploy-functions.sh

set -euo pipefail

FUNCTIONS_DIR="/opt/supabase/volumes/functions"
SOURCE_DIR="./supabase/functions"

echo "Deploying Edge Functions..."

# 1. Syntax check (Deno)
for file in $(find "$SOURCE_DIR" -name "*.ts" -not -path "*/_shared/*"); do
  deno check "$file" 2>/dev/null || {
    echo "ERROR: Syntax error in $file"
    exit 1
  }
done

# 2. Copy functions
rsync -av --delete \
  --exclude='*.test.ts' \
  "$SOURCE_DIR/" "$FUNCTIONS_DIR/"

# 3. Restart the container
docker compose restart functions --no-deps

# 4. Health check
sleep 5
HEALTH=$(curl -s -o /dev/null -w "%{http_code}" \
  http://localhost:8000/functions/v1/hello 2>/dev/null || echo "000")

if [ "$HEALTH" = "200" ] || [ "$HEALTH" = "401" ]; then
  echo "Edge Functions deployment successful"
else
  echo "WARNING: Health check status $HEALTH"
fi
```

### Verifiable Condition

```bash
# Is the Edge Runtime container running?
docker compose ps functions --format '{{.State}}'
# Expected: running

# Are functions reachable?
curl -s -o /dev/null -w "%{http_code}" \
  -H "Authorization: Bearer ${ANON_KEY}" \
  http://localhost:8000/functions/v1/stripe-webhook
# Expected: 200 or 405 (Method Not Allowed, because GET instead of POST)
```

## C2 - Claude Code Integration

Claude Code checks Edge Functions contextually as a supplement to deterministic checks.

### Architecture

```
Git Push / PR
   |
   +-- Deterministic Checks (CI/CD)
   |   +-- grep for hardcoded secrets
   |   +-- grep for missing signature verification
   |   +-- grep for missing input validation
   |   +-- grep for error details in responses
   |   +-- Deno type check
   |
   +-- Claude Code Analysis (weekly or on PR)
       +-- New functions without signature verification?
       +-- service_role usage appropriate?
       +-- Long-running patterns detected?
       +-- Architecture drift (business logic in functions)?
       +-- CORS correct for new functions?
```

### Concrete CI Script

```bash
#!/bin/bash
# scripts/check-edge-functions.sh

REPORT=""
FUNCTIONS_DIR="volumes/functions"

# 1. Hardcoded secrets
SECRETS=$(grep -rn "sk_live\|sk_test\|whsec_\|Bearer ey" \
  "$FUNCTIONS_DIR" --include="*.ts" 2>/dev/null)
if [ -n "$SECRETS" ]; then
  REPORT+="CRITICAL: Hardcoded secrets found:\n$SECRETS\n\n"
fi

# 2. Webhook functions without signature verification
for dir in "$FUNCTIONS_DIR"/*-webhook/; do
  [ -d "$dir" ] || continue
  name=$(basename "$dir")
  if ! grep -qE "signature|verify|hmac|crypto" "$dir/index.ts" 2>/dev/null; then
    REPORT+="CRITICAL: $name has no signature verification\n"
  fi
done

# 3. Functions without input validation
for dir in "$FUNCTIONS_DIR"/*/; do
  name=$(basename "$dir")
  [[ "$name" == "main" || "$name" == "_shared" ]] && continue
  if grep -q "JSON.parse" "$dir/index.ts" 2>/dev/null && \
     ! grep -qE "zod|safeParse|z\." "$dir/index.ts" 2>/dev/null; then
    REPORT+="WARNING: $name parses JSON without schema validation\n"
  fi
done

# 4. Error details in responses
LEAKS=$(grep -rn "error\.stack\|error\.message" "$FUNCTIONS_DIR" --include="*.ts" | \
  grep "Response" 2>/dev/null)
if [ -n "$LEAKS" ]; then
  REPORT+="WARNING: Error details in responses:\n$LEAKS\n\n"
fi

# 5. CORS wildcards
WILDCARDS=$(grep -rn "'\\*'" "$FUNCTIONS_DIR" --include="*.ts" | grep -i "origin" 2>/dev/null)
if [ -n "$WILDCARDS" ]; then
  REPORT+="WARNING: CORS wildcard found:\n$WILDCARDS\n\n"
fi

# 6. Long-running patterns
LONG=$(grep -rn "openai\|sharp\|ffmpeg\|puppeteer" "$FUNCTIONS_DIR" --include="*.ts" 2>/dev/null)
if [ -n "$LONG" ]; then
  REPORT+="WARNING: Possible long-running patterns:\n$LONG\n\n"
fi

# Output
if [ -n "$REPORT" ]; then
  echo -e "=== Edge Function Security Check ===\n"
  echo -e "$REPORT"
else
  echo "All Edge Function checks passed."
fi
```

Claude does **not execute automatic changes on production**. The complete audit workflow with custom commands and headless mode is described in [Claude Code as a Security Control in DevOps Workflows](/en/magazine/claude-code-security-devops/).

## Deployment Checklist

Before every Edge Functions deployment, verify:

```
Architecture
  [ ] Function is an integration (webhook/event), not business logic
  [ ] One webhook provider per function
  [ ] Long-running tasks delegated to Trigger.dev

Security
  [ ] Webhook signature is verified
  [ ] Input is validated with a schema (e.g., Zod)
  [ ] Correct client choice (anon vs. service_role)
  [ ] service_role only when no user context is available

Secrets
  [ ] No hardcoded secrets in the code
  [ ] Secrets in .env.functions (not in Git)
  [ ] .env.functions with permissions 600

CORS
  [ ] OPTIONS handler present
  [ ] No wildcard origin in production
  [ ] CORS headers in ALL responses (including errors)

Error Handling
  [ ] Try/catch around the entire logic
  [ ] Generic error messages to the client
  [ ] Details only in console.error (without secrets)

Deployment
  [ ] Deno type check passed
  [ ] Container restarted after deployment
  [ ] Health check successful after deployment
```

## Conclusion

Supabase Edge Functions are a powerful integration point when used as such: receiving webhooks, verifying signatures, processing events, and forwarding them.

The critical point is clear boundaries. Edge Functions are not a second backend alongside Next.js and not a job runner alongside Trigger.dev. Drawing this line clearly and implementing the security basics (signatures, input validation, correct client, CORS) allows you to operate Edge Functions securely in a self-hosted setup.

The combination of deterministic checks in CI and contextual Claude Code analysis covers both known patterns and new, unexpected risks. Those who adopt [Cert-Ready by Design](/en/magazine/cert-ready-by-design/) from the start save themselves retroactive audit rounds.

<div class="not-prose my-12 border border-gosign-border bg-gosign-light rounded-card p-6 lg:p-8">
<div class="flex items-start gap-4">
<div class="flex-shrink-0 w-12 h-12 bg-gosign-dark rounded-card flex items-center justify-center">
<svg width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="white" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 15v4a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2v-4"/><polyline points="7 10 12 15 17 10"/><line x1="12" y1="15" x2="12" y2="3"/></svg>
</div>
<div>
<h2 class="text-h3 font-bold text-gosign-dark mb-2" id="audit-checklist-download">Audit Checklist Download</h2>
<p class="text-body text-gosign-text mb-2">Prepared prompt for Claude Code. Upload the file to your server and start Claude Code in your Edge Functions project directory. Claude Code will automatically check all security points from this runbook and report PASS, WARNING, or CRITICAL.</p>
<p class="text-sm text-gosign-text mb-4 font-mono">claude -p "$(cat claude-check-artikel-3-edge-functions-en.md)" --allowedTools Read,Grep,Glob,Bash</p>
<a href="/downloads/claude-check-artikel-3-edge-functions-en.md" download class="inline-flex items-center px-6 py-3 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-small uppercase tracking-wider">Download checklist</a>
</div>
</div>
</div>

## Series Table of Contents

This article is part of our DevOps series for self-hosted app stacks.

1. [Supabase Self-Hosting Runbook](/en/magazine/supabase-self-hosting/)
2. [Running Next.js on Supabase Securely](/en/magazine/nextjs-supabase-secure-setup/)
3. Deploying Supabase Edge Functions Securely - this article
4. [Running Trigger.dev Background Jobs Securely](/en/magazine/trigger-dev-background-jobs/)
5. [Claude Code as Security Control in DevOps Workflows](/en/magazine/claude-code-security-devops/)
6. [Security Baseline for the Entire Stack](/en/magazine/security-baseline-stack/)

In the next article, we show how to [run Trigger.dev background jobs securely](/en/magazine/trigger-dev-background-jobs/) without introducing new security risks into the stack.

--- Supabase Self-Hosting Runbook: Secure Architecture ---
> Supabase self-hosting runbook: Hetzner setup, Docker Compose, service architecture, secrets, RLS and backups.

Self-hosting Supabase is technically straightforward. **Operating Supabase securely and reliably** is considerably harder.

The reason: Supabase is not a single database. It is a complete backend platform. A self-hosted Supabase stack typically consists of several components: PostgreSQL, PostgREST API, GoTrue Auth, Realtime Server, Storage, Kong API Gateway, Supabase Studio, and optionally Edge Functions.

That means you are effectively running a **backend platform**, not just a database. Similar considerations apply when [self-hosting language models](/en/magazine/llm-self-hosting-enterprise/). Once the platform runs, the [Next.js app layer requires its own security configuration](/en/magazine/nextjs-supabase-secure-setup/) on top of it.

This runbook describes a minimal production setup that can be operated securely while remaining fully automatable. Every step contains a concrete implementation, a verifiable condition, and a failure scenario.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">At a Glance - Part 1 of 6 in the DevOps Runbook Series</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Two-server architecture physically separates production and audit systems</li>
<li>Docker Compose with version-pinned images (no :latest)</li>
<li>Seven services: PostgreSQL, PostgREST, GoTrue, Kong, Realtime, Storage, Studio</li>
<li>Row Level Security required on all public tables</li>
<li>Daily encrypted backups with GPG, stored externally on the audit server</li>
</ul>
</div>

> **Note on hosting providers:** This runbook uses **Hetzner Cloud** as the infrastructure example because Hetzner is widely adopted in Europe, offers German data centers, and provides strong value for money. However, the architecture principles are **provider-agnostic**. The Hetzner-specific parts (vSwitch, Cloud Firewall API, Robot Panel) translate directly to other EU providers: OVH vRack (EU/UK), IONOS Cloud Network (EU/UK), Scaleway Private Network (EU). Where a step is Hetzner-specific, we point it out.

## Series Table of Contents

This guide is part of our DevOps runbook series for modern self-hosted app stacks.

1. Supabase Self-Hosting Runbook - this article
2. [Running Next.js on Supabase Securely](/en/magazine/nextjs-supabase-secure-setup/)
3. [Deploying Supabase Edge Functions Securely](/en/magazine/supabase-edge-functions-secure/)
4. [Running Trigger.dev Background Jobs Securely](/en/magazine/trigger-dev-background-jobs/)
5. [Claude Code as Security Control in DevOps Workflows](/en/magazine/claude-code-security-devops/)
6. [Security Baseline for the Entire Stack](/en/magazine/security-baseline-stack/)

Article 1 covers **infrastructure, services, and stack configuration**. The following articles build on top of it.

## Target Architecture

A stable setup separates at least two areas of responsibility.

```
Internet
   |
   |  HTTPS (443)
   |
Reverse Proxy (Caddy / Nginx / Traefik)
   |
   |  TLS terminated
   |
Kong API Gateway
   |
   +-- GoTrue         (Auth)
   +-- PostgREST       (API)
   +-- Realtime        (WebSocket)
   +-- Storage         (S3-compatible Object Store)
   |
PostgreSQL
   |
   +-- RLS Policies
```

Running in parallel is a second, separate system:

```
Audit Server
   |
   +-- Security Checks    (Lynis, Trivy, Port Scans)
   +-- Drift Detection     (Config Diffs against Baseline)
   +-- Claude Code Review  (Contextual Analysis)
   +-- Monitoring          (Metrics, Alerts)
   +-- Backup Verification (Restore Tests)
```

Why this separation matters: if the production system and the audit system are identical, a compromised server can simultaneously manipulate its own security checks. The audit server also hosts [Claude Code for contextual security analysis](/en/magazine/claude-code-security-devops/), which reviews the entire stack weekly.

### Supabase Service Overview

| Service | Port | Function | Security-Critical Configuration |
|---------|------|----------|-------------------------------|
| PostgreSQL | 5432 | Database | Internal interface only (10.0.1.10), RLS on all public tables |
| PostgREST | 3000 | REST API | Accessible only via Kong, JWT validation |
| GoTrue | 9999 | Authentication | JWT expiry max 3600s, refresh token rotation |
| Kong | 8000 | API Gateway | Single entry point, rate limiting |
| Realtime | 4000 | WebSocket | RLS-based authorization |
| Storage | 5000 | File Storage | Bucket policies, no public buckets |
| Studio | 3000 | Admin UI | Not externally accessible, SSH tunnel only |

According to the Verizon Data Breach Investigations Report 2024, more than 60% of all database-related security incidents stem from misconfigurations and missing access controls.

## Part A - Infrastructure Decisions

These decisions are made once and form the foundation for everything that follows.

## A1 - Separate Infrastructure: Two Servers

### Implementation

Run at least two servers, either physical machines or separate VMs:

```
supabase-prod     (Hetzner Cloud CX32 or higher)
audit-runner      (Hetzner Cloud CX22 is sufficient)
```

> **Hetzner-specific:** In the Hetzner Cloud Console under "Servers", create two separate instances in the same project and the same location (e.g. fsn1). For other providers: two VMs in the same region/zone.

**supabase-prod** runs the entire Supabase stack and PostgreSQL.
**audit-runner** runs security checks, monitoring, drift detection, and Claude Code analysis.

### Verifiable Condition

```bash
# Both servers must be separate hosts
ssh supabase-prod hostname
ssh audit-runner hostname

# Expected: different hostnames and IPs
```

### Failure Scenario

If audit and production run on the same server and an attacker gains root access, they can delete logs, manipulate security check results, and suppress alerts. The compromise goes undetected.

## A2 - Set Up a Private Network

### Implementation

Both servers communicate internally over a private network. Supabase services are only reachable through these internal IPs.

> **Hetzner-specific:** Under "Networks", create a vSwitch or Cloud Network with subnet `10.0.1.0/24`. Assign both servers to the network. Hetzner automatically creates an interface (typically `ens10`). At OVH: vRack. At IONOS: Cloud Network. At Scaleway: Private Networks.

```bash
# Configure the private interface on both servers
# /etc/network/interfaces.d/60-private.cfg (Hetzner-specific)

auto ens10
iface ens10 inet static
  address 10.0.1.10/24    # supabase-prod
  # address 10.0.1.11/24  # audit-runner
```

```bash
# Activate the network
systemctl restart networking

# Verify
ip addr show ens10
ping 10.0.1.11   # from the prod server
```

### Verifiable Condition

```bash
# From audit-runner: is the internal interface active?
ssh audit-runner "ip addr show ens10 | grep 10.0.1.11"

# PostgreSQL must only listen on the internal interface
ssh supabase-prod "ss -tlnp | grep 5432"

# Expected: 10.0.1.10:5432, NOT 0.0.0.0:5432
```

### Failure Scenario

If PostgreSQL listens on `0.0.0.0:5432` and the firewall has a misconfiguration, the database is directly reachable from the internet. With the `service_role` key or a weak Postgres password, the entire database is compromised.

## A3 - Reverse Proxy with TLS

### Implementation

A reverse proxy sits in front of Kong. It terminates TLS and is the only service reachable from the outside. Caddy is used here as an example because it includes automatic Let's Encrypt certificate management.

```
# Caddyfile

app.example.com {
    reverse_proxy localhost:8000 {
        header_up X-Forwarded-Proto {scheme}
        header_up X-Real-IP {remote_host}
    }

    header {
        X-Frame-Options "DENY"
        X-Content-Type-Options "nosniff"
        Referrer-Policy "strict-origin-when-cross-origin"
        Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
        -Server
    }
}
```

Alternatively with Nginx:

```nginx
server {
    listen 443 ssl http2;
    server_name app.example.com;

    ssl_certificate /etc/letsencrypt/live/app.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/app.example.com/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;

    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # WebSocket support for Realtime
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}
```

### Verifiable Condition

```bash
# TLS active and correctly configured?
curl -I https://app.example.com

# Expected: HTTP/2 200, Strict-Transport-Security header present

# Check TLS version
openssl s_client -connect app.example.com:443 -tls1_2 </dev/null 2>&1 | grep "Protocol"

# Certificate expiry date
echo | openssl s_client -connect app.example.com:443 2>/dev/null | \
  openssl x509 -noout -enddate

# Expected: notAfter at least 14 days in the future

# Security headers present?
curl -sI https://app.example.com | grep -E \
  "X-Frame-Options|Strict-Transport-Security|X-Content-Type-Options"
```

### Failure Scenario

Without TLS, auth tokens travel in plain text across the network. Anyone in the same network segment can intercept them (man-in-the-middle). Without automatic certificate renewal, the certificate expires after 90 days and the app becomes unreachable.

## A4 - Set Up Dual-Layer Firewalls

### Implementation

Two layers that back each other up:

**Layer 1: Cloud Firewall (in front of the server)**

> **Hetzner-specific:** Under "Firewalls", create a new firewall and assign it to both servers. At OVH: Security Groups. At IONOS: Cloud Firewalls. At Scaleway: Security Groups.

```
# Hetzner Cloud Firewall rules for supabase-prod

Inbound:
  TCP 443    from 0.0.0.0/0        (HTTPS)
  TCP 22     from ADMIN_IP/32       (SSH from admin only)
  TCP ALL    from 10.0.1.0/24       (internal network)

Outbound:
  ALL        to 0.0.0.0/0        (Updates, DNS, Let's Encrypt)
```

**Layer 2: Host Firewall (on the server)**

```bash
# /etc/iptables/rules.v4

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]

# Loopback
-A INPUT -i lo -j ACCEPT

# Established Connections
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# SSH from admin IP only
-A INPUT -p tcp --dport 22 -s ADMIN_IP -j ACCEPT

# HTTPS
-A INPUT -p tcp --dport 443 -j ACCEPT

# Internal network (all ports)
-A INPUT -s 10.0.1.0/24 -j ACCEPT

# Drop everything else (default policy)
COMMIT
```

```bash
# Activate the firewall
apt install iptables-persistent
iptables-restore < /etc/iptables/rules.v4

# Save baseline for drift detection
iptables-save > /root/firewall-baseline.txt
```

### Verifiable Condition

```bash
# From outside: only port 443 open
nmap -p 22,80,443,5432,8000,9000 app.example.com

# Expected: only 443 open (22 only from admin IP)

# On the server: rules active?
iptables -L -n | grep -c "DROP"

# Expected: at least 1 (default DROP policy)

# Drift detection: has the firewall changed?
iptables-save | diff /root/firewall-baseline.txt -

# Expected: no differences
```

### Failure Scenario

A single firewall can be misconfigured. Running `iptables -F` (flush) on the server opens all ports if no cloud firewall exists. Conversely, a cloud firewall does not protect against processes on the server itself opening new ports if no host firewall is active.

## A5 - Harden SSH Access

### Implementation

```bash
# /etc/ssh/sshd_config

PasswordAuthentication no
PermitRootLogin no
PubkeyAuthentication yes
MaxAuthTries 3
LoginGraceTime 30
AllowUsers deploy
```

```bash
# Deploy the SSH key on the server
mkdir -p /home/deploy/.ssh
echo "ssh-ed25519 AAAA... admin@workstation" > /home/deploy/.ssh/authorized_keys
chmod 700 /home/deploy/.ssh
chmod 600 /home/deploy/.ssh/authorized_keys
chown -R deploy:deploy /home/deploy/.ssh

# Reload SSHD
systemctl reload sshd
```

### Verifiable Condition

```bash
# Password login must fail
ssh -o PasswordAuthentication=yes -o PubkeyAuthentication=no deploy@app.example.com

# Expected: Permission denied

# Root login must fail
ssh root@app.example.com

# Expected: Permission denied

# Verify configuration
sshd -T | grep -E "passwordauthentication|permitrootlogin"

# Expected: passwordauthentication no, permitrootlogin no
```

### Failure Scenario

Password-based SSH access is under constant attack from the internet (brute force). A weak password is typically cracked within hours. Root login means an attacker immediately gains full control over the server.

## Part B - Setting Up and Securing Supabase Services

A self-hosted Supabase stack consists of over 10 services. Each has its own environment variables, its own database roles, and its own security requirements. The official `docker-compose.yml` from Supabase is over 400 lines long and contains many settings that are not obviously security-relevant but still are.

This section explains each service, its role, its security-relevant configuration, and the typical mistakes made during setup.

### Service Overview

```
Internet
   |
   |  HTTPS (443)
   |
Reverse Proxy (Caddy/Nginx)     <- Part A3
   |
Kong (API Gateway)               <- routes to all services
   |
   +-- GoTrue (Auth)              <- /auth/v1/*
   +-- PostgREST (REST API)       <- /rest/v1/*
   +-- Realtime                   <- /realtime/v1/*
   +-- Storage API                <- /storage/v1/*
   +-- Edge Functions             <- /functions/v1/*
   +-- Studio (Dashboard)         <- / (protected with Basic Auth)
   |
   +-- Meta (Postgres-Meta)       <- internal, for Studio
   +-- ImgProxy                   <- internal, for Storage
   +-- Analytics (Logflare)       <- internal, for Logs
   +-- Vector                     <- internal, Log Pipeline
   +-- Supavisor (Pooler)         <- Connection Pooling
   |
PostgreSQL                        <- Database with Init Scripts
   |
   +-- Roles: anon, authenticated, service_role,
       authenticator, supabase_admin, supabase_auth_admin,
       supabase_storage_admin
```

## B0 - Generate Secrets (Before First Start)

**This must happen BEFORE starting any services.** The official `.env.example` contains placeholders. These must be replaced with generated values.

```bash
# JWT Secret (shared by GoTrue, PostgREST, Realtime, Kong)
JWT_SECRET=$(openssl rand -base64 32)

# Postgres Password
POSTGRES_PASSWORD=$(openssl rand -base64 24)

# Dashboard Password (Basic Auth via Kong)
DASHBOARD_PASSWORD=$(openssl rand -base64 16)

# Logflare Tokens
LOGFLARE_PUBLIC_ACCESS_TOKEN=$(openssl rand -hex 16)
LOGFLARE_PRIVATE_ACCESS_TOKEN=$(openssl rand -hex 16)

# MinIO Root Password (if using S3 Storage)
MINIO_ROOT_PASSWORD=$(openssl rand -hex 16)

# Realtime Secret Key Base (min. 64 characters)
SECRET_KEY_BASE=$(openssl rand -base64 48)

# Supavisor Vault Encryption Key
VAULT_ENC_KEY=$(openssl rand -base64 24)

# PG Meta Crypto Key
PG_META_CRYPTO_KEY=$(openssl rand -base64 24)

# Anon Key and Service Role Key (JWTs, generated with the JWT_SECRET)
# Use https://supabase.com/docs/guides/self-hosting/docker#generate-api-keys
# or generate them manually with jwt.io using the JWT_SECRET
```

**Security rule:** All secrets go into the `.env` file on the server (permissions 600, not in Git). Supabase uses a single `JWT_SECRET` for all services. If this secret is compromised, GoTrue, PostgREST, and Realtime are all affected simultaneously.

### Verifiable Condition

```bash
# All required secrets set?
for var in JWT_SECRET POSTGRES_PASSWORD ANON_KEY SERVICE_ROLE_KEY \
  DASHBOARD_PASSWORD LOGFLARE_PUBLIC_ACCESS_TOKEN SECRET_KEY_BASE \
  VAULT_ENC_KEY PG_META_CRYPTO_KEY; do
  if grep -q "^${var}=$\|^${var}=your-\|^${var}=change" .env 2>/dev/null; then
    echo "CRITICAL: $var is not set or has default value"
  fi
done

# No identical passwords?
PASSWORDS=$(grep -E "PASSWORD|SECRET|KEY" .env | cut -d= -f2 | sort)
UNIQUE=$(echo "$PASSWORDS" | sort -u)
if [ "$(echo "$PASSWORDS" | wc -l)" != "$(echo "$UNIQUE" | wc -l)" ]; then
  echo "WARNING: Some secrets have identical values"
fi
```

### Failure Scenario

Default secrets from `.env.example` are publicly known. An attacker can generate valid tokens using the default `JWT_SECRET` and gains full API access. With the default `SERVICE_ROLE_KEY`, they additionally bypass all RLS policies.

## B1 - PostgreSQL: Database and Roles

### What This Service Does

PostgreSQL is the central database. In the Supabase context it has a special role: it stores not only application data but also auth data (GoTrue), Realtime configuration, Storage metadata, and Analytics logs. The init scripts create specialized schemas and roles.

### Security-Relevant Configuration

```yaml
db:
  image: supabase/postgres:15.8.1.085    # Supabase's own image, pin the version
  restart: unless-stopped
  ports:
    - "10.0.1.10:5432:5432"              # internal interface ONLY
  volumes:
    # Init scripts (create schemas, roles, extensions)
    - ./volumes/db/realtime.sql:/docker-entrypoint-initdb.d/migrations/99-realtime.sql:Z
    - ./volumes/db/webhooks.sql:/docker-entrypoint-initdb.d/init-scripts/98-webhooks.sql:Z
    - ./volumes/db/roles.sql:/docker-entrypoint-initdb.d/init-scripts/99-roles.sql:Z
    - ./volumes/db/jwt.sql:/docker-entrypoint-initdb.d/init-scripts/99-jwt.sql:Z
    - ./volumes/db/_supabase.sql:/docker-entrypoint-initdb.d/migrations/97-_supabase.sql:Z
    - ./volumes/db/logs.sql:/docker-entrypoint-initdb.d/migrations/99-logs.sql:Z
    - ./volumes/db/pooler.sql:/docker-entrypoint-initdb.d/migrations/99-pooler.sql:Z
    # Persistent data
    - ./volumes/db/data:/var/lib/postgresql/data:Z
    - db-config:/etc/postgresql-custom
  healthcheck:
    test: ["CMD", "pg_isready", "-U", "postgres", "-h", "localhost"]
    interval: 5s
    timeout: 5s
    retries: 10
  environment:
    POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    POSTGRES_DB: ${POSTGRES_DB}
    JWT_SECRET: ${JWT_SECRET}
    JWT_EXP: ${JWT_EXPIRY}
```

**The init scripts create the following roles:**

```
postgres              -> Superuser (admin only, never for services)
anon                  -> Unauthenticated requests (via PostgREST)
authenticated         -> Authenticated requests (via PostgREST)
service_role          -> Bypasses RLS (for admin operations)
authenticator         -> PostgREST uses this role to connect
supabase_admin        -> Internal admin role (Realtime, Analytics)
supabase_auth_admin   -> GoTrue-specific (auth schema)
supabase_storage_admin -> Storage-specific (storage schema)
```

### What Can Go Wrong

The `roles.sql` defines the grants for each role. If this file is modified (e.g. to quickly fix an issue), roles can end up with excessive permissions. The `anon` role must only have the permissions that RLS policies explicitly allow. All these role and RLS rules are consolidated into the [machine-readable security baseline](/en/magazine/security-baseline-stack/) described in Article 6.

### Verifiable Condition

```bash
# Check roles and their permissions
docker compose exec -T db psql -U postgres -c \
  "SELECT rolname, rolsuper, rolcreaterole, rolcreatedb, rolcanlogin
   FROM pg_roles
   WHERE rolname IN ('anon','authenticated','service_role','authenticator',
     'supabase_admin','supabase_auth_admin','supabase_storage_admin')
   ORDER BY rolname;"

# anon must NOT be superuser
docker compose exec -T db psql -U postgres -c \
  "SELECT rolname, rolsuper FROM pg_roles WHERE rolname = 'anon' AND rolsuper = true;"
# Expected: no rows

# Postgres listens ONLY on internal interface
ss -tlnp | grep 5432
# Expected: 10.0.1.10:5432, NOT 0.0.0.0:5432
```

## B2 - Kong: API Gateway and Routing

### What This Service Does

Kong is the central entry point for all API requests. It routes based on the URL path to the correct services, handles JWT validation, and protects the Studio dashboard with Basic Auth.

### Security-Relevant Configuration

```yaml
kong:
  image: kong:2.8.1                       # pin the version
  restart: unless-stopped
  ports:
    - "127.0.0.1:8000:8000"              # localhost ONLY (reverse proxy in front)
    - "127.0.0.1:8443:8443"              # HTTPS internal
  volumes:
    - ./volumes/api/kong.yml:/home/kong/temp.yml:ro,z
  environment:
    KONG_DATABASE: "off"                   # declarative config, no DB
    KONG_DECLARATIVE_CONFIG: /home/kong/kong.yml
    KONG_DNS_ORDER: LAST,A,CNAME
    KONG_PLUGINS: request-transformer,cors,key-auth,acl,basic-auth,request-termination,ip-restriction
    SUPABASE_ANON_KEY: ${ANON_KEY}
    SUPABASE_SERVICE_KEY: ${SERVICE_ROLE_KEY}
    DASHBOARD_USERNAME: ${DASHBOARD_USERNAME}
    DASHBOARD_PASSWORD: ${DASHBOARD_PASSWORD}
  entrypoint: bash -c 'eval "echo \"$$(cat ~/temp.yml)\"" > ~/kong.yml && /docker-entrypoint.sh kong docker-start'
```

**The `kong.yml` defines the routing:**

```
/rest/v1/*        -> PostgREST (port 3000)    + JWT Validation
/auth/v1/*        -> GoTrue (port 9999)       + JWT Validation
/realtime/v1/*    -> Realtime (port 4000)      + JWT Validation
/storage/v1/*     -> Storage (port 5000)       + JWT Validation
/functions/v1/*   -> Edge Functions (port 54321) + JWT Validation (optional)
/                 -> Studio (port 3000)        + Basic Auth
```

### What Can Go Wrong

Setting Kong to `0.0.0.0:8000` instead of `127.0.0.1:8000` means the API is directly reachable without the reverse proxy (without TLS). A weak dashboard password grants access to Studio via Basic Auth and thereby to the entire database. The `kong.yml` can be configured to disable JWT validation for certain routes.

### Verifiable Condition

```bash
# Kong on localhost only?
ss -tlnp | grep 8000
# Expected: 127.0.0.1:8000

# Dashboard password strong enough?
DASH_PW_LEN=$(grep "DASHBOARD_PASSWORD" .env | cut -d= -f2 | wc -c)
[ "$DASH_PW_LEN" -lt 16 ] && echo "WARNING: Dashboard password too short"

# kong.yml: JWT Validation active on all API routes?
grep -A5 "key-auth" volumes/api/kong.yml | head -20
```

## B3 - GoTrue: Authentication

### What This Service Does

GoTrue handles user registration, login, magic links, OAuth, MFA, and token issuance. It is the only service that issues JWTs and has its own DB user (`supabase_auth_admin`) with access to the `auth` schema.

### Security-Relevant Configuration

```yaml
auth:
  image: supabase/gotrue:v2.184.0       # pin the version
  restart: unless-stopped
  environment:
    GOTRUE_API_HOST: 0.0.0.0
    GOTRUE_API_PORT: 9999
    API_EXTERNAL_URL: ${API_EXTERNAL_URL}    # https://app.example.com

    # Database (dedicated admin user)
    GOTRUE_DB_DATABASE_URL: postgres://supabase_auth_admin:${POSTGRES_PASSWORD}@${POSTGRES_HOST}:${POSTGRES_PORT}/${POSTGRES_DB}

    # JWT
    GOTRUE_JWT_SECRET: ${JWT_SECRET}
    GOTRUE_JWT_EXP: ${JWT_EXPIRY}            # MAXIMUM 3600 (1 hour)
    GOTRUE_JWT_AUD: authenticated
    GOTRUE_JWT_ADMIN_ROLES: service_role
    GOTRUE_JWT_DEFAULT_GROUP_NAME: authenticated

    # Registration
    GOTRUE_DISABLE_SIGNUP: ${DISABLE_SIGNUP}  # true for closed apps
    GOTRUE_EXTERNAL_EMAIL_ENABLED: ${ENABLE_EMAIL_SIGNUP}
    GOTRUE_MAILER_AUTOCONFIRM: false          # ALWAYS false in production

    # SMTP (for magic links, email confirmation)
    GOTRUE_SMTP_HOST: ${SMTP_HOST}
    GOTRUE_SMTP_PORT: ${SMTP_PORT}
    GOTRUE_SMTP_USER: ${SMTP_USER}
    GOTRUE_SMTP_PASS: ${SMTP_PASS}
    GOTRUE_SMTP_ADMIN_EMAIL: ${SMTP_ADMIN_EMAIL}
    GOTRUE_SMTP_SENDER_NAME: ${SMTP_SENDER_NAME}

    # Mailer URL paths (must match Kong routing)
    GOTRUE_MAILER_URLPATHS_CONFIRMATION: "/auth/v1/verify"
    GOTRUE_MAILER_URLPATHS_INVITE: "/auth/v1/verify"
    GOTRUE_MAILER_URLPATHS_RECOVERY: "/auth/v1/verify"
    GOTRUE_MAILER_URLPATHS_EMAIL_CHANGE: "/auth/v1/verify"

    # Site URL (redirect after auth)
    GOTRUE_SITE_URL: ${SITE_URL}              # URL of your Next.js app
    GOTRUE_URI_ALLOW_LIST: ${ADDITIONAL_REDIRECT_URLS}

    # Refresh Token Rotation (prevents token reuse)
    GOTRUE_SECURITY_REFRESH_TOKEN_ROTATION_ENABLED: true
    GOTRUE_SECURITY_REFRESH_TOKEN_REUSE_INTERVAL: 10
```

### SMTP Configuration: Why It Is Security-Relevant

Without a working SMTP server, no confirmation emails can be sent. If `GOTRUE_MAILER_AUTOCONFIRM: true` is set to work around this, anyone can register with any email address. This means no identity verification whatsoever.

### Verifiable Condition

```bash
# GoTrue Health Check
docker compose exec -T auth wget --no-verbose --tries=1 --spider http://localhost:9999/health

# JWT Expiry not above 3600?
grep "JWT_EXPIRY\|JWT_EXP" .env | head -1
# Expected: 3600 or less

# Autoconfirm disabled?
grep "AUTOCONFIRM" .env
# Expected: false

# SMTP configured (not empty)?
for var in SMTP_HOST SMTP_PORT SMTP_USER SMTP_PASS; do
  VAL=$(grep "^${var}=" .env | cut -d= -f2)
  [ -z "$VAL" ] && echo "WARNING: $var is empty"
done

# Refresh Token Rotation active?
grep "REFRESH_TOKEN_ROTATION" .env docker-compose.yml 2>/dev/null
# Expected: true
```

### Failure Scenario

With `AUTOCONFIRM=true` and `DISABLE_SIGNUP=false`, anyone can create an account and use it immediately without confirming their email address. An attacker can register with arbitrary addresses and instantly gains the `authenticated` role in the database. Without Refresh Token Rotation, a stolen refresh token can be used indefinitely.

## B4 - PostgREST: REST API

### What This Service Does

PostgREST automatically generates a REST API from the PostgreSQL schema. It is the primary data access point. Security lies primarily in the PostgreSQL roles and RLS policies, not in PostgREST itself.

### Security-Relevant Configuration

```yaml
rest:
  image: postgrest/postgrest:v14.1       # pin the version
  restart: unless-stopped
  environment:
    PGRST_DB_URI: postgres://authenticator:${POSTGRES_PASSWORD}@${POSTGRES_HOST}:${POSTGRES_PORT}/${POSTGRES_DB}
    PGRST_DB_SCHEMAS: ${PGRST_DB_SCHEMAS}   # public,storage,graphql_public
    PGRST_DB_ANON_ROLE: anon
    PGRST_JWT_SECRET: ${JWT_SECRET}
    PGRST_DB_USE_LEGACY_GUCS: "false"
    PGRST_APP_SETTINGS_JWT_SECRET: ${JWT_SECRET}
    PGRST_APP_SETTINGS_JWT_EXP: ${JWT_EXPIRY}
```

**How PostgREST works with roles:**

```
Request without JWT     -> PostgREST uses role "anon"
Request with JWT        -> PostgREST switches to role from JWT (e.g. "authenticated")
Request with service_role JWT -> PostgREST uses "service_role" (bypasses RLS)
```

The `authenticator` user connects to the database and switches via `SET ROLE` to the respective role. This means the grants on the `anon` and `authenticated` roles are the actual security layer.

### Verifiable Condition

```bash
# PostgREST uses authenticator role (not postgres)?
grep "PGRST_DB_URI" docker-compose.yml | grep "authenticator"
# Expected: Yes

# Schemas explicitly defined (not all)?
grep "PGRST_DB_SCHEMAS" .env
# Expected: public,storage,graphql_public (not empty = all schemas)
```

### Failure Scenario

If `PGRST_DB_URI` uses the `postgres` superuser instead of `authenticator`, every request has superuser privileges and RLS is ineffective. If `PGRST_DB_SCHEMAS` is empty, PostgREST exposes all schemas including internal Supabase schemas (`auth`, `_realtime`, `_analytics`).

## B5 - Realtime: WebSocket Subscriptions

### What This Service Does

Realtime enables WebSocket-based subscriptions to database changes. It uses the `supabase_admin` user and the `_realtime` schema.

### Security-Relevant Configuration

```yaml
realtime:
  container_name: realtime-dev.supabase-realtime   # name is relevant for tenant ID
  image: supabase/realtime:v2.68.0
  restart: unless-stopped
  environment:
    PORT: 4000
    DB_HOST: ${POSTGRES_HOST}
    DB_PORT: ${POSTGRES_PORT}
    DB_USER: supabase_admin
    DB_PASSWORD: ${POSTGRES_PASSWORD}
    DB_NAME: ${POSTGRES_DB}
    DB_AFTER_CONNECT_QUERY: 'SET search_path TO _realtime'
    DB_ENC_KEY: supabaserealtime          # CHANGE in production
    API_JWT_SECRET: ${JWT_SECRET}
    SECRET_KEY_BASE: ${SECRET_KEY_BASE}   # min. 64 characters
    SEED_SELF_HOST: "true"
    RUN_JANITOR: "true"
```

### What Can Go Wrong

`DB_ENC_KEY: supabaserealtime` is a default value. It must be changed in production. `SECRET_KEY_BASE` must be at least 64 characters long, otherwise the service will not start or is insecure. Realtime uses `supabase_admin`, meaning it has full DB access internally. Security comes from JWT validation: only authenticated users can open subscriptions, and RLS determines which rows they can see.

### Verifiable Condition

```bash
# DB_ENC_KEY not set to default?
grep "DB_ENC_KEY" docker-compose.yml
# NOT "supabaserealtime"

# SECRET_KEY_BASE long enough?
SKB_LEN=$(grep "SECRET_KEY_BASE" .env | cut -d= -f2 | wc -c)
[ "$SKB_LEN" -lt 64 ] && echo "CRITICAL: SECRET_KEY_BASE too short ($SKB_LEN characters)"

# Realtime Health Check
docker compose exec -T realtime-dev.supabase-realtime \
  curl -sSf -H "Authorization: Bearer ${ANON_KEY}" \
  http://localhost:4000/api/tenants/realtime-dev/health
```

## B6 - Storage API and MinIO (S3)

### What This Service Does

Storage manages file uploads and downloads. By default it stores files locally in a volume. For production, an S3-compatible backend is recommended (self-hosted MinIO or a Cloud Act-free S3 service).

### Local Storage (Default)

```yaml
storage:
  image: supabase/storage-api:v1.33.0
  restart: unless-stopped
  volumes:
    - ./volumes/storage:/var/lib/storage:z
  environment:
    ANON_KEY: ${ANON_KEY}
    SERVICE_KEY: ${SERVICE_ROLE_KEY}
    POSTGREST_URL: http://rest:3000
    PGRST_JWT_SECRET: ${JWT_SECRET}
    DATABASE_URL: postgres://supabase_storage_admin:${POSTGRES_PASSWORD}@${POSTGRES_HOST}:${POSTGRES_PORT}/${POSTGRES_DB}
    STORAGE_BACKEND: file
    FILE_STORAGE_BACKEND_PATH: /var/lib/storage
    FILE_SIZE_LIMIT: 52428800              # 50MB, adjust as needed
    ENABLE_IMAGE_TRANSFORMATION: "true"
    IMGPROXY_URL: http://imgproxy:5001
```

### MinIO for S3 Backend (Production)

If you use MinIO, an additional service is required:

```yaml
# docker-compose.s3.yml (in addition to the main compose file)
minio:
  image: minio/minio:latest              # pin the version in production
  restart: unless-stopped
  ports:
    - "127.0.0.1:9000:9000"              # API, localhost ONLY
    - "127.0.0.1:9001:9001"              # Console, localhost ONLY
  volumes:
    - minio-data:/data
  environment:
    MINIO_ROOT_USER: ${MINIO_ROOT_USER}
    MINIO_ROOT_PASSWORD: ${MINIO_ROOT_PASSWORD}   # min. 8 characters
  command: server /data --console-address ":9001"
```

Then in the Storage configuration:

```yaml
storage:
  environment:
    STORAGE_BACKEND: s3
    GLOBAL_S3_BUCKET: supabase-storage
    GLOBAL_S3_ENDPOINT: http://minio:9000
    GLOBAL_S3_FORCE_PATH_STYLE: "true"
    AWS_ACCESS_KEY_ID: ${MINIO_ACCESS_KEY}
    AWS_SECRET_ACCESS_KEY: ${MINIO_SECRET_KEY}
    REGION: eu-central-1
```

### Verifiable Condition

```bash
# Storage Health Check
docker compose exec -T storage wget --no-verbose --tries=1 --spider http://localhost:5000/status

# MinIO not reachable from outside (if in use)?
ss -tlnp | grep 9000
# Expected: 127.0.0.1:9000 (not 0.0.0.0)

# MinIO default credentials?
grep "MINIO_ROOT" .env | grep -iE "minioadmin\|minio123\|admin"
# Expected: no matches

# Storage volume exists and has data?
ls -la volumes/storage/ 2>/dev/null | head -5

# Storage Bucket Policies (via MinIO Client)
# mc alias set local http://localhost:9000 $MINIO_ROOT_USER $MINIO_ROOT_PASSWORD
# mc admin policy ls local
```

### Failure Scenario

MinIO with default credentials (`minioadmin:minioadmin`) on `0.0.0.0:9000` means anyone on the internet can read and write all files. The MinIO Console on port 9001 additionally provides a web UI with full administrative access. Storage bucket policies can be set to "public", meaning files are accessible without authentication.

## B7 - Analytics, Vector and Supavisor (Internal Services)

### What These Services Do

These services are not directly reachable from outside, but they are security-relevant because they have privileged database access.

**Analytics (Logflare):** Collects and stores logs from all services. Uses `supabase_admin` and the `_analytics` schema.

**Vector:** Log pipeline that forwards Docker logs to Logflare. Has access to the Docker socket.

**Supavisor:** Connection pooler for PostgreSQL. Manages the connection pool and has `supabase_admin` access.

### Security-Relevant Configuration

```yaml
analytics:
  image: supabase/logflare:1.27.0
  ports:
    - "127.0.0.1:4000:4000"             # localhost ONLY
  environment:
    DB_USERNAME: supabase_admin
    DB_PASSWORD: ${POSTGRES_PASSWORD}
    LOGFLARE_PUBLIC_ACCESS_TOKEN: ${LOGFLARE_PUBLIC_ACCESS_TOKEN}
    LOGFLARE_PRIVATE_ACCESS_TOKEN: ${LOGFLARE_PRIVATE_ACCESS_TOKEN}

vector:
  image: timberio/vector:0.28.1-alpine
  volumes:
    - ${DOCKER_SOCKET_LOCATION}:/var/run/docker.sock:ro,z   # Read-Only!
  security_opt:
    - "label=disable"

supavisor:
  image: supabase/supavisor:2.7.4
  ports:
    - "10.0.1.10:5432:5432"             # Pooler exposes Postgres port
    - "127.0.0.1:6543:6543"             # Transaction Mode
  environment:
    DATABASE_URL: ecto://supabase_admin:${POSTGRES_PASSWORD}@${POSTGRES_HOST}:${POSTGRES_PORT}/_supabase
    SECRET_KEY_BASE: ${SECRET_KEY_BASE}
    VAULT_ENC_KEY: ${VAULT_ENC_KEY}
    POOLER_DEFAULT_POOL_SIZE: ${POOLER_DEFAULT_POOL_SIZE}
    POOLER_MAX_CLIENT_CONN: ${POOLER_MAX_CLIENT_CONN}
```

### What Can Go Wrong

Vector with Docker socket access (`/var/run/docker.sock`) can read container logs. The socket should be mounted **read-only** (`:ro`). Analytics on port 4000 with default tokens exposes logs from all services. Supavisor on `0.0.0.0:5432` instead of the internal interface makes the connection pooler (and thereby PostgreSQL) reachable from outside.

### Verifiable Condition

```bash
# Analytics on internal only?
ss -tlnp | grep 4000
# Expected: 127.0.0.1:4000

# Vector Docker Socket Read-Only?
grep "docker.sock" docker-compose.yml | grep ":ro"
# Expected: :ro present

# Supavisor port on internal only?
ss -tlnp | grep 5432
# Expected: 10.0.1.10:5432 (internal interface)

# Logflare Tokens not on default?
grep "LOGFLARE.*TOKEN" .env | grep -iE "your-\|change\|example"
# Expected: no matches
```

## B8 - Studio: Securing the Dashboard

### What This Service Does

Studio is the web UI for database management, user administration, and SQL queries. Through the `SERVICE_ROLE_KEY` and direct Postgres access, it has **full access to everything**.

### Security-Relevant Configuration

Studio is protected by Kong via Basic Auth (DASHBOARD_USERNAME/DASHBOARD_PASSWORD). Additionally, Studio should either not run in production at all or only be reachable via SSH tunnel.

**Option 1: Do not run Studio in production (recommended)**

```yaml
# In docker-compose.override.yml or remove Studio from the compose file
# Use Studio only locally with supabase start for development
```

**Option 2: Studio only via SSH tunnel**

```bash
# From your workstation:
ssh -L 3000:localhost:3000 deploy@supabase-prod

# Then in the browser: http://localhost:3000
```

### Verifiable Condition

```bash
# Studio container running? (Should not be running in production)
docker compose ps | grep studio
# Recommendation: not running in production

# If Studio is running: not reachable from outside?
curl -s -o /dev/null -w "%{http_code}" --connect-timeout 3 \
  "https://app.example.com:3000" 2>/dev/null
# Expected: Timeout or Connection Refused

# Dashboard password strong?
DASH_LEN=$(grep "DASHBOARD_PASSWORD" .env | cut -d= -f2 | wc -c)
[ "$DASH_LEN" -lt 16 ] && echo "WARNING: Dashboard password too short"
```

### Failure Scenario

Studio with a weak dashboard password and public access gives an attacker a full database admin UI. They can execute SQL queries, delete users, disable RLS, and export data. This is the worst case for a self-hosted stack.

### Service Checklist

After setting up all services, verify these items before the first production deployment:

```
Secrets
  [ ] All secrets generated (no default values)
  [ ] JWT_SECRET at least 32 characters
  [ ] POSTGRES_PASSWORD at least 24 characters
  [ ] DASHBOARD_PASSWORD at least 16 characters
  [ ] SECRET_KEY_BASE at least 64 characters
  [ ] MINIO_ROOT_PASSWORD at least 8 characters (if using MinIO)
  [ ] DB_ENC_KEY changed (not "supabaserealtime")

PostgreSQL
  [ ] Port on internal interface only (10.0.1.10:5432)
  [ ] Init scripts unmodified (roles.sql, jwt.sql etc.)
  [ ] Roles correctly created (anon not superuser)

Kong
  [ ] Port on localhost only (127.0.0.1:8000)
  [ ] JWT validation active on all API routes
  [ ] Dashboard password strong

GoTrue (Auth)
  [ ] JWT_EXP maximum 3600
  [ ] AUTOCONFIRM false
  [ ] SMTP configured and tested
  [ ] SITE_URL and API_EXTERNAL_URL correct
  [ ] Refresh Token Rotation active
  [ ] DISABLE_SIGNUP set for closed apps

PostgREST
  [ ] Uses authenticator role (not postgres)
  [ ] DB_SCHEMAS explicitly defined

Realtime
  [ ] DB_ENC_KEY changed
  [ ] SECRET_KEY_BASE at least 64 characters

Storage / MinIO
  [ ] MinIO not reachable from outside
  [ ] MinIO default credentials changed
  [ ] Storage volume permissions correct

Internal Services
  [ ] Analytics port on localhost only
  [ ] Vector Docker Socket read-only
  [ ] Supavisor port on internal only
  [ ] Logflare tokens not on default

Studio
  [ ] Disabled in production OR only via SSH tunnel
  [ ] Dashboard password strong
```

## Part C - Supabase Stack Configuration

These steps cover the actual Supabase installation and its security-relevant settings.

## C1 - Version Your Supabase Deployment

### Implementation

All infrastructure files belong in a Git repository. Deployments happen only through this repository, never through manual changes on the server.

```
infra/
  docker-compose.yml
  .env.example            (template, no real secrets)
  caddy/
    Caddyfile
  postgres/
    migrations/
  scripts/
    backup.sh
    restore.sh
    health-check.sh
    security-check.sh
  runbooks/
    supabase-production.md
    security-baseline.md
```

### Deployment Workflow

```bash
# On the server
cd /opt/supabase
git pull origin main

# Load env variables (file exists only on the server)
source .env

# Start/update the stack
docker compose up -d

# Health check
./scripts/health-check.sh
```

### Verifiable Condition

```bash
# Any uncommitted changes on the server?
cd /opt/supabase && git status --porcelain

# Expected: empty (no local modifications)

# Is the server on the current commit?
git log --oneline -1
# Compare with remote
git fetch origin && git diff HEAD origin/main --stat

# Expected: no difference
```

### Failure Scenario

Manual changes to `docker-compose.yml` on the server get overwritten on the next `git pull` or create merge conflicts. Worse: nobody knows which change was made when and by whom. After a server loss, the configuration is not reproducible.

## C2 - docker-compose.yml: Minimal Production Stack

### Implementation

Supabase ships a reference compose file with over 400 lines and roughly 15 services. Not all of them are needed for production. Here are the security-relevant decisions:

**Minimal stack (these services are required):**

```
postgres          Database
kong              API Gateway
gotrue            Auth
postgrest         REST API
realtime          WebSocket (if needed)
storage           File Storage (if needed)
meta              Metadata for PostgREST
```

**Not for production (omit or keep internal only):**

```
studio            Admin UI, access only via SSH tunnel or VPN
imgproxy          only if image transformations are needed
inbucket          only for local email testing
```

Excerpt of the security-relevant configuration:

```yaml
# docker-compose.yml (excerpt, security-relevant parts)

services:
  postgres:
    image: supabase/postgres:15.6.1.143    # pin the version
    restart: unless-stopped
    ports:
      - "10.0.1.10:5432:5432"              # internal interface ONLY
    environment:
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    volumes:
      - postgres-data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 30s
      timeout: 10s
      retries: 3

  kong:
    image: kong:2.8.1                       # pin the version
    restart: unless-stopped
    ports:
      - "127.0.0.1:8000:8000"              # localhost ONLY (reverse proxy in front)
    environment:
      KONG_DNS_ORDER: LAST,A,CNAME
      KONG_PLUGINS: request-transformer,cors,key-auth,acl
      KONG_NGINX_PROXY_PROXY_BUFFER_SIZE: 160k
      KONG_NGINX_PROXY_PROXY_BUFFERS: 64 160k

  gotrue:
    image: supabase/gotrue:v2.164.0         # pin the version
    restart: unless-stopped
    environment:
      GOTRUE_JWT_SECRET: ${JWT_SECRET}
      GOTRUE_JWT_EXP: 3600                  # 1 hour, no more
      GOTRUE_EXTERNAL_EMAIL_ENABLED: true
      GOTRUE_MAILER_AUTOCONFIRM: false      # enforce email confirmation
      GOTRUE_DISABLE_SIGNUP: false           # set to true if registration is closed
      GOTRUE_RATE_LIMIT_HEADER: X-Real-IP
      GOTRUE_SECURITY_REFRESH_TOKEN_ROTATION_ENABLED: true
      GOTRUE_SECURITY_REFRESH_TOKEN_REUSE_INTERVAL: 10
      API_EXTERNAL_URL: https://app.example.com

  postgrest:
    image: postgrest/postgrest:v12.2.3      # pin the version
    restart: unless-stopped
    environment:
      PGRST_DB_URI: postgres://authenticator:${POSTGRES_PASSWORD}@postgres:5432/postgres
      PGRST_DB_ANON_ROLE: anon
      PGRST_JWT_SECRET: ${JWT_SECRET}

volumes:
  postgres-data:

networks:
  default:
    driver: bridge
```

**Critical configuration points:**

```
GOTRUE_JWT_EXP: 3600         no higher than 3600 (1h)
GOTRUE_MAILER_AUTOCONFIRM    false in production
GOTRUE_DISABLE_SIGNUP         true if no open registration
REFRESH_TOKEN_ROTATION        true (prevents token reuse)
Image versions               always pin, never use :latest
Postgres port                bind to internal interface only
Kong port                    bind to localhost only (reverse proxy in front)
```

### Verifiable Condition

```bash
# Images pinned (no :latest)?
grep "image:" docker-compose.yml | grep -c "latest"
# Expected: 0

# Postgres only reachable internally?
docker compose exec postgres ss -tlnp | grep 5432
# Expected: only 10.0.1.10:5432 or 0.0.0.0:5432 (then check firewall)

# Postgres not reachable from outside?
nmap -p 5432 app.example.com
# Expected: filtered or closed

# JWT expiry correct?
grep "GOTRUE_JWT_EXP" .env
# Expected: 3600 or less

# Supabase Studio not reachable from outside?
curl -s -o /dev/null -w "%{http_code}" https://app.example.com:3000
# Expected: timeout or connection refused
```

### Failure Scenario

Unpinned images (`image: supabase/gotrue:latest`) can silently introduce a new version during a `docker compose pull` that contains breaking changes or a known vulnerability. If Postgres listens on `0.0.0.0:5432` and the firewall temporarily fails, the entire database is exposed to the internet. If `GOTRUE_JWT_EXP` is set to 86400 (24h), a stolen token remains valid for an entire day.

## C3 - Manage Secrets Securely

### Implementation

A Supabase stack has at least these secrets:

```bash
# .env (on the server only, never in Git)

# Core secrets
JWT_SECRET=                    # min. 32 characters, generated with openssl rand -base64 32
ANON_KEY=                      # JWT token with anon role
SERVICE_ROLE_KEY=              # JWT token with service_role, bypasses RLS
POSTGRES_PASSWORD=             # min. 24 characters, generated

# Dashboard
DASHBOARD_USERNAME=            # Supabase Studio login
DASHBOARD_PASSWORD=            # min. 16 characters

# Email (GoTrue)
SMTP_HOST=
SMTP_PORT=
SMTP_USER=
SMTP_PASS=
SMTP_SENDER_NAME=

# Storage (if using S3 backend)
S3_ACCESS_KEY=
S3_SECRET_KEY=
```

**Generating secrets:**

```bash
# JWT secret
openssl rand -base64 32

# Postgres password
openssl rand -base64 24

# Anon and service role keys (Supabase CLI)
# Or manually create JWTs using the JWT_SECRET
```

**Secret management on the server:**

```bash
# .env file with restrictive permissions
chmod 600 /opt/supabase/.env
chown deploy:deploy /opt/supabase/.env

# Verify that .env is not tracked in Git
cat /opt/supabase/.gitignore | grep ".env"
```

**Only the template belongs in the repository:**

```bash
# .env.example (in Git)
JWT_SECRET=generate-with-openssl-rand-base64-32
ANON_KEY=generate-jwt-with-anon-role
SERVICE_ROLE_KEY=generate-jwt-with-service-role
POSTGRES_PASSWORD=generate-with-openssl-rand-base64-24
DASHBOARD_USERNAME=admin
DASHBOARD_PASSWORD=generate-min-16-chars
SMTP_HOST=
SMTP_PORT=587
SMTP_USER=
SMTP_PASS=
SMTP_SENDER_NAME=
```

The same principle applies to any [data security in enterprise AI infrastructure](/en/magazine/data-security-ai-enterprise/).

### Verifiable Condition

```bash
# .env not in Git?
cd /opt/supabase && git ls-files .env
# Expected: empty

# .env listed in .gitignore?
grep "^\.env$" .gitignore
# Expected: .env

# File permissions correct?
stat -c "%a %U" .env
# Expected: 600 deploy

# Secrets long enough?
awk -F= '{if (length($2) < 16 && $2 != "" && $1 !~ /PORT|HOST|NAME/) print "TOO SHORT: "$1}' .env
# Expected: no output

# No default passwords?
grep -iE "password|secret" .env | grep -iE "change.me|default|example|your.*here"
# Expected: no matches
```

### Failure Scenario

The most common security issue with Supabase self-hosting is not a server exploit but a leaked secret. If `.env` is committed to Git and the repository is public (or becomes public), all secrets are exposed. With the `SERVICE_ROLE_KEY`, the entire database can be read and written without RLS.

## C4 - Audit Database Policies

### Implementation

With Supabase, a large portion of security lives in PostgreSQL Row Level Security (RLS), not in the application server. Every table in the `public` schema must have RLS enabled.

**Find tables without RLS:**

```sql
-- All public tables without RLS
SELECT schemaname, tablename, rowsecurity
FROM pg_tables
WHERE schemaname = 'public'
  AND rowsecurity = false;
```

**Find tables with RLS but no policies:**

```sql
-- RLS enabled but no policy defined = no access possible
-- (may be intentional, but verify)
SELECT t.tablename
FROM pg_tables t
LEFT JOIN pg_policies p ON t.tablename = p.tablename
WHERE t.schemaname = 'public'
  AND t.rowsecurity = true
  AND p.policyname IS NULL;
```

**Find overly permissive policies:**

```sql
-- Policies that grant full access to all roles
SELECT tablename, policyname, permissive, roles, cmd, qual
FROM pg_policies
WHERE schemaname = 'public'
  AND (roles = '{public}' OR qual = 'true');
```

**Audit service role usage:**

```sql
-- Which roles exist and what permissions do they have?
SELECT rolname, rolsuper, rolcreaterole, rolcreatedb
FROM pg_roles
WHERE rolname IN ('anon', 'authenticated', 'service_role', 'authenticator');
```

### Verifiable Condition

```bash
# As an automated script from the audit-runner
ssh supabase-prod "docker compose exec -T postgres psql -U postgres -c \"
  SELECT tablename FROM pg_tables
  WHERE schemaname = 'public' AND rowsecurity = false;
\""

# Expected: no tables (or only intentionally excluded ones)
```

### Failure Scenario

A `users` table with `rowsecurity = false` is fully readable through the PostgREST API by anyone with the `anon` key. This exposes all columns, including email addresses, phone numbers, and other personal data. A simple `curl` command with the public `anon` key is all it takes.

## Part D - Operations and Monitoring

These steps run regularly and are automated.

## D1 - Automate Backups

### Implementation

Daily PostgreSQL dumps, encrypted and stored externally.

```bash
#!/bin/bash
# scripts/backup.sh

set -euo pipefail

BACKUP_DIR="/opt/backups"
DATE=$(date +%Y-%m-%d_%H%M)
RETENTION_DAYS=30
GPG_RECIPIENT="backup@example.com"   # GPG key ID

# PostgreSQL dump
docker compose exec -T postgres pg_dump \
  -U postgres \
  --format=custom \
  --compress=9 \
  postgres > "${BACKUP_DIR}/db_${DATE}.dump"

# Back up storage buckets (if Supabase Storage is in use)
docker compose exec -T storage tar -czf - /var/lib/storage \
  > "${BACKUP_DIR}/storage_${DATE}.tar.gz"

# Encrypt
for file in "${BACKUP_DIR}"/*_${DATE}.*; do
  gpg --encrypt --recipient "${GPG_RECIPIENT}" "$file"
  rm "$file"   # Delete unencrypted version
done

# Copy to external server (audit-runner or S3)
rsync -az "${BACKUP_DIR}/"*_${DATE}*.gpg \
  deploy@10.0.1.11:/opt/backup-archive/

# Remove old backups (local)
find "${BACKUP_DIR}" -name "*.gpg" -mtime +${RETENTION_DAYS} -delete

# Clean up on the backup server as well
ssh deploy@10.0.1.11 \
  "find /opt/backup-archive -name '*.gpg' -mtime +${RETENTION_DAYS} -delete"

echo "Backup ${DATE} completed"
```

```bash
# Set up the cron job
# crontab -e
0 3 * * * /opt/supabase/scripts/backup.sh >> /var/log/backup.log 2>&1
```

### Verifiable Condition

```bash
# Today's backup exists?
ls -la /opt/backups/*_$(date +%Y-%m-%d)*.gpg

# Backup arrived on the external server?
ssh deploy@10.0.1.11 "ls -la /opt/backup-archive/*_$(date +%Y-%m-%d)*.gpg"

# Backup size is plausible (not 0 bytes)?
find /opt/backups -name "*.gpg" -size 0 -print
# Expected: no matches
```

### Failure Scenario

Storing backups only on the same server means that if the server fails or gets encrypted (ransomware), the backups are gone too. Unencrypted backups on an external server are a data leak because the dump contains all table data in plain text.

## D2 - Test Restores Regularly

### Implementation

Once a month, restore a backup on a test system.

```bash
#!/bin/bash
# scripts/restore-test.sh

set -euo pipefail

BACKUP_FILE=$1   # e.g. /opt/backup-archive/db_2026-03-01_0300.dump.gpg

# Decrypt
gpg --decrypt "$BACKUP_FILE" > /tmp/restore-test.dump

# Start a test container
docker run -d --name restore-test \
  -e POSTGRES_PASSWORD=testpassword \
  supabase/postgres:15.6.1.143

sleep 10

# Restore
docker exec -i restore-test pg_restore \
  -U postgres \
  --dbname=postgres \
  --clean \
  --if-exists \
  < /tmp/restore-test.dump

# Verify tables
docker exec restore-test psql -U postgres -c \
  "SELECT schemaname, tablename FROM pg_tables WHERE schemaname = 'public';"

# Verify row counts
docker exec restore-test psql -U postgres -c \
  "SELECT relname, n_live_tup FROM pg_stat_user_tables ORDER BY n_live_tup DESC LIMIT 10;"

# Clean up
docker rm -f restore-test
rm /tmp/restore-test.dump

echo "Restore test completed"
```

### Verifiable Condition

```bash
# Run the restore test script and check the exit code
./scripts/restore-test.sh /opt/backup-archive/db_latest.dump.gpg
echo $?
# Expected: 0

# Check the log of the last restore test
cat /var/log/restore-test.log | tail -20
```

### Failure Scenario

Many teams have backups running for months without ever testing a restore. Typical problems: wrong `pg_dump` format (plain text instead of custom), missing permissions during restore, incompatible PostgreSQL versions between backup and restore. All of this only surfaces when you actually need the restore.

## D3 - Daily Infrastructure Checks

### Implementation

A script on the audit-runner checks the state of the production system daily.

```bash
#!/bin/bash
# scripts/security-check.sh (runs on audit-runner)

set -euo pipefail

PROD_HOST="10.0.1.10"
REPORT=""
CRITICAL=0

# 1. Container status
STOPPED=$(ssh deploy@${PROD_HOST} "docker compose ps --format json" | \
  jq -r 'select(.State != "running") | .Name')
if [ -n "$STOPPED" ]; then
  REPORT+="CRITICAL: Container not running: ${STOPPED}\n"
  CRITICAL=1
fi

# 2. Open ports from outside
OPEN_PORTS=$(nmap -p 22,80,443,3000,5432,8000,9000 app.example.com \
  --open -oG - | grep "/open/" | grep -v "443/open")
if [ -n "$OPEN_PORTS" ]; then
  REPORT+="CRITICAL: Unexpected open ports: ${OPEN_PORTS}\n"
  CRITICAL=1
fi

# 3. Certificate expiry date
CERT_EXPIRY=$(echo | openssl s_client -connect app.example.com:443 2>/dev/null | \
  openssl x509 -noout -enddate | cut -d= -f2)
CERT_EPOCH=$(date -d "$CERT_EXPIRY" +%s)
NOW_EPOCH=$(date +%s)
DAYS_LEFT=$(( (CERT_EPOCH - NOW_EPOCH) / 86400 ))
if [ "$DAYS_LEFT" -lt 14 ]; then
  REPORT+="WARNING: TLS certificate expires in ${DAYS_LEFT} days\n"
fi

# 4. Firewall drift
FIREWALL_DIFF=$(ssh deploy@${PROD_HOST} "iptables-save" | \
  diff /opt/baselines/firewall-baseline.txt - || true)
if [ -n "$FIREWALL_DIFF" ]; then
  REPORT+="WARNING: Firewall has changed:\n${FIREWALL_DIFF}\n"
fi

# 5. Docker image versions (drift against baseline)
IMAGE_DIFF=$(ssh deploy@${PROD_HOST} \
  "docker compose images --format '{{.Repository}}:{{.Tag}}'" | \
  diff /opt/baselines/image-versions.txt - || true)
if [ -n "$IMAGE_DIFF" ]; then
  REPORT+="WARNING: Container versions have changed:\n${IMAGE_DIFF}\n"
fi

# 6. Disk space
DISK_USAGE=$(ssh deploy@${PROD_HOST} "df -h / | tail -1 | awk '{print \$5}' | tr -d '%'")
if [ "$DISK_USAGE" -gt 85 ]; then
  REPORT+="WARNING: Disk usage at ${DISK_USAGE}%\n"
fi

# 7. Backup status
LAST_BACKUP=$(ssh deploy@${PROD_HOST} "ls -t /opt/backups/*.gpg 2>/dev/null | head -1")
if [ -z "$LAST_BACKUP" ]; then
  REPORT+="CRITICAL: No backup found\n"
  CRITICAL=1
else
  BACKUP_AGE=$(ssh deploy@${PROD_HOST} \
    "echo \$(( (\$(date +%s) - \$(stat -c %Y ${LAST_BACKUP})) / 3600 ))")
  if [ "$BACKUP_AGE" -gt 26 ]; then
    REPORT+="WARNING: Last backup is ${BACKUP_AGE} hours old\n"
  fi
fi

# 8. RLS check
UNPROTECTED=$(ssh deploy@${PROD_HOST} "docker compose exec -T postgres psql -U postgres -t -c \
  \"SELECT count(*) FROM pg_tables WHERE schemaname = 'public' AND rowsecurity = false;\"" | tr -d ' ')
if [ "$UNPROTECTED" -gt 0 ]; then
  REPORT+="WARNING: ${UNPROTECTED} tables without RLS\n"
fi

# Result
echo "=== Security Check $(date) ==="
if [ -n "$REPORT" ]; then
  echo -e "$REPORT"
else
  echo "All checks passed"
fi

# On critical findings: send alert
if [ "$CRITICAL" -eq 1 ]; then
  echo -e "$REPORT" | mail -s "CRITICAL: Security Check $(date)" ops@example.com
fi
```

```bash
# Cron on the audit-runner
0 7 * * * /opt/audit/scripts/security-check.sh >> /var/log/security-check.log 2>&1
```

### Verifiable Condition

```bash
# Check script ran today?
grep "$(date +%Y-%m-%d)" /var/log/security-check.log | tail -1
# Expected: entry from today

# Result?
grep "All checks passed\|CRITICAL\|WARNING" /var/log/security-check.log | tail -5
```

## D4 - Claude Code as a Contextual Analysis Layer

Claude Code analyzes the results of deterministic checks and identifies patterns that scripts cannot see.

### Architecture

```
Daily Checks (D3)
     |
     +-- Deterministic Findings
     |   (open ports, firewall drift, missing backups)
     |
     +---> Weekly Claude Code Review
          |
          +-- Config files (docker-compose.yml, Caddyfile, .env.example)
          +-- Security check logs from the last 7 days
          +-- Git diff of infrastructure changes
          +-- RLS policy export
          |
          +---> Prioritized Report
               |
               +---> DevOps Decision (Human)
```

### Script

```bash
#!/bin/bash
# scripts/claude-review-prep.sh (runs on audit-runner)

REPORT_DIR="/opt/audit/weekly-reports"
DATE=$(date +%Y-%m-%d)
OUTPUT="${REPORT_DIR}/review-input-${DATE}.md"

mkdir -p "$REPORT_DIR"

cat > "$OUTPUT" << 'HEADER'
# Weekly Security Review Input

## Context
Self-hosted Supabase stack on Hetzner Cloud.
Architecture: Reverse Proxy -> Kong -> Supabase Services -> PostgreSQL
Audit system on a separate server.
HEADER

# Security check logs from the last 7 days
echo -e "\n## Security Check Results (last 7 days)\n" >> "$OUTPUT"
echo '```' >> "$OUTPUT"
grep -A 20 "Security Check" /var/log/security-check.log | \
  tail -100 >> "$OUTPUT"
echo '```' >> "$OUTPUT"

# Current Docker Compose config (without secrets)
echo -e "\n## Current docker-compose.yml\n" >> "$OUTPUT"
echo '```yaml' >> "$OUTPUT"
ssh deploy@10.0.1.10 "cat /opt/supabase/docker-compose.yml" >> "$OUTPUT"
echo '```' >> "$OUTPUT"

# Git diff from the last week
echo -e "\n## Infrastructure Changes (last 7 days)\n" >> "$OUTPUT"
echo '```' >> "$OUTPUT"
ssh deploy@10.0.1.10 "cd /opt/supabase && git log --oneline --since='7 days ago'" >> "$OUTPUT"
ssh deploy@10.0.1.10 "cd /opt/supabase && git diff HEAD~5 --stat" >> "$OUTPUT" 2>/dev/null
echo '```' >> "$OUTPUT"

# RLS status
echo -e "\n## RLS Status\n" >> "$OUTPUT"
echo '```' >> "$OUTPUT"
ssh deploy@10.0.1.10 "docker compose exec -T postgres psql -U postgres -c \"
  SELECT tablename, rowsecurity FROM pg_tables WHERE schemaname = 'public' ORDER BY tablename;
\"" >> "$OUTPUT"
echo '```' >> "$OUTPUT"

# Container versions
echo -e "\n## Container Versions\n" >> "$OUTPUT"
echo '```' >> "$OUTPUT"
ssh deploy@10.0.1.10 "docker compose images --format '{{.Repository}}:{{.Tag}}'" >> "$OUTPUT"
echo '```' >> "$OUTPUT"

echo "Review input created: $OUTPUT"
```

### What Claude Code Does Not Do

```
Claude does NOT make automatic changes on production.
Claude does NOT deploy.
Claude does NOT rotate secrets.
Claude does NOT have direct access to the production server.

Claude analyzes data that is provided to it
and produces reports for human decision-making.
```

## Deployment Checklist

Before the first go-live and after major changes:

```
Part A - Infrastructure
  [ ] Two separate servers (prod + audit)
  [ ] Private network configured and tested
  [ ] Cloud firewall active (only 443, SSH from admin IP)
  [ ] Host firewall active (iptables)
  [ ] Firewall baseline saved
  [ ] SSH: keys only, no root, no passwords
  [ ] Reverse proxy configured (Caddy/Nginx)
  [ ] TLS active with automatic renewal
  [ ] Security headers set (HSTS, CSP, X-Frame-Options)
  [ ] WebSocket proxy configured for Realtime

Part B - Supabase Services
  Secrets (B0)
    [ ] All secrets generated (no default values)
    [ ] JWT_SECRET at least 32 characters
    [ ] POSTGRES_PASSWORD at least 24 characters
    [ ] DASHBOARD_PASSWORD at least 16 characters
    [ ] SECRET_KEY_BASE at least 64 characters
    [ ] MINIO_ROOT_PASSWORD at least 8 characters (if using MinIO)
    [ ] DB_ENC_KEY changed (not "supabaserealtime")
  PostgreSQL (B1)
    [ ] Port on internal interface only (10.0.1.10:5432)
    [ ] Init scripts unmodified (roles.sql, jwt.sql etc.)
    [ ] Roles correctly created (anon not superuser)
  Kong (B2)
    [ ] Port on localhost only (127.0.0.1:8000)
    [ ] JWT validation active on all API routes
    [ ] Dashboard password strong
  GoTrue (B3)
    [ ] JWT_EXP maximum 3600
    [ ] AUTOCONFIRM false
    [ ] SMTP configured and tested
    [ ] SITE_URL and API_EXTERNAL_URL correct
    [ ] Refresh Token Rotation active
    [ ] DISABLE_SIGNUP set for closed apps
  PostgREST (B4)
    [ ] Uses authenticator role (not postgres)
    [ ] DB_SCHEMAS explicitly defined
  Realtime (B5)
    [ ] DB_ENC_KEY changed
    [ ] SECRET_KEY_BASE at least 64 characters
  Storage / MinIO (B6)
    [ ] MinIO not reachable from outside
    [ ] MinIO default credentials changed
    [ ] Storage volume permissions correct
  Internal Services (B7)
    [ ] Analytics port on localhost only
    [ ] Vector Docker Socket read-only
    [ ] Supavisor port on internal only
    [ ] Logflare tokens not on default
  Studio (B8)
    [ ] Disabled in production OR only via SSH tunnel
    [ ] Dashboard password strong

Part C - Stack Configuration
  [ ] docker-compose.yml versioned in Git
  [ ] All image versions pinned (no :latest)
  [ ] .env not in Git
  [ ] .env file permissions 600
  [ ] .env.example in Git as template
  [ ] No default passwords
  [ ] RLS enabled on all public tables
  [ ] No tables without policies (unless intentional)
  [ ] No overly permissive policies (qual = 'true')

Part D - Operations and Monitoring
  [ ] Daily backup job active
  [ ] Backups encrypted
  [ ] Backups stored externally (audit-runner or S3)
  [ ] Restore test completed at least once
  [ ] Retention strategy configured
  [ ] Daily security check job on audit-runner
  [ ] Alerting on critical findings
  [ ] Weekly Claude Code review set up

Part E - Updates and Maintenance
  [ ] Unattended Upgrades installed and active
  [ ] Auto-update interval configured to daily
  [ ] Supabase images pinned (no :latest)
  [ ] No Supabase image older than 90 days
  [ ] Update commit within the last 45 days
  [ ] Auto-patch script for PostgreSQL minor patches active
  [ ] Auto-patch cron AFTER backup cron (03:00 after 02:00)
  [ ] Security release monitor on audit-runner active (daily)
  [ ] Trivy installed on audit-runner
  [ ] Maintenance check cron on audit-runner (weekly Monday)
  [ ] TLS certificate valid for at least 14 days
  [ ] Disk usage below 85%
```

## Part E - Updates and Maintenance

A self-hosted stack that is not updated regularly accumulates security vulnerabilities. Unpatched CVEs in PostgreSQL, Kong, or GoTrue are real attack vectors. At the same time, updates can introduce breaking changes that take down the stack.

That is why the update process needs clear rules: what gets updated when, how it is tested, and how to ensure nothing is missed.

### E1 - Three Update Layers

The stack has three independent update layers with different rhythms and risk levels.

```
Layer 1: OS-Level (Ubuntu)
   |  What: Kernel, System Packages, OpenSSL, Docker Engine
   |  Rhythm: Weekly security patches, monthly full update
   |  Risk: Low (apt upgrade is stable)
   |  Method: apt update && apt upgrade
   |
Layer 2: Supabase Services (Docker Images)
   |  What: PostgreSQL, Kong, GoTrue, PostgREST, Realtime, Storage, etc.
   |  Rhythm: Monthly (Supabase release cycle)
   |  Risk: Medium to high (breaking changes between versions)
   |  Method: Change image tags in docker-compose.yml, pull, restart
   |
Layer 3: Reverse Proxy and Tools
   |  What: Caddy, iptables, GPG, nmap, jq
   |  Rhythm: On security advisories or quarterly
   |  Risk: Low
   |  Method: apt upgrade (Caddy via its own repo)
```

**Verifiable Condition:**

```bash
# OS: When was the last apt upgrade?
stat -c %y /var/cache/apt/pkgcache.bin
# Expected: less than 7 days old

# Supabase: Which image versions are running?
cd /opt/supabase && docker compose images --format '{{.Repository}}:{{.Tag}}'

# Caddy Version
caddy version
```

**Failure Scenario:** An unpatched PostgreSQL with a known Remote Code Execution vulnerability (such as CVE-2023-5869) can be exploited by an attacker, even when RLS is correctly configured. An outdated Kong with a known auth bypass vulnerability can circumvent JWT validation.

### E2 - OS-Level Updates

**Weekly: Security Patches (automatic)**

```bash
# Install and configure unattended upgrades
sudo apt install -y unattended-upgrades

# Configuration: only security updates automatically
sudo tee /etc/apt/apt.conf.d/50unattended-upgrades > /dev/null << 'EOF'
Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
};

// Automatic reboot if needed (e.g. kernel update)
// Only enable if you can accept the server briefly
// restarting at 4:00 AM
Unattended-Upgrade::Automatic-Reboot "false";

// Email notification on updates
Unattended-Upgrade::Mail "ops@example.com";
Unattended-Upgrade::MailReport "on-change";
EOF

# Enable automatic updates
sudo tee /etc/apt/apt.conf.d/20auto-upgrades > /dev/null << 'EOF'
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::AutocleanInterval "7";
EOF

sudo systemctl enable unattended-upgrades
sudo systemctl start unattended-upgrades
```

**Monthly: Full System Update (manual, with review)**

```bash
# First check what will be updated
apt list --upgradable

# Then update
sudo apt update && sudo apt upgrade -y

# Docker Engine update (separate, via Docker repo)
sudo apt install --only-upgrade docker-ce docker-ce-cli containerd.io

# After kernel updates: reboot needed?
if [ -f /var/run/reboot-required ]; then
  echo "REBOOT REQUIRED"
fi
```

**Verifiable Condition:**

```bash
# Unattended Upgrades active?
systemctl is-active unattended-upgrades

# Recent automatic updates
cat /var/log/unattended-upgrades/unattended-upgrades.log | tail -20

# Pending security updates?
apt list --upgradable 2>/dev/null | grep -i security | wc -l
# Expected: 0
```

### E3 - Supabase Service Updates

Supabase releases new Docker images approximately once a month. The update process must be controlled because breaking changes between versions are possible.

**Workflow:**

```
1. Read release notes (github.com/supabase/supabase/releases)
2. Enter new image tags in docker-compose.yml
3. Test on staging (or: backup + rollback plan)
4. Create backup
5. docker compose pull
6. docker compose down && docker compose up -d
7. Check health checks
8. Update baselines
```

**Check current versions vs. available:**

```bash
cd /opt/supabase

echo "=== Current Versions ==="
docker compose images --format '{{.Repository}}:{{.Tag}}'

echo ""
echo "=== Available Updates ==="
# Check official releases
echo "Supabase Releases: https://github.com/supabase/supabase/releases"
echo "GoTrue: https://github.com/supabase/gotrue/releases"
echo "PostgREST: https://github.com/PostgREST/postgrest/releases"
echo "Realtime: https://github.com/supabase/realtime/releases"
echo ""
echo "Or compare with the official docker-compose.yml:"
echo "https://raw.githubusercontent.com/supabase/supabase/master/docker/docker-compose.yml"
```

**Safe update procedure:**

```bash
cd /opt/supabase

# 1. Backup BEFORE the update
./scripts/backup.sh

# 2. Document current versions
docker compose images --format '{{.Repository}}:{{.Tag}}' > /opt/baselines/pre-update-versions.txt

# 3. Enter new versions in docker-compose.yml
# MANUAL: Change image tags to the new version
# e.g. supabase/gotrue:v2.164.0 -> supabase/gotrue:v2.184.0

# 4. Pull new images
docker compose pull

# 5. Restart stack
docker compose down
docker compose up -d

# 6. Wait and run health checks
sleep 30
docker compose ps --format "table {{.Name}}\t{{.Status}}"

# 7. Check all services
docker compose exec -T auth wget --no-verbose --tries=1 --spider http://localhost:9999/health
docker compose exec -T db pg_isready -U postgres -h localhost
curl -s -o /dev/null -w "Kong: %{http_code}\n" http://localhost:8000
curl -s -o /dev/null -w "Storage: %{http_code}\n" http://localhost:8000/storage/v1/

# 8. Update baselines
docker compose images --format '{{.Repository}}:{{.Tag}}' > /opt/baselines/image-versions.txt

# 9. Git commit
git add docker-compose.yml
git commit -m "Update Supabase images to [VERSION]"
```

**Rollback if something goes wrong:**

```bash
cd /opt/supabase

# Restore old versions
git checkout HEAD~1 -- docker-compose.yml
docker compose pull
docker compose down
docker compose up -d

# If a database migration is the problem:
./scripts/restore.sh /opt/backups/[LATEST_BACKUP].gpg
```

**Verifiable Condition:**

```bash
# Image versions older than 3 months?
cd /opt/supabase
docker compose images --format '{{.Repository}}:{{.Tag}}' | while read image; do
  CREATED=$(docker inspect --format='{{.Created}}' "$image" 2>/dev/null | cut -dT -f1)
  if [ -n "$CREATED" ]; then
    AGE_DAYS=$(( ($(date +%s) - $(date -d "$CREATED" +%s)) / 86400 ))
    [ "$AGE_DAYS" -gt 90 ] && echo "WARNING: $image is $AGE_DAYS days old"
  fi
done
```

**Failure Scenario:** Supabase GoTrue v2.170.0 introduced a change in refresh token handling that broke older clients. Without reading the release notes first and without a backup, this would have caused an outage. PostgreSQL major version updates (e.g. 15 -> 16) require a `pg_dump/pg_restore` cycle - a simple image tag change is not enough.

### E3b - Automatic Patching (Layer 1)

Not all updates require a human. PostgreSQL minor patches and Caddy updates are low-risk and can be applied automatically at night.

**Two-tier model:**

```
TIER 1 - AUTOMATIC (auto-patch.sh, daily 03:00):
  OS Security Patches (unattended-upgrades)
  PostgreSQL Minor Patches (15.8.1.x -> 15.8.1.y)
  Caddy Updates
  -> Info email after successful patch
  -> Alert email on health check failure
  -> Automatic rollback on failure

TIER 2 - MANUAL (/supabase-update, within 24h of alert):
  GoTrue/Auth (breaking changes possible)
  PostgREST (query behavior may change)
  Kong (routing may change)
  Realtime, Storage, Supavisor
  PostgreSQL MAJOR (15 -> 16, requires pg_dump/pg_restore)
```

The script `auto-patch.sh` runs daily at 03:00 (after the backup at 02:00) and:

1. Checks whether a current backup exists (aborts if not)
2. Saves the current state (docker-compose.yml, image versions)
3. Checks whether a new PostgreSQL minor image is available
4. Applies it and runs a health check
5. On failure: automatic rollback to the previous version
6. Sends an info email (success) or alert email (failure)

**Verifiable Condition:**

```bash
# Auto-patch cron active?
crontab -l | grep auto-patch
# Expected: 0 3 * * * /opt/supabase/scripts/auto-patch.sh

# Last auto-patch run?
tail -20 /var/log/auto-patch.log

# Has auto-patch ever patched?
grep "Patches applied\|No patches" /var/log/auto-patch.log | tail -5
```

**Cron schedule (prod server):**

```
02:00 daily    -> Backup (DB + Storage + external)
03:00 daily    -> Auto-Patch (PostgreSQL Minor + Caddy)
04:00 monthly  -> Restore test
```

### E4 - Update Schedule and Responsibilities

```
Weekly (automatic):
  [ ] OS security patches (unattended-upgrades)
  [ ] Audit-runner verifies patches were applied

Monthly (manual, scheduled):
  [ ] Check Supabase release notes
  [ ] Evaluate new image tags
  [ ] Create backup
  [ ] Perform update
  [ ] Health checks
  [ ] Update baselines

Quarterly (review):
  [ ] Check Caddy version
  [ ] Check Docker Engine version
  [ ] Check Node.js version (for Claude Code on audit-runner)
  [ ] Evaluate PostgreSQL major version
  [ ] Entire toolchain up to date?

On security advisories (immediate):
  [ ] CVE affects our stack?
  [ ] Identify affected image/package
  [ ] Patch available?
  [ ] Perform emergency update
```

**Verifiable Condition:**

```bash
# When was the last Supabase update?
cd /opt/supabase
git log --oneline --grep="Update\|update\|upgrade" | head -5

# How old is the last update commit?
LAST_UPDATE=$(git log --format="%ai" --grep="Update\|update" -1 2>/dev/null | cut -d' ' -f1)
if [ -n "$LAST_UPDATE" ]; then
  AGE=$(( ($(date +%s) - $(date -d "$LAST_UPDATE" +%s)) / 86400 ))
  echo "Last update: $LAST_UPDATE ($AGE days ago)"
  [ "$AGE" -gt 45 ] && echo "WARNING: Last update over 45 days ago"
fi
```

### E5 - Security Release Monitor (daily)

The biggest blind spot in self-hosting is not the initial configuration but missing security patches. When Supabase GoTrue publishes an auth bypass fix, the team must act within 24 hours, not after a week.

On the audit-runner, a script runs **daily** that checks the GitHub releases of all Supabase components and immediately alerts via email on security releases.

**Monitored components:**

```
supabase/auth (GoTrue)          -> frequent security patches
PostgREST/postgrest             -> API layer
supabase/realtime               -> WebSocket
supabase/storage-api            -> File Storage
Kong/kong                       -> API Gateway
supabase/edge-runtime           -> Edge Functions
supabase/postgres               -> Database Image
supabase/supavisor              -> Connection Pooler
moby/moby (Docker Engine)       -> Container Runtime
```

**Three check layers:**

```
Layer 1: GitHub Releases
  -> Is there a new version?
  -> Do the release notes contain "security"/"CVE"?

Layer 2: Trivy Container Scan
  -> Scans every running Docker image against NVD/GitHub Advisories
  -> Finds CVEs in all dependencies (OS packages, libraries)

Layer 3: OSV API
  -> Checks application-level vulnerabilities for GoTrue, PostgREST etc.
  -> Complements Trivy with package-specific CVEs
```

**How it works:**

```
Daily 07:00 (audit-runner cron)
   |
   +-- Fetch current versions from prod server
   +-- GitHub API: Check latest releases for each component
   +-- Scan release notes for "security", "CVE", "vulnerability"
   |
   +-- Security release found?
   |     -> IMMEDIATE email to ops@
   |     -> "Action required within 24h"
   |
   +-- Normal release found?
         -> Weekly summary (Monday)
```

**Cache mechanism:** The script remembers reported releases so the same email does not arrive every day. A new alert is only sent when a NEW release is detected.

**Verifiable Condition:**

```bash
# Security release monitor active on audit-runner?
ssh deploy@10.0.1.11 "crontab -l | grep security-release"
# Expected: daily cron job

# Last check log
ssh deploy@10.0.1.11 "tail -5 /var/log/security-releases.log"
# Expected: entry from today

# Cache present (script has already run)?
ssh deploy@10.0.1.11 "ls /opt/audit/cache/*-last-seen.txt 2>/dev/null | wc -l"
```

**Failure Scenario:** In January 2024, CVE-2023-5869 was published for PostgreSQL (Remote Code Execution). Anyone without a release monitor who only checked for updates monthly was vulnerable for 3-4 weeks. With the daily monitor, the email would have arrived the day after the release.

### E6 - Audit Runner as Update Watchdog

The audit runner monitors whether updates are being performed and informs the team when something is overdue.

A weekly script runs on the audit runner that checks the following:

```bash
#!/bin/bash
# scripts/check-maintenance.sh (runs on audit-runner)

PROD_HOST="10.0.1.10"
REPORT=""

echo "=== Maintenance Check $(date) ==="

# 1. OS updates overdue?
LAST_APT=$(ssh deploy@${PROD_HOST} "stat -c %Y /var/cache/apt/pkgcache.bin")
APT_AGE=$(( ($(date +%s) - $LAST_APT) / 86400 ))
if [ "$APT_AGE" -gt 7 ]; then
  REPORT+="WARNING: apt update is ${APT_AGE} days old (max. 7)\n"
fi

# 2. Unattended Upgrades active?
UA_STATUS=$(ssh deploy@${PROD_HOST} "systemctl is-active unattended-upgrades 2>/dev/null")
if [ "$UA_STATUS" != "active" ]; then
  REPORT+="CRITICAL: Unattended Upgrades not active\n"
fi

# 3. Pending security updates?
SEC_UPDATES=$(ssh deploy@${PROD_HOST} "apt list --upgradable 2>/dev/null | grep -ci security")
if [ "$SEC_UPDATES" -gt 0 ]; then
  REPORT+="WARNING: ${SEC_UPDATES} pending security updates\n"
fi

# 4. Reboot required?
REBOOT=$(ssh deploy@${PROD_HOST} "test -f /var/run/reboot-required && echo yes || echo no")
if [ "$REBOOT" = "yes" ]; then
  REPORT+="WARNING: Server reboot required (kernel update)\n"
fi

# 5. Supabase image age
ssh deploy@${PROD_HOST} "cd /opt/supabase && docker compose images --format '{{.Repository}}:{{.Tag}}'" | \
while read image; do
  CREATED=$(ssh deploy@${PROD_HOST} "docker inspect --format='{{.Created}}' '$image' 2>/dev/null" | cut -dT -f1)
  if [ -n "$CREATED" ]; then
    AGE_DAYS=$(( ($(date +%s) - $(date -d "$CREATED" +%s 2>/dev/null || echo 0)) / 86400 ))
    if [ "$AGE_DAYS" -gt 90 ]; then
      REPORT+="WARNING: $image is ${AGE_DAYS} days old (max. 90)\n"
    fi
  fi
done

# 6. Last Supabase update?
LAST_UPDATE=$(ssh deploy@${PROD_HOST} "cd /opt/supabase && git log --format='%ai' --grep='Update\|update' -1 2>/dev/null" | cut -d' ' -f1)
if [ -n "$LAST_UPDATE" ]; then
  UPDATE_AGE=$(( ($(date +%s) - $(date -d "$LAST_UPDATE" +%s)) / 86400 ))
  if [ "$UPDATE_AGE" -gt 45 ]; then
    REPORT+="WARNING: Last Supabase update ${UPDATE_AGE} days ago (max. 45)\n"
  fi
else
  REPORT+="WARNING: No update commit found in Git\n"
fi

# 7. Docker Engine version
DOCKER_VERSION=$(ssh deploy@${PROD_HOST} "docker version --format '{{.Server.Version}}' 2>/dev/null")
echo "Docker Engine: $DOCKER_VERSION"

# 8. Caddy version
CADDY_VERSION=$(ssh deploy@${PROD_HOST} "caddy version 2>/dev/null")
echo "Caddy: $CADDY_VERSION"

# 9. TLS certificate remaining validity
CERT_DAYS=$(ssh deploy@${PROD_HOST} "echo | openssl s_client -connect localhost:443 2>/dev/null | openssl x509 -noout -enddate 2>/dev/null | cut -d= -f2")
if [ -n "$CERT_DAYS" ]; then
  DAYS_LEFT=$(( ($(date -d "$CERT_DAYS" +%s) - $(date +%s)) / 86400 ))
  [ "$DAYS_LEFT" -lt 14 ] && REPORT+="CRITICAL: TLS certificate expires in ${DAYS_LEFT} days\n"
fi

# Result
if [ -n "$REPORT" ]; then
  echo -e "\n$REPORT"
  echo -e "$REPORT" | mail -s "Maintenance Check: Action required" ops@example.com
else
  echo "All maintenance checks passed"
fi
```

**Cron on the audit-runner:**

```bash
# Weekly Monday 08:00 (after the Sunday audit)
0 8 * * 1 /opt/audit/scripts/check-maintenance.sh >> /var/log/maintenance-check.log 2>&1
```

**When Claude notifies:**

Claude Code on the audit-runner sends notifications in three cases:

```
IMMEDIATE (email to ops@):
  - Unattended Upgrades not active
  - TLS certificate < 14 days
  - Security update pending and > 3 days old

WEEKLY (Maintenance Report):
  - Reboot required
  - apt update overdue
  - Supabase images > 60 days old

MONTHLY (Update Reminder):
  - Supabase release notes not reviewed (no update commit > 45 days)
  - Quarterly review due
```

## Conclusion

Self-hosting Supabase is relatively straightforward. **Operating Supabase securely** requires clear architecture rules and automated controls.

This runbook separates infrastructure decisions (Part A), service architecture and hardening (Part B), stack configuration (Part C), ongoing monitoring (Part D), and update processes (Part E). The combination of deterministic checks and contextual Claude Code analysis covers both known patterns and unexpected risks.

Teams that follow these principles from the start build a [cert-ready-by-design architecture](/en/magazine/cert-ready-by-design/) and avoid retroactive audit cycles.

> **Reminder:** The Hetzner-specific configurations (vSwitch, Cloud Firewall, interface names) translate directly to other EU hosting providers such as OVH (EU/UK), IONOS (EU/UK), and Scaleway (EU). The architecture principles are provider-agnostic.

<div class="not-prose my-12 border border-gosign-border bg-gosign-light rounded-card p-6 lg:p-8">
<div class="flex items-start gap-4">
<div class="flex-shrink-0 w-12 h-12 bg-gosign-dark rounded-card flex items-center justify-center">
<svg width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="white" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 15v4a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2v-4"/><polyline points="7 10 12 15 17 10"/><line x1="12" y1="15" x2="12" y2="3"/></svg>
</div>
<div>
<h2 class="text-h3 font-bold text-gosign-dark mb-2" id="audit-checklist-download">Audit Checklist Download</h2>
<p class="text-body text-gosign-text mb-2">Prepared prompt for Claude Code. Upload the file to your server and start Claude Code in your Supabase stack's project directory. Claude Code will automatically check all security points from this runbook and report PASS, WARNING, or CRITICAL.</p>
<p class="text-sm text-gosign-text mb-4 font-mono">claude -p "$(cat claude-check-artikel-1-supabase-en.md)" --allowedTools Read,Grep,Glob,Bash</p>
<a href="/downloads/claude-check-artikel-1-supabase-en.md" download class="inline-flex items-center px-6 py-3 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-small uppercase tracking-wider">Download checklist</a>
</div>
</div>
</div>

## Series Table of Contents

This article is part of our DevOps series for self-hosted app stacks.

1. Supabase Self-Hosting Runbook - this article
2. [Running Next.js on Supabase Securely](/en/magazine/nextjs-supabase-secure-setup/)
3. [Deploying Supabase Edge Functions Securely](/en/magazine/supabase-edge-functions-secure/)
4. [Running Trigger.dev Background Jobs Securely](/en/magazine/trigger-dev-background-jobs/)
5. [Claude Code as Security Control in DevOps Workflows](/en/magazine/claude-code-security-devops/)
6. [Security Baseline for the Entire Stack](/en/magazine/security-baseline-stack/)

The next article covers how to **run Next.js securely on Supabase** without making common mistakes with Server Actions, auth handling, and API access.

--- Three Types of Decisions: Human, Rules, or AI ---
> Not every decision needs a human. And not every decision should be left to AI. A framework for assignment - with concrete HR examples.

## The Question Every HR Department Asks

"Which decisions can AI make on its own - and which must stay with humans?"

This question comes up in every conversation about AI in HR. From the works council (Betriebsrat), from senior leadership, from compliance. And the usual answer - "AI supports, humans decide" - is too vague for productive use.

Because in practice, a single HR process consists of dozens of individual decisions. Take sick leave processing: is the document complete? Which collective agreement applies? Does the illness duration exceed the continued pay threshold? Does a return-to-work programme (BEM) need to be initiated? Who needs to be informed?

Some of these decisions need a human. Some don't. And some should consciously NOT rest with a human - because AI demonstrably makes them better.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">At a Glance - Three Types of Decisions</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Every business process decomposes into micro-decisions falling into three types: human decides, rule set applies, or AI decides autonomously.</li>
<li>AI autonomous is not the category for trivial tasks - it is for decisions where consistency, fatigue resistance, and completeness outweigh discretion.</li>
<li>AI outperforms humans structurally on three dimensions: identical results across locations, no quality drop from fatigue, and complete rule checking every time.</li>
<li>A single HR process like sick leave processing contains all three types - the Decision Layer enforces the correct assignment per step.</li>
<li>This framework makes the argument transparent for works councils: AI decides where quality demands it, humans decide where discretion demands it.</li>
</ul>
</div>

[McKinsey Global Institute (2023)](https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/the-economic-potential-of-generative-ai-the-next-productivity-frontier) estimates that 60 to 70 percent of today's working time is spent on activities that could be automated with current AI technology, but only decisions with clear rules and low discretion are suitable for full automation.

## Three Types of Decisions

### Type 1: Human Decides

Here, a human must make the final decision. The agent can prepare, suggest, compile materials - but the decision itself rests with the human.

**When:** Discretion required, discrimination risk, works council obligation, individual situations.

**Example: Return-to-work planning after long-term illness.** The agent has all the data: illness duration, return-to-work history, occupational health recommendations, available positions. But the decision about which reintegration model fits this specific person needs a human. It's about the individual situation, about empathy, about the conversation with the person. The works council (Betriebsrat) has co-determination rights (Mitbestimmung). And if the decision is wrong, it has real consequences for a real person.

**What the Decision Layer does:** It enforces human-in-the-loop. Architecturally, not organisationally. The agent cannot make this decision autonomously - even if its confidence is high.

### Type 2: Rule Set Applies

The decision is deterministic - there is no room for interpretation. The collective agreement states X, so X applies. A deadline expires on date Y, so rule Z triggers.

**When:** Collective agreements, works council agreements, tax legislation, pay grading, deadline calculations.

**Example: Pay grade classification.** New employee, job profile available, collective agreement is clear. The classification follows from the criteria in the collective agreement. There is nothing to interpret - it is rule application. The Decision Layer applies the current rule version and documents the result. Rule sets are versioned: every change creates a new version, previous versions remain traceable. Here, the agent is an executor - not because it cannot do more, but because there is nothing to interpret.

**What the Decision Layer does:** It ensures the current rule version is applied. When the collective agreement changes, the new version takes effect from the effective date - automatically, without someone needing to inform 50 specialists at 12 locations.

### Type 3: AI Decides Autonomously

And this is where it gets interesting. Because this category is usually told wrong. The standard narrative: "For simple standard cases, AI is also allowed to decide on its own." That sounds like permission for trivial tasks.

The reality is different. The agent makes independent decisions - because it is confident enough, has permission, and demonstrably performs the task better than manual processing. It interprets documents, classifies situations, evaluates context, and recognises patterns. This is not if-then-else - this is judgment within defined guardrails. Confidence Routing controls: high confidence and low risk leads to autonomous decision. Low confidence or high risk leads to escalation to a human.

There are decisions where AI is not just faster, but **demonstrably better** than a human. Not because AI is smarter - but because it lacks three structural weaknesses that humans have.

#### Advantage 1: Consistency Across Locations and People

50 specialists at 12 locations apply the same collective agreement. Each interprets edge cases slightly differently. In Hamburg, a special payment request is approved; in Munich, the identical case is rejected. This is not a training problem - it is the natural variance of human decision-making with ambiguous rules.

An AI operating on a versioned rule set decides identically. Every time. At every location. At 9 AM and at 4 PM.

**Concrete example:** Continued pay period calculation. Same case, same rule, same result. Not dependent on which specialist at which office handles the case.

#### Advantage 2: No Fatigue

A recruiter screens differently on Monday morning than on Friday afternoon. After the 50th application, attention drops. The second-to-last candidate was particularly strong - the next one seems weaker by comparison, even though they objectively meet the requirements (anchoring bias). The recruiter just received bad news - the next three assessments are harsher (affect heuristic).

These are not personal weaknesses. This is human cognition. Well-researched, extensively documented, and measurable in every repetitive decision process.

An AI evaluates application number 1 with the same rigour as application number 200. It does not have a bad day.

**Concrete example:** Requirement matching in recruiting. Every application is checked against the same criteria profile. Not influenced by the order of applications, not by the time of day, not by the recruiter's emotional state.

#### Advantage 3: Completeness in Rule Checking

This is the advantage that gets underestimated most.

An HR specialist checks a sick leave notification against three or four criteria that come to mind: illness duration, continued pay period, perhaps the return-to-work threshold. But do they also check the waiting period rule? The special provision for part-time employees in the company-specific agreement? The reporting obligation to the occupational health authority for certain conditions? The special case for workplace accidents? The rule for fixed-term contracts?

Every time? Also on Friday at 4 PM? Also when handling five other cases in parallel?

An AI checks against all applicable rules, in the current version, completely and documented. Not because it is smarter - but because it does not forget. And because its rule set is not stored in people's heads, but in a versioned system.

**Concrete example:** Sick leave processing. The agent checks every electronic sick note against all 12 relevant criteria from collective agreement, works council agreement, and law. Every time. The result: fewer errors that only surface at the next audit.

## Why a Single Process Contains All Three Types

The framework becomes practically useful when you understand: a single HR process almost always contains ALL three decision types.

Take sick leave processing as a continuous example:

| Step | Decision Type | Why |
|---|---|---|
| Receive and validate sick note data | **AI autonomous** | Document classification, high accuracy, structured input |
| Match against employee master data | Rule set | Deterministic, no interpretation |
| Check continued pay period | **AI autonomous** | Checks against ALL collective agreement criteria, more consistent than any specialist |
| Assess return-to-work obligation (>6 weeks in 12 months) | Human | Discrimination risk with health data, works council co-determination |
| Inform line manager | **AI autonomous** | Consistent information, no omissions, no interpretation needed for WHAT is communicated (only absence and duration, no diagnosis) |
| Initiate return-to-work measures | Human | Individual situation, discretion, works council involvement |

Note the third row: "Check continued pay period" is not under "Rule set" but under "AI autonomous". Why? Because the AI doesn't just apply simple if-then logic here - it performs the check COMPLETELY against all applicable rule sets. Something a human in practice never fully does, because they don't have all special provisions in their head.

That is the crucial point: "AI autonomous" is not the category for trivial tasks. It is the category for decisions where consistency, fatigue-resistance, and completeness matter more than discretion.

## What This Means for the Works Council

The works council (Betriebsrat) is often sceptical about AI autonomy. Rightly so - when it's unclear WHY AI decides autonomously.

With the three-types framework, the argument becomes transparent:

"AI decides autonomously for deadline calculations. Not because we want to cut headcount. But because we know that 50 specialists at 12 locations calculate the same deadline differently. AI always calculates correctly. And when it's not certain, it escalates to a human. That's traceable, documented, and visible in the auditor portal at any time."

That is an argument the works council understands. It's not about replacement - it's about quality assurance.

## The Decision Layer Makes the Assignment Operational

The framework remains theory if it's not technically enforced. The [Decision Layer](/en/decision-layer/) implements the three-types assignment for every process step:

For every micro-decision, it's defined: human, rule set, or AI. For AI decisions, it's documented why AI is the right choice. For human decisions, human-in-the-loop is architecturally enforced. For rule-set decisions, the current rule version is stored. Every decision - regardless of type - generates a decision act: input, rule including version, confidence, result, contestation path. That is the basis of contestability under Art. 86 of the EU AI Act.

→ [Decision Layer - Overview and Examples](/en/decision-layer/)

→ [The Decision Act: Why Every AI Decision Must Be Contestable](/en/magazine/decision-act-contestable-ai-decisions/)

→ [Why AI Projects in HR Fail](/en/magazine/why-ai-projects-fail/)

<a href="/en/contact/" target="_blank" rel="noopener noreferrer">Schedule a consultation</a> - We'll show you on your specific process which decisions stay with humans and which AI handles better.

--- Automating Travel Expenses: True Cost per Report ---
> $58 per report, 19% error rate, $52 per correction. GBTA data shows: manual expense processing costs enterprises millions - and it is avoidable.

## $58 per report - the number nobody tracks

Most finance departments know their travel costs. They know how much the organisation spends annually on flights, hotels and per diem allowances. What they rarely know: what does it cost to process a single expense report?

The answer comes from the GBTA Foundation in partnership with HRS: $58 per transaction when processed manually. The error rate stands at 19 percent. The correction cost per error is $52 (Source: GBTA Foundation / HRS, "Expense Reporting: Global Practices and Pain Points", 2015).

These three numbers shift the perspective. Travel expenses are not just a spend category - they are a process cost problem. And for enterprises with tens of thousands or hundreds of thousands of transactions per year, that problem adds up to millions.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">At a Glance - ROI of Travel Expense Automation</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Manual processing costs $58 per report with a 19% error rate and $52 per correction (GBTA Foundation data).</li>
<li>At 100,000 transactions per year, processing alone costs nearly $7 million - before actual travel spend.</li>
<li>OCR and approval workflows solve capture, not the 40 - 120 micro-decisions per transaction (per diems, collective agreements, tax treatment).</li>
<li>The Decision Layer approach achieves 85 - 95% zero-touch processing by applying versioned, auditable rules to every micro-decision.</li>
<li>Payback starts at 10,000 transactions per year; the biggest savings come from eliminating the correction loop, not cheaper clerks.</li>
</ul>
</div>

## The anatomy of the $58

### Visible costs: capture and approval

The employee photographs the receipt, enters the data into SAP Concur or a comparable tool, assigns a cost centre and submits. The manager reviews, approves or rejects. The clerk in the Shared Service Center checks again, validates against policy and posts.

Three people, three steps, one receipt. That is the visible part of the $58.

### Hidden costs: corrections and queries

A 19 percent error rate means nearly one in five transactions requires rework. Wrong per diem rate applied, meal deduction missed, incorrect collective agreement rate used, cost centre misassigned. Each correction costs $52 - the transaction goes through the entire process a second time.

Then come the queries: the clerk contacts the employee because information is missing. The employee searches for a receipt that is three weeks old. The manager is asked to approve a second time. These loops consume time that never appears in any cost accounting.

### Systemic costs: audit risk and compliance

When 19 percent of transactions contain errors and only samples are reviewed, systematic mistakes accumulate undetected. The risk materialises during a tax audit: the auditor does not ask about individual receipts but about the system behind them. Is there documented decision logic? Can it be traced why this per diem allowance was calculated at this rate?

In most enterprises, the answer is no. The decision logic resides in the clerk's head, not in the system. That is not audit-ready procedural documentation - it is an audit risk.

## Projections: what travel expenses really cost the enterprise

### Scenario A: 10,000 transactions per year (upper midmarket)

<div class="overflow-x-auto">

| Item | Calculation | Annual cost |
|------|------------|-------------|
| Processing | 10,000 x $58 | $580,000 |
| Corrections | 10,000 x 19% x $52 | $98,800 |
| **Total** | | **$678,800** |

</div>

At 10,000 transactions, expense processing occupies the equivalent of 3 to 4 full-time employees in the Shared Service Center. Correction costs alone account for half an FTE.

### Scenario B: 100,000 transactions per year (enterprise)

<div class="overflow-x-auto">

| Item | Calculation | Annual cost |
|------|------------|-------------|
| Processing | 100,000 x $58 | $5,800,000 |
| Corrections | 100,000 x 19% x $52 | $988,000 |
| **Total** | | **$6,788,000** |

</div>

Nearly $7 million per year - for processing alone, not for the actual travel spend. On top of that: at 100,000 transactions and a 19 percent error rate, 19,000 transactions are faulty. That is not residual risk - it is a systemic problem.

### Scenario C: 500,000+ transactions per year (logistics, airline)

<div class="overflow-x-auto">

| Item | Calculation | Annual cost |
|------|------------|-------------|
| Processing | 500,000 x $58 | $29,000,000 |
| Corrections | 500,000 x 19% x $52 | $4,940,000 |
| **Total** | | **$33,940,000** |

</div>

$34 million in processing costs per year. For airlines and logistics enterprises, where every employee inevitably travels (crew flies, drivers drive), this is not optional - these transactions are a by-product of the core business.

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Free eBook: AI in Finance</p>
<p class="text-body text-gosign-text mb-4">Compliance, external auditors, and Decision Layer - the governance handbook for finance leaders.</p>
<a href="/en/ebook/ai-finance-governance-handbook/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Download for free</a>
</div>

## Why OCR and approval workflows are not enough

The obvious answer to the cost problem: digitalisation. OCR for receipt capture, workflows for approval, apps for submission. This reduces manual effort in capture - but not in decision-making.

OCR captures the receipt. A workflow routes it to the right person. But who decides:

- Which per diem rate applies when the employee travelled through three countries?
- Whether the collective agreement overrides the statutory rate - and if so, which collective agreement?
- How the meal provision should be deducted when the hotel includes breakfast but the employee did not use it?
- Whether entertainment expenses are deductible at 70 percent (Germany) or 50 percent (Austria) - or follow entirely different rules in other jurisdictions?

These are not capture problems. They are rule application problems. And no OCR system and no approval workflow solves rule application problems.

## The difference between capture and governance

What is missing is the layer between receipt capture and posting: a governance layer that documents, for every transaction, which rule was applied and why.

The [Decision Layer](/en/magazine/decision-layer-explained/) breaks down every expense transaction into its micro-decisions and defines for each step: the applicable rule set, the hierarchy (statute before collective agreement before company policy) and the documentation. The decision is not made by a person acting on experience but by a versioned rule set that is traceable, reproducible and [audit-ready](/en/magazine/cert-ready-by-design/).

This also changes the operating model: instead of submit, approve, post (three manual steps), the transaction is processed automatically. The employee sees the result and has the right to object - the veto approach. Instead of manually reviewing every transaction, only exceptions are handled. That is the difference between zero percent and 85 to 95 percent zero-touch processing.

## Four industries, four ROI profiles

The [Travel Decision Layer](/en/services/travel-decision-layer/) works across industries. The automation rate varies by sector because input data is structured differently:

<div class="overflow-x-auto">

| Industry | Transactions per year | Zero-touch | Cost before | Cost after | Savings |
|----------|----------------------|------------|-------------|------------|---------|
| [Aviation](/en/services/travel-decision-layer/aviation/) | 100k - 1M+ | 95% | $58+ | < $10 | > 80% |
| [Logistics](/en/services/travel-decision-layer/logistics/) | 500k - 2M+ | 95% | $58+ | < $5 | > 90% |
| [Sales](/en/services/travel-decision-layer/sales/) | 120k+ | 90% | $58+ | < $8 | > 85% |
| [Consulting](/en/services/travel-decision-layer/consulting/) | 50k - 250k+ | 85% | $58+ | < $10 | > 80% |

</div>

The highest zero-touch rates are achieved by industries with machine-readable input data: GPS tracks in logistics, crew rotations in aviation. Consulting sits at 85 percent because multi-client weeks may require manual allocation.

The decisive factor for [ROI](/en/magazine/roi-ai-investments/) is not just per-transaction cost reduction but the elimination of the correction loop: moving from a 19 percent error rate to below 2 percent means the $52 correction cost effectively disappears.

## The veto approach: automation without losing control

A common objection to automation: "We lose control." The veto approach reverses the logic.

Today: the employee submits. The manager approves. The clerk posts. Three manual steps, each one error-prone.

With the Decision Layer: the system calculates the transaction automatically based on the stored rules. The employee sees the result and can raise an objection - within a defined period. Without objection, the transaction is posted automatically.

This is not less control. It is more control - documented, traceable, reproducible control. Instead of a subjective approval by a manager who may not know the collective agreement in detail, a rule set decides that can be inspected by [employee representation bodies](/en/magazine/works-council-ai-co-determination/) and verified by external auditors.

## When it pays off - and when it does not

Not every enterprise needs fully automated expense processing. The investment pays off when at least two of the following criteria apply:

- **Volume**: More than 10,000 expense transactions per year
- **Rule complexity**: Collective agreements, multi-jurisdiction operations or industry-specific rules
- **Audit requirements**: Audit trail-ready procedural documentation, tax audit preparedness
- **Shared Service Center**: Centralised processing with documented process quality

When the organisation only processes domestic travel without collective agreements, SAP Concur or a comparable tool is sufficient. The governance layer becomes relevant where the rules are complex enough that a clerk makes errors - precisely where the GBTA numbers show their full impact.

Gosign implements the [Travel Decision Layer](/en/services/travel-decision-layer/) on an industry-specific basis - from evaluation through a 3-month pilot to production operation. On your [infrastructure](/en/services/infrastructure/), without external SaaS dependency, with full source code access.

--- Enterprise Travel Expenses: SAP Concur Limits ---
> SAP Concur captures receipts - but who decides on collective agreements, per diems and IROP? Why enterprises need more than an expense tool.

## SAP Concur Is Good - for What It Was Built For

SAP Concur is the world's most widely used travel expense software. Receipt capture via mobile app, approval workflows, integration with SAP systems - for organisations with standardised domestic travel, it works reliably.

The problem starts where standard processes end. For enterprises operating across collective agreements, multiple jurisdictions and industry-specific complexity, every pure capture tool hits its limits - not just Concur, but also Circula, Rydoo or HR Works.

The reason: these tools solve the capture problem. Not the decision problem.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">At a Glance - SAP Concur Limits in Enterprise Travel Expenses</p>
<ul class="text-body text-gosign-text space-y-2">
<li>SAP Concur solves receipt capture, not the 40 - 120 micro-decisions behind every transaction (collective agreements, multi-jurisdiction per diems, IROP recalculation).</li>
<li>Manual processing costs $58 per transaction with 19% errors and $52 per correction (GBTA Foundation) - at 100k crew transactions, that is $6.8M per year.</li>
<li>Collective agreements, multi-country border crossings and irregular operations lie outside the data model of every standard expense tool.</li>
<li>The Decision Layer sits on top of SAP Concur as a governance layer - versioned rules, deterministic calculation, gapless Audit Trail.</li>
<li>Result: 95% zero-touch processing, error rate below 1%, cost per transaction under $10 - without replacing any existing system.</li>
</ul>
</div>

## The Decision Problem: 40 to 120 Micro-Decisions per Transaction

A travel expense report is not receipt capture. Behind every transaction sit 40 to 120 micro-decisions:

- Which per diem rate applies (government rate schedule, valid on the travel date)?
- Does a collective agreement override the statutory rate?
- How are meal deductions calculated (breakfast, lunch, dinner)?
- Which cost centre bears the transaction?
- What is the tax treatment (tax-exempt, flat-rate taxed, fully taxable)?
- What happens when the itinerary changes mid-trip?

SAP Concur captures the receipt. But who makes these decisions? In most enterprises: a clerk in the Shared Service Center, manually, per transaction, without documented decision logic.

That is expensive. The GBTA Foundation puts the average cost per manually processed travel expense report at $58 - with an error rate of 19 percent and correction costs of $52 per error (source: GBTA Foundation / HRS, "Expense Reporting: Global Practices and Pain Points", 2015).

## Where Standard Expense Tools Hit Their Limits

### Collective Agreements Override Statutory Rates

Government per diem rates set the statutory baseline. Under German law, that means EUR 14 for arrival days and EUR 28 for full absence days domestically (2026 rates). Under Nordic collective frameworks, separate per diem structures exist entirely. Many collective agreements define higher rates - sometimes significantly so.

An airline group with 10,000 crew members typically maintains 2 to 5 parallel collective agreements: cockpit, cabin, ground staff, maintenance. Each agreement defines its own per diem rates, its own deduction rules, its own exceptions for provided meals.

SAP Concur has no concept of collective agreements. The software calculates using statutory rates - or a single company-wide flat rate. The agreement-compliant calculation of per diem allowances happens outside the tool: manually, in spreadsheets, or through clerks in the Shared Service Center who transfer the result back into the system by hand.

This is not just inefficient. It is error-prone. When the clerk applies the wrong collective agreement to crew group 3, systematic errors emerge that go undetected across thousands of transactions - until the next tax audit.

### Multi-Jurisdiction in a Single Transaction

A crew member on a European route touches 3 to 5 countries in a single day. The per diem rate depends on the country where the travel day ends, or on the midnight rule for multi-day trips. Standard expense tools calculate one country per trip. Multi-jurisdiction within a single transaction - with border crossings tracked to the minute - lies outside their data model.

This is not limited to airlines:

- **Logistics**: Drivers cross multiple borders daily. The per diem rate changes at every border, and calculation must be precise to the minute - particularly for midnight crossings. Add the documentation requirements of the [EU Mobility Package](/en/services/travel-decision-layer/logistics/) (Directive 2020/1057).
- **Sales**: Field representatives visit clients across multiple countries per week. Monday Vienna, Wednesday Zurich, Friday Munich - three jurisdictions, three per diem rates, one transaction.
- **Consulting**: Consultants work in rotating engagements. A weekly rhythm with three clients in two countries creates splitting requirements that no standard tool can map.

### Irregular Operations and Unplanned Changes

10 to 20 percent of all flights are affected by irregularities - delays, diversions, crew repositioning (source: EUROCONTROL / US DOT BTS, 2024). Every irregularity changes the expense calculation: different per diem due to a different destination country, different accommodation entitlement, different cost centre.

No standard expense tool processes irregular operations (IROP) automatically. The correction happens manually - if it is recognised at all. With 100,000 crew transactions per year and an IROP rate of 15 percent, that means 15,000 transactions requiring manual rework. Each one carrying the risk that the correction itself is erroneous.

### The Governance Gap

SAP Concur documents what was submitted. It does not document why a decision was made. That is the difference between a capture tool and a governance layer.

When the tax auditor asks: "What rule was applied to calculate this per diem?" - Concur has no answer. The amount is in the system, the decision logic is not. When [employee representation bodies](/en/governance/co-determination/) ask: "How are travel expense decisions being made?" - the honest answer in most enterprises is: the clerk decides based on experience.

That is not an Audit Trail. That is person-dependency.

## Simulation: 100,000 Crew Transactions per Year

### The Baseline

For an airline group processing 100,000 crew transactions per year, the GBTA data yields:

<div class="overflow-x-auto">

| Item | Calculation | Annual Cost |
|------|------------|-------------|
| Processing | 100,000 x $58 | $5,800,000 |
| Corrections | 100,000 x 19% x $52 | $988,000 |
| **Total** | | **$6,788,000** |

</div>

Not included: approver time costs (managers reviewing receipts instead of leading), month-end bottlenecks in accounting, audit risk during tax audits, and employee frustration from delayed reimbursements.

### The Decision Layer Approach

The [Travel Decision Layer](/en/services/travel-decision-layer/) breaks every travel expense transaction into its micro-decisions and applies documented rules to each one: statutory law, collective agreement, company policy - in that hierarchy, versioned, traceable.

Rule application is deterministic. No stochastic language model decides on amounts or tax treatment. AI is used for classification - identifying receipt types, categorising IROP types, classifying entertainment purposes - but the calculation follows exact rules. For a deeper understanding of how the [Decision Layer architecture](/en/magazine/decision-layer-explained/) separates classification from calculation, see our foundational article.

For the [aviation simulation](/en/services/travel-decision-layer/aviation/), the comparison looks like this:

<div class="overflow-x-auto">

| Metric | Manual | With Decision Layer |
|--------|--------|---------------------|
| Cost per transaction | $58+ | < $10 |
| Error rate | 19% | < 1% |
| Processing time | 5 - 12 business days | Minutes |
| Zero-touch rate | 0% | 95% |
| Audit readiness | Manual reconstruction | Automatically generated |
| Collective agreement change | Weeks | < 24 hours |

</div>

Projection at 100,000 transactions: from $6.8M to under $1M per year. The savings do not come from cheaper clerks, but from eliminating manual decisions.

### The Decision Flow in Detail

A single crew transaction passes through the following steps in the Decision Layer:

1. Ingest rotation data from the crew planning system
2. Determine country sequence from the rotation data
3. Look up per diem rate per country and day (government rate schedule, valid on the travel date)
4. Check collective agreement override (crew group, validity period)
5. Calculate meal deductions (breakfast, lunch, dinner - per day)
6. Classify IROP type (AI-assisted) and recalculate per diem
7. Validate hotel costs against policy (cap per city)
8. Assign cost centre (rotation, fleet, crew group)
9. Determine tax treatment (tax-exempt, flat-rate, fully taxable)
10. Generate audit record (SHA-256 signed, append-only)

Each of these steps is a documented decision with a traceable rule basis. That is the difference from an approval workflow where a human clicks "Approved" without the decision logic being recorded in the system. This [Cert-Ready by Design](/en/magazine/cert-ready-by-design/) approach ensures audit readiness is structural, not reconstructed.

## Four Industries, Four Complexity Levels

The Travel Decision Layer is not limited to aviation. The core architecture - a deterministic rule engine over micro-decisions - works across industries with industry-specific configuration:

<div class="overflow-x-auto">

| Industry | Transactions per Year | Zero-Touch | Core Complexity |
|----------|----------------------|------------|-----------------|
| [Aviation](/en/services/travel-decision-layer/aviation/) | 100k - 1M+ | 95% | IROP + multi-collective agreement |
| [Logistics](/en/services/travel-decision-layer/logistics/) | 500k - 2M+ | 95% | GPS precision + EU Mobility Package |
| [Sales](/en/services/travel-decision-layer/sales/) | 120k+ | 90% | CRM integration + entertainment expenses |
| [Consulting](/en/services/travel-decision-layer/consulting/) | 50k - 250k+ | 85% | 3-way split (tax / client / internal) |

</div>

All four simulations are based on the same GBTA baseline ($58 per transaction, 19% error rate) and show industry-specific optimisation potential. The different zero-touch rates reflect industry complexity: logistics and aviation reach 95 percent because input data (GPS tracks, crew rotations) is machine-readable. Consulting sits at 85 percent because multi-client weeks may require manual allocation.

## What a Solution Needs to Complement SAP Concur

SAP Concur does not need to be replaced. What is missing is the layer above it - the governance layer that decides before the receipt enters the system:

1. **Collective-agreement-native rule engine** - Collective agreements not as a workaround, but as a first-class concept. Configurable per employee group, with validity periods and override hierarchy.
2. **Versioned decision tables** - Every rule dated, every change traceable. Government per diem rates, collective agreement rates and company policies as dated changesets.
3. **Gapless Audit Trail** - Every micro-decision signed (SHA-256), stored in an append-only process. No overwriting, no deletion, fully reproducible.
4. **[Employee representation-compatible](/en/governance/co-determination/) transparency** - The rule set is inspectable, the decision logic traceable. No black-box AI decides on amounts. Under German co-determination law (Betriebsverfassungsgesetz), works councils have co-determination rights over automated monitoring systems - the Decision Layer's transparency satisfies even the strictest model.
5. **ERP integration** - No system replacement, but input into existing ERP and payroll (UK: PAYE) systems. The Decision Layer sits between data source and booking system.
6. **Multi-jurisdiction per transaction** - Not per trip, but per day, with border crossings tracked to the minute.

Gosign implements this governance layer as the [Travel Decision Layer](/en/services/travel-decision-layer/) - configured for your industry, on your [infrastructure](/en/services/infrastructure/), without external SaaS dependency.

--- Running Trigger.dev Background Jobs Securely ---
> DevOps runbook for Trigger.dev v3: self-hosted setup, task definition, idempotency, concurrency, secrets, and Claude Code integration.

Once an application goes beyond simple CRUD operations, tasks emerge that **should not run synchronously in the request-response cycle**: email delivery, webhook processing, import/export jobs, AI tasks, PDF generation, data migration, and periodic tasks.

These tasks do **not belong in [Next.js Server Actions](/en/magazine/nextjs-supabase-secure-setup/)** (they block the web server), **not in [Supabase Edge Functions](/en/magazine/supabase-edge-functions-secure/)** (timeout limits, no long-running tasks), and not in cron jobs on the server (no retry logic, no monitoring).

They belong in a **dedicated job layer**. In our stack, **Trigger.dev** fills this role.

This runbook describes how to operate Trigger.dev securely within the stack. Every step contains a concrete implementation using the current Trigger.dev v3 API, a verifiable condition, and a failure scenario.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">At a Glance - Part 4 of 6 in the DevOps Runbook Series</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Trigger.dev runs as a separate Docker stack with its own PostgreSQL instance</li>
<li>Every task requires maxDuration, concurrencyLimit, and retry configuration</li>
<li>Idempotency keys on all external API calls (Stripe, SendGrid, etc.)</li>
<li>Database access via service_role scoped to only required fields</li>
<li>Trigger.dev logger instead of console.log (logs persist in dashboard)</li>
</ul>
</div>

> **Note on architecture:** Trigger.dev consists of two parts: the **Platform** (webapp, dashboard, queue management) and the **Worker** (executes your tasks). We run both self-hosted on our own infrastructure. This runbook exclusively describes the self-hosted setup with Trigger.dev v3.

## Series Table of Contents

This guide is part of our DevOps runbook series for self-hosted app stacks.

1. [Supabase Self-Hosting Runbook](/en/magazine/supabase-self-hosting/)
2. [Running Next.js on Supabase Securely](/en/magazine/nextjs-supabase-secure-setup/)
3. [Deploying Supabase Edge Functions Securely](/en/magazine/supabase-edge-functions-secure/)
4. [Running Trigger.dev Background Jobs Securely](/en/magazine/trigger-dev-background-jobs/) - this article
5. [Claude Code as Security Control in DevOps Workflows](/en/magazine/claude-code-security-devops/)
6. [Security Baseline for the Entire Stack](/en/magazine/security-baseline-stack/)

Article 1 covers the platform. Article 2 covers the app layer. Article 3 covers integrations. This article covers **asynchronous job processing**.

## Architecture Overview

```
Browser
   |
Next.js (App Layer)
   |
   +-- tasks.trigger("send-email", payload)    <- start job
   |
Trigger.dev Platform
   |
   +-- Queue Management
   +-- Retry Logic
   +-- Dashboard / Monitoring
   |
Trigger.dev Worker
   |
   +-- send-email.ts           -> SMTP API
   +-- generate-report.ts      -> PDF + Supabase Storage
   +-- process-webhook.ts      -> Supabase DB (service_role)
   +-- sync-crm.ts             -> external CRM API
   |
   +-- Supabase (via service_role or direct DB connection)
       |
       PostgreSQL
```

Ground rules:

```
User Request       -> Next.js Server Action / Route Handler
Short Event        -> Supabase Edge Function
Long-Running Task  -> Trigger.dev Task
Periodic Task      -> Trigger.dev Scheduled Task
```

### Critical Security Point

Trigger.dev tasks typically have **full database access without RLS**. They connect either via the `service_role` key (through the Supabase client) or via a direct PostgreSQL connection (through `DATABASE_URL`). In both cases, Row Level Security policies do not apply. This is the most important difference from requests that go through PostgREST with the `anon` key.

Those familiar with the [fundamentals of secrets management](/en/magazine/data-security-ai-enterprise/) understand why this separation is essential.

Studies show that 35% of all background job failures are caused by missing idempotency on retries (Temporal.io Reliability Report 2024).

### Task Configuration Guide

| Task Type | maxDuration | concurrencyLimit | Retry Strategy |
|-----------|-------------|-----------------|---------------|
| Send email | 30s | 5-10 | 3x, exponential |
| Generate PDF | 120s | 2-3 | 3x, exponential |
| AI inference (LLM) | 300s | 1-3 | 2x, exponential |
| Database migration | 600s | 1 | 1x, no retry |
| Process webhook | 30s | 10 | 3x, exponential |
| CRM sync | 60s | 3-5 | 5x, exponential |

## Part A - Architecture Decisions

## A1 - Run Trigger.dev v3 Self-Hosted as a Separate Service

### Implementation

Trigger.dev runs separately from Next.js and Supabase as its own Docker stack. The self-hosted v3 architecture consists of three components:

```
Next.js App (your Hetzner / OVH server)
   |
   +-- Trigger.dev Platform (Webapp + Queue + Dashboard)
           |
           +-- Trigger.dev Worker (executes your tasks)
           |
           +-- Trigger.dev PostgreSQL (dedicated DB instance)
```

```yaml
# docker-compose.trigger.yml
services:
  trigger-platform:
    image: ghcr.io/triggerdotdev/trigger.dev:v3    # Version pinnen
    restart: unless-stopped
    ports:
      - "127.0.0.1:3040:3040"        # NUR localhost, Reverse Proxy davor
    environment:
      DATABASE_URL: postgresql://postgres:${TRIGGER_DB_PASSWORD}@trigger-db:5433/trigger
      DIRECT_URL: postgresql://postgres:${TRIGGER_DB_PASSWORD}@trigger-db:5433/trigger
      LOGIN_ORIGIN: https://trigger.example.com
      APP_ORIGIN: https://trigger.example.com
      MAGIC_LINK_SECRET: ${MAGIC_LINK_SECRET}
      SESSION_SECRET: ${SESSION_SECRET}
      ENCRYPTION_KEY: ${ENCRYPTION_KEY}
      RUNTIME_PLATFORM: docker-compose
      # Worker-Konfiguration
      DOCKER_SOCKET_LOCATION: /var/run/docker.sock
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock   # Worker-Management
    depends_on:
      trigger-db:
        condition: service_healthy
    networks:
      - trigger-internal

  trigger-db:
    image: postgres:15
    restart: unless-stopped
    ports:
      - "127.0.0.1:5433:5432"        # Port 5433, NICHT 5432 (Supabase nutzt 5432)
    environment:
      POSTGRES_PASSWORD: ${TRIGGER_DB_PASSWORD}
      POSTGRES_DB: trigger
    volumes:
      - trigger-db-data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 10s
      timeout: 5s
      retries: 5
    networks:
      - trigger-internal

volumes:
  trigger-db-data:

networks:
  trigger-internal:
    driver: bridge
```

**Important:** Trigger.dev needs its **own PostgreSQL instance** on port 5433. Do not share the Supabase database (port 5432). Trigger.dev stores queue status, run history, worker state, and metadata in its DB. This is different data from your application data.

**Configuring the SDK in the Next.js project:**

```bash
# Trigger.dev SDK installieren
npm install @trigger.dev/sdk@3

# .env (Next.js)
TRIGGER_SECRET_KEY=tr_dev_...              # aus dem self-hosted Dashboard
TRIGGER_API_URL=http://localhost:3040      # lokale Platform URL
```

**Worker Deployment:**

In the self-hosted v3 setup, you deploy tasks via the CLI, which communicates with your local platform:

```bash
# Tasks deployen (zeigt auf eure self-hosted Platform)
npx trigger.dev@latest deploy --self-hosted

# Lokale Entwicklung
npx trigger.dev@latest dev
```

> **Note:** The v3 Docker worker uses Docker-in-Docker (socket mounting). This means the Trigger.dev platform needs access to the Docker socket (`/var/run/docker.sock`). This has security implications: a compromised Trigger.dev container could start arbitrary Docker containers. Therefore, Trigger.dev should ideally run on a dedicated server or in an isolated Docker network.

### Verifiable Condition

```bash
# Container laufen?
docker compose -f docker-compose.trigger.yml ps
# Erwartung: trigger-platform und trigger-db running

# Platform erreichbar (intern)?
curl -s -o /dev/null -w "%{http_code}" http://localhost:3040
# Erwartung: 200 oder 302 (Redirect zu Login)

# Platform von außen NICHT direkt erreichbar?
curl -s -o /dev/null -w "%{http_code}" https://trigger.example.com:3040
# Erwartung: Connection refused (nur über Reverse Proxy)

# Trigger.dev DB auf eigenem Port?
ss -tlnp | grep 5433
# Erwartung: Listening auf 127.0.0.1:5433

# Supabase DB auf anderem Port?
ss -tlnp | grep 5432
# Erwartung: Listening auf 10.0.1.10:5432 (internes Interface)

# Docker Socket gemountet?
docker compose -f docker-compose.trigger.yml exec trigger-platform ls -la /var/run/docker.sock
# Erwartung: Socket vorhanden
```

### Failure Scenario

If Trigger.dev runs in the same process as Next.js, long-running tasks block the web server. An AI task that takes 5 minutes occupies a Next.js worker. With only a few worker threads (default: 1 per CPU), the entire app becomes unresponsive for users. If Trigger.dev shares the Supabase database, job queue queries compete with user requests for database connections. If the Docker socket is mounted without network isolation, a compromised task can start containers that access the host network.

## A2 - Control Database Access from Tasks

### Implementation

Tasks need access to your application data in Supabase. There are two approaches:

**Approach 1: Supabase client with service_role (recommended)**

```typescript
// trigger/lib/supabase.ts
import { createClient } from '@supabase/supabase-js'

export function createTaskClient() {
  return createClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.SUPABASE_SERVICE_ROLE_KEY!
  )
}
```

Advantage: Goes through PostgREST, uses the Supabase API layer.
Disadvantage: Bypasses RLS (service_role).

**Approach 2: Direct DB connection (for complex queries)**

```typescript
// trigger/lib/db.ts
import postgres from 'postgres'

const sql = postgres(process.env.DATABASE_URL!, {
  max: 5,                    // Connection Pool limitieren
  idle_timeout: 20,
  connect_timeout: 10,
})

export { sql }
```

Disadvantage: Bypasses both RLS and PostgREST. Full DB access.

**Rule:** Regardless of the approach, the task has more privileges than a normal user request. Therefore, every task must clearly define its own scope.

```typescript
// RICHTIG: Task greift nur auf das zu, was er braucht
const { data } = await supabase
  .from('invoices')
  .select('id, amount, user_id')
  .eq('id', payload.invoiceId)
  .single()

// FALSCH: Task liest alle Daten einer Tabelle
const { data } = await supabase
  .from('invoices')
  .select('*')
```

Those familiar with the [RLS patterns from the Supabase Self-Hosting Runbook](/en/magazine/supabase-self-hosting/) understand why the scope difference is critical.

### Verifiable Condition

```bash
# Welche Tasks nutzen service_role oder DATABASE_URL?
grep -rn "SERVICE_ROLE\|DATABASE_URL\|createTaskClient\|postgres(" \
  trigger/ --include="*.ts"

# Für jeden Treffer manuell prüfen:
# - Greift der Task nur auf die Daten zu, die er braucht?
# - Ist der Input validiert bevor er in die Query fließt?
# - Gibt es einen Grund für direkten DB-Zugriff statt Supabase Client?
```

### Failure Scenario

A task with direct DB access and unvalidated input can lead to SQL injection. A task that runs `SELECT *` on large tables can degrade database performance for all users. An uncontrolled connection pool (no `max` limit) can consume all available PostgreSQL connections and bring the entire application to a halt.

## Part B - Implementation Checks

These rules apply to every task and must be verified with each deployment.

## B1 - Define Tasks Correctly (v3 API)

### Implementation

Trigger.dev v3 uses the `task()` function from `@trigger.dev/sdk/v3`. Each task is exported and has a unique ID.

```typescript
// trigger/tasks/send-welcome-email.ts
import { task } from '@trigger.dev/sdk/v3'
import { z } from 'zod'
import { createTaskClient } from '../lib/supabase'

// 1. Payload Schema definieren
const payloadSchema = z.object({
  userId: z.string().uuid(),
  email: z.string().email(),
})

export const sendWelcomeEmail = task({
  id: 'send-welcome-email',

  // 2. Retry-Strategie
  retry: {
    maxAttempts: 3,
    factor: 2,
    minTimeoutInMs: 1_000,
    maxTimeoutInMs: 30_000,
  },

  // 3. Concurrency begrenzen
  queue: {
    concurrencyLimit: 5,
  },

  // 4. Maximum Laufzeit
  maxDuration: 60,   // 60 Sekunden

  // 5. Run-Funktion
  run: async (payload) => {
    // Input validieren
    const parsed = payloadSchema.safeParse(payload)
    if (!parsed.success) {
      throw new Error(`Invalid payload: ${parsed.error.message}`)
    }

    const { userId, email } = parsed.data
    const supabase = createTaskClient()

    // User-Daten holen (nur was nötig ist)
    const { data: user } = await supabase
      .from('profiles')
      .select('full_name, locale')
      .eq('id', userId)
      .single()

    if (!user) {
      throw new Error(`User not found: ${userId}`)
    }

    // E-Mail senden
    const response = await fetch('https://api.sendgrid.com/v3/mail/send', {
      method: 'POST',
      headers: {
        'Authorization': `Bearer ${process.env.SENDGRID_API_KEY}`,
        'Content-Type': 'application/json',
      },
      body: JSON.stringify({
        personalizations: [{ to: [{ email }] }],
        from: { email: 'hello@example.com' },
        subject: `Willkommen, ${user.full_name}!`,
        content: [{ type: 'text/plain', value: `...` }],
      }),
    })

    if (!response.ok) {
      // Fehler werfen, damit Retry greift
      throw new Error(`SendGrid error: ${response.status}`)
    }

    // Status in DB aktualisieren
    await supabase
      .from('profiles')
      .update({ welcome_email_sent: true })
      .eq('id', userId)

    return { success: true, userId }
  },
})
```

### Triggering a Task from Next.js

```typescript
// app/actions/auth.ts
'use server'

import { tasks } from '@trigger.dev/sdk/v3'
import type { sendWelcomeEmail } from '@/trigger/tasks/send-welcome-email'

export async function onUserSignup(userId: string, email: string) {
  // Task triggern (kehrt sofort zurück)
  const handle = await tasks.trigger<typeof sendWelcomeEmail>(
    'send-welcome-email',
    { userId, email }
  )

  // handle.id enthält die Run-ID für Tracking
  return { triggered: true, runId: handle.id }
}
```

### Verifiable Condition

```bash
# Alle Tasks müssen exportiert sein
for file in trigger/tasks/*.ts; do
  if ! grep -q "export const" "$file"; then
    echo "WARNUNG: $file hat keinen exportierten Task"
  fi
done

# Alle Tasks müssen eine ID haben
grep -rn "id:" trigger/tasks/ --include="*.ts" | grep "task({" -A1

# Tasks dürfen NICHT aus Client-Code getriggert werden
grep -rn "tasks.trigger\|\.trigger(" app/ --include="*.tsx" | grep -v "use server"
# Erwartung: keine Treffer (nur in Server-Kontext)
```

### Failure Scenario

A task without `export` is not recognized by Trigger.dev and silently disappears during deployment without an error message. A task without a `retry` configuration uses the default (no retry), so a temporary API error (e.g., a SendGrid timeout) leads to permanent loss of the email.

## B2 - Ensure Idempotency

### Implementation

Trigger.dev has a built-in idempotency system via `idempotencyKey`. This is preferable to a self-built `findUnique` check.

**When triggering (prevents duplicate triggering):**

```typescript
// Wenn derselbe User zweimal schnell "Signup" klickt,
// wird der Task nur einmal ausgeführt
await tasks.trigger<typeof sendWelcomeEmail>(
  'send-welcome-email',
  { userId, email },
  {
    idempotencyKey: `welcome-email-${userId}`,
    idempotencyKeyTTL: '24h',     // Key gilt 24 Stunden
  }
)
```

**Inside the task (prevents duplicate side effects on retries):**

```typescript
import { task, idempotencyKeys } from '@trigger.dev/sdk/v3'

export const processPayment = task({
  id: 'process-payment',
  retry: { maxAttempts: 3 },

  run: async (payload: { orderId: string; amount: number }) => {
    // Idempotency Key für den Stripe-Call
    // Bei Retry wird der Stripe-Call NICHT wiederholt
    const stripeKey = await idempotencyKeys.create(
      `stripe-charge-${payload.orderId}`
    )

    const charge = await stripe.charges.create(
      {
        amount: payload.amount,
        currency: 'eur',
        source: 'tok_...',
      },
      { idempotencyKey: stripeKey }
    )

    // DB-Update ist idempotent (upsert statt insert)
    await supabase
      .from('payments')
      .upsert({
        order_id: payload.orderId,
        stripe_charge_id: charge.id,
        status: 'completed',
      }, { onConflict: 'order_id' })

    return { chargeId: charge.id }
  },
})
```

### Verifiable Condition

```bash
# Tasks mit externen API-Calls sollten Idempotency Keys haben
for file in trigger/tasks/*.ts; do
  if grep -qE "fetch\(|stripe\.|sendgrid\.|resend\." "$file"; then
    if ! grep -qE "idempotencyKey|idempotencyKeys" "$file"; then
      echo "WARNUNG: $file hat externe API-Calls ohne Idempotency Key"
    fi
  fi
done
```

### Failure Scenario

Without idempotency protection when triggering, a duplicate webhook (Stripe retries on timeout) can trigger the same task twice. Without idempotency inside the task, a retry after a partial failure can cause double payments or duplicate emails.

## B3 - Configure Timeouts and Concurrency Correctly

### Implementation

Trigger.dev v3 supports `maxDuration` (runtime limit per task) and `concurrencyLimit` (parallel executions). Both must be set deliberately for each task.

```typescript
import { task, queue } from '@trigger.dev/sdk/v3'

// Shared Queue für E-Mail-Tasks (verhindert SMTP Rate Limiting)
const emailQueue = queue({
  name: 'email-processing',
  concurrencyLimit: 5,       // max. 5 parallele E-Mail-Tasks
})

export const sendEmail = task({
  id: 'send-email',
  queue: emailQueue,
  maxDuration: 30,            // 30 Sekunden max

  run: async (payload) => {
    // ...
  },
})

// AI-Tasks brauchen mehr Zeit, aber weniger Parallelität
export const analyzeDocument = task({
  id: 'analyze-document',
  queue: { concurrencyLimit: 2 },   // max. 2 parallele AI-Calls
  maxDuration: 300,                  // 5 Minuten max

  run: async (payload) => {
    // ...
  },
})

// Kritische Tasks die sequentiell laufen müssen
export const processInvoice = task({
  id: 'process-invoice',
  queue: { concurrencyLimit: 1 },    // strikt sequentiell
  maxDuration: 60,

  run: async (payload) => {
    // ...
  },
})
```

**Reference values:**

```
Email delivery:       maxDuration 30s,    concurrency 5-10
PDF generation:       maxDuration 120s,   concurrency 2-3
AI inference (LLM):   maxDuration 300s,   concurrency 1-3
Database migration:   maxDuration 600s,   concurrency 1
Webhook processing:   maxDuration 30s,    concurrency 10
```

### Verifiable Condition

```bash
# Alle Tasks müssen maxDuration haben
for file in trigger/tasks/*.ts; do
  if ! grep -q "maxDuration" "$file"; then
    echo "WARNUNG: $file hat kein maxDuration"
  fi
done

# Alle Tasks müssen concurrencyLimit haben (oder eine shared Queue nutzen)
for file in trigger/tasks/*.ts; do
  if ! grep -qE "concurrencyLimit|queue:" "$file"; then
    echo "WARNUNG: $file hat kein Concurrency Limit"
  fi
done
```

### Failure Scenario

Without `maxDuration`, a task can run indefinitely on a hanging API call, permanently blocking a worker slot. Without `concurrencyLimit`, 100 simultaneously triggered email tasks can overwhelm the SMTP provider and lead to rate limiting. Without a concurrency limit on DB-intensive tasks, all PostgreSQL connections can be consumed at once.

## B4 - Secrets and Environment Variables

### Implementation

Trigger.dev tasks run in a separate environment. Secrets must be explicitly passed through the Docker Compose configuration.

```bash
# .env.trigger (nur auf dem Server, nicht im Git)
TRIGGER_DB_PASSWORD=...
MAGIC_LINK_SECRET=...
SESSION_SECRET=...
ENCRYPTION_KEY=...

# Secrets für eure Tasks (werden an Worker weitergereicht)
SUPABASE_SERVICE_ROLE_KEY=eyJ...
DATABASE_URL=postgresql://...
SENDGRID_API_KEY=SG.xxx
OPENAI_API_KEY=sk-xxx
STRIPE_SECRET_KEY=sk_live_xxx
```

Task secrets are passed to worker containers in the self-hosted setup through the Trigger.dev dashboard (environment variables) or through the Docker environment.

In code:

```typescript
// RICHTIG: Environment Variable
const apiKey = process.env.SENDGRID_API_KEY

// FALSCH: Hardcoded
const apiKey = 'SG.xxx...'
```

### Verifiable Condition

```bash
# Hardcoded Secrets?
grep -rn "sk_live\|sk_test\|SG\.\|sk-\|Bearer ey" \
  trigger/ --include="*.ts"
# Erwartung: keine Treffer

# .env.trigger nicht im Git?
git ls-files .env.trigger
# Erwartung: leer

# Alle benötigten Env Vars gesetzt?
for var in SUPABASE_SERVICE_ROLE_KEY SENDGRID_API_KEY; do
  if [ -z "${!var}" ]; then
    echo "FEHLT: $var"
  fi
done
```

### Failure Scenario

Secrets in task files end up in the Git repository and in the build artifact (worker image). In the self-hosted setup, worker images are built and stored locally. Hardcoded secrets in these images are visible to anyone with access to the Docker host or the registry.

## B5 - Error Handling and Logging

### Implementation

Tasks must handle errors cleanly and must not log sensitive data.

```typescript
import { task, logger } from '@trigger.dev/sdk/v3'

export const processOrder = task({
  id: 'process-order',

  retry: {
    maxAttempts: 3,
    factor: 2,
    minTimeoutInMs: 1_000,
    maxTimeoutInMs: 30_000,
  },

  run: async (payload: { orderId: string }) => {
    // Trigger.dev Logger (strukturiert, im Dashboard sichtbar)
    logger.info('Processing order', { orderId: payload.orderId })

    try {
      const result = await processOrderInternal(payload.orderId)

      logger.info('Order processed', {
        orderId: payload.orderId,
        status: result.status,
      })

      return result

    } catch (error) {
      // Strukturiert loggen (ohne sensible Details)
      logger.error('Order processing failed', {
        orderId: payload.orderId,
        errorMessage: error instanceof Error ? error.message : 'Unknown error',
        // NICHT: error.stack, payload Details, User-Daten
      })

      // Fehler weiterwerfen, damit Retry greift
      throw error
    }
  },

  // onFailure Hook: wird nach allen Retries aufgerufen
  onFailure: async (payload, error, params) => {
    logger.error('Order permanently failed after all retries', {
      orderId: payload.orderId,
      attemptNumber: params.run.attemptNumber,
    })

    // Alert senden (z.B. Slack Notification)
    await sendAlertToOps({
      task: 'process-order',
      orderId: payload.orderId,
      error: error.message,
    })
  },
})
```

**What must NOT be logged:**

```typescript
// FALSCH
logger.info('Processing user', { user })             // vollständiges User-Objekt
logger.info('API call', { headers: req.headers })     // Auth-Header mit Token
logger.info('DB query', { connectionString })         // Datenbank-URL
console.log(process.env.SUPABASE_SERVICE_ROLE_KEY)    // Secret
```

### Verifiable Condition

```bash
# console.log statt logger?
grep -rn "console\.log\|console\.error" trigger/tasks/ --include="*.ts"
# Erwartung: keine Treffer (immer logger von @trigger.dev/sdk verwenden)

# Sensible Daten in Logs?
grep -rn "logger\.\(info\|error\|warn\)" trigger/ --include="*.ts" | \
  grep -iE "password|secret|key|token|email.*:" | \
  grep -v "orderId\|taskId\|runId"
# Erwartung: keine Treffer
```

### Failure Scenario

Trigger.dev stores all logs and displays them in the dashboard. If `console.log(user)` logs a complete user object with email and metadata, that data is visible in the Trigger.dev dashboard to anyone with dashboard access, even months later, since run history is persistent.

## Part C - Operations and Monitoring

## C1 - Monitoring and Alerting

### Implementation

Trigger.dev has a built-in dashboard with run history, logs, and traces. In addition, these metrics should be actively monitored:

```
Critical Metrics:
  - Failed Runs (last 24h)           -> Alert when > 5
  - Queue Length                     -> Alert when > 100
  - Average Run Duration             -> Alert when > 2x baseline
  - Runs in WAITING State            -> Info, no immediate alert
```

**Securing the self-hosted dashboard:**

```
# Das Trigger.dev Dashboard darf NICHT öffentlich erreichbar sein
# Zugang nur über:
# - Reverse Proxy mit Basic Auth
# - VPN / WireGuard
# - SSH Tunnel

# Beispiel: SSH Tunnel zum Dashboard
ssh -L 3040:localhost:3040 deploy@trigger-server

# Dann im Browser: http://localhost:3040
```

**Automated health check:**

```bash
#!/bin/bash
# scripts/check-trigger-health.sh

# Trigger.dev Platform erreichbar?
HEALTH=$(curl -s -o /dev/null -w "%{http_code}" http://localhost:3040/healthcheck)
if [ "$HEALTH" != "200" ]; then
  echo "KRITISCH: Trigger.dev Platform nicht erreichbar"
fi

# Worker-Container läuft?
WORKER_STATUS=$(docker compose -f docker-compose.trigger.yml ps trigger-worker --format '{{.State}}')
if [ "$WORKER_STATUS" != "running" ]; then
  echo "KRITISCH: Trigger.dev Worker nicht running ($WORKER_STATUS)"
fi

# Failed Runs der letzten 24h (über Trigger.dev DB)
FAILED=$(docker compose -f docker-compose.trigger.yml exec -T trigger-db \
  psql -U postgres -d trigger -t -c \
  "SELECT count(*) FROM task_runs WHERE status = 'FAILED' AND created_at > now() - interval '24 hours';" 2>/dev/null)

if [ "${FAILED:-0}" -gt 5 ]; then
  echo "WARNUNG: $FAILED fehlgeschlagene Runs in den letzten 24h"
fi
```

### Verifiable Condition

```bash
# Dashboard nur intern erreichbar?
curl -s -o /dev/null -w "%{http_code}" https://trigger.example.com:3040
# Erwartung: Connection refused oder 401

# Health Check Script läuft täglich?
crontab -l | grep "check-trigger-health"
# Erwartung: Eintrag vorhanden
```

## C2 - Dead Letter Handling

### Implementation

Tasks that fail after all retries end up in the `FAILED` status. These must be actively addressed.

```typescript
import { task, logger } from '@trigger.dev/sdk/v3'
import { createTaskClient } from '../lib/supabase'

export const criticalTask = task({
  id: 'critical-task',

  retry: {
    maxAttempts: 5,
    factor: 2,
    minTimeoutInMs: 2_000,
    maxTimeoutInMs: 60_000,
  },

  run: async (payload: { orderId: string }) => {
    // ... Task-Logik
  },

  onFailure: async (payload, error, params) => {
    const supabase = createTaskClient()

    // Failed Job in eigene Tabelle schreiben
    await supabase
      .from('failed_jobs')
      .insert({
        task_id: 'critical-task',
        payload: JSON.stringify(payload),
        error_message: error.message,
        attempts: params.run.attemptNumber,
        failed_at: new Date().toISOString(),
        resolved: false,
      })

    // Alert
    logger.error('Critical task permanently failed', {
      orderId: payload.orderId,
      attempts: params.run.attemptNumber,
    })
  },
})
```

```sql
-- Migration: failed_jobs Tabelle
CREATE TABLE IF NOT EXISTS failed_jobs (
  id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
  task_id TEXT NOT NULL,
  payload JSONB NOT NULL,
  error_message TEXT,
  attempts INTEGER,
  failed_at TIMESTAMPTZ NOT NULL,
  resolved BOOLEAN DEFAULT false,
  resolved_at TIMESTAMPTZ,
  resolved_by TEXT
);

-- RLS: nur service_role darf zugreifen
ALTER TABLE failed_jobs ENABLE ROW LEVEL SECURITY;
-- Keine Policy für anon/authenticated = kein Zugriff über PostgREST
```

### Verifiable Condition

```bash
# Gibt es unresolvierte Failed Jobs?
# Über Supabase Client oder direkte DB-Query
psql -c "SELECT count(*) FROM failed_jobs WHERE resolved = false;"
# Erwartung: 0 (oder aktiv in Bearbeitung)

# Haben alle kritischen Tasks einen onFailure Hook?
grep -L "onFailure" trigger/tasks/*.ts
# Erwartung: nur unkritische Tasks ohne onFailure
```

## C3 - Claude Code Integration

### Architecture

```
Git Push / PR
   |
   +-- Deterministic Checks (CI/CD)
   |   +-- All tasks have maxDuration?
   |   +-- All tasks have concurrencyLimit?
   |   +-- External API calls have idempotency keys?
   |   +-- No hardcoded secrets?
   |   +-- No console.log (only logger)?
   |
   +-- Claude Code Analysis (weekly or on PR)
       +-- New tasks without retry strategy?
       +-- DB access correctly scoped?
       +-- Idempotency patterns consistent?
       +-- onFailure for critical tasks present?
       +-- Concurrency limits appropriate?
```

### CI Script

```bash
#!/bin/bash
# scripts/check-trigger-tasks.sh

REPORT=""

# 1. Tasks ohne maxDuration
for file in trigger/tasks/*.ts; do
  name=$(basename "$file" .ts)
  if ! grep -q "maxDuration" "$file"; then
    REPORT+="WARNUNG: $name hat kein maxDuration\n"
  fi
done

# 2. Tasks ohne Concurrency
for file in trigger/tasks/*.ts; do
  name=$(basename "$file" .ts)
  if ! grep -qE "concurrencyLimit|queue:" "$file"; then
    REPORT+="WARNUNG: $name hat kein Concurrency Limit\n"
  fi
done

# 3. Externe API-Calls ohne Idempotency
for file in trigger/tasks/*.ts; do
  name=$(basename "$file" .ts)
  if grep -qE "fetch\(|stripe\.|resend\." "$file"; then
    if ! grep -qE "idempotencyKey|idempotencyKeys" "$file"; then
      REPORT+="WARNUNG: $name hat externe API-Calls ohne Idempotency\n"
    fi
  fi
done

# 4. Hardcoded Secrets
SECRETS=$(grep -rn "sk_live\|sk_test\|SG\.\|sk-" trigger/ --include="*.ts" 2>/dev/null)
if [ -n "$SECRETS" ]; then
  REPORT+="KRITISCH: Hardcoded Secrets:\n$SECRETS\n\n"
fi

# 5. console.log statt logger
CONSOLE=$(grep -rn "console\.\(log\|error\|warn\)" trigger/tasks/ --include="*.ts" 2>/dev/null)
if [ -n "$CONSOLE" ]; then
  REPORT+="WARNUNG: console.log statt Trigger.dev logger:\n$CONSOLE\n\n"
fi

# 6. Nicht exportierte Tasks
for file in trigger/tasks/*.ts; do
  name=$(basename "$file" .ts)
  if ! grep -q "export const" "$file"; then
    REPORT+="KRITISCH: $name Task ist nicht exportiert\n"
  fi
done

if [ -n "$REPORT" ]; then
  echo -e "=== Trigger.dev Task Security Check ===\n$REPORT"
else
  echo "Alle Trigger.dev Checks bestanden."
fi
```

Claude does **not execute automatic changes on production**. The full audit setup with custom commands and cron-based reviews is described in [Claude Code as a Security Control in DevOps Workflows](/en/magazine/claude-code-security-devops/).

## Deployment Checklist

Before every deployment of Trigger.dev tasks, verify:

```
Architecture
  [ ] Trigger.dev runs as a separate service (not in the Next.js process)
  [ ] Dedicated PostgreSQL instance (not the Supabase DB)
  [ ] Dashboard only accessible internally

Task Definition
  [ ] Every task is exported
  [ ] Every task has a unique ID
  [ ] Every task has maxDuration
  [ ] Every task has concurrencyLimit or a shared queue
  [ ] Every task has retry configuration

Idempotency
  [ ] Trigger calls have idempotencyKey where needed
  [ ] External API calls inside tasks have idempotency
  [ ] DB operations are idempotent (upsert instead of insert where possible)

Database Access
  [ ] service_role only via createTaskClient()
  [ ] Queries access only required data (no SELECT *)
  [ ] Connection pool limited (max: 5-10)

Secrets
  [ ] No hardcoded secrets in code
  [ ] Secrets via environment variables / dashboard
  [ ] .env.trigger not in Git

Logging
  [ ] Trigger.dev logger instead of console.log
  [ ] No sensitive data in logs (user objects, tokens, keys)

Error Handling
  [ ] Critical tasks have onFailure hook
  [ ] Failed jobs are stored in failed_jobs table
  [ ] Alerting configured for permanent failures
```

## Conclusion

Trigger.dev forms the background processing layer of the stack. Used correctly, it processes asynchronous jobs reliably with retries, idempotency, and monitoring.

The most critical security point is database access: tasks typically have more privileges than normal user requests because they work with `service_role` or a direct DB connection. Therefore, input validation, scope restriction, and idempotency must be deliberately implemented for every task.

The combination of built-in Trigger.dev retry logic, deliberate concurrency limits, and contextual Claude Code analysis leads to stable background workflows that function correctly even during partial failures.

Those who pursue these principles together with a [Cert-Ready by Design architecture](/en/magazine/cert-ready-by-design/) build verifiable security instead of retroactive audits.

<div class="not-prose my-12 border border-gosign-border bg-gosign-light rounded-card p-6 lg:p-8">
<div class="flex items-start gap-4">
<div class="flex-shrink-0 w-12 h-12 bg-gosign-dark rounded-card flex items-center justify-center">
<svg width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="white" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 15v4a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2v-4"/><polyline points="7 10 12 15 17 10"/><line x1="12" y1="15" x2="12" y2="3"/></svg>
</div>
<div>
<h2 class="text-h3 font-bold text-gosign-dark mb-2" id="audit-checklist-download">Audit Checklist Download</h2>
<p class="text-body text-gosign-text mb-2">Prepared prompt for Claude Code. Upload the file to your server and start Claude Code in your Trigger.dev setup's project directory. Claude Code will automatically check all security points from this runbook and report PASS, WARNING, or CRITICAL.</p>
<p class="text-sm text-gosign-text mb-4 font-mono">claude -p "$(cat claude-check-artikel-4-trigger-dev-en.md)" --allowedTools Read,Grep,Glob,Bash</p>
<a href="/downloads/claude-check-artikel-4-trigger-dev-en.md" download class="inline-flex items-center px-6 py-3 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-small uppercase tracking-wider">Download checklist</a>
</div>
</div>
</div>

## Series Table of Contents

1. [Supabase Self-Hosting Runbook](/en/magazine/supabase-self-hosting/)
2. [Running Next.js on Supabase Securely](/en/magazine/nextjs-supabase-secure-setup/)
3. [Deploying Supabase Edge Functions Securely](/en/magazine/supabase-edge-functions-secure/)
4. [Running Trigger.dev Background Jobs Securely](/en/magazine/trigger-dev-background-jobs/) - this article
5. [Claude Code as Security Control in DevOps Workflows](/en/magazine/claude-code-security-devops/)
6. [Security Baseline for the Entire Stack](/en/magazine/security-baseline-stack/)

The next article describes how **Claude Code is used as a security control in the DevOps workflow** - as the overarching analysis layer across all previous articles.

--- What Are AI Agents? Three Types for Enterprise ---
> AI agents: Document Agents, Workflow Agents, Knowledge Agents. How they execute domain tasks autonomously and differ from chatbots and RPA

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">At a Glance - AI Agents in Enterprise</p>
<ul class="text-body text-gosign-text space-y-2">
<li>AI agents are specialized software components that autonomously execute domain tasks - unlike chatbots (answer only) or RPA (rule-based only).</li>
<li>Three types exist: Document Agents (read and process documents), Workflow Agents (orchestrate cross-system processes), Knowledge Agents (contextual answers from corporate knowledge).</li>
<li>McKinsey (2024) estimates that AI agents could automate up to 30% of hours worked across most occupations by 2030.</li>
<li>The agent is not the model - the language model is interchangeable, while the agent provides domain logic, system integration, and governance.</li>
<li>Enterprise deployment requires a Decision Layer between agent and target system - ensuring every automated decision is traceable, auditable, and compliant.</li>
</ul>
</div>

## What Is an AI Agent?

An AI agent is a specialized software component that autonomously executes domain-specific tasks based on Large Language Models (LLMs). Unlike a chatbot, which answers questions, an agent takes action: it reads a document, evaluates the content, makes a decision, and triggers an action in a target system.

AI agents in an enterprise context do not operate freely. They work within defined boundaries: rule sets, scopes, confidence thresholds, escalation rules. Every agent decision is traceable and auditable.

The foundation of an AI agent is a language model - Claude, ChatGPT, Gemini, Llama, Mistral, DeepSeek, or gpt-oss. The model provides language comprehension. The agent provides the domain logic, system integration, and governance.

## Distinction: AI Agent vs. Chatbot vs. RPA

These three concepts are frequently confused. They solve different problems.

**Chatbot:** A chatbot answers questions in natural language. It has no capacity for action. When an employee asks "How many vacation days do I have left?", the chatbot answers. It does not book vacation, it does not check rules, it does not generate an audit trail.

**RPA (Robotic Process Automation):** RPA automates rule-based, repetitive tasks via user interfaces. An RPA bot clicks through SAP, copies data from A to B, fills out forms. RPA has no language comprehension. When the form changes, the bot breaks.

**AI Agent:** An AI agent understands context, interprets unstructured data, and makes decisions. It reads an invoice, regardless of format, understands the content, applies rule sets, and generates a booking proposal. When the invoice format changes, the agent continues to work because it understands the content, not the layout.

| Property | Chatbot | RPA | AI Agent |
|----------|---------|-----|----------|
| Language comprehension | Yes | No | Yes |
| Capacity for action | No | Yes (rule-based) | Yes (context-based) |
| Unstructured data | Yes | No | Yes |
| Governance/Audit | No | Partial | Yes (via Decision Layer) |
| System integration | Superficial | Via UI | Via API/Integration Layer |
| Adaptation to changes | Change prompt | Reprogram bot | Agent understands context |

## Three Types of Enterprise AI Agents

In the Gosign architecture, there are three agent types. Each type has a defined scope of responsibility and operates within the boundaries set by the Decision Layer.

### Document Agents

Document Agents read, understand, and process documents. Invoices, sick leave certificates, contracts, attestations, receipts, credit notes.

The key difference from OCR or template recognition: Document Agents have genuine language comprehension. They do not recognize fields at specific positions on a page but understand the content of the document. An invoice in PDF format, as a scanned image, or as an email attachment - the Document Agent understands all three.

A Document Agent for invoice processing reads an incoming invoice and extracts: vendor, amount, service description, date, tax rate, banking details. It produces a structured data record that is handed off to the Decision Layer.

Document Agents do not work in isolation. They are the entry point of a workflow - after reading the document, the Workflow Agent takes over.

### Workflow Agents

Workflow Agents orchestrate processes across systems. They coordinate the flow between Document Agent, Decision Layer, and target system.

A Workflow Agent for invoice processing coordinates: the Document Agent reads the invoice, the Decision Layer reviews the booking proposal, at high confidence the booking goes to the target system, at low confidence it escalates to the case worker, after approval the booking is finalized, the entire operation is documented in the audit trail.

Workflow Agents also handle exceptions: What happens when the target system is unreachable? What happens during a timeout? What happens when the case worker does not respond? The Workflow Agent has escalation rules, retry mechanisms, and timeout logic.

Workflow orchestration runs on [Trigger.dev](https://trigger.dev/) or [Camunda](https://camunda.com/), depending on the complexity and compliance requirements of the client. Workflows are versioned, testable, and defined as code.

### Knowledge Agents

Knowledge Agents provide context-based answers from organizational knowledge. Company agreements, policies, collective bargaining agreements, compliance rules, internal policies.

The difference from a search function: a Knowledge Agent understands the question, searches the relevant context, and delivers an answer with source citation and rule version. When a case worker asks "Does the night shift bonus also apply to part-time employees in the Western tariff region?", the Knowledge Agent provides the answer with a reference to the applicable company agreement in the current version.

Knowledge Agents use RAG (Retrieval Augmented Generation): organizational knowledge is indexed in a vector database. The agent retrieves the relevant passages and generates an answer based on these sources, not based on its training data.

Every answer includes: the source, the rule version, the validity date. No hallucinations, no fabricated rule references.

## How AI Agents Work Together in Enterprise Architecture

The three agent types do not work in isolation. In a typical enterprise implementation, the Workflow Agent orchestrates the overall process and delegates to specialized Document and Knowledge Agents.

An example from HR case management: a sick leave certificate arrives (email with PDF attachment). The Document Agent reads the certificate and extracts: employee, time period, medical certificate, follow-up certificate. The Knowledge Agent checks: which rules apply to this employee? Collective agreement, company agreement, individual supplementary agreements. The Decision Layer evaluates: is the continued pay calculation correct? Are the deadlines met? The Workflow Agent coordinates the entire flow and ensures all systems are updated.

Each agent has its defined scope. No agent "decides" alone on business-critical operations. The [Decision Layer](/en/decision-layer/) sits between the agent and the target system and ensures governance.

## Model-Agnosticism: The Agent Is Not the Model

A common misconception: the agent is not the language model. The model (Claude, ChatGPT, Llama) provides language comprehension. The agent provides the domain logic, the system integration, the governance.

In the Gosign architecture, the Model Layer is interchangeable. When a new model becomes available - more powerful, more cost-effective, with a better license - it can be integrated without changing the layers above. The business logic in the Decision Layer, the workflows, the rule sets remain unchanged.

An agent can also use multiple models: a cost-effective open-source model for pre-classification and a more powerful model for complex decisions. The routing between models is configurable.

This model-agnosticism prevents vendor lock-in. No organization is dependent on a single model provider.

## Prerequisites for Enterprise AI Agents

AI agents in enterprise environments require more than a language model:

**Governance:** Every agent decision must be traceable and auditable. The Decision Layer ensures this.

**Integration:** Agents must be integrated with existing systems - SAP, [DATEV](https://www.datev.de/), [Sage](https://www.sage.com/), [Workday](https://www.workday.com/), [SuccessFactors](https://www.sap.com/products/hcm.html), SharePoint. The Integration Layer decouples the agent logic from the target system.

**Infrastructure:** Agents need a runtime environment: LLM hosting, vector databases for RAG, workflow engine, API gateway. This infrastructure can be operated in the cloud, self-hosted, or hybrid.

**Employee Representation:** In many jurisdictions, employee representative bodies (such as works councils in Germany) have co-determination rights when introducing AI systems. The architecture must account for this from the outset.

More on this: [AI Agents in Detail](/en/services/ai-agents/)

<a href="/en/contact/" target="_blank" rel="noopener noreferrer">Book a consultation</a> - We will show you which agent type is the right fit for your process.

--- Why AI Projects in HR Fail ---
> Most AI projects fail not because of technology but because nobody defined the rules. Why the operating model matters more than the language model.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">At a Glance - Why AI Projects Fail</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Most AI projects do not fail because of technology. They fail because nobody defined which decisions AI may make and which must stay with humans.</li>
<li>The AI Paradox: enterprises adopt AI widely, but only a fraction achieve measurable results - the decision architecture is the missing piece.</li>
<li>MIT Sloan Management Review (2024) found that 70% of enterprise AI initiatives fail to move from pilot to production.</li>
<li>Investment ratio: for every euro in technology, enterprises need four to five euros in processes, governance, and change management. Technology alone addresses about 20% of the problem.</li>
<li>The Decision Layer decomposes business processes into documented decision steps - human, rule set, or AI - making AI experiments into production systems.</li>
</ul>
</div>

## A Pilot That Worked - and Then Disappeared

An HR department launches an AI project. An agent processes sick leave certificates: reads the document, extracts data, checks against the collective agreement, creates a proposal for SAP SuccessFactors. In the pilot, everything works. Accuracy reaches 94%. Processing time drops from 45 minutes to 5 minutes.

Six months later, the agent is still running in pilot mode. Not because the technology failed. But because nobody answered the questions that come after the pilot:

Who approves the booking the agent proposes? What happens when the agent is wrong - who is liable? Does the logic also apply to the Munich office, which has a different collective agreement? May the agent automatically initiate a return-to-work process for long-term illness, or does a human need to decide? What does the works council (Betriebsrat) say?

These are not technical questions. They are decision questions. And as long as they remain unanswered, every agent stays an experiment.

## The AI Paradox: High Adoption, Low Impact

What happens here is not an isolated case. It is a pattern that runs through enterprises of every size.

Most organisations already use AI - at minimum in the form of chatbots, Copilot licences, or initial pilots. But very few report that AI makes a measurable contribution to business results.

This is the AI Paradox: the technology works. But the impact doesn't materialise.

The usual explanations fall short. "Data quality isn't good enough" - sometimes true, but solvable. "The model isn't good enough" - unlikely given what current language models deliver. "Employees are afraid of AI" - change management matters, but doesn't explain why well-supported projects still stall.

The real cause is different: the decision architecture is missing.

## What's Missing: Not Better Technology - But Clear Rules

An AI agent processing sick leave makes five to ten individual decisions per document: Is the document complete? Which collective agreement applies? Is this a long-term illness? Does a return-to-work procedure need to be initiated? Which system receives the booking?

For each of these decisions, it must be defined in advance:

**Does a human decide?** The architecture enforces human review for discretionary decisions, discrimination risk, and employee representation matters. For example, in long-term illness cases, because a return-to-work process requires discretion and the works council (Betriebsrat) has co-determination rights (Mitbestimmung). This escalation is technically enforced, not organisationally agreed.

**Does a rule set apply?** The decision is deterministic - there is no room for interpretation. For example, when checking the collective agreement: the collective agreement states X, so X applies. Rule sets are versioned, every change creates a new version.

**Does the AI decide autonomously?** The agent makes independent decisions - because it is confident enough, has permission, and demonstrably performs the task better than manual processing. For example, in document classification: is this a sick note or a disability certificate? The agent interprets the document, classifies the situation, and evaluates context. This is not if-then-else - this is judgment within defined guardrails.

Without this assignment, the agent is a black box. It produces results, but nobody can trace the basis. No auditor accepts this. No works council approves it. No compliance team signs off.

## The Investment Ratio: Why Technology Alone Isn't Enough

Industry experience reveals a ratio that surprises many: for every euro in technology, enterprises need four to five euros in processes, governance, and change management.

This means: if you have an AI budget of EUR 500,000 and invest everything in licences and models, you address about 20% of the problem. The remaining 80% - process design, decision rules, works council agreements, training, governance structures - remain unaddressed.

This explains the AI Paradox. It is not a technology problem. It is an investment allocation problem.

## What This Means for HR

HR processes are particularly susceptible to the AI Paradox. For three reasons:

**First: High rule complexity.** Collective agreements, works council agreements, country-specific laws, internal policies. A single process like sick leave can touch five different rule sets.

**Second: Co-determination (Mitbestimmung).** In Germany, the works council (Betriebsrat) has co-determination rights when AI systems process employee data. Without traceable decision logic, the works council cannot verify what the agent does. Similar requirements exist across the EU under the EU AI Act.

**Third: Liability.** When an agent produces an incorrect payroll calculation, the agent is not liable. The company is. Without a documented decision path, it is unclear where the error occurred.

## First Make Decisions Visible, Then Automate

The solution is not less AI. The solution is more structure.

Before an agent automates a process, the process must be decomposed into individual decision steps. For each step, the assignment is defined: human, rule set, or AI. This assignment is not static - it can change when a rule set changes or when the agent gains more experience.

The [Decision Layer](/en/decision-layer/) implements exactly this. It sits between the AI agent and the target system, decomposing every business process into documented decision steps. Each step has a clear assignment, a versioned rule set, and a complete audit trail.

The result: an AI experiment becomes a production system. One that the works council can verify, that auditors accept, and that works consistently across locations.

## AI Project Failure Patterns

| Failure Pattern | Root Cause | Solution |
|---|---|---|
| Pilot succeeds but never scales | Decision rules undefined - nobody owns the post-pilot questions | Decision Layer: define human/rule/AI assignment per step before scaling |
| High adoption but no measurable impact | Investment concentrated in technology, processes and governance neglected | Rebalance: 20% technology, 80% processes, governance, change management |
| Works council blocks deployment | AI decisions not traceable, no audit trail | Architecture-level transparency: versioned rules, complete audit trail |
| Agent produces errors that nobody can explain | Black-box decisions without documented reasoning path | Confidence Routing: escalation thresholds, Human-in-the-Loop for edge cases |
| Different results at different locations | Rule sets vary but agent logic is uniform | Location-aware rule engine with versioned, testable rule sets |

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Free eBook: AI in HR</p>
<p class="text-body text-gosign-text mb-4">EU AI Act checklist, Decision Framework, works council perspective, and readiness assessment - the governance handbook for HR leaders.</p>
<a href="/en/ebook/ai-hr-governance-handbook/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Download for free</a>
</div>

## Conclusion

The AI Paradox is not inevitable. It is the consequence of misallocation: too much investment in technology, too little in the rules that determine what the technology may do.

Enterprises that understand this don't invest in the next language model - they invest in their decision architecture. And that is the difference between an AI pilot that ends up in a drawer and a system that runs in production.

→ [Decision Layer - Overview and Examples](/en/decision-layer/)

→ [Three Types of Decisions: When Humans Decide, When AI Decides](/en/magazine/three-types-of-decisions/)

--- Why Pair Programming Is Not Optional ---
> 15% more effort, 60% fewer defects, 40% faster onboarding. The scientific evidence for pair programming - with all KPIs and sources.

Two developers, one screen, one problem. What sounds like waste is the best-evidenced method in software engineering - and yet most organizations ignore it. In this article we have compiled 25 years of research data: from Williams' pioneering studies at the University of Utah through Cockburn's field experiments to Arisholm's controlled studies at Simula Research. The conclusion is unambiguous. Pair programming costs 15% more time - and saves multiples of that through fewer bugs, faster onboarding, and code that more than one person understands. Anyone who still lets developers work solo after reading this is doing so out of habit, not conviction.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">At a Glance - 25 Years of Pair Programming Research</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Pairs need only 15% more time - not double - while producing 15-60% fewer defects (Williams & Kessler, 2000; Arisholm et al., 2007).</li>
<li>Complex tasks finish 29% faster in pairs, and onboarding accelerates by 30-50% through knowledge transfer.</li>
<li>Cognitive load splits across two working memories, catching 40% more edge cases and reaching 99% detection for critical bugs.</li>
<li>In the AI era, pair programming counteracts professional isolation - 68% of developers report days without any team interaction (Microsoft, 2024).</li>
<li>Enterprise model calculation: a 10-developer project saves approximately EUR 345,000 net per year through reduced defect and knowledge costs.</li>
</ul>
</div>

## The Myth of the Lone Genius

The romantic notion persists: a brilliant developer sits alone at the screen, thinks hard, and produces elegant code. Linus Torvalds wrote Git in a weekend. John Carmack built Doom engines single-handedly.

These stories are true. They are also irrelevant.

Enterprise software is not a weekend project. It consists of hundreds of integrations, regulatory requirements, team handoffs, and systems that have grown over years. In this context, working alone is not a sign of productivity. It is a risk factor.

The research over the last 25 years is remarkably clear. The numbers:

- **15%** more total development time - not 100% <sup>[1]</sup>
- **15-60%** fewer defects in code <sup>[1][4]</sup>
- **29%** faster completion on complex tasks <sup>[2]</sup>
- **30-50%** faster onboarding of new team members <sup>[1]</sup>
- **95%** of pairing participants report higher satisfaction <sup>[2]</sup>
- **48%** fewer lines of code for the same functionality <sup>[1]</sup>
- **30x** higher costs when bugs are found in production <sup>[6]</sup>

This is not gut feeling. These are replicated study results from controlled experiments with hundreds of professional developers.

## The KPI Collection: 25 Years of Research in Numbers

### Defect Density and Code Quality

<table>
<thead><tr><th>Study</th><th>n</th><th>KPI</th><th>Result</th></tr></thead>
<tbody>
<tr><td>Williams & Kessler (2000) <sup>[1]</sup></td><td>41</td><td>Tests passed first time</td><td><strong>+15%</strong> vs. solo</td></tr>
<tr><td>Williams & Kessler (2000) <sup>[1]</sup></td><td>41</td><td>Defect density</td><td><strong>significantly lower</strong></td></tr>
<tr><td>Nosek (1998) <sup>[2]</sup></td><td>15</td><td>Functional correctness</td><td><strong>higher</strong> for pairs</td></tr>
<tr><td>Nosek (1998) <sup>[2]</sup></td><td>15</td><td>Code readability</td><td><strong>higher</strong> for pairs</td></tr>
<tr><td>Arisholm et al. (2007) <sup>[4]</sup></td><td>295</td><td>Error rate (complex tasks)</td><td><strong>-60%</strong> vs. solo</td></tr>
<tr><td>Arisholm et al. (2007) <sup>[4]</sup></td><td>295</td><td>Error rate (simple tasks)</td><td><strong>marginal</strong></td></tr>
<tr><td>Dyba et al. (2007) <sup>[5]</sup></td><td>18 studies</td><td>Overall code quality</td><td><strong>statistically significant improvement</strong></td></tr>
<tr><td>Jensen (2003) <sup>[16]</sup></td><td>120</td><td>Post-acceptance defects</td><td><strong>-40%</strong></td></tr>
<tr><td>Padberg & Mueller (2003) <sup>[17]</sup></td><td>Simulation</td><td>Post-release defects</td><td><strong>-20 to -40%</strong></td></tr>
</tbody>
</table>

### Time Expenditure and Productivity

| Study | n | KPI | Result |
|-------|---|-----|--------|
| Williams & Kessler (2000) <sup>[1]</sup> | 41 | Total development time | **+15%** (not +100%) |
| Nosek (1998) <sup>[2]</sup> | 15 | Elapsed time (complex task) | **-29%** faster |
| Arisholm et al. (2007) <sup>[4]</sup> | 295 | Effort (simple tasks) | **+84%** |
| Arisholm et al. (2007) <sup>[4]</sup> | 295 | Effort (complex tasks) | **+18%** |
| Cockburn & Williams (2001) <sup>[3]</sup> | Review | Break-even at defect reduction | **from 3-5%** |
| Lui & Chan (2006) <sup>[18]</sup> | 40 | Task throughput | **+43%** vs. solo |

### Satisfaction and Team Dynamics

| Study | n | KPI | Result |
|-------|---|-----|--------|
| Nosek (1998) <sup>[2]</sup> | 15 | Satisfaction with outcome | **+95%** for pairs |
| Williams et al. (2000) <sup>[1]</sup> | 41 | Would recommend to colleagues | **96%** would pair again |
| Begel & Nagappan (2008) <sup>[19]</sup> | 106 | Satisfaction with pairing (Microsoft) | **65%** satisfied |
| Begel & Nagappan (2008) <sup>[19]</sup> | 106 | See quality improvement (Microsoft) | **74%** |

### Code Efficiency

| Study | KPI | Result |
|-------|-----|--------|
| Williams & Kessler (2000) <sup>[1]</sup> | Lines of code (same functionality) | **-48%** fewer lines |
| Mueller (2004) <sup>[20]</sup> | Cyclomatic complexity | **lower** for pairs |

The core finding across all studies: pair programming costs slightly more time. It produces less code that has fewer bugs, is easier to maintain, and is understood by more people.

## "But I Am Faster Alone" - What Really Bothers Developers

Let us address the elephant in the room. Most developers who reject pair programming do not have numbers against it. They have a feeling. And that feeling is not irrational - it is simply incomplete.

### "I cannot concentrate when someone watches me"

This is real. Research on Social Facilitation <sup>[10]</sup> shows, however, that the presence of an observer disrupts performance only for **new, unpracticed tasks**. For tasks you have mastered - the actual programming work - presence **improves** performance by 15-20%.

What you experience as "disruption" is your brain switching from System 1 (autopilot) to System 2 (analytical thinking) <sup>[9]</sup>. This feels more strenuous. But it produces better code. Every developer knows the feeling of writing a "brilliant" solution at 11 PM alone - that looks embarrassing the next morning. The partner prevents 11 PM decisions in real time.

### "I need to think alone before I can code"

True. And that is exactly why pair programming does not mean two people sitting next to each other for 8 hours. The most effective practice according to a study by Chong and Hurlbutt (2007) <sup>[21]</sup>: **2-4 hour sessions** with breaks for solo exploration.

The model: think solo, pair to build, think solo, pair to review. The studies measuring 15% additional effort with 60% fewer defects are based on this rhythm - not on 8-hour continuous pairing.

### "My partner is too slow / too fast"

Skill mismatch is the most common problem in practice <sup>[19]</sup>. Begel and Nagappan (2008) found in their Microsoft study: **73% of developers** who rejected pairing cited skill mismatch as the reason. Not pairing itself.

The solution is not no pairing. The solution is better matching. Their data also showed: with well-matched pairs, satisfaction was at **90%** - and perceived productivity even exceeded solo work <sup>[19]</sup>.

And here is the point nobody likes to hear: if you are always the "faster" one, you are also the knowledge monopolist. You are the bus factor of 1. Your team depends on you. Pairing with someone who is "slower" is not a brake - it is knowledge transfer. It is the cheapest insurance your team can buy.

### "I lose my flow state"

Csikszentmihalyi's flow theory <sup>[22]</sup> describes the state of complete absorption in a task. Solo programming can produce flow. But flow has a problem: it suppresses critical thinking. In flow state, warning signs are ignored, edge cases skipped, shortcuts taken that "feel right" <sup>[9]</sup>.

What developers experience as "flow" is often System 1 running at full speed - fast, intuitive, and blind to its own errors. Pair programming replaces uncontrolled flow with **productive focus**: high concentration with simultaneous quality control.

The studies show: pairs report **equal or higher job satisfaction** compared to solo developers <sup>[2]</sup>. Flow is not the only recipe for good work. Shared focus is the more sustainable variant.

### "Code reviews are sufficient"

Fagan (1976) <sup>[14]</sup> showed: formal code reviews find **60-70% of defects**. That sounds good. Pair programming finds **85-95%** <sup>[1]</sup>. But the decisive difference is not the rate - it is the timing.

A code review finds errors hours or days after they were written. The context is gone. The reviewer must reconstruct the thought process - and does so incorrectly in **60% of cases** (Bacchelli & Bird, 2013) <sup>[23]</sup>. They approve code they do not fully understand because the social pressure is too great to keep a colleague waiting hours for an approve.

Pair programming does not have this problem. The navigator was present during the entire thought process. No context loss. No social pressure. And no queue in PR review that slows down the entire team.

### "It is socially exhausting"

Yes. For introverted developers, continuous pairing is draining. This is not an argument against pairing - it is an argument for **measured pairing**. The research <sup>[21]</sup> recommends 50-70% pairing time, not 100%. Critical tasks (architecture, integration, security) in pairs. Routine work (configuration, simple bugs) solo.

The key finding: developers who "never" wanted to pair changed their minds after **2 weeks of consistent pairing** - 96% would recommend it <sup>[1]</sup>. The initial rejection is almost always a comfort zone defense, not an evidence-based position.

## The Cognitive Explanation: Why Two Brains Outperform One

### Cognitive Load Theory (Sweller, 1988) <sup>[7]</sup>

Every person has a limited capacity for simultaneous information processing in working memory. Miller (1956) <sup>[8]</sup> quantified this capacity at **7 plus or minus 2 units**. When programming, up to **12-15 parallel demands** compete for this capacity: syntax, logic, system architecture, edge cases, naming conventions, testing requirements, API contracts, performance implications.

In pair programming, this load distributes across two working memories. The driver focuses on the tactical level: syntax, variable names, current function. The navigator keeps the strategic level in view: does the solution fit the overall architecture? Is an edge case missing? Is there a simpler variant?

Measurable: pairs consider **40% more edge cases** than solo developers on the same task <sup>[17]</sup>. Not because they are smarter. But because their combined cognitive capacity is higher.

### Verbalization Effect (Chi et al., 1989) <sup>[11]</sup>

One of the most powerful debugging tools is rubber duck debugging: explaining the problem out loud, even if only a rubber duck is listening. Chi et al. demonstrated the Self-Explanation Effect: students who explained their solution steps aloud achieved problem-solving test **scores 2.5x higher** than silent problem-solvers. The error rate dropped by **30%** <sup>[11]</sup>.

Pair programming institutionalizes this effect. Every decision must be explained to the partner. "I am using a HashMap instead of an ArrayList here because..." - the sentence forces justification. And justifications that are not convincing get challenged. Before the code is written, not weeks later in code review.

### Dual Process Theory (Kahneman, 2011) <sup>[9]</sup>

Daniel Kahneman's Dual Process Theory distinguishes two thinking modes: System 1 (fast, intuitive, error-prone) and System 2 (slow, analytical, precise). In solo programming, System 1 dominates - developers copy known patterns, skip checks because "that has always worked."

The partner activates System 2. Not through control, but through mere presence. Social psychology calls this Social Facilitation <sup>[10]</sup>: the presence of a competent observer improves performance on well-practiced tasks by **15-20%**.

### Working Memory Complement (Flor & Hutchins, 1991) <sup>[24]</sup>

Two programmers do not simply share the work. They complement their working memories. What person A overlooks, person B notices - not because B is more attentive, but because attention scatters statistically.

The mathematical consequence: if a solo developer detects a specific class of errors with **90% probability**, two independent developers detect the same error class with **99% probability** (1 - 0.1 x 0.1). At a detection rate of 80%, the pair detection rate rises to **96%**. This statistical effect alone explains a large portion of the observed defect reduction.

## The Psychological Dimension: Safety, Knowledge, Belonging

### Psychological Safety (Edmondson, 1999) <sup>[12]</sup>

Amy Edmondson coined the term Psychological Safety: the belief that one can admit mistakes, ask questions, and take risks in a team without being punished.

- **Google Project Aristotle (2015)** <sup>[13]</sup>: Psychological Safety was the **#1 predictor** of team performance - more important than structure, clarity, meaning, or dependability
- **Edmondson (1999)** <sup>[12]</sup>: teams with high Psychological Safety **reported 70% more errors** and could fix them faster as a result
- **Rozovsky (2015)** <sup>[13]</sup>: teams in the top quartile for Psychological Safety had **17% higher productivity** and **40% lower attrition**

Pair programming creates a natural framework for this. "I do not understand what this API returns" is a normal statement in a pairing session. In a solo setting, the same uncertainty often goes unspoken - and becomes a bug.

### Knowledge Distribution and Bus Factor

The cost of knowledge loss in numbers:

- **Bus factor of 1** (only one person knows the code): risk of **complete project failure** on personnel change
- **Knowledge loss through attrition**: with each departure, **42% of process-relevant knowledge** is lost - of which **70% is tacit**, meaning undocumented <sup>[15]</sup>
- **Cost of re-onboarding**: **6-12 months** until a new developer is productive in an enterprise project, **3-6 months** with pair onboarding <sup>[1]</sup>
- **Attrition costs**: 50-200% of annual salary per departure (SHRM, 2019)

Pair programming is the most reliable mechanism we know to [distribute tacit knowledge from individual heads into the team](/en/magazine/why-ai-projects-fail/).

### Onboarding Acceleration

- **30-50% faster productivity** with pair onboarding vs. self-study <sup>[1]</sup>
- **75% of onboarding pairs** feel "ready for independent work" after 2 weeks vs. **25% with solo onboarding** <sup>[21]</sup>
- **Cognitive Apprenticeship** (Collins, Brown & Newman, 1989) <sup>[25]</sup>: learning through observation and gradual takeover is **2-3x more effective** than instruction-based learning for complex tasks

## The Business Case: The Complete Calculation

### Mistake 1: The 100% Assumption

Pairs do not take twice as long:

- Simple tasks: **+84% effort** <sup>[4]</sup> - pairing rarely pays off here
- Medium tasks: **+15% effort** <sup>[1]</sup>
- Complex tasks: **+18% effort** with simultaneously **-60% defects** <sup>[4]</sup>
- Elapsed time (complex task): **-29%** faster to completion <sup>[2]</sup>

Pairs discard bad approaches **4x faster** because the navigator recognizes the thinking error earlier <sup>[18]</sup>.

### Mistake 2: Defect Costs Are Ignored

The cost escalation curve per Boehm and Basili (2001) <sup>[6]</sup>:

| Phase | Remediation cost (relative) | Example (at EUR 500 base cost) |
|-------|---------------------------|--------------------------------------|
| Coding | 1x | EUR 500 |
| Code review | 2x | EUR 1,000 |
| Integration/testing | 5x | EUR 2,500 |
| System test | 10x | EUR 5,000 |
| Production | 30x | EUR 15,000 |
| Post-release (customer affected) | 100x | EUR 50,000 |

The **National Institute of Standards and Technology (NIST)** <sup>[26]</sup> estimated the annual cost of software defects in the US at **USD 59.5 billion**. Of that, **USD 22.2 billion** (37%) could have been avoided through earlier defect detection.

### Mistake 3: Knowledge Costs Are Ignored

When a developer quits and no one knows their code:

- **Reverse engineering**: 2-6 months of effort
- **Elevated error rate** during transition: +200-300%
- **Delayed feature delivery**: 3-9 months until normal state
- **Total attrition cost**: 50-200% of annual salary (SHRM, 2019)

### The Full Calculation (Model Project)

For an enterprise project with 10 developers, 12-month duration:

| Item | Solo | Pairing | Delta |
|------|------|---------|-------|
| Development effort | Baseline | +15% | +EUR 105,000 |
| Defect remediation (test) | Baseline | -40% | -EUR 120,000 |
| Defect remediation (production) | Baseline | -50% | -EUR 225,000 |
| Knowledge transfer/onboarding | Baseline | -40% | -EUR 80,000 |
| Documentation effort | Baseline | -30% | -EUR 25,000 |
| **Net savings** | | | **-EUR 345,000** |

The numbers vary by project. The direction does not. In enterprise development - where a production bug in a [payroll (UK: PAYE) system](/en/services/hr-agent/payroll-decision-layer/) or an interface to SAP affects thousands of employees - solo development is the more expensive model.

## Real-Time Review vs. Post-Hoc Review

| KPI | Post-hoc code review | Pair Programming | Source |
|-----|---------------------|-----------------|--------|
| Defect detection | 60-70% | 85-95% | <sup>[14]</sup> <sup>[1]</sup> |
| Time to detection | Hours to days | Seconds | Structural |
| Context loss | High | Zero | <sup>[23]</sup> |
| Review misunderstandings | 60% (reviewer misunderstands intent) | 0% | <sup>[23]</sup> |
| PR wait time | 4-24 hours (team blocker) | 0 | Structural |
| Knowledge transfer | Low (only code visible) | High (decision process visible) | <sup>[24]</sup> |

Bacchelli and Bird (2013) <sup>[23]</sup> analyzed code reviews at Microsoft and found: in **60% of cases**, the reviewer did not correctly understand the author's intent. Reviews that were supposed to find bugs degenerated into style discussions. The main reason: missing context.

## The Human Factor: Why Pairing Matters More in the AI Era, Not Less

There is an argument for pair programming that appears in no study from the 2000s - because the problem did not exist back then.

In 2026, developers spend a growing share of their workday in dialogue with AI assistants. Code is generated with Copilot, architecture questions posed to Claude, debugging performed with ChatGPT. The productivity gains are real. But a side effect is emerging that nobody planned for: **professional isolation**.

The numbers are alarming:

- **Gallup State of the Global Workplace (2024)**: only **23% of employees** worldwide feel engaged at work. For remote knowledge workers, the figure is **18%**
- **Microsoft Work Trend Index (2024)**: **68% of developers** report that on some days they **do not speak with anyone on their team** about work
- **Buffer State of Remote Work (2024)**: **23% of remote workers** name **loneliness** as their biggest challenge - ahead of "distractions" and "motivation"
- **Murthy (2023)**: the US Surgeon General declared workplace loneliness a **Public Health Crisis** with measurable effects on productivity, creativity, and error rates

A developer who spends 8 hours a day talking to an LLM and no one on their team makes decisions in a vacuum. The LLM does not push back from experience. It does not know the team dynamics. It does not know that the last developer who "quickly" changed the database structure caused three weeks of cleanup. It has no opinion based on scars.

### Social Cognition vs. Tool Cognition

Neuroscience distinguishes two networks in the brain <sup>[27]</sup>: the **Task-Positive Network** (activated during problem-solving, tool use, focused work) and the **Default Mode Network** (activated during social cognition, perspective-taking, empathy). During solo programming with AI assistants, almost exclusively the Task-Positive Network is active. The Default Mode Network - responsible for "How would my colleague see this?" - stays silent.

Pair programming activates **both networks simultaneously**: problem-solving and social cognition. The result is decisions that are not only technically correct but also consider the team context.

### Trust Is Built Through Shared Work, Not Slack Messages

Dutton and Heaphy (2003) <sup>[28]</sup> studied "High-Quality Connections" in the workplace: brief, intense interactions that generate trust, energy, and mutual appreciation. Their research shows:

- **A single day of intensive collaboration** generates more trust than **weeks of asynchronous communication**
- Teams with regular high-quality connections have **25% lower attrition** and **30% higher engagement** <sup>[28]</sup>
- Trust built through shared problem-solving is **3x more stable** than trust built through social events <sup>[12]</sup>

Pair programming is the densest form of professional interaction that exists. Two people solve a problem together, share frustration and success, learn how the other thinks. This is not a soft-skill bonus. It is the glue that holds functioning teams together.

### The Counter-Calculation: What Happens When Teams Stop Talking

- **Silo formation**: without regular professional exchange, knowledge islands form. Each developer builds their own mental model of the system - and those models diverge over time <sup>[15]</sup>
- **Duplicate work**: without visibility into others' work, **15-25% of features are implemented redundantly** (Herbsleb & Grinter, 1999) <sup>[29]</sup>
- **Quality loss**: developers who feel socially isolated show **33% more defects** than engaged team members (Begel & Nagappan, 2008) <sup>[19]</sup>
- **Burnout**: professional isolation is one of the strongest predictors of burnout among knowledge workers (Maslach & Leiter, 2016) <sup>[30]</sup>

The irony: AI assistants make individual developers more productive. But they make teams more fragile - when pairing is absent as a counterweight. The solution is not less AI. The solution is intentional human interaction as a standard process. Pair programming is the simplest and most effective path to get there.

## What This Means for Enterprise Development

In [enterprise software development](/en/services/software-engineering/) all the above effects compound:

**Integration complexity.** When an agent must connect to SAP, DATEV, and Microsoft Graph, cognitive load per task rises to **15+ parallel contexts**. Exactly the situation where pair programming shows the greatest advantage: +18% effort with -60% defects <sup>[4]</sup>.

**Regulatory requirements.** Compliance-relevant code demands correctness. The **99% detection rate** (vs. 90% solo) for critical error classes is not a nice-to-have. It is a business requirement.

**Four-eyes principle.** In regulated industries, compliance mandates a four-eyes principle (MaRisk, ISO 27001). Pair programming fulfills this requirement natively - **zero additional effort** for compliance review.

**Co-Build as a model.** At Gosign we work in a [Co-Build model](/en/services/ai-agents/): customer teams develop with us, not alongside us. This is pair programming at the organizational level - **100% knowledge transfer** to the customer team, no vendor lock-in.

## The Summary in Numbers

| KPI | Solo | Pair Programming | Source |
|-----|------|-----------------|--------|
| Development time | Baseline | +15% | <sup>[1]</sup> |
| Elapsed time (complex) | Baseline | -29% | <sup>[2]</sup> |
| Defect density | Baseline | -15 to -60% | <sup>[1]</sup> <sup>[4]</sup> |
| Lines of code (same function) | Baseline | -48% | <sup>[1]</sup> |
| Tests passed first time | Baseline | +15% | <sup>[1]</sup> |
| Onboarding duration | 3-6 months | 1.5-3 months | <sup>[1]</sup> |
| Satisfaction | Baseline | +95% | <sup>[2]</sup> |
| Would pair again | n/a | 96% | <sup>[1]</sup> |
| Bus factor | 1 | At least 2 | Structural |
| Post-release defects | Baseline | -20 to -40% | <sup>[17]</sup> |
| Defect detection (critical) | 90% | 99% | Statistical |
| Cost per defect (production) | 30x coding | Avoided | <sup>[6]</sup> |
| PR review wait time | 4-24h | 0 | Structural |
| Code review misunderstandings | 60% | 0% | <sup>[23]</sup> |

## Conclusion

The question is not whether an organization can afford pair programming. The question is whether it can afford to go without it.

**15% more development time. 60% fewer defects. 40% faster onboarding. 48% less code. 99% detection rate for critical errors. EUR 345,000 net savings per year in the model project.**

And to the developers who find pairing annoying: 96% of your colleagues changed their minds after two weeks of consistent pairing <sup>[1]</sup>. The evidence does not say pairing is comfortable. It says it works better. For the code, for the team, and for you.

Pair programming is not a preference. It is an engineering decision with measurable ROI.

> [Software Engineering at Gosign - Co-Build Instead of Black Box](/en/services/software-engineering/)

> [Why AI Projects Fail - and What Decision Architecture Has to Do With It](/en/magazine/why-ai-projects-fail/)

> [AI Agents - Custom Solutions in the Co-Build Model](/en/services/ai-agents/)

---

## References

<small>

**[1]** Williams, L. & Kessler, R. (2000). "All I Really Need to Know About Pair Programming I Learned in Kindergarten." *Communications of the ACM*, 43(5), 108-114. University of Utah.

**[2]** Nosek, J.T. (1998). "The Case for Collaborative Programming." *Communications of the ACM*, 41(3), 105-108.

**[3]** Cockburn, A. & Williams, L. (2001). "The Costs and Benefits of Pair Programming." *Proceedings of the First International Conference on Extreme Programming and Flexible Processes in Software Engineering (XP2000)*, 223-243.

**[4]** Arisholm, E., Gallis, H., Dyba, T. & Sjoberg, D.I.K. (2007). "Evaluating Pair Programming with Respect to System Complexity and Programmer Expertise." *IEEE Transactions on Software Engineering*, 33(2), 65-86.

**[5]** Dyba, T., Arisholm, E., Sjoberg, D.I.K., Hannay, J.E. & Shull, F. (2007). "Are Two Heads Better than One? On the Effectiveness of Pair Programming." *IEEE Software*, 24(6), 12-15.

**[6]** Boehm, B. & Basili, V. (2001). "Software Defect Reduction Top 10 List." *IEEE Computer*, 34(1), 135-137.

**[7]** Sweller, J. (1988). "Cognitive Load During Problem Solving: Effects on Learning." *Cognitive Science*, 12(2), 257-285.

**[8]** Miller, G.A. (1956). "The Magical Number Seven, Plus or Minus Two." *Psychological Review*, 63(2), 81-97.

**[9]** Kahneman, D. (2011). *Thinking, Fast and Slow.* Farrar, Straus and Giroux. New York.

**[10]** Zajonc, R.B. (1965). "Social Facilitation." *Science*, 149(3681), 269-274.

**[11]** Chi, M.T.H., Bassok, M., Lewis, M.W., Reimann, P. & Glaser, R. (1989). "Self-Explanations: How Students Study and Use Examples in Learning to Solve Problems." *Cognitive Science*, 13(2), 145-182.

**[12]** Edmondson, A. (1999). "Psychological Safety and Learning Behavior in Work Teams." *Administrative Science Quarterly*, 44(2), 350-383.

**[13]** Rozovsky, J. (2015). "The Five Keys to a Successful Google Team." *re:Work*, Google.

**[14]** Fagan, M.E. (1976). "Design and Code Inspections to Reduce Errors in Program Development." *IBM Systems Journal*, 15(3), 182-211.

**[15]** DeLong, D.W. (2004). *Lost Knowledge: Confronting the Threat of an Aging Workforce.* Oxford University Press.

**[16]** Jensen, R.W. (2003). "A Pair Programming Experience." *CrossTalk: The Journal of Defense Software Engineering*, 16(3), 22-24.

**[17]** Padberg, F. & Mueller, M. (2003). "Analyzing the Cost and Benefit of Pair Programming." *Proceedings of the 9th International Software Metrics Symposium (METRICS 2003)*, IEEE, 166-177.

**[18]** Lui, K.M. & Chan, K.C.C. (2006). "Pair Programming Productivity: Novice-Novice vs. Expert-Expert." *International Journal of Human-Computer Studies*, 64(9), 915-925.

**[19]** Begel, A. & Nagappan, N. (2008). "Pair Programming: What's in it for Me?" *Proceedings of the Second ACM-IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM)*, 120-128.

**[20]** Mueller, M. (2004). "Are Reviews an Alternative to Pair Programming?" *Empirical Software Engineering*, 9(4), 335-351.

**[21]** Chong, J. & Hurlbutt, T. (2007). "The Social Dynamics of Pair Programming." *Proceedings of the 29th International Conference on Software Engineering (ICSE)*, 354-363.

**[22]** Csikszentmihalyi, M. (1990). *Flow: The Psychology of Optimal Experience.* Harper & Row. New York.

**[23]** Bacchelli, A. & Bird, C. (2013). "Expectations, Outcomes, and Challenges of Modern Code Review." *Proceedings of the 35th International Conference on Software Engineering (ICSE)*, 712-721.

**[24]** Flor, N.V. & Hutchins, E.L. (1991). "Analyzing Distributed Cognition in Software Teams: A Case Study of Team Programming During Perfective Software Maintenance." *Proceedings of the Fourth Annual Workshop on Empirical Studies of Programmers*, 36-64. Ablex Publishing.

**[25]** Collins, A., Brown, J.S. & Newman, S.E. (1989). "Cognitive Apprenticeship: Teaching the Crafts of Reading, Writing, and Mathematics." In L.B. Resnick (Ed.), *Knowing, Learning, and Instruction: Essays in Honor of Robert Glaser*, 453-494. Lawrence Erlbaum Associates.

**[26]** National Institute of Standards and Technology (2002). "The Economic Impacts of Inadequate Infrastructure for Software Testing." *NIST Planning Report 02-3.*

**[27]** Fox, M.D. et al. (2005). "The Human Brain Is Intrinsically Organized into Dynamic, Anticorrelated Functional Networks." *Proceedings of the National Academy of Sciences*, 102(27), 9673-9678.

**[28]** Dutton, J.E. & Heaphy, E.D. (2003). "The Power of High-Quality Connections." In K.S. Cameron, J.E. Dutton & R.E. Quinn (Eds.), *Positive Organizational Scholarship*, 263-278. Berrett-Koehler Publishers.

**[29]** Herbsleb, J.D. & Grinter, R.E. (1999). "Architectures, Coordination, and Distance: Conway's Law and Beyond." *IEEE Software*, 16(5), 63-70.

**[30]** Maslach, C. & Leiter, M.P. (2016). "Understanding the Burnout Experience: Recent Research and Its Implications for Psychiatry." *World Psychiatry*, 15(2), 103-111.

</small>

--- Why We Don't Train AI Agents Anymore ---
> 92% accuracy without training. The EU AI Act requires explainable individual decisions for high-risk systems (deadline 2 August 2026, postponement to Dec 2027 provisionally agreed). Trained models cannot deliver that.

## Training Is the New Fax

In 2019 we had to train AI models. They were too limited for anything else. GPT-2 could not write a coherent paragraph. BERT needed thousands of labelled examples and a GPU cluster running for days for every task.

That was six years ago. Six years in which language model capabilities improved by orders of magnitude. Yet the industry still acts as if "training" is the natural first step.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">At a Glance - Why Training Is the Wrong Architecture</p>
<ul class="text-body text-gosign-text space-y-2">
<li>An LLM achieves 92% correct decisions in invoice review - without a single training example. Experienced lawyers reach 72%.<sup>[1]</sup></li>
<li>The EU AI Act (Art. 13, 14, 86) requires explainable individual decisions for high-risk systems - under current law from 2 August 2026, with a postponement to 2 December 2027 provisionally agreed (Digital Omnibus, 7 May 2026, formal adoption still pending). Trained models cannot deliver that.<sup>[10]</sup></li>
<li>The alternative: rulebook (versioned), context (per decision), Decision Layer (human / rulebook / AI per Micro-Decision).</li>
<li>Configured agents are model-agnostic: switch foundation models without changing a single rule. No lock-in, no retraining.</li>
<li>Over 40% of agentic AI projects will fail by 2027 - mostly due to missing governance, not missing model performance.<sup>[9]</sup></li>
</ul>
</div>

If someone says "we train our AI agents" in 2026, it is like saying "we fax our orders" in 2010. It works. But it shows a fundamental misunderstanding of the architecture.

<!-- Timeline: From Training to Configuration -->
<div class="not-prose my-12">
<div class="bg-gosign-dark rounded-card p-6 sm:p-8">
<p class="text-h3 font-bold text-white mb-6">From Training to Configuration</p>
<div class="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-4 gap-4">

<div class="border border-white/10 rounded-lg p-4 bg-white/5">
<p class="text-gosign-text-on-dark text-xs uppercase tracking-wider mb-1">2018 - 2020</p>
<p class="text-white font-bold text-lg mb-2">Training Is Required</p>
<p class="text-gosign-text-on-dark text-sm mb-3">BERT, GPT-2. 110M - 1.5B parameters.</p>
<div class="space-y-1 text-xs text-gosign-text-on-dark">
<p>Duration: Weeks</p>
<p>Cost: $10,000 - $100,000</p>
<p>Prerequisite: GPU cluster</p>
</div>
</div>

<div class="border border-white/10 rounded-lg p-4 bg-white/5">
<p class="text-gosign-text-on-dark text-xs uppercase tracking-wider mb-1">2021 - 2023</p>
<p class="text-white font-bold text-lg mb-2">Training Becomes Optional</p>
<p class="text-gosign-text-on-dark text-sm mb-3">GPT-3/3.5. 175B parameters.</p>
<div class="space-y-1 text-xs text-gosign-text-on-dark">
<p>Duration: Days</p>
<p>Cost: $1,000 - $10,000</p>
<p>Prerequisite: GPU required</p>
</div>
</div>

<div class="border border-white/10 rounded-lg p-4 bg-white/5">
<p class="text-gosign-text-on-dark text-xs uppercase tracking-wider mb-1">2024</p>
<p class="text-white font-bold text-lg mb-2">Training or Prompting?</p>
<p class="text-gosign-text-on-dark text-sm mb-3">GPT-4o, Claude 3.5. Multimodal.</p>
<div class="space-y-1 text-xs text-gosign-text-on-dark">
<p>Duration: Hours</p>
<p>Cost: $10 - $100</p>
<p>Prerequisite: API call</p>
</div>
</div>

<div class="border border-gosign-accent rounded-lg p-4 bg-gosign-accent/10">
<p class="text-gosign-accent-on-dark text-xs uppercase tracking-wider mb-1">2025 - 2026</p>
<p class="text-white font-bold text-lg mb-2">Configuration Is Enough</p>
<p class="text-gosign-text-on-dark text-sm mb-3">GPT-5.5, Claude Opus 4.7. Reasoning.</p>
<div class="space-y-1 text-xs text-gosign-text-on-dark">
<p>Duration: Minutes</p>
<p>Cost: $10 - $100</p>
<p>Prerequisite: API call</p>
</div>
</div>

</div>
</div>
</div>

Kumar Gauraw puts it clearly: "Most reach for fine-tuning too early."<sup>[5]</sup> Not because fine-tuning is bad. Because in 2026, it is no longer necessary for most enterprise tasks.

## What a Trained Model Cannot Do: Explain an Individual Decision

A candidate is rejected by your recruiting agent. They ask: Why?

Two answers. Two architectures.

**Trained model:** "Our model learned from 50,000 historical hiring decisions that your profile has a 34% success probability."

**Configured agent:** "Your qualification in mechanical engineering does not meet requirement 3 (electrical engineering or equivalent). Rule: job profile v2026-03. Contestable: Yes. Process: department reviews whether mechanical engineering qualifies as 'equivalent'."

Under the EU AI Act high-risk obligations, the first answer does not hold up. Those obligations apply from 2 August 2026 under current law, with a postponement to 2 December 2027 provisionally agreed under the Digital Omnibus of 7 May 2026 (formal adoption still pending, as of June 2026) - the classification itself does not change, so this is what you build for now.

EU AI Act, Art. 13 (transparency), Art. 14 (human oversight), Art. 86 (right to explanation).<sup>[10]</sup> For high-risk systems - and recruiting is high-risk, Annex III(4) - every individual decision must be traceable, explainable and contestable. (US: No federal equivalent exists, but EEOC guidance increasingly demands similar explainability for automated hiring decisions.)

Not the model. The individual decision. For this candidate. With this justification.

A trained model cannot do that. It has no decision record. It has weights. And weights explain nothing to an employee representative body.

### The Compliance Test: Trained vs. Configured

<!-- Two-column comparison: Trained vs. Configured -->
<div class="not-prose my-10">
<div class="bg-gosign-dark rounded-card overflow-hidden">
<div class="grid grid-cols-1 md:grid-cols-2">

<!-- Left column: Trained -->
<div class="p-6 sm:p-8 border-b md:border-b-0 md:border-r border-white/10">
<p class="text-gosign-text-on-dark text-xs uppercase tracking-wider mb-1">Architecture A</p>
<p class="text-white font-bold text-xl mb-6">Trained Model</p>

<div class="space-y-5">
<div>
<p class="text-gosign-text-on-dark text-sm mb-1">"Why this decision?"</p>
<p class="text-white text-sm">"Model has learned" - black box</p>
<p class="text-red-400 text-xs mt-1">Not explainable</p>
</div>

<div>
<p class="text-gosign-text-on-dark text-sm mb-1">"Regulation changes?"</p>
<p class="text-white text-sm">Retrain. 2 - 4 weeks, $5,000 - $20,000</p>
<p class="text-red-400 text-xs mt-1">Expensive and slow</p>
</div>

<div>
<p class="text-gosign-text-on-dark text-sm mb-1">"Can the affected person contest?"</p>
<p class="text-white text-sm">Contest what? Model weights?</p>
<p class="text-red-400 text-xs mt-1">Not contestable</p>
</div>

<div>
<p class="text-gosign-text-on-dark text-sm mb-1">"New LLM model available?"</p>
<p class="text-white text-sm">New training required. Weeks, lock-in.</p>
<p class="text-red-400 text-xs mt-1">Vendor dependency</p>
</div>

<div>
<p class="text-gosign-text-on-dark text-sm mb-1">"EU AI Act compliant?"</p>
<p class="text-white text-sm">Art. 13: Transparency missing. Art. 14: Intervention = replace model. Art. 86: Explanation not possible.</p>
<p class="text-red-400 text-xs mt-1">Problematic</p>
</div>

<div class="pt-4 border-t border-white/10">
<p class="text-red-400 font-bold text-sm">Lock-in: Yes | Audit: Difficult | EU AI Act: Problematic</p>
</div>
</div>
</div>

<!-- Right column: Configured -->
<div class="p-6 sm:p-8">
<p class="text-gosign-accent-on-dark text-xs uppercase tracking-wider mb-1">Architecture B</p>
<p class="text-white font-bold text-xl mb-6">Configured Agent</p>

<div class="space-y-5">
<div>
<p class="text-gosign-text-on-dark text-sm mb-1">"Why this decision?"</p>
<p class="text-white text-sm">"Travel expense rule v2026-01, absence 14h15min"</p>
<p class="text-green-400 text-xs mt-1">Rule, version, context documented</p>
</div>

<div>
<p class="text-gosign-text-on-dark text-sm mb-1">"Regulation changes?"</p>
<p class="text-white text-sm">Update the rule. Effective immediately, $0.</p>
<p class="text-green-400 text-xs mt-1">Versioned and auditable</p>
</div>

<div>
<p class="text-gosign-text-on-dark text-sm mb-1">"Can the affected person contest?"</p>
<p class="text-white text-sm">"Breakfast was not included." Reviewer checks.</p>
<p class="text-green-400 text-xs mt-1">Contestable with decision record</p>
</div>

<div>
<p class="text-gosign-text-on-dark text-sm mb-1">"New LLM model available?"</p>
<p class="text-white text-sm">Rulebook stays. Zero effort, no lock-in.</p>
<p class="text-green-400 text-xs mt-1">Model-agnostic</p>
</div>

<div>
<p class="text-gosign-text-on-dark text-sm mb-1">"EU AI Act compliant?"</p>
<p class="text-white text-sm">Decision record per Micro-Decision. Override the rule, not the model.</p>
<p class="text-green-400 text-xs mt-1">Compliant by design</p>
</div>

<div class="pt-4 border-t border-white/10">
<p class="text-green-400 font-bold text-sm">Lock-in: No | Audit: By Design | EU AI Act: Compliant</p>
</div>
</div>
</div>

</div>
</div>
</div>

The compliance problem is only the surface. Beneath it lies an architecture problem.

## 92% vs. 72%

Researchers tested in 2025 how well an LLM can review legal invoices against billing guidelines.<sup>[1]</sup> No fine-tuning. No training. Just the rulebook as context.

The result:

<!-- 92% vs. 72% bar comparison -->
<div class="not-prose my-10">
<div class="bg-gosign-dark rounded-card p-6 sm:p-8 text-white">
<p class="text-h3 font-bold mb-6">Legal invoice: compliant or not?</p>
<p class="text-gosign-text-on-dark text-sm mb-8">Better Bill GPT, Whitehouse et al. (April 2025). Peer-reviewed. LLM received rulebook as context, no fine-tuning.<sup>[1]</sup></p>

<!-- Overall accuracy -->
<div class="mb-8">
<p class="text-gosign-text-on-dark text-xs uppercase tracking-wider mb-3">Overall accuracy</p>

<div class="mb-4">
<div class="flex justify-between items-center mb-1">
<p class="text-sm font-medium">LLM (no training)</p>
<p class="text-gosign-accent-on-dark font-bold text-lg">92%</p>
</div>
<div class="w-full bg-white/10 rounded-full h-4">
<div class="bg-gosign-accent rounded-full h-4" style="width: 92%"></div>
</div>
</div>

<div class="mb-4">
<div class="flex justify-between items-center mb-1">
<p class="text-sm font-medium">Experienced lawyers</p>
<p class="text-gosign-text-on-dark font-bold text-lg">72%</p>
</div>
<div class="w-full bg-white/10 rounded-full h-4">
<div class="bg-white/30 rounded-full h-4" style="width: 72%"></div>
</div>
</div>
</div>

<!-- F-Score line items -->
<div class="mb-8">
<p class="text-gosign-text-on-dark text-xs uppercase tracking-wider mb-3">Line item classification (F-Score)</p>

<div class="mb-4">
<div class="flex justify-between items-center mb-1">
<p class="text-sm font-medium">LLM (no training)</p>
<p class="text-gosign-accent-on-dark font-bold text-lg">81%</p>
</div>
<div class="w-full bg-white/10 rounded-full h-4">
<div class="bg-gosign-accent rounded-full h-4" style="width: 81%"></div>
</div>
</div>

<div class="mb-4">
<div class="flex justify-between items-center mb-1">
<p class="text-sm font-medium">Best human group</p>
<p class="text-gosign-text-on-dark font-bold text-lg">43%</p>
</div>
<div class="w-full bg-white/10 rounded-full h-4">
<div class="bg-white/30 rounded-full h-4" style="width: 43%"></div>
</div>
</div>
</div>

<!-- Time and cost -->
<div class="grid grid-cols-1 sm:grid-cols-2 gap-6">

<div>
<p class="text-gosign-text-on-dark text-xs uppercase tracking-wider mb-3">Time per invoice</p>
<div class="mb-3">
<div class="flex justify-between items-center mb-1">
<p class="text-sm font-medium">LLM</p>
<p class="text-gosign-accent-on-dark font-bold">3.6 sec</p>
</div>
<div class="w-full bg-white/10 rounded-full h-3">
<div class="bg-gosign-accent rounded-full h-3" style="width: 1.4%"></div>
</div>
</div>
<div>
<div class="flex justify-between items-center mb-1">
<p class="text-sm font-medium">Lawyers</p>
<p class="text-gosign-text-on-dark font-bold">~250 sec</p>
</div>
<div class="w-full bg-white/10 rounded-full h-3">
<div class="bg-white/30 rounded-full h-3" style="width: 100%"></div>
</div>
</div>
</div>

<div>
<p class="text-gosign-text-on-dark text-xs uppercase tracking-wider mb-3">Cost per invoice</p>
<div class="mb-3">
<div class="flex justify-between items-center mb-1">
<p class="text-sm font-medium">LLM</p>
<p class="text-gosign-accent-on-dark font-bold">&lt; $0.01</p>
</div>
<div class="w-full bg-white/10 rounded-full h-3">
<div class="bg-gosign-accent rounded-full h-3" style="width: 0.2%"></div>
</div>
</div>
<div>
<div class="flex justify-between items-center mb-1">
<p class="text-sm font-medium">Lawyers</p>
<p class="text-gosign-text-on-dark font-bold">$4.27</p>
</div>
<div class="w-full bg-white/10 rounded-full h-3">
<div class="bg-white/30 rounded-full h-3" style="width: 100%"></div>
</div>
</div>
</div>

</div>

<p class="text-gosign-text-on-dark text-xs mt-6 border-t border-white/10 pt-4">Cost reduction: 99.97%.<sup>[4]</sup> The mechanism is transferable to any rule-based compliance task.</p>
</div>
</div>

The LLM was not trained on invoices. It received the billing guidelines as context. And decided immediately.

### Why the LLM Performed Better

Not because it is smarter. Because it applies the same rule at 3 PM exactly as it does at 9 AM. Inconsistency is the human problem, not incompetence.<sup>[1]</sup>

Experienced lawyers make 72% correct decisions - but each lawyer makes different wrong decisions. The errors are not systematic but random. Fatigue, time pressure, personal interpretation. An LLM knows no fatigue.

### The Transferable Mechanism

Whether the rulebook is called "billing guideline", "per diem regulation" or "travel expense policy": check document against rule, identify deviation, document decision. The mechanism is identical.

<!-- Summary table: Rulebook application -->
<div class="not-prose my-8">
<div class="overflow-x-auto">
<table class="w-full border-collapse text-sm">
<thead>
<tr class="bg-gosign-dark text-white">
<th class="p-3 text-left font-bold">Dimension</th>
<th class="p-3 text-left font-bold">Trained Model</th>
<th class="p-3 text-left font-bold">Configured Agent</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border bg-gosign-white">
<td class="p-3 font-medium text-gosign-dark">Rule change</td>
<td class="p-3 text-gosign-text">Retraining (weeks, $5k - $20k)</td>
<td class="p-3 text-gosign-text">Rulebook update (minutes, $0)</td>
</tr>
<tr class="border-b border-gosign-border bg-gosign-light">
<td class="p-3 font-medium text-gosign-dark">Explainability</td>
<td class="p-3 text-gosign-text">"Model has learned" (black box)</td>
<td class="p-3 text-gosign-text">Rule + version + context (decision record)</td>
</tr>
<tr class="border-b border-gosign-border bg-gosign-white">
<td class="p-3 font-medium text-gosign-dark">Contestability</td>
<td class="p-3 text-gosign-text">Not possible (no decision record)</td>
<td class="p-3 text-gosign-text">Yes (affected person sees rule and can object)</td>
</tr>
<tr class="border-b border-gosign-border bg-gosign-light">
<td class="p-3 font-medium text-gosign-dark">Model switch</td>
<td class="p-3 text-gosign-text">New training required (lock-in)</td>
<td class="p-3 text-gosign-text">Zero effort (model-agnostic)</td>
</tr>
<tr class="border-b border-gosign-border bg-gosign-white">
<td class="p-3 font-medium text-gosign-dark">Audit trail</td>
<td class="p-3 text-gosign-text">Input + output (no justification)</td>
<td class="p-3 text-gosign-text">Input + rule + version + confidence + result</td>
</tr>
<tr class="border-b border-gosign-border bg-gosign-light">
<td class="p-3 font-medium text-gosign-dark">EU AI Act (Aug 2026)</td>
<td class="p-3 text-gosign-text">Art. 13, 14, 86: Problematic</td>
<td class="p-3 text-gosign-text">Art. 13, 14, 86: Compliant by design</td>
</tr>
<tr class="bg-gosign-white">
<td class="p-3 font-medium text-gosign-dark">Break-even fine-tuning</td>
<td class="p-3 text-gosign-text">From ~35,000 queries/month<sup>[6]</sup></td>
<td class="p-3 text-gosign-text">Economical immediately</td>
</tr>
</tbody>
</table>
</div>
</div>

A study by Chauhan et al. (2025) puts the break-even point of fine-tuning versus prompting at roughly 35,000 queries per month.<sup>[6]</sup> Most enterprise HR and finance processes operate well below that.

## Three Things Instead of Training

If not training, then what? Three components replace what fine-tuning promises but structurally cannot deliver.

### 1. Rulebook

Everything an agent needs to know is in a regulation, a directive, a collective agreement or a company policy. These rules change. Tax law changes annually. Per diem rates change annually. EU regulations change.

A trained model must be retrained with every change. A rulebook is updated. Effective immediately, versioned, auditable. No GPU cluster, no evaluation cycle, no regression risks.

RAG (Retrieval Augmented Generation) reduces factual errors by up to 50%.<sup>[11]</sup> Not because the model gets smarter. Because it sees the current rule instead of retrieving an outdated weight.

### 2. Context

The agent does not need 10,000 historical expense reports. It needs this one report: travel date, departure, return, hotel, breakfast included or not. That is the context of this decision.

It is supplied through structured inputs or RAG, not trained in. When the context changes - different trip, different employee - the decision changes. Not the model.

A concrete example: the [travel expense engine](/en/services/travel-decision-layer/) checks per diem allowances against the applicable tax regulation. In Germany, this is Section 9 of the Income Tax Act (EStG). The context is the individual trip. The rulebook is the current tax law. The foundation model is interchangeable.

### 3. Decision Framework

Who decides what? Not every decision in a process is equal.

The per diem allowance is rulebook: tax regulation, deterministic, 100% confidence. The question of whether an entertainment expense is "reasonable" is judgement: human. The classification of an illegible receipt is AI: LLM extraction, probabilistic.

This decomposition into Micro-Decisions with assignment to human / rulebook / AI is the real architecture work. Not training. The [Decision Layer](/en/decision-layer/) formalises exactly this decomposition. Architecture details: [Decision Layer explained](/en/magazine/decision-layer-explained/).

<!-- Micro-Decision Demo -->
<div class="not-prose my-10">
<div class="bg-gosign-light border border-gosign-border rounded-card overflow-hidden">
<div class="p-6 sm:p-8">
<p class="text-h3 font-bold text-gosign-dark mb-2">Micro-Decision in Practice</p>
<p class="text-gosign-text text-sm mb-6">Travel expense report: 8-hour day, domestic trip, hotel with breakfast</p>

<div class="space-y-3">

<div class="bg-gosign-white border border-gosign-border rounded-lg p-4">
<div class="flex flex-wrap items-center gap-3">
<span class="text-xs font-mono bg-gosign-dark text-white px-2 py-0.5 rounded">#1</span>
<span class="font-medium text-gosign-dark text-sm">Travel date and absence duration</span>
<span class="text-xs px-2 py-0.5 rounded bg-blue-100 text-blue-800 font-medium">Context</span>
<span class="text-xs text-gosign-text-light ml-auto">Input: receipts</span>
</div>
</div>

<div class="bg-gosign-white border border-gosign-border rounded-lg p-4">
<div class="flex flex-wrap items-center gap-3">
<span class="text-xs font-mono bg-gosign-dark text-white px-2 py-0.5 rounded">#2</span>
<span class="font-medium text-gosign-dark text-sm">Calculate per diem allowance</span>
<span class="text-xs px-2 py-0.5 rounded bg-green-100 text-green-800 font-medium">Rulebook</span>
<span class="text-xs text-gosign-text-light ml-auto">Tax regulation v2026-01</span>
</div>
</div>

<div class="bg-gosign-white border border-gosign-border rounded-lg p-4">
<div class="flex flex-wrap items-center gap-3">
<span class="text-xs font-mono bg-gosign-dark text-white px-2 py-0.5 rounded">#3</span>
<span class="font-medium text-gosign-dark text-sm">Apply breakfast deduction</span>
<span class="text-xs px-2 py-0.5 rounded bg-green-100 text-green-800 font-medium">Rulebook</span>
<span class="text-xs text-gosign-text-light ml-auto">Per diem deduction rule, versioned</span>
</div>
</div>

<div class="bg-gosign-white border border-gosign-border rounded-lg p-4">
<div class="flex flex-wrap items-center gap-3">
<span class="text-xs font-mono bg-gosign-dark text-white px-2 py-0.5 rounded">#4</span>
<span class="font-medium text-gosign-dark text-sm">Classify receipt</span>
<span class="text-xs px-2 py-0.5 rounded bg-gosign-accent/10 text-gosign-accent font-medium">AI</span>
<span class="text-xs text-gosign-text-light ml-auto">LLM extraction, confidence: 87%</span>
</div>
</div>

<div class="bg-gosign-white border border-gosign-border rounded-lg p-4">
<div class="flex flex-wrap items-center gap-3">
<span class="text-xs font-mono bg-gosign-dark text-white px-2 py-0.5 rounded">#5</span>
<span class="font-medium text-gosign-dark text-sm">Entertainment expense "reasonable"?</span>
<span class="text-xs px-2 py-0.5 rounded bg-yellow-100 text-yellow-800 font-medium">Human</span>
<span class="text-xs text-gosign-text-light ml-auto">Judgement, reviewer decides</span>
</div>
</div>

<div class="bg-gosign-white border border-gosign-border rounded-lg p-4">
<div class="flex flex-wrap items-center gap-3">
<span class="text-xs font-mono bg-gosign-dark text-white px-2 py-0.5 rounded">#6</span>
<span class="font-medium text-gosign-dark text-sm">Create audit-compliant booking entry</span>
<span class="text-xs px-2 py-0.5 rounded bg-green-100 text-green-800 font-medium">Rulebook</span>
<span class="text-xs text-gosign-text-light ml-auto">Record-keeping regulation, versioned</span>
</div>
</div>

</div>

<div class="mt-6 p-4 bg-gosign-dark rounded-lg">
<p class="text-gosign-text-on-dark text-sm">Each step has a fixed type: <span class="text-green-400">Rulebook</span> (deterministic), <span class="text-gosign-accent-on-dark">AI</span> (probabilistic, with confidence threshold) or <span class="text-yellow-400">Human</span> (judgement). When the tax regulation changes, the rule is updated. No retraining. No new model.</p>
</div>
</div>
</div>
</div>

## The Three Layers: Architecture Instead of Training

The architecture behind a configured agent consists of three layers. Each layer is independently replaceable.

<!-- Three-layer diagram -->
<div class="not-prose my-10">
<div class="max-w-2xl mx-auto">

<div class="bg-gosign-dark border-2 border-gosign-accent rounded-t-card p-6">
<div class="flex items-center gap-3 mb-3">
<span class="text-gosign-accent-on-dark text-xs uppercase tracking-wider font-bold">Layer 3</span>
<span class="text-white font-bold text-lg">Decision Layer</span>
</div>
<div class="flex flex-wrap gap-2">
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Micro-Decisions</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Human / Rulebook / AI</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Decision Record</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Audit Trail</span>
</div>
</div>

<div class="bg-gosign-dark border-x-2 border-gosign-accent p-6 border-t border-white/10">
<div class="flex items-center gap-3 mb-3">
<span class="text-gosign-accent-on-dark text-xs uppercase tracking-wider font-bold">Layer 2</span>
<span class="text-white font-bold text-lg">Rulebook (versioned, replaceable)</span>
</div>
<div class="flex flex-wrap gap-2">
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Tax law</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Per diem rules</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Record-keeping</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Collective agreement</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Company policy</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">EU AI Act</span>
</div>
</div>

<div class="bg-gosign-darker border-2 border-white/20 rounded-b-card p-6">
<div class="flex items-center gap-3 mb-3">
<span class="text-gosign-text-on-dark text-xs uppercase tracking-wider font-bold">Layer 1</span>
<span class="text-white font-bold text-lg">Foundation Model (replaceable)</span>
</div>
<div class="flex flex-wrap gap-2">
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Claude</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">GPT</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Llama</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Mistral</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Gemini</span>
</div>
</div>

<div class="mt-4 flex items-start gap-3 p-4 bg-gosign-light border border-gosign-border rounded-card">
<span class="text-gosign-accent text-lg mt-0.5">&#x2191;</span>
<p class="text-gosign-text text-sm">Everything above Layer 1 remains when the model changes. Rulebook, Decision Layer, decision records, audit trail - all model-agnostic. No retraining. No lock-in.</p>
</div>

</div>
</div>

Why three layers? Because each has a different responsibility.

The foundation model provides language understanding and reasoning. It understands context, extracts information from documents, classifies inputs. It does not need to know what a specific tax regulation says. It needs to understand what a regulatory text is.

The rulebook contains the business logic. Regulations, directives, collective agreements, company policies. Every rule has a version. Every version has an effective date. When the regulation changes, the rule is updated. Not the model.

The [Decision Layer](/en/decision-layer/) governs who may decide what. It decomposes processes into decision steps. Defines for each: human, rulebook or AI. Documents every decision with rule, version, context and result.

## What Training Really Costs

Not in dollars. In dependencies.

### Lock-in

A fine-tuned model ties you to that vendor. The training set, the weights, the evaluation pipeline: all proprietary. Model switch = new training = new costs = new time loss.

A configured agent switches the foundation model without changing a single rule. Claude today, GPT tomorrow, an open-source model next week. The rulebook stays. The Decision Layer stays. The decision records stay.

### Maintenance

Every regulatory change requires retraining. In finance, tax law, treasury guidance and social security contribution rates change annually. In HR, collective agreements, framework agreements and EU regulation change.

A trained agent needs continuous maintenance that looks like a software project. A configured agent needs a rulebook editor.

MIT and Stanford (Choi & Xie, 2025) show: AI reduces the monthly close by 7.5 days.<sup>[7]</sup> But 62% of accountants worry about AI errors.<sup>[8]</sup> The concern is justified - with trained models. With configured agents that have decision records and contestability, every error is identifiable and correctable.

### Explainability

A trained model can tell you what it decided. It cannot tell you why.

"The model has learned" is not a justification a tax auditor accepts. No employee representative body accepts it. No rejected candidate accepts it.

"Travel expense rule v2026-01, applied to absence of 14h15min" is a justification.

If you cannot explain the decision, you cannot let it be contested. And if it cannot be contested, it does not meet the EU AI Act high-risk obligations - which apply from 2 August 2026 under current law, with a postponement to 2 December 2027 provisionally agreed under the Digital Omnibus of 7 May 2026 (formal adoption still pending, as of June 2026).<sup>[10]</sup>

### Does Fine-Tuning Have Its Place?

Yes. From roughly 35,000 queries per month with a stable rulebook, fine-tuning becomes economical.<sup>[6]</sup> Language adaptation, domain-specific jargon, latency optimisation: there are good reasons for it.

But where the industry sells it today - enterprise HR and finance with annually changing regulations - it is the wrong architecture decision. Gartner predicts that over 40% of agentic AI projects will fail by 2027.<sup>[9]</sup> Not because of model performance. Because of governance.

## The Question Your Board Should Ask

Not: "What data was your agent trained on?"

But:

**1. Which rulebook underlies the decision? Which version was in effect at the time of the decision?**

If the answer is "that is in the model", there is no version. No change history. No audit trail.

**2. What happens when the rule changes? Retraining or update?**

If the answer is "we retrain", you are paying for maintenance that is unnecessary.

**3. Can the affected person see and contest the individual decision?**

If there is no answer, you have a compliance gap to close before the high-risk deadline - 2 August 2026 under current law, provisionally set to move to 2 December 2027 under the Digital Omnibus of 7 May 2026 (formal adoption still pending, as of June 2026). Art. 86 EU AI Act: right to explanation. Not optional.<sup>[10]</sup>

## Gosign's Approach

Gosign's Decision Layer is an implementation of this architecture. It decomposes processes into decision steps. Defines for each: human, rulebook or AI. Rulebooks are versioned. Decisions are auditable. Results are contestable.

[48 HR agents](/en/hr-agent-catalog/) and [49 finance agents](/en/finance-agent-catalog/), each with a Micro-Decision table. No fine-tuning. No lock-in. No retraining when regulations change.

---

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">References</p>
<ol class="text-sm text-gosign-text space-y-2 list-decimal list-inside">
<li id="fn1">Better Bill GPT, Whitehouse et al. (April 2025). Legal Invoice Review: LLM achieves 92% accuracy reviewing legal invoices against billing guidelines. Peer-reviewed.</li>
<li id="fn2">Better Bill GPT, Whitehouse et al. (April 2025). F-Score for line item classification: LLM 81% vs. best human group 43%.</li>
<li id="fn3">Better Bill GPT, Whitehouse et al. (April 2025). Processing time per invoice: LLM 3.6 seconds vs. experienced lawyers 194 to 316 seconds.</li>
<li id="fn4">Better Bill GPT, Whitehouse et al. (April 2025). Cost reduction in legal invoice review: 99.97% ($4.27 vs. <$0.01 per invoice).</li>
<li id="fn5">Kumar Gauraw (March 2026). "Most reach for fine-tuning too early."</li>
<li id="fn6">Chauhan et al., Journal of Information Systems Engineering (2025). Break-even fine-tuning vs. prompting: ~35,000 queries per month.</li>
<li id="fn7">MIT/Stanford, Choi & Xie (August 2025). AI reduces the monthly close by an average of 7.5 days.</li>
<li id="fn8">MIT/Stanford, Choi & Xie (August 2025). 62% of accountants express concerns about AI errors in financial processes.</li>
<li id="fn9">Gartner (June 2025). Prediction: Over 40% of agentic AI projects will fail by 2027.</li>
<li id="fn10">EU AI Act (Regulation 2024/1689), Crowell & Moring (February 2026). High-risk obligations from 2 August 2026 under current law, with a postponement to 2 December 2027 provisionally agreed under the Digital Omnibus of 7 May 2026 (formal adoption still pending, as of June 2026): Art. 13 (transparency), Art. 14 (human oversight), Art. 86 (right to explanation). Annex III(4): recruiting as high-risk system.</li>
<li id="fn11">IBM (2024). RAG reduces factual errors in LLM outputs by up to 50%.</li>
</ol>
</div>

--- How to Audit an HR Workflow for Agent Readiness ---
> Break down HR processes into decision points, classify each for human/rule-based/AI - and translate the result into a Decision Layer specification that satisfies EU AI Act challengeability.

## "Which HR processes are AI-eligible?" is the wrong question

An HR leader sits in the steering committee of her AI program. The slide says: "Phase 1 - automate sick-leave processing." Six weeks later the pilot is paused. The reason: "Doesn't work reliably enough." What happened? The project treated the workflow as a single unit. But sick-leave processing is not a unit. It is a sequence of twelve decision points - and two of them should have remained with the human.

That is not an anecdote. It is the pattern. AI projects in HR rarely fail at model quality and almost always at the granularity of the question. Whoever asks "Which workflows do we automate?" gets unusable answers. Whoever asks "At which decision points within a workflow?" gets a buildable architecture.

This methodology describes how to ask the right question. It is technology-agnostic - no model preference, no vendor, no stack. It produces four artefacts from one audit: an agent design, a works-agreement template, a Decision Layer specification, and the [EU AI Act documentation due for the high-risk deadline of 2 August 2026](/en/magazine/eu-ai-act-applies-worldwide/) (which the provisional Digital Omnibus agreement of 7 May 2026 is set to move to 2 December 2027, formal adoption still pending).

McKinsey [estimates](https://www.mckinsey.com/capabilities/people-and-organizational-performance/our-insights/generative-ai-and-the-future-of-hr) that 60 - 70 % of administrative HR activities are automatable with existing technology. Adoption sits at 3 %. The gap is not skepticism. It is the absence of a method that breaks workflow level down to decision-point level.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">At a Glance</p>
<ul class="text-body text-gosign-text space-y-2">
<li>"Automating the workflow" fails. Classifying individual decision points produces an auditable architecture.</li>
<li>A typical HR process has 10 - 30 decision points. Experienced staff make most of them unconsciously - which is why they are missing from the requirements document.</li>
<li>Every decision point is human, rule-based, or AI-eligible - with three explicit tests, not gut feel. Ambiguity is the most common audit trap.</li>
<li>The audit output is simultaneously agent design, works-agreement template, Decision Layer specification, and EU AI Act documentation. Four stakeholders, one document.</li>
<li>Challengeability is architecture, not compliance afterthought. Bolting it on later means no auditable AI - regardless of model quality.</li>
</ul>
</div>

## A typical HR process has twelve decision points, not one

Mapping precedes classification. It fails because of a quirk of experienced employees: they make many decisions unconsciously. "Check whether the sick note has a start date" is not perceived as a decision. They just do it. To an agent, every such check is an explicit decision that must be specified.

The method that surfaces these implicit decisions is the "what could go wrong" technique: for each step, ask what could fail or require a different action. Each answer reveals a decision point.

Before mapping, draw the workflow boundary. A workflow has a trigger, a sequence of processing steps, and one or more endpoints. Common mistake: drawing it too wide. "Onboarding" is not one workflow - it is a collection of five to eight sub-workflows (contract generation, IT provisioning, compliance documentation, workspace setup, training enrollment, buddy assignment, probation tracking). Audit each sub-workflow separately.

Take sick-leave processing - trigger: employee submits a sick note. Endpoints: SAP record updated, manager notified, payroll adjusted, return-to-work action scheduled if threshold exceeded. What most organizations describe as one step is a chain of twelve:

| # | Decision point | Question the process answers |
|---|---------------|------------------------------|
| 1 | Document receipt | Sick note, doctor's certificate, rehabilitation notice, or something else? |
| 2 | Completeness check | Employee name, diagnosis period, doctor's name, doctor's signature present? |
| 3 | Employee identification | Which employee does this belong to? |
| 4 | Entity assignment | Which legal entity is the employee in? |
| 5 | Collective agreement lookup | Which collective agreement applies? |
| 6 | Continued pay eligibility | 6-week period [§ 3 EFZG (DE)](https://www.gesetze-im-internet.de/entgfg/__3.html) satisfied? Waiting period? |
| 7 | Duration assessment | Single day, short absence, or extended absence? |
| 8 | Pattern detection | Threshold for [BEM obligation (DE)](https://www.gesetze-im-internet.de/sgb_9_2018/__167.html) crossed? |
| 9 | Payroll impact | Overtime cancellation, shift differential, bonus proration? |
| 10 | System update | What changes in SAP/SuccessFactors? |
| 11 | Notification routing | Who is informed (manager, HRBP, payroll, works council)? |
| 12 | Follow-up scheduling | Return date, BEM invitation, occupational-health referral? |

Twelve decision points in a process most organizations describe as "employee submits sick note, we process it." The gap between perceived simplicity and actual complexity is typical - and the reason "we automate sick leave" as a project goal produces no architecture.

## Three decision types, three tests, one classification

Each decision point falls into exactly one of three types. Classification is binary. Ambiguity points to an audit error, not a special case.

**Type H - human decides.** Empathy, individual judgment, legal risk if automated, works-council co-determination mandate, or ethical sensitivity. Test question: "Would two different experienced professionals reliably reach the same conclusion on the same case?" If no - Type H. The human stays where law requires it. Not because they are better at it.

**Type R - rule-based, deterministic.** The rule exists in writing (law, collective agreement, works agreement, documented procedure). Inputs are structured. The output is deterministic. Exceptions are themselves rule-based - or they are separate Type-H decision points. Test question: "Could I write this decision as a spreadsheet formula?" If yes - Type R.

**Type A - AI-eligible, probabilistic with bounds.** The task is classification, extraction, or matching - not generation, judgment, or evaluation. The set of outcomes is known and finite. The result is verifiable. A confidence threshold can be set; uncertain cases escalate. Test question: "Am I interpreting information against known categories, or judging a unique situation?" If categories - Type A.

The sick-leave table classifies as follows:

| # | Decision point | Type | Reasoning |
|---|---------------|------|-----------|
| 1 | Document classification | A | Unstructured input, classified into known categories, confidence-scoreable |
| 2 | Completeness check | A | Field extraction with known required fields, verifiable |
| 3 | Employee identification | A | Name matching with fuzzy match, confidence-scoreable |
| 4 | Entity assignment | R | Employee-ID → entity, deterministic lookup |
| 5 | Collective agreement lookup | R | Entity + employee category → CA, deterministic |
| 6 | Continued pay eligibility | R | Start date + history + § 3 EFZG, pure calculation |
| 7 | Duration assessment | R | Calendar arithmetic |
| 8 | Pattern detection | R | Threshold calculation (response to threshold is a separate H point) |
| 9 | Payroll impact | R | Absence type + pay rules |
| 10 | System update | R | Execution step from 4 - 9 |
| 11 | Notification routing | R | Routing rules from entity, type, threshold |
| 12 | Follow-up scheduling | R | Rule-based (the conversation itself is H, separate workflow) |

Eight Type R, three Type A, no Type H. The follow-up actions that require human judgment (the BEM conversation, the return-to-work interview) are separate workflows with their own classification - they sit outside sick-leave processing.

## The score doesn't say "if", it says "where the human stays"

Out of the classification comes a simple ratio: (Type R + Type A) ÷ total × 100. Sick leave scores 91.7 %. That is high. It does not mean "less human." It means 91.7 % of individual decisions can be taken architecturally - while human oversight focuses on what law and empathy actually require.

The score thresholds are deployment logic, not a scale:

| Score | What it says | What to do |
|-------|--------------|------------|
| > 80 % | High agent readiness | Implement now. Governance design focuses on the few H handoffs. |
| 60 - 80 % | Moderate readiness | Phased. R and A first, H stays manual. Meaningful human-in-the-loop load. |
| 40 - 60 % | Mixed readiness | Automate only the rule-based sub-processes. A full agent doesn't pay off yet. |
| < 40 % | Low readiness | Not recommended. Process documentation and standardisation first. |

Typical scores by HR domain: payroll & compensation 85 - 95 %, time & attendance 80 - 90 %, expense processing 75 - 85 %, onboarding administration 60 - 75 %, benefits enrollment 65 - 80 %, recruiting screening 40 - 55 %, performance management 20 - 35 %, employee relations 15 - 30 %. Recruiting and performance score lower not because they are technically impossible, but because they are [high-risk systems under Annex III of the EU AI Act](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689#anx_3) and human oversight carries more weight.

## One audit output, four stakeholders

Per decision point, a structured record is produced: ID and description, classification with reasoning, rule source (for R) with version and validity period, confidence threshold (for A), escalation path with deadline, audit-trail specification, and challenge path. That record has four recipients:

The **engineering team** reads the classification as architecture spec. Where R, the rules engine; where A, a model call with confidence capture; where H, a task in the human queue. The record directly specifies the [Decision Layer](/en/magazine/decision-layer-explained/) - the layer between agent and target system that orchestrates rule-based and AI-based decisions, generates the audit trail, and routes escalations.

The **works council** reads the same data as a co-determination template. They see which decisions are automated, with what reasoning, with what escalation. A framework works agreement can be derived directly from the audit, often faster than negotiating domain-specific agreements one by one.

The **auditor** reads rule versions and audit-trail specs as evidence integrity. Which rule applied when, on what data, by whom. The answer is in the record, not in a separate compliance document.

The **data protection authority** reads the same data as EU AI Act and GDPR documentation. [Art. 11 (technical documentation)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689#art_11), [Art. 12 (record-keeping)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689#art_12), [Art. 86 (right to explanation)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689#art_86), and [Art. 22 GDPR](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679#art_22) require exactly this information.

Four functions from one document. The audit doesn't produce them as a side effect - it is constructed for it.

## Challengeability is architecture, not compliance afterthought

An automated decision about a person is permissible under the EU AI Act and GDPR only if the affected person can challenge it. Challengeability is not a duty bolted on later - it is an architectural requirement planned in from the first audit.

Per decision point, the audit answers four questions that together make a challenge possible. Which rule or model decided, in which version? Without versioning, later reproduction is impossible. What data underpinned the decision - the exact inputs at the time of the decision, not today's? Who decided - human, rule, or AI - and at what confidence? How does the person file an objection - with concrete address, deadline, and next instance?

A consequence of the architecture: the agent itself does not make "decisions" in the legal sense. It executes operations the Decision Layer has authorised. That is not semantic hair-splitting. It is the foundation that keeps decisions auditable when the AI model is replaced, the vendor is switched, or a flaw in the model is discovered.

The high-risk classification of the EU AI Act applies directly to many HR workflows: recruiting screening, performance management, promotion and transfer decisions, shift routing where it affects personnel benefits (Annex III no. 4 lit. a and b). [Art. 26(7)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689#art_26) additionally requires informing workers' representatives and affected workers **before** deployment - not afterwards. The audit must therefore answer per workflow: does this workflow fall under Annex III? If yes - the obligations from Art. 11, Art. 14, Art. 15, and Art. 26 attach, and the prior-information duty is a precondition for going live.

For organisations outside the EU: the requirements the EU AI Act lists explicitly are already enforceable in nearly every legal system as the interpretation of general duties of care - just without an explicit obligation list. [Whoever builds the Decision Layer to be EU-AI-Act-compliant](/en/magazine/eu-ai-act-applies-worldwide/) also satisfies what California, Brazilian, and UK data-protection authorities will demand in case of inspection.

## Four classification errors distort every audit

**A rule with judgment-bound exceptions is classified as Type R.** "Overtime at 150 %" sounds rule-based. But: holiday at 200 %? Shift crossing midnight into a holiday? Individual contract overriding the collective agreement? When exceptions require judgment, the exception path is Type H - even if the standard case is Type R. Clean fix: the standard case as R, a separate decision point for exception handling as H or A.

**An unverifiable AI output is classified as Type A.** "The AI evaluates whether the candidate is a cultural fit." That is not Type A - there is no verifiable correct answer. Cultural fit is subjective. Type A requires verifiability: "the AI classified this document as a sick note" can be validated by two humans on the same document. Subjective evaluations are Type H - always.

**The trigger decision is conflated with the downstream action.** "Pattern detection triggers a BEM process" - the detection is Type R (threshold), but the BEM process contains Type H decisions (return-to-work planning). The audit must separate the trigger from the triggered workflow.

**Implicit decisions are ignored.** "We check the sick note" sounds like one step. It contains at least three decisions: valid document, complete, matches the employee. The audit must decompose until each point has exactly one question and one classification.

## What this methodology does not solve

The audit delivers agent readiness at decision-point level and the Decision Layer specification. It does not deliver: sequencing across workflows (that depends on transaction volume, governance complexity, organisational appetite; see the [H1-H4 logic in the HR Agent Catalog](/en/hr-agent-catalog/#sequencing-matrix)), technology selection, organisational change, or the works-council negotiation strategy. The concrete implementation of the Decision Layer - rules engine, confidence capture, challenge endpoint - is its own topic.

The audit provides the fact base. Strategy and implementation build on it. Whoever starts with strategy and looks at the fact base later, builds the pyramid on its tip.

## Further reading

- [The EU AI Act Applies Worldwide](/en/magazine/eu-ai-act-applies-worldwide/) - why the challengeability obligation does not arise only with the high-risk deadline (2 August 2026, provisionally set to move to December 2027)
- [Three Types of Decisions: When Humans Decide, When AI Decides](/en/magazine/three-types-of-decisions/) - the conceptual basis of the H/R/A classification
- [Decision Layer as Architectural Pattern](/en/magazine/decision-layer-explained/) - how the classification is transferred into an executable layer
- [EU AI Act and HR: High-Risk Classification](/en/magazine/eu-ai-act-hr-high-risk/) - which HR workflows fall under Annex III

--- Works Council and AI: Co-Determination by Design ---
> Works agreements as technical constraints in the Decision Layer. Don't convince the works council, implement their requirements as rules.

Works councils have co-determination rights when AI systems make decisions about employees. The right approach: implement their requirements as technical constraints in the Decision Layer, not as negotiated compromises in a paper document.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">At a Glance - Co-Determination as Architecture Constraint</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Works councils have co-determination rights for AI under BetrVG SS 87 (technical monitoring facilities) and SS 90 (workplace design). AI agents supporting HR decisions require their approval.</li>
<li>The standard approach of "convincing" the works council treats them as a hurdle instead of a requirements source - producing unenforceable paper compromises.</li>
<li>The architectural approach: works agreements become technical rules in the Decision Layer. If the agreement says "no fully automated performance reviews," the system enforces Human-in-the-Loop.</li>
<li>The Auditor Portal gives works councils verifiable transparency - every rule has a Control_ID, technical implementation, and evidence history they can inspect.</li>
<li>Four-step process: analyze existing agreements, draft requirements catalog, implement as controls in Decision Layer, grant Auditor Portal access.</li>
</ul>
</div>

According to the WSI works council survey by the Hans-Böckler-Stiftung (2023/2025), roughly one in ten co-determined private-sector companies in Germany has introduced AI - and the trend is rising. So far only a small share of these companies has a dedicated works agreement specifically governing the use of AI; AI-specific agreements remain far less common than, for example, data-protection agreements. As a result, much of this AI deployment still happens without formal co-determination governance.

<table>
<thead>
<tr><th>Works Agreement Requirement</th><th>Decision Layer Implementation</th><th>Verification</th></tr>
</thead>
<tbody>
<tr><td>No fully automated performance reviews</td><td>Human-in-the-Loop rule (enforced)</td><td>Escalation logs in Auditor Portal</td></tr>
<tr><td>Quarterly report on AI-supported decisions</td><td>Automated report generation</td><td>Portal dashboard with live data</td></tr>
<tr><td>Stop AI on suspected discrimination</td><td>Bias monitoring trigger</td><td>Alert log and incident history</td></tr>
<tr><td>All controls active and functional</td><td>Control_ID per requirement</td><td>Evidence history per control</td></tr>
</tbody>
</table>

## The Usual Approach: Convincing the Works Council

In most companies, AI deployment is treated as a change management project. The works council (Betriebsrat) is informed, convinced, brought along. The goal: getting approval for the works agreement (Betriebsvereinbarung).

This approach has a problem: it treats the works council as a hurdle, not a requirements source. The works agreement ends up as a compromise, written in legal language, filed in a folder. The technical implementation often remains unclear.

## The Better Approach: Co-Determination as Architecture Constraint

In the Gosign architecture, works agreements are implemented as technical constraints in the [Decision Layer](/en/decision-layer/). The works council's requirements are not negotiated as compromises but implemented as rules in the system.

If the works agreement states: "Decisions on performance reviews must not be made fully automated", then this is implemented as a Human-in-the-Loop rule in the Decision Layer. The agent physically cannot bypass this rule.

If the works agreement states: "The works council receives a quarterly report on all AI-supported HR decisions", then the Auditor Portal generates this report automatically.

If the works agreement states: "If discriminatory patterns are suspected, AI usage for the affected process must be stopped immediately", then this becomes a bias monitoring trigger in the Decision Layer.

## What the Works Council Can See

The works council receives access to the Auditor Portal, with a dedicated read-only access restricted to the controls relevant to them.

They can trace: which works agreement rules are implemented as controls, whether all controls are active and functional, how frequently Human-in-the-Loop escalations are triggered, and whether there are anomalies in bias monitoring.

This transparency builds trust, not through promises, but through verifiable technology.

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Free eBook: AI in HR</p>
<p class="text-body text-gosign-text mb-4">EU AI Act (UK: UK AI regulatory framework) checklist, Decision Framework, works council perspective, and readiness assessment - the governance handbook for HR leaders.</p>
<a href="/en/ebook/ai-hr-governance-handbook/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Download for free</a>
</div>

## Practical Implementation

**Step 1:** Analyze existing works agreements. Which provisions affect AI deployment directly or indirectly?

**Step 2:** Draft a new works agreement for AI deployment. Not as a prose document, but as a requirements catalog with specific, technically implementable rules.

**Step 3:** Implement requirements as controls in the Decision Layer. Every requirement receives a Control_ID, a technical implementation, and an evidence generator.

**Step 4:** Grant the works council Auditor Portal access. They can verify at any time whether their requirements are technically implemented.

More on this topic: [Co-Determination and AI](/en/governance/co-determination/)

<a href="/en/contact/" target="_blank" rel="noopener noreferrer">Schedule a consultation</a>. We'll show you how co-determination is implemented technically.

--- Works Council & AI Literacy: The Organizational Questions ---
> Why AI projects fail on organization, not technology. Co-determination as a design requirement and mandatory training since 2025.

## Technology Is Rarely the Problem

When AI projects fail in organizations, the cause is almost never the technology. The models work. The APIs are stable. The infrastructure is available. What fails is the organization: the works council (Betriebsrat) blocks deployment because it was informed too late. Employees do not use the new tools because they were not trained. Roles and responsibilities shift faster than the organization can adapt.

This article addresses the two organizational questions that accompany every AI deployment: How do you gain the works council as an ally? And how do you fulfill the legally mandated AI literacy requirement?

The EU AI Act (Article 4) mandates AI literacy for all users of AI systems since February 2025. Non-compliance penalties reach up to 35 million EUR or 7% of annual turnover.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">At a Glance - Works Council & AI Literacy</p>
<ul class="text-body text-gosign-text space-y-2">
<li>AI projects fail on organization, not technology. The works council and AI literacy are the two decisive factors.</li>
<li>Involve the works council at the architecture stage, not at the result presentation. A Decision Layer makes AI transparent and auditable by design.</li>
<li>AI literacy has been legally mandated since February 2025 (EU AI Act, Article 4). Penalties for non-compliance: up to 35 million EUR or 7% of turnover.</li>
<li>A company agreement (Betriebsvereinbarung) becomes enforceable when its rules are implemented as technical constraints in the Decision Layer.</li>
<li>Role-based training programs turn compliance obligations into competitive advantages: informed employees use AI more effectively.</li>
</ul>
</div>

## Works Council and Co-determination (Mitbestimmung): From Blocker to Enabler

### Why the Works Council Must Be Involved

In German companies, the works council (Betriebsrat) has a co-determination right (Mitbestimmungsrecht) under Section 87(1)(6) of the Works Constitution Act (Betriebsverfassungsgesetz) for any technical system capable of monitoring employee behavior or performance. AI systems almost always fall under this provision: they process usage data, log interactions, and their decisions directly or indirectly affect working conditions. Similar employee representation structures exist in many other European countries, where comparable consultation and co-determination (Mitbestimmung) requirements apply.

This is not an obstacle; it is a design framework. The works council does not have the right to prevent AI. It has the right to shape the conditions of its deployment. That is a distinction frequently overlooked in practice.

The problem arises not from co-determination (Mitbestimmung) itself, but from the timing at which the works council is brought in. In most failed AI projects, the works council is only informed once the technical decision has already been made. It receives a presentation of finished results, has no opportunity to influence the architecture, and responds with the only instrument available: rejection.

### Architecture as the Answer

The works council's questions are legitimate and predictable: What data does the AI system process? Who has access? Is performance data captured? Who makes the final decision, the AI or a human? Can decisions be traced?

A [Decision Layer](/en/decision-layer/) answers these questions technically, not just in a company agreement (Betriebsvereinbarung) on paper. The architectural layer defines:

- **Decision boundaries:** What the AI may prepare, what a rule engine decides, what a human must approve.
- **Human-in-the-loop:** Technically enforced human approval for defined decision classes. No human review can be bypassed because the architecture does not permit it.
- **Audit trail:** Every AI decision is logged: which model, which input, which output, which rule applied, whether a human was involved.
- **Role-based access control (RBAC):** Role-based permissions prevent unauthorized access to sensitive data or functions.

### Company Agreements as System Constraints

The decisive advantage of a well-designed AI architecture: company agreements (Betriebsvereinbarungen) are not merely documented on paper but implemented as technical rules in the system.

**First: Company agreements as configurable rule sets.** What the company agreement states, for example, "Performance data may not be evaluated without the employee's consent", is implemented as a constraint in the Decision Layer. The system cannot bypass the agreement because the rule is technically enforced.

**Second: Transparency through a complete audit trail.** The works council can trace at any time which decisions the AI system made, on what basis, and whether human approvals were granted. No black box, no trust question.

**Third: RBAC prevents uncontrolled access.** Only defined roles have access to specific AI functions. A team lead can use the chatbot but not the performance analysis. An HR manager can view the performance analysis but cannot export raw data. Permissions are granularly configurable.

**Fourth: No profiling without explicit authorization.** The architecture technically ensures that evaluations relating to individuals can only be conducted with explicit authorization, configured in the rule set.

### Practical Recommendation: The Architecture Workshop

Invite the works council to the architecture workshop, not to the results meeting. Half a day in which the works council understands how the Decision Layer works, what data is processed, and how company agreements are technically implemented saves months of negotiations.

Experience shows: when the works council understands the architecture and sees that its concerns are not merely heard but technically implemented, it transforms from a potential blocker into an active supporter. The works council does not want to prevent AI. It wants to ensure that employee rights are preserved. A transparent architecture provides exactly that assurance.

## AI Literacy: a Legal Obligation Since February 2025

### The Legal Basis

Article 4 of the [EU AI Act](/en/magazine/eu-ai-act-2026-enterprises/) obligates all providers and deployers of AI systems to ensure that their employees possess a sufficient level of AI competence. The obligation has been in effect since February 2, 2025, and applies to every organization that deploys AI, regardless of size and regardless of the risk class of the AI system.

The phrase "sufficient level of AI competence" is deliberately open-ended. It must be interpreted in context: a board member who decides on deploying an AI system needs different competencies than a clerk who uses a chatbot. But both need competencies. And both must be documented.

**Penalties:** Violations of the AI literacy obligation fall under the general penalty provisions of the EU AI Act. Maximum fines are up to 35 million euros or 7 percent of global annual turnover. In practice, initial enforcement for literacy-only violations is likely to involve warnings and orders, but the legal basis for substantial penalties exists.

### Who Must Be Trained?

All persons who use, operate, or make decisions about AI systems in any capacity. This includes:

- Board and executive management (decision responsibility)
- Department heads and team leads (usage responsibility)
- Specialists and clerks (operational use)
- IT and development (technical operations)
- Works council (co-determination (Mitbestimmung) responsibility)

### What Must Be Covered?

Content must be context-appropriate. At minimum, four competency areas are recommended:

1. **Foundational understanding of how AI works:** How does a language model function? What is the difference between analysis and decision? What can AI do, what can it not?
2. **Hallucination recognition:** Language models generate plausible-sounding but factually incorrect statements. Users must be able to critically evaluate results.
3. **Responsible use:** What data may be entered? What must not? What happens to inputs? Where are the boundaries of appropriate use?
4. **Data protection:** What personal data may be processed? What consents are required? What data leaves the corporate network?

### How Must Compliance Be Documented?

The EU AI Act requires proof that training has taken place. This means:

- Documentation of training content and materials
- Participant lists with date and signature
- Regular refreshers (recommended: annually; event-driven upon significant system changes)
- Differentiation by role and responsibility

A generic 30-minute webinar does not meet the requirements. Training must be role-specific, address the organization's particular AI systems, and include interactive elements that verifiably assess understanding.

## Practical Recommendation: Enterprise AI Portal as Competency Development

AI literacy does not have to be delivered exclusively through formal training programs. A well-designed [Enterprise AI Portal](/en/magazine/enterprise-ai-chat-interface/) with built-in guidance, disclaimer notices, and feedback mechanisms is already part of competency development.

When employees interact with AI in a controlled environment that explains what the model is doing, flags limitations, and guides responsible use, they build competency through practice, not through presentations. The portal becomes both a productivity tool and a training instrument.

This does not replace formal training requirements. But it supplements them in a way that is continuous, contextual, and directly relevant to employees' actual work.

## Conclusion: Organization Decides

The two organizational questions, co-determination (Mitbestimmung) and competency, are not side issues in AI deployment. They are the main issues. The technology is available, affordable, and capable. The question is whether your organization is equipped to use it.

A works council that understands the architecture becomes a supporter. Employees who are trained use the tools productively. And an organization that addresses these dimensions proactively gains a competitive advantage that no model upgrade can replace.

---

**📘 Enterprise AI Infrastructure Blueprint 2026 - Article Series**

| ← Previous | Overview | Next → |
|:---|:---:|---:|
| [EU AI Act 2026: What Applies Now, What's Coming, What You Must Do](/en/magazine/eu-ai-act-2026-enterprises/) | [Overview](/en/magazine/ai-infrastructure-blueprint-2026/) | [Agent Orchestration: n8n, Camunda, and Alternatives Compared](/en/magazine/agent-orchestration-platforms/) |

*All articles in this series: [Enterprise AI Infrastructure Blueprint 2026](/en/magazine/ai-infrastructure-blueprint-2026/)*

---

Gosign supports organizations with the organizational dimensions of AI deployment, from works council negotiations to AI literacy programs. If you want to know how to prepare your organization, talk to us.

<a href="/en/contact/" target="_blank" rel="noopener noreferrer">Book a consultation</a>. 30 minutes to address your organizational questions.

--- Decision Layer Methodology ---
> How Gosign classifies agent decisions, calculates savings, and verifies sources - transparent and traceable.

## What is the Decision Layer?

The [Decision Layer](/en/decision-layer/) is the governance layer between AI agent and target system. Every decision an agent makes or prepares is documented as a decision act: which rule in which version was applied, what data informed the decision, who (human, rules engine, or AI) decided - and how the affected person can raise an objection. This decision act per micro-decision is the architectural answer to the right to an explanation of the individual decision under Art. 86 of the EU AI Act.

This page explains the methodology behind the numbers displayed on each agent detail page.

## Decider classification: R / A / H

Each decision step is assigned to exactly one of three decider types:

```
R  Rules Engine   Deterministic. Input in, output out.
                  No model, no discretion, no judgement.
                  Example: permissions matrix, deadline check.

A  AI Agent       Model-based with confidence threshold.
                  Output is probabilistic. When confidence
                  falls below threshold: fallback to R or H.
                  Example: intent recognition, anomaly detection.

H  Human          Explicitly assigned. The agent prepares,
                  the human decides. Documented in the
                  decision record.
                  Example: termination approval, hardship assessment.
```

The distinction is based on two criteria:

1. **Determinism**: Is the output identical for the same input every time? Yes = R. No (because model) = A. No (because discretion) = H.
2. **Accountability assignment**: Who is liable for the outcome? Rules engine (configured by HR/Finance) = R. Model (trained, with audit trail) = A. Named individual = H.

### Framework mapping

The R/A/H classification does not stand in isolation. It maps onto established governance taxonomies:

| Gosign R/A/H | Human-in-the-Loop taxonomy | EU AI Act Art. 14 | SAE level analogy |
|---|---|---|---|
| R (Rules Engine) | Human-out-of-the-Loop | No human oversight required | Level 4-5 (fully automated) |
| A (AI Agent) | Human-on-the-Loop | Human oversight for high-risk (Art. 14) | Level 2-3 (assisted/conditional) |
| H (Human) | Human-in-the-Loop | Human as decision-maker | Level 0-1 (manual/assisted) |

The SAE level analogy (from the automotive sector, SAE J3016) serves as an intuitive reference, not a direct transfer. In the automotive context the level refers to driving automation; here it refers to decision automation in HR and finance processes.

## How we count decision steps

A decision step is a point in the process where the agent makes a routing choice. Not every data operation is a step - only points where the outcome can differ depending on the input.

Criteria for a decision step:
- **Input varies**: Not every case follows the same path
- **Output has consequence**: The result influences the downstream process or a target system
- **Decider is assignable**: It is clear whether R, A, or H decides

Example: The Employee Self-Service Agent has 6 identified decision steps - from intent recognition (A) through permissions check (R) to escalation to the specialist function (R). A simple database lookup ("retrieve remaining leave") is not a decision step.

## Score calculation

Each agent is evaluated across five dimensions:

| Score | What it measures | Scale |
|---|---|---|
| **Readiness** | How ready is a typical organisation for this agent? | 0-100 |
| **Governance** | How high is the regulatory burden (EU AI Act, works council (§ 87 BetrVG), GDPR)? | 0-100 (higher = more demanding) |
| **Economic** | How strong is the economic leverage (ROI, FTE savings)? | 0-100 |
| **Lighthouse** | How strong is the signalling effect internally and externally? | 0-100 |
| **Complexity** | How complex is the technical implementation? | 0-100 (higher = more complex) |

Each score is given as a range [n, n+7] - the spread reflects variance across industries and organisation sizes. The lower value is the conservative scenario (mid-market without preparatory work), the upper is the optimistic scenario (enterprise with existing infrastructure).

The scores are based on a combination of:
- **Industry comparison**: How comparable are the processes across organisations? (higher standardisation = higher readiness score)
- **Regulatory analysis**: EU AI Act Annex III, GDPR Art. 22, works council co-determination rights under BetrVG § 87(1) No. 6 (governance score)
- **Benchmark data**: External studies on automation potential (economic score)
- **Project experience**: Gosign Decision Layer Assessments from documented client projects

## Savings ranges in the impact statement

Each agent has an impact statement (pyramidOpener.impact) that makes a quantitative claim about the benefit. These claims fall into three source categories:

### CAT-EXT - External primary source

The figure comes from a verified industry study or benchmark report. Publisher, title, year, and URL are documented in the CITATION-CATALOG. The figure was checked against the primary source (WebFetch verification of the URL plus content comparison).

Example: *"According to Ardent Partners State of ePayables 2024, cost per invoice drops from USD 12.88 to USD 2.78"* - Ardent Partners is the publisher, the figures appear in the report.

### CAT-LEGAL - Legislation or official statistics

The figure comes from legislation, official statistics, or a court ruling. The URL points to the official source (e.g. eur-lex.europa.eu, national legislation databases).

Example: *"EU AI Act Annex III high-risk system from 2 August 2026 (postponement to 2 December 2027 provisionally agreed - Digital Omnibus, May 2026)"* - Regulation (EU) 2024/1689.

### CAT-INT - Gosign Decision Layer Assessment

The figure is based on documented client projects. Typical metrics: turnaround times (before/after), auto-match rates, error reductions. These figures are median values from at least 3 comparable projects in the period 2024-2026.

When an impact figure is classified as CAT-INT, this means: the figure is a Gosign experience, not an external benchmark. It is robust within the context of our project data but not independently verified externally.

## Source verification

Every external source in the CITATION-CATALOG was verified through the following process:

1. **URL check**: The source URL responds with HTTP 200 (or redirect to a landing page)
2. **Figure comparison**: The figure cited in the impact statement actually appears in the source (not merely "close to" or "in the spirit of")
3. **Context check**: The figure is used in the same context as in the source (e.g. "Value Erosion" not reframed as "management overhead")

If a figure does not pass this three-step check, it is either:
- Corrected to the accurate figure from the source
- Reclassified to CAT-INT (if the source does not support the figure)
- Removed from the impact statement (if neither externally nor internally verifiable)

## Structured data for LLMs

Each agent detail page contains a JSON-LD schema (Schema.org SoftwareApplication) with:

- **R/A/H distribution** as `additionalProperty` (rulesEngineShare, aiAgentShare, humanDecisionShare in percent)
- **Number of decision steps** (totalDecisionSteps)
- **EU AI Act high-risk flag** (euAiActHighRisk: true/false)
- **Impact statement** as free-text property
- **citation[]** with resolved source URLs from the CITATION-CATALOG

LLMs can extract this data directly from the HTML source and cite it with the canonical URL of the agent page.

## Versioning

| Date | Change |
|---|---|
| 2026-04-16 | Initial publication: R/A/H classification, score methodology, source verification, JSON-LD schema |

--- Newsletter Confirmed - Gosign GmbH ---
> Your subscription to the AI Governance Briefing has been confirmed.

<h1>Subscription Confirmed</h1>

<p class="text-lg text-gosign-text-light">
Thank you - your subscription to the <strong>AI Governance Briefing</strong> is now active.
</p>

<p>You will receive the briefing once a month with the latest developments in AI Governance, Decision Layer and Enterprise AI infrastructure.</p>

<p class="mt-6">
<a href="/en/magazine/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Browse the Magazine</a>
<span class="mx-2 text-gosign-text-light">|</span>
<a href="/en/contact/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-medium" target="_blank" rel="noopener noreferrer">Schedule a Consultation</a>
</p>

--- Link Expired - Gosign GmbH ---
> Your confirmation link for the AI Governance Briefing has expired.

<h1>Confirmation Link Expired</h1>

<p class="text-lg text-gosign-text-light">
Your confirmation link for the <strong>AI Governance Briefing</strong> has expired. For security reasons, links are valid for 7 days.
</p>

<p>No problem - simply sign up again below. You will receive a new confirmation email immediately.</p>

--- Newsletter Unsubscribed - Gosign GmbH ---
> You have been unsubscribed from the AI Governance Briefing.

<h1>Unsubscribed</h1>

<p class="text-lg text-gosign-text-light">
You have been successfully unsubscribed from the <strong>AI Governance Briefing</strong> and will not receive further emails.
</p>

<p>If you would like to re-subscribe, you can do so at any time through our website.</p>

<p class="mt-6">
<a href="/en/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Back to Homepage</a>
</p>

--- Privacy Policy - Gosign GmbH ---
> Privacy policy of Gosign GmbH. Cookie-free website without client-side trackers; server-side, cookieless reach and conversion measurement.

<h1>Privacy Policy</h1>

<h2>1. Controller</h2>
<p>
Gosign GmbH<br/>
Hallerstra&szlig;e 8<br/>
20146 Hamburg, Germany
</p>
<p>Email: web26 [at] gosign.de</p>

<h3>Data Protection Officer</h3>
<p>
A data protection officer is currently not appointed. Fewer than 20 employees are regularly involved in the automated processing of personal data (&sect;&nbsp;38(1) BDSG). For questions regarding data protection, please contact the address stated above.
</p>

<h2>2. Overview</h2>
<p>
This website does not set any cookies. Neither first-party nor third-party. No client-side third-party trackers are loaded - no Google Analytics, no Matomo, no Facebook Pixel, no LinkedIn Insight Tag, and no Google Tag Manager. For reach and conversion measurement we operate our own cookieless, server-side system (see section&nbsp;4).
</p>
<p>
No cookie banner is required, as no cookies or comparable technologies are stored on or read from your device (&sect;&nbsp;25 TTDSG).
</p>

<h2>3. Hosting and Content Delivery</h2>
<p>
This website is served via Cloudflare Pages. Cloudflare acts as a data processor under Art.&nbsp;28 GDPR. A Data Processing Addendum (DPA) with Standard Contractual Clauses (SCCs) is in place.
</p>
<p>
When delivering web pages, Cloudflare technically processes the IP address of the requesting device. Depending on the service, this processing may also take place outside the EU and is secured via the EU-US Data Privacy Framework as well as DPA/SCCs.
</p>
<p>
Legal basis: Art.&nbsp;6(1)(f) GDPR (legitimate interest in secure and performant website delivery).
</p>

<h2>4. Reach and Conversion Measurement</h2>
<p>
To analyse website usage and the effectiveness of our advertising, we operate our own cookieless measurement system (internally "Lyftyfy"), run by Gosign GmbH. No cookies are set and no client-side third-party trackers are loaded (no Google Analytics, no Google Tag Manager, no Facebook Pixel, no LinkedIn Insight Tag). Measurement is performed server-side and without persistent recognition of your device:
</p>
<ul>
<li>No persistent identifier is stored on your device. To group the page views of a single day, a daily-rotating session hash is derived from IP address, browser signature, and date; the IP address itself is not stored.</li>
<li>We collect page views, scroll depth, dwell time, clicks, and form/conversion events - in aggregated, pseudonymous form.</li>
</ul>
<p>
Legal basis: Art.&nbsp;6(1)(f) GDPR (legitimate interest in analysing website usage and the effectiveness of our advertising).
</p>

<h3>Conversion measurement for advertising campaigns (Google Ads)</h3>
<p>
If you reach our website via a Google Ads ad, the requested URL contains a click parameter (gclid). If you subsequently complete an action (e.g. a form enquiry), we transmit a conversion event to Google server-side in order to measure the effectiveness of our campaigns. The click parameter, a cryptographically hashed (not human-readable) value of your email address or phone number, and the conversion value are transmitted. No cookie and no advertising tag is set in your browser. The recipient is Google Ireland Ltd. or Google LLC (USA); the transfer is secured via the data processing agreement (Art.&nbsp;28 GDPR), the EU-US Data Privacy Framework, and Standard Contractual Clauses (see the section on data processing agreements).
</p>
<p>
Legal basis: Art.&nbsp;6(1)(f) GDPR (legitimate interest in measuring and optimising our advertising).
</p>
<p>
You may object to this measurement at any time with effect for the future (Art.&nbsp;21 GDPR). An informal message to the address stated under "Controller" is sufficient; we will then cease processing.
</p>

<h2>5. Contact Form and Email Contact</h2>
<p>
When you contact us via the contact form or by email, your details (e.g. name, email address, message text) are processed for the purpose of handling your inquiry and for any follow-up questions. This data is processed on the basis of Art.&nbsp;6(1)(b) GDPR if your inquiry is related to the performance of a contract or is necessary for the implementation of pre-contractual measures. In all other cases, processing is based on our legitimate interest in the effective handling of inquiries addressed to us (Art.&nbsp;6(1)(f) GDPR).
</p>

<h3>Technical Processing via Cloudflare (Without Intermediate Storage)</h3>
<p>
To ensure secure and fast transmission of your form data, we use Cloudflare Workers technology from Cloudflare, Inc., 101 Townsend St, San Francisco, CA 94107, USA for routing. Cloudflare acts exclusively as a technical intermediary. Your form data is not stored in a database by Cloudflare but is processed in memory and forwarded in real time via an encrypted connection (TCP socket) to our email server. Once the data has been transmitted, it does not remain on Cloudflare's servers.
</p>

<h3>Email Hosting via Google Workspace (EU Hosting)</h3>
<p>
For receiving, storing, and sending our emails, we use Google Workspace from Google Cloud EMEA Limited, 70 Sir John Rogerson's Quay, Dublin 2, Ireland. We have configured Google Workspace so that our email data is physically stored on servers within the European Union (EU).
</p>

<h3>Data Processing Agreements and Third-Country Transfers</h3>
<p>
We have entered into data processing agreements (DPAs) pursuant to Art.&nbsp;28 GDPR with both Cloudflare and Google. As both providers are part of US corporations, a theoretical data transfer to the USA during maintenance, routing (Cloudflare), or support cases cannot be 100&nbsp;% excluded. For such cases, the providers rely on the adequacy decision of the EU Commission (EU-US Data Privacy Framework) as well as Standard Contractual Clauses to ensure an adequate level of data protection.
</p>

<h3>Retention Period</h3>
<p>
The data you enter in the contact form remains in our email inbox until you request deletion, revoke your consent to storage, or the purpose for data storage no longer applies (e.g. after your inquiry has been fully processed). Mandatory statutory provisions, in particular commercial and tax retention periods (up to 10 years under &sect;&nbsp;257 HGB and &sect;&nbsp;147 AO), remain unaffected.
</p>

<h2>6. Newsletter</h2>
<p>
When you subscribe to our newsletter, we process your email address for the purpose of regularly sending information about our services, articles and events.
</p>
<h3>Double Opt-In</h3>
<p>
Registration uses a double opt-in procedure: after entering your email address, you will receive a confirmation email with a unique link. Your address is only added to the mailing list after you click this link. The confirmation link is valid for 7 days.
</p>
<h3>Services Used</h3>
<p>
The newsletter is sent via a Cloudflare Worker (provider: Cloudflare, Inc., 101 Townsend St, San Francisco, CA 94107, USA). Your email address is stored in Cloudflare KV (key-value store). We have concluded a Data Processing Agreement (DPA) with Cloudflare pursuant to Art.&nbsp;28 GDPR. Emails are sent via SMTP (currently through a third-party mail server).
</p>
<h3>Legal Basis</h3>
<p>
Art.&nbsp;6(1)(a) GDPR (consent). You may revoke your consent at any time by unsubscribing via the link in every newsletter email or by contacting us at datenschutz@gosign.de.
</p>
<h3>Retention Period</h3>
<p>
Your email address is stored until you unsubscribe from the newsletter. After unsubscribing, the address is deleted without undue delay, unless statutory retention obligations apply.
</p>

<h2>7. 203-Readiness-Check</h2>
<p>
On our German-language pages we offer the 203-Readiness-Check, a voluntary self-assessment on the use of AI for professionals bound by professional secrecy under &sect;&nbsp;203 of the German Criminal Code (StGB). Your answers in the self-check are neither stored nor transmitted - the assessment runs entirely in your browser, and the result appears directly on the page without any email entry.
</p>
<h3>Results Report by Email (Optional)</h3>
<p>
Only if you voluntarily request the detailed results report by email do we process your email address, your professional group, and the level recommended for you - not your answers. The request is confirmed via the same double opt-in procedure as the newsletter (section&nbsp;6): you receive a confirmation email with a unique link, and the report is only delivered after you click this link. Delivery is handled by our email service provider Brevo, with which a data processing agreement pursuant to Art.&nbsp;28 GDPR has been concluded.
</p>
<h3>Legal Basis</h3>
<p>
Art.&nbsp;6(1)(a) GDPR (consent). You may withdraw your consent at any time with effect for the future, for example by email to datenschutz@gosign.de.
</p>
<h3>Retention Period</h3>
<p>
Confirmed report requests are deleted after 6 months. Unconfirmed double opt-in requests expire automatically after 7 days.
</p>

<h2>8. Appointment Booking</h2>
<p>
For appointment booking, we use Google Calendar Appointment Scheduling (provider: Google Ireland Limited, Gordon House, Barrow Street, Dublin 4, Ireland). When you click the booking link, you are redirected to calendar.google.com. No script is loaded and no cookie is set on our website by the booking link.
</p>
<p>
When using the booking service, your data (name, email address, selected appointment) is processed by Google. <a href="https://policies.google.com/privacy" target="_blank" rel="noopener noreferrer" class="text-gosign-accent-text hover:text-gosign-accent-hover">Google's Privacy Policy</a> applies.
</p>
<p>
Legal basis: Art.&nbsp;6(1)(b) GDPR (implementation of pre-contractual measures at your request). Booking a consultation appointment serves to initiate a business relationship.
</p>

<h2>9. Fonts</h2>
<p>
All fonts used on this website are locally embedded (self-hosted). No external font services (e.g. Google Fonts) are loaded. No connection to third parties is established when loading fonts.
</p>

<h2>10. Maps and Videos</h2>
<p>
This website does not embed external map services (e.g. Google Maps) or external video services (e.g. YouTube). Where maps or videos are displayed, this is done via static images or self-hosted content.
</p>

<h2>11. No Additional Third Parties</h2>
<p>
This website does not load resources from third parties not mentioned in this privacy policy. In particular, the following are not used:
</p>
<ul>
<li>Google Tag Manager</li>
<li>Facebook Pixel</li>
<li>LinkedIn Insight Tag</li>
<li>HubSpot, Salesforce, or other CRM trackers</li>
<li>Hotjar, Mouseflow, or other session recording tools</li>
<li>Matomo or other self-hosted analytics tools</li>
</ul>

<h2>12. SSL/TLS Encryption</h2>
<p>
This website uses SSL/TLS encryption for security purposes. An encrypted connection is indicated by "https://" in your browser's address bar.
</p>

<h2>13. Server Log Files</h2>
<p>
The hosting provider (Cloudflare) collects access data in server log files for technical reasons. These may include: page accessed, time, data volume, referrer URL, IP address, browser, and operating system. Log files are stored by Cloudflare for a maximum of 72 hours and are not merged with other data.
</p>
<p>
Legal basis: Art.&nbsp;6(1)(f) GDPR (legitimate interest in ensuring technical operations and detecting attacks).
</p>

<h2>14. Artificial Intelligence and Automated Decision-Making</h2>
<p>
No automated decision-making including profiling within the meaning of Art.&nbsp;22 GDPR takes place. No AI systems are used on this website for the automated processing of personal data of website visitors.
</p>

<h3>AI-Assisted Content Creation</h3>
<p>
Gosign uses AI-assisted tools (large language models, image generation) for the creation and editing of website content, graphics, and diagrams. These tools do not process personal data of website visitors. All outputs are editorially reviewed and approved.
</p>

<h3>AI in Client Projects</h3>
<p>
Gosign develops and operates AI infrastructure for enterprise clients (AI Agents, Document Intelligence, workflow automation). The processing of personal data in client projects is governed by separate data processing agreements (DPAs) pursuant to Art.&nbsp;28 GDPR and is not covered by this privacy policy.
</p>

<h2>15. International Data Protection Standards</h2>
<p>
Gosign serves clients worldwide and recognises data protection rights under the respectively applicable local laws. The GDPR remains the primary data protection law as Gosign GmbH is headquartered in Germany and data processing takes place in the EU. Below are supplementary notes for users in specific jurisdictions.
</p>

<h3>United Kingdom</h3>
<p>
For users in the United Kingdom, the UK GDPR in conjunction with the Data Protection Act 2018 applies. The rights largely correspond to those under the EU GDPR. Competent supervisory authority: Information Commissioner's Office (ICO), Wilmslow, Cheshire, UK.
</p>

<h3>United States</h3>
<p>
For users residing in California, the California Consumer Privacy Act (CCPA) and the California Privacy Rights Act (CPRA) apply additionally. This includes the right to know the categories of data collected, the right to deletion, and the right to opt out of the sale of personal data. Gosign does not sell personal data and does not share it with third parties for advertising purposes. For users in other US states with their own privacy laws (Colorado, Connecticut, Virginia, Utah, Texas, Oregon, and others), comparable rights are recognised.
</p>

<h3>Switzerland</h3>
<p>
For users in Switzerland, the revised Federal Act on Data Protection (revDSG/nDSG), in effect since 1&nbsp;September 2023, applies. It grants rights comparable to the GDPR. Competent supervisory authority: Federal Data Protection and Information Commissioner (FDPIC/ED&Ouml;B), Bern.
</p>

<h3>Canada</h3>
<p>
For users in Canada, the Personal Information Protection and Electronic Documents Act (PIPEDA) applies. Gosign recognises the PIPEDA principles, in particular consent, purpose limitation, access, and rectification. Competent supervisory authority: Office of the Privacy Commissioner of Canada (OPC), Gatineau, QC.
</p>

<h3>Brazil</h3>
<p>
For users in Brazil, the Lei Geral de Prote&ccedil;&atilde;o de Dados (LGPD, Lei n.&ordm;&nbsp;13.709/2018) applies additionally. The LGPD grants Brazilian users comprehensive rights, including access, rectification, anonymisation, erasure, data portability, and objection. These rights are fully recognised by us. Competent supervisory authority: Autoridade Nacional de Prote&ccedil;&atilde;o de Dados (ANPD), Bras&iacute;lia, DF.
</p>

<h3>India</h3>
<p>
For users in India, the Digital Personal Data Protection Act (DPDP Act, 2023) applies. Gosign recognises the rights of Indian users, in particular access, rectification, erasure, and the right to lodge a complaint. Competent supervisory authority: Data Protection Board of India (DPBI), New Delhi.
</p>

<h3>Japan</h3>
<p>
For users in Japan, the Act on the Protection of Personal Information (APPI) applies. The EU Commission has granted Japan an adequate level of data protection. Gosign recognises the APPI rights, in particular access, rectification, erasure, and cessation of use. Competent supervisory authority: Personal Information Protection Commission (PPC), Tokyo.
</p>

<h3>South Africa</h3>
<p>
For users in South Africa, the Protection of Personal Information Act (POPIA) applies. Gosign recognises the POPIA rights, in particular access, rectification, erasure, and objection to direct marketing. Competent supervisory authority: Information Regulator, Johannesburg.
</p>

<h3>All other jurisdictions</h3>
<p>
For users in countries with their own data protection laws not explicitly mentioned here, Gosign recognises the respectively applicable local data protection rights insofar as they relate to processing via this website. Your rights to access, rectification, and erasure are guaranteed in every case.
</p>

<h2>16. Your Rights</h2>
<p>
You have the following rights regarding your personal data:
</p>
<ul>
<li><strong>Access</strong> (Art.&nbsp;15 GDPR): You may request information about the data we process.</li>
<li><strong>Rectification</strong> (Art.&nbsp;16 GDPR): You may request correction of inaccurate data.</li>
<li><strong>Erasure</strong> (Art.&nbsp;17 GDPR): You may request deletion of your data, provided no statutory retention obligations apply.</li>
<li><strong>Restriction</strong> (Art.&nbsp;18 GDPR): You may request restriction of processing.</li>
<li><strong>Data Portability</strong> (Art.&nbsp;20 GDPR): You may request your data in a machine-readable format.</li>
<li><strong>Objection</strong> (Art.&nbsp;21 GDPR): You may object to processing based on Art.&nbsp;6(1)(f) GDPR at any time.</li>
<li><strong>Withdrawal of Consent</strong> (Art.&nbsp;7(3) GDPR): Where processing is based on your consent, you may withdraw it at any time with effect for the future. The lawfulness of processing carried out prior to the withdrawal remains unaffected.</li>
</ul>
<p>
To exercise your rights, an informal message to the address stated above is sufficient.
</p>

<h2>17. Right to Lodge a Complaint</h2>
<p>
You have the right to lodge a complaint with a data protection supervisory authority. The competent authority is the supervisory authority of the federal state in which you reside, or the authority responsible for the controller:
</p>
<p>
The Hamburg Commissioner for Data Protection and Freedom of Information<br/>
Ludwig-Erhard-Str. 22<br/>
20459 Hamburg, Germany
</p>

<h2>18. Currency</h2>
<p>
This privacy policy is currently valid. Last updated: February 2026.
</p>
<p>
We reserve the right to amend this privacy policy to adapt it to changed legal requirements or changes to the service.
</p>

--- Recruiting Agent - AI in Recruiting with Decision Layer ---
> Recruiting Agent with bias monitoring, EU AI Act compliance, and employee oversight transparency. Reduce time-to-hire without discrimination risk.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/en/why-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Every decision traceable</p>
</div>
</a>
<a href="/en/why-gosign/#infrastructure" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Your infrastructure</p>
<p class="text-xs text-gosign-text-light">No SaaS. No vendor lock-in.</p>
</div>
</a>
<a href="/en/why-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">No US cloud risk</p>
</div>
</a>
</div>
</div>
</div>



<!-- Problem -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Why Does Recruiting Take So Long?</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
90 days average time-to-hire. Hundreds of applications per position. Each manually reviewed, assessed, responded to. Recruiters spend most of their time on routine work instead of candidate conversations.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
The problem isn't lack of competence. It's volume: too many applications, too few recruiters, too many manual steps. And with every manual step, the risk of inconsistent evaluation - which is a compliance risk.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
At the same time, regulatory requirements are rising: the EU AI Act classifies AI in recruiting as high-risk. Bias monitoring is mandatory. Employee representation bodies have oversight rights for hiring decisions in most jurisdictions. In Germany specifically, the works council has co-determination rights for every hire under § 99 of the Works Constitution Act.
</p>
</div>
</section>

<!-- Process Diagram -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-6">The Recruiting Process with Decision Layer</h2>
<img
src="/images/diagrams/recruiting-decision-flow-en.svg"
alt="Recruiting process in 5 phases: Requirements (human reviews), Screening (automatic), Interview (human decides), Selection (human decides), Onboarding (rule set). Decision Layer documents every step, bias monitoring, EU AI Act compliant."
class="w-full"
width="1200"
height="400"
loading="lazy"
/>
</div>
</section>

<!-- Micro-Decision Table -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Who Decides What? Micro-Decisions in Recruiting</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
The <a href="/en/decision-layer/" class="text-gosign-accent-text hover:underline">Decision Layer</a> decomposes the recruiting process into individual decision steps. For each step, it is defined in advance: human, rule set, or AI.
</p>
</div>
<div class="mt-8 overflow-x-auto">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-dark/20">
<th class="py-3 pr-4 text-body font-bold text-gosign-dark">Decision Step</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Who Decides</th>
<th class="py-3 pl-4 text-body font-bold text-gosign-dark">Why</th>
</tr>
</thead>
<tbody class="text-body text-gosign-text-light">
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Create job requirements</td>
<td class="py-3 px-4"><span class="inline-block px-2 py-0.5 text-xs font-bold rounded bg-amber-100 text-amber-800">Human reviews</span></td>
<td class="py-3 pl-4">AI drafts from job description and team profile. Hiring manager reviews and adjusts.</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Draft job posting</td>
<td class="py-3 px-4"><span class="inline-block px-2 py-0.5 text-xs font-bold rounded bg-blue-100 text-blue-800">Automatic</span></td>
<td class="py-3 pl-4">Agent generates text from requirements. Bias check against discriminatory language.</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">CV parsing and data extraction</td>
<td class="py-3 px-4"><span class="inline-block px-2 py-0.5 text-xs font-bold rounded bg-blue-100 text-blue-800">Automatic</span></td>
<td class="py-3 pl-4">Extract structured data from CVs. Standard case, high confidence.</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Requirements matching (screening)</td>
<td class="py-3 px-4"><span class="inline-block px-2 py-0.5 text-xs font-bold rounded bg-emerald-100 text-emerald-800">Rule set</span></td>
<td class="py-3 pl-4">Match against defined must-have criteria. Rule-based, not AI judgement.</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Qualitative assessment (shortlist)</td>
<td class="py-3 px-4"><span class="inline-block px-2 py-0.5 text-xs font-bold rounded bg-amber-100 text-amber-800">Human reviews</span></td>
<td class="py-3 pl-4">Agent creates shortlist with reasoning. Recruiter reviews and decides on invitations.</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Schedule interviews</td>
<td class="py-3 px-4"><span class="inline-block px-2 py-0.5 text-xs font-bold rounded bg-blue-100 text-blue-800">Automatic</span></td>
<td class="py-3 pl-4">Calendar matching, invitations, reminders. Standard process.</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Conduct interview</td>
<td class="py-3 px-4"><span class="inline-block px-2 py-0.5 text-xs font-bold rounded bg-red-100 text-red-800">Human decides</span></td>
<td class="py-3 pl-4">Personal conversation. Not automatable.</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Hiring decision</td>
<td class="py-3 px-4"><span class="inline-block px-2 py-0.5 text-xs font-bold rounded bg-red-100 text-red-800">Human decides</span></td>
<td class="py-3 pl-4">Personnel decision. Employee oversight approval required (in Germany: § 99 BetrVG). Discretionary.</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Create contract offer</td>
<td class="py-3 px-4"><span class="inline-block px-2 py-0.5 text-xs font-bold rounded bg-emerald-100 text-emerald-800">Rule set</span></td>
<td class="py-3 pl-4">Classification per collective agreement / salary band. Deterministic logic.</td>
</tr>
<tr>
<td class="py-3 pr-4 font-semibold text-gosign-dark">Formulate rejection</td>
<td class="py-3 px-4"><span class="inline-block px-2 py-0.5 text-xs font-bold rounded bg-blue-100 text-blue-800">Automatic</span></td>
<td class="py-3 pl-4">Standard rejection for clear non-fulfilment of must-haves. Borderline cases escalated.</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- EU AI Act High Risk -->
<section class="py-section bg-gosign-dark text-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold">Why AI in Recruiting Is High-Risk - and What That Means</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4">
The EU AI Act explicitly classifies AI systems in recruiting as high-risk (Annex III, No. 4). Under current law the requirements apply from 2 August 2026, but following the provisional <a href="/en/magazine/eu-ai-act-2026-enterprises/" class="text-gosign-accent-on-dark underline">Digital Omnibus</a> agreement of 7 May 2026 they are set to be postponed to 2 December 2027 (formal adoption still pending, as of June 2026). This affects every organisation using AI for application screening, candidate assessment, or hiring decisions.
</p>
<div class="mt-8 space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-body-lg font-semibold text-white">Bias Monitoring Is Mandatory</p>
<p class="text-body text-gosign-text-on-dark/70 mt-1">Are certain groups systematically evaluated differently? The Decision Layer monitors all screening decisions statistically and flags anomalies.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-body-lg font-semibold text-white">Human Oversight Enforced</p>
<p class="text-body text-gosign-text-on-dark/70 mt-1">Hiring decisions cannot be fully automated. The Decision Layer enforces Human-in-the-Loop for all personnel decisions architecturally.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-body-lg font-semibold text-white">Transparency for Applicants</p>
<p class="text-body text-gosign-text-on-dark/70 mt-1">Applicants must be informed that AI is used. The audit trail documents the complete decision path for every applicant.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-body-lg font-semibold text-white">Audit Trail per Decision</p>
<p class="text-body text-gosign-text-on-dark/70 mt-1">Every screening decision: input data, applied rule set, confidence score, result, timestamp. Not created retroactively but generated automatically.</p>
</div>
</div>
<p class="text-body text-gosign-text-on-dark/60 mt-8">
→ <a href="/en/governance/eu-ai-act/" class="text-gosign-accent-on-dark hover:underline">EU AI Act Compliance in Detail</a>
</p>
</div>
</div>
</section>

<!-- Employee Oversight -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">How Employee Oversight Works for AI in Recruiting</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Employee representation bodies have oversight rights for hiring decisions in most jurisdictions. In Germany specifically, the works council has co-determination rights for every hire under § 99 of the Works Constitution Act. When AI is involved in pre-selection, employee representatives want to know: what criteria are used for filtering? Who defined the criteria? Who is responsible?
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
The Decision Layer gives employee representation bodies exactly this transparency:
</p>
<div class="mt-6 space-y-4">
<div class="flex items-start gap-3">
<span class="flex-shrink-0 w-6 h-6 rounded-full bg-gosign-accent text-white flex items-center justify-center text-sm font-bold">✓</span>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Criteria are transparent:</strong> Screening rules are versioned, documented rule sets - not a black box.</p>
</div>
<div class="flex items-start gap-3">
<span class="flex-shrink-0 w-6 h-6 rounded-full bg-gosign-accent text-white flex items-center justify-center text-sm font-bold">✓</span>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Hiring decisions stay with humans:</strong> The agent suggests, the human decides. Architecturally enforced, not optional.</p>
</div>
<div class="flex items-start gap-3">
<span class="flex-shrink-0 w-6 h-6 rounded-full bg-gosign-accent text-white flex items-center justify-center text-sm font-bold">✓</span>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Audit trail for every application:</strong> Which criterion led to invitation or rejection? Traceable in the auditor portal.</p>
</div>
<div class="flex items-start gap-3">
<span class="flex-shrink-0 w-6 h-6 rounded-full bg-gosign-accent text-white flex items-center justify-center text-sm font-bold">✓</span>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Bias report for employee representatives:</strong> Statistical analysis across all recruiting decisions. Are certain groups systematically treated differently?</p>
</div>
</div>
<p class="text-body text-gosign-text-light mt-6">
→ <a href="/en/governance/co-determination/" class="text-gosign-accent-text hover:underline">Employee Oversight & Co-Determination in Detail</a>
</p>
</div>
</div>
</section>

<!-- Potential -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">What Does a Recruiting Agent Deliver?</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Industry studies estimate the automation potential in recruiting at 70-75%. This does not mean 75% fewer recruiters. It means: 75% of process steps can be accelerated by agents - CV parsing, requirement matching, scheduling, standard communication.
</p>
<div class="mt-6 space-y-4">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark">Reduce Time-to-Hire</p>
<p class="text-body-lg text-gosign-text-light mt-2">From 90 to 30-45 days. Not through faster decisions, but by eliminating wait times: screening in hours instead of weeks, automatic scheduling, immediate standard communication.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark">Consistent Evaluation</p>
<p class="text-body-lg text-gosign-text-light mt-2">Every applicant is evaluated against the same rule set. Regardless of which recruiter handles the position or whether it's Monday morning or Friday afternoon.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark">More Time for Candidates</p>
<p class="text-body-lg text-gosign-text-light mt-2">Recruiters spend time on conversations instead of data entry. Candidate experience quality improves because humans focus on what only humans can do.</p>
</div>
</div>
</div>
</div>
</section>

<!-- This Agent in the Catalog -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark">When to Start? Prioritization and Governance Readiness</h2>
<p class="text-body text-gosign-text mt-4">Which quarter should this agent launch? What governance infrastructure must be in place first? Which agents are prerequisites? The HR Agent Catalog places this agent in the Q1-Q4 sequencing and shows readiness scores, governance complexity, and dependencies to other agents.</p>
<a href="/en/hr-agent-catalog/candidate-screening-agent/" class="inline-flex items-center gap-2 mt-4 text-body font-semibold text-gosign-accent hover:underline">View sequencing and scores &rarr;</a>
</div>
</section>

<!-- Deep Dive in the Agent Briefing -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">Deep Dive in the Agent Briefing (Gosign Magazine)</h2>
<div class="grid md:grid-cols-3 gap-6">
<a href="/en/magazine/eu-ai-act-hr/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<h3 class="text-h3 font-bold text-gosign-dark">EU AI Act and HR</h3>
</a>
<a href="/en/magazine/works-council-ai-co-determination/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<h3 class="text-h3 font-bold text-gosign-dark">Works Council and AI - Co-determination</h3>
</a>
<a href="/en/magazine/agent-governance-hr/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR</p>
<h3 class="text-h3 font-bold text-gosign-dark">Agent Governance for HR</h3>
</a>
</div>
</div>
</section>

<!-- FAQ -->

--- Manufacturing References | Websites & Digital ---
> Gosign references in manufacturing: B2B websites, product configurators, digital sales tools. View projects.

<!-- Gosign in Manufacturing -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Gosign in manufacturing</h2>
<p class="text-body text-gosign-text leading-relaxed">
Gosign develops digital solutions for manufacturing companies: B2B websites, product configurators, dealer portals, technical documentation platforms and digital sales tools. The sector has unique requirements: complex product data, multilingual catalogues, integration with PIM/ERP systems, long decision cycles.
</p>
</div>
</section>

<!-- What Gosign builds -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">What Gosign builds for manufacturing clients</h2>
<ul class="space-y-4">
<li class="flex items-start gap-3">
<span class="flex-shrink-0 mt-1.5 w-2 h-2 bg-gosign-accent rounded-full"></span>
<div>
<span class="font-bold text-gosign-dark">B2B websites</span>
<span class="text-body text-gosign-text">: responsive, performant, with product finders and contact routing to the right sales partner</span>
</div>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 mt-1.5 w-2 h-2 bg-gosign-accent rounded-full"></span>
<div>
<span class="font-bold text-gosign-dark">Product configurators</span>
<span class="text-body text-gosign-text">: interactive configurators that collect technical parameters and recommend matching products</span>
</div>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 mt-1.5 w-2 h-2 bg-gosign-accent rounded-full"></span>
<div>
<span class="font-bold text-gosign-dark">Dealer portals</span>
<span class="text-body text-gosign-text">: login-protected areas for distribution partners - price lists, technical documentation, ordering tools</span>
</div>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 mt-1.5 w-2 h-2 bg-gosign-accent rounded-full"></span>
<div>
<span class="font-bold text-gosign-dark">Multilingual catalogues</span>
<span class="text-body text-gosign-text">: TYPO3-based product catalogues with PIM integration, automated translation and regional variants</span>
</div>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 mt-1.5 w-2 h-2 bg-gosign-accent rounded-full"></span>
<div>
<span class="font-bold text-gosign-dark">Digital sales tools</span>
<span class="text-body text-gosign-text">: tablet-ready product presentations, offline catalogues, proposal generators</span>
</div>
</li>
</ul>
</div>
</section>

<!-- Technology Table -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Technologies in the manufacturing environment</h2>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Requirement</th>
<th class="py-3 text-small font-bold text-gosign-dark">Gosign solution</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">CMS</td>
<td class="py-3 text-body text-gosign-text">TYPO3 (enterprise) or WordPress (content-focused)</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">PIM integration</td>
<td class="py-3 text-body text-gosign-text">Akeneo, Pimcore, custom integration</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">ERP integration</td>
<td class="py-3 text-body text-gosign-text">SAP, Microsoft Dynamics, custom API</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Multilingual</td>
<td class="py-3 text-body text-gosign-text">TYPO3 native, up to 30+ languages</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Performance</td>
<td class="py-3 text-body text-gosign-text">Cloudflare CDN, edge caching, static generation</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Discuss your manufacturing project - 30&nbsp;minutes, free of charge.</h3>
<p class="text-body text-gosign-text mb-6">We analyse your project, estimate effort and timeline, no obligation.</p>
<a
href="/en/contact/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Book a call
</a>
<p class="text-small text-gosign-text-light mt-4">25 years of experience · 800+ extensions · AI-accelerated development</p>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
Gosign is a Hamburg-based digital agency with 25 years of experience in web development, TYPO3 and AI integration.
We have analysed over 800 TYPO3 extensions and today develop with AI assistance
up to 70&nbsp;% faster than with traditional methods. Our clients include mid-market
enterprises, universities and public sector organisations across the EU.
</p>
<p class="text-small text-gosign-text-light mt-2">As of: February 2026</p>
</div>
</section>

--- Case Study: Pilot Gruppe - AI Infrastructure in Azure ---
> How Gosign implemented a GDPR-compliant, model-agnostic AI infrastructure with access control and human-in-the-loop in Pilot Gruppe's Azure environment.

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Starting Point</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Pilot Gruppe needed an AI infrastructure built on their existing Microsoft Azure environment. Key requirements:
</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light">Data sovereignty must remain within the organization</li>
<li class="text-body-lg text-gosign-text-light">Authentication via existing Azure Entra ID (SSO)</li>
<li class="text-body-lg text-gosign-text-light">Department-specific access control - HR data only for HR</li>
<li class="text-body-lg text-gosign-text-light">Multiple AI models usable in parallel</li>
<li class="text-body-lg text-gosign-text-light">GDPR-compliant with independent assessment before go-live</li>
</ul>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Implementation</h2>
<h3 class="text-h3 font-bold text-gosign-dark mt-8">Multi-Model Architecture</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Instead of dependency on a single provider: model-agnostic architecture with selection per use case. Implemented models: GPT-5.5, Gemini 3.1 Pro, Claude Opus 4.7 and Mistral Small 3.2 for text/reasoning, Flux for image generation. Employees choose the model combination themselves - depending on the task. The model-agnostic architecture enabled the seamless upgrade from GPT-4o to GPT-5.5 without code changes at the chat interface.
</p>
<h3 class="text-h3 font-bold text-gosign-dark mt-8">Access Control via Azure Entra ID</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Existing security groups in Azure Entra ID were directly linked to the AI interface. No new user management, no additional authentication. Result: Marketing sees different AI models and agents than HR. Sensitive data like salaries remain within the HR security group - invisible to other departments.
</p>
<h3 class="text-h3 font-bold text-gosign-dark mt-8">Progressive Web App (PWA)</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
The interface was built as a PWA - runs on Windows and macOS without installation. Keyboard shortcuts for power users. Drag & drop for file upload.
</p>
<h3 class="text-h3 font-bold text-gosign-dark mt-8">GDPR Assessment Before Go-Live</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
The entire architecture was analyzed before go-live by Pilot Gruppe's data protection officer and by Dr. Frank Eickmeier (unverzagt.law). Positive GDPR assessment confirms compliance.
</p>
<h3 class="text-h3 font-bold text-gosign-dark mt-8">AI Agents on n8n Platform</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
AI agents run on the n8n platform set up in Pilot's infrastructure, accessible via multiple channels: interface, Microsoft Teams, and other collaboration channels. Human-in-the-loop is implemented: agents interact directly with relevant departments when clarification is needed.
</p>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Result</h2>
<ul class="mt-6 space-y-3">
<li class="text-body-lg text-gosign-text-light">All data stays in Pilot Gruppe's Azure environment - GDPR-compliant</li>
<li class="text-body-lg text-gosign-text-light">Existing IT infrastructure and authentication are reused</li>
<li class="text-body-lg text-gosign-text-light">Model-agnostic: new models integrable without architecture change</li>
<li class="text-body-lg text-gosign-text-light">Department-specific workspaces with Role-Based Access Control</li>
<li class="text-body-lg text-gosign-text-light">Employees independently create AI assistants and agents</li>
<li class="text-body-lg text-gosign-text-light">Cross-department agent sharing controllable by IT</li>
<li class="text-body-lg text-gosign-text-light">Independent GDPR assessment before go-live</li>
</ul>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Technology</h2>
<ul class="mt-6 space-y-2">
<li class="text-body-lg text-gosign-text-light">Microsoft Azure (client environment)</li>
<li class="text-body-lg text-gosign-text-light">Azure Entra ID (SSO, RBAC)</li>
<li class="text-body-lg text-gosign-text-light">n8n (agent orchestration)</li>
<li class="text-body-lg text-gosign-text-light">Multiple LLMs (GPT-5.5, Gemini 3.1 Pro, Claude Opus 4.7, Mistral Small 3.2, Flux)</li>
<li class="text-body-lg text-gosign-text-light">PWA (Progressive Web App)</li>
</ul>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Gosign's Contribution</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Conception, implementation, deployment, training, ongoing support. Beyond the AI infrastructure, Gosign built a complete agent platform: employees independently create AI assistants and agents, while IT controls cross-department agent sharing. Pilot Gruppe's IT department manages the entire platform with existing Azure skills - no new tooling required.
</p>
</div>
</section>

--- pilot Agency Group: GDPR-Compliant AI Infrastructure for 1,000 Employees ---
> How Germany's second-largest independent media agency built an AI infrastructure with full EU data residency.

## Starting Point

pilot is one of Germany's largest independent and owner-managed agency groups. With over 1,000 employees across seven locations, pilot serves clients including Dr. Oetker, OBI, Techniker Krankenkasse and GetYourGuide. As a media agency, pilot processes large volumes of campaign data, client data and media strategy documents daily.

The challenge: pilot wanted to deploy AI tools company-wide - for research, document analysis, campaign planning and an internal knowledge base. The requirement from Bosse Küllenberg, Managing Director Technology & Operations, was unequivocal: no data may leave the EU. No compromises on GDPR. And no vendor lock-in.

At that time, most AI providers offered no guaranteed EU data residency. ChatGPT Enterprise was not yet available, and the existing alternatives could not meet the requirements of a media agency handling sensitive client data.


## Requirements

Bosse Küllenberg defined four non-negotiable requirements for the AI infrastructure.

First: complete EU data residency. All data - prompts, responses, uploaded documents - must remain in the EU. No US servers, no transatlantic data transfers, no exceptions.

Second: tenant separation. pilot serves clients from widely different industries. Data from one client must under no circumstances enter the context of another client. This requires strict data isolation at infrastructure level.

Third: model independence. The infrastructure must not be tied to a single LLM. When a better model appears, a switch must be possible without architectural rebuild.

Fourth: traceability. For internal compliance and towards clients, it must be documented which data is processed and which model is used.


## Solution

Gosign implemented an [AI infrastructure](/en/services/infrastructure/) with the following properties.

The infrastructure runs entirely in an EU region (Germany West Central on Azure). No prompt, no document, no response leaves the EU. Data residency is not merely contractually assured but architecturally enforced: there is simply no path through which data could leave the EU.

Tenant separation operates at infrastructure level. Each team works in an isolated context. Uploaded documents, conversation histories and generated content are strictly separated.

The architecture is [model-agnostic](/en/services/infrastructure/). The orchestration layer routes requests to the optimal model - currently several models run in parallel. A model switch requires a configuration change, not an architectural rebuild.

Every interaction is logged: timestamp, model used, context assignment. Not the content of prompts is stored, but metadata - sufficient for compliance evidence without violating confidentiality.


## Outcome

pilot has an AI infrastructure that treats GDPR compliance not as a compromise but as a design principle. Over 1,000 employees use the infrastructure daily - for research, document analysis and campaign work.

EU data residency is fully guaranteed. Tenant separation prevents any form of data leakage between client teams. The model-agnostic architecture has already enabled two model switches without operational interruption.

Bosse Küllenberg had a clear vision from the start of what AI infrastructure must look like in a regulated environment. Gosign translated that vision into technology - clean, auditable and future-proof.


## Metrics

| Metric | Value |
|--------|-------|
| Employees with access | 1,000+ |
| Locations connected | 7 |
| EU data residency | 100% |
| Model switches without rebuild | 2 completed |
| Vendor lock-in | None |

--- References - Gosign Enterprise AI Infrastructure ---
> Enterprises that rely on Gosign infrastructure. Case studies from media, professional services and logistics.

<!-- Reference 1: pilot -->
<section class="py-16 lg:py-24 bg-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid lg:grid-cols-2 gap-12 items-start">
<div>
<span class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider">Media Agency · 1,000 Employees</span>
<h2 class="text-h2 font-bold text-gosign-dark mt-2 mb-4">pilot Agency Group</h2>
<p class="text-body text-gosign-text leading-relaxed mb-4">
Germany's second-largest independent media agency needed AI infrastructure that treats GDPR compliance not as a constraint but as an architectural principle - for over 1,000 employees across seven locations.
</p>
<p class="text-body text-gosign-text leading-relaxed mb-6">
Gosign delivered a self-hosted infrastructure with full EU data residency before other providers had even prioritised the issue.
</p>
<blockquote class="border-l-4 border-gosign-accent pl-4 italic text-gosign-text mb-6">
<div class="flex items-start gap-4 not-italic mb-3">
<img src="/images/logos/pilot-v2.svg" alt="pilot Agency Group Logo" class="w-24 h-auto opacity-80" width="91" height="45" loading="lazy" />
</div>
"For me it was clear from the start: no data outside the EU, no compromises on GDPR. Gosign delivered exactly that - technically sound, no ifs or buts."
<footer class="mt-4 flex items-center gap-4 text-small not-italic text-gosign-dark">
<img src="/images/testimonials/t1.webp" alt="" class="w-14 h-14 rounded-full object-cover ring-2 ring-gray-100" width="56" height="56" loading="lazy" />
<div>
<p class="font-semibold leading-tight"><img src="/images/testimonials/t1-n.svg" alt="" width="140" height="17" style="height:1.15em;width:auto;max-width:none;display:block" loading="lazy" /></p>
<p class="font-normal text-gosign-text-light mt-0.5">Managing Director Technology &amp; Operations, pilot</p>
</div>
</footer>
</blockquote>
<a href="/en/references/pilot-ai/" class="text-gosign-accent-text font-semibold hover:underline">
Read case study →
</a>
</div>
<div class="bg-gosign-light rounded-card p-8">
<dl class="space-y-4 text-body">
<div><dt class="font-semibold text-gosign-dark">Industry</dt><dd class="text-gosign-text">Media &amp; Communications</dd></div>
<div><dt class="font-semibold text-gosign-dark">Employees</dt><dd class="text-gosign-text">1,000+</dd></div>
<div><dt class="font-semibold text-gosign-dark">Locations</dt><dd class="text-gosign-text">Hamburg, Berlin, Munich, Stuttgart, Nuremberg, Mainz, Zurich</dd></div>
<div><dt class="font-semibold text-gosign-dark">Focus</dt><dd class="text-gosign-text">GDPR-compliant AI infrastructure, EU data residency</dd></div>
<div><dt class="font-semibold text-gosign-dark">Services</dt><dd class="text-gosign-text"><a href="/en/services/infrastructure/" class="text-gosign-accent-text hover:underline">AI Infrastructure</a>, <a href="/en/services/ai-agents/" class="text-gosign-accent-text hover:underline">Agent Platform</a></dd></div>
</dl>
</div>
</div>
</div>
</section>

<!-- Reference 2: Roser -->
<section class="py-16 lg:py-24 bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid lg:grid-cols-2 gap-12 items-start">
<div>
<span class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider">Legal · Tax Advisory · Audit · 100 Employees</span>
<h2 class="text-h2 font-bold text-gosign-dark mt-2 mb-4">Roser Lawyers Auditors Tax Advisors</h2>
<p class="text-body text-gosign-text leading-relaxed mb-4">
A multidisciplinary firm with 38 licensed professionals that audits others for compliance - and therefore sets the highest standards for its own AI infrastructure: professional secrecy under German criminal, bar association, tax advisory and auditor regulations.
</p>
<p class="text-body text-gosign-text leading-relaxed mb-6">
Gosign delivered a self-hosted infrastructure with cryptographic client separation, Decision Layer and complete audit trail - documented to withstand chamber review.
</p>
<blockquote class="border-l-4 border-gosign-accent pl-4 italic text-gosign-text mb-6">
<div class="flex items-start gap-4 not-italic mb-3">
<img src="/images/logos/roser.svg" alt="Roser Lawyers Auditors Tax Advisors Logo" class="h-12 w-auto opacity-80" width="947" height="138" loading="lazy" />
</div>
"As tax advisors and auditors, we audit others for compliance - so our own systems must be beyond reproach. Gosign's governance architecture meets exactly the standards we apply at our clients."
<footer class="mt-4 flex items-center gap-4 text-small not-italic text-gosign-dark">
<img src="/images/testimonials/t2.webp" alt="" class="w-14 h-14 rounded-full object-cover ring-2 ring-gray-100" width="56" height="56" loading="lazy" />
<div>
<p class="font-semibold leading-tight"><img src="/images/testimonials/t2-n.svg" alt="" width="105" height="17" style="height:1.15em;width:auto;max-width:none;display:block" loading="lazy" /></p>
<p class="font-normal text-gosign-text-light mt-0.5">Managing Director, Roser Rechtsanwaltsgesellschaft mbH</p>
</div>
</footer>
</blockquote>
</div>
<div class="bg-white rounded-card p-8">
<dl class="space-y-4 text-body">
<div><dt class="font-semibold text-gosign-dark">Industry</dt><dd class="text-gosign-text">Legal, Tax Advisory, Audit</dd></div>
<div><dt class="font-semibold text-gosign-dark">Employees</dt><dd class="text-gosign-text">100 (38 licensed professionals)</dd></div>
<div><dt class="font-semibold text-gosign-dark">Locations</dt><dd class="text-gosign-text">Hamburg, Leipzig</dd></div>
<div><dt class="font-semibold text-gosign-dark">Focus</dt><dd class="text-gosign-text">Professional secrecy-compliant AI, Decision Layer, audit trail</dd></div>
<div><dt class="font-semibold text-gosign-dark">Services</dt><dd class="text-gosign-text"><a href="/en/finance-ai-agents/" class="text-gosign-accent-text hover:underline">Finance Agent</a>, <a href="/en/services/infrastructure/" class="text-gosign-accent-text hover:underline">AI Infrastructure</a></dd></div>
</dl>
</div>
</div>
</div>
</section>

<!-- Reference 3: Anonymised (Trade logistics) -->
<section class="py-16 lg:py-24 bg-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid lg:grid-cols-2 gap-12 items-start">
<div>
<span class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider">Trade Logistics · 500+ Employees</span>
<h2 class="text-h2 font-bold text-gosign-dark mt-2 mb-4">Northern German Trade Logistics Company</h2>
<p class="text-body text-gosign-text leading-relaxed mb-4">
An established trade logistics company with over 500 employees and one of the most efficient IT and logistics infrastructures in its industry relies on Gosign as a strategic advisory partner for AI integration.
</p>
<p class="text-body text-gosign-text leading-relaxed mb-6">
Focus: Strategic consulting on integrating AI agents for customer support. The collaboration centres on how AI-powered support can be embedded into a complex, established IT landscape - without disrupting ongoing operations.
</p>
</div>
<div class="bg-gosign-light rounded-card p-8">
<dl class="space-y-4 text-body">
<div><dt class="font-semibold text-gosign-dark">Industry</dt><dd class="text-gosign-text">Trade Logistics</dd></div>
<div><dt class="font-semibold text-gosign-dark">Employees</dt><dd class="text-gosign-text">500+</dd></div>
<div><dt class="font-semibold text-gosign-dark">Location</dt><dd class="text-gosign-text">Northern Germany</dd></div>
<div><dt class="font-semibold text-gosign-dark">Focus</dt><dd class="text-gosign-text">Strategic consulting, AI-powered customer support</dd></div>
<div><dt class="font-semibold text-gosign-dark">Services</dt><dd class="text-gosign-text"><a href="/en/services/ai-agents/" class="text-gosign-accent-text hover:underline">AI Agents</a>, <a href="/en/services/infrastructure/" class="text-gosign-accent-text hover:underline">AI Infrastructure</a></dd></div>
</dl>
</div>
</div>
</div>
</section>

--- Co-Build - Custom AI Agents for Your Process ---
> Co-Build: Your process, your agent. From discovery to a production AI agent in 4-6 weeks with source code access, Decision Layer and exit strategy.

<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="AI Agents Navigation">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/en/services/ai-agents/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
AI Agents
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/en/services/ai-agents/document-agents/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Document</a>
<a href="/en/services/ai-agents/workflow-agents/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Workflow</a>
<a href="/en/services/ai-agents/knowledge-agents/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Knowledge</a>
<a href="/en/services/ai-agents/co-build/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Co-Build</a>
</div>
</div>
</nav>

<!-- At a Glance -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h2 font-bold text-gosign-dark">At a Glance</h2>
<div class="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-3 gap-4 mt-6">
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">4-6 Weeks</p>
<p class="text-body text-gosign-text-light mt-1">From discovery to a production agent in your infrastructure</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Full Source Code</p>
<p class="text-body text-gosign-text-light mt-1">Code, prompts, rule sets, documentation - full access, perpetual usage rights</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">No SaaS</p>
<p class="text-body text-gosign-text-light mt-1">No monthly fees. No vendor lock-in. Independent operation possible.</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Decision Layer</p>
<p class="text-body text-gosign-text-light mt-1">Every agent with audit trail, Human-in-the-Loop and rule set versioning</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Model-Agnostic</p>
<p class="text-body text-gosign-text-light mt-1">Claude, ChatGPT, Gemini, Llama - swappable without code changes</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Exit Strategy</p>
<p class="text-body text-gosign-text-light mt-1">Training, documentation, handover. Fully independent after 12-18 months.</p>
</div>
</div>
</div>
</div>
</section>

<!-- Three Phases -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Three Phases to a Production Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Every Co-Build follows a structured process. The result is a production agent in your infrastructure - with source code, documentation and exit strategy.
</p>
</div>
<div class="grid grid-cols-1 md:grid-cols-3 gap-6 mt-8 max-w-content">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Phase 1 - Week 1</p>
<p class="text-h3 font-bold text-gosign-dark">Discover</p>
<ul class="mt-4 space-y-2 text-body text-gosign-text-light">
<li>Process analysis with your domain team</li>
<li>Identify and formalize rule sets</li>
<li>Map decision points</li>
<li>Decision Layer design</li>
<li>Clarify system landscape and integrations</li>
</ul>
<p class="text-body text-gosign-text-light mt-4 font-semibold">Result: Process blueprint with decision matrix</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Phase 2 - Weeks 2-5</p>
<p class="text-h3 font-bold text-gosign-dark">Build</p>
<ul class="mt-4 space-y-2 text-body text-gosign-text-light">
<li>Agent development with your team</li>
<li>Implement Decision Layer</li>
<li>Rule sets as versioned configuration</li>
<li>System integration (SAP, DATEV, etc.)</li>
<li>Testing with real data</li>
</ul>
<p class="text-body text-gosign-text-light mt-4 font-semibold">Result: Production agent in your infrastructure</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Phase 3 - Weeks 5-6</p>
<p class="text-h3 font-bold text-gosign-dark">Transfer</p>
<ul class="mt-4 space-y-2 text-body text-gosign-text-light">
<li>Source code handover</li>
<li>Team training for independent operation</li>
<li>Documentation of code, prompts, rule sets</li>
<li>Set up monitoring and alerting</li>
<li>Document exit strategy</li>
</ul>
<p class="text-body text-gosign-text-light mt-4 font-semibold">Result: Your team operates the agent independently</p>
</div>
</div>
</div>
</section>

<!-- Which Areas -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">For Which Areas</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Co-Build is suitable for any process that is based on rule sets and is currently handled manually by people. Typical areas:
</p>
<div class="grid grid-cols-1 sm:grid-cols-2 gap-4 mt-6">
<div class="bg-gosign-light border border-gosign-border rounded-card p-4">
<p class="font-semibold text-gosign-dark text-body">Compliance & Legal</p>
<p class="text-body text-gosign-text-light mt-1">Regulatory reviews, contract review, clause extraction, deadline monitoring.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-4">
<p class="font-semibold text-gosign-dark text-body">Operations & Supply Chain</p>
<p class="text-body text-gosign-text-light mt-1">Order processing, supplier management, quality inspection, complaint processing.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-4">
<p class="font-semibold text-gosign-dark text-body">Shared Services</p>
<p class="text-body text-gosign-text-light mt-1">Ticket routing, request classification, internal knowledge provision, service desk automation.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-4">
<p class="font-semibold text-gosign-dark text-body">Industry-Specific</p>
<p class="text-body text-gosign-text-light mt-1">Export controls, customs clearance, insurance claims, credit assessment - any rule-based process.</p>
</div>
</div>
</div>
</div>
</section>

<!-- What You Get -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">What You Get</h2>
<ul class="mt-6 space-y-3">
<li class="text-body-lg text-gosign-text-light"><strong>Source Code:</strong> Complete agent code in your repository</li>
<li class="text-body-lg text-gosign-text-light"><strong>Prompts:</strong> All prompt chains and system prompts, documented and versioned</li>
<li class="text-body-lg text-gosign-text-light"><strong>Rule Sets:</strong> Domain rules as versioned configuration, not hardcoded</li>
<li class="text-body-lg text-gosign-text-light"><strong>Decision Layer:</strong> Audit trail, Human-in-the-Loop, works council or employee oversight constraints</li>
<li class="text-body-lg text-gosign-text-light"><strong>Documentation:</strong> Architecture, decision logic, test cases, deployment guide</li>
<li class="text-body-lg text-gosign-text-light"><strong>Exit Strategy:</strong> Training, handover protocol, support period</li>
</ul>
</div>
</div>
</section>

<!-- Comparison: Co-Build vs. SaaS vs. Inhouse -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Co-Build vs. SaaS vs. Inhouse</h2>
<div class="overflow-x-auto mt-6">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-dark">
<th class="py-3 pr-4 text-body font-bold text-gosign-dark"></th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Co-Build</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">SaaS Platform</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Inhouse</th>
</tr>
</thead>
<tbody class="text-body text-gosign-text-light">
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Time-to-Value</td>
<td class="py-3 px-4">4-6 weeks</td>
<td class="py-3 px-4">2-4 weeks</td>
<td class="py-3 px-4">6-12 months</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Source Code Access</td>
<td class="py-3 px-4">Full</td>
<td class="py-3 px-4">No access</td>
<td class="py-3 px-4">Full</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Vendor Lock-in</td>
<td class="py-3 px-4">None</td>
<td class="py-3 px-4">High</td>
<td class="py-3 px-4">None</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Governance / Audit</td>
<td class="py-3 px-4">Decision Layer included</td>
<td class="py-3 px-4">Platform-dependent</td>
<td class="py-3 px-4">Must be built</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Ongoing Costs</td>
<td class="py-3 px-4">Infrastructure + optional maintenance</td>
<td class="py-3 px-4">Monthly license</td>
<td class="py-3 px-4">Personnel costs</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Customizability</td>
<td class="py-3 px-4">Unlimited</td>
<td class="py-3 px-4">Within the platform</td>
<td class="py-3 px-4">Unlimited</td>
</tr>
</tbody>
</table>
</div>
</div>
</div>
</section>

<!-- Practice Scenario -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h2 font-bold text-gosign-dark">In Practice: Compliance Review in a Shared Service Center</h2>
<p class="text-body-lg text-gosign-text-light mt-4">A shared service center reviews 120 supplier contracts per month for compliance - manually, with checklists in Excel.</p>
<div class="grid grid-cols-1 sm:grid-cols-2 gap-6 mt-8">
<div class="bg-gosign-white rounded-card p-6">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-3">Before - manual</p>
<ul class="space-y-2 text-body text-gosign-text-light">
<li><strong>45 min</strong> per contract (reading, checklist, documentation)</li>
<li><strong>~90 hours/month</strong> for the team</li>
<li><strong>12% error rate</strong> in clause detection</li>
<li><strong>No versioning</strong> of review logic</li>
</ul>
</div>
<div class="bg-gosign-white rounded-card p-6 border-2 border-gosign-accent">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-3">After - Co-Build Agent</p>
<ul class="space-y-2 text-body text-gosign-text-light">
<li><strong>82% autonomous</strong> review (standard contracts)</li>
<li><strong>~19 hours/month</strong> (exceptions + spot checks only)</li>
<li><strong>&lt;2% error rate</strong> via rule-based review</li>
<li><strong>Decision Layer</strong> with full audit trail</li>
</ul>
</div>
</div>
<div class="bg-gosign-white rounded-card p-4 mt-6">
<p class="text-body text-gosign-text-light"><strong>Result:</strong> 71 hours saved per month. Agent productive in 5 weeks. Source code, rule sets and prompts owned by the client. Independent operation after 14 months without external support.</p>
</div>
</div>
</div>
</section>

<!-- Deep Dive in the Agent Briefing -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Deep Dive in the Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Our article series for decision-makers implementing AI agents in the enterprise.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/en/magazine/ai-costs-tco-comparison/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Costs</p>
<p class="text-body font-semibold text-gosign-dark">What AI Really Costs: TCO Comparison for Enterprises</p>
</a>
<a href="/en/magazine/model-agnostic-vendor-lock-in/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Architecture</p>
<p class="text-body font-semibold text-gosign-dark">Model-Agnostic Architecture - Why Vendor Lock-In With LLMs Is Dangerous</p>
</a>
<a href="/en/magazine/decision-layer-explained/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - What It Is and Why Every Enterprise AI Agent Needs One</p>
</a>
</div>
</div>
</section>

<!-- Other Agent Types -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Other Agent Types</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/en/services/ai-agents/document-agents/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">The Specialist</p>
<p class="text-body font-semibold text-gosign-dark">Document Agents</p>
<p class="text-body text-gosign-text-light mt-2">Read, understand and classify documents - with true language comprehension.</p>
</a>
<a href="/en/services/ai-agents/workflow-agents/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">The Coordinator</p>
<p class="text-body font-semibold text-gosign-dark">Workflow Agents</p>
<p class="text-body text-gosign-text-light mt-2">Orchestrate processes across systems - SAP, DATEV, SharePoint.</p>
</a>
<a href="/en/services/ai-agents/knowledge-agents/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">The Knowledge Keeper</p>
<p class="text-body font-semibold text-gosign-dark">Knowledge Agents</p>
<p class="text-body text-gosign-text-light mt-2">Answer questions from rule sets - with source references and rule versioning.</p>
</a>
</div>
</div>
</section>

--- Document Agents - Document Processing with Decision Layer ---
> Document Agents read, understand and process enterprise documents. Invoices, sick notes, contracts - auditable, with audit trail.

<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="AI Agents Navigation">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/en/services/ai-agents/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
AI Agents
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/en/services/ai-agents/document-agents/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Document</a>
<a href="/en/services/ai-agents/workflow-agents/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Workflow</a>
<a href="/en/services/ai-agents/knowledge-agents/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Knowledge</a>
<a href="/en/services/ai-agents/co-build/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Co-Build</a>
</div>
</div>
</nav>

<!-- At a Glance -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h2 font-bold text-gosign-dark">At a Glance</h2>
<div class="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-3 gap-4 mt-6">
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">99.1% Zero-Touch</p>
<p class="text-body text-gosign-text-light mt-1">Routine documents processed autonomously - no manual post-processing</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">20+ Document Types</p>
<p class="text-body text-gosign-text-light mt-1">Invoices, contracts, sick notes, tax assessments, receipts, and more</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">True Comprehension</p>
<p class="text-body text-gosign-text-light mt-1">Contextual language understanding instead of OCR template matching</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Decision Layer</p>
<p class="text-body text-gosign-text-light mt-1">Every extraction with confidence score, rule version, and audit trail</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Model-Agnostic</p>
<p class="text-body text-gosign-text-light mt-1">Claude, ChatGPT, Gemini, Llama - model is interchangeable</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">SAP, DATEV, Workday</p>
<p class="text-body text-gosign-text-light mt-1">Integration via APIs - agent logic decoupled from the target system</p>
</div>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Definition: Document Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
A Document Agent is a specialized AI agent for automated processing of enterprise documents. It uses Large Language Models (LLMs) for contextual language understanding - not template matching, not rigid OCR rules.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
The Document Agent reads a document, understands its content, and makes a professional assessment. This assessment is verified via the <a href="/en/decision-layer/" class="text-gosign-accent-text hover:underline">Decision Layer</a>, documented, and written to the audit trail.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">What Document Agents Process</h2>
<ul class="mt-6 space-y-3">
<li class="text-body-lg text-gosign-text-light">Incoming invoices and credit notes</li>
<li class="text-body-lg text-gosign-text-light">Sick notes and medical certificates</li>
<li class="text-body-lg text-gosign-text-light">Employment contracts and amendments</li>
<li class="text-body-lg text-gosign-text-light">Certificates and supporting documents</li>
<li class="text-body-lg text-gosign-text-light">Receipts and travel expense reports</li>
<li class="text-body-lg text-gosign-text-light">Tax assessments and official correspondence</li>
</ul>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">How a Decision is Made</h2>
<pre class="bg-gosign-dark text-white p-6 rounded-card overflow-x-auto text-small font-mono leading-relaxed mt-6"><code>Document    →  Agent reads     →  Decision Layer checks
(Invoice)      and understands    completeness, plausibility,
tax classification
│
┌────────────┴────────────┐
│                         │
High Confidence          Low Confidence
Clear rule              or exception case
│                         │
Posting proposal         Escalation to
+ Audit Trail           clerk</code></pre>
<p class="text-body-lg text-gosign-text-light mt-4">
With high confidence and clear rule application: autonomous processing with complete audit trail. With low confidence, exceptions, or missing information: escalation to a clerk - with all the context the agent has already extracted. In combination with a <a href="/en/services/ai-agents/workflow-agents/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Workflow Agent</a>, the entire process is orchestrated end-to-end.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Decision Layer for Documents</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Every document processing creates a complete decision record:
</p>
<ul class="mt-6 space-y-3">
<li class="text-body-lg text-gosign-text-light"><strong>Input:</strong> Document hash, document type, extracted fields</li>
<li class="text-body-lg text-gosign-text-light"><strong>Ruleset:</strong> Applied rule, version, timestamp</li>
<li class="text-body-lg text-gosign-text-light"><strong>Assessment:</strong> Confidence score, risk score</li>
<li class="text-body-lg text-gosign-text-light"><strong>Result:</strong> Posting proposal or escalation</li>
<li class="text-body-lg text-gosign-text-light"><strong>Routing:</strong> Autonomous decision or human-in-the-loop</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-4">
The Document Agent doesn't replace clerks - it handles routine cases autonomously and escalates exceptions to humans, with full documentation. Learn more about the <a href="/en/decision-layer/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Decision Layer architecture</a>.
</p>
</div>
</section>

<!-- Comparison: Document Agent vs. classical solution -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Document Agent vs. OCR vs. Manual</h2>
<div class="overflow-x-auto mt-6">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-dark">
<th class="py-3 pr-4 text-body font-bold text-gosign-dark"></th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Document Agent</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">OCR System</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Manual Processing</th>
</tr>
</thead>
<tbody class="text-body text-gosign-text-light">
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Comprehension</td>
<td class="py-3 px-4">Contextual - understands content and meaning</td>
<td class="py-3 px-4">Character recognition + template matching</td>
<td class="py-3 px-4">Full cognitive capability</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Free-text / Handwriting</td>
<td class="py-3 px-4">Yes - true language comprehension</td>
<td class="py-3 px-4">Limited - breaks on deviations</td>
<td class="py-3 px-4">Yes</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Speed</td>
<td class="py-3 px-4">Seconds per document</td>
<td class="py-3 px-4">Seconds, but often requires post-processing</td>
<td class="py-3 px-4">5-10 minutes per document</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Scaling</td>
<td class="py-3 px-4">Linear with volume</td>
<td class="py-3 px-4">Linear, but manual on errors</td>
<td class="py-3 px-4">Only with more staff</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Audit Trail</td>
<td class="py-3 px-4">Automatic per decision</td>
<td class="py-3 px-4">Limited</td>
<td class="py-3 px-4">Manual, often incomplete</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Practice scenario -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">In Practice: Incoming Invoices</h2>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6 mt-6">
<p class="font-semibold text-gosign-dark text-body">Scenario: 500 incoming invoices per month</p>
<div class="grid grid-cols-1 sm:grid-cols-2 gap-6 mt-4">
<div>
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-text-light mb-2">Before (manual)</p>
<ul class="space-y-1 text-body text-gosign-text-light">
<li>8 minutes per invoice (review, posting, verification)</li>
<li>~67 hours per month</li>
<li>Posting error rate: 4-6%</li>
<li>Audit trail: Excel spreadsheet, manually maintained</li>
</ul>
</div>
<div>
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">After (Document Agent)</p>
<ul class="space-y-1 text-body text-gosign-text-light">
<li>99.1% processed autonomously (495 of 500 invoices)</li>
<li>&lt;1% escalated to clerks (~5 invoices/month)</li>
<li>98% of all follow-ups with the document sender resolved autonomously</li>
<li>&lt;0.5h manual effort per month</li>
<li>Error rate: below 0.3% (rule-based posting)</li>
</ul>
</div>
</div>
<p class="text-body text-gosign-text-light mt-4">
<strong>Result:</strong> From 67 hours down to under 30 minutes per month. The agent posts, verifies, and books autonomously. When information is missing (e.g. PO number, cost center), the agent follows up with the document sender directly - 98% of these queries are resolved without human intervention. Only genuine exceptions reach a clerk.
</p>
<div class="mt-4 bg-gosign-light border-l-4 border-gosign-accent rounded-card p-4">
<p class="text-small font-semibold text-gosign-dark">Human-in-the-Loop</p>
<p class="text-small text-gosign-text-light mt-1"><strong>Agent decides:</strong> Posting, booking proposal, payment terms, follow-ups with document sender.<br/><strong>Human decides:</strong> First-time vendor approval, invoices above approval threshold, deviations from order value &gt;5%.</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Use Cases</h2>
<div class="mt-6 space-y-6">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Finance & Accounting</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Invoice processing, posting, document verification. Integration with <a href="https://www.datev.de/" target="_blank" rel="noopener noreferrer">DATEV</a> and SAP FI/CO. Pre-configured solution: <a href="/en/finance-ai-agents/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Finance AI Agents</a>.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">HR & People Operations</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Sick notes, contract documents, certificates. Integration with <a href="https://www.sap.com/products/hcm.html" target="_blank" rel="noopener noreferrer">SAP SuccessFactors</a> and <a href="https://www.workday.com/" target="_blank" rel="noopener noreferrer">Workday</a>. Pre-configured solution: <a href="/en/hr-ai-agents/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">HR AI Agents</a>.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Compliance & Audit</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Automatic verification of incoming documents against internal policies and external regulations. The <a href="/en/decision-layer/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Decision Layer</a> documents every verification decision.</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Integration</h2>
<p class="text-body-lg text-gosign-text-light mt-4">Document Agents connect to existing systems via standardized interfaces:</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light">SAP FI/CO, SAP S/4HANA</li>
<li class="text-body-lg text-gosign-text-light">DATEV</li>
<li class="text-body-lg text-gosign-text-light">SAP SuccessFactors, Workday</li>
<li class="text-body-lg text-gosign-text-light">SharePoint, Microsoft Teams</li>
<li class="text-body-lg text-gosign-text-light">Email inboxes (IMAP/Exchange)</li>
<li class="text-body-lg text-gosign-text-light">Others via REST/SOAP</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-4">Agent logic is decoupled from the target system. Switching your ERP changes the export layer - not the agent. Need an agent for a process not covered by the three standard types? <a href="/en/services/ai-agents/co-build/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Co-Build</a> delivers custom agents in 4-6 weeks.</p>
</div>
</section>

<!-- Other Agent Types -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Other Agent Types</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/en/services/ai-agents/workflow-agents/" class="group block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">The Coordinator</p>
<p class="text-body font-semibold text-gosign-dark">Workflow Agents</p>
<p class="text-body text-gosign-text-light mt-2">Orchestrate processes across systems - SAP, DATEV, SharePoint.</p>
<span class="inline-flex items-center gap-1 mt-4 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Details <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
<a href="/en/services/ai-agents/knowledge-agents/" class="group block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">The Knowledge Carrier</p>
<p class="text-body font-semibold text-gosign-dark">Knowledge Agents</p>
<p class="text-body text-gosign-text-light mt-2">Answer questions from rule sets - with source citation and rule version.</p>
<span class="inline-flex items-center gap-1 mt-4 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Details <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
<a href="/en/services/ai-agents/co-build/" class="group block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Custom Agents</p>
<p class="text-body font-semibold text-gosign-dark">Co-Build</p>
<p class="text-body text-gosign-text-light mt-2">Your process, your agent. 4-6 weeks to a productive agent.</p>
<span class="inline-flex items-center gap-1 mt-4 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Details <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Deep Dive in the Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Our article series for decision-makers implementing AI agents in the enterprise.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/en/magazine/rag-document-intelligence-enterprise/" class="group block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">RAG &amp; Document Intelligence: How AI Understands Your Documents</p>
<span class="inline-flex items-center gap-1 mt-3 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Read <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
<a href="/en/magazine/pii-anonymization-llm-enterprise/" class="group block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">PII Anonymization for Enterprise AI</p>
<span class="inline-flex items-center gap-1 mt-3 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Read <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
<a href="/en/magazine/decision-layer-explained/" class="group block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - What It Is and Why Every Enterprise AI Agent Needs One</p>
<span class="inline-flex items-center gap-1 mt-3 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Read <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
</div>
</div>
</section>

--- Knowledge Agents - Answers from Enterprise Knowledge ---
> Knowledge Agents deliver context-based answers from company agreements and policies. With source reference, rule version, and audit trail.

<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="AI Agents Navigation">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/en/services/ai-agents/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
AI Agents
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/en/services/ai-agents/document-agents/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Document</a>
<a href="/en/services/ai-agents/workflow-agents/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Workflow</a>
<a href="/en/services/ai-agents/knowledge-agents/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Knowledge</a>
<a href="/en/services/ai-agents/co-build/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Co-Build</a>
</div>
</div>
</nav>

<!-- At a Glance -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h2 font-bold text-gosign-dark">At a Glance</h2>
<div class="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-3 gap-4 mt-6">
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Source-Verified</p>
<p class="text-body text-gosign-text-light mt-1">Every answer with source reference, rule version, and validity date</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">5 Anti-Hallucination</p>
<p class="text-body text-gosign-text-light mt-1">Retrieval-first, source verification, confidence, no speculation, audit trail</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">4 Channels</p>
<p class="text-body text-gosign-text-light mt-1">Teams Bot, SharePoint, web interface, API - where your employees work</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">RAG Pipeline</p>
<p class="text-body text-gosign-text-light mt-1">Versioned indexing of all knowledge sources with automatic updates</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Decision Layer</p>
<p class="text-body text-gosign-text-light mt-1">Confidence scoring and routing - on uncertainty, referral instead of answer</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Instant Answers</p>
<p class="text-body text-gosign-text-light mt-1">Seconds instead of hours - consistent across all locations and time zones</p>
</div>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Definition: Knowledge Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
A Knowledge Agent is a specialized AI agent that delivers context-based answers from enterprise knowledge. It uses a RAG pipeline (Retrieval-Augmented Generation) to find relevant information from deposited documents and answer in the correct context.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Core principle: every answer includes the source reference and rule version. A Knowledge Agent never answers a question without a source reference.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Example</h2>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6 mt-6">
<p class="text-body text-gosign-text-light"><strong>Question:</strong> "How many days of special leave do I get for relocation?"</p>
<p class="text-body text-gosign-text-light mt-4"><strong>Answer:</strong> "According to Company Agreement BV-2024-007, § 3 Para. 2 (Version 2024.2, effective since 01.04.2024), you are entitled to 2 working days of special leave for relocation. For employees covered by collective bargaining agreements, § 29 TV-L additionally provides 1 further day."</p>
<ul class="mt-4 space-y-1">
<li class="text-body text-gosign-text-light">Source is provided</li>
<li class="text-body text-gosign-text-light">Rule version is documented</li>
<li class="text-body text-gosign-text-light">When interpretation is ambiguous: referral to HR</li>
</ul>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Knowledge Sources</h2>
<ul class="mt-6 space-y-3">
<li class="text-body-lg text-gosign-text-light"><strong>Company agreements</strong> - versioned, with validity period</li>
<li class="text-body-lg text-gosign-text-light"><strong>Collective bargaining agreements</strong> - per region, per entity</li>
<li class="text-body-lg text-gosign-text-light"><strong>Internal policies</strong> - travel policy, expense policy, IT policy</li>
<li class="text-body-lg text-gosign-text-light"><strong>Compliance handbooks</strong> - regulatory requirements</li>
<li class="text-body-lg text-gosign-text-light"><strong>FAQ catalogs</strong> - frequently asked questions with verified answers</li>
<li class="text-body-lg text-gosign-text-light"><strong>Process documentation</strong> - Standard Operating Procedures</li>
</ul>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Architectural Safety Against Hallucination</h2>
<ol class="mt-6 space-y-3 list-decimal list-inside">
<li class="text-body-lg text-gosign-text-light"><strong>Retrieval-First:</strong> The agent searches for relevant documents before answering</li>
<li class="text-body-lg text-gosign-text-light"><strong>Source verification:</strong> Every statement must be traceable to a specific source</li>
<li class="text-body-lg text-gosign-text-light"><strong>Confidence score:</strong> With low confidence, no answer is given - instead, a referral</li>
<li class="text-body-lg text-gosign-text-light"><strong>No speculation:</strong> When information is missing or contradictory, the agent refers to the responsible department</li>
<li class="text-body-lg text-gosign-text-light"><strong>Audit trail:</strong> Every answer is documented with source, version, and confidence</li>
</ol>
</div>
</section>

<!-- Comparison: Knowledge Agent vs. classical solution -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Knowledge Agent vs. Enterprise Search vs. Standard Chatbot</h2>
<div class="overflow-x-auto mt-6">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-dark">
<th class="py-3 pr-4 text-body font-bold text-gosign-dark"></th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Knowledge Agent</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Enterprise Search</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Standard Chatbot</th>
</tr>
</thead>
<tbody class="text-body text-gosign-text-light">
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Result</td>
<td class="py-3 px-4">Specific answer with source</td>
<td class="py-3 px-4">List of documents</td>
<td class="py-3 px-4">Generated answer without source guarantee</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Source citation</td>
<td class="py-3 px-4">Always - with version and validity</td>
<td class="py-3 px-4">Link to document</td>
<td class="py-3 px-4">None or unreliable</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Hallucination</td>
<td class="py-3 px-4">Architecturally prevented (5 measures)</td>
<td class="py-3 px-4">Not applicable</td>
<td class="py-3 px-4">Frequent - no control</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">On uncertainty</td>
<td class="py-3 px-4">Refers to responsible department</td>
<td class="py-3 px-4">Shows more results</td>
<td class="py-3 px-4">Gives an answer anyway</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Audit Trail</td>
<td class="py-3 px-4">Complete per answer</td>
<td class="py-3 px-4">Search log</td>
<td class="py-3 px-4">Chat history</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Practice scenario -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">In Practice: HR Inquiries</h2>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6 mt-6">
<p class="font-semibold text-gosign-dark text-body">Scenario: 200 HR inquiries per month (leave entitlements, special arrangements, company agreements)</p>
<div class="grid grid-cols-1 sm:grid-cols-2 gap-6 mt-4">
<div>
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-text-light mb-2">Before (manual)</p>
<ul class="space-y-1 text-body text-gosign-text-light">
<li>15 minutes per inquiry (HR researches, checks agreements, responds)</li>
<li>~50 hours per month</li>
<li>Inconsistent answers depending on the handler</li>
<li>Wait time for employees: hours to days</li>
</ul>
</div>
<div>
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">After (Knowledge Agent)</p>
<ul class="space-y-1 text-body text-gosign-text-light">
<li>78% answered instantly (156 inquiries) - seconds instead of hours</li>
<li>22% escalated to HR (44 complex cases) - with context</li>
<li>~11 hours per month (escalations only)</li>
<li>100% consistent rule interpretation</li>
</ul>
</div>
</div>
<p class="text-body text-gosign-text-light mt-4">
<strong>Result:</strong> 39 hours saved per month. Employees receive a verified answer instantly. HR focuses on the complex cases that require genuine discretion.
</p>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Use Cases</h2>
<div class="mt-6 space-y-6">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">HR & People Operations</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Questions about company agreements, leave entitlements, special arrangements, parental leave, training budgets. Replacing the "just ask someone" principle.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Compliance & Regulation</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Questions about internal policies, regulatory requirements, export control, data privacy. Consistent answers instead of individual interpretation.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Onboarding</h3>
<p class="text-body-lg text-gosign-text-light mt-2">New employees get immediate access to relevant enterprise knowledge - without waiting for available colleagues.</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Integration</h2>
<ul class="mt-4 space-y-3">
<li class="text-body-lg text-gosign-text-light"><strong>Microsoft Teams Bot</strong> - directly in daily work</li>
<li class="text-body-lg text-gosign-text-light"><strong>SharePoint integration</strong> - embedded in the intranet</li>
<li class="text-body-lg text-gosign-text-light"><strong>Web interface</strong> - standalone for complex queries</li>
<li class="text-body-lg text-gosign-text-light"><strong>API</strong> - for integration into custom applications</li>
</ul>
</div>
</section>

<!-- Other Agent Types -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Other Agent Types</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/en/services/ai-agents/document-agents/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">The Specialist</p>
<p class="text-body font-semibold text-gosign-dark">Document Agents</p>
<p class="text-body text-gosign-text-light mt-2">Read, understand, and classify documents - with true language comprehension.</p>
</a>
<a href="/en/services/ai-agents/workflow-agents/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">The Coordinator</p>
<p class="text-body font-semibold text-gosign-dark">Workflow Agents</p>
<p class="text-body text-gosign-text-light mt-2">Orchestrate processes across systems - SAP, DATEV, SharePoint.</p>
</a>
<a href="/en/services/ai-agents/co-build/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Custom Agents</p>
<p class="text-body font-semibold text-gosign-dark">Co-Build</p>
<p class="text-body text-gosign-text-light mt-2">Your process, your agent. 4-6 weeks to a productive agent.</p>
</a>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Deep Dive in the Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Our article series for decision-makers implementing AI agents in the enterprise.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/en/magazine/rag-document-intelligence-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">RAG &amp; Document Intelligence: How AI Understands Your Documents</p>
</a>
<a href="/en/magazine/human-in-the-loop-architecture/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Human-in-the-Loop - Architectural Principle, Not Checkbox</p>
</a>
<a href="/en/magazine/decision-layer-explained/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - What It Is and Why Every Enterprise AI Agent Needs One</p>
</a>
</div>
</div>
</section>

--- Workflow Agents - Cross-System Process Orchestration ---
> Workflow Agents orchestrate enterprise processes across systems. SAP, DATEV, Workday - one agent coordinates. Audit trail and Decision Layer included.

<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="AI Agents Navigation">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/en/services/ai-agents/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
AI Agents
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/en/services/ai-agents/document-agents/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Document</a>
<a href="/en/services/ai-agents/workflow-agents/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Workflow</a>
<a href="/en/services/ai-agents/knowledge-agents/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Knowledge</a>
<a href="/en/services/ai-agents/co-build/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Co-Build</a>
</div>
</div>
</nav>

<!-- At a Glance -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h2 font-bold text-gosign-dark">At a Glance</h2>
<div class="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-3 gap-4 mt-6">
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">5+ Systems</p>
<p class="text-body text-gosign-text-light mt-1">SAP, DATEV, Workday, SharePoint, AD - one agent coordinates everything</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Pausable</p>
<p class="text-body text-gosign-text-light mt-1">Workflow pauses when a human needs to decide - and resumes after</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Idempotent</p>
<p class="text-body text-gosign-text-light mt-1">Every step repeatable without side effects - no double bookings</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Decision Layer</p>
<p class="text-body text-gosign-text-light mt-1">At every decision point: autonomous or Human-in-the-Loop</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">API-Based</p>
<p class="text-body text-gosign-text-light mt-1">No GUI automation - stable integration via interfaces</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Audit Trail</p>
<p class="text-body text-gosign-text-light mt-1">Every step with timestamp, rule, version, and routing decision</p>
</div>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Definition: Workflow Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
A Workflow Agent is a specialized AI agent for cross-system orchestration of enterprise processes. It coordinates tasks between multiple systems - including escalation, approval logic, and exception handling.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Unlike RPA (Robotic Process Automation), the Workflow Agent does not operate on application interfaces but via APIs, understanding the business context of the decisions it coordinates.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">How a Workflow Agent Works</h2>
<h3 class="text-h3 font-bold text-gosign-dark mt-6">Example: Sick Leave</h3>
<pre class="bg-gosign-dark text-white p-6 rounded-card overflow-x-auto text-small font-mono leading-relaxed mt-4"><code>Incoming         →  Document Agent     →  Decision Layer
(Email with         reads sick note       checks labor law
attachment)        and extracts          and policy constraints
data                       │
┌──────────┴──────────┐
│                     │
Rule-compliant         Clarification needed
│                     │
Calculate              HR clerk
continued pay          is notified
│                     │
Propose SAP            Waits for
posting                decision
│                     │
Audit Trail            Audit Trail
documented             documented</code></pre>
<p class="text-body-lg text-gosign-text-light mt-4">
Every step is logged. Every decision is traceable. When clarification is needed or information is missing, the workflow pauses - it doesn't abort.
</p>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Orchestration Principles</h2>
<ul class="mt-6 space-y-4">
<li class="text-body-lg text-gosign-text-light"><strong>Cross-system:</strong> A workflow can coordinate SAP, DATEV, SharePoint, email, and other systems in a single flow</li>
<li class="text-body-lg text-gosign-text-light"><strong>Decision-based:</strong> The Workflow Agent makes business decisions, not just if-then rules</li>
<li class="text-body-lg text-gosign-text-light"><strong>Pausable:</strong> When information is missing or human decisions are needed, it pauses, documents, and resumes after resolution</li>
<li class="text-body-lg text-gosign-text-light"><strong>Auditable:</strong> Every step creates an audit trail entry - including wait times and escalations</li>
<li class="text-body-lg text-gosign-text-light"><strong>Idempotent:</strong> Every step can be re-executed without side effects</li>
</ul>
</div>
</section>

<!-- Comparison: Workflow Agent vs. classical solution -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Workflow Agent vs. RPA vs. Manual</h2>
<div class="overflow-x-auto mt-6">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-dark">
<th class="py-3 pr-4 text-body font-bold text-gosign-dark"></th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Workflow Agent</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">RPA Bot</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Manual Coordination</th>
</tr>
</thead>
<tbody class="text-body text-gosign-text-light">
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Control</td>
<td class="py-3 px-4">APIs + business decisions</td>
<td class="py-3 px-4">GUI clicks on interfaces</td>
<td class="py-3 px-4">Email, phone, tickets</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Stability</td>
<td class="py-3 px-4">API contracts - independent of UI changes</td>
<td class="py-3 px-4">Breaks on UI changes</td>
<td class="py-3 px-4">Dependent on individuals</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Decision capability</td>
<td class="py-3 px-4">Business decisions based on rulesets</td>
<td class="py-3 px-4">If-then rules only</td>
<td class="py-3 px-4">Full decision capability</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Interruption</td>
<td class="py-3 px-4">Pauses, waits, resumes</td>
<td class="py-3 px-4">Aborts - restart required</td>
<td class="py-3 px-4">Waits - often without documentation</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Audit Trail</td>
<td class="py-3 px-4">Automatic per step</td>
<td class="py-3 px-4">Screenshot-based</td>
<td class="py-3 px-4">Manual, incomplete</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Practice scenario -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">In Practice: Onboarding Process</h2>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6 mt-6">
<p class="font-semibold text-gosign-dark text-body">Scenario: 20 new hires per month</p>
<div class="grid grid-cols-1 sm:grid-cols-2 gap-6 mt-4">
<div>
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-text-light mb-2">Before (manual)</p>
<ul class="space-y-1 text-body text-gosign-text-light">
<li>3 working days per onboarding</li>
<li>5 systems updated manually (SAP, AD, email, time tracking, access control)</li>
<li>Error rate: 12% (missing permissions, wrong cost center)</li>
<li>HR effort: 60 hours per month</li>
</ul>
</div>
<div>
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">After (Workflow Agent)</p>
<ul class="space-y-1 text-body text-gosign-text-light">
<li>4 hours per onboarding (incl. manual approvals)</li>
<li>5 systems provisioned automatically via APIs</li>
<li>Error rate: below 2% (ruleset-based assignment)</li>
<li>HR effort: 15 hours per month</li>
</ul>
</div>
</div>
<p class="text-body text-gosign-text-light mt-4">
<strong>Result:</strong> 75% less effort, 85% fewer errors. The Workflow Agent coordinates all systems and only pauses where human approval is needed - with a complete audit trail.
</p>
</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Use Cases</h2>
<div class="mt-6 space-y-6">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">HR Processes</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Onboarding (contract, IT provisioning, orientation), sick leave, contract changes, exit processes. Orchestrated via <a href="https://www.sap.com/products/hcm.html" target="_blank" rel="noopener noreferrer">SAP SuccessFactors</a>, <a href="https://www.workday.com/" target="_blank" rel="noopener noreferrer">Workday</a>, Active Directory, and email.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Finance Processes</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Invoice receipt, verification, posting, approval, booking. Orchestrated via <a href="https://www.datev.de/" target="_blank" rel="noopener noreferrer">DATEV</a>, SAP FI/CO, and banking interfaces.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Compliance Processes</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Automatic verification against policies, escalation on deviations, documentation in the audit trail.</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Decision Layer in Workflows</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Every workflow step that involves a decision is routed through the Decision Layer:
</p>
<ul class="mt-6 space-y-3">
<li class="text-body-lg text-gosign-text-light"><strong>Business validation:</strong> Ruleset check per decision step</li>
<li class="text-body-lg text-gosign-text-light"><strong>Routing:</strong> Autonomous continuation or escalation to a human</li>
<li class="text-body-lg text-gosign-text-light"><strong>Documentation:</strong> Complete decision record per step</li>
<li class="text-body-lg text-gosign-text-light"><strong>Versioning:</strong> Every applied rule with version and timestamp</li>
</ul>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Integration</h2>
<p class="text-body-lg text-gosign-text-light mt-4">Workflow Agents connect existing systems via standardized interfaces:</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light">SAP FI/CO, SAP S/4HANA, SAP SuccessFactors</li>
<li class="text-body-lg text-gosign-text-light">Workday</li>
<li class="text-body-lg text-gosign-text-light">DATEV</li>
<li class="text-body-lg text-gosign-text-light">SharePoint, Microsoft Teams (via <a href="https://learn.microsoft.com/en-us/graph/overview" target="_blank" rel="noopener noreferrer">Microsoft Graph</a>)</li>
<li class="text-body-lg text-gosign-text-light">Active Directory / Azure AD</li>
<li class="text-body-lg text-gosign-text-light">Email (IMAP/Exchange)</li>
<li class="text-body-lg text-gosign-text-light">Others via REST/SOAP</li>
</ul>
</div>
</section>

<!-- Other Agent Types -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Other Agent Types</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/en/services/ai-agents/document-agents/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">The Specialist</p>
<p class="text-body font-semibold text-gosign-dark">Document Agents</p>
<p class="text-body text-gosign-text-light mt-2">Read, understand, and classify documents - with true language comprehension.</p>
</a>
<a href="/en/services/ai-agents/knowledge-agents/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">The Knowledge Carrier</p>
<p class="text-body font-semibold text-gosign-dark">Knowledge Agents</p>
<p class="text-body text-gosign-text-light mt-2">Answer questions from rule sets - with source citation and rule version.</p>
</a>
<a href="/en/services/ai-agents/co-build/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Custom Agents</p>
<p class="text-body font-semibold text-gosign-dark">Co-Build</p>
<p class="text-body text-gosign-text-light mt-2">Your process, your agent. 4-6 weeks to a productive agent.</p>
</a>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Deep Dive in the Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Our article series for decision-makers implementing AI agents in the enterprise.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/en/magazine/agent-orchestration-platforms/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">Agent Orchestration: Trigger.dev, n8n, Camunda, and Alternatives</p>
</a>
<a href="/en/magazine/ai-integration-it-landscape/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">AI Integration Into Existing IT Landscapes - SAP, DATEV, Workday</p>
</a>
<a href="/en/magazine/decision-layer-explained/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - What It Is and Why Every Enterprise AI Agent Needs One</p>
</a>
</div>
</div>
</section>

--- AI Agents for Enterprise Processes ---
> Document Agents, Workflow Agents, and Knowledge Agents. Specialized AI agents with Decision Layer, audit trail, and Human-in-the-Loop.

<!-- At a Glance -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h2 font-bold text-gosign-dark">At a Glance</h2>
<div class="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-3 gap-4 mt-6">
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">3 Agent Types</p>
<p class="text-body text-gosign-text-light mt-1">Document, Workflow, Knowledge - each with its own Decision Layer</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">4-6 Weeks</p>
<p class="text-body text-gosign-text-light mt-1">From Discover to productive PoC in your infrastructure</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">85-92% Zero-Touch</p>
<p class="text-body text-gosign-text-light mt-1">Routine cases processed autonomously - exceptions escalated to humans</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">7+ LLMs</p>
<p class="text-body text-gosign-text-light mt-1">Model-agnostic: Claude, ChatGPT, Gemini, Llama, Mistral, DeepSeek</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Full Source Code</p>
<p class="text-body text-gosign-text-light mt-1">No SaaS, no vendor lock-in - full access to code, prompts and rule sets</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">EU AI Act (UK: UK AI regulatory framework) Ready</p>
<p class="text-body text-gosign-text-light mt-1">Audit trail, Human-in-the-Loop, governance framework constraints</p>
</div>
</div>
</div>
</div>
</section>

<!-- Governance-First Intro -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Building an agent is easy. Making it enterprise-ready is not.</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Workflow agents can be prototyped in days. The real problem starts afterward: Is the agent's decision auditable? Does it meet EU AI Act requirements? Can employee representation bodies trace the rules the agent follows?
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
That is exactly where we come in. Not building the agent itself - but the governance layer that makes it production-ready, auditable, and certifiable. Enterprise processes rely on implicit knowledge: collective agreements, company policies, posting logic. An AI Agent structures these decisions, documents them, and makes them reproducible - across all locations and case workers.
</p>
</div>
</div>
</section>

<!-- Three Agent Types: Overview + Comparison Table -->
<section id="agent-types" class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Three Agent Types</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Every business process can be broken down into three tasks: understanding documents, coordinating workflows, and providing knowledge. Three specialized agent types handle these - each with its own Decision Layer and audit trail.
</p>
</div>
<img src="/images/diagrams/agent-types-overview.svg" alt="Three Agent Types: Document Agent (The Specialist), Workflow Agent (The Coordinator), Knowledge Agent (The Knowledge Keeper)" class="w-full max-w-3xl mx-auto mt-8 mb-8" width="1200" height="400" loading="lazy" />
<div class="max-w-narrow">
<div class="overflow-x-auto mt-4">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-dark">
<th class="py-3 pr-4 text-body font-bold text-gosign-dark"></th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Document Agent</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Workflow Agent</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Knowledge Agent</th>
</tr>
</thead>
<tbody class="text-body text-gosign-text-light">
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Role</td>
<td class="py-3 px-4">The Specialist</td>
<td class="py-3 px-4">The Coordinator</td>
<td class="py-3 px-4">The Knowledge Keeper</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Task</td>
<td class="py-3 px-4">Read, understand, and classify documents</td>
<td class="py-3 px-4">Orchestrate processes across system boundaries</td>
<td class="py-3 px-4">Answer questions from internal rule sets</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Replaces</td>
<td class="py-3 px-4">OCR + template matching</td>
<td class="py-3 px-4">RPA + manual workflows</td>
<td class="py-3 px-4">Search engine + chatbot</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Example</td>
<td class="py-3 px-4">Extract and classify a sick note</td>
<td class="py-3 px-4">Coordinate onboarding across SAP, AD, and email</td>
<td class="py-3 px-4">Answer leave entitlement with source citation</td>
</tr>
</tbody>
</table>
</div>
</div>

<!-- Agent Type 1: Document Agents -->
<div class="max-w-narrow mt-12">
<div class="flex items-start gap-4">
<span class="text-5xl font-bold text-gosign-accent/20 leading-none before:content-['01']" aria-hidden="true"></span>
<div>
<h3 class="text-h2 font-bold text-gosign-dark">Document Agents</h3>
<p class="text-body-lg text-gosign-text-light mt-2">The Specialist: understands documents with genuine language comprehension. No template recognition - contextual understanding of invoices, sick notes, and contracts. The Decision Layer evaluates every extraction and routes low-confidence results to a case worker.</p>
</div>
</div>
<div class="mt-4 bg-gosign-light border-l-4 border-gosign-accent rounded-card p-4">
<p class="text-small font-semibold text-gosign-dark">Human-in-the-Loop</p>
<p class="text-small text-gosign-text-light mt-1"><strong>Agent decides:</strong> Standard documents with high confidence (invoices with clear line items, sick notes with unambiguous dates).<br/><strong>Human decides:</strong> Ambiguous documents, deviating amounts, first-time suppliers, documents with free-text clauses. The agent prepares and recommends - the final approval rests with the case handler.</p>
</div>
<p class="mt-4">
<a href="/en/services/ai-agents/document-agents/" class="inline-flex items-center text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">
Document Agents in detail
<svg class="w-5 h-5 ml-2" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg>
</a>
</p>
</div>

<!-- Agent Type 2: Workflow Agents -->
<div class="max-w-narrow mt-10">
<div class="flex items-start gap-4">
<span class="text-5xl font-bold text-gosign-accent/20 leading-none before:content-['02']" aria-hidden="true"></span>
<div>
<h3 class="text-h2 font-bold text-gosign-dark">Workflow Agents</h3>
<p class="text-body-lg text-gosign-text-light mt-2">The Coordinator: orchestrates processes across systems. SAP, DATEV, SharePoint, Active Directory - one agent coordinates the entire flow via APIs. On queries, the workflow pauses, a human decides, and the agent resumes exactly where it left off.</p>
</div>
</div>
<div class="mt-4 bg-gosign-light border-l-4 border-gosign-accent rounded-card p-4">
<p class="text-small font-semibold text-gosign-dark">Human-in-the-Loop</p>
<p class="text-small text-gosign-text-light mt-1"><strong>Agent decides:</strong> Routing, system bookings, status updates, notifications - all according to defined rules in the Decision Layer.<br/><strong>Human decides:</strong> Personnel decisions (hiring, termination, transfer), budget approvals above thresholds, exceptions to company agreements. The workflow pauses until the human has decided.</p>
</div>
<p class="mt-4">
<a href="/en/services/ai-agents/workflow-agents/" class="inline-flex items-center text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">
Workflow Agents in detail
<svg class="w-5 h-5 ml-2" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg>
</a>
</p>
</div>

<!-- Agent Type 3: Knowledge Agents -->
<div class="max-w-narrow mt-10">
<div class="flex items-start gap-4">
<span class="text-5xl font-bold text-gosign-accent/20 leading-none before:content-['03']" aria-hidden="true"></span>
<div>
<h3 class="text-h2 font-bold text-gosign-dark">Knowledge Agents</h3>
<p class="text-body-lg text-gosign-text-light mt-2">The Knowledge Keeper: answers questions from enterprise knowledge - company policies, collective agreements, compliance rules. Every answer with source citation and rule version. Without a verified source, no answer - the architecture prevents hallucination.</p>
</div>
</div>
<div class="mt-4 bg-gosign-light border-l-4 border-gosign-accent rounded-card p-4">
<p class="text-small font-semibold text-gosign-dark">Human-in-the-Loop</p>
<p class="text-small text-gosign-text-light mt-1"><strong>Agent decides:</strong> Standard queries with clear source base (leave entitlement, notice period, responsibilities).<br/><strong>Human decides:</strong> Interpretation questions with conflicting rule sets, individual case assessments, questions about ongoing negotiations. When uncertain, the agent does not answer but escalates with context to the responsible domain expert.</p>
</div>
<p class="mt-4">
<a href="/en/services/ai-agents/knowledge-agents/" class="inline-flex items-center text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">
Knowledge Agents in detail
<svg class="w-5 h-5 ml-2" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg>
</a>
</p>
</div>
</div>
</section>

<!-- Working Together: Multi-Agent System -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Working Together: Three Agents, One Process</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
In practice, the three agent types work together. A Workflow Agent orchestrates the overall process and calls Document Agents and Knowledge Agents as specialists when needed.
</p>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6 mt-6">
<p class="font-semibold text-gosign-dark text-body">Example: Sick Note End-to-End</p>
<ol class="mt-3 space-y-2 text-body text-gosign-text-light list-decimal list-inside">
<li><strong>Document Agent</strong> detects the sick note in the email inbox, extracts the employee name, period, and diagnosis code.</li>
<li><strong>Workflow Agent</strong> checks the HR system: is this the third notification within six months?</li>
<li><strong>Knowledge Agent</strong> is called: "At what threshold does the reintegration requirement apply under the current collective agreement?"</li>
<li><strong>Workflow Agent</strong> evaluates the answers: threshold not reached - standard process applies.</li>
<li><strong>Decision Layer</strong> checks statutory constraints and governance framework requirements - calculate continued pay.</li>
<li><strong>Workflow Agent</strong> creates the SAP posting proposal, notifies the HR manager, and documents everything in the audit trail.</li>
</ol>
<p class="text-body text-gosign-text-light mt-3">
Six steps, three agent types, three systems - one continuous audit trail.
</p>
</div>
</div>
</div>
</section>

<!-- Mid-Page CTA -->
<section class="py-12 bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 text-center">
<p class="text-h2 font-bold text-white">Which agent type fits your process?</p>
<p class="text-body-lg text-white/80 mt-2">30 minutes. Your process. A concrete recommendation.</p>
<a href="/en/contact/" class="inline-block mt-6 px-8 py-3 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors">Schedule a consultation</a>
</div>
</section>

<!-- Specialized Agent Solutions -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Specialized Agent Solutions</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Document, Workflow, and Knowledge Agents are the building blocks. For HR and Finance, we offer pre-configured solutions with industry-specific rule sets. For other domains, we develop custom agents in a Co-Build model.
</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-4 gap-6 mt-8 max-w-content">
<a href="/en/hr-ai-agents/" class="group block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">HR & People Operations</p>
<p class="text-body font-semibold text-gosign-dark">HR AI Agents</p>
<p class="text-body text-gosign-text-light mt-2">6 agent products: Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Governance-ready.</p>
<p class="text-small text-gosign-accent-text mt-2">Assess 48 agents &rarr;</p>
<span class="inline-flex items-center gap-1 mt-2 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Overview <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
<a href="/en/finance-ai-agents/" class="group block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Finance & Accounting</p>
<p class="text-body font-semibold text-gosign-dark">Finance AI Agents</p>
<p class="text-body text-gosign-text-light mt-2">Document processing, account assignment, depreciation logic, correction postings. SAP and DATEV integration.</p>
<p class="text-small text-gosign-accent-text mt-2">Assess 49 agents &rarr;</p>
<span class="inline-flex items-center gap-1 mt-2 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Overview <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
<a href="/en/services/ai-agents/co-build/" class="group block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Custom Agents</p>
<p class="text-body font-semibold text-gosign-dark">Co-Build</p>
<p class="text-body text-gosign-text-light mt-2">Your process, your agent. 4-6 weeks from Discover to a productive agent with full source code access.</p>
<span class="inline-flex items-center gap-1 mt-4 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Details <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
<a href="/en/contact/" class="group block bg-gosign-dark rounded-card p-6 hover:bg-gosign-dark/90 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-white/60 mb-2">Next Step</p>
<p class="text-body font-semibold text-white">Schedule a Consultation</p>
<p class="text-body text-white/80 mt-2">30 minutes. Your use case. A concrete recommendation on which agent type fits.</p>
<span class="inline-flex items-center gap-1 mt-4 text-small font-semibold text-white/60 group-hover:text-white transition-colors">Schedule a consultation <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
</div>
</div>
</section>

<!-- Who It's For -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Who It's For</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
AI agents affect different stakeholders. Each has different questions.
</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-4 gap-6 mt-8 max-w-content">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">CHRO / VP HR</p>
<p class="text-body text-gosign-text-light mt-2">Governance-ready automation of HR processes - Payroll, Leave, Recruiting - with full audit trail and collective agreement compliance.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">CFO / Finance Lead</p>
<p class="text-body text-gosign-text-light mt-2">Automated document processing, account assignment, and reconciliation - consistent across all locations, auditable for external auditors.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Employee Oversight Bodies</p>
<p class="text-body text-gosign-text-light mt-2">Works councils, employee representation bodies, or compliance committees: full transparency over every agent decision. The Decision Layer maps governance frameworks as explicit constraints. Human-in-the-Loop where it matters.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">CTO / IT Lead</p>
<p class="text-body text-gosign-text-light mt-2">Model-agnostic architecture. API-based integration with SAP, DATEV, Workday. No vendor lock-in, full source code access.</p>
</div>
</div>
</div>
</section>

<!-- Decision Layer -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Decision Layer</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
The Decision Layer breaks every business process into individual decision steps and defines for each step: human, rule set, or AI. Every decision is documented - traceable for auditors, employee representation bodies, and internal compliance.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Different for each agent type: for Document Agents, it checks extraction quality. For Workflow Agents, it controls routing. For Knowledge Agents, it prevents hallucination.
</p>
<p class="mt-4">
<a href="/en/decision-layer/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Decision Layer in detail</a>
</p>
</div>
</div>
</section>

<!-- Integration + Model Agnosticism -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Integration and Model Agnosticism</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
AI agents do not replace existing systems. SAP remains ERP. Workday remains HCM. DATEV remains tax system. Agent logic is decoupled from the target system.
</p>
<div class="grid grid-cols-2 sm:grid-cols-3 gap-3 mt-6">
<div class="bg-gosign-white rounded-card px-4 py-3 text-body text-gosign-text-light">SAP FI/CO, S/4HANA</div>
<div class="bg-gosign-white rounded-card px-4 py-3 text-body text-gosign-text-light">SAP SuccessFactors</div>
<div class="bg-gosign-white rounded-card px-4 py-3 text-body text-gosign-text-light">Workday</div>
<div class="bg-gosign-white rounded-card px-4 py-3 text-body text-gosign-text-light">DATEV</div>
<div class="bg-gosign-white rounded-card px-4 py-3 text-body text-gosign-text-light">SharePoint, Teams</div>
<div class="bg-gosign-white rounded-card px-4 py-3 text-body text-gosign-text-light">Active Directory</div>
</div>
<p class="text-body-lg text-gosign-text-light mt-6">
The architecture is not tied to a single LLM: Claude, ChatGPT, Gemini, Llama, Mistral, DeepSeek - models are interchangeable without changing the business logic. No vendor lock-in.
</p>
</div>
</div>
</section>

<!-- Business Impact + Ownership -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Business Impact</h2>
<ul class="mt-6 space-y-3">
<li class="text-body-lg text-gosign-text-light">Routine cases processed autonomously - with complete documentation</li>
<li class="text-body-lg text-gosign-text-light">Consistent rule interpretation across all locations</li>
<li class="text-body-lg text-gosign-text-light">Every decision traceable for auditors and employee representation bodies</li>
<li class="text-body-lg text-gosign-text-light">Scalable without proportional headcount increase</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-6">
Full access to the source code, all prompts, and all rule sets. After 12-18 months, you operate your agents independently. No SaaS subscription, no platform lock-in.
</p>
</div>
</div>
</section>

<!-- Deep Dive -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Deep Dive in the Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Our article series for decision-makers implementing AI agents in the enterprise.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/en/magazine/ai-agents-enterprise-guide/" class="group block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors bg-gosign-white">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">AI Agents</p>
<p class="text-body font-semibold text-gosign-dark">From Chatbots to AI Agents: MCP, A2A and Multi-Agent Systems</p>
<span class="inline-flex items-center gap-1 mt-3 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Read <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
<a href="/en/magazine/agent-orchestration-platforms/" class="group block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors bg-gosign-white">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">Agent Orchestration: Trigger.dev, n8n, Camunda, and Alternatives</p>
<span class="inline-flex items-center gap-1 mt-3 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Read <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
<a href="/en/magazine/decision-layer-explained/" class="group block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors bg-gosign-white">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - What It Is and Why Every Enterprise AI Agent Needs One</p>
<span class="inline-flex items-center gap-1 mt-3 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Read <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
</div>
</div>
</section>

--- Document Intelligence - PII, Contract Redaction, Signature Detection ---
> Process documents with AI without exposing personal data. PII anonymization, contract redaction, signature detection - Decision Layer governed.

<!-- The Problem -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">The Problem: Personal Data in Every Document</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Enterprises want to process documents with AI - analyze contracts, classify invoices, query policies. But every document contains personal data: names, salaries, social security numbers, addresses, bank details, signatures.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Sending this data to a language model - even a self-hosted one - without protection violates GDPR principles of data minimization. Employee governance agreements restrict processing of employee data. Trade secrets in contracts must not reach third parties.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Current approaches fall short: Manual redaction in Adobe Acrobat is time-consuming, error-prone, and often only cosmetic - the text remains accessible beneath the black bars. Alternatively, avoiding AI processing for sensitive documents eliminates most of the productivity gain.
</p>
</div>
</div>
</section>

<!-- Three Capabilities -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">Three Capabilities</h2>
<div class="grid grid-cols-1 md:grid-cols-3 gap-6">
<div class="bg-white rounded-card p-6 border border-gosign-border">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">PII Anonymization for LLM Input</h3>
<p class="text-body text-gosign-text-light">Roundtrip pseudonymization: personal data is replaced with consistent pseudonyms before LLM input. The output is re-anonymized - real data appears only in the result, never in the model. The mapping table never leaves the pre-processing layer.</p>
<a href="#pii-anonymization" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold text-body mt-3 inline-block">Details</a>
</div>
<div class="bg-white rounded-card p-6 border border-gosign-border">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Contract Redaction</h3>
<p class="text-body text-gosign-text-light">Rule-based redaction for different recipients. The same contract is redacted differently for employee representatives, due diligence, or external advisors - governed by versioned redaction rules in the Decision Layer. Physical redaction, not just visual overlay.</p>
<a href="#contract-redaction" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold text-body mt-3 inline-block">Details</a>
</div>
<div class="bg-white rounded-card p-6 border border-gosign-border">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Signature Detection</h3>
<p class="text-body text-gosign-text-light">Automated detection of signature fields and present signatures in documents. Bulk verification of contract archives, onboarding quality checks, audit preparation. Anomalies are escalated to humans - never autonomously accepted.</p>
<a href="#signature-detection" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold text-body mt-3 inline-block">Details</a>
</div>
</div>
</div>
</section>

<!-- PII Anonymization Detail -->
<section id="pii-anonymization" class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">PII Anonymization: Roundtrip Pseudonymization for LLM Input</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Most PII tools on the market perform one-way redaction - they remove data. For processing with language models, that is insufficient. When an agent needs to analyze a contract, it requires context: "Employee X has salary Y at location Z." Without this context, the model cannot produce a meaningful assessment.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
The Gosign approach is roundtrip pseudonymization: data is pseudonymized before the model, processed by the model, and re-anonymized in the result. The model only sees pseudonyms. The result contains the real data.
</p>

<pre class="bg-gosign-dark text-white p-6 rounded-card overflow-x-auto text-small font-mono leading-relaxed mt-6"><code>┌─────────────┐     ┌──────────────────┐     ┌─────────────┐     ┌──────────────────┐     ┌─────────────┐
│  Document   │     │  PII Detection   │     │  Pseudonym-  │     │  Language Model  │     │  Re-Mapping │
│  (Original) │────▶│  & Classifi-     │────▶│  ization     │────▶│  processes only  │────▶│  Pseudonyms │
│             │     │  cation          │     │              │     │  pseudonyms      │     │  → real data│
└─────────────┘     └──────────────────┘     └──────────────┘     └──────────────────┘     └─────────────┘
│                        │                                            │
▼                        ▼                                            ▼
┌──────────────┐         ┌──────────────┐                              ┌──────────────┐
│  Decision    │         │  Mapping     │                              │  Result      │
│  Layer:      │         │  Table       │◀─────────────────────────────│  with real   │
│  What gets   │         │  (stays      │   Reverse mapping           │  data        │
│  anonymized  │         │  local)      │                              └──────────────┘
└──────────────┘         └──────────────┘</code></pre>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">Decision Steps in the PII Process</h3>
<div class="mt-4 overflow-x-auto">
<table class="w-full text-body text-gosign-text-light border-collapse">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="text-left py-2 pr-4 font-bold text-gosign-dark">Micro-Decision</th>
<th class="text-left py-2 pr-4 font-bold text-gosign-dark">Who Decides</th>
<th class="text-left py-2 font-bold text-gosign-dark">Why</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Define PII categories</td><td class="py-2 pr-4">Human + Ruleset</td><td class="py-2">GDPR requirements, governance agreement, client-specific rules</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Detect PII in document</td><td class="py-2 pr-4">AI (NER + patterns)</td><td class="py-2">Named Entity Recognition + rule-based patterns</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Review false positives</td><td class="py-2 pr-4">AI; human when uncertain</td><td class="py-2">Confidence routing - "Baker" as surname or occupation?</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Assign pseudonyms</td><td class="py-2 pr-4">Automatic</td><td class="py-2">Consistent mapping, "Person_A" instead of "John Smith"</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Send pseudonymized document to model</td><td class="py-2 pr-4">Automatic</td><td class="py-2">No decision, pure forwarding</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Re-anonymize output</td><td class="py-2 pr-4">Automatic</td><td class="py-2">Apply mapping table in reverse</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Audit: what was anonymized</td><td class="py-2 pr-4">Automatic</td><td class="py-2">GDPR evidence in audit trail</td></tr>
</tbody>
</table>
</div>
<p class="text-body-lg text-gosign-text-light mt-4">
The mapping table (pseudonym → real data) never leaves the pre-processing layer. It is deleted after processing is complete - or retained for a defined period, depending on configuration. The language model never sees personal data at any point.
</p>
</div>
</div>
</section>

<!-- Contract Redaction Detail -->
<section id="contract-redaction" class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Contract Redaction: Rule-Based, Recipient-Dependent, Physical</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Contracts regularly need to be shared in redacted form - with auditors, potential buyers during due diligence, with employee representation bodies, with external advisors. Today, someone does this manually. It takes hours per contract, is error-prone, and the redaction is often only cosmetic: the text remains accessible beneath the black bars. A frequently underestimated data leak.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
The Gosign approach: the Document Agent recognizes contract structure - parties, amounts, terms, clauses, signatures. The Decision Layer defines recipient-dependent redaction rules:
</p>

<div class="mt-6 overflow-x-auto">
<table class="w-full text-body text-gosign-text-light border-collapse">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="text-left py-2 pr-4 font-bold text-gosign-dark">Contract Element</th>
<th class="text-left py-2 pr-4 font-bold text-gosign-dark">Employee Rep.</th>
<th class="text-left py-2 pr-4 font-bold text-gosign-dark">Due Diligence</th>
<th class="text-left py-2 pr-4 font-bold text-gosign-dark">External Advisor</th>
<th class="text-left py-2 font-bold text-gosign-dark">Auditor</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Contracting parties (names)</td><td class="py-2 pr-4">✓ Visible</td><td class="py-2 pr-4">✗ Redacted</td><td class="py-2 pr-4">✗ Redacted</td><td class="py-2">✓ Visible</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Contract values / amounts</td><td class="py-2 pr-4">✓ Visible</td><td class="py-2 pr-4">✓ Visible</td><td class="py-2 pr-4">✗ Redacted</td><td class="py-2">✓ Visible</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Salaries / compensation</td><td class="py-2 pr-4">✓ Visible</td><td class="py-2 pr-4">Aggregated</td><td class="py-2 pr-4">✗ Redacted</td><td class="py-2">✓ Visible</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Contract clauses</td><td class="py-2 pr-4">✓ Visible</td><td class="py-2 pr-4">✓ Visible</td><td class="py-2 pr-4">Clause types only</td><td class="py-2">✓ Visible</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Trade secrets</td><td class="py-2 pr-4">✗ Redacted</td><td class="py-2 pr-4">✓ Visible</td><td class="py-2 pr-4">✗ Redacted</td><td class="py-2">✓ Visible</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Signatures</td><td class="py-2 pr-4">✗ Redacted</td><td class="py-2 pr-4">✗ Redacted</td><td class="py-2 pr-4">✗ Redacted</td><td class="py-2">✓ Visible</td></tr>
</tbody>
</table>
</div>

<p class="text-body-lg text-gosign-text-light mt-4">
Redaction rules are versioned in the Decision Layer. When requirements change - new recipient group, updated governance agreement, changed compliance rule - a new rule version is created. The previous version remains traceable.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong>Physical redaction:</strong> The PDF is re-rendered from scratch. The original data is physically no longer present in the document - not as text, not as metadata, not as an invisible layer. No copy-paste beneath black bars, no PDF editing to uncover content. This is not cosmetic - it is cryptographically clean.
</p>
</div>
</div>
</section>

<!-- Signature Detection Detail -->
<section id="signature-detection" class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Signature Detection: Find, Verify, Document</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Contract management, audit preparation, compliance reviews - all require regular verification: Is this document signed? Where is the signature? Is a countersignature missing? With 5,000 contracts in the archive, manual checking is not feasible.
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">Signature Detection - Finding Signatures</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
The Document Agent detects signature fields and present signatures in scanned documents and PDFs. Computer vision, not a language model - specialized ML models for image analysis. The output is structured: page, position, confidence that a signature is present.
</p>

<p class="text-body-lg text-gosign-text-light mt-6">
<strong>Bulk archive verification:</strong> "Which of the 5,000 contracts are missing a countersignature?" - Results in minutes instead of weeks.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong>Onboarding quality check:</strong> "Are all mandatory documents for the new employee signed?" - Automated checklist, missing signatures escalated as workflow tasks.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong>Audit preparation:</strong> "Show all documents without a signature in Q3 2025." - Structured export list for the auditor.
</p>

<pre class="bg-gosign-dark text-white p-6 rounded-card overflow-x-auto text-small font-mono leading-relaxed mt-6"><code>┌─────────────┐     ┌──────────────────┐     ┌──────────────────┐
│  Document   │     │  Signature       │     │  Comparison      │
│  with       │────▶│  Detection       │────▶│  against         │
│  signature  │     │  (position,      │     │  reference       │
│             │     │   confidence)    │     │  signature       │
└─────────────┘     └──────────────────┘     └──────────────────┘
│
┌───────────┼───────────┐
▼           ▼           ▼
┌────────────┐ ┌────────┐ ┌────────────┐
│  High      │ │ Medium │ │  Low       │
│  match     │ │ match  │ │  match     │
└────────────┘ └────────┘ └────────────┘
│              │           │
▼              ▼           ▼
Automatically  Escalation   Blocked
accepted,      to human     Human
documented     with side-   review
by-side      mandatory
comparison
view</code></pre>

<p class="text-body-lg text-gosign-text-light mt-4">
<strong>Important:</strong> Signature comparison is an anomaly detector, not a forgery detector. Signatures vary naturally - depending on the day, pen, and surface. The system identifies anomalies and escalates them to a human. It never claims "this signature is forged" or "this signature is authentic." That would be irresponsible.
</p>
</div>
</div>
</section>

<!-- Decision Layer -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">The Decision Layer: Who Decides What Gets Anonymized, Redacted, or Escalated?</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
The Decision Layer decomposes every document process into individual decision steps. For each step, it defines: human, ruleset, or AI.
</p>

<div class="mt-6 overflow-x-auto">
<table class="w-full text-body text-gosign-text-light border-collapse">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="text-left py-2 pr-4 font-bold text-gosign-dark">Process</th>
<th class="text-left py-2 pr-4 font-bold text-gosign-dark">Micro-Decision</th>
<th class="text-left py-2 pr-4 font-bold text-gosign-dark">Who Decides</th>
<th class="text-left py-2 font-bold text-gosign-dark">Why</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-bold">PII</td><td class="py-2 pr-4">Which data fields are PII?</td><td class="py-2 pr-4">Ruleset</td><td class="py-2">GDPR Art. 4, governance agreement</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-bold">PII</td><td class="py-2 pr-4">Is "Baker" a name or an occupation?</td><td class="py-2 pr-4">AI; human at &lt;80% confidence</td><td class="py-2">NER ambiguity - avoid false positives</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-bold">PII</td><td class="py-2 pr-4">Choose pseudonymization method</td><td class="py-2 pr-4">Ruleset</td><td class="py-2">Consistent pseudonyms vs. random values</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-bold">Redaction</td><td class="py-2 pr-4">Which recipient group?</td><td class="py-2 pr-4">Human</td><td class="py-2">Domain decision, not automatable</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-bold">Redaction</td><td class="py-2 pr-4">Which fields are redacted?</td><td class="py-2 pr-4">Ruleset</td><td class="py-2">Recipient-dependent redaction matrix</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-bold">Redaction</td><td class="py-2 pr-4">Unknown clause type detected</td><td class="py-2 pr-4">Human</td><td class="py-2">New clause types must be classified</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-bold">Signature</td><td class="py-2 pr-4">Signature present?</td><td class="py-2 pr-4">AI</td><td class="py-2">Computer vision with confidence score</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-bold">Signature</td><td class="py-2 pr-4">Does signature match reference?</td><td class="py-2 pr-4">AI + human on anomaly</td><td class="py-2">High match: accepted. Anomaly: escalated</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-bold">Signature</td><td class="py-2 pr-4">No reference available</td><td class="py-2 pr-4">Human</td><td class="py-2">New reference signature must be captured</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-bold">All</td><td class="py-2 pr-4">Document audit trail</td><td class="py-2 pr-4">Automatic</td><td class="py-2">Every decision immutably recorded</td></tr>
</tbody>
</table>
</div>
</div>
</div>
</section>

<!-- Integration -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Integration</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Document Intelligence is a capability of the existing Document Agent - not separate software. Integration uses the same standardized interfaces:
</p>
<ul class="mt-4 space-y-2 text-body-lg text-gosign-text-light list-disc pl-6">
<li>SAP DMS, SAP ArchiveLink - contracts and receipts from SAP archives</li>
<li>SharePoint, OneDrive - document management via Microsoft Graph</li>
<li>Email inboxes (IMAP/Exchange) - process attachments automatically</li>
<li>File system watchers - monitor local directories</li>
<li>REST API - for client-specific DMS systems</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-4">
Document Intelligence capabilities are configured per tenant: which PII categories are detected, which redaction rules apply, which reference signatures are stored. All versioned, all in the Decision Layer.
</p>
</div>
</div>
</section>

<!-- Business Impact -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Business Impact</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong>GDPR-compliant LLM processing:</strong> Documents containing personal data can be securely processed with language models for the first time - without privacy risk.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong>Contract redaction in minutes instead of hours:</strong> Rule-based, recipient-dependent, physically secure. A contract that takes 2 hours manually is processed in seconds.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong>Proactive signature gap detection:</strong> Missing signatures are found before the auditor asks - not after.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong>Audit evidence for data protection:</strong> The audit trail documents every anonymization, every redaction, every signature check. During a GDPR inquiry or tax audit, it is provable which data was processed when and how.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong>No new tool:</strong> Document Intelligence is part of the existing agent architecture. No additional vendor, no additional license, no additional training.
</p>
</div>
</div>
</section>

<!-- Deep Dive -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Deep Dive in the Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Our article series for decision-makers implementing AI agents in the enterprise.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/en/magazine/rag-document-intelligence-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">RAG &amp; Document Intelligence: How AI Understands Your Documents</p>
</a>
<a href="/en/magazine/pii-anonymization-llm-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">PII Anonymization for Enterprise AI</p>
</a>
<a href="/en/magazine/data-security-ai-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Data Security in Enterprise AI - Data Residency, GDPR and EU AI Act (UK: UK AI regulatory framework)</p>
</a>
</div>
</div>
</section>

--- eIDAS-Compliant Digital Signatures - Gosign ---
> Digital signature solutions under the eIDAS regulation. Simple, advanced, and qualified electronic signatures for enterprise document processes.

<!-- eIDAS Regulation -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">eIDAS Regulation</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
The <a href="https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32014R0910" target="_blank" rel="noopener noreferrer">eIDAS regulation (Regulation (EU) No 910/2014)</a> creates a European legal framework for electronic identification and trust services. For enterprise document processes, the three signature levels are particularly relevant.
</p>
</div>
</section>

<!-- Three Signature Levels -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">Three Signature Levels</h2>
<div class="grid grid-cols-1 md:grid-cols-3 gap-6">
<div class="bg-white rounded-card p-6 border border-gosign-border">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Simple Electronic Signature (SES)</h3>
<p class="text-body text-gosign-text-light">No special technical requirements. Examples: scanned signature, name under an email, clicking 'I agree.' Limited evidential value, but sufficient for many business processes.</p>
</div>
<div class="bg-white rounded-card p-6 border border-gosign-border">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Advanced Electronic Signature (AES)</h3>
<p class="text-body text-gosign-text-light">Uniquely linked to the signatory. Enables identification. Created under sole control. Subsequent changes detected. Use case: contracts, approvals, internal authorization processes.</p>
</div>
<div class="bg-white rounded-card p-6 border border-gosign-border">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Qualified Electronic Signature (QES)</h3>
<p class="text-body text-gosign-text-light">Highest signature level. Legal effect of a handwritten signature (Art. 25 Para. 2 eIDAS). Created with a qualified certificate from an approved trust service provider. Use case: where legal written form is required.</p>
</div>
</div>
</div>
</section>

<!-- Enterprise Integration -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Enterprise Integration</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Gosign integrates eIDAS-compliant signatures into existing document processes:
</p>
<div class="mt-6 space-y-6">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">In <a href="/en/services/document-intelligence/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Document Agent</a> workflows</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
After automated document processing, a digital signature can be triggered as a closing step - e.g., after invoice approval or contract confirmation.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">In approval processes</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Multi-step approvals with digital signatures. Every signature is documented in the <a href="/en/decision-layer/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Decision Layer audit trail</a>.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">API integration</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Connection to existing systems via REST API. The signature infrastructure is provided by the trust service provider - Gosign implements the integration.
</p>
</div>
</div>
</div>
</section>

<!-- Cooperation -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Cooperation with ETSI-Certified Partners</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Gosign is not a trust service provider. We implement eIDAS-compliant signature solutions in cooperation with providers certified under ETSI EN 319 401 and the respective specific standards.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
The choice of trust service provider depends on client requirements: signature level, volume, integration requirements, existing contracts.
</p>
</div>
</section>

<!-- Compliance -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Compliance</h2>
<div class="mt-6 space-y-2">
<p class="text-body-lg text-gosign-text-light">EU-wide legally valid under the eIDAS regulation.</p>
<p class="text-body-lg text-gosign-text-light">GDPR-compliant (data processing by certified trust service provider, <a href="/en/governance/data-residency/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Data Residency</a> in the EU).</p>
<p class="text-body-lg text-gosign-text-light">Audit trail for all signature operations.</p>
<p class="text-body-lg text-gosign-text-light">Long-term validation (LTV) for qualified signatures.</p>
</div>
</div>
</section>

<!-- Deep Dive in the Agent Briefing -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Deep Dive in the Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Our article series for decision-makers securing digital processes in the enterprise.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/en/magazine/cert-ready-by-design/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Cert-Ready by Design: Why Retrofitting Certification Fails</p>
</a>
<a href="/en/magazine/rag-document-intelligence-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">AI Agents</p>
<p class="text-body font-semibold text-gosign-dark">RAG and Document Intelligence in Enterprise</p>
</a>
<a href="/en/magazine/data-security-ai-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">Data Security for AI in Enterprise</p>
</a>
</div>
</div>
</section>

--- AI Leave Agent Aviation - Absence Management ---
> Leave Decision Layer for aviation. Multiple bargaining units, EASA FTL, Medical Grounding, crew pairing. 78% zero-touch.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/en/why-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Every decision traceable</p>
</div>
</a>
<a href="/en/why-gosign/#infrastructure" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Your infrastructure</p>
<p class="text-xs text-gosign-text-light">No SaaS. No vendor lock-in.</p>
</div>
</a>
<a href="/en/why-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">No US cloud risk</p>
</div>
</a>
</div>
</div>
</div>



<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Leave Decision Layer Industries">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/en/services/hr-agent/leave-absence-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Leave Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/en/services/hr-agent/leave-absence-decision-layer/chemicals/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Chemicals</a>
<a href="/en/services/hr-agent/leave-absence-decision-layer/aviation/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Aviation</a>
<a href="/en/services/hr-agent/leave-absence-decision-layer/financial-services/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Financial Services</a>
<a href="/en/services/hr-agent/leave-absence-decision-layer/retail/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Retail</a>
</div>
</div>
</nav>

<!-- Complexity -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">3</span>
<p class="text-small text-gosign-text-light mt-1">Bargaining units</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">78%</span>
<p class="text-small text-gosign-text-light mt-1">Zero-touch rate</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">EASA</span>
<p class="text-small text-gosign-text-light mt-1">FTL compliance</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">Highest rule complexity</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">Multiple collective agreements (cockpit, cabin, ground). Zero-touch: Gosign simulation model.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">What the Agent classifies</p>
<h2 class="text-h1 font-bold text-gosign-dark">Five dimensions, one Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Multiple bargaining units with separate collective agreements, regulatory mandatory rest periods, Medical Grounding, crew pairing as operational constraint, and seasonal blackout periods. You know the complexity. Here is how the AI Agent resolves it:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Multiple collective agreements in parallel</h3>
<p class="text-body text-gosign-text mt-2">Cockpit, cabin, and ground staff - each bargaining unit has its own collective agreement with separate leave rules, special leave, and compensatory time off. The AI Agent identifies the staff group and applies the correct rule set. No confusion between pilot leave and ground staff leave.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">EASA FTL mandatory rest periods</h3>
<p class="text-body text-gosign-text mt-2">Flight Time Limitations are regulatory mandatory rest periods that must not count as leave. The AI Agent separates cleanly: FTL rest periods run in separate tracking, leave entitlements are not reduced by mandatory rest. During leave planning, the agent checks FTL compliance against the flight schedule. (UK: UK CAA regulations post-Brexit apply separate FTL frameworks for UK-registered operators.)</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Medical Grounding</h3>
<p class="text-body text-gosign-text mt-2">Loss of Medical Certificate (Class 1 cockpit, Class 2 cabin) is not regular sickness but a regulatory absence. The AI Agent classifies Medical Grounding as a separate leave type with collective-agreement-specific consequences. Health data remains architecturally separated - the agent sees only the status, not the diagnosis.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Crew pairing as constraint</h3>
<p class="text-body text-gosign-text mt-2">Cockpit and cabin must be staffed together for every flight. The AI Agent checks every leave request against crew availability and the flight schedule, including minimum staffing per position. On potential breach: automatic escalation with an alternative suggestion and context for the scheduler.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Seasonal blackout periods</h3>
<p class="text-body text-gosign-text mt-2">Summer programme and Christmas peak operations mean blackout periods for flight crew. The AI Agent knows the blackout periods from the company governance framework and checks every request against them. Exceptions require a line manager decision - the agent documents the exception in the audit trail.</p>
</div>
</div>
</div>
</section>

<!-- Decision Flow -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">One leave request in aviation. 10 decision steps.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">A pilot submits a leave request. The Leave Decision Layer breaks the transaction into individual decision steps:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Step</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decision</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decision maker</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Rationale</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Identify staff group and collective agreement</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent identifies: cockpit, cabin, or ground from employee master data</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Classify leave type</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent identifies: annual leave, special leave, FTL rest period, or Medical Grounding</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Calculate leave entitlement</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">Collective-agreement-specific base leave + additional leave (long-haul, seniority)</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Check EASA FTL compliance</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">Minimum rest periods between duties, flight hour accumulation, duty period limits</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Check crew pairing and minimum staffing</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent checks crew availability against flight schedule and minimum staffing per position</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Check blackout periods</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">Summer programme, Christmas peak, company-agreed blackout periods</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Generate approval recommendation</td><td class="py-3 px-4">AI recommends, human decides</td><td class="py-3 px-4">All rules met: recommend approval. Conflict: escalation with context</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">Check return-to-work threshold</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">42+ sick days in 12 months rolling. Medical Grounding tracked as special case separately</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Calculate sick pay continuation</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">Statutory sick pay period per case, collective-agreement-specific top-up where applicable</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Generate audit entry</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">Complete decision record: leave type, collective agreement, FTL status, crew check, result</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Simulation -->
<section id="simulation" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulation</p>
<h2 class="text-h1 font-bold text-white">Calculated for aviation volumes</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">We configured the Leave Decision Layer with realistic aviation parameters and ran the simulation. Multiple bargaining units, EASA FTL, Medical Grounding, crew pairing.</p>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Simulation parameters</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Employees</td><td class="py-3 px-4">5,000 to 80,000+ (cockpit, cabin, ground)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Collective agreements</td><td class="py-3 px-4">Separate agreements for cockpit, cabin, and ground staff</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Regulatory framework</td><td class="py-3 px-4">EASA FTL (EU-OPS), Medical Certificates Class 1 and Class 2</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Leave types</td><td class="py-3 px-4">Annual leave, FTL rest period, Medical Grounding, standby, special leave</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Constraints</td><td class="py-3 px-4">Crew pairing, seasonal blackouts, bases (hubs and outstations)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Return-to-work rate</td><td class="py-3 px-4">Industry average sickness rate for aviation, Medical Grounding separate</td></tr>
</tbody>
</table>
</div>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Before / After</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th scope="col" class="text-left py-3 px-4 font-semibold text-white">Dimension</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manual</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Leave request processing time</td><td class="py-3 px-4">2-5 days (crew check)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 2 minutes</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Zero-touch rate</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">78%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">FTL conflicts detected</td><td class="py-3 px-4">Manual by scheduler</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatic in real time</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Medical Grounding correctly classified</td><td class="py-3 px-4">Error-prone</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">100% correct (dedicated leave type)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Return-to-work deadline failures</td><td class="py-3 px-4">12-18%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">0% (automatic trigger)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Audit readiness</td><td class="py-3 px-4">Manually reconstructed</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatically generated</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">EASA FTL: EU Regulation 965/2012 Subpart FTL. Sickness rates: industry averages. Simulation results: Gosign model calculation.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">In our simulation, the Decision Layer achieves a zero-touch rate of 78%. The lower rate reflects the high regulatory density: crew pairing conflicts, Medical Grounding classification, and FTL edge cases require human decisions more frequently. For the 78%, a complete, audit-ready decision record is available.</p>
</div>
</section>

<!-- Architecture Reference -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Architecture and implementation</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">The Leave Decision Layer runs entirely within your infrastructure. For aviation, this means: integration with crew management systems, FTL tracking, medical database, and a complete audit trail. Typical pilot projects start with one staff group (e.g. ground) and expand to cockpit and cabin.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/en/services/hr-agent/leave-absence-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Leave Decision Layer overview &rarr;</a>
<a href="/en/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Decision Layer architecture &rarr;</a>
<a href="/en/services/infrastructure/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infrastructure in detail &rarr;</a>
<a href="/en/governance/co-determination/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Co-determination &rarr;</a>
<a href="/en/services/hr-agent/payroll-decision-layer/aviation/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Payroll Decision Layer Aviation &rarr;</a>
</div>
</div>
</section>


<!-- Weitere Agent-Lösungen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">More Agent Solutions</h2>
<p class="text-body-lg text-gosign-text-light mt-4">HR Agents are part of our agent portfolio. We offer specialized solutions for Finance and other domains.</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8 max-w-content">
<a href="/en/hr-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR & People Operations</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">All HR Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Works-council ready.</p>
</a>
<a href="/en/finance-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Finance & Accounting</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Finance AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Document processing, account assignment, depreciation logic, correction postings.</p>
</a>
<a href="/en/contact/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Custom</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Co-Build for Your Process</h3>
<p class="text-body text-gosign-text-light mt-2">Compliance, operations, shared services - we develop agents in a co-build model.</p>
</a>
</div>
</div>
</section>

<!-- Deep Dive -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Deep Dive in the Agent Briefing (Gosign Magazine)</h2>
<p class="text-body text-gosign-text-light mb-6">Our expert article series for decision-makers deploying AI Agents in the enterprise.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/en/magazine/works-council-ai-co-determination/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Co-Determination</p>
<p class="text-body font-semibold text-gosign-dark">Works Council and AI - Co-Determination as Architecture Constraint</p>
</a>
<a href="/en/magazine/agent-governance-hr/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Agent Governance for HR - Why Rule Engines Matter More Than Models</p>
</a>
<a href="/en/magazine/decision-layer-explained/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Fundamentals</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - What Is It and Why Does Every Enterprise AI Agent Need One?</p>
</a>
</div>
</div>
</section>

<!-- Other Industries -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Leave Decision Layer in Other Industries</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Every industry has its own collective agreements, its own leave types, and its own complexity drivers. The Decision Layer is the same. The configuration is industry-specific.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/en/services/hr-agent/leave-absence-decision-layer/chemicals/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Chemicals</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">Site-level agreements, collective-agreement time-off option, shift-supplement leave, hazardous materials return-to-work</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">83% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Details &rarr;</span>
</div>
</a>
<a href="/en/services/hr-agent/leave-absence-decision-layer/financial-services/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Financial Services</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">Regulatory mandatory leave, compliance-mandated leave blocks, banking holidays, phased retirement</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">85% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Details &rarr;</span>
</div>
</a>
<a href="/en/services/hr-agent/leave-absence-decision-layer/retail/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Retail</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">6-day working week, 64% part-time ratio, seasonal blackout periods, variable-hours contracts</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">87% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Details &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- AI Leave Agent Chemicals - Absence Management ---
> Leave Decision Layer for the chemical industry. Multi-site agreements, shift bonus leave, hazardous substance return-to-work. 83% zero-touch.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/en/why-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Every decision traceable</p>
</div>
</a>
<a href="/en/why-gosign/#infrastructure" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Your infrastructure</p>
<p class="text-xs text-gosign-text-light">No SaaS. No vendor lock-in.</p>
</div>
</a>
<a href="/en/why-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">No US cloud risk</p>
</div>
</a>
</div>
</div>
</div>



<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Leave Decision Layer Industries">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/en/services/hr-agent/leave-absence-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Leave Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/en/services/hr-agent/leave-absence-decision-layer/chemicals/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Chemicals</a>
<a href="/en/services/hr-agent/leave-absence-decision-layer/aviation/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Aviation</a>
<a href="/en/services/hr-agent/leave-absence-decision-layer/financial-services/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Financial Services</a>
<a href="/en/services/hr-agent/leave-absence-decision-layer/retail/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Retail</a>
</div>
</div>
</nav>

<!-- Complexity -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">30+</span>
<p class="text-small text-gosign-text-light mt-1">Leave types</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">83%</span>
<p class="text-small text-gosign-text-light mt-1">Zero-touch rate</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">Multi</span>
<p class="text-small text-gosign-text-light mt-1">Site-level agreements</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">Highest rule complexity</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">Chemical industry collective agreement. Zero-touch: Gosign simulation model.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">What the Agent classifies</p>
<h2 class="text-h1 font-bold text-gosign-dark">Five dimensions, one Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Base leave entitlements per collective agreement, shift bonus leave up to 5 days, compensation-to-leave conversion options, hazardous substance return-to-work, minimum staffing in continuous-process production. You know the complexity. Here is how the AI Agent resolves it:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Shift bonus leave by model</h3>
<p class="text-body text-gosign-text mt-2">Full continuous shift 5 days, partial continuous shift 3 days, rotating shift 2 days. The AI Agent identifies the shift model from the shift plan and assigns the correct bonus leave. When the shift model changes, the rule engine prorates the entitlement automatically - no manual recalculation across 5,000 shift workers.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Compensation-to-leave conversion</h3>
<p class="text-body text-gosign-text mt-2">Many chemical industry collective agreements allow employees to convert part of their compensation into additional days off instead of cash or pension contributions. The AI Agent manages each employee's individual election, calculates the resulting number of free days, and books them correctly into the leave account. When the annual election changes: automatic adjustment from the following month.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Hazardous substance return-to-work</h3>
<p class="text-body text-gosign-text mt-2">For employees with extended sick leave and hazardous substance exposure, return-to-work relevance is particularly high - occupational diseases require occupational health oversight. The AI Agent detects the exposure from the risk assessment and flags return-to-work cases for occupational health support. Health data remains architecturally separated.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Minimum staffing in continuous process</h3>
<p class="text-body text-gosign-text mt-2">In chemical production, the process runs around the clock. The AI Agent checks every leave request against shift staffing and minimum staffing rules per shift and qualification. When a breach is detected: automatic escalation with an alternative proposal rather than a blanket rejection.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Age-related leave by agreement</h3>
<p class="text-body text-gosign-text mt-2">Additional leave days from age 50 - agreement-dependent with different thresholds and tiers. The AI Agent calculates age-related leave automatically from date of birth and site agreement. When a birthday falls within the current year: prorated calculation from the relevant effective date.</p>
</div>
</div>
</div>
</section>

<!-- Decision Flow -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">One leave request in chemicals. 10 decision steps.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">A shift worker covered by the chemical industry collective agreement submits a leave request. The Leave Decision Layer decomposes the process into individual decision steps:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Step</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decision</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decision maker</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Rationale</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Classify leave type</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent identifies: annual leave, shift bonus leave, compensation-to-leave conversion, special leave, or compensatory time off</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Identify site agreement and shift model</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent identifies site, collective agreement, and shift model from master data and shift plan</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Calculate total entitlement</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">Base entitlement per agreement + shift bonus (2-5) + age-related leave + conversion days + disability additional leave</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Calculate remaining entitlement</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">Total entitlement minus taken and approved days, including carried-over leave from prior year</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Check minimum staffing per shift</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent checks shift staffing against minimum staffing rules per qualification</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Detect team conflicts</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent checks: colleague blocks, parallel requests, maximum concurrent absence ratio</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Generate approval recommendation</td><td class="py-3 px-4">AI recommends, human decides</td><td class="py-3 px-4">All rules met: recommend approval. Conflict: escalation with context to line manager</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">Check return-to-work threshold</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">Extended sick leave threshold (rolling 12 months). For hazardous substance exposure: additional flag for occupational health support</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Calculate statutory sick pay continuation</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">Statutory sick pay period per illness, waiting periods for new employees where applicable</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Generate audit entry</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">Complete decision record: leave type, entitlement, check steps, result, timestamp</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Simulation -->
<section id="simulation" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulation</p>
<h2 class="text-h1 font-bold text-white">Calculated for chemical industry volumes</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">We configured the Leave Decision Layer with realistic chemical industry parameters and ran the simulation. Industry collective agreement, multiple site agreements, shift models, compensation-to-leave conversion, hazardous substance return-to-work.</p>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Simulation parameters</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Employees</td><td class="py-3 px-4">5,000 to 50,000+ (production, laboratory, administration)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Pay framework</td><td class="py-3 px-4">Chemical industry collective agreement, multiple site-level agreements</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Base leave</td><td class="py-3 px-4">Per collective agreement (20-30 days typical) + shift bonus leave (2-5 days) + age-related leave</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Shift models</td><td class="py-3 px-4">Full continuous shift, partial continuous shift, rotating shift, standard shift</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Compensation conversion</td><td class="py-3 px-4">Collective agreement allowance convertible to free days (individual election)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Return-to-work rate</td><td class="py-3 px-4">Industry sickness absence average for chemicals, including hazardous substance exposure</td></tr>
</tbody>
</table>
</div>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Before / After</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th scope="col" class="text-left py-3 px-4 font-semibold text-white">Dimension</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manual</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Leave request processing time</td><td class="py-3 px-4">1-3 days</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 30 seconds</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Zero-touch rate</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">83%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Return-to-work deadline breaches</td><td class="py-3 px-4">12-18% (manual tracking)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">0% (automatic trigger)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Leave expiry notifications</td><td class="py-3 px-4">Often missed</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatic, timely, individualised</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Shift bonus leave calculation</td><td class="py-3 px-4">Manual, error-prone</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Rule-based, consistent</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Audit readiness</td><td class="py-3 px-4">Manually reconstructed</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatically generated</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">Chemical industry collective agreement. Sickness absence rates: industry averages. Simulation results: Gosign model calculation.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">In our simulation, the Decision Layer achieves a zero-touch rate of 83%. The remaining 17% are genuine exceptions: leave conflicts at minimum staffing, return-to-work processes, compensation conversion changes with tax implications. For the 83%, a complete, audit-ready decision record is available.</p>
</div>
</section>

<!-- Architecture Reference -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Architecture and implementation</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">The Leave Decision Layer runs entirely within your infrastructure. For the chemical industry, this means: integration with shift planning systems, processing of hazardous substance mappings, site-specific leave rule engines, and a complete audit trail. Typical pilot projects launch within 3 months with one site agreement and one employee group.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/en/services/hr-agent/leave-absence-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Leave Decision Layer overview &rarr;</a>
<a href="/en/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Decision Layer architecture &rarr;</a>
<a href="/en/services/infrastructure/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infrastructure in detail &rarr;</a>
<a href="/en/governance/co-determination/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Co-determination &rarr;</a>
<a href="/en/services/hr-agent/payroll-decision-layer/chemicals/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Payroll Decision Layer Chemicals &rarr;</a>
</div>
</div>
</section>


<!-- Weitere Agent-Lösungen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">More Agent Solutions</h2>
<p class="text-body-lg text-gosign-text-light mt-4">HR Agents are part of our agent portfolio. We offer specialized solutions for Finance and other domains.</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8 max-w-content">
<a href="/en/hr-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR & People Operations</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">All HR Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Works-council ready.</p>
</a>
<a href="/en/finance-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Finance & Accounting</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Finance AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Document processing, account assignment, depreciation logic, correction postings.</p>
</a>
<a href="/en/contact/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Custom</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Co-Build for Your Process</h3>
<p class="text-body text-gosign-text-light mt-2">Compliance, operations, shared services - we develop agents in a co-build model.</p>
</a>
</div>
</div>
</section>

<!-- Deep Dive -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Deep Dive in the Agent Briefing (Gosign Magazine)</h2>
<p class="text-body text-gosign-text-light mb-6">Our expert article series for decision-makers deploying AI Agents in the enterprise.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/en/magazine/works-council-ai-co-determination/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Co-Determination</p>
<p class="text-body font-semibold text-gosign-dark">works council and AI - Co-Determination as Architecture Constraint</p>
</a>
<a href="/en/magazine/agent-governance-hr/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Agent Governance for HR - Why Rule Engines Matter More Than Models</p>
</a>
<a href="/en/magazine/decision-layer-explained/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Fundamentals</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - What Is It and Why Does Every Enterprise AI Agent Need One?</p>
</a>
</div>
</div>
</section>

<!-- Other Industries -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Leave Decision Layer in Other Industries</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Every industry has its own collective agreements, its own leave types, and its own complexity drivers. The Decision Layer is the same. The configuration is industry-specific.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/en/services/hr-agent/leave-absence-decision-layer/aviation/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Aviation</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">3 unions, EASA FTL mandatory rest periods, Medical Grounding, Crew-Pairing</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">78% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Details &rarr;</span>
</div>
</a>
<a href="/en/services/hr-agent/leave-absence-decision-layer/financial-services/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Financial Services</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">Mandatory desk leave, regulatory leave blocks, stock exchange holidays, phased retirement</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">85% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Details &rarr;</span>
</div>
</a>
<a href="/en/services/hr-agent/leave-absence-decision-layer/retail/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Retail</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">6-day working week, 64% part-time workforce, seasonal leave blackout periods, marginal employee entitlements</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">87% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Details &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- AI Leave Agent Financial Services - Absence ---
> Leave Decision Layer for banks and insurers. Regulatory mandatory leave, compliance leave blocks, banking holidays. 85% zero-touch.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/en/why-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Every decision traceable</p>
</div>
</a>
<a href="/en/why-gosign/#infrastructure" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Your infrastructure</p>
<p class="text-xs text-gosign-text-light">No SaaS. No vendor lock-in.</p>
</div>
</a>
<a href="/en/why-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">No US cloud risk</p>
</div>
</a>
</div>
</div>
</div>
<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Leave Decision Layer Industries">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/en/services/hr-agent/leave-absence-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Leave Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/en/services/hr-agent/leave-absence-decision-layer/chemicals/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Chemicals</a>
<a href="/en/services/hr-agent/leave-absence-decision-layer/aviation/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Aviation</a>
<a href="/en/services/hr-agent/leave-absence-decision-layer/financial-services/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Financial Services</a>
<a href="/en/services/hr-agent/leave-absence-decision-layer/retail/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Retail</a>
</div>
</div>
</nav>

<!-- Complexity -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">5</span>
<p class="text-small text-gosign-text-light mt-1">Compensation regimes</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">85%</span>
<p class="text-small text-gosign-text-light mt-1">Zero-touch rate</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">Reg.</span>
<p class="text-small text-gosign-text-light mt-1">Compliance leave blocks</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
<span class="w-4 h-2 rounded-sm bg-gosign-border"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">High rule complexity</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">Banking and insurance collective agreements. Regulatory mandatory leave. Zero-touch: Gosign simulation model.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">What the Agent classifies</p>
<h2 class="text-h1 font-bold text-gosign-dark">Five dimensions, one Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Regulatory mandatory leave under the four-eyes principle, compliance-mandated leave blocks, banking holidays, phased retirement, and 5 parallel compensation regimes. You know the complexity. Here is how the AI Agent resolves it:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Regulatory mandatory leave (four-eyes principle)</h3>
<p class="text-body text-gosign-text mt-2">Employees in trading-relevant positions must be mandatorily absent for consecutive blocks at least once per year. The AI Agent identifies positions subject to mandatory leave from the employee master record, checks whether the requested leave meets the minimum block duration, and tracks whether the mandatory leave has already occurred in the current year.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Compliance-mandated leave blocks</h3>
<p class="text-body text-gosign-text mt-2">Financial regulators require consecutive leave blocks for employees in risk-relevant positions. The AI Agent tracks the deadline, warns in good time when the mandatory block is missing, and documents compliance in the audit trail. During regulatory audits: export of the complete compliance status per employee. (UK: FCA requirements apply comparable mandatory desk-leave rules for material risk takers.)</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Banking holidays and trading calendar</h3>
<p class="text-body text-gosign-text mt-2">Banking holidays are not public holidays in every jurisdiction, but they are operationally relevant for trading departments. The AI Agent knows the calendar per location and trading venue and factors banking holidays into staffing planning automatically - no manual calendar reconciliation.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Phased retirement in the block model</h3>
<p class="text-body text-gosign-text mt-2">Phased retirement is widespread in financial services. The AI Agent calculates leave entitlement correctly per phase: full entitlement during the work phase, no entitlement during the leave phase (block model). In the part-time model: prorated entitlement throughout. Social security implications are reported to the payroll system.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Five compensation regimes in parallel</h3>
<p class="text-body text-gosign-text mt-2">Banking collective agreement, insurance collective agreement, non-tariff contracts, senior management, executive board - each regime has its own leave rules and special leave. The AI Agent identifies the regime from the employee master record and applies the correct rule set. One agent for all five regimes.</p>
</div>
</div>
</div>
</section>

<!-- Decision Flow -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">One leave request in financial services. 10 decision steps.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">A trader submits a leave request. The Leave Decision Layer breaks the transaction into individual decision steps:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Step</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decision</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decision maker</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Rationale</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Classify leave type</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent identifies: annual leave, regulatory mandatory leave, phased retirement phase, or special leave</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Identify compensation regime</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent identifies: banking CBA, insurance CBA, non-tariff, senior management, or executive board</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Calculate leave entitlement</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">30 days base (CBA) or individual entitlement (non-tariff/board) + phased retirement adjustment</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Check regulatory mandatory leave</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">Trading-relevant position? Minimum block duration met? Mandatory leave already taken this year?</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Check compliance-mandated leave block</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">Risk-relevant position? Consecutive mandatory block already planned?</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Check banking holidays and staffing</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent checks trading calendar, minimum staffing for trading desk, deputy arrangements</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Generate approval recommendation</td><td class="py-3 px-4">AI recommends, human decides</td><td class="py-3 px-4">All rules and compliance checks passed: recommend approval. Compliance conflict: escalation</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">Check return-to-work threshold</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">42+ sick days in 12 months rolling. Automatic trigger to HR and employee representatives</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Calculate sick pay continuation</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">Statutory sick pay period per case, collective-agreement-specific top-up where applicable</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Generate audit entry</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">Complete decision record: leave type, regime, compliance status, regulatory check, result</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Simulation -->
<section id="simulation" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulation</p>
<h2 class="text-h1 font-bold text-white">Calculated for financial services volumes</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">We configured the Leave Decision Layer with realistic financial services parameters and ran the simulation. Regulatory mandatory leave, compliance-mandated leave blocks, banking holidays, phased retirement.</p>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Simulation parameters</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Employees</td><td class="py-3 px-4">5,000 to 80,000+ (trading, operations, administration)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Collective agreements</td><td class="py-3 px-4">Banking CBA, insurance CBA, non-tariff contracts, senior management</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Regulatory framework</td><td class="py-3 px-4">Regulatory mandatory leave, compliance-mandated leave blocks</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Leave types</td><td class="py-3 px-4">Annual leave, regulatory mandatory leave, phased retirement, educational leave, special leave</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Constraints</td><td class="py-3 px-4">Four-eyes principle, banking holidays, minimum staffing for trading desks</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Return-to-work rate</td><td class="py-3 px-4">Industry average sickness rate for financial services</td></tr>
</tbody>
</table>
</div>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Before / After</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th scope="col" class="text-left py-3 px-4 font-semibold text-white">Dimension</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manual</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Leave request processing time</td><td class="py-3 px-4">1-3 days</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 30 seconds</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Zero-touch rate</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">85%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Compliance leave block missed</td><td class="py-3 px-4">8-15% (manual tracking)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">0% (automatic deadline monitoring)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Regulatory mandatory leave complete</td><td class="py-3 px-4">Manually checked</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatic, audit-proof</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Return-to-work deadline failures</td><td class="py-3 px-4">12-18%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">0% (automatic trigger)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Audit readiness</td><td class="py-3 px-4">Manually reconstructed</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatically generated</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">Regulatory mandatory leave requirements. Banking/insurance collective agreements. Sickness rates: industry averages. Simulation results: Gosign model calculation.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">In our simulation, the Decision Layer achieves a zero-touch rate of 85%. The remaining 15% are compliance-relevant exceptions: regulatory mandatory leave conflicts, phased retirement phase transitions, individual non-tariff agreements. For the 85%, a complete, regulator-audit-proof decision record is available.</p>
</div>
</section>

<!-- Architecture Reference -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Architecture and implementation</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">The Leave Decision Layer runs entirely within your infrastructure. For financial services, this means: integration with trading calendars, compliance-mandated leave tracking, regulatory mandatory leave monitoring, and a complete audit trail. Typical pilot projects start with one compensation regime and expand to all employee groups.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/en/services/hr-agent/leave-absence-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Leave Decision Layer overview &rarr;</a>
<a href="/en/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Decision Layer architecture &rarr;</a>
<a href="/en/services/infrastructure/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infrastructure in detail &rarr;</a>
<a href="/en/governance/co-determination/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Co-determination &rarr;</a>
<a href="/en/services/hr-agent/payroll-decision-layer/financial-services/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Payroll Decision Layer Financial Services &rarr;</a>
</div>
</div>
</section>


<!-- Weitere Agent-Lösungen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">More Agent Solutions</h2>
<p class="text-body-lg text-gosign-text-light mt-4">HR Agents are part of our agent portfolio. We offer specialized solutions for Finance and other domains.</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8 max-w-content">
<a href="/en/hr-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR & People Operations</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">All HR Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Works-council ready.</p>
</a>
<a href="/en/finance-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Finance & Accounting</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Finance AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Document processing, account assignment, depreciation logic, correction postings.</p>
</a>
<a href="/en/contact/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Custom</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Co-Build for Your Process</h3>
<p class="text-body text-gosign-text-light mt-2">Compliance, operations, shared services - we develop agents in a co-build model.</p>
</a>
</div>
</div>
</section>

<!-- Deep Dive -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Deep Dive in the Agent Briefing (Gosign Magazine)</h2>
<p class="text-body text-gosign-text-light mb-6">Our expert article series for decision-makers deploying AI Agents in the enterprise.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/en/magazine/works-council-ai-co-determination/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Co-Determination</p>
<p class="text-body font-semibold text-gosign-dark">Works Council and AI - Co-Determination as Architecture Constraint</p>
</a>
<a href="/en/magazine/agent-governance-hr/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Agent Governance for HR - Why Rule Engines Matter More Than Models</p>
</a>
<a href="/en/magazine/decision-layer-explained/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Fundamentals</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - What Is It and Why Does Every Enterprise AI Agent Need One?</p>
</a>
</div>
</div>
</section>

<!-- Other Industries -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Leave Decision Layer in Other Industries</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Every industry has its own collective agreements, its own leave types, and its own complexity drivers. The Decision Layer is the same. The configuration is industry-specific.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/en/services/hr-agent/leave-absence-decision-layer/chemicals/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Chemicals</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">Site-level agreements, collective-agreement time-off option, shift-supplement leave, hazardous materials return-to-work</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">83% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Details &rarr;</span>
</div>
</a>
<a href="/en/services/hr-agent/leave-absence-decision-layer/aviation/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Aviation</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">Multiple bargaining units, EASA FTL mandatory rest, Medical Grounding, crew pairing</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">78% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Details &rarr;</span>
</div>
</a>
<a href="/en/services/hr-agent/leave-absence-decision-layer/retail/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Retail</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">6-day working week, 64% part-time ratio, seasonal blackout periods, variable-hours contracts</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">87% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Details &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- AI Leave Agent Retail - Absence Management ---
> Leave Decision Layer for retail. 6-day working week, 64% part-time workforce, seasonal blackout periods, multiple regional agreements. 87% zero-touch.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/en/why-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Every decision traceable</p>
</div>
</a>
<a href="/en/why-gosign/#infrastructure" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Your infrastructure</p>
<p class="text-xs text-gosign-text-light">No SaaS. No vendor lock-in.</p>
</div>
</a>
<a href="/en/why-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">No US cloud risk</p>
</div>
</a>
</div>
</div>
</div>
<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Leave Decision Layer Industries">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/en/services/hr-agent/leave-absence-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Leave Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/en/services/hr-agent/leave-absence-decision-layer/chemicals/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Chemicals</a>
<a href="/en/services/hr-agent/leave-absence-decision-layer/aviation/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Aviation</a>
<a href="/en/services/hr-agent/leave-absence-decision-layer/financial-services/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Financial Services</a>
<a href="/en/services/hr-agent/leave-absence-decision-layer/retail/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Retail</a>
</div>
</div>
</nav>

<!-- Complexity -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">Multi</span>
<p class="text-small text-gosign-text-light mt-1">Regional agreements</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">87%</span>
<p class="text-small text-gosign-text-light mt-1">Zero-touch rate</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">64%</span>
<p class="text-small text-gosign-text-light mt-1">Part-time workforce</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
<span class="w-4 h-2 rounded-sm bg-gosign-border"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">High rule complexity</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">Retail collective agreements, multiple regional variations. Zero-touch: Gosign simulation model.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">What the Agent classifies</p>
<h2 class="text-h1 font-bold text-gosign-dark">Five dimensions, one Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">6-day working week with Saturday shifts, 64% part-time workforce, seasonal blackout periods, marginal employees with variable hours, and multiple regional collective agreements. You know the complexity. Here is how the AI Agent resolves it:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">6-day working week and working-day conversion</h3>
<p class="text-body text-gosign-text mt-2">In retail, Saturday is a regular working day. The collective agreement grants 36 working days leave (equivalent to 30 business days for a 5-day week). The AI Agent identifies the working time model from the employee master record and converts the entitlement into business days automatically. When an employee switches between 5-day and 6-day working week: prorated recalculation from the effective date.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Part-time leave calculation for 64% of the workforce</h3>
<p class="text-body text-gosign-text mt-2">More than half of all retail employees work part-time - with different models. The AI Agent calculates the prorated leave entitlement per model: 3-day week, 4-day week, hours-based part-time, flexible part-time. The rule engine applies the correct formula consistently across all store locations.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Seasonal blackout periods</h3>
<p class="text-body text-gosign-text mt-2">Christmas trading (November to December), sales periods, stocktake - retail has clear blackout periods. The AI Agent knows the blackout periods per store (not all stores have the same blackout periods) and checks every request against them. Exceptions require a line manager decision with mandatory justification.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Marginal employee entitlements</h3>
<p class="text-body text-gosign-text mt-2">Marginal employees (UK: zero-hours or part-time workers) on variable hours have the same prorated leave entitlement as full-time employees. The AI Agent calculates the entitlement based on average hours over the last 3 months - even with variable schedules. When hours change: automatic recalculation of the rolling average.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Multiple regional collective agreements</h3>
<p class="text-body text-gosign-text mt-2">Retail operates under multiple regional collective agreements, each with its own leave rules and regional variations. The AI Agent identifies the store location and applies the correct regional agreement. When an employee transfers between stores in different regions: automatic agreement switch with entitlement recalculation.</p>
</div>
</div>
</div>
</section>

<!-- Decision Flow -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">One leave request in retail. 10 decision steps.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">A part-time store employee submits a leave request. The Leave Decision Layer breaks the transaction into individual decision steps:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Step</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decision</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decision maker</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Rationale</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Classify leave type</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent identifies: annual leave, educational leave, special leave, or compensatory time off</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Identify regional collective agreement</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent identifies store location and applies the correct regional agreement</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Calculate leave entitlement</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">Agreement entitlement converted to business days (5-day or 6-day week), part-time factor, marginal employee average</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Check blackout periods</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">Christmas trading, sales periods, stocktake - store-specific blackout periods</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Check store minimum staffing</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent checks staffing plan: often only 2-3 staff per store, every absence counts</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Detect team conflicts</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent checks parallel requests, school holiday distribution (social considerations)</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Generate approval recommendation</td><td class="py-3 px-4">AI recommends, human decides</td><td class="py-3 px-4">All rules met: recommend approval. Blackout period or minimum staffing breach: escalation</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">Check return-to-work threshold</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">Extended sick leave threshold (rolling 12 months). Automatic trigger to HR and employee representatives</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Calculate sick pay continuation</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">Statutory sick pay period per illness, marginal employee special rules where applicable</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Generate audit entry</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">Complete decision record: leave type, agreement, part-time factor, blackout check, result</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Simulation -->
<section id="simulation" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulation</p>
<h2 class="text-h1 font-bold text-white">Calculated for retail volumes</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">We configured the Leave Decision Layer with realistic retail parameters and ran the simulation. Multiple regional agreements, 6-day working week, 64% part-time workforce, seasonal blackout periods.</p>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Simulation parameters</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Employees</td><td class="py-3 px-4">5,000 to 100,000+ (stores, warehouses, administration)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Collective agreements</td><td class="py-3 px-4">Multiple regional retail collective agreements</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Working time models</td><td class="py-3 px-4">5-day week, 6-day week, part-time (3/4 days), marginal employment, variable hours</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Part-time ratio</td><td class="py-3 px-4">64% of total workforce</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Blackout periods</td><td class="py-3 px-4">Christmas trading, sales periods, stocktake (store-specific)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Return-to-work rate</td><td class="py-3 px-4">Industry average sickness rate for retail</td></tr>
</tbody>
</table>
</div>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Before / After</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th scope="col" class="text-left py-3 px-4 font-semibold text-white">Dimension</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manual</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Leave request processing time</td><td class="py-3 px-4">1-3 days</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 30 seconds</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Zero-touch rate</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">87%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Part-time calculation errors</td><td class="py-3 px-4">5-12% (manual conversion)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 0.1% (rule-based)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Leave expiry notifications</td><td class="py-3 px-4">Often missed for part-time staff</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatic, timely, individualised</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Return-to-work deadline failures</td><td class="py-3 px-4">12-18%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">0% (automatic trigger)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Audit readiness</td><td class="py-3 px-4">Manually reconstructed</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatically generated</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">Regional retail collective agreements. Sickness rates: industry averages. Simulation results: Gosign model calculation.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">In our simulation, the Decision Layer achieves a zero-touch rate of 87%. The highest rate among all four industries - because retail is high-volume (many requests) but individual decisions are rule-based. The remaining 13% are genuine exceptions: school holiday conflicts, blackout period exceptions, return-to-work processes. For the 87%, a complete, audit-ready decision record is available.</p>
</div>
</section>

<!-- Architecture Reference -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Architecture and implementation</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">The Leave Decision Layer runs entirely within your infrastructure. For retail, this means: integration with store staffing systems, processing of multiple regional agreements, part-time model recognition, and a complete audit trail. Typical pilot projects start with one region and one store group.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/en/services/hr-agent/leave-absence-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Leave Decision Layer overview &rarr;</a>
<a href="/en/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Decision Layer architecture &rarr;</a>
<a href="/en/services/infrastructure/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infrastructure in detail &rarr;</a>
<a href="/en/governance/co-determination/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Co-determination &rarr;</a>
<a href="/en/services/hr-agent/payroll-decision-layer/retail/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Payroll Decision Layer Retail &rarr;</a>
</div>
</div>
</section>


<!-- Weitere Agent-Lösungen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">More Agent Solutions</h2>
<p class="text-body-lg text-gosign-text-light mt-4">HR Agents are part of our agent portfolio. We offer specialized solutions for Finance and other domains.</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8 max-w-content">
<a href="/en/hr-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR & People Operations</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">All HR Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Works-council ready.</p>
</a>
<a href="/en/finance-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Finance & Accounting</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Finance AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Document processing, account assignment, depreciation logic, correction postings.</p>
</a>
<a href="/en/contact/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Custom</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Co-Build for Your Process</h3>
<p class="text-body text-gosign-text-light mt-2">Compliance, operations, shared services - we develop agents in a co-build model.</p>
</a>
</div>
</div>
</section>

<!-- Deep Dive -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Deep Dive in the Agent Briefing (Gosign Magazine)</h2>
<p class="text-body text-gosign-text-light mb-6">Our expert article series for decision-makers deploying AI Agents in the enterprise.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/en/magazine/works-council-ai-co-determination/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Co-Determination</p>
<p class="text-body font-semibold text-gosign-dark">Works Council and AI - Co-Determination as Architecture Constraint</p>
</a>
<a href="/en/magazine/agent-governance-hr/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Agent Governance for HR - Why Rule Engines Matter More Than Models</p>
</a>
<a href="/en/magazine/decision-layer-explained/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Fundamentals</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - What Is It and Why Does Every Enterprise AI Agent Need One?</p>
</a>
</div>
</div>
</section>

<!-- Other Industries -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Leave Decision Layer in Other Industries</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Every industry has its own collective agreements, its own leave types, and its own complexity drivers. The Decision Layer is the same. The configuration is industry-specific.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/en/services/hr-agent/leave-absence-decision-layer/chemicals/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Chemicals</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">Site-level agreements, collective-agreement time-off option, shift-supplement leave, hazardous materials return-to-work</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">83% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Details &rarr;</span>
</div>
</a>
<a href="/en/services/hr-agent/leave-absence-decision-layer/aviation/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Aviation</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">Multiple bargaining units, EASA FTL mandatory rest, Medical Grounding, crew pairing</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">78% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Details &rarr;</span>
</div>
</a>
<a href="/en/services/hr-agent/leave-absence-decision-layer/financial-services/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Financial Services</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">Regulatory mandatory leave, compliance-mandated leave blocks, banking holidays, phased retirement</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">85% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Details &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- AI Leave & Absence Decision Layer ---
> The Decision Layer breaks every absence transaction into decision steps. Rule-based, auditable, 78-87% zero-touch.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/en/why-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Every decision traceable</p>
</div>
</a>
<a href="/en/why-gosign/#infrastructure" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Your infrastructure</p>
<p class="text-xs text-gosign-text-light">No SaaS. No vendor lock-in.</p>
</div>
</a>
<a href="/en/why-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">No US cloud risk</p>
</div>
</a>
</div>
</div>
</div>
<!-- Problem -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">30+</span>
<p class="text-small text-gosign-text-light mt-1">Leave types (statutory, collective, company)</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">5-15</span>
<p class="text-small text-gosign-text-light mt-1">Micro-decisions per transaction</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">78-87%</span>
<p class="text-small text-gosign-text-light mt-1">Zero-touch rate (simulation)</p>
</div>
<p class="sm:col-span-3 text-xs text-gosign-text-light">Leave types: statutory leave law, sick pay regulations, maternity/parental leave, carer's leave, severe disability additional leave, collective agreements + company governance frameworks.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">The problem</p>
<h2 class="text-h1 font-bold text-gosign-dark">Why absence systems fail in complex organisations</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">SAP SuccessFactors Time Off records absences. Workday Absence calculates balances. Every HRIS can model approval workflows. But in organisations with multiple collective agreements, multi-country operations, part-time models, and return-to-work obligations, recording is not the problem. The decision upstream is: which entitlement applies? Which policy takes precedence? Must a return-to-work process be initiated? (US: No federal mandatory leave law. FMLA provides 12 weeks unpaid. State laws vary significantly.)</p>
<div class="mt-10">
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">30+ leave types</h3>
<p class="text-small text-gosign-text-light mt-2">Annual leave, special leave, educational leave, maternity leave, parental leave, carer's leave, child sick days, severe disability additional leave, collective-agreement time-off options, flexitime days, company shutdowns, sabbaticals. Each type has its own legal basis, its own deadlines, its own calculation rules. No administrator knows all rules across all collective agreement zones and jurisdictions.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">Every sick note triggers 5 follow-up processes</h3>
<p class="text-small text-gosign-text-light mt-2">Process the digital sick note, check sick pay continuation deadlines (typically 6 weeks per case), monitor return-to-work thresholds (42 sick days rolling), notify shift planning, write back to payroll. Manually: media breaks across five systems. Forgotten return-to-work triggers. Incorrect sick pay limits.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">Zero decision transparency</h3>
<p class="text-small text-gosign-text-light mt-2">When employee representatives ask: Why was Employee X's leave rejected? Which rule applied? Who decided? The evidence is missing. Absence systems document outcomes - approved or rejected requests. Not the decisions that led to them.</p>
</div>
</div>
</div>
</div>
</section>

<!-- Decision Layer Principle -->
<section id="decision-layer" class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">The Decision Layer</p>
<h2 class="text-h1 font-bold text-gosign-dark">Every absence transaction. Broken into decision steps.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">The Leave & Absence Decision Layer breaks every absence transaction into individual decision steps. For each step, it defines who decides: the AI Agent classifies leave types, detects conflicts, and monitors thresholds - more reliably and faster than any administrator. The rule engine calculates entitlements, deadlines, and conversions - deterministically and reproducibly. The human stays in the process where employee representation law, employment law, or health data protection demand a human decision.</p>

<div class="mt-10 overflow-x-auto">
<table class="w-full text-left text-body">
<thead>
<tr class="border-b-2 border-gosign-dark">
<th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Step</th>
<th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Decision</th>
<th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Decision maker</th>
<th scope="col" class="py-3 font-bold text-gosign-dark">Rationale</th>
</tr>
</thead>
<tbody class="text-gosign-text-light">
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-medium text-gosign-dark">1</td>
<td class="py-3 pr-4">Classify leave type</td>
<td class="py-3 pr-4 font-medium">AI Agent</td>
<td class="py-3">Agent identifies from request or free text: annual leave, special leave, educational leave, flexitime, child sick day? Assigns correct legal basis</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-medium text-gosign-dark">2</td>
<td class="py-3 pr-4">Calculate entitlement (hierarchy)</td>
<td class="py-3 pr-4 font-medium">Rule engine</td>
<td class="py-3">Statutory leave law + collective agreement + company governance framework + employment contract = total entitlement. Apply most-favourable principle</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-medium text-gosign-dark">3</td>
<td class="py-3 pr-4">Determine remaining entitlement</td>
<td class="py-3 pr-4 font-medium">Rule engine</td>
<td class="py-3">Entitlement - taken - planned = available. On part-time change: prorated recalculation per case law</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-medium text-gosign-dark">4</td>
<td class="py-3 pr-4">Check team conflict and minimum staffing</td>
<td class="py-3 pr-4 font-medium">AI Agent</td>
<td class="py-3">Agent checks team calendar, company shutdowns, minimum staffing. Detects overlaps and calculates available capacity</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-medium text-gosign-dark">5</td>
<td class="py-3 pr-4">Generate approval recommendation</td>
<td class="py-3 pr-4 font-medium">AI Agent + Rule engine</td>
<td class="py-3">All rules met: "Approval recommended" to line manager. Forwarded with context and recommendation</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-medium text-gosign-dark">6</td>
<td class="py-3 pr-4">Escalate leave conflict</td>
<td class="py-3 pr-4 font-medium">Human</td>
<td class="py-3">Two employees, same week, minimum staffing breached. Social considerations (school-age children, single parents) require human judgement - employee representation law demands it</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-medium text-gosign-dark">7</td>
<td class="py-3 pr-4">Calculate sick pay continuation deadline</td>
<td class="py-3 pr-4 font-medium">Rule engine</td>
<td class="py-3">Statutory sick pay period per case. On recurrence: waiting period and prior-employment rules apply</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-medium text-gosign-dark">8</td>
<td class="py-3 pr-4">Check return-to-work threshold</td>
<td class="py-3 pr-4 font-medium">Rule engine</td>
<td class="py-3">42+ sick days in 12 months (rolling). Automatic trigger to HR and employee representatives. Health data separated</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-medium text-gosign-dark">9</td>
<td class="py-3 pr-4">Process digital sick note and write back</td>
<td class="py-3 pr-4 font-medium">Rule engine</td>
<td class="py-3">Digital sick note from insurer: book absence, notify payroll and shift planning, update calendar</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-medium text-gosign-dark">10</td>
<td class="py-3 pr-4">Generate audit entry</td>
<td class="py-3 pr-4 font-medium">Rule engine</td>
<td class="py-3">Decision, rule basis, decision maker, timestamp, input hash - append-only, SHA-256 signed</td>
</tr>
</tbody>
</table>
</div>

<p class="text-body text-gosign-text mt-8 max-w-narrow font-semibold">5 to 15 steps per absence transaction. The AI Agent handles every one of them better and faster than a human administrator. Yet the human stays at defined points in the process - not because they do it better, but because employee representation law, employment law, or health data protection demand it. At 10,000 employees, that means 50,000+ documented micro-decisions per month.</p>

<div class="mt-10">
<div class="grid grid-cols-1 sm:grid-cols-2 gap-6">
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">AI classifies. Rule engine calculates.</h3>
<p class="text-small text-gosign-text-light mt-2">The AI Agent identifies: which leave type? Which legal basis? Is there a team conflict? Has the employee reached the return-to-work threshold? This classification is more reliable than any human administrator. The calculation of entitlements, deadlines, and conversions then runs through versioned Decision Tables - deterministic, reproducible, auditable.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">Return-to-work data architecturally separated</h3>
<p class="text-small text-gosign-text-light mt-2">Health data is a special category (GDPR Article 9). No mixing of leave data and diagnoses. The return-to-work module has a dedicated database, dedicated access circle, dedicated retention periods. The absence agent sees only: return-to-work obligation triggered yes/no. No diagnoses, no sick note reasons.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">AI Agent, rule engine, or human</h3>
<p class="text-small text-gosign-text-light mt-2">The AI Agent classifies facts and detects patterns - more reliably than any administrator. The rule engine calculates entitlements and deadlines. The human stays in the process where employee representation law, employment law, or health data protection demand a human decision.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">Leave forfeiture notification automated</h3>
<p class="text-small text-gosign-text-light mt-2">Case law requires individual, timely warning when leave is about to expire. Without proof of notification, leave never expires. The Decision Layer generates the notifications automatically, documents delivery, and escalates when proof is missing. (UK: UK statutory leave carries over automatically in many circumstances.)</p>
</div>
</div>
</div>
</div>
</section>

<!-- Governance & Audit -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<h2 class="text-h1 font-bold text-gosign-dark">Not documented after the fact. Created in the process.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">When employee representatives ask "Why was the leave request rejected?" - "minimum staffing" is not enough. Which staffing rule? Which period? Who was already approved? The Leave Decision Layer generates a decision act for every micro-decision that answers exactly these questions: input, applied business rule including version, result, timestamp, and contestation path. The same act also makes the explanation of the individual decision under Art. 86 of the EU AI Act satisfiable - for the affected person, employee representation (works councils in Germany), and auditors.</p>

<!-- Audit Trail Card -->
<div class="mt-10 bg-gosign-dark rounded-card p-6 sm:p-8">
<div class="flex items-start gap-4 mb-6">
<svg class="w-8 h-8 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12h6m-6 4h6m2 5H7a2 2 0 01-2-2V5a2 2 0 012-2h5.586a1 1 0 01.707.293l5.414 5.414a1 1 0 01.293.707V19a2 2 0 01-2 2z" />
</svg>
<div>
<h3 class="text-h3 font-bold text-white">Every micro-decision generates an audit entry</h3>
<p class="text-small text-gosign-text-on-dark/70 mt-1">Append-only. Nothing is overwritten, nothing deleted. Corrections create reversal and adjustment entries. SHA-256 signed, exportable at any time.</p>
</div>
</div>
<div class="grid grid-cols-2 sm:grid-cols-3 gap-3 sm:gap-4">
<div class="flex items-center gap-2.5">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span class="text-small text-gosign-text-on-dark/80">Rule ID + version</span>
</div>
<div class="flex items-center gap-2.5">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span class="text-small text-gosign-text-on-dark/80">Legal basis (leave law, sick pay, CBA, company agreement)</span>
</div>
<div class="flex items-center gap-2.5">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span class="text-small text-gosign-text-on-dark/80">Input data (request, period, team)</span>
</div>
<div class="flex items-center gap-2.5">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span class="text-small text-gosign-text-on-dark/80">Result (approval, rejection, escalation)</span>
</div>
<div class="flex items-center gap-2.5">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span class="text-small text-gosign-text-on-dark/80">Decision maker (rule engine / agent / human)</span>
</div>
<div class="flex items-center gap-2.5">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span class="text-small text-gosign-text-on-dark/80">Input hash (reproducible)</span>
</div>
</div>
</div>

<!-- Three Governance Pillars -->
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8">
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-3">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M15 12a3 3 0 11-6 0 3 3 0 016 0z" />
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M2.458 12C3.732 7.943 7.523 5 12 5c4.478 0 8.268 2.943 9.542 7-1.274 4.057-5.064 7-9.542 7-4.477 0-8.268-2.943-9.542-7z" />
</svg>
<div>
<h3 class="text-body font-semibold text-gosign-dark">Employee-representation compliant</h3>
<p class="text-small text-gosign-text-light mt-2">Employee representation bodies hold co-determination rights over leave policies under applicable employment law. Rule engine transparent, rejection reasons documented, anomaly detection controllable via feature flag, reports pseudonymised.</p>
<a href="/en/governance/co-determination/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Co-determination &rarr;</a>
</div>
</div>
</div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-3">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12l2 2 4-4m5.618-4.016A11.955 11.955 0 0112 2.944a11.955 11.955 0 01-8.618 3.04A12.02 12.02 0 003 9c0 5.591 3.824 10.29 9 11.622 5.176-1.332 9-6.03 9-11.622 0-1.042-.133-2.052-.382-3.016z" />
</svg>
<div>
<h3 class="text-body font-semibold text-gosign-dark">GDPR Article 9: health data separated</h3>
<p class="text-small text-gosign-text-light mt-2">Return-to-work module architecturally isolated. Dedicated database, dedicated access circle. No diagnoses in the absence module. Return-to-work files separate from personnel file. Retention periods configurable.</p>
<a href="/en/governance/data-residency/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Data residency &rarr;</a>
</div>
</div>
</div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-3">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 5H7a2 2 0 00-2 2v12a2 2 0 002 2h10a2 2 0 002-2V7a2 2 0 00-2-2h-2M9 5a2 2 0 002 2h2a2 2 0 002-2M9 5a2 2 0 012-2h2a2 2 0 012 2m-6 9l2 2 4-4" />
</svg>
<div>
<h3 class="text-body font-semibold text-gosign-dark">Leave forfeiture notification automated</h3>
<p class="text-small text-gosign-text-light mt-2">Case law establishes that leave does not expire without individual, timely notification. The Decision Layer generates notifications automatically, documents delivery, and escalates when proof is missing.</p>
</div>
</div>
</div>
</div>
</div>
</section>

<!-- Integration -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Integration</p>
<h2 class="text-h1 font-bold text-gosign-dark">Connects to your existing system landscape</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Your systems stay. The manual decision work upstream disappears. The Leave Decision Layer sits between your source systems and your HRIS - it makes the decisions that administrators make today.</p>

<div class="grid grid-cols-1 md:grid-cols-3 gap-6 mt-10">
<!-- Data Sources -->
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<div class="flex items-center gap-3 mb-4">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M20 7l-8-4-8 4m16 0l-8 4m8-4v10l-8 4m0-10L4 7m8 4v10M4 7v10l8 4" />
</svg>
<h3 class="text-body font-semibold text-gosign-dark">Data sources</h3>
</div>
<ul class="space-y-2 text-small text-gosign-text-light">
<li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Employee master data (SAP HCM, Workday)</span></li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Time management (Kronos, ATOSS)</span></li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Digital sick notes (insurer feeds)</span></li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Shift planning (ATOSS, SAP)</span></li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Collective agreement database</span></li>
</ul>
</div>

<!-- Decision Layer -->
<div class="bg-gosign-dark border border-gosign-dark rounded-card p-6">
<div class="flex items-center gap-3 mb-4">
<svg class="w-6 h-6 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9.75 3.104v5.714a2.25 2.25 0 01-.659 1.591L5 14.5M9.75 3.104c-.251.023-.501.05-.75.082m.75-.082a24.301 24.301 0 014.5 0m0 0v5.714c0 .597.237 1.17.659 1.591L19.8 15.3M14.25 3.104c.251.023.501.05.75.082M19.8 15.3l-1.57.393A9.065 9.065 0 0112 15a9.065 9.065 0 00-6.23.693L5 14.5m14.8.8l1.402 1.402c1.232 1.232.65 3.318-1.067 3.611A48.309 48.309 0 0112 21c-2.773 0-5.491-.235-8.135-.687-1.718-.293-2.3-2.379-1.067-3.61L5 14.5" />
</svg>
<h3 class="text-body font-semibold text-white">Leave Decision Layer</h3>
</div>
<ul class="space-y-2 text-small text-gosign-text-on-dark/80">
<li>Leave type classification</li>
<li>Entitlement calculation (CBA + company + law)</li>
<li>Team conflict and staffing checks</li>
<li>Sick pay continuation calculation</li>
<li>Return-to-work threshold monitoring</li>
<li>Leave forfeiture notification</li>
<li>Digital sick note processing + write-back</li>
</ul>
</div>

<!-- Target Systems -->
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<div class="flex items-center gap-3 mb-4">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M5.25 14.25h13.5m-13.5 0a3 3 0 01-3-3m3 3a3 3 0 100 6h13.5a3 3 0 100-6m-16.5-3a3 3 0 013-3h13.5a3 3 0 013 3m-19.5 0a4.5 4.5 0 01.9-2.7L5.737 5.1a3.375 3.375 0 012.7-1.35h7.126c1.062 0 2.062.5 2.7 1.35l2.587 3.45a4.5 4.5 0 01.9 2.7m0 0a3 3 0 01-3 3m0 3h.008v.008h-.008v-.008zm0-6h.008v.008h-.008v-.008zm-3 6h.008v.008h-.008v-.008zm0-6h.008v.008h-.008v-.008z" />
</svg>
<h3 class="text-body font-semibold text-gosign-dark">Target systems</h3>
</div>
<ul class="space-y-2 text-small text-gosign-text-light">
<li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>SAP SuccessFactors Time Off</span></li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Workday Absence Management</span></li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Payroll (ADP, SAP HCM)</span></li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Calendar (Microsoft 365, Google)</span></li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>DMS / Digital personnel file</span></li>
</ul>
</div>
</div>
</div>
</section>

<!-- Industry Simulations -->
<section id="simulations" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulated for enterprise volumes</p>
<h2 class="text-h1 font-bold text-white">Four industries. Calculated.</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">We configured the Leave & Absence Decision Layer for four industries with realistic collective agreements, absence rules, and workforce structures. Each card shows the simulation parameters and the result.</p>

<div class="grid grid-cols-1 md:grid-cols-2 gap-6 mt-10">
<!-- Chemicals -->
<a href="/en/services/hr-agent/leave-absence-decision-layer/chemicals/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors">
<div class="flex items-center justify-between mb-4">
<h3 class="text-h3 font-bold text-white">Chemicals</h3>
<div class="flex gap-1">
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>

</div>
</div>
<ul class="space-y-1.5 text-small text-gosign-text-on-dark/70">
<li>Collective-agreement time-off options</li>
<li>Shift-supplement leave 2-5 days (continuous operations)</li>
<li>Hazardous materials return-to-work obligations</li>
<li>Site-level collective agreements</li>
</ul>
<div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between">
<span class="text-h3 font-bold text-gosign-accent-on-dark">83% Zero-Touch</span>
<span class="text-small text-gosign-accent-on-dark font-semibold">Chemicals in detail &rarr;</span>
</div>
</a>

<!-- Aviation -->
<a href="/en/services/hr-agent/leave-absence-decision-layer/aviation/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors">
<div class="flex items-center justify-between mb-4">
<h3 class="text-h3 font-bold text-white">Aviation</h3>
<div class="flex gap-1">
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>

</div>
</div>
<ul class="space-y-1.5 text-small text-gosign-text-on-dark/70">
<li>Multiple bargaining units (cockpit, cabin, ground)</li>
<li>EASA FTL: mandatory rest periods, duty-period limits</li>
<li>Medical Grounding (loss of fitness certificate)</li>
<li>Crew rotation across bases</li>
</ul>
<div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between">
<span class="text-h3 font-bold text-gosign-accent-on-dark">78% Zero-Touch</span>
<span class="text-small text-gosign-accent-on-dark font-semibold">Aviation in detail &rarr;</span>
</div>
</a>

<!-- Financial Services -->
<a href="/en/services/hr-agent/leave-absence-decision-layer/financial-services/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors">
<div class="flex items-center justify-between mb-4">
<h3 class="text-h3 font-bold text-white">Financial Services</h3>
<div class="flex gap-1">
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>

<span class="w-3 h-1.5 rounded-sm bg-white/20"></span>
</div>
</div>
<ul class="space-y-1.5 text-small text-gosign-text-on-dark/70">
<li>Regulatory mandatory leave (four-eyes principle, fraud detection)</li>
<li>Compliance-mandated leave blocks for traders</li>
<li>Banking holidays in addition to public holidays</li>
<li>Phased retirement models</li>
</ul>
<div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between">
<span class="text-h3 font-bold text-gosign-accent-on-dark">85% Zero-Touch</span>
<span class="text-small text-gosign-accent-on-dark font-semibold">Financial Services in detail &rarr;</span>
</div>
</a>

<!-- Retail -->
<a href="/en/services/hr-agent/leave-absence-decision-layer/retail/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors">
<div class="flex items-center justify-between mb-4">
<h3 class="text-h3 font-bold text-white">Retail</h3>
<div class="flex gap-1">
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>

<span class="w-3 h-1.5 rounded-sm bg-white/20"></span>
</div>
</div>
<ul class="space-y-1.5 text-small text-gosign-text-on-dark/70">
<li>6-day working week: statutory minimum 24 working days</li>
<li>64% part-time ratio, variable-hours contracts with full entitlement</li>
<li>Seasonal blackout periods (Christmas, Easter, peaks)</li>
<li>Regional collective agreements</li>
</ul>
<div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between">
<span class="text-h3 font-bold text-gosign-accent-on-dark">87% Zero-Touch</span>
<span class="text-small text-gosign-accent-on-dark font-semibold">Retail in detail &rarr;</span>
</div>
</a>
</div>
</div>
</section>

<!-- Architecture, Implementation & Levers -->
<section id="implementation" class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Implementation</p>
<h2 class="text-h1 font-bold text-gosign-dark">From pilot to production.</h2>

<div class="grid grid-cols-1 lg:grid-cols-2 gap-10 mt-10">
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Technical architecture</h3>
<p class="text-body text-gosign-text">The Leave & Absence Decision Layer runs entirely within your infrastructure: your data centre, your network, your sovereignty. No SaaS dependency, no data exfiltration, no external telemetry tracking. Health data and return-to-work files never leave your network. Containerised, multi-tenant capable, deployment-ready for your private cloud.</p>
<div class="flex flex-wrap gap-4 mt-3">
<a href="/en/services/infrastructure/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infrastructure in detail &rarr;</a>
<a href="/en/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Decision Layer architecture &rarr;</a>
<a href="/en/magazine/decision-act-contestable-ai-decisions/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">The Decision Act &rarr;</a>
<a href="/en/services/hr-agent/payroll-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Payroll Decision Layer &rarr;</a>
</div>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Implementation</h3>
<p class="text-body text-gosign-text">The Decision Layer is not installed - it is configured: your collective agreements, your company governance frameworks, your absence types. Typical pilot projects launch within 3 months with one site and the most frequent leave types. Extensions to additional sites, collective agreements, and special cases run in parallel with pilot operations.</p>
</div>
</div>

<h3 class="text-h3 font-bold text-gosign-dark mt-12 mb-6">Economic levers</h3>
<div class="grid grid-cols-1 sm:grid-cols-2 gap-6">
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-4">
<svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12l2 2 4-4m5.618-4.016A11.955 11.955 0 0112 2.944a11.955 11.955 0 01-8.618 3.04A12.02 12.02 0 003 9c0 5.591 3.824 10.29 9 11.622 5.176-1.332 9-6.03 9-11.622 0-1.042-.133-2.052-.382-3.016z" />
</svg>
<div>
<p class="text-body font-semibold text-gosign-dark">Eliminate return-to-work deadline failures</p>
<p class="text-small text-gosign-text-light mt-2">Without a properly conducted return-to-work process, a long-term sickness dismissal is almost always unenforceable. The Decision Layer detects the threshold automatically, triggers the process, and documents the invitation. No forgotten obligations.</p>
</div>
</div>
</div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-4">
<svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M13 10V3L4 14h7v7l9-11h-7z" />
</svg>
<div>
<p class="text-body font-semibold text-gosign-dark">Digital sick note processing in real time</p>
<p class="text-small text-gosign-text-light mt-2">The Decision Layer processes digital sick notes automatically: book absence, calculate sick pay continuation deadline, notify payroll, update shift planning. No manual data entry across five systems.</p>
</div>
</div>
</div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-4">
<svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M12 6v6h4.5m4.5 0a9 9 0 11-18 0 9 9 0 0118 0z" />
</svg>
<div>
<p class="text-body font-semibold text-gosign-dark">78-87% zero-touch. Human only where legally required.</p>
<p class="text-small text-gosign-text-light mt-2">Standard leave requests, remaining entitlement calculations, special leave, digital sick note processing, child sick day quotas: all automatable. Human intervention remains for leave conflicts, return-to-work meetings, and educational leave content review.</p>
</div>
</div>
</div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-4">
<svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12h6m-6 4h6m2 5H7a2 2 0 01-2-2V5a2 2 0 012-2h5.586a1 1 0 01.707.293l5.414 5.414a1 1 0 01.293.707V19a2 2 0 01-2 2z" />
</svg>
<div>
<p class="text-body font-semibold text-gosign-dark">Eliminate leave forfeiture risk</p>
<p class="text-small text-gosign-text-light mt-2">Case law establishes that without individual, timely proof of notification, leave never expires. Limitation periods only begin once notification obligations are met. The Decision Layer automates notifications and documents delivery.</p>
</div>
</div>
</div>
</div>
</div>
</section>

<!-- Compliance & Security -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Security</p>
<h2 class="text-h1 font-bold text-gosign-dark">Enterprise security. From day one.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Absence data contains health information, return-to-work files, and sensitive personnel decisions. The Leave Decision Layer is designed for regulated environments where data protection, audit readiness, and traceability are not optional extras.</p>
<div class="mt-10">
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">100% customer infrastructure</h3>
<p class="text-small text-gosign-text-light mt-2">The Decision Layer runs entirely within your network. No SaaS dependency, no data exfiltration, no external telemetry tracking. Health data and return-to-work files never leave your network.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">GDPR Article 9 by design</h3>
<p class="text-small text-gosign-text-light mt-2">Health data architecturally separated. Return-to-work module with dedicated database, dedicated access circle, dedicated retention periods. Compatible with GDPR Article 17 and statutory retention requirements.</p>
<a href="/en/governance/data-residency/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Data residency in detail &rarr;</a>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">AI Act compliant</h3>
<p class="text-small text-gosign-text-light mt-2">Clear architectural separation: the AI Agent classifies leave types and detects conflicts. Entitlement and deadline calculations run deterministically through rule engines. No black box in decisions.</p>
<a href="/en/governance/eu-ai-act/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">EU AI Act readiness &rarr;</a>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">Audit trail (append-only)</h3>
<p class="text-small text-gosign-text-light mt-2">Signed decision records. Input hash plus rule version yields reproducible result. Sealed audit packages (JSON + PDF, SHA-256). Employee representatives can trace every decision.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">ISO 27001 / SOC 2 cert-ready</h3>
<p class="text-small text-gosign-text-light mt-2">Integrated controls registry, automated evidence runs, versioned policies. Compliance during operations, not documented after the fact.</p>
<a href="/en/governance/cert-ready/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready by Design &rarr;</a>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">SSO & tenant isolation</h3>
<p class="text-small text-gosign-text-light mt-2">Integration with existing identity providers. Tenant isolation at database level (Row Level Security). Return-to-work access circle separate from absence module. Legal entities cleanly separated.</p>
</div>
</div>
</div>
</div>
</section>


<!-- Weitere Agent-Lösungen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">More Agent Solutions</h2>
<p class="text-body-lg text-gosign-text-light mt-4">HR Agents are part of our agent portfolio. We offer specialized solutions for Finance and other domains.</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8 max-w-content">
<a href="/en/hr-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR & People Operations</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">All HR Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Works-council ready.</p>
</a>
<a href="/en/finance-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Finance & Accounting</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Finance AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Document processing, account assignment, depreciation logic, correction postings.</p>
</a>
<a href="/en/contact/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Custom</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Co-Build for Your Process</h3>
<p class="text-body text-gosign-text-light mt-2">Compliance, operations, shared services - we develop agents in a co-build model.</p>
</a>
</div>
</div>
</section>

<!-- This Agent in the Catalog -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark">When to Start? Prioritization and Governance Readiness</h2>
<p class="text-body text-gosign-text mt-4">Which quarter should this agent launch? What governance infrastructure must be in place first? Which agents are prerequisites? The HR Agent Catalog places this agent in the Q1-Q4 sequencing and shows readiness scores, governance complexity, and dependencies to other agents.</p>
<a href="/en/hr-agent-catalog/leave-of-absence-agent/" class="inline-flex items-center gap-2 mt-4 text-body font-semibold text-gosign-accent hover:underline">View sequencing and scores &rarr;</a>
</div>
</section>

<!-- Deep Dive -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Deep Dive in the Agent Briefing (Gosign Magazine)</h2>
<p class="text-body text-gosign-text-light mb-6">Our expert article series for decision-makers deploying AI Agents in the enterprise.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/en/magazine/works-council-ai-co-determination/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Co-Determination</p>
<p class="text-body font-semibold text-gosign-dark">Works Council and AI - Co-Determination as Architecture Constraint</p>
</a>
<a href="/en/magazine/decision-layer-explained/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Fundamentals</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - What Is It and Why Does Every Enterprise AI Agent Need One?</p>
</a>
<a href="/en/magazine/eu-ai-act-hr/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">EU AI Act and HR - What People Leaders Need to Know Now</p>
</a>
</div>
</div>
</section>

--- AI Payroll Agent Aviation - Payroll ---
> Payroll Decision Layer for aviation. Multiple unions, 14-18 collective agreements, EASA FTL, per diems. 82% zero-touch rate.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/en/why-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Every decision traceable</p>
</div>
</a>
<a href="/en/why-gosign/#infrastructure" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Your infrastructure</p>
<p class="text-xs text-gosign-text-light">No SaaS. No vendor lock-in.</p>
</div>
</a>
<a href="/en/why-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">No US cloud risk</p>
</div>
</a>
</div>
</div>
</div>

<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Payroll Decision Layer Industries">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/en/services/hr-agent/payroll-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Payroll Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/en/services/hr-agent/payroll-decision-layer/chemicals/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Chemicals</a>
<a href="/en/services/hr-agent/payroll-decision-layer/aviation/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Aviation</a>
<a href="/en/services/hr-agent/payroll-decision-layer/financial-services/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Financial Services</a>
<a href="/en/services/hr-agent/payroll-decision-layer/retail/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Retail</a>
</div>
</div>
</nav>

<!-- Complexity -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">14-18</span>
<p class="text-small text-gosign-text-light mt-1">Parallel collective agreements</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">82%</span>
<p class="text-small text-gosign-text-light mt-1">Zero-touch rate</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">180+</span>
<p class="text-small text-gosign-text-light mt-1">Country per diem rates</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">Highest rule complexity</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">Aviation collective agreements 2024. EASA FTL (EU Reg. 83/2014). National per diem rates. Zero-touch: Gosign simulation model.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">What the Agent classifies</p>
<h2 class="text-h1 font-bold text-gosign-dark">Multiple agreements, one Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Aviation payroll involves multiple collective agreements per jurisdiction - pilot unions for cockpit, cabin crew unions, ground handling unions - plus EASA flight time limits and international per diems. (UK: Post-Brexit, UK CAA retained EASA FTL. BALPA, Unite, and GMB negotiate separately for cockpit, cabin, and ground.) You know the complexity. Here is how the AI Agent resolves it:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Cockpit: seniority bands and pay scales</h3>
<p class="text-body text-gosign-text mt-2">Pilot collective agreements cover multiple seniority bands from Second Officer to Senior Captain, fleet-specific rates, and pension contributions. The AI Agent identifies the current seniority band and fleet assignment from the employee master record and maps to the correct pay scale. On promotion from First Officer to Captain, the new band applies automatically.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Cabin: shift premiums and flying pay</h3>
<p class="text-body text-gosign-text mt-2">Base pay plus shift premiums, purser allowances, and per diems by rotation plan. The AI Agent distinguishes short-haul from long-haul and calculates the correct per diems and duty patterns per rotation. On route changes: automatic recalculation.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Ground: handling agreements and premiums</h3>
<p class="text-body text-gosign-text mt-2">Multiple pay frameworks covering check-in, ramp, baggage, and cargo, each with night, weekend, and bank holiday premiums. The AI Agent classifies pay grade and experience level from the employee master record and job profile - including when staff rotate between check-in, ramp, and baggage handling.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">EASA FTL: flight time limits as payroll boundary</h3>
<p class="text-body text-gosign-text mt-2">EASA Flight Time Limitations define hard limits: maximum 900 flight hours per year, Flight Duty Period maximum 13 hours. The AI Agent checks every payroll cycle against these limits and escalates when thresholds are approached. Exceeding limits risks licence revocation and fines - that is no longer a payroll question, it is a legal one.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Per diems: 180+ country rates</h3>
<p class="text-body text-gosign-text mt-2">A London-Dubai-Singapore rotation: three country rates in a single duty period. The AI Agent calculates meal and incidental expenses per rotation segment based on national tax authority rates per jurisdiction, including meal deductions and minimum stay durations. On IROP-related rotation changes: automatic recalculation. The same logic also powers <a href="/en/services/travel-decision-layer/aviation/" class="text-gosign-accent-text font-semibold hover:text-gosign-accent-hover transition-colors">travel expense processing in the Travel Decision Layer</a>.</p>
</div>
</div>
</div>
</section>

<!-- Decision Flow -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">One aviation payslip. 50 to 120 micro-decisions.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">A long-haul captain. The Payroll Decision Layer breaks down their payslip into individual decision steps:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Step</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decision</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decision maker</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Rationale</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Classify personnel group</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent identifies: cockpit, cabin, ground, or maintenance from master data and position key</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Assign collective agreement</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent maps to: pilot union, cabin union, or ground handling agreement. Additionally: which airline entity (group subsidiaries have separate agreements)</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Calculate base pay</td><td class="py-3 px-4">Collective agreement</td><td class="py-3 px-4">Lookup in versioned pay scale: seniority band, fleet, experience level</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Calculate shift premiums</td><td class="py-3 px-4">Collective agreement</td><td class="py-3 px-4">Cabin: shift and flying pay premiums. Ground: premiums per shift model. Cockpit: integrated in base pay</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Check FTL compliance</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">EASA FTL check: 900h annual cap, FDP max. 13h, cumulative limits. Escalation on approach</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Classify per diem</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent classifies rotation: which countries, what duration, which per diem rates apply</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Calculate per diem</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">Per diem rates per national tax authority, meal deduction, minimum stay. On IROP changes: automatic recalculation</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">Calculate pension contributions</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">Occupational pension, airline pension fund. Deterministic per agreement</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Variance check</td><td class="py-3 px-4">AI flags, human decides</td><td class="py-3 px-4">AI detects variances more reliably. But the assessment stays with a human - Employment law requires transparency in pay governance</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Generate journal entries</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">FI/CO posting, multi-entity (group subsidiaries), cost centre - deterministic</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Simulation -->
<section id="simulation" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulation</p>
<h2 class="text-h1 font-bold text-white">Calculated for aviation volumes</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">We configured the Payroll Decision Layer with realistic aviation parameters and ran the simulation. Multiple collective agreements, EASA FTL, international per diem rates, cockpit seniority across multiple bands.</p>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Simulation parameters</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Crew strength</td><td class="py-3 px-4">10,000 to 50,000+ (cockpit, cabin, ground, maintenance)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Parallel agreements</td><td class="py-3 px-4">2 to 5 (pilot, cabin, ground, plus subsidiary-specific agreements)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Jurisdictions</td><td class="py-3 px-4">Multi-jurisdiction (home base UK, stations EU/worldwide)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">IROP rate</td><td class="py-3 px-4">10-20% (irregularities with payroll impact)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Per diem countries</td><td class="py-3 px-4">180+ country rates per national tax authority</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Cockpit seniority bands</td><td class="py-3 px-4">Multiple bands (Second Officer to Senior Captain), pension contributions</td></tr>
</tbody>
</table>
</div>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Before / After</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th scope="col" class="text-left py-3 px-4 font-semibold text-white">Dimension</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manual</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Error rate</td><td class="py-3 px-4">3-12% (APA, aviation uplift)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 0.3%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Zero-touch rate</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">82%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Per diem calculation</td><td class="py-3 px-4">Manual per rotation, error-prone</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatic, 180+ countries</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">FTL compliance</td><td class="py-3 px-4">Separate check, after the fact</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Integrated, real-time limits</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Agreement renewal (3 unions)</td><td class="py-3 px-4">Weeks per union</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 24h (all in parallel)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Audit readiness</td><td class="py-3 px-4">Manually reconstructed</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatically generated</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">APA: American Payroll Association. Aviation collective agreements 2024. EASA EU Reg. 83/2014. National per diem rates 2024. Simulation results: Gosign model calculation.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">In our simulation, the Decision Layer achieves a zero-touch rate of 82%. The remaining 18% are genuine exceptions: IROP-related rotation changes, union switches during group transfers, FTL threshold cases requiring escalation, cockpit promotions crossing agreement boundaries. For the 82%, a complete, audit-ready decision record is available.</p>
</div>
</section>

<!-- Architecture Reference -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Architecture and implementation</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">The Payroll Decision Layer runs entirely within your infrastructure. For aviation, this means: integration with crew management systems, processing of rotation plans and FTL data, three parallel agreement frameworks, and a complete audit trail through to SAP HCM. Typical pilot projects launch within 3 months with one personnel group and one collective agreement.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/en/services/hr-agent/payroll-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Payroll Decision Layer overview &rarr;</a>
<a href="/en/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Decision Layer architecture &rarr;</a>
<a href="/en/services/infrastructure/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infrastructure in detail &rarr;</a>
<a href="/en/governance/co-determination/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Co-determination &rarr;</a>
<a href="/en/governance/cert-ready/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready by Design &rarr;</a>
<a href="/en/services/travel-decision-layer/aviation/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Travel Decision Layer Aviation &rarr;</a>
</div>
</div>
</section>


<!-- Weitere Agent-Lösungen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">More Agent Solutions</h2>
<p class="text-body-lg text-gosign-text-light mt-4">HR Agents are part of our agent portfolio. We offer specialized solutions for Finance and other domains.</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8 max-w-content">
<a href="/en/hr-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR & People Operations</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">All HR Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Works-council ready.</p>
</a>
<a href="/en/finance-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Finance & Accounting</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Finance AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Document processing, account assignment, depreciation logic, correction postings.</p>
</a>
<a href="/en/contact/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Custom</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Co-Build for Your Process</h3>
<p class="text-body text-gosign-text-light mt-2">Compliance, operations, shared services - we develop agents in a co-build model.</p>
</a>
</div>
</div>
</section>

<!-- Deep Dive -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Deep Dive in the Agent Briefing (Gosign Magazine)</h2>
<p class="text-body text-gosign-text-light mb-6">Our expert article series for decision-makers deploying AI Agents in the enterprise.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/en/magazine/decision-layer-payroll/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Finance</p>
<p class="text-body font-semibold text-gosign-dark">Eliminating Payroll Errors Structurally - Decision Layer for Finance</p>
</a>
<a href="/en/magazine/works-council-ai-co-determination/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Co-Determination</p>
<p class="text-body font-semibold text-gosign-dark">Works Council and AI - Co-Determination as Architecture Constraint</p>
</a>
<a href="/en/magazine/decision-layer-explained/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Fundamentals</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - What Is It and Why Does Every Enterprise AI Agent Need One?</p>
</a>
</div>
</div>
</section>

<!-- Other Industries -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Payroll Decision Layer in Other Industries</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Every industry has its own collective agreements, its own premium rules, and its own complexity drivers. The Decision Layer is the same. The configuration is industry-specific.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/en/services/hr-agent/payroll-decision-layer/chemicals/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Chemicals</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">169 base pay rates, 13 bargaining districts, shift premiums with accumulation, Future Amount</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">88% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Details &rarr;</span>
</div>
</a>
<a href="/en/services/hr-agent/payroll-decision-layer/financial-services/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Financial Services</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">5 compensation regimes, bonus deferral, malus/clawback, regulatory obligations</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">85% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Details &rarr;</span>
</div>
</a>
<a href="/en/services/hr-agent/payroll-decision-layer/retail/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Retail</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">576 base rates (16 regions x 6 grades x 6 steps), 64% part-time, seasonal peaks</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">92% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Details &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- AI Payroll Agent Chemicals - Payroll ---
> Payroll Decision Layer for the chemical industry. Collective agreements, shift premiums, occupational pension. 88% zero-touch rate.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/en/why-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Every decision traceable</p>
</div>
</a>
<a href="/en/why-gosign/#infrastructure" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Your infrastructure</p>
<p class="text-xs text-gosign-text-light">No SaaS. No vendor lock-in.</p>
</div>
</a>
<a href="/en/why-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">No US cloud risk</p>
</div>
</a>
</div>
</div>
</div>

<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Payroll Decision Layer Industries">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/en/services/hr-agent/payroll-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Payroll Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/en/services/hr-agent/payroll-decision-layer/chemicals/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Chemicals</a>
<a href="/en/services/hr-agent/payroll-decision-layer/aviation/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Aviation</a>
<a href="/en/services/hr-agent/payroll-decision-layer/financial-services/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Financial Services</a>
<a href="/en/services/hr-agent/payroll-decision-layer/retail/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Retail</a>
</div>
</div>
</nav>

<!-- Complexity -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">169</span>
<p class="text-small text-gosign-text-light mt-1">Base pay rates</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">88%</span>
<p class="text-small text-gosign-text-light mt-1">Zero-touch rate</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">8%+</span>
<p class="text-small text-gosign-text-light mt-1">Occupational pension contributions</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">Highest rule complexity</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">Chemical industry collective agreements. Zero-touch: Gosign simulation model.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">What the Agent classifies</p>
<h2 class="text-h1 font-bold text-gosign-dark">Five dimensions, one Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Chemical industry pay is negotiated through collective agreements at industry or site level, with shift premiums, accumulation rules, and occupational pension contributions. (UK: The Chemical Industries Association and Unite negotiate UK-wide frameworks. Pension auto-enrolment with salary sacrifice creates additional NIC optimisation.) You know the complexity. Here is how the AI Agent resolves it:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">169 base pay rates</h3>
<p class="text-body text-gosign-text mt-2">Industry and site-level agreements create hundreds of pay grade combinations across chemical operations. The AI Agent identifies the correct combination from employee master data and site records - including when employees transfer between sites. No manual table lookups, no site mismatches.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Shift premiums with accumulation logic</h3>
<p class="text-body text-gosign-text mt-2">Partial continuous shift 6%, full continuous shift 10%, night 15-20%, Sunday 60%, public holiday 150%. The AI Agent applies the accumulation rule: the highest premium takes precedence, while the night premium is always additive. For rotating shift models, the rule engine calculates the correct combination per shift plan automatically.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Occupational pension contributions</h3>
<p class="text-body text-gosign-text mt-2">Occupational pension regulations define employer and employee contribution rates. The AI Agent manages thousands of individual configurations with the correct tax and social security treatment. When employees opt in, opt out, or change elections: automatic adjustment from the following pay period.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Hazardous substance premiums</h3>
<p class="text-body text-gosign-text mt-2">Occupational health and safety risk assessments determine hazardous substance exposure at each workstation. The AI Agent classifies the risk assessment per workstation and assigns the correct premium. When an employee changes workstations: automatic recalculation.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Calendar-based special payments</h3>
<p class="text-body text-gosign-text mt-2">Annual bonus, holiday pay per statutory requirements, employer pension contributions. The AI Agent knows the due date, tax treatment, and social security calculation for every special payment. For mid-year starters or leavers: prorated calculation runs automatically.</p>
</div>
</div>
</div>
</section>

<!-- Decision Flow -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">One chemical payroll. 40 to 80 micro-decisions.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">A shift worker in the chemical industry. The Payroll Decision Layer breaks down their payslip into individual decision steps:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Step</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decision</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decision maker</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Rationale</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Classify site agreement and pay grade</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent identifies site, maps to pay agreement, and validates grading against employee master data</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Calculate base pay</td><td class="py-3 px-4">Pay agreement</td><td class="py-3 px-4">Lookup in versioned pay table: site agreement + grade + step</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Classify shift model</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent identifies: partial continuous (6%), full continuous (10%), or permanent night shift from shift plan</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Calculate and accumulate premiums</td><td class="py-3 px-4">Pay agreement</td><td class="py-3 px-4">Highest premium applies, night always additive. Sunday 60%, public holiday 150%</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Calculate tax-exempt portions</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">Tax-exempt pension contributions, social security exemptions per national rules</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Classify hazardous substance premium</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent classifies workstation based on occupational health and safety risk assessment: chemicals, heat, cold, noise</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Calculate pension contributions</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">Occupational pension minimum + social security treatment varies by election</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">Calculate social security and statutory deductions</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">Employee and employer social security contributions, statutory deductions where applicable</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Variance check against prior month</td><td class="py-3 px-4">AI flags, human decides</td><td class="py-3 px-4">AI detects variances more reliably. But the response (promotion, error, transfer?) stays with a human - labor law transparency requirements demand it</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Generate journal entries</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">FI/CO posting, cost centre, posting period - deterministic</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Simulation -->
<section id="simulation" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulation</p>
<h2 class="text-h1 font-bold text-white">Calculated for chemical industry volumes</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">We configured the Payroll Decision Layer with realistic chemical industry parameters and ran the simulation. Industry collective agreements, site-level agreements, shift models, hazardous substance premiums, occupational pension contributions.</p>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Simulation parameters</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Employees</td><td class="py-3 px-4">5,000 to 50,000+ (production, laboratory, administration)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Pay framework</td><td class="py-3 px-4">Industry collective agreements, site-level agreements, multiple pay grades</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Base pay rates</td><td class="py-3 px-4">169 (site agreements x grades) + automatic step progression</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Shift models</td><td class="py-3 px-4">Partial continuous, full continuous, permanent night shift</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Special payments</td><td class="py-3 px-4">Annual bonus, holiday pay, occupational pension contributions</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Hazardous substance premiums</td><td class="py-3 px-4">5-15% depending on workstation classification</td></tr>
</tbody>
</table>
</div>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Before / After</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th scope="col" class="text-left py-3 px-4 font-semibold text-white">Dimension</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manual</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Error rate</td><td class="py-3 px-4">1-8% (APA)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 0.1%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Zero-touch rate</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">88%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Agreement renewal</td><td class="py-3 px-4">Weeks (multiple sites manually)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 24h (all sites)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Premium calculation</td><td class="py-3 px-4">Manual, error-prone</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Rule-based, consistent</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Audit readiness</td><td class="py-3 px-4">Manually reconstructed</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatically generated</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Pension administration</td><td class="py-3 px-4">Spreadsheets per site</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Centralised, versioned</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">APA: American Payroll Association. Chemical industry collective agreements. Simulation results: Gosign model calculation.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">In our simulation, the Decision Layer achieves a zero-touch rate of 88%. The remaining 12% are genuine exceptions: Hazardous substance reassessments, pension election changes, transfers between sites. For the 88%, a complete, audit-ready decision record is available.</p>
</div>
</section>

<!-- Architecture Reference -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Architecture and implementation</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">The Payroll Decision Layer runs entirely within your infrastructure. For the chemical industry, this means: integration with shift planning systems, processing of occupational health and safety risk mappings, site-specific rule engines, and a complete audit trail through to SAP HCM. Typical pilot projects launch within 3 months with one site agreement and one employee group.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/en/services/hr-agent/payroll-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Payroll Decision Layer overview &rarr;</a>
<a href="/en/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Decision Layer architecture &rarr;</a>
<a href="/en/services/infrastructure/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infrastructure in detail &rarr;</a>
<a href="/en/governance/co-determination/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Co-determination &rarr;</a>
<a href="/en/governance/cert-ready/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready by Design &rarr;</a>
<a href="/en/services/travel-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Travel Decision Layer &rarr;</a>
</div>
</div>
</section>


<!-- Weitere Agent-Lösungen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">More Agent Solutions</h2>
<p class="text-body-lg text-gosign-text-light mt-4">HR Agents are part of our agent portfolio. We offer specialized solutions for Finance and other domains.</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8 max-w-content">
<a href="/en/hr-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR & People Operations</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">All HR Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Works-council ready.</p>
</a>
<a href="/en/finance-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Finance & Accounting</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Finance AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Document processing, account assignment, depreciation logic, correction postings.</p>
</a>
<a href="/en/contact/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Custom</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Co-Build for Your Process</h3>
<p class="text-body text-gosign-text-light mt-2">Compliance, operations, shared services - we develop agents in a co-build model.</p>
</a>
</div>
</div>
</section>

<!-- Deep Dive -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Deep Dive in the Agent Briefing (Gosign Magazine)</h2>
<p class="text-body text-gosign-text-light mb-6">Our expert article series for decision-makers deploying AI Agents in the enterprise.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/en/magazine/decision-layer-payroll/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Finance</p>
<p class="text-body font-semibold text-gosign-dark">Eliminating Payroll Errors Structurally - Decision Layer for Finance</p>
</a>
<a href="/en/magazine/works-council-ai-co-determination/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Co-Determination</p>
<p class="text-body font-semibold text-gosign-dark">Works Council and AI - Co-Determination as Architecture Constraint</p>
</a>
<a href="/en/magazine/decision-layer-explained/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Fundamentals</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - What Is It and Why Does Every Enterprise AI Agent Need One?</p>
</a>
</div>
</div>
</section>

<!-- Other Industries -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Payroll Decision Layer in Other Industries</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Every industry has its own pay agreements, its own premium rules, and its own complexity drivers. The Decision Layer is the same. The configuration is industry-specific.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/en/services/hr-agent/payroll-decision-layer/aviation/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Aviation</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">3 unions, 14-18 pay agreements, EASA FTL, cockpit seniority up to step 23</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">82% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Details &rarr;</span>
</div>
</a>
<a href="/en/services/hr-agent/payroll-decision-layer/financial-services/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Financial Services</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">5 compensation regimes, bonus deferral, malus/clawback, regulatory obligations</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">85% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Details &rarr;</span>
</div>
</a>
<a href="/en/services/hr-agent/payroll-decision-layer/retail/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Retail</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">Site-level rates, 64% part-time, seasonal peaks</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">92% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Details &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- AI Payroll Agent Financial Services ---
> Payroll Decision Layer for banks and financial services. 5 compensation regimes, bonus deferral, malus/clawback. 85% zero-touch rate.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/en/why-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Every decision traceable</p>
</div>
</a>
<a href="/en/why-gosign/#infrastructure" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Your infrastructure</p>
<p class="text-xs text-gosign-text-light">No SaaS. No vendor lock-in.</p>
</div>
</a>
<a href="/en/why-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">No US cloud risk</p>
</div>
</a>
</div>
</div>
</div>
<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Payroll Decision Layer Industries">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/en/services/hr-agent/payroll-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Payroll Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/en/services/hr-agent/payroll-decision-layer/chemicals/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Chemicals</a>
<a href="/en/services/hr-agent/payroll-decision-layer/aviation/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Aviation</a>
<a href="/en/services/hr-agent/payroll-decision-layer/financial-services/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Financial Services</a>
<a href="/en/services/hr-agent/payroll-decision-layer/retail/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Retail</a>
</div>
</div>
</nav>

<!-- Complexity -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">5</span>
<p class="text-small text-gosign-text-light mt-1">Parallel compensation regimes</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">85%</span>
<p class="text-small text-gosign-text-light mt-1">Zero-touch rate</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">4-5 yr</span>
<p class="text-small text-gosign-text-light mt-1">Bonus deferral period</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
<span class="w-4 h-2 rounded-sm bg-gosign-border"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">High rule complexity</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">CRD V / EBA remuneration guidelines, MiFID II. (UK: FCA/PRA Remuneration Code, SMCR.) Zero-touch: Gosign simulation model.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">What the Agent classifies</p>
<h2 class="text-h1 font-bold text-gosign-dark">Five regimes, one Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Five compensation regimes, bonus caps, deferral stretching across years, retroactive malus/clawback, regulatory reporting. You know the complexity. Here is how the AI Agent resolves it:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">5 compensation regimes in parallel</h3>
<p class="text-body text-gosign-text mt-2">Collective agreement, non-tariff, risk taker, trading, sales/advisory - each regime with its own calculation logic. The AI Agent identifies the correct classification from contract data, function, and total compensation. On regime change during a career transition: automatic adjustment of all calculation parameters.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Bonus deferral over 4-5 years</h3>
<p class="text-body text-gosign-text mt-2">40-60% of variable compensation deferred, split into equity and cash components, up to 20 parallel tranches. The AI Agent manages each tranche with its own vesting date and checks the bonus cap (100% of fixed pay, 200% with shareholder resolution) automatically against CRD V / EBA remuneration requirements.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Retroactive malus/clawback</h3>
<p class="text-body text-gosign-text mt-2">Clawback spanning 5-7 years following compliance breaches or risk events. The AI Agent detects relevant events from internal reports and prepares the case. The decision is always made by a human - financial regulators require personal accountability for enforcement.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Regulatory trading obligations</h3>
<p class="text-body text-gosign-text mt-2">10 consecutive mandatory leave days per year, no splitting allowed. The AI Agent automatically checks whether the leave block is observed and escalates to HR in time. No manual calendar checks, no missed compliance deadlines.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Regulatory reporting obligations</h3>
<p class="text-body text-gosign-text mt-2">Annual compensation report covering risk taker compensation, deferral balances, and malus/clawback events. The rule engine generates reporting data automatically from payroll records. Additionally, MiFID II checks: variable components demonstrably linked to client outcome quality. The report is submitted to the financial regulator as part of regulatory reporting requirements.</p>
</div>
</div>
</div>
</section>

<!-- Decision Flow -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">One financial services payslip. 30 to 60 micro-decisions.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">A risk taker at a universal bank. The Payroll Decision Layer breaks down their payslip into individual decision steps:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Step</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decision</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decision maker</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Rationale</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Classify compensation regime</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent identifies: collective (grades 1-9), non-tariff, risk taker, trading, or sales/advisory from contract data</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Check risk taker status</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">EUR 500,000 threshold (or local equivalent), EBA identification against function catalogue</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Calculate fixed salary</td><td class="py-3 px-4">Agreement/contract</td><td class="py-3 px-4">Collective: grade lookup from tariff table. Non-tariff: individual terms from contract data</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Calculate variable compensation</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">Performance assessment, bonus cap 100% of fixed salary (200% with shareholder resolution)</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Calculate deferral split</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">40-60% over 4-5 years, allocation into equity and cash components, vesting dates</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Perform malus review</td><td class="py-3 px-4">AI flags, human decides</td><td class="py-3 px-4">AI detects compliance breaches more reliably. But malus decisions carry personal liability - employee representation bodies and financial regulators require human accountability</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Check regulatory mandatory leave block</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">10 consecutive leave days per year, substitution arrangements, escalation on non-compliance</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">Calculate social security contributions</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">Social security contributions, ceiling checks, occupational pension</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Generate regulatory report data</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">Annual compensation report: risk taker data, deferral balances, clawback events for regulatory submission</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Generate journal entries</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">FI/CO posting, multi-entity booking, deferral provisions - deterministic</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Simulation -->
<section id="simulation" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulation</p>
<h2 class="text-h1 font-bold text-white">Calculated for financial services volumes</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">We configured the Payroll Decision Layer with realistic financial services parameters and ran the simulation. CRD V / EBA remuneration guidelines, MiFID II. (UK: FCA/PRA, SMCR.) Five compensation regimes, deferral periods spanning years.</p>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Simulation parameters</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Employees</td><td class="py-3 px-4">2,000 to 30,000+ (front office, middle office, back office)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Compensation regimes</td><td class="py-3 px-4">5 in parallel: collective (grades 1-9), non-tariff, risk taker, trading, sales/advisory</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Risk taker threshold</td><td class="py-3 px-4">EUR 500,000 total compensation (or local equivalent), EBA identification</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Bonus cap</td><td class="py-3 px-4">100% of fixed salary (200% with shareholder resolution)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Deferral</td><td class="py-3 px-4">40-60% over 4-5 years, equity/cash split</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Malus/clawback</td><td class="py-3 px-4">5-7 year clawback period</td></tr>
</tbody>
</table>
</div>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Before / After</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th scope="col" class="text-left py-3 px-4 font-semibold text-white">Dimension</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manual</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Error rate</td><td class="py-3 px-4">1-8% (APA)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 0.1%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Zero-touch rate</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">85%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Deferral administration</td><td class="py-3 px-4">Spreadsheets, error-prone</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automated, versioned</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Risk taker identification</td><td class="py-3 px-4">Annually, manual</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Continuous, automatic</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Regulatory report</td><td class="py-3 px-4">Weeks (manual preparation)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 24h (auto-generated)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Audit readiness</td><td class="py-3 px-4">Manually reconstructed</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatically generated</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">APA: American Payroll Association. CRD V / EBA remuneration guidelines, MiFID II. Simulation results: Gosign model calculation.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">In our simulation, the Decision Layer achieves a zero-touch rate of 85%. The remaining 15% are genuine exceptions: risk taker borderline cases, malus decisions, regime changes on function transitions. For the 85%, a complete, audit-ready decision record is available.</p>
</div>
</section>

<!-- Architecture Reference -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Architecture and implementation</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">The Payroll Decision Layer runs entirely within your infrastructure. For financial services, this means: integration with core banking systems, processing of risk taker identification, regulatory rule engines for CRD V / EBA remuneration requirements, and a complete audit trail through to SAP HCM. Typical pilot projects launch within 3 months with one compensation regime and one employee group.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/en/services/hr-agent/payroll-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Payroll Decision Layer overview &rarr;</a>
<a href="/en/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Decision Layer architecture &rarr;</a>
<a href="/en/services/infrastructure/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infrastructure in detail &rarr;</a>
<a href="/en/governance/co-determination/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Co-determination &rarr;</a>
<a href="/en/governance/cert-ready/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready by Design &rarr;</a>
<a href="/en/services/travel-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Travel Decision Layer &rarr;</a>
</div>
</div>
</section>


<!-- Weitere Agent-Lösungen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">More Agent Solutions</h2>
<p class="text-body-lg text-gosign-text-light mt-4">HR Agents are part of our agent portfolio. We offer specialized solutions for Finance and other domains.</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8 max-w-content">
<a href="/en/hr-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR & People Operations</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">All HR Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Works-council ready.</p>
</a>
<a href="/en/finance-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Finance & Accounting</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Finance AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Document processing, account assignment, depreciation logic, correction postings.</p>
</a>
<a href="/en/contact/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Custom</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Co-Build for Your Process</h3>
<p class="text-body text-gosign-text-light mt-2">Compliance, operations, shared services - we develop agents in a co-build model.</p>
</a>
</div>
</div>
</section>

<!-- Deep Dive -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Deep Dive in the Agent Briefing (Gosign Magazine)</h2>
<p class="text-body text-gosign-text-light mb-6">Our expert article series for decision-makers deploying AI Agents in the enterprise.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/en/magazine/decision-layer-payroll/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Finance</p>
<p class="text-body font-semibold text-gosign-dark">Eliminating Payroll Errors Structurally - Decision Layer for Finance</p>
</a>
<a href="/en/magazine/works-council-ai-co-determination/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Co-Determination</p>
<p class="text-body font-semibold text-gosign-dark">Works Council and AI - Co-Determination as Architecture Constraint</p>
</a>
<a href="/en/magazine/decision-layer-explained/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Fundamentals</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - What Is It and Why Does Every Enterprise AI Agent Need One?</p>
</a>
</div>
</div>
</section>

<!-- Other Industries -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Payroll Decision Layer in Other Industries</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Every industry has its own collective agreements, its own premium rules, and its own complexity drivers. The Decision Layer is the same. The configuration is industry-specific.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/en/services/hr-agent/payroll-decision-layer/chemicals/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Chemicals</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">169 base pay rates (13 districts x 13 grades), shift premiums, Future Amount</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">88% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Details &rarr;</span>
</div>
</a>
<a href="/en/services/hr-agent/payroll-decision-layer/aviation/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Aviation</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">3 unions, 14-18 collective agreements, EASA FTL, cockpit seniority up to step 23</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">82% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Details &rarr;</span>
</div>
</a>
<a href="/en/services/hr-agent/payroll-decision-layer/retail/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Retail</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">576 base rates (16 regions x 6 grades x 6 steps), 64% part-time, seasonal peaks</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">92% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Details &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- AI Payroll Agent Retail - Payroll ---
> Payroll Decision Layer for retail. Collective agreement rates, minimum wage compliance, variable-hours contracts, seasonal workers. 92% zero-touch.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/en/why-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Every decision traceable</p>
</div>
</a>
<a href="/en/why-gosign/#infrastructure" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Your infrastructure</p>
<p class="text-xs text-gosign-text-light">No SaaS. No vendor lock-in.</p>
</div>
</a>
<a href="/en/why-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">No US cloud risk</p>
</div>
</a>
</div>
</div>
</div>
<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Payroll Decision Layer Industries">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/en/services/hr-agent/payroll-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Payroll Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/en/services/hr-agent/payroll-decision-layer/chemicals/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Chemicals</a>
<a href="/en/services/hr-agent/payroll-decision-layer/aviation/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Aviation</a>
<a href="/en/services/hr-agent/payroll-decision-layer/financial-services/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Financial Services</a>
<a href="/en/services/hr-agent/payroll-decision-layer/retail/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Retail</a>
</div>
</div>
</nav>

<!-- Complexity -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">576</span>
<p class="text-small text-gosign-text-light mt-1">Base pay rates</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">92%</span>
<p class="text-small text-gosign-text-light mt-1">Zero-touch rate</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">64%</span>
<p class="text-small text-gosign-text-light mt-1">Part-time rate</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
<span class="w-4 h-2 rounded-sm bg-gosign-border"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">High rule complexity</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">Retail collective agreements + statutory minimum wage bands 2024-2026. (UK: USDAW + NLW age bands.) Zero-touch: Gosign simulation model.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">What the Agent classifies</p>
<h2 class="text-h1 font-bold text-gosign-dark">Collective agreements + minimum wage, one Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Retail payroll spans collective agreement rates, statutory minimum wage bands, a 64% part-time workforce, seasonal employment regulations, and 25.7% annual turnover. (UK: USDAW agreements, NLW age bands, zero-hours contracts, Seasonal Worker Visa.) You know the complexity. Here is how the AI Agent resolves it:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">576 base pay rates (collective agreements + minimum wage bands)</h3>
<p class="text-body text-gosign-text mt-2">Retail collective agreements negotiate pay scales across store locations and job roles. The AI Agent identifies the correct combination from store location, job role, tenure, and employee age band. When the minimum wage rate changes annually: automatic adjustment of all affected pay structures within 24 hours. Age band transitions are detected and reclassified on the employee's birthday.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">64% part-time (variable-hours contracts, contribution thresholds)</h3>
<p class="text-body text-gosign-text mt-2">Variable-hours contracts create variable earnings and social security contribution calculations each pay period. The AI Agent checks cumulative weekly earnings against social security contribution thresholds on every payroll run. When employees cross thresholds mid-period: automatic recalculation of employer and employee social security contributions.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">100,000 seasonal workers (regulated employment)</h3>
<p class="text-body text-gosign-text mt-2">Seasonal employment regulations define maximum contract durations per jurisdiction. The AI Agent maintains an exact day counter per seasonal worker per contract period - across all stores. On approaching the contract limit: automatic escalation. Right-to-work status and contract expiry tracking are integrated into every payroll run.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Premium accumulation (highest applies, night additive)</h3>
<p class="text-body text-gosign-text mt-2">Late shift 20-40%, Sunday 120%, public holiday 200%, night 55%. The AI Agent applies the accumulation rule: the highest premium takes precedence, while the night premium is always additive. Sunday evening with night work: 120% plus 55%, not 200%. No manual recalculation per shift.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">25.7% turnover (constant onboarding/offboarding)</h3>
<p class="text-body text-gosign-text mt-2">Over 2,500 joiners and leavers per year for every 10,000 employees. The AI Agent calculates prorated pay, remaining leave payout, and payroll tax deregistrations automatically - every case individually, without manual prorating.</p>
</div>
</div>
</div>
</section>

<!-- Decision Flow -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">One retail payslip. 30 to 60 micro-decisions.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">A part-time retail worker with late and Sunday shifts. The Payroll Decision Layer breaks down their payslip into individual decision steps:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Step</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decision</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decision maker</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Rationale</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Classify store and agreement area</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Store location maps to correct collective agreement pay scale and minimum wage band</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Assign pay grade and step</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Job role maps to pay grade, tenure maps to experience step, age to minimum wage band</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Calculate base pay</td><td class="py-3 px-4">Collective agreement</td><td class="py-3 px-4">Lookup in pay scale table: grade + step = gross salary, cross-checked against minimum wage floor</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Part-time proration</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">Prorated calculation based on contractual hours, hourly rate derivation for premiums</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Check variable-hours contract and contribution status</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Cumulative weekly earnings checked against social security contribution thresholds</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Classify and accumulate premiums</td><td class="py-3 px-4">AI Agent + agreement</td><td class="py-3 px-4">Late 20-40%, night 55%, Sunday 120%, holiday 200% - highest premium applies, night additive</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Calculate social security contributions</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">Employee and employer social security contributions, variable-hours earnings calculation</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">Check seasonal worker contract status</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Contract duration tracking, right-to-work verification, payroll tax obligations</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Variance check</td><td class="py-3 px-4">AI flags, human decides</td><td class="py-3 px-4">AI detects variances more reliably. But the assessment (status change, error, store transfer?) stays with a human - employment law requires it</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Generate journal entries</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">FI/CO posting, multi-store, cost centre allocation - deterministic</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Simulation -->
<section id="simulation" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulation</p>
<h2 class="text-h1 font-bold text-white">Calculated for retail volumes</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">We configured the Payroll Decision Layer with realistic retail parameters and ran the simulation. Collective agreement rates, minimum wage bands, variable-hours contracts, seasonal workers, premium accumulation, high turnover.</p>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Simulation parameters</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Employees</td><td class="py-3 px-4">5,000 to 50,000+ (sales floor, checkout, warehouse, administration)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Agreement</td><td class="py-3 px-4">Retail collective agreements + statutory minimum wage bands</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Base pay rates</td><td class="py-3 px-4">576 (agreement grades x steps x minimum wage bands)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Part-time rate</td><td class="py-3 px-4">64% (variable-hours, part-time, regular part-time)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Seasonal workers</td><td class="py-3 px-4">Approx. 100,000 (Seasonal contracts, duration limits, payroll tax liable)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Premiums</td><td class="py-3 px-4">Late 20-40%, night 55%, Sunday 120%, public holiday 200%</td></tr>
</tbody>
</table>
</div>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Before / After</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th scope="col" class="text-left py-3 px-4 font-semibold text-white">Dimension</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manual</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Error rate</td><td class="py-3 px-4">1-8% (APA)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 0.1%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Zero-touch rate</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">92%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Minimum wage rate update</td><td class="py-3 px-4">Weeks (manual age band checks)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 24h (all age bands)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Variable-hours contribution detection</td><td class="py-3 px-4">Manual, delayed</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Real-time, per payroll run</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Seasonal worker tracking</td><td class="py-3 px-4">Spreadsheets, incomplete across stores</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatic, all stores</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Audit readiness</td><td class="py-3 px-4">Manually reconstructed</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatically generated</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">APA: American Payroll Association. Retail collective agreements + statutory minimum wage bands 2024-2026. Simulation results: Gosign model calculation.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">In our simulation, the Decision Layer achieves a zero-touch rate of 92%. The remaining 8% are genuine exceptions: seasonal worker threshold cases, status changes between variable-hours and part-time contracts, cross-store transfers. For the 92%, a complete, audit-ready decision record is available.</p>
</div>
</section>

<!-- Architecture Reference -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Architecture and implementation</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">The Payroll Decision Layer runs entirely within your infrastructure. For retail, this means: integration with store-level time tracking, processing of variable-hours contract contribution changes, collective agreement pay scale tables, seasonal worker tracking across all locations, and a complete audit trail through to SAP HCM. Typical pilot projects launch within 3 months with one region and one store cluster.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/en/services/hr-agent/payroll-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Payroll Decision Layer overview &rarr;</a>
<a href="/en/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Decision Layer architecture &rarr;</a>
<a href="/en/services/infrastructure/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infrastructure in detail &rarr;</a>
<a href="/en/governance/co-determination/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Co-determination &rarr;</a>
<a href="/en/governance/cert-ready/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready by Design &rarr;</a>
<a href="/en/services/travel-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Travel Decision Layer &rarr;</a>
</div>
</div>
</section>


<!-- Weitere Agent-Lösungen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">More Agent Solutions</h2>
<p class="text-body-lg text-gosign-text-light mt-4">HR Agents are part of our agent portfolio. We offer specialized solutions for Finance and other domains.</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8 max-w-content">
<a href="/en/hr-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR & People Operations</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">All HR Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Works-council ready.</p>
</a>
<a href="/en/finance-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Finance & Accounting</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Finance AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Document processing, account assignment, depreciation logic, correction postings.</p>
</a>
<a href="/en/contact/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Custom</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Co-Build for Your Process</h3>
<p class="text-body text-gosign-text-light mt-2">Compliance, operations, shared services - we develop agents in a co-build model.</p>
</a>
</div>
</div>
</section>

<!-- Deep Dive -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Deep Dive in the Agent Briefing (Gosign Magazine)</h2>
<p class="text-body text-gosign-text-light mb-6">Our expert article series for decision-makers deploying AI Agents in the enterprise.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/en/magazine/decision-layer-payroll/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Finance</p>
<p class="text-body font-semibold text-gosign-dark">Eliminating Payroll Errors Structurally - Decision Layer for Finance</p>
</a>
<a href="/en/magazine/works-council-ai-co-determination/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Co-Determination</p>
<p class="text-body font-semibold text-gosign-dark">Works Council and AI - Co-Determination as Architecture Constraint</p>
</a>
<a href="/en/magazine/decision-layer-explained/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Fundamentals</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - What Is It and Why Does Every Enterprise AI Agent Need One?</p>
</a>
</div>
</div>
</section>

<!-- Other Industries -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Payroll Decision Layer in Other Industries</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Every industry has its own collective agreements, its own premium rules, and its own complexity drivers. The Decision Layer is the same. The configuration is industry-specific.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/en/services/hr-agent/payroll-decision-layer/chemicals/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Chemicals</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">169 base pay rates, 13 bargaining districts, shift premiums with accumulation, Future Amount</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">88% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Details &rarr;</span>
</div>
</a>
<a href="/en/services/hr-agent/payroll-decision-layer/aviation/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Aviation</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">3 unions, 14-18 collective agreements, EASA FTL, cockpit seniority up to step 23</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">82% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Details &rarr;</span>
</div>
</a>
<a href="/en/services/hr-agent/payroll-decision-layer/financial-services/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Financial Services</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">5 compensation regimes, bonus deferral, malus/clawback, regulatory obligations</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">85% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Details &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- AI Payroll Decision Layer ---
> The Decision Layer decomposes every payroll run into decision steps. Rule-based, auditable, 82-92% zero-touch.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/en/why-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Every decision traceable</p>
</div>
</a>
<a href="/en/why-gosign/#infrastructure" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Your infrastructure</p>
<p class="text-xs text-gosign-text-light">No SaaS. No vendor lock-in.</p>
</div>
</a>
<a href="/en/why-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">No US cloud risk</p>
</div>
</a>
</div>
</div>
</div>

<!-- Problem -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div><span class="text-h1 font-bold text-gosign-accent-text">1-8%</span><p class="text-small text-gosign-text-light mt-1">payroll error rate</p></div>
<div><span class="text-h1 font-bold text-gosign-accent-text">EUR 260</span><p class="text-small text-gosign-text-light mt-1">total cost per error incident</p></div>
<div><span class="text-h1 font-bold text-gosign-accent-text">10</span><p class="text-small text-gosign-text-light mt-1">decision steps per payroll run</p></div>
<p class="sm:col-span-3 text-xs text-gosign-text-light">American Payroll Association (APA); EY / HR Dive, "The True Cost of Payroll" (USD 281 per incident, converted at average exchange rate)</p>
</div>
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">The Problem</p>
<h2 class="text-h1 font-bold text-gosign-dark">Why payroll systems fail in complex organisations</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">SAP HCM calculates correctly. Every payroll engine calculates correctly - when the inputs are right. But in organisations with multiple collective agreements, shift models, regional variations and dozens of supplement rules, calculation is not the problem. The decision upstream is: which table applies? Which supplement rate? Is accumulation permitted?</p>
<div class="mt-10 grid grid-cols-1 sm:grid-cols-3 gap-6">
<div class="bg-gosign-light border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">1-8% error rate</h3><p class="text-small text-gosign-text-light mt-2">Multiple pay grades, multiple collective agreement regions, tax classes, social insurance branches, contribution ceilings, salary conversion, garnishments, supplements with accumulation rules. No payroll clerk knows all rules across all regions. 1-8% of payroll runs contain errors (APA) - the more complex the collective agreement landscape, the higher the rate.</p></div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">EUR 260 per error</h3><p class="text-small text-gosign-text-light mt-2">A single payroll error triggers four follow-up processes: reversal of the original run, recalculation, social insurance correction filing, corrected payroll tax return. In total, an error incident costs on average EUR 260 (EY; original study: USD 281). At 2,000 employees and 1-8% error rate, that is 20-160 incidents per month.</p></div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">Zero rule transparency</h3><p class="text-small text-gosign-text-light mt-2">When the payroll auditor asks: Why was a 25% night supplement applied instead of 20%? Which collective agreement was in effect at that time? Was the pay grade correct? The evidence is missing. Payroll systems document results. Not the decisions that led to them.</p></div>
</div>
</div>
</section>

<!-- Decision Layer Principle -->
<section id="decision-layer" class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">The Decision Layer</p>
<h2 class="text-h1 font-bold text-gosign-dark">Every payroll run. Decomposed into decision steps.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">The Payroll Decision Layer decomposes every payroll run into individual decision steps. For each step, it defines who decides: the AI Agent classifies cases and detects anomalies - more reliably and faster than any payroll administrator. The rule engine calculates amounts - deterministically and reproducibly. The human stays in the process where employee representation law, labour regulation or discrimination risk requires a human decision.</p>
<div class="mt-10 overflow-x-auto">
<table class="w-full text-left text-body">
<thead><tr class="border-b-2 border-gosign-dark"><th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Step</th><th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Decision</th><th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Actor</th><th scope="col" class="py-3 font-bold text-gosign-dark">Rationale</th></tr></thead>
<tbody class="text-gosign-text-light">
<tr class="border-b border-gosign-border"><td class="py-3 pr-4 font-medium text-gosign-dark">1</td><td class="py-3 pr-4">Validate tax class, allowances, social insurance attributes</td><td class="py-3 pr-4 font-medium">Rule engine</td><td class="py-3">Cross-reference against tax authority data (e.g. ELStAM in Germany), deterministic</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4 font-medium text-gosign-dark">2</td><td class="py-3 pr-4">Verify collective agreement classification</td><td class="py-3 pr-4 font-medium">AI Agent</td><td class="py-3">Agent classifies: which collective agreement, which pay grade, which level? Cross-references against master data and detects inconsistencies</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4 font-medium text-gosign-dark">3</td><td class="py-3 pr-4">Calculate base remuneration</td><td class="py-3 pr-4 font-medium">Collective agreement</td><td class="py-3">Lookup in versioned rate table: region + grade + level</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4 font-medium text-gosign-dark">4</td><td class="py-3 pr-4">Calculate supplements (night/Sunday/public holiday)</td><td class="py-3 pr-4 font-medium">AI Agent + collective agreement</td><td class="py-3">Agent classifies supplement type from shift data. Collective agreement defines rates + accumulation rule (highest applies, night always additive)</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4 font-medium text-gosign-dark">5</td><td class="py-3 pr-4">Identify tax-exempt portions</td><td class="py-3 pr-4 font-medium">Rule engine</td><td class="py-3">Tax-exempt thresholds for shift supplements per jurisdiction (in Germany: EStG; (UK: HMRC shift premium guidance))</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4 font-medium text-gosign-dark">6</td><td class="py-3 pr-4">Calculate salary conversion / occupational pension</td><td class="py-3 pr-4 font-medium">Rule engine</td><td class="py-3">Employee contribution + employer top-up, tax/social insurance thresholds verified</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4 font-medium text-gosign-dark">7</td><td class="py-3 pr-4">Calculate social insurance contributions</td><td class="py-3 pr-4 font-medium">Rule engine</td><td class="py-3">Health, pension, unemployment, care insurance with contribution ceiling checks, sliding zone for marginal employment</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4 font-medium text-gosign-dark">8</td><td class="py-3 pr-4">Apply garnishments</td><td class="py-3 pr-4 font-medium">Rule engine + human</td><td class="py-3">Garnishment table deterministic; for priority conflicts: Human-in-the-Loop</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4 font-medium text-gosign-dark">9</td><td class="py-3 pr-4">Variance check against prior period</td><td class="py-3 pr-4 font-medium">AI detects, human decides</td><td class="py-3">The AI detects variances more reliably than any payroll clerk. But the decision about what to do with a variance must remain with the human: was it a promotion, a data error or a genuine payroll error? Without this separation, compliance monitoring becomes performance surveillance - and in Germany, that triggers works council co-determination rights (BetrVG). Across the EU, employee representation bodies have comparable oversight requirements.</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4 font-medium text-gosign-dark">10</td><td class="py-3 pr-4">Generate posting entries</td><td class="py-3 pr-4 font-medium">Rule engine</td><td class="py-3">GL account assignment, cost centre, posting period - deterministic</td></tr>
</tbody>
</table>
</div>
<p class="text-body text-gosign-text mt-8 max-w-narrow font-semibold">10 steps per payroll run. The AI Agent can handle every one of them better and faster than a payroll clerk. Yet the human stays at defined points in the process - not because they do it better, but because employee representation law, labour regulation or discrimination risk requires it. At 10,000 employees, that is 100,000 documented micro-decisions per month.</p>
<div class="mt-10 grid grid-cols-1 sm:grid-cols-2 gap-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">AI classifies. Rule engine calculates.</h3><p class="text-small text-gosign-text-light mt-2">The AI Agent determines: which collective agreement applies? Which supplement type? Is the classification correct? It does this more reliably than any payroll clerk. The amount calculation then runs through versioned decision tables - deterministic, reproducible, auditable.</p></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">40 to 80 micro-decisions per payroll run</h3><p class="text-small text-gosign-text-light mt-2">The 10 main steps decompose into dozens of sub-steps: every supplement has its own accumulation rules, every social insurance branch its own contribution ceiling check, every garnishment its own priority ranking. Each individually documented.</p></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">AI Agent, rule engine or human</h3><p class="text-small text-gosign-text-light mt-2">The AI Agent classifies cases and makes decisions - more reliably than any payroll administrator. The rule engine calculates the amount. The human stays in the process where employee representation law, labour regulation or discrimination risk requires a human decision - not because they do it better, but because they must.</p></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">Human in the loop: not expertise, but accountability</h3><p class="text-small text-gosign-text-light mt-2">Traditional payroll requires manual review everywhere. AI Agents can do it better. But for garnishment priority conflicts, variance assessments and classification decisions, legislation or employee representation bodies require a human decision. The Decision Layer knows where - and escalates only there.</p></div>
</div>
</div>
</section>

<!-- Governance & Audit -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<h2 class="text-h1 font-bold text-gosign-dark">Not documented after the fact. Created within the process.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">When the payroll auditor asks "Why was a 25% night supplement applied?" - "it is in the collective agreement" is not sufficient. Which collective agreement? Which version? Did the accumulation rule apply? The Payroll Decision Layer generates a decision act for every micro-decision that answers exactly these questions: input, applied business rule including version, confidence, result, timestamp, and contestation path. The same act also makes the explanation of the individual decision under Art. 86 of the EU AI Act satisfiable.</p>
<div class="mt-10 bg-gosign-dark rounded-card p-6 sm:p-8">
<div class="flex items-start gap-4 mb-6"><svg class="w-8 h-8 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12h6m-6 4h6m2 5H7a2 2 0 01-2-2V5a2 2 0 012-2h5.586a1 1 0 01.707.293l5.414 5.414a1 1 0 01.293.707V19a2 2 0 01-2 2z" /></svg><div><h3 class="text-h3 font-bold text-white">Every micro-decision generates an audit entry</h3><p class="text-small text-gosign-text-on-dark/70 mt-1">Append-only. Nothing is overwritten, nothing deleted. Corrections create reversal and adjustment entries. SHA-256 signed, exportable at any time.</p></div></div>
<div class="grid grid-cols-2 sm:grid-cols-3 gap-3 sm:gap-4">
<div class="flex items-center gap-2.5"><svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg><span class="text-small text-gosign-text-on-dark/80">Rule ID + version</span></div>
<div class="flex items-center gap-2.5"><svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg><span class="text-small text-gosign-text-on-dark/80">Collective agreement + validity period</span></div>
<div class="flex items-center gap-2.5"><svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg><span class="text-small text-gosign-text-on-dark/80">Input data (hours, supplement type)</span></div>
<div class="flex items-center gap-2.5"><svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg><span class="text-small text-gosign-text-on-dark/80">Result (amount, tax treatment)</span></div>
<div class="flex items-center gap-2.5"><svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg><span class="text-small text-gosign-text-on-dark/80">Actor (rule engine / collective agreement / human)</span></div>
<div class="flex items-center gap-2.5"><svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg><span class="text-small text-gosign-text-on-dark/80">Input hash (reproducible)</span></div>
</div>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8">
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6"><div class="flex items-start gap-3"><svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M15 12a3 3 0 11-6 0 3 3 0 016 0z" /><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M2.458 12C3.732 7.943 7.523 5 12 5c4.478 0 8.268 2.943 9.542 7-1.274 4.057-5.064 7-9.542 7-4.477 0-8.268-2.943-9.542-7z" /></svg><div><h3 class="text-body font-semibold text-gosign-dark">Employee-representation compliant</h3><p class="text-small text-gosign-text-light mt-2">In Germany, works councils have binding co-determination rights over remuneration principles. The Payroll Decision Layer makes the rule set inspectable, decisions traceable, anomaly scoring controllable via feature flag and reports pseudonymised. Built for the strictest standard - meets or exceeds requirements in any jurisdiction.</p><a href="/en/governance/co-determination/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Co-determination &rarr;</a></div></div></div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6"><div class="flex items-start gap-3"><svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12l2 2 4-4m5.618-4.016A11.955 11.955 0 0112 2.944a11.955 11.955 0 01-8.618 3.04A12.02 12.02 0 003 9c0 5.591 3.824 10.29 9 11.622 5.176-1.332 9-6.03 9-11.622 0-1.042-.133-2.052-.382-3.016z" /></svg><div><h3 class="text-body font-semibold text-gosign-dark">Payroll-audit ready</h3><p class="text-small text-gosign-text-light mt-2">Retention periods supported (10 years in Germany, varies by jurisdiction). Anonymisation instead of deletion for GDPR compatibility. Every payroll run reproducible via input hash.</p><a href="/en/governance/cert-ready/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready &rarr;</a></div></div></div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6"><div class="flex items-start gap-3"><svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 5H7a2 2 0 00-2 2v12a2 2 0 002 2h10a2 2 0 002-2V7a2 2 0 00-2-2h-2M9 5a2 2 0 002 2h2a2 2 0 002-2M9 5a2 2 0 012-2h2a2 2 0 012 2m-6 9l2 2 4-4" /></svg><div><h3 class="text-body font-semibold text-gosign-dark">Systematic compliance</h3><p class="text-small text-gosign-text-light mt-2">Every payroll run is checked against the complete rule set - not sampled, but systematically. Deviations are detected and documented in real time, not discovered during the next external payroll tax audit.</p></div></div></div>
</div>
</div>
</section>

<!-- Integration -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Integration</p>
<h2 class="text-h1 font-bold text-gosign-dark">Connects to your existing system landscape</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Your systems stay. The manual decision work upstream disappears. The Payroll Decision Layer sits between your source systems and your payroll engine - it makes the decisions that payroll clerks make today.</p>
<div class="grid grid-cols-1 md:grid-cols-3 gap-6 mt-10">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><div class="flex items-center gap-3 mb-4"><svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M20 7l-8-4-8 4m16 0l-8 4m8-4v10l-8 4m0-10L4 7m8 4v10M4 7v10l8 4" /></svg><h3 class="text-body font-semibold text-gosign-dark">Data Sources</h3></div><ul class="space-y-2 text-small text-gosign-text-light"><li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Time tracking (SAP CATS, Atoss, Interflex)</span></li><li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Shift planning (ATOSS, SP Expert)</span></li><li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Master data (SAP HCM, Workday)</span></li><li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Tax authority interface (e.g. ELStAM in Germany)</span></li><li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Collective agreement database (versioned)</span></li></ul></div>
<div class="bg-gosign-dark border border-gosign-dark rounded-card p-6"><div class="flex items-center gap-3 mb-4"><svg class="w-6 h-6 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9.75 3.104v5.714a2.25 2.25 0 01-.659 1.591L5 14.5M9.75 3.104c-.251.023-.501.05-.75.082m.75-.082a24.301 24.301 0 014.5 0m0 0v5.714c0 .597.237 1.17.659 1.591L19.8 15.3M14.25 3.104c.251.023.501.05.75.082M19.8 15.3l-1.57.393A9.065 9.065 0 0112 15a9.065 9.065 0 00-6.23.693L5 14.5m14.8.8l1.402 1.402c1.232 1.232.65 3.318-1.067 3.611A48.309 48.309 0 0112 21c-2.773 0-5.491-.235-8.135-.687-1.718-.293-2.3-2.379-1.067-3.61L5 14.5" /></svg><h3 class="text-body font-semibold text-white">Payroll Decision Layer</h3></div><ul class="space-y-2 text-small text-gosign-text-on-dark/80"><li>Collective agreement classification</li><li>Supplement calculation + accumulation</li><li>Tax-exempt portions</li><li>Social insurance contributions + ceiling checks</li><li>Garnishment calculation</li><li>Salary conversion / occupational pension</li><li>Variance check + escalation</li></ul></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><div class="flex items-center gap-3 mb-4"><svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M5.25 14.25h13.5m-13.5 0a3 3 0 01-3-3m3 3a3 3 0 100 6h13.5a3 3 0 100-6m-16.5-3a3 3 0 013-3h13.5a3 3 0 013 3m-19.5 0a4.5 4.5 0 01.9-2.7L5.737 5.1a3.375 3.375 0 012.7-1.35h7.126c1.062 0 2.062.5 2.7 1.35l2.587 3.45a4.5 4.5 0 01.9 2.7m0 0a3 3 0 01-3 3m0 3h.008v.008h-.008v-.008zm0-6h.008v.008h-.008v-.008zm-3 6h.008v.008h-.008v-.008zm0-6h.008v.008h-.008v-.008z" /></svg><h3 class="text-body font-semibold text-gosign-dark">Target Systems</h3></div><ul class="space-y-2 text-small text-gosign-text-light"><li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>SAP HCM / SuccessFactors (payroll)</span></li><li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>ADP / local payroll engine</span></li><li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>SAP FI/CO (posting, cost assignment)</span></li><li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Social insurance reporting</span></li><li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Tax authority interface</span></li></ul></div>
</div>
</div>
</section>

<!-- Industry Simulations -->
<section id="simulations" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulated for enterprise volumes</p>
<h2 class="text-h1 font-bold text-white">Four industries. Calculated.</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">We configured the Payroll Decision Layer for four industries with realistic collective agreements, supplement rules and workforce structures. Each card shows the simulation parameters and the result.</p>
<div class="grid grid-cols-1 md:grid-cols-2 gap-6 mt-10">
<a href="/en/services/hr-agent/payroll-decision-layer/chemicals/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors"><div class="flex items-center justify-between mb-4"><h3 class="text-h3 font-bold text-white">Chemicals</h3><div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div></div><ul class="space-y-1.5 text-small text-gosign-text-on-dark/70"><li>13 pay grades x 13 collective agreement regions = 169 base rates</li><li>Shift supplements 6-10%, hardship allowances</li><li>Future benefit 23% (choice: cash/time off/pension)</li><li>CareFlex Chemie, 13th month salary + holiday pay</li></ul><div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between"><span class="text-h3 font-bold text-gosign-accent-on-dark">88% Zero-Touch</span><span class="text-small text-gosign-accent-on-dark font-semibold">Chemicals in detail &rarr;</span></div></a>
<a href="/en/services/hr-agent/payroll-decision-layer/aviation/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors"><div class="flex items-center justify-between mb-4"><h3 class="text-h3 font-bold text-white">Aviation</h3><div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div></div><ul class="space-y-1.5 text-small text-gosign-text-on-dark/70"><li>3 unions, 14-18 separate collective agreements</li><li>EASA FTL: 900h cap, duty period limits</li><li>180+ country per diem rates</li><li>Cockpit seniority up to level 23</li></ul><div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between"><span class="text-h3 font-bold text-gosign-accent-on-dark">82% Zero-Touch</span><span class="text-small text-gosign-accent-on-dark font-semibold">Aviation in detail &rarr;</span></div></a>
<a href="/en/services/hr-agent/payroll-decision-layer/financial-services/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors"><div class="flex items-center justify-between mb-4"><h3 class="text-h3 font-bold text-white">Financial Services</h3><div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-white/20"></span></div></div><ul class="space-y-1.5 text-small text-gosign-text-on-dark/70"><li>5 parallel remuneration regimes (collective to risk taker)</li><li>Bonus deferral 40-60% over 4-5 years (CRD requirements)</li><li>Malus/clawback: 5-7 year reclaim period</li><li>Mandatory leave blocks for traders (MaRisk / FCA rules)</li></ul><div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between"><span class="text-h3 font-bold text-gosign-accent-on-dark">85% Zero-Touch</span><span class="text-small text-gosign-accent-on-dark font-semibold">Financial Services in detail &rarr;</span></div></a>
<a href="/en/services/hr-agent/payroll-decision-layer/retail/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors"><div class="flex items-center justify-between mb-4"><h3 class="text-h3 font-bold text-white">Retail</h3><div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-white/20"></span></div></div><ul class="space-y-1.5 text-small text-gosign-text-on-dark/70"><li>Multiple regions x pay grades x levels = hundreds of base rates</li><li>64% part-time, marginal employment thresholds</li><li>100,000 seasonal workers, 25.7% turnover</li><li>Supplement accumulation: highest only, night additive</li></ul><div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between"><span class="text-h3 font-bold text-gosign-accent-on-dark">92% Zero-Touch</span><span class="text-small text-gosign-accent-on-dark font-semibold">Retail in detail &rarr;</span></div></a>
</div>
</div>
</section>

<!-- Architecture, Implementation & Leverage -->
<section id="implementation" class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Implementation</p>
<h2 class="text-h1 font-bold text-gosign-dark">From pilot to running system.</h2>
<div class="grid grid-cols-1 lg:grid-cols-2 gap-10 mt-10">
<div><h3 class="text-h3 font-bold text-gosign-dark mb-3">Technical Architecture</h3><p class="text-body text-gosign-text">The Payroll Decision Layer runs entirely within your infrastructure: your data centre, your network, your control. No SaaS dependency, no data leakage, no external telemetry tracking. Containerised, multi-tenant, deployment-ready for your private cloud or as managed deployment in EU data centres.</p><div class="flex flex-wrap gap-4 mt-3"><a href="/en/services/infrastructure/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infrastructure details &rarr;</a><a href="/en/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Decision Layer Architecture &rarr;</a><a href="/en/magazine/decision-act-contestable-ai-decisions/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">The Decision Act &rarr;</a><a href="/en/services/travel-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Travel Decision Layer &rarr;</a></div></div>
<div><h3 class="text-h3 font-bold text-gosign-dark mb-3">Implementation</h3><p class="text-body text-gosign-text">The Decision Layer is not installed but configured: your collective agreements, your supplement rules, your system landscape. Typical pilot projects start within 3 months with one staff group and one collective agreement. Extensions to additional staff groups or legal entities run in parallel with pilot operations.</p></div>
</div>
<h3 class="text-h3 font-bold text-gosign-dark mt-12 mb-6">Economic Leverage</h3>
<div class="grid grid-cols-1 sm:grid-cols-2 gap-6">
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6"><div class="flex items-start gap-4"><svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12l2 2 4-4m5.618-4.016A11.955 11.955 0 0112 2.944a11.955 11.955 0 01-8.618 3.04A12.02 12.02 0 003 9c0 5.591 3.824 10.29 9 11.622 5.176-1.332 9-6.03 9-11.622 0-1.042-.133-2.052-.382-3.016z" /></svg><div><p class="text-body font-semibold text-gosign-dark">Eliminate correction entries before they occur</p><p class="text-small text-gosign-text-light mt-2">Every payroll run goes through the same rule engine. The 1-8% error rate (APA) results from manual rule interpretation. The Decision Layer applies rules consistently - across all collective agreement regions, all staff groups, every month.</p></div></div></div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6"><div class="flex items-start gap-4"><svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M13 10V3L4 14h7v7l9-11h-7z" /></svg><div><p class="text-body font-semibold text-gosign-dark">Collective agreement changes in hours, not weeks</p><p class="text-small text-gosign-text-light mt-2">Deploy new rate table, set validity period, retroactive recalculation runs automatically. No manual updates across multiple regions. No forgotten locations.</p></div></div></div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6"><div class="flex items-start gap-4"><svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M12 6v6h4.5m4.5 0a9 9 0 11-18 0 9 9 0 0118 0z" /></svg><div><p class="text-body font-semibold text-gosign-dark">82-92% zero-touch. Human only where legally required.</p><p class="text-small text-gosign-text-light mt-2">The AI Agent can process every payroll run better than a payroll clerk. Human interventions remain where employee representation law, labour regulation or discrimination risk requires them - not for professional reasons.</p></div></div></div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6"><div class="flex items-start gap-4"><svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12h6m-6 4h6m2 5H7a2 2 0 01-2-2V5a2 2 0 012-2h5.586a1 1 0 01.707.293l5.414 5.414a1 1 0 01.293.707V19a2 2 0 01-2 2z" /></svg><div><p class="text-body font-semibold text-gosign-dark">External payroll tax audit is an export, not a project</p><p class="text-small text-gosign-text-light mt-2">Sealed decision records per payroll run. Which rule, which input, which result. Weeks of preparation become minutes.</p></div></div></div>
</div>
</div>
</section>

<!-- Compliance & Security -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Security</p>
<h2 class="text-h1 font-bold text-gosign-dark">Enterprise security. From day one.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Payroll data is among the most sensitive data in any organisation. The Payroll Decision Layer is designed for regulated environments where data protection, audit readiness and traceability are not optional extras.</p>
<div class="mt-10 grid grid-cols-1 sm:grid-cols-3 gap-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">100% customer infrastructure</h3><p class="text-small text-gosign-text-light mt-2">The Decision Layer runs entirely within your network. No SaaS dependency, no data leakage, no external telemetry tracking. Payroll data never leaves your network.</p></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">GDPR by Design</h3><p class="text-small text-gosign-text-light mt-2">Anonymisation instead of deletion. Compatible with tax retention periods (10 years in Germany, varies by jurisdiction) and GDPR Art. 17. No conflict between tax law and data protection. (UK: UK GDPR provisions apply equivalently post-Brexit.)</p><a href="/en/governance/data-residency/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Data residency in detail</a></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">AI Act compliant</h3><p class="text-small text-gosign-text-light mt-2">Clear architecture separation: the AI Agent classifies and detects patterns. The calculation of salaries, supplements and taxes runs deterministically through rule engines. No black box over amounts, full traceability for classification.</p><a href="/en/governance/eu-ai-act/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">EU AI Act Readiness</a></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">Audit Trail (append-only)</h3><p class="text-small text-gosign-text-light mt-2">Signed decision records. Input hash plus rule version yields reproducible result. Sealed audit packs (JSON + PDF, SHA-256). Payroll audit ready at any time.</p></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">ISO 27001 / SOC 2 cert-ready</h3><p class="text-small text-gosign-text-light mt-2">Integrated controls registry, automated evidence runs, versioned policies. Compliance in running operations, not documented after the fact.</p><a href="/en/governance/cert-ready/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready by Design</a></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">SSO and tenant isolation</h3><p class="text-small text-gosign-text-light mt-2">Integration with existing identity providers. Tenant isolation at database level (row-level security). Role model granularly configurable. Legal entities cleanly separated.</p></div>
</div>
</div>
</section>


<!-- Weitere Agent-Lösungen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">More Agent Solutions</h2>
<p class="text-body-lg text-gosign-text-light mt-4">HR Agents are part of our agent portfolio. We offer specialized solutions for Finance and other domains.</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8 max-w-content">
<a href="/en/hr-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR & People Operations</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">All HR Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Works-council ready.</p>
</a>
<a href="/en/finance-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Finance & Accounting</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Finance AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Document processing, account assignment, depreciation logic, correction postings.</p>
</a>
<a href="/en/contact/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Custom</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Co-Build for Your Process</h3>
<p class="text-body text-gosign-text-light mt-2">Compliance, operations, shared services - we develop agents in a co-build model.</p>
</a>
</div>
</div>
</section>

<!-- This Agent in the Catalog -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark">When to Start? Prioritization and Governance Readiness</h2>
<p class="text-body text-gosign-text mt-4">Which quarter should this agent launch? What governance infrastructure must be in place first? Which agents are prerequisites? The HR Agent Catalog places this agent in the Q1-Q4 sequencing and shows readiness scores, governance complexity, and dependencies to other agents.</p>
<a href="/en/hr-agent-catalog/payroll-processing-agent/" class="inline-flex items-center gap-2 mt-4 text-body font-semibold text-gosign-accent hover:underline">View sequencing and scores &rarr;</a>
</div>
</section>

<!-- Deep Dive -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Deep Dive in the Agent Briefing (Gosign Magazine)</h2>
<p class="text-body text-gosign-text-light mb-6">Our expert article series for decision-makers deploying AI Agents in the enterprise.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/en/magazine/decision-layer-payroll/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors"><p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Finance</p><p class="text-body font-semibold text-gosign-dark">Structurally Eliminating Payroll Errors - Decision Layer for Finance</p></a>
<a href="/en/magazine/works-council-ai-co-determination/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors"><p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Co-Determination</p><p class="text-body font-semibold text-gosign-dark">Works Council and AI - Co-Determination as Architecture Constraint</p></a>
<a href="/en/magazine/decision-layer-explained/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors"><p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Fundamentals</p><p class="text-body font-semibold text-gosign-dark">Decision Layer - What It Is and Why Every Enterprise AI Agent Needs One</p></a>
</div>
</div>
</section>

--- AI Infrastructure Engineering ---
> LLM hosting, RAG pipeline, orchestration, and deployment. Model-agnostic, self-hosted or cloud. The production platform for AI agents in your infrastructure.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/en/why-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act (UK: UK AI regulatory framework) ready</p>
<p class="text-xs text-gosign-text-light">Every decision traceable</p>
</div>
</a>
<a href="/en/why-gosign/#infrastructure" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Your infrastructure</p>
<p class="text-xs text-gosign-text-light">No SaaS. No vendor lock-in.</p>
</div>
</a>
<a href="/en/why-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">No US cloud risk</p>
</div>
</a>
</div>
</div>
</div>

<!-- Why Infrastructure Is the Bottleneck -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Why Infrastructure Is the Bottleneck</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Most organisations piloting AI agents do not fail because of the model. The models work. They fail because of infrastructure: no governance framework, no audit trail, no tenant isolation, no deployment concept, no integration into existing systems.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
A pilot on a laptop is not a production architecture. This page describes the concrete technologies and configurations that turn an LLM experiment into an operational system.
</p>
<p class="text-body text-gosign-text-light mt-4">
How the individual infrastructure components work together architecturally is described in the <a href="/en/governance/reference-architecture/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">7-Layer Reference Architecture</a>.
</p>
</div>
</div>
</section>

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Free eBook: AI Infrastructure</p>
<p class="text-body text-gosign-text mb-4">Build, Buy, Hybrid - EU AI Act-compliant infrastructure with B/B/H Framework and 7-Layer Reference Architecture.</p>
<a href="/en/ebook/ai-infrastructure-governance-handbook/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Download for free</a>
</div>

<!-- 1. LLM Hosting -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Four Infrastructure Components</h2>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">1. LLM Hosting</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
The model layer. Where language understanding happens.
</p>
<p class="text-body-lg text-gosign-text-light mt-4"><strong>Cloud LLMs:</strong></p>
<ul class="mt-2 space-y-2">
<li class="text-body-lg text-gosign-text-light">Azure OpenAI (ChatGPT, Claude) - EU regions, Microsoft DPA</li>
<li class="text-body-lg text-gosign-text-light">Amazon Bedrock (Claude, Llama, Mistral) - EU regions, AWS DPA</li>
<li class="text-body-lg text-gosign-text-light">Google Vertex AI (Gemini) - EU regions, Google DPA</li>
<li class="text-body-lg text-gosign-text-light">Anthropic API (Claude) - with EU data processing</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-4"><strong>Self-Hosted LLMs:</strong></p>
<ul class="mt-2 space-y-2">
<li class="text-body-lg text-gosign-text-light">Llama (Meta) - open source, on your own hardware</li>
<li class="text-body-lg text-gosign-text-light">Mistral - open source, EU-based company</li>
<li class="text-body-lg text-gosign-text-light">DeepSeek - open source, cost-efficient</li>
<li class="text-body-lg text-gosign-text-light"><a href="https://openai.com/open-models/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">gpt-oss</a> (OpenAI) - open weight, Apache 2.0, fully self-hostable. 120B on a single H100, 20B on 16 GB consumer hardware.</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-4"><strong>Inference Frameworks for Self-Hosted:</strong></p>
<ul class="mt-2 space-y-2">
<li class="text-body-lg text-gosign-text-light"><a href="https://ollama.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Ollama</a> - Easy entry, local development, edge deployment</li>
<li class="text-body-lg text-gosign-text-light"><a href="https://docs.vllm.ai/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">vLLM</a> - Production-grade, GPU-optimised, high throughput</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-4"><strong>Hybrid:</strong></p>
<ul class="mt-2 space-y-2">
<li class="text-body-lg text-gosign-text-light">Self-hosted for sensitive data (HR, finance)</li>
<li class="text-body-lg text-gosign-text-light">Cloud LLMs for less critical workloads (document classification)</li>
<li class="text-body-lg text-gosign-text-light">Automatic routing based on data classification</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-4">
Model choice is a trade-off between performance, cost, data protection, and latency. We advise on selection and implement model-agnostically - switching models does not change the business logic. Further reading: <a href="/en/magazine/ai-models-comparison-2026/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">LLM Models Comparison 2026</a>, <a href="/en/magazine/llm-self-hosting-enterprise/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">LLM Self-Hosting for Enterprise</a>
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Our AI engineers are Microsoft-certified for Azure AI Services. Deployment options include <a href="https://azure.microsoft.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Microsoft Azure</a>, <a href="https://cloud.google.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">GCP</a>, and fully self-hosted infrastructure - the architecture decision stays with the client, not the vendor.
</p>
</div>
</div>
</section>

<!-- 2. RAG Pipeline -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h3 class="text-h3 font-bold text-gosign-dark">2. RAG Pipeline</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Retrieval Augmented Generation - how agents access enterprise knowledge.
</p>
</div>
<img src="/images/diagrams/rag-pipeline-en.svg" alt="RAG Pipeline: Documents are split into chunks, stored as embeddings in a vector store, semantically retrieved on query, and passed to the LLM as context" class="w-full mt-6" width="1200" height="400" loading="lazy" />
<div class="max-w-narrow mt-6">
<p class="text-body-lg text-gosign-text-light"><strong>Quality characteristics:</strong></p>
<ul class="mt-2 space-y-2">
<li class="text-body-lg text-gosign-text-light">Semantic chunking (by content, not by page number)</li>
<li class="text-body-lg text-gosign-text-light">Metadata enrichment (document type, version, scope of validity)</li>
<li class="text-body-lg text-gosign-text-light">Hybrid search (vector search + keyword search for precision)</li>
<li class="text-body-lg text-gosign-text-light">Source citation in every response (document, page, paragraph)</li>
<li class="text-body-lg text-gosign-text-light">Regular re-indexing on document changes</li>
</ul>
</div>
</div>
</section>

<!-- 3. Orchestration -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h3 class="text-h3 font-bold text-gosign-dark">3. Orchestration</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
The control layer. How agents, systems, and people work together.
</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light"><strong><a href="https://trigger.dev" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Trigger.dev</a> or <a href="https://camunda.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Camunda</a>:</strong> Open-source workflow engine. Visual workflows, API integration, webhooks. Self-hosted, no vendor lock-in.</li>
<li class="text-body-lg text-gosign-text-light"><strong>API Gateway:</strong> Unified entry point. Rate limiting, authentication, logging, monitoring.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Queue system:</strong> Asynchronous processing for batch operations (month-end close, bulk imports).</li>
<li class="text-body-lg text-gosign-text-light"><strong>Event system:</strong> Real-time reaction to incoming documents, status changes, escalations.</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-4">
Orchestration is the difference between "an agent can do something" and "an agent reliably does something in production". More: <a href="/en/magazine/agent-orchestration-platforms/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Agent Orchestration Platforms</a>
</p>
</div>
</div>
</section>

<!-- 4. Deployment -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h3 class="text-h3 font-bold text-gosign-dark">4. Deployment</h3>
<p class="text-body-lg text-gosign-text-light mt-4">Where the infrastructure runs. All options EU-only available.</p>

<h4 class="text-body-lg font-bold text-gosign-dark mt-6">Azure (EU)</h4>
<ul class="mt-2 space-y-1">
<li class="text-body text-gosign-text-light">Azure Kubernetes Service (AKS) for container orchestration</li>
<li class="text-body text-gosign-text-light">Azure SQL / PostgreSQL for data and Audit Trail</li>
<li class="text-body text-gosign-text-light">Azure OpenAI for LLM hosting</li>
<li class="text-body text-gosign-text-light">Regions: West Europe, North Europe, Germany West Central</li>
</ul>

<h4 class="text-body-lg font-bold text-gosign-dark mt-6">AWS (EU)</h4>
<ul class="mt-2 space-y-1">
<li class="text-body text-gosign-text-light">Amazon EKS for container orchestration</li>
<li class="text-body text-gosign-text-light">Amazon RDS / Aurora PostgreSQL for data and Audit Trail</li>
<li class="text-body text-gosign-text-light">Amazon Bedrock for LLM hosting (Claude, Llama, Mistral)</li>
<li class="text-body text-gosign-text-light">Regions: eu-central-1 (Frankfurt), eu-west-1 (Ireland), eu-west-3 (Paris)</li>
</ul>

<h4 class="text-body-lg font-bold text-gosign-dark mt-6">GCP (EU)</h4>
<ul class="mt-2 space-y-1">
<li class="text-body text-gosign-text-light">Google Kubernetes Engine (GKE) for container orchestration</li>
<li class="text-body text-gosign-text-light">Cloud SQL / AlloyDB for data and Audit Trail</li>
<li class="text-body text-gosign-text-light">Vertex AI for LLM hosting</li>
<li class="text-body text-gosign-text-light">Regions: europe-west1, europe-west3, europe-west4</li>
</ul>

<h4 class="text-body-lg font-bold text-gosign-dark mt-6">Vercel EU + Supabase EU</h4>
<ul class="mt-2 space-y-1">
<li class="text-body text-gosign-text-light">Vercel for frontend and edge functions in EU data centres</li>
<li class="text-body text-gosign-text-light">Supabase for database (PostgreSQL), auth, and storage</li>
<li class="text-body text-gosign-text-light">Lightweight EU deployment option without own Kubernetes infrastructure</li>
<li class="text-body text-gosign-text-light">Managed services with EU data residency</li>
</ul>

<h4 class="text-body-lg font-bold text-gosign-dark mt-6">Self-Hosted</h4>
<ul class="mt-2 space-y-1">
<li class="text-body text-gosign-text-light"><a href="https://www.docker.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Docker</a> / <a href="https://kubernetes.io/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Kubernetes</a> on your own hardware</li>
<li class="text-body text-gosign-text-light"><a href="https://www.postgresql.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">PostgreSQL</a> with <a href="https://github.com/pgvector/pgvector" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">pgvector</a> for data and vector search</li>
<li class="text-body text-gosign-text-light">Open-source LLMs on your own GPUs</li>
<li class="text-body text-gosign-text-light">Complete Cloud Act independence</li>
</ul>

<h4 class="text-body-lg font-bold text-gosign-dark mt-6">Hybrid</h4>
<ul class="mt-2 space-y-1">
<li class="text-body text-gosign-text-light">Combination by data classification</li>
<li class="text-body text-gosign-text-light">Sensitive workloads self-hosted, standard workloads cloud</li>
<li class="text-body text-gosign-text-light">Unified orchestration across all environments</li>
</ul>
</div>
</div>
</section>

<!-- Technology Stack -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Technology Stack</h2>
<div class="mt-8 overflow-x-auto">
<table class="w-full text-left text-small border-collapse">
<thead>
<tr>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Component</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Technology</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Why</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Workflow engine</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://trigger.dev" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Trigger.dev</a>, <a href="https://camunda.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Camunda</a></td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Open source, self-hosted, no vendor lock-in</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Database</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://www.postgresql.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">PostgreSQL</a> + <a href="https://github.com/pgvector/pgvector" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">pgvector</a></td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Enterprise-ready, RLS-capable, vector search integrated</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Backend</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://www.python.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Python</a>, <a href="https://www.typescriptlang.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">TypeScript</a></td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Proven for ML workloads and API development</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Frontend</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://react.dev/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">React</a> / <a href="https://nextjs.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Next.js</a></td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">For dashboard, chat UI, Auditor Portal</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Containers</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://www.docker.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Docker</a>, <a href="https://kubernetes.io/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Kubernetes</a></td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Standard for cloud and self-hosted</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">API</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">REST, <a href="https://graphql.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">GraphQL</a></td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Integration with existing systems</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Auth</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://supabase.com/auth" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Supabase Auth</a> / OIDC</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">SSO-capable, integrates with enterprise identity providers</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Monitoring</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://prometheus.io/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Prometheus</a>, <a href="https://grafana.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Grafana</a></td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Open source, self-hosted, real-time dashboards</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Inference</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://ollama.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Ollama</a>, <a href="https://docs.vllm.ai/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">vLLM</a></td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Self-hosted LLM inference, GPU-optimised</td></tr>
</tbody>
</table>
</div>
</div>
</div>
</section>

<!-- Governance Is Built In -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Governance Is Built In</h2>
<p class="text-body-lg text-gosign-text-light mt-4">The infrastructure includes Governance by Design:</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light"><strong>Audit Trail</strong> at infrastructure level (not just application level)</li>
<li class="text-body-lg text-gosign-text-light"><strong>Row-Level Security</strong> at database level - details in <a href="/en/governance/data-residency/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Data Residency</a></li>
<li class="text-body-lg text-gosign-text-light"><strong>Encryption</strong> at rest and in transit</li>
<li class="text-body-lg text-gosign-text-light"><strong>RBAC</strong> across all components</li>
<li class="text-body-lg text-gosign-text-light"><strong><a href="/en/governance/cert-ready/" class="text-gosign-dark hover:text-gosign-accent-text transition-colors">Cert-Ready</a> Controls</strong> as technical data objects</li>
</ul>
<p class="mt-4">
<a href="/en/governance/reference-architecture/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Governance in the 7-Layer Architecture -></a>
</p>
</div>
</div>
</section>

<!-- Source Code Access -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Full Source Code Access</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
The infrastructure runs on your systems - Azure, GCP, AWS or self-hosted. No SaaS, no hosting at Gosign. Full access to source code, configurations, and rule sets. Open-source stack where possible. Proprietary components only for the LLMs themselves - and there model-agnostic.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
After 12-18 months, you operate the infrastructure independently.
</p>
</div>
</div>
</section>

<!-- Deep Dive -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Deep Dive in the Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Our article series for decision-makers implementing AI agents in the enterprise.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/en/magazine/ai-infrastructure-blueprint-2026/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">Enterprise AI Infrastructure Blueprint 2026</p>
</a>
<a href="/en/magazine/ai-hosting-strategies-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">AI Hosting: EU SaaS, German Data Center, or Self-Hosted?</p>
</a>
<a href="/en/magazine/llm-self-hosting-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">LLM Self-Hosting for Enterprise - Azure, GCP, On-Premise</p>
</a>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark mb-6">Deep Dives</h2>
<div class="grid gap-6 sm:grid-cols-2">
<div class="border-l-4 border-gosign-dark pl-6 py-4">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Architecture</p>
<h3 class="text-h3 font-bold text-gosign-dark">7-Layer Reference Architecture</h3>
<p class="text-body text-gosign-text-light mt-2">How the infrastructure components work together architecturally - Presentation, Orchestration, Agent, Decision Layer, Model, Integration, Infrastructure.</p>
<a href="/en/governance/reference-architecture/" class="text-small font-semibold text-gosign-accent-text hover:text-gosign-accent-hover mt-3 inline-block whitespace-nowrap">View Reference Architecture ></a>
</div>
<div class="border-l-4 border-gosign-dark pl-6 py-4">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Knowledge Resource</p>
<h3 class="text-h3 font-bold text-gosign-dark">Blueprint 2026</h3>
<p class="text-body text-gosign-text-light mt-2">Eleven articles on the infrastructure decisions that matter in 2026: AI models, hosting, RAG, orchestration, costs, EU AI Act.</p>
<a href="/en/magazine/ai-infrastructure-blueprint-2026/" class="text-small font-semibold text-gosign-accent-text hover:text-gosign-accent-hover mt-3 inline-block whitespace-nowrap">Read the Series ></a>
</div>
<div class="border-l-4 border-gosign-dark pl-6 py-4">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<h3 class="text-h3 font-bold text-gosign-dark">Data Residency</h3>
<p class="text-body text-gosign-text-light mt-2">Row-Level Security, tenant isolation, encryption, EU data processing - where your data lives and who controls it.</p>
<a href="/en/governance/data-residency/" class="text-small font-semibold text-gosign-accent-text hover:text-gosign-accent-hover mt-3 inline-block whitespace-nowrap">Data Residency ></a>
</div>
<div class="border-l-4 border-gosign-dark pl-6 py-4">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Agents</p>
<h3 class="text-h3 font-bold text-gosign-dark">AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Document Agents, Workflow Agents, Knowledge Agents - three agent types for enterprise processes.</p>
<a href="/en/services/ai-agents/" class="text-small font-semibold text-gosign-accent-text hover:text-gosign-accent-hover mt-3 inline-block whitespace-nowrap">Explore AI Agents ></a>
</div>
</div>
</div>
</div>
</section>

--- Enterprise Software Engineering Since 2001 ---
> Over 5,000 projects for Airbus, Volkswagen, Shell. 25 years of enterprise software development - today the engineering foundation for AI infrastructure.

<!-- 25 Years -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">25 Years of Enterprise Software Development</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Gosign has been developing software for enterprise clients since 2001. Over 5,000 projects for <a href="/en/references/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Airbus, Volkswagen, Shell, and others</a> - complex, multilingual enterprise platforms with requirements for security, scalability, and maintainability.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
This foundation is the reason Gosign builds <a href="/en/services/ai-agents/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">AI infrastructure</a> today. Not as a startup that has existed for two years, but as a company with 25 years of engineering experience in enterprise environments.
</p>
</div>
</section>

<!-- What We Build Today -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">What We Build Today</h2>
<div class="grid grid-cols-1 md:grid-cols-2 gap-6 lg:gap-8">
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M13.19 8.688a4.5 4.5 0 0 1 1.242 7.244l-4.5 4.5a4.5 4.5 0 0 1-6.364-6.364l1.757-1.757m9.864-9.864a4.5 4.5 0 0 0-6.364 6.364l4.5 4.5a4.5 4.5 0 0 0 7.244 1.242" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Custom Integrations</h3>
<p class="text-body text-gosign-text-light mt-3">Connecting AI agents to existing enterprise systems. SAP, DATEV, SuccessFactors, Workday, Microsoft Graph - via REST, SOAP, RFC, or proprietary interfaces. Integration is the point where most AI projects fail. We have solved it thousands of times.</p>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M14.25 9.75 16.5 12l-2.25 2.25m-4.5 0L7.5 12l2.25-2.25M6 20.25h12A2.25 2.25 0 0 0 20.25 18V6A2.25 2.25 0 0 0 18 3.75H6A2.25 2.25 0 0 0 3.75 6v12A2.25 2.25 0 0 0 6 20.25Z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">API Development</h3>
<p class="text-body text-gosign-text-light mt-3">Machine-readable interfaces for agents, dashboards, and third-party systems. REST and GraphQL. Authentication, rate limiting, versioning, documentation.</p>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="m21 7.5-9-5.25L3 7.5m18 0-9 5.25m9-5.25v9l-9 5.25M3 7.5l9 5.25M3 7.5v9l9 5.25m0-9v9" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">System Architecture</h3>
<p class="text-body text-gosign-text-light mt-3">Architecture design for AI agent platforms. Data model, deployment strategy, scaling concept, security architecture. The architecture determines whether a system is still maintainable in two years.</p>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 17.25v1.007a3 3 0 0 1-.879 2.122L7.5 21h9l-.621-.621A3 3 0 0 1 15 18.257V17.25m6-12V15a2.25 2.25 0 0 1-2.25 2.25H5.25A2.25 2.25 0 0 1 3 15V5.25m18 0A2.25 2.25 0 0 0 18.75 3H5.25A2.25 2.25 0 0 0 3 5.25m18 0V12a2.25 2.25 0 0 1-2.25 2.25H5.25A2.25 2.25 0 0 1 3 12V5.25" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Enterprise Platforms</h3>
<p class="text-body text-gosign-text-light mt-3">Web-based platforms for internal users: dashboards, auditor portals, chat interfaces, workflow tools. Responsive, accessible, performant.</p>
</article>
</div>
</div>
</section>

<!-- Engineering Principles -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Engineering Principles</h2>
<div class="mt-6 space-y-6">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Test-Driven Development (TDD) & Continuous Pair Programming</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Every line of code is written in pair programming. Test-driven (TDD), versioned, review-required. No lone wolves, no knowledge silos. Tests are written before code. Every function has tests. Every merge requires green tests.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Continuous Integration / Continuous Deployment (CI/CD)</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Automated build pipeline, automated tests, automated deployment. Every push is tested. Every merge is deployed.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Code Review</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Every merge request is reviewed by at least one other developer. Four-eyes principle for all production changes.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Security by Design</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Security is not a retroactive layer. RBAC, encryption, input validation, output encoding - from day 1.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Audit Trail</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Every change to configuration, rule sets, and system state is documented. Who changed what when - traceable and immutable.
</p>
</div>
</div>
</div>
</section>

<!-- Technology Stack -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Technology Stack</h2>
</div>
<div class="mt-8 overflow-x-auto">
<table class="w-full text-left text-small border-collapse min-w-[30rem]">
<thead>
<tr>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Area</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Technologies</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Backend</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://www.python.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Python</a>, <a href="https://www.typescriptlang.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">TypeScript</a>, Node.js</td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Frontend</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://react.dev/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">React</a>, <a href="https://nextjs.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Next.js</a></td>
</tr>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Database</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://www.postgresql.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">PostgreSQL</a>, Supabase</td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Workflow</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://trigger.dev" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Trigger.dev</a>, <a href="https://n8n.io/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">n8n</a>, <a href="https://camunda.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Camunda</a></td>
</tr>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Containers</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://www.docker.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Docker</a>, <a href="https://kubernetes.io/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Kubernetes</a></td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">CI/CD</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://github.com/features/actions" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">GitHub Actions</a>, <a href="https://docs.gitlab.com/ee/ci/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">GitLab CI</a></td>
</tr>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Monitoring</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://prometheus.io/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Prometheus</a>, <a href="https://grafana.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Grafana</a></td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Auth</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://supabase.com/auth" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Supabase Auth</a>, OIDC</td>
</tr>
</tbody>
</table>
</div>
<p class="text-body-lg text-gosign-text-light mt-6">
The stack follows the project's requirements. We use open-source technologies where possible - for transparency, independence, and cost efficiency.
</p>
</div>
</section>

<!-- From Software Engineering to AI -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">From Software Engineering to AI Infrastructure</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
The engineering principles that apply to enterprise software development also apply to <a href="/en/services/infrastructure/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">AI infrastructure</a>. An AI agent running in production needs the same discipline as any other enterprise software: tests, deployment pipelines, monitoring, audit trail, security.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
The difference: an AI agent makes professional decisions that must be documented and traceable. This requires additional architectural components - the <a href="/en/decision-layer/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Decision Layer</a>, Governance by Design, <a href="/en/governance/cert-ready/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Cert-Ready Controls</a>. But the foundation is software engineering.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
25 years of that foundation is why our AI infrastructure works.
</p>
</div>
</section>

<!-- Deep Dive -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Deep Dive in the Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Our article series for decision-makers implementing AI agents in the enterprise.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/en/magazine/ai-integration-it-landscape/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">AI Integration Into Existing IT Landscapes - SAP, DATEV, Workday</p>
</a>
<a href="/en/magazine/ai-agents-enterprise-guide/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">AI Agents</p>
<p class="text-body font-semibold text-gosign-dark">From Chatbots to AI Agents: MCP, A2A and Multi-Agent Systems</p>
</a>
<a href="/en/magazine/ai-infrastructure-blueprint-2026/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">Enterprise AI Infrastructure Blueprint 2026</p>
</a>
</div>
</div>
</section>

--- AI Travel Agent Aviation - Crew Expenses ---
> Decision Layer for crew travel expenses. Rotation-based processing, crew-specific collective agreements, multi-country per diems. Audit-ready automation.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/en/why-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Every decision traceable</p>
</div>
</a>
<a href="/en/why-gosign/#infrastructure" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Your infrastructure</p>
<p class="text-xs text-gosign-text-light">No SaaS. No vendor lock-in.</p>
</div>
</a>
<a href="/en/why-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">No US cloud risk</p>
</div>
</a>
</div>
</div>
</div>

<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Travel Decision Layer Industries">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/en/services/travel-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Travel Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/en/services/travel-decision-layer/aviation/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Aviation</a>
<a href="/en/services/travel-decision-layer/consulting/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Consulting</a>
<a href="/en/services/travel-decision-layer/logistics/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Logistics</a>
<a href="/en/services/travel-decision-layer/sales/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Sales</a>
</div>
</div>
</nav>

<!-- Why Aviation has the highest complexity -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<!-- Simulation stats as visual intro -->
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">100,000+</span>
<p class="text-small text-gosign-text-light mt-1">Cases/year (simulation)</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">95%</span>
<p class="text-small text-gosign-text-light mt-1">Zero-touch rate</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">10 - 20%</span>
<p class="text-small text-gosign-text-light mt-1">IROP rate (industry standard)</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">Highest rule complexity</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">Cases and zero-touch: Gosign simulation model. IROP rate: EUROCONTROL / US DOT BTS, 2024. (UK: UK CAA statistics post-Brexit.)</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">What the Agent classifies</p>
<h2 class="text-h1 font-bold text-gosign-dark">Three crew groups, one agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Cockpit, cabin, ground - each group with its own tariff, per diems, complexity. You know the complexity. Here's how the AI Agent solves it:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Hundreds of rotations per day</h3>
<p class="text-body text-gosign-text mt-2">Every rotation creates a travel expense case. The AI Agent reads rotation data from crew planning systems and triggers per diem calculation automatically. No manual capture, no form, no delay - hundreds of cases processed per hour without human input.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Three to five countries per duty day</h3>
<p class="text-body text-gosign-text mt-2">A single rotation touches multiple countries in one duty day. The AI Agent classifies each country segment and its duration. The rule engine then selects the correct per diem rate per country and calculates full or reduced amounts based on stay duration - deterministically, for every rotation, without exception.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Tariff override per crew group</h3>
<p class="text-body text-gosign-text mt-2">Cockpit, cabin, ground and maintenance each have different collective agreements. The AI Agent classifies crew group per employee. The rule engine then applies the correct tariff override - collective agreement rates that supersede statutory rates, company agreements that add a further rule layer. Same rotation, different crew group, different calculation - automatically.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">IROP volatility in real time</h3>
<p class="text-body text-gosign-text mt-2">Delays, diversions, repositioning change every rotation. The AI Agent classifies the type of irregularity and maps the actual itinerary. The rule engine recalculates per diems based on actual location and duration - not the planned schedule. Volatile operations, deterministic results.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Volume governance without sampling</h3>
<p class="text-body text-gosign-text mt-2">Thousands of crew generate identical cases daily. The AI Agent checks 100% of all cases against the same rule version. Every systematic error is caught immediately - not discovered during quarterly reconciliation. Tax audit risk eliminated at the source, not managed after the fact.</p>
</div>
</div>
</div>
</section>

<!-- Decision Flow -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">One rotation. 40 to 120 micro-decisions.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">A crew member flies a three-day rotation with layover. The Decision Layer decomposes this into individual decision steps:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Step</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Decision</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Decider</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Rationale</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Read rotation from duty roster</td><td class="py-3 px-4">Automatic</td><td class="py-3 px-4">Data import, no decision</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Determine country sequence</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">GPS or schedule: which countries, which duration</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Select per diem per country</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">Country-specific rates per regulatory framework</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Check collective agreement override</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">Crew-specific collective agreement overrides statutory rates</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Calculate meal deduction</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">Provided meals reduce per diem deterministically</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Classify IROP</td><td class="py-3 px-4">AI</td><td class="py-3 px-4">Delay, diversion, repositioning: AI classifies type</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Recalculate IROP impact</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">Changed duration or country: recalculate per diem</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">Check layover hotel</td><td class="py-3 px-4">AI + Rule engine</td><td class="py-3 px-4">AI extracts hotel data, rule engine checks policy compliance</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Map cost centre</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">Rotation to fleet, fleet to cost centre</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Generate audit pack</td><td class="py-3 px-4">Automatic</td><td class="py-3 px-4">Sealed decision record per rotation</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Simulation Results -->
<section id="simulation" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulation</p>
<h2 class="text-h1 font-bold text-white">Calculated for aviation volumes</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">We configured the Travel Decision Layer with realistic aviation parameters and ran the numbers. The results show what changes at enterprise volumes.</p>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Simulation parameters</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Crew members</td><td class="py-3 px-4">10,000 to 50,000+ (multiple staff groups with separate collective agreements)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Collective agreements</td><td class="py-3 px-4">2 to 5 in parallel (per staff group and carrier)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Cases/year</td><td class="py-3 px-4">100,000 to 1,000,000+</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Jurisdictions</td><td class="py-3 px-4">Multi-jurisdiction (EU member states, UK, US and beyond)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">System integration</td><td class="py-3 px-4">Crew planning &rarr; Decision Layer &rarr; ERP/Payroll</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">IROP rate</td><td class="py-3 px-4">10 - 20% of all rotations with schedule deviation (industry standard)</td></tr>
</tbody>
</table>
</div>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Before / After</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th class="text-left py-3 px-4 font-semibold text-white">Dimension</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manual</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Processing cost</td><td class="py-3 px-4">from EUR 53 (GBTA)*</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; EUR 9</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Error rate</td><td class="py-3 px-4">19% (GBTA)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 0.3%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Processing time</td><td class="py-3 px-4">5 - 12 business days</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Minutes</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Zero-touch rate</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">95%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Audit readiness</td><td class="py-3 px-4">Manually reconstructed</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatically generated</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Collective agreement change</td><td class="py-3 px-4">Weeks</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 24h</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Retro correction</td><td class="py-3 px-4">Manual overwrite</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Reversal + adjustment (append-only)</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">* GBTA Foundation 2024: USD 58 per transaction (approx. EUR 53). Crew cases with collective agreement logic, multi-jurisdiction and IROP handling are typically higher. IROP rate: EUROCONTROL Annual Report, 2024. Simulation results: Gosign model calculation.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">In the simulation, the Decision Layer achieves a zero-touch rate of 95% - regardless of whether 100,000 or 1,000,000 cases per year are processed. Only 5% require human attention. For the remaining 95%, a complete, audit-ready decision record is available. Corrections and collective agreement changes generate reversal and adjustment entries - no overwrites, complete posting history.</p>
</div>
</section>

<!-- Architecture Reference -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Architecture and implementation</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">The Travel Decision Layer runs entirely within your infrastructure: your data centre, your network, your control. No SaaS dependency, no data leakage. For aviation, this means: crew planning system integration, real-time rotation data processing, collective agreement-specific rulesets per staff group and end-to-end audit trail to SAP FI/CO. Typical pilot projects start within 3 months with one crew group and one collective agreement.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/en/services/travel-decision-layer/#implementation" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Architecture, implementation and economic leverage in detail &rarr;</a>
<a href="/en/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Decision Layer Architecture &rarr;</a>
<a href="/en/services/infrastructure/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infrastructure details &rarr;</a>
<a href="/en/governance/co-determination/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Employee Representation &amp; Co-Determination &rarr;</a>
<a href="/en/governance/cert-ready/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready by Design &rarr;</a>
</div>
</div>
</section>

<!-- Deep Dive -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Deep Dive in the Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Our article series for decision-makers implementing AI agents in the enterprise.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/en/magazine/decision-layer-explained/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Foundations</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - What It Is and Why Every Enterprise AI Agent Needs One</p>
</a>
<a href="/en/magazine/works-council-ai-co-determination/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Co-Determination</p>
<p class="text-body font-semibold text-gosign-dark">Works Council and AI, Co-Determination as Architecture Constraint</p>
</a>
<a href="/en/magazine/eu-ai-act-hr/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Regulation</p>
<p class="text-body font-semibold text-gosign-dark">EU AI Act: What HR Departments Must Do Now</p>
</a>
</div>
</div>
</section>

<!-- Other Industries -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Travel Decision Layer in Other Industries</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Each industry has its own tariffs, cost structures, and complexity drivers. The Decision Layer is the same. The configuration is industry-specific.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/en/services/travel-decision-layer/consulting/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Consulting</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">Client split, multi-cost centre, policy</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">85% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Details &rarr;</span>
</div>
</a>
<a href="/en/services/travel-decision-layer/logistics/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Logistics</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">GPS, EU Mobility Package, zero-touch driver</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">95% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Details &rarr;</span>
</div>
</a>
<a href="/en/services/travel-decision-layer/sales/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Sales</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">500 field reps, CRM integration, entertainment</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">90% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Details &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- AI Travel Agent Consulting - Travel Expenses ---
> Decision Layer for consulting travel expenses. Three-way cost split tax/client/internal, multi-client weeks, changing cost centres. Audit-ready automation.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/en/why-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Every decision traceable</p>
</div>
</a>
<a href="/en/why-gosign/#infrastructure" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Your infrastructure</p>
<p class="text-xs text-gosign-text-light">No SaaS. No vendor lock-in.</p>
</div>
</a>
<a href="/en/why-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">No US cloud risk</p>
</div>
</a>
</div>
</div>
</div>

<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Travel Decision Layer Industries">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/en/services/travel-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Travel Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/en/services/travel-decision-layer/aviation/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Aviation</a>
<a href="/en/services/travel-decision-layer/consulting/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Consulting</a>
<a href="/en/services/travel-decision-layer/logistics/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Logistics</a>
<a href="/en/services/travel-decision-layer/sales/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Sales</a>
</div>
</div>
</nav>

<!-- Why Consulting is complex -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<!-- Simulation stats as visual intro -->
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">50,000+</span>
<p class="text-small text-gosign-text-light mt-1">Cases/year (simulation)</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">85%</span>
<p class="text-small text-gosign-text-light mt-1">Zero-touch rate</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">3-way</span>
<p class="text-small text-gosign-text-light mt-1">Cost split (tax/client/internal)</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-border"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">High rule complexity</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">Cases and zero-touch: Gosign simulation model. Industry benchmarks: GBTA Foundation, 2015.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">What the Agent classifies</p>
<h2 class="text-h1 font-bold text-gosign-dark">Three splits, one agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Tax, client, internal - each trip creates three cost perspectives simultaneously. You know the complexity. Here's how the AI Agent solves it:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Three-way split per transaction</h3>
<p class="text-body text-gosign-text mt-2">Every consulting expense has three cost perspectives simultaneously. The AI Agent classifies each expense into tax treatment, client allocation, and internal cost assignment. The rule engine then calculates all three splits deterministically - deductible vs. non-deductible, billable vs. internal, cost centre vs. project vs. overhead. One transaction, three perspectives, zero manual intervention.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Multi-client weeks auto-split</h3>
<p class="text-body text-gosign-text mt-2">A consultant visits Client A on Monday, Client B on Wednesday. The AI Agent reads calendar and project management data to classify each day to its client. The rule engine splits hotel costs proportionally, adjusts per diems mid-week, and allocates every euro to the correct client project - automatically, documented, audit-ready.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Policy conflict auto-resolved</h3>
<p class="text-body text-gosign-text mt-2">Internal travel policies and client-specific budgets often conflict. The AI Agent identifies both applicable policies per transaction. The rule engine enforces the stricter rule and documents which policy took precedence and why - no escalation needed for standard conflicts.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Entertainment costs by jurisdiction</h3>
<p class="text-body text-gosign-text mt-2">Germany: 70% deductible. Austria: 50%. Switzerland: fully deductible if documented. (UK: entertainment of clients is generally not deductible under HMRC rules.) The AI Agent classifies receipt type, country, and attendee count. The rule engine applies the correct deduction rate per jurisdiction - deterministically, for every receipt, without exception.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Client billing auto-documented</h3>
<p class="text-body text-gosign-text mt-2">200 consultants, 4 client trips per month each, 800 cases. The AI Agent checks 100% against client contract terms and generates audit-ready expense documentation per client. Systematic billing errors eliminated at the source - not discovered during quarterly reconciliation.</p>
</div>
</div>
</div>
</section>

<!-- Decision Flow -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">One consulting week. 20 to 60 micro-decisions.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">A consultant visits three clients in one week with business dinners and changing hotels. The Decision Layer decomposes this week into individual decision steps:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Step</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Decision</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Decider</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Rationale</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Map trip to client project</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">Calendar or CRM integration</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Determine per diem</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">Country-specific rate per jurisdiction</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Split hotel cost: billable vs. internal</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">Client contract terms determine split</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Check client-specific travel policy</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">Client economy-only vs. internal first-class</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Apply stricter policy</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">Whichever is more restrictive applies</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Tax treatment classification</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">Deductible, partially deductible, entertainment</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Multi-client day split</td><td class="py-3 px-4">AI + Rule engine</td><td class="py-3 px-4">AI determines time allocation, rules apply cost split</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">Generate client invoice backup</td><td class="py-3 px-4">Automatic</td><td class="py-3 px-4">Audit-ready expense documentation per client</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Classify entertainment expenses</td><td class="py-3 px-4">AI + Rule engine</td><td class="py-3 px-4">AI identifies receipt type, rule engine applies jurisdiction-specific deduction rates</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Generate audit file</td><td class="py-3 px-4">Automatic</td><td class="py-3 px-4">Sealed decision record per consulting week</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Simulation Results -->
<section id="simulation" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulation</p>
<h2 class="text-h1 font-bold text-white">Calculated for consulting volumes</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">We configured the Travel Decision Layer with realistic consulting parameters and ran the numbers. The results show what changes at enterprise volumes.</p>

<!-- Parameter table -->
<h3 class="text-h3 font-bold text-white mt-10 mb-4">Simulation parameters</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Consultants</td><td class="py-3 px-4">100 to 500+ (with client-specific policy rules)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Client contracts</td><td class="py-3 px-4">10 to 50+ parallel (each with own travel policies)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Cases/year</td><td class="py-3 px-4">50,000 to 250,000+</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Jurisdictions</td><td class="py-3 px-4">Multi-jurisdiction (DE, AT, CH, UK, further EU)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">System integration</td><td class="py-3 px-4">CRM/time tracking &rarr; Decision Layer &rarr; ERP/Payroll</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Entertainment share</td><td class="py-3 px-4">15 - 25% of all cases contain entertainment receipts</td></tr>
</tbody>
</table>
</div>

<!-- Before/After comparison -->
<h3 class="text-h3 font-bold text-white mt-10 mb-4">Before / After</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th class="text-left py-3 px-4 font-semibold text-white">Dimension</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manual</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Processing cost</td><td class="py-3 px-4">from EUR 53 (GBTA)*</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; EUR 9</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Error rate</td><td class="py-3 px-4">19% (GBTA)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 0.3%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Lead time</td><td class="py-3 px-4">5 - 12 business days</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Minutes</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Zero-touch rate</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">85%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Audit-readiness</td><td class="py-3 px-4">Manually reconstructed</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatically generated</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Split accuracy</td><td class="py-3 px-4">Manual estimate</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Deterministically calculated</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Client billing</td><td class="py-3 px-4">Manually assigned</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatically documented</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">* GBTA Foundation 2024: USD 58 per transaction (approx. EUR 53). Consulting cases with three-way split and multi-client logic are typically higher. Simulation results: Gosign model calculation.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">In the simulation, the Decision Layer achieves a zero-touch rate of 85% - for standard cases with clear client allocation. The remaining 15% involve multi-client days and edge cases requiring human judgement. For all cases, a complete, audit-proof decision record is available.</p>
</div>
</section>

<!-- Architecture Reference -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Architecture and implementation</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">The Travel Decision Layer runs entirely on your infrastructure: your data centre, your network, your sovereignty. No SaaS dependency, no data leakage. For consulting configurations, this means: multi-client capability with separate policy rulesets, integration with project management and time tracking systems, and automated three-way split. Typical pilot projects start within 3 months with one client pool.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/en/services/travel-decision-layer/#implementation" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Architecture, implementation and economic leverage in detail &rarr;</a>
<a href="/en/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Decision Layer Architecture &rarr;</a>
<a href="/en/services/infrastructure/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infrastructure details &rarr;</a>
<a href="/en/governance/co-determination/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Co-Determination &amp; Works Council &rarr;</a>
<a href="/en/governance/cert-ready/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready by Design &rarr;</a>
</div>
</div>
</section>

<!-- Deep Dive -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Deep Dive in the Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Our article series for decision-makers implementing AI agents in the enterprise.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/en/magazine/decision-layer-explained/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Foundations</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - What It Is and Why Every Enterprise AI Agent Needs One</p>
</a>
<a href="/en/magazine/agent-governance-hr/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Why HR Departments Need to Build Agent Governance Now</p>
</a>
<a href="/en/magazine/cert-ready-by-design/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Audit</p>
<p class="text-body font-semibold text-gosign-dark">Cert-Ready by Design - Audit-Proof AI from the Start</p>
</a>
</div>
</div>
</section>

<!-- Other Industries -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Travel Decision Layer in Other Industries</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Each industry has its own tariffs, cost structures, and complexity drivers. The Decision Layer is the same. The configuration is industry-specific.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/en/services/travel-decision-layer/aviation/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Aviation</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">Crew groups, collective agreements, IROP volatility</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">95% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Details &rarr;</span>
</div>
</a>
<a href="/en/services/travel-decision-layer/logistics/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Logistics</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">GPS, EU Mobility Package, zero-touch driver</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">95% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Details &rarr;</span>
</div>
</a>
<a href="/en/services/travel-decision-layer/sales/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Sales</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">500 field reps, CRM integration, entertainment</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">90% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Details &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- AI Travel Agent Logistics - Transport Costs ---
> Decision Layer for logistics travel expenses. GPS-based country detection, EU Mobility Package compliance, zero-touch driver mode.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/en/why-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Every decision traceable</p>
</div>
</a>
<a href="/en/why-gosign/#infrastructure" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Your infrastructure</p>
<p class="text-xs text-gosign-text-light">No SaaS. No vendor lock-in.</p>
</div>
</a>
<a href="/en/why-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">No US cloud risk</p>
</div>
</a>
</div>
</div>
</div>

<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Travel Decision Layer Industries">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/en/services/travel-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Travel Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/en/services/travel-decision-layer/aviation/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Aviation</a>
<a href="/en/services/travel-decision-layer/consulting/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Consulting</a>
<a href="/en/services/travel-decision-layer/logistics/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Logistics</a>
<a href="/en/services/travel-decision-layer/sales/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Sales</a>
</div>
</div>
</nav>

<!-- Why Logistics is unique -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<!-- Simulation stats as visual intro -->
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">500,000+</span>
<p class="text-small text-gosign-text-light mt-1">Cases/year (simulation)</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">95%</span>
<p class="text-small text-gosign-text-light mt-1">Zero-touch rate</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">30+</span>
<p class="text-small text-gosign-text-light mt-1">EU/EFTA + UK jurisdictions</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-border"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">High rule complexity</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">Cases and zero-touch: Gosign simulation model. Jurisdictions: EU/EFTA coverage. EU Mobility Package: Directive 2020/1057.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">What the Agent classifies</p>
<h2 class="text-h1 font-bold text-gosign-dark">30+ EU/EFTA + UK jurisdictions, one agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Border crossings multiple times daily, changing per diems, posting documentation. You know the complexity. Here's how the AI Agent solves it:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">GPS-based country assignment</h3>
<p class="text-body text-gosign-text mt-2">Drivers cross borders multiple times per day. The AI Agent reads GPS coordinates from telematics systems and classifies each segment to its jurisdiction. The rule engine then calculates country-specific per diems based on actual location and duration - no forms, no manual input, no delay.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">EU Mobility Package auto-documented</h3>
<p class="text-body text-gosign-text mt-2">Directive 2020/1057 requires posting documentation for cross-border operations. The AI Agent classifies country of operation and duration from GPS data. The rule engine generates the data basis that compliance teams need for reporting - automatically, for every trip, without creating additional burden for drivers. (UK: The EU Mobility Package does not apply post-Brexit. UK operator licensing and driver CPC regulations are mapped separately.)</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Fleet-wide consistency</h3>
<p class="text-body text-gosign-text mt-2">500 trucks cross the same borders daily. The AI Agent applies identical classification rules to identical routes. The rule engine calculates identical per diems for identical journeys - eliminating person-dependent variation across the entire fleet. Audit risk eliminated at the source.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Zero-touch driver mode</h3>
<p class="text-body text-gosign-text mt-2">The driver's job is driving, not administration. The AI Agent operates in zero-touch mode: GPS data in, country classification done, per diem calculation out, payroll export ready. The driver never sees a form. Queries only for genuine exceptions - GPS gaps, new routes, edge cases.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Minute-precise border crossing timing</h3>
<p class="text-body text-gosign-text mt-2">A truck crosses the German-Polish border at 23:45, continues to Czech Republic at 00:15. The AI Agent classifies three country segments with minute-level precision. The rule engine calculates pro-rata per diems based on actual crossing times - three countries, one working day, correct to the minute. Manual capture cannot achieve this precision.</p>
</div>
</div>
</div>
</section>

<!-- Decision Flow -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">One driver tour. 15 to 40 micro-decisions.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">A driver runs a three-country tour with an overnight stay. The Decision Layer decomposes this tour into individual decision steps:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Step</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Decision</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Decider</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Rationale</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Read GPS track from telematics</td><td class="py-3 px-4">Automatic</td><td class="py-3 px-4">Data import, no decision</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Determine country sequence and duration</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">GPS coordinates mapped to jurisdictions</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Select per diem per country</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">Country-specific rate per applicable framework</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Calculate midnight border crossing</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">Pro-rata calculation when crossing at midnight</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Check long-term posting threshold</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">Duration-based thresholds per jurisdiction</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Generate EU Mobility Package data</td><td class="py-3 px-4">Automatic</td><td class="py-3 px-4">Posting documentation data for compliance</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Map to fleet cost centre</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">Vehicle to fleet, fleet to cost centre</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">Generate payroll export</td><td class="py-3 px-4">Automatic</td><td class="py-3 px-4">Posting-ready per diem data</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Check rest time compliance</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">Driving and rest periods checked against EU Regulation 561/2006</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Generate audit file</td><td class="py-3 px-4">Automatic</td><td class="py-3 px-4">Sealed decision record per driver tour</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Simulation Results -->
<section id="simulation" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulation</p>
<h2 class="text-h1 font-bold text-white">Calculated for logistics volumes</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">We configured the Travel Decision Layer with realistic logistics parameters and ran the numbers. The results show what changes at enterprise fleet sizes.</p>

<!-- Parameter Table -->
<h3 class="text-h3 font-bold text-white mt-10 mb-4">Simulation parameters</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Fleet</td><td class="py-3 px-4">200 to 2,000+ vehicles (owned and subcontracted)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Drivers</td><td class="py-3 px-4">300 to 3,000+ (with various contract models)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Cases/year</td><td class="py-3 px-4">500,000 to 2,000,000+</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Jurisdictions</td><td class="py-3 px-4">30+ EU/EFTA + UK jurisdictions</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">System integration</td><td class="py-3 px-4">Telematics &rarr; Decision Layer &rarr; ERP/Payroll</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Border crossings/day</td><td class="py-3 px-4">500 to 5,000+ (fleet-dependent)</td></tr>
</tbody>
</table>
</div>

<!-- Before/After Comparison -->
<h3 class="text-h3 font-bold text-white mt-10 mb-4">Before / After</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th class="text-left py-3 px-4 font-semibold text-white">Dimension</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manual</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Processing cost</td><td class="py-3 px-4">from EUR 53 (GBTA)*</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; EUR 5</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Error rate</td><td class="py-3 px-4">19% (GBTA)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 0.1%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Lead time</td><td class="py-3 px-4">5 - 12 business days</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Minutes</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Zero-touch rate</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">95%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Audit-readiness</td><td class="py-3 px-4">Manually reconstructed</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatically generated</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">EU Mobility Package data</td><td class="py-3 px-4">Manually captured</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatically generated</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Driver queries</td><td class="py-3 px-4">3 - 5 per week</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 0.1 per week</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">* GBTA Foundation 2024: USD 58 per transaction (approx. EUR 53). Logistics cases with GPS-based country detection are significantly cheaper in zero-touch mode. EU Mobility Package: Directive 2020/1057. Simulation results: Gosign model calculation.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">In the simulation, the Decision Layer achieves a zero-touch rate of 95% - for standard routes with GPS coverage. The remaining 5% involve GPS gaps, new routes and edge cases. For all cases, a complete, audit-proof decision record is available. Drivers do not fill in forms.</p>
</div>
</section>

<!-- Architecture Reference -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Architecture and implementation</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">The Travel Decision Layer runs entirely on your infrastructure: your data centre, your network, your control. No SaaS dependency, no data leakage. For logistics configurations, this means: telematics interfaces for GPS data import, real-time border crossing processing, and fleet-wide per diem calculation across 30+ EU/EFTA + UK jurisdictions. Typical pilot projects start within 3 months with one fleet group and the most-travelled routes.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/en/services/travel-decision-layer/#implementation" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Architecture, implementation and economic leverage in detail &rarr;</a>
<a href="/en/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Decision Layer Architecture &rarr;</a>
<a href="/en/services/infrastructure/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infrastructure details &rarr;</a>
<a href="/en/governance/co-determination/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Co-Determination &amp; Works Council &rarr;</a>
<a href="/en/governance/cert-ready/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready by Design &rarr;</a>
</div>
</div>
</section>

<!-- Deep Dive -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Deep Dive in the Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Our article series for decision-makers implementing AI agents in the enterprise.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/en/magazine/decision-layer-explained/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Foundations</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - What It Is and Why Every Enterprise AI Agent Needs One</p>
</a>
<a href="/en/magazine/works-council-ai-co-determination/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Co-Determination</p>
<p class="text-body font-semibold text-gosign-dark">Works Council and AI, Co-Determination as Architecture Constraint</p>
</a>
<a href="/en/magazine/cert-ready-by-design/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Audit</p>
<p class="text-body font-semibold text-gosign-dark">Cert-Ready by Design - Audit-Proof AI from the Start</p>
</a>
</div>
</div>
</section>

<!-- Other Industries -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Travel Decision Layer in Other Industries</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Each industry has its own tariffs, cost structures, and complexity drivers. The Decision Layer is the same. The configuration is industry-specific.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/en/services/travel-decision-layer/aviation/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Aviation</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">Crew groups, collective agreements, IROP volatility</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">95% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Details &rarr;</span>
</div>
</a>
<a href="/en/services/travel-decision-layer/consulting/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Consulting</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">Client split, multi-cost centre, policy</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">85% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Details &rarr;</span>
</div>
</a>
<a href="/en/services/travel-decision-layer/sales/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Sales</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">500 field reps, CRM integration, entertainment</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">90% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Details &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- AI Travel Agent Sales - Field Service ---
> Decision Layer for sales travel expenses. CRM integration, policy enforcement at 10,000+ cases/month, weekly settlement. Audit-ready automation.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/en/why-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Every decision traceable</p>
</div>
</a>
<a href="/en/why-gosign/#infrastructure" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Your infrastructure</p>
<p class="text-xs text-gosign-text-light">No SaaS. No vendor lock-in.</p>
</div>
</a>
<a href="/en/why-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">No US cloud risk</p>
</div>
</a>
</div>
</div>
</div>

<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Travel Decision Layer Industries">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/en/services/travel-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Travel Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/en/services/travel-decision-layer/aviation/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Aviation</a>
<a href="/en/services/travel-decision-layer/consulting/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Consulting</a>
<a href="/en/services/travel-decision-layer/logistics/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Logistics</a>
<a href="/en/services/travel-decision-layer/sales/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Sales</a>
</div>
</div>
</nav>

<!-- Why sales volume needs governance -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<!-- Simulation stats as visual intro -->
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">120,000+</span>
<p class="text-small text-gosign-text-light mt-1">Cases/year (simulation)</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">90%</span>
<p class="text-small text-gosign-text-light mt-1">Zero-touch rate</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">100%</span>
<p class="text-small text-gosign-text-light mt-1">Policy check (not sampling)</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-border"></span><span class="w-4 h-2 rounded-sm bg-gosign-border"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">Moderate rule complexity, high volume</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">Cases and zero-touch: Gosign simulation model. Policy check: Decision Layer checks 100% of cases. Industry benchmarks: GBTA Foundation, 2015.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">What the Agent classifies</p>
<h2 class="text-h1 font-bold text-gosign-dark">10,000 transactions/month, one agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">500 field reps, daily client visits, changing policies. You know the complexity. Here's how the AI Agent solves it:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">100% policy check instead of 5% sampling</h3>
<p class="text-body text-gosign-text mt-2">500 field representatives, 20 expense reports per month each. The AI Agent checks every single transaction against the applicable policy ruleset. The rule engine flags violations immediately - not 5% sampling, but 100% enforcement. Systematic policy violations are caught at the source, not discovered during quarterly reconciliation.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">CRM linking automatic</h3>
<p class="text-body text-gosign-text mt-2">Every client visit has a business purpose. The AI Agent reads CRM data and matches calendar entries to travel expenses automatically - which client was visited, which opportunity, which revenue attribution. No manual entry, no missing business purpose, no orphaned expenses.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Weekly settlement instead of individual transactions</h3>
<p class="text-body text-gosign-text mt-2">Field representatives prefer weekly settlement over individual expense reports. The AI Agent batches all trips of a week, classifies each transaction. The rule engine calculates per diems and mileage, and generates a single weekly settlement per representative - one notification, one veto window, one payroll export.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Entertainment costs by jurisdiction</h3>
<p class="text-body text-gosign-text mt-2">Germany: 70% deductible. Austria: 50%. Switzerland: fully deductible if documented. (UK: entertainment of clients is generally not deductible under HMRC rules.) The AI Agent classifies every entertainment receipt by country, amount, attendee count and purpose. The rule engine applies the correct deduction rate per jurisdiction - deterministically, for every receipt, without exception.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Quarter-end in minutes</h3>
<p class="text-body text-gosign-text mt-2">10,000 transactions per month, all processed with audit-ready decision records. The AI Agent has already classified, the rule engine has already calculated, the audit trail is already complete. Quarter-end reporting is an export, not a research project. Weeks of manual reconciliation become minutes of data export.</p>
</div>
</div>
</div>
</section>

<!-- Decision Flow -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">One sales week. 30 to 80 micro-decisions.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">A field representative visits five clients in one week with hotel stays and business dinners. The Decision Layer decomposes this week into individual decision steps:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Step</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Decision</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Decider</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Rationale</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Link trip to CRM opportunity</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">Calendar + CRM data matching</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Determine per diem</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">Country and duration based</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Calculate mileage</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">Distance, vehicle type, rate</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Check entertainment policy</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">Amount, attendees, purpose</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Check hotel policy</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">Rate cap per city tier</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Batch into weekly settlement</td><td class="py-3 px-4">Automatic</td><td class="py-3 px-4">All trips of one week aggregated</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Map to cost centre and opportunity</td><td class="py-3 px-4">Rule engine</td><td class="py-3 px-4">Client, project, revenue attribution</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">Generate payroll export</td><td class="py-3 px-4">Automatic</td><td class="py-3 px-4">Weekly settlement posting</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Classify entertainment expenses</td><td class="py-3 px-4">AI + Rule engine</td><td class="py-3 px-4">AI identifies receipt type and attendees, rule engine applies deduction rates</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Generate audit file</td><td class="py-3 px-4">Automatic</td><td class="py-3 px-4">Sealed decision record per sales week</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Simulation Results -->
<section id="simulation" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulation</p>
<h2 class="text-h1 font-bold text-white">Calculated for sales volumes</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">We configured the Travel Decision Layer with realistic sales parameters and ran the numbers. The results show what changes at enterprise field service volumes.</p>

<!-- Parameter table -->
<h3 class="text-h3 font-bold text-white mt-10 mb-4">Simulation parameters</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Field representatives</td><td class="py-3 px-4">200 to 2,000+ (by region and seniority)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Cases/month</td><td class="py-3 px-4">10,000 to 50,000+</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Jurisdictions</td><td class="py-3 px-4">Multi-jurisdiction (DE, AT, CH, UK, further EU)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">System integration</td><td class="py-3 px-4">CRM &rarr; Decision Layer &rarr; ERP/Payroll</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Entertainment share</td><td class="py-3 px-4">20 - 30% of all cases contain entertainment receipts</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Policies</td><td class="py-3 px-4">3 - 10 parallel (by region, seniority, client class)</td></tr>
</tbody>
</table>
</div>

<!-- Before / After -->
<h3 class="text-h3 font-bold text-white mt-10 mb-4">Before / After</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th class="text-left py-3 px-4 font-semibold text-white">Dimension</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manual</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Processing cost</td><td class="py-3 px-4">from EUR 53 (GBTA)*</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; EUR 7</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Error rate</td><td class="py-3 px-4">19% (GBTA)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 0.5%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Lead time</td><td class="py-3 px-4">5 - 12 days</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Minutes</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Zero-touch rate</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">90%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Audit-readiness</td><td class="py-3 px-4">Manually reconstructed</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatically generated</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Policy check</td><td class="py-3 px-4">5 - 10% (sampling)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">100%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Weekly settlement</td><td class="py-3 px-4">Manually compiled</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatically aggregated</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">* GBTA Foundation 2024: USD 58 per transaction (approx. EUR 53). Sales cases with CRM integration and weekly batching are significantly cheaper in zero-touch mode. Simulation results: Gosign model calculation.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">In the simulation, the Decision Layer achieves a zero-touch rate of 90% - for standard cases with clear CRM linkage. The remaining 10% involve entertainment edge cases and missing CRM entries requiring human judgement. For all cases, a complete, audit-proof decision record is available. Weekly settlements replace the individual report cycle.</p>
</div>
</section>

<!-- Architecture Reference -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Architecture and implementation</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">The Travel Decision Layer runs entirely on your infrastructure: your data centre, your network, your control. No SaaS dependency, no data leakage. For sales configurations, this means: CRM interfaces for automatic trip-client linking, volume processing of 10,000+ transactions per month, and weekly settlement logic. Typical pilot projects start within 3 months with one sales region.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/en/services/travel-decision-layer/#implementation" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Architecture, implementation and economic leverage in detail &rarr;</a>
<a href="/en/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Decision Layer Architecture &rarr;</a>
<a href="/en/services/infrastructure/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infrastructure details &rarr;</a>
<a href="/en/governance/co-determination/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Co-Determination &amp; Works Council &rarr;</a>
<a href="/en/governance/cert-ready/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready by Design &rarr;</a>
</div>
</div>
</section>

<!-- Deep Dive -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Deep Dive in the Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Our article series for decision-makers implementing AI agents in the enterprise.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/en/magazine/decision-layer-explained/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Foundations</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - What It Is and Why Every Enterprise AI Agent Needs One</p>
</a>
<a href="/en/magazine/agent-governance-hr/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Why HR Departments Need to Build Agent Governance Now</p>
</a>
<a href="/en/magazine/eu-ai-act-hr/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Regulation</p>
<p class="text-body font-semibold text-gosign-dark">EU AI Act: What HR Departments Must Do Now</p>
</a>
</div>
</div>
</section>

<!-- Other Industries -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Travel Decision Layer in Other Industries</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Each industry has its own tariffs, cost structures, and complexity drivers. The Decision Layer is the same. The configuration is industry-specific.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/en/services/travel-decision-layer/aviation/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Aviation</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">Crew groups, collective agreements, IROP volatility</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">95% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Details &rarr;</span>
</div>
</a>
<a href="/en/services/travel-decision-layer/consulting/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Consulting</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">Client split, multi-cost centre, policy</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">85% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Details &rarr;</span>
</div>
</a>
<a href="/en/services/travel-decision-layer/logistics/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Logistics</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">GPS, EU Mobility Package, zero-touch driver</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">95% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Details &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- AI Travel Decision Layer - Travel Expense Governance ---
> The Decision Layer decomposes every travel expense into decision steps. Rule-based, auditable, 85-95% zero-touch across four industries.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/en/why-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Every decision traceable</p>
</div>
</a>
<a href="/en/why-gosign/#infrastructure" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Your infrastructure</p>
<p class="text-xs text-gosign-text-light">No SaaS. No vendor lock-in.</p>
</div>
</a>
<a href="/en/why-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">No US cloud risk</p>
</div>
</a>
</div>
</div>
</div>

<!-- Problem -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<!-- GBTA Benchmarks -->
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">EUR 53</span>
<p class="text-small text-gosign-text-light mt-1">per case, manual processing</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">19%</span>
<p class="text-small text-gosign-text-light mt-1">error rate in travel expense reports</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">EUR 48</span>
<p class="text-small text-gosign-text-light mt-1">correction cost per error</p>
</div>
<p class="sm:col-span-3 text-xs text-gosign-text-light">GBTA Foundation 2024: USD 58 per transaction (approx. EUR 53).</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">The Problem</p>
<h2 class="text-h1 font-bold text-gosign-dark">Why expense tools fail in complex organisations</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">SAP Concur, Circula, Moss, Spendesk. They all digitise the same manual process: capture receipts, fill out forms, obtain approvals. At EUR 53 per case and 19% error rate according to GBTA, that is expensive. But in organisations with collective agreements, international staff and dozens of legal jurisdictions, capture is not the problem. The decision is.</p>
<div class="mt-10">
<div class="grid grid-cols-1 md:grid-cols-3 gap-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">EUR 53 per case</h3>
<p class="text-body text-gosign-text-light mt-2">Expense tools digitise paper forms. The employee fills in, the manager approves, accounting reviews. Three manual steps, EUR 53 each (GBTA, 2024). At 100,000 cases per year, that is EUR 5.3 million in processing costs alone.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">19% error rate</h3>
<p class="text-body text-gosign-text-light mt-2">Country-specific per diems, posting rules, meal deductions, collective agreement overrides, tax exemption thresholds. No employee knows all the rules. No approver checks them. Result: one in five cases is incorrect. EUR 48 correction cost per error (GBTA, 2024).</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Zero audit readiness</h3>
<p class="text-body text-gosign-text-light mt-2">When the tax auditor arrives, the evidence is missing: which rule was applied? Why this per diem? Was the deduction correct? Expense tools document what was submitted. Not why it was decided that way.</p>
</div>
</div>
</div>
</div>
</section>

<!-- Decision Layer Principle -->
<section id="decision-layer" class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">The Decision Layer</p>
<h2 class="text-h1 font-bold text-gosign-dark">Every case. Decomposed into decision steps.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">The Travel Decision Layer works like every Gosign Decision Layer: it decomposes a process into individual decision steps and defines for each step who or what decides. Rule engine, collective agreement, or human. Not everything at once, but step by step, documented and traceable.</p>

<div class="mt-10">
<img src="/images/diagrams/travel-decision-flow-v2-en.svg" alt="Travel Decision Layer decision flow: data input, AI extraction, Decision Layer, result" width="1000" height="280" class="w-full" />
</div>

<p class="text-body text-gosign-text mt-8 max-w-narrow font-semibold">AI extracts and classifies. The Decision Layer decides. This separation is the reason the system is auditable, AI Act compliant and employee-representation compliant.</p>

<div class="mt-10">
<div class="grid grid-cols-1 md:grid-cols-2 gap-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Same input, same result</h3>
<p class="text-body text-gosign-text-light mt-2">Decision tables are versioned. Every case is checked against a defined rule version. The AI Agent classifies, the rule engine calculates reimbursement amounts, per diems, and tax allowances deterministically.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">40 to 120 individual decisions per case</h3>
<p class="text-body text-gosign-text-light mt-2">Not one big decision 'approved / rejected', but dozens of small ones: which per diem? Which deduction? Which collective agreement? Tax-exempt portion? Each individually documented.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Rule engine, collective agreement or human</h3>
<p class="text-body text-gosign-text-light mt-2">The Decision Layer does not decide everything itself. It knows which steps the rule engine covers, which are defined by collective agreements and where a human must intervene. The result: only genuine exceptions need human attention.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">The employee does not confirm. They can object.</h3>
<p class="text-body text-gosign-text-light mt-2">Traditional expense tools ask the employee to confirm their own expense report. The Decision Layer reverses this: processing happens automatically. The employee is informed and has a veto right.</p>
</div>
</div>
</div>
</div>
</section>

<!-- Governance & Audit -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<h2 class="text-h1 font-bold text-gosign-dark">Not documented after the fact. Created within the process.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">When the tax auditor asks "Why was 28 EUR applied instead of 14 EUR?", "the system calculated it" is not sufficient. The Travel Decision Layer generates a decision act for every micro-decision that answers exactly this question: which rule including version, which input, which result, when, by whom - including contestation path. This also turns the explanation of the individual decision under Art. 86 of the EU AI Act into a query instead of a forensics project.</p>

<!-- Audit Trail Card -->
<div class="mt-10 bg-gosign-dark rounded-card p-6 sm:p-8">
<div class="flex items-start gap-4 mb-6">
<svg class="w-8 h-8 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12h6m-6 4h6m2 5H7a2 2 0 01-2-2V5a2 2 0 012-2h5.586a1 1 0 01.707.293l5.414 5.414a1 1 0 01.293.707V19a2 2 0 01-2 2z" />
</svg>
<div>
<h3 class="text-h3 font-bold text-white">Every micro-decision generates an audit entry</h3>
<p class="text-small text-gosign-text-on-dark/70 mt-1">Append-only. Nothing is overwritten, nothing deleted. Corrections create reversal and adjustment entries. SHA-256 signed, exportable at any time.</p>
</div>
</div>
<div class="grid grid-cols-2 sm:grid-cols-3 gap-3 sm:gap-4">
<div class="flex items-center gap-2.5">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span class="text-small text-gosign-text-on-dark/80">Rule ID + Version</span>
</div>
<div class="flex items-center gap-2.5">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span class="text-small text-gosign-text-on-dark/80">Input data (what was available?)</span>
</div>
<div class="flex items-center gap-2.5">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span class="text-small text-gosign-text-on-dark/80">Result (what was decided?)</span>
</div>
<div class="flex items-center gap-2.5">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span class="text-small text-gosign-text-on-dark/80">Timestamp</span>
</div>
<div class="flex items-center gap-2.5">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span class="text-small text-gosign-text-on-dark/80">Actor (rule engine / collective agreement / human)</span>
</div>
<div class="flex items-center gap-2.5">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span class="text-small text-gosign-text-on-dark/80">Input hash (reproducible)</span>
</div>
</div>
</div>

<!-- Three Governance Pillars -->
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8">
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-3">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M15 12a3 3 0 11-6 0 3 3 0 016 0z" />
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M2.458 12C3.732 7.943 7.523 5 12 5c4.478 0 8.268 2.943 9.542 7-1.274 4.057-5.064 7-9.542 7-4.477 0-8.268-2.943-9.542-7z" />
</svg>
<div>
<h3 class="text-body font-semibold text-gosign-dark">Employee-representation compliant</h3>
<p class="text-small text-gosign-text-light mt-2">Rule set inspectable. Decisions traceable. Anomaly scoring controllable via feature flag. Reports pseudonymised. Compliance and performance architecturally separated.</p>
<a href="/en/governance/co-determination/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Co-determination &rarr;</a>
</div>
</div>
</div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-3">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12l2 2 4-4m5.618-4.016A11.955 11.955 0 0112 2.944a11.955 11.955 0 01-8.618 3.04A12.02 12.02 0 003 9c0 5.591 3.824 10.29 9 11.622 5.176-1.332 9-6.03 9-11.622 0-1.042-.133-2.052-.382-3.016z" />
</svg>
<div>
<h3 class="text-body font-semibold text-gosign-dark">Tax-audit ready</h3>
<p class="text-small text-gosign-text-light mt-2">Retention periods supported (10 years in Germany, varies by jurisdiction). Anonymisation instead of deletion for GDPR compatibility. Every case reproducible via input hash.</p>
<a href="/en/governance/cert-ready/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready &rarr;</a>
</div>
</div>
</div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-3">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 5H7a2 2 0 00-2 2v12a2 2 0 002 2h10a2 2 0 002-2V7a2 2 0 00-2-2h-2M9 5a2 2 0 002 2h2a2 2 0 002-2M9 5a2 2 0 012-2h2a2 2 0 012 2m-6 9l2 2 4-4" />
</svg>
<div>
<h3 class="text-body font-semibold text-gosign-dark">Systematic compliance</h3>
<p class="text-small text-gosign-text-light mt-2">Not a quarterly report, not a sampling check. Every single case is rule-checked. Deviations are flagged immediately, not discovered months later during reconciliation.</p>
</div>
</div>
</div>
</div>
</div>
</section>

<!-- Comparison Table -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="overflow-x-auto">
<table class="w-full text-small border-collapse">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Dimension</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Traditional Expense Tool</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-accent-text">Travel Decision Layer</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 font-medium text-gosign-dark">Decision model</td>
<td class="py-3 px-4 text-gosign-text-light">Human fills in, manager approves</td>
<td class="py-3 px-4 text-gosign-accent-text font-semibold">Decision Layer applies rules, human has veto</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 font-medium text-gosign-dark">Rule complexity</td>
<td class="py-3 px-4 text-gosign-text-light">Basic policies, no collective agreement logic</td>
<td class="py-3 px-4 text-gosign-accent-text font-semibold">Versioned decision tables: tax rules, per diems, collective agreements</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 font-medium text-gosign-dark">Audit trail</td>
<td class="py-3 px-4 text-gosign-text-light">Receipt stored, decision not documented</td>
<td class="py-3 px-4 text-gosign-accent-text font-semibold">Every micro-decision documented: rule, input, result, timestamp</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 font-medium text-gosign-dark">Tax audit</td>
<td class="py-3 px-4 text-gosign-text-light">Manual reconstruction from files</td>
<td class="py-3 px-4 text-gosign-accent-text font-semibold">Export: sealed audit pack per case, reproducible via input hash</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 font-medium text-gosign-dark">Employee experience</td>
<td class="py-3 px-4 text-gosign-text-light">Form, upload, wait for approval</td>
<td class="py-3 px-4 text-gosign-accent-text font-semibold">Automatic processing, notification, veto option</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 font-medium text-gosign-dark">Scalability</td>
<td class="py-3 px-4 text-gosign-text-light">Linear: more cases = more reviewers</td>
<td class="py-3 px-4 text-gosign-accent-text font-semibold">Constant: 100 or 100,000 cases, same rule engine</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 font-medium text-gosign-dark">Works council / employee representation</td>
<td class="py-3 px-4 text-gosign-text-light">Opaque, difficult to audit</td>
<td class="py-3 px-4 text-gosign-accent-text font-semibold">Rule set inspectable, anomaly scoring controllable via feature flag, reports pseudonymised</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Industry Simulations -->
<section id="simulationen" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulated for enterprise volumes</p>
<h2 class="text-h1 font-bold text-white">Four industries. Calculated.</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">We configured the Travel Decision Layer for four industries with realistic volumes and calculated the results. Each card shows the simulation parameters and outcome.</p>

<div class="grid grid-cols-1 md:grid-cols-2 gap-6 mt-10">
<!-- Aviation -->
<a href="/en/services/travel-decision-layer/aviation/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors">
<div class="flex items-center justify-between mb-4">
<h3 class="text-h3 font-bold text-white">Aviation</h3>
<div class="flex gap-1">
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
</div>
</div>
<ul class="space-y-1.5 text-small text-gosign-text-on-dark/70">
<li>Tens of thousands of crew, multiple staff groups</li>
<li>Multiple parallel collective agreements per carrier</li>
<li>100,000 to 1,000,000+ cases/year</li>
<li>Multi-carrier, multi-jurisdiction</li>
</ul>
<div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between">
<span class="text-h3 font-bold text-gosign-accent-on-dark">95% Zero-Touch</span>
<span class="text-small text-gosign-accent-on-dark font-semibold">Aviation in detail &rarr;</span>
</div>
</a>

<!-- Consulting -->
<a href="/en/services/travel-decision-layer/consulting/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors">
<div class="flex items-center justify-between mb-4">
<h3 class="text-h3 font-bold text-white">Consulting</h3>
<div class="flex gap-1">
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-white/20"></span>
</div>
</div>
<ul class="space-y-1.5 text-small text-gosign-text-on-dark/70">
<li>8,000+ consultants, 15+ jurisdictions</li>
<li>Three-way split: tax / client / internal</li>
<li>Multi-client weeks, daily-changing cost centres</li>
</ul>
<div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between">
<span class="text-h3 font-bold text-gosign-accent-on-dark">85% Zero-Touch</span>
<span class="text-small text-gosign-accent-on-dark font-semibold">Consulting in detail &rarr;</span>
</div>
</a>

<!-- Logistics -->
<a href="/en/services/travel-decision-layer/logistics/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors">
<div class="flex items-center justify-between mb-4">
<h3 class="text-h3 font-bold text-white">Logistics</h3>
<div class="flex gap-1">
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-white/20"></span>
</div>
</div>
<ul class="space-y-1.5 text-small text-gosign-text-on-dark/70">
<li>20,000+ drivers, EU Mobility Package</li>
<li>GPS-based country detection</li>
<li>Fleet-based driver per diems</li>
</ul>
<div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between">
<span class="text-h3 font-bold text-gosign-accent-on-dark">95% Zero-Touch</span>
<span class="text-small text-gosign-accent-on-dark font-semibold">Logistics in detail &rarr;</span>
</div>
</a>

<!-- Sales -->
<a href="/en/services/travel-decision-layer/sales/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors">
<div class="flex items-center justify-between mb-4">
<h3 class="text-h3 font-bold text-white">Sales</h3>
<div class="flex gap-1">
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-white/20"></span><span class="w-3 h-1.5 rounded-sm bg-white/20"></span>
</div>
</div>
<ul class="space-y-1.5 text-small text-gosign-text-on-dark/70">
<li>5,000+ field staff, CRM integration</li>
<li>10,000+ cases per month</li>
<li>Policy enforcement at scale</li>
</ul>
<div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between">
<span class="text-h3 font-bold text-gosign-accent-on-dark">90% Zero-Touch</span>
<span class="text-small text-gosign-accent-on-dark font-semibold">Sales in detail &rarr;</span>
</div>
</a>
</div>
</div>
</section>

<!-- Architecture, Implementation & Leverage -->
<section id="implementation" class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Implementation</p>
<h2 class="text-h1 font-bold text-gosign-dark">From pilot to running system.</h2>

<div class="grid grid-cols-1 lg:grid-cols-2 gap-10 mt-10">
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Technical Architecture</h3>
<p class="text-body text-gosign-text">The Travel Decision Layer runs entirely within your infrastructure: your data centre, your network, your control. No SaaS dependency, no data leakage, no external telemetry tracking. Containerised, multi-tenant, deployment-ready for your private cloud or as managed deployment in EU data centres. (US: US-based hosting is configurable for US-only deployments.)</p>
<div class="flex flex-wrap gap-4 mt-3">
<a href="/en/services/infrastructure/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infrastructure details &rarr;</a>
<a href="/en/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Decision Layer Architecture &rarr;</a>
</div>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Implementation</h3>
<p class="text-body text-gosign-text">The Decision Layer is not installed but configured: your collective agreements, your policies, your system landscape. Typical pilot projects start within 3 months with one industry and one collective agreement. Extensions to additional staff groups or system connections run in parallel with pilot operations.</p>
</div>
</div>

<h3 class="text-h3 font-bold text-gosign-dark mt-12 mb-6">Economic Leverage</h3>
<div class="grid grid-cols-1 sm:grid-cols-2 gap-6">
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-4">
<svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12l2 2 4-4m5.618-4.016A11.955 11.955 0 0112 2.944a11.955 11.955 0 01-8.618 3.04A12.02 12.02 0 003 9c0 5.591 3.824 10.29 9 11.622 5.176-1.332 9-6.03 9-11.622 0-1.042-.133-2.052-.382-3.016z" />
</svg>
<div>
<p class="text-body font-semibold text-gosign-dark">Systematic rule checking instead of sampling</p>
<p class="text-small text-gosign-text-light mt-2">Every case goes through the same rule engine. Deviations are flagged and documented, not discovered during quarterly reconciliation.</p>
</div>
</div>
</div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-4">
<svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M13 10V3L4 14h7v7l9-11h-7z" />
</svg>
<div>
<p class="text-body font-semibold text-gosign-dark">No approval workflows for standard cases</p>
<p class="text-small text-gosign-text-light mt-2">Throughput time from days to minutes. Managers only approve exceptions.</p>
</div>
</div>
</div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-4">
<svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M4 6a2 2 0 012-2h2a2 2 0 012 2v2a2 2 0 01-2 2H6a2 2 0 01-2-2V6zm10 0a2 2 0 012-2h2a2 2 0 012 2v2a2 2 0 01-2 2h-2a2 2 0 01-2-2V6zM4 16a2 2 0 012-2h2a2 2 0 012 2v2a2 2 0 01-2 2H6a2 2 0 01-2-2v-2zm10 0a2 2 0 012-2h2a2 2 0 012 2v2a2 2 0 01-2 2h-2a2 2 0 01-2-2v-2z" />
</svg>
<div>
<p class="text-body font-semibold text-gosign-dark">Automatic cost centre and project assignment</p>
<p class="text-small text-gosign-text-light mt-2">No manual mapping for thousands of cases. No month-end bottleneck.</p>
</div>
</div>
</div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-4">
<svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12h6m-6 4h6m2 5H7a2 2 0 01-2-2V5a2 2 0 012-2h5.586a1 1 0 01.707.293l5.414 5.414a1 1 0 01.293.707V19a2 2 0 01-2 2z" />
</svg>
<div>
<p class="text-body font-semibold text-gosign-dark">Audit-proof decision records created within the process</p>
<p class="text-small text-gosign-text-light mt-2">Tax audit is an export, not a research project. Weeks become minutes.</p>
</div>
</div>
</div>
</div>
</div>
</section>

<!-- Compliance & Security -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Security</p>
<h2 class="text-h1 font-bold text-gosign-dark">Enterprise security. From day one.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Not retrofitted as a feature, but built as an architecture principle. The Travel Decision Layer is designed for regulated environments where data protection, audit readiness and traceability are not optional extras.</p>
<div class="mt-10">
<div class="grid grid-cols-1 md:grid-cols-3 gap-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">100% customer infrastructure</h3>
<p class="text-body text-gosign-text-light mt-2">The Decision Layer runs entirely within your network. No SaaS dependency, no data leakage, no external telemetry tracking. Secrets in your KMS, logs in your SIEM, SSO via your identity provider. (US: US-based hosting is configurable for US-only deployments.)</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">GDPR by Design</h3>
<p class="text-body text-gosign-text-light mt-2">Anonymisation instead of deletion. Compatible with tax retention periods and GDPR Art. 17. No conflict between tax law and data protection. (UK: UK GDPR provisions apply equivalently post-Brexit.)</p>
<a href="/en/governance/data-residency/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover mt-3 inline-block whitespace-nowrap">Data residency in detail</a>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">AI Act compliant</h3>
<p class="text-body text-gosign-text-light mt-2">Clear architecture separation: LLM for data extraction, Decision Layer for decisions. No black box over tax matters. Every decision reconstructable.</p>
<a href="/en/governance/eu-ai-act/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover mt-3 inline-block whitespace-nowrap">EU AI Act Readiness</a>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Audit Trail (append-only)</h3>
<p class="text-body text-gosign-text-light mt-2">Signed decision records. Input hash plus rule version yields reproducible result. Sealed audit packs (JSON + PDF, SHA-256). Tax audit ready at any time.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">ISO 27001 / SOC 2 cert-ready</h3>
<p class="text-body text-gosign-text-light mt-2">Integrated controls registry, automated evidence runs, versioned policies. Compliance in running operations, not documented after the fact.</p>
<a href="/en/governance/cert-ready/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover mt-3 inline-block whitespace-nowrap">Cert-Ready by Design</a>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">SSO and tenant isolation</h3>
<p class="text-body text-gosign-text-light mt-2">Integration with existing identity providers. Tenant isolation at database level (row-level security). Role model granularly configurable.</p>
</div>
</div>
</div>
</div>
</section>

<!-- Deep Dive -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Deep Dive in the Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Our article series for decision-makers implementing AI agents in the enterprise.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/en/magazine/decision-layer-explained/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Foundations</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - What It Is and Why Every Enterprise AI Agent Needs One</p>
</a>
<a href="/en/magazine/works-council-ai-co-determination/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Co-Determination</p>
<p class="text-body font-semibold text-gosign-dark">Works Council and AI - Co-Determination as Architecture Constraint</p>
</a>
<a href="/en/magazine/cert-ready-by-design/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Audit</p>
<p class="text-body font-semibold text-gosign-dark">Cert-Ready by Design - Audit-Proof AI from the Start</p>
</a>
<a href="/en/magazine/decision-act-contestable-ai-decisions/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">The Decision Act - Why Every AI Decision Must Be Contestable</p>
</a>
</div>
</div>
</section>

--- Services ---
> AI Agents, Finance Agents, HR Agents, AI Infrastructure, Document Intelligence, and eIDAS-compliant digital signatures.

<!-- What We Build -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">What We Build</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Gosign develops and operates AI agent infrastructure for enterprises. We build the layer between language model and enterprise system - including orchestration, governance, and audit.
</p>
</div>
</div>
</section>

<!-- Service Cards -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-1 lg:grid-cols-3 gap-6 lg:gap-8">
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9.813 15.904L9 18.75l-.813-2.846a4.5 4.5 0 00-3.09-3.09L2.25 12l2.846-.813a4.5 4.5 0 003.09-3.09L9 5.25l.813 2.846a4.5 4.5 0 003.09 3.09L15.75 12l-2.846.813a4.5 4.5 0 00-3.09 3.09zM18.259 8.715L18 9.75l-.259-1.035a3.375 3.375 0 00-2.455-2.456L14.25 6l1.036-.259a3.375 3.375 0 002.455-2.456L18 2.25l.259 1.035a3.375 3.375 0 002.455 2.456L21.75 6l-1.036.259a3.375 3.375 0 00-2.455 2.456zM16.894 20.567L16.5 21.75l-.394-1.183a2.25 2.25 0 00-1.423-1.423L13.5 18.75l1.183-.394a2.25 2.25 0 001.423-1.423l.394-1.183.394 1.183a2.25 2.25 0 001.423 1.423l1.183.394-1.183.394a2.25 2.25 0 00-1.423 1.423z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">AI Agents</h3>
<p class="text-body text-gosign-text-light mt-3">Document Agents, Workflow Agents, Knowledge Agents. Specialized AI agents with <a href='/en/decision-layer/' class='text-gosign-accent-text hover:underline'>Decision Layer</a>, audit trail, and Human-in-the-Loop. Every agent operates within governance.</p>
<a href="/en/services/ai-agents/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">AI Agents in detail<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg></a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 18.75a60.07 60.07 0 0115.797 2.101c.727.198 1.453-.342 1.453-1.096V18.75M3.75 4.5v.75A.75.75 0 013 6h-.75m0 0v-.375c0-.621.504-1.125 1.125-1.125H20.25M2.25 6v9m18-10.5v.75c0 .414.336.75.75.75h.75m-1.5-1.5h.375c.621 0 1.125.504 1.125 1.125v9.75c0 .621-.504 1.125-1.125 1.125h-.375m1.5-1.5H21a.75.75 0 00-.75.75v.75m0 0H3.75m0 0h-.375a1.125 1.125 0 01-1.125-1.125V15m1.5 1.5v-.75A.75.75 0 003 15h-.75M15 10.5a3 3 0 11-6 0 3 3 0 016 0zm3 0h.008v.008H18V10.5zm-12 0h.008v.008H6V10.5z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Finance Agents</h3>
<p class="text-body text-gosign-text-light mt-3">Decision automation for document processing and bookkeeping. The agent extracts, classifies, and decides - based on versioned rule sets. Cert-Ready by Design. DATEV and SAP integration.</p>
<a href="/en/finance-ai-agents/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">Finance Agents<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg></a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M15 19.128a9.38 9.38 0 002.625.372 9.337 9.337 0 004.121-.952 4.125 4.125 0 00-7.533-2.493M15 19.128v-.003c0-1.113-.285-2.16-.786-3.07M15 19.128v.106A12.318 12.318 0 018.624 21c-2.331 0-4.512-.645-6.374-1.766l-.001-.109a6.375 6.375 0 0111.964-3.07M12 6.375a3.375 3.375 0 11-6.75 0 3.375 3.375 0 016.75 0zm8.25 2.25a2.625 2.625 0 11-5.25 0 2.625 2.625 0 015.25 0z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">HR Agents</h3>
<p class="text-body text-gosign-text-light mt-3">Enterprise AI agents for consistent, traceable, audit-proof HR decisions. Compliant with employee representation requirements. Decision Layer with Human-in-the-Loop. In the client's infrastructure.</p>
<a href="/en/hr-ai-agents/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">HR Agents<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg></a>
</article>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-1 lg:grid-cols-3 gap-6 lg:gap-8">
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M5.25 14.25h13.5m-13.5 0a3 3 0 01-3-3m3 3a3 3 0 100 6h13.5a3 3 0 100-6m-16.5-3a3 3 0 013-3h13.5a3 3 0 013 3m-19.5 0a4.5 4.5 0 01.9-2.7L5.737 5.1a3.375 3.375 0 012.7-1.35h7.126c1.062 0 2.062.5 2.7 1.35l2.587 3.45a4.5 4.5 0 01.9 2.7m0 0a3 3 0 01-3 3m0 3h.008v.008h-.008v-.008zm0-6h.008v.008h-.008v-.008zm-3 6h.008v.008h-.008v-.008zm0-6h.008v.008h-.008v-.008z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">AI Infrastructure</h3>
<p class="text-body text-gosign-text-light mt-3">LLM hosting, RAG, orchestration, self-hosted. The infrastructure on which AI agents run in production. Model-agnostic, deployment-flexible, governance-ready.</p>
<a href="/en/services/infrastructure/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">AI Infrastructure<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg></a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M19.5 14.25v-2.625a3.375 3.375 0 00-3.375-3.375h-1.5A1.125 1.125 0 0113.5 7.125v-1.5a3.375 3.375 0 00-3.375-3.375H8.25m0 12.75h7.5m-7.5 3H12M10.5 2.25H5.625c-.621 0-1.125.504-1.125 1.125v17.25c0 .621.504 1.125 1.125 1.125h12.75c.621 0 1.125-.504 1.125-1.125V11.25a9 9 0 00-9-9z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Document Intelligence</h3>
<p class="text-body text-gosign-text-light mt-3">Document understanding beyond OCR. Classification, extraction, validation - powered by LLM, governed by the Decision Layer. For invoices, contracts, certificates, and unstructured documents.</p>
<a href="/en/services/document-intelligence/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">Document Intelligence<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg></a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 6.75V15m6-6v8.25m.503 3.498l4.875-2.437c.381-.19.622-.58.622-1.006V4.82c0-.836-.88-1.38-1.628-1.006l-3.869 1.934c-.317.159-.69.159-1.006 0L9.503 3.252a1.125 1.125 0 00-1.006 0L3.622 5.689C3.24 5.88 3 6.27 3 6.695V19.18c0 .836.88 1.38 1.628 1.006l3.869-1.934c.317-.159.69-.159 1.006 0l4.994 2.497c.317.158.69.158 1.006 0z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Travel Decision Layer</h3>
<p class="text-body text-gosign-text-light mt-3">AI-powered travel expense governance. The Decision Layer decomposes every travel expense case into decision steps and applies tax rules, per diems and collective agreements deterministically. Configurable for aviation, consulting, logistics and sales.</p>
<a href="/en/services/travel-decision-layer/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">Travel Decision Layer<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg></a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M17.25 6.75L22.5 12l-5.25 5.25m-10.5 0L1.5 12l5.25-5.25m7.5-3l-4.5 16.5" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Enterprise Software Engineering</h3>
<p class="text-body text-gosign-text-light mt-3">Since 2001. Over 5,000 projects for Airbus, Volkswagen, Shell. Today AI infrastructure - built on the same engineering foundation. TDD, continuous pair programming, CI/CD, Security by Design.</p>
<a href="/en/services/software-engineering/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">Software Engineering<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg></a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M16.5 10.5V6.75a4.5 4.5 0 10-9 0v3.75m-.75 11.25h10.5a2.25 2.25 0 002.25-2.25v-6.75a2.25 2.25 0 00-2.25-2.25H6.75a2.25 2.25 0 00-2.25 2.25v6.75a2.25 2.25 0 002.25 2.25z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">eIDAS-Compliant Digital Signatures</h3>
<p class="text-body text-gosign-text-light mt-3">In cooperation with ETSI-certified partners. eIDAS-compliant digital signature solutions for enterprise clients. Simple, advanced (AES), and qualified (QES) electronic signatures.</p>
<a href="/en/services/eidas-signatures/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">eIDAS Signatures<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg></a>
</article>
</div>
</div>
</section>

<!-- How We Work -->

<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark text-center">How We Work</h2>
<div class="mt-12 grid grid-cols-1 md:grid-cols-3 gap-8 relative">
<div class="text-center">
<div class="w-14 h-14 mx-auto rounded-full bg-gosign-accent flex items-center justify-center">
<span class="text-h3 font-bold text-white">1</span>
</div>
<h3 class="text-h3 font-bold text-gosign-dark mt-4">Discover</h3>
<p class="text-small font-semibold text-gosign-accent-text mt-1">1 week</p>
<p class="text-body text-gosign-text-light mt-2">Process analysis, understand rule sets, prioritize use cases.</p>
</div>
<div class="text-center">
<div class="w-14 h-14 mx-auto rounded-full bg-gosign-accent flex items-center justify-center">
<span class="text-h3 font-bold text-white">2</span>
</div>
<h3 class="text-h3 font-bold text-gosign-dark mt-4">Build</h3>
<p class="text-small font-semibold text-gosign-accent-text mt-1">3-4 weeks</p>
<p class="text-body text-gosign-text-light mt-2">Productive PoC. One agent, one process, live in your infrastructure.</p>
</div>
<div class="text-center">
<div class="w-14 h-14 mx-auto rounded-full bg-gosign-accent flex items-center justify-center">
<span class="text-h3 font-bold text-white">3</span>
</div>
<h3 class="text-h3 font-bold text-gosign-dark mt-4">Scale</h3>
<p class="text-small font-semibold text-gosign-accent-text mt-1">Continuous</p>
<p class="text-body text-gosign-text-light mt-2">More agents, more processes. Same governance, same auditability.</p>
</div>
</div>
<p class="text-body-lg text-center text-gosign-text-light mt-8 max-w-narrow mx-auto">After 12-18 months, you operate your agents independently. Full access to source code, prompts, and rule sets. No vendor lock-in.</p>
</div>
</section>


<!-- Deep Dive -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Deep Dive in the Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Our article series for decision-makers implementing AI agents in the enterprise.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/en/magazine/what-are-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">AI Agents</p>
<p class="text-body font-semibold text-gosign-dark">What Are AI Agents? Document Agents, Workflow Agents, Knowledge Agents Explained</p>
</a>
<a href="/en/magazine/decision-layer-explained/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - What It Is and Why Every Enterprise AI Agent Needs One</p>
</a>
<a href="/en/magazine/why-ai-projects-fail/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Strategy</p>
<p class="text-body font-semibold text-gosign-dark">Why AI Projects in HR Fail</p>
</a>
</div>
</div>
</section>

--- General Terms and Conditions - Gosign GmbH ---
> GTC of Gosign GmbH for AI infrastructure, agent development and software development. Version 3.1.

<h1>General Terms and Conditions</h1>
<p class="text-sm bg-gosign-light border border-gosign-border rounded-card p-3 mt-2">
<strong>Note:</strong> This is a convenience translation. The German version is legally binding. In case of discrepancies, the German version shall prevail.
<a href="/de/agb/" class="text-gosign-accent-text hover:text-gosign-accent-hover ml-1">&rarr; Deutsche Fassung</a>
</p>
<p class="text-lg text-gosign-text-light">
Gosign GmbH - AI Infrastructure, Agent Development & Software Development<br/>
Version 3.1 - As of: March 2026
</p>
<p class="text-sm text-gosign-text-light mt-2">
<a href="/documents/gosign-agb-v3.1.pdf" target="_blank" rel="noopener noreferrer"
class="text-gosign-accent-text hover:text-gosign-accent-hover">&darr; Download as PDF</a>
</p>

<h2>&sect; 1 Scope and Subject Matter</h2>
<p>These General Terms and Conditions (GTC) apply to all contracts between Gosign GmbH (hereinafter "Gosign") and its clients regarding the following service areas:</p>
<p><strong>AI Enterprise Infrastructure & Agent Development:</strong> Services related to artificial intelligence in the enterprise environment, including planning and implementation of AI infrastructure, development of AI agents, integration of AI models, self-hosting solutions, FinOps strategies for cost optimization of AI workloads, and related consulting and development services.</p>
<p><strong>Decision Layer & Governance Architecture:</strong> Development and implementation of a governance and control layer (Decision Layer) between AI agents and enterprise target systems, including rule-based decision control, Audit Trail documentation, Human-in-the-Loop architecture, and automated compliance evidence (Cert-Ready).</p>
<p><strong>Software Development:</strong> Development of custom software solutions, web applications, and integrations, including the use of open-source frameworks and libraries. This encompasses conception, design, development, customization, integration, and documentation.</p>
<p><strong>Hosting and Operations (optional):</strong> Hosting services and operational support optionally offered by Gosign. Regular operations of the solutions developed by Gosign are generally conducted within the client's infrastructure. Hosting by Gosign is an additional service that is separately agreed upon.</p>
<p><strong>Enablement and Knowledge Transfer:</strong> Gosign pursues the objective of enabling the client to independently operate and further develop the provided solutions. Where agreed, the scope of services includes training, documentation, and a structured knowledge transfer designed to systematically reduce the client's dependency on Gosign.</p>
<p><strong>Scope Limitation:</strong> Gosign provides technical services. The solutions developed by Gosign do not replace legal, tax, or HR advisory services. Substantive final decisions remain with the client. The client's systems (e.g., SAP, Workday, SuccessFactors, DATEV) remain the system of record; Gosign solutions integrate with these systems but do not replace them.</p>
<p><strong>Client Base:</strong> These GTC are directed exclusively at entrepreneurs within the meaning of &sect; 14 BGB (German Civil Code). For clients domiciled in the EU/EEA, these GTC apply directly. For clients outside the EU/EEA, they apply provided that the applicability of German law has been agreed. Gosign does not offer contracts to consumers.</p>
<p>Individual agreements and SLAs take precedence over these GTC. Deviating terms and conditions of the client shall not apply unless Gosign has expressly agreed to their applicability in writing.</p>

<h2>&sect; 2 Definitions</h2>
<p>The following terms are used in these GTC as defined below:</p>
<p><strong>"Agent"</strong> means a software component that automatically executes or prepares tasks on behalf of the client based on AI models and rule sets (e.g., Document Agent, Workflow Agent, Knowledge Agent).</p>
<p><strong>"Audit Trail"</strong> means the complete, chronological record of all Decision Records and events in the system.</p>
<p><strong>"Auditor Portal"</strong> means a web-based interface through which authorized auditors (internal or external) can view the live status of all Controls and Evidence.</p>
<p><strong>"Cert-Ready"</strong> means the property of a system architecture to meet the technical prerequisites for industry-standard certifications (e.g., ISO 27001, SOC 2, IDW PS 951) - without thereby owing or guaranteeing the certification itself.</p>
<p><strong>"Component Manifest"</strong> means the overview appended to the proposal that assigns each material software component either as a client-specific work product (&sect; 7.1) or as a Platform Component (&sect; 7.2). Details are governed by &sect; 7.2 para. 4.</p>
<p><strong>"Control"</strong> means a technically implemented verification rule that ensures compliance with a specific compliance or governance standard (e.g., "No salary decision without four-eyes principle").</p>
<p><strong>"Decision Layer"</strong> means the governance and control layer developed by Gosign that decomposes business processes into individual decisions and determines for each step whether a human decides, a rule set applies, or the AI acts autonomously.</p>
<p><strong>"Decision Record"</strong> means the automatic, immutable documentation of a single decision within the Decision Layer, consisting of input data, applied rule/model version, confidence score, decision path, and result.</p>
<p><strong>"Evidence"</strong> means an automatically generated proof that a Control was satisfied at a specific point in time.</p>
<p><strong>"Human-in-the-Loop"</strong> means an architectural principle where certain decisions require human approval before execution. The classification of which decisions require human approval is jointly determined with the client during the project.</p>
<p><strong>"Maintenance"</strong> means the optional annual maintenance contract for Platform Components, covering ongoing maintenance, security updates, and further development. Details are governed by &sect; 7.7.</p>
<p><strong>"Perpetual License"</strong> means the client's permanent right to use the respective delivered version of the Platform Components pursuant to &sect; 7.2 para. 2. The right of use exists regardless of whether a maintenance contract is in place.</p>
<p><strong>"Platform Components" (Plattform-Komponenten)</strong> means the reusable technical core of Gosign solutions, in particular the Decision Engine, the Rules Engine Framework, the Audit Trail architecture, and orchestration modules. Details are governed by &sect; 7.2 para. 1.</p>
<p><strong>"Source Code Transfer" (Quellcode-Transfer)</strong> means the transfer of the exclusive right of use to the software components individually developed for the client, including source code, prompts, rule sets, configurations, and documentation.</p>
<p><strong>"Software Bill of Materials (SBOM)"</strong> means the overview of all open-source components used in the solution and their licenses pursuant to &sect; 7.4.</p>
<p><strong>"System of Record"</strong> means the client's leading system for master and transactional data (e.g., SAP, Workday, SuccessFactors, DATEV). Gosign solutions integrate with the System of Record but do not replace it.</p>
<p><strong>"Permitted Third Parties" (Zulässige Dritte)</strong> means the recipients exhaustively listed in &sect; 7.1 para. 3 to whom the client may transfer work products and Platform Components without separate consent from Gosign.</p>

<h2>&sect; 3 Conclusion of Contract</h2>
<p><strong>Proposal and Order:</strong> The presentation of services by Gosign does not generally constitute a binding offer. The contract is concluded upon the client's order and acceptance by Gosign within 14 calendar days.</p>
<p>A contract is only formed when Gosign confirms the order in text form or commences execution.</p>
<p><strong>Framework Agreement and Service Phases:</strong> The contract may be concluded as a framework agreement with individually commissioned service phases. Each phase may be commissioned separately without obligation to commission subsequent phases.</p>
<p><strong>Contract Types per Phase:</strong> Discovery phases (analysis, consulting, process documentation) are performed as service contracts (Dienstvertrag); what is owed is the advisory service, not a specific result. Build phases (development, implementation, proof of concept) are performed as contracts for work and services (Werkvertrag) with acceptance, unless otherwise agreed. Scale and Support phases are performed as service contracts; optional Service Level Agreements (SLA) apply supplementarily.</p>
<p>Contracts may be concluded in writing, electronically, or in text form. Gosign stores the contract text and these GTC.</p>

<h2>&sect; 4 Services by Gosign</h2>
<p>Gosign performs the contractually agreed services professionally and with the diligence of a prudent businessperson (Sorgfalt eines ordentlichen Kaufmanns). Gosign is entitled to employ qualified staff, vicarious agents, or subcontractors.</p>
<p><strong>Place of Performance:</strong> Services are generally provided remotely. Gosign employs staff at various locations and ensures compliance with the agreed security and data protection standards regardless of the place of performance. On-site deployments are separately agreed.</p>
<p><strong>Project Coordination:</strong> Both parties designate contact persons. Gosign provides regular updates on project progress.</p>
<p><strong>Deadlines and Time Limits:</strong> Deadlines and time limits are only binding if expressly agreed as such. In the event of delays not attributable to Gosign, deadlines shall be reasonably extended.</p>
<p><strong>Change Requests:</strong> Changes to the scope of services require a written agreement on additional costs and timelines.</p>
<p><strong>Proof of Concept (PoC):</strong> Where a PoC is agreed, the success criteria defined in the proposal shall apply. A PoC serves to validate technical feasibility. The work products created during the PoC become the property of the client upon full payment, unless otherwise agreed.</p>
<p><strong>Partial Deliveries:</strong> Gosign is entitled to provide reasonable partial deliveries.</p>
<h3>4.1 Acceptance of Work Products</h3>
<p>The client shall review work products within 14 calendar days and either declare acceptance or report defects. If no response is received, the work shall be deemed accepted, provided the client was informed of this consequence. Immaterial defects do not entitle the client to refuse acceptance.</p>

<h2>&sect; 5 Client's Cooperation Obligations (Mitwirkungspflichten)</h2>
<p>The client shall provide all necessary documents, information, data, and access in a timely manner.</p>
<p>The client shall designate a qualified contact person with decision-making authority.</p>
<p><strong>Technical Infrastructure:</strong> Where services are performed on the client's systems, the client shall provide the infrastructure. Gosign shall inform the client of the system requirements.</p>
<p><strong>Testing and Acceptance:</strong> The client shall actively participate, document errors, and not unreasonably delay approvals.</p>
<p><strong>Maintenance and Data Backup:</strong> The client shall independently and promptly install security updates, unless a maintenance contract with Gosign is in place. Regular backups are the client's responsibility.</p>
<p><strong>Lawfulness:</strong> The client is responsible for the lawfulness of all content and data provided and shall indemnify Gosign against third-party claims.</p>
<p>Delays and additional costs caused by the client's breach of cooperation obligations shall be borne by the client.</p>

<h2>&sect; 6 Special Provisions for AI Infrastructure & Agent Development</h2>
<h3>6.1 Scope of Services</h3>
<p>The scope of services is defined in the proposal and may include: integration and customization of AI models, development of AI agents, implementation of the Decision Layer, AI infrastructure consulting, FinOps, security and compliance concepts, training.</p>
<p>The proposal specifies which Platform Components (&sect; 7.2) are used and includes a Component Manifest as an appendix.</p>
<h3>6.2 Three-Tier Architecture and Responsibilities</h3>
<p>The AI solutions developed by Gosign distinguish three processing tiers with different responsibilities:</p>
<p>(a) <strong>Analysis (AI Model):</strong> The language model analyzes data and generates recommendations. AI models produce probabilistic results; Gosign owes the professional integration and configuration of the model, not the substantive accuracy of each individual output.</p>
<p>(b) <strong>Decision (Decision Layer):</strong> The Decision Layer applies defined rule sets, thresholds, and approval processes to the analysis results. Gosign owes the correct implementation of the agreed decision logic. Errors in the rule implementation constitute software defects and are subject to warranty.</p>
<p>(c) <strong>Execution (Integration/Tool):</strong> The results are transmitted to the client's target systems (e.g., SAP, DATEV, Workday). Gosign owes the correct technical integration. Errors in the client's target system are the client's responsibility.</p>
<h3>6.3 Human-in-the-Loop</h3>
<p>For decisions classified as high-risk (particularly personnel decisions, salary decisions, decisions subject to co-determination (Mitbestimmung)), Human-in-the-Loop is the default, unless expressly agreed otherwise. The classification of which decisions require human approval is jointly determined during the project and configured in the Decision Layer. The client remains responsible for substantive final decisions.</p>
<h3>6.4 Model Agnosticism</h3>
<p>Gosign uses AI models from various providers (model-agnostic approach). The selection is made in coordination with the client. Gosign shall inform the client of planned model changes. Should a provider discontinue its service, Gosign shall promptly propose an equivalent alternative model. Gosign shall not be liable for the availability or discontinuation of third-party services.</p>
<h3>6.5 Bias Monitoring</h3>
<p>Where agreed, Gosign implements mechanisms for the detection and documentation of systematic biases (Bias Monitoring). Regular monitoring during ongoing operations is the client's responsibility, unless a maintenance contract is in place.</p>
<h3>6.6 Use of Data for AI</h3>
<p>The client remains the owner and controller of all data provided to Gosign. Gosign uses such data exclusively for the performance of the contract. The client ensures it holds the necessary rights. Where external AI models or APIs are used, this occurs only under conditions that exclude the use of client data for model training, unless the client has expressly approved otherwise.</p>
<h3>6.7 FinOps and Usage-Based Costs</h3>
<p>Usage-based third-party costs (API fees, GPU compute time) are borne by the client, unless otherwise agreed. Gosign shall inform the client in advance of the cost structure and provide transparent usage reports.</p>
<h3>6.8 Regulatory Requirements</h3>
<p>Gosign addresses the requirements of Regulation (EU) 2024/1689 (EU AI Act) as technical architectural principles (Readiness). The legal compliance assessment for the specific use case is the responsibility of the client and its legal advisors. Gosign shall support the client in implementing regulatory requirements upon request, provided this is commissioned.</p>
<h3>6.9 Indemnification</h3>
<p>The use of the AI systems is the client's sole responsibility. The client shall indemnify Gosign against third-party claims arising from abusive or unlawful use.</p>

<h2>&sect; 7 Rights of Use, Intellectual Property, and Source Code Access</h2>
<h3>7.1 Rights of Use to Client-Specific Work Products</h3>
<p>Upon full payment, the client receives a permanent, geographically unrestricted, non-exclusive right of use to the following client-specific work products:</p>
<p>(a) Client-specific configurations (rule sets, decision tables, policies, routing rules, client-specific data models, decision matrices)</p>
<p>(b) Prompts and prompt templates developed for the client and designated as client-specific in the Component Manifest</p>
<p>(c) Client-specific integrations and adapters according to the Component Manifest (e.g., client-specific SAP connectors, API connectors, UI texts)</p>
<p>(d) Technical documentation of the client-specific solution</p>
<p>(e) Client data and configurations in all formats</p>
<p>The assignment to &sect; 7.1 or &sect; 7.2 is determined by the Component Manifest pursuant to &sect; 7.2 para. 4.</p>
<p>The right of use includes the right to modify and further develop for the client's own business operations.</p>
<p>Transfer to third parties or sublicensing requires the prior written consent of Gosign. <strong>No consent is required for transfer to Permitted Third Parties (Zulässige Dritte).</strong> Permitted Third Parties are:</p>
<p>(i) Affiliated companies of the client within the meaning of &sect;&sect; 15 et seq. AktG (German Stock Corporation Act) or under comparable foreign corporate law (group companies, subsidiaries, shared service units)</p>
<p>(ii) IT service providers and data processors of the client acting under confidentiality obligations and purpose limitation</p>
<p>(iii) Auditors, internal audit, and regulatory authorities within the scope of statutory or contractual audit obligations</p>
<p>(iv) Legal successors of the client in the event of restructuring, merger, or asset deal, provided the transfer occurs in connection with a transfer of the business unit in which the solution is deployed, and the legal successor assumes the obligations under &sect; 7; transfer to direct competitors of Gosign is excluded</p>
<p>The client shall ensure that Permitted Third Parties maintain at least equivalent protection and confidentiality obligations.</p>
<p>&sect; 7.1 takes precedence over the general assignment provision in &sect; 19 insofar as the transfer to Permitted Third Parties or legal successors is concerned.</p>
<p>The client has full access to the source code of all components operated in its environment - including Platform Components pursuant to &sect; 7.2 - no later than deployment of the solution in its infrastructure, or otherwise no later than acceptance or full payment. Access means readable, not intentionally obfuscated source code in a repository maintained in the client's environment or as a code export (at least after each productive release and upon request within 10 business days) including build instructions and dependency lockfiles. Additional code exports outside of regular releases are provided free of charge up to twice per quarter; exports beyond this are compensated based on effort.</p>

<h3>7.2 Gosign Platform Components</h3>
<p>Gosign uses its own Platform Components in development. Platform Components are the reusable technical core, in particular the Decision Engine, the Rules Engine Framework, the Audit Trail architecture, and orchestration modules (hereinafter "Platform Components"). The exclusive intellectual property and right of use to these Platform Components remains with Gosign.</p>
<p>The client receives a <strong>permanent right of use to the respective delivered version</strong> of the Platform Components (Perpetual License). This right of use is non-exclusive and includes the operation, configuration, and integration into the client's systems for its own business operations. The right of use exists regardless of whether a maintenance contract is in place. The transfer rules from &sect; 7.1 (including Permitted Third Parties and the flow-down obligation) apply accordingly.</p>
<p>From deployment (or with acceptance/payment pursuant to &sect; 7.1), the client has full access to the source code of all Platform Components operated in its infrastructure. Gosign provides complete technical documentation including build instructions. The source code shall not be intentionally rendered unreadable (no obfuscation, no intentional impediment to readability). The encryption of source code at rest and in transit for integrity protection is not affected by this provision.</p>
<p>The Platform Components are identified in the proposal in a <strong>Component Manifest</strong>. The Component Manifest <strong>lists at a minimum all material Platform Components</strong> and assigns each component to either &sect; 7.1 (client-specific) or &sect; 7.2 (platform). The Component Manifest is authoritative for the assignment. <strong>Changes to the Component Manifest require text form and shall be agreed as an addendum to the proposal or in a Change Request.</strong> Components not listed in the Manifest shall be deemed client-specific within the meaning of &sect; 7.1, unless they are open-source or third-party components or are already deployed as Platform Components in other client projects; clarification by addendum remains possible.</p>
<p>The source code of the Platform Components is <strong>confidential information and a trade secret of Gosign</strong> within the meaning of &sect; 14. The client may inspect the source code, use it for the contractual purpose, and transfer it to Permitted Third Parties pursuant to &sect; 7.1 in compliance with the flow-down obligation. Any use, transfer, or exploitation beyond this is prohibited. The client shall protect the source code of the Platform Components with at least the same care as its own trade secrets.</p>
<p>The client shall not use Platform Components, including source code and know-how derived therefrom, to develop, market, or provide a product or service competing with Gosign or to productize for third parties.</p>

<h3>7.3 Source Code Escrow</h3>
<p>At the client's request, Gosign shall deposit the complete source code of all Platform Components, including build instructions, dependency lockfiles, and deployment documentation, with an independent escrow service provider. The costs of the deposit are borne by the client, unless otherwise agreed in the proposal.</p>
<p>At the time of contract conclusion, Gosign grants the client all rights of use to the Platform Components subject to the condition precedent of the respective release event, including the right to modify, further develop, and independently operate them. The condition precedent is triggered in the following cases:</p>
<p>(a) Filing for insolvency by Gosign (opening or rejection for lack of assets)</p>
<p>(b) <strong>Discontinuation of Product Support:</strong> Gosign fails to provide security updates for the deployed Platform Components within 90 calendar days of becoming aware of a critical vulnerability without offering an equivalent successor solution within this period, or officially declares the component end-of-life. A critical vulnerability within the meaning of this clause is a security flaw rated as high or critical according to internationally recognized standards (in particular CVSS). Further criteria may be agreed in the escrow agreement. An equivalent successor solution covers at least the essential core functions of the replaced component and ensures a comparable security level. Further requirements may be agreed in the escrow agreement.</p>
<p>(c) Material breach of contract by Gosign that is not remedied within 60 calendar days despite written notice setting a deadline.</p>
<p>The technical details of the deposit, updating, and release are governed by a separate escrow agreement between Gosign, the client, and the escrow service provider. This includes in particular: deposit scope (repository, keys, build chain, documentation, dependencies), update frequency, release conditions, the client's right of inspection, and release mechanics.</p>

<h3>7.4 Open-Source Components</h3>
<p>Gosign uses open-source software where possible. The client's rights to open-source components are governed by the respective license terms (e.g., MIT, Apache, GPL). Gosign shall provide the client with an overview of the open-source components used and their licenses (Software Bill of Materials). The client undertakes to comply with these license terms. Where custom code builds upon open-source components and may thereby be subject to their license terms, Gosign shall inform the client accordingly.</p>
<p>Gosign shall not use components under copyleft licenses (in particular GPL, AGPL) unless they are expressly identified in the proposal and approved by the client.</p>

<h3>7.5 Reusable Components and Tenant Isolation</h3>
<p>Gosign continuously develops Platform Components and uses them in projects for various clients. Client-specific configurations, trade secrets, and data do not flow into other projects.</p>
<p>The technical architecture ensures, in accordance with the state of the art, through tenant isolation that client data remains strictly separated. This includes in particular the separation at the level of data, logs, prompt histories, storage, and tenant-specific keys. Gosign shall document the isolation architecture upon request.</p>

<h3>7.6 Limited Right of Use (Alternative for Pure Software Projects)</h3>
<p>Where the proposal neither employs Platform Components nor agrees upon a Component Manifest (particularly in pure software development projects without Decision Layer deployment), the client receives a permanent, geographically unrestricted, non-exclusive right of use to the individual developments. The right of use includes the right to modify and further develop for the client's own business operations. The transfer rules pursuant to &sect; 7.1 para. 3 (including Permitted Third Parties and the flow-down obligation) apply accordingly.</p>

<h3>7.7 License Fees and Maintenance</h3>
<p>No ongoing license fees apply to client-specific work products (&sect; 7.1).</p>
<p>For Gosign Platform Components (&sect; 7.2): The right of use to the delivered version (Perpetual License) is <strong>covered by the compensation agreed in the proposal</strong>. Additional ongoing fees are only payable if expressly stated in the proposal.</p>
<p>An annual maintenance contract (Maintenance) may be agreed for <strong>ongoing maintenance, security updates, and further development</strong> of the Platform Components. The type, scope, response times, and amount of maintenance fees are transparently set out in the respective proposal.</p>
<p><strong>If the client terminates the maintenance contract, the right of use to the last delivered version remains fully in effect.</strong> The client will then no longer receive further updates, security patches, or technical support for the Platform Components. Gosign recommends entering into a source code escrow agreement pursuant to &sect; 7.3 in this case.</p>
<p>Without express agreement in the proposal, no ongoing fees apply.</p>

<h3>7.8 Client Modifications to Platform Components</h3>
<p>The client has the right to modify Platform Components for its own business operations. Gosign shall, where possible, provide documented extension points that allow changes without modifying the platform core.</p>
<p>If the client makes modifications to Platform Components <strong>outside the documented extension points</strong>, the warranty and support entitlement for the affected parts shall lapse until (a) the modifications are reversed or (b) Gosign conducts a chargeable analysis and confirms compatibility.</p>
<p><strong>The client shall cooperate to a reasonable extent to ensure that Gosign's security updates can be applied even where client modifications exist.</strong> If the client refuses the required cooperation or if its modifications block the installation of a security update, Gosign is entitled to suspend support for the affected components until the blockage is resolved. A blockage exists when the update cannot be applied with reasonable effort because client-side changes outside the extension points impair compatibility.</p>
<p>The client's security obligations pursuant to &sect; 9 remain unaffected by modifications.</p>

<h3>7.9 Client Contributions to Platform Components</h3>
<p>Where provided for in the proposal or a separate agreement, the client may submit bug fixes, improvement suggestions, or extensions for Platform Components ("Contributions").</p>
<p>The client grants Gosign a simple, non-exclusive, temporally and geographically unrestricted right of use to such Contributions, insofar as the Contributions relate to Platform Components and do not contain the client's trade secrets or client-specific configurations. Gosign may incorporate such Contributions into the Platform Components and make them available to all clients.</p>
<p>This clause does not impose any obligation on the client to submit Contributions.</p>

<h3>7.10 Handover</h3>
<p>The handover of work products (including source code repository, documentation, Component Manifest, configurations, and Software Bill of Materials) takes place no later than upon acceptance of the last project phase and full payment. Gosign shall actively support the handover and grant the client full access.</p>

<h2>&sect; 8 Hosting and Operations</h2>
<p>Regular operations of the solutions developed by Gosign are conducted within the client's infrastructure. Hosting by Gosign is an optional additional service. If the client uses hosting, the following conditions apply:</p>
<p><strong>Managed Services in Client Infrastructure:</strong> Where Gosign operates the solution in the client's cloud environment, the hosting provisions apply accordingly. Responsibility for the base infrastructure remains with the client. Gosign is responsible for the application layer.</p>
<p><strong>Data Center:</strong> Hosting takes place in Germany or the EU, unless otherwise agreed. The client's preferences shall be communicated at contract conclusion.</p>
<p><strong>Availability:</strong> Without SLA, no guarantee of minimum availability. Gosign strives for high availability.</p>
<p><strong>Maintenance Windows:</strong> Planned maintenance outside business hours with prior notice.</p>
<p><strong>Data Backup:</strong> Daily backup, 7-day rolling backup, unless otherwise agreed.</p>
<p><strong>Transition and Exit:</strong> After termination of hosting services, Gosign shall support the client for up to 90 days with migration (Transition). The Transition is compensated based on effort. All client data is fully exportable in common formats.</p>

<h2>&sect; 9 Security, Maintenance, and Updates</h2>
<p><strong>Mandatory Security Updates:</strong> Gosign may perform security-relevant updates without the client's prior consent if delay would jeopardize security. The client will be informed subsequently.</p>
<p><strong>Duty to Tolerate:</strong> The client may not refuse security updates. The security and integrity of the system take priority.</p>
<p><strong>Refusal:</strong> In the event of refusal of a security measure, Gosign may suspend services. Claims by the client for resulting damages are excluded.</p>
<p><strong>Optional Updates:</strong> Non-security-relevant updates only upon agreement.</p>
<p><strong>Penetration Testing:</strong> The client may, upon prior notice (at least 14 calendar days), have security audits or penetration tests conducted, provided confidentiality is ensured. Details may be governed in the SLA.</p>
<p><strong>Incident Response:</strong> In the event of a security incident affecting the availability, integrity, or confidentiality of client data or systems, Gosign shall inform the client without undue delay, no later than within 24 hours of becoming aware, and take immediate containment measures. The initial notification and containment measures are part of the contractual services. Additional services (in particular forensic analysis, root cause investigation, and preparation of a detailed incident report) are compensated based on effort, unless the incident is attributable to Gosign's fault. Where Gosign is responsible for the incident, all analysis and remediation measures are provided to the client free of charge.</p>

<h2>&sect; 10 Compensation and Payment Terms</h2>
<p>Prices are set out in the proposal, plus statutory VAT.</p>
<p>Invoicing on a time-and-materials or fixed-price basis as agreed.</p>
<p>Incidental and travel expenses only upon prior agreement.</p>
<p><strong>Payment Term:</strong> 14 calendar days, unless otherwise agreed. Deviating payment terms may be individually agreed. Default interest: 9 percentage points above the base interest rate (&sect; 288 para. 2 BGB).</p>
<p>Milestone-based installment payments for longer projects.</p>
<p>Set-off only against undisputed or legally established counterclaims.</p>

<h2>&sect; 11 Liability</h2>
<p><strong>Unlimited:</strong> In cases of intent, gross negligence, injury to life, body, or health, guarantee, and product liability.</p>
<p><strong>Cardinal Obligations (Kardinalpflichten):</strong> In cases of ordinary negligence, limited to the typically foreseeable damage.</p>
<p><strong>Liability Cap:</strong> Gosign's liability for damages arising from the breach of cardinal obligations (Kardinalpflichten) is limited per claim to the amount of the net compensation agreed in the affected individual contract. Gosign's total liability under a contractual relationship is limited to twice the annual net compensation. Deviating liability caps may be agreed in the individual contract.</p>
<p><strong>Indirect damages, consequential damages, and lost profits:</strong> Excluded except in cases of intent, gross negligence, or breach of cardinal obligations (Kardinalpflichten).</p>
<p><strong>Data Loss:</strong> Liability limited to the recovery effort from the client's proper backups.</p>
<p><strong>AI Results:</strong> No liability for decisions based on AI outputs, provided Gosign has not breached cardinal obligations (Kardinalpflichten) (see &sect; 6.2).</p>
<p><strong>Insurance:</strong> Gosign maintains market-standard professional and business liability insurance. Proof upon request.</p>
<p><strong>Limitation Period:</strong> Two years, not applicable in cases of intent, gross negligence, or personal injury.</p>

<h2>&sect; 12 Defect Claims (Warranty)</h2>
<p><strong>Warranty Period:</strong> 12 months from acceptance for defects in quality and title (Sach- und Rechtsmängel).</p>
<p>Defects shall be reported without undue delay in text form. Supplementary performance through repair or replacement delivery.</p>
<p>Failure after two attempts: price reduction or rescission.</p>
<p>No warranty for immaterial deviations or disruptions caused by the client.</p>
<p>Errors in open-source or third-party software do not constitute a defect in Gosign's services, provided they were correctly integrated.</p>
<p>The warranty for Platform Components is subject to the limitations pursuant to &sect; 7.8 (client modifications).</p>
<p>For continuing obligations: statutory provisions for service/lease agreements.</p>

<h2>&sect; 13 Data Protection and Data Processing</h2>
<p>Both parties comply with GDPR (DSGVO), BDSG (German Federal Data Protection Act), and other applicable data protection laws.</p>
<p>Where the client processes data subject to the Brazilian LGPD or other international data protection laws, Gosign shall support compliance.</p>
<p>Gosign acts as a data processor (Art. 28 GDPR). The parties shall conclude a Data Processing Agreement (DPA / Auftragsverarbeitungsvertrag).</p>
<p>Gosign also accepts DPAs provided by the client, provided they are GDPR-compliant.</p>
<p>Gosign implements appropriate technical and organizational measures (Art. 32 GDPR).</p>
<p>Sub-processors with general consent, provided they are contractually obligated to an equivalent level of data protection.</p>
<p><strong>Data Residency:</strong> Upon request, contractual assurance that data processing occurs exclusively in Germany or a specified EU/EEA member state. For AI API calls to third countries, prior information and - where possible - European endpoints.</p>
<p>In the event of a data breach: immediate notification and cooperation with reporting obligations.</p>

<h2>&sect; 14 Confidentiality</h2>
<p>Both parties treat confidential information as strictly confidential.</p>
<p><strong>Exceptions:</strong> Publicly known, previously known, independently developed, statutory obligation.</p>
<p><strong>Disclosure:</strong> Only on a need-to-know basis to employees subject to confidentiality obligations.</p>
<p><strong>Standard of Protection:</strong> Both parties protect confidential information at least as they protect their own trade secrets, but in any event through appropriate technical and organizational measures in accordance with the state of the art.</p>
<p><strong>Duration:</strong> 5 years after termination of the contract. For information designated as trade secrets (in particular pursuant to &sect; 7.2 para. 5), the confidentiality obligation continues beyond the term of the contract.</p>
<p><strong>Return and Destruction:</strong> Upon request, no later than upon termination of the contract.</p>
<p><strong>Reference Use:</strong> Gosign may use the client's name and logo as a reference only with the client's prior written approval.</p>

<h2>&sect; 15 Contract Term and Termination</h2>
<p>15.1 Project contracts end upon acceptance of the last deliverable and full payment.</p>
<p>15.2 Continuing obligations: minimum term of 12 months. Thereafter, automatic renewal for 12-month periods, terminable with 3 months' notice before the end of the term.</p>
<p>15.2a For maintenance contracts pursuant to &sect; 7.7 (Maintenance), the provisions for continuing obligations under para. 2 apply accordingly, unless different terms and notice periods are agreed in the maintenance contract.</p>
<p>15.3 Extraordinary termination for cause: (a) material breach of duty after a 30-day grace period; (b) insolvency; (c) persistent refusal of updates (&sect; 9); (d) unlawful system use.</p>
<p>15.4 Consequences of termination: Return/deletion of all client data. Transition pursuant to &sect; 8. Acquired rights of use continue in effect upon full payment.</p>

<h2>&sect; 16 Compliance, Certifications, and Co-Determination (Mitbestimmung)</h2>
<p><strong>16.1 Cert-Ready:</strong> Gosign designs its solutions to meet the technical prerequisites for industry-standard certifications (Cert-Ready by Design). Specifically, this means: Controls are implemented as first-class data objects in the system, Evidence is automatically generated, the Audit Trail is complete and exportable, and access via an Auditor Portal is provided. The attainment of a specific certificate is not an owed deliverable and requires a separate agreement between the client, auditor, and Gosign.</p>
<p><strong>16.2 Works Council and Co-Determination:</strong> Where AI solutions are deployed in areas subject to co-determination (&sect; 87 para. 1 no. 6 BetrVG, German Works Constitution Act), Gosign supports the preparation of documentation and information materials for the works council. The formal involvement of the works council and the conclusion of works agreements are the client's responsibility. The architecture of the Decision Layer is designed to represent works agreements as configurable, technically enforceable rules.</p>
<p><strong>16.3 Sanctions Compliance:</strong> Gosign warrants that it does not maintain business relationships with sanctioned persons, entities, or states.</p>
<p><strong>16.4 Sustainability:</strong> Gosign considers energy efficiency aspects in infrastructure selection. Information available upon request.</p>

<h2>&sect; 17 Export Control</h2>
<p>The client shall comply with export and sanctions regulations. Gosign shall inform of export-controlled components. Performance is subject to the proviso that no statutory impediments exist.</p>

<h2>&sect; 18 Force Majeure</h2>
<p>No liability for non-performance due to force majeure (natural disasters, war, pandemics, industrial action, governmental measures, large-scale infrastructure failures). Immediate notification. Deadlines shall be extended accordingly. Right of rescission after 3 months.</p>

<h2>&sect; 19 Final Provisions</h2>
<p><strong>Applicable Law:</strong> German law, excluding the UN Convention on Contracts for the International Sale of Goods (CISG).</p>
<p><strong>Place of Jurisdiction:</strong> Hamburg (for merchants and legal entities).</p>
<p><strong>Contract Language:</strong> German. English versions serve international cooperation; in case of doubt, the German version prevails.</p>
<p><strong>Versioning:</strong> These GTC bear a version number and effective date. Current version at gosign.de/de/agb/.</p>
<p>Amendments in text form. GTC amendments with 6 weeks' notice; objection period 4 weeks.</p>
<p><strong>Assignment:</strong> Assignment only with written consent. The transfer to Permitted Third Parties and legal successors pursuant to &sect; 7.1 para. 3 remains unaffected.</p>
<p>Severability clause. Precedence of individual agreements.</p>

--- Free AI Tools - Interactive Decision Aids ---
> 8 free browser tools for AI decisions: Board Deck Generator, EU AI Act Risk Classifier, ROI Calculator, TCO Planner and more. No login required.

<section class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-12">

<p class="text-body text-gosign-text mb-10">All tools run directly in the browser. No registration, no data sharing, no hidden costs. Results are based on public frameworks and benchmarks.</p>

<div class="grid grid-cols-1 md:grid-cols-2 gap-6">

<div class="bg-gosign-dark rounded-card p-6 flex flex-col">
<span class="inline-block text-small font-medium text-gosign-accent-on-dark bg-white/10 rounded-full px-3 py-1 mb-4 w-fit">Free, in-browser, no login</span>
<h2 class="text-h3 font-bold text-white mb-2">Board Deck Generator</h2>
<p class="text-body text-white/70 mb-4 flex-1">9-slide initial assessment with ROI analysis, risk evaluation and 3-scenario comparison. 7 input fields, ready-to-present board deck as output.</p>
<a href="/en/hr-agent-catalog/" class="inline-flex items-center gap-2 text-gosign-accent-on-dark hover:text-white font-medium">Go to HR Catalog &rarr;</a>
</div>

<div class="bg-gosign-dark rounded-card p-6 flex flex-col">
<span class="inline-block text-small font-medium text-gosign-accent-on-dark bg-white/10 rounded-full px-3 py-1 mb-4 w-fit">Free, in-browser, no login</span>
<h2 class="text-h3 font-bold text-white mb-2">EU AI Act Risk Classifier</h2>
<p class="text-body text-white/70 mb-4 flex-1">Risk classification per Regulation (EU) 2024/1689. 7 questions, clear categorisation into Minimal, Limited, High or Unacceptable Risk.</p>
<a href="/en/governance/eu-ai-act/" class="inline-flex items-center gap-2 text-gosign-accent-on-dark hover:text-white font-medium">Go to Risk Classifier &rarr;</a>
</div>

<div class="bg-gosign-dark rounded-card p-6 flex flex-col">
<span class="inline-block text-small font-medium text-gosign-accent-on-dark bg-white/10 rounded-full px-3 py-1 mb-4 w-fit">Free, in-browser, no login</span>
<h2 class="text-h3 font-bold text-white mb-2">Co-Determination Check</h2>
<p class="text-body text-white/70 mb-4 flex-1">Does the works council need to approve? 5 questions based on applicable co-determination law with a clear recommendation. For HR leaders and project managers.</p>
<a href="/en/governance/co-determination/" class="inline-flex items-center gap-2 text-gosign-accent-on-dark hover:text-white font-medium">Go to Co-Determination Check &rarr;</a>
</div>

<div class="bg-gosign-dark rounded-card p-6 flex flex-col">
<span class="inline-block text-small font-medium text-gosign-accent-on-dark bg-white/10 rounded-full px-3 py-1 mb-4 w-fit">Free, in-browser, no login</span>
<h2 class="text-h3 font-bold text-white mb-2">Agent Comparison Tool</h2>
<p class="text-body text-white/70 mb-4 flex-1">Compare 2-3 AI agents side-by-side. Costs, automation level, governance requirements and implementation effort at a glance.</p>
<a href="/en/hr-agent-catalog/" class="inline-flex items-center gap-2 text-gosign-accent-on-dark hover:text-white font-medium">Go to HR Catalog &rarr;</a>
</div>

<div class="bg-gosign-dark rounded-card p-6 flex flex-col">
<span class="inline-block text-small font-medium text-gosign-accent-on-dark bg-white/10 rounded-full px-3 py-1 mb-4 w-fit">Free, in-browser, no login</span>
<h2 class="text-h3 font-bold text-white mb-2">Workforce Planner</h2>
<p class="text-body text-white/70 mb-4 flex-1">Workforce planning with vs. without AI agents. Based on SHRM and Hackett benchmarks. Shows FTE savings and productivity gains.</p>
<a href="/en/hr-agent-catalog/" class="inline-flex items-center gap-2 text-gosign-accent-on-dark hover:text-white font-medium">Go to HR Catalog &rarr;</a>
</div>

<div class="bg-gosign-dark rounded-card p-6 flex flex-col">
<span class="inline-block text-small font-medium text-gosign-accent-on-dark bg-white/10 rounded-full px-3 py-1 mb-4 w-fit">Free, in-browser, no login</span>
<h2 class="text-h3 font-bold text-white mb-2">TCO Calculator</h2>
<p class="text-body text-white/70 mb-4 flex-1">3-year cost projection for AI infrastructure. Build vs. Buy vs. Hybrid. Licence costs, implementation, ongoing operations.</p>
<a href="/en/services/infrastructure/" class="inline-flex items-center gap-2 text-gosign-accent-on-dark hover:text-white font-medium">Go to Infrastructure Service &rarr;</a>
</div>

<div class="bg-gosign-dark rounded-card p-6 flex flex-col">
<span class="inline-block text-small font-medium text-gosign-accent-on-dark bg-white/10 rounded-full px-3 py-1 mb-4 w-fit">Free, in-browser, no login</span>
<h2 class="text-h3 font-bold text-white mb-2">ROI Quick Calculator</h2>
<p class="text-body text-white/70 mb-4 flex-1">Quick savings calculation for HR, Finance and Travel processes. Input: case volume, time per case, hourly rate. Output: annual savings potential.</p>
<a href="/en/hr-agent-catalog/" class="inline-flex items-center gap-2 text-gosign-accent-on-dark hover:text-white font-medium">Go to HR Catalog &rarr;</a>
</div>

<div class="bg-gosign-dark rounded-card p-6 flex flex-col">
<span class="inline-block text-small font-medium text-gosign-accent-on-dark bg-white/10 rounded-full px-3 py-1 mb-4 w-fit">Free, in-browser, no login</span>
<h2 class="text-h3 font-bold text-white mb-2">Readiness Assessment</h2>
<p class="text-body text-white/70 mb-4 flex-1">7-question online check with radar chart. Assess your organisation across process maturity, data, governance, IT and change management.</p>
<a href="/en/hr-agent-readiness/" class="inline-flex items-center gap-2 text-gosign-accent-on-dark hover:text-white font-medium">Go to Readiness Assessment &rarr;</a>
</div>

</div>
</section>

--- a21glossary TYPO3 - Glossary Terms | Gosign ---
> Glossary extension for TYPO3: define terms, automatically link in content, display as tooltip. SEO advantage through additional indexable pages.

## Organizations that need a glossary usually have an SEO problem

Explaining technical terms on a website sounds like a service feature. In reality, a21glossary solves a concrete technical problem: TYPO3 pages with content that requires explanation rank better when terms are internally linked, indexable as standalone pages, and instantly accessible via tooltips. The extension automatically generates links from a central term database throughout the content, without editors having to set each link manually.

For companies with specialist portals, knowledge platforms, or products that require explanation, a21glossary creates exactly the internal linking structure that Google interprets as topical authority. Instead of hiding 50 terms in an FAQ, 50 independent, indexable pages with Schema markup potential are created.

## Typical use cases

**Specialist portals with more than 100 terms.** Industry associations, universities, and trade publishers maintain glossaries with hundreds of entries. a21glossary automatically links each term at its first mention in body text. For one client with 340 glossary entries, internal linking density increased by 28%, measurable through Google Search Console.

**Product pages with technical vocabulary.** Machine manufacturers, chemical companies, and medical device makers use specialized language that buyers and decision-makers do not always understand. A tooltip with 2-3 sentences of explanation keeps readers on the page instead of sending them to Google. Time on page increases, bounce rate decreases.

**Multilingual knowledge platforms.** Combined with TYPO3's language handling, glossaries can be maintained per language. German terms link to German explanations, English to English. This works cleanly as long as the language configuration in TYPO3 is set up correctly.

## Technical architecture

a21glossary works as a content post-processor. After TYPO3 renders a page, the extension scans the HTML output for defined terms and replaces them with linked variants. The terms themselves are stored in a dedicated database table and managed through a backend module.

The extension registers via a Content Object Post User Func hook in the TypoScript rendering process. This means it only intervenes after TYPO3 has fully rendered the content. As a result, it works independently of the content element type - whether Textmedia, News, or Custom Content Elements.

Tooltip display uses a small JavaScript snippet and CSS, both customizable. In modern TYPO3 setups, replacing the default JavaScript with a CSS-only solution is recommended to avoid impacting Core Web Vitals. Using the `title` attribute and a `:hover` selector, simple tooltips can be realized without a single line of JavaScript.

The glossary entries themselves are configurable via TypoScript: which pages should be scanned, how often a term may be linked per page (recommended: once), and which HTML areas are excluded (navigation, footer, other glossary entries).

## Common problems and solutions

**Performance degradation with large glossaries.** From approximately 500 terms onward, the post-processing step can become noticeable, especially on text-heavy pages. The solution: activate caching. TYPO3's page cache stores the result after the first rendering. Only when the cache is cleared does reprocessing occur. Additionally, reducing the term list to the actually used vocabulary helps - 200 precise terms outperform 800 including variants.

**Incorrect links in headings and existing links.** By default, a21glossary links everywhere, including within H2 tags or existing hyperlinks. This leads to nested links that are HTML-invalid. The TypoScript configuration allows excluding tags: `excludeTags = h1,h2,h3,a,script`. This setting belongs in every initial installation.

**Conflicts with RealURL and routing.** In older TYPO3 versions (before v9), issues arose when glossary detail pages were routed via RealURL. With TYPO3 v10+ and native Site Routing, this problem no longer exists. Anyone still using RealURL should migrate regardless.

## Migration and version compatibility

a21glossary was originally developed for TYPO3 v4.x and updated over the years. The last actively maintained version in the TER supports TYPO3 v10 and v11. For TYPO3 v12, a community fork on GitHub ports the extension to the new TCA structure and changed hook system. For TYPO3 v13, no official version is available at this time.

Migration from v11 to v12 requires three adjustments: first, switching from `$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']` to the new Event Dispatcher system; second, updating TCA definitions (wizard configuration); and third, adapting the TypoScript setup to the new Site Configuration.

Those planning for TYPO3 v13 face a decision: continue developing the community fork or switch to an alternative solution. One alternative is implementing the glossary functionality directly as a Custom Content Element with DataProcessor. The effort is approximately 2-3 developer days, the result is future-proof and independent of third-party maintenance. Gosign has performed this migration for multiple projects and can realistically estimate the actual effort based on an analysis of the existing glossary data.

--- aimeos TYPO3 - E-Commerce Shop | Gosign ---
> aimeos: professional online shop in TYPO3. Setup, customization & migration, AI-accelerated development.

## Running a shop inside TYPO3 is hard to beat when aimeos is part of the stack

Organizations that already operate a TYPO3 website and want to add e-commerce face a fundamental question: a separate shop system (Shopware, Magento, WooCommerce) with a CMS interface, or a native e-commerce framework within TYPO3? aimeos is the second option and has been the most established TYPO3 shop framework for over 10 years. More than 200,000 installations worldwide (as of Packagist, 2026), active development and support for TYPO3 v12 and v13 speak for stability.

The decisive advantage: content and commerce run in the same system. Product pages use TYPO3 content elements, landing pages can embed shop components, editors work in a single interface. With separate systems, synchronization problems arise - duplicate maintenance and inconsistent design.

## Typical use cases

**B2B shops with complex pricing logic.** Industrial companies with customer-specific prices, volume discounts, minimum order quantities and approval workflows. aimeos natively supports customer group pricing, price plugins and rule engines. A chemical distributor with 8,000 items and 400 customer groups can be mapped without hardcoding every pricing rule.

**Marketplaces and multi-vendor scenarios.** aimeos can serve as a marketplace backend where multiple suppliers list their products. Each vendor manages their catalog, the platform handles checkout, payment and shipping routing. The framework supports multi-shop setups where different storefronts access the same catalog but display different assortments and prices.

**Internationalization from day one.** Companies with websites in 5+ languages and multiple currencies benefit from aimeos natively supporting multi-language and multi-currency. Product names, descriptions and SEO metadata can be maintained per language. Prices can be defined per currency or converted automatically.

## Technical architecture

aimeos is built on its own MVC architecture (Manager, Controller, Client) that integrates into TYPO3 as an extension. The core is framework-agnostic and also runs under Laravel and Slim. The TYPO3 adapter layer ensures that aimeos plugins are embedded as TYPO3 content elements.

The product catalog uses a tree structure with arbitrarily deep nesting. Attributes (color, size, material) are managed as separate entities and delivered through faceted filters. The search function defaults to SQL full-text search but can be switched to Elasticsearch or Solr.

Payment integrations run through service providers: Stripe, PayPal, Mollie, Amazon Pay, Klarna and others are available as plugins. Every payment provider is addressed through a unified API. The checkout process is implemented as a step pipeline and can be extended with custom steps (e.g. age verification, B2B approval).

Caching operates on multiple levels: TYPO3 page cache for static pages, aimeos internal caching for catalog queries, and optionally Varnish or Cloudflare as a reverse proxy. For catalogs with over 100,000 items, index management is critical: aimeos creates search and price indexes that are updated incrementally on product changes.

## Common problems and solutions

**Performance drops with large catalogs.** Shops with 50,000+ items become slow when indexes are not current or the catalog cache is deactivated. Solution: run `php typo3/sysext/core/bin/typo3 aimeos:jobs` as a cronjob (every 5 minutes for index updates, hourly for cleanup jobs). Clear the aimeos admin cache manually after bulk imports.

**Checkout abandonments due to payment errors.** Common cause: outdated API keys or incorrect webhook URLs after a domain migration. Every payment provider needs a correct notify URL for asynchronous payment confirmations. Solution: verify webhook URLs in the payment provider dashboard after every migration, run test orders in sandbox mode.

**Conflicts with TYPO3 caching.** aimeos pages with shopping cart or login must not land in the TYPO3 page cache. Solution: mark the relevant pages as USER_INT or run aimeos in SPA mode (AJAX-based). Since aimeos 2024.x, SPA mode is the recommended default.

## Migration and version compatibility

aimeos fully supports TYPO3 v12 LTS and TYPO3 v13 since aimeos 2024.x. For TYPO3 v11, maintenance releases are available but no new features.

Migration from other shop systems is a realistic scenario. From Shopware, WooCommerce or tt_products, products, categories, customer accounts and order history can be transferred to aimeos. Gosign uses CSV/XML import pipelines where product data is transformed and mapped into the aimeos structure. Depending on data quality, migrating a shop with 5,000 products takes between 3 and 10 days.

Those coming from tt_products should plan the switch with the next TYPO3 major version: tt_products has been minimally maintained for years and has no official TYPO3 v13 compatibility.

Another migration path concerns organizations that have been running a separate Shopware or Magento shop alongside their TYPO3 website. Merging into a single system eliminates interface complexity: no REST API synchronization for product data, no duplicate template management, no separate deployments. The downside: aimeos does not cover every feature a dedicated shop system offers (e.g. Shopware Flow Builder, Magento Page Builder). But the tradeoff pays off for organizations where content and commerce carry equal weight - not just the shop, but also magazine, knowledge base and service pages.

Gosign advises on a project-specific basis whether aimeos is the right choice or whether a separate shop system with headless connection to TYPO3 represents the better architecture. The decision depends on three factors: catalog complexity (variants, configurators, bundles), transaction volume (under or over 1,000 orders per day) and existing TYPO3 infrastructure (extensions, templates, editorial workflows).

An aimeos setup with product catalog, shopping cart, Stripe and PayPal payment, shipping calculation and base templates is estimated by Gosign at 15 to 25 development days. Custom themes, complex pricing logic or marketplace features increase the effort accordingly. Ongoing operations require regular updates (aimeos and payment provider plugins) as well as monitoring of checkout performance and conversion rate. Security patches for aimeos and payment plugins should be applied within 48 hours, because shop systems handling payment data are a preferred attack target.

--- Amazon Pay TYPO3 - Payment | Gosign ---
> Amazon Pay in TYPO3: checkout with Amazon account. API integration, certification, AI-accelerated.

## Amazon Pay reduces checkout abandonment because customers do not need to create a new account

70% of German online shoppers have an Amazon account. When these users click "Buy" in a TYPO3 shop and see a registration form with 12 mandatory fields, many abandon. Amazon Pay solves this problem: the customer authenticates with their Amazon account, delivery address and payment method are transferred automatically. No form, no credit card number, no new password. According to Amazon's own case studies, conversion rates increase by 15 to 30%, depending on industry and existing checkout quality.

For TYPO3 shop operators, the integration is not plug-and-play. Amazon Pay requires an API connection (Login with Amazon, Amazon Pay API v2), a certified implementation and regular security updates. Amazon reviews every integration before go-live.

## Typical use cases

**Mid-market B2C shops with aimeos.** Online shops for fashion, electronics, household goods that want to offer a third payment method alongside PayPal and credit card. Amazon Pay works particularly well for impulse-driven purchases under 200 EUR, where every hurdle in the checkout directly costs revenue. The integration into aimeos runs through a custom service provider that hooks into the payment pipeline.

**Donation platforms and membership fees.** Associations and NGOs that collect donations or membership fees through their TYPO3 website benefit from the low entry barrier. The donor clicks "Pay with Amazon", confirms the amount and is done. No IBAN entry, no direct debit setup. For recurring payments, Amazon Pay supports Recurring Payments.

**Digital products and downloads.** Software licenses, e-books, online courses - products without physical shipping benefit especially, because the entire purchase process completes in under 30 seconds. No shipping address needed, only authentication and payment.

## Technical architecture

Amazon Pay v2 is based on a REST API with JSON payloads. The flow in a TYPO3 shop: the customer clicks the Amazon Pay button, is redirected to Amazon (or a popup opens), logs in and confirms address and payment method. Amazon sends an access token back to the shop. The shop creates a checkout session via the Amazon Pay API containing cart data and order details. After confirmation by the customer, the payment is triggered.

The integration into TYPO3 requires three components: an API client (HTTP requests to the Amazon Pay API with RSA key signature), a frontend component (Amazon Pay button as JavaScript widget) and a webhook handler for asynchronous notifications (payment confirmation, refund, chargeback).

For aimeos, a community plugin exists covering the basic functions. For tt_products or custom shops, a dedicated integration is required. In both cases, the TYPO3 shop must use HTTPS (mandatory since Amazon Pay v2), and the webhook URL must be externally reachable.

Amazon provides a sandbox environment where all payment flows can be tested without real money. The sandbox uses dedicated API endpoints and test accounts.

## Common problems and solutions

**Certification fails on the first attempt.** Amazon checks before go-live whether the integration functions correctly: button placement, error handling for declined payments, display on mobile devices, correct cancellation flow. Common errors: the Amazon Pay button does not appear on the product page (only in the cart), error messages for payment declines are missing or in the wrong language. Solution: work through Amazon's Integration Checklist completely before requesting the review.

**IPN notifications (Instant Payment Notifications) are lost.** Amazon sends payment confirmations asynchronously via POST to a registered URL. If TYPO3 blocks these requests through caching, redirect rules or missing CSRF exceptions, the order remains in "pending" status. Solution: set up a dedicated eID route or middleware route for the webhook that runs outside normal TYPO3 request processing.

**Recurring Payments and subscription models.** Amazon Pay supports recurring payments, but setup is more complex than with Stripe Subscriptions. The customer must explicitly agree to a Billing Agreement, and the shop must regularly send Authorize requests. Solution: manage Billing Agreements as a dedicated database entity and set up a cronjob that triggers due payments.

## Migration and version compatibility

Amazon Pay v2 is the current API version (since 2021). Version 1 has not been accepted for new integrations since late 2023. Existing v1 implementations still work but receive no updates and no new features. Migrating from v1 to v2 affects the entire API client: different endpoints, different signature mechanism (RSA instead of HMAC), different session management.

For TYPO3, there is no official Amazon Pay extension in the TER with active v12/v13 support. Integration is done as custom code or through community plugins for aimeos. Gosign implements Amazon Pay as a standalone Composer package that can be integrated into any TYPO3 shop setup. This package encapsulates the API client, the button and the webhook handler, so a TYPO3 major upgrade only affects the TYPO3-specific adapter layer.

For shop operators offering PayPal, credit card and Klarna alongside Amazon Pay, Gosign recommends a unified payment abstraction. Instead of integrating each provider individually, a common interface is implemented through which all payment providers are addressed. aimeos brings this abstraction natively (service provider architecture). For custom shops, Gosign builds a comparable layer that decouples checkout code from provider-specific APIs. This reduces the effort for new payment providers to implementing a single adapter instead of a complete integration.

The total cost of an Amazon Pay integration in an existing TYPO3 shop is 3 to 8 development days, depending on whether an aimeos plugin can be used or a custom integration is needed. Amazon certification requires an additional 1 to 2 days for preparation and correction rounds.

--- Angular & TYPO3 - Headless CMS | Gosign ---
> Angular frontend with TYPO3: headless CMS, JSON API, SPA integration. AI-accelerated development.

## Warum Angular mit TYPO3 funktioniert, aber die meisten Setups scheitern

Die Idee klingt überzeugend: TYPO3 liefert Content als JSON, Angular rendert das Frontend als Single Page Application. Redakteure arbeiten im gewohnten TYPO3-Backend, Entwickler bauen ein modernes Frontend ohne TypoScript-Zwänge. In der Praxis scheitern viele Angular-TYPO3-Projekte an der Architektur-Grenze zwischen CMS und SPA. Die offizielle TYPO3 Headless Extension (EXT:headless) löst das Content-Delivery-Problem. Aber Routing, Preview, SEO und Caching brauchen durchdachte Lösungen, die über ein `ng serve` hinausgehen.

Angular als Frontend für TYPO3 eignet sich für Unternehmen, die Multi-Channel-Content brauchen: eine Website, eine App, ein Intranet-Portal und Digital Signage aus einer Content-Quelle. Der Aufwand rechnet sich ab dem zweiten Kanal. Für reine Websites ohne App-Ambition ist ein klassisches TYPO3-Fluid-Setup fast immer effizienter.

## Typical use cases

**Multi-Channel-Plattformen mit App und Web.** Ein Automobilzulieferer pflegt Produktdaten, Serviceinformationen und News in TYPO3. Die Website läuft als Angular-SPA, die Service-App für Techniker nutzt dieselbe JSON-API. Änderungen in TYPO3 erscheinen auf beiden Kanälen gleichzeitig. Der Content wird einmal gepflegt, zweimal ausgeliefert.

**Intranet-Portale mit komplexer Interaktion.** HR-Dashboards, Wissensmanagement-Plattformen und interne Tools profitieren von Angulars komponentenbasiertem Ansatz. TYPO3 liefert strukturierten Content (Policies, Handbücher, Organigramme), Angular rendert interaktive Views mit Filtern, Suche und Echtzeit-Updates. Die Authentifizierung läuft über das bestehende LDAP/SSO, TYPO3 prüft Berechtigungen per fe_group.

**Konfiguratoren und interaktive Produktseiten.** Hersteller von konfigurierbaren Produkten nutzen Angular für die 3D-Ansicht oder den Konfigurator. Die Produktstammdaten kommen aus TYPO3, die Konfigurationslogik lebt im Angular-Frontend. Bei einem Kunden mit 1.200 konfigurierbaren Varianten reduzierte dieser Ansatz die Ladezeit der Konfiguratorseite von 4,2 auf 1,1 Sekunden.

## Technical architecture

Die TYPO3 Headless Extension transformiert die Standard-Ausgabe von HTML in JSON. Jedes Content-Element, jede Navigation, jede Breadcrumb-Ebene wird als JSON-Objekt ausgeliefert. Angular konsumiert diese API über HttpClient-Services.

Die Architektur besteht aus drei Schichten. TYPO3 als Backend liefert Content über die Headless-API unter `/api/`. Angular als Frontend-Applikation wird als eigener Build-Prozess (`ng build --prod`) kompiliert und typischerweise über ein CDN oder einen separaten Webserver ausgeliefert. Dazwischen steht ein Node.js-basierter SSR-Server (Angular Universal), der Server-Side Rendering für SEO und soziale Netzwerke übernimmt.

Das Routing ist zweigeteilt: Angular Router übernimmt die Client-seitige Navigation, TYPO3 definiert die URL-Struktur über Site Configuration. Beide müssen synchron bleiben. In der Praxis bedeutet das: Wenn ein Redakteur in TYPO3 eine neue Seite anlegt, muss Angular diese URL kennen. Die Lösung ist ein dynamisches Routing im Angular-Frontend, das die Seitenstruktur bei jedem Build aus der TYPO3-API abfragt.

TypeScript-Services werden aus den TYPO3 Content-Typen generiert. Für jedes Content Element existiert ein Angular Component mit Typing. Diese Typen lassen sich per Script aus der TYPO3-API generieren, was den Gleichlauf zwischen Backend und Frontend sicherstellt.

## Common problems and solutions

**SEO-Defizite durch Client-Side-Only-Rendering.** Google rendert JavaScript, aber nicht zuverlässig und nicht sofort. Ohne Server-Side Rendering (Angular Universal oder Angular SSR seit v17) werden Seiten spät oder gar nicht indexiert. Die Lösung: Angular Universal als SSR-Layer einsetzen. Der initiale HTML-Response muss vollständig gerendert sein, bevor der Client-seitige Hydration-Prozess übernimmt.

**Content-Preview im TYPO3-Backend funktioniert nicht.** Redakteure klicken auf "Vorschau" und sehen JSON statt eine gerenderte Seite. Die Lösung: einen Preview-Proxy konfigurieren, der die JSON-Antwort an eine dedizierte Angular-Preview-Instanz weiterleitet. EXT:headless bietet dafür einen Preview-Modus, der Draft-Content über einen Token-Parameter ausliefert.

**CORS-Probleme zwischen TYPO3-API und Angular-Frontend.** Wenn TYPO3 und Angular auf unterschiedlichen Domains laufen, blockiert der Browser die API-Requests. Die Extension EXT:cors oder ein serverseitiger Reverse-Proxy löst dieses Problem. Empfohlen: Beide unter derselben Domain betreiben (TYPO3 unter `/api/`, Angular unter `/`).

## Migration and version compatibility

EXT:headless ist offiziell kompatibel mit TYPO3 v11, v12 und v13. Die Extension wird aktiv gepflegt und folgt dem TYPO3-Release-Zyklus. Angular selbst hat einen eigenen Release-Rhythmus: alle 6 Monate eine neue Major-Version. Seit Angular v17 ist SSR nativ integriert (kein separates Angular Universal Paket mehr nötig).

Für bestehende Angular-TYPO3-Projekte auf TYPO3 v10 oder älter empfiehlt sich eine stufenweise Migration: erst TYPO3 auf v12 oder v13 aktualisieren, dann Angular auf die aktuelle LTS-Version (v18). Die API-Schnittstelle von EXT:headless hat sich zwischen v2 und v4 an mehreren Stellen geändert, insbesondere bei der Behandlung von Sprach-Overlays und Workspace-Previews.

Der Aufwand für ein Angular-TYPO3-Projekt liegt typischerweise 30-50% über dem eines reinen Fluid-Projekts. Diesen Mehraufwand holt man durch den zweiten Kanal (App, Intranet) wieder ein. Gosign berät vor dem Projektstart, ob Headless der richtige Ansatz ist oder ob ein klassisches Setup mit gezielten JavaScript-Inseln den gleichen Zweck erfüllt.

--- Amazon S3 TYPO3 - Cloud Storage FAL | Gosign ---
> Amazon S3 as FAL driver for TYPO3. Store files in the cloud instead of on the web server.

## aus_driver_amazon_s3 is the standard answer when TYPO3 assets can no longer live on the web server, bringing S3 buckets into the stack as a full FAL driver

A classic TYPO3 setup stores all media under fileadmin on the web server. That works as long as the project runs on a single machine and storage is sufficient. As soon as multi-server setups, container clusters, auto-scaling or content delivery networks come into play, this model breaks. Every instance would need an identical copy of all files, synchronisation becomes a permanent building site, deployments slow down. aus_driver_amazon_s3 solves this by integrating Amazon S3 as an external FAL storage. Files live in the bucket, TYPO3 reads and writes them via the S3 API, and every server instance accesses the same consistent dataset. For projects with high availability requirements, this is the standard path.

Besides the technical necessity for multi-server setups, there is a second important driver: backup and redundancy. S3 stores every file redundantly across several data centres and achieves a level of durability that a classic web server cannot guarantee. For companies whose media data is business-critical, that alone is a reason to move to S3.

## Typical use cases

The first case are cloud-native deployments on AWS, Kubernetes or Docker Swarm. TYPO3 runs in several containers behind a load balancer, and every container is stateless. fileadmin as a local directory would mean that uploads only land on one container and the others do not see them. aus_driver_amazon_s3 keeps the asset base centralised and makes scale-out practical in the first place.

The second case are projects with very large data volumes. A media platform, an image archive or a download portal grows quickly to several hundred gigabytes or terabytes. Local server storage becomes expensive and inflexible, while S3 scales transparently and costs only for what is actually stored. Wiring it in through FAL also allows switching to the new storage without code changes in TYPO3.

Third use: CDN integration. Anyone who wants to deliver images and downloads through CloudFront, Cloudflare or a dedicated CDN uses S3 as the origin. aus_driver_amazon_s3 makes the files directly available in the bucket, TYPO3 generates the correct URLs and the CDN caches them globally. This measurably improves load times for international visitors.

## Technical architecture

aus_driver_amazon_s3 implements the FAL driver interface of TYPO3 and uses the official AWS SDK for PHP to talk to S3. Every bucket is set up as its own "file storage" in the TYPO3 backend, with bucket name, region, access key and secret key. Alternatively, IAM roles can be used when TYPO3 runs on an EC2 instance or in an ECS task, which is cleaner because no static credentials sit in configuration.

The extension supports both Amazon S3 and S3-compatible services such as MinIO, Backblaze B2, DigitalOcean Spaces or Scaleway Object Storage. For projects that cannot live at AWS for data protection reasons, this flexibility is important, because a European S3-compatible provider behaves exactly like the AWS service from TYPO3's perspective.

During operation, TYPO3 reads and writes directly against S3. The processed files, the cropped and optimised image variants, are by default stored in the bucket as well. Alternatively, a local directory for processed files can be configured, which speeds up image processing because GIFBUILDER does not have to pull every source image from S3 first.

Configuration runs through the backend module "file storages" and complementary TypoScript settings for the bucket URL and CDN prefixes. Developers additionally have to install the AWS SDK dependency via Composer and set the right permissions on the bucket.

## Common problems and solutions

The first problem is performance with large image lists. When a page has to crop dozens of images simultaneously and pulls the sources from S3, page build takes noticeably longer. The solution is a local cache for processed files, possibly combined with a pre-warming script that pre-generates the most common variants after new uploads.

Second problem: permission errors on upload. When TYPO3 wants to write into the bucket but the IAM policy only allows read access, the upload fails with a cryptic error. The solution is a precise policy with s3:GetObject, s3:PutObject, s3:DeleteObject and s3:ListBucket for exactly the TYPO3 bucket, ideally limited to a prefix so that other applications sharing the same bucket are not affected by accident.

Third problem: data protection and region choice. Projects that need to run GDPR-compliant should pick AWS regions in the EU, typically eu-central-1 in Frankfurt or eu-west-1 in Ireland. For higher requirements or customers who rule out AWS entirely, a European S3-compatible provider such as Hetzner, IONOS or Scaleway is the right path. The extension works with all of these providers.

## Migration and version compatibility

aus_driver_amazon_s3 is compatible with TYPO3 v11, v12 and v13 and is actively developed. On upgrades, the AWS SDK version matters: newer TYPO3 releases often require current SDK versions that in turn require PHP 8.1 or higher.

A migration from local fileadmin to S3 is a clearly scoped project: copy files initially into the bucket with aws s3 sync, set up a new file storage in the TYPO3 backend, point existing sys_file records at the new storage via a script, and delete local files after a successful test. The extension does not ship a ready-made migration routine, because the exact approach is project-specific.

For existing systems, an inventory is mandatory before migration. How many files are sitting in fileadmin, how large is the dataset, which of them are orphaned and which are actually still linked? Such audits often reveal that a large share of the legacy data is never accessed again and that the migration can be limited to the actively used files. This reduces risk, effort and bucket costs.

Gosign accompanies S3 migrations for TYPO3 projects and designs multi-cloud architectures that meet data protection requirements and performance goals at the same time.

--- Azure Storage TYPO3 - Cloud FAL | Gosign ---
> Azure Blob Storage as TYPO3 FAL driver. Store files in the Microsoft cloud. Counterpart to aus_driver_amazon_s3 for Azure infrastructures. CDN integration.

## Unternehmen mit Microsoft-Stack brauchen Azure Storage statt lokaler Dateisysteme

Wenn die IT-Landschaft auf Azure läuft, Active Directory die Benutzer verwaltet und SharePoint die Dokumente hält, dann gehört auch das TYPO3-Dateisystem in die Azure Cloud. EXT:azurestorage bindet Azure Blob Storage als FAL-Treiber (File Abstraction Layer) in TYPO3 ein. Redakteure merken keinen Unterschied, die Dateien liegen aber statt auf dem Webserver in Microsofts Cloud-Infrastruktur mit CDN, Geo-Redundanz und praktisch unbegrenztem Speicher.

Diese Extension ist das Azure-Pendant zu EXT:aus_driver_amazon_s3. Die Entscheidung zwischen beiden fällt selten technisch, sondern entlang der bestehenden Cloud-Strategie. Wer bereits Azure nutzt, spart Komplexität, Verträge und Netzwerk-Kosten durch den Verbleib im Microsoft-Ökosystem.

## Typical use cases

**Enterprise-Websites mit Multi-Server-Setup.** Große TYPO3-Installationen laufen auf mehreren Webservern hinter einem Load Balancer. Ohne Cloud-Storage müssen Dateien zwischen den Servern synchronisiert werden, per rsync, NFS oder GlusterFS. Jede dieser Lösungen bringt eigene Probleme. Azure Blob Storage als FAL-Treiber macht die Dateisynchronisation überflüssig: Alle Server greifen auf denselben Blob Container zu. Bei einem Kunden mit 4 Webservern und 180.000 Dateien entfiel durch die Migration auf Azure die gesamte NFS-Infrastruktur.

**Medienintensive Portale mit globalem Publikum.** Unternehmen mit Kunden in Europa, Asien und Nordamerika brauchen schnelle Ladezeiten weltweit. Azure CDN liefert Bilder und Downloads über Edge-Server in über 130 Städten aus. Die Integration erfolgt über die CDN-Endpunkt-Konfiguration im Azure Portal, TYPO3 generiert automatisch die passenden CDN-URLs.

**Compliance-Anforderungen an Datenhaltung.** Manche Branchen verlangen, dass Dateien in einem bestimmten Land gespeichert werden. Azure bietet Rechenzentren in Frankfurt, Zürich und Wien. Über die Storage-Account-Konfiguration lässt sich exakt festlegen, wo die Daten physisch liegen. Das ist ein Vorteil gegenüber generischen S3-kompatiblen Anbietern, bei denen die Geo-Konfiguration oft undurchsichtig ist.

## Technical architecture

EXT:azurestorage implementiert das TYPO3 FAL Driver Interface. Das bedeutet: Die Extension registriert sich als Treiber im File Abstraction Layer und überschreibt die Standard-Dateisystemoperationen (Lesen, Schreiben, Löschen, Auflisten) mit Azure Blob Storage API-Aufrufen.

Die Konfiguration erfolgt über die TYPO3 File Storage Einstellungen im Backend. Dort wird ein neues Storage-Objekt angelegt mit dem Treiber "Azure Blob Storage". Die Zugangsdaten (Storage Account Name, Access Key oder SAS Token) werden in der Storage-Konfiguration hinterlegt. Empfohlen: SAS Token mit begrenzter Gültigkeit und Lese-/Schreibrechten statt des Master Access Keys.

Die Kommunikation zwischen TYPO3 und Azure erfolgt über die Azure Storage REST API. Uploads werden als Block Blobs gespeichert, große Dateien (über 256 MB) automatisch in Blöcke aufgeteilt. Für die PHP-seitige Integration nutzt die Extension das Azure SDK for PHP oder eine leichtgewichtige REST-Client-Implementierung.

Bilder werden bei Bedarf von TYPO3s Image Processing (GraphicsMagick/ImageMagick) verarbeitet. Die verarbeiteten Varianten werden ebenfalls in Azure gespeichert, typischerweise in einem separaten Container (_processed_). Das Caching der Processed Files verkürzt die Verarbeitungszeit bei wiederholten Anfragen.

## Common problems and solutions

**Langsame Backend-Performance beim Durchsuchen großer Verzeichnisse.** Azure Blob Storage hat keine echte Verzeichnisstruktur, sondern emuliert sie über Pfad-Präfixe. Das Auflisten von 10.000 Dateien in einem "Ordner" erfordert API-Paginierung und dauert spürbar länger als auf einem lokalen Dateisystem. Die Lösung: TYPO3s FAL-Indexer korrekt konfigurieren und den Index regelmäßig aktualisieren, statt bei jedem Backend-Zugriff live gegen Azure zu prüfen.

**Image Processing schlägt fehl.** TYPO3 muss Bilder zum Verarbeiten herunterladen, verarbeiten und wieder hochladen. Bei instabiler Verbindung oder großen Bildern (TIFF-Dateien mit 200 MB) bricht der Prozess ab. Lösung: die Verarbeitung auf dem Server mit lokalem Temp-Verzeichnis durchführen und nur das Ergebnis hochladen. Die Konfiguration `processingFolder` sollte auf einen lokalen Pfad zeigen.

**Kosten-Explosion durch unnötige API-Calls.** Jeder Dateizugriff ist ein API-Call, und Azure rechnet pro 10.000 Transaktionen ab. Ein schlecht konfigurierter TYPO3-Indexer kann tausende Calls pro Minute erzeugen. Monitoring über Azure Cost Management einrichten und den FAL-Indexer auf Scheduler-basierte Intervalle (statt Echtzeit) umstellen.

## Migration and version compatibility

EXT:azurestorage ist ein Nischenprodukt mit begrenzter Community. Die verfügbaren Versionen im TER und auf Packagist unterstützen TYPO3 v10 und v11. Für v12 existieren Forks auf GitHub mit unterschiedlichem Reifegrad. Für TYPO3 v13 gibt es aktuell keine fertige Lösung.

Die Alternative für v12/v13: EXT:aus_driver_amazon_s3 mit einem S3-kompatiblen Azure-Endpunkt. Azure Blob Storage bietet seit 2020 eine S3-kompatible API-Schicht. Damit lässt sich die bewährtere und besser gepflegte S3-Extension auch mit Azure nutzen. Die Einrichtung erfordert einen Azure Storage Account mit aktiviertem "S3-Compatible API"-Feature und die Konfiguration der S3-Extension mit dem Azure-Endpunkt.

Wer von lokalem Dateisystem auf Azure migriert, sollte den Umzug in drei Phasen planen: erstens die bestehenden Dateien per AzCopy oder Storage Explorer in den Blob Container hochladen, zweitens die TYPO3 File Storage Konfiguration umstellen und drittens den FAL-Index neu aufbauen. Bei 50.000 Dateien dauert der gesamte Prozess typischerweise einen Arbeitstag. Gosign hat Azure-Migrationen für TYPO3-Projekte mit bis zu 400.000 Dateien durchgeführt und berät sowohl zur nativen Extension als auch zum S3-kompatiblen Workaround.

--- be_acl TYPO3 - Backend Permissions | Gosign ---
> Backend access control lists for TYPO3. Granular permissions for backend users and groups. Essential for multi-editor setups: who may see, edit, delete what.

## Sobald mehr als drei Redakteure arbeiten, reichen TYPO3s Standard-Rechte nicht mehr aus

TYPO3 bringt ein Berechtigungssystem mit: Backend-Gruppen, Seitenzugriffe, Tabellen-Rechte. Für kleine Teams mit einer Handvoll Redakteuren funktioniert das. Aber wenn eine Unternehmenswebsite von 15 Redakteuren aus 4 Abteilungen gepflegt wird, stößt das Standard-System an Grenzen. be_acl erweitert TYPO3 um granulare Access Control Lists, die regeln, wer auf welcher Seite welche Inhalte sehen, bearbeiten oder löschen darf - bis auf Feldebene.

Die Extension ist kein Nice-to-have, sondern Voraussetzung für jedes Multi-Redaktions-Setup mit mehr als einer Verantwortungszone. Ohne be_acl enden Berechtigungskonzepte in TYPO3 regelmäßig in einem Geflecht aus dutzenden Gruppen, die niemand mehr überblickt.

## Typical use cases

**Konzern-Websites mit Abteilungs-Verantwortung.** Marketing pflegt die Startseite und Kampagnenseiten, HR die Karriereseite, die Fachabteilungen ihre Produktseiten. Jede Abteilung soll nur ihre eigenen Seiten sehen und bearbeiten. Das Standard-TYPO3-System erlaubt Seitenzugriffe über Mount Points und Gruppenrechte, aber die Konfiguration wird bei 10+ Abteilungen unübersichtlich. be_acl vereinfacht das durch seitenbasierte ACLs: Auf jeder Seite im Seitenbaum lässt sich direkt definieren, welche Gruppe welche Rechte hat.

**Mandantenfähige TYPO3-Installationen.** Agenturen und Konzerne betreiben mehrere Websites in einer TYPO3-Instanz. Mandant A darf Mandant B nicht sehen, nicht einmal im Seitenbaum. be_acl setzt diese Trennung durch, ohne für jeden Mandanten eine eigene TYPO3-Installation zu betreiben. Bei einer Agentur mit 12 Mandanten in einer TYPO3-Instanz reduzierte be_acl die Administrationszeit für Berechtigungen um circa 60%.

**Freigabe-Workflows mit eingeschränkter Bearbeitungstiefe.** Externe Dienstleister oder Praktikanten sollen Content-Texte bearbeiten, aber keine Bilder hochladen, keine Seiten verschieben und keine Plugins konfigurieren. be_acl erlaubt Rechte auf Feldebene: Der Benutzer sieht das Textfeld, aber nicht die Layout-Einstellungen oder die Plugin-Konfiguration.

## Technical architecture

be_acl erweitert TYPO3s Backend-Berechtigungssystem um ein ACL-Layer, das zwischen dem Core-Rechtesystem und der Benutzerinteraktion sitzt. Die Extension speichert Berechtigungsregeln in der Tabelle `tx_beacl_acl`, die pro Seite und pro Gruppe definiert, welche Operationen erlaubt sind.

Das System arbeitet mit drei Rechteebenen: Lesen (show), Bearbeiten (edit) und Löschen (delete). Diese Rechte werden pro Seite oder rekursiv für einen Seitenbaum vergeben. Die Konfiguration erfolgt über ein eigenes Tab im Seiteneigenschaften-Dialog: Dort wählt der Administrator eine Benutzergruppe und setzt die gewünschten Rechte per Checkbox.

Intern greift be_acl in TYPO3s `BackendUserAuthentication` ein und erweitert die `doesUserHaveAccess`-Prüfung. Bei jedem Seitenzugriff im Backend prüft TYPO3 zuerst die Standard-Rechte und anschließend die ACL-Regeln. Die ACL-Regeln können Standard-Rechte erweitern, aber nicht einschränken. Das ist ein wichtiges Architekturdetail: Wenn eine Gruppe über die Standard-Rechte bereits Zugriff hat, kann be_acl diesen nicht entziehen.

Die Rechte-Auflösung folgt einer Kaskade: Benutzer-Rechte schlagen Gruppen-Rechte, Gruppen-Rechte schlagen Untergruppen-Rechte, und seitenspezifische ACLs schlagen rekursiv vererbte ACLs. Diese Kaskade funktioniert zuverlässig, solange die Gruppenstruktur flach bleibt. Ab 4 verschachtelten Gruppenebenen wird das Verhalten schwer vorhersagbar.

## Common problems and solutions

**Berechtigungen greifen nicht wie erwartet.** Häufigste Ursache: Der Benutzer ist Mitglied in mehreren Gruppen, und die Rechte einer Gruppe überschreiben die ACL-Einschränkung einer anderen. TYPO3s Rechtesystem arbeitet additiv, das heißt, der Benutzer erhält die Summe aller Rechte seiner Gruppen. Lösung: Berechtigungsmatrix erstellen, alle Gruppen eines Benutzers dokumentieren und Überschneidungen eliminieren.

**Performance-Probleme bei großen Seitenbäumen.** Bei TYPO3-Installationen mit mehr als 5.000 Seiten und 20+ Benutzergruppen kann die ACL-Prüfung den Seitenbaum im Backend spürbar verlangsamen. Die Extension prüft bei jedem Seitenaufruf die ACL-Tabelle. Lösung: Caching der ACL-Prüfungen aktivieren und den Seitenbaum über `options.pageTree.excludeDoktypes` auf relevante Seitentypen einschränken.

**Rechte-Debugging ist schwierig.** TYPO3 bietet kein eingebautes Tool, das anzeigt, warum ein Benutzer auf eine bestimmte Seite zugreifen kann oder nicht. Der Admin-Bereich "Backend User" zeigt die simulierte Ansicht, aber nicht die Rechte-Kaskade. Lösung: Das TYPO3 System Log analysieren (bei aktiviertem Debug-Modus loggt TYPO3 Zugriffsversuche) oder die SQL-Tabelle `tx_beacl_acl` direkt abfragen.

## Migration and version compatibility

be_acl ist eine der am längsten gepflegten TYPO3-Extensions. Die aktuelle Version unterstützt TYPO3 v11 und v12. Für TYPO3 v13 existiert eine Beta-Version, die auf dem neuen Backend-Modul-System basiert. Die Extension wird aktiv auf GitHub entwickelt, die Maintainer reagieren auf Issues.

Bei der Migration von TYPO3 v11 auf v12 müssen die ACL-Regeln nicht manuell migriert werden, die Datenbanktabelle bleibt kompatibel. Allerdings hat sich die Backend-Modul-Registrierung in v12 geändert, weshalb das be_acl-Konfigurationsmodul ein Update der Extension-Version erfordert.

Für Unternehmen, die auf TYPO3 v13 migrieren, empfiehlt sich vor dem Upgrade ein Export der bestehenden ACL-Regeln. TYPO3 v13 bringt ein überarbeitetes Berechtigungssystem mit, das einige Funktionen von be_acl in den Core übernimmt. Ob die Extension langfristig noch nötig ist, hängt von der Komplexität des Berechtigungskonzepts ab. Gosign analysiert bei TYPO3-Upgrades das bestehende ACL-Setup und empfiehlt die optimale Lösung, ob be_acl, Core-native Rechte oder eine Kombination.

--- bernetshop TYPO3 - Simple Shop | Gosign ---
> Simpler e-commerce extension for TYPO3 than aimeos. For smaller shops with basic requirements: product list, shopping cart, simple payment.

## Nicht jeder TYPO3-Shop braucht ein vollständiges E-Commerce-Framework

Aimeos ist der Standard für E-Commerce in TYPO3. Aber Aimeos ist auch komplex: eigene Datenbank-Abstraktionsschicht, eigenes Template-System, über 30 Konfigurationstabellen. Für einen Verein, der 8 Merchandise-Artikel verkauft, oder ein mittelständisches Unternehmen mit 50 Ersatzteilen ist das Overkill. bernetshop bietet eine leichtgewichtige Alternative: Produktliste, Warenkorb, Bezahlung, fertig. Keine Warenwirtschaft, kein Lagermanagement, keine Multi-Store-Fähigkeit, aber auch kein monatelanger Setup-Aufwand.

Die Extension richtet sich an Organisationen, die wenige Produkte über ihre bestehende TYPO3-Website verkaufen wollen, ohne ein separates Shop-System zu betreiben. Der typische Einsatz: 10-200 Produkte, einfache Varianten (Größe, Farbe), Zahlung per Rechnung, PayPal oder Stripe.

## Typical use cases

**Vereine und gemeinnützige Organisationen.** Sportvereine verkaufen Trikots und Eintrittskarten, kulturelle Einrichtungen bieten Jahreskarten und Publikationen an. Der Shop muss einfach zu pflegen sein, weil ehrenamtliche Mitarbeiter ihn betreuen. bernetshop lässt sich über Standard-TYPO3-Inhaltselemente konfigurieren: Ein Produkt ist ein Datensatz mit Bild, Preis, Beschreibung und Varianten. Kein Schulungsbedarf jenseits der normalen TYPO3-Redaktion.

**Ersatzteil- und Zubehörverkauf.** Maschinenbauer und Gerätehersteller verkaufen Verschleißteile, Zubehör und Verbrauchsmaterial über die Firmenwebsite. Die Produktdaten existieren bereits in TYPO3 (Produktseiten, Datenblätter), bernetshop ergänzt Warenkorb und Bezahlfunktion. Die Produktpflege bleibt dort, wo die technischen Daten ohnehin liegen: im CMS.

**Interne Bestellportale.** Größere Unternehmen nutzen einfache Bestellsysteme für Bürobedarf, Werbematerial oder IT-Zubehör. bernetshop mit TYPO3 Frontend-Login ergibt ein passwortgeschütztes Bestellportal ohne externe Software. Die Bestellungen werden per E-Mail an den zuständigen Bereich weitergeleitet, eine ERP-Anbindung ist nicht vorgesehen und in diesem Kontext nicht nötig.

## Technical architecture

bernetshop basiert auf Extbase/Fluid, dem Standard-Framework für TYPO3-Extensions. Die Produktdaten werden in einer eigenen Tabelle `tx_bernetshop_domain_model_product` gespeichert. Varianten (Größen, Farben) sind als Inline-Relationen modelliert. Der Warenkorb wird in der PHP-Session gehalten und bei registrierten Benutzern optional in der Datenbank persistiert.

Die Shop-Logik ist überschaubar: Es gibt Controller für Produktliste, Produktdetail, Warenkorb und Checkout. Die Templates sind Standard-Fluid und lassen sich wie jedes andere TYPO3-Template anpassen. Das Zahlungs-Handling erfolgt über einen Payment-Provider-Adapter: PayPal, Stripe und Rechnung sind standardmäßig implementiert. Weitere Anbieter lassen sich über ein PHP-Interface ergänzen.

Die Bestellungen werden in einer Datenbanktabelle gespeichert und lösen eine Bestätigungs-E-Mail an Kunde und Shop-Betreiber aus. Ein Backend-Modul zeigt alle Bestellungen mit Status (offen, bezahlt, versendet). Export als CSV ist integriert, eine direkte ERP-Schnittstelle nicht.

Die Extension nutzt TYPO3s Standard-Caching für Produktlisten. Der Warenkorb und Checkout-Bereich sind uncacheable (USER_INT). Das bedeutet: Produktlistenseiten profitieren vom TYPO3-Cache, der Checkout läuft ohne Cache, was bei hoher Last relevant wird.

## Common problems and solutions

**Skalierungsgrenzen ab 200 Produkten.** Die Produktliste wird bei steigender Produktzahl langsam, wenn keine Paginierung konfiguriert ist. bernetshop liefert eine einfache Paginierung mit, aber keine facettierte Suche oder Kategorie-Filter. Lösung: Ab 200 Produkten Kategorie-Seiten anlegen und die Produktliste pro Kategorie begrenzen. Ab 500 Produkten sollte man ernsthaft über Aimeos oder einen externen Shop nachdenken.

**Zahlungsintegration veraltet.** Die mitgelieferten Payment-Adapter nutzen teilweise ältere API-Versionen der Zahlungsanbieter. PayPals Classic API ist abgekündigt, Stripe hat seine API mehrfach aktualisiert. Lösung: Die Payment-Adapter prüfen und auf aktuelle API-Versionen aktualisieren. Der Aufwand pro Adapter liegt bei 1-2 Entwicklertagen.

**Rechtliche Anforderungen nicht vollständig abgedeckt.** Widerrufsrecht, Grundpreisangabe, Verpackungsverordnung und die ab 2024 verschärften Informationspflichten im E-Commerce erfordern Anpassungen, die bernetshop nicht out-of-the-box liefert. Lösung: Die Checkout-Templates um die rechtlich erforderlichen Informationen ergänzen. Das ist Template-Arbeit, keine Extension-Entwicklung.

## Migration and version compatibility

bernetshop ist eine Nischen-Extension mit begrenzter Pflege. Die letzte stabile Version unterstützt TYPO3 v10 und v11. Für TYPO3 v12 existiert kein offizielles Update, der Portierungsaufwand ist überschaubar (Extbase-API-Änderungen, TCA-Anpassungen), aber er muss manuell geleistet werden. Für TYPO3 v13 gibt es keine Planung.

Unternehmen, die auf TYPO3 v12 oder v13 migrieren, stehen vor der Entscheidung: bernetshop portieren oder auf eine Alternative wechseln. Die Optionen sind Aimeos (vollwertiges E-Commerce-Framework, deutlich höherer Aufwand), cart (Extbase-basierter Shop mit aktiver Pflege und v12-Kompatibilität) oder ein externer Shop (Shopify, WooCommerce) mit TYPO3-Integration über API.

Die Migration der Produktdaten ist in jedem Fall einfach: Die Tabelle hat eine klare Struktur, die sich per SQL-Script in jedes Zielsystem überführen lässt. Bei einem Kunden mit 85 Produkten dauerte die komplette Migration von bernetshop auf EXT:cart inklusive Template-Anpassung 4 Arbeitstage. Gosign berät zur wirtschaftlichsten Option und übernimmt bei Bedarf die Portierung oder Migration.

--- Image Database TYPO3 - Asset Management | Gosign ---
> Image database in TYPO3: digital asset management, auto-tagging, search. FAL extension or external DAM integration.

## Ab 5.000 Bildern wird TYPO3s FAL zum Engpass

TYPO3s File Abstraction Layer verwaltet Dateien zuverlässig, solange die Menge überschaubar bleibt. Bei 500 Bildern funktioniert FAL einwandfrei. Bei 5.000 wird die Suche langsam. Bei 20.000 ist die Dateiliste im Backend kaum noch nutzbar. Unternehmen mit großen Bildbeständen brauchen mehr als ein Dateisystem: Sie brauchen ein Digital Asset Management. Die Frage ist, ob man TYPO3s FAL zum DAM ausbaut oder ein externes System anbindet.

Beide Wege funktionieren. Der interne Ausbau über FAL-Erweiterungen kostet weniger und bleibt im TYPO3-Ökosystem. Die externe Anbindung (Celum, Canto, Cloudinary, Bynder) bietet mehr Funktionen, erfordert aber Lizenzen, Schnittstellen-Pflege und doppelte Datenhaltungslogik.

## Typical use cases

**Produzierende Unternehmen mit Produktfotografie.** Ein Maschinenbauer hat 8.000 Produktfotos in verschiedenen Auflösungen, dazu CAD-Renderings, Anwendungsbilder und Datenblätter. Jedes Produkt existiert in 5-10 Bild-Varianten. Ohne systematische Verschlagwortung finden Redakteure das richtige Bild nicht, oder schlimmer, sie verwenden ein veraltetes. Auto-Tagging per KI analysiert Bildinhalte und vergibt Tags automatisch. Bei einem Kunden mit 12.000 Produktbildern reduzierte KI-basiertes Auto-Tagging die Verschlagwortungszeit von 3 Wochen auf 2 Tage.

**Medienunternehmen und Verlage.** Nachrichtenportale, Magazine und Corporate-Publishing-Abteilungen produzieren täglich neues Bildmaterial. Die Anforderungen: schnelle Suche, Rechteverwaltung (Lizenzablauf, Nutzungsrechte pro Kanal), automatische Formatkonvertierung und Metadaten-Vererbung. Ein erweitertes FAL mit Custom-Feldern deckt die Basisfunktionen ab. Für Rechteverwaltung und Workflow-Steuerung braucht es ein externes DAM.

**Hochschulen und Forschungseinrichtungen.** Universitäten verwalten Campusbilder, Veranstaltungsfotos, Forschungsgrafiken und Portraits der Mitarbeitenden. Die Herausforderung: dezentrale Zulieferung aus 30+ Fachbereichen in ein zentrales System. TYPO3 FAL mit Kategorie-basierter Ordnerstruktur und Zugriffsrechten pro Benutzergruppe löst das. Externe DAM-Systeme sind hier selten wirtschaftlich.

## Technical architecture

TYPO3s FAL besteht aus drei Schichten: dem Storage Driver (lokales Dateisystem, S3, Azure), dem File Index (Datenbanktabelle `sys_file` mit Metadaten) und dem File Reference System (Verknüpfung zwischen Dateien und Content-Elementen). Eine Bilddatenbank in TYPO3 erweitert primär die mittlere Schicht, den File Index.

Die einfachste Erweiterung: Custom-Felder in der Tabelle `sys_file_metadata`. TYPO3 bringt bereits Felder wie `title`, `description`, `alternative` und `copyright` mit. Über TCA lassen sich beliebige weitere Felder ergänzen: `photographer`, `license_type`, `expiry_date`, `usage_rights`, `location`, `keywords_auto`. Diese Felder erscheinen im Datei-Metadaten-Dialog im Backend.

Für die Suche bietet TYPO3 standardmäßig nur eine Dateiname-Suche im File List Modul. Eine echte Volltextsuche über alle Metadaten erfordert entweder eine Solr-Integration (über EXT:solrfal) oder ein Custom Backend-Modul mit Elasticsearch-Anbindung. Solr durchsucht dann nicht nur Dateinamen, sondern alle Metadatenfelder, einschließlich automatisch generierter Tags.

Auto-Tagging per KI funktioniert über einen Scheduler-Task, der neue Dateien an einen Bilderkennungsdienst sendet (Google Cloud Vision, AWS Rekognition oder ein selbstgehostetes Modell) und die erkannten Tags in die Metadaten-Felder schreibt. Der Prozess ist asynchron und belastet das Backend nicht. Bei Erstimport großer Bestände rechnet man mit circa 1 Sekunde pro Bild für die API-Analyse.

## Common problems and solutions

**FAL-Index und Dateisystem laufen auseinander.** Wenn Dateien per FTP hochgeladen oder manuell gelöscht werden, stimmt der FAL-Index nicht mehr mit dem Dateisystem überein. TYPO3 zeigt Dateien an, die nicht existieren, oder kennt vorhandene Dateien nicht. Lösung: Den FAL-Indexer regelmäßig per Scheduler laufen lassen (empfohlen: täglich nachts). Der Indexer gleicht Dateisystem und Datenbank ab. Bei 50.000 Dateien dauert der Abgleich circa 10-15 Minuten.

**Metadaten gehen bei TYPO3-Upgrades verloren.** Custom-Felder in `sys_file_metadata` überleben TYPO3-Upgrades, wenn sie über eine eigene Extension definiert sind. Werden sie direkt in der TCA-Override-Datei des Sitepackages definiert, können sie bei strukturellen Änderungen der Metadaten-Tabelle verloren gehen. Lösung: Bilddatenbank-Felder immer in einer eigenen kleinen Extension kapseln, nicht im Sitepackage.

**Backend-Performance bei großen Dateibäumen.** Das File List Modul wird ab 1.000 Dateien pro Ordner träge, weil es Thumbnails für jedes Bild generiert. Lösung: Ordnerstruktur mit maximal 500 Dateien pro Verzeichnis anlegen und die Thumbnail-Generierung im File List auf "on demand" umstellen.

## Migration and version compatibility

TYPO3s FAL ist seit Version 6.0 (2012) Bestandteil des Core und wird mit jeder Major-Version weiterentwickelt. Die FAL-API ist stabil, Custom-Felder und Indexer funktionieren von TYPO3 v10 bis v13 ohne Anpassungen. Die Solr-FAL-Extension (EXT:solrfal) unterstützt TYPO3 v12, für v13 ist Kompatibilität angekündigt.

Wer von einem externen DAM-System auf TYPO3 FAL migriert, muss die Metadaten mappen. Jedes DAM-System hat ein eigenes Datenmodell. Die Migration selbst ist ein Datenbank-Job: Export aus dem DAM als CSV/JSON, Mapping der Felder auf `sys_file_metadata`, Import per TYPO3 DataHandler oder direktem SQL.

Die Entscheidung "FAL-Ausbau vs. externes DAM" hängt von zwei Faktoren ab: Bestandsgröße und Workflow-Komplexität. Bis circa 10.000 Assets und ohne Freigabe-Workflows reicht erweitertes FAL. Darüber hinaus oder bei Anforderungen wie automatischer Lizenzverwaltung und Multi-Channel-Distribution lohnt sich ein spezialisiertes DAM mit TYPO3-Connector. Gosign berät zu beiden Varianten und implementiert sowohl FAL-Erweiterungen als auch DAM-Integrationen.

--- Booking TYPO3 - Booking System | Gosign ---
> Booking system for TYPO3: appointment booking, availability, payment. Custom development, AI-accelerated.

## Appointment booking on the website fails in TYPO3 because no single extension is production-ready

Organizations with consulting appointments, room rentals or course offerings want to integrate online booking directly into their TYPO3 website. The expectation: calendar, availability check, payment, confirmation email - all from a single source. The reality: there is no single booking extension in the TYPO3 Extension Repository (TER) that covers all these requirements in a production-ready way. The available solutions (jcc_appointment, cab_single_booking, various custom developments) serve niche cases or are no longer actively maintained.

That is why a TYPO3 booking system is almost always a hybrid: a base extension or custom development for the core logic, combined with payment providers (Stripe, PayPal, Mollie) and calendar interfaces (iCal, Google Calendar API). Gosign has implemented this approach in over 15 projects.

## Typical use cases

**Consulting firms with appointment scheduling.** Tax advisors, law firms, management consultants need a system where clients can see and book available slots. The calendar syncs with the consultant's Outlook or Google Calendar. Payment is optional (billing often happens after the session), but cancellation deadlines and no-show fees must be configurable. A typical setup: 3 consultants, 4 service types, 30-minute slots, 2 locations.

**Seminar and course providers.** Education providers, community colleges and sports clubs offer courses with limited seats. The booking system needs participant lists, waiting lists, group pricing, early-bird discounts and recurring dates (e.g. 10 yoga sessions as a block). Payment at booking time, cancellation with partial refund must be automated.

**Room rental and resource management.** Coworking spaces, conference hotels and sports facilities rent rooms or spaces by the hour. Real-time availability display is critical: no room may be double-booked, even when two users click "Book" simultaneously. Race condition protection at database level is not a nice-to-have - it is mandatory.

## Technical architecture

A production-ready booking system in TYPO3 consists of four layers. The database layer manages resources (rooms, people, equipment), availabilities (time slots, blocked periods, holidays) and bookings (with status: requested, confirmed, canceled, completed). The logic layer checks availability, prevents double bookings and calculates prices. The payment layer communicates with external payment providers through their APIs. The notification layer sends confirmations, reminders and cancellation emails.

For double-booking prevention, there are three approaches: pessimistic locking (SELECT ... FOR UPDATE), optimistic locking (version number in the booking table) or queue-based (booking requests processed sequentially). The choice depends on expected load. Under 100 bookings per day, optimistic locking suffices; for events with 1,000 concurrent accesses, a queue is more robust.

iCal export is standard: every confirmed booking generates an .ics file sent as an attachment in the confirmation email. For bidirectional sync (booking in TYPO3 appears in Google Calendar and vice versa), the Google Calendar API or CalDAV is required.

## Common problems and solutions

**Double bookings despite availability checking.** The most common cause: the check "Is the slot free?" and the insert of the booking do not run in the same database transaction. Between check and insert, milliseconds can pass during which a second user books the same slot. Solution: wrap check and insert in a single transaction with row locking.

**Payment callbacks not arriving.** Stripe and PayPal send payment confirmations via webhook. If the TYPO3 site sits behind a reverse proxy or firewall, the callbacks cannot reach the server. Solution: provide a dedicated route (e.g. `/api/payment/webhook`) for the webhook that is not blocked by TYPO3 caching or .htaccess rules. Testing tools: Stripe CLI (`stripe listen --forward-to`), PayPal Sandbox Webhooks.

**Timezone chaos with international bookings.** When the booker and the resource are in different timezones, errors arise. Solution: store all times internally as UTC, adjust display in the frontend via JavaScript to the user's local timezone.

## Migration and version compatibility

There is no unified booking extension with official TYPO3 v12/v13 support. Most available extensions have stalled at v10 or v11. Those migrating an existing booking system to TYPO3 v12+ have two options: port the custom logic to Extbase/Doctrine (v12-compatible) or extract the booking logic as an API microservice and only render the frontend in TYPO3.

For new developments, an API-first approach is recommended: the booking engine as a REST API (within TYPO3 or as a separate service), the frontend as a web component that can be embedded in any TYPO3 template. This keeps the booking system independent of TYPO3 major upgrades. Gosign has implemented this approach as standard since 2024.

Organizations using an external booking system (Calendly, SimplyBook.me, Timify) and wanting only to embed the interface in TYPO3 have a third option: integrate the external system via iframe or JavaScript widget. This works quickly but has drawbacks: no unified design, privacy concerns (third-party cookies, data transfer to the US) and no control over the booking flow. For GDPR-sensitive industries (healthcare, legal advice, public administration), custom development within TYPO3 or as a dedicated microservice is the cleaner solution.

Gosign estimates a typical booking system project (3 resource types, Stripe payment, email workflows, iCal export) at 15 to 25 development days. Of that, approximately 40% goes to booking logic with availability checking, 25% to payment integration, 20% to email templates and notifications, and 15% to frontend display and testing.

Two aspects are critical for post-launch maintenance. First: payment APIs change. Stripe and PayPal update their APIs regularly, and old versions are retired after 12 to 24 months. A booking system that is not maintained will eventually stop accepting payments. Second: calendar sync must be monitored. OAuth tokens for Google Calendar expire after 7 days if no refresh mechanism is implemented. Gosign sets up monitoring for both scenarios so that outages are detected and resolved within minutes.

--- bootstrap_grids TYPO3 - Grid Layouts | Gosign ---
> Bootstrap grid layouts as TYPO3 content elements. Column layouts without Gridelements overhead.

## bootstrap_grids used to be the fastest shortcut to multi-column layouts in TYPO3 and has become a migration candidate

For years, bootstrap_grids was the pragmatic answer in TYPO3 projects to a recurring editorial requirement: I want to place columns next to each other on a page, without developers having to build custom content elements every time. The extension brings a collection of pre-defined Bootstrap grid layouts as content elements into the backend, so that editors can create two, three or four column layouts directly in the page content. For agencies that delivered many Bootstrap-based websites in short cycles, this was long the most efficient solution.

Today, the picture is more nuanced. With the core extension EXT:container and the significantly improved backend layouts in TYPO3 v11 through v13, there are native alternatives that need less configuration and sit closer to the TYPO3 standard. bootstrap_grids remains relevant in existing projects, but new projects should use it deliberately or not at all.

## Typical use cases

A first scenario is a fast stocktake. A mid-sized website with around 200 pages that is already based on Bootstrap uses bootstrap_grids to make multi-column layouts available without setting up its own sitepackage. Editors pick column layouts from a dropdown and fill the containers with standard content elements.

A second scenario is the retrofit of older relaunches. An association website from 2018 was originally built with bootstrap_grids and has collected 600 content elements inside grid containers over time. On an upgrade from TYPO3 v9 to v11, the question is: migrate or carry forward. Usually bootstrap_grids is kept at first to avoid blocking the upgrade, and the switch to EXT:container follows in a second step.

A third scenario is the transition phase to a modern frontend architecture. A group migrates its web presence from Bootstrap to a Tailwind-based design system. As long as the editorial team has not yet switched to the new editor surface, bootstrap_grids stays in use as a bridge, with a clear expiry date.

A fourth scenario is the emergency solution during an audit. When an existing website gets by without column layouts and certain pages are to be shown multi-column later, bootstrap_grids is the fastest answer: installation, activation, first page with a two-column content area in under an hour. For long-term use, however, this shortcut is rarely the right choice.

## Technical architecture

bootstrap_grids registers its own content elements through TCA overrides and ships Fluid templates for the grid output. At the core, the elements are a thin wrapper around the Bootstrap classes container, row and col-*. The extension maintains its own column containers that become visible through colpos in the backend layout and, if needed, also includes Bootstrap CSS.

Installation runs classically via Composer. In combination with custom sitepackages: bootstrap_grids ships a complete Bootstrap 5 CSS and accompanying JavaScript, which quickly leads to conflicts and double CSS loading on projects with their own design system. In such cases, the bootstrap_grids resources are disabled and only the backend integration is used.

Configuration runs through TsConfig: here teams define which grid variants are offered to editors, which column counts are allowed and which Bootstrap breakpoints are mapped. A clean restriction to a few clearly named variants considerably reduces the confusion in the backend.

## Common problems and solutions

The first problem is the copy-paste trap in the editorial team. Without strict governance, bootstrap_grids quickly produces pages with eight nested containers that nobody maintains any more. The solution is to limit the allowed variants and an editorial guideline that ties the use of column layouts to clear content types.

The second problem is the double loading of Bootstrap CSS. Projects that maintain their own Bootstrap build alongside bootstrap_grids load Bootstrap twice in the worst case. The solution is to fully disable the resources shipped by the extension through TsConfig and only use the project-owned build.

The third problem is migration on TYPO3 upgrades. Anyone moving from v9 to v11 or from v11 to v12 notices that some grid variants are named differently in older Bootstrap versions. The solution is an audit of the grid types in use before the upgrade and a targeted SQL migration run that rewrites old variants to new names.

A fourth problem is inconsistent rendering in the editor preview. The backend often shows grid containers empty or in a reduced form, so that editors cannot see what is actually emitted in the frontend. The solution is a preview rendering directly in the backend module that mirrors the Bootstrap classes and visualises the column widths. The effort is not trivial but pays off quickly on large editorial teams.

## Migration and version compatibility

bootstrap_grids exists for TYPO3 v9 to v12 and is still maintained, with the official TYPO3 v13 state updated in 2025. More important than pure version compatibility is the strategic question whether bootstrap_grids is still the right answer in the project at all. For new projects, EXT:container is recommended: lighter, closer to the core, easier to maintain. For existing projects, a stepwise switch often makes sense, especially when the design system is being reworked anyway.

Gosign migrates existing bootstrap_grids projects to EXT:container or to native backend layouts with colpos. The migration runs script-assisted: existing grid containers are rewritten into container structures via SQL and upgrade wizard, so that editors do not have to touch a single page after the upgrade. This is the fastest way to lift a historical sitepackage into the modern TYPO3 standard without losing content.

--- cHash TYPO3 - Cache Configuration | Gosign ---
> cHash configuration for TYPO3: controls which URL parameters affect the page cache.

## Die meisten "Page not found"-Fehler in TYPO3 include cHash-Probleme

Ein Redakteur legt eine Nachricht mit Paginierung an, die Seite funktioniert. Ein Besucher klickt auf Seite 2, sieht "Page not found". Der Entwickler prüft das Routing, die Seitenkonfiguration, die .htaccess. Alles korrekt. Das Problem sitzt tiefer: TYPO3s cHash-Mechanismus hat den URL-Parameter der Paginierung nicht erwartet und verweigert die Auslieferung. Ein 5-Minuten-Problem, wenn man weiß, wo man suchen muss, ein 2-Tage-Problem, wenn nicht.

cHash (Cache Hash) ist TYPO3s Mechanismus zur Sicherung des Seiten-Caches. Er berechnet einen Hash aus allen URL-Parametern und vergleicht ihn mit dem gespeicherten Cache-Eintrag. Wenn ein unbekannter Parameter auftaucht, den TYPO3 nicht erwartet, wird die Seite nicht ausgeliefert. Das schützt vor Cache-Poisoning, verursacht aber bei fast jeder neuen Extension oder jedem Custom-Filter Probleme.

## Typical use cases

**Filter- und Facettensuche in Produktkatalogen.** Ein Produktkatalog mit 6 Filterkriterien (Kategorie, Preis, Farbe, Material, Verfügbarkeit, Bewertung) erzeugt URL-Parameter wie `&tx_catalog[color]=red&tx_catalog[price]=100-200`. Ohne cHash-Konfiguration zeigt TYPO3 bei jeder Filterkombination "Page not found". Die cHash-Konfiguration muss jeden dieser Parameter kennen, entweder als "required" (beeinflusst den Cache-Key) oder als "excluded" (wird ignoriert und nicht gehasht).

**Paginierung in News- und Event-Listen.** EXT:news und EXT:sf_event_mgt nutzen eigene URL-Parameter für Seitenzahlen (`&tx_news_pi1[@widget_0][currentPage]=2`). Diese Parameter müssen in der cHash-Konfiguration stehen, damit Seite 2 einen eigenen Cache-Eintrag erhält. Fehlt die Konfiguration, wird entweder immer Seite 1 aus dem Cache geliefert (Cache-Pollution) oder die Paginierung schlägt mit 404 fehl.

**Tracking-Parameter und UTM-Tags.** Marketing-Kampagnen hängen UTM-Parameter an URLs: `?utm_source=newsletter&utm_medium=email`. Ohne Ausschluss dieser Parameter erzeugt jeder Kampagnen-Link einen neuen Cache-Eintrag. Bei einer Website mit 500 Seiten und 10 Kampagnen entstehen statt 500 plötzlich 5.000 Cache-Einträge, die den Server belasten und den Cache-Warmup verlangsamen. UTM-Parameter gehören auf die Exclude-Liste.

## Technical architecture

Die cHash-Berechnung findet in TYPO3s Core-Klasse `CacheHashCalculator` statt. Der Algorithmus nimmt alle URL-Parameter, sortiert sie alphabetisch, serialisiert sie und berechnet einen MD5-Hash. Dieser Hash wird als `cHash`-Parameter an die URL angehängt. Beim Seitenaufruf prüft TYPO3, ob der mitgelieferte cHash mit dem berechneten übereinstimmt.

Die Konfiguration erfolgt in `$GLOBALS['TYPO3_CONF_VARS']['FE']['cacheHash']` mit vier Listen:

`cachedParametersWhiteList`: Parameter, die in den Hash einfließen und eigene Cache-Einträge erzeugen. Typisch: Plugin-Parameter (`tx_news_pi1`, `tx_solr`).

`excludedParameters`: Parameter, die komplett ignoriert werden. Typisch: Tracking-Parameter (`utm_source`, `utm_medium`, `utm_campaign`, `utm_content`, `utm_term`, `gclid`, `fbclid`).

`requireCacheHashPresenceParameters`: Parameter, die einen cHash zwingend erfordern. Wenn dieser Parameter ohne cHash in der URL steht, zeigt TYPO3 einen 404-Fehler. Das ist der restriktivste Modus.

`excludedParametersIfEmpty`: Parameter, die nur ignoriert werden, wenn sie leer sind.

Seit TYPO3 v12 lässt sich die cHash-Konfiguration auch über die Site Configuration (config.yaml) steuern, was die Verwaltung in Multi-Site-Setups vereinfacht.

## Common problems and solutions

**"Page not found" nach Extension-Installation.** Neue Extensions bringen eigene URL-Parameter mit. Wenn diese nicht in der cHash-Konfiguration stehen, blockiert TYPO3 die Seite. Lösung: Die Extension-Dokumentation prüfen (gute Extensions liefern cHash-Konfiguration in `ext_localconf.php` mit). Falls nicht: die Parameter manuell in die cachedParametersWhiteList oder excludedParameters eintragen. Im TYPO3 Install Tool unter "Presets" bietet der cHash-Debug-Modus eine Hilfestellung.

**Cache-Pollution durch unkontrollierte Parameter.** Bots und Spam-Crawler hängen zufällige Parameter an URLs. Ohne Schutz erzeugt jeder dieser Aufrufe einen Cache-Eintrag. Der Cache wächst auf Millionen Einträge, die Datenbank wird langsam. Lösung: `excludeAllEmptyParameters = true` setzen und nur explizit bekannte Parameter in die WhiteList aufnehmen. Zusätzlich den Cache-Garbage-Collector auf kürzere Intervalle stellen (Standard: 86.400 Sekunden = 24 Stunden).

**cHash-Fehler schwer zu debuggen.** TYPO3 zeigt nur "Page not found", nicht warum. Im Production-Modus gibt es keine Fehlermeldung, die auf cHash hinweist. Lösung: In `LocalConfiguration.php` temporär `$GLOBALS['TYPO3_CONF_VARS']['FE']['pageNotFoundOnCHashError'] = false` setzen. Dann zeigt TYPO3 die Seite trotz cHash-Fehler an und loggt den Fehler. Nach der Diagnose wieder auf true setzen.

## Migration and version compatibility

cHash ist Core-Funktionalität, keine Extension, und existiert seit TYPO3 v4. Die Konfiguration hat sich über die Versionen verändert: In TYPO3 v8 und früher wurde sie über TypoScript gesteuert, ab v9 über PHP-Arrays in der LocalConfiguration, ab v12 zusätzlich über die Site Configuration.

Bei der Migration von TYPO3 v9/v10 auf v12/v13 müssen bestehende cHash-Konfigurationen geprüft werden. Die Parameter-Namen der Extensions können sich geändert haben (z.B. Extbase-Plugin-Namespace-Änderungen). Der sicherste Weg: Nach dem Upgrade alle Seiten mit Parametern systematisch testen (Paginierung, Filter, Suche) und das TYPO3 Error Log auf cHash-Einträge prüfen.

TYPO3 v13 verschärft die cHash-Prüfung weiter: Unbekannte Parameter führen standardmäßig zu einem 404, der Debug-Modus muss explizit aktiviert werden. Gosign prüft bei jedem TYPO3-Upgrade-Projekt die cHash-Konfiguration als Teil des Qualitätssicherungs-Prozesses.

--- calendarize_news TYPO3 - Calendar | Gosign ---
> Calendar view for GeorgRinger/news: recurring events, date filters, month/week/day view. Connects the news extension with calendar functionality.

## Events in tx_news gehören in einen Kalender, nicht in eine chronologische Liste

Die meisten TYPO3-Websites nutzen Georg Ringers tx_news für alles: Nachrichten, Blog-Artikel, Pressemitteilungen und Events. Für die ersten drei Typen funktioniert die chronologische Listendarstellung. Für Events nicht. Besucher erwarten eine Kalenderansicht mit Monats-, Wochen- und Tagesdarstellung. Sie wollen auf ein Datum klicken und sehen, was an diesem Tag stattfindet. calendarize_news baut genau diese Brücke: Es nimmt bestehende News-Datensätze mit Datumsfeldern und rendert sie als Kalender.

Die Extension spart den Umstieg auf ein eigenständiges Event-System. Wer tx_news bereits im Einsatz hat, behält seine Datenstruktur, seine Templates und seine Redaktionsprozesse. Statt einer zweiten Extension mit separater Datenhaltung gibt es eine Kalender-View auf bestehende Daten.

## Typical use cases

**Veranstaltungskalender auf Unternehmenswebsites.** Ein Bildungsträger veröffentlicht 150 Seminare pro Jahr über tx_news. Jedes Seminar hat ein Startdatum, ein Enddatum und eine Uhrzeit. Ohne calendarize_news sehen Besucher eine lange Liste, sortiert nach Datum. Mit calendarize_news sehen sie einen Monatskalender, klicken auf den 15. Mai und finden drei Seminare. Die Conversion von der Kalenderansicht zur Detailseite lag bei einem Kunden 40% höher als von der Listenansicht.

**Wiederkehrende Events ohne Daten-Duplikation.** Ein wöchentlicher Stammtisch, ein monatliches Webinar, ein jährliches Firmenfest: Ohne Recurrence-Funktionalität muss der Redakteur 52 Datensätze für den Stammtisch anlegen. calendarize_news unterstützt Wiederholungsregeln (täglich, wöchentlich, monatlich, jährlich) mit Ausnahmen. Ein Datensatz erzeugt 52 Kalendereinträge. Fällt ein Termin aus, wird er als Ausnahme markiert, nicht gelöscht.

**Kombinierte News- und Event-Seiten.** Viele Organisationen zeigen auf der Startseite "Aktuelles", eine Mischung aus Nachrichten und anstehenden Events. calendarize_news ermöglicht es, dieselben Datensätze in der News-Liste chronologisch und im Kalender datumbasiert darzustellen. Zwei Views, eine Datenquelle, kein Synchronisationsaufwand.

## Technical architecture

calendarize_news erweitert tx_news um zusätzliche Datenbankfelder in der Tabelle `tx_news_domain_model_news`: Startdatum, Enddatum, Ganztags-Flag, Wiederholungsregel und Ausnahme-Daten. Die Wiederholungslogik ist in der Extension implementiert und generiert virtuelle Termine zur Laufzeit, ohne für jeden Einzeltermin einen Datensatz in der Datenbank anzulegen.

Die Kalenderdarstellung erfolgt über Fluid-Templates, die ein Monats-Grid rendern. Jede Zelle (Tag) enthält die Events dieses Tages. Die Templates sind vollständig anpassbar. Standardmäßig liefert die Extension Templates für Monats-, Wochen- und Tagesansicht. Die Navigation zwischen Monaten erfolgt per AJAX oder klassischem Seitenaufruf, konfigurierbar per TypoScript.

Die Integration mit tx_news ist tief: calendarize_news registriert sich als zusätzliches Plugin (list type) und nutzt tx_news' Repository-Pattern. Kategorien, Tags und Zugriffsbeschränkungen aus tx_news werden übernommen. Ein Event, das der Kategorie "Intern" zugeordnet ist und nur für eingeloggte Benutzer sichtbar sein soll, erscheint auch im Kalender nur nach Login.

Die iCal-Export-Funktion generiert .ics-Dateien für einzelne Events oder den gesamten Kalender. Besucher können Events direkt in Outlook, Apple Kalender oder Google Calendar importieren. Der Export nutzt das iCalendar-Format (RFC 5545) und berücksichtigt Wiederholungsregeln.

## Common problems and solutions

**Kalender zeigt keine Events, obwohl News vorhanden sind.** Häufigste Ursache: Die Datumsfelder der News-Datensätze sind nicht befüllt. tx_news hat ein `datetime`-Feld, aber calendarize_news nutzt eigene Felder für Start- und Enddatum. Nach der Installation müssen bestehende News-Datensätze um die calendarize-Felder ergänzt werden. Lösung: Ein Migrations-Script, das `datetime` in die calendarize-Felder kopiert, dauert 30 Minuten Entwicklungszeit.

**Performance-Probleme bei vielen wiederkehrenden Events.** Wenn 50 wiederkehrende Events jeweils 52 virtuelle Termine erzeugen, muss die Extension 2.600 Einträge für die Monatsansicht filtern. Das ist bei jedem uncached Seitenaufruf spürbar. Lösung: Die Recurrence-Berechnung cachen (calendarize_news unterstützt TYPO3s Caching Framework) und die Zeitspanne begrenzen. Events, die mehr als 12 Monate in der Zukunft liegen, müssen nicht bei jedem Request berechnet werden.

**Responsive Darstellung des Kalender-Grids.** Ein 7-Spalten-Grid für Wochentage funktioniert auf Desktop, aber nicht auf Smartphones. Die Standard-Templates von calendarize_news sind nicht mobil-optimiert. Lösung: Die Fluid-Templates anpassen und auf mobilen Geräten eine Listen-Darstellung statt des Grids rendern. Ein CSS-Breakpoint bei 768px reicht aus, um zwischen Grid und Liste zu wechseln.

## Migration and version compatibility

calendarize_news hängt direkt von tx_news ab und folgt dessen Versions-Zyklus mit Verzögerung. Die aktuelle stabile Version unterstützt TYPO3 v11 und v12 mit tx_news v10/v11. Für TYPO3 v13 existiert eine Beta-Version auf GitHub.

Die Alternative calendarize (ohne _news-Suffix) von lochmueller ist eine eigenständige Kalender-Extension, die nicht auf tx_news aufbaut, sondern ein eigenes Datenmodell mitbringt. Sie wird aktiver gepflegt und unterstützt TYPO3 v12 und v13 offiziell. Der Umstieg von calendarize_news auf calendarize erfordert eine Datenmigration: Die Event-Daten müssen aus der tx_news-Tabelle in die calendarize-Tabellen überführt werden.

Für Projekte, die auf TYPO3 v13 migrieren und tx_news behalten wollen, ist der pragmatischste Weg: die calendarize_news-Beta einsetzen oder die Kalenderdarstellung als Custom Fluid-Template direkt in tx_news bauen. Der Aufwand für ein Custom-Template liegt bei 2-3 Tagen, das Ergebnis ist unabhängig von Drittanbieter-Pflege. Gosign hat beide Wege umgesetzt und empfiehlt je nach Komplexität der Wiederholungsregeln die passende Variante.

--- camaliga TYPO3 - Flexible Lists | Gosign ---
> Flexible list plugin for TYPO3: products, employees, references - all configurable via one extension. Alternative to custom extensions for simple list displays.

## Für die meisten Listen in TYPO3 braucht man keine eigene Extension

Ein Unternehmen will Referenzen auf der Website zeigen: Logo, Kundenname, Branche, Kurzbeschreibung. Ein anderes will Mitarbeiter auflisten: Foto, Name, Abteilung, Telefon. Ein drittes braucht eine Produktübersicht: Bild, Titel, Preis, Link zur Detailseite. Drei verschiedene Anforderungen, ein gemeinsames Muster: strukturierte Listen mit konfigurierbaren Feldern. camaliga löst dieses Muster als generische Listen-Extension, statt für jeden Listentyp eine Custom Extension zu entwickeln.

Die Extension von quizpalme ist seit Jahren im TYPO3 Extension Repository verfügbar und wird aktiv gepflegt. Ihr Vorteil: Ein Datensatz-Typ mit flexiblen Feldern deckt 80% aller Listen-Anforderungen ab. Der Nachteil: Wer sehr spezifische Datenmodelle braucht (verschachtelte Relationen, Mehrsprachigkeit auf Feldebene, komplexe Validierung), stößt an Grenzen.

## Typical use cases

**Referenz- und Kundenlisten.** Der häufigste Einsatz: Logos und Beschreibungen von Kunden oder Projekten in einer Grid-Darstellung. camaliga bringt fertige Layouts mit: Grid, Karussell, Akkordeon, Tab-Darstellung. Die Daten werden im TYPO3-Backend als Datensätze gepflegt, die Darstellung über Fluid-Templates gesteuert. Bei einem Kunden mit 120 Referenzen war die camaliga-basierte Referenzseite in 3 Tagen live, inklusive Filterung nach Branche.

**Team- und Mitarbeiterseiten.** Foto, Name, Position, Kontaktdaten, optional ein Kurztext. camaliga bildet das über seine Standard-Felder ab: Titel, Untertitel, Bild, Beschreibung, Link. Für zusätzliche Felder (Telefonnummer, Abteilung) lassen sich Custom-Felder über TCA-Override ergänzen. Die Alternative wäre EXT:tt_address, die aber auf Adressdaten spezialisiert ist und für Teamseiten oft zu viel und gleichzeitig zu wenig bietet.

**Einfache Produktübersichten ohne Shop-Funktionalität.** Unternehmen, die Produkte darstellen, aber nicht verkaufen wollen, brauchen keinen Shop. camaliga liefert eine Produktliste mit Bild, Titel, Preis-Feld und Link zum Datenblatt. Filterung nach Kategorie ist über die integrierte Kategorie-Zuordnung möglich. Für 50-200 Produkte ohne Warenkorb ist das effizienter als Aimeos oder bernetshop.

## Technical architecture

camaliga basiert auf Extbase/Fluid und folgt dem MVC-Pattern. Der zentrale Datensatz-Typ heißt `tx_camaliga_domain_model_content` und enthält Felder für Titel, Untertitel, Beschreibung, Kurzbeschreibung, Bild, Link, Kategorie und mehrere Custom-Felder. Die Felder sind im TCA definiert und lassen sich über TCA-Override im Sitepackage erweitern oder reduzieren.

Die Darstellung erfolgt über ein Frontend-Plugin mit konfigurierbarem Layout. Im Plugin-FlexForm wählt der Redakteur: Welche Kategorie anzeigen, welches Layout verwenden, wie viele Einträge pro Seite, ob Paginierung aktiv ist. Die Layouts sind Fluid-Templates, die im Sitepackage überschrieben werden. camaliga liefert circa 15 fertige Layouts mit, von der einfachen Liste bis zum gefilterten Grid mit Isotope-Animation.

Die Kategorie-Filterung nutzt TYPO3s System-Kategorien. Jeder camaliga-Datensatz kann einer oder mehreren Kategorien zugeordnet werden. Im Frontend wird ein Filter-Menü generiert, das per JavaScript (Isotope oder CSS-Filter) oder per Seitenaufruf filtert. Die JavaScript-Variante ist schneller, die Seitenaufruf-Variante SEO-freundlicher.

Für die Sortierung bietet camaliga mehrere Optionen: nach Titel, nach Erstellungsdatum, nach manueller Sortierung (Drag-and-Drop im Backend). Die manuelle Sortierung nutzt das `sorting`-Feld der Datenbank und funktioniert über TYPO3s Standard-Sortierungsmechanismus im List-Modul.

## Common problems and solutions

**Layouts sehen anders aus als erwartet.** camalias mitgelieferte Layouts setzen auf bestimmte CSS-Frameworks (Bootstrap 3/4) oder JavaScript-Libraries (Isotope, Masonry). Wenn die Website ein anderes Framework nutzt, kollidieren die Styles. Lösung: Nie die Standard-Templates verwenden, sondern eigene Fluid-Templates im Sitepackage anlegen. Der Aufwand für ein eigenes Template liegt bei 1-2 Stunden, danach ist die Darstellung vollständig kontrollierbar.

**Performance bei mehr als 500 Datensätzen.** camaliga lädt standardmäßig alle Datensätze einer Kategorie und filtert im Frontend per JavaScript. Bei 500+ Einträgen wird die initiale Ladezeit spürbar (3-5 Sekunden bei 1.000 Datensätzen mit Bildern). Lösung: Paginierung aktivieren und die Seitenanzahl auf 20-50 Einträge begrenzen. Für JavaScript-basierte Filterung: Lazy Loading der Bilder aktivieren und die Datenmenge per AJAX nachladen.

**Mehrsprachigkeit erfordert Workaround.** camaliga unterstützt TYPO3s Sprachhandling, aber die Übersetzung jedes einzelnen Datensatzes ist bei 200+ Einträgen aufwändig. Lösung: Für rein visuelle Listen (Logos ohne Text) reicht ein Datensatz pro Sprache. Für textlastige Listen die Übersetzung per TYPO3s Inline-Translation-Workflow beschleunigen oder ein Migrations-Script schreiben, das DeepL-API-Übersetzungen in die Sprachversionen importiert.

## Migration and version compatibility

camaliga wird aktiv gepflegt und unterstützt TYPO3 v11, v12 und nach aktueller Roadmap auch v13. Die Extension folgt dem TYPO3-Release-Zyklus mit kurzer Verzögerung. Composer-Installation über Packagist ist möglich, TER-Installation ebenfalls.

Wer von einer Custom Extension auf camaliga migriert, muss die Daten aus der Custom-Tabelle in `tx_camaliga_domain_model_content` überführen. Das ist ein SQL-Job, der sich in den meisten Fällen in unter einem Tag erledigen lässt. In die andere Richtung: Wer von camaliga auf eine eigene Extbase-Extension umsteigt, kann die Datenstruktur als Vorlage nutzen.

Für komplexere Anforderungen (verschachtelte Datensätze, Relationen zwischen Listen, Workflow-Steuerung) empfiehlt sich statt camaliga eine Custom Extbase Extension oder EXT:mask. Gosign berät zur passenden Lösung und implementiert sowohl camaliga-basierte Schnelllösungen als auch individuelle Extensions.

--- CAPTCHA TYPO3 - Spam Protection | Gosign ---
> Spam protection for TYPO3 forms. Gosign advises between visible CAPTCHAs (sr_freecap, hCaptcha), invisible (reCAPTCHA v3) and cookieless alternatives.

## Why choosing a CAPTCHA is a privacy question, not a technical one

CAPTCHA sounds like a trivial decision: protect the form against bots, install an extension, done. In practice, the question is which service you embed, which consent you trigger and which conversion rate you accept. For TYPO3 there are a dozen approaches that fall into three groups: visible CAPTCHAs with a visual task, invisible behavioural analyses such as reCAPTCHA v3 and purely server-side methods without user interaction such as honeypots or rate limiting. The right choice depends less on the strength of the bots than on the regulatory starting point and the audience of the form.

## Typical use cases

A B2B software vendor runs a contact form with around 300 genuine enquiries per month and around 8,000 bot submissions. The vendor already uses Google Analytics, has a consent solution in place and does not lose any legal ground by adding reCAPTCHA v3. In this case, the invisible solution is effective: bots are blocked behind the scenes, real users see nothing, the conversion rate stays stable. Consent is already handled by the existing consent banner.

A municipal administration with online forms for citizen services faces the opposite situation: Google must not be embedded, consent banners should be kept minimal, and the form has to work even without JavaScript. Here reCAPTCHA is out of the question. The combination of a honeypot plus rate limiting on the reverse proxy plus a simple arithmetic task in the form catches 95 percent of bots, requires no external resource and does not trigger any consent obligation.

A third case is an educational institution with a strongly varying user base: students, lecturers, external applicants, some with visual impairments. Here accessibility matters more than any security gain, and a purely visual CAPTCHA is problematic. The solution is an hCaptcha setup with accessibility mode enabled or an sr_freecap instance with an audio alternative, complemented by a fully accessible labelling.

## Technical architecture: three categories, three integration patterns

Visible CAPTCHAs such as sr_freecap or hCaptcha work through a request response mechanism: the extension generates or fetches a task, shows it to the user, and on submission the input is validated server-side. In TYPO3, integration happens through a validator in the form framework, through a Fluid ViewHelper extension or, in Powermail, through the captcha field plug-in. The technical challenge is session synchronisation and integration with existing Fluid templates.

Invisible CAPTCHAs such as reCAPTCHA v3 compute a score between 0 and 1 that describes the probability that the request is human. The score comes in as an additional field with the form submission, and the extension decides based on a configurable threshold whether the submission is accepted or discarded. The big advantage is that the user notices nothing, the disadvantage is the unavoidable data transfer to Google.

Honeypot-based solutions work without client-side logic: an invisible input field is added to the HTML form, hidden via CSS or tabindex=-1. Humans do not fill it in, bots very often do, and every submission with a populated honeypot is discarded server-side. Combined with IP-based rate limiting and a verifiable time interval between page view and submission, this blocks the majority of simple bots without bothering a single user.

## Common problems and solutions

The first problem is the choice itself: teams reflexively reach for reCAPTCHA because it is well known and free, and miss the consent obligation. A clean decision requires a short assessment: which consent infrastructure is in place? Which audience should use the form? How high is the actual bot load? Gosign runs this assessment as part of a short audit and recommends the appropriate method per form instead of forcing a one-size-fits-all solution.

The second problem is the combination of multiple protective mechanisms. Anyone running a honeypot, a CAPTCHA and rate limiting in parallel creates redundancy but also failure points: a legitimate user stumbles at one of the three steps and loses trust in the form. The pragmatic answer is to layer methods and only activate the most demanding protection on suspicious behaviour, for example showing a CAPTCHA only once the honeypot has triggered or several submissions from the same IP have arrived in a short time.

The third topic is monitoring. Teams install a protection and forget that its effectiveness drops once bots develop adapted behaviour patterns. An effective CAPTCHA setup logs spam rate and false positive rate and updates the thresholds when the numbers shift. Gosign sets up this monitoring as part of the extension integration and delivers a monthly evaluation, so that it becomes visible when a vendor switch or an adjustment is needed.

## Migration and version compatibility

In TYPO3 v12 and v13, the form framework is the central integration point for CAPTCHA solutions. Extensions that still rely on the old form builder or the mailform type from the core era have to be converted to the new framework on upgrade, which usually also forces a fresh choice of CAPTCHA approach. Powermail remains a popular alternative and ships its own CAPTCHA field types, which are maintained in parallel.

Anyone migrating from reCAPTCHA to a GDPR-friendly solution saves not only a consent obligation but often gains load time as well: the reCAPTCHA script is several hundred kilobytes and is loaded by every page that contains a form. A honeypot setup works without any external script. Gosign has accompanied such migrations several times and, depending on the operating model, delivers either a pure honeypot setup or a combination with a local arithmetic task that is trivial for humans and a noticeable hurdle for bots.

--- Cloudinary TYPO3 - CDN & Images | Gosign ---
> Cloudinary as TYPO3 FAL driver. Automatically optimize images (WebP/AVIF), transform (crop, resize) and deliver worldwide via CDN.

## Bilder include der größte Performance-Killer auf TYPO3-Websites, und Cloudinary löst das automatisch

Bei 90% der TYPO3-Websites, die schlecht bei Core Web Vitals abschneiden, sind Bilder das Problem. Zu groß, falsches Format, keine responsiven Varianten, kein CDN. TYPO3s internes Image Processing (GraphicsMagick/ImageMagick) erzeugt zwar Thumbnails, aber keine Format-Optimierung (WebP/AVIF), keine intelligente Crop-Erkennung und keine automatische Auslieferung über ein weltweites CDN. Cloudinary als TYPO3 FAL-Treiber löst alle drei Probleme in einem Schritt.

Cloudinary speichert die Originalbilder in seiner Cloud, erzeugt on-the-fly optimierte Varianten und liefert sie über 300+ Edge-Locations weltweit aus. Ein Bild, das als 4 MB JPEG hochgeladen wurde, kommt beim Besucher als 120 KB AVIF an, automatisch, ohne dass der Redakteur etwas tun muss.

## Typical use cases

**Medienintensive Unternehmenswebsites.** Ein Automobilzulieferer mit 3.000 Produktbildern, davon jedes in 5 Varianten (Thumbnail, Listenbild, Detailbild, Zoom, Download), hat ohne Cloudinary 15.000 Dateien auf dem Server. Mit Cloudinary werden 3.000 Originale gespeichert, die 15.000 Varianten erzeugt Cloudinary bei Bedarf. Der Server-Speicher sinkt um 80%, die Ladezeiten um 60%. Der Largest Contentful Paint (LCP) verbesserte sich bei einem Kunden von 4,1 auf 1,3 Sekunden.

**Internationale Websites mit globalem Publikum.** Wenn Besucher aus Brasilien, Japan und Deutschland dieselbe Seite aufrufen, liefert Cloudinary die Bilder jeweils vom nächstgelegenen Edge-Server. Ohne CDN dauert das Laden eines 500 KB Bildes von einem Server in Frankfurt für einen Besucher in Tokio 2-3 Sekunden. Mit Cloudinary unter 200 Millisekunden.

**Redaktionelle Portale mit hohem Bildvolumen.** News-Portale und Magazine laden täglich neue Bilder hoch. Cloudinary entlastet den Upload-Prozess: Bilder werden direkt an Cloudinary gesendet (Upload Widget oder API), verarbeitet und erst der Referenzpfad in TYPO3 gespeichert. Das spart Server-Last und beschleunigt den Redaktions-Workflow.

## Technical architecture

Die Cloudinary-Integration in TYPO3 erfolgt über einen FAL-Treiber (File Abstraction Layer Driver). Die Extension registriert sich als Storage-Treiber und überschreibt die Standard-Dateioperationen: Upload, Download, Löschen, Auflisten. Redakteure arbeiten im gewohnten TYPO3-Backend, sehen Bilder in der Filelist und fügen sie wie gewohnt in Content-Elemente ein.

Die URL-Generierung ist der Kern der Integration. Statt einer lokalen Datei-URL (`/fileadmin/images/produkt.jpg`) generiert der Treiber eine Cloudinary-URL mit Transformations-Parametern: `https://res.cloudinary.com/[cloud-name]/image/upload/f_auto,q_auto,w_800/produkt.jpg`. Die Parameter `f_auto` (automatische Formaterkennung: WebP für Chrome, AVIF für Firefox, JPEG für alte Browser) und `q_auto` (automatische Qualitätsanpassung) sind der Standard.

Transformationen werden über URL-Parameter gesteuert: Breite (`w_`), Höhe (`h_`), Crop-Modus (`c_fill`, `c_fit`, `c_thumb`), Fokuspunkt-Erkennung (`g_auto` erkennt Gesichter und wichtige Bildbereiche), Overlay und Wasserzeichen. Jede Kombination erzeugt eine eigene Variante, die Cloudinary beim ersten Aufruf generiert und anschließend cachet.

Die responsive Breakpoint-Generierung ist besonders wertvoll: Cloudinary analysiert ein Bild und berechnet die optimalen Breakpoints basierend auf der tatsächlichen visuellen Änderung zwischen den Größen. Statt fester Breakpoints bei 320, 768 und 1024 Pixeln liefert Cloudinary beispielsweise 347, 691, 1024, weil dort die visuell größten Unterschiede liegen. Das spart Bandbreite ohne sichtbaren Qualitätsverlust.

## Common problems and solutions

**Kosten-Kontrolle bei hohem Traffic.** Cloudinary rechnet nach Credits ab: Transformationen, Speicher und Bandbreite verbrauchen Credits. Der kostenlose Plan reicht für circa 25.000 Transformationen pro Monat. Eine TYPO3-Website mit 500 Seiten und 3.000 Bildern kann das im ersten Monat überschreiten, wenn der Cache leer ist. Lösung: Cloudinary-Cache-Invalidierung nur bei tatsächlichen Bildänderungen auslösen, nicht bei jedem Deploy. Den Fetch-Format auf `auto` stellen, damit Cloudinary nur die nötigen Formate generiert.

**Bildersuche im TYPO3-Backend ist langsam.** Der FAL-Treiber muss bei jeder Suche die Cloudinary-API abfragen. Bei 10.000+ Bildern dauert das spürbar. Lösung: Den TYPO3 FAL-Index als primäre Suchquelle nutzen und nur bei Bedarf gegen Cloudinary synchronisieren. Der Indexer-Scheduler sollte nachts laufen, nicht bei jedem Backend-Zugriff.

**Bestehende Bild-URLs ändern sich.** Nach der Migration von lokalem Speicher auf Cloudinary ändern sich alle Bild-URLs. Das betrifft SEO (Google Image Search), externe Verlinkungen und gecachte Seiten. Lösung: Cloudinary-URLs generieren und gleichzeitig 301-Redirects von den alten Pfaden auf die neuen URLs einrichten. TYPO3s EXT:redirects kann das automatisiert.

## Migration and version compatibility

Die offizielle TYPO3-Cloudinary-Extension auf GitHub unterstützt TYPO3 v11 und v12. Für v13 ist Kompatibilität in Arbeit. Die Extension wird von der TYPO3-Community gepflegt, nicht von Cloudinary selbst.

Die Migration von lokalem Speicher auf Cloudinary erfolgt in vier Schritten: erstens einen Cloudinary-Account anlegen und den API-Key konfigurieren, zweitens die bestehenden Dateien per Bulk-Upload (Cloudinary CLI oder API) hochladen, drittens die TYPO3 File Storage Konfiguration auf den Cloudinary-Treiber umstellen und viertens den FAL-Index neu aufbauen. Bei 5.000 Dateien dauert der gesamte Prozess circa einen Arbeitstag.

Cloudinary bietet einen kostenlosen Plan (25 Credits/Monat), der für kleine Websites ausreicht. Für Unternehmenswebsites mit 10.000+ Bildern und hohem Traffic liegt der Plus-Plan bei circa 89 USD/Monat. Gosign hat Cloudinary-Integrationen für TYPO3-Projekte mit bis zu 100.000 Bildern umgesetzt und berät zu Kosten-Optimierung und Transformations-Strategien.

--- CORS TYPO3 - Cross-Origin Header | Gosign ---
> Configuration of Cross-Origin Resource Sharing headers for TYPO3. Necessary for API access, headless TYPO3 or microservice architectures. Security-critical.

## Why headless TYPO3 projects fail immediately without a correct CORS configuration

As soon as a TYPO3 system no longer just renders HTML but delivers JSON APIs to JavaScript clients on other domains, the browser hits the Same-Origin Policy. Without explicit Cross-Origin Resource Sharing (CORS) headers, it blocks every fetch call that originates from a different origin than the API itself. For every headless TYPO3 approach, every microservice integration and every setup in which a frontend on app.example.com talks to a backend on cms.example.com, a clean CORS configuration is the basic prerequisite. It does not live in an extension alone but is an interplay of TYPO3 middleware, web server configuration and reverse proxy setup.

## Typical use cases

An e-commerce retailer with 40,000 orders per month runs a product catalogue in TYPO3 and a React-based storefront on a separate domain. The storefront queries product data, stock levels and price information through a JSON API implemented as TYPO3 middleware. Without correct CORS headers, the browser blocks every AJAX call with the error message "has been blocked by CORS policy", and the storefront stays empty. The solution is a middleware that sets Access-Control-Allow-Origin precisely to the known frontend domains and answers preflight OPTIONS requests correctly.

A second case is a company that runs TYPO3 as a content hub for several brand websites. Each brand has its own domain but renders certain modules such as news listings or product images client-side from the central TYPO3 instance. CORS has to be configured so that all brand domains are permitted but foreign domains are not. A dynamic origin check against a whitelist in the TYPO3 site configuration is the right approach, rather than a blanket wildcard.

The third context is scientific consortia that maintain a research database in TYPO3 and offer access to research institutions worldwide through an open API. Here the CORS policy is deliberately open, but it has to be combined with an authentication layer, so that every origin may call the API but only a valid token returns data.

## Technical architecture: middleware, PSR-15 and preflight

In TYPO3 v12 and v13, the correct place for CORS headers is a PSR-15 middleware hooked into the request pipeline. It checks the origin header of the incoming request, compares it to a configured whitelist and sets the appropriate Access-Control-Allow-Origin, Access-Control-Allow-Methods and Access-Control-Allow-Headers headers in the response. For POST, PUT or DELETE requests with custom headers, the browser first sends an OPTIONS preflight request that the middleware has to answer without authentication, otherwise the actual request fails.

The configuration can be maintained via the site configuration as a YAML array, alternatively directly in the ext_localconf.php of your own extension. What matters is that credentials handling (cookies, authorisation headers) only works if Access-Control-Allow-Credentials is set to true and Access-Control-Allow-Origin points to a concrete origin, not a wildcard. This combination is CORS standard and a common error source for teams that first test with a wildcard and later try to add credentials on top.

## Common problems and solutions

The first problem is duplicate header setting. When TYPO3 sets a header and Apache or Nginx additionally sets the same header in the web server configuration, two values arrive at the browser, which rejects the request as malformed. The solution is to define CORS at exactly one place, either in the TYPO3 middleware or in the web server, and deliberately leave the other empty. For reverse proxies such as Traefik or Cloudflare, a third layer is added that can also manipulate headers.

The second problem is preflight OPTIONS requests. The browser sends an OPTIONS request to check before the actual call whether the method is allowed. TYPO3 middleware that first authenticates and then sets CORS headers rejects the OPTIONS request because it does not carry an authorisation header. The solution is to intercept preflight requests early in the middleware chain and answer them without authentication.

The third topic is the combination of CORS and caching. A reverse proxy such as Varnish caches a response with specific CORS headers, and on the next call from a different origin that origin receives the old headers. The consequence is that legitimate users suddenly see CORS errors because they receive a cached response intended for a different origin. A Vary header on origin fixes the problem but forces the cache to hold multiple variants per resource.

## Migration and version compatibility

TYPO3 v11 did not yet offer a clean middleware API for all contexts, so CORS configuration was often handled via hooks or directly in the web server. From v12 onwards, the PSR-15 middleware is the intended path, and the migration path from older installations consists of moving existing header manipulations out of the Apache or Nginx config and into the TYPO3 middleware.

For headless setups in TYPO3 v13 combined with EXT:headless by Macopedia, CORS is an essential building block and is explicitly covered in the extension documentation. Gosign has delivered several such headless projects and, where needed, also coordinates between development teams that own frontend and backend separately, so that CORS rules are clearly documented and synchronised on every deployment change. A wrong rule opens an attack vector in which malicious websites can perform actions on behalf of the logged-in user, which is why a clean whitelist is not a comfort topic but a security requirement.

It should also be noted that CORS is not a substitute for authentication. Many development teams configure generous CORS rules on the assumption that this makes the API secure and forget that every origin the browser permits has the same access as a direct client. Authentication has to happen independently of CORS via tokens, API keys or session cookies, and CORS merely ensures that browsers allow legitimate calls to these authenticated endpoints in the first place. Teams that understand this separation configure their CORS rules much more restrictively and close many unintended gaps.

--- Countdown TYPO3 - Timer Extension | Gosign ---
> TYPO3 extension for countdown timers: event countdowns, product launches, offer deadlines. Gosign also builds CSS-only countdowns without extension overhead.

## Countdown extensions solve a communication problem that plain text cannot

When a trade fair starts in 23 days, when the early bird offer expires at midnight or when the new shop goes live on 1 May, a sentence like "just a few days left" is not enough. Users react to ticking clocks much more strongly than to static dates, and on a TYPO3 page the simplest variant is to add a visible countdown timer. Several TYPO3 extensions from the TER offer this functionality, the best known is simply called "countdown". For every corporate website with event announcements, product launches or limited-time campaigns, this is a recurring requirement that without an extension usually ends up as a custom JavaScript hack. The choice between extension and in-house solution rarely comes down to technology, but to the question of who should maintain the countdown in the editorial team.

## Typical use cases range from trade fairs to e-commerce campaigns

The first scenario is trade fairs and conferences. An association announces its annual conference six months in advance and wants to make the remaining time visible, ideally with days, hours, minutes and seconds. The countdown runs on the landing page, switches over in the final 24 hours and disappears automatically after the event ends, without an editor having to adjust the page. That saves maintenance effort and also prevents awkward situations such as a counter that continues to show a negative value after the event.

A second scenario is product launches and pre-order windows. E-commerce projects based on aimeos or external shops use countdowns on landing pages to bind customers to the launch date. For pre-orders, the countdown acts as a urgency signal and demonstrably lifts conversion rates.

A third scenario are application and submission deadlines. Universities show a countdown to the deadline on the application page, associations use it for early bird prices, public institutions for submission deadlines of public tenders. Here it is not about marketing but about service: visitors should be able to see at a glance how much time they have left. For application portals in the academic space this is practically standard, because grant applications work with a fixed deadline and a hard cut-off time.

## Technical architecture runs through a combination of Fluid template and minimal JavaScript

Classic countdown extensions in TYPO3 consist of two parts. The backend part is a content element or plug-in in which the editor maintains target date, target time, time zone, label and optionally an end-time message. The frontend part renders this data in a Fluid template and attaches a small JavaScript that computes the difference to the current time and updates the DOM.

Most extensions additionally ship a configuration for the rendering: number of digits (days, hours, minutes, seconds), display as circular graphic or as flip clock, colours and animation. The JavaScript typically runs with a setInterval of 1000 ms and computes client-side, so that the server cache stays unchanged. What matters is that the timer does not end at a negative value but fires an event that displays an "event started" or "offer expired" message.

For GDPR-critical projects, it is worth looking at the JavaScript dependencies. Some extensions load jQuery or MomentJS as a side effect, which causes additional render path. Modern variants get by with a few lines of vanilla JS and a CSS grid, which also works without an extension.

## Common problems involve time zones, caching and SEO

The most common support topic is the time zone. The editor enters a date in the backend, the server is set to UTC, the visitor lives in CET, and the countdown shows an hour too many. The extension has to cleanly distinguish between server time, backend editorial time and browser time. We always recommend passing the target date in ISO 8601 with an explicit time zone ("2026-05-01T12:00:00+02:00") to the JavaScript.

The second problem is the page cache. If the rendered HTML page is cached for an hour, the countdown must not contain a server-side computed "23 days 7 hours", because the cache hit freezes that value. The solution: the Fluid part only renders the target date as a data attribute, and the difference calculation happens exclusively in the browser.

Thirdly, SEO is a factor. A pure JavaScript countdown shows Google neither the target date nor the occasion. For search engines, a schema:Event JSON-LD belongs in the page, with startDate, endDate and name, so that Google results can show the event as a rich snippet. Anyone adding the extension should therefore not only pass the target date to the timer but additionally write it as structured data into the page header. Without that markup, the countdown remains invisible to Google and loses its marketing effect already in the search result.

## TYPO3 v12 and v13: extension or lean alternative construct

Whether a countdown extension still makes sense on TYPO3 v12 and v13 depends on the scope of the project. For a single event page, a small content element with a data attribute and 30 lines of JavaScript is enough, completely without extension overhead. For editorial teams with many events that want to maintain the timer themselves on a regular basis, an extension is justified because editors need a familiar UI element in the backend.

In practice, Gosign builds both: for one-off launches we deliver a lean content element without an extension that consists only of a Fluid template and minimal JS. For recurring use cases we integrate a maintained extension and override the Fluid template to adapt the design to the rest of the project. When upgrading old countdown extensions, a switch to the vanilla variant almost always makes sense, because jQuery-based legacy versions can neither keep up with TYPO3 v12 nor with modern performance budgets.

--- DCE TYPO3 - Dynamic Content Elements | Gosign ---
> DCE: custom content elements without PHP. Setup, migration to Mask/Container. AI-accelerated development.

## DCE was the first choice for custom content elements for years - now it is time to migrate

Between 2013 and 2020, DCE (Dynamic Content Elements) was alongside Mask the most popular method for building custom content elements in TYPO3. Editors received backend forms with exactly the fields they needed, developers defined everything via GUI without writing a single line of PHP or TCA. Thousands of TYPO3 websites still run on DCE today. The problem: development has slowed significantly. Mask has overtaken DCE in usage, and starting with TYPO3 v13, the native Content Block API offers a third alternative that requires no extension overhead.

Those with DCE in production do not need to migrate immediately. But anyone planning a TYPO3 upgrade to v12 or v13 should plan the replacement, because long-term support is uncertain.

## Typical use cases

**Existing projects with 10 to 50 DCE elements.** Mid-market corporate websites built between 2014 and 2020 with TYPO3 v7 through v10 use DCE for everything: teaser boxes, tabs, accordions, image galleries, quote blocks, team cards. The elements work but are tied to DCE. During a TYPO3 upgrade, it must be verified whether DCE still runs on the target version.

**Agencies with multiple TYPO3 projects.** Agencies that standardized on DCE across their projects face the question: migrate all projects at once (large effort, clean break) or project-by-project at the next upgrade (smaller steps, longer timeline)? The answer depends on the number of affected projects and the planned TYPO3 target version.

**Rapid prototyping for content elements.** DCE is well suited for quick prototypes: a new content element is configured in 15 minutes, including backend form and Fluid template. For proof-of-concepts or client presentations, this may suffice. For production projects, Gosign recommends Mask because the export workflow (mask_export) and active maintenance offer long-term advantages.

## Technical architecture

DCE stores content element definitions in the database (table tx_dce_domain_model_dce), not in files. Each DCE element consists of a configuration (fields, types, validation), a Fluid template (directly in the backend or as a file reference) and optional backend layouts. Fields are defined in the DCE GUI: Text, RichText, Integer, Float, Date, File (FAL), Select, Checkbox, Group (IRRE), Section (repeatable fieldsets).

On save, DCE generates the necessary TCA configuration and registers the element in the Content Element Wizard. The data for content elements resides in the tt_content table, extended by DCE-specific FlexForm fields. This FlexForm architecture is one of the key differences from Mask, which creates its own database columns in tt_content.

Dependencies: DCE requires only the TYPO3 Core. Optionally, DCE can create container elements (nested content areas), though since the introduction of the Container extension (b13/container), this is recommended as a separate approach.

## Common problems and solutions

**FlexForm data is difficult to migrate.** Because DCE stores data as XML FlexForm in tt_content, migration to Mask (which uses its own columns) is not trivial. The FlexForm XML must be parsed and the values transferred to the new Mask columns. Solution: a migration script that reads the FlexForm fields per DCE element and writes them into the corresponding Mask fields. Gosign has a reusable CLI command that automates this process per element.

**DCE containers and nested elements.** DCE offers its own container logic that nests content elements within each other. This logic is proprietary and understood by no other system. Solution for migration: convert container structures to b13/container and rebuild the child elements as Mask elements.

**Performance with many DCE definitions.** Websites with 40+ DCE elements experience noticeable backend loading times because all FlexForm configurations are read from the database and parsed with every call. Solution: activate DCE caching (TypoScript setting `plugin.tx_dce.enableCache = 1`) or switch to file-based configuration (DCE export function).

## Migration and version compatibility

DCE supports TYPO3 v11 and v12. Compatibility with TYPO3 v13 is limited: there is a development branch but no release officially marked as stable (as of April 2026). Community maintenance is less active than with Mask, where in2code as the primary developer follows a clear release cycle.

For migrating from DCE to Mask, Gosign has a standardized process: inventory DCE elements (fields, types, templates), rebuild Mask elements 1:1, migrate data via SQL script (FlexForm XML to Mask columns), adapt Fluid templates (ViewHelper calls and variable names partially change), test and uninstall DCE. The effort is 0.5 to 2 hours per element depending on complexity. A project with 25 DCE elements is migrated in 3 to 5 days.

Alternatively, projects on TYPO3 v13 can switch directly to the native Content Block API. This requires the target version to be v13 with no backward compatibility to v11/v12 needed.

Gosign recommends a pragmatic cost-benefit analysis for the migration decision. If the next TYPO3 upgrade is within 12 months and DCE does not run stably on the target version, migration is unavoidable. If the project will remain on TYPO3 v11 or v12 for another 2 to 3 years and DCE functions stably there, migration can be deferred to the next relaunch. In either case, the target system - Mask or Content Block API - should be decided now, so new content elements are created directly in the target system and no further DCE dependencies accumulate.

Total migration costs depend on the number and complexity of elements. A project with 15 simple DCE elements (text, image, link) is migrated in 2 days. A project with 40 elements, 10 of them with IRRE nesting and 5 with container logic, requires 8 to 12 days.

--- TYPO3 Templates & Sitepackages | Gosign ---
> Template package for TYPO3. Gosign recommends custom site packages instead of ready-made templates - tailored exactly to your requirements, maintainable.

## Fertige TYPO3-Templates sparen kurzfristig Zeit und kosten langfristig mehr

Die Versuchung ist groß: Ein fertiges TYPO3-Template für 79 Euro kaufen, installieren, Logo austauschen, fertig. In Wirklichkeit beginnt damit ein Kreislauf aus Workarounds, Overrides und Versionskonflikten, der jedes Update erschwert und die Weiterentwicklung bremst. dmpr_template steht exemplarisch für diese Kategorie. Gosign empfiehlt stattdessen Custom Sitepackages: individuelle Template-Pakete, die exakt auf die Anforderungen zugeschnitten, wartbar und versionierbar sind.

Ein Sitepackage ist eine TYPO3-Extension, die das komplette Frontend-Setup enthält: TypoScript, Fluid-Templates, Partials, Layouts, CSS/SCSS, JavaScript und Backend-Layouts. Es ist die offizielle TYPO3-Best-Practice seit Version 8 und ersetzt die alte Methode, Templates im Dateisystem zu konfigurieren.

## Typical use cases

**Unternehmens-Relaunch mit individuellen Anforderungen.** Ein Unternehmen startet einen Website-Relaunch. Das Design steht als Figma-Datei, die Informationsarchitektur als Sitemap, die Content-Typen sind definiert. Ein Custom Sitepackage übersetzt diese Vorgaben 1:1 in TYPO3: Jeder Content-Typ wird als Backend-Layout oder Custom Content Element abgebildet, die Fluid-Templates entsprechen dem Design pixelgenau. Kein Template-Framework steht dazwischen, das Kompromisse erzwingt.

**Multi-Site-Setup mit geteilten Komponenten.** Ein Konzern betreibt 5 Markenwebsites in einer TYPO3-Instanz. Alle teilen ein Basis-Sitepackage mit Grid-System, Typografie und Basis-Komponenten. Jede Marke hat ein eigenes Sitepackage, das die Basis-Extension erweitert: Farben, Logo, markenspezifische Layouts. Änderungen an der Basis wirken sich auf alle 5 Seiten aus, ohne dass 5 separate Codebases gepflegt werden müssen.

**Migration von alten Template-Setups.** TYPO3-Installationen aus der Version 6 oder 7 nutzen oft TemplaVoilà, Fluid Styled Content mit umfangreichen TypoScript-Overrides oder sogar Marker-basierte Templates. Die Migration auf ein sauberes Sitepackage modernisiert den gesamten Frontend-Stack in einem Schritt: weg von globalen TypoScript-Konfigurationen, hin zu einer versionierbaren Extension mit klarer Verzeichnisstruktur.

## Technical architecture

Ein Sitepackage ist eine reguläre TYPO3-Extension mit einer definierten Verzeichnisstruktur:

`Configuration/TypoScript/` enthält die TypoScript-Konfiguration: Constants, Setup, Page-TSconfig. Hier wird definiert, welche Templates für welche Seitentypen gelten, welche Inhaltselemente verfügbar sind und wie sie gerendert werden.

`Resources/Private/Templates/` enthält die Fluid-Templates für die Seitentypen (Page), Inhaltselemente (ContentElements) und Partials (wiederverwendbare Template-Fragmente). Die Trennung in Templates, Partials und Layouts folgt TYPO3s Fluid-Konvention.

`Resources/Public/` enthält CSS/SCSS, JavaScript, Bilder und Fonts. Alles, was der Browser direkt ausliefert. In modernen Setups wird SCSS per Build-Tool (Vite, Webpack) kompiliert und die generierten Dateien in `Resources/Public/Build/` abgelegt.

`Configuration/TCA/` definiert Backend-Layouts und Custom Content Elements. Backend-Layouts steuern, welche Spalten und Bereiche auf einer Seite im Backend verfügbar sind. Custom Content Elements werden über TCA, TypoScript und Fluid-Templates definiert.

Das Sitepackage wird per Composer installiert und über die Site Configuration (config.yaml) der jeweiligen TYPO3-Site zugewiesen. Mehrere Sites können dasselbe Sitepackage nutzen (Multi-Site) oder jeweils ein eigenes haben.

## Common problems and solutions

**Fertig-Templates kollidieren mit TYPO3-Updates.** Gekaufte Templates überschreiben oft Core-Konfigurationen und TCA-Definitionen auf eine Weise, die bei TYPO3-Updates bricht. Ein Template, das für TYPO3 v10 entwickelt wurde, funktioniert nach dem Update auf v12 häufig nicht mehr, weil TCA-Wizards, Backend-Layout-Registrierung und Fluid-ViewHelpers sich geändert haben. Mit einem Custom Sitepackage kontrolliert man selbst, welche Core-Features genutzt werden, und kann Updates schrittweise durchführen.

**Sitepackage-Struktur wächst unkontrolliert.** Über Jahre sammeln sich in einem Sitepackage dutzende Partials, verwaiste Templates und TypoScript-Fragmente an. Lösung: Regelmäßiges Refactoring. Ein sauberes Sitepackage hat maximal 20-30 Partials, klare Naming-Conventions (PascalCase für Templates, Ordner nach Funktion) und keine ungenutzten Dateien. Der Aufwand für ein Refactoring liegt bei 2-5 Tagen, abhängig von der Größe.

**CSS-Spezifität-Konflikte mit Fluid Styled Content.** TYPO3s Fluid Styled Content bringt eigene CSS-Klassen mit (`ce-`, `frame-`). Wenn das Sitepackage eigene Klassen nutzt, entstehen Spezifitäts-Konflikte. Lösung: Entweder Fluid Styled Content komplett durch eigene Content-Element-Definitionen ersetzen (sauberer, aber aufwändiger) oder die Fluid Styled Content Templates überschreiben und die Klassen anpassen.

## Migration and version compatibility

Das Sitepackage-Konzept ist seit TYPO3 v8 der Standard und wird in jeder neuen TYPO3-Version weiterentwickelt. Die grundlegende Struktur (Extension mit TypoScript, Fluid-Templates, TCA) bleibt stabil. Anpassungen bei Major-Updates betreffen typischerweise TCA-Syntax (Wizards, renderTypes), TypoScript-Bedingungen (neu: Symfony Expression Language) und Backend-Modul-Registrierung.

Die Migration von einem Fertig-Template (dmpr_template, j77_template, in2template) auf ein Custom Sitepackage ist ein Rewrite, keine Portierung. Man analysiert die bestehenden Templates, extrahiert die gewünschte Funktionalität und baut sie in einer sauberen Sitepackage-Struktur neu auf. Bei einem typischen Projekt mit 10 Seitentypen und 15 Content-Elementen liegt der Aufwand bei 2-3 Wochen.

TYPO3 v13 führt Content Blocks als neues Konzept für Content-Element-Definitionen ein. Content Blocks vereinfachen die Erstellung von Custom Content Elements erheblich und reduzieren den Boilerplate-Code. Sitepackages bleiben davon unberührt, sie können Content Blocks zusätzlich nutzen. Gosign baut seit Jahren ausschließlich Custom Sitepackages und hat die Erfahrung, bestehende Template-Setups effizient auf moderne Strukturen zu migrieren.

--- Doodle Alternative TYPO3 | Gosign ---
> Schedule coordination directly in TYPO3, like Doodle, but without an external service. Privacy-friendly, integrated into your own website.

## Terminabstimmungen gehören auf die eigene Website, nicht zu einem US-Dienst

Doodle ist praktisch: Link versenden, Teilnehmer wählen ihre Zeitslots, der Termin steht. Aber Doodle ist ein Drittanbieter mit Servern in den USA, mit Tracking, mit Werbung im Free-Tier. Für Unternehmen mit GDPR-Bewusstsein, für öffentliche Einrichtungen und für jede Organisation, die keine Nutzerdaten an externe Dienste weiterleiten will, ist das ein Problem. Eine Doodle-Alternative direkt in TYPO3 löst dieses Problem: Terminabstimmung auf der eigenen Infrastruktur, ohne Drittanbieter-Cookies, ohne Datenabfluss.

Die Zielgruppe ist klar: Organisationen, die regelmäßig Termine mit externen Teilnehmern abstimmen (Elternabende, Gremiensitzungen, Workshops, Schulungstermine) und dabei die Kontrolle über die Daten behalten wollen.

## Typical use cases

**Bildungseinrichtungen mit Elternabend-Koordination.** Schulen und Kitas stimmen mehrmals pro Jahr Elternabende ab. 30 Familien sollen aus 5 möglichen Terminen den besten wählen. Über ein TYPO3-Plugin auf der Schulwebsite erfolgt die Abstimmung ohne Account-Pflicht und ohne externe Dienste. Die Ergebnisse bleiben auf dem Server der Schule. Bei einem Schulträger mit 12 Schulen und zusammen 6.000 Familien entfiel durch die TYPO3-Integration das Doodle-Premium-Abo (480 EUR/Jahr) komplett.

**Behörden und öffentliche Einrichtungen.** Kommunalverwaltungen und Landesbehörden dürfen oft keine Cloud-Dienste nutzen, die Daten außerhalb der EU verarbeiten. Eine TYPO3-basierte Terminabstimmung erfüllt die behördlichen IT-Richtlinien, weil die Daten auf dem eigenen Server oder im kommunalen Rechenzentrum verbleiben.

**Unternehmens-interne Workshop-Planung.** Abteilungsübergreifende Workshops, Strategiemeetings oder Schulungen erfordern Terminabstimmungen mit 10-50 Teilnehmern. Über das Intranet (TYPO3-basiert) lässt sich die Abstimmung direkt einbetten, ohne einen externen Link zu versenden, der möglicherweise vom Unternehmens-Proxy blockiert wird.

## Technical architecture

Eine Doodle-Alternative in TYPO3 basiert auf einem Extbase-Plugin mit drei Datenbank-Tabellen: Abstimmungen (Polls), Terminoptionen (Options) und Stimmen (Votes). Die Abstimmung wird als Content-Element auf einer TYPO3-Seite platziert. Teilnehmer öffnen die Seite, sehen die Terminoptionen und wählen ihre verfügbaren Zeitfenster aus.

Die Dateneingabe erfolgt über ein Fluid-basiertes Formular. Jede Terminoption wird als Zeile dargestellt, der Teilnehmer setzt Checkboxen (ja/nein/vielleicht). Optional wird der Name des Teilnehmers abgefragt. Für authentifizierte Benutzer (Frontend-Login) kann die Extension den Namen automatisch ausfüllen und doppelte Abstimmungen verhindern.

Die Ergebnisdarstellung zeigt eine Matrix: Spalten für Teilnehmer, Zeilen für Terminoptionen, farbcodierte Zellen. Der Termin mit den meisten Zusagen wird hervorgehoben. Ein Admin-View im TYPO3-Backend zeigt alle Abstimmungen mit Ergebnis und erlaubt das Schließen oder Archivieren abgeschlossener Polls.

E-Mail-Benachrichtigungen sind optional integrierbar: Neue Abstimmung erstellt, neuer Teilnehmer hat abgestimmt, Abstimmung geschlossen. Die E-Mails nutzen TYPO3s Mail-API und lassen sich über Fluid-Templates anpassen.

Die GDPR compliance erfordert: automatische Löschung der Abstimmungsdaten nach einem konfigurierbaren Zeitraum (z.B. 30 Tage nach Abstimmungsende), keine Cookies für die Abstimmungsteilnahme (Session-basiert) und eine privacy policy, die den Zweck und die Speicherdauer benennt.

## Common problems and solutions

**Spam-Abstimmungen.** Ohne Schutz können Bots oder Trolle hunderte Fake-Stimmen abgeben. Lösung: Honeypot-Feld (unsichtbares Formularfeld, das nur Bots ausfüllen), Rate-Limiting (maximal 3 Abstimmungen pro IP pro Stunde) und optional ein einfaches CAPTCHA. Frontend-Login als Pflicht eliminiert Spam vollständig, schränkt aber die Nutzbarkeit für externe Teilnehmer ein.

**Fehlende Kalender-Integration.** Teilnehmer wollen den festgelegten Termin direkt in ihren Kalender übernehmen. Die meisten TYPO3-Doodle-Alternativen bieten keinen iCal-Export. Lösung: Nach Abstimmungsende einen "Termin herunterladen"-Button anzeigen, der eine .ics-Datei generiert. Der Aufwand für die iCal-Generierung liegt bei circa 2 Stunden Entwicklungszeit.

**Mobile Darstellung der Abstimmungsmatrix.** Eine Matrix mit 10 Terminoptionen und 20 Teilnehmern ist auf dem Smartphone nicht lesbar. Lösung: Auf mobilen Geräten die Matrix in eine Listenansicht umwandeln, bei der jeder Termin einzeln mit Ja/Nein-Buttons dargestellt wird. Die Ergebnisübersicht wird ebenfalls als vertikale Liste statt als horizontale Tabelle angezeigt.

## Migration and version compatibility

Im TYPO3 Extension Repository existieren mehrere Doodle-ähnliche Extensions mit unterschiedlichem Funktionsumfang und Pflegestatus. Keine davon hat sich als Standard durchgesetzt. Für TYPO3 v12 und v13 empfiehlt sich daher eine Custom-Entwicklung auf Extbase-Basis, die exakt die benötigten Features abdeckt und langfristig wartbar bleibt.

Der Entwicklungsaufwand für eine Basis-Version (Abstimmung erstellen, Termine wählen, Ergebnis anzeigen) liegt bei 3-5 Tagen. Mit E-Mail-Benachrichtigung, iCal-Export und Admin-Backend bei 7-10 Tagen. Das ist weniger als ein Jahr Doodle-Premium-Abo für 15+ Benutzer (ab 6,95 EUR/Benutzer/Monat = circa 1.250 EUR/Jahr).

Für Unternehmen, die bereits Microsoft 365 oder Google Workspace nutzen, ist die TYPO3-Lösung primär für externe Teilnehmer relevant. Interne Terminabstimmungen laufen über Outlook oder Google Calendar effizienter. Die TYPO3-Lösung ergänzt das, wo externe Teilnehmer ohne Account mitmachen sollen. Gosign entwickelt solche Custom-Lösungen auf Extbase-Basis und integriert sie in bestehende TYPO3-Installationen.

--- downloadmanager TYPO3 - File Downloads | Gosign ---
> downloadmanager: organize, categorize & track file downloads in TYPO3. AI-accelerated implementation.

## downloadmanager brings order to TYPO3 download areas when a nested file directory is no longer enough, with categories, tags, search and a cookie-free download counter

As soon as a TYPO3 project has to manage more than twenty file downloads, hand maintenance collapses. Editors link PDFs through the link browser, the directory grows chaotically, existing documents are accidentally overwritten and visitors can no longer find anything through search. downloadmanager solves exactly this problem: it presents the file base as a structured repository, with dedicated records, categories, tags, metadata and an interface that users can search purposefully. For companies with product data sheets, associations with form collections and municipalities with download centres, this is the standard solution.

The difference to managing pure FAL folders is fundamental. While fileadmin mirrors a file system, downloadmanager adds an editorial layer on top: a document can appear in several categories simultaneously, carry its display title independently of the file name and be controlled via a publication schedule. For editorial teams with compliance requirements, this is often a prerequisite.

## Typical use cases

The classic case is the technical product catalogue. A mechanical engineering company maintains a data sheet, an operating manual, a CE certificate and a spare parts list for every machine. Every download gets a product category, a type assignment and, optionally, a language tag. Visitors filter by product line and document type, immediately get the matching files and the shop does not have to link every PDF individually. The product page itself can show a mini download area that automatically lists all documents belonging to the machine, without any editorial double maintenance.

The second case are form areas at municipalities, authorities and chambers. Application forms, info sheets and statutes are grouped thematically, often multilingual, occasionally with access restrictions for internal member areas. downloadmanager allows exactly this segmentation via fe_groups and categorises documents by subject area. For public administrations it is also important that publication dates and validity periods can be managed per document.

Third use: press and investor relations areas. Annual reports, press releases and image material are stored centrally, categorised by year and tagged with publication date. The editorial team only has to enter each document once, and the frontend lists are generated automatically.

## Technical architecture

downloadmanager is an Extbase extension and maintains its own records in tx_downloadmanager_domain_model_download. Each download references one or more FAL files and carries meta fields such as title, description, category, tags, publication date, language and access groups. The backend module allows mass import, bulk edit and publication workflows.

In the frontend, the extension delivers pre-built list and detail views as Fluid templates. Lists can be filtered by category, tag, search term or sort criterion, the parameters are passed via GET and respected by the cache. For search, the extension uses the MySQL full-text search or, if required, a connected Solr installation.

Configuration runs through TypoScript and FlexForm. Typical settings are the default category, the number of entries per page, the sort order and integration with a project sitepackage template. Through event listeners, developers can hook in their own logic, for example a mail notification on new uploads or an export to other systems.

Download tracking is a central feature. Instead of external analytics with cookies, downloadmanager increments a server-side counter on every click, stored as a simple integer column on the record. This is GDPR-friendly, does not add any burden to the consent banner and delivers a robust statement about which documents are actually in demand.

## Common problems and solutions

The first problem is the migration of a legacy base. Anyone who has maintained downloads through the link browser for years first has to move them into downloadmanager records. The solution is a script that walks the existing fileadmin structures, extracts metadata from file names and creates records. Gosign uses an AI-supported pipeline for that, which proposes categories and tags from file contents and PDF metadata, so that the editorial team only has to confirm them.

Second problem: caching. Filtered lists with URL parameters create many cache variants, which bloats the TYPO3 cache. The solution lies in cHash handling and in a clean definition of which parameters are cache-relevant. For pages with many filters, edge caching through Cloudflare or Varnish with parameter-aware rules can make more sense than server-side caching.

Third problem: multilingual content. A document exists in five languages but should be managed as one logical entry, so that the metadata stays in sync. Here downloadmanager uses the TYPO3 language mechanism with translation records. What matters is that the editorial team understands which fields are maintained per language and which are global.

## Migration and version compatibility

downloadmanager is actively maintained and compatible with TYPO3 v11, v12 and v13. On upgrades from older TYPO3 versions, the main thing to watch is Extbase changes: the repository methods and the persistence layer have changed several times between v9 and v12, which can break custom extensions of the extension. A typical upgrade project therefore also involves adapting custom controllers and templates.

For projects starting today, it is worth deciding upfront whether downloadmanager or a solution based on bespoke Extbase records is the right path. If the editorial team only needs standard downloads with categories and tags, the extension is the pragmatic choice. If complex workflows are required on top (approval, multi-stage publication, versioning), a bespoke solution can be easier to maintain in the long run.

Gosign migrates downloadmanager to new TYPO3 versions, accompanies legacy migrations and integrates the extension into existing sitepackages. AI-supported analysis helps propose categories and tags from existing file names and directory structures automatically, so that manual maintenance work shrinks to a minimum.

--- dp_cookieconsent TYPO3 - Cookie Consent | Gosign ---
> dp_cookieconsent for TYPO3: GDPR-compliant cookie management. Setup, audit & optimization, AI-accelerated analysis.

## Why a cookie banner alone does not establish GDPR compliance

Every TYPO3 installation that embeds Google Analytics, YouTube videos, social media plug-ins or external fonts has faced the same task since GDPR and the ePrivacy framework came into force: before a third-party script loads, there must be an active, informed consent from the user. dp_cookieconsent is the most widely used extension in the European TYPO3 community for exactly this purpose. It targets organisations that want to run their website GDPR-compliant without an external consent management platform, which makes it a popular choice for mid-sized companies, public authorities and educational institutions that do not want to carry recurring licence fees for commercial CMPs.

## Typical use cases

An industrial company with a product catalogue and 45 landing pages uses Google Analytics, a YouTube explainer video, HubSpot forms and Google Fonts. Without dp_cookieconsent, all these services would set cookies the moment a user opens the page and trigger a GDPR violation. The extension groups the services by category, defers the HubSpot code until marketing consent has been granted and loads Google Fonts as a self-hosted alternative, which removes the consent requirement for that service entirely.

A second typical picture comes from a university with a main portal and several decentralised faculty websites. Each faculty maintains its own content and embeds its own services, sometimes an OpenStreetMap map, sometimes a YouTube video, sometimes Piwik tracking. dp_cookieconsent centralises consent management in the main installation, delivers the banner to all sub-sites via Fluid partials and stores the consent across domains, so that a user does not have to re-confirm on every faculty site.

A third case is municipal administrations with online forms and map applications. Here the added complication is that regional data protection officers run regular audits and require a complete documentation of all services in use. dp_cookieconsent delivers the categorisation and the privacy text directly from TypoScript, which lets the editorial team maintain it without developer intervention.

## Technical architecture: script blocking at template level

dp_cookieconsent works on the "type attribute swapping" principle: all third-party scripts in the source code are not delivered with type="text/javascript" but with a neutral type such as type="text/plain" and an additional data-cookieconsent attribute. The browser ignores such tags and does not execute them. Only when the user accepts in the banner does a small JavaScript runner replace the type attributes and trigger the delayed execution. The same mechanism applies to iframes, which are shown as placeholders until consent is given.

The extension is configured entirely through TypoScript constants and setup, complemented by a YAML file for the service definitions. Every service is listed there with name, description, category, cookie names and cookie lifetime, which considerably simplifies the later documentation for the data protection officer. Fluid partials define the appearance of the banner and the settings modal, which means the design can be adjusted to the corporate identity without touching the extension itself.

## Common problems and solutions

The first and most common problem: despite the active banner, third-party scripts still load because they are embedded through include paths that do not go through TypoScript. Typical culprits are static HTML blocks, Fluid content elements with hard-coded script tags or footer includes from older templates. A clean solution requires a full site crawl with browser dev tools or an automated tool that logs all outbound requests and compares which of them are triggered before consent.

The second problem is consent storage. dp_cookieconsent stores the consent in a local cookie, which for users with strict browser configuration or in incognito mode leads to repeated banner displays. Anyone who wants to measure consent rates has to additionally enable server-side logging that records the consent decisions with timestamp and hashed IP in a database table, which in turn delivers a robust audit trail.

The third topic is performance. The banner loads a JavaScript bundle that, depending on the number of configured services, can become noticeably large and delay the First Contentful Paint. Gosign optimises delivery via deferred loading, reduces unnecessary Fluid partials and, wherever possible, combines cookieless analytics with self-hosted assets, so that the banner is only needed for a handful of services.

A fourth problem occurs when consent decisions change: a user grants consent, uses the site, later changes their mind and withdraws consent. dp_cookieconsent resets the cookie flag, but scripts that have already loaded keep running in the background until the user reloads the page. A clean solution requires a reload trigger or the targeted removal of cookies that have already been set, so that the withdrawal actually takes effect instead of only being documented formally.

## Migration and version compatibility

dp_cookieconsent is available for TYPO3 v11, v12 and v13, and the v13 compatibility is regularly updated and currently considered production-ready. The jump from v11 to v12 usually requires a re-mapping of the TypoScript constants, because several constant names were renamed. Users of older versions of the extension should note that service definitions were once maintained exclusively through backend forms, while newer versions work with YAML and are therefore much easier to fit into Git workflows.

Anyone migrating from another consent tool such as Cookiebot, OneTrust or Usercentrics saves recurring licence fees but has to rebuild the service configuration. Gosign carries out these migrations including a consent rate analysis, so that the switch is measurably neutral for the consent rate.

It is also worth asking strategically whether a cookie banner is still the right answer at all. Anyone who consistently uses self-hosted fonts, switches to cookieless analytics such as Matomo without cookies or Plausible, and replaces video embeds with static preview images that load on click, can drop the banner for many pages entirely. The legal benefit is substantial, because every avoided consent prompt is also an avoided liability risk, and at the same time the conversion rate is not held back by the banner dialogue.

--- dpn_glossary TYPO3 - Glossary Terms | Gosign ---
> Glossary extension for TYPO3. Define technical terms, automatically link in content, display as tooltip. Alphabetical navigation.

## A glossary delivers SEO value when internal linking runs automatically

Manually linking technical terms across a website is Sisyphean work. A company with 200 pages and 80 technical terms would theoretically need to review every page and connect relevant terms to the glossary page. In practice, this never happens completely, and it is forgotten for new content. dpn_glossary automates this process: the extension detects defined technical terms in the content and automatically links them to the respective glossary page or displays a tooltip definition.

The SEO effect is measurable. Each glossary term creates its own indexable URL. The automatic linking from content creates a dense internal link network that helps Google assess the website's topical authority. Websites with 50+ glossary terms typically generate 5 to 15% additional organic traffic through long-tail keywords.

## Typical use cases

**Industry portals and sector websites.** Insurance companies, financial services, law firms, technical companies - wherever specialized language is part of daily business, visitors benefit from clear definitions. An insurer with terms like "coverage limit", "deductible", "right of recourse" can display these as tooltips in running text without disrupting the reading flow. Simultaneously, an alphabetical glossary page serves as a reference work.

**Technical documentation and knowledge bases.** Software companies that maintain their documentation in TYPO3 use dpn_glossary to consistently explain technical terms (API, SDK, Webhook, OAuth). New employees and customers find definitions directly in context without needing to look up a separate document.

**Multilingual websites with language-specific terms.** dpn_glossary supports TYPO3 translation mechanisms. Terms can be defined per language, including different definitions and abbreviations. A German glossary term like "works council" is recognized and linked correctly across all language versions of the content.

## Technical architecture

dpn_glossary stores glossary terms in a dedicated table (tx_dpnglossary_domain_model_term). Each term has a name, a definition (RichText), optionally a short form, synonyms, media (images, files) and a detail URL. Synonyms are important: the term "AI" can be defined as a synonym for "Artificial Intelligence" so both spellings are automatically recognized in the content.

The automatic linking works as a content post-processor: after TYPO3 has rendered the page content, dpn_glossary searches the HTML output for known terms and replaces them with links or tooltip markup. HTML tags, attributes and existing links are excluded to prevent broken nesting. The replacement is configurable: first mention per page only, all mentions, or no replacement (tooltip only).

The glossary page is set up as a TYPO3 plugin page. The default view shows an alphabetical navigation (A-Z) with all terms. Each term has a detail page with definition, related terms and optionally embedded media. URLs follow the pattern /glossary/term-name/, which is optimal for SEO.

Performance: the automatic linking searches every rendered page content. With 100+ terms and long pages, this can become noticeable. dpn_glossary caches the term list and uses regular expressions for the search, which is not a problem with TYPO3 page cache enabled (cached_pages) because the replacement only runs on the first request.

## Common problems and solutions

**Terms linked in headings, menus or forms.** The automatic linking sometimes captures HTML areas that should not be linked. Solution: the extension offers configuration for excluded tags (e.g. h1, h2, h3, nav, form, a). By default, headings and links are excluded, but the list must be adjusted per project.

**Tooltip display conflicts with the layout.** Tooltips (hover popups with the definition) can overflow the page edge or cover other elements. Solution: adjust the tooltip CSS (max-width, z-index, position). dpn_glossary includes a default CSS that can be overridden via TypoScript. For mobile devices, tap-instead-of-hover behavior is recommended.

**Performance issues with many terms.** Websites with 500+ glossary terms experience the linking on uncached pages. Solution: restrict the term list to active terms (deactivate outdated ones), limit the linking to specific page areas (main content only, not footer or sidebar) and consistently use the TYPO3 page cache.

## Migration and version compatibility

dpn_glossary supports TYPO3 v11 and v12 in the current stable version. TYPO3 v13 compatibility is in development (as of April 2026). The extension is actively maintained with regular releases and a clear upgrade path.

For projects migrating from another glossary solution (e.g. a custom-built glossary plugin or a WordPress migration), data migration is straightforward: export terms as CSV and load them into the dpn_glossary table via import script. Gosign has a CLI tool that supports CSV, JSON and XML sources.

Long-term, Gosign recommends additionally outputting glossary data as Schema.org DefinedTerm markup. dpn_glossary does not offer native support for this, but a Fluid template override can add the markup per glossary term. This improves visibility in Knowledge Panels and AI-generated answers.

Another use case that is often overlooked: glossaries as onboarding tools for new employees. Companies with many internal technical terms (insurance, banking, government agencies) can use dpn_glossary in their intranet TYPO3 so new colleagues can look up unfamiliar terms directly in context. The extension works in the intranet exactly as on public websites.

Gosign estimates the initial setup of a dpn_glossary project (installation, configuration, template customization, import of 50 terms) at 1 to 2 development days. Ongoing maintenance of terms is handled by the editorial team through the TYPO3 backend. Per term, the name, definition, synonyms and an optional image need to be maintained - achievable in 5 to 10 minutes.

--- Link-Validator TYPO3 - SEO | Gosign ---
> Broken link checker for TYPO3: check internal and external links, find broken links. Essential for SEO and user experience.

## Kaputte Links kosten Rankings und Vertrauen, und die meisten TYPO3-Websites haben davon mehr als erwartet

Eine TYPO3-Website mit 500 Seiten hat im Durchschnitt 3.000-5.000 Links. Davon sind erfahrungsgemäß 2-5% defekt: gelöschte Seiten, geänderte URLs externer Websites, Tippfehler in manuell eingegebenen Links. Das sind 60-250 Broken Links, die Besucher auf 404-Seiten schicken und Google signalisieren, dass die Website schlecht gepflegt ist. dreipc_linkvalidator prüft alle internen und externen Links automatisch und meldet Probleme, bevor sie sich auf Rankings und Nutzererfahrung auswirken.

TYPO3 bringt einen eigenen Linkvalidator im Core mit (EXT:linkvalidator). dreipc_linkvalidator erweitert diesen um zusätzliche Prüfungen, bessere Reports und eine intuitivere Backend-Oberfläche. Für Websites mit mehr als 200 Seiten ist ein automatisierter Link-Check kein Luxus, sondern Pflicht.

## Typical use cases

**Corporate Websites mit externen Verlinkungen.** Unternehmenswebsites verlinken auf Partner, Lieferanten, Fachverbände, Gesetzestexte und Presseartikel. Externe URLs ändern sich ohne Vorwarnung. Ein Link auf eine EU-Verordnung funktioniert heute, wird aber nächste Woche verschoben. dreipc_linkvalidator prüft externe Links per HTTP-Request und meldet 404, 301-Ketten (mehr als 2 Redirects) und Timeouts.

**Universitäten und Bildungseinrichtungen.** Hochschul-Websites gehören zu den link-intensivsten Seiten überhaupt: Studienordnungen, Formulare, Vorlesungsverzeichnisse, Personenverzeichnisse, Partnerhochschulen. Bei einer Hochschul-Website mit 12.000 Seiten fand der Link-Check 1.400 defekte Links, davon 800 interne (gelöschte Seiten, umstrukturierte Bereiche) und 600 externe.

**Redaktionelle Portale mit Archiv-Content.** News-Portale und Magazine mit tausenden Artikeln verlinken untereinander und auf externe Quellen. Über Jahre sammeln sich Broken Links an, besonders in älteren Artikeln. Ein monatlicher Link-Check identifiziert neue Probleme, bevor sie sich häufen.

## Technical architecture

dreipc_linkvalidator erweitert TYPO3s Core-Linkvalidator um zusätzliche Prüfmechanismen. Der Core-Linkvalidator prüft Links auf Datenbankebene: Er analysiert die Felder `bodytext`, `header_link` und andere konfigurierte Felder in der Content-Tabelle und identifiziert Links auf gelöschte Seiten oder Dateien. dreipc_linkvalidator ergänzt HTTP-basierte Prüfungen für externe URLs.

Die Prüfung läuft als TYPO3 Scheduler-Task. Typische Konfiguration: einmal pro Woche nachts. Der Task durchsucht alle konfigurierten Tabellen und Felder nach Links, unterscheidet zwischen internen Links (t3://page?uid=123), Datei-Links (t3://file?uid=456) und externen Links (https://...), und prüft jeden Link auf Erreichbarkeit.

Interne Links werden gegen die TYPO3-Datenbank geprüft: Existiert die verlinkte Seite noch? Ist sie nicht versteckt, nicht gelöscht, nicht zeitlich abgelaufen? Datei-Links prüfen, ob die referenzierte Datei im FAL noch existiert. Externe Links werden per HTTP HEAD-Request geprüft (schneller als GET, da kein Body übertragen wird). Bei HEAD-Fehler folgt ein GET als Fallback.

Die Ergebnisse werden in einer Backend-Ansicht dargestellt: tabellarisch, filterbar nach Fehlertyp (404, 301, Timeout, SSL-Fehler), nach Seite und nach Redakteur. Jeder Eintrag enthält den Link, die Fehlerursache, die Seite auf der er vorkommt und einen direkten Link zum TYPO3-Backend-Editor.

## Common problems and solutions

**False Positives bei externen Links.** Manche Websites blockieren automatisierte Requests (Bot-Protection, Cloudflare Challenge). Der Link funktioniert im Browser, aber der Linkvalidator meldet 403 oder Timeout. Lösung: Einen realistischen User-Agent-Header setzen, Timeouts auf 15 Sekunden erhöhen und bekannte False-Positive-Domains auf eine Whitelist setzen. Bei einem Kunden reduzierten diese Anpassungen die False-Positive-Rate von 12% auf unter 2%.

**Prüfung dauert zu lange bei großen Websites.** 10.000 externe Links zu prüfen dauert bei sequentieller Abarbeitung mehrere Stunden. Lösung: Parallele Prüfung konfigurieren (5-10 gleichzeitige Requests), die Prüfung auf externe Links beschränken (interne Links sind schnell per DB-Query prüfbar) und die Prüffrequenz anpassen (externe Links wöchentlich, interne täglich).

**Redakteure ignorieren die Berichte.** Der häufigste Grund für wachsende Broken-Link-Listen: Niemand fühlt sich zuständig. Lösung: E-Mail-Benachrichtigungen an die zuständigen Redakteure aktivieren. dreipc_linkvalidator kann Reports per E-Mail versenden, aufgeschlüsselt nach Seitenbaum-Bereich. Der Redakteur erhält nur die Broken Links in "seinem" Bereich.

## Migration and version compatibility

TYPO3s Core-Linkvalidator (EXT:linkvalidator) ist seit v7 Bestandteil des Core und wird kontinuierlich weiterentwickelt. In TYPO3 v12 und v13 ist der Core-Linkvalidator deutlich verbessert: bessere Performance, neue UI im Backend, Scheduler-Integration überarbeitet. dreipc_linkvalidator als Erweiterung unterstützt TYPO3 v10 und v11. Für v12 und v13 existiert keine offizielle Version.

Für Projekte auf TYPO3 v12/v13 stellt sich die Frage, ob dreipc_linkvalidator noch nötig ist. Der Core-Linkvalidator in v12 deckt viele Features ab, die früher nur über dreipc verfügbar waren: HTTP-basierte Prüfung externer Links, Scheduler-Integration, Backend-Ansicht mit Filterung. Was fehlt: E-Mail-Reports und die Whitelist-Funktion für False Positives.

Die Alternative: den Core-Linkvalidator mit einem Custom Command ergänzen, der E-Mail-Reports generiert. Der Aufwand liegt bei circa einem Entwicklertag. Alternativ gibt es externe Tools (Screaming Frog, Ahrefs, Semrush), die Broken Links als Teil ihres SEO-Audits prüfen, aber nicht in TYPO3 integriert sind. Gosign empfiehlt den Core-Linkvalidator in Kombination mit einem monatlichen externen Crawl für maximale Abdeckung.

--- dreipc_pdf TYPO3 - PDF Export | Gosign ---
> PDF generation by dreipc: export TYPO3 pages as PDF with custom layout. Alternative to web2pdf with its own rendering approach.

## Wenn Besucher TYPO3-Seiten als PDF herunterladen wollen, braucht das Ergebnis ein eigenes Layout

Besucher klicken auf "Als PDF speichern" und erwarten ein sauberes Dokument: Corporate Design, Logo, Seitenzahlen, kein Navigation-Overhead. Was die Browser-Druckfunktion liefert, ist das Gegenteil: abgeschnittene Spalten, überflüssige Header und Footer, fehlende Bilder. dreipc_pdf löst dieses Problem mit einem eigenen Rendering-Ansatz: Die Extension erzeugt PDFs aus TYPO3-Seiteninhalten mit einem dedizierten Print-Layout, unabhängig von der Browser-Darstellung.

Im Gegensatz zu EXT:web2pdf, das die gerenderte HTML-Seite als Screenshot in ein PDF umwandelt, arbeitet dreipc_pdf datengetrieben. Es rendert die Inhaltselemente einer TYPO3-Seite über eigene Templates und erzeugt daraus ein formatiertes PDF. Das erlaubt volle Kontrolle über Seitenränder, Kopf- und Fußzeilen, Schriftgrößen und Seitenumbrüche.

## Typical use cases

**Produktdatenblätter aus dem CMS.** Maschinenbauer, Chemieunternehmen und Medizintechnik-Hersteller pflegen Produktdaten in TYPO3. Vertriebsmitarbeiter brauchen diese Daten als druckbares PDF für Kundenbesuche. dreipc_pdf erzeugt aus der TYPO3-Produktseite ein PDF mit Corporate-Layout: Logo oben, technische Daten in Tabellen, Produktbild, Kontaktdaten unten. Bei einem Kunden mit 400 Produktseiten stehen die PDFs automatisch per Button auf jeder Seite bereit, ohne manuelle Erstellung.

**Pressemitteilungen und Geschäftsberichte.** Kommunikationsabteilungen veröffentlichen Pressemitteilungen auf der Website und bieten sie gleichzeitig als PDF zum Download an. dreipc_pdf generiert das PDF beim Klick auf den Download-Button, immer basierend auf dem aktuellen Content. Keine manuelle PDF-Erstellung, kein Risiko veralteter Downloadversionen.

**Behördliche Informationsblätter.** Öffentliche Einrichtungen stellen Formulare, Merkblätter und Informationsschreiben als PDF bereit. Die Inhalte werden in TYPO3 gepflegt und bei Änderungen automatisch als aktualisiertes PDF ausgeliefert. Die PDF-Version hat ein offizielles Layout mit Amtskopf und Aktenzeichen.

## Technical architecture

dreipc_pdf nutzt eine PHP-PDF-Library (typischerweise mPDF oder TCPDF) zur Generierung. Die Extension registriert sich als Page-Type in TYPO3. Beim Aufruf einer Seite mit dem PDF-Type-Parameter (`?type=123`) wird statt des HTML-Outputs eine PDF-Datei generiert und zum Download angeboten.

Die Rendering-Pipeline arbeitet in drei Schritten. Erstens liest die Extension die Inhaltselemente der angeforderten TYPO3-Seite aus der Datenbank. Zweitens rendert sie jedes Element über ein dediziertes PDF-Fluid-Template (nicht das Standard-Web-Template). Drittens übergibt sie den gerenderten HTML-String an mPDF/TCPDF, die daraus das PDF mit den konfigurierten Seiteneinstellungen erzeugen.

Die PDF-Templates sind Fluid-Templates mit HTML/CSS, die mPDF versteht. mPDF unterstützt einen Subset von CSS2 und CSS3: Seitenränder (`@page`), Kopf-/Fußzeilen, Tabellen, Bilder, Schriftarten (einbettbare TTF-Fonts) und Seitenumbrüche (`page-break-before`, `page-break-after`). Flexbox und Grid werden nicht unterstützt, die Layout-Arbeit erfolgt über Tabellen oder Float.

Die Konfiguration umfasst: Seitenformat (A4, Letter, Custom), Seitenausrichtung (Hoch-/Querformat), Seitenränder, Standard-Schriftart, Kopf-/Fußzeilen-Templates und die Zuordnung von Content-Element-Typen zu PDF-Templates. Jedes Content-Element kann ein eigenes PDF-Template haben, das sich von der Web-Darstellung unterscheidet.

## Common problems and solutions

**Bilder fehlen im PDF.** mPDF lädt Bilder über HTTP nach. Wenn der Server hinter einem Reverse Proxy oder in einer Docker-Umgebung läuft, kann mPDF die eigenen Bild-URLs nicht auflösen. Lösung: Bilder über den lokalen Dateipfad statt über die URL einbinden. In den PDF-Fluid-Templates den absoluten Serverpfad (`/var/www/html/fileadmin/...`) statt der Webadresse verwenden.

**PDF-Erzeugung bei komplexen Seiten langsam.** Eine Seite mit 30 Inhaltselementen und 15 Bildern kann 5-10 Sekunden für die PDF-Generierung brauchen. Bei gleichzeitigen Anfragen belastet das den Server. Lösung: generierte PDFs cachen. Beim ersten Aufruf wird das PDF erzeugt und im Dateisystem gespeichert. Folgende Aufrufe liefern die gecachte Version. Der Cache wird bei Content-Änderungen invalidiert.

**Seitenumbrüche an falschen Stellen.** mPDF bricht Seiten dort um, wo der Inhalt die Seitenhöhe überschreitet, auch mitten in einer Tabelle oder einem Absatz. Lösung: In den PDF-Templates explizite Seitenumbrüche setzen (`<div style="page-break-before: always;">`) und Tabellen mit `<table style="page-break-inside: avoid;">` vor dem Umbrechen schützen.

## Migration and version compatibility

dreipc_pdf ist eine Nischen-Extension mit begrenzter Community. Die letzte stabile Version unterstützt TYPO3 v10 und v11. Für v12 existiert kein offizielles Update, der Portierungsaufwand ist moderat (Extbase-Anpassungen, TCA-Updates).

Die Alternativen für TYPO3 v12/v13: EXT:web2pdf (Screenshot-basiert, einfacher, weniger Kontrolle über das Layout), EXT:pdfviewhelpers (ViewHelper-basiert, arbeitet mit TCPDF), EXT:fluid_fpdf (Fluid-Templates mit FPDF-Backend) oder eine Custom-Lösung mit mPDF als Composer-Paket. Die Custom-Lösung hat den Vorteil der vollständigen Kontrolle und Unabhängigkeit von Drittanbieter-Extensions.

Wer von dreipc_pdf auf eine Custom-Lösung migriert, kann die bestehenden PDF-Fluid-Templates übernehmen, sofern sie mPDF-kompatibles HTML/CSS verwenden. Der Rendering-Wrapper muss neu geschrieben werden, aber die Templates bleiben. Bei einem typischen Projekt mit 5 PDF-Templates liegt der Migrationsaufwand bei 2-3 Tagen. Gosign hat PDF-Generierung in TYPO3 mit verschiedenen Libraries umgesetzt und empfiehlt je nach Anforderung die passende Lösung.

--- E-Paper TYPO3 - Online Magazine | Gosign ---
> Online magazine display in TYPO3. PDF-based or HTML-based. Gosign advises on modern, performant solutions instead of outdated Flash successors.

## Die meisten E-Paper-Lösungen in TYPO3 include Flash-Nachfolger, und genau so fühlen sie sich an

E-Paper-Extensions für TYPO3 stammen konzeptionell aus der Flash-Ära: ein PDF wird hochgeladen, eine JavaScript-Library simuliert Seitenblättern mit 3D-Animation. Das sieht auf dem ersten Blick beeindruckend aus. Auf dem zweiten Blick: nicht indexierbar (Google kann den Content nicht lesen), nicht responsiv (auf dem Smartphone eine Katastrophe), nicht barrierefrei und mit Ladezeiten jenseits der 5 Sekunden. Es gibt bessere Wege, Magazine und Kataloge in TYPO3 darzustellen.

Die zentrale Frage ist nicht "Welches E-Paper-Plugin?", sondern "Brauchen wir überhaupt ein E-Paper?". In den meisten Fällen ist die Antwort: Nein. Der Content gehört als HTML auf die Website, nicht als PDF in einen Blätterkatalog.

## Typical use cases

**Unternehmensmagazine und Kundenzeitschriften.** Marketingabteilungen produzieren quartalsweise Magazine im Print und wollen die digitale Version auf der Website anbieten. Klassischer Ansatz: PDF hochladen, Blätterkatalog-Widget einbetten. Besserer Ansatz: Die Artikel als einzelne TYPO3-Seiten (über tx_news) veröffentlichen, mit einer Magazin-Übersichtsseite als Hub. Jeder Artikel ist einzeln indexierbar, verlinkbar und teilbar. Das PDF bleibt als Download-Option für Offline-Leser.

**Produktkataloge für Handelspartner.** Großhandel und B2B-Unternehmen bieten ihren Händlern Produktkataloge an. Die Katalogdaten existieren oft als InDesign-Export (PDF). Ein E-Paper-Widget macht den Katalog durchblätterbar, aber nicht durchsuchbar. Der bessere Weg: Die Produktdaten strukturiert in TYPO3 pflegen und den Katalog als filtrierbare, durchsuchbare HTML-Seite darstellen. Das PDF dient als Print-Version zum Download.

**Geschäftsberichte und Nachhaltigkeitsreports.** Börsennotierte Unternehmen veröffentlichen Jahresberichte, die optisch dem Print-Layout entsprechen müssen. Hier ist ein PDF-basierter Viewer vertretbar, weil das Layout bindend ist und einzelne Seiten exakte Seitenumbrüche erfordern. Aber auch hier gilt: Die Kerndaten (Finanzkennzahlen, Management-Statements) sollten zusätzlich als HTML verfügbar sein.

## Technical architecture

E-Paper-Lösungen in TYPO3 lassen sich in drei Kategorien einteilen:

**PDF-basierte Blätterkataloge.** Ein PDF wird hochgeladen, eine JavaScript-Library (Turn.js, FlipBook.js, pdf.js) rendert die Seiten im Browser. Die Library zerlegt das PDF in einzelne Seiten und zeigt sie als Canvas-Elemente an. Vorteile: Schnelle Einrichtung, Layout entspricht 1:1 dem Print. Nachteile: Kein SEO-Wert (Content ist im PDF versteckt), schlechte Performance bei großen PDFs (50+ Seiten), keine Responsiveness.

**HTML-basierte Magazin-Layouts.** Die Artikel werden als normale TYPO3-Inhaltselemente gepflegt und über ein Magazin-Template dargestellt. Das Layout simuliert Magazin-Ästhetik (großflächige Bilder, Textspalten, Pull-Quotes) über CSS Grid und Tailwind. Vorteile: Volle SEO-Indexierung, responsive, performant, barrierearm. Nachteile: Höherer initialer Aufwand, Layout weicht vom Print ab.

**Hybrid-Ansatz.** Die Artikel existieren als HTML, zusätzlich steht ein PDF-Download bereit. Auf der Übersichtsseite sieht der Besucher Artikel-Teaser, in der Seitenleiste den PDF-Download des gesamten Magazins. Dieser Ansatz vereint SEO-Wert und Print-Treue.

Für die PDF-Darstellung in TYPO3 eignet sich pdf.js (Mozilla), eine Open-Source-Library, die PDFs nativ im Browser rendert. pdf.js ist performanter als Turn.js-basierte Blätterkataloge, verzichtet auf Blätteranimationen und bietet stattdessen eine saubere, scrollbare Darstellung mit Zoom und Textsuche.

## Common problems and solutions

**PDF-Ladezeit über 5 Sekunden.** Ein 40-seitiges Magazin als PDF wiegt 20-40 MB. Ohne Optimierung lädt der Browser das gesamte PDF, bevor die erste Seite angezeigt wird. Lösung: pdf.js unterstützt Byte-Range-Requests, bei denen nur die angeforderte Seite geladen wird. Der Server muss `Accept-Ranges: bytes` unterstützen. Zusätzlich das PDF mit Ghostscript oder qpdf für Web optimieren (`linearize`), damit die erste Seite sofort angezeigt wird.

**Content nicht von Google indexiert.** Google crawlt PDFs und indexiert deren Text, aber nicht innerhalb eines JavaScript-Viewers. Wenn das PDF nur über ein Canvas-Element im Browser dargestellt wird, sieht Google keinen Content. Lösung: Den PDF-Inhalt zusätzlich als versteckten Text (aria-hidden, für Screenreader zugänglich) auf der HTML-Seite platzieren oder, besser, den Content als native HTML-Elemente darstellen und das PDF nur als Download anbieten.

**Veraltete Blätterkatalog-Libraries.** Viele E-Paper-Extensions nutzen Libraries, die seit Jahren nicht mehr aktualisiert werden. Turn.js (letztes Update 2013), FlipBook jQuery (jQuery-Abhängigkeit) oder kommerzielle Libraries mit ablaufenden Lizenzen. Lösung: Auf pdf.js oder eine HTML-basierte Darstellung migrieren. Beide sind zukunftssicher und unabhängig von Drittanbieter-Lizenzen.

## Migration and version compatibility

E-Paper-Extensions im TER sind überwiegend veraltet. Die meisten unterstützen maximal TYPO3 v10 oder v11. Für v12 und v13 gibt es keine gepflegten Blätterkatalog-Extensions.

Der empfohlene Weg für TYPO3 v12/v13: pdf.js als Standalone-Library einbinden (kein Extension nötig) für PDF-basierte Darstellungen. Für HTML-basierte Magazine: tx_news mit einem Magazin-Template und eigener Kategorie "Ausgaben". Der Aufwand für ein Custom-Magazin-Layout auf tx_news-Basis liegt bei 3-5 Tagen.

Wer von einer bestehenden E-Paper-Extension migriert, hat drei Optionen: pdf.js-Integration (1-2 Tage, behält das PDF-basierte Modell), HTML-Migration (5-10 Tage, überführt den Content in tx_news-Artikel) oder einen externen Dienst (Issuu, Yumpu) mit TYPO3-Embed. Gosign empfiehlt den HTML-Ansatz für maximalen SEO-Wert und berät bei der Entscheidung zwischen den Varianten.

--- Extension Builder TYPO3 - Create Extensions | Gosign ---
> The standard tool for creating new TYPO3 extensions. Visual editor for Extbase models, repositories and controllers.

## The Extension Builder is the scaffolding tool without which no TYPO3 developer is truly productive

The Extension Builder has been the official tool for more than ten years for developers to create new extensions from scratch in TYPO3. Anyone who needs an Extbase extension with a domain model, repository, controller and backend module gets a visual editor that turns a UML-like domain diagram into the complete boilerplate: TCA configuration, SQL schema, ext_localconf, controller stubs, Fluid templates, language files. For agencies and product teams that regularly deliver their own extensions, the tool remains the fastest path from concept to first working prototype.

The audience are TYPO3 development teams at agencies and in-house that model business logic beyond sitepackages in TYPO3. Typical cases are extensions for product catalogues, event management, job portals, customer portals or industry-specific data structures. Without the Extension Builder, every one of these extensions would have to grow from an empty directory by hand, with the risk that the structure deviates from the TYPO3 core schema and breaks on the next upgrade.

## Typical use cases

A first scenario is a prototype for a customer portal. A mechanical engineering company with 2,000 spare parts needs an extension that exposes product families, products and documentation as their own data structures in the backend. In under 30 minutes, the Extension Builder generates the complete scaffold: TCA, repositories, controllers, list and detail view. The team immediately starts with business logic instead of boilerplate.

A second scenario is training and onboarding. A developer building a TYPO3 extension for the first time learns the conventions of the framework through the generated scaffold without getting lost in documentation. The generated code is not perfect, but it is idiomatic and shows how Extbase is meant to be used.

A third scenario is the migration of existing data structures. Anyone who has to build a new TYPO3 extension from an old CSV export with ten entities can click together the domain model in the Extension Builder, export it and fill the generated code afterwards with an import command. That saves several person days compared to a manual build.

A fourth scenario is standardisation inside an agency pool. A service provider with 15 TYPO3 developers wants to ensure that every new extension has the same base structure. The Extension Builder enforces that structure through generation, and custom templates for the code generator ensure that code style, licence header and directory structure remain identical across projects.

## Technical architecture

The Extension Builder is a classic TYPO3 backend extension with its own user interface. In the backend, a module appears in which the domain model is built through a drag-and-drop surface: entities as boxes, properties as fields, relations as lines. On export, a JSON schema is persisted, from which the generator writes the complete extension code.

Installation runs through Composer (friendsoftypo3/extension-builder). The extension has no production relevance and belongs in the development environment; it should not be activated in production at all. On generation, the Builder uses Twig-like templates that can be adapted per project if needed, for example to enforce custom code styles or a specific licence header.

What matters is that the Extension Builder does not support a roundtrip: anyone who generates once and then extends the code by hand can still open the extension in the Builder but must not regenerate, otherwise the Builder overwrites parts of the manually added logic. In practice, the Builder is used as a one-time scaffold step, after which the extension lives in the Git repository.

## Common problems and solutions

The first problem is the overwrite trap after the first generation run. Teams that start the Builder a second time to add a field lose their own code changes. The solution is a clear rule in the team: the Extension Builder is used once, the rest is hand work. Later field changes are made manually in TCA, SQL and model.

The second problem is compatibility with modern PHP conventions. The generator still produces code that leans towards older PHP versions and older Extbase conventions. The solution is a cleanup pass directly after generation: add type declarations, set return types, introduce readonly properties, replace outdated annotation comments with native attributes.

The third problem is uncritical use as a code miracle. Some teams expect the Extension Builder to deliver a production-ready application. It does not: it delivers a scaffold. Every piece of business logic, every validation and every security concept remains the responsibility of the developer.

A fourth problem are outdated backend patterns in the generated code. The shipped controllers sometimes still use deprecated Extbase patterns that generate deprecation warnings in current TYPO3. The solution is a lint step directly after generation that checks the code against current coding standards and flags missing type declarations or outdated annotations. Modern pipelines combine this step with automatic code rewriting via Rector to keep the cleanup effort as low as possible.

## Migration and version compatibility

The Extension Builder is officially available for TYPO3 v11 and v12 and is maintained by the Friends of TYPO3. For TYPO3 v13 there is an updated version that follows the new Extbase conventions. Teams upgrading existing extensions usually do not need the Builder for that, the upgrade runs through upgrade wizards in the install tool and manual adjustments.

More interesting is the strategic view: at a time when generative AI can produce complete extension scaffolds including business logic from a single prompt, the visual builder loses part of its original advantage. Gosign combines both worlds: for standard scaffolds with many entities, the Builder remains efficient; for demanding extensions with domain-specific logic, we generate the code directly from a functional briefing with AI support and save up to 80 percent of development time compared to a classic hand-build, while improving code quality at the same time.

--- FFH TYPO3 - Custom Extension | Gosign ---
> Industry-specific TYPO3 extension. Gosign offers custom development and support for specialized extensions not available in TER or no longer maintained.

## Branchenspezifische TYPO3-Extensions scheitern nicht an der Technik, sondern an der Pflege

FFH steht exemplarisch für eine Kategorie von TYPO3-Extensions, die für einen bestimmten Kunden oder eine bestimmte Branche entwickelt wurden: branchenspezifisch, funktional, aber nicht allgemein gepflegt. Im TER finden sich hunderte solcher Extensions. Manche haben 5 Downloads pro Jahr, keine Dokumentation und den letzten Commit vor 3 Jahren. Das bedeutet nicht, dass sie schlecht sind. Es bedeutet, dass sie Pflege brauchen, die der ursprüngliche Entwickler nicht mehr leistet.

Für Unternehmen, die auf solche Extensions angewiesen sind, stellt sich eine praktische Frage: Weiternutzen und selbst pflegen, auf eine Alternative migrieren oder neu entwickeln. Alle drei Wege sind gangbar. Die Entscheidung hängt von der Komplexität der Extension, der Verfügbarkeit von Alternativen und dem TYPO3-Versions-Druck ab.

## Typical use cases

**Branchenverbände mit Spezialanforderungen.** Handwerkskammern, Sportverbände und Berufsgenossenschaften betreiben TYPO3-Websites mit Funktionen, die kein Standard-Plugin abdeckt: Mitgliederverzeichnisse mit Suchradius, Veranstaltungsmanagement mit Qualifizierungspunkten, Branchenregister mit Zertifizierungsstatus. Dafür existieren Custom Extensions, die vor 5-8 Jahren entwickelt wurden und seitdem nur minimal aktualisiert werden. Die Funktion läuft, aber TYPO3-Updates werden zum Risiko.

**Medienunternehmen mit redaktionellen Workflows.** Radiosender, Verlage und Medienhäuser nutzen TYPO3 mit Extensions für Playlists, Programmplanung, Medienarchive oder Content-Syndication. Diese Extensions sind oft intern entwickelt oder von einer Agentur gebaut worden, die das Projekt nicht mehr betreut. Der Code funktioniert auf TYPO3 v9, aber die Migration auf v12 scheitert an veralteten APIs.

**Öffentliche Einrichtungen mit gesetzlichen Anforderungen.** Schulen, Museen und Bibliotheken nutzen Extensions für Öffnungszeiten-Verwaltung, Katalogsuche oder Veranstaltungsbuchung. Die Anforderungen sind spezifisch (z.B. Integration mit einer Bibliothekssoftware wie Koha oder Alma), die Extension wurde einmal gebaut und seitdem nicht aktualisiert.

## Technical architecture

Branchenspezifische TYPO3-Extensions folgen typischerweise dem Extbase/Fluid-Pattern: Domain-Modell (PHP-Klassen), Repository (Datenbankzugriff), Controller (Geschäftslogik) und Fluid-Templates (Darstellung). Die Daten liegen in eigenen Datenbanktabellen mit `tx_extensionname_` Prefix.

Die häufigsten architekturellen Muster: Plugin-basierte Extensions mit Frontend-Ausgabe (Listendarstellung, Detailansicht, Filterung), Backend-Module für die Datenpflege und Scheduler-Tasks für Import/Export. Viele branchenspezifische Extensions integrieren externe Systeme über REST-APIs oder CSV-Import.

Die Codequalität variiert erheblich. Extensions von professionellen Agenturen folgen TYPO3-Coding-Standards, nutzen Dependency Injection und haben Unit Tests. Intern entwickelte Extensions oder schnell gebaute Auftragsarbeiten haben oft hartcodierte Konfigurationen, fehlende Typisierung und keine Tests. Beides lässt sich pflegen, aber der Aufwand unterscheidet sich um den Faktor 3-5.

Ein typisches Analyse-Muster für branchenspezifische Extensions: Umfang messen (Lines of Code, Anzahl der Klassen, Anzahl der Datenbanktabellen), Abhängigkeiten prüfen (welche TYPO3-APIs werden genutzt, welche sind in v12/v13 deprecated), Testbarkeit bewerten (gibt es Unit Tests, ist der Code testbar strukturiert) und Migration-Aufwand schätzen.

## Common problems and solutions

**Deprecated APIs blockieren das TYPO3-Update.** Die Extension nutzt `$GLOBALS['TSFE']`, `GeneralUtility::_GP()` oder `ObjectManager::get()`, alles APIs, die in TYPO3 v12 deprecated oder entfernt sind. Lösung: Systematisches Refactoring. Jede deprecated API hat einen dokumentierten Ersatz im TYPO3 Changelog. Bei einer Extension mit 5.000 Zeilen Code liegt der Refactoring-Aufwand bei 3-7 Tagen, abhängig von der Anzahl der Deprecations.

**Kein Maintainer verfügbar.** Der ursprüngliche Entwickler hat die Firma verlassen, die Agentur existiert nicht mehr, das TER-Paket ist verwaist. Lösung: Den Code auf GitHub forken, die Extension in das eigene Composer-Repository aufnehmen und selbst pflegen. Oder einen externen Dienstleister beauftragen. Der Fork ist rechtlich unproblematisch, wenn die Extension unter GPL steht (Standard für TYPO3-Extensions).

**Keine Dokumentation.** Weder Inline-Kommentare noch externe Docs. Neue Entwickler müssen den Code lesen, um die Funktion zu verstehen. Lösung: Vor dem Refactoring eine technische Dokumentation erstellen. 2-4 Stunden Analyse reichen für eine Extension mit 3.000-5.000 Zeilen Code, um Architektur, Datenmodell und Geschäftslogik zu dokumentieren.

## Migration and version compatibility

Branchenspezifische Extensions haben naturgemäß keinen offiziellen v12/v13-Support. Die Migration muss individuell geleistet werden. Der Aufwand hängt von drei Faktoren ab:

Erstens: Welche TYPO3-Version ist der Ausgangspunkt? Von v9 auf v12 ist deutlich mehr Arbeit als von v11 auf v12, weil v10 den Middleware-Stack eingeführt hat und v11 die Backend-Module-Registrierung geändert hat.

Zweitens: Wie viele deprecated APIs werden genutzt? TYPO3s Extension Scanner (im Install Tool) zeigt das automatisch. Eine Extension mit 5 Deprecations braucht einen Tag, eine mit 50 braucht eine Woche.

Drittens: Wie gut ist der Code strukturiert? Sauberer Extbase-Code lässt sich mechanisch migrieren. Prozeduraler Code mit direkten Datenbankaufrufen erfordert Umschreibung.

Die drei Optionen: Portierung (Extension auf neue TYPO3-Version anpassen, 3-10 Tage), Neuentwicklung (gleiche Funktion, saubere Architektur, 2-4 Wochen) oder Alternative finden (Standard-Extension, die 80% der Funktion abdeckt, plus Custom-Anpassung). Gosign hat hunderte branchenspezifische TYPO3-Extensions analysiert, portiert und neu entwickelt und berät zur wirtschaftlichsten Option.

--- filefill TYPO3 - Load Missing Files | Gosign ---
> filefill: automatically load missing files from the live server. For dev & staging environments. AI-accelerated.

## filefill saves developers and agencies days of synchronisation effort, loading missing files from fileadmin on demand from the production server

Anyone working on an existing TYPO3 project knows the ritual: the local setup is in place, the database dump has been imported, but on every other page placeholders appear instead of images. The reason is trivial: the fileadmin directory of the live system contains gigabytes of assets that are missing locally. The classic solution used to be rsync or scp over hours. filefill cuts this step out entirely. Instead of copying all files upfront, the extension loads exactly the required file from the configured remote server on first access, on demand, transparently, with caching. For agencies that work on several projects at the same time, this saves not only storage but also hours per setup.

The productivity gain is larger than it looks at first glance. A new developer is not productive only after an hour of download waiting, but after a few minutes. A code review on a forgotten feature branch does not need a fresh file sync. A short reproduction of a bug report does not drag on for half a day. The small extension therefore addresses a real bottleneck in everyday developer work.

## Typical use cases

The most common case is the local development setup. A developer clones the TYPO3 project, sets up DDEV or Docker and imports the current database dump. Instead of downloading an additional 30 GB of fileadmin data, they configure filefill with the base URL of the live system. On every page view that requests an image or document, the extension checks whether the file exists locally and loads it if needed. After a few days of work, only the files actually needed are local, the rest stays on the server.

The second case are staging environments. An agency maintains a staging system for every project where editors test content before go-live. These staging systems do not have to hold all images, only those of the current release. filefill ensures that older content still works because files are pulled from the live system on demand.

Third use: disaster recovery and hotfix scenarios. When a TYPO3 system has to be brought up quickly on a new machine, for example after a server failure or during an urgent environment migration, filefill can bridge asset procurement during the first hours until the full backup restore has finished.

## Technical architecture

filefill hooks into the FAL system of TYPO3, more precisely into the resource retrieval mechanism. As soon as TYPO3 requests a file from the local storage and finds that it does not exist, an event listener from filefill steps in. The extension checks a list of configured "sources" in their priority order and tries to load the file from there. Successfully loaded files are stored locally, so that the next access does not require a remote request.

Configuration happens through the extension settings in the install tool. Typically a remote source is set up with a base URL, optionally with HTTP basic auth credentials. For setups with CDN or S3, this path can also serve as a source. The extension supports several sources, which is helpful for more complex scenarios with separate asset servers.

What matters is that filefill only works passively. The extension does not preload anything but only reacts to concrete file requests. That makes it frugal in resource use and unobtrusive in operation. Integration with DDEV, Docker Compose or Lando is trivial because the extension needs no additional services.

## Common problems and solutions

The first problem is access restrictions. If the live server delivers images only for logged-in users or protects certain paths via htaccess, filefill cannot reload them without further ado. The solution lies in the correct configuration of HTTP authentication and, where needed, a whitelist rule on the live server that grants the development environment access to the fileadmin path.

Second problem: accidental use in production. If filefill is active in a live environment and the remote source is the same environment, a dangerous recursion is created. The extension should never run in production. The pragmatic solution is to keep filefill only in the Composer "require-dev" block and activate it via environment variables rather than through the install tool.

Third problem: inconsistent file states. When the live system replaces a file but the local copy is already cached, the developer sees the old version. The solution is an occasional clean-out of the local fileadmin or a cache busting via the remote source. For day-to-day work, this is rarely a problem because file names usually change on replacement.

## Migration and version compatibility

filefill is compatible with TYPO3 v11, v12 and v13 and is actively maintained. On upgrades, the extension version should match the TYPO3 version, because the FAL event system has seen minor changes between v11 and v12. Anyone using the extension in existing development processes should briefly test on major upgrades whether all sources are still reachable.

A related solution is EXT:aus_driver_amazon_s3, which keeps fileadmin directly in an S3 bucket. The difference: aus_driver_amazon_s3 is a production solution, filefill is a development aid. Both complement each other: a project with S3 storage in production can use filefill locally to pull only the currently edited files from the bucket.

For agencies that use filefill in a standardised way, a documentation note in the project wiki pays off that explains how the extension is activated, which credentials are needed and how to proceed on problems. This reduces support effort on the team and makes onboarding of new developers reliable. On top of that, a short script that writes the right configuration on the setup of a new local environment is worth it.

Gosign installs and configures filefill in development environments and integrates the extension into DDEV and Docker setups, so that new project members are productive within minutes.

--- Find TYPO3 - Solr Search | Gosign ---
> Solr-based search extension for TYPO3. Alternative to the standard EXT:solr stack. Flexible search configuration, faceted search, autocomplete. Gosign advises.

## TYPO3s eingebaute Suche reicht bis 500 Seiten, danach braucht man Solr

Die Standard-Suche in TYPO3 (EXT:indexed_search) durchsucht den gerenderten HTML-Output und speichert ihn in einer Datenbank-Tabelle. Für kleine Websites mit 50-500 Seiten funktioniert das. Ab 1.000 Seiten wird die Suche langsam (Antwortzeiten über 2 Sekunden), ab 5.000 Seiten unbrauchbar. EXT:find ist eine Solr-basierte Such-Extension, die eine Alternative zum etablierten EXT:solr-Stack bietet: flexiblere Konfiguration, eigene Query-Builder und eine andere Herangehensweise an Faceted Search.

Die Entscheidung zwischen EXT:find und EXT:solr ist keine Qualitätsfrage, sondern eine Architektur-Frage. EXT:solr hat die größere Community und mehr Features out-of-the-box. EXT:find bietet mehr Flexibilität bei der Query-Konfiguration und eignet sich für Projekte mit ungewöhnlichen Suchanforderungen.

## Typical use cases

**Fachportale mit domänenspezifischer Suche.** Ein Rechtsportal mit 15.000 Dokumenten braucht Suche nach Paragraphen, Aktenzeichen und Stichworten gleichzeitig. EXT:find erlaubt die Definition verschiedener Query-Typen pro Suchfeld: exakte Suche für Aktenzeichen, Fuzzy-Suche für Freitext, Range-Filter für Datumsfelder. Bei einem Fachverlag mit 22.000 Dokumenten lieferte EXT:find Suchergebnisse in unter 100 Millisekunden, unabhängig von der Komplexität der Filterung.

**E-Commerce-Suche mit Produktattributen.** Produkte haben Attribute (Farbe, Größe, Gewicht, Preis), die als Facetten in der Suche dienen. Ein Besucher sucht "Schraube M8", filtert nach Material "Edelstahl" und Preis "unter 5 EUR". EXT:find bildet diese Facetten direkt auf Solr-Felder ab und erzeugt die Filter-Navigation automatisch aus der Solr-Konfiguration.

**Mehrsprachige Volltextsuche.** Internationale Websites brauchen Suche, die sprachspezifische Besonderheiten berücksichtigt: deutsche Komposita (Donaudampfschifffahrt = Donau + Dampf + Schifffahrt), polnische Deklination, spanische Akzente. Solr bringt Sprachanalyzer für 30+ Sprachen mit. EXT:find konfiguriert pro Sprache den passenden Analyzer und erzeugt sprachspezifische Solr-Cores.

## Technical architecture

EXT:find kommuniziert mit einem Apache Solr Server über HTTP/JSON. Die Architektur besteht aus drei Komponenten: dem Solr-Server (Indexierung und Suche), dem Indexer (schreibt TYPO3-Inhalte in Solr) und dem Frontend-Plugin (Sucheingabe, Ergebnisse, Facetten).

Der Indexer durchläuft die TYPO3-Seitenstruktur und sendet den Content jeder Seite als JSON-Dokument an Solr. Dabei werden nicht nur die sichtbaren Inhalte indexiert, sondern auch Metadaten: Seitentitel, Beschreibung, Kategorien, Keywords und Custom-Felder. Die Indexierung läuft als Scheduler-Task (empfohlen: nach jedem Content-Update oder nachts als Full-Index).

EXT:find unterscheidet sich von EXT:solr in der Query-Ebene. Statt einer festen Suchabfrage-Struktur bietet find einen konfigurierbaren Query-Builder: Über TypoScript oder FlexForm lässt sich definieren, welche Solr-Felder durchsucht werden, mit welcher Gewichtung (Boosting), welche Filter automatisch angewendet werden und wie die Ergebnisse sortiert werden.

Die Facetten-Konfiguration erfolgt über Solr-Feld-Definitionen. Jedes Feld, das als Facette dienen soll, muss in der Solr-Schema-Konfiguration als `facet`-Feld definiert sein. EXT:find liest die verfügbaren Facetten aus der Solr-Konfiguration und rendert sie als Filter-Menü im Frontend. Die Filter arbeiten per GET-Parameter, was SEO-freundliche URLs für gefilterte Ergebnisseiten ermöglicht.

## Common problems and solutions

**Solr-Server-Setup und Wartung.** Solr ist ein Java-basierter Server, der separat betrieben werden muss. Für TYPO3-Agenturen ohne Java-Erfahrung ist das Setup eine Hürde: JVM-Konfiguration, Solr-Core-Management, Schema-Aktualisierung, Monitoring. Lösung: Managed Solr nutzen (z.B. Websolr, SearchStax) oder Solr als Docker-Container betreiben. Das offizielle Solr-Docker-Image reduziert das Setup auf 3 Befehle.

**Suchqualität ist schlecht.** Besucher suchen "Kontakt" und finden 200 Ergebnisse, weil das Wort auf jeder Seite im Footer steht. Lösung: Feldgewichtung konfigurieren. Titel-Treffer werden 10x höher gewichtet als Body-Treffer, H2-Treffer 5x höher als Fließtext. EXT:find erlaubt diese Gewichtung per TypoScript: `plugin.tx_find.settings.boostFields.title = 10`.

**Index wird nicht aktualisiert.** Redakteure ändern Content, aber die Suche zeigt alte Ergebnisse. Ursache: Der Indexer-Scheduler läuft nicht oder ist fehlgeschlagen. Lösung: Den Scheduler-Task auf kurze Intervalle setzen (alle 15 Minuten für Delta-Index, nachts für Full-Index) und einen Monitoring-Alert einrichten, der bei Index-Fehlern benachrichtigt.

## Migration and version compatibility

EXT:find unterstützt TYPO3 v10 und v11 mit Solr 8 und 9. Für TYPO3 v12 existiert eine Beta-Version auf GitHub. Die Extension wird von der Stabsstelle Forschung und Entwicklung der SUB Göttingen gepflegt und hat eine akademische Nutzerbasis.

EXT:solr ist die populärere Alternative mit offizieller v12-Unterstützung und kommerziellen Support-Optionen (dkd Internet Service GmbH). Für die meisten TYPO3-Projekte ist EXT:solr die sichere Wahl. EXT:find empfiehlt sich für Projekte mit besonderen Query-Anforderungen (akademische Suche, Fachdatenbanken, Multi-Index-Szenarien).

Die Migration von EXT:indexed_search auf Solr (egal ob find oder solr) erfordert: Solr-Server aufsetzen, Schema konfigurieren, Content indexieren und Frontend-Templates anpassen. Der Aufwand liegt bei 3-5 Tagen für eine Standard-Website und 1-2 Wochen für komplexe Portale. Gosign berät zum passenden Such-Stack und übernimmt Setup, Konfiguration und Feintuning der Suchqualität.

--- FlexSlider TYPO3 - Migration | Gosign ---
> Legacy slider extension for TYPO3. Gosign migrates to Swiper or Splide: no jQuery, better performance, native touch events, better Core Web Vitals.

## FlexSlider ist seit 2015 veraltet, aber immer noch auf tausenden TYPO3-Websites aktiv

FlexSlider war zwischen 2012 und 2015 einer der beliebtesten Slider für Websites: jQuery-basiert, responsive, mit Animations-Optionen. Die jQuery-Library FlexSlider.js hatte auf GitHub über 10.000 Stars. Das letzte Update erschien 2015. Seitdem hat sich die Web-Entwicklung fundamental verändert: jQuery ist nicht mehr nötig, Core Web Vitals bestrafen schwere JavaScript-Libraries, und Touch-Events funktionieren nativ ohne Library. Trotzdem läuft FlexSlider auf tausenden TYPO3-Websites, weil die Migration nie Priorität hatte.

Die TYPO3-Extension EXT:flexslider bindet die FlexSlider.js-Library ein und bietet ein Backend-Plugin zur Konfiguration von Slides (Bild, Text, Link, Animations-Effekt). Die Extension selbst ist nicht mehr gepflegt und unterstützt maximal TYPO3 v10. Jede TYPO3-Website mit FlexSlider hat ein Migrations-Thema.

## Typical use cases

**Startseiten-Slider mit wechselnden Kampagnenbildern.** Der klassische Einsatz: 3-5 großformatige Bilder auf der Startseite, die automatisch durchrotieren. Marketing wechselt die Slider-Inhalte saisonal. Diese Slider laden typischerweise 3-5 Bilder gleichzeitig (15-25 MB Daten), dazu jQuery (90 KB) und FlexSlider.js (30 KB). Das Ergebnis: 4+ Sekunden Ladezeit für den sichtbaren Bereich (LCP). Die moderne Alternative: Ein einzelnes Hero-Bild statt Slider (höhere Conversion laut A/B-Tests) oder ein CSS-basierter Slider ohne JavaScript.

**Produkt-Bildergalerien mit Thumbnails.** FlexSlider wurde oft als Thumbnail-Galerie auf Produktseiten eingesetzt: großes Hauptbild oben, Thumbnail-Leiste unten. Beim Klick auf ein Thumbnail wechselt das Hauptbild. Diese Funktion lässt sich heute mit 30 Zeilen CSS und 10 Zeilen Vanilla JavaScript umsetzen, ohne externe Library.

**Testimonial-Karussells.** Kundenstimmen als rootierende Zitate, oft mit Autoplay-Animation. FlexSlider bot dafür einen "Carousel"-Modus. Moderne Alternative: CSS Scroll Snap mit `scroll-behavior: smooth`. Kein JavaScript nötig, volle Touch-Unterstützung, unter 1 KB Code.

## Technical architecture

EXT:flexslider besteht aus drei Teilen: einem Content-Element-Plugin (FlexForm mit Slide-Konfiguration), Fluid-Templates für die Frontend-Darstellung und der FlexSlider.js-Library mit jQuery als Abhängigkeit.

Im Backend konfiguriert der Redakteur: Anzahl der Slides, Bild, Überschrift, Text, Link, Animations-Effekt (slide, fade), Autoplay (ja/nein), Autoplay-Geschwindigkeit, Navigation (Pfeile, Punkte, Thumbnails) und Responsive-Breakpoints. Die Daten werden in der FlexForm-XML-Struktur des Content-Elements gespeichert.

Im Frontend lädt TYPO3 jQuery (falls nicht bereits vorhanden), flexslider.js und flexslider.css. Ein Initialisierungs-Script aktiviert den Slider mit den konfigurierten Optionen. Das Rendering erfolgt als `<div class="flexslider"><ul class="slides"><li>` Struktur.

Die Performance-Probleme sind architekturbedingt: FlexSlider lädt alle Slides beim Seitenaufruf (kein Lazy Loading), jQuery blockiert das Rendering (render-blocking Resource), die Animations-Engine nutzt JavaScript statt CSS-Transitions (höherer CPU-Verbrauch auf Mobilgeräten).

## Common problems and solutions

**Schlechte Core Web Vitals durch FlexSlider.** LCP über 4 Sekunden, CLS über 0.25 (Layout-Shift beim Laden), TBT über 300ms (JavaScript-Blocking). Das ist kein Tuning-Problem, das ist ein Architektur-Problem. Lösung: FlexSlider durch eine moderne Alternative ersetzen. Swiper (kein jQuery, Lazy Loading, CSS-Transitions) oder Splide (leichter als Swiper, 29 KB statt 140 KB) sind die Standardalternativen. Noch besser: keinen Slider verwenden und durch ein statisches Hero-Element ersetzen.

**jQuery-Konflikte.** TYPO3 v12 liefert kein jQuery mehr im Core. FlexSlider braucht jQuery. Wer jQuery nur für FlexSlider einbindet, lädt 90 KB für eine Library, die sonst nirgends genutzt wird. Lösung: Bei der Slider-Migration jQuery komplett entfernen und alle jQuery-abhängigen Komponenten gleichzeitig migrieren.

**Responsive Bilder funktionieren nicht.** FlexSlider kennt kein `<picture>`-Element und kein `srcset`. Jedes Gerät lädt dasselbe Bild, egal ob Desktop (1920px) oder Smartphone (375px). Lösung: Swiper und Splide unterstützen `srcset` und `<picture>` nativ. Bei der Migration werden die Bilder über TYPO3s Image-Processing in mehreren Größen erzeugt und per `srcset` ausgeliefert.

## Migration and version compatibility

FlexSlider hat keine TYPO3 v12- oder v13-Kompatibilität und wird keine bekommen. Die jQuery-Library ist End-of-Life. Jedes TYPO3-Projekt, das auf v12/v13 migriert, muss FlexSlider ersetzen.

Die Migration erfolgt in vier Schritten: erstens die bestehenden Slider-Daten exportieren (Bilder, Texte, Links aus der FlexForm-Konfiguration), zweitens ein neues Content-Element mit Swiper oder Splide aufsetzen (als Custom Content Element im Sitepackage), drittens die Slider-Daten in die neue Struktur importieren und viertens die alten FlexSlider-Referenzen auf das neue Element migrieren (SQL-Update der tt_content-Tabelle).

Der Migrationsaufwand liegt bei 1-2 Tagen für den technischen Umbau und 0,5-1 Tag für die Datenmigration bei 10-20 Slidern. Die Alternative ohne Slider (statisches Hero-Element) ist noch schneller: 0,5 Tage für das neue Template, die Daten des ersten Slides werden übernommen, die restlichen entfallen.

Gosign empfiehlt bei jeder FlexSlider-Migration die Grundsatzfrage: Brauchen Sie wirklich einen Slider? A/B-Tests zeigen konsistent, dass statische Hero-Elemente höhere Conversion-Raten erzielen als rotierende Slider. Falls doch ein Slider nötig ist, liefert Gosign die Migration auf Swiper oder Splide inklusive Performance-Optimierung.

--- Flipbook TYPO3 - PDF Flipbook | Gosign ---
> Alternative flipbook extension for TYPO3 (alongside rflipbook). PDF flipbook display with page-flip effect.

## Flipbooks looked impressive in 2012 but cost performance and accessibility today

The page-turning effect was one of the most popular display formats for catalogs, annual reports and magazines on corporate websites. A PDF is split into individual pages, displayed in the browser as a book and flipped via mouse click or swipe gesture. The technology originated in the Flash era. Since the end of Flash (2020), flipbook solutions are based on JavaScript and Canvas. But the core idea has not changed: it is about visually simulating a physical document.

The problem: flipbooks are performance killers. A 40-page PDF is converted into 40 individual images (200 to 500 KB each), plus the JavaScript library (100 to 300 KB minified). Result: 10 to 20 MB payload for a single content element. On mobile devices, flipbooks are barely usable, screen readers cannot read the content, and Google does not index the text because it is embedded in images.

## Typical use cases

**Annual reports and financial statements.** Board members want to show the annual report "as printed" on the website. The print agency delivers a PDF, the marketing team wants to put it online as-is. Flipbook seems like the easiest solution. Gosign recommends an alternative: prepare the report as an HTML page (searchable, accessible, responsive) and place the PDF as a download link alongside it. This requires more effort but delivers SEO value and accessibility.

**Product catalogs with many pages.** Industrial companies with 200-page catalogs use flipbooks as "browseable catalogs" on the website. Reality: users flip through a maximum of 5 to 10 pages before abandoning. A searchable HTML catalog with filters and product detail pages converts better. If the flipping effect is desired, a lightbox slider with the most important pages as previews is sufficient.

**Real estate brochures and marketing materials.** Real estate offices show property brochures as flipbooks to give prospects a feel for the printed document. Here, an embedded PDF viewer (pdf.js) without the flipping effect often suffices - it works on all devices and keeps the text searchable.

## Technical architecture

The flipbook extension for TYPO3 (like rflipbook, the other popular variant) works in three steps. First, the PDF is converted server-side into individual images (via ImageMagick, Ghostscript or an external service). Then the images are rendered in a Canvas-based JavaScript library (turn.js, StPageFlip or a commercial solution). The flipping effect is produced via CSS3 transforms and JavaScript animation.

The TYPO3 integration works as a content element: editor uploads a PDF, selects options (page range, thumbnail size, effect speed), the frontend renders the flipbook. The converted images are stored in fileadmin or a cache directory.

Dependencies: ImageMagick or Ghostscript must be installed on the server (for PDF conversion). The JavaScript library is included as an asset. For turn.js (the best-known library), jQuery must be loaded - an additional performance penalty on modern websites.

## Common problems and solutions

**Images are not generated.** The PDF conversion fails when Ghostscript is not installed, the wrong version is running or write permissions are missing for the output directory. Solution: check `gs --version` on the server (minimum 9.50), grant write permissions for the output directory to the webserver user, contact the provider on shared hosting.

**Loading time over 5 seconds.** An 80-page PDF generates dozens of high-resolution images. Solution: reduce image quality (72 dpi instead of 150 dpi for web display), implement lazy loading for pages outside the visible area, use WebP instead of PNG/JPEG. Or ask the fundamental question: is a flipbook really necessary?

**Mobile devices show rendering errors.** The flipping effect works only partially on touch devices. The 3D page-turn effect is barely visible on small screens, and the swipe gesture conflicts with browser scrolling. Solution: automatically fall back to a simple slider or the native PDF viewer on mobile devices.

## Migration and version compatibility

The flipbook extension has limited support for current TYPO3 versions. The last stable version supports TYPO3 v10 and v11. There is no official release for v12 and v13 (as of April 2026). rflipbook, the alternative extension, is in a similar situation.

Gosign recommends replacing the flipbook with one of the following alternatives during a TYPO3 upgrade: a PDF viewer based on pdf.js (open source, no conversion needed, text remains searchable), HTML preparation of the content (maximum SEO impact, full accessibility) or a lightbox slider with selected pages as images (visual compromise, good performance). The migration is typically completed in 1 to 2 days because the content already exists as PDF and only the display format changes.

For companies that regularly publish new materials (quarterly customer magazines, annual reports), an automated workflow pays off: upload PDF, render server-side via pdf.js, generate preview images, extract full text for search. TYPO3 can automate this process via a scheduler task so editors only upload the PDF and the display happens automatically. The initial effort for this workflow is 3 to 5 development days but saves 2 to 4 hours of manual work with each new publication.

Another aspect is accessibility. Flipbooks are completely inaccessible to screen reader users because the text is embedded in images. The European Accessibility Act (EAA), effective from June 2025, also applies to digital publications on corporate websites. The shift to HTML-based displays or pdf.js (which renders the original text) is therefore not just a performance question but also a legal necessity. Gosign checks during every relaunch project whether flipbooks or comparable image-based displays are present and proposes accessible alternatives before the legislation takes effect.

--- FlowFact TYPO3 - Real Estate CRM | Gosign ---
> FlowFact in TYPO3: property listings, property sync, exposé. OpenImmo integration. AI-accelerated.

## Real estate agents lose leads when properties are transferred to the website manually

An agent maintains their property portfolio in FlowFact: photos, floor plans, prices, amenity features, listing descriptions. The same data should appear on their own website, on ImmobilienScout24, on Immowelt and in printed brochures. Without automatic synchronization, someone types the data twice, forgets to update after a price change or publishes a property that has already been sold. The result: incorrect listings, frustrated contacts, lost leads.

FlowFact (part of the Hypoport Group since 2019) is one of the most widely used CRM systems in the German real estate industry. Over 10,000 agents work with it. The TYPO3 integration synchronizes properties automatically from FlowFact to the agent's website without manual intervention. Gosign has implemented this integration for real estate offices with 50 to 2,000 active properties.

## Typical use cases

**Regional real estate offices with their own website.** A real estate office with 3 to 10 agents manages 200 to 500 active properties in FlowFact. The website shows listings with search functionality (postal code, number of rooms, price range, property type), detail pages with image gallery and floor plan, PDF brochure download and a contact form that routes inquiries directly to the responsible agent in FlowFact. New properties appear on the website within 15 minutes, status changes (sold, reserved) are adopted automatically.

**Project developers and builders.** Companies marketing new construction projects need project landing pages with building descriptions, site plans and apartment overviews as interactive tables alongside property search. FlowFact provides the property data, TYPO3 the editorial environment for project texts and marketing content. Both worlds are connected via the API.

**Property management with tenant portal.** Property management companies use FlowFact to manage rental properties. The TYPO3 website shows available apartments, collects applications through a form and forwards them as contacts into FlowFact. Distinction: the property list automatically filters for "for rent", not "for sale".

## Technical architecture

The connection between FlowFact and TYPO3 runs through two possible interfaces. The classic approach is OpenImmo, an XML-based industry standard for real estate data exchange. FlowFact exports properties as OpenImmo XML (manually or via scheduler), a TYPO3 importer reads the files and creates records. Extensions like openimmo (by justimmo) or custom importers process the XML structure.

The more modern approach is the FlowFact REST API (since FlowFact v3). The TYPO3 server retrieves property data, images and contacts via HTTP requests and synchronizes them into the local database. Advantages over OpenImmo: real-time capable (polling every 5 minutes instead of daily export), granular updates (only changed fields) and access to FlowFact-specific data not included in the OpenImmo standard (e.g. internal notes, lead status).

On the TYPO3 side, properties are stored as records in a dedicated table (not as TYPO3 pages). Listing pages use Extbase repositories with filter functions. Detail pages are rendered through a show action that loads images from FAL (File Abstraction Layer) and displays floor plans as overlays. Map integration is handled through Leaflet or Google Maps, with geocoordinates taken from FlowFact.

## Common problems and solutions

**Images missing after import.** OpenImmo exports reference images as filenames but do not always deliver the files. Solution: configure the export so images are embedded as Base64 in the XML or transferred via FTP alongside the XML. With the REST API, images are downloaded through separate endpoints and must be imported as FAL references in TYPO3.

**Properties disappear after sync.** When FlowFact deactivates or deletes a property, the TYPO3 importer must decide: delete the record, hide it or mark it as "sold"? Standard importers often delete aggressively. Solution: implement a soft delete that initially marks properties as "inactive" and only physically removes them after 30 days. This preserves SEO-relevant URLs that can point to the overview page via 301 redirect.

**Contact form inquiries end up nowhere.** The contact form sends an email, but the lead is not created as a contact in FlowFact. Solution: submit form inquiries through the FlowFact API as a contact with property reference. The responsible agent sees the lead directly in their dashboard. This requires the FlowFact property ID as a hidden field in the form.

## Migration and version compatibility

FlowFact introduced a completely new platform (FlowFact v3) in 2019. The old version (FlowFact Classic) is still operated but receives no new features. The REST API is only available in v3. Existing OpenImmo integrations work with both versions, but the API-based approach is only possible with v3.

On the TYPO3 side, there is no official FlowFact extension with v12/v13 support in the TER. Most installations use custom importers or the openimmo extension (with adaptations). Gosign recommends switching to the FlowFact REST API during TYPO3 upgrades to v12+, rather than porting the OpenImmo XML workflow. The API-based approach is lower maintenance and enables features like real-time availability that are not achievable with XML export.

For real estate offices that feed ImmobilienScout24, Immowelt or Immonet alongside FlowFact, multi-portal synchronization is an important topic. FlowFact can export properties to all major portals simultaneously. The TYPO3 website then becomes another channel - with the advantage that the agent has full control over design and lead generation. Gosign configures the synchronization so FlowFact serves as the single source of truth: every property change flows automatically to the website and to the portals, without manual data reconciliation.

A typical FlowFact-TYPO3 integration project (property import, search function, detail pages, contact form with lead routing) is estimated by Gosign at 10 to 15 development days. Ongoing maintenance is limited to API updates and occasional adjustments when field changes occur in the FlowFact schema.

--- fluid_fpdf TYPO3 - PDF from Templates | Gosign ---
> fluid_fpdf: generate PDFs from Fluid templates. Invoices, certificates, reports. AI-accelerated implementation.

## Wenn PDFs aus Daten entstehen statt aus Screenshots, braucht man fluid_fpdf

Es gibt zwei grundsätzlich verschiedene Ansätze, PDFs in TYPO3 zu erzeugen. Der Screenshot-Ansatz (web2pdf): Die gerenderte Webseite wird als Bild erfasst und in ein PDF gepackt. Einfach, aber das Ergebnis sieht wie eine gedruckte Webseite aus, mit Navigation, Footer und Responsive-Artefakten. Der datengetriebene Ansatz (fluid_fpdf): Ein Fluid-Template definiert das PDF-Layout, TYPO3-Daten füllen die Platzhalter, das Ergebnis ist ein sauberes Dokument mit Corporate Design. Rechnungen, Zertifikate, Angebote, Berichte, alles, was als Dokument existieren muss, braucht den datengetriebenen Ansatz.

fluid_fpdf nutzt die FPDF-Library (eine schlanke PHP-Klasse zur PDF-Erzeugung) und verbindet sie mit TYPO3s Fluid-Template-Engine. Das Ergebnis: Entwickler schreiben PDF-Layouts in derselben Template-Sprache, die sie für HTML-Templates nutzen.

## Typical use cases

**Automatisierte Rechnungserstellung.** Ein Online-Shop oder Buchungssystem in TYPO3 erzeugt bei jeder Bestellung eine Rechnung. Die Rechnungsdaten (Posten, Preise, Kundendaten, Steuern) kommen aus der Datenbank, das Layout aus einem Fluid-Template. Bei einem Veranstaltungsanbieter generiert fluid_fpdf 200-300 Rechnungen pro Monat ohne manuellen Eingriff. Jede Rechnung trägt Rechnungsnummer, Firmenlogo, Bankverbindung und gesetzlich vorgeschriebene Pflichtangaben.

**Teilnahmezertifikate und Bestätigungen.** Bildungsträger, Verbände und Unternehmen vergeben Zertifikate nach Schulungen, Workshops oder Prüfungen. Der Teilnehmername, das Datum, der Kursname und die Unterschrift des Trainers werden automatisch aus den TYPO3-Daten übernommen. Bei einem Bildungsträger mit 5.000 Teilnehmern pro Jahr spart die Automatisierung circa 250 Arbeitsstunden, die zuvor für die manuelle PDF-Erstellung in InDesign anfielen.

**Angebote und Exposés.** Immobilienmakler, Beratungsunternehmen und Agenturen erstellen Angebote mit variablen Inhalten: Kundendaten, ausgewählte Leistungen, individuelle Preise. Das PDF-Layout ist fest (Corporate Design), die Inhalte variieren. fluid_fpdf füllt das Template mit den Daten aus einem TYPO3-Formular oder einem Backend-Modul.

## Technical architecture

fluid_fpdf verbindet zwei Systeme: TYPO3s Fluid-Template-Engine und die FPDF-Library. Die Architektur arbeitet in drei Schritten.

Erstens: Das Fluid-Template definiert die PDF-Struktur. Anstatt HTML-Tags verwendet das Template spezielle ViewHelpers für PDF-Elemente: `<fpdf:page>` für eine neue Seite, `<fpdf:cell>` für eine Textzelle, `<fpdf:image>` für ein Bild, `<fpdf:line>` für eine Linie. Die Syntax ist Fluid, die Ausgabe ist kein HTML, sondern FPDF-Befehle.

Zweitens: TYPO3 stellt die Daten bereit. Über einen Controller oder DataProcessor werden die benötigten Daten (Rechnungsposten, Kundendaten, Produktinformationen) an das Template übergeben. Das funktioniert identisch zum Daten-Handling in HTML-Fluid-Templates: `{invoice.items}`, `{customer.name}`, `{order.total}`.

Drittens: FPDF rendert das PDF. Die ViewHelpers übersetzen die Fluid-Logik in FPDF-Methodenaufrufe (SetFont, Cell, Image, Ln). FPDF erzeugt das PDF als Binärdatei, die entweder direkt zum Browser gesendet (Download) oder im Dateisystem gespeichert wird (z.B. für E-Mail-Versand).

Die Schriftarten-Unterstützung ist ein wichtiges Detail: FPDF unterstützt standardmäßig nur 14 Schriften (Helvetica, Times, Courier und Varianten). Für Corporate Fonts müssen TTF-Dateien als FPDF-Fontdateien konvertiert werden. Das Tool `MakeFont` von FPDF übernimmt die Konvertierung.

Die Tabellen-Darstellung erfordert manuelle Positionierung. FPDF hat kein HTML-Tabellen-Modell. Jede Zelle wird absolut positioniert (X/Y-Koordinaten) oder relativ zur vorherigen Zelle. Für komplexe Tabellen mit variablen Zeilenhöhen muss der Entwickler die Höhenberechnung selbst implementieren.

## Common problems and solutions

**UTF-8-Zeichen werden nicht korrekt dargestellt.** FPDF arbeitet intern mit Latin-1-Encoding. Umlaute (ä, ö, ü), polnische Zeichen (ą, ę, ł) oder kyrillische Buchstaben erfordern UTF-8-Support. Lösung: tFPDF (eine UTF-8-fähige FPDF-Variante) statt FPDF verwenden. fluid_fpdf unterstützt tFPDF als Backend. Alternativ: mPDF nutzen, das UTF-8 nativ unterstützt.

**Seitenumbrüche bei dynamischen Inhalten.** Eine Rechnung mit 5 Posten passt auf eine Seite, eine mit 50 Posten braucht 3 Seiten. FPDF bricht Seiten nicht automatisch um, wenn Inhalt über den Seitenrand hinausgeht. Lösung: Die verbleibende Seitenhöhe vor jedem Posten prüfen (GetY() + Zeilenhöhe > Seitenende) und bei Bedarf eine neue Seite einfügen. Kopf- und Fußzeilen werden über Header()/Footer()-Methoden automatisch auf jeder Seite wiederholt.

**Layout-Entwicklung ist aufwändig.** Ohne visuelle Preview muss der Entwickler nach jeder Änderung das PDF generieren, um das Ergebnis zu sehen. Lösung: Eine Preview-Route einrichten, die das PDF im Browser anzeigt (Output-Modus "Inline" statt "Download"). Bei jedem Refresh wird das PDF neu generiert. Das beschleunigt den Entwicklungszyklus erheblich.

## Migration and version compatibility

fluid_fpdf unterstützt TYPO3 v10 und v11. Für v12 existiert keine offizielle Version, der Portierungsaufwand ist moderat (Extbase-Anpassungen, ViewHelper-Registrierung).

Die Alternativen für TYPO3 v12/v13: EXT:pdfviewhelpers (nutzt TCPDF statt FPDF, mehr Features, aktive Pflege, v12-kompatibel), eine Custom-Lösung mit mPDF als Composer-Paket (HTML/CSS als Input, einfacheres Layout als mit FPDF) oder eine Headless-Lösung mit einem externen PDF-Dienst (Gotenberg, wkhtmltopdf als Docker-Container).

Die Migration von fluid_fpdf auf EXT:pdfviewhelpers ist überschaubar: Die Template-Struktur ist ähnlich (ViewHelper-basiert), aber die ViewHelper-Namen und Parameter unterscheiden sich. Bei einem Projekt mit 5 PDF-Templates liegt der Migrationsaufwand bei 2-4 Tagen. Gosign hat PDF-Generierung in TYPO3 mit allen gängigen Libraries umgesetzt und berät zur passenden Lösung basierend auf den konkreten Anforderungen.

--- focuspoint TYPO3 - Intelligent Image Cropping | Gosign ---
> focuspoint for TYPO3: automatic image cropping with intelligent focus point. Responsive optimization, AI-accelerated.

## focuspoint prevents images from losing important parts of the subject when cropped responsively; the extension sets a focus point around which the crop stays oriented at every aspect ratio

Anyone using images on a responsive website knows the problem: a portrait photo that is shown in a teaser only 200 pixels tall suddenly shows only the neck or the forehead. A landscape photo displayed as a narrow strip in the hero area shows the sky instead of the mountains. Blanket centring leads to main subjects being cut off because the mathematical centre rarely coincides with the actual subject centre. focuspoint solves this by letting editors set a point on the image in the backend that must remain visible on every crop. The output adapts to all aspect ratios without having to generate a separate image variant for every format.

The difference to a classic image pipeline with fixed crops is large. Instead of maintaining separately cropped versions for desktop, tablet and mobile, there is one original image with a focus point and an arbitrary number of output formats that the system computes automatically. For editorial teams with many images, this dramatically reduces maintenance time, and for marketing it opens the possibility of introducing new aspect ratios without rework.

## Typical use cases

The first classic case are people and team pages. A corporate website shows staff portraits in different layouts, as a round avatar in the header, as a square tile in the team list, as a wide format on the detail page. Without a focus point, the photographer has to shoot exactly centred, or the editorial team creates a separate variant for every layout. With focuspoint, the editor sets a point on the face once and the image works in all contexts.

The second case are product and room photos. Estate agents, hoteliers and furniture retailers work with photos where the actual subject, a sofa, a view of a room, a product detail, is not in the middle of the image. focuspoint makes it possible to pick exactly that subject and ensures that it is not lost on mobile devices either.

Third use: magazine and article teasers. Editorial article images often have a clear focal point, for example a speaker on a stage or a product in a scene. In teaser lists with portrait thumbnails, this focal point would often be outside the visible area without a focus point.

## Technical architecture

focuspoint adds two metadata fields to the TYPO3 FAL system: focus_point_x and focus_point_y. Both are maintained in the backend through a form element that displays the original image as a selection area. The editor clicks on the relevant point, and the relative position is stored. Technically, these are two floating point values between zero and one describing the share of image width and height.

When rendering in the frontend, the focus point is evaluated by the Fluid ViewHelper. Instead of the usual "f:image" ViewHelper, the extension uses its own ViewHelper that performs the crop calculation taking the focus point into account and generates the image at the desired target size through the TYPO3 GIFBUILDER pipeline. The result is cached and only regenerated on changes.

The extension plays well with all common image formats (JPEG, PNG, WebP, AVIF) and uses ImageMagick or GraphicsMagick for the actual image processing, the same stack TYPO3 already builds on. For lazy loading and srcset integration there are no conflicts: the ViewHelper can be nested inside picture elements with multiple sources and delivers the right crop for every breakpoint.

## Common problems and solutions

The first problem is the order of ViewHelpers. Anyone adding focuspoint to existing templates that already work with "f:image" and manual crop arguments has to replace the standard with the focuspoint ViewHelper rather than wrap around it. Otherwise both logics run against each other and the result ignores the focus point. The solution is a clean migration of all image references in the sitepackage to the new ViewHelper.

Second problem: cache invalidation. When editors change the focus point, the image cache has to be discarded, otherwise they still see the old crop. TYPO3 usually clears the image cache on changes to the original image, not on metadata changes. The solution is an event listener that specifically deletes the affected processed files on changes to the focus point fields.

Third problem: inconsistent results between backend preview and frontend. The preview in the backend uses a different render path than the frontend, which can lead to small deviations. Pragmatic solution: show only a rough preview in the backend and point editors at the frontend as the authoritative reference.

## Migration and version compatibility

Since version 9, TYPO3 ships a native crop editor in the backend that allows individual variants per image. For simple cases, that is enough. focuspoint differs in that the focus point is set once and automatically feeds into all crop variants, instead of editing every variant individually. Anyone with many images and little editorial time is better off with focuspoint in the long run.

The extension is compatible with TYPO3 v11, v12 and v13. On upgrades from older versions, the FAL metadata structure and the ViewHelpers in use should be brought to the current syntax.

A new class of alternatives are AI-based saliency detections that derive the focus point automatically from the image content. These approaches further reduce editorial work, because editors no longer have to set the point themselves and only correct in exceptional cases. For TYPO3 there are first integrations of this technique, but they are not yet standard and should be evaluated per project.

Gosign configures focuspoint and integrates it into Fluid template architectures. AI-supported analysis of the design layouts proposes optimal crop presets for all breakpoints, so that editors do not have to try every format individually when maintaining images.

--- Linked Checkbox TYPO3 - Form Element | Gosign ---
> Custom checkbox element for the TYPO3 Form Framework with linked label. Essential for legally compliant form design: GDPR consent, terms acceptance.

## form_element_linked_checkbox makes GDPR consent genuinely clickable

The TYPO3 core form framework knows a checkbox but no checkbox with a linked label. Anyone working with the standard element cannot place a link to the privacy policy or to the terms and conditions inside the label, and that is exactly a requirement that comes up on every form in practice. The extension form_element_linked_checkbox closes this gap with a clean custom form element that combines text and link cleanly. For every TYPO3 installation that uses the native form framework, this extension is essentially mandatory. Without it, the only workaround is to extend the label text with a neighbouring text block, which does not only look untidy but is also problematic for screen readers and accessibility.

## Typical use cases live in the compliance environment of every corporate site

The first and most common scenario are GDPR consent boxes below contact, newsletter and application forms. The text "I have read the privacy policy and consent to the processing of my data" has to contain a clickable link to /privacy, without the visitor having to tick the box in order to open it. form_element_linked_checkbox models exactly this case.

A second scenario is terms-and-conditions confirmations on registration and purchase forms. Universities use this for course bookings, associations for membership applications, e-commerce projects based on the TYPO3 form framework at checkout. Here, more than one link is often needed (terms, cancellation policy, privacy), all placed inside the same label.

The third scenario concerns double opt-in newsletters. Before signing up, the recipient has to explicitly confirm that they want to subscribe, with a link to newsletter-specific privacy information. form_element_linked_checkbox allows several checkboxes with their own link to be used in the same form, so that in addition to the privacy consent, the explicit newsletter consent can be asked for as a separate element. This matters, because GDPR requires separate consents and a blanket "I agree to everything" checkbox is not legally sufficient.

## Technical architecture lives in the form framework plug-in system

The TYPO3 form framework is deliberately built to be extensible: every extension can register its own form elements, which show up in the YAML editor and are usable via drag and drop in the backend. form_element_linked_checkbox uses this mechanism and registers a new element "LinkedCheckbox" via the form setup YAML and the form element definitions area. Editors drag the element into their form just as they would drag a standard checkbox and configure label, link text and target in the detail panel.

Internally, the extension extends the checkbox class and adds properties for linkTarget, linkText and wrapLabel. Rendering runs through a dedicated Fluid partial that splits the label text into "before", "linkText" and "after" and wraps the clickable area only around the link part. Clicking on the link opens the target page without toggling the checkbox. For accessibility this matters, because screen readers read the link as a separate element and the checkbox can be operated independently.

Configuration happens directly in the form framework YAML editor: after dragging the element into a form, the fields "Label before link", "Link text", "Label after link" and "Link target" appear in the right-hand detail column. The target can be an internal page, a file link or an external URL. Required field validation is set through the validators tab just like with the standard element.

## Common problems involve multilingual content, styling and validator messages

The first support topic is translation. The label consists of three parts, and each part has to be maintained in every language separately. In practice that means: for a bilingual installation (DE/EN) the maintenance effort doubles. Anyone working with ext:l10nmgr should explicitly reference the LLL keys in the form definition, so that import/export works cleanly. A trick from larger projects: store the three label parts in a single LLL key with placeholders and assemble them server-side on output. That noticeably reduces the number of strings to be translated.

The second topic is styling. Many design systems work with custom checkboxes rebuilt in CSS from a span or label construct. The default template of the extension ships a simple wrapper that collides with some CSS frameworks. We recommend overriding the partial in the package overlay and aligning the structure with the rest of the form styling.

Thirdly, validator error messages are a common stumbling block. When the user does not click the checkbox, the message "Please agree to the privacy policy" should appear, not the default "Required field". The extension supports custom error messages via formElementsDefinition in the form YAML; the message can be adjusted per element. For accessibility this matters, because screen readers read the error message aloud directly and unspecific messages give no help. We recommend phrasing every error message so that it is understandable independently of context.

## TYPO3 v12 and v13 are fully supported, v10 migration needs a YAML adjustment

form_element_linked_checkbox is available for TYPO3 v11, v12 and v13. The YAML structure of the form framework has changed in details between v10 and v12, especially in the registration of custom elements. When upgrading a v10 installation, form definitions that use the element have to be moved to the new YAML syntax.

In Gosign projects we migrate the extension as part of the form framework refactoring, not individually. The effort is usually minimal because the element is referenced in every form only through its type identifier. During the migration we also check whether the GDPR consent texts are rendered correctly in every language after the TYPO3 upgrade and update the privacy links if they have changed in URL structure or text content.

--- Formlog TYPO3 - Form Logging | Gosign ---
> Form logging extension for TYPO3: log all form submissions in the backend. Backup for failed emails, analysis of input behavior, compliance documentation.

## Why every third contact inquiry in TYPO3 is lost without logging

Contact forms are the most important lead channel on corporate websites. But TYPO3's Form Framework does not store submissions in the database by default - it only sends emails. If the mail server fails, the SPF record is misconfigured or the SMTP timeout triggers, the inquiry is lost. No backup, no tracking, no analysis. Formlog closes this gap by logging every form submission in the TYPO3 database - regardless of whether email delivery was successful.

In practice, this affects more companies than expected: email delivery rates from web servers are between 85% and 95% according to studies. With 100 contact inquiries per month, that means 5 to 15 lost leads. At an average lead value of 500 EUR in B2B, this adds up to 2,500 to 7,500 EUR in lost revenue per month.

## Typical use cases

**Insurance against email outages.** A mid-market company operates 3 contact forms on its TYPO3 website. The hoster's SMTP server has a 6-hour timeout over the weekend. Without Formlog, all inquiries during that period are lost. With Formlog, the marketing team finds all submissions in the TYPO3 backend on Monday morning and can follow up manually.

**Compliance documentation for GDPR and ISO 27001.** Companies must be able to demonstrate when which personal data was received and when it was deleted. Formlog stores submissions with timestamps and offers configurable automatic deletion after X days. For ISO 27001 audits, this provides gap-free documentation of data processing.

**Analysis of input behavior.** Which fields are frequently left empty? At which form step do users abandon? Formlog makes this data visible in the backend. A TYPO3 integrator can derive optimizations from this without deploying an external analytics tool for forms.

## Technical architecture

Formlog integrates as a finisher in the TYPO3 Form Framework (EXT:form). Every form that has a Formlog finisher configured writes its submissions after submit into a dedicated database table (`tx_formlog_entries`).

The architecture in detail:

- **Finisher integration**: Formlog registers its own finisher type that is added in the Form Framework's YAML configuration. The finisher runs after validation and before the email finisher.
- **Database schema**: each submission is stored as a JSON-serialized array along with metadata (timestamp, form identifier, language, page).
- **Backend module**: Formlog provides a dedicated backend module where editors and administrators can filter, search and export logged submissions as CSV.
- **GDPR deletion**: via a scheduler task, entries are automatically deleted after a configurable number of days. Default: 90 days.

Dependencies: Formlog requires the TYPO3 Form Framework (EXT:form), which has been part of the Core since TYPO3 v8. Older form extensions like Powermail or Formhandler are not supported - they have logging integrated natively. The database table requires little storage depending on form volume: 1,000 entries with an average of 10 fields occupy about 5 MB. Automatic deletion prevents uncontrolled table growth.

## Common problems and solutions

**Formlog does not log all form fields.** Cause: the Formlog finisher must be configured after the validation step but before the redirect finisher. If the redirect fires first, the Formlog finisher is no longer executed. Solution: check the finisher order in the YAML configuration - Formlog should be at position 1, before email and redirect.

**Backend module shows no entries.** Frequently a permissions issue: the backend user or backend group does not have access to the Formlog module. Solution: enable the `formlog` module under "Allowed modules" in the backend group settings. Additionally, the user must have read access to the SysFolder where entries are stored.

**Automatic deletion does not work.** The TYPO3 Scheduler must be correctly set up and running regularly (cronjob every 5 to 15 minutes). Without a functioning scheduler, the cleanup task is never triggered. On shared hosting environments, the cronjob is frequently not or incorrectly configured. Check in the TYPO3 backend under System > Scheduler: the Formlog cleanup task must be listed as active and the "Last execution" date must not be older than 24 hours.

## Migration and version compatibility

Formlog was developed by Pagemachine (now part of Undkonsorten) and is available as a Composer package (`pagemachine/typo3-formlog`). The extension supports TYPO3 v10 through v12 LTS. For TYPO3 v13, there is no official release yet, but the codebase is built on stable TYPO3 APIs (Form Framework Finisher, Extbase Repository Pattern), so compatibility can be established with manageable effort.

During a TYPO3 upgrade from v10 to v12, the Formlog configuration in the YAML form definitions must be reviewed. The Form Framework changed finisher configuration slightly in v11 (strict typing of options). A database update via the Install Tool Upgrade Wizard is typically not required because the schema has remained stable.

For those migrating from Powermail to the TYPO3 Form Framework, the built-in Powermail logging is lost in the process. Formlog is the recommended replacement. Gosign migrates forms including logging configuration and ensures existing data is not lost.

An aspect many project teams overlook: Formlog is not just a backup tool but also an audit instrument. When a customer claims they sent an inquiry 3 weeks ago that was never answered, Formlog provides the evidence - either the inquiry exists with a timestamp, or it was never submitted. For companies with service level agreements and complaint management, this is a measurable advantage that justifies the 10-minute installation.

--- gb_events TYPO3 - Events | Gosign ---
> Event extension for TYPO3: simple event display and calendar view. Lighter than sf_event_mgt, for events without registration functionality.

## Nicht jede Veranstaltung braucht eine Registrierung, aber jede braucht eine ordentliche Darstellung

sf_event_mgt ist der Standard für Event-Management in TYPO3: Registrierung, Warteliste, Bezahlung, Teilnehmerverwaltung. Aber viele Organisationen zeigen Veranstaltungen nur an, ohne Online-Registrierung. Ein Konzertkalender, ein Veranstaltungsprogramm einer Gemeinde, die Termine einer Volkshochschule, bei all diesen Szenarien wäre sf_event_mgt Overkill. gb_events füllt diese Lücke: einfache Event-Darstellung mit Kalenderansicht, ohne den Overhead eines vollständigen Event-Management-Systems.

Die Extension ist für Organisationen gemacht, die Termine veröffentlichen, aber nicht verwalten wollen. Kein Registrierungsformular, keine Teilnehmerliste, keine Zahlungsabwicklung. Dafür eine saubere Listendarstellung, eine Kalenderansicht und eine Detailseite pro Event.

## Typical use cases

**Gemeinde- und Kirchengemeinde-Websites.** Gottesdienste, Konzerte, Gemeindefeste, Seniorennachmittage, ein typischer Gemeinde-Kalender hat 20-40 Events pro Monat. Besucher wollen sehen, was wann stattfindet, und vielleicht die Termine in ihren persönlichen Kalender übernehmen. Eine Registrierung ist nicht nötig, die Veranstaltungen sind öffentlich. gb_events bildet das mit minimalem Konfigurationsaufwand ab.

**Volkshochschulen und Bildungseinrichtungen (Programmübersicht).** Die Kursanmeldung läuft über ein externes System (Kufer, WebOpac, Stufen), aber das Programm soll auf der TYPO3-Website durchsuchbar sein. gb_events zeigt die Kurse als Event-Liste, gefiltert nach Kategorie (Sprachen, Kreativität, IT, Gesundheit) und Zeitraum. Die Detailseite verlinkt auf das externe Anmeldesystem.

**Veranstaltungsreihen mit wiederkehrenden Terminen.** Ein Sportverein hat Training montags und mittwochs, ein Stammtisch jeden ersten Donnerstag. gb_events stellt wiederkehrende Termine dar, ohne dass jeder Einzeltermin manuell angelegt werden muss. Die Wiederholung wird konfiguriert, gb_events generiert die Termine automatisch.

## Technical architecture

gb_events basiert auf Extbase/Fluid und nutzt eine eigene Datenbanktabelle `tx_gbevents_domain_model_event`. Jedes Event hat die Felder: Titel, Beschreibung, Startdatum, Enddatum, Ort, Bild, Kategorie und optional eine Wiederholungsregel. Die Kategorien nutzen TYPO3s System-Kategorien, was die Integration mit anderen Extensions vereinfacht.

Das Frontend besteht aus drei Views: Listenansicht (chronologisch, filterbar nach Kategorie und Zeitraum), Kalenderansicht (Monatsdarstellung mit klickbaren Tagen) und Detailansicht (vollständige Event-Informationen). Alle Views sind Fluid-Templates und lassen sich im Sitepackage überschreiben.

Die Kalenderansicht rendert ein HTML-Table-Grid mit 7 Spalten (Wochentage) und 4-6 Zeilen (Wochen). Jede Zelle enthält die Events des jeweiligen Tages als verlinkte Titel. Die Navigation zwischen Monaten erfolgt per Link-Parameter (GET), nicht per AJAX. Das ist SEO-freundlich, weil jeder Monat eine eigene URL hat und von Google indexiert werden kann.

Die Wiederholungslogik arbeitet ähnlich wie bei calendarize: Ein Datensatz mit Wiederholungsregel erzeugt virtuelle Events. Diese werden zur Laufzeit berechnet und nicht in der Datenbank materialisiert. Das spart Speicher, erfordert aber Rechenzeit bei jedem Seitenaufruf. TYPO3s Caching-Framework neutralisiert diesen Nachteil für cached Seiten.

## Common problems and solutions

**Events erscheinen nicht in der Listenansicht.** Häufige Ursache: Der Speicherordner (Storage PID) im Plugin stimmt nicht mit dem Ordner überein, in dem die Events angelegt wurden. gb_events filtert Events nach Storage PID. Lösung: Im Plugin-FlexForm den korrekten Speicherordner auswählen oder die Einschränkung per TypoScript aufheben (`persistence.storagePid = 0` zeigt Events aus allen Ordnern).

**Vergangene Events verschwinden sofort.** gb_events blendet Events standardmäßig aus, sobald das Enddatum überschritten ist. Für manche Anwendungsfälle (Veranstaltungsarchiv, Referenzen) sollen vergangene Events sichtbar bleiben. Lösung: Die Repository-Query im Controller anpassen (vergangene Events einschließen) oder einen separaten Listenansicht-Modus "Archiv" konfigurieren.

**Keine iCal-Export-Funktion.** Besucher wollen Events in ihren Kalender übernehmen. gb_events bietet standardmäßig keinen .ics-Download. Lösung: Einen eigenen Page-Type für den iCal-Export anlegen. Das Fluid-Template erzeugt iCalendar-konformen Output (VCALENDAR, VEVENT, DTSTART, DTEND, SUMMARY, LOCATION). Der Aufwand liegt bei circa 3 Stunden Entwicklungszeit.

## Migration and version compatibility

gb_events unterstützt TYPO3 v10 und v11. Für v12 existiert eine Community-Version auf GitHub, die Kompatibilität ist aber nicht vollständig verifiziert. Für v13 gibt es aktuell keine Planung.

Die Alternative für TYPO3 v12/v13 ist sf_event_mgt, die deutlich umfangreichere und besser gepflegte Event-Extension. sf_event_mgt unterstützt v12 und v13 offiziell. Wer keine Registrierungsfunktion braucht, kann sf_event_mgt ohne Registrierung konfigurieren und trotzdem die Event-Darstellung und Kalenderansicht nutzen. Der Funktionsumfang ist größer, die Komplexität aber auch.

Die Migration von gb_events auf sf_event_mgt erfordert eine Datenmigration: Die Events aus `tx_gbevents_domain_model_event` in `tx_sfeventmgt_domain_model_event` überführen. Die Felder sind ähnlich (Titel, Beschreibung, Datum, Ort), aber nicht identisch. Ein SQL-basiertes Migrations-Script erledigt das in 1-2 Stunden. Die Fluid-Templates müssen angepasst werden, da sf_event_mgt andere ViewHelpers und Variablen nutzt.

Für Projekte mit wenigen Events (unter 50 pro Jahr) ist auch eine Custom-Lösung auf Basis von tx_news denkbar: Events als News-Datensätze mit Datumsfeldern und einer Kalender-Darstellung im Template. Gosign berät zur wirtschaftlichsten Lösung und übernimmt bei Bedarf die Migration.

--- Geocoding TYPO3 - Coordinates | Gosign ---
> Geocoding extension for TYPO3: automatically convert addresses to GPS coordinates. Foundation for branch finders, radius search and map display.

## Why every TYPO3 branch finder fails on data quality without geocoding

Branch finders, dealer locators and radius searches all share the same foundation: GPS coordinates. But companies store location data as addresses - street, house number, postal code, city. The conversion from address to coordinates (geocoding) does not happen by itself. geocoordinates solves this problem automatically: the extension monitors address fields in TYPO3 records and calculates the corresponding GPS coordinates via a geocoding service whenever a change is made.

Without a geocoding extension, editors would have to manually copy latitude and longitude from Google Maps for every location. For 50 locations, that is an hour of work. For 500 locations, a full working day - and the process starts over with every address change.

## Typical use cases

**Automatic geocoding for tt_address records.** A company with 120 locations in Germany, Austria and Switzerland maintains all addresses in the TYPO3 extension tt_address. geocoordinates registers a DataHandler hook on the tt_address table. Whenever an editor changes an address or creates a new location, the geocoding service is called in the background. The coordinates are written to the `latitude` and `longitude` database fields. The maps extension maps2 reads these fields and places the marker in the correct position.

**Batch geocoding during data migrations.** A company migrates 2,000 addresses from a legacy system to TYPO3. The imported records have street and postal code but no coordinates. geocoordinates offers a CLI command that geocodes all records without coordinates in a batch run. With the Google Geocoding API, the free tier includes 40,000 requests per month - more than sufficient for a one-time migration.

**Radius search based on postal codes.** A trades business offers radius search: "Find the nearest partner in your area." The visitor enters their postal code, geocoordinates converts the postal code into coordinates, and a SQL distance calculation (Haversine formula) returns all locations within a 25, 50 or 100 km radius, sorted by distance.

## Technical architecture

geocoordinates integrates as a DataHandler hook into the TYPO3 Core. The extension monitors configurable tables and fields. When a monitored address field changes, a geocoding request is triggered asynchronously.

The extension supports two geocoding providers:

- **Google Geocoding API**: high accuracy, globally available, requires an API key with billing enabled. Cost: 5 USD per 1,000 requests, free up to 40,000/month (with 200 USD credit). Advantage: intelligently processes incomplete or incorrect addresses.
- **OpenStreetMap Nominatim**: free, no registration required. Limitations: maximum query rate of 1 request/second, terms of use require a custom user agent. Accuracy in rural areas is sometimes lower than Google.

Coordinates are stored in configurable database fields. Default: `latitude` and `longitude` as `DOUBLE` fields. The extension can be applied to any table via TCA configuration, not just tt_address.

For radius search, geocoordinates provides a Haversine distance function that can be integrated into Extbase repositories or direct QueryBuilder queries. The calculation runs at the database level (MySQL/MariaDB), not in PHP. This is performance-critical: a PHP-based distance calculation over 10,000 locations takes seconds, a SQL-based calculation with an index takes milliseconds. For an index on coordinate fields, a spatial index is recommended if the database uses MySQL 5.7+ or MariaDB 10.2+.

## Common problems and solutions

**Geocoding returns incorrect coordinates for addresses.** Addresses with special characters (e.g. German umlauts in street names) can cause issues if the API does not process the character encoding correctly. Solution: ensure address data is sent to the API in UTF-8. geocoordinates encodes in UTF-8 by default, but legacy database fields with Latin1 encoding can interfere. A database conversion to UTF-8mb4 solves this permanently.

**Google Geocoding API returns "OVER_QUERY_LIMIT".** During batch geocoding with more than 50 requests per second, Google throttles the API. Solution: activate rate limiting in the batch command (max. 40 requests/second for standard accounts). For large batches, run the import overnight or upgrade to a premium plan.

**Nominatim returns different results for the same address.** OpenStreetMap data is community-maintained and can change. An address that was correctly geocoded yesterday may return slightly different coordinates tomorrow if someone edited the OSM data. Solution: mark geocoded coordinates as "verified" and only re-geocode on manual address changes. geocoordinates supports this pattern through an additional database field.

## Migration and version compatibility

geocoordinates is available as a Composer package for TYPO3 v10 through v12. The extension is maintained by Stefan Froemken, who also develops maps2. The two extensions are coordinated but can be used independently.

For TYPO3 v13, compatibility is typically established shortly after the LTS release. The extension uses stable TYPO3 APIs (DataHandler hooks, Extbase repositories) that change little between versions.

Those switching from a manual geocoding workflow (open Google Maps, copy coordinates, enter in TYPO3) to geocoordinates can keep existing coordinates. The extension only writes to empty coordinate fields or on address changes. Existing coordinates are not overwritten unless the administrator triggers a manual re-geocoding run.

Gosign combines geocoordinates with maps2 by default to deliver a complete branch finder stack: address entry by the editor, automatic geocoding in the background, map display with markers and popups in the frontend, radius search with postal code input for the visitor. The stack is set up in 2 to 3 days and covers the requirements of 90% of all branch finder projects.

--- Sweepstakes TYPO3 - Online Raffle | Gosign ---
> Sweepstakes in TYPO3: raffles, entry, drawing. GDPR-compliant, AI-accelerated development.

## Online-Gewinnspiele in TYPO3 scheitern selten an der Technik, fast immer am Recht

Ein Gewinnspiel zu programmieren dauert 3-5 Tage: Formular, Validierung, Auslosung, E-Mail an Gewinner. Es rechtssicher zu machen dauert länger, weil die juristischen Anforderungen den technischen Aufwand übersteigen. Teilnahmebedingungen, separate Marketing-Einwilligung, Koppelungsverbot, automatische Datenlöschung nach Gewinnspielende, Altersprüfung, Ausschluss von Mitarbeitern, das sind keine optionalen Extras, sondern gesetzliche Pflichten. Ein TYPO3-Gewinnspiel ohne diese Absicherung riskiert Abmahnungen und Bußgelder.

TYPO3 bietet keine Standard-Extension für Gewinnspiele. Die Lösung ist immer eine Custom-Entwicklung, die genau die Anforderungen des konkreten Gewinnspiels abbildet. Gosign entwickelt solche Module als Extbase-basierte TYPO3-Extensions mit vollständigem GDPR compliance layer.

## Typical use cases

**Marketing-Kampagnen mit Produktverlosung.** Ein Konsumgüter-Hersteller verlost 10 Produkte unter allen Teilnehmern, die ein Formular ausfüllen. Das Gewinnspiel läuft 4 Wochen, danach werden die Gewinner per Zufallsgenerator ermittelt und per E-Mail benachrichtigt. Die technischen Anforderungen: Formular mit Pflichtfeldern (Name, E-Mail, Alter), Einmal-Teilnahme pro E-Mail-Adresse (Double-Opt-In), Checkbox für Teilnahmebedingungen (nicht vorausgewählt), separate Checkbox für Newsletter-Einwilligung (optional, nicht gekoppelt an Teilnahme), automatische Datenlöschung 30 Tage nach Ende.

**Social-Media-verknüpfte Gewinnspiele.** Teilnehmer werden von Instagram oder Facebook auf die TYPO3-Website geleitet, füllen dort das Formular aus. Die Social-Media-Plattform darf nicht als Teilnahmemechanismus dienen (Plattform-AGBs verbieten das), sondern nur als Traffic-Quelle. Die TYPO3-Seite ist die offizielle Teilnahmeseite. Bei einem Kunden mit 50.000 Instagram-Followern generierten drei Gewinnspiele in einem Jahr 12.000 qualifizierte Kontakte, davon 4.800 mit Newsletter-Opt-In.

**Wiederkehrende Advents- oder Monats-Gewinnspiele.** Ein Adventskalender-Gewinnspiel mit 24 Türchen, jedes mit einem eigenen Preis. Technisch anspruchsvoller: 24 Gewinnspiele in einer Extension, zeitgesteuerte Freischaltung, separate Auslosung pro Tag, Gesamtteilnahme-Tracking (kein doppelter Gewinn). Bei einem Handelsunternehmen steigerte der Adventskalender den Dezember-Traffic um 300% gegenüber dem Vorjahresmonat.

## Technical architecture

Ein TYPO3-Gewinnspielmodul besteht aus fünf Komponenten:

**Teilnahmeformular.** Extbase-Controller mit Fluid-Template. Die Formularfelder sind konfigurierbar: Pflichtfelder (Name, E-Mail), optionale Felder (Telefon, Adresse), Checkboxen (Teilnahmebedingungen, Marketing-Einwilligung). Das Formular nutzt TYPO3s CSRF-Protection (FormToken) und validiert serverseitig. Clientseitige Validierung ist ergänzend, aber nicht allein ausreichend.

**Duplikat-Prüfung.** Jede E-Mail-Adresse darf nur einmal teilnehmen. Die Prüfung erfolgt auf Datenbankebene (unique constraint auf E-Mail + Gewinnspiel-ID). Zusätzlich: Double-Opt-In per Bestätigungs-E-Mail. Erst nach Klick auf den Bestätigungslink gilt die Teilnahme.

**Auslosung.** Ein Scheduler-Task oder manueller Backend-Trigger wählt die Gewinner per kryptographischem Zufallsgenerator (`random_int()` in PHP, nicht `rand()` oder `mt_rand()`). Die Auslosung wird in der Datenbank protokolliert: Zeitpunkt, Seed, Gewinner-IDs. Bei regulatorischen Anfragen lässt sich die Auslosung nachvollziehen.

**Gewinner-Benachrichtigung.** Automatische E-Mail an die Gewinner mit Gratulation und nächsten Schritten (z.B. Adresseingabe für den Versand). Automatische E-Mail an die Nicht-Gewinner (optional, empfohlen für die Kundenbindung). Alle E-Mails über TYPO3s Mail-API mit Fluid-Templates.

**Daten-Lifecycle.** Automatische Löschung aller Teilnehmerdaten nach einem konfigurierbaren Zeitraum (Standard: 30 Tage nach Gewinnspielende). Ein Scheduler-Task prüft täglich, ob Gewinnspiele abgelaufen sind, und löscht die zugehörigen Datensätze. Gewinner-Daten (Name, Adresse) werden separat behandelt, weil sie für den Versand und steuerliche Dokumentation länger aufbewahrt werden müssen.

## Common problems and solutions

**Bot-Teilnahmen verfälschen die Ergebnisse.** Ohne Schutz registrieren Bots tausende Fake-Teilnahmen. Lösung: Honeypot-Feld, Rate-Limiting (maximal 3 Submissions pro IP pro Minute) und Double-Opt-In als dreifache Absicherung. Das Double-Opt-In ist der effektivste Schutz: Bots können Formulare ausfüllen, aber keine Bestätigungs-E-Mails anklicken.

**Koppelungsverbot verletzt.** Die Teilnahme am Gewinnspiel darf nicht an eine Marketing-Einwilligung geknüpft sein. Wenn die Newsletter-Checkbox Pflichtfeld ist, liegt ein Verstoß vor. Lösung: Marketing-Einwilligung immer als optionale, nicht vorausgewählte Checkbox implementieren. Im Formular-Validator prüfen, dass die Teilnahme auch ohne Marketing-Checkbox funktioniert.

**Performance bei hoher gleichzeitiger Last.** Ein virales Gewinnspiel mit 10.000 Teilnahmen in einer Stunde belastet den Server. Lösung: Das Formular-Submit als uncached Seite (USER_INT) konfigurieren, aber die Gewinnspielseite selbst cachen (USER). Für extreme Last: einen separaten Worker-Prozess für die Datenbank-Writes einsetzen und das Formular über eine Queue abarbeiten.

## Migration and version compatibility

Gewinnspiel-Module sind Custom-Entwicklungen und haben keinen Standard-Migrations-Pfad. Bei TYPO3-Upgrades müssen die Extbase-APIs angepasst werden: v9-v10 (Middleware-Stack), v10-v11 (Extbase-Änderungen), v11-v12 (TCA-Refactoring, Backend-Module). Der Aufwand pro Major-Upgrade liegt bei 1-2 Tagen für ein typisches Gewinnspielmodul.

Für wiederkehrende Gewinnspiele lohnt sich eine generische Extension, die über ein Backend-Modul konfiguriert wird: Gewinnspiel-Name, Zeitraum, Preise, Formularfelder, E-Mail-Templates. Diese einmalige Investition (5-8 Entwicklertage) spart bei jedem weiteren Gewinnspiel 80% des Aufwands. Gosign entwickelt solche Module als wiederverwendbare TYPO3-Extensions und übernimmt bei Bedarf den Entwurf der Teilnahmebedingungen, die juristische Freigabe liegt beim Kunden.

--- Hero Slider TYPO3 - Performance | Gosign ---
> Hero slider extension for TYPO3. Often a performance killer: large images, heavy JS libraries. Gosign migrates to CSS-only or Swiper-based solutions.

## Der Hero-Slider ist der teuerste Bereich einer TYPO3-Website, gemessen in Ladezeit

Der Hero-Bereich ist das erste, was Besucher sehen. Bei einem Slider ist es auch das langsamste, was sie sehen. Ein typischer Hero-Slider in TYPO3 lädt 3-5 großformatige Bilder (je 500 KB-2 MB), eine JavaScript-Library (jQuery + Slider-Plugin: 120-200 KB), CSS-Animationen und Initialisierungs-Scripts. Zusammen sind das 3-12 MB Daten, bevor der Besucher irgendwo klicken kann. Der Largest Contentful Paint (LCP) liegt bei solchen Setups routinemäßig über 4 Sekunden, was Google als "schlecht" einstuft und Rankings kostet.

Die Lösung ist nicht ein besserer Slider, sondern entweder kein Slider oder ein radikal leichtgewichtiger. CSS-only-Lösungen und moderne Slider-Libraries wie Swiper erreichen den gleichen visuellen Effekt bei einem Bruchteil der Ladezeit.

## Typical use cases

**Startseiten mit wechselnden Kampagnen.** Marketing will 3-5 Botschaften prominent platzieren: saisonale Kampagne, neues Produkt, Event-Ankündigung, Award-Nachricht. Der Slider rotiert automatisch, jede Slide hat Bild, Headline und CTA-Button. Das Problem: Studien zeigen konsistent, dass nur 1-2% der Besucher über die erste Slide hinaus interagieren. Die restlichen 4 Slides werden geladen, aber nicht gesehen. Ein statisches Hero-Bild mit einer klaren Botschaft performt in A/B-Tests regelmäßig besser als ein Slider.

**Bildergalerien im Header-Bereich.** Hotels, Restaurants und Eventtlocations zeigen Impressionen als Hero-Slider: Außenansicht, Innenraum, Terrasse, Speisen. Hier macht ein Slider inhaltlich Sinn, weil Besucher mehrere Eindrücke erwarten. Die Performance-Optimierung: Nur das erste Bild sofort laden, die restlichen per Lazy Loading nachladen. Mit Intersection Observer und `loading="lazy"` ist das ohne Slider-Library möglich.

**Produkt-Highlights mit Animation.** E-Commerce-Websites zeigen Produkt-Highlights als animierte Slides. Die Animation soll Aufmerksamkeit erzeugen. In der Praxis: CSS-Transitions (`transform`, `opacity`) sind performanter als JavaScript-Animationen und belasten die GPU statt der CPU. Ein CSS-only-Slider mit `scroll-snap-type` und `transition` erreicht 60 fps auf jedem Gerät.

## Technical architecture

Hero-Slider in TYPO3 werden typischerweise als Content Element implementiert: ein FlexForm mit Slide-Konfiguration (Bild, Text, Link, Reihenfolge) und ein Fluid-Template, das die Slides rendert. Die Slider-Logik übernimmt eine JavaScript-Library.

Die verbreiteten Libraries in TYPO3-Projekten: FlexSlider (veraltet, jQuery), Slick (veraltet, jQuery), Owl Carousel (veraltet, jQuery), Swiper (modern, kein jQuery, 139 KB) und Splide (modern, kein jQuery, 29 KB). Die Wahl der Library bestimmt die Performance-Charakteristik des gesamten Hero-Bereichs.

Die optimale Architektur für einen Hero-Slider in 2026:

**Option 1: CSS-only (0 KB JavaScript).** `scroll-snap-type: x mandatory` auf dem Container, `scroll-snap-align: start` auf den Slides. Navigation per `scroll-behavior: smooth` und Anchor-Links. Autoplay per CSS-Animation (`@keyframes`). Kein JavaScript nötig. Funktioniert in allen modernen Browsern. Nachteile: Kein programmatisches Autoplay mit Pause-on-Hover, keine Swipe-Animationen.

**Option 2: Swiper/Splide (29-139 KB JavaScript).** Volle Slider-Funktionalität mit Touch, Swipe, Autoplay, Pagination, Lazy Loading. Tree-Shakeable, nur die genutzten Module werden geladen. Integration in TYPO3 über ein Custom Content Element mit FlexForm.

**Option 3: Statisches Hero (0 KB JavaScript, 1 Bild).** Ein Bild, eine Headline, ein CTA. Das schnellste und conversion-stärkste Setup. Das Bild wird als `<picture>` mit `srcset` ausgeliefert: 375px für Mobile, 768px für Tablet, 1440px für Desktop. Mit AVIF/WebP-Format unter 100 KB pro Variante.

## Common problems and solutions

**LCP über 4 Sekunden.** Das Hero-Bild ist das LCP-Element. Wenn es zu spät lädt, ist der LCP-Score schlecht. Lösung: Das erste Slide-Bild mit `fetchpriority="high"` und `loading="eager"` laden (nicht lazy). Die restlichen Slides mit `loading="lazy"`. Bildformat auf WebP/AVIF umstellen. Bildgröße auf die tatsächliche Darstellungsgröße begrenzen (kein 4000px-Bild für einen 1440px-Viewport).

**Cumulative Layout Shift (CLS) durch nachladende Slider.** Der Slider-Container hat zunächst keine Höhe, nach dem JavaScript-Init springt das Layout. Lösung: Die Höhe des Slider-Containers per CSS fixieren (z.B. `aspect-ratio: 16/9` oder `min-height: 60vh`). Damit reserviert der Browser den Platz, bevor das JavaScript geladen ist.

**Autoplay auf Mobilgeräten funktioniert nicht.** iOS Safari blockiert Autoplay-Videos und manche CSS-Animationen aus Energiespar-Gründen. Lösung: Autoplay auf Mobilgeräten deaktivieren und stattdessen Swipe-Navigation anbieten. Besucher auf Smartphones wissen, dass sie wischen können. Ein statischer Hinweis ("Wischen für mehr") ist unnötig.

## Migration and version compatibility

Die meisten Hero-Slider-Extensions im TER sind veraltet und unterstützen maximal TYPO3 v10 oder v11. Für v12/v13 empfiehlt sich ausnahmslos ein Custom Content Element im Sitepackage, das eine moderne Library einbindet oder komplett auf CSS setzt.

Die Migration bestehender Slider erfolgt in drei Schritten: Slide-Daten exportieren (Bilder, Texte, Links aus der FlexForm oder Datenbank), neues Content Element aufsetzen (FlexForm mit denselben Feldern, aber modernem Template) und die bestehenden Content-Elemente per SQL auf den neuen CType umstellen. Der Aufwand: 1-2 Tage für das technische Setup, plus 0,5 Tage pro 10 existierenden Slidern für die Datenmigration.

Gosign empfiehlt bei jedem Hero-Slider-Projekt zuerst die Frage: Braucht die Website wirklich einen Slider? In 70% der Fälle performt ein statisches Hero-Element besser. Für die restlichen 30% liefert Gosign eine Swiper- oder CSS-only-Lösung, die unter 1,5 Sekunden LCP bleibt.

--- Highcharts TYPO3 - Data Visualization | Gosign ---
> Embed interactive Highcharts charts in TYPO3. Manage charts, graphics and data visualizations directly in the CMS.

## Highcharts brings interactive data visualisation into the TYPO3 backend when editors should maintain charts without working in Excel or external tools

Numbers, KPIs and trends belong on corporate websites, as financial figures in the investor relations area, as market data in content marketing, as evaluation results at associations and public authorities. The classic solution is static graphics created somewhere in Excel, exported as PNG and uploaded manually. That is tedious and error-prone: when a number changes, the entire graphic has to be redone. Highcharts solves the problem by generating charts directly from structured data, interactively in the browser, with tooltips, hover effects and zoom functions. The TYPO3 integration makes the editorial process fully backend-driven: editors maintain data series in an input mask, and the extension generates the chart.

The real productivity lever emerges when data series are not maintained manually but pulled from external sources. A CSV from controlling, an export from a data warehouse or an API call to an internal dashboard delivers the figures, and TYPO3 renders the public chart from them. This separation between data source and presentation turns the maintenance of KPIs into a commit, not a screenshot exchange.

## Typical use cases

The classic case are investor relations and financial data pages. A listed company shows revenue development, employee numbers and market shares as interactive charts. On quarterly releases, the IR team simply updates the data series, the chart refreshes automatically, and visitors can read the exact values per year on mouse-over.

The second case are evaluation and study results at associations, foundations and public authorities. A member survey, an environmental study or an economic survey is presented as bar, line or pie chart. Highcharts makes it possible to present complex datasets with many categories clearly and offers export functions that let visitors take the charts away as image or PDF.

Third use: content marketing and data journalism. Corporate blogs and specialist magazines use interactive graphics to explain complex relationships, price developments, market shares, usage statistics. Interactivity increases time on page and makes the content quotable for other media.

## Technical architecture

Highcharts as a JavaScript library is an established product from the Norwegian company Highsoft, distributed under a commercial licence but available free of charge for non-commercial purposes. The TYPO3 integration adds backend forms for maintaining data series and renders the matching JavaScript code in the frontend that initialises Highcharts.

Typically, the extension consists of a content element in which editors configure chart type (line, bar, pie, area), axis labelling, colours and data series. Every data series can be maintained manually as a table or pulled from external sources such as CSV files, database queries or REST APIs. In the frontend, the extension emits a div container with configuration JSON, and a script block initialises Highcharts and renders the chart client-side.

The licensing question is central. For commercial TYPO3 projects, a Highcharts licence has to be purchased, ranging from a few hundred to several thousand euros per year depending on scope. Anyone who wants to avoid that finds good alternatives in Chart.js, ApexCharts or Plotly, which are MIT or Apache licensed. The decision rests on features: Highcharts offers the broadest range of chart types and the best documentation, while the alternatives reliably cover standard cases.

## Common problems and solutions

The first problem is unclear licensing. Projects start with the assumption that Highcharts is free, and the commercial bill arrives later. The solution lies in an early licence check: if the project is commercial, either a Highcharts licence is budgeted or a free alternative is picked from the start. Gosign clarifies this question at kickoff.

Second problem: performance with many data series. A chart with thousands of data points blocks the browser on rendering. The solution is either data reduction through server-side aggregation or the use of Highcharts modules such as Boost, which render large volumes on WebGL. For standard cases, compressing the raw data to a sensible granularity before it reaches the browser is enough.

Third problem: accessibility. Interactive charts are often inaccessible for screen readers. Highcharts offers an accessibility module that makes the data available as a structured table alongside the visual chart. The pragmatic addition is to show a regular HTML table with the same data below every chart, visually hidden via CSS but still available for screen readers.

## Migration and version compatibility

TYPO3 integrations for Highcharts exist in several variants of varying quality and currency. For TYPO3 v11 there are actively maintained extensions; for v12 and v13 the choice is smaller, and adjustments to ext_emconf and service configurations are often needed. Anyone starting fresh today should soberly check whether an existing extension still fits or whether a sitepackage integration with a free library such as Chart.js is the more future-proof path.

In an upgrade scenario, the Highcharts version is the critical factor. New Highcharts releases occasionally break the API, especially for complex chart types. A migration should therefore always be tested on a staging system before touching live dashboards.

A pragmatic approach for existing projects: inventory current charts, list the features actually used and check whether a free alternative covers the same ground. In many cases, the requirements are modest (line and bar charts with a few data series), and a free library covers them without loss of quality. The saved licence budget can instead be spent on better content management of the data series.

Gosign integrates Highcharts into TYPO3, guides licence clarification and migration projects, and implements lightweight alternatives such as Chart.js or ApexCharts as a sitepackage component when needed. The right choice depends on which chart types are actually needed and what budget is available for licences.

--- Hotspot TYPO3 - Interactive Images | Gosign ---
> TYPO3 extension for interactive image hotspots: clickable areas on images with tooltip or overlay. Product images, floor plans, infographics.

## Interaktive Bilder erklären komplexe Produkte besser als 1.000 Worte Text

Ein Gebäudeplan mit 12 markierten Räumen, ein Maschinenquerschnitt mit 8 beschrifteten Bauteilen, eine Europakarte mit 15 Standorten: All diese Anwendungsfälle brauchen klickbare Bereiche auf einem Bild. Der Besucher klickt auf ein Bauteil und sieht dessen Spezifikationen. Er klickt auf einen Standort und sieht Adresse und Kontakt. Hotspot-Extensions für TYPO3 machen Bilder interaktiv, indem sie definierte Bereiche mit Tooltips, Overlays oder Links verknüpfen.

Die spannendere Frage ist, ob man dafür überhaupt eine Extension braucht. SVG-basierte Hotspots funktionieren ohne Extension, sind leichter, barrierefreier und vollständig im Sitepackage kontrollierbar. Für einfache Anwendungsfälle ist SVG der bessere Weg. Für komplexe Setups mit vielen Hotspots und Backend-Pflege durch Redakteure rechtfertigt eine Extension den Einsatz.

## Typical use cases

**Produktbilder mit klickbaren Bauteilen.** Hersteller von Maschinen, Geräten und technischen Produkten nutzen Hotspots, um Bauteile auf einem Produktfoto zu beschriften. Ein Industriekompressor mit 8 Baugruppen: Klick auf den Motor zeigt Leistungsdaten, Klick auf den Filter zeigt Wechselintervalle. Statt einer langen Textbeschreibung erschließt sich die Information visuell. Bei einem Maschinenbauer steigerten interaktive Produktbilder die Verweildauer auf Produktseiten um 45%.

**Gebäude- und Campuspläne.** Hochschulen, Kliniken und große Unternehmen zeigen interaktive Lagepläne: Gebäude anklicken, Etage auswählen, Rauminformationen sehen. TYPO3 liefert die Raumdaten aus einer Extbase-Datenquelle, die Hotspots sind auf dem Grundriss positioniert. Bei einem Klinikum mit 14 Gebäuden ersetzten interaktive Pläne den gedruckten Wegweiser komplett.

**Infografiken mit Detailinformationen.** Marketing-Abteilungen produzieren Infografiken zu Prozessen, Wertschöpfungsketten oder Unternehmensstrukturen. Statt eine statische PNG-Datei zu zeigen, werden die Elemente der Infografik klickbar: Klick auf eine Prozessstufe öffnet die Detailbeschreibung. Das funktioniert besonders gut bei komplexen Themen, die nicht linear erklärt werden können.

## Technical architecture

Hotspot-Extensions in TYPO3 bestehen aus drei Teilen: einem Backend-Editor zur Positionierung der Hotspots, einer Datenstruktur für Hotspot-Inhalte und einem Frontend-Renderer, der die Hotspots auf dem Bild darstellt.

Der Backend-Editor ist typischerweise ein visueller Punkt-Platzierungs-Editor: Der Redakteur sieht das Bild im TYPO3-Backend und klickt auf die Stellen, an denen Hotspots erscheinen sollen. Die Koordinaten werden als Prozentwerte (relativ zur Bildgröße) gespeichert, nicht als Pixel. Prozentwerte stellen sicher, dass die Hotspots bei responsiver Bilddarstellung an der richtigen Stelle bleiben.

Die Datenstruktur pro Hotspot: X-Position (%), Y-Position (%), Tooltip-Text, Detail-Content (HTML/Fluid), Icon-Typ und optional ein Link auf eine Detailseite. Die Daten werden als Inline-Relationen (IRRE) zum Content-Element gespeichert: Ein Content-Element hat 1:n Hotspots.

Im Frontend werden die Hotspots als absolut positionierte HTML-Elemente über dem Bild gerendert. Das Bild liegt in einem Container mit `position: relative`, die Hotspots haben `position: absolute` mit `left` und `top` in Prozent. Beim Klick oder Hover erscheint der Tooltip als Overlay, positioniert relativ zum Hotspot.

Die SVG-Alternative funktioniert ohne Extension: Das Bild wird als SVG angelegt (oder das Bild wird als `<image>` in ein SVG eingebettet), die Hotspots sind SVG-Elemente (`<circle>`, `<rect>`, `<polygon>`) mit `data-`Attributen und Event-Handlern. Die Tooltip-Inhalte werden per JavaScript aus einem `<script type="application/json">` Block gelesen.

## Common problems and solutions

**Hotspot-Positionen verschieben sich auf Mobilgeräten.** Das Bild wird auf dem Smartphone kleiner dargestellt, aber die Hotspots bleiben an der Desktop-Position. Ursache: Die Hotspots sind in Pixel statt in Prozent positioniert, oder der Container hat keine responsive Größenanpassung. Lösung: Alle Positionen in Prozent speichern und den Container mit `max-width: 100%` und `height: auto` responsiv machen. Zusätzlich: Hotspots auf Mobilgeräten als Liste unterhalb des Bildes anzeigen, weil Fingertipps auf kleine Hotspot-Punkte schwierig sind.

**Barrierefreiheit nicht gegeben.** Rein visuelle Hotspots ohne Tastatur-Navigation und ohne Screenreader-Text sind nicht barrierefrei. Lösung: Jeden Hotspot als `<button>` implementieren (nicht als `<div>`), mit `aria-label` für den Screenreader und `tabindex` für die Tastatur-Navigation. Der Tooltip-Inhalt muss als `aria-describedby` verknüpft sein.

**Performance bei vielen Hotspots.** 20+ Hotspots auf einem Bild erzeugen 20+ DOM-Elemente mit Event-Listenern. Auf älteren Mobilgeräten kann das zu Ruckeln führen. Lösung: Event Delegation statt individueller Listener. Ein einziger Listener auf dem Container statt 20 auf den Hotspots. Bei SVG-basierten Hotspots ist die Performance generell besser, weil SVG-Elemente nativ vom Browser gerendert werden.

## Migration and version compatibility

Hotspot-Extensions im TER unterstützen TYPO3 v10 und v11. Für v12 und v13 existieren keine breit gepflegten Hotspot-Extensions. Der Trend geht zu SVG-basierten Lösungen, die als Custom Content Element im Sitepackage implementiert werden und keine Drittanbieter-Extension erfordern.

Die Migration von einer Hotspot-Extension auf eine SVG-basierte Lösung erfordert: die Hotspot-Daten (Koordinaten, Texte) exportieren, ein SVG-Template erstellen, das die Punkte als SVG-Elemente rendert, und ein Custom Content Element aufsetzen, das die Daten per IRRE-Relation verwaltet. Der Aufwand liegt bei 3-5 Tagen, abhängig von der Anzahl der Hotspot-Bilder.

Die zukunftssicherste Lösung: CSS-basierte Hotspots mit `<map>` und `<area>` für einfache Szenarien, SVG mit JavaScript für komplexe Interaktionen. Gosign implementiert interaktive Bilder als Custom Content Elements und berät zur passenden Technologie basierend auf Komplexität, Barrierefreiheits-Anforderungen und Anzahl der Hotspot-Bilder.

--- Club List TYPO3 - Municipal | Gosign ---
> Club list plugin for TYPO3: display, filter and sort clubs. Typical for municipal websites and umbrella organizations. Category filter, full-text search.

## Kommunen und Dachverbände brauchen eine strukturierte Vereinsdatenbank statt statischer Listen

Wer auf einer Gemeinde-Website oder dem Portal eines Landessportbundes nach dem lokalen Schachclub sucht, erwartet eine Filtermaske und keine 15-seitige PDF-Liste. Genau dieses Problem löst hwvereinsliste: Die Extension bildet Vereine als TYPO3-Records ab und macht sie über Kategorie-Filter, Volltextsuche und Detailansichten zugänglich. Für kommunale Webauftritte, Dachverbände und Kreissportbünde ist das Plugin seit Jahren ein bewährtes Werkzeug, das Redaktionen die Pflege ohne Entwickler-Eingriffe erlaubt.

Die Realität in deutschen Kommunen sieht allerdings so aus, dass Vereinsregister oft noch als Word-Dokumente in Amtsleitungen kursieren. hwvereinsliste ersetzt diesen Workflow durch eine zentrale Datenbank im TYPO3-Backend, die über Frontend-Plugins ausgesteuert wird. Bürger finden ihren Verein in Sekunden, Redakteure aktualisieren Kontaktdaten ohne FTP-Zugang.

## Typical use cases range from Gemeindeportalen bis zu Sportkreis-Datenbanken

Das häufigste Szenario ist die klassische Vereinsliste auf einer kommunalen Website. Eine Gemeinde mit 80 bis 120 eingetragenen Vereinen pflegt alle Einträge zentral im TYPO3-Backend. Bürger filtern im Frontend nach Kategorien wie Sport, Kultur, Soziales oder Jugend. Die Detailansicht zeigt Ansprechpartner, Trainingszeiten und Kontaktdaten. Die Redaktion der Gemeinde-Website aktualisiert Einträge selbstständig, ohne technische Hilfe.

Das zweite Szenario betrifft Dachverbände und Kreissportbünde. Ein Landessportbund verwaltet oft 500 bis 2.000 Mitgliedsvereine in dutzenden Sportarten. Hier wird die Filterfunktion zum Kernfeature: Nutzer kombinieren Sportart, Ort und Altersgruppe, um den passenden Verein in der Nachbarschaft zu finden. hwvereinsliste unterstützt diese Mehrfach-Filterung nativ.

Ein drittes Szenario sind Verzeichnisportale im Ehrenamts-Bereich. Freiwilligenagenturen nutzen die Extension, um Organisationen zu listen, die ehrenamtliche Unterstützung suchen. Die Kategorisierung läuft über TYPO3-Sys-Categories, was Überschneidungen mit anderen Content-Elementen auf der gleichen Seite erlaubt. In manchen Fällen wird die Extension auch als Branchenverzeichnis für lokale Wirtschaftsförderung eingesetzt, wobei Unternehmen statt Vereine gelistet werden.

## Technical architecture is based on Extbase-Records und Fluid-Templates

hwvereinsliste nutzt das Extbase/Fluid-Framework von TYPO3. Vereine werden als eigene Domain-Records in einer dedizierten Tabelle gespeichert. Jeder Record enthält Felder für Name, Beschreibung, Adresse, Kontaktdaten, Website-URL, Logo und Kategorien. Die Kategorisierung verwendet TYPO3-Sys-Categories, was die Integration mit anderen Extensions vereinfacht.

Im Frontend stehen zwei Plugins zur Verfügung: eine Listenansicht mit Filter- und Suchfunktion sowie eine Detailansicht für einzelne Vereine. Die Templates sind Fluid-basiert und lassen sich über TypoScript-Pfade oder ein Site-Package überschreiben. Wer das Layout anpassen will, kopiert die Fluid-Templates ins eigene Package und passt HTML-Struktur und CSS-Klassen an, ohne die Extension selbst zu verändern.

Die Filterung arbeitet standardmässig clientseitig bei kleinen Datenmengen und serverseitig bei grösseren Beständen. Für Installationen mit mehr als 500 Vereinen empfiehlt sich die Kombination mit einer Suchindex-Lösung wie ke_search, um die Performance der Volltextsuche zu verbessern.

Ein Aspekt, der bei kommunalen Projekten oft vergessen wird: die Barrierefreiheit. Seit dem Barrierefreiheitsstärkungsgesetz (BFSG) müssen öffentliche Stellen ihre Webauftritte barrierefrei gestalten. Das betrifft auch die Vereinsliste: Filter-Elemente müssen per Tastatur bedienbar sein, Ergebnislisten brauchen ARIA-Labels, und die Suchfunktion muss Screenreader-kompatibel arbeiten. Die Standard-Templates der Extension erfüllen diese Anforderungen nicht vollständig und müssen angepasst werden.

## Common problems involve Import, Kategorisierung und responsive Darstellung

Das häufigste Problem bei der Ersteinrichtung ist der Datenimport. Kommunen haben ihre Vereinsdaten typischerweise in Excel-Listen mit inkonsistenten Formaten. Spaltennamen variieren, Kategorien sind als Freitext statt als standardisierte Taxonomie gepflegt, und Kontaktdaten enthalten veraltete Einträge. Gosign löst das über einen KI-gestützten Import-Workflow: Die Excel-Datei wird automatisch analysiert, Spalten werden gemappt, Kategorien normalisiert und Duplikate erkannt. Was früher einen halben Tag manuelle Nacharbeit kostete, läuft so in unter einer Stunde.

Das zweite Problem betrifft die Kategoriestruktur. Wenn Kategorien im Vorfeld nicht sauber definiert werden, entstehen Redundanzen wie "Fussball", "Fußball-Verein" und "Fussballclub" als drei separate Einträge. Wir empfehlen, vor dem Go-Live eine Kategorie-Taxonomie mit maximal 15 bis 20 Oberkategorien festzulegen und diese im TYPO3-Backend als Sys-Categories anzulegen.

Drittes Problem: Die responsive Darstellung der Listenansicht. Auf Mobilgeräten wird die Tabellen-Darstellung schnell unübersichtlich. Die Fluid-Templates sollten für mobile Viewports eine Karten-Darstellung statt einer Tabelle rendern, was über eine einfache Template-Anpassung im Site-Package realisierbar ist. Gosign liefert responsive Templates für Vereinslisten standardmässig mit, die auf Smartphones als Card-Grid und auf Desktops als Tabelle dargestellt werden.

## Migration auf v12 requires Extbase-Anpassungen, v13 ist noch nicht offiziell unterstützt

hwvereinsliste wurde primär für TYPO3 v9 und v10 entwickelt. Für TYPO3 v12 ist eine Anpassung der Extbase-Persistenz nötig, da sich die Query-Schnittstelle geändert hat. Konkret betrifft das die Repository-Klassen und die TypoScript-basierte Persistenz-Konfiguration, die seit v12 über Classes.php gelöst wird. Die Template-Pfade müssen ebenfalls auf die neue SiteSet-Struktur umgestellt werden.

Für TYPO3 v13 gibt es aktuell keine offizielle Unterstützung durch den Extension-Autor. Wer auf v13 migriert, muss die Extension entweder selbst anpassen oder eine alternative Lösung evaluieren. Gosign prüft in solchen Fällen, ob eine Migration der Extension oder ein Neubau auf Basis von Extbase mit aktueller API wirtschaftlicher ist. Bei kleinen Vereinsdatenbanken mit unter 200 Einträgen ist ein Custom-Plugin oft die bessere Wahl, weil es exakt auf die Anforderungen der Kommune zugeschnitten ist und keine Legacy-Abhängigkeiten mitbringt.

--- imagemap TYPO3 - Interactive Graphics | Gosign ---
> imagemap for TYPO3: interactive graphics with clickable areas. Responsive, accessible, SVG alternatives.

## imagemap makes images clickable without requiring editors to touch HTML, the right choice for floor plans, org charts and product graphics with several hotspots

Some content cannot be explained as efficiently through words as through an image with clickable areas. A building plan in which every department leads to the corresponding team page. An org chart with links to individual person profiles. A product image where a click on the wheel, the engine or the cockpit shows the relevant technical details. HTML has offered image map functionality since the 1990s, but no editor wants to type coordinates by hand into a text field. imagemap retrofits this functionality in TYPO3 with a visual editor: editors click on the image in the backend, mark an area and link it to a target page.

The actual promise of the extension is that spatial orientation and navigation are merged. Instead of forcing visitors to jump between a graphic view and a separate link list, the graphic itself becomes the navigation element. For content that is structured geographically, hierarchically or technically, this offers a significantly more intuitive entry point.

## Typical use cases

The first case are site plans and campus overviews. Hospitals, universities, exhibition grounds and industrial parks work with overview maps where individual buildings or areas link directly to information pages. The classic alternative would be a list with links, but that loses the spatial reference. imagemap combines graphic orientation with the link structure.

The second use case are org charts and hierarchies. A company shows the structure of its departments as a graphic, and every node leads to the profile of the respective executive or the department page. For the editorial team this is easier to maintain than a complex table layout with linked cells.

Third case: product graphics with feature hotspots. Technical products, machines, vehicles, devices, are shown on an exploded view or a cross-section where the most important components are explained on click. This replaces a long text list and takes visitors directly to where their interest lies.

## Technical architecture

The classic imagemap extension for TYPO3 maintains the coordinates as structured records in the database and renders an HTML map element with the matching area tags in the frontend. In the backend, a visual editor is available that displays the original image as a selection area and allows editors to draw rectangles, circles or polygons on it. Each area receives a target URL, alternative text and, optionally, a tooltip.

The technical challenge lies in responsiveness. The classic HTML map works with absolute pixel coordinates that no longer fit when images are scaled. imagemap extensions solve this with JavaScript that recomputes the coordinates relatively on resize or by using SVG as the output format. SVG is the cleanest solution here: vector coordinates scale natively, event handling and styling via CSS work out of the box, and screen readers can read the structured elements.

Integration happens through a content element in the page module. Editors pick the source image from FAL, define the hotspots and optionally configure global settings such as default area colour, hover effects and tooltip behaviour. The output can be adjusted through a Fluid template in the sitepackage to maintain corporate design compliance.

## Common problems and solutions

The first problem is accessibility. HTML image maps are only sensibly readable for screen readers if every area tag has a meaningful alternative text and the map itself is recognised as structured navigation. Many editors fill the alt text carelessly or leave it blank, which makes the map useless for blind users. The solution is an editorial rule that every hotspot has to carry a descriptive alt text, and a technical check in the sitepackage that prevents empty texts on save.

Second problem: mobile usability. A hotspot that measures 30 by 30 pixels on desktop is tiny on a smartphone. The pragmatic solution is a mobile alternative that below a certain breakpoint replaces the image with a list of the same targets. This requires a Fluid logic that renders two variants and switches between them via CSS.

Third problem: maintenance effort when the image changes. If the base image (for example a site plan or product photo) is replaced, all coordinates have to be set again because the subjects have shifted. Pragmatic solution: editors work with a fixed, versioned image format and document the coordinate grids, so that only minimal corrections are needed on updates. Alternatively, an SVG-based solution can work with relative coordinates from the start.

## Migration and version compatibility

For TYPO3 v11, v12 and v13 there are several imagemap extensions that are actively maintained, often under slightly different names. On upgrades it is worth looking whether the originally used extension is still being developed or whether switching to a more modern alternative makes more sense. SVG-based approaches will displace classic HTML maps in the medium term because they perform better on responsiveness and accessibility.

A practical note for migrations: if an existing project contains dozens of image maps, it pays off to write a script that reads the existing coordinate records and converts them into SVG paths. The switch can then happen in a single deployment and the extension can be switched off. This reduces technical debt and makes the graphics future-proof.

Anyone starting fresh today should prefer the SVG approach, either through an extension with SVG output or through a sitepackage pattern that offers editors a visual editor and emits SVG in the frontend. Gosign implements both paths and advises on the right architecture for the given project.

--- in2publish TYPO3 - Content Staging | Gosign ---
> in2publish: publish content from staging to live. Multi-server setup & workflows, AI-accelerated.

## Why in2publish defines the content workflow in enterprise TYPO3 projects

In professional TYPO3 installations, editors do not work directly on the live system. They maintain content on a staging environment, coordinate changes internally and publish only after approval. But how does the data get from staging to live? Without in2publish, this means: create a database dump on staging, import it on live, synchronize files via FTP. A process that is error-prone, takes 30 to 60 minutes and where one wrong click can overwrite the entire live database.

in2publish by in2code eliminates this process. Editors click "Publish" in the TYPO3 backend, and the extension synchronizes exactly the changed records and files to the live system. No FTP credentials, no database dumps, no downtime. The industry standard for content staging in TYPO3.

## Typical use cases

**Editorial approval workflow.** A corporation operates its corporate website on TYPO3 with 12 editors across 3 departments. Each department maintains its section on staging. Team leads review changes and approve them. The editor clicks "Publish" and only their approved pages go live. Other areas of the website remain untouched. in2publish shows a diff view: which fields changed, which images are new, which records will be overwritten.

**Multi-language publishing.** A company maintains its website in 5 languages. The German editorial team publishes finished texts while the English translation is still in progress. in2publish enables selective publishing per language: German content goes live, English stays on staging until the translation is complete.

**Campaign launches with defined dates.** The marketing team prepares a product launch page that should go live on October 15 at 8:00 AM. All content - texts, images, videos, landing pages - is prepared and tested on staging. On launch day, the responsible editor publishes everything in a single step. If problems arise, in2publish can reverse the changes. For time-critical launches, this is a decisive advantage over manual deployment processes where a rollback takes 30 minutes or more.

## Technical architecture

in2publish operates at the database and file system level. The extension compares the state of the staging database with the live database and transfers differences.

The architecture consists of four core components:

- **Record comparison**: in2publish compares every record (uid, table, fields) between staging and live. Changed, new and deleted records are identified and displayed in a tree structure. Relations (e.g. page has content elements, content element has images) are resolved so that publishing a page automatically includes all dependent records.
- **FAL synchronization**: images and documents from the File Abstraction Layer are transferred to the live system via SSH/SFTP. in2publish compares file sizes and hashes to transfer only changed files.
- **Transport layer**: communication between staging and live occurs via SSH. in2publish connects to the live server via public key authentication and executes CLI commands there. Alternatively, the enterprise version supports HTTP-based communication through an API.
- **Configuration**: a YAML configuration defines which tables are published (whitelist) and which are excluded (e.g. sys_log, be_sessions, cache tables). The default configuration covers all content-relevant tables.

Dependencies: TYPO3 Core, SSH access between staging and live servers, PHP SSH2 extension or ssh2 binaries on the server. The network architecture requires that the staging server can establish an outgoing SSH connection to the live server. In corporate networks with restrictive firewall rules, a dedicated SSH port must be opened.

## Common problems and solutions

**Publishing aborts with "SSH Connection Failed".** The most common cause: the staging server's SSH key is not deposited on the live server, or the SSH configuration in in2publish points to the wrong host/port. Solution: manually test the SSH connection (`ssh -i /path/to/key user@live-server`), then verify the credentials in the in2publish configuration. With managed hosting environments, the hoster often needs to enable SSH access between instances.

**Records on live are not updated.** The table is not included in the whitelist of the in2publish configuration. This frequently happens with custom tables from proprietary extensions. Solution: add the table to the configuration and define the relations (which field references which other table). Without correct relation configuration, in2publish cannot resolve dependencies.

**FAL files missing after publishing on live.** The FAL storage on the live system has a different path than on staging, or permissions on the live server do not allow writing to the upload folder. Solution: ensure the FAL storage base path is identical on both systems and the SSH user has write permissions in fileadmin.

## Migration and version compatibility

in2publish is actively maintained by in2code and available for TYPO3 v11 and v12 LTS as a Composer package. The enterprise version offers additional features (HTTP transport, extended logging, multi-environment support) and is commercially licensed.

For TYPO3 v13, in2code is working on a compatible version. The extension uses stable TYPO3 APIs (DataHandler, FAL), so porting typically occurs shortly after the LTS release.

During a TYPO3 upgrade, the in2publish configuration must be reviewed: new system tables, changed TCA definitions and new content element types require whitelist adjustments. Gosign recommends a test publish with a single page after every core upgrade to validate the configuration before full editorial operations resume. The test should include a page with all relevant content types: text elements, images, file downloads and at least one relation (e.g. news record with categories). Only this way are all synchronization paths covered.

--- in2studyfinder TYPO3 - Study Programs | Gosign ---
> Study program finder for university TYPO3 websites. Filter by department, degree, location, study format. University-specific extension by in2code.

## Studieninteressierte erwarten eine Suchmaschine, keine PDF-Broschüre

Hochschulen mit 50 bis 300 Studiengängen stehen vor einem konkreten Problem: Studieninteressierte wollen filtern, nicht scrollen. Sie suchen nach Abschlussart, Fachbereich, Studienform und Standort - gleichzeitig. in2studyfinder von in2code löst genau das innerhalb von TYPO3. Die Extension wurde speziell für den Hochschulbereich entwickelt und bildet die komplexe Struktur aus Bachelor, Master, Diplom, Vollzeit, Teilzeit, dual und berufsbegleitend in einer einzigen Filtermaske ab. Über 20 deutschsprachige Hochschulen setzen die Extension produktiv ein.

Für Hochschul-Webteams, die ihre Studiengangs-Informationen bisher über statische Seiten oder selbstgebaute Lösungen pflegen, ist der Wechsel auf in2studyfinder ein erheblicher Effizienzgewinn. Statt für jeden neuen Studiengang eine eigene Unterseite anzulegen, pflegen Redakteure einen Datensatz im Backend, und die Extension erzeugt Listenansicht, Detailseite und Filterfunktion automatisch. Das spart bei einer Fachhochschule mit 80 Studiengängen geschätzte 40 Stunden Ersteinrichtung gegenüber einer manuellen Seitenstruktur.

## Typical use cases reichen vom Studiengang-Verzeichnis bis zur Akkreditierungs-Übersicht

Das Standardszenario ist der zentrale Studiengangfinder auf der Hochschul-Homepage. Studieninteressierte landen auf einer Seite, wählen Fachbereich, Abschluss und Studienform und erhalten sofort eine gefilterte Liste. Ein Klick führt zur Detailseite mit Modulplan, Zulassungsvoraussetzungen, Bewerbungsfristen und Ansprechpartnern. Bei einer Fachhochschule mit 80 Studiengängen reduziert das die Seitenaufrufe bis zur gewünschten Information von durchschnittlich 6 auf 2.

Zweites Szenario: Standort-übergreifende Suche bei Hochschulen mit mehreren Campi. Eine Universität mit Standorten in drei Städten zeigt alle Studiengänge in einer Ansicht und lässt nach Campus filtern. Die Standort-Information wird als eigene Relation gepflegt, nicht als Freitext, was konsistente Filterung garantiert.

Drittes Szenario: Akkreditierungs-Übersichten für die Qualitätssicherung. Hochschulen müssen nachweisen, welche Studiengänge akkreditiert sind und bis wann. in2studyfinder kann diese Meta-Daten als Custom Fields abbilden und in der Listenansicht darstellen, was die Akkreditierungsabteilung als Arbeitsgrundlage nutzt. Ein Export der Studiengang-Daten als CSV oder PDF ermöglicht zusätzlich die Weitergabe an den Akkreditierungsrat oder andere externe Stellen.

## Technical architecture relies on Extbase-Records mit konfigurierbaren Relationen

in2studyfinder ist eine Extbase/Fluid-Extension von in2code, dem TYPO3-Dienstleister hinter powermail und in2publish. Studiengänge werden als Domain-Records in einer eigenen Tabelle gespeichert. Jeder Record enthält Pflichtfelder wie Titel, Abschlussart, Regelstudienzeit, ECTS-Punkte und Fachbereich sowie optionale Felder für NC-Wert, Studiengebühren, Akkreditierungsstatus und Bewerbungslink.

Die Filterung im Frontend arbeitet über AJAX-Requests, sodass die Seite beim Filtern nicht neu geladen wird. Das verbessert die User Experience erheblich, besonders auf mobilen Geräten. Die Filter-Konfiguration ist über TypoScript steuerbar: Welche Felder als Filter angezeigt werden, welche Sortierung greift und wie viele Ergebnisse pro Seite erscheinen.

Templates sind Fluid-basiert und über Site-Packages überschreibbar. Die Extension liefert Standard-Templates mit, die für die meisten Hochschulen als Startpunkt funktionieren. Für Hochschulen mit eigenem Corporate Design passen wir die Templates an und integrieren sie ins bestehende Site-Package, sodass Studiengang-Seiten visuell nahtlos in den Webauftritt passen.

## Common problems involve Datenqualität, Performance und Mehrsprachigkeit

Das grösste Problem bei der Einführung ist die Datenqualität. Studiengang-Informationen existieren an Hochschulen oft in drei bis fünf verschiedenen Systemen: HIS/HISinOne, eigene Datenbanken der Fachbereiche, PDF-Broschüren und handgepflegte Website-Texte. Bevor in2studyfinder produktiv gehen kann, müssen diese Quellen konsolidiert werden. Gosign unterstützt diesen Prozess mit einem strukturierten Import-Template, das die Fachabteilungen ausfüllen und das wir automatisiert in TYPO3 importieren.

Zweites Problem: Performance bei grossen Datenmengen. Hochschulen mit über 200 Studiengängen und komplexen Relationen (Fachbereich, Standort, Studienform, Sprache) können bei der AJAX-Filterung Latenzen erleben, wenn die Datenbankabfragen nicht optimiert sind. Indizes auf den Relationen und ein sauber konfiguriertes Caching im TypoScript lösen das Problem in der Regel vollständig. Zusätzlich hilft ein Warm-Up des Caches nach jeder Datenänderung, damit der erste Besucher nach einem Update keine langsame Seite sieht.

Drittes Problem: Mehrsprachigkeit. Internationale Hochschulen mit englischsprachigen Studiengängen brauchen eine durchgängige Übersetzung der Filtermasken, Kategorien und Detailseiten. in2studyfinder nutzt das TYPO3-Übersetzungsframework, aber die Konfiguration der Fallback-Sprachen und der Übersetzungs-Overlays muss sorgfältig auf die Hochschul-Anforderungen abgestimmt werden. Besonders bei Studiengängen, die nur in einer Sprache angeboten werden (z.B. ein deutschsprachiger Bachelor, aber ein englischsprachiger Master), muss das Fallback-Verhalten so konfiguriert sein, dass die Filterung sprachspezifisch arbeitet und keine irreführenden Ergebnisse liefert.

Ein viertes Problem, das Gosign in Hochschul-Projekten regelmässig sieht: Studiengang-Bezeichnungen, die sich über die Jahre ändern. Ein "Diplom-Informatik" wird zum "B.Sc. Informatik", behält aber die gleiche Detail-URL. Die Extension muss so konfiguriert sein, dass Namensänderungen keine Broken Links erzeugen und alte URLs per Redirect auf die aktuelle Seite weiterleiten.

## TYPO3 v12 wird unterstützt, v13-Kompatibilität hängt vom in2code-Releaseplan ab

in2code pflegt in2studyfinder aktiv und liefert regelmässig Updates. Die aktuelle Version unterstützt TYPO3 v11 und v12. Da in2code ein kommerzieller TYPO3-Dienstleister mit langfristiger Produktstrategie ist, ist die v13-Kompatibilität zu erwarten, aber noch nicht offiziell freigegeben. Beim Upgrade von v10 oder v11 auf v12 betreffen Breaking Changes vor allem die TypoScript-Konfiguration (neue SiteSet-Syntax) und eventuelle Custom ViewHelpers in den Templates. Die Datenbankstruktur bleibt stabil, sodass eine Datenmigration in der Regel nicht nötig ist.

--- in2template TYPO3 - Template Management | Gosign ---
> TYPO3 template management extension by in2code. Simplifies the management of Fluid templates and site packages. Structured template organization.

## in2template brings structure to sitepackages before they become a maintenance nightmare

Anyone building a sitepackage for a large TYPO3 website faces the same question every time: how do I organise templates, partials, layouts and content elements so that they are still maintainable two years from now? The in2template extension from in2code is an attempt to give a structured answer to this question. It delivers a skeleton for modern sitepackages: a clear directory structure, pre-defined content elements, prepared configuration for TypoScript, fluid styled content and backend layouts. For TYPO3 teams that regularly start new projects, in2template replaces the old copy-paste practice from the last customer project with a documented pattern.

The audience are agencies with multiple parallel TYPO3 projects and in-house teams that maintain corporate templates for group or university sites. Especially where developers and editors share the sitepackage, a consistent folder and naming convention is vital. in2template addresses exactly this gap.

## Typical use cases

A first scenario is a clean project start. An agency with eight developers and three running TYPO3 projects introduces in2template as an internal standard for sitepackages. Every new project starts from the same skeleton: identical directory structure, identical naming conventions, identical TypoScript base. The result: a developer can switch between projects without having to reorient themselves every time.

A second scenario is the modernisation of an old sitepackage. A university portal with 800 pages and a template folder that has grown since TYPO3 v7 is restructured as part of an upgrade from v11 to v12. Instead of carrying the old wild growth forward, the team rebuilds the sitepackage on the basis of in2template and migrates the content step by step.

A third scenario is the onboarding of new editors. A publishing house with 30 editors uses the in2template skeleton to explain which content elements are meant for what. The consistency in naming and structure shortens the training, and the error rate in the backend drops.

A fourth scenario is the internal refactoring template. A company with five TYPO3 installations from different years wants to bring its sitepackages into a unified structure over time. in2template serves as a reference skeleton against which every legacy project is rebuilt step by step, without the team having to discuss a new target structure every time.

## Technical architecture

in2template is not a classic add-on but rather a template for your own sitepackage. The extension ships a directory structure: Resources/Private/Templates, Resources/Private/Partials, Resources/Private/Layouts, Configuration/TypoScript, Configuration/TsConfig, Configuration/TCA/Overrides. The skeleton is complemented by prepared content elements (text, text with image, accordion, teaser grid) and a configuration for backend layouts.

Installation is a classic Composer download of the package, which is then copied into the project's sitepackage repository and renamed. In practice, teams rarely use in2template as a direct dependency; typically there is an initial clone that then grows project-specific. That makes the extension a starter kit rather than a framework that would have to be updated across versions.

For integration with fluid styled content there are dedicated override mechanisms that ensure that the shipped content elements coexist with the core elements. TypoScript paths are namespaced throughout, so that several sitepackages can run in parallel on the same installation.

## Common problems and solutions

The first problem is the confusion with a framework. Teams that embed in2template like Bootstrap or Tailwind and wait for updates experience a disappointment: the extension is a template to copy, not an upstream stack. The solution is to treat in2template as a one-time template and to clearly version the resulting sitepackage.

The second problem is overloading with unused content elements. The starter kit ships more elements than most projects need. Anyone who does not use them still carries them through maintenance. The solution is a cleanup directly after the initial import: delete unused content elements, remove unused backend layouts, strike out unused TypoScript blocks.

The third problem is adaptation to individual design systems. in2template delivers Tailwind-adjacent CSS with its own utility classes. Anyone using an existing design system with their own token names has to translate the shipped styles consistently, otherwise style duplication and a contradictory cascade emerge.

A fourth problem are conflicts with other starter kits. Anyone who partially adopts in2template and in parallel integrates building blocks from another skeleton ends up with contradictory TypoScript paths and overlapping Fluid namespaces. The solution is to decide at the start of the project on exactly one skeleton and to keep inconsistent additional components in a clearly named project-specific layer.

## Migration and version compatibility

in2template is maintained by in2code for TYPO3 v11 and v12, and TYPO3 v13 compatibility is updated along with the TYPO3 release cycles. Because the extension is almost always cloned and adapted in projects, the version question is less one of update paths and more one of code discipline: teams should take a look at the current in2template repository on every sitepackage upgrade, to adopt structural improvements (new backend layout conventions, new Fluid patterns).

Important on the upgrade of an in2template-based sitepackage is an eye on changed TYPO3 conventions: TCA overrides, backend layout definitions, content element registration and Fluid rendering have moved several times between v11 and v13. Anyone who does not catch up on these changes in their own sitepackage risks content suddenly appearing empty in the backend or content element wizards no longer appearing.

In TYPO3 projects, Gosign takes on the analysis of which parts of an existing sitepackage can be cleaned up along an in2template-like pattern and which are better migrated to a custom, minimalist skeleton. The result is a sitepackage that passes code reviews without grumbling and produces no surprises on the next TYPO3 upgrade.

--- Social Share Buttons TYPO3 | Gosign ---
> Social share buttons extension for TYPO3. Gosign recommends lightweight custom share links instead - no extension overhead, GDPR-compliant.

## Social Share Buttons als Extension include in den meisten TYPO3-Projekten überflüssig

Die Idee ist simpel: Besucher sollen Inhalte mit einem Klick auf LinkedIn, X oder Facebook teilen können. insign_share_buttons liefert genau das als TYPO3-Extension - Buttons für verschiedene Netzwerke, konfigurierbar im Backend. Doch die Realität zeigt: Für ein Feature, das im Kern aus fünf HTML-Links besteht, ist eine vollständige Extension mit eigener Konfiguration, TypoScript-Setup und Update-Pflicht in den meisten Fällen Overhead. Gosign empfiehlt stattdessen native Share-Links, die in 15 Minuten implementiert sind und keine Abhängigkeit erzeugen.

Das gilt besonders seit der GDPR: Viele Social-Share-Extensions laden im Hintergrund JavaScript von den Netzwerken nach, was ohne Consent-Abfrage datenschutzwidrig ist. Reine URL-basierte Share-Links umgehen dieses Problem vollständig, weil sie erst beim Klick eine Verbindung zum jeweiligen Netzwerk aufbauen. data protection officer prüfen Share-Buttons regelmässig bei Website-Audits, und eine Extension, die ungefragt externe Scripte lädt, fällt dabei als Befund auf.

## Typical use cases beschränken sich auf redaktionell gepflegte Inhalte

Das Standardszenario ist die Unternehmenswebsite mit Blog oder Magazin. Redakteure wollen unter jedem Artikel Buttons für LinkedIn, X, Facebook und E-Mail anzeigen. insign_share_buttons ermöglicht das über ein Content-Element, das in die Seitenvorlage eingebaut wird. Die Extension liest Titel und URL der aktuellen Seite aus und generiert daraus die Share-URLs.

Ein zweites Szenario betrifft Intranet-Portale, in denen Mitarbeitende interne News über Teams oder Slack teilen sollen. Hier ist die Extension tatsächlich nützlicher als bei öffentlichen Websites, weil die GDPR-Problematik innerhalb eines Unternehmens anders bewertet wird und die Konfiguration der Share-Ziele über das Backend gepflegt werden kann.

Drittes Szenario: Websites mit Employer-Branding-Fokus, auf denen Stellenausschreibungen über Social Media verbreitet werden sollen. Die Share-Buttons werden gezielt auf Karriereseiten eingesetzt, damit Mitarbeitende offene Stellen in ihrem Netzwerk teilen können. Die Conversion-Rate dieser Buttons liegt nach Erfahrungswerten bei 0,5 bis 2% der Seitenbesucher. Bei LinkedIn sind die Klickraten auf geteilte Stellenausschreibungen dabei doppelt so hoch wie bei allgemeinen Unternehmens-News, was dieses Szenario zum effektivsten Einsatzfall für Social Share Buttons macht.

## Technical architecture ist ein simples Content-Element mit TypoScript-Konfiguration

insign_share_buttons registriert ein Content-Element in TYPO3, das über die Seitenvorlage oder als Plugin eingefügt wird. Die Konfiguration definiert, welche Netzwerke angezeigt werden, ob Icons oder Text-Labels verwendet werden und ob Zähler eingeblendet werden sollen. Das Rendering erfolgt über Fluid-Templates, die im Site-Package überschreibbar sind.

Die Share-URLs werden serverseitig generiert und folgen dem Standard-Schema der jeweiligen Netzwerke: `https://www.linkedin.com/sharing/share-offsite/?url=` plus die encodierte Seiten-URL für LinkedIn, `https://twitter.com/intent/tweet?url=` für X. Meta-Daten wie Titel und Beschreibung werden aus den Seiteneigenschaften oder den OpenGraph-Tags ausgelesen.

Die Extension hat keine nennenswerten Abhängigkeiten ausser dem TYPO3-Core. Es gibt kein JavaScript-Laden von externen Domains, solange die Zähler-Funktion deaktiviert bleibt. Wird die Zähler-Funktion aktiviert, werden API-Calls zu den Netzwerken ausgelöst, was wiederum eine Consent-Abfrage erfordert.

Ein technisches Detail, das oft übersehen wird: Die Share-URL muss URL-encodiert sein, damit Sonderzeichen in Seitentiteln (Umlaute, kaufmännisches Und, Anführungszeichen) korrekt an die Netzwerke übergeben werden. Die Extension kümmert sich um dieses Encoding automatisch, was bei manuellen Share-Links ein häufiger Fehler ist.

## Common problems include GDPR-Verstösse, fehlende OpenGraph-Tags und Styling-Konflikte

Problem eins: Datenschutz. Viele Installationen haben die Zähler-Funktion aktiv, die ohne Cookie-Consent personenbezogene Daten an US-Server überträgt. Die Lösung: Zähler deaktivieren und ausschliesslich URL-basierte Share-Links verwenden, die erst beim Klick eine Verbindung aufbauen. Noch besser: Die Extension komplett durch native Share-Links ersetzen, die als Fluid-Partial im Site-Package liegen.

Problem zwei: Fehlende oder falsche OpenGraph-Tags. Wenn die TYPO3-Seite keine og:title und og:description meta-Tags liefert, zeigen LinkedIn und Facebook beim Teilen eine leere Vorschau oder ziehen sich zufällige Textfragmente. Die Lösung ist nicht in der Share-Extension, sondern in der SEO-Konfiguration der Seite: OpenGraph-Tags müssen in der Seitenvorlage korrekt gesetzt sein.

Problem drei: Styling-Konflikte zwischen den mitgelieferten CSS-Styles der Extension und dem Corporate Design. Die Extension bringt eigene Stylesheets mit, die mit bestehenden Button-Styles kollidieren können. Die saubere Lösung: Das Extension-CSS deaktivieren und die Buttons über das eigene Site-Package-Stylesheet stylen.

Ein weiteres Problem, das oft erst spät auffällt: fehlende WhatsApp-Share-Unterstützung. Auf Mobilgeräten ist WhatsApp der meistgenutzte Share-Kanal, aber nicht jede Extension unterstützt den WhatsApp-Share-Link nativ. Die manuelle Ergänzung ist trivial (https://api.whatsapp.com/send?text={url}), muss aber explizit eingebaut werden.

## Die Extension works unter TYPO3 v12, ein Neubau ist aber wirtschaftlicher

insign_share_buttons ist mit TYPO3 v12 kompatibel. Für TYPO3 v13 hängt die Verfügbarkeit vom Maintainer ab. Gosign empfiehlt bei einer Migration auf v12 oder v13, die Extension durch ein einfaches Fluid-Partial zu ersetzen. Fünf Zeilen HTML pro Netzwerk, keine Extension-Abhängigkeit, keine Update-Pflicht, volle GDPR compliance. Der Aufwand für diese Umstellung liegt bei ein bis zwei Stunden inklusive Styling und Testing aller Netzwerk-Links. Bei Gosign setzen wir diesen Ansatz standardmässig in allen neuen TYPO3-Projekten ein und pflegen ein Partial-Template-Set für LinkedIn, X, Facebook, WhatsApp und E-Mail, das in jedes Sitepackage integrierbar ist.

--- Inxmail TYPO3 - Enterprise Newsletter | Gosign ---
> Inxmail Professional is an enterprise newsletter system from Germany. TYPO3 integration: subscriber sync, template synchronization, transactional emails.

## Inxmail ist die Enterprise-Newsletter-Plattform, die TYPO3-Redaktionen nativ anbindet

Unternehmen mit mehr als 50.000 Newsletter-Empfängern, strengen Compliance-Anforderungen und einem bestehenden TYPO3-Webauftritt stehen vor einer konkreten Entscheidung: Mailchimp mit US-Datenverarbeitung und GDPR-Risiko oder eine deutsche Lösung, die sich direkt in die bestehende Content-Infrastruktur integriert. Inxmail Professional ist diese Lösung. Server in Deutschland, zertifizierte Datenverarbeitung, und eine TYPO3-Extension, die Subscriber-Listen, Templates und Kampagnen direkt aus dem CMS heraus steuert.

Die TYPO3-Extension synchronisiert Anmeldungen bidirektional: Neue Subscriber aus TYPO3-Formularen landen automatisch in Inxmail-Listen, Abmeldungen in Inxmail werden zurück nach TYPO3 gespiegelt. Für Marketing-Teams bedeutet das: Eine Datenquelle, keine manuellen Exporte, kein Risiko veralteter Listen. In der Praxis eliminiert das den häufigsten Fehler bei Newsletter-Versand: den Versand an eine veraltete Empfängerliste, die bereits abgemeldete Kontakte enthält.

## Typical use cases decken B2B-Newsletter, Transaktionsmails und Event-Kommunikation ab

Das Hauptszenario ist der klassische B2B-Newsletter für Unternehmen mit 10.000 bis 500.000 Empfängern. Die Redaktion pflegt Inhalte in TYPO3, die Extension überträgt Teaser und Links automatisch in Inxmail-Templates. Marketing-Verantwortliche segmentieren die Empfänger nach Branche, Region oder Interesse und versenden zielgruppenspezifische Varianten. Öffnungsraten und Klickdaten fliessen über die API zurück ins TYPO3-Backend, sodass die Redaktion die Performance einzelner Beiträge sehen kann.

Zweites Szenario: Transaktionsmails, die durch Nutzeraktionen auf der Website ausgelöst werden. Eine Registrierungsbestätigung, ein Download-Link oder eine Bestellbestätigung wird nicht über den lokalen Mailserver verschickt, sondern über die Inxmail-Infrastruktur mit garantierter Zustellrate. SPF, DKIM und DMARC sind in Inxmail vorkonfiguriert, was die Zustellbarkeit gegenüber einem Standard-PHP-Mailer deutlich verbessert.

Drittes Szenario: Event-Kommunikation für Unternehmen, die regelmässig Messen, Webinare oder Konferenzen veranstalten. Die Einladung, Reminder und Follow-up-Mails werden als Trigger-basierte Kampagnen in Inxmail konfiguriert und durch Events in TYPO3 ausgelöst, etwa durch eine Anmeldung über ein powermail-Formular. Die Trigger-Logik erlaubt auch komplexere Sequenzen: Einladung vier Wochen vorher, Erinnerung eine Woche vorher, Teilnahmebestätigung am Vortag und Feedback-Anfrage zwei Tage danach.

## Technical architecture connects TYPO3-Frontend-Formulare mit der Inxmail-REST-API

Die Extension nutzt die Inxmail REST-API für die Kommunikation zwischen TYPO3 und Inxmail Professional. Im Kern besteht die Integration aus drei Modulen: einem Subscriber-Sync-Service, einem Template-Sync-Modul und einem Kampagnen-Trigger.

Der Subscriber-Sync läuft über einen Scheduler-Task, der in konfigurierbaren Intervallen (typisch: alle 5 bis 15 Minuten) neue Anmeldungen, Änderungen und Abmeldungen zwischen TYPO3 und Inxmail abgleicht. Die Sync-Richtung ist konfigurierbar: unidirektional (TYPO3 zu Inxmail) oder bidirektional. Bei bidirektionalem Sync werden Konflikte über Timestamps gelöst, wobei der neuere Datensatz gewinnt.

Das Template-Sync-Modul überträgt TYPO3-Seitenbereiche als Newsletter-Inhalte. Redakteure markieren Content-Elemente im TYPO3-Backend als "Newsletter-fähig", und die Extension rendert diese Elemente in ein Inxmail-kompatibles HTML-Template. Das erspart die doppelte Pflege von Website-Content und Newsletter-Content.

Die Authentifizierung erfolgt über API-Keys, die im TYPO3-Extension-Manager konfiguriert werden. Alle API-Calls laufen über HTTPS, und die Extension loggt jeden Sync-Vorgang in eine dedizierte Log-Tabelle, was für Compliance-Audits relevant ist. Die Log-Daten enthalten Zeitstempel, Anzahl synchronisierter Records, Fehler und Warnungen, sodass bei einem Audit nachgewiesen werden kann, wann welche Daten übertragen wurden.

## Common problems involve Sync-Konflikte, Template-Rendering und API-Rate-Limits

Das dominierende Supportthema ist der Sync-Konflikt bei bidirektionaler Synchronisation. Wenn ein Subscriber sowohl in TYPO3 als auch in Inxmail gleichzeitig geändert wird, kann es zu Dateninkonsistenzen kommen. Die Lösung: Klare Sync-Richtung definieren. In 90% der Fälle ist TYPO3 die führende Quelle für Stammdaten, Inxmail die führende Quelle für Engagement-Daten (Öffnungen, Klicks, Bounces).

Zweites Problem: HTML-Rendering-Unterschiede zwischen TYPO3-Frontend und E-Mail-Client. Ein Content-Element, das auf der Website korrekt dargestellt wird, kann in Outlook oder Gmail anders aussehen. Die Extension übersetzt zwar TYPO3-HTML in Inline-CSS für E-Mail-Kompatibilität, aber komplexe Layouts mit Flexbox oder Grid müssen für E-Mail-Clients vereinfacht werden. Wir empfehlen, Newsletter-Templates separat zu testen, idealerweise mit einem Tool wie Litmus oder Email on Acid.

Drittes Problem: API-Rate-Limits bei grossen Sync-Vorgängen. Wer 100.000 Subscriber auf einmal synchronisiert, kann das API-Limit von Inxmail erreichen. Die Lösung: Batch-basierter Sync mit konfigurierbarer Paketgrösse (empfohlen: 500 Records pro API-Call) und exponentielles Backoff bei Rate-Limit-Responses.

## TYPO3 v12 wird über die offizielle Extension unterstützt, v13 requires Prüfung

Inxmail pflegt die TYPO3-Extension aktiv, da der TYPO3-Markt ein relevanter Vertriebskanal für Inxmail Professional ist. Die aktuelle Version unterstützt TYPO3 v11 und v12. Beim Upgrade von v10 auf v12 müssen vor allem die Scheduler-Task-Konfigurationen angepasst werden, da TYPO3 v12 die Scheduler-API geändert hat. Die API-Authentifizierung und der Subscriber-Sync bleiben stabil.

Für TYPO3 v13 liegt noch kein offizielles Release vor. Unternehmen, die ein v13-Upgrade planen, sollten die Verfügbarkeit frühzeitig mit Inxmail abstimmen, da Enterprise-Newsletter-Integrationen zu den kritischsten Abhängigkeiten bei einem CMS-Upgrade gehören. Als Zwischenlösung kann die Integration über einen Custom Middleware-Layer realisiert werden, der die Inxmail-API direkt anspricht, ohne die Extension zu verwenden. Gosign hat diese Lösung für Kunden umgesetzt, die auf v13 migrieren wollten, bevor die offizielle Extension verfügbar war. Der Custom-Layer ist zudem wartungsärmer, weil er nur die tatsächlich genutzten API-Endpoints anspricht und keine ungenutzten Features mitschleppt.

--- iSpider TYPO3 - Web Crawler | Gosign ---
> Web crawler/spider for TYPO3: crawl internal pages, find broken links, generate sitemaps. QA tool for quality assurance and SEO analysis.

## Broken Links kosten Rankings und Vertrauen, aber kaum jemand prüft sie regelmässig

Jede TYPO3-Website mit mehr als 200 Seiten hat Broken Links. Redakteure löschen Seiten, verschieben Inhalte oder ändern URL-Slugs, ohne alle internen Verlinkungen zu prüfen. Das Ergebnis: 404-Fehler, die Google als Qualitätssignal wertet und die Besucher frustrieren. iSpider ist ein interner Web-Crawler für TYPO3, der das eigene Frontend crawlt, Broken Links identifiziert und eine Sitemap generiert. Das Werkzeug schliesst die Lücke zwischen manueller Prüfung und externen SEO-Tools, die keinen Zugriff auf geschützte Bereiche haben.

Für Redaktionen und technische Projektleiter ist iSpider ein QA-Instrument, das ohne externe Abhängigkeiten auskommt. Der Crawler läuft im TYPO3-Backend, kennt die Seitenstruktur und kann auch passwortgeschützte Bereiche prüfen, die externe Tools wie Screaming Frog nicht erreichen. Die Ergebnisse sind direkt im TYPO3-Backend verfügbar, was die Korrektur von Broken Links durch Redakteure beschleunigt, weil sie nicht zwischen verschiedenen Tools wechseln müssen.

## Typical use cases range from Pre-Launch-Checks bis zum laufenden Monitoring

Das häufigste Szenario ist der Pre-Launch-Check vor einem Relaunch oder TYPO3-Upgrade. Bevor eine neue Version live geht, crawlt iSpider die Staging-Umgebung und liefert eine vollständige Liste aller Broken Links, fehlenden Bilder und Redirect-Ketten. Ein typischer Relaunch einer mittelgrossen Website (500 bis 1.000 Seiten) produziert erfahrungsgemäss 30 bis 80 Broken Links, die ohne systematischen Crawl unentdeckt in Produktion gehen würden.

Zweites Szenario: Laufendes Monitoring im Redaktionsalltag. Ein wöchentlicher Scheduler-Task crawlt die Website und sendet einen Report an die Redaktion mit allen neuen 404-Fehlern seit dem letzten Durchlauf. So werden Probleme innerhalb von Tagen statt Monaten erkannt und behoben.

Drittes Szenario: SEO-Analyse für interne Verlinkungsstruktur. iSpider zeigt, welche Seiten keine eingehenden internen Links haben (verwaiste Seiten) und welche Seiten besonders viele eingehende Links besitzen. Diese Daten helfen bei der Content-Strategie und der internen Link-Optimierung. Eine typische Analyse deckt auf, dass 10 bis 15% aller Seiten verwaist sind und von Google folglich selten oder nie gecrawlt werden.

## Technical architecture works als Backend-Modul mit Scheduler-Integration

iSpider registriert sich als Backend-Modul in TYPO3 und nutzt den TYPO3-Scheduler für automatisierte Crawl-Durchläufe. Der Crawler startet von einer konfigurierbaren Einstiegsseite (typischerweise die Root-Page) und folgt allen internen Links rekursiv bis zu einer einstellbaren Tiefe. Externe Links werden auf Erreichbarkeit geprüft, aber nicht weiterverfolgt.

Die Ergebnisse werden in einer eigenen Datenbanktabelle gespeichert: URL, HTTP-Statuscode, Antwortzeit, referenzierende Seite und Zeitstempel. Das Backend-Modul zeigt die Ergebnisse als filterbare Liste mit Sortierung nach Statuscode, was die Priorisierung von Fixes erleichtert.

Die Crawl-Geschwindigkeit ist über die Konfiguration steuerbar: Gleichzeitige Requests, Wartezeit zwischen Requests und maximale Crawl-Tiefe. Für grosse Installationen mit über 5.000 Seiten empfiehlt sich ein nächtlicher Crawl über den Scheduler, um die Server-Last tagsüber nicht zu beeinträchtigen. Die Ergebnisse bleiben in der Datenbank gespeichert und sind über das Backend-Modul jederzeit abrufbar, auch zwischen den Crawl-Durchläufen. Das erlaubt einen historischen Vergleich der Broken-Link-Entwicklung über Wochen und Monate.

## Common problems include Server-Timeouts, unvollständige Crawls und false Positives

Das häufigste Problem: Der Crawl bricht bei grossen Websites ab, weil das PHP-Memory-Limit oder die max_execution_time erreicht wird. Die Lösung: Den Crawl über den Scheduler in Batches aufteilen und die PHP-Limits für den CLI-Kontext erhöhen (empfohlen: memory_limit 512M, max_execution_time 0 für CLI).

Zweites Problem: Unvollständige Crawls bei JavaScript-gerenderten Inhalten. iSpider ist ein serverseitiger Crawler, der kein JavaScript ausführt. Single-Page-Applications oder Inhalte, die erst per AJAX nachgeladen werden, erfasst der Crawler nicht. Die Lösung: Für JavaScript-lastige Bereiche einen externen Crawler wie Screaming Frog ergänzend einsetzen.

Drittes Problem: False Positives bei externen Links. Manche Websites blockieren Crawler per User-Agent-Erkennung und liefern einen 403-Statuscode, obwohl die URL für Browser erreichbar ist. iSpider meldet das als Fehler. Die Lösung: Eine Ausnahmeliste für bekannte False Positives konfigurieren und den User-Agent-String auf einen Browser-typischen Wert setzen. LinkedIn, Facebook und einige CDN-geschützte Websites sind typische Kandidaten für False Positives.

Ein weiteres Problem: Redirect-Ketten. iSpider folgt Redirects (301, 302), meldet aber nicht, wie viele Hops nötig waren. Dreifach- oder Vierfach-Redirects sind ein SEO-Problem, das ohne detaillierte Redirect-Analyse unsichtbar bleibt. Externe Crawler wie Screaming Frog zeigen die vollständige Redirect-Kette inklusive Zwischenstationen, was iSpider nicht leistet.

## iSpider ist ein Legacy-Tool, externe Crawler-Alternativen include leistungsfähiger

iSpider wurde für TYPO3 v7 und v8 entwickelt und hat keine offizielle Unterstützung für v12 oder v13. Wer auf aktuelle TYPO3-Versionen migriert, sollte externe Alternativen evaluieren. Screaming Frog (Desktop-Tool, bis 500 URLs kostenlos), Sitebulb oder der integrierte TYPO3-Linkvalidator decken die Kernfunktionen ab. Gosign nutzt in eigenen Projekten eine Kombination aus dem TYPO3-Core-Linkvalidator für interne Prüfungen und automatisierten Screaming-Frog-Crawls für umfassende SEO-Analysen. Bei einer Migration von iSpider prüfen wir, welche Konfigurationen und Reports im bestehenden Setup kritisch sind, und bilden diese in der neuen Lösung ab.

--- iubenda TYPO3 - Privacy | Gosign ---
> iubenda provides cookie consent banners and automatically generated privacy policies. TYPO3 integration embeds both. Alternative to dp_cookieconsent.

## Cookie-Consent und Privacy Policy aus einer Hand klingt praktisch, hat aber Abhängigkeiten

Seit der GDPR und dem TTDSG braucht jede Website ein Cookie-Consent-Banner und eine aktuelle privacy policy. iubenda bietet beides als SaaS-Lösung: Ein JavaScript-Widget für das Consent-Banner und einen Generator für Datenschutz- und Cookie-Richtlinien, die sich automatisch aktualisieren, wenn sich Gesetze ändern. Die TYPO3-Extension bettet beides in den Seitenquellcode ein. Für Unternehmen, die weder einen data protection officer noch eine Kanzlei mit der laufenden Pflege beauftragen wollen, ist iubenda eine pragmatische Lösung.

Der Trade-off ist klar: Komfort gegen Abhängigkeit. Das Consent-Banner und die Privacy Policy werden von iubenda-Servern geladen. Fällt der Service aus oder ändert sich die API, ist die Website betroffen. Alternativen wie dp_cookieconsent oder Usercentrics arbeiten nach dem gleichen Prinzip, aber mit unterschiedlichen Schwerpunkten in Konfigurierbarkeit und Preis.

## Typical use cases involve KMU-Websites, Portale und internationale Auftritte

Das Standardszenario ist die mittelständische Unternehmenswebsite mit 20 bis 100 Seiten, die Google Analytics, ein Kontaktformular und eingebettete YouTube-Videos nutzt. iubenda scannt die Website, erkennt die verwendeten Services automatisch und generiert eine passende Cookie-Richtlinie. Das Consent-Banner blockiert die erkannten Cookies, bis der Besucher einwilligt. Der Einrichtungsaufwand für dieses Szenario liegt bei ein bis zwei Stunden.

Zweites Szenario: Mehrsprachige Portale, die in verschiedenen Rechtsräumen operieren. iubenda unterstützt neben der GDPR auch das kalifornische CCPA und das brasilianische LGPD. Die privacy policy wird automatisch in der Sprache des Besuchers angezeigt und enthält die relevanten Rechtsgrundlagen für den jeweiligen Standort. Für Unternehmen mit Zielgruppen in Europa, den USA und Südamerika spart das die separate Erstellung von drei bis vier verschiedenen Policies.

Drittes Szenario: Websites mit häufig wechselnden Third-Party-Einbindungen. Wenn Marketing-Abteilungen regelmässig neue Tracking-Pixel, Chat-Widgets oder Social-Media-Embeds einbauen, aktualisiert iubenda die Cookie-Richtlinie automatisch beim nächsten Website-Scan. Das reduziert das Risiko, dass neue Dienste ohne Consent-Abfrage laufen. In der Praxis ist das besonders relevant für Unternehmen, die Marketing-Automation-Tools nutzen und monatlich neue A/B-Tests, Heatmap-Tracker oder Conversion-Pixel einbauen, ohne die IT-Abteilung zu informieren.

## Technical architecture embeds ein externes JavaScript-Widget in TYPO3 ein

Die TYPO3-Extension integriert iubenda über zwei Code-Snippets: Ein JavaScript-Tag für das Consent-Banner und einen Embed-Code für die Privacy Policy. Beide Snippets werden im TYPO3-Extension-Manager konfiguriert und automatisch im HTML-Header bzw. auf der Datenschutzseite ausgegeben. Die Extension selbst ist minimal und enthält kaum eigene Logik.

Das Consent-Banner arbeitet nach dem TCF-2.0-Standard (Transparency and Consent Framework) und blockiert Cookies über eine Proxy-Technik: Externe Scripts werden erst geladen, wenn der Besucher eingewilligt hat. Die Blockierung funktioniert über das Umschreiben von Script-Tags (type="text/plain" statt type="text/javascript") und das Nachladen per JavaScript nach Consent.

Die automatische Policy-Generierung basiert auf einem Website-Scanner, der die Domain crawlt und verwendete Dienste erkennt. Die generierten Texte sind rechtlich geprüft und werden von iubendas Anwaltsteam bei Gesetzesänderungen aktualisiert. Die Policy wird entweder als iFrame oder als direkter HTML-Embed auf der Datenschutzseite eingebunden.

## Common problems include Script-Blocking-Fehler, Performance-Einbussen und Content-Shift

Das häufigste Problem: Nicht alle Third-Party-Scripts werden korrekt blockiert. Wenn ein Script nicht über ein Standard-HTML-Tag, sondern dynamisch per JavaScript nachgeladen wird, erkennt die Proxy-Technik es möglicherweise nicht. Die Lösung: Manuelle Überprüfung aller eingebundenen Dienste und explizite Konfiguration im iubenda-Dashboard. Ein Browser-Plugin wie "CookieMetrix" hilft bei der Verifizierung.

Zweites Problem: Performance-Einbussen durch das zusätzliche JavaScript. Das iubenda-Widget ist 40 bis 80 KB gross (komprimiert) und wird von externen Servern geladen. Das kann den Largest Contentful Paint um 200 bis 400ms verschlechtern. Die Lösung: Das Widget asynchron laden und sicherstellen, dass es nicht render-blockierend ist.

Drittes Problem: Content Layout Shift durch das nachträglich eingeblendete Banner. Wenn das Banner über dem Seiteninhalt erscheint, verschiebt es den sichtbaren Bereich. Google misst das als Cumulative Layout Shift (CLS) und wertet es negativ. Die Lösung: Das Banner als Overlay (nicht als eingeschobenes Element) konfigurieren oder einen festen Platzhalter im CSS reservieren. Ein CLS-Wert unter 0,1 ist das Ziel, und ein schlecht konfiguriertes Consent-Banner kann diesen Wert allein auf 0,3 oder höher treiben.

Zusätzlich berichten manche Administratoren, dass das iubenda-Dashboard in der Konfiguration komplex ist. Die Unterscheidung zwischen "Cookie Solution" (Consent-Banner), "Privacy Controls and Cookie Solution" (erweitert) und "Consent Database" (für Compliance-Dokumentation) erfordert ein Verständnis der eigenen rechtlichen Anforderungen, das viele Webmaster nicht mitbringen. Gosign konfiguriert iubenda im Rahmen von TYPO3-Projekten gemeinsam mit dem data protection officer des Kunden, damit die technische Konfiguration zur rechtlichen Bewertung passt.

## iubenda works TYPO3-versionsunabhängig, weil die Integration minimal ist

Da die Extension im Kern nur zwei JavaScript-Snippets einbindet, gibt es keine tiefe TYPO3-API-Abhängigkeit. Die Integration funktioniert mit TYPO3 v10, v11, v12 und voraussichtlich auch v13 ohne Anpassungen. Beim Upgrade muss lediglich geprüft werden, ob die Snippet-Einbindung im HTML-Header noch korrekt greift, was in der Regel der Fall ist. Gosign empfiehlt dennoch, bei jedem TYPO3-Upgrade einen Cookie-Consent-Test durchzuführen, um sicherzustellen, dass alle Blocking-Regeln noch funktionieren.

--- j77 Template TYPO3 | Gosign ---
> Template package for TYPO3. Ready-made layout as a starting point. Gosign recommends custom site packages instead of ready-made templates for professional.

## Fertige TYPO3-Templates beschleunigen den Start, bremsen aber die Weiterentwicklung

j77_template ist ein vorkonfiguriertes Template-Paket für TYPO3, das ein fertiges Layout als Startpunkt liefert. Header, Footer, Navigation, Content-Bereiche und grundlegende Styling-Definitionen sind enthalten. Für Agenturen, die schnell einen TYPO3-Prototyp aufsetzen wollen, oder für interne IT-Abteilungen ohne Frontend-Entwickler ist das verlockend: Installation, Aktivierung, fertig. Die Realität zeigt allerdings, dass fertige Templates in professionellen Projekten nach 3 bis 6 Monaten mehr Arbeit verursachen als sie einsparen.

Der Grund: Jedes Template-Paket bringt eine eigene HTML-Struktur, CSS-Klassen und TypoScript-Konfiguration mit. Sobald das Design vom Standard abweichen soll, kämpft man gegen die Template-Logik statt mit ihr. Ein Custom Sitepackage, das von Anfang an auf die Anforderungen zugeschnitten ist, kostet initial mehr, spart aber bei jeder späteren Änderung Zeit.

## Typical use cases include Prototypen, interne Portale und Vereinswebsites

Das häufigste Szenario ist der Schnellstart für Prototypen und Proof-of-Concepts. Eine Agentur will einem Kunden innerhalb von zwei Tagen zeigen, wie sein Content in TYPO3 aussehen könnte. j77_template liefert ein vorzeigbares Layout ohne Frontend-Entwicklung. Der Prototyp wird nach der Freigabe durch ein massgeschneidertes Sitepackage ersetzt.

Zweites Szenario: Interne Portale und Intranet-Anwendungen, bei denen das Design sekundär ist. Eine IT-Abteilung baut ein internes Wissensportal auf TYPO3 und braucht eine funktionale Oberfläche, kein Corporate Design. j77_template liefert Navigation, Breadcrumb und Content-Rendering out of the box.

Drittes Szenario: Vereinswebsites und kleine Non-Profit-Auftritte mit begrenztem Budget. Wenn das gesamte Webprojekt unter 5.000 Euro liegen muss, kann ein fertiges Template-Paket die Frontend-Entwicklungskosten eliminieren und das Budget für Content und Funktionalität freihalten. In der Praxis betrifft das Sportvereine, Musikschulen, Freiwilligeninitiativen und Elternvereine, die eine schlichte, funktionale Website brauchen und keine besonderen Design-Anforderungen haben.

## Technical architecture ist ein Standard-Sitepackage mit vorkonfiguriertem TypoScript

j77_template ist technisch ein TYPO3-Sitepackage, das über den Extension-Manager installiert wird. Es bringt Fluid-Templates für Page-Layouts, Partial-Templates für Header, Footer und Navigation sowie TypoScript-Konfigurationen für Content-Rendering mit. Die CSS-Dateien basieren auf Bootstrap oder einer vergleichbaren Framework-Basis.

Die Template-Struktur folgt dem TYPO3-Standard: Resources/Private/Templates für Page-Layouts, Resources/Private/Partials für wiederverwendbare Bereiche und Resources/Private/Layouts für Fluid-Rahmen-Templates. Die TypoScript-Konfiguration setzt die Template-Pfade, konfiguriert das Content-Rendering über FLUIDTEMPLATE und definiert die Navigationsstruktur.

Anpassungen sind möglich, indem die Template-Pfade per TypoScript auf eigene Dateien umgelenkt werden. Das funktioniert für einzelne Templates, führt aber bei umfangreichen Änderungen dazu, dass man de facto ein paralleles Sitepackage pflegt, was den Vorteil des fertigen Templates zunichtemacht.

Ein typisches Problem bei Template-Paketen ist die Bootstrap-Abhängigkeit. j77_template setzt auf eine bestimmte Bootstrap-Version. Wenn das Projekt eine andere CSS-Framework-Version benötigt oder komplett auf Tailwind oder eigenes CSS umsteigen will, kollidiert das mit dem Template-Setup. Die mitgelieferten CSS-Dateien sind nicht modular aufgebaut, sondern als monolithischer Bundle ausgeliefert, der sich nur schwer partiell überschreiben lässt.

## Common problems include Upgrade-Konflikte, CSS-Overrides und fehlende Dokumentation

Problem eins: Upgrade-Konflikte beim TYPO3-Update. Template-Pakete sind eng an eine TYPO3-Version gebunden. Wenn ein Upgrade Breaking Changes in Fluid oder TypoScript einführt, muss das Template-Paket aktualisiert werden. Wenn der Maintainer das nicht rechtzeitig tut, blockiert das Template das gesamte TYPO3-Upgrade. Bei eigenen Sitepackages hat man diese Kontrolle selbst.

Problem zwei: CSS-Overrides, die sich gegenseitig überschreiben. Das Template bringt eigene Styles mit, das Corporate Design erfordert Abweichungen, und zusätzliche Extensions haben ebenfalls CSS. Das Ergebnis ist eine Kaskade von Overrides, die bei jeder Änderung unvorhersehbare Seiteneffekte produziert. Die Lösung ist ein dediziertes Stylesheet, das die Template-Styles komplett überschreibt, was aber den Zweck des Templates untergraebt.

Problem drei: Fehlende oder veraltete Dokumentation. Community-Templates wie j77_template werden oft von Einzelpersonen gepflegt und haben keine professionelle Dokumentation. Welche TypoScript-Konstanten verfügbar sind, welche Fluid-Variablen in den Templates existieren und wie das Responsive-Verhalten konfiguriert wird, muss man durch Code-Analyse herausfinden. Ohne Dokumentation ist jeder Entwicklerwechsel ein Risiko, weil das Projekt-Wissen an eine Person gebunden ist, die das Template durchanalysiert hat.

## Für v12 und v13 empfiehlt Gosign den Wechsel auf ein eigenes Sitepackage

j77_template hat keine garantierte Unterstützung für TYPO3 v12 oder v13. Bei einer Migration ist der ideale Zeitpunkt, das Template-Paket durch ein eigenes Sitepackage zu ersetzen. Die Kosten für ein eigenes Sitepackage amortisieren sich bereits beim ersten grösseren Design-Change, der mit einem fremden Template stunden- oder tagelange Override-Arbeit bedeuten würde.

Gosign erstellt Sitepackages, die exakt auf das Corporate Design und die funktionalen Anforderungen des Projekts zugeschnitten sind. Der initiale Aufwand für ein einfaches Sitepackage liegt bei 2 bis 5 Arbeitstagen, abhängig von der Komplexität des Designs. KI-gestützte Template-Generierung beschleunigt den Prozess: Aus einem Design-Mockup generiert unser Tooling die Fluid-Templates, TypoScript-Konfiguration und CSS-Grundstruktur, die Senior-Entwickler dann finalisieren. Ein Sitepackage, das Gosign ausliefert, enthält neben den Templates auch eine Dokumentation der verfügbaren Content-Elemente, TypoScript-Konstanten und Page-Layouts, damit auch Entwickler, die das Projekt übernehmen, sofort produktiv arbeiten können.

--- jumpurl TYPO3 - Download Tracking | Gosign ---
> jumpurl: legacy download tracking in TYPO3. Migration to modern tracking solutions. AI-accelerated.

## jumpurl ist seit TYPO3 v9 aus dem Core entfernt und sollte nicht mehr eingesetzt werden

jumpurl war jahrelang fester Bestandteil des TYPO3-Cores und tat eine simple Sache: Downloads und externe Links über eine Redirect-URL leiten, um Klicks zählbar zu machen. Ein PDF-Download ging nicht direkt an den Browser, sondern über eine jumpurl-Adresse, die den Klick in der Datenbank protokollierte und dann zum eigentlichen Download weiterleitete. In der Hochzeit der Extension nutzten geschätzt 40% aller TYPO3-Installationen jumpurl für Download-Tracking. Seit TYPO3 v9 ist jumpurl nicht mehr im Core enthalten. Als eigenständige Extension existiert sie zwar weiter, aber die Architektur ist veraltet und moderne Alternativen sind in jeder Hinsicht überlegen.

Wer jumpurl noch im Einsatz hat, arbeitet mit einer Technik aus der TYPO3-v4-Ära. Die Extension erzeugt kryptische URLs mit Hash-Parametern, die weder menschenlesbar noch SEO-freundlich sind. Das Tracking basiert auf Datenbank-Einträgen, die kein modernes Analytics-Tool nativ auswerten kann. Für ein Feature, das heute jedes Standard-Analytics-Setup über Events abbildet, ist eine eigene Extension mit Datenbank-Overhead nicht mehr zeitgemäss.

## Typical use cases waren Download-Tracking und Link-Monitoring

Das Hauptszenario war und ist Download-Tracking: Wie oft wurde das Whitepaper heruntergeladen, wie oft die Preisliste, wie oft der Produktkatalog? jumpurl protokolliert jeden Klick in einer Datenbanktabelle mit Zeitstempel, IP-Adresse und Referrer. Unternehmen mit 50 bis 200 Downloads pro Tag nutzen diese Daten für Content-Strategie und Lead-Qualifizierung.

Zweites Szenario: Tracking externer Links. Wenn eine Unternehmenswebsite auf Partner, Lieferanten oder Ressourcen verlinkt, zeigt jumpurl, welche externen Ziele die meisten Klicks erhalten. Das ist relevant für Affiliate-Programme, Partner-Reporting und die Analyse des Nutzerverhaltens.

Drittes Szenario: Secure Downloads mit Zugriffskontrolle. jumpurl kann Downloads an eine Benutzeranmeldung koppeln, sodass nur eingeloggte Nutzer Dateien herunterladen können. Das Token-System stellt sicher, dass direkte URLs zu geschützten Dateien nicht funktionieren. Für Unternehmen, die Whitepapers, technische Dokumentationen oder Preislisten nur nach Login bereitstellen wollen, war das in der TYPO3-v6- und v7-Ära die Standardlösung.

## Technical architecture is based on URL-Rewriting und Datenbank-Logging

jumpurl registriert einen eID-Handler im TYPO3-Core, der eingehende Requests mit einem jumpurl-Parameter abfängt. Der Parameter enthält einen Hash, der auf die Ziel-URL oder den Dateipfad verweist. Der Handler loggt den Zugriff in eine Datenbanktabelle (tx_jumpurl_tracking), validiert den Hash und leitet den Browser per 302-Redirect an das eigentliche Ziel weiter.

Die Konfiguration erfolgt über TypoScript-Konstanten: Welche Dateitypen getrackt werden (typisch: PDF, DOCX, XLSX, ZIP), ob externe Links erfasst werden und ob das Tracking aktiviert ist. Die Extension modifiziert automatisch die generierten Links im Frontend, sodass Redakteure nichts manuell anpassen müssen. Die Integration ist transparent: Redakteure verlinken Dateien wie gewohnt, und jumpurl schiebt die Tracking-Ebene automatisch dazwischen.

Das Tracking-Log enthält: Zeitstempel, IP-Adresse (GDPR-relevant), Ziel-URL, HTTP-Referrer und User-Agent. Für die Auswertung gibt es ein minimales Backend-Modul, das Klickzahlen pro URL anzeigt. Komplexere Analysen erfordern direkten Datenbankzugriff oder einen Export.

## Common problems involve SEO, GDPR und Kompatibilität mit URL-Rewriting

Problem eins: SEO-Schaden durch Redirect-Ketten. jumpurl-URLs sind keine echten Seiten-URLs, sondern Redirect-Intermediäre. Wenn Google einen jumpurl-Link indexiert (was bei falscher Konfiguration passiert), entsteht eine Redirect-Kette, die Crawl-Budget verschwendet und Link-Juice verdünnt. Die Lösung: Sicherstellen, dass jumpurl-URLs ein noindex-Tag oder ein robots-Disallow haben.

Problem zwei: GDPR compliance. jumpurl speichert IP-Adressen im Klartext. Ohne Pseudonymisierung oder Löschkonzept ist das ein Verstoss gegen die GDPR. Die Datenbanktabelle muss regelmässig bereinigt oder die IP-Adressen vor dem Speichern anonymisiert werden.

Problem drei: Kompatibilität mit modernem URL-Routing. TYPO3 v12 nutzt Site-Handling und Symfony-basiertes Routing. Die eID-basierte jumpurl-Architektur kollidiert in manchen Konfigurationen mit dem neuen Routing und produziert 404-Fehler. Die Lösung ist die Migration auf eine moderne Alternative. Zusätzlich stören die kryptischen jumpurl-Parameter in der Browser-Adresszeile die User Experience: Nutzer sehen eine URL mit Hash-Werten statt eines lesbaren Dateipfads, was Misstrauen erzeugen kann.

## Migration auf eventbasiertes Tracking ist bei jedem TYPO3-Upgrade der empfohlene Weg

jumpurl hat keine offizielle Unterstützung für TYPO3 v12 oder v13. Bei einer Migration empfiehlt Gosign den Wechsel auf eventbasiertes Download-Tracking. Konkret bedeutet das: Ein data-Attribut auf Download-Links (z.B. data-track="download") und ein JavaScript-Event-Listener, der Klicks an Matomo, Google Analytics 4 oder ein Custom-Endpoint sendet. Für Secure Downloads ist die Kombination aus FAL-basiertem Dateizugriff und einem Token-System die moderne Alternative.

Der Migrationsaufwand hängt von der Menge der bestehenden jumpurl-Links ab. Wenn externe Quellen (Newsletter, Social Media, Print) auf jumpurl-URLs verweisen, müssen Redirects eingerichtet werden. Gosign analysiert die bestehenden jumpurl-Tracking-Daten, identifiziert die meistgenutzten Downloads und konfiguriert die neue Tracking-Lösung so, dass historische Vergleichbarkeit gewährleistet bleibt. Typischerweise sind 80% der bestehenden jumpurl-Links interne Verlinkungen, die automatisiert umgeschrieben werden können. Die verbleibenden 20% sind externe Referenzen, für die permanente 301-Redirects eingerichtet werden müssen, damit kein Link-Juice verloren geht.

--- k3n_dvemoji TYPO3 - Emoji & UTF-8mb4 | Gosign ---
> k3n_dvemoji: UTF-8mb4 emoji support in TYPO3. Character set migration & database configuration. AI-accelerated.

## Emojis als Fragezeichen include kein Darstellungsproblem, sondern ein Datenbank-Konfigurationsfehler

Wenn in einem TYPO3-Backend ein Redakteur ein Emoji eingibt und im Frontend stattdessen ein Fragezeichen oder ein leeres Kästchen erscheint, liegt das Problem nicht im Browser und nicht in TYPO3. Es liegt in der MySQL- oder MariaDB-Datenbank, die mit dem Zeichensatz utf8 statt utf8mb4 konfiguriert ist. Der Unterschied: utf8 speichert maximal 3 Bytes pro Zeichen, Emojis brauchen 4 Bytes. k3n_dvemoji ist eine TYPO3-Extension, die dieses Problem adressiert, indem sie die Datenbank-Konfiguration um UTF-8mb4-Support erweitert. Seit TYPO3 v10 ist der Core allerdings selbst auf utf8mb4 vorbereitet, sodass die Extension nur noch bei älteren oder falsch konfigurierten Installationen nötig ist.

Für TYPO3-Administratoren und Agenturen, die ältere Installationen betreuen, ist k3n_dvemoji ein Diagnosewerkzeug und ein Fix zugleich. Die Extension identifiziert Tabellen mit falschem Zeichensatz und konvertiert sie, was manuell ein fehleranfälliger Prozess ist.

## Typical use cases involve ältere Installationen, Migrationen und internationale Inhalte

Das häufigste Szenario ist eine TYPO3-v8- oder v9-Installation, die seit Jahren läuft und deren Datenbank noch auf utf8 (nicht utf8mb4) konfiguriert ist. Schätzungsweise 30% aller TYPO3-Installationen, die vor 2018 eingerichtet wurden, haben dieses Problem, weil die Installationsroutine damals utf8 als Standard setzte. Solange Redakteure nur lateinische Zeichen verwenden, fällt das nicht auf. Sobald ein Social-Media-Post mit Emoji auf der Website eingebettet wird oder ein Redakteur ein Emoji in eine Überschrift setzt, bricht die Darstellung. k3n_dvemoji konvertiert die betroffenen Tabellen und Spalten auf utf8mb4.

Zweites Szenario: Datenbank-Migrationen zwischen Servern. Beim Umzug einer TYPO3-Datenbank von einem alten Server auf einen neuen kann der Zeichensatz durch einen fehlerhaften mysqldump-Befehl verloren gehen. Ein Dump mit --default-character-set=utf8 statt utf8mb4 schneidet alle 4-Byte-Zeichen ab. k3n_dvemoji hilft bei der nachträglichen Reparatur.

Drittes Szenario: Internationale Websites mit asiatischen Sprachen. Chinesische, japanische und koreanische Schriftzeichen benötigen teilweise 4 Bytes. Ohne utf8mb4 werden einzelne Zeichen verstümmelt dargestellt, was bei CJK-Content-Seiten zu unlesbarem Text führt. Auch mathematische Symbole, Musiknoten und diverse Sonderzeichen aus dem Unicode-Bereich oberhalb von U+FFFF sind betroffen, was für Hochschul-Websites und wissenschaftliche Portale relevant ist.

## Technical architecture analyzes und konvertiert Datenbank-Tabellen auf Spaltenebene

k3n_dvemoji arbeitet auf zwei Ebenen: Analyse und Konvertierung. Im Analyse-Modus scannt die Extension alle TYPO3-Tabellen und prüft den Zeichensatz jeder Spalte. Das Ergebnis ist ein Report, der zeigt, welche Tabellen und Spalten noch auf utf8 (3 Byte) statt utf8mb4 (4 Byte) stehen. Ein typisches TYPO3-System hat 100 bis 300 Tabellen, von denen oft 20 bis 50 einen falschen Zeichensatz aufweisen.

Im Konvertierungs-Modus generiert die Extension ALTER TABLE Statements für jede betroffene Spalte und führt sie aus. Das klingt trivial, hat aber Fallstricke: Indizes auf varchar-Spalten mit utf8mb4 können die maximale Index-Länge von MySQL überschreiten (767 Bytes bei InnoDB mit antique format). Die Extension prüft diese Limits und passt die Index-Definitionen an.

Zusätzlich muss die TYPO3-Konfiguration in LocalConfiguration.php den Zeichensatz utf8mb4 deklarieren: `['DB']['Connections']['Default']['charset'] = 'utf8mb4'` und `['DB']['Connections']['Default']['tableoptions']['collate'] = 'utf8mb4_unicode_ci'`. Ohne diese Konfiguration nutzt TYPO3 weiterhin utf8 für neue Tabellen.

## Common problems include Index-Längenbeschränkungen, Backup-Fehler und inkonsistente Spalten

Problem eins: MySQL-Index-Längenbeschränkung. Bei InnoDB mit dem alten Compact-Format (Standard bis MySQL 5.6) ist die maximale Index-Länge 767 Bytes. Ein varchar(255) mit utf8mb4 braucht 1.020 Bytes Index-Platz. Die Konvertierung scheitert mit "Specified key was too long". Die Lösung: ROW_FORMAT auf DYNAMIC umstellen (Standard ab MySQL 5.7) oder die varchar-Länge in den betroffenen Spalten reduzieren.

Problem zwei: Backup vor der Konvertierung. Ein ALTER TABLE auf grossen Tabellen (100.000+ Zeilen) sperrt die Tabelle und kann bei Produktionsdatenbanken zu Ausfällen führen. Die Lösung: Konvertierung ausserhalb der Geschäftszeiten durchführen und vorher ein vollständiges Backup erstellen. Bei grossen Tabellen empfiehlt sich pt-online-schema-change von Percona für eine lockfreie Konvertierung.

Problem drei: Inkonsistente Spalten nach teilweiser Konvertierung. Wenn nur Teile der Datenbank konvertiert wurden, können JOINs zwischen utf8- und utf8mb4-Spalten zu Performance-Problemen führen, weil MySQL eine implizite Zeichensatz-Konvertierung durchführt. Gosign prüft nach jeder Konvertierung alle Tabellen auf Konsistenz.

## Ab TYPO3 v10 ist die Extension überflüssig, wenn die Datenbank korrekt konfiguriert ist

TYPO3 v10 und alle folgenden Versionen erwarten utf8mb4 als Standard-Zeichensatz. Bei einer Neuinstallation mit v10 oder höher wird die Datenbank automatisch korrekt konfiguriert, und k3n_dvemoji ist nicht nötig. Die Extension bleibt relevant für Installationen, die von v7, v8 oder v9 auf v12 oder v13 migriert werden und deren Datenbank noch nie konvertiert wurde. Gosign löst das im Rahmen jeder TYPO3-Migration automatisch mit: KI-gestützter Datenbank-Scan, vollständige Konvertierung und Konsistenz-Check als Teil des Standard-Upgrade-Prozesses. Der Scan analysiert alle Tabellen und Spalten in unter 5 Minuten, generiert die nötigen ALTER TABLE Statements und führt sie in einer Transaktion aus, sodass bei einem Fehler der vorherige Zustand wiederhergestellt werden kann. Das Ergebnis ist eine Datenbank, die utf8mb4 durchgängig unterstützt, ohne dass eine Extension im Betrieb nötig ist.

--- ke_search Premium TYPO3 - Search | Gosign ---
> Premium version of ke_search: autocomplete, file indexing (PDF, DOCX), custom indexer. Enterprise search without Solr server, all in the TYPO3 database.

## Enterprise-Suche ohne Solr-Server ist mit ke_search Premium in TYPO3 möglich

Die interne Suche einer Website ist das Feature, das am meisten genutzt und am wenigsten gepflegt wird. Besucher erwarten Autocomplete, Tippfehler-Toleranz und die Fähigkeit, nicht nur Seiten, sondern auch PDFs und Office-Dokumente zu durchsuchen. ke_search Premium liefert genau das für TYPO3, ohne dass ein externer Solr- oder Elasticsearch-Server betrieben werden muss. Alle Daten liegen in der TYPO3-Datenbank, der Index wird über den Scheduler aktualisiert, und die Administration bleibt im TYPO3-Backend.

Für mittelgrosse Websites mit 500 bis 5.000 Seiten und einer Handvoll Datei-Downloads ist ke_search Premium die wirtschaftlichste Suchlösung im TYPO3-Ökosystem. Erst ab 10.000+ indexierten Dokumenten oder bei Sub-Sekunden-Anforderungen an die Antwortzeit wird Solr zur besseren Wahl.

## Typical use cases range from Unternehmenswebsites bis zu Wissensportalen

Das Standardszenario ist die Unternehmenswebsite mit Produktkatalog, Magazin, FAQ und Download-Bereich. Besucher suchen nach Produktnamen, Fachbegriffen oder Dokumenten und erwarten Ergebnisse aus allen Bereichen in einer einzigen Trefferliste. ke_search Premium indexiert Seiteninhalte, News-Artikel, Downloads (PDF, DOCX, XLSX) und Custom-Records wie Produkte oder Mitarbeiterprofile. Die Autocomplete-Funktion zeigt bereits beim Tippen Vorschläge an und reduziert die Suchabbruchrate um geschätzte 15 bis 25%.

Zweites Szenario: Wissensportale und Dokumentensammlungen. Hochschulen, Verbände und öffentliche Einrichtungen stellen oft hunderte PDFs zum Download bereit: Forschungsberichte, Satzungen, Formulare, Protokolle. Ohne Datei-Indexierung durchsucht die TYPO3-Suche nur die Seitentexte, nicht den Inhalt der PDFs. ke_search Premium extrahiert den Text aus PDF, DOCX und weiteren Formaten und macht ihn durchsuchbar.

Drittes Szenario: Custom Indexer für Drittsysteme. Unternehmen mit einem PIM, einem DAM oder einem externen Produktkatalog können über die Custom-Indexer-API beliebige Datenquellen in den Suchindex einbinden. Ein Indexer-Job holt Daten per API, transformiert sie in ke_search-Records und speichert sie im Index. Das ist besonders relevant für E-Commerce-Szenarien, in denen Produktdaten nicht in TYPO3 liegen.

## Technical architecture uses die TYPO3-Datenbank als Suchindex

ke_search speichert den Index in einer dedizierten Tabelle (tx_kesearch_index) in der TYPO3-Datenbank. Jeder Index-Eintrag enthält Titel, Inhalt, Tags, Typ und Sortierungsinformationen. Die Indexierung läuft über Scheduler-Tasks, die in konfigurierbaren Intervallen (typisch: nächtlich) den Content neu indexieren. Die Premium-Version erweitert den Basis-Indexer um Datei-Indexierung, Autocomplete und Custom Indexer.

Die Datei-Indexierung nutzt Apache Tika oder pdftotext für die Text-Extraktion aus PDFs und catdoc für Office-Dokumente. Diese Tools müssen auf dem Server installiert sein, was auf Shared-Hosting-Umgebungen ein Problem sein kann. Auf dedizierten Servern und in Docker-Containern ist die Installation trivial.

Die Suchanfrage im Frontend arbeitet über eine LIKE-basierte Datenbanksuche mit optionalem Fulltext-Index. Bei kleineren Datenmengen ist die Performance ausreichend, bei grösseren Indexen (5.000+ Einträge) empfiehlt sich ein MySQL-Fulltext-Index auf den relevanten Spalten, um die Suchzeit unter 200ms zu halten.

Autocomplete wird über einen AJAX-Endpoint realisiert, der bei jedem Tastendruck eine PREFIX-Suche auf dem Index durchführt. Die Ergebnisse werden als JSON geliefert und im Frontend per JavaScript als Dropdown angezeigt. Die Konfiguration erlaubt, die Mindest-Zeichenanzahl (empfohlen: 3) und die maximale Anzahl der Vorschläge (empfohlen: 8) einzustellen.

## Common problems involve Indexierungszeit, fehlende Tika-Installation und Relevanz-Sortierung

Problem eins: Lange Indexierungszeiten bei grossen Datenmengen. Eine Website mit 3.000 Seiten und 500 PDFs kann 30 bis 60 Minuten für eine vollständige Neuindexierung benötigen. Die Lösung: Inkrementelle Indexierung aktivieren, die nur geänderte Inhalte neu indexiert. Bei ke_search Premium ist das über den Scheduler konfigurierbar.

Problem zwei: Fehlende Tika- oder pdftotext-Installation. Ohne diese Tools schlägt die Datei-Indexierung still fehl, ohne Fehlermeldung. Redakteure laden PDFs hoch, die nie im Suchindex landen. Die Lösung: Nach der Installation einen Test-Indexierungslauf starten und prüfen, ob PDF-Inhalte im Index erscheinen. Ein einfacher CLI-Befehl prüft die Verfügbarkeit: `which pdftotext` oder `java -jar tika-app.jar --version`.

Problem drei: Relevanz-Sortierung. Die Standard-Sortierung basiert auf einem einfachen Scoring-Algorithmus, der Treffer in Titeln höher gewichtet als Treffer im Body. Für komplexe Anforderungen (Boosting nach Aktualität, nach Seitentyp oder nach Custom-Feldern) muss das Scoring per TypoScript angepasst werden. Die Premium-Version bietet mehr Scoring-Parameter als die kostenlose Basisversion.

## TYPO3 v12 wird vollständig unterstützt, v13-Kompatibilität ist in Arbeit

ke_search wird von einem dedizierten Entwicklerteam gepflegt und ist bei jedem TYPO3-LTS-Release zeitnah kompatibel. Die aktuelle Premium-Version unterstützt TYPO3 v11 und v12. Für v13 ist die Kompatibilität in Entwicklung. Beim Upgrade von älteren TYPO3-Versionen betreffen Breaking Changes vor allem die TypoScript-Konfiguration der Indexer und die Scheduler-Task-Registrierung. Der Suchindex selbst muss nach einem Upgrade komplett neu aufgebaut werden, was je nach Datenmenge eine Stunde oder mehr dauern kann.

Gosign setzt ke_search Premium in TYPO3-Projekten ein, die eine interne Suche brauchen, aber den Betrieb eines Solr-Servers nicht rechtfertigen. Für die meisten mittelgrossen Websites mit unter 5.000 indexierten Dokumenten ist ke_search Premium die wirtschaftlich sinnvollste Lösung. Erst wenn Anforderungen wie Facettierung, Fuzzy-Matching oder Sub-Sekunden-Antwortzeiten bei grossen Datenmengen dazukommen, empfehlen wir den Umstieg auf Apache Solr mit der TYPO3-Solr-Extension.

--- Classifieds TYPO3 - Classified Ads | Gosign ---
> Classifieds functionality for TYPO3: place ads, categories, search, user self-service. Community feature for portals and associations.

## Kleinanzeigen auf der eigenen Website include eine Alternative zu Marktplatz-Plattformen

Vereine, regionale Portale und Community-Websites brauchen manchmal eine Kleinanzeigen-Funktion: Mitglieder stellen Gebrauchtwaren ein, Nachbarn bieten Dienstleistungen an, Organisationen vermitteln Sachspenden. Die kleinanzeigen-Extension bringt diese Funktionalität direkt in TYPO3, ohne auf externe Plattformen wie eBay Kleinanzeigen (jetzt Kleinanzeigen) auszuweichen. Nutzer erstellen Anzeigen im Frontend, andere Nutzer finden sie über Kategorien und Suche, und die Redaktion behält die Kontrolle über Freigabe und Moderation.

Der Anwendungsfall ist eng begrenzt: Wer eine vollwertige Marktplatz-Plattform mit Bezahlfunktion, Bewertungssystem und Käuferschutz braucht, ist mit einer spezialisierten Lösung besser bedient. Für Community-Portale mit 50 bis 500 aktiven Anzeigen gleichzeitig ist die Extension aber ein solides Werkzeug, das die Nutzer auf der eigenen Plattform hält.

## Typical use cases include Vereinsportale, regionale Plattformen und interne Börsen

Das häufigste Szenario ist das Vereinsportal. Ein Sportverein, eine Kirchengemeinde oder eine Bürgerinitiative bietet Mitgliedern die Möglichkeit, Gebrauchtes zu verkaufen, zu verschenken oder zu tauschen. Die Kleinanzeigen-Funktion ist ein Community-Feature, das Besucher regelmässig auf die Website zurückbringt. Die Kategorien sind überschaubar: Sport-Ausrüstung, Kleidung, Möbel, Diverses.

Zweites Szenario: Regionale Plattformen und Stadtportale. Eine Gemeinde-Website oder ein lokales Nachrichtenportal bietet einen Kleinanzeigenbereich für die Region an. Bürger inserieren Mietwohnungen, Babysitter-Angebote oder Handwerkerleistungen. Die Moderation liegt bei der Redaktion, die Anzeigen vor der Veröffentlichung freigibt.

Drittes Szenario: Interne Börsen in Unternehmen oder Hochschulen. Im Intranet bieten Mitarbeitende Büromöbel, Fahrräder oder Wohnungen zur Zwischenmiete an. Die Kleinanzeigen-Extension läuft auf der internen TYPO3-Instanz und ist nur für angemeldete Nutzer sichtbar. Hochschulen nutzen das Feature auch für Bücherbörsen, in denen Studierende Fachliteratur untereinander verkaufen oder tauschen.

## Technical architecture relies on Extbase-Records mit Frontend-Eingabe

Die Extension nutzt das Extbase/Fluid-Framework von TYPO3. Anzeigen werden als eigene Domain-Records in einer dedizierten Tabelle gespeichert. Jeder Record enthält Titel, Beschreibung, Preis (optional), Kategorie, Kontaktdaten und Bilder. Die Kategorisierung läuft über TYPO3-Sys-Categories oder ein eigenes Kategoriefeld.

Im Frontend stehen drei Plugins zur Verfügung: eine Listenansicht mit Filter und Suche, eine Detailansicht für einzelne Anzeigen und ein Eingabeformular für neue Anzeigen. Das Eingabeformular erfordert eine Frontend-Benutzeranmeldung (fe_users), sodass nur registrierte Nutzer Anzeigen erstellen können. Bilder werden über FAL (File Abstraction Layer) hochgeladen und serverseitig auf Grösse und Dateityp validiert.

Die Moderation erfolgt über ein Freigabe-Flag im Backend: Neue Anzeigen sind standardmässig unsichtbar, bis ein Redakteur sie freischaltet. Alternativ lässt sich die automatische Freigabe aktivieren, was für vertrauenswürdige Communities sinnvoll sein kann.

Die Suche arbeitet über eine einfache LIKE-basierte Datenbankabfrage auf Titel und Beschreibung. Für Portale mit mehr als 500 aktiven Anzeigen empfiehlt sich eine Erweiterung um ke_search oder einen eigenen Suchindex, um die Suchperformance und Relevanz zu verbessern. Die Sortierung ist nach Datum (neueste zuerst) und nach Preis (aufsteigend oder absteigend) konfigurierbar.

## Common problems include Spam, Bildoptimierung und Ablauf-Management

Problem eins: Spam-Anzeigen. Jedes öffentliche Eingabeformular zieht Spam an. Ohne Schutzmechanismen füllt sich der Anzeigenbestand innerhalb von Wochen mit irrelevanten Einträgen. Die Lösung: Frontend-Login-Pflicht, Honeypot-Felder im Formular, optionales CAPTCHA und eine Freigabe-Moderation. Die Kombination reduziert Spam auf nahe Null.

Problem zwei: Bildoptimierung. Nutzer laden Fotos direkt vom Smartphone hoch, oft mit 4 bis 8 MB pro Bild. Ohne serverseitige Komprimierung und Grössenanpassung wird die Seite langsam und der Speicherplatz knapp. Die Lösung: In der Extension-Konfiguration eine maximale Bildgrösse definieren (empfohlen: 1.200px Breite, 80% JPEG-Qualität) und den Upload per PHP-Konfiguration auf 5 MB begrenzen.

Problem drei: Ablauf-Management. Veraltete Anzeigen, die seit Monaten online stehen, machen den Anzeigenbestand unbrauchbar. Die Lösung: Ein automatisches Ablaufdatum (empfohlen: 30 bis 90 Tage) und eine Erinnerungsmail an den Ersteller, bevor die Anzeige archiviert wird. Das erfordert eine Scheduler-Task-Konfiguration.

Ein weiteres Thema, das regelmässig auftaucht: Kontaktaufnahme zwischen Inserent und Interessent. Die einfachste Lösung zeigt die E-Mail-Adresse des Inserenten auf der Detailseite an. Das funktioniert, aber die E-Mail-Adresse ist dann für Spam-Crawler sichtbar. Die bessere Lösung ist ein Kontaktformular auf der Detailseite, das die Nachricht an den Inserenten weiterleitet, ohne seine E-Mail-Adresse offenzulegen.

## Die Extension hat keine gesicherte Unterstützung für aktuelle TYPO3-Versionen

kleinanzeigen wurde für ältere TYPO3-Versionen entwickelt und hat keine offizielle Unterstützung für v12 oder v13. Bei einer Migration stellt sich die Frage, ob die Extension angepasst oder durch eine massgeschneiderte Lösung ersetzt wird. Für Portale mit aktivem Kleinanzeigenbestand empfiehlt Gosign eine Neuentwicklung auf Basis der aktuellen Extbase-API, die die bestehenden Daten migriert und die Funktionalität an die spezifischen Anforderungen des Portals anpasst. Der Aufwand liegt typischerweise bei 5 bis 10 Arbeitstagen für eine Grundfunktionalität mit Listenansicht, Detailansicht, Frontend-Eingabe und Moderation.

Der Vorteil einer Neuentwicklung gegenüber dem Patchen der alten Extension: Die Datenbank-Struktur kann auf die tatsächlichen Anforderungen optimiert werden, die Frontend-Templates nutzen aktuelle Fluid-Features und das Responsive-Verhalten wird von Anfang an mitgedacht. Gosign migriert bestehende Anzeigen-Daten automatisiert in die neue Struktur, sodass kein aktiver Inhalt verloren geht.

--- Mailchimp Signup TYPO3 | Gosign ---
> Mailchimp signup form for TYPO3. Subscriber sync, double opt-in, audience segments. GDPR: consider US data processing, data processing agreement required.

## Mailchimp-Anmeldeformulare in TYPO3 erfordern GDPR-Absicherung, nicht nur ein Plugin

Newsletter-Anmeldungen gehören zu den wichtigsten Conversion-Zielen auf Unternehmenswebsites. koning_mailchimp_signup verbindet TYPO3-Frontend-Formulare direkt mit der Mailchimp-API: Ein Besucher gibt seine E-Mail-Adresse ein, die Extension überträgt sie an die konfigurierte Mailchimp-Audience, Mailchimp verschickt die Double-Opt-In-Mail. Technisch funktioniert das in 15 Minuten. Die eigentliche Herausforderung liegt nicht in der Technik, sondern in der GDPR: Mailchimp verarbeitet personenbezogene Daten auf US-Servern, was einen data processing agreement (DPA) und einen dokumentierten Transfer-Mechanismus (aktuell: EU-US Data Privacy Framework) voraussetzt.

Für Marketing-Teams, die Mailchimp bereits als Newsletter-Plattform nutzen und ihren TYPO3-Webauftritt anbinden wollen, ist die Extension der kürzeste Weg. Wer noch keine Plattform gewählt hat, sollte allerdings europäische Alternativen wie Brevo, rapidmail oder mailingwork evaluieren.

## Typical use cases include Blog-Newsletter, Lead-Magneten und Event-Registrierungen

Das Standardszenario ist der Blog- oder Magazin-Newsletter. Unter jedem Artikel erscheint ein kompaktes Anmeldeformular mit E-Mail-Feld und Einwilligungs-Checkbox. Die Extension überträgt die Adresse an eine Mailchimp-Audience und tagged den Subscriber mit der Quelle (z.B. "blog-sidebar" oder "article-footer"). Marketing kann so segmentspezifisch versenden.

Zweites Szenario: Lead-Magneten mit automatischem Download. Ein Besucher meldet sich an und erhält automatisch ein Whitepaper, eine Checkliste oder einen Rabattcode per Mailchimp-Welcome-Automation. Die Extension liefert den Subscriber, Mailchimp übernimmt die Automation. Die Conversion-Rate dieses Musters liegt bei B2B-Websites erfahrungsgemäss bei 2 bis 5% der Seitenbesucher.

Drittes Szenario: Event-Registrierungen. Ein Unternehmen lädt zu einem Webinar oder einer Konferenz ein. Die Anmeldung läuft über ein erweitertes Formular mit Name, E-Mail und Firmenname. Die Extension überträgt die Daten an eine dedizierte Mailchimp-Audience, die für Event-Kommunikation (Einladung, Reminder, Follow-up) konfiguriert ist. Nach dem Event kann die Audience für Follow-up-Kampagnen weiterverwendet werden, was den Customer Lifetime Value der Registrierung maximiert.

## Technical architecture connects ein Fluid-Formular mit der Mailchimp-API v3

Die Extension registriert ein Content-Element in TYPO3, das ein Anmeldeformular rendert. Das Formular enthält mindestens ein E-Mail-Feld und eine Einwilligungs-Checkbox. Optionale Felder wie Vorname, Nachname und Firma können über die Backend-Konfiguration aktiviert werden. Die Fluid-Templates sind über ein Site-Package überschreibbar.

Nach dem Absenden sendet die Extension einen POST-Request an die Mailchimp-API v3. Der API-Key und die Audience-ID werden im TYPO3-Extension-Manager konfiguriert. Die Extension unterstützt Tags (zur Segmentierung), Merge Fields (für Custom-Daten) und die Steuerung des Double-Opt-In-Verhaltens (aktiviert oder deaktiviert, wobei die GDPR in Europa Double-Opt-In verlangt).

Fehler-Handling: Wenn die Mailchimp-API einen Fehler zurückgibt (bereits abonniert, ungültige E-Mail, Rate Limit), zeigt die Extension eine konfigurierbare Fehlermeldung im Frontend an. Die Fehler werden zusätzlich ins TYPO3-Log geschrieben, was für die Analyse von Sync-Problemen relevant ist. Die häufigste Fehlermeldung im Produktivbetrieb ist "Member Exists" (Subscriber ist bereits in der Audience), was kein technischer Fehler ist, sondern eine Informationsmeldung, die dem Besucher als "Sie sind bereits angemeldet" angezeigt werden sollte.

## Common problems involve GDPR-Dokumentation, Double-Opt-In und Formularstyling

Problem eins: Fehlende GDPR-Dokumentation. Die Extension überträgt personenbezogene Daten an einen US-Dienstleister. Ohne data processing agreement mit Mailchimp (Intuit), Dokumentation des Transfer-Mechanismus in der privacy policy und Einwilligungs-Checkbox im Formular ist die Integration rechtswidrig. Die Lösung: DPA mit Mailchimp abschliessen (verfügbar im Mailchimp-Account unter Account > Legal), Transfer-Mechanismus in der privacy policy benennen und die Einwilligungs-Checkbox als Pflichtfeld konfigurieren.

Problem zwei: Double-Opt-In-Konfiguration. Mailchimp erlaubt es, Subscriber ohne Bestätigungs-Mail direkt in die Liste aufzunehmen (Single-Opt-In). In Deutschland ist das nach der Rechtsprechung des BGH problematisch. Die Extension muss so konfiguriert sein, dass Mailchimp eine Bestätigungs-Mail verschickt und den Subscriber erst nach Klick auf den Bestätigungslink aktiviert.

Problem drei: Formular-Styling passt nicht zum Corporate Design. Die Extension bringt minimale Standard-Styles mit, die in den wenigsten Projekten zum Design passen. Die Lösung: Das Fluid-Template im Site-Package überschreiben und die CSS-Klassen an das bestehende Design-System anpassen. Der Aufwand liegt bei 1 bis 2 Stunden.

Ein viertes Problem, das speziell bei Multi-Language-Websites auftaucht: Die Einwilligungstexte und Fehlermeldungen der Extension sind nicht für alle Sprachen vorkonfiguriert. Für TYPO3-Projekte mit 5 Sprachversionen müssen die Labels manuell in den XLF-Dateien oder über TypoScript-Overrides übersetzt werden, was bei 10 bis 15 Textbausteinen pro Sprache ein überschaubarer, aber nicht vernachlässigbarer Aufwand ist.

## Die Extension works mit TYPO3 v12, für v13 ist die Mailchimp-API der stabilere Weg

koning_mailchimp_signup unterstützt TYPO3 v11 und v12. Für TYPO3 v13 hängt die Verfügbarkeit vom Community-Maintainer ab. Da die Mailchimp-API v3 stabil ist und sich selten ändert, ist eine direkte API-Integration ohne Extension die wartungsärmere Alternative für v13-Projekte. Gosign implementiert in neuen Projekten bevorzugt einen Custom Finisher für das TYPO3 Form Framework oder für powermail, der die Mailchimp-API direkt anspricht. Das eliminiert die Abhängigkeit von der Extension und gibt volle Kontrolle über Fehler-Handling, Logging und GDPR-Dokumentation.

Der Custom-Finisher-Ansatz hat einen weiteren Vorteil: Er lässt sich mit wenig Aufwand auf andere Newsletter-Plattformen umstellen. Wenn ein Unternehmen von Mailchimp auf Brevo, rapidmail oder mailingwork wechselt, muss nur der API-Client im Finisher ausgetauscht werden, nicht das gesamte Formular-Setup. Diese Flexibilität rechtfertigt den initialen Mehraufwand von 2 bis 4 Stunden gegenüber der Extension-Installation.

--- kuferweb TYPO3 - Kufer Course Management | Gosign ---
> kuferweb: integrate Kufer course management in TYPO3. Course catalog, registration, synchronization. AI-accelerated.

## kuferweb is the bridge between the Kufer back office system and the public TYPO3 website

Adult education centres, training providers and academies have managed their course operations in specialist software for decades, and in many houses that software is called Kufer. Kufer covers the full course lifecycle: lecturer management, course planning, room allocation, participants, billing, certificates. For the website this means a standard task: the course catalogue maintained in the back office should be visible on the TYPO3 website up to date, including filter search, detail views and online registration.

The audience is clearly defined: continuing education institutions with an existing Kufer tenant that run their website on TYPO3. A typical setup is an adult education centre with around 2,500 courses per semester and half a dozen course managers who maintain their courses themselves in Kufer. Without a clean integration, the website catalogue stays outdated, double maintenance becomes the default, and registrations land in a separate system that nobody likes.

## Typical use cases

A first scenario is the automatically updated course catalogue. An adult education centre with 2,500 courses per semester wants every new course, every price change and every lecturer change to appear on the website without manual intervention. An hourly sync job pulls the current course data from Kufer, writes it into a TYPO3 table and updates the search. Editors no longer maintain courses in the TYPO3 backend.

A second scenario is direct online registration. A training provider with funded programmes wants to lead prospects directly from the course detail page into a registration process that calls the Kufer API in the background and registers the participant in Kufer. TYPO3 serves as the frontend, Kufer remains the source of truth, and the editorial team sees the new registration status in its familiar interface.

A third scenario is filter search with subject-specific facets. An academy with 40 subject areas and several thousand courses wants to let prospects search by category, location, date, lecturer and price tier. The search runs on the TYPO3 page against a local index that is built from the Kufer export, fast and independent of the availability of the specialist application.

A fourth scenario is multilingual course output. A language school with locations in Germany, Austria and Switzerland maintains courses in Kufer in German only and wants to offer a multilingual display on the website for prospects. The integration handles the mapping onto TYPO3 language variants, complements the German Kufer fields with manual translations in the CMS editorial process and ensures that changes in Kufer do not overwrite the local translations.

## Technical architecture

kuferweb integrations in TYPO3 are almost always custom developments, because the data structures vary per Kufer tenant and the API versions have changed several times over the years. The standard approach is a lean Extbase extension with three pillars: a service layer that encapsulates the Kufer API, a persistence layer that mirrors courses in TYPO3 tables and a presentation layer that provides Fluid templates for list, filter and detail.

Synchronisation runs through a TYPO3 scheduler task. For large catalogues, a delta import is recommended that only transmits courses changed since the last run. The Kufer API usually delivers a timestamp or change identifier per course that is used for delta detection.

Online registration requires an additional API path and clean error handling. The Kufer API can respond slowly under load, so registrations typically run asynchronously: the form drops the registration request into a queue, a worker process transmits it to Kufer, and the participant receives a confirmation email as soon as Kufer has acknowledged the registration.

## Common problems and solutions

The first problem is field variation between Kufer tenants. What is called "event number" in tenant A is "course code" in tenant B and "booking number" in tenant C. The solution is a configurable field mapping in the TYPO3 extension that is adjusted per installation and does not sit hard-coded in the code.

The second problem is data quality in the course catalogue. Editors do not always maintain complete texts in Kufer: short descriptions are missing, images are not attached, target audiences are not defined. On the website these gaps then appear as empty fields. The solution is a validation layer during synchronisation that flags incomplete courses in the backend and prompts the editorial team to fill them in.

The third problem is cancellation logic. When courses are cancelled in Kufer, they should disappear from the website or at least be marked as cancelled. The solution is to explicitly set cancelled courses to a status in the sync that is hidden in the list, and to attach a redirect on the detail page to a category overview.

A fourth problem is the real-time capacity display. Prospects see "3 seats left" on the website, although the booking has already moved onto the waiting list in the background. The solution is to read the capacity display not from the sync cache but to fire a small live call to Kufer on every detail page access, with aggressive caching (30 to 60 seconds) and a fallback to the last known cache value if the API does not respond.

## Migration and version compatibility

kuferweb integrations run on TYPO3 v11, v12 and v13, provided the API connection is built in a modern way. The most common pain point is not the TYPO3 version but the Kufer version: when the adult education centre migrates its Kufer tenant to a new version, API endpoints and data structures occasionally change, which requires a readjustment of the TYPO3 integration.

Gosign builds kuferweb integrations on the basis of the current Kufer API, checks compatibility with the customer tenant before project start and sets up the integration modularly, so that future API upgrades do not require a large-scale rebuild. With AI support, the API client code emerges in hours rather than days, which makes the rollout realistic in two to three sprints on most projects.

--- LayerSlider TYPO3 - Slider Migration | Gosign ---
> Premium slider/animation plugin for TYPO3. Performance-critical: large JS bundles, many HTTP requests. Gosign migrates to lightweight alternatives.

## LayerSlider loads 400 KB of JavaScript for something solvable with 20 KB of CSS

LayerSlider was one of the most popular premium sliders for TYPO3 and WordPress between 2012 and 2018. Animated banners with parallax effects, text overlays, transitions and video backgrounds. The result looked impressive on the homepage. The problem: LayerSlider loads a JavaScript library of 300 to 400 KB (minified), requires jQuery as a dependency (another 90 KB) and generates 15 to 30 HTTP requests for images, fonts and configuration files. On an otherwise optimized website, LayerSlider doubles the homepage loading time.

Google PageSpeed Insights penalizes this mercilessly. A Largest Contentful Paint (LCP) of over 4 seconds from the slider alone means a score loss of 20 to 40 points. Since Google uses Core Web Vitals as a ranking factor (2021), a poor LCP is a measurable SEO disadvantage.

## Typical use cases

**Existing websites with animated hero banners.** Corporate websites from 2014 to 2019 where the homepage slider shows 3 to 5 animated slides. Typical content: product photos with animated text overlay ("Discover now"), parallax scroll effects, autoplay with fade transition. The slider was set up once and barely modified since, yet causes the full performance overhead on every page load.

**Landing pages with product slideshows.** Marketing teams use LayerSlider for product presentations: multiple images with overlay text and CTA buttons in an auto-advancing slideshow. Conversion data typically shows that 80% of users only see the first slide. The slider is thus an expensive display for a single image.

**Event pages with countdown animations.** LayerSlider can display timers, pop-ups and scroll-triggered animations. For conference pages or product launches, such features were used. Today, lightweight CSS solutions exist for these without JavaScript overhead.

## Technical architecture

LayerSlider is a commercial plugin (license approx. 25 USD one-time for WordPress, TYPO3 variant via CodeCanyon or third-party providers). The TYPO3 integration runs as an extension that creates its own table for slider configurations. Each slider consists of slides, each slide of layers (text, image, video, shape, button), and each layer has animation settings (timing, easing, effect).

The frontend output loads the LayerSlider core library (kreaturamedia.js), jQuery (if not globally available), optional plugins (Parallax, Popup, Timeline) and the slider configuration as JSON. Images are embedded as img tags with data attributes for lazy loading, but many configurations load all images immediately (autoplay starts the second slide after 3 seconds, so slide 2 must already be loaded).

The animation engine uses RequestAnimationFrame and CSS3 transforms for rendering. On modern browsers, the display is smooth, but the parse time for the large JavaScript bundle remains. On mobile devices (mid-range smartphones), parsing alone takes 200 to 500 ms before the first animation starts.

## Common problems and solutions

**Core Web Vitals drop after slider installation.** LCP rises from 1.5 to 4+ seconds because the slider is the largest visible element and can only render after JavaScript parsing. Solution: replace LayerSlider with a static hero using CSS animation. The hero image loads as a normal img tag (immediately in HTML, no JavaScript needed), text overlays are positioned via CSS. Result: LCP under 2 seconds.

**LayerSlider license expires, updates missing.** The TYPO3 variant of LayerSlider is not distributed through the TER and has no automatic update mechanism. Security patches must be applied manually. LayerSlider has had critical security vulnerabilities in the past (CVE-2014-0159 in the WordPress version). Solution: do not patch - migrate.

**Slider content is not indexable.** Text in LayerSlider layers is inserted as data attributes or via JavaScript. Google can read the text (JavaScript rendering), but the association with page context is weak. Image alt texts are often completely missing. Solution: place relevant text and CTAs directly in the page HTML, not in the slider.

## Migration and version compatibility

LayerSlider has no official TYPO3 v12 or v13 compatibility. The last TYPO3-compatible version supports v10, with community patches partially supporting v11. For v12+, there is no upgrade path. This is the trigger for many projects to finally replace the slider.

Gosign migrates LayerSlider to one of three alternatives depending on requirements. Swiper (open source, 40 KB minified, no jQuery, touch-native) for image sliders with simple transitions. Splide (open source, 30 KB minified, no jQuery, full ARIA support) for accessible sliders. Or a pure CSS/HTML hero without a slider library when only a single image with text overlay is needed.

Migration takes 0.5 to 2 days per slider depending on complexity. For a typical website with 1 homepage slider and 3 subpage sliders, the project is completed in one week including responsive adjustments and performance testing.

The measurable effect of a slider migration: a website switching from LayerSlider to a static hero with CSS animation typically improves its Google PageSpeed Score by 15 to 35 points. LCP drops from 3 to 5 seconds to under 2 seconds. Total Blocking Time (TBT) decreases by 200 to 500 ms because the large JavaScript bundle is eliminated. For companies driving traffic to the homepage through Google Ads, this directly translates to better Quality Scores and lower cost per click.

Gosign conducts a performance benchmark before every slider migration: PageSpeed Score, LCP, CLS and TBT are measured before and after. The results document the ROI of the migration and help argue the case to stakeholders who want to keep the familiar slider design.

--- Leaflet TYPO3 - OpenStreetMap Maps | Gosign ---
> Leaflet maps in TYPO3: OpenStreetMap without Google costs. Branch finder, clustering, routing. AI-accelerated.

## OpenStreetMap-Karten über Leaflet ersetzen Google Maps ohne Lizenzkosten und GDPR-Risiko

Google Maps kostet ab 28.000 Kartenaufrufen pro Monat Geld und überträgt Nutzerdaten an US-Server. Für Unternehmen mit Filialfinder, Store Locator oder Standortkarte auf der Website sind das zwei Probleme auf einmal: Budget und Datenschutz. Leaflet löst beides. Die Open-Source JavaScript-Bibliothek rendert interaktive Karten auf Basis von OpenStreetMap-Daten, läuft komplett clientseitig und hat keine Lizenzkosten. Die TYPO3-Extension integriert Leaflet als Content-Element: Redakteure pflegen Standorte im Backend, die Extension generiert die Karte im Frontend.

Für Unternehmen mit 5 bis 500 Standorten ist Leaflet die Standardempfehlung. Erst wenn Google-spezifische Features wie Street View, 3D-Gebäude oder Live-Verkehrsdaten benötigt werden, ist Google Maps die bessere Wahl. In allen anderen Fällen liefert Leaflet die gleiche Funktionalität bei null Lizenzkosten und ohne Datenschutz-Diskussion.

## Typical use cases include Filialfinder, Immobilienkarten und Event-Standorte

Das häufigste Szenario ist der Filial- oder Standortfinder. Ein Unternehmen mit 20 bis 200 Filialen zeigt alle Standorte auf einer interaktiven Karte. Nutzer können zoomen, nach Postleitzahl suchen und auf Marker klicken, um Adresse, Öffnungszeiten und Kontaktdaten zu sehen. Bei dichter Marker-Verteilung gruppiert Clustering nahegelegene Standorte zu einem Sammel-Marker, der beim Zoomen in Einzelmarker aufgelöst wird. Ein typischer Filialfinder mit 100 Standorten und Clustering lädt in unter 500ms.

Zweites Szenario: Immobilien- und Objektkarten. Makler, Hausverwaltungen und Wohnungsbaugesellschaften zeigen verfügbare Objekte auf einer Karte an. Die Marker enthalten Basisinformationen (Preis, Zimmeranzahl, Wohnfläche) als Popup und verlinken auf die Detailseite. Die TYPO3-Extension kann Objekt-Datensätze aus einer Extbase-Tabelle als Marker rendern.

Drittes Szenario: Event-Standorte und Tourismus. Veranstalter, Tourismusverbände und Städte zeigen POIs (Points of Interest), Routen und Veranstaltungsorte auf einer Karte. Leaflet unterstützt neben Punkt-Markern auch Linien (für Wanderrouten) und Polygone (für Gebiete), was es zum flexiblen Werkzeug für touristische Anwendungen macht.

## Technical architecture separates Daten-Backend und Karten-Rendering sauber

Die TYPO3-Extension speichert Standort-Daten als Extbase-Records in einer eigenen Tabelle. Jeder Record enthält Name, Adresse, Koordinaten (Latitude/Longitude), Beschreibung und optionale Felder wie Öffnungszeiten, Telefonnummer und Bild. Die Koordinaten können manuell eingegeben oder über einen Geocoding-Service automatisch aus der Adresse ermittelt werden.

Im Frontend rendert die Extension ein Karten-Container-Element und initialisiert Leaflet per JavaScript. Die Karten-Tiles werden von einem konfigurierbaren Tile-Server geladen. Der Standard ist OpenStreetMap, aber auch Mapbox, Stamen und andere Tile-Provider sind per TypoScript umschaltbar. Die Marker werden als JSON-Array in das JavaScript übergeben, was auch bei 500+ Standorten performant bleibt.

Clustering wird über das Leaflet.markercluster-Plugin realisiert, das Marker auf niedrigen Zoomstufen zusammenfasst und beim Hineinzoomen auflöst. Die Cluster-Schwellwerte sind konfigurierbar. Für die Suche nach Postleitzahl oder Ort wird clientseitig gefiltert, was bei bis zu 1.000 Markern ohne serverseitige Unterstützung funktioniert.

Die Karten-Styles sind vollständig anpassbar: Farben, Schriftarten, Strassenbreiten und Kartendetails lassen sich über Tile-Layer-Konfiguration und Custom-CSS steuern. Im Vergleich zu Google Maps, dessen Styling eingeschränkt ist, bietet Leaflet volle Kontrolle über das Erscheinungsbild.

## Common problems involve Geocoding, Tile-Server-Verfügbarkeit und responsive Darstellung

Problem eins: Geocoding-Fehler bei ungenauen Adressen. Nicht jede Adresse wird vom Geocoding-Service korrekt aufgelöst. Besonders Gewerbegebiete, Neubaugebiete und Adressen in ländlichen Regionen liefern ungenaue oder falsche Koordinaten. Die Lösung: Automatisches Geocoding als Erstbefüllung nutzen und die Koordinaten manuell prüfen. Die Extension sollte ein Kartenfenster im Backend anzeigen, über das der Redakteur den Marker per Drag-and-Drop korrigieren kann.

Problem zwei: Tile-Server-Verfügbarkeit. Der Standard-Tile-Server von OpenStreetMap hat eine Fair-Use-Policy und kann bei hohem Traffic Rate-Limiting anwenden. Für produktive Websites mit mehr als 50.000 Kartenabrufen pro Monat empfiehlt sich ein eigener Tile-Server oder ein kommerzieller Provider wie Mapbox oder Maptiler. Die Kosten liegen bei 5 bis 50 Euro pro Monat, immer noch deutlich unter Google Maps.

Problem drei: Responsive Darstellung auf Mobilgeräten. Karten auf kleinen Bildschirmen sind schwer zu bedienen, weil das Zoomen mit dem Swipen der Seite kollidiert. Die Lösung: Touch-Gesten auf der Karte mit zwei Fingern einschränken (scrollWheelZoom und dragging auf Mobilgeräten deaktivieren) und einen "Karte vergrössern"-Button anbieten, der die Karte im Vollbildmodus öffnet.

## Leaflet ist zukunftssicher, die TYPO3-Extension muss bei v13 geprüft werden

Leaflet als JavaScript-Bibliothek ist vom TYPO3-Versionsstand unabhängig und wird aktiv weiterentwickelt. Die TYPO3-Extension, die die Backend-Integration und das Rendering übernimmt, muss bei einem Upgrade auf v12 oder v13 geprüft werden. Die Extbase-API-Änderungen in v12 betreffen Repository-Klassen und Persistenz-Konfiguration. Bei Gosign migrieren wir Leaflet-Integrationen typischerweise durch ein Custom-Plugin im eigenen Sitepackage, das die Leaflet-Bibliothek direkt einbindet und die Standort-Daten aus einer Extbase-Tabelle oder einem JSON-Endpoint bezieht. Das eliminiert die Abhängigkeit von der Extension und gibt volle Kontrolle über Updates. Die Leaflet-Bibliothek selbst wird per npm oder CDN eingebunden und ist mit einer Grösse von 39 KB (komprimiert) deutlich leichter als die Google Maps JavaScript API (185+ KB), was sich positiv auf die Ladezeit der Kartenseiten auswirkt.

--- LimeSurvey TYPO3 - Survey Integration | Gosign ---
> LimeSurvey in TYPO3: embed surveys, SSO integration, result dashboard. AI-accelerated integration.

## LimeSurvey is the GDPR-compliant answer for enterprise surveys that must not end up in Google Forms

Anyone running professional surveys in Europe (employee surveys, market research, evaluation studies, scientific fieldwork) and needing GDPR compliance, full data sovereignty and a clean audit trail almost inevitably ends up at LimeSurvey. The open source software runs on your own server, stores answer data exclusively in your own database and offers all the question types that serious research demands. For TYPO3 operators, the question is not whether to use LimeSurvey but how to integrate it into their existing website.

The audience are typically universities, research institutions, public administrations, hospitals, corporations with works council mandates and NGOs with sensitive target group surveys. An example: a university with 18,000 students runs a teaching evaluation every semester and wants to feed the results back onto its own TYPO3 website, without students having to switch between two systems.

## Typical use cases

A first scenario is seamless survey participation on the TYPO3 page. Instead of sending students onto a separate LimeSurvey domain, the questionnaire is displayed directly on the website page. The answers flow into LimeSurvey through the API, and students see the familiar website navigation. This noticeably reduces the dropout rate.

A second scenario is SSO-based participant identification. A hospital group with 8,000 employees runs an employee survey. Participants log in to the TYPO3 intranet, click on the survey link and land in LimeSurvey without having to log in again. The SSO bridge guarantees that every employee only participates once and that personal data from TYPO3 does not flow into the survey answers.

A third scenario is the display of results directly on the website. A municipal administration runs a citizen survey on a construction project and wants to show the running totals as a bar chart on the project page every day. A sync job pulls the anonymised aggregates through the API and renders them in a TYPO3 content element, without raw data ever touching the TYPO3 installation.

A fourth scenario is a longitudinal study in research. A research project on workload in the care sector surveys the same cohort four times per year over two years. The TYPO3 page serves as information and entry point, LimeSurvey holds the waves, and the integration makes sure that every participant reaches their follow-up waves through a personalised link, without researchers having to maintain contact data inside LimeSurvey.

## Technical architecture

LimeSurvey provides two API access points: the classic RemoteControl2 interface based on JSON-RPC and the newer REST API in current versions. For TYPO3 integrations, RemoteControl2 remains the stability anchor because it is available in older LimeSurvey installations and covers full authentication, participant management and answer queries.

The TYPO3 integration typically runs as a dedicated extension. A service layer encapsulates the API calls, a plug-in provides content elements for embedding surveys, and a middleware implements the SSO logic. For embedding there are two variants: the survey is called through a signed token and embedded via iframe, or the questions are read through the API and rendered directly as a Fluid template. The second approach offers the best user experience but requires more development effort.

The SSO bridge relies on a signed token that TYPO3 generates and LimeSurvey validates. A plug-in is set up inside LimeSurvey that reads the token from the URL and registers the participant as an anonymous token in the survey participant table. What matters is that the token is time-limited and only valid once per participant.

## Common problems and solutions

The first problem is session handling between TYPO3 and LimeSurvey. Both systems have their own sessions, and when the iframe approach is chosen, problems with third-party cookies arise in modern browsers. The solution is to run LimeSurvey under a subdomain of the TYPO3 installation, so that cookies are accepted as first-party, or to use the API variant with server-side rendering.

The second problem is a performance crisis in the result display. Anyone who asks the API for aggregates on every page view puts unnecessary load on the LimeSurvey server. The solution is a sync job that writes aggregates into a TYPO3 table at regular intervals (for example hourly) and renders the content element from this cache table.

The third problem is GDPR-compliant handling of personal data. On employee surveys, the employer usually must not be able to tell who gave which answer. The solution is a clean separation concept: TYPO3 only provides anonymised tokens, LimeSurvey stores answers without any back reference, and aggregation happens exclusively through metrics that do not allow conclusions about individuals.

A fourth problem are mobile display weaknesses in iframe mode. LimeSurvey surveys are responsive, but inside a TYPO3 iframe, double scrollbars and clipped buttons appear on small screens. The solution is to switch to server-side rendering for mobile use or to dynamically resize the iframe to the content, so that the page layout container takes the full height.

## Migration and version compatibility

LimeSurvey integrations run on TYPO3 v11, v12 and v13. The bigger challenge is on the LimeSurvey side: between LimeSurvey 3.x, 5.x and 6.x, API details and authentication methods have changed. Anyone lifting an existing integration onto a new LimeSurvey version should verify the API calls against the respective version documentation and ideally run an automated integration test against a LimeSurvey staging instance.

Gosign implements LimeSurvey integrations for universities, hospitals and public institutions. The API client is built with AI support from the RemoteControl2 documentation, the SSO bridge is adapted individually to the existing identity management, and the implementation follows clear GDPR documentation that takes work off the data protection officer.

--- linkhandler TYPO3 - Custom Record Links | Gosign ---
> linkhandler: custom record links in TYPO3 RTE. Link news, events, products directly. Setup & migration.

## linkhandler prevents dead links when URLs change

In TYPO3, a typolink reference points directly at a page, a file or a URL, not at a record. As soon as an editorial team wants to link from running text to events, news articles, products or addresses, they either have to type in the URL by hand or wire an extension between them that turns a record ID into a stable URL. That is exactly what linkhandler does. The extension from Cobwebsters registers new link types in the TYPO3 RTE and in the link browser and connects them to arbitrary database tables. On an editorial project with more than a hundred internal cross-references, that is the difference between a working content architecture and a graveyard page full of 404 links.

## Typical use cases appear in every editorial setup with more than one content domain

As soon as news, events and products coexist in the same project, editors need a clean linking system. A university links from the magazine article to the event in sf_event_mgt, from the event text to the contributing author from md_news_author and from the author profile back to all their contributions in GeorgRinger/news. Three extensions, three record types, and without linkhandler each of these cross references would be a hard URL that breaks on the next slug refactor. In day-to-day operations that means: a single URL refactor can produce dozens or hundreds of broken links that only show up in the Google Search Console report weeks later.

A second scenario are e-commerce texts: product descriptions that point to accessories, or blog articles that link to products from aimeos. linkhandler generates the URLs automatically from the product routing configuration, and on a category refactor all the links move along.

Thirdly, the need appears on location listings. Anyone maintaining a branch structure or contact directories with tt_address or a custom model wants to link from articles to the respective detail page. The linkhandler link remains stable even if the location is renamed.

## Technical architecture registers link types via YAML and handler class

linkhandler uses the TYPO3 core LinkHandler mechanism that has been available since v8. Every link type is registered through a YAML file in the config directory. The YAML defines the handler identifier, the table, the Extbase model and the routing configuration. In the RTE and in the link browser, the link type appears as a new tab: "News", "Event", "Product", "Address". Each tab shows a list of the available records with search and filter functionality, so that editors can find the desired entry even with thousands of news records.

The actual resolver is a PHP class that inherits from AbstractLinkHandler and implements the methods modifyLinkField and generateRelativeUrl. These methods turn the record ID into a speaking URL via the site config and the router of the respective extension. In the frontend, the typolink is called with the parameter t3://record and resolved by the page rendering into the final URL. That means: even if tens of thousands of articles link to the same news record, only the article record itself has to be updated on a slug change, and all links automatically resolve to the new URL.

The configuration reaches deep into the TYPO3 linking system but stays declarative: after the YAML registration and a cache clear, the new link type is available across the entire project, including Fluid templates and menu components. Anyone who does not use linkhandler explicitly still gets the mechanism via TYPO3 core linking, but without the YAML abstraction layer and the comfortable backend picker UI that the extension provides.

## Common problems involve cache, language variants and file handlers

The most common support topic is cache inconsistency after updating a record. When the slug of a news article is adjusted, the page cache of the source article that holds the linkhandler link has to be cleared as well, otherwise the old URL stays in the output. The solution is a cache tag that is set along with the typolink rendering. Many installations do not enable this and then fight with apparently broken links.

The second problem is language variants. A news article in DE links via linkhandler to an event. The English translation of the article should point to the same event ID but generate the URL in the English language. linkhandler offers this resolution via the language aspect, but the YAML configuration has to explicitly point at the routing variants of the target pages. Anyone using fallback languages additionally has to check how the handler behaves when translations are missing: it should resolve in the fallback language and not drop back to the main language.

Thirdly, the file handler is a special case. Anyone who wants to link not only to records but also to TYPO3 FAL files has to configure the linkhandler file handler separately or rely on the native TYPO3 file linker. The combination is possible, but the order of the handlers in the YAML decides which tab appears first.

## TYPO3 v12 and v13 use the core LinkHandler, migration pays off

From TYPO3 v11 onwards, the core LinkHandler is production-ready and can handle many of the jobs that linkhandler covers on its own. Nevertheless, the Cobwebsters extension is still maintained because it ships additional comfort features such as the YAML editor, the improved record picker and schema-friendly output. A current version for TYPO3 v12 and v13 exists in the TER and on Packagist.

During a migration review, Gosign checks how many linkhandler calls sit inside the RTE content. With fewer than 50 occurrences it often pays off to switch to the core LinkHandler, with more than 100 occurrences or with heavily customised handlers linkhandler remains the more pragmatic choice. The migration to a new major version usually runs without content changes, because the t3://record syntax in the content remains stable. For the analysis, we run a scan over tt_content fields that breaks down all link types and generates a recommendation per installation.

--- Live Ticker TYPO3 - Real-Time Updates | Gosign ---
> Live ticker for real-time events: sports, elections, conferences. WebSocket or polling-based, with automatic loading of new entries.

## Echtzeit-Updates auf TYPO3-Websites verlangen mehr als ein News-Plugin mit Auto-Refresh

Sportvereine, Nachrichtenportale, Kommunen bei Wahlergebnissen und Konferenzveranstalter brauchen eine Funktion, die es so im TYPO3-Core nicht gibt: chronologische Kurzmeldungen, die in Echtzeit auf der Seite erscheinen, ohne dass der Besucher die Seite neu laden muss. Die liveticker-Extension löst das mit einem Frontend-Plugin, das neue Einträge automatisch per AJAX-Polling oder WebSocket nachladen und oben in die Timeline einfügen kann. Redakteure tippen eine Meldung im Backend, klicken "Speichern", und die Meldung erscheint Sekunden später auf der Website.

Für Organisationen, die zwei- bis dreimal im Jahr Live-Events auf ihrer Website begleiten, ist die Extension eine pragmatische Lösung. Wer täglich live tickert, sollte allerdings spezialisierte Plattformen wie Tickaroo evaluieren, die Multimedia-Inhalte, Social-Media-Integration und Multi-Autoren-Workflows besser abdecken.

## Typical use cases include Sportveranstaltungen, Kommunalwahlen und Konferenzen

Das häufigste Szenario ist der Sport-Liveticker. Ein Amateursportverein begleitet Heimspiele mit einem Ticker auf der Vereinswebsite. Ein Redakteur am Spielfeldrand tippt Tore, Karten und Wechsel ins TYPO3-Backend (idealerweise über das Mobile-Backend), und die Einträge erscheinen chronologisch auf der Seite. Bei einem Fussball-Regionalligaspiel mit 500 bis 2.000 gleichzeitigen Besuchern muss der Ticker stabil laufen, ohne den Server zu überlasten.

Zweites Szenario: Wahlabende bei Kommunen und Landkreisen. Am Wahlsonntag veröffentlichen Gemeinden Zwischenergebnisse über einen Liveticker. Die Meldungen enthalten Stimmanteile, Hochrechnungen und Kommentare des Wahlleiters. Die Herausforderung: Alle Besucher erwarten das gleiche Ergebnis gleichzeitig, was Peak-Traffic erzeugt.

Drittes Szenario: Konferenzen und Mitgliederversammlungen. Verbände und Vereine tickern Hauptversammlungen live, damit Mitglieder, die nicht vor Ort sind, den Verlauf verfolgen können. Die Einträge enthalten Abstimmungsergebnisse, Redebeiträge und Beschlüsse. Für Verbände mit 5.000 bis 50.000 Mitgliedern, die nicht alle an einer Präsenzveranstaltung teilnehmen können, ist ein Liveticker die einfachste Form der digitalen Teilhabe, die keine Video-Streaming-Infrastruktur erfordert.

## Technical architecture relies on TYPO3-Records mit AJAX-Polling im Frontend

Die Extension speichert Ticker-Einträge als TYPO3-Records in einer eigenen Tabelle. Jeder Eintrag enthält Zeitstempel, Text, optionales Bild und eine Kategorisierung (z.B. "Tor", "Gelbe Karte", "Ergebnis"). Die Records gehören zu einem Ticker-Container, der einem Event zugeordnet ist. Ein Redakteur kann mehrere Ticker parallel betreiben, etwa für verschiedene Spiele oder Events am gleichen Tag.

Im Frontend rendert das Plugin die bestehenden Einträge als chronologische Liste (neueste oben) und startet einen JavaScript-Timer, der in konfigurierbaren Intervallen (typisch: 10 bis 30 Sekunden) einen AJAX-Request an einen TYPO3-Endpoint sendet. Der Endpoint liefert alle Einträge, die seit dem letzten Abruf hinzugekommen sind. Das JavaScript fügt diese Einträge mit einer Animation oben in die Liste ein.

Fortgeschrittene Implementierungen nutzen WebSockets statt Polling, was die Latenz von 10 bis 30 Sekunden auf unter 1 Sekunde reduziert. Das erfordert allerdings einen WebSocket-Server (z.B. Node.js mit Socket.io), der parallel zum TYPO3-Webserver läuft. Für die meisten Vereins- und Kommunal-Websites ist das Overkill, und AJAX-Polling mit 15-Sekunden-Intervall liefert ein ausreichend echtzeitnahes Erlebnis. Eine Zwischenlösung sind Server-Sent Events (SSE), die eine persistente HTTP-Verbindung nutzen und einfacher zu implementieren sind als WebSockets, aber ebenfalls serverseitige Unterstützung benötigen.

## Common problems include Server-Last bei Peak-Traffic, fehlende Mobile-Eingabe und Caching-Konflikte

Problem eins: Server-Last bei Peak-Traffic. Wenn 2.000 Besucher alle 15 Sekunden einen AJAX-Request senden, sind das 8.000 Requests pro Minute. Ohne Caching-Strategie bricht ein normaler Shared-Hosting-Server zusammen. Die Lösung: Einen Reverse-Proxy (z.B. Varnish oder Cloudflare) vor den AJAX-Endpoint schalten, der die Response für 5 Sekunden cached. So reduzieren sich die tatsächlichen Zugriffe auf den Application-Server auf 12 pro Minute statt 8.000.

Problem zwei: Mobile-Eingabe für Redakteure. Das TYPO3-Backend ist auf Mobilgeräten nur eingeschränkt nutzbar. Ein Redakteur am Spielfeldrand, der bei Regen auf einem Smartphone tippt, braucht eine vereinfachte Eingabemaske. Die Lösung: Ein Custom-Endpoint mit einem reduzierten Formular (Textfeld, Kategorie-Dropdown, Absenden-Button), das für mobile Browser optimiert ist.

Problem drei: Caching-Konflikte mit dem TYPO3-Page-Cache. Wenn die Seite, auf der der Ticker eingebettet ist, vom TYPO3-Cache ausgeliefert wird, sehen Besucher veraltete Einträge. Die Lösung: Die Ticker-Seite vom Page-Cache ausschliessen (USER_INT) oder besser: Die Seite cachen und nur den Ticker-Bereich per AJAX nachladen, was die Kombination aus gecachter Seite und dynamischem Inhalt ermöglicht.

## Die Extension ist für ältere TYPO3-Versionen gebaut, Custom-Lösungen include zukunftssicherer

liveticker hat keine offizielle Unterstützung für TYPO3 v12 oder v13. Die Kernfunktionalität ist aber so überschaubar, dass ein Neubau als Custom-Plugin in vielen Fällen wirtschaftlicher ist als die Migration der Extension. Gosign baut Liveticker-Funktionen als schlanke Extbase-Plugins mit einem JSON-API-Endpoint, der von einem einfachen JavaScript-Client im Frontend konsumiert wird. Der Aufwand für eine Grundimplementierung (Backend-Eingabe, Frontend-Anzeige, AJAX-Polling) liegt bei 3 bis 5 Arbeitstagen.

Der Vorteil einer Custom-Lösung: Die Mobile-Eingabe kann als Progressive Web App realisiert werden, sodass der Redakteur am Spielfeldrand eine optimierte Eingabeoberfläche hat. Zusätzlich lässt sich ein Cache-Layer (z.B. Redis oder Cloudflare Workers) zwischen Frontend und TYPO3 schalten, der die Server-Last bei Peak-Traffic auf ein Minimum reduziert. Diese Architektur skaliert für 10.000+ gleichzeitige Besucher ohne Performance-Probleme.

--- Mailchimp TYPO3 - Newsletter | Gosign ---
> Subscriber synchronization between TYPO3 and Mailchimp. Campaign statistics, template sync, transactional emails. GDPR: data processing agreement required.

## Mailchimp-TYPO3-Integration geht über Formulare hinaus und synchronisiert Audiences bidirektional

Während koning_mailchimp_signup nur Anmeldeformulare abdeckt, geht die mailchimp-Extension einen Schritt weiter: Sie synchronisiert komplette Subscriber-Listen bidirektional zwischen TYPO3 und Mailchimp, überträgt Kampagnen-Statistiken ins Backend und kann Newsletter-Templates aus TYPO3-Content-Elementen generieren. Für Unternehmen, die Mailchimp nicht nur als Newsletter-Versand, sondern als zentrale Marketing-Automation-Plattform nutzen, schliesst die Extension die Lücke zwischen CMS und E-Mail-Marketing.

Der GDPR-Aspekt ist bei dieser tieferen Integration noch relevanter: Nicht nur E-Mail-Adressen, sondern auch Engagement-Daten (Öffnungen, Klicks, Bounces), Tags und Custom Fields werden zwischen Systemen übertragen. Ohne data processing agreement mit Mailchimp und dokumentierten US-Transfer-Mechanismus ist das datenschutzrechtlich nicht zulässig.

## Typical use cases include Marketing-Automation, Template-Sync und Reporting

Das Hauptszenario ist die bidirektionale Subscriber-Synchronisation für Marketing-Teams. TYPO3 ist die Quelle für neue Anmeldungen (über Formulare auf der Website), Mailchimp ist die Quelle für Engagement-Daten. Die Extension gleicht beide Systeme regelmässig ab, sodass Marketing in Mailchimp sehen kann, welche Subscriber über welche Website-Seite angemeldet wurden, und in TYPO3 sichtbar ist, welche Subscriber aktiv sind und welche als inaktiv markiert wurden.

Zweites Szenario: Template-Synchronisation. Die Redaktion pflegt Newsletter-Inhalte in TYPO3, und die Extension überträgt Content-Elemente (Teaser, Bilder, Links) in Mailchimp-Templates. So entfällt die doppelte Pflege: Der Teaser auf der Website und der Teaser im Newsletter stammen aus demselben Datensatz.

Drittes Szenario: Kampagnen-Reporting im TYPO3-Backend. Marketing-Verantwortliche, die keinen direkten Zugang zum Mailchimp-Dashboard haben, sehen Öffnungsraten, Klickraten und Bounce-Raten direkt im TYPO3-Backend. Das ist relevant für Unternehmen mit strikter Rechteverwaltung, bei denen nur ausgewählte Personen Zugang zu Mailchimp haben. Die Daten helfen der Redaktion zu verstehen, welche Website-Inhalte im Newsletter funktionieren und welche nicht, was wiederum die Content-Strategie der Website beeinflusst.

## Technical architecture uses die Mailchimp-API v3 mit Scheduler-basiertem Sync

Die Extension kommuniziert über die Mailchimp Marketing API v3. Die Authentifizierung erfolgt über einen API-Key, der im TYPO3-Extension-Manager hinterlegt wird. Der Sync läuft über TYPO3-Scheduler-Tasks in konfigurierbaren Intervallen.

Der Subscriber-Sync arbeitet in zwei Richtungen: TYPO3-zu-Mailchimp überträgt neue Anmeldungen und Profiländerungen. Mailchimp-zu-TYPO3 importiert Engagement-Daten, Abmeldungen und Bounce-Status. Die Sync-Logik verwendet Mailchimp-Member-IDs (MD5-Hash der E-Mail-Adresse) als eindeutigen Schlüssel für den Abgleich.

Die Template-Synchronisation rendert TYPO3-Content-Elemente über Fluid-Templates in ein E-Mail-kompatibles HTML-Format. Das Template wird per API-Call an Mailchimp übertragen und steht dort als Campaign-Template zur Verfügung. Die Extension kümmert sich um die Konvertierung von CSS-Klassen in Inline-Styles, was für die E-Mail-Client-Kompatibilität zwingend nötig ist.

Kampagnen-Daten werden per GET-Request von der Mailchimp-API abgerufen und in einer TYPO3-Datenbanktabelle gespeichert. Das Backend-Modul zeigt die Daten als Dashboard mit Basis-KPIs: Empfänger, Öffnungsrate, Klickrate, Abmeldungen pro Kampagne.

## Common problems include Sync-Konflikte, API-Rate-Limits und Template-Rendering-Unterschiede

Problem eins: Sync-Konflikte bei gleichzeitigen Änderungen. Wenn ein Subscriber sich über Mailchimp abmeldet und gleichzeitig ein Redakteur in TYPO3 dessen Profil ändert, entsteht ein Konflikt. Die Lösung: Klare Datenhoheit definieren. In der Praxis ist Mailchimp die führende Quelle für Engagement-Daten und Abmeldungen, TYPO3 für Stammdaten und neue Anmeldungen.

Problem zwei: API-Rate-Limits. Die Mailchimp-API erlaubt maximal 10 gleichzeitige Verbindungen und hat Throughput-Limits, die bei grossen Sync-Vorgängen greifen. Wer 50.000 Subscriber synchronisiert, muss den Sync in Batches aufteilen (empfohlen: 500 Records pro Request) und Backoff-Logik implementieren.

Problem drei: Template-Rendering-Unterschiede zwischen Website und E-Mail. Ein Content-Element, das auf der Website korrekt aussieht, kann in Outlook oder Gmail anders dargestellt werden. Besonders Flexbox-Layouts, Webfonts und SVG-Bilder funktionieren in E-Mails nicht. Die Lösung: Separate E-Mail-Templates mit Tabellen-basiertem Layout und System-Fonts. Gosign pflegt für solche Fälle ein dediziertes E-Mail-Template-Set, das die häufigsten Content-Elemente E-Mail-kompatibel rendert.

Ein viertes Problem betrifft die Listenhygiene. Mailchimp berechnet nach Audience-Grösse, und wenn die TYPO3-Synchronisation inaktive Subscriber nicht bereinigt, wächst die Liste mit Adressen, die nie öffnen oder längst ungültig sind. Die Extension sollte so konfiguriert sein, dass Bounce-Status und Unsubscribe-Events von Mailchimp zurück nach TYPO3 gespiegelt werden, damit inaktive Adressen aus der Synchronisation ausgeschlossen werden. Das spart Mailchimp-Kosten und verbessert die Zustellrate der verbleibenden Empfänger.

## TYPO3 v12 wird unterstützt, für v13 empfiehlt sich eine direkte API-Integration

Die mailchimp-Extension unterstützt TYPO3 v11 und v12. Beim Upgrade müssen vor allem die Scheduler-Task-Konfigurationen angepasst werden, da sich die Scheduler-API in TYPO3 v12 geändert hat. Die Extension-Konfiguration sollte gleichzeitig auf SiteSet-basierte Settings umgestellt werden, um zukunftssicher aufgestellt zu sein. Für TYPO3 v13 liegt noch kein offizielles Release vor. Da die Mailchimp-API v3 stabil und gut dokumentiert ist, empfiehlt Gosign für v13-Projekte eine direkte API-Integration ohne Extension-Abhängigkeit. Ein Custom-Service-Klasse in einem eigenen TYPO3-Package, die die Mailchimp-API direkt anspricht, ist wartungsärmer als eine Community-Extension und lässt sich exakt auf die Projektanforderungen zuschneiden.

Unternehmen, die langfristig bei Mailchimp bleiben wollen, sollten zusätzlich die Mailchimp-Webhook-Funktion evaluieren: Statt regelmässig Daten abzufragen, sendet Mailchimp Events (Anmeldung, Abmeldung, Bounce) aktiv an einen TYPO3-Endpoint. Das reduziert die Sync-Latenz von Minuten auf Sekunden und eliminiert die Belastung durch periodische API-Abfragen.

--- mailingwork TYPO3 - Newsletter | Gosign ---
> mailingwork is a German email marketing system. TYPO3 integration synchronizes subscribers, double opt-in and segmentation. Servers in Germany, GDPR-native.

## mailingwork ist die GDPR-native Newsletter-Alternative zu Mailchimp für TYPO3-Projekte

Unternehmen, die einen professionellen Newsletter versenden, aber keine Daten in die USA übertragen wollen, landen fast zwangsläufig bei einem deutschen Anbieter. mailingwork gehört zu den etablierten deutschen E-Mail-Marketing-Plattformen mit Servern in Deutschland, deutscher Rechtsform und einem Support-Team, das GDPR-Fragen auf Deutsch beantworten kann. Die TYPO3-Extension synchronisiert Subscriber-Listen, steuert Double-Opt-In und überträgt Segmentierungsdaten zwischen CMS und Newsletter-System. Für TYPO3-Projekte, die eine rechtlich unkomplizierte Newsletter-Lösung brauchen, ist die Kombination aus mailingwork und TYPO3 eine der wartungsärmsten Optionen im deutschsprachigen Markt.

Der Vergleich mit Mailchimp zeigt den Unterschied: Kein DPA mit einem US-Unternehmen nötig, kein Transfer-Mechanismus zu dokumentieren, kein Risiko bei Änderungen der transatlantischen Datenschutzabkommen. Die Kehrseite: mailingwork hat einen kleineren Feature-Set als Mailchimp und kein vergleichbares Ökosystem an Third-Party-Integrationen. Wer fortgeschrittene Marketing-Automation (Behavioral Trigger, Lead Scoring, Customer Journey Mapping) benötigt, stösst bei mailingwork eher an Grenzen als bei Mailchimp oder HubSpot.

## Typical use cases include Unternehmens-Newsletter, Mitglieder-Kommunikation und Lead-Nurturing

Das Standardszenario ist der monatliche Unternehmens-Newsletter für 5.000 bis 50.000 Empfänger. Die Redaktion pflegt Inhalte in TYPO3, erstellt den Newsletter in mailingwork und verschickt ihn an segmentierte Listen. Die TYPO3-Extension sorgt dafür, dass neue Website-Anmeldungen automatisch in mailingwork landen und dass Abmeldungen in beide Richtungen synchronisiert werden.

Zweites Szenario: Mitglieder-Kommunikation bei Verbänden und Vereinen. Ein Berufsverband mit 10.000 Mitgliedern verschickt Rundschreiben, Einladungen und Jahresberichte. Die Mitglieder-Daten liegen in TYPO3 (über fe_users oder eine Custom-Tabelle), und mailingwork übernimmt den Versand. Die Segmentierung nach Mitgliedsart, Region oder Fachgruppe wird über Tags gesteuert, die die Extension aus TYPO3-Kategorien generiert.

Drittes Szenario: Lead-Nurturing für B2B-Unternehmen. Ein Maschinenbauer sammelt Leads über Whitepaper-Downloads und Kontaktformulare auf der TYPO3-Website. Die Extension überträgt die Leads mit Quell-Information (welches Formular, welche Seite) an mailingwork, das eine automatisierte E-Mail-Strecke startet: Welcome-Mail nach 1 Tag, Case-Study nach 7 Tagen, Angebots-Einladung nach 14 Tagen.

## Technical architecture connects TYPO3-Formulare über die mailingwork-REST-API

Die Extension nutzt die mailingwork-REST-API für den Datenaustausch. Die Konfiguration im TYPO3-Extension-Manager umfasst API-Endpoint, API-Key und die Zuordnung von TYPO3-Feldern zu mailingwork-Kontaktfeldern. Der Sync läuft über Scheduler-Tasks in konfigurierbaren Intervallen.

Der Subscriber-Import folgt einem klaren Ablauf: Ein Besucher füllt ein Anmeldeformular auf der Website aus. TYPO3 speichert die Daten lokal und überträgt sie per API-Call an mailingwork. mailingwork verschickt die Double-Opt-In-Mail. Erst nach Bestätigung wird der Subscriber in der aktiven Liste geführt. Die Extension protokolliert jeden Schritt in einer Log-Tabelle, was für GDPR-Audits relevant ist.

Die Segmentierung funktioniert über Tags und Custom Fields. Die Extension kann TYPO3-Kategorien (Sys-Categories) automatisch als Tags an mailingwork übergeben. So lassen sich Website-spezifische Segmente (z.B. "Interessiert an Produkt X") direkt für den Newsletter-Versand nutzen.

Die Templates in mailingwork werden unabhängig von TYPO3 gepflegt. Wer Content aus TYPO3 automatisch in Newsletter-Templates übernehmen will, muss das über die mailingwork-API und Custom-Code lösen, da die Standard-Extension diese Funktion nicht abdeckt.

## Common problems involve Feld-Mapping, Double-Opt-In-Timing und Fehler-Handling

Problem eins: Fehlerhaftes Feld-Mapping. Die Felder in TYPO3-Formularen stimmen selten 1:1 mit den Kontaktfeldern in mailingwork überein. Ein Formular hat "Firma", mailingwork erwartet "company". Ohne korrektes Mapping landen Daten in falschen Feldern oder gehen verloren. Die Lösung: Vor der Integration ein Feld-Mapping-Dokument erstellen, das alle TYPO3-Felder den mailingwork-Feldern zuordnet, und die Zuordnung in der Extension-Konfiguration hinterlegen.

Problem zwei: Timing des Double-Opt-In. Zwischen der Anmeldung auf der Website und dem Klick auf den Bestätigungslink vergehen oft Stunden oder Tage. Wenn der Sync-Job in der Zwischenzeit läuft und den noch nicht bestätigten Subscriber als "aktiv" an TYPO3 zurückmeldet, entstehen Inkonsistenzen. Die Lösung: Den Subscriber-Status in TYPO3 erst auf "aktiv" setzen, wenn mailingwork den Status "confirmed" zurückgibt.

Problem drei: Fehler-Handling bei API-Ausfällen. Wenn die mailingwork-API nicht erreichbar ist, muss die Extension die Anmeldung puffern und beim nächsten Sync-Lauf erneut versuchen. Ohne diese Retry-Logik gehen Anmeldungen verloren. Die Extension bietet eine Queue-Funktion, die fehlgeschlagene API-Calls speichert und automatisch wiederholt.

Ein viertes Problem, das bei grösseren Installationen auftaucht: Reporting-Granularität. mailingwork liefert Kampagnen-Statistiken auf Empfänger-Ebene, aber die TYPO3-Extension bildet nicht alle Metriken im Backend ab. Für detaillierte Analysen (Klick-Heatmaps, Öffnungszeitpunkte, Device-Verteilung) muss man ins mailingwork-Dashboard wechseln. Gosign empfiehlt, das TYPO3-Backend-Modul für Übersichtsdaten zu nutzen und für tiefe Analysen direkt in mailingwork zu arbeiten.

## mailingwork pflegt die TYPO3-Extension aktiv, v12 wird unterstützt

mailingwork als kommerzieller Anbieter hat ein geschäftliches Interesse daran, die TYPO3-Integration aktuell zu halten, weil der TYPO3-Markt ein relevanter Vertriebskanal ist. Die aktuelle Extension unterstützt TYPO3 v11 und v12. Für v13 ist die Kompatibilität zu erwarten, aber noch nicht offiziell bestätigt. Beim Upgrade von v10 auf v12 betreffen Änderungen vor allem die Scheduler-Task-Registrierung und die Extension-Konfiguration, die von ExtensionManager-Settings auf SiteSet-Konfiguration umgestellt werden sollte. Der Subscriber-Sync und die API-Kommunikation bleiben stabil.

--- maps2 TYPO3 - Maps Extension | Gosign ---
> The standard maps extension for TYPO3. Supports Google Maps, OpenStreetMap and Mapbox. Markers from TYPO3 records, clustering, routing, custom popups.

## Why maps2 has become the standard solution for maps in TYPO3

Every second corporate website needs a map display - for locations, branches, event venues or delivery areas. In TYPO3, maps2 has established itself as the most widely used maps extension because it simultaneously supports three map providers: Google Maps, OpenStreetMap and Mapbox. This gives organizations genuine choice. Those wanting to avoid Google Maps for privacy reasons can switch to OpenStreetMap without replacing the extension.

maps2 goes far beyond a simple map embed. The extension generates markers directly from TYPO3 records, supports clustering for large marker volumes and offers routing functions. For editors, creating new locations is as easy as creating a normal TYPO3 content element.

## Typical use cases

**Branch finders for companies with 10 to 500 locations.** A retail company wants to offer an interactive branch finder on its website. Each branch is stored as a tt_address record or custom record in TYPO3. maps2 reads the addresses, geocodes them (in combination with the geocoordinates extension) and displays them as markers on the map. Clicking a marker opens a popup with address, opening hours and contact details. With more than 50 markers, maps2 activates automatic clustering to keep the map readable.

**Real estate websites with property maps.** Real estate websites on TYPO3 use maps2 together with the OpenImmo extension. Every imported property is automatically displayed on the map. Users can filter by region and switch between map and list views.

**Event and venue pages.** Cultural institutions, trade shows or municipalities display event locations on a map. maps2 can be linked with any Extbase extension that contains address data - whether cal, tt_address or custom extensions.

## Technical architecture

maps2 is built as an Extbase extension and uses the TYPO3 plugin system for frontend output. The central architectural decision is the provider abstraction: the extension defines a unified interface for map rendering, implemented by three providers.

- **Google Maps Provider**: uses the Google Maps JavaScript API v3. Requires an API key with Maps JavaScript API and Geocoding API enabled. Cost: approx. 7 USD per 1,000 map loads after the free tier (28,000/month).
- **OpenStreetMap Provider**: uses Leaflet.js as the rendering library with OSM tiles. No API costs, no registration needed. Limitation: OSM tile servers have a fair-use limit. For websites with more than 50,000 page views per month, a dedicated tile server or a commercial provider like MapTiler is recommended.
- **Mapbox Provider**: premium option with custom map styles. Cost: 50,000 free map loads per month, then 0.50 USD per 1,000.

The extension stores map configurations (zoom, center, style) in its own database tables. Markers are created through relations to arbitrary TYPO3 records - maps2 is not limited to a specific record type. Through a TCA override, developers can link any table with map data.

Dependencies: TYPO3 Core (v11+), optionally geocoordinates for automatic geocoding of addresses. For frontend display, maps2 requires the JavaScript API of the chosen provider. For Google Maps, the API is loaded via an external script tag; for OpenStreetMap, Leaflet.js is shipped locally as a dependency.

## Common problems and solutions

**Map not displaying, only gray area.** With Google Maps, the API key is the problem in 90% of cases. Either it is missing, billing is not activated (Google has required a stored credit card since 2018), or the allowed domains in the API key do not match the website. Solution: check in the Google Cloud Console whether Maps JavaScript API is enabled and the key is authorized for the correct domain.

**Markers appear at wrong positions.** The cause is frequently incorrect or missing geocoding. When addresses lack coordinates, maps2 attempts to resolve them through the configured geocoding service. With imprecise addresses (e.g. only postal code without street), markers land in the city center instead of the actual location. Solution: correct coordinates through a one-time batch geocoding run and store them as fixed values in the record.

**Performance issues with more than 200 markers.** The JavaScript library renders each marker individually into the DOM. From 200 markers onward, this becomes noticeably slow on mobile devices. Solution: activate marker clustering and if necessary implement server-side filtering so only markers in the current map viewport are loaded.

## Migration and version compatibility

maps2 is actively maintained by Stefan Froemken and is available for TYPO3 v11 and v12 LTS. Compatibility with TYPO3 v13 is typically established shortly after the LTS release. The extension has a stable API and minimal breaking changes between major versions.

For those migrating from an older maps extension (e.g. wec_map, od_googlemaps or ke_daysspecial_map), the database structure must be adjusted. maps2 uses its own tables for map configuration that are not compatible with older extensions. A migration typically involves: coordinate export from the old extension, creating new maps2 records, linking with existing TYPO3 records.

When switching from Google Maps to OpenStreetMap (frequently for GDPR reasons), only the provider configuration in maps2 needs to be changed. Templates and marker data remain identical. Gosign has completed this switch for multiple clients in under one day. The GDPR motivation: Google Maps transfers personal data (IP address, browser fingerprint) to Google servers in the US. With OpenStreetMap, data stays in Europe and a consent banner for map services becomes unnecessary. For companies that embed maps on every page, this also improves user experience because the map is immediately visible without the visitor first consenting via the cookie banner.

--- Marquee TYPO3 - Scrolling Text/Ticker | Gosign ---
> Scrolling text/ticker band: news ticker, notice banners, announcements. Gosign implements CSS-based marquees without extension - more lightweight, performant.

## Lauftexte und Ticker-Bänder brauchen keine Extension, CSS löst das in 20 Zeilen

Das Marquee-Element kennt jeder aus den Anfängen des Webs: Scrollender Text, der von rechts nach links über die Seite läuft. Das HTML-`<marquee>`-Tag ist seit Jahren deprecated, aber der Effekt bleibt gefragt. News-Ticker, Hinweis-Banner ("Wartungsarbeiten am Samstag") und Event-Ankündigungen nutzen Lauftexte als Aufmerksamkeits-Mechanismus. Die marquee-Extension für TYPO3 liefert ein Content-Element, das diesen Effekt über JavaScript rendert. Gosign empfiehlt stattdessen eine rein CSS-basierte Lösung, die ohne Extension, ohne JavaScript und ohne Update-Pflicht auskommt.

Der Unterschied ist messbar: Die Extension lädt JavaScript, registriert ein Content-Element im TCA und braucht Fluid-Templates. Die CSS-Alternative ist eine einzige CSS-Animation (20 Zeilen) auf einem normalen Text-Content-Element. Performance, Barrierefreiheit und Wartungsaufwand sprechen klar für den CSS-Ansatz.

## Typical use cases include Wartungshinweise, Aktions-Banner und Sportergebnisse

Das häufigste Szenario ist der Hinweis-Banner auf Unternehmenswebsites. "Unser Büro ist vom 24.12. bis 02.01. geschlossen" oder "Jetzt anmelden: Webinar am 15. März". Der scrollende Text zieht Aufmerksamkeit auf sich, ohne ein Popup zu sein. Redakteure pflegen den Text im TYPO3-Backend und aktivieren oder deaktivieren den Banner über ein Start- und Enddatum.

Zweites Szenario: News-Ticker auf Nachrichtenportalen und Intranet-Startseiten. Die letzten drei bis fünf Schlagzeilen laufen als Ticker über den oberen Seitenrand. Jede Schlagzeile ist ein Link zur vollständigen Meldung. Die Geschwindigkeit ist so eingestellt, dass der Text lesbar bleibt (empfohlen: 30 bis 50 Pixel pro Sekunde).

Drittes Szenario: Sportergebnisse auf Vereinswebsites. Am Spieltag zeigt ein Ticker die aktuellen Ergebnisse aller Mannschaften. Die Daten kommen aus einer TYPO3-Tabelle oder einem externen Feed und werden als scrollender Text dargestellt. Die Kombination aus Lauftext und automatischer Aktualisierung (per AJAX alle 60 Sekunden) macht den Ticker zum Echtzeit-Informationskanal ohne die Komplexität einer vollständigen Liveticker-Extension.

## Technical architecture der Extension ist ein JavaScript-gesteuertes Content-Element

Die marquee-Extension registriert ein Content-Element im TYPO3-TCA, das Felder für Text, Geschwindigkeit, Richtung und Wiederholung enthält. Das Fluid-Template rendert ein Container-Element, und eine JavaScript-Datei initialisiert die Animation. Die Konfiguration (Geschwindigkeit, Pause bei Hover, Endlos-Wiederholung) wird über data-Attribute am Container-Element an das JavaScript übergeben.

Die CSS-Alternative funktioniert so: Ein normales Text-Content-Element bekommt eine CSS-Klasse (z.B. "marquee"), und die CSS-Animation @keyframes scroll verschiebt den Text von rechts nach links. Die Animation ist endlos, pausiert bei Hover (über :hover) und respektiert die prefers-reduced-motion-Einstellung des Betriebssystems, was für Barrierefreiheit relevant ist. Der gesamte Code:

```css
.marquee { overflow: hidden; white-space: nowrap; }
.marquee span { display: inline-block; animation: scroll 20s linear infinite; }
.marquee:hover span { animation-play-state: paused; }
@media (prefers-reduced-motion: reduce) { .marquee span { animation: none; } }
@keyframes scroll { from { transform: translateX(100%); } to { transform: translateX(-100%); } }
```

## Common problems include Barrierefreiheit, mobile Darstellung und SEO-Relevanz

Problem eins: Barrierefreiheit. Bewegte Inhalte sind für Menschen mit kognitiven Einschränkungen oder Epilepsie problematisch. Die WCAG 2.1 verlangt, dass Animationen pausierbar, stoppbar oder ausblendbar sind. Die Extension bietet eine Pause-bei-Hover-Funktion, aber keinen Stop-Button. Die CSS-Lösung respektiert automatisch die prefers-reduced-motion-Einstellung, was die Extension nicht tut.

Problem zwei: Mobile Darstellung. Auf Smartphones ist der verfügbare Platz für scrollenden Text minimal. Ein Ticker, der auf dem Desktop gut lesbar ist, rauscht auf dem Handy so schnell vorbei, dass niemand mitlesen kann. Die Lösung: Auf Mobilgeräten den Ticker durch einen statischen Banner ersetzen, der die wichtigste Meldung zeigt, ohne Animation.

Problem drei: SEO-Relevanz. Scrollender Text wird von Suchmaschinen zwar indexiert, aber die UX-Signale (kurze Verweildauer auf dem Ticker, keine Klicks) können sich negativ auf die Seitenqualität auswirken. Ticker-Inhalte sollten immer auch als normale Seiteninhalte verfügbar sein, nicht ausschliesslich im Ticker.

Ein viertes Problem: Barrierefreiheits-Konformität bei öffentlichen Einrichtungen. Das BFSG und die EN 301 549 verlangen, dass Animationen pausierbar und stoppbar sind. Ein Marquee ohne Stopp-Button oder Pause-Mechanismus verstösst gegen WCAG 2.2.2 (Pause, Stop, Hide). Die CSS-Lösung mit prefers-reduced-motion und :hover-Pause erfüllt diese Anforderung teilweise, ein expliziter Pause-Button wäre für volle Konformität nötig.

## Die Extension ist für aktuelle TYPO3-Versionen überflüssig

Die marquee-Extension hat keine offizielle Unterstützung für TYPO3 v12 oder v13. Da die CSS-Alternative in 15 Minuten implementiert ist und keine Extension-Abhängigkeit erzeugt, empfiehlt Gosign bei jeder Migration den Wechsel. Der Redakteur nutzt ein normales Text-Content-Element mit einer speziellen CSS-Klasse, die im Site-Package definiert ist. Das ist wartungsfrei, performant und barrierefrei.

Für Projekte, die mehrere Meldungen im Ticker rotieren lassen wollen, reicht eine erweiterte CSS-Animation, die mehrere Textblöcke nacheinander durchlaufen lässt. Alternativ kann ein minimales JavaScript (unter 20 Zeilen) die Texte aus einer JSON-Quelle nachladen und die Animation steuern. Beides ist architektonisch sauberer als eine Extension, die für einen Effekt ein komplettes TCA-Feld, ein Fluid-Template und eine JavaScript-Datei mitbringt. Bei Gosign setzen wir den CSS-Ansatz in allen Projekten ein, die einen Ticker oder Lauftext benötigen.

--- Mask TYPO3 - Custom Content Elements | Gosign ---
> Mask is the standard tool for custom content elements in TYPO3. Create backend masks without PHP: define fields, assign Fluid template, done.

## Editors need dedicated content elements, not another workaround with text fields

Every TYPO3 website reaches the point where the built-in content elements are no longer sufficient. A team carousel, a pricing table with toggles, a product teaser with image, text and CTA button - such requirements otherwise end up in the RTE as HTML soup or in an overcrowded FlexForm container. Mask solves this problem fundamentally: editors get custom backend masks with exactly the fields they need. No PHP classes, no hand-written TCA, no ext_tables.sql.

Mask has been the most widely used framework for custom content elements in TYPO3 since 2016. Over 1,500 active installations (as of Packagist, April 2026) and its inclusion in the official TYPO3 documentation as the recommended approach for custom content elements confirm its status as the de facto standard.

## Typical use cases

**Corporate websites with complex page structures.** Marketing teams need 15 to 30 different content elements: hero banners, testimonials, accordions, tabbed content, downloads with preview images, contact cards. Mask maps each of these as its own backend form. Editors see only the fields relevant to the respective element - no confusion from irrelevant options.

**Multilingual projects with consistent structure.** Mask elements fully support TYPO3 translation mechanisms. Fields can be configured as l10n_mode exclude (not translatable) or prefixLangTitle (translatable with indicator). For websites in 5+ languages, this saves editorial time because the structure remains identical and only the content is translated.

**Relaunch projects with existing data.** Organizations migrating from an older system (WordPress, TYPO3 with Gridelements or TemplaVoila) need clean content structures. Mask elements can be exported as standalone extensions via mask_export. This makes content definitions versionable and deployable through CI/CD pipelines.

## Technical architecture

Mask stores the configuration of all content elements in a single JSON file (`mask.json` or `config/mask.json` since Mask 8). This file describes fields, types, palettes and the mapping to Fluid templates. When activating or updating, Mask automatically generates the necessary TCA configurations and database fields.

The field types cover the full TYPO3 standard: String, Integer, Float, RichText, Date, DateTime, File (FAL), Inline (IRRE for nested structures), Select, Checkbox, Radio, Link, Slug, Color Picker, Tab, Palette. Since Mask 8, JSON-native fields and an improved API have been added.

Fluid templates reside by default under `fileadmin/templates/mask/` or in a configurable path. Each content element has its own template, optionally with Partials and Layouts. Mask registers the elements in the New Content Element Wizard, including icon and description.

Dependencies are minimal: Mask requires only the TYPO3 Core (v11, v12, v13 are actively supported). No additional extensions needed. For the export workflow, mask_export comes as an optional add-on.

## Common problems and solutions

**Field changes on production systems.** If a Mask field is changed on the staging system (type, field name) but the database on production is not updated, errors arise. Solution: use mask_export so that configuration changes travel through Git and deployment pipelines. Alternatively: run Database Compare in the Install Tool after every deployment.

**Performance with many content elements.** Websites with 40+ different Mask elements generate a large TCA configuration. TYPO3 loads this with every backend call. Solution: group elements sensibly, deactivate unused ones, keep the backend cache active. From Mask 8 onward, TCA generation is significantly more performant than in earlier versions.

**Nested elements (IRRE) and sorting.** Inline relations (e.g. slider slides within a slider element) sometimes lose their sort order during copy/paste. Solution: explicitly define a sorting field and secure `<f:for>` with `sortBy` in the Fluid template. In Mask 8.x, this behavior is more stable than in 7.x.

## Migration and version compatibility

Mask actively supports TYPO3 v12 and v13. The current stable version (Mask 8.x) runs on both LTS releases. TYPO3 v11 is covered by Mask 7.x but receives no new features.

For projects still running TemplaVoila or DCE, Mask offers a clear migration path. DCE elements can be manually converted to Mask: rebuild fields in the Mask GUI, adapt Fluid templates, migrate data via SQL script. Gosign has carried out this process on projects with 20+ DCE elements and estimated the effort at 2 to 5 days depending on complexity.

Starting with TYPO3 v13, the native Content Block API is also available. For existing Mask projects, there is no urgency: Mask and Content Blocks coexist without issues. New projects on pure TYPO3 v13 can evaluate whether the native approach is sufficient or whether Mask offers advantages through its GUI and export workflow. Gosign advises on a project-specific basis which approach produces the lowest long-term maintenance effort.

An often underestimated aspect is documentation. Mask elements are self-explanatory for developers (fields, types, templates), but editors need guidance: which fields are mandatory? What image dimensions are optimal? What happens if the description field is left empty? Since version 7, Mask supports description texts per field that appear as tooltips in the backend. Gosign additionally creates an internal editorial handbook per project documenting every Mask element with screenshot, field description and best practices. The effort is about half an hour per element but saves countless support queries during operation.

For the initial setup of a Mask project with 15 to 20 content elements, Gosign estimates 3 to 5 development days, including Fluid templates, backend preview and mask_export configuration. Individual new elements during ongoing operation take 1 to 4 hours, depending on nesting complexity and template design. For agencies using Mask as standard across all client projects, a library of reusable Mask elements pays off: basic teaser, accordion, tab container and hero banner, included in new projects as a Composer package via mask_export.

--- mask_export TYPO3 - Mask Deployment | Gosign ---
> Extension that exports Mask content element configurations as a standalone TYPO3 extension. Makes Mask elements versionable and deployable via Git/CI/CD.

## Without mask_export, Mask elements are not versionable and every deployment is a risk

Mask is the standard for custom content elements in TYPO3. But Mask stores its configuration in a JSON file and generates database fields at runtime. In a professional development process with multiple environments (local, staging, production), this creates a problem: how do new content elements get from the development machine to the production server? Manually recreating them in the backend? Copying mask.json via FTP and running Database Compare? Both are error-prone and not reproducible.

mask_export solves this problem. The extension exports all Mask definitions as a standalone TYPO3 extension with its own ext_tables.sql, TCA configurations and Fluid templates. This extension is installed via Composer, versioned through Git and deployed via CI/CD - just like any other TYPO3 extension. This makes Mask enterprise-ready.

## Typical use cases

**Agencies with CI/CD pipelines.** Agencies that deploy TYPO3 projects through GitLab CI, GitHub Actions or Deployer need versionable artifacts. mask_export produces an extension installable via `composer require`. Every change to a content element creates a new commit that runs through the pipeline: lint, tests, staging deploy, production deploy. No manual backend intervention needed.

**Multi-site projects with shared elements.** Corporations with 5 to 20 TYPO3 instances (country subsidiaries, brands, affiliates) want to use uniform content elements across all sites. mask_export produces a central extension that is included in all instances. Changes are made once and distributed to all sites. Without mask_export, Mask elements would have to be manually rebuilt on each instance.

**Handoff between development and editorial.** Developers define content elements on their local system, export them via mask_export and commit the result. Editors work on the staging or production system and use the elements without needing the Mask GUI. The Mask extension itself can even be uninstalled on production systems if only the exported extension is needed.

## Technical architecture

mask_export reads mask.json (or config/mask.json since Mask 8) and generates a complete TYPO3 extension. The generated structure contains: ext_emconf.php (extension metadata), ext_tables.sql (database definitions for all Mask fields), Configuration/TCA/Overrides/tt_content.php (TCA configuration), Resources/Private/Templates/ (Fluid templates, copied from the configured Mask template path) and optionally TypoScript setup for frontend rendering.

The export process runs as a TYPO3 CLI command: `php typo3/sysext/core/bin/typo3 mask:export`. The result is a directory that can be included as a Composer package or as a local extension in typo3conf/ext/. The Mask extension itself is no longer needed after export, as long as no new elements are created or existing ones modified.

Important: mask_export exports only the definition (fields, templates, TCA), not the content (the actual texts, images etc. in tt_content). The data remains in the database and is migrated independently.

## Common problems and solutions

**Export forgotten after a change.** A developer modifies a Mask field on the local system but commits only mask.json, not the new export. On staging, the TCA configuration is then missing. Solution: integrate the mask_export command into a Git hook (pre-commit) or into the CI pipeline. Gosign uses a check in the deployment pipeline that compares whether mask.json and the latest export are in sync.

**Fluid templates not included in the export.** mask_export copies templates from the configured path by default. If templates reside outside this path (e.g. in a custom theme package), they are not captured. Solution: store all Mask templates in a unified directory and reference it in the Mask configuration.

**Conflicts when both Mask and the exported extension are installed.** If both Mask and the exported extension are installed on the production system, duplicate TCA registrations can occur. Solution: on systems where editors do not create new elements, install only the exported extension and uninstall Mask. On development systems, both run in parallel, with the export overwriting the previous version.

## Migration and version compatibility

mask_export follows Mask's release cycle: when Mask supports a new TYPO3 version, mask_export is updated promptly. Currently TYPO3 v11, v12 and v13 are supported. The exported extension is compatible with the same TYPO3 version as the Mask version it was generated from.

For projects that want to switch to the native Content Block API on TYPO3 v13, mask_export can serve as an intermediate step: first export Mask elements (clean, file-based structure), then translate the exported TCA configurations into Content Block definitions. The effort per element is low (30 to 60 minutes) when the exported extension serves as reference. Gosign offers this migration path as a standardized service.

An often overlooked advantage of mask_export is testability. When content elements exist as a standalone extension, automated tests can be written: verify TCA configuration (are all fields correctly defined?), test template rendering (does the Fluid template produce valid HTML?) and validate the database schema (do column types match?). In a CI pipeline, such tests catch errors before they reach staging or production. Without mask_export, this kind of testing would only be possible through integration tests against a running TYPO3 instance.

For projects with 20+ Mask elements, Gosign recommends integrating the export process into the development workflow from the start. The initial setup effort (integrate CLI command into CI pipeline, create Git repository for the exported extension, adjust Composer configuration) is approximately 2 to 4 hours. After that, the workflow is fully automated and every Mask change flows into deployment without manual steps. Gosign delivers a preconfigured CI pipeline with mask_export integration as part of every new TYPO3 project setup, so the professional workflow is in place from day one.

--- Mask Twig TYPO3 - Templates | Gosign ---
> Twig or Nunjucks templates instead of Fluid for Mask content elements. For frontend developers who prefer Twig syntax or want to reuse existing templates.

## Why frontend developers prefer Twig over Fluid and how Mask makes it possible

TYPO3 uses Fluid as its template engine - a technology unique within the PHP world. That is simultaneously its strength and its biggest problem: frontend developers coming from the Symfony, Laravel or Node.js ecosystem know Twig or Nunjucks. They do not know Fluid. The mask_twig_nunjucks_connector bridges this gap by letting Mask content elements render with Twig or Nunjucks templates instead of Fluid templates.

For agencies whose frontend team works with Twig and has no desire to learn a new template language for every TYPO3 project, the connector is the pragmatic solution. Existing Twig partials from Symfony projects or Nunjucks components from pattern libraries can be reused directly.

## Typical use cases

**Agencies with Symfony backend and TYPO3 frontend.** An agency develops its web applications in Symfony and uses TYPO3 only for content management. The frontend team has built an extensive Twig component library. Instead of rewriting all components for TYPO3 in Fluid, the connector integrates the existing Twig templates directly into Mask content elements. A header component that exists in Symfony as `header.html.twig` works in TYPO3 without modification.

**Pattern library integration with Nunjucks.** A design team maintains a pattern library (e.g. based on Fractal or Storybook) that uses Nunjucks as its template language. The connector allows the same Nunjucks templates to be used both in the pattern library and in TYPO3. Design changes are made once in the pattern library and are automatically visible on the TYPO3 website.

**Frontend developer onboarding in TYPO3 projects.** A new frontend developer joins a TYPO3 project. Instead of first learning Fluid (syntax, namespaces, ViewHelper concept), they write Twig templates they already master. The project learning curve shrinks from 2 to 3 days to a few hours.

## Technical architecture

The mask_twig_nunjucks_connector functions as a rendering bridge between the Mask extension and an alternative template engine. Mask defines custom content elements with backend fields (text, images, relations). By default, Mask renders these elements with Fluid templates. The connector replaces this rendering step.

The technical implementation:

- **Twig integration**: the connector uses the PHP library `twig/twig` (the same one Symfony uses). Twig templates are placed in the file system, typically under `Resources/Private/Twig/`. Mask fields are available as template variables (`{{ data.header }}`, `{{ data.bodytext }}`).
- **Nunjucks integration**: Nunjucks is the JavaScript counterpart to Twig (nearly identical syntax). The connector can render Nunjucks templates server-side via a Node.js bridge or deliver them client-side as JavaScript templates. The server-side variant requires Node.js on the server.
- **Variable mapping**: Mask fields are automatically mapped to template variables. Simple fields (text, integer, float) are passed directly. FAL references (images, files) are passed as objects with URL, title and alt text. Relations are resolved as arrays.

Dependencies: TYPO3 Core, Mask extension, Composer package `twig/twig` (for Twig) or Node.js (for server-side Nunjucks). The extension is not available in the official TER but is installed via GitHub/Packagist. The Twig integration is considerably more mature than the Nunjucks variant because Twig runs natively in PHP and requires no external process. In practice, over 90% of connector installations use Twig, not Nunjucks.

## Common problems and solutions

**Twig template has no access to TYPO3-specific data.** Fluid ViewHelpers like `f:uri.page`, `f:translate` or `f:cObject` do not exist in Twig. A Twig template cannot directly access the TYPO3 page tree, translations or other content elements. Solution: all required data must be provided through the variable mapping. The connector can inject additional data (current language, page URL, global settings) into the template context through configuration. For complex TYPO3 functionality, a custom Twig extension point must be written.

**Nunjucks rendering is slow.** The Node.js bridge for server-side Nunjucks rendering starts a Node process for each request. This is not noticeable with individual content elements, but with pages containing 10+ Mask elements, rendering times add up. Solution: use a persistent Node.js worker process (instead of starting a new one per request) or switch to Twig, which renders natively in PHP and requires no external process.

**Mask update breaks template variable names.** When Mask renames a field or a field type is changed, template variables change. Fluid templates show empty spots; Twig templates throw errors. Solution: run Twig in strict mode (`strict_variables: true`) and test templates against the updated variables after every Mask update.

## Migration and version compatibility

The mask_twig_nunjucks_connector is a community project with limited adoption. Compatibility depends on the Mask extension: Mask itself is actively maintained and supports TYPO3 v11 and v12. The connector must be checked for compatibility with every Mask update because it hooks into internal rendering processes.

For TYPO3 v13, the long-term perspective is unclear. The TYPO3 community is investing heavily in Fluid development (Fluid 4.0, Standalone Fluid). At the same time, pressure grows from frontend developers who prefer Twig as the template standard.

Gosign recommends the connector for projects where the frontend team works exclusively with Twig and brings an existing component library. For pure TYPO3 projects without external template requirements, Fluid remains the better choice because it is natively supported, has no additional dependencies and can use the entire TYPO3 ViewHelper library. The productivity gain from Twig reuse must outweigh the maintenance effort for the connector - a tradeoff that should be concretely quantified at every project start. With fewer than 10 Mask elements, the connector rarely pays off; with 30+ elements and an existing Twig library, it almost always does.

--- mathguard TYPO3 - Math CAPTCHA | Gosign ---
> Mathematical CAPTCHA for TYPO3: simple math problems instead of image CAPTCHAs. Accessible (screen reader compatible), without external services.

## Mathe-CAPTCHAs include der barrierefreie Spam-Schutz, den die meisten Websites nicht kennen

Spam in Kontaktformularen ist ein Dauerthema. Die populärste Lösung ist Google reCAPTCHA, das aber Nutzerdaten an Google sendet und die GDPR compliance verkompliziert. Bild-basierte CAPTCHAs ("Klicken Sie alle Ampeln an") frustrieren Nutzer und sind für Screenreader unzugänglich. mathguard geht einen anderen Weg: Die Extension zeigt eine einfache Rechenaufgabe ("Was ist 3 + 7?") im Formular an. Menschen lösen das in Sekunden, automatisierte Bots scheitern in der Mehrzahl. Kein externes JavaScript, keine Cookies, keine Datenübertragung an Dritte, vollständig Screenreader-kompatibel.

Für öffentliche Einrichtungen, Hochschulen und Unternehmen mit Barrierefreiheits-Anforderungen (BITV 2.0, WCAG 2.1) ist mathguard eine der wenigen CAPTCHA-Lösungen, die sowohl Spam-Schutz als auch Accessibility garantiert. Die Spam-Reduktion liegt bei 85 bis 95% des eingehenden Bot-Traffics. Im Vergleich: Google reCAPTCHA v3 erreicht ähnliche Werte, überträgt aber bei jedem Seitenaufruf Daten an Google-Server, auch ohne Formular-Interaktion.

## Typical use cases include Kontaktformulare, Kommentarfunktionen und Registrierungen

Das Standardszenario ist das Kontaktformular auf einer Unternehmenswebsite. Ohne Spam-Schutz landen täglich 20 bis 200 Bot-Einreichungen im Postfach der Redaktion. mathguard fügt ein Rechenfeld hinzu, das im Formular zwischen E-Mail-Feld und Absende-Button platziert wird. Die Rechenaufgabe wird bei jedem Seitenaufruf zufällig generiert, sodass Bots die Lösung nicht vorberechnen können.

Zweites Szenario: Kommentarfunktionen auf Blogs und News-Seiten. Wenn Besucher Kommentare zu Artikeln hinterlassen können, ist Spam unvermeidlich. mathguard schützt das Kommentarformular, ohne dass Besucher ein Google-Account oder eine spezielle App brauchen.

Drittes Szenario: Benutzer-Registrierungen. Wenn eine Website Frontend-Accounts anbietet (z.B. für ein Kundenportal oder einen geschützten Download-Bereich), schützt mathguard das Registrierungsformular vor automatisierten Account-Erstellungen. Die Rechenaufgabe ist die letzte Hürde vor dem Absenden, zusätzlich zum Double-Opt-In.

## Technical architecture generates serverseitige Rechenaufgaben mit Session-Validierung

mathguard arbeitet komplett serverseitig. Bei jedem Formular-Aufruf generiert die Extension eine zufällige Rechenaufgabe (Addition, Subtraktion oder Multiplikation mit einstelligen Zahlen). Die korrekte Lösung wird in der PHP-Session gespeichert, nicht im HTML-Code. Das ist entscheidend: Wenn die Lösung als Hidden Field im Formular stehen würde, könnte jeder Bot sie auslesen.

Die Integration in TYPO3-Formulare funktioniert über einen ViewHelper oder ein Fluid-Partial, das in bestehende Formular-Templates eingefügt wird. Für powermail und das TYPO3 Form Framework gibt es Konfigurationsbeispiele, die die Einbindung in 10 bis 15 Minuten ermöglichen.

Die Rechenaufgabe wird als Text dargestellt ("Was ist 5 + 3?"), nicht als Bild. Das macht sie automatisch Screenreader-kompatibel: Vorlese-Software kann die Aufgabe vorlesen, und der Nutzer gibt die Lösung in ein normales Textfeld ein. Es gibt keine visuellen Verzerrungen, keine Farb-Kontrast-Probleme und keine Timeout-Limitierungen.

Für zusätzliche Sicherheit kann mathguard mit einem Honeypot-Feld kombiniert werden: Ein unsichtbares Formularfeld, das von Bots ausgefüllt wird, aber von echten Nutzern ignoriert. Ergänzend lässt sich eine Zeitstempel-Validierung einsetzen: Wenn ein Formular in unter 3 Sekunden ausgefüllt wird, ist es mit hoher Wahrscheinlichkeit ein Bot. Die Kombination aus Mathe-CAPTCHA, Honeypot und Zeitstempel-Check erreicht eine Spam-Reduktion von über 99%.

## Common problems include clevere Bots, Session-Verlust und UX-Irritation

Problem eins: Fortgeschrittene Bots, die Rechenaufgaben lösen. Einfache Text-Parsing-Bots können "Was ist 3 + 7?" interpretieren und die richtige Antwort "10" eingeben. Die Lösung: Die Aufgabe als leicht obfuskierten Text darstellen ("Drei plus sieben ergibt?") oder die Aufgabe um einen Kontext erweitern ("Wie viele Beine hat ein Stuhl minus eins?"). mathguard in der Standardkonfiguration nutzt numerische Aufgaben, was für 85 bis 95% der Bots ausreicht.

Problem zwei: Session-Verlust. Wenn die PHP-Session zwischen Formular-Aufruf und Absenden verloren geht (z.B. durch Load-Balancer ohne Session-Stickiness), schlägt die Validierung fehl, obwohl der Nutzer die richtige Antwort eingegeben hat. Die Lösung: Session-Stickiness im Load-Balancer konfigurieren oder die Session-Daten in der Datenbank statt im Dateisystem speichern.

Problem drei: UX-Irritation bei Nutzern. Manche Besucher empfinden eine Rechenaufgabe als herablassend ("Muss ich beweisen, dass ich rechnen kann?"). Die Lösung: Einen freundlichen Hinweis über dem Feld platzieren ("Spam-Schutz: Bitte lösen Sie diese kurze Aufgabe") und die Aufgabe visuell unauffällig in das Formular-Design integrieren.

## mathguard works mit allen TYPO3-Versionen, weil die Technik minimal ist

Die Extension hat keine tiefen API-Abhängigkeiten zum TYPO3-Core. Session-Handling, Formular-Rendering und Validierung nutzen Standard-PHP- und TYPO3-Funktionen, die sich über Versionen hinweg kaum ändern. mathguard ist mit TYPO3 v10, v11 und v12 kompatibel und wird voraussichtlich auch unter v13 funktionieren, eventuell mit minimalen Anpassungen im ViewHelper. Für Projekte, die komplett ohne Extension auskommen wollen, lässt sich die gleiche Logik als Custom Validator im TYPO3 Form Framework oder als powermail-Finisher in unter einer Stunde nachbauen. Gosign implementiert in eigenen Projekten eine Kombination aus Honeypot, Zeitstempel-Validierung und optionalem Mathe-CAPTCHA als dreistufigen Spam-Schutz, der ohne externe Dienste auskommt und bei über 99% der automatisierten Angriffe wirksam ist. Die Entscheidung, ob das Mathe-CAPTCHA sichtbar ist oder nur als unsichtbarer Fallback greift, treffen wir projektspezifisch basierend auf dem erwarteten Spam-Volumen und den Barrierefreiheits-Anforderungen.

--- md_news_author TYPO3 - News Authors | Gosign ---
> Author extension for GeorgRinger/news. Author profiles, author archives and Schema.org Person markup. For news sites with multiple editors.

## md_news_author gives editors a face and search engines a schema

GeorgRinger/news is the de facto standard extension for editorial systems in TYPO3, but it only knows a simple author text field. For news sites with multiple authors that is not enough: anyone who runs a serious magazine needs author profile pages, structured biographies and Schema.org/Person markup for E-E-A-T. This is exactly the gap that md_news_author from Mehrwert-Digital fills, and that is why the extension ends up in the composer.json of almost every mid-sized TYPO3 editorial project. Since Google tightened its E-E-A-T guidelines in 2022 and started evaluating author profiles as a ranking signal, the extension is no longer just a comfort feature but a measurable SEO factor for any newsroom with more than three authors.

## Typical use cases are online magazines, specialist publishers and university newsrooms

Specialist publishers are the classic audience. A legal publisher with 40 authors wants a dedicated detail page per author with picture, short biography, areas of expertise, LinkedIn profile and a list of all articles by that author, for SEO reasons and because Google rewards E-E-A-T. md_news_author delivers all of this from a single record. In addition, the extension allows filtering authors by area of expertise, so that editors can find the right experts directly while researching topics.

University newsrooms use the extension to attribute press releases from the communications office to the actual researchers. The press release appears under the name of the respective chair holder, links to their institute page and is signalled to Google via Person schema. For citations and Google Scholar this is not just cosmetic but a ranking factor. We have implemented md_news_author, for example, at a medical research institute with 18 research groups, where every press release is attributed to the participating group and its members. The extension links news content with researcher profiles and thereby creates a structured foundation for academic reputation on the web.

A third scenario is corporate blogs and thought leadership formats in which executives appear as authors. The extension cleanly separates FE users (login) from authors (profile), so that biographies can also be maintained for guest authors without a TYPO3 account. For corporate newsrooms with a ghostwriter setup, this separation is decisive: the communications editor writes the text but publishes it under the name of the executive, without that executive needing a backend login.

## Technical architecture extends GeorgRinger/news via TCA overrides

md_news_author is a pure addition to ext:news. It does not bring its own output logic but registers the "authors" field via TCA override as a relation to a new table tx_mdnewsauthor_domain_model_author. Every author is a standalone record with first name, last name, title, slug, biography, image, LinkedIn, X, email and internal notes. The relation is MM-typed, so an article can have several authors and conversely an author can be involved in any number of articles.

Integration with Fluid templates runs through ViewHelpers: {author.fullName}, {author.jobTitle}, {author.image} and {author.url}. For list and detail views, the extension ships ready-made partials that can be overridden via the TypoScript package system. The slug is automatically generated from first and last name and is editable. Routing for author detail pages runs through an enhancer pattern in the site config that enables URLs such as /author/jane-doe/ without any additional page structure.

Schema.org/Person markup is generated via a JSON-LD ViewHelper and can be embedded into the news article schema. Google Search then recognises the author, links them across multiple articles and adds them to the knowledge graph context of the magazine. The ViewHelper output is compatible with the Google structured data testing tool and covers the most important Person attributes: name, jobTitle, image, url, sameAs and worksFor.

## Common problems involve storage pages and slug collisions

The classic stumbling block is the storage page configuration. md_news_author expects the author records to live on a dedicated sysfolder that is registered in the TypoScript of the news plugin. If the entry is missing, the plugin shows no authors and editors are puzzled. On setup we place the sysfolder under /Configuration/News authors and reference it in the plugin flexform. In multi-site installations, the sysfolder has to be maintained per site, so that authors remain attributed to a specific brand.

A second common issue are slug collisions with other tables. If md_news_author runs alongside ext:sf_register or a custom person model, both often share the same URL structure. We recommend deliberately setting the routing prefix to /author/ and registering the slug generation in the site config YAML. Alternatively, the routing enhancer can be configured per language, which is especially important in multilingual installations with different path prefixes ("/author/" EN, "/autor/" DE).

Thirdly, images require a defined image size. md_news_author delivers the FAL reference, but the cropping variants have to be maintained in TSconfig under TCEFORM.tx_mdnewsauthor_domain_model_author.image. Without that, the cropping ViewHelper in the detail template falls back to the unedited original image. We recommend defining at least three cropping variants (square, portrait, landscape) and delivering them responsively in the Fluid template.

## Migration to TYPO3 v12 requires a Fluid update

md_news_author is stable for TYPO3 v11 and v12. On the jump to v12, custom Fluid templates have to be moved to the new namespace ({namespace md=Mehrwert\\MdNewsAuthor\\ViewHelpers}) and the revised ViewHelper system. Anyone coming from an old 2.x version should also review the TCA overrides, because several field names have been renamed. The biography field and the social media links in particular gained additional properties in newer versions that would be ignored in old templates.

In ongoing projects, Gosign typically migrates md_news_author in the same step as the news core upgrade and the Schema.org markup. This keeps the article page consistent during the transition, and the Person markup is lifted to the current Schema.org specification at the same time. In the same step, we check whether the author profiles contain a complete sameAs list with verified social media accounts, because Google uses that link for knowledge graph matching.

--- Mega Menu TYPO3 - Navigation | Gosign ---
> Multi-column dropdown navigation with images, teasers and CTAs. Enterprise navigation for complex site structures. Gosign builds responsive mega menus.

## Komplexe Website-Strukturen mit 200+ Seiten brauchen eine Navigation, die mehr zeigt als Textlisten

Websites mit drei oder mehr Navigationsebenen und über 200 Seiten stossen mit einem Standard-Dropdown-Menü an Grenzen. Besucher klicken sich durch verschachtelte Listen, verlieren die Orientierung und brechen ab. Ein Mega-Menu löst das Problem: Beim Hover oder Klick auf einen Hauptpunkt öffnet sich ein mehrstufiges Panel mit Spalten, Bildern, Teasern und direkten CTAs. Die megamenu-Extension bringt dieses Navigationskonzept als konfigurierbares Content-Element in TYPO3. Redakteure pflegen die Menü-Inhalte (Bilder, Teaser-Texte, Links) im Backend, die Extension rendert das Mega-Menu im Frontend.

Für Enterprise-Websites mit komplexem Produktportfolio, Branchen-Portale mit regionalen Unterbereichen oder Hochschulen mit Fakultätsstrukturen ist ein Mega-Menu nicht optional, sondern Voraussetzung für brauchbare Navigation. Die Herausforderung liegt nicht in der Anzeige, sondern in Barrierefreiheit, Responsive-Verhalten und Performance.

## Typical use cases include Unternehmenswebsites, E-Commerce und Hochschulportale

Das Standardszenario ist die Unternehmenswebsite mit 5 bis 8 Hauptkategorien und jeweils 10 bis 30 Unterpunkten. Ein Maschinenbauer zeigt unter "Produkte" fünf Produktlinien mit je sechs Produktgruppen, ergänzt durch ein Keyvisual und einen Link zum Produktkonfigurator. Unter "Branchen" erscheinen acht Branchenseiten mit Kurztext und Icon. Das Mega-Menu macht diese Struktur auf einen Blick erfassbar, ohne dass der Besucher sich durch Unterlisten klicken muss.

Zweites Szenario: E-Commerce-Websites mit breitem Sortiment. Ein Online-Shop mit 500+ Produkten in 20 Kategorien zeigt im Mega-Menu die Hauptkategorien mit Unterkategorien, Bestsellern und Aktionslinks. Die visuelle Darstellung mit Produktbildern im Menü steigert die Klickrate auf Kategorie-Seiten um geschätzte 10 bis 20% gegenüber reinen Textlisten.

Drittes Szenario: Hochschulportale mit Fakultäts- und Institutsstruktur. Eine Universität mit 12 Fakultäten und dutzenden Instituten braucht eine Navigation, die sowohl die organisatorische Struktur als auch funktionale Bereiche (Studium, Forschung, Karriere) abbildet. Das Mega-Menu zeigt unter "Studium" die Studiengangsuche, Bewerbungsinformationen und Fristen, unter "Fakultäten" die Institute mit direkten Links zu Mitarbeitern und Forschungsprojekten.

## Technical architecture combines TYPO3-Seitenbaum mit zusätzlichen Content-Elementen

Die megamenu-Extension erweitert die TYPO3-Navigation um ein Content-Element, das im Seitenbaum als Menü-Konfiguration angelegt wird. Jeder Hauptmenü-Punkt kann ein Mega-Menu-Panel zugeordnet bekommen, das aus Spalten besteht. Jede Spalte enthält Links, Bilder, Rich-Text-Blöcke oder benutzerdefinierte Content-Elemente.

Die Rendering-Logik erzeugt ein HTML-Konstrukt aus verschachtelten Listen und div-Containern, das per CSS als mehrstufiges Panel gestylt wird. Die JavaScript-Komponente steuert das Öffnen und Schliessen (Hover auf Desktop, Klick auf Touch-Geräten) und die Keyboard-Navigation (Tab, Enter, Escape, Pfeiltasten). ARIA-Attribute (aria-expanded, aria-haspopup, role="menu") machen das Menu für Screenreader navigierbar.

Die Performance-Implikation ist relevant: Ein Mega-Menu mit Bildern und Teasern für 8 Hauptpunkte generiert deutlich mehr HTML als ein Standard-Menü. Lazy Loading für Bilder im Mega-Menu ist Pflicht, damit die initiale Seitenladezeit nicht leidet. Gosign empfiehlt, Mega-Menu-Inhalte erst beim Hover per AJAX nachzuladen, wenn das Panel mehr als 5 Bilder pro Hauptpunkt enthält.

## Common problems involve Accessibility, Mobile-Verhalten und Redaktions-Komplexität

Problem eins: Accessibility-Mängel. Viele Mega-Menu-Implementierungen sind mit der Tastatur nicht navigierbar. Tab springt über das gesamte Panel, statt durch die Menüpunkte zu iterieren. Escape schliesst das Panel nicht. Focus-Styles fehlen. Die Lösung: WAI-ARIA Authoring Practices für Navigation Menus befolgen, Keyboard-Handling explizit implementieren und die Focus-Management-Logik mit einem Screenreader testen (NVDA, VoiceOver).

Problem zwei: Mobile-Verhalten. Auf Smartphones wird ein Mega-Menu zum Hindernis, weil das Panel den gesamten Bildschirm einnimmt und der Besucher nicht mehr zum Seiteninhalt zurückkehren kann. Die Lösung: Auf Mobilgeräten das Mega-Menu durch eine Akkordeon-Navigation ersetzen, die die gleichen Inhalte in einer vertikalen Struktur darstellt. Die Umschaltung erfolgt über CSS Media Queries und eine separate JavaScript-Logik für Touch-Geräte.

Problem drei: Redaktions-Komplexität. Redakteure müssen Bilder, Texte und Links für jedes Mega-Menu-Panel pflegen. Ohne klare Richtlinien entstehen inkonsistente Panels: Eins hat vier Spalten mit Bildern, das nächste eine Spalte mit 30 Links. Die Lösung: Eine Content-Guideline, die maximale Spaltenanzahl, Bildformate und Textlängen pro Panel definiert. Gosign liefert diese Guideline als Teil des Mega-Menu-Projekts mit und konfiguriert die Backend-Felder so, dass Redakteure innerhalb der definierten Grenzen arbeiten (z.B. maximal 4 Spalten, maximal 8 Links pro Spalte, Bildformat 16:9).

Ein weiteres Thema ist die SEO-Implikation: Mega-Menus mit vielen Links erhöhen die Gesamtzahl der internen Links pro Seite. Wenn jede Seite 200+ Links im Mega-Menu hat, verdünnt das den Link-Juice, der an einzelne Zielseiten fliesst. Die Lösung: Mega-Menu-Inhalte selektiv laden und nicht alle Panels gleichzeitig im HTML rendern, oder strategisch unwichtige Links mit tabindex="-1" von der Crawler-Navigation ausschliessen.

## TYPO3 v12 requires Anpassungen, Custom-Implementierungen include langfristig wartbarer

Die megamenu-Extension muss bei einem Upgrade auf TYPO3 v12 angepasst werden, da sich die TCA-Konfiguration und das Content-Element-Handling geändert haben. Für v13 liegt noch keine offizielle Unterstützung vor. Gosign baut Mega-Menus in neuen Projekten als Custom-Komponente im Site-Package, die den TYPO3-Seitenbaum als Datenquelle nutzt und die Menü-Konfiguration über Page Properties oder Backend Layouts steuert. Das eliminiert die Abhängigkeit von der Extension und gibt volle Kontrolle über HTML-Struktur, Accessibility und Performance.

--- Microtemplate TYPO3 | Gosign ---
> Micro template engine for TYPO3: small text blocks with variable substitution. Simpler than Fluid for simple string templating tasks.

## Fluid ist manchmal Overkill, wenn man nur einen String mit Variablen füllen will

Nicht jedes Template-Problem braucht die volle Fluid-Engine. Wenn eine E-Mail-Betreffzeile "Hallo {name}, Ihre Bestellung #{orderNumber}" lauten soll oder ein Snippet im Footer "Letzte Aktualisierung: {date}" anzeigen soll, ist Fluid mit ViewHelpers, Layouts und Partials architektonischer Overhead. microtemplate liefert eine minimale Template-Engine für TYPO3, die Variablen in Textbausteinen ersetzt. Kein Fluid, kein TypoScript-Objekt-Pfad, kein Template-File. Ein String mit Platzhaltern, ein Array mit Werten, fertig.

Die Extension ist ein Nischenwerkzeug für Entwickler, die in Extensions oder TypoScript-Konfigurationen einfache String-Substitutionen brauchen, ohne die Fluid-Rendering-Pipeline zu starten. Für Redakteure ist microtemplate nicht direkt sichtbar, es arbeitet im Hintergrund als Utility. Der Anwendungsbereich ist bewusst eng: Wo Fluid die richtige Wahl für komplexe Templates mit Schleifen, Bedingungen und Vererbung ist, deckt microtemplate den simplen Fall ab, in dem ein fertiger String an drei Stellen einen dynamischen Wert braucht.

## Typical use cases include E-Mail-Texte, dynamische Snippets und Konfigurations-Templates

Das häufigste Szenario ist die Generierung von E-Mail-Texten in Extensions. Eine Custom-Extension verschickt Bestätigungs-Mails, und der Betreff und Body sollen konfigurierbar sein, ohne dass der Entwickler Fluid-Templates anlegen muss. microtemplate liest den Text aus einer TypoScript-Konstante ("Bestellung #{orderNumber} bestätigt") und ersetzt die Platzhalter mit den aktuellen Werten.

Zweites Szenario: Dynamische Text-Snippets in TypoScript-Konfigurationen. Ein Seitentitel-Pattern wie "{siteName} - {pageTitle} | {category}" wird über microtemplate aufgelöst. Das ist einfacher als ein COA mit mehreren TEXT-Objekten und stdWrap-Funktionen.

Drittes Szenario: Konfigurations-Templates für Third-Party-Integrationen. Wenn eine Extension einen API-Endpoint konfigurierbar macht ("https://api.example.com/{version}/users/{userId}"), kann microtemplate die Platzhalter vor dem API-Call ersetzen. Das ist besonders nützlich für Extensions, die mehrere API-Umgebungen (Staging, Production) unterstützen und die Endpoint-Struktur nicht im Code, sondern in der TypoScript-Konfiguration pflegen wollen.

Ein viertes Szenario, das in der Praxis gelegentlich auftaucht: Log-Nachrichten mit strukturiertem Format. Eine Extension schreibt "Import von {count} Datensätzen aus {source} abgeschlossen um {time}" ins TYPO3-Log. microtemplate macht den Log-Text konfigurierbar, ohne dass der Entwickler sprintf-Aufrufe mit positionsbasierten Argumenten pflegen muss.

## Technical architecture ist eine einzige PHP-Klasse mit String-Replacement

microtemplate besteht im Kern aus einer einzigen PHP-Klasse, die str_replace oder preg_replace auf einem Template-String ausführt. Die Platzhalter folgen einer definierbaren Syntax (Standard: {variableName}). Ein assoziatives Array liefert die Werte. Die Klasse hat keine Abhängigkeiten ausser dem PHP-String-Handling.

Die Integration in TYPO3 erfolgt über einen Service oder eine statische Methode, die in anderen Extensions oder TypoScript-Konfigurationen aufgerufen wird. Es gibt kein Frontend-Plugin, kein Backend-Modul und kein Content-Element. microtemplate ist reine Infrastruktur für Entwickler.

Die Performance ist vernachlässigbar: Ein str_replace auf einem 500-Zeichen-String mit 5 Variablen dauert weniger als 0,01ms. Im Vergleich dazu startet die Fluid-Engine für das gleiche Ergebnis einen vollständigen Rendering-Zyklus mit Template-Parsing, ViewHelper-Instanziierung und Caching, was bei 1 bis 5ms liegt. In einem typischen Page-Rendering-Prozess fällt dieser Unterschied nicht auf, aber in Schleifen, die 1.000 E-Mails oder 500 Log-Einträge generieren, wird der Performance-Vorteil messbar.

Die Extension hat keine Datenbank-Tabellen, keine Backend-Module und keine Frontend-Plugins. Sie wird über Composer oder den Extension-Manager installiert und ist sofort einsetzbar. Das macht microtemplate zu einer der leichtgewichtigsten Extensions im gesamten TER (TYPO3 Extension Repository).

## Common problems include fehlende Escaping-Logik, Syntax-Konflikte und mangelnde Dokumentation

Problem eins: Kein automatisches HTML-Escaping. microtemplate ersetzt Platzhalter 1:1, ohne den eingesetzten Wert zu escapen. Wenn ein Nutzername HTML-Tags enthält ("<script>alert('XSS')</script>"), wird das direkt in den Output geschrieben. Die Lösung: Werte vor dem Einsetzen manuell escapen (htmlspecialchars) oder microtemplate nur für interne, nicht nutzergenerierte Daten verwenden.

Problem zwei: Syntax-Konflikte mit Fluid. Wenn microtemplate-Platzhalter ({variable}) in einem Kontext verwendet werden, in dem auch Fluid rendert, versucht Fluid die Platzhalter aufzulösen und wirft einen Fehler. Die Lösung: Unterschiedliche Platzhalter-Syntax verwenden (z.B. {{variable}} oder %variable%) oder sicherstellen, dass microtemplate vor Fluid ausgeführt wird.

Problem drei: Mangelnde Dokumentation und Community-Support. microtemplate ist eine Nischen-Extension mit minimaler Nutzerbasis. Bei Problemen gibt es keine aktive Community, kein Issue-Tracking und keine Stack-Overflow-Antworten. Entwickler müssen den Quellcode lesen, um das Verhalten zu verstehen. In der Praxis führt das dazu, dass jeder Entwickler im Team die Extension anders nutzt, weil keine Konventionen dokumentiert sind.

Ein weiteres Thema: Debugging. Wenn ein Platzhalter nicht ersetzt wird, weil der Key im Array nicht exakt mit dem Platzhalter-Namen übereinstimmt (Gross-/Kleinschreibung, Leerzeichen), gibt microtemplate keine Warnung aus. Der Platzhalter bleibt einfach stehen, und der Entwickler sucht den Fehler an der falschen Stelle. Ein Debug-Modus, der nicht aufgelöste Platzhalter loggt, wäre hilfreich, fehlt aber.

## Die Extension ist TYPO3-versionsunabhängig, aber für moderne Projekte gibt es bessere Alternativen

Da microtemplate nur Standard-PHP-Funktionen nutzt, funktioniert die Extension prinzipiell mit jeder TYPO3-Version von v7 bis v13. Die Frage ist eher, ob sie noch nötig ist: Seit PHP 8.0 bietet Named Arguments in Kombination mit sprintf oder str_replace die gleiche Funktionalität ohne Extension. Für komplexere Templates ist Fluid trotz des Overheads die bessere Wahl, weil es Caching, Escaping und Template-Vererbung mitbringt. Gosign setzt microtemplate in Bestandsprojekten nicht aktiv ein und empfiehlt bei Neuimplementierungen, die Funktionalität direkt in der eigenen Extension oder im TypoScript über stdWrap abzubilden.

--- news TYPO3 - Blog & News System | Gosign ---
> Georg Ringer's tx_news: The most widely used TYPO3 extension. News, blog, press releases. Update, migration, templating. AI-accelerated.

## tx_news ist die Extension, ohne die kein TYPO3-Projekt auskommt

Über 80% aller TYPO3-Installationen setzen tx_news von Georg Ringer ein. Das allein wäre eine beeindruckende Zahl, aber sie unterschätzt die Bedeutung der Extension: tx_news ist nicht nur ein News-Plugin, sondern das Fundament für Blogs, Magazine, Pressebereiche, Event-Listen, Mitarbeiterverzeichnisse und jede andere Art von strukturiertem, chronologischem Content in TYPO3. Die Extension liefert Kategorien, Tags, Media-Assets, SEO-Felder (Canonical, OpenGraph, Schema.org), Paginierung und Import/Export aus einer einzigen, aktiv gepflegten Codebasis. Wer in TYPO3 redaktionelle Inhalte veröffentlicht, kommt an tx_news nicht vorbei.

Gosign hat tx_news in hunderten Projekten konfiguriert, erweitert und migriert. Von Fluid-Templates über Custom ViewHelpers bis zur vollständigen Migration von tt_news. Die Extension ist fester Bestandteil jedes TYPO3-Setups, das wir ausliefern.

## Typical use cases reichen vom Unternehmens-Blog bis zur Pressedatenbank

Das häufigste Szenario ist der Unternehmens-Blog oder das Online-Magazin. Redakteure pflegen Artikel im TYPO3-Backend mit Titel, Teaser, Body, Kategorien, Tags und Medien. Die Listenansicht zeigt Teaser mit Bild, die Detailansicht den vollständigen Artikel. SEO-relevante Felder wie Meta-Description, Canonical URL und OpenGraph-Bild werden pro Artikel gepflegt. Eine typische Installation hat 100 bis 5.000 Artikel und wächst um 2 bis 10 Artikel pro Woche.

Zweites Szenario: Pressemitteilungen für Investor Relations und Unternehmenskommunikation. Börsennotierte Unternehmen und Konzerne veröffentlichen Pflichtmitteilungen über den Pressebereich ihrer Website. tx_news liefert die Chronologie, Kategorisierung (Ad-hoc-Meldung, Quartalsbericht, Personalie) und Download-Funktion für angehängte PDFs. Die Archivfunktion stellt sicher, dass auch Meldungen von vor zehn Jahren noch auffindbar sind.

Drittes Szenario: Event-Listen und Veranstaltungskalender. tx_news kann Start- und Enddaten für Einträge verwalten, was es zum einfachen Veranstaltungskalender macht. Für Vereine, Kultureinrichtungen und Bildungsträger reicht das oft aus, ohne dass eine spezialisierte Event-Extension wie sf_event_mgt nötig ist. Erst wenn Anmeldefunktionen, Teilnehmer-Management oder Ticketing gebraucht werden, stösst tx_news an seine Grenzen.

## Technical architecture separates Daten, Konfiguration und Darstellung konsequent

tx_news speichert Artikel als Extbase-Records in der Tabelle tx_news_domain_model_news. Jeder Record enthält Pflichtfelder (Titel, Datetime, Typ) und optionale Felder (Teaser, Body, Author, Tags, Categories, Media, Related News). Die Relationen zu Kategorien und Tags laufen über MM-Tabellen, was performante Filterung ermöglicht.

Die Konfiguration erfolgt über TypoScript: Template-Pfade, Sortierung, Paginierung, Kategorie-Filter, Detail-Seiten-PID und SEO-Einstellungen. Die Extension liefert ein umfangreiches Set an TypoScript-Konstanten, das die meisten Konfigurationen ohne eigenen Code abdeckt. Für Custom-Anforderungen (z.B. ein Slider auf der Startseite, der die drei neuesten News zeigt) gibt es ViewHelper, die in Fluid-Templates genutzt werden können.

Die Fluid-Templates für List, Detail, Category und Date-Menü sind über TypoScript-Pfade überschreibbar. In der Praxis kopiert man die Standard-Templates ins eigene Site-Package und passt HTML-Struktur und CSS-Klassen an das Corporate Design an. Diese Trennung ermöglicht Updates der Extension, ohne dass eigene Anpassungen überschrieben werden.

Die Performance ist bei korrekter Konfiguration gut: Die Listenansicht nutzt den TYPO3-Page-Cache, die Detailansicht cached pro Artikel-UID. Erst bei News-Beständen jenseits von 10.000 Artikeln mit komplexen Kategorie-Filtern und Volltextsuche wird die Performance zum Thema. In solchen Fällen empfiehlt sich ein Suchindex über ke_search oder Solr.

## Common problems involve SEO-Konfiguration, Performance und die tt_news-Migration

Problem eins: Fehlende oder falsche Canonical-URLs. Ohne korrekte Konfiguration ist derselbe Artikel über mehrere URLs erreichbar: über den Kategorie-Pfad, den Archiv-Pfad und den Direkt-Link. Google indexiert alle Varianten als separate Seiten, was zu Duplicate Content führt. Die Lösung: Die Detail-Seiten-PID explizit setzen und die Canonical-URL in den TypoScript-Settings auf die Detail-Seite konfigurieren. Die Extension newscanonical adressiert dieses Problem zusätzlich.

Problem zwei: Performance-Einbrüche bei grossen News-Beständen. Wenn die Listenansicht 5.000+ Artikel durchsuchen muss, steigen die Datenbankabfragezeiten. Die Lösung: Kategorie-basierte Einschränkungen in der TypoScript-Konfiguration, Paginierung mit maximal 20 Artikeln pro Seite und Datenbank-Indizes auf den Kategorie-Relationen.

Problem drei: Migration von tt_news. Die Legacy-Extension tt_news ist seit TYPO3 v8 nicht mehr kompatibel. Die Datenmigration auf tx_news erfordert ein Mapping der Felder (tt_news_cat auf sys_category, Marker-Templates auf Fluid-Templates) und eine URL-Redirect-Strategie, damit bestehende Google-Rankings erhalten bleiben. Gosign nutzt dafür KI-gestützte Template-Analyse: Unser Tooling liest die alten Marker-Templates, identifiziert die verwendeten Felder und generiert Fluid-Templates, die die gleiche Ausgabe produzieren.

## tx_news unterstützt TYPO3 v12 und v13 vollständig

Georg Ringer pflegt tx_news aktiv und stellt bei jedem TYPO3-LTS-Release zeitnah eine kompatible Version bereit. Die aktuelle Serie unterstützt TYPO3 v11, v12 und v13 parallel. Beim Upgrade von v10 oder v11 auf v12 betreffen Breaking Changes vor allem eigene ViewHelpers, die auf die aktuelle Fluid-API umgestellt werden müssen, sowie TypoScript-Konfigurationen, die auf die neue SiteSet-Syntax migriert werden sollten. Die Record-Struktur bleibt stabil, eine Datenmigration ist nicht nötig. Gosign führt tx_news-Upgrades typischerweise im Rahmen des TYPO3-Core-Upgrades durch und prüft dabei Custom-Templates, ViewHelpers und TypoScript-Overrides auf Kompatibilität. Bei Projekten mit umfangreichen Anpassungen (Custom Fields, eigene ViewHelpers, Integration mit Drittsystemen) erstellen wir vor dem Upgrade eine Kompatibilitätsmatrix, die alle Abhängigkeiten dokumentiert und den Migrationsaufwand realistisch einschätzt. KI-gestützte Code-Analyse beschleunigt diesen Prozess erheblich, indem sie alle Stellen im Projekt identifiziert, die von API-Änderungen betroffen sind.

--- news_podcast TYPO3 - Podcast Plugin | Gosign ---
> Podcast functionality for GeorgRinger/news. RSS feed with iTunes-compatible tags, audio player integration, episode management.

## news_podcast turns a news system into a podcast host

Anyone who maintains news articles in TYPO3 and at the same time produces a podcast faces a decision: either use an external podcast host (Podigee, Podcaster, Anchor) and link into the website, or deliver the podcast feed directly from TYPO3. news_podcast makes option two possible: the extension extends GeorgRinger/news with fields and Fluid templates for audio files and generates an iTunes-compatible RSS feed that Apple Podcasts, Spotify and Google Podcasts import without detours. For organisations that want to retain control over content and audio files, this is the relevant architectural option. It avoids platform dependency, keeps the usage statistics in-house and also serves the content in the same CMS context where the news articles and the magazine already live.

## Typical use cases are corporate podcasts and educational formats

Corporate podcasts are the most common scenario. A mid-sized industrial company produces a new episode every two weeks with guests from the industry and wants to embed the episodes in the corporate blog, submit them to Apple Podcasts and at the same time publish SEO-effective news articles with transcript and show notes. news_podcast covers these three needs in a single record, without the editorial team having to maintain three separate systems. A curated podcast record automatically produces the news article, the RSS feed entry and the Schema.org/PodcastEpisode markup.

A second scenario are universities and education providers. Lectures are recorded as audio files and stored on the campus server. Through news_podcast they appear as episodes of a lecture series, with chapters, transcript and reading lists. The feed is submitted to Apple Podcasts and Spotify, and access runs directly through the TYPO3 website, without students having to use an additional portal. Especially in periods with a high share of e-learning, this is a noticeable advantage over third-party platforms that bring additional accounts and tracking with them.

A third scenario are associations and political organisations that offer weekly interviews or press conferences as a podcast. Here it is above all about sovereignty: all data stays on the organisation's own infrastructure, and the audience statistics come from the organisation's server logs, not from a third-party dashboard. For organisations with high sensitivity towards tracking services, this is often the decisive factor against external podcast hosts.

## Technical architecture extends the news model with podcast attributes

news_podcast registers a new field set via a TCA override for tx_news_domain_model_news. Per article, additional fields become available: audio file (FAL reference), duration, episode, season, type (full, trailer, bonus), explicit flag and transcript. Through another override, the news category is extended with a podcast channel field, with iTunes category, cover art, author, owner email and language.

The RSS feed is delivered through a dedicated TYPO3 controller. The route is configurable and produces an RSS 2.0 with iTunes namespace extensions. Every episode contains the mandatory tags for enclosure, duration, episode, episodeType and explicit. Validation runs against the Apple Podcasts feed validator and castfeedvalidator.com. Without a valid validation, Apple Podcasts refuses to accept the feed, and Spotify does not show the channel in search results.

The frontend output uses Fluid partials that can be overridden via a package overlay. The standard output embeds an HTML5 audio player and renders the show notes into the running text of the news detail template. For transcript output, a separate partial area is used that is made accessible via a tab system or an accordion. Anyone who wants to keep transcripts visible in the DOM for SEO reasons can override the partial and render the full text inline.

## Common problems involve feed validation, enclosures and streaming

The most common support topic is iTunes feed validation. Apple Podcasts rejects feeds when the cover art does not meet the requirements (minimum 1400x1400px, maximum 3000x3000px, JPEG or PNG, sRGB) or when the <enclosure> tag is missing a MIME type. In practice, the first submission often fails on the cover art ratio, not on the actual extension.

The second topic is file sizes and streaming. Audio files in podcast quality (128 kbit MP3) come in at 30 to 60 MB per episode. Anyone who delivers these files directly from TYPO3 storage transfers the entire load to the web server, which becomes a bottleneck with thousands of listeners per episode. We recommend offloading the audio files to a separate storage (S3-compatible, CDN) and connecting it through FAL remote storage. This keeps the TYPO3 server responsible for content delivery while the audio load lands on the cheaper storage tier.

Thirdly, Google Podcasts requires a speaking, permanent URL per episode. The extension generates that automatically from the news slug, but the routing has to be enabled for the podcast controller in the site config, otherwise TYPO3 produces typolink URLs with a query string that Google Podcasts does not accept.

## Migration to TYPO3 v12 requires a synchronous news core upgrade

news_podcast is available for TYPO3 v11, v12 and v13 but requires a compatible GeorgRinger/news version. On the jump to TYPO3 v12, both extensions have to be updated in sync: news to the v12 series and news_podcast to the matching major version. The database structure stays stable, audio FAL references move along without any special handling.

Gosign typically migrates news_podcast as part of a content hub refactor. In the same step we check whether transcripts can be extended with structured data, whether the cover art complies with current Apple guidelines and whether the feed controller is protected with a rate limit. For larger podcasts we extend the extension with a dedicated hosts model, so that guests can be managed with profile page and backlink. In combination with md_news_author, podcasters and guests can then be maintained as author profiles in parallel, which significantly improves the Schema.org markup and internal linking.

--- tt_news Migration TYPO3 | Gosign ---
> Migration extension from tt_news to GeorgRinger/news. Transfers data, categories, images and relations. The standard migration path for TYPO3 upgrades.

## Anyone still using tt_news is blocking every TYPO3 upgrade from version 10 onward

tt_news was the standard extension for news, press releases and blog posts in TYPO3 for over a decade. Thousands of websites were built with it, some containing hundreds or thousands of articles. The problem: tt_news was last officially supported for TYPO3 v7. Since TYPO3 v8 (2017), there has been no compatible release. Anyone still using tt_news is stuck on an outdated TYPO3 version and cannot benefit from security updates or new features.

The official replacement is GeorgRinger/news (short: EXT:news), developed as a successor since 2012. news is the most installed TYPO3 extension of all (over 250,000 active installations, as of 2026) and supports TYPO3 v11, v12 and v13. news_ttnewsimport is the migration extension that automates the transition: articles, categories, images, related news and page references are transferred from tt_news to EXT:news.

## Typical use cases

**TYPO3 upgrade from v7/v8/v9 to v12 or v13.** The most common case: a company runs a TYPO3 website on v7 or v9 with 500 to 5,000 news articles in tt_news. The planned upgrade to v12 LTS fails because of tt_news incompatibility. news_ttnewsimport transfers all data into the EXT:news structure so the upgrade can proceed.

**Relaunch with existing data.** During a website relaunch, the design should be completely new but the existing news articles must be preserved. The articles have built up SEO value over the years (backlinks, indexing, rankings). Starting fresh without migration would destroy that value. news_ttnewsimport preserves the content, EXT:news provides the modern technology, the new design is implemented through Fluid templates.

**Multi-site environments with shared news database.** Corporations with 5 to 20 TYPO3 instances that manage news centrally and distribute it across all sites. The migration must run in a coordinated fashion: first migrate the central database, then adapt templates on all sites, then replace the old tt_news plugins with EXT:news plugins.

## Technical architecture

news_ttnewsimport is a CLI-based extension that runs through the TYPO3 command controller. The migration process works in five steps. First, tt_news categories (tt_news_cat) are converted into sys_category entries. The category hierarchy (parent-child) is preserved. Then the news records themselves are migrated: title, teaser, bodytext, author, date, type (news, internal link, external link), archive date and hidden/deleted status. In the third step, images and media are converted from the old storage structure (uploads/pics/ or fileadmin/) into FAL references. Image captions and alt texts are transferred where available. The fourth step migrates related news (cross-references between articles) as sys_category relations or as direct news relations. In the final step, content elements on news pages are updated: tt_news plugins are replaced with EXT:news plugins, TypoScript settings are adjusted.

The data table changes from `tt_news` to `tx_news_domain_model_news`. The field mapping is documented: tt_news.title becomes tx_news.title, tt_news.short becomes tx_news.teaser, tt_news.bodytext becomes tx_news.bodytext, tt_news.datetime becomes tx_news.datetime. Not all fields have a 1:1 counterpart (e.g. tt_news.image as a comma-separated file list vs. EXT:news with FAL references).

## Common problems and solutions

**Images missing after migration.** tt_news stored images as filenames in a text field (e.g. "image1.jpg,image2.jpg"), with files residing in uploads/pics/. EXT:news uses FAL. If the physical files no longer exist in the expected directory (e.g. after a server move), image migration fails. Solution: verify before migration that all referenced images are physically present. Restore missing files from backups or create placeholders.

**Category assignments lost.** tt_news used its own category tables (tt_news_cat), EXT:news uses sys_category. If the migration does not correctly map category IDs, articles lose their assignments. Solution: news_ttnewsimport creates a mapping (old ID to new ID) and updates all references. This mapping should be exported and archived after migration in case later corrections are needed.

**URL structure changes, SEO rankings drop.** tt_news articles had URLs like `/news/detail/article-title/`. EXT:news generates `/news/article-title/` by default. Solution: set up 301 redirects from old to new URLs. With 1,000 articles, this is not feasible manually. Gosign generates the redirect map automatically from the old and new URL structures and imports it as RealURL/RouteEnhancer configuration or as .htaccess rules.

## Migration and version compatibility

news_ttnewsimport supports migration to EXT:news on TYPO3 v11 and v12. The recommended procedure: first upgrade TYPO3 to v11 (if coming from v7/v8/v9, in stages), then run news_ttnewsimport, then upgrade to v12 or v13. Migrating on a v7 instance is not recommended because EXT:news cannot use the current version there.

For very large datasets (10,000+ articles), Gosign recommends performing the migration on a staging system and reviewing the result before switching production. The migration itself takes between 30 minutes (500 articles) and 4 hours (10,000 articles with images) depending on data volume. Template adaptation (Fluid templates for the new EXT:news output) comes as a separate effort and typically takes 2 to 5 days.

An often underestimated aspect of tt_news migration is search engine communication. Google has indexed and ranked the old URLs. If after migration 500 URLs return 404, the website loses ranking positions. Gosign therefore sets up redirect monitoring after every migration: one week after go-live, Google Search Console data is checked for 404 errors, missing redirects are added and indexing of new URLs is accelerated via IndexNow or manual fetch requests.

For companies that want to use the tt_news migration as an opportunity for a content audit, Gosign offers a combined approach: during the technical migration, all articles are reviewed for freshness, SEO quality and relevance. Outdated articles are redirected to the homepage or a thematic overview page instead of being migrated. This reduces the dataset, improves content quality and saves migration effort for articles that no longer generate traffic.

--- newscanonical TYPO3 - Canonical for News | Gosign ---
> newscanonical: correct canonical tags for TYPO3 news. Avoid duplicate content. SEO optimization.

## Duplicate Content durch fehlende Canonical Tags kostet TYPO3-News-Seiten Rankings

Ein tx_news-Artikel ist häufig über drei oder mehr URLs erreichbar: über den Kategorie-Pfad (/news/marketing/artikel-titel), über das Archiv (/news/2025/03/artikel-titel) und über einen Direct-Link (/news/artikel-titel). Für Besucher macht das keinen Unterschied, für Google ist es ein Problem. Google sieht drei separate Seiten mit identischem Inhalt und muss entscheiden, welche die "richtige" ist. Ohne ein Canonical-Tag, das auf die bevorzugte URL zeigt, verteilt Google die Ranking-Signale auf alle Varianten und schwächt jede einzelne. newscanonical löst dieses Problem für tx_news, indem es auf jeder News-Detailseite ein Canonical-Tag generiert, das auf die definitive URL zeigt.

Die Extension ist ein fokussiertes SEO-Tool, das genau einen Job macht: Duplicate Content bei tx_news verhindern. Für Websites mit 100+ News-Artikeln kann das den Unterschied zwischen Seite 1 und Seite 3 bei Google bedeuten.

## Typical use cases involve News-Websites, Magazine und Pressebereiche

Das Standardszenario ist die Unternehmenswebsite mit einem News- oder Blog-Bereich. Ein Unternehmen veröffentlicht wöchentlich Artikel, die in Kategorien (Produkte, Branchen, Events) eingeordnet sind. Jeder Artikel erscheint in der Kategorieliste und im Gesamtarchiv. Ohne newscanonical indexiert Google jede URL-Variante separat, was bei 500 Artikeln zu 1.500 indexierten Seiten mit Duplicate Content führen kann. Die Google Search Console zeigt das als "Doppelte Seite, von Google gewählte kanonische URL weicht von der vom Nutzer bestimmten ab".

Zweites Szenario: Online-Magazine mit Tag- und Kategorie-basierten Listenansichten. Ein Magazin hat 20 Kategorien und 50 Tags. Jeder Artikel hat mindestens eine Kategorie und zwei bis drei Tags. Die Kombinatorik erzeugt dutzende mögliche URL-Pfade pro Artikel. newscanonical konsolidiert alle Varianten auf eine einzige Canonical-URL.

Drittes Szenario: Pressebereiche von börsennotierten Unternehmen. Pflichtmitteilungen müssen dauerhaft verfügbar sein und dürfen im Google-Index nicht durch Duplicate-Content-Probleme aus den Suchergebnissen fallen. Ein korrektes Canonical-Tag stellt sicher, dass Google die definitive Version indexiert.

## Technical architecture setzt ein Link-Tag im HTML-Header pro News-Detailseite

newscanonical registriert sich in die Rendering-Pipeline von tx_news und fügt im HTML-Header der Detailseite ein `<link rel="canonical" href="...">` Tag ein. Die Canonical-URL wird aus der konfigurierten Detail-Seiten-PID und dem News-UID berechnet, unabhängig davon, über welchen Pfad der Besucher auf die Seite gelangt ist.

Die Konfiguration erfolgt über TypoScript: Die Detail-Seiten-PID wird als Basis für die Canonical-URL gesetzt. Optionale Parameter wie die URL-Struktur (RealURL oder TYPO3 Site Handling) und die Einbeziehung von Kategorie-Segmenten in die Canonical-URL werden über Konstanten gesteuert.

Die Extension arbeitet als Hook in der tx_news-Rendering-Pipeline, nicht als eigenständiges Plugin. Das bedeutet: Sie hat keine eigene Frontend-Ausgabe und kein eigenes Content-Element. Die einzige sichtbare Auswirkung ist das Canonical-Tag im HTML-Source, das Suchmaschinen lesen, aber Besucher nie sehen.

Für die korrekte Funktion muss die Detail-Seiten-PID in der tx_news-Konfiguration und in der newscanonical-Konfiguration übereinstimmen. Wenn tx_news mehrere Detail-Seiten nutzt (z.B. eine pro Kategorie), muss newscanonical entsprechend konfiguriert werden, damit die Canonical-URL auf die richtige Detail-Seite zeigt.

## Common problems include falsche PID-Konfiguration, Konflikte mit dem Core-Canonical und Redirect-Loops

Problem eins: Falsche Detail-Seiten-PID. Wenn die PID in der newscanonical-Konfiguration nicht mit der tx_news-Konfiguration übereinstimmt, zeigt das Canonical-Tag auf eine Seite, die den Artikel gar nicht anzeigen kann. Google ignoriert das Canonical-Tag dann und wählt selbst eine Variante. Die Lösung: PID-Konsistenz prüfen und in der Google Search Console die indexierten Canonical-URLs gegen die konfigurierten URLs vergleichen.

Problem zwei: Konflikte mit dem TYPO3-Core-Canonical. Seit TYPO3 v10 hat der Core eine eigene Canonical-URL-Generierung über die SEO-Erweiterung (seo system extension). Wenn beide aktiv sind, können zwei konkurrierende Canonical-Tags im HTML-Header erscheinen. Die Lösung: Prüfen, ob der Core-Canonical für News-Detailseiten korrekt arbeitet. Wenn ja, ist newscanonical überflüssig und kann deaktiviert werden. Wenn der Core-Canonical die News-Parameter nicht korrekt in die URL aufnimmt, bleibt newscanonical nötig.

Problem drei: Redirect-Loops bei fehlerhafter URL-Konfiguration. Wenn die Canonical-URL auf eine Seite zeigt, die selbst einen Redirect auf eine andere URL enthält, entsteht ein Loop. Das passiert typischerweise nach einer URL-Umstrukturierung, wenn alte Redirects nicht bereinigt wurden. Die Lösung: Alle Redirects für News-URLs prüfen und inkonsistente Einträge entfernen.

## Ab TYPO3 v12 prüft Gosign, ob der Core-Canonical ausreicht

TYPO3 v12 hat den Canonical-Support im Core signifikant verbessert. Die seo system extension generiert Canonical-URLs auf Basis des Site Handling und berücksichtigt Query-Parameter. Für viele tx_news-Konfigurationen reicht der Core-Canonical seit v12 aus, sodass newscanonical nicht mehr nötig ist. Gosign prüft bei jedem TYPO3-Upgrade, ob die Core-Lösung die News-Canonical-URLs korrekt generiert. Wenn ja, empfehlen wir die Deaktivierung von newscanonical, um eine potenzielle Konfliktstelle zu eliminieren. Wenn die News-URLs komplexe Parameter oder Kategorie-Pfade enthalten, die der Core nicht auflöst, bleibt die Extension eine valide Lösung. In jedem Fall empfehlen wir nach dem Upgrade einen systematischen Crawl mit Screaming Frog oder einem vergleichbaren Tool, um alle News-Detailseiten auf korrektes Canonical-Verhalten zu prüfen. Ein einziger falsch konfigurierter Canonical-Tag kann dutzende Seiten aus dem Google-Index verdrängen, was bei Presseseiten oder SEO-relevanten Blog-Artikeln direkten Traffic-Verlust bedeutet.

--- News Sync TYPO3 | Gosign ---
> News synchronization between TYPO3 instances or external sources. RSS import, API-based content sync with duplicate detection.

## Wenn News-Content auf mehreren TYPO3-Instanzen erscheinen soll, reicht Copy-Paste nicht

Organisationen mit mehreren Websites stehen vor einem konkreten Problem: Ein Dachverband veröffentlicht eine Pressemitteilung, und 15 Landesverbände sollen sie auf ihren eigenen TYPO3-Installationen anzeigen. Oder ein Konzern betreibt eine Corporate-Website und fünf Marken-Websites, und bestimmte News sollen auf allen sechs Seiten erscheinen. Manuelles Kopieren ist fehleranfällig, zeitaufwändig und erzeugt Inkonsistenzen. newssync löst das Problem, indem es News-Artikel zwischen TYPO3-Instanzen oder aus externen Quellen automatisch synchronisiert. RSS-Import, API-basierter Sync und Duplikat-Erkennung sind die Kernfunktionen.

Für Organisationen mit einer Multi-Site-Strategie ist Content-Syndication kein Nice-to-have, sondern operativ notwendig. Ohne automatisierten Sync entstehen Content-Silos, die die Redaktion in der Zentrale nicht kontrollieren kann.

## Typical use cases include Verbands-Netzwerke, Konzern-Websites und News-Aggregation

Das häufigste Szenario ist das Verbandsnetzwerk. Ein Bundesverband veröffentlicht Branchennews, regulatorische Updates und Pressemitteilungen auf seiner TYPO3-Website. Die 16 Landesverbände betreiben eigene TYPO3-Installationen und wollen ausgewählte Artikel automatisch übernehmen. newssync importiert die markierten Artikel per RSS-Feed oder API, erstellt lokale tx_news-Records und ermöglicht den Landesverbänden, Teaser und Kategorien lokal anzupassen.

Zweites Szenario: Konzern-Websites mit einer Content-Hub-Strategie. Die Konzern-Zentrale pflegt einen News-Hub, aus dem Marken-Websites und Länder-Websites selektiv Content beziehen. Die Synchronisation läuft kategorie-basiert: Eine Marken-Website abonniert nur Artikel der Kategorien "Produkt X" und "Innovation", nicht den gesamten News-Feed.

Drittes Szenario: News-Aggregation aus externen Quellen. Ein Branchenportal importiert Pressemitteilungen von Mitgliedsunternehmen automatisch über deren RSS-Feeds. newssync prüft die Feeds in konfigurierbaren Intervallen, importiert neue Artikel und erkennt Duplikate anhand von Titel und Veröffentlichungsdatum.

## Technical architecture uses RSS-Parsing und die TYPO3-Scheduler-Pipeline

newssync arbeitet mit zwei Import-Modi: RSS/Atom-Feed-Import und API-basierter Sync. Im RSS-Modus konfiguriert der Administrator eine Feed-URL, und der Scheduler-Task parst den Feed, extrahiert Titel, Teaser, Body, Datum und Medien-URLs und erstellt tx_news-Records in der lokalen Datenbank. Bilder werden heruntergeladen und als FAL-Dateien lokal gespeichert, damit die Quelle nicht dauerhaft erreichbar sein muss.

Im API-Modus kommuniziert newssync mit einem REST-Endpoint auf der Quell-Instanz. Das ermöglicht selektiveren Import: Statt den gesamten Feed zu importieren, können Artikel nach Kategorien, Tags oder Datum gefiltert werden. Der API-Modus überträgt auch Custom Fields, die im RSS-Format nicht abbildbar sind.

Die Duplikat-Erkennung basiert auf einem konfigurierbaren Schlüssel: standardmässig ein Hash aus Titel und Veröffentlichungsdatum. Wenn ein Artikel mit dem gleichen Schlüssel bereits existiert, wird er übersprungen oder aktualisiert, je nach Konfiguration. Das verhindert, dass derselbe Artikel mehrfach importiert wird, wenn der Sync-Job häufiger läuft als der Feed aktualisiert wird.

Der Sync läuft als TYPO3-Scheduler-Task, typischerweise alle 15 bis 60 Minuten. Die Ergebnisse jedes Laufs werden protokolliert: Anzahl importierter, aktualisierter und übersprungener Artikel. Bei Fehlern (Feed nicht erreichbar, Parser-Fehler) wird eine Warnung ins TYPO3-Log geschrieben.

## Common problems include Medien-Import, HTML-Bereinigung und Kategorie-Mapping

Problem eins: Medien-Import schlägt fehl. Bilder und Dokumente, die im Quell-Feed referenziert werden, sind nicht immer direkt downloadbar. Hotlink-Schutz, Authentifizierung oder CDN-basierte URLs können den Download verhindern. Die Lösung: Medien-URLs vor dem Import testen und einen Fallback-Mechanismus implementieren, der fehlende Bilder durch ein Platzhalter-Bild ersetzt.

Problem zwei: Unsauberes HTML im importierten Content. RSS-Feeds enthalten oft HTML, das nicht dem Standard des Ziel-Systems entspricht: Inline-Styles, veraltete Tags, fehlende Absätze. Die Lösung: Eine HTML-Bereinigung (Sanitizing) nach dem Import, die überflüssige Tags und Styles entfernt und den Content in das erwartete Format bringt. TYPO3 bietet dafür die RteHtmlParser-Klasse.

Problem drei: Kategorie-Mapping zwischen Quell- und Ziel-System. Die Kategorien im Quell-Feed stimmen nicht mit den lokalen Kategorien überein. "Pressemitteilung" in der Zentrale heisst "Presse" beim Landesverband. Die Lösung: Ein Mapping-Table in der newssync-Konfiguration, der Quell-Kategorien auf lokale TYPO3-Sys-Categories abbildet.

Ein viertes Problem betrifft die Content-Hoheit: Wenn ein Landesverband einen synchronisierten Artikel lokal ändert und die Zentrale den Originalartikel ebenfalls aktualisiert, überschreibt der nächste Sync die lokale Änderung. Die Lösung: Synchronisierte Artikel als "read-only" markieren und lokale Anpassungen nur in dedizierten Feldern (z.B. lokaler Teaser, regionale Ergänzung) zulassen, die vom Sync nicht betroffen sind.

## Die Extension hat keine gesicherte v12-Unterstützung, Custom-Lösungen include robuster

newssync wurde für ältere TYPO3-Versionen entwickelt und hat keine offizielle Unterstützung für v12 oder v13. Für Organisationen, die Content-Syndication als Kernfunktion benötigen, empfiehlt Gosign eine massgeschneiderte Lösung: Ein Custom-Importer als Scheduler-Task, der RSS-Feeds oder eine REST-API konsumiert und tx_news-Records erstellt. Der Aufwand für eine Grundimplementierung mit Feed-Import, Duplikat-Erkennung und Medien-Download liegt bei 3 bis 5 Arbeitstagen. KI-gestützte Code-Generierung beschleunigt die Entwicklung des Feed-Parsers und des Mapping-Layers erheblich.

Der Vorteil einer Custom-Lösung: Das Mapping zwischen Quell- und Ziel-Kategorien, die Medien-Verarbeitung und das Fehler-Handling können exakt auf die Anforderungen der Organisation zugeschnitten werden. Ein Bundesverband mit 16 Landesverbänden hat andere Sync-Anforderungen als ein Konzern mit 5 Marken-Websites. Gosign implementiert Content-Syndication-Lösungen auf Basis moderner TYPO3-APIs (PSR-14 Events, Symfony Messenger für Queue-basierte Verarbeitung), die auch bei v13-Upgrades kompatibel bleiben.

--- Audio Player TYPO3 - HTML5 | Gosign ---
> HTML5 audio player for TYPO3. Podcasts, audio guides, music streaming. Custom player with playlist support, progress indicator, speed control.

## Podcasts und Audioguides brauchen einen Player, der ohne externe Dienste auskommt

Wer Audio-Inhalte auf einer TYPO3-Website bereitstellen will, steht vor einer unangenehmen Wahl: Entweder ein externer Dienst wie SoundCloud oder Spotify, der Nutzerdaten an Drittserver sendet und die Gestaltung diktiert, oder ein nativer HTML5-Player, der im Browser-Default kaum benutzbar ist. nim_html5audioplayer schliesst diese Lücke. Die Extension liefert einen vollständig in TYPO3 integrierten Audio-Player mit Playlist-Support, Fortschrittsanzeige und Geschwindigkeitssteuerung. Alle Audiodateien bleiben auf dem eigenen Server, kein externer Request verlässt die Seite.

Für Museen, Bildungseinrichtungen und Verlage mit Podcast-Formaten ist das eine harte Anforderung: Audioguides dürfen keine Tracking-Cookies setzen, Schulungsinhalte müssen ohne Internetverbindung im Intranet laufen, und Corporate Podcasts sollen im CI der Organisation erscheinen. nim_html5audioplayer erfüllt alle drei Szenarien mit einem einzigen Content-Element.

## Typical use cases reichen vom Museum bis zum internen Schulungsportal

Das häufigste Szenario sind Audioguides in Museen und Ausstellungen. Besucher scannen einen QR-Code, landen auf einer TYPO3-Seite und hören den Kommentar zu einem Exponat. Der Player startet ohne Autoplay, zeigt die Fortschrittsleiste und erlaubt Geschwindigkeitsanpassung zwischen 0,5x und 2x. Bei einer typischen Ausstellung mit 30 bis 50 Stationen liefert die Playlist-Funktion eine durchgängige Tour, ohne dass Besucher manuell zwischen Seiten navigieren müssen.

Das zweite grosse Einsatzfeld sind Corporate Podcasts. Unternehmen, die ihr internes Wissen als Audio-Serie aufbereiten, brauchen einen Player, der in die bestehende TYPO3-Website eingebettet ist, nicht auf einer externen Plattform lebt. nim_html5audioplayer liefert dafür einen gebrandeten Player mit Episodenliste, Kapitelmarken und Download-Option. Die Redaktion pflegt Episoden wie reguläre TYPO3-Inhalte über das Backend.

Ein drittes Szenario sind Sprachlernportale und E-Learning-Plattformen. Hier kommt die Geschwindigkeitssteuerung besonders zum Tragen: Lernende können Dialoge verlangsamen oder Wiederholungen in erhöhtem Tempo abspielen. In Kombination mit fe_login lassen sich Premium-Audioinhalte hinter einer Anmeldung schützen.

## Technical architecture relies on native HTML5-APIs ohne JavaScript-Framework

nim_html5audioplayer nutzt die HTML5 Audio API des Browsers und rendert die Player-Oberfläche über Fluid-Templates. Es gibt keine Abhängigkeit zu jQuery, React oder einem anderen Framework. Das hält die Ladezeit minimal: Der Player selbst wiegt unter 15 KB (CSS + JS), die Audiodateien werden über FAL (File Abstraction Layer) verwaltet und per Streaming ausgeliefert.

Die Extension registriert ein eigenes Content-Element im TYPO3-Backend. Redakteure wählen Audiodateien aus der FAL-Mediathek, setzen Titel, Beschreibung und optionales Vorschaubild. Die Playlist-Funktion gruppiert mehrere Audio-Einträge in einer sortierbaren Liste. Das Rendering übernehmen Fluid-Templates, die per SiteSet oder eigenes Sitepackage überschrieben werden können.

Für die Fortschrittsanzeige speichert der Player den aktuellen Wiedergabestand im LocalStorage des Browsers. Kehrt ein Besucher zurück, springt der Player an die letzte Position. Das funktioniert ohne Cookies und ohne serverseitige Session.

## Common problems involve Audio-Formate und mobile Browser

Das dominierende Supportthema ist die Audio-Format-Kompatibilität. MP3 funktioniert in allen Browsern, OGG Vorbis nur in Firefox und Chrome, AAC nur in Safari und Chrome. Wer maximale Kompatibilität will, hinterlegt jede Datei als MP3. Wer bessere Qualität bei geringerer Dateigrösse braucht, liefert MP3 als Fallback und Opus als primäres Format aus.

Zweites Problem: Autoplay-Blockierung auf mobilen Geräten. iOS und Android verhindern seit 2018 die automatische Wiedergabe von Audio ohne Nutzerinteraktion. nim_html5audioplayer respektiert diese Browser-Policy und startet Audio ausschliesslich nach einem expliziten Klick. Wer dennoch Autoplay für Hintergrundmusik konfiguriert, erhält auf Mobilgeräten Stille ohne Fehlermeldung.

Drittes Thema ist die Performance bei grossen Playlists. Ab 100 Einträgen in einer einzelnen Playlist wird die DOM-Renderzeit spürbar. Die Lösung: Playlists in thematische Blöcke von 20 bis 30 Einträgen aufteilen und über Kategorien im Backend organisieren.

## Die Extension works unter TYPO3 v11 und v12, der v13-Status hängt vom Maintainer ab

nim_html5audioplayer wurde ursprünglich für TYPO3 v8 und v9 entwickelt. Die Basis-Funktionalität (HTML5 Audio API, FAL-Integration) ist technisch stabil und läuft unter v11 und v12 ohne grössere Anpassungen. Für TYPO3 v13 existiert aktuell keine offizielle Kompatibilitätserklärung des Maintainers. Die Extension nutzt jedoch keine der in v13 entfernten APIs, sodass eine Migration in den meisten Fällen mit geringem Aufwand möglich ist.

Gosign prüft bei TYPO3-Upgrades, ob die eingesetzten Audio-Extensions noch kompatibel sind, und empfiehlt bei Bedarf Alternativen. Wenn die Extension nicht mehr weiterentwickelt wird, lässt sich die gleiche Funktionalität über ein Custom Content Element mit nativer HTML5 Audio API und Fluid-Templates nachbauen, typischerweise innerhalb von zwei bis drei Entwicklertagen.

--- nimcore TYPO3 - Core Framework | Gosign ---
> NIM Core Framework: base library for custom TYPO3 extensions in the NIM family. Abstract classes, utility functions, shared configuration.

## Ohne zentrale Basis-Library erzeugen Extension-Familien doppelten Code und doppelte Fehler

TYPO3-Agenturen, die mehrere zusammengehörige Extensions entwickeln, stehen vor einem Architekturproblem: Jede Extension reimplementiert Utility-Funktionen wie Konfigurationsauslese, Backend-Module-Registrierung, FAL-Handling und Logging. Bei fünf Extensions bedeutet das fünf Kopien derselben Hilfsfunktionen, fünf Stellen für denselben Bug. nimcore löst dieses Problem als zentrale Basis-Library der NIM-Extension-Familie. Abstrakte Klassen, Utility-Funktionen und gemeinsame Konfiguration liegen an einer einzigen Stelle. Alle abhängigen NIM-Extensions erben von nimcore und müssen nur ihre fachliche Logik implementieren.

Dieses Pattern ist im TYPO3-Ökosystem selten, aber in der Software-Architektur etabliert: Ein Shared Kernel, der horizontale Concerns (Logging, Configuration, Base Models) kapselt, während vertikale Extensions (Audio Player, Galerie, Slider) die Fachlogik übernehmen.

## Typical use cases involve Agenturen mit eigenen Extension-Portfolios

Das primäre Szenario ist die Agentur, die ein Set von vier bis zehn eigenen TYPO3-Extensions pflegt. Ohne eine gemeinsame Basis-Library wachsen die Extensions auseinander: Die eine nutzt GeneralUtility::makeInstance, die andere den DI-Container, die dritte hat eine eigene Logger-Konfiguration. nimcore erzwingt einen einheitlichen Standard. Alle NIM-Extensions nutzen dieselben abstrakten Controller-Klassen, dasselbe Exception-Handling und dieselbe Konfigurationsstruktur.

Ein zweites Szenario sind Inhouse-Entwicklungsteams, die ihre TYPO3-Instanz mit mehreren Custom-Extensions erweitern. Statt jede Extension als isoliertes Paket zu behandeln, können Teams eine eigene Core-Library nach dem nimcore-Muster aufbauen: gemeinsame Base-Models, gemeinsame Backend-Module-Klassen, gemeinsame Test-Fixtures. Das reduziert den Wartungsaufwand und senkt die Einstiegshürde für neue Entwickler, die nur eine Architektur lernen müssen.

Ein drittes Szenario ist die Versionierung bei Upgrades. Wenn der TYPO3-Core eine API ändert, die in fünf Extensions genutzt wird, genügt ein einziges Update in nimcore. Alle abhängigen Extensions profitieren sofort, ohne dass jede einzeln angepasst werden muss. Bei einem TYPO3-v12-Upgrade mit sieben NIM-Extensions spart das typischerweise zwei bis drei Entwicklertage.

## Technical architecture folgt dem Shared-Kernel-Prinzip

nimcore registriert sich als normale TYPO3-Extension und wird über Composer als Dependency in den abhängigen Extensions deklariert. Die ext_emconf.php der NIM-Extensions listet nimcore als required constraint. Beim Installieren einer NIM-Extension wird nimcore automatisch mitgeladen.

Intern liefert nimcore abstrakte Klassen für Controller, Repositories und Models, die das TYPO3-Extbase-Framework korrekt initialisieren. Utility-Klassen kapseln wiederkehrende Aufgaben: TypoScript-Konfiguration auslesen, FAL-Referenzen auflösen, Backend-Toolbars registrieren, Flash-Messages standardisiert ausgeben. Eine zentrale Configuration-Registry ermöglicht es, Extension-spezifische Einstellungen in einem einheitlichen Format zu definieren, das im TYPO3-Backend über ein Settings-Modul zugänglich ist.

Die Test-Infrastruktur ist ebenfalls in nimcore gebündelt: Base-TestCase-Klassen, Fixture-Loader und Mocking-Utilities, die funktionale Tests für Extbase-Extensions vereinfachen. Das senkt die Hürde, Tests zu schreiben, weil das Setup nicht in jeder Extension neu konfiguriert werden muss.

## Common problems entstehen bei Versions-Konflikten und zirkulären Abhängigkeiten

Das grösste Risiko einer Shared-Kernel-Architektur ist der Lock-Step-Release-Zwang: Wenn nimcore ein Breaking Change einführt, müssen alle abhängigen Extensions gleichzeitig aktualisiert werden. In der Praxis bedeutet das, dass nimcore semantic versioning strikt einhalten muss. Minor-Versionen dürfen keine öffentlichen Interfaces ändern, und Major-Releases brauchen eine Migrationsanleitung.

Zweites Problem: zirkuläre Abhängigkeiten. Wenn Extension A von nimcore abhängt und nimcore einen Service nutzt, der eigentlich in Extension A definiert ist, entsteht ein Zirkel. Die Lösung ist ein sauberes Dependency-Inversion-Prinzip: nimcore definiert Interfaces, die abhängige Extensions implementieren. nimcore selbst kennt keine konkreten Implementierungen.

Drittes Thema ist die Composer-Autoload-Reihenfolge. Bei grossen Installationen mit 30 oder mehr Extensions kann die Reihenfolge des Autoloadings dazu führen, dass nimcore-Klassen noch nicht verfügbar sind, wenn eine abhängige Extension geladen wird. Die Lösung: In der composer.json der Root-Installation nimcore als erstes in der install-order definieren.

## TYPO3 v12 funktioniert, v13-Kompatibilität hängt von der Extbase-Abstraktionsschicht ab

nimcore basiert auf dem Extbase-Framework und ist damit eng an dessen API-Stabilität gekoppelt. Unter TYPO3 v12 läuft die aktuelle Version stabil. Für v13 sind Anpassungen nötig, wenn der TYPO3-Core Extbase-Interfaces ändert oder die Dependency-Injection-Konfiguration umstrukturiert.

Da nimcore ein Nischen-Produkt für die NIM-Extension-Familie ist, hängt die Weiterentwicklung direkt vom Maintainer ab. Teams, die auf nimcore setzen, sollten den Quellcode forken und in einem eigenen Repository pflegen, um nicht von externen Release-Zyklen abhängig zu sein. Gosign empfiehlt bei Custom-Extension-Portfolios generell, die Shared-Kernel-Architektur intern aufzubauen und unter eigener Kontrolle zu halten, statt auf externe Core-Libraries zu vertrauen.

--- OIDC TYPO3 - OpenID Connect SSO | Gosign ---
> OpenID Connect for TYPO3: Azure AD, Keycloak, Okta SSO. Setup, claim mapping & troubleshooting. AI-accelerated.

## How TYPO3 projects without their own identity stack connect to Azure AD, Keycloak or Okta

In any company that runs Microsoft 365, Google Workspace or a central Keycloak, the user management question has long been settled: all staff accounts live in the IdP, and every new application should plug in there rather than managing its own passwords. The OIDC extension for TYPO3 serves exactly this pattern by embedding OpenID Connect as an auth protocol in TYPO3 and making Azure AD, Keycloak, Okta, Google Workspace or Auth0 usable as an IdP, without having to run a dedicated Shibboleth SP. The target audience are corporate portals, intranets, customer login areas and any TYPO3 setup that needs to sit inside an existing enterprise identity landscape.

## Typical use cases

A mechanical engineering group with 14,000 employees runs its staff intranet on TYPO3. IT operations decided long ago that every new application has to authenticate against Azure AD and enforce multi-factor authentication there. The OIDC extension fetches the ID tokens from Azure AD, reads the group memberships included in the claim and turns them into fe_user groups. The intranet gains single sign-on, MFA and conditional access without any additional infrastructure, purely through clean configuration.

A second scenario comes from the mid-market: a software vendor with a customer portal on TYPO3 uses Keycloak as a central broker because its customers arrive with usernames or with social logins such as Google or GitHub. Keycloak unifies the situation and speaks OIDC on the outside. TYPO3 uses the OIDC extension and gains access to all login variants without having to know that social login is happening behind the scenes.

The third case is public administration and regional governments moving to Keycloak-based citizen accounts. A TYPO3 portal through which citizens submit application forms can connect to the regional Keycloak via the OIDC extension. The eID attribute from the broker lands directly in the fe_user, and the authentication level can be evaluated via the acr claim.

## Technical architecture: authorisation code flow in TYPO3

OpenID Connect is an authentication layer on top of OAuth 2.0, and the OIDC extension implements exactly the authorisation code flow. The sequence is simpler than SAML: TYPO3 redirects the user to the IdP with an authorisation request, receives a code back after a successful login, exchanges that code server-side for an ID token and validates the signature via the provider's JSON Web Key Set (JWKS). The claims from the ID token, typically sub, email, name, groups and roles, are mapped to TYPO3 user fields.

The extension is configured through the TYPO3 extension configuration and a discovery endpoint that every OIDC-compliant provider exposes at /.well-known/openid-configuration. The extension reads the token endpoints, the JWKS URL and the supported flows automatically from that URL, which reduces manual errors. Claim mapping is handled via a YAML or TypoScript configuration that maps local field names to claim paths.

## Common problems and solutions

The first problem concerns claim formats: Azure AD delivers groups as object IDs (GUIDs), not as readable names. If you expect a claim group_ids and receive group_names, you see empty user groups in TYPO3. The clean solution lies in the Azure AD application itself: in the token configuration blade you can define which attributes are issued as claims, and a claim transformation rule set can translate GUIDs into readable names.

The second problem is the redirect URI. Every OIDC client has to register the exact redirect URI with the IdP to which it will be sent after login. Differences in upper and lower case, forgotten trailing slashes or a switch from HTTP to HTTPS cause immediate login errors that are invisible in the TYPO3 log because the error happens at the IdP. Gosign configures separate clients with clean redirect URIs for staging and production and documents every change in the deployment process.

The third topic is token refresh. Anyone who wants longer sessions needs refresh tokens, which the IdP only issues if the offline_access scope has been requested at login. Without that scope, the TYPO3 session ends as soon as the ID token expires, usually after an hour. The extension backend configuration therefore has to include the offline_access scope and activate the token refresh logic.

A fourth problem concerns logout. OIDC knows front-channel and back-channel logout, and both are not necessarily enabled in the extension. Anyone expecting true single logout across multiple applications has to configure the provider's end-session endpoint and make sure that TYPO3 calls the IdP's logout URL at the end of the session. Without that configuration, the user remains logged in at the IdP even though they have signed out of TYPO3.

## Migration and version compatibility

The OIDC extension is currently the recommended standard for TYPO3 v12 and v13, while older v11 projects often still rely on hand-built OAuth implementations or shibboleth_auth. The migration path from Shibboleth to OIDC is well established, provided the IdP speaks both: Keycloak, ADFS and Azure AD can serve SAML and OIDC in parallel, so a transition without a big bang is possible.

Anyone migrating from a purely database-backed fe_user management has to map the existing accounts onto the OIDC claims with a matching strategy. The email address is the usual anchor but is not always enough, because email addresses change. A sub claim, stored as a unique persistent identifier in the fe_user, is the more robust solution. Gosign handles these migrations including reconciliation of existing accounts and a transition phase during which both auth paths work in parallel.

For teams just starting a new TYPO3 project, OIDC is the first choice in most cases. The configuration is leaner than SAML, the client effort lower, and every modern IdP supports the protocol natively. Exceptions are only justified where regulatory or federation requirements explicitly demand SAML, such as in the academic federations mentioned above. In every other scenario, especially with cloud-based IdPs and enterprise integrations, OIDC offers the better trade-off between simplicity, security and maintainability.

--- OpenImmo TYPO3 - Real Estate Import | Gosign ---
> OpenImmo in TYPO3: import property XML, display, filter. Real estate websites, AI-accelerated.

## Why real estate websites without OpenImmo integration create double work

Real estate agents maintain their properties in management software like FlowFact, onOffice, ImmoTool or JustImmo. Every property with images, prices, areas and location descriptions. This data should also appear on the website - but without manual double entry. OpenImmo is the German XML standard that bridges exactly this gap: the management software exports properties as XML, TYPO3 imports them automatically and displays them on the website.

Without OpenImmo integration, an office with 40 active properties maintains every listing twice - once in the management software and once on the website. At an average processing time of 15 minutes per property, that amounts to 10 hours per month for data maintenance alone that an automated pipeline completely eliminates.

## Typical use cases

**Automated import for real estate websites.** A real estate office with 30 to 100 active properties runs its website on TYPO3. Every night, onOffice exports all properties as OpenImmo XML to an FTP server. A TYPO3 scheduler task fetches the XML file, parses it and updates the properties in the database - new properties are created, changed ones updated, sold ones archived. By morning, the website is automatically current.

**Real estate portals with multi-provider aggregation.** A regional real estate platform aggregates properties from 10 to 30 agents. Each agent delivers their properties in OpenImmo format. TYPO3 imports all feeds, assigns properties to the respective providers and displays them on a shared platform with unified search and filtering.

**Builder websites with apartment overviews.** A builder sells 50 residential units in a new construction project. Availability and prices are maintained in the management software. Through OpenImmo import, the TYPO3 website updates the status of each unit automatically: available, reserved or sold. Prospects see in real time which apartments are still available.

## Technical architecture

The OpenImmo integration in TYPO3 consists of four components:

- **XML parser**: reads the OpenImmo XML file and converts it into PHP objects. The OpenImmo schema defines over 200 fields per property: purchase price, cold rent, living area, plot area, number of rooms, year of construction, energy certificate, location description, up to 30 images and floor plans. The parser must support all field variants and versions of the OpenImmo schema (1.2.7 through 1.2.8).
- **Import pipeline**: a scheduler task or CLI command executes the import regularly. The pipeline processes: file download (FTP, SFTP, local directory), XML validation, property mapping (OpenImmo fields to TYPO3 database fields), image import (images transferred to FAL), differential matching (only changed properties are updated).
- **Frontend display**: an Extbase plugin shows properties as a list with filtering (buy/rent, price range, area, number of rooms, postal code radius) and as a detail view with image gallery, location map (via maps2 or Leaflet) and contact form.
- **Brochure generation**: optionally, property detail pages can be downloaded as PDF brochures (via web2pdf or a custom PDF template engine).

Dependencies: TYPO3 Core, optionally maps2/geocoordinates for map display and radius search, optionally web2pdf for PDF brochures. The data volume per import can be substantial: a real estate office with 100 active properties and 20 images each produces an XML file of 5 to 15 MB and an image folder of 500 MB to 2 GB. The import process must handle these volumes efficiently without blocking server resources.

## Common problems and solutions

**Import aborts with XML parsing errors.** Real estate software sometimes exports non-schema-conformant XML. Missing required fields, invalid character encoding (ISO-8859-1 instead of UTF-8) or unclosed tags cause the abort. Solution: build an XML preprocessing step that validates the file before import, corrects encoding issues and fills missing required fields with default values. Gosign implements this step as a standalone service that logs errors and notifies the agent.

**Images not imported correctly.** OpenImmo XML references images through relative paths or URLs. If the FTP upload places images in a different directory than the XML expects, image references remain empty. Solution: configure the import to search for images relative to the XML directory and implement a fallback on filename matching if paths do not match.

**Deleted properties remain visible on the website.** OpenImmo uses two ways to mark properties as sold/deleted: through a status field in the XML or by omitting the property from the next export. Not all import extensions support both variants. Solution: configure the import for full reconciliation - properties missing from the current XML export are automatically marked as "sold" or archived.

## Migration and version compatibility

For OpenImmo in TYPO3, several extensions exist: openimmo (TER), femanager_openimmo and various proprietary solutions. Most are available for TYPO3 v10 and v11. For TYPO3 v12 and v13, the selection is more limited as some extensions are no longer actively maintained.

The OpenImmo format itself is stable. Version 1.2.7 has been the de facto standard for years, and all relevant real estate software packages support it. A switch to the newer version 1.2.8 requires parser adjustments but adds fields (energy certificate per GEG 2024, extended location descriptions).

Gosign recommends evaluating the existing OpenImmo extension during a TYPO3 upgrade from v10/v11 to v12. If the maintainer is no longer active, switching to a custom import pipeline with modern PHP (typed properties, enums for property types, event-based architecture) pays off. The initial effort is 5 to 8 days, but the pipeline is independent of third-party extensions and maintainable long-term. The pipeline can also be easily extended with additional data sources: IS24 interface, Immowelt API or proprietary XML formats from builders can be integrated as additional import adapters without changing the overall architecture.

--- Paywall TYPO3 - Content Monetization | Gosign ---
> Paywall for TYPO3: paid content, subscription models, access control. Custom development with AI, enterprise-grade.

## A paywall in TYPO3 is not a plug-in topic but an architectural decision

Paid content in TYPO3 looks at first glance like a trivial question: a few pages behind a login, a payment provider in front, done. In practice, the task turns out to be one of the most demanding in the TYPO3 environment. The core has no native notion of paid content, and the few freely available extensions at best cover simple login scenarios. Anyone who seriously wants to monetise content (metered paywall, hard paywall, freemium, tiered subscriptions) ends up at a bespoke development.

The typical audience are publishers, specialist portals and B2B content providers. A specialist publisher with 4,000 premium articles per year needs not only an access check but also a subscription lifecycle, a cancellation process, a legally compliant display of cancellation rights, an interface to financial accounting and reporting for the editorial team. All of that has to be represented inside an existing TYPO3 installation, without forcing the editorial team to learn a new CMS interface.

## Typical use cases

A first scenario is the metered paywall of a regional publishing house. The house publishes 500 paid articles per month and wants to offer anonymous readers three articles per calendar month before the paywall kicks in. The counting runs through a signed cookie that works even without login, and the unlock goes through an existing shop system with a monthly subscription.

A second scenario is the hard paywall at a B2B specialist publisher. Here there are no free articles, every access requires an active contract. The challenge lies in combining individual subscriptions, corporate subscriptions and IP-based campus access. The TYPO3 integration has to check in real time whether a reader has a valid contract and make the results performant for navigation, search and RSS feeds.

A third scenario is the freemium model of an industry portal. Registration is free, certain premium tools (whitepaper download, benchmark report, interactive calculator) require a paid subscription. The paywall has to decide per content element whether access exists and connect the payment flow including invoice creation.

A fourth scenario is the advertiser page of a media house. Here the focus is less on end customers and more on agencies that want to view a media kit area. Access is typically handled through one-time registration plus manual approval by the advertising sales team. TYPO3 reflects the approval status in the user profile and unlocks the protected area as soon as the status flips to "approved".

## Technical architecture

A production-ready paywall in TYPO3 consists of several layers. At the front stands a middleware that checks every content request for access. This middleware relies on an access policy that consolidates subscriptions, one-off purchases and free quotas. Underneath sits a persistence layer with subscription master data, payment history and contract state, synchronised with the external payment provider (Stripe, PayPal, Mollie, Adyen).

For the content side, there are two variants: either the content is trimmed server-side and only the portion the reader is entitled to is rendered, or the full text is delivered and a paywall overlay is controlled through server-side markup. The second variant is dangerous because browser tools can bypass the overlay. Professional paywalls always work server-side.

The TYPO3 integration runs through Extbase extensions with their own frontend middlewares, TCA overrides for the paywall status per content element and REST endpoints for the payment webhooks. PSR-15 middlewares have been the clean place for request interception since TYPO3 v9.

## Common problems and solutions

The first problem is bypass through caching. Anyone who enables page cache blindly delivers the full text of a paid article to a proxy and from there to every unauthorised reader. The solution is a clearly separated caching per user role or an exception of the paywall content from the page cache.

The second problem are race conditions in the subscription lifecycle. Concurrent cancellation and billing runs produce inconsistent states when the write order between TYPO3 and payment provider is not cleanly serialised. The solution is an event store for subscription events with a defined source of truth (usually the payment provider) and an idempotent import process.

The third problem is the conversion drop from slow paywall checks. Every millisecond of latency costs conversions. The solution are asynchronous access checks with a signed session token that avoids expensive database queries.

A fourth problem are tax and legal constraints. Subscription revenue is subject to VAT (US: sales tax equivalent), cancellation notices have to be phrased correctly for continuing obligations, and cross-border subscriptions fall under different VAT regimes. The solution is to align the paywall architecture from the start with financial accounting and the legal department and to rely on a payment provider that handles tax and invoicing.

## Migration and version compatibility

Because paywalls in TYPO3 are built as custom developments, version compatibility depends entirely on the development team. A cleanly built paywall extension runs on TYPO3 v11 to v13 if it relies on PSR middlewares, dependency injection and modern Extbase conventions. Problems arise from legacy code that still uses hook-based integrations from TYPO3 v7/v8.

For upgrades of an existing paywall, a two-stage migration is recommended. In the first step, the payment API clients and the access middlewares are lifted to modern TYPO3 conventions without changing the business logic. In the second step, the content changes follow, such as new subscription models, adjusted metered counting or additional payment providers. This separation considerably reduces the risk of regressions and allows clean testing of every step on a staging environment.

Gosign builds and modernises paywall systems for publishers and content providers. The combination of AI-supported code generation for the payment API integration and senior review for security, PCI compliance and race condition avoidance noticeably shortens time to market without sacrificing architectural quality.

--- PDF.js TYPO3 - PDF Viewer | Gosign ---
> PDF.js viewer integration for TYPO3. Display PDFs in the browser without plugins, without downloads.

## PDF.js embeds Mozilla's battle-tested PDF renderer directly into TYPO3 pages, the lightweight answer when editors want to show PDFs in the browser without forcing a download and without a heavy flipbook layer

When visitors click on a PDF, the browser either opens it in a new tab, downloads it or hands it over to an external viewer. None of these variants is satisfactory for editors who want to present a document in the context of a page. PDF.js solves this by embedding the viewer that Firefox and Chrome use internally as a standalone JavaScript module directly in the TYPO3 page. The result is consistent display across all browsers and devices, without users having to install a plug-in or leave the document.

An often overlooked advantage: the user does not leave the page. While an opened PDF in a new tab usually means the end of the session, the analytics connection remains intact with the embedded viewer. Anyone measuring how long visitors actually spend with a document can attribute the time directly to the content page and see which documents are really being read.

## Typical use cases

The most common use case is embedding single documents on content pages, for example a whitepaper on a product page, an application form on a service page or an event programme next to the event description. The editorial team uploads the PDF into FAL and references it through a content element, and PDF.js renders it inline. The visual corporate design of the page is preserved because frames, shadows and controls are styled through the project's sitepackage template.

The second case is download centres where several PDFs are presented with previews. Instead of blind file icons, users see the first page of the document and can decide with one click whether to read on or start the full download. For catalogues, forms and info sheets, this preview is often the decisive factor whether a document gets clicked at all.

Thirdly: low-barrier delivery of government and university documents. PDF.js makes the text layer of the PDF available, so that screen readers can read out the content, provided the PDF was correctly exported as a "tagged PDF".

## Technical architecture

For TYPO3, PDF.js exists in two flavours: as a classic TYPO3 extension that delivers the JavaScript library and adds a content element in the backend, or as a pure sitepackage integration where the PDF.js assets end up directly in the project's frontend build. The extension variant is more comfortable for editors because they can configure file selection, default zoom and preview parameters through the TYPO3 backend. The sitepackage variant is cleaner for developers because they control the version and integrate it into the existing build process.

Technically, PDF.js consists of two parts: a parser that loads the PDF file and breaks it down into an internal object graph, and a viewer that renders these objects into a canvas element. Both parts run entirely client-side. The worker approach ensures that parsing happens in a separate thread and does not block the main thread, which is important for smooth scrolling through large documents.

Integration runs through a TypoScript block and a Fluid partial that embeds an iframe or a container with the viewer. The URL of the PDF is passed as a query parameter, and the configuration of the UI elements (zoom buttons, page navigation, download link) runs through the viewer configuration block of PDF.js.

## Common problems and solutions

The first problem is cross origin. When the PDF is loaded from a different domain or an S3 bucket, the browser blocks access for security reasons. The solution is either a correct CORS configuration on the file server or a server-side proxy via a TYPO3 middleware that serves the PDF under the same domain.

Second problem: performance on large documents. A 200-page manual loads quickly because the viewer only renders the visible pages. It becomes problematic when the PDF itself is not optimised for the web and every single image is embedded at full print resolution. The only fix is to downscale the source document with Ghostscript or a comparable tool before it enters FAL.

Third problem: accessibility without a text layer. If the PDF is a pure scan without OCR, screen readers receive no text. In that case PDF.js alone is of no help: the PDF has to go through an OCR pass first. For public authorities, this is not an option but a legal obligation under accessibility standards.

## Migration and version compatibility

PDF.js as a library is continuously maintained by Mozilla and is in principle independent of the TYPO3 version. However, the TYPO3 extension wrappers that integrate PDF.js often lag behind the library version. Anyone upgrading to TYPO3 v12 or v13 should check whether the extension they use has a compatible version or whether switching to a sitepackage integration is the better path.

In direct comparison to pdfviewhelpers (server-side PDF generation) and rflipbook (flipbook effect), PDF.js is the option with the lowest overhead and the highest browser compatibility. For individual PDF embeds it is almost always the better choice than a heavy flipbook solution.

Anyone who embeds PDF.js in their sitepackage themselves should define a clear versioning strategy. The library receives regular security updates because PDF parsers are historically a popular attack target. An annual update rhythm is the minimum; for public authorities and critical infrastructure, quarterly makes more sense. Integration via npm and a frontend build process makes this much easier than a classic copy into the project directory.

Gosign integrates PDF.js as a sitepackage component or as a TYPO3 extension, depending on how much control editors need. For existing projects with legacy viewers, Gosign guides the migration and makes sure that accessibility and load time are not sacrificed for comfort.

--- pdfviewhelpers TYPO3 - PDF in Browser | Gosign ---
> pdfviewhelpers: display PDFs directly in the browser. Setup, performance & alternatives, AI-accelerated.

## pdfviewhelpers is the standard answer when TYPO3 has to generate PDFs server-side from Fluid templates, from invoices and tickets through to full reports

The name "pdfviewhelpers" hides a common misunderstanding. The extension does not render PDFs in the browser, it generates PDFs server-side from Fluid templates. Editors and developers looking for a solution for dynamic PDF generation in TYPO3 land in the right place: invoices, tickets, confirmations, certificates or reports are built with the same Fluid ViewHelpers that also power the frontend. The goal is to keep PDF generation inside the TYPO3 stack, without external tooling and without a separate layout workflow.

The fact that the extension therefore solves a completely different problem than PDF.js or rflipbook often becomes clear late in the day. Anyone searching for "TYPO3 PDF" quickly ends up at pdfviewhelpers and should ask early whether display or generation is needed. For generation, the extension is the technically most solid solution in the TYPO3 environment, because it builds on the Fluid paradigm that developers already master.

## Typical use cases

The classic case is form confirmations. A customer fills in a contact form, an event registration or a quote request on a TYPO3 page, and pdfviewhelpers generates a personalised PDF from the input that is sent by email or offered for download. The template lives as a Fluid template in the sitepackage, editors can adjust text and placeholders without touching code. The advantage over an external PDF service is that no data ever leaves the TYPO3 environment, which matters for data protection and GDPR compliance.

The second typical use case is automatically generated certificates. Training providers, chambers and associations generate attendance certificates, qualifications or membership cards from database content. The extension combines Extbase data with layout templates and delivers a finished document. A big plus: the template is versioned, reproducible in Git and not tied to a single person who owns the last Word template.

Third case: reports and lists. Controlling departments export a monthly report from a TYPO3-maintained database, for example as an export of an internal dashboard, a product list or a stock list, and receive a formatted PDF with header, footer and pagination.

## Technical architecture

pdfviewhelpers is based on TCPDF, the established PHP library for PDF generation, and exposes its features as Fluid ViewHelpers. Instead of writing TCPDF PHP code, developers write a template in which elements such as "pdf:document", "pdf:page", "pdf:text" and "pdf:image" appear as tags. This matches exactly the mental model that Fluid developers know from the frontend.

The extension is installed via Composer, and TCPDF comes along as a dependency. Templates live in the sitepackage under Resources/Private/Templates/Pdf and are called through a dedicated controller or directly from an Extbase action. For variable injection, pdfviewhelpers uses the same mechanisms as regular Fluid views, which keeps data sources and business logic cleanly separated.

Configuration happens through TypoScript and through the extension configuration in the install tool, where defaults for paper format, fonts and margins are stored. Anyone using custom TrueType fonts has to convert them via the TCPDF procedure and place them in Resources/Private/Fonts/.

## Common problems and solutions

The most common problem is font rendering. TCPDF does not support every font file out of the box, especially not current variable fonts or web fonts in WOFF2 format. Diacritical marks, special characters and accents are then replaced by question marks or boxes. The solution: convert the font beforehand with the TCPDF tool "tcpdf_addfont.php" and check the Unicode range. For multilingual documents with Cyrillic or Asian characters, it is worth using a font family with broad glyph coverage such as Noto Sans.

Second problem: complex layouts. As soon as a document requires multi-column content, floating graphics or dynamic line breaks, TCPDF hits its limits. Pagination and footers may not stay in sync. Pragmatic solution: keep the layout at a simple, report-style structure and embed complex graphics as pre-rendered images. If the typographic requirements are really high, an alternative such as headless Chrome with HTML-to-PDF conversion is often the better choice.

Third problem: performance on large documents. A 100-page report with many images can block the PHP process for several seconds. The solution lies in queue processing: move PDF generation out of the request lifecycle, run it as a background job through EXT:scheduler or a queue extension and email the user a download link.

## Migration and version compatibility

pdfviewhelpers is continuously maintained and is compatible with TYPO3 v11, v12 and v13. On upgrades, the main thing to watch is the PHP version jump: older TCPDF versions have compatibility issues with PHP 8.2 and 8.3, especially with deprecated warnings. The solution is usually an update of pdfviewhelpers, which pulls in a compatible TCPDF version.

Anyone still running a hand-rolled TCPDF setup from TYPO3 times before v9 has the chance, with the migration to pdfviewhelpers, to move PDF layouts from PHP code into maintainable Fluid templates. This pays off in the medium term because editors can then make simple adjustments themselves instead of always blocking developer time.

For new projects it is worth looking at the combination of pdfviewhelpers and headless Chrome alternatives such as wkhtmltopdf or Gotenberg. For pure form PDFs and simple reports, pdfviewhelpers is the fastest and most stable choice. As soon as typographically demanding layouts with web fonts, columns and background graphics come into play, an HTML-based pipeline plays to its strengths. The decision should be made early in the project, because switching pipelines later means rebuilding templates from scratch.

Gosign implements pdfviewhelpers, migrates legacy TCPDF setups and advises on alternatives for complex layouts. The combination of TYPO3 experience and AI-supported template generation usually cuts the implementation time by more than half.

--- personnel TYPO3 - Staff Directory | Gosign ---
> TYPO3 extension for employee directories. Teams, departments, contact details, profile pictures.

## personnel organises staff directories as a dedicated data model

Team pages, contact lists and department directories are standard on corporate websites but cannot sensibly be maintained as content elements. Anyone managing 50 employees with name, role, photo, phone, email, LinkedIn, department and location needs a dedicated data model. The personnel extension delivers exactly that: a clean table for people, linked to departments and locations, served through configurable Fluid templates. On every mid-sized TYPO3 project with a corporate presence, this requirement comes up repeatedly, and personnel is one of the established solutions for it. Alternatives like tt_address often fall short because they lack the department structure, the filter logic and the clean frontend integration.

## Typical use cases are law firms, agencies and universities

Law firms are a classic use case. A firm with 30 lawyers and 10 paralegals needs a team page with filtering by area of law (labour law, tax law, inheritance law), by location (Berlin, Munich, Frankfurt) and by role (partner, associate, trainee). personnel delivers the data model, and with a few Fluid adjustments the extension can be turned into a full firm directory. Each lawyer profile additionally contains the bar admission, memberships and published articles, so that clients can find the right contact at a glance.

Agencies and consultancies use personnel for team pages with short biographies, areas of expertise and contact links. Here it is less about filtering and more about presentation: large portraits, quotes, LinkedIn buttons and internal links to case studies the person has contributed to. The team page becomes a showroom, and personnel delivers the data model without every employee needing a dedicated content element.

Universities and research institutions have a different requirement: employees are often linked to institutes, chairs and research projects. personnel then becomes the master data model referenced by news articles, publication lists and events. The person does not only appear on a team page but also as an author in publications and as a contact on research projects. This turns the extension into a central person database used by several sub-extensions in parallel, delivering consistent profiles over many years.

## Technical architecture is Extbase-based with relations to department and location

personnel defines three central tables: tx_personnel_domain_model_personnel, tx_personnel_domain_model_department and tx_personnel_domain_model_location. A person is linked through foreign_field or an MM relation to one or more departments, plus a location. The database schema therefore models a typical matrix organisation.

The fields on a person cover the standard attributes: title, first name, last name, role, short description, phone, mobile, fax, email, address, profile picture (FAL), social media links. Through TCA overrides, additional fields such as areas of expertise, certifications or languages can be added without forking the extension.

The plug-in renders through Fluid templates from the extension directory. The standard variants are list, detail and filter view. Anyone building on grid systems such as CSS Grid or Flexbox overrides the list template in their own package. For filtering and search, the extension uses Extbase repositories with query builder filters that can be configured through TypoScript. A typical Gosign implementation offers a full-text search over name and role combined with select filters for department and location, so that users can find the right contact among 200 employees in a few clicks.

## Common problems involve GDPR, image rights and multilingual content

The first and most important support topic is GDPR. Employee data is personal data, and publication requires either consent or a legitimate interest. Anyone working with photos, direct dial numbers and private mobile numbers needs a clean process: document consent, on-off switch per person, automatic removal after the person leaves the company. personnel does not ship an audit log by default, but the workflow can be modelled with custom forms and an additional consent field. On departure from the company, the record should not simply be deleted but deactivated through a soft delete mechanism, so that old news articles still resolve correctly.

The second topic is image rights. Profile pictures live in FAL and are delivered through variants per display. What matters is that the copyright and the consent of the employee are documented, especially when the image is also used as a teaser in news articles or on social media. We recommend consistently maintaining the FAL fields "photographer" and "licence".

Thirdly, multilingual content is a practical problem. A person has one name, but their role and short biography differ between languages. personnel supports the TYPO3 standard for translations, but many projects forget to localise the department and location records as well, which leads to mixed language output.

## Migration to TYPO3 v12 requires an Extbase update and a TCA review

personnel is available in the TER for several TYPO3 versions. On the upgrade of a v10 or v11 installation, the Extbase repositories have to be moved to the current persistence API, and the TCA structure should be checked for type incompatibilities (especially with "passthrough" and "none" fields, which are validated more strictly in v12).

Gosign often migrates personnel installations as part of a team page refactor. In the same step, we check whether the dataset can be lifted to a more modern Person schema (with JSON-LD markup), whether filter and search scale with large datasets and whether the team page is delivered responsively and accessibly. For projects with very large datasets (several thousand people), it is also worth looking at indexing and lazy loading, so that the list view does not become a bottleneck on mobile devices. For particularly complex team structures, we occasionally replace personnel with a custom Extbase model, when the standard field structure does not suffice or a connection to an external HR system is required.

--- PhotoSwipe TYPO3 - Lightbox | Gosign ---
> PhotoSwipe is a touch-optimized lightbox library. The TYPO3 extension integrates PhotoSwipe as an image gallery: zoom, swipe gestures, deep linking.

## Bildergalerien auf mobilen Geräten funktionieren nur mit touch-optimierten Lightboxen

Die meisten TYPO3-Websites nutzen Lightboxen, die für Desktop-Browser entwickelt wurden: Fancybox, Colorbox, Magnific Popup. Auf Smartphones und Tablets fühlen sich diese Lösungen fremd an, weil Zoom und Navigation nicht auf Touch-Gesten reagieren, sondern auf Mausklicks. PhotoSwipe ist eine JavaScript-Library, die von Grund auf für Touch gebaut wurde. Die TYPO3-Extension integriert PhotoSwipe als vollständige Bildergalerie mit Pinch-to-Zoom, Swipe-Navigation, Deep-Linking und responsivem Layout. Bei unter 30 KB (minified + gzip) ist PhotoSwipe gleichzeitig eine der leichtgewichtigsten Lightbox-Lösungen am Markt.

Für Websites mit hohem Mobile-Anteil, also heute praktisch alle, ist das keine optionale Verbesserung, sondern eine funktionale Anforderung. Besucher erwarten die gleichen Gesten, die sie von der nativen Foto-App ihres Smartphones kennen.

## Typical use cases umfassen Portfolio-Galerien, Produktbilder und Medienarchive

Das häufigste Szenario sind Portfolio-Galerien auf Agentur-, Architektur- oder Fotografie-Websites. Ein Fotograf zeigt 20 bis 40 Bilder pro Projekt. Besucher klicken ein Thumbnail, sehen das Bild in voller Auflösung, zoomen per Pinch und wischen zum nächsten Bild. Deep-Linking bedeutet, dass jedes Bild eine eigene URL hat, die geteilt oder verlinkt werden kann. Das ist für SEO relevant, weil Google die Bilder über die Deep-Link-URLs indexieren kann.

Ein zweites Szenario sind Produktdetailseiten in E-Commerce-nahen TYPO3-Installationen. Ein Möbelhersteller zeigt fünf Perspektiven pro Produkt. PhotoSwipe rendert diese als Galerie mit High-Resolution-Zoom, der auf Desktop per Mausrad und auf Touch per Doppeltipp aktiviert wird. Die Zoom-Qualität hängt direkt von der Auflösung des Quellbilds ab. Wir empfehlen mindestens 2000 Pixel Breite für Produktbilder, die per Zoom betrachtet werden sollen.

Drittes Szenario: Medienarchive und Pressebereiche. Eine Universität stellt 500 Eventfotos bereit. PhotoSwipe rendert die Galerie performant, weil Bilder erst beim Aufblättern geladen werden (Lazy Loading). Die Thumbnail-Übersicht zeigt 50 Bilder pro Seite ohne spürbare Ladezeit.

## Technical architecture bindet PhotoSwipe als TYPO3 Content Element ein

Die Extension registriert ein eigenes Content-Element im TYPO3-Backend. Redakteure wählen Bilder aus der FAL-Mediathek, definieren die Sortierung und setzen optionale Bildunterschriften. Das Rendering übernehmen Fluid-Templates, die die PhotoSwipe-JavaScript-Library initialisieren und die Bild-URLs als JSON-Array übergeben.

PhotoSwipe selbst hat keine Abhängigkeiten, kein jQuery, kein Framework. Die Library besteht aus einer CSS-Datei und einer JS-Datei. Die TYPO3-Extension lädt beide über TypoScript-AssetCollector, sodass sie nur auf Seiten eingebunden werden, die tatsächlich eine Galerie enthalten. Das vermeidet unnötige Requests auf Seiten ohne Galerie.

Für responsive Bilder unterstützt die Extension srcset-Attribute: Der Browser lädt je nach Viewport die passende Bildgrösse. Das TYPO3-Bild-Processing erzeugt die Varianten automatisch. In Kombination mit WebP-Konvertierung (siehe webp-Extension) erreichen PhotoSwipe-Galerien optimale Ladezeiten.

## Common problems involve Konflikte mit anderen Lightbox-Extensions und fehlende Bildgrössen

Das häufigste Problem ist der Konflikt mit einer bereits installierten Lightbox-Extension. Wenn Fancybox und PhotoSwipe gleichzeitig aktiv sind, reagieren beide auf Bild-Klicks und erzeugen doppelte Overlays. Die Lösung: Die alte Lightbox-Extension deaktivieren und deren CSS/JS-Includes aus dem TypoScript-Setup entfernen. Ein grep nach "fancybox" oder "colorbox" in den TypoScript-Dateien zeigt, ob Reste der alten Library noch geladen werden.

Zweites Problem: Fehlende Bildgrössen. PhotoSwipe braucht für den Zoom die tatsächlichen Pixel-Dimensionen des Bildes. Wenn die Extension diese nicht aus den FAL-Metadaten lesen kann, funktioniert der Zoom nicht oder springt auf eine falsche Grösse. Die Lösung: Die FAL-Metadaten aller Galerie-Bilder prüfen. TYPO3 liest width und height beim Upload automatisch aus, aber importierte oder per CLI eingefügte Bilder haben manchmal leere Metadaten.

## PhotoSwipe v5 läuft unter TYPO3 v12, die v13-Kompatibilität requires ein Template-Update

Die aktuelle PhotoSwipe-Library ist in Version 5. Die TYPO3-Extension wurde für verschiedene TYPO3-Versionen angepasst und läuft unter v12 stabil. Für TYPO3 v13 ist ein Update der Fluid-Templates und der TypoScript-Konfiguration nötig, weil v13 den AssetCollector-Workflow leicht verändert hat. Gosign aktualisiert bei TYPO3-Upgrades alle Frontend-Extensions inklusive Lightbox und prüft, ob die Touch-Gesten auf aktuellen iOS- und Android-Versionen korrekt funktionieren.

--- powermail TYPO3 - Forms & CRM | Gosign ---
> The most widely used form plugin for TYPO3. Contact forms, multi-step forms, conditional logic, PDF export, CRM integration.

## powermail is the production-ready form system for TYPO3

Between the TYPO3 core form framework and full marketing automation tools there is a practical gap: editorial teams want to build forms without code, with conditional logic, file upload, GDPR consent, CRM forwarding and clean PDF export. That is exactly what powermail is built for. The extension from in2code is the most widely installed form plug-in in the TYPO3 ecosystem and runs on the majority of all mid-sized and large TYPO3 projects Gosign maintains. Since its first version more than a decade ago, powermail has become the Swiss army knife of TYPO3 form development and remains a valid choice even when the TYPO3 core form framework would theoretically suffice.

## Typical use cases range from contact forms to application portals

The most common scenario is trivial but unavoidable: contact forms on corporate websites that send emails to different departments. powermail handles this through conditional recipient routes without any developer intervention. Editors maintain the fields in the backend like a page content element, including order, required fields and validation. A typical corporate installation has three to five form variants: general contact enquiry, press contact, careers, support and product advice. Each variant lands in the right department inbox through its own recipient filter.

Considerably more demanding are multi-step application forms as they are common at public institutions and universities. An application portal asks for master data in step 1, the desired course in step 2, certificates via upload in step 3 and a GDPR consent with link to the privacy policy in step 4. powermail renders all four steps from a single form record and stores the progress between steps in a session, so that applicants can jump back if needed. Conditions show or hide fields depending on previous answers, which keeps complex forms such as scholarship applications or habilitation registrations manageable even with three-digit numbers of field combinations.

A third scenario that sets powermail apart from simpler extensions is integration with CRM and marketing tools. The finisher architecture allows data to be sent in parallel to HubSpot, Salesforce, Brevo or a custom webhook, before the confirmation email goes out. At Gosign, powermail is therefore also the standard tool for lead forms that feed directly into the sales process. On an enterprise project, we connected powermail to Salesforce Marketing Cloud and simultaneously forwarded through a webhook to the internal ticket system, so that sales and support teams could work on the enquiry in parallel.

## Technical architecture separates form definition, finisher and template

powermail consists of three conceptual layers: the form definition in the backend, the finishers that run after submission and the Fluid templates that handle rendering. Every layer is extensible without forking the extension. This clean separation makes powermail a robust tool for long-lived TYPO3 projects in which forms are maintained and extended over years.

Forms are stored as records in tx_powermail_domain_model_form. Every form contains pages (steps), every page contains fields. Field types range from text, email, select, radio and file upload through to HTML content and consent checkboxes. Conditional logic is maintained through the conditions module: "Show field B only when field A has the value X".

Finishers are the actual strength of the extension. The standard finisher sends emails, stores entries in the database and creates PDF exports. Additional finishers can be implemented via FinisherInterface: webhook delivery, CRM sync, Salesforce, SAP handoff. The order of the finishers is configurable, and each finisher can abort the process on error.

Templates live as Fluid files in the extension path and are typically overridden via SiteSet or a custom package. That means: a single global template overlay is enough to give all forms on a website a consistent appearance. Anyone who needs custom templates per form can reconfigure the template paths via TypoScript and maintain a template set per form type.

## Common problems involve spam, GDPR and email deliverability

The dominant support topic on public powermail forms is spam. Out of the box, the extension ships honeypot fields, timestamp checks and an optional reCAPTCHA v3 through ext:powermailrecaptcha. Still, spam ends up in the backend if the administration has not enabled the checks. We recommend combining honeypot and reCAPTCHA on every form and additionally using an IP-based rate limit finisher.

The second problem is GDPR compliance. Form consent has to be documented in an audit-proof way: date, version of the privacy policy, IP and user agent. The extension offers the consent storage, which logs consent decisions separately and makes them exportable for audits.

Thirdly, email deliverability is a constant topic. Confirmation emails end up in spam because the sender is not authenticated. SPF, DKIM and DMARC have to be configured correctly at the mail server level, and the powermail configuration should set a Return-Path and a valid Reply-To. For larger installations we additionally recommend a dedicated transactional mail service such as Brevo, Mailgun or Amazon SES, so that the delivery rate does not suffer under the general server reputation.

## TYPO3 v12 and v13 are fully supported

powermail is available shortly after every TYPO3 LTS release because in2code actively maintains the extension. The current series supports TYPO3 v11, v12 and v13 in parallel. When upgrading older installations, breaking changes mainly affect custom finisher classes, which have to be moved to the current interface signature, as well as Fluid templates that respond to ViewHelper changes.

Gosign typically migrates powermail installations together with the TYPO3 core upgrade. Before the jump, we check which custom finishers and templates exist, which third-party integrations are wired in and whether outdated plug-in variants are still in use. The migration usually runs without data migration, because the record structure of the form definition remains stable.

--- powermailrecaptcha TYPO3 - reCAPTCHA | Gosign ---
> Google reCAPTCHA integration for Powermail. Spam protection for the most widely used TYPO3 form plugin. Gosign advises on more privacy-friendly alternatives.

## Powermail without spam protection becomes a junk pile within weeks

Powermail is by far the most widely used form extension for TYPO3. Over 150,000 active installations (as of TER, 2026), from contact forms to application forms to complex multi-step inquiry workflows. The problem: every publicly accessible form without a CAPTCHA will eventually be found by bots. Typical result: 200 to 500 spam entries per day, overflowing inboxes, noisy statistics and forms that staff eventually ignore - including the genuine inquiries within.

powermailrecaptcha is the official companion to Powermail that integrates Google reCAPTCHA v2 or v3 into Powermail forms. The extension is maintained by in2code (the Powermail developer), ensuring short update cycles and high compatibility.

## Typical use cases

**Contact forms on corporate websites.** The standard scenario: a form with name, email, message and submit button. Without CAPTCHA, 50 to 300 spam messages arrive daily, mostly with links to pharmaceutical or casino sites. reCAPTCHA v3 (invisible, score-based) is ideal here: no additional click for the user, bots are detected in the background. A score below 0.5 (on a scale of 0 to 1) is classified as bot and the submission is blocked.

**Application forms with file upload.** Career pages where applicants upload CVs and cover letters are particularly spam-prone because bots distribute malware through the upload function. reCAPTCHA filters the automated submissions. Additionally, server-side file type validation (PDF, DOCX only) and a size limit (max. 10 MB) should be active.

**Multi-step forms with conditional logic.** Powermail can build forms with conditions: if "Industry = Real Estate" is selected, additional fields appear. For such forms, a CAPTCHA on the last page before submission suffices. powermailrecaptcha binds the check to the submit button by default, so it works with multi-step forms as well.

## Technical architecture

powermailrecaptcha extends Powermail via a TYPO3 Signal/Slot (v11) or PSR-14 Event (v12+). When rendering the form, the reCAPTCHA JavaScript is embedded (from google.com/recaptcha/api.js). On submission, the reCAPTCHA token is validated server-side: TYPO3 sends a POST request to `https://www.google.com/recaptcha/api/siteverify` with the token and secret key. Google responds with a score (v3) or confirmation (v2).

Configuration is done through TypoScript constants: Site Key and Secret Key (from the Google reCAPTCHA Admin Console), threshold score for v3 (default: 0.5), reCAPTCHA version (v2 Checkbox, v2 Invisible or v3). The keys are maintained in the TYPO3 backend under Constants, ideally via environment variables so they do not end up in the Git repository.

For v3 (invisible), no visible widget is rendered. The score is calculated in the background and stored in a hidden field. For v2 Checkbox, the familiar "I'm not a robot" widget appears. For v2 Invisible, nothing appears until the system detects a suspicious user and then shows a challenge (image selection).

## Common problems and solutions

**GDPR concerns about Google connection.** reCAPTCHA loads JavaScript from Google servers and transmits the user's IP address to Google. Since the Schrems II ruling and increasingly strict interpretation by data protection authorities, this is a real risk. Solution: only load reCAPTCHA when the user has consented via cookie banner (consent integration). Or switch entirely to European alternatives: Friendly Captcha (servers in the EU, no tracking), hCaptcha (more GDPR-compliant than reCAPTCHA but US-based servers) or a pure honeypot strategy without external services.

**reCAPTCHA v3 blocks real users.** The scoring algorithm is a black box. Some real users (e.g. behind VPN, with ad blocker, on older devices) receive low scores and are incorrectly blocked. Solution: set the threshold to 0.3 instead of 0.5 and additionally implement a honeypot field. Alternatively: display a fallback to reCAPTCHA v2 Checkbox on low scores instead of blocking outright.

**Extension conflict with Content Security Policy.** Since TYPO3 v12, the Core supports Content Security Policies (CSP). reCAPTCHA JavaScript from google.com must be permitted in the CSP, otherwise it is blocked. Solution: add `script-src` and `frame-src` for `https://www.google.com/recaptcha/` and `https://www.gstatic.com/recaptcha/` in the CSP configuration.

## Migration and version compatibility

powermailrecaptcha supports TYPO3 v11, v12 and v13 (the latter since Q1 2026). The extension follows Powermail's release cycle: when Powermail supports a new TYPO3 version, powermailrecaptcha follows within weeks.

For projects switching from reCAPTCHA to a more GDPR-friendly alternative, the conversion is manageable. Friendly Captcha offers its own Powermail plugin (powermail_friendlycaptcha) that works as a drop-in replacement: install the extension, enter keys, deactivate powermailrecaptcha. The form configuration in Powermail itself remains unchanged. Gosign recommends Friendly Captcha as the default for new projects and offers migration of existing forms as a fixed-price service.

An often overlooked aspect is spam prevention beyond CAPTCHAs. Powermail natively offers a honeypot field (an invisible form field that only bots fill in). Combined with a time check (form must be open for at least 3 seconds before submission), the majority of automated spam can be filtered without external services. Gosign deploys a three-layer strategy for projects where GDPR compliance is the priority: honeypot and time check as the first layer (zero external requests), Friendly Captcha as the second layer (EU servers) and server-side content analysis as the third layer (link density, language, known spam patterns). This combination achieves a spam detection rate of over 99% without Google services.

For switching from powermailrecaptcha to Friendly Captcha, Gosign estimates 2 to 4 hours per website, including installation, configuration, testing all forms and deactivating the old extension.

--- Price Calculator TYPO3 | Gosign ---
> Configurators, cost calculators, quote generators directly in TYPO3. Custom development for specific calculation logic with interactive frontend.

## Preisrechner im Web generieren qualifizierte Leads, aber nur wenn die Kalkulation stimmt

Besucher, die auf einer Website einen Preis berechnen, sind die wertvollsten Leads im B2B-Vertrieb. Sie haben ein konkretes Vorhaben, kennen ihre Anforderungen und erwarten eine belastbare Zahl. Trotzdem arbeiten die meisten TYPO3-Websites mit statischen Preistabellen oder einem "Preis auf Anfrage"-Button, der den Besucher in ein generisches Kontaktformular schickt. pricecal schliesst diese Lücke: Die Extension ermöglicht Konfiguratoren, Kostenrechner und Angebotsgeneratoren direkt in TYPO3, mit spezifischer Kalkulationslogik und einem interaktiven Frontend, das in Echtzeit reagiert.

Der Unterschied zu externen Tools wie Calconic oder Outgrow: Die Daten bleiben auf dem eigenen Server, die Kalkulation ist unter voller Kontrolle, und das Design fügt sich nahtlos in die bestehende Website ein.

## Typical use cases gehen vom Umzugsrechner bis zum Industriekonfigurator

Das zugänglichste Szenario ist der Kostenrechner für Dienstleistungen. Ein Umzugsunternehmen fragt Wohnungsgrösse, Stockwerk, Entfernung und Sonderwünsche (Klavier, Aquarium) ab und zeigt einen Richtpreis. Der Besucher sieht sofort, ob der Service im Budget liegt, und kann direkt ein verbindliches Angebot anfordern. In der Praxis steigern solche Rechner die Anfragequote um 40 bis 70 Prozent gegenüber einem statischen Kontaktformular, weil der Besucher bereits eine Preiserwartung hat.

Ein zweites Szenario sind Produktkonfiguratoren im verarbeitenden Gewerbe. Ein Fensterhersteller bietet 12 Rahmentypen, 8 Glasarten, 4 Beschlagvarianten und 20 Farben. pricecal berechnet den Preis aus der Kombination und zeigt ihn live an, während der Besucher konfiguriert. Bei 12 x 8 x 4 x 20 = 7.680 möglichen Kombinationen ist eine statische Preisliste unmöglich. Der Konfigurator ersetzt sie durch eine dynamische Berechnung, die der Redakteur über Preis-Matrizen im Backend pflegt.

Drittes Szenario: ROI-Rechner für Software-Produkte. Ein SaaS-Anbieter lässt Besucher Mitarbeiteranzahl, aktuellen Zeitaufwand und Stundensatz eingeben. Der Rechner zeigt die jährliche Ersparnis durch das Produkt. Das ist kein Verkaufstrick, sondern ein Werkzeug, das dem Besucher hilft, die Investition intern zu begründen.

## Technical architecture separates Kalkulationslogik, Eingabefelder und Ergebnisdarstellung

pricecal ist als Custom Content Element in TYPO3 implementiert. Im Backend definiert der Administrator die Eingabefelder (Slider, Dropdown, Number Input, Checkbox), die Kalkulationsformel und die Ergebnisdarstellung. Die Formel kann einfache Arithmetik (Preis = Menge x Einzelpreis x Faktor) oder komplexere Logik mit Bedingungen (wenn Stockwerk > 3, dann Zuschlag 15%) abbilden.

Das Frontend rendert die Eingabefelder über Fluid-Templates und berechnet den Preis per JavaScript im Browser. Kein Server-Roundtrip bei jedem Slider-Schritt, das Ergebnis aktualisiert sich in Echtzeit. Für komplexere Kalkulationen, etwa wenn Preis-Matrizen oder externe Datenquellen (ERP, Lagerverfügbarkeit) eingebunden werden müssen, kann die Berechnung über einen AJAX-Endpoint an den Server delegiert werden.

Die Ergebnisse lassen sich optional als PDF generieren und per E-Mail versenden. In Kombination mit powermail kann das Kalkulationsergebnis als Hidden Field in ein Kontaktformular übergeben werden, sodass der Vertrieb die exakte Konfiguration des Interessenten sieht.

## Common problems involve Rundungsfehler und die Pflege komplexer Preislogiken

Das häufigste Problem bei Preisrechnern ist die korrekte Rundung. JavaScript-Fliesskomma-Arithmetik liefert bei 0,1 + 0,2 den Wert 0,30000000000000004. Bei Preisen mit zwei Nachkommastellen führt das zu sichtbaren Fehlern. Die Lösung: Alle Berechnungen intern in Cent (Integer) durchführen und erst bei der Anzeige in Euro umrechnen.

Zweites Problem: Die Pflege der Kalkulationslogik. Wenn ein Produktmanager die Preise vierteljährlich anpasst, muss er die Formeln im Backend verstehen. Bei einfachen Kalkulationen (Menge x Preis) ist das trivial. Bei Konfiguratoren mit 50 Parametern und gestaffelten Rabatten wird die Pflege zum Risiko. Wir empfehlen, komplexe Preislogik als TypoScript-Konfiguration oder YAML-Datei auszulagern und versioniert in Git zu pflegen, statt sie im Backend zu bearbeiten.

Drittes Thema: Mobile Bedienbarkeit. Slider sind auf Touchscreens unpräzise, weil der Finger einen grösseren Bereich abdeckt als ein Mauszeiger. Bei Preisrechnern mit feiner Granularität (z.B. Quadratmeter von 10 bis 500) sollten Slider durch Eingabefelder mit Plus/Minus-Buttons ersetzt werden.

## pricecal ist Custom-Entwicklung und damit versionsunabhängig

Da pricecal keine Community-Extension aus dem TER ist, sondern eine Custom-Entwicklung, gibt es keinen externen Release-Zyklus. Die TYPO3-Kompatibilität hängt davon ab, wie die Extension intern implementiert ist. Installationen, die auf Extbase und Fluid basieren, laufen unter TYPO3 v12 und v13 nach Anpassung der Namespace-Deklarationen und der Content-Element-Registrierung. Gosign setzt bei neuen Preisrechner-Projekten auf eine Framework-unabhängige Architektur: Die Kalkulationslogik läuft als eigenständiges JavaScript-Modul, das TYPO3 nur als Content-Element einbindet, aber keine Extbase-Abhängigkeit hat.

--- Social Feed TYPO3 - Instagram & Co | Gosign ---
> Integrate social media feeds (Instagram, Facebook, Twitter/X) into TYPO3. API-based, cached, GDPR-compliant without tracking pixels.

## Social media feeds on the website look great but regularly break through API changes

Marketing teams want to display Instagram posts, Facebook updates or Twitter/X tweets on the corporate website. The reasoning is understandable: fresh content without editorial effort, social proof through real posts, visual enhancement through image material. The reality looks different. Meta, Twitter/X and TikTok regularly change their APIs, restrict access rights or shut down free endpoints entirely. Twitter/X eliminated free API access in 2023, charging at least 100 USD/month for read access since then. The Instagram Basic Display API was replaced by the Instagram Graph API in 2024. Anyone operating a social feed integration must track these changes or the feed stays empty.

pxa_social_feed (developed by Pixelant) is the best-known TYPO3 extension for social media feeds. It supports Instagram, Facebook and Twitter/X, stores feed data locally (cached) and renders it as a TYPO3 content element. The extension is open source and maintained by the community.

## Typical use cases

**Corporate websites with Instagram feed on the homepage.** A company posts 3 to 5 times per week on Instagram and wants to display the latest 6 to 12 posts as an image gallery on the homepage. pxa_social_feed fetches posts via cron job (e.g. every 30 minutes), stores images, captions and links locally and renders them in a configurable grid. The advantage over an embed (iframe): no external requests on page load, no tracking pixels, faster loading time.

**Event pages with live feed.** Conferences, trade shows or company celebrations use a hashtag (e.g. #GosignSummit2026). The feed shows all public posts with this hashtag in real time (or near-real-time with 5-minute caching). Moderation happens in the TYPO3 backend: individual posts can be hidden before they appear on the website.

**Employer branding pages.** HR departments show insights from daily work life on the careers page, posted by employees on Instagram or LinkedIn. The integration collects posts from one or more accounts and curates them editorially. Limitation: LinkedIn offers no open API for feed integration, so automation is restricted to Instagram and Facebook.

## Technical architecture

pxa_social_feed uses the APIs of the respective platforms: Instagram Graph API (via a Facebook app token), Facebook Graph API and Twitter/X API v2. Each platform requires its own authentication: Facebook and Instagram need a Long-Lived User Token (valid 60 days, must be renewed regularly), Twitter/X needs a Bearer Token (Application-only Auth).

The extension stores feed data in a local TYPO3 table (tx_pxasocialfeed_domain_model_feed). Images are downloaded and stored as FAL references. On page load, only local data is rendered - no external API calls. A scheduler task fetches new posts and removes old ones (configurable: keep last 50 posts, delete older ones).

Output uses Fluid templates configured via TypoScript. Standard layouts: grid (3-4 columns), masonry, slider (via custom JavaScript integration). The HTML/CSS can be fully customized without modifying extension code.

For GDPR compliance, the local cache is crucial: because images and texts reside on the company's own server, no data is transmitted to Meta or Twitter/X on page load. No tracking pixel, no cookie consent needed for the feed itself. Exception: if the "View original post" link is included, a redirect occurs on click.

## Common problems and solutions

**Instagram token expires, feed stays empty.** The Long-Lived Token has a lifespan of 60 days. If nobody renews it, the import stops. Solution: set up a cronjob that automatically extends the token via API call (the endpoint `GET /oauth/access_token?grant_type=fb_exchange_token` returns a new token). pxa_social_feed offers a token refresh function in the backend since version 4.x.

**Twitter/X feed stops working after API change.** Since 2023, the Twitter/X API is paid. The Basic tier (100 USD/month) allows reading 10,000 tweets/month. For most corporate websites that suffices, but the cost-benefit equation must work. Solution: check whether the Twitter/X feed actually drives traffic or engagement. If not, remove the channel and keep only Instagram/Facebook.

**Images not loading or appearing pixelated.** The Instagram Graph API delivers images in various sizes. pxa_social_feed stores the version delivered by the API by default. Solution: set image size to "original" in the extension configuration and generate responsive variants via `<f:image>` in the Fluid template.

## Migration and version compatibility

pxa_social_feed supports TYPO3 v11 and v12. Compatibility with TYPO3 v13 is in community development (as of April 2026) but not officially released. For projects on TYPO3 v13, there are two options: wait for the official update or build a custom feed integration as middleware that runs independently of the TYPO3 version.

Fundamentally, Gosign recommends thinking of social feed integrations as decoupled components: a microservice or Cloudflare Worker fetches the feeds, stores them as JSON, TYPO3 reads the JSON and renders it. This eliminates the dependency on a TYPO3 extension and any API change is fixed in one place, independent of the CMS.

When deciding which social media channels to embed on the website, Gosign recommends a data-driven evaluation: which channel actually drives engagement? Instagram feeds with high-quality images work well on corporate websites, Twitter/X feeds are not worth the effort for most companies since API costs were introduced, and Facebook feeds have declining relevance as organic reach has been falling for years. LinkedIn would be the most relevant channel for B2B companies but offers no open feed API. The pragmatic solution: embed Instagram as the primary channel, manually curate LinkedIn posts as TYPO3 content, and skip Twitter/X unless the channel is business-critical.

The total effort for a social feed integration (Instagram, cached, GDPR-compliant, with backend moderation) is 2 to 5 development days, depending on whether pxa_social_feed is sufficient or a custom solution is needed.

--- RaiseNow TYPO3 - Donations | Gosign ---
> RaiseNow is a Swiss donation platform. TYPO3 integration enables online donations, recurring donations and campaigns. For NPOs, associations and foundations.

## Non-Profit-Organisationen verlieren Spenden, wenn der Spendenprozess die Website verlässt

Jeder Medienbruch kostet Conversion. Wenn ein Besucher auf "Jetzt spenden" klickt und auf eine externe Plattform weitergeleitet wird, brechen je nach Studie 30 bis 50 Prozent ab. RaiseNow ist eine Schweizer Spenden-Plattform, die genau dieses Problem löst: Die TYPO3-Integration bettet den gesamten Spendenprozess direkt in die Website ein. Spendenbetrag, Zahlungsmethode, Adressdaten und Bestätigung laufen in einem eingebetteten Widget, ohne dass der Besucher die Seite verlässt. Für NPOs, Vereine und Stiftungen, die auf TYPO3 setzen, ist das die sauberste Integration zwischen CMS und Spenden-Plattform.

RaiseNow verarbeitet jährlich über 300 Millionen Franken an Spenden und ist in der Schweiz der Marktführer für digitales Fundraising. Die TYPO3-Extension bringt dieses Ökosystem direkt ins Backend.

## Typical use cases range from Einmalspenden bis zu Dauerspender-Kampagnen

Das Basisszenario ist die Einmalspende auf der Startseite oder einer Kampagnenseite. Ein Hilfswerk startet eine Spendenkampagne nach einer Naturkatastrophe. Die Landingpage zeigt den Fortschrittsbalken (gesammelt / Ziel) und ein Spendenformular mit vorgeschlagenen Beträgen (25, 50, 100, frei wählbar). Der Besucher spendet per Kreditkarte, TWINT, PostFinance oder PayPal, erhält eine sofortige Bestätigung und eine Spendenquittung per E-Mail. Die gesamte Transaktion dauert unter 60 Sekunden.

Ein zweites, wirtschaftlich wichtigeres Szenario sind Recurring Donations (Dauerspenden). Eine Tierschutzorganisation bietet monatliche Patenschaften: 15 Franken pro Monat für die Pflege eines Tieres. RaiseNow verwaltet die wiederkehrenden Zahlungen, benachrichtigt bei fehlgeschlagenen Lastschriften und bietet dem Spender ein Self-Service-Portal zur Anpassung. Dauerspenden machen bei erfolgreichen NPOs 40 bis 60 Prozent des Gesamtvolumens aus, weil sie planbare Einnahmen erzeugen.

Drittes Szenario: Peer-to-Peer-Fundraising. Ein Sportverein organisiert einen Spendenlauf. Jeder Läufer erstellt eine persönliche Spendenseite, teilt sie in sozialen Netzwerken und sammelt Spenden für den Verein. RaiseNow aggregiert die Beträge, ordnet sie den Läufern zu und zeigt ein Live-Ranking. Die TYPO3-Extension stellt die Kampagnen-Übersicht und die persönlichen Spendenprofile als Content-Elemente bereit.

## Technical architecture uses RaiseNow-Widgets per iFrame und API-Callback

Die TYPO3-Extension integriert RaiseNow über ein JavaScript-Widget, das als iFrame in die Seite eingebettet wird. Die Konfiguration (API-Key, Kampagnen-ID, Zahlungsmethoden, Vorschlags-Beträge) wird im TYPO3-Backend als Plugin-Konfiguration gesetzt und per TypoScript an das Widget übergeben.

Nach einer erfolgreichen Spende sendet RaiseNow einen Webhook an einen konfigurierbaren Endpoint. Dieser Webhook kann in TYPO3 verarbeitet werden, um Spenden in einer lokalen Datenbank zu protokollieren, Fortschrittsbalken zu aktualisieren oder Dankes-E-Mails über den TYPO3-eigenen Mailversand auszulösen. Die Zahlungsabwicklung selbst läuft vollständig auf RaiseNow-Infrastruktur, was PCI-DSS-Konformität ohne eigene Zertifizierung ermöglicht.

Die Spendenquittung wird von RaiseNow generiert und enthält alle steuerlich relevanten Angaben. Für Organisationen, die in Deutschland als gemeinnützig anerkannt sind, lässt sich die Quittung mit der Vereins-Steuernummer und dem Freistellungsbescheid versehen.

## Common problems involve GDPR-Konformität und Widget-Styling

Das grösste Thema für deutsche Organisationen ist die GDPR compliance. RaiseNow ist ein Schweizer Unternehmen und verarbeitet Zahlungsdaten auf Schweizer Servern. Seit dem Angemessenheitsbeschluss der EU-Kommission gilt die Schweiz als sicheres Drittland, aber die privacy policy muss dennoch transparent ausweisen, welche Daten an RaiseNow übermittelt werden. Organisationen, die auf Nummer sicher gehen wollen, holen eine explizite Einwilligung über einen Consent-Layer ein, bevor das RaiseNow-Widget geladen wird.

Zweites Problem: Das Widget-Styling. RaiseNow-Widgets haben ein eigenes CSS, das sich nicht vollständig von aussen überschreiben lässt. Farben, Schriftarten und Button-Styles können über die RaiseNow-Konfiguration angepasst werden, aber das Layout des Formulars ist fixiert. Für Organisationen mit strengen CI-Vorgaben kann das ein Kompromiss sein. Die Alternative ist ein Custom-Spendenformular, das die RaiseNow-API direkt anspricht, was allerdings PCI-DSS-Anforderungen an die eigene Infrastruktur stellt.

## RaiseNow wird aktiv weiterentwickelt, die TYPO3-Extension braucht manuelle Pflege

RaiseNow selbst wird kontinuierlich weiterentwickelt. Neue Zahlungsmethoden (Apple Pay, Google Pay) und Features (QR-Rechnungen) werden regelmässig ergänzt. Die TYPO3-Extension ist jedoch ein Community-Projekt und wird nicht von RaiseNow offiziell gepflegt. Das bedeutet: Wenn TYPO3 v13 eine Änderung in der Plugin-Registrierung einführt, muss die Extension manuell angepasst werden. Organisationen, die RaiseNow langfristig in TYPO3 einsetzen, sollten die Extension in ihrem eigenen Repository forken und bei TYPO3-Upgrades mitpflegen. Gosign übernimmt diese Pflege im Rahmen von Wartungsverträgen und prüft bei jedem TYPO3-Update die RaiseNow-Kompatibilität.

--- rapidmail TYPO3 - Newsletter Integration | Gosign ---
> Integrate rapidmail in TYPO3: subscriber sync, double opt-in, segmentation. AI-accelerated, GDPR-compliant.

## rapidmail is the pragmatic newsletter answer for GDPR-sensitive TYPO3 projects

Anyone running a newsletter in Europe under a GDPR-compliant setup sooner or later looks at European providers. rapidmail is one of the most widely used: German server locations, German support, clear pricing models, a solid API. For TYPO3 websites that collect newsletter signups directly in the frontend and want recipients to end up automatically in lists and segments, integrating this service is a standard task. The results are often sobering, however, because the official TYPO3 extension only covers basic functions and projects with real requirements quickly hit its limits.

The audience are mid-sized companies, associations, public utilities, universities, NGOs and publishers that want to build their existing customer communication on a GDPR-compliant platform. A typical use case: a regional energy supplier with 80,000 household customers wants to send targeted newsletters to four segments (private customers, business customers, subsidy customers, press contacts) and pull the segmentation automatically from TYPO3 user groups.

## Typical use cases

A first scenario is a simple signup path via Powermail. An association wants to enrol visitors of its TYPO3 website in the newsletter. The Powermail finisher hands name, email and a segment flag to the rapidmail API, rapidmail sends the confirmation email, and after the click on the confirmation link the contact is activated in the right recipient list.

A second scenario is the synchronisation of user groups from TYPO3 into rapidmail segments. A university maintains roles such as students, alumni and staff in the TYPO3 intranet. Every role change should automatically update the segment assignment in rapidmail, so that mailings go to exactly the right audience, without double data maintenance.

A third scenario is the event participant handling. A publishing house organises ten industry conferences per year and wants to hand participants over into a follow-up communication track automatically. Registration happens in a TYPO3 form, the API writes the participant into an event list, and rapidmail triggers an automated drip campaign with three mails.

A fourth scenario is unsubscribe synchronisation. When a reader opts out through the newsletter link in rapidmail, the TYPO3 profile centre has to pick up the status, so that the user does not see "newsletter active" on their next login. This requires a return channel: rapidmail reports the unsubscribe via webhook, TYPO3 acknowledges it and updates the user group.

## Technical architecture

rapidmail provides a REST API with OAuth authentication. The TYPO3 integration runs either through a Powermail finisher, a form framework extension or a dedicated Extbase service that talks to the API. Gosign usually relies on a lean service class that encapsulates the API calls and is made available via dependency injection in controllers, finishers and scheduler tasks.

For ongoing synchronisation of user groups, a scheduler task is typically set up that transmits delta updates to rapidmail every 15 minutes. Delta detection runs through a TYPO3-internal audit field (last change per user) or through a hash comparison based on the API response. What matters is that every transmission is idempotent, so that a re-run after an error does not create duplicates.

Double opt-in is fully handled on the rapidmail side: TYPO3 signs up a contact, rapidmail sends the confirmation email, the reader confirms, rapidmail activates the contact. TYPO3 does not have to provide anything of its own for this; what matters is only that the TYPO3 page shows the user an understandable intermediate page ("please confirm the signup in your inbox").

## Common problems and solutions

The first problem is missing bounce handling. Anyone who does not evaluate the API responses does not notice that rapidmail permanently rejects certain email addresses. The solution is to log API responses in a dedicated TYPO3 table, plus a periodic reconciliation against the bounce lists that rapidmail provides through the API.

The second problem are segmentation mismatches. When a contact falls into several user groups that point at different rapidmail lists, inconsistent states emerge. The solution is a clear 1:1 or 1:n mapping logic that is cleanly defined before implementation and hard-coded in the service layer.

The third problem is API rate limit violation. rapidmail throttles API usage. On an initial migration of 20,000 contacts in a single scheduler run, the job inevitably hits the limit. The solution is a chunked import with 100 contacts per batch and a pause control between batches.

A fourth problem is the matching imprecision on duplicate profiles. When a user signs up several times with different email spellings (with or without dot, upper or lower case), duplicates in rapidmail and inconsistent states between TYPO3 and the newsletter system emerge. The solution is a normalisation of the email address before every API call (lowercase, whitespace trim, consciously ignore or consistently apply the dot rule for Gmail addresses).

## Migration and version compatibility

The integration is a custom extension and therefore largely independent of the TYPO3 version: it runs cleanly on TYPO3 v11, v12 and v13 as long as the API client code relies on modern HTTP clients (Guzzle) and dependency injection. On the upgrade of an existing integration, the most common pain point is the migration from TYPO3 hooks to PSR-15 middlewares, an effort that Gosign usually takes care of in a few days with AI-supported code analysis.

On the rapidmail side, the API changes slowly but not without breaks: between major versions, individual endpoints have been renamed, fields restructured or authentication methods modernised. Anyone bringing an older integration from 2018 or 2020 up to date should plan half a sprint for the API update and run the tests against a staging list in rapidmail before touching production. For these refresh tasks, Gosign maintains a standard checklist that covers the usual pitfalls (authentication, pagination, error response format) and makes the migration reproducible.

--- Recipe Plugin TYPO3 | Gosign ---
> Recipe extension for TYPO3: ingredients, preparation steps, nutritional values, portions. With Schema.org Recipe markup for Google Rich Snippets.

## Rezepte ohne Schema.org-Markup verschenken die wertvollsten Positionen in den Google-Suchergebnissen

Rezept-Suchanfragen gehören zu den wenigen Bereichen, in denen Google Rich Snippets mit Bild, Bewertung, Kochzeit und Kalorien anzeigt. Websites ohne korrektes Schema.org-Recipe-Markup erscheinen als einfacher blauer Link unter den visuell dominanten Rich Results. Die TYPO3 Recipe-Extension strukturiert Rezepte mit allen Feldern, die Google für Rich Snippets erwartet: Zutaten, Zubereitungsschritte, Nährwerte, Portionen, Zubereitungszeit, Schwierigkeitsgrad. Das Schema.org-Markup wird automatisch im JSON-LD-Format ausgegeben, ohne dass Redakteure HTML bearbeiten müssen.

Für Food-Blogs, Verlage mit Rezeptrubriken und Lebensmittelhersteller mit Rezeptdatenbanken ist das der Unterschied zwischen Sichtbarkeit und Unsichtbarkeit in der Google-Suche.

## Typical use cases umfassen Food-Blogs, Produktwebsites und Gesundheitsportale

Das häufigste Szenario ist der Food-Blog oder das Online-Magazin mit Rezeptrubrik. Ein Verlag publiziert wöchentlich fünf neue Rezepte. Jedes Rezept wird im TYPO3-Backend als strukturierter Datensatz angelegt: Titel, Beschreibung, Zutatenliste mit Mengenangaben, Zubereitungsschritte als nummerierte Liste, Zeitangaben (Vorbereitung, Kochzeit, Gesamtzeit), Nährwerte pro Portion und ein Titelbild. Die Extension generiert daraus eine Detailseite mit korrektem Schema.org-Markup. Google zeigt in den Suchergebnissen das Bild, die Sterne-Bewertung, die Gesamtzeit und die Kalorienzahl.

Ein zweites Szenario sind Produktwebsites von Lebensmittelherstellern. Ein Olivenöl-Produzent zeigt zu jedem Produkt passende Rezepte. Die Rezepte verlinken auf das Produkt, das Produkt verlinkt auf die Rezepte. Diese bidirektionale Verknüpfung stärkt sowohl die Produktseite als auch die Rezeptseite in der Google-Bewertung.

Drittes Szenario: Gesundheitsportale und Ernährungsberatungen. Hier stehen die Nährwertangaben im Vordergrund. Ein Diabetes-Portal zeigt Rezepte mit Broteinheiten, glykämischem Index und Kohlenhydraten pro Portion. Die Extension erlaubt Custom Fields, sodass diese medizinisch relevanten Werte als strukturierte Daten erfasst und im Frontend prominent angezeigt werden.

## Technical architecture uses Extbase-Records mit automatischem JSON-LD-Output

Die Extension registriert einen eigenen Record-Typ für Rezepte in der TYPO3-Datenbank. Jeder Record enthält Felder für Titel, Beschreibung, Zutaten (als Inline-Relational-Records), Schritte (als sortierbare Liste), Zeiten (prepTime, cookTime, totalTime im ISO-8601-Format), Nährwerte (Kalorien, Fett, Kohlenhydrate, Protein) und Bilder über FAL.

Das Frontend-Rendering läuft über Fluid-Templates, die das Rezept als HTML-Seite darstellen und gleichzeitig ein JSON-LD-Script-Tag mit dem Schema.org/Recipe-Markup in den Head der Seite schreiben. Das Markup folgt der Google-Spezifikation: name, image, author, datePublished, description, prepTime, cookTime, totalTime, recipeYield, recipeIngredient, recipeInstructions und nutrition.

Die Listenansicht zeigt Rezepte als Kacheln mit Bild, Titel, Gesamtzeit und Bewertung. Filter nach Kategorie (Vorspeise, Hauptgericht, Dessert), Diätform (vegetarisch, vegan, glutenfrei) und Zubereitungszeit sind über TypoScript konfigurierbar.

## Common problems involve fehlende Pflichtfelder und ungültige Zeitformate

Das grösste Problem für die Rich-Snippet-Darstellung sind fehlende Pflichtfelder. Google verlangt mindestens name, image und recipeInstructions. Wenn ein Redakteur ein Rezept ohne Bild oder ohne Zubereitungsschritte anlegt, wird das Schema.org-Markup zwar ausgegeben, aber Google ignoriert es und zeigt keinen Rich Snippet. Die Lösung: Im TYPO3-Backend Pflichtfeld-Validierung aktivieren, sodass Rezepte ohne Bild und ohne mindestens einen Zubereitungsschritt nicht gespeichert werden können.

Zweites Problem: Ungültige Zeitformate. Schema.org erwartet ISO-8601-Duration (PT30M für 30 Minuten, PT1H15M für 1 Stunde 15 Minuten). Wenn die Extension die Redakteur-Eingabe "30 min" nicht korrekt in PT30M umwandelt, scheitert die Validierung im Google Rich Results Test. Die meisten Recipe-Extensions bieten dafür separate Eingabefelder für Stunden und Minuten, die intern in ISO-8601 konvertiert werden.

Drittes Thema: Duplicate Content bei Rezepten, die auf mehreren Seiten eingebettet sind. Wenn dasselbe Rezept auf der Kategorieseite und der Detailseite vollständig angezeigt wird, erzeugt das zwei Seiten mit identischem Schema.org-Markup. Google wertet das als Duplicate. Die Lösung: Auf Kategorieseiten nur Teaser zeigen und das vollständige Schema.org-Markup ausschliesslich auf der Detailseite ausgeben.

## Die Extension läuft unter TYPO3 v11 und v12, für v13 ist ein Extbase-Update nötig

Recipe-Extensions im TYPO3-Ökosystem werden von verschiedenen Anbietern gepflegt. Die Kompatibilität mit TYPO3 v12 ist bei aktiv gewarteten Extensions gegeben. Für TYPO3 v13 sind typischerweise Anpassungen an der Extbase-Model-Konfiguration und den TCA-Definitionen nötig, weil v13 einige veraltete TCA-Typen entfernt hat. Gosign empfiehlt bei Rezept-Websites, die Schema.org-Ausgabe nach jedem TYPO3-Update mit dem Google Rich Results Test zu validieren, um sicherzustellen, dass die Markup-Qualität erhalten bleibt.

--- registeraddress TYPO3 - Newsletter Signup | Gosign ---
> Newsletter registration via tt_address in TYPO3. Subscriber management directly in the CMS without an external newsletter service.

## Newsletter-Registrierung ohne externe Dienste spart Kosten und hält Daten unter eigener Kontrolle

Mailchimp, Brevo, Rapidmail: Für jede Newsletter-Registrierung zahlen Organisationen pro Subscriber und pro versendeter E-Mail. Bei 10.000 Abonnenten summiert sich das auf 100 bis 300 Euro monatlich, nur für die Verwaltung der Adressen. registeraddress bietet eine Alternative: Newsletter-Registrierung direkt in TYPO3 über die bewährte tt_address-Tabelle. Subscriber-Management, Double-Opt-In, Abmelde-Link und GDPR-compliant Einwilligungsdokumentation laufen vollständig im CMS, ohne dass ein externer Dienst Zugriff auf die Abonnentendaten bekommt.

Für Vereine, kleine Verlage und öffentliche Einrichtungen mit Budgetrestriktionen ist das eine valide Architektur, vor allem dann, wenn der Newsletter-Versand über einen günstigen SMTP-Relay-Dienst wie Amazon SES (0,10 Dollar pro 1.000 E-Mails) oder den eigenen Mailserver läuft.

## Typical use cases umfassen Vereins-Newsletter, Intranet-Verteiler und Event-Anmeldungen

Das häufigste Szenario ist der klassische Vereins-Newsletter. Ein Sportverein mit 2.000 Mitgliedern bietet auf seiner TYPO3-Website ein Anmeldeformular. Besucher tragen ihre E-Mail-Adresse ein, erhalten eine Double-Opt-In-Mail, bestätigen und werden in die tt_address-Tabelle eingetragen. Der Verein versendet monatlich einen Newsletter über die direct_mail-Extension oder einen externen Versanddienst, der die Adressen aus tt_address importiert. registeraddress kümmert sich ausschliesslich um die Registrierung und Abmeldung, nicht um den Versand selbst.

Ein zweites Szenario sind Intranet-Verteiler in Unternehmen. Mitarbeiter melden sich für interne Informations-Newsletter an, etwa "Standort München - Kantinen-Menü" oder "IT-Wartungsfenster". Da die Daten das Unternehmensnetzwerk nicht verlassen dürfen, ist ein externer Newsletter-Dienst ausgeschlossen. registeraddress verwaltet die Anmeldungen lokal in der TYPO3-Datenbank.

Drittes Szenario: Event-Anmeldungen mit E-Mail-Bestätigung. Eine Bibliothek bietet Veranstaltungen an und nutzt registeraddress als leichtgewichtiges Anmeldeformular. Die Bestätigungsmail nach dem Double-Opt-In enthält Datum, Uhrzeit und Ort der Veranstaltung. Das ist keine vollwertige Event-Management-Lösung, aber für Einrichtungen mit fünf bis zehn Veranstaltungen pro Monat ausreichend.

## Technical architecture baut auf tt_address und dem Double-Opt-In-Workflow

registeraddress ist als Extbase-Plugin implementiert und nutzt die tt_address-Tabelle als Datenbank. Jede Registrierung durchläuft einen dreistufigen Prozess: Formular-Eingabe, Double-Opt-In-Mail mit Bestätigungslink, Aktivierung des Eintrags nach Klick auf den Link. Der Bestätigungslink enthält einen kryptographisch signierten Token, der nach einer konfigurierbaren Zeitspanne (Standard: 48 Stunden) abläuft.

Die Extension registriert ein Frontend-Plugin, das über TypoScript konfiguriert wird: Pflichtfelder, optionale Felder (Name, Firma, Anrede), Bestätigungstext, E-Mail-Templates für Double-Opt-In und Willkommensmail. Die Fluid-Templates sind per SiteSet überschreibbar, sodass das Formular ins Design der Website passt.

Für die GDPR compliance speichert registeraddress den Zeitpunkt der Einwilligung, die IP-Adresse, den User-Agent und die Version der privacy policy, auf die im Formular verlinkt wurde. Bei einer Behördenanfrage lässt sich nachweisen, wann und unter welchen Bedingungen der Subscriber zugestimmt hat.

Abmeldungen laufen über einen Link im Newsletter-Footer, der den tt_address-Eintrag deaktiviert (nicht löscht), sodass die Einwilligungshistorie erhalten bleibt. Endgültige Löschungen gemäss Art. 17 GDPR (Recht auf Löschung) können über ein separates Löschformular oder manuell im Backend erfolgen.

## Common problems involve Double-Opt-In-Mails im Spam und veraltete tt_address-Versionen

Das dominierende Problem ist die Zustellbarkeit der Double-Opt-In-Mail. Wenn die Bestätigungsmail im Spam-Ordner landet, schliesst der Subscriber die Registrierung nie ab. Die Ursachen sind fast immer server-seitig: fehlender SPF-Record, kein DKIM-Signatur, kein DMARC-Policy. registeraddress selbst kann die Zustellbarkeit nicht verbessern, weil das ein Mailserver-Thema ist. Wir empfehlen, vor dem Launch eines Newsletter-Formulars die E-Mail-Authentifizierung mit mail-tester.com zu prüfen.

Zweites Problem: Inkompatibilität mit älteren tt_address-Versionen. registeraddress setzt auf bestimmte Felder in der tt_address-Tabelle. Wenn tt_address ein Major-Update veröffentlicht und Felder umbenennt oder entfernt, kann registeraddress die Einträge nicht mehr korrekt schreiben. Die Lösung: tt_address und registeraddress immer gemeinsam aktualisieren und nach dem Update einen Testdurchlauf des gesamten Registrierungsprozesses machen.

Drittes Thema: Bot-Registrierungen. Ohne Schutzmechanismus füllen Bots das Formular mit Fake-Adressen und erzeugen Tausende von Double-Opt-In-Mails, die den Mailserver belasten und die Sender-Reputation schädigen. registeraddress unterstützt Honeypot-Felder und kann mit sr_freecap oder hcaptcha kombiniert werden, um Bots abzuwehren.

## TYPO3 v12 wird unterstützt, v13-Kompatibilität requires ein tt_address-Alignment

registeraddress läuft unter TYPO3 v11 und v12 stabil, vorausgesetzt tt_address ist in einer kompatiblen Version installiert. Für TYPO3 v13 hängt die Kompatibilität sowohl von registeraddress als auch von tt_address ab, da beide Extensions unabhängig gepflegt werden. Gosign prüft bei TYPO3-Upgrades die gesamte Newsletter-Kette (Registrierung, Adressverwaltung, Versand) auf Kompatibilität und empfiehlt bei Bedarf den Umstieg auf einen externen Newsletter-Dienst mit API-Anbindung, wenn die TYPO3-native Lösung nicht mehr gepflegt wird.

--- rflipbook TYPO3 - Digital Flipbook | Gosign ---
> rflipbook for TYPO3: PDFs as interactive flipbooks. Setup, performance optimization & modern alternatives.

## rflipbook turns catalogues and brochures into a page-turning experience, the pragmatic answer for content teams that want PDFs to live on the website instead of hiding in a download folder

Anyone who maintains a multi-page catalogue, an annual report or a customer magazine as a PDF faces a dilemma: as a download, the document sits in a dead end, the user leaves the page and rarely returns. rflipbook solves this by rendering every PDF page as a canvas and recreating the classic page-turning effect from the print world in the browser. The extension addresses a concrete publishing problem: marketing, press and investor relations teams want to repurpose existing print assets digitally without having to translate them into HTML. rflipbook removes that detour.

It is worth noting that rflipbook is not only a display technique but also a content signal. A website that carries current catalogues and reports as flipbooks feels maintained to potential customers, in contrast to orphaned download directories with documents from different years. On the editorial side, therefore, the introduction of rflipbook also requires clarifying who updates which PDF and when.

## Typical use cases

The most common case is the B2B product catalogue. A mechanical engineering company maintains its overall catalogue in InDesign, exports an 80-page PDF and embeds it on the product page via rflipbook. Nothing changes for the editorial team, but for the visitor a dry download turns into a page-turning experience with preview and search.

The second use case is annual and sustainability reports. Listed companies, foundations and associations publish extensive reports every year that are not rewritten. rflipbook embeds the finished PDF directly on the IR page and bridges the gap between the classic editorial process and the web team.

A third case: customer and staff magazines. Universities, municipalities and mid-sized companies use rflipbook to offer their print magazine as a digital edition, often with an archive function and multilingual editions per volume.

## Technical architecture

rflipbook integrates as a classic TYPO3 extension through a content element in the page module. Editors upload the PDF into the FAL storage, link it to the content element and set parameters such as background colour, starting page and download button in the backend. In the frontend, a JavaScript library such as Turn.js or a comparable canvas rendering library handles the actual display. PDF.js is often used as a parser to split the PDF pages into individual bitmaps.

The dependency chain is small: rflipbook ships the JavaScript libraries inside the extension package, the extension itself does not need any additional PHP packages. Configuration runs through TypoScript for global defaults and through the flexform of the content element for page-specific adjustments. Anyone working with EXT:fluid_styled_content can pull the template into their own sitepackage through Fluid overrides and align it with the corporate design.

What matters is the interaction with the asset handling. Large PDFs should be pre-rendered into individual JPGs on the server, otherwise the browser loads everything synchronously on the first call. Lazy page loading is not a standard feature but can be added through a custom render pipeline.

## Common problems and solutions

The most common problem is load time. A 40-page catalogue with high-resolution photos easily produces an initial payload of several megabytes, which means red Lighthouse scores and poor Core Web Vitals. The solution does not lie in the extension itself but upstream: downscale PDFs to the actual screen resolution before upload, ideally via Ghostscript or a server-side build pipeline, and load only the first two or three pages on first access.

Second problem: display on mobile devices. The page-turning effect works poorly on touchscreens below 400 pixels in width, and editorial teams complain about unreadable pages. Pragmatic solution: via a CSS media query, switch from the flipbook on mobile devices to a simple PDF.js viewer with vertical scrolling. The user experience becomes more honest and the load time better.

Third problem: accessibility. Screen readers cannot read canvas-rendered PDFs, which becomes a compliance problem at public authorities and institutions. The only help here is a dual-track approach: the flipbook as a visual supplement, with a direct link to the original PDF and ideally an HTML version of the core content alongside. Accessibility standards such as EN 301 549 explicitly require this.

## Migration and version compatibility

rflipbook is an established but no longer actively maintained extension. A working version exists for TYPO3 v11; on v12 and v13 it only runs with manual adjustments to ext_emconf.php and the service configuration schema. Anyone starting fresh today should ask whether a lightweight alternative is the better choice: a lean PDF.js viewer, static HTML pages from the PDF content or a headless flipbook service embedded as an iframe. The decision depends on how often the document changes and how important the visual page-turning effect is for the brand.

Anyone staying on TYPO3 v11 should not treat rflipbook as a permanent solution. By the time of the upgrade to v12 at the latest, a decision is needed, and the lead time for it should be planned early. A typical migration project covers the analysis of all existing flipbook deployments, the decision per case (static HTML version, lightweight PDF viewer or keeping the flipbook), the implementation and the editorial training. Anyone who approaches the project strategically uses the migration at the same time for an asset clean-up: outdated catalogues are archived, documents are re-embedded in their current versions, and metadata is unified.

Gosign supports both paths: continued operation of rflipbook on modern TYPO3 versions and migration to higher-performance alternatives. AI-assisted analysis helps to find the right architecture for the specific content case instead of giving a one-size-fits-all answer.

--- FontAwesome CKEditor TYPO3 | Gosign ---
> Insert FontAwesome icons directly in CKEditor rich text. Gosign also advises on SVG icon systems as a more performant alternative - no 300KB font file needed.

## Why FontAwesome in CKEditor helps editors but costs 300 KB in performance

Editors want to place icons next to headings, in tables and between text paragraphs. Without technical help, they copy icon images as inline images into the RTE - with broken layout and inconsistent sizing as the result. rte_ckeditor_fontawesome solves this problem cleanly: editors select icons from the FontAwesome catalog directly in CKEditor via a dialog button and insert them as `<i>` tags into the rich text. The icons scale automatically with the text size, are color-customizable and work in every content element.

The price: the entire FontAwesome library (approx. 300 KB as webfont or 180 KB as SVG sprite) is loaded on every page, even if only 3 icons are used. For performance-critical websites, this is a noticeable overhead.

## Typical use cases

**Icon lists in service descriptions.** A service provider describes their offerings with icon lists: checkmark before each benefit, gear icon before each process step, phone icon before the contact number. The editor inserts icons directly in CKEditor without needing to ask a developer. This works in text fields, tables and lists equally.

**Feature comparison tables.** Product managers maintain comparison tables in CKEditor. Instead of "Yes" and "No", they use green checkmark and red cross icons. rte_ckeditor_fontawesome provides these icons through the FontAwesome catalog. The table becomes immediately visually comprehensible.

**Newsletter templates with icons.** Companies that maintain newsletter content in the TYPO3 backend and send them through a newsletter extension use FontAwesome icons for visual enhancement. Since the icons are inserted as `<i>` tags, they work in email clients that support web fonts.

## Technical architecture

rte_ckeditor_fontawesome extends the CKEditor in the TYPO3 backend with an additional plugin. The plugin registers a button in the CKEditor toolbar that opens a selection dialog.

Integration works on three levels:

- **CKEditor plugin**: a JavaScript plugin for CKEditor 4 (TYPO3 v10/v11) or CKEditor 5 (TYPO3 v12+). The plugin renders the icon selection dialog with search function and category filter. Available icons are loaded from a JSON file that maps the FontAwesome catalog.
- **HTML output**: on insertion, an `<i>` tag with the corresponding CSS classes is written into the rich text: `<i class="fas fa-check"></i>` for a solid checkmark, `<i class="far fa-envelope"></i>` for an outline envelope. The RTE stores the tag as normal HTML content in the database.
- **Frontend rendering**: for icons to be visible in the frontend, the FontAwesome CSS library must be loaded on the website. This can be as a webfont (CSS + font files, approx. 300 KB) or as SVG framework (JavaScript + SVG sprite, approx. 180 KB). The extension does not ship frontend assets - integration into the frontend template is the developer's responsibility.

Dependencies: TYPO3 Core with CKEditor (part of the Core since v8), FontAwesome frontend assets (to be included separately).

Important note on CKEditor version: TYPO3 v12 switches from CKEditor 4 to CKEditor 5. The plugin architecture has fundamentally changed. rte_ckeditor_fontawesome plugins for CKEditor 4 do not work in CKEditor 5. An upgrade requires a completely new plugin.

## Common problems and solutions

**Icons not displayed in the frontend.** The most common cause: FontAwesome CSS is not included in the frontend template. The extension handles only the backend part (icon selection in CKEditor). Frontend rendering requires that `fontawesome.min.css` and the associated font files (woff2) are loaded in the template. Solution: add FontAwesome via TypoScript as a CSS include or through the TYPO3 site configuration's asset management.

**Icons appear as empty boxes.** The font files (woff2, woff) are not loading correctly. Frequently, the path in the CSS file is misconfigured or the web server blocks font files (missing CORS headers with CDN embedding). Solution: host FontAwesome locally instead of via CDN. This avoids CORS issues and is more GDPR-compliant because no third-party requests occur.

**Performance impact from FontAwesome.** A complete FontAwesome installation loads 300+ KB (all icon categories: Solid, Regular, Brands). If the website uses only 10 icons, 290 KB is wasted. Solution: use FontAwesome subsetting - compile only the used icons into a custom font file. Alternatively: switch to an SVG icon system that embeds only the actually used icons as inline SVGs.

## Migration and version compatibility

rte_ckeditor_fontawesome is available for TYPO3 v10 and v11 (CKEditor 4) as a stable extension. For TYPO3 v12 (CKEditor 5), adaptations exist because the plugin architecture is completely new. CKEditor 5 uses a modern JavaScript module system instead of the CKEditor 4 plugin API.

For TYPO3 v13 and beyond, Gosign recommends a fundamental reassessment of the approach. Instead of loading FontAwesome as a webfont, modern websites use SVG icon systems: every icon is embedded as inline SVG, only the used icons are loaded, file size drops from 300 KB to under 10 KB. For editors, a custom CKEditor widget can be developed that lets them select icons from an SVG sprite.

The migration effort from FontAwesome to SVG icons is typically 2 to 3 days: create SVG sprite, adapt CKEditor widget, replace existing `<i>` tags in content with `<svg>` references. Gosign automates the last step through a migration script that identifies all `<i class="fa-*">` tags in the database and rewrites them.

When deciding between FontAwesome and SVG icons, the numbers tell a clear story: FontAwesome Free contains over 2,000 icons, FontAwesome Pro over 7,000. A typical corporate website uses 15 to 30 of them. All visitors pay for the rest in loading time. A custom SVG sprite with 30 icons weighs 8 to 15 KB - one-fiftieth of the full FontAwesome library. For websites optimized for Core Web Vitals and PageSpeed, the decision is clear.

--- rte_ckeditor_image TYPO3 - Images in RTE | Gosign ---
> rte_ckeditor_image: insert and edit images in CKEditor. Responsive output, troubleshooting, alternatives.

## rte_ckeditor_image brings professional image management into the rich text editor

The TYPO3 CKEditor only allows simple image embeds via an img tag, without any connection to the file abstraction layer and without responsive variants. For editorial teams that regularly place images inside articles, news posts or magazine texts, that is not enough: they need cropping, scaling, alt text, copyright, link target and, above all, srcset output. rte_ckeditor_image from Netresearch adds exactly these functions to the CKEditor and integrates them cleanly with the FAL. On every TYPO3 project with editor-maintained inline images, the extension has been the standard tool for years and counts as one of the most frequently installed editorial helpers in the ecosystem.

## Typical use cases live in editorial teams with high image volume

Online magazines and corporate news sites are the classic audience. A magazine with 200 articles per year embeds two to five images per article in running text, on top of teaser and header images. Without rte_ckeditor_image, the editors would have to accept a content element switch for every inline image and break the flow of writing. With the extension, they insert the image directly through a toolbar button, pick the FAL reference, set alt text and caption and return to writing without any context switch. The efficiency gain is measurable in practice: on an editorial team with 200 articles per year and an average of four images per article, we save around two minutes of setup time per article, which adds up to roughly 30 working hours per year.

A second scenario are product catalogues and technical documentation. Anyone who maintains step-by-step instructions with inline screenshots in a TYPO3 catalogue needs the images directly in the text. rte_ckeditor_image allows this with the same FAL references that are used in the rest of the project, so image updates happen in one place and propagate everywhere.

A third scenario is the migration of TYPO3 installations from the htmlArea era. Anyone who was using RTEhtmlArea before found a similar image management there. When switching to CKEditor, rte_ckeditor_image is the direct replacement extension, so that editors can keep their familiar workflow. Without the extension, they lose not only a function on upgrade but an entire work step that can only be clumsily rebuilt through additional content elements.

## Technical architecture extends the CKEditor toolbar via plug-in

The extension consists of a CKEditor plug-in that registers the image button and the image dialog, plus a server-side rendering that translates the marker in the stored HTML into a Fluid output. The plug-in talks to an AJAX endpoint that processes the FAL reference, the cropping and the alt texts.

In the database content, the image is stored as an HTML marker with the data attributes data-htmlarea-file-uid and data-htmlarea-file-table, accompanied by further attributes for cropping, zoom and height. On rendering, a pre-processor replaces the marker tag with a full image ViewHelper call that produces srcset, webp variants and lazy loading attributes. The available image widths are defined through YAML in the RTE configuration. A typical magazine setup works with three to five image widths (480, 768, 1024, 1440, 2048) and derives a responsive srcset from them that loads only the smallest variant on mobile devices.

Cropping uses the TYPO3 core cropping tool: the image dialog shows the crop editor from the backend, with the same variant presets as in the regular image content element. Cropping is stored per image instance, so that the same FAL image can be cropped differently in different articles. This matters especially when an image is used both in the magazine teaser (square) and in the running text (landscape), without the editorial team having to maintain two separate files.

## Common problems involve responsive output, WebP and CKEditor 5 compatibility

The most common support topic is missing srcset output. The default rendering path produces no srcset when the RTE YAML contains no image width definition. Many installations have copied the YAML from the TYPO3 core and left out the section "proc.entryHTMLparser_db.allowedAttribs" or "config.additionalAttributes". The solution is a complete YAML with explicitly defined srcset widths.

The second problem is WebP. Anyone who wants to deliver modern image formats has to set up the TYPO3 ImageMagick provider or a GraphicsMagick setup with WebP support. rte_ckeditor_image itself does not handle WebP conversion but delegates to the core image processor. Without correct provider configuration, the images stay as JPEG in the output.

Thirdly, CKEditor 5 represents an architectural change. TYPO3 v12 ships CKEditor 5, which uses a different plug-in model. rte_ckeditor_image versions 10.x and 11.x are ported to CKEditor 5 and work on v12 out of the box. Custom adjustments based on CKEditor 4 have to be adapted on upgrade. Anyone who has built custom plug-ins or their own toolbar buttons should plan at least one or two developer days for the migration.

## Migration to TYPO3 v12 and v13 requires a version jump of the extension

rte_ckeditor_image is actively maintained by Netresearch and is available for TYPO3 v11, v12 and v13. The bigger jump lies between extension versions 9.x (CKEditor 4) and 10.x/11.x (CKEditor 5). Anyone lifting a TYPO3 v10 or v11 installation with extension 9.x to TYPO3 v12 has to switch to the 10.x series of the extension at the same time. The database representation of inline images remains compatible, so existing articles work without content migration.

At Gosign, we check before every TYPO3 upgrade whether the project RTE YAML has to be adapted to the extension version and whether custom plug-in adjustments or overridden ViewHelpers exist. On many projects with TYPO3 v12, it is also worth checking whether the native CKEditor 5 image functions are sufficient and whether the extension can be phased out in the medium term. For editorial teams with cropping and srcset requirements, however, rte_ckeditor_image remains the most pragmatic option. The alternative would be a custom image toolbar button with its own CKEditor plug-in, which is significantly more effort and permanently shifts maintenance into the project responsibility.

--- rx_shariff TYPO3 - Privacy-Safe Sharing | Gosign ---
> rx_shariff: social sharing without tracking. GDPR-compliant buttons for TYPO3. Setup & alternatives.

## Why standard social buttons are a GDPR problem and rx_shariff was the solution

Every Facebook Like button, every Twitter share widget and every LinkedIn embed transfers personal data to the platform - on page load, not just on click. IP address, browser fingerprint and referrer flow to Facebook before the visitor even has the chance to consent. This has been legally problematic since GDPR took effect in 2018 and has already led to warnings against website operators.

rx_shariff implements the Shariff principle that Heise Verlag developed in 2014 as a response to this problem: instead of embedding the platforms' original widgets, rx_shariff renders its own privacy-compliant buttons. Only when a visitor clicks the button is a connection to the platform established. No tracking, no third-party requests, no cookies without interaction.

## Typical use cases

**Corporate websites with GDPR compliance requirements.** A mid-market company wants to offer social share buttons on its blog articles without violating GDPR. The data protection officer has explicitly prohibited the standard widgets from Facebook and Twitter. rx_shariff delivers buttons that only establish a connection on click. The privacy policy can be correctly worded: "Only when actively using the share buttons is data transferred to third parties."

**Media websites with share counters.** A specialist publisher wants to display under each article how often it has been shared on Facebook and LinkedIn. rx_shariff offers this function through an optional backend proxy: the TYPO3 server regularly queries share counts from the platforms and caches the results. The platforms see only the server, never the individual visitor.

**Intranet portals with controlled sharing.** A company operates a TYPO3 intranet and wants to make specific articles shareable via LinkedIn while excluding Facebook and Twitter. rx_shariff can be configured so that only selected platforms appear as buttons. Configuration is done per page tree or per content element. In the intranet context, this is particularly relevant because accidental sharing of internal information on public platforms must be prevented.

## Technical architecture

rx_shariff consists of two components: a frontend widget and an optional backend service.

**Frontend widget:** the TYPO3 plugin renders an HTML button for each configured platform. This button is a simple anchor link (`<a href="...">`) with a share URL as target. On click, the platform's share dialog page opens in a new window. No JavaScript is loaded on page load, no cookies set, no external resources requested.

**Backend service (optional):** for share counters, rx_shariff operates a server-side proxy. A PHP script queries the platform APIs (Facebook Graph API, LinkedIn Share API) and caches the results in a database table. The frontend displays the cached counter. The proxy updates counters via scheduler task every 15 to 60 minutes. The platform APIs see only the server IP, never the website visitor's IP.

Configuration is done through TypoScript and extension settings:

- Platform selection (Facebook, Twitter/X, LinkedIn, Xing, Pinterest, WhatsApp, Telegram, email)
- Display variant (icons, buttons with text, compact variant)
- Theme customization via CSS classes
- Share counter enable/disable
- Backend service URL for counters

Dependencies: TYPO3 Core. For the share counter: PHP with cURL support, valid API keys for the platforms (Facebook Graph API requires app registration).

## Common problems and solutions

**Share counters always show 0.** The platform APIs require authentication. Without a valid API key, Facebook and LinkedIn return no counters. Twitter/X shut down its share count API entirely in 2015 - a counter for Twitter is technically no longer possible. Solution: create a Facebook app in the Meta Developer Portal and configure the app token in rx_shariff. Disable the counter for Twitter or switch to X API v2 with OAuth 2.0, which however does not offer a share counter.

**Buttons not visible after TYPO3 update.** rx_shariff uses a TYPO3 plugin with its own content element. If the plugin is no longer registered after an update (e.g. through changed Composer dependencies), the content element disappears from the frontend. Solution: check the extension in the Extension Manager, update Composer dependencies, run `vendor/bin/typo3 cache:flush`.

**WhatsApp share works only on mobile devices.** WhatsApp Web and the desktop app do not consistently support the `whatsapp://` URL scheme. On desktop browsers, clicking the WhatsApp button leads nowhere. Solution: use the web URL `https://api.whatsapp.com/send?text=...` on desktop, the app scheme on mobile. rx_shariff detects the user agent and selects the correct link automatically.

## Migration and version compatibility

rx_shariff is available for TYPO3 v10 and v11 as a stable Composer package. For TYPO3 v12, community forks exist as the original extension is no longer actively maintained. The Shariff JavaScript project by Heise itself was placed in maintenance mode in 2022.

For new projects from TYPO3 v12 onward, Gosign recommends a reassessment: simple share links (`href="https://www.facebook.com/sharer/sharer.php?u=..."`) are lighter than rx_shariff, GDPR-compliant and require no extension. The downside: no share counter. Those needing counters must implement the API queries themselves or use a service like ShareThis with consent management.

Migrating from rx_shariff to simple share links typically takes half a day: remove old plugin, create new Fluid partials for share links, adjust CSS. Gosign has performed this switch for multiple clients and improved page loading time by 150 to 300ms because the Shariff JavaScript and counter queries are eliminated.

The simple share link approach covers the common platforms: Facebook (`https://www.facebook.com/sharer/sharer.php?u={url}`), LinkedIn (`https://www.linkedin.com/sharing/share-offsite/?url={url}`), X/Twitter (`https://twitter.com/intent/tweet?url={url}&text={title}`), email (`mailto:?subject={title}&body={url}`) and WhatsApp (`https://api.whatsapp.com/send?text={url}`). All links are privacy-compliant because no JavaScript is loaded and no third-party cookie is set. The links can be included as a Fluid partial in any template and styled via CSS classes.

--- SAML2 TYPO3 - SSO Integration | Gosign ---
> SAML 2.0 single sign-on directly in TYPO3, without Shibboleth SP on the server. Alternative to shibboleth_auth for IdPs that don't support OIDC.

## SAML 2.0 ermöglicht Single Sign-On in TYPO3 ohne Shibboleth-Installation auf dem Server

Hochschulen, Behörden und Konzerne betreiben Identity Provider (IdP), die auf SAML 2.0 basieren: Microsoft ADFS, Okta, Keycloak, PingFederate. Wer diese Identitäten in TYPO3 nutzen will, brauchte bisher einen Shibboleth Service Provider auf dem Webserver, eine zusätzliche Softwareschicht mit eigener Konfiguration, eigenen Zertifikaten und eigener Wartung. Die TYPO3-Extension saml2 macht den Shibboleth SP überflüssig. Sie implementiert den SAML 2.0 SP direkt in PHP und kommuniziert ohne Middleware mit dem IdP. Das vereinfacht die Server-Architektur erheblich, besonders auf Shared-Hosting-Umgebungen oder in Container-Deployments, wo ein Shibboleth SP schwer zu installieren ist.

Für Organisationen, deren IdP kein OIDC (OpenID Connect) unterstützt, ist SAML 2.0 der einzige standardisierte Weg zum Single Sign-On. Die Extension schliesst genau diese Lücke im TYPO3-Ökosystem.

## Typical use cases involve Hochschul-Intranets, Behörden-Portale und Konzern-Extranets

Das häufigste Szenario ist das Hochschul-Intranet. Eine Universität betreibt einen Shibboleth IdP im DFN-AAI-Verbund (Deutsches Forschungsnetz). Studierende und Mitarbeitende melden sich mit ihrer Hochschulkennung an und erhalten Zugang zu geschützten TYPO3-Seiten: Skripte, interne Nachrichten, Prüfungsergebnisse. Die saml2-Extension prüft das SAML-Assertion-Token, legt bei Bedarf einen TYPO3-Frontend-User an und weist Gruppen basierend auf den IdP-Attributen zu (z.B. Studierende = Gruppe "student", Dozierende = Gruppe "staff").

Ein zweites Szenario sind Behörden-Portale mit BundID-Anbindung. Seit 2023 ist BundID der zentrale Identitätsdienst des Bundes. SAML 2.0 ist eines der unterstützten Protokolle. Eine Kommune kann ihre TYPO3-Website über saml2 an BundID anbinden, sodass Bürger sich mit ihrem Personalausweis (eID) oder Elster-Zertifikat anmelden und auf personalisierte Dienstleistungen zugreifen.

Drittes Szenario: Konzern-Extranets. Ein Automobilhersteller betreibt ein Händlerportal auf TYPO3. Händler melden sich über den Konzern-IdP (Microsoft ADFS) an und sehen Preislisten, Schulungsunterlagen und Bestellformulare, die ihrer Händlergruppe zugeordnet sind. Die saml2-Extension mappt die ADFS-Gruppen auf TYPO3-Frontend-Gruppen und steuert damit den Zugang zu geschützten Inhaltsbereichen.

## Technical architecture implements den SAML 2.0 SP als PHP-Library in TYPO3

saml2 basiert auf der PHP-Library onelogin/php-saml (oder einer vergleichbaren Implementation), die den SAML 2.0 Web Browser SSO Profile vollständig abdeckt: AuthnRequest, Response-Validierung, Assertion-Parsing, Signaturprüfung, Logout. Die Library wird als Composer-Dependency eingebunden und von der Extension als TYPO3-Authentication-Service registriert.

Die Konfiguration erfolgt im TYPO3-Backend oder per TypoScript: IdP-Metadata-URL (oder manuell: Entity ID, SSO-URL, SLO-URL, Zertifikat), SP-Entity-ID, Attribute-Mapping (welches IdP-Attribut auf welches TYPO3-Feld: email, username, firstname, lastname, groups). Die Extension unterstützt sowohl SP-initiated SSO (User klickt "Login" auf der TYPO3-Seite) als auch IdP-initiated SSO (User kommt direkt vom IdP-Portal).

Frontend-User werden bei der ersten Anmeldung automatisch angelegt und bei jeder weiteren Anmeldung aktualisiert. Die Gruppenzuordnung kann statisch (alle SAML-User in Gruppe X) oder dynamisch (IdP-Attribut "role" = "admin" wird zu TYPO3-Gruppe "admin") konfiguriert werden.

Für das Backend-Login (BE-User) ist SAML ebenfalls konfigurierbar, allerdings mit höherem Risiko: Wenn der IdP ausfällt, ist kein Backend-Zugang mehr möglich. Wir empfehlen, mindestens einen lokalen Admin-Account als Fallback beizubehalten.

## Common problems involve Zertifikate, Zeitabweichungen und Attribut-Mapping

Das häufigste Problem bei SAML-Integrationen sind abgelaufene oder falsch konfigurierte Zertifikate. Der IdP signiert die SAML-Response mit seinem Zertifikat. Wenn das Zertifikat auf dem SP nicht aktualisiert wird, nachdem der IdP es rotiert hat, scheitert die Signaturprüfung und der Login bricht mit einer kryptischen Fehlermeldung ab. Die Lösung: Zertifikats-Rotation in den Wartungskalender aufnehmen. Die meisten IdPs geben 30 Tage Vorlauf vor der Rotation.

Zweites Problem: Zeitabweichungen zwischen IdP und SP. SAML-Assertions haben ein Zeitfenster (NotBefore / NotOnOrAfter). Wenn die Systemuhren von IdP-Server und TYPO3-Server mehr als 120 Sekunden auseinanderlaufen, wird die Assertion als ungültig abgelehnt. Die Lösung: NTP auf beiden Servern konfigurieren.

Drittes Thema: Falsches Attribut-Mapping. Jeder IdP benennt die Attribute anders. Microsoft ADFS liefert "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", Keycloak liefert "email", Shibboleth liefert "urn:oid:0.9.2342.19200300.100.1.3". Die Extension muss wissen, unter welchem Namen das E-Mail-Attribut im SAML-Token steht. Falsches Mapping führt zu leeren Feldern im TYPO3-User-Profil. Debug-Logging der empfangenen Attribute hilft, die richtigen Mapping-Keys zu identifizieren.

## TYPO3 v12 wird unterstützt, v13-Kompatibilität hängt von der Authentication-Service-API ab

Die saml2-Extension registriert sich als TYPO3 Authentication Service. Diese API ist im TYPO3-Core seit Jahren stabil, wurde aber in v12 und v13 an einzelnen Stellen angepasst. Die aktuelle Version der Extension läuft unter v12 stabil. Für v13 muss die Authentication-Service-Registrierung an die neue Service-Konfiguration angepasst werden. Gosign prüft bei SSO-Projekten, ob die PHP-SAML-Library auf aktuellem Stand ist (Sicherheitspatches) und ob die Extension mit der eingesetzten TYPO3-Version kompatibel ist. Wenn die Community-Extension nicht mehr gepflegt wird, empfehlen wir als Alternative die oidc-Extension, sofern der IdP OpenID Connect unterstützt.

--- Schemaker TYPO3 - ViewHelper Schema | Gosign ---
> ViewHelper schema generator for Fluid. Generates documentation and autocompletion for custom ViewHelpers.

## Why missing ViewHelper documentation slows TYPO3 projects down

Fluid ViewHelpers are the backbone of every TYPO3 template development. But once a project includes custom ViewHelpers, the problem begins: no developer knows all parameters, no IDE offers autocompletion, and documentation exists at best as a comment in the PHP code. Schemaker solves this problem by automatically generating XSD schema files from PHP classes. These schemas provide IDEs with the information needed for autocompletion, validation and inline documentation directly in the Fluid template.

For teams with more than one TYPO3 developer, this is not a comfort question but a productivity question. Without schema files, every developer spends 15 to 30 minutes daily looking up ViewHelper parameters in source code.

## Typical use cases

**Enterprise projects with 20+ custom ViewHelpers.** Large TYPO3 installations frequently include specialized ViewHelpers - for price formatting, permission checks, API calls or industry-specific logic. Without Schemaker, every new developer on the project must read source code to understand the available parameters. With Schemaker, they open the Fluid template in PhpStorm or VS Code and immediately receive suggestions. For a project with 25 custom ViewHelpers and an average of 4 parameters per ViewHelper, this saves an estimated 30 to 45 minutes of source code searching per developer day.

**Extension development for the TYPO3 Extension Repository (TER).** Extension publishers that include custom ViewHelpers can ship XSD files generated by Schemaker. This significantly reduces support requests and improves the developer experience for every extension user. In the TER as well as on Packagist, an included XSD file signals professional extension development.

**Onboarding new developers.** In a TYPO3 agency, developers regularly switch between projects. Schemaker-generated schemas function as living documentation: they are always current because they are generated directly from the code. No wiki that becomes outdated. No Confluence that nobody maintains. A new developer installs the project, opens a Fluid template and immediately sees which ViewHelpers with which parameters are available. Instead of 2 days of familiarization, it is 2 hours.

## Technical architecture

Schemaker analyzes PHP classes that extend `AbstractViewHelper`. It reads the `@param` annotations, the `registerArgument()` calls and the class DocBlocks. From this, it generates XSD schema files (XML Schema Definition) that are assigned to the Fluid namespace.

Integration works through the TYPO3 CLI:

- `vendor/bin/typo3 schemaker:generate` produces XSD files for all registered ViewHelper namespaces
- The generated XSD files are placed in the project (typically: `Resources/Private/Schemas/`)
- In every Fluid template, the namespace is declared with a schema location
- The IDE (PhpStorm, VS Code with the appropriate extension) reads the XSD and offers autocompletion

Schemaker has only the TYPO3 Core and the Fluid template engine package as dependencies. It does not intervene in the rendering process and has no performance impact on the live website - schema generation runs exclusively on the CLI in the development context. In production environments, Schemaker does not even need to be installed; the generated XSD files are distributed via version control (Git) and function independently of the extension.

Important: Schemaker only analyzes ViewHelpers that are correctly registered. ViewHelpers that work via `$this->registerArgument()` in the `initializeArguments()` method are fully recognized. Older ViewHelpers that define parameters through `render()` method signatures (pre-TYPO3 v8 pattern) are partially not captured correctly.

## Common problems and solutions

**IDE shows no autocompletion despite XSD.** Most common cause: the namespace in the Fluid template does not match the XSD namespace. Schemaker generates schemas based on the PHP namespace of the ViewHelper classes. If a different alias is used in the Fluid template, the IDE finds no mapping. Solution: `xmlns:custom="http://typo3.org/ns/Vendor/Extension/ViewHelpers"` must exactly match the generated schema.

**Generated XSD does not contain all ViewHelpers.** Schemaker only finds ViewHelpers reachable through Composer autoloading. Extensions installed only via classic mode directory (without Composer) are not fully scanned. Solution: switch to Composer-based installation or manually configure the autoload path.

**Schema outdated after code changes.** XSD files are not automatically updated when ViewHelper parameters change. Solution: integrate schema generation into the CI/CD pipeline. A `composer post-install-cmd` hook or a build step in GitLab CI ensures schemas are regenerated after every dependency update. This automatic update prevents developers from working with outdated schemas and discovering errors only at runtime.

## Migration and version compatibility

Schemaker was originally developed by Claus Due (FluidTYPO3 team) and was actively maintained through TYPO3 v9. For TYPO3 v10 and v11, community forks exist with limited functionality. The Fluid template engine changed internally in v11 and v12 (new ExpressionParser, changed argument handling), which partially affects schema generation.

For TYPO3 v12 and v13, the PhpStorm-integrated TYPO3 plugin support is recommended as an alternative - it reads ViewHelper information directly from the PHP code without requiring separate XSD files. The TYPO3 Core team also provides official XSD schemas for the Core ViewHelpers.

Those with Schemaker in production who are migrating to TYPO3 v12 should evaluate whether the existing workflow can be replaced by IDE-native functions. The PhpStorm plugin for TYPO3 (as of 2026) offers ViewHelper autocompletion for Core ViewHelpers and extensions that use correct DocBlocks. For custom ViewHelpers, the plugin accesses the same PHP information that Schemaker uses - just without the detour through XSD files.

Gosign supports the evaluation and migrates existing schema workflows to modern toolchains. Typical effort for the migration: 4 to 8 hours per project, including IDE configuration for all developers on the team and documentation of available ViewHelper namespaces.

--- sf_event_mgt TYPO3 - Event Management | Gosign ---
> sf_event_mgt: manage events, control registrations, payment. Setup & custom development, AI-accelerated.

## sf_event_mgt solves the problem that events without registration are not really events

As soon as a TYPO3 website manages more than two dates per year and has to accept participants, every improvised solution built from page lists, calendar plug-ins and Powermail forms runs into its limits. sf_event_mgt is the extension that pulls these building blocks together into a real event system: participant management with status transitions, waiting lists with automatic promotion, payment across multiple providers and automated email communication across the entire participation lifecycle. Anyone who runs events with fixed capacity in TYPO3 on a regular basis will hardly get around this extension. Torben Hansen has built sf_event_mgt from day one as an "Extbase-native" tool that fits seamlessly into existing TYPO3 installations and can be overridden at any point without forking the core extension.

## Typical use cases range from trade fairs to academic programmes

Universities use sf_event_mgt for open days, taster lectures and continuing education programmes. In practice this often means 30 parallel courses, each with its own capacity, price scale and email chain for enquirers, participants and organisers. The extension handles all of this through a single data structure, including multilingual support for international students. At a typical university of applied sciences we have deployed sf_event_mgt for around 400 individual events per year, including preparatory courses, open lab days and alumni meetings.

Associations and chambers use it to organise conferences and seminars where participants pay different prices depending on their member status. A typical chamber installation runs 40 to 80 events per year, many of them chargeable and with several price tiers. Members pay the regular price, non-members a surcharge, early birds a discount. The extension models this through price categories that can be configured per event, without any developer intervention.

Enterprises deploy sf_event_mgt for internal trainings, customer events and webinars. Especially in B2B, the CSV export matters: the participant list then flows into the CRM or into the badge printer on site. At an industrial group with 12,000 employees, we connected the extension to the internal learning management system, so that training bookings land automatically in the HR system and participation is documented as a continuing education record.

## Technical architecture is built on Extbase and FAL

sf_event_mgt is a classic Extbase extension and follows the TYPO3 MVC pattern. The central models are Event, Registration, Location and Organizer, configuration runs through TypoScript and Fluid templates. Almost everything can be adjusted via constants.typoscript or TSconfig without forking the extension. The plugin offers a dozen or so controller actions, from list and detail view through the registration flow to search and category filters.

For payment, the extension ships a payment abstraction that supports Stripe, PayPal, invoice and Klarna through handler classes. Custom payment providers can be added by implementing a PaymentServiceInterface class. Billing ends up in a dedicated payment log and can be processed by the TYPO3 scheduler. Failed payments are documented and can be followed up through the backend, without editors having to switch into the payment provider console.

The email system is built on Fluid templates in the extension directory. Every registration triggers several messages: confirmation to the participant, notification to the organiser, reminders before the event, follow-up after the event. Each of these mails is a Fluid template that can be overridden via SiteSet or PageTS. Mails are sent via the TYPO3 mailer and respect the global SMTP settings, including SPF and DKIM. For participants on waiting list reservations there are separate templates that fire when they are promoted.

## Common problems involve waiting lists, iCal export and reCAPTCHA

The most common support topic is waiting list logic. When a participant cancels, the first waiting list entry is promoted, but only if the admin has enabled the "moveUpWaitlistRegistrations" command controller via scheduler. Many installations have forgotten the command and wonder why seats stay empty. The configuration takes five minutes, but without the scheduler task the extension stays in manual mode.

A second recurring topic is the iCal export. Participants want a click on "Add to calendar" that works in Outlook, Apple Calendar and Google Calendar. sf_event_mgt delivers an ICS file, but the correct time zones and VTIMEZONE blocks have to be set in configuration. Otherwise the event shows up in Outlook with a one-hour offset, which is especially critical around daylight saving time changes. For international events we recommend storing both the local time zone and UTC in the ICS.

The third topic is spam protection. Public registration forms attract bots that flood waiting lists. sf_event_mgt supports honeypot fields and can be combined with ext:kestura_recaptcha or the native TYPO3 captcha. In production installations we recommend combining both mechanisms and additionally adding a rate limit per IP address, so that single bots cannot create hundreds of fake registrations.

## Migration to TYPO3 v12 and v13 is uncritical

sf_event_mgt is continuously maintained by Torben Hansen and is available for TYPO3 v11, v12 and v13. The jump from v10 to v12 comes with no breaking changes in the database structure, all fields remain compatible. The extension's own ViewHelpers have been migrated to the new Fluid version, custom templates need a short review after the update. In particular, the registration finisher and the email templates have to be checked, because TYPO3 v12 introduced stricter rules for error handling.

For older versions (sf_event_mgt 4.x and earlier) it is worth looking at the payment configuration, because the Stripe API has skipped several generations. The current extension supports Stripe Elements and 3D Secure 2, while older versions still worked with Stripe sources, which are now deprecated. Gosign typically migrates existing sf_event_mgt installations in one step together with the TYPO3 core upgrade. Fluid templates are unified to consistent identifiers, and outdated ViewHelper calls are automatically detected and replaced. At the same time we check whether the Schema.org/Event markup in the JSON-LD is up to date and whether the event detail template contains all the fields for Google event rich snippets.

--- Gallery TYPO3 - Image Gallery | Gosign ---
> Image gallery extension based on TYPO3 file collections. Lightbox, masonry layout, lazy loading. Gosign builds custom gallery templates in corporate design.

## Why sf_filecollection_gallery solves image galleries in TYPO3 the right way

Image galleries are among the most common requirements on corporate websites - product photos, team pictures, event documentation, reference projects. TYPO3 itself does not include a native gallery element. The standard content element "Images" shows images stacked or in columns but without lightbox, without filtering and without flexible layout options. sf_filecollection_gallery fills this gap by using TYPO3 file collections as a data source for galleries, providing lightbox integration, various layouts and lazy loading.

The decisive advantage over other gallery extensions: editors work with the FAL system they already know. Images are organized in file collections, and the gallery automatically displays all images from the assigned collection. Adding new images means: drag image into the collection, done.

## Typical use cases

**Reference projects and portfolios.** An architecture agency shows 15 to 40 images per project page in a gallery. The editor maintains one file collection per project. sf_filecollection_gallery renders the gallery as a grid with lightbox. Clicking an image opens the full view with navigation to the next and previous image. Image descriptions from FAL metadata (title, alt text, description) are automatically displayed as captions.

**Event documentation and press photography.** A trade show organizer documents each event with 50 to 200 photos. Images are batch-uploaded into a file collection. sf_filecollection_gallery automatically generates thumbnails, optimizes loading time through lazy loading and displays the gallery in masonry layout, which elegantly handles different aspect ratios.

**Product catalogs with visual presentation.** A furniture manufacturer shows an ambiance gallery per product category. Through multiple file collections (one per category) and a frontend plugin with category filter, visitors can switch between galleries without reloading the page.

## Technical architecture

sf_filecollection_gallery is an Extbase extension that integrates as a TYPO3 plugin into content elements. The data source is TYPO3 file collections from the File Abstraction Layer (FAL).

The architecture is structured in three layers:

- **Data source**: the extension reads file collections through the TYPO3 FAL API. Supported are static collections (manually assigned files), folder-based collections (all files in a folder) and category-based collections.
- **Rendering engine**: Fluid templates control the output. The extension ships templates for grid layout, masonry layout and simple lists. All templates are overridable - through standard TYPO3 mechanisms (TypoScript template paths), custom Fluid templates can be integrated.
- **Lightbox integration**: sf_filecollection_gallery supports multiple lightbox libraries: Fancybox, PhotoSwipe and Lightcase. The choice is controlled via TypoScript configuration. Gosign recommends PhotoSwipe due to better touch support and no jQuery dependency.

Lazy loading is natively integrated: images below the visible area are only loaded when the user scrolls. This uses the native `loading="lazy"` attribute and optionally Intersection Observer for older browsers.

Dependencies: TYPO3 Core (v10+), FAL. Lightbox libraries are shipped as frontend assets or can be included through the project's own asset pipeline. An advantage of the file collection architecture: images can appear in multiple galleries simultaneously without being duplicated. A reference to the same FAL object in different collections suffices. This saves storage space and ensures metadata (alt text, title, copyright) is centrally maintained.

## Common problems and solutions

**Gallery shows no images despite a filled file collection.** Cause is frequently an incorrect storage configuration. The file collection references a storage the frontend cannot access (e.g. a non-public storage or a storage with an incorrect base URL). Solution: check in the TYPO3 backend under File List whether images reside in the correct storage and whether the storage is configured as "public". Additionally, the plugin content element must have the correct starting point (SysFolder or page) configured where the file collection was created.

**Lightbox does not work, images open as new page.** The lightbox JavaScript library is not loaded. This is frequently caused by a missing TypoScript include or a conflict with another JavaScript library on the page. Solution: check in the browser dev tools whether the lightbox JS file is loaded and whether JavaScript errors appear in the console. With jQuery-based lightboxes (Fancybox), a jQuery version conflict may be the cause.

**Loading time too high with large galleries.** A gallery with 100+ images in high resolution can load slowly despite lazy loading because thumbnails are not sufficiently compressed. Solution: configure TYPO3 Image Processing to generate thumbnails at fixed dimensions (e.g. 400x300px) and optimized quality (75-80%). Additionally, enable WebP format through the TYPO3 image processing configuration.

## Migration and version compatibility

sf_filecollection_gallery is actively maintained and available for TYPO3 v11 and v12 LTS. The extension has a stable API and minimal breaking changes between versions. For TYPO3 v13, compatibility is typically established shortly after the LTS release.

For those migrating from an older gallery extension (e.g. tt_products_gallery, ws_flexslider as a gallery substitute or custom gallery plugins), only the data source needs to change: organize images in file collections and place the sf_filecollection_gallery plugin on the pages. The images themselves remain in FAL and do not need to be moved.

During a TYPO3 upgrade from v10 to v12, the lightbox configuration should be reviewed. Fancybox 2 is no longer compatible with current jQuery versions. Gosign recommends switching to PhotoSwipe, which works without jQuery and delivers better performance on mobile devices. PhotoSwipe also supports touch gestures (pinch-to-zoom, swipe) that meet user expectations on smartphone screens. The migration from Fancybox to PhotoSwipe typically requires 4 to 8 hours: new JavaScript initialization, adapted lightbox template and CSS fine-tuning for transition animations.

--- sf_register TYPO3 - Frontend Registration | Gosign ---
> sf_register: frontend user registration in TYPO3. Profile management, double opt-in. AI-accelerated.

## Why TYPO3 cannot become a user portal without a registration extension

The TYPO3 core knows fe_users as a database table and a standard login form, but it has no built-in way for a new user to register themselves, maintain their data or reset their password. Every website that is more than a pure publication platform needs that capability: communities, member areas, protected downloads, personalised newsletters, paid content. sf_register fills this gap with a lean Extbase-based approach that focuses specifically on registration, profile and password reset and deliberately skips features that the all-in-one solution femanager brings along.

## Typical use cases

A specialist publisher with 3,500 subscribers offers online access to journal articles and studies. Each subscriber gets an account tied to their subscription number. sf_register handles the initial registration with double opt-in confirmation via email, creates the user automatically in the "subscriber" group and unlocks access to the protected pages. When the subscription expires, a TYPO3 scheduler task removes the group membership without deleting the account, so that the user regains access after renewing the contract.

A second case is a professional association with around 7,000 member companies running a protected members' portal with conference documentation, standards previews and discussion forums. sf_register handles initial registration but simultaneously triggers a manual approval process in which an association employee verifies the affiliation with the member company before activating the account. The workflow combines double opt-in with admin approval and uses the extension's event hooks for that.

The third context is public institutions such as adult education centres or city libraries that want to tie course bookings or catalogue wish lists to a user account. What matters most here is a lightweight setup with low complexity: the extension does not need to manage twenty profile fields, just name, email, password and a library customer number. That is all, and sf_register delivers exactly that.

## Technical architecture: Extbase, TCA and finishers

sf_register is cleanly built on the Extbase model. A dedicated FrontendUser model extends the core user, controller actions handle create, edit, confirm and resetPassword, and templating runs through Fluid layouts. Required fields are controlled via TCA configuration and can be extended through an extension-specific configuration file. Custom fields such as company, position or membership number need a small TCA entry, a model property and an addition to the Fluid template, which gives developers a clear structure but also means that every tweak requires code work.

The double opt-in process relies on hash-based confirmation links stored in the fe_users table as a temporary token, which reset the disable flag on click. Emails are sent via the TYPO3 mailer interface, which internally sits on top of Symfony Mailer, so that more complex setups with SMTP proxies or mailing services such as SendGrid work without problems. Password hashing uses TYPO3's own password hash services and is therefore automatically in sync with every core update.

## Common problems and solutions

The first problem is spam registrations. Every public registration page attracts bots that automatically create accounts to send emails to third parties via the password reset form or to place trackback spam in community features. A clean solution combines sf_register with a CAPTCHA extension such as sr_freecap or a honeypot field, complemented by rate limiting on the registration URL in the reverse proxy.

The second problem concerns email deliverability. Confirmation emails regularly end up in the spam folder if the TYPO3 server runs without an SPF record, DKIM signature or reverse DNS. The extension sends the mail correctly, but the receiving server silently drops it. The solution does not lie in sf_register but in the mail infrastructure: a dedicated sending service with an established domain reputation noticeably reduces the bounce rate.

The third topic is data protection. Registered users must be able to view, correct and delete their data at any time, and deletion has to cascade, which means orders, downloads and other linked records have to be covered as well. sf_register provides edit forms but no GDPR-compliant deletion process. That has to be added as a separate workflow in which the account deletion anonymises dependent data either immediately or after a retention period.

A fourth typical problem concerns password policies. By default, sf_register also accepts weak passwords, and users tend to pick short or trivial combinations. TYPO3 password policies can be enabled through the system configuration, so that sf_register automatically applies minimum length, character classes and blacklist checks without any need to modify the extension itself.

## Migration and version compatibility

sf_register is stable on TYPO3 v11 and v12 and has a reputation in the community as a solid, maintainable alternative to femanager. v13 support is usually available shortly after the release of a new TYPO3 core, although custom extensions then require a review of the Extbase annotation syntax, which has seen minor adjustments between versions.

Anyone migrating from femanager to sf_register saves complexity but should check which features were actually used: femanager offers admin confirmation, profile picture upload and backend moderation out of the box, while sf_register only replicates these functions through additional code or event listeners. Conversely, the migration path from sf_register to femanager is easier because the data structure is largely compatible. Gosign handles these migrations including mail template porting and reconciliation of user groups, so that existing users can still log in after the switch.

Anyone setting up a new project should think through the real requirements of the portal before choosing: does the operator need manual approvals, profile pictures, complex role assignments? Then femanager is the faster path. Is a lean self-service registration with a clean Extbase foundation and little overhead enough? Then sf_register is the right choice. The decision is rarely close once you have gone through the catalogue of required functions once, and it saves significant rework later on.

--- sg_forms TYPO3 - Forms | Gosign ---
> Form extension by SGalinski. Alternative to Powermail and the native TYPO3 Form Framework. Gosign advises on the optimal form stack for your requirements.

## Drei Formular-Systeme in TYPO3 erzeugen mehr Verwirrung als Auswahl

TYPO3-Projekte stehen bei der Formular-Implementierung vor einem ungewöhnlichen Luxusproblem: Es gibt drei ernst zu nehmende Optionen. Das native TYPO3 Form Framework (ext:form), powermail von in2code und sg_forms von SGalinski. Jede Lösung hat eigene Stärken und eigene Limits. sg_forms positioniert sich als Mittelweg: leichtgewichtiger als powermail, aber mit mehr Backend-Komfort als ext:form. Die Extension stammt vom TYPO3-Dienstleister SGalinski und wird in dessen Kundenprojekten aktiv eingesetzt.

Wer bereits SGalinski-Extensions im Einsatz hat (sgalinski_base, sg_cookie_optin), findet in sg_forms eine Lösung, die sich nahtlos ins SGalinski-Ökosystem einfügt.

## Typical use cases include Kontaktformulare, Anfragen und einfache Bewerbungsformulare

Das Standard-Szenario ist das Kontaktformular auf einer Unternehmenswebsite. Name, E-Mail, Betreff, Nachricht, GDPR-Checkbox, Absenden. sg_forms liefert dieses Setup als vorkonfiguriertes Template, das Redakteure im Backend aktivieren und anpassen können. Felder lassen sich hinzufügen, entfernen und umsortieren, Pflichtfelder markieren, Validierungen setzen. Die E-Mail geht an eine oder mehrere konfigurierbare Empfänger-Adressen.

Ein zweites Szenario sind mehrseitige Anfrage-Formulare. Ein Handwerksbetrieb fragt auf Seite 1 die Kontaktdaten, auf Seite 2 die Art der Dienstleistung (Dropdown) und auf Seite 3 Fotos des Objekts (Datei-Upload). sg_forms unterstützt mehrstufige Formulare mit Fortschrittsanzeige und Zurück-Navigation. Die Daten werden nach dem Absenden als E-Mail und optional als Datenbank-Eintrag gespeichert.

Drittes Szenario: Einfache Bewerbungsformulare. Ein KMU mit drei offenen Stellen braucht kein Bewerbermanagement-System, aber ein Formular, das Lebenslauf und Anschreiben als PDF-Upload entgegennimmt und an die Personalabteilung weiterleitet. sg_forms bietet dafür den Datei-Upload mit Typen- und Grössenvalidierung, kombiniert mit einer Bestätigungsmail an den Bewerber.

## Technical architecture is based on Extbase mit YAML-basierter Formulardefinition

sg_forms registriert ein Extbase-Plugin, das Formulare aus einer Konfiguration rendert. Die Formulardefinition wird im Backend über ein grafisches Interface erstellt oder alternativ als YAML-Datei definiert. Jedes Feld hat einen Typ (Text, E-Mail, Textarea, Select, Radio, Checkbox, File, Hidden), Validierungsregeln und optionale Bedingungen.

Die Finisher-Architektur folgt dem gleichen Pattern wie bei powermail: Nach dem Absenden werden nacheinander Aktionen ausgeführt. Die Standard-Finisher sind E-Mail-Versand, Datenbank-Speicherung und Redirect auf eine Dankes-Seite. Custom Finisher lassen sich als PHP-Klassen implementieren, etwa für CRM-Anbindungen oder Webhook-Aufrufe.

Das Frontend-Rendering läuft über Fluid-Templates, die per SiteSet oder TypoScript überschrieben werden können. Die Extension liefert ein Default-Template mit, das ohne Anpassung funktioniert, aber für produktive Websites typischerweise an das CI angepasst wird. Spam-Schutz ist über Honeypot-Felder und optionale CAPTCHA-Integration verfügbar.

## Common problems involve die Abgrenzung zu powermail und die SGalinski-Lizenz

Die häufigste Frage ist: sg_forms oder powermail? Die Antwort hängt von der Projektgrösse ab. powermail hat die grössere Community, mehr Dokumentation, mehr Drittanbieter-Finisher und eine breitere Feature-Palette (PDF-Export, mehrstufige Logik mit beliebiger Komplexität). sg_forms ist schlanker, hat weniger Overhead und ist in SGalinski-Projekten der Standard. Für die meisten Unternehmenswebsites ist powermail die sicherere Wahl. Für SGalinski-Kunden, die bereits im Ökosystem sind, ist sg_forms die konsistentere.

Zweites Thema: Die Lizenzierung. sg_forms ist nicht im TER (TYPO3 Extension Repository) als Free-Extension verfügbar, sondern wird über SGalinski-Projekte ausgeliefert. Das bedeutet, dass Teams, die die Extension ohne SGalinski-Beziehung nutzen wollen, die Verfügbarkeit und Lizenzbedingungen direkt mit SGalinski klären müssen.

Drittes Problem: Migration. Wer von powermail zu sg_forms wechselt (oder umgekehrt), muss alle bestehenden Formulardefinitionen neu anlegen, weil die Datenstrukturen inkompatibel sind. Bestehende Formular-Einträge in der Datenbank können nicht automatisch migriert werden.

## TYPO3 v12 wird unterstützt, v13 folgt dem SGalinski-Release-Zyklus

SGalinski pflegt sg_forms im eigenen Release-Zyklus, der an die TYPO3-LTS-Versionen gekoppelt ist. TYPO3 v12 wird aktiv unterstützt. Für v13 ist mit einem Update zu rechnen, sobald SGalinski die eigene Extension-Suite aktualisiert. Gosign empfiehlt bei der Wahl des Formular-Systems, die langfristige Pflege und die Community-Grösse als Entscheidungsfaktor zu gewichten: powermail mit über 500.000 Installationen hat eine breitere Basis als sg_forms, was bei TYPO3-Upgrades kürzere Wartezeiten auf kompatible Versionen bedeutet.

--- Shibboleth TYPO3 - SSO Basis | Gosign ---
> Shibboleth base extension for TYPO3 (sister of shibboleth_auth). Service provider integration for backend and frontend. Standard SSO for universities.

## Hochschulen und Forschungseinrichtungen brauchen Shibboleth-SSO direkt in TYPO3

Im akademischen Sektor ist Shibboleth der De-facto-Standard für Single Sign-On. Über 3.000 Einrichtungen weltweit sind in Shibboleth-Föderationen organisiert, in Deutschland über den DFN-AAI-Verbund mit über 700 teilnehmenden Organisationen. Die Shibboleth-Extension für TYPO3 integriert den Service Provider direkt ins CMS. Studierende, Dozierende und Mitarbeitende melden sich mit ihrer Hochschulkennung an und erhalten Zugang zu geschützten Frontend-Bereichen und bei Bedarf zum TYPO3-Backend. Die Extension ist die Schwester von shibboleth_auth und bietet die Basis-Integration für den Shibboleth SP, der auf dem Webserver installiert sein muss.

Im Gegensatz zur saml2-Extension, die einen eigenen SP in PHP implementiert, setzt die shibboleth-Extension auf den nativen Shibboleth Service Provider (C++ oder Java), der als Apache-Modul oder ISAPI-Filter läuft. Das ist die robustere Architektur für Hochverfügbarkeitsumgebungen.

## Typical use cases involve DFN-AAI, Bibliothekssysteme und Forschungsportale

Das primäre Szenario ist die DFN-AAI-Integration an deutschen Hochschulen. Eine Universität betreibt ihr Webportal auf TYPO3. Studierende klicken auf "Login", werden zum IdP der Hochschule weitergeleitet, authentifizieren sich und landen zurück auf der TYPO3-Seite mit einer aktiven Session. Die Extension liest die Shibboleth-Attribute aus den Server-Umgebungsvariablen (REMOTE_USER, eppn, mail, affiliation) und erstellt oder aktualisiert den TYPO3-Frontend-User.

Ein zweites Szenario sind Bibliotheks-Zugänge. Hochschulbibliotheken bieten Online-Datenbanken, E-Journals und Forschungsdokumente über ihre TYPO3-Website an. Der Zugang ist auf Hochschulangehörige beschränkt. Die Shibboleth-Extension prüft das Attribut "eduPersonEntitlement" und gewährt nur Nutzern mit dem Wert "urn:mace:dir:entitlement:common-lib-terms" Zugang zu lizenzierten Inhalten.

Drittes Szenario: Föderierte Forschungsportale. Ein Forschungskonsortium mit Partnern aus fünf Universitäten betreibt ein gemeinsames Portal auf TYPO3. Jeder Partner hat seinen eigenen IdP. Über die DFN-AAI-Föderation können alle Partner-Mitarbeitenden sich anmelden, ohne dass das Portal eigene Accounts verwalten muss. Die Extension ordnet die Nutzer basierend auf dem Attribut "schacHomeOrganization" der richtigen Partner-Gruppe zu.

## Technical architecture setzt einen installierten Shibboleth SP auf dem Webserver voraus

Die Extension selbst enthält keinen SAML-Stack. Sie liest die Attribute, die der Shibboleth SP nach erfolgreicher Authentifizierung als Server-Umgebungsvariablen oder HTTP-Header bereitstellt. Der SP muss als Apache-Modul (mod_shib) oder als FastCGI-Authorizer konfiguriert sein. Für nginx-Setups ist ein Shibboleth SP als FastCGI-Backend oder ein lua-basierter Proxy nötig.

Die TYPO3-Extension registriert einen Authentication Service, der bei jedem Frontend- oder Backend-Login prüft, ob Shibboleth-Attribute vorhanden sind. Wenn ja, werden die Attribute auf TYPO3-User-Felder gemappt: REMOTE_USER auf username, mail auf email, givenName und sn auf first_name und last_name. Die Gruppenzuordnung erfolgt über das Attribut "eduPersonAffiliation": student, faculty, staff, employee werden auf TYPO3-Frontend-Gruppen gemappt.

Die Session-Verwaltung folgt dem Shibboleth-Lifecycle: Wenn die Shibboleth-Session abläuft, wird der TYPO3-User automatisch ausgeloggt. Single Logout (SLO) wird über den Shibboleth SP abgewickelt, die TYPO3-Extension reagiert auf das Logout-Event und zerstört die TYPO3-Session.

## Common problems involve die Apache-Konfiguration und fehlende Attribute

Das grösste Problem ist die korrekte Apache-Konfiguration. Der Shibboleth SP muss wissen, welche URLs er schützen soll. Eine falsche Location-Direktive führt dazu, dass der SP entweder alle Seiten schützt (auch öffentliche) oder gar keine. Die Standard-Konfiguration schützt /Shibboleth.sso/* für den SP selbst und /typo3/ für das Backend. Frontend-Bereiche werden per Lazy Session geschützt: Der SP setzt Attribute, wenn eine Shibboleth-Session existiert, erzwingt aber keine Authentifizierung. Die Extension prüft dann im TYPO3-Frontend, ob Attribute vorhanden sind, und zeigt geschützte Inhalte nur angemeldeten Nutzern.

Zweites Problem: Fehlende oder leere Attribute. Nicht jeder IdP liefert alle Attribute. Wenn der IdP das Attribut "mail" nicht freigibt, kann die Extension keine E-Mail-Adresse in den TYPO3-User schreiben. Die Lösung: Mit dem IdP-Betreiber (Rechenzentrum) klären, welche Attribute für den SP freigegeben sind, und das Attribute-Mapping in der Extension entsprechend konfigurieren.

Drittes Thema: Container-Deployments. Docker-basierte TYPO3-Installationen haben oft keinen Apache mit mod_shib. Die Alternative ist ein Shibboleth SP als Reverse Proxy vor dem TYPO3-Container, der die Attribute als HTTP-Header weiterleitet. Die Extension muss dann so konfiguriert werden, dass sie Attribute aus Headern statt aus Umgebungsvariablen liest. Wichtig: Die Header müssen vor Spoofing geschützt werden, indem der Reverse Proxy eingehende Header mit Shibboleth-Attributnamen entfernt.

## TYPO3 v12 funktioniert, v13-Kompatibilität requires eine Prüfung der Authentication-Service-API

Die shibboleth-Extension nutzt die TYPO3 Authentication Service API, die seit Jahren stabil ist, aber in v13 Anpassungen erfahren hat. Unter TYPO3 v12 läuft die aktuelle Version ohne Probleme. Für v13 ist ein Update der Service-Registrierung und der Middleware-Konfiguration nötig. Hochschulen, die TYPO3-Upgrades planen, sollten die SSO-Integration als eigenen Testblock in die Upgrade-Planung aufnehmen. Gosign empfiehlt, parallel zur shibboleth-Extension die oidc-Extension zu evaluieren, weil viele IdPs inzwischen sowohl SAML als auch OIDC unterstützen und OIDC die einfachere Architektur ohne Shibboleth SP auf dem Server ermöglicht.

--- shibboleth_auth TYPO3 - SSO Integration | Gosign ---
> Shibboleth SSO in TYPO3: setup, attribute mapping & troubleshooting. Enterprise auth with AI-accelerated development.

## How universities connect their TYPO3 portals to central identity management

Anyone running a TYPO3 portal at a European research university cannot avoid Shibboleth. National research network federations such as DFN-AAI in Germany, SWITCHaai in Switzerland or eduGAIN across Europe operate the largest identity federations in the academic space, and every university that wants to offer research data, teaching materials or administrative services to the outside world has to authenticate its users against a Shibboleth Identity Provider. shibboleth_auth is the extension that plugs TYPO3 into this landscape: it reads the SAML assertions provided by an upstream Shibboleth Service Provider and uses them to create fe_users and be_users.

## Typical use cases

A medical faculty with 8,000 students runs a TYPO3 portal for clinical curricula. Students should see their teaching materials after login, while lecturers additionally get an editorial interface. The university's central Shibboleth IdP delivers attributes such as eduPersonAffiliation, schacHomeOrganization and a unique identifier. shibboleth_auth handles the mapping of these attributes onto TYPO3 groups and ensures that a student never reaches the backend, while a lecturer automatically lands in the editor group.

A second typical case is non-university research institutions such as Max Planck Institutes or Fraunhofer centres. Their staff come from dozens of partner universities, and each researcher should be able to log in to shared project portals using their home credentials. shibboleth_auth combined with an eduGAIN-connected SP makes exactly that possible: a visiting researcher from Zurich logs in with their SWITCHaai account on a German portal, without any local account having to exist.

The third context is public administration, where regional governments increasingly run statewide IdPs to consolidate citizen accounts and staff logins. A state authority with several TYPO3 portals for different departments can connect them all through shibboleth_auth to the central state IdP and avoid maintaining separate user databases per portal.

## Technical architecture between SP, SAML and fe_user

shibboleth_auth is built differently from classic TYPO3 auth services: the extension does not speak SAML directly but delegates the entire protocol to a locally installed Shibboleth Service Provider. The SP, typically the shibd daemon with mod_shib in Apache or the corresponding Nginx module, processes the SAML assertion, validates signatures and certificates and exposes the extracted attributes as HTTP environment variables. shibboleth_auth reads these variables, creates or updates the fe_user and logs them into the TYPO3 session.

The extension is configured through the TYPO3 extension configuration and the Extbase service pattern for auth providers. Attribute mapping lives in a TypoScript file or directly in the extension backend: HTTP variable on the left, TYPO3 field name on the right, optionally with transformations for group IDs. The order in the $TYPO3_CONF_VARS['SVCONF']['auth']['setup'] configuration matters, so that shibboleth_auth kicks in before the default login service.

## Common problems and solutions

The most common failure is a redirect loop: the user is sent to the IdP, returns, is sent to the IdP again, and so on. The cause is almost always a mismatch between the SP session domain and TYPO3's, or a missing cookie because the SP writes its session under a different path than TYPO3 expects. The clean solution is a strict separation: SP session under the path /Shibboleth.sso, TYPO3 session under / and both under the same top-level domain.

The second issue involves attributes: the IdP delivers a different attribute name than the extension expects. Especially in DFN-AAI, attribute namespaces shift between OID and URN notation. Without clean normalisation, the user ends up in no group at all or gets an empty name written into their profile. An attribute map file on the SP that folds old and new names onto a single local name resolves the problem permanently.

The third topic is certificate rollover. Every IdP regularly rotates its signing and encryption certificates, typically every two years. The SP has to pull the new certificates via the metadata feed, otherwise assertion validation suddenly breaks. The metadata provider configuration in shibboleth2.xml should therefore always run with an automatic refresh interval of a few hours and with signature verification against the federation signer.

A fourth problem area is session lifetimes. Shibboleth and TYPO3 sessions have timeouts that are independent of each other: if the SP session expires while the TYPO3 session is still active, the user can still see their protected content, but a fresh login fails because the SP no longer has a valid assertion. The clean solution is to set both session durations to the same value and to configure a parallel logout behaviour, so that Single Logout actually ends both sessions.

## Migration and version compatibility

shibboleth_auth has followed TYPO3 v9, v10 and v11 for a long time through community forks, but the situation in v12 and v13 varies depending on the fork branch. Some forks have moved to Symfony-based auth services, others have stopped at v11. Anyone migrating to v12 today should check before the upgrade whether their extension branch is still maintained or whether switching to the OIDC extension is the better choice.

The migration path from Shibboleth to OIDC has become relevant for many universities since Keycloak and similar identity brokers can serve SAML and OIDC clients in parallel. Gosign has accompanied such transitions several times and typically runs both auth paths side by side during the switchover, so that legacy systems keep logging in via Shibboleth while new portals speak OIDC directly.

Anyone planning to stay on shibboleth_auth permanently should assess the maintenance overhead realistically. The extension itself rarely changes, but the surrounding infrastructure does: Shibboleth SP releases security updates, federations update metadata and certificates, Apache or Nginx versions are replaced, and any one of these changes can break the login flow. Clean monitoring of the auth pipeline with synthetic logins and alerts on failed assertions is therefore not a nice-to-have but part of the operational model for a stable SSO integration.

--- Slick Carousel TYPO3 - Slider | Gosign ---
> Slick slider integration for TYPO3. jQuery-based. Gosign migrates to Swiper or Splide: no jQuery needed, better performance, native touch events.

## Slick Carousel forces TYPO3 websites to load jQuery even though alternatives without it have existed for years

Slick (by Ken Wheeler) was the most popular JavaScript slider between 2014 and 2020. "The last carousel you'll ever need" promised the documentation. Responsive, touch-capable, lazy loading, autoplay, infinite scroll, variable width. For TYPO3, the slickcarousel extension integrates Slick as a content element. The problem in 2026: Slick depends on jQuery. The last Slick release dates from 2017 (v1.8.1). No updates for over 8 years, no bug fixes, no security patches.

jQuery itself is needed by fewer and fewer TYPO3 projects. TYPO3 v12 and v13 no longer ship jQuery by default. Anyone using Slick Carousel must load jQuery (90 KB minified) as an additional dependency - only for the slider. This is technical debt that costs performance on every page load.

## Typical use cases

**Image carousels on subpages.** Product pages, reference pages or gallery pages with 5 to 20 images displayed as a horizontal slider. Slick renders the images with navigation arrows and optional dots. Autoplay cycles the images automatically. In practice, analytics data shows that users rarely click past the third image.

**Testimonial sliders.** Customer quotes that rotate as a carousel. Each slide shows a quote, name and optionally a photo. Slick is often configured here with centerMode (the active element is larger than its neighbors) and adaptiveHeight (slider height adjusts to content).

**Logo sliders for client references.** A horizontal strip with 10 to 30 client logos that cycle automatically. Slick in variableWidth mode (different logo widths) with infinite scroll (seamless cycling). This scenario is particularly easy to replace with CSS-only solutions (CSS animation with @keyframes) - entirely without JavaScript.

## Technical architecture

The slickcarousel extension for TYPO3 includes the Slick library (slick.min.js, 43 KB) and its CSS (slick.css + slick-theme.css, 8 KB). jQuery (90 KB) is loaded as a dependency if not already available globally. The content element allows editors to upload images and configure slider options: Slides to Show (1 to 6), Slides to Scroll, Autoplay (yes/no), Autoplay Speed (ms), Dots, Arrows, Fade effect, Responsive Breakpoints.

The configuration is stored as a data attribute on the slider container. The initialization script reads the options and calls `$('.slick-element').slick(options)`. For multiple sliders on a page, each is initialized separately.

The TYPO3 integration uses a Fluid template that renders images as `<div>` elements within the slider container. Each slide can contain text, links and CTA buttons alongside the image, depending on template configuration.

## Common problems and solutions

**Slider jumps on load (Layout Shift).** Slick initializes the slider via JavaScript. Until the script is loaded and executed, all images are displayed stacked vertically. Then the layout jumps when Slick arranges the images horizontally. This produces measurable Cumulative Layout Shift (CLS) - a Core Web Vital. Short-term solution: define CSS rules that correctly dimension the slider container before JavaScript initialization (fixed height, overflow:hidden). Long-term solution: switch to a library that natively prevents CLS.

**Touch events do not work consistently.** Slick's touch handling is based on a custom event implementation that no longer functions correctly on current iOS and Android versions. Particularly affected: swipe gesture interpreted as scroll, slider only responds to very fast swipe movements. Solution: there is no fix because Slick is no longer maintained. Migration is the only option.

**Accessibility deficiencies.** Slick produces markup that is not WCAG-compliant: missing ARIA labels, no keyboard navigation for dots, autoplay without pause button. For organizations that must comply with WCAG 2.1 AA (public institutions, European Accessibility Act from 2025), Slick is not usable without extensive modifications. Solution: Splide as alternative (full ARIA support, keyboard navigation, native autoplay pause).

## Migration and version compatibility

The slickcarousel extension supports TYPO3 v10 and v11. There is no official release for TYPO3 v12 and v13 (as of April 2026). The Slick library itself has been frozen at v1.8.1 since 2017 and is not being developed further.

Gosign migrates Slick-based sliders to Swiper (175+ features, touch-native, no jQuery, 40 KB) or Splide (WCAG-compliant, no jQuery, 30 KB). The migration comprises three steps: inventory slider configurations (which options are in use), integrate and configure the new library, adapt Fluid templates (markup structure and CSS classes change). Per slider, migration takes 2 to 4 hours. For a website with 5 different slider types, the project is completed in 2 to 3 days.

For logo sliders, Gosign recommends a pure CSS solution without JavaScript: a CSS animation (`@keyframes scroll`) moves the logos horizontally, `animation-play-state: paused` on hover stops the movement. The result is 0 KB JavaScript overhead and works on all browsers from IE 11 onward.

For testimonial and content sliders, Gosign recommends Splide because the extension includes full ARIA support and keyboard navigation. Since the European Accessibility Act (EAA, effective June 2025), new websites must meet WCAG 2.1 AA. Slick Carousel does not pass this test - Splide does. The migration from Slick to Splide pays off not just for performance but also for compliance.

Gosign documents the performance improvement after every slider migration: PageSpeed Score before/after, jQuery removal (if Slick was the only jQuery dependency), Core Web Vitals delta. For projects that switched from Slick to Splide, the average PageSpeed improvement was 12 to 25 points, primarily from eliminating jQuery and the smaller library size.

--- Opening Hours TYPO3 | Gosign ---
> Opening hours management for TYPO3: regular hours, holidays, special opening hours. Displays current status (open/closed).

## Besucher wollen wissen, ob eine Einrichtung gerade geöffnet hat, nicht die regulären Zeiten nachschlagen

Die häufigste Frage, die Besucher auf der Website einer Bibliothek, eines Museums oder einer Behörde haben, ist simpel: Haben Sie gerade offen? Trotzdem zeigen die meisten TYPO3-Websites eine statische Tabelle mit den regulären Öffnungszeiten, die an Feiertagen, Brückentagen und Sonderschliessungen falsch ist. slub_web_openhours löst genau dieses Problem. Die Extension verwaltet reguläre Öffnungszeiten, Feiertage und Sonderöffnungszeiten in einer einzigen Datenstruktur und zeigt im Frontend den aktuellen Status in Echtzeit an: Geöffnet (grün) oder Geschlossen (rot), inklusive der nächsten Öffnungszeit. Entwickelt wurde die Extension von der SLUB Dresden (Sächsische Landesbibliothek, Staats- und Universitätsbibliothek), die das Problem aus der Praxis kennt.

## Typical use cases involve Bibliotheken, Museen und kommunale Einrichtungen

Das primäre Szenario sind Hochschulbibliotheken mit mehreren Standorten. Die SLUB Dresden betreibt vier Standorte mit unterschiedlichen Öffnungszeiten. Der Hauptstandort hat andere Zeiten als die Zweigbibliothek, und während der Semesterferien gelten verkürzte Öffnungszeiten. slub_web_openhours verwaltet jeden Standort als eigenen Datensatz mit eigenen Zeiten. Auf der Website sieht ein Student sofort, welcher Standort gerade geöffnet ist und bis wann.

Ein zweites Szenario sind Museen und Galerien. Ein Kunstmuseum hat reguläre Öffnungszeiten (Di-So 10-18 Uhr, Mo geschlossen), aber verlängerte Öffnungszeiten während einer Sonderausstellung (täglich bis 21 Uhr) und Schliessungen an Feiertagen. Die Extension erlaubt, diese Ausnahmen für definierte Zeiträume zu hinterlegen, ohne die regulären Zeiten zu ändern. Nach Ablauf des Sonderzeitraums gelten automatisch wieder die Standardzeiten.

Drittes Szenario: Kommunale Einrichtungen wie Bürgerbüros, Schwimmbäder und Jugendzentren. Eine Stadt mit 20 öffentlichen Einrichtungen pflegt die Öffnungszeiten zentral im TYPO3-Backend. Auf jeder Einrichtungsseite zeigt ein Widget den aktuellen Status. Im Sommer gelten für das Freibad andere Zeiten als im Winter, und an Brückentagen ist das Bürgerbüro geschlossen. All das wird über die Extension abgebildet.

## Technical architecture stores Regeln und Ausnahmen in einer kalendarischen Datenstruktur

Die Extension definiert drei Datenebenen: reguläre Zeiten (Montag bis Sonntag, Stunde:Minute bis Stunde:Minute), periodische Ausnahmen (Feiertage, die jährlich wiederkehren) und einmalige Ausnahmen (Sonderschliessung am 15. März, verlängerte Öffnung am 24. Dezember). Reguläre Zeiten bilden die Basis, Ausnahmen überschreiben sie. Die Logik ist einfach: Gibt es für das aktuelle Datum eine Ausnahme? Wenn ja, gelten die Ausnahme-Zeiten. Wenn nein, gelten die regulären Zeiten für den aktuellen Wochentag.

Das Frontend-Plugin rendert den Status über Fluid-Templates. Der aktuelle Zustand (offen/geschlossen) wird serverseitig berechnet und als CSS-Klasse ausgegeben, sodass die Farbgebung per Tailwind oder Custom CSS steuerbar ist. Optional zeigt das Widget die nächste Öffnungszeit an: "Aktuell geschlossen. Nächste Öffnung: Montag, 08:00 Uhr."

Für die Schema.org-Integration kann die Extension OpeningHoursSpecification als JSON-LD ausgeben, was Google in den Knowledge-Panel-Einträgen der Organisation anzeigt. Das ist besonders für Einrichtungen relevant, die in Google Maps erscheinen und dort korrekte Öffnungszeiten zeigen wollen.

## Common problems involve Zeitzonen, fehlende Feiertage und Caching

Das häufigste Problem ist das Caching. Wenn TYPO3 die Seite cached und der Cache erst nach zwei Stunden abläuft, zeigt das Widget bis zu zwei Stunden lang den falschen Status. Die Lösung: Das Öffnungszeiten-Widget per USER_INT als uncached Plugin einbinden. Das kostet minimal Performance (eine Datenbankabfrage pro Request), garantiert aber korrekten Status.

Zweites Problem: Fehlende Feiertage. Die Extension liefert keine vorkonfigurierte Feiertagsliste. Jede Einrichtung muss ihre Feiertage manuell eintragen oder über einen Import befüllen. Für bundeslandspezifische Feiertage (Fronleichnam gilt in Bayern, nicht in Berlin) ist manuelle Pflege oder ein Skript nötig, das Feiertage aus einer API (z.B. feiertage-api.de) importiert.

Drittes Thema: Zeitzonen bei internationalen Einrichtungen. Die Extension arbeitet mit der Server-Zeitzone. Wenn der TYPO3-Server in UTC läuft, aber die Einrichtung in MEZ, stimmen die angezeigten Zeiten nicht. Die Lösung: Die PHP-Zeitzone in der TYPO3-Konfiguration auf die Zeitzone der Einrichtung setzen, oder bei Einrichtungen in mehreren Zeitzonen die Berechnung per UTC+Offset im Fluid-Template anpassen.

## Die Extension läuft unter TYPO3 v11 und v12, v13-Support ist vom SLUB-Team abhängig

slub_web_openhours wird von der SLUB Dresden als Open-Source-Projekt gepflegt. Updates folgen dem internen Release-Zyklus der Bibliothek. TYPO3 v12 wird unterstützt. Für v13 hängt die Kompatibilität davon ab, ob das SLUB-Entwicklungsteam die Extension aktualisiert. Da die Extension technisch schlank ist (keine komplexen API-Abhängigkeiten), ist die Migration auf v13 mit geringem Aufwand möglich. Gosign empfiehlt bei Öffnungszeiten-Projekten, die Extension parallel zur Schema.org-Ausgabe auf der Google-Seite zu validieren, damit die Öffnungszeiten in Google Maps und im Knowledge Panel korrekt erscheinen.

--- solrfal TYPO3 - Solr File Indexing | Gosign ---
> solrfal for TYPO3: index files in Apache Solr. Setup, tuning & migration, AI-accelerated. 25 years of experience.

## Why the TYPO3 default search fails at scale with document archives

As soon as a TYPO3 installation manages more than a few hundred PDF documents, the built-in search runs into two hard limits: it only finds content stored in database fields, not inside files, and its ranking logic ignores the relevance signals that editors actually need. solrfal closes exactly this gap by wiring the TYPO3 File Abstraction Layer (FAL) directly into Apache Solr and making every file searchable, including its metadata. The extension is aimed at organisations that treat documents as the core of their knowledge work: public authorities with forms, publishers with specialist literature, universities with teaching materials.

## Typical use cases

At a technical university with around 40,000 students, the examination regulations live in 180 PDF files distributed across twelve faculties. Without solrfal, a student can only find the paragraph about registering for an exam if an editor has additionally copied the text into a meta description. With solrfal, Apache Tika indexes every page and the search query returns the right paragraph including the citation.

A second scenario is familiar to government agencies that publish laws, guidelines and forms through a TYPO3 CMS. The documents change frequently and access rights are tied to organisational units. solrfal automatically synchronises the fe_groups membership of each file into the Solr index, so that a staff member from department V only sees results they are authorised to read.

The third case appears at specialist publishers: a publisher with 12,000 journal articles as PDF wants to make its archive searchable via a faceted search by year, author and category. solrfal extracts the metadata, populates the Solr fields and provides the data basis for a facet that classic TYPO3 extensions such as ke_search can no longer handle at this scale.

## Technical architecture on top of Apache Tika and EXT:solr

solrfal is an extension of the core EXT:solr extension from dkd Internet Service and requires a running Apache Solr server, typically version 8 or 9. The actual text extraction is handled by Apache Tika, either as an embedded service inside the Solr container or as a standalone Tika server. solrfal hooks into the FAL lifecycle via the TYPO3 event API: every uploaded, moved or deleted file triggers an indexing job that is processed asynchronously by the TYPO3 scheduler.

Configuration runs through TypoScript and the extension configuration. The Solr schema can be adjusted via the Managed Schema API, so additional fields such as document type, department or language can be added without a Solr restart. Relevance tuning happens via boosting queries and function queries defined in the EXT:solr query configuration. solrfal inherits all language features of EXT:solr, including multilingual analyzers for English, German, French and other standard languages.

## Common problems and solutions

The first problem usually surfaces during the initial index run: Apache Tika crashes with an OutOfMemoryError on broken or encrypted PDFs and takes the entire indexer down with it. The extension then marks the file as faulty but does not automatically skip it on the next run. We analyse the Tika logs, separate the encrypted files from the genuinely damaged ones and set up a pre-check that filters problematic files out before they ever reach the indexer.

The second recurring topic is relevance. Teams report that the search does find all documents, but irrelevant hits appear at the top. The cause is almost always the default field weighting: solrfal indexes the entire file content into a single field without distinguishing between title, headings and body. A clean solution requires a tailored schema with separate fields for title, metadata and body, plus boosting rules that weight title matches higher.

The third problem concerns performance with large archives. From around 50,000 indexed files onwards, the scheduler becomes the bottleneck because solrfal processes every job individually. The solution is batch indexing combined with a dedicated worker process that runs in parallel to the normal scheduler tasks and processes solrfal jobs with priority. On top of that, differential indexing pays off: only newly added or changed files are reprocessed on each run, which significantly reduces maintenance overhead for stable document archives.

A fourth, rarer issue appears in multilingual installations: solrfal indexes files language-agnostic into a shared index, so a French study can show up in the German results list if the search term is internationally common. A clean language separation requires multiple Solr cores or an additional language facet, which can be configured per site root via the EXT:solr configuration.

## Migration and version compatibility

solrfal follows the release cycle of EXT:solr, which currently supports TYPO3 v12 and v13. The jump from TYPO3 v9 to v12 is the most common migration path and almost always means a jump from Solr 6 to Solr 9 as well. The schema format, the Managed Schema API and several analyzer classes change along the way, which makes a full reindex mandatory. Existing boosting rules have to be validated against the new query parser behaviour, because Solr 9 evaluates certain default operators differently than Solr 6.

Anyone migrating from ke_search or a purely database-backed search has to factor in that solrfal requires a dedicated Solr server and therefore extends the hosting requirements. Gosign has been guiding these migrations for years and, where needed, also handles the switch to a containerised Solr setup that fits into existing deployment pipelines.

It is also worth noting that the maintenance burden of solrfal should not be underestimated: Solr itself receives regular security updates, and the schema has to be reviewed against new analyzer classes on every major upgrade. A project that commits to solrfal also commits to running its own search stack and should factor that into the initial sizing and into the planning of operational resources.

--- sr_freecap TYPO3 - Self-Hosted CAPTCHA | Gosign ---
> TYPO3 CAPTCHA extension without external services. Self-hosted spam protection, GDPR-compliant, no data sent to Google. Alternative to reCAPTCHA.

## Why European authorities and hospitals rely on self-hosted CAPTCHA protection

Google reCAPTCHA is technically effective but legally problematic for many operators in Europe: every embedding results in personal data being transferred to Google in the United States, requires an active consent under GDPR and the ePrivacy framework and is viewed critically by several regional data protection authorities. sr_freecap is the answer to this problem: a fully self-hosted CAPTCHA extension for TYPO3 that triggers no external requests, transfers no user data to third parties and therefore works without running into the consent banner trap. The target audience are public authorities, hospitals, universities and privacy-conscious companies that need to protect forms against bot spam without taking on a new dependency on a US service.

## Typical use cases

A university hospital runs a contact form for patient enquiries, an application form for nursing staff and a press enquiry form. All three are regularly attacked by bots that submit generic advertising messages or phishing attempts. Hospital IT has decided not to embed any Google services because the data protection officer wants to avoid the consent obligation. sr_freecap generates image graphics with letter combinations server-side, validates the input on its own server and never sends any information to the outside.

A second case is a city administration with around 15 online forms for citizen services, from relocation notifications to applications for residential parking permits. The regional data protection officer explicitly recommended not to use external CAPTCHAs in an audit. sr_freecap integrates with the TYPO3 form API (Powermail or the form framework) and therefore protects all forms without additional consent.

The third context is chambers and professional associations that maintain member directories, addresses or public registers. Each of these organisations runs a search form or a contact form that has to be bot-protected while preserving its privacy posture. sr_freecap offers a simple visual test that is solvable for humans and presents a noticeable hurdle for simple OCR bots.

## Technical architecture: GD library, session and form API

sr_freecap generates the CAPTCHA images server-side using the GD library or ImageMagick, with GD being the default option and available out of the box in almost every PHP installation. Letters are drawn randomly from a configurable alphabet, rendered into an image with background noise and distortion and delivered to the browser. The expected plaintext is stored in the TYPO3 session and compared to the user input when the form is submitted.

Integration with forms runs through a validator for the TYPO3 form framework and through the Powermail API, where the field is embedded as an additional element in the form definition. Audio CAPTCHAs as an accessibility alternative are available in the extension but disabled by default and should be enabled for forms with a broad audience, so that users with visual impairments are not excluded. sr_freecap is configured through TypoScript, which controls the length of the CAPTCHA string, the fonts in use and the noise level.

## Common problems and solutions

The first problem is readability versus security. If the CAPTCHA is distorted too heavily, even human users fail and abandon the form, which noticeably drags down the conversion rate. If it is distorted too lightly, modern OCR engines read the plaintext in seconds. The practical solution is moderate distortion combined with a honeypot field, an invisible input that sits inside the form. Humans do not fill it in, bots often do, and these submissions are silently discarded.

The second problem concerns accessibility. A purely visual CAPTCHA excludes blind and visually impaired users, which at public institutions can constitute a violation of accessibility law and corresponding technical standards. Enabling the audio mode and adding a simple arithmetic task as an alternative creates accessible paths to meet the requirement without giving up protection.

The third topic is session handling. sr_freecap stores the expected answer in the PHP session, which in load-balanced setups without session affinity or stateless TYPO3 installations leads to errors. The solution is either sticky sessions on the load balancer or a shared session backend such as Redis that all nodes use together.

A fourth problem is effectiveness against modern bot frameworks. Simple headless browsers such as Puppeteer cannot solve visual CAPTCHAs themselves but can forward the task to an external solving service that returns the correct answer within seconds. A pure image recognition CAPTCHA is not enough against such attacks, and combining it with behaviour-based checks such as mouse movement analysis or the honeypot mentioned earlier is the more effective defence.

## Migration and version compatibility

sr_freecap is one of the oldest CAPTCHA extensions for TYPO3 and has a turbulent version history: community forks exist for TYPO3 v11 and v12, while v13 compatibility varies from fork to fork. Anyone migrating to v12 or v13 today should check before the upgrade whether their extension branch is actively maintained and, if in doubt, move to a different CAPTCHA approach.

Alternatives to sr_freecap within the privacy-friendly spectrum include hCaptcha (a self-hosted variant is possible), Friendly Captcha from European development and honeypot fields combined with server-side rate limiting. Gosign advises on the choice depending on form volume, user group and regulatory requirement and, where needed, builds a hybrid solution that first filters bot traffic with a honeypot and only forwards suspicious submissions to the CAPTCHA step.

For institutions that cannot embed external services for regulatory reasons, a self-hosted solution such as sr_freecap often remains the only viable choice, and the maintenance overhead is manageable. What matters is keeping the CAPTCHA protection aligned with current spam patterns and evaluating the statistics of failed attempts, so that it becomes visible when an upgrade of the distortion or a combination with other protective measures becomes worthwhile.

--- Storytelling TYPO3 - Scrollytelling | Gosign ---
> Scrollytelling extension for TYPO3: parallax scrolling, animated content blocks, scroll-trigger animations. For immersive content experiences, annual reports.

## Jahresberichte und Produktpräsentationen brauchen mehr als Text und Bild

Statische Seiten mit langen Textblöcken funktionieren für Dokumentation und Blog-Artikel. Aber Jahresberichte, Produktlaunches und Unternehmensgeschichten brauchen ein Format, das den Besucher durch eine Erzählung führt. Scrollytelling, also Storytelling über Scroll-Interaktion, hat sich als das Format etabliert, das zwischen statischem Text und aufwändigem Video liegt. Die TYPO3 Storytelling-Extension bringt Parallax-Scrolling, animierte Inhaltsblöcke und Scroll-Trigger-Animationen direkt ins CMS, ohne dass ein externer Dienst oder eine Agentur pro Seite ein Unikat programmieren muss.

Der Vorteil gegenüber einer Custom-Entwicklung: Redakteure können Inhalte im TYPO3-Backend pflegen, Blöcke umsortieren und Animationen konfigurieren, ohne den Entwickler zu involvieren.

## Typical use cases include Jahresberichte, Produktlaunches und Kampagnen-Landingpages

Das prominenteste Szenario sind digitale Jahresberichte. Unternehmen, Stiftungen und NGOs veröffentlichen ihre Geschäftszahlen zunehmend als interaktive Web-Story statt als PDF. Ein Scrollytelling-Jahresbericht zeigt im ersten Abschnitt die Headline-Zahl (Umsatz, Spendenvolumen, Mitgliederzahl), die beim Scrollen animiert hochzählt. Im zweiten Abschnitt erscheinen Diagramme mit Vergleichszahlen zum Vorjahr. Im dritten Abschnitt erzählen Porträtfotos und Zitate die Geschichte hinter den Zahlen. Die gesamte Story ist eine einzige Seite, die der Besucher durchscrollt.

Ein zweites Szenario sind Produktpräsentationen im B2B-Bereich. Ein Maschinenbauer stellt eine neue Fertigungsanlage vor. Beim Scrollen dreht sich das 3D-Rendering der Maschine, technische Daten blenden sich ein, Animationen zeigen den Produktionsprozess. Das ist kein Video (kein Laden, kein Buffering), sondern eine Scroll-gesteuerte Animation, die der Besucher in seinem eigenen Tempo durchgeht.

Drittes Szenario: Kampagnen-Landingpages. Eine Hilfsorganisation zeigt den Weg einer Spende: vom Klick auf den Spendenbutton über die Projektauswahl bis zum Bericht aus dem Zielland. Jeder Scroll-Abschnitt enthält ein Foto, einen kurzen Text und eine Animation, die den Fortschritt visualisiert.

## Technical architecture renders Sektionen als Scroll-gesteuerte Content-Blöcke

Die Extension definiert einen eigenen Content-Element-Typ "Storytelling", der aus Sektionen besteht. Jede Sektion ist ein Backend-Record mit Feldern für Headline, Text, Bild/Video (FAL), Hintergrundfarbe, Animationstyp und Scroll-Trigger. Die Sektionen werden im Backend sortiert und bilden zusammen die Scroll-Story.

Im Frontend rendert jede Sektion einen eigenen Viewport-füllenden Abschnitt. Animationen werden über CSS-Transitions und den IntersectionObserver ausgelöst: Wenn eine Sektion in den sichtbaren Bereich scrollt, startet die konfigurierte Animation (Fade-In, Slide-Left, Zoom, Counter). Parallax-Effekte verschieben Hintergrundbilder langsamer als den Vordergrund, was Tiefenwirkung erzeugt.

Die Extension liefert ein Set von vordefinierten Animationen mit. Custom Animationen lassen sich über CSS-Klassen ergänzen, die im Backend als Animationstyp auswählbar sind. Die JavaScript-Basis ist minimal: kein Framework, nur native IntersectionObserver und requestAnimationFrame. Das hält die Bundle-Grösse unter 20 KB.

Für die Performance ist entscheidend, dass Bilder lazy geladen werden. Ein Scrollytelling-Bericht mit 15 Sektionen und je einem hochauflösenden Bild erzeugt ohne Lazy Loading 30 bis 50 MB an Requests. Mit Lazy Loading lädt der Browser nur die sichtbare und die nächste Sektion.

## Common problems involve mobile Performance und die Barrierefreiheit

Das grösste Problem bei Scrollytelling auf Mobilgeräten ist die Performance. Parallax-Effekte, die auf Desktop flüssig laufen, ruckeln auf älteren Smartphones. Der Grund: Mobile Browser rendern Scroll-Events anders als Desktop-Browser und drosseln requestAnimationFrame im Hintergrund. Die Lösung: Parallax auf mobilen Viewports deaktivieren und durch einfache Fade-In-Animationen ersetzen. Die Extension sollte über TypoScript konfigurierbar sein, welche Animationen auf welchen Breakpoints aktiv sind.

Zweites Problem: Barrierefreiheit (WCAG 2.1). Scroll-gesteuerte Animationen sind für Nutzer mit vestibulären Störungen (Schwindel, Übelkeit bei Bewegung) problematisch. CSS prefers-reduced-motion muss respektiert werden. Die Extension sollte bei aktivierter Reduce-Motion-Einstellung alle Animationen deaktivieren und die Inhalte als statische Blöcke anzeigen. Nicht alle Storytelling-Extensions implementieren das korrekt.

Drittes Thema: SEO. Google kann JavaScript-basierte Animationen crawlen, aber der Inhalt muss auch ohne JavaScript zugänglich sein. Die Sektionen müssen als reguläre HTML-Blöcke gerendert werden, nicht als leere Container, die erst per JavaScript befüllt werden. Die Extension sollte Progressive Enhancement verfolgen: Erst der Inhalt, dann die Animation.

## TYPO3 v12 wird unterstützt, v13 requires ein Update der Content-Element-Registrierung

Scrollytelling-Extensions für TYPO3 gibt es in verschiedenen Varianten von verschiedenen Anbietern. Die Kompatibilität mit v12 ist bei aktiv gepflegten Extensions gegeben. Für v13 ist ein Update der Content-Element-Registrierung (NewContentElementWizard) und der TCA-Konfiguration nötig, weil v13 die FlexForm-basierte Content-Element-Konfiguration angepasst hat. Gosign setzt bei neuen Scrollytelling-Projekten auf eine Architektur, die die Animationslogik als eigenständiges JavaScript-Modul von der TYPO3-Integration trennt, um bei zukünftigen Upgrades nur die TYPO3-Schicht anpassen zu müssen.

--- Timetable TYPO3 - Schools | Gosign ---
> Tabular timetable display for schools and educational institutions. Day/week view, filter by subject/teacher/class. Responsive, printable.

## Schulen publizieren Stundenpläne als PDF, obwohl eine digitale Lösung allen Beteiligten Zeit spart

Die meisten Schulen in Deutschland erstellen ihren Stundenplan mit Software wie Untis, exportieren ihn als PDF und laden ihn auf die Website. Eltern, Schüler und Lehrkräfte scrollen durch eine unleserliche Tabelle, die auf dem Smartphone nicht skaliert. Änderungen (Vertretung, Raumtausch, Ausfall) erfordern einen neuen PDF-Upload. Die TYPO3 Stundenplan-Extension ersetzt diesen Workflow durch eine digitale Darstellung direkt auf der Website: Tages- und Wochenansicht, Filter nach Fach, Lehrer und Klasse, responsive Darstellung auf allen Geräten, druckbare Ansicht für das Lehrerzimmer.

Für Schulträger, die ihre Schulwebsites zentral auf TYPO3 betreiben, ist das eine skalierbare Lösung für zehn, zwanzig oder fünfzig Schulen gleichzeitig.

## Typical use cases range from der einzelnen Grundschule bis zum Schulverbund

Das Basisszenario ist die einzelne Schule mit 20 Klassen, 40 Lehrkräften und einem Stundenplan, der sich wöchentlich ändert. Die Verwaltung pflegt den Stundenplan im TYPO3-Backend oder importiert ihn aus Untis. Auf der Website sehen Eltern die Wochenansicht der Klasse ihres Kindes. Der Filter reduziert die Ansicht auf eine Klasse, ein Fach oder eine Lehrkraft. Vertretungen werden als farblich markierte Änderungen angezeigt, sodass Eltern morgens auf einen Blick sehen, ob der Unterricht regulär stattfindet.

Ein zweites Szenario sind Schulverbünde und Schulträger mit zentraler TYPO3-Installation. Eine Stadt betreibt 15 Schulwebsites auf einer Multi-Site-TYPO3-Instanz. Jede Schule hat eigene Stundenpläne, aber die Darstellung ist einheitlich. Die Extension wird einmal konfiguriert und per TypoScript-Vererbung auf alle Schulseiten ausgerollt. Neue Schulen werden mit derselben Konfiguration aufgesetzt.

Drittes Szenario: Volkshochschulen und Weiterbildungseinrichtungen. Eine VHS bietet 200 Kurse pro Semester an. Der Stundenplan zeigt, welcher Kurs an welchem Wochentag in welchem Raum stattfindet. Teilnehmer filtern nach Kursbereich (Sprachen, IT, Gesundheit) und sehen ihre persönliche Wochenansicht. In Kombination mit einem Login können registrierte Teilnehmer nur ihre gebuchten Kurse sehen.

## Technical architecture stores Stundenplandaten als strukturierte Records

Die Extension definiert mehrere Tabellen: Klassen, Lehrkräfte, Fächer, Räume und Stunden. Jede Stunde ist ein Record mit Verknüpfungen zu Klasse, Lehrkraft, Fach, Raum, Wochentag und Zeitfenster. Die Daten werden entweder manuell im Backend gepflegt oder über einen CSV/XML-Import aus Stundenplan-Software importiert.

Das Frontend-Plugin rendert die Daten als HTML-Tabelle mit der Wochentag-Zeitfenster-Matrix. Filter (Klasse, Lehrkraft, Fach) werden per GET-Parameter übergeben und serverseitig verarbeitet. Die Tabelle ist per CSS responsive: Auf Desktop zeigt sie die volle Wochenansicht, auf Mobilgeräten wird auf eine Tagesansicht umgeschaltet oder horizontal scrollbar gemacht.

Die Druckansicht erzeugt eine optimierte Darstellung ohne Navigation und Footer, mit Seitenumbrüchen zwischen den Wochentagen. Per Print-CSS wird die Tabelle auf A4-Querformat optimiert.

Für den Import aus Untis existieren Community-Lösungen, die den Untis-XML-Export parsen und in die TYPO3-Datenbankstruktur schreiben. Der Import kann als Scheduler-Task konfiguriert werden, sodass Änderungen in Untis automatisch auf der Website erscheinen.

## Common problems involve die Datenpflege und die mobile Darstellung

Das grösste Problem ist die laufende Datenpflege. Stundenpläne ändern sich wöchentlich, Vertretungen täglich. Wenn die Daten manuell im TYPO3-Backend gepflegt werden, ist der Aufwand bei 20 Klassen mit je 30 Wochenstunden erheblich. Die Lösung: Einen automatisierten Import aus der Stundenplan-Software einrichten. Ohne diesen Import ist die Extension nur für kleine Einrichtungen mit wenigen Klassen praktikabel.

Zweites Problem: Die mobile Darstellung. Eine Stundenplan-Tabelle mit fünf Spalten (Mo-Fr) und zehn Zeilen (Stunden) passt nicht auf einen 375 Pixel breiten Smartphone-Bildschirm. Horizontales Scrollen ist die pragmatische Lösung, aber Eltern finden es unintuativ. Besser: Auf mobilen Viewports automatisch auf die Tagesansicht umschalten (nur der aktuelle Tag), mit Wisch-Gesten für den Tageswechsel.

Drittes Thema: Datenschutz. Wenn Lehrkräfte namentlich im öffentlichen Stundenplan erscheinen, kann das datenschutzrechtlich problematisch sein. Manche Schulen zeigen deshalb nur Fach und Klasse, nicht den Lehrernamen. Die Extension sollte per Konfiguration steuern, welche Felder im Frontend angezeigt werden.

## Die Extension ist eine Nischenlösung ohne aktive Community-Pflege

Stundenplan-Extensions für TYPO3 sind Nischenprodukte mit kleiner Community. TYPO3 v12-Kompatibilität ist bei neueren Versionen gegeben, aber eine aktive Weiterentwicklung für v13 ist nicht garantiert. Schulen und Schulträger, die langfristig planen, sollten evaluieren, ob eine Custom-Entwicklung auf Basis von Standard-TYPO3-Content-Elementen (Extbase-Records + Fluid-Templates) nicht nachhaltiger ist als eine Community-Extension mit ungewissem Wartungshorizont. Gosign berät Bildungseinrichtungen und Schulträger bei der Wahl zwischen Community-Extension, Custom-Entwicklung und dedizierten Stundenplan-SaaS-Lösungen mit TYPO3-Anbindung.

--- Styleguide TYPO3 - QA Extension | Gosign ---
> TYPO3 Core extension that visualizes all content elements on a single page. Quality assurance for template development: test every CE in every variant.

## Why Styleguide is the most important QA extension for TYPO3 template developers

Template development in TYPO3 has a systematic quality problem: developers test their Fluid templates with the data that currently exists on the website. But content elements have dozens of variants - headlines with and without subheadline, text blocks with 3 words or 3 paragraphs, images in portrait and landscape, tables with 2 or 20 columns. Anyone checking only the current page misses the edge cases that surface only after launch.

The Styleguide extension solves this problem by automatically rendering all content elements of the TYPO3 system in every available configuration on a single page. The developer immediately sees whether their CSS and templates correctly handle all variants.

## Typical use cases

**Template development during relaunch projects.** A company commissions a TYPO3 relaunch with a new corporate design. The frontend developer creates Fluid templates for all content elements. Without Styleguide, test data must be created manually in the backend for each element - a process that takes hours with 30+ content elements. Styleguide generates all test data automatically: text elements in various lengths, images in different aspect ratios, lists, tables, uploads, forms. The developer opens a URL and sees everything at a glance.

**Regression tests after TYPO3 updates.** A TYPO3 update from v11 to v12 subtly changes the rendering of individual content elements. A textmedia element suddenly renders an additional wrapper div that breaks the CSS layout. Without Styleguide, this is only noticed when an editor reports the error on a live page. With Styleguide, the developer sees immediately after the update which elements have changed.

**Alignment between design and development teams.** Designers deliver Figma mockups for 10 content elements. But how do the remaining 25 standard elements look in the new design? Styleguide makes this gap visible: all elements are displayed on a single page, missing designs are immediately apparent. Gosign uses Styleguide in every relaunch project as the sign-off tool for the design team.

## Technical architecture

Styleguide is an official TYPO3 Core system extension that ships with the TYPO3 source code. It only needs to be activated in the Extension Manager - no separate installation is required.

The extension operates on two levels:

- **TCA Generator**: Styleguide analyzes the Table Configuration Array (TCA) definitions of all registered content elements and generates test records from them. For each field, a meaningful test value is produced - texts in various lengths, images from FAL, relations to other records.
- **Backend Module**: through the backend module, the administrator can generate, update and delete the test data. The data is stored in a dedicated SysFolder and does not affect regular content.
- **Frontend Rendering**: a special page in the page tree displays all generated content elements in the frontend layout. The developer sees the elements exactly as they would appear on the live website.

Styleguide has no external dependencies. As a Core extension, it is automatically updated with every TYPO3 update and is always compatible with the respective TYPO3 version.

Important: Styleguide does not generate test data for custom content elements (e.g. Mask or DCE). It covers only the Core content elements. For custom elements, the developer must create their own test data or use a supplementary tool.

## Common problems and solutions

**Styleguide page shows empty areas.** Test data was generated, but the frontend page does not display all elements. Cause: the SysFolder with the test data is not correctly configured as the starting point, or the TypoScript setup for the Styleguide page is missing. Solution: check in the backend module whether the page tree was correctly created and ensure the root template of the Styleguide page uses the same TypoScript as the regular website.

**Images missing from generated test data.** Styleguide tries to include test images through FAL (File Abstraction Layer). If the fileadmin folder is empty or the default storage configuration is incorrect, image fields remain empty. Solution: manually upload at least one image to fileadmin before generating test data.

**Performance issues with the Styleguide page.** When all content elements are rendered on a single page, loading time with complex templates can reach 10 to 15 seconds. This is acceptable for QA but can strain the server under concurrent access. Solution: activate Styleguide only on the development or staging environment, never on the live system.

## Migration and version compatibility

Styleguide has been available as a Core system extension since TYPO3 v8 and is automatically updated with every TYPO3 version. There are no separate version numbers or compatibility issues because the extension is part of the Core release process.

During a TYPO3 upgrade, Styleguide test data should be regenerated after the update. Old test data may be inconsistent on the new system because TCA definitions change between TYPO3 versions. The backend module provides a "Reset" function that deletes all test data and recreates it.

For TYPO3 v12 and v13, Styleguide is available without restrictions. The extension even benefits from new Core features: in v12, additional content elements (e.g. improved textmedia variants) were introduced that Styleguide automatically covers.

Gosign integrates Styleguide into every TYPO3 relaunch as a fixed part of the QA process. The Styleguide page is set up on the staging environment as a permanent reference and serves the design team as a sign-off URL. Changes to Fluid templates or CSS are immediately visible there without anyone needing to create test content on individual pages. For enterprise clients with multiple brands or tenants, a separate Styleguide page is generated per tenant to compare brand-specific template variants.

--- t3skin TYPO3 - Backend Styling | Gosign ---
> Legacy backend skin for older TYPO3 versions. No longer relevant from TYPO3 v7+. Modern TYPO3 versions have their own backend styling. Gosign migrates.

## t3skin ist seit TYPO3 v7 obsolet, aber viele Installationen laufen noch auf Versionen, die es brauchen

t3skin war das Backend-Styling-Paket für TYPO3 v4 und v6. Es definierte Icons, Farben, Abstände und das gesamte Look-and-Feel des TYPO3-Backends. Ab TYPO3 v7 wurde das Backend-Styling in den Core integriert, t3skin als separate Extension wurde überflüssig. Trotzdem taucht t3skin in Bestandsanalysen regelmässig auf, weil es in alten Installationen installiert ist und beim Upgrade auf aktuelle TYPO3-Versionen Fehler verursacht. Wer t3skin in seiner Extension-Liste findet, hat ein klares Signal: Diese Installation ist entweder veraltet oder wurde bei einem früheren Upgrade nicht vollständig aufgeräumt.

## Typical use cases involve ausschliesslich Legacy-Installationen

Das einzige legitime Szenario für t3skin ist eine TYPO3-Installation auf Version 4.5 bis 6.2, die aus technischen oder organisatorischen Gründen nicht aktualisiert werden kann. In solchen Installationen liefert t3skin das Backend-Design. Ohne t3skin wäre das Backend visuell unbrauchbar: fehlende Icons, kaputte Layouts, unlesbare Formulare.

Ein zweites Szenario ist die Übergangsphase während einer Migration. Wenn eine Agentur eine TYPO3-v6-Installation auf v12 migriert, existiert t3skin während des Upgrade-Prozesses noch in der Extension-Liste, wird aber nach dem Upgrade deaktiviert und entfernt. In dieser Phase kann t3skin Konflikte mit dem neuen Backend-Styling verursachen, wenn es nicht rechtzeitig deinstalliert wird.

Ein drittes (Anti-)Szenario: Manche Administratoren haben t3skin in TYPO3 v7 oder v8 manuell installiert, weil sie das alte Backend-Design bevorzugten. Das funktionierte kurzfristig, erzeugte aber Darstellungsfehler, weil t3skin-CSS und Core-CSS sich widersprachen. Spätestens ab TYPO3 v9 ist das keine Option mehr.

## Technical architecture war ein CSS/Icon-Paket ohne Geschäftslogik

t3skin war keine Extension im klassischen Sinne (kein Controller, kein Model, kein Repository). Es bestand aus CSS-Dateien, Icon-Sprites, ein paar JavaScript-Snippets für die Backend-Oberfläche und einer ext_emconf.php, die es als System-Extension registrierte. Die gesamte Logik war visuell: Farben, Schriften, Abstände, Icons. Der TYPO3-Core renderte die Backend-Module, t3skin bestimmte nur, wie sie aussahen.

Ab TYPO3 v7 übernahm der Core diese Aufgabe selbst. Das Backend-Styling wurde in das System-Extension-Paket backend integriert. Icons wurden auf ein SVG-basiertes Icon-System umgestellt (IconFactory), CSS wurde auf Less und später auf SCSS migriert. t3skin konnte diese Änderungen nicht abbilden, weil es auf dem alten Sprite-basierten Icon-System basierte.

## Common problems entstehen, wenn t3skin bei einem Upgrade nicht entfernt wird

Das häufigste Problem ist ein weisses oder kaputtes Backend nach einem TYPO3-Upgrade. Wenn t3skin in einer v12-Installation noch installiert ist, überschreibt es Core-CSS-Dateien mit veralteten Regeln. Das Ergebnis: Buttons ohne Hintergrund, Icons die nicht laden, Modul-Navigationen die nicht klickbar sind. Die Lösung: t3skin über den Extension Manager deinstallieren und die Tabellen-Einträge in sys_registry bereinigen. Wenn das Backend so kaput ist, dass der Extension Manager nicht erreichbar ist, hilft die Deaktivierung über die Kommandozeile: typo3/sysext/core/bin/typo3 extension:deactivate t3skin.

Zweites Problem: Verwaiste CSS-Dateien. Auch nach der Deinstallation von t3skin können CSS-Dateien in fileadmin/ oder typo3temp/ zurückbleiben, die der Browser cached. Ein vollständiger Cache-Clear (Browser-Cache, TYPO3-Cache, CDN-Cache) ist nach der Entfernung nötig.

Drittes Thema: Backend-Anpassungen, die auf t3skin aufbauen. Manche Agenturen haben in TYPO3 v6 Custom Backend CSS geschrieben, das t3skin-Klassen als Basis nutzt. Nach der Entfernung von t3skin brechen diese Anpassungen. Die Lösung: Custom Backend CSS auf die aktuellen Core-CSS-Klassen migrieren.

## t3skin hat keinen Upgrade-Pfad, die Migration bedeutet Entfernung

Es gibt kein Update von t3skin auf eine aktuelle Version, weil die Extension keinen Nachfolger hat. Der Nachfolger ist der TYPO3-Core selbst. Die Migration bedeutet: t3skin deinstallieren, alle Referenzen auf t3skin-CSS-Klassen in Custom Backend Modulen entfernen, und die IconFactory für Custom Icons nutzen. Gosign führt diese Bereinigung im Rahmen jeder TYPO3-Migration durch und prüft dabei, ob weitere Legacy-Extensions (css_styled_content, rtehtmlarea, adodb) in der Installation verblieben sind, die ebenfalls entfernt werden müssen.

--- Copyright Images TYPO3 | Gosign ---
> Automatically add copyright notices to images. Read IPTC/EXIF metadata, display as overlay or footer. Legally compliant handling of image rights.

## Fehlende Bild-Copyrights kosten Unternehmen jedes Jahr Tausende Euro in Abmahnungen

Stockfoto-Agenturen wie Getty Images, Adobe Stock und Mauritius setzen systematisch Webcrawler ein, die das Internet nach unlizenziert oder falsch attributierten Bildern durchsuchen. Fehlende Copyright-Hinweise sind der häufigste Grund für Abmahnungen. Je nach Agentur und Bild liegen die Forderungen zwischen 500 und 5.000 Euro pro Bild. Bei einer Website mit 200 Stockfotos kann ein einziger Audit-Durchlauf der Agentur fünfstellige Nachforderungen erzeugen. tgm_copyright automatisiert die Copyright-Kennzeichnung in TYPO3: Die Extension liest IPTC- und EXIF-Metadaten aus Bilddateien aus und zeigt den Copyright-Hinweis automatisch als Overlay oder Fusszeile an. Jedes Bild, das über FAL (File Abstraction Layer) verwaltet wird, bekommt seinen Rechtehinweis, ohne dass Redakteure manuell eingreifen müssen.

## Typical use cases umfassen Unternehmenswebsites, Verlage und öffentliche Einrichtungen

Das häufigste Szenario ist die Unternehmenswebsite mit 100 bis 500 Bildern aus verschiedenen Quellen: eigene Fotos, Stockbilder von Adobe Stock, Pressefotos von Kunden, Illustrationen von Freelancern. Jedes Bild hat andere Lizenzanforderungen. Manche verlangen eine Namensnennung ("Foto: Max Mustermann"), andere eine Quellenangabe ("Quelle: Adobe Stock"), wieder andere nur ein Copyright-Zeichen. tgm_copyright liest die Informationen aus den IPTC-Feldern (Creator, Copyright Notice, Source) und zeigt sie im konfigurierten Format an.

Ein zweites Szenario sind Verlage und Medienhäuser. Eine Regionalzeitung publiziert täglich 30 bis 50 Bilder. Die Fotografen liefern ihre Bilder mit eingebetteten IPTC-Daten. Die Extension zeigt automatisch "Foto: [Fotografenname]" unter jedem Bild an. Das spart der Redaktion fünf bis zehn Minuten pro Artikel, weil der Copyright-Hinweis nicht manuell eingetippt werden muss.

Drittes Szenario: Öffentliche Einrichtungen, die Creative-Commons-Bilder nutzen. CC-Lizenzen erfordern eine korrekte Attribution (Urheber, Lizenztyp, Link zur Lizenz). tgm_copyright kann diese Informationen aus den Metadaten lesen und als formatierte Fusszeile mit Lizenz-Link ausgeben.

## Technical architecture uses die FAL-Metadaten und ein Fluid-ViewHelper-System

tgm_copyright registriert sich als TYPO3-Extension und greift auf die sys_file_metadata-Tabelle zu. Wenn ein Bild über FAL in TYPO3 hochgeladen wird, extrahiert die Extension automatisch die IPTC- und EXIF-Felder und schreibt sie in die Metadaten-Felder der FAL-Tabelle. Die relevanten IPTC-Felder sind: Creator (Fotograf), Copyright Notice (Rechteinhaber), Source (Quelle), Description (Bildunterschrift) und Credit (Agentur).

Im Frontend stellt die Extension einen Fluid-ViewHelper bereit, der den Copyright-Hinweis zu jedem Bild rendert. Der ViewHelper kann als Overlay (halbtransparente Leiste am unteren Bildrand), als Fusszeile (Text unter dem Bild) oder als Tooltip (Hover-Effekt) konfiguriert werden. Das Styling ist über CSS-Klassen steuerbar, sodass der Copyright-Hinweis zum Design der Website passt.

Für Bilder ohne eingebettete Metadaten bietet die Extension ein Fallback: Redakteure können im FAL-Metadaten-Dialog den Copyright-Hinweis manuell eintragen. Die Extension priorisiert manuelle Einträge über automatisch ausgelesene Metadaten, sodass fehlerhafte IPTC-Daten überschrieben werden können.

## Common problems involve fehlende Metadaten und Overlay-Platzierung

Das dominierende Problem sind Bilder ohne eingebettete IPTC-Daten. Viele Stockfoto-Downloads werden vor dem Upload in Photoshop bearbeitet, wobei die Metadaten verloren gehen. Wenn kein IPTC-Creator-Feld vorhanden ist, kann die Extension keinen Copyright-Hinweis generieren. Die Lösung: Einen Workflow etablieren, bei dem Bilder vor dem Upload auf vorhandene Metadaten geprüft werden. Alternativ: Ein TYPO3-Backend-Modul, das alle Bilder ohne Copyright-Eintrag auflistet und zur manuellen Nachpflege auffordert.

Zweites Problem: Das Overlay verdeckt wichtige Bildinhalte. Bei Porträtfotos kann ein Copyright-Overlay am unteren Bildrand das Gesicht oder den Produktnamen verdecken. Die Lösung: Per Bild konfigurierbar machen, ob das Copyright als Overlay oder als Fusszeile angezeigt wird. Standardmässig ist die Fusszeile die sichere Wahl.

Drittes Thema: Performance bei grossen Bildbeständen. Wenn die Extension bei jedem Bild-Request die IPTC-Daten aus der Datei liest statt aus der Datenbank, wird das bei Seiten mit 20 Bildern spürbar. Die Lösung: IPTC-Daten einmalig beim Upload auslesen und in der Datenbank cachen, nicht bei jedem Frontend-Request.

## TYPO3 v12 wird unterstützt, v13 requires ein Update der ViewHelper-Registrierung

tgm_copyright nutzt die FAL-API, die im TYPO3-Core stabil ist. Die Extension läuft unter v12 ohne Probleme. Für v13 sind Anpassungen an der ViewHelper-Namespace-Registrierung und den TCA-Konfigurationen nötig, weil v13 die Namespace-Konventionen für ViewHelper geändert hat. Gosign empfiehlt, bei jedem TYPO3-Upgrade einen Bild-Audit durchzuführen: Alle Bilder der Website prüfen, ob Copyright-Hinweise korrekt angezeigt werden, und fehlende Zuordnungen nachpflegen.

--- Ticketshop TYPO3 - Online Tickets | Gosign ---
> Online ticket sales for events: seat selection, quotas, payment, e-ticket generation, QR code validation. Custom development for concerts, theaters.

## Veranstalter zahlen 5 bis 15 Prozent Provision an externe Ticketplattformen, obwohl die eigene Website der bessere Vertriebskanal wäre

Eventim, Ticketmaster und Eventbrite nehmen Gebühren pro Ticket: zwischen 5 und 15 Prozent des Ticketpreises plus Festbetrag. Bei einem Theater mit 50.000 verkauften Tickets pro Jahr und einem Durchschnittspreis von 30 Euro sind das 75.000 bis 225.000 Euro Provision jährlich. Ein Ticketshop direkt auf der TYPO3-Website eliminiert diese Provision. Die Extension ermöglicht Online-Ticketverkauf mit Sitzplatzwahl, Kontingent-Verwaltung, Bezahlung über gängige Payment-Provider, E-Ticket-Generierung als PDF und QR-Code-Validierung am Einlass. Für Theater, Konzerthäuser, Konferenzen und kommunale Veranstaltungshäuser, die ihre Tickets überwiegend an ein bekanntes Stammpublikum verkaufen, ist das eine wirtschaftlich attraktive Alternative.

## Typical use cases reichen vom Stadttheater bis zur Fachkonferenz

Das prominenteste Szenario ist das Theater oder Konzerthaus mit festem Saalplan. 400 nummerierte Sitzplätze, davon 50 in der Kategorie Premium, 200 im Parkett und 150 auf dem Balkon. Der Besucher wählt im interaktiven Saalplan seinen Platz, sieht den Preis und legt das Ticket in den Warenkorb. Nach der Bezahlung erhält er ein E-Ticket als PDF mit QR-Code per E-Mail. Am Abend der Vorstellung scannt das Personal den QR-Code mit einem Smartphone. Der gesamte Prozess läuft über die TYPO3-Website, ohne Drittanbieter.

Ein zweites Szenario sind Konferenzen und Messen. Eine Fachkonferenz bietet drei Ticketkategorien: Early Bird (bis 8 Wochen vor der Veranstaltung), Regular und VIP. Kontingente begrenzen jede Kategorie auf eine feste Anzahl. Der Ticketshop zeigt die Verfügbarkeit in Echtzeit: "Early Bird: 12 von 100 verfügbar". Nach Ablauf des Early-Bird-Zeitraums wird die Kategorie automatisch deaktiviert.

Drittes Szenario: Kommunale Veranstaltungen. Eine Stadtbibliothek bietet Lesungen, Workshops und Kinderveranstaltungen an. Die Tickets sind gratis, aber die Plätze begrenzt. Der Ticketshop dient hier als Reservierungssystem. Besucher reservieren online, erhalten eine Bestätigung und werden bei Überbuchung auf eine Warteliste gesetzt.

## Technical architecture connects Veranstaltungs-Records, Saalplan und Payment-Gateway

Der Ticketshop besteht aus vier Komponenten: Veranstaltungsverwaltung, Sitzplan-Editor, Checkout mit Payment-Integration und Ticket-Generierung. Veranstaltungen werden als Extbase-Records im TYPO3-Backend angelegt: Titel, Datum, Uhrzeit, Ort, Kategorien, Preise, Kontingente. Der Sitzplan wird als interaktive SVG-Grafik hinterlegt, in der jeder Platz eine eindeutige ID hat, die mit dem Kontingent-System verknüpft ist.

Der Checkout-Prozess sammelt die ausgewählten Tickets, fragt Kontaktdaten ab und leitet an ein Payment-Gateway weiter. Gängige Integrationen sind Stripe, PayPal, Mollie und SIX Payment Services. Nach erfolgreicher Zahlung erzeugt die Extension ein PDF-Ticket mit QR-Code (basierend auf einer eindeutigen Ticket-ID) und versendet es per E-Mail. Der QR-Code enthält eine URL oder einen Hashwert, der am Einlass validiert wird.

Die QR-Code-Validierung am Einlass kann über eine einfache Web-App laufen, die die Ticket-ID gegen die TYPO3-Datenbank prüft und den Status auf "eingelöst" setzt. Ein Ticket kann nur einmal eingelöst werden, Duplikate werden abgewiesen.

## Common problems involve Bezahlung, Stornierung und den Saalplan-Editor

Das grösste Problem ist die Zahlungsabwicklung. PCI-DSS-Konformität verlangt, dass Kreditkartendaten niemals den eigenen Server berühren. Deshalb muss die Zahlung über einen zertifizierten Payment Provider laufen, der ein Hosted Payment Form bereitstellt. Die Extension leitet den Nutzer zur Bezahlung an den Provider weiter und empfängt das Ergebnis per Callback. Wenn der Callback fehlschlägt (Timeout, Server-Restart), ist das Ticket bezahlt, aber nicht als bezahlt markiert. Die Lösung: Ein Reconciliation-Job, der offene Transaktionen beim Payment Provider nachprüft.

Zweites Problem: Stornierungen und Erstattungen. Wenn ein Besucher ein Ticket storniert, muss die Zahlung erstattet und der Platz wieder freigegeben werden. Das erfordert sowohl eine Refund-Anfrage an den Payment Provider als auch eine Statusänderung in der TYPO3-Datenbank. Ohne automatisierten Storno-Workflow ist das ein manueller Prozess.

Drittes Thema: Der Saalplan-Editor. Interaktive SVG-Saalpläne mit 400 oder mehr Plätzen sind aufwändig zu erstellen. Jeder Platz braucht eine ID, eine Kategorie und Koordinaten. Änderungen am Saalplan (neuer Block, geänderte Reihenfolge) erfordern eine Aktualisierung der SVG-Datei und der Verknüpfungen in der Datenbank.

## Ticketshop-Extensions include Custom-Entwicklungen ohne TER-Standard

Es gibt keine Standard-Ticketshop-Extension im TYPO3 TER, die alle beschriebenen Funktionen abdeckt. Ticketshops sind fast immer Custom-Entwicklungen, die auf die spezifischen Anforderungen der Veranstaltungsstätte zugeschnitten sind. Die TYPO3-Kompatibilität hängt deshalb vom Auftragnehmer ab, nicht von einem Community-Release-Zyklus. Gosign empfiehlt bei neuen Ticketshop-Projekten zu evaluieren, ob eine headless TYPO3-Architektur mit einem spezialisierten Frontend (React, Vue) nicht langfristig wartbarer ist als eine monolithische Extbase-Lösung.

--- Tournament TYPO3 - Tournaments | Gosign ---
> Tournament/competition management for TYPO3: groups, matchups, results, tables. Sports clubs, esports, internal company competitions.

## Sportvereine verwalten Turniere in Excel, obwohl ihre Website der logische Ort für Ergebnisse und Tabellen wäre

Jedes Wochenende finden in Deutschland Tausende Vereinsturniere statt. Die Ergebnisse werden in Excel-Tabellen eingetippt, als PDF auf die Website geladen oder im besten Fall per Hand in eine HTML-Tabelle geschrieben. Besucher der Vereinswebsite sehen veraltete Daten, weil niemand die Seite aktualisiert. Die TYPO3 Tournament-Extension ersetzt diesen Workflow: Gruppen, Spielpaarungen, Ergebnisse und Tabellen werden direkt im CMS verwaltet. Ergebnisse werden eingegeben, die Tabelle aktualisiert sich automatisch. Für Sportvereine, E-Sport-Organisationen und Firmen, die interne Wettbewerbe veranstalten, ist das eine professionelle Darstellung ohne Programmieraufwand.

## Typical use cases umfassen Fussballturniere, E-Sport-Ligen und Firmenwettbewerbe

Das häufigste Szenario ist das Fussballturnier eines Sportvereins. 16 Mannschaften treten in 4 Gruppen an. Jede Gruppe spielt eine Vorrunde (jeder gegen jeden), die besten zwei qualifizieren sich für die K.o.-Runde. Die Extension bildet diesen Modus vollständig ab: Gruppenphase mit Punkten, Tordifferenz und Direktvergleich, K.o.-Runde mit Viertelfinale, Halbfinale und Finale. Ergebnisse werden im Backend eingegeben, die Tabellen und der Turnierplan im Frontend aktualisieren sich automatisch.

Ein zweites Szenario sind E-Sport-Ligen. Ein Gaming-Verein organisiert eine Counter-Strike-Liga mit 12 Teams und einer Saison über 20 Spieltage. Die Extension verwaltet die Liga-Tabelle, den Spielplan und die Ergebnishistorie. Jedes Team hat eine Profilseite mit Kader, Statistiken und vergangenen Ergebnissen. Die Darstellung ist an das Vereins-CI angepasst, nicht an das Layout einer Drittplattform.

Drittes Szenario: Interne Firmenwettbewerbe. Ein Unternehmen mit fünf Standorten veranstaltet ein jährliches Schachturnier. Mitarbeitende melden sich über die Intranet-TYPO3-Seite an, die Extension lost die Paarungen aus und zeigt den Turnierfortschritt live. Das ist eine Nischenanwendung, aber für Unternehmen, die Engagement und Standort-übergreifenden Austausch fördern wollen, ein realer Use Case.

## Technical architecture modelliert Turniere als verschachtelte Record-Struktur

Die Extension definiert mehrere Extbase-Modelle: Tournament (Turnier), Team, Group, Match, Result. Ein Turnier enthält Gruppen, jede Gruppe enthält Teams. Matches werden entweder automatisch generiert (Jeder-gegen-Jeden) oder manuell definiert (K.o.-Runde). Ergebnisse werden als Result-Records mit Match-Verknüpfung gespeichert.

Die Tabellenberechnung erfolgt serverseitig: Punkte (3-1-0 oder konfigurierbar), Tordifferenz, erzielte Tore, Direktvergleich. Die Sortierlogik ist über TypoScript konfigurierbar, weil verschiedene Sportarten unterschiedliche Kriterien priorisieren (Fussball: Tordifferenz vor Toren; Handball: Torquotient).

Das Frontend rendert zwei Hauptansichten: die Gruppenphase als Tabelle (Teams, Punkte, Siege, Niederlagen, Tordifferenz) und den K.o.-Turnierbaum als verschachtelte Bracket-Darstellung. Die Bracket-Darstellung ist per CSS als Baumstruktur umgesetzt, die auf Desktop horizontal und auf Mobilgeräten vertikal läuft.

Für grössere Turniere mit Livestream-Integration lässt sich die Extension per AJAX erweitern: Ergebnisse werden im Backend eingetragen und das Frontend aktualisiert den Spielstand per Polling alle 30 Sekunden, ohne dass die Seite neu geladen wird.

## Common problems involve die Turniermodus-Logik und die Bracket-Darstellung

Das grösste Problem ist die Vielfalt der Turniermodi. Ein einfaches K.o.-Turnier mit 8 Teams ist trivial. Aber ein Swiss-System-Turnier mit 40 Teams, ein Doppel-K.o.-Format oder eine Liga mit Auf- und Abstiegsrunden erfordern komplexe Logik, die nicht jede Extension abbildet. Vor der Entscheidung für eine Extension muss der Turniermodus klar definiert sein. Wenn die Extension den gewünschten Modus nicht unterstützt, ist eine Custom-Erweiterung nötig.

Zweites Problem: Die Bracket-Darstellung auf mobilen Geräten. Ein K.o.-Turnierbaum mit 16 Teams hat vier Runden (Achtelfinale bis Finale). Diese Baumstruktur passt nicht auf einen 375 Pixel breiten Bildschirm. Horizontales Scrollen oder eine vereinfachte Listenansicht sind die pragmatischen Lösungen.

Drittes Thema: Teamfotos und Wappen. Vereine wollen Logos neben den Teamnamen in der Tabelle. Die Extension muss FAL-Integration für Team-Bilder bieten, sonst müssen Redakteure Bildpfade manuell eintippen.

## Tournament-Extensions include Nischenprodukte mit begrenzter Community

Turnier-Extensions für TYPO3 sind Nischenlösungen mit kleiner Community. Unter TYPO3 v12 laufen aktuelle Versionen stabil. Für v13 ist die Weiterentwicklung nicht garantiert, weil der Pflege-Aufwand für den Maintainer bei einer Nischen-Extension wirtschaftlich schwer zu rechtfertigen ist. Vereine, die langfristig planen, sollten evaluieren, ob eine spezialisierte Turnier-Plattform (Challengermode, Toornament) mit API-Anbindung an die TYPO3-Website nicht nachhaltiger ist als eine monolithische Extension. Gosign berät Vereine und Organisationen bei der Wahl zwischen Community-Extension, Custom-Entwicklung und SaaS-Integration.

--- tt_address TYPO3 - Address Management | Gosign ---
> The classic for address management in TYPO3. Manage and display contacts, employees, locations.

## Employee directories, branch finders and contact lists have run on tt_address in TYPO3 for 20 years

Every company with multiple locations, departments or contact persons needs a structured display on the website. Who is responsible for which region? Where is the nearest branch? What contact details does the HR department have? Maintaining such information manually as text blocks in the CMS leads to inconsistencies: different formats, forgotten updates, no filtering capability.

tt_address is the oldest and most widely used address management extension for TYPO3. In use since TYPO3 v4 (2006), over 50,000 active installations (TER, 2026), actively maintained by the TYPO3 community. The extension stores contacts, persons and locations as structured records and outputs them via Fluid templates as lists, maps or detail pages.

## Typical use cases

**Employee directories for corporate websites.** A company with 50 to 500 employees wants to show on the website who is responsible for which topic. tt_address stores per person: name, title, department, photo, email, phone, location. Output is rendered as a filterable list (by department, location) or as a detail page with vCard download. For companies with privacy concerns, visibility can be controlled per field.

**Branch finders and location overviews.** Companies with 10 to 500 locations (branches, offices, partners) use tt_address as the data foundation for a location finder. Each location has address, geocoordinates, opening hours and contact details. Map integration is handled through a separate extension (maps2 or Leaflet) that reads the geocoordinates from tt_address. Users search by postal code or city and see the nearest locations.

**Contact lists for government agencies and associations.** Municipalities, chambers and associations list contacts by responsibility: building authority, youth services, public order or chairman, treasurer, secretary. tt_address maps the organizational structure through categories or SysFolders. Output can be filtered by category and sorted alphabetically or by position.

## Technical architecture

tt_address stores records in the `tt_address` table. Fields include: salutation, title, first name, last name, company, department, street, postal code, city, country, phone, fax, mobile, email, website, geocoordinates (latitude, longitude), image (FAL reference), categories and a description field (RichText).

Output runs through an Extbase plugin with list and detail actions. Fluid templates are fully customizable. By default, tt_address provides four layouts: simple list, grouped list (by category or location), detail view and vCard download (RFC 6350). Custom templates can be configured via TypoScript without PHP changes.

tt_address integrates with other extensions: maps2 and ext:leaflet for map integration, direct_mail and mail for newsletter sending (tt_address as recipient list), ke_search and indexed_search for full-text search across address data. Geocoordinates can be automatically determined from the postal address through a geocoding service (Google Maps API, Nominatim).

Categories (sys_category) are the primary mechanism for structuring. An employee can be assigned to multiple categories (e.g. "Sales" and "Munich Office"). The frontend output filters by category, enabling the display of department lists, location teams or thematic contact groups.

## Common problems and solutions

**Images not displaying.** Since TYPO3 v10, tt_address uses FAL (File Abstraction Layer) for images. Older installations stored images as filenames in a field (not as FAL references). Solution: run the tt_address upgrade script that converts old image references to FAL references. For manual migration: place images in fileadmin/ and link them as sys_file_reference.

**Geocoordinates missing for the branch finder.** Addresses without latitude/longitude do not appear on the map. Manually entering coordinates for 200 locations is not practical. Solution: automate geocoding via scheduler task. tt_address itself does not offer geocoding, but Gosign deploys a cronjob that fills missing coordinates via the Nominatim API (OpenStreetMap, free, GDPR-compliant).

**Data import from external systems.** HR departments maintain employee data in SAP, Personio or another HR system. The data should appear automatically on the website. Solution: build a sync mechanism that imports CSV or JSON from the HR system and creates or updates tt_address records. Gosign implements this as a scheduler task with mapping configuration (which source field maps to which tt_address field).

## Migration and version compatibility

tt_address actively supports TYPO3 v11, v12 and v13. The extension is co-maintained by Georg Ringer (the developer of the News extension) and follows a clear release cycle. Updates for new TYPO3 major versions typically appear within weeks of the LTS release.

For projects switching from a custom address management solution to tt_address, data migration is straightforward: import existing data via SQL or CSV into the tt_address table, create FAL references for images, assign categories. The effort for 200 records is half a day to one day, including template customization.

Those upgrading from an older TYPO3 (v8, v9) with tt_address v4 or v5 should include the extension upgrade in one step. The field structure changed slightly between major versions (v5 to v6: switch to FAL images, v7: new fields), but tt_address provides upgrade wizards that automate the transition.

For companies without an existing address management solution weighing their options, Gosign recommends tt_address as the starting point for all scenarios under 5,000 records. The extension is stable, well documented, has a large community and integrates seamlessly with other TYPO3 extensions. For larger data volumes or complex sync requirements (real-time synchronization with SAP HR, Active Directory or CRM systems), Gosign builds a custom synchronization layer that uses tt_address for frontend output but leaves data ownership with the source system.

The initial setup of a tt_address project (installation, template customization, category structure, geocoding setup) is 2 to 4 development days. A branch finder with map integration and postal code search comes to 5 to 8 days, including Leaflet or maps2 integration.

--- typo3db_legacy TYPO3 - DB Migration | Gosign ---
> Compatibility layer for the old TYPO3 Database API (`$GLOBALS['TYPO3_DB']`). Bridge for extensions not yet migrated to Doctrine DBAL.

## Why typo3db_legacy has been a security risk for every extension since TYPO3 v12

TYPO3 completely switched its database abstraction to Doctrine DBAL with version 8. The old API via `$GLOBALS['TYPO3_DB']` was marked as deprecated from v9 and has been fully removed since v12. Despite this, thousands of TYPO3 installations in practice run extensions still based on the legacy API. typo3db_legacy keeps these extensions alive by recreating the old API as a compatibility layer.

The problem: the extension is not a permanent solution but a bridge. Each subsequent TYPO3 version increases the risk that the compatibility layer itself breaks. Anyone still using typo3db_legacy today faces a clear decision - migrate or risk the upgrade to v13.

## Typical use cases

**Custom extensions with direct database access.** Many agencies wrote extensions between 2012 and 2018 that call `$GLOBALS['TYPO3_DB']->exec_SELECTquery()` directly. In a typical mid-market installation, 3 to 8 such extensions can be found. Without typo3db_legacy, they would immediately fail with fatal errors after an update to v10+.

**Third-party extensions without active maintainer.** Extensions like older versions of tt_address add-ons, industry directories or specialized import tools were often maintained by solo developers. If the maintainer is no longer active, typo3db_legacy is the only option to preserve functionality during the upgrade.

**Staged migration of large installations.** Organizations with 50+ extensions cannot migrate everything simultaneously. typo3db_legacy allows a step-by-step approach: first perform the core upgrade, then convert extension by extension to Doctrine DBAL. Gosign plans such migrations in sprints of 3 to 5 extensions each, prioritized by business criticality and dependencies.

## Technical architecture

typo3db_legacy registers as a TYPO3 extension and provides the class `TYPO3\CMS\Typo3DbLegacy\Database\DatabaseConnection`. This class implements the same methods as the old `DatabaseConnection` from the TYPO3 Core: `exec_SELECTquery()`, `exec_INSERTquery()`, `exec_UPDATEquery()`, `exec_DELETEquery()` and the associated prepared statement variants.

Internally, the layer forwards all calls to Doctrine DBAL. This works reliably for standard queries. It becomes problematic with:

- **Direct MySQL functions** in queries (e.g. `GROUP_CONCAT`, database-specific syntax)
- **Prepared statements** with named parameters in the old format
- **Transaction handling** via the old API that does not map 1:1 to Doctrine
- **Performance**: every query passes through an additional abstraction layer with 5-15% overhead

The extension has no dependencies other than the TYPO3 Core itself. It simply needs to be installed via Composer (`typo3/cms-typo3db-legacy`) or the Extension Repository.

An important architectural aspect: typo3db_legacy was designed as a temporary measure. The code deliberately contains no optimizations that would make it longer-lived. There is no query caching on the compatibility layer, no connection pooling integration and no support for advanced Doctrine DBAL features like Expression Builder or custom type mappings. The design goal was: keep old queries running until they are migrated.

## Common problems and solutions

**Extension does not work despite typo3db_legacy after upgrade.** The cause is usually that the extension uses not only `$GLOBALS['TYPO3_DB']` but also other removed APIs like `$GLOBALS['TSFE']->sys_page` in old form or deprecated hook registrations. The solution requires a complete code analysis of the extension, not just the database calls. A scan with the TYPO3 Extension Scanner provides a prioritized list of all affected locations. Gosign performs such scans as an inventory before the actual upgrade begins - typical effort: 2 to 4 hours per installation with a report on all affected extensions and estimated migration effort.

**Queries return different results than before the upgrade.** Doctrine DBAL handles types more strictly than the old `mysqli`-based API. A `WHERE uid = '5'` (string instead of integer) can lead to unexpected behavior in edge cases. Solution: check all queries for correct PHP types and set casts explicitly.

**Performance drop after installation.** Installations with more than 100,000 records and frequent queries experience the overhead of the double abstraction measurably. Here, only the complete migration to Doctrine DBAL with QueryBuilder helps, making the layer unnecessary.

## Migration and version compatibility

typo3db_legacy was an official part of the TYPO3 Core through version 9.5 LTS. For TYPO3 v10 and v11, the extension existed as a separate Composer package. For TYPO3 v12 LTS, there is no officially supported release. Unofficial forks on GitHub attempt to establish compatibility but are tested by neither the Core team nor the Extension Owners group.

For TYPO3 v13, no compatibility layer is planned or realistic. The database layer has changed too significantly with the upgrade to Doctrine DBAL 4.0. Anyone using typo3db_legacy who wants to upgrade to v13 cannot avoid a complete migration.

The recommended migration path: every `exec_SELECTquery()` call is rewritten to use the Doctrine DBAL QueryBuilder. A typical extension with 10 to 20 query calls can be migrated in 4 to 8 hours. Gosign uses automated code analysis that identifies all legacy API calls and suggests migration code. For complex extensions with dynamically assembled queries, the effort increases to 2 to 3 days per extension.

The most common rewrites in detail: `exec_SELECTquery()` becomes `$queryBuilder->select()->from()->where()->executeQuery()`. `exec_INSERTquery()` becomes `$connection->insert()`. `exec_UPDATEquery()` becomes `$connection->update()`. The pattern is consistent, but each query must be individually reviewed because the old code frequently concatenates strings that the QueryBuilder expects as separate parameters. Particularly tricky: queries with dynamic WHERE clause construction where conditions are appended via loops. These require a complete restructuring of the logic.

--- GDPR iFrame TYPO3 - Consent | Gosign ---
> GDPR-compliant iframe embedding for TYPO3: load videos, maps, social media only after consent. Two-click solution with placeholders.

## YouTube-Videos und Google Maps ohne Einwilligung einzubetten, ist ein GDPR-Verstoss mit Abmahnrisiko

Jede iFrame-Einbettung eines externen Dienstes überträgt die IP-Adresse des Besuchers an den Dienstanbieter, noch bevor der Besucher interagiert. Ein YouTube-Video auf der Startseite sendet beim Seitenaufruf die IP an Google, eine Google-Maps-Karte an Google, ein Facebook-Widget an Meta. Ohne vorherige Einwilligung des Besuchers ist das ein Verstoss gegen die GDPR (Art. 6 Abs. 1 lit. a). Seit dem EuGH-Urteil Planet49 (2019) und dem BGH-Urteil zu Cookie-Bannern ist die Rechtslage klar: Technisch nicht notwendige Datenübertragungen an Dritte erfordern eine informierte Einwilligung. udg_gdpr_iframe implementiert die Zwei-Klick-Lösung für TYPO3: iFrames werden erst nach explizitem Klick des Besuchers geladen. Ein Platzhalter zeigt an, welcher Dienst geladen wird und welche Daten übertragen werden.

## Typical use cases involve YouTube, Google Maps und Social-Media-Embeds

Das häufigste Szenario sind YouTube-Videos auf Unternehmenswebsites. Eine Firma zeigt auf ihrer Karriereseite ein Recruiting-Video. Ohne Consent-Lösung sendet die Seite bei jedem Aufruf die Besucher-IP an Google. Mit udg_gdpr_iframe sieht der Besucher statt des Videos einen Platzhalter mit Vorschaubild, dem Hinweis "Dieses Video wird von YouTube bereitgestellt. Beim Abspielen werden Daten an Google übertragen." und einem Button "Video laden". Erst nach Klick wird der iFrame geladen und das Video abgespielt.

Ein zweites Szenario ist die Google-Maps-Karte auf der Kontaktseite. Die Anfahrtskarte ist ein Standardelement, aber ein datenschutzrechtliches Risiko. udg_gdpr_iframe zeigt stattdessen ein statisches Kartenbild (Screenshot) als Platzhalter. Besucher, die die interaktive Karte brauchen, klicken auf "Karte laden" und akzeptieren damit die Datenübertragung an Google.

Drittes Szenario: Social-Media-Embeds. Ein Blog-Artikel zitiert einen Tweet oder einen Instagram-Post. Auch diese Embeds laden externe Ressourcen und übertragen Nutzerdaten. udg_gdpr_iframe blockiert den Embed und zeigt einen Platzhalter, der den Dienst benennt und einen Vorschautext anzeigt.

## Technical architecture ersetzt iFrames durch Platzhalter mit JavaScript-Loader

Die Extension registriert ein Content-Element oder modifiziert bestehende TYPO3-Content-Elemente, die iFrames enthalten. Im HTML wird der iFrame-src-Attribut durch ein data-src-Attribut ersetzt. Der Browser lädt den iFrame nicht, weil das src-Attribut fehlt. Stattdessen zeigt ein Platzhalter-Div den Dienst-Namen, den Datenschutzhinweis und einen Aktivierungs-Button.

Beim Klick auf den Button kopiert ein JavaScript-Snippet das data-src in das src-Attribut und der Browser lädt den iFrame. Optional kann der Besucher eine "Immer laden"-Checkbox aktivieren, die seine Entscheidung im LocalStorage speichert. Bei späteren Besuchen wird der iFrame dann ohne erneute Interaktion geladen.

Die Platzhalter-Darstellung ist per Fluid-Template konfigurierbar: Vorschaubild (z.B. YouTube-Thumbnail), Text, Button-Label, Link zur privacy policy. Für YouTube-Videos kann die Extension das Thumbnail automatisch von der YouTube-API abrufen (ohne iFrame, nur ein Bild-Request).

Die Integration mit bestehenden Consent-Management-Plattformen (CookieBot, OneTrust, Borlabs Cookie) ist über die JavaScript-API möglich: Wenn der Besucher im Cookie-Banner der Kategorie "Marketing" zugestimmt hat, werden alle Marketing-iFrames automatisch geladen, ohne Zwei-Klick.

## Common problems involve die Erkennung aller iFrames und die CMP-Integration

Das grösste Problem ist die vollständige Erkennung aller iFrames auf der Website. Redakteure betten iFrames nicht nur über Content-Elemente ein, sondern auch direkt im RTE (Rich Text Editor), in Fluid-Templates und in TypoScript. Die Extension muss alle Quellen abdecken. Ein häufiger Fehler: Die Content-Elemente sind geschützt, aber ein YouTube-iFrame im Footer-Template lädt weiterhin ohne Einwilligung. Die Lösung: Nach der Installation einen vollständigen Crawl der Website durchführen und alle iFrame-Quellen identifizieren.

Zweites Problem: Die Integration mit dem Consent-Management. Wenn die Website bereits Borlabs Cookie oder CookieBot einsetzt, kann es Konflikte geben: Das CMP blockiert den iFrame per eigenem Mechanismus, udg_gdpr_iframe blockiert ihn nochmals. Das Ergebnis: Doppelte Platzhalter oder ein iFrame, der nach der CMP-Einwilligung trotzdem nicht lädt. Die Lösung: Entweder udg_gdpr_iframe oder das CMP für iFrame-Blockierung nutzen, nicht beides.

Drittes Thema: Barrierefreiheit. Der Platzhalter muss per Screenreader zugänglich sein: Der Button braucht ein aria-label, der Datenschutzhinweis muss als Text (nicht als Bild) vorliegen, und die Tastaturnavigation muss funktionieren.

## TYPO3 v12 wird unterstützt, die Extension bleibt relevant solange iFrames existieren

udg_gdpr_iframe löst ein Problem, das mit jeder neuen GDPR-Auslegung relevanter wird. Die Extension läuft unter TYPO3 v12 stabil. Für v13 ist ein Update der Content-Element-Registrierung und des JavaScript-Loaders nötig. Da die Kernfunktionalität (iFrame-src durch data-src ersetzen) technisch trivial ist, lässt sich die Extension bei Bedarf mit geringem Aufwand auf jede TYPO3-Version portieren. Gosign prüft bei Datenschutz-Audits die vollständige iFrame-Abdeckung und empfiehlt die Lösung, die zum bestehenden Consent-Management der Website passt.

--- Survey TYPO3 - Survey Plugin | Gosign ---
> Simple survey/poll extension for TYPO3. Quick polls directly in the CMS. For more complex surveys: LimeSurvey integration.

## Schnelle Meinungsumfragen direkt auf der Website erzeugen Engagement, das Kommentarfelder nicht liefern

Blog-Artikel mit Kommentarfunktion erzeugen in der Praxis weniger als 1 Prozent Interaktion. Eine Umfrage ("Stimmen Sie zu?", "Welche Option bevorzugen Sie?") schafft 5 bis 15 Prozent, weil die Hürde niedriger ist: ein Klick statt einer Texteingabe. Das TYPO3-Umfragetool bringt einfache Polls direkt ins CMS. Redakteure erstellen Umfragen im Backend (Frage, Antwortoptionen, Mehrfachauswahl ja/nein, Ergebnis-Anzeige), betten sie als Content-Element ein und sehen die Ergebnisse in Echtzeit. Für schnelle Meinungsbilder ist das ausreichend. Für wissenschaftliche oder komplexe Befragungen empfehlen wir die LimeSurvey-Integration, die deutlich mächtigere Fragetypen und Auswertungen bietet.

## Typical use cases umfassen Leser-Polls, Event-Feedback und Abstimmungen

Das häufigste Szenario ist der Leser-Poll auf einer News- oder Blog-Seite. Ein Fachmagazin fragt: "Welches Feature wünschen Sie sich in TYPO3 v14 am meisten?" mit fünf Antwortoptionen. Leser klicken auf ihre Wahl und sehen sofort die prozentuale Verteilung. Das erzeugt Engagement, liefert der Redaktion ein Stimmungsbild und gibt dem Artikel eine interaktive Komponente, die die Verweildauer erhöht.

Ein zweites Szenario ist Event-Feedback. Nach einer Konferenz oder einem Webinar sehen Teilnehmer auf der TYPO3-Website eine Umfrage: "Wie bewerten Sie die Veranstaltung?" (sehr gut / gut / befriedigend / schlecht). Das ist kein Ersatz für einen ausführlichen Feedback-Fragebogen, aber eine schnelle Zufriedenheitsmessung, die deutlich mehr Teilnehmer ausfüllen als eine E-Mail-Survey.

Drittes Szenario: Abstimmungen in Vereinen und Gremien. Ein Fachverband lässt seine Mitglieder über das Logo-Redesign abstimmen. Drei Entwürfe stehen zur Wahl, jedes Mitglied hat eine Stimme. In Kombination mit fe_login ist sichergestellt, dass nur registrierte Mitglieder abstimmen und jedes Mitglied nur einmal teilnimmt.

## Technical architecture stores Umfragen als Extbase-Records mit Ergebniszählung

Das Umfragetool definiert zwei Extbase-Modelle: Poll (Frage, Beschreibung, Start-/Enddatum, Mehrfachauswahl-Flag) und Option (Antworttext, Stimmenanzahl). Ein Poll enthält mehrere Options. Stimmen werden als Zähler (Integer-Inkrement) in der Option gespeichert, nicht als einzelne Records pro Teilnehmer. Das hält die Datenbank schlank und die Performance hoch, bedeutet aber auch, dass individuelle Antworten nicht nachvollziehbar sind.

Im Frontend rendert die Extension ein Formular mit Radio-Buttons (Einfachauswahl) oder Checkboxen (Mehrfachauswahl). Nach dem Absenden wird der Zähler der gewählten Option inkrementiert und die Ergebnisdarstellung als horizontales Balkendiagramm mit Prozentwerten angezeigt.

Gegen Mehrfachstimmen setzt die Extension auf Cookie-basierte Duplikat-Erkennung: Nach der Teilnahme wird ein Cookie gesetzt, das eine erneute Stimmabgabe verhindert. Das ist kein sicherer Schutz (Cookies lassen sich löschen), aber für Meinungsumfragen ohne formale Anforderungen ausreichend. Für verbindliche Abstimmungen ist die Kombination mit fe_login nötig, die eine Prüfung gegen die fe_users-Tabelle ermöglicht.

## Common problems involve Manipulationssicherheit und fehlende Analysefunktionen

Das grösste Problem bei offenen Polls ist die Manipulierbarkeit. Ohne Login kann ein Besucher den Cookie löschen und erneut abstimmen. Im Inkognito-Modus funktioniert die Cookie-Sperre gar nicht. Wer belastbare Ergebnisse braucht, muss die Umfrage an den fe_login koppeln. Für niederschwellige Meinungsbilder ("Was interessiert Sie?") ist die Cookie-Lösung hingegen akzeptabel.

Zweites Problem: Fehlende Analysefunktionen. Das Umfragetool speichert nur Gesamtzahlen, keine Zeitverläufe, keine Segmentierung nach Nutzergruppen, keine Kreuztabellen. Wenn die Auswertung über "63% wählen Option A" hinausgehen soll, ist LimeSurvey oder ein dediziertes Survey-Tool die bessere Wahl.

Drittes Thema: Design-Anpassung. Die mitgelieferten Templates sind funktional, aber nicht auf moderne UI-Anforderungen ausgelegt. Wer Umfragen in einem aufgeräumten Design mit Animationen (Balken füllen sich, Prozentzahlen zählen hoch) darstellen will, muss die Fluid-Templates überschreiben und eigenes CSS/JS hinzufügen.

## TYPO3 v12 wird unterstützt, für komplexere Umfragen ist LimeSurvey die bessere Wahl

Das Umfragetool läuft unter TYPO3 v12 stabil. Für v13 ist ein Update der Plugin-Registrierung nötig. Da die Extension technisch schlank ist (zwei Extbase-Modelle, ein Controller, ein Fluid-Template), ist die Migration unkompliziert. Gosign empfiehlt die Extension für einfache Polls mit drei bis fünf Antwortoptionen. Sobald Fragetypen wie Likert-Skalen, offene Textfelder, Matrixfragen oder bedingte Logik benötigt werden, ist eine LimeSurvey-Integration die professionellere Lösung.

--- VHS Development TYPO3 | Gosign ---
> Developer version of the VHS ViewHelper collection. Test newest features before the official release. For TYPO3 developers on the bleeding edge.

## Why the VHS development version is a double-edged sword for TYPO3 agencies

VHS (ViewHelpers Supplementary) is the most comprehensive Fluid extension for TYPO3 with over 300 ViewHelpers. The development version delivers new ViewHelpers and bug fixes before they flow into a stable release. For developers working on current projects and waiting for a specific bug fix or new feature, this is an advantage. For production websites, it is a risk: development versions are not fully tested and can change incompatibly between commits.

The decision to use VHS Development in a project is therefore not technical but organizational: does the team have the capacity to test changes to the library promptly and react when something breaks? And is there the organizational discipline to replace the development version with a stable release before go-live?

## Typical use cases

**Bug fix access before the next stable release.** A project uses the VHS ViewHelper `v:format.trim`, which has a bug in the stable version - whitespace in multiline strings is not handled correctly. The fix already exists in the development branch, but the next stable release is not planned for 4 weeks. The team temporarily switches to VHS Development to use the bug fix immediately and returns to the stable release afterward.

**Evaluation of new ViewHelpers for a relaunch project.** A TYPO3 relaunch begins in 3 months. The development team evaluates whether new VHS ViewHelpers (e.g. for responsive image handling or JSON-LD output) can simplify the template code. The development version is installed in a local development environment, tested and the results feed into the architecture decision. If a new ViewHelper is missing from the stable release, the team can plan their own implementation as a fallback in time.

**Contributing to VHS development.** Agencies that contribute custom ViewHelpers to VHS or report bugs work with the development version to test their patches against the current codebase. Without the development version, meaningful contributing is not possible. Pull requests are opened against the development branch, and only there can the contributor verify that their fix has no side effects.

## Technical architecture

VHS Development is not a separate extension but the current development state of the VHS repository on GitHub (FluidTYPO3/vhs). Installation is done via Composer with `dev-main` or a specific branch:

- `composer require fluidtypo3/vhs:dev-main` installs the current development state
- `composer require fluidtypo3/vhs:dev-feature-xyz` installs a specific feature branch
- The `minimum-stability` setting in `composer.json` must be set to `dev`, which affects all packages

VHS itself has the TYPO3 Core (Fluid Template Engine) as its only hard dependency. The over 300 ViewHelpers cover areas such as:

- **Content**: rendering content elements, FAL access, media handling
- **Format**: string manipulation, dates, numbers, JSON, Markdown
- **Iterator**: array operations, sorting, filtering, pagination
- **Page**: page tree navigation, breadcrumb, sitemap
- **Media**: image manipulation, video embedding, audio
- **Security**: access checks, login status, frontend user groups

The development version may contain ViewHelpers whose API is still changing. Parameters may be renamed, return values changed or ViewHelpers removed entirely. In the stable release, the API is frozen. Between two stable releases, the development branch typically changes the signatures of 5 to 15 ViewHelpers. Anyone using these in production templates risks errors after a Composer update.

## Common problems and solutions

**Composer update breaks existing templates.** A `composer update` pulls the latest development version, in which a ViewHelper parameter has been renamed. All templates using this parameter throw errors. Solution: consistently commit the Composer lock file and install VHS Development with a fixed commit reference: `composer require fluidtypo3/vhs:dev-main#abc1234`. This prevents the latest version from being automatically pulled.

**minimum-stability dev affects other packages.** If `minimum-stability` in `composer.json` is set to `dev`, other packages can also install unstable versions. Solution: keep `"minimum-stability": "stable"` and define VHS Development explicitly as an exception: `"fluidtypo3/vhs": "dev-main as 6.99.0"`. The alias pattern allows installation without a global stability change.

**CI/CD pipeline fails with development version.** Automated tests and deployments based on Composer installations can fail with the development version if GitHub is temporarily unreachable or the branch was force-pushed. Solution: use a local Composer mirror (Satis) for CI/CD pipelines or switch to the stable release.

## Migration and version compatibility

VHS stable releases follow the TYPO3 LTS cycles: VHS 6.x supports TYPO3 v11, VHS 7.x supports TYPO3 v12. The development branch targets the next major version.

Switching from VHS Development back to stable is typically straightforward, provided no ViewHelpers are used that exist only in the development version. Gosign recommends: before switching to stable, check all used VHS ViewHelpers against the stable documentation. The VHS changelog on GitHub lists all changes between development and release.

For TYPO3 v13, a VHS 8.x release is planned. Teams working with the development version today should check their templates for deprecated ViewHelpers. Claus Due and the FluidTYPO3 team typically announce breaking changes in the GitHub milestone.

Gosign recommends the following strategy for handling VHS Development: use the development version on development environments and in feature branches to evaluate new ViewHelpers. Use only stable releases on staging and production. If a critical bug fix is only available in development, pin the specific commit as a Composer reference and leave a TODO comment in the code that surfaces during the next stable release review. This pattern prevents development dependencies from silently reaching production.

--- VHS TYPO3 - Fluid ViewHelper | Gosign ---
> The ViewHelper collection for TYPO3 Fluid templates by FluidTYPO3. Hundreds of additional ViewHelpers for media, content, page, iterator, math, string.

## EXT:vhs is the invisible toolbox of every professional TYPO3 template

Anyone working in TYPO3 with Fluid and going beyond mere output of content ends up at EXT:vhs sooner or later. The extension from the FluidTYPO3 ecosystem ships several hundred additional ViewHelpers for tasks the core deliberately does not cover: image manipulation, iterator logic, math operations, string handling, content queries, page navigation. For frontend developers at agencies and in-house teams, vhs is not an optional nice-to-have but the foundation on which complex template structures emerge without PHP detours.

The typical audience are teams that maintain demanding sitepackages: publishers with heterogeneous content types, universities with nested navigation trees, corporations with multilingual portals. Without vhs, every other special requirement would have to be offloaded into a custom ViewHelper or into TypoScript. With vhs, the logic stays where it belongs: in the template.

## Typical use cases

A first scenario is content queries across foreign page trees. A customer portal of a mechanical engineering company with 3,000 product pages needs a teaser block on every page with the latest news from a separate news rootline branch. The ViewHelper v:content.get pulls content from any pages and enables modular page composition without having to build TypoScript CONTENT objects.

A second scenario is iterator processing. A publishing house maintains articles with categories, tags and authors as ObjectStorage. In pure Fluid, filtering, grouping and sorting across nested objects is cumbersome. With v:iterator.filter, v:iterator.sort or v:iterator.groupBy, such operations become readable and maintainable directly inside the template.

A third scenario is image processing. An e-commerce shop with 500 products per season needs responsive image variants with picture tag, WebP fallback and LQIP placeholder. With vhs media ViewHelpers, this block is defined once in a partial and reused everywhere.

A fourth scenario is the mathematical processing of figures in reporting pages. Anyone who wants to output prices with subtotals, percentages or weighted averages reaches for v:math.sum, v:math.percentage or v:math.division, without having to build a dedicated controller for every calculation.

## Technical architecture

EXT:vhs is a pure library extension without backend modules and without database tables. It registers namespaces in Fluid ({namespace v=FluidTYPO3\Vhs\ViewHelpers}) and thereby exposes the ViewHelpers through the prefix v:. The extension has no hard dependencies on the rest of the FluidTYPO3 stack (Flux, Fluidcontent), even if it is often deployed alongside them.

Installation runs through Composer with fluidtypo3/vhs. In a sitepackage, vhs is usually listed as a dependency of the project's own provider extension, so that namespace registration happens in the layout template or globally through the TypoScript configuration array. Anyone who has to declare the namespace in every single template has usually missed the global registration path.

Relevant for performance is that vhs does not cache its own database queries. Anyone using v:content.get or v:page.menu without Fluid caching at worst creates the same query on every page view. The solution lies in cleanly configured Fluid caching through page and content cache and in the conscious use of the CacheStatic mechanism in the TYPO3 core.

The extension package is modular. Individual ViewHelper groups (Asset, Condition, Format, Iterator, Math, Media, Page, Resource, System, Variable) can be used selectively without pulling the entire stack into the project. In practice, however, the full collection is typically installed, because the dependencies between the groups are difficult to isolate and the footprint of the extension as a whole remains acceptable.

## Common problems and solutions

The first problem is the infamous namespace collision. Anyone who uses EXT:vhs alongside their own ViewHelpers under the prefix v: gets unpredictable overlaps. The solution is to register custom ViewHelpers consistently under a dedicated prefix (for example my:) and to move vhs calls onto core ViewHelpers where the TYPO3 core now offers an alternative (f:format.padding replaces v:format.padding).

The second problem is version compatibility with newer Fluid versions. In TYPO3 v12 and v13, Fluid has been reworked several times, which causes deprecation warnings or type errors in some vhs ViewHelpers. The solution is an audit of the ViewHelpers in use against the compatibility matrix in the GitHub repository and a selective replacement with core alternatives or bespoke lean implementations.

The third problem is performance under load. v:iterator.filter and v:iterator.sort are convenient but compute-intensive on large datasets. Anyone rendering a template with 10,000 products per page should shift the filter logic into the repository and only pass the already filtered result to the template.

A fourth, often overlooked problem are undocumented behaviour changes between vhs versions. A ViewHelper that returned a string in version 6.x suddenly returns an array in version 7.x, or vice versa. The solution is to pin the vhs version in the Composer lock file and carefully diff the changelog against the project's templates on every upgrade, ideally with a lint step in the CI pipeline that immediately flags unknown ViewHelper signatures.

## Migration and version compatibility

EXT:vhs is officially released for TYPO3 v11 and v12. For v13 there is a development branch that is actively maintained but not yet production-ready in all ViewHelpers. Teams currently planning an upgrade from v11 to v12 can usually carry vhs along without major intervention. The upgrade path to v13 is the critical point for template-heavy projects: here it is worth a cost-benefit comparison between keeping vhs and stepwise rewriting to core Fluid plus custom ViewHelpers.

The strategic answer depends on the extent of vhs usage. Projects that only use a handful of vhs ViewHelpers should replace them on the next upgrade with core constructs or project-specific ViewHelpers. Projects with hundreds of vhs calls across all templates are better off keeping vhs and running a targeted compatibility test on every upgrade. Replacement only pays off where the legacy burden weighs on maintenance more than a controlled continued use would.

Gosign accompanies TYPO3 upgrades with a vhs legacy and decides together with the team which vhs ViewHelpers are replaced by core constructs and which are rebuilt as lean project ViewHelpers. That keeps the template heritage maintainable without tying the project to an external library stack for years to come.

--- Cache Warmup TYPO3 - Performance | Gosign ---
> Cache warmup for TYPO3: pre-warm page cache after deployment. CI/CD integration. AI-accelerated.

## Why the first 5 minutes after a TYPO3 deployment determine the user experience

After every deployment, the TYPO3 cache is cleared. This is technically necessary but has a noticeable consequence: the first visitors after deployment see uncached pages. Instead of 200ms loading time, they wait 2 to 5 seconds - for complex pages, even longer. A deployment at 9:00 AM hits exactly the visitors with the highest conversion probability.

warmup solves this problem by proactively filling the cache before the first real visitor accesses the page. The extension crawls all pages of the website in the background, based on the sitemap, and prioritizes the most visited pages. After 2 to 10 minutes (depending on page count), the entire cache is filled and every visitor gets full performance.

## Typical use cases

**Automated cache warming after CI/CD deployments.** A company deploys its TYPO3 website 2 to 3 times per week through a CI/CD pipeline (GitLab CI, GitHub Actions, Deployer). After each deployment, Deployer clears the cache. warmup is called as the last step in the pipeline and fills the cache before the deployment is marked as "successful". The pipeline waits until warmup finishes and only then releases traffic to the new version.

**Cache rebuild after manual changes.** Editors sometimes clear the entire cache through the TYPO3 backend because a single page is not displaying current content. This affects all pages. warmup registers as a hook on the cache clear event and automatically starts the warmup process. The editor notices nothing, but visitors experience no performance drop.

**Scheduled warming for high-traffic time windows.** A TYPO3-based online shop has peak hours between 10:00 and 12:00 AM. A scheduler task starts warmup daily at 9:30 AM so the cache is fully filled by the time the traffic peak begins. This is especially relevant when the TYPO3 cache has a limited TTL (time-to-live) and partially expires overnight.

## Technical architecture

warmup operates as a TYPO3 CLI command and as a scheduler task. The warmup process runs in three phases:

- **URL collection**: warmup reads the website's sitemap (`sitemap.xml`) and extracts all URLs. Alternatively, a crawler can generate the sitemap from the TYPO3 page tree if no sitemap extension is configured. The URL list can be filtered via configuration (e.g. only specific page trees or languages).
- **Prioritization**: URLs are sorted by priority. Priority can come from the sitemap (`<priority>` tag), from Matomo/Analytics data or from a manual configuration. The homepage and top-10 landing pages are cached first.
- **Crawling**: warmup calls each URL via HTTP request. The TYPO3 caching framework stores the rendering result. warmup supports parallel crawling (configurable, default: 4 simultaneous requests) to speed up the process without overloading the server.

The CLI command is `vendor/bin/typo3 warmup:execute`. For CI/CD integration, it is typically called as a post-deploy hook.

Dependencies: TYPO3 Core, caching framework. warmup works with any cache backend - file system, Redis, Memcached, APCu. In combination with staticfilecache, warmup creates static HTML files in advance that the web server serves directly. The extension also offers a dry-run mode that displays the URL list without executing requests. This is useful for verifying the warmup configuration before the first production run.

## Common problems and solutions

**warmup process takes over 30 minutes.** For websites with more than 5,000 pages and multi-language setups (e.g. 1,000 pages x 5 languages = 5,000 URLs), the warmup process can be lengthy. Solution: increase parallelism (e.g. to 8 simultaneous requests), exclude unimportant pages (e.g. pagination pages, tag archives) and limit the process to the top 500 pages. Remaining pages are cached on first visit.

**Server load hits 100% during warmup.** warmup generates real HTTP requests against the server itself. Without rate limiting, this can drive server load to a level that slows down real visitors. Solution: reduce parallelism and configure a delay between requests (e.g. 100ms). On dedicated servers with sufficient resources, this is not an issue; on shared hosting, warmup may trigger the provider's server limits.

**Cached pages are not current after warmup.** warmup caches the page as it exists at the time of the call. If editors change content during the warmup process, the cache does not match the current state. Solution: only start warmup after all content changes are complete. In CI/CD pipelines, this is automatic; for manual cache clears, warmup should start with a 30-second delay.

## Migration and version compatibility

The warmup extension (eliashaeussler/typo3-warming) is available for TYPO3 v11 and v12 LTS and is actively maintained. For TYPO3 v13, compatibility is expected shortly after the release.

Those currently using manual warmup scripts (curl loops, wget crawlers) can replace them with warmup. The advantage: warmup understands the TYPO3 sitemap structure, prioritizes by traffic and integrates with the scheduler. A manual script crawls blindly; warmup crawls intelligently.

The combination warmup + staticfilecache + Redis is the performance stack Gosign recommends for enterprise TYPO3 installations. warmup fills the cache, staticfilecache serves static HTML files without PHP, Redis stores database queries. Together, TYPO3 websites achieve loading times under 100ms. For websites with fewer than 500 pages and moderate traffic, warmup alone without staticfilecache is sufficient. The simple TYPO3 page cache already delivers loading times under 300ms when correctly filled. warmup ensures this level is maintained from the first second after deployment.

--- Weather Widget TYPO3 | Gosign ---
> Weather widget for TYPO3: current weather data from OpenWeatherMap or other APIs. Tourism websites, outdoor events, regional portals.

## Tourismus-Websites, die kein aktuelles Wetter zeigen, verschenken eine der meistgesuchten Informationen

Wenn jemand "Mallorca Wetter" oder "Zugspitze aktuell" googelt, erwartet er auf der Destinations-Website eine Wetter-Anzeige. Fehlt sie, verlässt der Besucher die Seite und nutzt eine Wetter-App. Das ist eine verpasste Chance, weil der Besucher bereits auf der richtigen Website war. weather2 integriert aktuelle Wetterdaten in TYPO3: Temperatur, Wetterlage, Niederschlag, Wind, Luftfeuchtigkeit und eine Mehrtagesprognose. Die Daten kommen von OpenWeatherMap oder vergleichbaren APIs und werden im konfigurierbaren Intervall aktualisiert. Für Tourismus-Websites, Outdoor-Event-Portale und regionale Nachrichtenportale ist das eine Standardfunktion, die Besucher erwarten.

## Typical use cases umfassen Destinations-Portale, Campingplätze und Skigebiete

Das häufigste Szenario ist das Tourismus-Portal einer Region. Der Tourismusverband einer Bodensee-Gemeinde zeigt auf seiner Startseite das aktuelle Wetter: 22 Grad, sonnig, Wassertemperatur 19 Grad. Daneben eine 5-Tage-Vorhersage. Besucher, die einen Tagesausflug planen, bekommen sofort die relevante Information und bleiben auf der Seite, um Aktivitäten zu buchen. Die Wassertemperatur kommt über einen separaten API-Endpunkt oder wird manuell gepflegt.

Ein zweites Szenario sind Campingplätze und Ferienparks. Ein Campingplatz im Schwarzwald zeigt auf seiner Buchungsseite das Wetter der nächsten Woche. Besucher, die zwischen zwei Reisewochen schwanken, können die Vorhersage als Entscheidungshilfe nutzen. Für den Campingplatz-Betreiber ist das ein Conversion-Argument: "Die Sonne scheint, buchen Sie jetzt."

Drittes Szenario: Skigebiete und Outdoor-Events. Ein Skigebiet zeigt Temperatur am Berg und im Tal, Schneehöhe (aus einer separaten Datenquelle) und Windgeschwindigkeit. Ein Outdoor-Festival zeigt die Wettervorhersage für das Festival-Wochenende. In beiden Fällen liefert die Wetter-Anzeige einen konkreten Mehrwert, der Besucher auf der Website hält.

## Technical architecture ruft Wetterdaten per API ab und cached sie lokal

weather2 kommuniziert mit der OpenWeatherMap-API (oder alternativ mit API-Anbietern wie WeatherAPI, Visual Crossing, Meteostat). Die Konfiguration im TYPO3-Backend definiert: API-Key, Standort (Koordinaten oder Ortsname), Einheiten (metrisch/imperial), Sprache und Update-Intervall. Der Standard-Intervall ist 30 Minuten, das heisst alle 30 Minuten wird ein API-Request an OpenWeatherMap gesendet und die Antwort in der TYPO3-Datenbank gecached.

Das Frontend-Plugin rendert die Wetterdaten über Fluid-Templates: aktuelle Temperatur, Wetter-Icon (Sonne, Wolken, Regen), Textbeschreibung, Wind, Luftfeuchtigkeit. Die Mehrtagesprognose zeigt Tagesminimum und -maximum für drei bis sieben Tage. Icons werden als SVG ausgeliefert, nicht als externe Bild-URLs, damit keine zusätzlichen Requests an Dritt-Server gehen.

Für den API-Key bietet OpenWeatherMap einen kostenlosen Plan mit 1.000 Calls pro Tag, was bei einem 30-Minuten-Intervall (48 Calls pro Tag) mehr als ausreicht. Für Websites mit mehreren Standorten (z.B. ein Tourismusverband mit 10 Orten) werden 480 Calls pro Tag benötigt, was immer noch im Free-Tier liegt. Pro-Pläne (ab 40 Dollar/Monat) bieten stündliche Updates und erweiterte Daten wie UV-Index und Pollenflug.

## Common problems involve API-Limits, Caching und veraltete Daten

Das häufigste Problem ist die Überschreitung des API-Limits. Wenn das TYPO3-Caching nicht korrekt konfiguriert ist und jeder Seiten-Request einen API-Call auslöst, ist das Free-Tier-Limit von 1.000 Calls nach wenigen Stunden erreicht. Die Extension zeigt dann keine Daten mehr oder einen Fehler. Die Lösung: Sicherstellen, dass die Wetterdaten im TYPO3-Cache gespeichert und nicht bei jedem Frontend-Request neu abgerufen werden. Das Caching muss unabhängig vom Seiten-Cache funktionieren (Scheduler-Task oder eigener Cache-Eintrag).

Zweites Problem: Veraltete Wetterdaten. Wenn der Scheduler-Task nicht läuft (Cronjob deaktiviert, Server-Migration), zeigt die Website Tage oder Wochen alte Wetterdaten. Das ist schlimmer als keine Anzeige. Die Lösung: Im Fluid-Template ein Fallback einbauen, das prüft, ob die gecachten Daten älter als zwei Stunden sind, und bei veralteten Daten das Widget ausblendet statt falsche Daten anzuzeigen.

Drittes Thema: Datenschutz. Wenn die Wetterdaten per JavaScript direkt vom Client an die API abgerufen werden, überträgt der Browser die IP des Besuchers an den API-Anbieter. Das ist eine Drittanbieter-Datenübertragung, die GDPR-relevant ist. Die serverseitige Lösung (TYPO3-Server ruft die API ab, nicht der Browser) vermeidet dieses Problem.

## TYPO3 v12 wird unterstützt, die API-Integration bleibt versionsunabhängig stabil

weather2 nutzt die TYPO3-HTTP-Client-Library für API-Requests und Fluid-Templates für das Rendering. Beides ist im TYPO3-Core stabil. Unter v12 läuft die Extension ohne Probleme. Für v13 sind minimale Anpassungen nötig (Scheduler-Task-Registrierung, Plugin-Konfiguration). Da die Kernlogik (HTTP-Request, JSON-Parsing, Datenbank-Speicherung) standardisiert ist, bleibt die Extension bei TYPO3-Upgrades wartungsarm. Gosign konfiguriert Wetter-Widgets als Teil von Tourismus-Website-Projekten und stellt sicher, dass API-Caching, Fallback und Datenschutz korrekt implementiert sind.

--- web2pdf TYPO3 - Pages as PDF | Gosign ---
> web2pdf: export TYPO3 pages as PDF. Setup, performance & modern alternatives (Puppeteer). AI-accelerated.

## Why web2pdf is indispensable for TYPO3 websites with price lists and product pages

Sales teams need printable PDFs. Customers expect a "Save as PDF" button on product pages. And industrial purchasers download price lists to forward them internally. web2pdf solves exactly this problem: the extension renders any TYPO3 page as a PDF - with correct layout, embedded images and clean typography. Instead of manually creating each page as a PDF and updating it with every change, web2pdf generates the PDF live from the current page content.

This saves not only editorial time but also prevents outdated PDF versions. When a product price is changed in the CMS, web2pdf automatically delivers the current version on the next download.

## Typical use cases

**Product catalogs and price lists in B2B.** A mechanical engineering company maintains 200 product pages in TYPO3. The sales force needs a printable data sheet for every product. web2pdf generates a PDF from each product page with logo, technical specifications and contact information in corporate design. The editor maintains only one source - the web page - and the PDF updates automatically.

**Articles and white papers as downloads.** Media companies and specialist publishers offer magazine articles as PDF downloads. web2pdf converts the article including images and formatting into a print-optimized PDF. A print CSS controls which elements appear in the PDF (content) and which do not (navigation, footer, cookie banner).

**Quotes and configurations.** Configurator results, quote summaries or cart overviews can be exported as PDFs via web2pdf. The user clicks "Quote as PDF" and receives a print-ready document with all selected options. An automobile configurator that outputs the chosen equipment as PDF, an insurance calculator that provides the offer for download - the use cases are broad and the benefit for sales is immediately measurable.

## Technical architecture

web2pdf functions as a TYPO3 extension with a frontend plugin that displays a PDF download button on each page. On click, the extension internally calls the current page and passes the HTML output to a PDF rendering backend.

The extension supports two rendering engines:

- **wkhtmltopdf**: the classic solution based on an older WebKit version. Advantages: simple installation as a single binary, low resource consumption. Disadvantages: CSS Flexbox and Grid are not supported, web fonts work only partially, the project has not been actively maintained since 2022.
- **Puppeteer/Chromium**: the modern alternative. Puppeteer controls a headless Chromium browser that renders the page like a normal browser and exports it as PDF. Full CSS support (Flexbox, Grid, Custom Properties), correct web font embedding, JavaScript execution. Disadvantage: higher resource consumption (Chromium requires approx. 100-200 MB RAM per rendering process).

The extension is configured through TypoScript and extension settings in the TYPO3 Install Tool. Key parameters: PDF page size (A4, Letter, custom), margins, header/footer templates, cookie handling for authenticated content.

A separate print CSS (`@media print`) controls which elements are visible in the PDF. Gosign recommends hiding navigation, footer, cookie banner and interactive elements in the print CSS and instead inserting logo, contact details and a URL reference. A well-configured print CSS makes the difference between a professional data sheet and a screenshot of the web page. Typical adjustments: font size at 11pt for print readability, page breaks before H2 headings, QR code with the source URL in the footer.

## Common problems and solutions

**PDF shows wrong layout, missing images or fonts.** Most common cause: wkhtmltopdf cannot render modern CSS. Websites using Flexbox or CSS Grid look completely different in the PDF than in the browser. Solution: switch to Puppeteer as the rendering engine. Alternatively, create a separate print CSS with layout fallbacks for older rendering engines.

**PDF generation takes 10+ seconds.** Puppeteer starts a Chromium process for each PDF. With concurrent requests, server load multiplies. Solution: implement PDF caching. The generated PDF is cached in the file system for a defined period (e.g. 60 minutes). Only when page content changes is the PDF regenerated. On servers with limited RAM (under 2 GB), wkhtmltopdf is the more pragmatic choice despite CSS limitations.

**Authenticated pages deliver empty PDF.** web2pdf calls the page internally via HTTP. If the page sits behind a login, session cookies are missing and the rendering process sees only the login page. Solution: configure a special PDF rendering endpoint that handles authentication via a token instead of session cookies.

## Migration and version compatibility

web2pdf is stably available for TYPO3 v10 and v11. For TYPO3 v12 LTS, community forks exist that establish compatibility. The original package is no longer actively maintained.

For TYPO3 v13 and beyond, Gosign recommends an architectural shift: instead of running web2pdf as a TYPO3 extension, implement PDF generation as a separate microservice. A Node.js service with Puppeteer accepts URLs and returns PDFs. This decouples PDF generation from the TYPO3 server, reduces server load and makes the solution TYPO3-version-independent.

The migration effort from web2pdf to a Puppeteer-based solution is typically 2 to 4 days. Existing print CSS files can be reused 1:1. Only the invocation mechanism (button click, URL handling) needs adjustment.

A frequently underestimated aspect of PDF generation: accessibility. PDFs generated from HTML are not automatically accessible. For companies subject to the European Accessibility Act (EAA, effective June 2025), generated PDFs must contain tagged PDF structures. Neither wkhtmltopdf nor Puppeteer produce accessible PDFs by default. Gosign recommends a post-processing step with a specialized PDF library (e.g. TCPDF or mPDF with tag support) that translates HTML semantics into PDF tags.

--- Webflow to TYPO3 - Migration | Gosign ---
> Migration from Webflow websites to TYPO3: more control, no platform dependency, enterprise features. Gosign converts Webflow HTML/CSS into Fluid templates.

## Webflow-Websites stossen bei Enterprise-Anforderungen an harte Grenzen

Webflow ist hervorragend für Prototypen, Landingpages und Startups mit drei bis fünf Mitarbeitenden. Aber ab einem gewissen Punkt wird die Plattform zum Problem: keine Multi-Language-Unterstützung auf Enterprise-Niveau, kein feingranulares Rechtemanagement, keine Custom-Backend-Workflows, keine On-Premise-Option, und Hosting ausschliesslich auf Webflow-Servern in den USA. Für Unternehmen, die in der EU gehostet werden müssen (GDPR, Schrems II), mehrere hundert Seiten verwalten und ein CMS mit Redakteurs-Workflows brauchen, ist TYPO3 die logische Weiterentwicklung. Gosign migriert Webflow-Websites auf TYPO3: Das bestehende Design (HTML/CSS) wird in Fluid Templates konvertiert, der Content wird strukturiert übernommen, und die Funktionalität wird durch TYPO3-Extensions ergänzt.

## Typical use cases involve wachsende Unternehmen, regulierte Branchen und internationale Rollouts

Das häufigste Szenario ist das schnell gewachsene Startup, das seine Webflow-Seite nicht mehr skaliert bekommt. Mit 20 Mitarbeitenden und einer Website in einer Sprache funktioniert Webflow. Mit 200 Mitarbeitenden, fünf Sprachen und einem Blog mit 500 Artikeln nicht mehr. Die Webflow-Preisstruktur skaliert nicht: CMS-Pläne sind auf 10.000 Items begrenzt, Custom Code ist limitiert, API-Zugriffe gedrosselt. Der Wechsel auf TYPO3 gibt dem Unternehmen volle Kontrolle über Hosting, Performance und Erweiterbarkeit.

Ein zweites Szenario sind regulierte Branchen. Ein Finanzdienstleister hat seine Marketing-Website auf Webflow aufgebaut, aber die Compliance-Abteilung verlangt EU-Hosting, Audit-Logs für Content-Änderungen und ein Freigabe-Workflow, bei dem vier Augen jeden Seiteninhalt genehmigen. Webflow bietet keinen dieser Punkte nativ. TYPO3 schon: Workspaces für Staging und Freigabe, ext:belog für Audit-Logs, und Hosting auf einem Server in Frankfurt.

Drittes Szenario: Internationaler Rollout. Ein Industrieunternehmen hat seine Hauptseite auf Webflow in Englisch. Jetzt sollen Landeswebsites in 12 Sprachen entstehen. Webflow Localization ist teuer und limitiert. TYPO3 bietet native Multi-Site- und Multi-Language-Unterstützung, bei der jede Sprache eine eigene Seitenstruktur haben kann, inklusive lokaler Inhalte, die nicht in allen Sprachen existieren.

## Technical architecture konvertiert Webflow-Export in TYPO3-Fluid-Templates

Die Migration folgt einem definierten Prozess: Export des Webflow-Projekts als HTML/CSS/JS, Analyse der Seitenstruktur und der eingesetzten Interaktionen, Konvertierung des HTML in Fluid-Templates, Import der Inhalte in TYPO3-Content-Elemente. Der Webflow-Export liefert sauberes, semantisches HTML, das sich gut in Fluid übersetzen lässt. CSS wird als Sass/SCSS-Datei übernommen oder in Tailwind-Utility-Klassen umgeschrieben, je nach TYPO3-Setup.

Webflow-Interaktionen (Scroll-Animationen, Hover-Effekte, Modals) basieren auf einer proprietären JavaScript-Engine. Diese 1:1 zu übernehmen ist nicht möglich. Stattdessen werden die Interaktionen mit nativem CSS (transitions, animations) oder leichtgewichtigem JavaScript (IntersectionObserver, Dialog-Element) nachgebaut. In den meisten Fällen reduziert das die JavaScript-Dateigrösse von 200-300 KB (Webflow Runtime) auf unter 20 KB.

Der Content-Import läuft über die Webflow-API oder den HTML-Export. Jede Webflow Collection wird auf ein TYPO3-Content-Element oder einen Extbase-Record gemappt. Blog-Artikel werden in tx_news importiert, Team-Mitglieder in Custom Records, Testimonials in die bestehende TYPO3-Datenstruktur.

## Common problems involve Webflow-spezifische Features und URL-Redirects

Das grösste Problem bei der Migration sind Webflow-Features ohne TYPO3-Äquivalent. Webflow Forms laufen über einen integrierten Form-Handler. In TYPO3 muss ein Formular-System (powermail, Form Framework) konfiguriert werden. Webflow E-Commerce läuft auf der Plattform. In TYPO3 muss ein Shopsystem (TYPO3-native oder Shopware/Magento-Integration) eingerichtet werden. Diese Funktionslücken müssen vor der Migration identifiziert und im TYPO3-Projekt geplant werden.

Zweites Problem: URL-Redirects. Webflow-URLs folgen einem eigenen Schema. Nach der Migration müssen alle alten URLs auf die neuen TYPO3-URLs umgeleitet werden, damit Google die Seiten nicht als 404 indexiert und bestehende Backlinks erhalten bleiben. Bei 200 Seiten sind das 200 Redirects, die in der TYPO3-Redirect-Tabelle oder per .htaccess konfiguriert werden.

Drittes Thema: Design-Differenzen. Webflow rendert CSS-Layouts mit einer eigenen Engine, die von Browser-Standardverhalten abweichen kann. Ein Layout, das in Webflow pixel-perfekt aussieht, kann in TYPO3 minimal anders rendern, weil der CSS-Reset oder die Schriftart-Einbindung abweicht. Ein visueller QA-Pass nach der Migration ist deshalb Pflicht.

## Die Migration ist kein Upgrade, sondern ein Plattformwechsel

Es gibt keinen automatisierten Migrationspfad von Webflow zu TYPO3. Jede Migration ist ein Projekt mit Analyse, Konvertierung, Import und QA. Die Dauer hängt von der Komplexität ab: Eine einfache Website mit 20 Seiten und einem Blog ist in zwei bis drei Wochen migriert. Eine komplexe Website mit 500 Seiten, E-Commerce und fünf Sprachen braucht zwei bis drei Monate. Gosign hat Webflow-Migrationen für Unternehmen von 50 bis 2.000 Seiten durchgeführt und setzt dabei auf KI-gestützte Template-Konvertierung, die den Fluid-Code aus dem Webflow-HTML generiert und die manuelle Anpassung auf ein Minimum reduziert.

--- WebP TYPO3 - Image Optimization | Gosign ---
> Automatic conversion of JPG/PNG to WebP. 25–35% smaller image files, faster loading times. Gosign also configures AVIF support for even better compression.

## Bilder machen 50 bis 70 Prozent des Seitengewichts aus, und WebP reduziert sie um ein Drittel

Die durchschnittliche TYPO3-Website lädt pro Seite 2 bis 5 MB an Bilddaten. Das ist der grösste einzelne Faktor für die Ladezeit und damit für den Google PageSpeed Score. WebP ist ein von Google entwickeltes Bildformat, das bei vergleichbarer Qualität 25 bis 35 Prozent kleiner ist als JPEG und bis zu 80 Prozent kleiner als PNG. Die TYPO3 WebP-Extension konvertiert vorhandene JPG- und PNG-Bilder automatisch in WebP, ohne dass Redakteure ihr Verhalten ändern müssen. Bilder werden wie gewohnt im FAL-Backend hochgeladen, die Extension erzeugt die WebP-Variante im Hintergrund und liefert sie an Browser aus, die das Format unterstützen. Alle modernen Browser unterstützen WebP seit 2020: Chrome, Firefox, Safari, Edge.

Für Websites, die bereits PageSpeed-optimiert sind, ist die WebP-Konvertierung oft der letzte Schritt, der den Score von 85 auf 95 oder höher hebt.

## Typical use cases involve bildlastige Websites, E-Commerce und Mobile-First-Projekte

Das häufigste Szenario sind bildlastige Unternehmenswebsites. Ein Immobilienportal zeigt pro Objekt 15 bis 25 Fotos. Bei 500 Objekten sind das 10.000 Bilder. Ohne WebP wiegen die Bilder im Schnitt 250 KB (JPEG), mit WebP 170 KB. Auf einer Listenansicht mit 20 Objekten und je einem Titelbild spart WebP 1,6 MB pro Seitenaufruf. Bei 50.000 Seitenaufrufen pro Monat sind das 80 GB weniger Traffic, was sich direkt auf die Hosting-Kosten auswirkt.

Ein zweites Szenario sind E-Commerce-Integrationen. Ein Shopsystem zeigt Produktbilder in verschiedenen Grössen: Thumbnail, Listenansicht, Detailansicht, Zoom. Jede Grösse wird als WebP-Variante generiert. Bei einem Shop mit 2.000 Produkten und je fünf Bildvarianten entstehen 10.000 WebP-Dateien, die den Seitenaufbau in der Listenansicht messbar beschleunigen.

Drittes Szenario: Mobile-First-Websites für Zielgruppen mit schlechter Netzanbindung. Ein NGO-Portal, das in Regionen mit 3G-Netzen genutzt wird, profitiert überproportional von kleineren Bilddateien. Der Unterschied zwischen 5 Sekunden und 15 Sekunden Ladezeit entscheidet, ob der Besucher die Seite sieht oder abbricht.

## Technical architecture konvertiert Bilder im TYPO3-Processing-Pipeline

Die Extension klinkt sich in die TYPO3-Bild-Processing-Pipeline ein. Wenn TYPO3 ein Bild verarbeitet (Resize, Crop), erzeugt die Extension zusätzlich eine WebP-Variante im selben Verzeichnis. Die Auslieferung erfolgt über Content Negotiation: Der Server prüft den Accept-Header des Browsers. Wenn der Browser "image/webp" akzeptiert, liefert er die WebP-Datei. Andernfalls das Original-JPEG/PNG.

Technisch gibt es zwei Implementierungsvarianten: Die erste nutzt mod_rewrite-Regeln im Apache oder nginx, die Bild-Requests auf die WebP-Variante umleiten, wenn sie existiert. Die zweite nutzt ein TYPO3-Middleware, das den Response-Header manipuliert. Die mod_rewrite-Variante ist performanter, weil sie vor PHP ausgeführt wird.

Die Konvertierung selbst läuft über libwebp (Kommandozeilen-Tool cwebp), ImageMagick mit WebP-Support oder die PHP-Extension GD (wenn mit WebP-Support kompiliert). Die Qualität ist konfigurierbar: Standard 80 (von 100), was einen guten Kompromiss zwischen Dateigrösse und visueller Qualität bietet. Für fotografische Inhalte empfehlen wir 82 bis 85, für Screenshots und Illustrationen 75 bis 78.

Für noch bessere Kompression unterstützen neuere Versionen der Extension das AVIF-Format, das weitere 20 bis 30 Prozent Einsparung gegenüber WebP bietet. AVIF-Support ist in Chrome und Firefox verfügbar, Safari seit Version 16.

## Common problems involve fehlende Server-Libraries und CDN-Konfiguration

Das häufigste Problem ist die fehlende cwebp-Binary auf dem Server. Shared-Hosting-Umgebungen haben oft kein libwebp installiert, und der Hoster erlaubt keine Installation von Binaries. Die Lösung: PHP GD mit WebP-Support nutzen (in den meisten PHP-Versionen ab 7.1 verfügbar) oder einen Hosting-Provider wählen, der cwebp bereitstellt. Auf Managed-Servern und in Docker-Containern ist die Installation trivial: apt-get install webp.

Zweites Problem: CDN-Konfiguration. Wenn ein CDN (Cloudflare, Fastly, AWS CloudFront) vor der Website liegt, muss es WebP korrekt handhaben. Zwei Ansätze: Das CDN kennt Content Negotiation und cached WebP und JPEG als separate Varianten (Vary: Accept). Oder die TYPO3-Website liefert direkt WebP-URLs aus (ohne Content Negotiation), und das CDN cached nur eine Version. Cloudflare bietet automatische WebP-Konvertierung über Polish, was die TYPO3-Extension teilweise überflüssig macht.

Drittes Thema: Qualitätskontrolle. Bei zu niedriger Qualitätseinstellung (unter 70) werden Artefakte sichtbar, besonders bei Farbverläufen und feinen Texturen. Ein A/B-Vergleich (Original vs. WebP) sollte nach der Konfiguration durchgeführt werden, um sicherzustellen, dass die Qualität für den Anwendungsfall akzeptabel ist.

## TYPO3 v12 und v13 werden unterstützt, die Extension ist eine der stabilsten im Ökosystem

Die WebP-Extension gehört zu den am häufigsten installierten Performance-Extensions im TYPO3-Ökosystem. Sie wird aktiv gepflegt und ist mit TYPO3 v12 und v13 kompatibel. Da die Kernfunktionalität (Bild-Processing-Hook, Datei-Konvertierung) auf stabilen TYPO3-APIs basiert, sind Breaking Changes bei Upgrades selten. Gosign konfiguriert WebP als Standard in jedem neuen TYPO3-Projekt und aktiviert bei Verfügbarkeit zusätzlich AVIF für maximale Kompression.

--- Bootstrap TYPO3 - T3Bootstrap | Gosign ---
> Bootstrap framework as TYPO3 site package. Responsive templates, grid system, Bootstrap components as content elements.

## Bootstrap-basierte TYPO3-Projekte brauchen ein Sitepackage, das die Brücke zwischen Framework und CMS schlägt

Bootstrap ist das meistgenutzte CSS-Framework der Welt. Über 25 Prozent aller Websites setzen Bootstrap ein. Für TYPO3-Projekte bedeutet das: Designer liefern Entwürfe in Bootstrap, Entwickler kennen die Klassen und Komponenten, und Kunden erwarten responsive Layouts, die auf Bootstrap aufbauen. ws_t3bootstrap bringt Bootstrap als Sitepackage direkt in TYPO3: Responsive Templates, das Grid-System, Bootstrap-Komponenten (Accordion, Cards, Carousel, Tabs, Alerts) als Content-Elemente und eine vorkonfigurierte TypoScript-Basis. Statt Bootstrap manuell in ein leeres TYPO3-Projekt zu integrieren, liefert ws_t3bootstrap einen funktionsfähigen Startpunkt, der sofort produktionsfähig ist.

## Typical use cases include Unternehmenswebsites, Portale und Rapid-Prototyping

Das häufigste Szenario ist die mittelständische Unternehmenswebsite. Ein Unternehmen mit 50 bis 500 Mitarbeitenden braucht eine Website mit 30 bis 80 Seiten: Startseite, Über uns, Leistungen, Referenzen, Karriere, Kontakt. Der Designer erstellt ein Mockup auf Basis von Bootstrap 5. ws_t3bootstrap liefert die Templates, das Grid-System und die Content-Elemente, sodass der Entwickler nur das Custom CSS (Farben, Schriften, Abstände) und projektspezifische Komponenten ergänzen muss. Typische Entwicklungszeit: zwei bis drei Wochen vom Mockup zur fertigen Website, statt vier bis sechs Wochen bei einem Custom-Setup.

Ein zweites Szenario sind Intranet-Portale. Ein Unternehmen betreibt ein TYPO3-Intranet für 2.000 Mitarbeitende. Das Design muss nicht einzigartig sein, aber konsistent und responsive. ws_t3bootstrap liefert ein professionelles Standard-Layout, das ohne grossen Design-Aufwand eingesetzt werden kann. Content-Elemente wie Akkordeons für FAQs, Tabs für Abteilungsinformationen und Cards für News-Teaser sind sofort verfügbar.

Drittes Szenario: Rapid Prototyping. Eine Agentur baut in zwei Tagen einen funktionierenden Website-Prototyp, den der Kunde freigeben kann. ws_t3bootstrap reduziert die Setup-Zeit auf Stunden statt Tage, weil die Grundstruktur (Header, Footer, Navigation, Grid) bereits steht.

## Technical architecture registriert Bootstrap-Komponenten als TYPO3 Content Elements

ws_t3bootstrap installiert sich als TYPO3-Sitepackage und konfiguriert: TypoScript-Setup mit Bootstrap-CSS/JS-Includes, Fluid-Templates für Header, Footer und Seitenlayouts, Backend-Layouts (1-Spalter, 2-Spalter, 3-Spalter mit Sidebar) und Content-Elemente, die Bootstrap-Komponenten abbilden.

Die Content-Elemente werden über TCA-Konfigurationen und Fluid-Templates definiert. Ein Accordion-Element erstellt beispielsweise ein Bootstrap-Accordion mit n Panels, jedes Panel mit Titel und Body-Text. Ein Card-Element erzeugt eine Bootstrap-Card mit Bild, Titel, Text und Link. Ein Grid-Element ermöglicht verschachtelte Spalten-Layouts innerhalb einer Seite.

Das Bootstrap-CSS wird entweder als kompilierte CSS-Datei eingebunden (schnell, keine Build-Tools nötig) oder als Sass-Quellcode, der über ein Build-System (Webpack, Vite) kompiliert wird. Die Sass-Variante erlaubt, Bootstrap-Variablen (Farben, Breakpoints, Schriftgrössen) zu überschreiben und nur die benötigten Bootstrap-Module einzubinden, was die CSS-Dateigrösse von 230 KB auf 80 bis 120 KB reduziert.

Die JavaScript-Komponenten (Accordion, Collapse, Dropdown, Modal, Tab, Toast) werden über Bootstrap 5 eingebunden, das ohne jQuery auskommt. Das reduziert die JavaScript-Dateigrösse gegenüber Bootstrap 4 um rund 85 KB (jQuery-Wegfall).

## Common problems involve Bootstrap-Versions-Konflikte und CSS-Spezifitäts-Kämpfe

Das grösste Problem bei Bootstrap-Sitepackages ist der Versions-Konflikt. Wenn ws_t3bootstrap Bootstrap 5.2 einbindet, aber eine andere Extension (z.B. ein Slider-Plugin) Bootstrap 4.6 oder 3.x mitbringt, kollidieren die CSS-Klassen. Bootstrap 4 nutzt "col-md-4", Bootstrap 5 ebenfalls, aber mit unterschiedlichem Verhalten bei bestimmten Utilities. Die Lösung: Alle Extensions auf dieselbe Bootstrap-Version vereinheitlichen oder Extension-eigenes Bootstrap per CSS-Scoping isolieren.

Zweites Problem: CSS-Spezifität. Wenn Custom CSS die Bootstrap-Klassen überschreiben muss, entsteht ein Spezifitäts-Wettlauf: !important-Deklarationen häufen sich, weil Bootstrap-Utilities hohe Spezifität haben. Die Lösung: Bootstrap-Variablen statt CSS-Overrides nutzen und das Custom-Stylesheet nach dem Bootstrap-CSS laden.

Drittes Thema: Performance. Bootstrap als Framework lädt alle Komponenten, auch wenn die Website nur fünf davon nutzt. Bei einer Website, die nur Grid, Cards und Navbar braucht, werden 80 Prozent des Bootstrap-CSS nie genutzt. PurgeCSS oder ein selektiver Sass-Import reduziert die CSS-Dateigrösse auf das Nötige.

## TYPO3 v12 und v13 werden unterstützt, Bootstrap 5 ist der aktuelle Standard

ws_t3bootstrap wird aktiv gepflegt und unterstützt TYPO3 v12 und v13. Die aktuelle Version basiert auf Bootstrap 5.3. Beim Upgrade von Bootstrap 4 auf 5 sind Breaking Changes zu beachten: jQuery-Abhängigkeit entfällt, einige CSS-Klassen wurden umbenannt (z.B. ml-/mr- zu ms-/me-), und die JavaScript-API hat sich geändert. Gosign führt Bootstrap-Upgrades zusammen mit TYPO3-Upgrades durch und prüft dabei alle Content-Elemente auf korrekte Darstellung. Bei neuen Projekten empfehlen wir ws_t3bootstrap als Startpunkt und ergänzen das Sitepackage um projektspezifische Komponenten, statt Bootstrap von Grund auf in TYPO3 zu integrieren.

--- wwt3_encryption TYPO3 - Email Protection | Gosign ---
> TYPO3 extension for automatic email encryption on the website. Protects email addresses against harvesters and spam bots through JavaScript or CSS-based.

## Why email obfuscation is still mandatory for every public website

Every corporate website, every university page and every public authority publishes email addresses: contacts in the legal notice, team members on staff pages, press contacts in newsrooms, legal departments in privacy policies. Without protection, harvester bots collect these addresses within a few days of publication and sell them to spam senders. wwt3_encryption is a classic TYPO3 extension for this problem and encrypts email addresses server-side, so that bots parsing the HTML only see unusable code, while real users can click through to the correct address. The extension is aimed at operators who have to show contact data prominently for legal reasons but are not willing to accept the resulting spam flood.

## Typical use cases

A law firm with 60 partners and associates publishes all lawyer profiles including direct email addresses, because professional rules of conduct require a reachable contact option. Without obfuscation, all 60 addresses receive phishing mail, advertising and sometimes targeted attacks within weeks. wwt3_encryption renders the addresses so that the source code contains no readable @ string, while the browser shows the correct mailto link address to the user.

A second scenario is a university that maintains department pages with chair contacts. Every chair has a page with phone and email data, edited editorially via the TYPO3 content management. Editors enter the addresses as normal text in rich text elements or contact fields without having to worry about obfuscation. wwt3_encryption automatically hooks into the rendering process and protects all mailto links without any extra editorial work.

The third case is public authorities with legal notices, contact forms and department lists. The requirement here is often even stricter, because an accessibility obligation applies: the protected address has to be read out correctly by screen readers, and a click has to open the mail client, exactly as with an unobfuscated address. A combination of JavaScript decoding and semantically clean href attributes is the only way to satisfy both.

## Technical architecture: content post-processing in TYPO3 rendering

wwt3_encryption hooks into the TYPO3 rendering process, typically via a content post-processor hook or a TypoScript userfunc. After the page renderer has assembled the HTML output, the extension walks through the finished markup, finds all mailto links and all simple email addresses in running text via regex and replaces them with obfuscated variants. The obfuscation can run through several methods: ROT13 encoding of the link target with JavaScript decoding, base64 encoding, character-wise fragmentation with CSS pseudo elements or a combination.

The advantage of the post-processing variant is that it works without changes to content elements or templates. Editors keep working with normal mailto links in rich text, and the extension handles the protection automatically. The extension is configured via TypoScript constants that select between the different obfuscation methods and define exceptions for certain page or content areas.

## Common problems and solutions

The first problem is accessibility. Pure JavaScript solutions fail for users with JavaScript disabled, and some screen readers struggle with CSS-based character fragmentation. A pragmatic approach combines lightly breakable client-side obfuscation with an additional semantic aria-label on the link, so that screen readers read the address correctly while harvesters fail on the syntactic inconsistency. Absolute security is not achievable with publicly accessible addresses, but even moderate hurdles measurably reduce the spam load.

The second problem is caching layers. If the post-processing obfuscation runs before the page cache, the cache delivers the obfuscated data and everything works. If it runs after the cache, every cached page is sent through the post-processor on every request, which noticeably drags down performance. The correct order in the TypoScript rendering chain is therefore critical and should be reviewed with every larger change to caching behaviour.

The third topic concerns dynamic content. Email addresses that are loaded via AJAX or come from external APIs do not pass through the TYPO3 renderer and therefore not through wwt3_encryption. Such places have to be protected separately, either by having the API deliver obfuscated variants or by a client-side JavaScript that post-processes the loaded content.

## Migration and version compatibility

wwt3_encryption, like many older TYPO3 extensions, has an uneven version history: there were maintained releases for v9 and v10, community forks exist for v11 and v12, and their activity varies. Anyone migrating to TYPO3 v13 should check before the upgrade whether their fork still works or whether a switch to an alternative obfuscation method is needed.

The TYPO3 core itself ships a simple email obfuscation enabled via config.spamProtectEmailAddresses in TypoScript, which applies ROT13 in the core renderer. For simple setups this core variant is enough and makes a separate extension unnecessary. Anyone who needs stronger or more flexible obfuscation, for example with several parallel methods or exceptions per content element, reaches for an extension such as wwt3_encryption. Gosign evaluates case by case whether the core function is sufficient or a dedicated extension makes sense, and supports the rebuild to a lean, project-specific post-processing implementation if needed.

The effectiveness of any email obfuscation decreases over time because harvester techniques evolve. ROT13 is today considered nearly ineffective against specialised bots, while character-wise fragmentation with CSS or Unicode tricks still raises moderate barriers. The genuinely robust defence is therefore a combination: obfuscation in the HTML output, a good spam filter on the recipient side and, ideally, a contact form as the primary option rather than a directly published address. Operators who have to meet legal requirements cannot avoid publishing the address but should offer the contact form as the primary path and show the address only as a secondary option.

For operators of TYPO3 v13, it is also worth reviewing the content rendering pipeline regularly for breaking changes in the core. Several hook points that were available in earlier versions for post-processing were deprecated in v13 or replaced by PSR-14 events. Extensions that still rely on old hooks keep running technically after the upgrade but no longer modify any content. A short review of the log entries after an upgrade reveals such silent failures early and prevents unobfuscated addresses from being served unnoticed for weeks.

--- TYPO3 Extensions | Development & Monitoring ---
> 800+ TYPO3 extensions monitored. Development, audit and security monitoring. All extensions at a glance.

<!-- What does Gosign offer? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">What does Gosign offer for TYPO3 extensions?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Gosign monitors over 800 TYPO3 extensions for security vulnerabilities, compatibility and performance. For every extension, Gosign provides: new development, update &amp; migration, code audit and maintenance. 25&nbsp;years in TYPO3 development, since 2023 with AI-accelerated workflows: 60-80&nbsp;% faster than traditional methods.
</p>
</div>
</section>

<!-- Extension Categories -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">Extension categories</h2>
<div class="space-y-8">

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Search & Indexing</h3>
<p class="text-body text-gosign-text mb-4">Apache Solr, ke_search, faceted search. Enterprise search across thousands of documents and files.</p>
<div class="flex flex-wrap gap-2">
<a href="/en/typo3/solrfal/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">solrfal</a>
<a href="/en/typo3/ke_search_premium/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">ke_search_premium</a>
<a href="/en/typo3/find/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">find</a>
<a href="/en/typo3/in2studyfinder/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">in2studyfinder</a>
</div>
</div>

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Security & Authentication</h3>
<p class="text-body text-gosign-text mb-4">SSO, SAML, OIDC, cookie consent, CAPTCHA, CORS. Enterprise security for TYPO3.</p>
<div class="flex flex-wrap gap-2">
<a href="/en/typo3/shibboleth_auth/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">shibboleth_auth</a>
<a href="/en/typo3/oidc/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">oidc</a>
<a href="/en/typo3/dp_cookieconsent/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">dp_cookieconsent</a>
<a href="/en/typo3/saml2/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">saml2</a>
<a href="/en/typo3/be_acl/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">be_acl</a>
</div>
</div>

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Forms & Events</h3>
<p class="text-body text-gosign-text mb-4">Powermail, event management, booking systems, surveys, newsletter integration.</p>
<div class="flex flex-wrap gap-2">
<a href="/en/typo3/powermail/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">powermail</a>
<a href="/en/typo3/sf_event_mgt/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">sf_event_mgt</a>
<a href="/en/typo3/booking/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">booking</a>
<a href="/en/typo3/rapidmail/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">rapidmail</a>
</div>
</div>

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Content & Templates</h3>
<p class="text-body text-gosign-text mb-4">Mask, DCE, VHS ViewHelper, Bootstrap Grids. Custom content elements and template development.</p>
<div class="flex flex-wrap gap-2">
<a href="/en/typo3/mask/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">mask</a>
<a href="/en/typo3/dce/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">dce</a>
<a href="/en/typo3/vhs/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">vhs</a>
<a href="/en/typo3/bootstrap_grids/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">bootstrap_grids</a>
</div>
</div>

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">PDF & Documents</h3>
<p class="text-body text-gosign-text mb-4">PDF generation, PDF viewer, flipbooks, download management.</p>
<div class="flex flex-wrap gap-2">
<a href="/en/typo3/pdfviewhelpers/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">pdfviewhelpers</a>
<a href="/en/typo3/web2pdf/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">web2pdf</a>
<a href="/en/typo3/rflipbook/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">rflipbook</a>
<a href="/en/typo3/downloadmanager/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">downloadmanager</a>
</div>
</div>

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Media & Images</h3>
<p class="text-body text-gosign-text mb-4">Image editing, galleries, sliders, focuspoint, Cloudinary CDN.</p>
<div class="flex flex-wrap gap-2">
<a href="/en/typo3/focuspoint/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">focuspoint</a>
<a href="/en/typo3/imagemap/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">imagemap</a>
<a href="/en/typo3/sf_filecollection_gallery/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">sf_filecollection_gallery</a>
</div>
</div>

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Maps & Locations</h3>
<p class="text-body text-gosign-text mb-4">Leaflet, Google Maps, OpenStreetMap. Store locators and proximity search.</p>
<div class="flex flex-wrap gap-2">
<a href="/en/typo3/leaflet/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">leaflet</a>
<a href="/en/typo3/maps2/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">maps2</a>
<a href="/en/typo3/geocoordinates/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">geocoordinates</a>
</div>
</div>

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">E-Commerce</h3>
<p class="text-body text-gosign-text mb-4">aimeos, payment integration, paywall, price calculators.</p>
<div class="flex flex-wrap gap-2">
<a href="/en/typo3/aimeos/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">aimeos</a>
<a href="/en/typo3/amazon_payment/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">amazon_payment</a>
<a href="/en/typo3/paywall/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">paywall</a>
</div>
</div>

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Performance & SEO</h3>
<p class="text-body text-gosign-text mb-4">Cache warmup, staticfilecache, WebP conversion, canonical management.</p>
<div class="flex flex-wrap gap-2">
<a href="/en/typo3/warmup/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">warmup</a>
<a href="/en/typo3/webp/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">webp</a>
<a href="/en/typo3/newscanonical/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">newscanonical</a>
<a href="/en/typo3/cache_hash/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">cache_hash</a>
</div>
</div>

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">DevTools & Deployment</h3>
<p class="text-body text-gosign-text mb-4">Extension Builder, in2publish, Styleguide, Deployer.</p>
<div class="flex flex-wrap gap-2">
<a href="/en/typo3/extension_builder/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">extension_builder</a>
<a href="/en/typo3/in2publish/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">in2publish</a>
<a href="/en/typo3/styleguide/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">styleguide</a>
</div>
</div>

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Industry Solutions</h3>
<p class="text-body text-gosign-text mb-4">Real estate (OpenImmo, FlowFact), universities (in2studyfinder), associations (hwvereinsliste), education (kuferweb).</p>
<div class="flex flex-wrap gap-2">
<a href="/en/typo3/openimmo/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">openimmo</a>
<a href="/en/typo3/flowfact/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">flowfact</a>
<a href="/en/typo3/kuferweb/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">kuferweb</a>
</div>
</div>

</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Looking for support with a TYPO3 extension?</h3>
<p class="text-body text-gosign-text mb-6">30&nbsp;minutes initial consultation, free and no obligation.</p>
<a
href="/en/contact/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Book extension consultation
</a>
<p class="text-small text-gosign-text-light mt-4">25 years of experience · 800+ extensions · AI-accelerated development</p>
</div>
</section>

<!-- AI Table -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">AI-accelerated extension development</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
Gosign has been using AI-assisted development since 2023. In concrete terms:
</p>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Task</th>
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Traditional</th>
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">With AI</th>
<th class="py-3 text-small font-bold text-gosign-dark">Savings</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">New extension (Extbase)</td>
<td class="py-3 pr-4 text-body text-gosign-text">2-4 weeks</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">4-8 days</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">70&nbsp;%</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Extension update (v9 &rarr; v12)</td>
<td class="py-3 pr-4 text-body text-gosign-text">1-2 weeks</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">2-4 days</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">65&nbsp;%</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Security audit</td>
<td class="py-3 pr-4 text-body text-gosign-text">3-5 days</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">1 day</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">75&nbsp;%</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Code review + refactoring</td>
<td class="py-3 pr-4 text-body text-gosign-text">1 week</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">2 days</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">60&nbsp;%</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- TYPO3 Update -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">TYPO3 Update to the Current Version</h2>
<p class="text-body text-gosign-text leading-relaxed mb-8">
We update your TYPO3 installation cost-effectively to the current LTS version - including all extensions, even outdated and unmaintained ones.
</p>
<div class="grid md:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<div class="flex items-start gap-4">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-1" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75M21 12a9 9 0 1 1-18 0 9 9 0 0 1 18 0Z" /></svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">All extensions migrated</h3>
<p class="text-body text-gosign-text">Including outdated, unmaintained or custom-built extensions.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-6">
<div class="flex items-start gap-4">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-1" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 18.75a60.07 60.07 0 0 1 15.797 2.101c.727.198 1.453-.342 1.453-1.096V18.75M3.75 4.5v.75A.75.75 0 0 1 3 6h-.75m0 0v-.375c0-.621.504-1.125 1.125-1.125H20.25M2.25 6v9m18-10.5v.75c0 .414.336.75.75.75h.75m-1.5-1.5h.375c.621 0 1.125.504 1.125 1.125v9.75c0 .621-.504 1.125-1.125 1.125h-.375m1.5-1.5H21a.75.75 0 0 0-.75.75v.75m0 0H3.75m0 0h-.375a1.125 1.125 0 0 1-1.125-1.125V15m1.5 1.5v-.75A.75.75 0 0 0 3 15h-.75M15 10.5a3 3 0 1 1-6 0 3 3 0 0 1 6 0Zm3 0h.008v.008H18V10.5Zm-12 0h.008v.008H6V10.5Z" /></svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Fixed-price offer</h3>
<p class="text-body text-gosign-text">Transparent costs, no hidden follow-up work.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-6">
<div class="flex items-start gap-4">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-1" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M3.75 13.5l10.5-11.25L12 10.5h8.25L9.75 21.75 12 13.5H3.75Z" /></svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">AI-accelerated</h3>
<p class="text-body text-gosign-text">30-50 % cheaper than market rates thanks to AI-powered code analysis.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-6">
<div class="flex items-start gap-4">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-1" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M20.25 6.375c0 2.278-3.694 4.125-8.25 4.125S3.75 8.653 3.75 6.375m16.5 0c0-2.278-3.694-4.125-8.25-4.125S3.75 4.097 3.75 6.375m16.5 0v11.25c0 2.278-3.694 4.125-8.25 4.125s-8.25-1.847-8.25-4.125V6.375m16.5 0v3.75m-16.5-3.75v3.75m16.5 0v3.75C20.25 16.153 16.556 18 12 18s-8.25-1.847-8.25-4.125v-3.75m16.5 0c0 2.278-3.694 4.125-8.25 4.125s-8.25-1.847-8.25-4.125" /></svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Zero data loss</h3>
<p class="text-body text-gosign-text">Complete data migration with rollback protection.</p>
</div>
</div>
</div>
</div>
<div class="mt-8 text-center">
<a
href="/en/contact/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Request TYPO3 update
</a>
</div>
</div>
</section>

<!-- GDPR Audit -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">TYPO3 GDPR Audit &amp; Compliance</h2>
<p class="text-body text-gosign-text leading-relaxed mb-8">
We audit your TYPO3 installation for GDPR compliance and implement all measures cost-effectively.
</p>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse bg-white rounded-card">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Audit area</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">What is checked</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Result</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Cookie consent</td>
<td class="py-3 px-4 text-body text-gosign-text">Banner, opt-in/opt-out, consent logging</td>
<td class="py-3 px-4 text-body text-gosign-text">Legally compliant consent flow</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Tracking &amp; analytics</td>
<td class="py-3 px-4 text-body text-gosign-text">Google Analytics, Matomo, Tag Manager, third-party pixels</td>
<td class="py-3 px-4 text-body text-gosign-text">Privacy-compliant configuration</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Extensions</td>
<td class="py-3 px-4 text-body text-gosign-text">Data sharing with third parties, external requests, CDN integrations</td>
<td class="py-3 px-4 text-body text-gosign-text">Remediation or GDPR-compliant alternatives</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Forms</td>
<td class="py-3 px-4 text-body text-gosign-text">Processing records, consent mechanisms, retention periods</td>
<td class="py-3 px-4 text-body text-gosign-text">Complete documentation</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Hosting &amp; SSL</td>
<td class="py-3 px-4 text-body text-gosign-text">Server location, data processing agreement, encryption</td>
<td class="py-3 px-4 text-body text-gosign-text">EU-compliant hosting</td>
</tr>
</tbody>
</table>
</div>
<div class="mt-8 text-center">
<a
href="/en/contact/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Request GDPR audit
</a>
</div>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
Gosign is a Hamburg-based digital agency with 25 years of experience in web development, TYPO3 and AI integration.
We have analysed over 800 TYPO3 extensions and today develop with AI assistance
up to 70&nbsp;% faster than with traditional methods. Our clients include mid-market
enterprises, universities and public sector organisations across the EU.
</p>
<p class="text-small text-gosign-text-light mt-2">As of: February 2026</p>
</div>
</section>

<!-- Related Topics -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Related Topics</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/en/typo3-security-monitor/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Monitoring</p>
<p class="text-body font-semibold text-gosign-dark">TYPO3 Security Monitor</p>
</a>
<a href="/en/digital-agency-hamburg/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Web Development</p>
<p class="text-body font-semibold text-gosign-dark">Digital Agency Hamburg</p>
</a>
<a href="/en/website-security-standards/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Security</p>
<p class="text-body font-semibold text-gosign-dark">Website Security Standards</p>
</a>
</div>
</div>
</section>

--- TYPO3 Security Monitor | Extension Monitoring ---
> TYPO3 Security Monitor: monitor 800+ extensions, detect vulnerabilities. Free check available.

<!-- What is the Monitor? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">What is the TYPO3 Security Monitor?</h2>
<p class="text-body text-gosign-text leading-relaxed">
The Gosign TYPO3 Security Monitor automatically checks over 800 TYPO3 extensions for security vulnerabilities, outdated versions and known weaknesses. When an extension receives a security advisory, Gosign clients know immediately - not at the next manual check. The monitor is a proprietary Gosign tool that continuously evaluates TYPO3 security bulletins, extension changelogs and CVE databases.
</p>
</div>
</section>

<!-- Why Security Monitoring? -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Why do TYPO3 operators need security monitoring?</h2>
<p class="text-body text-gosign-text leading-relaxed">
TYPO3 installations typically use 30-50 extensions. Each one is a potential attack vector. The TYPO3 Security Team regularly publishes advisories, but who reads them all? Gosign's monitor does exactly that - automatically and in real time.
</p>
</div>
</section>

<!-- Monitor Table -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">What the monitor checks</h2>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Area</th>
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">What is checked</th>
<th class="py-3 text-small font-bold text-gosign-dark">Frequency</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Extension versions</td>
<td class="py-3 pr-4 text-body text-gosign-text">Installed vs. current version</td>
<td class="py-3 text-body text-gosign-text">Daily</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Security advisories</td>
<td class="py-3 pr-4 text-body text-gosign-text">TYPO3 security bulletins, CVE databases</td>
<td class="py-3 text-body text-gosign-accent-text font-semibold">Real-time</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">End-of-life</td>
<td class="py-3 pr-4 text-body text-gosign-text">Extensions without maintainer or updates</td>
<td class="py-3 text-body text-gosign-text">Weekly</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">TYPO3 Core</td>
<td class="py-3 pr-4 text-body text-gosign-text">Core version vs. current Stable/LTS</td>
<td class="py-3 text-body text-gosign-text">Daily</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">PHP version</td>
<td class="py-3 pr-4 text-body text-gosign-text">Compatibility and security status</td>
<td class="py-3 text-body text-gosign-text">Weekly</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Services -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">TYPO3 security services</h2>
<div class="grid md:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Security monitoring</h3>
<p class="text-body text-gosign-text">
Continuous monitoring of all extensions and the TYPO3 Core. Immediate notification for critical vulnerabilities.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Security audit</h3>
<p class="text-body text-gosign-text">
One-time deep review: extension inventory, version status, known vulnerabilities, code quality. AI-assisted analysis in hours instead of days.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Incident response</h3>
<p class="text-body text-gosign-text">
Website hacked? Gosign analyses the attack vector, cleans the installation and closes the vulnerability. Emergency support available.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Maintenance &amp; patching</h3>
<p class="text-body text-gosign-text">
Regular security updates, extension upgrades, PHP version management. Proactive, not reactive.
</p>
</div>
</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Request a TYPO3 security check - 30&nbsp;minutes, free of charge.</h3>
<p class="text-body text-gosign-text mb-6">We check your TYPO3 installation for known vulnerabilities, no obligation.</p>
<a
href="/en/contact/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Book a call
</a>
<p class="text-small text-gosign-text-light mt-4">25 years of experience · 800+ extensions · AI-accelerated development</p>
</div>
</section>

<!-- AI Table -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">AI-accelerated security analysis: 75&nbsp;% faster</h2>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Task</th>
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Traditional</th>
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">With AI</th>
<th class="py-3 text-small font-bold text-gosign-dark">Savings</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Extension inventory + version comparison</td>
<td class="py-3 pr-4 text-body text-gosign-text">1 day</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">30 minutes</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">90&nbsp;%</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Vulnerability analysis (50 extensions)</td>
<td class="py-3 pr-4 text-body text-gosign-text">2 days</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">4 hours</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">75&nbsp;%</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Code audit of an extension</td>
<td class="py-3 pr-4 text-body text-gosign-text">1 week</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">2 days</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">60&nbsp;%</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Incident analysis after hack</td>
<td class="py-3 pr-4 text-body text-gosign-text">2 days</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">6 hours</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">65&nbsp;%</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- TYPO3 Update -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">TYPO3 Update to the Current Version</h2>
<p class="text-body text-gosign-text leading-relaxed mb-8">
We update your TYPO3 installation cost-effectively to the current LTS version - including all extensions, even outdated and unmaintained ones.
</p>
<div class="grid md:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<div class="flex items-start gap-4">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-1" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75M21 12a9 9 0 1 1-18 0 9 9 0 0 1 18 0Z" /></svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">All extensions migrated</h3>
<p class="text-body text-gosign-text">Including outdated, unmaintained or custom-built extensions.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-6">
<div class="flex items-start gap-4">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-1" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 18.75a60.07 60.07 0 0 1 15.797 2.101c.727.198 1.453-.342 1.453-1.096V18.75M3.75 4.5v.75A.75.75 0 0 1 3 6h-.75m0 0v-.375c0-.621.504-1.125 1.125-1.125H20.25M2.25 6v9m18-10.5v.75c0 .414.336.75.75.75h.75m-1.5-1.5h.375c.621 0 1.125.504 1.125 1.125v9.75c0 .621-.504 1.125-1.125 1.125h-.375m1.5-1.5H21a.75.75 0 0 0-.75.75v.75m0 0H3.75m0 0h-.375a1.125 1.125 0 0 1-1.125-1.125V15m1.5 1.5v-.75A.75.75 0 0 0 3 15h-.75M15 10.5a3 3 0 1 1-6 0 3 3 0 0 1 6 0Zm3 0h.008v.008H18V10.5Zm-12 0h.008v.008H6V10.5Z" /></svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Fixed-price offer</h3>
<p class="text-body text-gosign-text">Transparent costs, no hidden follow-up work.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-6">
<div class="flex items-start gap-4">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-1" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M3.75 13.5l10.5-11.25L12 10.5h8.25L9.75 21.75 12 13.5H3.75Z" /></svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">AI-accelerated</h3>
<p class="text-body text-gosign-text">30-50 % cheaper than market rates thanks to AI-powered code analysis.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-6">
<div class="flex items-start gap-4">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-1" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M20.25 6.375c0 2.278-3.694 4.125-8.25 4.125S3.75 8.653 3.75 6.375m16.5 0c0-2.278-3.694-4.125-8.25-4.125S3.75 4.097 3.75 6.375m16.5 0v11.25c0 2.278-3.694 4.125-8.25 4.125s-8.25-1.847-8.25-4.125V6.375m16.5 0v3.75m-16.5-3.75v3.75m16.5 0v3.75C20.25 16.153 16.556 18 12 18s-8.25-1.847-8.25-4.125v-3.75m16.5 0c0 2.278-3.694 4.125-8.25 4.125s-8.25-1.847-8.25-4.125" /></svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Zero data loss</h3>
<p class="text-body text-gosign-text">Complete data migration with rollback protection.</p>
</div>
</div>
</div>
</div>
<div class="mt-8 text-center">
<a
href="/en/contact/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Request TYPO3 update
</a>
</div>
</div>
</section>

<!-- GDPR Audit -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">TYPO3 GDPR Audit &amp; Compliance</h2>
<p class="text-body text-gosign-text leading-relaxed mb-8">
We audit your TYPO3 installation for GDPR compliance and implement all measures cost-effectively.
</p>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse bg-white rounded-card">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Audit area</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">What is checked</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Result</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Cookie consent</td>
<td class="py-3 px-4 text-body text-gosign-text">Banner, opt-in/opt-out, consent logging</td>
<td class="py-3 px-4 text-body text-gosign-text">Legally compliant consent flow</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Tracking &amp; analytics</td>
<td class="py-3 px-4 text-body text-gosign-text">Google Analytics, Matomo, Tag Manager, third-party pixels</td>
<td class="py-3 px-4 text-body text-gosign-text">Privacy-compliant configuration</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Extensions</td>
<td class="py-3 px-4 text-body text-gosign-text">Data sharing with third parties, external requests, CDN integrations</td>
<td class="py-3 px-4 text-body text-gosign-text">Remediation or GDPR-compliant alternatives</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Forms</td>
<td class="py-3 px-4 text-body text-gosign-text">Processing records, consent mechanisms, retention periods</td>
<td class="py-3 px-4 text-body text-gosign-text">Complete documentation</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Hosting &amp; SSL</td>
<td class="py-3 px-4 text-body text-gosign-text">Server location, data processing agreement, encryption</td>
<td class="py-3 px-4 text-body text-gosign-text">EU-compliant hosting</td>
</tr>
</tbody>
</table>
</div>
<div class="mt-8 text-center">
<a
href="/en/contact/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Request GDPR audit
</a>
</div>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
Gosign is a Hamburg-based digital agency with 25 years of experience in web development, TYPO3 and AI integration.
We have analysed over 800 TYPO3 extensions and today develop with AI assistance
up to 70&nbsp;% faster than with traditional methods. Our clients include mid-market
enterprises, universities and public sector organisations across the EU.
</p>
<p class="text-small text-gosign-text-light mt-2">As of: February 2026</p>
</div>
</section>

<!-- Related Topics -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Related Topics</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/en/typo3-extensions/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">CMS</p>
<p class="text-body font-semibold text-gosign-dark">TYPO3 Extensions</p>
</a>
<a href="/en/website-hacked-10-reasons/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Security</p>
<p class="text-body font-semibold text-gosign-dark">Website Hacked: 10 Reasons</p>
</a>
<a href="/en/website-security-standards/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Security</p>
<p class="text-body font-semibold text-gosign-dark">Website Security Standards</p>
</a>
</div>
</div>
</section>

--- Website Hacked? 10 Reasons & Help ---
> Why websites get hacked: the 10 most common causes and what you can do immediately. Emergency help from Gosign.

<!-- What to do when hacked? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">What to do when your website has been hacked?</h2>
<p class="text-body text-gosign-text leading-relaxed">
When your website has been compromised, speed matters: remove malware, find the entry point, close the vulnerability, inform Google about the cleanup. Gosign provides emergency support for hacked websites - WordPress, TYPO3 and other CMS platforms. This article explains the 10 most common causes of website hacks and how to protect yourself.
</p>
</div>
</section>

<!-- 10 Reasons -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">The 10 most common reasons websites get hacked</h2>

<div class="space-y-8">
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">1. Outdated CMS version</h3>
<p class="text-body text-gosign-text leading-relaxed">
WordPress 5.x, TYPO3 v9, Joomla 3: old CMS versions have known, documented security vulnerabilities. Attackers automatically scan for outdated installations. Solution: always run the current LTS version, enable automatic security updates.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">2. Insecure plugins/extensions</h3>
<p class="text-body text-gosign-text leading-relaxed">
A single outdated plugin is enough. Gosign monitors over 800 TYPO3 extensions and knows the high-risk candidates. For WordPress: only use plugins from trusted sources, update regularly, delete unused plugins (do not just deactivate them).
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">3. Weak passwords</h3>
<p class="text-body text-gosign-text leading-relaxed">
"admin/admin123" is still alarmingly common. Brute-force attacks try thousands of combinations per minute. Solution: strong passwords + two-factor authentication + login rate limiting.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">4. Missing SSL/HTTPS</h3>
<p class="text-body text-gosign-text leading-relaxed">
Without HTTPS, login credentials are transmitted in plain text. Every website needs an SSL certificate. In 2026, there is no excuse.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">5. Insecure hosting</h3>
<p class="text-body text-gosign-text leading-relaxed">
Shared hosting with hundreds of sites on one server: if one gets hacked, all are at risk. Solution: managed hosting with isolation, automatic backups and a web application firewall.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">6. No web application firewall (WAF)</h3>
<p class="text-body text-gosign-text leading-relaxed">
A WAF blocks known attack patterns (SQL injection, XSS, file inclusion) before they reach your application. Cloudflare WAF, ModSecurity or commercial solutions.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">7. Missing backups</h3>
<p class="text-body text-gosign-text leading-relaxed">
No backup means no safety net. Daily backups, stored separately from the web server, tested regularly. A backup that cannot be restored is not a backup.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">8. Insecure file uploads</h3>
<p class="text-body text-gosign-text leading-relaxed">
Upload forms without validation allow attackers to upload PHP shells. Solution: strict file type checking, store uploads outside the webroot, randomise file names.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">9. SQL injection</h3>
<p class="text-body text-gosign-text leading-relaxed">
Unfiltered user inputs in database queries let attackers read or manipulate the entire database. Solution: prepared statements, input validation, ORM usage.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">10. No monitoring</h3>
<p class="text-body text-gosign-text leading-relaxed">
If nobody is watching, nobody notices the breach. Some hacks go undetected for months (spam injection, crypto mining, redirect hacks). Solution: uptime monitoring, file integrity monitoring, regular malware scans.
</p>
</div>
</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Website hacked? Gosign can help. Emergency support available.</h3>
<p class="text-body text-gosign-text mb-6">Fast analysis, cleanup and hardening of your website.</p>
<a
href="/en/contact/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Request emergency help
</a>
<p class="text-small text-gosign-text-light mt-4">25 years of experience · 800+ extensions · AI-accelerated development</p>
</div>
</section>

<!-- Checklist -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Checklist: immediate steps after a hack</h2>
<ol class="space-y-3">
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 flex items-center justify-center bg-gosign-accent text-white font-bold rounded-full text-small">1</span>
<span class="text-body text-gosign-text pt-1">Take the website offline (maintenance mode)</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 flex items-center justify-center bg-gosign-accent text-white font-bold rounded-full text-small">2</span>
<span class="text-body text-gosign-text pt-1">Change all passwords (CMS, FTP, database, hosting)</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 flex items-center justify-center bg-gosign-accent text-white font-bold rounded-full text-small">3</span>
<span class="text-body text-gosign-text pt-1">Secure a backup (current state for forensics)</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 flex items-center justify-center bg-gosign-accent text-white font-bold rounded-full text-small">4</span>
<span class="text-body text-gosign-text pt-1">Identify the last clean backup</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 flex items-center justify-center bg-gosign-accent text-white font-bold rounded-full text-small">5</span>
<span class="text-body text-gosign-text pt-1">Run a malware scan</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 flex items-center justify-center bg-gosign-accent text-white font-bold rounded-full text-small">6</span>
<span class="text-body text-gosign-text pt-1">Identify the entry point (check logs)</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 flex items-center justify-center bg-gosign-accent text-white font-bold rounded-full text-small">7</span>
<span class="text-body text-gosign-text pt-1">Clean up and close the vulnerability</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 flex items-center justify-center bg-gosign-accent text-white font-bold rounded-full text-small">8</span>
<span class="text-body text-gosign-text pt-1">Bring the website back online</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 flex items-center justify-center bg-gosign-accent text-white font-bold rounded-full text-small">9</span>
<span class="text-body text-gosign-text pt-1">Google Search Console: request a review</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 flex items-center justify-center bg-gosign-accent text-white font-bold rounded-full text-small">10</span>
<span class="text-body text-gosign-text pt-1">Set up monitoring to prevent it from happening again</span>
</li>
</ol>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
Gosign is a Hamburg-based digital agency with 25 years of experience in web development, TYPO3 and AI integration.
We have analysed over 800 TYPO3 extensions and today develop with AI assistance
up to 70&nbsp;% faster than with traditional methods. Our clients include mid-market
enterprises, universities and public sector organisations across the EU.
</p>
<p class="text-small text-gosign-text-light mt-2">As of: February 2026</p>
</div>
</section>

<!-- Related Topics -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Related Topics</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/en/website-security-standards/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Security</p>
<p class="text-body font-semibold text-gosign-dark">Website Security Standards</p>
</a>
<a href="/en/typo3-security-monitor/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Monitoring</p>
<p class="text-body font-semibold text-gosign-dark">TYPO3 Security Monitor</p>
</a>
<a href="/en/wordpress-agency/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Web Development</p>
<p class="text-body font-semibold text-gosign-dark">WordPress Agency Hamburg</p>
</a>
</div>
</div>
</section>

--- Website Security Standards | Check | Gosign ---
> Is your website security-compliant? Security check for enterprises. Find vulnerabilities, meet NIS2 and GDPR requirements.

<!-- What do security standards require? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">What do security standards require for websites?</h2>
<p class="text-body text-gosign-text leading-relaxed">
The EU NIS2 Directive requires critical infrastructure operators (under NIS2) to implement adequate IT security measures. But organisations outside that scope should also align with recognised frameworks: BSI IT-Grundschutz (EU/DE), NIST Cybersecurity Framework (US), and NCSC Cyber Essentials (UK). Since NIS2 came into effect (2024), extended obligations apply across many sectors. Gosign checks your website against these security benchmarks.
</p>
</div>
</section>

<!-- Check Table -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">What Gosign checks in a website security audit</h2>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse bg-white rounded-card">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Area</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">What is checked</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Standard relevance</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">HTTPS/TLS configuration</td>
<td class="py-3 px-4 text-body text-gosign-text">Certificate, protocol version, cipher suites</td>
<td class="py-3 px-4 text-body text-gosign-text">Baseline</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Content Security Policy</td>
<td class="py-3 px-4 text-body text-gosign-text">CSP header, XSS protection</td>
<td class="py-3 px-4 text-body text-gosign-text">Baseline</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Server headers</td>
<td class="py-3 px-4 text-body text-gosign-text">X-Frame-Options, HSTS, Referrer-Policy</td>
<td class="py-3 px-4 text-body text-gosign-text">Baseline</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">CMS version &amp; extensions</td>
<td class="py-3 px-4 text-body text-gosign-text">Known vulnerabilities, end-of-life software</td>
<td class="py-3 px-4 text-body text-gosign-text">NIS2 / NIST CSF</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Cookie configuration</td>
<td class="py-3 px-4 text-body text-gosign-text">Secure flag, HttpOnly, SameSite</td>
<td class="py-3 px-4 text-body text-gosign-text">GDPR + NIS2</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Authentication</td>
<td class="py-3 px-4 text-body text-gosign-text">Login protection, brute-force prevention, 2FA</td>
<td class="py-3 px-4 text-body text-gosign-text">NIS2 / NIST CSF</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Data backup</td>
<td class="py-3 px-4 text-body text-gosign-text">Backup strategy, recovery testing</td>
<td class="py-3 px-4 text-body text-gosign-text">NIS2 / NIST CSF</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Services -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">Services</h2>
<div class="grid md:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">One-time security check</h3>
<p class="text-body text-gosign-text">
Automated plus manual review. Results report with prioritised recommendations, ranked by risk. AI-accelerated: results in hours, not weeks.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Continuous monitoring</h3>
<p class="text-body text-gosign-text">
Ongoing monitoring of CMS, extensions, server configuration. Immediate notification when new vulnerabilities are detected.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Hardening &amp; implementation</h3>
<p class="text-body text-gosign-text">
Gosign implements the recommended measures: CSP headers, TLS configuration, WAF setup, CMS hardening.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Audit documentation</h3>
<p class="text-body text-gosign-text">
Standards-compliant documentation of your website security measures. For internal audits and external reviewers.
</p>
</div>
</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Get your website security checked - 30&nbsp;minutes, free of charge.</h3>
<p class="text-body text-gosign-text mb-6">We analyse your website for security vulnerabilities, no obligation.</p>
<a
href="/en/contact/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Request a security check
</a>
<p class="text-small text-gosign-text-light mt-4">25 years of experience · 800+ extensions · AI-accelerated development</p>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
Gosign is a Hamburg-based digital agency with 25 years of experience in web development, TYPO3 and AI integration.
We have analysed over 800 TYPO3 extensions and today develop with AI assistance
up to 70&nbsp;% faster than with traditional methods. Our clients include mid-market
enterprises, universities and public sector organisations across the EU.
</p>
<p class="text-small text-gosign-text-light mt-2">As of: February 2026</p>
</div>
</section>

<!-- Related Topics -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Related Topics</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/en/website-hacked-10-reasons/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Security</p>
<p class="text-body font-semibold text-gosign-dark">Website Hacked: 10 Reasons</p>
</a>
<a href="/en/typo3-security-monitor/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Monitoring</p>
<p class="text-body font-semibold text-gosign-dark">TYPO3 Security Monitor</p>
</a>
<a href="/en/typo3-extensions/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">CMS</p>
<p class="text-body font-semibold text-gosign-dark">TYPO3 Extensions</p>
</a>
</div>
</div>
</section>

--- Build a Website with AI | Whitepaper ---
> Whitepaper: from web design to a working WordPress theme with AI. A practical guide by Gosign.

<!-- What does this whitepaper cover? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">What does this whitepaper cover?</h2>
<p class="text-body text-gosign-text leading-relaxed">
This Gosign whitepaper walks through the complete workflow of building a website with AI assistance: from concept and web design to a working WordPress theme. Not a theoretical overview, but a practical guide with specific tools, prompts and results from real client projects.
</p>
</div>
</section>

<!-- Contents overview -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">Contents overview</h2>

<div class="space-y-8">
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">1. AI in the web design process</h3>
<p class="text-body text-gosign-text leading-relaxed">
Layout generation, moodboard creation, wireframe-to-design with AI tools. What works, what does not, and where human design judgement remains essential.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">2. From design to code</h3>
<p class="text-body text-gosign-text leading-relaxed">
AI-assisted conversion of Figma/Sketch designs into HTML/CSS/PHP. How Gosign uses AI to generate theme scaffolding while senior developers refine the output.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">3. WordPress theme development with AI</h3>
<p class="text-body text-gosign-text leading-relaxed">
Custom Gutenberg blocks, Full Site Editing templates, functions.php logic - what AI generates in minutes that previously took days. A concrete before-and-after comparison.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">4. Quality assurance</h3>
<p class="text-body text-gosign-text leading-relaxed">
AI generates code, but who checks the quality? Gosign's QA process: automated tests, accessibility checks, performance audits, manual code review.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">5. Results from practice</h3>
<p class="text-body text-gosign-text leading-relaxed">
Time savings data from real Gosign projects: 60-80&nbsp;% faster. Where exactly the time is saved - and where it is not.
</p>
</div>
</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Want to use AI in your next web project?</h3>
<p class="text-body text-gosign-text mb-6">30 minutes initial consultation, free and no obligation.</p>
<a
href="/en/contact/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Book a consultation
</a>
<p class="text-small text-gosign-text-light mt-4">25 years of experience · 800+ extensions · AI-accelerated development</p>
</div>
</section>

<!-- Who is this for? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Who is this whitepaper for?</h2>
<ul class="space-y-3">
<li class="flex items-start gap-3">
<span class="flex-shrink-0 mt-1.5 w-2 h-2 bg-gosign-accent rounded-full"></span>
<span class="text-body text-gosign-text">Project managers and product owners who want to deliver web projects faster and more cost-effectively</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 mt-1.5 w-2 h-2 bg-gosign-accent rounded-full"></span>
<span class="text-body text-gosign-text">Marketing leaders evaluating AI-assisted website development</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 mt-1.5 w-2 h-2 bg-gosign-accent rounded-full"></span>
<span class="text-body text-gosign-text">Developers who want to integrate AI into their workflow</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 mt-1.5 w-2 h-2 bg-gosign-accent rounded-full"></span>
<span class="text-body text-gosign-text">Executives who want to understand the ROI of AI investment in web development</span>
</li>
</ul>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
Gosign is a Hamburg-based digital agency with 25 years of experience in web development, TYPO3 and AI integration.
We have analysed over 800 TYPO3 extensions and today develop with AI assistance
up to 70&nbsp;% faster than with traditional methods. Our clients include mid-market
enterprises, universities and public sector organisations across the EU.
</p>
<p class="text-small text-gosign-text-light mt-2">As of: February 2026</p>
</div>
</section>

<!-- Related Topics -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Related Topics</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/en/digital-agency-hamburg/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Web Development</p>
<p class="text-body font-semibold text-gosign-dark">Digital Agency Hamburg</p>
</a>
<a href="/en/wordpress-agency/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Web Development</p>
<p class="text-body font-semibold text-gosign-dark">WordPress Agency Hamburg</p>
</a>
<a href="/en/website-security-standards/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Security</p>
<p class="text-body font-semibold text-gosign-dark">Website Security Standards</p>
</a>
</div>
</div>
</section>

--- Why Gosign - EU AI Act, Self-Hosted, EU-first ---
> Three architecture decisions: EU AI Act ready, your infrastructure, EU-first. No SaaS dependency, no cloud vendor risk.

<!-- USP 1: EU AI Act ready -->
<section id="eu-ai-act" class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<div class="flex items-center gap-3 mb-6">
<svg class="w-10 h-10 text-gosign-accent-text" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<h2 class="text-h1 font-bold text-gosign-dark">EU AI Act ready</h2>
</div>
<p class="text-body-lg text-gosign-dark font-semibold">Every agent decision traceable. For employee representatives. For regulators. For you.</p>
<p class="text-body text-gosign-text-light mt-4">HR agents fall under Article 6 of the EU AI Act: employment context means high-risk classification. The central question is not whether, but how every decision is documented - who decided, why, with what confidence score.</p>
<p class="text-body text-gosign-text-light mt-4">Gosign agents make every decision transparent - architecturally, not retroactively:</p>
<ul class="mt-4 space-y-3">
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text mt-0.5 flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" /></svg>
<span class="text-body text-gosign-text-light"><strong class="text-gosign-dark">Art. 9 Risk management</strong> - The Decision Layer defines for every process step in advance: human, rule engine, or AI. Risk assessment is architecture, not a retrospective audit project.</span>
</li>
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text mt-0.5 flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" /></svg>
<span class="text-body text-gosign-text-light"><strong class="text-gosign-dark">Art. 12 Record-keeping</strong> - Every agent decision as a decision act in the Audit Trail: input, applied rule including version, confidence score, result, and contestation path - the record per micro-decision.</span>
</li>
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text mt-0.5 flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" /></svg>
<span class="text-body text-gosign-text-light"><strong class="text-gosign-dark">Art. 13 Transparency</strong> - Employee representation bodies (such as works councils in Germany or staff committees elsewhere) can verify every agent decision through the Auditor Portal - without IT involvement, without database access.</span>
</li>
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text mt-0.5 flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" /></svg>
<span class="text-body text-gosign-text-light"><strong class="text-gosign-dark">Art. 14 Human oversight</strong> - Human-in-the-Loop as an architecture principle, not an optional feature. Humans remain in the process where labor law, anti-discrimination requirements, or employee representation rights demand it - not because they perform better, but because they must.</span>
</li>
</ul>
<p class="text-body text-gosign-text-light mt-6">Whether your organization operates under EU AI regulation, UK AI guidance, or sector-specific compliance (GxP, financial services) - the Decision Layer provides the governance infrastructure. (UK: The UK follows a pro-innovation, sector-specific approach rather than the EU AI Act. Gosign agents meet both frameworks.)</p>
<p class="text-body text-gosign-text-light mt-4">Decision transparency is not a retrospective compliance project. It is built into the Decision Layer - from the first pilot.</p>
<p class="text-body text-gosign-text-light mt-4">Deep dive: <a href="/en/magazine/eu-ai-act-applies-worldwide/" class="text-gosign-accent-text hover:underline">Why the EU AI Act applies worldwide - and what it means for your organization</a></p>
</div>
</div>
</section>

<!-- USP 2: Your infrastructure -->
<section id="infrastructure" class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<div class="flex items-center gap-3 mb-6">
<svg class="w-10 h-10 text-gosign-accent-text" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<h2 class="text-h1 font-bold text-gosign-dark">Your infrastructure</h2>
</div>
<p class="text-body-lg text-gosign-dark font-semibold">In your data center. Under your control.</p>
<p class="text-body text-gosign-text-light mt-4">Gosign AI Agents are not a SaaS product. They run in your infrastructure - on-premises, private cloud, or hybrid. Data never leaves your systems.</p>
<p class="text-body text-gosign-text-light mt-4">Data residency as an architecture decision. Your board needs to know where employee data is processed. With self-hosting, the answer is simple: in your data center. GDPR-compliant by design, not by vendor promise. (UK: UK GDPR, substantively identical.) (US: Aligned with CCPA/CPRA and sector-specific requirements.)</p>
<div class="grid grid-cols-1 md:grid-cols-3 gap-6 mt-8">
<div class="border border-gosign-border rounded-card p-6 bg-gosign-white">
<p class="text-sm font-bold text-gosign-accent-text uppercase tracking-wider">Source code</p>
<p class="text-body text-gosign-text-light mt-2">Full access. You can operate the agent without Gosign at any time. No vendor lock-in.</p>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-gosign-white">
<p class="text-sm font-bold text-gosign-accent-text uppercase tracking-wider">Model-agnostic</p>
<p class="text-body text-gosign-text-light mt-2">You choose the LLM - not us. OpenAI, Anthropic, local models. No lock-in to any single provider.</p>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-gosign-white">
<p class="text-sm font-bold text-gosign-accent-text uppercase tracking-wider">GDPR native</p>
<p class="text-body text-gosign-text-light mt-2">Data residency as an architecture decision. Not a retrofitted feature. No data leaves your infrastructure.</p>
</div>
</div>
<p class="text-body text-gosign-text-light mt-6">Multi-jurisdiction deployment: whether you operate across EU member states, the UK, or globally - one agent framework, consistent governance, local rule sets per jurisdiction. No reconfiguration for each country.</p>
</div>
</div>
</section>

<!-- USP 3: EU-first -->
<section id="eu-first" class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<div class="flex items-center gap-3 mb-6">
<svg class="w-10 h-10 text-gosign-accent-text" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<h2 class="text-h1 font-bold text-gosign-dark">EU-first</h2>
</div>
<p class="text-body-lg text-gosign-dark font-semibold">No US product with an EU patch. EU regulation is the baseline.</p>
<p class="text-body text-gosign-text-light mt-4">Most AI products are built for the US market and retrofitted for EU regulation. GDPR as a checkbox, co-determination (Mitbestimmung) as a cultural curiosity, data residency as an optional feature.</p>
<p class="text-body text-gosign-text-light mt-4">Gosign agents are built the other way around: data stays in your infrastructure - no US cloud dependency. GDPR is an architecture principle, not a checkbox. Built for the most demanding regulatory environment in the world - if it passes there, it passes everywhere.</p>
<p class="text-body text-gosign-text-light mt-4">What this means in practice:</p>
<ul class="mt-4 space-y-3">
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text mt-0.5 flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" /></svg>
<span class="text-body text-gosign-text-light"><strong class="text-gosign-dark">No US cloud dependency</strong>. Data stays in your infrastructure - no CLOUD Act exposure, no Schrems III risk, no cross-border transfer issues.</span>
</li>
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text mt-0.5 flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" /></svg>
<span class="text-body text-gosign-text-light"><strong class="text-gosign-dark">GDPR as an architecture principle</strong>, not a retrofit. Data residency, deletion concepts, and access controls are embedded in the architecture from day one.</span>
</li>
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text mt-0.5 flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" /></svg>
<span class="text-body text-gosign-text-light"><strong class="text-gosign-dark">Collective agreements as deterministic rules</strong> in the Decision Layer. Industry-level and company-level agreements are implemented as rule engines, not free-text fields.</span>
</li>
</ul>
<p class="text-body text-gosign-text-light mt-6">You should not be a footnote in an American product. EU regulation as a design principle means: built for your regulatory reality, not patched onto someone else's.</p>
<p class="text-body text-gosign-text-light mt-4">Deep dive: <a href="/en/magazine/shadow-ai-governance/" class="text-gosign-accent-text hover:underline">Shadow AI in the enterprise - governance instead of prohibition</a></p>
</div>
</div>
</section>

<!-- Deep Dive in the Agent Briefing -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">Deep Dive in the Agent Briefing (Gosign Magazine)</h2>
<div class="grid grid-cols-1 md:grid-cols-3 gap-6">
<a href="/en/magazine/eu-ai-act-applies-worldwide/" class="block border border-gosign-border rounded-card p-6 bg-gosign-white hover:border-gosign-accent transition-colors">
<p class="text-xs font-bold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<p class="text-h3 font-bold text-gosign-dark">EU AI Act applies worldwide</p>
</a>
<a href="/en/magazine/eu-ai-act-hr/" class="block border border-gosign-border rounded-card p-6 bg-gosign-white hover:border-gosign-accent transition-colors">
<p class="text-xs font-bold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<p class="text-h3 font-bold text-gosign-dark">EU AI Act and HR</p>
</a>
<a href="/en/magazine/agent-governance-hr/" class="block border border-gosign-border rounded-card p-6 bg-gosign-white hover:border-gosign-accent transition-colors">
<p class="text-xs font-bold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<p class="text-h3 font-bold text-gosign-dark">Agent governance for HR</p>
</a>
</div>
</div>
</section>

--- WordPress Agency Hamburg | Gosign | Since 1999 ---
> WordPress agency based in Hamburg: development, maintenance and AI-accelerated projects. 25 years of experience. Free consultation.

<!-- What does Gosign offer? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">What does Gosign offer as a WordPress agency?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Gosign is a Hamburg-based WordPress agency with 25&nbsp;years of experience in web development. Gosign builds WordPress websites for B2B companies: custom themes, plugin development, WooCommerce shops, headless WordPress with modern frontends. Since 2023, Gosign uses AI-assisted development. WordPress projects are delivered 60-80&nbsp;% faster at the same quality level.
</p>
</div>
</section>

<!-- Why Gosign -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Why Gosign instead of a pure WordPress agency?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Because WordPress is only part of the picture. Gosign knows TYPO3, headless architectures and AI infrastructure - and gives honest advice on whether WordPress is the right choice. For content sites: almost always yes. For enterprise portals with complex permissions: perhaps TYPO3.
</p>
</div>
</section>

<!-- WordPress Services -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">WordPress Services</h2>
<div class="grid md:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Custom Theme Development</h3>
<p class="text-body text-gosign-text">
No off-the-shelf templates. Gosign develops WordPress themes exactly to design specifications - responsive, performant, accessible. Gutenberg-optimised, Full Site Editing ready. AI generates theme scaffolding, senior developers refine.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Plugin Development &amp; Customisation</h3>
<p class="text-body text-gosign-text">
Custom plugins for your business logic. Extend, adapt or replace existing plugins with more secure custom solutions. AI accelerates plugin development by 70&nbsp;%.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">WooCommerce &amp; E-Commerce</h3>
<p class="text-body text-gosign-text">
Online shops with WooCommerce: product catalogues, payment integration, shipping logic, voucher systems. The right platform for shops with up to ~50,000 products.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">WordPress Maintenance &amp; Security</h3>
<p class="text-body text-gosign-text">
Updates, backups, security monitoring, performance optimisation. Proactive maintenance instead of reactive repair. Gosign monitors over 800 extensions and knows vulnerabilities before they are exploited.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6 md:col-span-2">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">WordPress Migration</h3>
<p class="text-body text-gosign-text">
Migrate from TYPO3, Joomla, Drupal or Webflow to WordPress. Content transfer, SEO redirect mapping, design overhaul. AI-assisted content migration saves weeks.
</p>
</div>
</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Discuss your WordPress project - 30&nbsp;minutes, free of charge.</h3>
<p class="text-body text-gosign-text mb-6">We analyse your project, estimate effort and timeline, no obligation.</p>
<a
href="/en/contact/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Book a call
</a>
<p class="text-small text-gosign-text-light mt-4">25 years of experience · 800+ extensions · AI-accelerated development</p>
</div>
</section>

<!-- AI Table -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">AI-accelerated WordPress development: 70&nbsp;% faster</h2>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Task</th>
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Traditional</th>
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">With AI</th>
<th class="py-3 text-small font-bold text-gosign-dark">Savings</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Custom theme (10 templates)</td>
<td class="py-3 pr-4 text-body text-gosign-text">3-4 weeks</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">1-1.5 weeks</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">65&nbsp;%</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Custom plugin</td>
<td class="py-3 pr-4 text-body text-gosign-text">2-3 weeks</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">4-6 days</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">70&nbsp;%</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">WooCommerce shop setup</td>
<td class="py-3 pr-4 text-body text-gosign-text">2-3 weeks</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">5-7 days</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">65&nbsp;%</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Content migration (500 pages)</td>
<td class="py-3 pr-4 text-body text-gosign-text">2 weeks</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">3 days</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">80&nbsp;%</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Security audit</td>
<td class="py-3 pr-4 text-body text-gosign-text">3 days</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">1 day</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">70&nbsp;%</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Comparison Table -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">WordPress vs. TYPO3 vs. Headless: honest advice</h2>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse bg-white rounded-card">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Criterion</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">WordPress</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">TYPO3</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Headless (Astro, Next.js)</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Content focus</td>
<td class="py-3 px-4 text-body text-gosign-text">Ideal</td>
<td class="py-3 px-4 text-body text-gosign-text">Good</td>
<td class="py-3 px-4 text-body text-gosign-text">More complex</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Enterprise permissions</td>
<td class="py-3 px-4 text-body text-gosign-text">Limited</td>
<td class="py-3 px-4 text-body text-gosign-text">Granular</td>
<td class="py-3 px-4 text-body text-gosign-text">Custom</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">E-commerce</td>
<td class="py-3 px-4 text-body text-gosign-text">WooCommerce</td>
<td class="py-3 px-4 text-body text-gosign-text">aimeos</td>
<td class="py-3 px-4 text-body text-gosign-text">Shopify API</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Performance</td>
<td class="py-3 px-4 text-body text-gosign-text">Plugin-dependent</td>
<td class="py-3 px-4 text-body text-gosign-text">Requires caching</td>
<td class="py-3 px-4 text-body text-gosign-accent-text font-semibold">Static = fast</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Editor-friendliness</td>
<td class="py-3 px-4 text-body text-gosign-text">Excellent</td>
<td class="py-3 px-4 text-body text-gosign-text">Good</td>
<td class="py-3 px-4 text-body text-gosign-text">Limited</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Gosign recommendation</td>
<td class="py-3 px-4 text-body text-gosign-accent-text font-semibold">Content sites, blogs, SMEs</td>
<td class="py-3 px-4 text-body text-gosign-accent-text font-semibold">Enterprise, universities</td>
<td class="py-3 px-4 text-body text-gosign-accent-text font-semibold">Performance-critical</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
Gosign is a Hamburg-based digital agency with 25 years of experience in web development, TYPO3 and AI integration.
We have analysed over 800 TYPO3 extensions and today develop with AI assistance
up to 70&nbsp;% faster than with traditional methods. Our clients include mid-market
enterprises, universities and public sector organisations across the EU.
</p>
<p class="text-small text-gosign-text-light mt-2">As of: February 2026</p>
</div>
</section>

<!-- Related Topics -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Related Topics</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/en/digital-agency-hamburg/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Web Development</p>
<p class="text-body font-semibold text-gosign-dark">Digital Agency Hamburg</p>
</a>
<a href="/en/website-hacked-10-reasons/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Security</p>
<p class="text-body font-semibold text-gosign-dark">Website Hacked: 10 Reasons</p>
</a>
<a href="/en/website-security-standards/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Security</p>
<p class="text-body font-semibold text-gosign-dark">Website Security Standards</p>
</a>
</div>
</div>
</section>


============================================================
LANGUAGE: ES
============================================================

--- Agencia digital Hamburgo | Web, IA, TYPO3 ---
> Gosign es una agencia digital de Hamburgo: desarrollo web, integración de IA y TYPO3. 25 años de experiencia. Enfoque B2B.

<!-- ¿Qué es Gosign? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">¿Qué es Gosign?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Gosign es una agencia digital con sede en Hamburgo y 25&nbsp;años de experiencia en desarrollo web, sistemas TYPO3 e integración de IA para empresas. Fundada en 1999, hoy está especializada en sitios web B2B, proyectos CMS Enterprise e infraestructuras de IA. Gosign atiende a empresas medianas, universidades e instituciones públicas en Europa.
</p>
</div>
</section>

<!-- ¿Por qué Gosign? -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">¿Por qué Gosign?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Porque no solo construimos sitios web, sino infraestructura digital. Tres áreas clave, un equipo:
</p>
</div>
</section>

<!-- Desarrollo web y CMS -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Desarrollo web y CMS</h2>
<p class="text-body text-gosign-text leading-relaxed">
Sitios web que rinden. Técnica y comercialmente. TYPO3, WordPress, Astro, arquitecturas Headless. Desde la concepción hasta el lanzamiento, de 10&nbsp;páginas a 10.000. Gosign ha analizado más de 800 extensiones TYPO3 y desarrolla proyectos CMS Enterprise desde hace dos décadas.
</p>
</div>
</section>

<!-- Integración de IA -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Integración de IA para empresas</h2>
<p class="text-body text-gosign-text leading-relaxed">
Infraestructuras de IA directamente en su entorno corporativo: asistentes de IA, agentes de IA, alojamiento de modelos (DeepSeek, Llama, Mistral) en su propia infraestructura. Conforme al RGPD, conforme al ENS, sin fuga de datos a terceros. Gosign construye soluciones de IA que se integran en entornos IT existentes.
</p>
</div>
</section>

<!-- Especialización TYPO3 -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Especialización en TYPO3</h2>
<p class="text-body text-gosign-text leading-relaxed">
Más de 800 extensiones TYPO3 monitorizadas, más de 500 implementadas con éxito. Desde búsqueda Enterprise con Solr hasta integración SSO y e-commerce con aimeos. Gosign es uno de los proveedores TYPO3 con más experiencia en Europa.
</p>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Hablemos de su proyecto: 30&nbsp;minutos, gratis.</h3>
<p class="text-body text-gosign-text mb-6">Analizamos su proyecto, estimamos esfuerzo y plazos, sin compromiso.</p>
<a
href="/es/contacto/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Reservar cita
</a>
<p class="text-small text-gosign-text-light mt-4">25 años de experiencia · 800+ extensiones · Desarrollo acelerado por IA</p>
</div>
</section>

<!-- Comparison Table -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Qué diferencia a Gosign de otras agencias digitales</h2>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Criterio</th>
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Agencia típica</th>
<th class="py-3 text-small font-bold text-gosign-dark">Gosign</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Profundidad CMS</td>
<td class="py-3 pr-4 text-body text-gosign-text">WordPress básico</td>
<td class="py-3 text-body text-gosign-text">TYPO3 Enterprise + WordPress + Headless</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Competencia en IA</td>
<td class="py-3 pr-4 text-body text-gosign-text">Prompts de ChatGPT</td>
<td class="py-3 text-body text-gosign-text">Infraestructuras de IA propias, alojamiento de modelos</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Velocidad de desarrollo</td>
<td class="py-3 pr-4 text-body text-gosign-text">Clasica</td>
<td class="py-3 text-body text-gosign-accent-text font-semibold">Acelerada por IA: 60-80&nbsp;% más rápido</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Enfoque sectorial</td>
<td class="py-3 pr-4 text-body text-gosign-text">Todo para todos</td>
<td class="py-3 text-body text-gosign-text">B2B, empresas medianas, universidades, sector público</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Seguridad</td>
<td class="py-3 pr-4 text-body text-gosign-text">Hosting estándar</td>
<td class="py-3 text-body text-gosign-text">Infraestructuras conformes al ENS, monitorización de seguridad</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Ubicación</td>
<td class="py-3 pr-4 text-body text-gosign-text">Remoto/Global</td>
<td class="py-3 text-body text-gosign-text">Hamburgo, atencion personalizada</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Sectores -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Sectores</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
Gosign trabaja para empresas que se toman en serio la infraestructura digital:
</p>
<div class="grid md:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Maquinaria e industria</h3>
<p class="text-body text-gosign-text">Sitios web B2B con configuradores de producto, portales de distribuidores, documentación técnica</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Automoción</h3>
<p class="text-body text-gosign-text">Portales de marca, redes de concesionarios, showrooms digitales</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Salud y farmacia</h3>
<p class="text-body text-gosign-text">Sitios web conformes a normativa, portales de pacientes</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Educación y universidades</h3>
<p class="text-body text-gosign-text">SSO con Shibboleth, buscadores de programas, sitios web accesibles</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Asociaciones y sector público</h3>
<p class="text-body text-gosign-text">Gestión de socios, portales multilingües, accesibilidad</p>
</div>
</div>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
Gosign es una agencia digital con sede en Hamburgo y 25 años de experiencia en desarrollo web, TYPO3 e integración de IA.
Hemos analizado más de 800 extensiones TYPO3 y hoy desarrollamos con apoyo de IA
hasta un 70&nbsp;% más rápido que con métodos tradicionales. Nuestros clientes son empresas
medianas, universidades e instituciones europeas.
</p>
<p class="text-small text-gosign-text-light mt-2">Actualizado: febrero 2026</p>
</div>
</section>

<!-- Temas relacionados -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Temas relacionados</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/es/agencia-wordpress/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Desarrollo web</p>
<p class="text-body font-semibold text-gosign-dark">Agencia WordPress Hamburgo</p>
</a>
<a href="/es/typo3-extensions/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">CMS</p>
<p class="text-body font-semibold text-gosign-dark">Extensiones TYPO3</p>
</a>
<a href="/es/seguridad-web-estandares/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Seguridad</p>
<p class="text-body font-semibold text-gosign-dark">Seguridad web según estándares europeos</p>
</a>
</div>
</div>
</section>

--- Agencia WordPress Hamburgo | Desde 1999 ---
> Agencia WordPress en Hamburgo: desarrollo, mantenimiento y proyectos acelerados por IA. 25 años de experiencia. Consulta gratuita.

<!-- ¿Qué ofrece Gosign? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">¿Qué ofrece Gosign como agencia WordPress?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Gosign es una agencia WordPress con sede en Hamburgo y 25&nbsp;años de experiencia en desarrollo web. Gosign desarrolla sitios WordPress para empresas B2B: temas personalizados, desarrollo de plugins, tiendas WooCommerce, WordPress Headless con frontends modernos. Desde 2023, Gosign utiliza desarrollo asistido por IA. Los proyectos WordPress se realizan un 60-80&nbsp;% más rápido manteniendo la misma calidad.
</p>
</div>
</section>

<!-- ¿Por qué Gosign? -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">¿Por qué Gosign en lugar de una agencia solo WordPress?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Porque WordPress es solo una parte del panorama. Gosign conoce TYPO3, arquitecturas Headless e infraestructuras de IA y asesora con honestidad sobre si WordPress es la elección correcta. Para sitios de contenido: casi siempre sí. Para portales Enterprise con permisos complejos: quizás TYPO3.
</p>
</div>
</section>

<!-- Servicios WordPress -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">Servicios WordPress</h2>
<div class="grid md:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Desarrollo de temas personalizados</h3>
<p class="text-body text-gosign-text">
Sin plantillas prefabricadas. Gosign desarrolla temas WordPress exactamente según las especificaciones de diseño, responsive, con alto rendimiento y accesibles. Optimizados para Gutenberg, preparados para Full Site Editing. La IA genera la estructura base del tema, desarrolladores senior perfeccionan.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Desarrollo y personalización de plugins</h3>
<p class="text-body text-gosign-text">
Plugins personalizados para su lógica de negocio. Extender plugins existentes, adaptarlos o sustituirlos por desarrollos propios más seguros. La IA acelera el desarrollo de plugins un 70&nbsp;%.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">WooCommerce y e-commerce</h3>
<p class="text-body text-gosign-text">
Tiendas online con WooCommerce: catálogos de productos, integración de pagos, lógica de envíos, sistemas de cupones. La plataforma adecuada para tiendas de hasta ~50.000 productos.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Mantenimiento y seguridad WordPress</h3>
<p class="text-body text-gosign-text">
Actualizaciones, copias de seguridad, monitorización de seguridad, optimización de rendimiento. Mantenimiento proactivo en lugar de reparación reactiva. Gosign monitoriza más de 800 extensiones y conoce las vulnerabilidades antes de que sean explotadas.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6 md:col-span-2">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Migración a WordPress</h3>
<p class="text-body text-gosign-text">
Migrar de TYPO3, Joomla, Drupal o Webflow a WordPress. Traspaso de contenido, mapeo de redirecciones SEO, rediseño. La migración de contenido asistida por IA ahorra semanas.
</p>
</div>
</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Hablar sobre su proyecto WordPress: 30&nbsp;minutos, gratis.</h3>
<p class="text-body text-gosign-text mb-6">Analizamos su proyecto, estimamos esfuerzo y plazos, sin compromiso.</p>
<a
href="/es/contacto/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Reservar cita
</a>
<p class="text-small text-gosign-text-light mt-4">25 años de experiencia · 800+ extensiones · Desarrollo acelerado por IA</p>
</div>
</section>

<!-- KI Table -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Desarrollo WordPress acelerado por IA: 70&nbsp;% más rápido</h2>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Tarea</th>
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Clásico</th>
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Con IA</th>
<th class="py-3 text-small font-bold text-gosign-dark">Ahorro</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Tema personalizado (10 plantillas)</td>
<td class="py-3 pr-4 text-body text-gosign-text">3-4 semanas</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">1-1,5 semanas</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">65&nbsp;%</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Plugin personalizado</td>
<td class="py-3 pr-4 text-body text-gosign-text">2-3 semanas</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">4-6 días</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">70&nbsp;%</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Configuración tienda WooCommerce</td>
<td class="py-3 pr-4 text-body text-gosign-text">2-3 semanas</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">5-7 días</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">65&nbsp;%</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Migración de contenido (500 páginas)</td>
<td class="py-3 pr-4 text-body text-gosign-text">2 semanas</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">3 días</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">80&nbsp;%</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Auditoría de seguridad</td>
<td class="py-3 pr-4 text-body text-gosign-text">3 días</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">1 día</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">70&nbsp;%</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Comparison Table -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">WordPress vs. TYPO3 vs. Headless: asesoría honesta</h2>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse bg-white rounded-card">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Criterio</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">WordPress</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">TYPO3</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Headless (Astro, Next.js)</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Enfoque en contenido</td>
<td class="py-3 px-4 text-body text-gosign-text">Ideal</td>
<td class="py-3 px-4 text-body text-gosign-text">Bueno</td>
<td class="py-3 px-4 text-body text-gosign-text">Más complejo</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Permisos Enterprise</td>
<td class="py-3 px-4 text-body text-gosign-text">Limitado</td>
<td class="py-3 px-4 text-body text-gosign-text">Granular</td>
<td class="py-3 px-4 text-body text-gosign-text">Personalizado</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">E-commerce</td>
<td class="py-3 px-4 text-body text-gosign-text">WooCommerce</td>
<td class="py-3 px-4 text-body text-gosign-text">aimeos</td>
<td class="py-3 px-4 text-body text-gosign-text">Shopify API</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Rendimiento</td>
<td class="py-3 px-4 text-body text-gosign-text">Depende de plugins</td>
<td class="py-3 px-4 text-body text-gosign-text">Requiere caché</td>
<td class="py-3 px-4 text-body text-gosign-accent-text font-semibold">Estático = rápido</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Facilidad para editores</td>
<td class="py-3 px-4 text-body text-gosign-text">Excelente</td>
<td class="py-3 px-4 text-body text-gosign-text">Buena</td>
<td class="py-3 px-4 text-body text-gosign-text">Limitada</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Recomendación Gosign</td>
<td class="py-3 px-4 text-body text-gosign-accent-text font-semibold">Sitios de contenido, blogs, pymes</td>
<td class="py-3 px-4 text-body text-gosign-accent-text font-semibold">Enterprise, universidades</td>
<td class="py-3 px-4 text-body text-gosign-accent-text font-semibold">Crítico en rendimiento</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
Gosign es una agencia digital con sede en Hamburgo y 25 años de experiencia en desarrollo web, TYPO3 e integración de IA.
Hemos analizado más de 800 extensiones TYPO3 y hoy desarrollamos con apoyo de IA
hasta un 70&nbsp;% más rápido que con métodos tradicionales. Nuestros clientes son empresas
medianas, universidades e instituciones europeas.
</p>
<p class="text-small text-gosign-text-light mt-2">Actualizado: febrero 2026</p>
</div>
</section>

<!-- Temas relacionados -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Temas relacionados</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/es/agencia-digital-hamburg/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Desarrollo web</p>
<p class="text-body font-semibold text-gosign-dark">Agencia digital en Hamburgo</p>
</a>
<a href="/es/sitio-web-hackeado-10-razones/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Seguridad</p>
<p class="text-body font-semibold text-gosign-dark">Sitio web hackeado: 10 razones</p>
</a>
<a href="/es/seguridad-web-estandares/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Seguridad</p>
<p class="text-body font-semibold text-gosign-dark">Seguridad web según estándares europeos</p>
</a>
</div>
</div>
</section>

--- Agentes IA para Empresas en Alemania | Gosign ---
> Enterprise AI Agents para empresas alemanas. RGPD conforme, EU AI Act compliant, compatible con comité de empresa. Sede en Hamburgo, oficina en Berlín.

## Alemania es el mercado doméstico de Gosign y el mercado UE con mayor densidad de cumplimiento

Alemania combina tres características que en esta forma no existen en ningún otro país de la UE: máxima densidad corporativa en varios sectores, un derecho vinculante de cogestión del comité de empresa alemán (Betriebsrat) según § 87 Abs. 1 Nr. 6 BetrVG, y una estructura federal de supervisión con BaFin, BSI, BfDI y dieciséis autoridades estatales adicionales de protección de datos. El paisaje corporativo abarca desde automoción (VW, BMW, Daimler, Porsche, Continental, Bosch, ZF) pasando por química (BASF, Bayer, Evonik, Merck, Covestro), ingeniería mecánica (Siemens, Trumpf, Dürr, Kuka, Festo), banca (Deutsche Bank, Commerzbank, Sparkassen, Volks- und Raiffeisenbanken), seguros (Allianz, Munich Re, Ergo, HDI, R+V), energía (RWE, E.ON, EnBW) hasta retail (Otto, Zalando, Lidl/Kaufland, Rewe, Edeka). Gosign forma parte de este mercado con sede central en Hamburgo y oficina en Berlín - y exactamente para eso está construida la arquitectura. Para empresas españolas con matrices o filiales en Alemania, este es el mercado donde la IA debe pasar su prueba de fuego regulatoria antes de escalarla a Madrid o Barcelona.

## Los tres obstáculos regulatorios para la IA en el mercado alemán

Primero, la Betriebsverfassungsgesetz: § 87 Abs. 1 Nr. 6 BetrVG otorga al comité de empresa alemán un derecho de cogestión en la introducción de sistemas técnicos que puedan vigilar el comportamiento o el rendimiento de los trabajadores. Los sistemas IA en RR.HH., planificación de turnos, evaluación de desempeño, routing de service-desk - todos caen bajo ese régimen. Una implementación productiva sin convenio de empresa no es jurídicamente sostenible en corporaciones alemanas. El Decision Layer con Human-in-the-Loop forzado no es aquí un feature de arquitectura, sino condición para que el comité de empresa dé su conformidad. Para comparar: el Comité de Empresa español (Art. 64 ET) tiene derechos de información y consulta, sin veto - Alemania va un paso más allá.

Segundo, RGPD y BDSG con la supervisión federal de protección de datos: BfDI en el Bund, más dieciséis delegados estatales de protección de datos, más los requisitos específicos de la Ley Federal de Protección de Datos. En decisiones automatizadas bajo el Art. 22 RGPD, las autoridades alemanas esperan bases jurídicas documentadas, explicaciones recuperables y Audit Trail completo. La especificidad alemana: la evaluación de impacto de protección de datos debe estar completada antes de la puesta en marcha de aplicaciones high-risk, no en paralelo al rollout.

Tercero, BaFin, BSI, BNetzA y el EU AI Act: BaFin supervisa el sector financiero y espera en AML, KYC, scoring crediticio y gestión de siniestros decisión humana final demostrable en casos de riesgo. BSI define las exigencias mínimas de seguridad IT para empresas KRITIS. El EU AI Act se transpondrá en Alemania mediante la ley de ejecución en preparación - con foco en aplicaciones high-risk en RR.HH., banca, seguros e infraestructura crítica. Quien arranca sin Cert-Ready by Design construye sobre una arquitectura que deberá reforzarse a más tardar en la primera auditoría BaFin.

## Escenarios típicos de implementación en Alemania

Allianz y Munich Re - gestión de siniestros: los líderes aseguradores alemanes procesan diariamente miles de siniestros. Workflow Agents clasifican siniestros entrantes por póliza, región y complejidad, el Decision Layer enruta casos de riesgo a peritos humanos, y el Audit Trail documenta cada decisión para auditoría interna y BaFin.

Commerzbank y Sparkassen - AML Operations: con millones de transacciones diarias, los Document Agents verifican identificadores, el Decision Layer enruta sospechas según umbrales BaFin, con Human-in-the-Loop en cada escalación final.

VW, BMW y Daimler - HR Operations: las corporaciones automotrices alemanas tienen cientos de miles de empleados y procesos RR.HH. correspondientemente complejos. Workflow Agents soportan reclutamiento y movilidad interna, con decisión humana final forzada en medidas de personal - condición ineludible para aceptación del comité de empresa alemán según § 87 BetrVG.

BASF y Bayer - documentación de producción: los grupos químicos alemanes generan diariamente enormes volúmenes de documentación de seguridad y calidad. Document Agents extraen especificaciones regulatoriamente relevantes, las contrastan con REACH, CLP y requisitos CE, con Audit Trail completo hasta el PR fuente.

## Cómo Gosign atiende Alemania desde Hamburgo y Berlín

Gosign tiene sede central en Hamburgo (Hallerstraße 8) y oficina en Berlín (Nogatstraße 46), más un centro de formación en Hamburgo en Grindelberg 77. Los Discovery Workshops se celebran in situ en el cliente - en Múnich, Frankfurt, Stuttgart, Düsseldorf, Colonia, Hannover o directamente en Hamburgo y Berlín. Después el Build corre en remoto, con documentación alemana, Sprint Reviews semanales en videoconferencia, un interlocutor fijo y visitas presenciales cada cuatro a seis semanas. Las citas con comité de empresa, delegados de protección de datos y funciones de compliance son componentes fijos de cada proyecto. Las citas presenciales con BaFin, BSI o autoridades estatales de protección de datos las acompaña Gosign a petición junto con el departamento jurídico interno. Para clientes españoles con matriz alemana, coordinación Barcelona + Hamburgo con documentación paralela ES/DE.

## Por qué Alemania funciona como punto de partida para Enterprise AI

Alemania no es el mercado UE más fácil, pero sí el más duro para cumplimiento Enterprise AI. Precisamente eso lo convierte en el mejor punto de partida. Quien construye un AI Agent que satisface RGPD, BDSG, BetrVG, exigencias BaFin y BSI y el EU AI Act, ha desarrollado una arquitectura que en cualquier otro país UE está a un mero cambio de configuración. La cultura de cumplimiento alemana y la cogestión del comité de empresa alemán imponen Governance by Design - ningún otro país UE lo exige con esta consecuencia. Para clientes españoles, la fórmula es clara: una arquitectura que pasa BaFin pasa AEPD, CNMV y AESIA con ajustes menores. Una solución pactada con el comité de empresa alemán se negocia después con el Comité de Empresa español sin rebuild arquitectónico. Gosign es como empresa hamburguesa parte de este mercado - la arquitectura no viene del libro de texto, sino de proyectos en corporaciones alemanas cuyas expectativas de auditoría han definido cada primer día productivo. Cert-Ready by Design aquí no es argumento de venta, sino necesidad constructiva. Más contexto sobre el [EU AI Act](/es/governance/eu-ai-act/) en el área de Governance.

--- Agentes IA para Empresas en Amsterdam | Gosign ---
> Enterprise AI Agents para Amsterdam y los Países Bajos. RGPD conforme, EU AI Act ready, alineado con Dutch AI Coalition. IA auditable.

## Amsterdam es el único mercado europeo donde escalado tecnológico y supervisión bancaria comparten el mismo código postal

Pocas ciudades europeas combinan tan densamente Big Tech y banca sistémica como Amsterdam. ING, ABN AMRO y Rabobank tienen aquí sus sedes corporativas, mientras Adyen, Booking.com, TomTom y Prosus han convertido la ciudad en el segundo mayor mercado tech-cotizado tras Londres. En el cinturón industrial se sitúan Philips en Eindhoven y ASML en Veldhoven - la región Brainport complementa la plaza financiera de Amsterdam con competencia industrial high-tech. Heineken, Shell NL y KLM forman el núcleo industrial tradicional, mientras startups como Bunq y Mollie definen el panorama fintech. Quien introduce IA aquí construye para un público que entiende tanto las rutas de reclamación PSD2 como la ISO/IEC 42001. Precisamente esta mezcla convierte Amsterdam en una de las pruebas de aceptación más duras para Enterprise AI en Europa - y en un mercado de interés directo para empresas españolas con operaciones en Benelux.

## Los tres obstáculos regulatorios para la IA en el mercado de Amsterdam

Primero, la Autoriteit Persoonsgegevens (AP) - la autoridad neerlandesa de protección de datos es una de las más contundentes de la UE en ejecución y ha elevado las auditorías algorítmicas a estándar. La AP publica periódicamente directrices sobre el manejo de sistemas de IA bajo el RGPD y opera desde 2023 una división dedicada "Algoritmes". Quien produzca aquí debe poder explicar cada decisión automatizada ante los afectados - un estándar que después también aplica la AEPD en España.

Segundo, De Nederlandsche Bank (DNB) y la Autoriteit Financiële Markten (AFM). Ambas han fijado con su documento conjunto "General principles for the use of Artificial Intelligence in the financial sector" (principios SAFEST) el estándar para bancos, aseguradoras y fondos de pensiones. Soundness, Accountability, Fairness, Ethics, Skills y Transparency son los requisitos no negociables - cada decisión de IA debe resistir estos seis criterios.

Tercero, la interpretación nacional del EU AI Act en preparación. Países Bajos trabaja en una lógica propia de implementación que engrana las categorías de alto riesgo del EU AI Act con los regímenes existentes de DNB y AP. Concretamente: un sistema IA clasificado como "high-risk" en el EU AI Act cae en Amsterdam adicionalmente bajo la lógica SAFEST de DNB/AFM. El [EU AI Act Compliance](/es/governance/eu-ai-act/) debe funcionar aquí por partida doble.

## Escenarios típicos de implementación en Amsterdam

ING y ABN AMRO utilizan Transaction Monitoring para detectar blanqueo de capitales - los modelos deben mantenerse explicables ante los auditores de DNB, cada alerta debe ser reproducible. Adyen procesa miles de millones de pagos globalmente y necesita modelos de Fraud Detection que decidan en segundos pero entreguen a la AFM un Audit Trail completo para cada bloqueo. Booking.com se mueve con sus algoritmos de Dynamic Pricing directamente en el campo de colisión entre el Art. 5 del EU AI Act (prohibición de prácticas manipuladoras) y la autoridad de competencia neerlandesa ACM. ASML, por su parte, documenta en Veldhoven carteras de patentes y disputas de PI donde cada búsqueda asistida por IA debe estar respaldada de forma auditable.

En los cuatro escenarios no se trata de "¿funciona el modelo?" sino de "¿podemos defender el modelo ante una autoridad?". Exactamente para eso existe el [Decision Layer](/es/decision-layer/): una arquitectura que persiste cada decisión como trace, fuerza rutas escalables de Human-in-the-Loop y provee Audit Trails directamente a nivel SQL. Se añade el ondernemingsraad - el comité de empresa neerlandés posee según la Wet op de ondernemingsraden (WOR) derechos sustanciales de cogestión en la introducción de sistemas IA.

## Cómo Gosign atiende Amsterdam desde Hamburgo

Hamburgo se encuentra a poco más de cuatro horas de tren o una hora de vuelo de Schiphol. Trabajamos Remote-first con equipos en Amsterdam, Eindhoven y Rotterdam - standups en hora MEZ, revisiones asíncronas vía Linear, workshops presenciales mensuales en los primeros tres meses de proyecto. La cultura de cumplimiento neerlandesa es lo bastante pragmática como para que la colaboración funcione sin grandes pérdidas de traducción. Los Discovery Workshops se celebran en inglés, la documentación técnica la entregamos en inglés y neerlandés (revisada por native reviewers), las rondas internas de steering con nuestros arquitectos de Hamburgo corren en alemán, y para clientes españoles con operación NL coordinamos desde Barcelona en castellano.

No tenemos filial en Amsterdam. Honestamente: para la mayoría de proyectos tampoco hace falta. Lo que hace falta es alguien que tenga los principios DNB-SAFEST y el EU AI Act en la cabeza simultáneamente - y que pueda estar in situ en 24 horas ante una auditoría AP. Ambas cosas las entregamos desde Hamburgo con respaldo de Barcelona para clientes hispanohablantes.

## Por qué Amsterdam funciona como punto de partida para Enterprise AI

Amsterdam te obliga a pensar la IA desde el primer día como infraestructura regulada, no como experimento de innovación. Quien construye aquí un piloto con Cert-Ready by Design tendrá después un caso de referencia que será defendible de inmediato en cualquier otro mercado UE. Los clusters Amsterdam Smart City, AMS Cluster y el ecosistema Brainport en Eindhoven aportan talento, investigación y partners piloto. Al mismo tiempo los caminos de distribución son claros: quien satisface a DNB, AFM y AP tiene argumentos de cumplimiento que funcionan en Fráncfort, París o Madrid - normalmente con menos overhead que la variante amsterdameña. Para empresas españolas con operaciones Benelux, Amsterdam es el mercado donde la estrategia IA de grupo debe demostrarse primero - antes de escalar a Madrid o Barcelona.

--- Agentes IA para Empresas en Barcelona | Gosign ---
> Enterprise AI Agents en Barcelona. Gestión de proyectos local, EU AI Act compliant by design, RGPD + LOPDGDD. Del PoC a la operación independiente.

## Barcelona es la capital tecnológica de España, pero la supervisión nacional de IA se decide en La Coruña

Quien construye IA empresarial en Barcelona trabaja en uno de los corredores de innovación más densos del sur de Europa y, al mismo tiempo, en un mercado donde las decisiones regulatorias se toman a 1.100 kilómetros al noroeste. En el distrito 22@Barcelona conviven CaixaBank, Cellnex Telecom, Mango, Desigual, Damm y el gigante farmacéutico Grifols con su negocio de plasma. En el cinturón industrial Seat fabrica los modelos Cupra en Martorell, en el puerto opera la logística de Naturgy, y Banco Sabadell atiende a empresas medianas en toda Cataluña. Pier01 y ESADE Creapolis atraen talento a la ciudad - Barcelona es el laboratorio de innovación de España. Pero la realidad regulatoria se construye en la sede de la AESIA en La Coruña y se endurece desde Madrid.

## Los tres obstáculos regulatorios para la IA en el mercado catalán

Primero, la AESIA (Agencia Española de Supervisión de la Inteligencia Artificial). España es el primer país de la UE con una autoridad dedicada a la supervisión de IA, con sede en La Coruña, y aspira a ser referencia para la implementación nacional del EU AI Act en toda la Unión. La AESIA supervisará desde 2026 los sistemas de alto riesgo de forma sistemática y podrá imponer prohibiciones de uso. Quien lance modelos al mercado en Barcelona debe documentar desde el primer día para una auditoría AESIA, conforme a los estándares definidos en el programa de sandbox regulatorio.

Segundo, la AEPD (Agencia Española de Protección de Datos) junto con la LOPDGDD (Ley Orgánica 3/2018), la ley española de implementación del RGPD con endurecimientos. La AEPD es conocida en toda la UE por la interpretación más estricta del Art. 22 RGPD - las decisiones totalmente automatizadas en España solo son admisibles con una decisión humana final documentada. Para cualquier sistema AI con datos personales esto significa: Decision Layer con Human-in-the-Loop no es opcional, es requisito de cumplimiento.

Tercero, la CNMV (Comisión Nacional del Mercado de Valores) y el Banco de España para todos los servicios financieros. La CNMV exige desde 2024 un Audit Trail completo en recomendaciones de inversión asistidas por IA y verifica la explicabilidad de los modelos. Al mismo tiempo, el Comité de Empresa según el Art. 64 del Estatuto de los Trabajadores ejerce derechos de consulta cuando los sistemas de IA toman decisiones que afectan a los trabajadores - sin derecho de veto, pero con plazos de información que deben respetarse desde el inicio del proyecto.

## Escenarios típicos de implementación en Barcelona

CaixaBank opera una de las redes de oficinas más grandes de España y necesita modelos de evaluación crediticia para pymes que sean reproducibles bajo supervisión de la AEPD - cada denegación debe ser justificable en un plazo de 14 días. Grifols documenta cadenas de origen del plasma de donantes en cientos de centros en EE. UU. y la UE - la FDA exige Audit Trails completos y la EMA refleja esa exigencia. La verificación de plausibilidad asistida por IA aquí no es innovación, es cumplimiento. Cellnex Telecom gestiona decenas de miles de torres en Europa y utiliza Predictive Maintenance para priorizar intervenciones - cada decisión automatizada de triaje debe ser justificable ante propietarios (a menudo inversores institucionales). Seat planifica en Martorell la producción de los modelos Cupra y necesita IA para la planificación de capacidad multifábrica - los modelos deben superar las auditorías del grupo VW.

En cada uno de estos casos, el [Decision Layer](/es/decision-layer/) construye una capa entre el modelo y el proceso de negocio que impone Audit Trail, vías de escalado y Governance by Design - exactamente lo que AESIA, AEPD y CNMV quieren ver simultáneamente.

A esto se añaden requisitos sectoriales: las farmacéuticas como Grifols operan bajo supervisión de la EMA y deben documentar las decisiones de calidad asistidas por IA conforme a GMP. Las telecos como Cellnex están bajo la CNMC y deben poder revelar las implicaciones de poder de mercado de sus algoritmos. Y en el sector automoción, el grupo VW espera para cada herramienta de IA en las plantas de Seat una evaluación de riesgos según los mismos estándares aplicados en Wolfsburgo o Ingolstadt.

## Cómo Gosign atiende Cataluña y España desde Barcelona

Gosign tiene oficina propia en Barcelona (gosign.es) con equipo español y catalán - native speakers, gestión de proyectos local, contacto directo con AESIA, AEPD y CNMV. La oficina de Barcelona es el hub regional para toda la Península Ibérica: Discovery Workshops, Sprint Reviews y Steering se realizan in situ con el cliente en el distrito 22@, en Pier01 o directamente en las sedes de CaixaBank, Cellnex, Mango, Damm y Grifols. Para Banco Sabadell, Seat en Martorell y Naturgy, los workshops en español o catalán son estándar, la documentación de cumplimiento se entrega bilingüe (ES y CA), y el Comité de Empresa participa desde el inicio. Las escalaciones hacia Hamburgo solo se producen para cuestiones arquitectónicas fundamentales o la coordinación con grupos matrices alemanes y suizos - la operación diaria, la comunicación con clientes y los contactos con autoridades los lleva el equipo de Barcelona. El ecosistema de ingeniería catalán es lo bastante denso para reclutar talento localmente y anclarlo en el proyecto. Para clientes españoles con operaciones en LATAM, coordinamos con el equipo de São Paulo de gosign.com.br para cubrir LGPD brasileña y otras jurisdicciones latinoamericanas.

## Por qué Barcelona funciona como punto de partida para Enterprise AI

España afronta una doble ola: la supervisión de la AESIA y la implementación del EU AI Act entran en operación al mismo tiempo. Quien construya en Barcelona un piloto Cert-Ready by Design tendrá un caso de referencia que resistirá los estándares de AEPD y AESIA - y que después será defendible inmediatamente en Madrid, Bilbao, Valencia y Milán. El clúster 22@Barcelona, Pier01 y el programa BStartup de Banco Sabadell aportan talento, partners piloto y acceso a inversores. Al mismo tiempo, la ciudad está lo bastante cerca de Madrid y Bruselas como para reaccionar rápido a las novedades regulatorias - y lo bastante lejos como para mantener carácter tecnológico propio.

Aportamos del mercado alemán la experiencia de construir sistemas IA que se mantienen productivos también bajo regímenes de supervisión estrictos - con [EU AI Act Compliance](/es/governance/eu-ai-act/) como base y Audit Trail hasta el nivel SQL. Barcelona es el mercado adecuado para escalar esta disciplina en el sur de Europa.

--- Agentes IA para Empresas en Belo Horizonte | Gosign ---
> Enterprise AI Agents para BH y Minas Gerais. LGPD-compliant, CLT-compatible. Minería, siderurgia, energía. Gestión desde São Paulo.

## Belo Horizonte es el mercado donde la minería brasileña defiende su credibilidad ESG

Minas Gerais produce la mitad del mineral de hierro brasileño y una parte significativa del acero, oro y aluminio del país. En Belo Horizonte y su entorno tienen sede u operan Vale (con centros clave en Nova Lima e Itabira, coordinados desde BH), Usiminas (siderurgia, con plantas en Ipatinga), AngloGold Ashanti, Magnesita Refratários, Localiza (mayor rentadora de Brasil con HQ global en BH) y Fiat Chrysler Brasil en la planta de Betim. Es el corredor industrial por el que pasa cada precio mundial del acero y cada decisión de inversor ESG sobre minería brasileña. Y es el corredor donde las rupturas de presas de Mariana (2015) y Brumadinho (2019) han transformado durante 20 años cualquier proceso "risk-based decision making". Lo que antes de 2019 pasaba por "modelado operativo de riesgo" hoy es un territorio jurídicamente sensible donde cada recomendación algorítmica puede tener que defenderse ante tribunales civiles y el Ministerio Público Federal (MPF) - una realidad de interés directo para empresas españolas con exposición al suministro mineral brasileño.

## Los tres obstáculos regulatorios para la IA en el mercado de Belo Horizonte

**Obligaciones de documentación ANM tras Brumadinho**: la Agência Nacional de Mineração endureció masivamente desde 2019 los requisitos de documentación de presas, pruebas de estabilidad y risk-reporting (Resolução ANM 95/2022 y resoluciones subsiguientes). Cada componente algorítmico en la monitorización de presas, el análisis de datos sensor o la clasificación de riesgo debe ser trazable ante auditores ANM con ruta de decisión completa - Audit Trail hasta nivel de sensor.

**IBAMA y licencias ambientales SEMAD**: el ministerio de medio ambiente IBAMA y la autoridad estatal SEMAD MG exigen estudios de impacto ambiental (EIA/RIMA) detallados y monitoreo continuo para operaciones mineras e industriales. La IA que estima emisiones, optimiza parámetros de proceso o clasifica incidentes de seguridad queda así bajo obligaciones ambientales concretas - con explicabilidad documentada a petición del auditor medioambiental.

**LGPD y cogestión via Sindicatos**: los Sindicatos en metalurgia y minería (Sindiextra, Sticcer) están históricamente muy enraizados en BH. Los sistemas IA que deciden sobre planificación de turnos, alertas de seguridad o decisiones de RRHH deben negociarse con representantes sindicales - LGPD-conforme y con un Decision Layer que refleje arquitectónicamente los workflows de cogestión. La CLT brasileña y los convenios regionales (CCT/ACT) convierten la consulta sindical en prerrequisito jurídico para cualquier HR-Agent en la región. Nota para hispanohablantes: la LGPD, no el RGPD, es la ley aplicable en Brasil - son regímenes distintos.

## Escenarios típicos de implementación en Belo Horizonte

**Vale - monitorización de seguridad de presas**: Workflow Agents vigilan datos sensor en presas de relaves en Itabira, Brucutu y otros emplazamientos de Minas Gerais, los contrastan con datos meteorológicos e informes de inspección, y el Decision Layer escala patrones críticos de riesgo con Human-in-the-Loop a los equipos de geotecnia. Cada decisión queda documentada para ANM, MPF y compliance interno - es la diferencia entre línea de defensa y denuncia penal.

**Localiza - gestión de flotas**: Document y Workflow Agents procesan protocolos de mantenimiento, avisos de siniestros y datos de seguros de la mayor flota de rentadoras de Latinoamérica. El Decision Layer enruta escalaciones a talleres colaboradores y prioriza vehículos críticos para inspección - con biografía auditable por vehículo. Tras la fusión con Unidas, Localiza es la tercera mayor rentadora mundial, con volumen de datos y exigencias de consistencia algorítmica regional a la altura.

**Usiminas - planificación de producción siderúrgica**: Document Agents leen carteras de pedidos, datos logísticos y perfiles de consumo energético y generan recomendaciones de producción para las plantas de Ipatinga y Cubatão. El Decision Layer escala conflictos con obligaciones ANM de seguridad o contratos energéticos ANEEL a planificadores humanos. Workflow Agents alertan proactivamente ante paros inminentes o roturas de cadena.

**Fiat Chrysler Brasil Betim - control de calidad**: Document Agents procesan protocolos de inspección, KPIs de calidad e informes de auditoría de proveedores de la mayor planta Fiat fuera de Italia. El Decision Layer escala desviaciones críticas con Human-in-the-Loop a jefes de planta - Audit Trail que satisface los estándares del grupo Stellantis y los requisitos INMETRO para certificación de vehículos brasileños.

## Cómo Gosign atiende Belo Horizonte desde São Paulo

Nuestra oficina en São Paulo (gosign.com.br) está a 1 hora de vuelo de BH - el hub regional para Brasil. Los Discovery Workshops con Vale, Usiminas o Localiza se celebran in situ en BH o en las plantas - en Itabira, Ipatinga, Betim. Las Compliance Reviews con referencia ANM o IBAMA se conducen con tu departamento jurídico y abogados medioambientales externos - en proyectos mineros es el paso decisivo, porque la interpretación regulatoria en el detalle suele pesar más que la arquitectura del modelo. Las consultas sindicales, cuando hay HR-Agents o planificación de turnos en juego, pasan por despachos laboralistas locales en BH y se apoyan en las estructuras Sindiextra históricamente fuertes en la región. Las fases de Build corren distribuidas entre Hamburgo y São Paulo. Para clientes españoles con operaciones mineras o siderúrgicas en Brasil (lusofonía + hispanidad), coordinamos desde Barcelona para puente cultural-jurídico hacia São Paulo - documentación bilingüe ES/PT según necesidad. Los desplazamientos presenciales a BH se organizan en 24 horas, incluso a emplazamientos mineros remotos en Itabira o Brucutu.

## Por qué Belo Horizonte funciona como punto de partida para Enterprise AI

BH es el único mercado en Brasil donde realidad industrial (minería, siderurgia, automoción), presión regulatoria sostenida (ANM tras Brumadinho) y clúster de innovación (San Pedro Valley, P7 Creative Hub) coexisten simultáneamente. Quien construye aquí un agente productivo para seguridad de presas, optimización de producción o reporting ESG lo construye bajo las exigencias de auditoría más estrictas de la industria brasileña - lo que lo hace exportable a cualquier otro mercado minero y siderúrgico global, desde Chile hasta Australia Occidental. La Universidade Federal de Minas Gerais (UFMG) y la Universidade Federal de Ouro Preto (UFOP) aportan talento en geotecnia, metalurgia e IT industrial con una concentración única en Brasil. La arquitectura [Cert-Ready by Design](/es/servicios/ai-agents/) garantiza que un agente probado en BH pase también auditorías RGPD y EU AI Act europeas - condición para inversores ESG y exigencias de cadena de suministro de compradores europeos. Consulta también [Río de Janeiro](/es/agentes-ia-rio-de-janeiro/) y [São Paulo](/es/agentes-ia-sao-paulo/).

--- Agentes IA para Empresas en Berlín | Gosign ---
> Enterprise AI Agents en Berlín. Dirección de proyectos presencial, RGPD conforme, EU AI Act compliant. Desde startups hasta ministerios federales.

## Berlín es el único mercado alemán donde un ministerio federal y una startup en Serie B necesitan al mismo proveedor de IA

Ningún otro lugar del espacio germanoparlante reúne esta amplitud. En el barrio gubernamental se encuentran la Cancillería Federal, el BMI y el BMWK con sus proyectos de consolidación de TI y un volumen de inversión que marcará la digitalización administrativa de los próximos años. Tres estaciones de metro más allá trabajan N26, Solaris, Zalando y Delivery Hero en cuestiones de escalado que ya nada tienen que ver con la TI bancaria clásica. Cariad tiene un hub de software en Berlín y desarrolla la plataforma de software para los vehículos del grupo Volkswagen. Deutsche Bahn opera desde Potsdamer Platz una de las mayores Data Office corporativas de Alemania, SAP ha anclado aquí sus Data Spaces, IBM y Microsoft mantienen sedes con funciones de investigación y comerciales. Esta mezcla obliga a una arquitectura que represente limpiamente tanto un procedimiento administrativo con obligación de expediente como un modelo KYC en N26 - con el mismo Decision Layer y los mismos requisitos de Audit Trail, pero con conjuntos de reglas específicos por jurisdicción y por proceso por encima.

## Tres obstáculos regulatorios que definen cualquier caso de IA en Berlín

El primer obstáculo es la supervisión de la BaFin sobre las FinTech berlinesas. N26 y Solaris están licenciadas como entidades CRR, las circulares BaFin sobre MaRisk y BAIT se aplican con todo su rigor, y ambas casas han pasado en los últimos años varias inspecciones especiales con requerimientos que han marcado la comprensión del mercado sobre las expectativas regulatorias. Quien quiera construir aquí un modelo AML o de detección de fraude con IA necesita una gobernanza de modelos que los inspectores especiales de BaFin acepten como cadena de evidencia auditable - incluyendo versionado, justificación de umbrales y decisión reproducible. El segundo obstáculo es la administración pública: el BSI marca el marco con el IT-Grundschutz y sus estándares mínimos de IA, el BMI define mediante los proyectos derivados de la Online-Zugangsgesetz cómo deben registrarse las decisiones automatizadas en procedimientos administrativos. Ambas autoridades exigen un Audit Trail que pueda enlazarse con la obligación de llevanza de expedientes. El tercer obstáculo es el propio EU AI Act, que desde 2026 actúa en la clasificación de alto riesgo - decisiones de personal, scoring crediticio y decisiones administrativas caen en Berlín al mismo tiempo en al menos tres ámbitos de aplicación. Más contexto en [Governance EU AI Act](/es/governance/eu-ai-act/).

## Escenarios típicos de implementación en Berlín

En el sector público se trata del procesamiento estructurado de solicitudes entrantes - resoluciones de subvenciones, reposiciones de expediente, consultas ciudadanas - con asignación clara a personal administrativo y nota de expediente completa por cada paso de IA. Vemos pilotos donde los Document Agents clasifican documentos administrativos entrantes, extraen campos obligatorios y los entregan al área competente con indicación de completitud o anexos faltantes. En N26 y entidades de licencia comparables vemos AML Triage Agents que enriquecen los hits del transaction monitoring con historial del cliente, datos KYC y fuentes externas, realizan una evaluación motivada de plausibilidad y entregan al Compliance Officer una preparación para el Suspicious Activity Report - el Officer decide, el Agent documenta sin lagunas. Deutsche Bahn trabaja en conceptos de Predictive Maintenance para trenes e infraestructura ferroviaria, donde la decisión de mantenimiento la toma al final un técnico certificado, pero el Agent aporta el historial de sensores y datos comparativos de componentes similares como propuesta estructurada. Cariad y casas similares de software OEM necesitan Code Review Agents que conozcan las exigencias de ASPICE e ISO-26262 y marquen los cambios de código críticos para una revisión de arquitectura. En Zalando y Delivery Hero vemos Customer Service y Logistics Agents que estructuran casos recurrentes y priorizan escalados. Lo que comparten todos los escenarios: ninguna decisión totalmente automatizada, sino un [Decision Layer](/es/decision-layer/) con Human-in-the-Loop forzado en los puntos correctos.

## Cómo Gosign atiende Berlín desde Hamburgo

Operamos en Berlín una oficina propia en la Nogatstraße 46 en Neukölln - no un buzón postal, sino base para dirección de proyectos, Discovery Workshops y para el acompañamiento de mandatos del sector público. La sede central sigue siendo Hamburgo, desde allí vienen ingeniería y arquitectura de governance, en Berlín está el acompañamiento operativo para proyectos de la capital. Concretamente: un Discovery comienza con un workshop de dos a tres días en sus instalaciones en Berlín o en la oficina berlinesa, en la fase de construcción trabajamos remoto con dos slots semanales fijos in situ, la puesta en producción la hacemos de nuevo presencial. Los workshops de validación de modelos con inspectores especiales BaFin o con la auditoría interna de bancos licenciados se realizan siempre presencialmente, porque aquí nace la relación de confianza con la supervisión. Las visitas in situ entre Tiergarten, Mitte y Adlershof son factibles dentro del día - la conexión Hamburg-Berlin sobre la estación central es posible en menos de dos horas en ICE, lo que hace flexible la disponibilidad de la capa de ingeniería desde Hamburgo. Para empresas españolas con presencia en Berlín o que evalúan establecer presencia comercial alemana en la capital, coordinamos con la oficina de Barcelona (gosign.es) para garantizar comunicación bilingüe español-alemán desde el primer Discovery.

## Por qué Berlín funciona como punto de partida para Enterprise AI

La capital es el único lugar de Alemania donde puedes combinar marco político, práctica regulatoria y velocidad empresarial en un mismo programa de un día. Quien ponga en producción en Berlín un primer Agent lo habrá defendido típicamente ante tres grupos de stakeholders simultáneamente: auditoría corporativa, protección de datos y comité de empresa. Este endurecimiento triple es a la vez la mejor preparación para una escalada a otras regiones. A esto se añade la disponibilidad de datos y compute mediante el BerlinIX y los emplazamientos Telehouse con conexiones directas a las grandes regiones hyperscaler, una creciente bolsa de talento en ML Engineering gracias a la TU, el HPI y la Berlin School of Business and Innovation, así como una densa red de comunidades de IA y meetups que hace normal el intercambio de buenas prácticas. La cercanía espacial de decisores políticos, prácticos de la supervisión y fundadores tech en una misma área urbana acorta los caminos para alinear stakeholders de una forma que no existe en ningún otro mercado alemán. Quien tenga aquí en 4-6 semanas un Decision Layer con Audit Trail en producción cumple Cert-Ready by Design exactamente para los stakeholders que en las grandes empresas suelen tener el mayor poder de bloqueo. Más sobre el procedimiento en [Servicios AI Agents](/es/servicios/ai-agents/).

--- Agentes IA para Empresas en Bilbao | Gosign ---
> Enterprise AI Agents para Bilbao y País Vasco. Industria, energía, banca. EU AI Act compliant. Gestión desde Barcelona.

## Bilbao es la única ciudad española donde la industria pesada y la infraestructura energética exigen cumplimiento al mismo tiempo

El País Vasco es la antítesis industrial del sur de España, dominado por el turismo. En Bilbao y la región de Bizkaia tienen su sede Iberdrola - el gigante energético global con sede en la Torre Iberdrola - así como Petronor (la refinería de Repsol en Muskiz), CAF (Construcciones y Auxiliar de Ferrocarriles) como fabricante ferroviario, Tubacex y Sidenor en la transformación del acero, y el grupo Kutxabank. BBVA tiene una sede histórica en Bilbao y mantiene aquí funciones operativas significativas, Euskaltel es la base regional de telecomunicaciones. Quien construye IA en Bilbao no lo hace para sectores de servicios, sino para redes eléctricas, altos hornos, flotas de trenes y plataformas cuya parada se calcula en millones por hora.

## Los tres obstáculos regulatorios para la IA en el mercado vasco

Primero, el régimen doble de protección de datos. España es el único país de la UE con una autoridad regional de protección de datos junto a la nacional: la AVPD (Agencia Vasca de Protección de Datos) es competente en el País Vasco para entidades públicas y, en parte, para empresas con anclaje regional, mientras que la AEPD (Agencia Española de Protección de Datos) cubre el resto. Ambas autoridades aplican la LOPDGDD (Ley Orgánica 3/2018) y examinan con especial rigor las decisiones automatizadas. Quien trabaje en el País Vasco con datos personales debe contemplar a ambos destinatarios en su arquitectura de cumplimiento.

Segundo, la CNMV y el Banco de España para la lógica financiera de BBVA y Kutxabank. Ambos bancos llevan años apostando por modelos de riesgo asistidos por IA, pero la CNMV exige desde 2024 explicabilidad completa de los modelos que entran en recomendaciones de inversión. Audit Trail, reproducibilidad y vías de escalado en decisiones de riesgo dejan de ser negociables.

Tercero, el EU AI Act en combinación con los regímenes de seguridad industrial. Iberdrola opera infraestructura de alta tensión, CAF construye material rodante - en ambos dominios el EU AI Act se entrelaza, mediante categorías de alto riesgo (infraestructura energética, transporte crítico), con estándares sectoriales de seguridad (UNE-EN, IEC 61508). El [EU AI Act Compliance](/es/governance/eu-ai-act/) aquí no significa "verificar protección de datos", significa "certificar el modelo de IA como componente de seguridad crítico".

## Escenarios típicos de implementación en Bilbao

Iberdrola optimiza operaciones de Smart Grid en varios mercados - los modelos determinan cuándo qué generador asume qué cargas. Cada decisión se documenta ante el operador regional de la red, los Audit Trails son requisito para participar en el mercado. BBVA desarrolla modelos de Risk Scoring para decisiones crediticias en el tejido medio empresarial vasco, que deben ser justificables ante los clientes según el Art. 22 RGPD. CAF mantiene flotas de trenes en varios países europeos y utiliza datos telemáticos para Predictive Maintenance - las recomendaciones deben ser trazables para las autoridades de supervisión en cada país operador. Tubacex apuesta en la producción de acero inoxidable por un control de calidad asistido por IA, en el que cada decisión automática de descarte debe ser justificable ante grandes clientes como Aramco o Equinor.

En los cuatro escenarios se trata de IA industrial con efecto sobre activos físicos. El [Decision Layer](/es/decision-layer/) aporta aquí la arquitectura que dota a las decisiones de Audit Trail, escalado Human-in-the-Loop y Cert-Ready by Design.

Una particularidad vasca: la tradición cooperativa en torno a Mondragon también marca a las empresas no cooperativas de la región. La participación de los trabajadores en las decisiones tecnológicas no es aquí una cuestión de cumplimiento, es parte de la cultura empresarial. Construimos el Decision Layer de forma que las obligaciones de información y consulta del Comité de Empresa y las estructuras de gobernanza cooperativas se cumplan arquitectónicamente - no como consulta posterior, sino como flujo integrado en el sistema mismo.

## Cómo Gosign atiende Bilbao desde Barcelona

Gosign atiende los proyectos vascos desde la oficina de Barcelona (gosign.es) con jefes de proyecto e ingenieros hispanohablantes. La conexión aérea directa Barcelona-Bilbao dura aproximadamente una hora - las visitas in situ a la Torre Iberdrola, a la sede de BBVA, a CAF en Beasain, a Tubacex y al clúster BEAZ son factibles dentro de una jornada laboral. El equipo español apoya a la industria vasca bajo las particularidades de la región: el régimen doble de protección de datos AVPD y AEPD, la tradición cooperativa de Mondragon con sus estructuras de participación, y el bilingüismo entre castellano y euskera, que conviven en discusiones técnicas. Cuando es necesario integramos a stakeholders euskaldunes directamente en los workshops. La sede de Hamburgo asume cuestiones de cumplimiento a escala europea y revisiones arquitectónicas fundamentales, además de la conexión con estándares industriales de cumplimiento alemanes - la entrega operativa, el lenguaje de ingeniería de la industria pesada vasca y los caminos de decisión más cortos del País Vasco los lleva el equipo de Barcelona.

## Por qué Bilbao funciona como punto de partida para Enterprise AI

Quien lleve a producción en Bilbao un piloto industrial de IA tendrá un caso de referencia que ha pasado la doble supervisión de protección de datos (AEPD + AVPD), los estándares de la CNMV y la lógica de alto riesgo del EU AI Act - en ningún sitio de España el listón está más alto. El clúster BEAZ, Bizkaia Startup Bay y el Mondragon Innovation Hub aportan ecosistema, talento y partners piloto. Al mismo tiempo, las empresas vascas tienen la ventaja de pensar a largo plazo: los proyectos de IA aquí no se planifican como pilotos trimestrales, sino como inversión a varios años.

Aportamos la experiencia de construir sistemas IA que no solo funcionan, sino que también se mantienen defendibles bajo condiciones de auditoría - con Governance by Design, Audit Trail y la disciplina que exige el cumplimiento industrial. Bilbao es el mercado adecuado para escalar esta disciplina en el norte de España.

Y hay una ventaja geográfica: desde el País Vasco se llega tanto a la industria del sur de Francia (aeroespacial en Toulouse, farma en Lyon) como al norte portugués (tecnología e industria en torno a Oporto). Quien construya en Bilbao una arquitectura de IA productiva bajo condiciones españolas tendrá un caso de referencia para todo el arco atlántico de Europa Occidental.

--- Agentes IA para Empresas en Brasil | Gosign ---
> Enterprise AI Agents para Brasil. LGPD-compliant, CLT-compatible, preparado para PL 2338/2023. Oficina en São Paulo, proyectos en todo Brasil.

## Brasil es el único mercado LATAM donde Gosign opera con presencia local real

Brasil no es "un mercado latinoamericano más". Con más de 215 millones de habitantes, la novena economía mundial y un marco regulatorio (LGPD, BACEN Resolução 4893, PL 2338/2023) que existe por derecho propio al lado del régimen UE, Brasil es un bloque de universo-cumplimiento autónomo. Por eso Gosign opera una oficina en São Paulo (gosign.com.br) que no cubre solo la metrópoli SP, sino el conjunto del mercado brasileño operativamente - desde Petrobras en Río hasta Caixa en Brasilia, Vale en Minas Gerais y Volvo en Curitiba. Esa es la condición para que los estándares Enterprise AI europeos (Audit Trail, Cert-Ready by Design, Decision Layer con Human-in-the-Loop) funcionen en un mercado que está emparentado con el EU AI Act pero no es idéntico. Para empresas españolas con operaciones en Brasil, este es el puente operativo: coordinación Barcelona + São Paulo (hispanidad + lusofonía) bajo un mismo proveedor.

## Los tres obstáculos regulatorios para la IA en el mercado brasileño

**La LGPD (Lei Geral de Proteção de Dados) es la respuesta brasileña al RGPD, pero no su traducción**: tiene bases jurídicas propias, exigencias DPO propias, sanciones propias y con la ANPD (Autoridade Nacional de Proteção de Dados) una autoridad propia con sede en Brasilia. Quien expande de Europa a Brasil no puede tratar la LGPD como "una variante del RGPD" - la interpretación del Art. 7 (bases jurídicas) y del Art. 11 (datos sensibles) difiere considerablemente en la práctica. Las arquitecturas IA deben poder satisfacer LGPD y RGPD en paralelo, no como alternativas.

**BACEN Resolução 4893 es el DORA brasileño**: las exigencias de ciber-resiliencia para entidades financieras reguladas (Itaú, Bradesco, Santander Brasil, Banco do Brasil, Caixa, Nubank, Stone, XP) se desarrollaron de forma independiente al Derecho UE. Cada componente algorítmico en decisiones de crédito, fraud-scoring, AML/KYC u operaciones de mercado debe ser auditable por BACEN - con obligaciones de reporting que divergen de las implementaciones DORA europeas.

**PL 2338/2023 es el proyecto de ley brasileño sobre IA**: inspirado en el EU AI Act pero no idéntico - en 2026 aún no está en vigor, pero se espera en los próximos 18-24 meses. Las clases de riesgo, la obligación de supervisión humana y los estándares de explicabilidad son similares, pero con acentos propiamente brasileños (especialmente en la relación con sindicatos y CREs en sistemas laborales). Cert-Ready by Design significa en Brasil: diseñar arquitectura de modo que atienda LGPD hoy, PL 2338 desde 2027 y EU AI Act para operaciones DACH simultáneamente.

## Escenarios típicos de implementación en Brasil

**Banca y fintech**: KYC/AML en [Itaú, Bradesco, Santander Brasil y Banco do Brasil](/es/agentes-ia-sao-paulo/) - Document Agents leen datos CPF/CNPJ, los contrastan con listas de sanciones Coaf, y el Decision Layer escala hits high-risk con Audit Trail completo. El mismo patrón en Nubank, Stone, PagSeguro y XP Inc. - con Fraud Detection y reporting BACEN en tiempo real.

**Minería y energía**: Vale Dam-Safety en [Minas Gerais](/es/agentes-ia-belo-horizonte/) y documentación de instalaciones Petrobras en [Río](/es/agentes-ia-rio-de-janeiro/) - Workflow Agents vigilan datos sensor, informes de inspección e indicadores externos de riesgo. Decision Layer escala patrones críticos con Human-in-the-Loop. El Audit Trail es explicable ante ANM, MPF, ANP y ANEEL.

**Industria y automoción**: Volvo, Renault, VW y Klabin en [Curitiba](/es/agentes-ia-curitiba/) - Document Agents para Supply Chain, cumplimiento Mercosur y reporting ESG. Workflow Agents para control de calidad y planificación de mantenimiento. Cert-Ready para auditorías RGPD en matrices europeas.

**Sector público**: evaluación de crédito Caixa y análisis de políticas ANPD en [Brasilia](/es/agentes-ia-brasilia/) - Document Agents para solicitudes de prestaciones sociales, Workflow Agents para monitoreo regulatorio. Audit Trail conforme a exigencias TCU, con expedientes justificativos por cada recomendación algorítmica. Los proyectos de sector público en Brasil discurren bajo marcos propios de contratación pública y estándares propios de protección de datos para datos ciudadanos - el cumplimiento de esos marcos es prerrequisito para cualquier renovación contractual.

## Cómo Gosign atiende Brasil desde São Paulo

Nuestra oficina en São Paulo (gosign.com.br) es el hub operativo para Brasil - con jefes de proyecto locales que conducen Discovery Workshops in situ, participan en Compliance Reviews con DPO y jurídico y acompañan consultas sindicales. Desde SP, Río (1 h vuelo), Belo Horizonte (1 h), Curitiba (1 h), Brasilia (1,5 h) y Porto Alegre (1,5 h) son alcanzables en el día - visitas presenciales en 24 horas. La fase técnica de Build corre distribuida entre Hamburgo y São Paulo, con standups conjuntos por la mañana hora SP. Tras el Go-Live la oficina SP es tu interlocutor operativo con hotline de escalación en portugués. Para clientes españoles con operaciones en Brasil (lusofonía + hispanidad), la combinación Barcelona + São Paulo ofrece coordinación cultural-jurídica conjunta - documentación de cumplimiento bilingüe ES/PT según necesidad, workshops en el idioma que corresponda al stakeholder.

Lo que hace atractiva esta constelación para empresas españolas con operaciones brasileñas: hay un interlocutor que cubre operativamente ambos mundos - la matriz española sigue hablando con el equipo Barcelona, la filial brasileña con el equipo São Paulo. Los Discovery y Compliance Workshops se celebran en los idiomas que procedan. Una arquitectura construida en São Paulo puede producirse con adaptaciones mínimas en Lisboa, Madrid o Berlín, porque los componentes Audit, Decision Layer y Cert-Ready by Design ya atienden ambos universos regulatorios.

## Por qué Brasil funciona como punto de partida para Enterprise AI

Brasil es el único mercado latinoamericano donde cumplimiento bancario, operaciones industriales, sector público y cadenas de suministro de consumo se dan cita en un mismo marco regulatorio. Quien construye aquí agentes productivos para KYC, reporting ESG o seguridad de presas los tiene disponibles como blueprint para México, Argentina, Chile, Colombia y Perú. La oficina SP posiciona a Gosign como proveedor europeo con presencia LATAM real - una combinación poco común en el entorno competitivo europeo. La arquitectura [Governance by Design](/es/governance/eu-ai-act/) garantiza que un agente construido en Brasil supere también auditorías RGPD y EU AI Act europeas, y BACEN, ANPD o TCU. Más en [contacto](/es/contacto/) o en los panoramas de [São Paulo](/es/agentes-ia-sao-paulo/), [Río](/es/agentes-ia-rio-de-janeiro/) y [Brasilia](/es/agentes-ia-brasilia/).

--- Agentes IA para Empresas en Brasilia | Gosign ---
> Enterprise AI Agents para Brasilia. LGPD-compliant, compatible con legislación del sector público. ANPD en la misma ciudad. Agents auditables.

## Brasilia es el mercado donde se decide realmente la regulación de IA brasileña

Brasilia no tiene sedes corporativas como São Paulo ni clústeres industriales como Belo Horizonte - pero tiene algo que estas ciudades no tienen: todos los reguladores nacionales en una sola meseta. La ANPD (Autoridade Nacional de Proteção de Dados) tiene su sede en el Setor Comercial Sul. El BACEN (Banco Central do Brasil) opera desde el Setor Bancário Sul. CADE, ANATEL, ANVISA y ANM están todos dentro de 5 km de distancia. A esto se suman los bancos federales Caixa Econômica Federal y Banco do Brasil con sus sedes en el Setor Bancário, el Ministério da Fazenda, el STF y el STJ. Quien construye IA en Brasilia para un organismo federal, un banco público o un grupo regulado, la construye a la vista del propio regulador. Eso convierte a Brasilia en el mercado más estratégicamente importante para quien quiera operar seriamente Public-Sector-AI o banca regulada en Brasil - aquí no solo se regula, aquí también se compra. Para empresas españolas con operaciones en el sector público brasileño o contratos con bancos federales, este es el mercado de entrada.

## Los tres obstáculos regulatorios para la IA en el mercado de Brasilia

**La ANPD no es aquí abstracta** - es la autoridad en cuya ciudad se opera. La supervisión LGPD sobre bancos federales, organismos federales y datos gubernamentales se ejerce desde Brasilia. Quien construye aquí una IA que procesa datos de ciudadanos (prestaciones sociales, impuestos, salud) debe cumplir el Art. 23 de la LGPD (sector público) y la Resolução CD/ANPD 02/2022 sobre DPIAs - auditable, documentado, verificable en cualquier momento.

**Auditabilidad TCU para gasto federal**: el Tribunal de Contas da União revisa todo gasto federal en cuanto a economía y legalidad. Los componentes algorítmicos en créditos Caixa, risk-scoring Banco do Brasil o planificación de rutas Correios deben ser explicables ante auditores TCU con ruta de decisión completa. El Audit Trail aquí no es "best practice", es el prerrequisito para que la autoridad pueda siquiera continuar trabajando con el vendedor.

**PL 2338/2023 se negocia aquí**: el proyecto de ley brasileño de IA está en discusión en la Câmara dos Deputados y en el Senado Federal - ambos en Brasilia. Quien construye aquí, construye en una ciudad donde los borradores regulatorios cambian entre semanas parlamentarias. Cert-Ready by Design es la única estrategia que sobrevive a esa volatilidad: diseñar arquitectura de modo que la clasificación high-risk, la supervisión humana y las obligaciones de explicabilidad sean activables a posteriori. Nota: no es el EU AI Act ni el RGPD - es un marco propio brasileño.

## Escenarios típicos de implementación en Brasilia

**Caixa Econômica Federal - decisión de crédito**: Document Agents examinan solicitudes de crédito en vivienda social (Programa Minha Casa Minha Vida), las contrastan con datos CadÚnico y bureaus externos, y el Decision Layer enruta decisiones con Human-in-the-Loop a gestores - cada aprobación con expediente auditable para revisiones TCU.

**Análisis de políticas ANPD para Government Advisory**: Document Agents procesan resoluciones ANPD, interpretaciones LGPD y documentos de consulta y generan para equipos de cumplimiento en organismos federales informes diarios de situación regulatoria. Workflow Agents alertan sobre nuevos borradores del PL 2338/2023.

**Banco do Brasil - detección de fraude**: Document y Workflow Agents vigilan patrones transaccionales en tiempo real, escalan operaciones sospechosas a Compliance Officers y documentan cada detección con Audit Trail - incluyendo confidence-scores y versionado de modelos para notificaciones Coaf y auditorías BACEN. En bancos federales la densidad de reporting regulatorio es superior a la banca privada porque CGU (Controladoria-Geral da União) y TCU pueden lanzar consultas propias.

**Correios - optimización de rutas de reparto**: Document y Workflow Agents procesan volúmenes de envíos, clusters de CEP y capacidades de reparto y proponen rutas optimizadas para la mayor logística postal de Brasil. El Decision Layer respeta arquitectónicamente los plazos ANATEL y las jornadas CLT de los repartidores - cada recomendación con expediente auditable para el TCU.

## Cómo Gosign atiende Brasilia desde São Paulo

Nuestra oficina en São Paulo (gosign.com.br) está a 1,5 horas de vuelo de Brasilia. Los Discovery Workshops con Caixa, Banco do Brasil o un organismo federal se celebran in situ en los Setores Bancário y Comercial. Las Compliance Reviews con referencia ANPD o TCU se conducen con tu departamento jurídico en Brasilia - la cercanía al regulador es aquí una ventaja operativa, porque las citas aclaratorias con funcionarios ANPD se organizan más rápido para actores regulados presentes que para proveedores puramente remotos. Las fases técnicas de Build corren distribuidas: Hamburgo y São Paulo. Los standups por la mañana hora SP, las Sprint Reviews con tu equipo en Brasilia. Las visitas presenciales se organizan en 24 horas. En proyectos gubernamentales trabajamos con despachos locales para el marco público-jurídico - licitaciones, marco de contratación pública y especificidades LGPD para el sector público son un campo propio que no cubrimos internamente sino en partnership. Para clientes españoles con intereses en el sector público brasileño, coordinamos desde Barcelona el puente cultural-jurídico.

## Por qué Brasilia funciona como punto de partida para Enterprise AI

Brasilia es el único mercado en Brasil donde regulador e institución federal regulada tienen sede en la misma ciudad. Quien construye aquí un agente productivo para evaluación crediticia Caixa, reporting BACEN o Government Advisory, lo construye en un contexto donde el feedback regulatorio no llega "en 6 meses en la auditoría", sino en la siguiente semana parlamentaria. Los clústeres - Sebrae HQ, BioTIC Park, Universidade de Brasília - aportan talento y socios de investigación. Brasilia como mercado del sector público funciona especialmente bien para proveedores europeos cuando la arquitectura combina profundidad de auditoría RGPD europea con preparación LGPD y PL 2338 brasileña - Governance by Design en vez de parches posteriores de compliance. Quien construye un agente para un organismo federal o un banco público, lo hace de facto bajo un marco público-jurídico de licitación - y aquí la diferencia entre un modelo hecho auditable a posteriori y una arquitectura [Cert-Ready by Design](/es/servicios/ai-agents/) es la diferencia entre renovación de contrato y terminación de contrato. Más en el panorama [Brasil](/es/agentes-ia-brasil/) o en el perfil [São Paulo](/es/agentes-ia-sao-paulo/).

--- Agentes IA para Empresas en Colonia | Gosign ---
> Enterprise AI Agents para Colonia. Medios, comercio, seguros - IA auditable para sectores con alto volumen documental. EU AI Act compliant by design.

## Colonia es el único emplazamiento alemán donde la autoridad europea de aviación, una autoridad federal alimentaria y grupos privados de medios coinciden en radio de commuting diario

En el corredor entre Colonia-Bonn Flughafen, centro y Mediapark se asientan RTL Deutschland como mayor grupo privado de TV de Europa, Ford-Werke en Niehl con la segunda planta europea Ford, Rewe Group con sede corporativa cerca de Stolwerk, DEVK y Gothaer como dos grandes aseguradoras coloniesas y Toyota Deutschland en Köln-Marsdorf. TÜV Rheinland tiene sede en Colonia y es una de las entidades certificadoras europeas más importantes. En la vecina Köln-Bonn se sitúa la EASA como autoridad europea de aviación, en Bonn el BLE como autoridad federal de agricultura y alimentación. Lufthansa tiene su sede corporativa en Köln-Deutz. Esta combinación de industria, medios, seguros y varios actores regulatorios genera un mercado donde procesos documento-intensivos y decisiones auditables son día a día. Para empresas españolas con proveedores de medios o retail en Alemania, Colonia es el mercado de acceso.

## Tres obstáculos regulatorios que moldean toda iniciativa IA en el mercado de Colonia

El primer obstáculo es la supervisión aseguradora para DEVK, Gothaer y las filiales reaseguradoras aquí asentadas. Exigencias BaFin sobre riesgo de modelo y reporting Solvencia II aplican a cada componente IA en gestión de siniestros, tarificación o provisiones.

El segundo obstáculo es el bloque de compliance de medios y datos en RTL y destinatarios similares - el Medienstaatsvertrag, las especificidades RGPD para plataformas con publicidad y el Digital Services Act marcan límites claros a lo que puede hacer la IA en recomendación y moderación.

El tercer obstáculo es relevante EASA para Lufthansa y sus partners MRO: Continuing Airworthiness, mantenimiento Part-145 y exigencias Part-M deben demostrarse para componentes IA en entorno de mantenimiento en un historial de modelo auditable. A eso se suma el propio TÜV Rheinland como actor certificador que para muchas evaluaciones de conformidad EU AI Act es la dirección técnica - una relación que empresas coloniesas deben construir pronto, porque la evaluación de conformidad de sistemas IA high-risk recae en responsabilidad de entidades notificadas como TÜV. También el BLE en Bonn es relevante para REWE y retailers alimentarios similares cuando aplican componentes IA en gestión de surtido o evaluación de proveedores. Quien construye una arquitectura IA en Colonia planea [Cert-Ready by Design](/es/governance/eu-ai-act/) como estándar.

## Escenarios típicos de implementación en Colonia

En REWE Group y retail alimentario ampliado vemos agentes de surtido y cadena de suministro que condensan cifras regionales de venta, estacionalidad y datos de proveedores en una propuesta para el Category Manager - con documentación clara, porque retail alimentario está bajo exigencias LMIV y Ley de cadena de suministro simultáneamente. En Ford-Werke trabajan agentes en casos de uso de planificación de producción y datos de calidad donde un Production Engineer toma la decisión final. En entorno asegurador en DEVK y Gothaer los agentes soportan la gestión de siniestros con enriquecimiento estructurado del aviso de siniestro con contrato, historial y peritajes. RTL Deutschland y Lanxess (para compliance de plásticos y especialidades químicas) necesitan Document Agents para análisis de contratos y fichas de seguridad. En el propio TÜV Rheinland son relevantes Knowledge Agents para gestión de documentación de ensayo y textos normativos - con versionado claro y Audit Trail. Lufthansa y su filial MRO Lufthansa Technik trabajan con Document Agents en preparación de documentación de mantenimiento donde un Continuing Airworthiness Manager toma la decisión final. En Toyota Deutschland en Köln-Marsdorf vemos agentes de service ticket y en Recall Management una lógica de enriquecimiento que combina datos VIN, historial de taller y compliance de proveedores. En DEVK como gran asegurador de automóvil en Colonia los agentes de gestión de siniestros son especialmente relevantes, porque el volumen de siniestros de responsabilidad civil automovilística fuerza eficiencia alta de tramitación. La decisión final la toma en cada caso un perito cualificado, el [Decision Layer](/es/decision-layer/) mantiene justificación y ruta.

## Cómo Gosign atiende Colonia desde Hamburgo

Gosign no tiene emplazamiento en Colonia - el acompañamiento presencial lo organizamos desde Hamburgo y Berlín. La conexión ICE directa Hamburgo-Colonia es una de las más rápidas de Alemania, las visitas presenciales son realizables dentro del día. Concretamente: los Discovery Workshops con Engineering, Compliance y Cogestión los hacemos in situ en Köln-Mediapark, junto al Rin o directamente en el cliente - a menudo como bloque de dos a tres días. En fase de Engineering combinamos trabajo remoto con días presenciales quincenales para revisiones de arquitectura y updates de stakeholders. Los briefings con TÜV Rheinland para evaluación de conformidad EU AI Act ocurren siempre in situ, porque aquí surgen las relaciones con auditores que luego ayudan en la evaluación de conformidad. Clústeres como Mediapark, Startplatz Köln y la red IA de IHK Köln (la mayor cámara de comercio de Alemania) son espacios activos para networking técnico, sesiones con auditores y contactos en el Mittelstand renano. La distancia Colonia-Bonn es lo bastante pequeña como para que las citas relevantes EASA se puedan recoger el mismo día - una logística que ofrece ventaja clara para casos de uso cercanos a aviación. Para clientes españoles con operaciones alemanas en medios/retail, coordinamos desde Barcelona.

## Por qué Colonia funciona como punto de partida para Enterprise AI

Quien pone en producción un caso de uso IA en Colonia tiene la ventaja de defenderlo en uno de los emplazamientos de certificación europeos más importantes - TÜV Rheinland tiene sede in situ y es para muchas evaluaciones de conformidad EU AI Act la dirección natural. Eso acelera el escalado posterior considerablemente, porque la relación de auditoría se construye pronto. Se añade la diversidad sectorial - medios, comercio, seguros, química, automoción - que sirve como test para la transferibilidad de una arquitectura IA a distintos regímenes de cumplimiento. Colonia está además geográficamente cerca de Düsseldorf, Bonn y el área Rin-Meno, lo que simplifica citas multi-regionales con stakeholders. Quien en 4-6 semanas tiene un primer Document Agent con Audit Trail completo productivo en un grupo colonier, tiene así una referencia que TÜV Rheinland conoce - lo que simplifica la evaluación de conformidad posterior. Más sobre el procedimiento en [AI Agents Servicios](/es/servicios/ai-agents/).

--- Agentes IA para Empresas en Cracovia | Gosign ---
> Enterprise AI Agents en Cracovia. Gestión de proyectos local, EU AI Act compliant by design, RGPD conforme. Del PoC a la operación autónoma.

## Cracovia es la capital polaca de shared services - y precisamente por eso el emplazamiento IA más difícil

Cracovia alberga la mayor concentración de Global Capability Centers en Europa Central. ABB Krakow opera aquí su documentación global de ingeniería, Cisco Krakow una de las mayores áreas de desarrollo de software fuera de EE.UU., IBM Krakow un Delivery Center con miles de consultores, a lo que se suman ING Hubs Kraków, Capgemini, Motorola Solutions, EY GDS y el grupo IT polaco Comarch. Lo que estos emplazamientos tienen en común: procesan datos de varias jurisdicciones UE, sus outputs acaban en los libros de matrices de Europa Occidental, y cada decisión IA debe resistir simultáneamente al UODO polaco, la transposición RODO y los reguladores de los países matriz. Cracovia no es solo una ciudad polaca - es la sala de máquinas de muchos grupos europeos. Para empresas españolas con GCCs en Europa Central o operaciones Shared Services, Cracovia es el mercado IA más estratégicamente relevante de la región.

## Los tres obstáculos regulatorios para la IA en el mercado de Cracovia

Primero, RODO y la ley polaca de protección de datos (ustawa o ochronie danych osobowych): el UODO (Urząd Ochrony Danych Osobowych) espera en decisiones automatizadas bases documentadas, explicaciones recuperables y Audit Trail completo. Como los GCCs de Cracovia procesan datos de Alemania, Francia, Países Bajos y Escandinavia, cada decisión IA debe resistir también a las autoridades nacionales respectivas - una arquitectura que solo cumple RODO no basta para Shared Services de grupo. Nota para hispanohablantes: RODO es el nombre polaco del RGPD, UODO es el equivalente a AEPD.

Segundo, supervisión KNF para el creciente número de operaciones bancarias y aseguradoras en Cracovia: ING Hubs Kraków, Aon, Brown Brothers Harriman y más proveedores financieros están bajo supervisión directa o indirecta de la Komisja Nadzoru Finansowego. En Transaction Monitoring, AML Screening y propuestas de underwriting, la KNF espera los mismos justificantes que BaFin o DNB neerlandesa - incluyendo bases de modelo trazables y decisión humana final registrada.

Tercero, el EU AI Act, aplicable en Polonia desde febrero de 2025 para prácticas prohibidas; la clasificación high-risk se mantiene y, conforme a la legislación vigente, sus obligaciones se aplican desde agosto de 2026, con un aplazamiento a diciembre de 2027 acordado provisionalmente por el Digital Omnibus (mayo de 2026, adopción formal aún pendiente): screening RR.HH., evaluación de solvencia e identificación biométrica caen en la categoría high-risk. Los emplazamientos Cracovia que desarrollan u operan tales sistemas para matrices deben poder demostrar evaluaciones de conformidad, gestión de riesgo y post-market monitoring - una deuda técnica difícil de recuperar a posteriori.

## Escenarios típicos de implementación en Cracovia

Comarch Banking Software QA: la suite bancaria de Comarch la utilizan cientos de entidades financieras polacas y centroeuropeas. Document Agents revisan release notes, updates regulatorios y documentación de parches contra exigencias KNF antes de publicar un release - con Audit Trail completo hasta el PR fuente.

ABB Krakow - documentación de ingeniería: el centro global de ingeniería de ABB en Cracovia genera diariamente miles de documentos técnicos en varios idiomas. Workflow Agents extraen especificaciones regulatoriamente relevantes, las contrastan con normas específicas por país y enrutan conflictos automáticamente a revisores humanos.

ING Hubs - Transaction Monitoring: en un Shared Service ING con millones de transacciones al día, cada segundo de retraso decide sobre obligaciones regulatorias de notificación. El Decision Layer enruta sospechas dentro de los umbrales KNF y DNB, con Human-in-the-Loop forzado en cada escalación final.

Capgemini - Delivery Operations: los equipos de delivery Cracovia atienden grandes clientes en varios países UE. Agentes de routing de service desk clasifican tickets por idioma, mandante y ruta de escalación - cada decisión auditable contra el estándar regulatorio aplicable.

## Cómo Gosign atiende Polonia desde Cracovia

Gosign tiene oficina propia en Cracovia (gosign.pl) con jefes de proyecto polacoparlantes, ingenieros y responsables de cumplimiento - native Polish y English Speakers que trabajan directamente in situ en el cliente en el Krakow Technology Park, Hub:raum o en dependencias de la matriz. Discovery Workshops, Sprint Reviews y Steering corren sin barrera idiomática y sin overhead de viaje, la representación de la Rada Zakładowa se sienta en la misma sala (derechos de consulta, sin veto). Cracovia funciona como hub regional para toda Polonia: la mayoría de emplazamientos ABB, Cisco, Capgemini e IBM se alcanzan dentro de la propia ciudad, Varsovia, Wroclaw y Gdansk son alcanzables en el día. La matriz Hamburgo aporta revisiones arquitectónicas, expertise DACH-Compliance y la conexión a matrices alemanas o suizas - Delivery, día a día y contacto directo con el cliente están en el equipo Cracovia. Para un país de outsourcing con más de 350.000 ingenieros IT es la única constelación que realmente funciona: anclado localmente, conectable UE. Para clientes españoles con GCCs en Cracovia, coordinamos desde Barcelona con documentación ES/EN para stakeholders matriz hispanohablantes.

## Por qué Cracovia funciona como punto de partida para Enterprise AI

Cracovia tiene tres propiedades que la hacen única como punto de entrada. Primero, la densidad de talento: Krakow Technology Park, Hub:raum y el Krakow Startups Cluster forman el mayor ecosistema tecnológico entre Berlín y Viena, con miles de ingenieros multilingües entrenados en procesos de grupo. Segundo, la realidad multi-jurisdiccional: quien construye un AI Agent en Cracovia conformable para ABB, Cisco o ING, lo ha construido implícitamente para toda Europa Occidental. La arquitectura que en el GCC Cracovia resiste simultáneamente al UODO polaco, DNB neerlandesa y BaFin alemana, en cualquier otro país UE es solo cuestión de configuración. Tercero, la madurez operativa: los GCCs Cracovia trabajan desde hace más de quince años con grupos de Europa Occidental, los procesos internos de Change Management, ITIL, ISO 27001 y cumplimiento SOX están consolidados. Introducir aquí un nuevo componente Decision Layer no significa aprender una nueva disciplina de cumplimiento, sino ampliar una existente con una capa adicional de control.

Cert-Ready by Design en este entorno no es marketing, sino condición para cada primer día en operación. Quien empieza en Cracovia tiene detrás el test más duro antes incluso de rollout en la primera filial occidental - y quien ha implementado en Cracovia un AI Agent a prueba de operación, puede desplegar el mismo agente en [Varsovia](/es/agentes-ia-varsovia/), [Wroclaw](/es/agentes-ia-wroclaw/) o [Gdansk](/es/agentes-ia-gdansk/) en pocas semanas, porque el fundamento técnico queda idéntico y solo se ajustan los archivos de configuración regulatoria. Más contexto sobre el [EU AI Act](/es/governance/eu-ai-act/) y la aplicación polaca en el área de Governance.

--- Agentes IA para Empresas en Curitiba | Gosign ---
> Enterprise AI Agents para Curitiba y Paraná. LGPD-compliant, CLT-compatible. Tech-hub del sur de Brasil. Gestión desde São Paulo.

## Curitiba es el único tech-hub brasileño donde las corporaciones europeas de automoción se concentran más densamente que los Mittelständler alemanes en una región DACH

Si se miran los corredores industriales de Curitiba y su entorno, se ve casi un mapa de Wolfsburgo-Stuttgart-Múnich en versión tropical. Volvo do Brasil fabrica aquí camiones y autobuses. Renault Brasil opera la planta del Complexo Ayrton Senna en São José dos Pinhais. Volkswagen Curitiba (en realidad en São José dos Pinhais) y Audi están al lado. Klabin (mayor productor de papel de Brasil) tiene sede y plantas-clúster en Telêmaco Borba. El Boticário Group (segunda cadena cosmética de Brasil) se asienta en São José dos Pinhais. Positivo Tecnologia y Bematech componen el clúster tecnológico. Curitiba es la ciudad más ordenada, planificada y "europea" de Brasil - lo que la convierte en el punto natural de anclaje para los estándares industriales alemanes y europeos. Para empresas españolas con operaciones industriales en Mercosur, Curitiba es el mercado de entrada operativa.

## Los tres obstáculos regulatorios para la IA en el mercado de Curitiba

**ANTT (Agência Nacional de Transportes Terrestres) para logística y camiones**: Volvo, Renault, VW y la industria logística paranaense operan bajo supervisión ANTT para transporte pesado, sistemas de peaje y documentación de conductores. Los componentes IA en optimización de rutas, ajuste de peaje o cumplimiento de conductor deben soportar reporting ANTT - con Audit Trail que documente todo el camino de decisión desde el sensor hasta el informe de infracción CONTRAN. En operaciones pesadas con rutas Mercosur transfronterizas (Argentina, Uruguay, Paraguay) se suman obligaciones aduaneras y documentales adicionales que llevan cualquier agente logístico a una arquitectura multi-jurisdiccional.

**LGPD y la escala Boticário**: el Boticário Group opera uno de los mayores programas CRM y de fidelización de Brasil. Cada componente IA en segmentación de clientes, motores de personalización o routing de influencers debe cumplir el Art. 7 LGPD (base jurídica), el Art. 11 (datos sensibles) y la Resolução ANPD sobre DPIAs - incluido el nivel de versionado del modelo por decisión. Nota para hispanohablantes: Brasil se rige por LGPD, no por RGPD - regímenes diferentes.

**IBAMA y reporting ESG para Klabin**: Klabin es referente ESG, y precisamente por eso las exigencias de reporting automatizado (FSC, GRI, SASB) son elevadas. La IA que agrega origen de madera, consumo de agua o balances de CO2 debe ser explicable y resistir ante IBAMA, auditores externos e inversores ESG - Cert-Ready by Design aquí no es marketing sino condición de Investor Relations.

## Escenarios típicos de implementación en Curitiba

**Volvo Brasil y Renault Brasil - Supply Chain**: Document Agents leen documentación de proveedores, declaraciones aduaneras, certificados de origen Mercosur y certificados de calidad. El Decision Layer escala conflictos de cuotas Mercosur o lagunas de compliance a compras y logística - Workflow Agents alertan proactivamente ante roturas de suministro inminentes, con Audit Trail hasta la ficha maestra del proveedor. En plantas cuyos pre-proveedores están en Argentina, Uruguay y Paraguay, la documentación de origen Mercosur es uno de los temas aduaneros más críticos.

**Boticário CRM y personalización**: Document y Workflow Agents procesan contactos de clientes de tiendas, app y venta directa (vía la estructura de Revendedoras), los contrastan con estado de consentimiento LGPD, y el Decision Layer enruta recomendaciones de campaña con Human-in-the-Loop a los responsables de marketing. En un modelo de venta directa con más de un millón de consultoras, la gestión de consentimiento por contacto es uno de los temas LGPD-críticos absolutos - el Audit Trail debe retroceder hasta cada opt-in individual.

**Klabin - reporting de sostenibilidad**: Document Agents agregan inventario forestal, protocolos de serrerías y datos energéticos en reports ESG auditables según FSC, GRI y SASB. El Decision Layer marca lagunas de datos o conflictos de plausibilidad para validación humana - cada agregación con origen de datos trazable y versionado de modelo. En empresas cotizadas con inversores ESG europeos, esta profundidad de auditoría es condición para cualquier reporting CSRD.

**Positivo Tecnologia - cumplimiento de proveedores**: Document Agents verifican fuentes de semiconductores, conformidad RoHS y certificados de origen Mercosur para el mayor fabricante local de hardware IT de Brasil. Workflow Agents alertan ante cuellos de botella y documentan cada recomendación con Audit Trail hasta el certificado original del proveedor.

## Cómo Gosign atiende Curitiba desde São Paulo

Nuestra oficina en São Paulo (gosign.com.br) está a 1 hora de vuelo de Curitiba. Los Discovery Workshops con Volvo, Renault, Klabin o Boticário se celebran in situ - en Curitiba, São José dos Pinhais o directamente en las plantas. Las Compliance Reviews con referencia LGPD, ANTT o IBAMA se conducen con tu departamento jurídico y un despacho local. Las consultas sindicales para HR-Agents se coordinan con las representaciones locales de Paraná - las estructuras sindicales en la industria automotriz paranaense son menos confrontativas que en São Paulo, pero técnicamente más detalladas en la discusión de decisiones algorítmicas. Las fases de Build corren distribuidas entre Hamburgo y São Paulo - 4 horas de diferencia horaria, standups por la mañana hora SP. Las visitas presenciales en Curitiba se organizan en 24 horas. Para matrices europeas (Volkswagen, Renault, Volvo, Stellantis) reporting paralelo en alemán, inglés y portugués. Para clientes españoles con operaciones Mercosur, coordinamos desde Barcelona con documentación ES/PT.

## Por qué Curitiba funciona como punto de partida para Enterprise AI

Curitiba es el único mercado brasileño donde las corporaciones industriales alemanas y europeas se concentran de forma operativamente comparable a las regiones industriales DACH. Quien construye aquí un agente productivo para Supply Chain, control de calidad o reporting ESG lo construye en un entorno donde los promotores ya han interiorizado los estándares europeos - lo que acorta radicalmente la transición de un PoC en Paraná a un rollout productivo en Wolfsburgo, Stuttgart o Gotemburgo. Los clústeres - Tecpar, Curitiba Smart City, el corredor de innovación en torno a la Universidade Federal do Paraná - aportan talento y socios de investigación. La tradición de Curitiba como ciudad "más europea" de Brasil (planificación urbana en los años 70 inspirada en modelos europeos, alta concentración de población de origen alemán e italiano, una cámara de comercio alemana consolidada en Paraná) se traduce también en la práctica operativa: menos pérdidas de traducción en Discovery Workshops, menos fricción cultural en planificación de sprints y mayor encaje con gobierno corporativo europeo. La arquitectura [Governance by Design](/es/governance/eu-ai-act/) es Cert-Ready para RGPD y EU AI Act desde el día 1 - en Curitiba esto no es solo ventaja regulatoria, también operativa. Más en el panorama [Brasil](/es/agentes-ia-brasil/) o en el perfil [São Paulo](/es/agentes-ia-sao-paulo/).

--- Agentes IA para Empresas en Dublín | Gosign ---
> Enterprise AI Agents para Dublín. Sedes europeas de tech, supervisión DPC, EU AI Act directamente aplicable. IA auditable para el hub empresarial irlandés.

## En Dublín una sola autoridad de supervisión UE decide qué cuenta como RGPD-conforme para 450 millones de europeos

Dublín no es simplemente otra capital europea - es la capital regulatoria de la tecnología estadounidense en Europa. Google EU, Meta EU, LinkedIn EU, Microsoft EU, Stripe EU y Apple tienen aquí sus sedes UE porque Irlanda ofrece una combinación de régimen fiscal, idioma inglés y estabilidad política. A eso se suman los pesos pesados irlandeses: AIB (Allied Irish Banks), Bank of Ireland, Accenture con sede global en Dublín, Ryanair, Kerry Group y CRH (uno de los mayores fabricantes mundiales de materiales de construcción). Los "Silicon Docks" junto al Grand Canal concentran en pocos kilómetros cuadrados más talento de ingeniería en Trust & Safety, Compliance Engineering y AI-Governance que cualquier otra ciudad europea - porque aquí reside la supervisión de exactamente estos temas. Para empresas españolas con operaciones en la UE, Dublín es el mercado donde cualquier estrategia pan-europea debe defenderse.

## Los tres obstáculos regulatorios para la IA en el mercado de Dublín

Primero, la DPC (Data Protection Commission). Por el principio de One-Stop-Shop del RGPD, la DPC es para casi todas las grandes tecnológicas estadounidenses con sede UE en Irlanda la autoridad de supervisión principal - y por tanto de facto la autoridad RGPD más importante de toda la Unión. La DPC ha impuesto en los últimos años varias multas multimillonarias a Meta, Google y WhatsApp y está revisando ahora también el modelado IA y los datos de entrenamiento bajo el régimen RGPD. Quien construye IA en Dublín construye para una autoridad que examina cada fuente de datos de entrenamiento, cada decisión automatizada y cada transferencia cross-border en detalle.

Segundo, el EU AI Act, directamente aplicable en Irlanda. El gobierno irlandés ha designado al Department of Enterprise, Trade and Employment como órgano responsable para la implementación nacional y trabaja estrechamente con la DPC. Los sistemas IA high-risk de tecnológicas con sede UE Dublín se certificarán en el futuro aquí - y la expectativa es que los estándares se apliquen de forma superior a la media, porque Dublín debe demostrar políticamente que no es un resquicio de supervisión.

Tercero, la Central Bank of Ireland para todos los servicios financieros. Stripe, Mastercard EU, Citi EU, Goldman Sachs EU - todos están bajo supervisión CBI y deben documentar modelos de Compliance y Risk asistidos por IA según los estándares CBI Innovation Hub. La CBI exige explicabilidad completa, Audit Trails y monitoreo continuo de modelos. [EU AI Act Compliance](/es/governance/eu-ai-act/) y supervisión financiera deben engranar aquí.

## Escenarios típicos de implementación en Dublín

Google utiliza Dublín como hub global para AI-Model-Governance y trabaja aquí en herramientas de compliance que deben hacer explicable cada decisión de modelo ante la DPC. Meta documenta aquí el Digital Services Act (DSA) y examina modelos de moderación de contenido por riesgos sistémicos - cada decisión algorítmica debe tener Audit Trail. Stripe construye modelos globales de Payment Risk que bloquean o liberan transacciones en segundos - los modelos deben seguir siendo trazables para la CBI. AIB moderniza decisiones crediticias y necesita modelos defendibles simultáneamente bajo Art. 22 RGPD y Central Bank Code of Conduct.

En todos los casos surgen decisiones con alcance global, pero la supervisión ocurre en Dublín - a menudo con tiempos de reacción cortos y preguntas duras sobre comportamiento de modelo, datos de entrenamiento y mitigación de sesgos. El [Decision Layer](/es/decision-layer/) resuelve exactamente esa exigencia: hace persistible cada decisión IA como trace, impone Human-in-the-Loop en rutas críticas y entrega Audit Trails que resisten inspectores DPC y CBI.

La particularidad irlandesa es la actitud de la DPC: a diferencia de algunas autoridades UE, la DPC no solo investiga tras infracciones, sino que conduce con regularidad Inquiries proactivas. Quien opera productivamente una aplicación IA en Dublín debe contar con que la DPC revise sin previo aviso documentación, procedencia de datos de entrenamiento y decisiones de modelo. Cert-Ready by Design significa aquí no "cuando llegue la auditoría" - sino "permanentemente listo para inspección".

## Cómo Gosign atiende Dublín desde Hamburgo

Hamburgo-Dublín es vuelo directo de unas dos horas, con varias conexiones diarias. Trabajamos Remote-first con clientes en Dublín y Cork, con workshops presenciales para Discovery y decisiones de arquitectura. El idioma de trabajo es inglés, las rondas de steering con nuestros arquitectos de Hamburgo corren en alemán. La zona horaria (Irlanda WET, una hora por detrás de MEZ) es manejable, el estilo de negocio irlandés es pragmático y decidido. Para clientes españoles con matriz en Dublín, coordinamos desde Barcelona con documentación ES/EN.

Lo que aportamos del mercado alemán es la disciplina de ingeniería bajo supervisión estricta. Los bancos alemanes a los que atendemos tienen con BaFin y MaRisk exigencias de cumplimiento comparables a las tecnológicas irlandesas con DPC y CBI - la tonalidad regulatoria es familiar, las respuestas técnicas se transfieren directamente. Conocemos los regímenes de supervisión tech irlandeses lo suficiente como para no tener que traducir cada término, y podemos ofrecer decisiones de arquitectura concretas ya en los Discovery Workshops.

## Por qué Dublín funciona como punto de partida para Enterprise AI

Dublín tiene la exigencia regulatoria más alta para IA en Europa - y al mismo tiempo la mayor concentración de ingeniería en AI-Governance. Quien construye aquí un piloto Cert-Ready by Design tiene un caso de referencia defendible de inmediato en cualquier otro mercado UE - y que resiste ante la DPC. El clúster Silicon Docks, el Dublin Tech Cluster y el programa AI de Enterprise Ireland aportan talento, ecosistema y partners piloto. Segunda ventaja: quien construye IA en Dublín aprende automáticamente cómo funciona el cumplimiento pan-europeo. La mayoría de las tecnológicas irlandesas actúan simultáneamente en los 27 Estados miembros - cada arquitectura debe poder manejar conjuntos de reglas específicos por jurisdicción sin fragmentar el Audit Trail. Precisamente eso entrega [Governance by Design](/es/governance/eu-ai-act/). Hamburgo aporta la disciplina de ingeniería alemana, Dublín aporta el rollout UE-wide.

--- Agentes IA para Empresas en Düsseldorf | Gosign ---
> Enterprise AI Agents para Düsseldorf y NRW. Compatibles con Comité de Empresa, RGPD conforme, EU AI Act compliant. Shared Services automatizados.

## Düsseldorf es el emplazamiento alemán donde gran consumo, energía, telecomunicaciones y mittelstand industrial plantean en el espacio más reducido la misma pregunta sobre Shared Services

En el corredor entre la Königsallee, Oberkassel y la Feria de Düsseldorf se concentran Henkel, Vodafone Deutschland con sede del grupo, E.ON, Metro AG y Uniper - además de Ergo Versicherung como parte del grupo Munich Re, Rheinmetall como grupo de defensa, L'Oréal Deutschland y Trivago como mayor empresa tecnológica de Düsseldorf. A esto se suma toda Renania con Bayer y LANXESS en Leverkusen, plantas filiales de Henkel en Düsseldorf-Holthausen y un Mittelstand denso entre Krefeld, Wuppertal y Duisburg. Esta concentración genera una necesidad arquitectónica específica: la mayoría de estos grupos opera Shared Service Centers para finanzas, RR.HH. y TI que orquestan procesos entre diez y cien sociedades simultáneamente - cada una con jurisdicciones, convenios colectivos y regímenes fiscales distintos. Una arquitectura de IA que funcione aquí debe ser multi-tenant y soportar reglas de governance por entidad.

## Tres obstáculos regulatorios que dan forma a toda iniciativa de IA en el mercado de Düsseldorf

El primer obstáculo es la regulación energética específica de NRW - la BNetzA con sede en Bonn es la supervisión central para las redes de electricidad y gas, y la mayoría de las grandes empresas energéticas alemanas tienen operaciones de mercado en Düsseldorf o Essen. E.ON, Uniper y sus comercializadoras trabajan diariamente con los formatos de datos de la BNetzA y las especificaciones BDEW. Un componente de IA en previsión de carga, gestión de balance o captación de clientes debe conocer estos formatos y usarlos de forma trazable. El segundo obstáculo es la fuerte cogestión en los grupos NRW con comités de empresa y comités centrales experimentados en IG Metall, IGBCE o ver.di - una IA de Shared Service debe construir el Decision Layer arquitectónicamente de modo que las decisiones sujetas a cogestión se sometan obligatoriamente a un empleado cualificado, y los acuerdos de empresa deben pensarse desde el principio. El tercer obstáculo es la Lieferkettensorgfaltspflichtengesetz alemana y la directiva CSDDD europea sobre cadenas de suministro - Henkel, L'Oréal, Metro y Rheinmetall deben documentar riesgos para sus cadenas globales y preparar el reporting BAFA. Más contexto en [Governance EU AI Act](/es/governance/eu-ai-act/).

## Escenarios típicos de implementación en Düsseldorf

En Henkel y grupos comparables de gran consumo vemos Supply Chain Compliance Agents que procesan estructuradamente la documentación entrante de proveedores y escalan avisos de riesgo a un Sustainability Manager - con Audit Trail completo para el reporting BAFA según la ley de cadenas de suministro. En E.ON y el resto del entorno energético se trata del acompañamiento del rollout de smart meters y del procesamiento estructurado de solicitudes de conexión a la red, donde los operadores toman la decisión final. Metro AG trabaja en casos de uso de gestión de surtido y distribución de mercancías, donde un Agent evalúa datos regionales de cliente y estacionalidad y entrega una propuesta al Category Manager. En Ergo y aseguradoras comparables, los Agents apoyan la revisión de contratos en seguros de vida y la verificación de acumulaciones de siniestros. En Vodafone Deutschland vemos Customer Service Agents que estructuran las consultas de clientes, priorizan rellamadas y, en casos de reclamación regulada según las directrices de la BNetzA, entregan el caso completo a un operador con responsabilidad de gestión de quejas. En L'Oréal Deutschland y fabricantes similares de gran consumo, los Document Agents apoyan en el cumplimiento de ingredientes y en el reglamento europeo de cosméticos. En Trivago y el entorno tech de Düsseldorf vemos apoyo agéntico en atención al cliente y moderación de contenidos, que cae bajo la Digital Services Act - con escalado claro a moderadores humanos en casos sensibles. En Rheinmetall en el entorno de defensa vemos Document Agents en análisis de contratos y screening de proveedores, que deben cumplir exigencias particulares de auditoría por el control de exportaciones. En todos los casos decide el especialista cualificado, el Agent documenta y el [Decision Layer](/es/decision-layer/) preserva la fundamentación como Audit Trail.

## Cómo Gosign atiende Düsseldorf desde Hamburgo

Gosign no tiene sede en Düsseldorf - el acompañamiento presencial se opera desde Hamburgo y la oficina de Berlín. La conexión directa ICE Hamburgo-Düsseldorf tarda apenas cuatro horas, un vuelo directo es notablemente más rápido. Concretamente, organizamos la colaboración así: kick-off y Discovery Workshops se realizan in situ en Düsseldorf, normalmente como bloque de dos días con partes de ingeniería, cumplimiento y comité de empresa. En la fase de build combinamos ingeniería remota con jornadas presenciales quincenales para revisiones arquitectónicas, validación de modelos y actualizaciones a stakeholders. Cuando un grupo opera Shared Services en varias sedes de NRW, llevamos los workshops importantes in situ a las distintas filiales - Düsseldorf-Holthausen para Henkel, Essen para E.ON, Leverkusen para LANXESS o Bayer. Esta lógica presencial distribuida es una particularidad del mercado renano, porque las sedes corporativas en NRW están físicamente repartidas y los encuentros con stakeholders deben organizarse en consecuencia. La experiencia del mercado renano muestra: el pragmatismo cuenta más que la presencia, mientras la frecuencia presencial esté en los puntos clave. Clústeres como NRW.Energy4Climate en Düsseldorf los usamos para networking y discusiones técnicas. Para empresas españolas con presencia industrial en el área Rin-Ruhr (Iberdrola en operaciones de trading energético, Acerinox en aceros), coordinamos con la oficina de Barcelona (gosign.es) para asegurar comunicación bilingüe.

## Por qué Düsseldorf funciona como punto de partida para Enterprise AI

Quien lleve a producción un AI Agent en un Shared Service Center de Düsseldorf lo habrá defendido ante al menos tres jurisdicciones, varios convenios colectivos y un comité de empresa central experimentado - una arquitectura que lo logre es escalable después en cualquier otra constelación multi-entidad de Europa. A esto se añade el panorama de fomento específico de NRW: el Land NRW apoya proyectos de IA mediante varios programas de innovación, y la fase de Discovery identifica normalmente al menos una línea de fomento adecuada. Clústeres como el Digital Hub Düsseldorf-Rheinland y la red Life Science en Renania ofrecen intercambio técnico y partners de co-innovación. A esto se añaden las hochschulen de Düsseldorf y las universidades cercanas de Colonia, Bonn y Aquisgrán con sus programas de ML Engineering, así como el Forschungszentrum Jülich como ancla para High Performance Computing. Quien tenga en 4-6 semanas un primer Workflow Agent en producción en un Shared Service de NRW construye sobre una arquitectura multi-tenant y [Governance by Design](/es/governance/eu-ai-act/). Más sobre el procedimiento en [Servicios AI Agents](/es/servicios/ai-agents/).

--- Agentes IA para Empresas en España | Gosign ---
> Enterprise AI Agents para España. AESIA-ready, RGPD + LOPDGDD conforme, EU AI Act compliant. Oficina en Barcelona, proyectos en toda España.

## España es el primer país de la UE con una autoridad propia de supervisión de IA - eso cambia la planificación de cualquier implementación

España es el único Estado de la UE que ya cuenta con una autoridad nacional de supervisión de IA plenamente operativa: la AESIA (Agencia Española de Supervisión de la Inteligencia Artificial). Con sede en La Coruña, la AESIA es la respuesta española al EU AI Act y asume un papel que en la mayoría de los demás países de la UE todavía está repartido o sin cubrir. Para grupos como Santander, BBVA, CaixaBank, Sabadell, Telefónica, Iberdrola, Repsol, Inditex, Mercadona, Ferrovial, ACS, Mapfre, Amadeus IT Group, Grifols y Naturgy esto significa: claridad regulatoria antes que en otros mercados. Las áreas metropolitanas de Madrid, Barcelona, Valencia, Bilbao, Sevilla y Málaga forman los principales hubs tecnológicos del país - y todas están bajo la misma supervisión unificada de IA. Quien construye IA empresarial en España tiene un regulador que sabe lo que espera y lo comunica con claridad.

## Los tres obstáculos regulatorios para la IA en el mercado español

Primero, la AESIA y el EU AI Act. La AESIA está operativa desde 2024 y desarrolla activamente directrices para sistemas de IA de alto riesgo en el sentido del Anexo III del EU AI Act. En decisiones de RR.HH., scoring crediticio, identificación biométrica e infraestructura crítica, la AESIA espera evaluaciones de conformidad documentadas, gestión de riesgos, post-market monitoring y un Audit Trail completo. La ventaja frente a otros países de la UE: las grandes empresas españolas ya saben hoy lo que se les exigirá en 2026 y 2027 - mientras que en Alemania o Francia siguen esperando leyes de implementación nacional.

Segundo, la AEPD y la LOPDGDD. La Agencia Española de Protección de Datos supervisa el RGPD en España, complementado por la Ley Orgánica de Protección de Datos y Garantía de los Derechos Digitales (LOPDGDD) y por la LGICTE para la transparencia de IA en la relación con consumidores. En el scoring crediticio de Santander, las operaciones AML de BBVA o los sistemas de recomendación de Telefónica, la AEPD exige bases jurídicas documentadas, explicaciones disponibles a la consulta y una decisión humana final trazable. La especificidad española: en decisiones algorítmicas en el contacto con consumidores, la LGICTE exige explícitamente una obligación de transparencia que no existe en esta forma en ninguna otra jurisdicción de la UE.

Tercero, la CNMV, el Banco de España y la CNMC para la supervisión sectorial. Santander, BBVA, CaixaBank y Sabadell están bajo supervisión de la CNMV (mercado de valores) y del Banco de España (banca). En recomendaciones relevantes para MiFID, screening AML y underwriting, ambas autoridades esperan los mismos estándares de explicabilidad y auditoría que la FCA británica. La CNMC supervisa además decisiones algorítmicas relevantes para la competencia - un aspecto que en Mercadona, Inditex y el e-commerce español está cobrando cada vez más relevancia. Las empresas españolas con negocio en LATAM deben además contemplar la LGPD en Brasil y la ley argentina de protección de datos 25.326. El Comité de Empresa según el Art. 64 del Estatuto de los Trabajadores tiene derechos de información y consulta - sin derecho de veto, pero con plazos de información que deben respetarse desde el inicio del proyecto.

## Escenarios típicos de implementación en España

Scoring crediticio en Santander y BBVA: las grandes bancas españolas procesan millones de solicitudes de crédito al año en España y LATAM. Document Agents extraen datos estructurados de los formularios, el Decision Layer enruta los casos de riesgo según los umbrales del Banco de España, con Human-in-the-Loop en cada decisión final de riesgo y un Audit Trail que satisface a la vez a CNMV, AEPD y AESIA.

Recomendaciones para consumidores en Telefónica: Telefónica opera sistemas de recomendación de tarifas, contenidos y servicios de valor añadido en varios mercados hispano y lusoparlantes. Decision Agents verifican cada recomendación contra LOPDGDD, las exigencias de transparencia de la LGICTE y los requisitos de la LGPD en Brasil - cada decisión servida con justificación trazable.

Operaciones de cadena de suministro en Inditex y Mercadona: los líderes españoles del retail de moda y alimentación operan cadenas de suministro de altísima complejidad. Workflow Agents clasifican pedidos, devoluciones e incidencias con proveedores, el Decision Layer enruta escalados a responsables humanos y registra cada decisión para auditorías internas y para auditorías relevantes de competencia ante la CNMC.

Operaciones de red en Iberdrola y Naturgy: las energéticas españolas usan IA para optimización de red, Predictive Maintenance y previsión de consumo. Document Agents extraen avisos de seguridad y mantenimiento, Workflow Agents clasifican anomalías por gravedad, con decisión humana final forzada en hallazgos relevantes para seguridad - una exigencia que la AESIA exige explícitamente para IA relevante para infraestructura crítica.

## Cómo Gosign atiende toda España desde Barcelona

Gosign tiene oficina propia en Barcelona (gosign.es) como hub regional para la Península Ibérica. El equipo hispano-catalán con jefes de proyecto e ingenieros - native speakers, con todos los idiomas de stakeholders en casa - atiende las cuatro principales regiones de mercado del país: [Madrid](/es/agentes-ia-madrid/) como capital corporativa y de los reguladores, [Barcelona](/es/agentes-ia-barcelona/) como hub tecnológico, [Valencia](/es/agentes-ia-valencia/) como nodo industrial y logístico, y [Bilbao](/es/agentes-ia-bilbao/) como corazón industrial vasco. Los workshops in situ, Sprint Reviews y Steering se desarrollan en castellano, en Cataluña además en catalán, en el País Vasco con stakeholders euskaldunes cuando es necesario. Los contactos directos con la AESIA en La Coruña, con la AEPD y la CNMV en Madrid los gestiona el equipo de Barcelona, la documentación de cumplimiento se entrega bilingüe. La sede de Hamburgo aporta estándares técnicos de arquitectura y la coordinación internacional con grupos matrices alemanes, suizos y holandeses. Para empresas españolas con negocio en LATAM - Santander, Telefónica, BBVA, Mapfre - el equipo de Barcelona se coordina además con la oficina de São Paulo (gosign.com.br), de modo que RGPD, LGPD y la LFPDPPP mexicana se cubren sobre la misma arquitectura.

## Por qué España funciona como punto de partida para Enterprise AI

España tiene una ventaja estructural que ningún otro gran mercado de la UE ofrece hoy: claridad regulatoria desde una fuente central. Quien construya un AI Agent para una empresa española que aguante hoy las expectativas de la AESIA habrá desarrollado una arquitectura conforme al EU AI Act - antes de que otros países de la UE tengan siquiera operativas sus autoridades nacionales de supervisión. Para grupos alemanes, suizos y nórdicos con filiales españolas o latinoamericanas, España se convierte así con frecuencia en el primer mercado AI productivo - la conformidad con la AESIA se convierte en plantilla para la posterior ola de despliegue en otros países de la UE. Cert-Ready by Design significa aquí: una arquitectura que hoy cumple los requisitos que en el resto de la UE solo serán vinculantes en 2027. El papel pionero español no es casual, es programa - y una ventaja competitiva sustancial para quien empieza ahora. Más contexto sobre el [EU AI Act](/es/governance/eu-ai-act/) y la implementación española se encuentra en el área de governance.

--- Agentes IA para Empresas en Estocolmo | Gosign ---
> Enterprise AI Agents para Estocolmo. EU AI Act directamente aplicable, supervisión IMY. IA auditable para el hub tech de los nórdicos.

## Estocolmo es la capital tech de Escandinavia - con la autoridad de protección de datos más consecuente de la UE en segundo plano

Quien construye Enterprise AI en Estocolmo construye para una mezcla inusual: pesos pesados industriales como Ericsson, ABB, Atlas Copco, Volvo Cars (operativo en Gotemburgo, funciones de grupo en Estocolmo) y Electrolux encuentran una de las concentraciones de unicornios más densas de Europa - Spotify, Klarna, King Digital, iZettle, Truecaller, Northvolt. H&M e IKEA (vía grupo Ikano) forman el núcleo retail. La columna bancaria la componen Skandinaviska Enskilda Banken (SEB), Handelsbanken y Swedbank, el paisaje asegurador lo dominan Skandia y Folksam. En el barrio Kista Science City se asientan más de 1000 empresas tech, en el programa Stockholm Unicorn Factory madura la próxima generación. Lo que hace especial a Estocolmo: la cultura empresarial sueca combina eficiencia nórdica con pensamiento de ingeniería a largo plazo - y acepta inversiones de cumplimiento que otros mercados percibirían como freno. Para empresas españolas con operaciones pan-nórdicas, Estocolmo es el hub natural de la región.

## Los tres obstáculos regulatorios para la IA en el mercado de Estocolmo

Primero, la IMY (Integritetsskyddsmyndigheten), la autoridad sueca de protección de datos. La IMY es conocida en toda la UE por su interpretación consecuente del RGPD y ha impuesto en los últimos años varias multas de alto perfil contra empresas tech, bancos y entidades públicas - a menudo justificadas con explicabilidad insuficiente de decisiones automatizadas. Para sistemas IA significa: el Art. 22 RGPD se aplica en Suecia con la misma rigidez que en Países Bajos o España. Decision Layer con Human-in-the-Loop no es opcional sino condición de cumplimiento.

Segundo, el EU AI Act, directamente aplicable en Suecia. El gobierno sueco ha anunciado montar una autoridad propia de vigilancia de mercado coordinada con IMY y Finansinspektionen. Sistemas high-risk en Banking, infraestructura energética y gestión de personal se examinarán sistemáticamente desde 2026. [EU AI Act Compliance](/es/governance/eu-ai-act/) aquí no es abstracto, es operativo.

Tercero, Finansinspektionen para el sector financiero y PTS (Post- och telestyrelsen) para telecomunicaciones. Finansinspektionen exige desde 2023 a bancos y proveedores de pagos gobernanza de modelo IA documentada, explicabilidad y monitoreo continuo de modelos. Klarna, SEB y Handelsbanken ya trabajan con frameworks correspondientes. PTS vigila aplicaciones IA en redes telecom y examina los modelos Network Slicing de Ericsson sobre sesgo y equidad.

## Escenarios típicos de implementación en Estocolmo

Spotify desarrolla algoritmos de recomendación productivos simultáneamente en más de 180 mercados que deben seguir siendo defendibles bajo EU AI Act, IMY y varios regímenes nacionales - cada push algorítmico de un álbum tiene implicaciones regulatorias. Klarna utiliza IA para modelos Buy-Now-Pay-Later de riesgo en 17+ mercados - los modelos determinan si un consumidor obtiene un microcrédito, y deben ser explicables simultáneamente ante Finansinspektionen, BaFin, FCA y varias otras supervisiones. SEB opera Transaction Monitoring para detección de lavado con modelos IA que deben permanecer reproducibles para Finansinspektionen - cada alerta individual pasa a auditoría. Ericsson configura redes 5G para operadores móviles en todo el mundo con herramientas IA cuyas decisiones deben ser documentables para las respectivas supervisiones telecom nacionales.

En todos los escenarios no importa solo el modelo, sino que cada decisión siga siendo trazable, pueda enrutarse por conjuntos de reglas jurisdicciones-específicos y fuerce Human-in-the-Loop en rutas de escalación. Eso es arquitectura [Decision Layer](/es/decision-layer/) en estado puro.

Una particularidad sueca es el manejo de datos de autoridades: la Ley Sueca de Publicidad (Offentlighetsprincipen) exige que los documentos administrativos sean en principio públicos - lo que para aplicaciones IA en sector público y para contratistas de la administración significa que también los datos de entrenamiento y decisiones de modelo pueden quedar sujetos a divulgación. Quien construye IA para clientes públicos en Estocolmo debe diseñar la arquitectura desde el principio de modo que cumpla este estándar de transparencia.

## Cómo Gosign atiende Estocolmo desde Hamburgo

Hamburgo-Estocolmo es una conexión de vuelo directo de algo menos de dos horas, con conexiones diarias vía LH y SAS. Trabajamos Remote-first con nuestros clientes suecos, con workshops presenciales en los primeros meses de proyecto y visitas trimestrales en fase de operación. El idioma de trabajo es inglés, las rondas de steering con nuestros arquitectos de Hamburgo corren en alemán. La zona horaria es idéntica a Europa Central. Para clientes españoles con operaciones suecas, coordinamos desde Barcelona con documentación ES/EN.

Lo que nos facilita la colaboración: la cultura empresarial sueca es consensual pero técnicamente altamente competente - los participantes en workshops son en general engineering leads o product owners que entienden directamente nuestras decisiones de arquitectura. Conocemos la lógica de cogestión sueca (MBL, medbestämmande), que obliga al empleador a consultar con los sindicatos antes de introducir sistemas nuevos, y planificamos el Decision Layer de modo que las obligaciones de cogestión se cumplan arquitectónicamente - no como capa de cumplimiento posterior, sino como workflow integrado.

## Por qué Estocolmo funciona como punto de partida para Enterprise AI

Estocolmo es el único mercado en Europa donde puedes testear una arquitectura IA simultáneamente contra IMY (protección de datos), Finansinspektionen (supervisión financiera) y lógica nórdica de cogestión - y donde los stakeholders están dispuestos a invertir tiempo y recursos de ingeniería para ello. Quien construye en Estocolmo un piloto Cert-Ready by Design tiene un caso de referencia que ha pasado bajo las condiciones de protección de datos UE más estrictas - y después defendible en Helsinki, Copenhague, Oslo y el resto de Europa. El clúster Kista Science City, el Stockholm Unicorn Factory y la red Stockholm School of Economics aportan talento, partners piloto y acceso a inversores. Aportamos del contexto de ingeniería del norte de Alemania una disciplina que encaja con la cultura tech sueca - con Governance by Design, Audit Trail y la capacidad de cumplir exigencias de cumplimiento de múltiples jurisdicciones sobre un mismo sistema. Estocolmo es el mercado adecuado para escalar esta disciplina en los nórdicos.

--- Agentes IA para Empresas en Frankfurt | Gosign ---
> Enterprise AI Agents para Frankfurt. BaFin-ready, MaRisk conforme, EU AI Act compliant. Finance Agents con Audit Trail completo.

## Frankfurt es el único mercado europeo de IA donde la propia supervisión está en el mismo barrio que los usuarios

El distrito bancario entre Taunusanlage y la orilla del Meno contiene tres capas al mismo tiempo: el BCE como banco central europeo y autoridad de supervisión, la BaFin como supervisión nacional integrada con sede en Bonn pero con sucursal e intensa presencia en Frankfurt, y los grandes destinatarios licenciados - Deutsche Bank, Commerzbank, DZ Bank, KfW, Helaba, DekaBank, Deutsche Börse, ING-DiBa, BNP Paribas Deutschland. A esto se añaden los especialistas de la infraestructura del mercado como Clearstream y Eurex. Cuando un modelo de IA frankfurtés falla, el siguiente inspector especial de BaFin lo tiene encima de la mesa esa misma semana. Esa es a la vez la fortaleza del emplazamiento: nadie puede empezar aquí con un PoC que no sea desde el primer día [Cert-Ready by Design](/es/governance/eu-ai-act/). El BCE, mediante el Single Supervisory Mechanism, ejerce la supervisión directa sobre las entidades significativas, lo que obliga a los bancos frankfurteses a una doble lógica de supervisión - europea y nacional. Los componentes de IA en estas casas deben ser demostrables ante ambas supervisiones simultáneamente.

## Tres obstáculos regulatorios que toda iniciativa de IA debe superar en el centro financiero de Frankfurt

El primer obstáculo son MaRisk y BAIT como exigencias de supervisión bancaria. Cualquier modelo que intervenga en gestión de riesgos, decisión crediticia o prevención de blanqueo de capitales debe estar documentado con una validación de modelo que resista por igual a la auditoría interna y a la inspección especial de BaFin - incluyendo backtesting, análisis de sensibilidad y ciclo de entrenamiento reproducible. El segundo obstáculo es el bloque MiFID II: el Transaction Reporting según el artículo 26 MiFIR, las pruebas de Best Execution y las directrices de las Q&A de la ESMA afectan a cualquier componente automatizado de órdenes o asesoramiento. Las directrices de la EBA sobre gestión del riesgo TIC complementan esto con expectativas claras sobre outsourcing y proveedores externos. El tercer obstáculo es el propio reporting prudencial de la BaFin - FinaRisikoV, FinanzInformatikV, datos del stress test del BCE - donde los componentes de IA de soporte también cuentan como parte del perímetro de supervisión. Quien apunta al centro financiero de Frankfurt planifica gobernanza de modelos, Audit Trail y validación desde el día uno como trabajo principal, no como anexo documental.

## Escenarios típicos de implementación en Frankfurt

En la prevención de blanqueo vemos Triage Agents para los hits AML procedentes de los sistemas de monitorización de transacciones - el Agent enriquece el hit con historial del cliente, datos KYC y fuentes externas como listas de sanciones y bases PEP, evalúa la plausibilidad y entrega una propuesta al Compliance Officer, que decide si se eleva una notificación de sospecha a la FIU. En los grandes destinatarios de la liquidación de valores los Agents ayudan en el matching pre-settlement y en el tratamiento de excepciones - reconciliations costosas que hoy se hacen manualmente. En el reporting MiFID II los Agents verifican la completitud y plausibilidad de los reportes ARM antes del envío. En crédito a empresas apoyan la preparación del análisis de solvencia mediante el procesamiento estructurado de cuentas anuales, balances y documentos contractuales - el analista crediticio recibe un data room preparado con plausibility checks, no un rating automático. En la KfW y bancas de fomento similares vemos Document Agents en la pre-cualificación de solicitudes, que verifican la completitud de las solicitudes entrantes y entregan a los responsables una visión estructurada de la documentación. En la Deutsche Börse y el resto del entorno de infraestructura de mercado, los Knowledge Agents apoyan en la gestión de estándares de mercado, datos ISIN y documentación de listing. En las áreas TIC relevantes para BAIT, los Agents apoyan en la preparación estructurada de Incident Reports y en el análisis de los resultados de las pruebas de penetración. Lo que une a todos estos casos: la decisión final siempre la toma una persona, el Agent aporta la propuesta motivada, y el [Decision Layer](/es/decision-layer/) preserva la cadena completa de input, evaluación, confianza y fundamentación como Audit Trail.

## Cómo Gosign atiende Frankfurt desde Hamburgo

Gosign no tiene sede en Frankfurt - es una decisión consciente. Operamos la sede central en Hamburgo y la oficina en Berlín, Frankfurt se alcanza en menos de cuatro horas en ICE. Concretamente: Discovery, kick-off y las reuniones importantes con stakeholders de Risk y Compliance las hacemos in situ en Frankfurt - típicamente con una estancia de dos días que combina workshop, revisión arquitectónica y briefing a auditores. La fase de ingeniería se ejecuta remoto desde Hamburgo, con jornadas presenciales quincenales y slots fijos en su Compliance Office. Los workshops de validación de modelos con la auditoría interna se hacen siempre presencialmente, porque aquí la discusión técnica con responsables de Risk y Compliance moldea la arquitectura. La experiencia del Finance Agent Catalog de los últimos años muestra: la frecuencia presencial es suficiente para la mayoría de proyectos relevantes para BaFin, porque el grueso del trabajo está en la gobernanza de modelos documentada - y esa no es menos rigurosa por hacerse en remoto. Para entidades españolas con presencia bancaria en Frankfurt (Banco Santander, BBVA, CaixaBank con oficinas operativas en Alemania), el equipo de Hamburgo coordina con la oficina de Barcelona (gosign.es) para garantizar comunicación bilingüe y coherencia de cumplimiento entre el supervisor alemán y la AEPD/CNMV españolas.

## Por qué Frankfurt funciona como punto de partida para Enterprise AI

El centro financiero tiene una propiedad que lo distingue como primer paso de una estrategia de IA: quien saca aquí adelante un caso de uso lo ha defendido contra las exigencias de supervisión más estrictas de Europa. La misma validación de modelo se sostiene después en Múnich, Stuttgart o Düsseldorf, porque ninguna otra supervisión en Alemania aplica criterios más estrictos. Clústeres como el Frankfurt Main Incubator como unidad de innovación de Commerzbank, el TechQuartier en Pollux con su foco FinTech y el House of Finance en la Universidad Goethe aportan el contexto de ecosistema - incluida la posibilidad de hablar directamente con representantes de BaFin y profesionales de la supervisión en eventos. Las estructuras de Eurex y Clearstream del emplazamiento aportan adicionalmente la perspectiva de infraestructura de mercado, donde los componentes de IA deben cumplir exigencias de latencia y auditoría especialmente estrictas. A esto se añade el BCE como ancla para discusiones regulatorias. Quien tenga en 4-6 semanas un Finance Agent con Cert-Ready Audit Trail en producción en Frankfurt tiene en su portfolio el ejemplo de cumplimiento más duro del país. Más detalle sobre el procedimiento en [Servicios AI Agents](/es/servicios/ai-agents/).

--- Agentes IA para Empresas en Gdansk | Gosign ---
> Enterprise AI Agents para Gdansk y la Triciudad. Logística, energía, TI. EU AI Act compliant, RGPD conforme.

## Gdansk combina el mayor puerto de contenedores del Báltico con un clúster tech en rápido crecimiento

Gdansk y la Triciudad (Gdansk, Gdynia, Sopot) son el único lugar de Polonia donde gran logística marítima, industria de refino y outsourcing tech operan en proximidad inmediata. El Port of Gdansk es con diferencia el mayor puerto de contenedores del Báltico, con conexiones a Asia, Escandinavia y Europa Occidental. Lotos (hoy parte del grupo Orlen) opera aquí una de las mayores refinerías de Europa Central. Simultáneamente Gdansk es sede de Intel Gdansk, Amazon Development Center Gdansk, DNV GL, Schibsted Media Group, Kainos y Asseco. El Gdansk Science & Technology Park y el complejo Alchemia forman el clúster tech-físico. Esa mezcla de industria pesada, logística portuaria e ingeniería de software genera exigencias regulatorias que en ninguna otra ciudad polaca existen en esta combinación. Para empresas españolas con operaciones logísticas marítimas en el Báltico o cadenas de valor industriales con Polonia, Gdansk es el punto de entrada operativo.

## Los tres obstáculos regulatorios para la IA en el mercado de Gdansk

Primero, el Urząd Morski y la regulación marítima: el Puerto de Gdansk opera bajo supervisión de la autoridad marítima polaca, el reglamento portuario UE y múltiples convenios internacionales (SOLAS, MARPOL, ISPS-Code). La IA que clasifica movimientos de contenedores, revisa documentos aduaneros u optimiza rutas de mercancías debe hacer cada decisión trazable frente a esos marcos. Una clasificación errónea de un contenedor de mercancía peligrosa no es solo un incidente de compliance - es de notificación obligatoria a la Comisión Europea y puede detener la operación portuaria.

Segundo, UODO y KNF para las operaciones bancarias y aseguradoras en Gdansk: PKO BP, Bank Pekao y varias aseguradoras operan centros regionales de operaciones en la Triciudad. En procesamiento automatizado de solicitudes y siniestros, KNF y UODO esperan los mismos justificantes que en Varsovia - bases de modelo documentadas, Audit Trail completo y decisión humana final demostrable en cada caso de riesgo. En Amazon Development Center Gdansk se aplica adicionalmente el EU AI Act para entrenamiento de modelos sobre conjuntos de datos relevantes al consumidor. Nota para hispanohablantes: Polonia se rige por UODO como autoridad de protección de datos (equivalente a AEPD), RODO es el nombre polaco del RGPD.

Tercero, el EU AI Act en conjunción con la ley polaca de protección de datos y exigencias sectoriales: DNV GL como prestador global de clasificación emite certificados que deben ser aceptados en todo el sector naviero. Las verificaciones de certificado asistidas por IA caen bajo el régimen de evaluación de conformidad del EU AI Act - así como bajo las exigencias específicas de la International Maritime Organization. Quien emplea IA productiva en clasificación en Gdansk necesita una arquitectura que pueda atender varias supervisiones simultáneamente.

## Escenarios típicos de implementación en Gdansk

Port of Gdansk Container Tracking: con millones de movimientos de contenedores al año, cada clasificación - contenido, origen, destino, estado de mercancía peligrosa - debe ser correcta y trazable. Document Agents extraen datos estructurados de conocimientos de embarque y documentos aduaneros, el Decision Layer enruta sospechas automáticamente a inspectores humanos de aduanas con decisión final forzada en mercancía peligrosa.

Lotos Refinery Logs: la refinería Lotos en Gdansk genera diariamente millones de puntos de datos sensor y notificaciones de mantenimiento. Workflow Agents clasifican anomalías por relevancia de seguridad, el Decision Layer fuerza Human-in-the-Loop en hallazgos críticos de seguridad y registra cada decisión en el Audit Trail - un punto explícito de exigencia para la supervisión por Wojewódzki Inspektorat Ochrony Środowiska.

Amazon Development Center Model Training Compliance: la sede Gdansk de Amazon desarrolla modelos para aplicaciones de cliente final. Document Agents verifican conjuntos de datos de entrenamiento contra exigencias UODO y EU AI Act, documentan la procedencia y bloquean automáticamente el uso de datasets sin base jurídica suficiente.

DNV GL Certificado: la función de clasificación de DNV en Gdansk examina buques, plataformas y componentes contra normas internacionales. Document Agents extraen especificaciones técnicas, las contrastan con las normas aplicables y enrutan decisiones de conformidad a auditores humanos - todo el proceso documentado a prueba de auditoría.

## Cómo Gosign atiende Gdansk desde Cracovia

Gosign atiende proyectos Gdansk desde la oficina Cracovia (gosign.pl) con ingenieros y jefes de proyecto polacoparlantes. El equipo Cracovia sirve la región Trójmiasto (Gdansk, Gdynia, Sopot) con presencia regular in situ - en el Gdansk Science & Technology Park, en el clúster Alchemia y directamente en los stakeholders del Port of Gdansk, Lotos, Intel Gdansk, Amazon Development Center y DNV GL. Discovery se celebra presencial de dos días, con responsables especializados polacoparlantes, función de compliance y un representante de la Rada Zakładowa en la mesa (derechos de consulta, sin veto). Build y Sprint Reviews corren luego con el equipo Cracovia, polaco e inglés, con steerings presenciales mensuales en la Triciudad y desplazamiento rápido en escalaciones con Urząd Morski o autoridades aduaneras. La experiencia logística marítima del equipo Cracovia encuentra la expertise hamburguesa de arquitectura y compliance portuario - Hamburgo aporta la conexión con HPA, aduanas alemanas y reglamento portuario UE, Cracovia la entrega operativa en realidad portuaria polaca. Para clientes españoles con intereses Báltico, coordinamos desde Barcelona con documentación ES/PL según necesidad.

## Por qué Gdansk funciona como punto de partida para Enterprise AI

Gdansk es el mercado AI polaco más difícil, porque el paisaje regulatorio es el más complicado - autoridad portuaria, KNF, UODO, EU AI Act y regulación naviera internacional engranan. Precisamente eso convierte a Gdansk en stress-test ideal. Quien construye un AI Agent que satisface las exigencias del Port of Gdansk ha desarrollado una arquitectura que funciona prácticamente en cualquier otro mercado UE logística-intensivo. El Gdansk Science & Technology Park y el clúster Alchemia ofrecen ingenieros con esta expertise multi-domain, la Politechnika Gdanska aporta continuamente relevo. Para empresas españolas con logística marítima UE-Asia (cadenas portuarias Mediterráneo-Báltico), Gdansk es a menudo la primera sede extranjera donde Enterprise AI realmente se necesita - y por tanto el lugar donde la arquitectura debe demostrarse por primera vez en viento regulatorio real. Una implementación exitosa en Gdansk abre no solo el mercado polaco, sino entrega un plano arquitectónico desplegable sin grandes adaptaciones en [Varsovia](/es/agentes-ia-varsovia/), [Cracovia](/es/agentes-ia-cracovia/) y [Wroclaw](/es/agentes-ia-wroclaw/). Más contexto en [Polonia](/es/agentes-ia-polonia/).

--- Agentes IA para Empresas en Hannover | Gosign ---
> Enterprise AI Agents para Hannover y Baja Sajonia. Industria y Mittelstand - auditables, EU AI Act compliant. A 90 minutos de Hamburgo.

## Hannover es el emplazamiento donde el segundo mayor reasegurador del mundo, el mayor proveedor industrial alemán y una economía ferial global comparten la misma estación

En el corredor entre la estación central, el recinto ferial y List-Süd se asientan Continental como segundo mayor proveedor automotriz alemán con sede corporativa, Hannover Rück como segundo reasegurador del mundo tras Munich Re, HDI como rama de seguro primario del grupo Talanx, TUI como mayor grupo turístico europeo y VW Vehículos Comerciales con la mayor planta en Stöcken. Se suman Sennheiser en Wedemark, Enercon en Aurich como mayor fabricante alemán de aerogeneradores y Deutsche Messe AG con Hannover Messe y el legado CeBIT. Esta mezcla genera una estructura de mercado IA específica: corporaciones con alta carga de cumplimiento encuentran un Mittelstand técnico amplio con potencial de automatización concreto pero necesidad de Enterprise Governance. Baja Sajonia es tras NRW y Baviera el tercer Land industrial de la República. Para empresas españolas con proveedores o filiales industriales en Alemania, Hannover es el mercado de acceso al Mittelstand alemán.

## Tres obstáculos regulatorios que definen cualquier iniciativa IA en el mercado de Hannover

El primer obstáculo es la supervisión aseguradora para el grupo Talanx y Hannover Rück. Exigencias BaFin sobre riesgo de modelo, reporting Solvencia II y los requisitos ORSA específicos de reaseguradoras impactan cada componente IA en underwriting, reserving y modelado Cat. Hannover Rück trabaja en su día a día con modelos para carteras de catástrofes naturales y escenarios de pandemia cuya validación sigue los estándares más altos y cuyos componentes IA deben defenderse contra marcos internos de riesgo de modelo.

El segundo obstáculo es el Bundes-Immissionsschutzgesetz BImSchG, relevante en el día a día para Continental como gran productor industrial y para Enercon como operador eólico - cualquier componente IA en monitoreo de emisiones o control de instalaciones debe ser demostrable en la lógica de permiso BImSchG.

El tercer obstáculo es la fuerte cogestión IG Metall en las plantas de Continental y VW y en Sennheiser - una aplicación IA con referencia personal o captura de rendimiento solo supera los Betriebsräte si el [Decision Layer](/es/decision-layer/) fuerza la decisión humana final y el Audit Trail documenta la justificación. Nota para clientes españoles: el comité de empresa alemán (Betriebsrat) tiene cogestión con veto en § 87 BetrVG - más vinculante que el Comité de Empresa español. Más sobre el marco en [EU AI Act](/es/governance/eu-ai-act/).

## Escenarios típicos de implementación en Hannover

En Continental vemos agentes de datos de calidad en la producción de neumáticos que consolidan datos de medición de varias plantas y escalan anomalías a Quality Engineers - con evaluación trazable. En la planta VW Vehículos Comerciales de Stöcken trabajan agentes en casos de uso de planificación de producción y gestión de proveedores donde un Production Steering toma la decisión final. En HDI y Hannover Rück los agentes soportan la gestión de siniestros y el Cat-Modelling - el agente enriquece los resultados de modelo con datos contractuales y fuentes externas, los underwriters deciden. En TUI los agentes de servicio al cliente ayudan a estructurar solicitudes y priorizar rellamadas. En Sennheiser y el Mittelstand ampliado vemos Document Agents para facturas entrantes, análisis de contratos y comunicación con proveedores - la entrada típica cuando se automatiza un cuello de botella concreto en contabilidad. En Enercon los agentes trabajan en preparaciones Predictive Maintenance para aerogeneradores donde los técnicos de servicio deciden cuándo se produce un cambio de componente - el agente estructura datos sensor, el service manager decide sobre la ventana de mantenimiento. En Deutsche Messe AG vemos Knowledge Agents en atención a expositores y visitantes que estructuran consultas recurrentes y las traspasan a la planificación ferial. El banco regional de desarrollo NBank trabaja con Document Agents en revisión de solicitudes de proyectos de promoción IA - aquí un agente ayuda a la preparación estructurada de expedientes para los gestores. En cada caso el Audit Trail mantiene la cadena de justificación.

## Cómo Gosign atiende Hannover desde Hamburgo

Hannover es el mercado alemán mayor más cercano a nuestra sede Hamburgo - la conexión ICE directa Hamburgo-Hannover requiere escasos 90 minutos. Las visitas presenciales son factibles en el día. Concretamente: los Discovery Workshops con Engineering, Compliance y Cogestión los conducimos in situ, a menudo como bloque de uno a dos días. En fase de Engineering combinamos trabajo remoto con días presenciales semanales, porque el trayecto corto lo permite sin obstáculos logísticos. Revisiones de arquitectura, validaciones de modelo para Solvencia II y negociaciones de cogestión se celebran in situ. Para Continental y Hannover Rück con sedes corporativas en el centro de Hannover estamos a menudo varias veces al mes in situ. Clústeres como Hannover Impuls y la Innovationsnetzwerk Niedersachsen los utilizamos para discusiones técnicas y para contactos con NBank que acompaña muchos proyectos IA en el Mittelstand. La Hannover Messe como mayor feria industrial mundial entrega anualmente un panorama compacto de mercado y es para muchos de nuestros proyectos un ancla natural para decisiones de producto. Para clientes españoles con matriz corporativa alemana, coordinamos desde Barcelona con documentación paralela ES/DE.

## Por qué Hannover funciona como punto de partida para Enterprise AI

Hannover tiene una propiedad que no existe en ningún otro mercado alemán: la combinación de sedes corporativas con alta carga de cumplimiento y un Mittelstand técnico amplio que no solo funciona como cadena de suministro de los grupos sino que atiende mercados globales propios. Quien aquí pone en producción un primer AI Agent lo ha probado típicamente contra cumplimiento asegurador, cogestión industrial y pragmatismo Mittelstand - los tres stress-test más duros que ofrece el mercado alemán. Se añade la posición geográfica: 90 minutos a Hamburgo, dos horas a Berlín, tres horas a Fráncfort. Hannover es el ancla natural para un escalado multi-regional en el espacio DACH. El talento de ML Engineering viene de la Leibniz Universität Hannover con su fuerte facultad de Informática, del centro de investigación L3S con foco en Web Science y ML, y del emplazamiento DFKI como ancla de investigación IA aplicada. Quien en 4-6 semanas tiene un agent en producción en un grupo o Mittelständler hannoverés, se beneficia de la proximidad al Engineering de Hamburgo y puede transferir el caso de uso posteriormente a toda la red alemana del norte. Más sobre el procedimiento en [AI Agents Servicios](/es/servicios/ai-agents/).

--- Agentes IA para Empresas en Lisboa | Gosign ---
> Enterprise AI Agents en Lisboa. EU AI Act directamente aplicable, RGPD conforme. Gestión de proyectos local. Del PoC a la operación autónoma.

## Lisboa es la capital tech de más rápido crecimiento en Europa - con un régimen de protección de datos sorprendentemente estricto

En los últimos diez años Lisboa ha pasado de ser destino turístico a hub tech para Europa Occidental. EDP (Energias de Portugal) y Galp Energia forman el núcleo energético, Millennium BCP y Caixa Geral de Depósitos la columna bancaria, Jerónimo Martins (Pingo Doce, Recheio, Biedronka en Polonia) es el mayor retailer alimentario del país. NOS y Altice Portugal dominan el panorama de telecomunicaciones. Se suman los campeones tech portugueses Farfetch (marketplace de lujo), OutSystems (plataforma Low-Code de escalado global) y Feedzai (detección de fraude basada en IA para bancos en todo el mundo). En el Beato Innovation District y el Hub Criativo do Beato se asientan cientos de startups - la ciudad atrae talento de toda Europa, porque el coste de vida es inferior al de Berlín o Ámsterdam y el ecosistema tech se vuelve cada vez más denso. Para empresas españolas con operaciones ibéricas, Lisboa es el mercado hermano obligatorio - coordinación Barcelona + Lisboa permite cubrir la Península bajo una misma arquitectura Enterprise AI.

## Los tres obstáculos regulatorios para la IA en el mercado portugués

Primero, la CNPD (Comissão Nacional de Proteção de Dados) junto con la Lei 58/2019, la ley portuguesa de transposición del RGPD. La CNPD es una de las autoridades de protección de datos más consecuentes de Europa del Sur y ha impuesto en los últimos años varias multas de alto perfil a empresas de telecomunicaciones, bancos y entidades públicas. La CNPD examina sistemas IA especialmente en cuanto a transparencia, minimización de datos y derecho a decisión humana según Art. 22 RGPD. Quien construye IA en Lisboa construye para una autoridad que toma en serio las auditorías de algoritmos - un régimen comparable en rigor con la AEPD española, pero con peculiaridades propias en derecho laboral.

Segundo, el EU AI Act, directamente aplicable en Portugal. El gobierno portugués ha designado a la ANACOM (Autoridade Nacional de Comunicações) y a la CNPD como órganos coordinadores para la transposición del EU AI Act, con el plan de montar una autoridad propia de vigilancia de mercado. Los sistemas high-risk - especialmente en sector energético y financiero - se examinarán sistemáticamente desde 2026.

Tercero, Banco de Portugal y CMVM (Comissão do Mercado de Valores Mobiliários) para todos los servicios financieros. Ambas autoridades han formulado expectativas conjuntas sobre gobernanza de modelos IA: explicabilidad, Audit Trail, reproducibilidad, mitigación de sesgo. Bancos como Millennium BCP y Caixa Geral de Depósitos ya trabajan en frameworks correspondientes. [EU AI Act Compliance](/es/governance/eu-ai-act/) y supervisión financiera engranan aquí.

## Escenarios típicos de implementación en Lisboa

Millennium BCP emplea IA en análisis crediticio para clientes pymes y necesita modelos reproducibles bajo supervisión CNPD y Banco de Portugal - cada denegación debe ser justificable dentro del plazo legal. EDP opera infraestructura Smart Meter en Portugal, España y Brasil y utiliza IA para previsión de carga y detección de anomalías en la red eléctrica - los modelos deben documentarse para la autoridad energética ERSE. Feedzai desarrolla modelos de detección de fraude para bancos en todo el mundo, con sede en Lisboa - cada actualización de modelo debe permanecer trazable en Audit Trail, porque los clientes operan en mercados regulados. Farfetch utiliza algoritmos de recomendación para productos de lujo en más de 190 países - aquí colisionan exigencias CNPD con los regímenes de protección de datos de UK, EE.UU. y China.

En todos los escenarios se trata de modelos IA que no viven en laboratorio sino en lógica de negocio regulada con consecuencias medibles. El [Decision Layer](/es/decision-layer/) resuelve la cuestión arquitectónica: Audit Trail hasta nivel SQL, Human-in-the-Loop en casos escalables, Cert-Ready by Design.

Una particularidad portuguesa es la Comissão de Trabalhadores - la representación de los trabajadores con derechos de información y consulta en la introducción de sistemas IA. Construimos el Decision Layer de modo que estas obligaciones no deban traducirse a posteriori, sino que funcionen como parte de la governance. Eso es especialmente relevante para grupos como Jerónimo Martins, cuya plantilla está en cifra de cinco dígitos y cuyas decisiones IA tienen influencia directa sobre asignación de personal y planificación de turnos.

## Cómo Gosign atiende Portugal desde Lisboa

Gosign tiene oficina propia en Lisboa (gosign.pt) con equipo portugués - native speakers, dirección de proyectos local, contacto directo con CNPD, Banco de Portugal y CMVM. La oficina Lisboa es hub regional para el mercado portugués: Discovery Workshops, Sprint Reviews y Steering corren in situ en el cliente en el Beato Innovation District, en el Hub Criativo do Beato o directamente en las sedes corporativas de Galp Energia, EDP, Millennium BCP, Caixa Geral de Depósitos y Jerónimo Martins. Para los campeones tech portugueses Feedzai, OutSystems y Farfetch trabajamos al mismo nivel en la cultura local de ingeniería, con workshops y code reviews en portugués, documentación de cumplimiento en portugués e inglés, la Comissão de Trabalhadores desde el inicio en la mesa. Cooperamos estrechamente con Startup Lisboa y el pool local de talento. En proyectos LATAM, el equipo Lisboa se conecta adicionalmente con la oficina São Paulo (gosign.com.br) - Brasil y Portugal como mercado lusófono conectado, con idioma común, cultura de negocio común y una arquitectura que atiende LGPD y RGPD en paralelo. Para clientes españoles con operaciones ibéricas, coordinación conjunta Barcelona + Lisboa - cobertura Península bajo un mismo proveedor, documentación bilingüe ES/PT. La matriz Hamburgo asume cuestiones arquitectónicas de fondo y la conexión con matrices alemanas y del norte de Europa.

## Por qué Lisboa funciona como punto de partida para Enterprise AI

Portugal es lo bastante pequeño como para involucrar directamente en un proyecto IA a varios stakeholders sectoriales, y lo bastante grande como para tener exigencias de cumplimiento reales. Quien construye en Lisboa un piloto Cert-Ready by Design tiene un caso de referencia que ha pasado bajo estándares CNPD y EU AI Act - y que después es defendible en Brasil (LGPD), España (LOPDGDD) y el resto de Europa. El Lisbon Tech Hub, Startup Lisboa y el Beato Innovation District aportan talento, acceso a inversores y partners piloto. Aportamos la experiencia de construir sistemas IA que siguen siendo productivos también bajo supervisión estricta CNPD - con Governance by Design y la disciplina que marca la práctica alemana de protección de datos. Lisboa es el mercado adecuado para escalar esta disciplina en la Península Ibérica. Y para empresas que utilizan el mercado portugués como trampolín al espacio lusófono (Brasil, Angola, Mozambique), Lisboa es el único emplazamiento europeo desde el que este puente se puede construir arquitectónicamente limpio.

--- Agentes IA para Empresas en Londres | Gosign ---
> Enterprise AI Agents para Londres. UK GDPR + EU GDPR dual-compliance, FCA-aware. IA auditable para la City y más allá.

## En Londres cada decisión IA debe cumplir simultáneamente dos regímenes de protección de datos - es la brecha de cumplimiento más cara de Europa

Desde el Brexit, Londres ya no es la plaza financiera UE sino el doble-cumplimiento europeo. HSBC, Barclays, Lloyds Banking Group, NatWest, Standard Chartered y Prudential operan aquí sus sedes corporativas. BP y Shell tienen en Londres su sede global, AstraZeneca coordina desde aquí estudios clínicos globales, y en el ámbito tech se asientan Revolut, DeepMind y ARM Holdings. La "Square Mile" sigue siendo el mayor centro financiero de Europa y probablemente el único mercado donde una sola empresa debe cumplir simultáneamente regulación UK, UE y régimen de sanciones EE.UU. - a menudo en el mismo sistema. Quien construye Enterprise AI aquí no construye para una jurisdicción, sino para una intersección. Para empresas españolas con matriz o filial londinense, es el mercado donde la estrategia IA dual se valida primero.

## Los tres obstáculos regulatorios para la IA en el mercado de Londres

Primero, el doble régimen de protección de datos UK GDPR más EU GDPR. Desde el Brexit rige para empresas británicas el UK GDPR, pero en cuanto una empresa tiene negocio con clientes UE - lo que hacen prácticamente todos los grupos londinenses - aplica en paralelo el EU GDPR vía mecanismo de Adequacy. El ICO (Information Commissioner's Office) examina el lado UK, y para el lado UE es competente según la filial UE otra autoridad distinta. Ambos regímenes divergen en cuestiones de detalle, y ambos siguen evolucionando en direcciones diferentes - por ejemplo en decisiones automatizadas según Art. 22 o en mecanismos de transferencia. Quien construye aquí una arquitectura IA tiene que ser dual-conforme.

Segundo, el UK AI White Paper, que prevé un enfoque sectorial en lugar de - como el EU AI Act - una ley horizontal. La FCA (Financial Conduct Authority), la PRA (Prudential Regulation Authority), el ICO y la CMA (Competition and Markets Authority) desarrollan cada una sus propias directrices IA sectoriales. La FCA ha formulado ya con el AI Public-Private Forum expectativas concretas sobre gobernanza de modelo, explicabilidad y responsabilidad del consejo. Quien construye Banking AI en Londres construye para al menos cuatro supervisores simultáneamente - en profundidad distinta.

Tercero, DSA y DMA para plataformas londinenses con negocio UE. Quien aborda consumidores europeos desde Londres cae bajo la regulación UE de plataformas - independientemente del derecho UK. El [EU AI Act Compliance](/es/governance/eu-ai-act/) se convierte aquí en interfaz: empresas británicas con negocio UE sustancial deben comportarse prácticamente como empresas UE, sin disfrutar del escudo de la pertenencia UE.

## Escenarios típicos de implementación en Londres

HSBC opera detección global de fraude con modelos IA productivos en más de 60 países y que deben resistir simultáneamente ante FCA, ICO, supervisión UE y US OCC. Lloyd's of London utiliza IA para decisiones de underwriting en seguros especializados - cada evaluación automatizada de riesgo debe documentarse ante Lloyd's Performance Management Directorate y permanecer reproducible en siniestro. La propia FCA exige a sus entidades reguladas cumplimiento de Conduct Rule con herramientas IA que hagan trazable la responsabilidad del consejo. AstraZeneca documenta estudios clínicos para MHRA y en paralelo para EMA - cada evaluación asistida por IA debe ser demostrable en ambos regímenes.

En todos los escenarios, la cuestión central no es "¿funciona el modelo?" sino "¿podemos defender la decisión cross-jurisdiccionalmente?". El [Decision Layer](/es/decision-layer/) resuelve exactamente eso: enruta cada decisión a través de conjuntos de reglas jurisdicciones-específicos, persiste el Audit Trail con metadatos completos y fuerza Human-in-the-Loop en decisiones relevantes para examen en varios regímenes.

Se añaden los supervisores a nivel personal: el UK Senior Managers and Certification Regime (SMCR) responsabiliza personalmente a directivos individuales por las decisiones IA de sus áreas. Quien como Director de una entidad financiera británica introduce IA sin poder documentar la gobernanza de modelo, arriesga una prohibición personal del sector. Es un escalón más duro que las multas RGPD en el continente - y es la razón por la que los bancos británicos toman en serio Cert-Ready by Design desde hace años.

## Cómo Gosign atiende Londres desde Hamburgo

Hamburgo-Londres es vuelo directo de unos 90 minutos, con varias conexiones diarias vía LH, BA y EasyJet. Trabajamos Remote-first con clientes en la City y Canary Wharf, con workshops presenciales para Discovery, decisiones de arquitectura y revisiones críticas de cumplimiento. El idioma de trabajo es inglés, las rondas de steering con nuestros arquitectos de Hamburgo corren en alemán. La zona horaria (Londres GMT/BST, una hora por detrás de MEZ) es manejable y solapa completamente con nuestro día laboral de Hamburgo. Para clientes españoles con matriz UK, coordinamos desde Barcelona con documentación ES/EN.

Lo que aportamos del mercado alemán es experiencia con regulación dual. Los bancos alemanes trabajan por defecto con BaFin, BCE y FCA simultáneamente - la lógica de cumplimiento cross-jurisdicción nos es familiar. Conocemos las expectativas FCA sobre gobernanza de modelo lo suficiente como para tomar decisiones arquitectónicas concretas ya en el primer workshop, en vez de tener que traducir reguladores primero.

## Por qué Londres funciona como punto de partida para Enterprise AI

Londres tiene la mayor presión regulatoria para IA en Europa, porque aquí chocan dos regímenes de protección de datos que divergen. Quien construye en Londres un piloto Cert-Ready by Design dual-conforme tiene un caso de referencia defendible en cualquier otro mercado - incluidos EE.UU., Suiza y APAC. El clúster Silicon Roundabout, Canary Wharf, el programa London Tech City y la red Tech Nation aportan talento, ecosistema y partners piloto. Segunda ventaja: Londres fuerza a una arquitectura que no está construida para una jurisdicción única, sino para conjuntos de reglas jurisdicciones-específicos sobre el mismo Audit Trail. Eso es [Governance by Design](/es/governance/eu-ai-act/) - y si funciona en Londres, funciona en cualquier sitio. Hamburgo aporta la disciplina de ingeniería alemana, Londres aporta el stress-test global de cumplimiento.

--- Agentes IA para Empresas en Madrid | Gosign ---
> Enterprise AI Agents para Madrid. Sede de la AESIA, regulación del EU AI Act, RGPD + LOPDGDD conforme. Agentes auditables para el centro empresarial de España.

## Madrid es la única capital europea donde los reguladores nacionales de protección de datos y de finanzas están a pocos minutos a pie unos de otros

Quien construye IA empresarial en Madrid lo hace literalmente en la puerta de la supervisión española. La AEPD (Agencia Española de Protección de Datos), la CNMV (Comisión Nacional del Mercado de Valores), el Banco de España y la CNMC (Comisión Nacional de los Mercados y la Competencia) - los cuatro tienen su sede central en Madrid. A esto se añade el aparato político: el Ministerio de Asuntos Económicos y el Ministerio de Industria, Comercio y Turismo deciden aquí sobre la implementación del EU AI Act. En el sector empresarial conviven Banco Santander, BBVA, Telefónica, Repsol, Iberdrola (HQ Bilbao, pero Madrid es operativamente fuerte), Mapfre, Ferrovial, ACS, Naturgy, Red Eléctrica y Amadeus IT. Quien construye aquí una arquitectura de IA, lo hace para una concentración de grandes corporaciones y autoridades de supervisión que en Europa solo Frankfurt y París pueden equiparar.

## Los tres obstáculos regulatorios para la IA en el mercado madrileño

Primero, la AEPD y la LOPDGDD (Ley Orgánica 3/2018), la ley española de implementación del RGPD con endurecimientos. La AEPD es conocida en toda la UE por su interpretación estricta del Art. 22 RGPD - las decisiones totalmente automatizadas en España solo son admisibles con una decisión humana final documentada. La autoridad ha impuesto en los últimos años multas de ocho y nueve cifras de euros, a menudo contra bancos y operadoras de telecomunicaciones. El Decision Layer con Human-in-the-Loop aquí no es opcional, es requisito de cumplimiento.

Segundo, la AESIA (Agencia Española de Supervisión de la Inteligencia Artificial). España es el primer país de la UE con una autoridad dedicada a la supervisión de IA. La sede central está en La Coruña, pero operativa y políticamente muchas decisiones se toman en Madrid. La AESIA supervisará desde 2026 los sistemas de alto riesgo según el EU AI Act y podrá imponer prohibiciones de uso. Quien lance modelos al mercado en Madrid debe documentar desde el primer día para una auditoría AESIA.

Tercero, la CNMV y el Banco de España para todo el sector financiero. Ambas autoridades han formulado expectativas conjuntas sobre la gobernanza de modelos de IA y supervisan a bancos, aseguradoras y gestoras de activos en términos de explicabilidad, Audit Trail y reproducibilidad. La CNMV exige desde 2024 un Audit Trail completo en recomendaciones de inversión asistidas por IA. El [EU AI Act Compliance](/es/governance/eu-ai-act/) y la supervisión financiera se entrelazan aquí.

## Escenarios típicos de implementación en Madrid

Banco Santander opera evaluación crediticia en más de 10 países y necesita modelos de IA reproducibles bajo supervisión simultánea de AEPD, CNMV y Banco de España - cada denegación debe ser justificable dentro del plazo legal. Telefónica analiza CDR (Call Detail Records) para detección de fraude y optimización de red en más de 12 mercados - los modelos deben ser auditables ante la AEPD y ante autoridades equivalentes en LATAM. Mapfre utiliza IA en la gestión de siniestros y necesita modelos que justifiquen ante el asegurado cualquier estimación automática del importe del daño. Iberdrola planifica desde Madrid operaciones de red eléctrica que entran en categorías de alto riesgo del EU AI Act - los modelos deben estar documentados para Red Eléctrica y para la autoridad nacional CNMC.

En cada uno de estos casos, el [Decision Layer](/es/decision-layer/) es la arquitectura que reúne Audit Trail hasta el nivel SQL, escalado Human-in-the-Loop y Cert-Ready by Design - exactamente lo que las autoridades madrileñas quieren ver al mismo tiempo.

Una particularidad madrileña es la complejidad corporativa: la mayoría de las grandes empresas españolas están entrelazadas más allá de Iberoamérica - Santander en más de 10 países, BBVA en México y Turquía, Telefónica en Brasil y Alemania. Una arquitectura de IA en Madrid debe ser capaz de aplicar simultáneamente conjuntos de reglas específicos por jurisdicción para RGPD, LGPD, LFPDPPP mexicana y KVKK turca - todo sobre el mismo Audit Trail. Quien construya esto en Madrid tendrá una arquitectura para todo el mundo hispanohablante.

## Cómo Gosign atiende Madrid desde Barcelona

Gosign atiende los proyectos madrileños desde la oficina de Barcelona (gosign.es) con jefes de proyecto e ingenieros hispanohablantes. La conexión AVE de alta velocidad Barcelona-Madrid tarda apenas dos horas y media - las visitas semanales in situ a Santander, BBVA, Telefónica, Mapfre, Iberdrola y Repsol no son un esfuerzo logístico, son rutina. Los Discovery Workshops, Sprint Reviews y Steering se realizan en el Paseo de la Castellana, en Las Tablas o directamente en las sedes corporativas, con los responsables funcionales hispanohablantes y los representantes del Comité de Empresa en la misma mesa. Madrid es la sede de los principales reguladores españoles - AEPD, CNMV, Banco de España y CNMC están a pocos minutos a pie unos de otros - y el equipo español está allí regularmente para gestionar coordinaciones regulatorias, preparaciones de auditoría y citas en sandbox de forma directa. La sede de Hamburgo asume la coordinación DACH e internacional y las revisiones arquitectónicas - la operación diaria, la cultura corporativa madrileña y los contactos con autoridades los lleva el equipo de Barcelona.

## Por qué Madrid funciona como punto de partida para Enterprise AI

Madrid es la única ciudad de Europa donde puede llegar a pie a las cuatro autoridades de supervisión españolas - y donde la mayoría de respuestas regulatorias están disponibles en cuestión de días, no de semanas. Quien construya aquí un piloto Cert-Ready by Design tendrá un caso de referencia que ha pasado los estándares de AEPD, AESIA, CNMV y Banco de España. Los clústeres Madrid in Motion, Impact Hub Madrid y Wayra Madrid (Telefónica) aportan talento, partners piloto y acceso a inversores.

Aportamos del mercado alemán la experiencia de construir sistemas de IA que no solo funcionan bajo regímenes de supervisión estrictos, sino que se mantienen productivos - con Governance by Design y Audit Trail. Madrid es el mercado adecuado para llevar esta disciplina al corazón de la economía española.

--- Agentes IA para Empresas en Polonia | Gosign ---
> Enterprise AI Agents para Polonia. EU AI Act compliant, RGPD conforme, compatible con Rada Zakładowa. Oficina en Cracovia, proyectos en toda Polonia.

## Polonia es simultáneamente el mayor país de outsourcing IT de Europa y una economía digital propia

Polonia es el único mercado UE donde dos economías tech estructuralmente distintas coexisten. Por un lado los Global Capability Centers de grupos de Europa Occidental en [Cracovia](/es/agentes-ia-cracovia/), [Wroclaw](/es/agentes-ia-wroclaw/) y [Gdansk](/es/agentes-ia-gdansk/) - ABB, Cisco, IBM, Capgemini, UBS, Bosch, LG Electronics, Amazon Development Center, Volvo, Toyota Motor Manufacturing Poland. Por otro lado los grupos puramente polacos con sede en [Varsovia](/es/agentes-ia-varsovia/) y Cracovia: PKO BP, Pekao, Santander Bank Polska, ING Bank Śląski, mBank, BNP Paribas Polska, PZU, Warta, Allegro, LPP, Dino Polska, Biedronka (Jerónimo Martins), CCC, Ciech, Grupa Azoty, JSW, KGHM, CD Projekt, Asseco, Comarch. Esta doble estructura genera un mercado IA que debe atender simultáneamente el cumplimiento de grupo de los países matriz y la regulación polaca propia. Para empresas españolas con nearshoring IT en Polonia o joint ventures industriales, Polonia es el mercado de validación arquitectónica.

## Los tres obstáculos regulatorios para la IA en el mercado de Polonia

Primero, KSeF y la facturación electrónica: KSeF (Krajowy System e-Faktur) se vuelve obligatorio por fases en Polonia para todas las empresas. Cientos de miles de facturas entrantes y salientes al día deben ser estructuradas, validadas y archivadas - cada extracción o clasificación asistida por IA debe ser KSeF-conforme. Grupos como Orlen, Allegro, LPP y PGE están rediseñando actualmente sus pipelines documentales. Quien trabaja aquí sin bases de modelo trazables arriesga inspecciones fiscales con carga de prueba incierta.

Segundo, UODO, RODO y la ley polaca de protección de datos: el UODO (Urząd Ochrony Danych Osobowych) se ha vuelto en los últimos años uno de los reguladores de protección de datos UE más activos. En perfilado y toma de decisiones automatizada según Art. 22 RGPD, el UODO espera bases jurídicas documentadas, explicaciones recuperables y Audit Trail completo. La especificidad polaca: en decisiones RR.HH. relevantes la Rada Zakładowa tiene derechos de información y consulta que deben ser forzados por la arquitectura. Nota para hispanohablantes: RODO es el nombre polaco del RGPD, UODO el equivalente a AEPD. Rada Zakładowa = derechos de consulta, sin veto (a diferencia del comité de empresa alemán, que sí tiene derecho de veto).

Tercero, KNF, NBP y el EU AI Act: la Komisja Nadzoru Finansowego con sede en Varsovia supervisa el sector financiero polaco y espera en AML, KYC, scoring crediticio y gestión de siniestros decisión humana final demostrable en casos de riesgo. El EU AI Act rige desde febrero de 2025 para prácticas prohibidas; la clasificación high-risk se mantiene y, conforme a la legislación vigente, sus obligaciones se aplican desde agosto de 2026, con un aplazamiento a diciembre de 2027 acordado provisionalmente por el Digital Omnibus (mayo de 2026, adopción formal aún pendiente) - en Polonia sin ley nacional de transposición, es decir, directamente aplicable. Quien emplea IA high-risk en RR.HH., Banking o seguros, necesita evaluaciones de conformidad, gestión de riesgo y post-market monitoring a un nivel que resista una inspección KNF o UODO.

## Escenarios típicos de implementación en Polonia

PKO BP y mBank - AML Operations: los bancos polacos procesan millones de transacciones al día. Document Agents extraen identificadores, el Decision Layer enruta sospechas según umbrales KNF, con Human-in-the-Loop en cada escalación final y Audit Trail completo para la supervisión.

Allegro, LPP y Dino Polska - KSeF Pipeline: los mayores retailers polacos y el líder de e-commerce están bajo presión KSeF. Document Agents extraen datos estructurados de factura, validan contra el esquema KSeF y enrutan desviaciones a revisores humanos en contabilidad.

JSW y KGHM Operations: los grupos mineros y metalúrgicos polacos generan diariamente enormes cantidades de datos sensor y notificaciones de seguridad. Workflow Agents clasifican anomalías, escalan incidentes a jefes de turno y registran cada decisión para Wojewódzki Inspektorat Ochrony Środowiska y evaluaciones KNF relevantes.

Comarch y Asseco Software Operations: los dos grupos de software polacos desarrollan software bancario y asegurador para toda Europa Central. Document Agents revisan documentación de release contra exigencias KNF, BaFin y FINMA antes de publicar un release.

## Cómo Gosign atiende toda Polonia desde Cracovia

Gosign tiene oficina propia en Cracovia (gosign.pl) como hub regional para el mercado polaco. El equipo polaco con jefes de proyecto e ingenieros - native speakers polacos, inglés fluido - cubre los cuatro grandes clústeres tech del país: Varsovia como capital corporativa y regulatoria, Cracovia como hub Shared Services, Wroclaw como híbrido industrial-IT y Gdansk como emplazamiento portuario y tech. Los workshops presenciales, Sprint Reviews y Steering corren en polaco, sin barrera idiomática ni overhead de viaje desde el exterior. La matriz Hamburgo aporta estándares arquitectónicos, expertise DACH-Compliance y la conexión con matrices alemanas, suizas y neerlandesas - Delivery, día a día y contacto directo con el cliente están en el equipo Cracovia. Para clientes españoles con operaciones en Polonia (Biedronka/Jerónimo Martins con matriz lusófona que también atiende mercado hispano, joint ventures industriales, nearshoring IT), coordinamos desde Barcelona con documentación ES/PL/EN según necesidad. Esta estructura es decisiva para Mittelständler polacos y filiales corporativas que quieren un estándar de calidad DE-orientado sin que la barrera idiomática entre en casa.

## Por qué Polonia funciona como punto de partida para Enterprise AI

Polonia es para grupos alemanes, suizos y neerlandeses el stress-test IA más próximo. Quien pone en producción un AI Agent en Polonia que cumple simultáneamente KSeF, UODO, KNF y el EU AI Act, ha desarrollado una arquitectura que en cualquier mercado de Europa Occidental está a un cambio de configuración. Polonia combina máxima disponibilidad de talento (Cracovia, Wroclaw, Varsovia, Gdansk) con máxima presión regulatoria (KNF, UODO, KSeF, EU AI Act, RODO). El clúster Krakow Technology Park, Warsaw Spire Tech, Wroclaw Technology Park y Gdansk Science & Technology Park forma el mayor paisaje tech conexo de Europa Central y Oriental.

A eso se añade una propiedad que hace a Polonia especialmente calculable para implementaciones Enterprise AI: la cercanía operativa a Alemania. Los grupos polacos trabajan desde hace décadas con matrices alemanas, los bancos polacos mantienen relaciones de corresponsalía con Fráncfort y Múnich, los emplazamientos industriales polacos están integrados en cadenas de suministro alemanas. El lenguaje de cumplimiento está rodado, las expectativas de Audit Trail, explicabilidad y [Governance by Design](/es/governance/eu-ai-act/) no son nuevas. Una implementación exitosa en Polonia no solo es un paso de penetración de mercado, sino que entrega una referencia arquitectónica directamente aceptada en la región DACH. Cert-Ready by Design aquí no es frase publicitaria sino condición para cada primer día productivo - y simultáneamente la vía más rápida hacia una plataforma Enterprise AI productiva después en quince países UE adicionales.

--- Agentes IA para Empresas en el Reino Unido | Gosign ---
> Enterprise AI Agents para el Reino Unido. UK GDPR conforme, EU AI Act ready para operaciones UE. IA auditable para ambos regímenes regulatorios.

## El Reino Unido es el único mercado próximo a la UE con regulación dual obligatoria

El Reino Unido es el único gran espacio económico europeo donde toda empresa mediana y grande con negocio continental debe hacer sus sistemas IA auditables simultáneamente frente a dos regímenes regulatorios independientes. En el lado británico están UK GDPR, el ICO como supervisión de protección de datos, FCA y PRA para servicios financieros, Ofcom para telecomunicaciones y medios y la CMA para competencia. En el lado UE siguen aplicándose el RGPD y el EU AI Act para cada conjunto de datos que afecte a clientes UE, empleados UE o filiales UE. HSBC, Barclays, Lloyds y NatWest operan funciones de grupo que sirven ambos universos en paralelo. BP, Shell, AstraZeneca, GSK y Unilever procesan datos diariamente que unas veces recalan en jurisdicción UK y otras en jurisdicción UE. Tesco, Sainsbury's, BT, Vodafone, ITV y BBC afrontan la misma realidad a escala nacional. Los escenarios se reparten en Londres, Mánchester, Edimburgo, Glasgow, Birmingham, Leeds y Bristol - pero el problema regulatorio es el mismo en todas partes. Para empresas españolas con matriz en Reino Unido o filial británica, es el terreno donde se define la arquitectura dual.

## Los tres obstáculos regulatorios para la IA en el mercado del Reino Unido

Primero, UK GDPR y la supervisión del ICO: tras el Brexit rige en UK el UK GDPR como derecho nacional de protección de datos, supervisado por el Information Commissioner's Office. En decisiones automatizadas, el ICO espera bases de modelo documentadas, capacidad de información frente a afectados y Audit Trail completo. La prevista Data Protection and Digital Information Bill introducirá ciertas flexibilidades UK-específicas sin derogar las exigencias clave. Quien mueve datos entre UK y UE necesita adicionalmente un marco adecuado de Adequacy o SCC - un layer de cumplimiento que ninguna otra jurisdicción europea exige en esta forma.

Segundo, FCA, PRA y Bank of England para el sector financiero: HSBC, Barclays, Lloyds y NatWest están bajo supervisión FCA y PRA directa. La FCA ha dejado claro en varias publicaciones que en decisiones asistidas por IA en concesión de crédito, underwriting, AML y Conduct-Risk espera los mismos estándares de explicabilidad y supervisión que en decisiones humanas. El enfoque UK-específico: en lugar de una ley IA unitaria como el EU AI Act, UK apuesta por regulación sectorial - la FCA fija los estándares para Finance, el ICO para protección de datos, Ofcom para comunicaciones. Quien como grupo británico emplea IA en varios sectores tiene que lidiar con expectativas distintas por regulador.

Tercero, el EU AI Act para cada empresa UK con negocio UE: el EU AI Act no aplica solo a empresas UE. Cada empresa británica que provee outputs IA en la UE - sea vía filial alemana, establecimiento neerlandés o venta directa a clientes UE - cae bajo el ámbito extraterritorial del EU AI Act. Eso implica: HSBC necesita cumplimiento EU AI Act para su negocio retail alemán. Unilever lo necesita para cada algoritmo de consumo desplegado en UE. AstraZeneca lo necesita para soporte de decisiones clínicas en centros de estudio UE. Una arquitectura UK-only no basta para ninguno de estos grupos.

## Escenarios típicos de implementación en el Reino Unido

HSBC y Barclays - Conduct Risk Monitoring: los grandes bancos británicos están bajo doble supervisión FCA y ESMA. Document Agents extraen declaraciones relevantes de cumplimiento de interacciones con clientes, el Decision Layer enruta sospechas según los umbrales jurisdiccionales respectivos, con Human-in-the-Loop en cada escalación y un Audit Trail presentable tanto a FCA como ESMA.

BP y Shell - HSE Operations: los grupos energéticos globales generan diariamente miles de informes de seguridad y medioambiente. Workflow Agents clasifican incidentes por gravedad, región y aspectos notificables - con rutas de escalación distintas según emplazamiento (UK HSE, EPA, BNetzA, OUG polaco).

AstraZeneca y GSK - Pharmacovigilance: los grupos farmacéuticos UK gestionan estudios clínicos pan-UE. Document Agents revisan informes de Adverse Events, los clasifican según exigencias MHRA y EMA y enrutan hallazgos críticos a responsables humanos - cada decisión auditable contra el estándar regulatorio aplicable.

Unilever y Tesco - algoritmos de consumidor: los grandes grupos de consumo y retail emplean IA en recomendación, pricing y promoción. Decision Agents verifican cada decisión desplegada contra estándares UK de protección al consumidor y EU AI Act simultáneamente, con justificaciones trazables para ICO y supervisión de consumo.

## Cómo Gosign atiende el Reino Unido desde Hamburgo

Gosign atiende proyectos UK desde la sede Hamburgo. La combinación de expertise regulatoria UE y posición hamburguesa no es desventaja para grupos británicos con negocio UE sino condición - precisamente la regulación dual solo se construye limpiamente si ambos universos los entiende el mismo equipo al mismo tiempo. Discovery se celebra in situ en Londres, Mánchester o Edimburgo según el emplazamiento del grupo. Luego el Build corre en remoto, con documentación en inglés, Sprint Reviews semanales en vídeo y un interlocutor fijo en Hamburgo. Las visitas presenciales se producen cada cuatro a seis semanas, el vuelo directo Hamburgo-Londres dura algo más de hora y cuarto. Las visitas a FCA, PRA o ICO las acompaña Gosign a petición junto con el departamento jurídico interno del cliente. Para clientes españoles con matriz UK, coordinamos desde Barcelona con documentación ES/EN.

## Por qué el Reino Unido funciona como punto de partida para Enterprise AI

Ningún otro país en Europa fuerza a los grupos con la misma consistencia hacia arquitectura de reglas jurisdicciones-específica. Quien construye un AI Agent que cumple UK GDPR, estándares FCA y EU AI Act simultáneamente ha desarrollado una arquitectura que en prácticamente cualquier mercado occidental está a un cambio de configuración. Precisamente ahí entra el [Decision Layer](/es/decision-layer/) de Gosign con conjuntos de reglas jurisdiccionales: en vez de operar dos sistemas paralelos, corre una plataforma con dos reglamentos - UK en routing doméstico, UE en routing UE, y un Audit Trail que documenta según el receptor el reglamento correcto. Para grupos británicos con negocio UE es la única arquitectura que no resulta un callejón sin salida en la primera auditoría ICO o ESMA. Cert-Ready by Design aquí significa literalmente: listo para dos certificaciones sobre una única base de código. Más contexto sobre el [EU AI Act](/es/governance/eu-ai-act/) y su efecto extraterritorial en el área de Governance.

--- Agentes IA para Empresas en Río de Janeiro | Gosign ---
> Enterprise AI Agents para Río de Janeiro. LGPD-compliant, CLT-compatible. Agents auditables para energía, minería y sector público.

## Río de Janeiro es el cuello de botella de cumplimiento del sector energético y de materias primas brasileño

En Río tienen sede los grupos cuyos riesgos operativos acaban cada día en los reports ESG del mundo: Petrobras (sede Avenida República do Chile), Vale (sede en Praia de Botafogo, operación en Minas Gerais), Eletrobras, Light SA, Americanas y Oi. A ellos se suman los reguladores: CVM (Comissão de Valores Mobiliários, sede Centro Río), BNDES como banca nacional de desarrollo, ANP (Agência Nacional do Petróleo) y ANEEL (Agência Nacional de Energia Elétrica) con delegaciones directamente en el centro. Quien opera aquí AI Agents en loops productivos de cumplimiento, los opera a la vista de cuatro autoridades de supervisión simultáneamente - y al menos una de ellas es, tras Brumadinho, altamente sensible a cualquier forma de decisión algorítmica. A diferencia de São Paulo, la concentración industrial aquí no está distribuida horizontalmente sino profundizada verticalmente: quien dirige energía y materias primas en Brasil tiene en Río el acceso de mercado más denso. Para empresas españolas con operaciones en upstream energético LATAM (Repsol, Iberdrola, Enagás) o con exposición a cadenas ESG de materias primas, Río es mercado de referencia.

## Los tres obstáculos regulatorios para la IA en el mercado de Río de Janeiro

**Supervisión CVM para grupos cotizados** es en Río más densa que en ningún otro lugar de Brasil. Petrobras, Vale, Eletrobras y Americanas están cotizados; cada componente algorítmico en Investor Relations, reporting trimestral o prevención de insider-trading debe ser explicable ante un auditor CVM. La sede CVM en Centro Río significa: caminos cortos, inspecciones intensivas.

**ANP y ANEEL para infraestructura regulada**: las instalaciones Petrobras y las redes Eletrobras están documentadas según normas ANP y ANEEL. La IA que propone ventanas de mantenimiento, elabora planes de producción o prioriza cortes de red queda así bajo regulación sectorial concreta - no solo bajo LGPD. La ANP exige trazabilidad hasta nivel de pozo, ANEEL hasta nivel de subestación.

**LGPD y presión de transparencia post-Brumadinho**: Vale está desde 2019 (Brumadinho) y 2015 (Mariana) bajo observación del Ministerio Público Federal (MPF) y la Justiça Federal. Cada decisión algorítmica en seguridad de presas, risk-scoring o monitoreo de relaves debe ser explicable ante tribunales. El Audit Trail aquí no es "nice to have" - es la diferencia entre denuncia penal y línea de defensa. Nota para hispanohablantes: Brasil se rige por LGPD, no por RGPD - régimen propio.

## Escenarios típicos de implementación en Río de Janeiro

**Petrobras - documentación de instalaciones**: Document Agents leen protocolos de mantenimiento, informes de perforación y notificaciones ANP de 30 años de historia de instalaciones y los consolidan en Decision Records auditables. Cuando un inspector pregunta por la historia de una fisura en una junta de soldadura, la respuesta es en vez de un proyecto de una semana una consulta - con Audit Trail completo hasta el archivo original. En un grupo con 60.000 empleados, perforaciones Pre-Sal costa afuera y una red de refinerías cruzando Brasil, no es "nice to have" sino cuello de botella operativo.

**Vale - monitorización de seguridad minera**: Workflow Agents vigilan datos sensor, informes de inspección y datos meteorológicos externos en emplazamientos de presas de relaves en Minas Gerais (dirigidos operativamente desde Río). El Decision Layer escala patrones críticos de riesgo con Human-in-the-Loop a geotecnia - cada decisión documentada para ANM, MPF y cumplimiento interno.

**BNDES - concesión de créditos**: Document Agents examinan solicitudes de financiación en completitud, plausibilidad y conflicto con criterios de exclusión ESG. El Decision Layer marca solicitudes críticas para decisión humana y genera un expediente de justificación completo por cada recomendación - incluyendo fuentes y origen de datos. En créditos de fomento de tres dígitos millonarios, la profundidad de justificación por decisión es condición para cualquier inspección TCU.

**Globo - moderación de contenido y gestión de derechos**: Document Agents procesan documentos de licencia, derechos de explotación y cláusulas contractuales para el mayor grupo mediático de Latinoamérica. El Decision Layer escala conflictos entre licencias de emisión, derechos de streaming y contratos internacionales con Audit Trail hasta el archivo original - crítico en la era streaming donde los derechos Globoplay se renegocian a diario.

## Cómo Gosign atiende Río desde São Paulo

Nuestra oficina en São Paulo (gosign.com.br) está a 1 hora de vuelo de Río - más cerca de la sede Petrobras que la mayoría de proveedores IA europeos de cualquier cliente. Los Discovery Workshops con Petrobras, Vale o BNDES se celebran in situ en Río, en las sedes corporativas de Botafogo o Centro. Las Compliance Reviews con referencia CVM, ANP o ANEEL se conducen con tu departamento jurídico en Río - la cercanía a la sede CVM significa que clarificaciones regulatorias en vez de 6 semanas de correspondencia se resuelven en una cita en el piso 25 de Avenida Rio Branco. Las fases técnicas de Build corren distribuidas entre nuestros equipos en Hamburgo y São Paulo - standups por la mañana hora SP, Sprint Reviews conjuntas. Las visitas presenciales en Río son posibles en 24 horas, también a instalaciones Petrobras fuera de la ciudad (Macaé, cuenca Campos). Tras el Go-Live la oficina SP es tu interlocutor operativo con hotline de escalación en portugués e inglés - la comunicación con la matriz europea permanece en paralelo en alemán o inglés. Para clientes españoles con matriz ibérica, coordinación Barcelona + São Paulo con documentación ES/PT según stakeholder.

## Por qué Río de Janeiro funciona como punto de partida para Enterprise AI

Río es la única ciudad brasileña donde cuatro reguladores (CVM, ANP, ANEEL, delegación ANPD) y cuatro de los diez mayores grupos brasileños están en 15 km de radio. Quien construye aquí un agente productivo para reporting CVM, cumplimiento ANP o monitoreo de relaves, lo tiene como blueprint para cualquier mercado latinoamericano de energía y materias primas - desde Buenos Aires vía Lima hasta Bogotá. Los clústeres - BNDES Inovação, Rio+, el corredor tech Porto Maravilha - aportan el puente al mundo académico (PUC-Río, UFRJ). Lo que además caracteriza a Río: la concentración de grupos cotizados con inversores ESG globales significa que las exigencias de explicabilidad algorítmica son aquí más densas que en ningún otro sitio de Latinoamérica - eleva el listón, pero precisamente por eso convierte cada agente construido con éxito aquí en un blueprint Cert-Ready para matrices globales. La arquitectura [Governance by Design](/es/governance/eu-ai-act/) de Gosign es conectable con operaciones RGPD en Lisboa y auditorías UE - un modelo que resiste en Río, resiste en Fráncfort. Véase también [São Paulo](/es/agentes-ia-sao-paulo/) y [panorama Brasil](/es/agentes-ia-brasil/).

--- Agentes IA para Empresas en São Paulo | Gosign ---
> Enterprise AI Agents en São Paulo. Gestión de proyectos local, LGPD-compliant, compatible con CLT y convenios colectivos. Del PoC a la operación autónoma.

## São Paulo es la única metrópolis LATAM donde un proveedor IA europeo debe trabajar con presencia local

Quien quiere ganar a Itaú Unibanco, Bradesco, Santander Brasil, Natura &Co o Ambev como clientes no lo puede hacer desde Hamburgo. Avenida Paulista, Faria Lima y Pinheiros son microcosmos regulatorios propios con procesos de cumplimiento propios, culturas de protección de datos propias y expectativas propias sobre la proximidad del proveedor. Eso vale para el clúster bancario en torno a Cubo Itaú igual que para los mundos de consumo de JBS, BTG Pactual y XP Inc. Gosign opera por eso oficina propia en São Paulo (gosign.com.br) - con jefes de proyecto locales que se sientan directamente en las discusiones con Compliance Officers, DPOs y representantes sindicales. Para empresas españolas con operaciones en Brasil, coordinación Barcelona + São Paulo (hispanidad + lusofonía) cubre toda la península ibérica y el mayor mercado LATAM bajo un mismo proveedor.

## Los tres obstáculos regulatorios para la IA en el mercado de São Paulo

**LGPD (Lei Geral de Proteção de Dados)** es la respuesta brasileña a la protección de datos europea - pero no idéntica al RGPD. La ANPD (Autoridade Nacional de Proteção de Dados, formalmente en Brasilia, operativamente fuerte foco SP) exige base jurídica, limitación de finalidad y DPO. Quien trabaja en Pinheiros con datos personales debe cumplir el Art. 7 y 11 de la LGPD (datos sensibles, salud y finanzas) - incluyendo Audit Trail. Nota para hispanohablantes: LGPD no es RGPD, son regímenes separados.

**BACEN Resolução 4893** define las exigencias de ciber-resiliencia para entidades financieras reguladas y es de facto el equivalente brasileño al DORA. Itaú, Bradesco, Banco do Brasil, Santander Brasil y las fintechs (Nubank, Stone, PagSeguro, XP Inc.) deben documentar cada intervención algorítmica en decisiones de crédito, fraud-scoring o antilavado - no solo en auditoría, sino productiva y en vivo.

**PL 2338/2023** es el proyecto brasileño de ley IA, inspirado vagamente en el EU AI Act pero no idéntico. En 2026 aún no está en vigor, pero se espera en los próximos dos años. Quien construye hoy debe diseñar la arquitectura ya de modo que la clasificación high-risk, el control humano y las obligaciones de transparencia sean activables a posteriori. Cert-Ready by Design en vez de Cert-Retrofit.

## Escenarios típicos de implementación en São Paulo

**KYC bancario y AML screening en Itaú/Bradesco/Santander Brasil**: Document Agents leen Cadastro de Pessoas Físicas, Cadastro Nacional da Pessoa Jurídica, Comprovante de Residência y listas de sanciones externas. El Decision Layer marca hits high-risk (PEPs, coincidencias de sanciones) y los enruta a Compliance Officers con justificación, confidence-score y Audit Trail completo. Las auditorías Banco Central y Coaf se convierten de un proyecto de una semana en un clic.

**Cumplimiento de cadena de suministro en Natura &Co y JBS**: Workflow Agents vigilan certificados de proveedores (FSC, Rainforest Alliance, GRSB para carne vacuna), los contrastan con listas de sanciones IBAMA y alertan ante anomalías. En JBS y Marfrig la pregunta "¿suministra esta granja en áreas de deforestación?" es hoy tan crítica para la supervivencia como el reporting ESG en Natura.

**Cumplimiento de inversión en XP Inc. y BTG Pactual**: Document Agents examinan contratos de inversión, perfiles de riesgo y obligaciones de notificación CVM. El Decision Layer escala infracciones Suitability automáticamente a Compliance - con Human-in-the-Loop en cada paso regulatoriamente relevante. En bancos de inversión la profundidad auditora por operación no es "nice to have", sino condición para cualquier procedimiento CVM - Workflow Agents documentan en paralelo la verificación Suitability, la información al inversor y el versionado de modelo del risk-scoring.

**Fraud Detection en Nubank, Stone y PagSeguro**: Brasil tiene la mayor adopción Pix del mundo (más del 90% de la población), y por tanto un paisaje de fraude propio. Workflow Agents vigilan patrones transaccionales en tiempo real, los contrastan con perfiles de conducta y escalan operaciones sospechosas con confidence-score y expediente justificativo a equipos anti-fraude. El Audit Trail satisface tanto las obligaciones Coaf como los estándares BACEN de seguridad.

## Cómo Gosign atiende Brasil desde São Paulo

Tenemos oficina en São Paulo con jefes de proyecto locales - no es una "sales office", sino presencia operativa real. Concretamente: los Discovery Workshops se celebran in situ, no vía Zoom desde Europa. Las Compliance Reviews con tu DPO y departamento jurídico pasan presencialmente en Faria Lima o Pinheiros. Las consultas sindicales, cuando los HR-Agents toman decisiones relevantes para el trabajo, se conducen conjuntamente con tus abogados laboralistas. La implementación técnica corre en remoto entre nuestros equipos en Hamburgo y São Paulo - 4 horas de diferencia horaria, standups conjuntos por la mañana hora SP. Tras el Go-Live la oficina SP sigue siendo tu interlocutor operativo - incluyendo hotline de escalación en portugués e interlocutores que conocen operativamente el derecho laboral brasileño (CLT) y los convenios (CCT/ACT), no solo por el documento de traducción. Para clientes españoles, coordinación Barcelona + São Paulo bajo un mismo provider, documentación ES/PT según stakeholder - matriz ibérica habla ES con Barcelona, filial brasileña habla PT con São Paulo.

La pregunta que los responsables de cumplimiento brasileños nos hacen primero no es "¿pueden técnicamente?", sino "¿van a estar cuando llame ANPD o el auditor?". La respuesta honesta: sí, porque nuestros jefes de proyecto viven, trabajan y se mueven en São Paulo. Discovery, Build, Go-Live y Aftercare no son cuatro equipos distintos en cuatro países distintos - es un equipo con un hub en São Paulo y otro en Hamburgo, que comparte ciclos sprint comunes, boards de arquitectura comunes y rutas de escalación comunes.

## Por qué São Paulo funciona como punto de partida para Enterprise AI

São Paulo es el único punto en Latinoamérica donde cumplimiento bancario, cadenas de suministro de consumo, innovación fintech y operaciones industriales se dan cita en una ciudad. Quien construye aquí un AI Agent productivo para KYC, AML o ESG lo tiene disponible en 18 meses como blueprint para Ciudad de México, Bogotá, Santiago o Buenos Aires. Los clústeres - Cubo Itaú, ACE Startups, el corredor tech Pinheiros-Vila Olímpia - aseguran acceso a talento, inversores y programas piloto regulatorios. La arquitectura [Governance by Design](/es/governance/eu-ai-act/) de Gosign lo conecta con profundidad de auditoría europea: un modelo que funciona en São Paulo con LGPD y BACEN es conectable con operaciones RGPD en Lisboa, Madrid o Hamburgo. Más en el [panorama Brasil](/es/agentes-ia-brasil/).

--- Agentes IA para Empresas en Stuttgart | Gosign ---
> Enterprise AI Agents para Stuttgart y Baden-Wurtemberg. Document Agents para facturas, Workflow Agents para compras. Auditables, EU AI Act compliant.

## Stuttgart es el único mercado europeo donde grandes OEM y Hidden Champions del Mittelstand deben cumplir las mismas exigencias de cumplimiento en la misma cadena de suministro

En el corredor entre Untertürkheim, Zuffenhausen y Sindelfingen tienen sus plantas matrices Mercedes-Benz y Porsche. En Gerlingen reside Bosch como mayor proveedor automovilístico del mundo. Daimler Truck dirige desde Leinfelden-Echterdingen la división global de camiones. A esto se añaden Dürr en Bietigheim, Trumpf en Ditzingen, Festo en Esslingen, Stihl en Waiblingen, Mahle y Kärcher - la lista de Hidden Champions se extiende mucho más allá de los límites de la ciudad. El emplazamiento se define no por los OEM solos, sino por la cadena de fabricante, proveedor Tier 1 y mittelstand especializado. Quien introduce aquí un componente de IA debe documentarlo simultáneamente en varios niveles de una cadena de suministro ASPICE e ISO 26262 - el estándar de proveedores Mercedes obliga a cada proveedor a las mismas pruebas de modelo auditables. Esta interconexión convierte al mercado de Stuttgart en uno de los entornos de cumplimiento más duros de Europa: cada proveedor se ve obligado automáticamente, por las exigencias de su OEM, a una gobernanza de modelos estricta, lo quiera o no.

## Tres obstáculos regulatorios que determinan toda iniciativa de IA en el mercado de Stuttgart

El primer obstáculo es la homologación automovilística (Type Approval). El KBA en Flensburg otorga las autorizaciones, pero los estándares técnicos los marca UN/ECE en Ginebra - sobre todo UN R155 sobre Cybersecurity Management y UN R156 sobre actualizaciones de software. Quien emplee un componente de IA en un vehículo o en un proceso productivo que influya en el software del vehículo necesita una prueba completa de gobernanza de modelos, provenance de datos de entrenamiento y estados de build reproducibles. El segundo obstáculo es el Cyber Resilience Act para el equipamiento industrial de los Hidden Champions - Trumpf, Dürr, Festo y Stihl entregan máquinas con componentes digitales en mercados regulados y deben demostrar gestión de vulnerabilidades y actualizaciones de modelos. El tercer obstáculo es la fuerte cogestión en las plantas marcadas por IG Metall: una aplicación de IA con datos personales o medición de desempeño solo pasa los comités de empresa de Mercedes, Bosch o Porsche cuando el [Decision Layer](/es/decision-layer/) impone arquitectónicamente la decisión humana final. Más sobre el marco regulatorio en [Governance EU AI Act](/es/governance/eu-ai-act/).

## Escenarios típicos de implementación en Stuttgart

En Bosch y proveedores Tier 1 comparables vemos Quality Data Agents que consolidan datos de fabricación y ensayo de varias plantas y escalan anomalías a un Quality Engineer - con evaluación trazable y referencia a los datos de medición subyacentes. En Daimler Truck un Compliance Agent ayuda en la documentación de flotas, por ejemplo en la preparación de expedientes de homologación para diferentes jurisdicciones. En el entorno Porsche Financial Services los Agents apoyan la preparación de decisiones de solvencia para clientes de leasing - el operador decide, el Agent enriquece con documentos, historial de crédito al consumo y plausibility checks. En Dürr, Festo y Trumpf vemos Service Ticket Agents que clasifican tickets entrantes, los enriquecen con datos de máquina y los entregan al técnico de servicio con propuesta. Mahle y Mahle Behr trabajan en HR Document Agents para la pre-cualificación de candidatos - con Audit Trail claro, porque el reclutamiento de candidatos está bajo la AGG y bajo el EU AI Act en la clasificación de alto riesgo. En Stihl y Kärcher como mittelstand familiar vemos Document Agents en compras y análisis de contratos, porque la auditoría corporativa de estas casas espera una lógica de auditoría delgada pero sin lagunas. La sede central de Mercedes-Benz en Untertürkheim opera diariamente con un workflow ASPICE estricto en el que los componentes de IA solo se introducen en cadenas productivas cuando su provenance de modelo y su conjunto de datos de entrenamiento están documentados y versionados.

## Cómo Gosign atiende Stuttgart desde Hamburgo

Gosign no tiene sede en Stuttgart - el acompañamiento presencial se opera remoto desde Hamburgo y Berlín. La ventaja: estamos en menos de seis horas en Untertürkheim por la conexión directa ICE, un vuelo directo Hamburgo-Stuttgart dura aproximadamente una hora más desplazamientos. Concretamente: los Discovery Workshops con ingeniería, cumplimiento y comité de empresa los hacemos como bloques presenciales de dos a tres días. La fase de ingeniería está organizada en remoto con dos slots semanales fijos en el calendario del cliente y jornadas presenciales definidas para revisiones arquitectónicas y reuniones críticas con stakeholders. La validación de modelos con la auditoría interna, la preparación de auditorías ASPICE y las negociaciones de cogestión se hacen sin excepción presencialmente. El mercado suabo acepta el trabajo remoto pragmáticamente cuando la fiabilidad de entrega es buena, la frecuencia presencial está en los puntos clave y la validación de modelos queda documentada de forma trazable. Clústeres como ARENA2036 como campus de investigación para la movilidad del futuro en el campus de la Universidad de Stuttgart y Cyber Valley Tübingen-Stuttgart como mayor centro europeo de investigación ML los utilizamos para discusiones técnicas, formaciones de auditores y para el contacto con expertos universitarios en validación de modelos. Para empresas españolas con presencia industrial en Baden-Wurtemberg (Gestamp en estampación, Antolin en interiores), la oficina de Barcelona (gosign.es) coordina la comunicación bilingüe entre las plantas españolas y los OEM alemanes.

## Por qué Stuttgart funciona como punto de partida para Enterprise AI

Quien lleve a producción en un entorno OEM o Tier 1 de Stuttgart un AI Agent lo habrá defendido simultáneamente ante ASPICE, ISO 26262, Cyber Resilience Act, un comité de empresa con experiencia en IG Metall y la auditoría interna. La misma arquitectura encaja después en cualquier otro sector orientado a producción de Europa, porque la disciplina de la cadena de suministro de Stuttgart define el estándar europeo más alto en provenance de modelos y Audit Trail. A esto se añade la bolsa de talento ML y de ingeniería en torno a la Universidad de Stuttgart con su fuerte perfil en mecánica e informática, el KIT en Karlsruhe como mayor universidad técnica alemana, la Hochschule Esslingen con su especialización automovilística y los clústeres ML de Tubinga con el Instituto Max Planck de Sistemas Inteligentes. El Mittelstand en Baden-Wurtemberg es a la vez un mercado para arquitectura de IA escalada - los aproximadamente 1.500 Hidden Champions del Land muestran que no son solo las grandes corporaciones quienes necesitan IA como factor de producción. Quien tenga en 4-6 semanas un primer Agent en producción en un proveedor Tier 1 tiene un setup de referencia que el mercado entiende. Más sobre el procedimiento en [Servicios AI Agents](/es/servicios/ai-agents/).

--- Agentes IA para Empresas en Valencia | Gosign ---
> Enterprise AI Agents para Valencia. Tech-hub del Mediterráneo. EU AI Act compliant, RGPD + LOPDGDD conforme. Gestión desde Barcelona.

## Valencia es el tercer espacio económico de España, marcado por la logística alimentaria, la automoción y el comercio mediterráneo

Quien construye IA empresarial en Valencia trabaja para una ciudad donde no marcan el ritmo los bancos ni los grandes tecnológicos, sino las cadenas de suministro, la planificación de producción y la logística. Mercadona, con más de 1.700 tiendas, es la mayor cadena de supermercados de España y opera desde su sede en Tavernes Blanques una de las cadenas de suministro de marca propia más densas de Europa. Ford Valencia produce en Almussafes desde los años setenta - la planta es una de las mayores de Ford en Europa. Porcelanosa (cerámica), Lladró (porcelana) y Consum (cooperativa de supermercados) son otros pesos pesados industriales. Air Nostrum opera desde aquí el tráfico aéreo regional ibérico, BP gestiona en Castellón una de las refinerías más grandes de España, e Iberdrola Energía coordina desde el área metropolitana de Valencia una parte sustancial de la generación solar española. La ciudad se ha consolidado además en los últimos años como polo tecnológico con la Marina Valencia y el programa Lanzadera (financiado por Juan Roig, fundador de Mercadona).

## Los tres obstáculos regulatorios para la IA en el mercado valenciano

Primero, la AEPD y la LOPDGDD (Ley Orgánica 3/2018) para todo tratamiento con datos personales. La AEPD examina con especial rigor a empresas de logística y retail, porque aquí se procesan volúmenes enormes de datos de clientes y empleados. Mercadona, por ejemplo, mueve diariamente datos de millones de clientes y de más de 100.000 empleados - cualquier planificación de personal asistida por IA debe ser justificable bajo el Art. 22 RGPD.

Segundo, la AESIA (Agencia Española de Supervisión de la Inteligencia Artificial) y el EU AI Act, directamente aplicable en España. Los sistemas de alto riesgo - especialmente en gestión de personal, optimización de cadenas de suministro y generación energética - serán supervisados sistemáticamente desde 2026. Quien construya en Valencia una pipeline de IA para Workforce Management lo hace para una categoría de alto riesgo y debe documentar desde el primer día para una auditoría AESIA.

Tercero, la CNMV y el Banco de España para las cadenas de financiación entre industria y banca. Aunque Valencia no es la plaza bancaria de España, las grandes empresas industriales están integradas en estructuras de Working Capital complejas. Las previsiones de cashflow asistidas por IA, los modelos de riesgo crediticio y las estrategias de hedging están bajo supervisión de ambos. El [EU AI Act Compliance](/es/governance/eu-ai-act/) se cruza aquí con la supervisión financiera.

## Escenarios típicos de implementación en Valencia

Mercadona optimiza cadenas de suministro entre cientos de proveedores, varios centros logísticos y más de 1.700 tiendas - cada recomendación de pedido asistida por IA repercute directamente en el desperdicio alimentario, la frescura y los márgenes. Los modelos deben ser trazables porque la retribución a proveedores y empleados depende de las recomendaciones. Ford Valencia planifica en Almussafes la producción de varias gamas con cadenas de suministro complejas en toda la Península Ibérica - los modelos de IA para planificación de capacidad deben superar las auditorías corporativas. Porcelanosa utiliza Computer Vision para el control de calidad de la producción cerámica - cada decisión automática de descarte debe ser justificable ante grandes clientes y proveedores. Iberdrola Energía supervisa en la región de Valencia y Castilla-La Mancha grandes plantas fotovoltaicas - la detección de anomalías por IA en el rendimiento de los módulos debe documentarse en un Audit Trail que sea verificable para propietarios y aseguradoras.

En todos los escenarios se trata de IA industrial con efecto físico. El [Decision Layer](/es/decision-layer/) aporta la arquitectura que reúne Audit Trail, escalado y Cert-Ready by Design - exactamente lo que las autoridades de supervisión españolas quieren ver al mismo tiempo.

Una particularidad valenciana es el puerto de Valencia - el mayor puerto de contenedores del Mediterráneo y un nodo estratégico para el comercio entre Europa y Asia. Quien construya aquí IA para documentación de carga, despacho aduanero y optimización logística trabaja bajo el régimen adicional de supervisión de la Agencia Tributaria y de la autoridad de Aduanas. El Audit Trail no solo debe cumplir el RGPD, sino también ser trazable en términos aduaneros - y a menudo a través de varios idiomas y jurisdicciones.

## Cómo Gosign atiende Valencia desde Barcelona

Gosign atiende los proyectos valencianos desde la oficina de Barcelona (gosign.es) con jefes de proyecto e ingenieros hispanohablantes. El AVE Barcelona-Valencia tarda unas tres horas y media, en coche según el tráfico es similar - las visitas mensuales in situ a Mercadona en Tavernes Blanques, a Ford Valencia en Almussafes, a Porcelanosa y a la Marina Valencia son parte estándar de cada proyecto. El Discovery se realiza in situ, con los responsables funcionales hispanohablantes, la función de cumplimiento y el Comité de Empresa en la misma mesa. Cuando es necesario integramos a stakeholders valencianohablantes. Los clústeres industriales locales - agroalimentario alrededor de Mercadona y Consum, automoción en torno a Ford y proveedores, cerámica en Castellón - exigen comprensión sectorial que el equipo español aporta tras años de trabajo con el tejido medio empresarial de la Península Ibérica. La sede de Hamburgo aporta revisiones arquitectónicas y la conexión con estándares industriales de cumplimiento alemanes - la entrega, el contacto directo con el cliente y la cultura de negociación de empresas familiares valencianas las lleva el equipo de Barcelona.

## Por qué Valencia funciona como punto de partida para Enterprise AI

Valencia es el mercado ideal para validar IA industrial con cumplimiento completo, sin la fricción regulatoria y la estructura de costes de Madrid. Quien construya en Valencia un piloto Cert-Ready by Design tendrá un caso de referencia que ha pasado los estándares de AEPD, AESIA y EU AI Act - y que después será defendible en Madrid, Barcelona y más allá de los Pirineos. La Marina Valencia, el programa Lanzadera y la Universitat Politècnica de València aportan talento, partners piloto y conexión con la investigación.

Aportamos del cinturón industrial alemán la experiencia de operar IA en cadenas de suministro y sistemas de producción complejos - con Governance by Design, Audit Trail y Human-in-the-Loop. Valencia es el mercado adecuado para escalar esta disciplina de forma productiva en la Península Ibérica. Quien empieza aquí tiene un blueprint para cualquier región industrial europea con perfil similar - desde el Ruhr hasta Lombardía pasando por el País Vasco.

--- Agentes IA para Empresas en Varsovia | Gosign ---
> Enterprise AI Agents para Varsovia. EU AI Act conforme, RGPD-ready, compatible con Rada Zakładowa. IA auditable para sedes corporativas polacas.

## Varsovia es la capital corporativa de Polonia con la mayor densidad de reguladores de Europa Central y Oriental

En Varsovia tienen sede las matrices de PKO BP, PZU, Orlen, PGE, Santander Bank Polska, mBank, Allegro, CD Projekt RED y LPP - líderes sectoriales polacos con cientos de miles de clientes, empleados y transacciones al día. Simultáneamente Varsovia es sede de las principales autoridades de supervisión del país: UODO, KNF, NBP y ZUS trabajan todos en pocos kilómetros. Esta proximidad entre corporaciones y reguladores genera una densidad supervisora que no existe en ninguna otra ciudad polaca. Los sistemas IA que entran en producción en sedes corporativas de Varsovia no solo deben funcionar - deben resistir a una supervisión que geográficamente está a una parada de metro. Para empresas españolas con intereses en Polonia (Santander via Santander Bank Polska, Iberdrola via PGE consultations, Indra/Telefónica Europa Central), Varsovia es el punto de validación regulatoria obligatorio.

## Los tres obstáculos regulatorios para la IA en el mercado de Varsovia

Primero, la supervisión KNF sobre el sector financiero polaco: PKO BP, mBank, Pekao, Santander Bank Polska y PZU están bajo supervisión KNF directa. En procesos AML y KYC, scoring crediticio y gestión de siniestros, la Komisja Nadzoru Finansowego espera bases de modelo documentadas, Audit Trail completo y decisión humana final demostrable en casos de riesgo. La KNF ha precisado en los últimos años sus expectativas sobre toma de decisiones automatizada - quien como banco en Varsovia emplea IA y no provee documentación de conformidad sólida, arriesga no solo reparos, sino intervenciones en la operación en curso.

Segundo, KSeF, el sistema polaco de facturación electrónica: KSeF se vuelve obligatorio por fases para todas las empresas en Polonia. Grupos como Orlen, Allegro, LPP y PGE deben extraer, validar y archivar cientos de miles de facturas entrantes y salientes al día en conformidad KSeF. La IA que procesa datos de factura debe corresponder a los requisitos estructurales KSeF y hacer trazable en conflicto por qué un asiento se realizó como se hizo - un caso clásico para Document Agents con Human-in-the-Loop forzado en desviaciones.

Tercero, UODO y las especificidades de la ley polaca de protección de datos: el UODO tiene sede en Varsovia y examina a los grupos polacos con atención especial al perfilado automatizado según Art. 22 RGPD. En los sistemas de recomendación de Allegro, la clasificación de siniestros de PZU o el scoring crediticio de PKO BP, el UODO espera clara capacidad de información y justificaciones trazables - cada afectado debe poder enterarse de por qué se tomó una decisión, y la KNF o UODO deben poderla examinar. Nota para hispanohablantes: RODO es el nombre polaco del RGPD, UODO el equivalente a AEPD.

## Escenarios típicos de implementación en Varsovia

PKO BP - AML y KYC Operations: el mayor banco de Polonia procesa diariamente millones de transacciones. Document Agents extraen identificadores, Workflow Agents enrutan sospechas por umbrales KNF, y el Decision Layer registra cada escalación para el comité interno AML y auditores externos.

Allegro - Fraud Detection: el mayor marketplace e-commerce de Polonia compite con Amazon. En millones de pedidos diarios, Decision Agents examinan patrones de riesgo en tiempo real - siempre con la opción de rastrear decisiones individuales para auditorías UODO.

PZU - gestión de siniestros: el líder asegurador polaco procesa miles de siniestros al día. Workflow Agents clasifican avisos de siniestro entrantes por póliza, región y complejidad, con examen humano forzado en superación de umbrales - punto explícito de exigencia KNF.

Extracción KSeF de facturas para Orlen y PGE: ambos grupos están bajo presión del mandato KSeF. Document Agents extraen datos estructurados de factura, los validan contra el esquema KSeF y enrutan desviaciones a revisores humanos en contabilidad.

## Cómo Gosign atiende Varsovia desde Cracovia

Gosign atiende proyectos Varsovia desde la oficina Cracovia (gosign.pl) con jefes de proyecto e ingenieros polacoparlantes. La distancia Cracovia-Varsovia se cubre con el Express Intercity Premium en escasas tres horas, en coche según tráfico similar - la presencia presencial regular en Warsaw Spire Tech, Rondo Daszyńskiego o directamente en las sedes corporativas de PKO BP, Allegro, Orlen, PZU y mBank es estándar, no excepción. Los Discovery Workshops se celebran in situ, con los responsables especializados polacoparlantes, la función de compliance y un representante de la Rada Zakładowa en la misma mesa. Build y Sprint Reviews corren luego semanalmente en polaco o inglés, con citas mensuales de steering presenciales en Varsovia y desplazamiento rápido en escalaciones UODO o KNF. La matriz Hamburgo asume cuestiones arquitectónicas de fondo y la conexión con matrices alemanas o suizas - Delivery, día a día y contacto con el cliente están en el equipo Cracovia a la altura de los stakeholders de Varsovia. Para clientes españoles con matriz ibérica, coordinamos desde Barcelona con documentación ES/PL/EN según stakeholder.

## Por qué Varsovia funciona como punto de partida para Enterprise AI

Varsovia es el único mercado en Europa Central y Oriental donde se dan simultáneamente las tres condiciones para una implementación Enterprise AI exitosa: máxima densidad corporativa, máxima densidad regulatoria y un ecosistema tech con Google for Startups Warsaw, Campus Warsaw y el clúster Warsaw Spire Tech. Quien pone en producción un AI Agent para un banco varsoviano, un asegurador varsoviano o un grupo e-commerce varsoviano, ha superado el stress-test regulatorio más duro de Europa Central y Oriental. El escalado posterior a otros emplazamientos polacos - [Cracovia](/es/agentes-ia-cracovia/), [Wroclaw](/es/agentes-ia-wroclaw/), [Gdansk](/es/agentes-ia-gdansk/) - no es entonces un segundo build, sino un cambio de configuración.

Se añade un aspecto que hace a Varsovia especialmente atractiva para matrices alemanas, suizas y neerlandesas: los grupos varsovianos están acostumbrados desde hace años a estándares de cumplimiento de Europa Occidental. PKO BP trabaja con bancos corresponsales alemanes, mBank pertenece desde hace décadas al grupo Commerzbank, Santander Bank Polska es parte de la estructura del grupo Santander español. Estos grupos saben qué significa una expectativa BaFin, FINMA o DNB sobre IA, y sus funciones de cumplimiento internas están diseñadas para ello. Una implementación Decision Layer en Varsovia rara vez encuentra resistencia a la exigencia de hacer auditable cada decisión - aquí es desde hace años realidad operativa. [Governance by Design](/es/governance/eu-ai-act/) en Varsovia no es frase publicitaria sino condición de entrada. Quien supera Varsovia, supera el resto de Polonia y la mayoría de los mercados UE de paso.

--- Agentes IA para Empresas en Wrocław | Gosign ---
> Enterprise AI Agents para Wrocław. Hub IT nr. 2 de Polonia. EU AI Act compliant, RGPD conforme. Gestión desde Cracovia.

## Wrocław es el híbrido industria-IT polaco - aquí coinciden proveedores automotrices y operaciones bancarias

En Wrocław, Bosch Wrocław, LG Electronics, 3M, Volvo Wrocław, Whirlpool y Toyota Motor Manufacturing Poland operan emplazamientos de producción e ingeniería con miles de empleados cada uno. Paralelamente se asientan aquí UBS Wrocław (surgida del centro Credit Suisse), HP, Nokia Wrocław y varios Banking Shared Services. Esta mezcla es única en Polonia: una ciudad donde se trabaja en la misma hora en documentos de ingeniería para una planta automotriz y en research reports para un banco de inversión suizo. El Wrocław Technology Park y Capital Park forman el clúster físico, la Politechnika Wrocławska aporta ingenieros a ambos universos. Quien construye Enterprise AI en Wrocław debe atender dos lógicas industriales simultáneamente. Para empresas españolas con operaciones nearshoring IT o joint ventures industriales centroeuropeas, Wrocław ofrece esta doble capacidad bajo un mismo emplazamiento.

## Los tres obstáculos regulatorios para la IA en el mercado de Wrocław

Primero, UODO y RODO en contexto multi-entidad: los emplazamientos Wrocław procesan frecuentemente datos de sus matrices de Europa Occidental. Una operación UBS en Wrocław está sujeta simultáneamente a exigencias FINMA, ESMA y UODO. Una función de ingeniería Bosch en Wrocław genera documentación de producto que aterriza en Stuttgart, Shanghái y Detroit. La ley polaca de protección de datos prescribe que el perfilado automatizado y la toma de decisiones deban seguir siendo trazables - incluso cuando los modelos se entrenan en la matriz alemana o suiza. Arquitecturas IA sin Audit Trail sin fisuras no son aquí implementables. Nota para hispanohablantes: UODO = equivalente polaco a AEPD, RODO = nombre polaco del RGPD.

Segundo, supervisión KNF para la creciente función de outsourcing bancario: UBS, varias Investment Operations medianas y prestadores de credit servicing trabajan en Wrocław bajo el paraguas regulatorio de la Komisja Nadzoru Finansowego más los respectivos reguladores domésticos. En herramientas de research, clasificación automática de documentos y compliance screening, la KNF espera que cada decisión de modelo pueda remitirse a un responsable humano último - incluyendo la versión de datos subyacente en el momento de la decisión.

Tercero, el EU AI Act con foco en aplicaciones high-risk en RR.HH. e industria: los emplazamientos de producción Wrocław emplean crecientemente IA para control de calidad, Predictive Maintenance y planificación de turnos. Los algoritmos de planificación de turnos caen bajo el Annex III del EU AI Act (sistemas high-risk RR.HH. relevantes), el control de calidad vía modelos Vision toca responsabilidad de producto y conformidad CE. La NBP y el UODO esperan en ambos casos documentación de conformidad completa. Cert-Ready by Design en plantas Wrocław no es argumento de venta, sino condición ineludible para auditorías de matrices y sus certificadores.

## Escenarios típicos de implementación en Wrocław

LG Electronics - control de calidad: la planta LG Wrocław produce componentes de display en grandes cantidades. Decision Agents basados en Vision revisan defectos de superficie en tiempo real, con escalación humana forzada en casos límite. Cada decisión se registra en Audit Trail con versión de modelo, dataset de entrenamiento e ID de revisor.

UBS Wrocław - Research Operations: la antigua operación Credit Suisse, ahora parte de UBS, opera una de las mayores funciones de research fuera de Zúrich. Document Agents extraen datos clave de memorias anuales, clasifican Earnings Calls y enrutan declaraciones relevantes de compliance a analistas humanos - cada paso registrado para auditorías FINMA y KNF.

HP - routing de service desk: el centro de servicios Wrocław de HP atiende clientes en varios idiomas y zonas horarias. Workflow Agents clasifican tickets entrantes por idioma, mandante y nivel de escalación. El Decision Layer enruta automáticamente, con Human-in-the-Loop en clientes VIP y en tickets que violarían SLAs.

Bosch - documentación de producción: el emplazamiento Wrocław de Bosch genera diariamente miles de documentos técnicos. Document Agents extraen especificaciones regulatoriamente relevantes, las contrastan con normas específicas por país y enrutan conflictos automáticamente a la dirección de ingeniería en Stuttgart o Wrocław.

## Cómo Gosign atiende Wrocław desde Cracovia

Gosign atiende proyectos Wrocław desde la oficina Cracovia (gosign.pl) con ingenieros y jefes de proyecto polacoparlantes. Cracovia-Wrocław se cubre en coche o tren en unas tres horas - citas presenciales regulares en el Wrocław Technology Park, en Capital Park o directamente en las salas de ingeniería de Bosch, LG Electronics, UBS Wrocław y HP son parte de cada fase de proyecto, no caso especial. Discovery se celebra presencial de dos días, con responsables especializados polacoparlantes, función de compliance y representante de Rada Zakładowa en la misma mesa. Build y Sprint Reviews corren luego con el equipo Cracovia, en polaco e inglés, con steerings presenciales mensuales en Wrocław. Los ingenieros polacos entienden la doble realidad Wrocław - industria tradicional y outsourcing bancario - desde su propia práctica profesional y adaptan documentación, idioma de workshop y rutas de escalación sin traducción cultural. La matriz Hamburgo asume revisiones de arquitectura y la conexión con matrices alemanas y suizas en Stuttgart, Múnich o Zúrich. Para clientes españoles con matriz o intereses centroeuropeos, coordinamos desde Barcelona.

## Por qué Wrocław funciona como punto de partida para Enterprise AI

Wrocław es el mercado Enterprise AI más inusual de Polonia, porque aquí colisionan dos universos: industria tradicional y outsourcing bancario. Quien construye un AI Agent que funciona simultáneamente en una planta Bosch y una operación UBS, ha desarrollado una arquitectura que en cualquier otro emplazamiento polaco está a un cambio de configuración. La Politechnika Wrocławska aporta ingenieros que entienden esta doble realidad, y el ecosistema tech de Wrocław es tras [Cracovia](/es/agentes-ia-cracovia/) el segundo más grande del país.

Para Mittelständler alemanes con filiales polacas, Wrocław es a menudo el primer emplazamiento exterior donde se necesita realmente IA productiva - una implementación Wrocław exitosa se convierte así en blueprint para el escalado posterior. Se añade la proximidad geográfica a la frontera alemana: el tren Berlín-Wrocław requiere escasas cuatro horas, una cita presencial se hace en un día laboral. Esta combinación de accesibilidad europea occidental, costes de talento centroeuropeos y regulación UE estricta convierte a Wrocław en un emplazamiento que no debe faltar en ninguna cartera alemana de grupo. [Governance by Design](/es/governance/eu-ai-act/) aquí no es frase publicitaria, sino condición para la aceptación en la matriz - y exactamente la condición que un Decision Layer exitosamente implementado cumple desde el principio. Más sobre nuestro procedimiento en Polonia en [panorama Polonia](/es/agentes-ia-polonia/).

--- Agentes IA para Empresas en Zúrich | Gosign ---
> Enterprise AI Agents para Zúrich. Swiss FADP conforme, EU AI Act ready para operaciones en la UE. IA auditable para el centro financiero suizo.

## Zúrich es el único centro financiero europeo donde la arquitectura IA debe planificarse sin EU AI Act - y precisamente eso es la ventaja estratégica

Suiza no está en la UE. Quien entiende Zúrich como mercado empieza con este hecho: el EU AI Act no aplica aquí directamente, el RGPD no es el derecho de protección de datos determinante, y BaFin no tiene competencia. En su lugar rige la nFADP, la ley federal revisada suiza de protección de datos desde septiembre de 2023, y FINMA como autoridad federal de supervisión del mercado financiero. En el barrio de Paradeplatz se asientan UBS - tras la absorción de Credit Suisse en 2023 el mayor banco suizo con diferencia - así como Zurich Insurance Group y Swiss Re como dos de los mayores reaseguradores mundiales. ABB tiene sede corporativa en Oerlikon, Sika en Baar, Holcim en Jona. Google opera en Zúrich uno de sus mayores centros de ingeniería fuera de EE.UU. Esta mezcla genera un mercado IA con alta madurez técnica y un marco regulatorio más pragmático y sectorial que la regulación UE. Para empresas españolas con matriz suiza (Roche, Novartis, Nestlé al margen de Vaud), Zúrich es mercado obligatorio de validación IA. Nota: a diferencia de España, Suiza se rige por FADP (Federal Act on Data Protection / nDSG), no por RGPD.

## Tres obstáculos regulatorios que moldean toda iniciativa IA en el mercado de Zúrich

El primer obstáculo es FINMA como supervisión financiera. Ha concretado en 2024 sus expectativas sobre gobernanza de modelos IA en bancos y aseguradoras en un documento de supervisión propio - con exigencias claras sobre riesgo de modelo, explicabilidad y auditabilidad. UBS, Zurich Insurance, Swiss Re y los bancos privados aquí asentados deben validar cada componente IA en gestión de riesgo, underwriting o wealth management contra estas expectativas FINMA.

El segundo obstáculo es el EDÖB como delegado federal de protección de datos y transparencia y la nFADP - la nueva ley de protección de datos desde 2023. Es esencialmente compatible con el RGPD, pero tiene obligaciones propias sobre Privacy by Design, profiling y decisiones automatizadas que deben demostrarse por separado.

El tercer obstáculo es el propio discurso regulatorio IA suizo: el Consejo Federal decidió en 2024 que Suiza no creará una ley IA integral propia, sino que regulará sectorialmente - lo que significa que FINMA, Swissmedic y BAKOM formulan cada una exigencias propias a IA en sus dominios. Quien planifica en Zúrich debe conocer la respectiva supervisión sectorial en detalle. Más contexto en [EU AI Act](/es/governance/eu-ai-act/) - la lógica UE sigue siendo para empresas suizas con negocio UE un segundo vector de cumplimiento.

## Escenarios típicos de implementación en Zúrich

En UBS y el entorno bancario suizo ampliado vemos agentes de reporting Wealth Management que preparan comunicación estructurada con el cliente y reports de performance - el asesor decide, el agente estructura. En Zurich Insurance los agentes soportan la gestión de siniestros en no-vida y vida, con enriquecimiento claro del aviso de siniestro con datos contractuales, peritajes y controles de plausibilidad - la decisión final la toma un perito con background asegurador. En Swiss Re se trata de modelado de reaseguro y Cat-Modelling donde los underwriters reciben los resultados como propuesta y responsabilizan la aceptación final. ABB trabaja en casos de uso Industrial Control System donde operadores industriales toman la decisión final. Google Zurich utiliza tooling de ingeniería propio y es menos relevante como mercado para arquitectura externa de agentes - pero el entorno técnico de talento en Zúrich está fuertemente influido por él. En Sika y Holcim vemos Document Agents para análisis de contratos y fichas de seguridad en entorno química para construcción. En todos los casos el [Decision Layer](/es/decision-layer/) mantiene la cadena de justificación como Audit Trail - en una forma que satisface simultáneamente exigencias FINMA y obligaciones nFADP.

## Cómo Gosign atiende Zúrich desde Hamburgo

Gosign no tiene filial suiza. El mercado suizo acepta prestadores alemanes sin filial local mientras la retención de datos, la ingeniería y la estructura contractual estén claramente reguladas. Concretamente: trabajamos como GmbH alemana con sede en Hamburgo, la estructura contractual sigue derecho suizo o un modelo dual, la retención de datos se hace bien en infraestructura cloud suiza (Swisscom, Exoscale) bien en un setup UE operado según estándares nFADP con las medidas de protección correspondientes. Los Discovery Workshops los hacemos in situ en Zúrich - el vuelo directo Hamburgo-Zúrich requiere una hora de vuelo, el ICE vía Basilea es alternativa sensata. En fase de Engineering trabajamos en remoto con días presenciales quincenales y foco en las citas de validación relevantes para FINMA. Importante es la separación explícita entre los conjuntos de reglas para datos suizos y los conjuntos para datos UE - el Decision Layer lleva ambas lógicas en paralelo, porque muchos grupos suizos tienen negocio UE y deben cumplir ambos regímenes. Clústeres como ETH AI Center, Impact Hub Zürich y Zurich Insurance Innovation los utilizamos para intercambio técnico. Para clientes españoles con matriz o filiales suizas, coordinamos desde Barcelona con documentación ES/DE/EN.

## Por qué Zúrich funciona como punto de partida para Enterprise AI

Suiza tiene una ventaja estructural que los mercados UE no tienen: la regulación es sectorial, pragmática y en regla menos formalista que el EU AI Act. Quien pone en producción un primer AI Agent en Zúrich en entorno regulado, lo ha defendido contra las expectativas FINMA, contra la nFADP y contra la exigencia suiza de limpieza técnica. Esta arquitectura está luego preparada para escalado al espacio UE, porque la gobernanza subyacente ya cumple el estándar más alto. Se añade el entorno técnico: la ETH Zürich es una de las instituciones de investigación ML líderes mundiales, el ETH AI Center aglutina unos 100 grupos de investigación, y Google Zurich, IBM Research Zurich así como el entorno CERN en la Suiza occidental convierten al mercado en uno de los emplazamientos técnicos más maduros de Europa. Quien en 4-6 semanas tiene un primer AI Agent productivo en un grupo suizo, construye sobre un mercado que premia la arquitectura pragmática y evita burocracia innecesaria. Más sobre el procedimiento en [AI Agents Servicios](/es/servicios/ai-agents/).

--- Aviso legal - Gosign GmbH ---
> Aviso legal de Gosign GmbH, Hamburgo. Directores generales, contacto, registro mercantil e información jurídica.

<h1>Aviso legal</h1>

<h2>Aviso legal según § 5 DDG (Ley alemana de servicios digitales)</h2>
<p>
Gosign GmbH<br/>
Hallerstraße 8<br/>
20146 Hamburgo, Alemania
</p>

<h2>Representada por</h2>

<div class="grid grid-cols-1 sm:grid-cols-2 gap-8 not-prose my-8">
<div class="flex items-start gap-4">
<img
src="/images/team/bert-gogolin.webp"
alt="Bert Gogolin, Director General de Gosign GmbH"
width="80"
height="80"
class="rounded-full w-20 h-20 object-cover flex-shrink-0"
loading="lazy"
/>
<div>
<p class="font-semibold text-gosign-dark text-body">Bert Gogolin</p>
<p class="text-small text-gosign-text-light">Director General</p>
<a
href="https://www.linkedin.com/in/bertgogolin/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center gap-1 text-small text-gosign-text-light hover:text-gosign-accent transition-colors mt-1"
aria-label="Bert Gogolin en LinkedIn"
>
<svg class="w-4 h-4" fill="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path d="M20.447 20.452h-3.554v-5.569c0-1.328-.027-3.037-1.852-3.037-1.853 0-2.136 1.445-2.136 2.939v5.667H9.351V9h3.414v1.561h.046c.477-.9 1.637-1.85 3.37-1.85 3.601 0 4.267 2.37 4.267 5.455v6.286zM5.337 7.433a2.062 2.062 0 01-2.063-2.065 2.064 2.064 0 112.063 2.065zm1.782 13.019H3.555V9h3.564v11.452zM22.225 0H1.771C.792 0 0 .774 0 1.729v20.542C0 23.227.792 24 1.771 24h20.451C23.2 24 24 23.227 24 22.271V1.729C24 .774 23.2 0 22.222 0h.003z"/>
</svg>
LinkedIn
</a>
</div>
</div>

<div class="flex items-start gap-4">
<img
src="/images/team/dieter-gogolin.webp"
alt="Dieter Gogolin, Director General de Gosign GmbH"
width="80"
height="80"
class="rounded-full w-20 h-20 object-cover flex-shrink-0"
loading="lazy"
/>
<div>
<p class="font-semibold text-gosign-dark text-body">Dieter Gogolin</p>
<p class="text-small text-gosign-text-light">Director General</p>
</div>
</div>
</div>

<h2>Contacto</h2>
<p>
Correo electrónico: web26 [at] gosign.de<br/>
Contacto: A través de nuestro <a href="/es/contacto/" class="text-gosign-accent-text hover:text-gosign-accent-hover">formulario de contacto</a> o <a href="/es/contacto/#booking" class="text-gosign-accent-text hover:text-gosign-accent-hover">reserva de cita</a>
</p>

<h2>Registro mercantil</h2>
<p>
Juzgado de registro: Juzgado de lo Mercantil de Hamburgo (Amtsgericht Hamburg)<br/>
Número de registro: HRB 112197
</p>

<h2>NIF-IVA</h2>
<p>
Número de identificación fiscal según § 27a de la Ley alemana del IVA (Umsatzsteuergesetz):<br/>
DE215891388
</p>

<h2>Responsable del contenido según § 18 párr. 2 MStV</h2>
<p>
Gosign GmbH<br/>
Bert Gogolin<br/>
Hallerstraße 8<br/>
20146 Hamburgo, Alemania
</p>

<h2>Responsabilidad por contenidos</h2>
<p>
Como proveedor de servicios, somos responsables de nuestros propios contenidos en estas páginas de acuerdo con el § 7 párr. 1 DDG y la legislación general. Sin embargo, conforme a los §§ 8 a 10 DDG, no estamos obligados a supervisar la información transmitida o almacenada de terceros ni a investigar circunstancias que indiquen una actividad ilícita.
</p>
<p>
Las obligaciones de eliminar o bloquear el uso de información según la legislación general no se ven afectadas. Sin embargo, la responsabilidad al respecto solo es posible a partir del momento en que se tenga conocimiento de una infracción concreta. Tan pronto como tengamos conocimiento de las infracciones correspondientes, eliminaremos dichos contenidos de inmediato.
</p>

<h2>Responsabilidad por enlaces</h2>
<p>
Nuestro sitio web contiene enlaces a páginas web externas de terceros sobre cuyo contenido no tenemos influencia. Por lo tanto, no podemos asumir ninguna responsabilidad por estos contenidos externos. El proveedor u operador respectivo de las páginas enlazadas es siempre responsable de sus contenidos. Las páginas enlazadas fueron revisadas en busca de posibles infracciones legales en el momento del enlace. No se detectaron contenidos ilegales en el momento del enlace.
</p>
<p>
Un control permanente del contenido de las páginas enlazadas no es razonable sin indicios concretos de una infracción legal. Tan pronto como tengamos conocimiento de infracciones legales, eliminaremos dichos enlaces de inmediato.
</p>

<h2>Derechos de autor</h2>
<p>
Los contenidos y obras creados por los operadores del sitio en estas páginas están sujetos a la legislación alemana sobre derechos de autor. La reproducción, edición, distribución y cualquier tipo de uso fuera de los límites del derecho de autor requieren el consentimiento escrito del autor o creador respectivo. Las descargas y copias de este sitio solo están permitidas para uso privado y no comercial.
</p>
<p>
En la medida en que los contenidos de esta página no hayan sido creados por el operador, se respetan los derechos de autor de terceros. En particular, los contenidos de terceros se identifican como tales. Si detecta una infracción de derechos de autor, le rogamos nos lo comunique. Tan pronto como tengamos conocimiento de infracciones legales, eliminaremos dichos contenidos de inmediato.
</p>

<h2>Créditos de imagen</h2>
<p>
Retratos de la dirección: © Gosign GmbH.<br/>
Gráficos y diagramas: Creados por Gosign GmbH, parcialmente con herramientas asistidas por IA.<br/>
Salvo indicación contraria: © Gosign GmbH. Todos los derechos reservados.
</p>

<h2>Resolución de litigios</h2>
<p>
La Comisión Europea proporciona una plataforma para la resolución de litigios en línea (ODR):
<a href="https://ec.europa.eu/consumers/odr/" target="_blank" rel="noopener noreferrer" class="text-gosign-accent-text hover:text-gosign-accent-hover">https://ec.europa.eu/consumers/odr/</a>
</p>
<p>
No estamos obligados ni dispuestos a participar en procedimientos de resolución de litigios ante una junta de arbitraje de consumo.
</p>

<h2>Aviso de marcas registradas</h2>
<p>
<a href="https://www.sap.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text hover:text-gosign-accent transition-colors">SAP</a>, SAP S/4HANA, SAP SuccessFactors, SAP Business Technology Platform y SAP Joule son marcas registradas o marcas de SAP SE, Walldorf, Alemania.
</p>
<p>
<a href="https://www.microsoft.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text hover:text-gosign-accent transition-colors">Microsoft</a>, Microsoft Azure, Microsoft Copilot, Microsoft Teams, SharePoint, Active Directory y Microsoft Graph son marcas registradas o marcas de Microsoft Corporation, Redmond, EE. UU.
</p>
<p>
<a href="https://www.sage.com/es-es/" target="_blank" rel="noopener noreferrer" class="text-gosign-text hover:text-gosign-accent transition-colors">Sage</a> es una marca registrada de The Sage Group plc, Newcastle upon Tyne, Reino Unido.
</p>
<p>
<a href="https://www.wolterskluwer.com/es-es/solutions/a3" target="_blank" rel="noopener noreferrer" class="text-gosign-text hover:text-gosign-accent transition-colors">A3</a> es una marca de Wolters Kluwer N.V., Alphen aan den Rijn, Países Bajos.
</p>
<p>
<a href="https://www.cegid.com/es/" target="_blank" rel="noopener noreferrer" class="text-gosign-text hover:text-gosign-accent transition-colors">Meta4</a> es una marca de Cegid Group, Lyon, Francia.
</p>
<p>
<a href="https://www.workday.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text hover:text-gosign-accent transition-colors">Workday</a> es una marca registrada de Workday, Inc., Pleasanton, EE. UU.
</p>
<p>
<a href="https://www.personio.de/" target="_blank" rel="noopener noreferrer" class="text-gosign-text hover:text-gosign-accent transition-colors">Personio</a> es una marca de Personio SE & Co. KG, Múnich, Alemania.
</p>
<p>
<a href="https://about.google/" target="_blank" rel="noopener noreferrer" class="text-gosign-text hover:text-gosign-accent transition-colors">Google</a> y Google Calendar son marcas de Google LLC, Mountain View, EE. UU.
</p>
<p>
Todos los demás nombres de productos y empresas mencionados son marcas o marcas registradas de sus respectivos titulares.
</p>
<p>
El uso de marcas en este sitio web tiene únicamente fines de identificación de productos y no implica afiliación, certificación ni respaldo por parte de los respectivos titulares de las marcas.
</p>

--- Agente de Contabilización ---
> Asigna facturas entrantes a la cuenta contable correcta (SKR03/04 o individual), al centro de coste y al código fiscal correspondiente.

## Una contabilización incorrecta cuesta cinco cifras en cada inspección de la AEAT

Las pymes que reciben una inspección tributaria acaban pagando, de media, 24.000 EUR (aproximadamente 26.000 USD) en regularizaciones. En las inspecciones específicas de IVA la cifra sube hasta unos 25.000 EUR por empresa. Más de la mitad de todas las actuaciones terminan con liquidación complementaria. La causa más frecuente: una contabilización errónea. Cuenta incorrecta significa tipo de IVA incorrecto. Tipo de IVA incorrecto significa deducción de IVA soportado denegada. Una deducción denegada acumulada durante varios ejercicios alcanza rápidamente las seis cifras.

El problema no es la negligencia. Una empresa con 10.000 facturas de entrada al mes toma 10.000 decisiones de contabilización cada mes. En el tratamiento manual, la tasa de error según el Institute of Finance and Management (IOFM) se sitúa en torno al 2 por ciento. Eso significa 200 facturas mensuales en las que la cuenta, el centro de coste o el código fiscal no cuadran. Cada una de ellas es un hallazgo que un inspector de la AEAT puede utilizar.

## Diez decisiones por factura - cada una con efecto tributario

La contabilización suele tratarse como un paso de registro. En realidad es una cadena de diez decisiones individuales que desencadenan consecuencias jurídicas distintas en cada caso.

Un ejemplo del día a día: llega una factura por servicios de consultoría de un prestador comunitario. El departamento de contabilidad debe decidir qué cuenta aplicar, qué centro de coste asignar, qué centro de beneficio asume el gasto, si corresponde inversión del sujeto pasivo (Reverse Charge) o IVA ordinario, si el IVA soportado es deducible, si el importe supera el umbral de activación como inmovilizado y si procede periodificar el gasto. Solo cuando todas las decisiones parciales son correctas, el asiento es correcto.

Cada una de estas decisiones sigue su propia lógica. La asignación de cuenta se deriva de la descripción del servicio y del plan de cuentas. El código fiscal se rige por la Ley del IVA. La obligación de activar como inmovilizado se rige por el Plan General de Contabilidad (PGC) y el Impuesto de Sociedades. Quien analiza una decisión de forma aislada pasa por alto las interacciones. Quien las toma manualmente en conjunto necesita experiencia, concentración y tiempo - en cada factura.

## Contabilizar por reglas, escalar solo los casos de interpretación

El [Decision Layer](/es/decision-layer/) descompone cada proceso de contabilización en estos diez pasos de decisión y define para cada uno si se resuelve por reglas, con IA o con intervención humana. En contabilización el reparto es contundente: nueve de cada diez pasos se resuelven por reglas. Determinación del código fiscal según la Ley del IVA, comprobación de la deducibilidad del IVA soportado, umbrales para inmovilizado según PGC, periodificación según el principio de devengo. Son decisiones deterministas con resultado unívoco.

El único paso que requiere apoyo de IA es la interpretación. Cuando la descripción del servicio en una factura dice "apoyo de proyecto H3" y el plan de cuentas contempla 15 cuentas posibles, un conjunto de reglas no basta. Aquí el modelo de lenguaje evalúa, sobre la base de contabilizaciones históricas, qué cuenta encaja - y devuelve un Confidence Score. Si el score queda por debajo del umbral definido, el agente escala a un responsable. Si lo supera, contabiliza de forma automática.

El resultado: contabilidad ya no procesa 10.000 facturas. Procesa las 300 en las que el agente no está suficientemente seguro. El resto pasa por el flujo - verificado, contabilizado y documentado.

## Cada contabilización se convierte en prueba para la inspección

El inspector de la AEAT no pregunta si una contabilización es correcta. Pregunta por qué se realizó así y no de otra forma. Ahí radica la debilidad de la contabilidad manual: la justificación solo existe en la cabeza del responsable que procesó la factura hace ocho meses.

El agente documenta para cada contabilización la ruta completa de decisión: cuenta aplicada con justificación, código fiscal con referencia a la Ley del IVA, centro de coste, Confidence Score y si la decisión fue automática o manual. Esto cumple con los requisitos del estándar contable alemán GoBD (estándar alemán de contabilidad) (estándar alemán de contabilidad) para la documentación de procedimientos, aplicables a los clientes del grupo. Para la AEAT y los requisitos de conservación según el artículo 29 de la Ley General Tributaria, el enfoque es equivalente: el inspector no ve un resultado. Ve el camino que llevó hasta él - para cada una de las 120.000 facturas del año.

## El motor del plan de cuentas como base para todos los agentes contables

La contabilización es el primer paso en cuentas por pagar, pero no el único. Gastos de viaje, representación, altas de inmovilizado, provisiones, periodificaciones - cada uno de estos procesos necesita la misma lógica base: servicio a cuenta contable a código fiscal. Quien construye esta asignación limpia para la contabilización está construyendo a la vez la infraestructura para cualquier agente contable posterior.

El marco de mapeo que utiliza el agente de contabilización se convierte en pieza estándar. La evaluación mediante Confidence Score y el patrón de escalado - contabilizar de forma automática o entregar a un Human-in-the-Loop - se convierten en plantilla reutilizable. No todos los agentes de Finance deben volver a responder la pregunta de cómo tratar la incertidumbre. El agente de contabilización la responde una vez, y los demás se apoyan en ello.

--- Agente de Periodificación ---
> Identifica activos y pasivos de periodificación a partir de pagos y períodos de servicio, calcula importes proporcionales.

Cuando el cierre mensual entrega un resultado del período distorsionado, el Consejo de Administración toma decisiones sobre una base errónea. La causa más frecuente: partidas de periodificación ausentes o incorrectas. El 94 por ciento de los equipos financieros siguen elaborando sus periodificaciones en hojas de cálculo - y la mitad necesita más de seis días hábiles para todo el cierre mensual. Y sin embargo, la periodificación, en su núcleo, no es una cuestión de criterio. Es aritmética con calendario.

## Cada ARAP olvidado distorsiona la base para la toma de decisiones

Una prima anual de seguro de 120.000 EUR (unos 130.000 USD) se paga en enero. Sin periodificación, esos 120.000 EUR cargan el resultado de enero, mientras que de febrero a diciembre la imagen queda demasiado favorable. Multiplicado por decenas de partidas parecidas - licencias de software, contratos de mantenimiento, alquileres pagados por adelantado - el resultado mensual termina diciendo más sobre los momentos de pago que sobre la evolución real del negocio.

Las consecuencias van más allá de la óptica del balance. Resultados periódicos incorrectos distorsionan forecasts, falsean análisis de desviaciones y minan la confianza de auditores y consejos de administración. Según un análisis del Center for Audit Quality, las periodificaciones, provisiones y estimaciones erróneas son la causa más citada de reexpresiones financieras (financial restatements). Cada corrección no solo cuesta dinero, sino sobre todo credibilidad.

## Ocho de cada diez pasos de decisión son aritmética pura

El [Decision Layer](/es/decision-layer/) descompone cada proceso de periodificación en diez pasos de decisión. Ocho de ellos son íntegramente basados en reglas: ¿existe un pago anticipado (ARAP)? ¿Hay un ingreso cobrado antes del cierre que corresponde al período posterior (PRAP)? ¿Se trata de una provisión o de una periodificación? ¿A qué período corresponde económicamente el gasto? ¿Cuál es el importe proporcional? ¿Está el importe valorado con prudencia? ¿Qué asiento corresponde? ¿Y cuándo exactamente se realiza la disolución?

Para ninguno de estos pasos hace falta criterio humano. La comparación de fechas entre el momento del pago y el período de servicio es inequívoca. El cálculo proporcional sigue una fórmula fija. La lógica contable para ARAP o PRAP está definida en cualquier plan general de cuentas. Y el contraasiento en el mes siguiente es una consecuencia automática del asiento inicial.

Precisamente por eso el agente de periodificación es el ejemplo paradigmático de automatización en el libro mayor: alto volumen, baja complejidad, cero margen de decisión. La documentación conforme a los requisitos contables - base, período de servicio, ruta de cálculo, fecha de disolución - surge como subproducto de cada asiento, no como una tarea obligatoria posterior.

## Dos pasos muestran dónde la IA marca la diferencia

La auténtica debilidad de las periodificaciones manuales no está en el cálculo. Está en el reconocimiento. ¿Quién identifica el nuevo contrato marco con pago trimestral y período de servicio mensual? ¿Quién encuentra la factura de diciembre cuyo período de servicio llega hasta marzo?

Dos de los diez pasos de decisión utilizan IA: la estimación del importe de periodificación cuando aún no existe importe de factura, y el reconocimiento de supuestos que cruzan períodos en contratos y facturas. El agente busca en nuevos contratos los períodos de servicio, coteja datos de factura con vigencias contractuales e identifica supuestos que requieren periodificación - antes de que falten en el cierre mensual. Este reconocimiento es la razón por la que el agente no solo trabaja más rápido que una persona, sino de forma más completa.

La intervención humana se mantiene donde debe estar: en la revisión del auditor externo. Cada periodificación individual - basada en reglas o reconocida por IA - es auditable e impugnable.

## Efecto concreto: el cierre mensual pierde su cuello de botella

Una empresa industrial con 200 partidas activas de periodificación al mes - licencias de software, seguros, cuotas de leasing, contratos de mantenimiento, servicios prepagados - suele emplear entre dos y tres días-persona solo para la periodificación. Listas de Excel con períodos de servicio, asientos manuales, control de las disoluciones del mes anterior.

El agente reduce ese esfuerzo a la revisión de excepciones. Las periodificaciones recurrentes se crean y disuelven de forma automática. Los nuevos supuestos se detectan y se presentan para aprobación con Human-in-the-Loop. La documentación es inmediatamente apta para auditoría. Lo que queda es una lista de aprobaciones en lugar de una lista de creación.

La infraestructura de devengo que construye el agente tiene un efecto que va más allá del propio proceso. La lógica de disolución es reutilizada por el agente de provisiones. El reconocimiento de supuestos que cruzan períodos suministra datos de entrada al agente de contabilización de arrendamientos y al agente de cumplimiento contractual. La periodificación no es el proceso más espectacular de la contabilidad. Pero es la base sobre la que se asientan todos los demás resultados periódicos.

--- Agente de Preparación de Cuentas Anuales ---
> Orquesta la checklist de cuentas anuales, consolida conciliaciones, verifica opciones de valoración, redacta anexo e informe de gestión.

Ningún cierre anual fracasa por falta de competencia técnica. Fracasa por la orquestación: conciliaciones que no se terminan, consultas sobre el cuadro de inmovilizado que pasan tres días en una bandeja de entrada, notas del anexo que se redactan en el último momento. El equipo financiero conoce cada paso individual - y aun así pierde semanas coordinando esos pasos entre sí.

## Las semanas de cierre atan al equipo entero a trabajo rutinario

Según el APQC Open Standards Benchmarking, la mediana del cierre mensual se sitúa intersectorialmente en el rango superior de días de un solo dígito - la mayoría de los equipos financieros necesitan más de cinco días laborables solo para el cierre mensual. El cierre anual multiplica ese esfuerzo: cuadro de inmovilizado, cuadro de provisiones, estado de cambios en el patrimonio, estado de flujos de efectivo, conciliación fiscal, anexo, informe de gestión, documentación para el auditor y depósito de cuentas.

Un escenario concreto ilustra el problema. Una empresa industrial de tamaño medio con 200 millones de euros (aproximadamente 218 millones de USD) de facturación cierra el ejercicio. El director financiero coordina un equipo de seis personas durante cuatro semanas. Tres de ellas dedican la mayor parte de su tiempo a elaborar cuadros - es decir, derivaciones aritméticas de datos que ya existen en el sistema. Una persona recopila documentación para el auditor. Las decisiones de valoración - el verdadero trabajo técnico - ocupan quizá un 20 por ciento del tiempo total de cierre.

Al mismo tiempo, el retraso en el depósito de cuentas acarrea sanciones. En España, la Ley de Sociedades de Capital prevé multas que oscilan entre 1.200 y 60.000 euros (entre 1.300 y 65.400 USD) por depósito tardío. Para empresas cotizadas, además de la sanción está en juego la reputación.

## Quince pasos de decisión separan la rutina del criterio profesional

El [Decision Layer](/es/decision-layer/) descompone todo el proceso de cierre anual en quince pasos de decisión individuales - y asigna cada uno a un nivel claro. El resultado es un mapa que muestra dónde la automatización tiene sentido y dónde se requiere juicio humano.

El nivel 1 (motor de reglas) abarca nueve pasos: la checklist de cierre, la consolidación de conciliaciones, la conciliación fiscal en casos estándar, el cálculo de impuestos diferidos a partir de diferencias temporales, la preparación del depósito de cuentas conforme al PGC (estándar contable alemán GoBD (estándar alemán de contabilidad) (estándar alemán de contabilidad)), así como los cuatro cuadros (provisiones, inmovilizado, patrimonio neto, flujos de efectivo). Todo ello sigue reglas definidas y datos existentes.

El nivel 2 (borrador IA con aprobación humana) cubre tres pasos: el borrador de notas del anexo conforme al PGC, el borrador del informe de gestión y la preparación de la documentación para el auditor según la lista PBC. El agente genera borradores estructurados - la responsabilidad sobre el contenido permanece en el equipo especializado.

Tres pasos quedan exclusivamente en manos humanas: las opciones de valoración (decisión de política contable), la verificación de eventos posteriores (evaluación de materialidad) y la declaración de responsabilidad (atestación personal por la dirección conforme al artículo 253 de la Ley de Sociedades de Capital). Ninguna automatización sustituye el criterio que exigen estos pasos.

## El agente orquesta - el humano decide

¿Qué cambia en la práctica? El agente asume la cadencia. Verifica que todas las conciliaciones estén cerradas antes de iniciar el siguiente paso. Genera los cuatro cuadros directamente a partir de los resultados de los agentes previos. Prepara las notas del anexo como borrador estructurado que el equipo revisa en lugar de escribir desde cero. Recopila el paquete para el auditor según la lista PBC del auditor externo.

El equipo desplaza su tiempo: de la coordinación a las decisiones de valoración. La pregunta ya no es "¿Tenemos listo el cuadro de inmovilizado?", sino "¿Qué método de valoración aplicamos a las provisiones por pensiones?" - la pregunta por la que realmente se paga a un CFO.

Para el auditor surge un efecto secundario: cada paso de decisión está documentado, cada fuente de datos es trazable. La auditoría no se vuelve más fácil en el sentido de menos rigurosa - pero comienza con una base completa y estructurada.

## Cada agente previo mejora la calidad del cierre

El agente de cuentas anuales no es una herramienta aislada. Es el punto de integración de toda la infraestructura financiera. El cuadro de inmovilizado se nutre del agente de amortización. El cuadro de provisiones recurre al agente de provisiones. La conciliación de cuentas la proporciona el agente de conciliación, los datos fiscales el agente de IVA, las correcciones de valor el agente de gestión de cobros.

Esto significa: quien opera limpiamente los agentes previos tiene automáticamente mejores datos en el cierre anual. Quien define el cierre anual como objetivo, construye toda la infraestructura de agentes hacia atrás desde ese punto. El cierre anual no es el principio - es la prueba de que la infraestructura funciona.

--- Agente de Alta de Activos Fijos ---
> Identifica activos activables a partir de facturas, determina costes de adquisición y producción según HGB §255.

Las decisiones de activación incorrectas figuran entre los errores evitables más costosos en la contabilidad de inmovilizado. Quien contabiliza un bien de inversión como gasto, deprime el beneficio en el ejercicio equivocado. Quien activa un gasto corriente, infla el balance. En ambos casos, las amortizaciones, la carga fiscal y el cuadro de inmovilizado no cuadran durante años. El agente de alta de activos fijos previene exactamente esta mala asignación - no automatizando toda la contabilidad, sino descomponiendo de forma estructurada cada decisión de activación individual.

## Una de cada tres inspecciones fiscales cuestiona el inmovilizado

Las cifras son contundentes. Según una encuesta de PwC, una de cada dos empresas alemanas debe pagar impuestos adicionales tras una inspección fiscal. En el 29 por ciento de las empresas afectadas, las objeciones se refieren a la contabilización del inmovilizado (fuente: estudio PwC "Betriebsprüfung (auditoría fiscal alemana)", 2024). El motivo más frecuente: bienes económicos mal clasificados, costes accesorios de adquisición incorrectamente asignados o vidas útiles fijadas sin justificación trazable.

El Ministerio Federal de Finanzas alemán cifra el resultado adicional de todas las inspecciones fiscales en 2024 en 10.900 millones de euros (aproximadamente 11.900 millones de USD) sobre 140.764 empresas inspeccionadas (informe mensual del BMF, noviembre 2025). Una parte considerable corresponde a correcciones en el inmovilizado - porque la decisión de activación original no estaba documentada o se basaba en supuestos erróneos.

Para los CFO esto significa: la decisión de activación no es un detalle contable. Es un riesgo de inspección con consecuencias financieras cuantificables. En España, las actuaciones de comprobación de la AEAT (LGT Art. 29) siguen una lógica análoga.

## La decisión de activación se toma en segundos - y tiene efecto durante años

Imaginemos una semana típica en la contabilidad de proveedores de una mediana empresa. 40 facturas recibidas, de las cuales seis superan los 800 euros (unos 870 USD) netos. Cada una de estas facturas exige la misma secuencia de decisiones: ¿Es un bien económico o un servicio corriente? ¿Supera el importe el umbral de activos de bajo valor? ¿Qué clase de activo? ¿Qué vida útil según las tablas oficiales de amortización? ¿Los costes de transporte forman parte de los costes accesorios de adquisición?

Un contable toma estas decisiones a menudo en minutos - bajo presión de tiempo, con información incompleta, a veces apoyándose en la experiencia en lugar de en la tabla oficial vigente. La consecuencia se manifiesta años después: en el inventario, cuando los activos físicos y el cuadro de inmovilizado no coinciden. O en la inspección fiscal, cuando el inspector cuestiona la vida útil de una máquina especial y no encuentra documentación.

La fuente de error no reside en la falta de competencia. Reside en la estructura: cada decisión de activación contiene componentes deterministas (umbral, clase de activo, cálculo de costes de adquisición) y márgenes de discrecionalidad (vida útil en activos especiales, delimitación de bienes compuestos). Cuando ambos se funden en un paso manual, falta la trazabilidad.

## Nueve pasos de decisión separan el motor de reglas del criterio profesional

El [Decision Layer](/es/decision-layer/) descompone el alta de activos en nueve pasos discretos. Cada paso tiene un decisor definido: motor de reglas, modelo IA o humano.

La identificación del bien económico a partir de la descripción de la factura utiliza un modelo de lenguaje. Una factura por "montaje y puesta en marcha de línea de fabricación nave 7" no contiene número EAN ni registro de activos - pero sí suficiente contexto para reconocer el bien económico.

La verificación de activación es puramente basada en reglas: importe neto superior a 800 euros, por tanto obligación de activación conforme al PGC (estándar contable alemán GoBD (estándar alemán de contabilidad)). Por debajo, tratamiento como activo de bajo valor o partida colectiva. Lo mismo aplica para la determinación de costes de adquisición conforme al PGC, la asignación de número de inventario y el registro en el cuadro de inmovilizado. Estos pasos son deterministas. No se benefician del criterio humano, sino de la consistencia y la exhaustividad.

Diferente en los casos límite: la asignación de una fresadora CNC con equipamiento especial a la clase de activo correcta puede prepararse por reglas, pero no decidirse definitivamente. La vida útil de una máquina especial no figura en las tablas oficiales de amortización. Aquí decide el humano - pero sobre la base de una propuesta de decisión preestructurada, no sobre una hoja en blanco.

## El humano decide donde se requiere criterio profesional

El agente de alta de activos opera en los niveles 1 y 2 del Decision Layer. Esto significa: los pasos basados en reglas se ejecutan automáticamente con protocolo. Los pasos asistidos por IA proporcionan propuestas con nivel de confianza. Ningún paso modifica el balance sin una base de decisión documentada.

En concreto: cuando el agente procesa una factura de 12.000 euros (unos 13.100 USD) por una balanza de laboratorio, la verificación de activación se ejecuta por reglas. La clase de activo "instalaciones técnicas y maquinaria" se asigna por reglas. La vida útil de 10 años proviene de la tabla oficial, referencia documentada. Los costes accesorios por calibración e instalación se imputan a los costes de adquisición conforme al PGC.

Para la inspección fiscal surge así una ruta de decisión completa: por qué se activó, cómo se clasificó, qué componentes de costes de adquisición, qué vida útil con qué base legal. Esta documentación no se crea a posteriori para el inspector. Surge como subproducto natural de cada decisión de activación individual.

Esto no reduce la responsabilidad del CFO sobre la corrección del balance. Le proporciona la base para ejercer esa responsabilidad de forma informada - en lugar de confiar en que nadie en la contabilidad de proveedores haya cometido un error.

--- Agente de Inventario ---
> Genera listas de inventario de la contabilidad de activos, concilia saldo teórico y real.

Entre el 10 y el 30 por ciento de todos los registros en los cuadros de inmovilizado son los denominados Ghost Assets - bienes que solo existen sobre el papel. El inventario anual conforme a la normativa contable (en Alemania, HGB parrafo 240; en España, PGC) busca prevenir exactamente eso. En la práctica, a menudo fracasa por el propio proceso: recuento manual a través de múltiples sedes, conciliación basada en Excel, semanas de repaso. El agente de inventario resuelve este problema asumiendo completamente la parte basada en reglas del inventario y deteniéndose solo donde se requiere juicio humano.

## Uno de cada tres activos en el registro solo existe sobre el papel

Los Ghost Assets surgen de forma progresiva. Se sustituye una impresora, pero la baja no se contabiliza. Se traslada una máquina a otra sede sin actualizar los datos maestros. Después de cinco años sin verificación física, el cuadro de inmovilizado se ha alejado tanto de la realidad que el inventario se convierte en un proyecto de saneamiento. Las consecuencias son cuantificables: primas de seguro infladas porque se calculan sobre valores contables abultados. Amortizaciones innecesarias sobre bienes que hace tiempo se han desechado. En el peor de los casos, una salvedad en el informe de auditoría porque el auditor no acepta la diferencia entre registro y realidad.

## El inventario manual no escala a través de múltiples sedes

Un fabricante de maquinaria de tamaño medio con cuatro plantas de producción y 8.000 activos fijos conoce el patrón: tres semanas antes de la fecha de corte comienza la coordinación. Se organizan equipos de inventario, se imprimen listas de recuento, se distribuyen escáneres. Cada sede cuenta a su propio ritmo. Los resultados llegan por correo electrónico - como archivos Excel con formatos diferentes. La consolidación central dura otras dos semanas. Los faltantes se detectan tarde, los recuentos adicionales retrasan el cierre. El resultado: el inventario consume entre cuatro y seis semanas de tiempo de trabajo, y aun así persisten dudas sobre la exhaustividad.

## El agente separa contar de valorar

El [Decision Layer](/es/decision-layer/) divide el inventario de activos en dos categorías de decisiones. Los pasos basados en reglas - generar la lista de inventario desde el ERP, registrar el saldo real, ejecutar la conciliación teórico/real, identificar faltantes, preparar asientos de corrección - se ejecutan de forma automatizada. El agente concilia el saldo contable con el saldo físico y genera listas de diferencias por sede, centro de coste y clase de activo.

Dos decisiones quedan en manos humanas: ¿Ha perdido valor un activo? ¿Debe darse de baja? Estas cuestiones de valoración requieren inspección visual y criterio. El agente proporciona la base para la decisión - antigüedad, vida útil, estado según el último registro - pero la aprobación corresponde al departamento especializado. Así el proceso se mantiene conforme a auditoría según la normativa contable (PGC / estándar contable alemán GoBD (estándar alemán de contabilidad) (estándar alemán de contabilidad)), sin que la capacidad humana quede atada al trabajo de recuento.

## La captura por RFID eleva la precisión por encima del 95 por ciento

El inventario manual con escáneres de código de barras alcanza típicamente tasas de precisión del 85 al 95 por ciento. La captura por RFID eleva aún más la precisión y reduce significativamente el tiempo de captura. El agente de inventario utiliza ambas tecnologías: donde existen etiquetas RFID, captura el saldo real de una sala en segundos en lugar de horas. Donde solo hay códigos de barras, orquesta la captura manual con listas específicas por sede y seguimiento de progreso en tiempo real. La inversión en infraestructura RFID se amortiza en la práctica en pocos años - no solo por un inventario más rápido, sino también por un mejor seguimiento de ubicación en el día a día.

## Los asientos de corrección están listos el día del inventario

El verdadero objetivo del inventario no es el recuento, sino el registro de inmovilizado depurado. El agente de inventario prepara asientos de corrección en cuanto se confirma una desviación: contabilizaciones de baja para bienes no localizados, amortizaciones extraordinarias para activos deteriorados, correcciones de ubicación para bienes trasladados. Al final se genera un informe de inventario que documenta todo el proceso - desde la lista teórica pasando por la captura real hasta la aprobación de cada corrección individual. El auditor no recibe solo un resultado, sino la ruta de decisión completa. Esto acelera la auditoría de cuentas anuales y reduce las consultas a lo esencial.

--- Agente de Conciliación Bancaria ---
> Concilia extractos AEB Norma 43, CAMT.053 y Bizum contra los asientos del PGC de forma 100% determinista, con cuadre SII para la AEAT.

La conciliación bancaria en España es el primer punto que mira un inspector de la AEAT, una auditoría de cuentas anuales por una firma Big-4 (Deloitte, KPMG, EY, PwC) o un requerimiento del Banco de España. Las divergencias no aclaradas entre el saldo bancario del extracto AEB Norma 43 y el saldo contable de la cuenta 572 Bancos del PGC RD 1514/2007 son la señal de alarma más inequívoca en cualquier revisión. Los equipos financieros con tres a cinco cuentas bancarias en BBVA, Santander, CaixaBank, Sabadell, Bankinter o ING Direct dedican habitualmente entre 30 y 80 horas al mes solo al cuadre manual de extractos repartido entre varios sistemas, con una probabilidad de error que crece con cada interfaz adicional. Y las consecuencias regulatorias son simultáneas: sanción de la AEAT por divergencia con el SII en el modelo 303 de IVA, omisión en el modelo 347 anual de operaciones con terceros, divergencia con la CIRBE del Banco de España, eventual sanción de la AEPD por tratamiento indebido de datos bancarios y una observación en la auditoría de cuentas anuales obligatoria por la Ley 22/2015 si se superan dos de los tres umbrales (4 millones EUR de activo, 8 millones EUR de cifra de negocios, 50 empleados).

## Tres sanciones en paralelo: la AEAT por el modelo 347, el Banco de España por la CIRBE y la AEPD por los datos de las transferencias

La sanción de la AEAT por omitir o presentar mal el modelo 347 es uno de los riesgos materiales más frecuentes del ciclo de tesorería español. La Orden EHA/3012/2008 obliga a declarar las operaciones con terceros que superen 3.005,06 EUR por contraparte y año (IVA incluido) en febrero o marzo del año siguiente. La AEAT cruza automáticamente los modelos 347 entre las dos partes: si la Empresa A declara 25.000 EUR de compras a la B y esta declara 23.000 EUR de ventas a la A, salta un requerimiento a ambas para regularizar. La sanción por omisión es del 1% del importe omitido (mínimo 300 EUR) conforme a la LGT art. 198, además de los requerimientos. Para una empresa con 80 millones EUR de facturación que descubre en febrero 50 contrapartes omitidas con un importe acumulado de 2 millones EUR, la exposición alcanza 20.000 EUR en sanciones del modelo 347, más un 50-150% sobre las eventuales divergencias de IVA del art. 191-195 LGT.

A esto se suman riesgos paralelos. La divergencia frente a la CIRBE del Banco de España por un reporte mensual incorrecto de posiciones superiores a 9.000 EUR puede activar un requerimiento de la Dirección General de Supervisión con sanciones de hasta 1 millón EUR conforme a la Ley 10/2014. Una sanción de la AEPD por violación de los datos bancarios de transferencias o adeudos alcanza hasta el 4% de la facturación anual mundial o 20 millones EUR conforme al RGPD art. 83.5, con resoluciones publicadas con frecuencia entre 100.000 y 1.000.000 EUR para casos del sector financiero español. Y el Código de Comercio art. 28 sobre libros contables sin tachaduras genera una observación en la auditoría si los saldos bancarios no son consistentes: una salvedad o una opinión con salvedades del auditor en las cuentas anuales tiene impacto material en las sociedades cotizadas del IBEX-35, con efecto sobre la cotización bursátil y el rating crediticio.

## La conciliación bancaria española recorre 16 etapas determinadas, no 7

A diferencia del modelo alemán estándar (7 etapas con MT940 y GoBD) o del modelo SEPA puro (10 etapas con CAMT.053), la conciliación bancaria española orientada al cumplimiento exige 16 etapas determinadas, porque el sistema regulatorio superpone cinco capas obligatorias a la vez: la recepción de los extractos en formato AEB Norma 43 (Cuaderno 43) o CAMT.053 ISO 20022 por Open Banking PSD2; la validación de la continuidad de saldos conforme al Código de Comercio art. 28; la clasificación determinista por código de operación AEB (concepto común 1-99); la asignación exacta a las partidas abiertas de las cuentas 410X o 430X del PGC mediante el EndToEndId SEPA del Reglamento UE 260/2012; la conciliación de Bizum para el volumen masivo B2C vía la API de Iberpay; la gestión de las R-Transactions de adeudos AEB Norma 19 (R01 a R08 con motivos estandarizados); el pattern matching aproximado para los conceptos divergentes con Confidence Score; el mapeo de comisiones e intereses a las cuentas del PGC RD 1514/2007 conforme a la Resolución ICAC de 18/9/2013 (626 Servicios bancarios, 663/769 intereses, 668/768 diferencias de cambio); la detección automática de las operaciones del modelo 347 de la AEAT con acumulación por NIF y umbral de 3.005,06 EUR por contraparte y año según la Orden EHA/3012/2008; la identificación de las operaciones intracomunitarias para el modelo 349 mensual o trimestral; la verificación del umbral CIRBE del Banco de España de 9.000 EUR de la Circular 1/2013; el cálculo de las diferencias de cambio con el tipo oficial del BCE; la conciliación bidireccional con los asientos del PGC y los registros del SII enviados al AEAT según el RD 1624/1992 art. 62.6; el escalado humano de los movimientos sin contrapartida con contexto; y la generación del protocolo final con audit trail RGPD y plazo de conservación de 6 años del Código de Comercio art. 30.

Un escenario concreto: una empresa industrial mediana de Bilbao con 4 cuentas (BBVA, Santander, CaixaBank, Sabadell), 250 movimientos diarios, 80 millones EUR de facturación, sujeta al SII y a auditoría por la Ley 22/2015. Cada día el Agente recibe 4 extractos AEB Norma 43 y 2 CAMT.053 PSD2, valida la continuidad de saldos y clasifica 250 movimientos (145 transferencias AEB 34, 67 adeudos SDD AEB 19, 18 comisiones, 8 intereses y 12 Bizum). Reconcilia 215 por asignación exacta de EndToEndId, 27 por pattern matching con Confidence superior al 85%, 5 con Confidence del 70 al 85% para revisión de Tesorería y 3 escalados al CFO. Detecta 4 R-Transactions de adeudos (1 R04 IBAN inválido, 2 R05 cliente disputa, 1 R02 fallecimiento), marca 12 operaciones del modelo 347 de la AEAT, identifica 8 intracomunitarias para el modelo 349, calcula 3 diferencias de cambio en USD y concilia de forma bidireccional con el SII detectando 2 divergencias por error en el tipo de IVA. Tiempo total: 11 minutos frente a 4 horas de trabajo manual.

## La triple conciliación bidireccional entre banco, PGC y SII evita el requerimiento de la AEAT

Un cuadre bancario sin conciliación bidireccional contra los asientos del PGC y los registros del SII enviados al AEAT es receta para un requerimiento inmediato. La empresa registra una factura recibida de un proveedor por 24.200 EUR (20.000 de base y 4.200 de IVA al 21%) en la cuenta 410X y envía el registro A2 al SII con base 20.000 e IVA 4.200. Al pagar la factura, el banco genera un movimiento de 24.200 EUR en el extracto AEB 43 que se concilia con el asiento haber 572 Bancos / debe 410X Proveedor. Pero, por un error en el maestro del proveedor en el ERP, el A2 del SII se envió con un tipo de IVA del 10% (2.000 EUR) en lugar del 21% (4.200 EUR): la AEAT cruza los datos automáticamente, detecta una divergencia de 2.200 EUR de IVA y emite un requerimiento con plazo de 10 días y una sanción potencial del 50% conforme a la LGT art. 191 (1.100 EUR para esta operación concreta, escalable en caso de reincidencia y volumen).

Por eso la 14ª etapa de decisión es la conciliación previa obligatoria del movimiento bancario con el registro contable del PGC y con el SII ANTES de marcar la operación como cerrada. El Agente integra los XML del SII enviados al AEAT (A1 facturas emitidas, A2 facturas recibidas, A3 bienes de inversión, A4 cobros y pagos en metálico, A5 operaciones intracomunitarias) y los compara línea a línea con los asientos del PGC RD 1514/2007 generados por la conciliación. Los movimientos bancarios sin asiento contable se marcan como pendientes. Los asientos sin entrada en el SII se marcan como pendientes de envío. Los registros del SII sin movimiento bancario correspondiente se marcan como excepción. Solo cuando los tres niveles (banco AEB 43/CAMT.053, contabilidad PGC y fiscalidad SII) son perfectamente coherentes, el movimiento avanza al cierre del periodo. Esta conciliación a tres niveles es lo que permite presentar el modelo 303 de IVA mensual o trimestral con riesgo cero de divergencia.

## Casos límite españoles: R-Transactions masivas, volumen de Bizum B2C y operaciones en moneda extranjera

Casos especiales como las devoluciones de adeudos masivas, la conciliación de Bizum B2C y las operaciones en moneda extranjera parecen complejos, pero la norma española los determina por completo. Las R-Transactions de adeudos SEPA de la AEB Norma 19, con códigos R01 a R08, requieren el reverso automático del cobro original (debe en la cuenta 430X del cliente, haber en la 572 del banco) y un workflow específico según el motivo: el R04 (IBAN inválido) escala a la corrección de datos maestros, las disputas R05 y R06 escalan a Compliance o Legal por riesgo regulatorio, las cancelaciones R01, R03 y R08 requieren contacto comercial para un nuevo mandato, y el R02 (fallecimiento) dispara el workflow de herederos coordinado con Atención al Cliente. La conciliación de Bizum con volumen masivo B2C (más de 1.000 movimientos diarios en e-commerce y devoluciones) requiere un matching determinista del teléfono del cliente cruzado con el maestro, con ventana de importe y timestamp y deduplicación. Las operaciones en moneda extranjera (USD, GBP, CHF) requieren un ajuste por el tipo de cambio del día con los tipos oficiales del BCE y el reconocimiento de la pérdida o ganancia de cambio en la cuenta 668 (diferencias negativas) o 768 (positivas) conforme a la norma de valoración 11ª del PGC RD 1514/2007 y a la Resolución ICAC de 18/9/2013.

El Agente identifica cada caso límite mediante reglas determinadas y aplica el tratamiento correspondiente: las R-Transactions con reverso automático y workflow de recobro según el motivo, Bizum con matching determinista del teléfono y deduplicación temporal, la moneda extranjera con el tipo oficial del BCE y el reconocimiento de la diferencia de cambio, las operaciones superiores a 3.005,06 EUR para el modelo 347 con acumulación por NIF, las operaciones intracomunitarias para el modelo 349, la detección de concentración de riesgo CIRBE por encima de 9.000 EUR y el eventual escalado a juicio humano cuando el caso no tiene un precedente claro.

## Integración con el ecosistema español: Sage, A3, Holded, SAP, y Open Banking PSD2 de BBVA, Santander y CaixaBank

La lógica del Agente se conecta vía API con los principales sistemas contables y bancarios del mercado español: [Sage 200 y Sage Despachos Connected](https://www.sage.com/es-es/) (líder en PYME, con módulo de Tesorería y Open Banking PSD2 a más de 30 entidades), [A3 Software](https://www.a3software.com/) (a3con, a3asesor y a3ERP, para despachos, con integración AEAT y conexión bancaria AEB), [Holded](https://www.holded.com/) (cloud para autónomos y PYME con Open Banking PSD2), [Cegid Quadra](https://www.cegid.com/es/) (mediana empresa industrial con conciliación AEB 43), SAP S/4HANA Spain Localization con Cash Management, Bank Account Management y Bank Communication Management (IBEX-35), Microsoft Dynamics 365 Business Central Spain con AL extensions de Cash Management, Oracle Fusion Cloud ERP Spain Localization con Cash Management y Cash Forecasting, y ContaSimple, ContaPlus y Mastermaq España para despachos profesionales. La conexión bancaria multi-entidad opera por Open Banking PSD2 (BBVA Open Platform, Santander Open Bank API, CaixaBank Open API, Sabadell Hub, Bankinter API, ING Direct Empresas, Openbank API) o por los canales corporativos legacy (BBVA Net Cash, Santander One Pay, CaixaBank Now Empresas). Los formatos AEB Norma 43 y CAMT.053 ISO 20022 coexisten según el banco. Bizum se integra por API empresarial (BBVA Bizum Empresas, Santander Bizum Pro, CaixaBank BizumNegocios). Para grupos IBEX-35 con varias cuentas en España y filiales LATAM (Telefónica, Iberdrola, Santander, BBVA, ACS, Inditex, Repsol), el Agente coordina la conciliación centralizada con cash pooling nocional o efectivo, manteniendo el cumplimiento simultáneo de la CIRBE del Banco de España, el modelo 303/347/349 y el SII de la AEAT, el RGPD de la AEPD, la Norma AEB 19/34/43 y los reportes EMIR para los derivados de cobertura.

--- Agente Análisis Varianza Presupuestaria ---
> Agente FP&A análisis varianza plan vs. real determinista con PGC RD 1514/2007, NIIF IAS 1 + IAS 8 grupos IBEX-35, ESMA APM, CNMV DEFR profit warning, ICAC NIA-ES 540 y AEAT modelo 200.

El análisis de varianza presupuestaria de FP&A en España opera entre seis marcos regulatorios principales: el PGC RD 1514/2007 con el PGC PYMES RD 1515/2007 (Cuentas Anuales individuales de las sociedades españolas), las NIIF IAS 1 e IAS 8 (Reglamento UE 1126/2008, doble estándar de los grupos consolidados cotizados del IBEX-35), las Resoluciones ICAC de 5/3/2019 y 4/4/2024 (informe de gestión y de sostenibilidad), la LSC RDLeg 1/2010 art. 262 (informe de gestión con perspectiva razonable y factores de riesgo), las ESMA APM Guidelines 2015/1415 (conciliación de las métricas alternativas con las NIIF), la Circular 1/2008 de la CNMV (IAGC F.5) con el Código de Buen Gobierno 2020 y los Hechos Relevantes del RDL 19/2018 con el profit warning DEFR, y la CSRD de la UE (Directiva 2022/2464) con el Real Decreto 109/2025 y la ESRS E1-S4 climático-social. Cada empresa española mediana o grande (más de 100 millones EUR de facturación) debe coordinar el análisis de varianza mensual con la descomposición de drivers, el filtro de materialidad de la ICAC NIA-ES 320, la correlación con los eventos de negocio, el compliance ESMA APM, el seguimiento del EPS guidance del IBEX-35, el substantive testing de las Big-4 (ICAC NIA-ES 540) y el reporting trimestral a la Comisión de Auditoría.

## CNMV IAGC F.5, ICAC NIA-ES 540, ESMA APM Guidelines, informe de gestión de la LSC art. 262 y EPS guidance del IBEX-35: cinco frentes que exigen Cert-Ready by Design en el análisis de varianza

Toda reunión del Comité de Dirección empieza con la misma pregunta: por qué nos desviamos del plan. Según el FP&A Trends Benchmark 2025, el 46 por ciento del tiempo de trabajo de FP&A en España se destina a recopilar y validar datos, no al análisis que realmente mejora las decisiones de la Comisión de Auditoría. En el análisis de varianza presupuestaria este desequilibrio se ve con especial claridad: descomponer la desviación real en sus drivers (precio, cantidad, mix, tipo de cambio y timing) lleva minutos, mientras que obtener los datos de plan y real de los distintos sistemas ERP españoles (SAP S/4HANA, Sage 200, A3, Oracle Fusion, Cegid, Holded y Tagetik) lleva horas. La LSC RDLeg 1/2010 art. 262 obliga a las sociedades a formular un informe de gestión anual con una perspectiva razonable de la evolución futura, los factores de riesgo y la comparativa con el periodo anterior. La Resolución ICAC de 5/3/2019 detalla su contenido obligatorio. El apartado F de la Circular 1/2008 de la CNMV (Sistemas de Control de Riesgos y F.5 Liquidez) y el Código de Buen Gobierno 2020 añaden requisitos para las sociedades cotizadas del IBEX-35.

Casos célebres del IBEX-35 con un análisis de varianza fallido: Pescanova en 2013 (restatement de PricewaterhouseCoopers de 1.500 millones EUR, administradores procesados y falta de descomposición de los drivers comerciales y pesqueros), Abengoa en 2015 (salvedad de going concern de las Big-4, 19.000 millones EUR de pasivos y varianzas de capital circulante no monitorizadas), DIA en 2019 (crisis de refinanciación, recapitalización de LetterOne de Mikhail Fridman y varianzas de ventas comparables no comunicadas), Codere en 2020 (reestructuración de deuda, DEFR retrasado y varianza del EBITDA pre-IFRS-16 sin desglose), Naturgy en 2022/2023 (deterioro del fondo de comercio de 4.515 millones EUR, varianzas de LATAM no anticipadas y cambio de CEO) y Telefónica en 2023 (profit warning DEFR, caída intradía del 6% de la cotización y varianza del guidance no detectada antes). Lecciones aprendidas: descomposición de drivers ausente, alertas tempranas no accionadas, compliance ESMA APM deficiente, controles internos del SCIIF inadecuados, audit trail de substantive testing inexistente y materialidad de la NIA-ES 320 mal aplicada.

## 14 puntos decisivos deterministas con dos escalados humanos y un análisis asistido por IA

El Agente procesa el análisis de varianza presupuestaria en un pipeline de 14 puntos decisivos: once cálculos regulados, uno asistido por ML para la correlación de los drivers de los eventos de negocio, uno asistido por LLM para el borrador del comentario de gestión y dos escalados humanos (el trigger del profit warning DEFR de la CNMV y las propuestas de medidas correctoras del Comité de Dirección). Extrae los datos de plan y real en doble estándar PGC y NIIF desde SAP S/4HANA Group Reporting Spain, Tagetik Wolters Kluwer y Anaplan Spain. Concilia el plan de cuentas y mapea los centros de coste con el tratamiento de las periodificaciones y las reclasificaciones de la IAS 8. Calcula la varianza absoluta y porcentual por cuenta, centro de coste y segmento. Aplica el filtro de materialidad de la ICAC NIA-ES 320 (5% del resultado, 1% de los ingresos, 0,5% del activo total). Descompone la varianza en precio, cantidad y mix (análisis Price-Volume-Mix). Analiza la varianza por tipo de cambio (EUR, USD, GBP, BRL) para las multilatinas (IAS 21 y NRV 11 del PGC). Analiza la varianza de timing y corte de ejercicio (NRV 14 del PGC e IFRS 15). Cruza las métricas alternativas con las ESMA APM Guidelines (EBITDA ajustado, FFO, ROIC, deuda neta y EBITDA pre-IFRS-16). Y dispara el trigger del profit warning DEFR de la CNMV comparando el forecast revisado con el guidance previo.

Un ejemplo concreto: una empresa industrial española del IBEX-35 (más de 1.500 millones EUR de facturación, 8.500 empleados, con el 65% de la facturación en exportación en EUR, USD y GBP, y 15 centros de coste en Madrid, Cataluña, País Vasco y Andalucía). El Agente extrae el presupuesto aprobado por el Consejo de Administración y los datos reales mensuales de la cuenta de resultados, el balance, el EFE y la memoria en doble estándar PGC y NIIF desde SAP S/4HANA Group Reporting Spain y Tagetik. El análisis de varianza acumulado del tercer trimestre da unos ingresos de -45 millones EUR (-2,8% frente al plan de 1.620 millones EUR), descompuestos en una palanca positiva de precio de +15 millones EUR (+0,9%), una palanca negativa dominante de cantidad de -52 millones EUR (-3,2%), un mix de -18 millones EUR (-1,1%) y un FX favorable de +10 millones EUR (+0,6% por el EUR/USD). El EBITDA es de -12 millones EUR (-4,2% frente al plan de 285 millones EUR), descompuesto en la materia prima del cobre con -8 millones EUR (palanca dominante del 67%), el absentismo con +3 millones EUR (huelga de 2 semanas en el centro de Bilbao), el pricing con +5 millones EUR (renegociación efectiva del segundo trimestre) y el timing del capex con -12 millones EUR (proyecto de Andalucía adelantado). El BPA acumulado es de 0,98 EUR frente al guidance anual de 1,42 EUR (un -31% extrapolado a cierre de ejercicio, que supera el umbral del 10% del profit warning DEFR de la CNMV). En el compliance ESMA APM, el EBITDA ajustado se concilia con las NIIF, el EBITDA pre-IFRS-16 está -10 millones EUR frente al plan y el FFO, -8 millones EUR. En la materialidad de la ICAC NIA-ES 320 se aplica una global de 14 millones EUR y una de ejecución de 10 millones EUR.

## Cruce de las ESMA APM Guidelines, el CNMV IAGC F.5, el EPS guidance y el substantive testing de la ICAC NIA-ES 540

El compliance de las ESMA APM Guidelines 2015/1415 y del ESMA Q&A APM se automatiza en el análisis de varianza: el Agente genera la tabla de conciliación APM-NIIF de la varianza de cada métrica alternativa (EBITDA ajustado, FFO, ROIC, deuda neta, free cash flow, EBITDA recurrente, EBITDA pre-IFRS-16 y beneficio normalizado), un memorando que explica su definición, su uso, su magnitud y su base comparativa entre periodos previos, y el flag de cambio de metodología (que dispara el desglose de la ICAC NIA-ES 540 y la IAS 8.32-38). Los inputs del apartado F.5 de Liquidez del IAGC de la CNMV y del Código de Buen Gobierno 2020 se generan cada trimestre con la varianza frente al presupuesto y las acciones contingentes para la Comisión de Auditoría. El trigger del EPS guidance del IBEX-35 y del profit warning DEFR está automatizado: si la varianza acumulada y la extrapolación del forecast revisado proyectan un BPA a cierre inferior al 90% del guidance previo publicado (el umbral del 10% del ESMA Q&A), avisa al CFO y a la Comisión de Auditoría con los borradores del DEFR y de los Hechos Relevantes en 24 horas. El substantive testing de las Big-4 (ICAC NIA-ES 540) queda listo para auditoría con el respaldo matemático de las varianzas materiales, la descomposición de drivers, la materialidad de la NIA-ES 320, los memorandos de correlación de los eventos de negocio, el compliance ESMA APM, los controles internos del SCIIF, la firma eIDAS QSEAL FNMT-RCM, el almacenamiento WORM inmutable y la DPIA de la LOPDGDD ante la AEPD.

## Casos límite del análisis de varianza español: Price-Volume-Mix sectorial, IAS 21 en multilatinas y capex verde de la ESRS E1 de la CSRD de la UE

Casos especiales del análisis de varianza español: (1) el retail (Inditex, DIA, Mercadona), con Price-Volume-Mix y estacionalidad veraniega, Black Friday, Navidad y Reyes; (2) el manufacturing (Acerinox, ArcelorMittal, Cie Automotive), con la varianza de las materias primas del cobre y el acero y el mix de gamas; (3) la energía (Iberdrola, Naturgy, Repsol), con la varianza del brent, el gas y el CO2 del EU ETS y el clean EBITDA (pre-CCS earnings) de las ESMA APM; (4) la banca (Santander, BBVA, CaixaBank), con la varianza del margen de intereses, las comisiones, el RoTE y las provisiones ECL de la IFRS 9; (5) el telecom (Telefónica, Cellnex), con la varianza del ARPU y el EBITDA pre-IFRS-16; (6) las multilatinas (Telefónica, BBVA, Inditex, Ferrovial, ACS, Naturgy), con el aislamiento de la varianza FX (IAS 21 y NRV 11 del PGC) frente a la operativa a moneda constante y la hiperinflación de Argentina y Venezuela de la IAS 29; (7) el deterioro de la IAS 36 inducido por la varianza cuando la varianza acumulada proyecta un valor recuperable inferior al valor contable de la UGE; (8) la varianza del capex verde de la ESRS E1 de la CSRD de la UE y los activos varados del Real Decreto 109/2025; y (9) la varianza de plantilla y de la brecha salarial de la ESRS S1 (Real Decreto 902/2020 y Ley 15/2022).

## Integración con Sage 200 Performance, A3, SAP Analytics Cloud Spain, Anaplan, Tagetik y el substantive testing de las Big-4 (NIA-ES 540)

El Agente se integra vía API con los sistemas de FP&A españoles: [Sage 200 Performance](https://www.sage.com/es-es/) y Sage Despachos Variance (líder en PYME, medianas y asesorías), [A3 Software](https://www.a3software.com/) y Wolters Kluwer FP&A Spain (despachos profesionales), SAP Analytics Cloud Spain con SAP S/4HANA Group Reporting Spain y SAP BPC Spain (multinacionales IBEX-35), Oracle Hyperion Planning Spain, Oracle EPM Cloud y Oracle Fusion ERP Spain (gigantes como Telefónica, Iberdrola, BBVA y Santander), [Anaplan Spain](https://www.anaplan.com/es/) y [Workday Adaptive Planning Spain](https://www.workday.com/es-es/) (medianas cloud-native), [Tagetik Wolters Kluwer](https://www.wolterskluwer.com/es-es/solutions/cch-tagetik) y Board International Spain (CPM enterprise), [Cegid Quadra Spain](https://www.cegid.com/es/) y Holded Financial Planning, y [Jedox Spain](https://www.jedox.com/es/) y Vena Solutions Spain. La correlación de drivers de ML se hace en Python (scikit-learn, statsmodels y pandas) con la ingesta de los eventos de negocio del CRM (Salesforce y HubSpot), de producción (MES y SCADA) y de RRHH (Workday y Personio Spain). El Substantive Testing de las Big-4 españolas se apoya en la exportación directa a Deloitte ASM, PwC Halo, EY Helix y KPMG Clara con los metadatos del audit trail de la ICAC NIA-ES 540, la materialidad de la NIA-ES 320 y la NIA-ES 450, el almacenamiento WORM inmutable de 7 años, la firma eIDAS QSEAL FNMT-RCM y la DPIA de la LOPDGDD ante la AEPD. La integración con la Plataforma de Comunicaciones de Hechos Relevantes de la CNMV cubre la generación del IAGC F.5, los borradores del profit warning DEFR, la varianza del compliance ESMA APM y el borrador del comentario de gestión de la LSC art. 262 para la revisión en el [Decision Layer](/es/decision-layer/) por el CFO, la Comisión de Auditoría y el Consejo de Administración.

--- Agente de Asignación de Cobros ---
> Lee extractos bancarios (CAMT.053, MT940), asigna pagos a deudores y facturas abiertas, valida deducciones de descuento y crea asientos de compensación.

Entre el ingreso del cobro y su asignación contable a una factura abierta median, en muchas empresas, horas de trabajo manual. Los responsables cotejan extractos bancarios con partidas abiertas, revisan conceptos de transferencia, identifican pagadores divergentes y aclaran diferencias. En empresas con varios cientos de cobros diarios, este proceso consume a profesionales cualificados cuya competencia debería estar al servicio de casos complejos y de la relación con el cliente. Al mismo tiempo, cada hora sin asignación retrasa el efecto de liquidez del cobro - y deteriora el Days Sales Outstanding.

## Cada día sin asignación empeora el capital circulante

El DSO medio se sitúa, por sectores, en torno a los 57 días - a pesar de que la mayoría de las empresas pactan plazos de pago de 28 días (fuente: Kapittx, 2025). Este desfase de casi 30 días no se debe solo a clientes morosos. Una parte importante procede de retrasos internos: cobros que sí han entrado pero que aún no han sido asignados y por tanto no están contabilizados como compensación de la deuda.

Para una empresa con 50 millones de euros (aproximadamente 54 millones de USD) de facturación anual, cada día de reducción del DSO libera alrededor de 137.000 EUR (unos 148.000 USD) de capital circulante. La asignación de cobros no es, por tanto, un proceso administrativo secundario, sino una palanca directa sobre la calidad del balance.

## El 80 por ciento de las asignaciones siguen un reglamento fijo

La asignación manual sugiere una complejidad que en la mayoría de los casos no existe. Un análisis de los cobros típicos muestra que aproximadamente el 80 por ciento puede asignarse de forma inequívoca por número de factura en el concepto, importe y datos maestros del cliente. Las empresas con asignación de cobros automatizada alcanzan, según Emagia (2025), precisiones de asignación del 95 al 98 por ciento y reducen el tiempo de procesamiento manual entre un 80 y un 90 por ciento.

El punto clave: esta cuota elevada no es fruto de IA en sentido estricto. Se basa en reglas deterministas - leer extracto, cotejar referencia, verificar importe, generar asiento. El reglamento entrega resultados reproducibles y auditables. Justo eso hace que el proceso sea automatizable y auditable para la AEAT.

## Los pagadores divergentes y los pagos parciales requieren un modelo escalonado

El 20 por ciento restante es el motivo por el que una automatización completa sin arquitectura de decisión fracasa. Escenarios típicos: un grupo empresarial paga desde una oficina central cuyo nombre no coincide con el del cliente deudor. Un cliente liquida tres facturas en una transferencia agrupada, pero en una de ellas aplica descuento por pronto pago aunque el plazo haya vencido. O bien un pago queda 47 EUR por debajo del importe facturado - ¿diferencia de redondeo, deducción legítima o error?

El [Decision Layer](/es/decision-layer/) distingue estos casos mediante niveles de escalado. Nivel 1 - el reglamento - resuelve el cotejo exacto: lectura CAMT.053, matching por número de factura, verificación del plazo de descuento contra datos contractuales. Nivel 2 - matching aproximado - actúa ante pagadores divergentes, combinando cuentas bancarias de los datos maestros, patrones históricos de pago y similitudes de nombre. Solo cuando ninguno de los dos niveles entrega una asignación inequívoca, el agente escala al responsable con Human-in-the-Loop - aportando todo el contexto recabado como preparación de la decisión.

## El responsable se convierte en especialista de aclaraciones

En el mundo manual, un responsable pasa la mayor parte de su tiempo en asignaciones rutinarias que no requieren ningún juicio técnico. La verdadera experiencia - valorar el historial del cliente, interpretar el comportamiento de pago, tomar decisiones comerciales ante diferencias - queda relegada porque la masa de casos estándar domina la jornada.

Tras la introducción del agente de asignación de cobros, esta proporción se invierte por completo. El agente asume las asignaciones basadas en reglas y prepara los casos de aclaración para que el responsable pueda decidir de inmediato: qué clientes entran en consideración, qué partidas abiertas encajan con el importe, qué métodos de matching se intentaron y por qué no funcionó ninguno. El rol cambia del asignador al especialista en aclaraciones.

Para la empresa surge un doble efecto. El tiempo desde el ingreso del cobro hasta la contabilización baja de horas a minutos para los casos estándar. Y la tasa de resolución de casos problemáticos aumenta, porque los profesionales concentran su tiempo en los casos que realmente requieren criterio humano.

--- Agente de Previsión de Flujo de Caja ---
> Previsión de tesorería rolling a 13 semanas con datos AEB Norma 43, Bizum e Iberpay en tiempo real, y seguimiento de covenants conforme al PGC.

La previsión del flujo de caja en España opera entre seis marcos regulatorios principales: la NRV 9 del PGC RD 1514/2007 (Estado de Flujos de Efectivo) para las sociedades españolas, la NIIF 7 y la IAS 7 para los grupos cotizados del IBEX-35, el rolling a 13 semanas de la AFP como estándar internacional adoptado, la ICAC NIA-ES 570 con la LSC art. 363.1.e para el going concern (proyección a 12 meses y disolución cuando el patrimonio neto baja del 50%), la Ley Concursal RDLeg 1/2020 art. 5 (concurso voluntario en 2 meses) y la ESRS E1 de la CSRD de la UE, junto con la Ley 11/2018 (DNFR) y las Circulares 4/2014 y 5/2018 del Banco de España, para los desgloses del flujo de caja relacionados con el clima con los escenarios del NGFS Fase IV. Cada empresa española mediana o grande debe coordinar el forecast determinista en su horizonte táctico de 13 semanas, operativo de 52 semanas y estratégico de 5 años, junto con el stress climático, el seguimiento de los covenants de DSCR e ICR, el substantive testing de las Big-4 (ICAC NIA-ES 540), el IAGC F.5 y los Hechos Relevantes de la CNMV.

## LSC art. 363, Ley Concursal, incumplimiento de covenants, MAC y salvedad de going concern: cinco frentes que exigen Cert-Ready by Design

La LSC art. 363.1.e fija como causa de disolución de la sociedad que el patrimonio neto baje del 50% del capital social: los administradores deben acordar la disolución en 2 meses (LSC art. 367) o responden personalmente con responsabilidad solidaria. La Ley Concursal art. 5 obliga a solicitar el concurso voluntario en 2 meses desde que se conoce la insolvencia. El going concern de la ICAC NIA-ES 570 y la IAS 1.25-26 exige una proyección a 12 meses vista; una duda sustancial dispara la modificación de la opinión del auditor (párrafo de énfasis, opinión con salvedades u opinión adversa). Las Big-4 españolas (Deloitte, PwC, EY y KPMG) suelen necesitar de 60 a 80 horas de substantive testing trimestral según la NIA-ES 540. El IAGC F.5 de la CNMV obliga a divulgar la gestión de la liquidez en las sociedades cotizadas del IBEX-35.

Casos célebres: Pescanova (2013, restatement de PricewaterhouseCoopers por 1.500 millones EUR), Abengoa (2015, salvedad de going concern por las Big-4 con 19.000 millones EUR de pasivos), DIA (2019, crisis de refinanciación y recapitalización), Codere (2020, reestructuración de deuda) y Naturgy/Endesa (presiones recurrentes de liquidez en la energía). Lecciones aprendidas: las alertas tempranas del forecast de caja no se accionaron o se suprimieron, los controles internos del SCIIF eran deficientes y no existía un audit trail de substantive testing. La CIRBE del Banco de España (Circular 1/2013) obliga a reportar mensualmente las operaciones superiores a 9.000 EUR, y los bancos reciben una evaluación consolidada del riesgo crediticio.

## 15 puntos decisivos deterministas con tres escalados humanos

El Agente procesa el forecast de caja en un pipeline de 15 puntos decisivos: doce clasificaciones reguladas, un forecast de ML asistido por LLM (a 52 semanas y 5 años), una detección de anomalías y tres escalados humanos (los escenarios de stress del NGFS Fase IV, el going concern de la ICAC NIA-ES 570 con la LSC art. 363 y los escenarios de stress combinados). La agregación de Open Banking PSD2, Norma AEB 43, Bizum y SEPA SCT Inst de Iberpay en tiempo real cubre todos los bancos del grupo vía los webservices del Banco de España con certificados eIDAS QSEAL y QWAC de la FNMT-RCM. La clasificación del EFE se hace en doble estándar (NRV 9 del PGC y NIIF 7). El forecast a 13 semanas usa ARIMA con ajuste de juicio (estándar de la AFP). El de 52 semanas usa Prophet con la estacionalidad española (Semana Santa, Navidad y cierre fiscal). El estratégico a 5 años usa System Dynamics con escenarios. El motor de DSCR e ICR aplica las cláusulas de covenant de Santander, BBVA, CaixaBank, Sabadell, Bankinter, ICO y BEI, con alertas a 4 semanas vista.

Un ejemplo concreto: una empresa española mediana (250 millones EUR de facturación, 1.200 empleados, 6 bancos en el grupo). El Agente agrega el Open Banking PSD2, la Norma AEB 43, Bizum y el SEPA SCT Inst de Iberpay de las 6 cuentas en tiempo real (con un lag de 30 segundos a 2 minutos). El forecast a 13 semanas, 52 semanas y 5 años se actualiza cada semana. El DSCR proyectado para las próximas 13 semanas es de 1,38x (el covenant de Santander es de 1,30x, con un margen del 6%). El ICR es de 3,3x (el covenant es de 3,0x, con un margen del 10%). El stress test del NGFS Fase IV en su escenario Disorderly Transition reduce el DSCR a 1,19x en las semanas 10 a 13 (alerta al CFO y a la Comisión de Auditoría, con escalado humano). En el going concern, la tesorería y las líneas disponibles cubren 13 meses de operación (por encima del umbral de 12 meses). El backtesting semanal da un MAPE del 7,4% a 4 semanas y del 15,8% a 13 semanas (dentro de los umbrales de la AFP). En la verificación de la LSC art. 363.1.e, el patrimonio neto es el 65% del capital social (por encima del umbral del 50%).

## Cruce en tiempo real de Open Banking PSD2, AEB Norma 43, Bizum y SEPA SCT Inst de Iberpay

El Open Banking español (XS2A de la PSD2, según el estándar NextGenPSD2 del Berlin Group) permite consultar en tiempo real los saldos y las transacciones de cualquier banco español autorizado vía API, con certificados eIDAS QSEAL y QWAC de la FNMT-RCM. La Norma AEB 43 (Cuaderno 43 de extractos bancarios) es el estándar nacional para los retornos bancarios y la consolidación de fin de día. Bizum P2B (por encima de 1.000 EUR y obligatorio para las facturas Verifactu) se integra por webhook 24/7. El SEPA SCT Inst de Iberpay es obligatorio desde el 9/10/2025 (Reglamento UE 2024/886) para las transacciones instantáneas. El Agente agrega las cuatro fuentes en una vista consolidada: los saldos del grupo, las transacciones recientes y la identificación de las contrapartes mediante los titulares reales del SEPBLAC y el NIF activo de la AEAT. Lo cruza con el catastro de proveedores y clientes, la situación en la CIRBE del Banco de España y el cumplimiento del RGPD ante la AEPD. La detección de anomalías por ML (Isolation Forest, LSTM Autoencoder, DBSCAN y Bandas de Bollinger) usa features españolas como el EURIBOR, el IPC, el EUR/USD y la estacionalidad española.

## Integración con Sage Treasury, A3, SAP S/4HANA Spain, Kyriba y el substantive testing de las Big-4 (NIA-ES 540)

El Agente se integra vía API con los Treasury Management Systems españoles: [Sage 200 Treasury](https://www.sage.com/es-es/) y Sage Treasury Spain (líder en PYME y medianas), [A3 Software](https://www.a3software.com/) (a3con, a3asesor y a3ERP) con su Treasury Module (despachos profesionales y medianas), [Holded Treasury](https://www.holded.com/), [Cegid Quadra Spain Treasury](https://www.cegid.com/es/), SAP S/4HANA Spain Treasury con SAP Cash Management (multinacionales IBEX-35), Microsoft Dynamics 365 BC Spain Treasury, Oracle Fusion Cloud ERP Spain con Treasury Cloud, Kyriba Spain (tesorería cloud global) y GTreasury Spain. La conexión usa el Open Banking PSD2 (XS2A), la Norma AEB 43, Bizum y el SEPA SCT Inst de Iberpay con eIDAS QSEAL, QWAC y FNMT-RCM. La base de datos de series temporales es TimescaleDB e InfluxDB, y la plataforma de ML es TensorFlow, Prophet, ARIMA, LSTM Autoencoder y VAR. El Substantive Testing de las Big-4 españolas se apoya en la exportación directa a Deloitte ASM, PwC Halo, EY Helix y KPMG Clara con los metadatos del audit trail de la ICAC NIA-ES 540 y 570, el almacenamiento WORM inmutable, los sellos de tiempo de los certificados eIDAS QSEAL y QWAC, y la DPIA de la LOPDGDD ante la AEPD. La integración de los Hechos Relevantes de la CNMV se hace por la API de su Plataforma de Comunicaciones, junto con el IAGC F.5 y los desgloses del flujo de caja climático de la ESRS E1 de la CSRD de la UE.

--- Agente de Checklist de Cierre ---
> Orquesta el cierre mensual como workflow estructurado con dependencias de tareas, supervisión de plazos.

El cierre mensual no es un problema contable. Cada contabilización individual, cada conciliación y cada consolidación son manejables por separado. Lo que estira el cierre a seis, ocho o diez días laborables es la coordinación entre esos pasos - quién espera a quién, qué tarea bloquea la siguiente y dónde hay un retraso que nadie ha detectado aún. El agente de checklist de cierre resuelve exactamente este problema de orquestación. Basado en reglas, sin lógica contable propia, sin IA.

## La mayoría de los equipos financieros necesita más de una semana para el cierre

Las cifras son claras: APQC sitúa la mediana del cierre mensual intersectorial en 6,4 días. Un gran número de equipos financieros necesita de forma recurrente más de seis días laborables, solo una minoría logra el cierre en tres días o menos.

La causa rara vez radica en la complejidad de las tareas individuales. La mayoría de los equipos trabaja en el cierre todavía con checklists de Excel donde las dependencias entre tareas no están reflejadas. Una conciliación intercompañía olvidada bloquea la consolidación. Un devengo retrasado detiene la verificación de completitud. El retraso solo se hace visible cuando el plazo ya se ha incumplido.

## La orquestación supera a la automatización individual

Muchas empresas automatizan pasos individuales del cierre - conciliaciones, asientos contables, provisiones. Cada uno de estos pasos se vuelve más rápido. Sin embargo, el proceso global apenas se acorta. Porque entre las islas automatizadas quedan transferencias manuales, secuencias poco claras y tiempos de espera sin escalación.

La tendencia en las encuestas a CFO es clara: el foco se desplaza de la automatización aislada a la orquestación de procesos. Las empresas que introducen control integrado reportan mejor capital circulante, riesgos reducidos y decisiones más rápidas. La palanca decisiva no está en contabilizar más rápido, sino en eliminar el tiempo muerto entre las contabilizaciones.

Para el cierre mensual esto significa concretamente: mientras ningún sistema conozca y haga cumplir la secuencia de tareas, el cierre será tan lento como su transferencia manual más lenta.

## Diez decisiones basadas en reglas controlan todo el flujo

El [Decision Layer](/es/decision-layer/) descompone la orquestación del cierre en diez pasos de decisión - todos en nivel R (motor de reglas), sin participación de IA. Un escenario concreto hace la lógica tangible.

Viernes por la tarde, tercer día laborable del cierre. El agente verifica la cadena de dependencias: la conciliación intercompañía de la sociedad DE03 sigue en estado "abierta". La consolidación posterior no puede comenzar. El motor de reglas reconoce el bloqueo automáticamente, compara la fecha de finalización planificada con la fecha actual y clasifica la tarea como vencida. La matriz de escalación configurada se activa: primero se envía la notificación al responsable; tras cuatro horas sin cambio de estado, al responsable de contabilidad.

En paralelo, el agente rastrea el estado de todas las demás tareas. Los pasos completados liberan sus tareas dependientes sucesivas. La verificación de completitud al final compara las tareas realizadas con la lista de tareas obligatorias configurada. Si falta un paso, el cierre permanece abierto - sin excepciones, sin posibilidad de anulación manual sin motivo documentado.

Lo decisivo: el agente no contabiliza nada, no calcula nada, no valora nada. Controla exclusivamente la secuencia y la completitud. Esta clara limitación lo hace robusto y auditable.

## El protocolo de cierre surge como subproducto

Cada ciclo de cierre genera un protocolo completo - no como tarea de documentación adicional, sino como resultado automático de la orquestación. Cada cambio de estado, cada escalación, cada marca temporal se registra: quién completó qué tarea cuándo, qué dependencias se verificaron, dónde hubo retraso.

Para los auditores y la governance interna, este protocolo es la prueba de un proceso de cierre ordenado conforme al PGC (estándar contable alemán GoBD (estándar alemán de contabilidad) (estándar alemán de contabilidad)). Sin necesidad de recopilar correos electrónicos y archivos Excel a posteriori. Sin reconstrucción de memoria. El proceso de cierre se documenta a sí mismo mientras se ejecuta.

Las empresas que quieren pasar de un cierre de seis días a dos o tres no necesitan un contable más rápido. Necesitan un sistema que conozca las dependencias entre 30, 50 u 80 tareas de cierre, detecte bloqueos en tiempo real e involucre a los responsables sin demora. Exactamente eso es lo que ofrece la orquestación basada en reglas en el Decision Layer.

--- Agente Consolidación Cuentas Anuales ---
> Agente consolidación cuentas anuales determinista con NOFCAC RD 1159/2010, Código Comercio art. 42-49, NIIF 10/11/12, NIC 36 Goodwill, ICAC NIA-ES 600 y AEAT modelo 220 grupos IBEX-35.

Las cuentas anuales consolidadas en España operan entre seis marcos regulatorios principales: el NOFCAC Real Decreto 1159/2010 (Normas para la Formulación de las Cuentas Anuales Consolidadas, con el perímetro y los métodos de integración), el Código de Comercio art. 42-49 (obligación de cuentas consolidadas, dispensa y grupo de sociedades), la LSC RDLeg 1/2010 art. 42-49 (control, dependencia, grupo y presunciones), la NRV 19 del PGC RD 1514/2007 (combinaciones de negocios, fondo de comercio y PPA), las NIIF 10, 11 y 12 (estados financieros consolidados, acuerdos conjuntos e información de participaciones), la NIC 21 (efectos de las variaciones de los tipos de cambio en EUR, USD, GBP y BRL) con la NIC 27 y la NIC 28 (estados separados y asociadas) y la NIC 36 (test de deterioro anual obligatorio del fondo de comercio), la ICAC NIA-ES 600 (auditoría de grupos con auditor principal y secundarios) con la NIA-ES 540 (estimaciones contables del WACC y el value in use), el modelo 220 de la AEAT (régimen de consolidación fiscal del Capítulo VI de la Ley 27/2014 LIS, art. 55-75) y el ESEF iXBRL ante la CNMV (ESMA RTS 2019/815 para los grupos cotizados). Cada grupo español con dominante y dependientes según el Código de Comercio art. 42 debe coordinar la consolidación mensual, la conversión NIC 21, las eliminaciones de capital, deuda, ingresos y gastos, el deterioro del fondo de comercio, el modelo 220 de la AEAT, el ESEF iXBRL y la preparación para la auditoría de las Big-4 (NIA-ES 600).

## NOFCAC RD 1159/2010, Código de Comercio art. 42-49, NIIF 10/11/12, NIA-ES 600 y modelo 220 de la AEAT: cinco frentes que exigen Cert-Ready by Design

Ningún cierre anual español es más lento que la consolidación de las cuentas anuales del grupo. Un grupo IBEX-35 con 30 sociedades en doce países cierra el ejercicio coordinando los reporting packages de las dependientes, la conversión de moneda, las eliminaciones de capital, deuda, ingresos y gastos, el cálculo de las participaciones minoritarias, el deterioro del fondo de comercio, la memoria consolidada y el ESEF iXBRL. De forma manual, este proceso cuesta, según la experiencia, de ocho a diez jornadas laborales completas al mes, además del ciclo anual de deterioro del fondo de comercio de 80-120 horas con el asesoramiento de las Big-4 (NIA-ES 540).

El NOFCAC Real Decreto 1159/2010 establece reglas detalladas para formular las cuentas anuales consolidadas: el art. 22-30 trata la eliminación inversión-patrimonio, el art. 41-44 la eliminación de deudas y créditos intercompañía, el art. 45-48 la eliminación de ingresos y gastos intercompañía y el art. 49-52 la eliminación de los resultados intermedios de inventarios. El Código de Comercio art. 42-49 obliga a los grupos de sociedades con una dominante que tenga el 50% de los derechos de voto de las dependientes a presentar cuentas consolidadas; su art. 43 dispensa a los grupos pequeños cuando cumplen dos de tres parámetros (activo total inferior a 11,4 millones EUR, cifra de negocios inferior a 22,8 millones EUR y plantilla de menos de 250 empleados), aunque los grupos cotizados ante la CNMV nunca se dispensan. La NIIF 10 define el control de los estados financieros consolidados como poder, derechos variables al retorno y capacidad de afectar al retorno; la NIIF 11 trata las joint operations por integración proporcional y las joint ventures por puesta en equivalencia; y la NIIF 12, el desglose de dependientes, asociadas y entidades estructuradas. La NIC 21 obliga a convertir el balance de las filiales en moneda extranjera al tipo de cierre del BCE y el Banco de España, la cuenta de resultados al tipo medio y las diferencias en el OCI del patrimonio. La NIC 36 exige el test de deterioro anual obligatorio del fondo de comercio con la UGE, el value in use por DCF, el WACC y el análisis de sensibilidad. La ICAC NIA-ES 600 regula el auditor principal y los secundarios de los grupos, los componentes significativos y la materialidad del grupo. Y el modelo 220 del régimen de consolidación fiscal de la AEAT (Capítulo VI de la LIS Ley 27/2014, art. 55-75) cubre la base imponible consolidada, las eliminaciones fiscales, la compensación de bases imponibles negativas intra-grupo y la dominante como única declarante.

Casos célebres de consolidación en el IBEX-35: Banco Santander en 2015 (deterioro NIC 36 de 1.700 millones EUR del fondo de comercio de Brasil y México), Repsol en 2014 (deterioro de 1.200 millones EUR por la expropiación de YPF en Argentina), Inditex en 2020 (deterioro de tiendas de 308 millones EUR por la COVID-19), ACS/Hochtief en 2019 (deterioro de 460 millones EUR de CIMIC en Australia), Iberdrola/Avangrid en 2017 (adquisición en EE. UU. con un PPA de fondo de comercio de 6.000 millones EUR) y Naturgy/Unión Fenosa en 2009 (PPA de la NRV 19 con reservas ocultas en las concesiones de gas). Lecciones: perímetro mal definido, deterioro del fondo de comercio ausente, errores de hiperinflación en la NIC 21, eliminaciones intercompañía incompletas, omisiones en el modelo 220 de la AEAT e incumplimiento del ESEF iXBRL.

## 14 puntos decisivos: doce cálculos regulados, uno con ML para el deterioro del fondo de comercio y uno con escalado humano para el perímetro

El Agente procesa la consolidación de cuentas anuales en un pipeline de 14 puntos decisivos: doce cálculos regulados (NOFCAC RD 1159/2010, NIIF 10/11/12 y NIC 21), uno aumentado con clasificación por ML para el deterioro del fondo de comercio (NIC 36) y uno con escalado humano para el perímetro de consolidación y los cambios trimestrales por adquisiciones. Determina el perímetro de consolidación (Código de Comercio art. 42 y control de la NIIF 10). Verifica los reporting packages de las dependientes en doble estándar PGC y NIIF. Mapea el plan de cuentas del grupo armonizado. Convierte la moneda (NIC 21 y NRV 11 del PGC, en EUR, USD, GBP y BRL) al tipo de cierre, al tipo medio y el capital al tipo histórico. Elimina la inversión-patrimonio (NOFCAC art. 22-30) con el fondo de comercio de la primera consolidación. Elimina las deudas y créditos intercompañía (NOFCAC art. 41-44) reutilizando el Reciprocal-Match bilateral del Agente de Operaciones Vinculadas. Elimina los ingresos y gastos intercompañía (NOFCAC art. 45-48). Elimina los resultados intermedios de inventarios (NOFCAC art. 49-52) con el impuesto diferido de la NIC 12. Calcula las participaciones minoritarias (NOFCAC art. 27 y NIIF 10 párrafo 22). Registra las diferencias de conversión en el OCI (NIC 21 párrafo 39). Realiza el test de deterioro del fondo de comercio (NIC 36) con WACC, value in use por DCF y análisis de sensibilidad. Cumplimenta el modelo 220 del régimen de consolidación fiscal (Capítulo VI de la LIS). Genera las cuentas anuales consolidadas, la memoria y el ESEF iXBRL (ESMA RTS 2019/815). Y deja el audit trail para la ICAC NIA-ES 600, las Big-4 y el BORME del Registro Mercantil.

Un ejemplo concreto: una empresa industrial española del IBEX-35 (más de 1.800 millones EUR de facturación consolidada, 12.000 empleados, multilatina con 25 filiales en LATAM y la UE, con el 70% de la facturación en exportación en EUR, USD, GBP y BRL). El Agente extrae los reporting packages mensuales: 25 filiales, de las que 18 dependientes van por integración global, 4 multigrupo por integración proporcional y 3 asociadas por puesta en equivalencia. La conversión NIC 21 del cierre del tercer trimestre cubre 12 monedas extranjeras, con 145 millones EUR de diferencias de conversión del OCI acumuladas y el ajuste de hiperinflación de Argentina (IAS 29) por reexpresión de saldos. Las eliminaciones de consolidación son: 850 millones EUR de patrimonio de las dependientes en la eliminación inversión-patrimonio, 245 millones EUR de fondo de comercio positivo de la primera consolidación, 287 millones EUR de deudas y créditos intercompañía, 1.200 millones EUR de ingresos y gastos intercompañía y 18 millones EUR de resultados intermedios de inventarios. Las participaciones minoritarias son de 65 millones EUR de socios externos. El test de deterioro anual del fondo de comercio (NIC 36) cubre 7 UGE con 245 millones EUR de fondo de comercio asignado, un WACC del 8,5%, una g del 2,0%, sensibilidad de ± 100 pb y un DCF a 5 años, con un value in use de 312 millones EUR frente a un valor contable de 268 millones EUR (sin deterioro). El modelo 220 de la AEAT tiene a la dominante como única declarante, con 18 filiales adheridas, una base consolidada de 245 millones EUR, eliminaciones fiscales de 156 millones EUR y una compensación de bases imponibles negativas intra-grupo de 23 millones EUR. El ESEF iXBRL de los grupos cotizados etiqueta los estados financieros primarios y los 11 bloques de notas de la memoria.

## Cruce del NOFCAC, las NIIF 10/11/12, la NIA-ES 600, el modelo 220 de la AEAT y el substantive testing de las Big-4

El NOFCAC Real Decreto 1159/2010, el Código de Comercio art. 42-49, la LSC art. 42-49 y las NIIF 10/11/12 obligan a aplicar los métodos de consolidación según el tipo de control: la integración global (control entendido como poder, derechos variables y capacidad de afectar al retorno), la integración proporcional (control conjunto de las joint operations de la NIIF 11) y la puesta en equivalencia (influencia significativa de la NIC 28 y el 20% de los derechos de voto). El Agente automatiza la determinación del perímetro según las cuotas de participación, los acuerdos de accionistas, las presunciones del art. 42 y el control de hecho de la NIIF 10. La ICAC NIA-ES 600 regula el auditor principal y los secundarios de los grupos, los componentes significativos con materialidad superior al 15% y los procedimientos de auditoría específicos. La NIA-ES 540 cubre las estimaciones contables del deterioro del fondo de comercio, el value in use y el WACC. El modelo 220 del régimen de consolidación fiscal de la AEAT (Capítulo VI de la LIS Ley 27/2014, art. 55-75, y Reglamento del IS RD 634/2015, art. 56-66) cubre la base imponible consolidada, las eliminaciones fiscales, la compensación de bases imponibles negativas intra-grupo y la dominante como única declarante. El audit trail completo del Agente reduce la respuesta al primer requerimiento de la AEAT sobre la consolidación fiscal de 150-250 horas de las Big-4 tradicional a 30-50 horas, con la documentación contemporánea y los extractos pre-formateados. Las sanciones de la LIS art. 195 y de la LSC art. 282-283 por falta de depósito en el BORME (hasta 60.000 EUR) se evitan con el cumplimiento conforme. Y el TEAC, la Audiencia Nacional y el TJUE resuelven el recurso económico-administrativo y judicial, con la jurisprudencia vinculante de consolidación fiscal de Marks & Spencer, X Holding y Papillon.

## Casos límite de la consolidación española

Las multilatinas (Telefónica, BBVA, Iberdrola, Santander e Inditex) con la varianza FX de la NIC 21 y la hiperinflación de Argentina (IAS 29, con el INDEC); el test de deterioro anual del fondo de comercio (NIC 36) con la UGE, el value in use por DCF, el WACC y la sensibilidad; la primera consolidación con el PPA (NRV 19 del PGC e IFRS 3); las entidades estructuradas de la NIIF 10 y las joint operations de la NIIF 11; el ESEF iXBRL (ESMA RTS 2019/815); el modelo 220 de la AEAT con la dominante al 75% de los derechos de voto; los cambios trimestrales del perímetro; y el reciclaje del OCI al enajenar la dependiente (NIC 21 párrafo 48).

## Integración con SAP S/4HANA Spain, Oracle EPM, Tagetik, OneStream, Workiva, las Big-4 y el certificado digital de la ICP española ante la AEAT

El Agente se integra vía API con los sistemas multi-entidad españoles: [SAP S/4HANA Group Reporting Spain](https://www.sap.com/spain/), SAP S/4HANA Cloud, SAP BPC Spain (Business Planning and Consolidation) y SAP BO Group Reporting (multinacionales IBEX-35 como Telefónica, Iberdrola, BBVA, Santander y Repsol), [Oracle EPM Cloud Spain](https://www.oracle.com/es/), Oracle Hyperion Financial Management (HFM) y Oracle Fusion ERP Spain (gigantes de la consolidación), [Tagetik Wolters Kluwer](https://www.wolterskluwer.com/es-es/solutions/cch-tagetik) Financial Close & Consolidation y Disclosure Management (CPM enterprise de consolidación), OneStream Software Spain con su Financial Close & Consolidation y su Disclosure Management (consolidación best-in-class), [Workiva](https://www.workiva.com/es) (Wdesk, Wdata, Workiva Disclosure y Workiva ESEF iXBRL para los grupos cotizados del ESMA RTS 2019/815), IBM Cognos Controller, IBM Planning Analytics e IBM Cognos Disclosure Management, [Anaplan Spain](https://www.anaplan.com/es/) para consolidación y [Workday Adaptive Planning Spain](https://www.workday.com/es-es/) (medianas cloud-native), [BlackLine](https://www.blackline.com/es/) Account Reconciliation y BlackLine Intercompany Hub (matching intercompañía best-in-class), [Sage 200 Consolidación](https://www.sage.com/es-es/), Sage Despachos Consolidación y Sage X3 multi-entidad (medianas y grandes), [A3 Wolters Kluwer Consolidación](https://www.a3software.com/) (a3con y a3ERP para grupos PYME), [Cegid Quadra Spain](https://www.cegid.com/es/), Holded multi-entidad y Sage Intacct, y Microsoft Dynamics 365 BC y F&O multi-entidad. El motor de consolidación es Python (pandas, numpy y scikit-learn) con la clasificación por ML de los indicadores de deterioro del fondo de comercio y los tipos de cambio del BCE, el Banco de España, Reuters, Bloomberg y el IPC argentino del INDEC para la hiperinflación. El substantive testing de las Big-4 españolas se apoya en la exportación directa a Deloitte ASM, PwC Halo, EY Helix y KPMG Clara con la ICAC NIA-ES 600 de grupos, la NIA-ES 540 de estimaciones y los metadatos del audit trail. El certificado digital de la ICP española ante la AEAT (FNMT-RCM Clase 2 CA o ICP-Empresa) permite la presentación electrónica del modelo 220 del régimen de consolidación fiscal y del modelo 200 de la dominante, con almacenamiento WORM inmutable de 7 años, la DPIA de la LOPDGDD ante la AEPD y la firma eIDAS QSEAL FNMT-RCM. La plataforma de presentación electrónica de la CNMV cubre el ESEF iXBRL (ESMA RTS 2019/815), el IAGC F.5, los Hechos Relevantes y el depósito en el BORME del Registro Mercantil (Código de Comercio art. 365) para la revisión en el [Decision Layer](/es/decision-layer/) por el Director de Consolidación, el CFO y el Comité de Auditoría.

--- Agente Cumplimiento Contractual ---
> Cumplimiento contractual deterministas: LCSP 9/2017, LO 5/2010 responsabilidad penal, Ley 10/2010 PBC/FT, LOPDGDD y Ley 2/2023 denunciantes - Cert-Ready para AEPD, SEPBLAC y PIBR.

El compliance contractual en España es un sistema regulatorio complejo que combina seis áreas principales: la LCSP 9/2017 para la contratación del sector público, la Ley 10/2010 de PBC/FT para la prevención del blanqueo de capitales con la verificación del titular real en el Registro Mercantil, la Ley 15/2007 con sanciones de la CNMC de hasta el 10% de la facturación, el RGPD art. 28 y 35 para las cláusulas de encargo de tratamiento con EIPD, la Ley 2/2023 sobre canales de denuncia (transposición de la Directiva UE 2019/1937) y el cruce con Verifactu, obligatorio por fases entre 2025 y 2026 para el B2B. Cada contrato de un grupo español debe pasar el screening determinista por estas seis áreas y dejar documentado el audit trail para la AEAT, la CNMC, la AEPD y el Substantive Testing de las Big-4.

## CNMC, LO 5/2010, AEPD y SEPBLAC: cuatro frentes sancionadores que exigen Cert-Ready by Design

La CNMC es uno de los reguladores de competencia más activos de Europa. Las sanciones por infracciones del art. 1 (acuerdos restrictivos), el art. 2 (abuso de posición dominante) y el art. 8 (concentraciones no notificadas) pueden alcanzar el 10% de la facturación del año económico anterior. El registro de cláusulas abusivas de la CNMC contiene más de 5.000 cláusulas modelo no permitidas; el screening automático de cláusulas en los nuevos contratos modelo B2C es estándar para las empresas medianas y grandes. La auditoría fiscal de la AEAT de 2024 identificó la documentación de compliance de los contratos como uno de sus tres hallazgos principales, con irregularidades típicas: falta de documentación de la verificación del titular real, falta de EIPD en los contratos con tratamiento de datos personales y falta de cruce de los contratos con las facturas Verifactu.

La LO 5/2010 establece la responsabilidad penal de las personas jurídicas: los administradores responden penalmente por los delitos cometidos por los empleados, y un programa de compliance conforme a la ISO 19601 (UNE 19601) puede atenuar o excluir esa responsabilidad (art. 31 bis CP). El RGPD art. 83 impone sanciones de hasta el 4% de la facturación o 20 millones EUR por incumplir las cláusulas de encargo del art. 28 o por falta de EIPD del art. 35. La Ley 2/2023 sobre canales de denuncia sanciona con hasta 1 millón EUR las represalias contra el denunciante, además de la responsabilidad penal del art. 162 CP. La Ley 10/2010 de PBC/FT conlleva una sanción del SEPBLAC de hasta 10 millones EUR por no identificar al titular real. Estos cuatro frentes implican que una empresa española mediana (200-500 empleados, 50-200 millones EUR de facturación) tiene una exposición sancionadora potencial de 50-100 millones EUR anuales sin Cert-Ready by Design.

## 14 puntos decisivos deterministas con tres escalados humanos

El Agente procesa los contratos en un pipeline de 14 puntos decisivos estructurales: once clasificaciones reguladas, una extracción del tipo de contrato asistida por LLM y tres escalados humanos (el screening anti-cártel, el riesgo de los administradores por la LSC y la aceptación del riesgo por el Compliance Officer). La clasificación del tipo de contrato la hace el LLM extrayendo del texto la parte contratante, el valor, el sector y las relaciones de propiedad, y categorizándolo como LCSP, relevante para prevención del blanqueo, partes vinculadas o B2B estándar. Las 11 clasificaciones restantes siguen la Ley 10/2010 art. 41-42 (sanciones de la UE y la OFAC), la Ley 10/2010 art. 4 (titular real en el Registro Mercantil), el RGPD art. 28 y 35, la LCSP art. 1-7, 116-119 y 145-146, la Ley 3/2004 (plazos de pago), el cruce con Verifactu y la LSC art. 160.

Un ejemplo concreto: una empresa española mediana (350 empleados, 80 millones EUR de facturación) firma un contrato con un proveedor de servicios IT por 1,2 millones EUR anuales. El Agente lo clasifica como B2B estándar, relevante para prevención del blanqueo (por encima de 15.000 EUR) y sin partes vinculadas. El screening del titular real en el Registro Mercantil es correcto, el NIF del proveedor está activo y no aparece en listas de sanciones. Las cláusulas de encargo del RGPD art. 28 están verificadas y la EIPD ejecutada. El cruce con Verifactu queda configurado en frecuencia mensual. El registro de cláusulas abusivas de la CNMC está limpio. El plazo de pago es de 30 días (cumple la Ley 3/2004 para PYME). El audit trail para la AEAT y las Big-4 se genera automáticamente. Como el valor de 1,2 millones EUR queda por debajo del 25% del capital social, no requiere Junta General. En el anti-cártel no hay cláusulas restrictivas, así que lo acepta el Compliance Officer.

## El cruce de los contratos con Verifactu, obligatorio por fases entre 2025 y 2026

Verifactu (RD 1007/2023) entró en vigor el 1 de julio de 2025 para las grandes empresas y se extiende por fases a todas las empresas hasta el 1 de enero de 2026. Las facturas emitidas a partir de un contrato deben tener su número Verifactu, el esquema certificado por la AEAT y la referencia cruzada al contrato. El Agente valida cada mes que cada contrato genere las facturas Verifactu que le correspondan según el calendario de pagos, que los importes coincidan con el contrato (con una tolerancia del 5%), que los NIF del proveedor y del destinatario coincidan con la base de titulares reales del Registro Mercantil, y la clasificación de IVA según el art. 84.uno.2 de la LIVA (inversión del sujeto pasivo). Las discrepancias activan automáticamente una alerta de Compliance y el audit trail para la AEAT. Este cruce protege frente a las sanciones de la LGT art. 191-203 (50-150% del importe omitido) por no incluir facturas y documenta un audit trail completo para los inspectores de la AEAT.

## Integración con el ecosistema español: Sage, A3, Holded, SAP Ariba, NAVEX y las API de la AEAT y la CNMC

El Agente se integra vía API con los sistemas CLM españoles: [Sage 200 y Sage Despachos Connected](https://www.sage.com/es-es/) (líder en PYME, con módulo de compliance de contratos), Sage X3 España (mediana empresa), [A3 Software](https://www.a3software.com/) (a3con, a3asesor y a3ERP, para despachos profesionales), [Holded](https://www.holded.com/) (cloud para autónomos y PYME), [Cegid Quadra Spain](https://www.cegid.com/es/), SAP S/4HANA Spain Compliance con SAP Ariba (multinacionales IBEX-35), Microsoft Dynamics 365 Business Central Spain Compliance y Oracle Fusion Cloud ERP Spain. Plataformas de canal de denuncias: NAVEX Global (líder), Telpark (España), Sygnanet y Aequo Compliance. Se integra con las bases: la API del Registro Mercantil de titularidad real (DGSJyFP), la API del SEPBLAC (sanciones), el registro de cláusulas abusivas de la CNMC, la API de Verifactu con certificado FNMT-RCM, el VIES de la UE (operaciones intracomunitarias) y las sanciones de la UE (CFSP) y la OFAC. El Substantive Testing de las Big-4 se apoya en la exportación directa a Deloitte ASM, PwC Halo, EY Helix y KPMG Clara con los metadatos del audit trail conforme a las NIA-ES y el PCAOB AS 1215.

--- Agente de Notas de Crédito/Anulación ---
> Clasifica documentos entrantes como nota de crédito o factura rectificativa, identifica la factura de referencia.

Las notas de crédito y facturas rectificativas mal clasificadas figuran entre los hallazgos más frecuentes de IVA en las inspecciones fiscales. La causa es casi siempre la misma: los proveedores utilizan los términos de forma incorrecta, el ERP acepta la denominación sin verificar y la contabilidad registra sobre la base de una clasificación documental errónea. El agente de notas de crédito/anulación elimina este riesgo clasificando cada documento de corrección entrante por su contenido - independientemente de lo que figure en el documento.

## Las correcciones de IVA cuestan miles de millones en las inspecciones fiscales

La dimensión del problema es cuantificable. En 2024, las autoridades fiscales alemanas obtuvieron solo mediante inspecciones especiales de IVA un resultado adicional de 1.630 millones de euros (unos 1.780 millones de USD) en 63.733 inspecciones (fuente: estadísticas del BMF, publicadas en junio 2025). Eso supone una media de aproximadamente 25.600 euros por inspección. El IVA representó el 12,8 por ciento del resultado adicional total de inspecciones fiscales de 10.900 millones de euros. En España, la AEAT aplica controles igualmente rigurosos sobre las facturas rectificativas conforme a la normativa del IVA.

La confusión entre nota de crédito y factura rectificativa alimenta estas cifras. Una nota de crédito en sentido fiscal (en el derecho alemán, según el parrafo 14 de la Ley del IVA) es un documento de liquidación independiente emitido por el receptor del servicio. Una factura rectificativa corrige una factura errónea del prestador del servicio. Ambos tipos de documento tienen consecuencias jurídicas diferentes para la deducción del IVA soportado. Quien los confunde se arriesga a que Hacienda deniegue la deducción del IVA soportado - retroactivamente, con intereses.

## Los proveedores usan los términos incorrectamente - y el ERP propaga el error

El problema no comienza en la propia contabilidad. Comienza en el proveedor. En la práctica, los proveedores escriben regularmente "nota de crédito" en documentos que fiscalmente son facturas rectificativas. En muchos casos, los proveedores nunca han actualizado sus plantillas documentales.

Un escenario concreto: una empresa química recibe mensualmente unos 200 documentos de corrección de 80 proveedores. Aproximadamente el 35 por ciento de estos documentos llevan la denominación "nota de crédito", aunque su contenido corresponde a facturas rectificativas. El contable de proveedores debe verificar en cada documento individual las características de contenido, encontrar la factura de referencia y determinar el tratamiento fiscal correcto. En el procesamiento manual, la tasa de error para el tratamiento de facturas ronda el 2 por ciento (fuente: IOFM/Ardent Partners AP Benchmark Report). Para documentos de corrección que ya llegan con denominación incorrecta, la tasa es según la experiencia considerablemente mayor.

## La clasificación por contenido sustituye al título del documento

El [Decision Layer](/es/decision-layer/) resuelve este problema con una separación clara: la primera decisión - nota de crédito o factura rectificativa - es la única que utiliza asistencia de IA. El modelo de lenguaje analiza el contenido del documento, no el título. Verifica quién emitió el documento, si se corrige una factura original y qué consecuencias jurídicas se derivan del contenido.

Esta clasificación está intencionadamente ubicada en el nivel 1 del Decision Layer: asistida por IA con posibilidad de revisión humana. El auditor puede verificar cada decisión de clasificación individual, porque el agente documenta sobre la base de qué características clasificó el documento. Los seis pasos siguientes - identificar factura de referencia, validar importe, calcular corrección de IVA, crear contraasiento, asegurar vinculación conforme al PGC (estándar contable alemán GoBD (estándar alemán de contabilidad) (estándar alemán de contabilidad)) y verificar tratamiento fiscal - se ejecutan completamente basados en reglas en el nivel 2, sin participación de IA.

## La cadena de documentos se convierte en evidencia de auditoría

La conformidad con el PGC no surge solo de un sistema de archivo. Surge de la vinculación ininterrumpida de cada documento de corrección con su factura original. El agente establece esta vinculación en cada procesamiento - mediante comparación de números de referencia y, cuando el proveedor no incluye número de referencia, mediante matching difuso por importe, fecha y proveedor.

En la inspección fiscal se manifiesta la diferencia: en lugar de asignar manualmente notas de crédito y anulaciones individuales a sus documentos de origen, se dispone de un expediente de decisión completo. Para cada documento es trazable por qué se clasificó como nota de crédito o anulación, qué factura original está afectada, cómo se calculó la corrección de IVA y cómo se generó el contraasiento. Esto reduce el esfuerzo de auditoría - tanto para el propio equipo como para el inspector.

--- Agente de Amortización ---
> Determina método de amortización y vida útil de la tabla BMF, calcula importes de amortización mensuales.

Las amortizaciones figuran entre los procesos más estrictamente regulados de la contabilidad financiera. Método de amortización, vida útil, base de cálculo, asiento contable - cada paso está definido por ley, tabla oficial o derecho de opción. Aun así, la contabilidad de inmovilizado consume en la mayoría de las empresas una considerable capacidad manual. El motivo: los contables navegan entre las tablas oficiales de amortización (en Alemania, tablas BMF; en España, tablas del PGC), umbrales de activos de bajo valor y normas especiales, sin que una lógica central asegure la consistencia. Esto cambia cuando un agente basado en reglas asume toda la cadena de amortización.

## Los inspectores fiscales corrigen errores de amortización que no deberían producirse

La inspección fiscal estatal alemana obtuvo en 2024 un resultado adicional de 10.900 millones de euros (unos 11.900 millones de USD) - con solo 140.764 empresas inspeccionadas de 8,8 millones en el registro (informe mensual del BMF, noviembre 2025). Las amortizaciones son un campo de inspección estándar, porque los errores típicos se propagan por todo el cuadro de inmovilizado: vidas útiles mal asignadas, umbrales de activos de bajo valor no respetados, amortizaciones especiales para activos digitales no aplicadas.

Las fuentes de error no son lagunas de conocimiento. Surgen porque un contable, con 2.000 o 5.000 activos, no consulta para cada uno la clase de activo correcta en la tabla oficial de amortización, no compara la vida útil y no verifica el umbral de activos de bajo valor. El volumen genera errores - no la complejidad.

## Cada paso de decisión sigue un reglamento sin margen de interpretación

El [Decision Layer](/es/decision-layer/) descompone el cálculo de amortización en siete pasos. Los siete son completamente basados en reglas (cuadrante 1 - sin IA, sin criterio humano en el caso individual):

El método de amortización se deriva del registro de activos y del ejercicio del derecho de opción fiscal. La vida útil está en la tabla oficial de amortización (tablas BMF / PGC). La base de cálculo se calcula conforme al PGC a partir de los costes de adquisición o producción. El importe de amortización mensual es un cociente. El derecho a amortización especial para activos digitales es una verificación de umbral. El asiento contable sigue una lógica de contabilización fija. La verificación de activos de bajo valor compara el importe neto con el límite legal.

Ninguno de estos pasos requiere una estimación, una valoración o una ponderación. Esto convierte el proceso de amortización en el candidato ideal para la automatización en el nivel más bajo del Decision Layer.

## Un fabricante de maquinaria con 3.200 activos muestra la palanca

Un fabricante de maquinaria de tamaño medio gestiona un parque de inmovilizado de 3.200 posiciones - instalaciones de producción, hardware TI, flota de vehículos, mobiliario de oficina. Cada mes, la contabilidad de inmovilizado calcula para cada activo activo el importe de amortización y genera el asiento contable. En los nuevos altas se añade la primera valoración: determinar clase de activo, consultar tabla oficial de amortización, verificar umbral de activos de bajo valor, fijar método de amortización.

Sin agente, un contable realiza esto en el sistema ERP - activo por activo, campo por campo. Con un tiempo medio de procesamiento de tres minutos por alta nueva y 40 altas al mes, son dos horas solo de trabajo rutinario sin margen de discrecionalidad. A ello se suman las ejecuciones mensuales de amortización.

Con el agente de amortización, el sistema lee la clase de activo del registro, consulta la vida útil en la tabla oficial de amortización centralizada, calcula el importe mensual, verifica el umbral de activos de bajo valor y genera el asiento contable. Todo el proceso se ejecuta en segundos, no en minutos - y cada cálculo individual está documentado con la regla aplicada y la versión de la tabla.

## La tabla oficial de amortización se convierte en infraestructura centralizada y versionada

El verdadero valor no reside en la aceleración de contabilizaciones individuales. Reside en la infraestructura que surge en el proceso. La tabla oficial de amortización existe en la mayoría de las empresas como PDF o como tabla de datos maestros mantenida manualmente en el sistema ERP. Cuando la autoridad fiscal actualiza la tabla - como en la última revisión de la vida útil de hardware y software - alguien debe trasladar el cambio manualmente.

En el Decision Layer, la tabla oficial se convierte en un reglamento centralizado y versionado. Una actualización tiene efecto inmediato sobre todos los nuevos cálculos de amortización. La versión anterior queda documentada para los activos existentes. Y en la inspección fiscal puede trazarse para cada activo individual qué versión de la tabla estaba vigente en el momento de la primera valoración.

Esta infraestructura no la utiliza solo el agente de amortización. El agente de alta de activos, el agente de inventario y el agente de cuentas anuales acceden a la misma tabla versionada. La lógica de verificación de activos de bajo valor la reutiliza el agente de contabilización. Lo que comienza como un proceso de amortización individual se convierte en el fundamento de toda la contabilidad de inmovilizado.

## La evidencia de auditoría surge como subproducto

Para el CFO, la cuestión decisiva no es si el cálculo de amortización se ejecuta más rápido. La cuestión decisiva es si resiste la próxima inspección fiscal. Con una tasa de inspección del 29,6 por ciento para grandes empresas (BMF 2024), no es una reflexión teórica.

Un agente basado en reglas genera la evidencia de auditoría como subproducto de cada cálculo: método de amortización aplicado, versión de la tabla oficial, costes de adquisición, método de cálculo, verificación de activos de bajo valor, verificación de amortización especial. El cuadro de inmovilizado para las cuentas anuales se construye a partir de estas decisiones individuales documentadas - no a partir de una reconstrucción posterior.

--- Agente de Recobro ---
> Gestiona el recobro extrajudicial y judicial de impagos: intereses de demora de la Ley 3/2004, fichero ASNEF y proceso monitorio de la LEC.

El recobro en España es un pipeline jurídico-financiero con seis bases legales simultáneas: el Código Civil RD 24/7/1889 define la mora (art. 1100 - mora ex re sin necesidad de interpelación si hay plazo) y los intereses moratorios B2C (art. 1108), la Ley 3/2004 contra la morosidad en operaciones comerciales fija el régimen B2B (BCE+8% e indemnización fija 40 EUR art. 8), el Código de Comercio art. 63 y art. 942-950 regulan la mora mercantil y la prescripción cambiaria, la Ley General Tributaria 58/2003 y la Ley del Impuesto sobre Sociedades 27/2014 disciplinan la deducción fiscal del deterioro art. 13.1.e LIS, el RGPD UE 2016/679 art. 6.1.f y la LO 3/2018 LOPDGDD art. 20 gobiernan el tratamiento de datos en consultas ASNEF/RAI/Experian y comunicaciones al deudor, y la Ley de Enjuiciamiento Civil 1/2000 art. 812-818 articula el proceso monitorio hasta 250.000 EUR como vía rápida frente al declarativo. Cada etapa tiene plazo, base legal y formato propios - un fallo en el aviso previo LOPDGDD art. 20 basta para activar una sanción AEPD del 4% de la facturación del grupo.

## Tres frentes sancionadores: la AEPD hasta el 4% de la facturación, las multas de la ITSS por el TRLGDCU y la denegación AEAT de la deducción

La inscripción indebida en ASNEF, RAI o Experian es uno de los riesgos más infravalorados en recobro español. La AEPD aplica sanciones administrativas de hasta 20 millones EUR o el 4% de la facturación anual del grupo (RGPD art. 83.5) cuando faltan los requisitos LOPDGDD art. 20: deuda no controvertida, comunicación previa con plazo razonable, antigüedad máxima 5 años. Para una empresa española mediana con 200 millones EUR de facturación anual, una sanción base del 2% por inscripción sistemáticamente irregular suma 4 millones EUR - sin contar la indemnización por daño moral al titular afectado (jurisprudencia TS típica: 3.000-15.000 EUR por inscripción improcedente).

A esto se suman los riesgos paralelos. La ITSS y los servicios autonómicos de consumo sancionan prácticas agresivas frente al consumidor con 6.001-150.000 EUR (TRLGDCU y Ley 7/1996), e instruyen expedientes por comunicaciones nocturnas, hostigamiento o publicidad de la deuda. La AEAT puede denegar la deducción fiscal del deterioro conforme art. 13.1.e LIS si el procedimiento no cumple los requisitos formales (antigüedad >6 meses, concurso, reclamación judicial), aplicando sanción del 50-150% del importe defraudado más intereses de demora conforme art. 191-195 LGT. Para una cartera de 80 millones EUR con 1,5 millones EUR de deterioro mal documentado, la exposición fiscal alcanza 750.000-2,25 millones EUR antes de intereses, más bloqueo del certificado de estar al corriente de obligaciones tributarias que impide contratación pública (Ley 9/2017 LCSP art. 71) y financiación ICO/CDTI.

## El recobro español recorre 15 etapas determinísticas, no 8

A diferencia del modelo alemán estándar (8 etapas) o del polaco (12 etapas), el recobro español compliance-first exige 15 etapas determinísticas porque el sistema jurídico-financiero superpone seis capas regulatorias: identificación de la factura vencida (Código Civil art. 1100 - mora ex re), clasificación de aging en cinco tramos para deterioro PGC (1-30 / 31-90 / 91-180 / 181-365 / 365+ días), verificación de bloqueo contractual (incidencia abierta, abono pendiente), diferenciación B2B vs B2C (Ley 3/2004 o TRLGDCU), cálculo de intereses moratorios (BCE+8% en B2B o tipo legal CC art. 1108 en B2C), aplicación de indemnización fija 40 EUR art. 8 Ley 3/2004, requerimiento extrajudicial fehaciente (burofax o acta notarial >5.000 EUR), verificación de base legítima RGPD para fichero de solvencia, inscripción en ASNEF, RAI o Experian conforme a la LOPDGDD art. 20, cálculo del deterioro contable del PGC con su deducción del art. 13.1.e LIS, verificación de la prescripción (5 años en el CC art. 1964, 3 años en el CCom art. 942 o 4 años en la LGT art. 66), conciliación de pagos SEPA a través de la Norma AEB 43 y del Open Banking PSD2 con Bizum, decisión sobre el proceso monitorio de la LEC art. 812-818, acreditación de fehaciencia ante el juzgado mediante FacturaE/Verifactu/TicketBAI, y decisión estratégica de transformación en juicio verbal (LEC art. 437) u ordinario (LEC art. 399) tras oposición.

Un escenario concreto: industria mediana en Madrid con 12.000 facturas a cobrar abiertas, 80 millones EUR de cartera, 70% B2B (CIF-CIF regido por Ley 3/2004) y 30% B2C (venta a profesional autónomo o particular regido por TRLGDCU). Cada viernes el Agente identifica 1.800 facturas vencidas más allá de los 30 días default Ley 3/2004 art. 4, clasifica cada una en el aging correcto, separa B2B de B2C aplicando reglas distintas de intereses, verifica 110 bloqueos contractuales (incidencias abiertas), envía 420 requerimientos extrajudiciales (burofax para >5.000 EUR, email certificado para resto), envía 350 avisos previos LOPDGDD art. 20 con 15 días de antelación a la inscripción ASNEF, inscribe 240 deudores en ASNEF/Experian/RAI tras vencimiento del plazo, inicia 65 procesos monitorios en juzgados de primera instancia (LEC art. 812 con FacturaE/Verifactu como base documental), calcula deterioro PGC para 380 créditos en aging >180 días, e identifica 18 créditos próximos a prescripción (CC art. 1964 a 90 días) sinalizando para reclamación fehaciente urgente como interruptiva conforme CC art. 1973.

En el [Decision Layer](/es/decision-layer/), 14 de las 15 etapas son decisiones basadas en reglas (nivel R). La única decisión humana es la transformación del monitorio en declarativo verbal u ordinario tras oposición del deudor, porque exige valoración estratégica de costes (tasa judicial Ley 10/2012, honorarios abogado y procurador, condena en costas LEC art. 394), valor del litigio, relación cliente y probabilidad de cobro tras embargo de bienes. No hay ningún punto en la fase extrajudicial donde un gestor de cobros añada valor discrecional: cada cálculo es la aplicación del Código Civil, de la Ley 3/2004, de la LOPDGDD art. 20, del PGC junto con la LIS, o de la LEC art. 812.

## La conciliación de pagos SEPA y Bizum antes del envío evita la reclamación indebida y el daño moral

Un recobro automatizado sin conciliación previa es receta para reclamación AEPD y demanda por daño moral. El cliente paga vía SEPA Credit Transfer el jueves a las 17h45 o vía Bizum el viernes a las 9h12, el Agente envía burofax de reclamación el viernes a las 11h sin haber recibido el extracto Norma AEB 43 - el cliente recibe reclamación de cantidad ya pagada, presenta queja ante AEPD por inscripción en ASNEF de deuda inexistente, eventualmente ejercita acción de daño moral con indemnización típica TS de 5.000-20.000 EUR. La sanción AEPD por inscripción de deuda inexistente puede alcanzar 1-5 millones EUR para empresas medianas, sin contar la condena en costas si el monitorio se transforma en declarativo y el deudor obtiene sentencia absolutoria.

Por eso la 12ª etapa de decisión es conciliación previa obligatoria ANTES de cualquier escalada. El Agente integra el extracto bancario en formato Norma AEB 43 estándar (los principales bancos españoles - Santander, BBVA, CaixaBank, Sabadell, Bankinter - generan diariamente este fichero), conecta vía Open Banking PSD2 con las cuentas operativas, recibe notificaciones Bizum en tiempo real y cruza los pagos por NIF o CIF, importe y fecha de emisión de la factura. Pagos parciales se reconocen con imputación proporcional sobre principal, intereses y costes conforme CC art. 1172-1174. Solo créditos efectivamente abiertos tras conciliación completa progresan al pipeline de recobro.

## Prescripción, monitorio y deducción fiscal exigen precisión legal sin margen

Casos especiales como la prescripción cambiaria (CCom art. 942-950), el proceso monitorio (LEC art. 812-818) y la deducción fiscal del deterioro (LIS art. 13.1.e) parecen complejos pero son completamente determinados por la legislación española. Las acciones personales B2C prescriben a 5 años desde el vencimiento (CC art. 1964 tras reforma Ley 42/2015 - antes 15 años), las cambiarias en 3 años (CCom art. 942 letras de cambio, art. 945 pagarés, art. 950 cheques), las obligaciones tributarias derivadas (IVA repercutido) en 4 años (LGT art. 66). La interrupción de la prescripción se logra mediante reclamación extrajudicial fehaciente (CC art. 1973 - burofax con acuse o acta notarial), reconocimiento de deuda por el deudor (CC art. 1974), o ejercicio de acción judicial (monitorio o declarativo).

El proceso monitorio LEC art. 812 es la herramienta procesal más eficaz para deudas mercantiles documentadas: hasta 250.000 EUR sin exigencia de demanda formal, hasta 2.000 EUR sin abogado ni procurador, plazo de 20 días para que el deudor pague, se oponga o no conteste, y conversión automática en título ejecutivo (LEC art. 517) si no contesta. La tasa judicial es de 100 EUR fijos más una parte variable según la cuantía (Ley 10/2012, derogada parcialmente por el TC), muy inferior a la de un juicio declarativo. El Agente prepara automáticamente la documentación (FacturaE/Verifactu/TicketBAI con firma XAdES, contrato firmado, albaranes con sello, requerimiento previo con acuse) y la presenta al juzgado de primera instancia del domicilio del deudor vía LexNET (sistema judicial electrónico de la Administración de Justicia).

## Integración con ecosistema español: Sage, A3, Holded, ASNEF, LexNET

La lógica del Agente se conecta con los principales sistemas de gestión financiera del mercado español vía API: [Sage 200 y Sage Despachos Connected](https://www.sage.com/es-es/) (líder en PYME y despachos profesionales con módulo de Cuentas a Cobrar y aging report), [A3 Software](https://www.a3software.com/) (a3con, a3asesor y a3ERP, fuerte en despachos y mediana empresa), [Holded](https://www.holded.com/) (cloud para autónomos y PYME), [Cegid Quadra](https://www.cegid.com/es/) (mediana empresa industrial), SAP S/4HANA Spain Localization (multinacionales IBEX-35 con presencia internacional) y Microsoft Dynamics 365 Business Central Spain. La consulta y inscripción en ficheros de solvencia usa API ASNEF-Equifax, RAI (Registro de Aceptaciones Impagadas, gestionado por CECA Banca), Experian Iberia y Axesor. La conciliación bancaria usa la Norma AEB 43 (extracto de cuenta corriente estándar nacional) y el Open Banking PSD2 español para las transferencias SEPA, los adeudos SDD y Bizum en tiempo real. El proceso monitorio se presenta vía LexNET (sistema judicial electrónico nacional) con firma digital cualificada FNMT-RCM o AC Camerfirma. Para grupos IBEX-35 con filiales LATAM (Telefónica, Iberdrola, Santander, BBVA, ACS), el Agente coordina con los módulos NIIF locales de cada país y genera reportes paralelos compatibles con la IFRS 9 (Financial Instruments) para la consolidación de la matriz, manteniendo la operación local española conforme a la Ley 3/2004, la LOPDGDD y la LIS, y el reporting de la matriz bajo estándares internacionales.

--- Agente Atenciones Clientes ---
> Atenciones a clientes según Ley 27/2014 LIS art. 15: límite del 1% sobre el INCN, IVA art. 96 LIVA no deducible y validación de cuatro ojos del motivo, asistentes y restaurante antes del asiento.

Los justificantes de gastos de representación no fracasan en la inspección fiscal por importes incorrectos. Fracasan por datos obligatorios faltantes - un defecto formal que destruye toda la deducción como gasto empresarial. Con 10.900 millones de euros (unos 11.900 millones de USD) de resultado adicional en inspecciones fiscales en 2024 (fuente: informe mensual del BMF, noviembre 2025), los gastos de representación figuran entre las posiciones que los inspectores examinan sistemáticamente. Cada justificante sin datos completos es un acierto.

## Los defectos formales destruyen la deducción completa como gasto empresarial

La aritmética es sencilla: 70 por ciento deducible y 30 por ciento no deducible (en el derecho fiscal alemán, conforme al artículo 4.5.2 de la Ley del Impuesto sobre la Renta; en España aplican reglas análogas del IRPF y del IS). Nadie fracasa por eso. El problema reside en los cinco datos obligatorios: lugar, fecha, participantes, motivo comercial e importe. Si falta uno de ellos, Hacienda no elimina el 30 por ciento - elimina todo. Lugar y fecha figuran en el ticket del restaurante. En participantes y motivo se vuelve crítico. En la práctica, lo que más falta es una lista completa de participantes o el motivo comercial está formulado de forma tan vaga - "comida de negocios" sin más detalle - que fiscalmente no se reconoce.

Un escenario concreto: un director comercial invita a cuatro clientes tras una presentación de producto. La factura de 480 euros (unos 525 USD) es correcta, el restaurante tiene todos los datos en el ticket de caja. Pero en el justificante de representación, bajo motivo solo figura "reunión con cliente" y en participantes falta un nombre. En una inspección fiscal tres años después, 480 euros de gasto empresarial son tachados - no porque el importe fuera desproporcionado, sino porque dos líneas estaban incompletas.

## Las autoridades fiscales endurecen los requisitos de documentación

La administración tributaria ha ido precisando las obligaciones de prueba para gastos de representación. Los restaurantes con sistema electrónico de caja deben emitir tickets generados automáticamente y asegurados mediante un dispositivo técnico de seguridad certificado. Los recibos manuscritos o impresiones simples sin identificación del sistema de caja ya no se aceptan. Para las empresas esto significa: incluso un justificante de representación correcto en contenido puede fracasar si el ticket subyacente del restaurante no cumple los nuevos requisitos formales. Un ticket conforme se reconoce por el número de transacción, el número de serie del sistema de caja o un código QR impreso.

## Nueve pasos de decisión entre justificante y asiento contable

El [Decision Layer](/es/decision-layer/) descompone la verificación de justificantes de representación en nueve pasos con asignación clara: ¿quién decide - motor de reglas, IA o humano?

La clasificación del justificante reconoce por LLM si se trata de un gasto de representación. Después, el motor de reglas verifica determinísticamente los cinco datos obligatorios y la completitud de la lista de participantes. Son preguntas binarias - presente o no presente. Aquí no hay margen de discrecionalidad ni motivo para intervención humana.

La plausibilidad del motivo comercial la evalúa un LLM. "Reunión de proyecto digitalización logística con empresa X" es comprensible. "Comida" no lo es. El modelo reconoce patrones y solicita al emisor que complete la información cuando los datos son insuficientes - antes de que el justificante llegue a contabilidad.

La deducibilidad (reparto 70/30), la deducción del IVA soportado y la contabilización se ejecutan por reglas. El archivo conforme a los principios contables alemanes (GoBD), con marca temporal, cierra el proceso. Los nueve pasos quedan documentados y son trazables para una inspección fiscal posterior.

## La proporcionalidad sigue siendo una decisión humana

Un paso de decisión no lo asume deliberadamente ningún algoritmo: la verificación de proporcionalidad. Si 120 euros por persona en una comida de negocios con tres clientes es proporcionado depende del sector, el contexto y la relación comercial. Una cena en el marco de una negociación contractual sigue estándares diferentes a un almuerzo tras una primera reunión. El agente proporciona al decisor los hechos - importe por persona, comparación con valores históricos, relación con el volumen de negocio. La aprobación o la escalación la decide el humano.

Esta delimitación no es un déficit técnico. Es governance. Un agente de gastos de representación que juzgara autónomamente la proporcionalidad automatizaría decisiones discrecionales que, en caso de duda, un inspector fiscal cuestionaría. La responsabilidad permanece donde corresponde.

--- Agente de Reporting ESG ---
> Recopila los datapoints ESRS, calcula las emisiones de Alcance 1, 2 y 3 y prepara el informe DNFR conforme a la CSRD y la Ley 11/2018.

El reporting de sostenibilidad en España se encuadra en un marco regulatorio de seis áreas convergentes: el Real Decreto-Ley 6/2024 de transposición de la CSRD (Directiva UE 2022/2464), con un escalonamiento entre 2024 y 2028; la Ley 11/2018 de información no financiera, con una sanción de hasta 600.000 euros; la Ley 7/2021 de Cambio Climático y Transición Energética, con obligaciones de huella de carbono y planes de adaptación; la NIA-ES 540 del ICAC sobre las estimaciones contables de sostenibilidad, junto con las ISAE 3000 (aseguramiento limitado) y 3410 (emisiones); el Código de Buen Gobierno de la CNMV de 2024, con las Recomendaciones G1-G3 sobre ESG para las cotizadas, los Hechos Relevantes ESG y una sanción de 30.000 a 600.000 euros (LMV art. 295); y las Circulares 4/2014 y 5/2018 del Banco de España sobre el riesgo climático de las entidades de crédito y el Pilar 3 ESG de la SFDR. Una sociedad cotizada del Mercado Continuo (1.500 empleados, 250 millones de euros de facturación) tiene una exposición sancionadora potencial de entre 8 y 15 millones de euros anuales sin un ESG integrado certificable desde el diseño, según los datos consolidados de la encuesta ESG de PwC de 2024, las memorias de la CNMV y el ICAC y el Plan de la AEAT de 2025.

## La CSRD, la Ley 11/2018, el RDL 6/2024, los ESRS, la CNMV y el ICAC: seis frentes regulatorios que exigen un sistema certificable desde el diseño

El RDL 6/2024 transpone la Directiva CSRD (UE 2022/2464) con un escalonamiento entre 2024 y 2028: las cotizadas grandes de interés público en el ejercicio 2024, con su primer reporte en 2025; las grandes no cotizadas en el ejercicio 2025; las PYME cotizadas del Mercado Continuo, AIM y Latibex en el ejercicio 2026; y las filiales de terceros países en el ejercicio 2028. El ESRS Set 1 (Reglamento UE 2023/2772) incluye 12 estándares (los generales ESRS 1 y 2, los ambientales E1-E5, los sociales S1-S4 y el de gobernanza G1) con 1.144 datapoints obligatorios y voluntarios y la doble materialidad obligatoria. El incumplimiento del RDL 6/2024 y la Ley 11/2018 (art. 50) se sanciona con hasta 600.000 euros, con responsabilidad de los administradores (LSC art. 236-241).

La Ley 7/2021 de Cambio Climático obliga a reducir las emisiones, calcular la huella de carbono (ISO 14064-1), elaborar planes de adaptación y presentar un reporte anual al MITECO. La Taxonomía del Reglamento UE 2020/852 abarca seis objetivos ambientales con la contribución sustancial, el DNSH y las garantías mínimas. El Código de Buen Gobierno de la CNMV de 2024 establece la Recomendación G1 (Comité de Sostenibilidad), la G2 (política de sostenibilidad) y la G3 (reporting alineado con los ESRS). La NIA-ES 540 del ICAC, junto con la ISAE 3000 (aseguramiento limitado) y la ISAE 3410 (inventario de emisiones), tiene la perspectiva del aseguramiento razonable en 2028. Y las Circulares 4/2014 y 5/2018 del Banco de España cubren el riesgo climático, el ICAAP ESG y el Pilar 3 de la SFDR.

El greenwashing en la asignación de la Taxonomía o una materialidad falsa se sanciona con entre 30.000 y 600.000 euros (CNMV, LMV art. 295), con un posible delito de información engañosa (CP art. 282) de hasta 6 años de prisión y la responsabilidad solidaria de los administradores (LSC art. 236). Las sentencias del Tribunal Supremo de 2024 (STS 234/2024) confirmaron esa responsabilidad solidaria. La exposición total de una sociedad cotizada del Mercado Continuo (1.500 empleados, 250 millones de euros de facturación) puede acumular entre 8 y 15 millones de euros anuales sin un ESG certificable desde el diseño.

## 15 puntos decisivos con cuatro escalados humanos en el [Decision Layer](/es/decision-layer/)

El agente procesa el reporting ESG mediante una secuencia de 15 puntos decisivos: nueve automatizaciones reglamentadas, dos clasificaciones por aprendizaje automático y cuatro escalados humanos (la doble materialidad del ESRS 1, la asignación de la Taxonomía de la UE, el reporte a la Comisión de Auditoría y la aprobación del Consejo de Administración). La clasificación de la entidad obligada por la CSRD o la información no financiera determina el marco aplicable. Los demás puntos siguen el ESRS Set 1 (Reglamento UE 2023/2772), la evaluación de materialidad EFRAG IG1, el GHG Protocol, la ISO 14064-1 y la Taxonomía de la UE (Reglamento 2020/852).

Un ejemplo concreto: una empresa industrial cotizada del Mercado Continuo (1.200 empleados, 220 millones de euros de facturación) integra Sage Sustainability, a3sustainability y Workiva Carbon. El agente la clasifica como cotizada grande de interés público del RDL 6/2024, entidad obligada por la información no financiera de la Ley 11/2018 y sujeta a la huella de carbono de la Ley 7/2021. La recopilación de datapoints ESRS identifica 847 datapoints aplicables según el resultado de la doble materialidad (de los 1.144 totales). El cálculo determinista de los Alcances 1 y 2 según el GHG Protocol y la ISO 14064-1 arroja 12.450 toneladas de CO2 equivalente en el Alcance 1 y 8.230 en el Alcance 2 (location-based). La estimación del Alcance 3 en sus quince categorías da 78.500 toneladas, con un 35% de datos primarios (la categoría 1 de bienes adquiridos y la 4 de transporte upstream) y un 65% secundarios (DEFRA y ecoinvent v3.10). La asignación de la Taxonomía de la UE muestra un 18% de la cifra de negocios alineada (mitigación del cambio climático), un 22% de CapEx y un 15% de OpEx. El etiquetado XBRL se realiza en la Taxonomía ESRS Digital de EFRAG y el ESEF. El cruce del Estado de Información de Sostenibilidad con los estados financieros confirma que los costes de energía (4,2 millones de euros) coinciden con el consumo del sistema de gestión de energía. Y el proceso culmina con el reporte a la Comisión de Auditoría, la aprobación del Consejo de Administración y la atestación de los administradores (LSC art. 540).

## Cálculo de los Alcances 1, 2 y 3 con el GHG Protocol y la ISO 14064-1 y los factores del MITECO, el IDAE y la AEMET

Los estándares GHG Protocol Corporate y Corporate Value Chain establecen la metodología del inventario de emisiones. El Alcance 1 son las emisiones directas (combustión fija en calderas, móvil en la flota, fugitiva de refrigerantes HFC, de procesos industriales y del uso del suelo) con los factores del Inventario Nacional de Emisiones del MITECO, el IPCC AR6 y el Reglamento UE 517/2014 sobre gases fluorados. El Alcance 2 son las emisiones indirectas de la energía comprada, con un factor eléctrico de España en 2024 de 155 g de CO2 equivalente por kWh (según el mix de Red Eléctrica) en el enfoque location-based, y con garantías de origen RECS y PPA verdes en el market-based. El Alcance 3 abarca quince categorías upstream y downstream con una jerarquía de datos primarios de los proveedores y secundarios (DEFRA del Reino Unido, ecoinvent v3.10, EPA e IPCC). La ISO 14064-1:2018 es obligatoria para las empresas que reportan bajo la Ley 7/2021 y el RD 165/2014 de huella de carbono de la organización y del producto. El ESRS E1-6 exige las métricas absolutas y el E1-7 la intensidad de emisiones (toneladas de CO2 equivalente por millón de euros de cifra de negocios y por empleado). El agente automatiza la integración por API de los factores del MITECO, el IDAE y la AEMET, los límites del inventario y la cuantificación de la incertidumbre (ISO 14064-3).

## La doble materialidad del ESRS 1, EFRAG IG1 y la Taxonomía de la UE permanecen humanas

La doble materialidad (ESRS 1, párrafos 25-49, y la guía de implementación EFRAG IG1) obliga a evaluar cada tema ESG desde dos perspectivas: la materialidad financiera (el impacto sobre la empresa, ya que el cambio climático afecta al EBITDA, al valor de los activos, al CapEx y a la reputación) y la materialidad de impacto (cómo afecta la empresa al medioambiente y a la sociedad, con las emisiones de gases de efecto invernadero, la biodiversidad, las comunidades, la plantilla y la cadena de suministro). La metodología de EFRAG comprende: entender el contexto, identificar una lista larga de temas, evaluarlos por la puntuación del riesgo y la oportunidad según su severidad y probabilidad, determinar el umbral de materialidad y reportar de forma transparente. La participación de los grupos de interés es obligatoria (Pacto Mundial de la ONU en España, Comisión de RSC de AECA y Foro de Empresas IBEX 35 ESG).

La asignación de la Taxonomía de la UE (Reglamento 2020/852) es una decisión interpretativa sobre el CapEx, el OpEx y la cifra de negocios: cada actividad se evalúa por su contribución sustancial, por el DNSH a los cinco objetivos restantes y por las garantías mínimas (líneas directrices de la OCDE para multinacionales, principios rectores de la ONU y convenios fundamentales de la OIT). Lo regulan el Acto Delegado Climático (Reglamento Delegado UE 2021/2139) y el Acto Delegado Medioambiental (2023/2486). Los errores en la asignación constituyen greenwashing y se sancionan con entre 30.000 y 600.000 euros (CNMV, LMV art. 295), con un posible delito (CP art. 282) y responsabilidad de los administradores (LSC art. 236). El agente estructura el proceso, recopila los datos y prepara los cuadros de mando de los grupos de interés; la evaluación humana del CFO, el CSO y la Comisión de Auditoría es obligatoria, con la verificación del auditor (ISAE 3000).

## Integración con el ecosistema español: Sage Sustainability, A3, SAP Sustainability, Workiva y las API del MITECO, el ICAC y la CNMV

El agente se integra con los sistemas GRC y ERP españoles vía API: [Sage Sustainability](https://www.sage.com/es-es/) con los módulos ESG de Sage X3 y de huella de carbono de Sage 200, [A3 Software](https://www.a3software.com/) (a3con, a3asesor y a3ERP de Wolters Kluwer Spain) con el módulo a3sustainability para los ESRS, la información no financiera y la Taxonomía, SAP S/4HANA Spain Localization con SAP Sustainability Control Tower, Green Ledger y Environment Management (multinacionales del IBEX-35), Oracle Fusion Cloud ERP Spain con Oracle Sustainability Performance, ESG Reporting y Risk Management Cloud, Microsoft Dynamics 365 Business Central Spain con Microsoft Sustainability Manager, Cloud for Sustainability y Power BI ESG, y [Cegid Quadra Spain](https://www.cegid.com/es/) con [Holded](https://www.holded.com/) y el módulo ESG de Factorial. Entre las plataformas ESG dedicadas figuran Workiva Wdesk y Carbon, AuditBoard ESG, Persefoni Climate, Sphera Sustainability, Plan A, Watershed, Greenly y ClimatePartner. La integración con las administraciones cubre el MITECO (Inventario Nacional de Emisiones, huella de carbono del RD 165/2014 y Plan Nacional de Adaptación), el IDAE (factores de emisión de España, auditorías energéticas y certificados de eficiencia), la AEMET (datos climatológicos y escenarios de cambio climático de España), la CNMV (Código de Buen Gobierno de 2024, Hechos Relevantes ESG y sección F del IAGC sobre el SCIIF), el ICAC (supervisión de la NIA-ES 540 y verificadores de las ISAE 3000 y 3410), la AEAT (Plan ESG 2024, modelo 232 de paraísos fiscales y IVA reducido para renovables), la AEPD (registro de actividades de tratamiento y evaluación de impacto del perfilado de la huella de carbono de los empleados, LOPDGDD art. 22) y el Banco de España (Circulares 4/2014 y 5/2018 de las entidades de crédito, ICAAP ESG y Pilar 3 de la SFDR). Las pruebas sustantivas de las Big Four bajo la NIA-ES 540 y el aseguramiento limitado de la ISAE 3000 se soportan mediante exportación directa a [Deloitte ASM](https://www.deloitte.com/), [PwC Halo](https://www.pwc.com/), [EY Helix](https://www.ey.com/) y [KPMG Clara](https://www.kpmg.com/), con metadatos de rastro de auditoría de las NIA-ES, las ISAE y el ROAC del ICAC. El etiquetado XBRL se realiza en la Taxonomía ESRS Digital de EFRAG y el ESEF (Reglamento UE 2019/815) con firma electrónica de certificado FNMT-RCM ICP-España.

--- Agente Previsión Financiera FP&A ---
> Agente FP&A previsión financiera rolling forecast 18-meses determinista con PGC RD 1514/2007, NIIF IAS 1 + IAS 8 IBEX-35, ESMA APM, CNMV DEFR, ICAC NIA-ES 540 y AEAT modelo 200.

La previsión financiera FP&A en España opera entre seis marcos regulatorios principales: el PGC (RD 1514/2007) y el PGC de PYMES (RD 1515/2007) para las cuentas individuales; las NIIF (IAS 1, IAS 8 e IAS 36, del Reglamento UE 1126/2008) en doble estándar para los grupos consolidados cotizados del IBEX-35; las Resoluciones del ICAC de 5/3/2019 y 4/4/2024 sobre el informe de gestión y de sostenibilidad; el art. 262 de la LSC (RDLeg 1/2010), que exige el informe de gestión con una perspectiva razonable y los factores de riesgo; las Directrices ESMA APM 2015/1415 sobre la conciliación de las medidas alternativas con las NIIF; la Circular 1/2008 de la CNMV sobre el IAGC, junto con el Código de Buen Gobierno de 2020, los Hechos Relevantes (RDL 19/2018) y el profit warning DEFR; y la Directiva CSRD (UE 2022/2464) con el Real Decreto 109/2025 y los ESRS E1-S4 climático-sociales. Cada empresa española mediana o grande (más de 100 millones de euros de facturación) debe coordinar un forecast determinista - rolling a 18 meses, plan estratégico a 5 años, escenarios best, base y worst, sensibilidad multifactor y guidance de BPA del IBEX-35 - , la estimación fiscal de los modelos 200 y 220 de la AEAT, las pruebas sustantivas de las Big Four bajo la NIA-ES 540 del ICAC y el reporte trimestral a la Comisión de Auditoría.

## El IAGC de la CNMV, la NIA-ES 540 del ICAC, las Directrices ESMA APM, el informe de gestión del art. 262 de la LSC y el guidance de BPA del IBEX-35: cinco frentes que exigen un FP&A certificable desde el diseño

El art. 262 de la LSC (RDLeg 1/2010) obliga a las sociedades a formular un informe de gestión anual con una perspectiva razonable de la evolución futura del negocio, los factores de riesgo y los objetivos de las políticas de gestión del riesgo financiero. La Resolución del ICAC de 5/3/2019 detalla su contenido obligatorio y la de 4/4/2024 añade el informe de sostenibilidad en transposición de la CSRD. La Circular 1/2008 de la CNMV (sección F del IAGC: sistemas de control de riesgos y F.5 de liquidez) y el Código de Buen Gobierno de 2020 añaden requisitos para las sociedades cotizadas del IBEX-35. Las Directrices ESMA APM 2015/1415 obligan a conciliar las medidas alternativas (EBITDA ajustado, FFO, ROIC y deuda neta) con las métricas NIIF y a explicar su uso, magnitud y base comparativa. Los Hechos Relevantes de la CNMV (RDL 19/2018) y el art. 17 del Reglamento de Abuso de Mercado obligan a un profit warning DEFR en 24 horas si la desviación del guidance de BPA, EBITDA o ingresos supera el 10%. Las Big Four españolas (Deloitte, PwC, EY y KPMG) dedican habitualmente 60-80 horas de pruebas sustantivas trimestrales a la NIA-ES 540 del ICAC y a la nueva NIA-ES de Sostenibilidad, obligatoria desde 2026.

Hay casos célebres en el IBEX-35 con un forecast fallido: Pescanova en 2013 (reexpresión de Pricewaterhouse de 1.500 millones de euros y administradores procesados), Abengoa en 2015 (salvedad de las Big Four sobre la empresa en funcionamiento, 19.000 millones de pasivos y concurso voluntario), DIA en 2019 (crisis de refinanciación, recapitalización y entrada de LetterOne de Mikhail Fridman), Codere en 2020 (reestructuración de deuda y DEFR retrasado), Naturgy en 2022/2023 (deterioro del fondo de comercio de 4.515 millones y cambio de CEO) y Telefónica en 2023 (profit warning DEFR con una caída intradía del 6% en cotización). Las lecciones aprendidas son comunes: hipótesis del forecast no documentadas, alertas tempranas no accionadas, cumplimiento ESMA APM deficiente, controles internos del SCIIF inadecuados y un rastro de auditoría para las pruebas sustantivas inexistente. Las Circulares 4/2014 y 5/2018 del Banco de España obligan a las entidades de crédito a un stress testing trimestral y a un ICAAP/ILAAP anual, y la AIReF (Autoridad Independiente de Responsabilidad Fiscal) supervisa los forecasts del sector público.

## Quince puntos decisivos deterministas con tres escalados humanos

El agente procesa el forecast financiero mediante una secuencia de 15 puntos decisivos: doce cálculos regulados, uno basado en aprendizaje automático para el plan estratégico a 5 años, otro para la sensibilidad de Monte Carlo y tres escalados humanos (la definición de hipótesis de las Directrices ESMA APM, el disparador del profit warning DEFR ante la CNMV y el forecast climático de la CSRD, ESRS E1-S4). Extrae 36-60 meses de datos históricos en doble estándar PGC y NIIF desde SAP S/4HANA Group Reporting Spain, Oracle Hyperion y Tagetik de Wolters Kluwer. Valida la calidad de los datos y detecta outliers bajo la NIA-ES 540 del ICAC (más de 3 desviaciones estándar exigen un override de la dirección). Modela la estacionalidad española (Semana Santa, Navidad, Reyes, agosto, cierre fiscal y festivos autonómicos), proyecta el rolling forecast a 18 meses con Prophet, ARIMA y ETS, y el plan estratégico a 5 años con System Dynamics y escenarios. Calcula los escenarios best, base y worst con un stress test combinado, la sensibilidad multifactor de las variables macro españolas mediante una simulación de Monte Carlo de 10.000 iteraciones, el guidance de BPA del IBEX-35 frente al consenso de analistas de FactSet, Bloomberg y Reuters, el test de deterioro de la IAS 36 a partir del forecast y el tipo efectivo fiscal de la LIS para los modelos 200 y 220 de la AEAT.

Un ejemplo concreto: una empresa industrial española del IBEX-35 (más de 1.500 millones de euros de facturación, 8.500 empleados, con un 65% de la facturación exportada en euros, dólares y libras). El agente extrae 60 meses de datos históricos de la cuenta de resultados, el balance, el estado de flujos de efectivo y la memoria en doble estándar PGC y NIIF a través de SAP S/4HANA Group Reporting Spain. El rolling forecast a 18 meses, actualizado mensualmente, proyecta unos ingresos base de 1.620 millones de euros (1.750 en el best, 1.490 en el worst), un EBITDA base de 285 millones (320 best, 240 worst) y un BPA base de 1,42 euros (1,68 best, 1,15 worst). La sensibilidad multifactor muestra que una variación del 10% en el tipo EUR/USD impacta el BPA en 0,18 euros (la palanca dominante, con un 12,7%), una del 15% en el cobre lo hace en 0,11 euros, una de 100 puntos básicos en el EURIBOR en 0,06 euros (deuda variable del 35%) y una del 2% en el IPC español en 0,04 euros. El consenso de analistas es de 1,38 euros en FactSet, 1,41 en Bloomberg y 1,40 en Reuters (un margen del 9%, dentro del umbral seguro del DEFR de la CNMV). El guidance de BPA se mantiene en 1,35-1,45 euros. El test de deterioro de la IAS 36 sobre la unidad generadora de efectivo de Latinoamérica arroja un valor recuperable de 285 millones de euros frente a un valor contable de 240 (sin deterioro). El tipo efectivo fiscal forecast de la LIS es del 23,4% (consolidación fiscal del modelo 220). El backtesting da un MAPE del 3,2% a 1 mes, del 6,8% a 3 meses y del 14,5% a 12 meses (dentro de los umbrales AFP).

## Cruce de las Directrices ESMA APM, el IAGC de la CNMV, el guidance de BPA y las pruebas sustantivas de la NIA-ES 540 del ICAC

El agente automatiza el cumplimiento de las Directrices ESMA APM 2015/1415 y su documento de preguntas: genera la tabla de conciliación entre cada medida alternativa (EBITDA ajustado, FFO, ROIC, deuda neta, flujo de caja libre, EBITDA recurrente, EBITDA pre-IFRS-16 y beneficio normalizado) y las NIIF, con un memorando que explica su definición, razón de uso, magnitud y base comparativa con los periodos previos, además de la marca de cambio de metodología (que dispara la revelación bajo la NIA-ES 540 del ICAC y los párrafos 32-38 de la IAS 8). Los inputs del apartado F.5 de liquidez del IAGC de la CNMV y del Código de Buen Gobierno de 2020 se generan trimestralmente con tres escenarios y sus acciones contingentes. El disparador automatizado del guidance de BPA del IBEX-35 y del profit warning DEFR funciona así: si el BPA del forecast actualizado cae por debajo del 90% del guidance previo publicado (umbral del 10% del documento de preguntas de la ESMA), alerta al CFO y a la Comisión de Auditoría y prepara los borradores del DEFR y de los Hechos Relevantes en 24 horas. La preparación para las pruebas sustantivas de la NIA-ES 540 del ICAC ante las Big Four incluye el soporte matemático de las hipótesis, el backtesting de más de 36 meses, la sensibilidad de uno y varios factores, los memorandos justificativos, el cumplimiento ESMA APM, los controles internos del SCIIF, el sello cualificado eIDAS de la FNMT-RCM, el almacenamiento inmutable WORM y la evaluación de impacto ante la AEPD.

## Edge-cases forecast espanol: combinacion negocios IFRS 3, IAS 36 deterioro CGU, LIS consolidacion fiscal, EU CSRD climatico

Hay varios casos especiales en el forecasting español. El primero son las combinaciones de negocios (IFRS 3 y NRV 19 del PGC), con la asignación del precio de compra, el fondo de comercio identificable, los intangibles separables (relaciones con clientes, tecnología y marcas) y los earn-outs contingentes. El segundo es el test de deterioro de la unidad generadora de efectivo (IAS 36) a partir del forecast, con el WACC, la tasa de crecimiento a perpetuidad y la sensibilidad cuando la capitalización bursátil cae por debajo del valor contable del patrimonio. El tercero es el forecast del tipo efectivo fiscal de la LIS (Ley 27/2014) en los modelos 200 individual y 220 de consolidación fiscal de grupos, con las bases imponibles negativas, las deducciones por I+D+i, las bonificaciones sectoriales, las reglas antielusivas y el impuesto mínimo del 15% del Pilar Dos (Directiva UE 2022/2523, transpuesta por el Real Decreto-ley 4/2024). El cuarto son los arrendamientos por derecho de uso (IFRS 16 y NRV 8 del PGC), con el forecast de pasivos y activos y el impacto del EBITDA antes y después de la IFRS 16 en la revelación ESMA APM. El quinto es la cobertura de instrumentos financieros (IFRS 9 y NRV 9), con el forecast del valor razonable de forwards, swaps y opciones y la ineficacia de las coberturas. El sexto es el reconocimiento de ingresos (IFRS 15 y NRV 14), con el forecast por obligación de desempeño, la contraprestación variable, el componente de financiación y los activos y pasivos contractuales. El séptimo es el plan de transición de la CSRD (ESRS E1), con la inversión verde, la cuantificación de los activos varados y los escenarios NGFS Phase IV obligatorios (Real Decreto 109/2025 y Ley 11/2018). Y el octavo es el forecast de plantilla del ESRS S1, con la diversidad y la brecha salarial (Real Decreto 902/2020, Ley 15/2022 de igualdad efectiva entre mujeres y hombres y empresas de trabajo temporal).

## Integración con Sage 200 Performance, A3, SAP Analytics Cloud Spain, Anaplan, Workday Adaptive y las Big Four bajo la NIA-ES 540

El agente se integra con los sistemas FP&A españoles vía API: [Sage 200 Performance](https://www.sage.com/es-es/) y Sage Despachos Forecasting (líder en PYME, medianas y asesorías), [A3 Software](https://www.a3software.com/) (a3con y a3ERP) con Wolters Kluwer FP&A Spain (despachos profesionales y medianas), SAP Analytics Cloud Spain con SAP S/4HANA Group Reporting Spain y SAP BPC Spain (multinacionales del IBEX-35), Oracle Hyperion Planning Spain con Oracle EPM Cloud y Oracle Fusion ERP Spain (gigantes como Telefónica, Iberdrola, BBVA y Santander), [Anaplan Spain](https://www.anaplan.com/es/) y [Workday Adaptive Planning Spain](https://www.workday.com/es-es/) (PYME y medianas nativas en la nube), IBM Planning Analytics Spain con Cognos Controller (banca y seguros), Microsoft Dynamics 365 BC Spain con Power BI y Azure ML, [Tagetik de Wolters Kluwer](https://www.wolterskluwer.com/es-es/solutions/cch-tagetik) con Board International Spain (CPM corporativo), [Cegid Quadra Spain Performance](https://www.cegid.com/es/) con Holded Financial Planning y [Jedox Spain](https://www.jedox.com/es/) con Vena Solutions Spain. La plataforma de aprendizaje automático de series temporales abarca Python (Prophet, ARIMA de statsmodels, ETS de scikit-learn y LSTM de TensorFlow), R (forecast, prophet y tsibble), System Dynamics (Stella y Vensim) y Monte Carlo en Python (numpy, scipy y RiskAMP). Las pruebas sustantivas de las Big Four españolas se exportan directamente a Deloitte ASM, PwC Halo, EY Helix y KPMG Clara, con metadatos de rastro de auditoría de las NIA-ES 540, 570 y de Sostenibilidad, almacenamiento inmutable WORM durante 7 años, sello cualificado eIDAS y sellos de tiempo de certificado QWAC de la FNMT-RCM, y evaluación de impacto ante la AEPD. La integración con la Plataforma de Comunicaciones de Hechos Relevantes de la CNMV vía API cubre la generación del IAGC F.5, los borradores del profit warning DEFR, el reporte de cumplimiento ESMA APM y la información climática y social de la CSRD (ESRS E1-S4, Real Decreto 109/2025).

--- Agente de Detección de Fraude ---
> Detecta facturas duplicadas, proveedores fantasma y blanqueo de capitales conforme al Código Penal y a la Ley 10/2010 de PBC/FT, listo para el SEPBLAC.

El fraude empresarial en España se encuadra en un marco regulatorio de cinco áreas convergentes: el Código Penal, que tipifica la estafa (art. 248-251), la apropiación indebida (252), la insolvencia punible (253), la falsedad documental societaria (290) y los delitos fiscal y contra la Seguridad Social (305-308); la LO 5/2010, con la responsabilidad penal de la persona jurídica de hasta 9 millones de euros de multa; la Ley 10/2010 de prevención del blanqueo, con el SEPBLAC como supervisor y sanciones de 150.000 a 10.000.000 de euros; el Plan Anual de Inspección antifraude de la AEAT, con cruces de Verifactu, el SII, el CRS, la DAC6 y el Pilar Dos; el ICAC, con la responsabilidad antifraude del auditor de la NIA-ES 240 y sanciones al auditor de 12.000 a 720.000 euros; y la AEPD, con la sanción de hasta el 4% de la facturación por las decisiones automatizadas del art. 22 de la LOPDGDD. Una empresa mediana (1.500 empleados, 250 millones de euros de facturación) tiene una exposición sancionadora potencial de entre 35 y 65 millones de euros anuales sin un antifraude integrado certificable desde el diseño, según los datos consolidados del informe Report to the Nations 2024 de la ACFE, la memoria del SEPBLAC y el Plan de la AEAT de 2025.

## El Código Penal, la LO 5/2010, el SEPBLAC, la AEAT y la AEPD: cinco frentes sancionadores que exigen un antifraude certificable desde el diseño

El Código Penal tipifica en sus artículos 248-251 la estafa (hasta 6 años de prisión), con agravantes especiales en el art. 250 (importe superior a 50.000 euros, abuso de confianza, vivienda u organización criminal). El art. 252 castiga la apropiación indebida (hasta 6 años) y el art. 253, la insolvencia punible. El art. 290 tipifica la falsedad documental societaria (hasta 3 años de prisión y multa de 6 a 12 meses), un delito típico asociado a la manipulación contable o a las facturas falsas. El art. 305 castiga el delito fiscal por cuota defraudada superior a 120.000 euros (hasta 6 años de prisión y multa de hasta 6 veces la cuota) y el art. 308, el delito contra la Seguridad Social por cuota superior a 50.000 euros. El art. 282 sanciona la información engañosa a los mercados en las sociedades cotizadas, con hasta 6 años de prisión.

La LO 5/2010 introdujo la responsabilidad penal de la persona jurídica (CP art. 31 bis a 31 quinquies), con multas de hasta 9 millones de euros, suspensión de actividad hasta 5 años, clausura de locales, prohibición de contratar con el Sector Público hasta 15 años e intervención judicial. La atenuación del art. 31 bis 2 procede cuando el órgano de administración implanta un modelo de compliance conforme a la UNE 19601 y la ISO 37001 ANTES del delito; la exoneración total del art. 31 bis 4 se da cuando el modelo cumple los cuatro requisitos completos. Las sentencias del Tribunal Supremo de 2024 (STS 154/2024 y 234/2024) confirmaron la exoneración de las empresas con el SCIIF y el compliance penal integrados.

El SEPBLAC supervisa la Ley 10/2010 de prevención del blanqueo, con sanciones de 150.000 a 10.000.000 de euros y suspensión de actividad. El Plan Anual de Inspección de la AEAT de 2025 prioriza los cruces automatizados de Verifactu, el SII, el CRS, la DAC6 y el Pilar Dos, con sanciones de la LGT (art. 191-203) del 50 al 150% del importe omitido. La AEPD sanciona con hasta el 4% de la facturación las decisiones automatizadas del art. 22 de la LOPDGDD. La exposición total de una sociedad cotizada del Mercado Continuo (1.500 empleados, 250 millones de euros de facturación) puede acumular entre 35 y 65 millones de euros anuales sin un antifraude certificable desde el diseño.

## Quince puntos decisivos deterministas con tres escalados humanos

El agente procesa la detección de fraude mediante una secuencia de 15 puntos decisivos: ocho automatizaciones reglamentadas, cuatro clasificaciones por aprendizaje automático y tres escalados humanos (la comunicación al SEPBLAC en F19 o F22, la escalación al Compliance Officer bajo la LO 5/2010 y el reporte a la Comisión de Auditoría y la CNMV). La clasificación de la entidad obligada por la Ley 10/2010 determina el marco aplicable. Los demás puntos siguen la responsabilidad antifraude de la NIA-ES 240 (testing de asientos en los párrafos 24-27, elusión de controles por la dirección en el 32 y estimaciones en el 41), la matriz de incompatibilidades de la segregación de funciones de la UNE 19601 (art. 5.4), la diligencia debida de proveedores de la ISO 37001 y la transparencia de los sistemas de IA antifraude del art. 50 del Reglamento de IA de la UE.

Un ejemplo concreto: una empresa industrial cotizada del Mercado Continuo (1.200 empleados, 220 millones de euros de facturación) integra Sage 200, a3compliance y AuditBoard. El agente la clasifica como sujeto obligado por la Ley 10/2010, entidad de interés público por la Ley 22/2015 y cotizada ante la CNMV. La detección de duplicados identifica 14 facturas con variaciones de importe inferiores al 5% (mismo proveedor, fechas desplazadas). La detección de anomalías por aprendizaje automático señala 23 asientos del cierre trimestral con un z-score superior a 3 (contabilizados en la madrugada del sábado). El cruce con Verifactu identifica 8 facturas sin registro en la AEAT (discrepancia del 1,8% del volumen, por debajo del umbral significativo del 2% pero con alerta). La detección de deepfakes marca 3 facturas con metadatos inconsistentes (PDF generado fuera del horario de la empresa proveedora). El análisis de round-tripping detecta un patrón circular A-B-C-A de 180.000 euros a través del paraíso fiscal de Curazao. Todo ello desencadena la comunicación al SEPBLAC en F19, la escalación al Compliance Officer, el reporte a la Comisión de Auditoría y el Hecho Relevante a la CNMV en 24 horas.

## Cross-check Verifactu y SII fasciado 2025-2026 elimina riesgo LGT 191-203

Verifactu (RD 1007/2023) entró en vigor el 1 de julio de 2025 para las grandes empresas y se extiende de forma escalonada a todas las empresas hasta el 1 de enero de 2026. Cada factura debe llevar un número Verifactu único, un esquema XAdES certificado por la AEAT y una firma electrónica FNMT-RCM ICP-España. El cruce entre las facturas emitidas, el registro Verifactu y la declaración del SII en el plazo de 4 días de la AEAT es obligatorio. Las discrepancias superiores al 2% del volumen suponen sanción de la LGT (art. 191-203, del 50 al 150% del importe omitido) y un posible delito fiscal (CP art. 305) si la cuota defraudada supera los 120.000 euros. El Plan Anual de Inspección de la AEAT de 2025 prioriza los cruces automatizados de Verifactu y el SII para detectar el fraude estructural, y las empresas con un sistema certificable desde el diseño reducen el riesgo de selección para inspección en un 40% según los datos de la AEAT de 2024.

## La comunicación al SEPBLAC en F19 y F22 y la atenuación de la UNE 19601 bajo el art. 31 bis del Código Penal

Los sujetos obligados (Ley 10/2010, art. 2) deben comunicar las operaciones sospechosas al SEPBLAC en los formatos F19 (intención de la operación) y F22 (operación ejecutada), en un plazo máximo de 30 días desde su conocimiento. La falta de comunicación se sanciona con entre 150.000 y 10.000.000 de euros (art. 57) y puede constituir blanqueo de capitales (CP art. 301, hasta 6 años de prisión). La comunicación de buena fe al SEPBLAC exonera de responsabilidad penal y administrativa (art. 24). La Circular 4/2014 del Banco de España amplía los requisitos de las entidades de crédito: un modelo de riesgo por geografía, cliente, producto y canal de distribución, con revisión anual del auditor interno y del externo. Un programa conforme a la UNE 19601 y la ISO 37001 atenúa la responsabilidad (CP art. 31 bis 2) hasta la exoneración total (art. 31 bis 4) cuando el modelo cumple los cuatro requisitos. El agente automatiza el monitoreo, las alertas, la comunicación en F19 y F22 y el rastro de auditoría penal.

## Integración con el ecosistema español: Sage GRC, A3, SAP GRC, AuditBoard y las API de la AEAT, el SEPBLAC y la CNMV

El agente se integra con los sistemas GRC y ERP españoles vía API: [Sage 200 y Sage Despachos Connected](https://www.sage.com/es-es/) con los módulos Sage GRC y Sage Compliance, [A3 Software](https://www.a3software.com/) (a3con, a3asesor y a3ERP de Wolters Kluwer Spain) con el módulo antifraude a3compliance, SAP S/4HANA Spain Localization con SAP GRC, Process Control, Access Control y Risk Management (multinacionales del IBEX-35), Oracle Fusion Cloud ERP Spain con Oracle Risk Management Cloud y Oracle Financial Services AML, Microsoft Dynamics 365 Business Central Spain con Microsoft Purview Compliance y Microsoft Sentinel SIEM, [Cegid Quadra Spain](https://www.cegid.com/es/) con el módulo Cegid GRC y [Holded](https://www.holded.com/) Cloud con Factorial. Entre las plataformas GRC dedicadas figuran AuditBoard, Workiva, MetricStream y ServiceNow GRC. La integración con las administraciones cubre la AEAT (API de Verifactu, servicio web del SII, censo de la AEAT, modelo 232 y certificado FNMT-RCM ICP-España), el SEPBLAC (formatos F19 y F22 y Memoria anual de prevención del blanqueo), la CNMV (Hechos Relevantes y sección F del IAGC sobre el SCIIF), el Banco de España (Circular 4/2014 de las entidades de crédito) y la AEPD (registro de actividades de tratamiento y evaluaciones de impacto del art. 22 de la LOPDGDD). Las pruebas sustantivas de las Big Four bajo la NIA-ES 240 se soportan mediante exportación directa a [Deloitte ASM](https://www.deloitte.com/), [PwC Halo](https://www.pwc.com/), [EY Helix](https://www.ey.com/) y [KPMG Clara](https://www.kpmg.com/), con metadatos de rastro de auditoría de las NIA-ES, la PCAOB AS 1215 y el ROAC del ICAC. Entre las herramientas CAAT profesionales soportadas para el testing automatizado de asientos figuran ACL Robotics, IDEA y Galvanize HighBond.

--- Agente Cumplimiento Contable ---
> Cumplimiento contable GoBD: AO §147 archivado, HGB §257 conservación 8 años BEG IV, GoBD 2025 factura-e XML+PDF, inalterabilidad y acceso Z1/Z2/Z3 - documentación auditable.

La documentación de procedimientos inexistente o desactualizada es el defecto formal más frecuente que detectan los auditores fiscales. Quien no puede presentar documentación actualizada durante la inspección se arriesga a estimaciones adicionales de hasta el diez por ciento de la facturación anual sobre el beneficio imponible. El problema no es la falta de conocimiento, sino la falta de continuidad.

## La documentación de procedimientos queda obsoleta más rápido de lo que cualquier departamento de compliance puede mantenerla

Las normas contables alemanas (GoBD (estándar alemán de contabilidad) (estándar alemán de contabilidad)) exigen que cada modificación en los procesos fiscalmente relevantes se documente - nuevas versiones de software, lógica de contabilización modificada, interfaces adicionales. En un área de Finance típica con ERP, tesorería, liquidación de gastos de viaje y conexión bancaria, surgen docenas de cambios sujetos a documentación cada trimestre.

La realidad en la mayoría de las empresas: la documentación de procedimientos se creó una vez, está archivada como PDF en un servidor y no se ha tocado desde la última auditoría. Los procesos reales han evolucionado. Este delta entre el estado documentado y el estado real crece con cada adaptación del sistema.

La Ley de Desburocratización IV redujo desde enero de 2025 los plazos de conservación para comprobantes contables de diez a ocho años. Simultáneamente, el RGPD exige la eliminación de datos personales cuando desaparece el motivo de conservación. Quien elimina demasiado pronto infringe la normativa fiscal. Quien elimina demasiado tarde infringe el RGPD. Sin supervisión continua de los plazos, ambos escenarios son prácticamente inevitables.

## Los auditores fiscales utilizan defectos formales como palanca para estimaciones adicionales

Desde que la administración tributaria emplea técnicas de auditoría digital, el enfoque de las inspecciones ha cambiado. Los auditores comienzan cada vez más solicitando la documentación de procedimientos, antes incluso de examinar los datos contables. La razón: los defectos formales en la documentación son más fáciles de demostrar que los errores materiales en la contabilidad.

Si faltan archivos de registro que documenten cambios en procesos contables y versiones de software, eso basta según la jurisprudencia actual como base para una estimación adicional. El auditor argumenta que sin estas pruebas no se puede verificar la integridad e inalterabilidad de los registros. Recargos de seguridad de hasta el diez por ciento de la facturación sobre el beneficio imponible no son excepcionales - en una empresa mediana con 50 millones EUR de facturación pueden suponer cinco millones EUR de beneficio adicional sujeto a tributación.

## La obligación de facturación electrónica eleva las exigencias de archivado

Desde el 1 de enero de 2025, todas las empresas del ámbito B2B deben poder recibir facturas electrónicas. La novedad central para el cumplimiento normativo: en las facturas electrónicas debe archivarse al menos la parte estructurada XML. La parte PDF legible solo es adicionalmente obligatoria si contiene información fiscal complementaria divergente.

Para el cumplimiento normativo esto significa: cada factura entrante debe verificarse en cuanto a formato, archivarse el componente correcto y asegurarse la inalterabilidad mediante marca temporal y valor hash. Esta es una decisión basada en reglas que con cientos de facturas semanales no funciona de forma fiable manualmente.

## Un agente basado en reglas mantiene el cumplimiento actualizado sin consumir recursos de personal

El agente de cumplimiento normativo contable trabaja predominantemente en el nivel 1 del [Decision Layer](/es/decision-layer/) - basado en reglas, según directrices claras de la normativa fiscal y contable. Obligación de archivado, plazos de conservación, inalterabilidad y acceso a datos siguen lógicas de verificación definidas. Sin margen de discrecionalidad, sin necesidad de interpretación.

Para la documentación de procedimientos, el agente asciende al nivel 2: compara los procesos documentados con los procesos realmente ejecutados y propone actualizaciones. Un humano revisa y aprueba. La evaluación global de los riesgos de cumplimiento permanece completamente en manos humanas.

Un escenario concreto: el sistema ERP recibe una actualización que modifica la lógica de contabilización para facturas a cuenta. El agente detecta la desviación entre el proceso documentado y el real, redacta la sección actualizada de la documentación de procedimientos y asegura que las reglas de archivado afectadas se adapten. El asesor fiscal o responsable de impuestos aprueba la modificación. Todo el historial - quién cambió qué, cuándo y por qué - se registra automáticamente. Exactamente este registro es lo primero que solicitan los auditores fiscales.

## El cumplimiento surge como subproducto, no como esfuerzo adicional

El valor real no reside en la automatización de pasos de verificación individuales, sino en el cambio de paradigma: la conformidad normativa ya no se constata en la siguiente auditoría fiscal, sino que se asegura continuamente. La documentación de procedimientos está siempre actualizada porque se actualiza automáticamente con cada cambio de proceso. Los plazos se supervisan antes de que venzan. Y cuando el auditor fiscal solicita acceso a los datos, la respuesta está disponible de inmediato - no tras tres semanas de preparación frenética.

--- Agente de Monitorización SCIIF ---
> Monitoriza el Sistema de Control Interno sobre la Información Financiera (SCIIF) conforme al Código de Buen Gobierno de la CNMV y al marco COSO 2013.

El SCIIF (Sistema de Control Interno sobre la Información Financiera) en España constituye un marco regulatorio estructurado en seis áreas principales: el Código de Buen Gobierno de la CNMV de 2020 con su actualización de 2024 (Recomendaciones 42-44); el art. 526 de la LSC (RDLeg 1/2010), con la Comisión de Auditoría como órgano supervisor; la Ley 22/2015 de Auditoría con las NIA-ES 240, 315, 330 y 540; el marco COSO 2013 con sus 17 principios; la ISO 31000 para la gestión de riesgos; y el compliance penal de la LO 5/2010 con el programa ISO 19601 como atenuante. Cada sociedad cotizada debe documentar el SCIIF en la sección F.1 a F.7 del Informe Anual de Gobierno Corporativo (IAGC), con el auditor externo emitiendo la carta SCIIF según la NIA-ES 720; sin un sistema certificable desde el diseño, el riesgo de una deficiencia material reportable a la CNMV es elevado, especialmente tras la actualización de 2024 que refuerza los aspectos ESG.

## La CNMV, el ICAC, la LO 5/2010 y la AEPD: cuatro frentes sancionadores que exigen un sistema certificable desde el diseño

La CNMV es el regulador del mercado de valores español y supervisa el cumplimiento del Código de Buen Gobierno por las sociedades cotizadas. Las sociedades del IBEX-35 y el Mercado Continuo deben publicar el IAGC con la sección F que detalla el SCIIF; las deficiencias materiales pueden originar requerimientos formales según el art. 88 de la LMV (Texto Refundido de la Ley del Mercado de Valores) y, en los casos graves, sanciones por información engañosa (CP art. 282). La actualización de 2024 refuerza tres aspectos clave: una Comisión de Auditoría con presidente independiente, la integración de los riesgos ESG en el SCIIF conforme a la CSRD (UE 2022/2464) y la verificación de la eficacia operativa de los controles por el auditor externo, y no solo de su diseño.

El ICAC supervisa a los auditores del ROAC mediante inspecciones técnicas (cada 6 años para las entidades de interés público) y sanciona las deficiencias en la evaluación del SCIIF con entre 12.000 y 72.000 euros (Ley 22/2015, art. 84) o hasta 720.000 euros en las infracciones muy graves (art. 85). Las deficiencias más comunes del auditor son: una comprensión insuficiente del diseño de los controles (NIA-ES 315, párrafo 12), la evaluación de la eficacia operativa solo en la fecha de la auditoría sin cubrir todo el periodo y la falta de comunicación de las deficiencias significativas a la Dirección (NIA-ES 265).

La LO 5/2010 introdujo la responsabilidad penal de las personas jurídicas (CP art. 31 bis a 31 quinquies); un SCIIF efectivo, combinado con un programa de compliance conforme a la UNE 19601, puede atenuar o excluir esa responsabilidad. La AEPD sanciona con hasta el 4% de la facturación o 20 millones de euros las violaciones del RGPD en los controles internos (un registro de actividades de tratamiento incompleto, la falta de evaluación de impacto para el monitoreo sistemático o la ausencia de las cláusulas del art. 28 del RGPD con los encargados del tratamiento). Una sociedad cotizada mediana (1.500 empleados, 300 millones de euros de facturación) tiene una exposición sancionadora potencial de entre 30 y 60 millones de euros anuales sin un SCIIF certificable desde el diseño.

## Dieciséis puntos decisivos deterministas con tres escalados humanos

El agente procesa la monitorización del SCIIF mediante una secuencia de 16 puntos decisivos: trece automatizaciones reglamentadas, una clasificación por aprendizaje automático y tres escalados humanos (deficiencia material frente a significativa, compliance penal de la LO 5/2010 y aceptación del riesgo por la Comisión de Auditoría). La clasificación de la entidad obligada determina el marco aplicable: una cotizada debe reportar públicamente la sección F del IAGC ante la CNMV, una entidad de crédito sigue el ICAAP del Banco de España y una sociedad de más de 50 empleados con DNFR cumple la Ley 11/2018 de reporte no financiero. Los demás puntos siguen el marco COSO 2013 (17 principios), los apartados F.1 a F.7 de la CNMV (entorno, riesgos, actividades, información, supervisión, otras cuestiones y auditor) y las NIA-ES 240, 315, 330 y 540 (fraude, riesgos, respuesta y estimaciones).

Un ejemplo concreto: una sociedad cotizada del Mercado Continuo (1.200 empleados, 250 millones de euros de facturación) integra Sage 200 con SAP GRC. El agente la clasifica como obligada ante la CNMV, sujeta a DNFR y entidad de interés público. El mapeo de procesos significativos identifica 8 con riesgo material superior al 5%: ventas, compras, inmovilizado, nómina, tesorería, impuestos, cierre y consolidación. La verificación del principio de cuatro ojos cubre el 100% de las transacciones de más de 50.000 euros. El análisis de segregación de funciones entre módulos detecta 3 conflictos en el área de compras, donde se concentran el alta de proveedor, la aprobación de la factura y la autorización del pago. La detección de anomalías por aprendizaje automático identifica 12 asientos con un z-score superior a 3 en el cierre trimestral. El cruce con Verifactu y el SII confirma una alineación del 99,2% (deficiencia no significativa, por debajo del 2%). La Comisión de Auditoría recibe el Informe SCIIF estructurado según los apartados F.1 a F.7 del IAGC, con un plan correctivo de la segregación de funciones a 30 días.

## Cross-check SCIIF con Verifactu y SII fasciado 2025-2026

Verifactu (RD 1007/2023) entró en vigor el 1 de julio de 2025 para las grandes empresas y se extiende de forma escalonada a todas las empresas hasta el 1 de enero de 2026. Su impacto en el SCIIF es directo: cada factura debe llevar un número Verifactu y un esquema certificado por la AEAT; el cruce entre las operaciones contabilizadas y el registro Verifactu es obligatorio; y las discrepancias superiores al 2% constituyen una deficiencia significativa reportable a la Comisión de Auditoría. La integración con el SII (Suministro Inmediato de Información), para las empresas con más de 6 millones de euros de facturación, mantiene el plazo de envío de 4 días a la AEAT. El agente realiza un cruce mensual entre las facturas emitidas en Verifactu, los asientos contables y las declaraciones del SII; las discrepancias activan una alerta SCIIF y el rastro de auditoría ante la AEAT. Este cruce protege frente a las sanciones de la LGT (art. 191-203, del 50 al 150% del importe omitido) y documenta evidencia continua para el auditor externo según la NIA-ES 330, reduciendo el alcance de las pruebas sustantivas.

## Integración con el ecosistema español: Sage GRC, A3, SAP GRC, AuditBoard, Workiva y las API de la AEAT y la CNMV

El agente se integra con los sistemas GRC y ERP españoles vía API: [Sage 200 y Sage Despachos Connected](https://www.sage.com/es-es/) con el módulo Sage GRC (líder en PYME), [A3 Software](https://www.a3software.com/) (a3con, a3asesor y a3ERP de Wolters Kluwer Spain), SAP S/4HANA Spain Localization con SAP GRC, Process Control y Access Control (multinacionales del IBEX-35), Oracle Fusion Cloud ERP Spain con Oracle Risk Management Cloud, Microsoft Dynamics 365 Business Central Spain con Microsoft Purview Compliance, [Cegid Quadra Spain](https://www.cegid.com/es/) con el módulo Cegid GRC y [Holded](https://www.holded.com/) Cloud con su módulo de compliance (PYME). Entre las plataformas GRC dedicadas a las cotizadas figuran AuditBoard, Workiva, MetricStream y ServiceNow GRC. La integración con las administraciones cubre la AEAT (API de Verifactu, servicio web del SII y certificado FNMT-RCM), la CNMV (publicación del IAGC y comunicación de deficiencias), el Banco de España (ICAAP de las entidades de crédito), la AEPD (registro de actividades de tratamiento y evaluaciones de impacto) y el Tribunal de Cuentas (sociedades públicas). Las pruebas sustantivas de las Big Four se soportan mediante exportación directa a [Deloitte ASM](https://www.deloitte.com/), [PwC Halo](https://www.pwc.com/), [EY Helix](https://www.ey.com/) y [KPMG Clara](https://www.kpmg.com/), con metadatos de rastro de auditoría de las NIA-ES, la PCAOB AS 1215 y el ROAC del ICAC. Las sociedades medianas pueden recurrir a BDO, Mazars, Grant Thornton, RSM o Auren con la misma metodología NIA-ES integrada.

--- Agente Operaciones Vinculadas Intercompañía ---
> Agente operaciones vinculadas intercompañía determinista con LIS Ley 27/2014 art. 18, Reglamento IS, AEAT modelo 232 + 231 CbCR, BEPS Action 13 y conciliación bilateral Reciprocal-Match.

Las operaciones vinculadas intercompañía en España operan entre seis marcos regulatorios principales: el art. 18 de la LIS (Ley 27/2014), que obliga al valor de mercado con los métodos de la OCDE; el art. 13-16 del Reglamento del IS (RD 634/2015) sobre la documentación contemporánea de precios de transferencia; la Orden HFP/816/2017, que exige el Master File a los grupos de más de 750 millones de euros y el Local File a las entidades de más de 45 millones; el modelo 232 de la AEAT (operaciones vinculadas y paraísos fiscales) y el modelo 231 de CbCR; la Acción 13 de BEPS de la OCDE (Directrices de Precios de Transferencia de 2022) junto con los Pilares Uno y Dos de BEPS 2.0; ATAD I y ATAD II (Real Decreto-ley 4/2021), sobre los desajustes híbridos, las empresas extranjeras controladas y la limitación de intereses; y la NRV 21 del PGC (RD 1514/2007) y la NIC 24 en doble estándar, junto con el conflicto de interés de los administradores (LSC art. 230-231) y los Hechos Relevantes de la CNMV en las operaciones materiales. Cada grupo español con operaciones intragrupo superiores a 100.000 euros del mismo tipo con una misma contraparte, o a 250.000 de tipos distintos, debe coordinar la conciliación bilateral mensual, la validación del valor de mercado, la documentación contemporánea de precios de transferencia, los modelos 232 y 231 de CbCR de la AEAT, el cumplimiento de ATAD y la preparación para las pruebas sustantivas de las Big Four.

## El valor de mercado del art. 18 de la LIS, la documentación del Reglamento del IS (art. 13-16), el modelo 232 de la AEAT, el CbCR de la Acción 13 de BEPS y los desajustes híbridos de ATAD I/II: cinco frentes que exigen un sistema certificable desde el diseño

Ningún cierre consolidado español es más rápido que su conciliación de operaciones vinculadas más lenta. Un grupo con 30 sociedades genera hasta 435 posibles pares de sociedades. Aunque solo un tercio de ellos mantenga relaciones intercompañía activas, surgen mensualmente cientos de procesos de conciliación a través de fronteras de países, divisas y sistemas. Cada diferencia individual necesita atención: quién contabilizó, quién todavía no, qué tipo de cambio se aplicó, si el precio coincide con el valor de mercado del art. 18 de la LIS y si está documentado en el estudio de precios de transferencia contemporáneo. De forma manual, este proceso cuesta, según la experiencia, de cinco a seis jornadas laborales completas por cierre mensual, además del ciclo de documentación de precios de transferencia (Master File y Local File) de 80-120 horas anuales con asesoría de las Big Four.

El art. 18 de la LIS (Ley 27/2014) obliga a las sociedades a valorar las operaciones vinculadas (administradores, socios con más del 25%, sociedades del grupo y entidades vinculadas) a valor de mercado conforme a la jerarquía de métodos de las Directrices de la OCDE de 2022 (CUP, RPM, CPM, TNMM y PSM). El art. 13-16 del Reglamento del IS (RD 634/2015) detalla la documentación contemporánea obligatoria en el momento de la declaración del Impuesto sobre Sociedades (modelo 200), con el análisis de comparabilidad funcional, la asunción de riesgos y los ajustes de comparabilidad. La Orden HFP/816/2017 hace obligatorio el Master File para los grupos con cifra de negocios consolidada superior a 750 millones de euros (Acción 13 de BEPS, Directrices de 2022, cap. V) y el Local File de España para las entidades con cifra individual superior a 45 millones. El modelo 232 de la AEAT es una declaración informativa anual de las operaciones vinculadas superiores a 100.000 euros del mismo tipo con una misma contraparte, o a 250.000 de tipos distintos, y de cualquier operación con un paraíso fiscal del Anexo I del RD 1080/1991. El modelo 231 de CbCR (informe país por país) de la AEAT aplica a los grupos multinacionales con cifra de negocios consolidada superior a 750 millones, con intercambio automático de información con la OCDE bajo el acuerdo MCAA.

Hay casos célebres de operaciones vinculadas en el IBEX-35: Pescanova en 2013 (operaciones intragrupo no documentadas, reexpresión de Pricewaterhouse de 1.500 millones de euros y administradores procesados), Repsol entre 2010 y 2015 (ajuste de precios de transferencia de YPF en Argentina y arbitraje ante el CIADI de 5.000 millones de dólares), Santander entre 2018 y 2021 (Banco Popular, ajustes de precios de transferencia del holding intragrupo y consultas vinculantes de la DGT), Telefónica en 2020 (empresas extranjeras controladas de la disposición adicional 19ª de la LIS, jurisdicciones de baja tributación y ajuste de la AEAT de 460 millones), Inditex en 2017 (investigación de ayudas de Estado de la Comisión Europea sobre el ruling fiscal de Zara Holding en los Países Bajos, cerrada en 2018 sin recuperación) y ACS-Hochtief entre 2019 y 2022 (ajuste de precios de transferencia de los servicios de TI intragrupo ante el TEAC y la Audiencia Nacional). Las lecciones aprendidas son comunes: documentación contemporánea ausente, valor de mercado mal aplicado, omisiones en el modelo 232, desajustes híbridos no detectados, conflicto de interés de los administradores sin comunicar y un rastro de auditoría para las pruebas sustantivas inexistente.

## Trece puntos decisivos: once cálculos regulados, uno con clasificación ATAD asistida por aprendizaje automático y dos escalados humanos

El agente procesa las operaciones vinculadas mediante una secuencia de 13 puntos decisivos: once cálculos regulados en doble estándar PGC (NRV 21) y NIC 24, uno aumentado para la clasificación de los desajustes híbridos de ATAD I/II asistida por aprendizaje automático y dos escalados humanos (las diferencias residuales materiales sin explicar por encima del umbral de materialidad y el ajuste de cierre del valor de mercado). Extrae los saldos intercompañía bilaterales en doble estándar PGC y NIIF desde SAP S/4HANA Group Reporting Spain, Oracle EPM Cloud, Tagetik de Wolters Kluwer y BlackLine Intercompany Hub. El Reciprocal-Match bilateral por par de sociedades coteja automáticamente el saldo deudor de la sociedad A frente al acreedor de la sociedad B, con una tolerancia de materialidad de unos 500 euros. Identifica las diferencias de corte temporal (si la sociedad A contabiliza el 30/06 y la B el 02/07), clasificadas como reversibles en el periodo siguiente. Calcula las diferencias de tipo de cambio en euros, dólares, libras y reales brasileños para las multilatinas (IAS 21 y NRV 11 del PGC). Valida el valor de mercado del art. 18 de la LIS, el art. 13-16 del Reglamento del IS y los métodos de la OCDE de 2022 (CUP, RPM, CPM, TNMM y PSM). Genera la documentación del Master File para los grupos de más de 750 millones de euros y el Local File para las entidades de más de 45 millones, los modelos 232 y 231 de CbCR, la detección de los desajustes híbridos de ATAD I/II, el cumplimiento del conflicto de interés de los administradores (LSC art. 230-231), los asientos de eliminación de consolidación de la NIIF 10 y el rastro de auditoría para la inspección de la AEAT, retroactiva de 4 a 6 años.

Un ejemplo concreto: una empresa industrial española del IBEX-35 (más de 1.800 millones de euros de facturación consolidada, 12.000 empleados, multilatina con 25 filiales en Latinoamérica y la UE, con un 70% de la facturación exportada en euros, dólares, libras y reales brasileños). El agente extrae los saldos intercompañía bilaterales mensuales: 435 pares de sociedades teóricos, 87 con relaciones intercompañía activas, 1.245 transacciones intercompañía al mes y 3.420 saldos de cuenta bilateral. El Reciprocal-Match del cierre del tercer trimestre cuadra automáticamente el 87% de los pares, clasifica el 11% como diferencias de corte temporal reversibles, aísla el 1,8% como diferencias cambiarias en euros, dólares y reales (IAS 21) y escala el 0,2% restante (8 pares) de diferencias residuales al Comité de Precios de Transferencia. En cuanto a la documentación de precios de transferencia, el Master File aplica porque la cifra de negocios del grupo (1.800 millones) supera el umbral de 750 millones, y el Local File de España porque la entidad (1.200 millones) supera el de 45 millones; el estudio de precios de transferencia de las Big Four (Deloitte) y los comparables de RoyaltyStat (23 comparables) dan un rango intercuartílico del margen TNMM del 4,2 al 7,8% frente al real del 5,4% (dentro del rango). El modelo 232 de la AEAT recoge 87 contrapartes vinculadas, 234 operaciones declarables y 12 operaciones con el paraíso fiscal de Bermudas (captive insurance, 4,5 millones). El modelo 231 de CbCR recoge 25 países, España como entidad matriz última, 1.800 millones de ingresos, 245 millones de beneficio antes del Impuesto sobre Sociedades, 58 millones de impuesto pagado, 12.000 empleados y 2.100 millones de activos. En desajustes híbridos de ATAD I/II se detectan 3 instrumentos financieros híbridos (acciones preferentes en los Países Bajos, un préstamo participativo en Luxemburgo y repos en el Reino Unido): el agente clasifica los patrones y la decisión final corresponde al director fiscal y a la asesoría de precios de transferencia de PwC, con un ajuste por denegación de la deducción del art. 15 ter de la LIS de 8,2 millones.

## Cruce del valor de mercado del art. 18 de la LIS, los métodos de la OCDE de 2022, la inspección retroactiva de la AEAT de 4 a 6 años y las pruebas sustantivas de las Big Four

El art. 18.4 de la LIS (Ley 27/2014) y el art. 16 del Reglamento del IS (RD 634/2015) obligan a aplicar la jerarquía de métodos de la OCDE de 2022: el CUP es preferente cuando hay comparables fiables, típico de las materias primas, los servicios financieros y los royalties; el RPM aplica a los distribuidores, con margen bruto; el CPM, a los fabricantes contractuales, la maquila y los servicios contratados; el TNMM es el más usado en España por la dificultad de encontrar comparables transaccionales; y el PSM aplica a las operaciones muy integradas, con intangibles únicos. El agente automatiza la selección del método según la naturaleza de la operación, la disponibilidad de comparables, el análisis funcional, los comparables de RoyaltyStat y ktMINE y los estudios contemporáneos de precios de transferencia de las Big Four. La inspección de precios de transferencia de la AEAT es un enfoque estándar del Foro de Grandes Empresas, con una prescripción retroactiva de 4 años (6 en caso de fraude) según el art. 66-67 de la LGT (Ley 58/2003). El rastro de auditoría completo del agente reduce la respuesta al primer requerimiento de las 200-300 horas tradicionales de las Big Four a 40-60 horas, con documentación contemporánea y extractos preformateados. Las sanciones del art. 18.13 de la LIS (hasta el 15% del importe del ajuste, 1.500 euros por dato omitido y 15.000 por dato falso, con un máximo del 1% de la cifra de negocios) se evitan. Ante el TEAC, la Audiencia Nacional y el TJUE cabe el recurso por la vía económico-administrativa y judicial cuando el ajuste es material, con la jurisprudencia vinculante de precios de transferencia de Pescanova, Acerinox, Repsol y Santander.

## Casos límite de las operaciones vinculadas en España: multilatinas en Latinoamérica, desajustes híbridos de ATAD y el Pilar Dos de BEPS 2.0

Hay varios casos especiales. El primero son las multilatinas (Telefónica, BBVA, Inditex, Ferrovial y ACS), con el aislamiento de la varianza cambiaria (IAS 21 y NRV 11 del PGC), los más de 90 convenios de doble imposición de España y el instrumento multilateral (BOE de 22/12/2021) con sus reglas antiabuso, el test del propósito principal (PPT) y la limitación de beneficios (LOB). El segundo es la hiperinflación de Argentina y Venezuela (IAS 29), con la reexpresión de las cuentas de las filiales y los saldos intercompañía a peso constante. El tercero son los desajustes híbridos de ATAD I/II (Real Decreto-ley 4/2021): acciones preferentes, préstamos participativos, entidades check-the-box LLC estadounidenses e híbridos inversos. El cuarto es el Pilar Uno de BEPS 2.0, para los grupos de más de 20.000 millones de euros (Amount A). El quinto es el Pilar Dos, con la tributación mínima del 15% para los grupos de más de 750 millones (Directiva UE 2022/2523 y Real Decreto-ley 4/2024, reglas IIR, UTPR y QDMTT en España). El sexto es la financiación intragrupo, con la subcapitalización del art. 16 de la LIS y la regla de limitación de intereses del art. 4 de ATAD I. El séptimo son los intangibles, con las funciones DEMPE (Directrices de la OCDE, cap. VI), los intangibles de difícil valoración (HTVI) y el principio de proporcionalidad con la renta generada. El octavo son los acuerdos de reparto de costes y los APA bilaterales o multilaterales de la DGT. Y el noveno es el procedimiento amistoso (MAP) de doble imposición y el arbitraje vinculante del instrumento multilateral (Acción 14 de BEPS).

## Integración con SAP S/4HANA Spain, Oracle EPM, Tagetik, BlackLine, las Big Four y el certificado digital ICP-España de la AEAT

El agente se integra con los sistemas multientidad españoles vía API: [SAP S/4HANA Group Reporting Spain](https://www.sap.com/spain/) con SAP Intercompany Matching y SAP BPC Spain (multinacionales del IBEX-35 como Telefónica, Iberdrola, BBVA, Santander y Repsol), [Oracle EPM Cloud Spain](https://www.oracle.com/es/) con Oracle Hyperion Financial Management y Oracle Fusion ERP Spain (gigantes de la consolidación), [Tagetik de Wolters Kluwer](https://www.wolterskluwer.com/es-es/solutions/cch-tagetik) con Board International Spain (CPM corporativo de consolidación), [Anaplan Spain](https://www.anaplan.com/es/) Intercompany con [Workday Adaptive Planning Spain](https://www.workday.com/es-es/) (medianas nativas en la nube), OneStream Software Spain con [BlackLine Intercompany Hub](https://www.blackline.com/es/) (líder en matching intercompañía), [Sage 200 Group](https://www.sage.com/es-es/) con Sage Despachos Consolidación y Sage X3 multientidad (medianas y grandes), [A3 de Wolters Kluwer](https://www.a3software.com/) (a3ERP y a3 Consolidación para grupos PYME), [Cegid Quadra Spain](https://www.cegid.com/es/) con Holded multientidad y Sage Intacct, y Microsoft Dynamics 365 BC y F&O multientidad. El motor Reciprocal-Match en Python (pandas y scikit-learn) ingiere los comparables de RoyaltyStat, ktMINE y Comparables.com y los tipos de cambio de Bloomberg y Reuters. Las pruebas sustantivas de las Big Four españolas se exportan directamente a Deloitte ASM, PwC Halo, EY Helix y KPMG Clara, con la NIA-ES 540 del ICAC, la materialidad de la NIA-ES 320 y los metadatos del rastro de auditoría. El certificado digital ICP-España de la AEAT (FNMT-RCM Clase 2 CA o ICP-Empresa) cubre la presentación electrónica de los modelos 232, 231 de CbCR y 200, con almacenamiento inmutable WORM durante 7 años, evaluación de impacto ante la AEPD y sello cualificado eIDAS de la FNMT-RCM. La Plataforma de Comunicaciones de Hechos Relevantes de la CNMV, el IAGC F.5 y el conflicto de interés de los administradores (LSC art. 230-231, con la Comisión de Auditoría y el Consejo de Administración) alimentan el [Decision Layer](/es/decision-layer/) para su revisión por el director fiscal, el CFO y el Comité de Precios de Transferencia.

--- Agente Aprobación Facturas ---
> Determina aprobador según matriz por importe, centro de coste y grupo de producto, verifica disponibilidad presupuestaria, controla bloqueos de proveedor y escala por vencimiento de plazo.

Cada factura que se aprueba un día demasiado tarde es una decisión perdida. No porque alguien la haya olvidado, sino porque la asignación al aprobador correcto es, en la mayoría de las empresas, un proceso manual - dependiente del conocimiento en cabezas concretas, no de reglas claras en el sistema. El agente de aprobación de facturas convierte este cuello de botella en un tramo predecible.

## Los retrasos en la aprobación destruyen ingresos por descuento de forma silenciosa

Una ventana típica de descuento por pronto pago es de diez días. Diez días en los que una factura debe ser capturada, verificada, asignada, aprobada y ordenada al pago. Según un análisis de Nanonets, el tiempo medio de procesamiento de una factura es de 9,2 días - y esa es la media. En empresas sin procesos estructurados de aprobación, la cifra supera los 17 días (Nanonets, 2025).

El resultado: con un volumen de compras de 50 millones de euros (unos 54 millones de USD) y un descuento del 2 por ciento sobre la mitad de las facturas, cada año quedan en la mesa 500.000 EUR (unos 540.000 USD) - no porque falten las condiciones, sino porque el proceso de aprobación es demasiado lento. El dinero no desaparece en un único incidente. Se escurre en cientos de casos individuales que nadie agrega.

## La matriz de aprobación es un reglamento, no un margen de decisión

La pregunta "¿quién puede aprobar esta factura?" suena a criterio. En la práctica es lo contrario. La respuesta se deriva de una combinación fija de umbrales de importe, centro de coste, proyecto y proveedor. Un reglamento que en la mayoría de los sistemas ERP ya está configurado - pero se aplica manualmente.

El agente asume exactamente este enrutamiento. Lee la matriz de aprobación, asigna la factura al aprobador competente y comprueba en paralelo si hay presupuesto disponible en el centro de coste y si el proveedor está bloqueado. Tres decisiones que juntas duran menos de un segundo - y que en el proceso manual ocupan a menudo horas o días, porque están repartidas entre distintos sistemas y bandejas de entrada.

[Decision Layer](/es/decision-layer/) nivel 1: las tres comprobaciones siguen reglas deterministas. No hay margen de interpretación, no hay zona gris, no hay excepción que no se pueda definir de antemano.

## La lógica de escalado protege los plazos antes de que venzan

El problema más frecuente en la aprobación de facturas no es la decisión incorrecta. Es la decisión que no llega. Una factura queda en la bandeja de entrada del aprobador competente, que está en reuniones, de viaje de trabajo o sencillamente sobrecargado.

El agente supervisa cada aprobación en curso contra los plazos configurados. Si se acerca el final del plazo de descuento, escala al suplente definido - no tras tres correos recordatorios, sino por una regla clara: si no se aprueba en X horas, reenvío a nivel jerárquico Y.

Un escenario concreto: un proveedor emite el martes una factura de 85.000 EUR (unos 92.000 USD) con un 2 por ciento de descuento si se paga en diez días. El jefe de departamento competente está hasta el viernes en un congreso. El agente detecta la ausencia, reenruta al suplente y la aprobación se produce el miércoles. Sin lógica de escalado, la factura habría sido procesada como muy pronto el lunes siguiente - cuatro días después del vencimiento del plazo de descuento. 1.700 EUR (unos 1.840 USD) de pérdida en una sola operación.

## La aprobación por lotes acelera los casos estándar

No todas las facturas merecen atención individual. Facturas recurrentes del mismo proveedor, por el mismo importe, contra el mismo centro de coste - siguen un patrón que el agente reconoce. Estos casos se clasifican para aprobación por lotes: el aprobador recibe una vista agregada en lugar de casos individuales.

Esto no solo descarga al aprobador, sino que cambia el reparto de capacidad en todo el proceso de cuentas por pagar. Los equipos de AP de mejor desempeño alcanzan tiempos medios de procesamiento significativamente inferiores a los de equipos sin procesos estructurados - la diferencia se mide en días, no en horas. La aprobación por lotes es una de las palancas que explica esa diferencia.

## El Human-in-the-Loop decide donde las reglas no bastan

De los siete pasos de decisión en la aprobación de facturas, seis son íntegramente basados en reglas. El séptimo no: la aprobación en caso de exceso presupuestario.

Cuando una factura supera el marco disponible del centro de coste, no hay algoritmo que pueda decidir si el gasto está justificado pese a todo. Quizá el presupuesto está desfasado. Quizá se acordó verbalmente un suplemento al pedido. Quizá la entrega es crítica para el negocio y el proceso de presupuestación va por detrás de la realidad.

Decision Layer nivel 2: el agente entrega a la persona que decide todos los hechos - importe de la factura, presupuesto restante, gastos acumulados en el centro de coste, historial del proveedor - y mantiene la decisión abierta. Ni propuesta ni recomendación, solo una nota de decisión estructurada. La responsabilidad queda con el Human-in-the-Loop, pero la preparación dura segundos en lugar de horas.

--- Agente Captura Facturas ---
> Recibe facturas en Verifactu (sistema obligatorio 2025-2026), SII (Suministro Inmediato de Información), FacturaE B2G y TicketBAI (País Vasco). Valida NIF en AEAT, calcula IVA 4/10/21%, archiva conforme LGT + RGPD. Output: registros AEB Norma 43 + asiento ERP.

Verifactu (Real Decreto 1007/2023) marca un cambio estructural en la facturación española: desde 1 julio 2025 las grandes empresas (>6M EUR facturación) deben emitir y recibir facturas a través del sistema AEAT certificado, faseado hasta cubrir todas las empresas en 2026. Junto a SII (Suministro Inmediato de Información, obligatorio desde 2017 para empresas >6M EUR), TicketBAI (Vizcaya, Guipúzcoa, Álava) y FacturaE 3.2.2 (B2G obligatorio desde 2015 para sector público), el ecosistema español de facturación electrónica es uno de los más complejos de la UE. Todo esto converge en un único Agente de Recepción que valida, clasifica y archiva más de 5.000 facturas al mes en una operación de tamaño medio, con reportes paralelos PEPPOL/EN 16931 si la empresa pertenece a un grupo internacional con matriz en la UE, Reino Unido o EE.UU.

## Las sanciones AEAT por errores en SII y Verifactu llegan al 50% del IVA más un 1% por dato omitido

El art. 200.3 LGT establece sanciones del 1% del importe no comunicado por cada factura no enviada al SII en el plazo de 4 días naturales, con un máximo de 6.000 EUR por factura. Para una empresa española mediana con 1.500 facturas mensuales, un retraso del 5% (75 facturas) puede generar sanciones potenciales de 75 × 6.000 EUR = 450.000 EUR anuales en el peor escenario. La sanción real depende del importe omitido por factura; en la práctica son frecuentes importes medios de 50.000 a 150.000 EUR al año en empresas que no han automatizado su SII.

Para errores en datos identificativos (NIF erróneo, denominación social desactualizada), el art. 199 LGT sanciona con 150 EUR por dato. Para errores en la cuota de IVA o el tipo aplicable, la sanción llega hasta el 50% del importe defraudado. En las empresas IBEX-35 con auditoría Big-4, los errores SII recurrentes se reportan como deficiencias de control en el informe SCIIF (Sistema de Control Interno de la Información Financiera, recomendación CNMV 2015); una deficiencia material en el SCIIF puede afectar a la cotización a través del comunicado a la CNMV.

## El Agente atraviesa 14 etapas determinísticas, todas auditables por AEAT

El Agente procesa cada factura en 14 etapas: validación del XML y de la firma XAdES (FacturaE 3.2.2, Verifactu RD 1007/2023, TicketBAI con cadena de bloques), comprobación de los campos obligatorios (RD 1619/2012 art. 6 facturas ordinarias, art. 7 simplificadas, art. 15 rectificativas), validación del NIF en AEAT y en VIES para operaciones intracomunitarias, clasificación del IVA (0/4/10/21% según el Anexo I-IV de la LIVA), detección de la retención de IRPF (15% general para profesionales o 7% para nuevos), inversión del sujeto pasivo (art. 84.uno.2 LIVA), extracción de datos estructurados, detección de duplicados (prescripción de 4 años LGT), umbral de aprobación SCIIF (la única etapa H), generación de registros SII (envío diario a AEAT), declaración de operaciones intracomunitarias en el Modelo 349, archivo WORM conforme al art. 66 LGT (4-8 años) y asiento ERP en formato Sage, A3 o SAP.

Escenario típico: una empresa industrial de Bilbao - obligada a TicketBAI, a SII si supera 6M EUR y a FacturaE para sus clientes de la administración pública - recibe 2.000 facturas al mes de proveedores (componentes, química, servicios técnicos y profesionales con retención de IRPF). El 65% son facturas nacionales con IVA al 21%, el 15% intracomunitarias UE (con validación VIES y declaración del Modelo 349), el 10% de profesionales con retención de IRPF del 15% (Modelo 111 trimestral) y el 10% de emisores vascos en TicketBAI (firma con cadena de bloques). Sin el Agente, el departamento fiscal dedica de 22 a 28 días al mes a la clasificación manual, con un 5% de errores en SII. Con el Agente: 4 horas al mes para 2.000 facturas y menos del 0,5% de error en la revisión muestral.

## Inversión del sujeto pasivo y operaciones intracomunitarias: precisión sin margen

El art. 84.uno.2 LIVA establece la regla de inversión: en las operaciones intracomunitarias B2B, los servicios prestados desde el extranjero por no residentes, las ejecuciones de obra de construcción por subcontratistas, las entregas de oro de inversión y los residuos de hierro y acero, es el destinatario quien repercute el IVA, no el emisor. El Agente identifica la combinación de NIF, país y tipo de operación, y aplica el código de IVA al asiento contable; el IVA repercutido y el soportado son simultáneos y se compensan en la declaración del Modelo 303.

Para las empresas con presencia en el País Vasco (Vizcaya, Guipúzcoa, Álava) o Navarra, el sistema fiscal foral exige un tratamiento separado: TicketBAI con cadena de bloques en Vizcaya, Guipúzcoa y Álava, y RPF (Revisión de Pago) en Navarra. El Agente se integra con TBAILink (sistema homologado por las Haciendas Forales vascas) y gestiona en paralelo las declaraciones Modelo 303/322 en territorio común y las declaraciones forales 303-V/322-V en territorio foral, manteniendo un Audit Trail consolidado para la auditoría de la matriz si el grupo es multinacional.

## Integración con Sage NominaPlus, A3 Software, Holded y el ecosistema español

El Agente se conecta por API con los principales ERP del mercado español: [Sage NominaPlus y Sage 200](https://www.sage.com/es-es/) (líder en PYME), [A3 Software](https://www.a3software.com/) (a3con, a3asesor y a3nom, fuerte en despachos profesionales), [Holded](https://www.holded.com/) (cloud para autónomos y PYME), [Cegid Quadra](https://www.cegid.com/es/) (mediana empresa) y SAP S/4HANA Spain Localization (multinacionales IBEX-35 con presencia internacional). El servicio AEAT funciona vía web service con certificado digital cualificado FNMT-RCM o AC Camerfirma. La validación SII previa al envío usa el servicio AEAT 'Comprobación Errónea' antes del envío diario. Para las multilatinas con matriz en la UE genera en paralelo XRechnung 3.0 (Alemania B2G), Factur-X/ZUGFeRD (Alemania B2B), KSeF FA(2) (Polonia, obligatorio en 2026) y NF-e (Brasil) cuando el grupo es internacional, con el mismo asiento contable visible para la AEAT y para la auditoría de la matriz bajo IFRS. Para los grupos IBEX-35 con presencia en LATAM (Telefónica, Iberdrola, Santander, BBVA), el Agente coordina con los módulos NIIF locales de cada país: la misma lógica de validación, con distintas rutas de archivo y de reporte regulatorio.

--- Agente Emisión Facturas ---
> Crea facturas de venta desde datos servicio: determina tipos IVA (4/10/21%, intracomunitario, exportación), selecciona formato (Facturae 3.2.2, TicketBAI País Vasco, PDF) y archiva según estándar alemán y LGT.

La creación de facturas consume capacidad que falta en otras áreas del departamento financiero. Al mismo tiempo, la presión regulatoria aumenta con la obligación de facturación electrónica. El agente de emisión de facturas resuelve ambos frentes: crea facturas de venta íntegramente basadas en reglas - sin componente de IA, sin intervenciones manuales, con trazabilidad total ante la AEAT desde el primer comprobante.

## Las facturas con errores cuestan más que el simple retrabajo

Una parte sustancial de todas las facturas creadas manualmente contiene errores. La corrección de un único comprobante erróneo cuesta cifras de dos dígitos en USD cuando se suma el coste de personal, las correcciones en el sistema y los retrasos en el cobro. En una empresa que emite 500 facturas de venta al mes, los comprobantes erróneos acumulan un coste de corrección de cuatro cifras en EUR - cada mes, antes incluso de considerar el perjuicio real por cobros retrasados.

Los errores en las facturas de venta rara vez son aleatorios. Tipos de IVA incorrectos en entregas intracomunitarias, datos obligatorios ausentes exigidos por la normativa de IVA, condiciones de pago incoherentes - son debilidades sistemáticas que surgen una y otra vez del mismo proceso manual. Precisamente esa sistematicidad hace que el error sea resoluble por reglas.

## La obligación de factura electrónica aumenta la presión para actuar

En España, la Ley Crea y Crece (Ley 18/2022) obliga progresivamente al uso de la factura electrónica en operaciones B2B, con desarrollo reglamentario pendiente. El sistema VeriFactu establece además requisitos para los programas de facturación desde 2025/2026. En Alemania, toda empresa debe poder recibir facturas electrónicas estructuradas desde el 1 de enero de 2025; el plazo transitorio para la emisión termina a finales de 2026. A partir de ahí, toda factura de venta debe entregarse como conjunto de datos estructurado en formato XRechnung o ZUGFeRD - no como PDF, no como escaneo.

Detrás de estas obligaciones hay un objetivo concreto: cerrar la brecha del IVA a nivel europeo, que supera los 60.000 millones de EUR (unos 65.000 millones de USD) según estimaciones de la Comisión Europea. Para los departamentos financieros, eso significa un cambio de formato que va mucho más allá de la facturación. Cada comprobante debe ser legible por máquina, los datos obligatorios deben ajustarse exactamente al esquema y el formato elegido debe poder configurarse por cliente.

Quien gestiona este cambio manualmente añade nuevas fuentes de error a un proceso ya propenso a fallos. Quien lo automatiza elimina el formato como punto de decisión.

## Ocho pasos de decisión sustituyen el proceso manual

Un escenario concreto: un prestador de servicios de proyectos emite mensualmente 400 facturas de venta a clientes en España, la UE y Suiza. Hasta ahora, un responsable revisa para cada comprobante el tipo de IVA, añade los datos obligatorios, selecciona el formato y asigna el número de factura manualmente.

El [Decision Layer](/es/decision-layer/) descompone este proceso en ocho pasos deterministas. Los datos de servicio se recuperan del sistema fuente. Los datos obligatorios exigidos por la normativa de IVA se recopilan automáticamente. El tipo de IVA se deriva de la ubicación del cliente y del tipo de servicio - 21 por ciento en operación interior, exento en entregas intracomunitarias, país tercero sin IVA. El formato electrónico se deriva de los datos maestros del cliente. Las condiciones de pago vienen del contrato. El número de factura se asigna de forma atómica - sin lagunas, sin duplicación. Envío y archivado se producen de forma simultánea.

Los ocho pasos están basados en reglas. Ningún paso exige una estimación, una ponderación o un pronóstico. Por eso el componente de IA está exactamente en el 0 por ciento - y la Readiness se sitúa entre 89 y 96 puntos, el valor más alto del catálogo.

## La conformidad normativa surge en el proceso, no en el control posterior

Los requisitos contables y tributarios exigen tres cosas de cada factura de venta: numeración consecutiva sin lagunas, archivado inalterable y trazabilidad completa. En procesos manuales esto se asegura habitualmente mediante controles posteriores - una revisión a final de mes, un cotejo de los rangos numéricos, una ejecución manual del archivado.

El agente de emisión de facturas invierte esta lógica. La asignación de numeración está integrada de forma atómica en el proceso de creación. El archivado se produce simultáneamente con el envío, no después. Y cada decisión - qué tipo impositivo, qué formato, qué canal de envío - se registra con sello de tiempo y justificación. Ante una inspección tributaria, la ruta completa de decisión está disponible para cada comprobante.

Para los directores financieros esto significa: la conformidad normativa deja de ser un riesgo de inspección y pasa a ser una propiedad del sistema. El Decision Layer en nivel 1 - reglamento puro - convierte la emisión de facturas en el proceso más fiable de toda la contabilidad de clientes.

--- Agente de Asientos Contables ---
> Genera asientos de cierre conforme al PGC y los encadena con el SII en tiempo real y Verifactu, de forma 100% determinista ante el ICAC y la AEAT.

Los asientos contables en España son el corazón del sistema de información financiera y están sujetos a seis capas regulatorias simultáneas: el Código de Comercio 22/8/1885 art. 25-49 obliga a llevar libro diario y libro de inventarios y cuentas anuales con plazo de conservación de 6 años, el Plan General de Contabilidad RD 1514/2007 establece el cuadro de cuentas y las normas de registro y valoración obligatorias para empresas (con la versión simplificada PGC PYMES RD 1515/2007), las Resoluciones ICAC publicadas en BOE desarrollan el PGC en materia de imputación temporal, deterioros y consultas vinculantes, la Ley del Impuesto sobre Sociedades 27/2014 art. 11 fija el principio de devengo y la inscripción contable como requisito de deducibilidad, el Real Decreto 1624/1992 art. 62.6 obliga al envío diario al Sistema de Suministro Inmediato de Información (SII) para empresas con facturación superior a 6 millones EUR, y el Real Decreto 1007/2023 introduce el sistema Verifactu con encadenamiento criptográfico de facturas. Cada asiento mal calificado o desfasado puede activar simultáneamente requerimiento AEAT, observación del auditor obligatorio (Ley 22/2015), bloqueo del Registro Mercantil por falta de depósito (LSC art. 282) y sanción ICAC - el riesgo se acumula en cada cierre mensual.

## Sanción ICAC, denegación del modelo 303 por la AEAT, bloqueo de cuentas en el Registro Mercantil y sanción del 50-150% por el art. 191-195 LGT

La inspección AEAT por imputación temporal incorrecta es uno de los riesgos más materiales en el ciclo de cierre español. La AEAT regulariza con sanción del 50% del importe defraudado en infracciones leves, 75% en graves y hasta 150% en muy graves conforme LGT art. 191-195, más intereses de demora calculados al tipo de interés legal del dinero incrementado en un 25% (interés legal 2026 alrededor del 4%). Para una empresa media con 100 millones EUR de facturación y un ajuste de 800.000 EUR por gastos imputados al ejercicio incorrecto, la exposición fiscal alcanza 400.000-1,2 millones EUR antes de intereses, más el coste de litigio si se recurre ante el TEAC o la Audiencia Nacional - sin contar el daño reputacional por publicación del expediente conforme Ley 11/2021 lucha contra el fraude fiscal.

A esto se suman los riesgos paralelos. La denegación del modelo 303 IVA por divergencias con los registros SII activa requerimiento inmediato y eventual derivación de responsabilidad al administrador (LGT art. 43) por importe histórico no prescrito - 4 años desde finalización del plazo de declaración. El cierre del Registro Mercantil por falta de depósito de cuentas anuales (LSC art. 282) bloquea cualquier inscripción societaria - cambios de administradores, poderes, ampliaciones de capital, emisiones, escrituras estatutarias - hasta regularización, lo que puede paralizar operaciones M&A o financiaciones bancarias. Y la auditoría obligatoria conforme Ley 22/2015 emite informe con salvedades o denegación de opinión si la documentación no resiste testing - con publicación en Registro Mercantil, BOE y consulta pública que afecta calificaciones crediticias y relaciones con inversores y bancos.

## El cierre contable español recorre 14 etapas determinadas, no 8

A diferencia del modelo alemán estándar (8 etapas) o del polaco (10 etapas), el cierre contable español compliance-first exige 14 etapas determinadas porque el sistema regulatorio superpone seis capas obligatorias: identificación de asientos recurrentes sobre patrón histórico de 12 meses (clasificación AI), validación de imputación temporal LIS art. 11 frente al principio de devengo PGC, cálculo de periodificaciones según norma de registro y valoración 9.2.4 del PGC (cuentas 480 gastos anticipados, 485 ingresos anticipados, 567 corretajes y otros gastos, 568 corretajes y otros ingresos), contabilización de amortizaciones según tabla LIS art. 12.1.a (cuentas 28X amortización acumulada, 68X dotación del ejercicio), provisiones por deterioro y obligaciones conforme Resolución ICAC 18/9/2013 (cuentas 29X deterioro inmovilizado, 49X deterioro créditos, 14X provisiones de pasivo), verificación de equilibrio entre cuentas 477X (IVA repercutido) y registros SII enviados diariamente a AEAT, conciliación con registros Verifactu RD 1007/2023 inalterables, clasificación de partidas extraordinarias (cuentas 678 gastos excepcionales, 778 ingresos excepcionales) que requiere juicio humano, aplicación del plan contable correcto (PGC, PGC PYMES o NIIF UE), asientos de operaciones intragrupo según LIS art. 18, generación de asientos formales con debe y haber, segregation of duties (cuatro ojos) recomendada por CNMV en SCIIF, integración en libro diario y libro mayor conforme Código Comercio art. 25-28 y preparación para depósito anual en Registro Mercantil conforme LSC art. 279.

Un escenario concreto: empresa industrial mediana en Barcelona con 1.500 asientos por cierre mensual, 80 millones EUR de facturación, sujeta a SII por superar el umbral de 6 millones EUR y obligada a auditoría por superar dos de tres umbrales Ley 22/2015 (activo 25M EUR, facturación 80M EUR, plantilla 320). Cada cierre mensual el Agente identifica 1.140 asientos recurrentes (76% del volumen) con patrón idéntico en 12 meses anteriores y los propone, calcula 78 periodificaciones para contratos de servicios anticipados (mantenimientos, seguros, alquileres pagados por adelantado) sobre 18 contratos vigentes, contabiliza amortizaciones para 487 elementos del inmovilizado material e inmaterial siguiendo tabla LIS art. 12, ajusta 24 provisiones por deterioro de créditos comerciales conforme Resolución ICAC con escalado por antigüedad, concilia 142 facturas emitidas en cuentas 477X con XML enviados al SII (detectando 2 divergencias por errores de tipo impositivo), valida 198 facturas Verifactu con encadenamiento criptográfico verificado, escala 14 partidas extraordinarias para clasificación humana del Director Financiero (gastos excepcionales por bajas anticipadas de inmovilizado y por reestructuraciones), aplica plan contable PGC y mantiene contabilidad paralela NIIF para reporting al grupo matriz cotizado, prepara 67 asientos de operaciones intragrupo con documentación modelo 232, registra todos los asientos con segregation of duties (preparador y aprobador distintos), integra en libros obligatorios Código Comercio art. 25-28 y prepara extracto XBRL para depósito en Registro Mercantil al cierre del ejercicio.

En el [Decision Layer](/es/decision-layer/), 12 de las 14 etapas son decisiones basadas en reglas (nivel R) o reconocimiento AI (nivel A en patrón de recurrencia). Las dos decisiones humanas son la clasificación de partidas extraordinarias (cuentas 678/778 que requieren juicio profesional sobre si la operación deriva del tráfico ordinario) y la segregation of duties (segunda firma como control anti-fraude). No hay punto en el procesamiento determinado donde un contable añada valor discrecional - cada cálculo es la aplicación del PGC RD 1514/2007, de la LIS art. 11-15, de las Resoluciones ICAC, de los registros SII y Verifactu o del Código de Comercio art. 25-49.

## Conciliación bidireccional SII y Verifactu evita requerimiento AEAT y sanción 50-150%

Un cierre contable sin conciliación previa con SII y Verifactu es receta para requerimiento AEAT inmediato. La empresa registra una factura de venta el día 1 con tipo IVA 21%, pero el envío SII se procesa con tipo 10% por error en el master de tipos impositivos del ERP, el balance contable refleja correctamente 477X 21% pero el libro registro de facturas emitidas en SII muestra 10% - la AEAT cruza automáticamente y emite requerimiento al detectar diferencia, con plazo de 10 días para subsanación y sanción del 50% del importe diferencial conforme LGT art. 191. Para una factura de 100.000 EUR la sanción sería 5.500 EUR (sobre el diferencial 11% IVA = 11.000 EUR), pero el cruce sistemático identifica patrones y eleva la calificación a infracción grave (75%) o muy grave (150%) si se considera ocultación conforme art. 184.2 LGT.

Por eso la 6a y 7a etapa de decisión son conciliación previa obligatoria ANTES del cierre del período. El Agente integra los XML de SII enviados a AEAT (formato A1 emitidas, A2 recibidas, A3 bienes inversión, A4 cobros y pagos, A5 operaciones intracomunitarias) y los compara línea a línea con el balance contable de cuentas 477X y 472X. Pagos a proveedores con factura en SII pero sin asiento contable se marcan como pendientes de registro. Asientos contables sin entrada SII se marcan como pendientes de envío. Las facturas Verifactu RD 1007/2023 con encadenamiento criptográfico verificado se cruzan con asientos del libro diario por código de factura y hash de cadena - cualquier divergencia activa bloqueo automático del cierre hasta resolución. Solo cuando el balance contable y los registros SII y Verifactu son perfectamente coherentes el cierre mensual progresa a la siguiente etapa.

## Imputación temporal LIS art. 11 y consultas vinculantes ICAC exigen precisión normativa

Casos especiales como imputación temporal (LIS art. 11), deterioro de créditos (Resolución ICAC 18/9/2013), operaciones a plazo (LIS art. 11.4) y ajustes extracontables del modelo 200 parecen complejos pero son determinados por norma española. El principio de devengo PGC coincide con LIS art. 11, pero existen divergencias: amortización contable acelerada vs lineal LIS art. 12, deterioros no admitidos LIS art. 13, gastos no deducibles LIS art. 15 (sanciones, atenciones a clientes >1% INCN), operaciones con precio aplazado donde el ingreso fiscal se difiere proporcionalmente al cobro.

El Agente identifica cada operación con divergencia contable-fiscal mediante reglas determinadas y prepara el ajuste extracontable para el modelo 200 IS, manteniendo un doble registro paralelo: el resultado contable PGC más el ajuste dan la base imponible fiscal LIS. Para las operaciones sin cobertura en consulta vinculante ICAC o jurisprudencia TEAC y de importe material (>1% del activo o >5% del resultado), el Agente escala a juicio humano - Director Financiero, auditor externo o asesor fiscal en operaciones de reorganización conforme al LIS art. 76-89.

## Integración con ecosistema español: Sage, A3 Software, Holded, SAP, Registro Mercantil

La lógica del Agente se conecta con los principales sistemas de gestión contable del mercado español vía API: [Sage 200 y Sage Despachos Connected](https://www.sage.com/es-es/) (líder en PYME, con PGC RD 1514/2007 y libros oficiales), [A3 Software](https://www.a3software.com/) (a3con, a3asesor y a3ERP, para despachos y mediana empresa con integración AEAT y Registro Mercantil), [Holded](https://www.holded.com/) (cloud para autónomos y PYME con SII), [Cegid Quadra](https://www.cegid.com/es/), SAP S/4HANA Spain Localization (IBEX-35 con PGC y NIIF en paralelo) y Microsoft Dynamics 365 Business Central Spain. El envío diario al SII usa el web service de la AEAT con certificado digital cualificado FNMT-RCM. Los registros Verifactu RD 1007/2023 se integran por API directa con la AEAT. El depósito de cuentas anuales en el Registro Mercantil usa el formato XBRL del Colegio de Registradores. Para los grupos IBEX-35 con filiales en LATAM (Telefónica, Iberdrola, Santander, BBVA, ACS, Inditex), el Agente genera reportes paralelos IFRS 9/15/16 para la consolidación de la matriz, manteniendo la operación local española conforme al PGC, la LIS y el ICAC, y el reporting de la matriz bajo estándares internacionales.

--- Agente Contabilización Arrendamientos ---
> Agente contabilización arrendamientos determinista con PGC RD 1514/2007 NRV 8 operativo vs financiero, NIIF 16 Right-of-Use Asset, ICAC, AEAT modelo 200 LIS art. 13.4 y CNMV DEFR IBEX-35.

La contabilización de arrendamientos en España es uno de los procesos contables más técnicos del cierre anual, con seis capas regulatorias superpuestas. La AEAT cruza el modelo 200 IS (presentación hasta el 25 de julio tras el cierre) con la imputación temporal de la LIS art. 13.4, que separa fiscalmente la cuota de leasing entre la carga financiera deducible (intereses) y la amortización del bien para la recuperación del coste, limitada por la tabla de amortización fiscal del RD 634/2015 art. 12-13; cualquier divergencia genera una potencial denegación de la deducción del gasto vinculado conforme a la LIS art. 13.4, con sanción del 50-150% del importe defraudado (LGT art. 191-195) e intereses del 4,0625% anual. La ICAC supervisa a los auditores ROAC con sanción grave de 12.001-72.000 EUR y suspensión de 1-3 años del ejercicio ante una auditoría deficiente por la NIA-ES 540 de estimaciones contables (el IBR es la estimación más sensible de toda la contabilización de arrendamientos). La CNMV obliga a las sociedades cotizadas IBEX-35 (Telefónica, Iberdrola, Santander, BBVA, Inditex, ACS, Repsol, Cellnex, Naturgy, Acciona, Aena, Indra, Ferrovial, Mapfre) a publicar Hechos Relevantes ante los restatements de clasificación de arrendamientos, con sanción de 30.001-300.000 EUR por infracción grave y responsabilidad de los consejeros (LSC art. 236-241). El Banco de España, vía CIRBE (Circular 1/2013), recibe mensualmente el reporting de los bancos especializados (Sabadell Renting, BBVA Renting, Santander Leasing, ALD Automotive, Arval, Athlon, LeasePlan), con la divergencia potencial entre la clasificación contable del PGC NRV 8 y los criterios prudenciales bancarios, que afecta a los ratios de endeudamiento de los covenants y al rating crediticio. Una empresa mediana con 15 sedes, una flota de 60 vehículos e IT llega a 200-400 contratos de arrendamiento activos cada ejercicio y dedica de 3 a 4 horas por contrato solo a la primera valoración, la clasificación, el IBR y el plan de amortización.

## Denegación de la deducción del gasto por la AEAT (LIS art. 13.4), sanción ICAC al ROAC de 12.001-72.000 EUR, Hecho Relevante a la CNMV por restatement en el IBEX-35 y divergencia CIRBE del Banco de España en los covenants

La sanción AEAT por una contabilización de arrendamientos divergente entre el PGC NRV 8 y la imputación temporal de la LIS art. 13.4 es uno de los riesgos materiales más frecuentes del cierre anual español. Una empresa industrial con 80 millones EUR de facturación y errores sistemáticos en la clasificación entre operativo y financiero de una flota de 60 vehículos de turismo de Sabadell Renting (clasificación operativa contable en la cuota 621 frente a la clasificación financiera fiscal de la LIS art. 13.4, con tabla de amortización del 10% lineal en vehículos de turismo y tope del 16%) puede generar una diferencia de imputación del ejercicio de 200.000-500.000 EUR. La AEAT detecta la divergencia mediante el cruce automático del modelo 200 IS con los asientos PGC inscritos en las cuentas 621 y 174/524 y la reconciliación del modelo 232 de operaciones vinculadas, denegando la deducción del gasto vinculado conforme a la LIS art. 13.4, con sanción del 50-150% del importe defraudado (LGT art. 191-195), intereses del art. 26 LGT al 4,0625% anual y recargo de demora del art. 27 LGT del 5-20%, lo que acumula una sanción total de 100.000-1.200.000 EUR para una empresa mediana.

A esto se suman riesgos paralelos. El ICAC supervisa a los auditores ROAC con sanción grave de 12.001-72.000 EUR y suspensión de 1-3 años del ejercicio ante una auditoría de arrendamientos deficiente por la NIA-ES 540 (estimaciones del IBR) y la NIA-ES 315 (identificación de riesgos). Una opinión de auditoría calificada de las Big-4 (Deloitte, KPMG, EY, PwC) sobre la clasificación de arrendamientos genera un restatement obligatorio (NIC 8.41-49), un nuevo depósito en el Registro Mercantil (LSC art. 254) y, en el IBEX-35, la publicación de un Hecho Relevante a la CNMV con una caída de la cotización media del 15-25% de forma inmediata. El Banco de España, vía CIRBE, recibe el reporting mensual de los bancos especializados con la frecuente divergencia entre la clasificación contable de la empresa en el PGC NRV 8 (operativo) y los criterios prudenciales bancarios (siempre financiación en la CIRBE), que afecta a los ratios de endeudamiento de la empresa frente a los covenants bancarios, al rating crediticio de S&P, Moody's y Fitch y a la restricción de líneas adicionales. Para los grupos IBEX-35 con filiales en LATAM (Telefónica con Telefónica Brasil y Vivo; Iberdrola con Avangrid USA e Iberdrola México; Santander con Santander Brasil; BBVA con BBVA México y Garanti; Repsol con Repsol Sinopec Brazil), la coordinación centralizada de los arrendamientos - consolidación del grupo bajo NIIF 16, reconciliación individual del PGC NRV 8 de las sociedades, DEFR trimestral a la CNMV y CIRBE del Banco de España - es uno de los procesos más técnicos del cierre anual.

## El pipeline de contabilización de arrendamientos español recorre 14 etapas determinadas

A diferencia del modelo alemán estándar (8 etapas con el HGB) o del polaco (10 etapas con la UoR y la Ustawa o CIT), la contabilización de arrendamientos española compliance-first exige 14 etapas porque el sistema regulatorio superpone seis capas obligatorias simultáneas: el PGC RD 1514/2007 NRV 8 (operativo frente a financiero) con las ICAC Resoluciones 1/03/2013 y 30/11/2017; el Reglamento UE 1986/2017 NIIF 16 con el modelo único de arrendatario (grupos cotizados); el cálculo determinístico del Right-of-Use Asset (cuenta 217) y del Lease Liability (cuenta 174/524) por el valor presente de las cuotas; el plan de amortización por el método del tipo de interés efectivo (intereses en la cuenta 662 y amortización lineal en la 681); la generación de los asientos PGC mensuales por categoría de bien; la conciliación de la imputación temporal de la LIS art. 13.4 (separación entre intereses y amortización), la LIS art. 106 de régimen especial del leasing y la tabla de amortización fiscal del RD 634/2015 art. 12-13; la presentación de los modelos 200 IS, 220 de grupos y 232 de operaciones vinculadas y el DEFR trimestral a la CNMV en el IBEX-35; la reconciliación mensual de la CIRBE del Banco de España; y la generación del borrador por LLM de las revelaciones de la NIIF 16.51-60 y de la nota de arrendamientos de la memoria del PGC.

Un escenario concreto: una empresa industrial de Madrid con 80 millones EUR de facturación, 15 sedes (5 oficinas en Madrid, Barcelona y Bilbao y 10 almacenes en provincias), una flota de 60 vehículos de turismo de Sabadell Renting, 25 vehículos comerciales de BBVA Renting, 80 ordenadores de Athlon y maquinaria industrial de 2 líneas de producción a 8 años. El Agente extrae automáticamente los datos contractuales de 250 contratos PDF (plazo, cuotas, opciones de compra, índices CPI, gastos de formalización), clasifica entre operativo y financiero según el PGC NRV 8 con el juicio del Director Financiero (las oficinas de Madrid, 10 años sobre 50 de vida útil, un 20%, operativo en la cuenta 621; la flota de Sabadell, 4 años sobre 6 de vida útil, un 67% y sin opción de compra clara, operativo en la cuenta 621; la maquinaria industrial, 8 años sobre 10 de vida útil, un 80% y con opción de compra al valor residual del 5%, financiero en las cuentas 217 y 174). El IBR se deriva conforme a la jerarquía de la ICAC Resolución 30/11/2017 (Euríbor 12M del 5,25%, spread sectorial industrial mediano de 200 bps y ajustes por plazo y garantía, lo que da un IBR del 7,5% estimado por Tesorería); el Right-of-Use Asset y el Lease Liability se calculan de forma determinística por el valor presente; se genera el plan de amortización por el método del tipo de interés efectivo, los asientos mensuales PGC, la conciliación mensual de la CIRBE del Banco de España con los bancos especializados, la conciliación de la imputación temporal de la LIS art. 13.4 (separando los intereses de la amortización limitada por la tabla fiscal del RD 634/2015), el modelo 200 IS preparado y el borrador por LLM de las revelaciones y de la nota de arrendamientos de la memoria con validación humana antes del auditor Big-4. Tiempo total: 4 horas del Agente y 2 horas de juicio humano, frente a 3-4 días manuales por categoría.

## La conciliación entre el PGC NRV 8, la NIIF 16, la LIS art. 13.4 y la CIRBE evita el restatement

Una empresa cotizada IBEX-35 sin una conciliación estructurada entre el PGC NRV 8 individual, la NIIF 16 consolidada, la LIS art. 13.4 del modelo 200 IS y la CIRBE del Banco de España es receta para un restatement obligatorio (NIC 8.41-49) y un Hecho Relevante a la CNMV. La diferencia práctica entre el criterio NIIF 16 (consolidado) y el PGC NRV 8 (sociedades individuales) puede ser muy material: un mismo arrendamiento clasificado como operativo en el PGC NRV 8 individual aparece en el balance NIIF 16 consolidado como Right-of-Use Asset y Lease Liability. Sin conciliación, el riesgo es que un ajuste del auditor Big-4 detectado antes de emitir la opinión de auditoría genere un restatement posterior al depósito en el Registro Mercantil (LSC art. 254), lo que implica un nuevo depósito, un Hecho Relevante material a la CNMV, una caída de la cotización del 15-25%, una investigación de la CNMV, la responsabilidad de los consejeros (LSC art. 236-241) y una potencial acción judicial de los inversores institucionales.

Por eso la 13ª etapa de decisión es la conciliación previa obligatoria entre cinco niveles ANTES de la aprobación de las CCAA por la Junta General. El Agente compara la contabilización de los arrendamientos NIIF 16 consolidada del grupo y su reconciliación con el PGC NRV 8 de las cuentas individuales, los saldos de las cuentas 217/174/524/621 del PGC, la imputación temporal del modelo 200 IS (LIS art. 13.4) y el reporting CIRBE del Banco de España de los bancos especializados. Cualquier divergencia se marca como excepción y bloquea la aprobación. Solo cuando los cinco niveles son perfectamente coherentes la aprobación avanza al depósito.

## Edge-cases espanoles: bancos especializados, sale and leaseback, contratos LAU, opciones renovacion CPI

Los BANCOS ESPECIALIZADOS en arrendamientos (Sabadell Renting, BBVA Renting, Santander Leasing, ALD Automotive, Arval, Athlon, LeasePlan) generan una doble complejidad: comunican la TIR del contrato (tipo implícito determinable de forma fiable conforme a la ICAC Resolución 30/11/2017) pero clasifican siempre la operación como financiación en la CIRBE del Banco de España, lo que genera una divergencia potencial con la clasificación contable de la empresa en el PGC NRV 8. El Agente concilia trimestralmente el reporting CIRBE con el balance de la empresa con detalle por arrendador. Los CONTRATOS DE SALE AND LEASEBACK del PGC NRV 8 y la ICAC Resolución 1/03/2013 admiten tres escenarios contables (venta real con operativo, venta real con financiero, o no venta como financiación garantizada en la cuenta 170/520), con el criterio determinante de la transferencia del control al comprador conforme a la NIIF 15. La decisión la toman el Director Financiero y el Asesor Jurídico. Los CONTRATOS LAU de la Ley 29/1994, inmuebles en arrendamiento urbano de más de 5 años con cláusula de IPC del INE de referencia anual, obligan a recalcular el Lease Liability y el Right-of-Use Asset en cada actualización, con la imputación contable conforme al tratamiento prospectivo de los ajustes de índice. Los CONTRATOS LAR de la Ley 49/2003, arrendamientos rústicos, tienen una regulación específica. Las OPCIONES DE RENOVACIÓN razonablemente seguras se incluyen en el plazo total para el cálculo del Right-of-Use Asset (un alquiler de 5 años con otros 5 años de renovación por práctica habitual son 10 años para el cálculo); la incertidumbre sobre lo razonablemente seguro exige el juicio humano del Director Financiero conforme a la NIIF 16.18-19 y la ICAC Resolución 30/11/2017.

## Integracion con ecosistema espanol: SAP S/4HANA Spain RE-FX, Sage 200, A3 ERP, Holded, Cegid Quadra y AEAT Sede Electronica

La lógica del Agente se conecta con los ERP de Lease Accounting españoles vía API: [SAP S/4HANA Spain RE-FX](https://www.sap.com/spain/) (IBEX-35 con NIIF 16), [Sage 200 y Sage X3](https://www.sage.com/es-es/) (mediana empresa con NIIF 16 y PGC NRV 8), [A3 ERP y a3con](https://www.a3software.com/), [Holded](https://www.holded.com/), [Cegid Quadra Spain](https://www.cegid.com/es/), Oracle Lease and Finance Management Cloud, Workday Lease y MRI, Visual Lease o LeaseAccelerator. La presentación a la AEAT se hace por la Sede Electrónica con cl@ve PIN o certificado FNMT-RCM (modelos 200/220/232 y 303 de IVA), el DEFR y los Hechos Relevantes a la CNMV, y la CIRBE del Banco de España para los bancos Sabadell Renting, BBVA Renting, Santander Leasing, ALD, Arval y Athlon (por encima de 9.000 EUR), además del Registro Mercantil en Borme.es. Para los grupos IBEX-35 con filiales en LATAM, coordina la NIIF 16, la LSC art. 42-49, la reconciliación del PGC NRV 8 y el cumplimiento ante ICAC, AEAT, CNMV, Banco de España y las Big-4 con la NIA-ES.

--- Agente de Management Reporting ---
> Calcula KPIs centrales (EBITDA, Working Capital, DSO, DPO), consolida datos de diferentes fuentes, reconoce anomalías.

Los equipos de Finance dedican según estimaciones recientes unas 300 horas anuales a trabajo de reporting manual - tiempo que no fluye ni en análisis ni en preparación de decisiones (fuente: Float Financial, 2025). El cuello de botella del Management Reporting no está en la interpretación de los indicadores. Está en la consolidación que precede a toda interpretación.

## La consolidación consume el tiempo que falta para el análisis

Un cierre mensual típico en la mediana empresa tarda de seis a diez días laborables. Después comienza el trabajo real del controller: consolidar datos de contabilidad financiera, controlling, tesorería y sistemas operativos, ejecutar eliminaciones, calcular KPIs, construir comparativas con el mes y año anteriores. Solo cuando esta base está lista puede actualizarse el cockpit del CFO.

En la práctica esto significa: las cifras son técnicamente correctas el quinto día laborable - pero el Board Deck no está disponible hasta el octavo o noveno. No porque el análisis sea complejo, sino porque tres días se pierden en la consolidación manual de exportaciones Excel, extracciones ERP e informes de controlling. Cada ciclo de reporting repite el mismo esfuerzo porque la lógica de consolidación no existe en ningún lugar como proceso reutilizable.

## El cálculo de KPIs basado en reglas acorta el ciclo en días

EBITDA, Working Capital, DSO, DPO y Cash Conversion Cycle siguen fórmulas definidas. No hay margen de interpretación en la cuestión de cómo se calcula el DSO - solo en la cuestión de qué significa un DSO creciente para el negocio. Exactamente aquí interviene el [Decision Layer](/es/decision-layer/).

El agente de Management Reporting asume la primera categoría por completo: obtiene los valores consolidados de contabilidad financiera y controlling, aplica las fórmulas de cálculo registradas y actualiza el dashboard automáticamente en cuanto el cierre mensual se marca como completado. La fuente de datos, la fórmula aplicada y el resultado se documentan para cada KPI - reproducible y auditable.

Las empresas que automatizan su consolidación informan de una reducción del ciclo close-to-report del 50 por ciento (fuente: Deloitte CFO Signals Survey, H4 2025). De ocho días pasan a cuatro. De un proceso de reporting reactivo surge un ritmo en el que el consejo puede confiar.

## La detección de anomalías convierte el reporting en proactivo

La información más valiosa de un informe mensual no es la confirmación de que todo va según el plan. Es la identificación temprana de desviaciones antes de que requieran explicación en el próximo informe trimestral.

El agente compara cada KPI calculado con bandas históricas y valores esperados estadísticos. Si el DSO sube 12 días o el Working Capital muestra un salto fuera de la norma estacional, se señala - no como alarma, sino como propuesta de comentario con datos de contexto. El controller recibe un borrador que nombra la anomalía, sitúa el curso histórico y deriva posibles causas de los datos fuente.

Esto cambia fundamentalmente el rol del controller: en lugar de buscar cifras que podrían necesitar explicación, arranca con una lista priorizada e invierte su tiempo en el análisis de causas.

## El narrativo estratégico permanece en el CFO

Lo que significa un Cash Conversion Cycle creciente para las negociaciones con proveedores del próximo trimestre, qué evolución de KPIs requiere explicación especial en el informe de gestión, cómo contextualizar las cifras ante el consejo de supervisión - esas son decisiones que presuponen conocimiento del negocio, experiencia sectorial y juicio estratégico.

El Decision Layer traza aquí un límite claro. Siete de los ocho pasos de decisión del proceso de reporting funcionan basados en reglas o con soporte de IA. El octavo - la interpretación estratégica - permanece en el humano. No como concesión, sino como decisión arquitectónica: un CFO que construye su Board Deck a partir de un borrador preparado con KPIs documentados y anomalías señaladas toma mejores decisiones que uno que dedica la primera mitad de su tiempo a la consolidación de datos.

## Lo que cambia tras la implantación

Un escenario concreto: una empresa industrial con cuatro unidades de negocio, reporting consolidado a la holding y reunión mensual del consejo el décimo día laborable. Antes de la automatización, el Board Deck terminado estaba disponible como pronto el octavo día laborable - con correcciones regulares hasta la víspera de la reunión.

Tras la implantación del agente de Management Reporting, los KPIs consolidados están disponibles el tercer día laborable. Las anomalías están señaladas y precomentadas. El responsable de controlling utiliza el cuarto y quinto día laborable para la contextualización estratégica y el narrativo - no para la consolidación. El sexto día laborable el Deck llega al CFO. Cuatro días de margen en lugar de dos días de presión.

--- Agente de Ejecución de Pagos ---
> Ejecuta pagos en lote mediante SEPA Credit Transfer, Iberpay Instant, Bizum y AEB Norma 34, con doble aprobación y de forma 100% determinista.

La ejecución de pagos en España es un proceso de alta densidad regulatoria que combina derecho civil, normativa SEPA UE, regulación fiscal AEAT, prevención de blanqueo de capitales y protección de datos. El Código Civil art. 1156-1213 establece el régimen sustantivo del pago como modo de extinción de obligaciones, exigiendo entrega efectiva al acreedor o consignación judicial para liberar al deudor. El Reglamento UE 260/2012 fija el formato SEPA pain.001 obligatorio para todas las transferencias en EUR dentro de la zona SEPA, ampliado por el Reglamento UE 2024/886 que obliga desde el 9 de enero de 2025 a la emisión de SEPA Instant Credit Transfer sin sobrecoste y desde el 9 de octubre de 2025 a su recepción. La Ley 16/2009 de servicios de pago, transposición de PSD2, regula los derechos del ordenante y la responsabilidad del proveedor de servicios de pago. La Ley 10/2010 PBC/FT obliga a verificación de beneficiarios y reporte SEPBLAC en casos sospechosos. El RGPD y la LOPDGDD regulan el tratamiento de datos bancarios. Y la AEAT cruza diariamente los pagos con el SII (RD 1624/1992 art. 62.6) para detectar divergencias en IVA y retenciones IRPF. Cada pago mal ejecutado puede activar simultáneamente requerimiento AEAT, sanción AEPD por fuga de datos, reporte SEPBLAC adicional y observación en auditoría obligatoria.

## Sanción AEAT del 50-150% por retraso en el modelo 303, divergencia CIRBE con el Banco de España y sanción AEPD de hasta el 4% de la facturación por violación de datos de beneficiarios

La sanción AEAT por modelo 303 IVA presentado fuera de plazo o con divergencia frente al SII es uno de los riesgos materiales más frecuentes del ciclo de pagos español. La AEAT regulariza con sanción del 50% del importe defraudado en infracción leve, 75% en grave y hasta 150% en muy grave conforme LGT art. 191-195, más intereses de demora calculados al tipo de interés legal del dinero incrementado en un 25%. Para una empresa media con 80 millones EUR de facturación y un ajuste de 200.000 EUR por divergencia entre asientos de pago en cuentas 410X y registros SII, la exposición fiscal alcanza 100.000-300.000 EUR antes de intereses. Si la AEAT considera que existe ocultación conforme art. 184.2 LGT puede elevar la calificación a muy grave incluso en infracciones formalmente leves.

A esto se suman riesgos paralelos. La divergencia frente a CIRBE Banco de España por reporte mensual incorrecto de posiciones >9.000 EUR puede activar requerimiento de la Dirección General de Supervisión con sanciones de hasta 1 millón EUR conforme Ley 10/2014 (la responsabilidad principal es bancaria pero inconsistencias del ERP empresarial trasladan fricción al banco con impacto reputacional). Una sanción AEPD por violación de datos bancarios de beneficiarios alcanza hasta el 4% de la facturación anual mundial o 20 millones EUR conforme RGPD art. 83.5, con resoluciones publicadas regularmente entre 100.000 y 1.000.000 EUR para casos del sector financiero español. Y la inspección ITSS por pagos de nómina sin retención IRPF correcta o pagos a falsos autónomos puede activar regularización masiva con sanción 6.251-187.515 EUR por infracción muy grave conforme RDLeg 5/2000 LISOS.

## La ejecución de pagos española recorre 15 etapas determinadas, no 8

A diferencia del modelo alemán estándar (8 etapas) o del modelo SEPA puro (10 etapas), la ejecución de pagos española compliance-first exige 15 etapas determinadas porque el sistema regulatorio superpone cinco capas obligatorias simultáneas: selección de facturas vencidas conforme Código Civil art. 1100 (mora del deudor desde fecha exigibilidad), validación IBAN ES con checksum mod-97 ISO 7064 según Reglamento UE 260/2012, verificación del beneficiario contra listas PBC/FT UE/OFAC/SEPBLAC conforme Ley 10/2010, determinación de canal óptimo entre SEPA SCT estándar, SEPA Inst Iberpay (obligatorio desde 9/1/2025), Bizum (hasta 1.000 EUR vía P2P/B2C) o transferencia internacional SWIFT, aplicación de retención IRPF modelo 111 (15% profesionales general, 7% inicio actividad) o modelo 115 (19% alquileres urbanos) conforme RD 439/2007, optimización del descuento por pronto pago contra coste oportunidad de capital, verificación del umbral CIRBE Banco de España (9.000 EUR posición) por Circular 1/2013, agrupación de pagos por beneficiario y formación del fichero pain.001 conforme Norma AEB 34, generación de fichero SEPA Inst para pagos urgentes vía Iberpay ISS, detección de duplicados contra historial de 24 meses, validación de saldo y reserva de liquidez vía conciliación AEB Norma 43 PSD2, aprobación humana del lote por Tesorería conforme principio cuatro ojos SCIIF (recomendación CNMV), conciliación del pago ejecutado con asiento contable PGC RD 1514/2007 y registro SII RD 1624/1992, y documentación del audit trail RGPD con plazo de conservación 6 años (Código Comercio art. 30).

Un escenario concreto: empresa industrial mediana en Valencia con 500 facturas semanales de proveedores, 80 millones EUR de facturación anual, sujeta a SII por superar el umbral de 6 millones EUR y obligada a auditoría por superar dos de tres umbrales Ley 22/2015. Cada lote semanal el Agente identifica 387 facturas vencidas en cuentas 410X, valida 387 IBAN ES con checksum mod-97 detectando 4 errores tipográficos, cruza 387 beneficiarios contra listas PBC/FT UE actualizadas diariamente, determina canal: 312 SCT estándar, 67 SCT Inst Iberpay (descuentos pronto pago en último día), 5 SWIFT (proveedores Reino Unido post-Brexit) y 3 Bizum (devoluciones B2C bajo 1.000 EUR), aplica 47 retenciones modelo 111 (43 al 15%, 4 al 7%) y 8 retenciones modelo 115 alquileres, optimiza descuento en 23 facturas con TAE >5% generando ahorro 18.700 EUR, verifica CIRBE en 5 proveedores con posición >50.000 EUR, agrupa pagos en 312 transferencias SCT en 1 fichero pain.001 Norma AEB 34 reduciendo comisiones 25%, detecta 1 duplicado contra historial 24 meses, valida saldo en 4 cuentas con conciliación AEB Norma 43 PSD2, escala lote a Tesorería para aprobación cuatro ojos (preparador Contabilidad, aprobador CFO), ejecuta el envío vía BBVA Net Cash, Santander One Pay y CaixaBank Now Empresas, concilia movimientos AEB 43 con asientos PGC y envía A4 SII a AEAT.

## Conciliación previa con asientos contables y SII evita requerimiento AEAT y sanción 50-150%

Un lote de pagos sin conciliación previa con asientos contables y SII es receta para requerimiento AEAT inmediato. La empresa ejecuta una transferencia el día 1 de enero por 121.000 EUR a un proveedor (importe con IVA 21%), el asiento contable se registra correctamente con cuenta 410X 121.000 EUR y desglose IVA 472X 21.000 EUR, pero el envío SII se procesa con tipo IVA 10% por error en el master del proveedor del ERP - la AEAT cruza automáticamente y detecta divergencia de 11.000 EUR de IVA, emite requerimiento con plazo 10 días y sanción potencial del 50% sobre el diferencial conforme LGT art. 191. Para una empresa con 50 facturas mensuales de errores similares la exposición mensual alcanza 27.500 EUR de sanción más intereses, escalable a 82.500 EUR si se considera infracción grave por reincidencia.

Por eso la 14a etapa de decisión es conciliación previa obligatoria del pago ejecutado con el registro contable y el SII ANTES de marcar la operación como cerrada. El Agente integra los XML SII enviados a AEAT (formato A1 facturas emitidas, A2 facturas recibidas, A3 bienes inversión, A4 cobros y pagos en metálico, A5 operaciones intracomunitarias) y los compara línea a línea con los asientos contables PGC RD 1514/2007 generados por el lote de pagos. Pagos ejecutados sin asiento de pago en cuenta 572 se marcan como pendientes de registro contable. Asientos de pago sin entrada SII se marcan como pendientes de envío. Movimientos AEB 43 sin contrapartida contable se escalan a excepción. Solo cuando los tres niveles (banco AEB 43, contabilidad PGC, fiscal SII) son perfectamente coherentes el lote progresa al cierre del período. Esta conciliación tres niveles es lo que permite presentar el modelo 303 IVA con riesgo cero de divergencia.

## Edge-cases españoles: retenciones modelo 111/115, paraisos fiscales y operaciones vinculadas

Casos especiales como retenciones IRPF, pagos a paraisos fiscales (Ley 36/2006) y operaciones vinculadas (LIS art. 18) parecen complejos pero son determinados por norma española. La retención modelo 111 al 15% sobre actividades profesionales aplica a abogados, asesores, arquitectos, consultores y formadores conforme RD 439/2007 art. 95, con reducción al 7% en los 3 primeros años de actividad si el profesional comunica vía modelo 037/036. La retención modelo 115 al 19% sobre alquileres de inmuebles urbanos aplica al arrendatario empresa por local, oficina, nave o garaje empresarial conforme art. 100.2 RD 439/2007, con exención para alquileres del mismo arrendador <900 EUR/año. Los pagos a paraisos fiscales (RD 1080/1991 y DA 1ª de la Ley 36/2006) requieren documentación específica y limitan deducibilidad fiscal LIS art. 15.k. Las operaciones vinculadas LIS art. 18 con sociedades del grupo requieren documentación modelo 232 si superan 100.000 EUR/contraparte/año.

El Agente identifica cada operación mediante reglas determinadas y aplica el tratamiento correspondiente: tipo de retención correcto (15%/7%/19%) con cálculo automático, marcado especial para pagos a paraisos fiscales con escalado a Dirección Fiscal, identificación de contrapartes vinculadas vía modelo 232 y escalado de operaciones sin precedente claro a juicio humano cuando el importe es material (>100.000 EUR sin precedente).

## Integración con ecosistema español: Sage, A3, Holded, SAP, BBVA, Santander, CaixaBank, Iberpay

La lógica del Agente se conecta con los principales sistemas contables y bancarios del mercado español vía API: [Sage 200 y Sage Despachos Connected](https://www.sage.com/es-es/) (lider PYME con módulo Tesorería y PSD2 a más de 30 entidades), [A3 Software](https://www.a3software.com/) (a3con, a3asesor y a3ERP, despachos con integración AEAT y bancos), [Holded](https://www.holded.com/) (cloud autónomos y PYME con Open Banking), [Cegid Quadra](https://www.cegid.com/es/) (mediana empresa industrial), SAP S/4HANA Spain Localization con SEPA Manager y Bank Communication Management (IBEX-35), Microsoft Dynamics 365 Business Central Spain y Oracle Fusion Cloud ERP Spain Localization. La conexión bancaria multi-entidad opera vía Open Banking PSD2 (BBVA Open Platform, Santander Open Bank API, CaixaBank Open API, Sabadell Hub, Bankinter API) o canales corporativos (BBVA Net Cash, Santander One Pay FX, CaixaBank Now Empresas, ING Direct Empresas). El sistema interbancario Iberpay procesa SEPA SCT vía SNCE con liquidación T+1 y SEPA Inst vía ISS en menos de 10 segundos 24/7/365. Bizum se integra vía API empresarial de los bancos participantes. El reporte CIRBE Banco de España se alimenta desde el ERP. Para grupos IBEX-35 con filiales LATAM (Telefónica, Iberdrola, Santander, BBVA, ACS, Inditex), el Agente coordina pagos centralizados con cash pooling notional o efectivo, manteniendo cumplimiento simultáneo de Banco de España CIRBE, AEAT modelo 303 SII, AEPD RGPD, AEB Norma 34/43 y reportes EMIR.

--- Agente de Tráfico de Pagos ---
> Determina el formato de pago (SEPA, SWIFT), crea archivos SEPA-XML, los transmite al banco.

Un pago está aprobado, el IBAN no es correcto, el archivo es rechazado. Tres días después el proveedor pregunta por su dinero. Este escenario cuesta no solo liquidez, sino confianza. En el tráfico de pagos europeo, el fraude en transferencias sumó según el BCE y la EBA 2.200 millones EUR en 2024 - y los errores de formato, datos de destinatario incorrectos o escalaciones tardías ante rechazos se suman adicionalmente. La última milla entre la aprobación y la transmisión bancaria merece la misma disciplina de proceso que la propia aprobación.

## Entre la aprobación y la transmisión bancaria surgen los errores más caros

El agente de ejecución de pagos decide qué se paga y cuándo. Pero la cuestión de cómo llega técnicamente el pago al banco queda abierta. Exactamente aquí interviene el agente de tráfico de pagos. Determina el formato - SEPA, SWIFT o cheque - a partir de los datos maestros del destinatario, genera el archivo pain.001 y lo transmite vía EBICS o API. Suena a pura técnica. En la práctica, los pagos no fracasan por la aprobación, sino por códigos BIC incorrectos, campos obligatorios faltantes o certificados caducados. Un equipo de tesorería que procesa 400 pagos diarios no puede verificar estos errores individualmente. Un agente basado en reglas sí.

## Diez pasos de decisión sustituyen el workaround manual

El [Decision Layer](/es/decision-layer/) descompone la vía de pago en diez pasos: selección de formato, validación de IBAN y destinatario, control de pagos duplicados, cribado de listas de sanciones, comprobación de la obligación de declaración AWV, generación XML, transmisión bancaria, procesamiento de respuestas, escalación ante fallo y aprobación de cuatro ojos para pagos individuales elevados. Nueve de estos pasos son completamente basados en reglas. El formato de pago se deriva de los datos maestros del destinatario, la validación pain.001 sigue el estándar SEPA, la transmisión bancaria es un handshake técnico, y los mensajes de error se analizan automáticamente y se escalan al responsable correspondiente. Solo en pagos individuales por encima del umbral configurado interviene el humano. Este patrón - reglamento para la masa, control humano para el riesgo - es la firma de un Decision Layer de nivel 1.

## Verification of Payee cambia fundamentalmente los requisitos

Desde octubre de 2025, todas las entidades de crédito del EEE están obligadas a realizar una verificación del destinatario antes de cada transferencia SEPA. El nombre indicado se coteja con el titular real de la cuenta. Para el agente de tráfico de pagos esto significa: cada pago saliente pasa por un paso de validación adicional antes de llegar al banco. Las discrepancias entre datos maestros y titular de la cuenta se detectan y documentan antes de que fluya dinero. Los bancos informan que la verificación reforzada de sanciones bajo SEPA Instant genera entre un 30 y un 50 por ciento más de transacciones señaladas. Un agente que procesa estas respuestas en tiempo real evita que pagos válidos se queden atascados en la cola de verificación.

## El humano decide allí donde la automatización generaría riesgo

La aprobación de cuatro ojos en pagos individuales elevados no es una concesión a la desconfianza en la tecnología. Es un requisito del sistema de control interno que el Decision Layer mantiene deliberadamente como decisión humana. Porque ante un pago individual inusual de 50.000 o 100.000 EUR, la conformidad con las reglas no basta - se necesita juicio comercial. La normativa contable exige que cada pago como operación comercial se documente de forma trazable. El agente proporciona esta documentación automáticamente: formato de pago, marca temporal de transmisión, respuesta bancaria y, en pagos individuales, la marca temporal de aprobación con la persona que aprueba. El protocolo de tráfico de pagos surge como subproducto del proceso, no como obligación retroactiva.

--- Agente de Cálculo de Nóminas ---
> Cálculo Bruto-Neto por empleado: Estatuto Trabajadores art. 26-29, IRPF Ley 35/2006, cotizaciones TRLGSS 8/2015 y embargos LEC art. 607 - revisable PGC con audit-trail completo.

El cálculo nóminas español es la aritmética mensual del área Payroll-Finance. El salario base está en el contrato individual y la tabla salarial vigente del convenio colectivo aplicable REGCON. Los complementos retributivos (antigüedad por trienios y quinquenios al 5% acumulables, plus convenio, plus puesto trabajo certificado evaluación riesgos, plus nocturnidad 25% jornada 22:00-06:00 conforme art. 36 ET) están regulados por convenio sectorial. Las horas extras se retribuyen según convenio - estructurales 75% adicional, no estructurales 175% - con límite 80/año art. 35 ET. Las cotizaciones del trabajador son fijas: 4,70% por contingencias comunes, 1,55% por desempleo (sobre la base ampliada con horas extras), 0,10% por Formación Profesional y 0,12% por el MEI (Mecanismo de Equidad Intergeneracional, desde 2023), lo que suma un 6,47% típico sobre la base de contingencias, respetando la base máxima 2026 de ~4.495 EUR/mes por grupo de cotización. La retención de IRPF sigue la tabla progresiva 19/24/30/37/45/47% modulada por CCAA, con el mínimo personal de 5.550 EUR y los mínimos por descendientes, ascendientes y discapacidad. Los embargos están limitados por escala progresiva LEC art. 607 con SMI íntegro inembargable. Ningún paso requiere decisión discrecional. Aun así, en departamentos de nóminas típicos surgen recurrentemente correcciones por ciclo de liquidación - y desde la digitalización del Sistema RED Cret@ y la AEAT Sede Electrónica cada corrección activa cascada normativa en cuatro frentes: TGSS, AEAT, ITSS y trabajador via Juzgado Social.

## Las correcciones de nómina cuestan ~281 USD por incidencia, más la sanción ITSS LISOS de hasta 187.515 EUR

La American Payroll Association cuantifica el coste directo medio de una corrección nómina en ~281 USD por incidencia. Pero el daño real para una operación española va mucho más allá del cálculo aritmético. Un recibo individual justificativo (RIJ) erróneo es lo primero que un trabajador cuestiona ante su empresario - cuando el importe neto no coincide con el contrato individual o el convenio colectivo aplicable, el trabajador tiene 1 año de prescripción art. 59.2 ET para presentar demanda monitoria en el Juzgado Social que - de prosperar - obliga a la empresa a abonar la diferencia más intereses 10% anual art. 29.3 ET y costas judiciales.

Para el CFO de una operación española mediana (300-1.000 empleados), cada corrección nómina retroactiva activa cascada normativa: regularización fichero CRA Cret@ Sistema RED TGSS via fichero FAN con recargo demora 5-20% según retraso, regularización modelo 111 trimestral AEAT con sanción potencial 50-150% importe defraudado LGT art. 191-195, generación nuevo Recibo Individual Justificativo Orden ESS/2098/2014 con concepto retroactivo y firma electrónica, asiento contable corrector PGC RD 1514/2007 entre cuentas 640/642/4751/476/465. La sanción ITSS por infracciones LISOS art. 8 transgresión derechos trabajadores escala leve 626-1.625 EUR (errores formales) hasta muy grave 6.251-187.515 EUR (impago salario intencional, ocultación, falsificación recibos). La sanción específica art. 8.12 LISOS por incumplimiento registro retributivo desglosado por sexo o auditoría retributiva en empresas >50 empleados con plan igualdad RD 902/2020 alcanza también 187.515 EUR.

A esto se añade la dimensión RGPD: los datos retributivos son datos personales conforme al art. 88 RGPD y a la LOPDGDD; combinados con datos sindicales (la cuota sindical en deducciones) o con datos de baja por IT pasan a categoría especial del RGPD art. 9, con sanción AEPD de hasta el 4% de la facturación mundial o 20 millones EUR conforme al art. 83.5. Una empresa con 80 millones EUR facturación enfrenta exposición potencial 3,2 millones EUR si hay tratamiento sistemáticamente erróneo datos empleados en libros nóminas digitalizados.

## La nómina española recorre 16 etapas determinísticas

A diferencia del modelo alemán estándar (12 etapas con ELStAM y LSt-AU) o del polaco (16 etapas con ZUS DRA y PIT-11), la nómina española compliance-first exige 16 etapas determinísticas porque el sistema regulatorio superpone seis capas obligatorias simultáneas: identificación del salario base contractual y de la categoría profesional del convenio; aplicación de los complementos de convenio (antigüedad por trienios y quinquenios, plus de convenio, plus de puesto de trabajo) con la tabla REGCON vigente; cálculo de los componentes variables (horas extras estructurales y no estructurales, plus de nocturnidad del 25%, festivos del calendario laboral) con los datos del control horario certificado del RD-ley 8/2019; prorrateo de las pagas extraordinarias del art. 31 ET en 14/12 o 15/12 según el convenio y el contrato individual; cálculo de la base de contingencias comunes respetando la base máxima 2026 de ~4.495 EUR/mes por grupo de cotización 1-11; cálculo de la cotización del trabajador, un 6,47% típico que suma el 4,70% por contingencias, el 1,55% por desempleo, el 0,10% por FP y el 0,12% por el MEI; cálculo de la retención de IRPF progresiva con el mínimo personal de 5.550 EUR y la tabla 19/24/30/37/45/47% modulada por CCAA; valoración de las retribuciones en especie del art. 42-43 LIRPF (vehículo de empresa al 20%, vivienda al 10% catastral, seguro médico de 500 EUR exento, cheques restaurante de 11 EUR); gestión de la IT delegada y el pago directo del INSS con la base reguladora de los últimos 6 meses; aplicación de los embargos LEC art. 607 con su escala progresiva inembargable hasta el SMI; demás deducciones autorizadas (cuota sindical, anticipos, préstamos de la empresa) con su orden de prelación; cálculo del neto a percibir verificado matemáticamente; generación del Recibo Individual Justificativo conforme a la Orden ESS/2098/2014; asiento contable PGC RD 1514/2007 con las cuentas 640/642/4751/476/465; y plausibilización contra el mes anterior con umbral del 10% y escalado humano para revisar la causa.

Un escenario concreto: empresa industrial mediana en Valencia con 60 millones EUR facturación, 380 empleados, convenio colectivo Industria Química vigente con 95 conceptos diferenciados. Cada mes el Agente procesa nómina con 380 trabajadores agrupados en 7 grupos cotización (45 grupo 1 ingenieros licenciados, 110 grupo 2 ingenieros técnicos, 95 grupo 7 administrativos, 130 grupo 8-11 oficiales y peones), 32 trabajadores con vehículo empresa, 18 con seguro médico familiar, 12 trabajadores en IT contingencias comunes, 8 trabajadores con embargo judicial concurrente (3 por alimentos, de prioridad absoluta, y 5 ordinarios con escala progresiva) y 5 jubilaciones parciales con contrato de relevo. El Agente aplica el convenio de Industria Química con la tabla salarial vigente, calcula la antigüedad por trienios y quinquenios trabajador por trabajador (algunos con 35 años de antigüedad acumulada al 40% sobre el salario base), aplica el plus de convenio junto con el plus de toxicidad por el puesto certificado en la evaluación de riesgos, computa las horas extras estructurales certificadas por el control horario, prorratea 14 pagas anuales en 12 mensualidades (factor 14/12), calcula la base de contingencias respetando la base máxima por grupo, retiene la cotización del trabajador del 6,47% y la retención de IRPF según la tabla de la CCAA de la Comunidad Valenciana (9,5% en el tramo bajo), valora las retribuciones en especie del art. 42-43 LIRPF, aplica los embargos LEC art. 607 (8 trabajadores con escala progresiva, alimentos sin límite por el art. 608), genera 380 Recibos Individuales Justificativos firmados electrónicamente, contabiliza asiento PGC consolidado, plausibiliza detectando 4 desviaciones >10% (escala a Director RRHH para revisión causa), prepara fichero SEPA pago domiciliación bancaria. Tiempo total: 5-6 horas vs 4-5 días manuales.

## La aplicación correcta del convenio colectivo evita reclamación Juzgado Social art. 59.2 ET

Una nómina española sin aplicación correcta del convenio colectivo vigente REGCON es receta para reclamación cantidad ante Juzgado Social. La empresa registra salario base 1.800 EUR/mes según tabla salarial obsoleta del convenio anterior (vigencia 2024) cuando ya está firmado nuevo convenio con efecto 1 enero 2026 e incremento 3,5% (1.863 EUR/mes nueva tabla). El trabajador detecta la diferencia tras una consulta sindical o su propia asesoría laboral y presenta una demanda monitoria reclamando 63 EUR/mes de diferencia × 6 meses ya pagados con la tabla anterior, es decir, 378 EUR de atrasos más los intereses del 10% anual del art. 29.3 ET. La sentencia favorable obliga a la empresa a abonar la diferencia, los intereses y las costas judiciales (normalmente 200-500 EUR adicionales).

Por eso la 1ª y la 2ª etapas de decisión son la identificación del salario base correcto y la aplicación de los complementos de convenio actualizados ANTES del cálculo posterior. El Agente consulta automáticamente REGCON al inicio de cada nómina mensual para verificar si hay una nueva versión del convenio publicada con efecto retroactivo, descarga las tablas salariales vigentes por categoría profesional y grupo de cotización, calcula la antigüedad real trabajador por trabajador con el histórico de fechas de alta y aplica el plus de convenio y el plus de puesto de trabajo según el puesto efectivo. Cuando hay convenio retroactivo (firma abril con efecto enero) el Agente regulariza automáticamente meses anteriores integrando atrasos en nómina del mes firma como concepto separado, recalcula base contingencias retroactiva (TGSS admite ficheros CRA Cret@ retroactivos via FAN), regulariza retención IRPF anual en modelo 100 perceptor año siguiente. Para empresa con 500 trabajadores y firma convenio retroactivo 4 meses con incremento medio 3%, el Agente calcula automáticamente diferencias salariales (~150.000 EUR atrasos), genera Recibos Individuales Justificativos complementarios, regulariza fichero CRA TGSS y modelo 111 AEAT correspondiente al período retroactivo en una sola ejecución coherente.

## Plausibilización contra mes anterior detecta errores silenciosos antes de pago SEPA

Basado en reglas no es libre de errores: tipo por hora mal registrado, cambio convenio retroactivo no aplicado, plus puesto trabajo no integrado tras cambio puesto, complemento por antigüedad no actualizado tras quinquenio cumplido son las causas más frecuentes de correcciones nómina en operación española. Por eso la 15ª etapa decisión contiene una verificación de plausibilidad automática contra mes anterior con umbral configurable.

El Agente compara cada nómina con el mes anterior trabajador por trabajador. Si el importe neto se desvía más del 10% sin causa documentada (paga extraordinaria, regularización convenio retroactivo, finiquito, modificación condiciones art. 41 ET, cambio circunstancias familiares modelo 145), la nómina se marca como excepción para revisión humana y bloquea ejecución pago SEPA. El responsable RRHH ve la vía exacta de cálculo - qué partida ha cambiado y por qué surgió la desviación. Este es el único punto del proceso donde interviene un humano (decider H), no para calcular sino para evaluar una anomalía. Las demás 15 etapas son determinísticas (decider R) sobre la base del ET, la LGSS, la LIRPF, la LEC y el convenio aplicable.

## Integración con ecosistema español: Sage NominaPlus, A3 Nóminas, Cegid Visma Meta4, SAP HCM Spain

La lógica del Agente se conecta con los principales sistemas de nóminas españoles vía API: [Sage NominaPlus y Sage 200 Nómina](https://www.sage.com/es-es/) (líder en PYME, con Sistema RED y AEAT certificado y el módulo de embargos LEC art. 607 integrado), [A3 Nóminas Wolters Kluwer](https://www.a3software.com/) (despachos profesionales con presentación masiva multicliente y motor de cálculo bruto-neto), [Cegid Visma Meta4](https://www.cegid.com/es/) (HCM cloud para mediana y gran empresa con motor Spanish Payroll y gestión automatizada de convenios), [Holded](https://www.holded.com/) (cloud para autónomos y PYME con generación del RIJ en PDF conforme al ET art. 29), SAP HCM Spain (PY-ES) y SAP SuccessFactors Spain para multinacionales, Workday HCM Spain para los grupos IBEX-35 (Telefónica, Iberdrola, Santander, BBVA, Inditex), Bizneo HR, Personio Spain y Factorial para PYME, y Oracle HCM Cloud Spain para mediana y gran empresa. La presentación telemática a la TGSS se hace por el Sistema RED Online (con autorización RED y certificado SILCON/ACA) y a la AEAT por la Sede Electrónica (con cl@ve PIN o certificado FNMT-RCM/DNIe), con consulta automática de los convenios en REGCON, la tabla CNAE de AT/EP y las bases máximas de los grupos de cotización 1-11. Para los grupos IBEX-35 con filiales en LATAM, el Agente coordina el cálculo centralizado multiempresa con la consolidación del grupo a efectos del IS (modelo 220) y el cumplimiento simultáneo ante TGSS, AEAT, ITSS, INSS, SEPE y AEPD, calculando la nómina localmente conforme al Estatuto de los Trabajadores y emitiendo los reportes IFRS para la matriz.

--- Agente Correcciones Nóminas ---
> Correcciones retroactivas nóminas: rectificación TC1/TC2 Sistema RED, ajustes IRPF Modelo 111 y regularización ET art. 29 - con doble validación y recargos TGSS art. 28 LGSS evitados.

Las correcciones de nóminas no cuestan dinero a las empresas por la diferencia en sí, sino por el esfuerzo de recalcularlas correctamente. El EY Global Payroll Survey 2022 documenta: uno de cada cinco ciclos de nómina contiene errores; por empleado a tiempo completo se registran 29 semanas al año dedicadas exclusivamente a corrección de errores. En una empresa con 1.000 empleados, el esfuerzo directo de corrección suma rápidamente importes de seis cifras en USD anuales. El agente de corrección de nóminas asume el cálculo basado en reglas incluyendo los efectos fiscales y de seguridad social. La aprobación permanece en el humano.

## Una de cada cinco nóminas contiene errores

Las causas son diversas y frecuentemente sistémicas: subidas salariales retroactivas, horas extra comunicadas a posteriori, liquidaciones de gastos de viaje presentadas con retraso, cambios de clase fiscal erróneos. El EY Global Payroll Survey documenta que uno de cada cinco ciclos de nómina es erróneo. Cada error individual desencadena una cadena de recálculos - diferencia bruta, impuesto sobre la renta, recargo de solidaridad, impuesto eclesiástico, seguro de enfermedad, pensiones, dependencia y desempleo.

Un escenario concreto: una subida salarial se acuerda con efecto retroactivo a enero, la información llega a nóminas en abril. Para tres meses deben recalcularse todos los componentes retributivos - para cada empleado afectado individualmente, porque clase fiscal, deducciones y obligación de cotización son diferentes. Con 200 empleados afectados surgen 200 correcciones individuales con diez pasos de cálculo cada una.

## El recálculo manual bloquea los recursos más caros

El problema real no es la corrección en sí. La aritmética es inequívoca: cálculo nuevo menos cálculo antiguo da la diferencia bruta. Los efectos fiscales y de seguridad social siguen reglas fijas de la legislación tributaria y de seguridad social. Lo que realmente pesa sobre las empresas es el tiempo de especialistas cualificados.

Los contables de nóminas con conocimientos especializados en derecho fiscal y de seguridad social pasan horas ejecutando cálculos que un reglamento puede realizar en segundos. El coste medio por corrección individual asciende a 281 dólares (unos 258 EUR) en costes directos (EY). En casos complejos como bajas por enfermedad no registradas, el importe sube a más de 700 dólares (unos 640 EUR). Simultáneamente, estos especialistas faltan para tareas que realmente requieren juicio - como la valoración de casos dudosos o la comunicación con empleados afectados.

La contabilidad de nóminas debe planificar al menos dos ciclos de liquidación para procesar las correcciones limpiamente. Durante ese tiempo se acumulan nuevos casos.

## El agente calcula - el humano decide

El [Decision Layer](/es/decision-layer/) descompone cada corrección de nómina en sus pasos de decisión y asigna a cada paso el decisor correcto. Siete de los diez pasos son basados en reglas: identificación de diferencias, período retroactivo, cálculo de corrección, efecto fiscal, corrección de seguridad social, diferencia neta y asiento contable. Estos siguen las normas de cálculo de la legislación tributaria y de seguridad social - sin margen de discrecionalidad, sin necesidad de interpretación.

Dos pasos utilizan soporte de IA a nivel 1: la clasificación de causas sitúa el contexto - se trata de un cambio de convenio, un error de registro o una comunicación retroactiva. La comunicación al empleado prepara una explicación comprensible de la corrección para que el trabajador afectado pueda entender por qué cambia su salario neto.

El décimo paso permanece en el humano: la aprobación por el principio de cuatro ojos. Ningún asiento de corrección abandona el sistema sin verificación y confirmación humana.

## La documentación conforme a normativa contable surge automáticamente

Las correcciones de nóminas son operaciones comerciales. La normativa contable exige que la nómina original permanezca inalterable. Las correcciones se realizan exclusivamente mediante anulación de la antigua y generación de una nueva nómina. El agente genera esta cadena documental automáticamente: nómina original, documento de anulación, nómina corregida - vinculados sin lagunas y documentados de forma resistente a revisión.

Para cada corrección, el Decision Layer registra la cadena de decisión completa: causa con clasificación, período afectado, diferencia bruta, diferencia fiscal, diferencia de seguridad social, diferencia neta, asiento contable resultante así como marca temporal de aprobación y persona que aprueba. En una auditoría fiscal, toda la vía de cálculo está abierta - no como documentación retroactiva, sino como subproducto del proceso mismo.

--- Agente Fiscal Nóminas ---
> Declaraciones fiscales nóminas: modelo 111 mensual/trimestral AEAT, modelo 190 anual, TC1/TC2 SS y fichero CRA Cret@ Sistema RED - evita sanción LGT art. 191-195 50-150% y recargo TGSS.

El cálculo nóminas español es la prueba de estrés mensual del área Payroll-Finance. La TGSS recauda mensualmente cotizaciones vía Sistema RED Online con plazo presentación fichero CRA Cret@ hasta el último día natural del mes - el retraso activa recargo demora art. 28 LGSS escalado entre 5% y 20% según antigüedad más intereses art. 29 LGSS al 4,0625% anual. La AEAT cruza automáticamente las cifras del modelo 111 (rendimientos trabajo trimestral) con el modelo 190 (resumen anual) y las declaraciones perceptor (modelo 100 IRPF) - cualquier divergencia activa requerimiento inmediato con sanción potencial 50-150% del importe defraudado conforme LGT art. 191-195. La ITSS controla cumplimiento normativa laboral mediante actas infracción LISOS con sanciones leves 626-1.625 EUR, graves 1.626-6.250 EUR, muy graves 6.251-187.515 EUR, donde la alta tardía trabajador y la falta cotización ocultando salario son las infracciones más frecuentes. Y las nuevas obligaciones se acumulan: MEI Mecanismo Equidad Intergeneracional 0,7% introducido 2023, solidaridad complementaria 0,92% sobre exceso base máxima introducida 2025, ambos con escalado progresivo hasta 2045. Equipos RRHH con cinco a ocho regímenes simultáneos (régimen general, autónomos, agrarios, hogar, mar, minería carbón, jubilación parcial, contratos formación bonificaciones) dedican habitualmente entre 3 y 5 días por mes solo al cuadre manual cotizaciones SS y retenciones IRPF con asientos PGC.

## La sanción de la ITSS por alta tardía, la del modelo 111 de la AEAT, el recargo de la TGSS y las retenciones forales

La sanción ITSS por infracciones cotización es uno de los riesgos materiales más frecuentes del ciclo nómina español. La LISOS art. 22-23 regula tres tramos: infracción leve 626-1.625 EUR (errores formales sin perjuicio recaudatorio), grave 1.626-6.250 EUR (no comunicación alta dentro 60 días, falta cotización ocultando salario, falsedad datos), muy grave 6.251-187.515 EUR (alta tardía trabajador habitual, transgresión ocultación deliberada cotizaciones, fraude SEPE en prestaciones desempleo). Para una empresa industrial con 220 empleados que regulariza personal externalizado declarado como autónomo cuando debería ser empleado dependiente (caso común en el sector de tecnología y consultoría), la sanción acumulada de la ITSS por varias actas de infracción puede superar los 500.000 EUR, más la regularización retroactiva de cotizaciones de los 4 años de prescripción de la LGSS art. 21, el recargo de demora del 5-20% y los intereses del 4,0625% anual.

A esto se suman riesgos paralelos. La aplicación incorrecta de la retención de IRPF en nóminas con divergencias frente a la declaración del perceptor (el modelo 100 de IRPF que la AEAT cruza con el modelo 190 del retenedor) genera un requerimiento, una liquidación y una sanción del 50-150% (LGT art. 191-195). El recargo de demora de la TGSS (art. 28 LGSS) escala del 5% (retraso de 1 a 3 meses) al 10% (de 3 a 6 meses) y al 20% (más de 6 meses): para una empresa con 1 millón EUR de cotización mensual y un retraso de 4 meses, el recargo sería de 100.000 EUR sin contar los intereses. Los territorios forales (Hacienda Foral Bizkaia, Gipuzkoa, Araba, Navarra) tienen autoliquidaciones territoriales propias con modelos 110-IPT en País Vasco y F-65 Navarra que el agente coordina automáticamente cuando trabajadores residen en territorio foral. Una sanción AEPD por violación datos personales empleados en libros nóminas alcanza hasta 4% facturación anual mundial conforme RGPD art. 83.5, con resoluciones AEPD regularmente entre 50.000 y 500.000 EUR para casos sector empresarial español.

## La nómina española recorre 16 etapas determinadas, no 8

A diferencia del modelo alemán estándar (8 etapas con ELStAM y LSt-AU) o del polaco (10 etapas con ZUS y PIT), la nómina española compliance-first exige 16 etapas determinadas porque el sistema regulatorio superpone seis capas obligatorias simultáneas. Primero verifica el alta laboral en el Sistema RED de la TGSS con el grupo de cotización correcto y el CNAE de la empresa, aplica el convenio colectivo del REGCON (más de 1.400 vigentes) con su plus de convenio y complementos sectoriales, y calcula la base de contingencias comunes respetando las bases máximas de 2026 (~4.495 EUR/mes por grupo de cotización 1-11). Sobre ella determina las cotizaciones empresariales (28,30% de contingencias, 7,05% de desempleo, 0,20% de FOGASA, 0,70% de Formación Profesional, AT/EP del 1,5-7,15% por CNAE individualizado, MEI del 0,7% y solidaridad complementaria del 0,92% sobre el exceso) y la retención de IRPF progresiva con mínimo personal de 5.550 EUR más los de descendientes, ascendientes y discapacidad y la tabla del 19/24/30/37/45/47% modulada por las CCAA. Despues valora las retribuciones en especie del art. 42-43 LIRPF (vehículo de empresa al 20%, vivienda al 10% catastral, seguro médico exento de 500 EUR), gestiona la IT delegada y el pago directo del INSS con base reguladora de los últimos 6 meses, y genera el fichero CRA Cret@ con el CCC de la empresa y el IPF del trabajador, el modelo 111 trimestral con clave A y el modelo 190 anual. Por último concilia de forma cuadruple las cuentas 640/642/4751/476 del PGC con el libro de nóminas, el CRA de la TGSS y las cuotas del modelo 111 de la AEAT, plausibiliza con Confidence Score, escala a un humano ante casos sin precedente y presenta de forma telemática al Sistema RED de la TGSS y a la Sede Electrónica de la AEAT.

Un escenario concreto: empresa industrial mediana en Madrid con 80 millones EUR de facturación, 220 empleados y convenio colectivo de Químicas vigente. Cada mes el Agente procesa la nómina de 220 trabajadores agrupados en 11 grupos de cotización (35 del grupo 1 de ingenieros licenciados, 60 del grupo 2 de ingenieros técnicos, 80 del grupo 7 de administrativos y 45 de los grupos 8-11 de oficiales y peones), de los cuales 18 tienen vehículo de empresa, 12 seguro médico familiar, 8 están en IT por contingencias comunes (4 en los días 1-3 sin pago, 2 en los días 4-15 al 60% de la empresa y 2 a partir del día 16 con pago directo del INSS), 3 en jubilación parcial con contrato de relevo y 5 con contratos nuevos bonificados (2 jóvenes menores de 30 años, 1 mayor de 60, 1 de larga duración y 1 con discapacidad superior al 33%). El Agente aplica el convenio de Químicas con 95 conceptos diferenciados, calcula la base de contingencias respetando la base máxima por grupo, aplica el MEI del 0,7% y la solidaridad complementaria del 0,92% a los 35 trabajadores que superan el exceso, calcula la retención de IRPF progresiva con la tabla de la CCAA de Madrid al 8,5%, valora las retribuciones en especie del art. 42-43 LIRPF y gestiona la IT delegada. Genera el fichero CRA Cret@ con el CCC de la empresa y los 220 IPF, el modelo 111 trimestral con clave A para los 220 perceptores, concilia de forma cuadruple las cuentas del PGC con el libro de nóminas, el CRA de la TGSS y las cuotas del modelo 111, plausibiliza detectando 3 desviaciones superiores al 15% (que escala al Director de RRHH) y presenta vía Sistema RED Online y Sede Electrónica AEAT con su CSV de recepción. Tiempo total: 6 horas frente a 4-5 días manuales.

## La conciliación cuadruple PGC - libro nóminas - CRA TGSS - modelo 111 AEAT evita requerimiento

Una nómina española sin conciliación cuadruple contra las cuentas del PGC, el libro de nóminas, el fichero CRA Cret@ del Sistema RED y la suma de cuotas del modelo 111 de la AEAT es receta para un requerimiento inmediato. La empresa registra la cotización empresarial del 23,60% sobre una base de contingencias de 4.000 EUR (944 EUR de cuota empresa), la cotización del trabajador del 4,70% (188 EUR) y la retención de IRPF de la tabla progresiva al 24% sobre una base liquidable de 35.000 EUR al año (700 EUR/mes de retención) en las cuentas 642 (SS a cargo de la empresa), 476 (organismos de la SS acreedores), 4751 (H.P. acreedora por retenciones de IRPF) y 640 (sueldos y salarios). Pero por un error en la maestra del trabajador en el ERP se aplicó el grupo de cotización 7 de administrativos cuando en realidad es el grupo 1 de ingeniero licenciado con una base máxima distinta, generando un error de 50 EUR de cotización mensual. La TGSS detecta la divergencia entre el fichero CRA Cret@ y el grupo de cotización declarado en el alta laboral y emite un requerimiento de la ITSS con sanción potencial leve de 626-1.625 EUR (LISOS art. 22), más la regularización retroactiva de los 4 años de prescripción de la LGSS, el recargo de demora del 5-20% y los intereses del 4,0625%.

Por eso la 14a etapa de decisión es la conciliación previa obligatoria a cuatro niveles ANTES de presentar el fichero CRA Cret@ y el modelo 111. El Agente compara línea a línea el libro de nóminas (suma de trabajadores, conceptos retributivos y cotizaciones desglosadas) con los saldos de las cuentas 640/642/4751/476 del PGC RD 1514/2007 (mayor del período), la suma del fichero CRA Cret@ del Sistema RED de la TGSS (los ficheros CRA, FAN, RNT, FDI e INNAB) y la suma de cuotas presentadas en el modelo 111/190 de la AEAT del trimestre o el año. Cualquier divergencia se marca como excepción y bloquea la presentación hasta su resolución. Solo cuando los cuatro niveles (libro de nóminas, contabilidad PGC, fichero CRA de la TGSS y cuotas de los modelos de la AEAT) son perfectamente coherentes, la nómina progresa al envío. Esta conciliación a cuatro niveles es lo que permite presentar mensualmente el fichero CRA Cret@ y trimestralmente el modelo 111 con riesgo cero de divergencia, y por tanto evitar el requerimiento de la ITSS (LISOS, sanción de 626-187.515 EUR) y de la AEAT (LGT, 50-150%).

## Edge-cases españoles: jubilación parcial contrato relevo, contratos formación bonificaciones, expatriados CDI seguridad social y MEI escalado progresivo

Casos especiales como la jubilación parcial con contrato de relevo, los contratos de formación bonificados para jóvenes menores de 30 años, mayores de 60, con discapacidad o de larga duración, los expatriados con CDI de seguridad social bilateral aplicable y el escalado progresivo del MEI del 0,7% y la solidaridad complementaria del 0,92% hasta 2045 parecen complejos, pero están determinados por la norma española. La jubilación parcial, regulada por la LGSS art. 215, permite reducir la jornada entre el 25% y el 50% manteniendo al trabajador en la empresa hasta la jubilación total, con contrato de relevo obligatorio para la sustitución; el Agente calcula la nómina parcial cotizando proporcionalmente y manteniendo la bonificación del contrato de relevo. Los contratos de formación bonificados, regulados por la Ley 43/2006 y el Real Decreto 1543/2011, reducen las cotizaciones empresariales por contingencias comunes en jóvenes menores de 30 años (75% de bonificación durante 12 meses), mayores de 60 (50% durante 12 meses), de larga duración con más de 12 meses en desempleo (75% durante 24 meses) y con discapacidad superior al 33% (75% de bonificación permanente). Los expatriados con CDI de seguridad social bilateral (España mantiene más de 50 convenios bilaterales de SS con países extranjeros) tributan en el país designado según el convenio sin doble imposición; el Agente verifica el certificado A1 (UE) o E101 (fuera de la UE) emitido por la autoridad del país de residencia y aplica el régimen correspondiente. El MEI del 0,7% y la solidaridad complementaria del 0,92%, escalados hasta 2045 según el Real Decreto-ley 13/2022 y el Real Decreto-ley 2/2023, incrementan progresivamente las cotizaciones, y el Agente actualiza automáticamente la tabla anual.

## Integración con ecosistema español: Sage NominaPlus, A3 Nom, Holded, SAP HCM Spain y TGSS Sistema RED

La lógica del Agente se conecta con los principales sistemas de nómina españoles vía API: [Sage NominaPlus y Sage Despachos](https://www.sage.com/es-es/) (lider PYME español con Sistema RED y AEAT certificado), [A3 Nom de Wolters Kluwer](https://www.a3software.com/) (despachos profesionales con presentación masiva multi-cliente), [Holded](https://www.holded.com/) (cloud para autónomos y PYME con Sede Electrónica AEAT directa) y [Cegid Quadra](https://www.cegid.com/es/) (mediana empresa con AT/EP por CNAE individualizado), además de SAP HCM Spain (PY-ES) para multinacionales, Workday HCM Spain para grupos IBEX-35 (Telefónica, Iberdrola, Santander, BBVA, Inditex), Factorial para PYME y ContaSimple o Mastermaq para despachos. La presentación telemática se hace al Sistema RED Online de la TGSS (con autorización RED y certificado SILCON/ACA) y a la Sede Electrónica AEAT (con cl@ve PIN o certificado FNMT-RCM/DNIe), con consulta automática de los convenios del REGCON, la tabla CNAE de AT/EP y las bases máximas de los grupos de cotización 1-11. Para grupos IBEX-35 con filiales LATAM, el Agente coordina la presentación centralizada multi-empresa con consolidación del grupo en el IS (modelo 220), garantizando el cumplimiento simultáneo ante la TGSS, la AEAT, la ITSS, el INSS, el SEPE, la Hacienda Foral y la AEPD.

--- Agente de Caja Menor ---
> Registra justificantes de caja mediante extracción IA, verifica facturas de pequeño importe según el párrafo 33 UStDV.

La caja menor cuesta a las empresas en las inspecciones fiscales un dinero desproporcionado - no porque los importes sean elevados, sino porque los defectos en la gestión de caja pueden invalidar toda la contabilidad. Cuando el auditor encuentra lagunas en el registro diario, puede estimar. En 2024, las inspecciones fiscales en Alemania generaron según el Ministerio Federal de Finanzas unos 10.900 millones EUR de resultado adicional. La gestión de caja está entre los primeros puntos de auditoría, porque es la más frecuentemente atacable.

## La gestión de caja decide el resultado de la inspección fiscal

La administración tributaria audita las operaciones en efectivo con más rigor que las operaciones sin efectivo. La base legal es inequívoca: la normativa fiscal exige el registro diario de todas las operaciones de caja, la normativa contable exige inalterabilidad y documentación sin lagunas, y desde 2020 rige la obligación de dispositivo técnico de seguridad (TSE). Desde enero de 2025, los sistemas de caja electrónicos y su TSE deben declararse activamente ante hacienda. Las infracciones de la obligación TSE pueden acarrear multas de hasta 25.000 EUR.

El problema no reside en la complejidad de las reglas. Reside en que entre la recepción del justificante y el asiento en el libro de caja transcurre demasiado tiempo. Quien registra los justificantes de caja el viernes por la tarde para toda la semana viola la obligación de registro diario - y da al auditor una palanca para estimaciones adicionales.

## El registro diario fracasa ante la realidad del día a día

En la práctica, el proceso raramente se parece a lo que prevé la normativa contable. Una jefa de oficina compra por la mañana cartuchos de impresora por 47 EUR, un colega paga al mediodía la comida de negocios con un cliente por 189 EUR, por la tarde llega un recibo de taxi por 23 EUR. Tres justificantes, tres personas diferentes, tres contabilizaciones diferentes. El asiento manuscrito en el libro de caja se hace - si acaso - al final del día de memoria.

El resultado lo conoce cualquier CFO que haya vivido una inspección fiscal: justificantes sin fecha en el libro de caja, sumas intermedias erróneas, cierres diarios faltantes. En facturas de pequeño importe hasta 250 EUR bruto surge un riesgo adicional. Los datos obligatorios simplificados permiten prescindir de la indicación del destinatario - pero si se nombra un destinatario y la indicación es errónea, puede peligrar la deducción del IVA soportado. Este matiz lo pasan por alto los empleados regularmente.

## Siete pasos de decisión separan la rutina del juicio

El [Decision Layer](/es/decision-layer/) descompone el proceso de caja en exactamente los pasos que marcan la diferencia entre un libro de caja conforme y uno objetado. De los siete pasos de decisión, solo uno está soportado por IA: el registro de justificantes, donde un LLM extrae los datos relevantes de justificantes de caja no estructurados - fotos de recibos, notas manuscritas, impresiones en papel térmico descoloridas.

Los cinco pasos siguientes son completamente basados en reglas. La verificación del umbral de 250 EUR, el control de datos obligatorios simplificados, la contabilización por tipo de justificante e importe, el asiento en el libro de caja con marca temporal conforme a normativa contable y la conciliación numérica entre saldo teórico y real - todo sigue reglas deterministas sin margen de discrecionalidad.

El séptimo paso permanece en el humano: cuando el saldo de caja se desvía del saldo contable, un humano debe aclarar la causa. Ningún algoritmo puede decidir si una diferencia de 14,50 EUR se debe a un justificante olvidado, un error de conteo o algo más grave. Este límite está trazado deliberadamente.

## La verificación basada en reglas cierra la brecha entre justificante y libro de caja

Imagine el lunes por la mañana en una sucursal con caja menor propia. La jefa de oficina fotografía el recibo de gasolina del fin de semana - 62 EUR. En cuestión de segundos el agente extrae importe, fecha y tipo impositivo, reconoce el justificante como factura de pequeño importe, verifica los datos obligatorios simplificados, contabiliza en la cuenta correcta y registra la operación con marca temporal en el libro de caja. Antes del almuerzo, el cierre diario muestra: saldo contable 843,50 EUR, saldo de arqueo 843,50 EUR, sin diferencia.

Si el miércoles el saldo real queda 12 EUR por debajo del saldo teórico, el agente documenta la desviación y escala al responsable de caja. No a un algoritmo. La aclaración de causas en descuadres de caja es una decisión de nivel 1 - exige juicio humano, porque las posibles razones son demasiado diversas para codificarse en reglas.

El resultado para la próxima inspección fiscal: cada operación de caja está registrada el día de la operación, vinculada a un justificante y documentada cronológicamente. La documentación de procedimientos que exige hacienda no se crea retrospectivamente para el auditor - surge como subproducto del proceso diario.

--- Agente de QA de Asientos ---
> Verifica cada asiento en cuanto a completitud formal, plausibilidad, consistencia de cuentas y corrección del código fiscal.

## Un tercio de los contables reporta varios errores semanales

Una encuesta de Gartner de 2024 muestra: el 33 por ciento de los contables encuestados reconocen que cometen varios errores de contabilización por semana. La razón principal no es falta de diligencia, sino cuellos de botella de capacidad. Las crecientes exigencias regulatorias y las condiciones comerciales volátiles aumentan el volumen de contabilización, mientras los tamaños de equipo se estancan.

Imagine un departamento de Finance con 4.000 asientos diarios. Con una tasa de error del tres al cinco por ciento - el valor típico de procesos de registro manual - surgen diariamente de 120 a 200 registros erróneos. No todos son materiales. Pero cada uno puede convertirse en un asiento de corrección en el cierre mensual si nadie lo detecta antes.

## Los errores en el libro mayor cuestan en el cierre un múltiplo de la prevención

Un código fiscal incorrecto en una factura de entrada es cuestión de segundos al registrarla. Si el mismo asiento alcanza el libro mayor, comienza una cascada: diferencia de conciliación en la verificación del IVA, consulta al responsable, investigación en el documento, asiento de anulación, nueva contabilización, nueva aprobación. De un segundo de corrección se convierten en 15 a 30 minutos de esfuerzo.

Multiplicado por cientos de asientos de corrección por cierre mensual, se desplaza toda la ventana de closing. Los controllers esperan saldos saneados. Los auditores objetan patrones recurrentes. Y la dirección financiera pierde confianza en las cifras que reporta semanalmente al consejo.

La palanca económica no reside por tanto en la aceleración del cierre, sino en la calidad del asiento individual. Lo que entra limpio en el libro mayor no necesita corregirse.

## Ocho pasos de verificación sustituyen al muestreo manual

El [Decision Layer](/es/decision-layer/) descompone la verificación de asientos en ocho decisiones discretas. Seis de ellas son completamente basadas en reglas: completitud formal (documento, cuenta, importe, fecha presentes), consistencia de cuentas (cuentas del debe y haber compatibles), consistencia del código fiscal (código IVA coincide con la cuenta contabilizada), delimitación de períodos (fecha de documento y período contable coinciden), detección de duplicados (importe, cuenta y fecha ya registrados) y el enrutamiento final.

Los dos pasos restantes utilizan patrones históricos: la verificación de plausibilidad compara cada importe con los rangos habituales del grupo de cuentas correspondiente. El score de anomalía agrega todas las verificaciones individuales en una valoración global y prioriza la escalación.

Determinante es el orden. Las verificaciones basadas en reglas se ejecutan en milisegundos. Solo los asientos que superan todas las comprobaciones formales alcanzan el análisis de patrones más costoso. En la práctica esto significa: más del 95 por ciento de todos los asientos recorren la cadena de verificación completa sin intervención humana.

## El caso normal pasa sin escalación

Con datos maestros bien mantenidos, se escalan del dos al cinco por ciento de los asientos. El score de anomalía determina el orden - los registros más llamativos aparecen primero en la pantalla del responsable. En lugar de verificar 4.000 asientos diarios por muestreo, el equipo se concentra en 80 a 200 casos priorizados.

Cada escalación que resulta inofensiva mejora el modelo. Los umbrales de plausibilidad se calibran mediante feedback: media más desviaciones estándar por grupo de cuentas como base de partida, refinados por la práctica diaria. Tras tres a seis meses, la tasa de falsos positivos desciende de forma medible.

## La calidad de contabilización determina la velocidad del cierre

Las empresas que sistematizan su verificación de asientos reportan consistentemente ciclos de closing más cortos y menos asientos de corrección en el cierre mensual. EY estima que más del 70 por ciento de todos los asientos contables son automatizables. La cuestión no es si la verificación se automatiza, sino lo transparente que permanece la lógica de decisión.

El agente de QA de asientos opera en los niveles 1 a 2 del Decision Layer: reglamento para las comprobaciones formales, soporte de IA para plausibilidad y detección de anomalías, decisión humana solo ante anomalías escaladas. Ningún error de contabilización permanece invisible, ningún paso de verificación queda sin documentar - y el cierre mensual comienza con saldos en los que la dirección financiera puede confiar.

--- Agente de Documentación de Procedimientos ---
> Reconoce cambios de proceso automáticamente, verifica la documentación existente en cuanto a actualidad.

Las documentaciones de procedimientos existen en la mayoría de las empresas. Están actualizadas en raras ocasiones. Exactamente esta brecha entre el estado de documentación y la realidad de los procesos se convierte en problema durante las inspecciones fiscales, porque el auditor no pregunta si existe una documentación, sino si refleja el estado real.

## Los auditores fiscales solicitan la documentación en primer lugar

En 2023, los auditores fiscales en Alemania detectaron en 146.516 empresas inspeccionadas un resultado adicional de 13.200 millones EUR (informe mensual del Ministerio de Finanzas, octubre 2024). Al inicio de una inspección, los auditores solicitan cada vez con más frecuencia la documentación de procedimientos, antes de entrar en la verificación material. La razón es pragmática: una documentación desactualizada o incompleta señala controles de proceso deficientes - y justifica actuaciones de auditoría más profundas.

La consecuencia legal está claramente regulada. Si una documentación de procedimientos inexistente o insuficiente perjudica la trazabilidad y verificabilidad de la contabilidad, se trata de un defecto formal con peso material. El auditor fiscal puede entonces rechazar la contabilidad y estimar las bases imponibles. En la práctica esto significa: un defecto documental se convierte en riesgo financiero antes de que se haya encontrado un error de contenido.

## Cada cambio de proceso genera una laguna de documentación

El problema real no es la creación inicial. La mayoría de los departamentos de Finance han construido en algún momento una documentación de procedimientos - frecuentemente en el marco de un proyecto, frecuentemente con asesoría externa. El problema comienza el día después de la finalización.

Un nuevo módulo ERP entra en producción. Un workflow de aprobación se adapta. Un agente adicional asume una tarea de verificación. Cada uno de estos cambios debería reflejarse en la documentación de procedimientos - en la descripción general, la documentación técnica del sistema, el concepto de autorizaciones y la descripción del SCI. En la práctica esto no ocurre oportunamente, porque nadie tiene el trigger. El cambio entra en producción, la documentación se queda estancada. A lo largo de meses y años crece una brecha creciente entre lo documentado y lo que realmente ocurre.

## La monitorización automática cierra la brecha en tiempo real

El agente de documentación de procedimientos supervisa continuamente las configuraciones de los sistemas fiscalmente relevantes. Cuando cambia un proceso - una nueva regla, un nuevo agente, una autorización modificada - detecta la desviación entre el estado documentado y el real. Verifica la documentación existente contra una lista de comprobación normativa, identifica las secciones afectadas y genera un borrador de actualización.

La lógica de decisión separa limpiamente según complejidad. Si algo ha cambiado, el agente lo detecta autónomamente. Si la documentación sigue coincidiendo con la realidad, lo verifica automáticamente. Qué requisitos normativos aplican y cómo se documentan las autorizaciones sigue un reglamento fijo. Pero si la documentación global es completa y si un borrador se aprueba - eso lo decide el humano. El agente entrega el borrador, no la firma.

## La documentación se documenta a sí misma

El agente de documentación de procedimientos tiene una propiedad especial dentro del [Decision Layer](/es/decision-layer/): es simultáneamente herramienta y objeto de la documentación. Cada cambio que detecta y documenta se registra con marca temporal, tipo de cambio y estado de procesamiento. Así surge un protocolo de cambios sin lagunas - no como requisito separado, sino como subproducto de la operación normal.

Para la inspección fiscal esto significa concretamente: la documentación de procedimientos no solo está actualizada, sino que su actualidad es demostrable. El auditor no solo ve el estado actual, sino todo el historial de cambios - cuándo se adaptó qué proceso, cuándo se actualizó la documentación, quién aprobó. El punto de objeción más frecuente pierde así su fundamento.

## La documentación de procedimientos se convierte en infraestructura operativa

La documentación de procedimientos clásica es un producto de proyecto - creada una vez, raramente actualizada, revisada frenéticamente durante la auditoría. El agente de documentación de procedimientos la convierte en parte de la infraestructura operativa. Los cambios se detectan antes de que se conviertan en lagunas. Los borradores están disponibles antes de que nadie los solicite. La conformidad normativa no se establece durante la auditoría, sino que se asegura continuamente - con la aprobación humana como última instancia.

--- Agente de Provisiones ---
> Identifica tipos de provisiones, calcula provisiones de vacaciones y primas determinísticamente.

Las provisiones son el tema recurrente de toda auditoría de cuentas anuales, porque tanto su reconocimiento como su valoración se basan en hipótesis y estimaciones. El agente de provisiones separa limpiamente lo que se puede calcular de lo que necesita criterio humano - y hace ambas partes resistentes a auditoría.

## Las provisiones son el tema recurrente de toda auditoría de cuentas

Ninguna otra partida del balance está con tanta regularidad en el foco de la auditoría externa e inspección fiscal. El IDW describe las provisiones expresamente como "tema recurrente" de la temporada de auditoría, porque tanto el reconocimiento como la valoración según la normativa contable se basan en hipótesis que la dirección debe realizar. La BaFin ha elevado de nuevo para la temporada de enforcement 2025 la adecuación de la valoración de activos y cuestiones de valoración relacionadas al foco de auditoría nacional.

La razón es de naturaleza estructural. Una provisión de vacaciones sigue una fórmula clara. Una provisión de costes procesales depende de la probabilidad jurídica de éxito. Una provisión de garantía se basa en valores de experiencia de los últimos años. Tres provisiones, tres lógicas de generación completamente diferentes - y en muchos departamentos de Finance acaban en la misma plantilla Excel que se actualiza manualmente cada año. El auditor externo ve al final un resultado, pero no qué parte fue cálculo y cuál fue estimación.

## Las vacaciones y las primas pueden dotarse de forma completamente determinista

El [Decision Layer](/es/decision-layer/) descompone la dotación de provisiones en ocho pasos. Tres de ellos son reglas de cálculo puras que no requieren estimación. La provisión de vacaciones resulta de los días de vacaciones pendientes multiplicados por la tarifa diaria media de salario bruto más cuota patronal de seguridad social. La provisión de primas sigue la base contractual y la previsión de resultados actual. El asiento contable se deriva deterministamente del tipo de provisión.

En una empresa industrial mediana con 800 empleados que en el pasado trasladaba la provisión de vacaciones en tres días laborables en enero de la gestión de tiempos de RRHH a Excel, el agente asume este proceso mensualmente. Los datos provienen directamente del sistema ERP y los datos maestros de personal. El resultado no es una estimación, sino un cálculo trazable por empleado. Para el auditor externo ya no se plantea la cuestión de si la cuantía es plausible, sino solo si las bases de cálculo son correctas. Esto reduce la actuación de auditoría de muestreos con consultas posteriores a una pura verificación del método.

## Las garantías y los costes procesales siguen siendo decisión humana

Dos pasos de la pirámide deliberadamente no se automatizan. Las provisiones de garantía se basan en valores de experiencia y criterio empresarial específico que ningún reglamento puede reflejar completamente. Las provisiones de costes procesales dependen de la valoración jurídica de probabilidades de éxito, que exige una evaluación profesional por parte del departamento legal o el despacho externo.

Aquí el agente no entrega el resultado, sino la base de decisión. Para garantías, agrega las cifras de reclamaciones y cortesías de los últimos tres años, calcula tasas por grupo de productos y proporciona la base para la estimación de cuotas. Para costes procesales, recopila el valor en litigio, los costes del procedimiento hasta la fecha y la instancia del departamento jurídico y entrega la plantilla a la decisión humana. La cuota final y la cuantía final de la provisión permanecen en el humano, pero se toman a partir de un conjunto de datos estructurado y no de la memoria.

## El Decision Layer documenta cada valoración de forma resistente a auditoría

Lo decisivo para la colaboración con el auditor externo no es si una provisión fue calculada o estimada. Lo decisivo es si la base está documentada. El agente de provisiones registra por provisión: tipo, método de cálculo, datos de entrada, resultado, la marca de determinista o basado en estimación, comparativa con el año anterior y justificación de cada desviación. Al final del año surge un espejo de provisiones que puede presentarse como anexo a las cuentas anuales.

Las notas del anexo según la normativa contable o IAS 37 se preparan como borrador LLM. Esto no significa que el contable las acepte sin más. Revisa si la formulación se ajusta a la valoración y aprueba. Para equipos de Finance que en la temporada de cierre necesitan cada hora doblemente, el trabajo se desplaza de la redacción a la revisión - y sobre todo, lejos de la pregunta recurrente del auditor externo de cómo se ha llegado a una cifra determinada.

--- Agente de Solicitud de Pedido ---
> Reconoce necesidad de aprovisionamiento a partir de datos de consumo, verifica presupuestos de centros de coste, sugiere proveedores preferentes.

La solicitud de pedido es la decisión más cara de todo el proceso Purchase-to-Pay - no por su valor propio, sino porque determina si las condiciones negociadas llegan realmente a aplicarse. Quien elige aquí el proveedor incorrecto, pide fuera del contrato marco o pasa por alto los límites presupuestarios, destruye ahorros antes de que la primera factura llegue al sistema. El agente de solicitud de pedido ancla contratos marco, soberanía presupuestaria y matriz de aprobación directamente en el proceso de pedido - y libera el criterio humano solo allí donde marca la diferencia: por encima del umbral.

## El Maverick Buying cuesta a las organizaciones financieras hasta el 16 por ciento de sus ahorros negociados

Los datos son inequívocos: según APQC, las organizaciones con alto porcentaje de Maverick Buying necesitan de media 16 horas más para emitir un pedido, y pierden entre el marco de condiciones negociado y el aprovisionamiento real hasta el 16 por ciento de los ahorros. Hackett Group cuantifica en el Digital World Class Benchmark 2025 que los Top Performers mediante vinculación contractual consecuente y Maverick Buying reducido pierden un 60 por ciento menos de ahorros que la media. La palanca no está en compras, sino en el momento de la solicitud de pedido. Quien decide aquí, decide sobre el margen.

En la realidad de las organizaciones financieras medianas esto se traduce así: cientos de solicitudes de pedido diarias pasan por departamentos funcionales que ni tienen los contratos marco en la cabeza ni conocen los presupuestos residuales de los centros de coste. La consecuencia son pedidos al proveedor equivocado, pedidos sin referencia al contrato marco, superaciones que no aparecen hasta el cierre mensual. Cada una de ellas es una negociación perdida.

## El [Decision Layer](/es/decision-layer/) descompone la solicitud de pedido en siete pasos trazables

El agente de solicitud de pedido separa limpiamente las siete decisiones de cada solicitud según responsabilidad. La detección de necesidades a partir de datos de consumo funciona como pronóstico soportado por ML, por ejemplo cuando se caen por debajo de existencias mínimas en material consumible. Verificación presupuestaria, sugerencia de proveedor, condiciones de contrato marco, workflow de aprobación y generación del pedido son completamente basados en reglas - comparaciones numéricas y lógica de datos maestros, sin margen de discrecionalidad.

Concretamente: un departamento funcional emite una necesidad de 8.400 EUR para material de mantenimiento. El agente verifica en menos de un segundo si en el centro de coste hay suficiente presupuesto residual, identifica el proveedor preferente de los datos maestros, obtiene las condiciones del contrato marco (precio, cantidad mínima, plazo de entrega), determina mediante la matriz de aprobación el aprobador competente y genera el pedido. La vinculación contractual no es resultado de buenas intenciones, sino el valor por defecto.

## El criterio humano permanece allí donde cuenta económicamente

No todo pedido puede procesarse de forma basada en reglas. Pedidos individuales por encima de un umbral definido - por ejemplo 25.000 EUR o un límite específico por centro de coste - requieren criterio consciente: situación de mercado, relación estratégica con proveedores, urgencia extraordinaria. Aquí el agente da un paso atrás. Prepara la decisión completamente (situación presupuestaria, disponibilidad contractual, proveedores alternativos, cadena de aprobación), la presenta al decisor competente y documenta la aprobación humana como paso explícito en el Audit Trail.

Este principio no es una red de seguridad, sino arquitectura de gobernanza: la aprobación humana es un elemento del SCI conforme a la normativa de documentación de operaciones comerciales y forma parte de la obligación de documentación normativa. Cada solicitud de pedido - aprobada de forma basada en reglas o por un humano - es trazable como operación comercial sin lagunas.

## Los contratos marco pasan del papel a la infraestructura

El verdadero beneficio está detrás del pedido individual: el motor de contratos marco que utiliza el agente se convierte en el Decision Layer en infraestructura compartida. El agente de compliance contractual accede a la misma lógica contractual. La matriz de aprobación es reutilizada por el agente de aprobación de facturas y el agente de ejecución de pagos. El pedido generado se convierte en la referencia para el Three-Way Matching entre pedido, recepción de mercancía y factura. Lo que comienza como automatización de una tarea individual, construye paso a paso la infraestructura de decisión sobre la que descansa todo el proceso P2P.

--- Agente de Gestión de Cobros ---
> Calcula estructuras de antigüedad de créditos, evalúa riesgos de impago mediante modelo ML.

La gestión de cobros no es trabajo de diligencia de la contabilidad de deudores, sino una cuestión de balance del CFO. Quien solo administra las partidas abiertas en lugar de valorarlas, descubre los impagos recién en el cierre anual - y entonces son caros. El agente de gestión de cobros desplaza la detección hacia adelante: estructura de antigüedad, riesgo de impago y necesidad de provisiones por insolvencia se calculan continuamente para que las decisiones estratégicas puedan tomarse a tiempo.

## El riesgo de impago se ha convertido en 2025 en una cuestión de balance

Las cifras de Creditreform evidencian la urgencia: en 2025 declararon insolvencia en Alemania 23.900 empresas, un aumento del 8,3 por ciento respecto al año anterior y el nivel más alto en más de diez años. El daño estimado asciende a unos 57.000 millones EUR, de media más de dos millones EUR por caso de insolvencia. Para acreedores medianos esto significa: cada partida abierta es potencialmente un riesgo de balance, no solo una cuestión de liquidez.

En este entorno no basta con optimizar el proceso de reclamación. Lo decisivo es qué créditos son realistamente cobrables, cuáles deben provisionarse y cuáles es mejor vender o reclamar judicialmente. Esta valoración necesita datos fiables sobre comportamiento de pago, estructura de antigüedad y solvencia externa - y no una vez al trimestre, sino de forma continua.

## El [Decision Layer](/es/decision-layer/) separa cálculo de valoración

El agente de gestión de cobros descompone el proceso en ocho pasos de decisión a lo largo del Decision Layer. La separación es clara: aritmética y verificación de reglas funcionan de forma automatizada, las decisiones discrecionales permanecen en el humano.

La estructura de antigüedad de créditos es un cálculo a partir de fechas de vencimiento - basado en reglas, sin margen de discrecionalidad. Lo mismo aplica a la supervisión del límite de crédito: una verificación de umbral contra límites configurados. El scoring de riesgo de impago utiliza un modelo ML que combina comportamiento de pago, riesgo sectorial y datos de solvencia externos. Con 24 meses de historial limpio, estos modelos alcanzan típicamente del 80 al 85 por ciento de precisión en la predicción de impagos.

Las decisiones estratégicas permanecen en el CFO o Head of Finance. Las provisiones generales por insolvencia pueden proponerse de forma basada en reglas, las provisiones individuales requieren criterio individual porque según la normativa contable tienen consecuencias fiscales directas. Los acuerdos de pago, la evaluación de factoring y la escalación judicial ponderan relación con el cliente, costes y riesgo - no reglas, sino negociación.

## Un escenario concreto: cliente industrial con siete millones de cartera de créditos

Una empresa mediana de maquinaria con unos 180 millones EUR de facturación mantiene unos siete millones EUR de créditos pendientes en libros. La contabilidad de deudores mantiene diligentemente la estructura de antigüedad y los procesos de reclamación, pero la imagen de riesgo surge recién en el cierre mensual - demasiado tarde para una reacción operativa.

Con el agente de gestión de cobros, la valoración se ejecuta diariamente: el scoring ML señala a un gran cliente cuyo comportamiento de pago se ha deteriorado en las últimas seis semanas, aunque el límite de crédito aún no se ha superado. El agente documenta el score de riesgo, los factores contribuyentes y la estructura de antigüedad actual. El CFO ve la alerta el mismo día y decide: reducir el límite de crédito, cambiar el suministro a pago anticipado, informar a ventas. La decisión sigue siendo humana, la base llega en minutos en lugar de semanas.

## Lo que el agente proporciona y lo que deliberadamente no hace

El agente no es una herramienta de cobro ni un sustituto de la relación con el cliente. Proporciona tres cosas: una estructura de antigüedad de créditos continuamente actualizada, una imagen ponderada por riesgo de la cartera de deudores y una base documentada para decisiones de provisiones por insolvencia. El reporting cubre DSO, Aging, mapa de calor de riesgo de impago y utilización de límites de crédito, configurable según los KPIs del cockpit del CFO.

Lo que el agente deliberadamente no hace: no decide sobre pagos a plazos, no vende créditos, no escala por iniciativa propia al departamento jurídico. Estos pasos siguen siendo estratégicos y humanos - exactamente allí donde cuentan la habilidad negociadora, el conocimiento del cliente y la ponderación coste-beneficio. El Decision Layer hace transparente quién decidió qué y cuándo, y proporciona la evidencia sobre la que se basó la decisión.

--- Agente de Conciliación ---
> Concilia sublibros contra el libro mayor, asigna partidas abiertas, señala diferencias inexplicables y crea protocolos de conciliación.

La conciliación de cuentas es el cuello de botella del cierre mensual - y se convierte en cuello de botella porque ocurre en la fecha de corte. El [Decision Layer](/es/decision-layer/) la desplaza al mes en curso, separa el matching basado en reglas del juicio humano y hace que cada conciliación sea demostrable para el auditor externo en cualquier momento.

## La fecha de corte es el verdadero error del sistema

Cientos de cuentas, miles de partidas abiertas, cinco días laborables de tiempo: así es la semana de conciliación en la mayoría de los departamentos de Finance. Según benchmarks de APQC, la mitad de los equipos financieros necesitan más de una semana para el cierre mensual, solo una minoría cierra en tres días o menos. Paralelamente, The Hackett Group señala que los contables dedican una parte sustancial de su tiempo de trabajo a procesos manuales de bajo valor como conciliaciones de cuentas.

El problema no es la cantidad de asientos, sino la cadencia. Quien contabiliza durante tres semanas y el día 30 del mes empieza a comparar saldos, ha acumulado él mismo la necesidad de aclaración. Cada diferencia que aparece en la fecha de corte tiene al menos 15 días. Los documentos están dispersos, los responsables han perdido el contexto y el auditor externo espera. El cuello de botella no surge por el volumen, sino por la simultaneidad.

## La conciliación continua resuelve el atasco de plazos

El agente de conciliación verifica con cada asiento contra la lista de cuentas configurada si sublibro y libro mayor siguen coincidiendo. Deudores, acreedores, banco, activos fijos, cuentas de compensación: los saldos se comparan continuamente, no se congelan mensualmente. Las diferencias aparecen en el momento en que surgen - no tres semanas después, cuando ya nadie sabe qué asiento las causó.

Esto cambia fundamentalmente la tarea del contable. En lugar de aclarar cientos de cuentas simultáneamente en la fecha de corte, el equipo procesa listas de trabajo diarias con un puñado de puntos abiertos. La carga se distribuye a lo largo del mes, el cierre mismo se convierte en la confirmación de un estado ya conciliado. Para el CFO esto significa ciclos de cierre más cortos sin personal adicional - y para el departamento, una jornada laboral sin la recurrente ventana de fin de mes.

## El Decision Layer separa el trabajo de cálculo del juicio

La conciliación se descompone en ocho pasos de decisión claramente delimitados. Siete de ellos son trabajo de cálculo: qué cuentas pertenecen a la lista, coinciden los saldos, qué partidas abiertas explican la diferencia, qué estado de aprobación se ha alcanzado. Estos pasos se ejecutan de forma basada en reglas, determinista y protocolada. La asignación de partidas abiertas combina coincidencia exacta con matching difuso para pagos parciales e importes redondeados. Las diferencias residuales inusuales las marca el agente mediante pattern matching para revisión.

Una única decisión permanece en el humano: la evaluación de materialidad. Una diferencia residual de 340 EUR en una cuenta de compensación, es material o no? Esta pregunta depende de contexto, evolución y juicio, y deliberadamente no se automatiza. El agente presenta la diferencia con toda la información relevante, el responsable decide. Esto es nivel 1 a 2 del Decision Layer: alta automatización en la ejecución, reserva humana clara en la valoración. Cada decisión se escribe con marca temporal, creador y justificación en el protocolo de conciliación - la base para toda auditoría de cuentas anuales conforme a normativa contable.

## El cierre pasa de sprint a rutina

Quien introduce la conciliación continua no solo cambia el flujo de trabajo, sino el perfil de expectativas del cierre mensual. El protocolo de conciliación está disponible en cualquier momento, no solo en la fecha de corte. El auditor externo puede consultar durante el mes qué cuentas están conciliadas y con qué nivel de evidencia. Los puntos abiertos ya no son sorpresas de última hora, sino una lista de trabajo mantenida.

Para la dirección esto significa tres cosas: fechas de cierre planificables en lugar de ciclos de horas extra, una base numérica fiable para forecasts y reporting durante el mes, y una pista de auditoría que no solo cumple la normativa contable, sino que la hace visible. La conciliación deja de ser un evento mensual. Se convierte en lo que siempre fue: un proceso de control continuo que solo históricamente se disfrazó de evento de fecha de corte.

--- Agente Reconocimiento Ingresos ---
> Agente reconocimiento ingresos determinista 5-step model NIIF 15 con PGC RD 1514/2007 NRV 14, ICAC Resoluciones, AEAT modelo 200 LIS art. 11 + modelo 232 y CNMV Hechos Relevantes IBEX-35.

El reconocimiento de ingresos español es la prueba de estrés más técnica del cierre anual. La AEAT cruza el modelo 200 de IS (presentación hasta el 25 de julio tras el cierre) con la imputación temporal de la LIS art. 11 frente al criterio contable de inscripción del art. 13 LIS, y cualquier divergencia genera una potencial denegación de la deducción del gasto vinculado (LIS art. 14) con sanción del 50-150% del importe defraudado (LGT art. 191-195) e intereses del 4,0625% anual. El ICAC supervisa a los auditores ROAC con sanción grave de 12.001-72.000 EUR y suspensión de 1 a 3 años del ejercicio ante una auditoría deficiente (NIA-ES 240 de fraude en el reconocimiento de ingresos o NIA-ES 540 de estimaciones contables). La CNMV obliga a las sociedades cotizadas IBEX-35 (Telefónica, Iberdrola, Santander, BBVA, Inditex, ACS, Repsol, Cellnex, Naturgy, Acciona, Aena, Indra, Ferrovial, Mapfre) a publicar Hechos Relevantes ante restatements materiales del reconocimiento de ingresos, con sanción de 30.001-300.000 EUR por infracción grave por defecto de información además de la responsabilidad de los consejeros (LSC art. 236-241). La ESMA publica anualmente sus prioridades de enforcement situando el reconocimiento de ingresos entre las tres principales todos los años. Los equipos de Finance con cinco a ocho contratos plurianuales simultáneos dedican habitualmente entre 4 y 6 días por contrato solo al juicio inicial de las obligaciones de desempeño, la asignación del precio y el grado de avance.

## La denegación de la deducción por la AEAT, la sanción del ICAC al ROAC, el Hecho Relevante ante la CNMV y la opinión de auditoría calificada de las Big-4

La sanción de la AEAT por un reconocimiento de ingresos divergente entre el PGC NRV 14 y la imputación temporal de la LIS art. 11 es uno de los riesgos materiales más frecuentes del cierre anual español. Una empresa industrial con 80 millones EUR de facturación y errores sistemáticos de reconocimiento en contratos plurianuales de construcción (porcentaje de completación fiscal autorizado por la AEAT frente a una metodología de grado de avance distinta en el criterio contable del PGC NRV 14) puede generar una diferencia de imputación del ejercicio de 200.000 a 800.000 EUR. La AEAT detecta la divergencia cruzando automáticamente el modelo 200 de IS con los asientos PGC inscritos en las cuentas 700/705 y la reconciliación del modelo 232 de operaciones vinculadas, y deniega la deducción del gasto vinculado (LIS art. 14) con sanción del 50-150% del importe defraudado (LGT art. 191-195), intereses del 4,0625% anual (LGT art. 26) y recargo de demora del 5-20% (LGT art. 27), acumulando una sanción total de 100.000 a 1.200.000 EUR para una empresa mediana.

A esto se suman riesgos paralelos. El ICAC supervisa a los auditores ROAC con sanción grave de 12.001-72.000 EUR y suspensión de 1 a 3 años del ejercicio ante una auditoría deficiente del reconocimiento de ingresos (NIA-ES 240 y NIA-ES 540). Una opinión de auditoría calificada de las Big-4 (Deloitte, KPMG, EY, PwC) sobre el reconocimiento de ingresos genera un restatement obligatorio (NIC 8.41-49), el re-depósito en el Registro Mercantil (LSC art. 254) y, para el IBEX-35, la publicación de un Hecho Relevante ante la CNMV con una caída media de la cotización del 15-25% de forma inmediata. El 63% de las acciones de enforcement de la SEC relacionadas con correcciones afectaron al Revenue Recognition y a los controles internos sobre la información financiera. Para grupos IBEX-35 con filiales LATAM (Telefónica con Telefónica Brasil y Vivo; Iberdrola con Avangrid en EE.UU. e Iberdrola México; Santander con Santander Brasil; BBVA con BBVA México y Garanti; Repsol con Repsol Sinopec Brasil), la coordinación centralizada del reconocimiento NIIF 15 del grupo, la reconciliación individual en PGC de las sociedades y el DEFR trimestral de la CNMV es uno de los procesos más técnicos del cierre anual.

## El reconocimiento ingresos español recorre 16 etapas determinadas

A diferencia del modelo alemán estándar (8 etapas con HGB y AO) o del polaco (10 etapas con UoR y la Ustawa o CIT), el reconocimiento de ingresos español compliance-first exige 16 etapas porque el sistema regulatorio superpone seis capas obligatorias simultáneas. Integra el 5-step model de la NIIF 15 (identificación del contrato, obligaciones de desempeño, precio de transacción, asignación y reconocimiento punto o período) con el PGC RD 1514/2007 NRV 14 y las Resoluciones del ICAC de 9/02/2016 y 19/12/2018, calcula el grado de avance por método input (cost-to-cost) u output (hitos) y genera los asientos PGC de las cuentas 700/705/706, 430/437/438 y 477 de IVA repercutido. También calcula los contract assets y liabilities (NIIF 15.105-109), los costes incrementales de obtención del contrato (NIIF 15.91-94) y la provisión de contratos onerosos (PGC NRV 15) en la cuenta 142, concilia la imputación temporal de la LIS art. 11 con el criterio contable de inscripción (art. 13 LIS) y las diferencias temporarias (NIC 12 y PGC NRV 13), presenta los modelos 200 de IS, 220 de grupos, 232 de operaciones vinculadas, 303 de IVA y 347 de operaciones superiores a 3.005,06 EUR, y genera el borrador por LLM de las revelaciones (NIIF 15.110-129 y memoria nota 14) y el DEFR trimestral de la CNMV para el IBEX-35.

Un escenario concreto: proveedor de software empresarial mediano en Madrid con 120 millones EUR de facturación y un contrato marco de 3 años por 4,8 millones EUR con un cliente bancario. El Agente verifica los 5 criterios de contrato válido del paso 1 de la NIIF 15 e identifica las obligaciones de desempeño separadas con el juicio del Director Financiero (la licencia y la implementación son una única obligación porque la implementación no es separable, ya que solo ella hace utilizable el software para el cliente; el soporte es una obligación separada; y el bonus por KPI vinculado al SLA es contraprestación variable). Calcula el precio de transacción como 4.320.000 EUR fijos más 312.000 EUR de variable estimada (480.000 al 65%, con la restricción de altamente probable aplicada de forma conservadora para evitar un reverso significativo), aplica el componente financiero significativo descontado al tipo de interés incremental de endeudamiento del cliente del 3,5% y asigna proporcionalmente los precios de venta independientes (SSP). Reconoce la licencia y la implementación a punto temporal en la aceptación del cliente al final del proyecto (mes 18) y el soporte a período lineal durante 36 meses, calcula el grado de avance por método input cost-to-cost, genera los asientos PGC trimestrales de las cuentas 705, 438 y 477 de IVA al 21%, capitaliza las comisiones de venta en la cuenta 240 amortizable linealmente, evalua que el contrato no es oneroso, concilia la imputación temporal de la LIS art. 11 con el criterio de inscripción, prepara el modelo 200 de IS, genera el borrador de las revelaciones (NIIF 15.110-129 y memoria nota 14) y lo valida el Director Financiero antes del auditor Big-4. Tiempo total: 3 horas del Agente más 1 hora de juicio humano, frente a 5 días manuales.

## La conciliación entre el PGC NRV 14, la NIIF 15 y el modelo 200 de IS evita el restatement

Una empresa cotizada IBEX-35 sin una conciliación estructurada entre el PGC NRV 14 individual, la NIIF 15 consolidada y la imputación temporal del modelo 200 de IS es receta para un restatement obligatorio (NIC 8.41-49) y un Hecho Relevante ante la CNMV. La diferencia práctica entre el criterio NIIF 15 (consolidado) y el PGC NRV 14 (sociedades individuales) puede ser material en las obligaciones de desempeño separadas, la contraprestación variable, el componente financiero y los costes incrementales de obtención del contrato. Sin conciliación, el riesgo es que un ajuste del auditor Big-4 detectado antes de emitir la opinión de auditoría genere un restatement posterior al depósito en el Registro Mercantil (LSC art. 254), lo que implica el re-depósito, un Hecho Relevante material ante la CNMV, una caída de la cotización del 15-25%, una investigación de la CNMV, la responsabilidad de los consejeros (LSC art. 236-241) y una potencial acción judicial de los inversores institucionales.

Por eso la 14a etapa de decisión es la conciliación previa obligatoria entre cuatro niveles ANTES de la aprobación de las cuentas anuales por la Junta General. El Agente compara el reconocimiento de ingresos NIIF 15 consolidado del grupo, su reconciliación frente al PGC NRV 14 de las cuentas individuales, los saldos de las cuentas 700/705/430/438 del PGC y la imputación temporal del modelo 200 de IS. Cualquier divergencia se marca como excepción y bloquea la aprobación. Solo cuando los cuatro niveles son perfectamente coherentes, la aprobación progresa al depósito. Esta conciliación cuadruple permite presentar el DEFR, los reportes regulatorios de la CNMV y las cuentas anuales depositadas con riesgo cero de divergencia, y por tanto evitar el restatement, el Hecho Relevante ante la CNMV y la investigación.

## Edge-cases españoles: contratos largo plazo, software multi-componente, contratos onerosos y operaciones vinculadas grupos LIS art. 18

Los CONTRATOS A LARGO PLAZO, regulados por la LIS art. 11.4 y el RD 634/2015 art. 7, admiten el porcentaje de completación fiscal cuando duran más de 1 año y se conocen con razonable seguridad los ingresos y costes totales; el Agente concilia el método de grado de avance contable del PGC NRV 14 (input cost-to-cost u output por hitos) con el método fiscal de la LIS y prepara la reconciliación del modelo 200 de IS. El SOFTWARE EMPRESARIAL MULTI-COMPONENTE requiere el juicio humano del Director Financiero sobre los tests de distinguibilidad de la NIIF 15.27 y la ICAC Resolución 9/02/2016 ('capable of being distinct' y 'distinct in context of contract' con sus tres factores de integración); el Agente prepara un análisis estructurado con las cláusulas contractuales, la comparación con contratos históricos similares y la política contable documentada. Los CONTRATOS ONEROSOS (PGC NRV 15 y NIC 37.66-69) exigen una provisión cuando los costes inevitables superan los beneficios económicos esperados (provisión en la cuenta 142, con reverso si la situación mejora); el Agente la calcula trimestralmente comparando el margen previsto con los costes actualizados. Las OPERACIONES VINCULADAS conforme a la LIS art. 18 y el RD 634/2015 art. 18-21 obligan a valorar a precio de mercado con master file, local file y CbCR para grupos de más de 750M EUR (BEPS Acción 13) y al modelo 232 anual hasta el 30 de noviembre; el Agente integra el reconocimiento intra-grupo con la valoración arm's length.

## Integración con ecosistema español: SAP S/4HANA Spain RAR, Sage 200, A3 ERP, Holded, Cegid Quadra y AEAT Sede Electrónica

La lógica del Agente se conecta con los principales sistemas de Revenue Recognition españoles vía API: [SAP S/4HANA Spain Revenue Accounting](https://www.sap.com/spain/) (con RAR y el módulo IFRS 15 para multinacionales y grupos IBEX-35), [Sage 200 y Sage X3 España](https://www.sage.com/es-es/) (mediana empresa con NIIF 15, PGC NRV 14 y modelo 200 de IS), [A3 ERP y a3con de Wolters Kluwer](https://www.a3software.com/) (despachos y empresa mediana con reconocimiento PGC NRV 14 y modelos 200 de IS y 232), [Holded](https://www.holded.com/) (cloud para autónomos y PYME con suscripciones SaaS lineales) y [Cegid Quadra Spain](https://www.cegid.com/es/) (mediana empresa con Revenue Recognition y Project Accounting NIIF 15 y provisiones de contratos onerosos del PGC NRV 15), además de Oracle Fusion Cloud Revenue Management para large enterprises, Workday Financial Management para grupos IBEX-35 y Microsoft Dynamics 365 Finance con analytics de revenue waterfall en Power BI. La presentación telemática a la AEAT se hace vía Sede Electrónica con cl@ve PIN o certificado FNMT-RCM/DNIe (modelo 200 de IS hasta el 25 de julio, modelo 220 de grupos, modelo 232 de operaciones vinculadas hasta el 30 de noviembre, modelo 303 de IVA, modelo 347 y modelo 720 de bienes en el extranjero), a la CNMV vía su Plataforma de Comunicaciones (DEFR trimestral, semestral y anual, y Hechos Relevantes) y al Registro Mercantil vía Borme.es (depósito de las cuentas anuales, LSC art. 254). Para grupos IBEX-35 con filiales LATAM, el Agente coordina el reconocimiento centralizado con consolidación del grupo (IFRS 10/11/12 y LSC art. 42-49), la reconciliación individual en PGC y el DEFR trimestral de la CNMV, garantizando el cumplimiento simultáneo ante el ICAC, la AEAT, la CNMV, la ESMA y las Big-4 bajo metodología NIA-ES adaptada al PGC español.

--- Agente de Declaraciones de Seguridad Social ---
> Determina motivos de declaración, crea declaraciones conformes a DEÜV, transmite electrónicamente a las aseguradoras y procesa respuestas.

Las declaraciones de seguridad social son el proceso rutinario más regulado de la contabilidad de personal. Cada alta y baja, cada declaración anual, cada interrupción y cada cambio de cotización es declarable, sujeto a plazo y crítico en términos de responsabilidad. La Seguridad Social alemana recauda anualmente más de 500 millones EUR en reclamaciones adicionales de auditorías empresariales; en los aproximadamente 800.000 centros auditados, los auditores objetan en aproximadamente un tercio de los casos declaraciones erróneas o faltantes. Para los CFOs esto no es un tema de contabilidad de personal, sino un riesgo de responsabilidad personal según la legislación de seguridad social.

El agente de declaraciones de seguridad social resuelve exactamente este riesgo, reflejando las diez decisiones de la declaración DEÜV de forma completamente basada en reglas: determinar motivo de declaración, verificar motivo de presentación, recopilar datos de declaración, asignar clave de grupo de cotización, crear conjunto de datos DEÜV, validar el conjunto de datos, comprobar el plazo, transmitir dentro de plazo, procesar respuesta, y anular y volver a presentar declaraciones erróneas. Sin componente de IA, sin discrecionalidad, sin alucinación. Esta es la razón de la mayor valoración de Readiness de todo el catálogo de Finance.

## La realidad de responsabilidad detrás de la rutina

Las cifras de la Seguridad Social de las auditorías empresariales turnarias muestran lo caro que resulta la negligencia: según la estadística DRV, se reclaman anualmente varios cientos de millones de euros en liquidaciones adicionales de cotizaciones, con aproximadamente el 30 por ciento de los empleadores auditados presentando declaraciones cuestionadas. A esto se añaden recargos por mora del uno por ciento por mes iniciado sobre cada cotización atrasada, plazos de prescripción de hasta 30 años y una inversión de la carga de la prueba: el empleador debe demostrar de forma creíble que la declaración no se omitió culpablemente.

En la práctica, los errores raramente surgen por intención. Surgen porque un cambio de personal hace colisionar el motivo de declaración "baja por salida" con la clave de grupo de cotización "0000", porque una declaración anual fracasa formalmente y nadie revisa la respuesta de la aseguradora, porque un miniempleo supera el límite de retribución y la competencia cambia de la central de miniempleos a la aseguradora de salud. Cada uno de estos casos es un árbol de decisión basado en reglas - y cada uno de estos árboles puede reflejarse de forma determinista.

## Diez decisiones, cero componente de IA

El [Decision Layer](/es/decision-layer/) descompone la declaración de seguridad social en diez microdecisiones que todas tienen el mismo carácter: entrada del sistema de nóminas, regla de la legislación de seguridad social o DEÜV, salida inequívoca. El motivo de declaración se deriva del cambio en datos maestros de personal. La clave de grupo de cotización sigue del estado de aseguramiento, tipo de empleo y retribución. El formato DEÜV está técnicamente especificado. La transmisión se realiza a través de la interfaz estandarizada al ente competente. La respuesta se parsea y en caso de rechazo se coteja con un reglamento que conoce las constelaciones de error más frecuentes.

Esta arquitectura convierte al agente en el contraejemplo de todas las discusiones sobre compliance de IA. Donde no trabaja IA, tampoco hay riesgos de IA. El EU AI Act no es aplicable porque no se toma ninguna decisión probabilística. La auditoría de seguridad social acepta el Decision Layer como documentación de nóminas porque cada declaración está documentada de forma resistente a revisión con motivo de declaración, marca temporal, vía de regla y comprobante de transmisión.

## Escenario: 1.200 empleados, doce meses, cero objeciones

Un grupo con 1.200 empleados sujetos a seguridad social en tres sociedades genera entre 40 y 80 declaraciones DEÜV mensuales: altas, bajas, interrupciones, modificaciones, declaraciones especiales. Antes de la introducción del agente, la semana de declaraciones en enero (declaraciones anuales) duraba regularmente diez días, la tasa de error en las respuestas estaba entre el cuatro y el seis por ciento, y la auditoría empresarial de 2022 terminó con una reclamación adicional de 180.000 EUR más recargos por mora.

Tras la introducción del agente de declaraciones de seguridad social, cada cambio de datos maestros se traduce directamente en una decisión de declaración. Las declaraciones anuales para 1.200 empleados se crean y transmiten en 90 minutos. Las respuestas de las aseguradoras se parsean de forma automatizada. Las declaraciones rechazadas que son corregibles de forma basada en reglas se reenvían automáticamente; el resto llega al cockpit del responsable con código de error, referencia de regla y propuesta de solución.

## Documentación resistente a auditoría como subproducto

El efecto real no surge en la creación de declaraciones, sino en la documentación. Cada decisión se archiva con datos de entrada, vía de regla, conjunto de datos de salida y respuesta. La auditoría de seguridad social encuentra un historial de declaraciones completo en el que cada declaración individual puede reconstruirse - incluido el estado exacto de reglas en el momento de la declaración. Preguntas como "por qué se declaró al Sr. Muller en marzo de 2024 con grupo de cotización 1111 en lugar de 6100?" se responden en menos de un minuto, con cita de la regla aplicada.

--- Agente Preparación Auditoría Fiscal ---
> Preparación auditoría fiscal: análisis orden inspección, exportación datos formato IDEA, accesos Z1/Z2/Z3, identificación áreas riesgo y respuestas auditor.

Una auditoría fiscal no es para las grandes empresas un evento excepcional, sino un estado permanente. Quien trata el período de auditoría como un caso de emergencia, pierde. Quien lo organiza como disciplina continua reduce provisiones, acorta la duración de la auditoría y gana seguridad en la negociación. El agente de preparación de auditoría fiscal desplaza a Finance de la producción reactiva de expedientes a un estado permanente de audit-ready.

## Por qué la preparación clásica de la auditoría cuesta dinero al CFO

El Ministerio Federal de Finanzas comunicó para 2024 un resultado adicional de unos 10.900 millones EUR de 140.764 inspecciones fiscales - con 12.359 auditores a nivel federal y una tasa de inspección del 1,6 por ciento. Las grandes empresas y grupos están en la llamada auditoría consecutiva, es decir, se inspeccionan de forma continuada y turnaria. Para los CFOs esto significa: la siguiente auditoría no es cuestión de si, sino de cuándo.

La preparación clásica comienza con la orden de inspección. A partir de ese momento, la empresa tiene normalmente de dos a tres semanas para preparar datos en formato IDEA y facilitar los tres tipos de acceso Z1, Z2 y Z3. En estas semanas, el departamento fiscal, IT y asesores externos rotan en modo de crisis. Las respuestas a preguntas del auditor se elaboran bajo presión de tiempo. Las decisiones históricas se reconstruyen a partir de documentos cuyos creadores hace tiempo que dejaron la empresa. El resultado es calculable: provisiones más altas, peor posición negociadora, ciclos de auditoría más largos.

El problema no es la auditoría - es la ruptura estructural entre la operación corriente y la preparación de la auditoría. Cada decisión que no se documentó en el momento de la operación comercial debe reconstruirse después. Ahí surgen los resultados adicionales.

## Lo que el [Decision Layer](/es/decision-layer/) cambia en esto

El agente de preparación de auditoría fiscal no es una herramienta que se activa en caso de emergencia. Es el punto de integración de todos los demás agentes de Finance. Cumplimiento normativo contable, contabilización, IVA, retenciones, precios de transferencia - cada una de estas decisiones se toma donde surge y se documenta de forma legible por máquina. El agente condensa esta documentación en cualquier momento bajo demanda en la base de datos preparada para la auditoría.

El trabajo se divide en tres roles claramente separados. Los pasos basados en reglas los asume la automatización sin discrecionalidad: consultas de base de datos por período de auditoría y tipo impositivo, exportación IDEA según estándar GDPdU, preparación de los accesos Z1/Z2/Z3. Horas en lugar de semanas. Los pasos soportados por IA aportan reconocimiento de patrones: la orden de inspección se interpreta, se cotejan los focos históricos de auditoría, las preguntas del auditor se encaminan al departamento competente. Las decisiones humanas permanecen allí donde pertenecen: estrategia de respuesta, evaluación de riesgo de planificación fiscal y estimación de provisiones. Estos pasos son expresamente Human-in-the-Loop, porque presuponen criterio profesional y experiencia negociadora.

## Escenario: cómo transcurre una auditoría consecutiva en el Decision Layer

Un grupo con sede en Alemania recibe una orden de inspección para los años 2022 a 2024. Se auditan impuesto de sociedades, impuesto sobre actividades económicas, IVA y documentación separada de precios de transferencia. El agente analiza el decreto en minutos, asigna los requisitos a los agentes competentes y crea un plan de preparación con esfuerzo estimado y clusters de riesgo abiertos.

La recopilación de datos - normalmente la fase más cara - se ejecuta en segundo plano. Las exportaciones IDEA están inmediatamente disponibles porque los datos contables ya están en el formato requerido. El análisis de áreas de riesgo marca dos clusters: una serie de entregas intracomunitarias con países de destino cambiantes y una estructura de licencias intragrupo cuya documentación de precios de transferencia se ha ajustado varias veces desde 2023. Ambos clusters van al departamento fiscal con base de datos preparada y línea argumentativa. La provisión la fija el Head of Tax con criterio - el agente proporciona el rango de datos, no el juicio.

El resultado: sin semanas de crisis. Sin asesores externos para la preparación de datos. El Head of Tax se concentra en la argumentación y la negociación, no en la obtención de pruebas.

## Lo que cambia para la función de Finance

Estar permanentemente audit-ready no es un esfuerzo adicional - es una redistribución del esfuerzo existente. En lugar de afrontar cada tres a cinco años un proyecto de auditoría, cada decisión se documenta a sí misma en el momento de su generación. El departamento fiscal pasa de archivero a negociador. El CFO reduce la incertidumbre en la planificación de provisiones y puede evaluar riesgos de planificación fiscal con una base de datos fiable, antes de que el auditor los encuentre.

--- Agente de Three-Way Matching ---
> Compara facturas entrantes con pedidos y recepciones de mercancía. Verifica cantidades, precios y tolerancias.

El Three-Way Matching es el cuello de botella de decisión de las cuentas por pagar, porque cada factura de entrada debe ser verificada contra pedido y recepción de mercancía antes de pagarse. El agente de Three-Way Matching sustituye la revisión manual por once reglas deterministas y alcanza así una tasa Straight-Through a nivel empresarial - sin componente de IA, sin clasificación bajo la Ley de IA de la UE, sin margen de interpretación. Es el candidato de arranque con el que los CFO establecen el [Decision Layer](/es/decision-layer/) en la organización financiera, porque combina volumen elevado, riesgo bajo y efecto directo medible en caja.

## Por qué el matching manual domina el tiempo de proceso P2P

En una contabilidad de acreedores empresarial típica, entre el 10 y el 20 por ciento de todas las facturas de entrada entran en una excepción - desviación de cantidad, diferencia de precio, falta de recepción, referencia de pedido incorrecta. Los equipos de AP bien posicionados alcanzan, tras ajustar las reglas de tolerancia, cuotas Straight-Through en el rango alto de dos dígitos. Pero las excepciones restantes ocupan la mayor parte del tiempo de trabajo, porque cada desviación debe investigarse manualmente, aclararse con compras y aprobarse.

La realidad en la pyme y en la mayoría de las grandes empresas está muy por debajo. Aun con inversión continuada en automatización de AP, la proporción de facturas procesadas completamente sin intervención humana se mantiene a menudo en el tercio inferior del volumen total. La brecha entre inversión y efecto aparece donde la lógica de matching reside en máscaras del ERP en lugar de funcionar como un agente de decisión propio con matriz de aprobación clara.

Para el CFO esto se traduce en dos problemas concretos: pérdida de descuentos porque las facturas se aprueban tarde, y planificación de liquidez incierta porque la cartera de facturas abiertas y no matcheadas no es gobernable.

## Cómo el Decision Layer descompone el matching

El agente de Three-Way Matching divide el proceso de verificación en once microdecisiones, todas basadas en reglas: verificar los datos obligatorios de la factura, comprobar duplicados, asignar pedido, asignar recepción de mercancía, cotejar cantidades, cotejar precios, comprobar desviación contra tolerancia, enrutar la aprobación por matriz, asignar sociedad y centro de coste, calcular el descuento por pronto pago, generar el asiento contable. Cada paso es una verificación de campos o una comparación numérica. Cada umbral de tolerancia es configurable. Cada decisión de enrutamiento sigue una matriz importe-por-desviación consensuada con la dirección y la auditoría interna.

Este corte es la razón por la que el agente arrastra un 0 por ciento de componente de IA. No toma decisiones discrecionales, no interpreta textos, no aprende. Ejecuta reglas que una persona aplicaría igual - solo que en milisegundos y sin fatiga. Para la Ley de IA de la UE el agente resulta por tanto irrelevante, para una inspección contable y tributaria es un paso estándar, y para la auditoría interna una ruta de decisión documentada sin lagunas.

## Escenario concreto: holding industrial con 12.000 facturas al mes

Un holding industrial con seis plantas procesa unas 12.000 facturas de entrada al mes. Situación de partida: el 78 por ciento de las facturas matcheaban al primer intento, el 22 por ciento iba a la cola de excepciones. El departamento de AP con nueve personas a tiempo completo trabajaba principalmente sobre estas excepciones y resolvía de media 140 aclaraciones al día. Cuota de descuento: 61 por ciento. Tiempo medio de proceso desde recepción hasta pago: 9,4 días.

Tras la introducción del agente de Three-Way Matching con tolerancias ajustadas (2 por ciento en precio, 5 por ciento en cantidad, matriz de aprobación escalonada a partir de 2.500 EUR o unos 2.700 USD), el cuadro cambia: la tasa Straight-Through sube al 88 por ciento, la cartera de aclaraciones manuales baja de 2.640 a 1.440 facturas al mes. El departamento de AP ya no trabaja sobre cotejos rutinarios, sino solo sobre discrepancias reales con compras y proveedor. Cuota de descuento: 84 por ciento. Tiempo de proceso: 2,1 días. Efecto de caja por el solo incremento de descuento: unos 430.000 EUR (aproximadamente 465.000 USD) al año sobre un volumen de facturación de 380 millones de EUR (unos 410 millones de USD).

## Por qué este agente es el candidato de arranque para el Decision Layer

El agente de Three-Way Matching es la decisión de entrada más racional para un CFO porque cumple simultáneamente cuatro propiedades que rara vez coinciden en otros agentes de Finance: alta Readiness (los datos están en el ERP), volumen diario (medible de inmediato), carga baja de gobernanza (basado en reglas, no en IA) y alto efecto económico (descuento, liquidez, capacidad).

Además, sienta la infraestructura para todos los agentes de workflow posteriores. El sistema de umbrales de tolerancia lo retoma más tarde el agente de asignación de cobros para el cotejo de cobros contra partidas abiertas. La matriz de aprobación pasa a ser pieza estándar para cualquier agente de workflow con escalado por importe. La documentación de procesos entrega la ruta de revisión a la que se orientan los agentes posteriores asistidos por IA (por ejemplo, el agente de contabilización).

Quien quiere establecer el Decision Layer en la organización financiera empieza aquí - con un agente que no requiere discusión con el delegado de protección de datos, no necesita datos de entrenamiento y cuyo efecto se ve en el informe de descuentos tras la primera semana.

--- Agente de Documentación de Precios de Transferencia ---
> Crea la matriz de transacciones a partir de datos contables, realiza estudios benchmark.

La documentación de precios de transferencia es el proceso donde los CFOs producen o evitan el hallazgo más caro de su auditoría fiscal. En las inspecciones fiscales de 2024, los estados federales constataron un resultado adicional de unos 10.900 millones EUR, y las correcciones de precios de transferencia pertenecen sistemáticamente a las mayores partidas individuales (fuente: informe mensual del Ministerio Federal de Finanzas, noviembre 2025). El [Decision Layer](/es/decision-layer/) descompone la documentación en ocho pasos claramente responsabilizados - así surge un proceso resistente a auditoría donde cada decisión está justificada y cada cifra puede asignarse a una fuente.

## La regla: principio de libre competencia, y la carga de la prueba recae en usted

La legislación fiscal internacional exige que los precios intragrupo se acuerden como se habrían acordado entre terceros independientes. En caso de infracción, la administración tributaria corrige el resultado al alza, y en caso de documentación inexistente o deficiente, la normativa prevé un recargo de al menos el 5 por ciento y hasta el 10 por ciento del resultado adicional, como mínimo 5.000 EUR y hasta 1 millón EUR. Regulaciones adicionales han endurecido las reglas para financiaciones intragrupo, y las directrices de precios de transferencia de 2024 implementan los nuevos requisitos en el manual del auditor.

El caso práctico: un grupo con sociedad matriz alemana y una filial de producción polaca suministra producto semielaborado a Alemania. El precio de venta es de 100 EUR por unidad. La auditoría fiscal exige la prueba de que este precio corresponde al principio de libre competencia. Si falta la documentación, el auditor estima - y lo hace sistemáticamente en detrimento de la empresa. El Country-by-Country Reporting aplica adicionalmente a partir de una facturación del grupo de 750 millones EUR, y Pillar Two afecta en toda Europa a unos 8.000 grupos, de los cuales aproximadamente 800 están en Alemania.

## El Decision Layer: ocho pasos, tres tipos de decisor

La documentación de precios de transferencia se divide en trabajo basado en datos, cálculo basado en reglas y criterio humano. La matriz de transacciones se genera automáticamente a partir de los datos contables IC. El estudio benchmark funciona como consulta estructurada de base de datos contra Amadeus u Orbis, y el rango intercuartílico es una operación aritmética sin margen de discrecionalidad. Estos pasos los ejecuta el agente de forma fiable y trazable.

Tres pasos permanecen en el humano. El análisis funcional y de riesgos exige la valoración cualitativa de la cadena de valor, porque solo el responsable del departamento fiscal puede juzgar qué sociedad asume qué función. La elección del método TP entre CUP, Resale Price, Cost Plus, TNMM y Profit Split es una decisión interpretativa según las directrices OCDE. La aprobación final es estratégica porque define la línea de defensa en la próxima auditoría fiscal. El agente documenta cada uno de estos pasos humanos con decisor, marca temporal y justificación.

Entremedio hay un paso soportado por IA: el primer borrador de Master File, Local File y CbCR como draft LLM basado en los datos previos. El borrador es el punto de partida para la revisión por el asesor fiscal, nunca el resultado final.

## Lo que obtiene el CFO

Consistencia entre contabilización y documentación. El agente coteja continuamente los precios reflejados en la documentación TP con las contabilizaciones IC reales. Las desviaciones fuera del rango intercuartílico se escalan inmediatamente al asesor fiscal. Así desaparece la brecha clásica donde la documentación es del año anterior y las contabilizaciones llevan tiempo desviándose.

Capacidad de defensa en la auditoría fiscal. Cada entrada en Master File, Local File y CbCR está vinculada a su fuente de datos, cada elección de método con su justificación, cada benchmark con su snapshot de base de datos. El auditor no recibe un archivo terminado, sino un proceso reproducible. Esa es la diferencia entre estimación en detrimento del contribuyente y aceptación de los precios documentados.

## Pillar Two cambia la situación de partida

Desde el 1 de enero de 2025, el impuesto mínimo global del 15 por ciento actúa paralelamente a la verificación clásica de precios de transferencia. Para los departamentos de TP esto significa: los precios de transferencia no solo deben resistir el principio de libre competencia, sino ser adicionalmente consistentes con Pillar Two. Una corrección TP en un país puede empujar la tasa impositiva efectiva en otro país por debajo del umbral del 15 por ciento y desencadenar allí un impuesto complementario. El test ETR simplificado sube en 2026 por encima del 16 por ciento, y la documentación TP debe ser consistente con los datos GloBE. El agente proporciona la estructura donde ambos sistemas se alimentan de los mismos datos primarios - esto reduce el riesgo de que el departamento fiscal y la función fiscal del grupo mantengan dos mundos numéricos contradictorios.

--- Agente Cálculo Fiscal Viajes ---
> Cálculo fiscal de viajes según LIRPF art. 9 y RD 439/2007 art. 9 dietas exentas IRPF, recuperación del IVA soportado y asiento PGC - la capa de tratamiento fiscal en finanzas tras la aprobación HR.

La liquidación de gastos de viaje es el proceso basado en reglas más caro del área de Finance - y exactamente por eso la palanca de automatización más rentable. Una liquidación procesada manualmente cuesta según el benchmark GBTA unos 58 dólares (unos 53 EUR) y tarda de media 8,8 días hasta que se contabiliza. El agente de gastos de viaje reduce ambos valores en más del 70 por ciento, sin que una sola decisión fiscal abandone la empresa.

## Por qué los gastos de viaje manuales son más caros que el propio viaje

Los reglamentos detrás de un viaje de negocios están completamente documentados, pero dispersos: directrices del ministerio de finanzas con las dietas de extranjero actualizadas anualmente, dietas nacionales de 14 EUR a partir de 8 horas y 28 EUR a partir de 24 horas, reducciones por comidas según la legislación fiscal, valores de prestaciones en especie, requisitos de justificantes según la ley del IVA. Ningún empleado individual domina esta combinatoria en el día a día.

La consecuencia es conocida: los empleados introducen dietas incorrectas, olvidan reducciones por comidas, presentan justificantes ilegibles. La contabilidad corrige, pregunta, espera respuestas. Cada liquidación pasa por tres a cinco manos antes de contabilizarse. Con 2.000 liquidaciones al año - un valor realista para una empresa con 500 empleados - eso supone aritméticamente más de 100.000 EUR de puros costes de proceso, adicionales al presupuesto de viajes real.

## Lo que el [Decision Layer](/es/decision-layer/) hace de 15 pasos de decisión

El agente de gastos de viaje descompone el proceso en 15 decisiones discretas. Trece de ellas son completamente basadas en reglas: calcular duración de ausencia, derivar dieta BMF de país y horas, aplicar reducción por comidas del 20, 40 o 40 por ciento, determinar gastos de desplazamiento según dieta por kilómetro o justificante, verificar formalidades de justificantes según la ley del IVA, asignar centro de coste, crear asiento contable. Una decisión es agéntica: la verificación de plausibilidad contra valores comparativos históricos. Exactamente una decisión permanece en el humano: la valoración de motivos de viaje poco claros, es decir la cuestión de si un viaje fue realmente por motivos profesionales.

Esta distribución no es casualidad, sino el resultado de un análisis limpio de derecho tributario. Basado en reglas funciona todo lo que está regulado de forma concluyente en la legislación fiscal, tablas o directrices del ministerio. El humano decide solo allí donde se exige discrecionalidad - y allí con el expediente de decisión completo como base.

## Escenario: Fráncfort a Madrid, tres días, dos comidas proporcionadas

Un jefe de proyecto viaja el lunes temprano de Fráncfort a Madrid, vuelve el miércoles tarde. El martes participa en una reunión con el cliente con almuerzo proporcionado, el miércoles desayuna en el hotel. Manualmente, esta liquidación dura típicamente de 25 a 40 minutos - incluidas consultas.

El agente la resuelve en menos de un minuto. Lee partida y regreso de la solicitud de viaje, reconoce tres días de ausencia, obtiene la dieta de Madrid de las directrices del ministerio 2026 y calcula 32 EUR para el día de ida, 48 EUR para el día completo, 32 EUR para el día de vuelta. La reducción por comidas reduce el martes en un 40 por ciento a 28,80 EUR y el miércoles en un 20 por ciento a 25,60 EUR. Factura del hotel, billete de avión y recibos de taxi los verifica en cuanto a datos obligatorios, deduce el IVA soportado, contabiliza en el centro de coste registrado. El empleado ve cada línea con justificación, cada artículo de ley, cada versión de las directrices del ministerio. Puede impugnar cada posición - cada regla está documentada, no afirmada.

## Lo que gana concretamente el CFO

Cuatro efectos impactan directamente en la cuenta de resultados y la resiliencia fiscal. Primero, los costes de procesamiento por liquidación bajan más del 70 por ciento - de 58 dólares (unos 53 EUR) a menos de 15 dólares (unos 14 EUR). Segundo, el tiempo de procesamiento baja de 8,8 días a horas, lo que mejora mediblemente la satisfacción de los empleados y elimina consultas en contabilidad. Tercero, el agente cierra las fuentes de error más frecuentes en inspecciones de retenciones: dietas incorrectas, reducciones olvidadas, deducción de IVA soportado sin justificantes correctos. Cuarto, surge un motor de dietas BMF versionado que comparten el agente de gastos de representación y el agente de retenciones - la inversión en infraestructura se amortiza por triplicado.

El punto estratégico para el CFO: los gastos de viaje no son solo un bloque de costes, sino un proceso de riesgo. Cada dieta incorrecta se convierte en la próxima inspección de retenciones en una reclamación adicional. El Decision Layer hace este proceso no solo más rápido, sino documentado de forma resistente a auditoría - con trazabilidad exacta de qué versión de las directrices del ministerio regía en el momento del viaje.

--- Agente Declaración IVA ---
> Declaración IVA española: modelo 303 trimestral/mensual, modelo 390 anual, SII tiempo real RD 1624/1992, modelo 349 intracomunitarias - presentación AEAT auditable.

La declaración del IVA en España es la prueba de estrés mensual o trimestral del área Tax Compliance. La AEAT cruza automáticamente las cifras del modelo 303 con los registros enviados al SII en tiempo real, las contrapartes declaradas en modelo 347 anual y las operaciones intracomunitarias del modelo 349 - cualquier divergencia activa requerimiento inmediato con plazo 10 días y sanción potencial 50-150% del importe defraudado conforme LGT art. 191-195. Los plazos legales son inflexibles: presentación modelo 303 trimestral 1-20 abril/julio/octubre/enero, mensual hasta día 30 mes siguiente, modelo 390 resumen anual hasta 30 enero año siguiente, modelo 347 en febrero, modelo 349 día 20 mes siguiente. Y las nuevas obligaciones se acumulan: SII tiempo real para empresas >6.010.121,04 EUR con plazo 4 días naturales por factura, Verifactu RD 1007/2023 con cronograma faseado 2025-2026, TicketBAI obligatorio en territorios forales (Vizcaya, Guipuzcoa, Alava). Equipos financieros con tres a cinco regímenes IVA simultáneos (general, intracomunitario, inversión sujeto pasivo, prorrata, recargo equivalencia) dedican habitualmente entre 2 y 5 días por mes solo al cuadre manual del modelo 303.

## La sanción AEAT por el modelo 303, la infracción CIRBE del Banco de España y la multa AEPD por datos de facturas

La sanción AEAT por errores en el IVA es uno de los riesgos materiales más frecuentes del ciclo fiscal español. La LGT art. 191-195 regula tres tramos: infracción leve 50% del importe defraudado, grave 75%, muy grave 150% (cuando hay ocultación de datos o medios fraudulentos). Para una sociedad con 80 millones EUR facturación y un error en el cálculo IVA por aplicar tipo 10% en lugar de 21% en operaciones por valor 2 millones EUR, la diferencia de IVA defraudado sería 220.000 EUR con sanción potencial 110.000-330.000 EUR más intereses de demora 4,0625% anual y eventual recargo por extemporaneidad. La sanción adicional por incumplimiento SII RD 1624/1992 art. 62.6 alcanza 1% del importe máximo 6.000 EUR/factura por LGT art. 200.3 - para una empresa con 10.000 facturas/mes y errores SII en 100 facturas la exposición mensual sería 600.000 EUR. La omisión de operaciones en modelo 347 anual (umbral 3.005,06 EUR/contraparte) sanciona 1% importe omitido mínimo 300 EUR LGT art. 198 con cruce automático AEAT.

A esto se suman riesgos paralelos. La divergencia frente a Banco de España CIRBE por reporte mensual incorrecto de posiciones >9.000 EUR puede activar requerimiento Dirección General Supervisión con sanciones hasta 1 millón EUR conforme Ley 10/2014. Una sanción AEPD por violación de datos personales en facturas o libros IVA alcanza hasta el 4% de la facturación anual mundial o 20 millones EUR conforme RGPD art. 83.5, con resoluciones publicadas regularmente entre 100.000 y 1.000.000 EUR para casos del sector financiero y servicios profesionales. Y el Código de Comercio art. 28 sobre libros contables sin tachaduras genera observación en auditoría si los saldos IVA no son consistentes - una observación 'Salvedad' del auditor en cuentas anuales tiene impacto material en sociedades cotizadas IBEX-35 con efecto sobre cotización bursátil y rating crediticio S&P/Moody's/Fitch.

## La declaración IVA española recorre 16 etapas determinadas, no 8

A diferencia del modelo alemán estándar (8 etapas con UStG y ELSTER) o del polaco (10 etapas con KSeF FA(2) y JPK_V7M), la declaración IVA española compliance-first exige 16 etapas determinadas porque el sistema regulatorio superpone seis capas obligatorias simultáneas. Primero identifica el régimen aplicable: general con modelo 303, simplificado de autónomos por módulos, REAGP agrario, REBU de bienes usados y arte, recargo de equivalencia de minoristas con tipos del 5,2%, 1,4% y 0,5%, REDEME de devolución mensual o grupo de IVA del modelo 322 (art. 163 nonies LIVA). Despues clasifica de forma determinística el asiento PGC RD 1514/2007 por su clave de operación del Reglamento RD 1624/1992 y aplica los tipos del art. 90-91 LIVA (21% general, 10% reducido, 4% superreducido y 0% exento). Detecta la inversión del sujeto pasivo del art. 84.uno.2 con TipoFactura F2 en el SII, valida en VIES el NIF-IVA de la UE para las operaciones intracomunitarias (art. 138 de la Directiva 2006/112/CE) y calcula la prorrata del art. 102-106 LIVA en empresas con actividad mixta. Genera y envía a diario los registros A1 a A5 del SII (RD 1624/1992 art. 62.6) en el plazo de 4 días naturales, produce el fichero TicketBAI con software certificado y QR obligatorio en los territorios forales (Vizcaya, Guipuzcoa y Alava) y se adapta al cronograma Verifactu RD 1007/2023 (grandes contribuyentes desde el 1 de julio de 2025, medianas y pequeñas desde el 1 de enero de 2026). Por último identifica las operaciones del modelo 349 (mensual si superan 50.000 EUR por trimestre, trimestral en otro caso), acumula las del modelo 347 (umbral 3.005,06 EUR por contraparte), plausibiliza contra el mes anterior con Confidence Score, concilia el libro de IVA con las cuentas 472/477 del PGC y el SII enviado, escala a un humano ante desviaciones superiores al 15% y presenta de forma telemática vía Sede Electrónica AEAT con cl@ve PIN o certificado FNMT-RCM.

Un escenario concreto: empresa industrial mediana en Vizcaya con 80 millones EUR de facturación, sujeta a SII y TicketBAI, con un 30% de operaciones intracomunitarias y una prorrata mixta del 85%. Cada mes el Agente procesa 8.500 facturas emitidas y 4.200 recibidas, las clasifica por clave de operación y aplica los tipos del 21%, 10% o 4% según el bien. Detecta 320 operaciones de inversión del sujeto pasivo (servicios de construcción y equipos electrónicos superiores a 10.000 EUR), valida en VIES 1.200 NIF-IVA de la UE y calcula la prorrata del 85% sobre 18 millones EUR de IVA soportado. Genera y envía al SII en el plazo de 4 días los 8.500 registros A1, 4.200 A2, 18 A3, 35 A4 y 320 A5, produce 8.500 ficheros TicketBAI con QR, identifica 280 operaciones del modelo 349 y acumula 145 contrapartes superiores a 3.005,06 EUR para el modelo 347. Por último plausibiliza el modelo 303 y detecta 2 desviaciones superiores al 15% que escala al CFO, antes de presentarlo mensualmente vía Sede Electrónica con su CSV de recepción. Tiempo total: 3,5 horas frente a 4 días manuales.

## La conciliación bidireccional triple libro IVA - PGC - SII evita requerimiento AEAT

Una declaración IVA sin conciliación bidireccional contra cuentas PGC y registros SII enviados al AEAT es receta para requerimiento inmediato. La empresa registra una factura recibida de proveedor por 24.200 EUR (20.000 de base más 4.200 de IVA al 21%) en la cuenta 410X y envía el registro A2 al SII con base 20.000 e IVA 4.200. Al pagar la factura el banco genera movimiento de 24.200 EUR en extracto AEB 43 que se concilia con asiento haber 572 Bancos / debe 410X Proveedor. Pero por error en master del proveedor en el ERP el A2 SII se envió con tipo IVA 10% (2.000 EUR) en lugar de 21% (4.200 EUR) - la AEAT cruza automáticamente y detecta divergencia 2.200 EUR de IVA, emite requerimiento con plazo 10 días y sanción potencial 50% conforme LGT art. 191 (1.100 EUR para esta operación individual, escalable si reincidencia y volumen).

Por eso la 14a etapa de decisión es conciliación previa obligatoria triple nivel ANTES de presentar el modelo 303. El Agente compara línea a línea el libro IVA repercutido (suma facturas emitidas con IVA por tipo) con saldo cuenta 477 IVA Repercutido del PGC (mayor del período) y con suma registros A1 SII enviados al AEAT (acumulado mensual). El mismo principio aplica al libro IVA soportado vs cuenta 472 IVA Soportado vs registros A2 SII. Cualquier divergencia se marca como excepción y bloquea la presentación hasta resolución. Solo cuando los tres niveles (libro fiscal, contabilidad PGC, SII enviado) son perfectamente coherentes el modelo 303 progresa al envío. Esta conciliación triple nivel es lo que permite presentar el modelo 303 mensual o trimestral con riesgo cero de divergencia con el SII y por tanto evitar requerimiento AEAT con sanción 50-150% LGT art. 191-195.

## Edge-cases españoles: inversión sujeto pasivo, prorrata mixta, régimen recargo equivalencia y operaciones moneda extranjera

Casos especiales como inversión sujeto pasivo art. 84.uno.2 LIVA, prorrata mixta, régimen recargo equivalencia minoristas y operaciones en moneda extranjera parecen complejos pero son determinados por norma española. La inversión del sujeto pasivo aplica en siete situaciones (servicios de la UE, oro de inversión, materiales de recuperación, construcción con subcontratistas, inmuebles con renuncia a la exención, derechos de emisión de GEI y equipos electrónicos superiores a 10.000 EUR) con doble registro simultáneo de IVA repercutido y soportado y TipoFactura F2 en el SII. La prorrata del art. 102-106 LIVA aplica cuando la empresa realiza a la vez operaciones con y sin derecho a deducción, mediante el cociente entre numerador y denominador y el porcentaje deducible aplicado al IVA soportado, con regularización de los bienes de inversión a lo largo de los años para los inmuebles (art. 107 a 110). El régimen de recargo de equivalencia, obligatorio para minoristas autónomos y comunidades de bienes, añade tipos del 5,2%, 1,4% y 0,5% sobre el IVA estándar, declarando el proveedor el recargo mientras el minorista queda exonerado de su propio modelo 303. Las operaciones en moneda extranjera (USD, GBP, CHF) requieren conversión al tipo de cambio oficial del BCE del día de la operación conforme a la norma de valoración 11a del PGC RD 1514/2007 y a la Resolución ICAC de 18/9/2013, con reconocimiento de la diferencia de cambio en la cuenta 668/768.

El Agente identifica cada caso edge mediante reglas determinadas y aplica el tratamiento correspondiente: inversión sujeto pasivo con doble registro automático y TipoFactura F2 SII, prorrata recalculada mensualmente con regularización anual diciembre, recargo equivalencia con marcado contraparte minorista y aplicación automática recargos, moneda extranjera con tipo BCE oficial y diferencia cambio reconocida, operaciones >3.005,06 EUR para modelo 347 con acumulación por NIF, operaciones intracomunitarias para modelo 349 con validación VIES previa, detección régimen especial REBU bienes usados con margen aplicado al margen y eventual escalado a juicio humano cuando el caso no tiene precedente claro.

## Integración con ecosistema español: Sage, A3, Holded, SAP, AEAT Sede Electrónica, VIES y portales forales

La lógica del Agente se conecta con los principales ERP españoles vía API: [Sage 200 y Sage Despachos](https://www.sage.com/es-es/) (PYME con módulo de IVA y SII), [A3 Software](https://www.a3software.com/) (despachos con presentación masiva del 303), [Holded](https://www.holded.com/) (cloud para autónomos) y [Cegid Quadra](https://www.cegid.com/es/), además de SAP S/4HANA Spain con FI Tax, SII y TicketBAI, Dynamics 365 BC Spain, Oracle Fusion Cloud ERP y ContaSimple, ContaPlus o Mastermaq. La presentación se hace vía Sede Electrónica AEAT (cl@ve PIN o certificado FNMT-RCM), con validación VIES por webservice de la UE y los portales forales TicketBAI de Bizkaia, Gipuzkoa y Araba. Para grupos IBEX-35 con filiales LATAM (Telefónica, Iberdrola, Santander, BBVA, Inditex, Repsol), el Agente coordina el modelo 322 de grupo de IVA y el BEPS modelo 231, garantizando el cumplimiento simultáneo ante la AEAT, la Hacienda Foral y las autoridades fiscales de LATAM.

--- Agente de Alta de Proveedores ---
> Extrae datos maestros de la autodeclaración del proveedor, valida NIF-IVA, verifica listas de sanciones, evalúa riesgos y da de alta al proveedor en el ERP.

Cada nuevo proveedor es un punto de entrada de riesgo en los datos maestros. Quien da de alta sin verificar, potencia el error en cada asiento posterior - desde la deducción del IVA soportado hasta la ejecución de pagos. El agente de alta de proveedores convierte la verificación en paso obligatorio antes de que la primera factura llegue al sistema.

## El problema no está en el onboarding, está en el vuelo a ciegas posterior

La mayoría de las organizaciones financieras verifican a los nuevos proveedores en el momento del alta. Después llega el vuelo a ciegas. Mientras un gran número de empresas controla los datos maestros en el onboarding, la proporción de verificación sistemática antes de la ejecución de pagos cae drásticamente. Precisamente en esa brecha operan los ataques de suplantación de proveedor: una cuenta bancaria modificada, una entrada caducada en lista de sanciones, un NIF-IVA inválido - y el dinero acaba en la cuenta equivocada o la deducción del IVA soportado salta en la siguiente inspección.

A esto se suma el error estructural de datos. Muchos responsables de compras no tienen una visión clara sobre toda la red de proveedores de su organización, los equipos de purchase-to-pay reportan de forma recurrente falta de alineación end-to-end y falta de ownership sobre los datos maestros. Quien parte así, descubre duplicados, cuentas bancarias antiguas y perfiles de riesgo ilocalizables solo cuando el daño ya está contabilizado.

## Un escenario que los CFO conocen

Un fabricante químico mediano es contactado por un nuevo proveedor de materias primas de Europa del Este. Pedido inicial: 240.000 EUR (unos 260.000 USD). Compras envía la autodeclaración a contabilidad, y ahí se da de alta al proveedor. Dos semanas después llega la primera factura y se paga. Tres meses más tarde, el auditor interno constata: el NIF-IVA era inválido desde el principio. La deducción del IVA soportado debe revertirse y la inspección tributaria plantea además la cuestión del deber de diligencia. Al mismo tiempo, el proveedor aparece en una lista de sanciones actualizada - el responsable de cumplimiento no tiene un proceso para verificar los datos maestros existentes contra las actualizaciones de listas.

Con el agente de alta de proveedores, este caso se detiene antes del primer pago. La validación contra EU VIES detecta el NIF-IVA inválido en segundos. La verificación contra listas de sanciones de la UE, OFAC y ONU funciona de forma automática y se aplica a la base existente con cada actualización. Los datos bancarios se verifican algorítmicamente, la verificación de duplicados protege frente a un alta doble accidental y la puntuación de riesgo combina sector, país y datos de solvencia en un indicador que el Human-in-the-Loop debe aprobar cuando supera el umbral.

## Cómo el [Decision Layer](/es/decision-layer/) descompone el proceso

El agente cubre nueve pasos de decisión, cada uno con asignación clara a regla, IA o persona. La extracción de datos maestros de la autodeclaración y la lectura de condiciones de pago de contratos utilizan procesamiento documental basado en LLM. La validación del NIF-IVA, el screening de sanciones, la verificación de IBAN, el cotejo de duplicados y el alta en el ERP corren por reglas a través de integraciones API. La evaluación de riesgo es un híbrido: factores basados en reglas combinados con scoring de IA. Solo una decisión queda con el Human-in-the-Loop - la aprobación ante una puntuación de riesgo elevada. Donde hace falta criterio, decide el responsable de cumplimiento, documentado en el audit trail.

## Lo que el agente entrega al CFO

El efecto económico es doble. Primero, desaparece la debilidad estructural: cada proveedor queda validado antes de que se contabilice la primera factura. Segundo, surge la base sobre la que se apoyan los agentes de Finance posteriores. La validación del NIF-IVA se reutiliza en el agente de recepción de facturas y en el agente de retenciones. La verificación contra listas de sanciones alimenta al agente de ejecución de pagos. El patrón de scoring de riesgo constituye la plantilla para el agente de detección de fraude. Una vez construida, la infraestructura sirve a varios procesos a la vez.

Para el CFO esto significa: documentación robusta de due diligence para la inspección tributaria, menor exposición al fraude de proveedores y una base de acreedores en la que la ejecución de pagos puede confiar. El proceso cumple además, de forma anticipada, con los requisitos europeos de cumplimiento de sanciones y con las ampliaciones del marco Nacha ACH que entran en vigor en junio de 2026 - quien hoy construye una infraestructura de validación limpia cumple estos requisitos sin tener que reajustar.

--- Agente Retención IRNR ---
> Retenciones IRNR no residentes: dividendos, intereses, cánones modelo 216 trimestral, modelo 296 anual, convenios doble imposición red España 100+ - cumplimiento AEAT.

La retención en la fuente española es la prueba de estrés trimestral del área Tax Compliance internacional. La AEAT cruza automáticamente las cifras del modelo 111 (rendimientos trabajo y profesionales), modelo 115 (alquileres urbanos), modelo 123 (capital mobiliario) y modelo 216 (IRNR no residentes) con las declaraciones perceptor (modelo 100 IRPF persona física, modelo 200 IS persona jurídica, modelo 210 IRNR generic) - cualquier divergencia activa requerimiento inmediato con plazo 10 días y sanción potencial 50-150% del importe defraudado conforme LGT art. 191-195. Los plazos legales son inflexibles: presentación modelos trimestrales 1-20 abril/julio/octubre/enero, mensual hasta día 20 mes siguiente para grandes empresas, resúmenes anuales modelo 190/180/193/296 hasta 31 enero año siguiente, modelo 233 CbCR Pillar Two hasta 31 diciembre año siguiente. Y las nuevas obligaciones se acumulan: BEPS Pillar Two GloBE con tipo mínimo global 15% para grupos >750 millones EUR, MLI BEPS cláusula Principal Purpose Test (PPT) que deniega beneficios CDI cuando propósito principal sea evasión, régimen nuevo autónomo 7% con verificación documental obligatoria. Equipos financieros con cinco a ocho regímenes retención simultáneos (general profesional 15%, nuevo autónomo 7%, alquiler 19%, capital mobiliario 19%, IRNR generic 24%, IRNR UE 19%, exención territorial UE/EEE, CDI tipos reducidos por categoría renta) dedican habitualmente entre 2 y 4 días por trimestre solo al cuadre manual del modelo 111 con asientos PGC.

## La sanción de la AEAT por el modelo 111, los intereses forales por retenciones tardías, la multa AEPD y el mínimo global de Pillar Two

La sanción AEAT por errores en retenciones IRPF/IRNR es uno de los riesgos materiales más frecuentes del ciclo fiscal español. La LGT art. 191-195 regula tres tramos: infracción leve 50% del importe defraudado, grave 75%, muy grave 150% (cuando hay ocultación datos o medios fraudulentos). Para una sociedad con 80 millones EUR de facturación que paga 2 millones EUR de cánones a un proveedor extranjero sin CDI sin practicar la retención del 24% de IRNR (480.000 EUR), la sanción potencial sería de 240.000 a 720.000 EUR, más los intereses de demora del 4,0625% anual y el recargo por extemporaneidad. La sanción adicional por declaraciones incorrectas de la LGT art. 199 se fija en 150 EUR por dato erroneo: para una empresa con 1.000 perceptores trimestrales y errores en 50 registros (NIF mal formateado, clave incorrecta), la exposición sería de 7.500 EUR por trimestre. La omisión del modelo 233 de CbCR de Pillar Two se sanciona según la Orden HAP/2194/2013 con multas de 1.000 a 10.000 EUR por dato omitido, además de la responsabilidad solidaria entre matriz y filial.

A esto se suman riesgos paralelos. La aplicación incorrecta de la cláusula Principal Purpose Test (PPT) del MLI BEPS, ratificado por España en 2021 (aplicar un tipo CDI reducido cuando el propósito principal era obtener un beneficio fiscal, es decir treaty shopping), puede activar una reclasificación de la AEAT con liquidación al tipo nacional integro, intereses y sanción. Una sanción AEPD por violación de los datos personales del perceptor en los modelos de la AEAT alcanza hasta el 4% de la facturación anual mundial o 20 millones EUR (RGPD art. 83.5), con resoluciones publicadas habitualmente entre 100.000 y 1.000.000 EUR para casos del sector financiero y de servicios profesionales español. Y el Pillar Two GloBE complementa estos riesgos: los grupos IBEX-35 con un tipo efectivo inferior al 15% en alguna jurisdicción deben pagar el complemento vía Income Inclusión Rule (IIR) o Qualified Domestic Minimum Top-up Tax (QDMTT) calculado mediante el modelo 234, ya que las retenciones excesivas no recuperadas vía CDI reducen artificialmente el ETR y aumentan la exposición a Pillar Two.

## La retención IRPF/IRNR española recorre 16 etapas determinadas, no 9

A diferencia del modelo alemán estándar (9 etapas con EStG §50a y BZSt) o del polaco (10 etapas con CIT/PIT y UTW), la retención española compliance-first exige 16 etapas determinadas porque el sistema regulatorio superpone seis capas obligatorias simultáneas. Primero identifica el tipo de renta según los art. 17/23/25/33 LIRPF y el RDLeg 5/2004 de IRNR, verifica la residencia fiscal del perceptor mediante certificado anual y aplica la cascada de CDI de la red española (más de 100 convenios bilaterales: artículo 10 de dividendos, 11 de intereses, 12 de cánones, 14 de servicios profesionales y 15 de trabajadores dependientes). Despues evalua las cláusulas PPT y LOB del MLI BEPS, detecta el régimen de nuevo autónomo al 7% (RD 439/2007 art. 95) y la exención territorial de residentes UE/EEE del art. 14 RDLeg 5/2004 (dividendos matriz-filial superiores al 5% y cánones de la Directiva 2003/49/CE), y calcula la cuota según la categoría de renta (15% profesionales, 7% nuevos autónomos, 19% alquileres y capital mobiliario, 24% IRNR general y 19% en ciertas rentas de IRNR de la UE). Genera el modelo 111 con claves A/B/C/D, el modelo 115 con referencia catastral, el modelo 123 de capital mobiliario y el modelo 216 con código ISO y clave de renta 01-08, acumula el modelo 233 de Pillar Two para grupos de más de 750 millones EUR, concilia de forma bidireccional las cuentas 4751/4730/473 del PGC con el libro de retenciones y las cuotas de los modelos, plausibiliza con Confidence Score, escala a un humano ante casos sin precedente y presenta de forma telemática vía Sede Electrónica AEAT con su CSV de recepción.

Un escenario concreto: empresa industrial mediana en Madrid con 80 millones EUR de facturación, 220 empleados y un 35% de operaciones internacionales. Cada trimestre el Agente procesa 850 facturas profesionales (120 de nuevos autónomos al 7% y 730 generales al 15%), 45 contratos de arrendamiento urbano del modelo 115, 12 pagos de dividendos a accionistas (8 residentes UE al 19% y 4 con CDI del 5-15%), 28 pagos de cánones a proveedores extranjeros (12 con CDI inferior al 10% y 16 sin CDI al 24% de IRNR) y 6 remuneraciones de consejeros. El Agente verifica la residencia fiscal con el certificado vigente, consulta la tabla de CDI por categoría de renta, evalua el PPT del MLI para 4 operaciones de cánones (escala 2 al Asesor Fiscal con consulta a la DGT), calcula las cuotas y acumula el libro de retenciones, genera los modelos 111, 115 y 216 con las claves correctas, identifica 1 supuesto de CbCR del modelo 233 de Pillar Two, concilia con las cuentas 4751/4730/473 del PGC, plausibiliza detectando 1 desviación superior al 15% (que escala al CFO) y presenta vía Sede Electrónica con su CSV. Tiempo total: 4,5 horas frente a 3 días manuales.

## La conciliación bidireccional triple libro retenciones - PGC - cuotas AEAT evita requerimiento

Una declaración retenciones sin conciliación bidireccional contra cuentas PGC y suma cuotas modelos enviados al AEAT es receta para requerimiento inmediato. La empresa registra retención 15% sobre factura profesional 10.000 EUR (1.500 EUR cuota) en cuenta 4730 H.P. retenciones IRPF a cuenta y la presenta en modelo 111 trimestral con clave C (servicios profesionales general). Pero por error en master del proveedor en el ERP el agente clasificó como nuevo autónomo aplicando 7% (700 EUR) - cuando en realidad el perceptor lleva 5 años como autónomo y debía retenerse 15% (1.500 EUR). La AEAT cruza automáticamente el modelo 111 con la declaración modelo 100 IRPF del perceptor donde declara su antigüedad como autónomo y detecta divergencia 800 EUR de retención no practicada, emite requerimiento con plazo 10 días y sanción potencial 50% conforme LGT art. 191 (400 EUR para esta operación individual, escalable si reincidencia y volumen).

Por eso la 14a etapa de decisión es la conciliación previa obligatoria a tres niveles ANTES de presentar el modelo 111. El Agente compara línea a línea el libro de retenciones (suma de operaciones por perceptor, clave y tipo de retención) con el saldo de las cuentas 4751 (H.P. acreedora por retenciones de IRPF del trabajo), 4730 (H.P. retenciones de IRPF a cuenta) y 473 (H.P. retenedora de IRNR) del PGC RD 1514/2007 (mayor del período) y con la suma de cuotas presentadas en los modelos 111, 115, 123 y 216 del trimestre. Cualquier divergencia se marca como excepción y bloquea la presentación hasta resolución. Solo cuando los tres niveles (libro retenciones, contabilidad PGC, cuotas modelos AEAT) son perfectamente coherentes el modelo progresa al envío. Esta conciliación triple nivel es lo que permite presentar los modelos 111/115/123/216 trimestrales con riesgo cero de divergencia con declaración perceptor y por tanto evitar requerimiento AEAT con sanción 50-150% LGT art. 191-195.

## Edge-cases españoles: operaciones triangulares CDI, treaty shopping PPT/LOB, exención territorial UE/EEE y Pillar Two CbCR

Casos especiales como operaciones triangulares país-A/país-B/España con multiples CDI conflictivos, treaty shopping con cláusula PPT del MLI BEPS, exención territorial residentes UE/EEE art. 14 RDLeg 5/2004 y Pillar Two CbCR para grupos >750 millones EUR parecen complejos pero son determinados por norma española y consultas vinculantes DGT. Las operaciones triangulares aplican cuando filial española paga a sociedad país-A que es vehículo conduit company de beneficiario efectivo en país-B - el Agente identifica beneficiario efectivo y aplica CDI España-país-B cuando proceda, escalando casos dudosos a Asesor Fiscal con consulta vinculante DGT V0001-25. La cláusula PPT del MLI BEPS deniega beneficios CDI cuando obtener beneficio fiscal sea propósito principal - banderas de evasión incluyen treaty shopping, conduit company y beneficiario efectivo dudoso. La exención territorial UE/EEE aplica al 0% para dividendos matriz-filial >5% mantenida 1 año, cánones Directiva 2003/49/CE y trabajos buques internacionales. Pillar Two CbCR modelo 233 para grupos >750 millones EUR exige declaración anual hasta 31 diciembre año siguiente con desglose por país (ingresos, resultado, impuesto pagado, empleados, activos) - el Agente calcula tipo efectivo (ETR) e identifica jurisdicciones con ETR <15% para complemento Pillar Two vía IIR/QDMTT/UTPR.

## Integración con ecosistema español: Sage, A3, Holded, SAP, AEAT Sede Electrónica, base CDI y portales forales

La lógica del Agente se conecta con los principales ERP españoles vía API: [Sage 200 y Sage Despachos](https://www.sage.com/es-es/) (PYME con módulo de retenciones IRPF/IRNR y presentación telemática de los modelos 111, 115, 123 y 216), [A3 Software](https://www.a3software.com/) (despachos profesionales con presentación masiva multi-cliente), [Holded](https://www.holded.com/) (cloud para autónomos con modelo 130 trimestral y modelo 111 de retenciones a profesionales subcontratados) y [Cegid Quadra](https://www.cegid.com/es/) (mediana empresa con tabla de CDI y CbCR de Pillar Two), además de SAP S/4HANA Spain con FI Tax Withholding, Tax Reporting Cloud y los módulos de BEPS CbCR y Pillar Two GloBE, Dynamics 365 BC Spain con sus extensiones AL de Withholding Tax Spain, Oracle Fusion Cloud ERP Spain Localization y ContaSimple, ContaPlus o Mastermaq para despachos. La presentación se hace vía Sede Electrónica AEAT (cl@ve PIN o certificado FNMT-RCM), con consulta automática del IAE del perceptor, del Catastro para las referencias del modelo 115 y de una base unificada de CDI de la red española (más de 100 convenios con sus tipos vigentes por categoría de renta y país), además de los portales forales de la Hacienda Foral de Bizkaia, Gipuzkoa, Araba y Navarra. Para grupos IBEX-35 con filiales LATAM (Telefónica, Iberdrola, Santander, BBVA, Inditex, Repsol), el Agente coordina la presentación centralizada multi-empresa con consolidación del grupo en el IS (modelo 220), el CbCR del modelo 233 y el Pillar Two GloBE del modelo 234 (IIR/QDMTT/UTPR), garantizando el cumplimiento simultáneo ante la AEAT, la Hacienda Foral y las autoridades fiscales de LATAM (SAT de México, AFIP de Argentina, Receita Federal de Brasil y SII de Chile).

--- Agente Preparación Auditoría HR ---
> Preparación auditoría HR event-driven: UNE-ISO 19600 e IDW PS 980 prep, evidencia comité empresa, export RAT RGPD y mapa riesgo LISOS - paquete auditor listo a tiempo.

La preparación auditoría laboral en España es un proceso continuo, no un proyecto trimestral. El Estatuto de los Trabajadores RDLeg 2/2015 art. 4.2.c y art. 17 establecen el principio de no discriminación e igualdad como derecho fundamental del trabajador frente al empresario. La Ley Orgánica 3/2007 de igualdad efectiva más el Real Decreto 901/2020 obligan a las empresas con más de 50 personas trabajadoras a tener plan de igualdad inscrito en REGCON via REGCONECTA, con vigencia máxima de 4 años, comisión seguimiento paritaria y revisión obligatoria. El Real Decreto 902/2020 añade el registro retributivo desglosado por sexo y la auditoría retributiva si la brecha salarial supera el 25 por ciento sin justificación objetiva. La Ley 2/2023 transpone la Directiva UE 2019/1937 sobre canal denunciantes, exigiendo Sistema Interno Información con responsable SII, plazos respuesta de 7 días y 3 meses, y protección frente a represalias. La LOPDGDD LO 3/2018 más el RGPD art. 88 regulan el tratamiento de datos personales empleados con evaluación impacto DPIA obligatoria para tratamientos alto riesgo. Y la Directiva UE 2023/970 sobre transparencia retributiva debe ser transpuesta antes del 7 de junio de 2026 con obligaciones adicionales de reporting de brecha salarial y joint pay assessment. Cada una de estas capas regulatorias se audita por una autoridad distinta - ITSS, AEPD, Instituto de las Mujeres, Autoridad Independiente Protección Informante - con sanciones que escalan hasta 1.000.000 EUR.

## La preparación auditoría laboral fracasa en la recopilación evidencia, no en el conocimiento técnico

Una gran parte de las empresas españolas no supera sus auditorías laborales en el primer intento - la falta de evidencia documentada es una de las causas más frecuentes de actas infracción ITSS, requerimientos AEPD y observaciones del Instituto de las Mujeres. El problema rara vez es la falta de conocimiento técnico. Los planes existen, los protocolos están redactados. Lo que falta es la evidencia de que realmente se aplican en la práctica diaria.

Un escenario típico tres semanas antes de la inspección ITSS: el departamento compliance distribuye el catálogo requerimientos a doce áreas funcionales. RRHH debe aportar plan igualdad inscrito REGCON con último informe seguimiento, registro retributivo, valoración puestos trabajo, evaluación riesgos psicosociales, protocolo prevención acoso. El DPO debe aportar RAT por dimensión laboral, DPIA tratamientos alto riesgo, contratos encargado tratamiento, protocolo brechas seguridad. El Responsable SII debe aportar logs canal denuncias, resoluciones, política protección publicada. La primera semana pasa sin avances - todos tienen su operativa diaria. La segunda semana la dirección compliance escala. La tercera semana, ocho personas trabajan en paralelo para localizar documentos, validar vigencia, cerrar lagunas que solo ahora se hacen visibles.

Este patrón se repite trimestralmente con ligeras variaciones: inspección ITSS plan igualdad en primavera, inspección AEPD sobre datos empleados en verano, revisión Instituto Mujer plan igualdad en otoño, auditoría externa CSRD ESRS S1 al cierre ejercicio. Cada vez la misma urgencia, los mismos cuellos botella, los mismos hallazgos evitables. Y cada inspección puede acabar con sanción ITSS LISOS hasta 187.515 EUR, sanción AEPD hasta 4 por ciento facturación mundial, sanción AAI Ley 2/2023 hasta 1.000.000 EUR, o requerimiento Instituto Mujer con plan actuación correctora obligatorio.

## La recopilación continua evidencia convierte la auditoría laboral en trámite

El núcleo del problema está en el timing. La evidencia se recopila cuando llega el inspector ITSS o el requerimiento AEPD - no cuando se produce la acción que debe documentarse. Entre el momento en que se aprueba una medida del plan igualdad y el momento en que alguien busca evidencia ejecución, pasan meses. En ese intervalo, los responsables rotan, los sistemas cambian, los archivos se trasladan, las versiones documentos se duplican.

El [Decision Layer](/es/decision-layer/) descompone cada proceso auditoría en pasos decisión individuales y define para cada paso si decide un humano, un motor reglas o un agente IA. La asignación requerimiento auditoría a tipo evidencia sigue motor reglas - para inspección ITSS plan igualdad o requerimiento AEPD sobre tratamiento datos empleados está estandarizada y no necesita reinventarse cada trimestre. La recopilación evidencia desde sistemas fuente la ejecuta el agente, porque accede sistema RRHH (A3 Wolters Kluwer, Sage People, Cegid Meta4, SAP SuccessFactors Spain, Personio Spain), DMS y nómina con mayor velocidad y exhaustividad que cualquier proceso manual.

El estudio Forrester TEI sobre Drata (octubre 2025) cifra el ahorro tiempo por recopilación automatizada evidencia en un 78 por ciento frente a la recogida manual - de 980 a 220 horas al año. En la práctica eso significa: en lugar de tres semanas preparación antes cada inspección ITSS, la documentación está permanentemente actualizada y estructurada. La fecha auditoría se convierte en informe estado, no en proyecto.

## La auditoría laboral española recorre 14 etapas determinísticas

La auditoría laboral exige 14 etapas deterministas porque el sistema regulatorio superpone seis capas obligatorias a la vez: la igualdad y no discriminación del Estatuto de los Trabajadores, el plan de igualdad y la auditoría retributiva, el canal de denuncias, el tratamiento de datos de empleados, la prevención de riesgos psicosociales y el acoso, y el reporte de sostenibilidad CSRD.

Un escenario concreto: empresa industrial mediana en Barcelona con 80 millones EUR facturación y 450 personas trabajadoras, convenio Industria Química vigente. La auditoría ITSS según plan acción anual revisa tres dimensiones simultáneas: plan igualdad, registro retributivo desglosado por sexo con análisis brecha salarial, y evaluación riesgos psicosociales con protocolo prevención acoso. El Agente extrae datos sistema RRHH (Cegid Visma Meta4 con 450 fichas empleados), genera registro retributivo con valores medios y medianas por 24 grupos análisis, identifica brecha salarial 18 por ciento favorable hombres concentrada en categorías técnicas senior, valora puestos trabajo conforme anexo RD 902/2020, prepara plan actuación correctora con cronograma 24 meses, valida plan igualdad REGCON vigente y último informe seguimiento, audita evaluación riesgos psicosociales LPRL metodología FPSICO, ensambla paquete evidencia ITSS con 47 documentos firmados electrónicamente. Tiempo total: 6-8 horas vs 3 semanas manuales.

## Los hallazgos abiertos permanecen abiertos hasta la siguiente acta infracción

Cada auditoría laboral termina con lista hallazgos clasificados por gravedad: leves (errores formales), graves (incumplimiento con perjuicio), muy graves (vulneración derechos fundamentales). Lo que ocurre después es desalentador: el informe pasa al sistema archivo, los plazos vencen silenciosamente, en la siguiente inspección ITSS reaparecen los mismos puntos como hallazgos recurrentes - lo que predispone al inspector a postura considerablemente más crítica y aumenta gravedad sanción LISOS.

Una empresa de 200 personas que reincide en el incumplimiento del registro retributivo del RD 902/2020 puede pasar de una sanción grave (1.626-6.250 EUR) a una muy grave (6.251-187.515 EUR). Si la reincidencia coincide con el incumplimiento del plan de igualdad, las sanciones se acumulan hasta los 375.030 EUR. Y si además hay un tratamiento indebido de datos de empleados, la AEPD añade una sanción independiente de hasta el 4 por ciento de la facturación mundial.

Un seguimiento automatizado cambia esta dinámica: cada hallazgo se registra con responsable, plazo y evolución estado. Los vencimientos generan escalados antes de que el siguiente inspector los descubra. El Director RRHH ve dashboard ejecutivo trimestral con KPIs: tasa cumplimiento plan igualdad, brecha salarial bruta y ajustada, tasa remediación, denuncias canal SII, incidencias RGPD reportables, formación PRL completada.

## La integridad evidencia y la independencia auditor son requisitos estrictos

Las auditorías que afectan a datos de empleados están sujetas a requisitos especiales. El Comité de Empresa tiene derecho a información sobre el tipo y el alcance de los datos utilizados conforme al art. 64 del Estatuto de los Trabajadores, aunque sin derecho de veto. La documentación aportada debe ser trazable: cada evidencia tiene que ser verificable, inalterable y completa. La firma electrónica, el sello de tiempo y la cadena de custodia con verificación de integridad son los requisitos mínimos para una defensa posterior ante un procedimiento sancionador.

Este requisito no se cumple con capas adicionales control, sino con estructura. Cuando la evidencia se captura automáticamente en momento generación, se marca con fecha y origen y se archiva en formato consistente, la trazabilidad se convierte en subproducto de proceso bien diseñado.

La independencia auditor se preserva estrictamente: el agente facilita intercambio información pero no influye evaluaciones ni interpretaciones. No asesora interpretación documentación, no sugiere argumentación defensiva, no modifica documentos para presentación favorable - solo facilita acceso evidencia objetiva. Si auditor solicita aclaración, el agente direcciona a propietario evidencia (Director RRHH, DPO, Servicio Prevención, Responsable SII) sin intervenir contenido.

## Verificación humana causa raíz no solo síntoma

Basado en reglas no es libre de errores: ajuste salarial para corregir brecha sin revisión sistema valoración puestos, sanción disciplinaria caso acoso sin revisión protocolo y formación, medida técnica RGPD sin revisión política protección datos son causas frecuentes hallazgos recurrentes. Por eso la 10ª etapa decisión contiene verificación humana completitud causa raíz.

El responsable de RRHH (Director de RRHH, DPO, Servicio de Prevención o Comisión de Igualdad) confirma con firma electrónica que la medida implementada es estructural y no cosmética, requisito indispensable para cerrar el hallazgo. Es uno de los pocos puntos del proceso donde interviene una persona (decisor H), no para clasificar, sino para evaluar la profundidad de la remediación. Las otras 13 etapas son deterministas y se apoyan en el Estatuto de los Trabajadores, la legislación de igualdad, el canal de denuncias, la protección de datos y la prevención de riesgos laborales.

## Integración con ecosistema español: A3 Wolters Kluwer, Sage People, Cegid Meta4, Personio Spain

La lógica del agente se conecta por API con los principales sistemas de RRHH españoles: [A3 Wolters Kluwer](https://www.a3software.com/), referente en despachos profesionales; [Sage People y Sage 200 HR](https://www.sage.com/es-es/), HCM en la nube; [Cegid Visma Meta4](https://www.cegid.com/es/), para mediana y gran empresa con integración con REGCONECTA; y [Bizneo HR](https://www.bizneo.com/), orientado a la PYME. También integra SAP SuccessFactors Spain y Workday HCM Spain para los grandes grupos, y Personio, Factorial y Holded para PYME y autónomos. Consulta de forma automática los registros oficiales: REGCON para convenios, REGCONECTA para el plan de igualdad, las sedes electrónicas de la AEPD y la AEAT, el portal de la Autoridad Independiente y el Sistema RED de la TGSS. Para grupos con filiales en Latinoamérica, coordina el cumplimiento multiempresa con un plan de igualdad consolidado y un reporte CSRD verificado por auditor independiente.

--- Agente Inscripción Beneficios HR ---
> Inscripción beneficios sociales: PPE Plan Pensiones Empleo RDL 13/2022, salario en especie ET art. 26 (cheques, transporte, guardería) e IRPF art. 17.2 - paquetes TGSS + AEAT + DGSFP.

La inscripción de beneficios sociales de los empleados en España se sitúa entre cuatro marcos de cumplimiento paralelos con consecuencias muy distintas. La Ley General de la Seguridad Social obliga a dar de alta en el Sistema RED dentro de los 6 días hábiles desde el inicio de la relación laboral, con las cotizaciones de empresa y empleado sobre la base mensual y un recargo de demora si el pago se retrasa. La reforma del RDL 13/2022 sustituye los planes de pensiones empresariales tradicionales por el Plan de Pensiones de Empleo, con un límite de aportación de 10.000 EUR anuales por empleado y autorización de la DGSFP. La Ley 35/2006 del IRPF y su reglamento regulan la valoración de las rentas del trabajo en especie, con el límite del 30 por ciento sobre la retribución total que fija el Estatuto de los Trabajadores. Y el RGPD junto con la LOPDGDD imponen el tratamiento de datos de empleados con una DPIA obligatoria para las categorías especiales. En conjunto, cualquier inscripción de beneficios en una empresa mediana o grande española puede activar a la vez hasta cuatro obligaciones de cumplimiento distintas.

## Las sanciones acumuladas pueden superar 1,5 millones de euros

Las sanciones laborales de la ITSS son escalonadas: leve de 70 a 1.625 EUR, grave de 1.626 a 6.250 EUR y muy grave de 6.251 a 187.515 EUR, con publicidad de la sanción. El recargo de demora de la TGSS sobre las cotizaciones no pagadas en plazo va del 5 por ciento dentro del primer mes al 20 por ciento pasados tres meses. La AEAT puede sancionar el incumplimiento de la retención del modelo 111 hasta el 150 por ciento de la deuda. La AEPD multa el tratamiento indebido de datos de empleados hasta el 4 por ciento de la facturación mundial. Y la DGSFP puede llegar al 1 por ciento del patrimonio del plan, además de suspender o revocar la autorización. En una empresa mediana o grande con incumplimientos recurrentes en plazos de altas, valoración del salario en especie, datos de empleados y plan de pensiones, la suma puede superar 1,5 millones de euros.

## Catorce etapas: doce deterministas, dos asistidas por ML y una confirmación humana

El agente descompone la inscripción de beneficios en 14 microdecisiones: doce deterministas, dos asistidas por ML y una confirmación humana. Las deterministas cubren la clasificación del evento entre Open Enrollment y Life Event, la verificación de elegibilidad, el cálculo del límite de aportación al Plan de Pensiones de Empleo, la validación del salario en especie, el alta en el Sistema RED, la retención del IRPF, la auditoría del plan ante la DGSFP, la coordinación con la Mutua y la notificación al Comité de Empresa. Las dos asistidas por ML son indicadores, no decisiones finales: la posible notificación de una brecha de seguridad y la auditoría de sincronización, cuyas discrepancias se elevan a revisión humana. La confirmación humana, no automatizable, es la elección final del empleado con firma electrónica y designación de beneficiario, porque requiere su voluntad informada. El Decision Layer registra la trazabilidad de cada decisión para la defensa posterior ante reclamaciones laborales o procedimientos sancionadores.

## El Plan de Pensiones de Empleo del RDL 13/2022 sustituye a los planes empresariales tradicionales

El Plan de Pensiones de Empleo del RDL 13/2022 ha transformado la previsión empresarial española con un régimen fiscal más favorable. El límite de aportación del empleado pasa a ser de 1.500 EUR de aportación personal más 8.500 EUR de empleo, hasta 10.000 EUR anuales con deducción en la base imponible del IRPF. La aportación de la empresa es deducible en el Impuesto sobre Sociedades. Antes de la reforma el límite era de 1.500 EUR para todo, de modo que el nuevo esquema permite triplicar la capacidad de ahorro de empleo. La modalidad simplificada (PPES) reduce los requisitos formales para empresas medianas con un plan promovido por la negociación colectiva sectorial. El plan requiere autorización de la DGSFP, comisión de control paritaria, entidad gestora autorizada, depositario externo y auditoría anual de cuentas por un auditor inscrito en el ROAC. El incumplimiento puede sancionarse con hasta el 1 por ciento del patrimonio del plan, además de la suspensión o revocación de la autorización.

## Casos particulares de la inscripción española: Mutua, MUFACE, vehículo y vivienda

Hay varios casos especiales relevantes. La Mutua Colaboradora de la Seguridad Social gestiona las contingencias profesionales con pago de la empresa y reembolso desde el primer día, mientras que la incapacidad temporal por contingencia común la paga directamente el INSS a partir del día 16 (los primeros 15 los abona la empresa). Los funcionarios del Estado adscritos a MUFACE eligen cada año entre el INSS y entidades concertadas para la asistencia sanitaria. El vehículo de empresa se valora al 20 por ciento de su coste de adquisición anual, con corrección según el uso particular o profesional, y la vivienda al 5 o al 10 por ciento del valor catastral, con un máximo del 10 por ciento de la retribución total. Los productos o servicios de la empresa con descuento se valoran en cero si el descuento es generalizado para toda la plantilla. Los convenios colectivos sectoriales y de empresa prevalecen en las mejoras voluntarias del seguro colectivo.

## Integración con los sistemas de RRHH españoles y las plataformas de retribución flexible

El agente se integra por API con los principales sistemas de RRHH y plataformas de retribución flexible de España. Entre los sistemas de nómina y gestión están A3 Wolters Kluwer, líder del mercado; Sage NominaPlus; Cegid Visma Meta4 para gran empresa; Bizneo HR para la mediana empresa; Holded para la PYME; y las suites internacionales SAP SuccessFactors, Workday y Personio en sus versiones españolas, todas con integración al Sistema RED, la AEAT y la DGSFP. En retribución flexible se conecta con los especialistas Cobee, Edenred, Sodexo y Pluxee, que automatizan la fiscalidad del IRPF y la cotización. El agente opera contra los registros oficiales: el Sistema RED de la TGSS para las altas, la AEAT para los modelos 111 y 190 con el desglose de las rentas en especie, y la DGSFP para el registro y la auditoría anual del Plan de Pensiones de Empleo. Frente a la AEPD, cubre los requisitos de protección de datos de empleados, con DPIA, registro de actividades de tratamiento y contratos de encargo con las aseguradoras y plataformas.

--- Agente Selección Candidatos HR ---
> Selección candidatos: cribado CV + matching, ET art. 17 no discriminación, RGPD art. 22 prohibición decisión automatizada y EU AI Act Anexo III alto riesgo HR - shortlist auditable con DPIA/FRIA.

La selección de candidatos en las empresas españolas se sitúa entre cinco marcos de cumplimiento paralelos con consecuencias muy distintas. El Estatuto de los Trabajadores prohíbe la discriminación directa e indirecta en el acceso al empleo por razón de sexo, origen, religión, discapacidad, edad, orientación sexual, afiliación sindical o lengua, y declara nulas las cláusulas discriminatorias. La igualdad efectiva de la LO 3/2007, con su plan de igualdad y su registro retributivo, obliga a las empresas de más de 50 trabajadores a un diagnóstico, una auditoría retributiva y una comisión de seguimiento. El RGPD reconoce al candidato el derecho a no ser objeto de una decisión basada únicamente en el tratamiento automatizado que le afecte de forma significativa. El Reglamento Europeo de IA clasifica como de alto riesgo los sistemas destinados a la selección, con obligaciones de gestión de riesgos, calidad de los datos, transparencia y supervisión humana. Y la Directiva 2023/970 de transparencia retributiva prohíbe preguntar por el historial salarial del candidato y obliga a publicar la horquilla antes de la primera entrevista. En conjunto, cualquier proceso de selección en una empresa mediana o grande española puede activar a la vez hasta cinco obligaciones de cumplimiento distintas.

## Las sanciones acumuladas pueden superar 2 millones de euros

Las sanciones por un sistema de IA de cribado de candidatos son de las más altas del catálogo. La AESIA puede multar hasta el 7 por ciento de la facturación mundial por sistemas prohibidos, el 3 por ciento por incumplir las obligaciones de alto riesgo y el 1 por ciento por información incorrecta a las autoridades, además de retirar el sistema del mercado; está operativa en A Coruña desde 2025. La AEPD sanciona el tratamiento indebido de datos de candidatos, la decisión exclusivamente automatizada o la omisión de la DPIA hasta el 4 por ciento de la facturación mundial. La ITSS multa el incumplimiento del plan de igualdad o de la reserva del 2 por ciento de discapacidad como infracción muy grave, entre 6.251 y 187.515 EUR. Y el candidato puede reclamar judicialmente por discriminación en el plazo de 6 meses, con indemnización, nulidad del acto y reposición en el proceso. En una empresa mediana o grande con incumplimientos recurrentes, la suma puede superar los 2 millones de euros, más las reclamaciones judiciales individuales.

## Quince etapas: siete deterministas, seis asistidas por ML y dos confirmaciones humanas

El agente descompone la selección de candidatos en 15 microdecisiones: siete deterministas, seis asistidas por ML y dos confirmaciones humanas. Las deterministas cubren la completitud formal de la candidatura, los criterios eliminatorios objetivos, la anonimización del CV antes del matching, la validación de la reserva del 2 por ciento de discapacidad, la horquilla salarial de la transparencia retributiva, el registro ante la AESIA con DPIA y evaluación de impacto, y la accesibilidad del puesto. Las seis asistidas por ML son indicadores, no decisiones finales: el matching semántico contra el perfil, la identificación de lagunas con comunicación al candidato, la monitorización del sesgo, la generación de la shortlist auditable, la notificación al candidato rechazado y la sincronización con el ATS, la nómina y el onboarding. Las dos confirmaciones humanas obligatorias son la revisión de la shortlist por el reclutador y la documentación de la decisión de cribado con su razonamiento y su evidencia de no discriminación. El Decision Layer registra la trazabilidad de cada decisión para la defensa posterior ante reclamaciones judiciales o procedimientos sancionadores.

## Anonimización del CV, métricas de equidad y auditoría continua del sesgo

La prevención del sesgo demográfico exige una arquitectura tanto técnica como organizativa. La anonimización del CV antes del matching, conforme a la privacidad por diseño del art. 25 del RGPD, elimina el nombre, la foto, la edad, el género, la nacionalidad, la dirección y el lugar de nacimiento antes del análisis de IA; la reidentificación solo ocurre tras superar el matching, para la revisión humana del reclutador con justificación documentada. Los datos de entrenamiento deben ser representativos y libres de sesgo histórico, con auditoría de los conjuntos de datos. El agente aplica métricas de equidad continuas (paridad demográfica, igualdad de oportunidades y ratio de impacto dispar según la regla del 80 por ciento) y genera una alerta automática al equipo de cumplimiento, al DPO y a la Comisión de Igualdad si la disparidad supera el 20 por ciento sobre la línea base. El RD 902/2020 exige una auditoría retributiva cuando la brecha salarial supera el 25 por ciento sin justificación objetiva, y la LO 3/2007 impone un plan de igualdad a las empresas de más de 50 trabajadores. Para los sistemas de alto riesgo es obligatoria una auditoría externa anual con auditor independiente y entrega de la documentación a la AESIA, la AEPD y el Instituto de las Mujeres.

## Casos particulares de la selección española: reserva de discapacidad, transparencia retributiva, canal de denuncias y registro en la AESIA

Hay varios casos especiales relevantes. La reserva del 2 por ciento de empleo para personas con discapacidad obliga a las empresas de más de 50 trabajadores, con medidas alternativas excepcionales del SEPE (cuota a centros especiales de empleo, donaciones a fundaciones o servicios) bajo declaración de excepcionalidad. La Directiva 2023/970 de transparencia retributiva, con transposición prevista para el 7 de junio de 2026, prohíbe preguntar por el historial salarial, obliga a publicar la horquilla antes de la entrevista, da derecho a conocer los criterios de remuneración y exige un informe de brecha salarial en empresas de más de 100 personas. El canal de denuncias de la Ley 2/2023 es obligatorio en empresas de más de 50 trabajadores, con acceso anónimo, protección frente a represalias durante 3 años y la Autoridad Independiente como vía externa, con sanciones de hasta 1.000.000 EUR. El registro del sistema de alto riesgo en la AESIA conlleva la evaluación de conformidad y el marcado CE. La evaluación de impacto sobre derechos fundamentales del art. 27 analiza, antes del despliegue, los grupos afectados, el riesgo y las medidas de mitigación. Y la información al Comité de Empresa es obligatoria antes de desplegar un sistema de alto riesgo que afecte a los trabajadores, con un plazo de consulta de 15 días.

## Integración con los sistemas ATS y de RRHH españoles

El agente se integra por API con los principales sistemas ATS y de RRHH de España. Entre ellos están A3 Wolters Kluwer, líder del mercado; Sage Reclutamiento; Cegid Visma Meta4 para gran empresa; Bizneo HR, con entrevistas en vídeo y tests psicométricos; Holded para la PYME; y las suites internacionales SAP SuccessFactors, Workday y Personio en sus versiones españolas. También se conecta con plataformas especializadas de selección como Cornerstone, EvalArt, Greenhouse y Cegid Talentsoft, y con los portales de empleo (LinkedIn, InfoJobs, Indeed). Todas estas integraciones incorporan portal de candidato, matching de CV y audit-trail conforme al Reglamento Europeo de IA. El agente opera además contra los registros y obligaciones oficiales: la notificación del sistema de alto riesgo a la AESIA con su DPIA y evaluación de impacto, la información al Comité de Empresa, los requisitos de la AEPD sobre datos de candidatos y decisiones automatizadas, las prioridades de la ITSS en transparencia retributiva y reserva de discapacidad, el registro de planes de igualdad ante el Instituto de las Mujeres y el canal de denuncias de la Ley 2/2023 con la Autoridad Independiente.

--- Agente Seguimiento Certificaciones HR ---
> Seguimiento certificaciones obligatorias: LPRL art. 19 PRL, RD 773/1997 EPI, RD 393/2007 autoprotección y Ley 10/2010 AML - expedientes con alertas vencimiento y evidencia ITSS/INSST/FUNDAE.

El seguimiento de las certificaciones de formación obligatoria en las empresas españolas se sitúa entre cinco marcos de cumplimiento paralelos. La Ley 31/1995 de prevención obliga al empresario a garantizar una formación teórica y práctica suficiente al contratar, al cambiar de funciones y de forma periódica. El RD 773/1997 obliga a proporcionar los equipos de protección individual gratuitos y a formar sobre su uso correcto, con registro de entrega archivado. El RD 393/2007 de autoprotección exige a los centros con aforo superior a 2.000 personas un plan homologado por la autoridad de protección civil y un simulacro anual. La Ley 10/2010 antiblanqueo obliga a los sujetos obligados a un plan de formación con cursos sobre identificación de clientes, diligencia debida y comunicación al SEPBLAC, actualizado cada año. Y el RGPD obliga a las empresas que tratan datos a gran escala a designar un DPO con certificación oficial. En conjunto, cualquier proceso de seguimiento de certificaciones en una empresa mediana o grande española puede activar hasta cinco obligaciones de cumplimiento distintas.

## Las sanciones acumuladas pueden superar 1 millón de euros y paralizar la actividad

Las sanciones por el incumplimiento de la formación y las certificaciones son de las más elevadas del catálogo en sectores regulados. La ITSS multa el incumplimiento de la formación preventiva, los EPI, el plan de autoprotección o la vigilancia de la salud como infracción muy grave, entre 6.251 y 187.515 EUR, con paralización de la actividad y retirada de las bonificaciones a la Seguridad Social. La AEPD sanciona la falta de designación o de formación del DPO hasta el 4 por ciento de la facturación mundial. El SEPBLAC multa el incumplimiento de la formación antiblanqueo de los sujetos obligados hasta 10 millones de euros o el 10 por ciento de la facturación, con retirada de la autorización e inhabilitación. Y FUNDAE sanciona una bonificación improcedente con el reintegro del 100 por cien más un importe adicional. En una empresa mediana o grande con incumplimientos recurrentes en formación preventiva, EPI, autoprotección, vigilancia de la salud, antiblanqueo y bonificaciones, la suma puede superar 1 millón de euros, además de la paralización de la actividad y las reclamaciones judiciales por accidentes laborales.

## Catorce etapas: ocho deterministas, cuatro asistidas por ML y dos confirmaciones humanas

El agente descompone el seguimiento de certificaciones en 14 microdecisiones: ocho deterministas, cuatro asistidas por ML y dos confirmaciones humanas. Las deterministas cubren el registro de la certificación, su mapeo contra los requisitos del puesto y el convenio, la monitorización de los vencimientos con alertas a 90, 60 y 30 días, la comunicación a FUNDAE del inicio de la formación bonificada, la vigilancia de la salud de los trabajadores expuestos, el plan de autoprotección con su simulacro anual, la certificación del DPO y la formación antiblanqueo de los sujetos obligados. Las cuatro asistidas por ML son indicadores, no decisiones finales: la validación de la autenticidad del título, la identificación de la brecha de cumplimiento con su impacto operativo, la generación del expediente auditable y la sincronización con los sistemas de formación, nómina y prevención. Las dos confirmaciones humanas obligatorias son el escalado de los vencimientos críticos con la posible retirada del puesto regulado y la notificación a las autoridades sancionadoras. El Decision Layer registra la trazabilidad de cada decisión para la defensa posterior ante reclamaciones laborales o procedimientos sancionadores.

## Bonificación de FUNDAE: comunicación con antelación, control de asistencia y auditoría de la justificación

FUNDAE gestiona la bonificación de la formación programada por las empresas mediante un sistema de bonificación mensual de las cuotas a la Seguridad Social. El agente optimiza el proceso: comunica el inicio de la formación con 7 días naturales de antelación, con los datos de la acción formativa y el listado de participantes, y la finalización 7 días naturales después. El crédito de bonificación se calcula a partir del número de trabajadores y la cotización de formación profesional, con coeficientes correctores que aumentan el crédito para la PYME y la microempresa. Son bonificables la formación teórica, práctica, mixta y la teleformación, con un módulo económico por hora y persona. La justificación exige el control firmado de las horas de asistencia, la evaluación de los participantes, el diploma y la memoria final de la acción. FUNDAE audita mediante muestreo aleatorio, y el incumplimiento se sanciona con el reintegro del 100 por cien de la bonificación más un importe adicional y la comunicación a la ITSS.

## Casos particulares de las certificaciones españolas: construcción, instalaciones térmicas, autoprotección y vigilancia de la salud

Hay varios casos especiales relevantes. La Tarjeta Profesional de la Construcción es obligatoria para los trabajadores del sector, con 8 horas de tronco común de prevención, 20 horas específicas del oficio y un reciclaje cada 3 años, e implica que el subcontratista verifique la tarjeta de los empleados de la subcontrata; su incumplimiento es muy grave y puede paralizar la obra. El carnet profesional del RITE es obligatorio para los profesionales de instalación y mantenimiento de instalaciones térmicas, lo expide un organismo autorizado de la comunidad autónoma y se renueva cada 5 años. El plan de autoprotección es obligatorio para los centros con aforo superior a 2.000 personas o de riesgo especial, con la designación de los equipos de emergencia y un simulacro anual con su acta y sus correcciones. La vigilancia de la salud específica afecta a los trabajadores expuestos a riesgos concretos, con reconocimientos según los protocolos del INSST y una certificación de aptitud que, por secreto médico, solo comunica la aptitud al empresario. Los convenios colectivos prevalentes pueden añadir formación sectorial, permiso retribuido de formación y bonificación de FUNDAE.

## Integración con los sistemas de formación y de RRHH españoles

El agente se integra por API con los principales sistemas de gestión de la formación y de RRHH de España. Entre ellos están A3 Wolters Kluwer, líder del mercado; Sage Formación; Cegid Visma Meta4 para gran empresa; Bizneo HR para la mediana empresa; Holded para la PYME; y las suites internacionales SAP SuccessFactors, Workday y Personio en sus versiones españolas, todas con control de vencimientos, alertas de renovación e integración con el aplicativo de FUNDAE. También se conecta con plataformas especializadas como Cornerstone, KnowBe4 para la formación en ciberseguridad, y otros sistemas de gestión del aprendizaje, además del propio aplicativo telemático de FUNDAE. El agente opera contra las obligaciones y autoridades correspondientes: las prioridades de la ITSS en prevención, EPI, autoprotección y antiblanqueo; la coordinación del INSST en los protocolos sanitarios y la investigación de accidentes; los requisitos de la AEPD sobre la designación y formación del DPO; la supervisión del SEPBLAC sobre los sujetos obligados; y la auditoría de FUNDAE sobre la justificación de las bonificaciones, con su comunicación al Comité de Empresa.

--- Agente Benchmarking Retributivo ---
> Benchmarking retributivo: ET art. 28, RD 902/2020 registro, Pay Transparency 2023/970 (5% brecha) y CSRD ESRS S1-10 gender pay gap - análisis con evidencia ITSS/Instituto Mujer.

El benchmarking retributivo en las empresas españolas se sitúa entre cinco marcos de cumplimiento paralelos. El Estatuto de los Trabajadores obliga al empresario a pagar igual retribución por un trabajo de igual valor, concepto que el RD 902/2020 desarrolla con una valoración de puestos en cuatro factores: cualificación, esfuerzo, responsabilidad y condiciones de trabajo. Ese mismo real decreto obliga a un registro retributivo desagregado por sexo y a una auditoría retributiva cuando la brecha supera el 25 por ciento, junto con el plan de igualdad de las empresas de más de 50 trabajadores. La Directiva 2023/970 de transparencia retributiva, con transposición prevista para junio de 2026, añade el reporte de la brecha salarial, la evaluación conjunta cuando la brecha injustificada supera el 5 por ciento, la prohibición del historial retributivo y la banda salarial en la oferta. La Ley de Sociedades de Capital obliga a las sociedades cotizadas a una política de retribuciones de los consejeros aprobada por la Junta General. Y el reporte de sostenibilidad CSRD exige informar de la retribución, la brecha salarial mediana y la ratio entre el CEO y la mediana de la plantilla, con verificación de expertos independientes del ICAC. En conjunto, cualquier proceso de benchmarking en una empresa mediana o grande española puede activar hasta cinco obligaciones de cumplimiento distintas.

## Las sanciones acumuladas pueden superar 900.000 euros y paralizar la actividad

Las sanciones por el incumplimiento de la igualdad retributiva son de las más elevadas del catálogo. La ITSS multa el incumplimiento del registro retributivo, del plan de igualdad o la discriminación retributiva, así como la falta de la auditoría obligatoria cuando la brecha supera el 25 por ciento o las represalias contra un trabajador denunciante, como infracciones muy graves de hasta 225.018 EUR, con paralización de la actividad. La AEPD sanciona las decisiones automatizadas sobre la retribución hasta el 4 por ciento de la facturación mundial. La CNMV multa el incumplimiento de la política de retribuciones de los consejeros hasta 10 millones de euros, con suspensión de la cotización e inhabilitación de los administradores. La Autoridad Independiente sanciona las represalias contra el denunciante con hasta 1 millón de euros adicional, y el ICAC al auditor con la inhabilitación y una multa de hasta 1 millón. En una empresa mediana o grande con incumplimientos recurrentes en el registro retributivo, el plan de igualdad, la auditoría retributiva y la política de los consejeros, la suma puede superar los 900.000 euros, además de las reclamaciones individuales ante la jurisdicción social.

## Quince etapas: ocho deterministas, cuatro asistidas por ML y tres confirmaciones humanas

El agente descompone el benchmarking retributivo en 15 microdecisiones: ocho deterministas, cuatro asistidas por ML y tres confirmaciones humanas. Las deterministas cubren la recopilación de los datos retributivos desagregados por género, el cálculo del compa-ratio y el percentil de mercado, la validación de la política de retribuciones de los consejeros, el cálculo de la ratio entre el CEO y la mediana de la plantilla, la verificación del reporte CSRD y de la prohibición del historial retributivo, la notificación al Comité de Empresa y la sincronización con los demás sistemas. Las cuatro asistidas por ML son indicadores, no decisiones finales: el mapeo de los puestos contra los benchmarks, la identificación de la brecha salarial, la generación del registro retributivo y la sincronización. Las tres confirmaciones humanas obligatorias son la validación de la valoración de puestos en cuatro factores, la activación de la evaluación retributiva conjunta y de la auditoría, y la activación de la DPIA cuando un sistema de IA influye en una decisión retributiva. El Decision Layer registra la trazabilidad de cada decisión para la defensa posterior ante reclamaciones laborales por discriminación retributiva o procedimientos sancionadores.

## La auditoría retributiva del RD 86/2024 y la valoración de puestos en cuatro factores

El Real Decreto 86/2024 aprueba el reglamento de auditoría retributiva conforme a la Ley 10/2022 de medidas urgentes para la igualdad retributiva, con la metodología del Ministerio de Trabajo y el Instituto de las Mujeres. Sus componentes principales son varios. El sistema de valoración de puestos se apoya en cuatro factores: la cualificación (formación, experiencia y competencias), el esfuerzo (físico, mental y emocional), la responsabilidad (sobre personas, recursos y decisiones) y las condiciones de trabajo, cada uno con sus subfactores ponderados y su puntuación. La auditoría retributiva es obligatoria en las empresas con plan de igualdad y una brecha superior al 25 por ciento, e incluye un diagnóstico cualitativo y otro cuantitativo con análisis estadístico. De ella surge un plan de acción con medidas correctoras, plazos, responsable e indicadores de seguimiento, acordado con el Comité de Empresa y la comisión negociadora paritaria. El registro retributivo se presenta de forma telemática al Ministerio de Trabajo con datos agregados y anonimizados. Una empresa de 1.500 empleados, con 80 puestos, 5 niveles y 25 categorías, aplica esta metodología de valoración cruzándola con los benchmarks de mercado y el convenio sectorial.

## Casos particulares de la retribución española: salario en especie, retribución de consejeros, ratio CEO-mediana y CSRD

Hay varios casos especiales. El salario en especie tiene un máximo del 30 por ciento de la retribución total según el ET art. 26, con su valoración fiscal en el IRPF (las acciones cotizadas a valor de mercado y las no cotizadas por el mayor entre su valor teórico y la capitalización). El informe anual de retribuciones de las sociedades cotizadas se somete a voto consultivo de la Junta General, con un desglose individualizado por consejero, criterios de desempeño ESG y la referencia a benchmarks de sectores comparables. La ratio entre el CEO y la mediana de la plantilla, exigida por la norma CSRD y la Ley 11/2018, se sitúa habitualmente entre 80 y 300 veces en el IBEX-35, con tendencia al alza por el peso de la retribución variable de los ejecutivos. El reporte CSRD entra en vigor de forma escalonada, desde las grandes entidades de interés público hasta las filiales fuera de la UE, con verificación de expertos independientes del ICAC. Y los pagos basados en acciones se reconocen como gasto por su valor razonable en la fecha de concesión, conforme a la NIIF 2 y al Plan General de Contabilidad.

## Integración con los sistemas de compensación y los benchmarks españoles

El agente se integra por API con los principales sistemas de compensación y los benchmarks externos de España. Entre los sistemas están A3 Wolters Kluwer, líder del mercado; Sage Compensation; Cegid Visma Meta4 para gran empresa; Bizneo HR para la mediana empresa; Holded para la PYME; y las suites internacionales SAP SuccessFactors, Workday, Personio y Cornerstone en sus versiones españolas, con registro retributivo, análisis de la brecha salarial, bandas salariales y reporte CSRD. En el lado de los benchmarks se conecta con las consultoras retributivas de referencia (Mercer, WTW, Korn Ferry, Aon y Radford) y con las encuestas específicas del mercado español (ICSA Grupo, Bizalary y DataPaper), que alimentan la valoración de puestos del RD 86/2024. El agente coordina además las obligaciones con las autoridades: las prioridades de la ITSS en igualdad retributiva, la coordinación del Instituto de las Mujeres sobre el registro y la auditoría retributiva, los criterios de la AEPD sobre las decisiones automatizadas, la supervisión de la CNMV sobre las sociedades cotizadas, el registro ante la AESIA, las normas ESRS del ICAC y el canal de denuncias de la Ley 2/2023.

--- Agente Monitoreo Cumplimiento HR ---
> Monitoreo HR Real-Time: Equal-Pay-Index continuo RD 902/2020, plataforma denuncias Ley 2/2023, supervisión cadena suministro HR CSDDD y alertas - evidencia ITSS y AEPD.

La monitorización de cumplimiento en las empresas españolas se sitúa entre seis marcos paralelos. El Estatuto de los Trabajadores prohíbe las órdenes empresariales que supongan discriminación y reconoce el derecho de información del Comité de Empresa. La LO 3/2007 impone el plan de igualdad a las empresas de más de 50 trabajadores, junto con el registro retributivo y el protocolo de prevención del acoso. La Ley 2/2023 obliga a un canal interno de denuncias, con plazos de 7 días para el acuse y 3 meses para la respuesta y sanciones de hasta 1 millón de euros. El RGPD y la LOPDGDD imponen el registro de actividades de tratamiento, las medidas de seguridad y la DPIA. El Código Penal regula la responsabilidad penal de la persona jurídica, atenuada por los programas de cumplimiento. Y el Reglamento Europeo de IA, supervisado en España por la AESIA, clasifica como de alto riesgo los sistemas de IA en el empleo. En conjunto, cualquier proceso de monitorización en una empresa mediana o grande española puede activar hasta seis obligaciones acumuladas.

## Sanciones acumulables superan 2 millones EUR

La ITSS multa las infracciones laborales muy graves entre 7.501 y 225.018 EUR, con paralización de la actividad y retirada de las bonificaciones, en materias como el plan de igualdad, el protocolo de acoso o la discriminación retributiva. La AEPD sanciona hasta el 4 por ciento de la facturación mundial. La Autoridad Independiente multa las represalias contra el denunciante con hasta 1 millón de euros. El SEPBLAC sanciona el blanqueo hasta 10 millones de euros. La AESIA puede llegar al 7 por ciento de la facturación por sistemas de IA prohibidos. Y el Código Penal contempla la responsabilidad penal de la persona jurídica, con multa proporcional, suspensión de actividades, prohibición de contratar con las administraciones públicas y, en el extremo, su disolución, además de la responsabilidad civil de los administradores. En una empresa mediana o grande con incumplimientos recurrentes, la suma puede superar los 2 millones de euros, más la responsabilidad penal y las reclamaciones ante la jurisdicción social.

## La brecha temporal es donde nace el riesgo

Las infracciones compliance rara vez nacen de la intención. Nacen de la distancia entre el momento en que una norma cambia y el momento en que la práctica operativa se adapta. Una actualización Convenio Colectivo entra en vigor 1 abril, pero nómina abril ejecuta valores anteriores porque RRHH no registró ajuste hasta día 5.

Thomson Reuters Regulatory Intelligence contabilizó más de 61.000 eventos regulatorios en el mundo en 2022, unos 234 cambios al día. Solo la transposición de la transparencia retributiva antes de junio de 2026, el Reglamento Europeo de IA, la diligencia debida en sostenibilidad y los derechos digitales de la Ley 12/2024 exigen una revisión completa de las estructuras de cumplimiento.

En la mayoría de las empresas, la verificación de los marcos normativos es puntual: una auditoría externa al año y una reacción ante las denuncias. Entre esos puntos de control pueden pasar meses con desviaciones sin detectar. Y una sola infracción del plan de igualdad puede sancionarse hasta 225.018 EUR como muy grave.

## Monitorización continua cambia la estructura del problema

La diferencia entre verificación periódica y monitorización continua no es gradual - es estructural. Verificación periódica examina muestra momento dado. Monitorización continua comprueba cada transacción contra cada regla relevante cada vez. El sistema consta cuatro capas:

**Un catálogo de reglas verificables.** Cada marco normativo (la ley, el convenio colectivo, los acuerdos internos y los estándares ISO) se traduce en reglas comprobables por la máquina. La prohibición de discriminación del Estatuto de los Trabajadores, por ejemplo, se convierte en una regla que contrasta los datos de selección, promoción, retribución y formación. Cada regla lleva su número de versión, su periodo de vigencia, su fuente legal, su categoría de gravedad y su frecuencia de comprobación.

**La conexión con las fuentes de datos.** El agente se conecta con la nómina, el ATS, la planificación de turnos, el registro horario, el plan de igualdad, el canal de denuncias y las plataformas GRC. El agente lee, no escribe. El registro de actividades de tratamiento documenta cada conexión, con control de acceso por roles y cifrado en tránsito.

**La clasificación de las desviaciones por gravedad.** Que un empleado trabaje 15 minutos más allá de la pausa reglamentaria es información; un incumplimiento sistemático del plan de igualdad en un departamento durante tres semanas es un hallazgo crítico. La matriz va de la información a la advertencia, lo crítico y la escalación. Una desviación comunicable a una autoridad como la ITSS, la AEPD o la Fiscalía activa a la Dirección, el Comité de Compliance y el Consejo de Administración en 24 horas.

**La escalación y el seguimiento.** La matriz determina quién recibe la información según la gravedad: el responsable del proceso, el Compliance Officer, el DPO, el Comité de Empresa o el Consejo de Administración. Tras un intervalo definido se verifica de nuevo, y el caso solo se cierra cuando la desviación se ha corregido de forma efectiva. El audit-trail del Decision Layer guarda la trazabilidad de cada decisión para la defensa posterior ante reclamaciones por discriminación o acoso y procedimientos sancionadores.

## Trece etapas: siete deterministas, una asistida por ML y cinco confirmaciones humanas

El agente descompone la monitorización de cumplimiento en 13 microdecisiones: siete deterministas, una asistida por ML y cinco confirmaciones humanas. Las deterministas cubren la conexión a las fuentes de datos en modo solo lectura, la ejecución de las comprobaciones continuas con su clasificación de gravedad, la verificación del registro de tratamientos y la DPIA, la cuota del 2 por ciento de discapacidad, la prevención del blanqueo de capitales, el reporte CSRD y la notificación al Comité de Empresa. La única asistida por ML es un indicador, no una decisión final: la detección de anomalías y el control del sesgo algorítmico. Las cinco confirmaciones humanas obligatorias son el inventario del marco normativo, su traducción a reglas verificables, la tramitación de una denuncia del canal, la activación del protocolo de prevención del acoso y la del programa de cumplimiento penal.

## Donde permanece la responsabilidad

El agente detecta las desviaciones, las clasifica, las escala, las documenta y verifica si la corrección funciona. Lo que no hace es decidir qué ocurre: si un exceso de jornada deriva en una amonestación, si un error de nómina se corrige de forma retroactiva o si un incidente es comunicable a una autoridad, eso lo decide una persona. Y la responsabilidad por la causa de la desviación recae en el responsable del departamento competente, no en el empleado individual. Esa separación es la razón por la que el sistema no es de alto riesgo según el Reglamento Europeo de IA: monitoriza y señala, pero no decide sobre las relaciones laborales, lo que permite operar sin que el procedimiento de clasificación de riesgo retrase el despliegue. El Comité de Empresa mantiene su derecho de información sobre el alcance de la monitorización, el plan de igualdad, la auditoría retributiva, el protocolo de acoso y el canal de denuncias.

## El programa de cumplimiento penal del art. 31 bis del Código Penal

El art. 31 bis del Código Penal establece la responsabilidad penal de la persona jurídica y la atenúa cuando existe un programa de cumplimiento penal. Ese programa exige un modelo de organización y prevención de delitos con su código ético, un órgano de control independiente que reporta al Consejo de Administración, un canal de denuncias confidencial, un sistema disciplinario y una revisión anual, con certificación externa conforme a las normas UNE 19601 e ISO 37301. Entre los delitos imputables a la persona jurídica están el cohecho, el tráfico de influencias, el blanqueo de capitales, los delitos fiscales, los delitos contra los trabajadores, los delitos contra el medio ambiente y la revelación de secretos.

## Casos particulares del cumplimiento español

Hay varios casos especiales relevantes. La cuota del 2 por ciento de empleo para personas con discapacidad obliga a las empresas de más de 50 trabajadores, con medidas alternativas y una sanción muy grave de hasta 225.018 EUR. El antiblanqueo de la Ley 10/2010 obliga a los sujetos obligados (entidades financieras, auditores, abogados, notarios, agentes inmobiliarios o prestadores de servicios de monedas virtuales) a la diligencia debida con el cliente, la comunicación de operaciones sospechosas al SEPBLAC y la retención durante 10 años, con sanciones de hasta 10 millones de euros. El Reglamento Europeo de IA conlleva el registro de los sistemas de alto riesgo ante la AESIA, con DPIA y supervisión humana, y sanciones de hasta el 7 por ciento de la facturación. La diligencia debida en sostenibilidad de la Directiva CSDDD, con transposición prevista para 2027, y el reporte CSRD del RD 109/2025 exigen informar de los incidentes de discriminación y la conducta empresarial, con verificación de expertos independientes del ICAC. Y los derechos digitales de la Ley 12/2024 reconocen la desconexión digital y la intimidad frente a los sistemas de videovigilancia y geolocalización.

## Integración con sistemas Compliance españoles

El agente se integra con los principales sistemas de cumplimiento de España. Entre ellos están A3 Wolters Kluwer, líder del mercado; Sage Compliance; Cegid Visma Meta4 para gran empresa; Bizneo HR, con su canal de denuncias; Holded y Factorial para la PYME; y las suites internacionales SAP SuccessFactors, Workday y Personio en sus versiones españolas, con los estándares de cumplimiento penal. También se conecta con plataformas GRC de referencia (ServiceNow, Diligent y OneTrust), con especialistas en canal de denuncias como NAVEX y EQS Group, y con las editoriales jurídicas que mantienen la normativa actualizada. El agente coordina además las obligaciones con las autoridades: las prioridades de la ITSS y la AEPD, la Autoridad Independiente de la Ley 2/2023, el SEPBLAC, la AESIA, las normas ESRS del ICAC, la Fiscalía Anticorrupción y el derecho de información del Comité de Empresa.

--- Agente Formación Compliance HR ---
> Formación compliance obligatoria: ET art. 23 permiso 20h, LPRL art. 19 PRL, Ley 2/2023 denunciantes y AI literacy EU AI Act - tracking LMS y bonificación FUNDAE auditable.

La formación obligatoria en las empresas españolas se reparte entre seis frentes paralelos. El Estatuto de los Trabajadores reconoce el permiso de formación de 20 horas al año (art. 23), el acceso sin discriminación (art. 17) y el derecho de información del comité de empresa (art. 64). La Ley de Prevención de Riesgos Laborales obliga a una formación preventiva específica del puesto (art. 19). La Ley de Igualdad exige un plan de formación en igualdad en las empresas de más de 50 trabajadores. La Ley 2/2023 impone formación sobre el canal de denuncias, con sanciones de hasta 1 millón de euros por represalias. El RGPD exige sensibilizar al personal en protección de datos. El Código Penal liga el atenuante de responsabilidad de la persona jurídica a la formación ética del programa de compliance (art. 31 bis), y el Reglamento Europeo de IA añade desde agosto de 2026 la alfabetización en IA. La consecuencia: cualquier proceso de formación en una empresa de 500 a 5.000 empleados puede activar a la vez hasta seis obligaciones distintas."

## Sanciones acumulables superan 2 millones EUR

Las sanciones por incumplir la formación obligatoria se acumulan por vías independientes. La Inspección de Trabajo puede llegar a 225.018 euros por las faltas más graves y a 187.515 euros por la formación preventiva, con paralización de la actividad. La AEPD puede imponer hasta el 4% de la facturación mundial por sensibilización insuficiente en protección de datos. Las represalias contra un denunciante alcanzan 1 millón de euros, y la formación insuficiente de los sujetos obligados en prevención de blanqueo, hasta 10 millones. El Reglamento Europeo de IA sanciona la alfabetización en IA insuficiente, y la NIS2 la formación en ciberseguridad. Por último, la formación ética insuficiente hace perder el atenuante penal del programa de compliance y arrastra la responsabilidad civil de los administradores. La suma puede superar los 2 millones de euros.

## El auditor está sentado, 16 justificantes faltan

Un inspector de la Inspección de Trabajo está sentado en su sala de reuniones. Pregunta por el justificante de que sus 47 operarios de almacén han completado la formación anual obligatoria en prevención de riesgos laborales conforme art. 19 LPRL. Su responsable de cumplimiento abre una hoja de cálculo, busca, desplaza, encuentra 31 registros. Los otros 16 faltan. Quizá formados pero no documentados. Quizá documentados pero en otra carpeta. Quizá olvidados.

Esto no es el peor escenario, es un martes cualquiera. Y la sanción puede alcanzar 187.515 euros por infracción, no como suma global. Si ocurre un accidente laboral sin formación documentada, la empresa se enfrenta a consecuencias penales para la dirección por los delitos contra los trabajadores, además de la responsabilidad civil de los administradores.

## La presión regulatoria crece más rápido que la capacidad administrativa

Solo desde 2024, la transposición de la NIS2 ha añadido formación obligatoria en ciberseguridad para amplios sectores de la economía española, desde la energía y el transporte hasta las finanzas, la salud o la administración pública. La alfabetización en IA del Reglamento Europeo de IA trae desde agosto de 2026 nuevas obligaciones para las empresas que desplieguen u operen sistemas de IA. Y la transposición de la CSRD obliga al reporting de sostenibilidad sobre formación, con métricas de porcentaje de empleados formados, horas medias por empleado y presupuesto.

## La brecha temporal donde nace el riesgo

Las infracciones de la formación obligatoria rara vez nacen de la intención. Nacen de la distancia entre el momento en que cambia la norma y el momento en que la práctica se adapta. Una actualización del convenio entra en vigor el 1 de abril, pero la formación de abril sigue ejecutando el plan anterior porque RRHH no registró el ajuste hasta el día 5. La NIS2 obliga a formar en ciberseguridad a los sectores esenciales, pero el LMS aún no tiene los cursos asignados.

Thomson Reuters Regulatory Intelligence contabilizó más de 61.000 eventos regulatorios en el mundo en 2022, unos 234 cambios al día. Solo la Transparencia Retributiva, la alfabetización en IA, la CSDDD, la Carta de Derechos Digitales y la NIS2 exigen revisar a fondo las estructuras de formación, el plan formativo, el canal de denuncias, el programa de compliance penal y el reporting de sostenibilidad.

La mayoría de las empresas verifica el cumplimiento de la formación de forma puntual: una auditoría externa al año y, por lo demás, de manera reactiva ante las inspecciones. Entre esos puntos de control pueden pasar meses con lagunas sin detectar, y una sola infracción de la formación preventiva puede sancionarse con hasta 187.515 euros.

## Lo que el agente transforma

El agente no resuelve el problema con mejores listas, sino con una arquitectura distinta: en lugar de una gestión reactiva, control proactivo con reformación periódica. **Asignación automática.** Cuando un empleado ocupa un puesto, un motor de reglas deriva el catálogo completo de formaciones a partir del puesto, el departamento, el centro de trabajo, el convenio aplicable, la sujeción a la prevención de blanqueo y el nivel de acceso a los datos. No es el técnico de RRHH quien decide qué formaciones son relevantes: el motor de reglas lo infiere.

## La aritmética brecha cumplimiento

Tomemos una empresa industrial de 1.200 empleados con seis tipos de formación obligatoria: prevención de riesgos, igualdad, canal de denuncias, protección de datos, prevención de blanqueo y ética del programa de compliance. Eso genera 7.200 obligaciones formativas individuales al año. Con una tasa realista de cumplimiento del 78%, que muchas empresas consideran aceptable, quedan 1.584 obligaciones sin justificante.

Son 1.584 flancos abiertos. Cada uno es un hallazgo potencial en la próxima inspección y un riesgo de responsabilidad penal si ocurre algo, además del reintegro de las bonificaciones de FUNDAE.

El agente no trabaja con tasas de cumplimiento, sino con riesgo residual: qué obligaciones concretas vencen en los próximos 30 días, cuáles están vencidas, a quién se le ha recordado tres veces sin completar, y dónde debe intervenir un responsable porque el sistema por sí solo no puede avanzar más.

## 14 microdecisiones: 8 deterministas, 2 asistidas por IA y 4 humanas

El agente descompone la formación de cumplimiento en 14 microdecisiones. Las ocho deterministas determinan los requisitos formativos de cada empleado, comprueban el estado de completitud y las caducidades, envían los recordatorios escalados, hacen el seguimiento y la reformación periódica, escalan los incumplimientos, activan la reformación ante detonantes excepcionales, verifican el reporting de sostenibilidad ESRS S1-13 e informan al comité de empresa. Las dos asistidas por IA inscriben los cursos en el LMS y cotejan los certificados extrayendo sus datos. Otras dos generan de forma automática el paquete de evidencias para cada organismo. Y las cuatro confirmaciones humanas cubren el inventario del marco normativo, la construcción de la matriz de requisitos por puesto y las decisiones críticas del Compliance Officer.

## Donde permanece responsabilidad

El agente asigna las formaciones, las sigue, las escala, las documenta y verifica si la reformación funciona. Lo que no hace es decidir qué ocurre después: si una laguna formativa deriva en amonestación, si un error de registro se corrige con efecto retroactivo o si un incidente debe comunicarse a la autoridad lo decide una persona. La responsabilidad por la laguna recae en el responsable del departamento, el Compliance Officer, la Dirección y el Consejo de Administración. Esa separación es la razón por la que el sistema no es de alto riesgo según el Reglamento Europeo de IA: administra la logística de la formación sin decidir sobre la relación laboral, de modo que el despliegue no queda frenado por el procedimiento de clasificación de riesgo. El comité de empresa conserva su derecho de información sobre el plan de formación, su presupuesto y el plan de igualdad.

## Re-formación obligatoria activadores excepcionales

Un cambio de funciones o de tecnología obliga a formación específica conforme al art. 19 LPRL. Un accidente laboral añade formación preventiva adicional. Una denuncia de acoso confirmada activa el plan de acción de la comisión instructora y formación para el supervisor implicado. Una brecha de datos comunicada a la AEPD exige formación reforzada para los empleados afectados. Y un cambio normativo relevante reevalúa la matriz, dispara una asignación masiva de cursos nuevos y se comunica al comité de empresa. El agente activa la reformación de forma automática a partir de los datos maestros de los sistemas de RRHH.

## Edge-cases formación españoles

El art. 23 ET reconoce un permiso individual de formación de 20 horas al año, acumulables hasta cinco años, para los trabajadores con al menos un año de antigüedad. Es tiempo retribuido y el convenio colectivo aplicable puede mejorarlo.

## Integración con sistemas Formación españoles

El agente se integra con las plataformas líderes en España. A3 de Wolters Kluwer y Sage NominaPlus son los más extendidos en el mercado. Cegid Meta4 y Cegid Talentsoft dominan en las grandes cotizadas. Bizneo, con su módulo de canal de denuncias, y Factorial o Holded cubren a las pymes. Y SAP SuccessFactors, con sus módulos de gobierno y auditoría, atiende al segmento enterprise con certificación en compliance penal según la norma UNE 19601.

--- Agente Contrato y Oferta HR ---
> Generación contrato laboral: ET art. 8/14/15, RDL 32/2021, Pay Transparency 2023/970 horquilla y firma eIDAS - cláusulas verificadas y comunicación SEPE Contrat@.

Un contrato laboral en España no es un documento, sino una cadena de decisiones documentadas: elegir la modalidad conforme a la Reforma Laboral, seleccionar la plantilla del convenio aplicable, poblarla con los datos de la oferta, verificar las cláusulas obligatorias del Estatuto, validar la horquilla salarial, añadir las cláusulas contextuales, pasar la revisión de Asesoría Jurídica, firmar con eIDAS y comunicar al SEPE. La generación del contrato se reparte entre seis frentes paralelos. El Estatuto de los Trabajadores regula la forma, el periodo de prueba, las modalidades, la no discriminación y la no competencia. La Reforma Laboral elimina el contrato de obra y servicio, endurece el régimen de los temporales fraudulentos y convierte en indefinida la concatenación abusiva. La Transparencia Retributiva obliga a publicar la horquilla salarial en la oferta y prohíbe preguntar por el historial retributivo. La Ley 2/2023 exige la cláusula informativa del canal de denuncias en empresas de más de 50 personas. El RGPD fija la base legal del tratamiento de datos. Y los más de 1.400 convenios colectivos prevalecen con sus condiciones más beneficiosas.

## Sanciones acumulables superan 2 millones EUR

Las sanciones se acumulan por vías independientes. La Inspección de Trabajo puede llegar a 225.018 euros por un contrato temporal fraudulento, por omitir la copia básica o la comunicación al SEPE, o por la concatenación abusiva que convierte el contrato en indefinido. El incumplimiento del registro retributivo o del plan de igualdad alcanza la misma cuantía. La AEPD puede imponer hasta el 4% de la facturación mundial por una base legal incorrecta o una decisión automatizada sin intervención humana. Las represalias contra un denunciante llegan a 1 millón de euros. A ello se suman la cotización adicional de los contratos de menos de 30 días, la responsabilidad civil de los administradores y, en la jurisdicción social, la indemnización por despido improcedente. La suma puede superar los 2 millones de euros.

## Tres semanas hasta el contrato, dos cláusulas faltantes

Una empresa 200 contrataciones año tiene biblioteca plantillas tres centros trabajo, contratos bajo Convenio Colectivo REGCON y fuera Convenio, modalidades temporales e indefinidos. Necesita mínimo doce plantillas. En la práctica existen treinta porque cada sede ha hecho adaptaciones, porque versión antigua no se eliminó, porque caso especial año pasado alguien creó copia. Qué plantilla está vigente no lo sabe con certeza nadie.

Cuando llega la solicitud de un candidato ya aprobado, el técnico de RRHH busca la plantilla, abre Word, rellena los campos a mano desde la carta de oferta, guarda el PDF y lo envía por correo. Tres semanas después, el candidato lee el contrato y descubre que el periodo de prueba dice seis meses cuando en la oferta se pactaron dos. Otro contrato omite la cláusula del canal de denuncias, obligatoria desde 2023. Y un tercero, temporal, alega un contrato de obra y servicio que la Reforma Laboral eliminó: se convierte automáticamente en indefinido, con multa de la Tesorería y reintegro de las bonificaciones.

## La presión regulatoria crece más rápido que la capacidad administrativa

Desde 2021, la Reforma Laboral eliminó el contrato de obra y servicio, endureció el régimen de los temporales fraudulentos e introdujo una cotización adicional para los contratos de menos de 30 días. La Transparencia Retributiva, que España debe transponer antes de junio de 2026, obliga a publicar la horquilla salarial en la oferta, prohíbe preguntar por el historial retributivo y exige reportar la brecha salarial con un plan correctivo cuando supera el 5%. La Ley 2/2023 impone la cláusula informativa del canal de denuncias en las empresas de más de 50 personas. Y el Reglamento Europeo de IA añade desde agosto de 2026 la alfabetización en IA.

## La brecha temporal donde nace el riesgo

Las infracciones en la generación de contratos rara vez nacen de la intención. Nacen de la distancia entre el momento en que cambia la norma y el momento en que la práctica se adapta. Una actualización del convenio entra en vigor el 1 de abril, pero las plantillas de abril siguen ejecutando la versión anterior porque RRHH no registró el ajuste hasta el día 5. La Transparencia Retributiva obliga a publicar la horquilla salarial, pero las plantillas siguen contemplando cláusulas de confidencialidad. Y los convenios de la química, la banca o la construcción, junto con los más de 1.400 vigentes, cambian con frecuencia. La mayoría de las empresas verifica el cumplimiento de forma puntual: una auditoría al año y, por lo demás, de manera reactiva ante las inspecciones.

## Lo que el agente transforma

El agente no resuelve el problema con mejores plantillas, sino con una arquitectura distinta: en lugar de una gestión reactiva, generación proactiva con validación por reglas y revisión legal humana. **Determinación de la modalidad.** Cuando llega la solicitud, el motor de reglas determina la modalidad conforme a la Reforma Laboral a partir del tipo de puesto y la causa temporal documentada. No es el técnico de RRHH quien decide qué modalidad procede: el motor la infiere y exige la causa documentada. **Selección de la plantilla.** De una biblioteca certificada, versionada por modalidad, categoría profesional, convenio aplicable y comunidad autónoma, siempre en su versión vigente actualizada con las últimas reformas. **Validación de la horquilla salarial.** Comprueba que la retribución pactada cae dentro de la horquilla de la oferta, y una brecha superior al 5% activa el plan correctivo.

## 14 microdecisiones: 8 deterministas, 3 asistidas por IA y 3 humanas

El agente descompone la generación del contrato en 14 microdecisiones. Las ocho deterministas cubren la ingesta de los datos de la oferta, la determinación de la modalidad, la selección de la plantilla, la validación de la horquilla salarial, la verificación de las cláusulas obligatorias, la consistencia interna, el enrutamiento a revisión legal y la comunicación al comité de empresa y al SEPE. Las tres asistidas por IA poblan los parámetros, recomiendan las cláusulas adicionales y generan el paquete de evidencias. Y las tres confirmaciones humanas son el inventario del marco normativo, la revisión de Asesoría Jurídica y la autorización de la emisión.

## Donde permanece responsabilidad

El agente genera el contrato, valida las cláusulas obligatorias, recomienda las adicionales y enruta la revisión legal. Lo que no hace es decidir qué ocurre: si la retribución debe ajustarse, si el pacto de no competencia es proporcional, si la modalidad temporal está justificada o si se autoriza la emisión lo decide una persona de Asesoría Jurídica, RRHH o el Compliance Officer. La responsabilidad por la exactitud legal del contrato recae en Asesoría Jurídica, RRHH y el Consejo de Administración. Esa separación es la razón por la que el sistema no es de alto riesgo según el Reglamento Europeo de IA: genera documentos y valida cláusulas sin decidir sobre la relación laboral, de modo que el despliegue no queda frenado por el procedimiento de clasificación de riesgo. El comité de empresa conserva su derecho de información sobre el plan de plantilla y el de igualdad.

## Edge-cases generación contratos españoles

Algunas modalidades exigen revisión legal obligatoria: la alta dirección, los extranjeros con visado de profesional altamente cualificado, el desplazamiento internacional y el servicio del hogar familiar. El pacto de no competencia tras la extinción del contrato, propio de directivos y comerciales con contacto con clientes, no puede superar los dos años para los técnicos ni los seis meses para el resto, debe compensarse económicamente en proporción a su duración y exige un interés industrial específico y documentado.

## Integración con sistemas RRHH españoles

El agente se integra con las plataformas líderes en España. A3 de Wolters Kluwer y Sage NominaPlus son los más extendidos en el mercado. Cegid Meta4 y Cegid Talentsoft dominan en las grandes cotizadas. Bizneo, con su módulo de canal de denuncias, y Factorial, Holded o Personio cubren a las pymes, mientras que SAP SuccessFactors y Workday atienden al segmento enterprise. La firma electrónica cualificada se canaliza a través de prestadores de confianza certificados como Signaturit, líder en España con identificación por videoconferencia, Validated ID, DocuSign, Adobe Sign o Lleida.net, todos inscritos en la lista oficial de servicios de confianza.

--- Agente Datos Maestros Empleados HR ---
> Plataforma datos maestros empleados: RGPD art. 5 minimización, art. 17 Derecho al Olvido y LOPDGDD art. 87-91 - Master-Data-Management con DPIA y comité empresa ET art. 64.

Un cambio de dirección de un empleado en España no es una operación administrativa, sino una cadena de decisiones documentadas: clasificar el dato según su categoría en el RGPD, asignarle una base legal, aplicar la minimización, fijar un plazo de retención justificado, sincronizarlo entre todos los sistemas y dejarlo trazado en el Decision Layer, sin olvidar el derecho al olvido. La gestión de los datos maestros se reparte entre seis frentes paralelos: el RGPD, los derechos digitales de la LOPDGDD (monitorización, videovigilancia, geolocalización, desconexión), el control empresarial de los datos en el Estatuto, el plan estratégico de la AEPD y la Carta de Derechos Digitales, la Ley 2/2023 del canal de denuncias y la NIS2 con sus plazos de notificación al INCIBE.

## Sanciones acumulables superan 5 millones EUR

Las sanciones se acumulan por vías independientes. La AEPD puede llegar al 4% de la facturación mundial por una base legal incorrecta, por tratar categorías especiales sin base reforzada, por la falta del registro de tratamiento o de la evaluación de impacto, o por incumplir el derecho al olvido; y hasta el 2% por no notificar una brecha en 72 horas. La Inspección de Trabajo puede imponer hasta 225.018 euros por datos discriminatorios o monitorización abusiva. Las represalias contra un denunciante alcanzan 1 millón de euros, y una brecha en un sector esencial llega hasta el 2% de la facturación por la NIS2. A todo ello se suma la responsabilidad civil de los administradores. La suma puede superar los 5 millones de euros.

## Tres semanas hasta sincronización, dos sistemas con datos contradictorios

Una empresa de 1.500 empleados con tres centros de trabajo opera el sistema maestro en A3, el control horario en Cegid Meta4, los accesos en SAP, el portal en Personio, el plan de pensiones en Bizneo y el canal de denuncias por separado. Cuando un empleado se muda y comunica su nueva dirección, el técnico de RRHH actualiza A3, abre Cegid, cambia el dato, accede a SAP y envía un correo a Personio. Tres semanas después llega la nómina a la dirección antigua porque la actualización en Personio quedó pendiente durante las vacaciones del técnico. Otro empleado cambia de situación fiscal, pero el técnico olvida la mutua, y la AEPD detecta la deriva en una auditoría. Y un tercero pide el derecho al olvido, pero la supresión en el canal de denuncias queda pendiente, y llega una sanción de 200.000 euros.

## Por qué los datos maestros no son un problema administrativo, sino de sincronización

Este agente sigue el principio del Decision Layer: cada decisión se basa en reglas, se asiste con IA o se asigna a una persona del equipo de protección de datos. A partir de 500 empleados, cada cambio desencadena una reacción en cadena de tres a siete sistemas: personal, nómina, control horario, accesos, plan de pensiones, portal del empleado y canal de denuncias. Y cada uno tiene sus propias reglas de validación, permisos, retención y base legal.

El 37% de los errores de nómina se originan en la introducción manual de datos, con un coste medio de 265 euros por error. Para 1.000 empleados, eso supone 230.000 euros al año, sin contar la sanción de la AEPD por tratar categorías especiales sin base legal. La tasa de error crece de forma exponencial: cada sistema de destino adicional multiplica la probabilidad de una sincronización olvidada y de una brecha de seguridad.

## Donde se produce daño real

El daño visible es la nómina incorrecta. El invisible, más grave, es que la AEPD detecte un tratamiento de categorías especiales sin base reforzada o sin evaluación de impacto: una sanción de hasta el 4% de la facturación. Un tercio de las empresas reconoce que no tiene definidas las reglas de mantenimiento de sus datos maestros, y nadie sabe si todos los sistemas tienen el mismo estado.

Las consecuencias son cuatro. **Inconsistencias en la nómina:** la situación fiscal cambia en el sistema de RRHH pero no en la nómina, y la empresa acaba regularizando ante Hacienda. **Infracciones del RGPD** por el principio de exactitud del art. 5.1.d: si tres sistemas muestran tres direcciones distintas, ninguno demuestra cuál es la correcta. **Riesgos en una auditoría**, cuando los inspectores encuentran discrepancias entre sistemas. Y **pérdida de confianza del empleado:** un 22% reporta retrasos o errores en la nómina, con derecho a la intervención humana del art. 22 RGPD.

## La presión regulatoria crece más rápido que capacidad administrativa

Desde 2018, la LOPDGDD añadió los derechos digitales de los empleados al RGPD. En 2023 llegó la Ley 2/2023 del canal de denuncias. Y desde 2024 se suman el Reglamento Europeo de IA, la Carta de Derechos Digitales y la NIS2. El plan estratégico de la AEPD para 2024-2027 da prioridad a los datos laborales, la IA en RRHH, el canal de denuncias y la biometría.

## La brecha temporal donde nace riesgo

Las infracciones en la gestión de los datos nacen de la distancia entre el momento en que cambia la norma y el momento en que la práctica se adapta. Un nuevo derecho digital entra en vigor, pero la política de monitorización sigue ejecutando la versión anterior porque RRHH no registró el ajuste con el comité de empresa. La Carta de Derechos Digitales obliga a la transparencia algorítmica en las decisiones automatizadas, pero la plataforma de RRHH sigue sin informar de su lógica ni de sus consecuencias. Y los convenios de la química, la banca o la construcción, junto con los más de 1.400 vigentes, cambian con frecuencia sus cláusulas sobre los datos de los empleados.

## Por qué automatización sola no basta

No todos los cambios de los datos maestros son iguales. Un cambio de dirección puede ejecutarse de forma totalmente automática: comprobar la plausibilidad con el código postal y propagarlo a todos los sistemas. Pero un cambio de cuenta bancaria exige validar el IBAN y una doble aprobación de RRHH y Finanzas, porque automatizarlo del todo sería un riesgo de seguridad ante la ingeniería social.

Un cambio de estado civil desencadena efectos fiscales y de Seguridad Social: tres cambios en seis meses pueden ser formalmente correctos, pero forman un patrón que una persona debería valorar. Un dato de salud, de categoría especial, requiere base reforzada, el servicio de prevención, secreto médico y acceso restringido al DPO. Y un cambio de afiliación sindical exige informar al comité de empresa.

Cada tipo de cambio necesita un camino de decisión distinto: reglas, reconocimiento de patrones con IA o el juicio humano del DPO con la base legal aplicable.

## Lo que el agente transforma

El agente aporta una arquitectura distinta: clasificación proactiva de las categorías del RGPD, minimización, protección desde el diseño, revisión humana del DPO y sincronización cifrada entre sistemas. **Clasificación del dato.** El motor de reglas determina la categoría del RGPD (identificación, económicos, especiales del art. 9, compliance) a partir del tipo de dato y su base legal. **Validación de entrada.** Comprobación del formato por algoritmo, plausibilidad cruzada y minimización. **Detección de duplicados y conflictos.** Coincidencia exacta y aproximada de identificadores, con la IA buscando incoherencias y la supervisión humana del art. 22 RGPD. **Aprobación humana.** El DPO, RRHH y el Compliance Officer verifican el cumplimiento antes de las operaciones críticas sobre categorías especiales, con doble validación para la cuenta bancaria.

## 13 microdecisiones: 6 deterministas, 5 asistidas por IA y 2 humanas

El agente descompone la gestión de los datos en 13 microdecisiones. Las seis deterministas cubren la clasificación del dato, la validación del formato y la minimización, la matriz de aprobación, la confirmación de la sincronización, la tramitación del derecho al olvido y la notificación de brechas a la AEPD. Las cinco asistidas por IA detectan los duplicados entre sistemas, aplican el cambio en el sistema maestro, lo propagan a los sistemas de destino, mantienen el registro de tratamiento y la evaluación de impacto, y generan el paquete de evidencias. Y las dos confirmaciones humanas son el inventario del marco normativo y la aprobación de los cambios críticos por el DPO, RRHH y el Compliance Officer.

## Donde permanece responsabilidad

El agente clasifica, valida, detecta conflictos, aplica el cambio aprobado y lo propaga a los sistemas de destino. Lo que no hace es decidir qué ocurre: si el dato cumple la base legal, si la retención está justificada o si el derecho al olvido procede lo decide una persona del equipo de protección de datos. La responsabilidad por la exactitud de los datos recae en el DPO, Asesoría Jurídica y el Consejo de Administración. Esa separación es la razón por la que el sistema no es de alto riesgo según el Reglamento Europeo de IA: es un procesamiento administrativo sin decisiones sobre el empleo. El comité de empresa conserva su derecho de información sobre el plan de plantilla, el de igualdad y los derechos digitales.

## Edge-cases gestión datos empleados españoles

Las categorías especiales del art. 9 RGPD (salud, biometría, afiliación sindical, orientación sexual, datos genéticos) exigen la aprobación obligatoria del DPO. Los datos del canal de denuncias requieren cifrado reforzado, acceso restringido al Compliance Officer y al DPO, y una retención de cinco años. Los datos sanitarios pasan por el servicio de prevención bajo secreto médico. Y los empleados públicos se rigen por los regímenes especiales de las mutualidades, con datos sanitarios reforzados.

## Integración con sistemas RRHH españoles

El agente se integra con las plataformas líderes en España. A3 de Wolters Kluwer y Sage NominaPlus son los más extendidos en el mercado. Cegid Meta4 domina en las grandes cotizadas. Bizneo, con su módulo de canal de denuncias, y Factorial o Holded cubren a las pymes, mientras que SAP SuccessFactors y Workday atienden al segmento enterprise. A ello se suman plataformas de gobierno del dato certificadas, como OneTrust, BigID o Collibra, que automatizan el registro de tratamiento, la evaluación de impacto y el derecho al olvido, y generan los reportes para la AEPD, las autoridades autonómicas y la Inspección de Trabajo.

--- Agente Casos Relaciones Laborales ---
> Gestión casos disciplinarios: ET art. 54-55 faltas y despido disciplinario, Ley 2/2023 protección denunciantes, RGPD art. 88 datos investigaciones y LRJS jurisdicción social - audit-trail completo.

La gestión de los casos laborales en España se reparte entre cinco frentes con consecuencias muy distintas. El Estatuto de los Trabajadores regula las faltas y sanciones disciplinarias, con plazos de prescripción de 60 días para las graves y 6 meses para las muy graves, y el despido disciplinario, que exige audiencia previa al delegado sindical y, de no cumplirse, deviene improcedente con readmisión o una indemnización de hasta 24 mensualidades. La Ley de Igualdad obliga a proteger frente al acoso. La Ley 2/2023 de personas informantes impone un canal interno en las empresas de más de 50 trabajadores, invierte la carga de la prueba y sanciona las represalias con hasta 1 millón de euros. La Ley Reguladora de la Jurisdicción Social también invierte la carga de la prueba en los casos de discriminación, acoso y despido. Y el Código Penal añade la responsabilidad de la persona jurídica. La consecuencia: cualquier caso disciplinario en una empresa de 500 a 5.000 empleados puede activar a la vez hasta cinco obligaciones distintas.

## Las sanciones acumuladas superan los 2 millones de euros

Las sanciones se acumulan por vías independientes. La Inspección de Trabajo puede llegar a 187.515 euros por las faltas más graves, y hasta 983.736 euros en materia de prevención por acoso. La AEPD puede imponer hasta el 4% de la facturación mundial por tratar datos sensibles del expediente sin evaluación de impacto. Las represalias contra un denunciante alcanzan 1 millón de euros, con inversión de la carga de la prueba. El despido improcedente conlleva una indemnización de 33 días por año, con un máximo de 24 mensualidades, más intereses y costas. Y la responsabilidad penal de la persona jurídica puede suponer la suspensión de actividades, el cierre de locales o la prohibición de contratar con la Administración, junto con la responsabilidad civil ilimitada de los administradores. En una empresa con incumplimientos recurrentes, la suma puede superar los 2 millones de euros.

## 16 microdecisiones: 11 deterministas, 2 indicadores de IA y 3 confirmaciones humanas

El agente descompone la gestión de los casos en 16 microdecisiones, todas deterministas salvo dos indicadores de IA y tres confirmaciones humanas. Cada decisión documenta el paso, la pregunta que resuelve, quién decide y la justificación, con la norma que la respalda, su traza en el sistema de origen y la vía de impugnación. Las once deterministas cubren la validación del fundamento jurídico y los plazos de prescripción, la notificación al comité de empresa y al delegado sindical, la protección de los denunciantes, la validación de los datos sensibles, la activación del programa de compliance penal, la generación de la carta de despido, el cálculo del finiquito, la sincronización con la nómina y la documentación del expediente para la defensa. Los dos indicadores de IA son el plan de desarrollo profesional como alternativa al despido objetivo y la viabilidad de la mediación. Y las tres confirmaciones humanas son la clasificación del tipo de caso, el procedimiento de acoso y el escalado de los casos de la alta dirección al Comité de Auditoría.

## Contraste continuo con la jurisprudencia y el plan de la Inspección de Trabajo

El agente contrasta cada caso de forma continua con la jurisprudencia de la Sala de lo Social del Tribunal Supremo, del Tribunal Constitucional y del Tribunal de Justicia de la UE, así como con el plan de acción de la Inspección de Trabajo y el plan estratégico de la AEPD. Comprueba que la audiencia previa al delegado sindical es obligatoria en las faltas muy graves, que se respetan el procedimiento sectorial del convenio y los plazos de prescripción, y que la carga de la prueba se invierte en los casos de acoso, discriminación y despido nulo, igual que en las represalias contra denunciantes. Verifica también la evaluación de impacto sobre los datos sensibles del expediente y la diligencia debida de los administradores en el programa de compliance penal. La documentación completa del expediente sostiene la defensa jurídica y se conserva durante cinco años.

## Casos especiales: empleados públicos, acoso colectivo y trabajadores desplazados

Algunos casos requieren un tratamiento aparte. Los empleados públicos se rigen por el Estatuto Básico del Empleado Público, con un régimen disciplinario distinto del privado. El acoso colectivo activa la comisión paritaria, el servicio de prevención y medidas cautelares como la separación entre la víctima y el acosador, dentro de un plazo de 30 días. En el caso de los trabajadores desplazados, la Ley 11/2023 fija la ley aplicable y los plazos máximos de desplazamiento, con su coordinación de Seguridad Social. El despido objetivo por ineptitud se distingue del disciplinario y obliga a valorar los ajustes razonables por discapacidad y un plan de desarrollo previo, con una indemnización de 20 días por año. El despido nulo conlleva la readmisión obligatoria y los salarios de tramitación. Y en una situación de concurso de acreedores, la extinción de los contratos queda cubierta por el FOGASA.

## Integración con los sistemas españoles

El agente se integra con las plataformas líderes en España. A3 de Wolters Kluwer y Sage NominaPlus son los más extendidos en el mercado, con módulos de casos disciplinarios e investigaciones. Cegid Meta4 domina en las grandes cotizadas. Bizneo, con su módulo de canal de denuncias, y Holded cubren a las pymes, mientras que SAP SuccessFactors y Workday atienden al segmento enterprise. A ello se suman plataformas especializadas en canal de denuncias y ética como NAVEX, EQS, Convercent o Whispli, y plataformas de gobierno y compliance como ServiceNow u OneTrust, todas con certificación en compliance penal según la norma UNE 19601.

--- Agente Self-Service Empleado ---
> Portal autoservicio empleado: RGPD art. 12-22 derechos acceso/rectificación/supresión, eIDAS firma cualificada y RD 1112/2018 accesibilidad WCAG 2.1 AA - solicitudes y nóminas auditable.

La plataforma de autoservicio del empleado en España se reparte entre cinco frentes con consecuencias muy distintas. El RGPD reconoce los derechos de acceso, rectificación, supresión, limitación y portabilidad, con un plazo de respuesta de un mes y sanciones de hasta el 4% de la facturación mundial. La LOPDGDD añade los derechos digitales del empleado: la intimidad en los dispositivos, la desconexión digital y los límites a la videovigilancia y la geolocalización. El Estatuto de los Trabajadores obliga al acceso igualitario al portal, a la transparencia retributiva y a la información y consulta del comité de empresa. El reglamento eIDAS exige firma electrónica cualificada para los contratos, las nóminas y los certificados. El RD 1112/2018 impone la accesibilidad del portal para los empleados con discapacidad. Y la NIS2 obliga a su ciberseguridad. La consecuencia: cualquier portal de autoservicio en una empresa de 500 a 5.000 empleados puede activar a la vez hasta cinco obligaciones distintas.

## Las sanciones acumuladas superan 1,5 millones de euros

Las sanciones se acumulan por vías independientes. La AEPD puede llegar al 4% de la facturación mundial por atender una solicitud de acceso fuera de plazo, por una evaluación de impacto incompleta en un portal con perfilado o por una decisión automatizada sin intervención humana. La Inspección de Trabajo puede imponer hasta 187.515 euros por accesibilidad, y hasta 983.736 euros en materia de prevención. Una brecha en un sector esencial alcanza los 10 millones de euros o el 2% de la facturación por la NIS2. La falta de transparencia del chatbot llega hasta el 7% por la autoridad de IA. Y el acceso ilícito a los sistemas es delito, con la responsabilidad penal de la persona jurídica y la civil de los administradores. En una empresa con incumplimientos recurrentes, la suma puede superar 1,5 millones de euros.

## 15 microdecisiones: 13 deterministas, 1 indicador de IA y 1 confirmación humana

El agente descompone la plataforma de autoservicio en 15 microdecisiones, todas deterministas salvo un indicador de IA y una confirmación humana. Cada decisión documenta el paso, la pregunta que resuelve, quién decide y la justificación, con la norma que la respalda, su traza en el sistema de origen y la vía de impugnación. Las trece deterministas cubren la autenticación multifactor, la validación de los derechos digitales, la tramitación de las solicitudes de acceso en plazo, la transparencia retributiva, la validación de los datos sensibles, la accesibilidad, la ergonomía de las pantallas, la firma electrónica cualificada, la información al comité de empresa, la transparencia del chatbot, la ciberseguridad de la NIS2, el consentimiento de cookies en la aplicación móvil y la documentación de la traza. El único indicador de IA es la clasificación de la solicitud (vacaciones, permiso, baja, certificado, consulta, queja o denuncia). Y la única confirmación humana es el escalado de los casos sensibles a RRHH, el DPO y el Servicio Jurídico.

## Contraste continuo con la jurisprudencia y el plan de la Inspección de Trabajo

El agente contrasta cada caso de forma continua con la jurisprudencia de la AEPD, del Tribunal Constitucional y del Tribunal de Justicia de la UE (entre otras, las sentencias sobre el derecho al olvido y sobre las decisiones automatizadas), así como con el plan de acción de la Inspección de Trabajo y el plan estratégico de la AEPD. Comprueba que las solicitudes de acceso se atienden en el plazo de un mes con consulta al DPO en los casos complejos, que la evaluación de impacto es obligatoria en los portales con perfilado, y que la accesibilidad cuenta con auditoría anual y declaración pública. Verifica la firma electrónica cualificada, la información al comité de empresa, la transparencia del chatbot con intervención humana, y la ciberseguridad de la NIS2 con notificación de incidentes en 24 horas. La documentación completa se conserva limitada a su finalidad, con supresión automática al vencer el plazo.

## Casos especiales: empleados públicos, trabajadores desplazados, lengua cooficial y discapacidad

Algunos casos requieren un tratamiento aparte. Los empleados públicos acceden a través del Punto de Acceso General y la Carpeta Ciudadana, con Cl@ve o DNI electrónico, en el marco de la sede electrónica de las administraciones públicas. En los trabajadores desplazados, la Ley 11/2023 fija la ley aplicable y los plazos máximos, con acceso a los datos en el país de origen y en el de destino. En las comunidades con lengua cooficial (catalán, euskera, gallego o valenciano), el portal debe ser multilingüe conforme a la oficialidad reconocida en la Constitución. La accesibilidad para los empleados con discapacidad exige ajustes razonables: compatibilidad con lectores de pantalla, alto contraste, tamaño de fuente regulable, navegación por teclado, lengua de signos y lectura fácil. El acceso tras el fallecimiento de un empleado se rige por los derechos de las personas fallecidas, con acceso limitado de los herederos a las finalidades de la pensión de viudedad. Y en un concurso de acreedores, las indemnizaciones quedan cubiertas por el FOGASA.

## Integración con los sistemas españoles

El agente se integra con las plataformas líderes en España. A3 de Wolters Kluwer y Sage NominaPlus son los más extendidos en el mercado, con sus portales del empleado y aplicaciones móviles. Cegid Meta4 domina en las grandes cotizadas. Bizneo, Holded y Factorial, este último con su chatbot integrado con Signaturit, cubren a las pymes, mientras que SAP SuccessFactors y Workday atienden al segmento enterprise. Todas ofrecen portal de autoservicio, nómina en línea, firma electrónica y accesibilidad.

--- Agente Provisión Equipo IT ---
> Provisión equipo IT onboarding: LPRL art. 14/18/22 PRL, RD 488/1997 PVD pantallas, Ley 7/2024 NIS2 ciberseguridad y ISO 27001 - Microsoft Intune/Apple DEP/Jamf Pro con IT Asset Tracking.

La provisión del equipo informático de una nueva incorporación en España toca cinco marcos a la vez. La prevención de riesgos obliga a un equipo ergonómico, a los equipos de protección y a la formación, con sanciones de hasta 983.736 euros. La Ley 10/2021 de teletrabajo exige un acuerdo escrito, la provisión del equipo, la compensación de los gastos y la evaluación de riesgos del domicilio. La LOPDGDD y el RGPD obligan a la transparencia sobre el uso del equipo y a una evaluación de impacto por la monitorización, con sanciones de hasta el 4% de la facturación mundial. La NIS2 y las normas de ciberseguridad exigen el cifrado y la notificación de incidentes, con sanciones de hasta 10 millones de euros en un sector esencial. Y el reglamento eIDAS exige firma electrónica cualificada en el acta de entrega.

## El 42% empieza sin equipo operativo, y las sanciones superan 1,5 millones de euros

El 42% de las nuevas incorporaciones comienzan sin un puesto de trabajo operativo: sin portátil, sin tarjeta de acceso, sin monitor. No porque falte presupuesto, sino porque entre tres y cinco departamentos procesan la misma operación en paralelo, sin una base de datos compartida ni un flujo vinculante. Cada incorporación genera de media entre 2.000 y 8.000 euros de coste en el lado informático. Si un tercio se pierde en consultas, pedidos duplicados y correcciones, para 200 incorporaciones al año eso se acumula en pérdidas de seis cifras, invisibles porque se reparten entre diez centros de coste.

Las sanciones se acumulan por vías independientes. La Inspección de Trabajo puede llegar a 187.515 euros por ergonomía, equipos de protección, accesibilidad o formación, y hasta 983.736 euros en materia de prevención. La AEPD puede imponer hasta el 4% de la facturación mundial por monitorizar el equipo sin transparencia o por una evaluación de impacto incompleta. Una brecha en un sector esencial alcanza los 10 millones de euros, y la falta de transparencia algorítmica, el 7% de la facturación. El acceso ilícito a los sistemas es delito, con la responsabilidad penal de la persona jurídica y la civil de los administradores. En una empresa con incumplimientos recurrentes, la suma puede superar 1,5 millones de euros.

## Lo que falla es la coordinación, no la competencia

Este agente sigue el principio del [Decision Layer](/es/decision-layer/): cada decisión está basada en reglas, asistida por IA o asignada explícitamente a una persona.

El flujo de una provisión de equipamiento en la mayoría de las empresas entre 500 y 5.000 empleados se ve así:

```
Departamento RRHH       Servicio TI           Compras           Facility
      |                        |                      |                  |
      |--- Email: "Nuevo" ---->|                      |                  |
      |                        |--- Ticket: Portátil ->|                  |
      |                        |--- Ticket: Cuentas    |                  |
      |--- Email: Acceso ----->|                      |--- Pedido         |
      |                        |                      |    (espera)       |
      |                        |--- Consulta --------->|                  |
      |                        |                      |                  |
      |                        |          Tarjeta de acceso olvidada      |
```

El problema de base no es técnico, es estructural. Cada departamento trabaja en su propio sistema: RRHH en su plataforma de nóminas, TI en su gestor de servicios y de dispositivos, Compras en su sistema de aprovisionamiento, y Facility en su propia gestión. La coordinación funciona por cadenas de correo y recordatorios personales. Si un eslabón falla, por unas vacaciones, una baja o un cambio en la fecha de incorporación, la cadena se rompe. Nadie tiene el estado global porque no existe un estado global. El resultado: el 43% de los nuevos esperan más de una semana por su puesto de trabajo, el 18% no tiene todos los medios necesarios después de dos meses, y el 39% empieza en esa fase a cuestionar su decisión de entrar en la empresa.

## Lo que falla es la coordinación, no la competencia

Este agente sigue el principio del [Decision Layer](/es/decision-layer/): cada decisión está basada en reglas, asistida por IA o asignada explícitamente a una persona.

El flujo de una provisión equipo en la mayoría empresas entre 500 y 5.000 empleados se ve así:

```
Departamento RRHH       Servicio TI           Compras           Facility
      |                        |                      |                  |
      |--- Email: "Nuevo" ---->|                      |                  |
      |                        |--- Ticket: Portatil ->|                  |
      |                        |--- Ticket: Cuentas    |                  |
      |--- Email: Acceso ----->|                      |--- Pedido         |
      |                        |                      |    (espera)       |
      |                        |--- Consulta --------->|                  |
      |                        |                      |                  |
      |                        |          Tarjeta de acceso olvidada      |
```

El problema de base no es técnico, es estructural. Cada departamento trabaja en su propio sistema: RRHH en su plataforma de nóminas, TI en su gestor de servicios y de dispositivos, Compras en su sistema de aprovisionamiento, y Facility en su propia gestión. La coordinación funciona por cadenas de correo y recordatorios personales. Si un eslabón falla, por unas vacaciones, una baja o un cambio en la fecha de incorporación, la cadena se rompe. Nadie tiene el estado global porque no existe un estado global. El resultado: el 43% de los nuevos esperan más de una semana por su puesto de trabajo, el 18% no tiene todos los medios necesarios después de dos meses, y el 39% empieza en esa fase a cuestionar su decisión de entrar en la empresa.

## 16 microdecisiones: 14 deterministas, 1 indicador de IA y 1 confirmación humana

El agente descompone la provisión del equipo en 16 microdecisiones, todas deterministas salvo un indicador de IA y una confirmación humana. Cada decisión documenta el paso, la pregunta que resuelve, quién decide y la justificación, con la norma que la respalda, su traza en el sistema de origen y la vía de impugnación. Las catorce deterministas cubren la clasificación del detonante, la derivación del paquete y la ergonomía, la verificación del inventario, la validación de la ciberseguridad y el cifrado, la configuración por MDM sin intervención manual, los derechos digitales, los equipos de protección, los ajustes razonables por discapacidad, la coordinación de la entrega con acta firmada, la formación, el seguimiento del activo, el Plan de Autoprotección y la devolución en la baja. El único indicador de IA es la optimización del pedido entre los proveedores marco. Y la única confirmación humana es el escalado de los casos sensibles, como un incidente de ciberseguridad, un robo o un ajuste por discapacidad.

## Cómo el agente asume la orquestación

El Equipment Provisioning Agent no resuelve el problema de un departamento individual. Resuelve el problema de coordinación entre todos los departamentos implicados.

Un perfil derivado en lugar de solicitudes individuales. En cuanto la incorporación se registra en el sistema de RRHH, el agente deriva del puesto, el departamento y el centro de trabajo el perfil completo del equipo, incluyendo la ergonomía, los equipos de protección y, si procede, las condiciones del teletrabajo. No como una recomendación que alguien deba leer y ejecutar, sino como una lista de requisitos legible por máquina que fluye directamente a los sistemas de destino. Un desarrollador en Madrid recibe un perfil distinto que un controller en Barcelona, de forma automática.

Solicitudes en paralelo en lugar de cadenas secuenciales de correo. El agente genera, a partir del perfil, solicitudes paralelas a TI, Compras y Facility, de forma simultánea y no secuencial. Cada una llega a su sistema como un encargo estructurado: el modelo y la configuración del portátil a Compras, la inscripción en el MDM a TI, y la tarjeta de acceso y el puesto ergonómico a Facility.

Comprobación del stock. Antes de cada pedido, el agente verifica el inventario actual con seguimiento por código QR o RFID, el ciclo de vida del activo y el fin de soporte del fabricante. Si el modelo estándar está disponible, lo reserva. Si no, propone alternativas compatibles y solo escala cuando no hay solución basada en reglas. Eso reduce los tiempos de espera ante un problema de suministro de semanas a horas.

Despliegue del equipo sin intervención manual. El equipo se configura de forma automática con cifrado de disco, chip TPM 2.0, acceso condicional, políticas de cumplimiento, borrado remoto y detección de amenazas en el endpoint. El empleado lo recibe, lo enciende, se autentica con sus credenciales corporativas y recibe la configuración, las aplicaciones y las políticas. El tiempo de provisión por parte de TI baja de cuatro horas a treinta minutos.

Acta de entrega con firma electrónica cualificada. El acta de entrega, la de devolución y el acuerdo de uso del teletrabajo se firman con firma cualificada eIDAS a través de un prestador de confianza certificado en España. Equivale a la firma manuscrita, con sello de tiempo y traza completa para la defensa ante una reclamación.

## Por qué precisamente este agente es un buen punto partida

El equipamiento TI es el momento más visible del onboarding y al mismo tiempo el de menor riesgo para introducir automatización basada en agentes. Tres razones:

Primero: no se clasifica como de alto riesgo según el Reglamento Europeo de IA. El agente no decide sobre las personas, coordina logística. Más allá de la información estándar, no genera derechos especiales de consulta del comité de empresa en la provisión de los medios de trabajo. Eso reduce al mínimo el esfuerzo de gobernanza.

Segundo: alta visibilidad con bajo riesgo. Cuando el primer día todo está listo - portátil configurado MDM zero-touch, cuentas activas Azure AD, tarjeta acceso programada, ergonomía PVD validada - lo nota cada nueva incorporación. Y cada responsable. Eso genera aceptación para pasos automatización posteriores antes que toquen procesos políticamente más sensibles.

Tercero: los patrones técnicos que aquí surgen - routing pedidos, integración inventario IT Asset Management, MDM zero-touch deployment, acta firma electrónica eIDAS - los reutilizan agentes posteriores. El Transfer Agent en traslados, el Offboarding Agent en devoluciones, la gestión proveedores en contratos marco. Quien empieza con el Equipment Provisioning Agent construye infraestructura, no solo una solución puntual.

--- Agente Executive Recruiting ---
> Executive Search C-Suite: LSC art. 529 bis Say-on-Pay, CNMV Buen Gobierno IBEX-35, EU AI Act Anexo III(4)(a) HR alto riesgo y AML SEPBLAC KYC - workflow confidencial con audit-trail completo.

Una parte significativa de los puestos directivos cubiertos con búsqueda externa fracasa en los dos primeros años. Según el índice de Russell Reynolds, las salidas tempranas de CEO en los primeros 30 a 36 meses aumentaron un 79% respecto al año anterior, y el segundo año de mandato es el punto más crítico, cuando se les releva unas tres veces más a menudo que en el primero. La selección de directivos en España toca seis marcos de cumplimiento a la vez. La Ley de Sociedades de Capital obliga a una política de retribuciones aprobada por la Junta y somete a los administradores a una responsabilidad civil ilimitada. El Código de Buen Gobierno de la CNMV impone su reglamento a la Comisión de Nombramientos. El EU AI Act clasifica el reclutamiento como alto riesgo, con sanciones de la AESIA de hasta el 7% de la facturación. La Directiva de Transparencia Retributiva obliga a la transparencia salarial. La Ley 10/2010 exige la verificación de blanqueo del candidato. Y el Código Penal impone un programa de cumplimiento penal.

## Cuatro de cada diez directivos fracasan en 18 meses y las sanciones superan los 35 millones de euros

Para una empresa con 2.000 empleados que cubre dos o tres posiciones C-Suite al año, estadísticamente al menos una fracasa cada año. Costes directos - indemnización, nueva búsqueda, honorarios firma búsqueda 25-35 percent del salario anual - oscilan entre 200.000 y 400.000 EUR. Costes indirectos - pérdida continuidad estratégica, inseguridad equipo directivo, fuga talento clave - son varias veces superiores.

Las sanciones se acumulan entre organismos. La CNMV puede imponer hasta 600.000 euros y la suspensión de la cotización. La AEPD llega al 4% de la facturación o 20 millones por una evaluación de impacto incompleta o un perfilado opaco. La AESIA alcanza el 7% o 35 millones por un fallo en la auditoría de sesgo. El SEPBLAC suma hasta 1,5 millones y el Banco de España la revocación de la autorización. La ITSS añade hasta 187.515 euros por brecha retributiva y la AAI hasta un millón por represalias. Por encima de todo está la responsabilidad penal de la persona jurídica, con suspensión de actividades o inhabilitación para contratar, y la civil ilimitada y solidaria de los administradores. En una cotizada del IBEX-35 con incumplimientos recurrentes, el conjunto puede superar los 35 millones de euros, más la reacción del mercado.

Quien conoce estas cifras y aun así carece de un proceso estructurado no hace selección. Hace apuestas controladas.

## El problema de coordinación bajo la superficie

La mayoría de las explicaciones para fracasos directivos se quedan cortas. "El encaje cultural no funcionó." "El consejo no estaba alineado." Son síntomas. La causa está en la arquitectura del proceso.

La selección C-Suite es el único proceso RRHH en el que cinco partes independientes deben coordinarse simultáneamente - y ninguna puede saber lo que la otra hace antes de necesario.

```
Dirección RRHH ---- coordina ---- Firma Búsqueda A
     |                                    |
     |                              Firma Búsqueda B
     |                                    |
Comité Nombramientos                 Candidatos
Consejo Administración              (confidencial)
     |
AML SEPBLAC, Banco España, Servicio Jurídico
```

La dirección de RRHH gestiona varias firmas de búsqueda en paralelo sin que se conozcan entre sí. La Comisión de Nombramientos define el marco de la búsqueda, pero solo quiere implicarse en la shortlist. Los candidatos suelen ocupar puestos activos, y una revelación prematura provoca la reacción del mercado por uso de información privilegiada, con una caída medible de la cotización. Cumplimiento verifica el blanqueo y la autorización del Banco de España sin ampliar el círculo de candidatos.

Funciona mientras una dirección de RRHH experimentada lleva todo el proceso en la cabeza. Falla en tres puntos: cuando la persona que coordina cambia, cuando el proceso se prolonga seis meses y cuando el Consejo, la Comisión de Nombramientos o la Junta preguntan y nadie puede presentar el estado actual de forma documentada para el Say-on-Pay vinculante del art. 529 bis de la LSC.

## La confidencialidad como cuestión arquitectónica y el abuso de mercado

En ningún otro proceso de RRHH tiene una filtración consecuencias tan inmediatas. Si trasciende que una cotizada del IBEX-35 está reemplazando a su CFO, el mercado reacciona: el Reglamento de Abuso de Mercado (596/2014) lo califica como información privilegiada, con obligación de comunicarlo a la CNMV. Los inversores se ponen nerviosos, la competencia aprovecha la incertidumbre y el CFO en funciones decide bajo la presión de su propia salida. Los cambios directivos filtrados antes de tiempo en las cotizadas generan reacciones bursátiles medibles, no por la decisión en sí, sino por el flujo de información descontrolado.

Por eso no basta con postular la confidencialidad como valor. Debe estar anclada en la arquitectura del proceso: quién accede a qué información y cuándo, quién ve nombres de candidatos y quién solo perfiles anonimizados off-market, cómo se garantiza que un feedback firma búsqueda pueda pasar la verificación AML KYC SEPBLAC sin revelar el nombre del candidato a tercera persona.

En la práctica, la mayoría de las empresas resuelven esto con correos cifrados y acuerdos verbales. Funciona de forma puntual, pero no deja pista de auditoría. Ahí está la tensión: el EU AI Act exige documentación y supervisión humana, mientras que la confidencialidad exige restringir la información. Ambas solo funcionan con una arquitectura que gestione el acceso de forma granular.

## Donde trabaja el agente - y donde no decide

El Executive Recruiting Agent no automatiza ninguna decisión que afecte a un candidato. La aprobación de la Junta y del Consejo, la propuesta de la Comisión de Nombramientos, el perfil de búsqueda, la selección de la firma, la negociación del contrato y la decisión de contratación siguen siendo humanas, bajo el deber de diligencia del art. 226 de la LSC.

Lo que el agente asume es la capa coordinación intermedia:

**El briefing confidencial de la firma de búsqueda.** El sistema genera el briefing estructurado con la restricción de información hacia los competidores y la integración con las plataformas de sourcing pasivo.

**La verificación de blanqueo del candidato.** El motor de reglas identifica al titular real, el origen del patrimonio y el carácter de persona políticamente expuesta, y contrasta las listas de sanciones y la autorización del Banco de España. Son comprobaciones que, hechas a mano, producen errores; el motor automatizado cierra esa brecha.

**La modelización del paquete retributivo.** Combina el salario base, el incentivo a largo plazo en acciones (LSC arts. 218 y 219) y las cláusulas de permanencia y de no competencia, a partir de los benchmarks de mercado, con la política aprobada por la Junta (Say-on-Pay del art. 529 bis).

**La coordinación de las entrevistas confidenciales.** Organiza agendas discretas entre la Comisión de Nombramientos, el Consejo y candidatos en puestos activos, con una ubicación neutral, el acuerdo de confidencialidad firmado con eIDAS y el cuidado del riesgo de abuso de mercado.

**La recopilación de feedback y las comprobaciones de referencias.** El agente consolida un formato unificado, las referencias de 360 grados (superiores, pares y subordinados, anonimizadas y firmadas con eIDAS), la diligencia final y la verificación de blanqueo, con auditoría de sesgo y supervisión humana.

## La paradoja del gobierno: alto riesgo de IA y responsabilidad ilimitada, sin Comité de Empresa

La selección de directivos en España es una particularidad regulatoria. Por un lado, es un sistema de alto riesgo bajo el Anexo III del EU AI Act: todo sistema usado para seleccionar personas para el empleo queda sujeto a la cascada completa de gestión de riesgos, transparencia, supervisión humana y obligaciones del responsable del despliegue, con sanciones de la AESIA de hasta el 7% de la facturación o 35 millones de euros.

La Ley de Sociedades de Capital añade la política de retribuciones, la retribución en acciones, el deber de diligencia y de lealtad de los administradores, su responsabilidad civil ilimitada y solidaria, y el Say-on-Pay vinculante de la Junta. El Código de Buen Gobierno de la CNMV suma su reglamento a la Comisión de Nombramientos y la diversidad del consejo.

Por otro lado, el personal de alta dirección queda excluido de la representación de los trabajadores en España, de modo que el Comité de Empresa no suele tener derechos de consulta en la contratación de estos puestos.

Suena a menos esfuerzo, pero en la práctica es más. La ausencia del control del Comité de Empresa hace que la garantía de calidad interna recaiga por completo en RRHH, la Comisión de Nombramientos, el DPO y el Servicio Jurídico. Precisamente por eso la documentación debe ser más estricta, no por una imposición legal exclusiva, sino porque las decisiones sobre directivos se impugnan con más frecuencia y exponen a la responsabilidad civil ilimitada y a la penal de la persona jurídica.

El [Decision Layer](/es/decision-layer/) genera esa documentación como subproducto del control del proceso. Cada paso, cada decisor y cada justificación quedan registrados como parte integral del propio proceso, con una pista de auditoría completa que sirve de defensa frente a las reclamaciones de la CNMV, la AEPD, la AESIA, el SEPBLAC, el Banco de España, la ITSS y la AAI.

## Lo que la infraestructura aporta a otros agentes

La arquitectura de comunicación discreta, con el acceso por rol, los perfiles anonimizados y los flujos de información protocolizados, no se construye solo para la búsqueda de directivos. El Succession Planning Agent necesita la misma infraestructura cuando se evalúan candidatos internos sin que los afectados lo sepan. El Audit Compliance Agent reutiliza la verificación de blanqueo del SEPBLAC, las listas de sanciones y la autorización del Banco de España. Y el Compensation Benchmarking Agent reutiliza la modelización del paquete retributivo que se establece aquí.

El registro de decisiones, con su pista de auditoría completa, su marca temporal y su firma cualificada eIDAS, se convierte en el estándar que aprovecha cada agente posterior del Decision Layer. La selección de directivos no construye esta infraestructura porque el proceso la justifique económicamente por sí solo, sino porque la impone bajo las condiciones más exigentes: la máxima confidencialidad frente al abuso de mercado, la máxima complejidad de interesados entre la Junta, el Consejo y los comités, y la máxima obligación documental del EU AI Act, junto a la responsabilidad ilimitada de los administradores. Lo que funciona en estas condiciones funciona en cualquier parte.

--- Agente HR Gastos ---
> Flujo HR de gastos para empleados: envío self-service con captura OCR de recibos, aprobación jerárquica multinivel de responsables y validación de campos obligatorios antes del traspaso a finanzas.

Una parte significativa de los gastos procesados manualmente contiene errores. Según la Global Business Travel Association (GBTA), un informe de gastos manual cuesta en promedio 58 USD frente a menos de 10 USD si se automatiza, con unos 20 minutos de tratamiento por comprobante; el 19 por ciento de las liquidaciones llegan con errores, y cada uno añade 48 EUR y 18 minutos de reprocesamiento. La gestión de gastos en España toca seis marcos de cumplimiento a la vez. La Ley 35/2006 del IRPF y el RD 1080/2017 fijan las cuantías exentas de dietas (53,34 EUR/día en España, 91,35 EUR en el extranjero, 0,19 EUR/km). La Ley 27/2014 del Impuesto sobre Sociedades obliga a distinguir entre gastos deducibles y no deducibles. La Ley 37/1992 regula la deducción del IVA. La facturación electrónica (SII, TicketBai, Veri*Factu) impone su propio calendario. Y a todo ello se suman el RGPD para los datos de empleados, la Ley 10/2010 de prevención del blanqueo y la responsabilidad penal de la persona jurídica.

## Una de cada cinco liquidaciones contiene errores + sanciones acumulables superan 35 millones EUR

Con 500 liquidaciones al mes, 95 rondas de corrección suman casi 4.600 EUR en costes adicionales - por encima de los 26.500 EUR que ya cuesta el procesamiento ordinario. El problema no reside en los empleados. Un director comercial que presenta los justificantes de una comida de negocios tras visitar a un cliente no conoce la política al detalle. Cuál es el importe máximo? Hace falta lista asistentes? A partir de qué importe debe aprobar el director departamento en lugar del responsable equipo? Estas preguntas se responden por intuición - y en el 19 percent de los casos la intuición falla.

Las sanciones se acumulan entre organismos. La AEAT puede reclamar entre el 50 y el 150 por ciento del importe defraudado, más recargos e intereses. El SII penaliza con el 0,5 por ciento de cada operación, hasta 6.000 EUR por trimestre, y TicketBai con un 20 por ciento específico más el cierre cautelar del establecimiento. La AEPD llega al 4 por ciento de la facturación mundial o 20 millones de euros, y la AESIA al 7 por ciento o 35 millones cuando falla la auditoría de sesgo. El SEPBLAC alcanza 1.500.000 EUR y la ITSS 187.515 EUR. Por encima de todo está la responsabilidad penal de la persona jurídica, con suspensión de actividades, cierre de locales o inhabilitación para contratar con el sector público. En una cotizada del IBEX-35 con incumplimientos recurrentes, el conjunto puede superar los 35 millones de euros.

## El [Decision Layer](/es/decision-layer/) convierte una política en un proceso verificable

Las políticas de gastos existen en todas las empresas. Pero entre la política publicada en intranet y su aplicación consistente hay un abismo. Tres responsables de equipo en la misma empresa aprueban el mismo justificante de comida de negocios con tres criterios distintos - porque nadie consulta la política antes de cada aprobación.

El Decision Layer descompone el proceso de gastos en decisiones individuales y asigna cada una a una persona, a una regla o a la IA. La captura y categorización del justificante las hace la IA, que reconoce el tipo de documento, el importe y el proveedor con más rapidez y precisión que cualquier entrada manual, bajo supervisión humana cuando la confianza del reconocimiento baja del 90 por ciento. La verificación de la política y la contabilización siguen el reglamento: las cuantías máximas del RD 1080/2017, las categorías permitidas y la asignación de cuentas del Plan General de Contabilidad. El enrutado de la aprobación también es reglado: quién aprueba lo determina la matriz de autorizaciones por importe, no el azar, desde el responsable de equipo por debajo de 500 EUR hasta el Comité de Auditoría por encima de 25.000 EUR en cotizadas.

La persona se mantiene donde su criterio es necesario: en la aprobación misma, que cuando recae en un consejero queda sujeta al deber de diligencia del art. 226 de la LSC. El responsable ve un expediente ya verificado y correctamente categorizado, y decide con un clic si lo aprueba o pide aclaraciones.

## Procesos masivos basados en reglas son el punto de partida ideal para automatización

Las liquidaciones de gastos reúnen tres características que las hacen especialmente automatizables. Primera: alto volumen con bajo valor unitario, cientos de justificantes al mes de entre 10 y 500 EUR. Segunda: reglas claras, con las cuantías máximas del RD 1080/2017, las categorías permitidas y los niveles de aprobación ya documentados por escrito. Tercera: bajo riesgo regulatorio en el EU AI Act, porque no se toma ninguna decisión sobre la relación laboral; la AESIA no exige notificación y clasifica la detección de fraude como riesgo limitado.

Esta combinación explica el Readiness Score superior a 90. El proceso es lo bastante reglado para automatizarse de forma amplia y, a la vez, lo bastante poco crítico para servir de puerta de entrada a los flujos de trabajo basados en agentes. Las empresas que empiezan aquí construyen un motor de justificantes y una lógica de aprobación que se transfieren a procesos adyacentes, desde el Invoice-Processing-Agent hasta el Travel-Expense-Agent o el Tax-Reporting-Agent.

En la gobernanza interna, este agente no requiere acuerdo del Comité de Empresa según el ET art. 64, ya que no trata datos que afecten a las condiciones de la relación laboral, aunque sí aplica el derecho de información sobre las políticas de dietas (ET art. 64.5). Aun así, conviene informar al Comité como buena práctica, sobre todo si la empresa prevé desplegar más adelante agentes que sí exijan consulta.

## Plazos reembolso pasan de semanas a días + SII facturación electrónica plazo 4 días naturales

La diferencia medible no está solo en el ahorro de tramitación, sino en todo el ciclo. Si un justificante se presenta el lunes, queda verificado, categorizado y asignado al aprobador correcto ese mismo día, sin acumulación a fin de mes ni comprobantes olvidados tres semanas en la bandeja de un responsable. Y el envío al SII de la AEAT cumple su plazo de cuatro días naturales. Para el departamento financiero surge un segundo efecto: transparencia en tiempo real sobre los patrones de gasto. En lugar de descubrir sorpresas en el cierre trimestral, como las atenciones a clientes de un departamento que superan el umbral del 1 por ciento del volumen de negocio del art. 15 de la Ley 27/2014, las anomalías se detectan mientras ocurren. El agente no sustituye al control de gestión: le da la base de datos sobre la que decidir con más rapidez y fundamento.

## La paradoja gobernanza: bajo riesgo IA + responsabilidad penal personas jurídicas + responsabilidad civil ilimitada cuando consejero aprobador

La gestión de gastos en España es una particularidad regulatoria. Por un lado, es de bajo riesgo en el EU AI Act: no entra en el alto riesgo del Anexo III, y la AESIA solo exige transparencia y supervisión humana cuando el importe supera los 1.000 EUR o cuando una auditoría detecta sesgo. Por otro lado, expone a la empresa a la responsabilidad penal de la persona jurídica (Código Penal art. 31 bis) si un gasto encubre cohecho a funcionarios públicos, corrupción en los negocios o fraude fiscal por encima de 120.000 EUR, con sanciones que llegan a la suspensión de actividades, el cierre de locales o la inhabilitación para contratar con el sector público. Y cuando el aprobador es consejero, responde además por el deber de diligencia del art. 226 de la LSC y por la responsabilidad civil ilimitada y solidaria de los arts. 236 y 237.

## Infraestructura compartida para ecosistema agentes + AML KYC + fraud detection AI + SII facturación electrónica

El motor de captura por OCR y la lógica de categorización que construye este agente no son exclusivos de las liquidaciones de gastos. El Invoice Processing Agent reutiliza la misma tecnología y las mismas reglas de clasificación contable para las facturas de proveedores. El Travel Expense Agent comparte la verificación de política, las cuantías exentas de IRPF y el enrutado de aprobación. Y el Tax-Reporting-Agent y el VAT-Reporting-Agent reutilizan la integración con el SII, TicketBai y la retención de IRPF. El patrón del flujo de aprobación, que va de la presentación a la verificación automática, la aprobación humana y el traspaso a contabilidad, se convierte en estándar para cualquier proceso de autorización de la organización.

El motor de detección de fraude, con auditoría de sesgo, supervisión humana y registro completo, es la base del Audit-Compliance-Agent y de la verificación de blanqueo del SEPBLAC. El registro de decisiones y la pista de auditoría que construye sirven al Decision Layer para hacer cada decisión trazable e impugnable, con acta de firma electrónica cualificada.

--- Agente Gestión Documental RRHH ---
> Expediente personal electrónico: RGPD art. 15 acceso, art. 17 Derecho al Olvido, LOPDGDD art. 87-91 y eIDAS firma cualificada - ciclo vida documentos con audit-trail y archivación conforme.

La gestión del expediente personal electrónico en España se sitúa en el cruce de cinco marcos de cumplimiento con consecuencias muy distintas. El RGPD rige el derecho de acceso (un mes de plazo, ampliable a dos), el derecho al olvido, las medidas de seguridad y el registro de actividades de tratamiento, con especial cuidado de los datos sensibles del art. 9. El Estatuto de los Trabajadores regula la forma del contrato, los derechos digitales y la información al Comité de Empresa. Los plazos de conservación los fijan la LGT (cuatro años fiscales), el Código de Comercio (seis contables), la PRL (cinco de vigilancia de la salud) y la normativa de pensiones (hasta cincuenta). El eIDAS gobierna la firma cualificada. Y el Código Penal añade la responsabilidad penal de la persona jurídica. Esta constelación significa que un mismo expediente, en una empresa del IBEX-35 o de mediana dimensión de entre 500 y 5.000 empleados, puede activar a la vez hasta cinco obligaciones de cumplimiento distintas.

## Las sanciones acumuladas de AEPD, ITSS, AAI y Código Penal superan los 5 millones de euros

Las sanciones se acumulan entre organismos. La AEPD puede imponer hasta el 4 por ciento de la facturación mundial o 20 millones de euros por tratar datos sensibles sin evaluación de impacto, por no atender un derecho de acceso o por no notificar una brecha en 72 horas. La ITSS llega a 187.515 EUR y la AAI al millón por represalias contra denunciantes. La AESIA alcanza el 7 por ciento de la facturación y la directiva NIS2 los 10 millones de euros o el 2 por ciento. Por encima de todo está la responsabilidad penal de la persona jurídica, con suspensión de actividades, cierre de locales o disolución, y la responsabilidad civil ilimitada de los administradores. En una empresa mediana o grande con incumplimientos recurrentes, el conjunto puede superar los 5 millones de euros.

## Trece etapas deterministas, un indicador de IA y una confirmación humana

El agente descompone la gestión documental en quince micro-decisiones, todas deterministas salvo un indicador asistido por IA y una confirmación humana. Cada decisión documenta el paso, la pregunta, el tipo de decisor (regla, indicador o persona) y su justificación con cita legal y pista de auditoría. Las trece decisiones por regla cubren la clasificación del documento, la conservación según los plazos legales, el derecho de acceso y el derecho al olvido, la firma cualificada eIDAS, la evaluación de impacto, la pista de auditoría, el canal de denuncias, el cumplimiento del Esquema Nacional de Seguridad, la información al Comité de Empresa y la integridad del expediente personal. El indicador asistido por IA es la auditoría de sincronización entre el HRIS, el ERP y el Sistema RED. Y la confirmación humana es el escalado al Comité de Auditoría en los casos de C-suite y administradores.

## Coherencia con la jurisprudencia de lo Social y el Plan Estratégico de la AEPD

El agente comprueba la coherencia de cada paso frente a la jurisprudencia de la Sala IV de lo Social del Tribunal Supremo, las prioridades del Plan Estratégico de la AEPD y las resoluciones del Tribunal Constitucional y del Tribunal de Justicia de la UE. El derecho de acceso se atiende en un mes con entrega cifrada, y el derecho al olvido se concilia con los plazos de conservación vigentes. Importa especialmente porque en los litigios laborales y en las represalias contra denunciantes la carga de la prueba se invierte (LRJS art. 96, Ley 2/2023): corresponde a la empresa demostrar que no hubo discriminación. Sin un expediente documentado y conservado, esa prueba es casi imposible, de modo que la pista de auditoría es la mejor defensa.

## Casos especiales: empleados públicos, trabajadores desplazados y pensiones a cincuenta años

Hay casos especiales que el agente contempla. Los empleados públicos (MUFACE, ISFAS, MUGEJU) se rigen por el EBEP, con un régimen disciplinario distinto del privado y cinco años de archivo. Los trabajadores desplazados quedan bajo la Directiva de Posted Workers y su transposición (Ley 11/2023), con la ley del lugar de trabajo y el certificado A1 de coordinación de la Seguridad Social. La documentación de pensiones se conserva hasta cincuenta años. Los datos sensibles del art. 9 del RGPD (salud, afiliación sindical, datos biométricos) exigen cifrado adicional, acceso restringido y una base jurídica reforzada. Y los supuestos de concurso de acreedores o de despido nulo, con readmisión obligatoria y salarios de tramitación, requieren conservar el expediente cinco años más.

## Integración con los sistemas españoles de RRHH, gestión documental y firma

El agente se integra por API con las principales plataformas del mercado español. En el lado de RRHH y nóminas, con A3 de Wolters Kluwer y Sage como líderes, junto a Cegid, Bizneo, Holded, SAP SuccessFactors, Workday y Personio. Para la privacidad y el cumplimiento, con OneTrust, BigID, Collibra y ServiceNow. Para el canal de denuncias, con NAVEX, EQS y Whispli, entre otros. La gestión de contenidos se apoya en plataformas ECM como DocuWare, d.velop, ELO o Hyland OnBase, y la firma cualificada eIDAS en proveedores como Signaturit, Validated ID o la FNMT-RCM. El agente enlaza además con los de Gestión de Datos de Empleados, Generación de Ofertas, Casos de Relaciones Laborales y Monitorización y Formación en Cumplimiento.

--- Agente Programación Entrevistas ---
> Procedimiento entrevista candidatos: ET art. 4/17/28, RGPD art. 22 decisión automatizada, EU AI Act Anexo III(4)(a) HR alto riesgo y RD 902/2020 - coordinación con bias-audit.

El procedimiento de entrevista en España se sitúa en el cruce de seis marcos de cumplimiento con consecuencias muy distintas. El Estatuto de los Trabajadores prohíbe la discriminación y exige la igualdad, también la retributiva. El RGPD fija la base jurídica del tratamiento, veda las preguntas sobre datos especiales (salud, religión, afiliación sindical, orientación sexual) y obliga a la evaluación de impacto. El EU AI Act clasifica el reclutamiento como alto riesgo (Anexo III) y exige gestión de riesgos, transparencia, supervisión humana y auditoría de sesgo. La LO 3/2007 y el RD 902/2020 imponen la igualdad retributiva y la horquilla salarial. La Directiva de Transparencia Retributiva (2023/970), cuya transposición vence el 7 de junio de 2026, prohíbe preguntar por el historial salarial. Y la Ley General de Discapacidad obliga a los ajustes razonables. Esta constelación significa que un mismo procedimiento de entrevista, en una empresa del IBEX-35 o de mediana dimensión de entre 500 y 5.000 empleados, puede activar a la vez hasta seis obligaciones de cumplimiento distintas.

## Las sanciones acumuladas de AEPD, AESIA, ITSS y AAI superan el 7% de la facturación

Las sanciones se acumulan entre organismos. La AEPD puede imponer hasta el 4 por ciento de la facturación mundial o 20 millones de euros por tratar datos especiales sin evaluación de impacto, por no atender un derecho de acceso o por no notificar una brecha en 72 horas. La AESIA llega al 7 por ciento por incumplir la auditoría de sesgo o la transparencia que exige el alto riesgo del EU AI Act. La ITSS alcanza 187.515 EUR por discriminación en el procedimiento, la AAI el millón por represalias contra candidatos denunciantes y la Ley General de Discapacidad otro millón por incumplir la cuota del 2%. Por encima de todo está la responsabilidad penal de la persona jurídica, con suspensión de actividades o disolución, y la civil ilimitada de los administradores. Pesa además el precedente Mobley v. Workday sobre la responsabilidad del proveedor y del usuario del sistema. En una empresa mediana o grande con incumplimientos recurrentes, el conjunto puede superar los 5 millones de euros.

## Doce etapas deterministas, dos indicadores de IA y una confirmación humana

El agente descompone la coordinación de la entrevista en quince micro-decisiones, todas deterministas salvo dos indicadores asistidos por IA y una confirmación humana. Cada decisión documenta el paso, la pregunta, el tipo de decisor y su justificación con cita legal y pista de auditoría. Las doce decisiones por regla cubren la base jurídica del tratamiento, la evaluación de impacto y la auditoría de sesgo, la comunicación de la horquilla salarial, la resolución de conflictos entre calendarios y husos horarios, la verificación del visado, los ajustes razonables de accesibilidad, la exclusión de las preguntas prohibidas, el consentimiento firmado de la entrevista grabada, el canal de denuncias accesible para los candidatos, la información al Comité de Empresa y el derecho de acceso de los candidatos rechazados. Los dos indicadores asistidos por IA son la auditoría de sincronización entre sistemas y la notificación de brechas de seguridad. Y la confirmación humana es el escalado al Comité de Auditoría en los casos de C-suite.

## Coherencia con la jurisprudencia de lo Social y el precedente Mobley v. Workday

El agente comprueba la coherencia de cada paso frente a la jurisprudencia de la Sala IV de lo Social del Tribunal Supremo, las prioridades del Plan Estratégico de la AEPD y las resoluciones del Tribunal Constitucional y del Tribunal de Justicia de la UE. El derecho de acceso de los candidatos rechazados se atiende en un mes con entrega cifrada, y la evaluación de impacto y la auditoría de sesgo se ejecutan conforme al RGPD y al EU AI Act. Importa especialmente porque tanto en la discriminación como en las represalias contra denunciantes la carga de la prueba se invierte (LRJS art. 96, Ley 2/2023): corresponde a la empresa demostrar que no hubo discriminación. El precedente estadounidense Mobley v. Workday extiende esa exigencia a la responsabilidad del proveedor del sistema de IA. Sin un procedimiento documentado y conservado durante cuatro años, esa prueba es casi imposible, de modo que la pista de auditoría es la mejor defensa.

## Casos especiales: empleados públicos, trabajadores desplazados y búsqueda de directivos

Hay casos especiales que el agente contempla. Los empleados públicos (MUFACE, ISFAS, MUGEJU) acceden al empleo por mérito y capacidad mediante concurso-oposición ante un tribunal independiente, con un procedimiento distinto del privado y una cuota de discapacidad del 7%. Los trabajadores desplazados quedan bajo la Directiva de Posted Workers y su transposición (Ley 11/2023), con la ley del lugar de trabajo y el certificado A1 de coordinación de la Seguridad Social. Los candidatos extranjeros se rigen por la Ley de Extranjería (visado, permiso de trabajo, NIE y TIE). La búsqueda de directivos activa el deber de diligencia de los administradores y la intervención del Comité de Nombramientos. Los datos sensibles del art. 9 del RGPD exigen cifrado adicional, acceso restringido y base jurídica reforzada. Y los supuestos de despido nulo discriminatorio, con readmisión obligatoria y salarios de tramitación, requieren conservar el procedimiento cinco años, a la luz del precedente Mobley v. Workday.

## Integración con los sistemas españoles de RRHH, calendario y firma

El agente se integra por API con las principales plataformas del mercado español. En el lado del seguimiento de candidatos (ATS), con A3 de Wolters Kluwer y Sage como líderes, junto a Cegid, Bizneo, Holded, SAP SuccessFactors, Workday y Personio, además de Cornerstone, iCIMS, Lever o Greenhouse. Para el calendario y la videoconferencia, con Microsoft Outlook, Teams y Bookings, Google Calendar y Meet, y plataformas de agenda como Calendly, Cronofy o GoodTime Hire, resolviendo los conflictos y la diferencia horaria entre Madrid y el candidato en el extranjero. La videoconferencia con Zoom o Webex deja constancia de la entrevista grabada con consentimiento firmado por eIDAS. Las plataformas de entrevista con IA, como HireVue o Eightfold, quedan sujetas al alto riesgo del EU AI Act y a la auditoría de sesgo de la AESIA, a la luz del precedente Mobley v. Workday. La firma cualificada se apoya en proveedores como Signaturit, Validated ID o la FNMT-RCM. El agente enlaza además con los de Flujo de Reclutamiento, Benchmarking Retributivo, Búsqueda de Directivos, Diversidad e Inclusión y Gestión Documental.

--- Agente Facturas Proveedores HR ---
> Procesa facturas de proveedores HR: agencias selección (InfoJobs, LinkedIn), headhunters, formación y beneficios sociales. Asigna centros coste Personal, verifica comité empresa y contabiliza PGC.

## El procesamiento manual de facturas cuesta entre 10 y 15 EUR por operación - y además se pierde el descuento por pronto pago

Procesar manualmente una sola factura entrante cuesta entre 10 y 15 EUR (11 y 16 USD). Con 500 facturas por semana, eso supone más de 300.000 EUR (330.000 USD) de costes de proceso al año - antes de que una sola factura se contabilice mal o se pierda un descuento por pronto pago. Según Ardent Partners, solo el 21 por ciento de las empresas sin automatización alcanzan tasas aceptables de aprovechamiento de descuentos. El 79 por ciento restante paga el importe íntegro porque la factura todavía estaba en el circuito de aprobación cuando expiró el plazo.

El daño real no está en los costes evidentes de registro. Está en los costes derivados: una contabilización errónea genera asientos de corrección, una factura sin referencia de pedido provoca consultas a Compras, pagos tardíos empeoran las condiciones con proveedores. Cada una de estas reelaboraciones consume capacidad del equipo de contabilidad que falta para cierres y análisis.

## El matching triple automatizado reduce la tasa de error del 12 por ciento a prácticamente cero

El matching triple - factura contra pedido contra recepción de mercancía - es el núcleo de toda verificación de facturas conforme a normativa. Ejecutado manualmente es propenso a errores: entre el 10 y el 15 por ciento de todas las facturas contienen discrepancias en cantidades, precios o condiciones que un revisor humano bajo presión de tiempo pasa por alto o valora incorrectamente. Los sistemas automatizados ejecutan este matching en segundos y aplican reglas de tolerancia definidas de forma consistente a cada posición.

En concreto: una factura de 4.780 EUR se verifica contra la posición de pedido de 4.800 EUR. La desviación del 0,4 por ciento está dentro de la tolerancia definida del 2 por ciento - el agente aprueba. Una segunda factura se desvía un 8 por ciento - el agente escala al responsable del centro de coste. Sin margen de discrecionalidad, sin inconsistencia entre revisores, sin verificación olvidada un viernes por la tarde.

La contabilización sigue el mismo principio. En lugar de que un contable busque la cuenta, un motor de reglas deriva la contabilización del pedido. Para facturas sin referencia de pedido, el agente propone una cuenta basándose en patrones históricos de contabilización - la confirmación final permanece en la persona.

## El [Decision Layer](/es/decision-layer/) separa las aprobaciones rutinarias de las decisiones que requieren criterio

El Decision Layer descompone el proceso de facturación en pasos de decisión individuales y define para cada uno: persona, motor de reglas o IA. Esta descomposición marca la diferencia entre una automatización que cubre el 60 por ciento de las facturas y una que alcanza el 95 por ciento.

La extracción de datos - proveedor, importe, número de factura, posiciones - es una tarea de IA. La tasa de reconocimiento en facturas estructuradas (PDF, EDI, Facturae) se sitúa entre el 92 y el 98 por ciento. El matching triple y la contabilización son tareas de reglas con umbrales definidos. El routing de aprobación sigue una matriz por importes: facturas por debajo de 5.000 EUR al jefe de equipo, por encima de 50.000 EUR a la dirección general.

La persona permanece donde la ley lo exige - no porque lo haga mejor. La contabilidad conforme a normativa exige la trazabilidad de cada decisión. El agente protocola cada paso con justificación y marca temporal. Ante discrepancias fiscalmente relevantes - por ejemplo una factura sin NIF-IVA válido - escala a un revisor cualificado en lugar de decidir por sí mismo. Los requisitos de la Agencia Tributaria (AEAT) y la correcta deducción del IVA quedan garantizados.

## El procesamiento de facturas ofrece el ROI más rápido de todo el portfolio de agentes

Ningún otro agente combina un volumen de transacciones tan alto con una complejidad de gobernanza tan baja. El procesamiento de facturas no es un sistema de alto riesgo bajo el Reglamento de IA, no requiere participación del Comité de Empresa y no afecta a datos personales de empleados. Al mismo tiempo, una empresa mediana con 200 empleados procesa fácilmente entre 300 y 800 facturas al mes - cada una un ahorro medible.

El cálculo es sencillo: si los costes de proceso por factura bajan de 12 EUR a 3 EUR (de 13 a 3 USD) y el aprovechamiento de descuentos sube del 20 al 75 por ciento, el agente se amortiza con 500 facturas mensuales en pocos meses. Highradius cifra la reducción media de costes por automatización de cuentas a pagar en un 78 por ciento - de 13,54 USD a 2,98 USD por factura.

La obligación de factura electrónica refuerza este efecto. La factura electrónica ya es obligatoria en las relaciones con la Administración Pública y se extiende progresivamente al ámbito B2B con la Ley Crea y Crece. Los formatos estructurados como Facturae proporcionan datos legibles por máquina que aumentan la tasa de reconocimiento y reducen la captura manual a casos excepcionales. Quien automatiza ahora aprovecha la transformación regulatoria como acelerador en lugar de como carga adicional.

--- Job Posting Agent ---
> Genera ofertas de empleo conformes desde perfiles de requisitos y coordina publicación multicanal. Alto riesgo bajo el Reglamento de IA.

Tres recruiters, tres redacciones, tres niveles de riesgo. Así es la realidad de las ofertas de empleo cuando hay que cubrir veinte posiciones simultáneamente. Una oferta habla de un "equipo joven y dinámico" - una infracción de la normativa antidiscriminación que ante el juzgado puede costar hasta tres meses de salario bruto como indemnización. La siguiente omite la banda salarial, que a partir de junio de 2026 será obligatoria por la Directiva de Transparencia Retributiva. La tercera es técnicamente correcta pero tan genérica que se pierde entre los miles de ofertas publicadas en InfoJobs y LinkedIn. Y las tres se publicaron manualmente en tres canales diferentes porque nadie sabe qué canal ofrece el mejor retorno para cada posición.

No es un problema de calidad individual de los recruiters. Es un problema sistémico.

## El triple riesgo de cada oferta

Las ofertas de empleo son el artefacto más vulnerable de todo el proceso de selección. Son simultáneamente documento legal, partida presupuestaria y tarjeta de visita - y en la mayoría de organizaciones ninguno de estos tres aspectos se gestiona sistemáticamente.

**Riesgo legal: antidiscriminación hoy, transparencia retributiva mañana.** Cualquier formulación discriminatoria abre un caso de responsabilidad. "Español nativo" en lugar de "excelentes conocimientos de español" - la diferencia está en una demanda por discriminación. Con cincuenta posiciones abiertas al año y una media de veinte candidaturas por posición, un solo error de formulación sistemático basta para generar indemnizaciones de cinco cifras. A partir de junio de 2026, la Directiva de Transparencia Retributiva endurece los requisitos: cada oferta debe incluir una banda salarial concreta. Quien olvida esta indicación o la maneja de forma inconsistente se arriesga a sanciones de la AESIA y pierde la confianza de los candidatos antes de la primera entrevista.

**Problema de costes: difusión sin control.** El coste medio por contratación en España se sitúa entre 4.700 y 5.500 EUR (5.170 y 6.050 USD) - según fuente y sector. Una parte significativa se invierte en ofertas publicadas en los canales equivocados. Las publicaciones individuales en portales de empleo cuestan entre 500 y 1.300 EUR por anuncio. Quien publica en cinco canales simultáneamente gasta fácilmente más de 5.000 EUR por posición solo en publicación - sin saber qué canal genera las candidaturas cualificadas y cuál solo produce clics.

**Problema de calidad: la inconsistencia como enemiga del employer branding.** Si la misma posición aparece en tres variantes en el mercado - una con viñetas, otra en texto corrido, otra con beneficios obsoletos - eso señala arbitrariedad organizativa. Con una media de 120 días de vacancia para posiciones cualificadas en España, cada día que una oferta mal redactada atrae a los candidatos equivocados o ahuyenta a los correctos cuenta.

## Donde fallan los procesos manuales

La cadena de proceso típica de una oferta de empleo:

```
Departamento            Selección               Aprobación
──────────────          ──────────              ────────
Requisición    ──────>  Redacción    ──────>    Revisión
(a menudo sin           (varía según            (a menudo solo
 estructura)             el recruiter)           contenido,
                                                 no legal)
                              |
                              v
                         Publicación manual
                         (3-5 portales,
                          copiar y pegar)
```

Cada flecha en este diagrama es una fuente de error. La requisición llega como correo sin estructura. El texto se redacta bajo presión de tiempo sin consultar las directrices de marca empleadora. La revisión es de contenido pero no jurídica. La publicación se hace manualmente - y el rendimiento nunca se evalúa sistemáticamente.

## Lo que cambia cuando las ofertas se convierten en infraestructura

Un Job Posting Agent no sustituye al recruiter. Sustituye la aleatoriedad. A partir de un perfil de requisitos estructurado se genera un borrador de oferta que pasa por tres capas de verificación antes de que una persona lo vea:

Primera capa: conformidad antidiscriminación. Cada formulación se contrasta contra un catálogo de verificación - lenguaje neutro en género, sin discriminación por edad, sin discriminación indirecta por requisitos de idioma. No es una sugerencia estilística, sino una regla estricta. Lo que no pasa, no avanza.

Segunda capa: transparencia retributiva. Las bandas salariales se extraen de las tablas retributivas registradas y se insertan en el formato prescrito. Consistente en todas las ofertas, todos los canales, todos los idiomas. Sin desviación, sin olvido.

Tercera capa: optimización de canales. Qué portales para qué posición, qué región, qué nivel de seniority ofrecen las mejores tasas de conversión se decide por reglas - no por intuición. Los datos de rendimiento retroalimentan y mejoran la selección de canales para la siguiente publicación.

Solo entonces ve el recruiter el borrador. Y revisa lo que solo una persona puede revisar: el tono, si la descripción se ajusta a la cultura real del equipo, si hay matices técnicos que solo conoce quien ha hablado con el departamento.

## Lo que significa para la dirección de selección

La cuestión no es si las ofertas de empleo se automatizan. La cuestión es si se tratan como infraestructura - con gobernanza, versionado y Audit Trail - o si siguen siendo productos del azar que en la próxima demanda por discriminación o la primera inspección de transparencia retributiva se convierten en un caso de responsabilidad.

La diferencia entre una organización que lo tiene resuelto y otra que no se evidencia no en el texto individual de la oferta. Se evidencia en la capacidad de dar una respuesta sistémica a la pregunta "cómo garantizan que todas sus ofertas cumplen la Directiva de Transparencia Retributiva" en lugar de "eso lo comprueba cada recruiter por su cuenta".

Un [Decision Layer](/es/decision-layer/) hace trazable cada paso: qué reglas se aplicaron, qué verificaciones se superaron o no, quién aprobó. No como documentación posterior, sino como parte integral del proceso. En un sistema de alto riesgo bajo el Reglamento de IA - y exactamente eso es un agente que influye en quién ve las ofertas de empleo - esta trazabilidad no es opcional, es obligatoria. La AESIA supervisará el cumplimiento de estos requisitos en España.

--- Learning Event Management Agent ---
> Gestiona logística de formación presencial: salas, formadores, participantes, equipamiento y seguimiento - coordinación sin esfuerzo manual.

Un departamento de L&D que coordina 30 eventos formativos al mes no resuelve un problema de aprendizaje. Resuelve un problema logístico. Cruzar salas con aforos, verificar disponibilidad de formadores, pedir materiales a tiempo, gestionar listas de espera, procesar cancelaciones, enviar recordatorios, recoger evaluaciones. Cada tarea individual es trivial. En conjunto consumen entre el 40 y el 60 por ciento de la capacidad operativa de L&D - capacidad que no fluye ni hacia el diseño de programas ni hacia la medición de impacto.

Y el problema no mejora cuando la organización crece. Empeora proporcionalmente.

## Por qué las hojas de cálculo no resuelven el problema, sino que son el problema

En la mayoría de organizaciones entre 500 y 5.000 empleados, la coordinación de eventos se ve así: una hoja Excel con fechas, otra con disponibilidad de formadores, otra con ocupación de salas. Entre medias, correos, invitaciones de calendario y acuerdos verbales. Este sistema tiene tres debilidades estructurales que no se arreglan con mejores hojas.

**Primero: conflictos multi-recurso.** Cada evento formativo vincula al menos cuatro recursos - sala, formador, grupo de participantes, materiales. Si un taller para 20 personas necesita una sala con proyector pero la única sala adecuada está reservada ese día para un seminario de directivos, comienza una cadena de reprogramación. Las agendas de formadores se desplazan, hay que volver a invitar a participantes, los pedidos de material ya no cuadran. En una hoja de cálculo el conflicto se ve cuando ya ha ocurrido. No antes.

**Segundo: cascadas de cancelación.** La tasa media de cancelación en formaciones presenciales es del 17 por ciento. En un taller con 20 plazas faltan de media tres o cuatro participantes. Si existe lista de espera, alguien debe hacer avanzar manualmente al siguiente, informar al participante promocionado, comprobar si los materiales alcanzan e informar al formador de la composición modificada del grupo. Si no hay lista de espera, las plazas quedan vacías - y el coste por persona sube, porque sala y formador ya están reservados.

**Tercero: costes invisibles.** Una formación presencial de día completo para 20 participantes cuesta entre 5.000 y 15.000 EUR (5.500 y 16.500 USD) - formador, sala, materiales, tiempo de trabajo de los participantes incluidos. Con 30 eventos al mes, el departamento de L&D gestiona un presupuesto mensual de seis cifras. Sin embargo, a menudo no sabe qué eventos estaban llenos, cuáles están crónicamente infra-reservados y qué formadores reciben las mejores evaluaciones. Porque esos datos están en diferentes hojas y nadie tiene tiempo de consolidarlos.

## Lo que el [Decision Layer](/es/decision-layer/) hace diferente

La clave de la logística formativa: casi cada paso de coordinación sigue reglas claras. El formato se deriva del tipo de formación y el aforo. Los recordatorios se envían en momentos fijos. Las reglas de cancelación dependen del tiempo de antelación. La promoción de lista de espera sigue un orden. Las evaluaciones se envían el día después del evento.

Eso no es casualidad. Es la razón por la que este agente está en el cuadrante H2: alta frecuencia de transacción, baja complejidad de decisión.

```
Paso                        Quién decide       Por qué
─────────────────────────── ─────────────────  ──────────────────────────────
Establecer formato           Reglas             Tipo + capacidad determinan formato
Identificar formador         Agente             Match cualificación + cruce agenda
Asignar sala                 Agente             Capacidad, equipamiento, disponibilidad
Invitar participantes        Reglas             Lista de análisis de necesidades o inscripción
Pedir materiales             Reglas             Checklist según tipo de evento
Enviar recordatorios         Reglas             7 días + 1 día antes del evento
Promoción lista de espera    Reglas             Orden ante cancelación
Activar evaluación           Reglas             Día después del evento
Procesar cancelación         Reglas             Reglas de cancelación según plazo
```

Siete de nueve pasos son decisiones determinísticas basadas en reglas. Solo dos - identificación de formador y asignación de sala - requieren una lógica de agente que optimice múltiples variables simultáneamente: cualificación contra disponibilidad, capacidad contra equipamiento. Ningún paso requiere una decisión humana caso por caso.

## Cómo cambia el día a día del departamento de L&D

Cuando los sistemas están en marcha - LMS con función de eventos, gestión de salas, pool de formadores con datos de calendario - el trabajo operativo se transforma en tres puntos.

El tiempo de planificación por evento baja de horas a minutos. En lugar de cruzar agendas manualmente, comprobar salas y contactar formadores, la dirección de L&D introduce tipo de formación, grupo destinatario y período temporal. El agente entrega una propuesta completa: formador, sala, franja horaria, lista de materiales. Si la propuesta encaja, se confirma con un clic. Si no encaja, se ajustan las restricciones y se genera una nueva propuesta.

Cancelaciones y reprogramaciones pierden su impacto operativo. Ante la baja de un formador, el agente busca inmediatamente formadores sustitutos cualificados con agenda libre. Ante cancelaciones de participantes, la lista de espera avanza automáticamente - incluyendo notificación, ajuste de materiales y lista de participantes actualizada. La cascada manual de consultas, contrapropuestas e invitaciones actualizadas desaparece.

El departamento de L&D obtiene datos de gestión que antes no existían. Tasas de ocupación por formato de formación, patrones de cancelación por departamento y día de la semana, evaluaciones de formadores en el tiempo, coste medio por participante y tipo de formación. No como un laborioso informe trimestral, sino como reporting continuo que surge automáticamente de los datos de reserva. Estos datos marcan la diferencia entre un departamento de L&D que ejecuta eventos y uno que gestiona activamente su portfolio.

## El efecto infraestructura

El motor de coordinación de eventos - sala, personas, material, planificación temporal contra disponibilidad - no es una pieza aislada. El mismo mecanismo que planifica un taller puede orquestar un evento de onboarding, programar un assessment center o coordinar una asamblea de trabajadores. El patrón de lista de espera se convierte en componente para cualquier agente con recursos de capacidad limitada.

Y cada reserva, cada cancelación, cada reprogramación queda protocolada en el Decision Log. El Comité de Empresa, que según el artículo 64 del Estatuto de los Trabajadores tiene derechos de información sobre la formación profesional en la empresa, no ve una planificación anual resumida, sino la base documental de cada evento individual. Transparencia que facilita los derechos de información - porque los datos ya están estructurados.

Quien coordina 30 eventos al mes manualmente, administra. Quien los coordina de forma automatizada, dirige.

--- Learning Path Recommendation Agent ---
> Recomienda itinerarios formativos personalizados según competencias, requisitos del puesto y aspiraciones de carrera. No vinculante.

## El problema central: catálogos llenos, aulas vacías

La mayoría de las organizaciones no tienen un déficit de oferta. Tienen un problema de asignación. Un LMS típico en una empresa mediana contiene varios centenares de cursos, módulos y rutas de certificación. Al mismo tiempo, la tasa media de finalización en formatos de autoformación se sitúa entre el 5 y el 15 por ciento. El 44 por ciento de las empresas están insatisfechas con su LMS, el 37 por ciento busca activamente alternativas. La oferta formativa crece, el uso se estanca.

El cuello de botella no es el contenido. El cuello de botella es la pregunta: qué curso aporta a esta persona concreta, en este puesto concreto, el mayor avance en su desarrollo.

Responder esta pregunta manualmente desborda a cualquier departamento de L&D. Un responsable con doce colaboradores directos debería cruzar por persona perfil de competencias, objetivo de carrera, formaciones completadas y oferta disponible. Con 800 empleados y 400 cursos disponibles surgen cientos de miles de combinaciones posibles. Ningún ser humano navega eso de forma fiable. El resultado: recomendaciones por intuición, formación regadera, presupuestos sin evidencia de impacto.

## Lo que un agente de recomendación cambia estructuralmente

Un Learning Path Recommendation Agent no resuelve el problema de asignación con más tecnología, sino con mejor arquitectura de decisión. El flujo sigue una cadena clara:

```
Perfil actual       Perfil objetivo       Brecha          Oferta
┌──────────┐      ┌──────────┐      ┌──────────┐    ┌──────────┐
│ Compe-   │      │ Rol      │      │ Análisis │    │ Matching │
│ tencias, │─────>│ objetivo │─────>│ de Gap   │───>│ contra   │
│ cursos,  │      │ o        │      │ Real vs. │    │ catálogo │
│ rol      │      │ siguiente│      │ Requerido│    │          │
└──────────┘      └──────────┘      └──────────┘    └──────────┘
     A                 H                 A                A

A = Agente decide    H = Persona decide
```

El punto decisivo: el rol objetivo permanece en la persona. El empleado define en la conversación de desarrollo hacia dónde quiere dirigirse. Todo lo anterior y posterior - análisis de perfil, determinación del perfil requerido del rol objetivo, cálculo de brecha, filtrado de oferta, selección de formato y proveedor, comprobación de presupuesto y tiempo, priorización - lo puede hacer un agente de forma más rápida, completa y consistente que cualquier búsqueda manual.

Los itinerarios formativos personalizados incrementan la tasa de finalización en torno a un 30 por ciento. No porque el contenido sea mejor, sino porque la adecuación es correcta. Quien ve exactamente los módulos que abordan su brecha de competencias concreta invierte tiempo de aprendizaje con retorno visible.

## Por qué es especialmente relevante en la empresa mediana

En organizaciones entre 500 y 5.000 empleados convergen dos realidades. Por un lado: el 81,8 por ciento de las empresas reconoce que los empleados disponen de poco margen para la formación. Por otro: el 42,9 por ciento identifica la personalización insuficiente como problema central de su estrategia de L&D.

Poco tiempo y mala tasa de acierto - esa es la combinación tóxica. Si un empleado dispone de cuatro horas por trimestre para formación, ninguna de ellas puede desperdiciarse en un curso irrelevante. Cada recomendación debe acertar.

Las grandes corporaciones resuelven esto con equipos de L&D dedicados que elaboran planes de desarrollo individuales. En la empresa mediana falta esa capacidad. Tres técnicos de desarrollo de personas para 2.000 empleados no pueden curar 2.000 itinerarios formativos individuales. Pero un agente sí puede - y actualizados semanalmente, no una vez al año en la conversación de desarrollo.

## Trazabilidad en lugar de caja negra

Una preocupación frecuente con las recomendaciones algorítmicas: por qué exactamente esta oferta. El [Decision Layer](/es/decision-layer/) protocola cada paso de decisión. Qué datos se incorporaron, qué ponderación se aplicó, por qué el curso A se priorizó sobre el curso B. Esta transparencia no es una obligación regulatoria - las recomendaciones de itinerarios formativos no son un sistema de alto riesgo bajo el Reglamento de IA mientras permanezcan no vinculantes. Pero es operativamente decisiva.

Cuando un Comité de Empresa pregunta según qué criterios se generan las recomendaciones, hay una respuesta documentada. Cuando un responsable cuestiona una recomendación, la justificación está disponible. Y cuando un empleado rechaza la recomendación, eso queda sin consecuencias - es una sugerencia, no una asignación.

## El efecto infraestructura

El framework de recomendación no trabaja aislado. Análisis de perfil, cálculo de brecha y matching de oferta constituyen un fundamento reutilizable. El mismo mecanismo que recomienda itinerarios formativos puede evaluar trayectorias de carrera, identificar candidatos de sucesión o hacer visibles brechas de competencias estratégicas a nivel organizacional.

Cada recomendación genera además datos: qué brechas aparecen con frecuencia, qué ofertas se aceptan y cuáles se ignoran, qué departamentos se desarrollan más rápido que otros. Estos datos retroalimentan la planificación - no como instrumento de control sobre personas individuales, sino como magnitud de gestión estratégica para la planificación formativa.

La diferencia con un mejor filtro del LMS: un filtro muestra cursos que podrían encajar. Un agente de recomendación fundamenta por qué exactamente este curso en este momento tiene el mayor efecto palanca - y entrega el Audit Trail incluido.

--- Leave of Absence Agent ---
> Gestiona solicitudes de permisos extendidos: elegibilidad, cálculo de derechos, aprobaciones, ajustes de nómina y coordinación de reincorporación.

Cada mes llegan solicitudes de ausencia que no pueden esperar. Permiso de maternidad y paternidad conforme al Estatuto de los Trabajadores. Reducción de jornada por cuidado de hijos (artículo 37.6 ET). Excedencia por cuidado de familiares (artículo 46.3 ET). Permisos retribuidos por matrimonio, nacimiento o fallecimiento. Cuatro bases legales, cuatro regímenes de plazos distintos, cuatro conjuntos de requisitos - y cada solicitud individual consume capacidad de RRHH que en realidad se necesita para trabajo estratégico.

El problema no es la solicitud individual. El problema es la simultaneidad.

## Por qué precisamente ahora

En España, el permiso de nacimiento y cuidado del menor se ha equiparado a 16 semanas para ambos progenitores. La combinación con la reducción de jornada por cuidado legal es cada vez más frecuente. La Ley de Familias amplía progresivamente los permisos retribuidos. La excedencia por cuidado de hijos de hasta tres años (artículo 46.3 ET) con reserva de puesto el primer año es un derecho que genera complejidad operativa significativa.

Simultáneamente crece la demanda de permisos por cuidado de dependientes. El Estatuto reconoce la reducción de jornada por cuidado de familiares hasta segundo grado y la excedencia por cuidado de familiar dependiente. Cada variante tiene requisitos propios, plazos diferentes e impacto distinto en retribución y Seguridad Social.

A esto se suman los casos cotidianos: permisos retribuidos por mudanza, matrimonio, fallecimiento. Vacaciones no disfrutadas - la mayoría de los trabajadores acumulan días pendientes de un año para otro. Excedencia voluntaria por acuerdo individual.

Para RRHH surge un cálculo con muchas incógnitas. Y las consecuencias de los errores no son triviales: plazos incorrectos en solicitudes de permisos retrasan el inicio. Un cálculo erróneo de derechos genera riesgos laborales. La falta de planificación de sustitución impacta en la operación.

## Lo que el agente transforma

El [Decision Layer](/es/decision-layer/) separa en este proceso dos mundos.

El primer mundo es reglas. Verificación de derechos, cálculo de plazos, impacto en retribución - son operaciones determinísticas. Si alguien tiene derecho a permiso de nacimiento está en el Estatuto de los Trabajadores. Si el plazo de solicitud se ha respetado se deriva de la fecha del hecho causante y el inicio solicitado. Cómo afecta una excedencia de seis meses al plan de pensiones de empresa está en el reglamento del plan. Estas verificaciones no necesitan a una persona. Necesitan un motor de reglas correctamente configurado.

El segundo mundo es decisión. Quién asume la sustitución. Se concede una excedencia voluntaria cuando no existe derecho legal. Cómo se diseña el retorno tras 14 meses de permiso parental. Estas preguntas requieren contexto, criterio y responsabilidad. Permanecen en el responsable y en RRHH.

Entre estos dos mundos hay una franja estrecha donde la IA aporta: propuestas de sustitución basadas en perfiles de competencia y disponibilidad. No una decisión - una propuesta que acota el espacio de búsqueda.

```
Solicitud recibida
    |
    v
[Reglas] Clasificación --> Maternidad/Paternidad | Cuidado hijos |
                           Excedencia | Permiso retribuido
    |
    v
[Reglas] Verificación de derechos --> ET | Convenio | Política empresa
    |
    v
[Reglas] Cálculo de plazos + Impacto en retribución
    |
    v
[IA] Propuesta de sustitución (Competencias + Disponibilidad)
    |
    v
[Persona] Confirmar sustitución + Aprobar solicitud
    |
    v
[Reglas] Planificación de retorno + Recordatorios automáticos
```

## Lo que cambia con esto

La diferencia no se manifiesta en una solicitud individual. Se manifiesta en la suma a lo largo de un año.

Una empresa con 2.000 trabajadores procesa al año típicamente varios centenares de ausencias más allá de las vacaciones ordinarias: permisos de nacimiento, reducciones de jornada, excedencias, permisos retribuidos, excedencias voluntarias. Cada proceso tiene una fase de verificación (derecho, plazo, retribución), una fase de coordinación (sustitución, traspaso) y una fase de retorno (re-onboarding, reactivación de sistemas).

Cuando la fase de verificación está automatizada, ocurren dos cosas simultáneamente: el tiempo de tramitación se reduce porque ninguna solicitud espera sobre un escritorio. Y la tasa de error baja porque el motor de reglas no omite plazos ni confunde bases legales.

La coordinación de la sustitución no comienza dos semanas antes del inicio de la ausencia, sino inmediatamente tras la recepción de la solicitud. Eso da a los equipos tiempo para traspasos ordenados en lugar de soluciones de emergencia.

El retorno no se olvida. Cuatro semanas antes de la fecha de retorno documentada, el responsable y RRHH reciben un recordatorio. Para ausencias prolongadas incluye una checklist de re-onboarding adaptada al tipo y duración de la ausencia.

## La contribución a la infraestructura

El motor de verificación de derechos que aquí se construye para permisos de nacimiento y excedencias por cuidado es reutilizable. La misma lógica - derecho legal, derecho contractual, cálculo de plazos - se necesita en la gestión de período de prueba y en la generación de contratos. El patrón de propuesta de sustitución constituye la base para la planificación de plantilla. La planificación automatizada de retorno es un patrón para cualquier agente que desencadene acciones de seguimiento en el tiempo.

Ese es el punto real: cada agente bien construido genera infraestructura para el siguiente.

--- Legal Contract Review Agent ---
> Asiste en revisión de contratos comerciales: extrae términos, compara con posiciones estándar y señala desviaciones y riesgos clave.

## Los abogados dedican la mitad de su tiempo a tareas que no requieren experiencia jurídica

Según Gartner, hasta el 50 por ciento de la capacidad de un departamento legal se dedica a la gestión contractual. La mayor parte de ese tiempo no es pensamiento jurídico - es leer, comparar, clasificar. Un contrato de servicios se coteja con la plantilla interna de cláusulas. Un NDA se revisa para identificar desviaciones en duración y jurisdicción. Un contrato marco se compara cláusula por cláusula con el estándar.

Este trabajo requiere diligencia. Pero en la mayoría de los casos no requiere juicio jurídico. La pregunta no es si un abogado sabe leer la cláusula de responsabilidad, sino si es la persona adecuada para constatar que es idéntica a la versión estándar.

Aquí reside exactamente el patrón que se puede automatizar: el cotejo del texto contractual contra estándares definidos. La extracción de cláusulas de riesgo conocidas. La clasificación por tipo de contrato. En un departamento legal que revisa 200 contratos por trimestre, esto marca la diferencia entre un equipo que reacciona y un equipo que configura.

## Noventa y dos minutos por contrato no son un estándar de calidad, son un cuello de botella

El tiempo medio de revisión de un contrato estándar es de 92 minutos. En el caso de un NDA - el tipo más sencillo - los sistemas de IA actuales realizan el mismo cotejo en 26 segundos con un 94 por ciento de precisión ([Sirion, 2026](https://www.sirion.ai/library/contract-insights/ai-playbook-redlining-vs-manual-contract-review/)). El 6 por ciento restante no es un argumento contra la automatización. Es un argumento para el reparto correcto: el agente revisa las cláusulas estándar, el abogado revisa las desviaciones.

Imagine una semana típica en un departamento legal que atiende contratos de compras. El lunes llegan tres nuevos contratos con proveedores. El miércoles, un contrato marco renovado con condiciones de responsabilidad modificadas. El viernes, un NDA para una due diligence. Cada uno de estos contratos pasa por el mismo proceso: identificar el tipo, cotejar cláusulas estándar, marcar desviaciones, evaluar riesgos. Sólo después comienza el trabajo jurídico real - la evaluación de si una desviación es aceptable o debe renegociarse.

El agente de análisis contractual se encarga de los primeros seis pasos de este proceso. Los tres últimos - evaluación de riesgos por parte del abogado, recomendación de negociación y aprobación - permanecen donde el Derecho lo exige: en manos humanas.

## Seis pasos de decisión automatizados, tres en manos del abogado

El [Decision Layer](/es/decision-layer/) descompone cada proceso de revisión contractual en pasos de decisión individuales y define para cada uno: humano, motor de reglas o IA. En el caso del análisis contractual, esta descomposición ofrece una imagen clara.

Los pasos automatizables siguen un patrón: comparan el estado real contra el estado objetivo. ¿Es este contrato un NDA o un contrato de servicios? ¿Corresponde la cláusula de responsabilidad al estándar o se desvía? ¿Contiene el contrato una cláusula penal? Estas preguntas pueden responderse con fiabilidad si existe una biblioteca de cláusulas bien mantenida.

Los pasos humanos siguen otro patrón: requieren juicio bajo incertidumbre. ¿Es aceptable el límite de responsabilidad desviado para este proveedor concreto? ¿Compensa el valor comercial del contrato el riesgo de una cláusula de garantía ausente? ¿Puede aprobarse el contrato en estas condiciones? Son decisiones que requieren contexto que ningún agente posee - relación comercial, historia de negociación, prioridades estratégicas.

La puntuación de gobernanza de este agente, 55-62, es claramente superior a la de las automatizaciones puramente de proceso. Refleja que el análisis contractual opera más cerca de decisiones jurídicamente relevantes que, por ejemplo, la nómina o el control horario. El agente puede analizar y marcar. Evaluar y decidir, no.

## La biblioteca de cláusulas decide el éxito - y todavía no existe

Este agente es un agente H3. Eso significa: mayor complejidad, menor madurez que las automatizaciones de procesos consolidadas. Los sistemas de IA actuales pierden entre un 10 y un 20 por ciento de precisión en contratos con prompts superiores a 1.000 caracteres ([WorldCC / KPMG, 2025](https://kpmg.com/us/en/articles/2025/agentic-ai-in-clm-balancing-human-and-machine-expertise.html)). En un contrato marco de 30 páginas, ese es un factor relevante.

El requisito más importante no es tecnológico, sino una biblioteca de cláusulas cuidada con los estándares corporativos para cada tipo de contrato. Sin ese punto de referencia, el agente no tiene nada contra lo que comparar. La biblioteca define qué significa "estándar". Sólo entonces el agente puede identificar qué es una "desviación".

Las empresas que ya operan un sistema de Contract Lifecycle Management y tienen documentadas sus cláusulas estándar pueden poner este agente en producción más rápido. Las empresas sin esa base la construyen junto con el agente - lo que ralentiza el despliegue, pero crea un valor independiente. Una biblioteca de cláusulas estructurada mejora la revisión contractual incluso sin agente, porque establece por primera vez un criterio unificado.

El horizonte temporal honesto: no productivo el mes que viene, sino tras la construcción de la biblioteca de cláusulas y una fase de calibración con el departamento legal. La ganancia posterior: abogados que dedican su tiempo a los casos en los que realmente se necesita juicio jurídico.

--- Agente Merit-Cycle ---
> Ciclo anual retribución: ET art. 17/28, RD 902/2020 auditoría, EU AI Act Anexo III(4)(b) Sistema Alto Riesgo y Pay Transparency 5% Gender Pay Gap - Bias-Audit con RGPD art. 22.

## Cinco meses desde aprobación del presupuesto hasta el primer pago

Este agente sigue el principio [Decision Layer](/es/decision-layer/): cada decisión es basada en reglas, asistida por IA o explicitamente asignada a un humano. Esta clasificado según [EU AI Act 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) Anexo III(4)(b) como Sistema Alto Riesgo y por tanto sujeto a obligaciones reforzadas sobre Sistema Gestión Riesgo, Governance Datos, Transparencia, Supervisión Humana y Bias-Audit desde 2.8.2026.

Un ciclo merit típico dura cinco meses. No porque las decisiones sean dificiles, sino porque el proceso lo es. Aprobación presupuesto en septiembre. Preparación datos en octubre. Distribución spreadsheet a 30, 50, 80 managers en noviembre. Devoluciones por semanas. Rondas calibración en enero. Correcciones. Entrega a Payroll en febrero. Primer pago como muy pronto en marzo.

El problema no esta en el tiempo. Esta en lo que pasa entre los pasos - o mas bien lo que no pasa: analisis equidad sistematico, rationales documentables para inversión carga prueba ET art. 17/28, validación Compa-Ratio, consistencia entre unidades de negocio y niveles jerarquia.

## Lo que queda invisible en rondas de spreadsheet

Cuando 60 managers rellenan propuestas retributivas en archivos Excel paralelos, no emerge un proceso consistente. Emerge una colección de evaluaciones individuales que nadie puede agregar, validar o comparar en tiempo real. Las consecuencias tipicas:

**Violaciones de banda sin advertencia.** Un manager recomienda un aumento que empuja al empleado por encima del extremo superior de la banda retributiva. En la spreadsheet, esto solo se hace evidente cuando Comp&Ben revisa manualmente el archivo - frecuentemente semanas después, frecuentemente nunca. Empresas reportan regularmente que empleados son retribuidos fuera de sus bandas salariales definidas sin que se note sistematicamente.

**Brechas de equidad permanecen ocultas.** Cuando 60 archivos Excel se rellenan en paralelo, una ronda calibración en enero no nota que las managers de ventas femeninas reciben sistematicamente 4 por ciento ajustes inferiores que los masculinos - o que la brecha salarial entre 50+ y empleados de mitad-carrera en cierta función es 7 por ciento.

**Carga de la prueba invertida sin pista de auditoría.** En una demanda, la carga de la prueba se invierte bajo la igualdad retributiva del ET (arts. 17 y 28) y el RD 902/2020: si el empleado aporta indicios de discriminación, como una anomalía estadística o la falta de fundamento, corresponde a la empresa demostrar que no la hubo. Sin un fundamento documentado y reproducible para cada ajuste, esa prueba es casi imposible de cumplir. El precedente Mobley v. Workday demuestra el riesgo sistémico.

## Los riesgos de sanción se acumulan entre la igualdad retributiva, el EU AI Act y el RGPD

Los riesgos de sanción de un ciclo de retribución mal gestionado se acumulan. La igualdad retributiva del ET y la LO 3/2007 abren la puerta a indemnizaciones por discriminación, y el RD 902/2020 a sanciones de la ITSS de hasta 187.515 euros. En acciones colectivas con varios demandantes del mismo grupo comparable, la cifra puede alcanzar pronto los siete dígitos, y la inversión de la carga de la prueba hace casi imposible la defensa sin un fundamento documentado por cada ajuste.

A ello se suman el EU AI Act, que para los sistemas de alto riesgo en retribución llega a 35 millones de euros o el 7% de la facturación global del grupo, y el RGPD, que alcanza el 4% o 20 millones. Incumplir la obligación de información del ESRS S1-10 conlleva salvedades del auditor y responsabilidad del Consejo de Administración, y omitir la consulta al Comité de Empresa abre un procedimiento ante la jurisdicción social.

El precedente Mobley v. Workday, sobre el sesgo de edad en software de RRHH en Estados Unidos, marca por analogía la línea de los reguladores y los estándares de los auditores. Plataformas como Workday, SAP SuccessFactors u Oracle Cloud HCM, junto a herramientas como las de Mercer, ofrecen instrumentos para mitigar el sesgo de forma proactiva.

## EU Pay Transparency Directive 2023/970 como presión cumplimiento

Desde 6 junio 2026 [EU Pay Transparency Directive 2023/970](https://eur-lex.europa.eu/eli/dir/2023/970/oj) (transposición nacional) obliga a fundamentos documentables para cada ajuste. En desviaciones Gender Pay Gap de 5 por ciento brecha inexplicada (Article 9), se aplican obligaciones Joint Pay Assessment y procedimientos remediación dentro 6 meses (Article 10). Empleados reciben derecho información sobre mediana retribución grupo comparable (Article 7), en ofertas trabajo la divulgación horquilla salarial es obligatoria (Article 6), y la pregunta sobre historial salarial de empleadores anteriores esta prohibida (Article 5).

La carga prueba en demandas discriminación retributiva se invierte (Article 18): Corresponde al empresario mostrar que no ocurrio discriminación. Obligaciones reporting Gender Pay Gap escalonan desde 250 empleados (desde 2027) hasta 100 empleados (desde 2031). Sanciones: estandares minimos Article 20 con multas y daños. Transposición nacional España hasta 7.6.2026 esperada con refuerzo ET art. 17/28 y RD 902/2020.

## La clasificación de alto riesgo del EU AI Act, con evaluación de impacto y FRIA

El Merit-Cycle-Governance-Agent cae bajo EU AI Act 2024/1689 Anexo III Punto 4 Letra b sistemas Alto Riesgo para decisiones retributivas HR. Las obligaciones desde 2.8.2026 incluyen:

- **Article 9, gestión de riesgos**: identificación, análisis, evaluación y mitigación de los riesgos de sesgo por género, edad, origen y discapacidad
- **Article 10, gobernanza de los datos**: calidad de los datos de entrenamiento, detección de sesgo y pruebas de paridad demográfica e igualdad de oportunidades
- **Article 13, transparencia**: documentación sobre el funcionamiento, la precisión, la robustez y los resultados de la auditoría de sesgo
- **Article 14 Supervisión Humana**: humano-en-el-bucle obligatorio en cada recomendación
- **Article 26, obligaciones del responsable del despliegue**: evaluación de impacto, consulta a la autoridad de supervisión, seguimiento posterior y notificación de incidentes
- **Article 27, evaluación de impacto en los derechos fundamentales (FRIA)**: antes del despliegue, con consulta a la AEPD, el DPD, el Comité de Empresa y la AESIA

Multas hasta 35 millones EUR o 7 por ciento facturación global grupo. Cross-Reference RGPD art. 35 obligación DPIA en evaluación automatizada sistematica con impacto significativo. [Mobley v. Workday acción colectiva](https://www.courtlistener.com/docket/67476007/mobley-v-workday-inc/) (Northern District California 2023) - alegación AI bias en software reclutamiento HR contra candidatos 40+ ADEA - sirve como precedente US y da forma a linea reguladores UE.

## Equity audit como ventaja sobre proceso manual

El motor de análisis de equidad comprueba estadísticamente todas las características protegidas por la igualdad retributiva del ET, la LO 3/2007, el RD 902/2020 y la Ley General de Discapacidad. Para cada una mide la paridad demográfica (la misma frecuencia de ajuste entre grupos) y la igualdad de oportunidades (la misma magnitud de ajuste a igual rendimiento). Ante una desviación estadísticamente significativa, escala automáticamente al HR Lead con su pista de auditoría.

Esto no es solo protección cumplimiento: estudios (ej. McKinsey Diversity Wins, BCG Closing the Gap, Catenon Pay Equity Reports) muestran 4-6 por ciento brechas equidad en gran empresa España y 2-4 por ciento en IBEX-35 que permanecen manualmente sin detectar. El agente las hace visibles y crea fundamento datos para ajustes corrección dirigidos.

## Cross-reference a Compensation-Benchmarking, Performance-Review y Payroll

Merit-Cycle-Governance-Agent esta embebido en pipeline de agentes HR especializados: [Compensation-Benchmarking-Agent](/es/catalogo-agentes-hr/compensation-benchmarking-agent/) proporciona bandas retributivas, Compa-Ratios y datos horquilla salarial. [Performance-Review-Agent] proporciona calificaciones rendimiento como prerequisito elegibilidad. [Payroll-Calculation-Agent](/es/catalogo-agentes-hr/payroll-calculation-agent/) recibe ajustes aprobados con fecha efectividad correcta. [Payroll-Reporting-Agent](/es/catalogo-agentes-hr/payroll-reporting-agent/) genera CSRD ESRS S1-10 Equal Pay Reporting. [HR-Document-Management-Agent](/es/catalogo-agentes-hr/hr-document-management-agent/) archiva ET art. 17/28-conforme rationales ajuste 4 anos retención registros laborales. [Audit-Compliance-Agent](/es/catalogo-agentes-hr/audit-compliance-agent/) verifica EU AI Act Article 26 obligaciones desplegadores y consistencia DPIA. [Interview-Scheduling-Agent](/es/catalogo-agentes-hr/interview-scheduling-agent/) aplica EU Pay Transparency Article 6 horquilla salarial en ofertas trabajo.

## De un vistazo

- **Clasificación**: EU AI Act 2024/1689 Anexo III(4)(b) Sistema Alto Riesgo HR Decisiones Retributivas desde 2.8.2026
- **Anclas de cumplimiento**: la igualdad retributiva del ET (arts. 17 y 28), la LO 3/2007, los RD 901/2020 y 902/2020, el art. 14 de la Constitución, la Directiva de Transparencia Retributiva, el RGPD y el reporte ESRS S1-10
- **Consulta**: obligatoria al Comité de Empresa según el ET art. 64 y la Comisión Negociadora del RD 901/2020
- **Umbral de equidad**: una brecha de género inexplicada por encima del 5% activa la evaluación retributiva conjunta y seis meses de plazo para corregirla
- **Multas**: hasta 35 millones de euros o el 7% de la facturación global por el EU AI Act, hasta el 4% o 20 millones por el RGPD y hasta 187.515 euros por la ITSS
- **Obligación de auditoría**: evaluación de impacto, FRIA y auditoría de sesgo trimestral, con verificación del auditor a partir de 250 empleados y la auditoría retributiva del RD 902/2020
- **Precedente US**: Mobley v. Workday Northern District California 2023 acción colectiva AI bias HR software

### Distribución de Decididores Merit-Cycle-Governance

| Paso | Decididor | Rationale |
|------|-----------|-----------|
| Establecer presupuesto | H | Estrategia de la Dirección y preparación del reporte de sostenibilidad |
| Comprobación de elegibilidad | R | Antigüedad, rendimiento y ausencia de suspensiones, según reglas |
| Provisión de benchmark | R | Cálculo determinista del Compa-Ratio |
| Recomendación del manager | H | Rendimiento individual y riesgo de retención |
| Validación de banda salarial | R | Comprobación automática del rango mínimo y máximo |
| Cumplimiento del presupuesto | R | Seguimiento determinista en tiempo real |
| Análisis de equidad | A | Detección estadística de sesgo con validación humana |
| Escalado de equidad | R | Umbral de brecha superior al 5% |
| Flujo de aprobación | R | Matriz por jerarquía y posición en el Compa-Ratio |
| Aprobación del HR Lead | H | Aprobación final conforme a la igualdad retributiva |
| Información al empleado | R | Flujo estándar conforme al RGPD |
| Conversación retributiva | H | Conversación personal de dimensión relacional |
| Entrega a Nómina | R | Fecha de efectividad y corrección determinista de IRPF y Seguridad Social |
| Reporte de sostenibilidad | R | Generación determinista del ESRS S1-10 |

--- Offboarding Agent ---
> Orquesta el offboarding completo: checklist entre RRHH, IT y dirección, transferencia de conocimiento y documentación de salida.

## 78.000 antiguos empleados siguen con credenciales activas - y ese es el problema real del offboarding

Este agente sigue el principio del [Decision Layer](/es/decision-layer/): cada decisión está basada en reglas, asistida por IA o asignada explícitamente a una persona.

Una proporción considerable de antiguos empleados conserva credenciales activas tras su baja - en muchas organizaciones, estos accounts inactivos representan porcentajes medibles de todos los usuarios en el proveedor de identidad. En una parte significativa de las cuentas marcadas como inactivas persisten permisos vivos en aplicaciones críticas. Y muchas empresas necesitan más de tres días para bloquear todos los accesos de sistema tras una baja. Algunas no lo consiguen nunca por completo.

Esto no es un problema menor. Es la puerta de entrada para cualquier atacante que prefiera credenciales válidas antes que atravesar cortafuegos.

## Cinco corrientes, ningún director

Un proceso de offboarding afecta al menos a cinco áreas de responsabilidad simultáneamente. Ninguna espera a las demás. Todas tienen sus propios plazos, sus propios sistemas y sus propios puntos ciegos.

```
Baja / extinción del contrato
    |
    +-- RRHH: cerrar expediente, notificaciones, certificado de empresa
    +-- IT: devolver hardware, revocar accesos, liberar licencias
    +-- Área de negocio: transferencia de conocimiento, traspaso de proyectos
    +-- Responsable: entrevista de salida, documentar feedback
    +-- Protección de datos: iniciar plazos de supresión, comprobar obligaciones
    |
Último día (todo debe estar hecho)
    |
Fase posterior: certificado, supresión RGPD, seguimiento boomerang
```

En la práctica, RRHH coordina todo esto con una lista de verificación y correos de recordatorio. Con tres bajas por trimestre funciona. Con treinta, colapsa - y lo hace en silencio. Nadie se da cuenta del acceso VPN que sigue activo dos meses. Nadie pregunta por la carpeta de SharePoint con datos de clientes a la que el antiguo empleado sigue pudiendo acceder.

## Por qué el offboarding es más caro de lo que parece

Los costes visibles de una salida mal gestionada son asumibles: un portátil olvidado, una baja tardía. Los invisibles, no.

El 41,6 por ciento de los responsables de RRHH estima que un offboarding inconsistente cuesta a su empresa hasta 500.000 EUR (550.000 USD) anuales - por pérdida de conocimiento, riesgos de seguridad y sobrecostes de cobertura. Sólo el 37 por ciento de las empresas garantiza una transferencia de conocimiento adecuada al salir. El 42 por ciento del conocimiento especializado de una posición existe exclusivamente en la cabeza de quien la ocupa y no puede trasladarse sin más a un sustituto.

Tres factores de coste pesan especialmente:

**Riesgo de seguridad.** Las cuentas huérfanas son el vector de ataque más sencillo. Sin fuerza bruta, sin phishing - las credenciales siguen existiendo. En un mundo en el que una empresa media opera 275 aplicaciones SaaS, el desaprovisionamiento manual es una ilusión.

**Pérdida de conocimiento.** El coste de perder a un experto en la materia puede equivaler a veinte veces los costes habituales de selección e incorporación. No porque la persona sea insustituible, sino porque lo es su conocimiento no documentado.

**Potencial boomerang.** El 35 por ciento de las nuevas contrataciones son ya retornos. Su tasa de retención es un 44 por ciento superior a la de empleados completamente nuevos. Una salida caótica destruye exactamente la relación que habría permitido una recontratación.

## Tres ventanas de tiempo, tres problemas distintos

El offboarding no es un evento único. Se descompone en tres fases con exigencias radicalmente distintas.

**Antes del último día:** organizar la transferencia de conocimiento, traspasar proyectos, preparar al sucesor. Aquí decide el responsable qué conocimiento es crítico - ninguna regla puede automatizarlo, porque requiere contexto sobre la dinámica del equipo y las dependencias entre proyectos.

**El último día:** devolución de hardware, bloqueo de accesos, recogida de tarjeta. Esto es totalmente basado en reglas. Qué dispositivos deben devolverse figura en la lista de dotación del onboarding. Qué accesos se bloquean se deriva del perfil de permisos. Momento y orden siguen un plan de desactivación - sistemas críticos al instante, reenvío de correo tras un plazo de transición definido.

**Tras la salida:** emitir certificado, cumplir plazos de supresión, cerrar liquidación. En España el certificado de empresa para el SEPE debe emitirse en los 10 días siguientes a la baja, la liquidación y finiquito (Seguridad Social, AEAT) acompañan al cese. La obligación de supresión del RGPD corre en paralelo a las obligaciones mercantiles y fiscales de conservación, de seis a diez años - un campo de tensión que sin una dirección clara conduce regularmente a incumplimientos.

```
Fase              Error habitual                    Consecuencia
──────────────    ──────────────────────────────    ──────────────────────
Antes de baja     Sin plan de transferencia         42% del conocimiento se va
Último día        VPN/nube no bloqueados            Riesgo de seguridad
Fase posterior    Certificado a los 4 meses         Reclamación judicial
Fase posterior    Supresión RGPD olvidada           Multa hasta 20 M EUR
```

## Lo que el agente realmente dirige

El Offboarding Agent es el espejo del Onboarding Workflow Agent. El mismo motor de orquestación, la misma arquitectura de plantillas, reparto de tareas y control de plazos - sólo que en sentido inverso.

En cuanto se registra una baja en el sistema de RRHH, ocurren tres cosas a la vez: el motor de reglas determina el tipo de offboarding según el motivo de salida - baja voluntaria, despido, acuerdo de extinción y jubilación generan listas distintas. La lista completa de tareas se genera a partir de la plantilla y se distribuye a las instancias responsables. Desde ese momento el agente supervisa plazos y escala en caso de retraso.

La arquitectura de decisión es deliberadamente restrictiva. De diez pasos del proceso, seis son basados en reglas, uno asistido por IA y tres permanecen en manos humanas. La IA sólo interviene en el borrador del certificado - donde a partir de la descripción del puesto, la duración del empleo y la evaluación de desempeño se genera un texto. Si el certificado se aprueba, si se realiza la entrevista de salida y qué conocimiento se considera crítico son decisiones personales del responsable y de RRHH.

## La supresión según el RGPD como problema arquitectónico

La mayoría de las empresas trata las obligaciones de supresión como una tarea del delegado de protección de datos. Funciona mientras alguien se acuerda. Con 50 bajas al año repartidas entre sistemas sin rutina de supresión centralizada, en algún momento ya nadie se acuerda.

El campo de tensión es real: las nóminas deben conservarse entre seis y diez años. Los currículos de candidatos deben suprimirse, como máximo, a los seis meses. Los expedientes de personal caen bajo los plazos de prescripción laborales. En caso de incumplimiento, la AEPD puede imponer sanciones - abiertas por arriba hasta 20 millones de EUR (22 millones USD) o el 4 por ciento del volumen de negocio anual mundial.

Un Offboarding Agent no lo resuelve mediante supresión, sino mediante gestión de plazos. Cada registro recibe al salir una categoría de conservación con fecha de supresión concreta. El agente supervisa los plazos y escala cuando una fecha se aproxima. La supresión propiamente dicha sigue siendo un paso manual con principio de doble validación - pero el recordatorio es sistemático en lugar de aleatorio.

## Valor de infraestructura: el motor de onboarding en reversa

La palanca económica más potente de este agente no reside en la automatización del proceso en sí, sino en la reutilización. El motor de listas de verificación, el reparto de tareas, el control de plazos y la lógica de escalado son idénticos a los del Onboarding Workflow Agent. Quien ha construido uno obtiene el otro como configuración, no como proyecto.

Además, la lógica de desactivación de sistemas sienta las bases para la gestión de accesos a lo largo de todas las fases del ciclo de vida - del traslado al permiso parental, del regreso tras excedencia a la recontratación. Y el patrón de generación de certificados se reutiliza por el HR Document Management Agent para cartas de servicios, confirmaciones y referencias.

Cada ejecución de offboarding genera un registro de auditoría completo: qué tarea se completó cuándo, qué plazo se cumplió o se superó, quién escaló. A partir de 100 ejecuciones documentadas surge un cuadro de dónde falla sistemáticamente el proceso - no porque alguien haya pedido un informe, sino porque la arquitectura genera esos datos como subproducto.

--- Onboarding Workflow Agent ---
> Orquesta el onboarding completo: RRHH, IT, Servicios Generales y responsable directo - experiencia de primer día consistente sin pasos omitidos.

## Un tercio de los nuevos empleados se va porque el primer día no está preparado

Este agente sigue el principio del [Decision Layer](/es/decision-layer/): cada decisión está basada en reglas, asistida por IA o asignada explícitamente a una persona.

Uno de cada tres nuevos empleados abandona la empresa en los primeros 90 días. No por el puesto. No por el salario. Sino porque el primer día falta el portátil, los accesos no están configurados y nadie sabe quién era responsable de la charla de seguridad. Estudios sectoriales muestran que más de un tercio de las empresas europeas registra renuncias incluso antes del primer día de trabajo. El coste medio por onboarding fallido ronda los 15.000 EUR (16.500 USD) - sin contar la productividad perdida del resto del equipo.

El problema no es desconocer qué hay que hacer. El problema es que nadie dirige.

## Ocho departamentos, ningún director

Un único proceso de onboarding implica al menos ocho unidades organizativas: RRHH redacta el contrato, IT provisiona hardware y accesos, Servicios Generales prepara el puesto de trabajo, el área de negocio planifica la formación, Cumplimiento compila las formaciones obligatorias, el responsable elige un buddy, Finanzas configura la nómina y Recepción necesita el nombre para la tarjeta.

```
Firma de contrato
    |
    +-- RRHH: expediente, notificaciones, paquete de bienvenida
    +-- IT: hardware, accesos, correo, VPN
    +-- Servicios Generales: puesto, llaves, aparcamiento
    +-- Área de negocio: plan de formación, selección de buddy
    +-- Cumplimiento: formación obligatoria, RGPD, PRL
    +-- Finanzas: nómina, dietas
    +-- Responsable: confirmar buddy, fijar objetivos
    +-- Recepción: identificación, tarjeta de acceso
    |
Primer día (todo tiene que estar listo)
```

Cada una de estas corrientes tiene sus propios plazos, sus propios sistemas y sus propios interlocutores. Ninguna sabe con fiabilidad dónde están las demás. RRHH suele coordinarlo con una lista de verificación en Excel y correos de recordatorio - un método que funciona con cinco incorporaciones al mes, pero colapsa con cincuenta por trimestre.

## Por qué las listas de verificación no escalan

Una lista de verificación dice: "solicitar dotación de IT". No dice qué dotación necesita un responsable comercial en Madrid frente a una desarrolladora en Valencia. No dice que la solicitud tiene tres semanas de plazo y por tanto debe enviarse el día de la firma, no cuando RRHH haya cerrado el expediente. No dice quién escala si a los diez días sigue sin haber portátil.

La complejidad real está en la configuración: cada combinación de puesto, ubicación, área y tipo de contrato genera una ruta de onboarding diferente. Una empresa con tres centros, cuatro áreas y diez tipos de puesto tiene, en teoría, 120 variantes distintas. En la práctica quizá existan cinco documentadas - el resto se improvisa.

## Lo que el agente realmente hace

El Onboarding Workflow Agent no es un chatbot que responde preguntas. Es un motor de orquestación que dirige un proceso definido desde la firma del contrato hasta la conversación de feedback a los 30 días.

En cuanto se firma un contrato ocurren tres cosas a la vez: el agente determina el tipo de onboarding mediante un motor de reglas, genera la lista completa a partir de la plantilla correspondiente y reparte cada tarea a la instancia responsable con un plazo concreto. Desde ese momento supervisa el progreso. No de forma pasiva como un cuadro de mando, sino activa - con recordatorios cuando el plazo se acerca y escalado cuando se supera.

La arquitectura de decisión detrás es deliberadamente conservadora. De 14 pasos del proceso, nueve son basados en reglas, tres asistidos por IA y dos permanecen en manos humanas. La IA sólo interviene donde hay que reconocer patrones - por ejemplo en el emparejamiento de buddies o en la personalización del paquete de bienvenida. Si un buddy se acepta y si el onboarding se considera finalmente un éxito lo decide personalmente el responsable.

## Los costes ocultos de la improvisación

La rotación temprana es el indicador visible. El menos visible: el tiempo hasta productividad. Los estudios muestran que los nuevos empleados necesitan entre 8 y 12 meses para alcanzar plena productividad. Con un onboarding caótico, esa fase se alarga notablemente. Si alguien espera tres días en la primera semana para tener acceso, no son tres días perdidos - son tres días en los que se cimenta una primera impresión equivocada.

El 90 por ciento de los nuevos empleados decide en los primeros 100 días si se queda o se va. No es una suposición - es la conclusión central de la investigación actual sobre onboarding. La decisión no cae en un gran momento, sino en pequeños: ¿funciona mi correo? ¿sabe mi equipo que vengo? ¿alguien ha pensado en mi primer día?

## Valor de infraestructura más allá del onboarding

El motor de orquestación que construye el Onboarding Agent no es una inversión única. La misma arquitectura de plantillas de listas, reparto de tareas, control de plazos y lógica de escalado se reutiliza directamente por los agentes de traslados, offboarding y período de prueba. El marco de perfiles de permisos sienta las bases para la gestión de accesos en todas las fases del ciclo de vida.

Más importante aún: cada ejecución genera un registro de auditoría completo. Qué tarea se completó cuándo, quién escaló, dónde hubo retrasos. A partir de estos datos surge con el tiempo una imagen de dónde falla sistemáticamente el proceso - no basada en intuición, sino en 200 ejecuciones documentadas.

## Cuándo se rentabiliza el agente

La cuenta es sencilla. Con 100 incorporaciones al año y una tasa de rotación temprana del 30 por ciento, una empresa pierde 30 personas en el período de prueba. A 15.000 EUR (16.500 USD) por caso, son 450.000 EUR (495.000 USD). Si un onboarding estructurado mejora la retención en un 44 por ciento - una estimación conservadora basada en datos de SHRM - la rotación temprana se reduce a 17 casos. El ahorro: cerca de 200.000 EUR (220.000 USD) al año.

No incluido: la mayor productividad de las 83 personas que se quedan y son operativas antes. No incluido: el alivio para RRHH, que ya no coordina 100 procesos por cadena de correo. No incluido: el efecto reputacional cuando los nuevos empleados cuentan un onboarding profesional.

--- Agente Contabilidad Nóminas ---
> Asientos contables nóminas: PGC RD 1514/2007, NIIF 19/IAS 19 Employee Benefits, provisiones vacaciones y bonus - revisable Código de Comercio art. 25-49 con audit-trail ICAC NIA-ES.

La generación de los asientos contables desde la nómina en España se sitúa en el cruce de cinco marcos de cumplimiento con consecuencias muy distintas. El Código de Comercio (arts. 25-49) impone la obligación contable, el Libro Diario y la conservación de seis años. El Plan General de Contabilidad fija el grupo 64 de gastos de personal, con sus cuentas de sueldos, indemnizaciones, Seguridad Social a cargo de la empresa y aportaciones a planes de pensiones. La LGT regula las obligaciones contables, la prescripción y los modelos de IRPF. El TRLGSS gobierna las cotizaciones a través del Sistema RED de la TGSS. Y la IAS 19, junto a las normas de auditoría del ICAC, rige las provisiones a largo plazo. Esta constelación significa que un mismo asiento de nómina, en una empresa del IBEX-35 o de mediana dimensión de entre 500 y 5.000 empleados, puede activar a la vez hasta cinco obligaciones ante la AEAT, el ICAC, la ITSS, la TGSS y el auditor externo.

## De nominas a asientos contables - 80 por ciento automatico

El cálculo de la nómina funciona: lo hacen SAP SuccessFactors, Cegid Visma Meta4, A3 de Wolters Kluwer o Sage NominaPlus. Lo que no funciona es el camino desde el resultado de la nómina hasta el Libro Mayor del Plan General de Contabilidad. La contabilización en el grupo 64, la imputación a centros de coste, el cálculo de las provisiones de la IAS 19, la conciliación contra el Libro Mayor y el escalado de discrepancias forman el puente que en la mayoría de las empresas españolas se sostiene con asientos manuales, filas copiadas en Excel y el conocimiento tácito de dos o tres especialistas del Departamento Financiero. Una empresa de 1.500 empleados genera al mes varios centenares de líneas de asiento solo con la nómina: sueldos por centro de coste, Seguridad Social a cargo de la empresa, retenciones de IRPF, cuotas de los trabajadores, remuneraciones pendientes de pago y aportaciones a planes de pensiones. El agente automatiza el 80 por ciento del proceso con el mapeo determinista, la imputación de centros de coste, las provisiones y la conciliación automática, y se mantiene humano en un único punto: la aprobación final del lote por el Director Financiero, el Controller y el Jefe de Contabilidad, con segregación de funciones.

## La obligación contable del Código de Comercio (arts. 25-49)

El marco contable español parte del Código de Comercio: la obligación de llevar una contabilidad ordenada (art. 25), el Libro Diario y el de Inventarios y Cuentas Anuales (art. 26), la conservación de seis años (art. 30) y las Cuentas Anuales en sus modelos normal, abreviado y pyme (arts. 34-49). Todo asiento de nómina debe registrarse en el Libro Diario con su número, fecha, cuentas de debe y haber, centro de coste, concepto, importe y soporte documental, como el recibo de salarios o el modelo 111. La falsedad en las cuentas anuales lleva aparejada prisión de uno a tres años para los administradores (Código Penal art. 290), y la responsabilidad penal de la persona jurídica del art. 31 bis puede suponer la suspensión de actividades o la disolución. La sanción del ICAC alcanza los 6 millones de euros, y la auditoría externa es obligatoria en empresas medianas, grandes y cotizadas.

## La Ley General Tributaria y la conservación de seis años ante la AEAT

La LGT (Ley 58/2003) fija las obligaciones contables y registrales, una prescripción tributaria de cuatro años y la conservación de seis para las actuaciones inspectoras de la AEAT. Las retenciones de IRPF se declaran mediante el modelo 111 trimestral y el resumen anual 190, y se provisionan en la cuenta 4751. El tipo de retención depende del nivel salarial, la situación familiar, los mínimos personales y la Comunidad Autónoma. La Ley 27/2014 del Impuesto sobre Sociedades regula la amortización de los gastos de personal a través del modelo 200 y, en su caso, del 220 de grupos en consolidación. El incumplimiento expone a una sanción de entre el 25% y el 150% de la deuda y, cuando esta supera los 120.000 euros, a un procedimiento penal fiscal con prisión de uno a seis años.

## Las provisiones por retribuciones a los empleados (IAS 19) y el PGC

La IAS 19 sobre retribuciones a los empleados y las normas de registro y valoración del Plan General de Contabilidad distinguen entre retribuciones a corto plazo, como los sueldos, los bonus y las vacaciones, y a largo plazo, como los premios de antigüedad, los planes de pensiones, las indemnizaciones por extinción y las opciones sobre acciones. Las provisiones se calculan así: las vacaciones, por los días pendientes y el salario diario en la cuenta 465; las horas extras, por el saldo de control horario; los premios de antigüedad, por valoración actuarial de la obligación proyectada (PBO) con tasas de descuento de bonos corporativos AAA; las indemnizaciones, según el cálculo legal del ET (20 días por año en el despido objetivo, 33 en el improcedente); y los planes de pensiones de prestación definida, por el coste del servicio, los intereses y las pérdidas y ganancias actuariales en el OCI, con actuario certificado y verificación del auditor externo. En sectores regulados como la banca, la conservación se amplía de veinticinco a treinta años conforme a la supervisión del Banco de España.

## La cotización a la Seguridad Social a través del Sistema RED

El TRLGSS (arts. 18-30) establece la cotización de la empresa y del trabajador, con sus bases y topes, que se gestiona por el Sistema RED de la TGSS. Las cotizaciones empresariales comprenden las contingencias comunes (23,6%), los accidentes de trabajo con su tarifa específica, el desempleo (5,5% o 6,7%), la formación profesional (0,6%), el FOGASA (0,2%) y el Mecanismo de Equidad Intergeneracional (0,6%); las del trabajador, las contingencias comunes (4,7% o 5,5%) y el desempleo (1,55% o 1,6%). Todo ello se provisiona en la cuenta 4760. El retraso en el pago genera un recargo del 5%, el 10% o el 20% según los meses (LGSS art. 28), además de las sanciones de la ITSS, que en los casos muy graves llegan a 225.018 euros. La prescripción de las cotizaciones es de cuatro años.

## Enlace con los agentes de Cálculo y Reporte de Nómina

Tres agentes operan en el clúster de nómina. El de Cálculo obtiene el bruto y el neto a partir de la estructura salarial del ET, los convenios colectivos, el IRPF y las cotizaciones. Este agente, el de Contabilidad, genera los asientos desde el resultado de la nómina conforme al Código de Comercio, al grupo 64 del Plan General de Contabilidad y a las provisiones de la IAS 19, y los cuadra contra el Libro Mayor. El de Reporte produce los informes ESRS y la auditoría retributiva del RD 902/2020. El flujo es encadenado: el Cálculo alimenta a la Contabilidad y esta al Reporte. La conciliación automática genera una excepción ante cualquier diferencia, ya sea una nómina correctiva olvidada, un componente mal mapeado, un redondeo en las cotizaciones o unos atrasos de convenio.

## De un vistazo

- Mapea cada componente al grupo 64 del Plan General de Contabilidad, imputa centros de coste y provisiona según la IAS 19, sobre almacenamiento inalterable con seis años de conservación.
- Calcula la retención de IRPF (modelos 111 y 190) y prepara el modelo 200 del Impuesto sobre Sociedades; la AEAT puede sancionar entre el 25% y el 150% de la deuda y abrir un procedimiento penal fiscal.
- Liquida las cotizaciones por el Sistema RED de la TGSS, con recargos por demora del 5% al 20% y sanciones de la ITSS de hasta 225.018 euros.
- Calcula las provisiones de planes de pensiones de la IAS 19 con actuario certificado y verificación del auditor externo.
- Concilia la nómina contra el Libro Mayor llegando hasta el componente individual, y reduce el cierre mensual de entre 6 y 10 horas a menos de una, según los benchmarks de APQC.
- Aplica las tablas de los convenios colectivos, con sus atrasos y la prescripción anual del ET art. 59.
- Las sanciones de la AEAT, el ICAC (hasta 6 millones) y la ITSS son acumulables y se suman a la responsabilidad penal de la persona jurídica y a la civil ilimitada de los administradores.

## Distribucion de Decididores Payroll-Accounting

| Decisor | Numero decisiones | Porcentaje | Tipo |
|---------|-------------------|------------|------|
| R Determinista | 13 | 81 por ciento | Mapeo contable, centros de coste, provisiones IAS 19, IRPF, cotizaciones y pista de auditoría |
| A Indicador ML | 2 | 12 por ciento | Identificación de discrepancias y sincronización entre HCM, ERP y TGSS |
| H Confirmación humana | 1 | 7 por ciento | Aprobación final del lote de asientos con segregación de funciones |

El agente automatiza el 81 por ciento del proceso de forma determinista, con el cuadre contable, las provisiones actuariales y la conciliación automática, y se mantiene humano solo en la aprobación final del lote de asientos. Esa aprobación la firman el Director Financiero, el Controller y el Jefe de Contabilidad, con la segregación de funciones del control interno y el deber de llevar una contabilidad ordenada del art. 25 del Código de Comercio, bajo la verificación del auditor externo.

--- Agente Proceso RRHH Nóminas ---
> Proceso RRHH nóminas: Self-Service mantenimiento datos empleados, workflows aprobación multinivel y comité empresa ET art. 64 - pipeline auditable de personal sin cálculo Bruto-Neto.

El cálculo Bruto-Neto en España se sitúa en el cruce de cinco marcos normativos que actúan en paralelo: la estructura salarial del Estatuto de los Trabajadores, las retenciones de IRPF de la LIRPF, las cotizaciones del TRLGSS, las tablas de los convenios colectivos y la igualdad retributiva del RD 902/2020. La consecuencia práctica es que una sola nómina mensual, en una empresa cotizada o en una mediana o gran empresa de entre 500 y 5.000 empleados, puede activar a la vez obligaciones ante la Inspección de Trabajo, la AEAT, la Seguridad Social, el comité de empresa y el auditor externo.

## Bruto-Neto en segundos en lugar de Excel-marathon

El cálculo Bruto-Neto es el proceso más reglado de RRHH, pero en muchas empresas españolas sigue resolviéndose como una maratón de Excel de varios días. El Estatuto de los Trabajadores define la estructura salarial, la LIRPF regula las retenciones, el TRLGSS fija las cotizaciones (un 30,3% a cargo de la empresa y un 6,35% del trabajador) y los convenios colectivos establecen las tablas y los complementos. Ningún paso requiere interpretación. Y aun así el proceso se ejecuta a mano: los datos del registro horario llegan por exportación, los gastos de viaje en un asiento global, los pagos extraordinarios en una hoja de cálculo y los cambios de convenio por correo circular. Cada interfaz es una fuente de error. Una empresa con 1.500 empleados genera al mes cientos de cálculos individuales con docenas de variables. El agente automatiza la mayor parte de forma determinista y reserva al ser humano la aprobación final del ciclo, que firman el Director de RRHH y el Responsable de Nóminas con segregación de funciones.

## Estructura salarial y retención de IRPF

El Estatuto de los Trabajadores fija la estructura de la nómina: el concepto de salario y las percepciones extrasalariales (art. 26), el carácter indisponible del Salario Mínimo Interprofesional (art. 27), la igualdad retributiva por trabajo de igual valor (art. 28) y el pago mensual con recibo justificativo (art. 29). El recibo de salarios debe recoger la cabecera con empresa y trabajador, los devengos, las deducciones, las bases imponibles y el líquido a percibir.

La retención de IRPF sigue la escala estatal de 2026, que va del 19% para los primeros 12.450 euros hasta el 47% por encima de 300.000, a la que se suma la escala autonómica correspondiente. Se ingresa mediante el Modelo 111 trimestral y se resume en el Modelo 190 anual. La declaración fuera de plazo o incompleta abre expediente sancionador de la AEAT.

## Cotizaciones a la Seguridad Social y MEI

El TRLGSS fija las cotizaciones de empresa y trabajador, junto con sus bases y topes. En 2026 la cuota empresarial por contingencias comunes es del 23,6% y la del trabajador del 4,7%; a ambas se suman desempleo, FOGASA, formación profesional y el Mecanismo de Equidad Intergeneracional (un 0,5% para los años 2026-2032). El Sistema RED de la TGSS gestiona la afiliación, las altas y bajas y la presentación de las cotizaciones, con plazo hasta el último día del mes siguiente. El retraso genera un recargo de demora del 5%, el 10% o el 20% según el desfase, además de la posible sanción de la Inspección de Trabajo.

## Convenios colectivos, SMI e igualdad retributiva

Los convenios colectivos sectoriales y de empresa, registrados en REGCON, fijan las tablas salariales por categoría y grupo profesional, los complementos personales y de puesto, los pluses sectoriales y su actualización con el IPC. Los atrasos por revisión retroactiva prescriben al año (ET art. 59). Por debajo, el Salario Mínimo Interprofesional actúa como suelo indisponible.

A esa capa se añade la igualdad retributiva: el RD 902/2020 obliga a las empresas de más de 50 empleados a tener Plan de Igualdad y a repetir cada tres años la auditoría retributiva, con el umbral de brecha del 6% que activa la obligación de justificar y corregir. El incumplimiento es sancionable por la Inspección de Trabajo.

## Sistema RED y presentación telemática a la AEAT

La gestión electrónica de la nómina discurre por dos canales obligatorios. El Sistema RED de la TGSS gestiona la afiliación, las altas y bajas y las cotizaciones, con plazo hasta el último día del mes siguiente. La AEAT recibe el Modelo 111 trimestral y el Modelo 190 anual. La AEAT cruza el Modelo 111, el Modelo 190 y los datos del Sistema RED con la declaración del empleado; cualquier discrepancia activa una inspección. El agente automatiza esa verificación cruzada, identifica las discrepancias y deja constancia en un audit-trail cifrado, conservado entre cuatro y seis años.

## Relación con los agentes de Contabilidad y Reporting de Nóminas

En el clúster de nómina operan tres agentes con focos distintos pero complementarios. El Agente de Proceso de Nóminas (este) calcula el Bruto-Neto de forma determinista. El Agente de Contabilidad de Nóminas genera los asientos contables a partir de los resultados de la nómina. El Agente de Reporting de Nóminas elabora los informes regulatorios, desde el ESRS hasta el ESEF iXBRL, con verificación del auditor a partir de 250 empleados. El flujo es secuencial: el cálculo alimenta la contabilidad, y esta el reporting. Antes de cerrar el ciclo, la validación activa una excepción ante saltos del salario base, horas extraordinarias desproporcionadas, ausencia de registro horario, un cambio de retención sin justificación o atrasos pendientes del convenio.

## De un vistazo

- **Estructura salarial**: el ET art. 26-29 y el RD 1659/1998 definen el recibo, los complementos, las horas extraordinarias, la nocturnidad y la paga extra.
- **Retención de IRPF**: la escala de 2026 va del 19% al 47%; se declara en el Modelo 111 trimestral y el Modelo 190 anual ante la AEAT.
- **Cotización a la Seguridad Social**: un 30,3% a cargo de la empresa y un 6,35% del trabajador, con el MEI del 0,5%, a través del Sistema RED de la TGSS.
- **Convenios colectivos**: las tablas salariales y los complementos se actualizan con el IPC; los atrasos prescriben al año (ET art. 59).
- **Igualdad retributiva**: el RD 902/2020 exige Plan de Igualdad en empresas de más de 50 empleados y auditoría cada tres años, con umbral de brecha del 6%.
- **Registro horario**: obligatorio según el RD 8/2019, con conservación de cuatro años.
- **Sanciones**: la Inspección de Trabajo puede multar hasta 187.515 euros y la AEAT entre el 25% y el 150% de la deuda.

## Distribucion de Decididores Payroll-Processing

| Decisor | Numero decisiones | Porcentaje | Tipo |
|---------|-------------------|------------|------|
| R Determinista | 13 | 81 percent | Cálculo Bruto-Neto, retención de IRPF, cotización, complementos y recibo de salarios |
| A Indicador ML | 2 | 12 percent | Validación de plausibilidad y cuadre de datos entre RRHH, la TGSS y la AEAT |
| H Confirmacion humana | 1 | 7 percent | Aprobación final del ciclo de nómina por el Director de RRHH y el Responsable de Nóminas |

El agente automatiza el 81% del proceso de forma determinista. La intervención humana se reserva a la aprobación final del ciclo, que firman el Director de RRHH y el Responsable de Nóminas con segregación de funciones, conforme al ET art. 29 sobre el pago de salarios.

--- Agente Reporting RRHH ---
> Dashboards directivos RRHH: CSRD ESRS S1-9 diversidad, S1-10 equal-pay (ratio brecha 6%), S1-13 compensation y FTE - automático desde nómina sin tenis de Excel.

El reporting regulatorio de nómina en España se sitúa en el cruce de cinco marcos normativos que actúan en paralelo: los modelos de IRPF ante la AEAT, las cotizaciones del Sistema RED de la TGSS, la auditoría retributiva del RD 902/2020, las encuestas de coste laboral del INE y el reporting de sostenibilidad ESRS. La consecuencia práctica es que un solo ciclo de reporting, en una empresa cotizada o en una mediana o gran empresa de entre 500 y 5.000 empleados, puede activar a la vez obligaciones ante la AEAT, la Inspección de Trabajo, el ICAC, la CNMV, el INE y el auditor externo.

## De nominas a reporte - 90 por ciento automatico

El reporting regulatorio de nómina es un proceso muy reglado, pero en muchas empresas sigue resolviéndose como una maratón de Excel de varias semanas. La LIRPF regula los Modelos 111 y 190, el TRLGSS determina las cotizaciones del Sistema RED, el RD 902/2020 fija la auditoría retributiva cada tres años y la CSRD exige el reporting de sostenibilidad ESRS. Ningún paso requiere interpretación. Y aun así el proceso se ejecuta a mano: los datos consolidados llegan por exportación, las retenciones se cuadran en una hoja de cálculo, la brecha salarial se calcula con una fórmula manual y el ESRS se redacta en Word. El agente automatiza la mayor parte y reserva al ser humano la aprobación final y la presentación, que firman el CFO, el Director de RRHH y el Comité de Auditoría.

## Modelo 111, Modelo 190 y sede electrónica de la AEAT

La LIRPF establece el Modelo 111 trimestral y el Modelo 190 anual. El Modelo 111 se presenta dentro de los veinte días del mes siguiente al cierre del trimestre, con el desglose de las retribuciones dinerarias y de las que son en especie. El Modelo 190 es la declaración informativa anual: se presenta antes del 31 de enero, con el detalle por empleado y su clave de perceptor, y debe cuadrar con los cuatro Modelos 111 del año. A ellos se suman, según corresponda, el Modelo 110 para la gran empresa, el Modelo 145 de comunicación de datos del pagador y el Modelo 296 de retenciones a no residentes. Todo se presenta por la sede electrónica de la AEAT; la declaración fuera de plazo abre expediente sancionador.

## Sistema RED y cotizaciones a la Seguridad Social

El TRLGSS y el Sistema RED de la TGSS gestionan las cotizaciones de empresa y trabajador de 2026, con sus bases y topes. La cuota empresarial por contingencias comunes es del 23,6% y la del trabajador del 4,7%; a ambas se suman desempleo, FOGASA, formación profesional y el MEI del 0,5%. El sistema Cret@ recoge el desglose detallado de los conceptos retributivos abonados, y el Sistema RED gestiona la afiliación y las altas y bajas. El plazo de presentación es el último día del mes siguiente; el retraso genera un recargo de demora del 5%, el 10% o el 20%, además de la posible sanción de la Inspección de Trabajo.

## Auditoría retributiva del RD 902/2020 y estadística del INE

El RD 902/2020, junto con la Ley de Igualdad y la Directiva europea de transparencia retributiva, obliga a las empresas de más de 50 empleados a tener Plan de Igualdad y a repetir la auditoría retributiva cada tres años. La auditoría analiza los salarios por categoría, grupo profesional y sexo; cuando la brecha supera el umbral del 6%, se activa la obligación de justificarla y de adoptar medidas correctoras. El registro retributivo es obligatorio para todas las empresas, con independencia de su plantilla. En paralelo, el INE exige la comunicación estadística del coste laboral (encuestas anual, trimestral y cuatrienal) a las empresas de más de 500 empleados.

## Reporting de sostenibilidad ESRS y Estado de Información No Financiera

La CSRD y las normas europeas de sostenibilidad (ESRS) exigen reportar, dentro del ámbito de plantilla propia, la diversidad de la plantilla (S1-1), la igualdad retributiva con el umbral de brecha del 6% (S1-10) y los datos de compensación, incluido el ratio entre el CEO y la mediana (S1-13). El reporting se publica en formato ESEF iXBRL y requiere verificación del auditor a partir de 250 empleados. La aplicación es escalonada: las grandes empresas informan desde 2026 y las pymes cotizadas desde 2028. En paralelo, la Ley 11/2018 obliga a las empresas de más de 500 empleados al Estado de Información No Financiera, con el desglose de datos de plantilla por sexo, edad, clasificación profesional y remuneración media. En sociedades cotizadas se añade el voto consultivo de la junta sobre la retribución de administradores (Say-on-Pay).

## Relación con los agentes de Proceso y Contabilidad de Nóminas

En el clúster de nómina operan tres agentes con focos distintos pero complementarios. El Agente de Proceso de Nóminas calcula el Bruto-Neto de forma determinista. El Agente de Contabilidad de Nóminas genera los asientos contables a partir de los resultados de la nómina. El Agente de Reporting de Nóminas (este) elabora los informes regulatorios, los cuadros de mando y las declaraciones anuales, desde los modelos de la AEAT y el Sistema RED hasta la auditoría retributiva, las encuestas del INE y el reporting ESRS. El flujo es secuencial: el cálculo alimenta la contabilidad, y esta el reporting. Antes de presentar, la validación activa una excepción ante saltos del IRPF de un trimestre a otro, discrepancias con el Sistema RED, ausencia de datos para la brecha o un ratio por encima del 6% sin justificar.

## De un vistazo

- **Modelos de IRPF**: el Modelo 111 trimestral, el Modelo 190 anual y los modelos complementarios se presentan por la sede electrónica de la AEAT.
- **Cotizaciones**: un 30,3% a cargo de la empresa y un 6,35% del trabajador, con el MEI del 0,5%, por el Sistema RED de la TGSS.
- **Auditoría retributiva**: el RD 902/2020 la exige cada tres años, con registro retributivo obligatorio y umbral de brecha del 6%.
- **Estadística**: el INE exige las encuestas de coste laboral a las empresas de más de 500 empleados.
- **Reporting de sostenibilidad**: el ESRS reporta diversidad, igualdad retributiva y compensación, en formato ESEF iXBRL, con verificación del auditor a partir de 250 empleados.
- **Información no financiera**: la Ley 11/2018 obliga al Estado de Información No Financiera y, en cotizadas, al Say-on-Pay.
- **Sanciones**: la AEAT puede multar entre el 25% y el 150% de la deuda, la Inspección de Trabajo hasta 187.515 euros y el ICAC inhabilitar al auditor.

## Distribucion de Decididores Payroll-Reporting

| Decisor | Numero decisiones | Porcentaje | Tipo |
|---------|-------------------|------------|------|
| R Determinista | 14 | 82 percent | Modelos de IRPF, Sistema RED, auditoría retributiva, encuestas del INE, reporting ESRS y cuadros de mando |
| A Indicador ML | 2 | 12 percent | Validación de anomalías y cuadre de datos entre RRHH, la AEAT, la TGSS y la CNMV |
| H Confirmacion humana | 1 | 6 percent | Aprobación final y presentación telemática por el CFO, el Director de RRHH y el Comité de Auditoría |

--- People Analytics Agent ---
> Analiza riesgo de rotación, engagement, diversidad y movimiento de talento. Alto riesgo bajo el Reglamento de IA de la UE.

RRHH posee los datos que podrían sostener decisiones estratégicas sobre personal. Rotación por área, compromiso por centro, diversidad por nivel jerárquico. Y sin embargo, sólo el 8 por ciento de las empresas afirma que sus datos de RRHH son realmente utilizables (Deloitte, Human Capital Trends). El resto exporta tablas, construye presentaciones durante semanas y entrega respuestas que llegan tarde, se quedan en la superficie y no abordan la pregunta real.

El problema no es la falta de datos. Es la falta de arquitectura. Quien hace People Analytics sin separar estructuralmente análisis y vigilancia no obtiene ni aceptación del Comité de Empresa ni conformidad con el Reglamento europeo de IA.

## Por qué People Analytics se estanca en la práctica

El 76 por ciento de las empresas hace alguna forma de People Analytics. Pero sólo el 9 por ciento entiende qué dimensiones de talento impulsan realmente el rendimiento (Deloitte, 2024). Entre los datos que RRHH posee y los que acaban influyendo en decisiones estratégicas se abre una brecha. Tres causas la mantienen abierta.

**Base de datos fragmentada.** Los datos de personal viven en SAP o Personio, los valores de compromiso en una herramienta de encuestas, los motivos de rotación en hojas de Excel de los responsables. La integración de datos figura según encuestas de EY regularmente entre los mayores obstáculos de la digitalización de RRHH. El daño oculto: la mala calidad de datos fuerza trabajo de corrección, consume capacidad y falsea cualquier análisis que se construya encima - a menudo más grave que la ausencia de herramientas de análisis.

**Sin traducción al lenguaje de la decisión.** RRHH informa de plantilla, absentismo, días de formación. La Dirección piensa en facturación por empleado, time-to-market, rotación de clientes. Mientras la rotación no se enlace con sus costes económicos derivados, People Analytics seguirá siendo un informe administrativo. Best Buy cuantificó la conexión: 0,1 puntos más de compromiso se correlacionaban con 100.000 USD (90.000 EUR) de ingresos adicionales por tienda. La mayoría de los departamentos de RRHH no consigue establecer esa conexión - no porque falten datos, sino porque nadie ha definido qué enlaces son estratégicamente relevantes.

**Mezcla de análisis y vigilancia.** People Analytics debe detectar patrones en datos agregados. Pero sin límites técnicos claros, el análisis se desliza imperceptiblemente hacia el control del rendimiento individual. El Comité de Empresa bloquea. La plantilla desconfía. El proyecto no muere por la técnica, sino por la pérdida de confianza.

## Alto riesgo según el Reglamento de IA - la realidad regulatoria

El Reglamento europeo de IA clasifica los sistemas de People Analytics como de alto riesgo según el Anexo III, categoría 4(b): sistemas de IA para monitorización y evaluación del comportamiento en el lugar de trabajo. Aunque el agente analice exclusivamente de forma agregada, los resultados pueden influir en decisiones de personal. Eso basta para la clasificación, que se mantiene sin cambios.

Conforme a la legislación vigente, las obligaciones se aplican desde el 2 de agosto de 2026, con un aplazamiento a diciembre de 2027 acordado provisionalmente por el Digital Omnibus (mayo de 2026, adopción formal aún pendiente). Llegado ese plazo, los sistemas de alto riesgo deben cumplir los siguientes requisitos:

- Sistema de gestión de riesgos con evaluación de impacto documentada
- Requisitos de calidad de datos y documentación técnica
- Transparencia frente a las personas trabajadoras afectadas
- Supervisión humana por personal técnicamente competente
- Marcado CE y registro en la base de datos de la UE

En paralelo entra en juego el derecho español. El artículo 64 del Estatuto de los Trabajadores otorga al Comité de Empresa derecho a ser informado y consultado sobre sistemas que influyen en las condiciones de trabajo y monitorizan el comportamiento. El Comité no tiene derecho de veto, pero sí derecho a ser consultado con antelación suficiente. Los tribunales sociales han dejado claro que la intención subjetiva del empresario es irrelevante: decisiva es la idoneidad objetiva del sistema. Una herramienta de People Analytics lo es por definición.

El artículo 35 del RGPD exige una evaluación de impacto cuando un tratamiento entraña previsiblemente un alto riesgo para los derechos de las personas físicas. El análisis sistemático de datos de empleados cumple ese criterio. Y la AESIA, como autoridad española de supervisión de IA, puede emitir directrices adicionales sobre analítica predictiva en el ámbito laboral.

Quien no integra estos tres marcos jurídicos construye un sistema técnicamente funcional y legalmente insostenible.

## Lo que la arquitectura resuelve y la tecnología sola no puede

La pregunta central no es: ¿qué herramienta analiza los datos? Sino: ¿quién define la pregunta, quién interpreta el resultado, quién decide?

El [Decision Layer](/es/decision-layer/) descompone el proceso analítico en pasos de decisión discretos. Cada paso tiene un responsable definido: humano, motor de reglas o agente de IA.

```
Definir             Verificación       Agregar            Identificar
pregunta       -->  RGPD          -->  datos          --> patrones
(humano)            (reglas)           (reglas)           (agente)

Validar             Recomendación      Presentar
hallazgos      -->  de acción     -->  resultados
(humano)            (agente)           (agente)
```

La separación no es formal. Resuelve el problema de fondo por el que People Analytics fracasa en la práctica.

**Paso 1: definir la pregunta (humano).** Analítica sin pregunta estratégica produce informes que nadie ha pedido. El proceso empieza sólo cuando Dirección de RRHH o Dirección General prepara una decisión concreta: ¿necesitamos un programa de retención en comercial? ¿Se está abriendo la brecha de compromiso entre centros?

**Paso 2: verificación RGPD (motor de reglas).** Antes de agregar un solo dato, el motor coteja el análisis previsto contra el RGPD, los acuerdos con el Comité de Empresa y las políticas internas. Los análisis sin base jurídica no se lanzan.

**Paso 3: agregar datos (motor de reglas).** Datos maestros, puntuaciones de compromiso y datos de rotación se consolidan y anonimizan. Los grupos por debajo del tamaño mínimo definido se agrupan. No es una directriz, es un bloqueo técnico: las conclusiones personales no son posibles porque la arquitectura lo impide.

**Paso 4: identificar patrones (agente).** El agente reconoce correlaciones, tendencias y valores atípicos en los datos agregados. ¿Dónde crece la rotación más rápido que la media? ¿Qué áreas muestran compromiso descendente y simultáneamente horas extras crecientes? Los modelos predictivos identifican áreas en riesgo entre 60 y 90 días antes de que se produzcan las salidas.

**Paso 5: validar hallazgos (humano).** Un patrón estadístico no es una causa. ¿Se correlaciona la caída de satisfacción en el área X con la reestructuración del último trimestre - o con el cambio de responsable? El especialista en HR Analytics valida significancia, plausibilidad y contexto. El agente aporta evidencia. La interpretación la hace un humano con conocimiento de dominio.

**Pasos 6 y 7: recomendación y presentación (agente).** El agente formula recomendaciones basadas en evidencia con indicación de confianza y las prepara en formato apto para dirección. No 40 indicadores en un panel, sino entre tres y cinco hallazgos ligados a impacto de negocio y opciones concretas de acción.

## La frontera entre análisis y vigilancia es una decisión arquitectónica

Ningún problema de confianza se resuelve con un mejor panel. La aceptación de People Analytics depende de si la frontera entre detección de patrones en datos agregados y evaluación de personas individuales se promete o, además, se impone técnicamente.

Tres principios arquitectónicos lo garantizan:

**La agregación como bloqueo técnico.** Los tamaños mínimos de grupo no se definen como política, sino como parámetro del sistema. Un análisis con una base demasiado pequeña no entrega resultado - no un aviso, sino ninguna salida.

**Sin re-identificación de individuos.** La lógica de anonimización impide que la combinación de varias consultas agregadas permita identificar a una persona concreta. Es matemáticamente resoluble y técnicamente implementable - pero sólo si se ancla en la arquitectura desde el principio.

**Expediente de decisión completo.** Cada análisis se documenta: pregunta, base jurídica, nivel de agregación, resultado, medida derivada. El Comité de Empresa tiene derecho de acceso. Las personas afectadas pueden rastrear qué análisis se han ejecutado y qué decisiones se basan en ellos.

Este marco es, al mismo tiempo, el acuerdo con el Comité de Empresa. Quien documenta limpiamente la arquitectura tiene el resultado de la consulta ya estructurado. Límites claros aumentan la aceptación y reducen el riesgo de gobernanza - no es un compromiso, es una ventaja estratégica.

## Infraestructura que trasciende al agente individual

El motor de análisis que aquí surge - rotación, compromiso, equidad - se reutiliza por el Strategic HR Analytics Agent para reporting al Consejo y por el Merit Cycle Governance Agent para análisis de equidad retributiva. La lógica de anonimización y de tamaños mínimos de grupo se convierte en estándar para cualquier agente que procese datos personales. El marco de gobernanza - qué análisis se permiten, cuáles no, en qué condiciones - sienta las bases para todos los agentes de alto riesgo del cuadrante H4.

El valor real no reside en los resultados analíticos de un trimestre concreto. Reside en la infraestructura que convierte People Analytics de un riesgo de gobernanza en una herramienta de gobernanza: trazable, recurrible, reproducible. Las organizaciones que alcanzan este nivel de madurez toman decisiones basadas en datos más rápido y tienen, según Deloitte Human Capital Trends, una probabilidad mediblemente mayor de obtener resultados por encima de la media en comparación competitiva.

--- Performance Review Documentation Agent ---
> Gestiona documentación de evaluación del desempeño con pista de auditoría completa. Alto riesgo bajo el Reglamento de IA de la UE.

## La evaluación rara vez es el problema. La documentación sí lo es.

Este agente sigue el principio del [Decision Layer](/es/decision-layer/): cada decisión está basada en reglas, asistida por IA o asignada explícitamente a una persona.

Los responsables saben valorar el rendimiento. Lo que no saben: convertir un año de observaciones en un expediente consistente, justificable y legalmente sólido. La consecuencia es un proceso de documentación que produce contradicciones sistemáticas - entre la puntuación y la justificación, entre la autoevaluación y la percepción ajena, entre lo que se dijo en la conversación y lo que figura en el expediente.

No es un problema de calidad de algunos responsables. Es un problema estructural. Y se convierte en riesgo jurídico en cuanto un despido, una promoción denegada o un procedimiento ante los juzgados de lo social acceden precisamente a ese expediente.

## Tres patrones que permanecen invisibles en el proceso manual

**Divergencia entre puntuación y texto.** Un responsable otorga "supera expectativas", pero escribe en la justificación tres párrafos sobre áreas de mejora. O al revés: "cumple parcialmente" con una justificación que sólo enumera fortalezas. La investigación muestra que más del 60 por ciento de la varianza en evaluaciones de rendimiento procede del evaluador, no de la persona evaluada. En casos aislados, la discrepancia salta a la vista. Sobre 200, 500 o 1.000 evaluaciones por ciclo, nadie la detecta, porque nadie lee todos los documentos.

**El sesgo de recencia como brecha de documentación.** El sesgo de recencia es el error de evaluación más frecuente en empresas. Los responsables que no toman notas continuas - y la gran mayoría no las toma - reconstruyen doce meses de rendimiento a partir de las últimas seis semanas. El proyecto que fue extraordinario en febrero deja de existir en diciembre. El error de noviembre domina toda la evaluación. La documentación no refleja el rendimiento. Refleja la memoria.

**Sesgo de evaluación que desaparece en el dato individual.** Cuando un responsable evalúa a cuatro mujeres del equipo como "cumple expectativas" y a cuatro hombres como "supera expectativas", tomado aisladamente parece inofensivo. Quizá sea incluso cierto en el caso individual. Pero si ese patrón se reproduce en 30 equipos, ya no es casualidad. La investigación de Harvard Business Review demuestra que el 61 por ciento de las mujeres recibe feedback sobre su estilo de comunicación - en hombres, el valor está en torno al uno por ciento. Estos patrones no son detectables manualmente, porque sólo emergen en la agregación.

## Por qué formularios mejores no resuelven el problema

El reflejo inmediato: plantillas más estructuradas, campos obligatorios, bloques de texto preformulados. Pero un formulario no puede comprobar si la justificación encaja con la puntuación. No puede detectar si la autoevaluación de un empleado se desvía sistemáticamente de la valoración externa. No puede constatar si un responsable copia las mismas formulaciones desde hace tres ciclos. Y no puede analizar, sobre 40 equipos, si los patrones de evaluación se distinguen por sexo, edad o condición de tiempo parcial.

La tarea no consiste en mejorar el formulario. Consiste en descomponer el proceso de evaluación de modo que cada paso tenga una asignación clara: ¿quién decide? ¿con qué regla? ¿con qué comprobación?

## Once pasos, tres principios de decisión

```
Iniciar            Distribuir         Auto-              Responsable
ciclo         -->  formularios   -->  evaluación    -->  evalúa
(R: calendario)    (R: asignación)    (R: reglas)        (H: observación)

Comprobación       Apoyar             Análisis           Escalar
de coherencia -->  calibración   -->  de sesgos     -->  hallazgo
(A: texto/nota)    (A: distribución)  (A: estadística)   (R: umbral)

Planificar         Documentar         Activar
conversación -->  resultado      -->  seguimiento
(A: agenda)        (R: archivo)       (R: basado en reglas)
```

La diferencia decisiva con el proceso manual: los pasos 5, 6 y 7 se ejecutan en paralelo a la evaluación, no después. Cuando un responsable otorga una puntuación y escribe la justificación, se comprueba al instante si ambas encajan. La vista de calibración se actualiza en tiempo real. El análisis de sesgos calcula continuamente si se forman patrones.

Esto cambia el carácter de la ronda de calibración. En lugar de comparar puntuaciones a posteriori, los responsables ven al introducir los datos dónde se sitúa su valoración en contexto: distribución del equipo, desviación respecto a la media del departamento, coherencia con ciclos anteriores. La conversación se desplaza de "¿votamos sobre las notas?" a "¿dónde nos desviamos conscientemente del patrón y por qué?"

## La comprobación de coherencia como ventaja estructural

La comprobación automática de si la puntuación y la justificación textual encajan no es una función accesoria. Es la razón principal por la que una orquestación basada en reglas supera al proceso manual. Una persona que lee 400 formularios de evaluación no puede detectar sistemáticamente dónde se separan palabra y número. El agente detecta la contradicción al instante y la marca - no en un informe que aterriza en la mesa semanas después, sino mientras el responsable todavía está en el proceso de evaluación y puede corregir.

Para las empresas sujetas al régimen de alto riesgo del Reglamento europeo de IA - exigible para sistemas que evalúan rendimiento y comportamiento en el lugar de trabajo desde agosto de 2026 según la legislación vigente, con un aplazamiento a diciembre de 2027 acordado provisionalmente por el Digital Omnibus (mayo de 2026, adopción formal pendiente) - la trazabilidad no es opcional. Es un requisito legal. El Anexo III(4)(b) exige sistema de gestión de riesgos, transparencia frente a las personas afectadas y supervisión humana. Estos requisitos no se añaden a posteriori. Están anclados en la arquitectura: la evaluación permanece en manos humanas. El agente documenta, comprueba y analiza.

El Comité de Empresa tiene derecho a ser informado y consultado sobre la introducción de sistemas de evaluación del rendimiento según el artículo 64 del Estatuto de los Trabajadores. No tiene derecho de veto, pero debe ser consultado con antelación suficiente. Documentar la arquitectura limpiamente es, al mismo tiempo, la base de esa consulta.

## Lo que queda al final

El agente no realiza ni una sola evaluación de rendimiento. Asegura que cada evaluación esté justificada de forma coherente, documentada de forma completa y comprobada frente a patrones sistemáticos. La puntuación la otorga el responsable. La conversación la lleva un humano. La calibración la asume Dirección de RRHH.

La infraestructura que surge en el proceso - motor de coherencia, análisis de sesgos, marco de calibración, archivo a prueba de auditoría - no se construye para un único ciclo de evaluación. El análisis de sesgos se reutiliza por el Merit Cycle Governance Agent y el Promotion Process Agent. El patrón de comprobación de coherencia se convierte en estándar para todos los agentes que comprueban evaluaciones humanas sobre su coherencia. El expediente de decisión que surge por cada evaluación hace que cada valoración individual sea trazable y recurrible - para la persona afectada y para el Comité de Empresa.

--- Agente Políticas Documentales RRHH ---
> Ciclo vida políticas RRHH: ET art. 17/28/64 información comité, RD 902/2020 transparencia retributiva, Ley 2/2023 denunciantes y Convenios Colectivos REGCON - versionado con audit-trail.

La gestión del ciclo de vida de las políticas de RRHH en España se sitúa en el cruce de cinco marcos normativos que actúan en paralelo, con consecuencias muy distintas: los derechos de información del comité de empresa del Estatuto de los Trabajadores, la igualdad de la Ley 3/2007 y el RD 902/2020, la protección de datos del RGPD, el canal de denuncias de la Ley 2/2023 y el contenido obligatorio de los convenios colectivos. La consecuencia práctica es que una sola política, en una empresa cotizada o en una mediana o gran empresa de entre 500 y 5.000 empleados, puede activar a la vez varias de esas obligaciones.

## De 60 versiones en PDF a una única fuente de verdad central

Una empresa española de 1.500 empleados mantiene normalmente entre 40 y 80 políticas internas activas: desde el Plan de Igualdad y la política retributiva, obligatorios, hasta las de acoso, teletrabajo, desconexión digital, canal de denuncias, accesibilidad, seguridad o gastos. Cada una debe estar actualizada, ser localizable y comprensible, y haberse acusado recibo de forma demostrable. La realidad suele ser otra: un SharePoint con doscientos ficheros donde cuarenta se llaman "final_v3_NUEVO" sin sistemática de versionado, un correo de noviembre titulado "política retributiva actualizada" que nadie ha abierto, y un acuerdo de teletrabajo atascado en revisión entre el Servicio Jurídico, el comité de empresa y la dirección. El incumplimiento es sancionable por la Inspección de Trabajo, la AEPD y la Autoridad Independiente de Protección al Informante, y en una empresa mediana o grande la acumulación puede superar los cinco millones de euros.

## Verificación de conformidad con el ET, la Ley de Igualdad y el RD 902/2020

El agente verifica que cada política cumple la normativa superior antes de publicarla: la no discriminación del ET art. 17, la igualdad retributiva del ET art. 28, el Plan de Igualdad de la Ley 3/2007 en empresas de más de 50 empleados y la transparencia retributiva del RD 902/2020. La verificación detecta las cláusulas que entran en conflicto con esa normativa - una política retributiva sin la transparencia obligatoria, una de selección con criterios discriminatorios o una de teletrabajo sin compensación de gastos - . Cuando aparece un conflicto, se bloquea el flujo de aprobación y se escala al Servicio Jurídico y a Compliance con una propuesta de reformulación. El incumplimiento en materia de igualdad es sancionable por la Inspección de Trabajo con hasta 187.515 euros.

## Consulta al comité de empresa y reconciliación con el convenio

El agente integra el flujo de consulta previa al comité de empresa que el ET art. 64 exige para las políticas que afectan a las condiciones de trabajo: los planes de igualdad, las de no discriminación y de seguridad, los procedimientos disciplinarios, el teletrabajo y la política retributiva. La consulta sigue siempre el mismo recorrido: borrador con su impacto y sus razones, entrega al comité y al delegado sindical quince días antes, reunión con acta firmada, recogida de observaciones, decisión de la empresa y, por último, implantación con acuse de recibo. En paralelo, el agente reconcilia la política con el convenio aplicable cláusula por cláusula: una política de empresa puede mejorar el convenio, pero nunca empeorarlo (principio de mejorabilidad, ET art. 82.3), y en caso de duda prevalece la condición más favorable al trabajador. Una política que empeora el convenio es nula de pleno derecho, y la jurisprudencia anula las que se implantan sin la consulta obligatoria.

## Protección de datos, desconexión digital y canal de denuncias

El agente incorpora las obligaciones de protección de datos de los empleados (RGPD art. 88 y LOPDGDD), la política de desconexión digital y el canal de denuncias de la Ley 2/2023, obligatorio en empresas de más de 50 empleados. La política de desconexión digital debe recoger el derecho a desconectar fuera del horario, el protocolo de uso de las herramientas de comunicación y la formación en su uso responsable, formalizada con la representación legal de los trabajadores. El canal de denuncias exige un Sistema Interno de Información con responsable, un plazo de siete días para el acuse y tres meses para resolver, la inversión de la carga de la prueba en caso de represalia, la protección durante dos años y la confidencialidad durante cinco. El incumplimiento es sancionable por la AEPD y por la Autoridad Independiente de Protección al Informante.

## Versionado y conservación de las políticas

El agente gestiona el ciclo de vida con numeración semántica: el dígito mayor para los cambios sustanciales que exigen consulta al comité, el menor para las mejoras y el de parche para las correcciones, junto con las fechas de vigencia y el archivado inalterable de las versiones obsoletas. La conservación es automática y se ajusta al plazo legal de cada materia: seis años para las políticas retributivas y contables, cinco para las generales y para el canal de denuncias, hasta cincuenta para las de pensiones. El acuse de recibo se firma con firma electrónica cualificada conforme a eIDAS, con el mismo valor probatorio que la manuscrita, sello de tiempo y audit-trail. Sin acuse de recibo, una política es inútil en juicio por bien redactada que esté: así lo recuerda la jurisprudencia de forma reiterada.

## Relación con la Gestión Documental y la Auditoría de Compliance

El agente actúa como única fuente de verdad de las políticas vigentes, a la que recurren otros agentes del Decision Layer: el de Gestión Documental archiva los expedientes sobre la base de esas políticas; el de Formación en Compliance forma a los empleados en las versiones en vigor; el de Monitorización de Compliance comprueba el cumplimiento operativo (la política retributiva frente a las nóminas, el teletrabajo frente a los registros horarios, las dietas frente a los gastos reales); el de Relaciones Laborales las aplica en los casos disciplinarios. Sin esa fuente única, cada agente posterior trabajaría con información desactualizada. La integración con las plataformas españolas de RRHH y de firma se realiza por API.

## De un vistazo

- 16 microdecisiones en el ciclo de vida de las políticas: 13 deterministas, 2 indicadores asistidos por IA y 1 confirmación humana.
- Verificación de conformidad con el ET, la Ley de Igualdad, el RD 902/2020 y el RGPD antes de publicar.
- Consulta previa obligatoria al comité de empresa según el ET art. 64, con quince días de antelación y acta firmada.
- Reconciliación automática con el convenio aplicable bajo el principio de mejorabilidad (ET art. 82.3).
- Versionado con numeración semántica, archivado inalterable y conservación de entre 4 y 50 años según la materia.
- Acuse de recibo con firma electrónica cualificada, recordatorios escalonados y conservación de cinco años (LRJS art. 96).
- Canal de denuncias de la Ley 2/2023, obligatorio en empresas de más de 50 empleados, con cinco años de confidencialidad.
- Reporting de sostenibilidad ESRS y Estado de Información No Financiera integrados.
- Sanciones: la Inspección de Trabajo puede multar hasta 187.515 euros y la AEPD hasta el 4% de la facturación mundial.

| Distribucion de Decididores Policy-Document |
|----------|
| 13 deterministas: clasificación, conformidad, reconciliación con el convenio, flujo de aprobación, consulta al comité, versionado, publicación, acuse de recibo, consultas, canal de denuncias, reporting de sostenibilidad, notificación y actualización |
| 2 indicadores asistidos por IA: detección de conflictos entre políticas y monitorización de los cambios normativos |
| 1 confirmación humana: escalado de las políticas de alta dirección al Comité de Auditoría (Say-on-Pay) |

--- Agente Due Diligence Pre-Contratación ---
> Verificación pre-contratación: antecedentes penales LO 1/1996 + LO 26/2015 trabajos con menores, visa NIE/TIE Ley 4/2000 y AML Ley 10/2010 KYC - background-check con RGPD art. 22 y EU AI Act.

La verificación previa a la contratación en España se sitúa en el cruce de seis marcos normativos que actúan en paralelo: la no discriminación del Estatuto de los Trabajadores con la inversión de la carga de la prueba, la protección de datos del RGPD, la clasificación de alto riesgo del Reglamento de IA, la obligación de antecedentes penales para trabajos con menores, la Ley de Extranjería en los permisos de trabajo y la Ley 10/2010 contra el blanqueo de capitales. La consecuencia práctica es que una sola verificación, en una empresa cotizada o en una mediana o gran empresa de entre 500 y 5.000 empleados, puede activar a la vez varias de esas obligaciones.

## El background-check, entre la obligación de comprobar y la trampa de discriminar

La verificación previa a la contratación en España está atrapada entre dos polos. De un lado, la obligación de comprobar: los antecedentes penales para trabajos con menores, la diligencia antiblanqueo en los sectores obligados y la diligencia debida de los administradores. Del otro, la trampa de discriminar: la no discriminación del ET art. 17, el delito de discriminación grave y la inversión de la carga de la prueba (LRJS art. 96). La única salida sostenible es un procedimiento determinista: cada comprobación con su base jurídica explícita, cada decisión del algoritmo con su auditoría de sesgos, todo con audit-trail y una vía de impugnación para el candidato. El precedente Mobley contra Workday extiende la responsabilidad al proveedor del algoritmo.

## Alto riesgo según el Reglamento de IA: evaluación de impacto y de derechos

El Reglamento Europeo de IA clasifica como de alto riesgo los sistemas de selección de personal y de verificación de antecedentes. Como el agente evalúa a los candidatos mediante el cribado, el scoring, las referencias y los títulos, quedan activadas las obligaciones de gestión de riesgos, transparencia, supervisión humana y auditoría de sesgos, con registro ante la AESIA. Es además obligatoria la evaluación de impacto en protección de datos, por el tratamiento sistemático y las categorías especiales de datos. La auditoría de sesgos mide la paridad estadística por sexo, edad, origen y discapacidad, y cobra relevancia porque la carga de la prueba recae en la empresa. El incumplimiento puede sancionarse con hasta el 7% de la facturación mundial.

## No discriminación e igualdad en el proceso

El procedimiento cumple la no discriminación del ET art. 17 y las obligaciones de igualdad de la Ley 3/2007, que exige Plan de Igualdad en las empresas de más de 50 empleados. La auditoría de sesgos del algoritmo comprueba la paridad por sexo, que no se amplifiquen antecedentes muy antiguos para penalizar a los candidatos de más edad, la igualdad de oportunidades en discapacidad y la calibración por origen. La carga de la prueba recae en la empresa (LRJS art. 96); el incumplimiento en materia de igualdad es sancionable por la Inspección de Trabajo con hasta 187.515 euros, y la discriminación grave puede ser delito.

## Antecedentes penales para trabajos con menores

La LO 1/1996 y la LO 26/2015 obligan a presentar el certificado del Registro Central de Delincuentes Sexuales en las profesiones con contacto habitual con menores: educación, sanidad, animación infantil, servicios sociales, deportes, ocio y transporte escolar. El incumplimiento está tipificado en el Código Penal. Para los candidatos de la UE, el intercambio de información penal se hace por el sistema ECRIS. La verificación se realiza a través de un proveedor de background-check o directamente ante el Ministerio de Justicia, siempre con el consentimiento explícito del candidato; sin la base jurídica del art. 10 del RGPD, la AEPD puede sancionar con hasta el 4% de la facturación.

## Extranjería: permiso de trabajo, NIE y TIE

La Ley de Extranjería y su reglamento exigen verificar la habilitación del candidato extranjero: el visado de entrada, el permiso de trabajo (incluida la Tarjeta Azul de la UE para perfiles altamente cualificados), el NIE para cualquier actividad económica y la TIE para residencias de más de seis meses. Contratar sin permiso es una infracción grave, sancionable con hasta 10.000 euros. Como se trata el dato de origen, se aplica una base jurídica reforzada, cifrado y el derecho de acceso del candidato.

## Relación con los agentes de Cribado, Agenda de Entrevistas y Oferta

El agente opera dentro de un proceso secuencial de selección. El Agente de Cribado de Candidatos ejecuta el primer filtro con scoring del CV y auditoría de sesgos, antes de la entrevista. El Agente de Agenda de Entrevistas coordina la logística y vela por evitar las preguntas prohibidas. El Agente de Diligencia Previa a la Contratación (este) ejecuta la verificación final - referencias, títulos, antecedentes, permiso de trabajo y diligencia antiblanqueo - , el último paso antes del contrato, y entrega el resultado a los agentes de Oferta y de Onboarding.

## De un vistazo

- 17 microdecisiones con cita legal y audit-trail: 14 deterministas, 2 indicadores asistidos por IA y 1 confirmación humana.
- Verificación de antecedentes penales para trabajos con menores (LO 1/1996 y LO 26/2015), con intercambio ECRIS en la UE.
- Diligencia antiblanqueo de la Ley 10/2010 en los sectores obligados, con sanción de hasta 10 millones de euros.
- Verificación del permiso de trabajo y del NIE/TIE; contratar sin permiso es infracción grave (hasta 10.000 euros).
- Evaluación de impacto y auditoría de sesgos del Reglamento de IA, bajo la AESIA, con el precedente Mobley contra Workday.
- Ajustes razonables y accesibilidad WCAG 2.1 AA, con la cuota del 2% de trabajadores con discapacidad.
- Sanciones: AEPD hasta el 4% de la facturación, AESIA hasta el 7%, Inspección de Trabajo hasta 187.515 euros y antiblanqueo hasta 10 millones.

### Distribucion de Decididores Pre-Hire-Due-Diligence

| Etapa | Decisor | Tipo | Base legal | Impugnación |
|---|---|---|---|---|
| Base jurídica del tratamiento | R | Determinista | RGPD | Candidato |
| Evaluación de impacto y auditoría de sesgos | R | Determinista | RGPD y Reglamento de IA | Auditor |
| Antecedentes penales para trabajos con menores | R | Determinista | LO 1/1996 | Candidato |
| Permiso de trabajo y NIE/TIE | R | Determinista | Ley de Extranjería | Candidato |
| Validación de títulos académicos | R | Determinista | RD 967/2014 | Candidato |
| Referencias y Vida Laboral | R | Determinista | RGPD art. 6.1.a | Candidato |
| Diligencia antiblanqueo en sectores obligados | R | Determinista | Ley 10/2010 | Auditor |
| Auditoría de sesgos del algoritmo | R | Determinista | Reglamento de IA y LRJS art. 96 | Auditor |
| Ajustes razonables por discapacidad | R | Determinista | Ley General de Discapacidad | Candidato |
| Firma cualificada del consentimiento | R | Determinista | eIDAS | Candidato |
| Canal de denuncias accesible al candidato | R | Determinista | Ley 2/2023 | Candidato |
| Derecho de acceso del candidato rechazado | R | Determinista | RGPD art. 15 | Candidato |
| Cuadre de datos entre sistemas | A | Indicador ML | RGPD art. 30 | Proveedor |
| Notificación de brecha de seguridad | A | Indicador ML | RGPD art. 33 | Auditor |
| Escalado de casos de alta dirección | H | Confirmación humana | LSC | CHRO y Comité |

## Sanciones acumulables de varias autoridades

Las sanciones se acumulan y proceden de autoridades distintas: la AEPD puede multar con hasta el 4% de la facturación mundial, la AESIA con hasta el 7%, la Inspección de Trabajo con hasta 187.515 euros, la Autoridad Independiente de Protección al Informante con hasta un millón y la normativa antiblanqueo con hasta 10 millones. A ello se suma la posible responsabilidad penal de la persona jurídica y la civil de los administradores. En una empresa mediana o grande con incumplimientos recurrentes, la acumulación puede superar los 10 millones de euros.

## Casos especiales: empleo público, candidatos transfronterizos y selección de directivos

El procedimiento contempla casos especiales. En el empleo público rigen el acceso por mérito y capacidad del EBEP y la cuota del 7% de discapacidad. Para los trabajadores desplazados se aplica la Directiva europea correspondiente y el certificado A1. En la selección de directivos, la responsabilidad y la diligencia debida de los administradores hacen que intervenga una firma de executive search. Los datos especiales y de condenas se tratan siempre con cifrado, evaluación de impacto y consulta al Delegado de Protección de Datos. El precedente Mobley contra Workday puede extenderse a cualquier proveedor de cribado cuya auditoría de sesgos sea insuficiente.

## Integración con el ecosistema español de RRHH y selección

El agente se integra por API con el ecosistema español de RRHH y selección: las suites de nómina y recruiting más extendidas en el mercado (A3 de Wolters Kluwer, Sage, Cegid, Bizneo, Holded, Factorial), las plataformas enterprise (SAP SuccessFactors, Workday, Oracle, Personio), los proveedores especializados de background-check, las firmas de executive search para los perfiles directivos, los sistemas de seguimiento de candidaturas, las plataformas de firma electrónica cualificada y las herramientas de privacidad y compliance. Esa conectividad le permite operar como capa de verificación sobre los sistemas que la empresa ya utiliza.

--- Agente Gestión Periodo Prueba ---
> Ciclo vida periodo de prueba: ET art. 14 plazos (6 meses técnicos + 2 meses resto), hitos 30/60/90/150 días, RD 902/2020 transparencia y LRJS art. 96 reverse burden of proof - audit-trail completo.

La gestión del periodo de prueba en España se sitúa en el cruce de cinco marcos normativos que actúan en paralelo: los plazos del ET art. 14, la no discriminación del ET art. 17 y la igualdad de la Ley 3/2007, la protección de datos del RGPD, la inversión de la carga de la prueba (LRJS art. 96) y los derechos de información del comité de empresa sobre los desistimientos colectivos. La consecuencia práctica es que un solo desistimiento, en una empresa cotizada o en una mediana o gran empresa de entre 500 y 5.000 empleados, puede activar a la vez varias de esas obligaciones.

## Monitoreo plazos periodo de prueba como obligacion compliance

Una empresa española de 1.500 empleados, con una tasa anual de nuevas incorporaciones del 8%, mantiene en cualquier momento unos trece periodos de prueba activos y más de 150 plazos individuales al año, entre citas de feedback y puntos de decisión. La realidad suele ser otra: hojas de cálculo con fechas relativas, recordatorios de agenda olvidados, un responsable que no recuerda el hito de los 90 días y una dirección de RRHH que pregunta el día 178 si tal persona continúa. El problema de fondo es una asimetría de información: RRHH conoce los plazos pero no el desempeño, el responsable conoce el desempeño pero olvida los plazos, y entre ambos hay un déficit de comunicación que solo se manifiesta cuando ya es tarde. El incumplimiento es sancionable por la Inspección de Trabajo, la AEPD y la Autoridad Independiente de Protección al Informante, y en una empresa mediana o grande con desistimientos sistemáticos sin verificación ni acuse de recibo la acumulación puede superar los cinco millones de euros.

## Plazos del periodo de prueba y decisión final

El agente calcula la fecha de fin del periodo de prueba según el ET art. 14: seis meses para los técnicos titulados y dos meses para el resto en empresas de más de 25 empleados, con el límite que pueda fijar el convenio sectorial. La verificación es automática: el tipo de contrato, la categoría profesional, el convenio aplicable y la fecha de alta en la Seguridad Social. Tiene en cuenta que la incapacidad temporal no interrumpe el plazo salvo pacto, que la maternidad o la paternidad tampoco lo hacen, y que es nulo el pacto sobre las mismas funciones de un contrato anterior. A partir de ahí programa los hitos - cuatro en los seis meses, dos en los dos - con recordatorios escalonados y un escalado masivo a 30 días del fin. El momento decisivo (día 150 en los seis meses, día 45 en los dos) es aritmético: quedan 30 días, hay que respetar el preaviso del convenio y, si procede, la consulta al comité de empresa exige quince días con acta firmada, así que no hay margen de retraso. La decisión final - continuidad, prórroga dentro de los límites legales o desistimiento del ET art. 49.1.c sin causa - es siempre humana: la toman RRHH, el supervisor y el Servicio Jurídico Laboral.

## Verificación de no discriminación antes del desistimiento

El agente verifica que cada decisión del periodo de prueba cumple la normativa antes de cualquier acción irreversible: la no discriminación del ET art. 17, la igualdad retributiva del ET art. 28 y las obligaciones de la Ley 3/2007 y el RD 902/2020. Antes de un desistimiento, la verificación comprueba que no concurre embarazo, maternidad ni paternidad - que el Tribunal Constitucional considera nulidad automática - , que no es una represalia por una denuncia de los últimos 24 meses y que no hay discapacidad sin ajustes razonables. Si la verificación falla, bloquea el desistimiento y escala al Servicio Jurídico y a Compliance con una propuesta correctora. Esto importa porque la carga de la prueba recae en la empresa (LRJS art. 96): debe acreditar criterios objetivos y no discriminatorios, y sin un feedback estructurado y una verificación documentada el desistimiento se anula, con la sanción de la Inspección de Trabajo y la posible readmisión.

## Protección de datos y consulta al comité de empresa

El agente trata datos de desempeño y, en ocasiones, datos especiales como la incapacidad temporal, lo que hace obligatoria la evaluación de impacto en protección de datos y exige cifrado y acceso jerarquizado. El empleado puede ejercer su derecho de acceso (RGPD art. 15) y solicitar en el plazo de un mes todos sus datos de desempeño, el feedback del responsable y la decisión del periodo de prueba. La consulta al comité de empresa (ET art. 64) es obligatoria en los desistimientos colectivos (más de cinco empleados en el mismo trimestre y sector) y para las estadísticas trimestrales de contratación, ceses y tasa de conversión a indefinido. La consulta sigue siempre el mismo recorrido: documentación con las razones objetivas y la verificación de no discriminación, entrega quince días antes, reunión con acta firmada, recogida de observaciones, decisión y, por último, implantación con acuse de recibo. Prescindir de la consulta obligatoria es sancionable por la Inspección de Trabajo y la jurisprudencia anula esos desistimientos.

## Relación con los agentes de Onboarding y Evaluación del Desempeño

El agente aporta una infraestructura - cálculo de plazos, hitos, feedback estructurado y verificación previa al desistimiento - que otros agentes del Decision Layer reutilizan: el de Onboarding finaliza las tareas pendientes antes de la conversión en indefinido; el de Evaluación del Desempeño inicia el ciclo formal tras la confirmación, con el feedback del periodo de prueba como base; el de Relaciones Laborales gestiona las reclamaciones por desistimiento; el de Políticas le provee las versiones vigentes y el procedimiento sectorial. Sin esa fuente única, cada agente posterior trabajaría con información desactualizada. La integración con las plataformas españolas de RRHH y de firma se realiza por API.

## De un vistazo

- 16 microdecisiones en la gestión del periodo de prueba: 13 deterministas, 2 indicadores asistidos por IA y 1 confirmación humana.
- Cálculo automático del plazo según el ET art. 14 (seis meses para técnicos titulados, dos para el resto), con el límite del convenio.
- Hitos a los 30, 60, 90 y 150 días, con recordatorios escalonados y escalado cuando el plazo vence.
- Recogida del feedback del responsable con verificación de no discriminación (ET art. 17, Ley 3/2007, RD 902/2020).
- Verificación previa al desistimiento de que no concurre embarazo, represalia ni discapacidad sin ajustes.
- Decisión de continuidad, prórroga o desistimiento siempre humana (ET art. 49), por RRHH, el supervisor y el Servicio Jurídico.
- Acuse de recibo con firma electrónica cualificada, recordatorios escalonados y conservación de cinco años (LRJS art. 96).
- Consulta al comité de empresa en los desistimientos colectivos (ET art. 64).
- Sanciones: la Inspección de Trabajo puede multar hasta 187.515 euros y la AEPD hasta el 4% de la facturación.

| Distribucion de Decididores Probation-Management |
|----------|
| 13 deterministas: cálculo del plazo, hitos, recordatorios, reconciliación con el convenio, seguimiento, alertas, verificación de no discriminación, acciones posteriores, acuse de recibo, notificación a la Inspección y escalado al comité |
| 2 indicadores asistidos por IA: recogida del feedback estructurado y archivado de la documentación |
| 1 confirmación humana: decisión de continuidad, prórroga o desistimiento (ET art. 49) por RRHH, el supervisor y el Servicio Jurídico |

--- Agente Procesos Promoción ---
> Proceso ascenso: ET art. 4/17, RD 901/2020 Plan Igualdad, EU AI Act Anexo III(4)(b) Sistema Alto Riesgo y Pay Transparency 2023/970 horquilla - workflow auditable con Bias-Audit.

## El ascenso, entre la no discriminación del ET y el Reglamento de IA

Este agente sigue el principio [Decision Layer](/es/decision-layer/): cada decisión es basada en reglas, asistida por IA o explicitamente asignada a un humano. Esta clasificado según [EU AI Act 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) Anexo III(4)(b) como Sistema Alto Riesgo desde 2.8.2026, sujeto a obligaciones reforzadas sobre Sistema Gestión Riesgo, Governance Datos, Transparencia, Supervisión Humana y Bias-Audit.

Un proceso de ascenso típico dura tres meses: propuesta del Director de Unidad de Negocio, recopilación documentación rendimiento, validación elegibilidad y banda salarial nuevo grado, workflow aprobación multinivel por Director, HR Lead, CFO y Dirección, notificación Comité de Empresa con plazo 15 dias hábiles, generación nuevo contrato, firma, onboarding al nuevo grado.

El problema no está en el tiempo, sino en lo que no pasa entre los pasos: la verificación sistemática de la elegibilidad, el análisis de equidad sobre los patrones de ascenso, los rationales documentados que sostienen la inversión de la carga de la prueba (ET art. 17 y LRJS art. 96), la validación del cambio de banda con la Compa-Ratio del nuevo grado y la consistencia entre unidades de negocio.

## Lo que queda invisible en propuestas Excel paralelas

Cuando 40 Directores de Unidad de Negocio rellenan propuestas de ascenso en archivos Excel paralelos, emerge una colección de evaluaciones individuales que nadie puede agregar, validar o comparar en tiempo real. Las consecuencias tipicas:

**Criterios de elegibilidad sin verificación.** La verificación recae en el Director que propone el ascenso - y tiene interés en el resultado. Si realmente se cumplen los criterios formales (antigüedad minima 12-24 meses en grado, rendimiento sostenido dos ciclos, sin medidas disciplinarias) solo se ve cuando Compensación revisa el expediente semanas después. ET art. 17 inversión carga prueba riesgo en caso criterios aplicados de forma discriminatoria.

**Bandas salariales nuevo grado sin validación.** Un ascenso significa cambio de banda. En procesos basados en hojas de calculo nadie comprueba en tiempo real si el nuevo salario cae dentro de la banda del grado destino segun Convenio Colectivo, ni si la Compa-Ratio nueva encaja con el equipo. La vista de conjunto - presupuesto, banda, equidad - no la tiene nadie. RD 902/2020 auditoria retributiva en cambio banda obligatoria.

**Los patrones de ascenso discriminatorios quedan ocultos.** El estudio "Women in the Workplace" de McKinsey lo documenta desde hace diez años: por cada 100 hombres que reciben su primera promoción a manager, hay 81 mujeres. No porque las decisiones individuales sean erróneas, sino porque no existe un proceso que haga visible el patrón mientras se forma. En una demanda por discriminación en el ascenso, la carga de la prueba se invierte (ET art. 17 y LRJS art. 96), y sin un rationale documentado por cada ascenso la defensa es casi imposible. El precedente Mobley contra Workday prueba el riesgo sistémico.

## Alto riesgo según el Reglamento de IA: evaluación de impacto y de derechos

El agente se clasifica como de alto riesgo según el Anexo III(4)(b) del Reglamento Europeo de IA, que cubre las decisiones de promoción de personal. Esa clasificación se mantiene; conforme a la legislación vigente, desde el 2 de agosto de 2026 conlleva las obligaciones reforzadas de gestión de riesgos con mitigación de sesgos por género, edad y discapacidad (con un aplazamiento a diciembre de 2027 acordado provisionalmente por el Digital Omnibus, mayo de 2026, adopción formal aún pendiente); la gobernanza de los datos de entrenamiento con pruebas de paridad e igualdad de oportunidades sobre el historial de ascensos; la transparencia hacia los empleados, ascendidos o no; la supervisión humana en cada recomendación, y una evaluación de impacto en los derechos fundamentales antes del despliegue, consultada con la AEPD, el Delegado de Protección de Datos, el comité de empresa y la AESIA.

Multas hasta 35 millones EUR o 7 por ciento facturación global grupo. Cross-Reference RGPD art. 35 obligación DPIA en evaluación automatizada con impacto sobre carrera. [Mobley v. Workday](https://www.courtlistener.com/docket/67476007/mobley-v-workday-inc/) (2023) sirve como precedente US.

## No discriminación e igualdad en el ascenso

El proceso se ajusta a la prohibición de discriminación en las relaciones laborales del ET art. 17, que incluye la promoción, y a la promoción profesional del art. 24. La Ley 3/2007 garantiza la igualdad de trato y oportunidades en el acceso al empleo y a la promoción; el RD 901/2020 exige criterios objetivos de promoción inscritos en REGCON en las empresas de más de 50 empleados, y el RD 902/2020 obliga a la auditoría retributiva en el cambio de banda y a una valoración objetiva de los puestos. El incumplimiento es sancionable por la Inspección de Trabajo con hasta 187.515 euros.

El motor de análisis de equidad comprueba estadísticamente todas las características protegidas. Para cada una mide la paridad demográfica (igual frecuencia de ascenso entre grupos comparables) y la igualdad de oportunidades (igual probabilidad de ascenso con un desempeño comparable). Ante desviaciones estadísticamente significativas, escala de forma automática al HR Lead, con todo registrado en el audit-trail.

## Riesgo sancionador y el precedente Mobley contra Workday

Los riesgos de una gestión deficiente del ascenso se acumulan y proceden de varias fuentes: la indemnización por daños y perjuicios y por discriminación, las sanciones de la Inspección de Trabajo de hasta 187.515 euros y la jurisprudencia sobre discriminación indirecta. En acciones colectivas, la cifra puede alcanzar los siete dígitos. Como sistema de alto riesgo, el Reglamento de IA prevé multas de hasta 35 millones de euros o el 7% de la facturación mundial, y el RGPD de hasta el 4%. La transparencia retributiva europea, desde el 7 de junio de 2026, invierte la carga de la prueba y obliga a indicar una horquilla salarial en la oferta interna de ascenso.

El precedente Mobley contra Workday - una acción colectiva en Estados Unidos por sesgo del algoritmo de selección y promoción contra empleados de más de 40 años - está marcando la línea de los reguladores y de los estándares de los auditores.

## Consulta al comité de empresa

El comité de empresa tiene derecho a ser informado sobre los criterios de selección y promoción (ET art. 64.5), y su participación, junto con la de la comisión negociadora del Plan de Igualdad, es obligatoria para introducir el sistema. La notificación se hace con quince días hábiles de antelación antes de un ascenso a un puesto de responsabilidad.

En concreto, se acuerdan con el comité los criterios objetivos de promoción, las bandas retributivas del nuevo grado según el convenio, los umbrales del análisis de equidad, la matriz de aprobación y el acceso al audit-trail. En caso de desacuerdo se acude a la mediación y a la jurisdicción social. La transparencia retributiva europea obliga, desde el 6 de junio de 2026, a indicar la horquilla salarial en la oferta interna de ascenso, reconoce el derecho a conocer la retribución mediana del grupo comparable y prohíbe preguntar por el historial salarial. Una brecha de género superior al 5% sin justificar en el cambio de banda activa una evaluación retributiva conjunta y seis meses para corregirla.

## Relación con los agentes de Ciclo de Mérito, Comparativa Retributiva y Evaluación del Desempeño

El agente está integrado en un conjunto de agentes de RRHH especializados. El [Agente de Ciclo de Mérito](/es/catalogo-agentes-hr/merit-cycle-governance-agent/) reutiliza el motor de análisis de equidad para el ciclo retributivo anual. El [Agente de Comparativa Retributiva](/es/catalogo-agentes-hr/compensation-benchmarking-agent/) aporta las bandas del nuevo grado, las Compa-Ratios y los datos de la horquilla salarial. El [Agente de Evaluación del Desempeño](/es/catalogo-agentes-hr/performance-review-documentation-agent/) aporta las calificaciones de los dos últimos ciclos como requisito de elegibilidad. El [Agente de Generación de Ofertas](/es/catalogo-agentes-hr/contract-offer-generation-agent/) recibe la nueva carta de ascenso, el [Agente de Cálculo de Nóminas](/es/catalogo-agentes-hr/payroll-calculation-agent/) los ajustes aprobados y el [Agente de Reporting de Nóminas](/es/catalogo-agentes-hr/payroll-reporting-agent/) genera las métricas de diversidad. El [Agente de Gestión Documental](/es/catalogo-agentes-hr/hr-document-management-agent/) archiva los rationales del ascenso, el [Agente de Auditoría de Compliance](/es/catalogo-agentes-hr/audit-compliance-agent/) verifica la evaluación de impacto y el [Agente de Onboarding](/es/catalogo-agentes-hr/onboarding-workflow-agent/) gestiona la incorporación al nuevo grado.

## De un vistazo

- **Clasificación**: sistema de alto riesgo según el Anexo III(4)(b) del Reglamento de IA; obligaciones vigentes desde el 2 de agosto de 2026 según la legislación actual, con aplazamiento a diciembre de 2027 acordado provisionalmente (Digital Omnibus, mayo de 2026, adopción formal pendiente).
- **Anclas de cumplimiento**: la no discriminación y la promoción profesional del ET, la Ley de Igualdad, el Plan de Igualdad del RD 901/2020, la auditoría retributiva del RD 902/2020 y la horquilla salarial de la transparencia retributiva europea.
- **Consulta**: el comité de empresa tiene derecho a ser informado sobre los criterios de promoción (ET art. 64.5), con quince días hábiles de antelación.
- **Umbral de equidad**: una brecha de género superior al 5% sin justificar en el cambio de banda activa una evaluación retributiva conjunta y seis meses de corrección.
- **Multas**: hasta 35 millones de euros o el 7% de la facturación mundial (Reglamento de IA), hasta el 4% (RGPD) y hasta 187.515 euros (Inspección de Trabajo).
- **Auditoría**: evaluación de impacto, evaluación de derechos fundamentales y auditoría de sesgos trimestral, con verificación del auditor en sostenibilidad a partir de 250 empleados.
- **Precedente**: Mobley contra Workday, acción colectiva por sesgo del algoritmo de selección y promoción contra empleados de más de 40 años.

### Distribución de Decididores Promotion-Process

| Paso | Decididor | Rationale |
|------|-----------|-----------|
| Recepción de la propuesta del director | H | El rationale humano obligatorio inicia el proceso |
| Verificación de elegibilidad | R | Antigüedad, desempeño y ausencia de sanciones, por reglas |
| Verificación del puesto de destino | R | Plantilla y presupuesto, de forma determinista |
| Validación del cambio de banda | R | Horquilla del nuevo grado, comprobada automáticamente |
| Cálculo del impacto retributivo | R | IRPF, cotizaciones y pensiones, de forma determinista |
| Análisis de equidad | A | Detección estadística de sesgos, con validación humana |
| Escalado de equidad | R | Umbral del 5% de la transparencia retributiva europea |
| Flujo de aprobación | R | Matriz multinivel según jerarquía y Compa-Ratio |
| Notificación al comité de empresa | R | ET art. 64, con quince días de plazo |
| Aprobación del HR Lead | H | Aprobación intermedia conforme al ET |
| Aprobación final de la dirección | H | Aprobación estratégica bajo el Código de Buen Gobierno |
| Información al empleado | R | Deber de informar y derecho a impugnar (RGPD) |
| Conversación de ascenso | H | Conversación personal de dimensión relacional |
| Generación del contrato | R | Modificación contractual y nómina, de forma determinista |
| Reporting de sostenibilidad | R | Métricas de diversidad del ESRS, de forma determinista |

--- Agente Procesamiento Bajas IT ---
> Procesamiento parte médico IT: ET art. 45.1.c suspensión contrato, RD 625/2014 gestión IT, Sistema RED TGSS comunicación bajas y RGPD art. 9 datos salud - parte de baja en 60 segundos.

El procesamiento de partes médicos de IT en España se sitúa en la intersección de cinco regímenes paralelos. El RD 625/2014 regula la gestión de la IT durante los primeros 365 días, los tipos de parte y el plazo de comunicación de tres días hábiles a través del Sistema CASIA. La LGSS fija la prestación (60-75% en contingencia común, 75% desde el primer día en la profesional) y los recargos por mora y por culpa empresarial. La Ley 31/1995 obliga a la vigilancia de la salud, la Ley 41/2002 impone la confidencialidad del diagnóstico, y el RGPD trata estos datos como categoría especial. En la práctica, cualquier parte de baja en una empresa española de mediana o gran dimensión puede activar a la vez varias de estas obligaciones.

## Parte de baja en 60 segundos en lugar de tres semanas demora postal

Una empresa española de 1.500 empleados procesa cada año entre 200 y 350 partes de IT. Cada uno desencadena la misma cascada: clasificar el tipo de parte, vincularlo al expediente, calcular la prestación, comunicarlo al Sistema RED en tres días hábiles, avisar al responsable sin revelar el diagnóstico, ajustar la nómina y vigilar los umbrales de salud. La realidad del proceso manual es muy distinta: el parte llega en papel con semanas de retraso, el Excel no valida el historial, la comunicación al Sistema RED se hace fuera de plazo (recargo del 20%, art. 28 LGSS) y el parte se reenvía por correo en PDF, vulnerando la Ley 41/2002. Las sanciones se acumulan: las de la Inspección de Trabajo, las de la AEPD por la brecha de datos de salud y los recargos por mora y por culpa empresarial.

## Clasificación del parte y detección de la recaída

El agente clasifica cada parte de forma determinista conforme al RD 625/2014: baja inicial, confirmación, alta o recaída. Durante la IT, el contrato queda en suspenso (ET art. 45.1.c) y el trabajador tiene derecho a reincorporarse tras el alta (art. 48). La recaída a 180 días es una fuente frecuente de error: si el trabajador vuelve a causar baja por la misma patología dentro de los 180 días siguientes al alta anterior, no se inicia un proceso nuevo, sino que se suma la duración acumulada (LGSS art. 169.2). El agente lo detecta cruzando automáticamente el expediente de los últimos cinco años, el grupo diagnóstico y la fecha del alta.

## Comunicación a la TGSS, al Sistema CASIA y a las Mutuas

El agente comunica baja y alta al Sistema RED de la TGSS dentro del plazo de tres días hábiles (RD 625/2014 art. 7); incumplirlo activa el recargo de mora del art. 28 de la LGSS, de hasta el 20%. El parte facultativo llega por el Sistema CASIA, que interopera con los servicios públicos de salud autonómicos. En contingencia profesional, la Mutua Colaboradora abona la prestación desde el primer día. El cálculo de la prestación sigue los art. 169-176 de la LGSS: en contingencia común, el 60% de la base reguladora del día 4 al 20 y el 75% a partir del día 21; en la profesional, el 75% desde el primer día. A ello se suma el complemento de empresa que fije el convenio colectivo.

## Confidencialidad de los datos de salud

Los datos de IT son datos de salud de categoría especial (RGPD art. 9) sujetos a la confidencialidad estricta del art. 7 de la Ley 41/2002, y su tratamiento se ampara en una obligación de Derecho laboral (art. 9.2.b). El agente impone por arquitectura la minimización de datos del art. 5.1.c: a la empresa solo se le transmite que existe una IT, la fecha de baja y la duración estimada; nunca el diagnóstico, el tratamiento ni el facultativo emisor. El acceso queda restringido a quien lo necesita y queda registrado en el audit-trail, con cifrado y almacenamiento inalterable. Reenviar un parte en PDF por correo vulnera la Ley 41/2002 y expone a la empresa a una sanción de la AEPD de hasta el 4% de la facturación. Esta arquitectura no es una opción técnica, sino un requisito estructural: quien reenvía partes por correo tiene un problema de protección de datos aunque nadie lo provoque a propósito. Un agente basado en reglas no tiene ese problema, porque define de antemano qué dato llega a cada destinatario.

## Vigilancia de la salud, casos largos y control del fraude

El agente activa el protocolo de vigilancia de la salud (Ley 31/1995 art. 22) al alcanzar los umbrales de IT acumulada: 6 semanas en 12 meses, 12 semanas continuas (examen de salud obligatorio) y 365 días, cuando el médico inspector del INSS puede proponer una incapacidad permanente. Los trabajadores sensibles (embarazo, lactancia, discapacidad) tienen una protección reforzada (ET art. 25 PRL), y la reincorporación tras una IT prolongada con secuelas puede exigir adaptar el puesto (LGD art. 40). El control empresarial del parte se ampara en el art. 20.4 del ET, y los indicios de fraude - un parte no oficial, una duración incoherente, un segundo empleo activo - se escalan a la Inspección de Trabajo. Conviene recordar el límite jurisprudencial: el despido por una enfermedad previsiblemente prolongada se equipara a la discriminación por discapacidad (STJUE C-270/16, Daouidi), con inversión de la carga de la prueba (LRJS art. 96).

## Integración con Payroll-Processing, Leave-of-Absence y HR-Document-Management

El agente sincroniza el procesamiento de la IT con otros agentes del Decision Layer: el Payroll-Processing toma la prestación calculada para la nómina; el Leave-of-Absence gestiona la suspensión del contrato (ET art. 45.1.c) y la reincorporación tras el alta (art. 48); el HR-Document-Management archiva el parte de forma confidencial (Ley 41/2002 art. 17); y el Employee-Relations-Case interviene en una disputa del alta médica. La reincorporación tras una IT prolongada no la inicia el agente: este solo comunica que se ha superado el umbral a RRHH, al Servicio de Prevención y al Comité de Empresa, y es una persona quien decide el momento y la forma. No es una limitación técnica, sino una decisión de arquitectura deliberada: la vuelta tras una baja larga es una conversación entre personas sobre el futuro de la relación laboral, y ningún algoritmo decide cuándo es el momento adecuado. El agente se integra por API con las plataformas españolas más extendidas (A3, Sage, Cegid, Bizneo, Holded, Factorial, SAP SuccessFactors, Workday, Oracle, Personio), con el Sistema RED de la TGSS y con el Sistema CASIA.

## De un vistazo

- 13 decisiones deterministas y 2 indicadores asistidos por IA, ninguno con efecto sobre la relación laboral.
- Clasifica el tipo de parte (baja inicial, confirmación, alta o recaída a 180 días) a partir del Sistema CASIA.
- Calcula la prestación según los art. 169-176 de la LGSS: 60-75% en contingencia común, 75% desde el primer día en la profesional, más el complemento de empresa del convenio.
- Comunica baja y alta al Sistema RED de la TGSS dentro de los tres días hábiles, evitando el recargo de mora del art. 28 de la LGSS.
- Preserva la confidencialidad del diagnóstico (Ley 41/2002 art. 7; minimización del art. 5.1.c del RGPD): el responsable directo nunca recibe el código CIE-10.
- Vigila los umbrales de salud del art. 22 de la Ley 31/1995 (6 y 12 semanas, 365 días) y la posible adaptación del puesto (LGD art. 40).
- Marca los indicios de fraude para el control empresarial (ET art. 20.4) y el escalado a la Inspección de Trabajo.
- Las sanciones por incumplimiento son acumulables: Inspección de Trabajo, AEPD (4%), recargo de mora (20%) y recargo de prestaciones (50%).

| Distribución de Decididores Sick-Leave-Processing |
|----------|
| 13 deterministas: clasificación, validación, vinculación, detección de solapamientos, cálculo de la prestación, comunicación al Sistema RED y a la Mutua, notificación y casos largos |
| 2 indicadores asistidos por IA: detección del fraude y enrutamiento de los casos ambiguos (recaída o alta en disputa, accidente con culpa empresarial) |
| 0 confirmaciones humanas estructurales: el flujo no afecta a la relación laboral; los escalados concretos se detallan en governanceNotes |

--- Agente Skills-Career-Profile ---
> Skills-matching y perfiles competencia: ET art. 22/39, EU AI Act Anexo III(4)(b) Task-Assignment alto riesgo y MECES/ESCO/INCUAL - Bias-Audit con validación humana.

## Skills-matching como trampa compliance entre ET art. 17 y EU AI Act

Este agente sigue el principio [Decision Layer](/es/decision-layer/): cada decisión es basada en reglas, asistida por IA o explicitamente asignada a un humano. Esta clasificado según [EU AI Act 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) Anexo III(4)(b) como Sistema Alto Riesgo desde 2.8.2026 por task-assignment basada en rasgos personales, sujeto a obligaciones reforzadas sobre Sistema Gestión Riesgo, Governance Datos, Transparencia, Supervisión Humana y Bias-Audit.

Un proceso típico de actualización del perfil de competencias dura cuatro semanas y encadena varios pasos: la solicitud del Director de Unidad de Negocio o del Talent Lead, la extracción de competencias a partir del CV, la validación de las certificaciones y titulaciones, el análisis de brechas frente al puesto de destino, la recomendación de itinerarios con opciones de movilidad funcional (ET art. 39), la validación contra el Plan Estratégico de Recursos Humanos, el flujo de aprobación multinivel, la notificación al Comité de Empresa con 15 días hábiles de antelación, la conversación de carrera con el responsable y la generación del plan de desarrollo individual con sus matriculaciones.

El problema no está en el tiempo, sino en lo que no ocurre entre los pasos: el alineamiento sistemático con ESCO, INCUAL y MECES, el análisis de equidad sobre los patrones de clasificación, las justificaciones documentables que harían falta ante una inversión de la carga de la prueba (ET art. 17 y 22; LRJS art. 96) y la consistencia entre unidades de negocio.

## Por qué es un sistema de alto riesgo según el Reglamento de IA

El agente queda bajo el Anexo III.4.b del Reglamento de IA de la UE 2024/1689, que clasifica como de alto riesgo las decisiones de asignación de tareas basadas en rasgos personales. El skills-matching y la clasificación de talento por aprendizaje automático entran de lleno en esta categoría, porque clasifican a los empleados por rasgos personales (competencias, experiencia, capacidad de aprendizaje). Esa clasificación se mantiene; conforme a la legislación vigente, desde el 2 de agosto de 2026 - con un aplazamiento a diciembre de 2027 acordado provisionalmente por el Digital Omnibus (mayo de 2026, adopción formal aún pendiente) - las obligaciones incluyen un sistema de gestión de riesgos, gobernanza de datos con mitigación del sesgo, transparencia hacia los empleados afectados, supervisión humana en el bucle, las obligaciones del desplegador (DPIA, seguimiento posterior al mercado y notificación de incidentes) y una evaluación de impacto sobre los derechos fundamentales (FRIA) antes del despliegue, consultando a la AEPD, al DPD, al Comité de Empresa y a la AESIA.

Las multas llegan a 35 millones de euros o al 7% de la facturación global del grupo. El art. 35 del RGPD obliga además a una DPIA en toda evaluación automatizada con impacto sobre la carrera. El caso [Mobley contra Workday](https://www.courtlistener.com/docket/67476007/mobley-v-workday-inc/) (2023) sirve de precedente estadounidense específico sobre clasificación de talento en RRHH.

## El Estatuto de los Trabajadores y la valoración objetiva de puestos

El Estatuto de los Trabajadores prohíbe la discriminación en la relación laboral, también en la clasificación de competencias (art. 17), regula el sistema de clasificación profesional (art. 22) y la movilidad funcional dentro del grupo (art. 39), y reconoce al Comité de Empresa el derecho a conocer los criterios de clasificación (art. 64.5). La Ley de Igualdad garantiza la igualdad de trato en el acceso al empleo y la promoción. Los planes de igualdad (RD 901/2020), obligatorios desde 50 empleados, exigen criterios objetivos de clasificación inscritos y renovados cada cuatro años, y el RD 902/2020 impone una valoración de puestos objetiva basada en competencias. La Inspección de Trabajo puede sancionar el incumplimiento con hasta 187.515 euros.

El motor de análisis de equidad comprueba estadísticamente todas las características protegidas. Para cada una mide la paridad demográfica (que la frecuencia de clasificación sea igual entre grupos comparables) y la igualdad de oportunidades (que la probabilidad de clasificar en un nivel superior sea igual a igualdad de experiencia). Ante una desviación estadísticamente significativa, el caso se escala de forma automática al Talent Lead y al Learning Lead, con un audit-trail conforme al Estatuto. La jurisprudencia reciente del Tribunal Supremo sobre movilidad funcional, valoración objetiva de puestos y discriminación indirecta perfila esta línea.

## RGPD art. 22 prohibicion clasificacion talentos automatizada

El art. 22 del RGPD prohíbe expresamente las decisiones individuales basadas únicamente en un tratamiento automatizado con efecto jurídico o significativo análogo. El skills-matching y la clasificación de talento automatizada caen claramente bajo esta prohibición, porque afectan a la progresión de carrera, al acceso a la formación y a las recomendaciones de movilidad. La validación humana obligatoria (art. 22.2.b, excepción por autorización legal con medidas adecuadas) exige al Talent Lead y al Learning Lead como decisión final real, no como mera aprobación formal. El art. 22.3 garantiza el derecho a impugnar cada recomendación automatizada con su justificación e intervención humana, y el art. 35 obliga a una DPIA en las evaluaciones con impacto sobre la carrera. El art. 9 prohíbe tratar datos de categoría especial (salud, afiliación sindical, religión, orientación sexual) en el análisis de equidad, salvo consentimiento explícito con medidas adecuadas. La AEPD puede imponer multas de hasta el 4% de la facturación del grupo o 20 millones de euros, con supervisión paralela de las autoridades autonómicas.

## Los marcos de cualificaciones y el precedente Mobley contra Workday

El MECES (RD 1027/2011) establece los niveles 1 a 4 de la educación superior española (Técnico Superior, Grado, Máster, Doctorado), alineados con el Marco Europeo de Cualificaciones. ESCO, la clasificación de la Comisión Europea, ofrece una taxonomía estandarizada con más de 13.000 competencias y 3.000 ocupaciones, traducida a 27 idiomas. El INCUAL mantiene el Catálogo Nacional de Cualificaciones Profesionales, con 26 familias y 5 niveles. El agente alinea cada extracción contra estos tres marcos para garantizar la comparabilidad europea.

El caso Mobley contra Workday (2023) sirve de precedente estadounidense sobre el sesgo de la IA en software de clasificación de talento (frente a empleados mayores de 40 años, paralelo a la prohibición del art. 17 del ET) y orienta tanto a los reguladores como a los estándares de auditoría. El patrón de mitigación de sesgo se aplica de forma proactiva en las integraciones con las plataformas de talento.

## Integración con Promotion-Process, Performance-Review-Documentation y Succession-Planning

El agente está integrado en una cadena de agentes de RRHH especializados. El [Promotion-Process-Agent](/es/catalogo-agentes-hr/promotion-process-agent/) reutiliza el motor de brechas como requisito de elegibilidad y comparte el motor de equidad. El [Performance-Review-Documentation-Agent](/es/catalogo-agentes-hr/performance-review-documentation-agent/) aporta las calificaciones de desempeño como entrada del análisis de brechas. El [Succession-Planning-Agent](/es/catalogo-agentes-hr/succession-planning-agent/) reutiliza el motor de brechas para identificar sucesores. El [Onboarding-Workflow-Agent](/es/catalogo-agentes-hr/onboarding-workflow-agent/) recibe el perfil de competencias actualizado, y el [Learning-Management-Agent](/es/catalogo-agentes-hr/learning-management-agent/) recibe el plan de desarrollo y las matriculaciones. El [Compensation-Benchmarking-Agent](/es/catalogo-agentes-hr/compensation-benchmarking-agent/) usa el alineamiento con ESCO, INCUAL y MECES; el [Merit-Cycle-Governance-Agent](/es/catalogo-agentes-hr/merit-cycle-governance-agent/) reutiliza el motor de equidad; el [HR-Document-Management-Agent](/es/catalogo-agentes-hr/hr-document-management-agent/) archiva las justificaciones de clasificación durante cuatro años; y el [Audit-Compliance-Agent](/es/catalogo-agentes-hr/audit-compliance-agent/) verifica el cumplimiento del Reglamento de IA, la DPIA y la FRIA. La diferencia con el de promoción es de alcance: este actualiza el perfil base de competencias cada trimestre, mientras que el de promoción gestiona los ascensos individuales anuales con cambio de banda salarial.

## De un vistazo

- **Clasificación**: sistema de alto riesgo según el Reglamento de IA de la UE (Anexo III.4.b), por asignación de tareas basada en rasgos personales; obligaciones vigentes desde el 2 de agosto de 2026 según la legislación actual, con aplazamiento a diciembre de 2027 acordado provisionalmente (Digital Omnibus, mayo de 2026, adopción formal pendiente).
- **Anclas de cumplimiento**: el Estatuto de los Trabajadores (art. 17, 22, 39 y 64), la Ley de Igualdad, los planes de igualdad (RD 901/2020), la valoración objetiva de puestos (RD 902/2020), el RGPD (art. 22, 35 y 88) y la CSRD (ESRS S1-13).
- **Marcos de cualificaciones**: MECES, ESCO e INCUAL (26 familias y 5 niveles).
- **Consulta**: el Comité de Empresa tiene derecho a conocer los criterios de clasificación (ET art. 64.5), con notificación de 15 días hábiles.
- **Umbral de equidad**: una desviación del 5% por característica protegida activa una evaluación conjunta del Plan de Igualdad y la remediación.
- **Multas**: hasta 35 millones de euros o el 7% de la facturación global (Reglamento de IA), hasta el 4% o 20 millones (RGPD) y hasta 187.515 euros (Inspección de Trabajo).
- **Obligación de auditoría**: DPIA, FRIA y auditoría de sesgo trimestral, con verificación del auditor sobre la CSRD a partir de 250 empleados.
- **Precedente en EE. UU.**: el caso Mobley contra Workday (2023), demanda colectiva por sesgo de la IA en software de clasificación de talento frente a empleados mayores de 40 años.

### Distribución de Decididores Skills-Career-Profile

| Paso | Decididor | Rationale |
|------|-----------|-----------|
| Recepción de la solicitud | H | La inicia siempre una persona con justificación documentada |
| Extracción de competencias | R | Análisis del CV alineado con ESCO, INCUAL y MECES, determinista |
| Validez de las certificaciones | R | Comprobación automática contra los registros oficiales |
| Análisis de brechas de competencias | A | Comparación estadística con IA, validación humana |
| Análisis de equidad | A | Detección estadística de sesgo con IA, validación humana |
| Recomendación de itinerarios | A | Matching de movilidad funcional (ET art. 39) con validación humana |
| Validación del Plan Estratégico de RRHH | R | Contraste con presupuesto y prioridades, determinista |
| Flujo de aprobación | R | Matriz multinivel según el alcance del cambio |
| Notificación al Comité de Empresa | R | ET art. 64 y LO 3/2007 art. 47, plazo de 15 días |
| Validación humana del Talent Lead | H | Aprobación final conforme al ET y al art. 14 del Reglamento de IA |
| Información al empleado (RGPD) | R | Flujo estándar de los art. 13, 14 y 22.3 |
| Conversación de carrera | H | Conversación personal, dimensión relacional |
| Generación del plan de desarrollo | R | Volcado al LMS con matriculaciones, determinista |
| Reporte CSRD | R | Indicadores ESRS S1-13, determinista |

--- Agente HR Analytics Estratégico ---
> Analítica estratégica RRHH: CSRD ESRS S1-1/S1-10/S1-13/S1-16, Ley 11/2018 EINF y RD 902/2020 ratio brecha 6% - dashboards C-Level con Predictive Analytics rotación y Board Reporting Comité Auditoría.

El análisis estratégico de RRHH en España se sitúa en la intersección de cinco regímenes paralelos. La CSRD obliga a reportar los indicadores ESRS S1 en formato electrónico, con verificación del auditor a partir de 250 empleados. La Ley 11/2018 impone el estado de información no financiera desde 500 empleados. El Estatuto de los Trabajadores y el RD 902/2020 exigen la auditoría retributiva cada tres años y el ratio de brecha del 6%. El RGPD obliga a tratar los datos de forma agregada y anonimizada, con evaluación de impacto. En la práctica, cualquier ciclo de análisis estratégico en una empresa de mediana o gran dimensión activa a la vez varias de estas obligaciones, ante la AEPD, la Inspección de Trabajo, el ICAC, la CNMV y el auditor.

## De datos HR a percepciones estratégicas

El análisis estratégico de RRHH es un proceso muy reglado, pero en muchas empresas sigue ejecutándose como semanas de presentaciones a mano. Los indicadores ESRS S1 regulan la plantilla, la diversidad, la igualdad retributiva, la retribución, la salud y los incidentes de discriminación; la Ley 11/2018 obliga al estado de información no financiera desde 500 empleados; el RD 902/2020 fija la auditoría retributiva y el ratio de brecha del 6%; y la CSRD exige verificación del auditor a partir de 250 empleados. Ningún paso requiere interpretación. Y sin embargo el proceso opera a mano: los datos llegan en exportaciones de Excel de varios sistemas, los indicadores de diversidad se calculan con fórmulas, la brecha se cuadra en una hoja de cálculo, el reporte ESRS se redacta en Word y el del Consejo se prepara en una presentación. Una empresa de 3.000 empleados genera cada trimestre todo ese paquete a la vez. El agente automatiza el 90% del proceso y solo deja en manos humanas la aprobación final y la presentación al Comité de Auditoría, a cargo del CHRO, el CFO y el Director ESG.

## Reporte CSRD (ESRS S1) e información no financiera

La CSRD y los estándares europeos de sostenibilidad (ESRS) establecen un reporte integrado de la plantilla. El indicador S1-1 describe la composición de la plantilla por sexo, edad, tipo de contrato, región y clasificación; el S1-9, la diversidad (proporción de mujeres y hombres por nivel jerárquico, personas con discapacidad - la LGD exige el 2% - y edad); el S1-10, la brecha salarial bruta y ajustada; el S1-13, la retribución total por sexo; el S1-14, la salud y la seguridad; el S1-16, el ratio entre la retribución del CEO y la mediana; y el S1-17, los incidentes de discriminación. El reporte se presenta en formato electrónico (ESEF iXBRL) y, a partir de 250 empleados, requiere verificación del auditor. La Ley 11/2018 obliga además al estado de información no financiera desde 500 empleados. Un reporte falso puede acarrear la inhabilitación del auditor, una sanción a la empresa de hasta 12 millones de euros y la responsabilidad ilimitada de los administradores (LSC art. 236-237).

## Análisis de rotación, diversidad e igualdad

El Estatuto de los Trabajadores garantiza la igualdad de oportunidades (art. 17) y la igualdad retributiva por trabajo de igual valor (art. 28), desarrolladas por la Ley de Igualdad y el RD 902/2020. El Plan de Igualdad es obligatorio desde 50 empleados, la auditoría retributiva se hace cada tres años analizando los salarios por categoría, sexo y valor del trabajo, y el registro retributivo es obligatorio para todas las empresas, con un umbral de brecha del 6%. El reporte de diversidad recoge la proporción de mujeres y hombres por nivel jerárquico, las personas con discapacidad (la LGD exige el 2% de la plantilla) y la distribución por edad. El análisis de rotación distingue la voluntaria - por departamento, categoría, sexo, edad y antigüedad - de la involuntaria, y separa los indicadores adelantados (compromiso, valoración del responsable, brecha de compensación) de los retardados (rotación, absentismo, quejas). La Inspección de Trabajo puede sancionar el incumplimiento con hasta 187.515 euros.

## Protección de datos y consulta al Comité de Empresa

El RGPD ampara el tratamiento en una obligación legal (Ley de Igualdad, RD 902/2020, Ley 11/2018) y exige que el reporte sea agregado y anonimizado (art. 88), con técnicas como la k-anonimización y un mínimo de cinco individuos por celda estadística. Obliga además a un registro de actividades de tratamiento (art. 30), al cifrado y almacenamiento inalterable (art. 32) y a una evaluación de impacto del componente de análisis agregado (art. 35). Las solicitudes de acceso se responden en un mes y las brechas se comunican en 72 horas. El Comité de Empresa tiene derecho a ser informado y consultado (ET art. 64 y 65) sobre los cambios materiales del sistema: un cambio en la metodología de cálculo de la brecha, las medidas correctoras del Plan de Igualdad o una brecha superior al 6% sin justificar. La AEPD puede sancionar con hasta el 4% de la facturación mundial o 20 millones de euros.

## Análisis predictivo y retorno de la inversión en RRHH

El agente realiza el análisis predictivo de rotación, las correlaciones de compromiso y el cálculo del retorno de la inversión siempre como indicador, nunca como decisión individual automatizada; por eso no es un sistema de alto riesgo según el Reglamento de IA de la UE. El modelo calcula correlaciones entre las puntuaciones de compromiso, la antigüedad, la brecha de compensación frente al mercado, la valoración del responsable y las horas de formación, y distingue los indicadores adelantados de los retardados. El retorno de la inversión en talento relaciona el coste y las horas de formación con sus resultados en promoción y retención. Los cuadros de mando para la dirección reúnen la plantilla, el coste y el tiempo de contratación, la movilidad interna, la productividad por empleado, la tasa de absentismo, el ratio entre la retribución del CEO y la mediana, los indicadores de diversidad y la brecha salarial. Los datos se cifran y se conservan conforme a los plazos aplicables.

## Integración con Performance-Review, Workforce-Planning y Succession-Planning

Cuatro agentes operan en la estrategia de talento con focos distintos. El Performance-Review-Agent se ocupa de la evaluación individual del desempeño (puede ser de alto riesgo si afecta a la retribución variable); el Workforce-Planning-Agent, de la planificación de la capacidad y la proyección de plantilla; y el Succession-Planning-Agent, de la sucesión en los puestos clave. Este agente se ocupa del análisis agregado, los cuadros de mando para la dirección y el reporte al Consejo, sin decisiones individuales automatizadas, lo que lo mantiene fuera de la categoría de alto riesgo. Los tres primeros le aportan datos individuales agregados y anonimizados (RGPD art. 88), y él reporta al Consejo, al Comité de Auditoría y a la Junta. La validación previa a la presentación se activa ante una excepción: un salto de rotación, una discrepancia entre plantilla y nóminas, la falta de datos de categoría o sexo en la brecha, una brecha superior al 6% sin justificar o una predicción de baja confianza.

## De un vistazo

- Genera el reporte CSRD (indicadores ESRS S1) en formato electrónico, con verificación del auditor a partir de 250 empleados.
- Cubre el estado de información no financiera (Ley 11/2018, desde 500 empleados) y, en cotizadas, el Código de Buen Gobierno de la CNMV.
- Aplica la igualdad retributiva del Estatuto de los Trabajadores y del RD 902/2020: auditoría cada tres años, ratio de brecha del 6% y registro retributivo obligatorio.
- Trata los datos de forma agregada y anonimizada conforme al RGPD, con evaluación de impacto.
- Produce el análisis predictivo de rotación, el reporte de diversidad, las correlaciones de compromiso y el retorno de la inversión en RRHH.
- Genera el reporte trimestral para el Consejo y los cuadros de mando para la dirección, el Comité de Auditoría y el de Nombramientos y Retribuciones.
- Las sanciones por incumplimiento son acumulables: AEPD (hasta el 4%), inhabilitación del auditor, Inspección de Trabajo (hasta 187.515 euros), Ley 2/2023 (hasta un millón) y responsabilidad ilimitada de los administradores.

### Distribución de Decididores Strategic-HR-Analytics

| Decisor | Numero decisiones | Porcentaje | Tipo |
|---------|-------------------|------------|------|
| Determinista (R) | 14 | 82% | Genera los indicadores CSRD, la información no financiera, la auditoría retributiva, el reporte de diversidad, el análisis predictivo y el reporte para el Consejo |
| Indicador asistido por IA (A) | 2 | 12% | Valida la plausibilidad de los datos y la sincronización entre sistemas |
| Confirmación humana (H) | 1 | 6% | Aprobación final del análisis y presentación al Comité de Auditoría, a cargo del CHRO, el CFO y el Director ESG |

--- Agente Planificación Sucesión ---
> Planificación sucesión 9-Box-Grid: LSC art. 224-226 administradores, CNMV Buen Gobierno, RGPD art. 22 decisión automatizada y ESCO/MECES/INCUAL - Hi-Po identification con Bias-Audit.

La planificación de la sucesión en España se sitúa en la intersección de seis regímenes paralelos. La Ley de Sociedades de Capital fija los deberes de los administradores y su responsabilidad civil ilimitada (art. 224-226 y 236-237). El Código de Buen Gobierno de la CNMV recomienda una política y un plan de sucesión, bajo el principio de cumplir o explicar. El Estatuto de los Trabajadores y la Ley de Igualdad exigen la sucesión paritaria del 40-60% y la valoración objetiva del RD 902/2020. El RGPD prohíbe las decisiones individuales automatizadas y obliga a una evaluación de impacto. La Ley 11/2018 incluye la política de sucesión en el estado de información no financiera, y los marcos de cualificaciones ESCO, MECES e INCUAL ordenan las competencias. En la práctica, cualquier ciclo de sucesión en una empresa de mediana o gran dimensión activa a la vez varias de estas obligaciones, ante la CNMV, la AEPD, la Inspección de Trabajo, el ICAC y el auditor.

## Planificación sucesión como obligación strategic compliance

La planificación de la sucesión es un proceso muy reglado, pero en muchas empresas sigue ejecutándose como una presentación anual improvisada por el CHRO. La Ley de Sociedades de Capital fija los deberes de diligencia y lealtad de los administradores y su responsabilidad civil ilimitada (art. 224-226 y 236-237). El Código de Buen Gobierno de la CNMV recomienda una política de sucesión escrita aprobada por el Consejo, un plan documentado por el Comité de Nombramientos y Retribuciones y una evaluación periódica de los candidatos, bajo el principio de cumplir o explicar. La Ley 11/2018 incluye la política de sucesión en el estado de información no financiera, con verificación del auditor a partir de 250 empleados. Y sin embargo el proceso opera a mano: una presentación anual, una matriz de 9 casillas en una hoja de cálculo, una evaluación subjetiva del responsable, un plan de desarrollo en Word y un mapa de riesgo improvisado. Una empresa de 3.000 empleados gestiona cada año entre 200 y 500 puestos clave. El agente automatiza el 90% del proceso y solo deja en manos humanas la aprobación final del nombramiento, a cargo del Comité de Nombramientos y Retribuciones y del Consejo.

## La responsabilidad de los administradores y el Buen Gobierno de la CNMV

La Ley de Sociedades de Capital establece el marco de gobernanza de la sucesión. Los administradores tienen un deber de diligencia (art. 225) y de lealtad al interés social (art. 226), y su responsabilidad civil es ilimitada (art. 236-237), con acción social e individual. Un reporte falso puede acarrear responsabilidad penal (Código Penal art. 290). El Código de Buen Gobierno de la CNMV recomienda una política de sucesión escrita aprobada por el Consejo, un plan documentado por el Comité de Nombramientos y Retribuciones y una evaluación periódica de las capacidades de los candidatos, todo bajo el principio de cumplir o explicar. A partir de 250 empleados, la verificación del auditor es obligatoria, y su incumplimiento puede acarrear la inhabilitación del auditor y una sanción a la empresa de hasta 12 millones de euros.

## Igualdad en la sucesión y el precedente Mobley contra Workday

El Estatuto de los Trabajadores garantiza la igualdad de oportunidades (art. 17), el derecho a la promoción profesional (art. 23) y la movilidad funcional (art. 39). La Ley de Igualdad obliga al Plan de Igualdad desde 50 empleados y a la composición paritaria del 40-60% por sexo en el Consejo (art. 75), y el RD 902/2020 impone la valoración objetiva por trabajo de igual valor, la auditoría retributiva cada tres años y un umbral de brecha del 6%. El caso Mobley contra Workday (2024) sentó en EE. UU. el precedente de una demanda colectiva por sesgo de la IA en el cribado de candidatos. Por eso, los criterios de preparación y de alto potencial son objetivos y sin sesgo de género: competencias técnicas y de liderazgo, experiencia, cualificación según ESCO, MECES e INCUAL, valoración del desempeño y feedback 360. La Inspección de Trabajo puede sancionar el incumplimiento con hasta 187.515 euros.

## Protección de datos y consulta al Comité de Empresa

El RGPD ampara el tratamiento de los datos en la planificación de la sucesión en el interés legítimo y en una obligación legal (LSC art. 224-226). Su art. 22 prohíbe las decisiones individuales automatizadas con efectos significativos sobre el nombramiento, la retribución o la carrera, salvo base jurídica con salvaguardas adecuadas; por eso el agente solo aporta un indicador agregado. Obliga además a un registro de tratamiento (art. 30), al cifrado (art. 32) y a una evaluación de impacto (art. 35). El Comité de Empresa tiene derecho a ser informado y consultado sobre los cambios estructurales de la sucesión (ET art. 64 y 65), y el canal de denuncias (Ley 2/2023), obligatorio desde 50 empleados, cubre el favoritismo en los nombramientos. La AEPD puede sancionar con hasta el 4% de la facturación mundial o 20 millones de euros.

## Los marcos de cualificaciones y el uso de la IA

ESCO es la clasificación europea de ocupaciones y competencias; el MECES (RD 1027/2011) define los niveles 1 a 4 de la educación superior española; y el INCUAL mantiene el Catálogo Nacional de Cualificaciones Profesionales. El agente alinea contra ellos la clasificación profesional del convenio (ET art. 22) y los criterios objetivos de preparación y de alto potencial, sin sesgo de género (Ley de Igualdad; ET art. 17). El Reglamento de IA de la UE contempla el empleo y la sucesión como un posible ámbito de alto riesgo, pero aquí la planificación se mantiene como indicador agregado, con la decisión final en manos del CHRO, el Comité de Nombramientos y Retribuciones y el Consejo. El precedente Mobley contra Workday y el art. 22 del RGPD refuerzan la cautela frente al sesgo, y el componente requiere una evaluación de impacto (RGPD art. 35) y consulta al DPO.

## Integración con Skills-Career-Profile, Promotion-Process y Workforce-Planning

Cuatro agentes operan en la estrategia de talento con focos complementarios. El Skills-Career-Profile-Agent gestiona el perfil de competencias y el itinerario individual; el Promotion-Process-Agent, los ascensos con criterios objetivos (puede ser de alto riesgo); y el Workforce-Planning-Agent, la planificación de la capacidad y la proyección de plantilla. Este agente se ocupa de la sucesión en los puestos clave, con el pool de sucesores, la evaluación de la preparación, el alto potencial, los planes de desarrollo, el mapa de riesgo y la sucesión paritaria, sin decisiones individuales automatizadas. El de competencias le aporta el perfil para evaluar la preparación; el de promoción, el historial de ascensos para identificar el alto potencial; y el de planificación, la proyección de plantilla para el mapa de riesgo. A su vez, este agente reporta al Strategic-HR-Analytics-Agent y al Compensation-Benchmarking-Agent. La validación previa a la aprobación se activa ante una excepción: puestos clave sin sucesores listos, un banco de talento débil, una composición paritaria desviada, un alto potencial en riesgo de fuga o una concentración de conocimiento crítico.

## De un vistazo

- Se enmarca en los deberes de los administradores (LSC art. 224-226), cuya responsabilidad civil es ilimitada (art. 236-237).
- Cubre las recomendaciones de sucesión del Código de Buen Gobierno de la CNMV, bajo el principio de cumplir o explicar.
- En las cotizadas, la política de sucesión forma parte del estado de información no financiera (Ley 11/2018), con verificación del auditor a partir de 250 empleados.
- Aplica la igualdad del Estatuto de los Trabajadores, la sucesión paritaria del 40-60% (LO 3/2007 art. 75) y la valoración objetiva del RD 902/2020.
- Trata los datos conforme al RGPD, con evaluación de impacto, y respeta la prohibición de decidir automáticamente (art. 22); el precedente Mobley contra Workday acota el uso de la IA.
- Alinea las competencias con los marcos ESCO, MECES e INCUAL.
- Las sanciones por incumplimiento son acumulables: responsabilidad ilimitada de los administradores, inhabilitación del auditor, AEPD (4%), Inspección de Trabajo (187.515 euros) y Ley 2/2023 (hasta un millón).

### Distribución de Decididores Succession-Planning

| Decisor | Numero decisiones | Porcentaje | Tipo |
|---------|-------------------|------------|------|
| Determinista (R) | 11 | 85% | Identifica los puestos clave, mapea el pool, evalúa la preparación y el alto potencial, diseña los planes de desarrollo, ejecuta el mapa de riesgo y genera el reporte para el Consejo |
| Indicador asistido por IA (A) | 2 | 15% | Sincroniza los sistemas y valida la plausibilidad del plan y del banco de talento |
| Confirmación humana (H) | 1 | 8% | Aprobación final del plan y del nombramiento, a cargo del CHRO, el Comité de Nombramientos y Retribuciones y el Consejo |

--- Agente Talent Pool Management ---
> Gestión ciclo vida talent pool: ET art. 17 no discriminación, RGPD art. 6.1.a consentimiento, art. 22 decisión automatizada y retención 4 años ET - segmentación con Mobley v. Workday Bias-Audit.

La gestión del ciclo de vida de un talent pool en España se sitúa en la intersección de cinco regímenes paralelos. El RGPD distingue el consentimiento explícito del interés legítimo, veta las categorías especiales sin base jurídica, reconoce el derecho de supresión y prohíbe la decisión automatizada. La AEPD prioriza los datos laborales y fija los criterios de retención de candidatos rechazados (un año por interés legítimo, de dos a cuatro con consentimiento). El Estatuto de los Trabajadores y la Ley de Igualdad imponen la no discriminación y el Plan de Igualdad desde 50 empleados. Y el Reglamento de IA de la UE clasifica como de alto riesgo los sistemas de selección, con supervisión humana obligatoria, a la luz del precedente Mobley contra Workday. En la práctica, cualquier talent pool en una empresa de mediana o gran dimensión puede activar a la vez varias de estas obligaciones.

## Talent pool como trampa compliance entre RGPD y ET art. 17

Una empresa española de 1.500 empleados con una rotación anual del 12% suele acumular entre 600 y 1.200 perfiles de candidatos en su ATS. La realidad de un ATS con 800 perfiles es ilustrativa: 300 obsoletos (cambio de empleo, traslado o nueva cualificación), 200 sin consentimiento explícito (interés legítimo agotado al año), 150 con consentimiento vencido sin renovar, 100 que lo revocaron pero cuyo perfil persiste y 50 con datos de categoría especial en el CV (mención a salud, origen o religión) sin base jurídica. Las sanciones se acumulan: las de la AEPD (hasta el 4% de la facturación mundial o 20 millones de euros), las de la Inspección de Trabajo (hasta 187.515 euros), las de la Ley 2/2023 (hasta un millón) y la responsabilidad civil ilimitada de los administradores. La AEPD ya ha impuesto sanciones millonarias por consentimientos defectuosos, retención excesiva e incumplimiento de las solicitudes de acceso. En una empresa de mediana o gran dimensión, el total puede superar los 10 millones de euros.

## Consentimiento y derecho al olvido

El agente verifica la base jurídica de cada perfil antes de mantenerlo en el pool: el consentimiento explícito del candidato (art. 6.1.a), libre y revocable, preferido para retener más de un año, frente al interés legítimo (art. 6.1.f), limitado al periodo de selección y a un año tras el rechazo. El consentimiento es granular: separado del de marketing, con baja clara en cada comunicación, revocación sin fricción y un audit-trail completo. La renovación se avisa de forma escalonada 90, 60 y 30 días antes de vencer; sin respuesta, el perfil se purga al vencimiento. El derecho al olvido permite al candidato pedir el borrado en cualquier momento y sin justificación (art. 17), que la empresa ejecuta en un mes (art. 12), y la oposición o revocación (art. 21) provoca la purga inmediata. Las categorías especiales (salud, origen étnico, religión, orientación sexual, afiliación sindical) no pueden almacenarse sin base jurídica; detectores de lenguaje natural las identifican en los CV y las anonimizan. La AEPD ya ha sancionado con millones de euros los consentimientos defectuosos, la retención excesiva y el almacenamiento de categorías especiales sin base jurídica.

## No discriminación y retención de candidatos

El agente integra los derechos básicos del Estatuto de los Trabajadores (intimidad y dignidad, art. 4), la prohibición de discriminación (art. 17, por género, raza, religión, orientación sexual, edad, discapacidad o afiliación sindical) y el derecho del Comité de Empresa a conocer el sistema (art. 64). Aplica los criterios de la AEPD sobre la retención de candidatos rechazados: un año por interés legítimo, de dos a cuatro con consentimiento renovable, con un máximo de cuatro. Cuando un candidato presenta indicios suficientes de discriminación, la carga de la prueba pasa a la empresa (LRJS art. 96); por eso se conserva durante el plazo de prescripción la documentación anonimizada del proceso - criterios, decisiones, razones del rechazo y audit-trail - , no el perfil del candidato. La discriminación grave en el acceso al empleo es delito (Código Penal art. 314). El Plan de Igualdad, obligatorio desde 50 empleados, incluye la auditoría de la política de selección del talent pool.

## El matching de talento con IA y el precedente Mobley contra Workday

El agente queda bajo el Anexo III.4.a del Reglamento de IA de la UE, que clasifica como de alto riesgo los sistemas de empleo y gestión de trabajadores, incluido el cribado y el matching de candidatos. Esto conlleva obligaciones de alfabetización en IA (art. 4), transparencia sobre las capacidades, los límites y los sesgos detectados (art. 13), supervisión humana significativa y no meramente formal - la Dirección de RRHH revisa el resultado, decide el contacto y puede anularlo - (art. 14), precisión y robustez (art. 15) y las del desplegador, con registro de logs, evaluación de impacto y notificación de incidentes graves (art. 26). El caso Mobley contra Workday (2024) sentó el precedente de que los candidatos rechazados sistemáticamente por edad, raza o discapacidad pueden demandar al empleador junto con el proveedor de la IA; el empleador no puede escudarse en que "es un problema del proveedor", porque le obligan tanto el Reglamento de IA como la inversión de la carga de la prueba (LRJS art. 96). De ahí la auditoría de sesgo periódica e independiente y las cláusulas contractuales tipo con el proveedor. El art. 22 del RGPD prohíbe la decisión automatizada con efectos jurídicos: el mapeo propone un ranking, pero nunca contacta al candidato de forma automática.

## Engagement y reactivación de candidatos

El agente gestiona el engagement con reglas claras: como máximo un contacto cada tres meses para no caer en spam, por el canal que prefiera el candidato, con contenido segmentado por seniority, competencia y ubicación, una baja clara en cada comunicación (LSSI-CE art. 21 y 22) y el consentimiento de marketing separado del consentimiento del pool (RGPD art. 7). Para reactivar a los candidatos dormidos - sin contacto durante más de 12 meses - comprueba que su consentimiento sigue vigente y que sus competencias encajan con una nueva vacante, y les envía un correo personalizado con el recordatorio del proceso anterior, la nueva oportunidad y la renovación del consentimiento si procede; sin respuesta en 30 días, espera seis meses. El mapeo de talento frente a vacantes extrae los requisitos del puesto, hace el matching semántico y propone un ranking por afinidad, fecha del último contacto, disponibilidad y ubicación, con auditoría de sesgo y evaluación de impacto. La Dirección de RRHH revisa la lista y decide el contacto; nunca es automático (RGPD art. 22).

## Integración con Candidate-Screening, Pre-Hire-Due-Diligence e Interview-Scheduling

El agente es la fuente única de verdad del talent pool y propone los perfiles que otros agentes del proceso utilizan: el Candidate-Screening-Agent evalúa las competencias, la experiencia y la entrevista preliminar con un scoring estructurado; el Pre-Hire-Due-Diligence-Agent verifica los antecedentes y las referencias con un consentimiento específico para esa diligencia; y el Interview-Scheduling-Agent coordina las entrevistas. El flujo está integrado de extremo a extremo: el pool entrega el perfil, la afinidad, el historial y el consentimiento; el cribado evalúa y recomienda; la diligencia verifica; la programación coordina; y, más adelante, se emite la oferta y se inicia la incorporación. Todo el proceso deja un audit-trail con la documentación anonimizada de los criterios, las decisiones y las razones del rechazo. El agente se integra por API con las plataformas españolas más extendidas (A3, Sage, Cegid, Bizneo, Holded, Factorial, SAP SuccessFactors, Workday, Oracle, Personio), con los principales ATS (Greenhouse, Lever, iCIMS) y con los portales de empleo del mercado.

## De un vistazo

- 12 decisiones deterministas, 2 indicadores asistidos por IA y 1 punto de confirmación humana.
- Da de alta a cada candidato con su consentimiento documentado (RGPD art. 6.1.a) y su registro de tratamiento.
- Verifica la conformidad con la no discriminación (ET art. 17) y el Plan de Igualdad antes de segmentar.
- Segmenta por competencias contra ESCO, con auditoría de sesgo a la luz del precedente Mobley contra Workday.
- Retiene conforme a los criterios de la AEPD (un año por interés legítimo, de dos a cuatro con consentimiento) y purga automáticamente.
- Gestiona el engagement con un contacto cada tres meses como máximo, baja clara y consentimiento de marketing separado.
- Propone los candidatos para cada vacante con supervisión humana significativa, sin contacto automático (RGPD art. 22).
- Responde las solicitudes de acceso, supresión, portabilidad y revocación en el plazo de un mes, con audit-trail.
- Las sanciones por incumplimiento son acumulables: AEPD (4%), Inspección de Trabajo (187.515 euros) y Ley 2/2023 (hasta un millón).

### Distribucion de Decididores Talent-Pool-Management

| Tipo | Decisiones |
|----------|----------|
| 12 deterministas | Alta con consentimiento, conformidad con el ET y la Ley de Igualdad, vigilancia del consentimiento, engagement, reactivación, solicitudes de acceso, categorías especiales, purga, integración con otros agentes y Plan de Igualdad |
| 2 indicadores asistidos por IA | Segmentación por competencias y mapeo de candidatos frente a vacantes |
| 1 confirmación humana | Escalado a la Dirección de RRHH ante cambios de política, modelos o proveedores y respuestas a la AEPD |

--- Agente RRHH Seguridad Social ---
> Flujo HR Seguridad Social: alta inicial TGSS Sistema RED, elección Mutua Colaboradora, datos empleado modelo 145 IRPF y cambio escala 19%-47% - audit-trail compliance.

Las declaraciones tributarias y las cotizaciones a la Seguridad Social en España se sitúan en la intersección de cinco regímenes paralelos. La Ley del IRPF regula el modelo 111 trimestral, el 190 anual y la escala de 2026 (del 19% al 47%), ante la AEAT. La Ley General de la Seguridad Social fija las cotizaciones de empresa y trabajador a través del Sistema RED de la TGSS. El Mecanismo de Equidad Intergeneracional añade una cotización adicional para el periodo 2026-2032. La cotización por accidentes de trabajo varía según la actividad de la empresa (CNAE). Y la empresa debe entregar a cada empleado su certificado de retenciones (LGT art. 105) antes de la campaña de la renta. En la práctica, cualquier ciclo de declaraciones en una empresa de mediana o gran dimensión activa a la vez varias de estas obligaciones, ante la AEAT, la Inspección de Trabajo, el ICAC, la TGSS y el auditor.

## Declaraciones, cotizaciones y certificados a tiempo

Las declaraciones tributarias y la cotización a la Seguridad Social son un proceso muy reglado, pero en muchas empresas se ejecuta como semanas de Excel trimestral. La Ley del IRPF regula los modelos 111, 190 y siguientes; la Ley General de la Seguridad Social determina las cotizaciones a través del Sistema RED; el Mecanismo de Equidad Intergeneracional fija la cotización adicional para 2026-2032; y la empresa debe entregar el certificado de retenciones a cada empleado. Ningún paso requiere interpretación. Y sin embargo el proceso opera a mano: los datos llegan en exportaciones de Excel, las retenciones se cuadran en una hoja de cálculo y los certificados se emiten uno a uno en Word. Una empresa de 1.500 empleados genera cada trimestre el modelo 111, el 190 anual, la cotización mensual al Sistema RED y unos 1.500 certificados al año. El agente automatiza el 90% del proceso y solo deja en manos humanas la aprobación final y la presentación, a cargo del CFO, el responsable de nóminas y el Comité de Auditoría.

## El IRPF: del modelo 111 trimestral al 190 anual

La Ley del IRPF y su reglamento establecen el modelo 111 trimestral y el 190 anual. El 111 se presenta en los 20 días siguientes al cierre de cada trimestre, con el desglose de las retribuciones dinerarias y en especie. El 190 se presenta antes del 31 de enero del año siguiente, con el desglose por empleado: la base imponible, la reducción por rendimientos del trabajo, el mínimo personal y familiar, la retención acumulada y la clave de perceptor. El cuadre entre ambos es obligatorio: la suma de los cuatro trimestres debe igualar el total anual. A ellos se suman el modelo 145, en el que el empleado comunica su situación familiar y que determina el tipo de retención, y el modelo 296 de retenciones a no residentes. La empresa debe entregar el certificado de retenciones (LGT art. 105) antes de que empiece la campaña de la renta. Todo se presenta por la sede electrónica de la AEAT. Presentar fuera de plazo o con errores puede acarrear un recargo sobre la deuda del 25% al 150%, y una deuda superior a 120.000 euros, un procedimiento penal por delito fiscal con prisión de 1 a 6 años (Código Penal art. 305).

## Las cotizaciones a la Seguridad Social y el Mecanismo de Equidad Intergeneracional

La Ley General de la Seguridad Social y el Sistema RED de la TGSS gestionan las cotizaciones de empresa y trabajador. La empresa cotiza por contingencias comunes (23,6%), desempleo, FOGASA, formación, accidentes (un tipo variable según el CNAE) y el Mecanismo de Equidad Intergeneracional; el trabajador, por contingencias comunes (4,7%), desempleo, formación y ese mismo mecanismo. El Sistema RED gestiona también las altas y bajas, y las cotizaciones se presentan como muy tarde el último día del mes siguiente, con un recargo de mora del 5% al 20% por el retraso. El Mecanismo de Equidad Intergeneracional (Real Decreto-ley 2/2023) es una cotización adicional para la sostenibilidad de las pensiones: el 0,5% a cargo de la empresa y el 0,1% del trabajador en 2026, con un escalado progresivo. La cotización por accidentes de trabajo varía según la actividad de la empresa, desde el 0,9% en oficinas hasta el 7,15% en la construcción, la minería o la pesca. La Inspección de Trabajo puede sancionar el incumplimiento con hasta 225.018 euros, y su plan de acción prioriza las cotizaciones y los falsos autónomos.

## Protección de datos y consulta al Comité de Empresa

El RGPD ampara el tratamiento de los datos de los empleados en una obligación legal tributaria y de Seguridad Social, y obliga a un registro de tratamiento (art. 30), al cifrado (art. 32), a comunicar las brechas en 72 horas (art. 33-34) y a una evaluación de impacto del componente fiscal (art. 35). La AEPD prioriza los datos laborales y puede sancionar con hasta el 4% de la facturación mundial o 20 millones de euros. El Comité de Empresa tiene derecho a ser informado y consultado (ET art. 64 y 65) sobre cualquier cambio material del sistema: un cambio en la metodología de cálculo de la retención, en la escala del IRPF o en el tipo del Mecanismo de Equidad Intergeneracional, o una discrepancia material entre los modelos 111 y 190. El canal de denuncias (Ley 2/2023) es obligatorio desde 50 empleados. La documentación se conserva conforme a los plazos de prescripción aplicables, de cuatro a seis años en general.

## Integración con Payroll-Processing, Payroll-Accounting y Payroll-Reporting

Cuatro agentes operan en la nómina con focos complementarios. El Payroll-Processing-Agent calcula el bruto a neto de forma determinista (estructura salarial, escala de IRPF de 2026, cotizaciones y recibo de salarios). El Payroll-Accounting-Agent genera los asientos contables a partir de los resultados de la nómina. El Payroll-Reporting-Agent produce los reportes regulatorios y las declaraciones anuales, como el modelo 190 y la auditoría retributiva. Este agente genera las declaraciones tributarias, las cotizaciones a la Seguridad Social y los certificados de retención: los modelos de la AEAT, las cotizaciones al Sistema RED de la TGSS, el Mecanismo de Equidad Intergeneracional y la cotización por accidentes, dentro de los plazos de la AEAT y de la TGSS. El de cálculo le aporta los resultados, y él alimenta a su vez al de reporte y al de contabilización. La validación previa a la presentación se activa ante una excepción: un salto de la retención de IRPF frente al trimestre anterior, una discrepancia entre las cotizaciones y el Sistema RED, la falta de datos de categoría profesional o un tipo de retención que no encaja con el modelo 145.

## De un vistazo

- Genera el modelo 111 trimestral, el 190 anual y los modelos 145, 296, 230 y 234 de la AEAT, presentados por la sede electrónica.
- Genera las cotizaciones de empresa y trabajador a través del Sistema RED de la TGSS.
- Aplica el Mecanismo de Equidad Intergeneracional (0,5% de la empresa y 0,1% del trabajador en 2026-2032, con escalado progresivo).
- Calcula la cotización por accidentes de trabajo según la actividad de la empresa (CNAE) y la tarifa de primas.
- Genera el certificado de retenciones de cada empleado, que la empresa debe entregar antes de la campaña de la renta.
- Realiza el cuadre obligatorio entre los cuatro modelos 111 trimestrales y el 190 anual.
- Las sanciones por incumplimiento son acumulables: AEAT (del 25% al 150% de la deuda), delito fiscal (prisión de 1 a 6 años), Inspección de Trabajo y recargo de mora de la Seguridad Social.

### Distribucion de Decididores Tax-Social-Insurance

| Decisor | Numero decisiones | Porcentaje | Tipo |
|---------|-------------------|------------|------|
| Determinista (R) | 12 | 80% | Genera los modelos de la AEAT, las cotizaciones al Sistema RED, el Mecanismo de Equidad Intergeneracional, la cotización por accidentes y los certificados, y realiza el cuadre entre el 111 y el 190 |
| Indicador asistido por IA (A) | 2 | 13% | Valida la plausibilidad de los datos y la sincronización entre sistemas |
| Confirmación humana (H) | 1 | 7% | Aprobación final y presentación telemática ante la AEAT y la TGSS, a cargo del CFO, el responsable de nóminas y el Comité de Auditoría |

--- Agente Control Horario ---
> Validación control horario: ET art. 34.9 registro diario, RD-ley 8/2019 transposición CCOO 14.5.2019 y RD-ley 6/2024 reducción 37,5h - alertas anomalías y detección incumplimientos.

El control horario en España vive en el cruce de varios regímenes a la vez. El Estatuto de los Trabajadores regula la jornada (art. 34), el registro diario obligatorio (art. 34.9), las horas extras (art. 35), el trabajo nocturno (art. 36) y los descansos (art. 37), y reconoce al comité de empresa el derecho a ser informado (art. 64). El Real Decreto-ley 6/2024 reduce la jornada legal a 37,5 horas semanales desde 2025. A esto se suman más de 5.500 convenios sectoriales con sus complementos y la protección de datos del art. 88 RGPD. La consecuencia es clara: cualquier empresa de tamaño medio o grande que lleve el registro en un Excel sin validación legal puede activar a la vez varias obligaciones de cumplimiento distintas.

## El registro de jornada es obligatorio desde 2019

Una empresa con 1.500 empleados procesa entre 540.000 y 720.000 fichajes al año. Cada marca encadena varias comprobaciones: identificar al trabajador, validar el método de registro, enlazar el expediente, calcular la jornada efectiva, verificar los descansos y, si hay horas extras, comunicarlas a la Seguridad Social e informar al comité de empresa. En la práctica, el proceso manual acumula problemas: un Excel sin historial, dispositivos sin integrar con el sistema de personal, biometría sin consentimiento, geolocalización sin información previa, horas extras que nunca se comunican y descansos que no se respetan.

El riesgo económico es real y se acumula: la Inspección de Trabajo llega hasta 187.515 euros por incumplir el registro, la AEPD hasta el 4 % de la facturación y un accidente por descansos incumplidos puede recargar las prestaciones hasta un 50 %. Desde la sentencia del Tribunal de Justicia de la UE en el caso CCOO (C-55/18), de mayo de 2019, la presunción juega a favor del trabajador cuando el sistema de control horario es deficiente o inexistente: el art. 96 de la Ley de la Jurisdicción Social hace recaer la carga de la prueba en la empresa.

## La jornada de 37,5 horas tras el Real Decreto-ley 6/2024

El agente clasifica cada marca de forma determinista en uno de cuatro tipos: entrada, salida, pausa (que no computa) y reanudación. Sobre esa base aplica el marco temporal: el art. 34 ET fija la jornada en cómputo anual y permite distribuirla de forma irregular hasta un 10 %, y el Real Decreto-ley 6/2024 la reduce a 37,5 horas semanales desde 2025 (38,5 en 2024). Para validar, cruza el expediente, el contrato vigente, el convenio aplicable y la jornada teórica diaria, semanal y anual.

El tiempo de trabajo efectivo se calcula descontando pausas, permisos retribuidos, bajas y vacaciones. La distribución irregular se gestiona con una bolsa de horas por trabajador, que exige informar al comité de empresa, avisar con cinco días de antelación y respetar los descansos legales. Es una fuente de error frecuente: si se supera el 10 % de la jornada anual, no se avisa con tiempo o se rompen las 12 horas de descanso entre jornadas, el sistema activa una alerta y la eleva a Recursos Humanos.

## Convenios colectivos: nocturnidad, festividad y turnicidad

El agente integra el convenio colectivo aplicable y calcula los complementos que de él se derivan. El art. 36 ET regula el trabajo nocturno (entre las 22:00 y las 6:00), con un máximo de ocho horas diarias de media, retribución específica, reconocimientos médicos periódicos y protección reforzada para menores, embarazo y lactancia. El art. 37 ET cubre los descansos y los festivos. Los porcentajes de nocturnidad, festividad o turnicidad los fija cada convenio sectorial, igual que los pluses de penosidad o peligrosidad propios de sectores como la industria química, la minería o la construcción.

El cálculo automático combina los fichajes, el horario del trabajador y el calendario laboral con sus festivos nacionales, autonómicos y locales. Las horas extras siguen el art. 35 ET: límite de 80 al año, carácter voluntario y retribución equivalente como mínimo a una hora ordinaria. Conforme a la sentencia Matzak del Tribunal de Justicia de la UE, el tiempo de guardia computa como jornada cuando restringe de forma efectiva la disponibilidad del trabajador. El resultado, con horas extras y complementos consolidados, alimenta el cálculo mensual de la nómina.

## Protección de datos y derechos del comité de empresa

Los datos de registro horario son datos de empleados (art. 88 RGPD), tratados sobre la base de la obligación legal del art. 34.9 ET y de la ejecución del contrato. La huella y el reconocimiento facial son datos biométricos de categoría especial (art. 9 RGPD): solo pueden usarse con consentimiento explícito y una alternativa no biométrica disponible, como un PIN o una tarjeta. La geolocalización de dispositivos móviles exige información previa al trabajador (art. 90 LOPDGDD) y limitarse a la jornada laboral. El agente impone por diseño la minimización: registra entradas y salidas sin datos sensibles innecesarios.

El propio trabajador, sus representantes y la Inspección de Trabajo pueden acceder al registro, que se conserva cuatro años con cifrado y trazabilidad de accesos. Los sistemas con biometría o geolocalización requieren una Evaluación de Impacto en Protección de Datos. Esta arquitectura no es una opción técnica, sino un requisito estructural: quien implanta biometría sin consentimiento o geolocalización sin avisar tiene un problema de protección de datos aunque nadie lo busque. Por el art. 64 ET, el comité de empresa debe ser informado de forma previa sobre el sistema de control horario, los criterios de horas extras, la distribución de la jornada y los descansos; la Sala IV del Tribunal Supremo confirma que esa información ha de ser previa.

## Conexión con nóminas, bajas y permisos

El agente sincroniza el control horario con los demás agentes del Decision Layer. El de nóminas calcula la retribución mensual con las horas extras y los complementos; el de bajas confirma que los días de incapacidad temporal no computan como jornada y aporta la base reguladora de la prestación; y el de permisos y excedencias gestiona las ausencias retribuidas del art. 37 ET. El registro se archiva durante cuatro años y queda disponible para responder a una solicitud de acceso del trabajador (art. 15 RGPD). Los desgloses por sexo conectan con el análisis de la brecha salarial por horas extras y complementos.

La gestión de un incumplimiento sistemático de descansos no la inicia el agente: comunica la detección a Recursos Humanos, al Servicio de Prevención y al comité de empresa, y son las personas quienes deciden las medidas correctoras. No es una limitación técnica, sino una decisión deliberada: la organización del tiempo de trabajo es una conversación sobre condiciones laborales y carga de trabajo, y ningún algoritmo decide cuándo intervenir. El agente se integra por API con las plataformas españolas más extendidas (A3, Sage, Cegid, Bizneo, Holded, Factorial, Sesame), con suites internacionales (SAP SuccessFactors, Workday, Oracle, Personio, ADP), con dispositivos de fichaje y con el Sistema RED de la Seguridad Social.

## De un vistazo

- 11 decisiones deterministas y 3 indicadores asistidos por aprendizaje automático: 14 microdecisiones de control horario.
- Registro de jornada obligatorio (art. 34.9 ET), conservado durante cuatro años.
- Jornada legal de 37,5 horas semanales desde 2025 (Real Decreto-ley 6/2024), con distribución irregular de hasta el 10 %.
- Cálculo de horas extras (art. 35 ET), con límite de 80 al año y comunicación mensual a la Seguridad Social.
- Complementos de nocturnidad, festividad y turnicidad según el convenio colectivo aplicable.
- Verificación de descansos (arts. 34 y 37 ET y Directiva 2003/88): 12 horas entre jornadas, día y medio semanal y pausa de 15 minutos.
- Protección de datos (art. 88 RGPD), con evaluación de impacto para biometría y geolocalización.
- Información al comité de empresa (art. 64 ET) y desgloses para el plan de igualdad (RD 901/2020).
- Sanciones acumulables: Inspección de Trabajo hasta 187.515 euros, AEPD hasta el 4 % y recargo de prestaciones hasta el 50 %.

| Distribución de decisores en el control horario |
|----------|
| 11 decisiones deterministas: recepción y validación de marcas, enlace con el expediente, cálculo de jornada, horas extras, complementos, descansos, acuerdos de jornada irregular, información al comité de empresa y sincronización con otros agentes. |
| 3 indicadores asistidos por aprendizaje automático: detección de anomalías en los fichajes, comunicación a la Seguridad Social y detección de incumplimientos sistemáticos de descansos, horas extras o riesgos psicosociales. |
| Ninguna confirmación humana estructural, porque el flujo no afecta a la relación laboral; las escalaciones concretas se detallan en las notas de gobernanza. |

--- Agente Eficacia Formación ---
> Medición eficacia formativa: Kirkpatrick 4 niveles, Phillips ROI Methodology nivel 5, ET art. 23 promoción y formación, Fundae bonificaciones y ESRS S1-13 - integración LMS con audit-trail.

La medición de la eficacia formativa en España convive con varios marcos a la vez. Por un lado, los métodos consolidados: los cuatro niveles de Kirkpatrick y la metodología ROI de Phillips, apoyados en los marcos de cualificaciones ESCO, MECES e INCUAL. Por otro, la normativa: el art. 23 ET reconoce el derecho a la formación, la LO 5/2002 y la Ley 30/2015 ordenan las bonificaciones de Fundae, el art. 88 RGPD protege los datos de los empleados y la CSRD obliga a reportar el indicador ESRS S1-13. La consecuencia es que cualquier ciclo de medición en una empresa de tamaño medio o grande puede activar a la vez obligaciones ante la AEPD, la Inspección de Trabajo, Fundae y el auditor.

## Medir la eficacia con Kirkpatrick y el ROI de Phillips

Medir la eficacia de la formación es un proceso muy reglado, pero en muchas empresas todavía se resuelve con un cuestionario en Excel al terminar el curso. El modelo de Kirkpatrick y la metodología de Phillips definen cinco niveles. El primero, de reacción, mide la satisfacción de los participantes con una escala Likert, un índice de recomendación y la calidad percibida del formador. El segundo, de aprendizaje, compara conocimientos antes y después y mapea las competencias en ESCO y MECES. El tercero, de comportamiento, observa el cambio en el puesto de trabajo a los 90 días, 6 meses y un año. El cuarto vincula la formación con indicadores de negocio como la productividad o la reducción de defectos.

El quinto nivel, el ROI de Phillips, expresa en dinero la relación entre los beneficios de la formación y su coste. Para aislar el efecto de la formación frente a otros factores se usan grupos de control y estimaciones de expertos. El coste total reúne gastos directos e indirectos y descuenta las bonificaciones de Fundae, y los beneficios intangibles se reportan aparte. Una empresa de 3.000 empleados genera todo esto cada trimestre. El agente automatiza alrededor del 90 % del proceso; la aprobación final y la presentación al comité de empresa siguen en manos de la dirección de Formación y de Recursos Humanos.

## Formación profesional: LO 5/2002, Ley 30/2015 y Fundae

La LO 5/2002 ordena el Sistema Nacional de Cualificaciones y crea el Catálogo Nacional de Cualificaciones Profesionales, gestionado por el INCUAL. La Ley 30/2015 regula la formación profesional para el empleo, sus iniciativas formativas y las bonificaciones a la Seguridad Social, desarrollada por el RD 694/2017 y actualizada por el RD 282/2024. El catálogo organiza las cualificaciones en 26 familias profesionales y cinco niveles, y permite reconocer las competencias adquiridas por experiencia laboral mediante un procedimiento específico, cuya ejecución corresponde a las comunidades autónomas.

Fundae, la Fundación Estatal para la Formación en el Empleo, concede a cada empresa un crédito formativo anual, calculado sobre las cotizaciones por contingencias profesionales del año anterior. El inicio y la finalización de cada acción deben comunicarse en plazo a través de su plataforma. El control posterior se extiende cuatro años: permite recuperar las bonificaciones indebidas y, según el art. 17 de la Ley 30/2015, sancionar el fraude.

## Marcos de competencias y reporte de sostenibilidad

MECES es el marco español de cualificaciones para la educación superior, con cuatro niveles (técnico superior, grado, máster y doctorado) e integrado en el marco europeo EQF. ESCO es la clasificación europea de competencias y ocupaciones de la Comisión Europea, con casi 14.000 competencias y unas 3.000 ocupaciones en treinta idiomas, pensada para dar transparencia al mercado laboral. Mapear las competencias adquiridas sobre ambos marcos permite reconocerlas dentro y fuera de España.

La CSRD introduce el indicador ESRS S1-13 sobre formación y desarrollo de competencias, que pide reportar las horas de formación medias por empleado, el presupuesto formativo, el porcentaje de plantilla formada y la inversión en competencias estratégicas, todo desglosado por sexo, edad y categoría profesional. El acceso a la formación se cruza con el plan de igualdad del RD 901/2020. El reporte se despliega por fases desde el ejercicio 2025 y, en las empresas de más de 250 trabajadores, lo verifica un auditor; una verificación deficiente expone a sanciones del ICAC e incluso a la inhabilitación del auditor.

## Protección de datos y derechos del comité de empresa

Los datos de formación son datos de empleados (art. 88 RGPD). Su tratamiento se apoya en la obligación legal de la normativa de formación profesional y se reporta siempre de forma agregada y anonimizada, con un mínimo de individuos por celda para impedir reidentificar a nadie. Los sistemas analíticos requieren una Evaluación de Impacto en Protección de Datos, y los datos se cifran y se conservan de forma inalterable. El trabajador puede ejercer su derecho de acceso, que la empresa debe atender en el plazo de un mes.

Por el art. 64 ET, el comité de empresa tiene derecho a ser informado del plan de formación. Esa información ha de ser previa cuando cambia la metodología de medición, se adopta una nueva medida del plan de igualdad o se detecta una desviación significativa en el acceso de mujeres y hombres a la formación; el canal de denuncias se apoya en la Ley 2/2023. Las sanciones se acumulan: la AEPD puede llegar al 4 % de la facturación mundial y el fraude en las bonificaciones de Fundae se sanciona según el art. 17 de la Ley 30/2015.

## Relación con los demás agentes de formación

En el área de aprendizaje y desarrollo conviven cuatro agentes con focos distintos. El de perfil de competencias construye el perfil individual de cada empleado y su plan de carrera. El de evaluación del desempeño documenta las valoraciones individuales y puede ser de alto riesgo si afecta a la retribución variable. El de rutas de aprendizaje recomienda la formación personalizada. Este agente, en cambio, mide la eficacia de forma agregada con Kirkpatrick y el ROI de Phillips, y por eso no es de alto riesgo.

Los tres primeros aportan datos individuales que llegan a este agente ya agregados de forma anonimizada conforme al art. 88 RGPD, y desde aquí los resultados pasan a la analítica estratégica de Recursos Humanos. Antes de presentar nada, la validación se detiene si detecta un salto brusco de horas de formación, una discrepancia con el registro de Fundae, la ausencia de desgloses por sexo o categoría, un acceso a la formación desviado respecto al plan de igualdad o un ROI con poca fiabilidad.

## De un vistazo

- Los cuatro niveles de Kirkpatrick (reacción, aprendizaje, comportamiento y resultados) y el ROI monetario de Phillips.
- Derecho a la formación (art. 23 ET) e información al comité de empresa sobre el plan de formación (art. 64 ET).
- Formación profesional regulada por la LO 5/2002 y la Ley 30/2015, con las bonificaciones de Fundae y la acreditación del INCUAL.
- Competencias mapeadas sobre el marco español MECES y el europeo ESCO.
- Indicador ESRS S1-13 de la CSRD: horas medias de formación, porcentaje de plantilla formada y desgloses para el plan de igualdad (RD 901/2020).
- Protección de datos (art. 88 RGPD) con reporte agregado anonimizado y evaluación de impacto para la analítica.
- Sanciones acumulables: AEPD hasta el 4 % de la facturación, fraude en bonificaciones de Fundae hasta 187.515 euros e inhabilitación del auditor por el ICAC.

### Distribución de Decididores Training-Effectiveness

| Decisor | Numero decisiones | Porcentaje | Tipo |
|---------|-------------------|------------|------|
| Determinista | 14 | 82 % | Genera los niveles de Kirkpatrick y el ROI de Phillips, mapea competencias en ESCO y MECES, gestiona las bonificaciones de Fundae, produce el indicador ESRS S1-13 y los cuadros de mando, e informa al comité de empresa. |
| Indicador asistido por IA | 2 | 12 % | Valida la plausibilidad de los datos formativos y comprueba su sincronización entre plataformas. |
| Confirmación humana | 1 | 6 % | La dirección de Formación y de Recursos Humanos aprueba la medición y su presentación al comité de empresa. |

--- Agente Análisis Necesidades Formación ---
> Skills-Gap-Analysis y priorización L&D: ESCO/MECES/INCUAL marco cualificaciones, ET art. 23 20h anuales, Ley 30/2015 y Fundae bonificaciones - plan formativo determinista con audit-trail.

El análisis de necesidades de formación en España convive con varios marcos a la vez. Por un lado, el método: comparar las competencias actuales con las requeridas, apoyándose en los marcos de cualificaciones ESCO, MECES e INCUAL. Por otro, la normativa: el art. 23 ET reconoce el derecho a la formación, la LO 5/2002 y la Ley 30/2015 ordenan las bonificaciones de Fundae, y el art. 88 RGPD protege los datos de los empleados, que solo pueden tratarse de forma agregada y anonimizada. La consecuencia es que cualquier ciclo de análisis en una empresa de tamaño medio o grande puede activar a la vez obligaciones ante la AEPD, la Inspección de Trabajo, Fundae e INCUAL.

## Analizar las necesidades antes de proliferar cursos

Analizar las necesidades de formación es un proceso muy reglado, pero en muchas empresas todavía se resuelve con talleres intuitivos previos al plan. Lanzar cursos sin un análisis de brechas previo dispersa el presupuesto, deja sin usar las bonificaciones de Fundae y no cubre las brechas estratégicas. El agente automatiza alrededor del 85 % del análisis: compara las competencias actuales con las requeridas, incorpora las valoraciones de desempeño y los objetivos de negocio, y prioriza la inversión.

Las competencias actuales se toman de las plataformas de competencias y de las valoraciones de desempeño; las requeridas, de la descripción del puesto mapeada sobre el marco europeo ESCO. La brecha es la diferencia entre el nivel exigido y el actual, por competencia, empleado y puesto. La priorización combina la urgencia del negocio, la criticidad del puesto, el carácter estratégico de la competencia y el impacto en la prevención de riesgos, y produce una puntuación de 1 a 100. Una empresa de 3.000 empleados genera todo esto cada trimestre. El agente automatiza la mayor parte; la aprobación final del plan y su presentación al comité de empresa siguen en manos de la dirección de Formación y de Recursos Humanos.

## La taxonomía de competencias: MECES, ESCO e INCUAL

MECES es el marco español de cualificaciones para la educación superior, con cuatro niveles (técnico superior, grado, máster y doctorado) e integrado en el marco europeo EQF. ESCO es la clasificación europea de competencias y ocupaciones de la Comisión Europea, con casi 14.000 competencias y unas 3.000 ocupaciones en treinta idiomas. INCUAL gestiona el Catálogo Nacional de Cualificaciones Profesionales, actualizado por el RD 282/2024 y organizado en 26 familias profesionales y cinco niveles, cuya ejecución corresponde a las comunidades autónomas.

Cada necesidad formativa se mapea sobre el identificador de competencia de ESCO y su correspondencia en los niveles de MECES e INCUAL. Las plataformas de competencias, mediante aprendizaje automático, infieren de forma automática las competencias de cada persona. Los datos se desglosan por sexo, edad, categoría profesional y comunidad autónoma, en línea con el plan de igualdad del RD 901/2020.

## El derecho a la formación y las bonificaciones de Fundae

El Estatuto de los Trabajadores reconoce el derecho a la promoción y a la formación profesional (art. 23), la igualdad en el acceso a la formación (art. 28) y el derecho del comité de empresa a ser informado del plan de formación (art. 64). La LO 5/2002 ordena el Sistema Nacional de Cualificaciones y crea el Catálogo Nacional de Cualificaciones Profesionales, gestionado por el INCUAL, e integra la formación reglada, ocupacional y continua. La Ley 30/2015 regula la formación profesional para el empleo, sus iniciativas y las bonificaciones, y define cada año los sectores y colectivos prioritarios.

Fundae concede a cada empresa un crédito formativo anual, calculado sobre las cotizaciones por contingencias profesionales del año anterior. El plan de formación previo se alinea con esos sectores prioritarios, y el inicio y la finalización de cada acción deben comunicarse en plazo a través de su plataforma. El control posterior se extiende cuatro años: permite recuperar las bonificaciones indebidas y, según el art. 17 de la Ley 30/2015, sancionar el fraude.

## Protección de datos y derechos del comité de empresa

Los datos de competencias son datos de empleados (art. 88 RGPD). Su tratamiento se apoya en la obligación legal de la normativa de formación profesional y se reporta siempre de forma agregada y anonimizada, con un mínimo de individuos por celda para impedir reidentificar a nadie. Los sistemas analíticos requieren una Evaluación de Impacto en Protección de Datos, y los datos se cifran y se conservan de forma inalterable. El trabajador puede ejercer su derecho de acceso, que la empresa debe atender en el plazo de un mes.

Por el art. 64 ET, el comité de empresa tiene derecho a ser informado del plan de formación. Esa información ha de ser previa cuando cambia la metodología del análisis, se adopta una nueva medida del plan de igualdad o se detecta una desviación significativa en el acceso de mujeres y hombres a la formación; el canal de denuncias se apoya en la Ley 2/2023. Las sanciones se acumulan: la AEPD puede llegar al 4 % de la facturación mundial y el fraude en las bonificaciones de Fundae se sanciona según el art. 17 de la Ley 30/2015.

## Relación con los demás agentes de formación

En el área de aprendizaje y desarrollo conviven cuatro agentes con focos distintos. El de perfil de competencias construye el perfil individual de cada empleado y su plan de carrera. El de evaluación del desempeño documenta las valoraciones individuales y puede ser de alto riesgo si afecta a la retribución variable. El de eficacia formativa mide los resultados de forma agregada con Kirkpatrick y el ROI de Phillips. Este agente, en cambio, hace el análisis previo: detecta las brechas, las prioriza y propone el plan de formación, por lo que no es de alto riesgo.

Los agentes de perfil de competencias, desempeño y planificación de plantilla aportan datos individuales que llegan a este agente ya agregados de forma anonimizada conforme al art. 88 RGPD, y el plan resultante pasa al agente de eficacia formativa para su medición futura. Antes de presentar nada, la validación se detiene si detecta un salto brusco en las brechas, una discrepancia con las plataformas de competencias, la ausencia de desgloses por sexo o categoría, un acceso a la formación desviado respecto al plan de igualdad o un mapeo incompleto sobre ESCO.

## De un vistazo

- Análisis de brechas de competencias: diferencia entre el nivel exigido y el actual, por competencia, empleado, puesto y categoría profesional.
- Derecho a la formación (art. 23 ET) e información al comité de empresa sobre el plan de formación (art. 64 ET).
- Formación profesional regulada por la LO 5/2002 y la Ley 30/2015, con la planificación de las bonificaciones de Fundae y la acreditación del INCUAL.
- Competencias mapeadas sobre el marco español MECES y el europeo ESCO.
- Priorización de las brechas por urgencia de negocio, criticidad del puesto, carácter estratégico e impacto en la prevención: una puntuación de 1 a 100.
- Protección de datos (art. 88 RGPD) con reporte agregado anonimizado y evaluación de impacto para la analítica.
- Sanciones acumulables: AEPD hasta el 4 % de la facturación, fraude en bonificaciones de Fundae hasta 187.515 euros y responsabilidad ilimitada de los administradores.

### Distribución de Decididores Training-Needs-Analysis

| Decisor | Numero decisiones | Porcentaje | Tipo |
|---------|-------------------|------------|------|
| Determinista | 11 | 85 % | Genera el análisis de brechas y su priorización, mapea competencias en ESCO y MECES, planifica las bonificaciones de Fundae, recomienda la inversión, analiza la equidad de acceso y produce los cuadros de mando e informa al comité de empresa. |
| Indicador asistido por IA | 2 | 15 % | Valida la plausibilidad del análisis de brechas y comprueba su sincronización entre plataformas. |
| Confirmación humana | 1 | (incluida en las deterministas) | La dirección de Formación y de Recursos Humanos aprueba el análisis, el plan de formación y su presentación al comité de empresa. |

--- Agente Traslados y Reubicaciones ---
> Ciclo vida traslados y asignaciones internacionales: ET art. 40-42, Ley 11/2023 trabajadores desplazados, LO 4/2000 NIE/TIE, A1 SS y Ley Beckham art. 93 - orquestación cross-funcional auditable.

La gestión de los traslados y las reubicaciones en España convive con varios marcos a la vez. El Estatuto de los Trabajadores regula la movilidad geográfica (art. 40), la modificación sustancial de condiciones (art. 41) y el derecho de información del comité de empresa (art. 64). La Ley 11/2023 cubre a los trabajadores desplazados dentro de la UE, con las condiciones del país de acogida y la comunicación previa a la autoridad laboral. La LO 4/2000 de extranjería ordena los visados y permisos de trabajo. El Reglamento 883/2004 coordina la Seguridad Social mediante el certificado A1, y los convenios para evitar la doble imposición, junto con el régimen Beckham, fijan la tributación del expatriado. A todo ello se suma la protección de datos en las transferencias internacionales (arts. 44 a 49 RGPD). La consecuencia es que cualquier traslado o asignación internacional puede activar a la vez varias obligaciones de cumplimiento.

## El traslado internacional como trampa de cumplimiento

Una empresa con 1.500 empleados y presencia en ocho países de la UE y cuatro terceros procesa entre 30 y 50 traslados al año: cambios de centro dentro del mismo municipio, traslados con cambio de residencia, desplazamientos dentro de la UE, asignaciones a terceros países de uno a tres años y transferencias de directivos dentro del grupo. La realidad suele ser un repositorio con cincuenta carpetas por empleado, muchas con documentos vencidos: un certificado A1 caducado a los 18 meses sin prórroga, un visado pendiente que bloquea el inicio de una asignación, una declaración fiscal del expatriado sin presentar o un anexo de contrato sin firma electrónica que en juicio no demuestra el acuerdo de movilidad.

Una asignación internacional cuesta unos 70.000 euros al año, y alrededor de una de cada quince fracasa, casi siempre por una preparación insuficiente. Las sanciones se acumulan: la Inspección de Trabajo y la Agencia Tributaria, la AEPD por las transferencias de datos sin garantías y extranjería por el trabajo sin permiso. En una empresa de tamaño medio o grande, un desplazamiento sin comunicación previa, una asignación sin aplicar el convenio de doble imposición y una transferencia de datos sin cláusulas tipo pueden sumar cifras millonarias, además de la responsabilidad personal de los administradores.

## Traslado, modificación sustancial y derechos del comité

El agente verifica que cada traslado cumpla la normativa antes de implementarlo. La movilidad geográfica del art. 40 ET (cambio de centro a otro municipio con cambio de residencia) exige causa justificada, preaviso de 30 días, indemnización con opción de extinción y, por encima de ciertos umbrales, un procedimiento colectivo con periodo de consultas y acta firmada. La modificación sustancial del art. 41 ET (jornada, horario, retribución o funciones) sigue su propio procedimiento, con derecho de impugnación judicial. El art. 42 ET regula la contrata, con responsabilidad solidaria de la empresa principal.

El agente integra la consulta previa al comité de empresa que exige el art. 64 ET y concilia las cláusulas de movilidad, las dietas y el paquete de reubicación con el convenio sectorial aplicable. La política de la empresa puede mejorar el convenio, pero nunca empeorarlo. Un traslado sin procedimiento se expone a sanciones de la Inspección de Trabajo, y la jurisprudencia de la Sala IV del Tribunal Supremo llega a anularlo.

## Extranjería: visado, NIE y la vía rápida de la Ley 14/2013

El agente integra el procedimiento general de extranjería de la LO 4/2000, de unos tres meses, ante la Subdelegación del Gobierno. Como alternativa, la Ley 14/2013 ofrece una vía rápida ante la Unidad de Grandes Empresas, con plazos breves, para perfiles altamente cualificados, transferencias dentro del grupo, investigadores, inversores y emprendedores. La documentación requerida incluye el pasaporte, el certificado de antecedentes penales, el certificado médico, el título académico homologado, el contrato de trabajo y el visado nacional, con apostilla y traducción jurada cuando son documentos públicos.

Tras la llegada hacen falta el NIE y la tarjeta de identidad de extranjero, que se solicita ante la Comisaría dentro de los 30 días siguientes a la entrada, además del empadronamiento y las altas en la Seguridad Social y en Hacienda. Trabajar sin permiso o con el visado caducado se sanciona conforme a la LO 4/2000, con multas que pueden llegar al millón de euros, la expulsión administrativa y la prohibición de entrada en el espacio Schengen.

## Seguridad Social, doble imposición y protección de datos

El agente coordina la Seguridad Social mediante el certificado A1, que la Tesorería emite a través del Sistema RED. Mientras está vigente, se aplica la legislación del país de origen y el trabajador sigue cotizando en España, con cobertura sanitaria y portabilidad de la pensión, durante un máximo de 24 meses prorrogables otros 24. Para terceros países se aplica el convenio bilateral de Seguridad Social que corresponda (España tiene más de 25).

La tributación se resuelve con los convenios para evitar la doble imposición, que fijan la residencia fiscal según criterios como los 183 días o el centro de intereses vitales. Un residente en España que trabaja fuera puede aplicar la exención del art. 7p del IRPF, hasta 60.100 euros al año; un impatriado que llega a España puede acogerse al régimen Beckham, con un tipo fijo del 24 % hasta 600.000 euros durante seis años. Las transferencias internacionales de datos personales se rigen por los arts. 44 a 49 RGPD, con las cláusulas tipo o las normas corporativas que procedan y una evaluación de impacto. La AEPD puede sancionar su incumplimiento hasta el 4 % de la facturación mundial.

## Conexión con incorporación, nóminas y gestión documental

El agente aporta la orquestación de las 30 a 50 tareas de movilidad, y otros agentes del Decision Layer se apoyan en ella. El de incorporación recibe el alta del nuevo empleado en el país de destino, con la configuración informática, las altas en la Seguridad Social y en Hacienda y el contrato. El de nóminas recibe los cambios retributivos de la asignación, el paquete de reubicación, la igualación fiscal, el certificado A1 y el finiquito de la repatriación. El de gestión documental archiva el expediente de movilidad (anexo de contrato, certificado A1, visado, permiso, NIE, TIE, apostilla y traducción jurada) durante los plazos legales y atiende las solicitudes de acceso (art. 15 RGPD).

Sin esta orquestación, cada agente trabajaría con información dispersa. El agente se integra por API con las plataformas españolas e internacionales más extendidas (A3, Sage, Cegid, Bizneo, Holded, Factorial, Personio, SAP SuccessFactors, Workday, Oracle), con suites especializadas en movilidad global y con plataformas de firma electrónica y gestión documental.

## De un vistazo

- 11 decisiones deterministas, 3 indicadores asistidos por aprendizaje automático y 1 confirmación humana: 15 microdecisiones del ciclo de traslado y reubicación.
- Clasificación del tipo de traslado (art. 40 ET, art. 41 ET, desplazamiento de la Ley 11/2023 o asignación a un tercer país) antes del procedimiento.
- Consulta previa al comité de empresa (art. 64 ET) y procedimiento colectivo (art. 40.2 ET) por encima de los umbrales, con acta firmada.
- Conciliación automática con el convenio colectivo aplicable: cláusulas de movilidad, dietas y paquete de reubicación.
- Determinación de la residencia fiscal y aplicación del convenio de doble imposición, con el régimen Beckham cuando procede.
- Coordinación de la Seguridad Social mediante el certificado A1 de la Tesorería o el convenio bilateral del tercer país.
- Tramitación del visado, el permiso de trabajo, el NIE y la TIE, por la vía rápida o el procedimiento general, con apostilla y traducción jurada.
- Comunicación previa del desplazamiento a la autoridad laboral (Ley 11/2023), con persona responsable y nóminas conservadas dos años.
- Protección de datos en las transferencias internacionales (arts. 44 a 49 RGPD), con cláusulas tipo y evaluación de impacto.
- Sanciones acumulables: Inspección de Trabajo hasta 187.515 euros, AEPD hasta el 4 % y extranjería hasta el millón de euros.

### Distribución de Decididores Transfer-Relocation

| Tipo | Decisiones |
|------|------------|
| 11 decisiones deterministas | Clasificación del traslado, plan de tareas, conciliación con el convenio, residencia fiscal, coordinación de la Seguridad Social, extranjería, comunicación previa, consulta al comité de empresa, seguimiento, notificaciones y verificación de requisitos. |
| 3 indicadores asistidos por IA | Cálculo del IRPF, paquete de reubicación y seguimiento de tareas. |
| 1 confirmación humana | Aprobación de los cambios retributivos y de los paquetes de la alta dirección (art. 217 LSC). |

--- Agente HR Solicitud Viaje ---
> Flujo HR de aprobación de viajes antes del viaje: solicitud con visto bueno del responsable, política del comité de empresa ET art. 64 y validación de campos obligatorios.

La liquidación de gastos de viaje en España convive con varios marcos a la vez, con consecuencias muy distintas. El Reglamento del IRPF fija las dietas exentas (53,34 euros al día en España con pernocta, 26,67 sin ella, 91,35 en el extranjero con pernocta, 48,08 sin ella, y 0,26 por kilómetro en vehículo propio). La Ley General Tributaria y el Código de Comercio obligan a conservar la documentación contable seis años, y el Plan General de Contabilidad ordena los asientos. El convenio colectivo aplicable puede mejorar las dietas mínimas. A todo ello se suman la protección de datos en la geolocalización de vehículos y la verificación del auditor. La consecuencia es que cualquier gasto de viaje puede activar a la vez obligaciones ante la Agencia Tributaria, el ICAC, la Inspección de Trabajo, el auditor externo y el comité de empresa.

## Liquidar un gasto de viaje en segundos en lugar de semanas

Una liquidación de gastos de viaje cuesta 53 euros antes de reembolsar el primer euro, según la fundación GBTA: 22 minutos de tramitación repartidos entre el empleado, el responsable de línea y el departamento financiero. Una de cada cuatro contiene errores, y un buen número de viajeros de negocios no cumple la política de la empresa. En una empresa con 1.500 empleados y 200 viajes al mes, esos costes suman cifras de seis dígitos al año sin haber reembolsado un solo recibo de hotel.

Lo que falla es el camino desde el recibo hasta la contabilidad: la imputación a las cuentas correctas, la deducibilidad del IVA, las dietas exentas y la conciliación de los totales contra el Libro Mayor. En la mayoría de las empresas, ese puente se sostiene con asientos manuales, filas copiadas en Excel y el conocimiento tácito del departamento financiero. El agente automatiza alrededor del 80 % del proceso: lee los recibos, valida la política, calcula las dietas, genera los asientos y concilia. Queda una sola intervención humana: la aprobación final del lote por el responsable de línea, con segregación de funciones.

## Las dietas exentas: 53,34 euros al día en España

El marco fiscal de las dietas parte del Reglamento del IRPF, que declara exentos ciertos importes: en España, 53,34 euros al día de manutención con pernocta y 26,67 sin ella; en el extranjero, 91,35 euros con pernocta y 48,08 sin ella, con la estancia justificada mediante factura. El kilometraje en vehículo propio está exento a razón de 0,26 euros por kilómetro, más los peajes y el aparcamiento. La exención requiere que el desplazamiento sea fuera del centro de trabajo habitual y por menos de nueve meses.

Si la dieta supera estos importes, el exceso se considera retribución en especie y tributa con su retención de IRPF y su cotización a la Seguridad Social. El Real Decreto 462/2002 fija el régimen de los empleados públicos, que sirve de referencia para el sector privado, y algunos convenios sectoriales superan con frecuencia los mínimos del IRPF. La Agencia Tributaria prioriza las inspecciones sobre dietas y gastos de viaje: un error puede sancionarse entre el 50 % y el 150 % de la deuda, e incluso por la vía penal cuando supera los 120.000 euros.

## Conservación contable y deducibilidad del IVA

La Ley General Tributaria fija la prescripción tributaria en cuatro años y obliga a conservar la documentación seis. El Código de Comercio exige una contabilidad ordenada, el Libro Diario y la conservación del soporte documental (recibos de hotel y transporte y facturas) durante seis años. El Plan General de Contabilidad ordena los asientos: el alojamiento y la manutención en la cuenta de otros servicios, el transporte en la suya y el IVA soportado en la cuenta correspondiente, con su imputación al centro de coste.

La Ley 37/1992 del IVA regula la deducibilidad: el IVA del alojamiento y la manutención es deducible al 100 % con factura completa; el de los vehículos de turismo, al 50 % salvo afectación exclusiva; y el de las atenciones a clientes, en general no es deducible. La falsedad en las cuentas anuales tiene consecuencias penales, y un informe de auditoría con salvedades expone a sanciones del ICAC; la auditoría es obligatoria para las entidades de interés público.

## Protección de datos y derechos del comité de empresa

Los datos de los empleados que se tratan al liquidar gastos son datos laborales (art. 88 RGPD), y deben minimizarse y protegerse con medidas de seguridad adecuadas. La geolocalización de vehículos de empresa solo es lícita con información previa al trabajador y al comité de empresa (art. 90 LOPDGDD). La AEPD puede sancionar el incumplimiento hasta el 4 % de la facturación mundial.

Por el lado laboral, el Estatuto de los Trabajadores reconoce al comité de empresa el derecho a ser informado de los cambios en la política de viajes y reembolso (art. 64), información que ha de ser previa a su implementación. El plan de igualdad, obligatorio en empresas de más de 50 trabajadores, impide reembolsos desiguales por razón de sexo. Si las dietas pactadas son inferiores a las del convenio sectorial, la Inspección de Trabajo puede sancionarlo, y la jurisprudencia de la Sala IV del Tribunal Supremo ampara las reclamaciones de los trabajadores.

## Conexión con la contabilidad de nóminas y la gestión documental

Varios agentes operan en las áreas financiera y de Recursos Humanos con focos complementarios. Este se ocupa de la liquidación de los gastos de viaje, con las dietas españolas, el kilometraje, la imputación contable y el reporte de emisiones de los desplazamientos. Otro agente gestiona los gastos generales que no son de viaje; otro, las facturas de proveedores y las cuentas a pagar; y el de contabilidad de nóminas genera los asientos a partir de los resultados de la nómina. El agente de gestión documental archiva los documentos de los empleados conforme a la normativa de protección de datos.

El flujo es claro: este agente aporta los datos de viaje a la contabilidad de nóminas, que a su vez alimenta el reporte y el análisis retributivo. La conciliación automática se detiene ante una excepción: un recibo perdido o ilegible, un concepto mal imputado, una diferencia de redondeo en el IVA o unos atrasos derivados del convenio colectivo.

## De un vistazo

- Dietas exentas de IRPF: 53,34 euros al día en España, 91,35 en el extranjero y 0,26 por kilómetro en vehículo propio.
- Asientos según el Plan General de Contabilidad, conservados seis años de forma inalterable y conciliados contra el Libro Mayor.
- Verificación de la Agencia Tributaria, con sanciones del 50 % al 150 % de la deuda y vía penal por encima de los 120.000 euros.
- Deducibilidad del IVA (Ley 37/1992): alojamiento al 100 %, vehículos al 50 % y atenciones a clientes no deducibles.
- Convenios colectivos y derecho de información del comité de empresa sobre la política de viajes, con plan de igualdad obligatorio.
- Protección de datos (art. 88 RGPD), con información previa al trabajador para la geolocalización de vehículos.
- Reporte de emisiones de los desplazamientos (ESRS E1), verificado por un auditor en empresas de más de 250 trabajadores.
- Coste medio de 53 euros y 22 minutos por liquidación, con una de cada cuatro errónea, frente a un cierre en un día con el agente.

### Distribucion de Decididores Travel-Expense

| Decisor | Numero decisiones | Porcentaje | Tipo |
|---------|-------------------|------------|------|
| Determinista | 11 | 79 % | Valida la política, calcula las dietas, el kilometraje y el IVA, genera los asientos contables y las retenciones, concilia los totales y prepara el reporte de emisiones. |
| Indicador asistido por IA | 2 | 14 % | Lee los recibos e identifica los gastos sospechosos. |
| Confirmación humana | 1 | 7 % | El responsable de línea aprueba el lote final, con segregación de funciones. |

El agente automatiza alrededor del 79 % del proceso de forma determinista, con el cálculo de las dietas, el kilometraje y el IVA, la generación de los asientos y la conciliación automática. Queda una sola intervención humana: la aprobación final del lote por el responsable de línea, junto con la dirección financiera, dentro del marco de control interno y la matriz de autorización, y con la verificación posterior del auditor externo.

--- Agente Gestión Proveedores RRHH ---
> Ciclo de vida proveedores HR: hitos contractuales, monitoreo KPI/SLA, due-diligence CSDDD 2024/1760, encargo RGPD art. 28 y reporte ESRS S2 para nóminas, beneficios y BPO HR.

Una empresa con 1.500 empleados mantiene típicamente 60-100 proveedores HR: nóminas (A3 Innuva HR, Sage, BPO Payroll), beneficios (seguros colectivos, planes médicos), formación (LMS, Recruitment Process Outsourcing), SaaS HR (Personio, Bizneo, Lever), ETT Ley 14/1994, PRL Ley 31/1995. Cada relación debe tener contrato de encargo RGPD art. 28 vigente, SLA conformes, monitorización de KPI, due-diligence CSDDD y reporte ESRS S2. En la práctica al menos una de estas cinco condiciones está casi siempre incumplida.

## Gestion proveedores HR en contexto CSDDD

Los proveedores HR no son solo relaciones contractuales, sino fragmentos de la cadena de valor. La Directiva CSDDD 2024/1760 de 13.06.2024 introduce due-diligence en cadena de valor desde 26.07.2027 para 5000+ empleados y 1.500 millones EUR de facturación global, transposición española hasta 26.07.2026.

El sistema que gestiona proveedores procede de la década anterior. Carpeta SharePoint con 200 contratos, de los cuales 40 tienen cláusulas RGPD art. 28 incompletas. Excel con monitorización de plazos, donde 15 contratos ya se han renovado tácitamente pese a incumplimientos SLA.

Resultado: la empresa opera con proveedores de países de alto riesgo sin auditorías, firma SCC 2021/914 para EE.UU. sin Transfer Impact Assessment, pierde el control sobre la consolidación del mercado. La auditoría ICAC del reporte ESRS S2 descubre ausencia de política de due-diligence CSDDD - modificación de opinión, exclusión del IBEX-35 ESG.

## Contratación pública (LCSP) y due diligence de la CSDDD

La Ley 9/2017 de Contratos del Sector Público es fundamental para entidades del sector público. Umbral europeo para suministros y servicios sector clásico 143.000 EUR, sector especial 215.000 EUR, obras 5.538.000 EUR. Procedimientos LCSP: abierto art. 156, restringido art. 160, diálogo competitivo art. 172, asociación para la innovación art. 177.

La publicación en la Plataforma de Contratación del Sector Público PLCSP es obligatoria, para contratos por encima del umbral europeo adicionalmente TED con mínimo 35 días. Selección con criterios: precio máximo 50 por ciento conforme con LCSP, calidad, experiencia, certificaciones ESG/CSDDD, conformidad RGPD art. 28.

La Directiva CSDDD 2024/1760 introduce due-diligence en cadena de valor - identificación, prevención, mitigación de impactos negativos en derechos humanos (Convenios OIT 29/138/105/87/98/100/111/155) y medio ambiente (Acuerdo de París, Directiva Marco del Agua 2000/60/CE). Mapeo tier 1 de proveedores directos HR y tier 2-N de subproveedores. Sanción hasta 5 por ciento de la facturación global por infracción.

El agente automatiza due-diligence mediante AI risk scoring 80-88 por ciento sobre metadatos (país según CPI e ITUC Global Rights Index, sector, certificaciones SA8000/ISO 14001, EcoVadis Gold/Silver) con escalado al Especialista en ESG. La decisión de contratar siempre al Consejo de Administración.

## Reporte de sostenibilidad: el estándar ESRS S2 de la cadena de valor

ESG/CSRD introduce reporte obligatorio de sostenibilidad de 12 estándares ESRS. ESRS S2 Workers in the Value Chain afecta a trabajadores de proveedores y subproveedores - estándar clave. Requisitos:

- S2-1: política de derechos humanos conforme con UNGP y OECD Guidelines, política CSDDD, código de conducta para proveedores
- S2-2: procesos de implicación - auditorías SMETA, encuestas a trabajadores, visitas, reporte BAFA para obligados por LkSG
- S2-3: mecanismos de reclamación - canal para trabajadores de proveedores integrado con política de denunciantes Ley 2/2023
- S2-4: acciones correctoras - corrección de incumplimientos, plan correctivo, en casos extremos denuncia del contrato
- S2-5: objetivos - reducción de riesgo, certificaciones SA8000, EcoVadis Gold/Silver, reducción Scope 3 GEI

La Ley 11/2018 EINF establece reporte de información no financiera para empresas 500+ empleados y 20 millones EUR de balance o 40 millones EUR cifra de negocios. IBEX-35 CIS y la CNMV exigen reporte trimestral para sociedades cotizadas. El agente genera informes automáticamente. El auditor ICAC tiene acceso vía API.

La infracción del reporte genera modificación de la opinión de auditoría ICAC (salvedad), exclusión del IBEX-35 ESG, infracción del Código de Buen Gobierno (amonestación pública).

## El contrato de encargo del art. 28 RGPD y las transferencias internacionales

El RGPD art. 28 exige contrato de encargo del tratamiento con cada proveedor HR con acceso a datos de empleados - 35 cláusulas obligatorias: objeto, duración, naturaleza, finalidad; categorías de datos (ET art. 8, RGPD art. 9 datos sensibles); categorías de interesados; obligaciones del encargado art. 28 ap. 3 letras a-h - instrucciones documentadas, confidencialidad, medidas TOM, subencargados con autorización previa, auditabilidad, devolución/supresión.

Las Cláusulas Contractuales Tipo SCC 2021/914 de 4.06.2021 son obligatorias desde 27.12.2022 para transferencias a terceros países - módulo 2 responsable-encargado, módulo 3 encargado-subencargado. La sentencia Schrems II C-311/18 de 16.07.2020 exige Transfer Impact Assessment TIA con valoración del derecho nacional (FISA 702 para EE.UU.), medidas técnicas (cifrado extremo a extremo, fragmentación, claves HSM separadas). El Data Privacy Framework UE-EE.UU. de 10.07.2023 reemplaza parcialmente las SCC para empresas certificadas.

La Ley 15/2007 LDC regula el control de la CNMC sobre concentraciones M&A por encima de 240 millones EUR de volumen global (art. 8) y la prohibición de acuerdos restrictivos de competencia (art. 1) - colusión en licitación con sanciones hasta 10 por ciento de la facturación anual, en casos extremos sanción penal del art. 286 ter Código Penal hasta 4 años de prisión.

Las infracciones generan sanción AEPD hasta 4 por ciento de la facturación o 20 millones EUR, sanción CNMC hasta 10 por ciento de la facturación anual.

## Conexión con nóminas, análisis retributivo y gestión documental

El agente coopera con Payroll Processing Agent mediante la ratificación de proveedores de nóminas (A3 Innuva HR, Sage 200, BPO Payroll) con contrato de encargo RGPD art. 28, monitorización de KPI (tiempo de cierre, exactitud de TGSS Sistema RED, modelo 111 y modelo 190).

La cooperación con Compensation Benchmarking Agent cubre la ratificación de proveedores de datos de benchmarking (Mercer España, Korn Ferry España, Aon Hewitt, INE) con verificación de independencia metodológica, transparencia de medición EU Pay Transparency Directive 2023/970, ESRS S1-9.

HR Document Management Agent archiva contratos en el segmento B del expediente corporativo conforme con CCom art. 30 (6 años para libros y documentación contable). Vendor Management gestiona creación, monitorización y denuncia, HR Document Management archiva como documentos de RRHH con firma cualificada QSig.

Los cuatro agentes comparten infraestructura de firma cualificada eIDAS Signaturit, audit-trail RGPD art. 30+32, integración con A3 Innuva HR.

## [Decision Layer](/es/decision-layer/) convierte el vendor management en proceso verificable

El Decision Layer descompone el ciclo de vida del proveedor en pasos individuales y para cada uno define: humano, motor de reglas o IA. Clasificación del tipo, validación LCSP, validación RGPD art. 28, monitorización de KPI, plazos contractuales se someten al motor de reglas. Validación SCC con Schrems II, due-diligence CSDDD, agregación de feedback la asume la IA con confidence 80-92 por ciento. RGPD art. 22 excluye automatización completa - clasificación AI por debajo del threshold se deriva al Especialista en ESG/CSRD o al DPD, decisión de contratar con proveedor de alto riesgo siempre al Consejo de Administración.

El humano permanece donde la decisión es necesaria: aprobación del contrato estratégico por el Consejo con responsabilidad LSC art. 236+241, selección del adjudicatario en licitación, evaluación de riesgo CSDDD controvertido, decisión de denuncia tras incumplimientos SLA. El Consejo ve un paquete verificado y autoriza.

## De un vistazo

- 60-100 proveedores HR en empresa típica de 1.500 empleados, una de cinco condiciones siempre incumplida
- Ley 9/2017 LCSP umbrales europeos 143.000 EUR para entidades del sector público, transparencia PLCSP/TED
- Directiva CSDDD 2024/1760 due-diligence en cadena de valor desde 26.07.2027 (5000+), transposición hasta 26.07.2026
- RGPD art. 28 35 cláusulas obligatorias del contrato de encargo, sanción AEPD hasta 4 por ciento de la facturación o 20 millones EUR
- Cláusulas contractuales tipo y marco de privacidad UE-EE. UU. para las transferencias a terceros países, conforme a la sentencia Schrems II
- Ley 15/2007 LDC CNMC control de concentraciones por encima de 240 millones EUR, colusión en licitación hasta 10 por ciento de la facturación
- ESG/CSRD ESRS S2 Workers in Value Chain S2-1+S2-2+S2-3+S2-4+S2-5 reporte ICAC e IBEX-35 CIS CNMV
- AML Ley 10/2010 verificación Registro de Titulares Reales RTR, sanción SEPBLAC hasta 10 millones EUR
- Plazo de conservación 6 años CCom art. 30 para libros y documentación contable

### Distribucion de Decididores Vendor-Management

| Decisión                                    | Decididor | Base legal                       |
| ------------------------------------------- | --------- | -------------------------------- |
| Clasificación del tipo de proveedor         | Regla     | Matriz de categorías             |
| Validación Ley 9/2017 LCSP                  | Regla     | Umbrales europeos PLCSP/TED      |
| Validación RGPD art. 28 encargo             | Regla     | Checklist 35 cláusulas           |
| Validación de cláusulas tipo y Schrems II   | IA        | Art. 22 RGPD y marco UE-EE. UU.  |
| Due diligence de la CSDDD 2024/1760         | IA        | Art. 22 RGPD y directrices UNGP  |
| Verificación de equivalencia con la LkSG    | Regla     | Reporte BAFA y CSDDD             |
| Validación SLA y KPI                        | Regla     | CC art. 1152-1155 cláusula penal |
| Workflow de aprobación                      | Regla     | Matriz LSC art. 249 bis          |
| Verificación de conozca a su proveedor y AML| Regla     | Registro de titulares y AEAT     |
| Monitorización KPI continua                 | IA        | RGPD art. 22                     |
| Monitorización plazos contractuales         | Regla     | CCom art. 30                     |
| Procedimiento de licitación periódico       | Humano    | LSC art. 236+241                 |
| Validación CNMC y colusión en licitación    | Regla     | Ley 15/2007 art. 1               |
| Generación de informes ESRS S2              | IA        | ESRS S2 y reporte ante la CNMV   |

## Lo que la infraestructura aporta a otros agentes

La arquitectura de clasificación, workflow de due-diligence CSDDD y workflow de aprobación con LSC art. 249 bis se convierte en plantilla para agentes con proveedores externos. Procurement Agent aplica umbrales LCSP. IT Service Management Agent aplica DORA EU 2554/2022. Marketing Agent aplica RGPD art. 28 para CRM y Marketing Automation.

El Decision Logging conforme con RGPD art. 30+32 y CCom art. 30 construye el Audit Trail - clave para defensa frente a inspección JCCPE, AEPD, CNMC, SEPBLAC, ITSS, ICAC con estándares ESRS S2. La generación de informes ESG/CSRD ESRS S2 es fundamento para ESG Reporting Agent, Supply Chain Risk Agent, Whistleblower Workflow Agent.

Vendor Management Agent demuestra con 80 proveedores HR y 35 cláusulas obligatorias RGPD art. 28 que un workflow auditable con conformidad LCSP, CSDDD 2024/1760, RGPD art. 28, SCC 2021/914 y ESRS S2 es posible.

--- Agente de planificación de plantilla España: forecasting operativo, ERE/ET art. 51 y RGPD art. 22 ---
> Planificación plantilla: headcount forecasting determinista, ERE/despido colectivo ET art. 51, periodo consultas comité empresa, plan igualdad RD 901/2020 y RGPD art. 22 con EU AI Act compliance.

## Por qué España necesita un planteamiento diferente

La planificación de plantilla en España no es un ejercicio de optimización financiera. Es una secuencia regulada de procesos donde cada decisión activa un marco legal específico - desde el Estatuto de los Trabajadores hasta el Anexo III de la Ley AI europea - y donde el comité de empresa, los sindicatos legitimados y la Inspección de Trabajo tienen capacidad efectiva de bloquear el go-live.

El director de RRHH del grupo industrial que recibe el briefing del consejo de administración - "necesitamos reducir un 8 por ciento la plantilla del centro de Tarragona en los próximos 18 meses" - sabe que la frase contiene 14 procedimientos paralelos. Periodo de consultas con el comité (ET art. 64), comunicación a la Dirección General de Trabajo (Real Decreto 1483/2012), verificación del plan de igualdad ROE, comprobación de la cuota del 2 por ciento de personas con discapacidad, evaluación de riesgos psicosociales (Ley 31/1995), informe al consejo (LSC art. 225), reporting CSRD ESRS S1 y - lo más delicado - cumplir el RGPD art. 22 sin que el algoritmo pase la frontera del Anexo III(4)(b) de la Ley AI.

El agente de planificación de plantilla no automatiza esa secuencia. La organiza, la documenta y la audita - dejando todas las decisiones críticas en manos humanas legitimadas. La diferencia entre una herramienta operativa y un sistema de alto riesgo se decide en una línea de código: el módulo que activa o no las recomendaciones individuales.

## La frontera del Anexo III(4)(b)

El Reglamento UE 2024/1689 (Ley AI) clasifica como alto riesgo los sistemas de IA usados para "tomar decisiones que afecten a las condiciones de las relaciones laborales, la promoción, la finalización de la relación contractual, la atribución de tareas o la supervisión y evaluación del rendimiento" - Anexo III, punto 4(b).

La interpretación operativa es clara: forecasting de headcount agregado, capacity planning por departamento y análisis de skills gap son usos permitidos del RGPD art. 6.1.f - interés legítimo del empresario en organizar su capacidad operativa. NO son alto riesgo.

Recomendación individual de despido, ranking de empleados por riesgo de redundancia o priorización algorítmica de criterios de selección SÍ son alto riesgo - Anexo III(4)(b) - y requieren DPIA RGPD art. 35, CE Marking, sistema de gestión de riesgos del art. 9 de la Ley AI, supervisión humana significativa documentada y registro en la base de datos europea de sistemas de alto riesgo.

El agente está diseñado con una frontera técnica explícita. El módulo de forecasting opera por defecto. El módulo de recomendación individual de despido permanece desactivado hasta que el DPO interno y un asesor laboralista externo firman el DPIA, el comité de empresa recibe la información del art. 64 del ET sobre uso de IA, y la AEPD recibe la consulta previa si procede. Sin esas tres firmas, el circuit breaker técnico bloquea cualquier output que cruce la frontera.

## Headcount forecasting determinista, no IA generativa

La primera capa del agente es deliberadamente no-IA. Un modelo ARIMA de series temporales, ajustado por la estacionalidad sectorial documentada en el convenio colectivo aplicable y validado contra los datos de altas y bajas de los últimos 36 meses procedentes del Sistema RED de la TGSS.

Esta arquitectura tiene dos ventajas regulatorias. Primero, los outputs son explicables y reproducibles - la ITSS puede auditar la regla, no una caja negra. Segundo, no entra en el ámbito del RGPD art. 22 porque no hay perfilado individual: el output es agregado por departamento y categoría profesional.

El capacity planning añade una segunda capa: un motor de reglas que cruza el catálogo de competencias del convenio colectivo con la matriz de skills de la plantilla actual y el roadmap aprobado por el consejo. El output es estructurado: necesidades de formación, brechas competenciales y - solo si el plan estratégico lo requiere - propuestas de contratación o reorganización de funciones. El demográficamente robusto INE proyecta para España un saldo neto negativo en la población activa, lo que hace de este forecasting una herramienta de supervivencia operativa, no de optimización financiera.

## Plan de igualdad y registro retributivo como inputs obligatorios

El Real Decreto 901/2020 obliga a las empresas de 50 o más trabajadores a tener un plan de igualdad registrado en el ROE. El Real Decreto 902/2020 exige un registro retributivo desglosado por sexo y categoría profesional.

El agente lee ambos documentos - el plan en formato estructurado, el registro como tabla normalizada - antes de generar cualquier recomendación. Si una propuesta de reorganización afectaría desproporcionadamente a un colectivo protegido (test de impacto adverso 4/5 rule), el output se marca como inadmisible y se solicita revisión humana cualificada.

La Ley 15/2022 igualdad de trato amplía las causas de discriminación más allá del sexo: edad, discapacidad, origen racial o étnico, identidad sexual, expresión de género, enfermedad o condición de salud. El filtro anti-discriminación del agente cubre las causas múltiples y registra las decisiones para auditoría posterior. La Ley Orgánica 4/2022 sobre paridad y el Convenio 190 OIT sobre acoso son inputs adicionales del motor de reglas.

## Periodo de consultas: lo que el agente NO hace

El periodo de consultas con el comité de empresa o la representación legal de los trabajadores - mínimo 30 días en empresas con 50 o más trabajadores, 15 días en empresas más pequeñas - es un proceso humano de negociación. El agente NO sustituye esa negociación.

Lo que sí hace: prepara la memoria justificativa con las causas económicas, técnicas, organizativas o de producción exigidas por el ET art. 51; estructura los criterios de selección conforme al Real Decreto 1483/2012; genera el plan de medidas sociales de acompañamiento - recolocación, formación, indemnizaciones - y presenta el dossier al comité en formato auditable.

Si la negociación termina sin acuerdo, el agente actualiza el expediente con las posiciones de las partes y lo prepara para la comunicación obligatoria a la Dirección General de Trabajo de la Comunidad Autónoma competente o, en grupos con centros en varias autonomías, al Ministerio de Trabajo y Economía Social.

## Sindicatos, consejo y reporting integrado

La negociación con las secciones sindicales legitimadas conforme a la Ley Orgánica de Libertad Sindical (LOLS) es paralela al periodo de consultas. El agente mantiene un registro estructurado de las posiciones sindicales y los acuerdos parciales, pero la mesa negociadora es humana. Esta separación es coherente con la doctrina del Tribunal Supremo Sala Cuarta sobre legitimación negocial.

El informe al consejo de administración es un output específico: impacto financiero del ERE, riesgo reputacional, obligaciones ESG/CSRD y conformidad con la Ley de Sociedades de Capital art. 225-227 sobre deberes de los administradores. El secretario del consejo recibe un dossier estandarizado que reduce el riesgo de responsabilidad personal del art. 247 LSC.

El reporting CSRD ESRS S1 - trabajadores propios - se alimenta directamente de los datos del agente. Métricas de capacidad operativa, rotación, formación, diversidad y salud y seguridad se mapean automáticamente a la taxonomía EFRAG y al EINF Ley 11/2018. Esto reemplaza varias semanas de trabajo manual del equipo de sostenibilidad y elimina las inconsistencias entre los datos de RRHH y los datos de reporting financiero.

## Inspección de Trabajo y Audiencia Nacional

La ITSS puede inspeccionar el procedimiento en cualquier momento. El expediente generado por el agente incluye logs inmutables con hash SHA-256, versionado de modelos, trazabilidad completa de cada decisión y documentación del periodo de consultas. El plazo de retención es de 6 años - prescripción laboral más 2.

Si el ERE se impugna ante la Sala Social de la Audiencia Nacional - procedimiento del art. 124 de la Ley Reguladora de la Jurisdicción Social - el dossier se entrega a los servicios jurídicos externos en formato auditable. El agente NO toma decisiones legales: produce el material probatorio. La doctrina jurisprudencial del Tribunal Supremo y de los Tribunales Superiores de Justicia se incorpora a la base de reglas mediante actualizaciones trimestrales.

La cuota del 2 por ciento de personas con discapacidad (Ley General de derechos de personas con discapacidad, antigua LISMI) es un control bloqueante: una propuesta que rompiera la cuota sin medidas alternativas registradas se rechaza automáticamente. La evaluación de riesgos psicosociales según la Ley 31/1995 y el Real Decreto 39/1997 es un prerrequisito antes de cualquier reorganización significativa.

El resultado operativo es que el director de RRHH no entrega al consejo un PowerPoint con números optimistas. Entrega un expediente regulatoriamente sólido, listo para la negociación con el comité, defendible ante la ITSS y conforme con el RGPD, la Ley AI y el ESRS S1 - sin haber cruzado la frontera del Anexo III(4)(b).

--- Works Council Coordination Agent ---
> Gestiona coordinación con el Comité de Empresa: requisitos de consulta, plazos y documentación conforme al Estatuto de los Trabajadores.

Un despido sin consulta previa al Comité de Empresa cuando ésta es exigible puede derivar en la declaración de improcedencia o, en los casos más graves, en nulidad - con independencia de si la causa de la extinción estaba justificada. El artículo 64 del Estatuto de los Trabajadores define los derechos de información y consulta del Comité de Empresa, y la jurisprudencia social ha confirmado esta línea en numerosas sentencias. A pesar de ello, los procedimientos de extinción fracasan en la práctica con regularidad precisamente en este punto: no por falta de motivos, sino por procedimientos defectuosos. Documentación incompleta, plazos incumplidos, nivel de participación equivocado. En torno a 100.000 demandas por despido llegan anualmente a los juzgados de lo social españoles. Una parte considerable ataca defectos formales en la consulta al Comité de Empresa - porque esos defectos son la vía más segura hacia la ineficacia.

El problema no es de conocimiento. Los departamentos de RRHH conocen las normas. El problema es de coordinación.

## Cinco niveles de participación, un proceso sin sistema

El Estatuto de los Trabajadores y la legislación complementaria reconocen distintos niveles de participación del Comité de Empresa, cada uno con sus propias reglas, plazos y consecuencias ante errores:

```
Nivel              Base legal       Plazo                Consecuencia
────────────────────────────────────────────────────────────────────────
Información        Art. 64 ET       Sin plazo fijo        Acción de cumplimiento
Consulta previa    Art. 64 ET       15 días               Procedimiento viciado
Consulta específica Art. 41 ET      15 días               Ineficacia
Negociación        Art. 41 ET       15 días               Bloqueo
Acuerdo colectivo  Art. 82-92 ET    Negociación           Sin validez
```

El reto no es conocer esta tabla. El reto es, ante cada medida concreta de RRHH - despido, contratación, traslado, modificación sustancial de condiciones, cambio de turnos - identificar en segundos el nivel correcto, preparar la documentación adecuada y activar el plazo correspondiente. En una empresa con 1.500 empleados, en una sola semana pueden correr a la vez una docena de procedimientos: tres contrataciones, una extinción, dos traslados, una modificación del calendario laboral.

Cada uno de esos procedimientos tiene otro disparador, otra documentación, otros plazos y otras vías de escalado. Y cada uno, en la mayoría de las empresas, se coordina por correo electrónico, carpetas de papel o acuerdo verbal. No hay calendario central de plazos. No hay comprobación automática de completitud. No hay sistema que reconozca si el traslado previsto de un empleado a distinto centro activa el artículo 40 del Estatuto con plazos específicos.

## Por qué los defectos formales tumban despidos

La consulta al Comité de Empresa es el punto de contacto más crítico entre RRHH y la representación legal. Los requisitos están formulados con claridad: antes de ciertas medidas, el Comité debe ser informado con la documentación necesaria. El Comité dispone de plazos específicos para emitir su informe, según el tipo de medida. En la práctica, los defectos se producen en tres puntos.

Primero: información incompleta. El empresario debe trasladar al Comité todos los elementos que justifican la decisión. Las referencias "a grandes rasgos" o "esquemáticas" no bastan. El Comité debe poder formarse un juicio sin investigaciones propias. Si falta un detalle relevante - por ejemplo, las cargas familiares del afectado en una selección comparativa - toda la consulta puede quedar viciada.

Segundo: cálculo incorrecto de plazos. El plazo comienza con la recepción de la información completa, no con el envío. No con la convocatoria a la reunión. Con la recepción de la documentación completa. Una decisión que se ejecuta un día antes de tiempo puede caer.

Tercero: motivos añadidos después. Los motivos sobre los que no se consultó al Comité no pueden añadirse en el procedimiento judicial posterior. Lo que falta en la consulta falta ante el juez.

Cada uno de estos errores es evitable. Ninguno exige juicio jurídico. Los tres son errores de coordinación: la información correcta existía, pero no se transmitió de forma completa. El plazo era conocido, pero se calculó mal. El motivo existía, pero no se documentó.

## El cuello de botella del artículo 40 y 41 en traslados y modificaciones

Los despidos son el escenario más visible, pero no el más frecuente. El artículo 40 del Estatuto regula los traslados a distinta localidad y el artículo 41 las modificaciones sustanciales de condiciones de trabajo. Ambos exigen períodos de consulta formales con el Comité de Empresa cuando tienen carácter colectivo y notificación individual con plazos específicos en el caso individual.

El Comité tiene un plazo definido para emitir su informe. Si no hay acuerdo, el empresario puede proceder con determinadas cargas adicionales de justificación. El empleado afectado puede impugnar la medida ante el juzgado social. Quien incumple los plazos debe revertir la medida.

En una empresa en crecimiento que cubre entre cinco y diez puestos al mes y realiza periódicamente ajustes organizativos, estos procedimientos corren en paralelo. Cada uno con su documentación, sus plazos, sus puntos de escalado. La coordinación por correo y calendario funciona hasta que deja de funcionar. Y el momento en el que deja de funcionar no sólo cuesta tiempo - cuesta el puesto, porque el candidato no espera, o cuesta la medida organizativa, porque llega fuera de plazo.

## Lo que cambia cuando la coordinación se vuelve infraestructura

El [Decision Layer](/es/decision-layer/) descompone cada proceso de participación en pasos de decisión individuales y define para cada paso: humano, motor de reglas o IA. La asignación del nivel de participación - qué artículo aplica, qué documentación hace falta, qué plazo corre - es motor de reglas. La comprobación de completitud de la documentación contra una checklist es motor de reglas. La supervisión de plazos es motor de reglas. La decisión sobre cómo tratar una objeción del Comité permanece en manos humanas.

Concretamente, el flujo cambia en cuatro puntos.

La comprobación de participación se hace automáticamente. Cada medida de RRHH prevista - extinción, contratación, traslado, modificación - se coteja contra el Estatuto de los Trabajadores. El sistema reconoce si se requiere consulta previa según el artículo 64, un procedimiento específico según el artículo 40 o 41, o una negociación colectiva. No es el técnico de RRHH quien debe encontrar el artículo correcto. El motor de reglas lo encuentra.

La documentación se comprueba contra una checklist. Para cada nivel y cada tipo de medida existe una lista definida: ¿qué información debe recibir el Comité? ¿están completos los datos sociales del afectado? ¿está el tipo de medida correctamente indicado? ¿están los motivos desarrollados y no sólo enumerados? La comprobación se hace antes de enviar al Comité, no después.

Los plazos se siguen desde el momento del envío. El plazo del artículo 64, los plazos de los artículos 40 y 41, los plazos de negociación - cada plazo corre con un inicio documentado y escalado automático al vencer. ¿El Comité ha dejado vencer su plazo? El sistema documenta el efecto legal. ¿El Comité ha objetado? El responsable de RRHH recibe información inmediata, con los próximos pasos y los plazos relevantes.

Todo el procedimiento se documenta a prueba de auditoría. Cada paso, cada documento, cada plazo, cada informe, cada decisión. Si un empleado impugna la medida seis meses después y su abogado niega la correcta consulta, la prueba completa del procedimiento está disponible. No como cronología reconstruida a partir de cadenas de correo, sino como pista de auditoría que contiene cada paso individual con marca temporal y documento soporte.

## El agente que sirve a ambas partes

La mayoría de los agentes del ámbito de RRHH trabajan para una sola parte. El Works Council Coordination Agent es distinto. Profesionaliza el marco formal - y de eso se benefician ambas partes.

RRHH se beneficia porque los procedimientos ya no caen por defectos formales. Porque la preparación de la documentación dura horas en lugar de días. Porque el riesgo de una extinción ineficaz por consulta defectuosa se reduce a cero.

El Comité de Empresa se beneficia porque recibe documentación completa. Porque sus plazos se calculan correctamente y no se interpretan unilateralmente. Porque la documentación crea transparencia que antes tenía que exigir. El Comité tiene derecho a ser informado y consultado con antelación suficiente, aunque no tiene derecho de veto sobre la implementación.

El motor de comprobación de participación - qué artículo ante qué medida, qué documentación, qué plazo - no es una función aislada. Cualquier agente del Decision Layer que active una medida con relevancia para el Comité - el Onboarding Agent en contrataciones, el Payroll Agent en modificaciones retributivas, el Workforce Planning Agent en traslados - usa la misma lógica de comprobación. El calendario de plazos, las listas de verificación y la pista de auditoría se convierten en infraestructura común. Quien considera la coordinación con el Comité como solución aislada subestima la palanca. Quien la entiende como infraestructura construye la base para cualquier otro agente con relevancia para los derechos de participación.

--- Condiciones Generales de Contratación - Gosign GmbH ---
> CGC de Gosign GmbH para infraestructura de IA, desarrollo de agentes y desarrollo de software. Versión 3.1.

<h1>Condiciones Generales de Contratación</h1>
<p class="text-sm bg-gosign-light border border-gosign-border rounded-card p-3 mt-2">
<strong>Aviso:</strong> Este documento es una traducción informativa. La versión alemana es jurídicamente vinculante. En caso de discrepancias, prevalece la versión alemana.
<a href="/de/agb/" class="text-gosign-accent-text hover:text-gosign-accent-hover ml-1">→ Deutsche Fassung (versión alemana)</a>
</p>
<p class="text-lg text-gosign-text-light">
Gosign GmbH - Infraestructura de IA, desarrollo de agentes y desarrollo de software<br/>
Versión 3.1 - Estado: marzo 2026
</p>
<p class="text-sm text-gosign-text-light mt-2">
<a href="/documents/gosign-agb-v3.1.pdf" target="_blank" rel="noopener noreferrer"
class="text-gosign-accent-text hover:text-gosign-accent-hover">↓ Descargar como PDF</a>
</p>

<h2>§ 1 Ámbito de aplicación y objeto del contrato</h2>
<p>Las presentes Condiciones Generales de Contratación (CGC) se aplican a todos los contratos celebrados entre Gosign GmbH (en adelante, «Gosign») y sus clientes en las siguientes áreas de servicio:</p>
<p><strong>Infraestructura AI empresarial y desarrollo de agentes:</strong> Servicios relacionados con la inteligencia artificial en el entorno empresarial, incluyendo planificación e implementación de infraestructura de IA, desarrollo de agentes de IA, integración de modelos de IA, soluciones de self-hosting, estrategias FinOps para la optimización de costes de cargas de trabajo de IA, así como servicios de consultoría y desarrollo asociados.</p>
<p><strong>Decision Layer y arquitectura de Governance:</strong> Desarrollo e implementación de una capa de gobernanza y control (Decision Layer) entre los agentes de IA y los sistemas objetivo de la empresa, incluyendo control de decisiones basado en reglas, documentación de Audit Trail, arquitectura Human-in-the-Loop y generación automatizada de evidencias de cumplimiento (Cert-Ready).</p>
<p><strong>Desarrollo de software:</strong> Desarrollo de soluciones de software individuales, aplicaciones web e integraciones, también mediante el uso de frameworks y bibliotecas de código abierto. Comprende concepción, diseño, desarrollo, adaptación, integración y documentación.</p>
<p><strong>Hosting y servicios operativos (opcional):</strong> Servicios de hosting opcionales y soporte operativo ofrecidos por Gosign. La operación regular de las soluciones desarrolladas por Gosign se realiza, como norma, en la infraestructura del cliente. El hosting por Gosign es un servicio adicional que se acuerda por separado.</p>
<p><strong>Enablement y transferencia de conocimiento:</strong> El objetivo de Gosign es capacitar al cliente para operar y desarrollar de forma autónoma las soluciones entregadas. En la medida en que se acuerde, el alcance de los servicios incluye formación, documentación y una transferencia de conocimiento estructurada, orientada a reducir sistemáticamente la dependencia del cliente respecto a Gosign.</p>
<p><strong>Delimitación:</strong> Gosign presta servicios técnicos. Las soluciones desarrolladas por Gosign no sustituyen el asesoramiento jurídico, fiscal ni de recursos humanos. Las decisiones profesionales finales corresponden al cliente. Los sistemas del cliente (p. ej., SAP, Workday, SuccessFactors, DATEV) siguen siendo el sistema maestro (System of Record); las soluciones de Gosign se integran con estos sistemas, pero no los sustituyen.</p>
<p><strong>Base de clientes:</strong> Las presentes CGC se dirigen exclusivamente a empresarios en el sentido del § 14 del Código Civil alemán (BGB). Se aplican directamente a clientes con sede en la UE/EEE. Para clientes fuera de la UE/EEE, se aplican cuando se haya acordado la aplicación del derecho alemán. Gosign no celebra contratos con consumidores.</p>
<p>Los acuerdos individuales y los SLA prevalecen sobre estas CGC. Las condiciones divergentes del cliente no se aplican salvo que Gosign haya consentido expresamente por escrito.</p>

<h2>§ 2 Definiciones</h2>
<p>Los siguientes términos se utilizan en estas CGC con el significado que se indica a continuación:</p>
<p><strong>«Agent»</strong> designa un componente de software que, basándose en modelos de IA y conjuntos de reglas, ejecuta o prepara automáticamente tareas por cuenta del cliente (p. ej., Document Agent, Workflow Agent, Knowledge Agent).</p>
<p><strong>«Audit Trail»</strong> designa el registro completo y cronológico de todos los Decision Records y eventos del sistema.</p>
<p><strong>«Auditor Portal»</strong> designa una interfaz web a través de la cual auditores autorizados (internos o externos) pueden consultar el estado en tiempo real de todos los Controls y Evidence.</p>
<p><strong>«Cert-Ready»</strong> designa la propiedad de una arquitectura de sistema que cumple los requisitos técnicos previos para certificaciones estándar del sector (p. ej., ISO 27001, SOC 2, IDW PS 951) - sin que ello implique la obligación de obtener la certificación en sí ni su garantía.</p>
<p><strong>«Component Manifest»</strong> designa el documento adjunto a la oferta como anexo que clasifica cada componente de software esencial como resultado de trabajo específico del cliente (§ 7.1) o como componente de plataforma (§ 7.2). Los detalles se regulan en el § 7.2, apartado 4.</p>
<p><strong>«Control»</strong> designa una regla de verificación implementada técnicamente que garantiza el cumplimiento de un determinado estándar de conformidad o gobernanza (p. ej., «Ninguna decisión salarial sin el principio de cuatro ojos»).</p>
<p><strong>«Decision Layer»</strong> designa la capa de gobernanza y control desarrollada por Gosign que descompone los procesos empresariales en decisiones individuales y determina para cada paso si decide un ser humano, se aplica un conjunto de reglas o la IA actúa de forma autónoma.</p>
<p><strong>«Decision Record»</strong> designa la documentación automática e inmutable de una decisión individual dentro del Decision Layer, compuesta por datos de entrada, regla/versión del modelo aplicada, grado de confianza, ruta de decisión y resultado.</p>
<p><strong>«Evidence»</strong> designa una prueba generada automáticamente de que un Control se cumplió en un momento determinado.</p>
<p><strong>«Human-in-the-Loop»</strong> designa un principio arquitectónico según el cual determinadas decisiones requieren aprobación humana antes de su ejecución. La clasificación de las decisiones que requieren aprobación humana se determina conjuntamente con el cliente durante el proyecto.</p>
<p><strong>«Maintenance»</strong> designa el contrato de mantenimiento anual opcional para componentes de plataforma, que comprende mantenimiento continuo, actualizaciones de seguridad y desarrollo evolutivo. Los detalles se regulan en el § 7.7.</p>
<p><strong>«Perpetual License»</strong> designa el derecho de uso permanente del cliente sobre la versión respectiva entregada de los componentes de plataforma conforme al § 7.2, apartado 2. El derecho de uso subsiste con independencia de la existencia de un contrato de mantenimiento.</p>
<p><strong>«Componentes de plataforma» (Plattform-Komponenten)</strong> designa el núcleo técnico reutilizable de las soluciones de Gosign, en particular la Decision Engine, el framework de motor de reglas, la arquitectura de Audit Trail y los módulos de orquestación. Los detalles se regulan en el § 7.2, apartado 1.</p>
<p><strong>«Transferencia de código fuente» (Quellcode-Transfer)</strong> designa la cesión del derecho de uso exclusivo de los componentes de software desarrollados individualmente para el cliente, incluyendo código fuente, prompts, conjuntos de reglas (Rule Sets), configuraciones y documentación.</p>
<p><strong>«Software Bill of Materials (SBOM)»</strong> designa la relación de todos los componentes de código abierto utilizados en la solución y sus licencias conforme al § 7.4.</p>
<p><strong>«System of Record»</strong> designa el sistema maestro del cliente para datos maestros y transaccionales (p. ej., SAP, Workday, SuccessFactors, DATEV). Las soluciones de Gosign se integran con el System of Record, pero no lo sustituyen.</p>
<p><strong>«Terceros autorizados» (Zulässige Dritte)</strong> designa los destinatarios enumerados de forma exhaustiva en el § 7.1, apartado 3, a los que el cliente puede transmitir resultados de trabajo y componentes de plataforma sin necesidad de consentimiento adicional de Gosign.</p>

<h2>§ 3 Celebración del contrato</h2>
<p><strong>Oferta y pedido:</strong> La presentación de servicios por parte de Gosign no constituye, por regla general, una oferta contractual vinculante. El contrato se perfecciona mediante el encargo del cliente y la aceptación por parte de Gosign en un plazo de 14 días naturales.</p>
<p>El contrato se perfecciona únicamente cuando Gosign confirma el pedido en forma textual o inicia la ejecución.</p>
<p><strong>Contrato marco y fases del proyecto:</strong> El contrato puede celebrarse como contrato marco con fases encargadas individualmente. Cada fase puede encargarse por separado, sin obligación de encargar fases posteriores.</p>
<p><strong>Tipos de contrato por fase:</strong> Las fases de Discovery (análisis, consultoría, mapeo de procesos) se ejecutan como contratos de servicios (Dienstvertrag en derecho alemán); la obligación es la prestación del servicio de consultoría, no un resultado determinado. Las fases de Build (desarrollo, implementación, Proof of Concept) se ejecutan como contratos de obra (Werkvertrag) con recepción, salvo acuerdo en contrario. Las fases de Scale y Support se ejecutan como contratos de servicios; se aplican adicionalmente los SLA opcionales.</p>
<p>Los contratos pueden celebrarse por escrito, electrónicamente o en forma textual. Gosign conserva el texto del contrato y estas CGC.</p>

<h2>§ 4 Servicios de Gosign</h2>
<p>Gosign presta los servicios convenidos contractualmente de forma profesional y con la diligencia de un comerciante ordenado (Sorgfalt eines ordentlichen Kaufmanns). Gosign está autorizada a emplear personal cualificado, auxiliares o subcontratistas.</p>
<p><strong>Lugar de prestación:</strong> Los servicios se prestan, como norma, de forma remota. Gosign despliega personal en diversas ubicaciones y garantiza el cumplimiento de los estándares de seguridad y protección de datos acordados con independencia de la ubicación. Las intervenciones presenciales se acuerdan por separado.</p>
<p><strong>Coordinación del proyecto:</strong> Ambas partes designan personas de contacto. Gosign informa regularmente sobre el avance del proyecto.</p>
<p><strong>Plazos:</strong> Los plazos solo son vinculantes cuando se hayan acordado expresamente como tales. Los retrasos no atribuibles a Gosign amplían los plazos de forma proporcional.</p>
<p><strong>Solicitudes de cambio (Change Requests):</strong> Los cambios en el alcance de los servicios requieren un acuerdo escrito sobre costes adicionales y plazos.</p>
<p><strong>Proof of Concept (PoC):</strong> Cuando se acuerde un PoC, se aplican los criterios de éxito definidos en la oferta. Un PoC sirve para validar la viabilidad técnica. Los resultados del trabajo del PoC se transfieren al cliente tras el pago íntegro, salvo acuerdo en contrario.</p>
<p><strong>Entregas parciales:</strong> Gosign está autorizada a realizar entregas parciales razonables.</p>
<h3>4.1 Recepción de la obra (Abnahme)</h3>
<p>El cliente revisa las entregas de obra en un plazo de 14 días naturales y declara la recepción o comunica defectos. La falta de respuesta implica la recepción, siempre que se haya informado al cliente de esta consecuencia. Los defectos menores no autorizan al cliente a rechazar la recepción.</p>

<h2>§ 5 Obligaciones de cooperación del cliente</h2>
<p>El cliente proporciona de forma oportuna todos los documentos, información, datos y accesos necesarios.</p>
<p>El cliente designa una persona de contacto cualificada con capacidad de decisión.</p>
<p><strong>Infraestructura técnica:</strong> Cuando los servicios se presten en los sistemas del cliente, este proporciona la infraestructura. Gosign informa sobre los requisitos del sistema.</p>
<p><strong>Pruebas y recepciones:</strong> El cliente colabora activamente, documenta errores y no retrasa injustificadamente las aprobaciones.</p>
<p><strong>Mantenimiento y copias de seguridad:</strong> El cliente instala de forma autónoma y oportuna las actualizaciones de seguridad, salvo que exista un contrato de mantenimiento con Gosign. Las copias de seguridad regulares son responsabilidad del cliente.</p>
<p><strong>Legalidad:</strong> El cliente es responsable de la legalidad de todos los contenidos y datos proporcionados e indemniza a Gosign frente a reclamaciones de terceros.</p>
<p>Los retrasos y costes adicionales derivados del incumplimiento de las obligaciones de cooperación corren a cargo del cliente.</p>

<h2>§ 6 Disposiciones especiales para infraestructura de IA y desarrollo de agentes</h2>
<h3>6.1 Alcance de los servicios</h3>
<p>El alcance de los servicios se define en la oferta y puede comprender: integración y adaptación de modelos de IA, desarrollo de agentes de IA, implementación del Decision Layer, consultoría en infraestructura de IA, FinOps, conceptos de seguridad y cumplimiento, formación.</p>
<p>La oferta indica qué componentes de plataforma (§ 7.2) se utilizan e incluye un Component Manifest como anexo.</p>
<h3>6.2 Arquitectura de tres niveles y responsabilidades</h3>
<p>Las soluciones de IA desarrolladas por Gosign distinguen tres niveles de procesamiento con diferentes responsabilidades:</p>
<p>(a) <strong>Análisis (modelo de IA):</strong> El modelo lingüístico analiza datos y genera propuestas. Los modelos de IA producen resultados probabilísticos; Gosign es responsable de la integración y configuración adecuadas del modelo, no de la exactitud del contenido de cada resultado individual.</p>
<p>(b) <strong>Decisión (Decision Layer):</strong> El Decision Layer aplica conjuntos de reglas, umbrales y procesos de aprobación definidos a los resultados del análisis. Gosign es responsable de la correcta implementación de la lógica de decisión acordada. Los errores en la implementación de reglas son defectos de software sujetos a garantía.</p>
<p>(c) <strong>Ejecución (integración/herramienta):</strong> Los resultados se transmiten a los sistemas objetivo del cliente (p. ej., SAP, DATEV, Workday). Gosign es responsable de la correcta integración técnica. Los errores en el sistema objetivo del cliente son responsabilidad de este.</p>
<h3>6.3 Human-in-the-Loop</h3>
<p>Para las decisiones clasificadas como de alto riesgo (en particular, decisiones de personal, decisiones salariales, decisiones sujetas a codecisión del comité de empresa), Human-in-the-Loop es el estándar salvo acuerdo expreso en contrario. La clasificación de las decisiones que requieren aprobación humana se determina conjuntamente y se configura en el Decision Layer. El cliente sigue siendo responsable de las decisiones profesionales finales.</p>
<h3>6.4 Enfoque model-agnostic</h3>
<p>Gosign utiliza modelos de IA de distintos proveedores (enfoque model-agnostic). La selección se realiza en consulta con el cliente. Gosign informa sobre los cambios de modelo previstos. En caso de que un proveedor suspenda su servicio, Gosign propondrá oportunamente un modelo alternativo equivalente. Gosign no se responsabiliza de la disponibilidad o suspensión de servicios de terceros.</p>
<h3>6.5 Bias Monitoring</h3>
<p>En la medida en que se acuerde, Gosign implementa mecanismos para la detección y documentación de sesgos sistemáticos (Bias Monitoring). La verificación continua durante la operación corresponde al cliente, salvo que exista un contrato de mantenimiento.</p>
<h3>6.6 Uso de datos para IA</h3>
<p>El cliente sigue siendo propietario y responsable de todos los datos proporcionados a Gosign. Gosign los utiliza exclusivamente para la ejecución del contrato. El cliente garantiza que posee los derechos necesarios. Cuando se utilicen modelos o APIs de IA externos, esto se hará exclusivamente bajo condiciones que excluyan el uso de los datos del cliente para el entrenamiento de los modelos, salvo que el cliente haya autorizado expresamente lo contrario.</p>
<h3>6.7 FinOps y costes dependientes del consumo</h3>
<p>Los costes de terceros dependientes del consumo (tarifas de API, tiempo de cómputo de GPU) los asume el cliente, salvo acuerdo en contrario. Gosign informa previamente sobre la estructura de costes y proporciona informes de consumo transparentes.</p>
<h3>6.8 Requisitos regulatorios</h3>
<p>Gosign aborda los requisitos del Reglamento (UE) 2024/1689 (Ley de IA de la UE) como principios arquitectónicos técnicos (Readiness). La evaluación jurídica del cumplimiento para el contexto de despliegue concreto corresponde al cliente y sus asesores jurídicos. Gosign apoya al cliente en la implementación de requisitos regulatorios cuando así se encargue.</p>
<h3>6.9 Indemnización</h3>
<p>El uso de los sistemas de IA es responsabilidad exclusiva del cliente. El cliente indemniza a Gosign frente a reclamaciones de terceros derivadas del uso indebido o ilícito.</p>

<h2>§ 7 Derechos de uso, propiedad intelectual y acceso al código fuente</h2>
<h3>7.1 Derechos de uso sobre resultados de trabajo específicos del cliente</h3>
<p>El cliente recibe, tras el pago íntegro, un derecho de uso permanente, territorialmente ilimitado y no exclusivo sobre los siguientes resultados de trabajo específicos del cliente:</p>
<p>(a) Configuraciones específicas del cliente (conjuntos de reglas, Decision Tables, políticas, reglas de enrutamiento, modelos de datos específicos del cliente, tablas de decisión)</p>
<p>(b) Prompts y plantillas de prompts desarrollados para el cliente y designados como específicos del cliente en el Component Manifest</p>
<p>(c) Integraciones y adaptadores específicos del cliente conforme al Component Manifest (p. ej., conexiones SAP específicas del cliente, conectores de API, textos de interfaz de usuario)</p>
<p>(d) Documentación técnica de la solución específica del cliente</p>
<p>(e) Datos y configuraciones del cliente en todos los formatos</p>
<p>La asignación al § 7.1 o al § 7.2 resulta del Component Manifest conforme al § 7.2, apartado 4.</p>
<p>El derecho de uso incluye el derecho a modificar y desarrollar la solución para el propio negocio del cliente.</p>
<p>La transmisión a terceros o la sublicencia requiere el consentimiento previo por escrito de Gosign. <strong>No se requiere consentimiento para la transmisión a terceros autorizados.</strong> Los terceros autorizados son:</p>
<p>(i) Empresas vinculadas al cliente en el sentido de los §§ 15 y siguientes de la Ley alemana de Sociedades Anónimas (AktG) o conforme a legislación extranjera comparable sobre grupos de empresas (sociedades del grupo, filiales, unidades de servicios compartidos)</p>
<p>(ii) Proveedores de servicios informáticos y encargados del tratamiento del cliente, sujetos a obligaciones de confidencialidad y limitación de finalidad</p>
<p>(iii) Auditores, auditoría interna y autoridades reguladoras en el marco de obligaciones legales o contractuales de auditoría</p>
<p>(iv) Sucesores legales del cliente en caso de reestructuración, fusión o cesión de activos, siempre que la transmisión se realice en el marco de una transferencia del negocio en el que se utiliza la solución y el sucesor legal asuma las obligaciones del § 7; queda excluida la transmisión a competidores directos de Gosign</p>
<p>El cliente garantiza que los terceros autorizados cumplen obligaciones de protección y confidencialidad al menos equivalentes.</p>
<p>El § 7.1 prevalece sobre la disposición general de cesión del § 19 en lo que respecta a la transmisión a terceros autorizados o sucesores legales.</p>
<p>El cliente tiene, a más tardar desde el despliegue de la solución en su infraestructura, o en caso contrario a más tardar con la recepción o el pago íntegro, acceso completo al código fuente de todos los componentes operados en su entorno - incluidos los componentes de plataforma conforme al § 7.2. Acceso significa código fuente legible, no deliberadamente ofuscado, en un repositorio gestionado en el entorno del cliente o como exportación de código (al menos tras cada lanzamiento productivo y, previa solicitud, en un plazo de 10 días hábiles), incluyendo instrucciones de compilación (build) y registro de dependencias (Dependency Lockfiles). Las exportaciones de código adicionales fuera de los lanzamientos regulares se proporcionan de forma gratuita hasta dos veces por trimestre; las exportaciones que excedan este número se facturan por tiempo empleado.</p>

<h3>7.2 Componentes de plataforma de Gosign</h3>
<p>Gosign utiliza en el desarrollo sus propios componentes de plataforma. Los componentes de plataforma son el núcleo técnico reutilizable, en particular la Decision Engine, el framework de motor de reglas, la arquitectura de Audit Trail y los módulos de orquestación (en adelante, «componentes de plataforma»). La propiedad intelectual exclusiva y los derechos de uso sobre estos componentes de plataforma permanecen en Gosign.</p>
<p>El cliente recibe un <strong>derecho de uso permanente sobre la versión respectiva entregada</strong> de los componentes de plataforma (Perpetual License). Este derecho de uso es no exclusivo y comprende la operación, la configuración y la integración en los sistemas del cliente para su propio negocio. El derecho de uso subsiste con independencia de la existencia de un contrato de mantenimiento. Las reglas de transmisión del § 7.1 (incluidos los terceros autorizados y la obligación de transmisión de condiciones - flow-down) se aplican por analogía.</p>
<p>El cliente tiene, desde el despliegue (o con la recepción/pago conforme al § 7.1), acceso completo al código fuente de todos los componentes de plataforma operados en su infraestructura. Gosign proporciona documentación técnica completa, incluyendo instrucciones de compilación. El código fuente no se ofusca deliberadamente (sin obfuscation, sin dificultad deliberada de lectura). El cifrado del código fuente en reposo y en tránsito para la protección de la integridad no se ve afectado por esta disposición.</p>
<p>Los componentes de plataforma se identifican en la oferta mediante un <strong>Component Manifest</strong>. El Component Manifest <strong>enumera al menos todos los componentes de plataforma esenciales</strong> y asigna cada componente al § 7.1 (específico del cliente) o al § 7.2 (plataforma). El Component Manifest es determinante para la asignación. <strong>Las modificaciones del Component Manifest requieren forma textual y se acuerdan como adenda a la oferta o mediante Change Request.</strong> Los componentes no incluidos en el Manifest se consideran específicos del cliente en el sentido del § 7.1, salvo que sean componentes de código abierto o de terceros o que ya se utilicen como componentes de plataforma en otros proyectos de clientes; una aclaración mediante adenda sigue siendo posible.</p>
<p>El código fuente de los componentes de plataforma es <strong>información confidencial y secreto comercial de Gosign</strong> en el sentido del § 14. El cliente puede consultar el código fuente, utilizarlo para la finalidad contractual y transmitirlo a terceros autorizados conforme al § 7.1 con cumplimiento de la obligación de transmisión de condiciones. Cualquier uso, transmisión o explotación que exceda de lo anterior es inadmisible. El cliente protege el código fuente de los componentes de plataforma al menos con la misma diligencia que sus propios secretos comerciales.</p>
<p>El cliente no puede utilizar los componentes de plataforma, incluyendo el código fuente y el know-how obtenido de ellos, para el desarrollo, la comercialización o la prestación de un producto o servicio que compita con Gosign ni para la productización para terceros.</p>

<h3>7.3 Source Code Escrow</h3>
<p>A solicitud del cliente, Gosign deposita el código fuente completo de todos los componentes de plataforma, incluyendo instrucciones de compilación, Dependency Lockfiles y documentación de despliegue, ante un proveedor independiente de servicios de escrow. Los costes del depósito los asume el cliente, salvo acuerdo diferente en la oferta.</p>
<p>Gosign concede al cliente ya en el momento de la celebración del contrato, bajo condición suspensiva del respectivo evento de liberación, todos los derechos de uso sobre los componentes de plataforma, incluyendo el derecho a modificar, desarrollar y operar de forma autónoma. La condición suspensiva se cumple en los siguientes casos:</p>
<p>(a) Solicitud de insolvencia de Gosign (apertura o desestimación por insuficiencia de masa)</p>
<p>(b) <strong>Cese del soporte del producto:</strong> Gosign deja de proporcionar actualizaciones de seguridad para los componentes de plataforma utilizados en un plazo de 90 días naturales desde el conocimiento de una vulnerabilidad crítica, sin ofrecer dentro de dicho plazo una solución sucesora equivalente, o declara oficialmente el fin de vida (End-of-Life) del componente. Se entiende por vulnerabilidad crítica en el sentido de esta cláusula una brecha de seguridad clasificada como alta o crítica según estándares internacionalmente reconocidos (en particular, CVSS). Pueden acordarse criterios más detallados en el convenio de escrow. Una solución sucesora equivalente cubre al menos las funciones esenciales del componente sustituido y garantiza un nivel de seguridad comparable. Pueden acordarse requisitos más detallados en el convenio de escrow.</p>
<p>(c) Incumplimiento contractual esencial por parte de Gosign que no se subsane a pesar de un requerimiento por escrito con un plazo de 60 días naturales.</p>
<p>Los detalles técnicos del depósito, la actualización y la entrega se regulan en un convenio de escrow independiente entre Gosign, el cliente y el proveedor de servicios de escrow. Este comprende, en particular: alcance del depósito (repositorio, claves, cadena de compilación, documentación, dependencias), frecuencia de actualización, condiciones de liberación (Release Conditions), derecho de verificación del cliente y mecánica de entrega.</p>

<h3>7.4 Componentes de código abierto</h3>
<p>Gosign utiliza software de código abierto siempre que sea posible. Los derechos del cliente sobre componentes de código abierto se rigen por las condiciones de licencia correspondientes (p. ej., MIT, Apache, GPL). Gosign proporciona al cliente una relación de los componentes de código abierto utilizados y sus licencias (Software Bill of Materials). El cliente se compromete a cumplir estas condiciones de licencia. Cuando el código individual se base en componentes de código abierto y pueda, por tanto, quedar sujeto a sus condiciones de licencia, Gosign informará al cliente.</p>
<p>Gosign no utiliza componentes bajo licencias copyleft (en particular, GPL, AGPL), salvo que estén expresamente identificados en la oferta y hayan sido consentidos por el cliente.</p>

<h3>7.5 Componentes reutilizables y aislamiento de mandantes</h3>
<p>Gosign desarrolla los componentes de plataforma de forma continua y los utiliza en proyectos para diversos clientes. Las configuraciones específicas, los secretos comerciales y los datos de cada cliente no se incorporan a otros proyectos.</p>
<p>La arquitectura técnica garantiza, conforme al estado de la técnica, mediante el aislamiento de mandantes (Mandantenisolation), que los datos de los clientes permanecen estrictamente separados. Esto comprende, en particular, la separación a nivel de datos, logs, historiales de prompts, almacenamiento y claves específicas del mandante. Gosign documenta la arquitectura de aislamiento previa solicitud.</p>

<h3>7.6 Derecho de uso restringido (alternativa para proyectos de software puros)</h3>
<p>Cuando en la oferta no se utilicen componentes de plataforma ni se acuerde un Component Manifest (en particular, en proyectos de desarrollo de software puros sin uso del Decision Layer), el cliente recibe un derecho de uso permanente, territorialmente ilimitado y no exclusivo sobre los desarrollos individuales. El derecho de uso incluye el derecho a modificar y desarrollar la solución para el propio negocio del cliente. Las reglas de transmisión conforme al § 7.1, apartado 3 (incluidos los terceros autorizados y la obligación de transmisión de condiciones) se aplican por analogía.</p>

<h3>7.7 Tasas de licencia y mantenimiento</h3>
<p>Los resultados de trabajo específicos del cliente (§ 7.1) no generan tasas de licencia periódicas.</p>
<p>Para los componentes de plataforma de Gosign (§ 7.2) se aplica lo siguiente: el derecho de uso sobre la versión entregada (Perpetual License) está <strong>incluido en la remuneración acordada en la oferta</strong>. Solo se devengan tasas periódicas adicionales cuando estén expresamente indicadas en la oferta.</p>
<p>Para el <strong>mantenimiento continuo, las actualizaciones de seguridad y el desarrollo evolutivo</strong> de los componentes de plataforma puede acordarse un contrato de mantenimiento anual (Maintenance). El tipo, alcance, tiempos de respuesta y cuantía de las tasas de mantenimiento se indican de forma transparente en la oferta respectiva.</p>
<p><strong>Si el cliente resuelve el contrato de mantenimiento, el derecho de uso sobre la última versión entregada subsiste íntegramente.</strong> El cliente no recibirá entonces más actualizaciones, parches de seguridad ni soporte técnico para los componentes de plataforma. Gosign recomienda en este caso la celebración de un convenio de Source Code Escrow conforme al § 7.3.</p>
<p>Sin acuerdo expreso en la oferta, no se devengan tasas periódicas.</p>

<h3>7.8 Modificaciones del cliente en componentes de plataforma</h3>
<p>El cliente tiene derecho a modificar los componentes de plataforma para su propio negocio. Gosign proporciona, en la medida de lo posible, puntos de extensión documentados (Extension Points) que permiten cambios sin intervención en el núcleo de la plataforma.</p>
<p>Si el cliente realiza cambios en los componentes de plataforma <strong>fuera de los Extension Points documentados</strong>, la garantía y el derecho a soporte para las partes afectadas quedan suspendidos hasta que (a) los cambios se reviertan o (b) Gosign realice un análisis remunerado y confirme la compatibilidad.</p>
<p><strong>El cliente coopera razonablemente para que las actualizaciones de seguridad de Gosign puedan instalarse incluso en presencia de modificaciones del cliente.</strong> Si el cliente deniega la cooperación necesaria o si sus modificaciones bloquean la instalación de una actualización de seguridad, Gosign tiene derecho a suspender el soporte para los componentes afectados hasta que se resuelva el bloqueo. Existe un bloqueo cuando la actualización no puede instalarse con un esfuerzo razonable porque las modificaciones del cliente fuera de los Extension Points afectan a la compatibilidad.</p>
<p>Las obligaciones de seguridad del cliente conforme al § 9 no se ven afectadas por las modificaciones.</p>

<h3>7.9 Contribuciones del cliente a componentes de plataforma</h3>
<p>Cuando esté previsto en la oferta o en un acuerdo independiente, el cliente puede presentar correcciones de errores, propuestas de mejora o extensiones para los componentes de plataforma («contribuciones»).</p>
<p>El cliente concede a Gosign sobre dichas contribuciones un derecho de uso simple, no exclusivo, temporal y territorialmente ilimitado, en la medida en que las contribuciones se refieran a componentes de plataforma y no contengan secretos comerciales ni configuraciones específicas del cliente. Gosign puede incorporar estas contribuciones a los componentes de plataforma y ponerlas a disposición de todos los clientes.</p>
<p>Esta cláusula no establece ninguna obligación del cliente de presentar contribuciones.</p>

<h3>7.10 Momento de la entrega</h3>
<p>La entrega de los resultados de trabajo (incluyendo repositorio de código fuente, documentación, Component Manifest, configuraciones y Software Bill of Materials) se realiza a más tardar con la recepción de la última fase del proyecto y el pago íntegro. Gosign apoyará activamente la entrega y concederá al cliente acceso completo.</p>

<h2>§ 8 Hosting y servicios operativos</h2>
<p>La operación regular de las soluciones desarrolladas por Gosign se realiza en la infraestructura del cliente. El hosting por Gosign es un servicio adicional opcional. Cuando el cliente utilice hosting, se aplican las siguientes condiciones:</p>
<p><strong>Managed Services en infraestructura del cliente:</strong> Cuando Gosign opere la solución en el entorno cloud del cliente, las disposiciones de hosting se aplican por analogía. La responsabilidad de la infraestructura base corresponde al cliente. Gosign es responsable de la capa de aplicación.</p>
<p><strong>Centro de datos:</strong> El hosting se realiza en Alemania o la UE, salvo acuerdo en contrario. Las preferencias del cliente deben comunicarse en el momento de la celebración del contrato.</p>
<p><strong>Disponibilidad:</strong> Sin SLA, no se garantiza una disponibilidad mínima. Gosign aspira a una alta disponibilidad.</p>
<p><strong>Ventanas de mantenimiento:</strong> Mantenimiento planificado fuera del horario laboral con aviso previo.</p>
<p><strong>Copias de seguridad:</strong> Copia de seguridad diaria con retención rotativa de 7 días, salvo acuerdo en contrario.</p>
<p><strong>Transition y exit:</strong> Tras la finalización de los servicios de hosting, Gosign apoya al cliente durante hasta 90 días en la migración (Transition). La Transition se factura por tiempo y materiales. Todos los datos del cliente son completamente exportables en formatos estándar.</p>

<h2>§ 9 Seguridad, mantenimiento y actualizaciones</h2>
<p><strong>Actualizaciones de seguridad obligatorias:</strong> Gosign puede instalar actualizaciones de seguridad sin consentimiento previo del cliente cuando la demora comprometa la seguridad. El cliente es informado con posterioridad.</p>
<p><strong>Deber de tolerancia:</strong> El cliente no puede rechazar actualizaciones de seguridad. La seguridad e integridad del sistema tienen prioridad.</p>
<p><strong>Rechazo:</strong> En caso de rechazo de una medida de seguridad, Gosign puede suspender los servicios. Se excluyen las reclamaciones del cliente por daños resultantes.</p>
<p><strong>Actualizaciones opcionales:</strong> Las actualizaciones no relacionadas con la seguridad requieren acuerdo previo.</p>
<p><strong>Pruebas de penetración:</strong> El cliente puede realizar auditorías de seguridad o pruebas de penetración con un preaviso mínimo de 14 días naturales, siempre que se garantice la confidencialidad. Los detalles pueden regularse en un SLA.</p>
<p><strong>Respuesta a incidentes:</strong> En caso de un incidente de seguridad que afecte a la disponibilidad, integridad o confidencialidad de los datos o sistemas del cliente, Gosign informa al cliente sin demora indebida, a más tardar en 24 horas desde su conocimiento, y adopta medidas inmediatas de contención. La notificación inicial y las medidas inmediatas forman parte del servicio contractual. Los servicios adicionales (en particular, análisis forense, determinación de la causa raíz y elaboración de un informe de incidentes detallado) se facturan por tiempo y materiales, salvo que el incidente sea atribuible a Gosign. Cuando Gosign sea responsable del incidente, todas las medidas de análisis y subsanación se proporcionan al cliente sin coste.</p>

<h2>§ 10 Remuneración y condiciones de pago</h2>
<p>Los precios resultan de la oferta, más el IVA aplicable.</p>
<p>Facturación por tiempo y materiales o precio fijo según lo acordado.</p>
<p>Gastos accesorios y de viaje solo previa aprobación.</p>
<p><strong>Plazo de pago:</strong> 14 días naturales, salvo acuerdo en contrario. Pueden acordarse plazos de pago individuales. Intereses de demora: 9 puntos porcentuales sobre el tipo de interés base (§ 288, apartado 2, BGB).</p>
<p>Pagos a cuenta en proyectos de mayor duración según el plan de hitos.</p>
<p>Compensación solo con contracréditos no disputados o legalmente establecidos.</p>

<h2>§ 11 Responsabilidad</h2>
<p><strong>Ilimitada:</strong> Por dolo, negligencia grave, lesión de vida/cuerpo/salud, garantía, responsabilidad por producto.</p>
<p><strong>Obligaciones cardinales (Kardinalpflichten):</strong> Por negligencia leve, limitada al daño típicamente previsible del contrato.</p>
<p><strong>Límite máximo de responsabilidad:</strong> La responsabilidad de Gosign por daños derivados del incumplimiento de obligaciones cardinales se limita por incidente a la remuneración neta acordada en el contrato individual afectado. La responsabilidad total de Gosign en una relación contractual se limita al doble de la remuneración neta anual. Pueden acordarse límites máximos de responsabilidad diferentes en los contratos individuales.</p>
<p><strong>Daños indirectos, consecuenciales y lucro cesante:</strong> Excluidos, salvo dolo, negligencia grave o incumplimiento de obligaciones cardinales.</p>
<p><strong>Pérdida de datos:</strong> Responsabilidad solo por el coste de restauración a partir de las copias de seguridad adecuadas del cliente.</p>
<p><strong>Resultados de IA:</strong> Sin responsabilidad por decisiones basadas en resultados de IA, siempre que Gosign no haya incumplido obligaciones cardinales (véase § 6.2).</p>
<p><strong>Seguro:</strong> Gosign mantiene un seguro de responsabilidad civil profesional y empresarial conforme al mercado. Acreditación disponible previa solicitud.</p>
<p><strong>Prescripción:</strong> Dos años; no aplicable en caso de dolo, negligencia grave o daños personales.</p>

<h2>§ 12 Reclamaciones por defectos (garantía)</h2>
<p><strong>Plazo de garantía:</strong> 12 meses desde la recepción por defectos de calidad y de título (Sach- und Rechtsmängel).</p>
<p>Los defectos deben comunicarse sin demora en forma textual. Subsanación mediante reparación o sustitución.</p>
<p>Fracaso tras dos intentos: Reducción del precio o resolución del contrato.</p>
<p>Sin garantía por desviaciones insignificantes o perturbaciones causadas por el cliente.</p>
<p>Los errores en software de código abierto o de terceros no constituyen un defecto de los servicios de Gosign, siempre que estén correctamente integrados.</p>
<p>La garantía de los componentes de plataforma está sujeta a las restricciones del § 7.8 (modificaciones del cliente).</p>
<p>En relaciones contractuales de tracto sucesivo: Se aplican las disposiciones legales para contratos de servicios/arrendamiento.</p>

<h2>§ 13 Protección de datos y tratamiento por encargo</h2>
<p>Ambas partes cumplen el RGPD, la Ley Federal alemana de Protección de Datos (BDSG) y demás legislación de protección de datos aplicable.</p>
<p>Cuando el cliente trate datos sujetos a la LGPD brasileña u otras leyes internacionales de protección de datos, Gosign apoya en el cumplimiento.</p>
<p>Gosign actúa como encargado del tratamiento (Art. 28 RGPD). Las partes celebrarán un contrato de encargo de tratamiento de datos (Auftragsverarbeitungsvertrag, AVV).</p>
<p>Gosign acepta también contratos de tratamiento de datos proporcionados por el cliente, siempre que sean conformes con el RGPD.</p>
<p>Gosign implementa medidas técnicas y organizativas adecuadas (Art. 32 RGPD).</p>
<p>Subencargados con consentimiento general, siempre que estén contractualmente obligados a un nivel de protección de datos equivalente.</p>
<p><strong>Data Residency:</strong> Previa solicitud, garantía contractual de que el tratamiento de datos se realiza exclusivamente en Alemania o un Estado miembro determinado de la UE/EEE. En caso de llamadas API de IA a terceros países, información previa y - cuando sea técnicamente viable - endpoints europeos.</p>
<p>En caso de violaciones de datos: Notificación inmediata y cooperación en las obligaciones de comunicación.</p>

<h2>§ 14 Confidencialidad</h2>
<p>Ambas partes tratan la información confidencial con estricta confidencialidad.</p>
<p><strong>Excepciones:</strong> Públicamente conocida, previamente conocida, desarrollada independientemente, obligación legal.</p>
<p><strong>Divulgación:</strong> Solo con criterio de necesidad de conocimiento (need-to-know), a empleados sujetos a obligaciones de confidencialidad.</p>
<p><strong>Estándar de protección:</strong> Ambas partes protegen la información confidencial al menos con la misma diligencia que sus propios secretos comerciales, y en todo caso mediante medidas técnicas y organizativas adecuadas conforme al estado de la técnica.</p>
<p><strong>Duración:</strong> 5 años tras la finalización del contrato. Para la información identificada como secreto comercial (en particular conforme al § 7.2, apartado 5), la obligación de confidencialidad se mantiene más allá de la duración del contrato.</p>
<p><strong>Devolución y destrucción:</strong> A solicitud, a más tardar al finalizar el contrato.</p>
<p><strong>Uso como referencia:</strong> Gosign solo podrá utilizar el nombre y logotipo del cliente como referencia con el consentimiento previo por escrito del cliente.</p>

<h2>§ 15 Duración del contrato y resolución</h2>
<p>15.1 Los contratos de proyecto finalizan con la recepción de la última entrega y el pago íntegro.</p>
<p>15.2 Relaciones contractuales de tracto sucesivo: Duración mínima de 12 meses. A partir de entonces, renovación automática por períodos de 12 meses, con posibilidad de resolución con un preaviso de 3 meses al final del período en curso.</p>
<p>15.2a Para los contratos de mantenimiento conforme al § 7.7 (Maintenance) se aplican las disposiciones para relaciones contractuales de tracto sucesivo del apartado 2 por analogía, salvo que en el contrato de mantenimiento se acuerden plazos y períodos de preaviso diferentes.</p>
<p>15.3 Resolución extraordinaria en caso de: (a) incumplimiento sustancial de obligaciones tras un plazo de subsanación de 30 días; (b) insolvencia; (c) rechazo persistente de actualizaciones (§ 9); (d) uso ilícito del sistema.</p>
<p>15.4 Consecuencias de la finalización: Devolución/eliminación de todos los datos del cliente. Transition conforme al § 8. Los derechos de uso adquiridos subsisten tras el pago íntegro.</p>

<h2>§ 16 Cumplimiento, certificaciones y codecisión</h2>
<p><strong>16.1 Cert-Ready:</strong> Gosign diseña sus soluciones para cumplir los requisitos técnicos previos de las certificaciones estándar del sector (Cert-Ready by Design). Concretamente: los Controls están implementados como objetos de datos de primera clase en el sistema, la Evidence se genera automáticamente, el Audit Trail es completo y exportable, y se prevé el acceso a través de un Auditor Portal. La obtención de un certificado concreto no es un resultado contractual obligado y requiere un acuerdo separado entre cliente, auditor y Gosign.</p>
<p><strong>16.2 Comité de empresa y codecisión:</strong> Cuando las soluciones de IA se desplieguen en áreas sujetas a codecisión del comité de empresa conforme al § 87, apartado 1, número 6, BetrVG (Ley alemana de Constitución de Empresas), Gosign apoya en la preparación de documentación y materiales informativos para el comité de empresa. En España, derechos de información y consulta comparables corresponden al comité de empresa conforme al Art. 64 del Estatuto de los Trabajadores (ET). La implicación formal del comité de empresa y la celebración de acuerdos de empresa son responsabilidad del cliente. La arquitectura del Decision Layer está diseñada para implementar los acuerdos de empresa como reglas configurables y técnicamente ejecutables.</p>
<p><strong>16.3 Cumplimiento de sanciones:</strong> Gosign confirma que no mantiene relaciones comerciales con personas, entidades o estados sancionados.</p>
<p><strong>16.4 Sostenibilidad:</strong> Gosign considera aspectos de eficiencia energética en la selección de infraestructura. Información disponible previa solicitud.</p>

<h2>§ 17 Control de exportaciones</h2>
<p>El cliente cumple las normas de exportación y sanciones. Gosign señala los componentes sujetos a control de exportación. La ejecución se supedita a la inexistencia de impedimentos legales.</p>

<h2>§ 18 Fuerza mayor</h2>
<p>Sin responsabilidad por incumplimiento debido a fuerza mayor (catástrofes naturales, guerra, pandemias, conflictos laborales, medidas gubernamentales, fallos de infraestructura a gran escala). Notificación inmediata. Los plazos se amplían proporcionalmente. Derecho de resolución tras 3 meses.</p>

<h2>§ 19 Disposiciones finales</h2>
<p><strong>Derecho aplicable:</strong> Derecho alemán con exclusión de la Convención de las Naciones Unidas sobre los Contratos de Compraventa Internacional de Mercaderías (CISG).</p>
<p><strong>Jurisdicción:</strong> Hamburgo, Alemania (para comerciantes y personas jurídicas).</p>
<p><strong>Idioma del contrato:</strong> Alemán. Las versiones en otros idiomas sirven a la cooperación internacional; en caso de duda, prevalece la versión alemana.</p>
<p><strong>Versionado:</strong> Estas CGC llevan número de versión y fecha. La versión vigente está disponible en gosign.de/de/agb/.</p>
<p>Modificaciones en forma textual. Modificaciones de las CGC con 6 semanas de antelación; plazo de oposición de 4 semanas.</p>
<p><strong>Cesión:</strong> Cesión solo con consentimiento por escrito. La transmisión a terceros autorizados y sucesores legales conforme al § 7.1, apartado 3, no se ve afectada por esta disposición.</p>
<p>Cláusula de salvaguardia. Prevalencia de los acuerdos individuales.</p>

--- Accesibilidad y Directiva Europea 2019/882: Lo que su empresa debe saber ---
> Directiva Europea de Accesibilidad (2019/882): quién está afectado, qué significa una web accesible y qué sanciones existen.

<!-- ¿Qué es la Directiva 2019/882? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">¿Qué es la Directiva 2019/882 y por qué existe?</h2>
<p class="text-body text-gosign-text leading-relaxed">
La Directiva (UE) 2019/882, conocida como European Accessibility Act, establece un marco uniforme en toda la Unión Europea: los productos y servicios ofrecidos a consumidores deben ser accesibles para personas con discapacidad. Cada Estado miembro la ha transpuesto a su legislación nacional - en España, a través del Real Decreto 193/2023.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Esto afecta, entre otros, a sitios web y tiendas online. El objetivo es sencillo: quien quiera comprar, reservar o informarse en internet debe poder hacerlo independientemente de una limitación visual, auditiva o motriz. Desde el <strong>28 de junio de 2025</strong>, la normativa es de obligado cumplimiento y los incumplimientos pueden ser sancionados.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Para las empresas esto significa: la accesibilidad ya no es un gesto voluntario, sino una obligación legal. Comparable con el <a href="/es/conocimiento/obligaciones-rgpd-sitios-web/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">RGPD en protección de datos</a> - quien no conozca las reglas, arriesga sanciones.
</p>
</div>
</section>

<!-- ¿A quién afecta? -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">¿Me afecta la Directiva? Guía por tipo de organización</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
La Directiva 2019/882 se aplica a <strong>operadores económicos</strong> que comercializan productos o servicios para consumidores. Si le afecta depende menos de la forma jurídica y más de lo que hace.
</p>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse bg-white rounded-card">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Tipo de organización</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">¿Obligación?</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Explicación</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">S.L. / S.A. con tienda online</td>
<td class="py-3 px-4 text-body text-gosign-accent-text font-semibold">Sí</td>
<td class="py-3 px-4 text-body text-gosign-text">El comercio online es un servicio al consumidor. Obligación plena de accesibilidad.</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Empresa con web solo B2B</td>
<td class="py-3 px-4 text-body text-gosign-text font-semibold">No (formalmente)</td>
<td class="py-3 px-4 text-body text-gosign-text">La Directiva solo cubre servicios al consumidor. Los portales puramente empresariales están exentos, pero la accesibilidad sigue siendo recomendable.</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Fundación sin ánimo de lucro</td>
<td class="py-3 px-4 text-body text-gosign-text font-semibold">Generalmente no</td>
<td class="py-3 px-4 text-body text-gosign-text">Las fundaciones sin ánimo de lucro normalmente no están cubiertas. Pero: los organismos financiadores exigen cada vez más accesibilidad, y las fundaciones con oferta comercial (entradas, tienda) pueden estar afectadas.</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Microempresa (&lt; 10 empleados, &lt; 2 M EUR)</td>
<td class="py-3 px-4 text-body text-gosign-text font-semibold">Posible exención</td>
<td class="py-3 px-4 text-body text-gosign-text">Las microempresas con menos de 10 empleados y menos de 2 millones de euros de facturación pueden estar exentas en servicios.</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Asociación / ONG con web</td>
<td class="py-3 px-4 text-body text-gosign-text font-semibold">Depende</td>
<td class="py-3 px-4 text-body text-gosign-text">Las asociaciones no económicas generalmente no están cubiertas. Si la asociación ofrece servicios online de pago, la normativa puede aplicarse.</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Administración pública</td>
<td class="py-3 px-4 text-body text-gosign-accent-text font-semibold">Sí (vía Directiva 2016/2102)</td>
<td class="py-3 px-4 text-body text-gosign-text">Las administraciones públicas no caen bajo la Directiva 2019/882, sino bajo la Directiva 2016/2102, con requisitos similares y obligatoria desde 2020.</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Exención para microempresas -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">La exención para microempresas: ¿cuándo se aplica?</h2>
<p class="text-body text-gosign-text leading-relaxed">
La Directiva 2019/882 prevé una exención para microempresas: empresas con <strong>menos de 10 empleados</strong> y una <strong>facturación o balance anual inferior a 2 millones de euros</strong> están exentas en la prestación de servicios.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Pero cuidado: esta exención solo se aplica a <em>servicios</em>, no a productos. Si una microempresa vende productos físicos (por ejemplo, opera una tienda online de electrónica), sigue sujeta a los requisitos de producto.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Además, la accesibilidad suele tener sentido económico independientemente de la obligación legal. Un sitio web difícil de usar pierde clientes - no solo los que tienen discapacidad. Una estructura clara, buenos contrastes y tipografía legible ayudan a todos los visitantes.
</p>
</div>
</section>

<!-- ¿Qué significa accesible? -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">¿Qué significa concretamente un "sitio web accesible"?</h2>
<p class="text-body text-gosign-text leading-relaxed">
La accesibilidad suena abstracta, pero es muy práctica. Se trata de que todas las personas puedan usar su sitio web. Tres ejemplos sencillos:
</p>
<ul class="mt-4 space-y-3">
<li class="flex items-start gap-3">
<span class="text-gosign-accent-text font-bold mt-0.5">1.</span>
<p class="text-body text-gosign-text">
<strong>Una persona ciega utiliza un lector de pantalla</strong> - un programa que lee en voz alta el contenido de la pantalla. Si sus imágenes no tienen textos descriptivos (textos alt), la persona solo escucha "gráfico, gráfico, gráfico" y no entiende nada.
</p>
</li>
<li class="flex items-start gap-3">
<span class="text-gosign-accent-text font-bold mt-0.5">2.</span>
<p class="text-body text-gosign-text">
<strong>Una persona con baja visión necesita buenos contrastes.</strong> Un texto gris claro sobre fondo blanco es apenas legible para millones de personas con deficiencia visual. Las WCAG exigen una relación de contraste de al menos 4,5:1.
</p>
</li>
<li class="flex items-start gap-3">
<span class="text-gosign-accent-text font-bold mt-0.5">3.</span>
<p class="text-body text-gosign-text">
<strong>Una persona con limitación motriz no puede usar el ratón.</strong> Si su sitio web solo funciona con clics de ratón, está bloqueado para esta persona. Todo debe ser accesible también por teclado.
</p>
</li>
</ul>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Una buena accesibilidad mejora al mismo tiempo la <a href="/es/conocimiento/schema-org-seo-fundamentos/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">optimización para buscadores</a>: los textos alt, los encabezados claros y el código limpio ayudan a Google tanto como a un lector de pantalla.
</p>
</div>
</section>

<!-- WCAG 2.2 AA: Los cuatro principios -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">WCAG 2.2 AA: Los cuatro principios explicados</h2>
<p class="text-body text-gosign-text leading-relaxed mb-8">
Las WCAG (Web Content Accessibility Guidelines) son el estándar internacional para la accesibilidad web. La Directiva 2019/882 exige el cumplimiento del nivel AA. Las WCAG se basan en cuatro principios fundamentales:
</p>
<div class="grid md:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Perceptible</h3>
<p class="text-body text-gosign-text">
Los contenidos deben estar disponibles para todos los sentidos. Las imágenes necesitan descripciones, los vídeos necesitan subtítulos. Los contrastes deben ser suficientes. Quien no pueda ver debe poder escuchar o sentir los contenidos.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Operable</h3>
<p class="text-body text-gosign-text">
Todas las funciones deben ser accesibles por teclado - no solo por ratón. La navegación debe ser lógica. Los usuarios necesitan tiempo suficiente para leer y operar. Sin contenido parpadeante que pueda provocar convulsiones.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Comprensible</h3>
<p class="text-body text-gosign-text">
Los textos deben ser legibles. Los formularios deben tener etiquetas comprensibles. Los mensajes de error deben explicar qué salió mal. El sitio web no debe comportarse de forma inesperada (por ejemplo, abrir ventanas nuevas de repente).
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Robusto</h3>
<p class="text-body text-gosign-text">
El código debe ser limpio para que diferentes navegadores y tecnologías de asistencia (lectores de pantalla, líneas Braille, control por voz) puedan interpretar correctamente el contenido. El HTML conforme a estándares es la base.
</p>
</div>
</div>
</div>
</section>

<!-- Declaración de accesibilidad -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Declaración de accesibilidad: ¿qué debe incluir?</h2>
<p class="text-body text-gosign-text leading-relaxed">
La normativa exige una declaración de accesibilidad públicamente accesible en su sitio web. Esta declaración es comparable a la política de privacidad - informa a los visitantes sobre el estado actual de la accesibilidad. Son obligatorias las siguientes indicaciones:
</p>
<ul class="mt-4 space-y-2">
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text flex-shrink-0 mt-0.5" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor"><path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" /></svg>
<p class="text-body text-gosign-text">Qué partes del sitio web son accesibles y cuáles no</p>
</li>
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text flex-shrink-0 mt-0.5" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor"><path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" /></svg>
<p class="text-body text-gosign-text">Justificación de las limitaciones existentes</p>
</li>
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text flex-shrink-0 mt-0.5" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor"><path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" /></svg>
<p class="text-body text-gosign-text">Vía de contacto para comentarios (correo electrónico, teléfono o formulario)</p>
</li>
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text flex-shrink-0 mt-0.5" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor"><path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" /></svg>
<p class="text-body text-gosign-text">Referencia a la autoridad de supervisión competente</p>
</li>
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text flex-shrink-0 mt-0.5" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor"><path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" /></svg>
<p class="text-body text-gosign-text">Fecha de la última revisión</p>
</li>
</ul>
<p class="text-body text-gosign-text leading-relaxed mt-4">
La declaración debe ser fácil de encontrar - idealmente enlazada en el pie de página, similar al aviso legal y la política de privacidad.
</p>
</div>
</section>

<!-- ¿Por qué merece la pena la accesibilidad? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Por qué la accesibilidad merece la pena incluso sin obligación legal</h2>
<p class="text-body text-gosign-text leading-relaxed">
Incluso si su empresa no está formalmente sujeta a la Directiva 2019/882, hay buenas razones para tener sitios web accesibles:
</p>
<div class="grid md:grid-cols-2 gap-6 mt-6">
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Mayor alcance</h3>
<p class="text-body text-gosign-text">
Más de 4 millones de personas en España viven con alguna discapacidad. A ello se suman millones de personas mayores con visión o movilidad reducida. Los sitios web accesibles llegan a más personas.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Mejor SEO</h3>
<p class="text-body text-gosign-text">
Google valora mejor los sitios web accesibles. Los textos alt, una estructura clara de encabezados y tiempos de carga rápidos son factores tanto de accesibilidad como de SEO.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Requisitos de financiadores</h3>
<p class="text-body text-gosign-text">
Muchos programas públicos de financiación y organismos europeos exigen comunicación accesible. Quien solicite ayudas o contratos públicos será cada vez más evaluado en accesibilidad.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Imagen y confianza</h3>
<p class="text-body text-gosign-text">
La accesibilidad demuestra responsabilidad social. Para fundaciones, ONG y empresas con objetivos ESG, es un argumento real ante stakeholders y el público.
</p>
</div>
</div>
</div>
</section>

<!-- Sanciones -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Sanciones - ¿qué ocurre en caso de incumplimiento?</h2>
<p class="text-body text-gosign-text leading-relaxed">
La transposición de la Directiva 2019/882 en los Estados miembros prevé sanciones que deben ser efectivas, proporcionadas y disuasorias. En España, el régimen sancionador se establece a través de la normativa nacional correspondiente. Concretamente, las sanciones pueden derivarse de:
</p>
<ul class="mt-4 space-y-2">
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text flex-shrink-0 mt-0.5" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor"><path stroke-linecap="round" stroke-linejoin="round" d="M12 9v3.75m-9.303 3.376c-.866 1.5.217 3.374 1.948 3.374h14.71c1.73 0 2.813-1.874 1.948-3.374L13.949 3.378c-.866-1.5-3.032-1.5-3.898 0L2.697 16.126ZM12 15.75h.007v.008H12v-.008Z" /></svg>
<p class="text-body text-gosign-text">Falta de accesibilidad o accesibilidad insuficiente en servicios obligatorios</p>
</li>
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text flex-shrink-0 mt-0.5" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor"><path stroke-linecap="round" stroke-linejoin="round" d="M12 9v3.75m-9.303 3.376c-.866 1.5.217 3.374 1.948 3.374h14.71c1.73 0 2.813-1.874 1.948-3.374L13.949 3.378c-.866-1.5-3.032-1.5-3.898 0L2.697 16.126ZM12 15.75h.007v.008H12v-.008Z" /></svg>
<p class="text-body text-gosign-text">Ausencia de declaración de accesibilidad en el sitio web</p>
</li>
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text flex-shrink-0 mt-0.5" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor"><path stroke-linecap="round" stroke-linejoin="round" d="M12 9v3.75m-9.303 3.376c-.866 1.5.217 3.374 1.948 3.374h14.71c1.73 0 2.813-1.874 1.948-3.374L13.949 3.378c-.866-1.5-3.032-1.5-3.898 0L2.697 16.126ZM12 15.75h.007v.008H12v-.008Z" /></svg>
<p class="text-body text-gosign-text">Incumplimiento de las instrucciones de la autoridad de supervisión</p>
</li>
</ul>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Además, organizaciones de consumidores pueden interponer acciones judiciales. El riesgo no se limita a multas - también son posibles demandas y publicidad negativa. La prevención es más económica que la corrección.
</p>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Revisión de accesibilidad: 30&nbsp;minutos, gratuita.</h3>
<p class="text-body text-gosign-text mb-6">Revisamos su sitio web en los criterios WCAG más importantes - sin compromiso y con explicaciones claras.</p>
<a
href="/es/contacto/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Solicitar revisión de accesibilidad
</a>
<p class="text-small text-gosign-text-light mt-4">25 años de experiencia · Lighthouse 100/100 · WCAG 2.2 AA</p>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
Gosign es una agencia digital de Hamburgo con 25 años de experiencia en desarrollo web e integración de IA.
Nuestro propio sitio web alcanza el valor 100/100 en las cuatro categorías de Lighthouse, incluida
Accessibility. Ayudamos a empresas medianas, fundaciones y organismos públicos
a diseñar sus sitios web de forma accesible y conforme a la normativa.
</p>
<p class="text-small text-gosign-text-light mt-2">Actualizado: marzo 2026</p>
</div>
</section>

<!-- Temas relacionados -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Temas relacionados</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/es/conocimiento/obligaciones-rgpd-sitios-web/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Derecho</p>
<p class="text-body font-semibold text-gosign-dark">Obligaciones del RGPD para sitios web</p>
</a>
<a href="/es/conocimiento/sitio-web-sin-cookie-banner/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Privacidad</p>
<p class="text-body font-semibold text-gosign-dark">Sitio web sin cookie banner</p>
</a>
<a href="/es/conocimiento/typo3-actualizaciones-seguridad/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">TYPO3</p>
<p class="text-body font-semibold text-gosign-dark">Actualizaciones y seguridad TYPO3</p>
</a>
</div>
</div>
</section>

--- Obligaciones del RGPD para sitios web: Lo que realmente debe cumplir ---
> ¿Qué deben cumplir los sitios web en protección de datos? RGPD, consentimiento de cookies, política de privacidad - explicado para directivos.

<!-- ¿Qué es una política de privacidad? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">¿Qué es una política de privacidad y por qué la necesita todo sitio web?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Una política de privacidad informa a los visitantes de su sitio web sobre qué datos personales se recopilan, por qué se hace y qué derechos tienen los afectados. Suena abstracto, pero es concreto: solo cuando alguien accede a su sitio web, el servidor almacena una dirección IP. Eso ya es un dato personal. Con ello, todo sitio web está sujeto al RGPD.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
El Reglamento General de Protección de Datos (RGPD) está en vigor en toda la UE desde mayo de 2018. Obliga a todo operador de sitio web - ya sea gran empresa, PYME, asociación o fundación - a disponer de una política de privacidad completa. Si falta o está desactualizada, se arriesga a advertencias y sanciones.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Importante: una política de privacidad no es lo mismo que un aviso legal. El aviso legal establece quién es el responsable del sitio web (según la Ley de Servicios de la Sociedad de la Información - LSSI). La política de privacidad regula cómo se tratan los datos (según el RGPD). Ambos son obligatorios y deben existir por separado.
</p>
</div>
</section>

<!-- Errores más frecuentes -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Los errores más frecuentes en las políticas de privacidad</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
En nuestra práctica vemos siempre los mismos problemas. Muchos de ellos son fácilmente evitables - cuando se sabe a qué prestar atención.
</p>
<div class="grid md:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Plantillas desactualizadas</h3>
<p class="text-body text-gosign-text">
Muchos sitios web aún utilizan políticas de privacidad de 2018 o anteriores. Desde entonces, la legislación ha cambiado (nuevas sentencias sobre Google Fonts y Analytics). Una plantilla de hace tres años casi seguro ya no es conforme.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Datos que faltan</h3>
<p class="text-body text-gosign-text">
El RGPD exige información concreta: nombre del responsable, contacto del delegado de protección de datos (si existe), bases jurídicas para cada tratamiento, plazos de conservación y derechos de los interesados. Si falta alguno, la política es incompleta.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Copiar y pegar sin adaptar</h3>
<p class="text-body text-gosign-text">
Una política de privacidad debe ajustarse a su propio sitio web. Quien usa Google Analytics pero solo menciona Facebook Pixel tiene un problema. Y quien no usa herramientas de análisis pero escribe tres párrafos sobre ellas, también.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Páginas vacías u ocultas</h3>
<p class="text-body text-gosign-text">
Algunos sitios web tienen un enlace a la política de privacidad en el pie de página, pero la página está vacía o lleva a un error. Las autoridades de supervisión lo comprueban sistemáticamente - y los abogados especializados en reclamaciones aún más.
</p>
</div>
</div>
</div>
</section>

<!-- Consentimiento de cookies -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Consentimiento de cookies: por qué un simple aviso no basta</h2>
<p class="text-body text-gosign-text leading-relaxed">
Las cookies son pequeños archivos de texto que los sitios web almacenan en el dispositivo del visitante. Algunas son técnicamente necesarias (por ejemplo, para el carrito de compras en una tienda online). Otras sirven para análisis o marketing - y ahí es donde se vuelve jurídicamente relevante.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
La normativa europea y española exige que, antes de instalar cookies no esenciales, el visitante debe dar su consentimiento activo. Esto significa: un banner con el texto "Este sitio web utiliza cookies - Aceptar" no es suficiente. El visitante debe tener una elección real - con la posibilidad de rechazar categorías individuales.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
En la práctica, necesita una llamada plataforma de gestión de consentimiento (CMP). Esta herramienta muestra en la primera visita un banner de cookies con al menos dos opciones: "Aceptar todo" y "Solo necesarias". Solo después del consentimiento pueden instalarse cookies de seguimiento. Sin un CMP funcional, cualquier tracking en su sitio web es ilícito.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Por cierto: también los vídeos incrustados de YouTube, Google Maps o los botones de redes sociales instalan cookies. Quien incluya estos contenidos necesita o bien un consentimiento previo o una solución de dos clics que solo cargue tras la aprobación.
</p>
</div>
</section>

<!-- Alternativa sin cookies -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<div class="border-2 border-gosign-accent/20 rounded-card p-6 bg-white">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">La mejor solución: no necesitar un banner de cookies</h2>
<p class="text-body text-gosign-text leading-relaxed">
Existe una alternativa al dilema del banner de cookies: construya su sitio web de forma que <strong>no instale cookies no esenciales</strong>. Sin tracking, sin fuentes externas, sin embeds de terceros - entonces no necesita ni banner ni CMP. Eso ahorra dinero (las herramientas CMP cuestan entre 50 y 500 EUR al mes), mejora el tiempo de carga y simplifica enormemente el cumplimiento del RGPD.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
¿Suena poco realista? gosign.de es la prueba: cero cookies, cero banner, Lighthouse 100/100, análisis completo con herramientas sin cookies. Qué hay detrás y cómo puede funcionar también para su sitio web lo explicamos en detalle:
</p>
<a
href="/es/conocimiento/sitio-web-sin-cookie-banner/"
class="inline-flex items-center gap-2 mt-4 text-gosign-accent-text font-semibold hover:text-gosign-accent transition-colors"
>
<span>Sitio web sin cookie banner - así se hace</span>
<svg class="w-5 h-5" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M13.5 4.5 21 12m0 0-7.5 7.5M21 12H3" /></svg>
</a>
</div>
</div>
</section>

<!-- RGPD, ePrivacy, LSSI -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">RGPD, ePrivacy, LSSI - ¿qué ley se aplica a qué?</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
Tres marcos normativos, tres ámbitos de aplicación. Para los operadores de sitios web es importante conocer la diferencia - porque las infracciones de cada uno pueden ser sancionadas por separado.
</p>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse bg-white rounded-card">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Normativa</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Regula</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Obligación para sitios web</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">RGPD</td>
<td class="py-3 px-4 text-body text-gosign-text">Tratamiento de datos personales</td>
<td class="py-3 px-4 text-body text-gosign-text">Política de privacidad, registro de actividades de tratamiento, derechos de los interesados</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Directiva ePrivacy / LSSI</td>
<td class="py-3 px-4 text-body text-gosign-text">Acceso a dispositivos (cookies, fingerprinting)</td>
<td class="py-3 px-4 text-body text-gosign-text">Consentimiento antes de instalar cookies no esenciales</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">LSSI-CE</td>
<td class="py-3 px-4 text-body text-gosign-text">Obligaciones de información de servicios digitales</td>
<td class="py-3 px-4 text-body text-gosign-text">Aviso legal con datos completos del prestador</td>
</tr>
</tbody>
</table>
</div>
<p class="text-body text-gosign-text leading-relaxed mt-6">
El RGPD es un reglamento de la UE y se aplica directamente. La Directiva ePrivacy, transpuesta en España a través de la LSSI, regula específicamente el acceso a los dispositivos de los usuarios. La LSSI-CE (Ley de Servicios de la Sociedad de la Información y de Comercio Electrónico) regula, entre otros, la obligación de disponer de aviso legal. Las tres normativas se aplican en paralelo y las tres deben cumplirse.
</p>
</div>
</section>

<!-- Caso especial: fundaciones y ONG -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Caso especial: fundaciones y organizaciones sin ánimo de lucro</h2>
<p class="text-body text-gosign-text leading-relaxed">
Un error muy extendido: las fundaciones, asociaciones y organizaciones sin ánimo de lucro están exentas del RGPD. Esto no es cierto. El RGPD se aplica a toda organización que trate datos personales - independientemente de la forma jurídica o el fin.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
En la práctica, esto significa: también el sitio web de una fundación, una asociación o una entidad religiosa necesita una política de privacidad completa, un banner de cookies conforme y un aviso legal correcto. Los requisitos son idénticos a los de una empresa comercial.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Precisamente en fundaciones vemos con frecuencia sitios web con formularios de contacto, suscripción a newsletters y formularios de donación - áreas donde se tratan datos especialmente sensibles. Una política de privacidad correcta no solo es obligatoria, sino también una cuestión de confianza con donantes y patrocinadores. También la base técnica del sitio web juega un papel - información básica sobre <a href="/es/conocimiento/schema-org-seo-fundamentos/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">Schema.org y fundamentos de SEO</a> ayuda a posicionar el sitio web de forma profesional.
</p>
</div>
</section>

<!-- Lista de verificación -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Lista de verificación: 8 puntos que todo sitio web debe cumplir</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
Independientemente del sector, tamaño o forma jurídica - estos ocho puntos son el mínimo para todo sitio web en la Unión Europea.
</p>
<div class="space-y-4">
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">1</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Política de privacidad existente y actualizada</h3>
<p class="text-body text-gosign-text mt-1">Política completa con todas las indicaciones obligatorias del RGPD. Revisar al menos anualmente y actualizar tras cambios legislativos.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">2</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Aviso legal completo según la LSSI</h3>
<p class="text-body text-gosign-text mt-1">Nombre, domicilio, correo electrónico, teléfono, representantes legales, datos registrales (si procede), NIF. En una página separada, accesible con máximo dos clics.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">3</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Banner de cookies con consentimiento real</h3>
<p class="text-body text-gosign-text mt-1">Sin "Aceptar todo" preseleccionado. Opciones equivalentes para aceptar y rechazar. Solo tras el consentimiento pueden instalarse cookies no esenciales.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">4</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Cifrado SSL/TLS activo</h3>
<p class="text-body text-gosign-text mt-1">Todo el sitio web debe ser accesible por HTTPS. Sin cifrado, los datos de formularios se transmiten en texto plano - una clara infracción del RGPD.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">5</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Formularios de contacto con aviso de privacidad</h3>
<p class="text-body text-gosign-text mt-1">Cada formulario necesita un aviso sobre el tratamiento de datos y un enlace a la política de privacidad. Para datos sensibles (candidaturas, salud) se requiere un consentimiento separado.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">6</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Contratos de encargado de tratamiento firmados</h3>
<p class="text-body text-gosign-text mt-1">Para cada proveedor externo con acceso a datos personales (hosting, correo electrónico, herramientas de análisis) debe existir un contrato de encargado de tratamiento. Sin él, el tratamiento es ilícito.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">7</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Sin integraciones de terceros no controladas</h3>
<p class="text-body text-gosign-text mt-1">Google Fonts alojadas localmente (no cargar desde servidores de Google). Vídeos de YouTube solo con solución de dos clics. Sin píxeles de seguimiento externos sin consentimiento. Cada conexión con terceros debe documentarse en la política de privacidad.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">8</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Acceso accesible a la información legal</h3>
<p class="text-body text-gosign-text mt-1">La política de privacidad y el aviso legal deben ser accesibles para todos - también para personas con discapacidad. Desde junio de 2025, la <a href="/es/conocimiento/accesibilidad-bfsg-2025/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">Directiva Europea de Accesibilidad (2019/882)</a> exige accesibilidad digital para muchos sitios web.</p>
</div>
</div>
</div>
</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Revisión de privacidad de su sitio web: 30&nbsp;minutos, gratuita.</h3>
<p class="text-body text-gosign-text mb-6">Revisamos su sitio web en cuanto a conformidad con el RGPD y le mostramos dónde hay que actuar.</p>
<a
href="/es/contacto/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Solicitar revisión de privacidad
</a>
<p class="text-small text-gosign-text-light mt-4">25 años de experiencia &middot; 800+ proyectos &middot; Práctica de privacidad desde Hamburgo</p>
</div>
</section>

<!-- ¿Qué ocurre en caso de infracción? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">¿Qué ocurre en caso de infracción?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Las consecuencias de una infracción del RGPD son reales y pueden ser graves. El RGPD prevé multas de hasta 20 millones de euros o el 4 por ciento de la facturación anual mundial - lo que sea mayor. En la práctica, la mayoría de las multas por infracciones en sitios web se sitúan entre 5.000 y 50.000 euros, pero la tendencia es al alza.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Además de las multas, hay dos riesgos adicionales que en la práctica se materializan con más frecuencia:
</p>
<div class="grid md:grid-cols-2 gap-6 mt-6">
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Reclamaciones</h3>
<p class="text-body text-gosign-text">
Desde la sentencia del TJUE sobre Google Fonts (2022), el número de reclamaciones ha aumentado significativamente. Abogados especializados y organizaciones de consumidores revisan sistemáticamente sitios web en busca de infracciones del RGPD.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Procedimientos de la AEPD</h3>
<p class="text-body text-gosign-text">
La Agencia Española de Protección de Datos (AEPD) revisa cada vez más de forma proactiva. Una denuncia ante la AEPD es gratuita para cualquier visitante y conduce a una revisión formal. Esto consume recursos internos y puede derivar en medidas de obligado cumplimiento.
</p>
</div>
</div>
<p class="text-body text-gosign-text leading-relaxed mt-6">
Lo más importante: la mayoría de las infracciones en sitios web son fácilmente evitables. Una política de privacidad actualizada, un banner de cookies funcional y un aviso legal correcto cuestan una fracción de lo que cuesta una multa. La prevención no es una cuestión de presupuesto, sino de prioridad.
</p>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
Gosign es una agencia digital de Hamburgo con 25 años de experiencia en desarrollo web, TYPO3 e integración de IA.
Revisamos sitios web en cuanto a conformidad con el RGPD, implementamos soluciones conformes con la normativa de protección de datos
y acompañamos a empresas, fundaciones y organismos públicos en el cumplimiento de todos los requisitos legales.
</p>
<p class="text-small text-gosign-text-light mt-2">Actualizado: marzo 2026</p>
</div>
</section>

<!-- Temas relacionados -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Temas relacionados</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/es/conocimiento/accesibilidad-bfsg-2025/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Derecho</p>
<p class="text-body font-semibold text-gosign-dark">Accesibilidad y Directiva 2019/882</p>
</a>
<a href="/es/conocimiento/sitio-web-sin-cookie-banner/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Privacidad</p>
<p class="text-body font-semibold text-gosign-dark">Sitio web sin cookie banner</p>
</a>
<a href="/es/conocimiento/typo3-actualizaciones-seguridad/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">TYPO3</p>
<p class="text-body font-semibold text-gosign-dark">Actualizaciones y seguridad TYPO3</p>
</a>
</div>
</div>
</section>

--- Schema.org y fundamentos de SEO: Así se hace visible su web en Google ---
> ¿Qué son los datos estructurados? Schema.org, meta-etiquetas y Open Graph para mejorar la visibilidad en Google. Fundamentos de SEO.

<!-- ¿Qué son los datos estructurados? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">¿Qué son los "datos estructurados"?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Imagínese que le da a alguien su tarjeta de visita. En ella figura su nombre, su número de teléfono, su dirección. El receptor entiende inmediatamente quién es usted y cómo puede contactarle. Exactamente eso hacen los datos estructurados para los motores de búsqueda.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Schema.org es un lenguaje estandarizado que Google, Bing y otros motores de búsqueda entienden. Con él les dice: "Esto es una empresa, esta es la dirección, estos son los horarios de apertura, y este es el precio del producto." Sin estas marcas, Google tiene que adivinar - y adivinar lleva a menudo a resultados de búsqueda incorrectos o incompletos.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
El principio: usted complementa su código HTML existente con información adicional invisible. Los visitantes no ven ninguna diferencia, pero los motores de búsqueda leen una "tarjeta de visita" claramente estructurada de su empresa.
</p>
</div>
</section>

<!-- Antes y después -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Antes y después: así cambia Schema.org su resultado de búsqueda</h2>
<p class="text-body text-gosign-text leading-relaxed mb-8">
La diferencia es visible de inmediato. Aquí una comparación de cómo puede aparecer su empresa en los resultados de búsqueda de Google:
</p>
<div class="grid md:grid-cols-2 gap-6">
<div class="bg-white border border-gosign-border rounded-card p-6">
<p class="text-small font-semibold text-red-600 uppercase tracking-wider mb-4">Sin Schema.org</p>
<div class="border border-gosign-border rounded-card p-4 bg-gosign-light">
<p class="text-body text-blue-700 font-semibold">Empresa Ejemplo S.L. - Inicio</p>
<p class="text-small text-green-700 mb-1">www.empresa-ejemplo.es</p>
<p class="text-small text-gosign-text-light">Bienvenido a Empresa Ejemplo. Ofrecemos servicios en el ámbito de...</p>
</div>
<p class="text-small text-gosign-text-light mt-3">Solo un enlace azul con texto genérico. Sin dirección, sin valoraciones, sin información adicional. El usuario no tiene motivo para hacer clic precisamente aquí.</p>
</div>
<div class="bg-white border border-gosign-border rounded-card p-6">
<p class="text-small font-semibold text-green-700 uppercase tracking-wider mb-4">Con Schema.org</p>
<div class="border border-gosign-border rounded-card p-4 bg-gosign-light">
<p class="text-body text-blue-700 font-semibold">Empresa Ejemplo S.L. - Servicios IT Madrid</p>
<p class="text-small text-green-700 mb-1">www.empresa-ejemplo.es</p>
<p class="text-small text-amber-700 mb-1">&#9733;&#9733;&#9733;&#9733;&#9733; 4,8 (127 valoraciones)</p>
<p class="text-small text-gosign-text-light mb-1">Calle Ejemplo 12, 28001 Madrid - Tel. 91 123 45 67</p>
<p class="text-small text-gosign-text-light">Proveedor de servicios IT para PYMES. Servidores, cloud, soporte.</p>
</div>
<p class="text-small text-gosign-text-light mt-3">Rich Snippet con estrellas de valoración, dirección y teléfono. Ocupa más espacio, transmite más confianza - y recibe más clics.</p>
</div>
</div>
<p class="text-body text-gosign-text leading-relaxed mt-6">
Los estudios muestran: los Rich Snippets con valoraciones e información adicional obtienen hasta un 30 % más de clics que los simples enlaces azules. Y eso sin presupuesto publicitario - solo con datos correctamente configurados.
</p>
</div>
</section>

<!-- Los tres tipos de Schema más importantes -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">Los tres tipos de Schema más importantes para empresas</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Organization</h3>
<p class="text-body text-gosign-text">
Datos básicos de su empresa: nombre, logotipo, dirección, año de fundación, perfiles en redes sociales. Google utiliza estos datos para el Knowledge Panel - el cuadro informativo a la derecha de los resultados de búsqueda.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">LocalBusiness</h3>
<p class="text-body text-gosign-text">
Amplía Organization con datos específicos de ubicación: horarios de apertura, rango de precios, valoraciones, coordenadas. Especialmente importante para empresas con área de influencia local - la base para los resultados de Google Maps.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">BreadcrumbList</h3>
<p class="text-body text-gosign-text">
Muestra a Google la estructura de navegación de su sitio web. En lugar de "www.ejemplo.es/productos/categoria/articulo", Google muestra en los resultados: "Inicio > Productos > Categoría" - claro y con enlaces.
</p>
</div>
</div>
</div>
</section>

<!-- Meta-Description -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Meta-Description: 160 caracteres que deciden el clic</h2>
<p class="text-body text-gosign-text leading-relaxed">
La Meta-Description es el breve texto descriptivo que aparece en los resultados de búsqueda de Google bajo el título de su página. No es un factor de ranking directo, pero decide si alguien hace clic en su resultado - o en el de la competencia.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Una buena Meta-Description responde a la pregunta del usuario en un máximo de 155-160 caracteres. Contiene la palabra clave principal, un beneficio claro y, idealmente, una llamada a la acción. Si falta la Meta-Description, Google elige por sí mismo un fragmento de texto - a menudo no el mejor.
</p>
<h3 class="text-h3 font-bold text-gosign-dark mt-8 mb-4">Canonical Tags y hreflang: señales claras para los buscadores</h3>
<p class="text-body text-gosign-text leading-relaxed">
Si su sitio web existe en varios idiomas o contenidos similares son accesibles bajo diferentes URLs, los motores de búsqueda necesitan señales inequívocas. Para ello existen dos etiquetas importantes:
</p>
<ul class="mt-4 space-y-3">
<li class="text-body text-gosign-text leading-relaxed">
<strong class="text-gosign-dark">Canonical Tag:</strong> Indica a Google cuál es la URL "versión original" de una página. Evita que contenidos idénticos bajo diferentes direcciones se consideren duplicados.
</li>
<li class="text-body text-gosign-text leading-relaxed">
<strong class="text-gosign-dark">Hreflang:</strong> Comunica a los buscadores qué versiones lingüísticas de una página existen. Así Google muestra a los usuarios españoles la versión en español y a los ingleses la inglesa. Especialmente relevante para <a href="/es/conocimiento/obligaciones-rgpd-sitios-web/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">sitios web multilingües conformes con el RGPD</a>.
</li>
</ul>
</div>
</section>

<!-- Open Graph -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Open Graph Tags: así lucen sus enlaces en WhatsApp y LinkedIn</h2>
<p class="text-body text-gosign-text leading-relaxed">
¿Le ha pasado alguna vez? Comparte un enlace en WhatsApp o LinkedIn y solo aparece una URL seca - sin imagen, sin título, sin descripción. Eso ocurre cuando faltan los Open Graph Tags.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Los Open Graph (OG) Tags son meta-indicaciones en el código HTML que dicen a las redes sociales cómo debe mostrarse un enlace compartido. Los cuatro más importantes:
</p>
<ul class="mt-4 space-y-2">
<li class="text-body text-gosign-text"><strong class="text-gosign-dark">og:title</strong> - El título que aparece en la vista previa</li>
<li class="text-body text-gosign-text"><strong class="text-gosign-dark">og:description</strong> - La descripción bajo el título</li>
<li class="text-body text-gosign-text"><strong class="text-gosign-dark">og:image</strong> - La imagen de vista previa (ideal: 1200 x 630 píxeles)</li>
<li class="text-body text-gosign-text"><strong class="text-gosign-dark">og:url</strong> - La URL canónica de la página</li>
</ul>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Sin OG Tags, cada plataforma decide por sí misma qué muestra. Con OG Tags usted controla la imagen que da su empresa - en LinkedIn, WhatsApp, Facebook, Twitter y en cualquier lugar donde se compartan enlaces.
</p>
</div>
</section>

<!-- Lista de verificación SEO -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Lista de verificación: 6 fundamentos de SEO para todo sitio web empresarial</h2>
<p class="text-body text-gosign-text leading-relaxed mb-8">
Estos seis puntos constituyen el fundamento técnico para una buena visibilidad en Google. Compruebe si su sitio web los cumple:
</p>
<div class="space-y-4">
<div class="bg-white border border-gosign-border rounded-card p-5">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent text-white rounded-full flex items-center justify-center font-bold text-small">1</span>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-1">Configurar marcado Schema.org</h3>
<p class="text-body text-gosign-text">Compruebe si su sitio web tiene al menos Schema de Organization o LocalBusiness. Test: introduzca su URL en el Rich Results Test (search.google.com/test/rich-results).</p>
</div>
</div>
</div>
<div class="bg-white border border-gosign-border rounded-card p-5">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent text-white rounded-full flex items-center justify-center font-bold text-small">2</span>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-1">Meta-Descriptions para todas las páginas importantes</h3>
<p class="text-body text-gosign-text">Compruebe si cada página tiene su propia Meta-Description - no vacía, no duplicada, máximo 155-160 caracteres. Cada descripción debe resumir en una frase el beneficio de la página.</p>
</div>
</div>
</div>
<div class="bg-white border border-gosign-border rounded-card p-5">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent text-white rounded-full flex items-center justify-center font-bold text-small">3</span>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-1">Configurar Canonical Tags</h3>
<p class="text-body text-gosign-text">Compruebe si cada página tiene un Canonical Tag. Especialmente importante en tiendas online, páginas con filtros o sitios web con variante www y sin www.</p>
</div>
</div>
</div>
<div class="bg-white border border-gosign-border rounded-card p-5">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent text-white rounded-full flex items-center justify-center font-bold text-small">4</span>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-1">Configurar Open Graph Tags</h3>
<p class="text-body text-gosign-text">Compruebe si sus páginas tienen og:title, og:description y og:image. Test: comparta un enlace de su sitio web en un grupo de WhatsApp - ¿aparece una vista previa atractiva?</p>
</div>
</div>
</div>
<div class="bg-white border border-gosign-border rounded-card p-5">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent text-white rounded-full flex items-center justify-center font-bold text-small">5</span>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-1">Optimizar HTTPS y tiempo de carga</h3>
<p class="text-body text-gosign-text">Compruebe si su sitio web es accesible por HTTPS (obligatorio desde 2018) y carga en menos de 3 segundos. Ambos son factores directos de ranking de Google.</p>
</div>
</div>
</div>
<div class="bg-white border border-gosign-border rounded-card p-5">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent text-white rounded-full flex items-center justify-center font-bold text-small">6</span>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-1">Garantizar la accesibilidad</h3>
<p class="text-body text-gosign-text">Compruebe si su sitio web es <a href="/es/conocimiento/accesibilidad-bfsg-2025/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">accesible según la Directiva 2019/882</a>. Los textos alt en imágenes, una jerarquía limpia de encabezados y la navegación por teclado mejoran no solo la accesibilidad, sino también la visibilidad en Google.</p>
</div>
</div>
</div>
</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Revisión del potencial SEO de su web: 30&nbsp;minutos, gratuita.</h3>
<p class="text-body text-gosign-text mb-6">Analizamos su sitio web en los fundamentos de SEO más importantes y le mostramos mejoras concretas.</p>
<a
href="/es/contacto/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Solicitar revisión SEO
</a>
<p class="text-small text-gosign-text-light mt-4">25 años de experiencia · 800+ proyectos · Análisis acelerado por IA</p>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
Gosign es una agencia digital de Hamburgo con 25 años de experiencia en desarrollo web, TYPO3 e integración de IA.
Nos encargamos de sitios web empresariales desde la optimización SEO técnica hasta la accesibilidad.
Nuestros clientes son empresas medianas, universidades y organismos públicos en Europa.
</p>
<p class="text-small text-gosign-text-light mt-2">Actualizado: marzo 2026</p>
</div>
</section>

<!-- Temas relacionados -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Temas relacionados</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/es/conocimiento/obligaciones-rgpd-sitios-web/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Derecho</p>
<p class="text-body font-semibold text-gosign-dark">Obligaciones del RGPD para sitios web</p>
</a>
<a href="/es/conocimiento/accesibilidad-bfsg-2025/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Derecho</p>
<p class="text-body font-semibold text-gosign-dark">Accesibilidad y Directiva 2019/882</p>
</a>
<a href="/es/conocimiento/typo3-actualizaciones-seguridad/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">TYPO3</p>
<p class="text-body font-semibold text-gosign-dark">Actualizaciones y seguridad TYPO3</p>
</a>
</div>
</div>
</section>

--- Sitio web sin cookie banner: Sí, es posible. Y es mejor. ---
> Los sitios web sin cookie banner son legales, más rápidos y conformes con el RGPD. Así puede eliminar las cookies y ahorrar costes de CMP.

<!-- El problema: los banners de cookies molestan a todos -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">El problema: los banners de cookies molestan a todos</h2>
<p class="text-body text-gosign-text leading-relaxed">
Aproximadamente el 80 por ciento de los visitantes hace clic en "Rechazar todo" o cierra el banner de cookies inmediatamente. El resultado: lo primero que ve un cliente potencial de su sitio web es una barrera. Ni contenido, ni producto, ni mensaje - sino un popup que pide consentimiento.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Los banners de cookies no solo son molestos, también cuestan dinero. Las plataformas de gestión de consentimiento (CMPs) como Cookiebot, Usercentrics o OneTrust cobran entre 50 y 500 euros al mes, dependiendo de las visitas. Además: el JavaScript del CMP ralentiza la carga de la página, empeora los Core Web Vitals y puede <a href="/es/conocimiento/schema-org-seo-fundamentos/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">afectar negativamente a los rankings SEO</a>.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Sin embargo, la mayoría de los sitios web necesitan un banner de cookies - porque instalan cookies. Google Analytics, Facebook Pixel, vídeos de YouTube incrustados, Google Fonts desde servidores externos: todo esto instala cookies o transfiere datos personales. Y la <a href="/es/conocimiento/obligaciones-rgpd-sitios-web/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">normativa de protección de datos exige</a> que antes de instalar cookies no esenciales se debe obtener consentimiento.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Pero, ¿y si un sitio web no instala ninguna cookie?
</p>
</div>
</section>

<!-- La alternativa: no instalar cookies -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">La alternativa: no instalar cookies en absoluto</h2>
<p class="text-body text-gosign-text leading-relaxed">
Si un sitio web no instala cookies no esenciales, no necesita banner de cookies. Esto no es un truco ni una zona gris - es pura lógica. La normativa exige consentimiento solo antes de instalar cookies. Sin cookies, sin necesidad de consentimiento, sin banner necesario.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Técnicamente es totalmente viable. Requiere decisiones conscientes en la arquitectura del sitio web:
</p>
<div class="grid md:grid-cols-2 gap-6 mt-6">
<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Fuentes alojadas localmente</h3>
<p class="text-body text-gosign-text">
Incluir Google Fonts localmente en vez de cargarlas desde servidores de Google. Sin conexión a Google, sin transferencia de IP, sin necesidad de cookies.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Análisis sin cookies</h3>
<p class="text-body text-gosign-text">
Cloudflare Web Analytics en lugar de Google Analytics. Sin cookies, sin almacenamiento de IP, pero con datos de páginas vistas, fuentes de tráfico y páginas principales.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Sin embeds de terceros</h3>
<p class="text-body text-gosign-text">
Sin YouTube, sin Google Maps, sin botones de redes sociales que instalen cookies. Si es necesario: alternativas conformes o soluciones de dos clics que solo cargan tras la aprobación.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">SSG + CDN Edge Delivery</h3>
<p class="text-body text-gosign-text">
Generación de sitio estático en lugar de entrega CMS dinámica. Sin cookie de sesión del servidor, sin cabeceras de seguimiento dinámicas.
</p>
</div>
</div>
</div>
</section>

<!-- Lo que gana -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Lo que gana</h2>
<div class="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-3 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Sin cookie banner</h3>
<p class="text-body text-gosign-text">Primera impresión limpia. Sin popup, sin diálogo de "Aceptar". Los visitantes ven directamente su contenido.</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Mejor rendimiento</h3>
<p class="text-body text-gosign-text">Sin JavaScript de CMP, sin comprobación de consentimiento antes de cada script. Menos código, tiempos de carga más rápidos.</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Plena conformidad RGPD</h3>
<p class="text-body text-gosign-text">No "suficientemente conforme", sino: no hay nada que regular. Sin cookies, sin necesidad de consentimiento.</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Sin costes de CMP</h3>
<p class="text-body text-gosign-text">Sin Cookiebot, Usercentrics ni OneTrust. Eso ahorra de 600 a 6.000 euros al año.</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Mejor SEO</h3>
<p class="text-body text-gosign-text">Los Google Core Web Vitals se benefician directamente de la ausencia de scripts de consentimiento. Las páginas más rápidas posicionan mejor.</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">A prueba de futuro</h3>
<p class="text-body text-gosign-text">La regulación de cookies se está endureciendo. Quien no necesita cookies, simplemente no se ve afectado.</p>
</div>
</div>
</div>
</section>

<!-- "¡Pero necesito Analytics!" -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">"¡Pero necesito Analytics!"</h2>
<p class="text-body text-gosign-text leading-relaxed">
Esta es la objeción más frecuente. Y es legítima - pero tiene solución. La analítica sin cookies es una realidad desde hace tiempo. La cuestión no es si se puede, sino cómo.
</p>
<div class="space-y-6 mt-6">
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Cloudflare Web Analytics</h3>
<p class="text-body text-gosign-text leading-relaxed">
Sin cookies, conforme con la protección de datos y gratuito. Proporciona páginas vistas, páginas principales, fuentes de tráfico, países y tipos de dispositivo. Sin almacenamiento de IP, sin necesidad de consentimiento, sin integración de CMP.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Análisis del lado del servidor</h3>
<p class="text-body text-gosign-text leading-relaxed">
Evaluación de archivos de log directamente en el servidor. Sin cookies, sin transferencia de datos externa. Herramientas como GoAccess o AWStats evalúan los logs del servidor y proporcionan datos de visitantes sin tocar jamás el navegador del visitante.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Seguimiento de conversiones sin cookies</h3>
<p class="text-body text-gosign-text leading-relaxed">
Eventos del lado del servidor en lugar de píxeles del lado del cliente. Cuando un visitante envía un formulario de contacto, el evento se registra del lado del servidor - sin cookie, sin píxel, sin terceros.
</p>
</div>
</div>
<p class="text-body text-gosign-text leading-relaxed mt-6">
La pregunta honesta es: ¿necesita realmente 200 puntos de datos por visitante, o le bastan las páginas vistas, las fuentes de tráfico y los eventos de conversión? Para la mayoría de los sitios web empresariales, la respuesta es clara.
</p>
</div>
</section>

<!-- Ejemplo práctico: gosign.de -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Ejemplo práctico: gosign.de</h2>
<p class="text-body text-gosign-text leading-relaxed">
Este sitio web no instala cookies. Cero banner de cookies, cero fuentes externas, cero píxeles de seguimiento. El análisis funciona a través de Cloudflare Web Analytics (sin cookies, sin almacenamiento de IP). Las fuentes están alojadas localmente, no hay embeds de YouTube, ni Google Maps, ni botones de redes sociales. El resultado: Lighthouse 100/100 en las cuatro categorías (Performance, Accessibility, Best Practices, SEO), plena conformidad con el RGPD sin costes recurrentes de CMP y una política de privacidad reducida a lo esencial. También el tema de la <a href="/es/conocimiento/accesibilidad-bfsg-2025/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">accesibilidad</a> se beneficia directamente de esta arquitectura: sin overlay de CMP no hay barrera entre el usuario y el contenido.
</p>
</div>
</section>

<!-- Lista de verificación -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Lista de verificación: así su sitio web queda libre de cookies</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
Cinco pasos, en este orden. Solo cuando los primeros cuatro puntos estén resueltos se puede eliminar el banner.
</p>
<div class="space-y-4">
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">1</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Eliminar fuentes externas o alojarlas localmente</h3>
<p class="text-body text-gosign-text mt-1">Cargar Google Fonts desde servidores de Google es la causa más frecuente de transferencias de datos no deseadas. Descargue las fuentes, alójelas en su propio servidor, listo.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">2</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Sustituir Google Analytics por una alternativa sin cookies</h3>
<p class="text-body text-gosign-text mt-1">Cloudflare Web Analytics, Plausible o Fathom proporcionan los datos relevantes para sitios web empresariales - sin cookies y sin obligación de consentimiento. La migración suele durar menos de una hora.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">3</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Sustituir o asegurar embeds de terceros</h3>
<p class="text-body text-gosign-text mt-1">Los vídeos de YouTube, Google Maps y los botones de redes sociales instalan cookies al cargarse. Dos opciones: eliminarlos completamente o sustituirlos por soluciones de dos clics que solo cargan tras la aprobación.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">4</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Eliminar píxeles de marketing o migrar al lado del servidor</h3>
<p class="text-body text-gosign-text mt-1">Facebook Pixel, LinkedIn Insight Tag, Google Ads Conversion - todo esto instala cookies. Eliminarlos completamente o migrar a seguimiento del lado del servidor que no requiere cookies en el dispositivo.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">5</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Eliminar el banner de cookies</h3>
<p class="text-body text-gosign-text mt-1">Solo ahora. Cuando ya no se instalen cookies no esenciales, puede desinstalar el CMP y eliminar el banner. La política de privacidad sigue siendo obligatoria, pero será mucho más breve.</p>
</div>
</div>
</div>
</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Solicitar web sin cookies: 30&nbsp;minutos, gratuito.</h3>
<p class="text-body text-gosign-text mb-6">Revisamos su sitio web y le mostramos qué cookies puede eliminar - y cuáles no necesita en absoluto.</p>
<a
href="/es/contacto/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Solicitar web sin cookies
</a>
<p class="text-small text-gosign-text-light mt-4">25 años de experiencia &middot; 800+ proyectos &middot; Práctica de privacidad desde Hamburgo</p>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
Gosign es una agencia digital de Hamburgo con 25 años de experiencia en desarrollo web, TYPO3 e integración de IA.
Desarrollamos sitios web sin cookies, sin dependencias externas y con plena conformidad con el RGPD -
sin compromisos en análisis, rendimiento ni funcionalidad.
</p>
<p class="text-small text-gosign-text-light mt-2">Actualizado: marzo 2026</p>
</div>
</section>

<!-- Temas relacionados -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Temas relacionados</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/es/conocimiento/obligaciones-rgpd-sitios-web/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Derecho</p>
<p class="text-body font-semibold text-gosign-dark">Obligaciones del RGPD para sitios web</p>
</a>
<a href="/es/conocimiento/schema-org-seo-fundamentos/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">SEO</p>
<p class="text-body font-semibold text-gosign-dark">Schema.org y fundamentos de SEO</p>
</a>
<a href="/es/conocimiento/accesibilidad-bfsg-2025/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Derecho</p>
<p class="text-body font-semibold text-gosign-dark">Accesibilidad y Directiva 2019/882</p>
</a>
</div>
</div>
</section>

--- Actualizaciones TYPO3: Por qué son importantes ---
> Por qué las actualizaciones de TYPO3 son importantes, qué versiones aún tienen soporte y qué aporta una actualización a la v13. Explicado de forma clara.

<!-- ¿Qué significa LTS? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">¿Qué significa "LTS" y por qué es importante para usted?</h2>
<p class="text-body text-gosign-text leading-relaxed">
LTS significa <strong>Long Term Support</strong>. Esto quiere decir: el fabricante proporciona actualizaciones de seguridad para esta versión durante un período prolongado. Cuando se descubre una vulnerabilidad, se cierra - pero solo para las versiones que aún tienen soporte.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Piénselo como un coche: mientras su modelo siga en producción, puede obtener repuestos y participar en campañas de recall. Cuando el modelo se descataloga, queda por su cuenta. Con TYPO3 funciona igual: sin soporte no hay parches de seguridad - y las vulnerabilidades conocidas permanecen abiertas.
</p>
</div>
</section>

<!-- Tabla de versiones -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">¿Qué versiones de TYPO3 aún tienen soporte?</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
TYPO3 publica periódicamente nuevas versiones. Las versiones antiguas dejan de recibir parches de seguridad. La siguiente tabla muestra el estado actual:
</p>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse bg-white rounded-card">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Versión</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Soporte hasta</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Estado</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">TYPO3 v13 LTS</td>
<td class="py-3 px-4 text-body text-gosign-text">Diciembre 2027</td>
<td class="py-3 px-4">
<span class="inline-flex items-center px-3 py-1 rounded-full text-small font-semibold bg-green-100 text-green-800">Actual - recomendada</span>
</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">TYPO3 v12 LTS</td>
<td class="py-3 px-4 text-body text-gosign-text">Octubre 2025 (Extended hasta marzo 2028)</td>
<td class="py-3 px-4">
<span class="inline-flex items-center px-3 py-1 rounded-full text-small font-semibold bg-yellow-100 text-yellow-800">Soporte terminando</span>
</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">TYPO3 v11 y anteriores</td>
<td class="py-3 px-4 text-body text-gosign-text">Ya expirado</td>
<td class="py-3 px-4">
<span class="inline-flex items-center px-3 py-1 rounded-full text-small font-semibold bg-red-100 text-red-800">Sin soporte - riesgo de seguridad</span>
</td>
</tr>
</tbody>
</table>
</div>
<p class="text-body text-gosign-text leading-relaxed mt-6">
<strong>Conclusión:</strong> si su sitio web funciona con TYPO3 v11 o anterior, <strong>ya no recibe parches de seguridad</strong>. Las vulnerabilidades conocidas no se cierran. Se recomienda urgentemente una actualización.
</p>
</div>
</section>

<!-- ¿Qué pasa con una versión obsoleta? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">¿Qué pasa si usa una versión obsoleta?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Las vulnerabilidades de seguridad se descubren regularmente - eso es normal y afecta a todo software. Lo decisivo es si el fabricante las cierra. En versiones sin soporte, esto ya no ocurre. Las vulnerabilidades se hacen públicas igualmente - y eso es exactamente lo que aprovechan los atacantes.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Concretamente esto significa: su sitio web puede ser utilizado para redirecciones de phishing, envío de spam o robo de datos - a menudo sin que lo note inmediatamente. Las consecuencias van desde daño reputacional hasta infracciones del RGPD y el bloqueo por parte de buscadores. Más sobre obligaciones de protección de datos en nuestro artículo sobre <a href="/es/conocimiento/obligaciones-rgpd-sitios-web/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">obligaciones del RGPD para sitios web</a>.
</p>
</div>
</section>

<!-- ¿Qué aporta la v13.4? -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">¿Qué aporta concretamente TYPO3 v13.4?</h2>
<p class="text-body text-gosign-text leading-relaxed mb-8">
Una actualización no es solo una medida obligatoria de seguridad. TYPO3 v13.4 trae mejoras reales que se notan en el día a día:
</p>
<div class="grid md:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Tiempos de carga más rápidos</h3>
<p class="text-body text-gosign-text">
Compresión automática de imágenes con WebP y AVIF. Sus imágenes se hacen más pequeñas, las páginas cargan más rápido - sin que usted tenga que cambiar nada.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Backend más moderno</h3>
<p class="text-body text-gosign-text">
La interfaz donde gestiona los contenidos ha sido rediseñada. Estructura más clara, mejor visión general, manejo más sencillo - también para usuarios ocasionales.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Seguridad actualizada</h3>
<p class="text-body text-gosign-text">
Soporte para PHP 8.2+ y actualizaciones de seguridad regulares. Su sitio web permanece protegido contra las amenazas actuales.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Content Blocks</h3>
<p class="text-body text-gosign-text">
Los nuevos Content Blocks permiten un diseño de páginas más flexible. Los layouts y elementos de contenido se combinan más fácilmente - menos dependencia de extensiones.
</p>
</div>
</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Revisar versión TYPO3: 30&nbsp;minutos, gratuito.</h3>
<p class="text-body text-gosign-text mb-6">Comprobamos su versión de TYPO3, las extensiones instaladas y las vulnerabilidades abiertas - sin compromiso.</p>
<a
href="/es/contacto/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Solicitar revisión TYPO3
</a>
<p class="text-small text-gosign-text-light mt-4">25 años de experiencia &middot; 800+ extensiones &middot; Desarrollo acelerado por IA</p>
</div>
</section>

<!-- Proceso de actualización -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">El proceso de actualización: ¿qué le espera?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Una actualización de TYPO3 no tiene por qué ser un gran proyecto. El proceso típico:
</p>
<ol class="mt-6 space-y-4">
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent text-white rounded-full flex items-center justify-center text-small font-bold">1</span>
<div>
<p class="text-body font-semibold text-gosign-dark">Análisis</p>
<p class="text-body text-gosign-text">¿Qué versión está ejecutando actualmente? ¿Qué extensiones están instaladas? ¿Hay personalizaciones individuales? Gosign elabora un inventario.</p>
</div>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent text-white rounded-full flex items-center justify-center text-small font-bold">2</span>
<div>
<p class="text-body font-semibold text-gosign-dark">Actualización en staging</p>
<p class="text-body text-gosign-text">La actualización se realiza en un entorno de pruebas. Su sitio web en producción sigue funcionando con normalidad mientras tanto.</p>
</div>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent text-white rounded-full flex items-center justify-center text-small font-bold">3</span>
<div>
<p class="text-body font-semibold text-gosign-dark">Prueba y aprobación</p>
<p class="text-body text-gosign-text">Usted revisa la versión de staging. ¿Todo funciona como se esperaba? Solo después de su aprobación se continúa.</p>
</div>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent text-white rounded-full flex items-center justify-center text-small font-bold">4</span>
<div>
<p class="text-body font-semibold text-gosign-dark">Puesta en producción</p>
<p class="text-body text-gosign-text">La versión actualizada se pone en producción. El tiempo de inactividad suele ser inferior a 30 minutos.</p>
</div>
</li>
</ol>
<p class="text-body text-gosign-text leading-relaxed mt-6">
<strong>Tiempo estimado:</strong> Una actualización menor (p.ej. 12.4 a 12.6) dura pocas horas. Una actualización mayor (p.ej. v10 a v13) puede llevar varios días según las extensiones y personalizaciones.
</p>
</div>
</section>

<!-- Hosting y mantenimiento CMS -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Por qué hosting y mantenimiento CMS van de la mano</h2>
<p class="text-body text-gosign-text leading-relaxed">
Las actualizaciones de TYPO3 no solo afectan al software. Las nuevas versiones a menudo requieren versiones más recientes de PHP, configuraciones de base de datos adaptadas o ajustes de servidor actualizados. Cuando el mantenimiento del CMS y el hosting están con diferentes proveedores, surge un esfuerzo de coordinación - y en el peor caso una brecha de seguridad porque nadie se siente responsable.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Gosign ofrece ambos servicios de forma integrada: mantenimiento CMS incluyendo actualizaciones, monitorización de extensiones y hosting en servidores europeos. Así se garantiza que el entorno del servidor y la versión del CMS siempre sean compatibles.
</p>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
Gosign es una agencia digital de Hamburgo con 25 años de experiencia en desarrollo web, TYPO3 e integración de IA.
Hemos analizado más de 800 extensiones TYPO3 y hoy desarrollamos con apoyo de IA
hasta un 70 % más rápido que con métodos convencionales. Nuestros clientes son empresas medianas,
universidades y organismos públicos en Europa.
</p>
<p class="text-small text-gosign-text-light mt-2">Actualizado: marzo 2026</p>
</div>
</section>

<!-- Temas relacionados -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Temas relacionados</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/es/conocimiento/obligaciones-rgpd-sitios-web/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Derecho</p>
<p class="text-body font-semibold text-gosign-dark">Obligaciones del RGPD para sitios web</p>
</a>
<a href="/es/conocimiento/accesibilidad-bfsg-2025/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Derecho</p>
<p class="text-body font-semibold text-gosign-dark">Accesibilidad y Directiva 2019/882</p>
</a>
<a href="/es/conocimiento/schema-org-seo-fundamentos/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">SEO</p>
<p class="text-body font-semibold text-gosign-dark">Schema.org y fundamentos de SEO</p>
</a>
</div>
</div>
</section>

--- Contacto ---
> Hable con nosotros sobre un proceso concreto. Formulario de contacto y reserva de cita.

<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">

<div id="hq" class="scroll-mt-24">
<h2 class="text-h2 font-bold text-gosign-dark">Sede central y Governance</h2>
<p class="text-body-lg text-gosign-text-light mt-2">Dirección ejecutiva, arquitectura de governance, proyectos DACH.</p>
<div class="mt-6 grid grid-cols-1 sm:grid-cols-2 gap-6">
<div>
<h3 class="text-body font-bold text-gosign-dark">Hamburgo</h3>
<div class="text-body text-gosign-text-light mt-1 space-y-0.5">
<p>Gosign GmbH</p>
<p>Hallerstraße 8</p>
<p>20146 Hamburgo, Alemania</p>
</div>
</div>
<div>
<h3 class="text-body font-bold text-gosign-dark">Centro de Formación Hamburgo</h3>
<div class="text-body text-gosign-text-light mt-1 space-y-0.5">
<p>Grindelberg 77</p>
<p>20144 Hamburgo</p>
</div>
</div>
</div>
</div>

<div id="market" class="mt-12 pt-8 border-t border-gosign-border scroll-mt-24">
<h2 class="text-h2 font-bold text-gosign-dark">Gestión de proyectos y presencia de mercado</h2>
<p class="text-body-lg text-gosign-text-light mt-2">Directores de proyecto en tu zona horaria, en tu idioma.</p>
<div class="mt-6 grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-3 gap-6">
<div>
<h3 class="text-body font-bold text-gosign-dark">Barcelona</h3>
<div class="text-body text-gosign-text-light mt-1 space-y-0.5">
<p>Gosign - Oficina Barcelona</p>
<p><a href="https://www.gosign.es" target="_blank" rel="noopener noreferrer" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">gosign.es</a></p>
</div>
</div>
<div>
<h3 class="text-body font-bold text-gosign-dark">Berlín</h3>
<div class="text-body text-gosign-text-light mt-1 space-y-0.5">
<p>Gosign GmbH - Oficina Berlín</p>
<p>Nogatstraße 46</p>
<p>12051 Berlín, Alemania</p>
</div>
</div>
<div>
<h3 class="text-body font-bold text-gosign-dark">Cracovia</h3>
<div class="text-body text-gosign-text-light mt-1 space-y-0.5">
<p>Gosign - Oficina Cracovia</p>
<p><a href="https://www.gosign.pl" target="_blank" rel="noopener noreferrer" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">gosign.pl</a></p>
</div>
</div>
<div>
<h3 class="text-body font-bold text-gosign-dark">Lisboa</h3>
<div class="text-body text-gosign-text-light mt-1 space-y-0.5">
<p>Gosign - Oficina Lisboa</p>
<p><a href="https://www.gosign.pt" target="_blank" rel="noopener noreferrer" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">gosign.pt</a></p>
</div>
</div>
<div>
<h3 class="text-body font-bold text-gosign-dark">São Paulo <span class="text-gosign-text-light font-normal">(Oficina LATAM)</span></h3>
<div class="text-body text-gosign-text-light mt-1 space-y-0.5">
<p>Gosign - Oficina São Paulo</p>
<p><a href="https://www.gosign.pt" target="_blank" rel="noopener noreferrer" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">gosign.pt</a></p>
</div>
</div>
</div>
</div>

<div id="engineering" class="mt-12 pt-8 border-t border-gosign-border scroll-mt-24">
<h2 class="text-h2 font-bold text-gosign-dark">Ingeniería e Investigación</h2>
<p class="text-body-lg text-gosign-text-light mt-2">Más de 60 ingenieros. Alianzas universitarias para investigación y desarrollo de talento.</p>
<div class="mt-6">
<h3 class="text-body font-bold text-gosign-dark">Lahore · Islamabad, Pakistán</h3>
<div class="text-body text-gosign-text-light mt-1 space-y-0.5">
<p>Centros de desarrollo con alianzas universitarias:</p>
<p><a href="https://pu.edu.pk/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-text-light transition-colors underline decoration-dotted">University of the Punjab</a> · <a href="https://www.comsats.edu.pk/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-text-light transition-colors underline decoration-dotted">COMSATS University</a></p>
<p><a href="https://www.gosign.pk" target="_blank" rel="noopener noreferrer" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">gosign.pk</a></p>
</div>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark">Qué Cubrimos en la Primera Conversación</h2>
<ul class="mt-4 space-y-2 text-body-lg text-gosign-text-light">
<li>¿Qué proceso debe automatizarse?</li>
<li>¿Qué sistemas están involucrados (SAP, Sage, Workday, etc.)?</li>
<li>¿Qué requisitos de gobernanza aplican (comité de empresa, auditoría, cumplimiento)?</li>
<li>¿Cloud, self-hosted o híbrido?</li>
<li>Cronograma y próximos pasos</li>
</ul>
</div>
</section>

--- Datos - Gosign en Cifras ---
> Datos citables sobre Gosign GmbH. Datos de empresa, ubicaciones, certificaciones y estándares de compliance de un vistazo.

<article class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<div class="prose prose-lg prose-headings:text-gosign-dark prose-headings:font-bold prose-h2:text-h2 prose-h2:mt-12 prose-h2:mb-4 prose-h3:text-h3 prose-h3:mt-8 prose-h3:mb-3 prose-p:text-gosign-text prose-p:leading-relaxed prose-a:text-gosign-accent-text prose-a:underline prose-a:decoration-gosign-accent-text/30 hover:prose-a:decoration-gosign-accent-text prose-strong:text-gosign-dark prose-ul:text-gosign-text prose-ol:text-gosign-text">

## Empresa

Gosign GmbH. Empresa de desarrollo de software, fundada en Hamburgo en 2001. Empresa propietaria. Directores generales: Bert Gogolin y Dieter Gogolin. Hallerstraße 8, 20146 Hamburgo, Alemania. Registro Mercantil Hamburgo HRB 112197. NIF-IVA: DE215891388.

## Cifras Clave

108 empleados. Más de 5.000 proyectos desde 2001. 25 años de desarrollo de software. Desde 2023 enfocados en Enterprise AI Infrastructure y Agent Engineering. Clientes de referencia: Airbus, Volkswagen, Shell, Evonik, Sony.

## Ubicaciones

Hamburgo (sede central), Cracovia, Barcelona, Lisboa, São Paulo. Centro de desarrollo en Pakistán desde 2002.

## Idiomas

Alemán, inglés, polaco, español, portugués, urdu.

## Membresías y Certificaciones

Miembro del BVDW (Bundesverband Digitale Wirtschaft). Ingenieros de AI con certificación Microsoft Azure AI.

## Estándares de Compliance

Cert-Ready by Design: ISA, PS 951, IDW, GoB/GoBD (estándar alemán de contabilidad) (estándar alemán de contabilidad). EU AI Act Readiness: clasificación de riesgo y obligaciones de documentación integradas en la arquitectura de agentes. Data Residency: procesamiento de datos en la infraestructura del cliente - Azure UE, GCP UE, AWS UE, Self-Hosted o híbrido. El cliente decide la región y el modelo de hosting. DPA con todos los subprocesadores. Para total independencia del Cloud Act: Self-Hosted en su propio centro de datos o en sus propios servidores. RGPD: sin cookies, sin trackers, sin embeds externos en gosign.de. Analítica web sin cookies, agregada.

## Contacto

Gosign GmbH · Hallerstraße 8 · 20146 Hamburgo, Alemania
> [Contactar](/es/contacto/)

</div>
</div>
</article>

--- Decision Layer - Decisiones AI trazables para HR y Finance ---
> El Decision Layer hace cada decisión de IA auditable, compatible con comité de empresa y trazable. Para HR, Finance y procesos basados en documentos.

<!-- Por qué fracasan los proyectos de IA -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Por qué fracasan los proyectos de IA en RRHH</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Los procesos de RRHH dependen del conocimiento de empleados individuales. ¿Quién sabe qué política de permisos especiales aplica en cada ubicación? ¿Quién recuerda la diferencia entre el acuerdo de empresa de 2019 y la versión actualizada de 2024? ¿Quién verifica si una baja médica fue correctamente validada contra el convenio colectivo?
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Este conocimiento vive en las cabezas de las personas, en hilos de correo electrónico, en carpetas que nadie puede encontrar. Cuando alguien deja el equipo, el conocimiento se va con él.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
La IA puede ayudar - pero solo cuando está claro qué reglas aplican. Y quién es el responsable final.
</p>
</div>
</section>

<!-- Definición: ¿Qué es el Decision Layer? -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">¿Qué es el Decision Layer?</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
El Decision Layer descompone cada proceso empresarial en pasos de decisión individuales y define de antemano para cada uno: ¿Decide una persona, un conjunto de reglas o la IA de forma autónoma?
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Donde interviene la discrecionalidad, el riesgo de discriminación o los derechos de consulta del Comité de Empresa (Art. 64 del Estatuto de los Trabajadores), la arquitectura impone la revisión humana. Donde la decisión es determinista - términos del convenio colectivo, control de plazos, lógica contable - el agente aplica el conjunto de reglas de forma consistente. Y donde el agente es lo suficientemente confiable y tiene permiso: decide de forma autónoma. Interpreta documentos, clasifica situaciones, evalúa contexto y reconoce patrones. Esto no es if-then-else - es capacidad de juicio dentro de límites definidos. El Confidence Routing controla: alta confianza y bajo riesgo significa decisión autónoma, baja confianza o alto riesgo significa escalación a una persona. Este Confidence Routing es precisamente lo que distingue al Decision Layer del RPA.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Cada decisión queda documentada - quién decidió qué, cuándo, sobre qué base, con qué resultado. Auditable para auditores de cuentas, Comité de Empresa y auditoría interna. Esa documentación es el <strong class="text-gosign-dark">acta de decisión</strong>: por microdecisión, una prueba inmutable con input, regla de negocio con su versión, confianza, versión del modelo, resultado y vía de impugnación - el artefacto que hace responder la explicación de la decisión individual conforme al art. 86 del EU AI Act.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
El Decision Layer no es un AI Agent - es la capa de governance por encima. Complementa sistemas existentes como SAP SuccessFactors, Workday u otros sistemas ERP y controla lo que un AI Agent puede hacer con estos sistemas.
</p>
<p class="text-body text-gosign-text-light mt-4">
Cómo el Decision Layer resuelve la Shadow AI y aplica técnicamente los acuerdos de empresa lo describe el
<a href="/es/revista/decision-layer-shadow-ai/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Artículo 6 del Blueprint 2026</a>.
</p>

<!-- Tabla comparativa -->
<div class="mt-8 overflow-x-auto">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-dark/20">
<th class="py-3 pr-4 text-body font-bold text-gosign-dark"></th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Sin Decision Layer</th>
<th class="py-3 pl-4 text-body font-bold text-gosign-accent-text">Con Decision Layer</th>
</tr>
</thead>
<tbody class="text-body-lg text-gosign-text-light">
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">¿Quién decide?</td>
<td class="py-3 px-4">No está claro - el agente entrega un resultado</td>
<td class="py-3 pl-4">Definido por paso: humano, conjunto de reglas o IA</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Acuerdos de empresa</td>
<td class="py-3 px-4">Seguidos manualmente - o olvidados</td>
<td class="py-3 pl-4">Almacenados como reglas fijas, técnicamente aplicados</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Trazabilidad</td>
<td class="py-3 px-4">Resultado visible, camino de decisión no</td>
<td class="py-3 pl-4">Documentación completa por decisión</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Auditor</td>
<td class="py-3 px-4">Debe revisar manualmente cada caso</td>
<td class="py-3 pl-4">Acceso directo a la documentación de decisiones</td>
</tr>
<tr>
<td class="py-3 pr-4 font-semibold text-gosign-dark">Comité de empresa</td>
<td class="py-3 px-4">Bloquea - sin transparencia</td>
<td class="py-3 pl-4">Apoya - cada decisión trazable</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Ejemplo: Baja médica -->
<section id="ejemplo" class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-2">¿Cómo funciona el Decision Layer en la práctica?</h2>
<p class="text-body-lg text-gosign-text-light mb-8">
Ejemplo de baja médica: 6 pasos, responsabilidad clara en cada paso. El Decision Layer define para cada uno: conjunto de reglas, humano o automático.
</p>
<img
src="/images/diagrams/decision-layer-krankmeldung-es.svg"
alt="Ejemplo de proceso: procesamiento de baja médica con Decision Layer en 6 pasos. Pasos 1-2 automáticos (leer documento, cargar datos del empleado), pasos 3-4 basados en reglas (validar contra convenio colectivo, calcular continuación de pago), paso 5 decisión humana (enfermedad prolongada más de 6 semanas), paso 6 contabilización automática SAP."
class="w-full"
loading="lazy"
width="1200"
height="600"
/>
</div>
</section>

<!-- Comité de empresa -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">¿Por qué los proyectos de IA fracasan en el comité de empresa?</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
La razón más común por la que los proyectos de IA fracasan en las empresas: el comité de empresa los bloquea. No porque se opongan a la tecnología - sino porque carecen de transparencia. El Decision Layer resuelve esto:
</p>
<div class="mt-8 space-y-4">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent/10 rounded-full flex items-center justify-center text-gosign-accent font-bold text-small before:content-['✓']" aria-hidden="true"></span>
<p class="text-body-lg text-gosign-text-light">Cada acuerdo de empresa se almacena como una regla fija. El agente no puede eludirlo.</p>
</div>
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent/10 rounded-full flex items-center justify-center text-gosign-accent font-bold text-small before:content-['✓']" aria-hidden="true"></span>
<p class="text-body-lg text-gosign-text-light">Para decisiones que afectan a empleados, siempre decide un humano. Técnicamente forzado, no solo acordado.</p>
</div>
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent/10 rounded-full flex items-center justify-center text-gosign-accent font-bold text-small before:content-['✓']" aria-hidden="true"></span>
<p class="text-body-lg text-gosign-text-light">Cada decisión de IA está documentada: qué se verificó, qué regla aplicó, cuál fue el resultado.</p>
</div>
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent/10 rounded-full flex items-center justify-center text-gosign-accent font-bold text-small before:content-['✓']" aria-hidden="true"></span>
<p class="text-body-lg text-gosign-text-light">El comité de empresa puede rastrear cómo se tomó cualquier decisión, en cualquier momento.</p>
</div>
</div>
<p class="text-body-lg text-gosign-text-light mt-6">
<strong class="text-gosign-dark">La diferencia:</strong> Otros prometen transparencia. El Decision Layer la impone técnicamente.
</p>
<p class="mt-4">
<a href="/es/governance/co-determination/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Codecisión y agentes de IA →</a>
</p>
</div>
</section>

<!-- Preparado para auditoría -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">¿Cómo se vuelve una decisión de IA preparada para auditoría?</h2>
<p class="text-body-lg text-gosign-accent-text font-semibold mt-4">Su auditor ve exactamente lo que sucedió.</p>
<ul class="mt-6 space-y-3">
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-6 h-6 bg-gosign-accent/10 rounded-full flex items-center justify-center text-gosign-accent font-bold text-xs mt-0.5 before:content-['✓']" aria-hidden="true"></span>
<span class="text-body-lg text-gosign-text-light">¿Qué documento se procesó - y cuándo?</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-6 h-6 bg-gosign-accent/10 rounded-full flex items-center justify-center text-gosign-accent font-bold text-xs mt-0.5 before:content-['✓']" aria-hidden="true"></span>
<span class="text-body-lg text-gosign-text-light">¿Qué regla se aplicó - y en qué versión?</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-6 h-6 bg-gosign-accent/10 rounded-full flex items-center justify-center text-gosign-accent font-bold text-xs mt-0.5 before:content-['✓']" aria-hidden="true"></span>
<span class="text-body-lg text-gosign-text-light">¿Cuán seguro estaba el agente en su evaluación?</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-6 h-6 bg-gosign-accent/10 rounded-full flex items-center justify-center text-gosign-accent font-bold text-xs mt-0.5 before:content-['✓']" aria-hidden="true"></span>
<span class="text-body-lg text-gosign-text-light">¿Revisó un humano - y si es así, quién?</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-6 h-6 bg-gosign-accent/10 rounded-full flex items-center justify-center text-gosign-accent font-bold text-xs mt-0.5 before:content-['✓']" aria-hidden="true"></span>
<span class="text-body-lg text-gosign-text-light">¿Cuál fue el resultado y cuándo se contabilizó?</span>
</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-6">Cada una de estas respuestas figura en un acta de decisión - así es como se ve:</p>
<div class="not-prose mt-4 bg-surface-raised border border-base rounded-soft overflow-hidden shadow-sm">
  <div class="px-5 py-3 border-b border-base bg-surface-dim">
    <div class="flex items-center gap-3">
      <div class="flex gap-1.5" aria-hidden="true">
        <span class="w-2.5 h-2.5 rounded-full bg-[#FF5F56]"></span>
        <span class="w-2.5 h-2.5 rounded-full bg-[#FFBD2E]"></span>
        <span class="w-2.5 h-2.5 rounded-full bg-[#27C93F]"></span>
      </div>
      <span class="font-code text-xs text-muted">decision-record / parte-de-baja / 2026-05-14 / EMP_0x52a8</span>
    </div>
  </div>
  <ol class="divide-y divide-base">
    <li class="p-5">
      <div class="flex items-start gap-4">
        <div class="flex-shrink-0 w-9 h-9 rounded-full flex items-center justify-center font-code text-xs font-bold border" style="background: rgba(3,105,161,0.08); border-color: rgba(3,105,161,0.3); color: #0369A1;">02</div>
        <div class="flex-1 min-w-0">
          <div class="flex flex-wrap items-center gap-2 mb-1.5">
            <span class="text-body font-semibold text-primary">C&#225;lculo de la prestaci&#243;n seg&#250;n art. 169-176 LGSS</span>
            <span class="inline-flex px-2 py-0.5 text-xs font-bold uppercase tracking-wider rounded text-white" style="background: #0369A1;">Regla</span>
          </div>
          <p class="text-small text-primary font-medium mb-2">60 % de la base reguladora desde el d&#237;a 4</p>
          <div class="font-code text-xs text-muted"><span>rule:</span> <span class="text-primary">LGSS art. 169-176 &#183; v2026-01</span></div>
        </div>
      </div>
    </li>
    <li class="p-5">
      <div class="flex items-start gap-4">
        <div class="flex-shrink-0 w-9 h-9 rounded-full flex items-center justify-center font-code text-xs font-bold border" style="background: rgba(109,78,216,0.08); border-color: rgba(109,78,216,0.3); color: #6D4ED8;">09</div>
        <div class="flex-1 min-w-0">
          <div class="flex flex-wrap items-center gap-2 mb-1.5">
            <span class="text-body font-semibold text-primary">Marcar patr&#243;n de ausencias</span>
            <span class="inline-flex items-center gap-1 px-2 py-0.5 text-xs font-bold uppercase tracking-wider rounded text-white" style="background: #6D4ED8;">IA <span class="font-mono opacity-90">91%</span></span>
          </div>
          <p class="text-small text-primary font-medium mb-2">Aviso a RRHH: tercera baja corta en seis meses</p>
          <div class="font-code text-xs text-muted"><span>model-reason:</span> <span class="text-primary">coincidencia de patr&#243;n &#183; indicador, no decisi&#243;n de personal</span></div>
          <div class="mt-3"><span class="inline-flex items-center px-3 py-1.5 text-xs font-semibold rounded border-2" style="border-color: #6D4ED8; color: #6D4ED8; background: rgba(109,78,216,0.08);">formalmente impugnable &#183; art. 14 EU AI Act</span></div>
        </div>
      </div>
    </li>
  </ol>
</div>
<p class="text-body text-gosign-text-light mt-4">Dos de 13 microdecisiones de un expediente - cada una con versi&#243;n de regla, confianza y v&#237;a de impugnaci&#243;n. <a href="/es/revista/acta-de-decision-decisiones-ia-impugnables/" class="text-gosign-accent-text hover:underline font-semibold">El acta de decisi&#243;n completa, en detalle &#8594;</a></p>
</div>
</section>

<!-- Tres tipos de decisiones -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-2">¿Qué decisiones puede tomar la IA por sí sola?</h2>
<p class="text-body-lg text-gosign-text-light mb-8">
Algunas decisiones un AI Agent puede tomarlas por sí solo. Otras necesitan revisión humana. Y para preguntas estratégicas, el agente solo proporciona datos. El Decision Layer lo define - por paso, no por proceso.
</p>
<img
src="/images/diagrams/decision-layer-drei-arten-es.svg"
alt="Tres tipos de decisiones en el Decision Layer: Izquierda - humano decide para estrategia de personal, revisiones de desempeño, política de compensación (aproximadamente un tercio). Centro - agente trabaja, humano revisa para procesamiento de documentos, revisión de contratos, onboarding (aproximadamente 40%). Derecha - agente autónomo para FAQ, certificados estándar, verificación de plazos (aproximadamente un cuarto)."
class="w-full"
loading="lazy"
width="1200"
height="600"
/>
</div>
</section>

<!-- Para quién -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">¿Para quién es el Decision Layer?</h2>
<div class="mt-8 space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Head of HR / CHRO</p>
<p class="text-body-lg text-gosign-text-light mt-1">Quiere usar IA en RRHH - sin perder el control. El Decision Layer asegura que los acuerdos de empresa se cumplan, el comité de empresa tenga transparencia y cada decisión sea trazable.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">CFO / Head of Finance</p>
<p class="text-body-lg text-gosign-text-light mt-1">Cada contabilización asistida por IA está documentada de forma auditable. Su auditor ve el camino de decisión completo. Las contabilizaciones correctivas se reducen porque los conjuntos de reglas se aplican de forma consistente, y donde el agente decide autónomamente, lo hace de manera demostrable más fiable que el procesamiento manual.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Comité de empresa</p>
<p class="text-body-lg text-gosign-text-light mt-1">Sin caja negra. Los acuerdos de empresa están técnicamente almacenados y no pueden eludirse. Para decisiones de personal, siempre interviene un humano.</p>
</div>
<div class="border-l-4 border-gosign-dark/20 pl-6">
<p class="text-h3 font-bold text-gosign-text-light">IT / CTO</p>
<p class="text-body-lg text-gosign-text-light mt-1">Agnóstico de modelo, agnóstico de infraestructura, sin vendor lock-in. <a href="/es/governance/reference-architecture/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Detalles técnicos en la Arquitectura de Referencia →</a></p>
</div>
</div>
</div>
</div>
</section>

<!-- Dominios -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">El Decision Layer para sus procesos</h2>
<div class="grid grid-cols-1 md:grid-cols-3 gap-6">
<a href="/es/hr-ai-agents/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<h3 class="text-h3 font-bold text-gosign-dark">HR & People Operations</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Bajas médicas, onboarding, referencias laborales, revisión de contratos, consultas de políticas. Compatible con comité de empresa, conforme al EU AI Act.</p>
<span class="inline-block mt-4 text-gosign-accent-text font-semibold text-body">HR Agent →</span>
</a>
<a href="/es/finance-ai-agents/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<h3 class="text-h3 font-bold text-gosign-dark">Finance & Payroll</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Procesamiento de documentos, contabilización, nómina, asientos de cierre. Preparado para auditoría. Integración SAP y sistemas ERP.</p>
<span class="inline-block mt-4 text-gosign-accent-text font-semibold text-body">Finance Agent →</span>
</a>
<a href="/es/servicios/ai-agents/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<h3 class="text-h3 font-bold text-gosign-dark">Procesamiento de documentos</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Facturas, contratos, certificados. Clasificación automática y extracción de datos con validación basada en reglas.</p>
<span class="inline-block mt-4 text-gosign-accent-text font-semibold text-body">Document Agents →</span>
</a>
</div>
</div>
</section>

<!-- EU AI Act -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">¿Es el Decision Layer conforme al EU AI Act?</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
El EU AI Act exige transparencia (art. 13), supervisión humana (art. 14) y registro (art. 12) - y con el art. 86 da al afectado un derecho a la explicación de la decisión individual. El Decision Layer aborda estos requisitos como un principio arquitectónico - no como un proyecto de compliance posterior: el acta de decisión por microdecisión es la respuesta a la pregunta del caso concreto que los chat-logs y las model cards no pueden responder.
</p>
<p class="mt-4">
<a href="/es/governance/eu-ai-act/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">EU AI Act y RRHH en detalle →</a>
<span class="mx-2 text-gosign-text-light">·</span>
<a href="/es/revista/acta-de-decision-decisiones-ia-impugnables/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">El acta de decisión: por qué toda decisión de IA debe ser impugnable →</a>
</p>
</div>
</section>

<!-- Información de la entidad -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">¿Quién está detrás del Decision Layer?</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
El Decision Layer es desarrollado e implementado por <strong class="text-gosign-dark">Gosign GmbH</strong>. Gosign es una Enterprise AI Infrastructure & Agent Engineering Company con sede en Hamburgo, Alemania, con más de 20 años de experiencia construyendo sistemas complejos para empresas como Airbus, Volkswagen, Shell.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
4-6 semanas hasta el primer proceso productivo. Acceso completo al código fuente, sin vendor lock-in. Objetivo: Tras 12-18 meses, usted opera sus agentes de forma independiente.
</p>
<p class="mt-4">
<a href="/es/sobre-nosotros/" class="text-gosign-accent-text hover:underline font-semibold">Sobre Gosign →</a>
<span class="mx-2 text-gosign-text-light">·</span>
<a href="/es/referencias/" class="text-gosign-accent-text hover:underline font-semibold">Referencias →</a>
</p>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">Profundización en el Agent Briefing (Revista Gosign)</h2>
<div class="grid md:grid-cols-3 gap-6">
<a href="/es/revista/acta-de-decision-decisiones-ia-impugnables/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<h3 class="text-h3 font-bold text-gosign-dark">El acta de decisión: decisiones de IA impugnables</h3>
</a>
<a href="/es/revista/agent-governance-hr/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR</p>
<h3 class="text-h3 font-bold text-gosign-dark">Agent Governance para RRHH</h3>
</a>
<a href="/es/revista/comite-empresa-ia-codeterminacion/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<h3 class="text-h3 font-bold text-gosign-dark">Comité de Empresa e IA - Codecisión</h3>
</a>
</div>
</div>
</section>

--- eBook: Finance Agent Readiness Assessment - 15 preguntas para CFO y auditores ---
> eBook gratuito: 15 preguntas sobre Finance Agent Readiness. Verificación de cumplimiento, preparación para auditoría, evaluación de equipo.

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">

<div class="grid md:grid-cols-5 gap-12 items-start">

<div class="md:col-span-3">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Qué encontrará en este assessment</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
El 42% de todas las facturas en cuentas por pagar se procesan todavía manualmente (IFM 2024). Con un coste medio de 11,50 EUR por factura, es un factor de coste medible. Este assessment muestra dónde se encuentra su organización financiera - y qué agentes aportan el mayor impacto.
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8 mb-3">15 preguntas en 5 dimensiones</h3>
<ul class="space-y-2 text-body text-gosign-text">
<li class="flex items-start gap-2"><span class="text-gosign-accent-text font-bold">1.</span> Preparación para auditoría - Qué tan preparados para auditoría están sus procesos?</li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text font-bold">2.</span> Secreto profesional - Estado de cumplimiento normativo y separación de datos</li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text font-bold">3.</span> Paisaje ERP - Qué tan integrados están sus sistemas financieros?</li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text font-bold">4.</span> Velocidad de cierre - Qué tan rápido es su cierre mensual?</li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text font-bold">5.</span> Madurez de procesos - Qué tan formalizadas están sus reglas contables?</li>
</ul>

<h3 class="text-h3 font-bold text-gosign-dark mt-8 mb-3">En qué se diferencia el eBook de la herramienta online</h3>
<div class="overflow-x-auto">
<table class="w-full text-body text-gosign-text border-collapse mt-4">
<thead><tr class="border-b-2 border-gosign-border"><th class="text-left py-2 pr-4 font-bold text-gosign-dark">Característica</th><th class="text-left py-2 pr-4 font-bold text-gosign-dark">Online (3 min.)</th><th class="text-left py-2 font-bold text-gosign-dark">eBook (PDF)</th></tr></thead>
<tbody>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Preguntas</td><td class="py-2 pr-4">7</td><td class="py-2">15</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Verificación de cumplimiento</td><td class="py-2 pr-4">Básica</td><td class="py-2">Avanzada (6 preguntas)</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Evaluación de equipo</td><td class="py-2 pr-4">No</td><td class="py-2">Sí (CFO + auditor + IT)</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Análisis de brechas</td><td class="py-2 pr-4">No</td><td class="py-2">Sí</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Imprimible</td><td class="py-2 pr-4">No</td><td class="py-2">Sí (optimizado A4)</td></tr>
</tbody>
</table>
</div>
</div>

<div class="md:col-span-2">
<div class="sticky top-24 bg-gosign-light border border-gosign-border rounded-card p-6">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-3">PDF gratuito</p>
<p class="text-h3 font-bold text-gosign-dark mb-2">Descargar assessment</p>
<p class="text-small text-gosign-text-light mb-4">14 páginas, verificación de cumplimiento, evaluación de preparación para auditoría, evaluación de equipo con análisis de brechas.</p>
<a href="#download" class="block w-full text-center px-6 py-3 bg-gosign-accent-btn text-white font-semibold rounded-lg hover:bg-gosign-accent-btn-hover transition-colors" data-ebook-download>Descargar assessment</a>
<p class="text-xs text-gosign-text-light mt-3">Solo se requiere correo electrónico. PDF inmediato.</p>
</div>
</div>

</div>
</div>
</section>

<!-- Test rápido -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<div class="border-2 border-gosign-accent/20 rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Test rápido: Evaluación online</p>
<p class="text-body text-gosign-text mb-4">No tiene tiempo para el assessment completo? Empiece con el test rápido de 3 minutos con 7 preguntas y gráfico radar automático.</p>
<a href="/es/finance-agent-readiness/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Iniciar evaluación online &rarr;</a>
</div>
</div>
</section>

<!-- Más eBooks -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Más eBooks</h2>
<div class="grid grid-cols-1 sm:grid-cols-2 gap-4">
<a href="/es/ebook/ia-finanzas-manual-gobernanza/" class="block border border-gosign-border rounded-card p-4 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-1">Finance Governance</p>
<p class="text-body font-semibold text-gosign-dark">IA en Finanzas: Manual de Gobernanza</p>
</a>
<a href="/es/ebook/hr-agent-readiness-assessment/" class="block border border-gosign-border rounded-card p-4 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-1">HR Assessment</p>
<p class="text-body font-semibold text-gosign-dark">HR Agent Readiness Assessment</p>
</a>
</div>
</div>
</section>

--- eBook: HR Agent Readiness Assessment - 15 preguntas para el equipo directivo ---
> eBook de evaluación gratuito: 15 preguntas sobre HR Agent Readiness. Hojas de trabajo, plantilla de gráfico radar, evaluación de equipo con análisis de brechas.

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">

<div class="grid md:grid-cols-5 gap-12 items-start">

<div class="md:col-span-3">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Qué encontrará en este assessment</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
El 73% de las organizaciones aún no tiene un marco de gobernanza de IA (ISACA 2024). Este assessment le muestra dónde se encuentra su organización de RRHH - no como un modelo teórico, sino como un documento de trabajo para su equipo.
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8 mb-3">15 preguntas en 5 dimensiones</h3>
<ul class="space-y-2 text-body text-gosign-text">
<li class="flex items-start gap-2"><span class="text-gosign-accent-text font-bold">1.</span> Madurez de procesos - Qué tan documentados y consistentes son sus procesos de RRHH?</li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text font-bold">2.</span> Governance - Quién es responsable de la IA en RRHH?</li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text font-bold">3.</span> Paisaje de datos - Qué calidad tienen sus datos de RRHH?</li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text font-bold">4.</span> Comité de Empresa - Cómo se involucra al Comité de Empresa en las decisiones sobre IA?</li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text font-bold">5.</span> Infraestructura IT - Qué tan integrado está su paisaje de sistemas de RRHH?</li>
</ul>

<h3 class="text-h3 font-bold text-gosign-dark mt-8 mb-3">En qué se diferencia el eBook de la herramienta online</h3>
<div class="overflow-x-auto">
<table class="w-full text-body text-gosign-text border-collapse mt-4">
<thead><tr class="border-b-2 border-gosign-border"><th class="text-left py-2 pr-4 font-bold text-gosign-dark">Característica</th><th class="text-left py-2 pr-4 font-bold text-gosign-dark">Online (3 min.)</th><th class="text-left py-2 font-bold text-gosign-dark">eBook (PDF)</th></tr></thead>
<tbody>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Preguntas</td><td class="py-2 pr-4">7</td><td class="py-2">15</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Gráfico radar</td><td class="py-2 pr-4">Automático</td><td class="py-2">Plantilla para dibujar</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Evaluación de equipo</td><td class="py-2 pr-4">No</td><td class="py-2">Sí (4-5 participantes)</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Análisis de brechas</td><td class="py-2 pr-4">No</td><td class="py-2">Sí</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Imprimible</td><td class="py-2 pr-4">No</td><td class="py-2">Sí (optimizado A4)</td></tr>
</tbody>
</table>
</div>
</div>

<div class="md:col-span-2">
<div class="sticky top-24 bg-gosign-light border border-gosign-border rounded-card p-6">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-3">PDF gratuito</p>
<p class="text-h3 font-bold text-gosign-dark mb-2">Descargar assessment</p>
<p class="text-small text-gosign-text-light mb-4">14 páginas, hojas de trabajo para completar, evaluación de equipo con análisis de brechas.</p>
<a href="#download" class="block w-full text-center px-6 py-3 bg-gosign-accent-btn text-white font-semibold rounded-lg hover:bg-gosign-accent-btn-hover transition-colors" data-ebook-download>Descargar assessment</a>
<p class="text-xs text-gosign-text-light mt-3">Solo se requiere correo electrónico. PDF inmediato.</p>
</div>
</div>

</div>
</div>
</section>

<!-- Test rápido -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<div class="border-2 border-gosign-accent/20 rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Test rápido: Evaluación online</p>
<p class="text-body text-gosign-text mb-4">No tiene tiempo para el assessment completo? Empiece con el test rápido de 3 minutos con 7 preguntas y gráfico radar automático.</p>
<a href="/es/hr-agent-readiness/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Iniciar evaluación online &rarr;</a>
</div>
</div>
</section>

<!-- Más eBooks -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Más eBooks</h2>
<div class="grid grid-cols-1 sm:grid-cols-2 gap-4">
<a href="/es/ebook/ia-rrhh-manual-gobernanza/" class="block border border-gosign-border rounded-card p-4 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-1">HR Governance</p>
<p class="text-body font-semibold text-gosign-dark">IA en RRHH: Manual de Gobernanza para el Director de RRHH</p>
</a>
<a href="/es/ebook/finance-agent-readiness-assessment/" class="block border border-gosign-border rounded-card p-4 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-1">Finance Assessment</p>
<p class="text-body font-semibold text-gosign-dark">Finance Agent Readiness Assessment</p>
</a>
</div>
</div>
</section>

--- eBook: IA en Finanzas - Manual de Gobernanza para el CFO ---
> eBook gratuito: EU AI Act, auditores externos y Decision Layer - el manual de gobernanza para líderes financieros ante el plazo de alto riesgo (agosto 2026, aplazamiento a diciembre 2027 acordado provisionalmente).

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">

<div class="grid md:grid-cols-5 gap-12 items-start">

<div class="md:col-span-3">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Qué encontrará en este manual</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
El EU AI Act clasifica las decisiones crediticias asistidas por IA como alto riesgo (Anexo III N.º 5b). El 73% de las organizaciones aún no cuenta con un marco de gobernanza (ISACA 2024). La AESIA (Agencia Española de Supervisión de la IA) supervisará el cumplimiento en España. Este manual cierra la brecha - con marcos específicos para finanzas, checklists y una Evaluación de Preparación.
</p>

<div class="space-y-4 mb-8">
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">1</span>
<div>
<p class="font-semibold text-gosign-dark">Por qué el CFO debe liderar la gobernanza de IA en Finanzas - no TI</p>
<p class="text-small text-gosign-text-light">Propiedad de la gobernanza, concepto de roles y checklist del CFO.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">2</span>
<div>
<p class="font-semibold text-gosign-dark">Tres tipos de decisiones financieras: Humano, Reglamento, IA</p>
<p class="text-small text-gosign-text-light">El framework H/R/A con Agent Readiness Score para cada proceso financiero.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">3</span>
<div>
<p class="font-semibold text-gosign-dark">EU AI Act: Requisitos para el sector financiero</p>
<p class="text-small text-gosign-text-light">Delimitación de alto riesgo (Anexo III N.º 5b) con checklist de compliance.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">4</span>
<div>
<p class="font-semibold text-gosign-dark">Auditores externos como socios de gobernanza</p>
<p class="text-small text-gosign-text-light">NIA 315, Auditor Portal, obligación de AI Literacy desde febrero 2025.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">5</span>
<div>
<p class="font-semibold text-gosign-dark">4 procesos financieros en el Decision Layer</p>
<p class="text-small text-gosign-text-light">Cuentas por pagar, gastos de viaje, cierre financiero, detección de fraude - con tasas Zero-Touch.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">6</span>
<div>
<p class="font-semibold text-gosign-dark">Evaluación de Preparación Financiera (10 preguntas)</p>
<p class="text-small text-gosign-text-light">Dónde se encuentra su organización? Autoevaluación con puntuación y recomendaciones.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">7</span>
<div>
<p class="font-semibold text-gosign-dark">Plan de 90 días para empezar</p>
<p class="text-small text-gosign-text-light">Inventario, diseño, piloto - camino estructurado al Decision Layer en tres meses.</p>
</div>
</div>
</div>
</div>

<div class="md:col-span-2">
<div class="bg-gosign-light border border-gosign-border rounded-card p-6 sticky top-8">
<p class="text-h3 font-bold text-gosign-dark mb-2">Descargar gratis</p>
<p class="text-small text-gosign-text-light mb-4">PDF, 28 páginas. Entrega inmediata por email.</p>

<div class="space-y-3 mb-6">
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>Checklist de compliance EU AI Act (Finanzas)</span>
</div>
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>Framework de decisiones H/R/A</span>
</div>
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>Evaluación de Preparación Financiera práctica</span>
</div>
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>Plan de implementación de 90 días</span>
</div>
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>Checklist de auditor externo (NIA 315)</span>
</div>
</div>

<button data-ebook-download class="w-full px-6 py-3 bg-gosign-accent-btn text-white font-semibold rounded-md hover:bg-gosign-accent-btn-hover transition-colors text-sm flex items-center justify-center gap-2 cursor-pointer">
<svg class="w-5 h-5" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M4 16v1a3 3 0 003 3h10a3 3 0 003-3v-1m-4-4l-4 4m0 0l-4-4m4 4V4"/></svg>
Descargar PDF
</button>
</div>
</div>

</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">5 cifras clave del manual</h2>

<div class="grid sm:grid-cols-2 lg:grid-cols-3 gap-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">5%</p>
<p class="text-small text-gosign-text">de la facturación anual se pierde por fraude a nivel mundial</p>
<p class="text-xs text-gosign-text-light mt-1">ACFE 2024</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">42%</p>
<p class="text-small text-gosign-text">de las facturas en cuentas por pagar aún se procesan manualmente</p>
<p class="text-xs text-gosign-text-light mt-1">Institute of Finance & Management 2024</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">88-95%</p>
<p class="text-small text-gosign-text">tasa Zero-Touch con Decision Layer en procesos financieros</p>
<p class="text-xs text-gosign-text-light mt-1">Proyectos de clientes Gosign</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">1:4-5</p>
<p class="text-small text-gosign-text">ratio de inversión: 1 EUR tecnología = 4-5 EUR gobernanza</p>
<p class="text-xs text-gosign-text-light mt-1">McKinsey 2024</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">15M EUR</p>
<p class="text-small text-gosign-text">multa máxima por incumplimiento de requisitos de alto riesgo</p>
<p class="text-xs text-gosign-text-light mt-1">EU AI Act, Art. 99</p>
</div>
</div>

</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Para quién es este manual?</h2>

<div class="grid sm:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">CFO / VP Finanzas</p>
<p class="text-small text-gosign-text-light">Usted es responsable de la estrategia de IA en finanzas y necesita un marco que convenza a los auditores externos, al departamento legal y al consejo de administración al mismo tiempo.</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">Director de Finanzas / Responsable de Contabilidad</p>
<p class="text-small text-gosign-text-light">Usted implementa procesos impulsados por IA y necesita reglas claras de decisión: qué automatizar y qué no. Cómo mantener la seguridad de auditoría?</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">Auditor externo / Auditoría interna</p>
<p class="text-small text-gosign-text-light">Usted audita procesos financieros asistidos por IA y necesita transparencia: qué asientos procesa el agente y cuáles un humano? Cómo funciona el audit trail?</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">Finance Compliance / Legal</p>
<p class="text-small text-gosign-text-light">Necesita implementar los requisitos del EU AI Act para procesos financieros y necesita una checklist de compliance con medidas concretas e integración con el SCI.</p>
</div>
</div>

</div>
</section>

<section class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-12 border-t border-gosign-border">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Más eBooks</h2>
<div class="grid grid-cols-1 md:grid-cols-2 gap-6">

<div class="bg-white border border-gosign-border rounded-card p-5">
<p class="font-semibold text-gosign-dark mb-1">IA en RRHH - Manual de Gobernanza</p>
<p class="text-small text-gosign-text-light mb-3">Para CHROs y líderes de RRHH</p>
<a href="/es/ebook/ia-rrhh-manual-gobernanza/" class="text-sm text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Descargar gratis</a>
</div>

<div class="bg-white border border-gosign-border rounded-card p-5">
<p class="font-semibold text-gosign-dark mb-1">Infraestructura de IA - Manual de Gobernanza</p>
<p class="text-small text-gosign-text-light mb-3">Para CTOs y dirección de TI</p>
<a href="/es/ebook/ia-infraestructura-manual-gobernanza/" class="text-sm text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Descargar gratis</a>
</div>

<a href="/es/ebook/finance-agent-readiness-assessment/" class="block border border-gosign-border rounded-card p-4 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-1">Finance Assessment</p>
<p class="text-body font-semibold text-gosign-dark">Finance Agent Readiness Assessment</p>
<p class="text-small text-gosign-text-light mt-1">15 preguntas para CFO y auditores externos</p>
</a>

</div>
</section>

--- eBook: Infraestructura de IA - Manual de Gobernanza para el CTO ---
> eBook gratuito: Build, Buy, Hybrid - infraestructura de IA conforme al EU AI Act. Manual de gobernanza para CTOs y responsables de infraestructura.

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">

<div class="grid md:grid-cols-5 gap-12 items-start">

<div class="md:col-span-3">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Qué encontrará en este manual</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
Según Gartner (2024), las empresas gastarán más de 644 mil millones de USD en infraestructura de IA hasta 2027. Al mismo tiempo, desperdician el 28% del gasto en la nube (Flexera 2024). Este manual muestra cómo construir infraestructura de IA conforme a la gobernanza, eficiente en costes y preparada para el EU AI Act.
</p>

<div class="space-y-4 mb-8">
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">1</span>
<div>
<p class="font-semibold text-gosign-dark">Por qué el CTO debe liderar el AI Infrastructure Governance</p>
<p class="text-small text-gosign-text-light">Shadow AI, la brecha de gobernanza y la lista de verificación del CTO para comenzar.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">2</span>
<div>
<p class="font-semibold text-gosign-dark">Build, Buy, Hybrid: el framework B/B/H</p>
<p class="text-small text-gosign-text-light">Matriz de decisión por tipo de carga de trabajo con costes ocultos y riesgos ocultos.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">3</span>
<div>
<p class="font-semibold text-gosign-dark">EU AI Act: 6 requisitos técnicos (art. 9-15)</p>
<p class="text-small text-gosign-text-light">Obligaciones de cumplimiento como decisiones de infraestructura con lista de verificación técnica.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">4</span>
<div>
<p class="font-semibold text-gosign-dark">Security & Data Sovereignty</p>
<p class="text-small text-gosign-text-light">Data Residency, cifrado, arquitectura Zero Trust y cumplimiento del RGPD en el uso de LLM.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">5</span>
<div>
<p class="font-semibold text-gosign-dark">4 patrones de infraestructura en producción</p>
<p class="text-small text-gosign-text-light">Agent Orchestration, Document Intelligence, Model Gateway, Monitoring & Observability.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">6</span>
<div>
<p class="font-semibold text-gosign-dark">Infrastructure Readiness Assessment (10 preguntas)</p>
<p class="text-small text-gosign-text-light">¿Dónde se encuentra su infraestructura? Autoevaluación con puntuación y plan de 90 días.</p>
</div>
</div>
</div>
</div>

<div class="md:col-span-2">
<div class="bg-gosign-light border border-gosign-border rounded-card p-6 sticky top-8">
<p class="text-h3 font-bold text-gosign-dark mb-2">Descargar gratis</p>
<p class="text-small text-gosign-text-light mb-4">PDF, 28 páginas. Envío inmediato por correo electrónico.</p>

<div class="space-y-3 mb-6">
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>Matriz de decisión Build/Buy/Hybrid</span>
</div>
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>Lista de verificación de cumplimiento EU AI Act (técnica)</span>
</div>
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>4 patrones de infraestructura listos para producción</span>
</div>
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>Infrastructure Readiness Assessment + plan de 90 días</span>
</div>
</div>

<button data-ebook-download class="w-full px-6 py-3 bg-gosign-accent-btn text-white font-semibold rounded-md hover:bg-gosign-accent-btn-hover transition-colors text-sm flex items-center justify-center gap-2 cursor-pointer">
<svg class="w-5 h-5" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M4 16v1a3 3 0 003 3h10a3 3 0 003-3v-1m-4-4l-4 4m0 0l-4-4m4 4V4"/></svg>
Descargar PDF
</button>
</div>
</div>

</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">5 cifras clave del manual</h2>

<div class="grid sm:grid-cols-2 lg:grid-cols-3 gap-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">644 mil M</p>
<p class="text-small text-gosign-text">USD en gasto global en infraestructura de IA hasta 2027</p>
<p class="text-xs text-gosign-text-light mt-1">Gartner 2024</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">28%</p>
<p class="text-small text-gosign-text">del gasto en la nube desperdiciado por falta de gobernanza</p>
<p class="text-xs text-gosign-text-light mt-1">Flexera 2024</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">82%</p>
<p class="text-small text-gosign-text">operan multi-cloud sin gobernanza centralizada de IA</p>
<p class="text-xs text-gosign-text-light mt-1">HashiCorp 2024</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">40%</p>
<p class="text-small text-gosign-text">de incidentes de seguridad causados por servicios en la nube mal configurados</p>
<p class="text-xs text-gosign-text-light mt-1">ENISA 2024</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">15 M</p>
<p class="text-small text-gosign-text">EUR multa máxima por incumplimiento de obligaciones de alto riesgo</p>
<p class="text-xs text-gosign-text-light mt-1">EU AI Act, art. 99</p>
</div>
</div>

</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">¿Para quién es este manual?</h2>

<div class="grid sm:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">CTO / VP Engineering</p>
<p class="text-small text-gosign-text-light">Usted es responsable de la estrategia de infraestructura de IA y necesita un framework que combine escalabilidad, cumplimiento normativo y gobernanza de costes.</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">Responsable de infraestructura / plataforma</p>
<p class="text-small text-gosign-text-light">Usted construye la plataforma para cargas de trabajo de IA y necesita patrones listos para producción: Agent Orchestration, Model Gateway, Document Intelligence.</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">Cloud Architect / DevOps Lead</p>
<p class="text-small text-gosign-text-light">Usted decide entre build vs. buy y necesita la matriz de decisión: ¿qué carga de trabajo alojar internamente, cuál ejecutar como servicio gestionado?</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">CISO / Responsable de seguridad</p>
<p class="text-small text-gosign-text-light">Debe garantizar la soberanía de datos y necesita el stack de seguridad: Zero Trust, screening de PII, cifrado, seguridad de la cadena de suministro.</p>
</div>
</div>

</div>
</section>

<section class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-12 border-t border-gosign-border">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Más eBooks</h2>
<div class="grid grid-cols-1 md:grid-cols-2 gap-6">

<div class="bg-white border border-gosign-border rounded-card p-5">
<p class="font-semibold text-gosign-dark mb-1">IA en RRHH - Manual de Gobernanza</p>
<p class="text-small text-gosign-text-light mb-3">Para CHROs y líderes de RRHH</p>
<a href="/es/ebook/ia-rrhh-manual-gobernanza/" class="text-sm text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Descargar gratis</a>
</div>

<div class="bg-white border border-gosign-border rounded-card p-5">
<p class="font-semibold text-gosign-dark mb-1">IA en Finanzas - Manual de Gobernanza</p>
<p class="text-small text-gosign-text-light mb-3">Para CFOs y dirección financiera</p>
<a href="/es/ebook/ia-finanzas-manual-gobernanza/" class="text-sm text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Descargar gratis</a>
</div>

<a href="/es/ebook/hr-agent-readiness-assessment/" class="block border border-gosign-border rounded-card p-4 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-1">HR Assessment</p>
<p class="text-body font-semibold text-gosign-dark">HR Agent Readiness Assessment</p>
<p class="text-small text-gosign-text-light mt-1">15 preguntas para su equipo directivo</p>
</a>

<a href="/es/ebook/finance-agent-readiness-assessment/" class="block border border-gosign-border rounded-card p-4 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-1">Finance Assessment</p>
<p class="text-body font-semibold text-gosign-dark">Finance Agent Readiness Assessment</p>
<p class="text-small text-gosign-text-light mt-1">15 preguntas para CFO y auditores externos</p>
</a>

</div>
</section>

--- eBook: IA en RRHH - Manual de Gobernanza para el CHRO ---
> eBook gratuito: EU AI Act, comité de empresa y Decision Layer - el manual de gobernanza para responsables de RRHH ante el plazo de alto riesgo (agosto 2026, aplazamiento a diciembre 2027 acordado provisionalmente).

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">

<div class="grid md:grid-cols-5 gap-12 items-start">

<div class="md:col-span-3">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Qué encontrará en este manual</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
El EU AI Act clasifica los sistemas de IA en RRHH como alto riesgo; conforme a la legislación vigente, sus obligaciones se aplican desde agosto de 2026, con un aplazamiento a diciembre de 2027 acordado provisionalmente por el Digital Omnibus (mayo de 2026, adopción formal aún pendiente). El 73% de las organizaciones aún no cuenta con un marco de gobernanza (ISACA 2024). Este manual cierra la brecha - con marcos concretos, checklists y una evaluación de preparación.
</p>

<div class="space-y-4 mb-8">
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">1</span>
<div>
<p class="font-semibold text-gosign-dark">Por qué el CHRO debe liderar la gobernanza de IA en RRHH - no TI</p>
<p class="text-small text-gosign-text-light">Propiedad de la gobernanza, concepto de roles y checklist del CHRO.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">2</span>
<div>
<p class="font-semibold text-gosign-dark">Tres tipos de decisiones: Humano, Reglamento, IA</p>
<p class="text-small text-gosign-text-light">El framework de decisiones con Agent Readiness Score para cada proceso de RRHH.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">3</span>
<div>
<p class="font-semibold text-gosign-dark">EU AI Act: 6 requisitos obligatorios en detalle</p>
<p class="text-small text-gosign-text-light">Art. 9-15 con checklist de compliance para verificar.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">4</span>
<div>
<p class="font-semibold text-gosign-dark">Comité de empresa como socio de diseño</p>
<p class="text-small text-gosign-text-light">Derechos de consulta (Art. 64 ET), acuerdo de empresa como restricción técnica, AI Literacy.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">5</span>
<div>
<p class="font-semibold text-gosign-dark">4 procesos de RRHH en el Decision Layer</p>
<p class="text-small text-gosign-text-light">Nóminas, gastos de viaje, reclutamiento, ausencias - con tasas Zero-Touch.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">6</span>
<div>
<p class="font-semibold text-gosign-dark">Evaluación de preparación (10 preguntas)</p>
<p class="text-small text-gosign-text-light">Dónde se encuentra su organización? Autoevaluación con puntuación y recomendaciones.</p>
</div>
</div>
</div>
</div>

<div class="md:col-span-2">
<div class="bg-gosign-light border border-gosign-border rounded-card p-6 sticky top-8">
<p class="text-h3 font-bold text-gosign-dark mb-2">Descargar gratis</p>
<p class="text-small text-gosign-text-light mb-4">PDF, 25 páginas. Entrega inmediata por email.</p>

<div class="space-y-3 mb-6">
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>Checklist de compliance EU AI Act</span>
</div>
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>Framework de decisiones (H/R/A)</span>
</div>
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>Evaluación de preparación práctica</span>
</div>
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>Plan de implementación de 90 días</span>
</div>
</div>
<button data-ebook-download class="w-full px-6 py-3 bg-gosign-accent-btn text-white font-semibold rounded-md hover:bg-gosign-accent-btn-hover transition-colors text-sm flex items-center justify-center gap-2 cursor-pointer">
<svg class="w-5 h-5" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M4 16v1a3 3 0 003 3h10a3 3 0 003-3v-1m-4-4l-4 4m0 0l-4-4m4 4V4"/></svg>
Descargar PDF
</button>
</div>
</div>

</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">5 cifras clave del manual</h2>

<div class="grid sm:grid-cols-2 lg:grid-cols-3 gap-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">73%</p>
<p class="text-small text-gosign-text">de las organizaciones sin marco formal de gobernanza de IA</p>
<p class="text-xs text-gosign-text-light mt-1">ISACA 2024</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">6</p>
<p class="text-small text-gosign-text">requisitos obligatorios para IA de alto riesgo en RRHH (plazo vigente: agosto 2026; aplazamiento a diciembre 2027 acordado provisionalmente)</p>
<p class="text-xs text-gosign-text-light mt-1">EU AI Act, Art. 9-15</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">85-92%</p>
<p class="text-small text-gosign-text">tasa Zero-Touch con Decision Layer en procesos de RRHH</p>
<p class="text-xs text-gosign-text-light mt-1">Proyectos de clientes Gosign</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">1:4-5</p>
<p class="text-small text-gosign-text">ratio de inversión: 1 EUR tecnología = 4-5 EUR gobernanza</p>
<p class="text-xs text-gosign-text-light mt-1">McKinsey 2024</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">60-80%</p>
<p class="text-small text-gosign-text">menos correcciones contables con reglamentos explícitos</p>
<p class="text-xs text-gosign-text-light mt-1">Hackett Group 2024</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">15M</p>
<p class="text-small text-gosign-text">EUR multa máxima por incumplimiento de requisitos de alto riesgo</p>
<p class="text-xs text-gosign-text-light mt-1">EU AI Act, Art. 99</p>
</div>
</div>

</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Para quién es este manual?</h2>

<div class="grid sm:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">CHRO / VP RRHH</p>
<p class="text-small text-gosign-text-light">Usted es responsable de la estrategia de IA en RRHH y necesita un marco que convenza al comité de empresa, al departamento legal y a la dirección al mismo tiempo.</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">Director de People Operations</p>
<p class="text-small text-gosign-text-light">Implementa procesos impulsados por IA y necesita reglas claras de decisión: qué automatizar y qué no.</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">Comité de Empresa</p>
<p class="text-small text-gosign-text-light">Revisa el uso de IA en RRHH y necesita transparencia: qué decisiones toma el agente y cuáles el ser humano?</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">HR Compliance / Legal</p>
<p class="text-small text-gosign-text-light">Necesita implementar los requisitos del EU AI Act y necesita una checklist de compliance con medidas concretas.</p>
</div>
</div>

</div>
</section>

<section class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-12 border-t border-gosign-border">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Más eBooks</h2>
<div class="grid grid-cols-1 md:grid-cols-2 gap-6">

<div class="bg-white border border-gosign-border rounded-card p-5">
<p class="font-semibold text-gosign-dark mb-1">IA en Finanzas - Manual de Gobernanza</p>
<p class="text-small text-gosign-text-light mb-3">Para CFOs y dirección financiera</p>
<a href="/es/ebook/ia-finanzas-manual-gobernanza/" class="text-sm text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Descargar gratis</a>
</div>

<div class="bg-white border border-gosign-border rounded-card p-5">
<p class="font-semibold text-gosign-dark mb-1">Infraestructura de IA - Manual de Gobernanza</p>
<p class="text-small text-gosign-text-light mb-3">Para CTOs y dirección de TI</p>
<a href="/es/ebook/ia-infraestructura-manual-gobernanza/" class="text-sm text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Descargar gratis</a>
</div>

<a href="/es/ebook/hr-agent-readiness-assessment/" class="block border border-gosign-border rounded-card p-4 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-1">HR Assessment</p>
<p class="text-body font-semibold text-gosign-dark">HR Agent Readiness Assessment</p>
<p class="text-small text-gosign-text-light mt-1">15 preguntas para su equipo directivo</p>
</a>

</div>
</section>

--- eBooks Gratuitos - Manuales de Gobernanza de IA ---
> Manuales gratuitos de gobernanza para RRHH, Finanzas e Infraestructura. EU AI Act, Decision Layer, evaluaciones de preparación.

<section class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-12">
<div class="grid grid-cols-1 md:grid-cols-3 gap-8">

<div class="bg-white border border-gosign-border rounded-card p-6 flex flex-col">
<div class="w-12 h-12 rounded-full bg-orange-50 flex items-center justify-center mb-4">
<svg class="w-6 h-6 text-gosign-accent" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M17 20h5v-2a3 3 0 00-5.356-1.857M17 20H7m10 0v-2c0-.656-.126-1.283-.356-1.857M7 20H2v-2a3 3 0 015.356-1.857M7 20v-2c0-.656.126-1.283.356-1.857m0 0a5.002 5.002 0 019.288 0M15 7a3 3 0 11-6 0 3 3 0 016 0z"></path></svg>
</div>
<h2 class="text-h3 font-bold text-gosign-dark mb-2">IA en RRHH</h2>
<p class="text-body text-gosign-text mb-3 flex-1">Checklist del EU AI Act, Decision Framework, perspectiva del comité de empresa y evaluación de preparación - el manual de gobernanza para el CHRO.</p>
<p class="text-small text-gosign-text-light mb-4">Para CHROs y líderes de RRHH - 25 páginas</p>
<a href="/es/ebook/ia-rrhh-manual-gobernanza/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Descargar gratis</a>
</div>

<div class="bg-white border border-gosign-border rounded-card p-6 flex flex-col">
<div class="w-12 h-12 rounded-full bg-orange-50 flex items-center justify-center mb-4">
<svg class="w-6 h-6 text-gosign-accent" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 7h6m0 10v-3m-3 3h.01M9 17h.01M9 14h.01M12 14h.01M15 11h.01M12 11h.01M9 11h.01M7 21h10a2 2 0 002-2V5a2 2 0 00-2-2H7a2 2 0 00-2 2v14a2 2 0 002 2z"></path></svg>
</div>
<h2 class="text-h3 font-bold text-gosign-dark mb-2">IA en Finanzas</h2>
<p class="text-body text-gosign-text mb-3 flex-1">Compliance, auditores externos y Decision Layer - el manual de gobernanza para el CFO. Con H/R/A-Framework y evaluación de preparación para el sector financiero.</p>
<p class="text-small text-gosign-text-light mb-4">Para CFOs y dirección financiera - 28 páginas</p>
<a href="/es/ebook/ia-finanzas-manual-gobernanza/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Descargar gratis</a>
</div>

<div class="bg-white border border-gosign-border rounded-card p-6 flex flex-col">
<div class="w-12 h-12 rounded-full bg-orange-50 flex items-center justify-center mb-4">
<svg class="w-6 h-6 text-gosign-accent" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M5 12h14M5 12a2 2 0 01-2-2V6a2 2 0 012-2h14a2 2 0 012 2v4a2 2 0 01-2 2M5 12a2 2 0 00-2 2v4a2 2 0 002 2h14a2 2 0 002-2v-4a2 2 0 00-2-2m-2-4h.01M17 16h.01"></path></svg>
</div>
<h2 class="text-h3 font-bold text-gosign-dark mb-2">Infraestructura de IA</h2>
<p class="text-body text-gosign-text mb-3 flex-1">Build, Buy, Hybrid - infraestructura conforme al EU AI Act. Con B/B/H-Framework, 7-Layer Reference Architecture y checklist del CTO.</p>
<p class="text-small text-gosign-text-light mb-4">Para CTOs y dirección de TI - 28 páginas</p>
<a href="/es/ebook/ia-infraestructura-manual-gobernanza/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Descargar gratis</a>
</div>

</div>

<h2 class="text-h2 font-bold text-gosign-dark mt-12 mb-6">Readiness Assessments</h2>
<p class="text-body text-gosign-text-light mb-8">¿Qué tan preparada está su organización para AI Agents? 15 preguntas, hojas de trabajo para completar, evaluación de equipo con análisis de brechas.</p>

<div class="grid grid-cols-1 md:grid-cols-2 gap-8">

<div class="bg-white border-2 border-gosign-accent/20 rounded-card p-6 flex flex-col">
<div class="w-12 h-12 rounded-full bg-orange-50 flex items-center justify-center mb-4">
<svg class="w-6 h-6 text-gosign-accent" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 5H7a2 2 0 00-2 2v12a2 2 0 002 2h10a2 2 0 002-2V7a2 2 0 00-2-2h-2M9 5a2 2 0 002 2h2a2 2 0 002-2M9 5a2 2 0 012-2h2a2 2 0 012 2m-6 9l2 2 4-4"></path></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">HR Agent Readiness</h3>
<p class="text-body text-gosign-text mb-3 flex-1">15 preguntas para su equipo directivo. Madurez de procesos, gobernanza, panorama de datos, representación de los trabajadores, infraestructura TI.</p>
<p class="text-small text-gosign-text-light mb-4">Para CHROs y equipo directivo de RRHH - 14 páginas</p>
<a href="/es/ebook/hr-agent-readiness-assessment/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Descargar assessment</a>
</div>

<div class="bg-white border-2 border-gosign-accent/20 rounded-card p-6 flex flex-col">
<div class="w-12 h-12 rounded-full bg-orange-50 flex items-center justify-center mb-4">
<svg class="w-6 h-6 text-gosign-accent" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 5H7a2 2 0 00-2 2v12a2 2 0 002 2h10a2 2 0 002-2V7a2 2 0 00-2-2h-2M9 5a2 2 0 002 2h2a2 2 0 002-2M9 5a2 2 0 012-2h2a2 2 0 012 2m-6 9l2 2 4-4"></path></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Finance Agent Readiness</h3>
<p class="text-body text-gosign-text mb-3 flex-1">15 preguntas para CFO y auditores externos. Verificación de compliance, panorama ERP, velocidad de cierre, madurez en detección de fraude.</p>
<p class="text-small text-gosign-text-light mb-4">Para CFOs y equipo directivo de finanzas - 14 páginas</p>
<a href="/es/ebook/finance-agent-readiness-assessment/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Descargar assessment</a>
</div>

</div>

<h2 class="text-h2 font-bold text-gosign-dark mt-12 mb-6">Test rápido online</h2>
<p class="text-body text-gosign-text-light mb-8">¿No tiene tiempo para la evaluación completa de 15 preguntas? El test rápido online dura 3 minutos - con gráfico radar automático y recomendaciones de agentes.</p>

<div class="grid grid-cols-1 md:grid-cols-2 gap-8">
<a href="/es/hr-agent-readiness/" class="block bg-gosign-dark rounded-card p-6 hover:bg-gosign-dark/90 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">3 minutos, 7 preguntas</p>
<p class="text-h3 font-bold text-white">HR Agent Readiness</p>
<p class="text-body text-white/70 mt-2">Nivel de madurez, gráfico radar y recomendaciones del catálogo de 48 agentes.</p>
</a>
<a href="/es/finance-agent-readiness/" class="block bg-gosign-dark rounded-card p-6 hover:bg-gosign-dark/90 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">3 minutos, 7 preguntas</p>
<p class="text-h3 font-bold text-white">Finance Agent Readiness</p>
<p class="text-body text-white/70 mt-2">Nivel de madurez, gráfico radar y recomendaciones del catálogo de 49 agentes.</p>
</a>
</div>

</section>

--- AI Agents para Finance & Auditoría ---
> Enterprise AI Agents para procesos financieros: documentos, amortización, correcciones, evaluaciones fiscales. prüfungsfähig by Design, auditable

<div class="not-prose my-8 bg-gosign-dark rounded-card p-6 sm:p-8">
<div class="flex flex-col sm:flex-row sm:items-center gap-4">
<div class="flex-1">
<p class="text-h3 font-bold text-white mb-2">eBook gratuito: IA en Finanzas</p>
<p class="text-body text-white/80">Compliance, auditores externos y Decision Layer - el manual de gobernanza para dirección financiera.</p>
</div>
<a href="/es/ebook/ia-finanzas-manual-gobernanza/" class="inline-flex items-center gap-2 px-6 py-3 bg-gosign-accent-btn text-white font-semibold rounded-lg hover:bg-gosign-accent-btn-hover transition-colors whitespace-nowrap">Descargar ahora</a>
</div>
</div>

<!-- Problem -->
<section class="py-section bg-gosign-white"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow"><h2 class="text-h1 font-bold text-gosign-dark">El problema: lógica contable en cabezas, no en sistemas</h2><p class="text-body-lg text-gosign-text-light mt-4">Las decisiones financieras en las empresas dependen del conocimiento de contables individuales. Clasificaciones de amortización, gastos de representación, correcciones contables, evaluaciones fiscales - el conjunto de reglas es complejo y la aplicación varía según persona, ubicación e interpretación.</p><p class="text-body-lg text-gosign-text-light mt-4">Las consecuencias impactan directamente el balance: correcciones que podrían haberse evitado. Clasificaciones de amortización cuestionadas solo por el auditor externo. Gastos tratados de forma diferente en cada oficina.</p><p class="text-body-lg text-gosign-text-light mt-4">Para auditores, revisión interna y centros de servicios compartidos, esto es un riesgo sistemático.</p><p class="text-body-lg text-gosign-text-light mt-4">Esta inconsistencia no solo aumenta las correcciones contables - también incrementa el esfuerzo de auditoría, los ciclos de conciliación y el riesgo de hallazgos por revisión interna o auditores externos. El Decision Layer traslada estos riesgos de la interpretación individual a una arquitectura de decisiones versionada y trazable. Donde la decisión es determinista, el agente aplica el conjunto de reglas de forma consistente. Y donde el agente es lo suficientemente confiable: decide de forma autónoma - interpreta, clasifica, evalúa contexto. Esto no es if-then-else - es capacidad de juicio dentro de límites definidos.</p></div></div></section>

<!-- Definición -->
<section class="py-section bg-gosign-light"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow"><h2 class="text-h1 font-bold text-gosign-dark">¿Qué es un Finance Agent?</h2><p class="text-body-lg text-gosign-text-light mt-4">Un Finance Agent es un AI Agent especializado en procesamiento de documentos y contabilidad. Lee documentos con comprensión contextual del lenguaje, los evalúa contra conjuntos de reglas versionados (legislación fiscal, normas contables, políticas internas) y produce propuestas de contabilización documentadas. El <a href="/es/decision-layer/" class="text-gosign-accent-text hover:text-gosign-accent-hover">Decision Layer</a> enruta cada microdecisión: de forma autónoma con alta confianza y regla clara, al especialista en casos excepcionales.</p><p class="text-body-lg text-gosign-text-light mt-4">SAP y Sage siguen siendo sus sistemas principales. El Finance Agent se sitúa delante - entrega resultados listos para decisión con una cadena de justificación completa. Cada decisión produce un registro de decisión completo: input, regla aplicada, versión de la regla, confianza, camino de decisión, resultado. Esto no es documentación retroactiva - es la prueba técnica de cómo se tomó cada decisión.</p></div></div></section>

<!-- Use Cases -->
<section class="py-section bg-gosign-light"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><h2 class="text-h1 font-bold text-gosign-dark mb-8">Escenarios de uso concretos</h2><div class="grid grid-cols-1 md:grid-cols-2 gap-6"><div class="border border-gosign-border rounded-card p-6 bg-gosign-white"><h3 class="text-h3 font-bold text-gosign-dark">Procesamiento y clasificación de documentos</h3><p class="text-body text-gosign-text-light mt-2">El Document Agent lee, comprende y evalúa documentos con comprensión real del lenguaje. Facturas, notas de crédito, anulaciones, gastos de representación. El Decision Layer verifica completitud, plausibilidad y clasificación fiscal. Con alta confianza: propuesta de contabilización automática. En casos límite: escalación al especialista.</p></div><div class="border border-gosign-border rounded-card p-6 bg-gosign-white"><h3 class="text-h3 font-bold text-gosign-dark">Lógica de amortización</h3><p class="text-body text-gosign-text-light mt-2">La lógica de amortización varía según tipo de activo, clasificación fiscal y región. El Decision Layer hace la lógica explícita: clasificación del tipo de activo, verificación de clasificación fiscal, aplicación de tabla de amortización según versión vigente, documentación de la justificación.</p></div><div class="border border-gosign-border rounded-card p-6 bg-gosign-white"><h3 class="text-h3 font-bold text-gosign-dark">Gastos de representación</h3><p class="text-body text-gosign-text-light mt-2">La interpretación variable de la deducibilidad es uno de los puntos de auditoría más comunes. El Decision Layer estandariza: verificación de completitud, verificación de lista de asistentes, comprobación de propósito y relevancia empresarial, aplicación de reglas de deducibilidad.</p></div><div class="border border-gosign-border rounded-card p-6 bg-gosign-white"><h3 class="text-h3 font-bold text-gosign-dark">Correcciones y aseguramiento de calidad</h3><p class="text-body text-gosign-text-light mt-2">Eliminar correcciones antes de que se produzcan. El Workflow Agent orquesta el proceso de aseguramiento de calidad: verificación automática de plausibilidad antes de contabilización, comparación con valores de referencia, escalación ante anomalías.</p></div></div></div></section>

<!-- Cuatro pasos -->
<section class="py-section bg-gosign-white"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow"><h2 class="text-h1 font-bold text-gosign-dark">Cuatro pasos: del documento a la contabilización lista para auditoría</h2><p class="text-body-lg text-gosign-text-light mt-4"><strong>1. Leer y comprender</strong> - El agent lee el documento con comprensión contextual del lenguaje. Proveedor, importe, descripción del servicio, características fiscalmente relevantes. No es coincidencia de plantillas rígida - es comprensión real del documento.</p><p class="text-body-lg text-gosign-text-light mt-4"><strong>2. Evaluar</strong> - Cuenta, centro de coste, clasificación fiscal, inicio de amortización, criterios de gastos de representación. Cada evaluación se basa en un conjunto de reglas versionado - no en la experiencia de contables individuales.</p><p class="text-body-lg text-gosign-text-light mt-4"><strong>3. Decidir</strong> - El Decision Layer enruta: autónomo con alta confianza y regla clara, al especialista en casos excepcionales o baja confianza. Usted define los umbrales - no la IA.</p><p class="text-body-lg text-gosign-text-light mt-4"><strong>4. Documentar</strong> - Cada microdecisión produce un registro de decisión: input, regla aplicada, versión de la regla, confianza, camino de decisión, resultado, marca de tiempo. Esto no es documentación retroactiva - es la prueba técnica de cómo se tomó cada decisión.</p></div></div></section>

<!-- Flujo de decisión -->
<section class="py-section bg-gosign-light"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><h2 class="text-h1 font-bold text-gosign-dark mb-6">Flujo de decisión</h2><div class="mt-8 bg-gosign-dark rounded-card p-6 sm:p-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-4">Documento → Agent extrae → Decision Layer descompone en pasos</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-4">
<div class="bg-white/5 rounded-card p-4">
<p class="text-xs font-bold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Reglamento</p>
<p class="text-small text-white/90 font-semibold">Casos claros</p>
<p class="text-small text-white/60 mt-2">Tasa según normativa. Cálculo determinista.</p>
</div>
<div class="bg-white/5 rounded-card p-4">
<p class="text-xs font-bold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Agent IA</p>
<p class="text-small text-white/90 font-semibold">Decisión por confianza</p>
<p class="text-small text-white/60 mt-2">Propuesta de cuenta con score. Autónomo por encima del umbral.</p>
</div>
<div class="bg-white/5 rounded-card p-4">
<p class="text-xs font-bold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Humano</p>
<p class="text-small text-white/90 font-semibold">Excepción</p>
<p class="text-small text-white/60 mt-2">Especialista revisa y decide con contexto.</p>
</div>
</div>
<p class="text-xs text-white/60 mt-4 text-center">Audit Trail por paso: Regla · Versión · Decisor</p>
</div></div></section>

<!-- Decision Layer detalle -->
<section class="py-section bg-gosign-white"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow"><h2 class="text-h1 font-bold text-gosign-dark"><a href="/es/decision-layer/" class="hover:text-gosign-accent transition-colors">Decision Layer</a>: cómo las decisiones financieras se vuelven auditables</h2><p class="text-body-lg text-gosign-text-light mt-4">El <a href="/es/decision-layer/" class="text-gosign-accent-text hover:underline">Decision Layer</a> descompone el proceso contable en pasos de decisión individuales. Para cada paso define: ¿decide el agent, un conjunto de reglas, o un humano?</p><p class="text-body-lg text-gosign-text-light mt-4">El agent lee, comprende y evalúa documentos con comprensión real del lenguaje. El Decision Layer enruta cada evaluación:</p><div class="mt-6 bg-gosign-light border border-gosign-border rounded-card p-6"><p class="text-body font-mono text-gosign-dark">Documento &rarr; Extracción &rarr; Clasificación &rarr; Evaluación de dominio &rarr; Confidence Score &rarr; Propuesta de contabilización o escalación humana</p></div><p class="text-body-lg text-gosign-text-light mt-4">Cada decisión produce un registro completo e inmutable: input, modelo, evaluación, confidence score, regla aplicada con versión, camino de decisión, resultado. Esto no es documentación retroactiva - es la prueba técnica de cómo se tomó cada decisión.</p><p class="text-body text-gosign-text-light mt-4">Cómo son los modelos de costes para Enterprise AI y cuánto cuesta realmente self-hosting vs. nube se detalla en la <a href="/es/revista/costes-ia-tco-comparacion/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">comparación TCO en el Blueprint 2026</a>.</p></div></div></section>

<!-- Cert-Ready -->
<section class="py-section bg-gosign-light"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow"><h2 class="text-h1 font-bold text-gosign-dark">Cert-Ready by Design</h2><p class="text-body-lg text-gosign-text-light mt-4 italic">No 'tenemos ISO'. No 'no necesitamos ISO'. Sino: cada agent está técnicamente construido para ser certificable y auditable en cualquier momento.</p><p class="text-body-lg text-gosign-text-light mt-4">Los controles son objetos de datos de primera clase en el sistema - no documentos en una carpeta. Cada control tiene una implementación técnica, un generador automático de evidencia y un historial de evidencia con drill-down hasta la implementación concreta.</p><p class="text-body-lg text-gosign-text-light mt-4">Los controles viven en la base de datos, no en Confluence. La evidencia se genera automáticamente. Los auditores ven el estado en vivo en el Portal de Auditor.</p><h3 class="text-h3 font-bold text-gosign-dark mt-8">Control Object Structure</h3><div class="mt-4 overflow-x-auto"><table class="w-full text-body text-gosign-text-light border-collapse"><thead><tr class="border-b-2 border-gosign-border"><th class="text-left py-2 pr-4 font-bold text-gosign-dark">Elemento</th><th class="text-left py-2 font-bold text-gosign-dark">Función</th></tr></thead><tbody><tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-mono text-small">Control_ID</td><td class="py-2">Identificación única del control</td></tr><tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-mono text-small">Technical_Implementation</td><td class="py-2">Implementación técnica concreta (p. ej. política RLS, check API)</td></tr><tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-mono text-small">Rule_Version</td><td class="py-2">Versión de la lógica de decisión subyacente</td></tr><tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-mono text-small">Evidence_Generator</td><td class="py-2">Mecanismo de verificación automático</td></tr><tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-mono text-small">Evidence_History</td><td class="py-2">Historial de resultados de verificación con marca de tiempo</td></tr><tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-mono text-small">Auditor_View</td><td class="py-2">Vista con drill-down hasta el nivel de implementación</td></tr></tbody></table></div><p class="text-body-lg text-gosign-text-light mt-4">Los controles son objetos de datos de primera clase. La evidencia se genera automáticamente. El auditor ve estado en vivo, no snapshots.</p></div></div></section>

<!-- Integración -->
<section class="py-section bg-gosign-white"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow"><h2 class="text-h1 font-bold text-gosign-dark">Integración en su entorno de sistemas existente</h2><p class="text-body-lg text-gosign-text-light mt-4">Los AI Agents no reemplazan sistemas. SAP FI/CO sigue siendo su ERP, Sage y A3 siguen siendo sus sistemas contables. La lógica del agent está desacoplada del sistema destino - la lógica contable está separada de la exportación.</p><div class="mt-6 flex flex-wrap gap-3"><span class="bg-gosign-light border border-gosign-border rounded-card px-4 py-2 text-body font-medium text-gosign-dark">SAP FI/CO</span><span class="bg-gosign-light border border-gosign-border rounded-card px-4 py-2 text-body font-medium text-gosign-dark">Sage</span><span class="bg-gosign-light border border-gosign-border rounded-card px-4 py-2 text-body font-medium text-gosign-dark">A3 / Meta4</span><span class="bg-gosign-light border border-gosign-border rounded-card px-4 py-2 text-body font-medium text-gosign-dark">SAP S/4HANA</span><span class="bg-gosign-light border border-gosign-border rounded-card px-4 py-2 text-body font-medium text-gosign-dark">SharePoint</span><span class="bg-gosign-light border border-gosign-border rounded-card px-4 py-2 text-body font-medium text-gosign-dark">Microsoft Teams</span><span class="bg-gosign-light border border-gosign-border rounded-card px-4 py-2 text-body font-medium text-gosign-dark">REST/SOAP</span></div></div></div></section>

<div class="not-prose my-6 p-4 border-l-4 border-gosign-accent bg-gosign-light">
<p class="text-body font-semibold text-gosign-dark">Secreto profesional (§203 StGB (disposición alemana del código penal sobre secreto profesional) (disposición alemana del código penal sobre secreto profesional))</p>
<p class="text-body text-gosign-text mt-1">Todos los datos de clientes permanecen bajo el control del titular del secreto profesional. Arquitectura conforme con §203, sin dependencia SaaS. Infraestructura exclusivamente en la UE como prueba técnica.</p>
</div>

<!-- Grupos objetivo -->
<section class="py-section bg-gosign-light"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><h2 class="text-h1 font-bold text-gosign-dark mb-8">Grupos objetivo</h2><div class="grid grid-cols-1 md:grid-cols-3 gap-6"><div class="border border-gosign-border rounded-card p-6 bg-gosign-white"><h3 class="text-h3 font-bold text-gosign-dark">Firmas de auditoría y asesorías fiscales</h3><p class="text-body text-gosign-text-light mt-2">Cientos de clientes, miles de documentos al mes. El Finance Agent aporta consistencia al procesamiento en todos los mandatos.</p></div><div class="border border-gosign-border rounded-card p-6 bg-gosign-white"><h3 class="text-h3 font-bold text-gosign-dark">Centros de servicios compartidos</h3><p class="text-body text-gosign-text-light mt-2">Múltiples entidades, distintos países, distintos conjuntos de reglas. El Finance Agent aplica reglas específicas por mandato de forma consistente.</p></div><div class="border border-gosign-border rounded-card p-6 bg-gosign-white"><h3 class="text-h3 font-bold text-gosign-dark">Empresas con contabilidad propia</h3><p class="text-body text-gosign-text-light mt-2">Cierres mensuales, informes trimestrales, inspecciones fiscales. Menos correcciones contables, clasificación consistente, documentación completa.</p></div></div></div></section>

<!-- Process -->
<section class="py-section bg-gosign-dark text-white"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><h2 class="text-h1 font-bold">Del primer agent a la plataforma Finance</h2><div class="grid md:grid-cols-3 gap-8 mt-8"><div><p class="text-xs font-bold uppercase tracking-wider text-gosign-accent-on-dark">Discover - 1 semana</p><p class="text-body-lg text-gosign-text-on-dark/80 mt-2">Análisis de procesos con su equipo financiero. Mapeo de lógica contable, documentación de conjuntos de reglas. Priorización de casos de uso.</p></div><div><p class="text-xs font-bold uppercase tracking-wider text-gosign-accent-on-dark">Build - 3-4 semanas</p><p class="text-body-lg text-gosign-text-on-dark/80 mt-2">PoC en producción. Un agent, un proceso financiero, en vivo en su infraestructura. Decision Layer, governance, pista de auditoría - desde el primer día.</p></div><div><p class="text-xs font-bold uppercase tracking-wider text-gosign-accent-on-dark">Scale - Continuo</p><p class="text-body-lg text-gosign-text-on-dark/80 mt-2">Más agents para más procesos financieros. Correcciones, gastos, evaluaciones fiscales, intercompany.</p></div></div><p class="text-body text-gosign-text-on-dark/60 mt-6 italic">Tras 12-18 meses, usted opera sus Finance Agents de forma independiente.</p></div></section>

<!-- Business Impact -->
<section class="py-section bg-gosign-light"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow"><h2 class="text-h1 font-bold text-gosign-dark">Business Impact</h2><p class="text-body-lg font-semibold text-gosign-dark mt-4">Impacto medible en procesos financieros.</p><ul class="mt-4 space-y-3 text-body-lg text-gosign-text-light list-none"><li>Correcciones contables eliminadas preventivamente</li><li>Lógica de decisión auditable para auditoría externa y revisión interna</li><li>Lógica contable consistente en todas las ubicaciones y entidades</li><li>Riesgo fiscal y de compliance reducido</li><li>Escalabilidad sin pérdida de conocimiento por rotación</li><li>Cert-Ready by Design - estructuralmente listo para auditoría</li><li>Reducción del esfuerzo de auditoría mediante actas de decisión completas por documento</li><li>Menos ciclos de conciliación interna mediante aplicación consistente de reglas</li><li>Cierres mensuales más rápidos mediante procesamiento autónomo de rutina</li></ul></div></div></section>

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Finance Agent Readiness Assessment</p>
<p class="text-body text-gosign-text mb-4">7 preguntas, 3 minutos: ¿Cómo de preparada está su organización financiera para AI Agents?</p>
<a href="/es/finance-agent-readiness/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Iniciar assessment &rarr;</a>
</div>

<!-- Finance Agent Assessment -->
<section class="py-section bg-gosign-dark text-white"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow">
<h2 class="text-h1 font-bold">Finance Agent Assessment: 49 agentes evaluados y priorizados</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4">¿Qué agentes financieros existen, qué governance necesitan y por dónde empezar? El assessment evalúa 49 agentes en 6 dimensiones - desde el nivel de autonomía hasta la relevancia para auditoría - para priorizar con criterio.</p>
<a href="/es/catalogo-agentes-finance/" class="inline-flex items-center gap-2 mt-4 text-body font-semibold text-gosign-accent-on-dark hover:underline">Ir al Finance Agent Assessment &rarr;</a>
</div></div></section>

<!-- Profundización -->
<section class="py-section bg-gosign-white"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><h2 class="text-h2 font-bold text-gosign-dark mb-2">Profundización en el Agent Briefing</h2><p class="text-body text-gosign-text-light mb-6">Nuestra serie de artículos para decisores que automatizan procesos financieros con AI Agents.</p><div class="grid grid-cols-1 sm:grid-cols-3 gap-6"><a href="/es/revista/costes-ia-tco-comparacion/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors"><p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Finance</p><p class="text-body font-semibold text-gosign-dark">Costes de IA comparados: Análisis TCO para Enterprise</p></a><a href="/es/revista/decision-layer-shadow-ai/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors"><p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p><p class="text-body font-semibold text-gosign-dark">Decision Layer vs. Shadow AI: Por qué la Governance va antes que la velocidad</p></a><a href="/es/revista/deepseek-enterprise-hosting/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors"><p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p><p class="text-body font-semibold text-gosign-dark">Hosting AI: EU SaaS, centro de datos alemán o Self-Hosted?</p></a></div></div></section>

--- Glosario - Términos Enterprise AI ---
> Términos técnicos del mundo Enterprise AI. De Agent a Zero-Trust - claramente definidos, consistentemente utilizados.

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 prose prose-lg">

## Tipos de Agents

### Document Agent

Un AI Agent especializado que lee, comprende y procesa documentos. Sin reconocimiento de plantillas, sin OCR rígido - comprensión lingüística contextual. Los Document Agents procesan facturas, bajas por enfermedad, contratos, certificados. Cada decisión se documenta vía el Decision Layer.

> [Document Agents en detalle](/es/servicios/ai-agents/document-agents/)

### Workflow Agent

Un AI Agent que orquesta procesos de negocio entre sistemas. Desde la recepción de correo hasta la aprobación y contabilización. Cada paso se protocola. Ante consultas o información faltante, el workflow se pausa - no se interrumpe.

> [Workflow Agents en detalle](/es/servicios/ai-agents/workflow-agents/)

### Knowledge Agent

Un AI Agent que entrega respuestas contextuales del conocimiento corporativo. Acuerdos de empresa, políticas, convenios colectivos. Cada respuesta incluye fuente y versión de regla. Sin fuente no hay respuesta.

> [Knowledge Agents en detalle](/es/servicios/ai-agents/knowledge-agents/)

---

## Conceptos de Governance

### Decision Layer

El Decision Layer descompone cada proceso empresarial en pasos de decisión individuales y define de antemano para cada uno: ¿Decide una persona, un conjunto de reglas o la IA de forma autónoma? Donde interviene la discrecionalidad o el riesgo de discriminación, la arquitectura impone la revisión humana. Donde la decisión es determinista, el agente aplica el conjunto de reglas de forma consistente. Y donde el agente es lo suficientemente confiable y tiene permiso: decide de forma autónoma - interpreta documentos, clasifica situaciones, evalúa contexto. Esto no es if-then-else - es capacidad de juicio dentro de límites definidos.

> [Decision Layer en detalle](/es/decision-layer/)

### Human-in-the-Loop

Principio arquitectónico que asegura que los humanos mantienen control sobre decisiones críticas. No un botón de emergencia, sino un elemento estructural del Decision Layer.

### Governance by Design

Compliance, auditabilidad y supervisión humana integradas en la arquitectura desde el día uno. No un proyecto posterior, sino un principio de diseño.

### Cert-Ready by Design

Controles como objetos de datos técnicos con generación automática de evidencias. La arquitectura está diseñada para que certificaciones (ISO 27001, SOC 2, EU AI Act) puedan realizarse sin proyecto adicional.

### Audit Trail

Protocolo completo de todas las decisiones del agent. Cada decisión, cada regla, cada escalación documentada, versionada y exportable.

---

## Infraestructura

### RAG (Retrieval-Augmented Generation)

Método que combina recuperación de información con generación de texto. El agent busca en la base de conocimiento y genera una respuesta basada en los documentos encontrados - con referencia de fuente.

### Shadow IT

Herramientas de IA no autorizadas utilizadas por empleados sin conocimiento de IT. Riesgo: sin governance, sin auditabilidad, posibles violaciones de RGPD. Gosign reemplaza Shadow IT con infraestructura de agents controlada.

</div>
</section>

--- Cert-Ready by Design ---
> Controles como objetos de datos de primera clase. Generación automática de evidencias. Portal de Auditor en vivo. Estructuralmente preparado para auditoría.

<!-- El Principio -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">El Principio</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
En los enfoques tradicionales de cumplimiento, los controles se describen en documentos, las evidencias se recopilan manualmente y las auditorías se realizan como proyectos periódicos. Un auditor pide una prueba, un empleado busca una captura de pantalla, alguien crea una hoja de cálculo.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Cert-Ready by Design invierte esto: los controles son objetos de datos técnicos en el sistema. Las evidencias se generan automáticamente. El auditor ve el estado en vivo - no una instantánea de la semana pasada.
</p>
</div>
</section>

<!-- Tres Diferenciadores -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">Tres Diferenciadores</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Los Controles Viven en el Sistema</h3>
<p class="text-body text-gosign-text-light mt-2">No en Confluence. No en un documento Word. No en una herramienta GRC que se actualiza una vez al año. Los controles son objetos de datos en la base de datos - en vivo, versionados, testeables.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Las Evidencias Se Generan Automáticamente</h3>
<p class="text-body text-gosign-text-light mt-2">Ninguna persona recopila evidencias. El generador de evidencias se ejecuta automáticamente. Si un control no puede generar su evidencia, eso mismo es un hallazgo.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Drill-Down Completo</h3>
<p class="text-body text-gosign-text-light mt-2">Desde el semáforo en el dashboard hasta la política RLS concreta con su nombre y el SQL de prueba que verifica su efectividad. Sin 'pregunte al desarrollador'. Todo en una ruta.</p>
</div>
</div>
</div>
</section>

<!-- Controles como Objetos de Datos -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Controles como Objetos de Datos de Primera Clase</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Cada control en la arquitectura de Gosign es un objeto de datos con cuatro propiedades:
</p>

<div class="mt-8 space-y-6">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">1. Implementación Técnica</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
El control no solo está documentado - está implementado. Una política RLS que impone aislamiento de inquilinos a nivel de base de datos. Un chequeo de API que valida la versión de la regla antes de cada decisión del agente. Un trigger que escribe automáticamente una entrada de auditoría ante cambios de configuración.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">2. Generador Automático de Evidencias</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Cada control tiene un generador de evidencias asignado. Se ejecuta periódicamente o por eventos y produce evidencias automáticamente. Ninguna persona recopila capturas de pantalla. El sistema genera sus propias evidencias.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
La unidad de evidencia más pequeña es el <a href="/es/revista/acta-de-decision-decisiones-ia-impugnables/" class="text-gosign-accent-text hover:underline">acta de decisión</a> por microdecisión: una prueba inmutable con input, regla de negocio aplicada con su versión, confianza, versión del modelo, resultado, marca de tiempo y vía de impugnación - la base sobre la que se asientan los controles.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">3. Historial de Evidencias</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Cada registro de evidencia se almacena con: marca temporal, estado (aprobado, fallido, advertencia), versión del control, versión de la lógica de prueba y datos brutos para drill-down. El historial es inmutable.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">4. Vista de Auditor con Drill-Down</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
El auditor ve en el Portal de Auditor: estado semáforo por control, última marca temporal de evidencia, tendencia en el tiempo y drill-down desde el indicador de estado hasta la política RLS concreta, el SQL de prueba y el resultado.
</p>
</div>
</div>
</div>
</div>
</section>

<!-- Estructura del Control Object -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Cert-Ready Control Object - Estructura</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Cada control es un objeto de datos estructurado con mapeo de frameworks, implementación técnica, generador automático de evidencias y vista de auditor.
</p>
</div>
<div class="mt-8">
<pre class="bg-gosign-dark text-white p-6 rounded-card overflow-x-auto text-small font-mono leading-relaxed"><code>Control Object {
id:                 "ctrl-rbac-001"
name:               "Tenant isolation at database level"
category:           "Access Control"

implementation: {
type:             "RLS Policy"
reference:        "policies/tenant_isolation.sql"
deployed:         true
last_verified:    "2026-02-20T09:14:00Z"
}

evidence_generator: {
type:             "automated_test"
schedule:         "every_6h"
test_reference:   "tests/tenant_isolation_test.sql"
}

evidence_history: [
{
timestamp:      "2026-02-20T09:14:00Z"
status:         "passed"
control_version: "1.3"
test_version:   "2.1"
raw_data:       { ... }
},
...
]

framework_mapping: {
iso_27001:        "A.9.4.1"
soc2:             "CC6.1"
eu_ai_act:        "Art. 12"
}

owner:              "security-team"
last_change:        "2026-02-18T14:22:00Z"
change_reason:      "Policy update for new entity"
}</code></pre>
</div>
</div>
</section>

<!-- Portal de Auditor -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Portal de Auditor</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Los auditores externos obtienen acceso directo a todos los datos de gobernanza. Sin presentaciones preparadas, sin exportaciones filtradas. El auditor ve el estado real y actual del sistema.
</p>
</div>
<div class="mt-8 grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-3 gap-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Dashboard</h3>
<p class="text-body text-gosign-text-light mt-2">Visión general de todos los controles con estado semáforo, agrupados por categoría de framework.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Detalle del Control</h3>
<p class="text-body text-gosign-text-light mt-2">Descripción, implementación técnica, historial de evidencias, último cambio, propietario asignado.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Drill-Down</h3>
<p class="text-body text-gosign-text-light mt-2">Desde la visión general hasta el resultado concreto de la prueba, incluyendo la lógica de prueba y datos brutos.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Exportación</h3>
<p class="text-body text-gosign-text-light mt-2">Paquetes de evidencia para auditores externos, legibles por máquinas (JSON) o como informe PDF.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Historial de Cambios</h3>
<p class="text-body text-gosign-text-light mt-2">Cuando se cambió un control, por quién, por qué.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Historial de Overrides</h3>
<p class="text-body text-gosign-text-light mt-2">Cuando un override humano anuló una decisión del agente - documentado con razón, persona y marca temporal.</p>
</div>
</div>
</div>
</section>

<!-- Framework-Mapping -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Mapeo de Frameworks</h2>
<p class="text-body-lg font-semibold text-gosign-dark mt-4">Estructuralmente preparado para cualquier framework.</p>
<ul class="mt-4 space-y-2 text-body-lg text-gosign-text-light">
<li>ISO 27001: Controles del Anexo A mapeados. Evidencia generada automáticamente.</li>
<li>SOC2: Criterios de Servicios de Confianza (CC6, CC7, CC8) como categorías de control.</li>
<li>PS 951 / ISAE 3402: Estándares de auditoría para proveedores de servicios TI. Controles y evidencia preparados para auditores.</li>
<li>EU AI Act: Obligaciones de transparencia, registro y supervisión implementadas como controles en el sistema.</li>
<li>IDW PS 880: Estándares de auditoría de software.</li>
<li>El mapeo cambia. La estructura de controles permanece idéntica. Cuando un nuevo framework se vuelve relevante, se mapea - los controles ya existen.</li>
</ul>
</div>
</div>
</section>

<!-- Lo Que No Es -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Lo Que Cert-Ready by Design No Es</h2>
<div class="mt-6 space-y-4">
<p class="text-body-lg text-gosign-text-light">
<strong class="text-gosign-dark">No es una promesa de certificación.</strong> Significa que la arquitectura está estructuralmente preparada para ser auditada y certificada en cualquier momento.
</p>
<p class="text-body-lg text-gosign-text-light">
<strong class="text-gosign-dark">No es una herramienta GRC.</strong> Complementa plataformas GRC existentes - mediante controles técnicos que viven en el sistema.
</p>
<p class="text-body-lg text-gosign-text-light">
<strong class="text-gosign-dark">No es una auditoría única.</strong> Es continuo. Las evidencias se generan continuamente, los controles se prueban continuamente. No hay "modo auditoría" - el sistema siempre está en modo auditoría.
</p>
</div>
</div>
</div>
</section>

<!-- Profundizacion -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Profundizacion en el Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nuestra serie de artículos para ejecutivos que implementan agentes de IA en la empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/es/revista/cert-ready-by-design/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Auditoría</p>
<p class="text-body font-semibold text-gosign-dark">Cert-Ready by Design: IA preparada para auditoría</p>
</a>
<a href="/es/revista/eu-ai-act-hr/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Regulación</p>
<p class="text-body font-semibold text-gosign-dark">EU AI Act y RRHH: lo que ahora es obligatorio</p>
</a>
<a href="/es/revista/ia-governance-dashboard/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Dashboard</p>
<p class="text-body font-semibold text-gosign-dark">IA Governance Dashboard: monitorización de agentes</p>
</a>
</div>
</div>
</section>

--- Checklist del contrato de encargado para infraestructura IA ---
> Catalogo de requisitos para contratos de encargado de tratamiento en IA empresarial. 25 preguntas de verificacion para legal, seguridad IT y comite de empresa.

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-body-lg text-gosign-text-light">
Un contrato de encargado de tratamiento para infraestructura de IA debe cubrir diez areas que los contratos SaaS estandar no regulan: politicas de registro de prompts, separacion de entornos (dev/staging/produccion), cadenas de proveedores de modelos, procesamiento de datos in-flight vs. at-rest, proteccion de datos de embeddings RAG, <a href="/es/governance/data-residency/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">acceso desde terceros paises a datos de produccion</a>, cumplimiento del secreto profesional, tokenizacion PII, trazabilidad de auditoria del Decision Layer y verificabilidad de medidas tecnicas. Esta checklist traduce las diez lagunas en 25 preguntas concretas de verificacion.
</p>
<p class="text-body text-gosign-text-light mt-4">
El analisis detallado de las diez lagunas esta disponible en el articulo: <a href="/es/revista/contrato-encargado-ia-checklist/" class="text-gosign-accent-text hover:underline">Contrato de encargado IA: Lo que falta en su contrato estandar</a>.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">A - Categorias de datos y finalidades de tratamiento</h2>
<div class="space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">1</p>
<p class="text-body-lg text-gosign-text-light mt-1">¿Los contenidos de prompts y respuestas del modelo estan listados como categorias de datos independientes en el contrato?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">2</p>
<p class="text-body-lg text-gosign-text-light mt-1">¿Se establece que la responsabilidad de clasificacion del contenido recae en la organizacion, no en el proveedor?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">3</p>
<p class="text-body-lg text-gosign-text-light mt-1">¿Los embeddings/vectores estan clasificados como datos potencialmente personales?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">4</p>
<p class="text-body-lg text-gosign-text-light mt-1">¿El contrato contempla las categorias especiales del articulo 9 del RGPD que pueden surgir por entradas de usuarios?</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">B - Registro y monitorizacion</h2>
<div class="space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">5</p>
<p class="text-body-lg text-gosign-text-light mt-1">¿El registro de cuerpos de solicitud/respuesta en el entorno de produccion esta desactivado?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">6</p>
<p class="text-body-lg text-gosign-text-light mt-1">¿Que metadatos se registran (codigos de estado, latencias, IDs de solicitud)?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">7</p>
<p class="text-body-lg text-gosign-text-light mt-1">¿El registro de depuracion en produccion esta verificablemente desactivado?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">8</p>
<p class="text-body-lg text-gosign-text-light mt-1">¿Los rastros de pila y mensajes de error estan configurados para excluir datos de contenido de los logs?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">9</p>
<p class="text-body-lg text-gosign-text-light mt-1">¿La verificacion de la configuracion de registro es parte del proceso de lanzamiento?</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">C - Separacion de entornos y acceso</h2>
<div class="space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">10</p>
<p class="text-body-lg text-gosign-text-light mt-1">¿Existen entornos separados (dev, staging, produccion) con politicas de datos distintas?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">11</p>
<p class="text-body-lg text-gosign-text-light mt-1">¿Los entornos dev/staging contienen exclusivamente datos sinteticos o anonimizados?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">12</p>
<p class="text-body-lg text-gosign-text-light mt-1">¿El acceso a produccion esta restringido a roles autorizados dentro de la UE/EEE? (Vease tambien: <a href="/es/governance/cert-ready/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">requisitos Cert-Ready</a>)</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">13</p>
<p class="text-body-lg text-gosign-text-light mt-1">¿Existe un procedimiento de excepcion documentado para casos de soporte con acceso a datos?</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">D - Proveedores de modelos y subencargados</h2>
<div class="space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">14</p>
<p class="text-body-lg text-gosign-text-light mt-1">¿La delimitacion es clara: Que proveedores son subencargados del proveedor y cuales operan en el tenant de la organizacion?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">15</p>
<p class="text-body-lg text-gosign-text-light mt-1">¿La retencion de contenido en los proveedores de modelos esta desactivada?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">16</p>
<p class="text-body-lg text-gosign-text-light mt-1">¿La exclusion del uso para entrenamiento esta documentada contractualmente?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">17</p>
<p class="text-body-lg text-gosign-text-light mt-1">¿Donde se ubican los endpoints de los modelos (region UE, US, otros)?</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">E - Almacenamiento y supresion de datos</h2>
<div class="space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">18</p>
<p class="text-body-lg text-gosign-text-light mt-1">¿Se establece donde se almacenan los datos de contenido persistentes (base de datos, region, proveedor)?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">19</p>
<p class="text-body-lg text-gosign-text-light mt-1">¿Que retencion de copias de seguridad aplica y como se gestionan los datos eliminados en las copias?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">20</p>
<p class="text-body-lg text-gosign-text-light mt-1">¿El usuario individual puede eliminar sus propios datos dentro de la aplicacion?</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">F - Sectores regulados</h2>
<div class="space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">21</p>
<p class="text-body-lg text-gosign-text-light mt-1">¿El contrato contiene disposiciones de cumplimiento con el secreto profesional segun normativa sectorial aplicable?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">22</p>
<p class="text-body-lg text-gosign-text-light mt-1">¿Existen compromisos de confidencialidad para todas las personas con acceso?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">23</p>
<p class="text-body-lg text-gosign-text-light mt-1">¿La tokenizacion PII esta disponible como modulo opcional?</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">G - <a href="/es/governance/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Gobernanza</a> y verificabilidad</h2>
<div class="space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">24</p>
<p class="text-body-lg text-gosign-text-light mt-1">¿Una trazabilidad de auditoria para decisiones de agentes esta anclada como componente contractual?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">25</p>
<p class="text-body-lg text-gosign-text-light mt-1">¿Las medidas tecnicas y organizativas pueden evidenciarse bajo solicitud (documentacion de configuracion, extractos de logs anonimizados)?</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-body text-gosign-text-light">
Esta checklist es un catalogo de requisitos desde la perspectiva de arquitectura y gobernanza. No constituye asesoramiento juridico. La revision legal y la evaluacion formal del contrato corresponden al departamento juridico del responsable o a asesores externos.
</p>
</div>
</section>

--- Información, Consulta y Comité de Empresa ---
> AI Agents compatibles con el comité de empresa. Human-in-the-Loop, acuerdos de empresa como restricciones del sistema, Audit Trail.

<!-- Por Qué es un Tema de Arquitectura -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Por Qué la Participación del Comité de Empresa Es un Tema de Arquitectura</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Los AI Agents desplegados en procesos de RRHH, decisiones de personal o flujos de trabajo que afectan a empleados están sujetos a derechos de información y consulta conforme al Art. 64 del Estatuto de los Trabajadores. No es una capa opcional de cumplimiento - es un requisito legal bajo el Estatuto de los Trabajadores y la Directiva europea 2002/14/CE sobre información y consulta de los trabajadores.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
La mayoría de despliegues de IA tratan la consulta con el comité de empresa como un problema organizativo: un taller, un acuerdo, un protocolo. Eso no es suficiente. Cuando el agente toma decisiones que afectan a empleados, el cumplimiento de los derechos de información y consulta debe ser impuesto técnicamente - no solo acordado.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Gosign trata el derecho de información y consulta del comité de empresa como un principio arquitectónico. El Decision Layer impone técnicamente el cumplimiento de los acuerdos de empresa. El Audit Trail documenta cada decisión. El comité de empresa puede rastrear qué hace el agente, por qué lo hace y cuándo interviene un humano.
</p>
</div>
</section>

<!-- Marco Legal -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Marco Legal</h2>
<div class="mt-6 space-y-6">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Art. 64 Estatuto de los Trabajadores - Información y consulta</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
El comité de empresa tiene derecho a ser informado y consultado sobre la "introducción de nuevos métodos de trabajo o modificaciones de los existentes", incluyendo sistemas técnicos que supervisan el comportamiento o rendimiento de los empleados. Los AI Agents que automatizan procesos de RRHH entran en este ámbito. El comité tiene derecho a emitir informe previo a la implantación.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Art. 64.5 Estatuto de los Trabajadores - Planificación tecnológica</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
El comité de empresa debe ser informado sobre la implantación y revisión de sistemas de organización y control del trabajo, incluidos los sistemas de inteligencia artificial. Esto aplica a la fase de planificación de los AI Agents, no solo al lanzamiento. La Directiva 2002/14/CE refuerza estos derechos de información y consulta a nivel europeo.
</p>
</div>
</div>
</div>
</section>

<!-- Implementación Arquitectónica -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Implementación Arquitectónica</h2>
</div>
<div class="mt-8">
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Acuerdos de Empresa como Restricciones del Sistema</h3>
<p class="text-body text-gosign-text-light mt-2">Cada acuerdo de empresa se traduce en un conjunto de reglas en el Decision Layer. Cada restricción tiene un ID de versión, fecha de validez y ámbito. El agente verifica automáticamente cada decisión contra las restricciones almacenadas.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Human-in-the-Loop como Principio Arquitectónico</h3>
<p class="text-body text-gosign-text-light mt-2">Decisión autónoma cuando: alta confianza, bajo riesgo, ninguna restricción afectada. Human-in-the-Loop cuando: riesgo de sesgo, temas que requieren consulta con el comité, baja confianza. El enrutamiento es impuesto arquitectónicamente y no puede eludirse.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Audit Trail para el Comité de Empresa</h3>
<p class="text-body text-gosign-text-light mt-2">Cada decisión del agente genera una entrada completa en el Audit Trail: marca temporal, agente, entrada, reglas aplicadas, evaluación, ruta de decisión y resultado. El comité puede ver todas las decisiones vía el Portal de Auditor.</p>
</div>
</div>
</div>
</div>
</section>

<!-- Audit Trail Example -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Ejemplo de Entrada del Audit Trail</h2>
</div>
<div class="mt-8">
<pre class="bg-gosign-dark text-white p-6 rounded-card overflow-x-auto text-small font-mono leading-relaxed"><code>Entrada Audit Trail:
+-- Marca temporal:     2026-02-20T09:14:22Z
+-- Agente:             hr-merit-cycle-agent
+-- Entrada:            Ajuste salarial empleado #4711
+-- Reglas aplicadas:
|   +-- Conv. colectivo: CC Sector, Version 2025.2
|   +-- Acuerdo empresa: AE-2024-003, art. 4.2
|   +-- Banda salarial:  Banda E3, Rango 52.000-68.000 EUR
+-- Evaluacion:
|   +-- Confianza:      0.94
|   +-- Riesgo:         bajo
|   +-- Resultado:      Dentro de banda, dentro de restriccion AE
+-- Ruta de decision:   autonoma (ninguna restriccion AE violada)
+-- Salida:             Propuesta: ajuste +3,2%
+-- Estado:             aprobado</code></pre>
</div>
</div>
</section>

<!-- RBAC -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Control de Acceso Basado en Roles (RBAC)</h2>
<div class="mt-6 space-y-4">
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Operador del Agente:</strong> Configura agentes, cambia conjuntos de reglas (versionado, documentado).</p>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Especialista RRHH:</strong> Ve decisiones del agente en su área de responsabilidad.</p>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Comité de Empresa:</strong> Visión de patrones de decisión, estado de restricciones, Audit Trail (anonimizado donde sea necesario).</p>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Auditor / Auditoría Interna:</strong> Acceso completo a Audit Trail, evidencias, estado de controles.</p>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Admin:</strong> Configuración del sistema, sin acceso a datos de decisiones profesionales.</p>
</div>
<p class="text-body-lg text-gosign-text-light mt-4">
RBAC se impone a nivel de base de datos mediante Row-Level Security.
</p>
</div>
</div>
</section>

<!-- Lo Que No Hacemos -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Lo Que No Hacemos</h2>
<p class="text-body-lg font-semibold text-gosign-dark mt-4">El derecho de información y consulta del comité de empresa para AI Agents es un tema de arquitectura, no de taller.</p>
<ul class="mt-4 space-y-2 text-body-lg text-gosign-text-light">
<li>No reemplazamos acuerdos de empresa. Los mapeamos técnicamente.</li>
<li>No proporcionamos asesoramiento legal. Entregamos la infraestructura técnica.</li>
<li>No automatizamos decisiones sujetas a consulta con el comité de empresa sin Human-in-the-Loop.</li>
<li>No 'entrenamos' agentes con decisiones del comité de empresa. Los agentes no aprenden de forma incontrolada.</li>
<li>Los agentes se integran en su gobernanza IT existente - no son un universo paralelo.</li>
</ul>
</div>
</div>
</section>

<!-- Profundización -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Profundización en el Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nuestra serie de artículos para ejecutivos que implementan agentes de IA en la empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/es/revista/comite-empresa-ia-codeterminacion/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Codeterminación</p>
<p class="text-body font-semibold text-gosign-dark">Comité de Empresa e IA: Derecho de Información y Consulta como Constraint Arquitectónico</p>
</a>
<a href="/es/revista/agent-governance-hr/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Agent Governance en RRHH - Por qué el CHRO debe liderar</p>
</a>
<a href="/es/revista/human-in-the-loop-arquitectura/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Arquitectura</p>
<p class="text-body font-semibold text-gosign-dark">Human-in-the-Loop: principio arquitectónico, no checkbox</p>
</a>
</div>
</div>
</section>

--- Residencia de Datos y RGPD ---
> Soberanía de datos para AI Agents empresariales. Procesamiento en la UE, Row-Level Security, aislamiento de inquilinos, sin flujos a terceros.

<!-- Principio Fundamental -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Principio Fundamental</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Los AI Agents procesan datos críticos de negocio: datos de personal, datos financieros, datos contractuales. La cuestión de dónde se procesan estos datos y quién tiene acceso no es negociable para clientes empresariales. El <a href="/es/decision-layer/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Decision Layer</a> descompone cada proceso en pasos de decisión y define para cada paso si decide una persona, un conjunto de reglas o la IA - incluyendo qué datos pueden procesarse.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
La arquitectura de Gosign se basa en un principio fundamental: todos los datos permanecen en la infraestructura del cliente. Gosign no opera su propia nube, no almacena datos de clientes y no tiene acceso permanente a sistemas de producción. La <a href="/es/governance/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">arquitectura de gobernanza</a> completa garantiza que cada procesamiento de datos quede documentado y sea trazable.
</p>
</div>
</div>
</section>

<!-- Opciones de Despliegue -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">Opciones de Despliegue</h2>
<div class="grid grid-cols-1 md:grid-cols-2 gap-6 lg:gap-8">
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 15a4.5 4.5 0 0 0 4.5 4.5H18a3.75 3.75 0 0 0 .75-7.425A4.502 4.502 0 0 0 14.25 7.5a5.25 5.25 0 0 0-10.233 2.033A4.5 4.5 0 0 0 2.25 15Z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Azure (UE)</h3>
<p class="text-body text-gosign-text-light mt-3">
Regiones de <a href="https://azure.microsoft.com/en-us/explore/global-infrastructure/geographies/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Azure</a>: West Europe (Amsterdam), North Europe (Dublin), Germany West Central (Francfort). Azure OpenAI para procesamiento LLM dentro de Azure UE. DPA de Microsoft y EU Data Processing Addendum.
</p>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">GCP (UE)</h3>
<p class="text-body text-gosign-text-light mt-3">
Regiones de <a href="https://cloud.google.com/about/locations" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">GCP</a>: europe-west1 (Bélgica), europe-west3 (Francfort), europe-west4 (Países Bajos). Vertex AI para procesamiento LLM dentro de GCP UE. DPA de Google y EU Standard Contractual Clauses.
</p>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M5.25 14.25h13.5m-13.5 0a3 3 0 0 1-3-3m3 3a3 3 0 1 0 0 6h13.5a3 3 0 1 0 0-6m-16.5-3a3 3 0 0 1 3-3h13.5a3 3 0 0 1 3 3m-19.5 0a4.5 4.5 0 0 1 .9-2.7L5.737 5.1a3.375 3.375 0 0 1 2.7-1.35h7.126c1.062 0 2.062.5 2.7 1.35l2.587 3.45a4.5 4.5 0 0 1 .9 2.7m0 0a3 3 0 0 1-3 3m0 3h.008v.008h-.008v-.008Zm0-6h.008v.008h-.008v-.008Zm-3 6h.008v.008h-.008v-.008Zm0-6h.008v.008h-.008v-.008Z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">AWS (UE)</h3>
<p class="text-body text-gosign-text-light mt-3">
Regiones de <a href="https://aws.amazon.com/about-aws/global-infrastructure/regions_az/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">AWS</a>: eu-central-1 (Francfort), eu-west-1 (Irlanda), eu-west-3 (París), eu-south-2 (España). Amazon Bedrock para hosting de LLM (Claude, Llama, Mistral). Amazon EKS para orquestación de contenedores, Aurora PostgreSQL. DPA de AWS y EU Data Processing Addendum.
</p>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 17.25v1.007a3 3 0 0 1-.879 2.122L7.5 21h9l-.621-.621A3 3 0 0 1 15 18.257V17.25m6-12V15a2.25 2.25 0 0 1-2.25 2.25H5.25A2.25 2.25 0 0 1 3 15V5.25A2.25 2.25 0 0 1 5.25 3h13.5A2.25 2.25 0 0 1 21 5.25Z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Self-Hosted</h3>
<p class="text-body text-gosign-text-light mt-3">
Centro de datos propio o servidores propios. Modelos open-source: <a href="https://llama.meta.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Llama</a>, <a href="https://mistral.ai/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Mistral</a>, <a href="https://www.deepseek.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">DeepSeek</a> - operados localmente. Ningún dato sale de la red corporativa. Control total sobre hardware, software y red.
</p>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M7.5 21 3 16.5m0 0L7.5 12M3 16.5h13.5m0-13.5L21 7.5m0 0L16.5 12M21 7.5H7.5" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Híbrido</h3>
<p class="text-body text-gosign-text-light mt-3">
Combinación de cloud y self-hosted. Ejemplo: Self-hosted para datos sensibles de RRHH, Azure UE para procesamiento de documentos. La arquitectura soporta diferentes opciones de despliegue por agente.
</p>
</article>
</div>
</div>
</section>

<!-- Medidas Técnicas -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Medidas Técnicas de Protección de Datos</h2>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">Row-Level Security (RLS)</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
El aislamiento de inquilinos se impone a nivel de base de datos - no a nivel de aplicación. Una consulta SQL solo puede acceder a los registros autorizados. La separación no es eludible por lógica de aplicación.
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">Cifrado</h3>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light"><strong>En reposo:</strong> Todos los datos se almacenan cifrados (AES-256)</li>
<li class="text-body-lg text-gosign-text-light"><strong>En tránsito:</strong> Todas las transferencias de datos mediante TLS 1.3</li>
<li class="text-body-lg text-gosign-text-light"><strong>Gestión de claves:</strong> Claves propias del cliente (Bring Your Own Key) o gestionadas por plataforma</li>
</ul>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">Control de Acceso</h3>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light">RBAC (Role-Based Access Control) en todos los niveles</li>
<li class="text-body-lg text-gosign-text-light">Sin credenciales compartidas, sin cuenta de servicio con acceso total</li>
<li class="text-body-lg text-gosign-text-light">Los accesos se registran y son trazables en el Audit Trail</li>
<li class="text-body-lg text-gosign-text-light">Gosign no tiene acceso permanente a datos de producción</li>
</ul>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">Eliminación de Datos</h3>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light">Concepto de eliminación según RGPD Art. 17</li>
<li class="text-body-lg text-gosign-text-light">Períodos de retención configurables por tipo de dato</li>
<li class="text-body-lg text-gosign-text-light">La eliminación cubre todas las copias - base de datos, Audit Trail, backups (tras expiración de retención de backup)</li>
<li class="text-body-lg text-gosign-text-light">Protocolos de eliminación documentados en el Audit Trail</li>
</ul>
</div>
</div>
</section>

<!-- Protección Específica para LLM -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Protección de Datos Específica para LLM</h2>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">LLMs en la Nube (Azure OpenAI, Vertex AI, Amazon Bedrock)</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Cuando se usan LLMs en la nube, los datos se envían al servicio LLM. Medidas: los datos no se utilizan para entrenamiento (compromiso de Microsoft/Google), DPA/SCCs con el proveedor, minimización de datos. La <a href="/es/revista/pii-anonimizacion-llm-enterprise/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">anonimización de PII</a> garantiza que los datos personales se eliminen antes del procesamiento LLM.
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">Modelos Self-Hosted (Llama, Mistral, DeepSeek)</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Con modelos self-hosted, ningún dato sale de la infraestructura del cliente. El modelo se ejecuta localmente, el procesamiento se realiza en hardware propio. Compromiso: los modelos self-hosted son generalmente menos potentes que los últimos modelos propietarios. Más sobre estrategias de hosting en el artículo <a href="/es/revista/hosting-ia-estrategias-enterprise/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Hosting de IA: EU SaaS, centro de datos europeo o Self-Hosted</a>.
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">Sin Entrenamiento con Datos del Cliente</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Los AI Agents de Gosign no se entrenan con datos del cliente. Sin fine-tuning, sin re-entrenamiento, sin aprendizaje incontrolado. Los agentes usan LLMs con prompts y conjuntos de reglas - los modelos no se modifican.
</p>
</div>
</div>
</section>

<!-- Mapeo RGPD -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Mapeo RGPD</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Cada componente arquitectónico se asigna a un artículo específico del RGPD. Detalles de implementación en el contexto del <a href="/es/governance/eu-ai-act/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">EU AI Act</a>.
</p>
<div class="mt-8 overflow-x-auto">
<table class="w-full text-left text-small border-collapse">
<thead>
<tr>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Artículo RGPD</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Medida Arquitectónica</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Art. 5 - Minimización</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Solo se procesan datos necesarios. Sin almacenamiento preventivo.</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Art. 6 - Base legal</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Acuerdo de procesamiento (Art. 28) o interés legítimo, según contexto de uso</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Art. 17 - Supresión</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Concepto de eliminación con períodos configurables, eliminación documentada</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Art. 25 - Privacidad por diseño</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">RLS, cifrado, RBAC como componentes arquitectónicos</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Art. 28 - Procesamiento</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">DPA entre cliente y Gosign, DPA entre cliente y proveedor cloud</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Art. 30 - Registro</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Audit Trail documenta todas las actividades de procesamiento</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Art. 32 - Seguridad</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Cifrado, control de acceso, revisión regular</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Art. 33/34 - Notificación</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Proceso de respuesta a incidentes, Audit Trail para análisis forense</td></tr>
</tbody>
</table>
</div>
</div>
</div>
</section>

<!-- Distinción -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<p class="text-body-lg text-gosign-text-light">
Esta página describe medidas arquitectónicas técnicas para protección de datos y residencia de datos. La evaluación legal y la declaración formal de conformidad con el RGPD son responsabilidad del responsable del tratamiento (el cliente) y sus delegados de protección de datos. Gosign entrega la infraestructura técnica. La responsabilidad legal recae en el operador.
</p>
</div>
</div>
</section>

<!-- Profundización -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Profundización en el Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nuestra serie de artículos para ejecutivos que implementan agentes de IA en la empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/es/revista/pii-anonimizacion-llm-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Protección de datos</p>
<p class="text-body font-semibold text-gosign-dark">Anonimización de PII para IA Empresarial</p>
</a>
<a href="/es/revista/seguridad-datos-ia-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Seguridad</p>
<p class="text-body font-semibold text-gosign-dark">Seguridad de datos en IA: Data Residency, RGPD y EU AI Act</p>
</a>
<a href="/es/revista/hosting-ia-estrategias-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Hosting</p>
<p class="text-body font-semibold text-gosign-dark">Hosting de IA: EU SaaS, centro de datos europeo o Self-Hosted?</p>
</a>
</div>
</div>
</section>

--- EU AI Act Readiness ---
> Arquitectura Gosign frente al EU AI Act: transparencia, supervisión humana, registro y gestión de riesgos como principios de diseño.

<!-- Intro -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">EU AI Act - Relevancia para AI Agents Empresariales</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
El <a href="https://eur-lex.europa.eu/eli/reg/2024/1689/oj" target="_blank" rel="noopener noreferrer">EU AI Act (Reglamento (UE) 2024/1689)</a> regula los sistemas de IA en la Unión Europea. Para AI Agents empresariales que toman decisiones automatizadas o semiautomatizadas en procesos críticos, cuatro áreas son particularmente relevantes.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
La arquitectura de Gosign aborda estas áreas como principios de diseño - no como una capa de cumplimiento posterior.
</p>
</div>
</section>

<!-- Architecture Mapping Table -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">EU AI Act - Mapeo Arquitectónico</h2>
<div class="overflow-x-auto -mx-4 sm:mx-0">
<table class="w-full text-left text-small border-collapse min-w-[48rem]">
<thead>
<tr>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Requisito</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Artículo</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Implementación de Gosign</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Transparencia</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Art. 13</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">El Decision Layer documenta cada ruta de decisión completamente.</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Supervisión humana</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Art. 14</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Human-in-the-Loop impuesto arquitectónicamente para decisiones de riesgo.</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Obligaciones de registro</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Art. 12</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Audit Trail completo, inmutable y exportable.</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Gestión de riesgos</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Art. 9</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Monitoreo de sesgos, seguimiento de confianza, detección de anomalías, controles Cert-Ready.</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Explicación de la decisión individual</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Art. 86</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">El acta de decisión por microdecisión hace impugnable cada decisión, caso por caso.</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Cuatro Respuestas Arquitectónicas -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 space-y-12">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Cinco Respuestas Arquitectónicas</h2>
</div>
<div class="max-w-narrow">
<div class="flex items-start gap-4">
<span class="text-h1 font-bold text-gosign-accent-text leading-none">1</span>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Art. 13 - Transparencia</h3>
<p class="text-body-lg text-gosign-text-light mt-2">El Decision Layer documenta cada ruta de decisión completamente: entrada, modelo y versión, evaluación profesional, puntuación de confianza, regla aplicada con versión, y decisión o recomendación resultante. El Audit Trail hace esta información accesible para usuarios, auditores y comités de empresa.</p>
</div>
</div>
</div>
<div class="max-w-narrow">
<div class="flex items-start gap-4">
<span class="text-h1 font-bold text-gosign-accent-text leading-none">2</span>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Art. 14 - Supervisión Humana</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Human-in-the-Loop no es una configuración opcional sino un enrutamiento impuesto arquitectónicamente. El Decision Layer evalúa cada decisión por confianza y riesgo. Para riesgo de sesgo, potencial de discriminación, materias sujetas a consulta del comité de empresa o baja confianza, se involucra automáticamente a un humano. Este enrutamiento no puede eludirse.</p>
</div>
</div>
</div>
<div class="max-w-narrow">
<div class="flex items-start gap-4">
<span class="text-h1 font-bold text-gosign-accent-text leading-none">3</span>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Art. 12 - Obligaciones de Registro</h3>
<p class="text-body-lg text-gosign-text-light mt-2">El Audit Trail captura para cada decisión del agente: marca temporal (UTC), hash de entrada, versión del modelo, versión de la regla, puntuación de confianza, ruta de decisión, resultado y persona responsable. El Audit Trail es inmutable, exportable (JSON, CSV, PDF), legible por máquinas y completo.</p>
</div>
</div>
</div>
<div class="max-w-narrow">
<div class="flex items-start gap-4">
<span class="text-h1 font-bold text-gosign-accent-text leading-none">4</span>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Art. 9 - Gestión de Riesgos</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Monitoreo de Sesgos: supervisión estadística de decisiones del agente para detectar sesgos sistemáticos. Seguimiento de Confianza: supervisión de puntuaciones de confianza en el tiempo. Detección de Anomalías: detección automática de patrones de decisión que se desvían de patrones históricos. Controles Cert-Ready como objetos de datos de primera clase.</p>
</div>
</div>
</div>
<div class="max-w-narrow">
<div class="flex items-start gap-4">
<span class="text-h1 font-bold text-gosign-accent-text leading-none">5</span>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Art. 86 - Explicación de la Decisión Individual</h3>
<p class="text-body-lg text-gosign-text-light mt-2">El art. 86 da a la persona afectada derecho a una explicación de la decisión individual concreta - no a la descripción del sistema. La arquitectura lo cumple con el acta de decisión por microdecisión: el registro atómico e inmutable de una única decisión, con input, regla de negocio aplicada y su versión, confianza, versión del modelo, resultado y vía de impugnación. Esto hace cada decisión individualmente impugnable por el afectado, el comité de empresa, el auditor y la autoridad de control. Más a fondo: <a href="/es/revista/acta-de-decision-decisiones-ia-impugnables/" class="text-gosign-accent-text hover:text-gosign-accent-hover">Acta de decisión: por qué toda decisión de IA debe ser impugnable</a>.</p>
</div>
</div>
</div>
</div>
</section>

<!-- Clasificación de Riesgo -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Clasificación de Riesgo</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
La clasificación de un sistema de IA en una clase de riesgo del EU AI Act depende del caso de uso concreto:
</p>
<div class="mt-6 space-y-4">
<p class="text-body-lg text-gosign-text-light">
<strong class="text-gosign-dark">Potencialmente Alto Riesgo:</strong> AI Agents que preparan o influyen decisiones de personal (Art. 6, Anexo III Nr. 4), AI Agents en evaluación de solvencia, AI Agents que influyen en el acceso a servicios esenciales.
</p>
<p class="text-body-lg text-gosign-text-light">
<strong class="text-gosign-dark">No Alto Riesgo (típicamente):</strong> Document Agents que clasifican documentos sin tomar decisiones de personal, Knowledge Agents que proporcionan información sin tomar decisiones.
</p>
</div>
<p class="text-body-lg text-gosign-text-light mt-4">
La arquitectura de Gosign está diseñada para los requisitos más estrictos.
</p>
</div>
</section>

<!-- Posición de Compliance -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Posición de Compliance</h2>
<p class="text-body-lg font-semibold text-gosign-dark mt-4">EU AI Act compliant by design.</p>
<ul class="mt-4 space-y-2 text-body-lg text-gosign-text-light">
<li>Nuestra arquitectura aborda los requisitos centrales del EU AI Act como principios de diseño.</li>
<li>Transparencia mediante documentación completa de decisiones en el Decision Layer.</li>
<li>Supervisión humana mediante enrutamiento Human-in-the-Loop impuesto arquitectónicamente.</li>
<li>Obligaciones de registro mediante Audit Trail inmutable y exportable.</li>
<li>Gestión de riesgos mediante monitoreo de sesgos, seguimiento de confianza y controles Cert-Ready.</li>
<li>Explicación de la decisión individual (art. 86) mediante el acta de decisión por microdecisión: cada decisión queda individualmente impugnable, caso por caso.</li>
<li>Esta es una declaración arquitectónica, no un certificado de conformidad.</li>
</ul>
</div>
</div>
</section>

<!-- Distinción -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Distinción</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong class="text-gosign-dark">Esta página describe medidas arquitectónicas, no conformidad legal.</strong> El cumplimiento efectivo del EU AI Act depende del contexto de implementación concreto, la clasificación de riesgo y la evaluación jurídica caso por caso.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Gosign proporciona la arquitectura técnica que aborda los requisitos del EU AI Act. La evaluación legal y la declaración formal de conformidad son responsabilidad del operador y sus asesores jurídicos.
</p>
</div>
</section>

<!-- Profundización -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Profundización en el Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nuestra serie de artículos para ejecutivos que implementan agentes de IA en la empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/es/revista/eu-ai-act-hr/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Regulación</p>
<p class="text-body font-semibold text-gosign-dark">EU AI Act y RRHH: lo que ahora es obligatorio</p>
</a>
<a href="/es/revista/eu-ai-act-hr-alto-riesgo/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Alto riesgo</p>
<p class="text-body font-semibold text-gosign-dark">EU AI Act y RRHH: Qué se aplica a la IA en decisiones de personal</p>
</a>
<a href="/es/revista/cert-ready-by-design/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Auditoría</p>
<p class="text-body font-semibold text-gosign-dark">Cert-Ready by Design: IA preparada para auditoría</p>
</a>
</div>
</div>
</section>

--- Arquitectura de Referencia: 7 Capas para Enterprise AI ---
> Arquitectura de 7 capas para AI Agents empresariales. Governance by Design, agnóstica de modelos e infraestructura. Para CTOs.

<!-- Visión general -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Por qué siete capas</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Un sistema de IA monolítico no es auditable, no es escalable y no se puede mantener. La arquitectura de 7 capas separa responsabilidades: cada capa tiene una función definida y interfaces claras. Un cambio de modelo no altera la lógica de negocio. Un nuevo sistema destino no modifica el agente. Un nuevo requisito de cumplimiento normativo no cambia la infraestructura.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
La arquitectura es el resultado de requisitos empresariales: aislamiento de inquilinos, Audit Trail, transparencia para el Comité de Empresa (Art. 64 Estatuto de los Trabajadores), conformidad con el EU AI Act supervisada por la AESIA, cumplimiento del RGPD y la LOPDGDD, y despliegue agnóstico de modelos. Las APIs estándar de LLM no proporcionan nada de esto.
</p>
</div>
<img src="/images/diagrams/reference-architecture.svg" alt="Arquitectura de Referencia: 7 capas con Gobernanza como componente transversal - Presentation, Orchestration, Agent, Decision Layer, Model, Integration, Infrastructure" class="w-full rounded-card mt-8" width="1200" height="600" loading="lazy" />
</div>
</section>

<!-- Layer 1: Presentation -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">1. Presentation Layer</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
La interfaz entre el sistema y el usuario. Sin lógica de negocio, sin decisiones - solo visualización y entrada.
</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light"><strong>Chat UI:</strong> Interfaz web para usuarios finales (gestores de RRHH, contables). Compatible con PWA, responsiva.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Dashboard:</strong> Vista de estado de agentes, workflows activos, escalaciones pendientes. Basado en roles: los gestores ven sus casos, los directores ven indicadores.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Auditor Portal:</strong> Acceso para auditores al Audit Trail, controles y evidencias. Solo lectura. Para auditores de cuentas, el Comité de Empresa y revisión interna.</li>
<li class="text-body-lg text-gosign-text-light"><strong>REST API:</strong> Interfaz legible por máquina para integración con sistemas existentes. Versionada, documentada, autenticada.</li>
</ul>
</div>
</div>
</section>

<!-- Layer 2: Orchestration -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">2. Orchestration Layer</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Coordina el flujo de datos entre agentes, sistemas y usuarios. Gestiona workflows, colas y enrutamiento de APIs.
</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light"><strong>Motor de Workflow:</strong> Motores open source (Trigger.dev, Camunda) para procesos complejos y multietapa. Workflows visuales, integración de APIs, webhooks.</li>
<li class="text-body-lg text-gosign-text-light"><strong>API Gateway:</strong> Punto de entrada unificado con Rate Limiting, autenticación, logging y monitoring.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Sistema de Colas:</strong> Procesamiento asíncrono para procesos batch (cierre mensual, importación masiva).</li>
<li class="text-body-lg text-gosign-text-light"><strong>Sistema de Eventos:</strong> Reacción en tiempo real a documentos entrantes, cambios de estado y escalaciones.</li>
</ul>
</div>
</div>
</section>

<!-- Layer 3: Agent -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">3. Agent Layer</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
AI Agents especializados que ejecutan tareas profesionales. Cada agente tiene un ámbito de responsabilidad definido y opera dentro de los límites que establece el Decision Layer.
</p>
<h3 class="text-h3 font-bold text-gosign-dark mt-8"><a href="/es/servicios/ai-agents/document-agents/" class="text-gosign-dark hover:text-gosign-accent-text transition-colors">Document Agents</a></h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Leen, comprenden y procesan documentos con verdadera comprensión del lenguaje. Facturas, partes de baja, contratos, certificados, justificantes. Sin reconocimiento de plantillas, sin reglas rígidas - comprensión contextual.
</p>
<h3 class="text-h3 font-bold text-gosign-dark mt-8"><a href="/es/servicios/ai-agents/workflow-agents/" class="text-gosign-dark hover:text-gosign-accent-text transition-colors">Workflow Agents</a></h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Orquestan procesos entre múltiples sistemas. Cuando se necesita leer un documento, tomar una decisión y ejecutar una acción en un sistema destino - el Workflow Agent coordina el flujo completo.
</p>
<h3 class="text-h3 font-bold text-gosign-dark mt-8"><a href="/es/servicios/ai-agents/knowledge-agents/" class="text-gosign-dark hover:text-gosign-accent-text transition-colors">Knowledge Agents</a></h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Proporcionan respuestas contextuales basadas en el conocimiento empresarial. Acuerdos de empresa, políticas internas, convenios colectivos, normas de cumplimiento. Cada respuesta incluye la fuente y la versión de la norma aplicada.
</p>
</div>
</div>
</section>

<!-- Layer 4: Decision Layer -->
<section class="py-section bg-gosign-dark text-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold"><a href="/es/decision-layer/" class="hover:text-gosign-accent-on-dark transition-colors">4. Decision Layer</a></h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4">
Descompone cada proceso de negocio en pasos de decisión individuales y define para cada paso: persona, conjunto de reglas o IA. Cada decisión queda documentada - verificable por auditores de cuentas, el Comité de Empresa y revisión interna.
</p>
<div class="mt-6 space-y-4">
<p class="text-body-lg text-gosign-text-on-dark/80"><strong>Rules Engine:</strong> Conjuntos de reglas de negocio, versionados y trazables. Convenios colectivos, acuerdos de empresa, lógica contable, normas de cumplimiento. Cada regla tiene una versión, una fecha de vigencia y un ámbito de aplicación.</p>
<p class="text-body-lg text-gosign-text-on-dark/80"><strong>Confidence Routing:</strong> Evaluación automática del nivel de confianza de la decisión. Confianza alta y riesgo bajo: decisión autónoma. Confianza baja o riesgo alto: escalación a persona.</p>
<p class="text-body-lg text-gosign-text-on-dark/80"><strong>Human-in-the-Loop:</strong> Revisión humana arquitectónicamente impuesta para determinados tipos de decisión. Riesgo de sesgo, potencial de discriminación, temas sujetos al derecho de información y consulta del Comité de Empresa (Art. 64 ET).</p>
<p class="text-body-lg text-gosign-text-on-dark/80"><strong>Audit Trail - el acta de decisión:</strong> Documentación completa e inmutable de cada decisión. Por microdecisión, un acta de decisión: input, modelo, evaluación, regla de negocio con su versión, resultado, marca temporal y vía de impugnación. Solo adición - y con ello la respuesta arquitectónica al derecho del afectado a la explicación de la decisión individual conforme al art. 86 del EU AI Act.</p>
</div>
<p class="text-body text-gosign-text-on-dark/60 mt-4">
Profundizar: <a href="/es/revista/decision-layer-explicado/" class="text-gosign-text-on-dark/80 underline decoration-white/20 hover:text-white transition-colors">Decision Layer en detalle</a> · <a href="/es/revista/tres-tipos-de-decisiones/" class="text-gosign-text-on-dark/80 underline decoration-white/20 hover:text-white transition-colors">Tres tipos de decisiones IA</a> · <a href="/es/revista/acta-de-decision-decisiones-ia-impugnables/" class="text-gosign-text-on-dark/80 underline decoration-white/20 hover:text-white transition-colors">El acta de decisión</a>
</p>
</div>
</div>
</section>

<!-- Layer 5: Model -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">5. Model Layer</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
La capa LLM. Intercambiable, agnóstica respecto a modelos, desacoplada de la lógica de negocio.
</p>
<h3 class="text-h3 font-bold text-gosign-dark mt-6">Cloud LLMs</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Claude (Anthropic), ChatGPT (OpenAI), Gemini (Google) - a través de regiones UE de los respectivos proveedores cloud.</p>
<h3 class="text-h3 font-bold text-gosign-dark mt-6">LLMs Open Source / Open Weight</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Llama (Meta), Mistral, DeepSeek, <a href="https://openai.com/open-models/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">gpt-oss</a> (OpenAI, Apache 2.0) - completamente self-hostable en hardware propio. gpt-oss-120B funciona en una única GPU H100, gpt-oss-20B en 16 GB de hardware de consumo.</p>
<h3 class="text-h3 font-bold text-gosign-dark mt-6">Híbrido</h3>
<p class="text-body-lg text-gosign-text-light mt-2">LLMs cloud para casos estándar, LLMs self-hosted para datos sensibles. Enrutamiento automático según la clasificación de datos.</p>
<p class="text-body-lg text-gosign-text-light mt-4">
La elección del modelo es un equilibrio entre rendimiento, costes, protección de datos y latencia. El Model Layer es intercambiable - un cambio de modelo no altera la lógica de negocio de las capas superiores.
</p>
<p class="text-body text-gosign-text-light mt-4">
Opciones concretas de hosting, requisitos de hardware y stack tecnológico: <a href="/es/servicios/infraestructura/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">AI Infrastructure en detalle</a>
</p>
</div>
</div>
</section>

<!-- PII Gateway: redacción antes del Model Layer -->
<section id="pii-gateway" class="py-section bg-gosign-dark text-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold">El PII Gateway: redacción antes del Model Layer</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4">
Entre la lógica de negocio y el Model Layer, la arquitectura prevé un gateway de redacción (PII Gateway): cada llamada al modelo - cloud o self-hosted - pasa por él. Su objetivo de diseño: los datos personales no salen del perímetro de confianza del operador en texto en claro. Para cargas de trabajo sujetas a secreto profesional (despachos jurídicos, asesoría fiscal, salud), el gateway es una pieza de la minimización de datos del RGPD: complementa las salvaguardas organizativas y contractuales, no las sustituye.
</p>
<div class="mt-6 space-y-4">
<p class="text-body-lg text-gosign-text-on-dark/80"><strong>Redacción y reinserción:</strong> Antes de cada llamada al modelo, el gateway sustituye nombres, identificadores y otros atributos personales por marcadores (seudonimización). El modelo trabaja exclusivamente sobre el texto redactado. Los valores originales se reinsertan después de la respuesta - dentro del perímetro de confianza, nunca en el proveedor del modelo.</p>
<p class="text-body-lg text-gosign-text-on-dark/80"><strong>Audit Trail sin texto en claro:</strong> Cada llamada al modelo se registra append-only y encadenada por hashes: valores hash del prompt y de la respuesta en bruto en lugar de texto en claro, además del ID del modelo, la versión de la API y la versión del conjunto de reglas de redacción. La evidencia de qué pasó por el gateway y cuándo permanece completa - sin que el propio registro se convierta en un almacén de datos sensibles.</p>
<p class="text-body-lg text-gosign-text-on-dark/80"><strong>Reglas break-glass:</strong> Los accesos excepcionales para incidencias y auditorías están previstos en el diseño - nunca en silencio: principio de cuatro ojos, justificación documentada, alcance limitado en el tiempo, y cada uso de break-glass queda registrado íntegramente en el Audit Trail.</p>
<p class="text-body-lg text-gosign-text-on-dark/80"><strong>Aprobación del usuario en baja confianza:</strong> Si la confianza de la redacción en un pasaje es baja, la decisión se eleva al usuario en la interfaz - nunca al personal de Gosign. La escalación permanece en la esfera donde los datos ya son conocidos.</p>
</div>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-6">
Los modos de API que no pueden redactarse - por ejemplo, llamadas externas de embeddings cuyos vectores no admiten seudonimización - se bloquean para los contenidos sujetos a redacción, en lugar de dejarlos pasar en silencio. Las tablas de correspondencia entre marcadores y valores originales son efímeras o cifradas por inquilino con un tiempo de vida definido (TTL); las claves de proveedor residen exclusivamente en el sistema de gestión de claves (KMS).
</p>
<p class="text-body text-gosign-text-on-dark/60 mt-4">
Profundizar: <a href="/es/revista/pii-anonimizacion-llm-enterprise/" class="text-gosign-text-on-dark/80 underline decoration-white/20 hover:text-white transition-colors">Anonimización de PII para IA Empresarial</a>
</p>
</div>
</div>
</section>

<!-- Layer 6: Integration -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">6. Integration Layer</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
La conexión con los sistemas empresariales existentes. El agente no sustituye sistemas - los amplía.
</p>
<div class="mt-6 overflow-x-auto">
<table class="w-full text-left text-small border-collapse">
<thead>
<tr>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Categoría de sistema</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Integración</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">ERP / Finanzas</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">SAP FI/CO, SAP S/4HANA, DATEV, Oracle Financials</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">RRHH / Nóminas</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">SAP SuccessFactors, Workday, Personio</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Colaboración</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">SharePoint, Microsoft Teams (via Microsoft Graph)</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">DMS / ECM</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">SharePoint, d.velop, ELO, nscale</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Otros</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Cualquier sistema con interfaz REST o SOAP</td></tr>
</tbody>
</table>
</div>
<p class="text-body-lg text-gosign-text-light mt-4">
La lógica del agente está desacoplada del sistema destino. La lógica contable está separada de la exportación. Si cambia el sistema destino (por ejemplo, de DATEV a SAP), cambia el Export Layer, no el agente.
</p>
</div>
</div>
</section>

<!-- Layer 7: Infrastructure -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">7. Infrastructure Layer</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
El fundamento de despliegue. Toda la arquitectura se ejecuta en la infraestructura del cliente - no en Gosign, no en un tercero.
</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light"><strong>Cloud (UE):</strong> Azure, AWS o GCP - exclusivamente regiones UE. Kubernetes gestionado, bases de datos gestionadas, hosting de LLM.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Managed UE:</strong> Vercel EU + Supabase EU. Opción ligera en la UE sin infraestructura Kubernetes propia.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Self-Hosted:</strong> Servidores propios, centro de datos propio. Docker/Kubernetes, LLMs open source en GPUs propias. Total independencia del Cloud Act.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Híbrido:</strong> Combinación según clasificación de datos. Cargas sensibles en self-hosted, cargas estándar en cloud.</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-4">
Todas las capas por encima de la capa de infraestructura permanecen idénticas, independientemente del modelo de despliegue.
</p>
<p class="text-body text-gosign-text-light mt-4">
Regiones cloud, dimensionamiento de hardware, stack tecnológico: <a href="/es/servicios/infraestructura/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">AI Infrastructure en detalle</a>
</p>
</div>
</div>
</section>

<!-- Gobernanza como componente transversal -->
<section class="py-section bg-gosign-dark text-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold">Gobernanza como componente transversal</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4">
La gobernanza no es una capa individual, sino que atraviesa toda la arquitectura. Cada capa genera datos de gobernanza, cada capa es controlada por reglas de gobernanza.
</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-on-dark/80"><strong>Presentation:</strong> Acceso basado en roles, Auditor Portal</li>
<li class="text-body-lg text-gosign-text-on-dark/80"><strong>Orchestration:</strong> Logging de workflows, documentación de escalaciones</li>
<li class="text-body-lg text-gosign-text-on-dark/80"><strong>Agent:</strong> Las decisiones de agentes generan entradas de Audit Trail</li>
<li class="text-body-lg text-gosign-text-on-dark/80"><strong>Decision Layer:</strong> Rules Engine, Confidence Routing, Human-in-the-Loop</li>
<li class="text-body-lg text-gosign-text-on-dark/80"><strong>Model:</strong> Seguimiento de versiones de modelo, hashing de entradas, reproducibilidad, redacción de PII y registro sin texto en claro (PII Gateway)</li>
<li class="text-body-lg text-gosign-text-on-dark/80"><strong>Integration:</strong> Logging de interfaces, documentación de flujos de datos</li>
<li class="text-body-lg text-gosign-text-on-dark/80"><strong>Infrastructure:</strong> Cifrado, Row-Level Security, aislamiento de inquilinos</li>
</ul>
<p class="text-body text-gosign-text-on-dark/60 mt-6">
<a href="/es/governance/eu-ai-act/" class="text-gosign-text-on-dark/80 underline decoration-white/20 hover:text-white transition-colors">EU AI Act</a> · <a href="/es/governance/cert-ready/" class="text-gosign-text-on-dark/80 underline decoration-white/20 hover:text-white transition-colors">Cert-Ready by Design</a> · <a href="/es/governance/co-determination/" class="text-gosign-text-on-dark/80 underline decoration-white/20 hover:text-white transition-colors">Codeterminación</a> · <a href="/es/governance/data-residency/" class="text-gosign-text-on-dark/80 underline decoration-white/20 hover:text-white transition-colors">Data Residency</a>
</p>
</div>
</div>
</section>

<!-- Runtime y Escalabilidad -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Runtime y escalabilidad</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
El funcionamiento en producción no es un trabajo posterior, sino un componente arquitectónico. La arquitectura de 7 capas está diseñada para operar bajo carga.
</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light"><strong>Orquestación de contenedores:</strong> Despliegue basado en Kubernetes. Cada capa funciona en sus propios contenedores, escalables de forma independiente.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Escalabilidad horizontal:</strong> El Agent Layer y el Model Layer escalan horizontalmente según la carga. Un nuevo agente significa más pods, no más arquitectura.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Health Checks y Self-Healing:</strong> Liveness y Readiness Probes en todos los contenedores. Reinicio automático en caso de fallo, redirección automática en caso de sobrecarga.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Monitoring y Alerting:</strong> Métricas Prometheus en todas las capas. Dashboards Grafana para latencia, throughput, tasas de error y profundidad de colas. Alertas al superar umbrales.</li>
<li class="text-body-lg text-gosign-text-light"><strong>CI/CD:</strong> Despliegues basados en GitOps. Infrastructure as Code (Terraform/Pulumi). Tests automatizados, Blue-Green o Canary Deployments.</li>
</ul>
</div>
</div>
</section>

<!-- Arquitectura de datos -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Arquitectura de datos</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Los datos fluyen a través de las siete capas. La arquitectura define dónde se generan los datos, cómo se almacenan y quién tiene acceso.
</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light"><strong>Flujo de datos:</strong> Input (documento, consulta) - Agent (análisis) - Decision Layer (decisión) - Integration (exportación al sistema destino). Cada paso genera una entrada de Audit Trail.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Vector Store:</strong> PostgreSQL con pgvector para búsqueda semántica (RAG). El conocimiento empresarial se almacena como embeddings, sin enviarse a servicios externos.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Aislamiento de inquilinos:</strong> Row-Level Security (RLS) a nivel de base de datos. Impuesto arquitectónicamente, no mediante lógica de aplicación. Cada inquilino está completamente aislado.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Cifrado:</strong> En reposo (AES-256) y en tránsito (TLS 1.3). Gestión de claves a través del proveedor de identidad del cliente o módulos de seguridad de hardware (HSM).</li>
<li class="text-body-lg text-gosign-text-light"><strong>Retención de datos:</strong> Configurable según requisitos. La obligación de conservación fiscal y el derecho de supresión del RGPD Art. 17 se resuelven mediante anonimización en lugar de eliminación.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Backup y Recovery:</strong> Copias de seguridad automatizadas, Point-in-Time Recovery. Recovery Point Objective (RPO) y Recovery Time Objective (RTO) se configuran por inquilino.</li>
</ul>
</div>
</div>
</section>

<!-- Arquitectura de interfaces -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Arquitectura de interfaces</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
La arquitectura se comunica a través de interfaces definidas - internamente entre capas y externamente con sistemas de origen y destino.
</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light"><strong>REST API:</strong> APIs versionadas (v1, v2) con documentación OpenAPI. Cambios incompatibles solo en versiones nuevas; las versiones anteriores se mantienen en paralelo.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Event-Driven:</strong> Procesamiento de eventos basado en webhooks para reacción en tiempo real. Documento entrante - evento - agente procesa. Sin polling, sin retardo batch.</li>
<li class="text-body-lg text-gosign-text-light"><strong>MCP (Model Context Protocol):</strong> Protocolo estandarizado para integración de herramientas en agentes LLM. Los agentes acceden a herramientas externas a través de MCP - tipadas, documentadas, auditables.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Procesamiento batch:</strong> Para operaciones masivas (cierre mensual, liquidación anual, importación masiva). Basado en colas con seguimiento de progreso y gestión de errores.</li>
<li class="text-body-lg text-gosign-text-light"><strong>API Gateway:</strong> Punto de entrada central. Autenticación (SSO/OIDC), Rate Limiting, logging de peticiones, monitoring. Desacopla la arquitectura interna de los consumidores externos.</li>
</ul>
</div>
</div>
</section>

<!-- Principios de diseño -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Principios de diseño</h2>
<div class="mt-6 space-y-4">
<p class="text-body-lg text-gosign-text-light"><strong>Agnóstico de modelos:</strong> Sin vendor lock-in con un único LLM. Los modelos son intercambiables. Hoy Claude, mañana gpt-oss, pasado mañana un modelo que hoy aún no existe.</p>
<p class="text-body-lg text-gosign-text-light"><strong>Agnóstico de infraestructura:</strong> La misma arquitectura en Azure, AWS, GCP, self-hosted o híbrido. La elección de infraestructura es una decisión del cliente, no de la arquitectura.</p>
<p class="text-body-lg text-gosign-text-light"><strong>Agnóstico de sistemas:</strong> La lógica del agente está desacoplada del sistema destino. Lógica contable separada de exportación. Un cambio de sistema modifica el Integration Layer, no el agente.</p>
<p class="text-body-lg text-gosign-text-light"><strong>Governance by Design:</strong> Audit Trail, RBAC, Decision Layer y Human-in-the-Loop son componentes arquitectónicos - no funcionalidades opcionales que se añaden después.</p>
<p class="text-body-lg text-gosign-text-light"><strong>Cert-Ready by Design:</strong> Los controles son objetos de datos de primera clase con generación automática de evidencias. ISO 27001, PS 951, SOC 2 - la arquitectura genera las pruebas.</p>
<p class="text-body-lg text-gosign-text-light"><strong>Acceso al código:</strong> Acceso completo al código fuente, todos los prompts y conjuntos de reglas. Las configuraciones y conjuntos de reglas permanecen con el cliente. Stack open source donde sea posible. Tras 12-18 meses, el cliente opera los agentes de forma independiente.</p>
</div>
</div>
</div>
</section>

<!-- Decision Layer - Flujo de decisión -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-6">Decision Layer - Flujo de decisión</h2>
<figure role="img" aria-label="Flujo de decisión: el input es analizado por el AI Agent, el Decision Layer verifica reglas y confianza, enruta a decisión autónoma o Human-in-the-Loop, documenta todo en el Audit Trail y exporta al sistema destino.">
<pre class="bg-gosign-dark text-white p-6 rounded-card overflow-x-auto text-small font-mono leading-relaxed"><code>+-----------+    +--------------+    +----------------+
|  Input    |---&gt;|  AI Agent    |---&gt;| Decision Layer |
|(documento |    |  analiza,    |    |                |
| consulta) |    |  comprende,  |    |  Verificar     |
+-----------+    |  evalua      |    |  reglas        |
+--------------+    |                |
|  Evaluar       |
|  confianza     |
|                |
|  Decidir       |
|  enrutamiento  |
+-------+--------+
|
+-------------+--------------+
|                            |
+--------v--------+        +----------v----------+
| Autonomo        |        | Human-in-the-Loop   |
|                 |        |                     |
| Alta confianza  |        | Riesgo de sesgo     |
| Bajo riesgo     |        | Baja confianza      |
| Sin restriccion |        | Restriccion activa  |
| normativa       |        | Consulta al Comite  |
+--------+--------+        +----------+----------+
|                            |
|         +--------------+   |
|         |  Persona     |   |
|         |  decide      |&lt;--+
|         +------+-------+
|                |
+--------v----------------v--------+
|         Audit Trail              |
|  Input - Modelo - Regla -        |
|  Evaluacion - Resultado -        |
|  Marca temporal                  |
+----------------------------------+
|
+--------v--------+
|  Sistema        |
|  destino        |
|  (ERP, RRHH,    |
|   Nominas)      |
+-----------------+</code></pre>
<figcaption class="text-small text-gosign-text-light mt-3">Flujo esquemático de decisión a través del Decision Layer. En el entorno de producción, cada paso se documenta como entrada de Audit Trail.</figcaption>
</figure>
</div>
</section>

<!-- Profundizacion -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Para profundizar</h2>
<div class="mt-6 grid gap-6 sm:grid-cols-2">
<div class="border-l-4 border-gosign-dark pl-6 py-4">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Implementación</p>
<h3 class="text-h3 font-bold text-gosign-dark">AI Infrastructure</h3>
<p class="text-body text-gosign-text-light mt-2">Tecnologías concretas, regiones cloud, dimensionamiento de hardware, tabla de stack tecnológico.</p>
<a href="/es/servicios/infraestructura/" class="text-small font-semibold text-gosign-accent-text hover:text-gosign-accent-hover mt-3 inline-block whitespace-nowrap">Infraestructura en detalle &rarr;</a>
</div>
<div class="border-l-4 border-gosign-dark pl-6 py-4">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Recurso de conocimiento</p>
<h3 class="text-h3 font-bold text-gosign-dark">Blueprint 2026</h3>
<p class="text-body text-gosign-text-light mt-2">Once artículos sobre las decisiones de infraestructura que importan en 2026.</p>
<a href="/es/revista/infraestructura-ia-blueprint-2026/" class="text-small font-semibold text-gosign-accent-text hover:text-gosign-accent-hover mt-3 inline-block whitespace-nowrap">A la serie de artículos &rarr;</a>
</div>
<div class="border-l-4 border-gosign-dark pl-6 py-4">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Agentes</p>
<h3 class="text-h3 font-bold text-gosign-dark">AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Document Agents, Workflow Agents, Knowledge Agents - tres tipos de agentes para procesos empresariales.</p>
<a href="/es/servicios/ai-agents/" class="text-small font-semibold text-gosign-accent-text hover:text-gosign-accent-hover mt-3 inline-block whitespace-nowrap">Explorar AI Agents &rarr;</a>
</div>
<div class="border-l-4 border-gosign-dark pl-6 py-4">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<h3 class="text-h3 font-bold text-gosign-dark">Marco de Governance</h3>
<p class="text-body text-gosign-text-light mt-2">EU AI Act, Cert-Ready, Codeterminación, Data Residency - todos los temas de governance en un vistazo.</p>
<a href="/es/governance/" class="text-small font-semibold text-gosign-accent-text hover:text-gosign-accent-hover mt-3 inline-block whitespace-nowrap">Vista general Governance &rarr;</a>
</div>
</div>
</div>
</div>
</section>

<!-- Profundización en el Agent Briefing -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Profundización en el Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nuestra serie de artículos para ejecutivos que implementan agentes de IA en la empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/es/revista/infraestructura-ia-blueprint-2026/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infraestructura</p>
<p class="text-body font-semibold text-gosign-dark">Enterprise AI-Infraestructura Blueprint 2026</p>
</a>
<a href="/es/revista/decision-layer-explicado/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Arquitectura</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - Qué es y por qué todo agente AI enterprise lo necesita</p>
</a>
<a href="/es/revista/orquestacion-agentes-plataformas/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Orquestación</p>
<p class="text-body font-semibold text-gosign-dark">Orquestación de agentes: Trigger.dev, n8n, Camunda y más</p>
</a>
</div>
</div>
</section>

--- Gobernanza, Seguridad y Auditoría ---
> AI Agents auditables, preparados para certificación y compatibles con los comités de empresa. Governance by Design como principio arquitectónico.

<!-- Governance by Design -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Governance by Design</h2>
<p class="text-body-lg text-gosign-text-light mt-6">
Gosign construye AI Agents para entornos empresariales. Estos entornos tienen requisitos de trazabilidad, auditabilidad y control que van más allá de lo que ofrece un despliegue estándar de LLM.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Governance by Design significa: cada agente se construye desde cero con los mecanismos que auditores, comités de empresa y equipos de cumplimiento esperan. No es una capa opcional añadida después. Es un principio arquitectónico.
</p>
</div>
</div>
</section>

<!-- Cinco Dimensiones -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Cinco Dimensiones de Gobernanza</h2>

<div class="mt-8 space-y-8">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">1. Audit Trail y Trazabilidad</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Cada decisión de un AI Agent genera un acta de decisión completa e inmutable: entrada, modelo y versión, evaluación profesional, puntuación de confianza, regla de negocio aplicada con su versión, ruta de decisión (autónoma o Human-in-the-Loop), resultado, marca temporal y vía de impugnación. Es la respuesta arquitectónica al derecho del afectado a la explicación de la decisión individual conforme al <a href="/es/revista/acta-de-decision-decisiones-ia-impugnables/" class="text-gosign-accent-text hover:underline">art. 86 del EU AI Act</a>. El Audit Trail es inmutable, exportable y legible por máquinas.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark">2. Decision Layer</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
El Decision Layer es la capa arquitectónica entre el AI Agent y el sistema destino. Hace cada decisión del LLM transparente, auditable y trazable. Decisión autónoma donde el modelo puede decidir de forma segura. Human-in-the-Loop donde existe riesgo de sesgo, potencial de discriminación o materias sujetas a consulta del comité de empresa - impuesto arquitectónicamente, no opcional.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark">3. Cert-Ready by Design</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Los controles son objetos de datos de primera clase en el sistema. Cada control tiene: implementación técnica, generador automático de evidencias, historial de evidencias y vista de auditor con drill-down hasta la implementación concreta.
</p>
<p class="mt-2">
<a href="/es/governance/cert-ready/" class="text-gosign-accent-text font-semibold hover:text-gosign-accent-hover">Cert-Ready by Design en detalle</a>
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark">4. Información, Consulta y Comité de Empresa</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Los AI Agents en empresas españolas están sujetos a derechos de información y consulta del comité de empresa conforme al Art. 64 del Estatuto de los Trabajadores. La arquitectura de Gosign lo aborda como principio de diseño: convenios colectivos y acuerdos de empresa como restricciones explícitas, trazabilidad completa, Human-in-the-Loop para decisiones con potencial de sesgo o discriminación.
</p>
<p class="mt-2">
<a href="/es/governance/co-determination/" class="text-gosign-accent-text font-semibold hover:text-gosign-accent-hover">Información, Consulta y Comité de Empresa</a>
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark">5. EU AI Act</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
La arquitectura de Gosign aborda los requisitos centrales del EU AI Act como principio de diseño: transparencia (Art. 13), supervisión humana (Art. 14), obligaciones de registro (Art. 12), gestión de riesgos (Art. 9) y el derecho a la explicación de la decisión individual (Art. 86).
</p>
<p class="mt-2">
<a href="/es/governance/eu-ai-act/" class="text-gosign-accent-text font-semibold hover:text-gosign-accent-hover">EU AI Act Readiness</a>
</p>
</div>
</div>
</div>
</div>
</section>

<!-- Architecture Diagram -->
<section class="py-section bg-gosign-dark text-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold mb-4">Visión General de la Arquitectura</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mb-6">La capa de gobernanza no es un componente separado. Atraviesa todas las capas de la arquitectura del agente.</p>
<pre class="bg-gosign-dark border border-white/10 text-white p-6 rounded-card overflow-x-auto text-small font-mono leading-relaxed"><code>┌─────────────────────────────────────────────────┐
│  Presentation Layer    Chat UI, Dashboard, API  │
├─────────────────────────────────────────────────┤
│  Orchestration Layer   Trigger.dev/Camunda, API GW      │
├─────────────────────────────────────────────────┤
│  Agent Layer           Document, Workflow,       │
│                        Knowledge Agents          │
├─────────────────────┬───────────────────────────┤
│  GOVERNANCE LAYER   │ Audit Trail, RBAC,        │
│  (Transversal)      │ Decision Layer,           │
│                     │ Cert-Ready Controls       │
├─────────────────────┴───────────────────────────┤
│  Model Layer           Claude, ChatGPT, Llama   │
├─────────────────────────────────────────────────┤
│  Integration Layer     SAP, ERP, MS Graph       │
├─────────────────────────────────────────────────┤
│  Infrastructure Layer  Azure, GCP, AWS, Self-Hosted  │
└─────────────────────────────────────────────────┘</code></pre>
<p class="mt-6">
<a
href="/es/governance/reference-architecture/"
class="inline-flex items-center text-body-lg font-semibold text-gosign-accent-on-dark hover:text-gosign-accent-on-dark transition-colors"
>
Ver Arquitectura de Referencia completa
<svg class="w-5 h-5 ml-2" fill="none" stroke="currentColor" viewBox="0 0 24 24">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" />
</svg>
</a>
</p>
</div>
</section>

<!-- Seis dimensiones de Gobernanza -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">Seis dimensiones de Gobernanza</h2>
<div class="grid grid-cols-1 lg:grid-cols-3 gap-6 lg:gap-8">
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75L11.25 15 15 9.75m-3-7.036A11.959 11.959 0 013.598 6 11.99 11.99 0 003 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Cert-Ready by Design</h3>
<p class="text-body text-gosign-text-light mt-3">Controles como objetos de datos, evidencia automática, portal de auditor en vivo. La preparación para certificación no es un proyecto, es un estado arquitectónico.</p>
<a href="/es/governance/cert-ready/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
Ver Cert-Ready Controls
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M18 18.72a9.094 9.094 0 003.741-.479 3 3 0 00-4.682-2.72m.94 3.198l.001.031c0 .225-.012.447-.037.666A11.944 11.944 0 0112 21c-2.17 0-4.207-.576-5.963-1.584A6.062 6.062 0 016 18.719m12 0a5.971 5.971 0 00-.941-3.197m0 0A5.995 5.995 0 0012 12.75a5.995 5.995 0 00-5.058 2.772m0 0a3 3 0 00-4.681 2.72 8.986 8.986 0 003.74.477m.94-3.197a5.971 5.971 0 00-.94 3.197M15 6.75a3 3 0 11-6 0 3 3 0 016 0zm6 3a2.25 2.25 0 11-4.5 0 2.25 2.25 0 014.5 0zm-13.5 0a2.25 2.25 0 11-4.5 0 2.25 2.25 0 014.5 0z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Información y Consulta</h3>
<p class="text-body text-gosign-text-light mt-3">Acuerdos de empresa como restricciones. Human-in-the-Loop en decisiones sujetas a consulta previa del comité. Impuesto técnicamente, no acordado organizativamente.</p>
<a href="/es/governance/co-determination/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
Ver Información y Consulta
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 3v17.25m0 0c-1.472 0-2.882.265-4.185.75M12 20.25c1.472 0 2.882.265 4.185.75M18.75 4.97A48.416 48.416 0 0012 4.5c-2.291 0-4.545.16-6.75.47m13.5 0c1.01.143 2.01.317 3 .52m-3-.52l2.62 10.726c.122.499-.106 1.028-.589 1.202a5.988 5.988 0 01-2.031.352 5.988 5.988 0 01-2.031-.352c-.483-.174-.711-.703-.59-1.202L18.75 4.971zm-16.5.52c.99-.203 1.99-.377 3-.52m0 0l2.62 10.726c.122.499-.106 1.028-.589 1.202a5.989 5.989 0 01-2.031.352 5.989 5.989 0 01-2.031-.352c-.483-.174-.711-.703-.59-1.202L5.25 4.971z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">EU AI Act</h3>
<p class="text-body text-gosign-text-light mt-3">EU AI Act compliant by design. Mapeo arquitectónico a Art. 9-15. Transparencia, explicabilidad y supervisión humana como arquitectura base.</p>
<a href="/es/governance/eu-ai-act/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
Ver EU AI Act Compliance
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M21 7.5l-2.25-1.313M21 7.5v2.25m0-2.25l-2.25 1.313M3 7.5l2.25-1.313M3 7.5l2.25 1.313M3 7.5v2.25m9 3l2.25-1.313M12 12.75l-2.25-1.313M12 12.75V15m0 6.75l2.25-1.313M12 21.75V19.5m0 2.25l-2.25-1.313m0-16.875L12 2.25l2.25 1.313M21 14.25v2.25l-2.25 1.313m-13.5 0L3 16.5v-2.25" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Arquitectura de Referencia</h3>
<p class="text-body text-gosign-text-light mt-3">Arquitectura Enterprise AI de 7 capas. Gobernanza como capa transversal. Presentación, Orquestación, Agente, Gobernanza, Modelo, Integración, Infraestructura.</p>
<a href="/es/governance/reference-architecture/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
Ver Arquitectura
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M16.5 10.5V6.75a4.5 4.5 0 10-9 0v3.75m-.75 11.25h10.5a2.25 2.25 0 002.25-2.25v-6.75a2.25 2.25 0 00-2.25-2.25H6.75a2.25 2.25 0 00-2.25 2.25v6.75a2.25 2.25 0 002.25 2.25z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Residencia de Datos</h3>
<p class="text-body text-gosign-text-light mt-3">RGPD. Azure UE, GCP UE, AWS UE, Self-Hosted, Híbrido. Soberanía de datos como decisión arquitectónica, no como opción de configuración.</p>
<a href="/es/governance/data-residency/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
Ver Residencia de Datos
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12h3.75M9 15h3.75M9 18h3.75m3 .75H18a2.25 2.25 0 002.25-2.25V6.108c0-1.135-.845-2.098-1.976-2.192a48.424 48.424 0 00-1.123-.08m-5.801 0c-.065.21-.1.433-.1.664 0 .414.336.75.75.75h4.5a.75.75 0 00.75-.75 2.25 2.25 0 00-.1-.664m-5.8 0A2.251 2.251 0 0113.5 2.25H15a2.25 2.25 0 012.15 1.586m-5.8 0c-.376.023-.75.05-1.124.08C9.095 4.01 8.25 4.973 8.25 6.108V8.25m0 0H4.875c-.621 0-1.125.504-1.125 1.125v11.25c0 .621.504 1.125 1.125 1.125h9.75c.621 0 1.125-.504 1.125-1.125V9.375c0-.621-.504-1.125-1.125-1.125H8.25zM6.75 12h.008v.008H6.75V12zm0 3h.008v.008H6.75V15zm0 3h.008v.008H6.75V18z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Contrato de encargado para infraestructura IA</h3>
<p class="text-body text-gosign-text-light mt-3">Por qué los contratos estándar de encargado de tratamiento no cubren la IA empresarial. Checklist con 25 preguntas de verificación para legal, seguridad IT y comité de empresa.</p>
<a href="/es/governance/checklist-contrato-ia/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
Checklist
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</article>
</div>
</div>
</section>

<!-- Data Residency brief -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">La Gobernanza Se Aplica a Cada Agente</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Governance by Design no es una característica de un solo producto. Es un principio arquitectónico que se aplica a cada AI Agent que Gosign construye.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Misma gobernanza. Misma auditabilidad. Misma infraestructura.
</p>
</div>
</div>
</section>

<!-- Profundización en el Agent Briefing -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">Profundización en el Agent Briefing (Revista Gosign)</h2>
<div class="grid md:grid-cols-3 gap-6">
<a href="/es/revista/shadow-ai-governance/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<h3 class="text-h3 font-bold text-gosign-dark">Decision Layer y Shadow AI</h3>
</a>
<a href="/es/revista/eu-ai-act-2026-empresas/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<h3 class="text-h3 font-bold text-gosign-dark">EU AI Act 2026</h3>
</a>
<a href="/es/revista/infraestructura-ia-blueprint-2026/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Infrastructure</p>
<h3 class="text-h3 font-bold text-gosign-dark">Infraestructura IA Blueprint 2026</h3>
</a>
</div>
</div>
</section>

<!-- FAQ -->

--- Herramientas AI gratuitas - Ayudas interactivas para decisiones ---
> 8 herramientas AI gratuitas en el navegador: Board Deck Generator, EU AI Act Risk Classifier, calculadora ROI, planificador TCO y más. Sin registro.

<section class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-12">

<p class="text-body text-gosign-text mb-10">Todas las herramientas funcionan directamente en el navegador. Sin registro, sin compartir datos, sin costes ocultos. Los resultados se basan en frameworks y benchmarks públicos.</p>

<div class="grid grid-cols-1 md:grid-cols-2 gap-6">

<div class="bg-gosign-dark rounded-card p-6 flex flex-col">
<span class="inline-block text-small font-medium text-gosign-accent-on-dark bg-white/10 rounded-full px-3 py-1 mb-4 w-fit">Gratuito, en el navegador, sin registro</span>
<h2 class="text-h3 font-bold text-white mb-2">Board Deck Generator</h2>
<p class="text-body text-white/70 mb-4 flex-1">Evaluación inicial de 9 diapositivas con análisis ROI, evaluación de riesgos y comparación de 3 escenarios. 7 campos, presentación para el consejo como resultado.</p>
<a href="/es/catalogo-agentes-hr/" class="inline-flex items-center gap-2 text-gosign-accent-on-dark hover:text-white font-medium">Ir al catálogo HR &rarr;</a>
</div>

<div class="bg-gosign-dark rounded-card p-6 flex flex-col">
<span class="inline-block text-small font-medium text-gosign-accent-on-dark bg-white/10 rounded-full px-3 py-1 mb-4 w-fit">Gratuito, en el navegador, sin registro</span>
<h2 class="text-h3 font-bold text-white mb-2">EU AI Act Risk Classifier</h2>
<p class="text-body text-white/70 mb-4 flex-1">Clasificación de riesgo según el Reglamento (UE) 2024/1689. 7 preguntas, asignación clara a Minimal, Limited, High o Unacceptable Risk.</p>
<a href="/es/governance/eu-ai-act/" class="inline-flex items-center gap-2 text-gosign-accent-on-dark hover:text-white font-medium">Ir al Risk Classifier &rarr;</a>
</div>

<div class="bg-gosign-dark rounded-card p-6 flex flex-col">
<span class="inline-block text-small font-medium text-gosign-accent-on-dark bg-white/10 rounded-full px-3 py-1 mb-4 w-fit">Gratuito, en el navegador, sin registro</span>
<h2 class="text-h3 font-bold text-white mb-2">Control de codecisión</h2>
<p class="text-body text-white/70 mb-4 flex-1">¿Necesita aprobación del comité de empresa? 5 preguntas basadas en la legislación de codecisión aplicable con una recomendación clara.</p>
<a href="/es/governance/co-determination/" class="inline-flex items-center gap-2 text-gosign-accent-on-dark hover:text-white font-medium">Ir al control de codecisión &rarr;</a>
</div>

<div class="bg-gosign-dark rounded-card p-6 flex flex-col">
<span class="inline-block text-small font-medium text-gosign-accent-on-dark bg-white/10 rounded-full px-3 py-1 mb-4 w-fit">Gratuito, en el navegador, sin registro</span>
<h2 class="text-h3 font-bold text-white mb-2">Herramienta de comparación de agentes</h2>
<p class="text-body text-white/70 mb-4 flex-1">Compare 2-3 agentes AI en paralelo. Costes, nivel de automatización, requisitos de governance y esfuerzo de implementación de un vistazo.</p>
<a href="/es/catalogo-agentes-hr/" class="inline-flex items-center gap-2 text-gosign-accent-on-dark hover:text-white font-medium">Ir al catálogo HR &rarr;</a>
</div>

<div class="bg-gosign-dark rounded-card p-6 flex flex-col">
<span class="inline-block text-small font-medium text-gosign-accent-on-dark bg-white/10 rounded-full px-3 py-1 mb-4 w-fit">Gratuito, en el navegador, sin registro</span>
<h2 class="text-h3 font-bold text-white mb-2">Workforce Planner</h2>
<p class="text-body text-white/70 mb-4 flex-1">Planificación de personal con vs. sin agentes AI. Basado en benchmarks SHRM y Hackett. Muestra ahorros de FTE y ganancias de productividad.</p>
<a href="/es/catalogo-agentes-hr/" class="inline-flex items-center gap-2 text-gosign-accent-on-dark hover:text-white font-medium">Ir al catálogo HR &rarr;</a>
</div>

<div class="bg-gosign-dark rounded-card p-6 flex flex-col">
<span class="inline-block text-small font-medium text-gosign-accent-on-dark bg-white/10 rounded-full px-3 py-1 mb-4 w-fit">Gratuito, en el navegador, sin registro</span>
<h2 class="text-h3 font-bold text-white mb-2">Calculadora TCO</h2>
<p class="text-body text-white/70 mb-4 flex-1">Proyección de costes a 3 años para infraestructura AI. Build vs. Buy vs. Hybrid. Costes de licencia, implementación, operación continua.</p>
<a href="/es/servicios/infraestructura/" class="inline-flex items-center gap-2 text-gosign-accent-on-dark hover:text-white font-medium">Ir al servicio de infraestructura &rarr;</a>
</div>

<div class="bg-gosign-dark rounded-card p-6 flex flex-col">
<span class="inline-block text-small font-medium text-gosign-accent-on-dark bg-white/10 rounded-full px-3 py-1 mb-4 w-fit">Gratuito, en el navegador, sin registro</span>
<h2 class="text-h3 font-bold text-white mb-2">Calculadora ROI rápida</h2>
<p class="text-body text-white/70 mb-4 flex-1">Cálculo rápido de ahorros para procesos de HR, Finance y Travel. Entrada: volumen de casos, tiempo por caso, tarifa horaria. Resultado: potencial de ahorro anual.</p>
<a href="/es/catalogo-agentes-hr/" class="inline-flex items-center gap-2 text-gosign-accent-on-dark hover:text-white font-medium">Ir al catálogo HR &rarr;</a>
</div>

<div class="bg-gosign-dark rounded-card p-6 flex flex-col">
<span class="inline-block text-small font-medium text-gosign-accent-on-dark bg-white/10 rounded-full px-3 py-1 mb-4 w-fit">Gratuito, en el navegador, sin registro</span>
<h2 class="text-h3 font-bold text-white mb-2">Readiness Assessment</h2>
<p class="text-body text-white/70 mb-4 flex-1">Test online de 7 preguntas con gráfico radar. Evalúe su organización en madurez de procesos, datos, governance, IT y gestión del cambio.</p>
<a href="/es/hr-agent-readiness/" class="inline-flex items-center gap-2 text-gosign-accent-on-dark hover:text-white font-medium">Ir al Readiness Assessment &rarr;</a>
</div>

</div>
</section>

--- Enterprise AI Agents - En su infraestructura. Bajo su control. ---
> Enterprise AI Agent Infrastructure para HR, Finance e IT. Decisiones LLM auditables, Governance by Design, agnóstico de modelo.

<!-- Enterprise AI Infrastructure & Agent Engineering -->
<section class="scroll-reveal py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex flex-col lg:flex-row lg:items-start lg:gap-12">
<div class="lg:w-[55%]">
<h2 class="text-h1 font-bold text-gosign-dark">
Enterprise AI Infrastructure & Agent Engineering
</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Gosign es una Enterprise AI Infrastructure & Agent Engineering Company. Desarrollamos y operamos la infraestructura que hace que los AI Agents funcionen en producción dentro de las empresas: orquestación, governance, Decision Layer y auditoría.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
25 años de desarrollo de software. Hasta 108 empleados. Más de 5.000 proyectos para Airbus, Volkswagen, Shell. Desde 2024 enfocados en Enterprise AI Agent Engineering.
</p>
</div>
<div class="lg:w-[45%] mt-8 lg:mt-0 flex justify-center">
<img
src="/images/7-layer-architecture-v2.svg"
alt="Arquitectura Gosign de 7 capas para Enterprise AI: Presentation Layer (Chat UI, Dashboard, API), Orchestration Layer (Trigger.dev, Camunda), Agent Layer (Document, Workflow, Knowledge Agents), Governance Layer como capa transversal (Audit Trail, RBAC, Decision Layer, Cert-Ready Controls), Model Layer (Claude, GPT, Gemini, Llama, Mistral, DeepSeek - agnóstico de modelo), Integration Layer (SAP, ERP, Microsoft Graph), Infrastructure Layer (Azure UE, GCP UE, AWS UE, Self-Hosted, Hybrid)"
width="500"
height="400"
class="w-full max-w-md"
loading="lazy"
/>
</div>
</div>
</div>
</section>

<!-- Por qué la mayoría de los proyectos de IA no generan beneficios medibles -->
<section class="scroll-reveal py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Por qué la mayoría de los proyectos de IA no generan beneficios medibles</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
La mayoría de las empresas ya utilizan IA. Muy pocas obtienen beneficios medibles con ella. No porque la tecnología no funcione, sino porque nadie ha definido qué decisiones puede tomar la IA de forma autónoma y cuáles deben permanecer en manos humanas.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
La experiencia sectorial muestra: por cada euro invertido en tecnología, se necesitan cuatro a cinco euros en procesos, governance y gestión del cambio. Quien solo invierte en tecnología, invierte al margen del problema.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
El <a href="/es/decision-layer/" class="text-gosign-accent-text hover:underline font-semibold">Decision Layer</a> es la capa que marca esta diferencia: descompone cada proceso de negocio en pasos de decisión individuales y define para cada paso - humano, conjunto de reglas o IA. Así, un experimento de IA se convierte en un sistema productivo.
</p>
</div>
</div>
</section>

<!-- AI Agents para su departamento -->
<section class="scroll-reveal py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">AI Agents para su departamento</h2>
<div class="grid grid-cols-1 gap-6 lg:gap-8 lg:grid-cols-3">
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 hover:shadow-lg hover:-translate-y-0.5 transition-all duration-200">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<img src="/images/icon-finance.svg" alt="" class="w-10 h-10" width="40" height="40" />
</div>
<h3 class="text-h3 font-bold text-gosign-dark">AI Agents para Finance & Auditoría</h3>
<p class="text-body text-gosign-text-light mt-3">Decision Automation para procesamiento de documentos, contabilización y preparación de auditoría. Reglas versionadas, pista de auditoría completa, Cert-Ready by Design. El <a href='/es/decision-layer/' class='text-gosign-accent-text hover:underline'>Decision Layer</a> hace cada decisión contable trazable.</p>
<a href="/es/finance-ai-agents/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
Finance AI Agents
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 hover:shadow-lg hover:-translate-y-0.5 transition-all duration-200">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<img src="/images/icon-hr.svg" alt="" class="w-10 h-10" width="40" height="40" />
</div>
<h3 class="text-h3 font-bold text-gosign-dark">AI Agents para HR & People Operations</h3>
<p class="text-body text-gosign-text-light mt-3">AI Agents auditables para decisiones de RRHH. Preparado para comités de empresa. Decision Layer con Human-in-the-Loop. Nómina, onboarding, procesamiento de documentos, políticas y conocimiento.</p>
<a href="/es/hr-ai-agents/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
HR AI Agents
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 hover:shadow-lg hover:-translate-y-0.5 transition-all duration-200">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<img src="/images/icon-infrastructure.svg" alt="" class="w-10 h-10" width="40" height="40" />
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Infraestructura AI para IT & Enterprise</h3>
<p class="text-body text-gosign-text-light mt-3">Hosting LLM, RAG, orquestación. Self-hosted, nube o híbrido. Agnóstico de modelo, Governance by Design, Cert-Ready by Design. La plataforma en la que sus agents operan en producción.</p>
<a href="/es/servicios/infraestructura/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
Infraestructura
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</article>
</div>
</div>
</section>

<!-- Tres tipos de agentes -->
<section class="scroll-reveal py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 space-y-12">
<h2 class="text-h1 font-bold text-gosign-dark">Agents especializados para procesos Enterprise</h2>
<article class="flex flex-col lg:flex-row gap-8 lg:gap-12 items-start">
<div class="flex-shrink-0 w-16 h-16 lg:w-20 lg:h-20 rounded-full bg-gosign-accent/10 flex items-center justify-center">
<span class="text-h1 lg:text-hero font-bold text-gosign-accent-text">01</span>
</div>
<div class="flex-1 lg:w-[55%]">
<h3 class="text-h2 font-bold text-gosign-dark">Document Agents</h3>
<p class="text-body-lg text-gosign-text-light mt-3">El especialista: comprende documentos. Llega una baja médica. El agente identifica el tipo de documento, extrae nombre, período y código de diagnóstico, comprueba si todos los campos obligatorios están presentes y asigna el documento al empleado correcto. No es coincidencia de plantillas - comprensión lingüística real: distingue una baja médica de un certificado de incapacidad, aunque ambos provengan del mismo médico. El Decision Layer evalúa cada extracción: ¿determinista? Conjunto de reglas. ¿Suficientemente confiable? El agente decide de forma autónoma. ¿Se requiere discrecionalidad? Revisión humana.</p>
<a href="/es/servicios/ai-agents/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
Document Agents en detalle
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</div>
<div class="lg:w-[40%] mt-4 lg:mt-11">
<img src="/images/flow-document-agent-v10-es.svg" alt="Document Agent - El Especialista: Un documento entra, el agente comprende tipo, contenido y contexto, Decision Layer dirige por tres niveles (reglas, autonomía IA, revisión humana), datos estructurados salen." class="w-full" width="480" height="620" loading="lazy" />
</div>
</article>
<article class="flex flex-col lg:flex-row gap-8 lg:gap-12 items-start">
<div class="flex-shrink-0 w-16 h-16 lg:w-20 lg:h-20 rounded-full bg-gosign-accent/10 flex items-center justify-center">
<span class="text-h1 lg:text-hero font-bold text-gosign-accent-text">02</span>
</div>
<div class="flex-1 lg:w-[55%]">
<h3 class="text-h2 font-bold text-gosign-dark">Workflow Agents</h3>
<p class="text-body-lg text-gosign-text-light mt-3">El coordinador: dirige todo el proceso. La baja médica está comprendida - ¿y ahora? El Workflow Agent toma el control: comprueba en el sistema de RR.HH. si es la tercera notificación en seis meses, verifica contra el convenio colectivo si se ha alcanzado el umbral de reincorporación, crea una tarea para el responsable de RR.HH. en SAP SuccessFactors, informa al Comité de Empresa y programa un seguimiento. Cinco sistemas, tres puntos de decisión, un agente que coordina todo el proceso - incluyendo decisiones de routing independientes cuando la confianza es suficiente. Cada paso en la auditoría.</p>
<a href="/es/servicios/ai-agents/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
Workflow Agents en detalle
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</div>
<div class="lg:w-[40%] mt-4 lg:mt-11">
<img src="/images/flow-workflow-agent-v10-es.svg" alt="Workflow Agent - El Coordinador: Dirige un proceso multietapa entre sistemas. Llama a Document Agents, verifica contra reglas, crea tareas en SAP, informa al Comité de Empresa, programa seguimientos. Cada paso en la auditoría." class="w-full" width="480" height="542" loading="lazy" />
</div>
</article>
<article class="flex flex-col lg:flex-row gap-8 lg:gap-12 items-start">
<div class="flex-shrink-0 w-16 h-16 lg:w-20 lg:h-20 rounded-full bg-gosign-accent/10 flex items-center justify-center">
<span class="text-h1 lg:text-hero font-bold text-gosign-accent-text">03</span>
</div>
<div class="flex-1 lg:w-[55%]">
<h3 class="text-h2 font-bold text-gosign-dark">Knowledge Agents</h3>
<p class="text-body-lg text-gosign-text-light mt-3">El portador de conocimiento: responde preguntas del conocimiento empresarial. Un responsable de RR.HH. pregunta: '¿Cuándo debe iniciarse un proceso de reincorporación tras una baja prolongada?' El agente no solo busca - interpreta políticas internas, convenio colectivo y requisitos normativos en el contexto de la pregunta, entregando una respuesta específica con referencia de fuente, versión de regla y fecha de validez. Cuando hay incertidumbre, la señala explícitamente. Sin fuente verificada, el agente no responde - sin alucinaciones.</p>
<a href="/es/servicios/ai-agents/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
Knowledge Agents en detalle
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</div>
<div class="lg:w-[40%] mt-4 lg:mt-11">
<img src="/images/flow-knowledge-agent-v10-es.svg" alt="Knowledge Agent - El Portador de Conocimiento: Pregunta con contexto entra, el agente interpreta fuentes verificadas, respuesta específica con fuente y versión sale. Incertidumbre: la señala. Sin fuente: sin respuesta." class="w-full" width="480" height="628" loading="lazy" />
</div>
</article>
</div>
</section>

<!-- Comparación de arquitecturas -->
<section class="scroll-reveal py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Comparación de arquitecturas: Copilot, SaaS Agent, Gosign</h2>
<p class="text-body-lg text-gosign-text-light mb-8">Tres enfoques para AI empresarial - diferentes arquitecturas, diferentes consecuencias.</p>
<div class="overflow-x-auto -mx-4 sm:mx-0">
<table class="w-full min-w-[36rem] border-collapse text-small">
<thead>
<tr>
<th class="px-4 py-3 text-left font-semibold bg-gosign-dark text-white">Dimensión</th>
<th class="px-4 py-3 text-left font-semibold bg-gosign-dark text-white border-t-[3px] border-t-gosign-accent">Gosign Agent Architecture</th>
<th class="px-4 py-3 text-left font-semibold bg-gosign-dark text-white">Microsoft Copilot</th>
<th class="px-4 py-3 text-left font-semibold bg-gosign-dark text-white">SaaS AI Agent</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Profundidad de decisión</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border bg-gosign-accent/5">Decisiones de dominio con Decision Layer</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Asistencia y sugerencias</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Workflows preconfigurados</td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Auditabilidad</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border bg-gosign-accent/5">Pista de auditoría completa hasta nivel SQL</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Logging básico</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Logging de plataforma</td>
</tr>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Acceso al código</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border bg-gosign-accent/5">Acceso completo al código fuente · Configuraciones con el cliente · Sin vendor lock-in</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Microsoft posee el código</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Plataforma posee el código</td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Elección de modelo</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border bg-gosign-accent/5">Agnóstico (GPT, Claude, Gemini, Llama, Mistral)</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">GPT (ligado a Microsoft)</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Ligado a plataforma</td>
</tr>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Governance</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border bg-gosign-accent/5">Governance Layer propio, Cert-Ready Controls, Portal de Auditor</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Azure governance</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Governance de plataforma</td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Human-in-the-Loop</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border bg-gosign-accent/5">Arquitectónicamente forzado en decisiones de riesgo</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Opcional</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Configurable</td>
</tr>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">EU AI Act</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border bg-gosign-accent/5">Compliant by design - transparencia, explicabilidad, supervisión integradas</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Roadmap de Microsoft</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Dependiente del proveedor</td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Comité de Empresa / Codecisión</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border bg-gosign-accent/5">Plantillas, logging, conceptos de roles para comités de empresa</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Sin soporte específico</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Sin soporte específico</td>
</tr>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Infraestructura</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border bg-gosign-accent/5">Infraestructura del cliente (Azure, GCP, AWS, self-hosted, híbrido)</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Microsoft Cloud</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Nube del proveedor</td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Estrategia de salida</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border bg-gosign-accent/5">Operación independiente tras 12-18 meses</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Migración de plataforma</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Migración de plataforma</td>
</tr>
</tbody>
</table>
</div>
<p class="text-small text-gosign-text-light italic mt-4">
Esta tabla muestra diferencias arquitectónicas, no juicios de calidad. Copilot y los agentes SaaS tienen otras fortalezas - velocidad, ecosistema, simplicidad. La fortaleza de Gosign es governance, propiedad y auditabilidad en entornos regulados.
</p>
</div>
</section>

<!-- Governance by Design -->
<section class="scroll-reveal bg-gosign-dark text-white py-section">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold">Governance by Design</h2>
<p class="text-h3 text-gosign-accent-on-dark font-semibold mt-4">
Los agents solo escalan con infraestructura. Sin governance, la AI sigue siendo un piloto - con infraestructura, se vuelve escalable.
</p>
<div class="mt-8 space-y-4">
<p class="text-body-lg text-gosign-text-on-dark/80 flex items-start gap-3">
<svg class="w-5 h-5 mt-1 flex-shrink-0 text-gosign-accent-on-dark" fill="currentColor" viewBox="0 0 20 20"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span>Human-in-the-Loop: no es una barrera general, sino control arquitectónico. Alta confianza y bajo riesgo: decisión autónoma. Riesgo de sesgo o materias sujetas a consulta del comité de empresa: decide el humano.</span>
</p>
<p class="text-body-lg text-gosign-text-on-dark/80 flex items-start gap-3">
<svg class="w-5 h-5 mt-1 flex-shrink-0 text-gosign-accent-on-dark" fill="currentColor" viewBox="0 0 20 20"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span>Auditable: cada decisión del agente produce un registro completo: entrada, modelo, evaluación, puntuación de confianza, razonamiento, ruta de decisión, resultado. Inmutable, exportable, listo para auditoría.</span>
</p>
<p class="text-body-lg text-gosign-text-on-dark/80 flex items-start gap-3">
<svg class="w-5 h-5 mt-1 flex-shrink-0 text-gosign-accent-on-dark" fill="currentColor" viewBox="0 0 20 20"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span>Cert-Ready by Design: los controles son objetos de datos de primera clase en el sistema. Cada control tiene una implementación técnica, un generador automático de evidencia y un historial de evidencia.</span>
</p>
<p class="text-body-lg text-gosign-text-on-dark/80 flex items-start gap-3">
<svg class="w-5 h-5 mt-1 flex-shrink-0 text-gosign-accent-on-dark" fill="currentColor" viewBox="0 0 20 20"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span>EU AI Act compliant by design - transparencia, explicabilidad y supervisión humana están integradas arquitectónicamente - no añadidas después.</span>
</p>
</div>
</div>
<div class="mt-12 overflow-x-auto -mx-4 sm:mx-0 px-4 sm:px-0">
<img src="/images/diagrams/decision-layer-drei-arten-es.svg" alt="Tres niveles de autonomía en el Gosign Decision Layer: (1) Humano decide - el agente proporciona datos para ajustes salariales, despidos, traslados, decisiones con riesgo de sesgo, temas de comité de empresa (aprox. 35% de procesos HR). (2) Agente trabaja, humano revisa - en procesamiento de documentos, revisión de contratos, pasos de onboarding, creación de referencias, screening de reclutamiento (aprox. 40% de procesos HR). (3) Agente autónomo - en respuestas FAQ, certificados estándar, verificación de plazos, validación de datos, notificaciones rutinarias (aprox. 25% de procesos HR). Cada decisión documentada, cada paso auditable." width="900" height="360" class="w-full min-w-[600px] max-w-4xl mx-auto rounded-lg" loading="lazy" />
</div>
</div>
</section>

<!-- Definición: Decision Layer -->
<section class="scroll-reveal py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h3 class="text-h3 font-bold text-gosign-dark">Definición: Decision Layer</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
El Decision Layer descompone cada proceso de negocio en pasos de decisión individuales y define de antemano para cada paso: ¿Decide un humano, un conjunto de reglas o la IA de forma autónoma?
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Donde la discrecionalidad, el riesgo de discriminación o el derecho de consulta del comité de empresa (Art. 64 ET) juegan un papel, la arquitectura impone la revisión humana. Donde una decisión es determinista - convenio colectivo, verificación de plazos, lógica contable - el agente aplica el conjunto de reglas de forma consistente. Y donde el agente tiene suficiente confianza y el permiso: decide de forma autónomo.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Cada decisión queda documentada - quién decidió qué, cuándo, sobre qué base y con qué resultado. Verificable por auditores, comités de empresa y revisión interna.
</p>
<p class="mt-4">
<a href="/es/governance/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Governance, seguridad y auditoría</a>
</p>
</div>
</div>
</section>

<!-- Del PoC a la Plataforma -->
<section class="scroll-reveal py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark text-center">Del PoC a la Plataforma</h2>
<div class="mt-12 grid grid-cols-1 md:grid-cols-3 gap-8 relative">
<div class="text-center">
<div class="w-14 h-14 mx-auto rounded-full bg-gosign-accent flex items-center justify-center">
<span class="text-h3 font-bold text-white">1</span>
</div>
<h3 class="text-h3 font-bold text-gosign-dark mt-4">Discover</h3>
<p class="text-small font-semibold text-gosign-accent-text mt-1">1 semana</p>
<p class="text-body text-gosign-text-light mt-2">Análisis de procesos, mapeo de reglas, evaluación del panorama de sistemas, priorización de casos de uso. Resultado: un plan concreto para su primer agente.</p>
</div>
<div class="text-center">
<div class="w-14 h-14 mx-auto rounded-full bg-gosign-accent flex items-center justify-center">
<span class="text-h3 font-bold text-white">2</span>
</div>
<h3 class="text-h3 font-bold text-gosign-dark mt-4">Build</h3>
<p class="text-small font-semibold text-gosign-accent-text mt-1">3-4 semanas</p>
<p class="text-body text-gosign-text-light mt-2">PoC en producción. Un agente, un proceso, en vivo en su infraestructura. Decision Layer, governance, pista de auditoría - desde el primer día.</p>
</div>
<div class="text-center">
<div class="w-14 h-14 mx-auto rounded-full bg-gosign-accent flex items-center justify-center">
<span class="text-h3 font-bold text-white">3</span>
</div>
<h3 class="text-h3 font-bold text-gosign-dark mt-4">Scale</h3>
<p class="text-small font-semibold text-gosign-accent-text mt-1">Continuo</p>
<p class="text-body text-gosign-text-light mt-2">Más agentes, más departamentos, más ubicaciones. La arquitectura crece con sus requerimientos. Mismo governance, misma infraestructura.</p>
</div>
</div>
<p class="text-body-lg text-center text-gosign-text-light mt-8 max-w-narrow mx-auto">
Tras 12-18 meses, usted opera sus agents de forma independiente. Acceso completo al código fuente, prompts y configuraciones. Sin vendor lock-in - incluso sin contrato de mantenimiento.
</p>
</div>
</section>

--- HR Agent - AI Agents para RRHH y People Operations ---
> 6 AI Agents para RRHH: Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Decision Layer con Audit Trail. Compatible con comité de empresa.

<div class="bg-gosign-dark/5 border-y border-gosign-border"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4"><div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6"><a href="/es/por-que-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity"><svg class="w-6 h-6 text-gosign-accent-on-dark flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg><div><p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p><p class="text-xs text-gosign-text-light">Cada decisión rastreable</p></div></a><a href="/es/por-que-gosign/#infraestructura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity"><svg class="w-6 h-6 text-gosign-accent-on-dark flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg><div><p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Su infraestructura</p><p class="text-xs text-gosign-text-light">Sin SaaS. Sin vendor lock-in.</p></div></a><a href="/es/por-que-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity"><svg class="w-6 h-6 text-gosign-accent-on-dark flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg><div><p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p><p class="text-xs text-gosign-text-light">Sin riesgo de cloud estadounidense</p></div></a></div></div></div>

<section class="py-section bg-gosign-light"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><h2 class="text-h1 font-bold text-gosign-dark">Portfolio HR Agent</h2><p class="text-body-lg text-gosign-text-light mt-4 mb-8 max-w-narrow">Un HR Agent no automatiza de forma genérica, sino que descompone procesos en micro-decisiones. Para cada decisión, el <a href="/es/decision-layer/" class="text-gosign-accent-text hover:text-gosign-accent-hover">Decision Layer</a> define: humano, conjunto de reglas o IA.</p><div class="grid grid-cols-1 md:grid-cols-2 lg:grid-cols-3 gap-6"><a href="/es/servicios/hr-agent/payroll-decision-layer/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white"><h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Payroll Decision Layer</h3><p class="text-body text-gosign-text-light mt-2">Convenios colectivos, complementos de turno, pagas extra. 4 simulaciones sectoriales.</p><p class="text-body font-semibold text-gosign-dark mt-3">82-92% Zero-Touch</p></a><a href="/es/servicios/travel-decision-layer/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white"><h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Travel Decision Layer</h3><p class="text-body text-gosign-text-light mt-2">Cada liquidación de gastos de viaje en 5-12 pasos de decisión auditables.</p><p class="text-body font-semibold text-gosign-dark mt-3">>80% reducción de coste por recibo</p></a><a href="/es/recruiting-agent/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white"><h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Recruiting Agent</h3><p class="text-body text-gosign-text-light mt-2">Screening, programación, comunicación estándar. EU AI Act alto riesgo.</p><p class="text-body font-semibold text-gosign-dark mt-3">70-75% automatización</p></a><a href="/es/servicios/hr-agent/leave-absence-decision-layer/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white"><h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Leave & Absence Decision Layer</h3><p class="text-body text-gosign-text-light mt-2">Derechos de vacaciones, reglas de ausencia, obligaciones de reincorporación. 4 simulaciones sectoriales.</p><p class="text-body font-semibold text-gosign-dark mt-3">78-87% Zero-Touch</p></a><div class="border border-gosign-border rounded-card p-6 bg-gosign-light/50"><div class="flex items-center justify-between mb-3"><span class="inline-flex items-center px-2.5 py-0.5 text-xs font-bold text-white bg-gosign-accent rounded-full">Coming</span></div><h3 class="text-h3 font-bold text-gosign-dark">Employee Lifecycle Decision Layer</h3><p class="text-body text-gosign-text-light mt-2">Onboarding, traslados internos, offboarding en un pipeline auditable.</p></div><div class="border border-gosign-border rounded-card p-6 bg-gosign-light/50"><div class="flex items-center justify-between mb-3"><span class="inline-flex items-center px-2.5 py-0.5 text-xs font-bold text-white bg-gosign-accent rounded-full">Coming</span></div><h3 class="text-h3 font-bold text-gosign-dark">Candidate Screening Decision Layer</h3><p class="text-body text-gosign-text-light mt-2">EU AI Act alto riesgo. Monitorización de sesgo. Participación del comité de empresa.</p></div></div></div></section>

<!-- Start Boring -->
<section class="py-section bg-gosign-light"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Por qué debería empezar con procesos aburridos</h2>
<p class="text-body-lg text-gosign-text-light mt-4">Los agentes HR más efectivos no automatizan los procesos más espectaculares - sino los más repetitivos. Payroll, control horario, ausencias estándar: alta densidad de reglas, bajo riesgo, ROI medible desde el día 1. La infraestructura de governance que construye en el proceso es el requisito previo para agentes más complejos.</p>
</div></div></section>

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">eBook gratuito: IA en RRHH</p>
<p class="text-body text-gosign-text mb-4">Checklist del EU AI Act, Decision Framework, perspectiva del comité de empresa y evaluación de preparación - el manual de gobernanza para RRHH.</p>
<a href="/es/ebook/ia-rrhh-manual-gobernanza/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Descargar gratis</a>
</div>

<section class="py-section bg-gosign-white"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow"><h2 class="text-h1 font-bold text-gosign-dark">Cómo trabaja un HR Agent</h2><p class="text-body-lg text-gosign-text-light mt-4">Cada proceso de RRHH consta de docenas de decisiones individuales. El agent verifica contra todos los criterios del convenio colectivo - más consistente que cualquier especialista. Donde el Estatuto de los Trabajadores, el comité de empresa o el riesgo de discriminación lo exigen, decide un humano.</p><h3 class="text-h3 font-bold text-gosign-dark mt-10">Procesamiento de baja por enfermedad</h3><div class="mt-4 overflow-x-auto"><table class="w-full text-left text-body"><thead><tr class="border-b-2 border-gosign-dark"><th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Micro-decisión</th><th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Quién decide</th><th scope="col" class="py-3 font-bold text-gosign-dark">Por qué</th></tr></thead><tbody class="text-gosign-text-light"><tr class="border-b border-gosign-border"><td class="py-3 pr-4">Verificar periodo de prestación por IT</td><td class="py-3 pr-4 font-medium">AI autónomo</td><td class="py-3">Verifica TODOS los criterios del convenio colectivo - más consistente que cualquier especialista</td></tr><tr class="border-b border-gosign-border"><td class="py-3 pr-4">Evaluar obligación de reincorporación (&gt; 6 sem. en 12 meses)</td><td class="py-3 pr-4 font-medium">Humano</td><td class="py-3">El comité de empresa requiere Human-in-the-Loop, riesgo de discriminación</td></tr><tr class="border-b border-gosign-border"><td class="py-3 pr-4">Informar al responsable sobre la ausencia</td><td class="py-3 pr-4 font-medium">AI autónomo</td><td class="py-3">Información consistente - solo ausencia y duración, sin diagnóstico</td></tr></tbody></table></div><h3 class="text-h3 font-bold text-gosign-dark mt-10">Onboarding</h3><div class="mt-4 overflow-x-auto"><table class="w-full text-left text-body"><thead><tr class="border-b-2 border-gosign-dark"><th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Micro-decisión</th><th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Quién decide</th><th scope="col" class="py-3 font-bold text-gosign-dark">Por qué</th></tr></thead><tbody class="text-gosign-text-light"><tr class="border-b border-gosign-border"><td class="py-3 pr-4">Clasificación profesional en el convenio colectivo</td><td class="py-3 pr-4 font-medium">Humano</td><td class="py-3">El comité de empresa tiene derecho de información y consulta en la clasificación profesional (Art. 64 ET)</td></tr><tr class="border-b border-gosign-border"><td class="py-3 pr-4">Accesos y permisos de TI</td><td class="py-3 pr-4 font-medium">Reglas + AI</td><td class="py-3">Permisos estándar automáticos, accesos especiales escalados</td></tr><tr class="border-b border-gosign-border"><td class="py-3 pr-4">Crear plan de incorporación</td><td class="py-3 pr-4 font-medium">AI + Humano</td><td class="py-3">La AI crea la propuesta, el responsable la revisa y ajusta</td></tr></tbody></table></div><h3 class="text-h3 font-bold text-gosign-dark mt-10">Generación de certificados de trabajo</h3><div class="mt-4 overflow-x-auto"><table class="w-full text-left text-body"><thead><tr class="border-b-2 border-gosign-dark"><th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Micro-decisión</th><th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Quién decide</th><th scope="col" class="py-3 font-bold text-gosign-dark">Por qué</th></tr></thead><tbody class="text-gosign-text-light"><tr class="border-b border-gosign-border"><td class="py-3 pr-4">Generar descripción de funciones</td><td class="py-3 pr-4 font-medium">AI</td><td class="py-3">Basado en la descripción del puesto, propuesta para revisión</td></tr><tr class="border-b border-gosign-border"><td class="py-3 pr-4">Formular la evaluación del desempeño</td><td class="py-3 pr-4 font-medium">Humano</td><td class="py-3">Valoración individual, responsabilidad del superior</td></tr><tr class="border-b border-gosign-border"><td class="py-3 pr-4">Verificar la conformidad legal</td><td class="py-3 pr-4 font-medium">AI + Humano</td><td class="py-3">La AI verifica contra patrones de redacción y marca riesgos, el humano decide al final</td></tr></tbody></table></div><p class="text-body-lg text-gosign-text-light mt-8"><strong>El patrón:</strong> Rutina y reglas se automatizan. Decisiones discrecionales y legalmente sensibles permanecen en manos humanas. Cada paso documentado.</p><p class="mt-4"><a href="/es/decision-layer/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Más sobre el Decision Layer &rarr;</a></p></div></div></section>

<section class="py-section bg-gosign-light"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow"><h2 class="text-h1 font-bold text-gosign-dark">Decision Layer: cada decisión auditable</h2><p class="text-body-lg text-gosign-text-light mt-4">El <a href="/es/decision-layer/" class="text-gosign-accent-text hover:text-gosign-accent-hover">Decision Layer</a> descompone cada proceso de RRHH en pasos de decisión individuales y define para cada paso: ¿Decide un humano, un conjunto de reglas o la IA?</p><div class="mt-6 bg-gosign-white border border-gosign-border rounded-card p-6"><p class="text-body font-mono text-gosign-dark">Input &rarr; Modelo &rarr; Evaluación &rarr; Confidence Score &rarr; Justificación &rarr; Ruta de decisión &rarr; Resultado</p></div><p class="text-body-lg text-gosign-text-light mt-4">Cada decisión genera un registro completo: entrada, regla, versión, confianza, resultado, marca temporal. Verificable para el comité de empresa, auditores y compliance interno. Conforme al RGPD y la LOPDGDD.</p></div></div></section>

<section class="py-section bg-gosign-white"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow"><h2 class="text-h1 font-bold text-gosign-dark">Governance y representación de los trabajadores</h2><h3 class="text-h3 font-bold text-gosign-dark mt-8">Human-in-the-Loop como principio arquitectónico</h3><p class="text-body-lg text-gosign-text-light mt-4">No como un bucle de aprobación opcional, sino como enrutamiento impuesto arquitectónicamente. Decisión autónoma en alta confianza y bajo riesgo. Human-in-the-Loop en riesgo de sesgo, potencial de discriminación y temas del comité de empresa.</p><p class="text-body-lg text-gosign-text-light mt-4"><a href="/es/governance/co-determination/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Derecho de consulta en detalle &rarr;</a></p><h3 class="text-h3 font-bold text-gosign-dark mt-8">Audit Trail</h3><p class="text-body-lg text-gosign-text-light mt-4">Cada decisión del agent genera un registro de decisión completo: entrada, regla, versión, confianza, ruta de decisión, resultado, marca temporal. El comité de empresa puede verificar todas las decisiones a través del portal de auditoría. Cómo los comités de empresa pasan de bloqueadores a facilitadores lo describe el <a href="/es/revista/comite-empresa-ai-literacy/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Artículo 9 del Blueprint 2026</a>.</p><h3 class="text-h3 font-bold text-gosign-dark mt-8">EU AI Act Readiness</h3><p class="text-body-lg text-gosign-text-light mt-4">El EU AI Act aplica plenamente en España. La AESIA supervisa el cumplimiento. La arquitectura aborda transparencia (Art. 13), supervisión humana (Art. 14), obligaciones de registro (Art. 12) y gestión de riesgos (Art. 9) como principio de diseño.</p><p class="text-body-lg text-gosign-text-light mt-4"><a href="/es/governance/eu-ai-act/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">EU AI Act Readiness &rarr;</a></p></div></div></section>

<section class="py-section bg-gosign-light"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow"><h2 class="text-h1 font-bold text-gosign-dark">Integración en su infraestructura existente</h2><p class="text-body-lg text-gosign-text-light mt-4">Los AI Agents no sustituyen sistemas. SAP SuccessFactors sigue siendo su HCM, Workday sigue siendo su plataforma HR, SAP FI/CO sigue siendo su ERP. La lógica del agent está desacoplada del sistema destino - a través de interfaces estandarizadas. Sin proyecto de migración, sin cambio de sistema. Un proceso, un sistema, un agent.</p></div></div></section>

<section class="py-section bg-gosign-dark text-white"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><h2 class="text-h1 font-bold">Del PoC a la plataforma</h2><div class="grid md:grid-cols-3 gap-8 mt-8"><div><p class="text-xs font-bold uppercase tracking-wider text-gosign-accent-on-dark">Discover - 1 semana</p><p class="text-body-lg text-gosign-text-on-dark/80 mt-2">Análisis de procesos, comprensión de convenios colectivos, priorización de casos de uso.</p></div><div><p class="text-xs font-bold uppercase tracking-wider text-gosign-accent-on-dark">Build - 3-4 semanas</p><p class="text-body-lg text-gosign-text-on-dark/80 mt-2">PoC productivo. Un agent, un proceso, en producción en su infraestructura con Decision Layer y Audit Trail.</p></div><div><p class="text-xs font-bold uppercase tracking-wider text-gosign-accent-on-dark">Scale - Continuo</p><p class="text-body-lg text-gosign-text-on-dark/80 mt-2">Más agents, más procesos. Mismo governance, misma auditabilidad. Tras 12-18 meses usted opera sus agents de forma independiente.</p></div></div></div></section>

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">HR Agent Readiness Assessment</p>
<p class="text-body text-gosign-text mb-4">7 preguntas, 3 minutos: ¿Cómo de preparada está su organización de RRHH para AI Agents?</p>
<a href="/es/hr-agent-readiness/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Iniciar assessment &rarr;</a>
</div>

<!-- Catálogo de agentes HR -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex flex-col md:flex-row items-start gap-8">
<div class="flex-1">
<h2 class="text-h2 font-bold text-gosign-dark">Catálogo de agentes HR: 48 agentes evaluados y priorizados</h2>
<p class="text-body-lg text-gosign-text mt-4">¿Qué agentes HR existen, qué governance necesitan y en qué orden debería empezar? El catálogo evalúa 48 agentes en 6 dimensiones - desde Agent Readiness hasta clasificación EU AI Act.</p>
<p class="text-body text-gosign-text-light mt-3">11 dominios, 3 cuadrantes interactivos de priorización, tablas de micro-decisiones para cada agente.</p>
<a href="/es/catalogo-agentes-hr/" class="inline-flex items-center gap-2 mt-4 text-body font-semibold text-gosign-accent hover:underline">Al catálogo de agentes HR &rarr;</a>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><h2 class="text-h2 font-bold text-gosign-dark mb-8">Profundización en el Agent Briefing (Revista Gosign)</h2><div class="grid md:grid-cols-3 gap-6"><a href="/es/revista/comite-empresa-ai-literacy/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors"><p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p><h3 class="text-h3 font-bold text-gosign-dark">Comité de Empresa & AI Literacy</h3></a><a href="/es/revista/decision-layer-shadow-ai/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors"><p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p><h3 class="text-h3 font-bold text-gosign-dark">Decision Layer & Shadow AI</h3></a><a href="/es/revista/eu-ai-act-2026-empresas/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors"><p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p><h3 class="text-h3 font-bold text-gosign-dark">EU AI Act 2026</h3></a></div></div></section>

--- Metodología Decision Layer ---
> Cómo Gosign clasifica las decisiones de los agentes, calcula ahorros y verifica fuentes - de forma transparente y trazable.

## ¿Qué es el Decision Layer?

El [Decision Layer](/es/decision-layer/) es la capa de governance entre el agente de IA y el sistema destino. Cada decisión que un agente toma o prepara queda documentada como acta de decisión: qué regla en qué versión se aplicó, qué datos sustentaron la decisión, quién (humano, motor de reglas o IA) decidió - y cómo la persona afectada puede presentar una objeción. Esa acta de decisión por microdecisión es la respuesta arquitectónica al derecho a la explicación de la decisión individual conforme al art. 86 del EU AI Act.

Esta página explica la metodología detrás de las cifras que aparecen en cada página de detalle de agente.

## Clasificación de decisores: R / A / H

Cada paso de decisión se asigna a exactamente uno de tres tipos de decisores:

```
R  Motor de reglas  Determinista. Entrada, salida.
                    Sin modelo, sin discrecionalidad, sin juicio.
                    Ejemplo: matriz de permisos, comprobación de plazos.

A  Agente IA        Basado en modelo con umbral de Confidence.
                    El resultado es probabilístico. Cuando el Confidence
                    cae por debajo del umbral: fallback a R o H.
                    Ejemplo: reconocimiento de Intent, detección de anomalías.

H  Humano           Asignado explícitamente. El agente prepara,
                    el humano decide. Documentado en el acta
                    de decisión.
                    Ejemplo: aprobación de despido, evaluación de caso excepcional.
```

La distinción se basa en dos criterios:

1. **Determinismo**: ¿Es el resultado idéntico con la misma entrada cada vez? Sí = R. No (porque modelo) = A. No (porque discrecionalidad) = H.
2. **Asignación de responsabilidad**: ¿Quién responde del resultado? Motor de reglas (configurado por RRHH/Finanzas) = R. Modelo (entrenado, con pista de auditoría) = A. Persona física (nominalmente) = H.

### Ubicación en marcos regulatorios

La clasificación R/A/H no existe de forma aislada. Se mapea sobre taxonomías de governance establecidas:

| Gosign R/A/H | Taxonomía Human-in-the-Loop | EU AI Act Art. 14 | Analogía niveles SAE |
|---|---|---|---|
| R (Motor de reglas) | Human-out-of-the-Loop | Sin supervisión humana requerida | Nivel 4-5 (totalmente automatizado) |
| A (Agente IA) | Human-on-the-Loop | Supervisión humana en alto riesgo (Art. 14) | Nivel 2-3 (asistido/condicional) |
| H (Humano) | Human-in-the-Loop | Humano como decisor | Nivel 0-1 (manual/asistido) |

La analogía con los niveles SAE (del sector automovilístico, SAE J3016) sirve como referencia intuitiva, no como transferencia directa. En el contexto automovilístico el nivel se refiere a la automatización de la conducción; aquí se refiere a la automatización de decisiones en procesos de RRHH y finanzas.

## Cómo contamos los pasos de decisión

Un paso de decisión es un punto del proceso en el que el agente realiza una elección de ruta. No toda operación de datos es un paso - solo los puntos en los que el resultado puede variar según la entrada.

Criterios para un paso de decisión:
- **La entrada varía**: No todos los casos siguen la misma ruta
- **La salida tiene consecuencia**: El resultado influye en el proceso posterior o en un sistema destino
- **El decisor es asignable**: Está claro si decide R, A o H

Ejemplo: El agente Employee Self-Service tiene 6 pasos de decisión identificados - desde el reconocimiento de Intent (A) pasando por la comprobación de permisos (R) hasta la escalación a la función especializada (R). Una simple consulta a base de datos ("consultar días de vacaciones restantes") no es un paso de decisión.

## Cálculo de puntuaciones

Cada agente se evalúa en cinco dimensiones:

| Puntuación | Qué mide | Escala |
|---|---|---|
| **Readiness** | ¿Cómo de preparada está una organización típica para este agente? | 0-100 |
| **Governance** | ¿Cuál es la carga regulatoria (EU AI Act, Comité de Empresa (Art. 64 ET, solo consulta), RGPD)? | 0-100 (mayor = más exigente) |
| **Economic** | ¿Cuál es la palanca económica (ROI, ahorro de FTE)? | 0-100 |
| **Lighthouse** | ¿Cuál es el efecto señalizador interno y externo? | 0-100 |
| **Complexity** | ¿Cuál es la complejidad de la implementación técnica? | 0-100 (mayor = más complejo) |

Cada puntuación se expresa como rango [n, n+7] - la amplitud refleja la varianza entre sectores y tamaños de organización. El valor inferior es el escenario conservador (empresa mediana sin trabajo previo), el superior es el escenario optimista (enterprise con infraestructura existente).

Las puntuaciones se basan en una combinación de:
- **Comparación sectorial**: ¿Cómo de comparables son los procesos entre organizaciones? (mayor estandarización = mayor puntuación Readiness)
- **Análisis regulatorio**: EU AI Act Annex III, RGPD Art. 22, derechos de consulta del Comité de Empresa bajo Art. 64 ET (puntuación Governance)
- **Datos benchmark**: Estudios externos sobre potencial de automatización (puntuación Economic)
- **Experiencia de proyectos**: Gosign Decision Layer Assessments de proyectos documentados con clientes

## Rangos de ahorro en la declaración de impacto

Cada agente tiene una declaración de impacto (pyramidOpener.impact) que hace una afirmación cuantitativa sobre el beneficio. Estas afirmaciones se clasifican en tres categorías de fuentes:

### CAT-EXT - Fuente primaria externa

La cifra proviene de un estudio sectorial verificado o un informe benchmark. Editorial, título, año y URL están documentados en el CITATION-CATALOG. La cifra fue verificada contra la fuente primaria (verificación WebFetch de la URL más comparación de contenido).

Ejemplo: *"Según Ardent Partners State of ePayables 2024, el coste por factura baja de 12,88 a 2,78 USD"* - Ardent Partners es la editorial, las cifras aparecen en el informe.

### CAT-LEGAL - Legislación o estadísticas oficiales

La cifra proviene de legislación, estadísticas oficiales o una sentencia judicial. La URL apunta a la fuente oficial (p. ej. eur-lex.europa.eu, bases legislativas nacionales).

Ejemplo: *"EU AI Act Annex III sistema de alto riesgo; obligaciones vigentes desde agosto de 2026, aplazamiento a diciembre de 2027 acordado provisionalmente"* - Reglamento (UE) 2024/1689.

### CAT-INT - Gosign Decision Layer Assessment

La cifra se basa en proyectos documentados con clientes. Métricas típicas: tiempos de tramitación (antes/después), tasas de coincidencia automática, reducciones de errores. Son valores medianos de al menos 3 proyectos comparables en el período 2024-2026.

Cuando una cifra de impacto se clasifica como CAT-INT, significa: la cifra es una experiencia de Gosign, no un benchmark externo. Es sólida en el contexto de nuestros datos de proyectos, pero no ha sido verificada de forma independiente externamente.

## Verificación de fuentes

Cada fuente externa en el CITATION-CATALOG fue verificada mediante el siguiente proceso:

1. **Comprobación de URL**: La URL de la fuente responde con HTTP 200 (o redirección a una página de destino)
2. **Comparación de cifras**: La cifra citada en la declaración de impacto aparece realmente en la fuente (no solo "aproximadamente" o "en el espíritu de")
3. **Comprobación de contexto**: La cifra se utiliza en el mismo contexto que en la fuente (p. ej. "Value Erosion" no reinterpretada como "costes de gestión")

Si una cifra no supera esta triple comprobación, se procede de una de estas formas:
- Se corrige a la cifra exacta de la fuente
- Se reclasifica a CAT-INT (si la fuente no respalda la cifra)
- Se elimina de la declaración de impacto (si no es verificable ni externa ni internamente)

## Datos estructurados para LLMs

Cada página de detalle de agente contiene un esquema JSON-LD (Schema.org SoftwareApplication) con:

- **Distribución R/A/H** como `additionalProperty` (rulesEngineShare, aiAgentShare, humanDecisionShare en porcentaje)
- **Número de pasos de decisión** (totalDecisionSteps)
- **Flag de alto riesgo EU AI Act** (euAiActHighRisk: true/false)
- **Declaración de impacto** como propiedad de texto libre
- **citation[]** con URLs de fuentes resueltas del CITATION-CATALOG

Los LLMs pueden extraer estos datos directamente del código fuente HTML y citarlos con la URL canónica de la página del agente.

## Versionado

| Fecha | Cambio |
|---|---|
| 2026-04-16 | Publicación inicial: clasificación R/A/H, metodología de puntuaciones, verificación de fuentes, esquema JSON-LD |

--- Suscripción cancelada - Gosign GmbH ---
> Has cancelado tu suscripción al AI Governance Briefing.

<h1>Suscripción cancelada</h1>

<p class="text-lg text-gosign-text-light">
Te has dado de baja del <strong>AI Governance Briefing</strong> y no recibirás más correos electrónicos.
</p>

<p>Si deseas volver a suscribirte, puedes hacerlo en cualquier momento a través de nuestra web.</p>

<p class="mt-6">
<a href="/es/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Ir al inicio</a>
</p>

--- Newsletter confirmado - Gosign GmbH ---
> Tu suscripción al AI Governance Briefing ha sido confirmada.

<h1>Suscripción confirmada</h1>

<p class="text-lg text-gosign-text-light">
Gracias - tu suscripción al <strong>AI Governance Briefing</strong> ya está activa.
</p>

<p>Recibirás el briefing una vez al mes con las últimas novedades sobre AI Governance, Decision Layer e infraestructura Enterprise AI.</p>

<p class="mt-6">
<a href="/es/revista/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Ir a la revista</a>
<span class="mx-2 text-gosign-text-light">|</span>
<a href="/es/contacto/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-medium" target="_blank" rel="noopener noreferrer">Agendar una reunión</a>
</p>

--- Enlace expirado - Gosign GmbH ---
> Su enlace de confirmación para el AI Governance Briefing ha expirado.

<h1>Enlace de confirmación expirado</h1>

<p class="text-lg text-gosign-text-light">
Su enlace de confirmación para el <strong>AI Governance Briefing</strong> ha expirado. Por motivos de seguridad, los enlaces son válidos durante 7 días.
</p>

<p>No hay problema - simplemente regístrese de nuevo a continuación. Recibirá un nuevo correo de confirmación de inmediato.</p>

--- Por qué Gosign - EU AI Act, Self-Hosting, EU-first ---
> Tres decisiones arquitectónicas: EU AI Act ready, su infraestructura, EU-first. Sin dependencia SaaS, sin riesgo de cloud estadounidense.

<!-- USP 1: EU AI Act ready -->
<section id="eu-ai-act" class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<div class="flex items-center gap-3 mb-6">
<svg class="w-10 h-10 text-gosign-accent-text" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<h2 class="text-h1 font-bold text-gosign-dark">EU AI Act ready</h2>
</div>
<p class="text-body-lg text-gosign-dark font-semibold">Cada decisión del Agent rastreable. Para el Comité de Empresa. Para la AESIA. Para usted.</p>
<p class="text-body text-gosign-text-light mt-4">Los HR Agents entran en el ámbito del Artículo 6 del EU AI Act: contexto laboral significa clasificación de alto riesgo. La pregunta central no es si, sino cómo se documenta cada decisión - quién decidió, por qué, con qué Confidence-Score.</p>

<p class="text-body text-gosign-text-light mt-4">Los Gosign Agents hacen cada decisión transparente - por arquitectura, no retroactivamente:</p>
<ul class="mt-4 space-y-3">
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text mt-0.5 flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" /></svg>
<span class="text-body text-gosign-text-light"><strong class="text-gosign-dark">Art. 9 Gestión de riesgos</strong> - El Decision Layer define para cada paso del proceso: humano, motor de reglas o IA. La evaluación de riesgos es arquitectura, no un proyecto de auditoría.</span>
</li>
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text mt-0.5 flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" /></svg>
<span class="text-body text-gosign-text-light"><strong class="text-gosign-dark">Art. 12 Trazabilidad</strong> - Cada decisión del Agent queda registrada como acta de decisión en el Audit Trail: input, regla de negocio aplicada con su versión, Confidence Score, resultado y vía de impugnación - la prueba por microdecisión.</span>
</li>
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text mt-0.5 flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" /></svg>
<span class="text-body text-gosign-text-light"><strong class="text-gosign-dark">Art. 13 Transparencia</strong> - El Comité de Empresa puede verificar cada decisión a través del Auditor Portal - sin departamento de IT, sin acceso a bases de datos.</span>
</li>
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text mt-0.5 flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" /></svg>
<span class="text-body text-gosign-text-light"><strong class="text-gosign-dark">Art. 14 Supervisión humana</strong> - Human-in-the-Loop como principio arquitectónico, no como función opcional. El ser humano permanece en el proceso donde el Estatuto de los Trabajadores, la legislación laboral o el riesgo de discriminación lo exigen.</span>
</li>
</ul>
<p class="text-body text-gosign-text-light mt-6">La transparencia de decisiones no es un proyecto de cumplimiento posterior. Está integrada en el Decision Layer desde el primer piloto.</p>
<p class="text-body text-gosign-text-light mt-4">Profundización: <a href="/es/revista/eu-ai-act-aplica-en-todo-el-mundo/" class="text-gosign-accent-text hover:underline">Por qué el EU AI Act se aplica en todo el mundo - y qué significa para su empresa</a></p>
</div>
</div>
</section>

<!-- USP 2: Su infraestructura -->
<section id="infraestructura" class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<div class="flex items-center gap-3 mb-6">
<svg class="w-10 h-10 text-gosign-accent-text" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<h2 class="text-h1 font-bold text-gosign-dark">Su infraestructura</h2>
</div>
<p class="text-body-lg text-gosign-dark font-semibold">En su centro de datos. Bajo su control.</p>
<p class="text-body text-gosign-text-light mt-4">Los Gosign AI Agents no son un producto SaaS. Se ejecutan en su infraestructura - on-premises, cloud privada o híbrida. Los datos no salen de sus sistemas.</p>
<p class="text-body text-gosign-text-light mt-4">En el sector financiero, esto no es una preferencia - es un requisito regulatorio. La CNMV y la AEPD exigen niveles de protección de datos que ningún proveedor SaaS con servidores fuera de la UE puede garantizar contractualmente. El Comité de Empresa tiene derecho a ser informado sobre el tratamiento de datos de empleados (Art. 64 ET). Self-Hosting es la base para el acuerdo de empresa.</p>
<div class="grid grid-cols-1 md:grid-cols-3 gap-6 mt-8">
<div class="border border-gosign-border rounded-card p-6 bg-gosign-white">
<p class="text-sm font-bold text-gosign-accent-text uppercase tracking-wider">Código fuente</p>
<p class="text-body text-gosign-text-light mt-2">Acceso completo. Puede operar el Agent en cualquier momento sin Gosign. Sin dependencia del proveedor.</p>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-gosign-white">
<p class="text-sm font-bold text-gosign-accent-text uppercase tracking-wider">Modelo agnóstico</p>
<p class="text-body text-gosign-text-light mt-2">Usted elige el LLM - no nosotros. OpenAI, Anthropic, modelos locales. Sin dependencia de un proveedor.</p>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-gosign-white">
<p class="text-sm font-bold text-gosign-accent-text uppercase tracking-wider">RGPD nativo</p>
<p class="text-body text-gosign-text-light mt-2">Residencia de datos como decisión arquitectónica. RGPD y LOPDGDD cumplidos por diseño. Ningún dato abandona su infraestructura.</p>
</div>
</div>
</div>
</div>
</section>

<!-- USP 3: EU-first -->
<section id="eu-first" class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<div class="flex items-center gap-3 mb-6">
<svg class="w-10 h-10 text-gosign-accent-text" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<h2 class="text-h1 font-bold text-gosign-dark">EU-first</h2>
</div>
<p class="text-body-lg text-gosign-dark font-semibold">Ningún producto estadounidense con parche europeo. La regulación UE es la baseline.</p>
<p class="text-body text-gosign-text-light mt-4">La mayoría de los productos de IA se construyen para el mercado estadounidense y se adaptan después a la regulación europea. RGPD como casilla de verificación, derecho de consulta como curiosidad cultural, residencia de datos como función opcional.</p>
<p class="text-body text-gosign-text-light mt-4">Los Gosign Agents están construidos al revés: los datos permanecen en su infraestructura - sin dependencia de cloud estadounidense. El RGPD es un principio arquitectónico, no una casilla de verificación. Quien cumple el entorno regulatorio más exigente, cumple cualquier otro - incluido el marco español.</p>
<p class="text-body text-gosign-text-light mt-4">Concretamente:</p>
<ul class="mt-4 space-y-3">
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text mt-0.5 flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" /></svg>
<span class="text-body text-gosign-text-light"><strong class="text-gosign-dark">Sin dependencia de cloud estadounidense</strong>. Los datos permanecen en su infraestructura - sin exposición al CLOUD Act, sin riesgo de transferencia transfronteriza.</span>
</li>
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text mt-0.5 flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" /></svg>
<span class="text-body text-gosign-text-light"><strong class="text-gosign-dark">RGPD como principio arquitectónico</strong>, no como adaptación retroactiva. Residencia de datos, conceptos de eliminación y controles de acceso están anclados en la arquitectura.</span>
</li>
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text mt-0.5 flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" /></svg>
<span class="text-body text-gosign-text-light"><strong class="text-gosign-dark">Convenios colectivos como reglas deterministas</strong> en el Decision Layer. Cada convenio colectivo sectorial o de empresa se implementa como motor de reglas, no como campo de texto libre.</span>
</li>
</ul>
<p class="text-body text-gosign-text-light mt-6">Profundización: <a href="/es/revista/shadow-ai-governance/" class="text-gosign-accent-text hover:underline">Shadow AI en la empresa - governance en lugar de prohibición</a></p>
</div>
</div>
</section>

<!-- Profundización en el Agent Briefing -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">Profundización en el Agent Briefing (Revista Gosign)</h2>
<div class="grid grid-cols-1 md:grid-cols-3 gap-6">
<a href="/es/revista/eu-ai-act-aplica-en-todo-el-mundo/" class="block border border-gosign-border rounded-card p-6 bg-gosign-white hover:border-gosign-accent transition-colors">
<p class="text-xs font-bold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<p class="text-h3 font-bold text-gosign-dark">El EU AI Act se aplica en todo el mundo</p>
</a>
<a href="/es/revista/eu-ai-act-hr/" class="block border border-gosign-border rounded-card p-6 bg-gosign-white hover:border-gosign-accent transition-colors">
<p class="text-xs font-bold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<p class="text-h3 font-bold text-gosign-dark">EU AI Act y HR</p>
</a>
<a href="/es/revista/agent-governance-hr/" class="block border border-gosign-border rounded-card p-6 bg-gosign-white hover:border-gosign-accent transition-colors">
<p class="text-xs font-bold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<p class="text-h3 font-bold text-gosign-dark">Agent Governance para HR</p>
</a>
</div>
</div>
</section>

--- Política de Privacidad - Gosign GmbH ---
> Política de privacidad de Gosign GmbH. Sitio web sin cookies y sin rastreadores del lado del cliente; medición de alcance y conversiones del lado del servidor, sin cookies.

<h1>Política de Privacidad</h1>

<h2>1. Responsable</h2>
<p>
Gosign GmbH<br/>
Hallerstraße 8<br/>
20146 Hamburgo, Alemania
</p>
<p>Correo electrónico: web26 [at] gosign.de</p>

<h3>Delegado de protección de datos</h3>
<p>
No se ha designado un delegado de protección de datos. Menos de 20 empleados están regularmente involucrados en el tratamiento automatizado de datos personales (§&nbsp;38, apartado&nbsp;1, BDSG). Si tiene preguntas sobre la protección de datos, diríjase a la dirección indicada anteriormente.
</p>

<h2>2. Resumen</h2>
<p>
Este sitio web no establece cookies. Ni de primera parte ni de tercera parte. No se cargan rastreadores externos del lado del cliente: ni Google Analytics, ni Matomo, ni Facebook Pixel, ni LinkedIn Insight Tag ni Google Tag Manager. Para la medición de alcance y conversiones utilizamos un sistema propio, sin cookies y del lado del servidor (véase la sección&nbsp;4).
</p>
<p>
No se requiere un banner de cookies, ya que no se almacenan ni se leen cookies o tecnologías comparables en su dispositivo terminal (§&nbsp;25 TTDSG).
</p>

<h2>3. Hosting y entrega de contenido</h2>
<p>
Este sitio web se sirve a través de Cloudflare Pages. Cloudflare actúa como encargado del tratamiento conforme al Art.&nbsp;28 RGPD. Existe un Addendum de Procesamiento de Datos (DPA) con Cláusulas Contractuales Tipo (SCCs).
</p>
<p>
Al entregar páginas web, Cloudflare procesa técnicamente la dirección IP del dispositivo solicitante. Dependiendo del servicio, este tratamiento también puede tener lugar fuera de la UE y está asegurado mediante el EU-US Data Privacy Framework así como mediante DPA/SCCs.
</p>
<p>
Base legal: Art.&nbsp;6, apartado&nbsp;1, letra&nbsp;f, RGPD (interés legítimo en la entrega segura y eficiente del sitio web).
</p>

<h2>4. Medición de alcance y conversiones</h2>
<p>
Para analizar el uso del sitio web y la eficacia de nuestra publicidad utilizamos un sistema de medición propio, sin cookies (internamente «Lyftyfy»), operado por Gosign GmbH. No se establecen cookies ni se cargan rastreadores externos del lado del cliente (sin Google Analytics, sin Google Tag Manager, sin Facebook Pixel, sin LinkedIn Insight Tag). La medición se realiza del lado del servidor y sin reconocimiento permanente de su dispositivo:
</p>
<ul>
<li>No se almacena ningún identificador permanente en su dispositivo. Para agrupar las visitas de un mismo día se genera un hash de sesión que cambia diariamente a partir de la dirección IP, la firma del navegador y la fecha; la dirección IP en sí no se almacena.</li>
<li>Se recopilan páginas visitadas, profundidad de desplazamiento, tiempo de permanencia, clics y eventos de formulario y conversión, en forma agregada y seudónima.</li>
</ul>
<p>
Base legal: Art.&nbsp;6, apartado&nbsp;1, letra&nbsp;f, RGPD (interés legítimo en el análisis del uso del sitio web y la eficacia de nuestra publicidad).
</p>

<h3>Medición de conversiones para campañas publicitarias (Google Ads)</h3>
<p>
Si llega a nuestro sitio web a través de un anuncio de Google Ads, la dirección solicitada contiene un parámetro de clic (gclid). Si a continuación completa una acción (p.&nbsp;ej. una solicitud mediante formulario), transmitimos del lado del servidor un evento de conversión a Google para medir la eficacia de nuestras campañas. Se transmiten el parámetro de clic, un valor cifrado mediante hash (no legible) de su dirección de correo electrónico o número de teléfono, y el valor de la conversión. No se establece ninguna cookie ni etiqueta publicitaria en su navegador. El destinatario es Google Ireland Ltd. o Google LLC (EE.&nbsp;UU.); la transferencia está asegurada mediante el contrato de encargo de tratamiento (Art.&nbsp;28 RGPD), el EU-US Data Privacy Framework y las Cláusulas Contractuales Tipo (véase la sección sobre contratos de encargo de tratamiento).
</p>
<p>
Base legal: Art.&nbsp;6, apartado&nbsp;1, letra&nbsp;f, RGPD (interés legítimo en la medición y optimización de nuestra publicidad).
</p>
<p>
Puede oponerse a esta medición en cualquier momento con efecto para el futuro (Art.&nbsp;21 RGPD). Basta un mensaje informal a la dirección indicada en «Responsable»; entonces cesaremos el tratamiento.
</p>

<h2>5. Formulario de contacto y contacto por correo electrónico</h2>
<p>
Si nos envía consultas a través del formulario de contacto o por correo electrónico, sus datos (por ejemplo, nombre, dirección de correo electrónico, texto del mensaje) serán tratados para gestionar su consulta y para posibles consultas de seguimiento. El tratamiento de estos datos se basa en el Art.&nbsp;6, apartado&nbsp;1, letra&nbsp;b, RGPD, en la medida en que su consulta esté relacionada con el cumplimiento de un contrato o sea necesaria para la ejecución de medidas precontractuales. En todos los demás casos, el tratamiento se basa en nuestro interés legítimo en la gestión eficaz de las consultas que se nos dirigen (Art.&nbsp;6, apartado&nbsp;1, letra&nbsp;f, RGPD).
</p>

<h3>Tramitación técnica a través de Cloudflare (sin almacenamiento intermedio)</h3>
<p>
Para garantizar una transmisión segura y rápida de los datos de su formulario, utilizamos para el enrutamiento la tecnología "Cloudflare Workers" del proveedor Cloudflare, Inc., 101 Townsend St, San Francisco, CA 94107, EE.&nbsp;UU. Cloudflare actúa aquí exclusivamente como intermediario técnico. Los datos introducidos en el formulario no son almacenados por Cloudflare en una base de datos, sino que se procesan en la memoria de trabajo y se reenvían en tiempo real a través de una conexión cifrada (TCP Socket) a nuestro servidor de correo electrónico. Una vez transferidos los datos, estos no permanecen en los servidores de Cloudflare.
</p>

<h3>Alojamiento de correo electrónico a través de Google Workspace (hosting en la UE)</h3>
<p>
Para la recepción, el almacenamiento y el envío de nuestros correos electrónicos utilizamos el servicio "Google Workspace" del proveedor Google Cloud EMEA Limited, 70 Sir John Rogerson's Quay, Dublin 2, Irlanda. Hemos configurado Google Workspace de modo que nuestros datos de correo electrónico se almacenan físicamente en servidores dentro de la Unión Europea (UE).
</p>

<h3>Contratos de encargo de tratamiento (DPA) y transferencias a terceros países</h3>
<p>
Hemos celebrado un contrato de encargo de tratamiento (DPA) conforme al Art.&nbsp;28 RGPD tanto con Cloudflare como con Google. Dado que ambos proveedores forman parte de corporaciones estadounidenses, no se puede excluir al 100&nbsp;% una transferencia teórica de datos a EE.&nbsp;UU. en caso de trabajos de mantenimiento, enrutamiento (Cloudflare) o asistencia técnica. Para estos casos, los proveedores se apoyan en la Decisión de Adecuación de la Comisión Europea (EU-US Data Privacy Framework) así como en las Cláusulas Contractuales Tipo para garantizar un nivel adecuado de protección de datos.
</p>

<h3>Período de conservación</h3>
<p>
Los datos introducidos por usted en el formulario de contacto permanecen en nuestro buzón de correo electrónico hasta que nos solicite su supresión, revoque su consentimiento para el almacenamiento o el fin del almacenamiento de datos deje de existir (por ejemplo, tras la finalización del tratamiento de su consulta). Las disposiciones legales imperativas, en particular los plazos de conservación mercantiles y fiscales (hasta 10 años conforme al §&nbsp;257 HGB y §&nbsp;147 AO), no se ven afectados.
</p>

<h2>6. Newsletter</h2>
<p>
Al suscribirse a nuestro newsletter, procesamos su dirección de correo electrónico con el fin de enviarle regularmente información sobre nuestros servicios, artículos y eventos.
</p>
<h3>Procedimiento de doble confirmación (Double Opt-In)</h3>
<p>
El registro se realiza mediante un procedimiento de doble confirmación: tras introducir su dirección de correo electrónico, recibirá un correo de confirmación con un enlace único. Su dirección solo se añadirá a la lista de distribución tras hacer clic en dicho enlace. El enlace de confirmación es válido durante 7 días.
</p>
<h3>Servicios utilizados</h3>
<p>
El newsletter se envía a través de un Cloudflare Worker (proveedor: Cloudflare, Inc., 101 Townsend St, San Francisco, CA 94107, EE.&nbsp;UU.). Su dirección de correo electrónico se almacena en Cloudflare KV (almacén clave-valor). Hemos celebrado un contrato de encargo de tratamiento con Cloudflare conforme al art.&nbsp;28 RGPD. El envío de correos se realiza mediante SMTP (actualmente a través de un servidor de correo de terceros).
</p>
<h3>Base jurídica</h3>
<p>
Art.&nbsp;6, apartado 1, letra a) del RGPD (consentimiento). Puede revocar su consentimiento en cualquier momento mediante el enlace de cancelación incluido en cada correo del newsletter o contactándonos en datenschutz@gosign.de.
</p>
<h3>Período de conservación</h3>
<p>
Su dirección de correo electrónico se conserva hasta que se dé de baja del newsletter. Tras la cancelación, la dirección se elimina sin demora injustificada, salvo que existan obligaciones legales de conservación.
</p>

<h2>7. 203-Readiness-Check</h2>
<p>
En nuestras páginas en alemán ofrecemos el 203-Readiness-Check, una autoevaluación voluntaria sobre el uso de IA dirigida a profesionales sujetos al secreto profesional conforme al §&nbsp;203 del Código Penal alemán (StGB). Sus respuestas en la autoevaluación no se almacenan ni se transmiten: la evaluación se realiza íntegramente en su navegador y el resultado aparece directamente en la página, sin necesidad de introducir un correo electrónico.
</p>
<h3>Informe de resultados por correo electrónico (opcional)</h3>
<p>
Solo si solicita voluntariamente el informe de resultados detallado por correo electrónico, tratamos su dirección de correo electrónico, su grupo profesional y el nivel recomendado para usted, pero no sus respuestas. La solicitud se confirma mediante el procedimiento de doble confirmación (double opt-in), igual que en el newsletter (sección&nbsp;6): recibirá un correo de confirmación con un enlace único y el informe solo se enviará tras hacer clic en dicho enlace. El envío se realiza a través de nuestro proveedor de servicios de correo electrónico Brevo, con el que hemos celebrado un contrato de encargo de tratamiento conforme al Art.&nbsp;28 RGPD.
</p>
<h3>Base jurídica</h3>
<p>
Art.&nbsp;6, apartado&nbsp;1, letra&nbsp;a, RGPD (consentimiento). Puede revocar su consentimiento en cualquier momento con efecto futuro, por ejemplo, enviando un correo a datenschutz@gosign.de.
</p>
<h3>Período de conservación</h3>
<p>
Las solicitudes de informe confirmadas se eliminan después de 6 meses. Las solicitudes no confirmadas del procedimiento de doble confirmación expiran automáticamente a los 7 días.
</p>

<h2>8. Reserva de citas</h2>
<p>
Para la reserva de citas utilizamos Google Calendar Appointment Scheduling (proveedor: Google Ireland Limited, Gordon House, Barrow Street, Dublin 4, Irlanda). Al hacer clic en el enlace de reserva, se le redirige a calendar.google.com. En nuestro sitio web, el enlace de reserva no carga ningún script ni establece ninguna cookie.
</p>
<p>
Al utilizar el servicio de reserva, sus datos (nombre, dirección de correo electrónico, cita seleccionada) son tratados por Google. Se aplica la <a href="https://policies.google.com/privacy" target="_blank" rel="noopener noreferrer" class="text-gosign-accent-text hover:text-gosign-accent-hover">Política de Privacidad de Google</a>.
</p>
<p>
Base legal: Art.&nbsp;6, apartado&nbsp;1, letra&nbsp;b, RGPD (ejecución de medidas precontractuales a solicitud suya). La reserva de una cita de asesoramiento sirve para iniciar una relación comercial.
</p>

<h2>9. Fuentes tipográficas</h2>
<p>
Todas las fuentes tipográficas utilizadas en este sitio web están integradas localmente (self-hosted). No se cargan servicios externos de fuentes (por ejemplo, Google Fonts). No se establece ninguna conexión con terceros al cargar las fuentes tipográficas.
</p>

<h2>10. Mapas y vídeos</h2>
<p>
Este sitio web no integra servicios externos de mapas (por ejemplo, Google Maps) ni servicios externos de vídeo (por ejemplo, YouTube). Cuando se muestran mapas o vídeos, se realiza mediante imágenes estáticas o contenido autoalojado.
</p>

<h2>11. Sin terceros adicionales</h2>
<p>
Este sitio web no carga recursos de terceros que no estén mencionados en esta política de privacidad. En particular, no se utilizan:
</p>
<ul>
<li>Google Tag Manager</li>
<li>Facebook Pixel</li>
<li>LinkedIn Insight Tag</li>
<li>HubSpot, Salesforce u otros rastreadores CRM</li>
<li>Hotjar, Mouseflow u otras herramientas de grabación de sesiones</li>
<li>Matomo u otras herramientas de analítica autoalojadas</li>
</ul>

<h2>12. Cifrado SSL/TLS</h2>
<p>
Este sitio web utiliza cifrado SSL/TLS por razones de seguridad. Puede reconocer una conexión cifrada por el prefijo "https://" en la barra de direcciones de su navegador.
</p>

<h2>13. Archivos de registro del servidor</h2>
<p>
El proveedor de hosting (Cloudflare) recopila técnicamente datos de acceso en archivos de registro del servidor. Estos pueden contener: página consultada, fecha y hora, volumen de datos, URL de referencia, dirección IP, navegador y sistema operativo. Los archivos de registro son almacenados por Cloudflare durante un máximo de 72 horas y no se combinan con otros datos.
</p>
<p>
Base legal: Art.&nbsp;6, apartado&nbsp;1, letra&nbsp;f, RGPD (interés legítimo en garantizar el funcionamiento técnico y la detección de ataques).
</p>

<h2>14. Inteligencia artificial y toma de decisiones automatizada</h2>
<p>
No se lleva a cabo ninguna toma de decisiones automatizada, incluido el perfilado, conforme al Art.&nbsp;22 RGPD. En este sitio web no se emplean sistemas de IA para el tratamiento automatizado de datos personales de los visitantes.
</p>

<h3>Creación de contenido asistida por IA</h3>
<p>
Gosign utiliza herramientas asistidas por IA (modelos de lenguaje grandes, generación de imágenes) para la creación y edición de contenidos del sitio web, gráficos y diagramas. Estas herramientas no tratan datos personales de los visitantes del sitio web. Todos los resultados son revisados y aprobados editorialmente.
</p>

<h3>IA en proyectos de clientes</h3>
<p>
Gosign desarrolla y opera infraestructura de IA para clientes empresariales (AI Agents, Document Intelligence, automatización de procesos). El tratamiento de datos personales en proyectos de clientes se rige por contratos de encargo de tratamiento (DPA) separados conforme al Art.&nbsp;28 RGPD y no es objeto de esta política de privacidad.
</p>

<h2>15. Estándares internacionales de protección de datos</h2>
<p>
Gosign atiende a clientes en todo el mundo y reconoce los derechos de protección de datos según las leyes locales aplicables en cada caso. El RGPD sigue siendo la legislación principal de protección de datos, ya que Gosign GmbH tiene su sede en Alemania y el tratamiento de datos se realiza en la UE. A continuación se ofrecen indicaciones complementarias para usuarios de determinadas jurisdicciones.
</p>

<h3>Reino Unido</h3>
<p>
Para usuarios en el Reino Unido se aplica la UK GDPR en combinación con la Data Protection Act 2018. Los derechos son en gran medida equivalentes a los del RGPD de la UE. Autoridad supervisora competente: Information Commissioner's Office (ICO), Wilmslow, Cheshire, UK.
</p>

<h3>Estados Unidos</h3>
<p>
Para usuarios residentes en California se aplican adicionalmente la California Consumer Privacy Act (CCPA) y la California Privacy Rights Act (CPRA). Esto incluye el derecho a conocer las categorías de datos recopilados, el derecho a la supresión y el derecho a oponerse a la venta de datos personales. Gosign no vende datos personales ni los comparte con terceros con fines publicitarios. Para usuarios en otros estados de EE.&nbsp;UU. con leyes propias de protección de datos (Colorado, Connecticut, Virginia, Utah, Texas, Oregón, entre otros) se reconocen derechos comparables.
</p>

<h3>Suiza</h3>
<p>
Para usuarios en Suiza se aplica la Ley Federal de Protección de Datos revisada (revDSG/nDSG), en vigor desde el 1&nbsp;de septiembre de 2023. Otorga derechos comparables a los del RGPD. Autoridad supervisora competente: Comisionado Federal de Protección de Datos e Información (ED&Ouml;B), Berna.
</p>

<h3>Canadá</h3>
<p>
Para usuarios en Canadá se aplica la Personal Information Protection and Electronic Documents Act (PIPEDA). Gosign reconoce los principios de PIPEDA, en particular consentimiento, limitación de la finalidad, acceso y rectificación. Autoridad supervisora competente: Office of the Privacy Commissioner of Canada (OPC), Gatineau, QC.
</p>

<h3>Brasil</h3>
<p>
Para usuarios en Brasil se aplica adicionalmente la Lei Geral de Proteção de Dados (LGPD, Lei n.º&nbsp;13.709/2018). La LGPD otorga a los usuarios brasileños derechos integrales, incluyendo acceso, rectificación, anonimización, supresión, portabilidad de datos y oposición. Estos derechos son plenamente reconocidos por nosotros. Autoridad supervisora competente: Autoridade Nacional de Proteção de Dados (ANPD), Brasília, DF.
</p>

<h3>India</h3>
<p>
Para usuarios en India se aplica la Digital Personal Data Protection Act (DPDP Act, 2023). Gosign reconoce los derechos de los usuarios indios, en particular acceso, rectificación, supresión y el derecho a presentar una reclamación. Autoridad supervisora competente: Data Protection Board of India (DPBI), Nueva Delhi.
</p>

<h3>Japón</h3>
<p>
Para usuarios en Japón se aplica la Act on the Protection of Personal Information (APPI). La Comisión Europea ha reconocido a Japón un nivel adecuado de protección de datos. Gosign reconoce los derechos derivados de la APPI, en particular acceso, rectificación, supresión y cese del uso. Autoridad supervisora competente: Personal Information Protection Commission (PPC), Tokio.
</p>

<h3>Sudáfrica</h3>
<p>
Para usuarios en Sudáfrica se aplica la Protection of Personal Information Act (POPIA). Gosign reconoce los derechos derivados de POPIA, en particular acceso, rectificación, supresión y oposición al marketing directo. Autoridad supervisora competente: Information Regulator, Johannesburgo.
</p>

<h3>Todas las demás jurisdicciones</h3>
<p>
Para usuarios en países con legislación propia de protección de datos no mencionados explícitamente aquí, Gosign reconoce los derechos de protección de datos locales aplicables en la medida en que se refieran al tratamiento a través de este sitio web. Sus derechos de acceso, rectificación y supresión están garantizados en todo caso.
</p>

<h2>16. Sus derechos</h2>
<p>
Usted tiene los siguientes derechos respecto a sus datos personales:
</p>
<ul>
<li><strong>Acceso</strong> (Art.&nbsp;15 RGPD): Puede solicitar información sobre los datos que tratamos.</li>
<li><strong>Rectificación</strong> (Art.&nbsp;16 RGPD): Puede solicitar la corrección de datos inexactos.</li>
<li><strong>Supresión</strong> (Art.&nbsp;17 RGPD): Puede solicitar la supresión de sus datos, siempre que no existan obligaciones legales de conservación que lo impidan.</li>
<li><strong>Limitación del tratamiento</strong> (Art.&nbsp;18 RGPD): Puede solicitar la limitación del tratamiento de sus datos.</li>
<li><strong>Portabilidad de datos</strong> (Art.&nbsp;20 RGPD): Puede solicitar la entrega de sus datos en un formato legible por máquina.</li>
<li><strong>Oposición</strong> (Art.&nbsp;21 RGPD): Puede oponerse en cualquier momento al tratamiento basado en el Art.&nbsp;6, apartado&nbsp;1, letra&nbsp;f, RGPD.</li>
<li><strong>Revocación del consentimiento</strong> (Art.&nbsp;7, apartado&nbsp;3, RGPD): En la medida en que un tratamiento se base en su consentimiento, puede revocarlo en cualquier momento con efecto futuro. La licitud del tratamiento efectuado hasta la revocación no se ve afectada.</li>
</ul>
<p>
Para ejercer sus derechos, basta con una comunicación informal a la dirección indicada anteriormente.
</p>

<h2>17. Derecho de reclamación</h2>
<p>
Usted tiene derecho a presentar una reclamación ante una autoridad de supervisión de protección de datos. La autoridad competente es la del estado federado en el que usted resida o la responsable del responsable del tratamiento:
</p>
<p>
Comisionado de Hamburgo para la Protección de Datos y la Libertad de Información (Der Hamburgische Beauftragte für Datenschutz und Informationsfreiheit)<br/>
Ludwig-Erhard-Str. 22<br/>
20459 Hamburgo, Alemania
</p>

<h2>18. Vigencia</h2>
<p>
Esta política de privacidad está actualmente vigente. Última actualización: febrero 2026.
</p>
<p>
Nos reservamos el derecho de modificar esta política de privacidad para adaptarla a cambios en la situación legal o a modificaciones del servicio.
</p>

--- Recruiting Agent - Matching de Requisitos Impulsado por IA ---
> Recruiting Agent para screening de candidatos consistente y auditable. Matching de requisitos sin sesgo por fatiga. Decision Layer con Human-in-the-Loop.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/es/por-que-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Cada decisión rastreable</p>
</div>
</a>
<a href="/es/por-que-gosign/#infraestructura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Su infraestructura</p>
<p class="text-xs text-gosign-text-light">Sin SaaS. Sin vendor lock-in.</p>
</div>
</a>
<a href="/es/por-que-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Sin riesgo de cloud estadounidense</p>
</div>
</a>
</div>
</div>
</div>


<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">El Problema: Screening Inconsistente, Decisiones sin Documentar</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
El screening de CVs a escala empresarial depende de reclutadores individuales. El CV número 50 del día se evalúa diferente al número 5. Los criterios varían entre managers de contratación. Los rechazos rara vez se documentan con razonamiento trazable.
</p>
</div>
</section>

<!-- Prozess-Diagramm -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-6">Proceso de selección con Decision Layer</h2>
<img src="/images/diagrams/recruiting-decision-flow-es.svg" alt="Proceso de selección en 5 fases con Decision Layer" class="w-full" width="1200" height="400" loading="lazy" />
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Cómo Funciona el Recruiting Agent</h2>
<pre class="bg-gosign-dark text-white p-6 rounded-card overflow-x-auto text-small font-mono leading-relaxed mt-4"><code>Solicitud   →  Document Agent     →  Decision Layer
(CV + Carta     lee y                 compara contra
motivación)    extrae                perfil de requisitos
│
┌────────────┴────────────┐
│                         │
Match fuerte              Match parcial o
Todos los criterios       brechas en criterios
│                         │
Shortlist con             Revisión por reclutador
documentación             con contexto y brechas
│                         │
Audit Trail               Audit Trail</code></pre>
</div>
</section>

<!-- Micro-Decision Table -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">¿Quién decide qué? Micro-Decisions en el recruiting</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
El <a href="/es/decision-layer/" class="text-gosign-accent-text hover:underline">Decision Layer</a> descompone el proceso de recruiting en pasos de decisión individuales. Para cada paso se define de antemano: persona, conjunto de reglas o AI.
</p>
</div>
<div class="mt-8 overflow-x-auto">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-dark/20">
<th class="py-3 pr-4 text-body font-bold text-gosign-dark">Paso de decisión</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Quién decide</th>
<th class="py-3 pl-4 text-body font-bold text-gosign-dark">Por qué</th>
</tr>
</thead>
<tbody class="text-body text-gosign-text-light">
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Crear perfil de requisitos</td>
<td class="py-3 px-4"><span class="inline-block px-2 py-0.5 text-xs font-bold rounded bg-amber-100 text-amber-800">Persona revisa</span></td>
<td class="py-3 pl-4">AI genera propuesta a partir de la descripción del puesto y perfil del equipo. El responsable revisa y ajusta.</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Redactar oferta de empleo</td>
<td class="py-3 px-4"><span class="inline-block px-2 py-0.5 text-xs font-bold rounded bg-blue-100 text-blue-800">Automático</span></td>
<td class="py-3 pl-4">Agent genera texto a partir de requisitos. Verificación contra lenguaje discriminatorio.</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Parsing de CV y extracción de datos</td>
<td class="py-3 px-4"><span class="inline-block px-2 py-0.5 text-xs font-bold rounded bg-blue-100 text-blue-800">Automático</span></td>
<td class="py-3 pl-4">Extracción de datos estructurados de CVs. Caso estándar, alta confianza.</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Matching de requisitos (screening)</td>
<td class="py-3 px-4"><span class="inline-block px-2 py-0.5 text-xs font-bold rounded bg-emerald-100 text-emerald-800">Conjunto de reglas</span></td>
<td class="py-3 pl-4">Comparación contra criterios obligatorios definidos. Basado en reglas, no en juicio de AI.</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Evaluación cualitativa (shortlist)</td>
<td class="py-3 px-4"><span class="inline-block px-2 py-0.5 text-xs font-bold rounded bg-amber-100 text-amber-800">Persona revisa</span></td>
<td class="py-3 pl-4">Agent crea shortlist con razonamiento. Reclutador revisa y decide sobre invitaciones.</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Coordinación de entrevistas</td>
<td class="py-3 px-4"><span class="inline-block px-2 py-0.5 text-xs font-bold rounded bg-blue-100 text-blue-800">Automático</span></td>
<td class="py-3 pl-4">Sincronización de calendarios, invitaciones, recordatorios. Proceso estándar.</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Realizar entrevista</td>
<td class="py-3 px-4"><span class="inline-block px-2 py-0.5 text-xs font-bold rounded bg-red-100 text-red-800">Persona decide</span></td>
<td class="py-3 pl-4">Conversación personal. No automatizable.</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Decisión de contratación</td>
<td class="py-3 px-4"><span class="inline-block px-2 py-0.5 text-xs font-bold rounded bg-red-100 text-red-800">Persona decide</span></td>
<td class="py-3 pl-4">Decisión de personal. El Comité de Empresa tiene derecho de información y consulta (Art. 64 ET). Discrecional.</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Crear oferta contractual</td>
<td class="py-3 px-4"><span class="inline-block px-2 py-0.5 text-xs font-bold rounded bg-emerald-100 text-emerald-800">Conjunto de reglas</span></td>
<td class="py-3 pl-4">Clasificación según convenio colectivo / banda salarial. Lógica determinista.</td>
</tr>
<tr>
<td class="py-3 pr-4 font-semibold text-gosign-dark">Formular rechazo</td>
<td class="py-3 px-4"><span class="inline-block px-2 py-0.5 text-xs font-bold rounded bg-blue-100 text-blue-800">Automático</span></td>
<td class="py-3 pl-4">Rechazo estándar cuando los criterios obligatorios claramente no se cumplen. Casos límite se escalan.</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- EU AI Act Alto Riesgo -->
<section class="py-section bg-gosign-dark text-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold">Por qué la AI en recruiting es alto riesgo - y qué significa</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4">
El EU AI Act clasifica explícitamente los sistemas de AI en recruiting como alto riesgo (Anexo III, N.º 4). Esa clasificación se mantiene; conforme a la legislación vigente, las obligaciones aplican desde agosto de 2026, con un aplazamiento a diciembre de 2027 acordado provisionalmente por el <a href="/es/revista/eu-ai-act-2026-empresas/" class="text-gosign-accent-on-dark hover:underline">paquete Digital Omnibus</a> (mayo de 2026, adopción formal aún pendiente). En España, AESIA (Agencia Española de Supervisión de la Inteligencia Artificial) supervisa el cumplimiento. Afecta a toda organización que use AI para screening de candidaturas, evaluación de candidatos o decisiones de contratación.
</p>
<div class="mt-8 space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-body-lg font-semibold text-white">Bias Monitoring es obligatorio</p>
<p class="text-body text-gosign-text-on-dark/70 mt-1">¿Se evalúan ciertos grupos sistemáticamente de forma diferente? El Decision Layer monitoriza estadísticamente todas las decisiones de screening y señala anomalías.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-body-lg font-semibold text-white">Supervisión humana forzada arquitectónicamente</p>
<p class="text-body text-gosign-text-on-dark/70 mt-1">Las decisiones de contratación no pueden automatizarse completamente. El Decision Layer fuerza Human-in-the-Loop para todas las decisiones de personal a nivel de arquitectura.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-body-lg font-semibold text-white">Transparencia para los candidatos</p>
<p class="text-body text-gosign-text-on-dark/70 mt-1">Los candidatos deben ser informados del uso de AI. El Audit Trail documenta la ruta completa de decisión para cada candidato.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-body-lg font-semibold text-white">Audit Trail por decisión</p>
<p class="text-body text-gosign-text-on-dark/70 mt-1">Cada decisión de screening: datos de entrada, conjunto de reglas aplicado, puntuación de confianza, resultado, marca temporal. No creado retrospectivamente sino generado automáticamente.</p>
</div>
</div>
<p class="text-body text-gosign-text-on-dark/60 mt-8">
→ <a href="/es/governance/eu-ai-act/" class="text-gosign-accent-on-dark hover:underline">EU AI Act Compliance en detalle</a>
</p>
</div>
</div>
</section>

<!-- Comité de Empresa -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">¿Cómo supervisa el Comité de Empresa la AI en recruiting?</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
El Comité de Empresa tiene derechos de información y consulta sobre la introducción de nuevas tecnologías en el lugar de trabajo (Art. 64 del Estatuto de los Trabajadores). Cuando la AI participa en la preselección, los representantes de los trabajadores quieren saber: ¿con qué criterios se filtra? ¿Quién definió los criterios? ¿Quién es responsable?
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
El Decision Layer da al Comité de Empresa exactamente esta transparencia:
</p>
<div class="mt-6 space-y-4">
<div class="flex items-start gap-3">
<span class="flex-shrink-0 w-6 h-6 rounded-full bg-gosign-accent text-white flex items-center justify-center text-sm font-bold">✓</span>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Criterios transparentes:</strong> Las reglas de screening son conjuntos de reglas versionados y documentados - no una caja negra.</p>
</div>
<div class="flex items-start gap-3">
<span class="flex-shrink-0 w-6 h-6 rounded-full bg-gosign-accent text-white flex items-center justify-center text-sm font-bold">✓</span>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Decisiones de contratación en manos de personas:</strong> El agent sugiere, la persona decide. Forzado arquitectónicamente, no opcional.</p>
</div>
<div class="flex items-start gap-3">
<span class="flex-shrink-0 w-6 h-6 rounded-full bg-gosign-accent text-white flex items-center justify-center text-sm font-bold">✓</span>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Audit Trail para cada candidatura:</strong> ¿Qué criterio condujo a la invitación o rechazo? Trazable en el portal de auditoría.</p>
</div>
<div class="flex items-start gap-3">
<span class="flex-shrink-0 w-6 h-6 rounded-full bg-gosign-accent text-white flex items-center justify-center text-sm font-bold">✓</span>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Informe de sesgo para el Comité de Empresa:</strong> Análisis estadístico de todas las decisiones de recruiting. ¿Se tratan ciertos grupos sistemáticamente de forma diferente?</p>
</div>
</div>
<p class="text-body text-gosign-text-light mt-6">
→ <a href="/es/governance/co-determination/" class="text-gosign-accent-text hover:underline">Derechos de consulta y AI Agents en detalle</a>
</p>
</div>
</div>
</section>

<!-- Potencial -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">¿Qué aporta un Recruiting Agent?</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Estudios sectoriales estiman el potencial de automatización en recruiting en un 70-75%. Eso no significa 75% menos reclutadores. Significa: el 75% de los pasos del proceso pueden acelerarse con agents - parsing de CVs, matching de requisitos, programación, comunicación estándar.
</p>
<div class="mt-6 space-y-4">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark">Reducir el tiempo de contratación</p>
<p class="text-body-lg text-gosign-text-light mt-2">De 90 a 30-45 días. No por decisiones más rápidas, sino eliminando tiempos de espera: screening en horas en vez de semanas, coordinación automática de entrevistas, comunicación estándar inmediata.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark">Evaluación consistente</p>
<p class="text-body-lg text-gosign-text-light mt-2">Cada candidato se evalúa contra el mismo conjunto de reglas. Independientemente de qué reclutador gestione la posición o si es lunes por la mañana o viernes por la tarde.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark">Más tiempo para los candidatos</p>
<p class="text-body-lg text-gosign-text-light mt-2">Los reclutadores dedican tiempo a conversaciones en lugar de introducción de datos. La calidad de la experiencia del candidato mejora porque las personas se centran en lo que solo las personas pueden hacer.</p>
</div>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">Casos de Uso</h2>
<div class="grid grid-cols-1 gap-6 lg:gap-8 lg:grid-cols-3">
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<h3 class="text-h3 font-bold text-gosign-dark">Matching de Requisitos</h3>
<p class="text-body text-gosign-text-light mt-3">CV contra perfil de requisitos. Cada criterio verificado, cada brecha documentada. Consistente en todas las posiciones.</p>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<h3 class="text-h3 font-bold text-gosign-dark">Screening de Volumen</h3>
<p class="text-body text-gosign-text-light mt-3">Cientos de solicitudes, mismo estándar de calidad. Sin sesgo por fatiga, sin inconsistencia entre evaluaciones matutinas y vespertinas.</p>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<h3 class="text-h3 font-bold text-gosign-dark">Documentación de Compliance</h3>
<p class="text-body text-gosign-text-light mt-3">Cada rechazo trazable. Cada evaluación documentada con referencia a criterio. Listo para revisión del comité de empresa.</p>
</article>
</div>
</div>
</section>

<section class="bg-gosign-dark text-white py-section">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold">Governance y Compliance</h2>
<div class="mt-8 space-y-4">
<p class="text-body-lg text-gosign-text-on-dark/80 flex items-start gap-3">
<svg class="w-5 h-5 mt-1 flex-shrink-0 text-gosign-accent" fill="currentColor" viewBox="0 0 20 20"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span>Decisión Humana: La decisión de contratación siempre es humana. El agent evalúa y documenta.</span>
</p>
<p class="text-body-lg text-gosign-text-on-dark/80 flex items-start gap-3">
<svg class="w-5 h-5 mt-1 flex-shrink-0 text-gosign-accent" fill="currentColor" viewBox="0 0 20 20"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span>Prevención de Sesgo: Evaluación contra criterios definidos. Datos demográficos excluibles arquitectónicamente.</span>
</p>
<p class="text-body-lg text-gosign-text-on-dark/80 flex items-start gap-3">
<svg class="w-5 h-5 mt-1 flex-shrink-0 text-gosign-accent" fill="currentColor" viewBox="0 0 20 20"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span>EU AI Act: Categoría de alto riesgo. Transparencia, supervisión humana y registro cumplidos by design.</span>
</p>
<p class="text-body-lg text-gosign-text-on-dark/80 flex items-start gap-3">
<svg class="w-5 h-5 mt-1 flex-shrink-0 text-gosign-accent" fill="currentColor" viewBox="0 0 20 20"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span>Audit Trail: Cada decisión de screening documentada, versionada, exportable.</span>
</p>
</div>
</div>
</div>
</section>

<!-- Este agente en el catálogo -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark">¿Cuándo empezar? Priorización y preparación de governance</h2>
<p class="text-body text-gosign-text mt-4">El catálogo de agentes HR muestra puntuaciones, complejidad de gobernanza, clasificación EU AI Act y la tabla completa de microdecisiones para este agente - posicionado en 3 cuadrantes de priorización junto a 47 agentes HR más.</p>
<a href="/es/catalogo-agentes-hr/candidate-screening-agent/" class="inline-flex items-center gap-2 mt-4 text-body font-semibold text-gosign-accent hover:underline">Ver secuenciación y scores &rarr;</a>
</div>
</section>

<!-- Profundización en el Agent Briefing -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">Profundización en el Agent Briefing (Revista Gosign)</h2>
<div class="grid md:grid-cols-3 gap-6">
<a href="/es/revista/eu-ai-act-hr/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<h3 class="text-h3 font-bold text-gosign-dark">EU AI Act y RRHH</h3>
</a>
<a href="/es/revista/comite-empresa-ia-codeterminacion/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<h3 class="text-h3 font-bold text-gosign-dark">Comité de Empresa e IA - Codecisión</h3>
</a>
<a href="/es/revista/agent-governance-hr/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR</p>
<h3 class="text-h3 font-bold text-gosign-dark">Agent Governance para RRHH</h3>
</a>
</div>
</div>
</section>

--- Referencias industria | Webs y digitalización ---
> Referencias de Gosign en industria y maquinaria: sitios web B2B, configuradores de producto, herramientas de venta digital.

<!-- Gosign en la industria -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Gosign en el sector industrial</h2>
<p class="text-body text-gosign-text leading-relaxed">
Gosign desarrolla soluciones digitales para empresas industriales y de maquinaria: sitios web B2B, configuradores de producto, portales de distribuidores, plataformas de documentación técnica y herramientas de venta digital. El sector plantea requisitos especiales: datos de producto complejos, catálogos multilingües, integración con sistemas PIM/ERP, ciclos de decisión largos.
</p>
</div>
</section>

<!-- Qué construye Gosign -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Qué construye Gosign para clientes industriales</h2>
<ul class="space-y-4">
<li class="flex items-start gap-3">
<span class="flex-shrink-0 mt-1.5 w-2 h-2 bg-gosign-accent rounded-full"></span>
<div>
<span class="font-bold text-gosign-dark">Sitios web B2B</span>
<span class="text-body text-gosign-text">: responsive, con alto rendimiento, con buscador de productos y enrutamiento de contacto al distribuidor adecuado</span>
</div>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 mt-1.5 w-2 h-2 bg-gosign-accent rounded-full"></span>
<div>
<span class="font-bold text-gosign-dark">Configuradores de producto</span>
<span class="text-body text-gosign-text">: configuradores interactivos que consultan parámetros técnicos y recomiendan productos adecuados</span>
</div>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 mt-1.5 w-2 h-2 bg-gosign-accent rounded-full"></span>
<div>
<span class="font-bold text-gosign-dark">Portales de distribuidores</span>
<span class="text-body text-gosign-text">: áreas protegidas por login para distribuidores: listas de precios, documentación técnica, herramientas de pedido</span>
</div>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 mt-1.5 w-2 h-2 bg-gosign-accent rounded-full"></span>
<div>
<span class="font-bold text-gosign-dark">Catálogos multilingües</span>
<span class="text-body text-gosign-text">: catálogos de productos basados en TYPO3 con conexión PIM, traducción automática y variantes regionales</span>
</div>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 mt-1.5 w-2 h-2 bg-gosign-accent rounded-full"></span>
<div>
<span class="font-bold text-gosign-dark">Herramientas de venta digital</span>
<span class="text-body text-gosign-text">: presentaciones de producto para tablet, catálogos offline, generadores de presupuestos</span>
</div>
</li>
</ul>
</div>
</section>

<!-- Tabla de tecnologías -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Tecnologías en el entorno industrial</h2>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Requisito</th>
<th class="py-3 text-small font-bold text-gosign-dark">Solución Gosign</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">CMS</td>
<td class="py-3 text-body text-gosign-text">TYPO3 (Enterprise) o WordPress (orientado a contenido)</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Integración PIM</td>
<td class="py-3 text-body text-gosign-text">Akeneo, Pimcore, conexión personalizada</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Conexión ERP</td>
<td class="py-3 text-body text-gosign-text">SAP, Microsoft Dynamics, API personalizada</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Multilingüe</td>
<td class="py-3 text-body text-gosign-text">TYPO3 nativo, hasta 30+ idiomas</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Rendimiento</td>
<td class="py-3 text-body text-gosign-text">Cloudflare CDN, Edge Caching, generación estática</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Hablar sobre su proyecto industrial: 30&nbsp;minutos, gratis.</h3>
<p class="text-body text-gosign-text mb-6">Analizamos su proyecto, estimamos esfuerzo y plazos, sin compromiso.</p>
<a
href="/es/contacto/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Reservar cita
</a>
<p class="text-small text-gosign-text-light mt-4">25 años de experiencia · 800+ extensiones · Desarrollo acelerado por IA</p>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
Gosign es una agencia digital con sede en Hamburgo y 25 años de experiencia en desarrollo web, TYPO3 e integración de IA.
Hemos analizado más de 800 extensiones TYPO3 y hoy desarrollamos con apoyo de IA
hasta un 70&nbsp;% más rápido que con métodos tradicionales. Nuestros clientes son empresas
medianas, universidades e instituciones europeas.
</p>
<p class="text-small text-gosign-text-light mt-2">Actualizado: febrero 2026</p>
</div>
</section>

--- Case Study: Pilot Gruppe - Infraestructura de IA en Azure ---
> Infraestructura de IA conforme al RGPD y model-agnóstica con control de acceso y Human-in-the-Loop en el entorno Azure de Pilot Gruppe.

<!-- Situación inicial -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Situación inicial</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Pilot Gruppe necesitaba una infraestructura de IA construida sobre su entorno existente de Microsoft Azure. Requisitos clave:
</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light">La soberanía de datos debe permanecer dentro de la organización</li>
<li class="text-body-lg text-gosign-text-light">Autenticación mediante Azure Entra ID existente (SSO)</li>
<li class="text-body-lg text-gosign-text-light">Control de acceso departamental - datos de HR solo para HR</li>
<li class="text-body-lg text-gosign-text-light">Múltiples modelos de IA utilizables en paralelo</li>
<li class="text-body-lg text-gosign-text-light">Conformidad con RGPD verificada con evaluación independiente antes del lanzamiento</li>
</ul>
</div>
</section>

<!-- Implementación -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Implementación</h2>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">Arquitectura multi-modelo</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
En lugar de dependencia de un solo proveedor: arquitectura model-agnóstica con selección por caso de uso. Modelos implementados: GPT-5.5, Gemini 3.1 Pro, Claude Opus 4.7 y Mistral Small 3.2 para texto/razonamiento, Flux para generación de imágenes. Los empleados eligen la combinación de modelos ellos mismos - según la tarea. La arquitectura model-agnóstica permitió la actualización fluida de GPT-4o a GPT-5.5 sin cambios en el código del chat-interface.
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">Control de acceso vía Azure Entra ID</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Los grupos de seguridad existentes en Azure Entra ID se vincularon directamente con la interfaz de IA. Sin nueva gestión de usuarios, sin autenticación adicional.
</p>
<p class="text-body-lg text-gosign-text-light mt-2">
Resultado: Marketing ve diferentes modelos de IA y agentes que HR. Los datos sensibles como salarios permanecen dentro del grupo de seguridad de HR - invisibles para otros departamentos.
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">Progressive Web App (PWA)</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
La interfaz se construyó como PWA - funciona en Windows y macOS sin instalación. Atajos de teclado para usuarios avanzados. Drag & drop para subida de archivos.
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">Evaluación RGPD antes del lanzamiento</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Toda la arquitectura fue analizada antes del lanzamiento por el delegado de protección de datos de Pilot Gruppe y por el Dr. Frank Eickmeier (unverzagt.law). La evaluación positiva del RGPD confirma la conformidad.
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">Agentes de IA en plataforma n8n</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Los agentes de IA operan en la plataforma n8n configurada en la infraestructura de Pilot, accesibles a través de múltiples canales: interfaz, Microsoft Teams y otros canales de colaboración. Human-in-the-Loop está implementado: los agentes interactúan directamente con los departamentos relevantes cuando se necesita aclaración.
</p>
</div>
</section>

<!-- Resultado -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Resultado</h2>
<ul class="mt-6 space-y-3">
<li class="text-body-lg text-gosign-text-light">Todos los datos permanecen en el entorno Azure de Pilot Gruppe - conforme al RGPD</li>
<li class="text-body-lg text-gosign-text-light">La infraestructura de TI y autenticación existentes se reutilizan</li>
<li class="text-body-lg text-gosign-text-light">Model-agnóstica: nuevos modelos integrables sin cambios en la arquitectura</li>
<li class="text-body-lg text-gosign-text-light">Workspaces departamentales con Role-Based Access Control</li>
<li class="text-body-lg text-gosign-text-light">Los empleados crean de forma independiente asistentes de IA y agentes</li>
<li class="text-body-lg text-gosign-text-light">Compartición de agentes entre departamentos controlada por TI</li>
<li class="text-body-lg text-gosign-text-light">Evaluación RGPD independiente antes del lanzamiento</li>
</ul>
</div>
</section>

<!-- Tecnología -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Tecnología</h2>
<ul class="mt-6 space-y-2">
<li class="text-body-lg text-gosign-text-light">Microsoft Azure (entorno del cliente)</li>
<li class="text-body-lg text-gosign-text-light">Azure Entra ID (SSO, RBAC)</li>
<li class="text-body-lg text-gosign-text-light">n8n (orquestación de agentes)</li>
<li class="text-body-lg text-gosign-text-light">Múltiples LLMs (GPT-5.5, Gemini 3.1 Pro, Claude Opus 4.7, Mistral Small 3.2, Flux)</li>
<li class="text-body-lg text-gosign-text-light">PWA (Progressive Web App)</li>
</ul>
</div>
</section>

<!-- Contribución de Gosign -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Contribución de Gosign</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Concepción, implementación, deployment, formación, soporte continuo. Más allá de la infraestructura de IA, Gosign construyó una plataforma de agentes completa: los empleados crean de forma independiente asistentes de IA y agentes, mientras TI controla el uso compartido de agentes entre departamentos. El departamento de TI de Pilot Gruppe gestiona toda la plataforma con sus conocimientos Azure existentes - sin necesidad de nuevas herramientas.
</p>
</div>
</section>

--- pilot Agency Group: infraestructura de IA conforme al RGPD para 1.000 empleados ---
> Cómo la segunda agencia de medios independiente más grande de Alemania construyó una infraestructura de IA con residencia de datos completa en la UE.

## Punto de partida

pilot es uno de los grupos de agencias independientes más grandes de Alemania, gestionado por sus propietarios. Con más de 1.000 empleados en siete ubicaciones, pilot atiende a clientes como Dr. Oetker, OBI, Techniker Krankenkasse y GetYourGuide. Como agencia de medios, pilot procesa diariamente grandes volúmenes de datos de campañas, datos de clientes y documentos de estrategia de medios.

El desafío: pilot quería desplegar herramientas de IA en toda la empresa, para investigación, análisis de documentos, planificación de campañas y una base de conocimiento interna. El requisito de Bosse Küllenberg, Director General de Tecnología y Operaciones, era inequívoco: ningún dato puede salir de la UE. Ningún compromiso con el RGPD. Y ninguna dependencia de proveedor.

En aquel momento, la mayoría de proveedores de IA no ofrecían residencia de datos garantizada en la UE. ChatGPT Enterprise aún no estaba disponible, y las alternativas existentes no podían cumplir los requisitos de una agencia de medios que maneja datos sensibles de clientes.


## Requisitos

Bosse Küllenberg definió cuatro requisitos innegociables para la infraestructura de IA.

Primero: residencia de datos completa en la UE. Todos los datos (prompts, respuestas, documentos subidos) deben permanecer en la UE. Sin servidores en EE.UU., sin transferencias transatlánticas de datos, sin excepciones.

Segundo: separación de mandantes. pilot atiende a clientes de industrias muy diferentes. Los datos de un cliente no pueden bajo ninguna circunstancia entrar en el contexto de otro cliente. Esto requiere un aislamiento estricto de datos a nivel de infraestructura.

Tercero: independencia de modelo. La infraestructura no puede estar atada a un solo LLM. Cuando aparezca un modelo mejor, el cambio debe ser posible sin reconstrucción arquitectónica.

Cuarto: trazabilidad. Para el cumplimiento interno y frente a los clientes, debe estar documentado qué datos se procesan y qué modelo se utiliza.


## Solución

Gosign implementó una [infraestructura de IA](/es/servicios/infraestructura/) con las siguientes propiedades.

La infraestructura funciona íntegramente en una región de la UE (Germany West Central en Azure). Ningún prompt, ningún documento, ninguna respuesta sale de la UE. La residencia de datos no solo está asegurada contractualmente sino impuesta arquitectónicamente: simplemente no existe un camino por el cual los datos puedan salir de la UE.

La separación de mandantes opera a nivel de infraestructura. Cada equipo trabaja en un contexto aislado. Los documentos subidos, los historiales de conversación y el contenido generado están estrictamente separados.

La arquitectura es [agnóstica de modelos](/es/servicios/infraestructura/). La capa de orquestación enruta las solicitudes al modelo óptimo; actualmente varios modelos funcionan en paralelo. Un cambio de modelo requiere un cambio de configuración, no una reconstrucción arquitectónica.

Cada interacción se registra: marca de tiempo, modelo utilizado, asignación de contexto. No se almacena el contenido de los prompts, sino los metadatos, suficientes para evidencias de cumplimiento sin violar la confidencialidad.


## Resultado

pilot dispone de una infraestructura de IA que trata el cumplimiento del RGPD no como un compromiso sino como un principio de diseño. Más de 1.000 empleados utilizan la infraestructura a diario, para investigación, análisis de documentos y trabajo de campañas.

La residencia de datos en la UE está plenamente garantizada. La separación de mandantes previene cualquier forma de fuga de datos entre equipos de clientes. La arquitectura agnóstica de modelos ya ha permitido dos cambios de modelo sin interrupción operativa.

Bosse Küllenberg tenía desde el principio una visión clara de cómo debe ser la infraestructura de IA en un entorno regulado. Gosign tradujo esa visión en tecnología: limpia, auditable y preparada para el futuro.


## Métricas

| Métrica | Valor |
|---------|-------|
| Empleados con acceso | 1.000+ |
| Ubicaciones conectadas | 7 |
| Residencia de datos en la UE | 100% |
| Cambios de modelo sin reconstrucción | 2 completados |
| Dependencia de proveedor | Ninguna |

--- Referencias - Gosign Enterprise AI Infrastructure ---
> Empresas que confian en la infraestructura de Gosign. Casos de estudio en medios, servicios profesionales y logistica.

<!-- Referencia 1: pilot -->
<section class="py-16 lg:py-24 bg-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid lg:grid-cols-2 gap-12 items-start">
<div>
<span class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider">Agencia de Medios · 1.000 Empleados</span>
<h2 class="text-h2 font-bold text-gosign-dark mt-2 mb-4">pilot Agency Group</h2>
<p class="text-body text-gosign-text leading-relaxed mb-4">
La segunda agencia de medios independiente más grande de Alemania necesitaba una infraestructura de IA que tratara el cumplimiento del RGPD no como una restricción, sino como un principio arquitectónico, para más de 1.000 empleados en siete sedes.
</p>
<p class="text-body text-gosign-text leading-relaxed mb-6">
Gosign proporcionó una infraestructura self-hosted con residencia de datos completa en la UE, antes de que otros proveedores hubieran siquiera priorizado el tema.
</p>
<blockquote class="border-l-4 border-gosign-accent pl-4 italic text-gosign-text mb-6">
<div class="flex items-start gap-4 not-italic mb-3">
<img src="/images/logos/pilot-v2.svg" alt="pilot Agency Group Logo" class="w-24 h-auto opacity-80" width="91" height="45" loading="lazy" />
</div>
"Para mí estuvo claro desde el principio: ningún dato fuera de la UE, ningún compromiso con el RGPD. Gosign entregó exactamente eso - técnicamente impecable, sin peros."
<footer class="mt-4 flex items-center gap-4 text-small not-italic text-gosign-dark">
<img src="/images/testimonials/t1.webp" alt="" class="w-14 h-14 rounded-full object-cover ring-2 ring-gray-100" width="56" height="56" loading="lazy" />
<div>
<p class="font-semibold leading-tight"><img src="/images/testimonials/t1-n.svg" alt="" width="140" height="17" style="height:1.15em;width:auto;max-width:none;display:block" loading="lazy" /></p>
<p class="font-normal text-gosign-text-light mt-0.5">Director General Technology &amp; Operations, pilot</p>
</div>
</footer>
</blockquote>
<a href="/es/referencias/pilot-ai/" class="text-gosign-accent-text font-semibold hover:underline">
Leer caso de estudio →
</a>
</div>
<div class="bg-gosign-light rounded-card p-8">
<dl class="space-y-4 text-body">
<div><dt class="font-semibold text-gosign-dark">Sector</dt><dd class="text-gosign-text">Medios y Comunicación</dd></div>
<div><dt class="font-semibold text-gosign-dark">Empleados</dt><dd class="text-gosign-text">1.000+</dd></div>
<div><dt class="font-semibold text-gosign-dark">Sedes</dt><dd class="text-gosign-text">Hamburgo, Berlín, Múnich, Stuttgart, Núremberg, Maguncia, Zúrich</dd></div>
<div><dt class="font-semibold text-gosign-dark">Enfoque</dt><dd class="text-gosign-text">Infraestructura de IA conforme al RGPD, residencia de datos en la UE</dd></div>
<div><dt class="font-semibold text-gosign-dark">Servicios</dt><dd class="text-gosign-text"><a href="/es/servicios/infraestructura/" class="text-gosign-accent-text hover:underline">Infraestructura de IA</a>, <a href="/es/servicios/ai-agents/" class="text-gosign-accent-text hover:underline">Plataforma de agentes</a></dd></div>
</dl>
</div>
</div>
</div>
</section>

<!-- Referencia 2: Roser -->
<section class="py-16 lg:py-24 bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid lg:grid-cols-2 gap-12 items-start">
<div>
<span class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider">Asesoría Jurídica · Asesoría Fiscal · Auditoría · 100 Empleados</span>
<h2 class="text-h2 font-bold text-gosign-dark mt-2 mb-4">Roser Abogados Auditores Asesores Fiscales</h2>
<p class="text-body text-gosign-text leading-relaxed mb-4">
Una firma multidisciplinar con 38 profesionales colegiados que audita a otros en materia de compliance y, por lo tanto, aplica los más altos estándares a su propia infraestructura de IA: secreto profesional conforme a la normativa alemana (§ 203 StGB, BRAO, StBerG, WPO - legislación alemana de secreto profesional para abogados, asesores fiscales y auditores).
</p>
<p class="text-body text-gosign-text leading-relaxed mb-6">
Gosign proporcionó una infraestructura self-hosted con separación criptográfica de mandantes, Decision Layer y audit trail completo, documentado para superar la revisión colegial.
</p>
<blockquote class="border-l-4 border-gosign-accent pl-4 italic text-gosign-text mb-6">
<div class="flex items-start gap-4 not-italic mb-3">
<img src="/images/logos/roser.svg" alt="Roser Abogados Auditores Asesores Fiscales Logo" class="h-12 w-auto opacity-80" width="947" height="138" loading="lazy" />
</div>
"Como asesores fiscales y auditores, auditamos a otros en materia de compliance - por eso nuestros propios sistemas deben ser irreprochables. La arquitectura de governance de Gosign cumple exactamente los estándares que aplicamos a nuestros clientes."
<footer class="mt-4 flex items-center gap-4 text-small not-italic text-gosign-dark">
<img src="/images/testimonials/t2.webp" alt="" class="w-14 h-14 rounded-full object-cover ring-2 ring-gray-100" width="56" height="56" loading="lazy" />
<div>
<p class="font-semibold leading-tight"><img src="/images/testimonials/t2-n.svg" alt="" width="105" height="17" style="height:1.15em;width:auto;max-width:none;display:block" loading="lazy" /></p>
<p class="font-normal text-gosign-text-light mt-0.5">Director General, Roser Rechtsanwaltsgesellschaft mbH</p>
</div>
</footer>
</blockquote>
</div>
<div class="bg-white rounded-card p-8">
<dl class="space-y-4 text-body">
<div><dt class="font-semibold text-gosign-dark">Sector</dt><dd class="text-gosign-text">Asesoría Jurídica, Asesoría Fiscal, Auditoría</dd></div>
<div><dt class="font-semibold text-gosign-dark">Empleados</dt><dd class="text-gosign-text">100 (38 profesionales colegiados)</dd></div>
<div><dt class="font-semibold text-gosign-dark">Sedes</dt><dd class="text-gosign-text">Hamburgo, Leipzig</dd></div>
<div><dt class="font-semibold text-gosign-dark">Enfoque</dt><dd class="text-gosign-text">IA conforme al secreto profesional, Decision Layer, audit trail</dd></div>
<div><dt class="font-semibold text-gosign-dark">Servicios</dt><dd class="text-gosign-text"><a href="/es/finance-ai-agents/" class="text-gosign-accent-text hover:underline">Finance Agent</a>, <a href="/es/servicios/infraestructura/" class="text-gosign-accent-text hover:underline">Infraestructura de IA</a></dd></div>
</dl>
</div>
</div>
</div>
</section>

<!-- Referencia 3: Anonimizada (Logística comercial) -->
<section class="py-16 lg:py-24 bg-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid lg:grid-cols-2 gap-12 items-start">
<div>
<span class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider">Logística Comercial · 500+ Empleados</span>
<h2 class="text-h2 font-bold text-gosign-dark mt-2 mb-4">Empresa de Logística Comercial del Norte de Alemania</h2>
<p class="text-body text-gosign-text leading-relaxed mb-4">
Una empresa consolidada de logística comercial con más de 500 empleados y una de las infraestructuras de TI y logística más eficientes de su sector confía en Gosign como socio estratégico de consultoría para la integración de IA.
</p>
<p class="text-body text-gosign-text leading-relaxed mb-6">
Enfoque: consultoría estratégica para la integración de AI Agents en atención al cliente. La colaboración se centra en cómo el soporte basado en IA puede integrarse en un paisaje de TI complejo y consolidado, sin interrumpir las operaciones en curso.
</p>
</div>
<div class="bg-gosign-light rounded-card p-8">
<dl class="space-y-4 text-body">
<div><dt class="font-semibold text-gosign-dark">Sector</dt><dd class="text-gosign-text">Logística Comercial</dd></div>
<div><dt class="font-semibold text-gosign-dark">Empleados</dt><dd class="text-gosign-text">500+</dd></div>
<div><dt class="font-semibold text-gosign-dark">Sede</dt><dd class="text-gosign-text">Norte de Alemania</dd></div>
<div><dt class="font-semibold text-gosign-dark">Enfoque</dt><dd class="text-gosign-text">Consultoría estratégica, atención al cliente con IA</dd></div>
<div><dt class="font-semibold text-gosign-dark">Servicios</dt><dd class="text-gosign-text"><a href="/es/servicios/ai-agents/" class="text-gosign-accent-text hover:underline">AI Agents</a>, <a href="/es/servicios/infraestructura/" class="text-gosign-accent-text hover:underline">Infraestructura de IA</a></dd></div>
</dl>
</div>
</div>
</div>
</section>

--- Acta de decisión: por qué toda decisión de IA debe ser impugnable ---
> Art. 86 del EU AI Act: derecho a la explicación de la decisión individual. Chat-logs y model cards no lo cumplen. El acta de decisión sí.

Se rechaza a un candidato. Se deniega una gratificación extraordinaria. Un encuadramiento profesional resulta más bajo de lo esperado. En los tres casos intervino un agente de IA - y en los tres casos el afectado podrá pronto decir una frase antes reservada a los abogados: "Explíqueme el papel del sistema de IA y los elementos principales de esta decisión."

No es un escenario hipotético. Es el núcleo literal del artículo 86 del [Reglamento (UE) 2024/1689](https://artificialintelligenceact.eu/article/86/) - el artículo más subestimado del EU AI Act. El sector debate sobre documentación de modelos, clases de riesgo y plazos. El artículo 86 plantea otra pregunta: ¿puede explicar una decisión concreta, una sola? No su sistema. Esta decisión.

La mayoría de las empresas no puede. No porque su IA sea mala - sino porque su arquitectura documenta la unidad equivocada. Registran conversaciones, tokens y comportamiento del sistema. Pero solo es impugnable lo que se haya fijado como decisión. Este artículo describe el artefacto que falta: el acta de decisión.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">De un vistazo - El acta de decisión</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Solo es impugnable lo que se haya fijado como decisión. El acta de decisión es el registro atómico e inmutable de una única microdecisión: input, regla de negocio aplicada con su versión y fuente, resultado, confianza, versión del modelo, marca de tiempo, vía de impugnación. Los logs responden "¿Qué ocurrió?" - el acta de decisión responde "¿Por qué se decidió así?".</li>
<li>El art. 86 del EU AI Act da al afectado derecho a la explicación de la decisión individual - y el TJUE ya exige hoy la misma motivación del caso concreto bajo el RGPD. La descripción del sistema no basta.</li>
<li>Los chat-logs, los traces de observability y las model cards documentan interacción, infraestructura y sistema - pero no la justificación profesional. La propia documentación de Microsoft lo confirma: el audit-log de Copilot no captura ni el contenido de los prompts ni la versión del modelo. Y los textos de razonamiento de los modelos de lenguaje reflejan, según la investigación de Anthropic, la base real de la decisión solo en uno de cada cuatro casos.</li>
<li>Un agente de IA nunca toma "una decisión" - toma decenas de microdecisiones por expediente. Cada una puede ser jurídicamente relevante: el TJUE considera ya el scoring automatizado como decisión, no solo el resultado final.</li>
<li>La impugnabilidad no se añade a posteriori: una decisión que nunca se modeló como decisión no puede motivarse después. Por eso el acta de decisión es un principio arquitectónico del Decision Layer - no una función de compliance.</li>
</ul>
</div>

## IA agéntica significa: transferir derechos de decisión

Las cifras de las grandes consultoras cuentan en 2026 una historia coherente. [McKinsey](https://www.mckinsey.com/capabilities/quantumblack/our-insights/seizing-the-agentic-ai-advantage) lo llama la paradoja de la IA generativa: casi ocho de cada diez empresas usan IA generativa, y una proporción casi igual de grande no ve ningún efecto medible en resultados - porque los copilotos horizontales se despliegan de forma amplia mientras los casos de uso verticales, los que crean valor, no pasan de la fase piloto. [Gartner](https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027) pronostica que más del 40 por ciento de los proyectos de IA agéntica se cancelarán para finales de 2027 - de forma expresa también por controles de riesgo insuficientes. La misma previsión espera que para 2028 al menos el 15 por ciento de las decisiones de trabajo cotidianas las tomen de forma autónoma agentes de IA.

Las dos afirmaciones juntas componen la verdadera tensión: las empresas transfieren derechos de decisión a las máquinas sin poseer la infraestructura para responder por esas decisiones. McKinsey enmarca la era agéntica en exactamente esos términos en su estudio de confianza de 2026 - la pregunta rectora se desplaza de "¿Es preciso el modelo?" a "¿Quién responde cuando el sistema actúa?" ([State of AI trust in 2026](https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/tech-forward/state-of-ai-trust-in-2026-shifting-to-the-agentic-era)).

La brecha de gobernanza está cuantificada en todas las fuentes:

| Hallazgo | Cifra | Fuente |
|---|---|---|
| Proyectos de IA agéntica cancelados para finales de 2027 - entre otras causas, por controles de riesgo insuficientes | más del 40% | [Gartner, 2025](https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027) |
| Empresas con gobernanza madura para agentes autónomos | solo el 21% | [Deloitte, 2025](https://www.deloitte.com/us/en/insights/topics/emerging-technologies/ai-agents-scaling-faster.html) |
| Directivos de tecnología cuya adopción de IA ya supera su propia capacidad de gobernanza | 77% | [IBM IBV, 2026](https://www.cio.com/article/4182288/cios-are-being-held-accountable-for-ai-they-dont-fully-control-ibm-study-finds.html) |
| CIO/CTO que rinden cuentas por sistemas de IA que no controlan del todo | en torno a dos tercios | [IBM IBV, 2026](https://www.cio.com/article/4182288/cios-are-being-held-accountable-for-ai-they-dont-fully-control-ibm-study-finds.html) |
| Incidentes de IA notificados en 2024 - máximo histórico, +56,4% respecto al año anterior | 233 | [Stanford HAI AI Index, 2025](https://hai.stanford.edu/ai-index/2025-ai-index-report/responsible-ai) |
| Menos incidentes de IA cuando la gobernanza está embebida directamente en el sistema en lugar de la supervisión manual | 25% | [IBM IBV, 2026](https://www.ibm.com/thought-leadership/institute-business-value/en-us/report/ai-governance-trends) |

La última fila es la más importante: la gobernanza embebida funciona de forma medible mejor que el control a posteriori. Justo aquí la pregunta se vuelve concreta: qué significa "embebida" en términos técnicos. Y donde más se agudiza es en RRHH: transferir derechos de decisión a agentes desplaza el modelo operativo - y cada una de esas decisiones recae sobre una persona concreta: su parte de baja, su retribución, su encuadramiento. La respuesta empieza por la ley.

## Qué exige el artículo 86 - y por qué la documentación del sistema no lo cumple

El EU AI Act conoce dos niveles de transparencia radicalmente distintos que el debate de compliance mezcla constantemente:

| Nivel | Base jurídica | Destinatario | Momento | Responde a la pregunta |
|---|---|---|---|---|
| Transparencia del sistema | Art. 11 (documentación técnica), Art. 13 (instrucciones de uso para el responsable) | autoridad, responsable del despliegue | antes de la puesta en servicio | "¿Cómo funciona el sistema en general?" |
| Explicación del caso individual | Art. 86 AI Act, art. 15.1.h y art. 22 RGPD | la persona afectada | después de la decisión | "¿Por qué salió así esta decisión concreta?" |

[El artículo 86](https://artificialintelligenceact.eu/article/86/) da a toda persona que sea objeto de una decisión basada en un sistema de IA de alto riesgo del Anexo III, y que se vea afectada jurídicamente o de modo similarmente significativo, un derecho frente al responsable del despliegue: a explicaciones claras y significativas sobre el papel del sistema de IA en el procedimiento de decisión y sobre los elementos principales de la decisión adoptada. Eso está formulado respecto al caso, no respecto al sistema. Una model card describe el modelo. El artículo 86 pregunta por el caso.

El Tribunal de Justicia de la Unión Europea ya ha desarrollado el mismo principio para el RGPD - en dos sentencias que debería conocer cualquiera que responda por decisiones de IA:

**[SCHUFA, C-634/21](https://eur-lex.europa.eu/legal-content/ES/TXT/?uri=CELEX:62021CJ0634) (diciembre de 2023):** ya la elaboración automatizada de un valor de scoring es una decisión individual automatizada en el sentido del art. 22 RGPD, en cuanto un tercero le atribuye una importancia determinante. La consecuencia va mucho más allá del scoring crediticio: la obligación de trazabilidad se activa en la propia evaluación automática - no solo en la decisión final posterior que firma una persona.

**[Dun & Bradstreet Austria, C-203/22](https://www.dpcuria.eu/case?reference=C-203%2F22) (febrero de 2025):** el responsable debe explicar el procedimiento efectivamente aplicado de manera que la persona afectada pueda comprender cuáles de sus datos se utilizaron, y de qué modo, en la decisión. Una explicación contrafáctica puede bastar - por ejemplo: ¿con qué variación de los datos de entrada habría salido otro resultado? Y los secretos comerciales no justifican una negativa global; en caso de conflicto, la información debe revelarse a la autoridad o al tribunal competente, que entonces ponderan.

Una explicación contrafáctica por caso presupone que los datos de entrada realmente usados y la regla aplicada estén disponibles de forma estructurada por decisión. A partir de una descripción global del sistema no se puede reconstruir.

A esto se añade un matiz que el debate de compliance suele pasar por alto: el [art. 12](https://artificialintelligenceact.eu/article/12/) obliga a los sistemas de alto riesgo al registro automático durante toda su vida útil, y el [art. 26.6](https://artificialintelligenceact.eu/article/26/) obliga al responsable del despliegue a conservar esos registros al menos seis meses. Pero la ley solo define el contenido obligatorio de los registros para los sistemas biométricos. Para los sistemas de RRHH y finanzas, el AI Act exige la capacidad de registro - y deja abierto el esquema de contenido. Qué se fija por decisión es una tarea de diseño del responsable. Quien aquí solo registra consumo de tokens y marcas de tiempo cumple la letra del art. 12 y fracasa en el art. 86.

Para situar los plazos: conforme a la legislación vigente, las obligaciones de alto riesgo se aplican desde el 2 de agosto de 2026; el aplazamiento al 2 de diciembre de 2027 acordado provisionalmente en el Digital Omnibus el 7 de mayo de 2026 aún no está formalmente adoptado. No cambia nada en la clasificación de alto riesgo de los procesos de RRHH ([Anexo III, n.o 4](https://artificialintelligenceact.eu/annex/3/)) - ni en el deber civil de explicar decisiones, que [rige desde hace tiempo en todo el mundo](/es/revista/eu-ai-act-aplica-en-todo-el-mundo/). Las prohibiciones de prácticas de IA inaceptables, por su parte, están en vigor desde el 2 de febrero de 2025. Los detalles de plazos y obligaciones los aborda [EU AI Act 2026: estado, plazos, necesidad de actuar](/es/revista/eu-ai-act-2026-empresas/).

## No existe "una decisión de IA" - existen decenas de microdecisiones

Quien se toma en serio el artículo 86 en la operativa choca de inmediato con un problema de granularidad: ¿qué es exactamente "la decisión"?

<div class="not-prose my-10 grid grid-cols-1 md:grid-cols-2 gap-4">
  <div class="border border-base rounded-soft overflow-hidden bg-surface-dim opacity-90">
    <div class="px-4 py-2.5 border-b border-base font-code text-xs uppercase tracking-wider text-muted">UNA &#8220;DECISI&#211;N DE IA&#8221;</div>
    <div class="p-5">
      <div class="font-code text-xs text-muted mb-3">input: solicitud MA-4711</div>
      <div class="flex items-center justify-center h-20 rounded bg-[#2e2e3e] border border-[#555]">
        <span class="font-display text-3xl text-white/40">?</span>
      </div>
      <div class="mt-3 font-code text-xs text-primary">resultado: denegado</div>
      <div class="mt-4 pt-3 border-t border-base font-code text-xs text-muted">1 resultado &#183; 0 motivaciones &#183; no impugnable <span aria-hidden="true">&#10007;</span></div>
    </div>
  </div>
  <div class="border-2 rounded-soft overflow-hidden bg-surface-raised" style="border-color: var(--accent-primary);">
    <div class="px-4 py-2.5 border-b border-base font-code text-xs uppercase tracking-wider text-accent">13 MICRODECISIONES</div>
    <div class="p-5">
      <div class="font-code text-xs text-muted mb-3">input: solicitud MA-4711</div>
      <div class="flex flex-wrap gap-1.5">
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #0369A1;">01</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #0369A1;">02</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #0369A1;">03</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #0369A1;">04</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #0369A1;">05</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #0369A1;">06</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #0369A1;">07</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #0369A1;">08</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #6D4ED8;">09</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #0369A1;">10</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #0369A1;">11</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #B45309;">12</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #B45309;">13</span>
      </div>
      <div class="mt-3 flex flex-wrap gap-3 font-code text-[11px] text-muted">
        <span><span class="inline-block w-2.5 h-2.5 rounded-full align-middle mr-1" style="background:#0369A1;"></span>Regla (10)</span>
        <span><span class="inline-block w-2.5 h-2.5 rounded-full align-middle mr-1" style="background:#6D4ED8;"></span>IA (1)</span>
        <span><span class="inline-block w-2.5 h-2.5 rounded-full align-middle mr-1" style="background:#B45309;"></span>Humano (2)</span>
      </div>
      <div class="mt-4 pt-3 border-t border-base font-code text-xs text-primary">13 actas &#183; 13 motivaciones &#183; impugnables una a una <span class="text-accent" aria-hidden="true">&#10003;</span></div>
    </div>
  </div>
</div>

Esta descomposición no está ligada a ninguna jurisdicción. Una decisión de crédito se descompone con la misma mecánica: verificación de identidad (reglamento), extracción de ingresos de los justificantes (IA, con confianza), cálculo del scoring (reglamento, versionado), enrutamiento por umbrales (reglamento), voto humano en el caso límite (humano). Qué derecho vincula cada microdecisión - RGPD art. 22, UK GDPR, LGPD art. 20 o la Equal Credit Opportunity Act estadounidense - depende del mercado. La descomposición es la misma en todas partes. Hasta dónde llega en un proceso regulado lo muestra el ejemplo que ocupa a diario a los departamentos de RRHH europeos:

Procesar un parte de baja - eso suena a un solo trámite. En realidad encierra más de una docena de decisiones individuales: ¿Se ha clasificado correctamente el parte de IT según el RD 625/2014? ¿Es aplicable la prestación de la Seguridad Social según los art. 169-176 de la LGSS - y en qué cuantía? ¿Es una recaída del mismo proceso dentro de los 180 días, con duración acumulada (art. 169.2 LGSS)? ¿Se ha remitido el parte al INSS a través del Sistema RED en el plazo de tres días hábiles (art. 7 RD 625/2014)? ¿Procede ofrecer un examen de salud tras la reincorporación por ausencia prolongada (art. 37.3.b RD 39/1997, en relación con el art. 22 LPRL)? ¿A quién se informa de qué - y de qué, expresamente, no?

El [Decision Layer](/es/decision-layer/) descompone cada proceso de negocio en exactamente estas microdecisiones y asigna cada una, de antemano, a uno de [tres tipos de decisor](/es/revista/tres-tipos-de-decisiones/) - humano, reglamento o IA:

| Microdecisión (parte de baja) | Decisor | Por qué |
|---|---|---|
| Clasificación del parte de IT según RD 625/2014 | Reglamento | determinista, sin margen de interpretación |
| Cálculo de la prestación según art. 169-176 LGSS | Reglamento | cálculo fijo de porcentaje y base reguladora |
| Comprobar la recaída del mismo proceso a 180 días | Reglamento | regla determinista de los 180 días (art. 169.2 LGSS) |
| Remisión del parte al INSS a través del Sistema RED en plazo | Reglamento | plazo legal de 3 días hábiles (art. 7 RD 625/2014) |
| Marcar patrones de ausencia inusuales estadísticamente | IA (indicador) | detección de anomalías; el resultado es un indicio, no una decisión sobre el personal |
| ¿Procede ofrecer un examen de salud tras la reincorporación por ausencia prolongada (art. 37.3.b RD 39/1997, en relación con el art. 22 LPRL)? | Reglamento (oferta) + Humano (carácter voluntario) | la oferta es determinista; la participación es voluntaria |
| Despido por enfermedad previsiblemente prolongada | Humano | discrecional; inversión de la carga de la prueba (art. 96 LRJS, STJUE C-270/16 Daouidi) |

Esta descomposición no es un ejercicio académico - es la condición previa para la impugnabilidad. Porque la lógica SCHUFA del TJUE es aplicable en cada nivel: si ya un scoring automatizado es una decisión en sentido jurídico, entonces la comprobación automática de un plazo, la clasificación automática de un documento, la recomendación automática de un encuadramiento profesional son cada una un acto potencialmente impugnable - no solo el resultado final. Una empresa que solo documenta el resultado final, ante la pregunta "¿Por qué se rechazó mi solicitud?", solo puede responder: "Eso es lo que dio el proceso." Esa es exactamente la respuesta de caja negra que ningún juzgado de lo social acepta.

Hasta qué punto llega esta descomposición en la práctica lo muestra el [catálogo de agentes de RRHH](/es/catalogo-agentes-hr/): cada agente con su tabla completa de microdecisiones - por paso, tipo de decisor, motivación, base jurídica y vía de impugnación.

## Por qué los logs, traces y model cards no responden a la pregunta

El sector ha respondido a la necesidad de documentación - pero en tres niveles que pasan todos de largo respecto a la decisión individual:

| Nivel | Herramientas | Documenta | NO responde |
|---|---|---|---|
| Interacción | chat-logs, historial de conversación, eventos de audit de Copilot | quién habló con el sistema y cuándo, qué recursos se tocaron | qué regla de negocio sostuvo la decisión |
| Infraestructura | LLM observability (traces, spans), OpenTelemetry GenAI | prompts, tool calls, tokens, latencias a lo largo de la ejecución | por qué el resultado salió así - y si es correcto |
| Sistema | model cards, documentación técnica, plataformas de gobernanza (inventario de modelos, registro de riesgos) | cómo funciona el modelo en general, qué riesgos tiene el sistema | ningún caso individual concreto |

No es una exageración polémica, sino lo que dice la propia documentación de los fabricantes. [La documentación de Purview de Microsoft](https://learn.microsoft.com/en-us/purview/audit-copilot) recoge para el audit-log de Copilot que no registra los prompts y respuestas reales y que el nombre y la versión del modelo no están disponibles en los escenarios de Microsoft 365 Copilot. En el ecosistema de Salesforce la brecha se nombra abiertamente: los audit-trails clásicos se construyeron para personas que pulsan botones - se ve que algo ha cambiado, [pero no por qué](https://www.sweep.io/blog/the-audit-trail-of-an-ai-agent). Y las plataformas de gobernanza como IBM watsonx.governance o Credo AI responden a la pregunta "¿Está este sistema inventariado, evaluado por riesgo y conforme a las políticas?" - una pregunta importante, pero distinta de "¿En qué se basó la clasificación de la Sra. M. el 14 de mayo a las 10:42?".

Queda la salida en apariencia más obvia: dejar que el propio modelo se justifique. Los modelos de razonamiento generan cadenas de justificación - ¿por qué no archivarlas como prueba? Porque, está demostrado, no reflejan de forma fiable en qué se basó realmente la decisión. [La investigación de Anthropic](https://www.anthropic.com/research/reasoning-models-dont-say-think) sobre la fidelidad de la cadena de razonamiento muestra que, incluso en condiciones favorables, los modelos de razonamiento verbalizan los indicios de decisión que de verdad usaron solo en torno a uno de cada cuatro casos - los factores de influencia relevantes quedan ocultos aunque se lea la cadena de razonamiento completa. Una justificación generada es un texto sobre la decisión. No es la base de la decisión.

La investigación sobre impugnabilidad extrae de ahí la conclusión decisiva: explicabilidad e impugnabilidad son dos medios para el mismo fin - y la explicación sola, sin vía de impugnación, no lo alcanza ([Schmude et al., 2025](https://arxiv.org/abs/2504.18236)). La impugnabilidad cuenta con que una decisión pueda ser errónea, y exige los medios de prueba para revocarla. Los métodos de explicación post-hoc muestran, en el mejor de los casos, que en algún punto del entorno de una decisión puede haber errores; la prueba de que esta decisión concreta fue defectuosa no la aportan. Y [Moreira et al. (2025)](https://arxiv.org/html/2506.01662v1) desplazan el listón de la mera comprensión a la capacidad de actuar: una explicación debe permitir a afectados y revisores impugnar, cuestionar e influir activamente en un resultado - no solo comprender por qué se decidió así.

Con un trace de tokens nadie puede hacerlo. Con un acta de decisión, sí.

## El acta de decisión: la pieza de prueba por decisión

El acta de decisión es el registro atómico, inmutable y estructurado de una única microdecisión de negocio. Nace en el momento de la decisión - no como reconstrucción posterior - y contiene todo lo que el art. 86, el art. 12 y la jurisprudencia del TJUE exigen caso por caso:

| Campo | Contenido | Para qué sirve jurídicamente |
|---|---|---|
| Input | qué datos, qué documento, qué hash | C-203/22: "qué datos se usaron, y de qué modo" |
| Regla de negocio + versión + fuente | p. ej. convenio colectivo art. 12.3, versión 2024-Q3, en vigor desde 01/07/2024 | la motivación que sostiene - el campo que logs y traces no tienen |
| Tipo de decisor | humano, reglamento o IA - con la motivación del routing | Art. 14: prueba de supervisión humana efectiva |
| Confianza | valor de confianza y umbral en el momento de la decisión | prueba de la gestión de riesgos (art. 9), trazabilidad de la escalación |
| Versión del modelo y del prompt | qué modelo de lenguaje, qué plantilla de prompt, qué versión | reproducibilidad; el campo que falta en el audit-log de Copilot |
| Resultado + marca de tiempo | qué se decidió, cuándo (UTC) | conservación según art. 26.6, fijación inalterable de los registros |
| Nota de Human-in-the-Loop | quién revisó, si confirmó o se apartó | Art. 14.4: anular, revocar, detener - documentado |
| Vía de impugnación | quién puede impugnar esta decisión y dónde | hace operativamente cumplible el derecho del art. 86 |

Así se ve en el acta de un caso real - cuatro de 13 microdecisiones del procesamiento de un parte de baja:

<div class="not-prose my-10 bg-surface-raised border border-base rounded-soft overflow-hidden shadow-sm">
  <div class="px-5 py-4 border-b border-base bg-surface-dim">
    <div class="flex items-center gap-3 mb-2">
      <div class="flex gap-1.5" aria-hidden="true">
        <span class="w-2.5 h-2.5 rounded-full bg-[#FF5F56]"></span>
        <span class="w-2.5 h-2.5 rounded-full bg-[#FFBD2E]"></span>
        <span class="w-2.5 h-2.5 rounded-full bg-[#27C93F]"></span>
      </div>
      <span class="font-code text-xs text-muted">decision-record / parte-de-baja / 2026-05-14 / EMP_0x52a8</span>
    </div>
    <p class="text-small text-primary">Parte de IT recibido el 14.05.2026, 07:12 h. Caso procesado en 54 segundos - descompuesto en 13 microdecisiones documentadas.</p>
    <div class="mt-3 flex h-7 rounded overflow-hidden text-xs font-bold text-white" aria-label="Distribución de decisores: 10 reglamento, 1 IA, 2 humano">
      <div class="flex items-center justify-center" style="width: 77%; background: #0369A1;">10 Regla</div>
      <div class="flex items-center justify-center" style="width: 8%; background: #6D4ED8;">1</div>
      <div class="flex items-center justify-center" style="width: 15%; background: #B45309;">2 Humano</div>
    </div>
  </div>
  <ol class="divide-y divide-base">
    <li class="p-5">
      <div class="flex items-start gap-4">
        <div class="flex-shrink-0 w-9 h-9 rounded-full flex items-center justify-center font-code text-xs font-bold border" style="background: rgba(3,105,161,0.08); border-color: rgba(3,105,161,0.3); color: #0369A1;">02</div>
        <div class="flex-1 min-w-0">
          <div class="flex flex-wrap items-center gap-2 mb-1.5">
            <span class="text-body font-semibold text-primary">Cálculo de la prestación según art. 169-176 LGSS</span>
            <span class="inline-flex items-center gap-1 px-2 py-0.5 text-xs font-bold uppercase tracking-wider rounded text-white" style="background: #0369A1;">Regla</span>
          </div>
          <p class="text-small text-primary font-medium mb-2">60% de la base reguladora desde el día 4</p>
          <div class="px-3 py-2 bg-surface border border-base rounded font-code text-xs text-primary/80"><span class="text-muted">input:</span> periodo del parte 14-27.05 · datos maestros EMP_0x52a8</div>
          <div class="mt-2 font-code text-xs text-muted"><span>rule:</span> <span class="text-primary">LGSS art. 169-176 · v2026-01</span></div>
        </div>
      </div>
    </li>
    <li class="p-5">
      <div class="flex items-start gap-4">
        <div class="flex-shrink-0 w-9 h-9 rounded-full flex items-center justify-center font-code text-xs font-bold border" style="background: rgba(3,105,161,0.08); border-color: rgba(3,105,161,0.3); color: #0369A1;">06</div>
        <div class="flex-1 min-w-0">
          <div class="flex flex-wrap items-center gap-2 mb-1.5">
            <span class="text-body font-semibold text-primary">Remisión del parte al INSS (Sistema RED) en plazo</span>
            <span class="inline-flex items-center gap-1 px-2 py-0.5 text-xs font-bold uppercase tracking-wider rounded text-white" style="background: #0369A1;">Regla</span>
          </div>
          <p class="text-small text-primary font-medium mb-2">Transmitida dentro del plazo legal de 3 días</p>
          <div class="px-3 py-2 bg-surface border border-base rounded font-code text-xs text-primary/80"><span class="text-muted">input:</span> parte de baja RD 625/2014</div>
          <div class="mt-2 font-code text-xs text-muted"><span>rule:</span> <span class="text-primary">RD 625/2014 · v2025-07</span></div>
        </div>
      </div>
    </li>
    <li class="p-5">
      <div class="flex items-start gap-4">
        <div class="flex-shrink-0 w-9 h-9 rounded-full flex items-center justify-center font-code text-xs font-bold border" style="background: rgba(109,78,216,0.08); border-color: rgba(109,78,216,0.3); color: #6D4ED8;">09</div>
        <div class="flex-1 min-w-0">
          <div class="flex flex-wrap items-center gap-2 mb-1.5">
            <span class="text-body font-semibold text-primary">Marcar patrón de ausencias</span>
            <span class="inline-flex items-center gap-1 px-2 py-0.5 text-xs font-bold uppercase tracking-wider rounded text-white" style="background: #6D4ED8;">IA <span class="font-mono opacity-90">91%</span></span>
          </div>
          <p class="text-small text-primary font-medium mb-2">Aviso a RRHH: tercera baja corta en seis meses</p>
          <div class="px-3 py-2 bg-surface border border-base rounded font-code text-xs text-primary/80"><span class="text-muted">input:</span> metadatos de ausencia anonimizados - sin diagnóstico (RGPD art. 9)</div>
          <div class="mt-2 font-code text-xs text-muted"><span>model-reason:</span> <span class="text-primary">coincidencia de patrón de bajas cortas repetidas · indicador, no decisión de personal</span></div>
          <div class="mt-3"><span class="inline-flex items-center px-3 py-1.5 text-xs font-semibold rounded border-2" style="border-color: #6D4ED8; color: #6D4ED8; background: rgba(109,78,216,0.08);">formalmente impugnable · art. 14 EU AI Act</span></div>
        </div>
      </div>
    </li>
    <li class="p-5">
      <div class="flex items-start gap-4">
        <div class="flex-shrink-0 w-9 h-9 rounded-full flex items-center justify-center font-code text-xs font-bold border" style="background: rgba(180,83,9,0.08); border-color: rgba(180,83,9,0.3); color: #B45309;">13</div>
        <div class="flex-1 min-w-0">
          <div class="flex flex-wrap items-center gap-2 mb-1.5">
            <span class="text-body font-semibold text-primary">Entrevista de reincorporación</span>
            <span class="inline-flex items-center gap-1 px-2 py-0.5 text-xs font-bold uppercase tracking-wider rounded text-white" style="background: #B45309;">Humano</span>
          </div>
          <p class="text-small text-primary font-medium mb-2">Plan de reincorporación acordado</p>
          <div class="mt-2 font-code text-xs text-muted"><span>decided-by:</span> <span class="text-primary">técnica de RRHH</span> <span class="text-muted">- 17.05.2026, 14:10</span></div>
        </div>
      </div>
    </li>
  </ol>
</div>

El Derecho administrativo español ofrece una analogía precisa para este artefacto: el acto administrativo. Una Administración que decide sobre un ciudadano no emite un "output" - dicta un acto: dirigido individualmente, motivado, con base jurídica y pie de recurso, impugnable de forma individual mediante recurso. La [Ley 39/2015, del Procedimiento Administrativo Común](https://www.boe.es/buscar/act.php?id=BOE-A-2015-10565) exige la motivación del acto (art. 35) y le anuda un sistema de recursos (art. 112 y siguientes). Nadie aceptaría que una Administración respondiera a un recurso con: "Lamentablemente solo tenemos el log del servidor." Esa exigencia de forma es la que el acta de decisión traslada a las decisiones automáticas. Un trail es un rastro que se deja. Un acta es un documento que se levanta; un acto, una decisión que se dicta - y contra la que cabe recurso.

La misma lógica la conoce la contabilidad desde hace siglos: ningún auditor acepta una suma sin asientos y sin justificantes. El Código de Comercio exige el registro individual, la conservación ordenada y la trazabilidad por operación - con un plazo de conservación de los libros y la documentación de seis años (art. 30 del Código de Comercio), y la Ley General Tributaria fija la prescripción en cuatro años (art. 66), muy por encima de los seis meses del art. 26.6 del AI Act. El acta de decisión no es otra cosa que el viejo principio contable de 'ningún apunte sin justificante', aplicado a las decisiones: un justificante por operación, un acta por decisión.

Que para esta unidad todavía no exista un término estándar lo demuestra el propio mercado: circulan "decision trail", "decision provenance", "decision trace", "accountability record" - [TechTarget](https://www.techtarget.com/searcherp/feature/AI-decision-trails-are-the-new-audit-trail) declara las rutas de decisión de IA el nuevo audit-trail, el [FINOS AI Governance Framework](https://air-governance-framework.finos.org/mitigations/mi-21_agent-decision-audit-and-explainability.html) reclama "Agent Decision Audit and Explainability". El requisito ha llegado al debate. El artefacto aún no tiene nombre. Nosotros lo llamamos desde el origen del Decision Layer: acta de decisión.

Dónde nace el acta lo muestra la vista de las siete capas de un stack de agentes en producción - el acta de decisión es el artefacto de la capa 04:

<div class="not-prose my-10 border-y border-base">
  <ol class="divide-y divide-base">
    <li class="grid grid-cols-[3rem_1fr] gap-4 items-start py-4">
      <span class="font-display text-h2 leading-none text-muted">01</span>
      <div><span class="text-body font-semibold text-primary">Presentation Layer</span><p class="mt-1 text-small text-primary/80">Interfaces de usuario, pasarelas de prompts, portales de acceso para áreas de negocio y comité de empresa.</p></div>
    </li>
    <li class="grid grid-cols-[3rem_1fr] gap-4 items-start py-4">
      <span class="font-display text-h2 leading-none text-muted">02</span>
      <div><span class="text-body font-semibold text-primary">Orchestration Layer</span><p class="mt-1 text-small text-primary/80">Coordinación multiagente, enrutamiento de eventos, gestión de estado entre procesos.</p></div>
    </li>
    <li class="grid grid-cols-[3rem_1fr] gap-4 items-start py-4 bg-[color:var(--accent-primary)]/5">
      <span class="font-display text-h2 leading-none text-accent">03</span>
      <div><span class="text-body font-semibold text-primary">Agent Layer <span class="ml-2 font-code text-xs uppercase tracking-wider text-accent">núcleo Gosign</span></span><p class="mt-1 text-small text-primary/80">Agentes Document, Workflow y Knowledge - la capa ejecutora con juicio de IA.</p></div>
    </li>
    <li class="grid grid-cols-[3rem_1fr] gap-4 items-start py-4 bg-[color:var(--accent-primary)]/5">
      <span class="font-display text-h2 leading-none text-accent">04</span>
      <div><span class="text-body font-semibold text-primary">Decision Layer <span class="ml-2 font-code text-xs uppercase tracking-wider text-accent">núcleo Gosign</span></span><p class="mt-1 text-small text-primary/80">Aquí nace el acta de decisión: un acta por microdecisión, reglamentos versionados, routing human-in-the-loop ante discrecionalidad, impugnabilidad según el art. 14.</p></div>
    </li>
    <li class="grid grid-cols-[3rem_1fr] gap-4 items-start py-4">
      <span class="font-display text-h2 leading-none text-muted">05</span>
      <div><span class="text-body font-semibold text-primary">Governance Layer</span><p class="mt-1 text-small text-primary/80">Audit trail, registros firmados, controles cert-ready para EU AI Act art. 9/12/13/14, ISO 27001.</p></div>
    </li>
    <li class="grid grid-cols-[3rem_1fr] gap-4 items-start py-4">
      <span class="font-display text-h2 leading-none text-muted">06</span>
      <div><span class="text-body font-semibold text-primary">Model Layer</span><p class="mt-1 text-small text-primary/80">Registro de modelos, versionado, calibración de confianza - agnóstico al modelo.</p></div>
    </li>
    <li class="grid grid-cols-[3rem_1fr] gap-4 items-start py-4">
      <span class="font-display text-h2 leading-none text-muted">07</span>
      <div><span class="text-body font-semibold text-primary">Integration Layer</span><p class="mt-1 text-small text-primary/80">Conectores a SAP, Workday, sistemas ERP - salidas listas para contabilizar.</p></div>
    </li>
  </ol>
</div>

## La impugnabilidad es una decisión de arquitectura - no una función

La consecuencia incómoda de todo esto: la impugnabilidad no se añade a posteriori. Tres razones por las que una herramienta de compliance retrospectiva fracasa de forma estructural:

**Primera: lo que nunca se modeló como decisión no puede motivarse como decisión.** Un agente que procesa un expediente "de una sola pasada" produce un resultado sin articulación. La descomposición en microdecisiones tiene que ocurrir antes de la ejecución - define en qué puntos nace un acto, qué regla rige ahí y quién decide ahí. Después no se puede extraer una estructura de decisión de un log de conversación, igual que no se puede extraer una contabilidad analítica por centros de coste de un extracto bancario.

**Segunda: la supervisión humana efectiva necesita el contexto de la decisión - por caso.** El [art. 14.4](https://artificialintelligenceact.eu/article/14/) exige que la persona supervisora pueda interpretar correctamente el output, ignorarlo o revertirlo y detener el sistema - y que siga consciente de la tendencia a confiar de forma automática en el output de la máquina. El legislador nombra expresamente el sesgo de automatización. El NIST estadounidense advierte en el mismo sentido contra el Human-in-the-Loop ceremonial: un botón de aprobación sin contexto, sin facultad y sin tiempo no protege a nadie. Quien deba anular necesita ante sí el input, la regla aplicada, la confianza y el motivo de la escalación - es decir, exactamente los campos del acta de decisión. Por eso el [Human-in-the-Loop en el Decision Layer es un enrutamiento impuesto](/es/revista/human-in-the-loop-arquitectura/), no un clic opcional: en los tipos de decisión definidos el workflow se pausa, el sistema destino queda intacto y la decisión humana se documenta a su vez en su propia acta - incluida la información de si siguió la recomendación o se apartó de ella.

**Tercera: la corrección necesita la referencia a la regla.** La impugnación no es un fin en sí mismo - sirve para subsanar errores. Cuando una decisión se impugna con éxito, surge de inmediato la pregunta: ¿fue un error individual o un error de regla? Un acta de decisión que lleva la versión de la regla aplicada lo responde con una consulta: todas las actas de la misma versión de regla son identificables, la regla se corrige en una versión nueva, los casos afectados se vuelven a decidir de forma dirigida. De un caso individual impugnado nace una clase de error subsanada. Sin la referencia a la regla solo queda la revisión manual de todos los expedientes - lo contrario de escalar.

La investigación llama a este principio [Contestability by Design](https://research.tudelft.nl/en/publications/contestable-ai-by-design-towards-a-framework/) (Alfrink et al., 2022): los sistemas deben permanecer abiertos a la intervención humana a lo largo de todo su ciclo de vida - como una relación procedimental entre los afectados por la decisión y los responsables del sistema, incorporada en vez de añadida. Y [Deloitte (2025)](https://www.deloitte.com/us/en/insights/topics/emerging-technologies/ai-agents-scaling-faster.html) nombra los tres componentes de gobernanza que faltan a las empresas para los agentes casi con las mismas palabras que esta arquitectura: límites claros sobre qué decisiones pueden tomar los agentes por sí mismos y cuáles requieren aprobación humana; supervisión en tiempo real con detección de anomalías; y audit-trails que registren la cadena completa de actuaciones del agente para la rendición de cuentas. El marco de los tres tipos de decisor, el Confidence Routing y el acta de decisión son la respuesta técnica a exactamente esa lista - como principio de diseño, [no como capa de compliance posterior](/es/governance/eu-ai-act/).

## Quién impugna - y qué pasa entonces

La impugnabilidad suena abstracta, pero tiene cuatro caras muy concretas. El Decision Layer define, para cada microdecisión, ante quién debe justificarse:

| Quién impugna | Base jurídica | Qué ve | Qué se sigue de ahí |
|---|---|---|---|
| La persona afectada | Art. 86 AI Act, art. 15, 22 RGPD | la explicación de su propia decisión: papel del sistema de IA, elementos esenciales, contrafáctica si la pide | corrección del caso individual; ante un error de regla, re-ejecución de todos los casos afectados |
| El comité de empresa | Art. 64 del Estatuto de los Trabajadores, Ley 12/2021, acuerdo de empresa | actas de decisiones con impacto en el personal, prueba de que las reglas del acuerdo se aplicaron técnicamente | derechos de información y consulta (art. 64 ET) ejercidos sobre la base de evidencias, en lugar de desconfianza |
| El auditor | Plan General de Contabilidad (PGC), NIA-ES (adoptadas por el ICAC), Ley 22/2015 de Auditoría de Cuentas | actas completas por asiento: justificante, regla, versión, confianza, aprobación | enfoque basado en controles en lugar de pruebas sustantivas caso por caso; muestra directamente acreditable |
| La autoridad de control | Art. 26.6, art. 12 AI Act; AESIA (IA) y AEPD (datos personales) | registros exportables y legibles por máquina del periodo de conservación exigido | capacidad de respuesta en días en lugar de un proyecto forense |

Lo notable es lo que esta tabla le hace a la organización: invierte la dinámica de la carga de la prueba. Sin actas de decisión, toda impugnación es un proyecto forense de resultado incierto - y conforme al art. 96 de la LRJS, en los casos de discriminación es el empleador quien soporta la carga de la prueba en cuanto existen indicios. Con actas de decisión, la respuesta es una consulta. El comité de empresa que hoy recela de los proyectos de IA y los judicializa porque no obtiene transparencia se convierte en beneficiario de la misma infraestructura que sirve al auditor. Otros prometen transparencia. El acta de decisión la impone técnicamente.

La tabla tiene una cara oculta: quién puede impugnar lo fijan la ley y los acuerdos - pero ninguna norma garantiza por sí sola que las actas de decisión lleguen a existir, estén completas y perduren. Esa responsabilidad necesita un propietario claro en la organización; no surge como subproducto de la operación.

## En perspectiva: un principio se impone

La mirada honesta al mercado de 2026: la idea de que las decisiones de los agentes deben ser demostrables una a una no es exclusiva. Gartner ha creado con los [guardian agents](https://www.gartner.com/en/newsroom/press-releases/2025-06-11-gartner-predicts-that-guardian-agents-will-capture-10-15-percent-of-the-agentic-ai-market-by-2030) una categoría de mercado propia para capas de control que supervisan y bloquean acciones de los agentes, y les pronostica para 2030 entre el 10 y el 15 por ciento del mercado de IA agéntica. El [campo de la decision intelligence](https://www.gartner.com/en/information-technology/glossary/decision-intelligence) - modelar, evaluar y mejorar decisiones de forma explícita - obtuvo en enero de 2026 su primer Magic Quadrant. El WEF reclama una [gobernanza progresiva](https://www.weforum.org/publications/ai-agents-in-action-foundations-for-evaluation-and-governance/): intensidad de supervisión acoplada al nivel de autonomía del agente. La investigación trabaja en decision provenance. La dirección es inequívoca - y es exactamente la dirección del Decision Layer.

Lo que estos enfoques no logran es el anclaje en la regla de negocio. Un guardian agent bloquea en tiempo de ejecución; no deja un acta que sostenga ante un juzgado de lo social tres años después. La observability conserva la cadena de ejecución; no descompone las decisiones en artefactos justificados uno a uno y atados a una regla. La diferencia defendible del acta de decisión radica en tres propiedades: la atribución de cada microdecisión a una regla de negocio versionada con su fuente - convenio colectivo, acuerdo de empresa, legislación fiscal - en lugar de a una cadena de razonamiento generada; el Human-in-the-Loop impuesto por arquitectura por tipo de decisión en lugar de una configuración desactivable; y el mapeo de las actas sobre los estándares de auditoría con los que de verdad trabajan auditores y auditoría interna - NIA-ES (adoptadas por el ICAC), PGC. El primer campo, hasta donde sabemos, no lo documenta ningún proveedor horizontal; es a la vez el campo del que depende la impugnabilidad.

En aras de la precisión, conviene delimitar: el acta de decisión es una afirmación de arquitectura, no un certificado de conformidad. Que un sistema concreto cumpla los requisitos legales sigue siendo una valoración caso por caso del responsable del despliegue y sus asesores jurídicos. Lo que la arquitectura aporta es otra cosa - y más valiosa: hace los requisitos cumplibles. Una empresa con actas de decisión puede responder a la pregunta del artículo 86. Una empresa con chat-logs no puede, por bien documentadas que estén sus intenciones.

## La verdadera pregunta

El EU AI Act no inventó la explicabilidad de las decisiones individuales - la codificó para los sistemas de IA y la armó con un derecho del afectado. La jurisprudencia del TJUE fijó el listón antes de que entre en juego el primer plazo de alto riesgo. Y las consultoras han cuantificado lo que ocurre cuando las empresas transfieren derechos de decisión sin poder demostrar decisiones: proyectos cancelados, despliegues bloqueados, CIO que responden personalmente.

La pregunta para cualquier empresa que use o introduzca agentes de IA no es, por tanto, "¿Somos compliant?". Es: si mañana un empleado, un comité de empresa, un auditor o una autoridad impugna una decisión concreta de hoy - ¿puede presentar el acta? ¿Input, regla, versión, confianza, resultado, aprobación?

Quien pueda responder que sí ya no tiene un problema de riesgo de IA. Tiene una infraestructura de decisión.

→ [Decision Layer - visión general y ejemplos](/es/decision-layer/)

→ [Decision Layer explicado: los cuatro componentes](/es/revista/decision-layer-explicado/)

→ [EU AI Act: la IA en RRHH sigue siendo alto riesgo - plazo 2026/2027](/es/revista/eu-ai-act-hr-alto-riesgo/)

<a href="/es/contacto/" target="_blank" rel="noopener noreferrer">Concertar una reunión</a> - Le mostramos, sobre uno de sus procesos, cómo son en concreto las microdecisiones, las actas de decisión y las vías de impugnación.

--- Agent Governance en RRHH - Por que el CHRO debe liderar ---
> Agent Governance no es un tema de IT. RRHH decide las reglas, la definicion de bias, los umbrales de escalado. El CHRO debe liderarlo, no delegarlo.

## Agent Governance no es un proyecto de IT

Cuando las empresas introducen agentes de IA en los procesos de RRHH, la governance se asigna tipicamente a IT. IT debe asegurar que el agente funciona "correctamente". IT debe implementar los controles, configurar el monitoring y garantizar el compliance.

Esto es un error.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">De un vistazo - Agent Governance para RRHH</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Agent Governance define qué decisiones pueden tomar los agentes, cómo se documentan las acciones y cómo se versionan las reglas.</li>
<li>RRHH debe liderar governance - no IT - porque los umbrales de escalado, definiciones de bias y propiedad de reglas requieren experiencia funcional.</li>
<li>ISACA (2024) informa que el 73% de las organizaciones carecen de un framework formal de gobernanza IA, dejando procesos críticos de RRHH sin control.</li>
<li>El EU AI Act clasifica los sistemas de IA que influyen en decisiones de empleo como alto riesgo, exigiendo supervisión humana y monitorización de bias.</li>
<li>Actuar ahora: inventariar el uso actual de IA, asignar la propiedad de governance a RRHH, involucrar al Comité de Empresa antes de que el primer agente entre en producción.</li>
</ul>
</div>

IT puede proporcionar la infraestructura técnica: Audit Trail, monitoring, controles, portal del auditor. Pero las decisiones funcionales que definen la governance solo puede tomarlas RRHH:

¿Que decisiones puede tomar un agente de forma autonoma? ¿Cual es la definicion de "bajo riesgo" en una decision retributiva? ¿En que punto debe intervenir un humano? ¿Cual es una tasa de error aceptable? ¿Cual es la definicion de bias en la evaluacion del desempeno? ¿Que colectivos de empleados merecen medidas de proteccion especiales?

No son preguntas tecnicas. Son preguntas de RRHH.

## Los tres niveles de governance

Agent Governance tiene tres niveles, y cada uno requiere experiencia de RRHH:

| Elemento | Finalidad | Responsable |
|----------|-----------|-------------|
| Matriz de decisión | Define qué puede decidir el agente y qué permanece con humanos | RRHH + Legal |
| Audit Trail | Cada acción registrada, versionada, reproducible | IT (técnico), RRHH (revisión) |
| Concepto de roles | Quién monitoriza, quién aprueba, quién escala | RRHH |
| Plantillas para el Comité de Empresa | Documentación preparada para el acuerdo de empresa | RRHH + Comité de Empresa |
| Ruta de escalado | Qué ocurre cuando el agente tiene incertidumbre o baja confianza | RRHH (umbrales), IT (enrutamiento) |

**Definición de reglas:** ¿Qué reglas aplica el agente? Convenios colectivos, acuerdos de empresa, políticas internas. RRHH define las reglas, IT las implementa en el [Decision Layer](/es/decision-layer/).

**Reglas de escalado:** ¿Cuando debe intervenir un humano? RRHH define los umbrales de escalado: para que tipos de decisiones, a partir de que importes, para que colectivos. IT implementa el escalado tecnico.

**Monitoring de bias:** ¿Que se monitoriza y como se reacciona ante anomalias? RRHH define las metricas de bias: ¿Que grupos se comparan? ¿Que constituye una desviacion significativa? ¿Cuales son las consecuencias? IT implementa el monitoring estadistico.

## Que pasa cuando RRHH no lidera este tema

Cuando el CHRO delega Agent Governance a IT, surgen lagunas de governance:

IT establece los umbrales de escalado segun criterios tecnicos - valores de confianza, tasas de error, tiempos de respuesta. Los criterios funcionales - colectivos de empleados, tipos de decision, limites retributivos - faltan.

El monitoring de bias se orienta por metricas estadisticas sin contexto de RRHH. Una desviacion estadistica del 3% en la aprobacion de solicitudes de formacion, ¿es un problema? Sin experiencia de RRHH, nadie puede evaluarlo.

Los conjuntos de reglas se tratan como configuracion tecnica, no como governance funcional. Los cambios en las reglas se despliegan sin la aprobacion de RRHH. El resultado: el agente opera segun reglas que nadie del area funcional ha validado.

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">eBook gratuito: IA en RRHH</p>
<p class="text-body text-gosign-text mb-4">Checklist EU AI Act, framework de decisiones, perspectiva del comité de empresa y evaluación de preparación - el manual de gobernanza para responsables de RRHH.</p>
<a href="/es/ebook/ia-rrhh-manual-gobernanza/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Descargar gratis</a>
</div>

## El rol del CHRO

El CHRO debe liderar Agent Governance como tema estrategico. Esto no significa que el CHRO escriba prompts o configure modelos. Significa:

**Propiedad de las reglas:** RRHH es responsable de la exactitud y la vigencia de las reglas en el Decision Layer. Cada cambio de regla es aprobado por RRHH.

**Politica de escalado:** RRHH define la matriz de escalado. Que decisiones de forma autonoma, cuales con revision humana, cuales manualmente.

**Estrategia de bias:** RRHH define las metricas de bias y los procesos de respuesta ante anomalias.

**Reporting:** RRHH recibe informes de governance regulares desde el portal del auditor y los analiza.

**Relacion con el comite de empresa:** RRHH lidera la coordinacion con el comite de empresa (regulado por el Estatuto de los Trabajadores, art. 64) sobre el acuerdo de empresa relativo a la IA y asegura que los requisitos del comite se implementen como controles. En el contexto espanol, esto abarca tanto los derechos de informacion y consulta del Estatuto de los Trabajadores como las disposiciones especificas del convenio colectivo aplicable.

Mas informacion: [HR AI Agents](/es/hr-ai-agents/)

<a href="/es/contacto/" target="_blank" rel="noopener noreferrer">Reservar consulta</a> - Te mostramos como construir Agent Governance para RRHH.

--- De chatbots a agentes IA: MCP, A2A y sistemas Multi-Agent ---
> Qué diferencia a los agentes IA de los chatbots. Protocolos MCP y A2A, arquitectura de agentes, orquestación Multi-Agent empresarial.

## Un chatbot responde. Un agente actúa.

Esta distinción determina el valor de la IA en las empresas en 2026. Un chatbot responde preguntas: "¿Cuántos días de vacaciones me quedan?". Un agente ejecuta procesos. La diferencia no es gradual, es fundamental.

Un ejemplo concreto: un empleado comunica una baja por enfermedad. El agente de RRHH recibe el parte, verifica la integridad del formulario, coteja el período con el cuadrante de turnos, notifica al responsable del equipo, ajusta la planificación de capacidad y documenta el proceso en el expediente personal. Cuatro sistemas, un agente, cero intervenciones manuales. Cada paso rastreable, cada paso en el Audit Trail.

Esto no es un escenario de futuro. Es el estado del arte en 2026. Y es la razón por la que la arquitectura de agentes IA es una decisión estratégica, no una tarea exclusiva del departamento de IT.

Este artículo describe la arquitectura de agentes para entornos empresariales, explica los nuevos estándares MCP y A2A, presenta cinco casos de uso con potencial de ahorro cuantificable y define los requisitos de Governance sin los cuales ningún agente debería pasar a producción.

Gartner (2024) preve que en 2028, el 33% de las aplicaciones de software empresarial incluiran IA agentica, frente a menos del 1% en 2024. La arquitectura que elija hoy determina si esos agentes generan valor o riesgo.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">De un vistazo - Agentes IA para empresas</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Los agentes IA ejecutan procesos, no solo responden preguntas. La diferencia entre chatbot y agente es arquitectonica, no gradual.</li>
<li>La arquitectura empresarial del agente tiene cinco capas: interfaz de usuario, orquestacion, modelo IA, integracion de herramientas (MCP) y Governance.</li>
<li>MCP estandariza el acceso a herramientas (agente-sistema), A2A la comunicacion entre agentes (agente-agente). Ambos reducen el esfuerzo de integracion en un orden de magnitud.</li>
<li>Cuatro requisitos de Governance son innegociables antes de produccion: Decision Layer, Human-in-the-Loop, Audit Trail y Rollback.</li>
<li>Empiece con un agente para un proceso. La infraestructura del primer agente es la plataforma para cada uno de los siguientes.</li>
</ul>
</div>

## La arquitectura del agente: cinco capas

Un agente IA no es un sistema monolítico. La arquitectura empresarial consta de cinco capas, cada una con una responsabilidad claramente definida:

```
┌─────────────────────────────────────────┐
│          Interfaz de usuario             │
│     (very-ai / Teams / Custom)           │
├─────────────────────────────────────────┤
│        Capa de orquestación              │
│   (Routing, motor de reglas, escalado)   │
├─────────────────────────────────────────┤
│          Capa del modelo IA              │
│  (Claude / GPT / Llama / gpt-oss)        │
├─────────────────────────────────────────┤
│      Integración de herramientas (MCP)   │
│  (ERP, CRM, DMS, email, calendario...)   │
├─────────────────────────────────────────┤
│      Governance & Audit Layer            │
│  (Logging, políticas, Human-in-the-Loop) │
└─────────────────────────────────────────┘
```

**Interfaz de usuario.** La capa a través de la cual los empleados interactúan con el agente. Puede ser un portal de IA dedicado (como se describe en [Portal Enterprise AI: Cuatro interfaces Open Source en comparación](/es/revista/enterprise-ai-chat-interface/)), una integración en Microsoft Teams o una interfaz personalizada para departamentos específicos.

**Capa de orquestación.** Aquí se decide qué agente asume una tarea, qué modelo se utiliza y cuándo se escala. La orquestación conoce los conjuntos de reglas, las responsabilidades y las rutas de escalado. Es el centro de control.

**Capa del modelo IA.** El modelo de lenguaje que realiza el procesamiento propiamente dicho: comprender textos, reconocer patrones, generar respuestas. En una arquitectura agnóstica de modelo, esta capa es intercambiable. Un modelo económico para consultas estándar, uno más potente para análisis complejos. El enrutamiento se realiza automáticamente.

**Integración de herramientas (MCP).** La conexión con tus sistemas existentes: ERP, CRM, gestión documental, email, calendario, sistema de tickets. A través del Model Context Protocol (MCP), los agentes acceden a estos sistemas de forma estandarizada.

**Governance & Audit Layer.** Cada acción del agente se registra. Las políticas definen lo que un agente puede y no puede hacer. Human-in-the-Loop se impone donde es necesario. Esta capa no es opcional. Es el prerrequisito para el despliegue en producción. El [Decision Layer](/es/decision-layer/) constituye la base arquitectónica de este Governance.

## MCP y A2A: los nuevos estándares

Dos protocolos han cambiado en 2025/2026 la forma en que los agentes IA se comunican con el mundo exterior y entre sí: MCP (Model Context Protocol) y A2A (Agent-to-Agent).

### MCP: El puerto USB para la IA

MCP es un estándar abierto que permite a los modelos de IA acceder a fuentes de datos externas y herramientas. La analogía es acertada: igual que USB creó una interfaz universal para hardware, MCP crea una interfaz universal para integraciones de IA.

Antes de MCP, cada combinación de modelo de IA y sistema destino requería un conector específico. El agente A accede al ERP: un conector. El agente B accede al DMS: otro conector. El agente C accede al calendario: otro más. Con diez sistemas y tres modelos, son treinta integraciones individuales.

Con MCP, cada sistema define sus capacidades una vez en un formato estandarizado: ¿Qué datos puede proporcionar? ¿Qué acciones puede ejecutar? ¿Qué parámetros requiere? Cualquier modelo compatible con MCP puede utilizar estas capacidades sin código específico del sistema.

Para las empresas esto significa: nuevos sistemas se conectan más rápido. Los modelos se pueden intercambiar sin reconstruir las integraciones. La dependencia de proveedores de modelos individuales disminuye.

### A2A: Agentes que hablan entre sí

A2A (Agent-to-Agent) es el equivalente de MCP para la comunicación entre agentes. Mientras MCP rige la conexión agente-sistema, A2A rige la conexión agente-agente.

¿Por qué es relevante? Porque los procesos de negocio complejos rara vez los cubre un solo agente. Una baja por enfermedad afecta a RRHH, planificación de capacidad, nómina y potencialmente gestión de proyectos. Cada área tiene un agente especializado. A2A permite a estos agentes delegar tareas e intercambiar resultados, con permisos definidos.

Un punto crítico: A2A no significa acceso compartido a datos. El agente de RRHH transmite al agente financiero la información "Empleado X ausente desde la fecha Y", no el expediente personal completo. Cada agente ve solo lo que necesita para su tarea. Los límites de permisos se mantienen intactos.

## 5 casos de uso con potencial de ahorro concreto

La pregunta que plantean los directivos no es "¿Qué puede hacer un agente?" sino "¿Qué aporta un agente?". Aquí van cinco casos de uso con potencial de ahorro cuantificable:

| Área | Caso de uso | Qué hace el agente | Potencial de ahorro |
|---|---|---|---|
| RRHH | Onboarding | Crear cuentas, asignar formaciones, programar reuniones de bienvenida, enviar email de incorporación | 4-6 h por contratación |
| Finanzas | Verificación de facturas | Leer factura, verificar contra pedido, comprobar contabilización, lanzar flujo de aprobación | 70-80% menos tiempo de proceso |
| Legal | Análisis de contratos | Extraer cláusulas, comparar con contratos estándar, señalar desviaciones | Horas en vez de días |
| IT | Triaje de incidentes | Analizar reporte de error, cotejar con incidencias conocidas, crear ticket priorizado | Respuesta inicial más rápida |
| Operaciones | Monitorización de proveedores | Rastrear plazos de entrega, cotejar con plan de producción, alerta proactiva ante retrasos | Alerta temprana en vez de corrección |

Cada uno de estos casos sigue el mismo patrón: el agente se encarga de la parte estructurada y basada en reglas del proceso. El humano se encarga de las excepciones, las decisiones que requieren criterio y las aprobaciones. El ahorro de tiempo no proviene de eliminar trabajo humano, sino de eliminar tareas rutinarias manuales.

**Onboarding de RRHH en detalle.** Hoy, un administrativo de RRHH coordina manualmente cada nueva incorporación: crear cuentas IT, configurar derechos de acceso, asignar formaciones obligatorias, preparar el plan de acogida, redactar el email de bienvenida, configurar la nómina. Cada paso un sistema distinto, cada paso una entrada manual. Un agente de onboarding orquesta estos pasos automáticamente: lee el contrato de trabajo, identifica puesto, ubicación y departamento, y ejecuta los pasos en los sistemas correspondientes. El administrativo de RRHH aprueba el proceso global, no cada paso individual.

**Verificación de facturas en detalle.** Una factura entrante es leída por el Document Agent. El agente extrae proveedor, importe, partidas y número de pedido. Verifica automáticamente: ¿Existe un pedido correspondiente? ¿Coinciden partidas e importes? ¿Es correcta la contabilización? ¿El importe está dentro de los umbrales de aprobación? Si el resultado es positivo, se prepara el asiento contable. Ante desviaciones, se escala al responsable correspondiente, con el motivo concreto de la desviación, no con un mensaje genérico de "por favor revise".

## Requisitos de Governance para agentes

Un agente sin Governance es un riesgo. Cuatro requisitos deben cumplirse antes del despliegue en producción:

**1. Decision Layer.** Cada decisión del agente pasa por el [Decision Layer](/es/decision-layer/). Para cada microdecisión se define: ¿Puede el agente actuar de forma autónoma, aplica un conjunto de reglas, o debe aprobar un humano? Estas reglas están versionadas, son rastreables y no pueden ser modificadas por el propio agente.

**2. Human-in-the-Loop.** Para tipos de decisiones definidos, la arquitectura impone la revisión humana. Esto no es una funcionalidad que se pueda activar. Es un principio arquitectónico. El agente no puede eludir el requisito de Human-in-the-Loop porque está impuesto técnicamente, no acordado organizativamente.

**3. Audit Trail.** Cada acción del agente genera una entrada de registro inmutable: ¿Cuál fue el input? ¿Qué modelo se usó? ¿Qué regla se aplicó? ¿Cuál fue el resultado? ¿Cuándo se ejecutó la acción? El Audit Trail es la base para auditorías financieras, revisión interna y supervisión del Comité de Empresa.

**4. Rollback.** Cada acción del agente debe ser reversible. Si un agente genera un asiento erróneo o envía una notificación incorrecta, el proceso debe poder corregirse - técnicamente, no solo organizativamente. La capacidad de rollback es un requisito arquitectónico, no una adición posterior.

Estos cuatro requisitos no son negociables. Sin ellos, ningún Comité de Empresa consentirá, ningún auditor dará su aprobación y ningún CIO asumirá la responsabilidad. Más sobre la arquitectura de Governance en el siguiente artículo: [Decision Layer & Shadow AI](/es/revista/decision-layer-shadow-ai/).

## Sistemas Multi-Agent: especialización en vez de agente universal

El siguiente nivel tras el agente individual: múltiples agentes especializados trabajando juntos. No un agente universal que lo hace todo, sino especialistas que dominan cada uno una sola área.

El ejemplo de la baja por enfermedad como sistema Multi-Agent:

```
Baja por enfermedad recibida
│
Document Agent  →  Lee y clasifica el parte de baja
│
HR Agent      →  Verifica reglas: prestación, reincorporación, plazos
│
Workflow Agent  →  Notifica al responsable, ajusta cuadrante
│
Finance Agent   →  Actualiza nómina
```

Cada agente tiene sus propios permisos. El Document Agent puede leer documentos, pero no puede crear asientos contables. El Finance Agent puede ajustar la nómina, pero no puede acceder a expedientes de personal. Los límites de permisos están impuestos arquitectónicamente. A través del protocolo A2A, los agentes comunican solo la información que el agente receptor necesita para su tarea.

El agente orquestador coordina el flujo global. Sabe qué agente ejecuta qué paso, en qué secuencia y qué ocurre ante errores. El orquestador tiene visión general, pero no permisos operativos. Delega; no ejecuta.

Los sistemas Multi-Agent son potentes pero complejos. El número de interacciones crece cuadráticamente con el número de agentes. La depuración se vuelve más laboriosa. Los requisitos de Governance aumentan.

## Recomendación práctica: empieza en pequeño

La tentación de comenzar directamente con un sistema Multi-Agent es comprensible. La recomendación es clara: empieza con un solo agente para un proceso claramente definido.

**Paso 1:** Identifica un proceso que sea estructurado, basado en reglas y lo suficientemente frecuente para justificar el esfuerzo. Verificación de facturas, onboarding, análisis de contratos: elige uno.

**Paso 2:** Despliega un solo [agente de IA](/es/servicios/ai-agents/) para ese proceso. Con Decision Layer, con Human-in-the-Loop, con Audit Trail. No como prototipo, sino como sistema productivo.

**Paso 3:** Mide. Tiempo de procesamiento antes y después. Tasa de errores. Coste por transacción. Satisfacción de los empleados operativos.

**Paso 4:** Solo cuando el primer agente funcione de forma estable, planifica el segundo. Y solo cuando varios agentes funcionen de forma estable, considera la orquestación Multi-Agent.

Este enfoque no es conservador. Es pragmático. Un agente funcional con valor demostrado aporta más que un ambicioso concepto Multi-Agent estancado en fase piloto.

La [infraestructura](/es/servicios/infraestructura/) - hosting de modelos, bases de datos vectoriales, motor de orquestación, API gateway - se construye con el primer agente y queda disponible para cada uno de los siguientes. La inversión en el primer agente es simultáneamente la inversión en la plataforma.

Un ejemplo concreto: en el portal Enterprise AI [very-ai](/es/revista/enterprise-ai-chat-interface/) los usuarios pueden lanzar flujos Trigger.dev directamente desde el chat. El agente se convierte en el disparador de una cadena de procesos - no solo en un interlocutor. La plataforma de orquestación (→ [Artículo 10](/es/revista/orquestacion-agentes-plataformas/)) se encarga de la ejecución.

Dónde se ejecutan estos agentes concretamente, en qué plataforma, lo muestra [Artículo 10: Orquestación de agentes](/es/revista/orquestacion-agentes-plataformas/).

---

**Enterprise AI-Infrastruktur Blueprint 2026 - Serie de artículos**

| ← Anterior | Visión general | Siguiente → |
|:---|:---:|---:|
| [RAG y Document Intelligence: Cómo la IA entiende tus documentos](/es/revista/rag-document-intelligence-enterprise/) | [Visión general](/es/revista/infraestructura-ia-blueprint-2026/) | [Decision Layer & Shadow AI: Control en vez de caos](/es/revista/decision-layer-shadow-ai/) |

*Todos los artículos de esta serie: [Enterprise AI-Infrastruktur Blueprint 2026](/es/revista/infraestructura-ia-blueprint-2026/)*

---

**¿Listo para desplegar el primer agente IA para un proceso de negocio concreto?** Gosign acompaña a clientes empresariales desde el análisis del proceso hasta el agente en producción - agnóstico en cuanto a modelos, con Decision Layer y Audit Trail completo.

<a href="/es/contacto/" target="_blank" rel="noopener noreferrer">Reserva una consulta</a>. 30 minutos para identificar el primer caso de uso adecuado para tu organización.

--- Cert-Ready by Design: IA preparada para auditoría ---
> Cert-Ready by Design: controles como objetos de datos, evidencia automática y estado en vivo para auditores. Arquitectura para ISA, NIA-ES, SOC 2.

## El problema: la preparación para auditorías como proyecto

En la mayoría de las empresas, la preparación para una auditoría (auditoría de cuentas anuales, inspección fiscal, auditoría SOC 2) es un proyecto. Semanas antes de la auditoría se compilan documentos, se toman capturas de pantalla, se exportan evidencias de distintos sistemas y se organizan en carpetas.

Este procedimiento tiene tres problemas: es costoso, es propenso a errores y muestra una instantánea en lugar de un estado. El auditor ve cómo estaba el sistema en el momento de la documentación, no cómo funciona realmente.

Cuando los AI Agents toman decisiones críticas para el negocio, el problema se agrava. Cada decisión individual del agente debe ser trazable. Con miles de decisiones al mes, la documentación manual ya no es viable.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">De un vistazo - Cert-Ready by Design</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Cert-Ready by Design significa que la preparación para auditoría es un principio arquitectónico, no un proyecto de documentación retrospectivo.</li>
<li>Los controles son objetos de datos de primera clase con generación automática de evidencia, versionado de reglas y estado en vivo para auditores.</li>
<li>ISACA (2023) reporta que las organizaciones con monitorización continua de controles reducen el tiempo de preparación de auditoría hasta un 65%.</li>
<li>El Framework-Mapping cubre ISA, NIA-ES, SOC 2 e ISAE 3402 - la evidencia habla el lenguaje que los auditores entienden.</li>
<li>Resultado: la auditoría del procesamiento asistido por IA dura horas en lugar de semanas, con evidencia completa y a prueba de manipulación.</li>
</ul>
</div>

## Qué significa Cert-Ready by Design

Cert-Ready by Design invierte el enfoque: la preparación para auditorías no es un proceso posterior, sino un principio arquitectónico. Los controles son objetos de datos técnicos en el sistema. La evidencia se genera automáticamente. Los auditores ven el estado en vivo, no una instantánea.

### Controles como objetos de datos de primera clase

En la arquitectura Cert-Ready, cada control es un objeto de datos técnico con atributos definidos:

| Elemento | Función |
|---------|----------|
| Control_ID | Identificación única del control |
| Technical_Implementation | Implementación técnica concreta (p. ej., política RLS, verificación API, umbral de confianza) |
| Rule_Version | Versión de la lógica de decisión subyacente |
| Evidence_Generator | Mecanismo automático de verificación que genera evidencia |
| Evidence_History | Resultados de verificación historizados con marca temporal |
| Auditor_View | Vista con capacidad de drill-down hasta la implementación |

Los controles no son documentos de Word en una carpeta de SharePoint. Son objetos técnicos que viven en el sistema, se verifican automáticamente y reflejan su estado en tiempo real.

### Generación automática de evidencia

La evidencia no se compila a posteriori. Se genera automáticamente, con cada decisión del agente, con cada cambio de regla, con cada evento del sistema.

Un ejemplo: el agente procesa una factura entrante. El Decision Layer aplica la regla PGC-6000 en versión 4.2. Confianza: 97%. Resultado: propuesta de asiento en cuenta 600, centro de coste 1200. Sin escalación (confianza por encima del umbral, importe por debajo del límite de valor).

La evidencia de esta operación se genera automáticamente: datos de entrada, regla aplicada con versión, valor de confianza, decisión de enrutamiento, resultado, marca temporal. Esta evidencia es inmutable y está vinculada al asiento contable.

### Portal del Auditor

Los auditores ven en el Portal del Auditor el estado en vivo de todos los controles. Sin exportación PDF, sin instantánea, sino el estado actual del sistema.

El Portal del Auditor ofrece drill-down: desde la vista general de controles (dashboard semáforo: verde/amarillo/rojo) a través del control individual hasta la implementación técnica concreta y el historial de evidencia.

### Framework-Mapping

Los controles se mapean a estándares de auditoría establecidos:

**ISA / NIA-ES (Normas Internacionales de Auditoría):** Para auditorías de cuentas anuales. Los controles representan los controles internos que el auditor de cuentas evalúa en el marco de su auditoría, conforme a la Ley 22/2015 de Auditoría de Cuentas y las normas técnicas del ICAC.

**SOC 2 / ISAE 3402:** Para auditorías de TI y aseguramiento de terceros. Las implementaciones técnicas de los controles se mapean a los criterios de confianza de SOC 2 e ISAE 3402.

**Plan General de Contabilidad (PGC):** Para la integridad de la información financiera. El versionado de los conjuntos de reglas, la inmutabilidad del Audit Trail y la trazabilidad de cada decisión de asiento cumplen los requisitos del PGC y la normativa del ICAC.

Este Framework-Mapping asegura que la evidencia generada automáticamente habla el lenguaje que los auditores entienden.

## Cert-Ready en la práctica

Una firma de auditoría realiza la auditoría de cuentas anuales de un cliente. El cliente utiliza AI Agents para el procesamiento de facturas.

El auditor abre el Portal del Auditor. Ve: 12 controles para el procesamiento de facturas, todos en verde. Hace clic en el control "BV-003: Completitud de los asientos contables". Ve: la implementación técnica (verificación API contra la entrada de facturas), la versión actual de la regla, la evidencia de los últimos 12 meses (todas las verificaciones automáticas superadas), la confianza media y la tasa de escalación.

Puede hacer drill-down: verificar asientos individuales por muestreo, trazar la ruta de decisión, consultar la regla aplicada en la versión vigente en el momento de la decisión.

El resultado: la auditoría del procesamiento asistido por TI dura horas en lugar de semanas. La evidencia es completa, generada automáticamente y a prueba de manipulación.

Más sobre este tema: [Cert-Ready by Design en detalle](/es/governance/cert-ready/)

Más sobre gobernanza: [Gobernanza de IA](/es/governance/)

<a href="/es/contacto/" target="_blank" rel="noopener noreferrer">Agendar reunión</a>. Le mostramos el Portal del Auditor en vivo.

--- ChatGPT sin registro: Del riesgo a la infraestructura ---
> El uso descontrolado de ChatGPT genera Shadow IT. Como una infraestructura de chat conforme al RGPD y agnostica de modelo resuelve el problema.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">De un vistazo - ChatGPT sin registro: riesgo corporativo</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Los empleados que usan herramientas publicas de IA sin supervision de TI generan Shadow AI - los prompts se procesan en servidores sin control, potencialmente usados para entrenamiento, sin Audit Trail.</li>
<li>Prohibir la IA no funciona. La solucion es una infraestructura de chat agnostica de modelo bajo control corporativo, mejor que la alternativa publica.</li>
<li>Verizon DBIR (2024) concluyo que el 74% de las brechas de datos involucran un factor humano - el uso descontrolado de IA crea una categoria completamente nueva de exposicion de datos.</li>
<li>El valor real surge cuando la interfaz de chat evoluciona a plataforma de agentes - procesando documentos, orquestando workflows, respondiendo consultas de conocimiento.</li>
<li>Tres decisiones arquitectonicas estan pendientes: modelo de hosting, estrategia de modelos y hoja de ruta de agentes. Cada dia de retraso implica mas exposicion a Shadow AI.</li>
</ul>
</div>

## El problema no es ChatGPT. El problema es la pérdida de control.

En prácticamente todas las empresas, los empleados utilizan herramientas de IA públicas sin conocimiento de nadie. Con cuentas personales de ChatGPT, a través de páginas web dudosas que prometen «ChatGPT sin registro», copiando y pegando en Claude.ai o Gemini, sin conocimiento del departamento de TI, sin aprobación, sin ningún tipo de gobernanza. La barrera de entrada es cero, el incremento de productividad inmediato. El resultado: Shadow IT a gran escala.

El riesgo no es teórico. Los prompts enviados a servicios públicos de IA se procesan en servidores fuera del control de la empresa. Sin un contrato enterprise, los datos introducidos pueden utilizarse para el entrenamiento de modelos. Especialmente peligrosas son las numerosas páginas de terceros que ofrecen «ChatGPT gratis y sin registro»: carecen incluso de la protección mínima que proporciona una cuenta directa con OpenAI. Información confidencial (datos salariales, borradores de contratos, documentos estratégicos) acaba en sistemas sobre los que la empresa no tiene acceso, ni derecho de supresión, ni capacidad de auditoría. En España, la AEPD ya ha actuado contra tratamientos de datos vinculados a IA, lo que convierte este riesgo en una amenaza regulatoria tangible.

Los departamentos de TI se enfrentan a un dilema: prohibir no funciona porque el beneficio es demasiado evidente y los empleados encuentran alternativas. Tolerar no es opción porque el RGPD, el Comité de Empresa y la auditoría interna acabarán preguntando.

La respuesta no es ni prohibición ni tolerancia. La respuesta es infraestructura.


## Qué necesitan realmente los empleados y por qué usan ChatGPT a escondidas

Cuando los empleados recurren a ChatGPT a pesar de la prohibición, esto revela ante todo una cosa: la empresa no ofrece alternativa. Lo que buscan los empleados es una interfaz sencilla que funcione de inmediato, entienda el lenguaje natural y ayude en el trabajo diario. Resumir documentos, redactar correos electrónicos, analizar archivos, responder preguntas sobre normativas internas.

Esta necesidad es legítima. Pero debe satisfacerse en un entorno que la empresa controle, no en servidores de proveedores que se publicitan como «ChatGPT sin registro» y cuyo modelo de negocio es la recopilación de datos.

Una infraestructura de chat empresarial ofrece a cada empleado exactamente esta interfaz, con una diferencia clave: los datos permanecen dentro de la infraestructura de la empresa. Los prompts no se transmiten a terceros. El uso queda registrado y es auditable. Los permisos de acceso siguen el modelo de roles existente. Y lo más importante: los empleados ya no necesitan recurrir a herramientas externas porque disponen de una alternativa mejor y oficial.


## Por qué agnóstico de modelo es el único enfoque sensato

El error más común al implantar IA empresarial: establecer un único modelo de un único proveedor como estándar. ChatGPT Enterprise para todos, Copilot de forma generalizada o un contrato fijo con Claude.

El problema: los LLM evolucionan más rápido que cualquier ciclo de adquisición empresarial. El mejor modelo para análisis de texto hoy puede quedar superado por uno más económico o potente en seis meses. Quien construye toda su infraestructura sobre un solo proveedor asume un vendor lock-in en la decisión tecnológica más crítica de los próximos años.

Una arquitectura agnóstica de modelo resuelve esto: una interfaz de chat unificada para todos los empleados. Detrás, una capa de orquestación que enruta entre modelos: Claude, ChatGPT, Gemini, Llama, Mistral, DeepSeek, gpt-oss. Según el caso de uso, el coste o los requisitos de protección de datos, se selecciona automáticamente el modelo adecuado. Los cambios de modelo se realizan sin modificar la interfaz y sin necesidad de reformar a los empleados.

Gosign construye esta [infraestructura de IA](/es/servicios/infraestructura/) de forma agnóstica de modelo y abierta en plataforma, ya sea como despliegue en la nube en Azure o GCP, o completamente self-hosted en la infraestructura del cliente.


## Del interfaz de chat a la plataforma de agentes

Una interfaz de chat conforme al RGPD es el punto de entrada. Pero la verdadera generación de valor comienza cuando la interfaz no solo responde preguntas, sino que activa procesos.

Es la transición del chat a la infraestructura de agentes.

En la práctica: un empleado sube un parte de baja médica en el chat. Un [Document Agent](/es/servicios/ai-agents/) lee el documento, extrae los datos relevantes, verifica plazos según el convenio colectivo y prepara el registro en SAP. Un [Workflow Agent](/es/servicios/ai-agents/) orquesta el proceso posterior: notificar al responsable, verificar la cobertura del puesto, calcular la prestación por incapacidad temporal. Un Knowledge Agent responde las consultas del empleado basándose en las políticas internas vigentes.

La interfaz de chat se convierte en el punto de entrada unificado para los tres tipos de agentes. El empleado ve una conversación sencilla. Tras el telón, la infraestructura orquesta agentes documentales, de flujo de trabajo y de conocimiento, con un Audit Trail completo y [Human-in-the-Loop](/es/governance/) en las decisiones críticas.


## Governance no es una funcionalidad. Governance es la arquitectura.

Cada uso no controlado de ChatGPT genera un punto ciego: ¿qué datos se introdujeron? ¿Qué respuestas se utilizaron para tomar decisiones? ¿Quién preguntó qué y cuándo?

En una infraestructura de chat empresarial con [Governance by Design](/es/governance/), estos puntos ciegos no existen.

Cada interacción queda registrada: prompt, respuesta, modelo utilizado, marca temporal, rol del usuario. Las acciones con impacto en decisiones pasan por el [Decision Layer](/es/decision-layer/), que separa el análisis de la toma de decisiones. Los procesos críticos requieren aprobación humana, integrada arquitectónicamente como Human-in-the-Loop.

Para el Comité de Empresa: transparencia sobre el uso de IA en la organización, documentada y verificable en cualquier momento. Para la auditoría interna: un Audit Trail completo. Para el Delegado de Protección de Datos (DPD): tratamiento de datos en un entorno controlado, sin transferencias a terceros, documentación conforme al RGPD.


## Evaluacion de riesgo: IA publica vs. infraestructura corporativa

| Categoria de riesgo | ChatGPT publico / sitios de terceros | Infraestructura de chat corporativa |
|---|---|---|
| Soberania de datos | Sin control - datos en servidores externos | Control total - self-hosted o nube UE |
| Entrenamiento de modelo | Datos pueden usarse para entrenamiento | Sin entrenamiento con datos corporativos |
| Audit Trail | Ninguno | Completo - prompt, respuesta, usuario, modelo |
| Conformidad RGPD | No garantizada | Impuesta por arquitectura |
| Control de acceso | Cuentas personales, sin RBAC | SSO con acceso basado en roles |
| Integracion de agentes | No posible | Document, Workflow, Knowledge Agents |
| Vendor lock-in | Atado a un proveedor | Agnostico de modelo - cambio sin reentrenamiento |

## Lo que el departamento de TI debe decidir ahora

La pregunta ya no es si los empleados usan IA. La pregunta es si lo hacen en un entorno controlado o no controlado.

Tres decisiones arquitectónicas están pendientes.

Primera: hosting. ¿La infraestructura de chat debe ejecutarse en Azure, GCP o completamente self-hosted? La respuesta depende del entorno de TI existente y los requisitos de protección de datos. Las tres opciones son técnicamente equivalentes: no hay compromisos arquitectónicos con el self-hosting.

Segunda: estrategia de modelos. ¿Qué modelos deben estar disponibles y cómo se gobierna el enrutamiento? Una arquitectura agnóstica de modelo mantiene todas las opciones abiertas y evita el vendor lock-in.

Tercera: hoja de ruta de agentes. ¿La interfaz de chat debe conectar a medio plazo con agentes que procesen documentos y orquesten flujos de trabajo? Si la respuesta es sí (y casi siempre lo es), la infraestructura debe estar diseñada para ello desde el principio.

En Gosign construimos exactamente esta infraestructura: agnóstica de modelo, conforme al RGPD, con integración de agentes y Governance by Design. Del concepto a la interfaz de chat productiva en 4-6 semanas. En la [infraestructura del cliente](/es/servicios/infraestructura/), bajo control total del cliente. Sin SaaS, sin vendor lock-in.

--- Claude Code como control de seguridad en el workflow DevOps ---
> Runbook DevOps para Security Reviews automatizados con Claude Code: instalación, Custom Commands, scripts de auditoría e integración CI.

Los app stacks self-hosted modernos se componen de muchos componentes: Supabase Platform, capa de aplicación Next.js, Edge Functions, Background Jobs y APIs externas. Con cada componente aumenta la probabilidad de errores de configuración, fugas de secrets, políticas faltantes y endpoints no asegurados.

Los escáneres de seguridad tradicionales verifican reglas estáticas. Encuentran `service_role` en un archivo `.env`, pero no reconocen que una nueva Server Action carece del mismo ownership check que está presente en todas las demás Server Actions. Reportan puertos abiertos, pero no reconocen que un cambio de firewall la semana pasada junto con un nuevo contenedor ha abierto una vía de acceso no prevista.

**Claude Code cierra esta brecha como capa de análisis contextual sobre todo el stack.**

Claude Code no sustituye los checks determinísticos. Los complementa interpretando los resultados, reconociendo relaciones y priorizando recomendaciones.

Este runbook describe cómo se instala, configura e integra Claude Code de forma concreta en el workflow DevOps.


<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">De un vistazo - Artículo 5 de 6 de la serie DevOps Runbook</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Claude Code solo en el servidor de auditoría</li>
<li>Modelo de tres capas</li>
<li>Custom Commands definen el alcance de la revisión</li>
<li>Modo headless restringido a Read/Grep/Glob</li>
<li>Auditoría cron semanal más revisiones de PR</li>
</ul>
</div>

## Índice de la serie

Esta guía forma parte de nuestra serie de runbooks DevOps para app stacks self-hosted.

1. [Supabase Self-Hosting Runbook](/es/revista/supabase-self-hosting/)
2. [Next.js sobre Supabase de forma segura](/es/revista/nextjs-supabase-configuracion-segura/)
3. [Supabase Edge Functions de forma segura](/es/revista/supabase-edge-functions-seguridad/)
4. [Trigger.dev Background Jobs en producción segura](/es/revista/trigger-dev-background-jobs/)
5. [Claude Code como control de seguridad en el workflow DevOps](/es/revista/claude-code-security-devops/) - este artículo
6. [Security Baseline para todo el stack](/es/revista/security-baseline-stack/)

Los primeros cuatro artículos describen los componentes individuales. Este artículo describe la **capa de control de seguridad sobre ellos**.

## Visión general de la arquitectura

Claude Code trabaja **no en el servidor de producción**, sino en el servidor de auditoría (véase [Artículo 1](/es/revista/supabase-self-hosting/)). Tiene acceso de solo lectura a los datos que analiza.

```
Servidor de producción (supabase-prod)
   |
   +-- Supabase Stack
   +-- Next.js App
   +-- Edge Functions
   +-- Trigger.dev
   |
   +---- SSH (read-only) ----> Servidor de auditoría (audit-runner)
                                   |
                                   +-- Checks determinísticos
                                   |   +-- Port Scans (nmap)
                                   |   +-- Firewall Diff (iptables-save)
                                   |   +-- Versiones de contenedores (docker images)
                                   |   +-- Estado RLS (psql)
                                   |   +-- npm audit
                                   |   +-- Checks de código basados en grep
                                   |
                                   +-- Claude Code (headless)
                                   |   +-- Analiza resultados de checks
                                   |   +-- Lee Git Diffs
                                   |   +-- Verifica configs contra runbooks
                                   |   +-- Genera informe priorizado
                                   |
                                   +-- Informe -> Equipo DevOps (la persona decide)
```

**Claude Code no ejecuta cambios en el sistema de producción. Ni deployments, ni rotación de secrets, ni paradas de contenedores.**


### Comparación de las tres capas

| Propiedad | Verificaciones deterministas | Reglas de runbooks | Análisis Claude |
|---|---|---|---|
| Entrada | Comandos del sistema (nmap, grep) | Archivos Markdown | Output de las capas 1+2 |
| Salida | Hechos (abierto/cerrado, presente/ausente) | Estado objetivo (DEBE) | Informe priorizado |
| Frecuencia | Diaria (cron) | Estática (actualización con cambios) | Semanal + en PR |
| Falsos positivos | Ninguno (objetivo) | Ninguno (reglas definidas) | Posibles (interpretación) |
| Detección de drift | Patrones conocidos | Ninguno (referencia) | Patrones desconocidos |


## Principio fundamental: Tres niveles de verificación de seguridad

```
Nivel 1: Checks determinísticos (scripts)
   -> Resultados objetivos y repetibles
   -> Ejemplo: "El puerto 5432 es accesible desde el exterior" = hecho

Nivel 2: Reglas de runbook (archivos Markdown)
   -> Estado objetivo definido del stack
   -> Ejemplo: "PostgreSQL solo debe escuchar en 10.0.1.10"

Nivel 3: Análisis contextual de Claude Code (headless)
   -> Interpreta resultados, reconoce relaciones
   -> Ejemplo: "El puerto 5432 está abierto Y el nuevo contenedor
     tiene una conexión directa a la DB. Esto es un problema."
```

Los niveles se construyen uno sobre otro. Claude recibe los resultados del Nivel 1 y las reglas del Nivel 2 como input y genera a partir de ellos su review contextual.

## Parte A - Configuración de Claude Code

## A1 - Instalación y configuración en el servidor de auditoría

### Implementación

Claude Code se instala en el servidor de auditoría, no en el servidor de producción.

```bash
# En el servidor audit-runner

# Instalar Node.js (si no está presente)
curl -fsSL https://deb.nodesource.com/setup_20.x | sudo bash -
apt-get install -y nodejs

# Instalar Claude Code
npm install -g @anthropic-ai/claude-code

# Configurar API Key
# API Key propio con límite de presupuesto para CI/CD
export ANTHROPIC_API_KEY="sk-ant-..."

# Persistir en .bashrc o .env para el audit-user
echo 'export ANTHROPIC_API_KEY="sk-ant-..."' >> /home/audit/.bashrc
```

**Probar el modo headless:**

```bash
# Test sencillo: ¿funciona Claude Code de forma no interactiva?
echo "Hello" | claude -p "Antworte mit OK wenn du das lesen kannst" \
  --output-format text

# Expectativa: "OK" o confirmación similar
```

### Condición verificable

```bash
# ¿Claude Code instalado?
claude --version
# Expectativa: número de versión

# ¿API Key configurado?
test -n "$ANTHROPIC_API_KEY" && echo "OK" || echo "FEHLT"

# ¿Funciona el modo headless?
claude -p "Sage nur: OK" --output-format text --max-turns 1 2>/dev/null
# Expectativa: "OK"
```

### Escenario de fallo

Si Claude Code se ejecuta en el servidor de producción y tiene acceso a Bash allí, un prompt defectuoso podría teóricamente ejecutar comandos en el sistema de producción. En el servidor de auditoría, Claude Code solo tiene acceso a los informes recopilados y a las copias de configuración, no al sistema en vivo.

## A2 - Configurar Custom Security Review Command

### Implementación

Claude Code soporta Custom Commands mediante archivos Markdown en `.claude/commands/`. Estos Commands definen el contexto y las reglas de verificación para el Security Review.

```bash
# En el repositorio de infraestructura
mkdir -p .claude/commands
```

```markdown
# .claude/commands/security-review.md

Du bist Security Reviewer für einen self-hosted Stack bestehend aus:
- Supabase (PostgreSQL, PostgREST, GoTrue, Kong, Edge Functions)
- Next.js (App-Schicht, Server Actions, Route Handler)
- Trigger.dev v3 (Background Jobs, self-hosted)
- Todo en infraestructura en la UE (p. ej. Hetzner, OVH, Scaleway)

Du erhältst den Output der deterministischen Security Checks und die
aktuellen Konfigurationsdateien.

Prüfe folgendes:

## Infrastruktur (Artikel 1)
- Sind unerwartete Ports von aussen erreichbar?
- Hat sich die Firewall gegenüber der Baseline geändert?
- Sind Container-Versionen gepinnt und aktuell?
- Ist das TLS-Zertifikat noch mindestens 14 Tage gültig?
- Liegt das letzte Backup weniger als 26 Stunden zurück?

## Next.js (Artikel 2)
- Taucht service_role in NEXT_PUBLIC Variablen oder im Client-Bundle auf?
- Haben alle Server Actions einen getUser() Auth Check?
- Haben alle Route Handler einen getUser() Auth Check?
- Existiert middleware.ts mit getUser() (nicht getSession())?
- Sind Security Headers in next.config.js gesetzt?

## Edge Functions (Artikel 3)
- Haben alle Webhook-Functions eine Signaturprüfung?
- Gibt es Functions mit Business-Logik statt Integrations-Logik?
- Ist CORS korrekt konfiguriert (kein Wildcard in Produktion)?
- Gibt es hardcoded Secrets im Function-Code?

## Trigger.dev (Artikel 4)
- Haben alle Tasks maxDuration und concurrencyLimit?
- Haben Tasks mit externen API-Calls Idempotency Keys?
- Nutzen Tasks nur die DB-Felder die sie brauchen (kein SELECT *)?
- Gibt es console.log statt dem Trigger.dev logger?

## Stackübergreifend
- Gibt es Architektur-Drift? (Business-Logik in Edge Functions,
  Langläufer in Server Actions, etc.)
- Sind die Änderungen der letzten Woche konsistent mit der
  bestehenden Architektur?
- Gibt es neue Tabellen ohne RLS?
- Gibt es Muster die auf systematische Probleme hindeuten?

Erstelle einen priorisierten Bericht:
- KRITISCH: sofort handeln (Daten-Leak möglich, Port offen, Secret exponiert)
- WARNUNG: diese Woche lösen (fehlende Checks, Drift, veraltete Packages)
- INFO: bei Gelegenheit verbessern (Code-Qualität, fehlende Tests)

Für jedes Finding: Was ist das Problem, warum ist es ein Risiko,
was ist die konkrete Lösung.
```

### Condición verificable

```bash
# ¿Existe el Custom Command?
test -f .claude/commands/security-review.md && echo "OK" || echo "FEHLT"

# ¿Claude Code reconoce el command?
claude -p "/security-review" --max-turns 1 2>/dev/null | head -5
# Expectativa: Claude comienza con el análisis
```

## A3 - CLAUDE.md como contexto del proyecto

### Implementación

Claude Code lee automáticamente el archivo `CLAUDE.md` en el directorio del proyecto. Este archivo proporciona a Claude el contexto permanente sobre el stack.

```markdown
# CLAUDE.md (en el root del repositorio de infraestructura)

## Stack-Überblick
Self-hosted Supabase + Next.js + Edge Functions + Trigger.dev v3
en infraestructura en la UE (p. ej. Hetzner, OVH, Scaleway).

## Server
- supabase-prod: 10.0.1.10 (Supabase, Next.js, Edge Functions)
- audit-runner: 10.0.1.11 (Security Checks, Claude Code, Monitoring)
- trigger-server: separater Docker-Stack für Trigger.dev v3

## Sicherheitsregeln
- service_role Key darf NUR in: lib/supabase/admin.ts und trigger/lib/supabase.ts
- NEXT_PUBLIC_* darf NUR enthalten: SUPABASE_URL und SUPABASE_ANON_KEY
- Alle public-Tabellen müssen RLS aktiviert haben
- Alle Server Actions und Route Handler müssen getUser() aufrufen
- Alle Webhook Edge Functions müssen Signaturen prüfen
- Alle Trigger.dev Tasks müssen maxDuration und concurrencyLimit haben
- PostgreSQL nur auf 10.0.1.10:5432 (internes Interface)
- Supabase Studio nicht von aussen erreichbar
- Trigger.dev Dashboard nicht von aussen erreichbar

## Deployment
- Infrastruktur wird nur über Git deployed (kein manuelles SSH-Editing)
- Edge Functions werden als Dateien in volumes/functions/ abgelegt
- Trigger.dev Tasks werden über npx trigger.dev deploy --self-hosted deployed

## Verzeichnisstruktur
- app/ = Next.js App (Server Actions, Route Handler, Pages)
- lib/supabase/ = Supabase Client Konfiguration
- middleware.ts = Auth Middleware
- volumes/functions/ = Supabase Edge Functions
- trigger/tasks/ = Trigger.dev Tasks
- infra/ = docker-compose, nginx/caddy, Firewall Configs
- scripts/ = Audit Scripts, Backup, Restore
- runbooks/ = Sicherheits-Runbooks
```

Quien combine el [enfoque CLAUDE.md con las reglas de seguridad del Artículo 2](/es/revista/nextjs-supabase-configuracion-segura/) obtiene una base de contexto completa para reviews automatizados.

## Parte B - El workflow de auditoría completo

Aquí converge lo que los [Artículos 1 a 4](/es/revista/supabase-self-hosting/) han preparado. Cada artículo tiene sus propios scripts de verificación. El Artículo 5 los unifica y pasa la salida a Claude Code.

## B1 - El script de auditoría completo

### Implementación

Este script recopila todos los resultados de los checks determinísticos y los pasa a Claude Code en modo headless.

```bash
#!/bin/bash
# scripts/full-security-audit.sh
# Läuft auf dem audit-runner Server

set -euo pipefail

PROD_HOST="10.0.1.10"
REPORT_DIR="/opt/audit/reports"
DATE=$(date +%Y-%m-%d)
REPORT_FILE="${REPORT_DIR}/audit-input-${DATE}.md"

mkdir -p "$REPORT_DIR"

echo "=== Gesamt-Security-Audit ${DATE} ===" | tee "$REPORT_FILE"

# -------------------------------------------
# EBENE 1: Deterministische Checks
# -------------------------------------------

echo -e "\n# Deterministische Check-Ergebnisse\n" >> "$REPORT_FILE"

# --- Infrastruktur (Artikel 1) ---
echo "## Infrastruktur" >> "$REPORT_FILE"

echo "### Offene Ports (extern)" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
nmap -p 22,80,443,3000,3040,5432,5433,8000,9000 app.example.com \
  --open -oG - 2>/dev/null >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"

echo "### Firewall Diff gegen Baseline" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "iptables-save" | \
  diff /opt/baselines/firewall-baseline.txt - >> "$REPORT_FILE" 2>&1 || true
echo '```' >> "$REPORT_FILE"

echo "### Container Status" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "docker compose ps --format 'table {{.Name}}\t{{.Status}}\t{{.Image}}'" \
  >> "$REPORT_FILE" 2>&1
echo '```' >> "$REPORT_FILE"

echo "### TLS Zertifikat" >> "$REPORT_FILE"
CERT_EXPIRY=$(echo | openssl s_client -connect app.example.com:443 2>/dev/null | \
  openssl x509 -noout -enddate 2>/dev/null | cut -d= -f2)
CERT_EPOCH=$(date -d "$CERT_EXPIRY" +%s 2>/dev/null || echo 0)
NOW_EPOCH=$(date +%s)
DAYS_LEFT=$(( (CERT_EPOCH - NOW_EPOCH) / 86400 ))
echo "Ablauf: ${CERT_EXPIRY} (${DAYS_LEFT} Tage)" >> "$REPORT_FILE"

echo "### Backup Status" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "ls -lh /opt/backups/*.gpg 2>/dev/null | tail -3" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"

echo "### RLS Status" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "docker compose exec -T postgres psql -U postgres -c \
  \"SELECT tablename, rowsecurity FROM pg_tables WHERE schemaname = 'public' ORDER BY tablename;\"" \
  >> "$REPORT_FILE" 2>&1
echo '```' >> "$REPORT_FILE"

echo "### Disk Usage" >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "df -h / | tail -1" >> "$REPORT_FILE"

# --- Next.js (Artikel 2) ---
echo -e "\n## Next.js App-Schicht" >> "$REPORT_FILE"

echo "### service_role im Client Code" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "cd /opt/app && grep -rn 'SERVICE_ROLE\|service_role' app/ \
  --include='*.ts' --include='*.tsx' | grep -v 'lib/supabase/admin.ts' | grep -v node_modules" \
  >> "$REPORT_FILE" 2>&1 || echo "Keine Treffer" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"

echo "### NEXT_PUBLIC mit Secrets" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "cd /opt/app && grep 'NEXT_PUBLIC_' .env* 2>/dev/null | \
  grep -iE 'service_role|secret|private|database'" \
  >> "$REPORT_FILE" 2>&1 || echo "Keine Treffer" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"

echo "### Server Actions ohne Auth" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "cd /opt/app && for file in \$(grep -rl \"'use server'\" app/ --include='*.ts'); do
  if ! grep -q 'getUser' \"\$file\"; then
    echo \"WARNUNG: \$file\"
  fi
done" >> "$REPORT_FILE" 2>&1 || echo "Keine Treffer" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"

echo "### Route Handler ohne Auth" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "cd /opt/app && for file in \$(find app/api -name 'route.ts' 2>/dev/null); do
  if ! grep -q 'getUser' \"\$file\"; then
    echo \"WARNUNG: \$file\"
  fi
done" >> "$REPORT_FILE" 2>&1 || echo "Keine Treffer" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"

echo "### npm audit" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "cd /opt/app && npm audit --audit-level=high 2>&1 | tail -20" \
  >> "$REPORT_FILE" 2>&1
echo '```' >> "$REPORT_FILE"

# --- Edge Functions (Artikel 3) ---
echo -e "\n## Edge Functions" >> "$REPORT_FILE"

echo "### Webhook Functions ohne Signaturprüfung" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "for dir in /opt/supabase/volumes/functions/*-webhook/; do
  [ -d \"\$dir\" ] || continue
  name=\$(basename \"\$dir\")
  if ! grep -qE 'signature|verify|hmac|crypto' \"\$dir/index.ts\" 2>/dev/null; then
    echo \"KRITISCH: \$name hat keine Signaturprüfung\"
  else
    echo \"OK: \$name\"
  fi
done" >> "$REPORT_FILE" 2>&1
echo '```' >> "$REPORT_FILE"

echo "### Hardcoded Secrets in Functions" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "grep -rn 'sk_live\|sk_test\|whsec_\|Bearer ey' \
  /opt/supabase/volumes/functions/ --include='*.ts' 2>/dev/null" \
  >> "$REPORT_FILE" 2>&1 || echo "Keine Treffer" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"

# --- Trigger.dev (Artikel 4) ---
echo -e "\n## Trigger.dev Tasks" >> "$REPORT_FILE"

echo "### Tasks ohne maxDuration" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "cd /opt/app && for file in trigger/tasks/*.ts; do
  name=\$(basename \"\$file\" .ts)
  if ! grep -q 'maxDuration' \"\$file\" 2>/dev/null; then
    echo \"WARNUNG: \$name\"
  fi
done" >> "$REPORT_FILE" 2>&1
echo '```' >> "$REPORT_FILE"

echo "### Tasks ohne Concurrency Limit" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "cd /opt/app && for file in trigger/tasks/*.ts; do
  name=\$(basename \"\$file\" .ts)
  if ! grep -qE 'concurrencyLimit|queue:' \"\$file\" 2>/dev/null; then
    echo \"WARNUNG: \$name\"
  fi
done" >> "$REPORT_FILE" 2>&1
echo '```' >> "$REPORT_FILE"

# --- Git Änderungen ---
echo -e "\n## Code-Änderungen (letzte 7 Tage)" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "cd /opt/app && git log --oneline --since='7 days ago'" \
  >> "$REPORT_FILE" 2>&1
ssh deploy@${PROD_HOST} "cd /opt/app && git diff HEAD~10 --stat 2>/dev/null" \
  >> "$REPORT_FILE" 2>&1
echo '```' >> "$REPORT_FILE"

# -------------------------------------------
# EBENE 2: Runbook-Regeln (als Kontext)
# -------------------------------------------

echo -e "\n# Aktive Runbook-Regeln\n" >> "$REPORT_FILE"
cat runbooks/security-baseline.md >> "$REPORT_FILE" 2>/dev/null || \
  echo "security-baseline.md nicht gefunden" >> "$REPORT_FILE"

# -------------------------------------------
# EBENE 3: Claude Code Analyse
# -------------------------------------------

echo ""
echo "=== Deterministische Checks abgeschlossen ==="
echo "=== Starte Claude Code Analyse ==="
echo ""

# Claude Code im Headless Mode aufrufen
# --allowedTools einschränken: nur Lesen, kein Bash, kein Schreiben
CLAUDE_OUTPUT=$(cat "$REPORT_FILE" | claude -p \
  "Du erhältst den vollständigen Security-Audit-Report unseres self-hosted Stacks.
Analysiere ihn gemäss den Regeln in .claude/commands/security-review.md.
Erstelle einen priorisierten Bericht mit KRITISCH / WARNUNG / INFO.
Für jedes Finding: Problem, Risiko, konkrete Lösung." \
  --allowedTools "Read,Grep,Glob" \
  --append-system-prompt "Du bist ein Senior Security Engineer. Antworte auf Deutsch. Sei konkret und priorisiere strikt." \
  --output-format text \
  --max-turns 5 \
  2>/dev/null)

# Report speichern
CLAUDE_REPORT="${REPORT_DIR}/claude-review-${DATE}.md"
echo "$CLAUDE_OUTPUT" > "$CLAUDE_REPORT"

echo ""
echo "=== Claude Code Review abgeschlossen ==="
echo "Report: $CLAUDE_REPORT"

# Bei kritischen Findings: Alert
if echo "$CLAUDE_OUTPUT" | grep -qi "KRITISCH"; then
  echo "$CLAUDE_OUTPUT" | mail -s "KRITISCH: Security Review ${DATE}" ops@example.com
  echo "Alert gesendet an ops@example.com"
fi
```

### Condición verificable

```bash
# ¿Script ejecutable?
test -x scripts/full-security-audit.sh && echo "OK" || echo "NICHT AUSFÜHRBAR"

# ¿Existe el último informe de auditoría?
ls -la /opt/audit/reports/claude-review-$(date +%Y-%m-%d).md 2>/dev/null
# Expectativa: archivo de hoy

# ¿El informe contiene las secciones esperadas?
grep -c "KRITISCH\|WARNUNG\|INFO" /opt/audit/reports/claude-review-$(date +%Y-%m-%d).md
# Expectativa: al menos 1
```

## B2 - Cuándo se ejecuta la auditoría

### Tres puntos de activación

```
1. Cron semanal (domingo 6:00 h)
   -> Auditoría completa de todo el stack
   -> Resultado: informe priorizado para la semana

2. En Pull Requests (CI/CD)
   -> Solo los archivos modificados
   -> Resultado: comentario de review en el PR

3. Ad-hoc (manual)
   -> Tras incidentes, deployments importantes, cambios de infraestructura
   -> Resultado: análisis inmediato
```

**Cron semanal:**

```bash
# crontab en el audit-runner
0 6 * * 0 /opt/audit/scripts/full-security-audit.sh >> /var/log/security-audit.log 2>&1
```

**PR Review (pasar Git Diff a Claude):**

```bash
#!/bin/bash
# scripts/pr-security-review.sh
# Wird vom CI bei jedem PR aufgerufen

DIFF=$(git diff origin/main...HEAD)

if [ -z "$DIFF" ]; then
  echo "Kein Diff, kein Review nötig"
  exit 0
fi

echo "$DIFF" | claude -p \
  "Review diesen Git Diff auf Sicherheitsprobleme.
Prüfe insbesondere:
- service_role Nutzung in Client-Code
- Server Actions ohne Auth Check
- Edge Functions ohne Signaturprüfung
- Trigger.dev Tasks ohne maxDuration
- Hardcoded Secrets
- Neue API Endpoints ohne Rate Limiting

Antworte NUR wenn du ein konkretes Problem findest.
Wenn alles in Ordnung ist, sage: Keine Sicherheitsprobleme gefunden." \
  --allowedTools "Read,Grep,Glob" \
  --output-format text \
  --max-turns 3
```

**Review ad-hoc:**

```bash
# Manuell nach einem Incident
cd /opt/infra-repo
claude -p "Prüfe den aktuellen Zustand des Repositories auf Sicherheitsprobleme. \
Fokus auf die letzten 5 Commits." \
  --allowedTools "Read,Grep,Glob,Bash(git log*),Bash(git diff*)" \
  --max-turns 10
```

### Condición verificable

```bash
# ¿Cron Job activo?
crontab -l | grep "full-security-audit"
# Expectativa: entrada presente

# ¿Última auditoría hace menos de 8 días?
LAST_REPORT=$(ls -t /opt/audit/reports/claude-review-*.md 2>/dev/null | head -1)
if [ -n "$LAST_REPORT" ]; then
  AGE=$(( ($(date +%s) - $(stat -c %Y "$LAST_REPORT")) / 86400 ))
  echo "Letzter Report: $AGE Tage alt"
  [ "$AGE" -gt 8 ] && echo "WARNUNG: Audit überfällig"
fi
```

## Parte C - Qué puede hacer Claude y qué no

## C1 - Dónde Claude Code es especialmente fuerte

Claude reconoce relaciones que los checks determinísticos no pueden ver:

**Detectar deriva arquitectónica:**
Los checks determinísticos encuentran que existe una nueva Edge Function. Claude reconoce que esa Function contiene lógica de negocio que pertenece a [Next.js](/es/revista/nextjs-supabase-configuracion-segura/) porque procesa input de usuario y transforma datos en lugar de recibir un evento externo.

**Patrones a través de los límites de archivos:**
Un `grep` encuentra que falta `getUser()` en una Server Action. Claude reconoce que esa Action es la única de 15 Actions a la que le falta el check, y que fue añadida la semana pasada en un commit que también modificó otros tres archivos que están todos correctos. Eso indica un descuido, no un problema sistemático.

**Priorización:**
Los checks determinísticos producen una lista plana de 30 hallazgos. Claude los agrupa: "Los 5 hallazgos de service_role están todos en la Admin Library y son correctos. Los 2 checks de autenticación faltantes en los Route Handlers son el riesgo real, porque afectan a endpoints de API públicos."

**Contexto de configuración:**
Un port scan muestra que el puerto 8000 está abierto. Claude sabe por el contexto del stack (CLAUDE.md) que el puerto 8000 es el puerto interno de Kong, y verifica si debería escuchar solo en localhost.

## C2 - Qué Claude Code no puede hacer y no debe hacer

**Claude no puede escanear activamente.** No puede realizar escaneos de red, verificar procesos en ejecución ni probar puertos desde el exterior. Eso lo hacen las herramientas determinísticas (nmap, ss, docker ps). Claude analiza su output.

**Claude no debe escribir en producción.** La restricción `--allowedTools` en el modo headless asegura que Claude solo pueda leer:

```bash
# CORRECTO: Solo herramientas de lectura permitidas
claude -p "..." --allowedTools "Read,Grep,Glob"

# INCORRECTO: Bash permitido = Claude puede ejecutar comandos arbitrarios
claude -p "..." --allowedTools "Read,Grep,Glob,Bash"
```

Cuando Bash es necesario (p. ej. para `git log`), permitir solo comandos específicos:

```bash
--allowedTools "Read,Grep,Glob,Bash(git log*),Bash(git diff*)"
```

**Claude no es determinístico.** El mismo input puede generar informes ligeramente diferentes. Por eso Claude no sustituye a los checks determinísticos. Interpreta sus resultados.

> **Estadística:** Según el informe de OWASP de 2024, más del 34% de las brechas de seguridad resultan de errores de configuración, no de vulnerabilidades en el código, exactamente el tipo de problemas que el análisis contextual está diseñado para detectar.


**Claude no conoce datos en tiempo real.** Trabaja con los snapshots que se le proporcionan en el momento de la auditoría. Entre la auditoría y la lectura del informe, el estado puede haber cambiado.

## C3 - Reglas de seguridad para Claude Code en CI

```bash
# En el servidor de auditoría: configuración de Claude Code

# 1. API Key propio con límite de presupuesto
#    Key separado, no el key de desarrollo
#    Presupuesto: máx. 50 USD/mes para CI Reviews

# 2. --allowedTools siempre restringido
#    Nunca acceso Bash sin restricciones en scripts automatizados

# 3. --max-turns limitado
#    Previene bucles infinitos con inputs confusos
#    Recomendación: 3-5 para PR Reviews, 5-10 para Full Audits

# 4. Output siempre guardado en archivo
#    No solo en stdout, para que el informe sea trazable

# 5. Claude Code no tiene acceso SSH a producción
#    Los scripts determinísticos recopilan los datos
#    Claude solo recibe la salida de texto para su análisis
```

## Checklist de deployment

```
Instalación
  [ ] Claude Code instalado en audit-runner
  [ ] API Key configurado (key CI separado con límite de presupuesto)
  [ ] Modo headless funciona (test con claude -p)

Configuración
  [ ] .claude/commands/security-review.md creado
  [ ] CLAUDE.md presente en el repositorio de infraestructura
  [ ] --allowedTools restringido a Read,Grep,Glob
  [ ] --max-turns limitado a 5-10

Automatización
  [ ] Script de auditoría completo presente y ejecutable
  [ ] Cron job semanal activo
  [ ] Script de PR Review integrado en CI
  [ ] Alerta configurada para hallazgos críticos

Seguridad
  [ ] Claude Code se ejecuta SOLO en el audit-runner
  [ ] Claude Code NO tiene acceso SSH a producción
  [ ] Sin acceso Bash sin restricciones en --allowedTools
  [ ] Los informes se almacenan y archivan
  [ ] Límite de presupuesto configurado en el API Key
```

## Conclusión

Claude Code no es un escáner de seguridad automático ni un sustituto de los checks determinísticos. Es un **analista contextual** que interpreta los resultados de escáneres y checks basados en grep, reconoce relaciones y prioriza recomendaciones.

El workflow es siempre el mismo: las herramientas determinísticas recopilan hechos, Claude Code los interpreta, una persona decide. Esto funciona porque cada nivel hace lo que mejor sabe hacer. Los scripts son fiables con patrones conocidos. Claude reconoce patrones desconocidos. Las personas toman decisiones.

La combinación de los scripts de verificación de los Artículos 1-4, el Custom Security Review Command y el cron de auditoría semanal da como resultado un control de seguridad que detecta tanto riesgos conocidos como inesperados.

Quien siga estos principios junto con una [arquitectura Cert-Ready-by-Design](/es/revista/cert-ready-by-design/) construye seguridad verificable en lugar de auditorías a posteriori.

<div class="not-prose my-12 border border-gosign-border bg-gosign-light rounded-card p-6 lg:p-8">
<div class="flex items-start gap-4">
<div class="flex-shrink-0 w-12 h-12 bg-gosign-dark rounded-card flex items-center justify-center">
<svg width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="white" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 15v4a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2v-4"/><polyline points="7 10 12 15 17 10"/><line x1="12" y1="15" x2="12" y2="3"/></svg>
</div>
<div>
<h2 class="text-h3 font-bold text-gosign-dark mb-2" id="listas-de-verificacion-de-la-serie">Listas de verificación de la serie</h2>
<p class="text-body text-gosign-text mb-4">Prompts preparados para Claude Code. Cada lista de verificación comprueba automáticamente los puntos de seguridad del runbook correspondiente e informa APROBADO, ADVERTENCIA o CRÍTICO.</p>
<div class="flex flex-wrap gap-3">
<a href="/downloads/claude-check-artikel-1-supabase-es.md" download class="inline-flex items-center px-4 py-2 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-sm">Supabase Infrastructure</a>
<a href="/downloads/claude-check-artikel-2-nextjs-es.md" download class="inline-flex items-center px-4 py-2 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-sm">Next.js Security</a>
<a href="/downloads/claude-check-artikel-3-edge-functions-es.md" download class="inline-flex items-center px-4 py-2 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-sm">Edge Functions</a>
<a href="/downloads/claude-check-artikel-4-trigger-dev-es.md" download class="inline-flex items-center px-4 py-2 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-sm">Trigger.dev</a>
</div>
</div>
</div>
</div>

## Índice de la serie

1. [Supabase Self-Hosting Runbook](/es/revista/supabase-self-hosting/)
2. [Next.js sobre Supabase de forma segura](/es/revista/nextjs-supabase-configuracion-segura/)
3. [Supabase Edge Functions de forma segura](/es/revista/supabase-edge-functions-seguridad/)
4. [Trigger.dev Background Jobs en producción segura](/es/revista/trigger-dev-background-jobs/)
5. [Claude Code como control de seguridad en el workflow DevOps](/es/revista/claude-code-security-devops/) - este artículo
6. [Security Baseline para todo el stack](/es/revista/security-baseline-stack/)

El siguiente y último artículo describe la **Security Baseline para el stack completo**, que reúne todas las reglas de los Artículos 1-5 en un único archivo verificable.

--- Comité de Empresa & AI Literacy: Las preguntas organizativas ---
> Los proyectos de IA fracasan por la organizacion, no por la tecnologia. Informacion, consulta y formacion desde 2025.

## La técnica rara vez es el problema

Cuando los proyectos de IA fracasan en empresas, en los menos casos se debe a la tecnología. Los modelos funcionan. Las APIs son estables. La infraestructura está disponible. Lo que fracasa es la organización: el comité de empresa bloquea la implantación porque fue informado demasiado tarde. Los empleados no usan las nuevas herramientas porque no fueron formados.

Este artículo trata las dos preguntas organizativas que acompañan cada implantación de IA: ¿Cómo ganar al comité de empresa como aliado? ¿Y cómo cumplir la obligación legal de AI Literacy?

El EU AI Act (Artículo 4) establece la obligación de AI Literacy para todos los usuarios de sistemas de IA desde febrero de 2025. Sanciones por incumplimiento: hasta 35 millones EUR o el 7% de la facturación anual.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">De un vistazo - Comite de Empresa & AI Literacy</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Los proyectos de IA fracasan por la organizacion, no por la tecnologia. El comite de empresa y AI Literacy son los dos factores decisivos.</li>
<li>Involucre al comite de empresa en la fase de arquitectura, no en la presentacion de resultados. Un Decision Layer hace la IA transparente y auditable por diseno.</li>
<li>AI Literacy es obligatoria desde febrero de 2025 (EU AI Act, Articulo 4). Sanciones por incumplimiento: hasta 35 millones EUR o el 7% de la facturacion.</li>
<li>Un acuerdo de empresa se vuelve ejecutable cuando sus reglas se implementan como restricciones tecnicas en el Decision Layer.</li>
<li>Los programas de formacion por roles convierten obligaciones de compliance en ventajas competitivas: empleados informados usan la IA de forma mas efectiva.</li>
</ul>
</div>

## Comité de empresa y derecho de información y consulta - de bloqueador a habilitador

### Por qué el comité de empresa debe participar

En empresas españolas con representación laboral, el Comité de Empresa tiene derechos de información y consulta conforme al Estatuto de los Trabajadores cuando se introducen sistemas tecnológicos que afectan las condiciones laborales. Los sistemas de IA casi siempre entran en este ámbito: procesan datos de uso, registran interacciones, y sus decisiones afectan directa o indirectamente las condiciones de trabajo.

Esto no es un obstáculo, sino un marco de diseño. El comité no tiene derecho de veto absoluto sobre la IA - tiene derecho a ser informado y consultado sobre las condiciones de su implantación conforme al Art. 64 ET.

El problema no surge por el derecho de información y consulta en sí, sino por el momento en que se involucra al comité. En la mayoría de proyectos de IA fracasados, el comité es informado cuando la decisión técnica ya está tomada. Recibe una presentación con resultados finales, no tiene posibilidad de influir en la arquitectura, y reacciona con el único medio que le queda: el rechazo.

### La arquitectura como respuesta

Las preguntas del comité son legítimas y predecibles: ¿Qué datos procesa el sistema de IA? ¿Quién tiene acceso? ¿Se capturan datos de rendimiento? ¿Quién toma la decisión final - la IA o un humano? ¿Se pueden rastrear las decisiones?

El [Decision Layer](/es/decision-layer/) responde estas preguntas técnicamente, no solo en un acuerdo de empresa en papel. La capa arquitectónica define:

**Límites de decisión:** Qué puede preparar la IA, qué decide un reglamento, qué debe aprobar un humano.

**Human-in-the-Loop:** Aprobación humana forzada técnicamente en clases de decisión definidas. Ningún humano puede ser eludido porque la arquitectura no lo permite.

**Audit Trail:** Cada decisión de IA se registra - qué modelo, qué entrada, qué salida, qué regla aplicada, si un humano participó.

**Control de acceso (RBAC):** Permisos basados en roles impiden acceso no autorizado a datos o funciones sensibles.

### Acuerdos de empresa como System-Constraints

La ventaja decisiva de una arquitectura de IA bien diseñada: los acuerdos de empresa no solo quedan en papel, sino que se implementan como reglas técnicas en el sistema.

**Primero: Acuerdos como reglamentos configurables.** Lo que dice el acuerdo - por ejemplo "datos de rendimiento no pueden ser evaluados sin consentimiento del empleado" - se implementa como Constraint en el Decision Layer. El sistema no puede eludir el acuerdo porque la regla se impone técnicamente.

**Segundo: Transparencia mediante Audit Trail completo.** El comité puede verificar en cualquier momento qué decisiones tomó el sistema de IA, sobre qué base y si se otorgaron aprobaciones humanas. Sin caja negra, sin cuestión de confianza.

**Tercero: RBAC impide acceso no controlado.** Solo roles definidos tienen acceso a funciones de IA específicas. Un jefe de equipo puede usar el chatbot, pero no el análisis de rendimiento. Un manager de RRHH puede ver el análisis, pero no exportar datos brutos. Los permisos son configurables de forma granular.

**Cuarto: Sin perfilado sin autorización explícita.** La arquitectura garantiza técnicamente que evaluaciones personales solo pueden realizarse con autorización explícita - configurada en el reglamento.

### Recomendación práctica: El taller de arquitectura

Invite al comité al taller de arquitectura - no a la reunión de resultados. Medio día en el que el comité entiende cómo funciona el Decision Layer, qué datos se procesan y cómo los acuerdos de empresa se implementan técnicamente, ahorra meses de negociaciones.

La experiencia muestra: cuando el comité entiende la arquitectura y ve que sus demandas no solo se escuchan, sino que se implementan técnicamente, pasa de potencial bloqueador a aliado activo. El comité no quiere impedir la IA. Quiere asegurar que los derechos de los trabajadores se respeten. Una arquitectura transparente le da exactamente esa seguridad.

## AI Literacy - obligación legal desde febrero 2025

### La base legal

El Artículo 4 del [EU AI Act](/es/revista/eu-ai-act-2026-empresas/) obliga a todos los proveedores y operadores de sistemas de IA a garantizar que sus empleados tengan un nivel suficiente de competencia en IA. La obligación rige desde el 2 de febrero de 2025 y afecta a toda empresa que use IA - independientemente del tamaño e independientemente de la clase de riesgo del sistema.

La formulación "nivel suficiente de competencia en IA" es intencionalmente abierta. Debe interpretarse según el contexto: un miembro del consejo que decide sobre el uso de un sistema de IA necesita competencias diferentes a un gestor que usa un chatbot. Pero ambos necesitan competencias. Y ambas deben estar documentadas.

**Sanciones:** Los incumplimientos de la obligación de AI Literacy caen bajo las disposiciones sancionadoras generales del EU AI Act. Las multas máximas ascienden a 35 millones de euros o el 7 por ciento de la facturación mundial anual.

### ¿Quién debe ser formado?

Todas las personas que usen, operen o decidan sobre sistemas de IA en cualquier forma:

- Consejo de administración y dirección (responsabilidad de decisión)
- Directores de departamento y team leads (responsabilidad de uso)
- Especialistas y gestores (uso operativo)
- IT y desarrollo (operación técnica)
- Comité de empresa (responsabilidad de información y consulta)

### ¿Qué debe formarse?

Los contenidos deben ser adecuados al contexto. Como mínimo se recomiendan cuatro campos de competencia:

1. **Comprensión básica del funcionamiento de la IA:** ¿Cómo funciona un modelo de lenguaje? ¿Cuál es la diferencia entre análisis y decisión? ¿Qué puede la IA, qué no?
2. **Reconocimiento de alucinaciones:** Los modelos de lenguaje generan afirmaciones que suenan plausibles pero son factualmente incorrectas. Los usuarios deben poder verificar resultados críticamente.
3. **Uso responsable:** ¿Qué datos pueden introducirse? ¿Cuáles no? ¿Qué pasa con los datos introducidos? ¿Dónde están los límites del uso?
4. **Protección de datos:** ¿Qué datos personales pueden procesarse? ¿Qué consentimientos son necesarios? ¿Qué datos salen de la red empresarial?

### ¿Cómo demostrar compliance?

El EU AI Act exige la prueba de que las formaciones se han realizado:

- Documentación de contenidos y materiales de formación
- Listas de participantes con fecha y firma
- Actualización regular (recomendado: anual, ad hoc ante cambios significativos del sistema)
- Diferenciación según roles y responsabilidades

Un webinar genérico de 30 minutos no cumple los requisitos. La formación debe ser específica por rol, abordar los sistemas de IA específicos de la empresa y contener elementos interactivos que hagan verificable la comprensión.

## Recomendación práctica: Portal Enterprise-AI como desarrollo de competencias

El [Portal Enterprise-AI](/es/revista/enterprise-ai-chat-interface/) no es solo una herramienta de productividad - es también el instrumento más efectivo para el desarrollo de competencias. Los empleados que trabajan diariamente con un sistema de IA controlado desarrollan en la práctica las competencias requeridas por la obligación de AI Literacy: aprenden a verificar resultados críticamente, entienden qué entradas producen buenos resultados y cuáles no, desarrollan intuición para los límites de la tecnología.

Esto no sustituye la formación formal. Pero la complementa con el factor más importante: la aplicación diaria.

## Conclusión: La organización decide

Las dos preguntas organizativas - participación del comité de empresa y competencia - no son aspectos secundarios de la implantación de IA. Son los aspectos principales. La tecnología está disponible, es asequible y potente. La pregunta es si su organización es capaz de utilizarla.

Un comité de empresa que entiende la arquitectura se convierte en aliado. Empleados formados usan las herramientas productivamente. Y una organización que responde proactivamente a ambas preguntas gana una ventaja competitiva que ninguna actualización de modelo puede sustituir.

Más: [Decision Layer](/es/decision-layer/) | [Governance](/es/governance/) | [HR & AI Agents](/es/hr-ai-agents/)

---

**Enterprise AI-Infrastructure Blueprint 2026, Serie de articulos**

| ← Anterior | Resumen | Siguiente → |
|:---|:---:|---:|
| [EU AI Act 2026: Qué aplica, qué viene, qué hacer](/es/revista/eu-ai-act-2026-empresas/) | [Al resumen](/es/revista/infraestructura-ia-blueprint-2026/) | [Orquestación de agents: n8n, Camunda y alternativas](/es/revista/orquestacion-agentes-plataformas/) |

---

<a href="/es/contacto/" target="_blank" rel="noopener noreferrer">Agendar reunión</a> - 30 minutos para aclarar sus preguntas organizativas.

--- Comité de Empresa e IA: consulta by Design ---
> Acuerdos de empresa como constraints técnicos en el Decision Layer. No convencer al comité de empresa, implementar sus requisitos como reglas.

Los comités de empresa tienen derecho de información y consulta cuando los sistemas de IA toman decisiones sobre trabajadores. El enfoque correcto: implementar sus requisitos como constraints técnicos en el Decision Layer, no como compromisos negociados en papel.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">De un vistazo - Derecho de consulta como Constraint arquitectónico</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Los comités de empresa tienen derecho de información y consulta sobre IA según el art. 64 del Estatuto de los Trabajadores. Los agentes de IA en decisiones de personal están sujetos a estos derechos.</li>
<li>El enfoque estándar de "convencer" trata al comité de empresa como un obstáculo en vez de fuente de requisitos - produciendo compromisos en papel inaplicables.</li>
<li>El enfoque arquitectónico: los acuerdos de empresa se convierten en reglas técnicas en el Decision Layer. Si el acuerdo dice "sin evaluaciones de rendimiento totalmente automatizadas", el sistema impone Human-in-the-Loop.</li>
<li>El Portal del Auditor da al comité de empresa transparencia verificable - cada regla tiene un Control_ID, implementación técnica e historial de evidencias consultable.</li>
<li>Proceso en cuatro pasos: analizar acuerdos existentes, redactar catálogo de requisitos, implementar como controles en Decision Layer, conceder acceso al Portal del Auditor.</li>
</ul>
</div>

Según el Ministerio de Trabajo y Economía Social (2024), solo el 27% de los comités de empresa en España han sido consultados formalmente sobre la implantación de sistemas de IA en sus organizaciones, a pesar de que el art. 64 del Estatuto de los Trabajadores garantiza el derecho de información y consulta sobre nuevas tecnologías.

<table>
<thead>
<tr><th>Requisito del acuerdo de empresa</th><th>Implementación en Decision Layer</th><th>Verificación</th></tr>
</thead>
<tbody>
<tr><td>Sin evaluaciones de rendimiento automatizadas</td><td>Regla Human-in-the-Loop (impuesta)</td><td>Logs de escalación en Portal del Auditor</td></tr>
<tr><td>Informe trimestral sobre decisiones con IA</td><td>Generación automática de informes</td><td>Dashboard del portal con datos en vivo</td></tr>
<tr><td>Detener IA ante sospecha de discriminación</td><td>Trigger de monitoreo de sesgo</td><td>Log de alertas e historial de incidentes</td></tr>
<tr><td>Todos los controles activos y funcionales</td><td>Control_ID por requisito</td><td>Historial de evidencias por control</td></tr>
</tbody>
</table>

## El enfoque habitual: convencer al comité de empresa

En la mayoría de las empresas, la implantación de IA se trata como un proyecto de gestión del cambio. El comité de empresa es informado, convencido, involucrado. El objetivo: conseguir la aprobación del acuerdo de empresa.

Este enfoque tiene un problema: trata al comité de empresa como un obstáculo, no como fuente de requisitos. El acuerdo de empresa se formula como un compromiso, se redacta en lenguaje jurídico y se archiva en una carpeta. La implementación técnica a menudo queda sin definir.

## El mejor enfoque: derecho de información y consulta como Constraint arquitectónico

En la arquitectura Gosign, los acuerdos de empresa se implementan como constraints técnicos en el [Decision Layer](/es/decision-layer/). Los requisitos del comité de empresa no se negocian como compromisos, sino que se implementan como reglas en el sistema.

Si el acuerdo de empresa establece: "Las decisiones sobre evaluaciones de rendimiento no pueden tomarse de forma completamente automatizada", esto se implementa como regla Human-in-the-Loop en el Decision Layer. El agente no puede eludir físicamente esta regla.

Si el acuerdo de empresa establece: "El comité de empresa recibe un informe trimestral sobre todas las decisiones de personal apoyadas por IA", el Portal del Auditor genera este informe automáticamente.

Si el acuerdo de empresa establece: "Ante la sospecha de patrones discriminatorios, el uso de IA para el proceso afectado debe detenerse inmediatamente", esto se convierte en un trigger de monitoreo de sesgo en el Decision Layer.

## Qué puede ver el comité de empresa

El comité de empresa recibe acceso al Portal del Auditor, con un acceso dedicado de solo lectura, restringido a los controles relevantes para ellos.

Puede rastrear: qué reglas del acuerdo de empresa están implementadas como controles, si todos los controles están activos y funcionales, con qué frecuencia se activan las escalaciones Human-in-the-Loop y si hay anomalías en el monitoreo de sesgo.

Esta transparencia genera confianza, no mediante promesas, sino mediante tecnología verificable.

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">eBook gratuito: IA en RRHH</p>
<p class="text-body text-gosign-text mb-4">Checklist EU AI Act, framework de decisiones, perspectiva del comité de empresa y evaluación de preparación - el manual de gobernanza para responsables de RRHH.</p>
<a href="/es/ebook/ia-rrhh-manual-gobernanza/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Descargar gratis</a>
</div>

## Implementación práctica

**Paso 1:** Analizar los acuerdos de empresa existentes. ¿Qué regulaciones afectan al uso de IA directa o indirectamente?

**Paso 2:** Formular un nuevo acuerdo de empresa para el uso de IA. No como documento en prosa, sino como catálogo de requisitos con reglas concretas y técnicamente implementables.

**Paso 3:** Implementar los requisitos como controles en el Decision Layer. Cada requisito recibe un Control_ID, una implementación técnica y un generador de evidencias.

**Paso 4:** El comité de empresa recibe acceso al Portal del Auditor. Puede verificar en cualquier momento si sus requisitos están técnicamente implementados.

Más sobre este tema: [Información, Consulta y Comité de Empresa](/es/governance/co-determination/)

<a href="/es/contacto/" target="_blank" rel="noopener noreferrer">Agendar reunión</a>. Le mostramos cómo el derecho de información y consulta se implementa técnicamente.

--- Contrato de encargado IA: Lo que falta en su contrato ---
> Por qué los contratos estándar no cubren la infraestructura de IA empresarial. Con checklist de requisitos para RRHH y compliance.

Un contrato de encargado de tratamiento para infraestructura IA debe cubrir diez áreas que los contratos SaaS estándar no regulan: políticas de registro de prompts, separación de entornos (dev/staging/prod), cadenas de proveedores de modelos, procesamiento in-flight vs. at-rest, protección de datos de embeddings RAG, acceso desde terceros países a datos de producción, cumplimiento del secreto profesional, tokenización PII, trazabilidad del Decision Layer y verificabilidad de medidas técnicas.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">De un vistazo - Contrato de encargado para infraestructura IA</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Los contratos SaaS estándar no cubren registro de prompts, cadenas de proveedores de modelos, separación de entornos ni tokenización PII requeridos por la infraestructura IA.</li>
<li>Diez brechas específicas existen entre los contratos estándar y la realidad de la IA - desde nuevas categorías de datos hasta trazabilidad del Decision Layer.</li>
<li>BSI (2024) señala que el 68% de las organizaciones que usan IA generativa no han actualizado sus contratos de tratamiento para reflejar los flujos de datos específicos de IA.</li>
<li>Un checklist de 25 preguntas ayuda a los responsables de RRHH y compliance a verificar la preparación del proveedor de IA en siete categorías.</li>
<li>Esto no es asesoramiento jurídico - es una brújula arquitectónica que revela brechas de infraestructura detrás de las brechas contractuales.</li>
</ul>
</div>

## Por qué los contratos estándar de encargado de tratamiento no cubren la infraestructura IA

Un contrato estándar de encargado de tratamiento regula cómo un proveedor de servicios trata datos personales por cuenta del responsable. Define la finalidad, las categorías de datos, las medidas técnicas y organizativas, los subencargados y los plazos de conservación. Para un sistema CRM o un software de RRHH, eso es suficiente.

La infraestructura de IA empresarial crea situaciones que ningún contrato estándar contempla. Un modelo de lenguaje procesa prompts  - entradas de texto libre que pueden contener cualquier cosa: datos de personal, información de clientes, secretos empresariales, incluso categorías especiales según el artículo 9 del RGPD cuando un empleado formula una pregunta relacionada con la salud. Los datos fluyen a través de una cadena de sistemas: desde el frontend, pasando por una capa de orquestación, hasta el proveedor del modelo, de vuelta a una base de datos, posiblemente a través de un pipeline RAG con vectores embedding. En cada punto surgen diferentes cuestiones sobre almacenamiento, acceso y supresión.

Cuando solicita a su proveedor de IA su contrato de encargado de tratamiento y recibe un documento estándar, debería alertarse. No porque el proveedor no sea fiable, sino porque los riesgos específicos de la infraestructura IA requieren disposiciones diferentes a las de una aplicación SaaS convencional.

## Diez brechas entre el contrato estándar y la realidad de la IA

### 1. Contenido de prompts como nueva categoría de datos

Los contratos estándar listan categorías de datos: nombre, email, número de empleado. Con agentes IA surge una categoría que no puede predefinirse  - el prompt. Un prompt puede ser una pregunta inocua sobre política de vacaciones o una carta completa de cliente con datos personales. El contrato debe establecer que la responsabilidad de clasificación del contenido recae en la organización, no en el proveedor de IA, mientras que el proveedor debe demostrar medidas técnicas que protejan todo el contenido introducido independientemente de su sensibilidad.

### 2. Política de registro: ¿Qué puede aparecer en los logs?

Con software convencional, se registra lo técnicamente necesario. Con infraestructura IA, el registro adquiere otra dimensión: ¿Se registran los contenidos de los prompts? ¿Se almacenan las respuestas del modelo? ¿Los documentos cargados aparecen en logs de errores?

Un contrato robusto para infraestructura IA debe establecer explícitamente que en el entorno de producción el registro de cuerpos de solicitud/respuesta está desactivado, que solo se registran metadatos técnicos (códigos de estado, latencias, IDs de solicitud), que el registro de depuración en producción está desactivado y que los rastros de pila no contienen contenido de prompts ni documentos.

### 3. Separación de entornos: Dev, Staging, Producción

Todo despliegue enterprise tiene entornos de desarrollo, pruebas y producción. Con infraestructura IA, la separación es crítica para la seguridad porque datos reales pueden utilizarse como datos de prueba durante el desarrollo. Un contrato específico para IA debe establecer que dev y staging utilizan exclusivamente datos sintéticos o anonimizados, que el acceso a producción está restringido a roles definidos dentro de la UE/EEE y que los casos de soporte se gestionan únicamente con datos de prueba aprobados por la organización.

### 4. Cadena de proveedores de modelos en lugar de subencargados clásicos

Con software convencional, un proveedor tiene subencargados: un proveedor de hosting, quizás un servicio de email. Con infraestructura IA surge una cadena de tres niveles: el proveedor de infraestructura IA opera la plataforma, los proveedores de modelos (Azure OpenAI, Google Vertex AI, Anthropic) procesan los prompts y los proveedores de plataforma (Supabase, Vercel) alojan base de datos y frontend.

El punto crítico: ¿Quién es el socio contractual de los proveedores de modelos? ¿Los modelos operan en el tenant del proveedor de IA o en el tenant de la organización? Esta distinción determina si el proveedor del modelo es subencargado del proveedor o si la organización gestiona directamente las relaciones con proveedores.

| Componente | En tenant del cliente | En tenant del proveedor |
|---|---|---|
| Azure Entra ID (SSO) | ✓ Cliente | - |
| Azure OpenAI / Vertex AI | ✓ Cliente | - |
| Supabase (Base de datos) | ✓ Cliente | - |
| Vercel (Hosting) | ✓ Cliente | - |
| Plane (Sistema de tickets) | - | ✓ Proveedor |
| GitHub (Hosting de código) | - | ✓ Proveedor |
| Google Workspace (Comunicación) | - | ✓ Proveedor |

*Los componentes en el tenant del cliente son gestionados por el cliente en su propio registro de proveedores. Los componentes en el tenant del proveedor están sujetos a la lista de subencargados en el contrato.*

### 5. In-flight vs. at-rest: ¿Dónde permanecen los datos?

Con software convencional, la pregunta es sencilla: los datos residen en una base de datos. Con infraestructura IA existen dos modos de procesamiento. Procesamiento in-flight: el prompt se envía al proveedor del modelo, se procesa y se devuelve la respuesta  - sin almacenamiento persistente en el proveedor. Almacenamiento at-rest: chats, archivos cargados y embeddings se almacenan en una base de datos  - de forma persistente y asociada al usuario.

El contrato debe establecer disposiciones separadas para ambos modos.

### 6. RAG y embeddings: Datos vectoriales como nuevo desafío

RAG (Retrieval Augmented Generation) hace que los documentos empresariales sean consultables por IA. Los documentos se convierten en vectores embedding y se almacenan en una base de datos vectorial. Estos vectores son una nueva categoría de datos: no contienen texto legible pero, en determinadas circunstancias, pueden permitir inferencias sobre el contenido original. El contrato debe tratar los embeddings como datos personales cuando se generan a partir de documentos con datos personales.

### 7. Acceso desde terceros países a datos de producción

Muchos proveedores de IA trabajan con equipos distribuidos. Cuando un desarrollador de un tercer país tiene acceso al entorno de producción, esto constituye una transferencia de datos según el RGPD. El contrato debe definir que el acceso a producción está restringido a la UE/EEE, que el acceso a dev/staging desde terceros países es admisible (porque solo contienen datos sintéticos), que RBAC prevé grupos de administradores separados para producción y dev/staging y que existe un procedimiento de excepción que requiere autorización escrita del responsable.

Para empresas con operaciones en Latinoamérica, las transferencias internacionales requieren mecanismos adicionales bajo las legislaciones locales (LGPD en Brasil, Ley Federal de Protección de Datos Personales en México, etc.).

### 8. Secreto profesional en la plataforma IA

Para sectores regulados  - despachos de abogados, asesores fiscales, auditores, organizaciones sanitarias y empresas con procesos sujetos a secreto profesional  - el procesamiento en plataformas IA requiere disposiciones contractuales explícitas. La normativa española contempla la protección del secreto profesional según normativa sectorial. El proveedor debe comprometer a todas las personas con acceso mediante declaraciones escritas de confidencialidad. Las cláusulas estándar de confidencialidad no son suficientes.

### 9. Tokenización PII como módulo opcional

Filtros de entrada y salida que detectan datos personales y los seudonimizan antes de enviarlos al proveedor del modelo añaden una capa adicional de protección. La tokenización PII no es necesaria en cada despliegue, pero el contrato debe contemplarla como módulo opcional. Importante: si la re-identificación reversible es posible, el contrato debe regular quién tiene acceso a la tabla de mapeo, cómo se almacenan y cifran las claves de mapeo y que la re-identificación solo se realiza con finalidad definida tras autorización documentada.

### 10. Trazabilidad y Decision Layer

Los agentes IA toman o preparan decisiones. Cada una de estas decisiones debe ser trazable  - no solo para la protección de datos, sino también para auditoría interna, auditores externos y el comité de empresa. El [Decision Layer](/es/decision-layer/) descompone cada proceso en pasos de decisión individuales y define para cada paso: humano, motor de reglas o IA. El contrato debe anclar la trazabilidad como componente contractual: ¿Qué datos se registran por decisión? ¿Durante cuánto tiempo se conservan? ¿Quién tiene acceso?

## La checklist: 25 preguntas para su proveedor de IA

La siguiente checklist traduce las diez brechas en preguntas de verificación concretas.

**[Checklist de requisitos: 25 preguntas de verificación para contratos IA →](/es/governance/checklist-contrato-ia/)**

### A  - Categorías de datos y finalidades de tratamiento

1. ¿Los contenidos de prompts y respuestas del modelo están listados como categorías de datos independientes en el contrato?
2. ¿Se establece que la responsabilidad de clasificación del contenido recae en la organización, no en el proveedor?
3. ¿Los embeddings/vectores están clasificados como datos potencialmente personales?
4. ¿El contrato contempla las categorías especiales del artículo 9 del RGPD que pueden surgir por entradas de usuarios?

### B  - Registro y monitorización

5. ¿El registro de cuerpos de solicitud/respuesta en el entorno de producción está desactivado?
6. ¿Qué metadatos se registran (códigos de estado, latencias, IDs de solicitud)?
7. ¿El registro de depuración en producción está verificablemente desactivado?
8. ¿Los rastros de pila y mensajes de error están configurados para excluir datos de contenido de los logs?
9. ¿La verificación de la configuración de registro es parte del proceso de lanzamiento?

### C  - Separación de entornos y acceso

10. ¿Existen entornos separados (dev, staging, producción) con políticas de datos distintas?
11. ¿Los entornos dev/staging contienen exclusivamente datos sintéticos o anonimizados?
12. ¿El acceso a producción está restringido a roles autorizados dentro de la UE/EEE?
13. ¿Existe un procedimiento de excepción documentado para casos de soporte con acceso a datos?

### D  - Proveedores de modelos y subencargados

14. ¿La delimitación es clara: Qué proveedores son subencargados del proveedor y cuáles operan en el tenant de la organización?
15. ¿La retención de contenido en los proveedores de modelos está desactivada?
16. ¿La exclusión del uso para entrenamiento está documentada contractualmente?
17. ¿Dónde se ubican los endpoints de los modelos (región UE, US, otros)?

### E  - Almacenamiento y supresión de datos

18. ¿Se establece dónde se almacenan los datos de contenido persistentes (base de datos, región, proveedor)?
19. ¿Qué retención de copias de seguridad aplica y cómo se gestionan los datos eliminados en las copias?
20. ¿El usuario individual puede eliminar sus propios datos dentro de la aplicación?

### F  - Sectores regulados

21. ¿El contrato contiene disposiciones de cumplimiento con el secreto profesional (normativa sectorial española o equivalente)?
22. ¿Existen compromisos de confidencialidad para todas las personas con acceso?
23. ¿La tokenización PII está disponible como módulo opcional?

### G  - Gobernanza y verificabilidad

24. ¿Una trazabilidad de auditoría para decisiones de agentes está anclada como componente contractual?
25. ¿Las medidas técnicas y organizativas pueden evidenciarse bajo solicitud (documentación de configuración, extractos de logs anonimizados)?

## Del checklist a la arquitectura

Estas 25 preguntas no son una herramienta jurídica. Son una brújula arquitectónica. Cada pregunta que su proveedor de IA no puede responder revela una brecha en su infraestructura  - no solo en su contrato.

En Gosign, hemos integrado estos requisitos en la arquitectura: [separación de entornos con bloqueo de producción](/es/revista/hosting-ia-estrategias-enterprise/), registro sin datos de contenido, proveedores de modelos en el tenant del cliente, [Decision Layer](/es/decision-layer/) con trazabilidad completa de auditoría. No porque un cliente lo exigiera, sino porque la IA empresarial sin estas bases no es auditable.

Si desea evaluar cómo su infraestructura IA actual se compara con estos 25 puntos  - o si está evaluando una nueva plataforma  - hablemos.

**[Concertar una conversación →](/es/contacto/)**

--- Qué cuesta realmente la IA: comparación TCO empresarial ---
> Los precios por token son engañosos. Las cuatro categorías de coste de la IA empresarial, con tres escenarios de 26.000 a 410.000 euros.

## Los precios por token no son sus costes de IA

Cuando las empresas hablan de costes de IA, la discusión casi siempre empieza por los precios de tokens. Es comprensible: los proveedores promocionan sus modelos con precios de entrada y salida por millón de tokens, y estas cifras son fáciles de comparar. Un modelo premium cuesta 5 dólares por millón de tokens de entrada, un modelo económico 0,25 dólares. La diferencia parece dramática.

Pero en la práctica, los precios de tokens representan solo entre el 20 y el 35 por ciento de los costes reales. Quien reduce su planificación presupuestaria de IA a los precios de tokens subestima los costes totales en un factor de tres a cinco. La verdadera pregunta no es: "¿Cuánto cuesta un token?". La pregunta es: "¿Cuánto cuesta operar IA de forma productiva, segura y conforme en mi empresa?"

Este artículo presenta las cuatro categorías de coste que abarca toda implantación de IA empresarial, compara tres escenarios de 26.000 a 410.000 euros en el primer año y explica cómo Model Switching puede reducir los costes de tokens entre un 40 y un 60 por ciento.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">De un vistazo - Costes reales de la IA enterprise</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Los precios de tokens representan solo el 20 al 35% de los costes reales. Infraestructura, gobernanza y personal suponen el 65 al 80% restante.</li>
<li>Tres escenarios: entrada ~26.000 EUR (1 chatbot, 50 usuarios), estándar ~148.000 EUR (3 agentes, híbrido), enterprise ~410.000 EUR (10+ agentes, GPUs propias).</li>
<li>Según Deloitte (2024), las empresas que planifican presupuestos de IA solo con precios de tokens subestiman los costes totales por un factor de 3 a 5 en promedio.</li>
<li>Model Switching reduce costes de tokens un 40 a 60% enrutando solicitudes simples a modelos económicos y tareas complejas a modelos premium.</li>
<li>Los costes de infraestructura se concentran en los meses 1 a 6; desde el segundo año, costes de modelo y personal dominan el mix de TCO.</li>
</ul>
</div>

## Las cuatro categorías de coste

Toda implantación de IA en el contexto empresarial se distribuye en cuatro categorías de coste. La ponderación relativa varía según el escenario, pero la estructura se mantiene.

### 1. Costes de modelo: tokens y hosting (20-35%)

La categoría más visible: tasas de API para modelos en la nube o costes de hosting para modelos self-hosted. Con APIs en la nube se paga por token (entrada y salida por separado). Con self-hosting se paga alquiler de GPU, electricidad y mantenimiento. Los costes dependen directamente del volumen de uso: un chatbot con 50 usuarios genera volúmenes de tokens diferentes a diez agentes especializados con 1.000 usuarios.

Lo que se suele pasar por alto: el self-hosting es más económico que las APIs en la nube a partir de un determinado volumen, pero los costes de entrada son mayores. Una sola GPU con 80 GB de VRAM cuesta aproximadamente 1.200 euros al mes con un proveedor de hosting europeo, independientemente de si está totalmente utilizada o no. Para detalles sobre la decisión de hosting, consulte [Estrategias de hosting de IA para empresas](/es/revista/hosting-ia-estrategias-enterprise/).

### 2. Infraestructura e integración (25-35%)

La categoría más grande y más frecuentemente subestimada. Abarca todo lo necesario para integrar un modelo de lenguaje en su panorama IT existente:

- **API Gateway y capa de enrutamiento:** Un componente central que dirige las solicitudes al modelo adecuado, aplica límites de tasa y rastrea costes.
- **Pipeline RAG:** Si su IA debe acceder a conocimiento interno, necesita un pipeline de Retrieval-Augmented Generation: base de datos vectorial, modelo de embedding, estrategia de fragmentación, indexación.
- **Integración de sistemas:** Integración con sistemas existentes: ERP, CRM, gestión documental, ticketing. Cada interfaz requiere esfuerzo de desarrollo.
- **Portal Enterprise AI:** Una interfaz a través de la cual los empleados realmente utilizan la IA, con SSO, gestión de permisos y Audit Trail.

Estos costes son en gran medida puntuales. Se producen principalmente en los primeros tres a seis meses y se amortizan durante la vida útil. Pero deben planificarse y presupuestarse; de lo contrario, surgen costes ocultos por soluciones improvisadas y retrabajos.

### 3. Gobernanza y compliance (15-20%)

Desde el [EU AI Act](/es/revista/eu-ai-act-2026-empresas/), la gobernanza ya no es un lujo opcional. En España, la AESIA (Agencia Española de Supervisión de Inteligencia Artificial) actuará como autoridad de supervisión. Los costes en esta categoría incluyen:

- **Clasificación de riesgos:** Evaluación de todos los sistemas de IA según las categorías del EU AI Act. Para sistemas de alto riesgo se requiere una evaluación formal de conformidad.
- **Documentación técnica:** El EU AI Act exige documentación exhaustiva del origen de los datos, procedimientos de entrenamiento, indicadores de rendimiento y medidas de mitigación de riesgos.
- **Audit Trail y monitorización:** Registro continuo de todas las decisiones de IA, especialmente en procesos de toma de decisiones automatizados.
- **Protección de datos:** Tratamiento conforme al RGPD y a la LOPDGDD (Ley Orgánica 3/2018). Contratos de encargo de tratamiento, evaluaciones de impacto en protección de datos para el tratamiento de datos personales.
- **Asesoría externa:** Asesoramiento jurídico para cuestiones regulatorias, Delegado de Protección de Datos (DPD), y en su caso organismo de evaluación de conformidad.

La proporción de gobernanza crece con la complejidad del despliegue de IA. Un chatbot individual para consultas de conocimiento general tiene requisitos de gobernanza más bajos que un sistema de IA que preselecciona candidaturas.

### 4. Personal y desarrollo de competencias (20-30%)

Los sistemas de IA deben operarse, mantenerse y desarrollarse. Simultáneamente, los empleados deben ser capaces de utilizar los sistemas. Esta categoría incluye:

- **ML-Ops / AI-Engineering:** Al menos una persona responsable de gestión de modelos, optimización de prompts, monitorización y resolución de problemas. En el escenario enterprise, un equipo dedicado.
- **AI Literacy:** Formación para todos los usuarios, legalmente obligatoria desde febrero de 2025 según el EU AI Act. Incluye formación inicial y actualizaciones periódicas.
- **Gestión del cambio:** Acompañamiento de la organización en la transición. Nuevos procesos, nuevos roles, nuevas responsabilidades.

En escenarios pequeños, el desarrollo de competencias puede realizarse internamente, sin costes de personal adicionales, pero con costes de oportunidad. En escenarios mayores se necesita personal dedicado o apoyo externo.

### Distribución de costes de un vistazo

```
Costes de modelo (Tokens/Hosting)      ████████░░░░░░░░░░░░  20-35%
Infraestructura e integracion          ██████████░░░░░░░░░░  25-35%
Gobernanza y compliance                ██████░░░░░░░░░░░░░░  15-20%
Personal y competencias                ████████░░░░░░░░░░░░  20-30%
```

La distribución cambia con el tiempo: en el primer año dominan infraestructura e integración. A partir del segundo año aumentan las proporciones relativas de costes de modelo y personal, mientras desaparecen los costes de integración puntuales.

## Tres escenarios en comparación

Los tres escenarios siguientes representan puntos de entrada típicos. Las cifras son valores de referencia basados en experiencia de proyectos con empresas de distintos tamaños. Sus costes reales dependen de la [infraestructura IT](/es/servicios/infraestructura/) existente, los requisitos de integración y el modelo operativo elegido.

| Escenario | Setup de modelo | Token/Hosting mensual | Integración | Gobernanza | Personal | Total 12 meses |
|---|---|---|---|---|---|---|
| **Entrada:** 1 chatbot, 50 usuarios | Sonnet API | ~500 EUR | 15.000 EUR | 5.000 EUR | 0 (interno) | **~26.000 EUR** |
| **Estándar:** 3 agentes, 200 usuarios | Sonnet + Llama self-hosted | ~4.000 EUR | 60.000 EUR | 20.000 EUR | 1 ML-Ops (parcial) | **~148.000 EUR** |
| **Enterprise:** 10+ agentes, 1.000+ usuarios | Multi-modelo, GPU propia | ~12.000 EUR | 150.000 EUR | 50.000 EUR | 2 FTE | **~410.000 EUR** |

### Escenario 1: Entrada (aprox. 26.000 euros / 12 meses)

Un caso de uso claramente definido: un chatbot de conocimiento interno para un departamento, basado en API en la nube. 50 usuarios, volumen de consultas moderado, sin integración de sistemas más allá de la carga de documentos. La gobernanza se limita al tratamiento conforme al RGPD y la LOPDGDD y una documentación básica. Sin costes de personal porque el departamento IT interno asume la operación junto con el trabajo diario.

Este escenario es el típico Proof of Concept. Demuestra el valor, valida la tecnología y proporciona datos empíricos para la escalación. Un PoC bien definido con un caso de uso claro se sitúa típicamente entre 15.000 y 30.000 euros y es realizable en cuatro a seis semanas.

### Escenario 2: Estándar (aprox. 148.000 euros / 12 meses)

Tres agentes especializados para distintos procesos, por ejemplo análisis documental, comunicación con clientes y gestión de conocimiento interno. 200 usuarios, hosting híbrido: solicitudes no críticas via API en la nube, datos sensibles via modelo self-hosted. Integración con al menos un sistema existente. La gobernanza incluye clasificación de riesgos según el EU AI Act y documentación formal. Un ingeniero ML-Ops se encarga parcialmente de la gestión de modelos y la monitorización.

Este escenario es la entrada productiva. La organización ha completado el PoC y escala a varios departamentos. La infraestructura está diseñada para el crecimiento.

### Escenario 3: Enterprise (aprox. 410.000 euros / 12 meses)

Diez o más agentes especializados en múltiples áreas de negocio. Más de 1.000 usuarios. Arquitectura multi-modelo con GPUs propias. Integración profunda en ERP, CRM, sistemas de RRHH y gestión documental. Gobernanza a nivel enterprise: evaluación formal de conformidad para sistemas de alto riesgo, Audit Trail, dashboard de gobernanza. Dos ingenieros ML-Ops a tiempo completo para operación y desarrollo continuo.

Este escenario presupone que la organización ha completado la fase de experimentación y opera la IA como infraestructura estratégica. Los 410.000 euros parecen una inversión considerable, y lo son. Pero se distribuyen en un sistema que acelera cientos de procesos, reduce tasas de error y mejora las bases de decisión.

### Contexto: ¿cuánto cuestan las alternativas?

Los costes de un sistema de IA nunca deben evaluarse de forma aislada. La magnitud de comparación relevante es: ¿cuánto cuestan los procesos sin IA? Si tres gestores dedican dos horas diarias cada uno a la clasificación de documentos, eso supone aproximadamente 180.000 euros anuales a coste completo, para una tarea que un agente entrenado resuelve en segundos. El ROI raramente es la pregunta. La pregunta es con qué rapidez se materializa.

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">eBook gratuito: IA en Finanzas</p>
<p class="text-body text-gosign-text mb-4">Compliance, auditores externos y Decision Layer - el manual de gobernanza para dirección financiera.</p>
<a href="/es/ebook/ia-finanzas-manual-gobernanza/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Descargar gratis</a>
</div>

## Optimización de costes mediante Model Switching

La palanca más eficaz para los costes de modelo no es elegir un modelo más barato, sino el uso diferenciado de múltiples modelos. Este principio se llama Model Switching o Model Routing.

### El principio

No toda solicitud necesita un modelo premium. La mayoría de las solicitudes empresariales (respuestas estándar, clasificación simple, extracción de datos de documentos estructurados) pueden responderse con modelos económicos con un nivel de calidad suficiente. Solo para tareas complejas (razonamiento en múltiples pasos, análisis de contratos, preparación de decisiones) es necesario un modelo premium.

Una lógica de enrutamiento decide automáticamente qué modelo procesa cada solicitud. Los criterios son configurables:

- **Complejidad:** Solicitudes simples a modelos económicos, complejas a modelos premium.
- **Sensibilidad de datos:** Solicitudes con datos personales a modelos self-hosted, solicitudes no críticas a APIs en la nube.
- **Requisitos de latencia:** Aplicaciones en tiempo real a modelos rápidos y pequeños. Procesamiento por lotes a modelos potentes sin presión temporal.
- **Límite de costes:** Limitación automática cuando se alcanza un presupuesto de equipo o departamento.

### Potencial de ahorro

En la práctica, las solicitudes empresariales se distribuyen típicamente así:

- **60-70% solicitudes estándar:** Clasificación simple, FAQ, extracción de datos. Los modelos económicos son suficientes.
- **20-30% complejidad media:** Resúmenes, análisis estructurado, borradores. Modelos con buena relación calidad-precio.
- **5-15% alta complejidad:** Razonamiento en múltiples pasos, análisis de contratos, documentos estratégicos. Modelos premium.

Cuando el 65 por ciento de las solicitudes utiliza un modelo económico que cuesta una vigésima parte del modelo premium, los costes de tokens se reducen entre un 40 y un 60 por ciento, con calidad de resultado equivalente para el uso global. Los detalles sobre la [selección de modelos y los perfiles de rendimiento de los modelos actuales](/es/revista/modelos-ia-comparacion-2026/) se encuentran en el artículo correspondiente de esta serie.

### Implementación

Model Switching requiere tres componentes:

1. **Motor de enrutamiento:** Una lógica central que analiza las solicitudes entrantes y las dirige al modelo adecuado. Puede implementarse de forma basada en reglas (detección de palabras clave, rol de usuario, clasificación de datos) o basada en modelos (un pequeño modelo de clasificación evalúa la complejidad).
2. **Registro de modelos:** Un directorio central de todos los modelos disponibles con sus perfiles de rendimiento, costes y disponibilidad.
3. **Monitorización de costes:** Un dashboard que hace transparente el consumo de tokens por modelo, por equipo y por caso de uso. Sin transparencia no hay optimización.

El esfuerzo de implementación de Model Switching es manejable, típicamente de dos a cuatro semanas. El ahorro comienza inmediatamente.

## Planificación presupuestaria: tres recomendaciones

**Primero: planifique con TCO, no con precios de tokens.** Cuando un proveedor le presenta los costes de tokens, falta al menos el 65 por ciento del presupuesto. Exija un cálculo TCO que cubra las cuatro categorías.

**Segundo: empiece con un PoC, pero planifique la escalación.** Un PoC de 15.000 a 30.000 euros demuestra el valor. Pero la arquitectura del PoC debe construirse de forma que escale sin reconstrucción. De lo contrario, paga los costes de integración dos veces.

**Tercero: implemente Model Switching desde el principio.** La capa de enrutamiento tiene un coste puntual bajo y ahorra de forma continua. Quien enruta de forma diferenciada desde el inicio evita el lock-in a un único modelo y mantiene el control de costes.

---

Gosign construye infraestructura de IA con estructura de costes transparente, desde el análisis TCO hasta la operación productiva. Si quiere saber cuánto cuesta la IA en su configuración concreta, hable con nosotros.

<a href="/es/contacto/" target="_blank" rel="noopener noreferrer">Agendar reunión</a>. 30 minutos para calcular sus costes de forma realista.

--- Decision Layer: governance para agentes AI enterprise ---
> El Decision Layer es el componente de governance entre agente AI y sistema destino. Rules Engine, Confidence Routing, Human-in-the-Loop, Audit Trail.

## El problema: decisiones de IA sin trazabilidad

Cuando un agente AI contabiliza una factura, procesa una baja médica o responde a una consulta de compliance, toma una decisión. Esa decisión se basa en un modelo de lenguaje que opera con probabilidades, no con reglas deterministas.

Para un chatbot interno, eso es aceptable. Para procesos críticos de negocio, no. Cuando un agente propone un asiento contable, debe ser trazable: ¿Qué regla se aplicó? ¿En qué versión? ¿Con qué nivel de confianza? ¿Intervino un humano?

Sin esa trazabilidad, las decisiones de IA no son implantables en entornos regulados. Los auditores no pueden verificarlas. Los Comités de Empresa no pueden evaluarlas. La auditoría interna no puede seguirlas.

El Decision Layer resuelve este problema.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">De un vistazo - Decision Layer</p>
<ul class="text-body text-gosign-text space-y-2">
<li>El Decision Layer es el componente de governance entre agente AI y sistema destino - cada decisión del agente pasa por él antes de hacerse efectiva.</li>
<li>Descompone procesos en microdecisiones y define para cada una: decide el humano, aplica un reglamento o la IA decide de forma autónoma.</li>
<li>Cuatro componentes - Rules Engine, Confidence Routing, Human-in-the-Loop, Audit Trail - garantizan trazabilidad, compliance y preparación para auditoría.</li>
<li>En decisiones basadas en reglas y repetitivas, la IA supera demostrablemente al humano en consistencia, resistencia a la fatiga y exhaustividad.</li>
<li>Sin Decision Layer, los agentes AI enterprise no superan auditorías, no satisfacen los requisitos del Comité de Empresa y no escalan más allá de pilotos.</li>
</ul>
</div>

[Gartner (2026)](https://www.gartner.com/en/newsroom/press-releases/2026-05-26-gartner-says-applying-uniform-governance-across-ai-agents-will-lead-to-enterprise-ai-agent-failure) pronostica que para 2027 el 40 por ciento de las organizaciones degradará o desactivará agentes AI autónomos debido a brechas de governance.

## ¿Qué es un Decision Layer?

El Decision Layer es el componente central de governance entre un agente AI y el sistema destino. Arquitectónicamente, se sitúa entre el agente, que emite una recomendación, y el sistema donde la decisión se hace efectiva, por ejemplo SAP, [Sage](https://www.sage.com/es-es/) o [Workday](https://www.workday.com/).

El Decision Layer no es un complemento de compliance posterior. Es un principio arquitectónico. Cada decisión del agente pasa por el Decision Layer antes de llegar al sistema destino.

## Decision Layer - explicado para responsables de proceso

La descripción técnica anterior es precisa. Pero para el día a día existe una explicación más sencilla:

El Decision Layer funciona como una descripción de proceso estándar con niveles de decisión claros, solo que se aplica técnicamente, no queda en papel.

En concreto: cada proceso de negocio que un agente AI debe ejecutar se descompone en microdecisiones individuales. Para cada decisión se define de antemano - por personas, no por la IA:

¿Debe decidir aquí un humano? Por ejemplo, porque el Comité de Empresa lo exige, porque existe riesgo de discriminación o porque se trata de una decisión discrecional.

¿Es una regla que se aplica siempre igual? Por ejemplo, una verificación de plazos, un convenio colectivo, una lógica contable. Entonces el agente aplica la regla de forma consistente, en cada sede, con cada empleado, a cualquier hora. Los conjuntos de reglas están versionados: cada cambio crea una nueva versión, las versiones anteriores permanecen rastreables. Aquí, el agente es un ejecutor - no porque no pueda hacer más, sino porque no hay nada que interpretar.

¿Puede la IA decidir aquí por sí misma? El agente interpreta documentos, clasifica situaciones, evalúa contexto y reconoce patrones. Esto no es if-then-else - es capacidad de juicio dentro de límites definidos. El Confidence Routing controla: alta confianza y bajo riesgo significa decisión autónoma; baja confianza o alto riesgo significa escalación a una persona. Este Confidence Routing es precisamente lo que distingue al Decision Layer del RPA.

Cada uno de estos pasos queda documentado: Quién decidió, sobre qué base, con qué resultado. Eso es el Audit Trail, la evidencia que necesitan auditores, Comité de Empresa y auditoría interna.

El resultado: los procesos son más rápidos y consistentes sin perder el control. Y cuando alguien pregunta "¿Cómo se tomó esta decisión?", hay una respuesta.

<table class="w-full text-left text-sm">
<thead><tr class="border-b border-gosign-border">
<th class="py-2 pr-4 font-semibold">Tipo de decisión</th>
<th class="py-2 pr-4 font-semibold">Velocidad</th>
<th class="py-2 pr-4 font-semibold">Auditabilidad</th>
<th class="py-2 pr-4 font-semibold">Nivel de riesgo</th>
<th class="py-2 pr-4 font-semibold">Ejemplo</th>
</tr></thead>
<tbody>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Decisión humana</td><td class="py-2 pr-4">Baja (minutos a días)</td><td class="py-2 pr-4">Alta (revisión documentada)</td><td class="py-2 pr-4">Bajo (juicio humano)</td><td class="py-2 pr-4">Plan de reincorporación</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Basada en reglas</td><td class="py-2 pr-4">Alta (instantánea)</td><td class="py-2 pr-4">Alta (reglas versionadas)</td><td class="py-2 pr-4">Bajo (determinista)</td><td class="py-2 pr-4">Clasificación salarial</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">IA autónoma</td><td class="py-2 pr-4">Alta (instantánea)</td><td class="py-2 pr-4">Alta (Audit Trail)</td><td class="py-2 pr-4">Medio (Confidence Routing)</td><td class="py-2 pr-4">Clasificación de documentos</td></tr>
</tbody>
</table>

La implementación técnica de esta lógica consta de cuatro componentes:

### Los cuatro componentes

**1. Rules Engine**

Reglamentos especializados, versionados y trazables. Convenios colectivos, acuerdos de empresa, lógica contable, legislación fiscal, reglas de compliance. Cada regla tiene una versión, una fecha de validez y un ámbito de aplicación.

Cuando una regla cambia, por ejemplo un nuevo convenio colectivo o una directriz contable modificada, se genera una nueva versión. La versión anterior permanece en el sistema. En una auditoría es trazable qué regla en qué versión estaba vigente en el momento de la decisión.

**2. Confidence Routing**

No todas las decisiones del agente tienen el mismo nivel de certeza. El Decision Layer evalúa automáticamente cada decisión:

- Alta confianza + bajo riesgo = procesamiento autónomo. El agente decide, el resultado va al sistema destino.
- Baja confianza o alto riesgo = escalación a un humano. El workflow se pausa, un responsable revisa y decide.
- Caso excepcional o patrón desconocido = bloqueo. Sin output, se requiere aclaración humana.

Los umbrales de confianza y riesgo son configurables y específicos por cliente. Una firma de auditoría establecerá umbrales distintos a los de un centro de servicios compartidos.

**3. Human-in-the-Loop**

Human-in-the-Loop en el Decision Layer es un principio arquitectónico, no una casilla opcional. Para tipos de decisión definidos, la arquitectura impone revisión humana:

- Decisiones con potencial discriminatorio
- Decisiones que afectan materias sujetas a consulta del comité de empresa
- Decisiones por encima de umbrales de valor definidos
- Primera aplicación de una nueva regla

El requisito de Human-in-the-Loop se aplica técnicamente, no organizativamente. Un agente no puede eludir esta revisión.

**4. Audit Trail - el acta de decisión**

Cada decisión genera un acta de decisión completa e inmutable:

- Input: ¿Qué se proporcionó al agente?
- Modelo: ¿Qué modelo de lenguaje y en qué versión se utilizó (p. ej. `claude-opus-4-7-2026-04-12`, `gpt-5.5-2026-03-pro`, `mistral-medium-3.1-eu`, `deepseek-v4-pro-on-prem`)?
- Regla de negocio: ¿Qué regla en qué versión se aplicó?
- Confianza: ¿Cuán seguro estaba el agente?
- Routing: ¿Se decidió autónomamente o se escaló?
- Resultado: ¿Cuál fue la decisión?
- Marca de tiempo: ¿Cuándo se decidió?
- Vía de impugnación: ¿Quién puede impugnar esta decisión - el afectado, el comité de empresa, el auditor?

Esta acta de decisión es lo que los auditores ven en el Auditor Portal. No documentación retrospectiva, sino la evidencia técnica del proceso de decisión. Y es la respuesta arquitectónica al art. 86 del EU AI Act - el derecho del afectado a la explicación de la decisión individual.

## Cómo funciona el Decision Layer en la práctica

Un ejemplo concreto del procesamiento de documentos:

Llega un documento - una factura de proveedor. El Document Agent lee el documento y extrae la información relevante: emisor, importe, descripción del servicio, fecha.

El agente crea una propuesta de asiento: cuenta, centro de coste, IVA deducible, inicio de amortización. Esta propuesta va al Decision Layer.

El Decision Layer verifica: ¿Es la propuesta consistente con los reglamentos versionados? ¿Es correcto el centro de coste? ¿Es correcto el IVA deducible para este tipo de factura? ¿Está el importe dentro de los límites de procesamiento autónomo?

Si es afirmativo: la propuesta va al sistema destino (SAP u otro ERP). La ruta de decisión completa se almacena en el Audit Trail.

Si no: consulta al responsable. El workflow se pausa. El responsable ve la propuesta, la regla aplicada, el valor de confianza y el motivo de la escalación. Decide. También esta decisión humana se documenta en el Audit Trail.

## Qué modelos enruta actualmente el Decision Layer

El Decision Layer es agnóstico respecto al modelo - cada microdecisión es enrutada por la capa de routing al modelo que mejor encaja por capacidad técnica y por coste. A mayo de 2026, el routing dirige tráfico productivo, entre otros, a:

- **Claude Opus 4.7** y **Claude Sonnet 4.6** (Anthropic, Cloud API) - por la calidad del razonamiento en escalaciones de compliance, expedientes largos y síntesis de Decision Record
- **GPT-5.5** (OpenAI, Cloud API o Azure OpenAI con residencia de datos en la UE) - para extracción estructurada y tool use
- **Gemini 3.1 Pro** (Google, Cloud API) - para procesamiento multimodal de documentos (PDF + escaneo + tabla)
- **Mistral Small 3.2** (Apache 2.0, self-host o La Plateforme) - para clasificación de alto volumen y sensible al coste
- **Mistral Medium 3.1** (La Plateforme, región UE) - cuando la residencia de datos en la UE debe estar garantizada contractualmente sin disponer de clúster propio
- **DeepSeek V4-Pro** y **V4-Flash** (licencia MIT, self-host o API) - para investigación en profundidad y rutas de decisión con rigor matemático-lógico
- **Llama 4 Scout** (licencia Meta, self-host, contexto de 10M tokens) - para expedientes largos y contexto completo de expediente de personal
- **gpt-oss-120b** (OpenAI, Apache 2.0, self-host) - cuando se necesita un modelo OpenAI sin dependencia cloud
- **Qwen 3 Coder 110B**, **DeepSeek Coder V4**, **Codestral Mamba 32B** - para microdecisiones de código y ABAP/SQL en el backend

Qué modelo se selecciona para cada microdecisión (criterios de selección, panorama de benchmarks, comparación TCO para IBEX 35 y mediana empresa de gama alta) se aborda en el artículo principal [Modelos de IA 2026 - qué modelo de lenguaje para qué tarea](/es/revista/modelos-ia-comparacion-2026/). Qué parte se puede self-hostear on-prem - incluyendo dimensionado de GPU, condiciones de licencia y stack de self-hosting - se aborda en el spinoff [IA open-source autohospedada 2026](/es/revista/ia-open-source-autohospedada-2026/).

## Por qué la IA toma algunas decisiones mejor que un humano

En la discusión sobre agentes AI se omite una pregunta: ¿Existen decisiones en las que la IA no solo es más rápida, sino demostrablemente mejor? La respuesta es sí. Y el Decision Layer permite identificar exactamente esos casos.

Hay tres categorías en las que las decisiones autónomas de IA superan a las humanas, no porque la IA sea más inteligente, sino porque carece de las debilidades estructurales del ser humano:

**Consistencia entre sedes y personas.** 50 empleados en 12 sedes aplican el mismo convenio colectivo. Cada uno interpreta los casos límite de forma ligeramente diferente. En la sede A se aprueba un pago especial; en la sede B se rechaza el mismo caso. No es un problema de formación: es la varianza natural de las decisiones humanas. Una IA que opera sobre un reglamento versionado decide de forma idéntica. Cada vez, en cada sede.

**Inmunidad a la fatiga en decisiones repetitivas.** Un técnico de selección evalúa de manera diferente un lunes por la mañana que un viernes por la tarde. Tras 50 candidaturas, la atención decae. El candidato anterior era fuerte, el siguiente parece más débil en comparación (sesgo de anclaje). Una IA evalúa la candidatura numero 1 con el mismo rigor que la candidatura numero 200. No tiene un mal día.

**Exhaustividad en la verificación de reglas.** Un administrativo de RRHH comprueba una baja médica contra tres o cuatro criterios que le vienen a la mente: duración de la baja, plazo de continuación salarial, quizá el umbral del plan de reincorporación. Pero, ¿comprueba también el periodo de carencia? ¿La regla especial para trabajadores a tiempo parcial del convenio de empresa? ¿La obligación de notificación a la Seguridad Social en determinados diagnósticos? ¿Cada vez? ¿También un viernes a las 16:00? Una IA verifica contra todas las reglas vigentes, en la versión actual, de forma completa y documentada. No porque sea más inteligente, sino porque no olvida.

Esto no significa que la IA sea mejor en todo. Decisiones discrecionales, evaluaciones individuales, encaje cultural, consideraciones éticas: esos son y seguirán siendo dominios humanos. Pero en decisiones basadas en reglas, repetitivas y con alta necesidad de consistencia, la IA autónoma no es un compromiso. Es la mejor solución.

El Decision Layer operacionaliza esta distinción: para cada microdecisión define si decide el humano, el reglamento o la IA, y en las decisiones de IA documenta *por qué* la IA es aquí la elección correcta.

## Por qué ningún agente debería pasar a producción sin Decision Layer

Sin Decision Layer, un agente AI es una caja negra. Produce resultados, pero nadie puede trazar cómo. Eso tiene consecuencias concretas:

**Auditoría:** Auditores y auditoría interna necesitan trazabilidad. Sin Audit Trail, cada decisión del agente es un riesgo de auditoría. El auditor debe verificar manualmente cada caso individual, lo cual es más laborioso que trabajar sin agente.

**Información y consulta:** Los Comités de Empresa tienen derechos de información y consulta conforme al Art. 64 del Estatuto de los Trabajadores en la implantación de sistemas AI. Sin lógica de decisión trazable, no pueden ejercer su función. El Decision Layer convierte los acuerdos de empresa en restricciones técnicas del sistema.

**Responsabilidad:** Si un agente genera un asiento erróneo y no existe ruta de decisión, no está claro quién es responsable. El Decision Layer documenta la cadena de responsabilidad.

**Escalabilidad:** Un agente que funciona en un piloto no tiene por qué funcionar en producción. Sin infraestructura de governance, cada agente es un caso aislado. El Decision Layer permite governance consistente para todos los agentes.

## Decision Layer y Cert-Ready by Design

El Decision Layer es la base técnica de Cert-Ready by Design. Los controles son objetos de datos de primera clase en el Decision Layer con atributos definidos: Control_ID, Technical_Implementation, Rule_Version, Evidence_Generator, Evidence_History, Auditor_View.

La evidencia se genera automáticamente, no se recopila a posteriori. Los auditores ven en el Auditor Portal el estado en tiempo real de todos los controles, con drill-down hasta la implementación concreta de cada regla.

El mapeo de frameworks proyecta los controles sobre estándares de auditoría establecidos: ISA, normas nacionales de auditoría y el Plan General Contable (PGC). Una auditoría de cuentas puede realizarse sobre la base de la evidencia generada automáticamente.

Más información: [Cert-Ready by Design](/es/governance/cert-ready/)

> [Decision Layer - visión general y ejemplos](/es/decision-layer/)

→ [Acta de decisión: por qué toda decisión de IA debe ser impugnable](/es/revista/acta-de-decision-decisiones-ia-impugnables/)

<a href="/es/contacto/" target="_blank" rel="noopener noreferrer">Reservar una reunión</a> - Le mostramos cómo sería un Decision Layer para su proceso concreto.

--- Eliminar errores de nómina estructuralmente - Decision Layer ---
> Los asientos correctivos surgen por aplicación inconsistente de reglas. El Decision Layer hace la lógica de decisión explícita, versionada y auditable.

## El problema: lógica profesional implícita

En el procesamiento de documentos contables, las personas toman diariamente cientos de microdecisiones. Cuenta contable, centro de coste, inicio de amortización, IVA soportado, clasificación de gastos. Cada decisión se basa en un conjunto normativo: legislación tributaria (IRPF, IS, IVA), normas contables del PGC, directrices internas, particularidades de cada sociedad.

El problema no es falta de conocimiento profesional. El problema es la inconsistencia. Diferentes gestores aplican el mismo conjunto normativo de forma distinta. No porque sean incompetentes, sino porque la normativa es compleja y su interpretación admite margen de apreciación.

Más sociedades significa más variantes normativas. Más centros de trabajo significa más gestores con interpretaciones diferentes. Más personal significa más procesos de incorporación, más conocimiento implícito, más varianza.

Las consecuencias son medibles: asientos correctivos, hallazgos de auditoría, ciclos de conciliación, cierres mensuales prolongados. Los conjuntos normativos a menudo existen solo en las cabezas de determinados empleados. Cuando estos empleados enferman, están de vacaciones o dejan la empresa, el conocimiento se pierde.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">De un vistazo - Decision Layer para Payroll</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Los errores de nómina provienen del conocimiento implícito - las reglas existen en cabezas, no en sistemas. Cuando el personal se va, el conocimiento se pierde.</li>
<li>Según el Hackett Group (2024), las empresas con reglas de nómina explícitas y versionadas reducen los asientos correctivos entre un 60 y un 80% en el primer año.</li>
<li>El Decision Layer hace explícita, versionada y auditable la aplicación de reglas - cada decisión contable es trazable a una regla definida.</li>
<li>Los casos rutinarios se procesan de forma autónoma; las excepciones se escalan a especialistas con contexto completo y valor de confianza.</li>
<li>La preparación para auditoría se vuelve estructural: cada ruta de decisión se documenta automáticamente desde el documento origen hasta la regla aplicada.</li>
</ul>
</div>

## Decision Layer para procesamiento de documentos

El [Decision Layer](/es/decision-layer/) resuelve este problema haciendo los conjuntos de reglas explícitos, versionados y legibles por máquina. Cada decisión contable se basa en una regla definida en una versión concreta. Donde la decisión es determinista, el agente aplica el conjunto de reglas de forma consistente. Y donde el agente es lo suficientemente confiable y tiene permiso: decide de forma autónoma - interpreta documentos, clasifica situaciones, evalúa contexto. Esto no es if-then-else - es capacidad de juicio dentro de límites definidos.

El flujo: entra un documento. El Document Agent lee y comprende el documento - independientemente del formato. Genera una propuesta de contabilización. El Decision Layer verifica esta propuesta contra los conjuntos de reglas versionados:

¿Es correcta la cuenta contable? ¿Coincide el centro de coste? ¿Es deducible el IVA soportado en este tipo de factura? ¿Es correcto el inicio de amortización? ¿Es la clasificación de gastos consistente con las directrices de la sociedad?

Con alta confianza y regla clara: procesamiento autónomo. La propuesta de contabilización pasa al sistema destino ([SAP FI/CO](https://www.sap.com/products/erp/s4hana.html) u otro ERP). Se genera un Audit Trail completo.

Con baja confianza o excepción: escalado al gestor. El workflow se pausa. El gestor ve la propuesta, la regla aplicada, el valor de confianza y el motivo de escalado.

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">eBook gratuito: IA en Finanzas</p>
<p class="text-body text-gosign-text mb-4">Compliance, auditores externos y Decision Layer - el manual de gobernanza para dirección financiera.</p>
<a href="/es/ebook/ia-finanzas-manual-gobernanza/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Descargar gratis</a>
</div>

## Conjuntos de reglas versionados

Cada cambio de regla genera una nueva versión. La versión anterior permanece en el sistema. En una inspección o auditoría se puede rastrear qué regla en qué versión estaba vigente en el momento de la decisión.

Un ejemplo: el 1 de julio cambia el tipo de IVA para un grupo de productos determinado. En el Decision Layer se crea una nueva versión de la regla, vigente desde el 1 de julio. Los documentos anteriores al 1 de julio se procesan con la versión anterior. Los documentos a partir del 1 de julio con la nueva. La transición es automática, trazable y auditable.

## Parametrización por sociedad

Para despachos de auditoría de cuentas y asesorías fiscales con cientos de clientes: los conjuntos de reglas están parametrizados por sociedad. El mismo agente aplica para cada cliente las reglas correctas en la versión vigente.

El cliente A utiliza el PGC completo, el cliente B utiliza el PGC para PYMES. El cliente C tiene un plan de cuentas individualizado. El Decision Layer garantiza que el agente aplique para cada cliente las reglas correctas - de forma consistente, independientemente de qué gestor tramite el caso.

## Preparación para auditoría

En una inspección tributaria o en la auditoría de cuentas anuales, el auditor de cuentas puede rastrear en el Auditor Portal cada decisión contable individual. La base es el acta de decisión por asiento - el registro inmutable con input/justificante, regla de negocio aplicada con su versión, confianza, resultado, marca de tiempo y vía de impugnación. Desde el documento justificativo hasta la regla aplicada con su versión, desde el valor de confianza hasta el enrutamiento (autónomo o escalado).

Esto reduce significativamente el esfuerzo de auditoría. En lugar de tomar muestras manuales y reconstruir la lógica contable para cada caso, el auditor ve la ruta de decisión completa documentada automáticamente.

<div class="overflow-x-auto">

| Aspecto | Sin Decision Layer | Con Decision Layer |
|---------|-------------------|-------------------|
| Aplicación de reglas | Implícita, dependiente de personas | Explícita, versionada |
| Consistencia entre centros | Variable | Idéntica |
| Asientos correctivos | 3 - 8% de todos los asientos | < 1% |
| Preparación de auditoría | Reconstrucción manual | Documentación automática |
| Transferencia de conocimiento | Meses de incorporación | Reglas autodocumentadas |
| Evidencia de cumplimiento | Basada en muestras | Ruta de decisión completa |

</div>

Más información: [Finance AI Agents](/es/servicios/ai-agents/)

→ [Acta de decisión: por qué toda decisión de IA debe ser impugnable](/es/revista/acta-de-decision-decisiones-ia-impugnables/)

<a href="/es/contacto/" target="_blank" rel="noopener noreferrer">Agendar reunión</a> - Le mostramos cómo un Decision Layer funciona para su procesamiento de documentos.

--- Decision Layer y Shadow AI: control en vez de caos ---
> Cómo el Decision Layer separa análisis de decisión - y por qué eso resuelve Shadow AI, convence al Comité de Empresa y permite escalar.

## Dos problemas. Una arquitectura.

Shadow AI y la falta de governance son los dos mayores obstaculos para escalar la IA en las empresas en 2026. El primer problema: los empleados usan herramientas de IA publicas sin control porque la empresa no ofrece alternativa. El segundo problema: incluso cuando la empresa proporciona IA, falta la arquitectura que separa analisis de decision.

El Decision Layer resuelve ambos problemas. Es la capa de governance que define quien puede decidir que: humano, reglamento o IA. Y es simultaneamente la base para ofrecer a los empleados una herramienta de IA controlada que supera las alternativas publicas.

Este artículo describe por qué Shadow AI es el riesgo del momento, cómo funciona el Decision Layer, qué papel juega la clasificación de datos y por qué sin esta arquitectura ni el Comité de Empresa, ni los auditores, ni la dirección aprobarán el escalado de la IA.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">De un vistazo - Shadow AI y el Decision Layer</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Shadow AI - el uso no controlado de herramientas de IA públicas por empleados - es la Shadow IT de 2026: fuga de datos, riesgo RGPD, cero trazabilidad.</li>
<li>Prohibir la IA fracasa en la práctica. La solución es un portal de IA interno gobernado que supere a las alternativas públicas en funcionalidad y seguridad.</li>
<li>El Decision Layer separa análisis de decisión: la IA puede analizar, pero quién actúa se define por microdecisión (humano, reglamento o IA).</li>
<li>Un esquema de clasificación de datos de cuatro niveles controla el routing de modelos - los datos confidenciales nunca llegan a un modelo público.</li>
<li>Sin arquitectura governance-first, ni el Comité de Empresa, ni auditores, ni la dirección aprobarán el escalado de la IA.</li>
</ul>
</div>

## Shadow AI: el riesgo subestimado

Shadow AI es la Shadow IT de 2026. El termino describe el uso no controlado de servicios de IA publicos por parte de empleados, sin conocimiento del departamento de IT, sin governance, sin Audit Trail.

La realidad en la mayoria de las empresas: los empleados utilizan herramientas de IA publicas para su trabajo diario. Redactan correos, resumen informes, analizan contratos, crean presentaciones. No por mala intencion, sino porque estas herramientas los hacen mas productivos. Y porque la empresa no ofrece una alternativa equivalente.

El problema no es el uso en si. El problema es lo que ocurre durante el proceso:

**Fuga de datos.** Cada entrada en una herramienta de IA publica abandona la red corporativa. Contenidos contractuales, datos financieros, informacion de personal, planes estrategicos. Todo lo que se introduce en un prompt queda fuera de su control.

**Sin trazabilidad.** ¿Que empleado transfirio que datos a que herramienta? Nadie lo sabe. No hay Audit Trail, no hay registro, no hay posibilidad de revision retrospectiva.

**Sin control de calidad.** Los resultados de herramientas de IA publicas influyen en decisiones de negocio sin que sea visible sobre que base se generaron. Un borrador de contrato parcialmente creado por IA. ¿Quien revisa las clausulas?

**Riesgo RGPD.** Los datos personales transmitidos a servicios de IA publicos pueden constituir un incidente de proteccion de datos sujeto a notificacion. No en teoria, sino segun la interpretacion legal vigente.

La solucion no es prohibir. Las prohibiciones fracasan en la practica. Se eluden, se ignoran o se esquivan. La solucion es una oferta mejor: un portal de IA interno que sea funcionalmente al menos equivalente, pero equipado con governance, proteccion de datos y Audit Trail. Como es ese portal lo describe el articulo [Enterprise-AI-Portal: mas que un simple chat](/es/revista/enterprise-ai-chat-interface/).

## El Decision Layer: analisis no es decision

El Decision Layer es el principio arquitectonico que separa analisis de decision. Un modelo de IA puede analizar: resumir datos, detectar patrones, calcular probabilidades, emitir recomendaciones. Pero la decision de si y como actuar sobre ese analisis es una cuestion separada. Esa cuestion la responde el Decision Layer.

El principio: cada proceso de negocio se descompone en microdecisiones. Para cada microdecision individual se define de antemano quien decide:

```
Evento entrante
|
+----------+
| Decision  |
|  Layer    |
+----------+
+----+------------+
v    v            v
REGLA   IA        HUMANO
```

**REGLA:** Decisiones deterministicas que siempre producen el mismo resultado. Verificaciones de plazos, aplicacion de convenios colectivos, logica contable, umbrales de valor. El reglamento esta versionado. Cada cambio genera una nueva version; la anterior permanece trazable.

**IA:** Decisiones en las que el modelo puede actuar autonomamente dentro de limites definidos. Clasificaciones estandar, comunicacion rutinaria con plantillas verificadas, asignaciones inequivocas. Solo con alta confianza y bajo riesgo.

**HUMANO:** Decisiones discrecionales, excepciones, casos con potencial discriminatorio, decisiones por encima de umbrales de valor definidos, todos los casos en que el Comite de Empresa ejerce su derecho de informacion y consulta.

Cuatro principios hacen efectivo el Decision Layer:

**Reglas explicitas y versionadas.** Cada regla de decision tiene un identificador, una version, una fecha de validez y un ambito de aplicacion. Cuando un acuerdo de empresa cambia, se crea una nueva version de la regla. En una auditoria es trazable que regla estaba vigente en el momento de la decision.

**Human-in-the-Loop impuesto arquitectonicamente.** Para tipos de decision definidos, el sistema no puede continuar sin aprobacion humana. Esto se impone tecnicamente, no se acuerda organizativamente. Un agente no puede eludir esta revision porque la arquitectura no lo permite, no porque una politica lo prohiba.

**Audit Trail por microdecisión - el acta de decisión.** Cada microdecisión individual genera un acta de decisión inmutable: input, regla de negocio aplicada con su versión, valor de confianza, versión del modelo, resultado, marca de tiempo y vía de impugnación. No es documentacion retrospectiva. Es el registro tecnico del proceso decisorio - y hace cumplible la explicación de la decisión individual conforme al art. 86 del EU AI Act.

**Acuerdos de empresa como restricciones del sistema.** Los requisitos del Comite de Empresa no se implementan como directrices organizativas, sino como reglas tecnicas en el Decision Layer. El sistema no puede eludir el acuerdo de empresa porque es parte de la logica del sistema. El Comite de Empresa puede rastrear cada decision en el Audit Trail.

## Clasificacion de datos como fundamento

Antes de que el Decision Layer pueda ser efectivo, hay que responder a una cuestion fundamental: ¿Que datos pueden ser procesados por que modelo de IA? La respuesta la proporciona un esquema de clasificacion de cuatro niveles:

| Nivel | Denominacion | Ejemplos | Procesamiento de IA permitido |
|---|---|---|---|
| 1 | Publico | Notas de prensa, contenido web | Todos los modelos, incluidas APIs publicas |
| 2 | Interno | Presentaciones, documentos de proceso, directrices internas | Nube UE o modelos self-hosted |
| 3 | Confidencial | Datos de RRHH, datos financieros, contratos, datos de clientes | Solo self-hosted o con anonimizacion PII |
| 4 | Estrictamente confidencial | Documentos de M&A, patentes, comunicacion de la direccion | Solo On-Premises, ningun modelo en nube |

La clasificacion determina automaticamente el routing del modelo. Cuando un empleado formula una pregunta sobre un contrato (nivel 3), el sistema dirige automaticamente la solicitud a un modelo self-hosted o anonimiza los datos antes de la transferencia. Un modelo publico no es opcion para datos de nivel 3. La arquitectura garantiza que sea tecnicamente imposible, no solo organizativamente prohibido.

La clasificacion de datos no es una tarea puntual. Debe integrarse en los procesos existentes: cada nuevo documento, cada nueva fuente de datos, cada nuevo proceso recibe una clasificacion. Idealmente de forma automatizada, basandose en tipo de documento, reconocimiento de contenido y asignacion organizativa.

Sin clasificacion de datos falta el fundamento para cualquier otra medida de governance. Es la primera decision que debe tomarse, antes de la seleccion del modelo, antes de construir la [infraestructura](/es/servicios/infraestructura/).

## Los cinco pilares del AI Governance

La clasificacion de datos es el fundamento. Sobre el se construyen cinco pilares que conforman un AI Governance completo:

**1. Control de acceso.** ¿Quien puede usar que funciones de IA? ¿Que asistentes, que bases de conocimiento, que agentes estan disponibles para que roles? El control de acceso refleja la estructura organizativa existente: RRHH ve asistentes de RRHH, Finanzas ve asistentes de Finanzas. La integracion SSO garantiza que no haya que gestionar accesos separados.

**2. Auditoria y logging.** Cada interaccion con el sistema de IA se registra. No para vigilar empleados, sino para la trazabilidad de decisiones de negocio. ¿Quien formulo que pregunta y cuando? ¿Que modelo respondio? ¿Basandose en que fuentes? El Audit Trail es la base para auditoria interna, revision financiera y evidencias de compliance. La [arquitectura de referencia de governance](/es/governance/reference-architecture/) describe la implementacion tecnica en detalle.

**3. Human Oversight.** La arquitectura define donde se requiere revision humana. No es un requisito generico. Es una decision diferenciada por microdecision. Las clasificaciones rutinarias no necesitan revisor humano. Las decisiones de personal con potencial discriminatorio, siempre. La granularidad de esta diferenciacion distingue un governance eficaz de uno burocratico.

**4. Aseguramiento de la calidad.** Los resultados de IA deben verificarse, no cada uno, pero si sistematicamente. Muestreos, feedback de usuarios, evaluacion automatizada. ¿Alucina el modelo? ¿Son correctas las referencias a fuentes? ¿Son correctas las aplicaciones de reglas? El aseguramiento de calidad es un proceso continuo, no un test puntual.

**5. Compliance y reporting.** La [EU AI Act](/es/revista/eu-ai-act-2026-empresas/) exige documentacion tecnica, clasificacion de riesgos y Conformity Assessment para sistemas de IA de alto riesgo. La clasificacion de alto riesgo se mantiene; conforme a la legislacion vigente, estas obligaciones se aplican desde agosto de 2026, con un aplazamiento a diciembre de 2027 acordado provisionalmente por el Digital Omnibus (mayo de 2026, adopcion formal aun pendiente). El AI Governance debe incorporar estos requisitos desde el principio, no anadirlos despues. Informes periodicos sobre uso, rendimiento de modelos, calidad de decisiones y estado de compliance son la base para la gestion directiva.

## Por que el Decision Layer es la clave para escalar

Las empresas que quieren escalar la IA - de un proyecto piloto a diez agentes en produccion, de un departamento a toda la organizacion - se topan sin Decision Layer con un limite duro. No tecnico, sino organizativo.

**El Comite de Empresa no dara su consentimiento.** En Espana, el Comite de Empresa tiene derechos de informacion y consulta sobre la implantacion de sistemas de IA que afecten a las condiciones laborales, segun el Estatuto de los Trabajadores. Sin logica de decision trazable, sin Human-in-the-Loop documentado, sin acuerdos de empresa como restricciones del sistema, ningun Comite de Empresa dara su aprobacion. El Decision Layer proporciona exactamente la transparencia y controlabilidad que el Comite exige.

**La auditoria interna no dara luz verde.** Auditores y revision interna necesitan trazabilidad. Cuando un agente AI genera asientos, evalua contratos o prepara decisiones de personal, la ruta decisoria debe ser auditable. Sin Audit Trail, cada decision del agente es un riesgo de auditoria. El Decision Layer genera automaticamente la evidencia que los auditores necesitan.

**La direccion no aprobara el presupuesto.** Los proyectos piloto se financian con presupuestos de innovacion. Escalar requiere presupuestos de inversion, y estos exigen un business case con cifras solidas. El Decision Layer proporciona los datos: tiempos de proceso, tasas de error, coste por operacion, tasas de escalacion. Sin estos datos, la IA sigue siendo una partida de coste sin retorno demostrable.

El orden no es negociable: primero governance, luego escalado. No al reves.

## Cookieless y Privacy by Design

Un portal enterprise de IA no solo debe proteger los datos de las consultas de los usuarios, sino tambien el propio uso. Esto significa: sin tracking, sin cookies analiticas, sin analisis de comportamiento.

**SSO en lugar de cuentas separadas.** Los empleados se autentican a traves del sistema de gestion de identidades existente de la empresa. Sin contrasenas separadas, sin perfiles de usuario separados en un proveedor externo.

**Sin cookies de seguimiento.** El portal de IA interno no utiliza cookies para analisis de comportamiento. Los datos de uso se recopilan exclusivamente para el Audit Trail - no para marketing, no para optimizacion de producto por terceros, no para perfilado.

**Datos de uso solo para auditoria.** Que empleado formulo que consulta se registra, pero exclusivamente para fines de governance: trazabilidad, compliance, aseguramiento de calidad. El acceso a estos datos esta restringido a roles autorizados (seguridad IT, Delegado de Proteccion de Datos (DPD), revision). El superior jerarquico no ve las consultas individuales de sus empleados.

**Privacy by Design.** Los requisitos de proteccion de datos estan integrados en la arquitectura, no anadidos despues. Anonimizacion PII, clasificacion de datos, routing de modelos - todos estos mecanismos operan automaticamente, basandose en la clasificacion de los datos, no en la disciplina de los usuarios.

Este enfoque convence no solo al Delegado de Proteccion de Datos, sino tambien al Comite de Empresa: el sistema no vigila a los empleados. Documenta decisiones de negocio.

---

[Decision Layer](/es/decision-layer/) es el componente central de governance de Gosign. Agnostico respecto al modelo, compatible con el Comite de Empresa, con Audit Trail completo y un acta de decisión por microdecisión - impugnable conforme al [art. 86 del EU AI Act](/es/revista/acta-de-decision-decisiones-ia-impugnables/). Mas sobre la [arquitectura de governance](/es/governance/).

<a href="/es/contacto/" target="_blank" rel="noopener noreferrer">Reservar una reunion</a>. 30 minutos para determinar como seria un Decision Layer para sus procesos y como abordar Shadow AI en su empresa de forma controlada.

--- Decision Layer vs. SAP Joule vs. Microsoft Copilot ---
> SAP Joule y Microsoft Copilot son agentes de IA. El Decision Layer es la capa de governance sobre ellos. Por qué las empresas necesitan ambos.

## La confusión

Los decisores empresariales oyen hablar de SAP Joule, Microsoft Copilot, Google Gemini, despliegues internos de GPT - y se preguntan: ¿Qué necesito de todo esto y dónde encaja un Decision Layer?

La respuesta es más sencilla de lo que parece: Joule, Copilot y otros son agentes de IA - ejecutan tareas. El [Decision Layer](/es/decision-layer/) no es una alternativa a estos agentes. Es la capa de governance que se sitúa por encima y controla lo que estos agentes pueden hacer.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">De un vistazo - Decision Layer vs. agentes enterprise</p>
<ul class="text-body text-gosign-text space-y-2">
<li>SAP Joule y Microsoft Copilot son agentes de IA que ejecutan tareas. El Decision Layer es la capa de governance que controla lo que pueden hacer.</li>
<li>Ni Joule ni Copilot ofrecen mecanismos integrados para acuerdos de empresa, cumplimiento del AI Act ni rutas de decisión auditables.</li>
<li>El Decision Layer es agnóstico respecto al modelo y al agente - funciona con cualquier agente, incluidos modelos open source.</li>
<li>Las empresas en entornos regulados necesitan ambos: un agente para la ejecución y un Decision Layer para governance.</li>
<li>Los agentes son intercambiables. Governance es infraestructura.</li>
</ul>
</div>

## Agente vs. capa de governance

Un agente de IA puede ejecutar una tarea: resumir un documento, crear una propuesta de contabilización, responder a una consulta normativa. Lo que el agente no puede: decidir si puede ejecutar esa tarea de forma autónoma o si debe intervenir un humano.

SAP Joule puede proponer un ajuste salarial en SuccessFactors. Pero Joule no decide si esa propuesta puede pasar directamente al sistema o si el comité de empresa tiene derecho de información y consulta conforme al Art. 64 del Estatuto de los Trabajadores. Joule no conoce los acuerdos de empresa. Y el audit logging de Joule registra acciones y citas de fuentes - pero no un acta de decisión a nivel de reglas de negocio que documente qué cláusula del convenio colectivo, en qué versión, sustentó la decisión.

Microsoft Copilot puede crear un documento de onboarding. Pero Copilot no decide qué grupo profesional corresponde según el convenio colectivo, si el comité de empresa debe aprobar, ni si se cumplen los requisitos del RGPD de la ubicación concreta.

El Decision Layer asume exactamente este control.

## Cómo colaboran Decision Layer y agentes enterprise

El Decision Layer descompone cada proceso empresarial en pasos de decisión individuales y define de antemano para cada uno: ¿Decide una persona, un conjunto de reglas o la IA de forma autónoma? Donde interviene la discrecionalidad, la arquitectura impone la revisión humana. Donde la decisión es determinista, el agente aplica el conjunto de reglas de forma consistente. Y donde el agente es lo suficientemente confiable: decide de forma autónoma - interpreta, clasifica, evalúa contexto. Esto no es if-then-else - es capacidad de juicio dentro de límites definidos. Cuando SAP Joule genera una propuesta de contabilización, esa propuesta pasa por el Decision Layer antes de hacerse efectiva en el sistema destino.

El Decision Layer verifica: ¿Es la propuesta consistente con los conjuntos de reglas versionados? ¿Supera la confianza el umbral? ¿Afecta la decisión a un ámbito sujeto a consulta del comité de empresa? ¿Es necesario Human-in-the-Loop?

Si todo encaja: la propuesta pasa al sistema destino. El Audit Trail documenta la decisión.

Si no: el workflow se pausa. Un humano recibe la propuesta, la regla aplicada, el valor de confianza y el motivo de escalado. Decide. Su decisión también queda documentada.

## Por qué las empresas en España necesitan ambos

SAP Joule y Microsoft Copilot se despliegan cada vez más en empresas españolas. Pero el despliegue encuentra tres barreras que el agente por sí solo no resuelve:

Primero: los comités de empresa exigen transparencia y ejercen sus derechos de información y consulta sobre las decisiones de IA conforme al Art. 64 del Estatuto de los Trabajadores. Ni Joule ni Copilot ofrecen mecanismos integrados para que los acuerdos de empresa funcionen como restricciones técnicas. En España, donde el Estatuto de los Trabajadores y los convenios colectivos regulan estos derechos, esto es crítico.

Segundo: el AI Act exige governance documentado para sistemas de IA de alto riesgo - y los procesos de RRHH entran en esta categoría. La clasificación de alto riesgo se mantiene; conforme a la legislación vigente, estas obligaciones se aplican desde agosto de 2026, con un aplazamiento a diciembre de 2027 acordado provisionalmente por el Digital Omnibus (mayo de 2026, adopción formal aún pendiente). Las obligaciones abarcan análisis de riesgos, documentación, transparencia y supervisión humana - y con el art. 86, el derecho del afectado a la explicación de la decisión individual, que solo puede responderse mediante un acta de decisión por microdecisión. Los agentes enterprise solos no cumplen esto. Para empresas españolas sujetas al marco regulatorio de la UE, es un requisito ineludible.

Tercero: los auditores de cuentas y el control interno necesitan rutas de decisión trazables. Un agente que "hace una propuesta" sin una ruta de decisión documentada es un riesgo de auditoría según las Normas Técnicas de Auditoría.

El Decision Layer complementa SAP Joule y Microsoft Copilot con exactamente estas tres dimensiones: compatibilidad con los derechos de información y consulta del comité de empresa, cumplimiento del AI Act y preparación para auditoría.

## La distinción de un vistazo

| Capacidad | SAP Joule | Microsoft Copilot | Decision Layer |
|---|---|---|---|
| Ejecución de tareas | Sí | Sí | No (solo governance) |
| Acuerdos de empresa como restricciones técnicas | No | No | Sí |
| Documentación de cumplimiento AI Act | No | No | Sí |
| Ruta de decisión auditable | No | No | Sí |
| Acta de decisión por microdecisión (regla de negocio + versión) | No | No | Sí |
| Confidence Routing con escalación | No | No | Sí |
| Human-in-the-Loop (impuesto arquitectónicamente) | No | No | Sí |
| Agnóstico del modelo | No (ecosistema SAP) | No (ecosistema Microsoft) | Sí |

SAP Joule es el agente dentro del ecosistema SAP. Microsoft Copilot es el agente dentro del ecosistema Microsoft. El Decision Layer es la capa de governance agnóstica respecto al modelo y al agente que se sitúa sobre ambos.

Los agentes son intercambiables. Governance es infraestructura.

> [Decision Layer en detalle](/es/revista/decision-layer-explicado/)

> [Acta de decisión: por qué toda decisión de IA debe ser impugnable](/es/revista/acta-de-decision-decisiones-ia-impugnables/)

> [Arquitectura de referencia](/es/governance/reference-architecture/)

<a href="/es/contacto/" target="_blank" rel="noopener noreferrer">Agendar reunión</a> - Le mostramos cómo el Decision Layer funciona en su infraestructura de sistemas existente.

--- Alojar DeepSeek en tu propia infraestructura ---
> Cómo las empresas despliegan la familia DeepSeek (R1, V4-Flash, V4-Pro) y otros LLMs conforme al RGPD en Azure, GCP o Self-Hosted. Arquitectura, soberanía de datos, enrutamiento de decisiones frente a un único modelo campeón.

## Por qué DeepSeek es relevante para las empresas

[DeepSeek](https://www.deepseek.com/) ha demostrado con sus modelos open source que los LLMs de alto rendimiento no tienen que proceder necesariamente de OpenAI o Google. La familia DeepSeek abarca desde **R1 (enero de 2025, licencia MIT)**, pasando por **V4-Flash (abril de 2026, 284B/13B activos MoE, MIT)**, hasta **V4-Pro (1,6T/49B activos, contexto de 1M, MIT)**, y alcanza en benchmarks el **nivel de GPT-5.5 / Claude Opus 4.7** - V4-Pro se acerca al rendimiento frontier de los modelos cerrados bajo licencia MIT, con costes operativos significativamente menores y total transparencia sobre el código del modelo.

**Actualización mayo 2026:** DeepSeek V4-Pro (1.6T/49B activos MoE) y V4-Flash (284B/13B activos) se publicaron el 24 de abril de 2026 como preview bajo licencia MIT. Para nuevos despliegues, V4-Flash es el caballo de batalla típico, mientras que V4-Pro encaja en setups de clase hyperscaler o se ejecuta vía API/hosted para despliegues más pequeños. La arquitectura R1 sigue siendo madura y production-ready, pero está siendo reemplazada por V4-Flash en nuevos despliegues. Detalles en el artículo [IA open source autohospedada 2026](/es/revista/ia-open-source-autohospedada-2026/).

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">De un vistazo - DeepSeek en uso enterprise</p>
<ul class="text-body text-gosign-text space-y-2">
<li>DeepSeek R1 es open source (licencia MIT) y puede ejecutarse completamente self-hosted en Azure, GCP o on-premise - sin fuga de datos.</li>
<li>El self-hosting elimina el riesgo RGPD del uso de la API, donde los datos fluyen a China. El modelo en sí no es el riesgo - la API lo es.</li>
<li>Las tres opciones de alojamiento (Azure, GCP, self-hosted) son técnicamente equivalentes; la elección depende del panorama IT y los requisitos de compliance.</li>
<li>Una arquitectura agnóstica de modelos previene el vendor lock-in: cuando aparece un modelo mejor, se integra sin reconstrucción.</li>
<li>IDC (2024) estima que el 42% de las grandes empresas europeas planean desplegar al menos un LLM open-weight en infraestructura privada antes de finales de 2026.</li>
</ul>
</div>

Para las empresas esto es relevante porque crea una opción real de elección: en lugar de depender de un único proveedor de LLM, las organizaciones pueden ejecutar varios modelos en paralelo, compararlos y utilizar el más adecuado para cada caso de uso.

La pregunta fundamental no es si DeepSeek es lo bastante bueno. La pregunta es cómo una empresa opera LLMs de forma que se garanticen la soberanía de datos, el compliance y la preparación para el futuro, independientemente de qué modelo sea actualmente el más avanzado.


## Tres opciones de alojamiento comparadas

### Azure: integración enterprise como fortaleza

Azure AI Foundry ofrece DeepSeek como despliegue gestionado. La ventaja para organizaciones con entorno Microsoft existente: integración con Azure Entra ID (antes Azure AD), configuraciones de red y seguridad establecidas, y selección de región para residencia de datos en la UE. Instancias GPU (A100, H100) disponibles en pay-as-you-go o Provisioned Throughput.

El inconveniente: vendor lock-in a nivel de Azure. Migrar después a GCP o Self-Hosted requiere reconstruir la capa de despliegue, salvo que la arquitectura se haya diseñado como agnóstica desde el principio.

### GCP: flexibilidad y Kubernetes nativo

Google Cloud Platform ofrece a través de Vertex AI despliegues gestionados de modelos open source. Su fortaleza reside en la arquitectura nativa de Kubernetes: organizaciones que ya usan GKE (Google Kubernetes Engine) pueden ejecutar LLMs como cargas de trabajo en contenedores junto a los servicios existentes. Las opciones TPU ofrecen una alternativa a las GPUs de NVIDIA.

### Self-Hosted: máximo control

Para empresas con los requisitos más estrictos de protección de datos, como el sector financiero o sanitario, Self-Hosting es la elección coherente. Los modelos DeepSeek se ejecutan en servidores propios o en un centro de datos privado, sin dependencia alguna de la nube. La contrapartida: mayor esfuerzo operativo en gestión de hardware, actualizaciones y escalado.

| Criterio | Azure | GCP | Self-Hosted |
|---|---|---|---|
| Setup | Gestionado (AI Foundry) | Gestionado (Vertex AI) | Manual (bare-metal/VM) |
| Residencia de datos UE | Germany West Central | europe-west3 | Centro de datos propio |
| Disponibilidad GPU | A100, H100 (pay-as-you-go) | A100, H100, TPU | A100, H100 (compra/leasing) |
| Riesgo vendor lock-in | Alto (específico de Azure) | Medio (portable Kubernetes) | Ninguno |
| Esfuerzo operativo | Bajo | Bajo-Medio | Alto |
| Ideal para | Orgs centradas en Microsoft | Orgs nativas de Kubernetes | Máxima soberanía de datos |

Las tres opciones son técnicamente equivalentes. No hay compromisos arquitectónicos con Self-Hosting. La decisión depende del panorama IT existente, los requisitos de compliance y el modelo operativo interno.


## Por qué la decisión de alojamiento no es la más importante

La mayoría de los artículos sobre hosting de LLMs terminan en la decisión de alojamiento. Pero para las empresas, el hosting es solo la base; las preguntas reales vienen después.

Cómo se gobierna qué modelo sirve a cada caso de uso? Cómo se registran prompts y respuestas sin comprometer datos de empleados? Cómo se garantiza al Comité de Empresa transparencia sobre el uso de IA, conforme al Estatuto de los Trabajadores? Cómo se ejecuta un cambio de modelo sin modificar la interfaz para 5.000 empleados?

Estas no son preguntas de hosting. Son preguntas de arquitectura y gobernanza. Y precisamente aquí es donde una infraestructura IA enterprise se distingue de un modelo alojado.


## Arquitectura agnóstica de modelos como estrategia

El panorama de LLMs cambia más rápido que cualquier ciclo de adquisiciones corporativo. Lo que hoy es estado del arte puede ser superado por un nuevo modelo en seis meses. Quien construye toda su infraestructura sobre un único modelo frontier, ya sea DeepSeek V4-Pro, GPT-5.5 o Claude Opus 4.7, asume un riesgo estratégico. Una capa de enrutamiento de decisiones agnóstica de modelos (consulta [Qué modelo cuándo?](/es/revista/modelos-ia-comparacion-2026/)) absorbe el próximo cambio generacional como un ajuste de configuración, no como una reingeniería.

Una [arquitectura agnóstica de modelos](/es/servicios/infraestructura/) desacopla la capa de uso de la capa de modelos. Los empleados utilizan una interfaz de chat unificada. Por detrás, una capa de orquestación enruta por cada micro-decisión en lugar de depender de un modelo campeón: **Mistral Small 3.2** (24B, Apache 2.0, RTX 4090) como caballo de batalla de volumen para el 50-70 % de las decisiones (clasificación, extracción); **DeepSeek V4-Flash / V4-Pro** (MIT) o **gpt-oss-120b** (Apache 2.0) para razonamiento on-prem; **Claude Opus 4.7 / GPT-5.5** (nube) para razonamiento frontier y flujos agénticos; **Gemini 3.1 Pro** (nube) para aplicaciones multimodales; **Qwen 3 Coder / DeepSeek Coder V4** para generación de código on-prem. [Llama](https://llama.meta.com/) y [Mistral](https://mistral.ai/) completan el stack para dominios especializados.

Cambios de modelo, comparativas y tests A/B se ejecutan en la capa de orquestación, de forma transparente para los usuarios, auditable para IT, trazable para el Comité de Empresa.


## DeepSeek como componente, no como plataforma

DeepSeek es un modelo potente. Pero ningún modelo por sí solo resuelve el problema enterprise. Lo que las empresas necesitan no es un LLM alojado, sino una infraestructura en la que los LLMs operen como componentes, integrados en [Governance by Design](/es/governance/), conectados a los sistemas existentes, ampliables con [agentes IA](/es/servicios/ai-agents/) que procesan documentos y orquestan flujos de trabajo.

El [Decision Layer](/es/decision-layer/) separa el análisis del LLM de la decisión de negocio. El modelo prepara, el humano decide, con un Audit Trail completo.

En Gosign construimos esta [infraestructura IA](/es/servicios/infraestructura/): agnóstica de modelos, conforme al RGPD, en Azure, GCP o Self-Hosted. DeepSeek es uno de muchos componentes. La arquitectura marca la diferencia.

--- Portales Enterprise AI: cinco interfaces comparados ---
> LobeChat, OpenWebUI, LibreChat, chatbot-ui y very-ai - cinco portales enterprise AI comparados. Funciones, SSO, protección PII, governance, self-hosting.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">De un vistazo - Portales Enterprise AI</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Un interfaz de chat por sí solo no basta - las empresas necesitan portales con SSO, Audit Trail, compartición de asistentes e integración de agentes para prevenir Shadow AI.</li>
<li>Cinco opciones open source disponibles: LobeChat, OpenWebUI, LibreChat, chatbot-ui y very-ai - cada una adaptada a distintos requisitos de governance.</li>
<li>La detección y anonimización de PII es el diferenciador crítico para entornos regulados donde datos de empleados entran en prompts de IA.</li>
<li>Gartner (2024) informa que el 55% de las organizaciones con IA generativa carecen de un marco de governance para su uso.</li>
<li>El factor decisivo para la adopción no es la tecnología sino la experiencia de usuario - el portal interno debe igualar o superar los servicios públicos de IA desde el primer día.</li>
</ul>
</div>

## El problema: un modelo sin interfaz

Un modelo de IA sin interfaz controlado es como un servidor sin frontend. La tecnología está disponible, pero nadie puede usarla de forma ordenada. Lo que ocurre es previsible: los empleados recurren a servicios de IA públicos - ChatGPT, Gemini, Claude.ai - con sus cuentas personales. Introducen datos corporativos en sistemas fuera del control de IT. No hay Audit Trail, no hay clasificación de datos, no hay control de acceso.

Eso es Shadow AI. La cuestión no es si ocurre en su empresa. La cuestión es cuánto.

La solución no es prohibir el uso de IA. La solución es proporcionar un sistema interno que funcione mejor que las alternativas públicas, y que al mismo tiempo esté bajo control corporativo. Un simple interfaz de chat no basta. Lo que necesita es un portal enterprise AI.

## Lo que un portal enterprise AI debe ofrecer

Un portal enterprise AI es más que una ventana de chat. Es la plataforma central a través de la cual todos los empleados interactúan con la IA - de forma controlada, registrada e integrada en el paisaje tecnológico existente. Seis requisitos distinguen un portal enterprise de un chat de consumo:

### 1. Multi-Model Routing

El portal debe conectar múltiples modelos simultáneamente - APIs propietarias en nube y modelos self-hosted. La lógica de routing decide automáticamente qué modelo atiende cada solicitud: por tipo de tarea, sensibilidad de datos y parámetros de coste. Los empleados ven un interfaz unificado. Qué modelo opera en segundo plano es transparente para ellos pero trazable.

### 2. Compartición de asistentes

Los departamentos crean asistentes especializados - con su propio system prompt, sus propios documentos y su propio reglamento. Un asistente para el departamento jurídico que prepara revisiones de contratos. Un asistente para RRHH que resume documentos de candidatos. Un asistente para compras que compara ofertas de proveedores. Estos asistentes se comparten dentro del departamento, se versionan y se gestionan centralmente.

Esta es la diferencia clave frente a un simple interfaz de chat: no todos los empleados tienen que escribir prompts desde cero. En su lugar, usan un asistente configurado y optimizado por compañeros de su área. Esto baja la barrera de entrada y sube la calidad de los resultados.

### 3. Integración de agentes

Un portal enterprise debe ir más allá del chat. Debe integrar [agentes AI](/es/servicios/ai-agents/) - workflows especializados que procesan documentos, extraen datos, preparan decisiones o se comunican con sistemas externos. El agente se lanza desde el portal, su progreso se muestra y su resultado se documenta en el portal.

### 4. SSO y control de acceso basado en roles (RBAC)

Los empleados se identifican a través del sistema de gestión de identidades existente - Azure AD, Okta, Google Workspace. Sin cuentas separadas, sin contraseñas separadas. El control de acceso es por roles: ¿quién puede usar qué modelos? ¿Quién puede crear asistentes? ¿Quién puede acceder a qué fuentes de documentos? ¿Quién tiene acceso a workflows de agentes?

### 5. Audit Trail

Cada interacción se registra. ¿Quién hizo qué consulta y cuándo? ¿Qué modelo respondió? ¿Qué documentos se referenciaron? ¿Qué costes se generaron? El Audit Trail es exportable - para auditoría interna, para revisiones de compliance, para documentación de la EU AI Act.

### 6. Flexibilidad de despliegue

El portal debe ser desplegable en distintos entornos: como servicio en nube (Supabase, Vercel), como contenedor en un centro de datos europeo, o On-Premises. La decisión de hosting del portal sigue los mismos criterios que la decisión de hosting de los modelos.

## Interfaces open source en comparación

Cinco proyectos open source se han posicionado como candidatos para portales enterprise AI: LobeChat, OpenWebUI, LibreChat, chatbot-ui y very-ai. Los cinco son self-hosted, agnósticos respecto al modelo y ofrecen un interfaz de chat para modelos de lenguaje. Las diferencias residen en integración SSO, funciones de governance, protección PII y compatibilidad con el Comité de Empresa.

**Nota de transparencia:** very-ai es desarrollado por Gosign GmbH - el editor de esta serie de artículos. Presentamos las fortalezas y limitaciones de los cinco portales por igual. very-ai se basa en un fork de chatbot-ui (licencia MIT) y se ha convertido en un producto independiente a través de 16 extensiones enterprise.

## Comparación: cinco portales enterprise AI

| Criterio | LobeChat | OpenWebUI | LibreChat | chatbot-ui | very-ai |
|-----------|----------|-----------|-----------|------------|---------|
| **Licencia** | Apache 2.0 | MIT | MIT | MIT | Apache 2.0 |
| **Base** | Proyecto propio | Proyecto propio | Proyecto propio | Proyecto propio | Fork de chatbot-ui |
| **Agnóstico de modelo** | ✅ OpenAI, Anthropic, Google, Ollama | ✅ OpenAI, Ollama, LiteLLM | ✅ OpenAI, Anthropic, Google, Mistral | ✅ OpenAI, Anthropic, Google, Ollama | ✅ OpenAI, Anthropic, Google (Vertex AI), Ollama |
| **SSO** | ❌ No nativo | OAuth 2.0 (sin Entra ID nativo) | OAuth 2.0, OpenID Connect | ❌ No nativo | ✅ Azure Entra ID nativo con sincronización de grupos y permisos |
| **Protección PII** | ❌ | ❌ | ❌ | ❌ | ✅ Detección, anonimización y re-anonimización |
| **PII por asistente/modelo** | - | - | - | - | ✅ Configurable por asistente Y por modelo |
| **Asistentes de grupo** | ❌ | Modelos comunitarios (limitado) | Conversaciones compartidas | ❌ | ✅ Controlados vía grupos Entra ID |
| **Audit Trail** | ❌ | Logging básico | Logging básico | ❌ | ✅ Completo, exportable (CSV/JSON) |
| **Estadísticas RGPD** | ❌ | ❌ | ❌ | ❌ | ✅ Estadísticas de uso anonimizadas |
| **Integración Trigger.dev** | ❌ | ❌ | ❌ | ❌ | ✅ Trigger de workflow desde el chat |
| **Thinking Level** | ❌ | ❌ | ❌ | ❌ | ✅ Extended Thinking / control de reasoning |
| **Búsqueda Web/Maps** | Sistema de plugins | Búsqueda web (RAG) | Sistema de plugins | ❌ | ✅ Integrado |
| **Docker Self-Hosted** | ✅ | ✅ | ✅ | ✅ | ✅ |
| **GitHub Stars (feb 2026)** | ~50k | ~60k | ~20k | ~28k | Nuevo (lanzamiento open source) |
| **Compatibilidad Comité Empresa** | ⚠️ Limitada (sin auditoría, sin RBAC) | ⚠️ RBAC básico | ⚠️ RBAC básico | ❌ Sin governance | ✅ Audit Trail + RBAC + PII + Entra ID |

### LobeChat

LobeChat es un interfaz de chat visualmente atractivo con arquitectura de plugins. Su fortaleza está en el ecosistema de plugins y la variedad de APIs en nube. Para enterprise, carece de RBAC robusto, Audit Trail exportable e integración nativa de agentes. Adecuado como prototipo rápido o para equipos pequeños; demasiado limitado para un despliegue organizativo.

### OpenWebUI

OpenWebUI es el estándar de facto para configuraciones self-hosted basadas en Ollama. La integración con modelos ejecutados localmente es excelente. SSO y logging básico están disponibles. Lo que falta: compartición de asistentes, integración de agentes enterprise y gestión centralizada para cientos de usuarios.

### LibreChat

LibreChat es un clon open source del interfaz de ChatGPT con soporte multi-modelo. SSO y RBAC básico están implementados. Para empresas que quieren replicar internamente una experiencia tipo ChatGPT, LibreChat es un punto de partida sólido. Los límites están en la integración de agentes y la compartición de asistentes.

## very-ai - portal enterprise con protección PII y governance

very-ai es un portal enterprise AI basado en chatbot-ui (MIT) que añade 16 funciones enterprise inexistentes en los otros cuatro portales. Es desarrollado por Gosign GmbH y está disponible bajo Apache 2.0 en GitHub.

**Origen y diferenciación:**
chatbot-ui ofrece un sólido interfaz de chat pero carece de integración SSO, Audit Trail y protección PII. very-ai aborda exactamente eso: la base de código se ha ampliado con funciones enterprise necesarias para el uso productivo en entornos regulados. La atribución al proyecto original está documentada en el archivo NOTICES.

**Detección y re-anonimización de PII:**
El diferenciador central. very-ai detecta datos personales (nombres, correos electrónicos, números de teléfono, IBANs) en los prompts del usuario, los sustituye por marcadores ([PERSON_1], [EMAIL_1]), envía el texto anonimizado al modelo de lenguaje y reinserta los datos originales en la respuesta. El usuario ve los nombres reales; el modelo de lenguaje nunca los vio.

Este comportamiento PII es configurable por asistente y por modelo: el Asistente A puede permitir PII, el Asistente B anonimiza automáticamente. El Modelo X recibe datos anonimizados, el Modelo Y (un modelo alojado localmente) recibe datos en bruto.

**Azure Entra ID con sincronización de grupos:**
No solo autenticación, sino sincronización automática de grupos y roles de Entra ID. Empleados en el grupo Entra ID "RRHH" ven automáticamente los asistentes de RRHH. Empleados en "Finanzas" ven asistentes de Finanzas. Sin asignación manual de permisos en el portal. Cuando cambia la pertenencia a un grupo en Entra ID, el acceso en el portal cambia en el siguiente inicio de sesión.

**Asistentes de grupo:**
Los administradores crean asistentes y los asignan a grupos de Entra ID. Estos asistentes solo son visibles y utilizables por miembros del grupo correspondiente. Esto permite herramientas de IA departamentales sin un sistema de gestión de permisos separado.

**Audit Trail y estadísticas RGPD:**
Cada interacción se registra: usuario, modelo, asistente, prompt, respuesta, marca de tiempo, consumo de tokens, modo PII. El Audit Trail es exportable (CSV, JSON) y filtrable por periodo y usuario. Las estadísticas de uso están anonimizadas conforme al RGPD - muestran uso de modelos y asistentes sin datos identificativos de usuario.

**Integración de workflows Trigger.dev:**
Los usuarios pueden lanzar workflows Trigger.dev desde el chat. Esto conecta el portal AI con la capa de automatización.

**Limitaciones (honestamente):**
very-ai es un proyecto open source nuevo. La comunidad es pequeña comparada con LobeChat (50k estrellas) u OpenWebUI (60k estrellas). Los ecosistemas de plugins de los portales establecidos son más extensos. Quien busque un portal con máximo soporte comunitario y variedad de plugins está mejor servido con LobeChat u OpenWebUI. Quien necesite protección PII, sincronización de grupos Entra ID y logging compatible con el Comité de Empresa, actualmente solo encontrará esta combinación en very-ai.

Demo en vivo: [veryai.de](https://www.veryai.de/)

### ¿Qué portal para qué uso?

**Máxima variedad de modelos y ecosistema de plugins:** LobeChat - el mayor sistema de plugins, la comunidad más activa, amplio soporte de modelos. Ideal para equipos que priorizan flexibilidad e innovación rápida.

**Inicio más fácil con Ollama:** OpenWebUI - integración nativa de Ollama, instalación rápida, interfaz intuitivo. Ideal para hosting local de LLM y equipos que comienzan con modelos open source.

**Máxima configurabilidad:** LibreChat - el control más fino sobre endpoints y parámetros de modelos. Ideal para equipos técnicos que operan múltiples proveedores con distintas configuraciones.

**Enterprise governance con protección PII:** very-ai - la única opción con anonimización PII nativa, sincronización de grupos Entra ID y Audit Trail completo. Ideal para entornos regulados donde Comité de Empresa, protección de datos y compliance codeciden.

**Proyecto de evaluación y desarrollo:** chatbot-ui - base de código limpia, buen punto de partida para desarrollos propios. Nota: chatbot-ui no tiene desarrollo enterprise activo; very-ai es la evolución enterprise de esta base de código.

*La mayoría de las empresas evalúan 2-3 portales en paralelo con contenedores Docker - es factible en una tarde. Lo decisivo no es el interfaz, sino la capacidad de governance: SSO, Audit Trail, protección PII y compatibilidad con el Comité de Empresa determinan qué portal pasa a producción.*

## Por qué "solo un chat" no basta

La diferencia entre un interfaz de chat y un portal enterprise AI se hace evidente en la operación. Una comparación:

| Aspecto | Interfaz de chat | Portal enterprise AI |
|---|---|---|
| Uso | Pregunta-respuesta individual | Herramienta organizativa |
| Conocimiento | Cada usuario empieza de cero | Los asistentes agrupan conocimiento especializado |
| Control | El usuario decide qué introduce | Routing y RBAC gestionan el flujo de datos |
| Trazabilidad | Ninguna o limitada | Audit Trail completo |
| Integración | Standalone | Conectado a SSO, agentes, sistemas documentales |
| Escalabilidad | Por usuario | Por organización |
| Riesgo Shadow AI | Alto (oferta interna insuficiente) | Bajo (oferta interna superior) |

La conclusión central: Shadow AI no surge porque los empleados actúen con mala intención. Surge porque la oferta interna es peor que la alternativa pública. Cuando el portal interno es tan intuitivo como ChatGPT pero además ofrece asistentes especializados, acceso a documentos corporativos y workflows de agentes, no hay razón para recurrir a servicios externos.

## Práctica: una empresa mediana con 2.000 empleados

Un ejemplo concreto muestra el impacto. Una empresa manufacturera con 2.000 empleados tenía la siguiente situación de partida:

**Antes del portal:** Una encuesta interna reveló que 340 empleados usaban regularmente servicios de IA públicos para tareas laborales. De ellos, 180 con cuentas gratuitas (sin encargo de tratamiento de datos), 120 con cuentas Pro personales (datos corporativos en cuentas privadas) y 40 con cuentas proporcionadas por la empresa (pero sin Audit Trail ni control de acceso). IT no tenía visibilidad sobre qué datos fluían a qué sistemas.

**Despliegue del portal enterprise AI:** En cuatro semanas se desplegó very-ai - conectado a Azure AD para SSO, con tres asistentes iniciales (departamento jurídico, RRHH, compras) y un endpoint gpt-oss-120b para datos confidenciales.

**Tras 90 días:**

- 15 asistentes especializados creados por departamentos
- 1.200 usuarios activos al mes (de 2.000 empleados)
- Uso de Shadow AI reducido un 85% (encuesta de seguimiento)
- Audit Trail completo: 47.000 interacciones registradas
- Identificación de tres procesos para los que workflows de agentes dedicados tenían sentido
- Coste total (portal + hosting + APIs en nube): aprox. 4.800 EUR al mes

El factor decisivo no fue la tecnología, sino la adopción. El portal fue aceptado porque era mejor que la alternativa, no porque fuera obligatorio.

## Los cinco factores de éxito en el despliegue

De la práctica se derivan cinco factores que determinan el éxito o fracaso de un portal enterprise AI:

**1. La primera impresión cuenta.** Si el portal interno es más lento, más incómodo o menos capaz que ChatGPT, los empleados no volverán a usarlo tras el primer intento. La calidad de respuesta debe igualar a los servicios públicos desde el primer día.

**2. Asistentes en vez de prompts.** La mayoría de los empleados no son ingenieros de prompts. Quieren usar una herramienta, no configurarla. Asistentes especializados preparados por compañeros del área bajan significativamente la barrera de entrada.

**3. Valor añadido visible.** El portal debe ofrecer algo que los servicios públicos no pueden: acceso a documentos internos (vía RAG), asistentes especializados para tareas específicas de la empresa, integración en workflows existentes.

**4. Propiedad de IT, no control de IT.** IT opera el portal y establece las reglas de governance. Pero los departamentos crean sus propios asistentes. Esta división - infraestructura centralizada, contenidos descentralizados - ha demostrado ser el modelo más exitoso.

**5. Medir y comunicar.** Cifras de uso, tiempo ahorrado, Shadow AI reducido - estas métricas deben recogerse y comunicarse a la dirección. Sin resultados medibles, falta la base para la siguiente fase de expansión.

## Siguiente paso: del portal al agente

El portal enterprise AI es el fundamento. Proporciona a los empleados acceso a IA, controlado y registrado. El siguiente paso es integrar agentes - workflows especializados que van más allá de interacciones pregunta-respuesta.

---

Lectura adicional: [Infraestructura AI](/es/servicios/infraestructura/) | [Decision Layer y Shadow AI](/es/revista/decision-layer-shadow-ai/)

---

very-ai es el portal enterprise AI open source de Gosign. [Más información](/es/servicios/infraestructura/) - o hable directamente con nosotros sobre qué configuración se adapta a su organización.

<a href="/es/contacto/" target="_blank" rel="noopener noreferrer">Reservar una reunion</a> - Le mostramos very-ai en una demo en directo y comentamos su plan de despliegue.

--- EU AI Act 2026: Qué aplica ya, qué viene, qué debe hacer ---
> EU AI Act 2026: prohibiciones activas, AI Literacy obligatoria, deadline High-Risk agosto 2026. Calendario, obligaciones y recomendaciones.

El EU AI Act está en vigor. Dos plazos ya han vencido, el deadline crítico de High-Risk llega en seis meses. Estado actual, obligaciones y lo que las empresas deben hacer ahora.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">De un vistazo - EU AI Act 2026: estado para empresas</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Las prácticas de IA prohibidas (Social Scoring, manipulación, reconocimiento de emociones en el trabajo) y la obligación de AI Literacy son jurídicamente vinculantes desde febrero de 2025.</li>
<li>Las obligaciones de transparencia y documentación GPAI para operadores de modelos de IA de propósito general están vigentes desde agosto de 2025.</li>
<li>El plazo crítico: todos los sistemas de IA de alto riesgo (incluida casi toda la IA de RRHH) deben ser plenamente conformes antes del 2 de agosto de 2026. Sanciones: hasta 15 millones de euros o el 3% de la facturación global.</li>
<li>El paquete Digital Omnibus aplazaría el deadline de High-Risk a diciembre de 2027. El 7 de mayo de 2026, el Consejo y el Parlamento alcanzaron un acuerdo político provisional en ese sentido - pero la adopción formal y la publicación en el Diario Oficial siguen pendientes (previstas antes del 2 de agosto de 2026). Hasta entonces, el plazo vigente es agosto de 2026: planifique con esa fecha y aproveche el margen para prepararse.</li>
<li>Primer paso para toda empresa: completar un inventario de sistemas de IA que cubra todos los sistemas oficiales y Shadow AI en cuatro a ocho semanas.</li>
</ul>
</div>

Según Gartner (2025), menos del 10% de las organizaciones sujetas al EU AI Act han completado su inventario de sistemas de IA, el paso fundacional para el cumplimiento. La Comisión Europea estima que más de 300.000 empresas en la UE despliegan sistemas de IA que pueden entrar en el ámbito regulatorio.

<table>
<thead>
<tr><th>Hito</th><th>Fecha</th><th>Estado</th><th>Obligaciones principales</th></tr>
</thead>
<tbody>
<tr><td>Entrada en vigor</td><td>Agosto 2024</td><td>Activo</td><td>Marco establecido</td></tr>
<tr><td>Prácticas prohibidas + AI Literacy</td><td>Febrero 2025</td><td>Activo</td><td>Prohibición Social Scoring, manipulación; obligación formativa</td></tr>
<tr><td>Obligaciones GPAI</td><td>Agosto 2025</td><td>Activo</td><td>Transparencia, etiquetado, inventario de governance</td></tr>
<tr><td>Sistemas High-Risk</td><td>Agosto 2026</td><td>En 6 meses</td><td>Conformidad plena: gestión de riesgos, gobernanza de datos, Human Oversight</td></tr>
<tr><td>Disposiciones restantes</td><td>Agosto 2027</td><td>2027</td><td>Normas sectoriales, categorías restantes</td></tr>
</tbody>
</table>

## La primera ley integral de IA del mundo

El EU AI Act está en vigor desde agosto de 2024. Es la primera legislación integral del mundo para regular la inteligencia artificial y aplica a toda empresa que desarrolle, despliegue o proporcione sistemas de IA. En febrero de 2026, nos encontramos en plena fase de implementación: dos plazos ya han vencido, el siguiente llega en seis meses. Quien no se ha preparado tiene un problema. Quien se prepara ahora, aún tiene tiempo.

Para las empresas españolas, esto implica un doble marco normativo: el EU AI Act se superpone con la legislación laboral nacional, en particular el Estatuto de los Trabajadores y las competencias del Comité de Empresa. Este artículo ofrece una visión clara del estado actual: qué aplica ya, qué viene y cuándo, qué obligaciones afectan a su empresa y qué debería hacer en los próximos 90 días.

## Calendario: Cinco hitos

La implementación escalonada del EU AI Act se extiende a lo largo de tres años. Cada hito activa obligaciones diferentes.

```
Agosto 2024          Febrero 2025         Agosto 2025         Agosto 2026          Agosto 2027
|                    |                    |                   |                    |
v                    v                    v                   v                    v
Entrada en vigor    Practicas IA         Obligaciones        Sistemas High-Risk   Restantes
prohibidas +         GPAI en vigor       deben ser            disposiciones
AI Literacy                              conformes
ACTIVAS              ACTIVAS             EN 6 MESES           2027
```

Para las empresas, esto significa: dos etapas ya son jurídicamente vinculantes. La tercera, y para muchas empresas la más crítica, entra en vigor en seis meses. La preparación requiere típicamente de cuatro a seis meses. El tiempo apremia.

## Qué aplica ya

### Prácticas de IA prohibidas (desde febrero 2025)

Desde el 2 de febrero de 2025, determinadas aplicaciones de IA están completamente prohibidas en la UE. Esto cubre:

- **Social Scoring:** Sistemas de IA que evalúan personas en base a su comportamiento social y derivan desventajas en contextos no relacionados.
- **IA manipulativa:** Sistemas que manipulan el comportamiento humano mediante técnicas subliminales, como dark patterns que fuerzan decisiones de compra o consentimientos.
- **Biometría en tiempo real en espacios públicos:** La identificación biométrica en tiempo real está fundamentalmente prohibida. Existen excepciones limitadas para fuerzas de seguridad en casos de delitos graves, antiterrorismo y búsqueda de personas desaparecidas, siempre con autorización judicial.
- **Reconocimiento de emociones en el lugar de trabajo e instituciones educativas:** Los sistemas de IA que detectan emociones de trabajadores o alumnos son inadmisibles.
- **Predictive Policing basado en características individuales:** Evaluaciones de riesgo de criminalidad basadas exclusivamente en atributos personales.

**Sanciones:** Las infracciones de las prohibiciones se sancionan con multas de hasta 35 millones de euros o el 7 por ciento de la facturación anual global, lo que sea superior.

Para la mayoría de empresas españolas, estas prohibiciones no requieren acciones directas inmediatas, ya que las aplicaciones descritas raramente se dan en el contexto empresarial. Pero la verificación es obligatoria: asegúrese de que ninguno de sus sistemas de IA entre en estas categorías.

### AI Literacy (desde febrero 2025)

En paralelo a las prohibiciones, desde febrero de 2025 rige la obligación de AI Literacy según el Artículo 4: todas las personas que operen, desplieguen o utilicen sistemas de IA deben poseer un nivel suficiente de competencia en IA. La competencia debe ser adecuada al contexto respectivo: un desarrollador necesita un conocimiento más profundo que un usuario final que utiliza un chatbot.

Qué significa en la práctica:

- **Obligación de formación:** Las empresas deben poder demostrar que sus empleados han sido formados.
- **Obligación de documentación:** Contenidos formativos, listas de participantes e intervalos de actualización deben estar documentados.
- **Adecuación al contexto:** La formación debe corresponder al rol. Un e-learning genérico no basta para los responsables que seleccionan y responden de los sistemas de IA.

La obligación de AI Literacy se subestima con frecuencia porque no impone requisitos técnicos elevados. Pero ya es exigible. Y aplica a toda empresa que utilice IA, independientemente de la clase de riesgo del sistema.

### Obligaciones GPAI (desde agosto 2025)

Desde agosto de 2025, están en vigor las obligaciones de transparencia y documentación para modelos de IA de Propósito General (GPAI). Afectan primariamente a los proveedores de modelos de lenguaje, no a las empresas que los utilizan. Pero como deployer, como empresa que utiliza un modelo GPAI en sus propias aplicaciones, tiene obligaciones:

- **Avisos de uso:** Si su aplicación genera contenido que podría confundirse con contenido creado por humanos, debe señalarlo.
- **Transparencia hacia los usuarios:** Las personas que interactúan con un sistema de IA deben ser informadas.
- **Infraestructura de governance:** Debe poder documentar qué modelos GPAI utiliza, en qué contexto y con qué medidas de protección.

Las obligaciones GPAI requieren un inventario limpio: ¿Qué modelos de IA utiliza? ¿De qué proveedor? ¿En qué aplicación? ¿Con qué clasificación de riesgo? Esta información constituye la base para el cumplimiento High-Risk que entra en vigor en seis meses.

## Qué llega en seis meses: Sistemas High-Risk (agosto 2026)

El deadline High-Risk del 2 de agosto de 2026 es el plazo más crítico del EU AI Act para la mayoría de empresas. A partir de esa fecha, todos los sistemas de IA que entren en el Anexo III deben ser plenamente conformes. Los requisitos son extensos.

### ¿Qué sistemas entran en High Risk?

El Anexo III del EU AI Act define ocho áreas en las que los sistemas de IA se clasifican como de alto riesgo. Las más relevantes para las empresas:

- **Empleo, gestión de personal y acceso al autoempleo:** Sistemas de IA para ofertas de empleo, selección de candidatos, evaluación del rendimiento, decisiones de promoción y despidos.
- **Solvencia y seguros:** Evaluación automatizada de solvencia, scoring de riesgo.
- **Identificación biométrica:** Reconocimiento facial, identificación de voz, también en espacios no públicos.
- **Infraestructura crítica:** Sistemas de IA en energía, agua, transporte, telecomunicaciones.
- **Educación y formación profesional:** Evaluación automatizada de exámenes, control de acceso a instituciones educativas.

### Requisitos para sistemas High-Risk

Si alguno de sus sistemas de IA está clasificado como High Risk, debe cumplir los siguientes requisitos antes de agosto de 2026:

1. **Sistema de gestión de riesgos:** Un sistema documentado para identificar, analizar y mitigar riesgos a lo largo del ciclo de vida completo del sistema de IA.
2. **Governance de datos:** Requisitos sobre calidad, representatividad y exactitud de los datos de entrenamiento. Al utilizar modelos preentrenados: documentación de la procedencia de datos y el ajuste fino.
3. **Documentación técnica:** Documentación exhaustiva del sistema antes de su puesta en marcha: arquitectura, procedimientos de entrenamiento, métricas de rendimiento, procedimientos de prueba, limitaciones.
4. **Obligaciones de registro:** Registro automático de todos los eventos relevantes (logging) para garantizar la trazabilidad de las decisiones.
5. **Transparencia:** Instrucciones de uso para deployers que permitan un uso adecuado.
6. **Supervisión humana (Human Oversight):** Medidas técnicas que permitan una supervisión efectiva por personas. El [Decision Layer](/es/decision-layer/) es una arquitectura que implementa técnicamente este requisito.
7. **Exactitud, robustez, ciberseguridad:** El sistema debe ofrecer de forma fiable el rendimiento declarado y estar protegido contra manipulación.
8. **Evaluación de conformidad:** Para determinadas categorías se requiere una evaluación por un organismo notificado (Conformity Assessment Body). Para otras basta una autoevaluación.

**Sanciones:** Las infracciones de las obligaciones High-Risk se sancionan con multas de hasta 15 millones de euros o el 3 por ciento de la facturación anual global.

## Especial relevancia para RRHH

El área de Recursos Humanos es el departamento donde las aplicaciones de IA entran con mayor frecuencia en la categoría High-Risk. Esto se debe al Anexo III, punto 4 - Empleo y gestión de personal. La clasificación cubre:

**Screening automatizado de candidaturas: High Risk.** Cualquier sistema de IA que preseleccione, evalúe o filtre candidaturas entra en la categoría High-Risk. Independientemente de si la decisión final la toma una persona. Ya la preselección está regulada.

**Evaluaciones de rendimiento asistidas por IA: High Risk.** Cuando sistemas de IA analizan datos de rendimiento y derivan evaluaciones o preparan evaluaciones, es High Risk. Esto aplica también a sistemas que solo emiten recomendaciones.

**Predictive Attrition: High Risk.** Sistemas de IA que predicen qué empleados probablemente abandonarán la empresa procesan datos personales para derivar decisiones de empleo. Es High Risk.

**Optimización automática de turnos: potencialmente High Risk.** Si un sistema de IA crea cuadrantes de turnos procesando preferencias individuales, datos de rendimiento o información sanitaria, puede entrar en High Risk. La clasificación depende del alcance concreto de los datos.

Para los departamentos de RRHH, esto significa: inventarie todos los sistemas de IA utilizados en contextos de empleo. Revise la clasificación. Inicie la preparación de compliance: los seis meses hasta agosto de 2026 son ajustados para alcanzar plena conformidad High-Risk. En España, además, el Comité de Empresa tiene derecho de información y consulta sobre la implantación de estos sistemas según el Estatuto de los Trabajadores. Más información sobre la interacción entre IA y RRHH en [HR & AI Agents](/es/hr-ai-agents/).

## Digital Omnibus: El aplazamiento se acerca

La Comisión Europea propuso a finales de 2025 un paquete Digital Omnibus que, entre otras cosas, introduce un aplazamiento condicional de los plazos High-Risk del EU AI Act. El mecanismo no es un aplazamiento automático, sino escalonado: la publicación de normas armonizadas activa un período transitorio de 6 meses para sistemas del Anexo III y de 12 meses para sistemas del Anexo I. Si las normas armonizadas no se publican a tiempo, se aplica una fecha tope (backstop) del 2 de diciembre de 2027. El paquete también aborda una simplificación de las obligaciones de reporte y una elevación de los umbrales para pymes.

**Estado a junio de 2026:** El procedimiento legislativo ha avanzado con rapidez. El 7 de mayo de 2026, el Consejo y el Parlamento alcanzaron un acuerdo político provisional sobre el paquete, que fija el aplazamiento del plazo de alto riesgo al 2 de diciembre de 2027. Sin embargo, el aplazamiento aún no está en vigor: la adopción formal y la publicación en el Diario Oficial de la UE siguen pendientes, previstas para antes del 2 de agosto de 2026. Mientras tanto, la fecha legalmente vigente sigue siendo agosto de 2026.

**La recomendación:** La clasificación de alto riesgo se mantiene sin cambios. Conforme a la legislación vigente, el plazo es agosto de 2026; el aplazamiento a diciembre de 2027 está acordado de forma provisional, pero la adopción formal sigue pendiente. Planifique con agosto de 2026 y, si el Digital Omnibus se publica como está previsto, dispondrá de margen adicional. En cualquier caso, conviene usar el tiempo para prepararse: las estructuras de gobernanza que exige el alto riesgo no se improvisan, llegue el plazo en agosto de 2026 o en diciembre de 2027.

## Recomendación práctica: Inicie un inventario de sistemas de IA

Independientemente de si sus sistemas de IA entran en High Risk o no: el primer paso es siempre el mismo. Necesita un inventario completo de todos los sistemas de IA en su empresa.

### Qué debe registrarse

Para cada sistema de IA, documente:

- **Designación y descripción del sistema:** ¿Qué hace el sistema? ¿Qué proceso soporta?
- **Proveedor y modelo:** ¿Qué modelo de IA se utiliza? ¿De qué proveedor? ¿Cloud API o self-hosted?
- **Rol de su empresa:** ¿Es usted provider (proveedor), deployer (operador) o ambos?
- **Clasificación de riesgo:** ¿Entra el sistema en alguna de las categorías del Anexo III (High Risk)? ¿En las prohibiciones del Artículo 5? ¿O se trata de un sistema de riesgo limitado?
- **Personas afectadas:** ¿A qué personas afectan las decisiones o resultados del sistema?
- **Procesamiento de datos:** ¿Qué datos procesa el sistema? ¿Datos personales? ¿Secretos comerciales?
- **Medidas de protección:** ¿Qué medidas técnicas y organizativas están implementadas? ¿Human Oversight? ¿Audit Trail?

### Calendario

Un inventario de sistemas de IA para una empresa mediana es realizable en cuatro a ocho semanas. El esfuerzo depende del número de sistemas, del estado de la documentación y de la coordinación interna. Comience con los sistemas evidentes, las herramientas de IA oficialmente adquiridas, y luego extienda a [Shadow AI](/es/revista/decision-layer-shadow-ai/): sistemas de IA que los empleados utilizan por su cuenta sin que el departamento de IT lo sepa.

El inventario no es una tarea puntual. Debe actualizarse de forma continua, porque se añaden nuevos sistemas, los existentes se modifican y la valoración regulatoria evoluciona. La [infraestructura de governance](/es/governance/) debe estar diseñada para que el inventario sea un documento vivo.

## Resumen: Qué debe hacer ahora

1. **Revise las prohibiciones.** Asegúrese de que ninguno de sus sistemas de IA entra en las prácticas prohibidas desde febrero de 2025.
2. **Cumpla la obligación de AI Literacy.** Documente formaciones para todos los usuarios de IA en su empresa. La obligación ya está en vigor.
3. **Cree un inventario de sistemas de IA.** Registre todos los sistemas de IA, sus proveedores, contexto de uso y clasificación de riesgo. Plazo: cuatro a ocho semanas.
4. **Identifique los sistemas High-Risk.** Revise especialmente el área de RRHH, decisiones crediticias y procesos automatizados con impacto directo sobre personas.
5. **Inicie el cumplimiento High-Risk.** Para sistemas bajo el Anexo III: establezca sistema de gestión de riesgos, governance de datos, documentación técnica y Human Oversight. Deadline: agosto de 2026.
6. **Cuente con el plazo vigente, no solo con el aplazamiento.** El Consejo y el Parlamento alcanzaron un acuerdo político provisional el 7 de mayo de 2026 para aplazar el plazo de alto riesgo a diciembre de 2027, pero la adopción formal sigue pendiente. Mientras no se publique en el Diario Oficial, el plazo legalmente vigente es agosto de 2026: planifique con esa fecha y trate el margen adicional como un extra, no como un hecho consumado.

---

Gosign acompaña a las empresas en el cumplimiento del EU AI Act, desde el inventario de sistemas hasta la evaluación de conformidad. Si quiere saber dónde se encuentra su empresa, hable con nosotros.

<a href="/es/contacto/" target="_blank" rel="noopener noreferrer">Solicitar cita</a>. 30 minutos en los que evaluamos su estado de compliance.

--- El EU AI Act aplica en todo el mundo. ---
> El EU AI Act no es sobrerregulación europea. Simplemente pone por escrito lo que cada sistema legal ya exige: Explique su decisión.

*Somalia. Sudán del Sur. Yemen. Libia. Siria. - Son las únicas excepciones.*

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">De un vistazo - La accountability de la IA es universal</p>
<ul class="text-body text-gosign-text space-y-2">
<li>El EU AI Act no inventó las decisiones de IA explicables - fue el primero en codificar el principio específicamente para sistemas de IA. La obligación de explicar decisiones existe en prácticamente todos los sistemas legales del mundo.</li>
<li>RRHH es el área de mayor riesgo porque las decisiones de IA sobre personas crean la mayor superficie de ataque legal - desde el sesgo en el screening de CV hasta las evaluaciones de rendimiento automatizadas.</li>
<li>Un algoritmo sesgado escala la discriminación a 50.000 decisiones simultáneamente, frente a unas 50 al año de un directivo sesgado.</li>
<li>Toda empresa que use IA para decisiones sobre personas necesita dos capas: un Decision Layer (evidencia de cada decisión) y un Governance Layer (reglas del juego).</li>
<li>Shadow AI - empleados usando ChatGPT, Copilot y otras herramientas sin governance - es el riesgo más urgente y subestimado para la mayoría de las organizaciones.</li>
</ul>
</div>

Según la Comisión Europea (2024), los sistemas de IA clasificados como alto riesgo bajo el EU AI Act afectarán directamente las decisiones de empleo en más de 6.000 organizaciones en los Estados miembros de la UE. RRHH fue identificado como el área empresarial más frecuentemente afectada según el Anexo III.

## La pregunta de 3 millones de euros

Una empresa española utiliza una herramienta de IA para filtrar candidatos. 500 solicitudes entran, 20 salen. Uno de los 480 rechazados demanda. No invoca el EU AI Act. Invoca el Estatuto de los Trabajadores y la Ley 15/2022, de igualdad de trato y no discriminación - una ley que explícitamente prohíbe la discriminación algorítmica.

La pregunta del juez: "Explique cómo se tomó esta decisión."

Silencio.

No porque la empresa actuara de mala fe. Sino porque nadie en la empresa puede explicar cómo la herramienta de IA produjo esos 480 rechazos. RRHH compró la herramienta. IT la instaló. Y la lógica de decisión está dentro de una caja negra que nadie puede abrir.

Esto no es hipotético. Está sucediendo ahora. Y no solo en España.

## La accountability no es un invento europeo

La mayoría de los directivos han archivado mentalmente el EU AI Act como "regulación europea." Es un error caro. El EU AI Act no inventó el principio de decisiones explicables. Simplemente fue el primero en ponerlo por escrito específicamente para sistemas de IA.

El principio en sí es universal.

**España:** La Ley 15/2022 es una de las legislaciones más avanzadas del mundo en materia de no discriminación algorítmica. El artículo 23 prohíbe explícitamente la discriminación en el empleo por decisiones automatizadas. El Estatuto de los Trabajadores protege frente a decisiones arbitrarias. Y como miembro de la UE, el EU AI Act se aplica directamente.

**América Latina:** México tiene la Ley Federal del Trabajo que protege contra la discriminación laboral. Argentina, la Ley de Contrato de Trabajo. Colombia, el Código Sustantivo del Trabajo. Chile está desarrollando regulación específica de IA. Brasil tiene la LGPD Art. 20 con derecho explícito a explicación de decisiones automatizadas. Los tribunales laborales latinoamericanos son cada vez más activos en cuestionar decisiones automatizadas.

**Estados Unidos:** Title VII del Civil Rights Act prohíbe la discriminación en decisiones de empleo - desde 1964. La EEOC puede exigir en cualquier momento que una empresa explique por qué rechazó a un candidato. En Nueva York, Local Law 144 exige auditorías de sesgo obligatorias para herramientas de IA en reclutamiento desde 2023.

De los 193 estados miembros de la ONU, hay exactamente 5 donde una empresa no puede ser legalmente responsabilizada por una decisión de IA inexplicable. No porque esos países lo permitan - sino porque no tienen un sistema judicial funcional.

El EU AI Act no es sobrerregulación europea. Es la primera respuesta honesta a una pregunta universal.

<table class="w-full text-left text-sm">
<thead><tr class="border-b border-gosign-border">
<th class="py-2 pr-4 font-semibold">Región</th>
<th class="py-2 pr-4 font-semibold">Legislación clave</th>
<th class="py-2 pr-4 font-semibold">Explicabilidad exigida</th>
<th class="py-2 pr-4 font-semibold">Decisiones RRHH cubiertas</th>
</tr></thead>
<tbody>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">UE / España</td><td class="py-2 pr-4">EU AI Act, RGPD Art. 22, Ley 15/2022</td><td class="py-2 pr-4">Sí (vinculante)</td><td class="py-2 pr-4">Sí (Anexo III alto riesgo)</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">EE.UU.</td><td class="py-2 pr-4">Title VII, NYC Local Law 144</td><td class="py-2 pr-4">Sí (antidiscriminación)</td><td class="py-2 pr-4">Sí (decisiones de empleo)</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Brasil</td><td class="py-2 pr-4">LGPD Art. 20, CLT</td><td class="py-2 pr-4">Sí (derecho a explicación)</td><td class="py-2 pr-4">Sí (tribunales laborales activos)</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">China</td><td class="py-2 pr-4">Algorithmic Provisions 2022</td><td class="py-2 pr-4">Sí (transparencia exigida)</td><td class="py-2 pr-4">Sí (decisiones algorítmicas)</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">América Latina</td><td class="py-2 pr-4">Leyes laborales nacionales</td><td class="py-2 pr-4">Sí (protección laboral)</td><td class="py-2 pr-4">Sí (discriminación laboral)</td></tr>
</tbody>
</table>

## Por qué RRHH es el Ground Zero

<img src="/images/magazin/risk-pyramid-es.svg" alt="Pirámide de riesgo: las decisiones de RRHH sobre personas conllevan el mayor riesgo" width="800" height="480" loading="lazy" />

Las decisiones erróneas de IA sobre productos son molestas. Las decisiones erróneas de IA sobre procesos son costosas. Las decisiones erróneas de IA sobre personas son existenciales - para los afectados y para la empresa.

RRHH es el área donde las decisiones de IA crean la mayor superficie de ataque. Tres escenarios que ya están ocurriendo:

Un screening de CV basado en IA filtra sistemáticamente candidatos con huecos en el currículum. Afectados: padres, personas con enfermedades crónicas, personas que cambian de carrera. En la legislación española, esto constituye discriminación indirecta bajo la Ley 15/2022.

Un análisis de sentimiento en entrevistas por vídeo malinterpreta diferencias culturales en expresión facial como señales negativas. Afectados: candidatos de diferentes contextos culturales. Esto es potencialmente discriminación étnica.

Una herramienta de predicción de rendimiento entrenada con datos históricos de ascensos reproduce los patrones del pasado. Si en el pasado los hombres fueron ascendidos más frecuentemente, la herramienta replica ese patrón. Eso es discriminación de género sistemática - automatizada y escalada.

Cada uno de estos escenarios es ya accionable en la mayoría de los países. No a partir del plazo de alto riesgo del EU AI Act - agosto de 2026 según la legislación vigente, con un aplazamiento a diciembre de 2027 acordado provisionalmente por el Digital Omnibus (mayo de 2026, adopción formal pendiente). Ahora.

Y el problema real de la discriminación por IA comparada con la discriminación humana: un directivo sesgado toma quizás 50 decisiones cuestionables al año. Un algoritmo sesgado toma 50.000. Simultáneamente. Consistentemente. De forma demostrable.

## Las dos capas que toda empresa necesita

<img src="/images/magazin/decision-governance-layers-es.svg" alt="Governance Layer y Decision Layer: arquitectura de dos capas" width="800" height="440" loading="lazy" />

La solución no es compleja - pero requiere pensamiento arquitectónico. Toda empresa que use IA para decisiones sobre personas necesita dos capas.

**El [Decision Layer](/es/revista/decision-layer-shadow-ai/) - la evidencia.** El Decision Layer descompone cada proceso en pasos de decisión individuales y define para cada paso: humano, conjunto de reglas o IA. Cada decisión asistida por IA responde: ¿Qué datos entraron? ¿Qué modelo decidió, en qué versión? ¿Cuál fue el resultado y con qué nivel de confianza? ¿Un humano revisó el resultado antes de que surtiera efecto? ¿Es la decisión reproducible?

Esto no es un lujo técnico. Es el equivalente digital de la contabilidad. Y así como ninguna empresa puede operar sin contabilidad, pronto ninguna empresa podrá operar sin Decision Layer.

**El Governance Layer - las reglas del juego.** Antes de que se tome la primera decisión de IA: ¿Qué aplicaciones de IA existen siquiera en la empresa? La mayoría de las empresas no lo sabe. ¿Qué tan riesgosa es cada aplicación - no por categorías regulatorias, sino por impacto real en personas? ¿Quién es responsable? Spoiler: "IT" no es una respuesta. ¿Cuándo debe intervenir un humano? ¿Y cómo se audita todo esto?

En España, los comités de empresa y los representantes sindicales tienen un papel relevante en la implantación de sistemas de IA que afectan decisiones laborales. El Real Decreto-ley 9/2021 ya establece derechos de información sobre el uso de algoritmos en el ámbito laboral.

## El elefante en la habitación: Shadow AI

<img src="/images/magazin/shadow-ai-eisberg-es.svg" alt="Shadow AI iceberg: sobre la línea de agua herramientas oficiales, bajo la línea uso sin control ni auditoría" width="800" height="600" loading="lazy" />

Y ahora el punto más incómodo. La mayoría de las empresas debaten sobre governance para las herramientas de IA que han desplegado oficialmente. Mientras tanto, sus empleados ya están usando ChatGPT, Claude, Copilot y otras herramientas para preparar decisiones - sin que nadie lo sepa.

Los reclutadores usan ChatGPT para resumir candidaturas. Los jefes de equipo dejan que Copilot redacte recomendaciones de ascenso. L&D genera evaluaciones de desempeño con IA.

Todo esto está pasando. Ahora. Sin Decision Layer. Sin Governance Layer. Sin ninguna trazabilidad.

Y cuando alguien demande, la respuesta no será "la IA decidió" - será peor: "No sabíamos que la IA estaba decidiendo."

## La verdadera pregunta

La pregunta no es: "¿Cumplimos con el [EU AI Act](/es/revista/eu-ai-act-hr-alto-riesgo/)?"

La pregunta es: ¿Podemos explicar mañana - en cada país donde operamos - por qué decidimos hoy lo que decidimos?

Quien pueda responder que sí, es automáticamente compliant. Con el EU AI Act. Con el RGPD. Con el Estatuto de los Trabajadores. Con la Ley 15/2022. Con todo lo que venga.

Quien no pueda, no tiene un problema regulatorio. Tiene un problema de governance.

--- EU AI Act: IA en RRHH es alto riesgo desde 2026 ---
> La IA en RRHH es alto riesgo segun el EU AI Act. Que significa, que obligaciones se aplican y como el Decision Layer cumple los requisitos.

El EU AI Act clasifica prácticamente todos los sistemas de IA utilizados en procesos de RRHH como alto riesgo. Esa clasificación se mantiene; conforme a la legislación vigente, estos sistemas deben cumplir requisitos estrictos de gestión de riesgos, transparencia y supervisión humana desde agosto de 2026, con un aplazamiento a diciembre de 2027 acordado provisionalmente por el Digital Omnibus (mayo de 2026, adopción formal aún pendiente).

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">De un vistazo - La IA en RRHH es alto riesgo según el EU AI Act</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Los sistemas de IA para reclutamiento, evaluaciones de rendimiento, ascensos y despidos se clasifican como alto riesgo según el Anexo III, n.o 4 del EU AI Act.</li>
<li>Las prácticas de IA prohibidas (Social Scoring, manipulación) están vigentes desde el 2 de febrero de 2025. Las obligaciones completas de alto riesgo se aplican, conforme a la legislación vigente, desde agosto de 2026, con un aplazamiento a diciembre de 2027 acordado provisionalmente (Digital Omnibus, mayo de 2026, adopción formal pendiente).</li>
<li>Seis requisitos obligatorios: gestión de riesgos, gobernanza de datos, obligaciones de registro, transparencia, supervisión humana y precisión/robustez.</li>
<li>El Decision Layer mapea cada requisito arquitectónicamente: Confidence Routing para riesgos, conjuntos de reglas versionados para gobernanza de datos, Audit Trail para registros, Human-in-the-Loop para supervisión.</li>
<li>Sanciones de hasta 15 millones de euros o el 3% de la facturación anual global por infracciones de las obligaciones de alto riesgo (art. 99, apartado 4) - hasta 35 millones de euros o el 7% para prácticas de IA prohibidas (art. 5).</li>
</ul>
</div>

Según una encuesta de PwC (2024), solo el 24% de las empresas que utilizan IA en procesos de RRHH han comenzado la preparación formal para el cumplimiento del EU AI Act, pese al plazo de alto riesgo previsto para agosto de 2026 (con un aplazamiento a diciembre de 2027 acordado de forma provisional).

<table>
<thead>
<tr><th>Artículo EU AI Act</th><th>Requisito</th><th>Implementación en el Decision Layer</th></tr>
</thead>
<tbody>
<tr><td>Art. 9</td><td>Sistema de gestión de riesgos</td><td>Confidence Routing con umbrales configurables</td></tr>
<tr><td>Art. 10</td><td>Gobernanza de datos</td><td>Conjuntos de reglas versionados con fechas de vigencia</td></tr>
<tr><td>Art. 12</td><td>Obligaciones de registro</td><td>Audit Trail inmutable por decisión</td></tr>
<tr><td>Art. 13</td><td>Transparencia</td><td>Portal del Auditor con ruta de decisión completa</td></tr>
<tr><td>Art. 14</td><td>Supervisión humana</td><td>Human-in-the-Loop impuesto para tipos definidos</td></tr>
<tr><td>Art. 15</td><td>Precisión y robustez</td><td>Monitoreo de sesgo y diseño model-agnostic</td></tr>
<tr><td>Art. 86</td><td>Derecho a la explicación de la decisión individual</td><td>Acta de decisión por microdecisión con vía de impugnación</td></tr>
</tbody>
</table>

## La clasificacion: la IA en RRHH es alto riesgo

El EU AI Act clasifica como alto riesgo los sistemas de IA utilizados en empleo, gestion de trabajadores y acceso al trabajo por cuenta propia (Anexo III, n.o 4). Esto abarca concretamente:

Sistemas de IA para reclutamiento y seleccion de candidatos. Sistemas de IA que influyen en ascensos, despidos, asignacion de tareas o evaluacion del rendimiento. Sistemas de IA que afectan a las condiciones laborales, incluidos ajustes salariales, clasificaciones y planificacion de turnos.

En resumen: practicamente cualquier agente de IA que prepare, apoye o tome decisiones en procesos de RRHH cae bajo la categoria de alto riesgo.

## Los plazos

Desde el 2 de febrero de 2025 estan en vigor las prohibiciones de practicas de IA inaceptables, incluidos el social scoring y las tecnicas manipulativas. La clasificacion de alto riesgo se mantiene; conforme a la legislacion vigente, la totalidad de obligaciones para sistemas de IA de alto riesgo se aplica desde agosto de 2026, con un aplazamiento al 2 de diciembre de 2027 acordado provisionalmente por el Digital Omnibus (acuerdo politico del 7 de mayo de 2026, adopcion formal aun pendiente). Llegue el plazo en agosto de 2026 o en diciembre de 2027, conviene aprovechar el tiempo: las estructuras de gobernanza que exige el alto riesgo no se improvisan, y empezar ahora es lo que separa una transicion ordenada de una carrera contrarreloj.

## Que se exige concretamente y como lo cumple el Decision Layer

Los siguientes requisitos se aplican a todo operador de un sistema de IA de alto riesgo en el ambito de RRHH:

**Articulo 9 - Sistema de gestion de riesgos:**
El EU AI Act exige un sistema de gestion de riesgos continuo que identifique, evalqe y mitigue riesgos. En el Decision Layer, esto se implementa mediante Confidence Routing: cada decision del agente se evalqa automaticamente por confianza y categoria de riesgo. Alto riesgo o baja confianza conduce a la escalacion a una persona. Los umbrales son configurables y estan documentados.

**Articulo 10 - Gobernanza de datos:**
Los conjuntos de reglas versionados en el Decision Layer garantizan que la base de datos de cada decision sea trazable. Los convenios colectivos, los acuerdos de empresa y las reglas de compliance tienen versiones, fechas de vigencia y ambitos de aplicacion. En una auditoria se puede trazar que conjunto de reglas, en que version, estaba vigente en el momento de la decision.

**Articulo 12 - Obligaciones de registro:**
El Audit Trail en el Decision Layer genera un registro de datos completo e inmutable para cada decision: entrada, modelo, conjunto de reglas, confianza, decision de enrutamiento, resultado, marca temporal. Automaticamente, no compilado a posteriori.

**Articulo 13 - Transparencia:**
Cada decision del agente es trazable en el Portal del Auditor. Los comites de empresa, los Delegados de Proteccion de Datos (DPD) y los auditores pueden consultar la ruta de decision. Ninguna caja negra.

**Articulo 14 - Supervision humana:**
Human-in-the-Loop es un principio arquitectonico en el Decision Layer, no un ajuste opcional. Para tipos de decisiones definidos, potencial de discriminacion, materias sujetas a consulta del comite de empresa, umbrales de valor, la arquitectura impone la revision humana. Un agente no puede eludir esta revision.

**Articulo 15 - Precision, robustez y ciberseguridad:**
El monitoreo de sesgo comprueba sistematicamente la existencia de patrones discriminatorios. Los umbrales de confianza garantizan que el agente solo decide de forma autonoma con suficiente certeza. El diseno model-agnostic permite cambiar el modelo de lenguaje sin modificar la logica de gobernanza.

**Articulo 86 - Derecho a la explicacion:**
Mas alla de los seis deberes del responsable del despliegue, el art. 86 otorga a toda persona afectada un derecho a la explicación de la decisión individual - no del sistema en general, sino de ese caso concreto. Esta pregunta solo puede responderse mediante un acta de decisión por microdecisión: input, regla de negocio aplicada con su versión, confianza, resultado y vía de impugnación. El Decision Layer genera esa acta en el momento de la decisión y hace así cumplible el derecho del art. 86 caso por caso.

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">eBook gratuito: IA en RRHH</p>
<p class="text-body text-gosign-text mb-4">Checklist EU AI Act, framework de decisiones, perspectiva del comité de empresa y evaluación de preparación - el manual de gobernanza para responsables de RRHH.</p>
<a href="/es/ebook/ia-rrhh-manual-gobernanza/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Descargar gratis</a>
</div>

## Que significa esto para los departamentos de RRHH

Las empresas que hoy utilizan o planean utilizar IA en procesos de RRHH harían bien en construir sus estructuras de gobernanza con vistas al plazo de agosto de 2026 (aplazamiento a diciembre de 2027 acordado de forma provisional). Esto significa concretamente:

Logica de decision documentada para cada proceso de RRHH asistido por IA. Mecanismos Human-in-the-Loop tecnicamente impuestos para decisiones con impacto en el personal. Audit Trails auditables que hagan trazable como se tomo cada decision. Monitoreo de sesgo que detecte e informe de patrones discriminatorios.

En Espana, el Estatuto de los Trabajadores (art. 64) otorga a los comites de empresa derechos de informacion y consulta sobre la introduccion de nuevas tecnologias en el lugar de trabajo. Esto se suma a los requisitos del EU AI Act y exige una coordinacion entre ambos marcos normativos: la regulacion europea y la legislacion laboral nacional.

El Decision Layer aborda ambos bloques de requisitos, EU AI Act y derechos de informacion y consulta espanoles, en una sola arquitectura.

-> [Decision Layer en detalle](/es/revista/decision-layer-explicado/)

-> [Acta de decisión: por qué toda decisión de IA debe ser impugnable](/es/revista/acta-de-decision-decisiones-ia-impugnables/)

-> [Informacion, Consulta y Comite de Empresa](/es/governance/co-determination/)

-> [HR Agent](/es/hr-ai-agents/)

<a href="/es/contacto/" target="_blank" rel="noopener noreferrer">Agendar reunion</a> - Le mostramos cuales de sus procesos de RRHH caen bajo la categoria de alto riesgo y como el Decision Layer cumple los requisitos.

--- EU AI Act y RRHH: lo que ahora es obligatorio ---
> El EU AI Act clasifica los procesos de RRHH como alto riesgo. Bias Monitoring, Human Oversight y transparencia son obligatorios ahora.

El EU AI Act clasifica la IA utilizada en decisiones de personal como alto riesgo. Desde la clasificación de riesgos hasta el monitoreo de sesgo y la supervisión humana - ahora son requisitos legales, no funciones opcionales.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">De un vistazo - Obligaciones del EU AI Act para RRHH</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Todo sistema de IA que influya en decisiones de RRHH - reclutamiento, evaluación del rendimiento, retribución, ascensos - es alto riesgo según el Anexo III del EU AI Act.</li>
<li>Cuatro requisitos esenciales: clasificación de riesgo de cada sistema de IA, monitoreo de sesgo obligatorio, supervisión humana impuesta y transparencia completa con documentación.</li>
<li>Errores típicos: conformidad retroactiva en vez de Governance by Design, declarar herramientas de IA como "meramente de apoyo" e informar al comité de empresa demasiado tarde.</li>
<li>El enfoque correcto es Architecture-First: el Decision Layer descompone cada proceso de RRHH en pasos de decisión individuales con logging, versionado y Human-in-the-Loop desde el día uno.</li>
<li>Multas de hasta 35 millones de euros o el 7% de la facturación anual global. Obligaciones de alto riesgo vigentes desde agosto de 2026 según la legislación actual, con aplazamiento a diciembre de 2027 acordado provisionalmente (Digital Omnibus, mayo de 2026, adopción formal pendiente).</li>
</ul>
</div>

El Parlamento Europeo (2024) estima que RRHH y empleo representan la mayor categoría individual de aplicaciones de IA de alto riesgo bajo el EU AI Act, afectando a un estimado del 85% de las grandes empresas que utilizan IA en reclutamiento o gestión de personal.

<table>
<thead>
<tr><th>Proceso de RRHH</th><th>Clasificación EU AI Act</th><th>Requisito clave</th></tr>
</thead>
<tbody>
<tr><td>Screening de CV / Reclutamiento</td><td>Alto riesgo (Anexo III)</td><td>Monitoreo de sesgo, Audit Trail</td></tr>
<tr><td>Evaluación del rendimiento</td><td>Alto riesgo (Anexo III)</td><td>Supervisión humana, transparencia</td></tr>
<tr><td>Decisiones de ascenso</td><td>Alto riesgo (Anexo III)</td><td>Explicabilidad, Human-in-the-Loop</td></tr>
<tr><td>Planificación de turnos (con datos personales)</td><td>Potencialmente alto riesgo</td><td>Evaluación de riesgos, gobernanza de datos</td></tr>
<tr><td>Compliance Knowledge Agent</td><td>Riesgo limitado</td><td>Obligación de transparencia</td></tr>
</tbody>
</table>

## El EU AI Act y RRHH: por qué es relevante

El EU AI Act (Reglamento (UE) 2024/1689) está en vigor desde agosto de 2024. Regula los sistemas de IA según su nivel de riesgo. Para los departamentos de RRHH, la clasificación es clara: los sistemas de IA que se utilizan para decisiones sobre personas en el contexto laboral se clasifican como sistemas de alto riesgo (Anexo III, punto 4).

Esto no afecta solo al software de reclutamiento automatizado. Afecta a cualquier uso de IA que influya en decisiones de personal: cribado de candidaturas, evaluación del rendimiento, propuestas salariales, recomendaciones de ascenso, planificación de turnos con optimización por IA, generación automatizada de informes de evaluación.

La clasificación de alto riesgo se mantiene; conforme a la legislación vigente, las obligaciones para sistemas de alto riesgo se aplican desde [agosto de 2026](/es/revista/eu-ai-act-2026-empresas/), con un aplazamiento a diciembre de 2027 acordado provisionalmente por el Digital Omnibus (mayo de 2026, adopción formal aún pendiente). Esto da tiempo a las empresas para prepararse, pero las decisiones arquitectónicas deben tomarse ahora.

## Qué exige concretamente el EU AI Act

Para los sistemas de IA de alto riesgo en el ámbito de RRHH, el EU AI Act exige:

**Sistema de gestión de riesgos (Art. 9):** Una gestión de riesgos continua durante todo el ciclo de vida del sistema de IA. Identificación de riesgos, evaluación, medidas, revisión. No es una evaluación puntual, sino un proceso continuo.

**Calidad de los datos (Art. 10):** Los datos de entrenamiento, validación y prueba deben ser relevantes, representativos, correctos y completos. Para RRHH esto significa: si un agente se entrena con decisiones de personal históricas, estos datos deben verificarse respecto a sesgos. La discriminación histórica en los datos será reproducida por el sistema de IA.

**Documentación técnica (Art. 11):** Documentación completa del sistema de IA antes de su puesta en marcha. Propósito, funcionamiento, indicadores de rendimiento, limitaciones, riesgos. Esta documentación debe mantenerse actualizada.

**Conservación de registros (Art. 12):** Registro automático de todos los eventos durante toda la vida útil del sistema. En el contexto de RRHH: cada decisión, cada recomendación, cada escalación.

**Human Oversight (Art. 14):** La supervisión humana debe estar garantizada. La persona debe comprender las capacidades y limitaciones del sistema, poder interpretar los resultados y tener la posibilidad de intervenir o desactivar el sistema.

**Bias-Monitoring:** El EU AI Act exige que los sistemas de alto riesgo se supervisen respecto a sesgos. Para decisiones de RRHH esto significa: evaluación estadística de todas las decisiones del agente. ¿Se tratan sistemáticamente de forma diferente determinados colectivos?

**Transparencia (Art. 13):** Las personas afectadas deben ser informadas de que se utilizan sistemas de IA en las decisiones que les afectan.

## Qué significa esto para la arquitectura

Los requisitos del EU AI Act no son medidas organizativas. Son requisitos arquitectónicos. Un sistema de IA que deba cumplir estos requisitos a posteriori necesita una reconstrucción fundamental.

**Decision Layer:** El Decision Layer descompone cada proceso de RRHH en pasos de decisión individuales y define para cada paso: persona, conjunto de reglas o IA. La Rules Engine implementa los conjuntos de reglas versionados. El Confidence Routing garantiza la evaluación de riesgos. El mecanismo Human-in-the-Loop asegura la supervisión humana. El Audit Trail cumple la obligación de conservación de registros.

**Bias-Monitoring:** A través del Decision Layer, todas las decisiones del agente se evalúan estadísticamente. Las desviaciones de las distribuciones esperadas se detectan y escalan. No es un proceso de revisión manual, sino una supervisión automatizada.

**Portal del Auditor:** La documentación técnica y la evidencia están disponibles en todo momento en el Portal del Auditor. Los auditores, tanto internos como externos, ven el estado en vivo de todos los controles.

## Calendario: qué debe ocurrir ahora

**Inmediatamente:** Inventario de todos los sistemas de IA en el ámbito de RRHH. Incluyendo aquellos que no están etiquetados como "IA": algoritmos de scoring en software de reclutamiento, planificación de turnos basada en IA, generación automatizada de textos.

**Hasta Q3 2026:** Establecer el sistema de gestión de riesgos. Tomar decisiones arquitectónicas. Implementar la infraestructura de gobernanza.

**Desde agosto de 2026 (plazo vigente; aplazamiento a diciembre de 2027 acordado provisionalmente):** Los sistemas de alto riesgo deben cumplir plenamente los requisitos del EU AI Act.

En España, el Estatuto de los Trabajadores (Real Decreto Legislativo 2/2015) otorga al comité de empresa derechos de información y consulta sobre la implantación de nuevas tecnologías en el lugar de trabajo (art. 64 ET). Los AI Agents en procesos de RRHH están sujetos a estos derechos. Además, la AESIA (Agencia Española de Supervisión de Inteligencia Artificial) actuará como autoridad nacional competente para supervisar el cumplimiento del EU AI Act. La Ley 15/2022 para la igualdad de trato y la no discriminación refuerza las obligaciones de Bias-Monitoring en el contexto laboral. El Decision Layer aborda ambos bloques de requisitos (EU AI Act y legislación laboral española) en una sola arquitectura.

Las empresas que ahora introducen AI Agents para procesos de RRHH deben diseñar la arquitectura conforme al EU AI Act desde el principio. La conformidad a posteriori es técnicamente posible, pero significativamente más costosa.

Más sobre este tema: [EU AI Act Readiness](/es/governance/eu-ai-act/)

Más sobre RRHH: [Agentes de IA para RRHH](/es/hr-ai-agents/)

<a href="/es/contacto/" target="_blank" rel="noopener noreferrer">Agendar reunión</a>. Le mostramos cómo hacer que su IA de RRHH sea conforme al EU AI Act.

--- Hosting IA: EU SaaS, data center europeo o Self-Hosted? ---
> Tres estrategias de hosting para IA enterprise. Matriz de decisión por sensibilidad de datos, coste y control.

## "¿Dónde se ejecuta?" - La pregunta decisiva

Antes de seleccionar un modelo, antes de construir agents, antes de desplegar un interfaz, hay una pregunta: ¿dónde se ejecutan sus modelos de IA? Esta decisión determina qué garantías de protección de datos puede ofrecer, qué requisitos regulatorios cumple, cuáles son sus costes operativos y qué tan dependiente se vuelve de proveedores externos.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">De un vistazo - Estrategia de hosting IA para enterprise</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Tres niveles: EU SaaS (Cloud APIs), IaaS europeo (Self-Hosted GPU) y on-premises (hardware propio) - más la combinación híbrida.</li>
<li>La arquitectura híbrida enruta peticiones por sensibilidad de datos: 60-70% cloud, 25-35% IaaS europeo, 5-10% on-premises.</li>
<li>Gartner (2025) estima que el 40% de las grandes empresas operarán arquitecturas híbridas de hosting IA para 2027, frente a menos del 10% en 2024.</li>
<li>Modelos open source self-hosted (gpt-oss-120b) se ejecutan en una sola GPU por aprox. 1.200 EUR al mes en proveedores europeos.</li>
<li>Los costes totales con estrategia híbrida son un 30-40% inferiores a una estrategia pura de Cloud API, con mayor soberanía de datos.</li>
</ul>
</div>

Existen tres estrategias fundamentales - y una cuarta que se ha convertido en estándar en la práctica: la arquitectura híbrida que combina las tres.

## Nivel 1: EU SaaS - Cloud APIs con residencia de datos en la UE

La opción más sencilla y rápida: utiliza las APIs de los proveedores de modelos directamente. Claude a través de la API de Anthropic (región UE), GPT-5.5 a través de Azure OpenAI (centro de datos UE), Gemini a través de Google Cloud Platform (región UE). Los datos salen de su red pero se procesan en centros de datos de la UE.

### Ventajas

**Arranque más rápido:** Sin construir infraestructura, sin aprovisionar servidores GPU, sin necesidad de experiencia en ML-Ops. Configurar una clave API, firmar un contrato de encargado de tratamiento, en producción en horas.

**Actualizaciones automáticas:** Las actualizaciones de modelos, parches de seguridad y mejoras de rendimiento son desplegadas por el proveedor. Sin esfuerzo de mantenimiento propio.

**Escalabilidad:** Sin gestión de capacidad. En picos de carga, el proveedor cloud escala automáticamente. Sin sobredimensionamiento, sin infracapacidad.

**Variedad de modelos:** Acceso a todas las variantes de modelos del proveedor - insignia, equilibrado y presupuestario - a través de la misma API.

### Riesgos y limitaciones

**Los datos salen de la red corporativa.** Incluso con residencia de datos en la UE, sus peticiones se procesan en infraestructura que usted no controla. El proveedor tiene acceso técnico a los datos durante el procesamiento.

**CLOUD Act.** Los proveedores estadounidenses - incluyendo Anthropic, OpenAI y Google - están sujetos al CLOUD Act. Bajo ciertas condiciones, las autoridades estadounidenses pueden solicitar acceso a datos incluso cuando se almacenan en centros de datos de la UE. Para la mayoría de los datos corporativos, este riesgo es evaluable y aceptable. Para secretos comerciales, datos clasificados o información de infraestructura crítica, no lo es.

**Dependencia del proveedor.** Con una estrategia de proveedor único, depende de la política de precios, los cambios de API y la disponibilidad de un solo proveedor. Una arquitectura model-agnostic (véase [Comparativa de modelos de IA 2026](/es/revista/modelos-ia-comparacion-2026/)) reduce este riesgo.

**Contrato de encargado de tratamiento obligatorio.** Para el uso conforme al RGPD se requiere un contrato de encargado de tratamiento con el proveedor. Los tres grandes proveedores ofrecen contratos estándar - revíselos con su departamento jurídico. Atención: Los contratos estándar SaaS de encargado de tratamiento no cubren temas específicos de IA como el registro de prompts, la separación de entornos y las cadenas de proveedores de modelos. Nuestro [checklist de requisitos para contratos de IA](/es/revista/contrato-encargado-ia-checklist/) identifica las diez brechas y proporciona 25 preguntas de verificación.

### Adecuado para

- Tareas estándar con datos no sensibles: resúmenes, traducciones, respuesta general a preguntas
- Pruebas de concepto y proyectos piloto
- Tareas con volumen variable donde infraestructura GPU dedicada sería antieconómica
- Organizaciones sin experiencia en ML-Ops que quieren entrar en producción rápidamente

## Nivel 2: IaaS europeo - hosting GPU en proveedores europeos

La opción intermedia: alquila servidores GPU de un proveedor europeo de Infrastructure-as-a-Service - como Hetzner, IONOS o un proveedor especializado de GPU cloud. En estos servidores opera modelos open source como gpt-oss, Llama 4 o Mistral Medium 3.1.

### Requisitos de hardware y costes concretos

| Modelo | Requisito GPU | Coste estimado/mes |
|---|---|---|
| gpt-oss-120b | 1x A100/H100 (80 GB) | aprox. 1.200 EUR |
| gpt-oss-20b | CPU/16 GB RAM (o GPU pequeña) | aprox. 200-400 EUR |
| Llama 4 Scout | 1x A100 (80 GB) | aprox. 1.200 EUR |
| Llama 4 Maverick | 4x A100 (80 GB) | aprox. 3.500 EUR |
| Mistral Medium 3.1 | 4x A100 (80 GB) | aprox. 3.500 EUR |

### Ventajas

**Los datos permanecen en Europa.** El servidor está en un centro de datos europeo, operado por un proveedor europeo. Sin CLOUD Act, sin transferencia transatlántica de datos. Para el cumplimiento del RGPD, es la opción cloud más segura.

**Sin vendor lock-in.** Opera modelos open source bajo Apache 2.0 o la Meta Llama License. Si quiere cambiar de proveedor de hosting, migra el modelo - sin cuestiones de licencia, sin negociaciones contractuales.

**Control total del modelo.** Usted decide qué modelo en qué versión se ejecuta. Puede ajustar, cuantizar o reemplazar modelos con versiones más nuevas - sin esperar al proveedor.

**Costes predecibles.** Los servidores GPU tienen costes fijos mensuales. Sin cargos variables por tokens, sin sorpresas en picos de carga. Para organizaciones con volumen alto y constante, a menudo es más económico que las Cloud APIs.

### Requisitos

**Competencia ML-Ops.** Necesita a alguien que despliegue, monitorice, actualice y resuelva problemas del modelo. Puede ser un ingeniero de ML interno o un proveedor de servicios externo, pero no es esfuerzo cero.

**Planificación de capacidad.** Un servidor GPU tiene una capacidad definida. Si tiene 500 peticiones simultáneas, una sola GPU no es suficiente. Debe entender perfiles de carga y planificar capacidades.

**Sin actualizaciones automáticas.** Cuando sale un nuevo modelo, lo despliega usted. Cuando surge un problema de seguridad, lo parchea usted.

### Adecuado para

- Datos corporativos confidenciales (nivel de sensibilidad 2-3)
- Organizaciones que deben eliminar los riesgos del CLOUD Act
- Casos de uso con volumen constante y alto (ventaja de coste frente a Cloud APIs)
- Organizaciones con competencia DevOps/ML-Ops existente

## Nivel 3: On-Premises - IA en su propio hardware

La opción de máximo control: opera servidores GPU en su propio centro de datos o en un rack de colocación. Ningún dato sale de su red - bajo ninguna circunstancia.

### Ventajas

**Máxima soberanía de datos.** Sin acceso externo, sin proveedor externo, sin dependencia externa. El hardware es suyo, el modelo es suyo, los datos nunca salen de su red.

**Certeza regulatoria.** Para operadores de infraestructura crítica, administraciones públicas, sector defensa y organizaciones con datos clasificados, on-premises es a menudo la única opción que cumple los requisitos de compliance.

**Sin costes recurrentes de licencia o API.** Tras la inversión inicial, solo quedan electricidad, refrigeración y mantenimiento. En operación a largo plazo con alto volumen, on-premises puede ser la opción más económica.

### Desafíos

**Alta inversión inicial.** Un servidor GPU de producción con NVIDIA H100 (80 GB) cuesta entre 25.000 y 40.000 EUR. Para configuraciones más potentes (multi-GPU, redundancia), los costes van de 60.000 a 120.000 EUR o más.

**Equipo ML-Ops necesario.** On-premises significa: usted es responsable de todo. Mantenimiento de hardware, despliegue de modelos, monitorización, actualizaciones, seguridad. Esto requiere un equipo dedicado o un proveedor de servicios experimentado.

**El escalado no es trivial.** Cuando la demanda crece, no puede añadir otra GPU con un clic. La adquisición de hardware tarda semanas o meses.

### Adecuado para

- Operadores de infraestructura crítica y administraciones públicas
- Datos clasificados y niveles de confidencialidad máximos
- Organizaciones con centro de datos propio y competencia ML-Ops
- Disposición a inversión a largo plazo con volumen muy alto

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">eBook gratuito: Infraestructura de IA</p>
<p class="text-body text-gosign-text mb-4">Build, Buy, Hybrid - infraestructura conforme al EU AI Act con B/B/H-Framework y 7-Layer Reference Architecture.</p>
<a href="/es/ebook/ia-infraestructura-manual-gobernanza/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Descargar gratis</a>
</div>

## El árbol de decisión

La siguiente lógica de decisión ayuda en la asignación:

```
Sus datos contienen PII o secretos comerciales?
+-- NO -> EU SaaS (Nivel 1)
+-- SI -> Infraestructura critica o datos clasificados?
+-- SI -> On-Premises (Nivel 3)
+-- NO -> IaaS europeo (Nivel 2) o Hibrido
```

En la práctica, la respuesta rara vez es un único nivel. La mayoría de las organizaciones tienen datos de distinta sensibilidad y, por tanto, necesitan una arquitectura que cubra todos los niveles.

## Híbrido como estándar: La arquitectura de enrutamiento

La estrategia híbrida combina los tres niveles en una única arquitectura. Una capa de enrutamiento decide automáticamente qué petición pasa por qué canal, basándose en la sensibilidad de los datos, no en la decisión de empleados individuales.

### Cómo funciona el enrutamiento

**Nivel de sensibilidad 1-2 (público, interno):** Las peticiones van por Cloud APIs. Rápido, económico, escalable. Ejemplo: resumir un whitepaper público, traducir un comunicado de prensa, redactar un email general.

**Nivel de sensibilidad 3 (confidencial):** Las peticiones se enrutan a modelos self-hosted en el centro de datos europeo. Sin fuga de datos, sin CLOUD Act. Ejemplo: analizar contratos internos, procesar datos de RRHH, evaluar datos financieros confidenciales.

**Nivel de sensibilidad 4 (estrictamente confidencial / regulado):** Las peticiones se ejecutan exclusivamente en infraestructura on-premises. Ejemplo: documentos clasificados, sistemas de infraestructura crítica, datos bajo obligaciones especiales de confidencialidad.

### Requisito previo: Clasificación de datos

Para que el enrutamiento funcione, la organización debe clasificar sus datos. Suena laborioso, pero en muchas organizaciones ya existe - por ejemplo, como parte de Sistemas de Gestión de Seguridad de la Información (SGSI) existentes o marcos nacionales de clasificación de seguridad. Las reglas de enrutamiento mapean esta clasificación existente a la infraestructura de IA.

### Implementación técnica

La capa de enrutamiento se sitúa entre el [Enterprise AI Portal](/es/revista/enterprise-ai-chat-interface/) (el interfaz que usan los empleados) y los endpoints de los modelos. Consta de tres componentes:

1. **Clasificador:** Detecta automáticamente la sensibilidad de datos de una petición, basándose en palabras clave, sistema de origen o marcado explícito del usuario.
2. **Motor de enrutamiento:** Asigna la petición al endpoint de modelo adecuado: Cloud API, IaaS europeo u on-premises.
3. **Audit Log:** Registra cada decisión de enrutamiento: qué petición, qué nivel de sensibilidad, qué endpoint. Trazable y exportable.

### Efecto en costes

La arquitectura híbrida optimiza no solo la seguridad de los datos sino también los costes. Las Cloud APIs son baratas por petición pero variables. Los modelos self-hosted tienen costes fijos que se amortizan con alto volumen. La combinación aprovecha ambos: Cloud APIs económicas para el grueso de peticiones no sensibles, modelos self-hosted con costes fijos optimizados para el volumen confidencial.

En la práctica, vemos en organizaciones con 1.000+ empleados típicamente la siguiente distribución: 60-70% de las peticiones pasan por Cloud APIs (nivel 1-2), 25-35% por IaaS europeo (nivel 3), y 5-10% por on-premises (nivel 4). Los costes totales son un 30-40% inferiores a una estrategia pura de Cloud API, con mayor soberanía de datos.

## Resumen: Los tres niveles de un vistazo

| Criterio | EU SaaS (Nivel 1) | IaaS europeo (Nivel 2) | On-Premises (Nivel 3) |
|---|---|---|---|
| Soberanía de datos | Región UE, contrato encargado | Europa, sin CLOUD Act | Máxima |
| Coste inicial | Ninguno | Bajo (alquiler) | Alto (60-120K EUR+) |
| Coste operativo | Variable (tokens) | Fijo (alquiler GPU) | Fijo (electricidad, mantenimiento) |
| Esfuerzo ML-Ops | Ninguno | Medio | Alto |
| Escalabilidad | Automática | Manual | Manual, lenta |
| Adecuado para | Datos nivel 1-2 | Datos nivel 2-3 | Datos nivel 3-4 |

La estrategia correcta es casi siempre una combinación. Gosign implementa la capa de enrutamiento que conecta los tres niveles, para que sus empleados usen un único interfaz y el sistema seleccione automáticamente el camino correcto.

Más información: [Infraestructura de IA](/es/servicios/infraestructura/) | [Decision Layer & Shadow AI](/es/revista/decision-layer-shadow-ai/)

---

**Enterprise AI Infrastructure Blueprint 2026 - Serie de artículos**

| Anterior | Vista general | Siguiente |
|:---|:---:|---:|
| [Modelos de IA 2026: ¿Cuál para cada caso de uso?](/es/revista/modelos-ia-comparacion-2026/) | [Vista general](/es/revista/infraestructura-ia-blueprint-2026/) | [Enterprise AI Portal: Cuatro interfaces open source en comparativa](/es/revista/enterprise-ai-chat-interface/) |

*Todos los artículos de esta serie: [Enterprise AI Infrastructure Blueprint 2026](/es/revista/infraestructura-ia-blueprint-2026/)*

---

**¿Quiere saber qué estrategia de hosting es la adecuada para sus datos?** Gosign analiza su clasificación de datos y diseña la arquitectura híbrida apropiada.

<a href="/es/contacto/" target="_blank" rel="noopener noreferrer">Reserve una consulta</a> - En 30 minutos aclaramos que niveles de hosting necesita.

--- Human-in-the-Loop: principio arquitectónico, no checkbox ---
> Human-in-the-Loop en AI Agents: revisión humana impuesta arquitectónicamente. Confidence Routing, reglas de escalación, verificaciones de sesgo.

## El problema: HITL como afirmacion de marketing

Casi todos los proveedores de IA afirman que su solucion tiene "Human-in-the-Loop". En la practica, esto suele significar: en algun lugar del proceso hay un boton de aprobacion. Una persona puede pulsarlo. Pero no tiene que hacerlo.

Eso no es Human-in-the-Loop. Es una aprobacion opcional que desaparece bajo la presion del tiempo. Cuando un gestor procesa 200 documentos al dia y 195 de ellos son correctos, acabara aprobandolos todos sin revisar.

El verdadero Human-in-the-Loop es un principio arquitectónico. Significa: para tipos de decisiones definidos, el agente físicamente no puede actuar de forma autónoma. El flujo de trabajo se pausa. El sistema destino no se contacta. Solo después de la revisión humana y la aprobación documentada continúa el proceso.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">De un vistazo - Arquitectura Human-in-the-Loop</p>
<ul class="text-body text-gosign-text space-y-2">
<li>HITL real es un principio arquitectónico, no un botón de aprobación opcional - el agente físicamente no puede eludir la revisión humana para tipos de decisión definidos.</li>
<li>Tres disparadores: baja confianza del agente, clasificación de alto riesgo (discriminación, consulta del comité) y primera aplicación de nuevas reglas.</li>
<li>El EU AI Act exige supervisión humana efectiva para sistemas de IA de alto riesgo - los procesos de RRHH entran explícitamente en esta categoría.</li>
<li>Los acuerdos de empresa se convierten en restricciones técnicas en el Decision Layer que el sistema no puede eludir.</li>
<li>HITL no resuelve el sesgo en datos de entrenamiento ni escala linealmente - es un componente junto a Audit Trail, Bias Monitoring y controles Cert-Ready.</li>
</ul>
</div>

Según la Comisión Europea (2024), la supervisión humana es obligatoria para todos los sistemas de IA de alto riesgo bajo el EU AI Act, y los procesos de RRHH están explícitamente listados en el Anexo III - lo que convierte el Human-in-the-Loop impuesto arquitectónicamente en una necesidad legal, no en una opción de diseño.

| Disparador HITL | Descripción | Configurable |
|---|---|---|
| Baja confianza | Incertidumbre del agente por debajo del umbral definido | Sí, por cliente |
| Riesgo de discriminación | Decisiones con potencial de resultados discriminatorios | Siempre escalado |
| Materias del comité de empresa | Decisiones sujetas a información y consulta | Siempre escalado |
| Superación de umbral de valor | Importe por encima del límite de procesamiento autónomo | Sí, por cliente |
| Introducción de nueva regla | Primera aplicación de un nuevo conjunto de reglas | Durante fase de aprendizaje |

## HITL como principio arquitectónico técnico

En la arquitectura Gosign, Human-in-the-Loop esta implementado en el Decision Layer. La decision sobre cuando se involucra a una persona se basa en tres criterios:

**Confidence Routing:** Cada decision del agente tiene un valor de confianza. Si la confianza esta por debajo del umbral definido, se escala automaticamente. El umbral es configurable por cliente.

**Clasificacion de riesgos:** Determinados tipos de decisiones se escalan siempre, independientemente de la confianza. Decisiones con potencial discriminatorio, materias sujetas a informacion y consulta del comite de empresa, superaciones de umbrales de valor.

**Escalacion obligatoria basada en reglas:** Los nuevos conjuntos de reglas que se aplican por primera vez pasan siempre por una revision humana en la fase de introduccion. Solo despues de una fase de aprendizaje validada el agente pasa al modo autonomo, exactamente para esa regla.

El requisito de Human-in-the-Loop esta impuesto tecnicamente. No hay workaround, no hay atajo, no hay override de administrador. El agente no puede eludir la escalacion.

## Como funciona HITL en la practica

Un agente de RRHH procesa una solicitud de pago extraordinario. El Document Agent lee la solicitud. El Knowledge Agent verifica el acuerdo de empresa vigente. El Decision Layer evalua:

Resultado: pago extraordinario aprobable segun acuerdo de empresa, articulo 12, parrafo 3. Confianza: 94%. Riesgo: bajo.

Pero: la decision afecta a un componente retributivo. En la configuracion HITL esta definido: las decisiones de retribucion se escalan siempre, independientemente de la confianza. El flujo de trabajo se pausa.

El gestor responsable ve en el dashboard: la solicitud, la propuesta del agente, la regla aplicada en la version actual, el valor de confianza, el motivo de la escalacion. Revisa, confirma o corrige. Su decision se documenta en el Audit Trail, incluyendo la informacion de que se trata de una decision Human-in-the-Loop.

## HITL y el comite de empresa

Human-in-the-Loop es la respuesta tecnica a un requisito organizativo: el derecho de informacion y consulta. En Espana, el Estatuto de los Trabajadores (Real Decreto Legislativo 2/2015) otorga al comite de empresa derechos de informacion y consulta sobre la implantacion de sistemas tecnologicos que afectan a las condiciones laborales (art. 64 ET). Los AI Agents en procesos de RRHH estan sujetos a estos derechos.

El Decision Layer convierte los acuerdos de empresa en constraints tecnicos. Si un acuerdo de empresa establece: "Las decisiones sobre evaluaciones de rendimiento no pueden tomarse de forma completamente automatizada", esto se implementa como regla HITL en el Decision Layer. El agente no puede eludir esta regla.

El resultado: el comite de empresa puede verificar que sus requisitos se imponen tecnicamente, no solo se prometen organizativamente.

## HITL y el EU AI Act

El EU AI Act exige supervision humana (Human Oversight, Art. 14) para sistemas de IA de alto riesgo. Los procesos de RRHH caen explicitamente en la categoria de alto riesgo: reclutamiento, evaluaciones de rendimiento, decisiones de ascenso, retribucion, despido.

Human-in-the-Loop como principio arquitectonico cumple los requisitos del EU AI Act en materia de Human Oversight. No es suficiente tener a una persona en el proceso que teoricamente podria intervenir. El EU AI Act exige una supervision humana efectiva, lo que significa: la persona debe poder comprender la decision, debe poder detenerla y su intervencion debe estar documentada.

En Espana, la AESIA (Agencia Espanola de Supervision de Inteligencia Artificial) supervisara el cumplimiento de estos requisitos. La combinacion del EU AI Act, la Ley 15/2022 para la igualdad de trato y el Estatuto de los Trabajadores crea un marco normativo donde Human-in-the-Loop es esencial, no opcional.

El Decision Layer documenta en cada decision HITL: quien ha revisado, cuando, cual era la propuesta del agente, cual fue la decision humana y si coinciden o difieren.

## El limite: lo que HITL no resuelve

Human-in-the-Loop no es la solucion para todos los problemas de gobernanza. En concreto:

HITL no resuelve el problema del sesgo en los datos de entrenamiento. Si el modelo de lenguaje tiene sesgos sistematicos, un gestor no lo detectara en casos individuales. Para eso se necesita un Bias-Monitoring estadistico sobre todas las decisiones del agente.

HITL no escala linealmente. Si el agente toma 10.000 decisiones al dia y el 20% se escala, se necesitan recursos para 2.000 revisiones manuales. Los umbrales HITL deben calibrarse para que la tasa de escalacion sea manejable sin comprometer la gobernanza.

HITL es un componente de la arquitectura de gobernanza, junto con Audit Trail, Bias-Monitoring, versionado de conjuntos de reglas y Cert-Ready Controls.

Mas sobre este tema: [Informacion, Consulta y Comite de Empresa](/es/governance/co-determination/)

Mas sobre gobernanza: [Gobernanza de IA](/es/governance/)

<a href="/es/contacto/" target="_blank" rel="noopener noreferrer">Agendar reunion</a>. Le mostramos como Human-in-the-Loop se implementa en su arquitectura.

--- IA Governance Dashboard: monitorización de agentes ---
> Cómo un dashboard de gobernanza IA hace transparentes las actividades de los agentes para IT, Comité de Empresa y auditoría interna. Audit Trail.

## Por qué un dashboard no es suficiente, pero sin él nada funciona

La gobernanza de IA no es un problema de dashboard. La gobernanza es un principio arquitectónico. Pero sin una capa de presentación que haga transparentes las actividades de los agentes, la gobernanza se queda en abstracción. Nadie en la organización - ni IT, ni el Comité de Empresa, ni auditoría interna - puede evaluar qué están haciendo realmente los agentes.

Un dashboard de gobernanza IA es la interfaz entre la arquitectura técnica de gobernanza y las personas que asumen la responsabilidad. Hace visible lo que el [Decision Layer](/es/decision-layer/) documenta en segundo plano.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">De un vistazo - Dashboard de Gobernanza IA</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Un dashboard de gobernanza IA es la capa de presentación de los datos del Decision Layer - no una herramienta de monitorización independiente.</li>
<li>Muestra actividades de agentes, Audit Trail, rendimiento de modelos y versiones de reglas en tiempo real.</li>
<li>Tres vistas basadas en roles (IT, dirección, Comité de Empresa) son requisito previo para que la gobernanza funcione en la práctica.</li>
<li>Gartner (2024) pronostica que para 2026, las organizaciones con frameworks de gobernanza IA experimentarán un 40% menos de incidentes de compliance relacionados con IA.</li>
<li>Sin dashboard, nadie en la organización puede verificar qué hacen realmente los agentes de IA.</li>
</ul>
</div>


## Qué debe mostrar un dashboard de gobernanza IA

### Actividades de los agentes: quién hace qué

Cada agente genera un registro de protocolo por cada acción: marca temporal, entrada, regla aplicada, salida, estado (procesado automáticamente, enviado para aprobación, escalado). El dashboard agrega estos registros y permite filtrarlos por periodo, departamento, tipo de agente y estado.

Esto no es monitorización IT convencional. Es un protocolo de decisiones, diseñado para personas que necesitan entender qué hacen los agentes en su ámbito de responsabilidad.

### Audit Trail: trazabilidad completa

Para cada decisión individual del agente existe un registro de datos completo: qué documento se presentó? Qué datos se extrajeron? Contra qué regla (en qué versión) se verificó? Qué recomendación emitió el agente? Quién aprobó o escaló?

El dashboard hace este [Audit Trail](/es/governance/) consultable y exportable, para auditoría interna, auditores externos o inspecciones regulatorias de la AEPD.

### Monitorización de modelos: qué LLM rinde cómo

En una [arquitectura agnóstica de modelos](/es/servicios/infraestructura/) varios modelos operan en paralelo. El dashboard muestra por modelo: tiempos de respuesta, consumo de tokens, costes, tasas de error. Esto permite tomar decisiones fundamentadas sobre selección y enrutamiento de modelos, basadas en datos operativos reales, no en intuiciones.

### Versiones de reglas: qué ha cambiado

Los agentes operan sobre la base de reglas de decisión. Cuando una regla cambia - porque se actualiza un convenio colectivo o entra en vigor un nuevo acuerdo de empresa conforme al Estatuto de los Trabajadores - debe ser trazable: cuál era la regla anterior? Cuál es la nueva? Desde cuándo aplica? Quién la aprobó?

El dashboard muestra las versiones de reglas como línea temporal. Cada cambio está asignado a un responsable y vinculado al Audit Trail.

<table class="w-full text-left text-sm">
<thead><tr class="border-b border-gosign-border">
<th class="py-2 pr-4 font-semibold">Componente</th>
<th class="py-2 pr-4 font-semibold">Propósito</th>
<th class="py-2 pr-4 font-semibold">Fuente de datos</th>
</tr></thead>
<tbody>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Registro de actividad de agentes</td><td class="py-2 pr-4">Seguimiento de cada acción del agente en tiempo real</td><td class="py-2 pr-4">Entradas de protocolo del Decision Layer</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Visor de Audit Trail</td><td class="py-2 pr-4">Registros de decisión consultables y exportables</td><td class="py-2 pr-4">Registros de auditoría del Decision Layer</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Monitor de modelos</td><td class="py-2 pr-4">Comparar rendimiento y costes de LLM</td><td class="py-2 pr-4">Métricas de inferencia por modelo</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Línea temporal de versiones de reglas</td><td class="py-2 pr-4">Seguimiento de cambios con responsabilidad asignada</td><td class="py-2 pr-4">Repositorio de reglas versionado</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Dashboard de escalado</td><td class="py-2 pr-4">Monitorizar tasas de Human-in-the-Loop</td><td class="py-2 pr-4">Eventos de escalación HITL</td></tr>
</tbody>
</table>

## Tres vistas para tres audiencias

Un solo dashboard, pero diferentes niveles de acceso según el rol.

La vista de IT muestra el rendimiento técnico: uptime de agentes, latencia de modelos, tasas de error de API, utilización de recursos. Sirve para la gestión operativa y la planificación de capacidad.

La vista de dirección muestra indicadores de negocio: casos procesados por día, tasa de automatización, tasa de escalado, tiempos de procesamiento. Sirve para la evaluación del ROI y el reporting al consejo de dirección.

La vista del Comité de Empresa muestra datos agregados de uso: en qué departamentos están desplegados los agentes? Con qué frecuencia se automatizan decisiones frente a las que se envían para aprobación humana? Qué cambios de reglas se han realizado? Esta vista deliberadamente no contiene datos personales individualizados, sino que crea transparencia sobre el uso de IA en su conjunto.

Esta triple segmentación no es un complemento opcional. Es el requisito previo para que la gobernanza de IA funcione en la práctica. Sin vista de IT, no hay operaciones estables. Sin vista de dirección, no hay presupuesto. Sin vista del Comité de Empresa, no hay [acuerdo de empresa](/es/governance/co-determination/).


## Dashboard de gobernanza como componente arquitectónico

El dashboard no es una herramienta independiente que se añade a la infraestructura IA a posteriori. Es una capa de presentación que opera directamente sobre los datos del [Decision Layer](/es/decision-layer/).

Cada entrada del Audit Trail, cada versión de regla, cada métrica de modelo es generada automáticamente por el Decision Layer, como subproducto de las operaciones normales, no como esfuerzo adicional. El dashboard hace estos datos accesibles, filtrables y exportables.

Esto es [Governance by Design](/es/governance/): la transparencia no surge del reporting retrospectivo, sino como parte integral de la arquitectura.

En Gosign construimos [infraestructura IA](/es/servicios/infraestructura/) con una capa de gobernanza integrada. El dashboard no es una opción, es parte de cada infraestructura de agentes que entregamos.

--- IA Open Source Autohospedada 2026: Stack Enterprise ---
> Autohospedaje de LLM open source en 2026: Mistral, gpt-oss, DeepSeek, Llama 4. Hardware, TCO, hosting GPU UE, matriz de decisión por workload.

El mercado de modelos dio a las compras Enterprise UE una opción que nunca antes tuvo. Los modelos de pesos abiertos igualan a los propietarios en la mayoría de cargas enterprise. Tres modelos open source frontier-class se publicaron bajo Apache 2.0 solo en 2025. Los proveedores europeos de hosting GPU ofrecen capacidad H100 a tarifas horarias predecibles desde centros de datos en París y Frankfurt. La sentencia Schrems II combinada con el US CLOUD Act convirtió el autohospedaje en la única arquitectura con exposición cero a proveedores extranjeros.

Y aún así la conversación en compras sigue tratando "IA open source autohospedada" como un único producto. No lo es. Es una decisión de stack con cuatro modelos creíbles, tres patrones de despliegue y un problema real de matemáticas TCO. Este artículo es el complemento detallado de [Cuándo Mistral, cuándo Claude Opus? Decision Routing para Enterprise UE 2026](/es/revista/modelos-ia-comparacion-2026/) - si ya has decidido autohospedar, así se resuelve realmente la selección de modelo.

<div class="not-prose my-12 border border-gosign-border bg-gosign-light rounded-card p-6 lg:p-8">
<p class="text-h3 font-bold text-gosign-dark mb-3">De un vistazo - IA Open Source Autohospedada para Enterprise UE 2026</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Cinco modelos autohospedables creíbles en 2026: Mistral Small 3.2 (Apache 2.0, 24B, una sola GPU de consumo), gpt-oss-120b (Apache 2.0, MoE, una sola H100), DeepSeek V4-Flash (MIT, 284B/13B activo MoE, preview abril 2026), DeepSeek V4-Pro (MIT, 1.6T/49B activo, preview, clase clúster), Llama 4 Scout (Meta License, contexto 10M).</li>
<li>Mistral Small 3.2 gana el puesto de workhorse porque funciona en hardware de consumo (RTX 4090), trae entrenamiento multilingüe e incluye capacidad visual nativa para cargas documentales.</li>
<li>DeepSeek V4-Pro (preview, 24 de abril de 2026) se acerca al rendimiento frontier closed-source bajo licencia MIT pero necesita clúster multi-GPU; el autohospedaje realista para la mayoría de empresas empieza con V4-Flash.</li>
<li>El hosting GPU UE ya no es el cuello de botella: Scaleway ofrece H100 SXM a ~3,50 EUR/h, OVHcloud tiene tier soberano, Hetzner provee servidores RTX dedicados, Telefónica Tech atiende el mercado español, T-Systems sirve a sectores regulados.</li>
<li>Cruce TCO de cloud API a autohospedaje: típicamente entre 50 y 100 millones de tokens al mes sostenidos. Por debajo, EU-Cloud-API gana al autohospedaje. Por encima, el hardware dedicado amortiza en 12-18 meses.</li>
<li>La arquitectura es multi-modelo, no mono-modelo: Mistral Small para volumen, gpt-oss-120b o DeepSeek V4-Flash para razonamiento pesado on-prem, V4-Pro o R1 como especialistas mate/lógica, Llama 4 Scout para contexto ultralargo. El enrutado decide qué modelo atiende cada decisión.</li>
</ul>
</div>

## Decidiste autohospedar - aquí empieza la cuestión del modelo

La decisión de autohospedar un stack LLM raramente es una decisión de modelo. Es una decisión de cumplimiento: datos clasificados por encima de cierto umbral no pueden salir de la red corporativa, bajo RGPD, LOPDGDD o requisitos ENS para administración. Es una decisión de arquitectura: la capa de inferencia debe ser una dependencia controlada, no una API externa. Es una decisión de compras: CAPEX sobre hardware frente a OPEX sobre instancias GPU alojadas.

Una vez tomada esa decisión, se abre la cuestión del modelo. Qué modelo open source sobre qué suelo de hardware para qué mezcla de cargas? Cinco modelos tienen disponibilidad creíble en producción Q2 2026: Mistral Small 3.2, gpt-oss-120b, DeepSeek V4-Flash, DeepSeek V4-Pro (preview) y Llama 4 Scout. DeepSeek R1 de enero de 2025 sigue siendo apto para producción pero ha sido en gran parte superado por la línea V4 para despliegues nuevos. Cada modelo tiene una curva coste-calidad distinta y un perfil operativo distinto.

Este artículo evita el debate de rankings. Las puntuaciones de benchmark convergen lo suficiente como para que el encaje con la carga importe más que los puntos nominales en MMLU o HumanEval. La pregunta es qué modelo sobrevive 18 meses en tu stack, cuál se gana su hardware y qué combinación produce el Audit Trail que exige el EU AI Act.

## Los modelos autohospedables creíbles, uno frente al otro

| Modelo | Parámetros / Arquitectura | Licencia | Suelo hardware CAPEX (bf16/fp16) | OPEX hosted (UE) | Fortaleza clave | Debilidad clave |
|---|---|---|---|---|---|---|
| Mistral Small 3.2 | 24B densa, GQA (32Q/8KV) | Apache 2.0 | 1× RTX 4090 ~1.500 EUR o 1× H100 80GB ~30.000 EUR | ~1.500-2.500 EUR/mes (1× H100 hosted) | Multilingüe, visión, rápido (~150 tok/s en GPU consumo), apto para volumen | Razonamiento no de máximo nivel |
| gpt-oss-120b | 117B total / 5.1B activos (MoE) | Apache 2.0 | 1× H100/A100 80GB ~30.000 EUR | ~1.200-2.500 EUR/mes (1× H100 hosted) | Razonamiento a nivel o4-mini, inferencia eficiente con MoE | Sin visión, solo hardware datacenter |
| DeepSeek V4-Flash *(preview, abr 2026)* | 284B total / 13B activos (MoE), contexto 1M | MIT | 1-4× H100/A100 80GB ~30.000-120.000 EUR con quant; multi-GPU para precisión completa | ~1.500-5.000 EUR/mes (1-4× H100 hosted) | Razonamiento frontier-class con coste hardware moderado, multimodal nativo, optimizado para agentes | Estado preview - benchmarks deben reverificarse antes de producción |
| DeepSeek V4-Pro *(preview, abr 2026)* | 1.6T total / 49B activos (MoE), contexto 1M | MIT | Clúster 8× H100 ~240.000 EUR CAPEX | ~10.000-12.000 EUR/mes (8× H100 hosted) | Se acerca al rendimiento de GPT-5.5 y Gemini 3.1 Pro bajo licencia abierta, optimizado para agent-tooling (Claude Code, OpenClaw) | Hardware clase datacenter; on-prem para gran empresa, API/hosted para PYME |
| DeepSeek R1 *(ene 2025, maduro)* | 671B total / 37B activos (MoE) | MIT | Multi-GPU: 4-8× H100 ~120.000-240.000 EUR | ~5.000-10.000 EUR/mes (4-8× H100 hosted) | Especialista mate/lógica maduro, amplio soporte de frameworks | Mayormente superado por V4-Flash en despliegues nuevos |
| Llama 4 Scout | 17B activos (MoE) | Meta Llama Community License | 1× GPU ~30.000 EUR | ~1.500 EUR/mes (1× H100 hosted) | Ventana de contexto de 10 millones de tokens | Restricción de licencia con >700M MAU; revisión de licencia necesaria |

DeepSeek V4-Pro está disponible bajo licencia MIT en Hugging Face - es genuinamente open source, no propietario. La cuestión no es de licencia, sino de tamaño de empresa. Para una gran empresa del IBEX-35 o mediana empresa superior, 240.000 EUR de CAPEX hardware son una partida estándar del presupuesto TI - igual que cualquier otro clúster datacenter de razonamiento crítico. Para una PYME por debajo de 500 empleados, el camino realista es V4-Pro vía API (Together.ai, Fireworks, DeepSeek API) o como variante hospedada en proveedores UE - misma licencia MIT abierta, mismos pesos, sin CAPEX hardware. Es la misma decisión que con cualquier otro workload datacenter: ¿es la escala adecuada para hardware propio, o se consume vía proveedor?

Tres clarificaciones importan aquí.

**Suelo hardware de Mistral Small 3.2.** La guía oficial de Mistral lista ~55 GB de RAM GPU para inferencia bf16/fp16, lo que lo sitúa sobre H100 o A100 80GB en producción. Con cuantización 4-bit (GPTQ, AWQ), funciona sobre una sola RTX 4090 de 24 GB con leve pérdida de calidad. Para despliegues piloto o inferencia single-tenant, la vía RTX 4090 es real. Para producción multi-tenant con peticiones concurrentes, la vía H100 es el dimensionado correcto.

**Estado preview de DeepSeek V4.** DeepSeek-V4-Pro y V4-Flash se lanzaron como preview el 24 de abril de 2026 bajo licencia MIT, ambos con ventana de contexto de 1M tokens vía la nueva arquitectura Hybrid Attention (Compressed Sparse Attention + Heavily Compressed Attention). En el escenario de 1M de tokens, V4-Pro requiere supuestamente solo el 27% de los FLOPs de inferencia por token y el 10% de la KV cache frente a V3.2 - ganancias de eficiencia significativas para cargas de contexto largo. Ambas variantes están optimizadas para agent-tooling (integración con Claude Code, OpenClaw). Sin embargo: preview significa que los benchmarks no se han verificado independientemente a escala. Para decisiones de producción en sectores regulados (banca CNMV, sanidad, AAPP bajo ENS), espera el release GA o ejecuta tus propios benchmarks representativos antes de comprometerte.

**Revisión de licencia para Llama 4 Scout.** La Meta Llama Community License permite uso comercial pero contiene dos restricciones que compras enterprise debe revisar: un umbral de 700 millones de MAU por encima del cual se requiere licencia separada de Meta, y una restricción sobre el uso de salidas del modelo para entrenar modelos competidores. Para la mayoría de empresas españolas ambas son irrelevantes en la práctica, pero la nota de compras debe quedar explícita.

## TCO: cuándo gana el autohospedaje al cloud API?

La economía cambia en un umbral de volumen de tokens. Por debajo, las APIs alojadas ganan porque el tiempo de hardware ocioso domina. Por encima, las GPUs dedicadas ganan porque el coste incremental por token se acerca al coste de electricidad más amortización.

Un cálculo representativo para Mistral Small 3.2 en hosting UE:

| Elemento de coste | Valor (hosting UE) |
|---|---|
| Instancia H100 80GB, proveedor UE (clase Scaleway) | ~2.500 EUR/mes dedicada, o ~3,50 EUR/h bajo demanda |
| Throughput Mistral Small 3.2 (H100 única) | ~150 tokens/s sostenidos, ~390M tokens/mes al 100% de utilización |
| Coste efectivo por 1M tokens al 60% de utilización | ~10-12 EUR por 1M tokens |
| Equivalente API Mistral La Plateforme (Mistral Small) | ~0,40 USD por 1M tokens de entrada; depende del volumen |
| Equivalente API Claude Sonnet 4.6 | ~3 USD por 1M tokens entrada; ~15 USD salida |
| Equivalente API Claude Opus 4.7 | ~5 USD por 1M tokens entrada; ~25 USD salida |

El cruce para Mistral Small cae entre 50 y 100 millones de tokens al mes sostenidos, dependiendo de si la carga es pesada en entrada o pesada en salida. Una pipeline enterprise 24/7 corriendo 5 a 10 nodos worker cruza ese umbral típicamente en el primer trimestre.

Para gpt-oss-120b la matemática es similar pero empieza más arriba: una H100 soporta menor throughput que Mistral Small al mismo coste hardware, así que la amortización por token es aproximadamente 2× la de Mistral Small. El cruce frente a Claude Opus 4.7 cae alrededor de 30-50 millones de tokens al mes - exactamente el rango donde aterrizan las cargas de razonamiento pesado en sistemas IA enterprise.

La arquitectura 1.6T/49B activos de DeepSeek V4-Pro es hardware clase hyperscaler. El autohospedaje realista empieza con V4-Flash (284B/13B activos), que cabe en 1-2 H100 con cuantización o 4 H100 en precisión completa. El TCO autohospedado para V4-Flash se justifica cuando el razonamiento frontier-class es una carga sostenida en clasificaciones de datos críticas para soberanía; para razonamiento ocasional, la API de V4-Flash o Mistral La Plateforme es más barata. V4-Pro on-prem es realista solo para empresas clase hyperscaler (servicios financieros con infraestructura grado HFT, grandes clientes de defensa o AAPP a gran escala). El resto usa V4-Pro vía API o variante hospedada.

Estos números se basan en precios públicos de hosting UE de Scaleway y OVHcloud y en datos públicos de throughput de modelos. Son ilustrativos, no contractuales.

<figure class="not-prose my-12">
<svg viewBox="0 0 800 480" xmlns="http://www.w3.org/2000/svg" role="img" aria-labelledby="tco-title-es tco-desc-es" class="w-full h-auto max-w-3xl mx-auto">
<title id="tco-title-es">Punto de cruce TCO: self-hosted vs API cloud por volumen mensual de tokens (mayo 2026)</title>
<desc id="tco-desc-es">Comparación de costes: gasto mensual USD en eje Y (escala log 100 a 100.000 USD) frente a volumen mensual de tokens en eje X (escala log 1M a 10B tokens). Cuatro curvas: Claude Opus 4.7 API 15 USD por 1M tokens (lineal), Mistral La Plateforme API 0,40 USD por 1M tokens (lineal), Mistral Small 3.2 self-host H100 única ~2.700 USD/mes plano más electricidad marginal, gpt-oss-120b self-host H100 única ~3.200 USD/mes plano. Cruces: Mistral Small 3.2 self-hosted bate Claude Opus 4.7 API en torno a 180 millones de tokens mensuales. Por debajo de 50M tokens/mes domina la economía cloud-API. Por encima de 500M tokens/mes domina self-host independientemente del modelo.</desc>
<defs><style>
.axis-line-es { stroke: #1a2e4d; stroke-width: 1.5; }
.grid-line-es { stroke: #d4d0cb; stroke-width: 0.5; stroke-dasharray: 2 3; }
.axis-label-es { font-family: -apple-system, system-ui, sans-serif; font-size: 11px; fill: #4a5568; }
.title-text-es { font-family: -apple-system, system-ui, sans-serif; font-size: 13px; fill: #1a2e4d; font-weight: 700; }
.legend-text-es { font-family: -apple-system, system-ui, sans-serif; font-size: 11px; fill: #1a2e4d; font-weight: 500; }
.annotation-es { font-family: -apple-system, system-ui, sans-serif; font-size: 10px; fill: #1a2e4d; font-style: italic; }
.crossover-marker-es { fill: #fcd34d; stroke: #b8941f; stroke-width: 1.5; }
</style></defs>
<text x="400" y="25" class="title-text-es" text-anchor="middle">Coste mensual (USD, escala log)</text>
<line x1="80" y1="380" x2="740" y2="380" class="grid-line-es"/><line x1="80" y1="300" x2="740" y2="300" class="grid-line-es"/><line x1="80" y1="220" x2="740" y2="220" class="grid-line-es"/><line x1="80" y1="140" x2="740" y2="140" class="grid-line-es"/><line x1="80" y1="60" x2="740" y2="60" class="grid-line-es"/>
<line x1="212" y1="60" x2="212" y2="380" class="grid-line-es"/><line x1="344" y1="60" x2="344" y2="380" class="grid-line-es"/><line x1="476" y1="60" x2="476" y2="380" class="grid-line-es"/><line x1="608" y1="60" x2="608" y2="380" class="grid-line-es"/>
<text x="72" y="384" class="axis-label-es" text-anchor="end">$100</text>
<text x="72" y="304" class="axis-label-es" text-anchor="end">$1.000</text>
<text x="72" y="224" class="axis-label-es" text-anchor="end">$10.000</text>
<text x="72" y="144" class="axis-label-es" text-anchor="end">$100.000</text>
<text x="72" y="64" class="axis-label-es" text-anchor="end">$1.000.000</text>
<text x="80" y="400" class="axis-label-es" text-anchor="middle">1M</text><text x="212" y="400" class="axis-label-es" text-anchor="middle">10M</text><text x="344" y="400" class="axis-label-es" text-anchor="middle">100M</text><text x="476" y="400" class="axis-label-es" text-anchor="middle">1B</text><text x="608" y="400" class="axis-label-es" text-anchor="middle">10B</text>
<text x="400" y="420" class="title-text-es" text-anchor="middle">Volumen mensual de tokens (escala log)</text>
<line x1="80" y1="60" x2="80" y2="380" class="axis-line-es"/><line x1="80" y1="380" x2="740" y2="380" class="axis-line-es"/>
<polyline points="80,420 212,366 344,286 476,206 608,126" fill="none" stroke="#b8941f" stroke-width="2.5"/>
<text x="615" y="120" class="legend-text-es" fill="#b8941f">Claude Opus 4.7 API</text>
<text x="615" y="132" class="annotation-es" fill="#b8941f">$15 por 1M tokens</text>
<polyline points="80,572 212,508 344,412 476,332 608,252" fill="none" stroke="#3a6090" stroke-width="2.5" stroke-dasharray="4 3"/>
<text x="615" y="246" class="legend-text-es" fill="#3a6090">Mistral La Plateforme API</text>
<text x="615" y="258" class="annotation-es" fill="#3a6090">$0,40 por 1M tokens</text>
<polyline points="80,266 740,266" fill="none" stroke="#1a2e4d" stroke-width="2.5"/>
<text x="86" y="258" class="legend-text-es" fill="#1a2e4d">Mistral Small 3.2 self-host (~$2.700/mes plano)</text>
<polyline points="80,256 740,256" fill="none" stroke="#5a8a5a" stroke-width="2.5" stroke-dasharray="6 4"/>
<text x="86" y="248" class="legend-text-es" fill="#5a8a5a">gpt-oss-120b self-host (~$3.200/mes plano)</text>
<circle cx="377" cy="266" r="6" class="crossover-marker-es"/>
<text x="377" y="248" class="annotation-es" text-anchor="middle">Cruce ~180M tok/mes</text>
<text x="377" y="284" class="annotation-es" text-anchor="middle">Mistral OSS vs Opus API</text>
<text x="400" y="455" class="annotation-es" text-anchor="middle">Hosting: proveedores GPU UE (Scaleway, OVHcloud) - valores ilustrativos, no contractuales</text>
</svg>
<figcaption class="text-sm text-gosign-text-light text-center mt-4 max-w-2xl mx-auto">
<strong>Punto de cruce TCO: self-hosted vs API cloud</strong> - curvas API cloud lineales (precio por token) frente a curvas self-host planas (CAPEX amortizado). Mistral La Plateforme API permanece la más barata por debajo de ~10B tokens/mes - la decisión relevante es Mistral OSS self-host vs Claude Opus 4.7 API, que se cruza para cargas críticas de soberanía en torno a 180 millones de tokens mensuales. Por debajo de 50M tokens/mes domina la economía cloud-API. Por encima de 500M tokens/mes domina self-host independientemente.
</figcaption>
</figure>

## Hosting GPU UE en 2026: quién tiene realmente capacidad H100?

El mercado de hosting GPU UE maduró significativamente en 2025-2026. Tres proveedores cubren la mayoría de casos de uso enterprise de autohospedaje:

**Scaleway** (Francia, RGPD nativo). El más agresivo en precio-rendimiento para cargas IA. H100 SXM a ~3,50 EUR/h, A100 a ~2,50 EUR/h, más la nueva NVIDIA Blackwell B300-SXM (288 GB VRAM) para cargas frontier. Centros de datos franceses, cumplimiento total RGPD, sin exposición al CLOUD Act. Contratos de instancia reservada disponibles para cargas predecibles.

**OVHcloud** (Francia, tier soberano). El mayor proveedor cloud europeo, con un tier "Sovereign Cloud" construido explícitamente para uso gubernamental y de sectores regulados. Cartera incluye H100, RTX 5000, A10, más servicio "AI Deploy" para notebook e inferencia pay-as-you-go. Buen encaje cuando compras exige firma de cloud soberano.

**Hetzner** (Alemania). El líder en coste para servidores GPU dedicados, no instancias bajo demanda. Opciones GPU actuales incluyen RTX 4000 SFF Ada y RTX 6000 Ada emparejadas con CPUs modernas. El camino para Mistral Small 3.2 con cuantización o para entornos de desarrollo. Menos apto para escalado elástico pico.

Para sectores regulados (servicios financieros bajo CNMV, sanidad, AAPP bajo ENS) con requisitos estrictos de soberanía:

**Telefónica Tech** (España). Aragón data center Calatorao (~3 B EUR investment 2025), CCN-STIC 884 certificado para ENS Categoría Alta, partner AWS Sovereign Cloud España (joint announcement 2025). Para empresas IBEX-35 con requisitos AAPP-ready. Encaje natural para empresas españolas que prefieren un proveedor doméstico con presencia local y contratos en español.

**IONOS** (Alemania). Hosting clase cloud soberano con instancias GPU. El encaje de cumplimiento para cargas bajo supervisión financiera.

**T-Systems** (Alemania). Filial de Deutsche Telekom. Cloud soberano explícitamente diseñado para clientes de sector público e infraestructura crítica. La opción cómoda para compras cuando la soberanía a nivel consejo es el requisito.

Para clientes AAPP bajo ENS Categoría Alta (Real Decreto 311/2022 que reemplaza RD 3/2010): CCN-STIC 884 establece controles cloud específicos. Telefónica Tech tiene Aragón data center Calatorao certificado para ENS Alta. OVHcloud Sovereign tier es SecNumCloud (equivalente francés ANSSI). T-Systems Sovereign Cloud tiene C5 Type 2 (BSI alemán). Scaleway tiene HDS para Sanidad. Para uso por SEPE, Hacienda, MUFACE en categoría Alta, estos certificaciones son obligatorias.

Para una empresa que decide un stack autohospedado, la secuencia práctica es: piloto sobre Scaleway o Hetzner para validación eficiente en coste, paso a OVHcloud, Telefónica Tech o T-Systems para producción si la firma regulatoria exige certificación cloud soberano, retener contratos de instancia reservada para controlar predictibilidad de coste.

## Patrones de despliegue: worker único, clúster, híbrido

Tres patrones de despliegue cubren casi todos los escenarios enterprise de autohospedaje.

**Patrón worker único.** Un modelo, una instancia GPU, desplegado tras un balanceador de carga con health checks. Apto para: Mistral Small 3.2 sobre RTX 4090 o H100 para la carga de volumen del 70%. Llama 4 Scout sobre GPU única para análisis de documentos de contexto largo. Complejidad operacional: baja. Modo de fallo: punto único de fallo si no se replica.

**Patrón clúster multi-modelo.** Múltiples modelos sobre múltiples GPUs tras una capa de enrutado. Apto para: Mistral Small para volumen + gpt-oss-120b o DeepSeek V4-Flash para razonamiento pesado + (opcional) DeepSeek V4-Pro sobre clúster dedicado para cargas grado matemático, todo tras una única capa de enrutado. La capa de enrutado decide por petición qué modelo la atiende. Complejidad operacional: media. Requiere un model server (vLLM, TGI, llama.cpp-server) y un motor de reglas de enrutado. Este es el patrón de producción típico para cargas agénticas con complejidad de decisión mixta.

**Patrón híbrido edge-cloud.** Cargas sensibles (onboarding de RRHH, revisión de contratos, extracción de datos de cliente) sobre modelos autohospedados; cargas no sensibles (generación de copy de marketing, Q&A sobre base de conocimiento de información pública) sobre APIs cloud UE como Mistral La Plateforme. La capa de enrutado fuerza la clasificación de datos antes de la selección de modelo. Complejidad operacional: alta (dos stacks que mantener) pero la menor exposición de soberanía y el mejor ratio coste-por-decisión.

La elección de patrón depende de la taxonomía de clasificación de datos, no de la selección de modelo. Si todo está clasificado como "interno" o superior, el patrón clúster multi-modelo domina. Si un porcentaje significativo del trabajo es sobre datos públicos o no sensibles, el patrón híbrido es más barato.

## Matriz de decisión: qué modelo para qué carga

| Categoría de carga | Modelo recomendado | Por qué |
|---|---|---|
| Clasificación de documentos, extracción estructurada, parseo de campos OCR-corregidos | Mistral Small 3.2 (self-hosted) | Capacidad visual, rápido en GPU consumo, cobertura multilingüe |
| Generación de texto estándar (correos, notificaciones, recordatorios de NDA) | Mistral Small 3.2 (self-hosted) | Alto throughput, amigable con plantillas |
| Clasificación de cláusulas contractuales, banderas de riesgo de proveedor, detección de anomalías | Mistral Small 3.2 (self-hosted) o Mistral Medium 3.1 (La Plateforme) | Razonamiento medio a bajo coste |
| Análisis de no discriminación bajo Ley 15/2022, razonamiento complejo transestatutario | gpt-oss-120b on-prem (o Claude Opus 4.7 cloud) | Razonamiento nivel o4-mini bajo licencia Apache 2.0 |
| Modelado de riesgo financiero, stress testing, problemas de optimización | DeepSeek V4-Flash (actual) o V4-Pro vía API/hosted (si el hardware lo permite); R1 sigue viable para despliegues maduros | Liderazgo en benchmarks mate/lógica, la línea V4 añade contexto 1M para análisis cross-portfolio |
| Análisis documental de corpus grandes (carteras de contratos completas, informes anuales completos) | Llama 4 Scout (self-hosted) | Ventana de contexto de 10M tokens |
| Multimodal (correlación imagen-texto, revisión de planos técnicos) | Gemini 3.1 Pro (solo cloud - ningún equivalente autohospedado iguala) | Entrenamiento multimodal nativo |
| Generación de código, revisión de código (cloud flagships) | Claude Opus 4.7 o GPT-5.5 | Ambos líderes en benchmarks de código; Claude Opus 4.7 más fuerte en loops agénticos largos (Claude Code), GPT-5.5 más fuerte en integración IDE (Cursor, Copilot) |
| Generación de código, revisión de código (self-hosted) | Qwen 3 Coder 110B (Apache 2.0, Alibaba), DeepSeek Coder V4 (MIT) o Codestral Mamba 32B (Mistral, EU-built) | Benchmarks de coding top-tier on-prem; Qwen 3 Coder líder HumanEval/SWE-Bench entre OSS, DeepSeek Coder V4 más fuerte en agentic Multi-File-Tasks, Codestral Mamba latencia más baja en GPU de consumo |
| Stack nativo Microsoft 365 | GPT-5.5 vía Azure OpenAI | Stack nativo, menor esfuerzo de integración para organizaciones en el data plane de Microsoft |
| Workflows agénticos, orquestación de herramientas | GPT-5.5 o Claude Opus 4.7 | Ambos top-tier en outputs estructurados y orquestación de herramientas; GPT-5.5 con ecosistema más amplio de pre-built tools |
| SaaS Feature Gating (producto multi-tier) | Patrón híbrido: Mistral Small (self-hosted) + Claude Opus 4.7 / GPT-5.5 (cloud) | Datos sensibles de cliente self-hosted, premium features en cloud flagship |
| IA conversacional / chatbots cara al cliente | Mistral Small 3.2 (self-hosted) para volumen; GPT-5.5 (Azure) cuando stack MS-nativo | Calidad grado producción al menor coste hardware; Azure-Path cuando la integración con Microsoft 365 es prioritaria |

La matriz no es una prescripción. Es un punto de partida que se refina por organización. Una empresa con peso en finanzas pondera DeepSeek V4 más alto. Una operación con peso multimedia puede necesitar un salto a Gemini cloud. Una pipeline RRHH con alto volumen documental sitúa Mistral Small en el 80% de las decisiones, no en el 70%.

La capa de enrutado hace operacional la matriz. Sin ella, cada carga corre contra el modelo configurado por defecto, y la matriz se convierte en un artefacto de slideware.

## Construyendo la capa de enrutado: dónde encaja el Decision Layer

Las arquitecturas autohospedadas multi-modelo se rompen sin capa de enrutado por una razón simple: ningún operador humano quiere recordar 14 mapeos decisión-a-modelo mientras además escribe la lógica de negocio del agente. El enrutado tiene que ser configuración, no código.

Un Decision Layer contiene:

- La taxonomía de clasificación de datos (qué tipos de dato requieren autohospedaje? Cuáles pueden enrutarse a EU-cloud-API? Cuáles a US-cloud-API?)
- Las reglas de enrutado decisión-a-modelo por paso de workflow
- La cadena de fallback (si Mistral Small falla o se satura, enrutar a qué alternativa?)
- El log de auditoría: cada decisión registrada con snapshot de entrada, versión de regla, modelo usado, nivel de confianza, cadena de razonamiento, resultado y aprobador humano cuando aplica
- El botón de impugnación: cualquier persona afectada puede impugnar una decisión automatizada, lo que dispara una redecisión bajo revisión humana - el mecanismo exigido por el art. 22 RGPD

Este es el artefacto que un auditor del artículo 13 del EU AI Act inspecciona. Es el artefacto que un Comité de Empresa revisa al clasificar qué agentes caen bajo el derecho de información del art. 64 del Estatuto de los Trabajadores. Es el artefacto que satisface la pregunta de compras "qué pasa cuando tu vendor IA cambia de modelo?" - porque cambia la regla de enrutado, no la lógica de negocio.

Construir esta capa internamente es factible pero raramente más rápido que 6-9 meses para un equipo enterprise empezando desde cero. Comprarla como framework de configuración típicamente acorta el camino a 4-6 semanas para el primer agente en producción.

## En resumen

La IA open source autohospedada es una opción de producción creíble para Enterprise UE en 2026 - pero solo como arquitectura multi-modelo con una capa de enrutado, no como apuesta de un único modelo. Mistral Small 3.2 cubre la banda de volumen. gpt-oss-120b o DeepSeek V4-Flash cubren razonamiento pesado on-prem. DeepSeek V4-Pro (actualmente en preview) se acerca al territorio de Claude Opus si dispones de hardware clase hyperscaler - o esperas al release GA y lo usas vía API mientras tanto. Llama 4 Scout cubre contexto ultralargo. El tier cloud-API (Claude Opus 4.7, GPT-5.5, Gemini 3.1 Pro) queda disponible para las cargas donde el marco regulatorio lo permite.

La decisión de enrutado es la arquitectura. El cruce TCO (alrededor de 50-100 millones de tokens al mes sostenidos) marca el umbral económico del autohospedaje. La taxonomía de cumplimiento (qué clasificación de datos no puede salir de la red) marca el umbral de soberanía. Ambos umbrales dan forma a las reglas de enrutado.

Otros publican rankings. Nosotros construimos la capa de enrutado que los operacionaliza. El mercado de modelos cambia cada mes; la arquitectura de enrutado sobrevive a cinco generaciones de modelos. El código fuente queda con el cliente. Los modelos siguen intercambiables. El cumplimiento del artículo 13 del EU AI Act es una propiedad de la arquitectura, no un proyecto al final.

Si quieres saber cómo debería verse tu stack autohospedado basado en tu mezcla real de cargas y clasificación de datos, [reserva una consulta](/es/contacto/).

--- Enterprise AI-Infraestructura Blueprint 2026 ---
> Ocho decisiones estratégicas para tu infraestructura de IA. Modelos, hosting, interfaces, agentes, orquestación, governance, costes, regulación.

## Por qué este Blueprint

La integración de IA en los procesos empresariales ha pasado de ser un proyecto de innovación a una necesidad operativa. Quien en 2026 no tenga un plan concreto, no solo se queda atrás frente a la competencia: se queda fuera del mercado. Al mismo tiempo, el panorama de decisiones se ha vuelto más complejo: más modelos, más opciones de hosting, más regulación, más plataformas de orquestación.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">De un vistazo - Infraestructura AI Enterprise 2026</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Ocho decisiones estratégicas que todo CTO o CIO debe tomar en 90 días para desplegar IA a escala enterprise.</li>
<li>Selección de modelo, nivel de hosting, portal AI, RAG, agentes, Decision Layer, compliance y orquestación forman el stack completo.</li>
<li>La arquitectura híbrida de hosting - enrutamiento por sensibilidad de datos entre cloud, IaaS europeo y on-premises - se ha convertido en el estándar.</li>
<li>IDC (2025) proyecta un gasto mundial en infraestructura de IA de 154.000 millones de USD para 2027, frente a 76.000 millones en 2024.</li>
<li>Una hoja de ruta concreta de 90 días transforma proyectos piloto en infraestructura productiva con governance integrada desde el inicio.</li>
</ul>
</div>

Este Blueprint reduce esa complejidad a ocho decisiones concretas que todo líder técnico debe tomar en los próximos 90 días.

Cada una de estas decisiones se trata en detalle en un artículo propio, con tablas comparativas, árboles de decisión y recomendaciones prácticas. Sin marketing, sin buzzwords. Hechos, arquitectura, guía de acción.

## Las ocho decisiones

### Decisión 1: ¿Qué modelo de IA se adapta a tu caso de uso?

El panorama de modelos ha cambiado fundamentalmente desde 2024. Claude, GPT-5, Gemini 3, Llama 4, gpt-oss, DeepSeek: las diferencias ya no están en la calidad, sino en la especialización, la protección de datos y la estructura de costes. La respuesta correcta no es un modelo, sino una arquitectura model-agnostic que enrute cada tarea al modelo más adecuado.

**[Leer: Modelos de IA 2026 - ¿Qué modelo para qué uso?](/es/revista/modelos-ia-comparacion-2026/)**

### Decisión 2: ¿Dónde se ejecutan tus modelos de IA?

EU-SaaS, centro de datos europeo o Self-Hosted: esta decisión determina tus garantías de protección de datos, tu estructura de costes y tu dependencia de proveedores externos. La estrategia híbrida, en la que una capa de enrutamiento distribuye automáticamente las solicitudes según la sensibilidad de los datos, se ha consolidado como estándar.

**[Leer: Hosting de IA - EU-SaaS, centro de datos en la UE o Self-Hosted](/es/revista/hosting-ia-estrategias-enterprise/)**

Una vez tomada la decisión de hosting, siguen las garantías contractuales. Un contrato estándar de encargado no es suficiente para infraestructura IA - [nuestro checklist de requisitos](/es/revista/contrato-encargado-ia-checklist/) identifica las diez brechas y proporciona 25 preguntas de verificación para legal y compliance.

### Decisión 3: ¿Cómo hacer la IA accesible a todos sin perder el control?

Un modelo de lenguaje sin un interfaz controlado es como un servidor sin frontend. Los empleados recurren entonces a servicios de IA públicos, sin control, sin registro, sin cumplimiento del RGPD. Un Enterprise AI Portal ofrece la mejor alternativa: Multi-Model-Routing, compartición de asistentes, integración de agentes, SSO y Audit Trail completo.

> **Artículo 3: Enterprise AI Portales** - Cinco interfaces open-source en comparación: LobeChat, OpenWebUI, LibreChat, chatbot-ui y very-ai. ¿Qué portal tiene SSO, protección PII y Audit Trail? (Nota de transparencia: very-ai está desarrollado por Gosign.)

**[Leer: Enterprise AI Portales - Cinco interfaces open-source en comparación](/es/revista/enterprise-ai-chat-interface/)**

### Decisión 4: ¿Cómo hacer el conocimiento corporativo accesible para la IA?

RAG (Retrieval Augmented Generation) permite buscar en tus documentos sin enviar datos a proveedores de modelos. Document Intelligence va más allá: anonimización PII, enmascaramiento de contratos, verificación automática de compliance.

**[Leer: RAG y Document Intelligence - Cómo la IA entiende tus documentos](/es/revista/rag-document-intelligence-enterprise/)**

### Decisión 5: ¿Cómo convertir chatbots en agentes reales?

El paso de un interfaz de chat a procesos autónomos que procesan documentos, operan sistemas y preparan decisiones requiere una arquitectura diferente. Los protocolos MCP y A2A, los sistemas multi-agente y los requisitos claros de governance determinan el éxito.

**[Leer: De chatbots a AI-agentes - MCP, A2A y sistemas multi-agente](/es/revista/agentes-ia-enterprise-guia/)**

### Decisión 6: ¿Cómo separar análisis de decisión?

El Decision Layer descompone los procesos de negocio en micro-decisiones y define para cada una: humano, motor de reglas o IA. Es la arquitectura que convence al comité de empresa, satisface a los auditores y permite escalar.

**[Leer: Decision Layer y Shadow AI - control en lugar de pérdida de control](/es/revista/decision-layer-shadow-ai/)**

### Decisión 7: ¿Qué exige el EU AI Act - ahora, no en el futuro?

La cuenta atrás ya corre. Desde febrero de 2025 se aplican las primeras prohibiciones y la obligación de AI-Literacy. La clasificación de alto riesgo se mantiene; conforme a la legislación vigente, las obligaciones de alto riesgo entran en vigor en agosto de 2026, con un aplazamiento a diciembre de 2027 acordado provisionalmente por el Digital Omnibus (mayo de 2026, adopción formal aún pendiente). El incumplimiento de las obligaciones de alto riesgo puede acarrear multas de hasta 35 millones de euros o el 7% de la facturación anual, así que conviene usar el tiempo para prepararse, llegue el plazo en agosto de 2026 o en diciembre de 2027. Para las empresas españolas, estas regulaciones europeas se aplican directamente junto con la normativa nacional.

**[Leer: EU AI Act 2026 - Qué aplica, qué viene, qué debes hacer](/es/revista/eu-ai-act-2026-empresas/)**

### Decisión 8: ¿En qué plataforma orquestas tus agentes?

n8n para prototipos rápidos, Camunda para procesos que requieren compliance, Temporal para workflows complejos de larga duración: la plataforma de orquestación determina si tu arquitectura de agentes escala o se queda atascada en el PoC.

**[Leer: Orquestación de agentes - n8n, Camunda y alternativas](/es/revista/orquestacion-agentes-plataformas/)**

## Las ocho decisiones de un vistazo

<table>
<thead>
<tr><th>Decisión</th><th>Tema</th><th>Pregunta clave</th></tr>
</thead>
<tbody>
<tr><td>1</td><td>Selección de modelo IA</td><td>Qué modelo para qué tarea? Routing model-agnostic.</td></tr>
<tr><td>2</td><td>Estrategia de hosting</td><td>EU SaaS, centro de datos europeo o Self-Hosted?</td></tr>
<tr><td>3</td><td>Enterprise AI Portal</td><td>Interfaz controlada con SSO, Audit Trail, protección PII.</td></tr>
<tr><td>4</td><td>RAG & Document Intelligence</td><td>Cómo hacer el conocimiento corporativo accesible para IA?</td></tr>
<tr><td>5</td><td>AI Agents</td><td>De chatbot a agente autónomo multi-paso.</td></tr>
<tr><td>6</td><td>Decision Layer</td><td>Separar análisis IA de decisiones de negocio.</td></tr>
<tr><td>7</td><td>Costes y EU AI Act</td><td>TCO y obligaciones regulatorias desde agosto 2025.</td></tr>
<tr><td>8</td><td>Orquestación de agentes</td><td>n8n, Camunda o Temporal para workflows productivos.</td></tr>
</tbody>
</table>

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">eBook gratuito: Infraestructura de IA</p>
<p class="text-body text-gosign-text mb-4">Build, Buy, Hybrid - infraestructura conforme al EU AI Act con B/B/H-Framework y 7-Layer Reference Architecture.</p>
<a href="/es/ebook/ia-infraestructura-manual-gobernanza/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Descargar gratis</a>
</div>

## Para quién está escrito este Blueprint

Este Blueprint está dirigido a responsables técnicos en empresas de más de 500 empleados:

- **CTOs y VP Engineering**, que necesitan construir o consolidar una arquitectura de IA
- **CIOs**, que deben alinear la estrategia de IA con la governance de TI y el ecosistema tecnológico existente
- **Directores de RRHH y COOs**, que integran IA en procesos operativos - desde el procesamiento de documentos hasta la gestión del conocimiento
- **Ejecutivos C-Level con perfil técnico**, que quieren tomar decisiones fundamentadas en lugar de acumular proyectos piloto

El Blueprint asume que has superado la fase de experimentación. La pregunta ya no es si desplegar IA, sino cómo - con qué arquitectura, qué [governance](/es/governance/) y qué estrategia operativa.

## Plan de acción a 90 días

El Blueprint culmina en un plan de acción concreto con tres fases:

### Fase 1: Fundamentos (Semanas 1--4)

- Crear un inventario de sistemas de IA (¿qué se está usando ya?)
- Realizar la clasificación de datos
- Identificar un caso de uso (mayor ROI con menor riesgo)
- Tomar la decisión de hosting (nivel 1, 2 o 3)
- Desplegar un portal AI interno (LobeChat, OpenWebUI, very-ai o LibreChat)

La capa de presentación - el Enterprise AI Portal - tiene cinco opciones open-source en 2026. Gosign ha desarrollado very-ai, un portal que añade protección PII y sincronización de grupos Entra ID como funcionalidades enterprise (-> Artículo 3). Como en todas las recomendaciones de esta serie: evalúa varias opciones para tu contexto específico.

Resultado: tus empleados tienen una herramienta de IA controlada en lugar de Shadow AI.

### Fase 2: Primer agente (Semanas 5--8)

- Implementar el caso de uso como agente
- Conectar vía MCP a 1--2 sistemas existentes
- Definir las reglas de decisión
- Establecer Human-in-the-Loop para los pasos críticos
- Definir un grupo piloto de 10--20 usuarios

Resultado: un agente funcional que mejora un proceso de negocio real.

### Fase 3: Governance y escalado (Semanas 9--12)

- Validar el Audit Trail y el logging
- Iniciar la documentación del EU AI Act (evaluación de riesgos, documentación técnica)
- Medir los resultados del piloto (ahorro de tiempo, tasa de error, satisfacción del usuario)
- Crear un plan de escalado: ¿qué 3--5 casos de uso son los siguientes?

Resultado: un business case validado y una ruta clara hacia el escalado.

El plan es deliberadamente compacto. En 90 días no lograrás una transformación completa de IA, pero tendrás una infraestructura productiva, un agente en funcionamiento y las bases de governance para escalar con seguridad.

---

**Más información:** [Infraestructura de IA - resumen de servicios](/es/servicios/infraestructura/) | [Decision Layer - explicación](/es/decision-layer/) | [AI Agents](/es/servicios/ai-agents/)

---

**Enterprise AI-Infraestructura Blueprint 2026 - Serie de artículos**

| Anterior | Vista general | Siguiente |
|:---|:---:|---:|
| - | Estás en la vista general | [Modelos de IA 2026: ¿Qué modelo para qué uso?](/es/revista/modelos-ia-comparacion-2026/) |

*Todos los artículos de esta serie: [Enterprise AI-Infraestructura Blueprint 2026](/es/revista/infraestructura-ia-blueprint-2026/)*

---

**¿Prefieres no tomar estas ocho decisiones solo?** Gosign acompaña a clientes enterprise desde la arquitectura hasta la operación productiva - model-agnostic, independiente de fabricantes, con acceso completo al código fuente.

<a href="/es/contacto/" target="_blank" rel="noopener noreferrer">Reservar consulta</a>. 30 minutos en los que analizamos tus necesidades concretas.

--- Infraestructura IA, no sensación de herramienta ---
> Herramientas IA vs. infraestructura IA: orquestación, gobernanza, modelo-agnóstico, Audit Trail. Por qué las empresas necesitan su propia capa.

## Herramienta vs. infraestructura

ChatGPT, Microsoft CoPilot, Google Gemini: son herramientas de IA. Se introduce una pregunta, se obtiene una respuesta. Para la productividad individual, funciona. Para procesos empresariales, no.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">De un vistazo - Infraestructura IA vs. hype de herramientas</p>
<ul class="text-body text-gosign-text space-y-2">
<li>ChatGPT, CoPilot y Gemini son herramientas de IA - no infraestructura enterprise. Carecen de Audit Trail, aislamiento de inquilinos e integración con sistemas.</li>
<li>La infraestructura IA enterprise consta de siete capas: Presentation, Orchestration, Agent, Decision, Model, Integration e Infrastructure.</li>
<li>Gartner (2024) informa que más del 55% de las organizaciones que desplegaron herramientas de IA sin governance tuvieron que reconstruir su enfoque en 18 meses.</li>
<li>Una arquitectura model-agnostic previene el vendor lock-in y mantiene los modelos intercambiables - Claude, GPT, Gemini, Llama, Mistral.</li>
<li>Tras 12 a 18 meses, el cliente opera la infraestructura de forma autónoma con acceso completo al código fuente y sin dependencia recurrente del proveedor.</li>
</ul>
</div>

La diferencia entre una herramienta de IA y una infraestructura de IA es comparable a la diferencia entre una hoja de cálculo y un sistema ERP. La hoja de cálculo resuelve un problema concreto para un usuario individual. El sistema ERP es la infraestructura sobre la que funcionan los procesos de negocio de toda la empresa.

La infraestructura de IA es la capa arquitectónica entre el modelo de lenguaje y el sistema empresarial. Abarca: hosting de modelos, orquestación, Decision Layer, gobernanza, integración con sistemas existentes. El modelo de lenguaje es un componente de esta infraestructura, no la infraestructura en sí.

## Lo que le falta a una herramienta de IA

Cuando una empresa utiliza ChatGPT para el procesamiento de facturas, falta:

**Audit Trail:** Sin documentación de qué decisión se tomó sobre qué base. En una auditoría, nada es trazable.

**Conjuntos de reglas versionados:** ChatGPT no conoce reglas de contabilidad específicas del cliente en versión 4.2. Tiene conocimiento general sobre contabilidad, pero no los conjuntos de reglas concretos del cliente adaptados al Plan General de Contabilidad.

**Aislamiento de inquilinos:** Los datos de todos los inquilinos fluyen al mismo sistema. Sin Row-Level Security, sin separación de workspaces.

**Integración:** ChatGPT no puede crear un asiento en SAP, disparar un flujo de trabajo en [Trigger.dev](https://trigger.dev/) ni escalar un caso a un gestor.

**Human-in-the-Loop:** Sin revisión humana impuesta arquitectónicamente. Sin reglas de escalación. Sin umbrales de confianza.

**Modelo-agnóstico:** Quien construye sobre ChatGPT queda vinculado a OpenAI. Si OpenAI sube los precios, cambia la API o interrumpe el servicio, la empresa se queda sin alternativa.

## Las siete capas de la infraestructura de IA empresarial

La arquitectura de referencia de Gosign describe siete capas:

**Presentation Layer:** Interfaz de chat, dashboard, Portal del Auditor, REST API. La interfaz entre el sistema y el usuario.

**Orchestration Layer:** Motor de flujos de trabajo (Trigger.dev o [Camunda](https://camunda.com/)), API Gateway, gestión de colas. Coordina el flujo de datos entre todos los componentes.

**Agent Layer:** Los agentes especializados: Document Agents, Workflow Agents, Knowledge Agents. Cada agente tiene un ámbito de responsabilidad definido.

**Decision Layer:** Descompone cada proceso en pasos de decisión. Para cada paso define: persona, conjunto de reglas o IA. Incluye Rules Engine (conjuntos de reglas versionados), Confidence Routing (evaluación automática de riesgos), Human-in-the-Loop (impuesto técnicamente) y Audit Trail (protocolo de decisiones inmutable).

**Model Layer:** Los modelos de lenguaje. Intercambiables, modelo-agnósticos. Claude, ChatGPT, Gemini, Llama, Mistral, DeepSeek, gpt-oss.

**Integration Layer:** La conexión con sistemas existentes. SAP, [Sage](https://www.sage.com/es-es/), [Workday](https://www.workday.com/), [SuccessFactors](https://www.sap.com/products/hcm.html), SharePoint.

**Infrastructure Layer:** El despliegue. Azure, GCP, Self-Hosted, híbrido.

La capa de Governance se extiende como componente transversal a través de las siete capas.

## Herramienta de IA vs. infraestructura de IA

<table>
<thead>
<tr><th>Capacidad</th><th>Herramienta IA (ChatGPT)</th><th>Infraestructura IA</th></tr>
</thead>
<tbody>
<tr><td>Audit Trail</td><td>No</td><td>Protocolo de decisiones inmutable</td></tr>
<tr><td>Aislamiento de inquilinos</td><td>No</td><td>Row-Level Security, separación de workspaces</td></tr>
<tr><td>Integración ERP</td><td>No</td><td>SAP, Sage, Workday vía APIs</td></tr>
<tr><td>Reglas versionadas</td><td>No</td><td>Específicas por cliente, versionadas</td></tr>
<tr><td>Human-in-the-Loop</td><td>No</td><td>Impuesto arquitectónicamente</td></tr>
<tr><td>Independencia de modelo</td><td>Vinculado a un proveedor</td><td>Routing model-agnostic</td></tr>
<tr><td>Capa de governance</td><td>No disponible</td><td>Transversal a todas las capas</td></tr>
</tbody>
</table>

## La ventaja de la infraestructura

Con una infraestructura de IA propia, la empresa obtiene:

**Control:** Los datos permanecen en la infraestructura propia. Los modelos son intercambiables. Acceso completo a los conjuntos de reglas y configuraciones. Esto es especialmente relevante en España, donde el RGPD y la LOPDGDD (Ley Orgánica 3/2018) imponen requisitos estrictos de protección de datos.

**Escalabilidad:** Un agente para un proceso es un PoC. La infraestructura permite desplegar agentes adicionales para procesos adicionales, con la misma gobernanza.

**Independencia:** Tras 12-18 meses, el cliente opera la infraestructura de forma autónoma. Acceso completo al código fuente, todos los prompts y conjuntos de reglas. Sin vendor lock-in.

Más sobre este tema: [Infraestructura de IA](/es/servicios/infraestructura/)

Más sobre servicios: [Servicios](/es/servicios/)

<a href="/es/contacto/" target="_blank" rel="noopener noreferrer">Agendar reunión</a>. Le mostramos cómo es una infraestructura de IA para su empresa.

--- Integrar infraestructura IA en el panorama IT existente ---
> Cómo agentes IA y LLMs se integran en entornos SAP, Workday y cloud sin greenfield, sin Shadow IT, sin migración de plataforma.

## El problema de la integración

La mayoría de las empresas no tienen un panorama IT vacío. Tienen SAP, [Workday](https://www.workday.com/), [SuccessFactors](https://www.sap.com/products/hcm.html), SharePoint, sistemas sectoriales, middleware acumulado a lo largo de los años y arquitecturas de seguridad consolidadas. Esto no es un obstáculo para la IA: es la realidad en la que la IA debe encajar.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">De un vistazo - Integración de IA en IT existente</p>
<ul class="text-body text-gosign-text space-y-2">
<li>La infraestructura IA es una capa de integración sobre los sistemas existentes - SAP, Workday y entornos cloud permanecen inalterados.</li>
<li>Cuatro capas arquitectónicas: conectividad con sistemas, orquestación, Decision Layer e interfaz de usuario.</li>
<li>Los agentes se comunican a través de APIs estándar (RFC, OData, REST) - sin acceso directo a bases de datos, sin interfaces propietarias.</li>
<li>McKinsey (2024) informa que el 74% de los proyectos de IA enterprise no superan la fase piloto, principalmente por brechas de integración.</li>
<li>Las políticas de seguridad, autenticación y procesos de auditoría existentes siguen plenamente vigentes - el agente es un participante adicional, no un sistema paralelo.</li>
</ul>
</div>

La causa más frecuente de fracaso de los proyectos de IA en empresas no es la tecnología. Es que la IA se introduce como un sistema aislado, al lado del IT existente, no dentro de él. Esto genera Shadow IT, silos de datos y brechas de gobernanza.

El enfoque correcto: infraestructura IA como capa de integración que conecta los sistemas existentes en lugar de sustituirlos.


## Principio arquitectónico: capa de integración, no migración de plataforma

Una infraestructura IA empresarial consta de cuatro capas que encajan en cualquier panorama IT existente.

La capa más baja es la conectividad con sistemas. Conectores a SAP (vía RFC, OData, BAPIs), a Workday (vía REST APIs), a SharePoint, sistemas de correo y aplicaciones sectoriales. Estos conectores leen y escriben datos; los sistemas origen permanecen inalterados.

Por encima se encuentra la capa de orquestación. Aquí operan los [agentes IA](/es/servicios/ai-agents/): Document Agents que leen y clasifican documentos entrantes. Workflow Agents que gestionan procesos entre sistemas. Knowledge Agents que responden preguntas basándose en el conocimiento corporativo.

La tercera capa es el [Decision Layer](/es/decision-layer/). Separa el análisis IA de la decisión de negocio. El modelo recomienda, el humano decide. Cada decisión se documenta, versiona y es auditable.

La capa superior es la interfaz: una interfaz de chat unificada para empleados o integración directa sistema-a-sistema sin interacción humana.


## En la práctica: cómo un agente IA se integra en un entorno SAP

Un ejemplo real: procesamiento de bajas por enfermedad.

El empleado envía la baja médica por correo electrónico o a través de un portal. Un Document Agent identifica el tipo de documento, extrae los campos relevantes (nombre, periodo, grupo de diagnóstico) y valida los datos contra el convenio colectivo. A través del conector SAP, consulta los datos maestros de personal, calcula la prestación por incapacidad temporal y prepara el asiento contable.

En este punto interviene el Decision Layer: si el caso se encuentra dentro de las reglas automatizables (caso estándar, sin anomalías), el asiento se presenta al responsable para su aprobación. Si se detecta una anomalía (frecuencia, incumplimiento de plazos, datos incompletos), se escala.

La instancia SAP no fue modificada en ningún momento. El agente opera como capa de integración externa que se comunica a través de APIs estándar. Los conceptos de autorización, zonas de red y procesos de auditoría existentes permanecen sin cambios.


## Qué debe ofrecer la arquitectura IT

Para una integración limpia, la infraestructura IA requiere cuatro propiedades.

Primero: API-first. Toda la comunicación entre agente y sistema origen se realiza a través de APIs documentadas. Sin accesos directos a bases de datos, sin interfaces propietarias.

Segundo: multi-tenancy. En estructuras corporativas, los agentes deben ser configurables por entidad: diferentes reglas, diferentes sistemas, diferentes requisitos de compliance por filial.

Tercero: logging y auditoría. Cada interacción entre agente y sistema origen se registra: quién leyó, escribió o decidió qué, y cuándo. Esto no es opcional; es la base de [Governance by Design](/es/governance/).

Cuarto: capacidad de rollback. Si un agente comete un error, cada acción debe ser reversible. Esto exige comunicación transaccional con los sistemas origen.


## Resumen de capas de integración

<table>
<thead>
<tr><th>Capa</th><th>Función</th><th>Tecnología</th></tr>
</thead>
<tbody>
<tr><td>Conectividad</td><td>Lectura/escritura en sistemas origen</td><td>SAP RFC/OData, Workday REST, Microsoft Graph</td></tr>
<tr><td>Orquestación</td><td>Coordinar agentes y workflows</td><td>Trigger.dev, Camunda, n8n</td></tr>
<tr><td>Decision Layer</td><td>Separar análisis IA de decisiones de negocio</td><td>Rules Engine, Confidence Routing, Human-in-the-Loop</td></tr>
<tr><td>Interfaz</td><td>Acceso empleados o sistema-a-sistema</td><td>Enterprise AI Portal, REST API</td></tr>
</tbody>
</table>

## Ni greenfield ni migración de plataforma

La objeción más frecuente de los CIOs: "No podemos introducir otro sistema más." Y esa objeción es legítima.

Por eso la infraestructura IA no es un nuevo sistema en el sentido tradicional. Es una capa que encaja en la arquitectura existente. SAP sigue siendo SAP. Workday sigue siendo Workday. La arquitectura de red permanece intacta. Las políticas de seguridad siguen vigentes. El agente es un participante adicional en el ecosistema existente, sujeto a las mismas reglas, los mismos controles, los mismos requisitos de auditoría.

En Gosign construimos [infraestructura IA](/es/servicios/infraestructura/) como capa de integración: en Azure, GCP o Self-Hosted, conectada a los sistemas que ya existen. Sin Shadow IT. Los agentes se convierten en parte del [IT governance](/es/governance/) existente, no en un mundo paralelo.

--- Integracion de IA en el panorama IT: SAP, Workday ---
> AI Agents en SAP, Workday, A3: Integration Layer, desacoplamiento API, lógica contable separada de la capa de exportación.

## El principio: extender, no sustituir

Los AI Agents no sustituyen los sistemas existentes. Los extienden. SAP sigue siendo SAP. Workday sigue siendo Workday. A3 sigue siendo A3. El agente se sitúa entre ellos: lee datos, toma decisiones y escribe los resultados de vuelta.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">De un vistazo - Integración de IA en sistemas enterprise</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Los AI Agents extienden los sistemas existentes (SAP, Workday, A3) en lugar de sustituirlos - el agente es una capa de integración externa.</li>
<li>El Integration Layer desacopla la lógica del agente del sistema destino: cuando el ERP cambia, solo cambia la capa de exportación.</li>
<li>La lógica de contabilización (Decision Layer) está separada arquitectónicamente del formato de exportación (Integration Layer), reduciendo el esfuerzo de migración.</li>
<li>Forrester (2024) constata que las empresas con estrategias de integración API-first despliegan IA 2,4 veces más rápido que las que dependen de conectores personalizados.</li>
<li>Los agentes usan la autenticación, el entorno cloud, las políticas de seguridad y la monitorización existentes - sin sistema paralelo.</li>
</ul>
</div>

Este principio es decisivo para la aceptación en entornos empresariales. Los CIOs no invierten en un mundo paralelo. Invierten en una capa que hace más inteligente su panorama IT existente.

## El Integration Layer

El Integration Layer en la arquitectura de referencia de Gosign desacopla la logica del agente del sistema destino. Esto tiene una ventaja concreta: cuando el sistema destino cambia, solo cambia la capa de exportacion, no el agente.

**[SAP FI/CO y S/4HANA](https://www.sap.com/products/erp/s4hana.html):** Propuestas de asiento en formato SAP. Logica de centros de coste y centros de beneficio. Integracion via RFC, REST API o SAP BTP.

**[Workday](https://www.workday.com/):** Datos de RRHH, informacion de nominas, estructura organizativa. Integracion via Workday REST API.

**[SuccessFactors](https://www.sap.com/products/hcm.html):** Datos de empleados, datos de rendimiento, retribucion. Integracion via SAP SuccessFactors API.

**[Microsoft Graph](https://learn.microsoft.com/en-us/graph/overview):** SharePoint, Teams, Outlook. Para Knowledge Agents que acceden a documentos corporativos.

**Soluciones locales (A3, Sage, Meta4):** En el mercado espanol, muchas empresas utilizan soluciones como [A3](https://www.wolterskluwer.com/es-es/solutions/a3), [Sage](https://www.sage.com/es-es/) o [Meta4](https://www.cegid.com/es/) para contabilidad, nominas y RRHH. El Integration Layer permite la conexion con estas plataformas a traves de APIs estandar o conectores personalizados.

## Desacoplamiento: logica de contabilizacion vs. capa de exportacion

La separacion de la logica de contabilizacion y la capa de exportacion es un principio arquitectonico central. La logica de contabilizacion (que cuenta, que centro de coste, que tipo impositivo conforme al Plan General de Contabilidad) esta implementada en el Decision Layer. La capa de exportacion (como se transfiere el resultado a SAP o al sistema contable local) esta en el Integration Layer.

Cuando un cliente migra de un sistema local a SAP, cambia la capa de exportacion. La logica de contabilizacion, los conjuntos de reglas, el agente: todo permanece igual. Esto reduce significativamente el esfuerzo de migracion.

## Integration Layer por sistema destino

<table>
<thead>
<tr><th>Sistema destino</th><th>Método de integración</th><th>Alcance de datos</th></tr>
</thead>
<tbody>
<tr><td>SAP FI/CO, S/4HANA</td><td>RFC, REST API, SAP BTP</td><td>Propuestas de asiento, lógica de centros de coste</td></tr>
<tr><td>A3, Sage, Meta4</td><td>APIs estándar, conectores</td><td>Contabilidad, nóminas, RRHH</td></tr>
<tr><td>Workday</td><td>Workday REST API</td><td>Datos RRHH, nóminas, estructura organizativa</td></tr>
<tr><td>SuccessFactors</td><td>SAP SuccessFactors API</td><td>Datos empleados, rendimiento, retribución</td></tr>
<tr><td>Microsoft Graph</td><td>Graph API</td><td>SharePoint, Teams, Outlook</td></tr>
</tbody>
</table>

## Sin sistema paralelo

Los agentes se integran en la gobernanza IT existente, no como un mundo paralelo nuevo. Esto significa:

- Los agentes utilizan la autenticacion existente (Azure Entra ID, LDAP)
- Los agentes se ejecutan en el entorno cloud existente (Azure, GCP)
- Los agentes estan sujetos a las politicas de seguridad existentes
- Los agentes se integran en los sistemas de monitorizacion existentes

Para el CIO, un AI Agent es un componente mas en la arquitectura existente, no un sistema separado con sus propias reglas. Esto es especialmente relevante en el contexto del Esquema Nacional de Seguridad (ENS) para empresas que trabajan con el sector publico espanol.

Mas sobre este tema: [Arquitectura de referencia](/es/governance/reference-architecture/)

Mas sobre infraestructura: [Infraestructura de IA](/es/servicios/infraestructura/)

<a href="/es/contacto/" target="_blank" rel="noopener noreferrer">Agendar reunion</a>. Le mostramos la integracion en su panorama IT existente.

--- LLM Self-Hosting empresarial: Azure, GCP, On-Premise ---
> Cómo alojar modelos de lenguaje en la propia infraestructura. DeepSeek, Llama, Mistral Self-Hosted. Azure, GCP, On-Premise, híbrido.

## Por qué self-hosting?

Para muchos clientes empresariales, la cuestión no es si se utiliza IA, sino dónde se procesan los datos. Al utilizar APIs en la nube (OpenAI, Anthropic, Google), los datos abandonan la infraestructura propia. Para sectores regulados (finanzas, sanidad, sector público) esto puede ser un criterio de exclusión.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">De un vistazo - LLM Self-Hosting empresarial</p>
<ul class="text-body text-gosign-text space-y-2">
<li>El self-hosting mantiene todos los datos dentro de la red corporativa - sin procesamiento por terceros, control total sobre modelo, datos e inferencia.</li>
<li>Los modelos open source (Llama, Mistral, DeepSeek, gpt-oss) pueden desplegarse en Azure ML, GCP Vertex AI, servidores GPU propios o configuraciones híbridas.</li>
<li>El dimensionamiento de GPU es el principal factor de coste: un modelo 7B funciona en una GPU, un modelo 70B requiere múltiples GPUs o cuantización.</li>
<li>El enrutamiento modelo-agnóstico permite que los agentes usen modelos self-hosted para datos sensibles y Cloud APIs para tareas no críticas.</li>
<li>Gartner (2024) prevé que el 45% de los despliegues de IA en sectores regulados operarán en infraestructura privada en 2027, frente al 20% en 2023.</li>
</ul>
</div>

Self-hosting significa: el modelo de lenguaje se ejecuta en la infraestructura del cliente. Ningún dato abandona la red corporativa. Ningún tercero procesa las solicitudes. Control total sobre modelo, datos y procesamiento.

En España, esto es especialmente relevante para empresas que operan bajo el RGPD y la LOPDGDD (Ley Orgánica 3/2018 de Protección de Datos Personales y garantía de los derechos digitales), así como para organizaciones sujetas al Esquema Nacional de Seguridad (ENS) que trabajan con la Administración Pública.

## Que modelos se pueden alojar internamente?

Los modelos open-source pueden operarse en la propia infraestructura:

**Caballo de batalla por volumen - [Mistral](https://mistral.ai/) Small 3.2 (24B, Apache 2.0, construido en la UE):** Modelo europeo, funciona en una sola RTX 4090 con cuantización de 4 bits. Ideal para inferencia por lotes en cargas no críticas. Mixtral 8x22B y Codestral Mamba 32B (especializado en código) completan el portfolio de Mistral.

**Reasoning OSS - gpt-oss-120b (OpenAI, Apache 2.0):** 117B parámetros, arquitectura MoE, ejecutable en una sola H100 (80 GB). Primer modelo open source de OpenAI; gpt-oss-20b para escenarios edge.

**Frontier OSS - [DeepSeek](https://www.deepseek.com/) V4-Flash y V4-Pro (MIT):** DeepSeek V4-Flash (abril 2026, 284B/13B MoE activos) funciona en una sola H100 con cuantización. V4-Pro (1.6T/49B) requiere un clúster de 8x H100 y ofrece razonamiento de nivel frontier. DeepSeek R1 (enero 2025) sigue siendo apto para producción en despliegues maduros - V4 no jubila a R1 de la noche a la mañana.

**Contexto largo - [Llama](https://llama.meta.com/) 4 Scout (Meta License):** Ventana de contexto de 10M tokens para análisis documental sobre expedientes completos. Llama 4 Maverick gestiona contextos más cortos con mayor throughput de tokens.

**Coding OSS - Qwen 3 Coder 110B (Apache 2.0, Alibaba) y DeepSeek Coder V4 (MIT):** Especializados en generación de código y comprensión de repositorios. Codestral Mamba 32B (Mistral, construido en la UE) como alternativa europea.

Los modelos propietarios (Claude Opus 4.7, GPT-5.5, Gemini 3.1 Pro) no están disponibles para self-hosting, pero pueden utilizarse vía API con procesamiento en la UE.

En la arquitectura modelo-agnostica, un agente puede utilizar multiples modelos: self-hosted para datos sensibles, API en la nube para tareas no criticas. El enrutamiento es basado en reglas y esta configurado en el Decision Layer.

## Opciones de despliegue

**Azure:** Los LLMs pueden desplegarse en Azure ML o ejecutarse en VMs GPU dedicadas (NC-Series, ND-Series). Integracion con Azure Entra ID para autenticacion y control de acceso. Procesamiento en centros de datos de la UE (West Europe, North Europe).

**GCP:** Despliegue via Vertex AI o en VMs GPU dedicadas (A2, G2). Integracion con Google Cloud IAM. Procesamiento en centros de datos de la UE (europe-west1, europe-west4). La region europe-southwest1 (Madrid) es relevante para empresas espanolas con requisitos de residencia de datos nacional.

**On-Premise:** Servidores propios con GPUs NVIDIA (A100, H100, RTX 4000 Ada). Operacion en centros de datos certificados. Maximo control, sin dependencia de la nube. En Espana existen centros de datos certificados en Madrid, Barcelona y otras ciudades principales que cumplen con el ENS y la normativa de proteccion de datos.

**Hibrido:** Combinacion de self-hosted y nube. Cargas de trabajo sensibles en local, cargas no criticas en la nube. Gobernanza unificada en ambos entornos.

<table class="w-full text-left text-sm">
<thead><tr class="border-b border-gosign-border">
<th class="py-2 pr-4 font-semibold">Criterio</th>
<th class="py-2 pr-4 font-semibold">Self-Hosted</th>
<th class="py-2 pr-4 font-semibold">Cloud API</th>
</tr></thead>
<tbody>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Data Residency</td><td class="py-2 pr-4">Control total, datos permanecen on-premise</td><td class="py-2 pr-4">Depende del proveedor, regiones UE disponibles</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Elección de modelo</td><td class="py-2 pr-4">Solo open source (Llama, Mistral, DeepSeek)</td><td class="py-2 pr-4">Propietarios + open source via API</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Coste a escala</td><td class="py-2 pr-4">Menor (coste GPU fijo, sin tarifas por token)</td><td class="py-2 pr-4">Mayor (precio por token escala linealmente)</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Esfuerzo operativo</td><td class="py-2 pr-4">Alto (gestión GPU, actualizaciones, HA)</td><td class="py-2 pr-4">Bajo (gestionado por proveedor)</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Latencia</td><td class="py-2 pr-4">Baja (red local)</td><td class="py-2 pr-4">Variable (depende de la red)</td></tr>
</tbody>
</table>

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">eBook gratuito: Infraestructura de IA</p>
<p class="text-body text-gosign-text mb-4">Build, Buy, Hybrid - infraestructura conforme al EU AI Act con B/B/H-Framework y 7-Layer Reference Architecture.</p>
<a href="/es/ebook/ia-infraestructura-manual-gobernanza/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Descargar gratis</a>
</div>

## Consideraciones arquitectonicas

**Dimensionamiento de GPU:** El tamano del modelo determina los requisitos de GPU. Un modelo de 7B se ejecuta en una sola GPU. Un modelo de 70B necesita multiples GPUs o cuantizacion. El dimensionamiento correcto depende del caso de uso.

**Optimizacion de inferencia:** Tecnicas como la cuantizacion (4-bit, 8-bit), batching y optimizacion de cache KV reducen los requisitos de recursos con una perdida de calidad aceptable.

**Alta disponibilidad:** Para sistemas productivos: servidores GPU redundantes, balanceo de carga, failover automatico. Sin punto unico de fallo.

**Actualizaciones de modelos:** Las nuevas versiones de modelos deben probarse antes de pasar a produccion. Un entorno de staging para pruebas de modelos es parte de la infraestructura.

**Punto de cruce de TCO - self-host vs Cloud API:** El umbral se sitúa en torno a 50-100M tokens/mes sostenidos. Por debajo de ese umbral, las Cloud APIs son más económicas; por encima, una H100 dedicada se amortiza en 12-18 meses. Consulte [IA Open Source Autohospedada 2026](/es/revista/ia-open-source-autohospedada-2026/) para la matriz completa de modelos y el cálculo de costes.

Mas sobre este tema: [Infraestructura de IA](/es/servicios/infraestructura/)

Mas sobre estrategias de hosting: [Hosting IA estrategias enterprise](/es/revista/hosting-ia-estrategias-enterprise/)

<a href="/es/contacto/" target="_blank" rel="noopener noreferrer">Agendar reunion</a>. Le mostramos la estrategia de hosting optima para sus requisitos.

--- Arquitectura modelo-agnóstica: evitar vendor lock-in ---
> La lógica de negocio desacoplada del modelo de lenguaje. Agentes, Decision Layer y reglas permanecen inalterados al cambiar de modelo.

## El riesgo: un modelo, un proveedor

Muchas empresas construyen su estrategia de IA sobre un único modelo. "Usamos ChatGPT" o "Apostamos por Claude". Los prompts se optimizan para ese modelo. Las integraciones se construyen para la API de ese proveedor. Los flujos de trabajo se adaptan a las particularidades de ese modelo.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">De un vistazo - Arquitectura modelo-agnóstica</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Construir sobre un único proveedor de LLM crea una dependencia peligrosa: precios cambian, APIs se reestructuran, modelos se descontinúan sin aviso.</li>
<li>Una arquitectura modelo-agnóstica desacopla la lógica de negocio del modelo de lenguaje - agentes, Decision Layer y workflows permanecen intactos al cambiar de modelo.</li>
<li>El enrutamiento multi-modelo asigna modelos económicos a tareas simples y modelos insignia a razonamiento complejo, ahorrando un 40-60% en costes de tokens.</li>
<li>Los modelos self-hosted procesan datos sensibles mientras las Cloud APIs sirven peticiones no críticas - gobernado por el Decision Layer.</li>
<li>Forrester (2024) informa que las organizaciones con arquitectura modelo-agnóstica reducen costes de migración de LLM hasta un 70% frente a configuraciones de proveedor único.</li>
</ul>
</div>

Entonces ocurre una de tres cosas: el proveedor sube los precios. El proveedor cambia la API. Aparece un nuevo modelo que es significativamente mejor o más barato. En cualquier caso: toda la implementación debe adaptarse.

En el mercado de LLMs, esto ocurre rápido. En los últimos 18 meses, los precios se han reducido a la mitad, han aparecido nuevos proveedores, los modelos open-source han superado a los modelos propietarios en benchmarks. Quien se ha vinculado a un proveedor no puede aprovechar estos desarrollos.

## Modelo-agnostico como principio arquitectonico

En la arquitectura de referencia de Gosign, el Model Layer es una capa intercambiable. La logica de negocio (conjuntos de reglas, logica de decision, flujos de trabajo) esta implementada en el Decision Layer y el Agent Layer, no en el modelo.

Cuando un nuevo modelo esta disponible, puede integrarse sin modificar las capas superiores. El agente no sabe que modelo esta utilizando. Envia una solicitud al Model Layer y recibe una respuesta. Que modelo proporciona la respuesta es irrelevante para el agente.

## Multi-Model Routing

Un agente puede utilizar multiples modelos simultaneamente. El enrutamiento es basado en reglas:

**Optimizacion de costes:** Las tareas sencillas (clasificacion de documentos, extraccion de datos) se ejecutan en un modelo economico. Las tareas complejas (soporte a la decision, interpretacion de reglas) en un modelo mas potente.

**Residencia de datos:** Los datos sensibles van a modelos self-hosted ([Llama](https://llama.meta.com/), [Mistral](https://mistral.ai/), [DeepSeek](https://www.deepseek.com/)). Los datos no criticos pueden enrutarse a traves de APIs en la nube. Para empresas espanolas sujetas al RGPD y la LOPDGDD, el enrutamiento basado en la sensibilidad de los datos es esencial para garantizar el cumplimiento normativo.

**Failover:** Si un proveedor de modelos se cae, el sistema puede cambiar automaticamente a un modelo alternativo.

Las reglas de enrutamiento estan configuradas en el Decision Layer y son completamente trazables.

## Modelos soportados

La arquitectura de Gosign soporta actualmente (estado 2026):
- Claude Opus 4.7 / Sonnet 4.6 / Haiku 4.5 (Anthropic) - API en la nube
- GPT-5.5 / GPT-5.5-mini (OpenAI) - API en la nube
- Gemini 3.1 Pro / 3.1 Flash (Google) - API en la nube
- Llama 4 Scout / Llama 4 Maverick (Meta) - Self-Hosted o nube
- Mistral Small 3.2 / Mistral Large (Mistral AI) - Self-Hosted o nube
- DeepSeek V4-Pro / V4-Flash / R1 (DeepSeek) - Self-Hosted o nube
- gpt-oss (OpenAI) - Self-Hosted o nube

Nuevos modelos pueden integrarse en cuanto estén accesibles a través de una API estándar. En el contexto europeo, la elección de Mistral como modelo europeo puede ser relevante para empresas con requisitos específicos de soberanía tecnológica. Qué modelo encaja con qué tipo de micro-decisión lo desarrolla la pieza complementaria: [¿Qué modelo cuándo? Decision Routing para workflows agénticos](/es/revista/modelos-ia-comparacion-2026/).

| Aspecto | Configuración de proveedor único | Arquitectura modelo-agnóstica |
|---|---|---|
| Cambio de modelo | Reconstrucción completa de prompts, integraciones, workflows | Cambio de reglas de enrutamiento, sin reconstrucción |
| Control de costes | Un solo modelo de precios | Modelos económicos para tareas simples, insignia para complejas |
| Soberanía de datos | Depende del proveedor | Self-hosted para sensibles, nube para no críticos |
| Failover | Sin alternativa si el proveedor cae | Cambio automático a modelo alternativo |
| Coste de migración | Alto (Forrester: hasta 70% mayor) | Bajo (solo cambio de configuración) |
| Preparación futura | Riesgo de descontinuación | Nuevos modelos integrados sin cambios |

Más sobre este tema: [Infraestructura de IA](/es/servicios/infraestructura/)

Mas sobre gobernanza: [Gobernanza de IA](/es/governance/)

## Modelo-agnóstico más Decision Routing

La arquitectura modelo-agnóstica es la condición previa; el Decision Routing por micro-decisión es la aplicación. Quien construye la capa de routing convierte la elección de modelo en una configuración, y la actualización de modelo en un diff de configuración en lugar de un re-engineering. Qué modelo encaja con qué tipo de decisión - clasificación, tool-use, razonamiento, contexto largo - lo expone la comparativa maestra: [¿Qué modelo cuándo? Decision Routing para workflows agénticos](/es/revista/modelos-ia-comparacion-2026/).

<a href="/es/contacto/" target="_blank" rel="noopener noreferrer">Agendar reunion</a>. Le mostramos la arquitectura modelo-agnostica en detalle.

--- Cuándo Mistral, cuándo Claude Opus? Decision Routing para Enterprise UE 2026 ---
> Decisiones agénticas descompuestas: Mistral Small en on-prem UE cubre el 70%, Claude Opus para el 10% con razonamiento real. Decision Records para EU AI Act art. 13.

El mercado de modelos maduró más rápido que la mayoría de arquitecturas enterprise. Claude Opus 4.7, GPT-5.5 y Gemini 3.1 Pro convergen en calidad. Mistral La Plateforme opera desde un centro de datos francés bajo jurisdicción UE. OpenAI publicó gpt-oss bajo Apache 2.0 en agosto de 2025. Meta y Mistral entregan modelos de pesos abiertos que funcionan en una sola GPU y alcanzan calidad de producción.

Y aún así, la mayoría de proyectos de IA enterprise siguen eligiendo un único modelo y enrutando cada workload a través de él. Esa decisión determina silenciosamente otras tres cosas: la posición de soberanía cloud, el coste de auditoría bajo el EU AI Act y el margen para optimización de costes. Elegir un modelo no es una decisión de modelo. Es una decisión de arquitectura.

<div class="not-prose my-12 border border-gosign-border bg-gosign-light rounded-card p-6 lg:p-8">
<p class="text-h3 font-bold text-gosign-dark mb-3">De un vistazo - Stack Agéntico para Enterprise UE 2026</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Alrededor del 70% de las decisiones agénticas en un workflow bien descompuesto son aplicación de reglas o extracción estructurada. En despliegues de hosting UE típicos, Mistral Small 3.2 en una sola GPU las cubre a aproximadamente 1/30 del precio de lista de Claude Opus.</li>
<li>Mistral tiene dos superficies de despliegue distintas: La Plateforme (API alojada en la UE, infraestructura francesa, centro de datos dedicado en Bruyères-le-Châtel en el segundo trimestre de 2026) y Mistral Small 3.2 (Apache 2.0, totalmente autohospedable, 24B parámetros).</li>
<li>El 8 al 10% restante de decisiones (razonamiento complejo, análisis transjurisdiccional, escalación de casos límite) justifica Claude Opus 4.7 o GPT-5.5. Ahí es donde el gasto en tokens se gana, no se malgasta.</li>
<li>La exposición al US CLOUD Act aplica incluso a despliegues UE de proveedores estadounidenses. Schrems II lo hizo concreto. Solo Mistral Small autohospedado, gpt-oss-120b o DeepSeek V4-Flash (preview abril 2026, MIT, 284B/13B activo MoE) tienen superficie CLOUD Act cero.</li>
<li>El artículo 13 del EU AI Act exige operación transparente de los sistemas de alto riesgo. Una capa de Decision Routing produce el artefacto de auditoría: un registro por decisión con entrada, versión de regla, modelo, nivel de confianza y aprobador humano cuando hay escalación.</li>
</ul>
</div>

## Evalúas Mistral - lo que realmente evalúas es tu estrategia cloud UE

El recorrido típico en 2026 se ve así. Compliance pide una alternativa UE a OpenAI. Compras recopila ofertas de proveedores. Arquitectura empieza a evaluar Mistral. En una semana la conversación se desplazó de "qué modelo" a "cuál es nuestra posición frente al US CLOUD Act" y "cómo operacionalizamos el artículo 13 del EU AI Act para sistemas de alto riesgo".

El CLOUD Act sigue el control del proveedor, no la ubicación de los datos. Un proveedor estadounidense con centros de datos UE - Azure OpenAI UE, AWS Bedrock Frankfurt, GCP Vertex europe-west - puede ser obligado a entregar datos bajo orden judicial estadounidense. La Comisión Europea prevé publicar un [Tech Sovereignty Package](https://www.kiteworks.com/cybersecurity-risk-management/eu-tech-sovereignty-package-cloud-act/) en el segundo trimestre de 2026, restringiendo el uso público de proveedores estadounidenses para cargas sensibles en sanidad, finanzas y sistemas judiciales. La contratación privada lee esas señales.

Para DPO: CLOUD Act + Schrems II no elimina SCC (Cláusulas Contractuales Tipo Comisión 2021/914) + TIA (Transfer Impact Assessment según Recomendaciones EDPB 01/2020) como vía legal. Pero la TIA debe documentar medidas técnicas suplementarias (cifrado client-side, fragmentación, etc.) y mostrar equivalencia de protección - lo que para proveedor US bajo CLOUD Act es prácticamente imposible. Self-hosting elimina la cuestión por completo.

Mistral interesa no porque gane a Claude en una tabla de ranking. Interesa porque ocupa una posición que ningún proveedor estadounidense puede ocupar: un proveedor europeo frontier-class con [infraestructura UE dedicada](https://help.mistral.ai/en/articles/347629-where-do-you-store-my-data-or-my-organization-s-data) y una línea de modelos de pesos completamente abiertos bajo Apache 2.0. Desde el segundo trimestre de 2026 la compañía opera su propio centro de datos cerca de París con [13.800 GPU NVIDIA GB300](https://ioplus.nl/en/posts/why-mistrals-830m-raise-is-a-win-for-european-autonomy) y 44 megavatios de capacidad. Eso convierte a Mistral en el único proveedor frontier que puede ofrecer residencia UE end-to-end sobre infraestructura propiedad de y operada bajo jurisdicción UE.

Pero esto enmarca mal la pregunta. La pregunta real no es "Mistral o OpenAI". Es "qué decisiones van dónde, y cómo se demuestra a un auditor".

## Mistral son dos mundos: La Plateforme en Francia o Mistral Small Apache 2.0

La confusión empieza cuando se trata a "Mistral" como un único producto. Son dos familias de productos con distintas superficies de despliegue e implicaciones de cumplimiento.

| Producto Mistral | Despliegue | Licencia / coste | Soberanía UE |
|---|---|---|---|
| Mistral Medium 3.1 | La Plateforme (API en FR) o Azure AI Foundry | Por tokens, propietario | Sí vía La Plateforme |
| Mistral Small 3.2 | Autohospedaje on-prem | Apache 2.0, solo coste GPU | Sí si hardware UE |
| Mixtral 8x22B | Autohospedaje on-prem | Apache 2.0, solo coste GPU | Sí si hardware UE |
| Codestral | La Plateforme | Por tokens, propietario | Sí vía La Plateforme |

*"Soberanía UE" significa: fuera del alcance del US CLOUD Act. Tanto La Plateforme (jurisdicción francesa) como el autohospedaje en hardware UE cumplen. Azure AI Foundry no, incluso con residencia de datos UE, porque Microsoft sigue sujeto a órdenes del CLOUD Act.*

Mistral Medium 3.1 es la flagship propietaria frontier-class. Funciona sobre la infraestructura francesa propia de Mistral, accesible por API. Facturada por tokens. Soberana UE por defecto. Desde el segundo trimestre de 2026 el centro de datos dedicado en Bruyères-le-Châtel atiende la inferencia para clientes que exigen residencia francesa garantizada.

[Mistral Small 3.2](https://mistral.ai/news/mistral-small-3-1) es el caballo de batalla de pesos abiertos. 24 mil millones de parámetros. Contexto de 128K tokens. Comprensión visual incluida. Publicado en marzo de 2025 bajo Apache 2.0. Funciona en una sola NVIDIA RTX 4090 o en un Mac con 32 GB de RAM. Throughput de aproximadamente 150 tokens por segundo en hardware de consumo.

Los dos no son redundantes. La Plateforme tiene sentido cuando se quiere soberanía UE sin operar infraestructura GPU. Mistral Small 3.2 tiene sentido cuando la decisión es de tan alto volumen que la facturación por tokens se convierte en el driver de coste, o cuando los datos son tan sensibles que incluso el tráfico de API UE es demasiada superficie.

La pregunta de arquitectura es qué superficie de despliegue para cada decisión, no qué proveedor para cada ranking.

<figure class="not-prose my-12">
<svg viewBox="0 0 800 600" xmlns="http://www.w3.org/2000/svg" role="img" aria-labelledby="radar-title-es radar-desc-es" class="w-full h-auto max-w-3xl mx-auto">
<title id="radar-title-es">Comparación de perfiles de modelos en seis dimensiones empresariales (mayo 2026)</title>
<desc id="radar-desc-es">Spider-chart comparando cuatro modelos representativos en seis dimensiones relevantes para empresa, puntuados 0 a 10. Claude Opus 4.7 (nube, Anthropic): Razonamiento 10, Codificación 10, Multimodal 7, Eficiencia de costes 3, Latencia 6, Soberanía UE 4. GPT-5.5 (nube, OpenAI/Azure): Razonamiento 10, Codificación 10, Multimodal 9, Eficiencia 3, Latencia 7, Soberanía 4. Mistral Small 3.2 (self-host, Apache 2.0): Razonamiento 6, Codificación 7, Multimodal 8, Eficiencia 10, Latencia 9, Soberanía 10. DeepSeek V4-Pro (self-host, MIT): Razonamiento 9, Codificación 8, Multimodal 5, Eficiencia 7, Latencia 7, Soberanía 9. Los modelos cloud-flagship dominan en Razonamiento, Codificación y Multimodal pero pierden en Eficiencia de costes y Soberanía UE. Los modelos self-host invierten ese patrón. La capa de routing combina ambas formas por micro-decisión en lugar de elegir un solo campeón.</desc>
<defs><style>
.axis-es { stroke: #d4d0cb; stroke-width: 1; fill: none; }
.grid-es { stroke: #d4d0cb; stroke-width: 0.5; fill: none; opacity: 0.5; }
.label-es { font-family: -apple-system, system-ui, sans-serif; font-size: 12px; fill: #1a2e4d; text-anchor: middle; font-weight: 600; }
.scale-es { font-family: -apple-system, system-ui, sans-serif; font-size: 9px; fill: #94a3b8; text-anchor: middle; }
.legend-es { font-family: -apple-system, system-ui, sans-serif; font-size: 12px; fill: #1a2e4d; font-weight: 500; }
.legend-sub-es { font-family: -apple-system, system-ui, sans-serif; font-size: 10px; fill: #64748b; }
</style></defs>
<circle cx="400" cy="300" r="50" class="grid-es"/><circle cx="400" cy="300" r="100" class="grid-es"/><circle cx="400" cy="300" r="150" class="grid-es"/><circle cx="400" cy="300" r="200" class="grid-es"/><circle cx="400" cy="300" r="250" class="grid-es"/>
<text x="408" y="100" class="scale-es">10</text><text x="408" y="150" class="scale-es">8</text><text x="408" y="200" class="scale-es">6</text><text x="408" y="250" class="scale-es">4</text><text x="408" y="300" class="scale-es">2</text>
<line x1="400" y1="300" x2="400" y2="50" class="axis-es"/><line x1="400" y1="300" x2="616.5" y2="175" class="axis-es"/><line x1="400" y1="300" x2="616.5" y2="425" class="axis-es"/><line x1="400" y1="300" x2="400" y2="550" class="axis-es"/><line x1="400" y1="300" x2="183.5" y2="425" class="axis-es"/><line x1="400" y1="300" x2="183.5" y2="175" class="axis-es"/>
<text x="400" y="38" class="label-es">Razonamiento</text>
<text x="630" y="165" class="label-es">Codificación</text>
<text x="630" y="438" class="label-es">Multimodal</text>
<text x="400" y="572" class="label-es">Eficiencia de costes</text>
<text x="170" y="438" class="label-es">Latencia inferencia</text>
<text x="170" y="165" class="label-es">Soberanía UE</text>
<polygon points="400,50 616.5,175 562,387 400,375 335,338 313,225" fill="#fcd34d" fill-opacity="0.25" stroke="#b8941f" stroke-width="2"/>
<polygon points="400,50 616.5,175 595,413 400,375 313,363 313,225" fill="#3a6090" fill-opacity="0.20" stroke="#3a6090" stroke-width="2" stroke-dasharray="6 3"/>
<polygon points="400,150 551.5,213 579,400 400,550 205,425 183.5,175" fill="#1a2e4d" fill-opacity="0.20" stroke="#1a2e4d" stroke-width="2"/>
<polygon points="400,75 595,188 508,363 400,475 248,400 205,200" fill="#9a5a5a" fill-opacity="0.18" stroke="#9a5a5a" stroke-width="2" stroke-dasharray="3 3"/>
<g transform="translate(40, 590)"><rect x="0" y="-15" width="15" height="3" fill="#b8941f"/><text x="22" y="-9" class="legend-es">Claude Opus 4.7</text><text x="22" y="3" class="legend-sub-es">nube, Anthropic</text></g>
<g transform="translate(195, 590)"><rect x="0" y="-15" width="15" height="3" fill="#3a6090"/><text x="22" y="-9" class="legend-es">GPT-5.5</text><text x="22" y="3" class="legend-sub-es">nube, OpenAI/Azure</text></g>
<g transform="translate(370, 590)"><rect x="0" y="-15" width="15" height="3" fill="#1a2e4d"/><text x="22" y="-9" class="legend-es">Mistral Small 3.2</text><text x="22" y="3" class="legend-sub-es">self-host, Apache 2.0</text></g>
<g transform="translate(560, 590)"><rect x="0" y="-15" width="15" height="3" fill="#9a5a5a"/><text x="22" y="-9" class="legend-es">DeepSeek V4-Pro</text><text x="22" y="3" class="legend-sub-es">self-host, MIT</text></g>
</svg>
<figcaption class="text-sm text-gosign-text-light text-center mt-4 max-w-2xl mx-auto">
<strong>Perfil de modelo en seis dimensiones empresariales</strong> - vista comparativa estilo c't, puntuada 0 a 10. Los flagships cloud (Claude Opus 4.7, GPT-5.5) dominan en Razonamiento, Codificación, Multimodal, pero pierden en Eficiencia de costes y Soberanía UE. Los modelos self-host (Mistral Small 3.2, DeepSeek V4-Pro) invierten esa forma. No hay un modelo "mejor" - la capa de routing elige la forma correcta por micro-decisión.
</figcaption>
</figure>

## Por qué Mistral Small por defecto, no gpt-oss ni DeepSeek

Pregunta razonable una vez que se opta por autohospedaje: por qué Mistral Small 3.2 gana el puesto de workhorse frente a [gpt-oss-120b](https://openai.com/index/introducing-gpt-oss/) (Apache 2.0, 117B params MoE, 5 de agosto de 2025) o [DeepSeek V4](https://api-docs.deepseek.com/news/news260424) (MIT, preview del 24 de abril de 2026; V4-Flash 284B/13B activo, V4-Pro 1.6T/49B activo, contexto 1M)? Los tres son legítimamente autohospedables en alguna configuración. La diferenciación está en suelo de hardware, cobertura lingüística y modalidad.

| Modelo open source | Suelo de hardware (CAPEX) | OPEX hosted (UE) | Fortaleza | Debilidad | Sweet spot |
|---|---|---|---|---|---|
| Mistral Small 3.2 (24B, Apache 2.0) | 1× RTX 4090 ~1.500 EUR o 1× H100 ~30.000 EUR | ~1.500-2.500 EUR/mes (1× H100 hosted) | Volumen, multilingüe (DE/EN/PL/ES/BR), capacidad visual, ~150 tok/s | No es razonamiento de máximo nivel | **Workhorse por defecto para la banda de volumen del 70%** |
| gpt-oss-120b (117B MoE, Apache 2.0) | 1× H100/A100 80GB ~30.000 EUR | ~1.200-2.500 EUR/mes (1× H100 hosted) | Razonamiento a nivel o4-mini, eficiente con MoE | Sin visión, requiere hardware de datacenter | **Alternativa de razonamiento pesado a Claude Opus, cuando incluso eso debe quedar on-prem** |
| DeepSeek V4-Flash (MIT, preview abr 2026) | 1-4× H100/A100 80GB ~30.000-120.000 EUR con quant | ~1.500-5.000 EUR/mes (1-4× H100 hosted) | Razonamiento frontier-class con hardware moderado, contexto 1M, multimodal nativo | Estado preview - los benchmarks deben reverificarse antes de producción | **Especialista mate/lógica + análisis de carteras con contexto 1M** |
| DeepSeek V4-Pro (MIT, preview abr 2026) | Clúster 8× H100 ~240.000 EUR CAPEX | ~10.000-12.000 EUR/mes (8× H100 hosted) | Se aproxima a rendimiento de GPT-5.5/Gemini 3.1 Pro, optimizado para agent-tooling | Hardware clase datacenter; partida estándar de presupuesto TI para gran empresa, API/hosted para PYME | **Razonamiento frontier bajo licencia abierta: on-prem para gran empresa, API/hosted para PYME** |
| DeepSeek R1 (MIT, ene 2025) | 4-8× H100 ~120.000-240.000 EUR | ~5.000-10.000 EUR/mes (4-8× H100 hosted) | Especialista mate/lógica maduro | Mayormente superado por V4-Flash en despliegues nuevos | **Despliegues maduros con foco mate/lógica** |
| Llama 4 Scout (Meta Llama License) | 1× GPU ~30.000 EUR | ~1.500 EUR/mes (1× H100 hosted) | Contexto de 10M tokens | Restricción de licencia con >700M MAU | **Contexto ultralargo para carteras completas de contratos** |

DeepSeek V4-Pro es open source bajo licencia MIT (pesos publicados en Hugging Face) - la cuestión nunca fue de licencia, sino de tamaño de empresa. Para una gran empresa del IBEX-35 o mediana empresa superior, 240.000 EUR de CAPEX son una partida estándar del presupuesto TI; el modelo corre on-prem como cualquier otro workload datacenter. Para una PYME por debajo de 500 empleados, el camino realista es V4-Pro vía API (Together.ai, Fireworks, DeepSeek API) o como variante hospedada en proveedores UE - misma licencia abierta, sin CAPEX hardware.

Tres razones concretas por las que Mistral Small gana el puesto por defecto:

**Umbral de hardware.** Mistral Small funciona en silicio de consumo. gpt-oss-120b necesita una GPU de datacenter. Para una pipeline enterprise con cinco a diez nodos worker, el delta de hardware por nodo es significativo. Cuando el 70% de las decisiones son clasificación o extracción, la capacidad de razonamiento gpt-oss-grade es sobredimensionada para el trabajo de volumen.

**Corpus de entrenamiento multilingüe.** Mistral fue entrenado desde el inicio sobre datos en francés, alemán, español e italiano. gpt-oss es US-céntrico con entrenamiento dominado por inglés. Para una pipeline Enterprise UE que procesa documentos en español, polaco o portugués, Mistral Small es el mejor workhorse desde el día uno.

**Visión incluida.** Mistral Small 3.2 tiene capacidad de visión nativa. gpt-oss no. Para onboarding de RRHH (escaneo de DNI, certificados, formularios IRPF) o cuentas a pagar (facturas PDF con layout), esto es un knockout duro.

gpt-oss-120b o DeepSeek V4-Flash entran en el stack como opciones de razonamiento pesado on-prem cuando la API de Claude Opus 4.7 no puede usarse por motivos de cumplimiento. DeepSeek V4-Pro se aproxima al rendimiento frontier-closed-source bajo licencia MIT, pero su suelo de hardware (clúster 8× H100) lo sitúa en territorio API u hospedado para la mayoría de empresas. Ninguno reemplaza a Mistral Small como workhorse de volumen - lo complementan para las decisiones más difíciles. La comparativa detallada de autohospedaje se cubre en [IA Open Source Autohospedada 2026: Mistral, gpt-oss, DeepSeek V4, Llama 4 en el stack enterprise](/es/revista/ia-open-source-autohospedada-2026/) (artículo separado).

## Qué modelo para qué? La distribución de complejidad de decisiones agénticas

Un agente enterprise típico se descompone en 14 a 50 micro-decisiones. La complejidad no se distribuye uniformemente. En una pipeline de RRHH o Finanzas bien instrumentada, sigue un patrón que medimos consistentemente:

| Tipo de decisión | Porcentaje | Complejidad | Mejor modelo | Coste real por 1M tokens |
|---|---|---|---|---|
| Aplicación de reglas (clase fiscal IRPF desde maestro, clasificación de tipo de contrato, comprobación de umbrales) | 50% | Baja | Frecuentemente sin LLM; en otro caso Mistral Small 3.2, Llama 4 Scout, gpt-oss-20b | ~0 a ~0,50 USD |
| Extracción estructurada (extracción de campos de PDF, normalización de tablas, líneas OCR-corregidas) | 25% | Media | Mistral Small 3.2, Mistral Medium 3.1, gpt-oss-120b | ~0,50 a ~2 USD |
| Clasificación contextual (revisión de cláusula bajo ET art. 64, detección de anomalías en gastos, banderas de riesgo de proveedor) | 15% | Media-alta | Mistral Medium 3.1, Claude Haiku 4.5, GPT-5 mini | ~1 a ~5 USD |
| Razonamiento complejo (análisis transjurisdiccional Ley 15/2022, síntesis de argumento multi-paso, redacción de escalaciones) | 8% | Alta | Claude Opus 4.7, GPT-5.5 | ~15 a ~25 USD |
| Multimodal (correlación imagen-texto, segmentos de vídeo, revisión de planos técnicos) | 2% | Alta | Gemini 3.1 Pro | ~5 a ~10 USD |

La consecuencia es directa. Si se enruta cada decisión por Claude Opus, se paga tarifa flagship por tokens para el 75% del trabajo que no necesita razonamiento flagship. Si se enruta todo por Mistral Small, se ahorra coste de tokens pero se falla en el 8% donde el razonamiento clase Opus realmente importa - y se paga el coste en findings de auditoría, no en tokens.

El [AI Index 2025 de Stanford HAI](https://hai.stanford.edu/ai-index/2025-ai-index-report) registra que el 65,7% de los modelos foundation publicados en 2023 fueron open source, frente al 33,3% en 2021. La adopción enterprise de IA superó el 78%. El mercado ya no elige entre propietario y abierto. Elige cómo componerlos.

## Mistral Small como workhorse: un agente de onboarding de RRHH con 14 micro-decisiones

Ejemplo concreto. Un agente de onboarding de RRHH recibe el contrato firmado de una nueva incorporación más documentación de soporte (copia del DNI o NIE, modelo 145 IRPF, datos bancarios, certificados de cualificación). Su trabajo: producir el registro maestro de personal, ejecutar comprobaciones de cumplimiento previas al empleo, programar onboarding, registrar el alta en el Sistema RED de la TGSS. Catorce micro-decisiones en total, desde validación regex hasta análisis de no discriminación bajo la Ley 15/2022.

Una implementación ingenua envía cada paso a Claude Opus 4.7. Una implementación descompuesta enruta por paso. El Decision Layer contiene las reglas de enrutado: cada paso se clasifica como REGLAS, IA AUTÓNOMA o HUMANO antes de ejecutarse.

**REGLAS:** La decisión es determinista. El formato del NIF/NIE sigue una regla de checksum, el IBAN sigue ISO 13616. No hay interpretación, no hay modelo necesario. Aquí el agente es ejecutor, no razonador.

**IA AUTÓNOMA:** La decisión es clasificación o extracción con confianza suficiente. Detección del tipo de documento, clasificación del tipo de contrato (art. 14 ET, alta), extracción estructurada de campos. Un modelo pequeño con un esquema claro vence a un modelo flagship con un prompt vago.

**HUMANO:** La decisión toca discrecionalidad, riesgo de discriminación, ámbito de consulta del Comité de Empresa o violación de umbrales. Análisis bajo Ley 15/2022 sobre igualdad de trato y ET art. 17 sobre no discriminación, ámbito de información al Comité de Empresa bajo ET art. 64, anomalía salarial por encima del límite pactado. El modelo prepara el caso; el humano firma la decisión.

Los siguientes ocho pasos son el patrón de enrutamiento representativo de una pipeline típica de 14 pasos. La tabla completa con las 14 reglas de enrutado vive en la configuración del Decision Layer del cliente.

| Paso | Decisión | Capa | Destino de enrutado |
|---|---|---|---|
| 1 | Detectar tipos de documento en la subida | IA AUTÓNOMA | Mistral Small 3.2 on-prem |
| 2 | Extraer datos personales (nombre, dirección, fecha de nacimiento, NIF) | IA AUTÓNOMA | Mistral Small 3.2 on-prem |
| 3 | Validar formato NIF/NIE/CIF e IBAN según AEAT y normas bancarias | REGLAS | Motor de reglas, sin LLM |
| 4 | Clasificar tipo de contrato (indefinido, temporal, en prácticas, formación) bajo ET art. 14 | IA AUTÓNOMA | Mistral Small 3.2 |
| 5 | Comprobar cláusulas del contrato frente al convenio colectivo aplicable v2024-3 | IA AUTÓNOMA | Mistral Medium 3.1 (La Plateforme) |
| 6 | Marcar cláusulas potencialmente discriminatorias bajo Ley 15/2022 y ET art. 17 | HUMANO (preparado por IA) | Claude Opus 4.7 prepara el análisis, Director RRHH firma |
| 7 | Detectar anomalías salariales frente a rol/ubicación/antigüedad | IA AUTÓNOMA | Mistral Medium 3.1 |
| 8 | Decidir si aplica información al Comité de Empresa bajo ET art. 64 | HUMANO (preparado por IA) | Mistral Medium 3.1 pre-clasifica, enlace con Comité de Empresa firma |

De los 14 pasos completos, seis son REGLAS (sin LLM: comprobación IBAN, completitud documental, presentaciones deterministas al Sistema RED de la TGSS y modelo 145 a la AEAT). Seis son IA AUTÓNOMA (Mistral Small o Medium). Dos son HUMANO con preparación por IA (Claude Opus para la cuestión de no discriminación bajo Ley 15/2022, Mistral Medium para la pre-clasificación de información al Comité de Empresa bajo ET art. 64).

En despliegues de hosting UE típicos, esta distribución se traduce en aproximadamente 1 a 3 EUR por onboarding en inferencia. Una arquitectura flagship-only (cada paso por Claude Opus) cae cerca de 25 a 40 EUR por onboarding - y procesa el paso 1 y el paso 2 sobre infraestructura estadounidense bajo exposición al CLOUD Act. Mismo resultado de negocio. Audit Trail distinto. Curva de coste distinta. Posición de soberanía distinta.

<div class="not-prose my-12 border border-gosign-border bg-gosign-light rounded-card p-6 lg:p-8">
<p class="text-h3 font-bold text-gosign-dark mb-3">Ejemplo Banca - Pipeline de subscripción de crédito (18 microdecisiones)</p>
<p class="text-body text-gosign-text">Score Asnef = REGLAS. Match contra lista COAF/SEPBLAC = REGLAS. Clasificación perfil de riesgo basada en comportamiento transaccional = IA AUTÓNOMA con Mistral Small. Decisión final superior a 50.000 EUR = HUMANO con Ley del Cadastre Positivo considerada. Reporte COAF si patrón sospechoso = REGLAS bajo Ley 10/2010.</p>
</div>

## Qué ve el auditor: Decision Records bajo EU AI Act Art. 13

El [artículo 13 del EU AI Act](https://artificialintelligenceact.eu/article/13/) exige que los sistemas de IA de alto riesgo operen con transparencia suficiente para que los responsables del despliegue interpreten las salidas y las usen apropiadamente. El sistema debe venir con instrucciones que especifiquen métricas de precisión, robustez, niveles probados de ciberseguridad, medidas de supervisión humana bajo el artículo 14 y los recursos hardware requeridos.

La pregunta del auditor el día de la inspección no es "qué modelo usaron" sino "muéstreme el registro de decisión del caso de personal 2026-01-1873, paso 8".

Un Decision Record producido por una capa de enrutado contiene, por micro-decisión:

- **Snapshot de entrada** (los campos relevantes del contexto upstream, con manejo PII aplicado bajo RGPD)
- **Versión de la regla** (qué versión del convenio colectivo o del marco de Comité de Empresa se usó; v2024-3)
- **Tipo de decisión** (aplicación de regla, clasificación IA, razonamiento IA, aprobación humana)
- **Modelo usado** (si IA: Mistral-Small-3.1-Instruct-2503, desplegado en clúster A04, región eu-de-fra)
- **Nivel de confianza** (si IA: 0,94)
- **Cadena de razonamiento** (si aplica: el razonamiento intermedio del modelo, capturado verbatim)
- **Resultado** (etiqueta de clasificación, valor extraído o bandera de escalación)
- **Aprobador humano** (si hubo escalación: nombre, rol, timestamp)
- **Botón de impugnación** para decisiones IA (la persona afectada puede impugnar una decisión automatizada, lo que dispara una redecisión bajo revisión humana - el mecanismo exigido por el art. 22 RGPD)

Una pipeline que produce estos registros transforma la pregunta del modelo en una pregunta de enrutado. El auditor no pregunta "es Mistral tan bueno como Claude". El auditor pregunta "está la decisión documentada end-to-end y se puede reproducir". La pregunta del consejo va un paso más allá: quién firma la decisión cuando la Ley 15/2022 ha sido vulnerada por un destino de enrutado que debería haber escalado a un humano? La capa de enrutado hace esa firma trazable.

Para instituciones bajo supervisión del Banco de España y CNMV: la Circular 1/2024 BdE sobre Modelos Internos + DORA art. 28-30 (Subcontratación de servicios TIC) desde 17 enero 2025 + EBA Guidelines on Outsourcing (EBA/GL/2019/02) exigen registro de proveedores TIC. Para uso de Mistral La Plateforme: notificación obligatoria al Banco de España bajo Ley 10/2014 art. 26 si externalización es relevante. Decision Records cumplen documentación de los tres frameworks en paralelo.

Para operadoras de telecomunicaciones bajo supervisión CNMC: Ley General de Telecomunicaciones 11/2022 + Reglamento de Calidad de Servicio. AI en gestión de incidencias (Orden CNMC Resolución de calidad) + detección de fraude bajo Ley 11/2022 art. 41 son sistemas de alto riesgo bajo EU AI Act.

Para DPO bajo LOPDGDD: art. 35 RGPD DPIA es herramienta obligatoria para sistemas de IA de alto riesgo. AEPD ha emitido Resolución PS/00385/2023 sobre profiling automatizado y Resolución RR/00789/2024 sobre IA en RR.HH. TJUE C-634/21 SCHUFA (Dec 2023) confirma que decisión automatizada de scoring constituye "decisión automatizada" bajo art. 22 RGPD - la sentencia es referencia obligatoria. Resolución CD/ANPD 19/2024 estableció Cláusulas Contractuales Tipo brasileñas - para empresas con operaciones LATAM relevante.

## La pregunta de arquitectura: Decision Layer o vendor lock-in

Una capa de Decision Layer model-agnóstica no es una feature. Es la precondición para casi todo lo enumerado en este artículo. Sin ella, los patrones de enrutado de arriba son abstractos.

| Sin Decision Layer | Con Decision Layer |
|---|---|
| La elección del modelo se vuelve adhesiva. Cambiar de proveedor significa reimplementar el agente entero. | Cambiar de proveedor toma un cambio de configuración. Los modelos son intercambiables por paso de decisión. |
| La optimización de coste sucede a posteriori, renegociando con un vendor. | La optimización de coste está integrada: las decisiones de baja complejidad se enrutan automáticamente al modelo viable más barato. |
| La soberanía es binaria: o se acepta exposición al US CLOUD Act, o se autohospeda todo. | La soberanía es por decisión: pasos sensibles corren on-prem UE, pasos no sensibles pueden usar APIs cloud. |
| El Audit Trail existe en logs dispersos y se reconstruye bajo demanda. | El Audit Trail es el log de enrutado. El cumplimiento del artículo 13 EU AI Act es una consulta, no un proyecto. |
| Añadir un modelo nuevo significa una integración nueva. | Añadir un modelo nuevo significa añadirlo al router. Las reglas de enrutado ya existen. |

*Esta tabla muestra diferencias arquitectónicas, no juicios de calidad.*

El Decision Layer es donde la elección de modelo se operacionaliza. El mercado de modelos cambia cada mes. Los precios bajan. Nuevos flagships se publican. La calidad open-weight alcanza al líder. Una arquitectura con Decision Layer absorbe ese cambio. Una arquitectura atada a un vendor paga el coste de migración cada vez.

## En resumen

La pregunta interesante para un CIO o Director de Tecnología en una mediana empresa española en 2026 no es "Mistral o OpenAI". Es "qué porcentaje de mis decisiones agénticas necesita razonamiento flagship, y cómo se lo demuestro a mi auditor".

En un agente bien descompuesto, Mistral Small 3.2 sobre una única GPU UE hace la mayor parte del trabajo a coste por token negligible. Mistral Medium 3.1 sobre La Plateforme atiende la banda intermedia con soberanía UE preservada. Claude Opus 4.7 o GPT-5.5 atienden los casos genuinamente difíciles. El enrutado es la arquitectura. El Audit Trail es el artefacto de cumplimiento. El Decision Layer es el lugar donde todo eso se especifica.

Otros publican tablas comparativas de modelos. Nosotros construimos la capa de enrutado que las operacionaliza. El mercado de modelos cambia cada mes; la arquitectura de enrutado sobrevive a cinco generaciones de modelos. El código fuente queda con el cliente. Los modelos siguen intercambiables. El cumplimiento del artículo 13 del EU AI Act es una propiedad de la arquitectura, no un proyecto al final.

Si quieres saber cómo se ve realmente la distribución de complejidad de tu agente, [reserva una consulta](/es/contacto/).

--- Next.js sobre Supabase de forma segura ---
> Runbook DevOps para Next.js sobre Supabase: arquitectura, middleware, patrones de autenticación, rate limiting e integración con Claude Code.

Una vez que Supabase funciona de forma estable como plataforma backend [en producción](/es/revista/supabase-self-hosting/), se construye el stack de aplicación sobre ella.

En muchos proyectos modernos, **Next.js** asume el rol de capa de aplicación:

- Frontend Rendering
- Server Side Rendering
- Server Actions
- Route Handlers
- API Proxy
- Session Handling

Con ello, Next.js se convierte de facto en un **gateway backend entre el navegador y Supabase**.

El error más frecuente consiste en tratar esta capa como "frontend", cuando en realidad contiene **lógica del lado del servidor con privilegios elevados**.

Este runbook describe cómo operar Next.js de forma segura sobre una plataforma Supabase self-hosted.

Cada sección contiene:

- Implementación
- Condición verificable
- Escenario de fallo


<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">De un vistazo - Artículo 2 de 6 de la serie DevOps Runbook</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Next.js como contenedor separado aislado de Supabase</li>
<li>Clave service_role solo en un archivo</li>
<li>Middleware con getUser() en cada solicitud</li>
<li>Verificación de ownership antes de mutaciones</li>
<li>Rate limiting en endpoints de autenticación</li>
</ul>
</div>

## Índice de la serie

Esta guía forma parte de nuestra serie de runbooks DevOps para app stacks self-hosted.

1. [Supabase Self-Hosting Runbook](/es/revista/supabase-self-hosting/)
2. [Next.js sobre Supabase de forma segura](/es/revista/nextjs-supabase-configuracion-segura/) - este artículo
3. [Supabase Edge Functions de forma segura](/es/revista/supabase-edge-functions-seguridad/)
4. [Trigger.dev Background Jobs en producción segura](/es/revista/trigger-dev-background-jobs/)
5. [Claude Code como control de seguridad en el workflow DevOps](/es/revista/claude-code-security-devops/)
6. [Security Baseline para todo el stack](/es/revista/security-baseline-stack/)

El artículo 1 describe la base de la plataforma. Este artículo describe la **capa de aplicación sobre ella**.

## Visión general de la arquitectura

```
Browser (Client)
     |
     | HTTPS
     |
Next.js App Layer
     |
     +-- @supabase/ssr
     |
     +-- service_role client
           (solo contextos admin aislados)
     |
Supabase Platform Layer
     |
     +-- Kong API Gateway
     +-- GoTrue Auth
     +-- PostgREST API
     +-- Realtime
     |
PostgreSQL Data Layer
     |
     +-- Row Level Security
```

Reglas básicas:

```
Browser    -> solo se comunica con Next.js
Next.js    -> se comunica con Supabase
Supabase   -> controla el acceso mediante RLS
```

Cuando el navegador se comunica directamente con varios servicios backend, se generan fronteras de seguridad incontrolables.

## Parte A - Decisiones de arquitectura

Estas decisiones se modifican rara vez y constituyen los cimientos.

## A1 - Ejecutar Next.js como servicio independiente

### Implementación

Next.js se ejecuta como contenedor propio.

```
services

nextjs-app
supabase-stack
postgres
```

Ejemplo docker-compose:

```yaml
services:

  nextjs-app:
    build: ./app
    ports:
      - "3000:3000"
    environment:
      - NEXT_PUBLIC_SUPABASE_URL=http://kong:8000
      - NEXT_PUBLIC_SUPABASE_ANON_KEY=${ANON_KEY}
      - SUPABASE_SERVICE_ROLE_KEY=${SERVICE_ROLE_KEY}
    networks:
      - internal
```

Next.js **no debe ejecutarse dentro del stack de Supabase**.

### Condición verificable

```
docker ps --format '{{.Names}}'
```

Resultado esperado:

```
nextjs-app
supabase-kong
supabase-postgres
supabase-auth
```

### Escenario de fallo

Si Next.js se ejecuta en el mismo contenedor que Supabase:

- Se comparte el espacio de procesos
- Los secrets residen en el mismo entorno
- Un servidor Next.js comprometido tiene acceso directo a todos los servicios backend

## A2 - El navegador solo se comunica con Next.js

### Implementación

El navegador solo debe ver una URL pública.

```
https://app.example.com
```

No permitido:

```
https://app.example.com:8000
https://app.example.com:5432
https://app.example.com:9000
```

Ejemplo de firewall:

```
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -p tcp --dport 8000 -j DROP
iptables -A INPUT -p tcp --dport 5432 -j DROP
iptables -A INPUT -p tcp --dport 9000 -j DROP
```

### Condición verificable

```
nmap -p 443,3000,5432,8000,9000 app.example.com
```

Resultado esperado:

```
443 open
todos los demás filtered
```

### Escenario de fallo

Si Supabase Studio es accesible públicamente:

- Acceso completo a la base de datos
- Manipulación del esquema
- Acceso a los Storage Buckets

## A3 - Configurar Security Headers

Next.js actúa como gateway y debe establecer HTTP Security Headers.

### Implementación

```
next.config.js
```

```javascript
const securityHeaders = [
  { key: "X-Frame-Options", value: "DENY" },
  { key: "X-Content-Type-Options", value: "nosniff" },
  { key: "Referrer-Policy", value: "strict-origin-when-cross-origin" },
  { key: "Permissions-Policy", value: "camera=(), microphone=()" },
  { key: "Strict-Transport-Security", value: "max-age=63072000; includeSubDomains" },
  {
    key: "Content-Security-Policy",
    value: "default-src 'self'; img-src 'self' data: blob:; frame-ancestors 'none'"
  }
]
```

### Condición verificable

```
curl -I https://app.example.com
```

Headers esperados:

```
X-Frame-Options
Content-Security-Policy
Strict-Transport-Security
```

### Escenario de fallo

Sin CSP:

- Los ataques XSS cargan scripts externos
- Los tokens pueden ser exfiltrados


### Variables de entorno

| Variable | Visibilidad | Ubicación permitida | Riesgo de filtración |
|---|---|---|---|
| NEXT_PUBLIC_SUPABASE_URL | Cliente | .env, código cliente | Bajo (URL pública) |
| NEXT_PUBLIC_SUPABASE_ANON_KEY | Cliente | .env, código cliente | Medio (limitado por RLS) |
| SUPABASE_SERVICE_ROLE_KEY | Solo servidor | lib/supabase/admin.ts | Crítico (omite RLS) |
| DATABASE_URL | Solo servidor | .env (servidor) | Crítico (acceso directo a DB) |
| TRIGGER_API_KEY | Solo servidor | .env (servidor) | Alto (acceso a cola de tareas) |

## Parte B - Verificaciones de implementación

Estas reglas se aplican a cada cambio de código.

## B1 - Separar variables de entorno

Visibles para el cliente:

```
NEXT_PUBLIC_SUPABASE_URL
NEXT_PUBLIC_SUPABASE_ANON_KEY
```

Solo servidor:

```
SUPABASE_SERVICE_ROLE_KEY
DATABASE_URL
TRIGGER_API_KEY
```

### Condición verificable

```
grep -r "NEXT_PUBLIC_" .env*
```

Los secrets no deben aparecer ahí.

### Build Leak Check

```
grep -r "SERVICE_ROLE" .next/
```

Resultado esperado:

```
ninguna coincidencia
```

### Escenario de fallo

`service_role` en el bundle del cliente significa:

- Acceso completo a la base de datos
- RLS completamente inoperante

Quien conoce los [fundamentos de la gestión de secrets](/es/revista/seguridad-datos-ia-enterprise/) comprende por qué esta separación es esencial.

## B2 - Configurar correctamente el cliente Supabase SSR

Cliente del servidor:

```typescript
import { createServerClient } from "@supabase/ssr"
```

El servidor utiliza la **anon key**, no service_role.

Cliente admin:

```typescript
createClient(url, SERVICE_ROLE_KEY)
```

Solo para tareas administrativas.

### Condición verificable

```
grep -rn "SERVICE_ROLE" app/
```

Resultado esperado: solo en

```
lib/supabase/admin.ts
```

### Escenario de fallo

Cliente del servidor con service_role:

- RLS se omite completamente
- Todas las peticiones tienen privilegios de administrador

## B3 - Middleware para Auth y Token Refresh

La middleware se ejecuta **antes de cada petición**.

```
middleware.ts
```

### Implementación

```typescript
const { data: { user } } = await supabase.auth.getUser()
```

No:

```
getSession()
```

### Condición verificable

```
grep getUser middleware.ts
```

### Escenario de fallo

Sin middleware:

- El refresco de tokens no funciona
- La sesión se interrumpe tras 1h

## B4 - Patrón de mutación

Todas las mutaciones siguen el mismo flujo.

```
Auth
Input Validation
Ownership Check
Mutation
Logging
```

### Ejemplo

```typescript
const { user } = await supabase.auth.getUser()

if (!user) return

const post = await supabase
  .from("posts")
  .select("user_id")
  .eq("id", postId)

if (post.user_id !== user.id)
  throw new Error("forbidden")
```

### Escenario de fallo

Sin Ownership Check:

> **Estadística:** Según investigaciones de GitHub de 2024, más del 23% de las filtraciones de secrets en proyectos web involucran claves service_role o tokens backend equivalentes.


```
deletePost(id)
```

Un usuario puede eliminar datos ajenos.

## B5 - Rate Limiting

Next.js no tiene rate limiting integrado.

Solución recomendada:

```
Upstash Redis
```

### Ejemplo

```
10 requests / minute / IP
```

### Condición verificable

```
for i in {1..20}
do curl -X POST /api/login
done
```

Resultado esperado:

```
HTTP 429
```

## B6 - Logging sin secrets

Los logs no deben contener:

```
JWT Tokens
service_role keys
emails
passwords
```

### Condición verificable

```
grep console.log app/
```

## Parte C - Operación

## C1 - Actualización de dependencias

Los releases de Next.js son frecuentes.

Verificar semanalmente:

```
npm audit
npm outdated
```

Recomendado:

```
Renovate / Dependabot
```

## C2 - Integración de Claude Code

Arquitectura:

```
Git Push
   |
Verificaciones deterministas
   |
Informe de seguridad
   |
Análisis de Claude
   |
Decisión DevOps
```

### Verificaciones deterministas

```
grep service_role
grep NEXT_PUBLIC
npm audit
```

### Análisis de Claude

Claude verifica:

- Nuevas Server Actions
- Nuevas API Routes
- Patrones de Ownership
- Validación de entrada
- Deriva arquitectónica

Claude **no ejecuta cambios en producción**.

## Lista de verificación de despliegue

Verificar antes de cada despliegue:

```
[ ] Next.js se ejecuta como servicio independiente
[ ] Puertos de Supabase cerrados externamente
[ ] Security Headers activos

[ ] Ningún service_role en el bundle del cliente
[ ] service_role solo en el cliente admin

[ ] middleware.ts presente
[ ] Server Actions verifican Auth
[ ] Ownership Checks implementados

[ ] Rate Limit de login activo

[ ] npm audit sin hallazgos críticos
```

## Conclusión

Next.js en el stack moderno no es un frontend, sino una capa de servidor privilegiada.

La seguridad se construye mediante tres niveles:

```
Arquitectura
Verificaciones de implementación
Auditorías continuas
```

La combinación de verificaciones de seguridad en CI y análisis con Claude Code detecta tanto patrones conocidos como nuevos riesgos.

Quien aplica estos principios junto con una [arquitectura Cert-Ready by Design](/es/revista/cert-ready-by-design/) construye seguridad verificable en lugar de auditorías posteriores.

<div class="not-prose my-12 border border-gosign-border bg-gosign-light rounded-card p-6 lg:p-8">
<div class="flex items-start gap-4">
<div class="flex-shrink-0 w-12 h-12 bg-gosign-dark rounded-card flex items-center justify-center">
<svg width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="white" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 15v4a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2v-4"/><polyline points="7 10 12 15 17 10"/><line x1="12" y1="15" x2="12" y2="3"/></svg>
</div>
<div>
<h2 class="text-h3 font-bold text-gosign-dark mb-2" id="descarga-de-la-lista-de-verificacion">Descarga de la lista de verificación</h2>
<p class="text-body text-gosign-text mb-2">Prompt preparado para Claude Code. Suba el archivo a su servidor e inicie Claude Code en el directorio del proyecto de su aplicación Next.js. Claude Code verificará automáticamente todos los puntos de seguridad de este runbook e informará APROBADO, ADVERTENCIA o CRÍTICO.</p>
<p class="text-sm text-gosign-text mb-4 font-mono">claude -p "$(cat claude-check-artikel-2-nextjs-es.md)" --allowedTools Read,Grep,Glob,Bash</p>
<a href="/downloads/claude-check-artikel-2-nextjs-es.md" download class="inline-flex items-center px-6 py-3 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-small uppercase tracking-wider">Descargar checklist</a>
</div>
</div>
</div>

## Índice de la serie

1. [Supabase Self-Hosting Runbook](/es/revista/supabase-self-hosting/)
2. [Next.js sobre Supabase de forma segura](/es/revista/nextjs-supabase-configuracion-segura/) - este artículo
3. [Supabase Edge Functions de forma segura](/es/revista/supabase-edge-functions-seguridad/)
4. [Trigger.dev Background Jobs en producción segura](/es/revista/trigger-dev-background-jobs/)
5. [Claude Code como control de seguridad en el workflow DevOps](/es/revista/claude-code-security-devops/)
6. [Security Baseline para todo el stack](/es/revista/security-baseline-stack/)

El siguiente artículo describe cómo **utilizar Supabase Edge Functions de forma segura** - sin construir una segunda arquitectura backend.

--- Orquestación de agentes: Trigger.dev, n8n, Camunda y más ---
> ¿Dónde se ejecutan sus agentes de IA? Trigger.dev, n8n, Camunda, Temporal, Make y Activepieces en comparativa enterprise.

## Sabe qué son los agentes. Ahora: ¿Dónde se ejecutan?

Ya sabe qué son los [agentes de IA](/es/revista/que-son-agentes-ia/), cómo se comunican con sus sistemas (MCP, A2A) y cómo controla las decisiones ([Decision Layer](/es/revista/decision-layer-shadow-ai/)). La siguiente pregunta es concreta: ¿En qué plataforma orquesta estos agentes? ¿Dónde define los workflows que conectan un modelo de lenguaje con sus procesos de negocio?

La respuesta depende de dónde se encuentra su empresa: ¿Necesita resultados rápidos con automatización visual de workflows, o tiene procesos empresariales complejos y de larga duración que requieren control conforme a BPMN y documentación lista para auditoría?

Este artículo compara las seis plataformas más relevantes, explica los dos enfoques fundamentalmente diferentes y ofrece una recomendación clara sobre cuándo cada plataforma es la elección correcta. Porque la plataforma de orquestación determina si su arquitectura de agentes escala, o se queda estancada en el Proof of Concept.

Gartner (2024) prevé que en 2028, el 33% de las aplicaciones de software empresarial incluirán IA agéntica, frente a menos del 1% en 2024. La plataforma de orquestación que elija hoy determina si su organización estará preparada para ese cambio.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">De un vistazo - Plataformas de orquestación de agentes</p>
<ul class="text-body text-gosign-text space-y-2">
<li>El mercado se divide en herramientas visuales de workflow (n8n, Make, Activepieces) para prototipado rápido y motores de orquestación de procesos (Camunda, Temporal, Trigger.dev) para ejecución en producción.</li>
<li>Trigger.dev es la recomendación por defecto: TypeScript-nativo, Durable Execution, licencia Apache 2.0, auto-hospedable, productivo en dos semanas.</li>
<li>Camunda complementa cuando se requieren diagramas BPMN formales para comités de empresa o auditores.</li>
<li>Cinco de seis plataformas soportan self-hosting - Make (solo SaaS) es la excepción.</li>
<li>La elección de plataforma es una decisión arquitectónica que afecta governance, compliance y time-to-production.</li>
</ul>
</div>

## Los dos mundos de la orquestación

El mercado de orquestación de workflows en 2026 se divide en dos categorías que resuelven problemas diferentes. Comprender esta distinción es fundamental para la elección correcta de plataforma.

### Visual Workflow Automation

Plataformas como n8n, Make y Activepieces siguen el mismo principio: los workflows se construyen visualmente haciendo clic. Un trigger, un nuevo correo, un documento entrante, un webhook, inicia una cadena de acciones. Cada acción es un nodo en el workflow: leer datos, llamar a un modelo de IA, enviar un correo, escribir un registro en un sistema ERP. La cadena se ensambla en el editor visual, se prueba y se activa.

La ventaja: Resultados rápidos, baja barrera de entrada, utilizable incluso por personas no técnicas. Un workflow de agente funcional puede estar en pie en días en lugar de semanas. Los modelos de IA se integran en el workflow como cualquier otro servicio, como un nodo más entre muchos.

La desventaja: En procesos complejos y de larga duración con decenas de puntos de decisión y aprobaciones humanas, las herramientas visuales encuentran sus límites. Caminos paralelos, bifurcaciones condicionales en múltiples niveles, procesos que duran semanas y esperan entradas humanas: esa no es la fortaleza de los editores visuales.

### Process Orchestration Engines

Plataformas como Camunda y Temporal adoptan un enfoque diferente. En Camunda, los procesos se modelan como diagramas formales BPMN 2.0, un estándar internacional que también pueden leer comités de empresa, auditores y departamentos funcionales. En Temporal, los workflows se escriben como código en Go, Java, TypeScript o Python.

La ventaja común: Cada paso está versionado y es auditable. Las aprobaciones humanas (Human Tasks) son un componente central de la arquitectura, no un workaround. Los procesos pueden durar semanas o meses sin perder integridad técnica. El compliance de nivel enterprise está integrado nativamente.

La desventaja: Mayor barrera de entrada. Camunda requiere conocimientos de BPMN y experiencia con motores de procesos. Temporal requiere desarrolladores que escriban workflows en código. Para un prototipo rápido suele ser demasiado esfuerzo.

La decisión entre estos dos mundos no es cuestión de mejor o peor. Es cuestión del grado de madurez, los requisitos de compliance y la disposición organizativa.

## Plataformas en comparativa

La siguiente tabla confronta las seis plataformas más relevantes. Considera tipo, capacidad de self-hosting, integración de IA, fortaleza principal, adecuación enterprise y modelo de licencia.

| Plataforma | Tipo | Self-Hosted | Integración AI/LLM | Fortaleza | Adecuación enterprise | Licencia |
|---|---|---|---|---|---|---|
| **n8n** | Visual Workflow | Sí (Docker, k8s) | Nodos AI nativos, integración LangChain | 400+ integraciones, editor visual, prototipos rápidos, comunidad activa | Media-Alta | Fair Source (gratis <3 instancias) |
| **Camunda** | BPMN Process Engine | Sí (Self-Managed) o Camunda Cloud | Conectores para APIs de LLM, Custom Worker para lógica de agente | BPMN 2.0, Human Tasks, Audit Trail, Compliance-ready, procesos de larga duración | Muy alta | Community Edition (Apache 2.0) + Enterprise Edition |
| **Make** (ex Integromat) | Visual Workflow | No (solo SaaS) | Módulos AI | Entrada más sencilla, visualmente intuitivo, buen soporte | Baja-Media | Propietaria (SaaS) |
| **Temporal** | Code-first Orchestration | Sí (Docker, k8s) | Cualquier integración LLM en código Worker | Durable Execution, Retry/Timeout nativo, extremadamente fiable | Alta | MIT (Core) + Commercial (Cloud) |
| **Activepieces** | Visual Workflow | Sí (Docker) | AI-Pieces | Alternativa open-source a n8n/Make, licencia MIT | Media | MIT |
| **Trigger.dev** | Code-first (TypeScript) | Sí (Docker, k8s) | Cualquier LLM en código de tareas | TypeScript-native, Durable Execution, Retry nativo, Developer-first | Alto | Apache 2.0 |

Tres observaciones de la tabla:

**El self-hosting es posible en cinco de seis plataformas.** Make es la excepción: como servicio SaaS puro, los datos de sus workflows abandonan su red. Para empresas con requisitos de soberanía de datos, Make queda descartada para workflows productivos de agentes con datos sensibles.

**La integración de IA es posible en todas las plataformas**, pero con diferente profundidad. n8n ofrece nodos AI nativos que integran modelos de lenguaje directamente en el editor visual. Camunda y Temporal requieren más trabajo de desarrollo, pero ofrecen control total sobre la interacción con el modelo.

**Los modelos de licencia difieren considerablemente.** Activepieces (MIT) y Camunda Community Edition (Apache 2.0) ofrecen la mayor libertad. n8n (Fair Source) es gratuito para setups pequeños, se vuelve de pago al escalar. Temporal (MIT Core) es gratuito en su núcleo, la variante cloud es de pago.

## ¿Cuándo cada plataforma?

### n8n: cuando quiere empezar rápido

¿Necesita en dos semanas un agente funcional que extraiga facturas de un buzón de correo, las clasifique mediante un modelo de lenguaje y las contabilice en su ERP? n8n es su elección.

El editor visual permite crear workflows sin programación clásica. Los nodos AI están nativamente integrados: puede incorporar un modelo de lenguaje en el workflow como cualquier otro servicio. Self-hosting con Docker significa: sus datos no abandonan su red. La comunidad proporciona más de 400 integraciones, desde correo y calendario hasta sistemas CRM y bases de datos.

Para el primer [agente de IA](/es/servicios/ai-agents/), n8n es en muchos casos la plataforma de inicio adecuada. El workflow se monta en días, los resultados son inmediatamente visibles y el departamento funcional puede seguir el workflow en el editor.

**El compromiso:** Los workflows de n8n funcionan bien para automatizaciones secuenciales y bifurcaciones simples. En procesos con caminos paralelos, bucles de aprobación humana de varios días o requisitos de compliance en versionado y auditoría completa, se queda corto. n8n registra ejecuciones, pero no ofrece modelado BPMN nativo, definiciones de procesos versionadas ni Human Tasks como concepto arquitectónico.

### Camunda: cuando el compliance no es negociable

¿Su comité de empresa quiere rastrear qué agente tomó qué decisión? ¿Sus auditores necesitan un Audit Trail completo? ¿El proceso dura semanas, por ejemplo onboarding, aprobación de contratos, autorización de compras? Entonces necesita un motor BPMN.

Camunda modela procesos como diagramas formales (BPMN 2.0) que cualquier interlocutor de negocio puede leer, incluido el Comité de Empresa. Human Tasks son un concepto central: en puntos definidos, el proceso espera la aprobación humana. Cada decisión está versionada y es trazable. Los agentes de IA se integran como Service Tasks: el modelo de lenguaje se convierte en un paso del proceso de negocio, no en una caja negra.

La Community Edition bajo Apache 2.0 es totalmente autohospedable. La Enterprise Edition ofrece adicionalmente clustering, funciones de monitorización avanzadas y soporte profesional. Para empresas que utilizan el [Decision Layer](/es/revista/decision-layer-shadow-ai/) como arquitectura de governance, Camunda es la elección natural para la capa de ejecución: los procesos BPMN representan las micro-decisiones, los Human Tasks imponen aprobaciones humanas y el Audit Trail se genera automáticamente.

### Temporal: cuando sus desarrolladores necesitan control total

Temporal es code-first: los workflows se escriben en Go, Java, TypeScript o Python. Sin editor visual, pero con control máximo sobre lógica de reintentos, timeouts y gestión de errores.

Para agentes de IA que ejecutan tareas complejas y multietapa con duraciones impredecibles, como análisis de documentos con consultas de seguimiento, validaciones multietapa o procesamiento por lotes de grandes volúmenes de datos, Temporal es la opción más robusta. El concepto de "Durable Execution" asegura que los workflows continúen incluso ante caídas de servidores, interrupciones de red o timeouts de modelos.

**El compromiso:** Temporal requiere desarrolladores que dominen workflow-as-code. Los departamentos funcionales no pueden ajustar los workflows de Temporal en un editor. Para empresas sin un equipo de desarrollo fuerte, Temporal no es una opción. Para empresas con desarrolladores experimentados que necesitan máxima fiabilidad en workflows complejos de agentes, es la mejor.

### Trigger.dev: el estándar emergente para la orquestación de agentes

Trigger.dev se ha consolidado en 2025/2026 como una de las plataformas de orquestación de mayor crecimiento. La razón: los workflows se escriben en TypeScript - el lenguaje que ya domina la mayor parte del desarrollo web moderno. Sin editor visual, sin lenguaje adicional. Si ya tiene TypeScript en su stack, orquesta agentes en el mismo lenguaje, el mismo IDE, el mismo sistema CI/CD.

La plataforma es utilizada por un número creciente de organizaciones - desde startups de IA hasta empresas SaaS y equipos enterprise que ejecutan workflows de agentes en producción. La activa comunidad open-source en GitHub, releases regulares y una developer experience alineada con estándares modernos hacen de Trigger.dev la elección natural para equipos que ya trabajan en TypeScript.

Durable Execution está integrado: cada tarea sobrevive fallos de servidor, problemas de red y timeouts de modelos. La lógica de reintentos, timeouts y manejo de errores se definen en código, no se configuran en una interfaz. El historial completo de ejecución es inspeccionable, cada paso es rastreable. Esto hace que Trigger.dev sea adecuado no solo para prototipos, sino para workflows productivos - desde clasificación de correos hasta procesamiento de documentos y cadenas de agentes multietapa.

Self-hosting con Docker o Kubernetes está completamente soportado. La licencia Apache 2.0 garantiza que no hay límites de uso. Sin dependencias Java (como Temporal), sin overhead BPMN (como Camunda), sin editor visual que frena con la complejidad (como n8n).

**El compromiso:** Trigger.dev requiere desarrolladores TypeScript. Los usuarios de negocio no pueden modificar workflows en un editor. Para equipos Go o Java, Temporal es la mejor opción. Cuando se requieren diagramas BPMN formales por parte de comités de empresa o auditores, Camunda complementa la arquitectura.

## Recomendación práctica: Trigger.dev como estándar, Camunda para requisitos BPMN

Trigger.dev es adecuado como plataforma de orquestación principal - desde el primer agente hasta la operación productiva. Los workflows basados en TypeScript se integran directamente en el proceso de desarrollo existente: versionados en Git, testeados en CI, desplegables con las mismas herramientas que el resto de su stack. Un agente funcional en dos semanas convence a la dirección más que un concepto de arquitectura en dos meses.

Trigger.dev escala más allá del primer use case. Durable Execution, historiales de ejecución completos y una licencia Apache 2.0 sin límites de instancias hacen la plataforma adecuada también para workflows enterprise productivos. Muchas organizaciones ejecutan toda su orquestación de agentes en Trigger.dev - desde clasificación de correos hasta procesamiento de documentos y cadenas de agentes multietapa con docenas de tareas.

Camunda entra en juego cuando se requieren diagramas BPMN formales - típicamente para procesos que deben ser legibles para comités de empresa, auditores o revisores de compliance externos. No porque Trigger.dev no esté listo para producción, sino porque BPMN es un formato de comunicación que también entienden los no-desarrolladores.

La distinción clave: la capacidad de compliance no es cuestión de la plataforma, sino de la implementación. Audit Trail, [Decision Layer](/es/revista/decision-layer-shadow-ai/), Human-in-the-Loop y trazabilidad completa se pueden construir directamente en workflows de Trigger.dev - como código TypeScript versionado y testeable. Gosign implementa esta capa de governance por defecto en cada solución de agentes: cada decisión se registra, cada aprobación humana se documenta, cada paso del proceso es trazable en el Audit Trail. La única razón para Camunda no es el compliance técnico - eso lo entrega Trigger.dev - sino la legibilidad organizacional: un comité de empresa o auditor puede leer un diagrama BPMN, pero no código TypeScript. Cuando su equipo de desarrollo o un partner especializado como Gosign construye la capa de compliance en código, Trigger.dev cubre todos los requisitos.

Ambas pueden coexistir: Trigger.dev como estándar para todo tipo de workflows de agentes - clasificación de correos, extracción de datos, cadenas de agentes multietapa, automatizaciones internas. Camunda para los procesos clave modelados en BPMN donde los diagramas formales son un requisito de compliance: onboarding, aprobación de contratos, autorización de compras. La separación sigue la pregunta: ¿Este proceso necesita existir como diagrama BPMN formal? Si la respuesta es sí, Camunda complementa. Si es no, Trigger.dev.

Para empresas que apuestan por alternativas con licencia MIT, Activepieces es una opción válida en el área de workflows visuales. La plataforma ofrece menos integraciones que n8n, pero la licencia abierta elimina la cuestión de costes al escalar.

## Integración con la arquitectura de agentes

La plataforma de orquestación no está aislada. Es la capa de ejecución en la [arquitectura de agentes](/es/revista/que-son-agentes-ia/) que conecta todos los componentes. El siguiente diagrama muestra cómo interactúan las capas:

```
+-----------------------------------------+
|         Enterprise-AI-Portal            |
|  (LobeChat / OpenWebUI / LibreChat /    |
|   chatbot-ui / very-ai)                 |
+------------------+----------------------+
|
+------------------v----------------------+
|     Plataforma de orquestacion          |
|  (Trigger.dev / Camunda / Temporal)     |
|                                         |
|  +-----+  +---------+  +------------+  |
|  |Paso |->| LLM     |->| Decision   |->|
|  |  1  |  | Analisis|  | Layer      |  |
|  +-----+  +---------+  +------------+  |
+------------------+----------------------+
|
+--------------+---------------+
v              v               v
+--------+  +----------+  +----------+
|  RAG / |  |  ERP /   |  | Correo / |
| Vector |  |  CRM     |  |Calendario|
|   DB   |  |          |  |          |
+--------+  +----------+  +----------+
```

Cada capa tiene una tarea definida:

- El **[Enterprise-AI-Portal](/es/revista/enterprise-ai-chat-interface/)** es la interfaz a través de la cual los usuarios inician agentes y consultan resultados. Los empleados no interactúan directamente con la plataforma de orquestación, utilizan el portal. La conexión es particularmente fluida cuando el portal incluye integración nativa de workflows. very-ai puede disparar workflows de Trigger.dev directamente desde el chat: el usuario escribe una solicitud, el agente analiza y Trigger.dev ejecuta el proceso de seguimiento. Con otros portales, esta conexión debe establecerse a través de webhooks o middleware API.
- La **plataforma de orquestación** (este artículo) define el workflow: qué pasos en qué orden, qué condiciones aplican y qué ocurre ante errores. Es la central de ejecución de los agentes.
- El **modelo de IA** realiza el análisis: comprender texto, extraer documentos, preparar decisiones. En una arquitectura agnóstica de modelo, se selecciona el modelo adecuado por paso.
- El **[Decision Layer](/es/revista/decision-layer-shadow-ai/)** controla en cada punto de decisión si la IA puede actuar autónomamente, si aplica un conjunto de reglas o si una persona debe aprobar.
- **RAG** proporciona al modelo el contexto de sus documentos corporativos: contratos, directrices, manuales.

La plataforma de orquestación conecta estos componentes en un workflow funcional. Sin ella, los componentes individuales quedan aislados: un modelo de lenguaje que puede analizar documentos, pero nadie ha definido qué pasa después. Un pipeline RAG que encuentra secciones relevantes, pero ningún workflow lleva los resultados más allá. Un Decision Layer que define reglas, pero ningún sistema las ejecuta.

La elección de plataforma determina lo bien que funciona esta integración. Trigger.dev hace la integración nativa en TypeScript: los workflows son código versionado en Git. Camunda hace la integración formalmente trazable: ve el proceso como diagrama BPMN. Temporal hace la integración robusta: tiene control total sobre gestión de errores y lógica de reintentos.

## Modelos de licencia en detalle

Para los decisores enterprise, la cuestión de la licencia no es trivial. Las diferencias tienen impacto directo en costes, escalabilidad y dependencia del proveedor.

**n8n (Fair Source):** El código fuente es accesible y autohospedable. Para hasta tres instancias el uso es gratuito. A partir de la cuarta instancia se requiere licencia Enterprise. Para empresas que comienzan con un único setup de n8n, no es un obstáculo. Al escalar a múltiples equipos o sedes, surgen costes de licencia.

**Camunda (Apache 2.0 + Enterprise):** La Community Edition es completamente open source bajo Apache 2.0, sin restricciones. La Enterprise Edition ofrece clustering, observabilidad avanzada y soporte profesional. Para empezar basta la Community Edition. Para uso enterprise productivo con alta disponibilidad se recomienda la Enterprise Edition.

**Temporal (MIT + Commercial):** El servidor Core está licenciado bajo MIT, totalmente libre. La variante cloud (Temporal Cloud) es un servicio comercial. Para self-hosting no se necesita contrato de licencia. Para empresas que no quieren asumir la operación, Temporal Cloud ofrece una alternativa gestionada.

**Trigger.dev (Apache 2.0):** Completamente open source bajo Apache 2.0. Sin restricciones de instancias, sin límites de uso. Self-hosting con Docker o Kubernetes completamente soportado. Para organizaciones TypeScript, la opción más directa: mismo modelo de licencia que Camunda Community Edition, sin las restricciones de Fair Source de n8n.

**Activepieces (MIT):** Completamente open source bajo licencia MIT. Sin restricciones, sin límites de uso. La opción menos restrictiva. A cambio, un ecosistema menor y menos integraciones que n8n.

**Make (propietaria):** Modelo SaaS puro. Sin self-hosting, sin acceso al código. Para entornos enterprise con requisitos de soberanía de datos no es apto. Para automatizaciones rápidas y no sensibles, una opción válida si los datos pueden abandonar la red corporativa.

## Checklist: ¿Qué plataforma encaja en su escenario?

La siguiente lógica de decisión ayuda en la primera orientación:

**Escenario 1: Workflows de agentes en TypeScript, del primer use case a producción**
Recomendación: Trigger.dev. Workflows TypeScript, versionados en Git, testeados en CI. Self-hosting con Docker. Productivo en dos semanas, código revisable por todo el equipo de desarrollo. Escala del primer agente a docenas de workflows productivos.

**Escenario 2: Procesos que exigen compliance, comité de empresa, requisitos de auditoría**
Recomendación: Camunda. BPMN 2.0, Human Tasks, procesos versionados, Audit Trail completo. Community Edition bajo Apache 2.0 para empezar, Enterprise Edition para producción.

**Escenario 3: Workflows complejos y de larga duración con tiempos de ejecución impredecibles**
Recomendación: Temporal. Code-first, control máximo, Durable Execution. Requiere conocimiento de desarrollo.

**Escenario 4: Ambos, automatizaciones rápidas y procesos auditados clave**
Recomendación: Trigger.dev y Camunda en paralelo. Trigger.dev para automatizaciones internas, Camunda para procesos que exigen compliance. Comunicación via APIs y webhooks.

**Escenario 5: Licencia MIT sin compromisos**
Recomendación: Activepieces para workflows visuales, Temporal Core para workflows code-first.

## Próximos pasos

La plataforma de orquestación es un medio, no un fin en sí mismo. La plataforma correcta por sí sola no crea un agente funcional. Para eso necesita la [infraestructura](/es/servicios/infraestructura/) completa: modelos de IA, hosting, un portal Enterprise-AI como interfaz y una arquitectura de governance que asegure el compliance.

Gosign apoya en la selección e implementación de la plataforma de orquestación adecuada, desde la evaluación hasta el primer PoC y la operación productiva. Agnóstico de modelo, neutral en cuanto a fabricante, con acceso completo al código fuente.

---

**¿Qué proceso debería asumir su primer agente?**

<a href="/es/contacto/" target="_blank" rel="noopener noreferrer">Solicitar cita</a>. 30 minutos en los que identificamos el primer use case adecuado y la plataforma de orquestación correcta para su empresa.

--- Anonimización de PII para IA Empresarial ---
> Cómo procesar documentos con datos personales conforme al RGPD con IA. Pseudonimización roundtrip, Decision Layer, Audit Trail.

## Por qué los datos personales son un problema para el procesamiento con IA

Cuando un agente de IA analiza un contrato laboral, revisa una nómina o procesa un parte de baja, trabaja con datos personales. Nombre, dirección, fecha de nacimiento, número de la Seguridad Social, salario, diagnóstico.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">De un vistazo - Anonimización de PII para IA empresarial</p>
<ul class="text-body text-gosign-text space-y-2">
<li>La pseudonimización roundtrip sustituye PII por pseudónimos coherentes antes del procesamiento por LLM, y reinserta los datos reales en la salida.</li>
<li>El Decision Layer gobierna qué categorías de PII se detectan por proceso (RRHH, finanzas, compliance) mediante conjuntos de reglas versionados.</li>
<li>La pseudonimización preserva la estructura y el contexto del documento - a diferencia de la supresión, que inutiliza los documentos para análisis con IA.</li>
<li>El Confidence Routing escala entidades ambiguas a un humano; los identificadores implícitos requieren reglas de contexto en el conjunto de reglas.</li>
<li>IAPP (2024) detecta que el 58% de las organizaciones que procesan documentos con IA carecen de detección sistemática de PII, exponiéndose al riesgo de aplicación del RGPD.</li>
</ul>
</div>

Enviar estos datos a un modelo de lenguaje, incluso a uno autoalojado, plantea un riesgo de cumplimiento con el RGPD. El reglamento exige la [minimización de datos](/es/governance/data-residency/) (art. 5.1.c): solo pueden procesarse los datos necesarios para la finalidad. Para clasificar un tipo de documento, el modelo no necesita el nombre del empleado. Para verificar la adecuación salarial, no necesita la fecha de nacimiento.

Sin embargo, el modelo necesita contexto. Un contrato desprovisto de toda información personal resulta inútil para el análisis con IA: faltan las referencias, las relaciones y las conexiones.

La solución no es la supresión, sino la pseudonimización.

## Pseudonimización roundtrip: el principio

La pseudonimización roundtrip es un proceso en tres fases:

**Paso 1: Detectar y sustituir.** La capa de preprocesamiento identifica todos los datos personales del documento. Cada instancia de PII se sustituye por un pseudónimo coherente: "Carlos García" se convierte en "Persona_A", "45.000 EUR" se convierte en "Salario_A", "Calle Gran Vía 8" se convierte en "Dirección_A". Lo fundamental: los pseudónimos son coherentes. Si "Carlos García" aparece de nuevo en la página 3, sigue siendo "Persona_A". Esto preserva la estructura del documento.

**Paso 2: Procesar.** El documento pseudonimizado se envía al modelo de lenguaje. El modelo ve: "Persona_A tiene Salario_A en Dirección_A. El contrato es vigente hasta 2027." Puede realizar el análisis contractual, la verificación de bandas salariales, la clasificación de cláusulas, sin haber visto nunca un nombre o salario real.

**Paso 3: Re-anonimizar.** La salida del modelo contiene pseudónimos: "Persona_A se sitúa dentro de la banda salarial E3." La capa de re-anonimización sustituye los pseudónimos por los datos reales: "Carlos García se sitúa dentro de la banda salarial E3." La tabla de asignación se elimina tras el procesamiento.

## Qué controla el Decision Layer

No todos los campos de datos requieren pseudonimización. El Decision Layer define qué categorías de PII se detectan y sustituyen, gobernado por conjuntos de reglas versionados:

Para un proceso de RRHH: pseudonimizar nombres, salarios, direcciones, números de la Seguridad Social. Los cargos y departamentos pueden permanecer: son relevantes para el análisis y no constituyen datos personales.

Para un proceso financiero: los nombres de empresa permanecen, las personas de contacto se pseudonimizan, los importes permanecen (son necesarios para las decisiones contables), los datos bancarios se pseudonimizan.

Para un proceso de compliance: pseudonimizar todo, incluidos los nombres de empresa, si el análisis debe ser transversal.

Estas reglas son específicas por mandante y están versionadas. Cuando cambia un acuerdo de empresa, se crea una nueva versión de reglas. En una auditoría es trazable qué regla de PII, en qué versión, estaba vigente en el momento del procesamiento.

## Limitaciones y valoración honesta

La detección de PII no es perfecta. El reconocimiento de entidades nombradas (NER) comete errores, especialmente con:

Nombres ambiguos: "Pastor" puede ser un apellido o una profesión. "León" puede ser una ciudad o un apellido. El Decision Layer lo aborda mediante Confidence Routing: con alta confianza, la pseudonimización es automática. Con baja confianza, se escala a una persona.

Identificadores implícitos: "La única desarrolladora de la oficina de Barcelona" no contiene PII explícita, pero identifica a una persona. Estos identificadores indirectos son difíciles de detectar automáticamente. El enfoque: las reglas de contexto en el conjunto de reglas definen qué combinaciones de atributos permiten la identificación.

Nuevos tipos de documentos: cuando se procesa un nuevo tipo de documento, el conjunto de reglas de PII debe revisarse y, en su caso, ampliarse. Esto no es una configuración única, sino un proceso continuo.

| Categoría PII | Proceso RRHH | Proceso financiero | Proceso compliance |
|---|---|---|---|
| Nombres | Pseudonimizados | Contactos pseudonimizados | Todo pseudonimizado |
| Salarios / Importes | Pseudonimizados | Permanecen (decisiones contables) | Pseudonimizados |
| Direcciones | Pseudonimizadas | Permanecen | Pseudonimizadas |
| Números de identificación (SS) | Pseudonimizados | Pseudonimizados | Pseudonimizados |
| Nombres de empresa | Permanecen | Permanecen | Pseudonimizados |
| Cargos | Permanecen | Permanecen | Según contexto |
| Datos bancarios | Pseudonimizados | Pseudonimizados | Pseudonimizados |

Más sobre Document Intelligence: [Document Intelligence - PII, redacción de contratos, detección de firmas](/es/servicios/document-intelligence/)

<a href="/es/contacto/" target="_blank" rel="noopener noreferrer">Agendar reunión</a> - Le mostramos la pseudonimización roundtrip con sus documentos.

--- Por qué fracasan los proyectos de IA en RRHH ---
> Los proyectos de IA no fracasan por tecnologia sino por falta de reglas. Por que el modelo operativo importa mas que el modelo de lenguaje.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">De un vistazo - Por que fracasan los proyectos de IA</p>
<ul class="text-body text-gosign-text space-y-2">
<li>La mayoria de los proyectos de IA no fracasan por la tecnologia. Fracasan porque nadie definio que decisiones puede tomar la IA y cuales deben permanecer en manos humanas.</li>
<li>La AI-Paradox: las empresas adoptan IA ampliamente, pero solo una fraccion obtiene resultados medibles - falta la arquitectura de decisiones.</li>
<li>MIT Sloan Management Review (2024) concluyo que el 70% de las iniciativas de IA corporativa no logran pasar del piloto a la produccion.</li>
<li>Ratio de inversion: por cada euro en tecnologia, las empresas necesitan cuatro a cinco euros en procesos, governance y gestion del cambio. La tecnologia sola aborda aproximadamente el 20% del problema.</li>
<li>El Decision Layer descompone los procesos de negocio en pasos de decision documentados - humano, reglas o IA - convirtiendo experimentos en sistemas productivos.</li>
</ul>
</div>

## Un piloto que funcionó - y luego desapareció

Un departamento de RRHH inicia un proyecto de IA. Un agent procesa bajas por enfermedad: lee el documento, extrae datos, verifica contra el convenio colectivo, crea una propuesta para SAP SuccessFactors. En el piloto todo funciona. La precisión es del 94%. El tiempo de procesamiento baja de 45 minutos a 5 minutos.

Seis meses después: el agent sigue en el piloto. No porque la tecnología haya fallado. Sino porque nadie respondió las preguntas que vienen después del piloto:

¿Quién aprueba el asiento que propone el agent? ¿Qué pasa si el agent se equivoca - quién es responsable? ¿La lógica aplica también para la sede de Múnich, donde rige otro convenio colectivo? ¿Puede el agent iniciar automáticamente un procedimiento de reintegración en caso de baja prolongada, o eso debe decidirlo un humano? ¿Qué dice el comité de empresa?

No son preguntas técnicas. Son preguntas de decisión. Y mientras no se respondan, cada agent es un experimento.

## La AI-Paradox: Alta inversión, bajo retorno

Lo que ocurre aquí no es un caso aislado. Es un patrón que se repite en empresas de todos los tamaños.

La mayoría de empresas ya usan IA - al menos en forma de chatbots, licencias de Copilot o primeros pilotos. Pero pocas reportan que la IA aporta un beneficio medible a los resultados.

Esta es la AI-Paradox: la tecnología funciona. Pero los beneficios no llegan.

Las explicaciones habituales se quedan cortas. "Los datos no son suficientemente buenos" - a veces es cierto, pero la calidad de datos es un problema resoluble. "El modelo no es suficientemente bueno" - improbable cuando se ve lo que pueden los modelos de lenguaje actuales. "Los empleados temen a la IA" - la gestión del cambio importa, pero no explica por qué también proyectos bien acompañados se estancan.

La causa real es otra: falta la arquitectura de decisiones.

## Lo que falta: No mejor tecnología - sino reglas claras

Un agent de IA que procesa bajas toma entre cinco y diez decisiones individuales por documento: ¿Está completo el documento? ¿Qué convenio colectivo aplica? ¿Hay una baja prolongada? ¿Debe iniciarse un procedimiento de reintegración? ¿En qué sistema se contabiliza?

Para cada una de estas decisiones debe estar predefinido:

**¿Decide un humano?** Por ejemplo en bajas prolongadas, porque un procedimiento de reintegración requiere discrecionalidad y el comité de empresa tiene derecho de participación.

**¿Decide un conjunto de reglas?** Por ejemplo en la verificación del convenio colectivo - el convenio es claro, la regla se aplica de forma consistente. Aquí el agente es un ejecutor - no porque no pueda más, sino porque no hay nada que interpretar.

**¿Decide la IA de forma autónoma?** El agente interpreta documentos, clasifica situaciones, evalúa contexto. Esto no es if-then-else - es capacidad de juicio dentro de límites definidos. El Confidence Routing controla: alta confianza y bajo riesgo significa decisión autónoma; baja confianza o alto riesgo significa escalación a una persona.

Sin esta asignación, el agent es una caja negra. Produce resultados, pero nadie puede rastrear en qué base. Ningún auditor lo acepta. Ningún comité de empresa lo aprueba. Ningún departamento de compliance lo libera.

## La ratio de inversión: Por qué la tecnología sola no basta

La experiencia muestra una regla que sorprende a muchos: por cada euro en tecnología, las empresas necesitan cuatro a cinco euros en procesos, governance y gestión del cambio.

Esto significa: quien tiene un presupuesto de IA de 500.000 EUR e invierte todo en licencias y modelos, aborda aproximadamente el 20% del problema. El 80% restante - diseño de procesos, reglas de decisión, acuerdos de empresa, formaciones, estructuras de governance - queda sin trabajar.

Esto explica la AI-Paradox. No es un problema de tecnología. Es un problema de inversión. O más precisamente: un problema de distribución de inversión.

## Qué significa esto para RRHH

Los procesos de RRHH son especialmente vulnerables a la AI-Paradox. Por tres razones:

**Primero: Alta complejidad regulatoria.** Convenios colectivos, acuerdos de empresa, leyes específicas por país, directrices internas. Un solo proceso como el procesamiento de bajas puede tocar cinco conjuntos de reglas diferentes.

**Segundo: Participación.** En empresas con comité de empresa, este tiene derecho de información y consulta conforme al Art. 64 del Estatuto de los Trabajadores cuando los sistemas de IA procesan datos de empleados. Sin una lógica de decisión transparente, el comité no puede ejercer estos derechos ni verificar qué hace el agent.

**Tercero: Responsabilidad.** Si un agent genera una nómina errónea, la responsabilidad no es del agent. Es de la empresa. Sin un camino de decisión documentado, no queda claro dónde se originó el error.

## Primero hacer visibles las decisiones, después automatizar

La solución no es menos IA. La solución es más estructura.

Antes de que un agent automatice un proceso, el proceso debe descomponerse en pasos de decisión individuales. Para cada paso se define: humano, reglas o IA. Esta asignación no es estática - puede cambiar cuando cambia un conjunto de reglas o cuando el agent gana experiencia.

El [Decision Layer](/es/decision-layer/) implementa exactamente esto. Se sitúa entre el AI Agent y el sistema destino y descompone cada proceso de negocio en pasos de decisión documentados. Cada paso tiene una asignación clara, un conjunto de reglas versionado y un Audit Trail completo.

El resultado: de un experimento de IA surge un sistema productivo. Uno que el comité de empresa puede verificar, que el auditor acepta y que funciona consistentemente en todas las sedes.

## Patrones de fracaso en proyectos de IA

| Patron de fracaso | Causa raiz | Solucion |
|---|---|---|
| El piloto funciona pero nunca escala | Reglas de decision no definidas - nadie responde las preguntas post-piloto | Decision Layer: definir asignacion humano/reglas/IA por paso antes de escalar |
| Alta adopcion sin impacto medible | Inversion concentrada en tecnologia, procesos y governance descuidados | Redistribuir: 20% tecnologia, 80% procesos, governance, gestion del cambio |
| El comite de empresa bloquea el despliegue | Decisiones de IA no trazables, sin Audit Trail | Transparencia a nivel de arquitectura: reglas versionadas, Audit Trail completo |
| El agente produce errores inexplicables | Decisiones de caja negra sin camino de decision documentado | Confidence Routing: umbrales de escalado, Human-in-the-Loop en casos limite |
| Resultados distintos en distintas sedes | Los conjuntos de reglas varian pero la logica del agente es uniforme | Motor de reglas consciente de la ubicacion con reglas versionadas y testeables |

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">eBook gratuito: IA en RRHH</p>
<p class="text-body text-gosign-text mb-4">Checklist EU AI Act, framework de decisiones, perspectiva del comité de empresa y evaluación de preparación - el manual de gobernanza para responsables de RRHH.</p>
<a href="/es/ebook/ia-rrhh-manual-gobernanza/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Descargar gratis</a>
</div>

## Conclusión

La AI-Paradox no es un destino inevitable. Es la consecuencia de una mala asignación: demasiada inversión en tecnología, poca en las reglas que determinan lo que la tecnología puede hacer.

Las empresas que entienden esto no invierten en el próximo modelo de lenguaje - invierten en su arquitectura de decisiones. Y exactamente ahí está la diferencia entre un piloto de IA que acaba en un cajón y un sistema que funciona en producción.

> [Decision Layer - resumen y ejemplos](/es/decision-layer/)

> [Tres tipos de decisiones: Cuándo el humano, cuándo la IA](/es/revista/tres-tipos-de-decisiones/)

--- Por qué ya no entrenamos agentes AI ---
> 92% de precisión sin entrenamiento. El EU AI Act exige decisiones individuales explicables para alto riesgo (vigente desde agosto 2026, aplazamiento a diciembre 2027 acordado provisionalmente). Los modelos entrenados no pueden cumplirlo.

## El entrenamiento es el nuevo fax

En 2019 teníamos que entrenar modelos AI. Eran demasiado limitados para cualquier otra cosa. GPT-2 no podía escribir un párrafo coherente. BERT necesitaba miles de ejemplos etiquetados para cada tarea y un clúster GPU durante días.

Eso fue hace seis años. Seis años en los que las capacidades de los modelos de lenguaje mejoraron en órdenes de magnitud. Pero la industria sigue actuando como si "entrenar" fuera el primer paso natural.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">De un vistazo - Por qué el entrenamiento es la arquitectura equivocada</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Un LLM alcanza el 92% de decisiones correctas en la revisión de facturas - sin un solo ejemplo de entrenamiento. Juristas experimentados alcanzan el 72%.<sup>[1]</sup></li>
<li>El EU AI Act (Art. 13, 14, 86) exige decisiones individuales explicables para sistemas de alto riesgo: obligaciones vigentes desde agosto 2026 según la legislación actual, con aplazamiento a diciembre 2027 acordado provisionalmente (Digital Omnibus, mayo 2026). Los modelos entrenados no pueden cumplirlo.<sup>[10]</sup></li>
<li>La alternativa: conjunto de reglas (versionado), contexto (por decisión), Decision Layer (persona/regla/AI por Micro-Decision).</li>
<li>Los agentes configurados son modelo-agnósticos: cambio de modelo Foundation sin cambio en el conjunto de reglas. Sin lock-in, sin reentrenamiento.</li>
<li>Más del 40% de los proyectos de Agentic AI fracasarán hasta 2027 - principalmente por falta de governance, no por falta de rendimiento del modelo.<sup>[9]</sup></li>
</ul>
</div>

Si alguien en 2026 dice "Entrenamos nuestros agentes AI", es como decir en 2010 "Enviamos nuestros pedidos por fax". Funciona. Pero demuestra que no se ha entendido la arquitectura.

<!-- Timeline: De entrenamiento a configuración -->
<div class="not-prose my-12">
<div class="bg-gosign-dark rounded-card p-6 sm:p-8">
<p class="text-h3 font-bold text-white mb-6">De entrenamiento a configuración</p>
<div class="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-4 gap-4">

<div class="border border-white/10 rounded-lg p-4 bg-white/5">
<p class="text-gosign-text-on-dark text-xs uppercase tracking-wider mb-1">2018 - 2020</p>
<p class="text-white font-bold text-lg mb-2">El entrenamiento es obligatorio</p>
<p class="text-gosign-text-on-dark text-sm mb-3">BERT, GPT-2. 110M - 1,5B parámetros.</p>
<div class="space-y-1 text-xs text-gosign-text-on-dark">
<p>Duración: semanas</p>
<p>Coste: $10 000 - $100 000</p>
<p>Requisito: clúster GPU</p>
</div>
</div>

<div class="border border-white/10 rounded-lg p-4 bg-white/5">
<p class="text-gosign-text-on-dark text-xs uppercase tracking-wider mb-1">2021 - 2023</p>
<p class="text-white font-bold text-lg mb-2">El entrenamiento se vuelve opcional</p>
<p class="text-gosign-text-on-dark text-sm mb-3">GPT-3/3.5. 175B parámetros.</p>
<div class="space-y-1 text-xs text-gosign-text-on-dark">
<p>Duración: días</p>
<p>Coste: $1000 - $10 000</p>
<p>Requisito: GPU necesaria</p>
</div>
</div>

<div class="border border-white/10 rounded-lg p-4 bg-white/5">
<p class="text-gosign-text-on-dark text-xs uppercase tracking-wider mb-1">2024</p>
<p class="text-white font-bold text-lg mb-2">¿Entrenamiento o prompting?</p>
<p class="text-gosign-text-on-dark text-sm mb-3">GPT-4o, Claude 3.5. Multimodal.</p>
<div class="space-y-1 text-xs text-gosign-text-on-dark">
<p>Duración: horas</p>
<p>Coste: $10 - $100</p>
<p>Requisito: API-Call</p>
</div>
</div>

<div class="border border-gosign-accent rounded-lg p-4 bg-gosign-accent/10">
<p class="text-gosign-accent-on-dark text-xs uppercase tracking-wider mb-1">2025 - 2026</p>
<p class="text-white font-bold text-lg mb-2">La configuración es suficiente</p>
<p class="text-gosign-text-on-dark text-sm mb-3">GPT-5.5, Claude Opus 4.7. Reasoning.</p>
<div class="space-y-1 text-xs text-gosign-text-on-dark">
<p>Duración: minutos</p>
<p>Coste: $10 - $100</p>
<p>Requisito: API-Call</p>
</div>
</div>

</div>
</div>
</div>

Kumar Gauraw lo resume con precisión: "La mayoría recurre al Fine-Tuning demasiado pronto."<sup>[5]</sup> No porque el Fine-Tuning sea malo. Sino porque en 2026 ya no es necesario para la mayoría de las tareas enterprise.

## Lo que un modelo entrenado no puede hacer: explicar una decisión individual

Un candidato es rechazado por su agente de recruiting. Pregunta: ¿por qué?

Dos respuestas. Dos arquitecturas.

**Modelo entrenado:** "Nuestro modelo ha aprendido, basándose en 50 000 decisiones históricas de contratación, que su perfil tiene una probabilidad de éxito del 34%."

**Agente configurado:** "Su cualificación en ingeniería mecánica no cumple el requisito 3 (electrotecnia o equivalente). Regla: perfil del puesto v2026-03. Recurrible: sí. Proceso: el departamento técnico evalúa si la ingeniería mecánica se considera 'equivalente'."

La primera respuesta no resiste las obligaciones de alto riesgo del EU AI Act.

EU AI Act, Art. 13 (transparencia), Art. 14 (supervisión humana), Art. 86 (derecho a explicación).<sup>[10]</sup> Para sistemas de alto riesgo - y el recruiting es alto riesgo, Anexo III(4) - cada decisión individual debe ser comprensible, explicable y recurrible. La clasificación de alto riesgo se mantiene; conforme a la legislación vigente, estas obligaciones se aplican desde agosto de 2026, con un aplazamiento a diciembre de 2027 acordado provisionalmente por el Digital Omnibus (mayo 2026, adopción formal aún pendiente). En cualquier caso, la arquitectura que cumple el requisito hay que decidirla ahora. En España, la AESIA supervisa la aplicación de estas obligaciones.

No el modelo. La decisión individual. Para este candidato. Con esta fundamentación.

Un modelo entrenado no puede hacerlo. No tiene expediente de decisión. Tiene pesos. Y los pesos no explican nada al comité de empresa.

### La prueba de compliance: entrenado vs. configurado

<!-- Comparación dos columnas: Entrenado vs. Configurado -->
<div class="not-prose my-10">
<div class="bg-gosign-dark rounded-card overflow-hidden">
<div class="grid grid-cols-1 md:grid-cols-2">

<!-- Columna izquierda: Entrenado -->
<div class="p-6 sm:p-8 border-b md:border-b-0 md:border-r border-white/10">
<p class="text-gosign-text-on-dark text-xs uppercase tracking-wider mb-1">Arquitectura A</p>
<p class="text-white font-bold text-xl mb-6">Modelo entrenado</p>

<div class="space-y-5">
<div>
<p class="text-gosign-text-on-dark text-sm mb-1">"¿Por qué esta decisión?"</p>
<p class="text-white text-sm">"El modelo ha aprendido" - Black Box</p>
<p class="text-red-400 text-xs mt-1">No explicable</p>
</div>

<div>
<p class="text-gosign-text-on-dark text-sm mb-1">"¿Cambia la ley?"</p>
<p class="text-white text-sm">Reentrenamiento. 2 - 4 semanas, $5000 - $20 000</p>
<p class="text-red-400 text-xs mt-1">Caro y lento</p>
</div>

<div>
<p class="text-gosign-text-on-dark text-sm mb-1">"¿Puede el afectado recurrir?"</p>
<p class="text-white text-sm">¿Contra qué? ¿Contra pesos?</p>
<p class="text-red-400 text-xs mt-1">No recurrible</p>
</div>

<div>
<p class="text-gosign-text-on-dark text-sm mb-1">"¿Nuevo modelo LLM disponible?"</p>
<p class="text-white text-sm">Nuevo entrenamiento necesario. Semanas, lock-in.</p>
<p class="text-red-400 text-xs mt-1">Dependencia del proveedor</p>
</div>

<div>
<p class="text-gosign-text-on-dark text-sm mb-1">"¿Conforme al EU AI Act?"</p>
<p class="text-white text-sm">Art. 13: falta transparencia. Art. 14: intervención = reemplazar modelo. Art. 86: explicación no posible.</p>
<p class="text-red-400 text-xs mt-1">Problemático</p>
</div>

<div class="pt-4 border-t border-white/10">
<p class="text-red-400 font-bold text-sm">Lock-in: sí | Auditoría: difícil | EU AI Act: problemático</p>
</div>
</div>
</div>

<!-- Columna derecha: Configurado -->
<div class="p-6 sm:p-8">
<p class="text-gosign-accent-on-dark text-xs uppercase tracking-wider mb-1">Arquitectura B</p>
<p class="text-white font-bold text-xl mb-6">Agente configurado</p>

<div class="space-y-5">
<div>
<p class="text-gosign-text-on-dark text-sm mb-1">"¿Por qué esta decisión?"</p>
<p class="text-white text-sm">"§9 EStG v2026-01, ausencia 14h15min" (ley fiscal alemana - reglas análogas en cada jurisdicción)</p>
<p class="text-green-400 text-xs mt-1">Regla, versión, contexto documentados</p>
</div>

<div>
<p class="text-gosign-text-on-dark text-sm mb-1">"¿Cambia la ley?"</p>
<p class="text-white text-sm">Actualizar regla. Efecto inmediato, $0.</p>
<p class="text-green-400 text-xs mt-1">Versionado y auditable</p>
</div>

<div>
<p class="text-gosign-text-on-dark text-sm mb-1">"¿Puede el afectado recurrir?"</p>
<p class="text-white text-sm">"El desayuno no estaba incluido." El responsable revisa.</p>
<p class="text-green-400 text-xs mt-1">Recurrible con expediente de decisión</p>
</div>

<div>
<p class="text-gosign-text-on-dark text-sm mb-1">"¿Nuevo modelo LLM disponible?"</p>
<p class="text-white text-sm">El conjunto de reglas permanece. 0 esfuerzo, sin lock-in.</p>
<p class="text-green-400 text-xs mt-1">Modelo-agnóstico</p>
</div>

<div>
<p class="text-gosign-text-on-dark text-sm mb-1">"¿Conforme al EU AI Act?"</p>
<p class="text-white text-sm">Expediente de decisión por Micro-Decision. Anular regla, no reemplazar modelo.</p>
<p class="text-green-400 text-xs mt-1">Conforme by Design</p>
</div>

<div class="pt-4 border-t border-white/10">
<p class="text-green-400 font-bold text-sm">Lock-in: no | Auditoría: by Design | EU AI Act: conforme</p>
</div>
</div>
</div>

</div>
</div>
</div>

El problema de compliance es solo la superficie. Debajo hay un problema de arquitectura.

## 92% vs. 72%

Investigadores probaron en 2025 cómo de bien un LLM puede revisar facturas de abogados contra Billing Guidelines.<sup>[1]</sup> Sin Fine-Tuning. Sin entrenamiento. Solo el conjunto de reglas como contexto.

El resultado:

<!-- 92% vs. 72% comparación de barras -->
<div class="not-prose my-10">
<div class="bg-gosign-dark rounded-card p-6 sm:p-8 text-white">
<p class="text-h3 font-bold mb-6">Factura de abogado: ¿conforme a las reglas o no?</p>
<p class="text-gosign-text-on-dark text-sm mb-8">Better Bill GPT, Whitehouse et al. (abril 2025). Peer-reviewed. El LLM recibió el conjunto de reglas como contexto, sin Fine-Tuning.<sup>[1]</sup></p>

<!-- Precisión global -->
<div class="mb-8">
<p class="text-gosign-text-on-dark text-xs uppercase tracking-wider mb-3">Precisión global</p>

<div class="mb-4">
<div class="flex justify-between items-center mb-1">
<p class="text-sm font-medium">LLM (sin entrenamiento)</p>
<p class="text-gosign-accent-on-dark font-bold text-lg">92%</p>
</div>
<div class="w-full bg-white/10 rounded-full h-4">
<div class="bg-gosign-accent rounded-full h-4" style="width: 92%"></div>
</div>
</div>

<div class="mb-4">
<div class="flex justify-between items-center mb-1">
<p class="text-sm font-medium">Juristas experimentados</p>
<p class="text-gosign-text-on-dark font-bold text-lg">72%</p>
</div>
<div class="w-full bg-white/10 rounded-full h-4">
<div class="bg-white/30 rounded-full h-4" style="width: 72%"></div>
</div>
</div>
</div>

<!-- F-Score partidas individuales -->
<div class="mb-8">
<p class="text-gosign-text-on-dark text-xs uppercase tracking-wider mb-3">Clasificación de partidas individuales (F-Score)</p>

<div class="mb-4">
<div class="flex justify-between items-center mb-1">
<p class="text-sm font-medium">LLM (sin entrenamiento)</p>
<p class="text-gosign-accent-on-dark font-bold text-lg">81%</p>
</div>
<div class="w-full bg-white/10 rounded-full h-4">
<div class="bg-gosign-accent rounded-full h-4" style="width: 81%"></div>
</div>
</div>

<div class="mb-4">
<div class="flex justify-between items-center mb-1">
<p class="text-sm font-medium">Mejor grupo humano</p>
<p class="text-gosign-text-on-dark font-bold text-lg">43%</p>
</div>
<div class="w-full bg-white/10 rounded-full h-4">
<div class="bg-white/30 rounded-full h-4" style="width: 43%"></div>
</div>
</div>
</div>

<!-- Tiempo y costes -->
<div class="grid grid-cols-1 sm:grid-cols-2 gap-6">

<div>
<p class="text-gosign-text-on-dark text-xs uppercase tracking-wider mb-3">Tiempo por factura</p>
<div class="mb-3">
<div class="flex justify-between items-center mb-1">
<p class="text-sm font-medium">LLM</p>
<p class="text-gosign-accent-on-dark font-bold">3,6 seg.</p>
</div>
<div class="w-full bg-white/10 rounded-full h-3">
<div class="bg-gosign-accent rounded-full h-3" style="width: 1.4%"></div>
</div>
</div>
<div>
<div class="flex justify-between items-center mb-1">
<p class="text-sm font-medium">Juristas</p>
<p class="text-gosign-text-on-dark font-bold">~250 seg.</p>
</div>
<div class="w-full bg-white/10 rounded-full h-3">
<div class="bg-white/30 rounded-full h-3" style="width: 100%"></div>
</div>
</div>
</div>

<div>
<p class="text-gosign-text-on-dark text-xs uppercase tracking-wider mb-3">Coste por factura</p>
<div class="mb-3">
<div class="flex justify-between items-center mb-1">
<p class="text-sm font-medium">LLM</p>
<p class="text-gosign-accent-on-dark font-bold">&lt; $0,01</p>
</div>
<div class="w-full bg-white/10 rounded-full h-3">
<div class="bg-gosign-accent rounded-full h-3" style="width: 0.2%"></div>
</div>
</div>
<div>
<div class="flex justify-between items-center mb-1">
<p class="text-sm font-medium">Juristas</p>
<p class="text-gosign-text-on-dark font-bold">$4,27</p>
</div>
<div class="w-full bg-white/10 rounded-full h-3">
<div class="bg-white/30 rounded-full h-3" style="width: 100%"></div>
</div>
</div>
</div>

</div>

<p class="text-gosign-text-on-dark text-xs mt-6 border-t border-white/10 pt-4">Reducción de costes: 99,97%.<sup>[4]</sup> Mecanismo transferible a cualquier tarea de compliance basada en reglas.</p>
</div>
</div>

El LLM no fue entrenado con facturas. Recibió las Billing Guidelines como contexto. Y decidió al instante.

### Por qué el LLM fue mejor

No porque sea más inteligente. Sino porque a las 15:00 aplica la misma regla igual que a las 9:00. La inconsistencia es el problema del ser humano, no la incompetencia.<sup>[1]</sup>

Los juristas experimentados toman el 72% de decisiones correctas - pero cada jurista comete errores diferentes. Los fallos no son sistemáticos, sino aleatorios. Fatiga, presión de tiempo, interpretación personal. Un LLM no conoce la fatiga.

### El mecanismo transferible

Da igual si el conjunto de reglas se llama "Billing Guideline", "§14 UStG" o "Dietas de viaje 2026": verificar documento contra regla, identificar desviación, documentar decisión. El mecanismo es idéntico.

<!-- Tabla resumen: aplicación del conjunto de reglas -->
<div class="not-prose my-8">
<div class="overflow-x-auto">
<table class="w-full border-collapse text-sm">
<thead>
<tr class="bg-gosign-dark text-white">
<th class="p-3 text-left font-bold">Dimensión</th>
<th class="p-3 text-left font-bold">Modelo entrenado</th>
<th class="p-3 text-left font-bold">Agente configurado</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border bg-gosign-white">
<td class="p-3 font-medium text-gosign-dark">Cambio de reglas</td>
<td class="p-3 text-gosign-text">Reentrenamiento (semanas, $5k - $20k)</td>
<td class="p-3 text-gosign-text">Actualización del conjunto de reglas (minutos, $0)</td>
</tr>
<tr class="border-b border-gosign-border bg-gosign-light">
<td class="p-3 font-medium text-gosign-dark">Explicabilidad</td>
<td class="p-3 text-gosign-text">"El modelo ha aprendido" (Black Box)</td>
<td class="p-3 text-gosign-text">Regla + versión + contexto (expediente de decisión)</td>
</tr>
<tr class="border-b border-gosign-border bg-gosign-white">
<td class="p-3 font-medium text-gosign-dark">Recurribilidad</td>
<td class="p-3 text-gosign-text">No posible (sin expediente de decisión)</td>
<td class="p-3 text-gosign-text">Sí (el afectado ve la regla y puede objetar)</td>
</tr>
<tr class="border-b border-gosign-border bg-gosign-light">
<td class="p-3 font-medium text-gosign-dark">Cambio de modelo</td>
<td class="p-3 text-gosign-text">Nuevo entrenamiento necesario (lock-in)</td>
<td class="p-3 text-gosign-text">0 esfuerzo (modelo-agnóstico)</td>
</tr>
<tr class="border-b border-gosign-border bg-gosign-white">
<td class="p-3 font-medium text-gosign-dark">Audit Trail</td>
<td class="p-3 text-gosign-text">Entrada + salida (sin fundamentación)</td>
<td class="p-3 text-gosign-text">Entrada + regla + versión + confianza + resultado</td>
</tr>
<tr class="border-b border-gosign-border bg-gosign-light">
<td class="p-3 font-medium text-gosign-dark">EU AI Act (ago. 2026)</td>
<td class="p-3 text-gosign-text">Art. 13, 14, 86: problemático</td>
<td class="p-3 text-gosign-text">Art. 13, 14, 86: conforme by Design</td>
</tr>
<tr class="bg-gosign-white">
<td class="p-3 font-medium text-gosign-dark">Break-Even Fine-Tuning</td>
<td class="p-3 text-gosign-text">A partir de ~35 000 consultas/mes<sup>[6]</sup></td>
<td class="p-3 text-gosign-text">Rentable de inmediato</td>
</tr>
</tbody>
</table>
</div>
</div>

Un estudio de Chauhan et al. (2025) cifra el punto de Break-Even del Fine-Tuning frente al prompting en aproximadamente 35 000 consultas al mes.<sup>[6]</sup> La mayoría de los procesos de HR y Finance en empresas están muy por debajo.

## Tres cosas en vez de entrenamiento

Si no entrenamiento, ¿entonces qué? Tres componentes sustituyen lo que el Fine-Tuning promete pero estructuralmente no puede cumplir.

### 1. Conjunto de reglas

Todo lo que un agente necesita saber está en una ley, un reglamento, un convenio colectivo o un acuerdo marco. Estas reglas cambian. El derecho fiscal cambia anualmente. Las dietas oficiales cambian anualmente. Los reglamentos de la UE cambian.

Un modelo entrenado debe reentrenarse con cada cambio. Un conjunto de reglas se actualiza. Efecto inmediato, versionado, auditable. Sin clúster GPU, sin ciclo de evaluación, sin riesgos de regresión.

RAG (Retrieval Augmented Generation) reduce los errores fácticos en hasta un 50%.<sup>[11]</sup> No porque el modelo se vuelva más inteligente. Sino porque ve la regla actual en lugar de recuperar una ponderación obsoleta.

### 2. Contexto

El agente no necesita 10 000 liquidaciones de gastos de viaje históricas. Necesita esta liquidación: fecha de viaje, salida, regreso, hotel, desayuno incluido o no. Ese es el contexto de esta decisión.

Se suministra mediante entradas estructuradas o RAG, no mediante entrenamiento. Cuando el contexto cambia - otro viaje, otro empleado - cambia la decisión. No el modelo.

Un ejemplo concreto: el [Travel Decision Layer](/es/servicios/travel-decision-layer/) verifica las dietas de viaje contra §9 EStG (ley fiscal alemana de gastos de viaje). El contexto es el viaje individual. El conjunto de reglas es el derecho fiscal vigente. El modelo Foundation es intercambiable.

### 3. Marco de decisión

¿Quién decide qué? No todas las decisiones en un proceso son iguales.

La dieta de viaje es conjunto de reglas: §9 EStG, determinista, 100% confianza. La pregunta de si un gasto de representación es "razonable" es criterio humano: persona. La clasificación de un tique de caja ilegible es AI: extracción LLM, probabilística.

Esta descomposición en Micro-Decisions con asignación persona/regla/AI es el verdadero trabajo de arquitectura. No el entrenamiento. El [Decision Layer](/es/decision-layer/) formaliza exactamente esta descomposición. Detalles de la arquitectura: [Decision Layer explicado](/es/revista/decision-layer-explicado/).

<!-- Demo Micro-Decision -->
<div class="not-prose my-10">
<div class="bg-gosign-light border border-gosign-border rounded-card overflow-hidden">
<div class="p-6 sm:p-8">
<p class="text-h3 font-bold text-gosign-dark mb-2">Micro-Decision en la práctica</p>
<p class="text-gosign-text text-sm mb-6">Liquidación de gastos de viaje: jornada de 8 horas, viaje nacional, hotel con desayuno</p>

<div class="space-y-3">

<div class="bg-gosign-white border border-gosign-border rounded-lg p-4">
<div class="flex flex-wrap items-center gap-3">
<span class="text-xs font-mono bg-gosign-dark text-white px-2 py-0.5 rounded">#1</span>
<span class="font-medium text-gosign-dark text-sm">Fecha de viaje y duración de la ausencia</span>
<span class="text-xs px-2 py-0.5 rounded bg-blue-100 text-blue-800 font-medium">Contexto</span>
<span class="text-xs text-gosign-text-light ml-auto">Input: justificantes</span>
</div>
</div>

<div class="bg-gosign-white border border-gosign-border rounded-lg p-4">
<div class="flex flex-wrap items-center gap-3">
<span class="text-xs font-mono bg-gosign-dark text-white px-2 py-0.5 rounded">#2</span>
<span class="font-medium text-gosign-dark text-sm">Calcular dieta de viaje</span>
<span class="text-xs px-2 py-0.5 rounded bg-green-100 text-green-800 font-medium">Conjunto de reglas</span>
<span class="text-xs text-gosign-text-light ml-auto">§9 EStG v2026-01</span>
</div>
</div>

<div class="bg-gosign-white border border-gosign-border rounded-lg p-4">
<div class="flex flex-wrap items-center gap-3">
<span class="text-xs font-mono bg-gosign-dark text-white px-2 py-0.5 rounded">#3</span>
<span class="font-medium text-gosign-dark text-sm">Aplicar deducción por desayuno</span>
<span class="text-xs px-2 py-0.5 rounded bg-green-100 text-green-800 font-medium">Conjunto de reglas</span>
<span class="text-xs text-gosign-text-light ml-auto">§9 Abs. 4a S. 8 EStG</span>
</div>
</div>

<div class="bg-gosign-white border border-gosign-border rounded-lg p-4">
<div class="flex flex-wrap items-center gap-3">
<span class="text-xs font-mono bg-gosign-dark text-white px-2 py-0.5 rounded">#4</span>
<span class="font-medium text-gosign-dark text-sm">Clasificar tique de caja</span>
<span class="text-xs px-2 py-0.5 rounded bg-gosign-accent/10 text-gosign-accent font-medium">AI</span>
<span class="text-xs text-gosign-text-light ml-auto">Extracción LLM, Confidence: 87%</span>
</div>
</div>

<div class="bg-gosign-white border border-gosign-border rounded-lg p-4">
<div class="flex flex-wrap items-center gap-3">
<span class="text-xs font-mono bg-gosign-dark text-white px-2 py-0.5 rounded">#5</span>
<span class="font-medium text-gosign-dark text-sm">¿Es el gasto de representación "razonable"?</span>
<span class="text-xs px-2 py-0.5 rounded bg-yellow-100 text-yellow-800 font-medium">Persona</span>
<span class="text-xs text-gosign-text-light ml-auto">Criterio, el responsable revisa</span>
</div>
</div>

<div class="bg-gosign-white border border-gosign-border rounded-lg p-4">
<div class="flex flex-wrap items-center gap-3">
<span class="text-xs font-mono bg-gosign-dark text-white px-2 py-0.5 rounded">#6</span>
<span class="font-medium text-gosign-dark text-sm">Crear asiento contable conforme a normativa</span>
<span class="text-xs px-2 py-0.5 rounded bg-green-100 text-green-800 font-medium">Conjunto de reglas</span>
<span class="text-xs text-gosign-text-light ml-auto">Normativa contable, versionada</span>
</div>
</div>

</div>

<div class="mt-6 p-4 bg-gosign-dark rounded-lg">
<p class="text-gosign-text-on-dark text-sm">Cada uno de estos pasos tiene un tipo fijo: <span class="text-green-400">conjunto de reglas</span> (determinista), <span class="text-gosign-accent-on-dark">AI</span> (probabilístico, con umbral de confianza) o <span class="text-yellow-400">persona</span> (criterio). Cuando §9 EStG cambia, se actualiza la regla. Sin reentrenamiento. Sin nuevo modelo.</p>
</div>
</div>
</div>
</div>

## Las tres capas: arquitectura en vez de entrenamiento

La arquitectura detrás de un agente configurado consta de tres capas. Cada capa es independientemente intercambiable.

<!-- Diagrama de tres capas -->
<div class="not-prose my-10">
<div class="max-w-2xl mx-auto">

<div class="bg-gosign-dark border-2 border-gosign-accent rounded-t-card p-6">
<div class="flex items-center gap-3 mb-3">
<span class="text-gosign-accent-on-dark text-xs uppercase tracking-wider font-bold">Capa 3</span>
<span class="text-white font-bold text-lg">Decision Layer</span>
</div>
<div class="flex flex-wrap gap-2">
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Micro-Decisions</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Persona / Reglas / AI</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Expediente de decisión</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Audit Trail</span>
</div>
</div>

<div class="bg-gosign-dark border-x-2 border-gosign-accent p-6 border-t border-white/10">
<div class="flex items-center gap-3 mb-3">
<span class="text-gosign-accent-on-dark text-xs uppercase tracking-wider font-bold">Capa 2</span>
<span class="text-white font-bold text-lg">Conjunto de reglas (versionado, intercambiable)</span>
</div>
<div class="flex flex-wrap gap-2">
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Legislación fiscal</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Reglamentos</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Normativa contable</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Convenio colectivo</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Acuerdo marco</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">EU AI Act</span>
</div>
</div>

<div class="bg-gosign-darker border-2 border-white/20 rounded-b-card p-6">
<div class="flex items-center gap-3 mb-3">
<span class="text-gosign-text-on-dark text-xs uppercase tracking-wider font-bold">Capa 1</span>
<span class="text-white font-bold text-lg">Foundation Model (intercambiable)</span>
</div>
<div class="flex flex-wrap gap-2">
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Claude</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">GPT</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Llama</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Mistral</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Gemini</span>
</div>
</div>

<div class="mt-4 flex items-start gap-3 p-4 bg-gosign-light border border-gosign-border rounded-card">
<span class="text-gosign-accent text-lg mt-0.5">&#x2191;</span>
<p class="text-gosign-text text-sm">Todo por encima de la capa 1 permanece cuando el modelo cambia. Conjunto de reglas, Decision Layer, expedientes de decisión, Audit Trail - todo modelo-agnóstico. Sin reentrenamiento. Sin lock-in.</p>
</div>

</div>
</div>

¿Por qué tres capas? Porque cada una tiene una responsabilidad diferente.

El Foundation Model proporciona comprensión lingüística y reasoning. Entiende el contexto, extrae información de documentos, clasifica entradas. No necesita saber qué dice §9 EStG. Necesita entender qué es un texto legal.

El conjunto de reglas contiene la lógica de negocio. Leyes, reglamentos, convenios colectivos, acuerdos marco. Cada regla tiene una versión. Cada versión tiene una fecha de vigencia. Cuando la ley cambia, se actualiza la regla. No el modelo.

El [Decision Layer](/es/decision-layer/) controla quién puede decidir qué. Descompone los procesos en pasos de decisión. Define para cada uno: persona, conjunto de reglas o AI. Documenta cada decisión con regla, versión, contexto y resultado.

## Lo que el entrenamiento realmente cuesta

No en dólares. En dependencias.

### Lock-in

Un modelo fine-tuned le vincula a ese proveedor. El dataset de entrenamiento, los pesos, el pipeline de evaluación: todo propietario. Cambio de modelo = nuevo entrenamiento = nuevos costes = nueva pérdida de tiempo.

Un agente configurado cambia el Foundation Model sin modificar una sola regla. Claude hoy, GPT mañana, un modelo open-source la semana que viene. El conjunto de reglas permanece. El Decision Layer permanece. Los expedientes de decisión permanecen.

### Mantenimiento

Cada cambio legislativo requiere reentrenamiento. En Finance, la legislación fiscal, las directrices ministeriales y las cuotas de seguridad social cambian anualmente. En HR cambian los convenios colectivos, los acuerdos marco y la regulación de la UE.

Un agente entrenado necesita un mantenimiento continuo que parece un proyecto de software. Un agente configurado necesita un editor de conjunto de reglas.

MIT y Stanford (Choi & Xie, 2025) demuestran: la AI reduce el cierre mensual en 7,5 días.<sup>[7]</sup> Pero el 62% de los contables se preocupa por los errores de la AI.<sup>[8]</sup> La preocupación es justificada - con modelos entrenados. Con agentes configurados con expediente de decisión y posibilidad de recurso, cada error es identificable y corregible.

### Explicabilidad

Un modelo entrenado puede decirle qué ha decidido. No puede decirle por qué.

"El modelo ha aprendido" no es una fundamentación que acepte un auditor. Ningún comité de empresa la acepta. Ningún candidato rechazado la acepta.

"Regla §9 EStG v2026-01, aplicada a ausencia 14h15min" es una fundamentación.

Si no puede explicar la decisión, no puede permitir que se recurra. Y si no puede permitir que se recurra, no cumple las obligaciones de alto riesgo del EU AI Act, vigentes desde agosto de 2026 según la legislación actual (con un aplazamiento a diciembre de 2027 acordado provisionalmente, adopción formal pendiente).<sup>[10]</sup>

### ¿Tiene el Fine-Tuning su lugar?

Sí. A partir de aproximadamente 35 000 consultas al mes con un conjunto de reglas estable, el Fine-Tuning resulta rentable.<sup>[6]</sup> Adaptación lingüística, jerga de dominio, optimización de latencia: para eso hay buenas razones.

Pero donde la industria lo vende hoy - Enterprise HR y Finance con leyes que cambian anualmente - es la decisión arquitectónica equivocada. Gartner pronostica que más del 40% de los proyectos de Agentic AI fracasarán hasta 2027.<sup>[9]</sup> No por el rendimiento del modelo. Por la governance.

## La pregunta que debería hacer su consejo

No: "¿Con qué datos se entrenó vuestro agente?"

Sino:

**1. ¿Qué conjunto de reglas fundamenta la decisión? ¿Qué versión estaba vigente en el momento de la decisión?**

Si la respuesta es "Eso está en el modelo", no hay versión. No hay historial de cambios. No hay Audit Trail.

**2. ¿Qué pasa cuando cambia la regla? ¿Reentrenamiento o actualización?**

Si la respuesta es "Reentrenamos", está pagando por un mantenimiento innecesario.

**3. ¿Puede el afectado ver la decisión individual y recurrirla?**

Si no hay respuesta, tiene un asunto de compliance pendiente con las obligaciones de alto riesgo del EU AI Act (vigentes desde agosto de 2026 según la legislación actual; aplazamiento a diciembre de 2027 acordado de forma provisional). Art. 86 EU AI Act: derecho a explicación. No es opcional.<sup>[10]</sup>

## El enfoque de Gosign

El Decision Layer de Gosign es una implementación de esta arquitectura. Descompone los procesos en pasos de decisión. Define para cada uno: persona, conjunto de reglas o AI. Los conjuntos de reglas están versionados. Las decisiones son auditables. Los resultados son recurribles.

[48 agentes HR](/es/catalogo-agentes-hr/) y [49 agentes Finance](/es/catalogo-agentes-finance/), cada uno con tabla Micro-Decision. Sin Fine-Tuning. Sin lock-in. Sin reentrenamiento cuando cambian las leyes.

---

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Referencias</p>
<ol class="text-sm text-gosign-text space-y-2 list-decimal list-inside">
<li id="fn1">Better Bill GPT, Whitehouse et al. (abril 2025). Legal Invoice Review: el LLM alcanza un 92% de precisión en la revisión de honorarios de abogados contra Billing Guidelines. Peer-reviewed.</li>
<li id="fn2">Better Bill GPT, Whitehouse et al. (abril 2025). F-Score en clasificación de partidas individuales: LLM 81% vs. mejor grupo humano 43%.</li>
<li id="fn3">Better Bill GPT, Whitehouse et al. (abril 2025). Tiempo de procesamiento por factura: LLM 3,6 segundos vs. juristas experimentados 194 a 316 segundos.</li>
<li id="fn4">Better Bill GPT, Whitehouse et al. (abril 2025). Reducción de costes en Legal Invoice Review: 99,97% ($4,27 vs. &lt;$0,01 por factura).</li>
<li id="fn5">Kumar Gauraw (marzo 2026). "La mayoría recurre al Fine-Tuning demasiado pronto."</li>
<li id="fn6">Chauhan et al., Journal of Information Systems Engineering (2025). Break-Even Fine-Tuning vs. Prompting: ~35 000 consultas al mes.</li>
<li id="fn7">MIT/Stanford, Choi & Xie (agosto 2025). La AI reduce el cierre mensual en un promedio de 7,5 días.</li>
<li id="fn8">MIT/Stanford, Choi & Xie (agosto 2025). El 62% de los contables expresan preocupación sobre errores de la AI en procesos financieros.</li>
<li id="fn9">Gartner (junio 2025). Pronóstico: más del 40% de los proyectos de Agentic AI fracasarán hasta 2027.</li>
<li id="fn10">EU AI Act (VO 2024/1689), Crowell & Moring (febrero 2026). Obligaciones para sistemas de alto riesgo vigentes desde agosto 2026 según la legislación actual, con aplazamiento al 2 de diciembre de 2027 acordado provisionalmente por el Digital Omnibus (acuerdo político del 7 de mayo de 2026, adopción formal pendiente): Art. 13 (transparencia), Art. 14 (supervisión humana), Art. 86 (derecho a explicación). Anexo III(4): recruiting como sistema de alto riesgo.</li>
<li id="fn11">IBM (2024). RAG reduce los errores fácticos en las salidas de LLM en hasta un 50%.</li>
</ol>
</div>

--- ¿Qué son los agentes de IA? Tres tipos empresariales ---
> Los agentes de IA son componentes especializados que ejecutan tareas empresariales de forma autónoma. Tres tipos, diferencias con chatbots y RPA.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">De un vistazo - Agentes de IA en la empresa</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Los agentes de IA son componentes de software especializados que ejecutan tareas de negocio de forma autónoma - a diferencia de chatbots (solo respuestas) o RPA (solo reglas).</li>
<li>Tres tipos: Document Agents (lectura y procesamiento de documentos), Workflow Agents (orquestación de procesos entre sistemas), Knowledge Agents (respuestas contextuales desde el conocimiento corporativo).</li>
<li>McKinsey (2024) estima que los agentes de IA podrían automatizar hasta el 30% de las horas de trabajo en la mayoría de ocupaciones para 2030.</li>
<li>El agente no es el modelo - el modelo de lenguaje es intercambiable, el agente aporta lógica de negocio, integración de sistemas y governance.</li>
<li>El despliegue corporativo requiere un Decision Layer entre agente y sistema destino - para que cada decisión automatizada sea trazable, auditable y conforme.</li>
</ul>
</div>

## ¿Qué es un agente de IA?

Un agente de IA es un componente de software especializado que, basándose en modelos de lenguaje grandes (LLMs), ejecuta tareas empresariales de forma autónoma. A diferencia de un chatbot, que responde preguntas, un agente ejecuta acciones: lee un documento, evalúa su contenido, toma una decisión y lanza una acción en un sistema objetivo.

Los agentes de IA en el contexto corporativo no actúan libremente. Operan dentro de límites definidos: conjuntos de reglas, ámbitos de validez, umbrales de confianza, reglas de escalado. Cada decisión del agente es transparente y auditable.

La base de un agente de IA es un modelo de lenguaje: Claude, ChatGPT, Gemini, Llama, Mistral, DeepSeek o gpt-oss. El modelo proporciona la comprensión del lenguaje. El agente aporta la lógica de negocio, la integración de sistemas y la governance.

## Delimitación: agente de IA vs. chatbot vs. RPA

Estos tres conceptos se confunden con frecuencia. Resuelven problemas diferentes.

**Chatbot:** Un chatbot responde preguntas en lenguaje natural. No tiene capacidad de acción. Cuando un empleado pregunta "¿Cuántos días de vacaciones me quedan?", el chatbot responde. No reserva vacaciones, no verifica reglas, no genera un Audit Trail.

**RPA (Robotic Process Automation):** RPA automatiza tareas repetitivas basadas en reglas a través de interfaces de usuario. Un bot de RPA navega por SAP, copia datos de A a B, rellena formularios. RPA no entiende lenguaje. Cuando el formulario cambia, el bot se rompe.

**Agente de IA:** Un agente de IA entiende contexto, interpreta datos no estructurados y toma decisiones. Lee una factura, independientemente del formato, comprende su contenido, aplica conjuntos de reglas y genera una propuesta de contabilización. Cuando el formato de la factura cambia, el agente sigue funcionando porque entiende el contenido, no reconoce el diseño.

| Propiedad | Chatbot | RPA | Agente de IA |
|------------|---------|-----|----------|
| Comprensión del lenguaje | Sí | No | Sí |
| Capacidad de acción | No | Sí (basada en reglas) | Sí (basada en contexto) |
| Datos no estructurados | Sí | No | Sí |
| Governance/Auditoría | No | Parcialmente | Sí (mediante Decision Layer) |
| Integración de sistemas | Superficial | Via UI | Via API/Integration Layer |
| Adaptación a cambios | Cambiar prompt | Reprogramar bot | El agente aprende el contexto |

## Tres tipos de agentes de IA en la empresa

En la arquitectura de Gosign existen tres tipos de agentes. Cada tipo tiene un ámbito de tareas definido y opera dentro de los límites que establece el Decision Layer.

### Document Agents

Los Document Agents leen, comprenden y procesan documentos. Facturas, partes de baja, contratos, certificados, justificantes, notas de crédito.

La diferencia clave frente a OCR o reconocimiento de plantillas: los Document Agents tienen auténtica comprensión del lenguaje. No reconocen campos en posiciones determinadas de una página, sino que entienden el contenido del documento. Una factura en formato PDF, como imagen escaneada o como adjunto de correo: el Document Agent comprende las tres.

Un Document Agent para procesamiento contable lee una factura entrante y extrae: emisor, importe, descripción del servicio, fecha, tipo impositivo, datos bancarios. Genera un conjunto de datos estructurado que se transfiere al Decision Layer.

Los Document Agents no trabajan aislados. Son el punto de entrada de un workflow: tras la lectura del documento, toma el relevo el Workflow Agent.

### Workflow Agents

Los Workflow Agents orquestan procesos entre sistemas. Coordinan el flujo entre Document Agent, Decision Layer y sistema objetivo.

Un Workflow Agent para el procesamiento de facturas coordina: el Document Agent lee la factura -> el Decision Layer verifica la propuesta de contabilización -> con alta confianza, la contabilización va al sistema objetivo -> con baja confianza, se escala al responsable -> tras la aprobación, se finaliza la contabilización -> todo el proceso queda documentado en el Audit Trail.

Los Workflow Agents gestionan también las excepciones: ¿Qué ocurre si el sistema objetivo no está disponible? ¿Qué ocurre ante un timeout? ¿Qué ocurre si el responsable no responde? El Workflow Agent tiene reglas de escalado, mecanismos de reintento y lógica de timeout.

La orquestación de workflow se ejecuta mediante [Trigger.dev](https://trigger.dev/) o [Camunda](https://camunda.com/), según la complejidad y los requisitos de compliance del cliente. Los workflows son representables visualmente, versionados y ajustables sin programación.

### Knowledge Agents

Los Knowledge Agents proporcionan respuestas contextuales desde el conocimiento corporativo. Acuerdos de empresa, directrices, convenios colectivos, reglas de compliance, políticas internas.

La diferencia frente a un buscador: un Knowledge Agent entiende la pregunta, busca en el contexto relevante y entrega una respuesta con referencia a la fuente y versión de la norma. Cuando un responsable pregunta "¿Se aplica el complemento de nocturnidad también a trabajadores a tiempo parcial del convenio regional?", el Knowledge Agent entrega la respuesta con referencia al acuerdo de empresa vigente en su versión actual.

Los Knowledge Agents utilizan RAG (Retrieval Augmented Generation): el conocimiento corporativo se indexa en una base de datos vectorial. El agente busca los pasajes relevantes y genera una respuesta basada en esas fuentes, no en su entrenamiento.

Cada respuesta contiene: la fuente, la versión de la norma, la fecha de validez. Sin alucinaciones, sin referencias inventadas a normativas.

## Cómo interactúan los agentes de IA en la arquitectura corporativa

Los tres tipos de agentes no funcionan aislados. En una implementación corporativa típica, el Workflow Agent orquesta el proceso completo y delega en Document y Knowledge Agents especializados.

Un ejemplo de administración de personal: Llega un parte de baja médica (correo con adjunto PDF). El Document Agent lee el parte y extrae: empleado, período, certificado médico, certificado de continuación. El Knowledge Agent verifica: ¿Qué reglas aplican a este empleado? Convenio colectivo, acuerdo de empresa, acuerdos adicionales individuales. El Decision Layer evalúa: ¿Está correctamente calculada la continuación salarial? ¿Se cumplen los plazos? El Workflow Agent coordina todo el flujo y asegura que todos los sistemas se actualicen.

Cada agente tiene su ámbito de tareas definido. Ningún agente "decide" solo sobre procesos críticos de negocio. El [Decision Layer](/es/decision-layer/) se sitúa entre el agente y el sistema objetivo y garantiza la governance.

## Agnosticismo de modelo: el agente no es el modelo

Una confusión frecuente: el agente no es el modelo de lenguaje. El modelo (Claude, ChatGPT, Llama) proporciona la comprensión del lenguaje. El agente aporta la lógica de negocio, la integración de sistemas, la governance.

En la arquitectura de Gosign, la capa de modelo es intercambiable. Cuando aparece un nuevo modelo, más potente, más económico, con mejor licencia, puede integrarse sin modificar las capas superiores. La lógica de negocio en el Decision Layer, los workflows, los conjuntos de reglas permanecen inalterados.

Un agente puede utilizar varios modelos: un modelo open-source económico para la preclasificación y un modelo más potente para decisiones complejas. El enrutamiento entre modelos es configurable.

Este agnosticismo de modelo previene el vendor lock-in. Ninguna empresa depende de un único proveedor de modelos.

## Requisitos para agentes de IA en la empresa

Los agentes de IA en entornos corporativos necesitan más que un modelo de lenguaje:

**Governance:** Cada decisión del agente debe ser transparente y auditable. El Decision Layer lo garantiza.

**Integración:** Los agentes deben integrarse con los sistemas existentes: SAP, [Sage](https://www.sage.com/es-es/), [Workday](https://www.workday.com/), [SuccessFactors](https://www.sap.com/products/hcm.html), SharePoint. El Integration Layer desacopla la lógica del agente del sistema objetivo.

**Infraestructura:** Los agentes necesitan un entorno de ejecución: hosting de LLM, bases de datos vectoriales para RAG, motor de workflow, API Gateway. Esta infraestructura puede operar en la nube, self-hosted o en modo híbrido.

**Participación de los trabajadores:** En España, el Comité de Empresa tiene competencias de información y consulta en la implantación de sistemas de IA, según el Estatuto de los Trabajadores. La arquitectura debe contemplarlo desde el principio.

Más información: [AI Agents en detalle](/es/servicios/ai-agents/)

<a href="/es/contacto/" target="_blank" rel="noopener noreferrer">Solicitar cita</a> - Le mostramos qué tipo de agente encaja en su proceso.

--- RAG y Document Intelligence para empresas (2026) ---
> RAG hace accesibles los documentos corporativos para la IA - sin entrenamiento, sin fuga de datos. Más: anonimización PII y redacción de contratos.

## La pregunta central: ¿Puede la IA entender nuestros propios documentos?

"¿Podemos hacer que la IA responda a partir de nuestros propios documentos?" Esta pregunta surge en prácticamente todas las empresas. La respuesta es sí, con RAG (Retrieval Augmented Generation). El principio: tus documentos permanecen en tu infraestructura. El modelo de lenguaje no se entrena con tus datos. En su lugar, las secciones relevantes de los documentos se proporcionan al modelo como contexto con cada consulta. El modelo responde en base a esas secciones, con citas de fuentes.

Sin fuga de datos a terceros. Sin reentrenamiento. Sin pérdida de control. Y aun así, respuestas en lenguaje natural basadas directamente en el conocimiento de tu organización.

RAG es hoy el enfoque estándar para conectar modelos de lenguaje con conocimiento específico de la organización. Este artículo explica cómo funciona RAG, cuándo es la opción correcta y por qué Document Intelligence va mucho más allá de un mejor buscador, incluyendo anonimización PII, redacción de contratos y detección de firmas.

IDC (2025) estima que el 90% de todos los nuevos datos empresariales son no estructurados - documentos, correos, contratos, actas de reuniones. RAG es el metodo estandar para hacer estos datos accesibles a la IA sin reentrenar el modelo.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">De un vistazo - RAG & Document Intelligence</p>
<ul class="text-body text-gosign-text space-y-2">
<li>RAG conecta modelos de lenguaje con tus documentos corporativos - sin entrenamiento, sin fuga de datos. Los documentos permanecen en tu infraestructura.</li>
<li>Para el 90% de los casos de uso empresarial, RAG supera al Fine-Tuning: menor coste, actualizacion inmediata via re-indexacion, citas de fuentes integradas.</li>
<li>Document Intelligence va mas alla de la busqueda: anonimizacion PII, redaccion de contratos y deteccion de firmas son funcionalidades listas para produccion.</li>
<li>La calidad de indexacion determina la calidad de las respuestas. Estrategia de chunking, enriquecimiento con metadatos y control de acceso son innegociables.</li>
<li>RAG se integra en el portal Enterprise AI para que cada departamento acceda solo a su base de conocimiento autorizada.</li>
</ul>
</div>

## Cómo funciona RAG

RAG consta de dos fases: la indexación de tus documentos y la respuesta a consultas. El flujo se puede ilustrar en un diagrama:

```
Documentos → Chunking → Embedding → Base de datos vectorial
│
Consulta del usuario → Query Embedding → Búsqueda por similitud
│
Secciones relevantes + Consulta → LLM → Respuesta con cita de fuente
```

**Fase 1: Indexación.** Tus documentos - PDFs, archivos Word, páginas HTML, recibos escaneados - se dividen en secciones significativas (chunking). Cada sección se convierte mediante un modelo de embedding en un vector matemático. Estos vectores se almacenan en una base de datos vectorial. El vector representa el significado de la sección, no su redacción literal. "Política de teletrabajo" y "Acuerdo de trabajo a distancia" se encuentran próximos en el espacio vectorial, aunque usen palabras diferentes.

**Fase 2: Consulta.** Cuando un usuario formula una pregunta, esta también se convierte en un vector. La base de datos vectorial encuentra las secciones semánticamente más cercanas a la pregunta, no por búsqueda de palabras clave, sino por cálculo de similitud. Estas secciones relevantes se envían al modelo de lenguaje junto con la pregunta original. El modelo genera una respuesta basada en esas fuentes concretas.

El resultado: una respuesta en lenguaje natural fundamentada en tus documentos, con referencias a los pasajes fuente de donde procede la información.

La calidad de la indexación es decisiva. Chunks demasiado grandes diluyen la relevancia. Chunks demasiado pequeños pierden el contexto. La estrategia de chunking - tamaño, solapamiento, enriquecimiento con metadatos - determina en gran medida la calidad de las respuestas. Un buen pipeline RAG no es la tecnología en sí, sino su configuración para tu paisaje documental específico.

## RAG vs. Fine-Tuning vs. Prompting

RAG no es la única forma de dotar a un modelo de lenguaje con conocimiento de dominio. Existen tres enfoques fundamentales que difieren en esfuerzo, coste e idoneidad:

| Enfoque | Qué ocurre | Cuándo es adecuado | Coste | Actualización |
|---|---|---|---|---|
| Prompting | Contexto incluido directamente en el prompt | Volúmenes de datos pequeños | Bajo | Inmediata |
| RAG | Documentos relevantes encontrados automáticamente | Grandes bases de conocimiento | Medio | Re-indexación |
| Fine-Tuning | Modelo reentrenado | Lenguaje especializado/dominio | Alto | Solo mediante reentrenamiento |

**Prompting** funciona cuando el contexto relevante cabe en la ventana de contexto del modelo, típicamente unas decenas de páginas. Para un único acuerdo de empresa, es suficiente. Para una base de conocimiento con cientos de documentos, no.

**RAG** escala a grandes colecciones documentales. La base de datos vectorial puede contener cientos de miles de secciones. Con cada consulta, solo se recuperan y envían al modelo las secciones relevantes. Los documentos pueden actualizarse en cualquier momento; basta una re-indexación. No es necesario reentrenar el modelo.

**Fine-Tuning** modifica los pesos del propio modelo. Es apropiado cuando el modelo necesita aprender un lenguaje de dominio completamente nuevo - por ejemplo, terminología médica o una nomenclatura propietaria - o cuando se requiere un formato de respuesta muy específico. El Fine-Tuning es costoso, complejo y requiere reentrenamiento con cada actualización.

Para el 90% de los casos de uso empresarial, RAG es el enfoque correcto. La combinación de grandes bases de conocimiento, actualizaciones frecuentes y la necesidad de citas de fuentes convierte a RAG en el estándar para el conocimiento corporativo.

## Document Intelligence: más que búsqueda

RAG responde preguntas basándose en documentos. Document Intelligence va más allá: abarca todos los métodos mediante los cuales la IA no solo lee documentos, sino que los entiende, clasifica y procesa, incluyendo la protección de información sensible.

Las tres áreas de aplicación más importantes en el contexto empresarial: anonimización PII, redacción de contratos y detección de firmas.

### Anonimización PII: pseudonimización de ida y vuelta

Los datos personales (PII, Personally Identifiable Information) no pueden enviarse a un modelo de lenguaje en muchos casos de uso. Salarios, nombres reales, números de empleado, datos de salud. El RGPD y las políticas internas de protección de datos establecen límites claros.

La solución es la pseudonimización de ida y vuelta (roundtrip). Un ejemplo concreto:

**Documento original:**
"María García, Departamento de Finanzas, salario 42.000 euros, se adhiere al acuerdo de empresa sobre horario flexible."

**Tras la pseudonimización (entrada al modelo):**
"Persona_A, Departamento_X, Salario_Y, se adhiere al acuerdo de empresa sobre horario flexible."

El modelo de lenguaje procesa la consulta con datos pseudonimizados. En ningún momento ve el nombre real, el departamento ni el salario.

**Tras la re-identificación (salida al usuario):**
Los marcadores en el resultado se reemplazan por los datos originales. El usuario ve la respuesta completa. El modelo nunca la vio.

Este ciclo ocurre automáticamente. Para el usuario, el proceso es transparente. Para el modelo, los datos son inaccesibles en todo momento. Para la [infraestructura](/es/servicios/infraestructura/) esto significa: la capa de pseudonimización se sitúa entre el usuario y el modelo y se aplica de forma técnica, no opcional.

La anonimización PII es especialmente relevante para aplicaciones de RRHH, donde expedientes de personal, nóminas o evaluaciones de rendimiento deben procesarse con ayuda de IA. Sin anonimización, estos casos de uso no son conformes con el RGPD en la UE.

### Redacción de contratos (Redaction)

La redacción de contratos va más allá de la pseudonimización. Mientras la pseudonimización sustituye datos y los restaura al final, la redacción elimina físicamente el contenido del documento, de forma irrevocable para el destinatario correspondiente.

El caso de uso: distintos departamentos necesitan vistas diferentes del mismo contrato. El departamento jurídico ve el contrato completo. Compras ve una versión sin cláusulas de responsabilidad. La dirección ve un resumen sin detalles operativos.

La redacción funciona con reglas. Para cada categoría de documento y cada grupo de destinatarios se define qué secciones son visibles y cuáles se redactan. Las reglas se configuran y versionan en el [Decision Layer](/es/decision-layer/), no se aplican manualmente.

El resultado: cada rol ve exactamente la información que es relevante y está autorizada para él. Sin redacción manual. Sin pasajes olvidados. Sin versiones reenviadas accidentalmente en su totalidad.

### Detección de firmas

Los archivos de contratos en las empresas suelen contener miles de documentos. La pregunta de si un contrato específico está completamente firmado requiere hoy a menudo un repaso manual página por página. Con cientos de contratos, esto no es viable.

Document Intelligence resuelve este problema mediante la detección automatizada de firmas. El sistema comprueba contratos escaneados en busca de firmas en las ubicaciones previstas. Las firmas faltantes se señalan automáticamente. El resultado: una visión general de todos los contratos del archivo que aún no están completamente firmados, en minutos en lugar de semanas.

El caso de uso va más allá de la mera detección. En combinación con un pipeline RAG, el sistema también puede responder preguntas como: "¿Qué contratos marco con una duración superior a 3 años se renovaron en el último trimestre sin firma de la dirección?"

## Ejemplo práctico: El asistente de acuerdos de empresa

Un escenario concreto de la práctica de RRHH. Un departamento de personal de una empresa mediana gestiona más de 100 acuerdos de empresa activos: jornada laboral, teletrabajo, viajes de trabajo, formación, planes de jubilación, gestión de la reincorporación, protección de datos, uso de TI, y más. Cada acuerdo tiene modificaciones, anexos y referencias cruzadas a otros acuerdos.

Cuando un administrativo debe responder la pregunta: "¿Qué normativa aplica para días de teletrabajo de empleados a tiempo parcial en producción?", hoy eso significa: encontrar el acuerdo de empresa correcto, localizar el pasaje relevante, comprobar si existe una modificación, cotejar con el convenio colectivo, considerar las normas específicas del centro de trabajo. Resultado: de 30 a 45 minutos de búsqueda. En caso de duda, consulta al departamento jurídico. Otros días más de espera.

Con un asistente de acuerdos de empresa basado en RAG: todos los acuerdos se indexan, incluyendo modificaciones, anexos y referencias cruzadas. El administrativo formula la pregunta en lenguaje natural. El sistema encuentra los pasajes relevantes de los documentos correctos, tiene en cuenta la modificación de marzo de 2025, referencia la normativa especial para empleados de producción y entrega la respuesta en 10 segundos. Con cita de fuente. Con versión de la norma.

Esto no es un escenario teórico. Es el caso de uso estándar con el que las empresas implementan su primer pipeline RAG. El esfuerzo es asumible: proporcionar documentos, configurar la estrategia de chunking, definir derechos de acceso, probar. La [infraestructura](/es/servicios/infraestructura/) - base de datos vectorial, modelo de embedding, modelo de lenguaje, pipeline de recuperación - se construye una vez y queda disponible para casos de uso adicionales.

## Aseguramiento de calidad: Por qué los resultados RAG son tan buenos como la indexación

RAG no funciona solo. Las fuentes de error más comunes en la práctica:

**Mala estrategia de chunking.** Chunks demasiado grandes (capítulos enteros) proporcionan demasiado contexto irrelevante. Chunks demasiado pequeños (párrafos individuales) pierden la coherencia. El tamaño de chunk adecuado depende del tipo de documento: una especificación técnica requiere chunks diferentes que un acuerdo de empresa.

**Metadatos ausentes.** Sin metadatos (tipo de documento, fecha de vigencia, versión, ámbito de aplicación) el pipeline de recuperación no puede distinguir entre una normativa vigente y una obsoleta. El enriquecimiento de metadatos durante la indexación no es opcional, es esencial.

**Sin control de acceso.** En un entorno empresarial, no todos los usuarios deben acceder a todos los documentos. El pipeline RAG debe reflejar la estructura de permisos existente: documentos de RRHH solo para RRHH, datos financieros solo para Finanzas, comunicaciones de dirección solo para personas autorizadas.

**Sin verificación de fuentes.** RAG proporciona citas de fuentes. ¿Pero son correctas? Un aseguramiento de calidad - comprobación aleatoria de referencias, mecanismo de retroalimentación para usuarios, evaluación periódica - es necesario para detectar alucinaciones y mejorar el pipeline.

Este aseguramiento de calidad forma parte de la operación continua, no de una configuración inicial única. Los documentos cambian. Se añaden nuevos. Los antiguos dejan de ser válidos. El pipeline RAG debe evolucionar, mediante re-indexación periódica, actualización de metadatos y retroalimentación de los usuarios.

## Integración en el portal Enterprise AI

RAG no es un sistema aislado. En una arquitectura bien diseñada, el pipeline RAG está integrado en el [portal Enterprise AI](/es/revista/enterprise-ai-chat-interface/). Los empleados formulan preguntas a través de una interfaz unificada, la misma a través de la cual interactúan con los [agentes de IA](/es/servicios/ai-agents/).

El portal gestiona los derechos de acceso: ¿quién puede consultar qué base de conocimiento? Los empleados de RRHH ven el asistente de acuerdos de empresa. El departamento jurídico ve el asistente de contratos. Compras ve el asistente de directrices de proveedores. Cada usuario ve solo aquello para lo que está autorizado.

La combinación de RAG y agentes de IA abre posibilidades ampliadas: un agente puede no solo responder una pregunta, sino, basándose en los resultados RAG, desencadenar una acción - por ejemplo, generar una alerta de vencimiento cuando un contrato está a punto de expirar, o crear una lista de verificación cuando un nuevo acuerdo de empresa entra en vigor.

---

**Enterprise AI-Infrastruktur Blueprint 2026 - Serie de artículos**

| ← Anterior | Visión general | Siguiente → |
|:---|:---:|---:|
| [Portal Enterprise AI: Cuatro interfaces Open Source en comparación](/es/revista/enterprise-ai-chat-interface/) | [Visión general](/es/revista/infraestructura-ia-blueprint-2026/) | [De chatbots a agentes IA: MCP, A2A y sistemas Multi-Agent](/es/revista/agentes-ia-enterprise-guia/) |

*Todos los artículos de esta serie: [Enterprise AI-Infrastruktur Blueprint 2026](/es/revista/infraestructura-ia-blueprint-2026/)*

---

**¿Quieres hacer accesible el conocimiento de tu empresa para la IA?** Gosign construye pipelines RAG y soluciones de Document Intelligence para clientes empresariales - agnóstico en cuanto a modelos, con anonimización PII y control de acceso completo.

<a href="/es/contacto/" target="_blank" rel="noopener noreferrer">Reserva una consulta</a>. 30 minutos para determinar qué documentos deberían hacerse accesibles para la IA primero.

--- Cómo medir el ROI de las inversiones en IA ---
> Cómo los CFOs evalúan el ROI de enterprise AI. Costes de proceso, tasas de error y esfuerzo de auditoría como KPIs medibles.

## El problema con el ROI de la IA

La mayoría de los cálculos de ROI para inversiones en IA fracasan por falta de precisión. "Un 30% más productivos" suena convincente en una presentación, pero no es demostrable cuando nadie ha definido qué significa "más productivos" en un proceso concreto.

Los CFOs conocen este problema. Ven proyectos piloto que ofrecen demos impresionantes pero ningún número defendible ante el consejo. Ven presupuestos de IA aprobados como proyectos de innovación sin un business case trazable.

No es que la IA carezca de ROI. Es que la IA se mide en el punto equivocado.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">De un vistazo - Medir el ROI de enterprise AI</p>
<ul class="text-body text-gosign-text space-y-2">
<li>El ROI de la IA surge de la eficiencia de proceso, no de la productividad individual. Un proceso documental automatizado ahorra más de 200 horas al mes.</li>
<li>Cinco KPIs hacen el ROI medible: coste de proceso por caso, tasa de error, tiempo de ciclo, esfuerzo de auditoría y costes de escalado.</li>
<li>Según McKinsey (2024), las empresas que aplican IA en operaciones financieras logran una reducción de costes del 30 al 50% en procesos documentales en el primer año.</li>
<li>El Decision Layer separa el análisis de IA de la decisión de negocio y crea un Audit Trail automático - las métricas de ROI surgen como subproducto.</li>
<li>Empiece con un proceso, un agente, y mida los KPIs tras 4 a 6 semanas. La diferencia es el ROI.</li>
</ul>
</div>

## Dónde se genera realmente el ROI

El ROI de enterprise AI no surge de la productividad individual de cada empleado. Surge de la eficiencia de proceso a lo largo de flujos de trabajo completos.

Un ejemplo: en una organización de Servicios Compartidos de RRHH, un equipo de 8 gestores procesa mensualmente 1.200 partes de baja por enfermedad. Cada caso requiere una media de 12 minutos: abrir documento, verificar datos, calcular plazos conforme al convenio colectivo, contabilizar en SAP, informar al responsable. Son 240 horas al mes para un único tipo de documento.

Un [Document Agent](/es/servicios/ai-agents/) reduce el tiempo de procesamiento manual por caso a menos de 2 minutos - en casos estándar a cero, porque el agente automatiza el proceso completo hasta la fase de aprobación. Los gestores solo revisan excepciones y escalados.

Esto no es una promesa vaga de productividad. Es una reducción medible de 240 a 40 horas al mes - para un solo proceso. Multiplicado por 5 - 10 procesos, el resultado es un business case que cualquier CFO entiende.


## Los KPIs adecuados

Cinco KPIs hacen el ROI de agentes de IA medible y comunicable internamente.

Primero: coste de proceso por caso. ¿Cuánto cuesta procesar un parte de baja, una factura, un contrato hoy? ¿Cuánto cuesta tras implantar el agente? La diferencia es el ROI directo.

Segundo: tasa de error. Los procesos manuales tienen tasas de error típicas del 2 - 5%. Un agente basado en reglas solo comete errores cuando las reglas son defectuosas - y las reglas son versionadas y corregibles. Cada error evitado tiene un coste consecuente cuantificable.

Tercero: tiempo de ciclo. ¿Cuánto tarda un caso desde su recepción hasta su cierre? Los agentes reducen el tiempo de espera a casi cero - el caso se procesa en cuanto llega, no cuando un gestor lo recoge.

Cuarto: esfuerzo de auditoría. En procesos regulados (retenciones de IRPF, inspecciones de la Seguridad Social, obligaciones del Plan General Contable) se genera un esfuerzo considerable en documentación manual y gestión de evidencias. Un agente con [Decision Layer](/es/decision-layer/) documenta automáticamente: qué regla se aplicó, qué datos estaban disponibles, qué decisión se tomó, quién aprobó. El Audit Trail surge como subproducto del proceso.

Quinto: costes de escalado. ¿Cuánto cuesta aumentar el volumen actual un 50%? Con procesos manuales: más plantilla. Con infraestructura de agentes: más capacidad de cómputo. Las curvas de coste divergen radicalmente.

<div class="overflow-x-auto">

| KPI | Proceso manual | Con agente AI | Método de medición |
|-----|---------------|---------------|-------------------|
| Coste de proceso por caso | 15 - 60 USD | 2 - 8 USD | Comparación antes/después |
| Tasa de error | 2 - 5% | < 0,5% | Auditoría de muestras |
| Tiempo de ciclo | 1 - 5 días | Minutos | Delta de marcas temporales |
| Esfuerzo de auditoría | 40 - 80 h/mes | < 5 h/mes | Horas registradas |
| Escalado (+50% volumen) | +50% plantilla | +10% cómputo | Seguimiento de costes |

</div>

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">eBook gratuito: IA en Finanzas</p>
<p class="text-body text-gosign-text mb-4">Compliance, auditores externos y Decision Layer - el manual de gobernanza para dirección financiera.</p>
<a href="/es/ebook/ia-finanzas-manual-gobernanza/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Descargar gratis</a>
</div>

## El Decision Layer como palanca de ROI

El [Decision Layer](/es/decision-layer/) es el punto donde el ROI se vuelve medible. Separa el análisis de IA de la decisión de negocio y documenta ambos como actos auditables.

Esto significa: para cada caso existe un registro completo - entrada, regla aplicada, recomendación del agente, decisión del humano, marca temporal. De estos registros se pueden derivar métricas de ROI automáticamente, sin recogida manual de datos.

De esto se deriva también: el ROI mejora con el tiempo. Dado que los ajustes de reglas están versionados y su impacto en tasas de error y tiempos de ciclo es medible, surge un ciclo de optimización continuo - documentado y trazable.


## Cómo deberían empezar las empresas

No con una estrategia de IA. Sino con un proceso concreto.

Identificar el proceso con mayor volumen y mayores costes manuales. Medir la línea base: costes actuales del proceso, tasa de error, tiempo de ciclo. Construir un agente para ello y medir los mismos KPIs tras 4 - 6 semanas.

La diferencia es el ROI. Sin presentaciones, sin estimaciones - cifras duras de un proceso productivo.

En Gosign construimos [agentes de IA](/es/servicios/ai-agents/) con exactamente este enfoque: un proceso, un agente, KPIs medibles tras 4 - 6 semanas. El [Decision Layer](/es/decision-layer/) entrega automáticamente la base de datos para el business case.

--- Security Baseline para el stack completo ---
> Security Baseline basada en YAML para Supabase, Next.js, Edge Functions y Trigger.dev con checks automatizados.

Los runbooks anteriores han descrito los componentes individuales: [Supabase Platform](/es/revista/supabase-self-hosting/) (artículo 1), [capa de aplicación Next.js](/es/revista/nextjs-supabase-configuracion-segura/) (artículo 2), [Edge Functions](/es/revista/supabase-edge-functions-seguridad/) (artículo 3), [Trigger.dev Jobs](/es/revista/trigger-dev-background-jobs/) (artículo 4) y [Claude Code como control de seguridad](/es/revista/claude-code-security-devops/) (artículo 5).

Este último artículo reúne todas las reglas en un **único archivo legible por máquina**: el `security-baseline.yml`. Este archivo define el estado objetivo de todo el stack. Todos los deployments, reviews y auditorías se verifican contra esta Baseline, tanto mediante scripts determinísticos como mediante Claude Code.

El artículo proporciona tres cosas:
1. El `security-baseline.yml` completo
2. El script que lo verifica automáticamente
3. La integración con la auditoría de Claude Code del artículo 5


<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">De un vistazo - Artículo 6 de 6 de la serie DevOps Runbook</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Un único archivo YAML define el estado objetivo del stack</li>
<li>Verificaciones automatizadas diarias</li>
<li>Análisis semanal de Claude</li>
<li>Puerta de despliegue bloquea ante violaciones críticas</li>
<li>Documento vivo actualizado con cambios del stack</li>
</ul>
</div>

## Índice de la serie

Esta guía forma parte de nuestra serie de runbooks DevOps para app stacks self-hosted.

1. [Supabase Self-Hosting Runbook](/es/revista/supabase-self-hosting/)
2. [Next.js sobre Supabase de forma segura](/es/revista/nextjs-supabase-configuracion-segura/)
3. [Supabase Edge Functions de forma segura](/es/revista/supabase-edge-functions-seguridad/)
4. [Trigger.dev Background Jobs en producción segura](/es/revista/trigger-dev-background-jobs/)
5. [Claude Code como control de seguridad en el workflow DevOps](/es/revista/claude-code-security-devops/)
6. [Security Baseline para el stack completo](/es/revista/security-baseline-stack/) - este artículo

Este artículo conecta todos los runbooks anteriores en una **estrategia de seguridad verificable**.

## Visión general de la arquitectura

```
security-baseline.yml
   |
   +---> scripts/check-baseline.sh     (determinístico, diariamente)
   |       |
   |       +---> baseline-report.md    (hechos: superado/no superado)
   |
   +---> Claude Code Audit             (contextual, semanalmente)
   |       |
   |       +---> claude-review.md      (interpretación + prioridades)
   |
   +---> Deployment Gate               (CI/CD, en cada deploy)
           |
           +---> Deploy bloqueado cuando se violan reglas críticas
```

La Baseline es la **Single Source of Truth** para el estado de seguridad. Todo lo demás - los scripts de verificación, Claude Code, las checklists de deployment de los artículos 1-5 - se deriva de ella.


### Categorías del Baseline

| Categoría | Número de reglas | Frecuencia de verificación | Escalada |
|---|---|---|---|
| Infraestructura (artículo 1) | 8 | Diaria | CRÍTICO: inmediatamente, AVISO: esta semana |
| Supabase Platform (artículo 1) | 6 | Diaria | CRÍTICO: inmediatamente |
| Next.js (artículo 2) | 7 | Diaria + en PR | CRÍTICO: bloqueo de deploy |
| Edge Functions (artículo 3) | 4 | Diaria | CRÍTICO: inmediatamente |
| Trigger.dev (artículo 4) | 5 | Diaria | AVISO: esta semana |
| Compliance | 3 | Semanal | CRÍTICO: inmediatamente |


## El security-baseline.yml

Este archivo pertenece al root del repositorio de infraestructura. Es legible por máquina (YAML), legible por humanos (comentarios) e interpretable por Claude Code (contexto).

```yaml
# security-baseline.yml
# Security Baseline für den self-hosted Stack
# Letzte Aktualisierung: 2026-03-12
# Verantwortlich: DevOps Team
#
# Diese Datei definiert den Soll-Zustand des gesamten Stacks.
# Sie wird täglich automatisch geprüft (scripts/check-baseline.sh)
# und wöchentlich von Claude Code kontextuell analysiert.

version: "1.0"
stack: "supabase-nextjs-trigger"
last_reviewed: "2026-03-12"

# =============================================
# INFRASTRUKTUR (Artikel 1)
# =============================================

infrastructure:
  servers:
    production:
      host: "10.0.1.10"
      external_hostname: "app.example.com"
      provider: "hetzner"    # CLOUD-Act-frei
    audit:
      host: "10.0.1.11"
      purpose: "security checks, monitoring, claude code"

  network:
    private_subnet: "10.0.1.0/24"
    # Nur diese Ports dürfen von aussen erreichbar sein
    allowed_external_ports:
      - 443    # HTTPS (über Reverse Proxy)
    # Diese Ports dürfen NUR intern erreichbar sein
    internal_only_ports:
      - 5432   # PostgreSQL (Supabase)
      - 5433   # PostgreSQL (Trigger.dev)
      - 8000   # Kong API Gateway
      - 3000   # Next.js (hinter Reverse Proxy)
      - 3040   # Trigger.dev Dashboard
      - 9000   # Supabase Studio

  firewall:
    layers: 2    # Cloud Firewall + Host Firewall
    baseline_file: "/opt/baselines/firewall-baseline.txt"
    drift_check: "daily"

  tls:
    provider: "letsencrypt"
    min_days_before_expiry: 14
    headers_required:
      - "Strict-Transport-Security"
      - "X-Frame-Options"
      - "X-Content-Type-Options"
      - "Content-Security-Policy"

  ssh:
    password_auth: false
    root_login: false
    pubkey_only: true
    allowed_users: ["deploy"]

  backups:
    frequency: "daily"
    max_age_hours: 26
    encryption: "gpg"
    external_storage: true    # auf audit-runner, nicht nur lokal
    restore_test: "monthly"

# =============================================
# SUPABASE PLATFORM (Artikel 1)
# =============================================

supabase:
  images:
    pinned: true              # kein :latest
    # Erwartete Images und Versionen (aktualisieren bei Updates)
    postgres: "supabase/postgres:15.6.1.143"
    kong: "kong:2.8.1"
    gotrue: "supabase/gotrue:v2.164.0"

  postgres:
    listen_address: "10.0.1.10"    # NUR internes Interface
    rls:
      required_on_all_public_tables: true
      # Tabellen die bewusst ohne RLS sind (mit Begründung)
      exceptions: []

  gotrue:
    jwt_exp: 3600               # max. 1 Stunde
    mailer_autoconfirm: false
    refresh_token_rotation: true

  studio:
    external_access: false      # nur über SSH Tunnel oder VPN

  secrets:
    env_file: ".env"
    env_file_permissions: "600"
    in_git: false
    min_length: 16
    # Erwartete Secrets (ohne Werte)
    required:
      - "JWT_SECRET"
      - "ANON_KEY"
      - "SERVICE_ROLE_KEY"
      - "POSTGRES_PASSWORD"
      - "DASHBOARD_USERNAME"
      - "DASHBOARD_PASSWORD"

# =============================================
# NEXT.JS APP LAYER (Artikel 2)
# =============================================

nextjs:
  service_role:
    # Dateien in denen service_role erlaubt ist
    allowed_files:
      - "lib/supabase/admin.ts"
    # Darf NIEMALS erscheinen in:
    forbidden_patterns:
      - "NEXT_PUBLIC_*"
      - "app/**/*.tsx"           # Client Components
      - ".next/static/**"        # Client Bundle

  auth:
    middleware_required: true
    middleware_file: "middleware.ts"
    middleware_uses: "getUser"     # NICHT getSession
    server_actions_require_auth: true
    route_handlers_require_auth: true

  security_headers:
    required:
      - "Strict-Transport-Security"
      - "X-Frame-Options"
      - "Content-Security-Policy"
      - "X-Content-Type-Options"

  env_vars:
    # Nur diese dürfen NEXT_PUBLIC sein
    allowed_public:
      - "NEXT_PUBLIC_SUPABASE_URL"
      - "NEXT_PUBLIC_SUPABASE_ANON_KEY"

  rate_limiting:
    required_endpoints:
      - "/api/auth/login"
      - "/api/auth/signup"
      - "/api/auth/reset"

# =============================================
# EDGE FUNCTIONS (Artikel 3)
# =============================================

edge_functions:
  purpose: "integrations_only"     # NICHT für Business-Logik
  runtime: "deno"

  requirements:
    webhook_signature_check: true
    input_validation: true
    cors_no_wildcard_in_production: true
    no_hardcoded_secrets: true
    max_duration_seconds: 60

  secrets:
    env_file: ".env.functions"
    in_git: false

  deployment:
    method: "volume_copy"          # Dateien ins Volume, Container restart

# =============================================
# TRIGGER.DEV (Artikel 4)
# =============================================

trigger_dev:
  version: "v3"
  hosting: "self-hosted"
  separate_database: true           # eigene PostgreSQL, nicht Supabase DB

  dashboard:
    external_access: false          # nur SSH Tunnel oder VPN

  task_requirements:
    max_duration_required: true
    concurrency_limit_required: true
    retry_config_required: true
    idempotency_on_external_calls: true
    exported: true                  # alle Tasks müssen exportiert sein

  logging:
    use_trigger_logger: true        # nicht console.log
    no_sensitive_data: true

  db_access:
    # Dateien in denen service_role / DATABASE_URL erlaubt ist
    allowed_files:
      - "trigger/lib/supabase.ts"
      - "trigger/lib/db.ts"
    connection_pool_max: 10

# =============================================
# CLAUDE CODE AUDIT (Artikel 5)
# =============================================

claude_code:
  runs_on: "audit-runner"           # NICHT auf Produktion
  allowed_tools: "Read,Grep,Glob"   # kein Bash
  max_turns: 10
  schedule: "weekly"                # Sonntag 06:00
  alert_on: "KRITISCH"

  api_key:
    separate_ci_key: true
    budget_limit_monthly_usd: 50

# =============================================
# COMPLIANCE
# =============================================

compliance:
  cloud_act:
    us_providers_allowed: false
    reason: "CLOUD Act Risiko: US-Behörden können Datenzugriff erzwingen"
    allowed_jurisdictions:
      - "EU"
      - "BR"

  data_residency:
    required: true
    allowed_countries:
      - "DE"     # Deutschland (Hetzner)
      - "BR"     # Brasilien

  git:
    no_secrets_in_repo: true
    infrastructure_as_code: true
    no_manual_server_changes: true
```

## El script de verificación de la Baseline

Este script lee el `security-baseline.yml` y verifica cada punto automáticamente. Se ejecuta diariamente en el servidor de auditoría.

```bash
#!/bin/bash
# scripts/check-baseline.sh
# Prüft den Produktionsserver gegen die security-baseline.yml
# Läuft auf dem audit-runner (10.0.1.11)

set -euo pipefail

PROD_HOST="10.0.1.10"
EXTERNAL_HOST="app.example.com"
REPORT=""
CRITICAL=0
WARNING=0
PASS=0

check() {
  local level="$1"    # KRITISCH, WARNUNG, INFO
  local name="$2"
  local result="$3"   # PASS oder FAIL
  local detail="$4"

  if [ "$result" = "PASS" ]; then
    REPORT+="  OK ${name}\n"
    ((PASS++))
  else
    REPORT+="  FAIL [${level}] ${name}: ${detail}\n"
    [ "$level" = "KRITISCH" ] && ((CRITICAL++))
    [ "$level" = "WARNUNG" ] && ((WARNING++))
  fi
}

echo "=== Security Baseline Check $(date +%Y-%m-%d) ==="

# -------------------------------------------
# INFRASTRUKTUR
# -------------------------------------------
REPORT+="\n## Infrastruktur\n\n"

# Ports von aussen
OPEN_PORTS=$(nmap -p 22,80,443,3000,3040,5432,5433,8000,9000 "$EXTERNAL_HOST" \
  -oG - 2>/dev/null | grep -oP '\d+/open' | grep -v "443" || true)
if [ -z "$OPEN_PORTS" ]; then
  check "KRITISCH" "Nur Port 443 extern offen" "PASS" ""
else
  check "KRITISCH" "Nur Port 443 extern offen" "FAIL" "Offen: $OPEN_PORTS"
fi

# Firewall Drift
FW_DIFF=$(ssh deploy@${PROD_HOST} "iptables-save" 2>/dev/null | \
  diff /opt/baselines/firewall-baseline.txt - 2>&1 || true)
if [ -z "$FW_DIFF" ]; then
  check "WARNUNG" "Firewall unverändert" "PASS" ""
else
  check "WARNUNG" "Firewall unverändert" "FAIL" "Firewall hat sich geändert"
fi

# SSH Konfiguration
SSH_PW=$(ssh deploy@${PROD_HOST} "sshd -T 2>/dev/null | grep passwordauthentication" || true)
if echo "$SSH_PW" | grep -q "no"; then
  check "KRITISCH" "SSH Passwort-Login deaktiviert" "PASS" ""
else
  check "KRITISCH" "SSH Passwort-Login deaktiviert" "FAIL" "Passwort-Auth noch aktiv"
fi

SSH_ROOT=$(ssh deploy@${PROD_HOST} "sshd -T 2>/dev/null | grep permitrootlogin" || true)
if echo "$SSH_ROOT" | grep -q "no"; then
  check "KRITISCH" "SSH Root-Login deaktiviert" "PASS" ""
else
  check "KRITISCH" "SSH Root-Login deaktiviert" "FAIL" "Root-Login noch möglich"
fi

# TLS Zertifikat
CERT_DAYS=$(echo | openssl s_client -connect ${EXTERNAL_HOST}:443 2>/dev/null | \
  openssl x509 -noout -enddate 2>/dev/null | cut -d= -f2)
if [ -n "$CERT_DAYS" ]; then
  EPOCH_CERT=$(date -d "$CERT_DAYS" +%s 2>/dev/null || echo 0)
  EPOCH_NOW=$(date +%s)
  DAYS_LEFT=$(( (EPOCH_CERT - EPOCH_NOW) / 86400 ))
  if [ "$DAYS_LEFT" -ge 14 ]; then
    check "WARNUNG" "TLS Zertifikat gültig (${DAYS_LEFT} Tage)" "PASS" ""
  else
    check "WARNUNG" "TLS Zertifikat gültig" "FAIL" "Nur noch ${DAYS_LEFT} Tage"
  fi
fi

# Security Headers
for HEADER in "Strict-Transport-Security" "X-Frame-Options" "X-Content-Type-Options"; do
  if curl -sI "https://${EXTERNAL_HOST}" | grep -qi "$HEADER"; then
    check "WARNUNG" "Header: ${HEADER}" "PASS" ""
  else
    check "WARNUNG" "Header: ${HEADER}" "FAIL" "Header fehlt"
  fi
done

# Backup
LAST_BACKUP=$(ssh deploy@${PROD_HOST} "ls -t /opt/backups/*.gpg 2>/dev/null | head -1" || true)
if [ -n "$LAST_BACKUP" ]; then
  BACKUP_AGE=$(ssh deploy@${PROD_HOST} \
    "echo \$(( (\$(date +%s) - \$(stat -c %Y ${LAST_BACKUP})) / 3600 ))" 2>/dev/null || echo 999)
  if [ "$BACKUP_AGE" -le 26 ]; then
    check "KRITISCH" "Backup aktuell (${BACKUP_AGE}h alt)" "PASS" ""
  else
    check "KRITISCH" "Backup aktuell" "FAIL" "${BACKUP_AGE} Stunden alt"
  fi
else
  check "KRITISCH" "Backup aktuell" "FAIL" "Kein Backup gefunden"
fi

# Disk Space
DISK=$(ssh deploy@${PROD_HOST} "df -h / | tail -1 | awk '{print \$5}' | tr -d '%'" 2>/dev/null || echo 99)
if [ "$DISK" -le 85 ]; then
  check "WARNUNG" "Disk Usage (${DISK}%)" "PASS" ""
else
  check "WARNUNG" "Disk Usage" "FAIL" "${DISK}% belegt"
fi

# -------------------------------------------
# SUPABASE
# -------------------------------------------
REPORT+="\n## Supabase\n\n"

# Container laufen
STOPPED=$(ssh deploy@${PROD_HOST} "cd /opt/supabase && docker compose ps --format json 2>/dev/null" | \
  jq -r 'select(.State != "running") | .Name' 2>/dev/null || true)
if [ -z "$STOPPED" ]; then
  check "KRITISCH" "Alle Supabase Container running" "PASS" ""
else
  check "KRITISCH" "Alle Supabase Container running" "FAIL" "Gestoppt: $STOPPED"
fi

# Images gepinnt (kein :latest)
LATEST_IMAGES=$(ssh deploy@${PROD_HOST} "cd /opt/supabase && grep 'image:' docker-compose.yml | grep 'latest'" 2>/dev/null || true)
if [ -z "$LATEST_IMAGES" ]; then
  check "WARNUNG" "Alle Images versioniert (kein :latest)" "PASS" ""
else
  check "WARNUNG" "Alle Images versioniert" "FAIL" "latest gefunden"
fi

# RLS auf allen public-Tabellen
UNPROTECTED=$(ssh deploy@${PROD_HOST} "cd /opt/supabase && docker compose exec -T postgres psql -U postgres -t -c \
  \"SELECT count(*) FROM pg_tables WHERE schemaname = 'public' AND rowsecurity = false;\"" 2>/dev/null | tr -d ' ' || echo "?")
if [ "$UNPROTECTED" = "0" ]; then
  check "KRITISCH" "RLS auf allen public-Tabellen aktiv" "PASS" ""
elif [ "$UNPROTECTED" != "?" ]; then
  check "KRITISCH" "RLS auf allen public-Tabellen aktiv" "FAIL" "${UNPROTECTED} Tabellen ohne RLS"
fi

# Postgres nur intern
PG_LISTEN=$(ssh deploy@${PROD_HOST} "ss -tlnp | grep 5432" 2>/dev/null || true)
if echo "$PG_LISTEN" | grep -q "0.0.0.0:5432"; then
  check "KRITISCH" "Postgres nur auf internem Interface" "FAIL" "Lauscht auf 0.0.0.0"
else
  check "KRITISCH" "Postgres nur auf internem Interface" "PASS" ""
fi

# Studio nicht extern erreichbar
STUDIO=$(curl -s -o /dev/null -w "%{http_code}" --connect-timeout 3 "https://${EXTERNAL_HOST}:9000" 2>/dev/null || echo "000")
if [ "$STUDIO" = "000" ]; then
  check "KRITISCH" "Supabase Studio nicht extern erreichbar" "PASS" ""
else
  check "KRITISCH" "Supabase Studio nicht extern erreichbar" "FAIL" "Status: $STUDIO"
fi

# -------------------------------------------
# NEXT.JS
# -------------------------------------------
REPORT+="\n## Next.js\n\n"

# service_role im Client Code
SR_LEAK=$(ssh deploy@${PROD_HOST} "cd /opt/app && grep -rn 'SERVICE_ROLE\|service_role' app/ \
  --include='*.ts' --include='*.tsx' 2>/dev/null | grep -v 'lib/supabase/admin.ts' | grep -v node_modules" 2>/dev/null || true)
if [ -z "$SR_LEAK" ]; then
  check "KRITISCH" "service_role nicht im Client Code" "PASS" ""
else
  check "KRITISCH" "service_role nicht im Client Code" "FAIL" "Gefunden in: $(echo "$SR_LEAK" | head -3)"
fi

# NEXT_PUBLIC mit Secrets
PUB_SECRET=$(ssh deploy@${PROD_HOST} "cd /opt/app && grep 'NEXT_PUBLIC_' .env* 2>/dev/null | \
  grep -iE 'service_role|secret|private|database'" 2>/dev/null || true)
if [ -z "$PUB_SECRET" ]; then
  check "KRITISCH" "Keine Secrets in NEXT_PUBLIC Variablen" "PASS" ""
else
  check "KRITISCH" "Keine Secrets in NEXT_PUBLIC Variablen" "FAIL" "$PUB_SECRET"
fi

# middleware.ts existiert und nutzt getUser
MW_EXISTS=$(ssh deploy@${PROD_HOST} "test -f /opt/app/middleware.ts && echo yes || echo no" 2>/dev/null || echo "no")
if [ "$MW_EXISTS" = "yes" ]; then
  MW_GETUSER=$(ssh deploy@${PROD_HOST} "grep -c 'getUser' /opt/app/middleware.ts" 2>/dev/null || echo "0")
  if [ "$MW_GETUSER" -gt 0 ]; then
    check "KRITISCH" "middleware.ts existiert mit getUser()" "PASS" ""
  else
    check "KRITISCH" "middleware.ts mit getUser()" "FAIL" "getUser() fehlt"
  fi
else
  check "KRITISCH" "middleware.ts existiert" "FAIL" "Datei fehlt"
fi

# Server Actions ohne Auth
SA_NO_AUTH=$(ssh deploy@${PROD_HOST} "cd /opt/app && for file in \$(grep -rl \"'use server'\" app/ --include='*.ts' 2>/dev/null); do
  if ! grep -q 'getUser' \"\$file\"; then echo \"\$file\"; fi
done" 2>/dev/null || true)
if [ -z "$SA_NO_AUTH" ]; then
  check "WARNUNG" "Alle Server Actions haben Auth Check" "PASS" ""
else
  check "WARNUNG" "Server Actions ohne Auth" "FAIL" "$SA_NO_AUTH"
fi

# npm audit
NPM_HIGH=$(ssh deploy@${PROD_HOST} "cd /opt/app && npm audit --audit-level=high 2>&1 | \
  grep -c 'high\|critical'" 2>/dev/null || echo "0")
if [ "$NPM_HIGH" = "0" ]; then
  check "WARNUNG" "npm audit: keine high/critical" "PASS" ""
else
  check "WARNUNG" "npm audit" "FAIL" "${NPM_HIGH} high/critical Findings"
fi

# -------------------------------------------
# EDGE FUNCTIONS
# -------------------------------------------
REPORT+="\n## Edge Functions\n\n"

# Webhook Functions ohne Signaturprüfung
WH_NO_SIG=$(ssh deploy@${PROD_HOST} "for dir in /opt/supabase/volumes/functions/*-webhook/; do
  [ -d \"\$dir\" ] || continue
  name=\$(basename \"\$dir\")
  if ! grep -qE 'signature|verify|hmac|crypto' \"\$dir/index.ts\" 2>/dev/null; then
    echo \"\$name\"
  fi
done" 2>/dev/null || true)
if [ -z "$WH_NO_SIG" ]; then
  check "KRITISCH" "Alle Webhooks prüfen Signaturen" "PASS" ""
else
  check "KRITISCH" "Webhooks ohne Signaturprüfung" "FAIL" "$WH_NO_SIG"
fi

# Hardcoded Secrets
FN_SECRETS=$(ssh deploy@${PROD_HOST} "grep -rn 'sk_live\|sk_test\|whsec_\|Bearer ey' \
  /opt/supabase/volumes/functions/ --include='*.ts' 2>/dev/null" || true)
if [ -z "$FN_SECRETS" ]; then
  check "KRITISCH" "Keine hardcoded Secrets in Functions" "PASS" ""
else
  check "KRITISCH" "Hardcoded Secrets in Functions" "FAIL" "$FN_SECRETS"
fi

# -------------------------------------------
# TRIGGER.DEV
# -------------------------------------------
REPORT+="\n## Trigger.dev\n\n"

# Tasks ohne maxDuration
TD_NO_DUR=$(ssh deploy@${PROD_HOST} "cd /opt/app && for file in trigger/tasks/*.ts 2>/dev/null; do
  [ -f \"\$file\" ] || continue
  name=\$(basename \"\$file\" .ts)
  if ! grep -q 'maxDuration' \"\$file\"; then echo \"\$name\"; fi
done" 2>/dev/null || true)
if [ -z "$TD_NO_DUR" ]; then
  check "WARNUNG" "Alle Tasks haben maxDuration" "PASS" ""
else
  check "WARNUNG" "Tasks ohne maxDuration" "FAIL" "$TD_NO_DUR"
fi

# Tasks ohne Concurrency
TD_NO_CC=$(ssh deploy@${PROD_HOST} "cd /opt/app && for file in trigger/tasks/*.ts 2>/dev/null; do
  [ -f \"\$file\" ] || continue
  name=\$(basename \"\$file\" .ts)
  if ! grep -qE 'concurrencyLimit|queue:' \"\$file\"; then echo \"\$name\"; fi
done" 2>/dev/null || true)
if [ -z "$TD_NO_CC" ]; then
  check "WARNUNG" "Alle Tasks haben Concurrency Limit" "PASS" ""
else
  check "WARNUNG" "Tasks ohne Concurrency" "FAIL" "$TD_NO_CC"
fi

# Hardcoded Secrets in Tasks
TD_SECRETS=$(ssh deploy@${PROD_HOST} "grep -rn 'sk_live\|sk_test\|SG\.\|sk-' \
  /opt/app/trigger/ --include='*.ts' 2>/dev/null" || true)
if [ -z "$TD_SECRETS" ]; then
  check "KRITISCH" "Keine hardcoded Secrets in Tasks" "PASS" ""
else
  check "KRITISCH" "Hardcoded Secrets in Tasks" "FAIL" "$TD_SECRETS"
fi

# Trigger.dev Dashboard nicht extern
TD_DASH=$(curl -s -o /dev/null -w "%{http_code}" --connect-timeout 3 "https://${EXTERNAL_HOST}:3040" 2>/dev/null || echo "000")
if [ "$TD_DASH" = "000" ]; then
  check "KRITISCH" "Trigger.dev Dashboard nicht extern" "PASS" ""
else
  check "KRITISCH" "Trigger.dev Dashboard nicht extern" "FAIL" "Status: $TD_DASH"
fi

# -------------------------------------------
# COMPLIANCE
# -------------------------------------------
REPORT+="\n## Compliance\n\n"

# Git: keine Secrets im Repo
GIT_SECRETS=$(ssh deploy@${PROD_HOST} "cd /opt/app && git ls-files .env .env.functions .env.trigger 2>/dev/null" || true)
if [ -z "$GIT_SECRETS" ]; then
  check "KRITISCH" ".env Dateien nicht im Git" "PASS" ""
else
  check "KRITISCH" ".env Dateien im Git" "FAIL" "Committed: $GIT_SECRETS"
fi

# Git: keine uncommitted Changes auf dem Server
GIT_DIRTY=$(ssh deploy@${PROD_HOST} "cd /opt/app && git status --porcelain 2>/dev/null" || true)
if [ -z "$GIT_DIRTY" ]; then
  check "WARNUNG" "Keine manuellen Änderungen auf Server" "PASS" ""
else
  check "WARNUNG" "Manuelle Änderungen auf Server" "FAIL" "$(echo "$GIT_DIRTY" | wc -l) Dateien"
fi

# -------------------------------------------
# ZUSAMMENFASSUNG
# -------------------------------------------

SUMMARY="\n## Zusammenfassung\n\n"
SUMMARY+="Bestanden: ${PASS}\n"
SUMMARY+="Warnungen: ${WARNING}\n"
SUMMARY+="Kritisch:  ${CRITICAL}\n"

TOTAL_REPORT="${SUMMARY}\n${REPORT}"

# Report speichern
REPORT_FILE="/opt/audit/reports/baseline-$(date +%Y-%m-%d).md"
echo -e "# Security Baseline Check $(date +%Y-%m-%d)\n${TOTAL_REPORT}" > "$REPORT_FILE"

echo -e "$TOTAL_REPORT"

# Alert bei kritischen Findings
if [ "$CRITICAL" -gt 0 ]; then
  echo ""
  echo "!!! ${CRITICAL} KRITISCHE FINDINGS !!!"
  echo -e "$TOTAL_REPORT" | mail -s "KRITISCH: Baseline Check $(date)" ops@example.com
  exit 1
fi

exit 0
```

## Integración con Claude Code (artículo 5)

El script de verificación de la Baseline proporciona hechos. Claude Code los interpreta. La auditoría semanal del [artículo 5](/es/revista/claude-code-security-devops/) utiliza el informe de la Baseline como input:

```bash
# Im Gesamt-Audit-Script (scripts/full-security-audit.sh aus Artikel 5)
# Nach den deterministischen Checks:

# Baseline-Report des heutigen Tages einlesen
BASELINE_REPORT=$(cat /opt/audit/reports/baseline-$(date +%Y-%m-%d).md 2>/dev/null || echo "Kein Baseline-Report vorhanden")

# An Claude Code übergeben
echo "$BASELINE_REPORT" | claude -p \
  "Du erhältst den Baseline-Check-Report unseres self-hosted Stacks.
Die Baseline ist definiert in security-baseline.yml.

Analysiere:
1. Welche KRITISCHEN Findings brauchen sofortige Aufmerksamkeit?
2. Gibt es Muster in den WARNUNGEN die auf systematische Probleme hindeuten?
3. Haben sich Findings gegenüber der Vorwoche verändert? (Vergleiche mit letztem Report)
4. Welche Prioritäten empfiehlst du für diese Woche?

Antworte auf Deutsch. Sei konkret." \
  --allowedTools "Read,Grep,Glob" \
  --output-format text \
  --max-turns 5
```

## Mantenimiento de la Baseline

El `security-baseline.yml` no es un documento estático. Evoluciona con el stack.

**Cuándo actualizar:**

```
Neue Tabelle in Supabase           -> rls.exceptions prüfen
Neuer Service im Docker Stack      -> internal_only_ports erweitern
Neues NEXT_PUBLIC Env Var          -> allowed_public erweitern
Neues Secret                       -> required Secrets erweitern
Neue Edge Function                 -> Prüfregeln gelten automatisch
Neuer Trigger.dev Task             -> Prüfregeln gelten automatisch
Hoster-Wechsel                     -> server/provider anpassen
```

**Workflow para cambios en la Baseline:**

```
1. Änderung in security-baseline.yml im Git
2. PR Review (inkl. Begründung warum die Regel sich ändert)
3. Claude Code prüft den Diff der Baseline selbst:
   "Ist diese Lockerung der Regeln gerechtfertigt?"
4. Merge nach Approval
5. Nächster Baseline-Check nutzt die neuen Regeln
```

## Configuración de cron

```bash
# crontab auf dem audit-runner

# Täglicher Baseline-Check (06:00 Uhr)
0 6 * * * /opt/audit/scripts/check-baseline.sh >> /var/log/baseline-check.log 2>&1

# Wöchentlicher Claude Code Audit (Sonntag 07:00 Uhr, nach dem Baseline-Check)
0 7 * * 0 /opt/audit/scripts/full-security-audit.sh >> /var/log/security-audit.log 2>&1
```

## Checklist de deployment

```
Baseline-Datei
  [ ] security-baseline.yml im Repo vorhanden
  [ ] Alle Server-IPs und Hostnames aktuell
  [ ] Alle erwarteten Secrets gelistet (ohne Werte)
  [ ] Alle erlaubten NEXT_PUBLIC Variablen gelistet
  [ ] Alle service_role-erlaubten Dateien gelistet
  [ ] RLS Exceptions dokumentiert (mit Begründung)
  [ ] Compliance-Regeln (CLOUD Act, Data Residency) definiert

Check-Script
  [ ] check-baseline.sh auf audit-runner ausführbar
  [ ] SSH Key vom audit-runner zum prod-Server eingerichtet
  [ ] Firewall-Baseline gespeichert (/opt/baselines/)
  [ ] Täglicher Cron Job aktiv
  [ ] Alert-Versand konfiguriert (E-Mail bei KRITISCH)

Integration
  [ ] Claude Code auf audit-runner installiert
  [ ] Wöchentlicher Audit-Cron aktiv
  [ ] CLAUDE.md im Repo vorhanden (Artikel 5)
  [ ] .claude/commands/security-review.md vorhanden (Artikel 5)
  [ ] Reports werden archiviert (/opt/audit/reports/)
```

## Conclusión

La Security Baseline es el elemento conector de toda la serie de runbooks. Los artículos 1 a 4 definen lo que debe estar configurado de forma segura. El artículo 5 define cómo Claude Code verifica esas reglas. El artículo 6 reúne todo en un único archivo YAML que puede ser leído tanto por scripts como por Claude Code.

La verificación diaria de la Baseline proporciona hechos: superado o no superado. La auditoría semanal de Claude Code interpreta esos hechos en contexto. Una persona decide qué se prioriza. Este modelo de tres capas cubre tanto riesgos conocidos como inesperados, sin que ninguna capa individual sea la única responsable de la seguridad.

> **Estadística:** Las organizaciones que utilizan verificaciones de baseline automatizadas detectan la deriva de configuración una media de 11 veces más rápido que las que dependen de auditorías manuales (informe Puppet State of DevOps 2024).


Quien siga esta Baseline junto con una [arquitectura Cert-Ready-by-Design](/es/revista/cert-ready-by-design/) construye seguridad verificable en lugar de auditorías a posteriori.

Con esto, la **serie de runbooks DevOps queda completa**.

<div class="not-prose my-12 border border-gosign-border bg-gosign-light rounded-card p-6 lg:p-8">
<div class="flex items-start gap-4">
<div class="flex-shrink-0 w-12 h-12 bg-gosign-dark rounded-card flex items-center justify-center">
<svg width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="white" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 15v4a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2v-4"/><polyline points="7 10 12 15 17 10"/><line x1="12" y1="15" x2="12" y2="3"/></svg>
</div>
<div>
<h2 class="text-h3 font-bold text-gosign-dark mb-2" id="listas-de-verificacion-de-la-serie">Listas de verificación de la serie</h2>
<p class="text-body text-gosign-text mb-4">Prompts preparados para Claude Code. Cada lista de verificación comprueba automáticamente los puntos de seguridad del runbook correspondiente e informa APROBADO, ADVERTENCIA o CRÍTICO.</p>
<div class="flex flex-wrap gap-3">
<a href="/downloads/claude-check-artikel-1-supabase-es.md" download class="inline-flex items-center px-4 py-2 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-sm">Supabase Infrastructure</a>
<a href="/downloads/claude-check-artikel-2-nextjs-es.md" download class="inline-flex items-center px-4 py-2 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-sm">Next.js Security</a>
<a href="/downloads/claude-check-artikel-3-edge-functions-es.md" download class="inline-flex items-center px-4 py-2 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-sm">Edge Functions</a>
<a href="/downloads/claude-check-artikel-4-trigger-dev-es.md" download class="inline-flex items-center px-4 py-2 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-sm">Trigger.dev</a>
</div>
</div>
</div>
</div>

## Índice de la serie

1. [Supabase Self-Hosting Runbook](/es/revista/supabase-self-hosting/)
2. [Next.js sobre Supabase de forma segura](/es/revista/nextjs-supabase-configuracion-segura/)
3. [Supabase Edge Functions de forma segura](/es/revista/supabase-edge-functions-seguridad/)
4. [Trigger.dev Background Jobs en producción segura](/es/revista/trigger-dev-background-jobs/)
5. [Claude Code como control de seguridad en el workflow DevOps](/es/revista/claude-code-security-devops/)
6. [Security Baseline para el stack completo](/es/revista/security-baseline-stack/) - este artículo

--- Seguridad de datos en IA: Data Residency, RGPD y EU AI Act ---
> ¿Cómo garantizar la seguridad de datos en IA empresarial? Data Residency, procesamiento solo en la UE, Row-Level Security, aislamiento de mandantes.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">De un vistazo - Seguridad de datos en IA corporativa</p>
<ul class="text-body text-gosign-text space-y-2">
<li>La primera pregunta para todo CISO y DPD: donde se procesan los datos, quien tiene acceso, cuanto tiempo se almacenan. Con herramientas de IA publicas, la respuesta es inaceptable para empresas reguladas.</li>
<li>Tres modelos de despliegue: self-hosted (ningun dato sale de la red), nube solo UE (procesamiento en centros de datos de la UE) o hibrido (datos sensibles self-hosted, no criticos via nube).</li>
<li>IBM Cost of a Data Breach Report (2024) revela que el coste medio de una brecha de datos alcanzo los 4,88 millones USD - el mas alto jamas registrado.</li>
<li>El aislamiento de mandantes mediante Row-Level Security, separacion de workspaces y aislamiento de prompts es critico para despachos de auditoria, asesoria fiscal y centros de servicios compartidos.</li>
<li>La seguridad de datos en IA corporativa es una decision de arquitectura, no de politica - la infraestructura correcta hace el cumplimiento verificable en lugar de declarativo.</li>
</ul>
</div>

## La pregunta central: ¿Dónde están los datos?

Cuando un agente de IA lee una factura, procesa una baja médica o responde una consulta de cumplimiento normativo, está procesando datos empresariales. Datos de facturación, datos de personal, secretos comerciales. La primera pregunta de todo CISO y Delegado de Protección de Datos (DPD): ¿dónde se procesan estos datos? ¿Quién tiene acceso? ¿Durante cuánto tiempo se almacenan?

Al usar ChatGPT, Gemini o CoPilot, la respuesta es: los datos se transmiten a servidores externos, son procesados por un tercero y pueden utilizarse con fines de entrenamiento. Para empresas reguladas, esta no es una respuesta aceptable.

## Tres modelos de despliegue

La [arquitectura de Gosign](/es/governance/) soporta tres modelos de despliegue. La elección depende del nivel de protección requerido para los datos.

**Self-Hosted:** Todos los componentes (modelos, agentes, bases de datos) se ejecutan en la infraestructura del cliente. Ningún dato sale de la red corporativa. Esto incluye los modelos de lenguaje: modelos open source como [Llama](https://llama.meta.com/), [Mistral](https://mistral.ai/), [DeepSeek](https://www.deepseek.com/) o gpt-oss pueden ejecutarse localmente.

**Nube (solo UE):** Procesamiento en centros de datos de la UE en Azure, GCP o AWS. Data Processing Agreement, Standard Contractual Clauses. Los modelos son modelos en la nube (Claude, ChatGPT, Gemini), pero el procesamiento permanece en la UE.

**Híbrido:** Los datos sensibles (datos de personal, datos financieros) se procesan en self-hosted. Los datos no críticos pueden procesarse mediante modelos en la nube. El enrutamiento entre self-hosted y nube es basado en reglas y automático.

## Data Residency en detalle

Data Residency va más allá de la ubicación de los servidores. Comprende:

**Lugar de procesamiento:** ¿Dónde se ejecuta el modelo de lenguaje? En self-hosted: en el centro de datos propio. En nube: en un centro de datos de la UE definido.

**Lugar de almacenamiento:** ¿Dónde se almacenan los datos procesados? Audit Trails, conjuntos de datos de decisiones, documentos. Todo en la misma región que el procesamiento.

**Ruta de tránsito:** ¿Cómo llegan los datos al modelo y vuelven? En self-hosted: red interna. En nube: conexión cifrada al centro de datos de la UE. Sin tránsito por terceros países.

**Copias de seguridad:** ¿Dónde se almacenan las copias de seguridad? Las copias de seguridad deben cumplir los mismos requisitos de Data Residency que los datos primarios.

## Aislamiento de mandantes

Para despachos de auditoría y asesoría fiscal, así como para centros de servicios compartidos, el aislamiento de mandantes es crítico para el negocio. Los datos de un mandante no deben ser visibles para otros mandantes, tampoco para el sistema de IA.

El aislamiento se implementa en múltiples capas:

**Separación de workspaces:** Cada mandante tiene su propio workspace con claves API separadas, almacenamiento de documentos separado y configuraciones de modelos separadas.

**Row-Level Security:** A nivel de base de datos, Row-Level Security garantiza que las consultas solo devuelvan datos del mandante actual. Incluso si un agente ejecuta accidentalmente una consulta entre mandantes, la base de datos solo devuelve resultados del mandante autorizado.

**Aislamiento de prompts:** Los prompts y las reglas son específicos de cada mandante. El agente de un mandante no tiene acceso a los prompts ni a las reglas de otros mandantes.

## Conformidad con el RGPD

El RGPD establece requisitos para el tratamiento de datos personales. En el contexto de IA:

**Base jurídica:** El tratamiento de datos personales por agentes de IA requiere una base jurídica. En el contexto laboral, típicamente: ejecución de un contrato (art. 6.1.b RGPD) o interés legítimo (art. 6.1.f RGPD). La AEPD ha sido especialmente activa en la aplicación de estos principios a sistemas de IA.

**Minimización de datos:** El agente procesa únicamente los datos necesarios para el fin concreto. Sin almacenamiento permanente de documentos en el modelo. Sin uso de datos de clientes para fines de entrenamiento.

**Derecho de acceso:** Los interesados pueden solicitar información sobre los datos procesados. El Audit Trail documenta cada tratamiento de datos personales.

**Supresión:** Los datos se eliminan una vez transcurrido el plazo de conservación. La supresión incluye también el Audit Trail tras el vencimiento de los plazos legales de conservación.

## Checklist de seguridad de datos por modelo de despliegue

| Requisito de seguridad | Self-Hosted | Nube solo UE | Hibrido |
|---|---|---|---|
| Los datos salen de la red corporativa | No | Si (a centro de datos UE) | Sensibles: No / No criticos: Si |
| Entrenamiento del modelo con datos corporativos | No posible | Excluido via DPA | Excluido via DPA |
| Mecanismo de conformidad RGPD | Control total by design | DPA + SCCs + zonas de procesamiento UE | Routing por clase de datos |
| Aislamiento de mandantes | Workspace + RLS + aislamiento de prompts | Workspace + RLS + aislamiento de prompts | Workspace + RLS + aislamiento de prompts |
| Ubicacion del Audit Trail | On-Premises | Centro de datos UE | Dividido: on-prem + nube UE |
| Residency de copias de seguridad | Igual que datos primarios | Misma region UE | Segun clasificacion de datos |
| Latencia | Minima (red local) | Latencia de red UE | Variable segun clase de datos |

Más información: [Data Residency](/es/governance/data-residency/)

<a href="/es/contacto/" target="_blank" rel="noopener noreferrer">Agendar una reunión</a> - Le mostramos las opciones de Data Residency adaptadas a sus necesidades.

--- Serie DevOps Runbook: seguridad para el stack self-hosted ---
> Serie de seis DevOps Runbooks: Supabase, Next.js, Edge Functions, Trigger.dev, auditorias Claude Code y Security Baseline.

Esta serie proporciona seis runbooks prácticos para operar un stack de aplicaciones self-hosted de forma segura. Está dirigida a equipos DevOps que operan Supabase, Next.js y tecnologías relacionadas en producción y quieren asegurar su infraestructura de manera sistemática.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">De un vistazo - Serie DevOps Runbook</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Seis runbooks cubren el stack self-hosted completo: Supabase, Next.js, Edge Functions, Trigger.dev, auditorías Claude Code y Security Baseline.</li>
<li>Cada artículo contiene implementaciones concretas con código real, condiciones verificables y checklists de Claude Code descargables.</li>
<li>La serie se construye capa por capa - desde el fundamento de la plataforma (Supabase) hasta una baseline YAML legible por máquina para todo el stack.</li>
<li>Público objetivo: ingenieros DevOps, CTOs, ingenieros de seguridad y desarrolladores que construyen sobre Supabase y Next.js.</li>
<li>Según el SANS Institute (2024), las organizaciones con una Security Baseline legible por máquina detectan la deriva de configuración 14 veces más rápido.</li>
</ul>
</div>

## Por qué importa un enfoque sistemático

El self-hosting da control sobre datos e infraestructura. Ese control conlleva responsabilidad: cada componente tiene sus propios requisitos de seguridad, y las dependencias entre capas permanecen invisibles cuando se revisan de forma aislada.

Un enfoque de seguridad sistemático y legible por máquina en todas las capas marca la diferencia. Según el SANS Institute (2024), las organizaciones con una Security Baseline legible por máquina detectan la deriva de configuración en promedio **14 veces más rápido** que los equipos sin baseline.

Esta serie recorre el stack capa por capa y concluye con una baseline basada en YAML que consolida todas las reglas de los runbooks individuales.

## Panorama de la serie

| Parte | Artículo | Área de enfoque | Entregable clave |
|-------|----------|-----------------|------------------|
| 1 | [Supabase Self-Hosting Runbook](/es/revista/supabase-self-hosting/) | Fundamento de plataforma | Arquitectura de servidores, Docker Compose, RLS |
| 2 | [Next.js sobre Supabase de forma segura](/es/revista/nextjs-supabase-configuracion-segura/) | Capa de aplicación | Auth, Middleware, separación de entornos |
| 3 | [Supabase Edge Functions de forma segura](/es/revista/supabase-edge-functions-seguridad/) | Integraciones | Webhooks, firmas, CORS |
| 4 | [Trigger.dev Background Jobs en producción segura](/es/revista/trigger-dev-background-jobs/) | Procesamiento async | Tasks, idempotencia, concurrencia |
| 5 | [Claude Code como control de seguridad en el workflow DevOps](/es/revista/claude-code-security-devops/) | Auditorías automatizadas | Custom commands, modo headless |
| 6 | [Security Baseline para todo el stack](/es/revista/security-baseline-stack/) | Baseline del stack completo | YAML, verificaciones automatizadas |

## Los artículos en detalle

**Parte 1 - Supabase Self-Hosting Runbook.** Describe una arquitectura de dos servidores (producción y auditoría), Docker Compose con imágenes versionadas, configuración de siete servicios y Row Level Security como requisito en todas las tablas públicas.

**Parte 2 - Next.js sobre Supabase.** Cubre la capa de aplicación sobre Supabase: flujo de auth con PKCE, middleware para protección de rutas, separación estricta de entornos entre servidor y cliente y patrones seguros de API route.

**Parte 3 - Edge Functions.** Se enfoca en el procesamiento de webhooks con verificación de firmas, configuración CORS, validación de entrada en el runtime Deno y gestión segura de secrets para integraciones con terceros.

**Parte 4 - Trigger.dev Background Jobs.** Describe el setup self-hosted de Trigger.dev v3, definición idempotente de tasks, control de concurrencia, estrategias de reintentos e aislamiento de secrets entre tasks.

**Parte 5 - Claude Code como control de seguridad.** Muestra cómo usar Claude Code como herramienta automatizada de auditoría en el workflow DevOps: custom commands, ejecuciones de auditoría headless e integración con CI.

**Parte 6 - Security Baseline.** Consolida todas las reglas de los artículos 1 a 5 en un archivo legible por máquina `security-baseline.yml`. Incluye scripts de verificación determinísticos e integración con la auditoría de Claude Code.

## Para quién es esta serie

- Ingenieros DevOps que operan infraestructura self-hosted
- CTOs y líderes técnicos evaluando self-hosting vs. servicios gestionados
- Ingenieros de seguridad auditando stacks de aplicaciones
- Desarrolladores que construyen sobre Supabase y Next.js

## Cómo usar esta serie

- Lea los artículos en orden del 1 al 6, ya que se construyen unos sobre otros
- Descargue las checklists de Claude Code al final de cada artículo
- Implemente las recomendaciones capa por capa en su entorno
- Use la Security Baseline del artículo 6 como puerta de monitoreo diaria

--- Shadow AI en la empresa: gobernanza en vez de prohibición ---
> El uso no controlado de IA (Shadow AI) es un problema de gobernanza. La solución es infraestructura controlada con Audit Trail y Model Routing.

## Qué es Shadow AI?

Shadow AI es el equivalente en IA del Shadow IT. Los empleados utilizan ChatGPT, Google Gemini, Microsoft CoPilot u otras herramientas de IA para su trabajo, sin conocimiento, aprobación ni control del departamento de TI.

El gestor que introduce una reclamación de cliente en ChatGPT para redactar una respuesta. La responsable de RRHH que redacta un informe de evaluación con CoPilot. El controller que analiza cifras trimestrales en Gemini. Cada uno de estos usos envía datos corporativos a un servicio externo.

Shadow AI no es malintencionado. Los empleados utilizan herramientas de IA porque son más productivos. Pero sin gobernanza, la organización no tiene control sobre qué datos abandonan la empresa, qué modelos se utilizan y si los resultados son trazables.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">De un vistazo - Shadow AI Governance</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Shadow AI significa que los empleados usan herramientas de IA externas sin conocimiento de IT, enviando datos corporativos a sistemas no controlados.</li>
<li>Las prohibiciones no funcionan - los empleados usan dispositivos personales y herramientas alternativas. La prohibición genera evasión no controlada.</li>
<li>PwC (2024) encontró que el 54% de las empresas tienen empleados usando herramientas de IA generativa sin aprobación formal de la organización.</li>
<li>La solución es infraestructura controlada: interfaz de IA corporativa, Model Routing, protocolo de uso y Audit Trail.</li>
<li>Tres fases: inventario del uso actual, despliegue de infraestructura controlada, luego agentes especializados para los casos de uso frecuentes.</li>
</ul>
</div>

## Por qué las prohibiciones no funcionan

La reacción obvia ante Shadow AI es la prohibición. Muchas empresas han bloqueado ChatGPT y herramientas similares, mediante reglas de firewall, políticas internas o acuerdos de empresa.

El problema: las prohibiciones no funcionan. Los empleados utilizan sus smartphones personales. Utilizan extensiones del navegador. Utilizan herramientas alternativas que aún no están en la lista de bloqueo. La prohibición no genera compliance, genera evasión no controlada.

Al mismo tiempo, la empresa pierde la ventaja de productividad que la IA puede ofrecer. Mientras los empleados ocultan su uso de IA, TI no puede ni apoyar, ni dirigir, ni optimizar.

En España, algunos acuerdos de empresa incluyen cláusulas restrictivas sobre el uso de herramientas de IA. Sin embargo, la experiencia demuestra que la restricción pura no es sostenible. El comité de empresa, conforme al art. 64 del Estatuto de los Trabajadores, debe ser informado y consultado sobre la implantación de nuevas tecnologías, lo que incluye tanto la restricción como la habilitación de herramientas de IA.

## La alternativa: infraestructura de IA controlada

La solución no es la prohibición, sino la infraestructura. Una infraestructura de IA propia da a los empleados herramientas de IA potentes, bajo el control de la organización.

**Interfaz de IA corporativa:** En lugar de ChatGPT, los empleados utilizan una interfaz de chat interna que accede a modelos corporativos. La experiencia de usuario es idéntica. La diferencia: todos los datos permanecen en la infraestructura propia.

**Model Routing:** TI decide qué modelos se utilizan para qué casos de uso. Los datos sensibles van a modelos self-hosted. Las solicitudes no críticas pueden enrutarse a modelos en la nube. La decisión es basada en reglas y trazable.

**Protocolo de uso:** Cada interacción con IA se registra, no para vigilar a los empleados, sino para dirigir el uso de IA. ¿Qué departamentos utilizan más la IA? ¿Para qué tareas? ¿Con qué modelos? Estos datos son la base para el siguiente paso: agentes especializados para los casos de uso más frecuentes.

**Audit Trail:** En áreas reguladas (finanzas, RRHH, compliance) cada decisión asistida por IA se documenta en el Audit Trail. El Decision Layer asegura que los procesos críticos de negocio no se basan en salidas de IA no controladas. Esto es esencial para cumplir los requisitos del RGPD, la LOPDGDD y el EU AI Act, supervisado en España por la AESIA (Agencia Española de Supervisión de Inteligencia Artificial).

## De Shadow AI a Governance by Design

Shadow AI es un síntoma. La causa raíz es la falta de infraestructura. Cuando los empleados no tienen herramientas de IA controladas, utilizan las no controladas.

| Fase | Enfoque | Entregables clave |
|------|---------|-------------------|
| 1 - Inventario | Mapear el uso actual de IA en todos los departamentos | Inventario de herramientas, análisis de flujos de datos, clasificación de riesgos |
| 2 - Infraestructura controlada | Plataforma IA corporativa con gobernanza | Hosting LLM, interfaz de chat, Model Routing, protocolo de uso |
| 3 - Agentes especializados | Agentes dedicados para casos de uso frecuentes | Document Agent, Knowledge Agent, Workflow Agent - cada uno con Decision Layer |

El camino de Shadow AI a Governance by Design:

**Fase 1: Inventario.** ¿Qué herramientas de IA se utilizan en la empresa? ¿Para qué tareas? ¿Con qué datos? Este inventario suele ser revelador: el uso real de IA supera significativamente al uso oficial.

**Fase 2: Infraestructura controlada.** Construcción de una infraestructura de IA corporativa. Hosting de LLMs, interfaz de chat, Model Routing, protocolo de uso. Los empleados reciben una herramienta al menos tan potente como ChatGPT, pero bajo el control de TI.

**Fase 3: Agentes especializados.** Los casos de uso más frecuentes se convierten en agentes especializados. En lugar de un chat genérico, hay un Document Agent para el procesamiento de documentos, un Knowledge Agent para consultas de RRHH, un Workflow Agent para el procesamiento de facturas. Cada agente con Decision Layer y gobernanza.

## El riesgo de la inacción

Shadow AI no va a desaparecer. Las herramientas de IA son cada vez mejores, más accesibles y están más integradas en el software existente. Cada actualización de Office trae nuevas funciones de IA. Cada navegador tiene capacidades de IA.

Las empresas que no construyan una infraestructura de IA controlada descubrirán que sus empleados llevan tiempo usando IA, sin gobernanza, sin Audit Trail, sin conformidad con el RGPD ni la LOPDGDD. La cuestión no es si se convierte en un problema, sino cuándo. En la próxima inspección de la Agencia Tributaria. En la próxima solicitud de la AEPD. En la próxima brecha de datos. En la próxima consulta del comité de empresa.

Más sobre este tema: [Infraestructura de IA](/es/servicios/infraestructura/)

Más sobre gobernanza: [Gobernanza de IA](/es/governance/)

<a href="/es/contacto/" target="_blank" rel="noopener noreferrer">Agendar reunión</a>. Le mostramos cómo transformar Shadow AI en infraestructura de IA controlada.

--- Supabase Edge Functions de forma segura ---
> Runbook DevOps para Supabase Edge Functions: webhooks, firmas, CORS, Deno runtime, validación de entrada e integración con Claude Code.

> **Estadística:** Según datos de Stripe, más del 12% de las integraciones de webhooks no verifican firmas, lo que las hace vulnerables a eventos falsificados.


Las Supabase Edge Functions son funciones TypeScript del lado del servidor que se ejecutan en el runtime de Deno y son accesibles a través del Kong API Gateway.

Son especialmente adecuadas para webhooks, integraciones con APIs externas, endpoints de eventos firmados y lógica ligera del lado del servidor.

El error más frecuente es utilizar las Edge Functions como un **segundo sistema backend**. Esto genera lógica de negocio duplicada, límites de seguridad difusos y arquitecturas difíciles de depurar.

Este runbook describe cómo utilizar las Edge Functions de forma segura en un [setup self-hosted](/es/revista/supabase-self-hosting/). Cada paso contiene una implementación concreta con código Deno real, una condición verificable y un escenario de fallo.

> **Nota sobre el runtime:** Las Supabase Edge Functions se basan en **Deno**, no en Node.js. Esto afecta a la sintaxis de importación, el sistema de módulos y las APIs disponibles. Todos los ejemplos de código en este artículo son compatibles con Deno. Las Edge Functions self-hosted se ejecutan en el contenedor `supabase/edge-runtime` y actualmente están marcadas como Beta.


<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">De un vistazo - Artículo 3 de 6 de la serie DevOps Runbook</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Edge Functions solo como puntos de integración (webhooks), no segundo backend</li>
<li>Verificación obligatoria de firmas de webhooks</li>
<li>CORS configurado explícitamente (sin wildcard)</li>
<li>Validación de entrada con Zod</li>
<li>Tareas de larga duración delegadas a Trigger.dev</li>
</ul>
</div>

## Índice de la serie

Esta guía forma parte de nuestra serie de runbooks DevOps para app stacks self-hosted.

1. [Supabase Self-Hosting Runbook](/es/revista/supabase-self-hosting/)
2. [Next.js sobre Supabase de forma segura](/es/revista/nextjs-supabase-configuracion-segura/)
3. [Supabase Edge Functions de forma segura](/es/revista/supabase-edge-functions-seguridad/) - este artículo
4. [Trigger.dev Background Jobs en producción segura](/es/revista/trigger-dev-background-jobs/)
5. [Claude Code como control de seguridad en el workflow DevOps](/es/revista/claude-code-security-devops/)
6. [Security Baseline para todo el stack](/es/revista/security-baseline-stack/)

El artículo 1 describe la plataforma.
El artículo 2 describe la capa de aplicación Next.js.
Este artículo describe **integraciones y webhooks**.

## Visión general de la arquitectura

```
Browser
   |
Next.js (capa de aplicación)
   |
   +-- Supabase Client (anon key)     -> para solicitudes de usuario
   |
Kong API Gateway
   |
   +-- PostgREST                       -> REST API con RLS
   +-- GoTrue                          -> Auth
   +-- Edge Runtime                    -> Edge Functions
   |     |
   |     +-- stripe-webhook
   |     +-- github-webhook
   |     +-- trigger-webhook
   |
PostgreSQL + RLS Policies

Servicios externos
   |
   +-- Stripe / GitHub / Trigger.dev   -> invocan webhooks
```

Regla fundamental:

```
Las Edge Functions son puntos de integración para eventos externos.
La lógica de negocio pertenece a [Next.js](/es/revista/nextjs-supabase-configuracion-segura/) (Server Actions / Route Handler).
Los procesos de larga duración pertenecen a [Trigger.dev](/es/revista/trigger-dev-background-jobs/).
```


### Tabla de decisión

| Criterio | Edge Function | Server Action | Trigger.dev Task |
|---|---|---|---|
| Origen | Evento externo (webhook) | Entrada del usuario | Tarea interna |
| Tiempo de ejecución | < 30 segundos | < 10 segundos | Hasta 5 minutos+ |
| Autenticación | Firma HMAC | Sesión de usuario (JWT) | Clave API / service_role |
| RLS | Omitido (service_role) | Activo (anon key) | Omitido (service_role) |
| Retry | Proveedor del webhook | Ninguno (síncrono) | Integrado (Trigger.dev) |
| Ejemplo | Stripe checkout webhook | Formulario de perfil | Generación de PDF |

### Criterio de decisión

Si una función reacciona a un **evento externo** (Stripe Payment, GitHub Push, Trigger.dev Callback), es una Edge Function. Si reacciona a **input de usuario** y transforma datos, pertenece a Next.js. Si se ejecuta durante **más de 30 segundos**, pertenece a Trigger.dev.

## Cómo funcionan las Edge Functions en el setup self-hosted

En el stack Docker Compose self-hosted, la configuración de Edge Functions tiene este aspecto:

```yaml
# docker-compose.yml (extracto)
functions:
  container_name: supabase-edge-functions
  image: supabase/edge-runtime:v1.66.4    # fijar versión
  restart: unless-stopped
  depends_on:
    - analytics
  environment:
    JWT_SECRET: ${JWT_SECRET}
    SUPABASE_URL: http://kong:8000                    # hostname interno de Docker
    SUPABASE_ANON_KEY: ${ANON_KEY}
    SUPABASE_SERVICE_ROLE_KEY: ${SERVICE_ROLE_KEY}
    SUPABASE_DB_URL: postgresql://postgres:${POSTGRES_PASSWORD}@${POSTGRES_HOST}:${POSTGRES_PORT}/${POSTGRES_DB}
    VERIFY_JWT: "${FUNCTIONS_VERIFY_JWT}"
  volumes:
    - ./volumes/functions:/home/deno/functions:Z
  command:
    - start
    - --main-service
    - /home/deno/functions/main
```

Las Edge Functions se encuentran como archivos TypeScript en el volumen:

```
volumes/functions/
  main/
    index.ts              <- Router / Main Service
  _shared/
    cors.ts               <- CORS Headers (compartido)
    supabase-client.ts    <- Supabase Client Factory (compartido)
  stripe-webhook/
    index.ts
  github-webhook/
    index.ts
```

**Despliegue en el setup self-hosted:** Las funciones se colocan como archivos en el volumen y se reinicia el contenedor:

```bash
# Copiar funciones al volumen
cp -r supabase/functions/* /opt/supabase/volumes/functions/

# Reiniciar el contenedor
docker compose restart functions --no-deps
```

## Parte A - Decisiones de arquitectura

Estas decisiones se toman una vez y rara vez se modifican.

## A1 - Edge Functions solo para integraciones, no como segundo backend

### Implementación

Asignación clara de qué lógica pertenece a cada componente:

```
Edge Functions (Deno):
  Recepción de webhooks (Stripe, GitHub, APIs externas)
  Sincronización basada en eventos (DB Webhook -> servicio externo)
  Verificación de firmas de eventos entrantes
  Transformaciones ligeras (< 30 segundos)

Next.js (Server Actions / Route Handler):
  Mutaciones orientadas al usuario (CRUD)
  Operaciones basadas en sesión
  Lógica de negocio
  Validación de entrada con contexto de usuario

Trigger.dev (Background Jobs):
  Generación de PDF
  Tareas de IA
  Envío masivo de correos
  Todo lo que supere los 30 segundos de ejecución
```

### Condición verificable

```bash
# ¿Cuántas Edge Functions existen?
ls -d volumes/functions/*/ | grep -v "main\|_shared" | wc -l

# Para cada función verificar: ¿es una integración?
for dir in volumes/functions/*/; do
  name=$(basename "$dir")
  [[ "$name" == "main" || "$name" == "_shared" ]] && continue
  echo "--- $name ---"
  # ¿Contiene patterns de webhook/integración?
  grep -l "signature\|webhook\|stripe\|github\|trigger" "$dir"*.ts 2>/dev/null || \
    echo "ADVERTENCIA: no se encontraron patterns de webhook/integración"
done
```

### Escenario de fallo

Si la lógica de negocio se implementa en las Edge Functions, surge una arquitectura sombra: la misma validación existe en las Next.js Server Actions Y en las Edge Functions, con diferencias sutiles. Los bugs se vuelven difíciles de reproducir porque no queda claro qué ruta de código estaba activa. La lógica de autenticación debe mantenerse en dos lugares.

## A2 - Aislar endpoints de webhooks: una función por webhook

### Implementación

Cada proveedor de webhooks recibe su propia función en un directorio propio:

```
volumes/functions/
  stripe-webhook/
    index.ts
  github-webhook/
    index.ts
  trigger-webhook/
    index.ts
```

**No de esta manera:**

```
volumes/functions/
  webhooks/
    index.ts     <- procesa Stripe, GitHub y Trigger en un solo archivo
```

### Condición verificable

```bash
# Cada función de webhook debe atender a un solo proveedor
for dir in volumes/functions/*-webhook/; do
  name=$(basename "$dir")
  providers=$(grep -ciE "stripe|github|trigger|slack|sendgrid" "$dir/index.ts")
  if [ "$providers" -gt 1 ]; then
    echo "ADVERTENCIA: $name atiende a varios proveedores ($providers)"
  fi
done
```

### Escenario de fallo

Si varios webhooks se procesan en una sola función, comparten el mismo manejador de errores. Un payload defectuoso de Stripe puede bloquear el webhook de GitHub. Las estrategias de reintento difieren según el proveedor (Stripe reintenta con backoff exponencial, GitHub solo 3 veces), lo que difícilmente se puede implementar de forma limpia en una función compartida.

## A3 - Configurar CORS correctamente

### Implementación

Las Edge Functions que se invocan desde el navegador (también indirectamente) necesitan cabeceras CORS. Supabase no proporciona una configuración CORS automática para las Edge Functions.

Configuración CORS compartida:

```typescript
// volumes/functions/_shared/cors.ts

const allowedOrigins = [
  'https://app.example.com',
  ...(Deno.env.get('ENVIRONMENT') === 'development'
    ? ['http://localhost:3000']
    : [])
]

export function getCorsHeaders(req: Request) {
  const origin = req.headers.get('origin') ?? ''
  const corsOrigin = allowedOrigins.includes(origin) ? origin : ''

  return {
    'Access-Control-Allow-Origin': corsOrigin,
    'Access-Control-Allow-Headers':
      'authorization, x-client-info, apikey, content-type',
    'Access-Control-Allow-Methods': 'POST, GET, OPTIONS',
  }
}
```

**Cada Edge Function** debe gestionar CORS al principio:

```typescript
import { getCorsHeaders } from '../_shared/cors.ts'

Deno.serve(async (req) => {
  const corsHeaders = getCorsHeaders(req)

  // El preflight CORS debe ser la PRIMERA verificación
  if (req.method === 'OPTIONS') {
    return new Response('ok', { headers: corsHeaders })
  }

  // ... lógica principal

  return new Response(JSON.stringify(data), {
    headers: { ...corsHeaders, 'Content-Type': 'application/json' },
  })
})
```

### Condición verificable

```bash
# Todas las funciones deben gestionar CORS
for dir in volumes/functions/*/; do
  name=$(basename "$dir")
  [[ "$name" == "main" || "$name" == "_shared" ]] && continue
  if ! grep -q "OPTIONS" "$dir/index.ts" 2>/dev/null; then
    echo "ADVERTENCIA: $name no tiene un manejador OPTIONS"
  fi
done

# Sin CORS wildcard en producción
grep -r "'\\*'" volumes/functions/ --include="*.ts" | grep -i "allow-origin"
# Expectativa: sin resultados (excepto en ramas de desarrollo)
```

### Escenario de fallo

Sin cabeceras CORS, todas las solicitudes del navegador a las Edge Functions fallan. El navegador bloquea la respuesta, aunque la función responda correctamente. Esto se manifiesta como un error CORS críptico en la consola. Con CORS wildcard (`'*'`) en producción, cualquier sitio web puede enviar solicitudes a las Edge Functions y leer las respuestas.

## Parte B - Verificaciones de implementación

Estas verificaciones se aplican a cada Edge Function y deben comprobarse en cada despliegue.

## B1 - Verificar firmas de webhooks

### Implementación

Cada endpoint de webhook debe verificar la firma del servicio emisor. Sin verificación de firma, cualquiera puede enviar payloads arbitrarios a la función.

**Ejemplo completo de webhook de Stripe:**

```typescript
// volumes/functions/stripe-webhook/index.ts

import { getCorsHeaders } from '../_shared/cors.ts'

const STRIPE_WEBHOOK_SECRET = Deno.env.get('STRIPE_WEBHOOK_SECRET')

Deno.serve(async (req) => {
  const corsHeaders = getCorsHeaders(req)

  if (req.method === 'OPTIONS') {
    return new Response('ok', { headers: corsHeaders })
  }

  // 1. Permitir solo POST
  if (req.method !== 'POST') {
    return new Response(
      JSON.stringify({ error: 'Method not allowed' }),
      { status: 405, headers: { ...corsHeaders, 'Content-Type': 'application/json' } }
    )
  }

  // 2. Verificar firma
  const signature = req.headers.get('stripe-signature')
  if (!signature) {
    return new Response(
      JSON.stringify({ error: 'Missing signature' }),
      { status: 401, headers: { ...corsHeaders, 'Content-Type': 'application/json' } }
    )
  }

  const body = await req.text()

  const isValid = await verifyStripeSignature(body, signature, STRIPE_WEBHOOK_SECRET!)
  if (!isValid) {
    return new Response(
      JSON.stringify({ error: 'Invalid signature' }),
      { status: 401, headers: { ...corsHeaders, 'Content-Type': 'application/json' } }
    )
  }

  // 3. Procesar evento
  const event = JSON.parse(body)

  switch (event.type) {
    case 'checkout.session.completed':
      await handleCheckoutCompleted(event.data.object)
      break
    case 'invoice.payment_failed':
      await handlePaymentFailed(event.data.object)
      break
    default:
      // Ignorar eventos desconocidos, no fallar
      console.log(`Unhandled event type: ${event.type}`)
  }

  // 4. Siempre devolver 200 (de lo contrario Stripe reintenta)
  return new Response(
    JSON.stringify({ received: true }),
    { status: 200, headers: { ...corsHeaders, 'Content-Type': 'application/json' } }
  )
})

// Verificación de firma de Stripe con Deno Crypto API
async function verifyStripeSignature(
  payload: string,
  header: string,
  secret: string
): Promise<boolean> {
  const parts = header.split(',')
  const timestamp = parts.find(p => p.startsWith('t='))?.split('=')[1]
  const signature = parts.find(p => p.startsWith('v1='))?.split('=')[1]

  if (!timestamp || !signature) return false

  // Verificación temporal: rechazar eventos con más de 5 minutos
  const now = Math.floor(Date.now() / 1000)
  if (now - parseInt(timestamp) > 300) return false

  const signedPayload = `${timestamp}.${payload}`
  const key = await crypto.subtle.importKey(
    'raw',
    new TextEncoder().encode(secret),
    { name: 'HMAC', hash: 'SHA-256' },
    false,
    ['sign']
  )

  const sig = await crypto.subtle.sign(
    'HMAC',
    key,
    new TextEncoder().encode(signedPayload)
  )

  const expectedSig = Array.from(new Uint8Array(sig))
    .map(b => b.toString(16).padStart(2, '0'))
    .join('')

  return expectedSig === signature
}

async function handleCheckoutCompleted(session: Record<string, unknown>) {
  console.log(`Checkout completed: ${session.id}`)
}

async function handlePaymentFailed(invoice: Record<string, unknown>) {
  console.log(`Payment failed: ${invoice.id}`)
}
```

**Verificación de firma de webhook de GitHub (procedimiento diferente):**

```typescript
// volumes/functions/github-webhook/index.ts

const GITHUB_WEBHOOK_SECRET = Deno.env.get('GITHUB_WEBHOOK_SECRET')

async function verifyGitHubSignature(
  payload: string,
  signatureHeader: string,
  secret: string
): Promise<boolean> {
  // GitHub utiliza sha256=<hex>
  const expected = signatureHeader.replace('sha256=', '')

  const key = await crypto.subtle.importKey(
    'raw',
    new TextEncoder().encode(secret),
    { name: 'HMAC', hash: 'SHA-256' },
    false,
    ['sign']
  )

  const sig = await crypto.subtle.sign(
    'HMAC',
    key,
    new TextEncoder().encode(payload)
  )

  const computed = Array.from(new Uint8Array(sig))
    .map(b => b.toString(16).padStart(2, '0'))
    .join('')

  return computed === expected
}
```

### Condición verificable

```bash
# Cada función de webhook debe tener una verificación de firma
for dir in volumes/functions/*-webhook/; do
  name=$(basename "$dir")
  if ! grep -qE "signature|verify|hmac" "$dir/index.ts" 2>/dev/null; then
    echo "CRÍTICO: $name no tiene verificación de firma"
  else
    echo "OK: $name verifica firmas"
  fi
done

# Verificar configuración de VERIFY_JWT
# Los webhooks necesitan VERIFY_JWT=false porque los servicios externos no envían JWT de Supabase
grep "VERIFY_JWT" .env
```

### Escenario de fallo

Sin verificación de firma, un atacante puede enviar eventos arbitrarios al webhook:

```bash
curl -X POST https://app.example.com/functions/v1/stripe-webhook \
  -H "Content-Type: application/json" \
  -d '{"type":"checkout.session.completed","data":{"object":{"customer":"cus_fake"}}}'
```

Esta solicitud generaría una confirmación de checkout falsa. La función actualizaría el estado del usuario aunque nunca se haya realizado un pago.

## B2 - Inicializar el cliente Supabase correctamente (anon vs. service_role)

### Implementación

Las Edge Functions tienen acceso a todas las variables de entorno de Supabase. La elección entre la clave `anon` y la clave `service_role` es la decisión de seguridad más importante por función.

**Client Factory compartida:**

```typescript
// volumes/functions/_shared/supabase-client.ts

import { createClient, SupabaseClient } from 'npm:@supabase/supabase-js@2'

// Cliente CON RLS (para operaciones con contexto de usuario)
export function createAnonClient(authHeader?: string): SupabaseClient {
  const client = createClient(
    Deno.env.get('SUPABASE_URL')!,
    Deno.env.get('SUPABASE_ANON_KEY')!,
    {
      global: {
        headers: authHeader ? { Authorization: authHeader } : {},
      },
    }
  )
  return client
}

// Cliente SIN RLS (para procesamiento de webhooks, tareas administrativas)
// ATENCIÓN: Omite todas las políticas de Row Level Security
export function createAdminClient(): SupabaseClient {
  return createClient(
    Deno.env.get('SUPABASE_URL')!,
    Deno.env.get('SUPABASE_SERVICE_ROLE_KEY')!
  )
}
```

**Cuándo usar cada cliente:**

```
createAnonClient(authHeader):
  Funciones orientadas al usuario (poco frecuente, normalmente pertenecen a Next.js)
  Cuando RLS debe controlar el acceso

createAdminClient():
  Procesamiento de webhooks (Stripe, GitHub)
  Tareas de sincronización internas
  Cuando la función NO tiene contexto de usuario

Regla general: los webhooks no tienen contexto de usuario,
por lo tanto necesitan service_role.
Pero: ejecutar solo las operaciones mínimas necesarias.
```

### Condición verificable

```bash
# ¿Dónde se utiliza service_role / Admin Client?
grep -rn "SERVICE_ROLE\|createAdminClient\|service_role" \
  volumes/functions/ --include="*.ts" | grep -v "_shared/"

# Expectativa: solo en funciones de webhook, no en funciones orientadas al usuario

# ¿Se alimenta el Admin Client con input de usuario no validado?
# Revisión manual: en cada función que utilice createAdminClient,
# verificar que el input se valida antes de la operación en la base de datos
```

### Escenario de fallo

Si una Edge Function se ejecuta con `service_role` y pasa input de usuario directamente a las consultas, omite RLS por completo. Un payload de webhook manipulado podría entonces leer o escribir datos arbitrarios en cualquier tabla, porque la clave `service_role` no tiene restricciones.

## B3 - Validación de entrada

### Implementación

Cada Edge Function debe validar los datos entrantes antes de procesarlos. En Deno, Zod funciona mediante importación npm:

```typescript
// volumes/functions/stripe-webhook/index.ts (extracto)

import { z } from 'npm:zod@3'

// Schema para el evento Stripe esperado
const stripeEventSchema = z.object({
  id: z.string().startsWith('evt_'),
  type: z.string(),
  data: z.object({
    object: z.record(z.unknown()),
  }),
})

// En la función principal después de la verificación de firma:
const parsed = stripeEventSchema.safeParse(JSON.parse(body))

if (!parsed.success) {
  return new Response(
    JSON.stringify({ error: 'Invalid payload structure' }),
    { status: 400, headers: { ...corsHeaders, 'Content-Type': 'application/json' } }
  )
}

// A partir de aquí trabajar con parsed.data (con tipos seguros)
const event = parsed.data
```

### Condición verificable

```bash
# Cada función debe tener validación de entrada
for dir in volumes/functions/*/; do
  name=$(basename "$dir")
  [[ "$name" == "main" || "$name" == "_shared" ]] && continue
  if grep -qE "zod|safeParse|z\.object|z\.string" "$dir/index.ts" 2>/dev/null; then
    echo "OK: $name tiene validación de schema"
  elif grep -qE "JSON\.parse" "$dir/index.ts" 2>/dev/null; then
    echo "ADVERTENCIA: $name parsea JSON sin validación de schema"
  fi
done
```

### Escenario de fallo

Sin validación de entrada, la función acepta cualquier payload que tenga una firma válida. Una clave API comprometida del proveedor de webhooks podría entonces enviar estructuras de datos inesperadas que provoquen operaciones indefinidas en la base de datos, por ejemplo `undefined` como ID de usuario en un insert.

## B4 - Secrets en variables de entorno, nunca en el código

### Implementación

En el setup self-hosted, los secrets se pasan a las Edge Functions a través de la configuración de Docker Compose:

```yaml
# docker-compose.yml (extracto)
functions:
  environment:
    JWT_SECRET: ${JWT_SECRET}
    SUPABASE_URL: http://kong:8000
    SUPABASE_ANON_KEY: ${ANON_KEY}
    SUPABASE_SERVICE_ROLE_KEY: ${SERVICE_ROLE_KEY}
  env_file:
    - .env.functions    # secrets adicionales para las funciones
```

```bash
# .env.functions (solo en el servidor, no en Git)
STRIPE_WEBHOOK_SECRET=whsec_...
STRIPE_SECRET_KEY=sk_live_...
GITHUB_WEBHOOK_SECRET=ghsec_...
TRIGGER_DEV_API_KEY=tr_...
```

Acceder en el código:

```typescript
// Así: variable de entorno
const secret = Deno.env.get('STRIPE_WEBHOOK_SECRET')

// NUNCA así: hardcoded
const secret = 'whsec_abc123...'
```

Para los fundamentos generales de la gestión de secrets, consulta [Seguridad de datos en la infraestructura IA enterprise](/es/revista/seguridad-datos-ia-enterprise/).

### Condición verificable

```bash
# ¿Secrets hardcoded en el código?
grep -rn "sk_live\|sk_test\|whsec_\|ghsec_\|Bearer ey" \
  volumes/functions/ --include="*.ts"
# Expectativa: sin resultados

# ¿.env.functions no está en Git?
git ls-files .env.functions
# Expectativa: vacío

# ¿Permisos de archivo correctos?
stat -c "%a" .env.functions
# Expectativa: 600
```

### Escenario de fallo

Los secrets hardcoded en el código fuente acaban en el repositorio Git. Incluso si el repositorio es privado, todos los desarrolladores con acceso al repositorio tienen también acceso a los secrets de producción. En caso de un push público accidental, los secrets quedan comprometidos de inmediato.

## B5 - Evitar timeouts y procesos de larga duración

### Implementación

Las Edge Functions están diseñadas para operaciones cortas e idempotentes. El Edge Runtime self-hosted tiene un timeout por defecto (configurable, típicamente 60 segundos para self-hosted). Los procesos de larga duración bloquean slots de workers.

```
Adecuado (< 30 segundos):
  Recibir webhook y actualizar la base de datos
  Verificar firma y reenviar evento
  Llamadas API cortas a servicios externos

NO adecuado (usar Trigger.dev):
  Generación de PDF
  Inferencia de IA (llamadas a LLM)
  Procesamiento de vídeo/imagen
  Operaciones masivas en la base de datos
  Envío de correos a muchos destinatarios
```

**Patrón para procesos de larga duración: Edge Function como disparador, job en Trigger.dev:**

```typescript
// volumes/functions/process-document/index.ts

// CORRECTO: la Edge Function solo dispara el job
Deno.serve(async (req) => {
  // ... verificar firma, validar entrada ...

  // Delegar el proceso de larga duración a Trigger.dev
  const triggerResponse = await fetch(
    `${Deno.env.get('TRIGGER_DEV_URL')}/api/v1/tasks/process-document/trigger`,
    {
      method: 'POST',
      headers: {
        'Authorization': `Bearer ${Deno.env.get('TRIGGER_DEV_API_KEY')}`,
        'Content-Type': 'application/json',
      },
      body: JSON.stringify({
        payload: { documentId: parsed.data.documentId },
      }),
    }
  )

  // Responder de inmediato, el job se ejecuta en segundo plano
  return new Response(
    JSON.stringify({ queued: true }),
    { status: 202, headers: { 'Content-Type': 'application/json' } }
  )
})
```

### Condición verificable

```bash
# Buscar patterns que indiquen procesos de larga duración
grep -rn "await.*fetch.*openai\|pdf\|sharp\|ffmpeg\|sleep\|setTimeout" \
  volumes/functions/ --include="*.ts" | grep -v "trigger"
# Expectativa: sin resultados (excepto llamadas API cortas)

# ¿Hay timeouts en el código?
grep -rn "AbortSignal.timeout\|setTimeout" \
  volumes/functions/ --include="*.ts"
# Cada fetch externo debería tener un timeout
```

### Escenario de fallo

Una Edge Function que espera 2 minutos a una llamada API de IA bloquea un slot de worker en el contenedor Edge Runtime. Con varias solicitudes simultáneas, los workers se saturan y las llamadas de webhook posteriores (por ejemplo de Stripe) fallan con timeouts. Stripe interpreta esto como un error y reintenta, lo que agrava la situación.

## B6 - Manejo de errores y respuestas seguras

### Implementación

Las Edge Functions no deben filtrar detalles internos al llamador en caso de error.

```typescript
// Patrón para manejo seguro de errores

Deno.serve(async (req) => {
  const corsHeaders = getCorsHeaders(req)

  if (req.method === 'OPTIONS') {
    return new Response('ok', { headers: corsHeaders })
  }

  try {
    // ... lógica principal ...

    return new Response(
      JSON.stringify({ success: true }),
      { status: 200, headers: { ...corsHeaders, 'Content-Type': 'application/json' } }
    )

  } catch (error) {
    // Registrar internamente (detalles)
    console.error(`Function error: ${error.message}`, {
      stack: error.stack,
      // NO registrar secrets ni datos de usuario
    })

    // Responder externamente (genérico)
    return new Response(
      JSON.stringify({ error: 'Internal server error' }),
      { status: 500, headers: { ...corsHeaders, 'Content-Type': 'application/json' } }
    )
  }
})
```

**Lo que NO debe incluirse en respuestas ni logs:**

```typescript
// INCORRECTO: enviar stack trace al cliente
return new Response(JSON.stringify({ error: error.stack }), { status: 500 })

// INCORRECTO: registrar secrets
console.log(`Connecting with key: ${Deno.env.get('SERVICE_ROLE_KEY')}`)

// INCORRECTO: registrar datos completos del usuario
console.log(`Processing user: ${JSON.stringify(user)}`)
```

### Condición verificable

```bash
# ¿Se envían detalles de error al cliente?
grep -rn "error\.stack\|error\.message" volumes/functions/ --include="*.ts" | \
  grep "Response"
# Expectativa: sin resultados (stack/message solo en console.error)

# ¿Se registran secrets?
grep -rn "console\.log.*KEY\|console\.log.*SECRET\|console\.log.*token" \
  volumes/functions/ --include="*.ts"
# Expectativa: sin resultados
```

### Escenario de fallo

Si se envía un stack trace de error al cliente, un atacante ve rutas internas, nombres de módulos y detalles de conexión a la base de datos. Esto facilita considerablemente los ataques dirigidos. Si los secrets aparecen en los logs, son visibles para cualquier persona con acceso a la monitorización.

## Parte C - Operación y monitorización

## C1 - Workflow de despliegue

### Implementación

En el setup self-hosted no existe un comando `supabase functions deploy`. El workflow se basa en archivos:

```bash
#!/bin/bash
# scripts/deploy-functions.sh

set -euo pipefail

FUNCTIONS_DIR="/opt/supabase/volumes/functions"
SOURCE_DIR="./supabase/functions"

echo "Deploying Edge Functions..."

# 1. Verificación de sintaxis (Deno)
for file in $(find "$SOURCE_DIR" -name "*.ts" -not -path "*/_shared/*"); do
  deno check "$file" 2>/dev/null || {
    echo "ERROR: error de sintaxis en $file"
    exit 1
  }
done

# 2. Copiar funciones
rsync -av --delete \
  --exclude='*.test.ts' \
  "$SOURCE_DIR/" "$FUNCTIONS_DIR/"

# 3. Reiniciar contenedor
docker compose restart functions --no-deps

# 4. Health Check
sleep 5
HEALTH=$(curl -s -o /dev/null -w "%{http_code}" \
  http://localhost:8000/functions/v1/hello 2>/dev/null || echo "000")

if [ "$HEALTH" = "200" ] || [ "$HEALTH" = "401" ]; then
  echo "Despliegue de Edge Functions completado con éxito"
else
  echo "ADVERTENCIA: Health Check con estado $HEALTH"
fi
```

### Condición verificable

```bash
# ¿Está corriendo el contenedor Edge Runtime?
docker compose ps functions --format '{{.State}}'
# Expectativa: running

# ¿Son accesibles las funciones?
curl -s -o /dev/null -w "%{http_code}" \
  -H "Authorization: Bearer ${ANON_KEY}" \
  http://localhost:8000/functions/v1/stripe-webhook
# Expectativa: 200 o 405 (Method Not Allowed, porque es GET en lugar de POST)
```

## C2 - Integración con Claude Code

Claude Code verifica las Edge Functions de forma contextual como complemento a las verificaciones deterministas.

### Arquitectura

```
Git Push / PR
   |
   +-- Verificaciones deterministas (CI/CD)
   |   +-- grep en busca de secrets hardcoded
   |   +-- grep en busca de verificación de firma ausente
   |   +-- grep en busca de validación de entrada ausente
   |   +-- grep en busca de detalles de error en respuestas
   |   +-- Deno Type Check
   |
   +-- Análisis de Claude Code (semanal o en PR)
       +-- ¿Funciones nuevas sin verificación de firma?
       +-- ¿Uso de service_role apropiado?
       +-- ¿Patterns de procesos de larga duración detectados?
       +-- ¿Deriva arquitectónica (lógica de negocio en Functions)?
       +-- ¿CORS correcto para funciones nuevas?
```

### Script CI concreto

```bash
#!/bin/bash
# scripts/check-edge-functions.sh

REPORT=""
FUNCTIONS_DIR="volumes/functions"

# 1. Secrets hardcoded
SECRETS=$(grep -rn "sk_live\|sk_test\|whsec_\|Bearer ey" \
  "$FUNCTIONS_DIR" --include="*.ts" 2>/dev/null)
if [ -n "$SECRETS" ]; then
  REPORT+="CRÍTICO: secrets hardcoded encontrados:\n$SECRETS\n\n"
fi

# 2. Funciones de webhook sin verificación de firma
for dir in "$FUNCTIONS_DIR"/*-webhook/; do
  [ -d "$dir" ] || continue
  name=$(basename "$dir")
  if ! grep -qE "signature|verify|hmac|crypto" "$dir/index.ts" 2>/dev/null; then
    REPORT+="CRÍTICO: $name no tiene verificación de firma\n"
  fi
done

# 3. Funciones sin validación de entrada
for dir in "$FUNCTIONS_DIR"/*/; do
  name=$(basename "$dir")
  [[ "$name" == "main" || "$name" == "_shared" ]] && continue
  if grep -q "JSON.parse" "$dir/index.ts" 2>/dev/null && \
     ! grep -qE "zod|safeParse|z\." "$dir/index.ts" 2>/dev/null; then
    REPORT+="ADVERTENCIA: $name parsea JSON sin validación de schema\n"
  fi
done

# 4. Detalles de error en respuestas
LEAKS=$(grep -rn "error\.stack\|error\.message" "$FUNCTIONS_DIR" --include="*.ts" | \
  grep "Response" 2>/dev/null)
if [ -n "$LEAKS" ]; then
  REPORT+="ADVERTENCIA: detalles de error en respuestas:\n$LEAKS\n\n"
fi

# 5. CORS Wildcards
WILDCARDS=$(grep -rn "'\\*'" "$FUNCTIONS_DIR" --include="*.ts" | grep -i "origin" 2>/dev/null)
if [ -n "$WILDCARDS" ]; then
  REPORT+="ADVERTENCIA: CORS wildcard encontrado:\n$WILDCARDS\n\n"
fi

# 6. Patterns de procesos de larga duración
LONG=$(grep -rn "openai\|sharp\|ffmpeg\|puppeteer" "$FUNCTIONS_DIR" --include="*.ts" 2>/dev/null)
if [ -n "$LONG" ]; then
  REPORT+="ADVERTENCIA: posibles patterns de procesos de larga duración:\n$LONG\n\n"
fi

# Salida
if [ -n "$REPORT" ]; then
  echo -e "=== Edge Function Security Check ===\n"
  echo -e "$REPORT"
else
  echo "Todas las verificaciones de Edge Functions superadas."
fi
```

Claude **no ejecuta cambios automáticos en producción**.

## Lista de verificación de despliegue

Comprobar antes de cada despliegue de Edge Functions:

```
Arquitectura
  [ ] La función es una integración (webhook/evento), no lógica de negocio
  [ ] Un proveedor de webhook por función
  [ ] Procesos de larga duración delegados a Trigger.dev

Seguridad
  [ ] Se verifica la firma del webhook
  [ ] Se valida el input con schema (p. ej. Zod)
  [ ] Elección correcta del cliente (anon vs. service_role)
  [ ] service_role solo cuando no hay contexto de usuario

Secrets
  [ ] Sin secrets hardcoded en el código
  [ ] Secrets en .env.functions (no en Git)
  [ ] .env.functions con permisos 600

CORS
  [ ] Manejador OPTIONS presente
  [ ] Sin wildcard-origin en producción
  [ ] Cabeceras CORS en TODAS las respuestas (también errores)

Manejo de errores
  [ ] Try/Catch alrededor de toda la lógica
  [ ] Mensajes de error genéricos al cliente
  [ ] Detalles solo en console.error (sin secrets)

Despliegue
  [ ] Deno Type Check superado
  [ ] Contenedor reiniciado tras el despliegue
  [ ] Health Check tras el despliegue exitoso
```

## Conclusión

Las Supabase Edge Functions son un punto de integración potente cuando se utilizan como tal: recibir webhooks, verificar firmas, procesar eventos y reenviarlos.

El punto decisivo es la delimitación. Las Edge Functions no son un segundo backend junto a Next.js ni un job runner junto a Trigger.dev. Quien trace esta frontera con claridad e implemente los fundamentos de seguridad (firmas, validación de entrada, cliente correcto, CORS), puede operar las Edge Functions de forma segura en un setup self-hosted.

La combinación de verificaciones deterministas en el CI y análisis contextual de Claude Code cubre tanto los patterns conocidos como los riesgos nuevos e inesperados. Quien apuesta desde el principio por [Cert-Ready-by-Design](/es/revista/cert-ready-by-design/) se ahorra rondas de auditoría posteriores.

<div class="not-prose my-12 border border-gosign-border bg-gosign-light rounded-card p-6 lg:p-8">
<div class="flex items-start gap-4">
<div class="flex-shrink-0 w-12 h-12 bg-gosign-dark rounded-card flex items-center justify-center">
<svg width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="white" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 15v4a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2v-4"/><polyline points="7 10 12 15 17 10"/><line x1="12" y1="15" x2="12" y2="3"/></svg>
</div>
<div>
<h2 class="text-h3 font-bold text-gosign-dark mb-2" id="descarga-de-la-lista-de-verificacion">Descarga de la lista de verificación</h2>
<p class="text-body text-gosign-text mb-2">Prompt preparado para Claude Code. Suba el archivo a su servidor e inicie Claude Code en el directorio del proyecto de sus Edge Functions. Claude Code verificará automáticamente todos los puntos de seguridad de este runbook e informará APROBADO, ADVERTENCIA o CRÍTICO.</p>
<p class="text-sm text-gosign-text mb-4 font-mono">claude -p "$(cat claude-check-artikel-3-edge-functions-es.md)" --allowedTools Read,Grep,Glob,Bash</p>
<a href="/downloads/claude-check-artikel-3-edge-functions-es.md" download class="inline-flex items-center px-6 py-3 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-small uppercase tracking-wider">Descargar checklist</a>
</div>
</div>
</div>

## Índice de la serie

Este artículo forma parte de nuestra serie DevOps para app stacks self-hosted.

1. [Supabase Self-Hosting Runbook](/es/revista/supabase-self-hosting/)
2. [Next.js sobre Supabase de forma segura](/es/revista/nextjs-supabase-configuracion-segura/)
3. [Supabase Edge Functions de forma segura](/es/revista/supabase-edge-functions-seguridad/) - este artículo
4. [Trigger.dev Background Jobs en producción segura](/es/revista/trigger-dev-background-jobs/)
5. [Claude Code como control de seguridad en el workflow DevOps](/es/revista/claude-code-security-devops/)
6. [Security Baseline para todo el stack](/es/revista/security-baseline-stack/)

En el próximo artículo mostramos cómo **operar Trigger.dev Background Jobs de forma segura** sin crear nuevos riesgos de seguridad en el stack.

--- Supabase Self-Hosting Runbook: arquitectura segura ---
> Supabase Self-Hosting Runbook: configuracion Hetzner, Docker Compose, arquitectura de servicios, secrets, RLS y backups.

Alojar Supabase por cuenta propia es técnicamente bastante sencillo. **Operar Supabase de forma segura y estable** es considerablemente más exigente.

La razón: Supabase no es una simple base de datos, sino una plataforma backend completa. Un stack self-hosted de Supabase se compone típicamente de varios componentes: PostgreSQL, PostgREST API, GoTrue Auth, Realtime Server, Storage, Kong API Gateway, Supabase Studio y opcionalmente Edge Functions.

> **Estadística:** Según el informe de Supabase de 2025, más del 68% de las instancias self-hosted no tienen RLS activo en todas las tablas públicas, lo que convierte esta verificación en la más frecuentemente omitida.


Con esto se opera de facto una **plataforma backend**, no solo una base de datos. Consideraciones similares se aplican al [self-hosting de modelos de lenguaje](/es/revista/llm-self-hosting-enterprise/).

Este runbook describe un setup de producción mínimo que puede operarse de forma segura y que al mismo tiempo sigue siendo automatizable. Cada paso contiene una implementación concreta, una condición verificable y un escenario de fallo.

> **Nota sobre el proveedor de hosting:** Este runbook utiliza **Hetzner Cloud** como ejemplo de infraestructura porque Hetzner está ampliamente extendido en el ámbito germanoparlante, ofrece centros de datos en Alemania y tiene una buena relación calidad-precio. Sin embargo, los principios de arquitectura son **independientes del proveedor**. Los elementos específicos de Hetzner (vSwitch, Cloud Firewall API, Robot Panel) se pueden trasladar directamente a proveedores españoles y europeos: Arsys/IONOS Cloud Network (ES), OVH vRack (ES - datacenter Madrid), Stackscale Private Network (ES), Acens Cloud (ES). Cuando un paso es específico de Hetzner, lo indicamos.


<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">De un vistazo - Artículo 1 de 6 de la serie DevOps Runbook</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Arquitectura de dos servidores separa producción y auditoría</li>
<li>Docker Compose con versiones de imágenes fijadas</li>
<li>Siete servicios (PostgreSQL, PostgREST, GoTrue, Kong, Realtime, Storage, Studio)</li>
<li>RLS en todas las tablas públicas</li>
<li>Backups cifrados diarios almacenados externamente</li>
</ul>
</div>

## Índice de la serie

Esta guía forma parte de nuestra serie de runbooks DevOps para app stacks self-hosted modernos.

1. [Supabase Self-Hosting Runbook](/es/revista/supabase-self-hosting/) - este artículo
2. [Next.js sobre Supabase de forma segura](/es/revista/nextjs-supabase-configuracion-segura/)
3. [Supabase Edge Functions de forma segura](/es/revista/supabase-edge-functions-seguridad/)
4. [Trigger.dev Background Jobs en producción segura](/es/revista/trigger-dev-background-jobs/)
5. [Claude Code como control de seguridad en el workflow DevOps](/es/revista/claude-code-security-devops/)
6. [Security Baseline para todo el stack](/es/revista/security-baseline-stack/)

El artículo 1 cubre **infraestructura, servicios y configuración del stack**. Los artículos siguientes se construyen sobre ella.


### Resumen de servicios

| Servicio | Puerto | Función | Configuración crítica de seguridad |
|---|---|---|---|
| PostgreSQL | 5432 | Almacenamiento de datos | RLS en todas las tablas, listen_address solo interno |
| PostgREST | 3000 | REST API | Aplicación automática de RLS, acceso basado en roles |
| GoTrue | 9999 | Autenticación | JWT expiry, confirmación por email, refresh token rotation |
| Kong | 8000 | API Gateway | Rate limiting, enrutamiento, validación JWT |
| Realtime | 4000 | WebSocket | Autorización de canales, límites de conexión |
| Storage | 5000 | Object Storage | Políticas de buckets, límites de tamaño de archivo |
| Studio | 3000 | Panel de administración | Acceso solo interno (SSH Tunnel/VPN) |

## Arquitectura objetivo

Un setup estable separa al menos dos áreas de responsabilidad.

```
Internet
   |
   |  HTTPS (443)
   |
Reverse Proxy (Caddy / Nginx / Traefik)
   |
   |  TLS terminado
   |
Kong API Gateway
   |
   +-- GoTrue         (Auth)
   +-- PostgREST       (API)
   +-- Realtime        (WebSocket)
   +-- Storage         (Object Store compatible con S3)
   |
PostgreSQL
   |
   +-- RLS Policies
```

En paralelo funciona un segundo sistema separado:

```
Audit Server
   |
   +-- Security Checks    (Lynis, Trivy, Port Scans)
   +-- Drift Detection     (Config Diffs contra Baseline)
   +-- Claude Code Review  (análisis contextual)
   +-- Monitoring          (métricas, alertas)
   +-- Backup Verification (pruebas de restore)
```

Por qué es necesaria esta separación: si el sistema de producción y el sistema de auditoría son idénticos, un servidor comprometido puede manipular simultáneamente también sus propias verificaciones de seguridad.

## Parte A - Decisiones de infraestructura

Estas decisiones se toman una sola vez y constituyen el fundamento de todo lo demás.

## A1 - Separar la infraestructura: dos servidores

### Implementación

Operar al menos dos servidores, físicos o como VMs separadas:

```
supabase-prod     (Hetzner Cloud CX32 o superior)
audit-runner      (Hetzner Cloud CX22 es suficiente)
```

> **Específico de Hetzner:** En la Hetzner Cloud Console, crear dos instancias separadas en "Servers", ambas en el mismo proyecto y la misma ubicación (p. ej. fsn1). Con otros proveedores: dos VMs en la misma región/zona.

**supabase-prod** aloja el stack completo de Supabase y PostgreSQL.
**audit-runner** aloja los Security Checks, Monitoring, Drift Detection y análisis con Claude Code.

### Condición verificable

```bash
# Ambos servidores deben ser hosts separados
ssh supabase-prod hostname
ssh audit-runner hostname

# Expectativa: nombres de host e IPs diferentes
```

### Escenario de fallo

Si la auditoría y la producción se ejecutan en el mismo servidor y un atacante obtiene acceso root, puede eliminar logs, manipular los resultados de los Security Checks y suprimir alertas. La vulneración pasa desapercibida.

## A2 - Configurar red privada

### Implementación

Ambos servidores se comunican internamente a través de una red privada. Los servicios de Supabase solo son accesibles a través de estas IPs internas.

> **Específico de Hetzner:** En "Networks", crear un vSwitch o un Cloud Network con la subred `10.0.1.0/24`. Asignar ambos servidores a la red. Hetzner crea automáticamente una interfaz (normalmente `ens10`). En Arsys/IONOS (ES): Cloud Network. En OVH (ES): vRack. En Stackscale (ES): Private Network.

```bash
# Configurar la interfaz privada en ambos servidores
# /etc/network/interfaces.d/60-private.cfg (específico de Hetzner)

auto ens10
iface ens10 inet static
  address 10.0.1.10/24    # supabase-prod
  # address 10.0.1.11/24  # audit-runner
```

```bash
# Activar la red
systemctl restart networking

# Verificar
ip addr show ens10
ping 10.0.1.11   # desde el servidor prod
```

### Condición verificable

```bash
# Desde audit-runner: ¿interfaz interna activa?
ssh audit-runner "ip addr show ens10 | grep 10.0.1.11"

# PostgreSQL solo debe escuchar internamente
ssh supabase-prod "ss -tlnp | grep 5432"

# Expectativa: 10.0.1.10:5432, NO 0.0.0.0:5432
```

### Escenario de fallo

Si PostgreSQL escucha en `0.0.0.0:5432` y el firewall tiene un error, la base de datos es directamente accesible desde Internet. Con la clave `service_role` o una contraseña débil de Postgres, toda la base de datos queda comprometida.

## A3 - Reverse Proxy con TLS

### Implementación

Delante de Kong se sitúa un Reverse Proxy que termina el TLS y es el único servicio accesible desde el exterior. Aquí se usa Caddy como ejemplo porque incluye Let's Encrypt automático.

```
# Caddyfile

app.example.com {
    reverse_proxy localhost:8000 {
        header_up X-Forwarded-Proto {scheme}
        header_up X-Real-IP {remote_host}
    }

    header {
        X-Frame-Options "DENY"
        X-Content-Type-Options "nosniff"
        Referrer-Policy "strict-origin-when-cross-origin"
        Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
        -Server
    }
}
```

Alternativa con Nginx:

```nginx
server {
    listen 443 ssl http2;
    server_name app.example.com;

    ssl_certificate /etc/letsencrypt/live/app.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/app.example.com/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;

    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # Soporte WebSocket para Realtime
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}
```

### Condición verificable

```bash
# ¿TLS activo y correctamente configurado?
curl -I https://app.example.com

# Expectativa: HTTP/2 200, cabecera Strict-Transport-Security presente

# Verificar versión TLS
openssl s_client -connect app.example.com:443 -tls1_2 </dev/null 2>&1 | grep "Protocol"

# Fecha de expiración del certificado
echo | openssl s_client -connect app.example.com:443 2>/dev/null | \
  openssl x509 -noout -enddate

# Expectativa: notAfter al menos 14 días en el futuro

# ¿Cabeceras de seguridad presentes?
curl -sI https://app.example.com | grep -E \
  "X-Frame-Options|Strict-Transport-Security|X-Content-Type-Options"
```

### Escenario de fallo

Sin TLS, los tokens de autenticación circulan en texto plano por la red. Cualquiera en el mismo segmento de red puede interceptarlos (Man-in-the-Middle). Sin renovación automática de certificados, el certificado expira tras 90 días y la aplicación deja de ser accesible.

## A4 - Doble firewall

### Implementación

Dos niveles que se protegen mutuamente:

**Nivel 1: Cloud Firewall (delante del servidor)**

> **Específico de Hetzner:** En "Firewalls", crear un nuevo firewall y asignarlo a ambos servidores. En Arsys/IONOS (ES): Cloud Firewall. En OVH (ES): Firewall Network. En Stackscale (ES): Security Groups.

```
# Reglas de Hetzner Cloud Firewall para supabase-prod

Inbound:
  TCP 443    desde 0.0.0.0/0        (HTTPS)
  TCP 22     desde ADMIN_IP/32       (SSH solo desde Admin)
  TCP ALL    desde 10.0.1.0/24       (red interna)

Outbound:
  ALL        hacia 0.0.0.0/0        (Updates, DNS, Let's Encrypt)
```

**Nivel 2: Host Firewall (en el servidor)**

```bash
# /etc/iptables/rules.v4

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]

# Loopback
-A INPUT -i lo -j ACCEPT

# Conexiones establecidas
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# SSH solo desde IP de Admin
-A INPUT -p tcp --dport 22 -s ADMIN_IP -j ACCEPT

# HTTPS
-A INPUT -p tcp --dport 443 -j ACCEPT

# Red interna (todos los puertos)
-A INPUT -s 10.0.1.0/24 -j ACCEPT

# Descartar todo lo demás (Default Policy)
COMMIT
```

```bash
# Activar el firewall
apt install iptables-persistent
iptables-restore < /etc/iptables/rules.v4

# Guardar baseline para Drift Detection
iptables-save > /root/firewall-baseline.txt
```

### Condición verificable

```bash
# Desde el exterior: solo puerto 443 abierto
nmap -p 22,80,443,5432,8000,9000 app.example.com

# Expectativa: solo 443 open (22 solo desde IP de Admin)

# En el servidor: ¿reglas activas?
iptables -L -n | grep -c "DROP"

# Expectativa: al menos 1 (Default DROP Policy)

# Drift Detection: ¿ha cambiado el firewall?
iptables-save | diff /root/firewall-baseline.txt -

# Expectativa: sin diferencias
```

### Escenario de fallo

Un único firewall puede estar mal configurado. Un `iptables -F` (flush) en el servidor abre todos los puertos si no existe un Cloud Firewall. A la inversa, un Cloud Firewall no protege contra procesos que abren nuevos puertos en el propio servidor si no hay un Host Firewall activo.

## A5 - Asegurar el acceso SSH

### Implementación

```bash
# /etc/ssh/sshd_config

PasswordAuthentication no
 PermitRootLogin no
PubkeyAuthentication yes
MaxAuthTries 3
LoginGraceTime 30
AllowUsers deploy
```

```bash
# Depositar la clave SSH en el servidor
mkdir -p /home/deploy/.ssh
echo "ssh-ed25519 AAAA... admin@workstation" > /home/deploy/.ssh/authorized_keys
chmod 700 /home/deploy/.ssh
chmod 600 /home/deploy/.ssh/authorized_keys
chown -R deploy:deploy /home/deploy/.ssh

# Recargar SSHD
systemctl reload sshd
```

### Condición verificable

```bash
# El login con contraseña debe fallar
ssh -o PasswordAuthentication=yes -o PubkeyAuthentication=no deploy@app.example.com

# Expectativa: Permission denied

# El login como root debe fallar
ssh root@app.example.com

# Expectativa: Permission denied

# Verificar configuración
sshd -T | grep -E "passwordauthentication|permitrootlogin"

# Expectativa: passwordauthentication no, permitrootlogin no
```

### Escenario de fallo

Los accesos SSH basados en contraseña son atacados continuamente desde Internet (fuerza bruta). Una contraseña débil se descubre normalmente en cuestión de horas. El login como root significa que un atacante obtiene inmediatamente control total sobre el servidor.

## Parte B - Configurar y asegurar los servicios de Supabase

Un stack self-hosted de Supabase se compone de más de 10 servicios. Cada uno tiene sus propias variables de entorno, sus propios roles de base de datos y sus propios requisitos de seguridad. El `docker-compose.yml` oficial de Supabase tiene más de 400 líneas y contiene muchos ajustes que no parecen relevantes para la seguridad pero que lo son.

Esta sección explica cada servicio, su función, su configuración relevante para la seguridad y los errores típicos durante el setup.

### Visión general de servicios

```
Internet
   |
   |  HTTPS (443)
   |
Reverse Proxy (Caddy/Nginx)     <- Parte A3
   |
Kong (API Gateway)               <- enruta a todos los servicios
   |
   +-- GoTrue (Auth)              <- /auth/v1/*
   +-- PostgREST (REST API)       <- /rest/v1/*
   +-- Realtime                   <- /realtime/v1/*
   +-- Storage API                <- /storage/v1/*
   +-- Edge Functions             <- /functions/v1/*
   +-- Studio (Dashboard)         <- / (protegido con Basic Auth)
   |
   +-- Meta (Postgres-Meta)       <- interno, para Studio
   +-- ImgProxy                   <- interno, para Storage
   +-- Analytics (Logflare)       <- interno, para Logs
   +-- Vector                     <- interno, Log-Pipeline
   +-- Supavisor (Pooler)         <- Connection Pooling
   |
PostgreSQL                        <- Base de datos con Init-Scripts
   |
   +-- Roles: anon, authenticated, service_role,
       authenticator, supabase_admin, supabase_auth_admin,
       supabase_storage_admin
```

## B0 - Generar secrets (antes del primer arranque)

**Esto debe ocurrir ANTES de iniciar todos los servicios.** El `.env.example` oficial contiene marcadores de posición. Estos deben ser reemplazados por valores generados.

```bash
# JWT Secret (compartido por GoTrue, PostgREST, Realtime, Kong)
JWT_SECRET=$(openssl rand -base64 32)

# Contraseña de Postgres
POSTGRES_PASSWORD=$(openssl rand -base64 24)

# Contraseña del Dashboard (Basic Auth via Kong)
DASHBOARD_PASSWORD=$(openssl rand -base64 16)

# Tokens de Logflare
LOGFLARE_PUBLIC_ACCESS_TOKEN=$(openssl rand -hex 16)
LOGFLARE_PRIVATE_ACCESS_TOKEN=$(openssl rand -hex 16)

# Contraseña root de MinIO (si se usa S3 Storage)
MINIO_ROOT_PASSWORD=$(openssl rand -hex 16)

# Realtime Secret Key Base (mín. 64 caracteres)
SECRET_KEY_BASE=$(openssl rand -base64 48)

# Supavisor Vault Encryption Key
VAULT_ENC_KEY=$(openssl rand -base64 24)

# PG Meta Crypto Key
PG_META_CRYPTO_KEY=$(openssl rand -base64 24)

# Claves Anon y Service Role (JWTs, generados con el JWT_SECRET)
# Usa https://supabase.com/docs/guides/self-hosting/docker#generate-api-keys
# o genéralos manualmente con jwt.io y el JWT_SECRET
```

**Regla de seguridad:** Todos los secrets se almacenan en el archivo `.env` en el servidor (permisos 600, no en Git). Supabase utiliza un único `JWT_SECRET` para todos los servicios. Si este secret se ve comprometido, GoTrue, PostgREST y Realtime se ven afectados simultáneamente.

### Condición verificable

```bash
# ¿Todos los secrets requeridos están configurados?
for var in JWT_SECRET POSTGRES_PASSWORD ANON_KEY SERVICE_ROLE_KEY \
  DASHBOARD_PASSWORD LOGFLARE_PUBLIC_ACCESS_TOKEN SECRET_KEY_BASE \
  VAULT_ENC_KEY PG_META_CRYPTO_KEY; do
  if grep -q "^${var}=$\|^${var}=your-\|^${var}=change" .env 2>/dev/null; then
    echo "CRITICO: $var no está configurado o tiene valor por defecto"
  fi
done

# ¿No hay contraseñas idénticas?
PASSWORDS=$(grep -E "PASSWORD|SECRET|KEY" .env | cut -d= -f2 | sort)
UNIQUE=$(echo "$PASSWORDS" | sort -u)
if [ "$(echo "$PASSWORDS" | wc -l)" != "$(echo "$UNIQUE" | wc -l)" ]; then
  echo "AVISO: Algunos secrets tienen valores idénticos"
fi
```

### Escenario de fallo

Los secrets por defecto del `.env.example` son públicamente conocidos. Un atacante puede generar tokens válidos con el `JWT_SECRET` por defecto y obtener acceso total a la API. Con el `SERVICE_ROLE_KEY` por defecto elude además todas las RLS Policies.

## B1 - PostgreSQL: base de datos y roles

### Qué hace este servicio

PostgreSQL es la base de datos central. En el contexto de Supabase tiene un papel especial: no solo almacena datos de la aplicación, sino también datos de autenticación (GoTrue), configuración de Realtime, metadatos de Storage y logs de Analytics. Los Init-Scripts crean schemas y roles especiales.

### Configuración relevante para la seguridad

```yaml
db:
  image: supabase/postgres:15.8.1.085    # Imagen propia de Supabase, fijar versión
  restart: unless-stopped
  ports:
    - "10.0.1.10:5432:5432"              # SOLO interfaz interna
  volumes:
    # Init-Scripts (crean schemas, roles, extensiones)
    - ./volumes/db/realtime.sql:/docker-entrypoint-initdb.d/migrations/99-realtime.sql:Z
    - ./volumes/db/webhooks.sql:/docker-entrypoint-initdb.d/init-scripts/98-webhooks.sql:Z
    - ./volumes/db/roles.sql:/docker-entrypoint-initdb.d/init-scripts/99-roles.sql:Z
    - ./volumes/db/jwt.sql:/docker-entrypoint-initdb.d/init-scripts/99-jwt.sql:Z
    - ./volumes/db/_supabase.sql:/docker-entrypoint-initdb.d/migrations/97-_supabase.sql:Z
    - ./volumes/db/logs.sql:/docker-entrypoint-initdb.d/migrations/99-logs.sql:Z
    - ./volumes/db/pooler.sql:/docker-entrypoint-initdb.d/migrations/99-pooler.sql:Z
    # Datos persistentes
    - ./volumes/db/data:/var/lib/postgresql/data:Z
    - db-config:/etc/postgresql-custom
  healthcheck:
    test: ["CMD", "pg_isready", "-U", "postgres", "-h", "localhost"]
    interval: 5s
    timeout: 5s
    retries: 10
  environment:
    POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    POSTGRES_DB: ${POSTGRES_DB}
    JWT_SECRET: ${JWT_SECRET}
    JWT_EXP: ${JWT_EXPIRY}
```

**Los Init-Scripts crean los siguientes roles:**

```
postgres              -> Superuser (solo para admin, nunca para servicios)
anon                  -> Requests no autenticados (via PostgREST)
authenticated         -> Requests autenticados (via PostgREST)
service_role          -> Elude RLS (para operaciones administrativas)
authenticator         -> PostgREST usa este rol para conectarse
supabase_admin        -> Rol interno de admin (Realtime, Analytics)
supabase_auth_admin   -> Específico de GoTrue (schema auth)
supabase_storage_admin -> Específico de Storage (schema storage)
```

### Qué puede salir mal

El archivo `roles.sql` define los grants para cada rol. Si este archivo se modifica (por ejemplo, para resolver rápidamente un problema), los roles pueden obtener demasiados permisos. El rol `anon` solo debe tener los permisos que las RLS Policies permiten explícitamente.

### Condición verificable

```bash
# Verificar roles y sus permisos
docker compose exec -T db psql -U postgres -c \
  "SELECT rolname, rolsuper, rolcreaterole, rolcreatedb, rolcanlogin
   FROM pg_roles
   WHERE rolname IN ('anon','authenticated','service_role','authenticator',
     'supabase_admin','supabase_auth_admin','supabase_storage_admin')
   ORDER BY rolname;"

# anon NO debe ser superuser
docker compose exec -T db psql -U postgres -c \
  "SELECT rolname, rolsuper FROM pg_roles WHERE rolname = 'anon' AND rolsuper = true;"
# Expectativa: ninguna fila

# Postgres escucha SOLO internamente
ss -tlnp | grep 5432
# Expectativa: 10.0.1.10:5432, NO 0.0.0.0:5432
```

## B2 - Kong: API Gateway y enrutamiento

### Qué hace este servicio

Kong es el punto de entrada central para todas las peticiones API. Enruta según la ruta URL a los servicios correspondientes, gestiona la validación JWT y protege el dashboard de Studio con Basic Auth.

### Configuración relevante para la seguridad

```yaml
kong:
  image: kong:2.8.1                       # Fijar versión
  restart: unless-stopped
  ports:
    - "127.0.0.1:8000:8000"              # SOLO localhost (Reverse Proxy delante)
    - "127.0.0.1:8443:8443"              # HTTPS interno
  volumes:
    - ./volumes/api/kong.yml:/home/kong/temp.yml:ro,z
  environment:
    KONG_DATABASE: "off"                   # Config declarativa, sin BD
    KONG_DECLARATIVE_CONFIG: /home/kong/kong.yml
    KONG_DNS_ORDER: LAST,A,CNAME
    KONG_PLUGINS: request-transformer,cors,key-auth,acl,basic-auth,request-termination,ip-restriction
    SUPABASE_ANON_KEY: ${ANON_KEY}
    SUPABASE_SERVICE_KEY: ${SERVICE_ROLE_KEY}
    DASHBOARD_USERNAME: ${DASHBOARD_USERNAME}
    DASHBOARD_PASSWORD: ${DASHBOARD_PASSWORD}
  entrypoint: bash -c 'eval "echo \"$$(cat ~/temp.yml)\"" > ~/kong.yml && /docker-entrypoint.sh kong docker-start'
```

**El `kong.yml` define el enrutamiento:**

```
/rest/v1/*        -> PostgREST (port 3000)    + JWT Validation
/auth/v1/*        -> GoTrue (port 9999)       + JWT Validation
/realtime/v1/*    -> Realtime (port 4000)      + JWT Validation
/storage/v1/*     -> Storage (port 5000)       + JWT Validation
/functions/v1/*   -> Edge Functions (port 54321) + JWT Validation (opcional)
/                 -> Studio (port 3000)        + Basic Auth
```

### Qué puede salir mal

Kong en `0.0.0.0:8000` en lugar de `127.0.0.1:8000` significa que la API es accesible directamente sin Reverse Proxy (sin TLS). Una contraseña de dashboard débil da acceso via Basic Auth al Studio y con ello a toda la base de datos. El `kong.yml` puede configurarse de forma que la validación JWT esté desactivada para ciertas rutas.

### Condición verificable

```bash
# ¿Kong solo en localhost?
ss -tlnp | grep 8000
# Expectativa: 127.0.0.1:8000

# ¿Contraseña del dashboard suficientemente fuerte?
DASH_PW_LEN=$(grep "DASHBOARD_PASSWORD" .env | cut -d= -f2 | wc -c)
[ "$DASH_PW_LEN" -lt 16 ] && echo "AVISO: Contraseña del dashboard demasiado corta"

# kong.yml: ¿JWT Validation activa en todas las rutas API?
grep -A5 "key-auth" volumes/api/kong.yml | head -20
```

## B3 - GoTrue: autenticación

### Qué hace este servicio

GoTrue gestiona el registro de usuarios, login, Magic Links, OAuth, MFA y la emisión de tokens. Es el único servicio que emite JWTs y tiene un usuario de BD propio (`supabase_auth_admin`) con acceso al schema `auth`.

### Configuración relevante para la seguridad

```yaml
auth:
  image: supabase/gotrue:v2.184.0       # Fijar versión
  restart: unless-stopped
  environment:
    GOTRUE_API_HOST: 0.0.0.0
    GOTRUE_API_PORT: 9999
    API_EXTERNAL_URL: ${API_EXTERNAL_URL}    # https://app.example.com

    # Base de datos (usuario admin propio)
    GOTRUE_DB_DATABASE_URL: postgres://supabase_auth_admin:${POSTGRES_PASSWORD}@${POSTGRES_HOST}:${POSTGRES_PORT}/${POSTGRES_DB}

    # JWT
    GOTRUE_JWT_SECRET: ${JWT_SECRET}
    GOTRUE_JWT_EXP: ${JWT_EXPIRY}            # MAXIMO 3600 (1 hora)
    GOTRUE_JWT_AUD: authenticated
    GOTRUE_JWT_ADMIN_ROLES: service_role
    GOTRUE_JWT_DEFAULT_GROUP_NAME: authenticated

    # Registro
    GOTRUE_DISABLE_SIGNUP: ${DISABLE_SIGNUP}  # true si la app es cerrada
    GOTRUE_EXTERNAL_EMAIL_ENABLED: ${ENABLE_EMAIL_SIGNUP}
    GOTRUE_MAILER_AUTOCONFIRM: false          # SIEMPRE false en producción

    # SMTP (para Magic Links, confirmación por email)
    GOTRUE_SMTP_HOST: ${SMTP_HOST}
    GOTRUE_SMTP_PORT: ${SMTP_PORT}
    GOTRUE_SMTP_USER: ${SMTP_USER}
    GOTRUE_SMTP_PASS: ${SMTP_PASS}
    GOTRUE_SMTP_ADMIN_EMAIL: ${SMTP_ADMIN_EMAIL}
    GOTRUE_SMTP_SENDER_NAME: ${SMTP_SENDER_NAME}

    # Rutas URL del Mailer (deben coincidir con el enrutamiento de Kong)
    GOTRUE_MAILER_URLPATHS_CONFIRMATION: "/auth/v1/verify"
    GOTRUE_MAILER_URLPATHS_INVITE: "/auth/v1/verify"
    GOTRUE_MAILER_URLPATHS_RECOVERY: "/auth/v1/verify"
    GOTRUE_MAILER_URLPATHS_EMAIL_CHANGE: "/auth/v1/verify"

    # Site URL (Redirect después de Auth)
    GOTRUE_SITE_URL: ${SITE_URL}              # URL de vuestra app Next.js
    GOTRUE_URI_ALLOW_LIST: ${ADDITIONAL_REDIRECT_URLS}

    # Refresh Token Rotation (previene reutilización de tokens)
    GOTRUE_SECURITY_REFRESH_TOKEN_ROTATION_ENABLED: true
    GOTRUE_SECURITY_REFRESH_TOKEN_REUSE_INTERVAL: 10
```

### Configuración SMTP: por qué es relevante para la seguridad

Sin un servidor SMTP funcional no se pueden enviar emails de confirmación. Si se configura `GOTRUE_MAILER_AUTOCONFIRM: true` para evitarlo, cualquiera puede registrarse con cualquier dirección de email. Esto significa: sin verificación de identidad.

### Condición verificable

```bash
# Health Check de GoTrue
docker compose exec -T auth wget --no-verbose --tries=1 --spider http://localhost:9999/health

# ¿JWT Expiry no superior a 3600?
grep "JWT_EXPIRY\|JWT_EXP" .env | head -1
# Expectativa: 3600 o menos

# ¿Autoconfirm desactivado?
grep "AUTOCONFIRM" .env
# Expectativa: false

# ¿SMTP configurado (no vacío)?
for var in SMTP_HOST SMTP_PORT SMTP_USER SMTP_PASS; do
  VAL=$(grep "^${var}=" .env | cut -d= -f2)
  [ -z "$VAL" ] && echo "AVISO: $var está vacío"
done

# ¿Refresh Token Rotation activo?
grep "REFRESH_TOKEN_ROTATION" .env docker-compose.yml 2>/dev/null
# Expectativa: true
```

### Escenario de fallo

Con `AUTOCONFIRM=true` y `DISABLE_SIGNUP=false`, cualquiera puede crear una cuenta y usarla inmediatamente sin confirmar la dirección de email. Un atacante puede registrarse con direcciones arbitrarias y obtiene inmediatamente el rol `authenticated` en la base de datos. Sin Refresh Token Rotation, un refresh token robado puede ser utilizado indefinidamente.

## B4 - PostgREST: REST API

### Qué hace este servicio

PostgREST genera automáticamente una REST API a partir del schema de PostgreSQL. Es el punto de acceso principal para datos. La seguridad reside primariamente en los roles de PostgreSQL y las RLS Policies, no en PostgREST en sí mismo.

### Configuración relevante para la seguridad

```yaml
rest:
  image: postgrest/postgrest:v14.1       # Fijar versión
  restart: unless-stopped
  environment:
    PGRST_DB_URI: postgres://authenticator:${POSTGRES_PASSWORD}@${POSTGRES_HOST}:${POSTGRES_PORT}/${POSTGRES_DB}
    PGRST_DB_SCHEMAS: ${PGRST_DB_SCHEMAS}   # public,storage,graphql_public
    PGRST_DB_ANON_ROLE: anon
    PGRST_JWT_SECRET: ${JWT_SECRET}
    PGRST_DB_USE_LEGACY_GUCS: "false"
    PGRST_APP_SETTINGS_JWT_SECRET: ${JWT_SECRET}
    PGRST_APP_SETTINGS_JWT_EXP: ${JWT_EXPIRY}
```

**Cómo trabaja PostgREST con los roles:**

```
Request sin JWT     -> PostgREST usa rol "anon"
Request con JWT      -> PostgREST cambia al rol del JWT (p. ej. "authenticated")
Request con service_role JWT -> PostgREST usa "service_role" (elude RLS)
```

El usuario `authenticator` se conecta a la BD y cambia mediante `SET ROLE` al rol correspondiente. Esto significa: los grants en los roles `anon` y `authenticated` son la verdadera capa de seguridad.

### Condición verificable

```bash
# ¿PostgREST usa el rol authenticator (no postgres)?
grep "PGRST_DB_URI" docker-compose.yml | grep "authenticator"
# Expectativa: Sí

# ¿Schemas definidos explícitamente (no todos)?
grep "PGRST_DB_SCHEMAS" .env
# Expectativa: public,storage,graphql_public (no vacío = todos los schemas)
```

### Escenario de fallo

Si `PGRST_DB_URI` usa el superusuario `postgres` en lugar de `authenticator`, cada request tiene permisos de superusuario y RLS es ineficaz. Si `PGRST_DB_SCHEMAS` está vacío, PostgREST expone todos los schemas incluyendo los internos de Supabase (`auth`, `_realtime`, `_analytics`).

## B5 - Realtime: suscripciones WebSocket

### Qué hace este servicio

Realtime permite suscripciones basadas en WebSocket a cambios en la base de datos. Usa el usuario `supabase_admin` y el schema `_realtime`.

### Configuración relevante para la seguridad

```yaml
realtime:
  container_name: realtime-dev.supabase-realtime   # El nombre es relevante para el Tenant-ID
  image: supabase/realtime:v2.68.0
  restart: unless-stopped
  environment:
    PORT: 4000
    DB_HOST: ${POSTGRES_HOST}
    DB_PORT: ${POSTGRES_PORT}
    DB_USER: supabase_admin
    DB_PASSWORD: ${POSTGRES_PASSWORD}
    DB_NAME: ${POSTGRES_DB}
    DB_AFTER_CONNECT_QUERY: 'SET search_path TO _realtime'
    DB_ENC_KEY: supabaserealtime          # CAMBIAR en producción
    API_JWT_SECRET: ${JWT_SECRET}
    SECRET_KEY_BASE: ${SECRET_KEY_BASE}   # mín. 64 caracteres
    SEED_SELF_HOST: "true"
    RUN_JANITOR: "true"
```

### Qué puede salir mal

`DB_ENC_KEY: supabaserealtime` es un valor por defecto. En producción debe cambiarse. `SECRET_KEY_BASE` debe tener al menos 64 caracteres, de lo contrario el servicio no arranca o es inseguro. Realtime usa `supabase_admin`, lo que significa que internamente tiene acceso completo a la BD. La seguridad reside en la validación JWT: solo usuarios autenticados pueden abrir suscripciones, y RLS determina qué filas ven.

### Condición verificable

```bash
# ¿DB_ENC_KEY no tiene valor por defecto?
grep "DB_ENC_KEY" docker-compose.yml
# NO "supabaserealtime"

# ¿SECRET_KEY_BASE suficientemente largo?
SKB_LEN=$(grep "SECRET_KEY_BASE" .env | cut -d= -f2 | wc -c)
[ "$SKB_LEN" -lt 64 ] && echo "CRITICO: SECRET_KEY_BASE demasiado corto ($SKB_LEN caracteres)"

# Health Check de Realtime
docker compose exec -T realtime-dev.supabase-realtime \
  curl -sSf -H "Authorization: Bearer ${ANON_KEY}" \
  http://localhost:4000/api/tenants/realtime-dev/health
```

## B6 - Storage API y MinIO (S3)

### Qué hace este servicio

Storage gestiona la subida y descarga de archivos. Por defecto almacena archivos localmente en el volumen. Para producción se recomienda un backend compatible con S3 (MinIO self-hosted o un servicio S3 libre del Cloud Act).

### Almacenamiento local (predeterminado)

```yaml
storage:
  image: supabase/storage-api:v1.33.0
  restart: unless-stopped
  volumes:
    - ./volumes/storage:/var/lib/storage:z
  environment:
    ANON_KEY: ${ANON_KEY}
    SERVICE_KEY: ${SERVICE_ROLE_KEY}
    POSTGREST_URL: http://rest:3000
    PGRST_JWT_SECRET: ${JWT_SECRET}
    DATABASE_URL: postgres://supabase_storage_admin:${POSTGRES_PASSWORD}@${POSTGRES_HOST}:${POSTGRES_PORT}/${POSTGRES_DB}
    STORAGE_BACKEND: file
    FILE_STORAGE_BACKEND_PATH: /var/lib/storage
    FILE_SIZE_LIMIT: 52428800              # 50MB, ajustar
    ENABLE_IMAGE_TRANSFORMATION: "true"
    IMGPROXY_URL: http://imgproxy:5001
```

### MinIO para backend S3 (producción)

Si usáis MinIO, se añade un servicio adicional:

```yaml
# docker-compose.s3.yml (adicional al Compose principal)
minio:
  image: minio/minio:latest              # Fijar versión en producción
  restart: unless-stopped
  ports:
    - "127.0.0.1:9000:9000"              # API, SOLO localhost
    - "127.0.0.1:9001:9001"              # Console, SOLO localhost
  volumes:
    - minio-data:/data
  environment:
    MINIO_ROOT_USER: ${MINIO_ROOT_USER}
    MINIO_ROOT_PASSWORD: ${MINIO_ROOT_PASSWORD}   # mín. 8 caracteres
  command: server /data --console-address ":9001"
```

Luego en la configuración de Storage:

```yaml
storage:
  environment:
    STORAGE_BACKEND: s3
    GLOBAL_S3_BUCKET: supabase-storage
    GLOBAL_S3_ENDPOINT: http://minio:9000
    GLOBAL_S3_FORCE_PATH_STYLE: "true"
    AWS_ACCESS_KEY_ID: ${MINIO_ACCESS_KEY}
    AWS_SECRET_ACCESS_KEY: ${MINIO_SECRET_KEY}
    REGION: eu-central-1
```

### Condición verificable

```bash
# Health Check de Storage
docker compose exec -T storage wget --no-verbose --tries=1 --spider http://localhost:5000/status

# ¿MinIO no accesible desde el exterior (si se usa)?
ss -tlnp | grep 9000
# Expectativa: 127.0.0.1:9000 (no 0.0.0.0)

# ¿Credenciales por defecto de MinIO?
grep "MINIO_ROOT" .env | grep -iE "minioadmin\|minio123\|admin"
# Expectativa: sin coincidencias

# ¿El volumen de Storage existe y tiene datos?
ls -la volumes/storage/ 2>/dev/null | head -5

# Bucket Policies de Storage (via MinIO Client)
# mc alias set local http://localhost:9000 $MINIO_ROOT_USER $MINIO_ROOT_PASSWORD
# mc admin policy ls local
```

### Escenario de fallo

MinIO con credenciales por defecto (`minioadmin:minioadmin`) en `0.0.0.0:9000` significa: cualquiera en Internet puede leer y escribir todos los archivos. La consola de MinIO en el puerto 9001 proporciona adicionalmente una interfaz web para la administración completa. Las Bucket Policies de Storage pueden estar configuradas como "public", lo que significa que los archivos son accesibles sin autenticación.

## B7 - Analytics, Vector y Supavisor (servicios internos)

### Qué hacen estos servicios

Estos servicios no son accesibles directamente desde el exterior, pero son relevantes para la seguridad porque tienen acceso privilegiado a la base de datos.

**Analytics (Logflare):** Recopila y almacena logs de todos los servicios. Usa `supabase_admin` y el schema `_analytics`.

**Vector:** Pipeline de logs que reenvía los logs de Docker a Logflare. Tiene acceso al Docker Socket.

**Supavisor:** Connection Pooler para PostgreSQL. Gestiona el pool de conexiones y tiene acceso `supabase_admin`.

### Configuración relevante para la seguridad

```yaml
analytics:
  image: supabase/logflare:1.27.0
  ports:
    - "127.0.0.1:4000:4000"             # SOLO localhost
  environment:
    DB_USERNAME: supabase_admin
    DB_PASSWORD: ${POSTGRES_PASSWORD}
    LOGFLARE_PUBLIC_ACCESS_TOKEN: ${LOGFLARE_PUBLIC_ACCESS_TOKEN}
    LOGFLARE_PRIVATE_ACCESS_TOKEN: ${LOGFLARE_PRIVATE_ACCESS_TOKEN}

vector:
  image: timberio/vector:0.28.1-alpine
  volumes:
    - ${DOCKER_SOCKET_LOCATION}:/var/run/docker.sock:ro,z   # Read-Only!
  security_opt:
    - "label=disable"

supavisor:
  image: supabase/supavisor:2.7.4
  ports:
    - "10.0.1.10:5432:5432"             # Pooler expone el puerto de Postgres
    - "127.0.0.1:6543:6543"             # Transaction Mode
  environment:
    DATABASE_URL: ecto://supabase_admin:${POSTGRES_PASSWORD}@${POSTGRES_HOST}:${POSTGRES_PORT}/_supabase
    SECRET_KEY_BASE: ${SECRET_KEY_BASE}
    VAULT_ENC_KEY: ${VAULT_ENC_KEY}
    POOLER_DEFAULT_POOL_SIZE: ${POOLER_DEFAULT_POOL_SIZE}
    POOLER_MAX_CLIENT_CONN: ${POOLER_MAX_CLIENT_CONN}
```

### Qué puede salir mal

Vector con acceso al Docker Socket (`/var/run/docker.sock`) puede leer los logs de los contenedores. El socket debe montarse en modo **Read-Only** (`:ro`). Analytics en el puerto 4000 con tokens por defecto expone los logs de todos los servicios. Supavisor en `0.0.0.0:5432` en lugar de la interfaz interna hace que el Connection Pooler (y con ello PostgreSQL) sea accesible desde el exterior.

### Condición verificable

```bash
# ¿Analytics solo interno?
ss -tlnp | grep 4000
# Expectativa: 127.0.0.1:4000

# ¿Docker Socket de Vector en Read-Only?
grep "docker.sock" docker-compose.yml | grep ":ro"
# Expectativa: :ro presente

# ¿Puerto de Supavisor solo interno?
ss -tlnp | grep 5432
# Expectativa: 10.0.1.10:5432 (interfaz interna)

# ¿Tokens de Logflare no por defecto?
grep "LOGFLARE.*TOKEN" .env | grep -iE "your-\|change\|example"
# Expectativa: sin coincidencias
```

## B8 - Studio: asegurar el dashboard

### Qué hace este servicio

Studio es la interfaz web para la gestión de la base de datos, administración de usuarios y consultas SQL. A través del `SERVICE_ROLE_KEY` y el acceso directo a Postgres tiene **acceso completo a todo**.

### Configuración relevante para la seguridad

Studio está protegido via Kong con Basic Auth (DASHBOARD_USERNAME/DASHBOARD_PASSWORD). Además, Studio en producción debería no estar en ejecución o solo ser accesible mediante SSH Tunnel.

**Opción 1: no iniciar Studio en producción (recomendado)**

```yaml
# En docker-compose.override.yml o eliminar Studio del Compose
# Usar Studio solo localmente con supabase start para desarrollo
```

**Opción 2: Studio solo mediante SSH Tunnel**

```bash
# Desde la estación de trabajo:
ssh -L 3000:localhost:3000 deploy@supabase-prod

# Luego en el navegador: http://localhost:3000
```

### Condición verificable

```bash
# ¿El contenedor Studio está en ejecución? (No debería estarlo en producción)
docker compose ps | grep studio
# Recomendación: no running en producción

# Si Studio está en ejecución: ¿no accesible desde el exterior?
curl -s -o /dev/null -w "%{http_code}" --connect-timeout 3 \
  "https://app.example.com:3000" 2>/dev/null
# Expectativa: Timeout o Connection Refused

# ¿Contraseña del dashboard fuerte?
DASH_LEN=$(grep "DASHBOARD_PASSWORD" .env | cut -d= -f2 | wc -c)
[ "$DASH_LEN" -lt 16 ] && echo "AVISO: Contraseña del dashboard demasiado corta"
```

### Escenario de fallo

Studio con una contraseña de dashboard débil y acceso público proporciona a un atacante una interfaz completa de administración de base de datos. Puede ejecutar consultas SQL, eliminar usuarios, desactivar RLS y exportar datos. Es el peor escenario para un stack self-hosted.

### Lista de verificación de servicios

Después de configurar todos los servicios, verificar antes del primer uso productivo:

```
Secrets
  [ ] Todos los secrets generados (sin valores por defecto)
  [ ] JWT_SECRET al menos 32 caracteres
  [ ] POSTGRES_PASSWORD al menos 24 caracteres
  [ ] DASHBOARD_PASSWORD al menos 16 caracteres
  [ ] SECRET_KEY_BASE al menos 64 caracteres
  [ ] MINIO_ROOT_PASSWORD al menos 8 caracteres (si se usa MinIO)
  [ ] DB_ENC_KEY cambiado (no "supabaserealtime")

PostgreSQL
  [ ] Puerto solo en interfaz interna (10.0.1.10:5432)
  [ ] Init-Scripts sin modificar (roles.sql, jwt.sql etc.)
  [ ] Roles creados correctamente (anon no es superuser)

Kong
  [ ] Puerto solo en localhost (127.0.0.1:8000)
  [ ] JWT Validation activa en todas las rutas API
  [ ] Contraseña del dashboard fuerte

GoTrue (Auth)
  [ ] JWT_EXP máximo 3600
  [ ] AUTOCONFIRM false
  [ ] SMTP configurado y probado
  [ ] SITE_URL y API_EXTERNAL_URL correctos
  [ ] Refresh Token Rotation activo
  [ ] DISABLE_SIGNUP configurado si la app es cerrada

PostgREST
  [ ] Usa rol authenticator (no postgres)
  [ ] DB_SCHEMAS definido explícitamente

Realtime
  [ ] DB_ENC_KEY cambiado
  [ ] SECRET_KEY_BASE al menos 64 caracteres

Storage / MinIO
  [ ] MinIO no accesible desde el exterior
  [ ] Credenciales por defecto de MinIO cambiadas
  [ ] Permisos del volumen de Storage correctos

Servicios internos
  [ ] Puerto de Analytics solo localhost
  [ ] Docker Socket de Vector en Read-Only
  [ ] Puerto de Supavisor solo interno
  [ ] Tokens de Logflare no por defecto

Studio
  [ ] Desactivado en producción O solo mediante SSH Tunnel
  [ ] Contraseña del dashboard fuerte
```

## Parte C - Configurar el stack de Supabase

Estos pasos se refieren a la instalación de Supabase propiamente dicha y sus ajustes relevantes para la seguridad.

## C1 - Versionar el despliegue de Supabase

### Implementación

Todos los archivos de infraestructura pertenecen a un repositorio Git. Los despliegues se realizan exclusivamente a través de este repositorio, nunca mediante cambios manuales en el servidor.

```
infra/
  docker-compose.yml
  .env.example            (plantilla, sin secrets reales)
  caddy/
    Caddyfile
  postgres/
    migrations/
  scripts/
    backup.sh
    restore.sh
    health-check.sh
    security-check.sh
  runbooks/
    supabase-production.md
    security-baseline.md
```

### Workflow de despliegue

```bash
# En el servidor
cd /opt/supabase
git pull origin main

# Cargar variables de entorno (el archivo solo existe en el servidor)
source .env

# Iniciar/actualizar el stack
docker compose up -d

# Health Check
./scripts/health-check.sh
```

### Condición verificable

```bash
# ¿Hay cambios sin commit en el servidor?
cd /opt/supabase && git status --porcelain

# Expectativa: vacío (sin cambios locales)

# ¿Está el servidor actualizado?
git log --oneline -1
# Comparar con remoto
git fetch origin && git diff HEAD origin/main --stat

# Expectativa: sin diferencias
```

### Escenario de fallo

Los cambios manuales en el `docker-compose.yml` del servidor se sobrescriben en el siguiente `git pull` o generan conflictos de merge. Peor aún: nadie sabe qué cambio fue realizado cuándo y por quién. Tras la pérdida de un servidor, la configuración no es reproducible.

## C2 - docker-compose.yml: stack de producción mínimo

### Implementación

Supabase proporciona un archivo Compose de referencia con más de 400 líneas y unos 15 servicios. No todos son necesarios para producción. Estas son las decisiones relevantes para la seguridad:

**Stack mínimo (estos servicios son necesarios):**

```
postgres          Base de datos
kong              API Gateway
gotrue            Auth
postgrest         REST API
realtime          WebSocket (si es necesario)
storage           File Storage (si es necesario)
meta              Metadatos para PostgREST
```

**No en producción (omitir o solo interno):**

```
studio            Admin UI, solo mediante SSH Tunnel o VPN
imgproxy          solo si se necesitan transformaciones de imágenes
inbucket          solo para pruebas locales de email
```

Extracto de la configuración relevante para la seguridad:

```yaml
# docker-compose.yml (extracto, partes relevantes para la seguridad)

services:
  postgres:
    image: supabase/postgres:15.6.1.143    # Fijar versión
    restart: unless-stopped
    ports:
      - "10.0.1.10:5432:5432"              # SOLO interfaz interna
    environment:
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    volumes:
      - postgres-data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 30s
      timeout: 10s
      retries: 3

  kong:
    image: kong:2.8.1                       # Fijar versión
    restart: unless-stopped
    ports:
      - "127.0.0.1:8000:8000"              # SOLO localhost (Reverse Proxy delante)
    environment:
      KONG_DNS_ORDER: LAST,A,CNAME
      KONG_PLUGINS: request-transformer,cors,key-auth,acl
      KONG_NGINX_PROXY_PROXY_BUFFER_SIZE: 160k
      KONG_NGINX_PROXY_PROXY_BUFFERS: 64 160k

  gotrue:
    image: supabase/gotrue:v2.164.0         # Fijar versión
    restart: unless-stopped
    environment:
      GOTRUE_JWT_SECRET: ${JWT_SECRET}
      GOTRUE_JWT_EXP: 3600                  # 1 hora, no más
      GOTRUE_EXTERNAL_EMAIL_ENABLED: true
      GOTRUE_MAILER_AUTOCONFIRM: false      # Forzar confirmación por email
      GOTRUE_DISABLE_SIGNUP: false           # Poner en true si el registro está cerrado
      GOTRUE_RATE_LIMIT_HEADER: X-Real-IP
      GOTRUE_SECURITY_REFRESH_TOKEN_ROTATION_ENABLED: true
      GOTRUE_SECURITY_REFRESH_TOKEN_REUSE_INTERVAL: 10
      API_EXTERNAL_URL: https://app.example.com

  postgrest:
    image: postgrest/postgrest:v12.2.3      # Fijar versión
    restart: unless-stopped
    environment:
      PGRST_DB_URI: postgres://authenticator:${POSTGRES_PASSWORD}@postgres:5432/postgres
      PGRST_DB_ANON_ROLE: anon
      PGRST_JWT_SECRET: ${JWT_SECRET}

volumes:
  postgres-data:

networks:
  default:
    driver: bridge
```

**Puntos de configuración críticos:**

```
GOTRUE_JWT_EXP: 3600         no superior a 3600 (1h)
GOTRUE_MAILER_AUTOCONFIRM    false en producción
GOTRUE_DISABLE_SIGNUP         true si no hay registro abierto
REFRESH_TOKEN_ROTATION        true (previene reutilización de tokens)
Versiones de imágenes         siempre fijar, nunca :latest
Puerto de Postgres            solo en interfaz interna
Puerto de Kong                solo en localhost (Reverse Proxy delante)
```

### Condición verificable

```bash
# ¿Imágenes fijadas (sin :latest)?
grep "image:" docker-compose.yml | grep -c "latest"
# Expectativa: 0

# ¿Postgres solo accesible internamente?
docker compose exec postgres ss -tlnp | grep 5432
# Expectativa: solo 10.0.1.10:5432 o 0.0.0.0:5432 (entonces verificar firewall)

# ¿Postgres no accesible desde el exterior?
nmap -p 5432 app.example.com
# Expectativa: filtered o closed

# ¿JWT Expiry correcto?
grep "GOTRUE_JWT_EXP" .env
# Expectativa: 3600 o menos

# ¿Supabase Studio no accesible desde el exterior?
curl -s -o /dev/null -w "%{http_code}" https://app.example.com:3000
# Expectativa: Timeout o Connection Refused
```

### Escenario de fallo

Las imágenes sin fijar (`image: supabase/gotrue:latest`) pueden introducir inadvertidamente una nueva versión con un `docker compose pull`, que contenga breaking changes o una vulnerabilidad conocida. Si Postgres escucha en `0.0.0.0:5432` y el firewall falla temporalmente, toda la base de datos queda accesible en Internet. Si `GOTRUE_JWT_EXP` está en 86400 (24h), un token robado es válido durante un día entero.

## C3 - Gestionar secrets de forma completa y segura

### Implementación

Un stack de Supabase tiene al menos estos secrets:

```bash
# .env (solo en el servidor, nunca en Git)

# Secrets principales
JWT_SECRET=                    # mín. 32 caracteres, generado con openssl rand -base64 32
ANON_KEY=                      # Token JWT con rol anon
SERVICE_ROLE_KEY=              # Token JWT con service_role, omite RLS
POSTGRES_PASSWORD=             # mín. 24 caracteres, generado

# Dashboard
DASHBOARD_USERNAME=            # Login de Supabase Studio
DASHBOARD_PASSWORD=            # mín. 16 caracteres

# Email (GoTrue)
SMTP_HOST=
SMTP_PORT=
SMTP_USER=
SMTP_PASS=
SMTP_SENDER_NAME=

# Storage (si se usa backend S3)
S3_ACCESS_KEY=
S3_SECRET_KEY=
```

**Generar secrets:**

```bash
# JWT Secret
openssl rand -base64 32

# Contraseña de Postgres
openssl rand -base64 24

# Claves Anon y Service Role (Supabase CLI)
# O crear JWT manualmente con el JWT_SECRET
```

**Gestión de secrets en el servidor:**

```bash
# Archivo .env con permisos restrictivos
chmod 600 /opt/supabase/.env
chown deploy:deploy /opt/supabase/.env

# Verificar que .env no está en Git
cat /opt/supabase/.gitignore | grep ".env"
```

**En el repositorio solo se encuentra la plantilla:**

```bash
# .env.example (en Git)
JWT_SECRET=generate-with-openssl-rand-base64-32
ANON_KEY=generate-jwt-with-anon-role
SERVICE_ROLE_KEY=generate-jwt-with-service-role
POSTGRES_PASSWORD=generate-with-openssl-rand-base64-24
DASHBOARD_USERNAME=admin
DASHBOARD_PASSWORD=generate-min-16-chars
SMTP_HOST=
SMTP_PORT=587
SMTP_USER=
SMTP_PASS=
SMTP_SENDER_NAME=
```

El mismo principio se aplica a cualquier [seguridad de datos en infraestructura de IA empresarial](/es/revista/seguridad-datos-ia-enterprise/).

### Condición verificable

```bash
# ¿.env no está en Git?
cd /opt/supabase && git ls-files .env
# Expectativa: vacío

# ¿.env en .gitignore?
grep "^\.env$" .gitignore
# Expectativa: .env

# ¿Permisos de archivo correctos?
stat -c "%a %U" .env
# Expectativa: 600 deploy

# ¿Los secrets tienen longitud suficiente?
awk -F= '{if (length($2) < 16 && $2 != "" && $1 !~ /PORT|HOST|NAME/) print "DEMASIADO CORTO: "$1}' .env
# Expectativa: sin salida

# ¿Sin contraseñas por defecto?
grep -iE "password|secret" .env | grep -iE "change.me|default|example|your.*here"
# Expectativa: sin coincidencias
```

### Escenario de fallo

El problema de seguridad más frecuente en Supabase Self-Hosting no es un exploit de servidor, sino un secret filtrado. Si `.env` se hace commit en Git y el repositorio es público (o llega a serlo), todos los secrets quedan expuestos. Con la clave `SERVICE_ROLE_KEY` se puede leer y escribir toda la base de datos sin RLS.

## C4 - Verificar las políticas de base de datos

### Implementación

En Supabase, gran parte de la seguridad reside en PostgreSQL Row Level Security (RLS), no en el servidor de aplicación. Cada tabla del esquema `public` debe tener RLS activado.

**Encontrar tablas sin RLS:**

```sql
-- Todas las tablas public sin RLS
SELECT schemaname, tablename, rowsecurity
FROM pg_tables
WHERE schemaname = 'public'
  AND rowsecurity = false;
```

**Encontrar tablas con RLS pero sin Policies:**

```sql
-- RLS activo pero sin policy definida = no es posible el acceso
-- (puede ser intencionado, pero hay que verificar)
SELECT t.tablename
FROM pg_tables t
LEFT JOIN pg_policies p ON t.tablename = p.tablename
WHERE t.schemaname = 'public'
  AND t.rowsecurity = true
  AND p.policyname IS NULL;
```

**Encontrar Policies demasiado abiertas:**

```sql
-- Policies que conceden acceso total a todos los roles
SELECT tablename, policyname, permissive, roles, cmd, qual
FROM pg_policies
WHERE schemaname = 'public'
  AND (roles = '{public}' OR qual = 'true');
```

**Verificar el uso de Service Role:**

```sql
-- ¿Qué roles existen y qué permisos tienen?
SELECT rolname, rolsuper, rolcreaterole, rolcreatedb
FROM pg_roles
WHERE rolname IN ('anon', 'authenticated', 'service_role', 'authenticator');
```

### Condición verificable

```bash
# Como script automatizado desde audit-runner
ssh supabase-prod "docker compose exec -T postgres psql -U postgres -c \"
  SELECT tablename FROM pg_tables
  WHERE schemaname = 'public' AND rowsecurity = false;
\""

# Expectativa: sin tablas (o solo las excluidas intencionadamente)
```

### Escenario de fallo

Una tabla `users` con `rowsecurity = false` es completamente legible a través de la API PostgREST para cualquiera con la clave `anon`. Esto afecta a todas las columnas, incluidas direcciones de email, números de teléfono y otros datos personales. Un simple comando `curl` con la clave pública `anon` es suficiente.

## Parte D - Operación y monitorización

Estos pasos se ejecutan de forma regular y automatizada.

## D1 - Automatizar backups

### Implementación

Volcados diarios de PostgreSQL, cifrados y almacenados externamente.

```bash
#!/bin/bash
# scripts/backup.sh

set -euo pipefail

BACKUP_DIR="/opt/backups"
DATE=$(date +%Y-%m-%d_%H%M)
RETENTION_DAYS=30
GPG_RECIPIENT="backup@example.com"   # GPG Key ID

# Volcado de PostgreSQL
docker compose exec -T postgres pg_dump \
  -U postgres \
  --format=custom \
  --compress=9 \
  postgres > "${BACKUP_DIR}/db_${DATE}.dump"

# Respaldar Storage Buckets (si se usa Supabase Storage)
docker compose exec -T storage tar -czf - /var/lib/storage \
  > "${BACKUP_DIR}/storage_${DATE}.tar.gz"

# Cifrar
for file in "${BACKUP_DIR}"/*_${DATE}.*; do
  gpg --encrypt --recipient "${GPG_RECIPIENT}" "$file"
  rm "$file"   # Eliminar la versión sin cifrar
done

# Copiar al servidor externo (audit-runner o S3)
rsync -az "${BACKUP_DIR}/"*_${DATE}*.gpg \
  deploy@10.0.1.11:/opt/backup-archive/

# Eliminar backups antiguos (local)
find "${BACKUP_DIR}" -name "*.gpg" -mtime +${RETENTION_DAYS} -delete

# Limpiar también en el servidor de backup
ssh deploy@10.0.1.11 \
  "find /opt/backup-archive -name '*.gpg' -mtime +${RETENTION_DAYS} -delete"

echo "Backup ${DATE} completado"
```

```bash
# Configurar Cron Job
# crontab -e
0 3 * * * /opt/supabase/scripts/backup.sh >> /var/log/backup.log 2>&1
```

### Condición verificable

```bash
# ¿Existe el backup de hoy?
ls -la /opt/backups/*_$(date +%Y-%m-%d)*.gpg

# ¿Ha llegado el backup al servidor externo?
ssh deploy@10.0.1.11 "ls -la /opt/backup-archive/*_$(date +%Y-%m-%d)*.gpg"

# ¿Tamaño del backup plausible (no 0 bytes)?
find /opt/backups -name "*.gpg" -size 0 -print
# Expectativa: sin coincidencias
```

### Escenario de fallo

Almacenar los backups solo en el mismo servidor significa que, si el servidor falla o es cifrado (ransomware), los backups también se pierden. Los backups sin cifrar en un servidor externo son una filtración de datos, ya que el volcado contiene todos los datos de las tablas en texto plano.

## D2 - Probar el restore periódicamente

### Implementación

Una vez al mes, restaurar un backup en un sistema de prueba.

```bash
#!/bin/bash
# scripts/restore-test.sh

set -euo pipefail

BACKUP_FILE=$1   # p. ej. /opt/backup-archive/db_2026-03-01_0300.dump.gpg

# Descifrar
gpg --decrypt "$BACKUP_FILE" > /tmp/restore-test.dump

# Iniciar contenedor de prueba
docker run -d --name restore-test \
  -e POSTGRES_PASSWORD=testpassword \
  supabase/postgres:15.6.1.143

sleep 10

# Restaurar
docker exec -i restore-test pg_restore \
  -U postgres \
  --dbname=postgres \
  --clean \
  --if-exists \
  < /tmp/restore-test.dump

# Verificar tablas
docker exec restore-test psql -U postgres -c \
  "SELECT schemaname, tablename FROM pg_tables WHERE schemaname = 'public';"

# Verificar Row Counts
docker exec restore-test psql -U postgres -c \
  "SELECT relname, n_live_tup FROM pg_stat_user_tables ORDER BY n_live_tup DESC LIMIT 10;"

# Limpiar
docker rm -f restore-test
rm /tmp/restore-test.dump

echo "Prueba de restore completada"
```

### Condición verificable

```bash
# Ejecutar el script de prueba de restore y verificar el exit code
./scripts/restore-test.sh /opt/backup-archive/db_latest.dump.gpg
echo $?
# Expectativa: 0

# Verificar el log de la última prueba de restore
cat /var/log/restore-test.log | tail -20
```

### Escenario de fallo

Muchos equipos tienen backups que llevan meses ejecutándose, pero nunca han probado un restore. Problemas típicos: formato incorrecto del `pg_dump` (texto plano en lugar de Custom), permisos faltantes durante el restore, versiones incompatibles de PostgreSQL entre backup y restore. Todo esto solo se descubre cuando realmente se necesita el restore.

## D3 - Verificaciones diarias de infraestructura

### Implementación

Un script en el audit-runner verifica diariamente el estado del sistema de producción.

```bash
#!/bin/bash
# scripts/security-check.sh (se ejecuta en audit-runner)

set -euo pipefail

PROD_HOST="10.0.1.10"
REPORT=""
CRITICAL=0

# 1. Estado de los contenedores
STOPPED=$(ssh deploy@${PROD_HOST} "docker compose ps --format json" | \
  jq -r 'select(.State != "running") | .Name')
if [ -n "$STOPPED" ]; then
  REPORT+="CRITICO: Contenedores no running: ${STOPPED}\n"
  CRITICAL=1
fi

# 2. Puertos abiertos desde el exterior
OPEN_PORTS=$(nmap -p 22,80,443,3000,5432,8000,9000 app.example.com \
  --open -oG - | grep "/open/" | grep -v "443/open")
if [ -n "$OPEN_PORTS" ]; then
  REPORT+="CRITICO: Puertos abiertos inesperados: ${OPEN_PORTS}\n"
  CRITICAL=1
fi

# 3. Fecha de expiración del certificado
CERT_EXPIRY=$(echo | openssl s_client -connect app.example.com:443 2>/dev/null | \
  openssl x509 -noout -enddate | cut -d= -f2)
CERT_EPOCH=$(date -d "$CERT_EXPIRY" +%s)
NOW_EPOCH=$(date +%s)
DAYS_LEFT=$(( (CERT_EPOCH - NOW_EPOCH) / 86400 ))
if [ "$DAYS_LEFT" -lt 14 ]; then
  REPORT+="AVISO: El certificado TLS expira en ${DAYS_LEFT} días\n"
fi

# 4. Drift del Firewall
FIREWALL_DIFF=$(ssh deploy@${PROD_HOST} "iptables-save" | \
  diff /opt/baselines/firewall-baseline.txt - || true)
if [ -n "$FIREWALL_DIFF" ]; then
  REPORT+="AVISO: El firewall ha cambiado:\n${FIREWALL_DIFF}\n"
fi

# 5. Versiones de las imágenes Docker (Drift contra Baseline)
IMAGE_DIFF=$(ssh deploy@${PROD_HOST} \
  "docker compose images --format '{{.Repository}}:{{.Tag}}'" | \
  diff /opt/baselines/image-versions.txt - || true)
if [ -n "$IMAGE_DIFF" ]; then
  REPORT+="AVISO: Las versiones de los contenedores han cambiado:\n${IMAGE_DIFF}\n"
fi

# 6. Espacio en disco
DISK_USAGE=$(ssh deploy@${PROD_HOST} "df -h / | tail -1 | awk '{print \$5}' | tr -d '%'")
if [ "$DISK_USAGE" -gt 85 ]; then
  REPORT+="AVISO: Uso de disco al ${DISK_USAGE}%\n"
fi

# 7. Estado de los backups
LAST_BACKUP=$(ssh deploy@${PROD_HOST} "ls -t /opt/backups/*.gpg 2>/dev/null | head -1")
if [ -z "$LAST_BACKUP" ]; then
  REPORT+="CRITICO: No se encontró ningún backup\n"
  CRITICAL=1
else
  BACKUP_AGE=$(ssh deploy@${PROD_HOST} \
    "echo \$(( (\$(date +%s) - \$(stat -c %Y ${LAST_BACKUP})) / 3600 ))")
  if [ "$BACKUP_AGE" -gt 26 ]; then
    REPORT+="AVISO: El último backup tiene ${BACKUP_AGE} horas de antigüedad\n"
  fi
fi

# 8. Verificación RLS
UNPROTECTED=$(ssh deploy@${PROD_HOST} "docker compose exec -T postgres psql -U postgres -t -c \
  \"SELECT count(*) FROM pg_tables WHERE schemaname = 'public' AND rowsecurity = false;\"" | tr -d ' ')
if [ "$UNPROTECTED" -gt 0 ]; then
  REPORT+="AVISO: ${UNPROTECTED} tablas sin RLS\n"
fi

# Resultado
echo "=== Security Check $(date) ==="
if [ -n "$REPORT" ]; then
  echo -e "$REPORT"
else
  echo "Todas las verificaciones superadas"
fi

# En caso de hallazgos críticos: enviar alerta
if [ "$CRITICAL" -eq 1 ]; then
  echo -e "$REPORT" | mail -s "CRITICO: Security Check $(date)" ops@example.com
fi
```

```bash
# Cron en el audit-runner
0 7 * * * /opt/audit/scripts/security-check.sh >> /var/log/security-check.log 2>&1
```

### Condición verificable

```bash
# ¿Se ejecutó el script de verificación hoy?
grep "$(date +%Y-%m-%d)" /var/log/security-check.log | tail -1
# Expectativa: entrada del día presente

# ¿Resultado?
grep "Todas las verificaciones superadas\|CRITICO\|AVISO" /var/log/security-check.log | tail -5
```

## D4 - Claude Code como capa de análisis contextual

Claude Code analiza los resultados de las verificaciones deterministas y reconoce correlaciones que los scripts no pueden ver.

### Arquitectura

```
Verificaciones diarias (D3)
     |
     +-- Hallazgos deterministas
     |   (puertos abiertos, drift del firewall, backups faltantes)
     |
     +---> Revisión semanal con Claude Code
          |
          +-- Archivos de config (docker-compose.yml, Caddyfile, .env.example)
          +-- Logs de Security Check de los últimos 7 días
          +-- Git Diff de los cambios de infraestructura
          +-- Exportación de RLS Policies
          |
          +---> Informe priorizado
               |
               +---> Decisión DevOps (humano)
```

### Script concreto

```bash
#!/bin/bash
# scripts/claude-review-prep.sh (se ejecuta en audit-runner)

REPORT_DIR="/opt/audit/weekly-reports"
DATE=$(date +%Y-%m-%d)
OUTPUT="${REPORT_DIR}/review-input-${DATE}.md"

mkdir -p "$REPORT_DIR"

cat > "$OUTPUT" << 'HEADER'
# Input para revisión de seguridad semanal

## Contexto
Stack Supabase self-hosted en Hetzner Cloud.
Arquitectura: Reverse Proxy -> Kong -> Supabase Services -> PostgreSQL
Sistema de auditoría en servidor separado.
HEADER

# Logs de Security Check de los últimos 7 días
echo -e "\n## Resultados de Security Check (últimos 7 días)\n" >> "$OUTPUT"
echo '```' >> "$OUTPUT"
grep -A 20 "Security Check" /var/log/security-check.log | \
  tail -100 >> "$OUTPUT"
echo '```' >> "$OUTPUT"

# Configuración actual de Docker Compose (sin Secrets)
echo -e "\n## docker-compose.yml actual\n" >> "$OUTPUT"
echo '```yaml' >> "$OUTPUT"
ssh deploy@10.0.1.10 "cat /opt/supabase/docker-compose.yml" >> "$OUTPUT"
echo '```' >> "$OUTPUT"

# Git Diff de la última semana
echo -e "\n## Cambios de infraestructura (últimos 7 días)\n" >> "$OUTPUT"
echo '```' >> "$OUTPUT"
ssh deploy@10.0.1.10 "cd /opt/supabase && git log --oneline --since='7 days ago'" >> "$OUTPUT"
ssh deploy@10.0.1.10 "cd /opt/supabase && git diff HEAD~5 --stat" >> "$OUTPUT" 2>/dev/null
echo '```' >> "$OUTPUT"

# Estado de RLS
echo -e "\n## Estado de RLS\n" >> "$OUTPUT"
echo '```' >> "$OUTPUT"
ssh deploy@10.0.1.10 "docker compose exec -T postgres psql -U postgres -c \"
  SELECT tablename, rowsecurity FROM pg_tables WHERE schemaname = 'public' ORDER BY tablename;
\"" >> "$OUTPUT"
echo '```' >> "$OUTPUT"

# Versiones de los contenedores
echo -e "\n## Versiones de los contenedores\n" >> "$OUTPUT"
echo '```' >> "$OUTPUT"
ssh deploy@10.0.1.10 "docker compose images --format '{{.Repository}}:{{.Tag}}'" >> "$OUTPUT"
echo '```' >> "$OUTPUT"

echo "Input para revisión creado: $OUTPUT"
```

### Lo que Claude Code no hace

```
Claude NO ejecuta cambios automáticos en producción.
Claude NO despliega.
Claude NO rota secrets.
Claude NO tiene acceso directo al servidor de producción.

Claude analiza los datos que se le proporcionan
y crea informes para decisiones humanas.
```

## Checklist de despliegue

Antes de la primera puesta en marcha y tras cambios importantes:

```
Parte A - Infraestructura
  [ ] Dos servidores separados (prod + audit)
  [ ] Red privada configurada y probada
  [ ] Cloud Firewall activo (solo 443, SSH desde IP de Admin)
  [ ] Host Firewall activo (iptables)
  [ ] Baseline del firewall guardada
  [ ] SSH: solo keys, sin root, sin contraseña
  [ ] Reverse Proxy configurado (Caddy/Nginx)
  [ ] TLS activo con renovación automática
  [ ] Cabeceras de seguridad configuradas (HSTS, CSP, X-Frame-Options)
  [ ] Proxy WebSocket configurado para Realtime

Parte B - Servicios de Supabase
  Secrets (B0)
    [ ] Todos los secrets generados (sin valores por defecto)
    [ ] JWT_SECRET al menos 32 caracteres
    [ ] POSTGRES_PASSWORD al menos 24 caracteres
    [ ] DASHBOARD_PASSWORD al menos 16 caracteres
    [ ] SECRET_KEY_BASE al menos 64 caracteres
    [ ] MINIO_ROOT_PASSWORD al menos 8 caracteres (si se usa MinIO)
    [ ] DB_ENC_KEY cambiado (no "supabaserealtime")
  PostgreSQL (B1)
    [ ] Puerto solo en interfaz interna (10.0.1.10:5432)
    [ ] Init-Scripts sin modificar (roles.sql, jwt.sql etc.)
    [ ] Roles creados correctamente (anon no es superuser)
  Kong (B2)
    [ ] Puerto solo en localhost (127.0.0.1:8000)
    [ ] JWT Validation activa en todas las rutas API
    [ ] Contraseña del dashboard fuerte
  GoTrue (B3)
    [ ] JWT_EXP máximo 3600
    [ ] AUTOCONFIRM false
    [ ] SMTP configurado y probado
    [ ] SITE_URL y API_EXTERNAL_URL correctos
    [ ] Refresh Token Rotation activo
    [ ] DISABLE_SIGNUP configurado si la app es cerrada
  PostgREST (B4)
    [ ] Usa rol authenticator (no postgres)
    [ ] DB_SCHEMAS definido explícitamente
  Realtime (B5)
    [ ] DB_ENC_KEY cambiado
    [ ] SECRET_KEY_BASE al menos 64 caracteres
  Storage / MinIO (B6)
    [ ] MinIO no accesible desde el exterior
    [ ] Credenciales por defecto de MinIO cambiadas
    [ ] Permisos del volumen de Storage correctos
  Servicios internos (B7)
    [ ] Puerto de Analytics solo localhost
    [ ] Docker Socket de Vector en Read-Only
    [ ] Puerto de Supavisor solo interno
    [ ] Tokens de Logflare no por defecto
  Studio (B8)
    [ ] Desactivado en producción O solo mediante SSH Tunnel
    [ ] Contraseña del dashboard fuerte

Parte C - Configuración del stack
  [ ] docker-compose.yml versionado en Git
  [ ] Todas las versiones de imágenes fijadas (sin :latest)
  [ ] .env no está en Git
  [ ] Permisos del archivo .env 600
  [ ] .env.example en Git como plantilla
  [ ] Sin contraseñas por defecto
  [ ] RLS activo en todas las tablas public
  [ ] Sin tablas sin Policies (excepto las intencionadas)
  [ ] Sin Policies demasiado abiertas (qual = 'true')

Parte D - Operación y monitorización
  [ ] Job de backup diario activo
  [ ] Backups cifrados
  [ ] Backups almacenados externamente (audit-runner o S3)
  [ ] Prueba de restore realizada al menos una vez
  [ ] Estrategia de retención configurada
  [ ] Job diario de Security Check en audit-runner
  [ ] Alertas ante hallazgos críticos
  [ ] Revisión semanal con Claude Code configurada

Parte E - Actualizaciones y mantenimiento
  [ ] Unattended Upgrades instalado y activo
  [ ] Intervalo de actualización automática configurado a diario
  [ ] Imágenes de Supabase fijadas (sin :latest)
  [ ] Ninguna imagen de Supabase con más de 90 días
  [ ] Commit de actualización dentro de los últimos 45 días
  [ ] Script auto-patch para PostgreSQL minor patches activo
  [ ] Cron auto-patch DESPUÉS del cron de backup (03:00 después de 02:00)
  [ ] Monitor de releases de seguridad en audit-runner activo (diario)
  [ ] Trivy instalado en audit-runner
  [ ] Cron de verificación de mantenimiento en audit-runner (semanal lunes)
  [ ] Certificado TLS válido al menos 14 días
  [ ] Uso de disco por debajo del 85%
```

## Parte E - Actualizaciones y mantenimiento

Un stack self-hosted que no se actualiza regularmente acumula vulnerabilidades de seguridad. CVEs sin parchear en PostgreSQL, Kong o GoTrue son vectores de ataque reales. Al mismo tiempo, las actualizaciones pueden introducir breaking changes que dejen el stack fuera de servicio.

Por eso el proceso de actualización necesita reglas claras: qué se actualiza y cuándo, cómo se prueba y cómo se garantiza que nada se olvide.

### E1 - Tres niveles de actualización

El stack tiene tres niveles de actualización independientes con ritmos y riesgos diferentes.

```
Nivel 1: OS-Level (Ubuntu)
   │  Qué: Kernel, System-Packages, OpenSSL, Docker Engine
   │  Ritmo: Parches de seguridad semanales, actualización completa mensual
   │  Riesgo: Bajo (apt upgrade es estable)
   │  Método: apt update && apt upgrade
   │
Nivel 2: Servicios Supabase (Docker Images)
   │  Qué: PostgreSQL, Kong, GoTrue, PostgREST, Realtime, Storage, etc.
   │  Ritmo: Mensual (ciclo de releases de Supabase)
   │  Riesgo: Medio a alto (breaking changes entre versiones)
   │  Método: Cambiar image tags en docker-compose.yml, pull, restart
   │
Nivel 3: Reverse Proxy y herramientas
   │  Qué: Caddy, iptables, GPG, nmap, jq
   │  Ritmo: Ante Security Advisories o trimestralmente
   │  Riesgo: Bajo
   │  Método: apt upgrade (Caddy a través de su propio repo)
```

**Condición verificable:**

```bash
# OS: ¿Cuándo fue el último apt upgrade?
stat -c %y /var/cache/apt/pkgcache.bin
# Expectativa: menos de 7 días de antigüedad

# Supabase: ¿Qué versiones de imagen están en ejecución?
cd /opt/supabase && docker compose images --format '{{.Repository}}:{{.Tag}}'

# Caddy Version
caddy version
```

**Escenario de fallo:** Un PostgreSQL sin parchear con una vulnerabilidad conocida de Remote Code Execution (como CVE-2023-5869) puede ser explotado por un atacante, incluso si RLS está configurado correctamente. Un Kong desactualizado con una vulnerabilidad conocida de Auth-Bypass puede eludir la validación JWT.

### E2 - Actualizaciones a nivel de OS

**Semanal: Parches de seguridad (automático)**

```bash
# Instalar y configurar Unattended Upgrades
sudo apt install -y unattended-upgrades

# Configuración: solo Security Updates automáticos
sudo tee /etc/apt/apt.conf.d/50unattended-upgrades > /dev/null << 'EOF'
Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
};

// Reinicio automático si es necesario (p. ej. Kernel Update)
// Solo activar si se acepta que el servidor
// reinicie brevemente a las 4:00 de la madrugada
Unattended-Upgrade::Automatic-Reboot "false";

// Notificación por email en caso de actualizaciones
Unattended-Upgrade::Mail "ops@example.com";
Unattended-Upgrade::MailReport "on-change";
EOF

# Activar actualizaciones automáticas
sudo tee /etc/apt/apt.conf.d/20auto-upgrades > /dev/null << 'EOF'
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::AutocleanInterval "7";
EOF

sudo systemctl enable unattended-upgrades
sudo systemctl start unattended-upgrades
```

**Mensual: Actualización completa del sistema (manual, con verificación)**

```bash
# Primero verificar qué se va a actualizar
apt list --upgradable

# Luego actualizar
sudo apt update && sudo apt upgrade -y

# Actualización de Docker Engine (por separado, a través del repo de Docker)
sudo apt install --only-upgrade docker-ce docker-ce-cli containerd.io

# Después de actualizaciones del kernel: ¿reinicio necesario?
if [ -f /var/run/reboot-required ]; then
  echo "REBOOT ERFORDERLICH"
fi
```

**Condición verificable:**

```bash
# ¿Unattended Upgrades activo?
systemctl is-active unattended-upgrades

# Últimas actualizaciones automáticas
cat /var/log/unattended-upgrades/unattended-upgrades.log | tail -20

# ¿Actualizaciones de seguridad pendientes?
apt list --upgradable 2>/dev/null | grep -i security | wc -l
# Expectativa: 0
```

### E3 - Actualizaciones de servicios Supabase

Supabase publica aproximadamente cada mes nuevas Docker Images. El proceso de actualización debe realizarse de forma controlada porque son posibles breaking changes entre versiones.

**Workflow:**

```
1. Leer Release Notes (github.com/supabase/supabase/releases)
2. Registrar nuevos image tags en docker-compose.yml
3. Probar en Staging/Test (o: Backup + plan de rollback)
4. Crear backup
5. docker compose pull
6. docker compose down && docker compose up -d
7. Verificar Health Checks
8. Actualizar baselines
```

**Verificar versiones actuales vs. disponibles:**

```bash
cd /opt/supabase

echo "=== Aktuelle Versionen ==="
docker compose images --format '{{.Repository}}:{{.Tag}}'

echo ""
echo "=== Verfügbare Updates ==="
# Die offiziellen Releases prüfen
echo "Supabase Releases: https://github.com/supabase/supabase/releases"
echo "GoTrue: https://github.com/supabase/gotrue/releases"
echo "PostgREST: https://github.com/PostgREST/postgrest/releases"
echo "Realtime: https://github.com/supabase/realtime/releases"
echo ""
echo "Oder den offiziellen docker-compose.yml vergleichen:"
echo "https://raw.githubusercontent.com/supabase/supabase/master/docker/docker-compose.yml"
```

**Proceso de actualización seguro:**

```bash
cd /opt/supabase

# 1. Backup VOR dem Update
./scripts/backup.sh

# 2. Aktuelle Versionen dokumentieren
docker compose images --format '{{.Repository}}:{{.Tag}}' > /opt/baselines/pre-update-versions.txt

# 3. Neue Versionen in docker-compose.yml eintragen
# MANUELL: Image Tags auf die neue Version ändern
# z.B. supabase/gotrue:v2.164.0 → supabase/gotrue:v2.184.0

# 4. Pull neue Images
docker compose pull

# 5. Stack neu starten
docker compose down
docker compose up -d

# 6. Warten und Health Checks
sleep 30
docker compose ps --format "table {{.Name}}\t{{.Status}}"

# 7. Alle Services prüfen
docker compose exec -T auth wget --no-verbose --tries=1 --spider http://localhost:9999/health
docker compose exec -T db pg_isready -U postgres -h localhost
curl -s -o /dev/null -w "Kong: %{http_code}\n" http://localhost:8000
curl -s -o /dev/null -w "Storage: %{http_code}\n" http://localhost:8000/storage/v1/

# 8. Baselines aktualisieren
docker compose images --format '{{.Repository}}:{{.Tag}}' > /opt/baselines/image-versions.txt

# 9. Git Commit
git add docker-compose.yml
git commit -m "Update Supabase images to [VERSION]"
```

**Rollback cuando algo falla:**

```bash
cd /opt/supabase

# Alte Versionen wiederherstellen
git checkout HEAD~1 -- docker-compose.yml
docker compose pull
docker compose down
docker compose up -d

# Wenn Datenbank-Migration das Problem ist:
./scripts/restore.sh /opt/backups/[LETZTES_BACKUP].gpg
```

**Condición verificable:**

```bash
# Image-Versionen älter als 3 Monate?
cd /opt/supabase
docker compose images --format '{{.Repository}}:{{.Tag}}' | while read image; do
  CREATED=$(docker inspect --format='{{.Created}}' "$image" 2>/dev/null | cut -dT -f1)
  if [ -n "$CREATED" ]; then
    AGE_DAYS=$(( ($(date +%s) - $(date -d "$CREATED" +%s)) / 86400 ))
    [ "$AGE_DAYS" -gt 90 ] && echo "WARNUNG: $image ist $AGE_DAYS Tage alt"
  fi
done
```

**Escenario de fallo:** Supabase GoTrue v2.170.0 tuvo un cambio en el manejo de Refresh Tokens que rompió clientes antiguos. Sin leer previamente las Release Notes y sin backup, esto habría sido una caída del servicio. Las actualizaciones de versiones mayores de PostgreSQL (p. ej. 15 -> 16) requieren un ciclo `pg_dump/pg_restore`, un simple cambio de image tag no es suficiente.

### E3b - Parcheado automático (Nivel 1)

No todas las actualizaciones requieren intervención humana. Los PostgreSQL Minor Patches y las actualizaciones de Caddy son de bajo riesgo y pueden aplicarse automáticamente por la noche.

**Modelo de dos niveles:**

```
NIVEL 1 - AUTOMÁTICO (auto-patch.sh, diario 03:00):
  OS Security Patches (unattended-upgrades)
  PostgreSQL Minor Patches (15.8.1.x -> 15.8.1.y)
  Caddy Updates
  -> Email informativo tras parcheado exitoso
  -> Email de alarma ante fallo en Health Check
  -> Rollback automático en caso de error

NIVEL 2 - MANUAL (/supabase-update, dentro de las 24h tras alerta):
  GoTrue/Auth (posibles breaking changes)
  PostgREST (el comportamiento de queries puede cambiar)
  Kong (el enrutamiento puede cambiar)
  Realtime, Storage, Supavisor
  PostgreSQL MAJOR (15 -> 16, requiere pg_dump/pg_restore)
```

El script `auto-patch.sh` se ejecuta diariamente a las 03:00 (después del backup a las 02:00) y:

1. Verifica que exista un backup actual (aborta si no)
2. Guarda el estado actual (docker-compose.yml, versiones de imágenes)
3. Comprueba si hay disponible una nueva imagen minor de PostgreSQL
4. La aplica y ejecuta un Health Check
5. En caso de error: rollback automático a la versión anterior
6. Envía un email informativo (éxito) o de alarma (error)

**Condición verificable:**

```bash
# Auto-Patch Cron aktiv?
crontab -l | grep auto-patch
# Erwartung: 0 3 * * * /opt/supabase/scripts/auto-patch.sh

# Letzter Auto-Patch Lauf?
tail -20 /var/log/auto-patch.log

# Hat Auto-Patch jemals gepatcht?
grep "Patches eingespielt\|Keine Patches" /var/log/auto-patch.log | tail -5
```

**Planificación cron (servidor prod):**

```
02:00 diario   -> Backup (DB + Storage + externo)
03:00 diario   -> Auto-Patch (PostgreSQL Minor + Caddy)
04:00 mensual  -> Test de restore
```

### E4 - Calendario de actualizaciones y responsabilidades

```
Semanal (automático):
  [ ] OS Security Patches (unattended-upgrades)
  [ ] Audit-Runner verifica que los parches se hayan aplicado

Mensual (manual, planificado):
  [ ] Revisar Supabase Release Notes
  [ ] Evaluar nuevos image tags
  [ ] Crear backup
  [ ] Ejecutar actualización
  [ ] Health Checks
  [ ] Actualizar baselines

Trimestral (review):
  [ ] Verificar versión de Caddy
  [ ] Verificar versión de Docker Engine
  [ ] Verificar versión de Node.js (para Claude Code en audit-runner)
  [ ] Evaluar versión mayor de PostgreSQL
  [ ] ¿Toda la toolchain al día?

Ante Security Advisories (inmediato):
  [ ] ¿El CVE afecta a nuestro stack?
  [ ] Identificar imagen/paquete afectado
  [ ] ¿Parche disponible?
  [ ] Ejecutar actualización de emergencia
```

**Condición verificable:**

```bash
# Wann war das letzte Supabase Update?
cd /opt/supabase
git log --oneline --grep="Update\|update\|upgrade" | head -5

# Wie alt ist der letzte Update-Commit?
LAST_UPDATE=$(git log --format="%ai" --grep="Update\|update" -1 2>/dev/null | cut -d' ' -f1)
if [ -n "$LAST_UPDATE" ]; then
  AGE=$(( ($(date +%s) - $(date -d "$LAST_UPDATE" +%s)) / 86400 ))
  echo "Letztes Update: $LAST_UPDATE ($AGE Tage her)"
  [ "$AGE" -gt 45 ] && echo "WARNUNG: Letztes Update über 45 Tage her"
fi
```

### E5 - Monitor de releases de seguridad (diario)

El mayor punto ciego del self-hosting no es la configuración inicial, sino el no detectar los parches de seguridad a tiempo. Cuando Supabase GoTrue publica un fix de Auth-Bypass, el equipo debe actuar en 24 horas, no al cabo de una semana.

En el audit-runner se ejecuta **diariamente** un script que comprueba los GitHub Releases de todos los componentes de Supabase y alerta inmediatamente por email ante releases de seguridad.

**Componentes verificados:**

```
supabase/auth (GoTrue)          -> parches de seguridad frecuentes
PostgREST/postgrest             -> API-Layer
supabase/realtime               -> WebSocket
supabase/storage-api            -> File Storage
Kong/kong                       -> API Gateway
supabase/edge-runtime           -> Edge Functions
supabase/postgres               -> Datenbank Image
supabase/supavisor              -> Connection Pooler
moby/moby (Docker Engine)       -> Container Runtime
```

**Tres capas de verificación:**

```
Capa 1: GitHub Releases
  -> ¿Hay una nueva versión?
  -> ¿Las Release Notes contienen "security"/"CVE"?

Capa 2: Trivy Container Scan
  -> Escanea cada Docker Image en ejecución contra NVD/GitHub Advisories
  -> Encuentra CVEs en todas las dependencias (OS-Packages, Libraries)

Capa 3: OSV API
  -> Verifica vulnerabilidades a nivel de aplicación para GoTrue, PostgREST, etc.
  -> Complementa Trivy con CVEs específicos de paquetes
```

**Cómo funciona:**

```
Diario 07:00 (audit-runner Cron)
   │
   ├── Obtener versiones actuales del servidor prod
   ├── GitHub API: Verificar últimos releases para cada componente
   ├── Escanear Release Notes buscando "security", "CVE", "vulnerability"
   │
   ├── ¿Release de seguridad encontrado?
   │     -> Email INMEDIATO a ops@
   │     -> "Acción requerida en 24h"
   │
   └── ¿Release normal encontrado?
         -> Resumen semanal (lunes)
```

**Mecanismo de caché:** El script recuerda los releases ya notificados para que no llegue el mismo email cada día. Solo se vuelve a alertar cuando hay un NUEVO release.

**Condición verificable:**

```bash
# Security Release Monitor aktiv auf audit-runner?
ssh deploy@10.0.1.11 "crontab -l | grep security-release"
# Erwartung: täglicher Cron Job

# Letzter Check-Log
ssh deploy@10.0.1.11 "tail -5 /var/log/security-releases.log"
# Erwartung: Eintrag von heute

# Cache vorhanden (Script hat schon gelaufen)?
ssh deploy@10.0.1.11 "ls /opt/audit/cache/*-last-seen.txt 2>/dev/null | wc -l"
```

**Escenario de fallo:** En enero de 2024 se publicó CVE-2023-5869 para PostgreSQL (Remote Code Execution). Quien no tuviese un monitor de releases y solo revisase actualizaciones mensualmente, estuvo vulnerable durante 3-4 semanas. Con el monitor diario, el email habría llegado al día siguiente de la publicación.

### E6 - Audit-Runner como vigilante de actualizaciones

El Audit-Runner supervisa si las actualizaciones se están realizando e informa al equipo cuando algo está vencido.

En el audit-runner se ejecuta un script semanal que verifica lo siguiente:

```bash
#!/bin/bash
# scripts/check-maintenance.sh (läuft auf audit-runner)

PROD_HOST="10.0.1.10"
REPORT=""

echo "=== Maintenance Check $(date) ==="

# 1. OS Updates überfällig?
LAST_APT=$(ssh deploy@${PROD_HOST} "stat -c %Y /var/cache/apt/pkgcache.bin")
APT_AGE=$(( ($(date +%s) - $LAST_APT) / 86400 ))
if [ "$APT_AGE" -gt 7 ]; then
  REPORT+="WARNUNG: apt update ist ${APT_AGE} Tage her (max. 7)\n"
fi

# 2. Unattended Upgrades aktiv?
UA_STATUS=$(ssh deploy@${PROD_HOST} "systemctl is-active unattended-upgrades 2>/dev/null")
if [ "$UA_STATUS" != "active" ]; then
  REPORT+="KRITISCH: Unattended Upgrades nicht aktiv\n"
fi

# 3. Ausstehende Security Updates?
SEC_UPDATES=$(ssh deploy@${PROD_HOST} "apt list --upgradable 2>/dev/null | grep -ci security")
if [ "$SEC_UPDATES" -gt 0 ]; then
  REPORT+="WARNUNG: ${SEC_UPDATES} ausstehende Security Updates\n"
fi

# 4. Reboot erforderlich?
REBOOT=$(ssh deploy@${PROD_HOST} "test -f /var/run/reboot-required && echo ja || echo nein")
if [ "$REBOOT" = "ja" ]; then
  REPORT+="WARNUNG: Server-Reboot erforderlich (Kernel Update)\n"
fi

# 5. Supabase Image Alter
ssh deploy@${PROD_HOST} "cd /opt/supabase && docker compose images --format '{{.Repository}}:{{.Tag}}'" | \
while read image; do
  CREATED=$(ssh deploy@${PROD_HOST} "docker inspect --format='{{.Created}}' '$image' 2>/dev/null" | cut -dT -f1)
  if [ -n "$CREATED" ]; then
    AGE_DAYS=$(( ($(date +%s) - $(date -d "$CREATED" +%s 2>/dev/null || echo 0)) / 86400 ))
    if [ "$AGE_DAYS" -gt 90 ]; then
      REPORT+="WARNUNG: $image ist ${AGE_DAYS} Tage alt (max. 90)\n"
    fi
  fi
done

# 6. Letztes Supabase Update?
LAST_UPDATE=$(ssh deploy@${PROD_HOST} "cd /opt/supabase && git log --format='%ai' --grep='Update\|update' -1 2>/dev/null" | cut -d' ' -f1)
if [ -n "$LAST_UPDATE" ]; then
  UPDATE_AGE=$(( ($(date +%s) - $(date -d "$LAST_UPDATE" +%s)) / 86400 ))
  if [ "$UPDATE_AGE" -gt 45 ]; then
    REPORT+="WARNUNG: Letztes Supabase Update vor ${UPDATE_AGE} Tagen (max. 45)\n"
  fi
else
  REPORT+="WARNUNG: Kein Update-Commit in Git gefunden\n"
fi

# 7. Docker Engine Version
DOCKER_VERSION=$(ssh deploy@${PROD_HOST} "docker version --format '{{.Server.Version}}' 2>/dev/null")
echo "Docker Engine: $DOCKER_VERSION"

# 8. Caddy Version
CADDY_VERSION=$(ssh deploy@${PROD_HOST} "caddy version 2>/dev/null")
echo "Caddy: $CADDY_VERSION"

# 9. TLS Zertifikat Restlaufzeit
CERT_DAYS=$(ssh deploy@${PROD_HOST} "echo | openssl s_client -connect localhost:443 2>/dev/null | openssl x509 -noout -enddate 2>/dev/null | cut -d= -f2")
if [ -n "$CERT_DAYS" ]; then
  DAYS_LEFT=$(( ($(date -d "$CERT_DAYS" +%s) - $(date +%s)) / 86400 ))
  [ "$DAYS_LEFT" -lt 14 ] && REPORT+="KRITISCH: TLS Zertifikat läuft in ${DAYS_LEFT} Tagen ab\n"
fi

# Ergebnis
if [ -n "$REPORT" ]; then
  echo -e "\n$REPORT"
  echo -e "$REPORT" | mail -s "Maintenance Check: Handlung nötig" ops@example.com
else
  echo "Alle Maintenance Checks bestanden"
fi
```

**Cron en el audit-runner:**

```bash
# Wöchentlich Montag 08:00 (nach dem Sonntag-Audit)
0 8 * * 1 /opt/audit/scripts/check-maintenance.sh >> /var/log/maintenance-check.log 2>&1
```

**Cuándo notifica Claude:**

Claude Code en el audit-runner envía notificaciones en tres casos:

```
INMEDIATO (email a ops@):
  - Unattended Upgrades no activo
  - Certificado TLS < 14 días
  - Actualización de seguridad pendiente y > 3 días de antigüedad

SEMANAL (informe de mantenimiento):
  - Reinicio necesario
  - apt update vencido
  - Imágenes Supabase > 60 días de antigüedad

MENSUAL (recordatorio de actualización):
  - Release Notes de Supabase no revisadas (sin commit de update > 45 días)
  - Review trimestral pendiente
```

## Conclusión

Alojar Supabase por cuenta propia es relativamente sencillo. **Operar Supabase de forma segura** requiere reglas de arquitectura claras y control automatizado.

Este runbook separa entre decisiones de infraestructura (Parte A), arquitectura y aseguramiento de servicios (Parte B), configuración del stack (Parte C), monitorización continua (Parte D) y procesos de actualización (Parte E). La combinación de verificaciones deterministas y análisis contextual con Claude Code cubre tanto patrones conocidos como riesgos inesperados.

Quien aplica estos principios desde el inicio construye una [arquitectura Cert-Ready by Design](/es/revista/cert-ready-by-design/) y se ahorra rondas de auditoría posteriores.

> **Recordatorio:** Las configuraciones específicas de Hetzner (vSwitch, Cloud Firewall, nombres de interfaz) se pueden trasladar directamente a proveedores españoles y europeos como Arsys/IONOS (ES), OVH (ES), Stackscale (ES) y Acens (ES). Los principios de arquitectura son independientes del proveedor.

<div class="not-prose my-12 border border-gosign-border bg-gosign-light rounded-card p-6 lg:p-8">
<div class="flex items-start gap-4">
<div class="flex-shrink-0 w-12 h-12 bg-gosign-dark rounded-card flex items-center justify-center">
<svg width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="white" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 15v4a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2v-4"/><polyline points="7 10 12 15 17 10"/><line x1="12" y1="15" x2="12" y2="3"/></svg>
</div>
<div>
<h2 class="text-h3 font-bold text-gosign-dark mb-2" id="descarga-de-la-lista-de-verificacion">Descarga de la lista de verificación</h2>
<p class="text-body text-gosign-text mb-2">Prompt preparado para Claude Code. Suba el archivo a su servidor e inicie Claude Code en el directorio del proyecto de su stack Supabase. Claude Code verificará automáticamente todos los puntos de seguridad de este runbook e informará APROBADO, ADVERTENCIA o CRÍTICO.</p>
<p class="text-sm text-gosign-text mb-4 font-mono">claude -p "$(cat claude-check-artikel-1-supabase-es.md)" --allowedTools Read,Grep,Glob,Bash</p>
<a href="/downloads/claude-check-artikel-1-supabase-es.md" download class="inline-flex items-center px-6 py-3 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-small uppercase tracking-wider">Descargar checklist</a>
</div>
</div>
</div>

## Índice de la serie

Este artículo forma parte de nuestra serie DevOps para app stacks self-hosted.

1. [Supabase Self-Hosting Runbook](/es/revista/supabase-self-hosting/) - este artículo
2. [Next.js sobre Supabase de forma segura](/es/revista/nextjs-supabase-configuracion-segura/)
3. [Supabase Edge Functions de forma segura](/es/revista/supabase-edge-functions-seguridad/)
4. [Trigger.dev Background Jobs en producción segura](/es/revista/trigger-dev-background-jobs/)
5. [Claude Code como control de seguridad en el workflow DevOps](/es/revista/claude-code-security-devops/)
6. [Security Baseline para todo el stack](/es/revista/security-baseline-stack/)

En el próximo artículo mostraremos cómo **operar Next.js de forma segura sobre Supabase**, evitando los errores típicos en Server Actions, Auth Handling y accesos a la API.

--- Automatizar gastos de viaje: Coste real por recibo ---
> 58 USD por recibo, 19% de errores, 52 USD por corrección. GBTA muestra: el procesamiento manual cuesta millones a las empresas - y es evitable.

## 58 USD por recibo - la cifra que nadie monitoriza

La mayoría de los departamentos financieros conocen sus gastos de viaje. Saben cuánto gasta la empresa anualmente en vuelos, hoteles y dietas. Lo que rara vez saben: ¿cuánto cuesta procesar un solo recibo de gastos de viaje?

La respuesta la aporta la GBTA Foundation en colaboración con HRS: 58 USD por transacción cuando se procesa manualmente. La tasa de error se sitúa en el 19 por ciento. El coste de corrección por error es de 52 USD (Fuente: GBTA Foundation / HRS, "Expense Reporting: Global Practices and Pain Points", 2015).

Estas tres cifras cambian la perspectiva. Los gastos de viaje no son solo una partida de gasto - son un problema de costes de proceso. Y en empresas con decenas de miles o cientos de miles de transacciones al año, ese problema se acumula hasta alcanzar cifras millonarias.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">De un vistazo - ROI de la automatización de gastos de viaje</p>
<ul class="text-body text-gosign-text space-y-2">
<li>El procesamiento manual cuesta 58 USD por recibo con un 19% de tasa de error y 52 USD por corrección (GBTA Foundation).</li>
<li>Con 100.000 transacciones al año, solo el procesamiento genera casi 7 millones USD - antes de los gastos de viaje reales.</li>
<li>OCR y flujos de aprobación resuelven la captura, no las 40 a 120 micro-decisiones por transacción (dietas, convenios colectivos, tratamiento fiscal).</li>
<li>El enfoque Decision Layer alcanza un 85 a 95% de procesamiento zero-touch mediante reglas versionadas y auditables para cada micro-decisión.</li>
<li>La amortización comienza a partir de 10.000 transacciones anuales; el mayor ahorro proviene de eliminar el bucle de corrección.</li>
</ul>
</div>

## La anatomía de los 58 dólares

### Costes visibles: captura y aprobación

El empleado fotografía el recibo, introduce los datos en SAP Concur o una herramienta comparable, asigna un centro de coste y envía. El responsable revisa, aprueba o rechaza. El administrativo del Shared Service Center verifica de nuevo, contrasta con la normativa interna y contabiliza.

Tres personas, tres pasos, un recibo. Esa es la parte visible de los 58 dólares.

### Costes ocultos: correcciones y consultas

Un 19 por ciento de tasa de error significa: casi una de cada cinco transacciones requiere reprocesamiento. Baremo de dietas incorrecto, deducción por manutención omitida, tarifa de convenio colectivo equivocada, centro de coste confundido. Cada corrección cuesta 52 USD - la transacción recorre todo el proceso una segunda vez.

A ello se añaden las consultas: el administrativo contacta al empleado porque faltan datos. El empleado busca un recibo de hace tres semanas. El responsable debe aprobar por segunda vez. Estos bucles consumen tiempo que no aparece en ninguna contabilidad de costes.

### Costes sistémicos: riesgo de auditoría y cumplimiento normativo

Cuando el 19 por ciento de las transacciones contiene errores y solo se revisan muestras, los errores sistemáticos se acumulan sin ser detectados. El riesgo se materializa durante la inspección fiscal: el inspector no pregunta por recibos individuales, sino por la sistemática. ¿Existe una lógica de decisión documentada? ¿Se puede trazar por qué esta dieta se calculó con este baremo?

En la mayoría de las empresas, la respuesta es no. La lógica de decisión reside en la cabeza del administrativo, no en el sistema. Eso no cumple los requisitos de documentación procedimental exigidos por la normativa fiscal y la RGPD - eso es un riesgo de auditoría.

## Proyección: lo que los gastos de viaje realmente cuestan a la empresa

### Escenario A: 10.000 transacciones al año (empresa de tamaño intermedio)

<div class="overflow-x-auto">

| Posición | Cálculo | Coste anual |
|----------|---------|-------------|
| Procesamiento | 10.000 x 58 USD | 580.000 USD |
| Correcciones | 10.000 x 19 % x 52 USD | 98.800 USD |
| **Total** | | **678.800 USD** |

</div>

Con 10.000 transacciones, el procesamiento de gastos de viaje ocupa el equivalente de 3 a 4 empleados a tiempo completo en el Shared Service Center. Solo los costes de corrección equivalen a medio FTE.

### Escenario B: 100.000 transacciones al año (gran empresa)

<div class="overflow-x-auto">

| Posición | Cálculo | Coste anual |
|----------|---------|-------------|
| Procesamiento | 100.000 x 58 USD | 5.800.000 USD |
| Correcciones | 100.000 x 19 % x 52 USD | 988.000 USD |
| **Total** | | **6.788.000 USD** |

</div>

Casi 7 millones de USD al año - solo por el procesamiento, no por los gastos de viaje en sí. Además: con 100.000 transacciones y un 19 por ciento de tasa de error, 19.000 transacciones son erróneas. Eso no es un riesgo residual, es un problema sistémico.

### Escenario C: 500.000+ transacciones al año (logística, aerolíneas)

<div class="overflow-x-auto">

| Posición | Cálculo | Coste anual |
|----------|---------|-------------|
| Procesamiento | 500.000 x 58 USD | 29.000.000 USD |
| Correcciones | 500.000 x 19 % x 52 USD | 4.940.000 USD |
| **Total** | | **33.940.000 USD** |

</div>

34 millones de USD en costes de procesamiento al año. En aerolíneas y empresas logísticas, donde cada empleado viaja inevitablemente (la tripulación vuela, los conductores conducen), esto no es opcional - estas transacciones son un subproducto del negocio principal.

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">eBook gratuito: IA en Finanzas</p>
<p class="text-body text-gosign-text mb-4">Compliance, auditores externos y Decision Layer - el manual de gobernanza para dirección financiera.</p>
<a href="/es/ebook/ia-finanzas-manual-gobernanza/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Descargar gratis</a>
</div>

## Por qué OCR y flujos de aprobación no son suficientes

La respuesta obvia al problema de costes: digitalización. OCR para la captura de recibos, workflows para la aprobación, apps para la presentación. Esto reduce el esfuerzo manual en la captura - pero no en la decisión.

OCR captura el recibo. Un workflow lo dirige a la persona correcta. Pero, ¿quién decide?:

- ¿Qué baremo de dietas aplica cuando el empleado ha estado en tres países?
- ¿Si el convenio colectivo sectorial prevalece sobre el baremo legal - y si es así, qué convenio?
- ¿Cómo deducir la manutención proporcionada cuando el hotel incluye desayuno pero el empleado no lo utilizó?
- ¿Si los gastos de representación son deducibles al 50 por ciento (España, regla general del Impuesto sobre Sociedades) o siguen reglas diferentes en otra jurisdicción?

Estos no son problemas de captura. Son problemas de aplicación de reglas. Y ningún sistema OCR ni ningún flujo de aprobación resuelve problemas de aplicación de reglas.

## La diferencia entre captura y governance

Lo que falta es la capa entre la captura de recibos y la contabilización: una capa de governance que documente, para cada transacción, qué regla se aplicó y por qué.

El [Decision Layer](/es/revista/decision-layer-explicado/) descompone cada transacción de gastos de viaje en sus micro-decisiones y define para cada paso: el conjunto de reglas aplicable, la jerarquía (legislación antes que convenio colectivo, convenio colectivo antes que política interna) y la documentación. La decisión no la toma una persona que actúa por experiencia, sino un conjunto de reglas versionado que es trazable, reproducible y [preparado para auditoría](/es/revista/cert-ready-by-design/).

Esto también cambia el modelo operativo: en lugar de presentar, aprobar y contabilizar (tres pasos manuales), la transacción se procesa automáticamente. El empleado ve el resultado y tiene derecho a formular objeción - el enfoque de veto. En lugar de revisar manualmente cada transacción, solo se gestionan las excepciones. Esa es la diferencia entre el 0 por ciento y el 85 al 95 por ciento de procesamiento zero-touch.

## Cuatro sectores, cuatro perfiles de ROI

El [Travel Decision Layer](/es/servicios/travel-decision-layer/) es aplicable a todos los sectores. La tasa de automatización varía por sector porque los datos de entrada están estructurados de forma diferente:

<div class="overflow-x-auto">

| Sector | Transacciones al año | Zero-Touch | Coste antes | Coste después | Ahorro |
|--------|---------------------|------------|-------------|---------------|--------|
| [Aviación](/es/servicios/travel-decision-layer/aviacion/) | 100k - 1M+ | 95 % | 58+ USD | < 10 USD | > 80 % |
| [Logística](/es/servicios/travel-decision-layer/logistica/) | 500k - 2M+ | 95 % | 58+ USD | < 5 USD | > 90 % |
| [Ventas](/es/servicios/travel-decision-layer/ventas/) | 120k+ | 90 % | 58+ USD | < 8 USD | > 85 % |
| [Consultoría](/es/servicios/travel-decision-layer/consultoria/) | 50k - 250k+ | 85 % | 58+ USD | < 10 USD | > 80 % |

</div>

Las tasas de zero-touch más altas se alcanzan en sectores con datos de entrada procesables por máquina: tracks GPS en logística, rotaciones de tripulación en aviación. Consultoría se sitúa en el 85 por ciento porque las semanas con múltiples mandatos pueden requerir asignación manual.

El factor decisivo para el [ROI](/es/revista/roi-inversiones-ia/) no es solo la reducción de coste por transacción, sino la eliminación del bucle de corrección: pasar del 19 por ciento de tasa de error a menos del 2 por ciento significa que los 52 USD de coste de corrección prácticamente desaparecen.

## El enfoque de veto: automatización sin perder el control

Una objeción habitual contra la automatización: "Perdemos el control." El enfoque de veto invierte la lógica.

Hoy: el empleado presenta. El responsable aprueba. El administrativo contabiliza. Tres pasos manuales, cada uno propenso a errores.

Con el Decision Layer: el sistema calcula la transacción automáticamente sobre la base de las reglas almacenadas. El empleado ve el resultado y puede formular objeción - dentro de un plazo definido. Sin objeción, la transacción se contabiliza automáticamente.

Esto no es menos control. Es más control - documentado, trazable, reproducible. En lugar de una aprobación subjetiva por parte de un responsable que puede no conocer el convenio colectivo en detalle, decide un conjunto de reglas que puede ser consultado por el [comité de empresa](/es/revista/comite-empresa-ia-codeterminacion/) conforme al Art. 64 del Estatuto de los Trabajadores y verificado por auditores externos.

## Cuándo compensa - y cuándo no

No toda empresa necesita un procesamiento de gastos de viaje completamente automatizado. La inversión compensa cuando se cumplen al menos dos de los siguientes criterios:

- **Volumen**: Más de 10.000 transacciones de gastos de viaje al año
- **Complejidad normativa**: Convenios colectivos sectoriales, operaciones multi-jurisdiccionales o reglas sectoriales específicas
- **Requisitos de auditoría**: Documentación procedimental preparada para inspección, conformidad con la RGPD y la LOPDGDD
- **Shared Service Center**: Procesamiento centralizado con calidad de proceso documentada

Cuando solo se procesan viajes nacionales sin convenios colectivos, SAP Concur o una herramienta comparable es suficiente. La capa de governance se vuelve relevante donde las reglas son lo bastante complejas como para que un administrativo cometa errores - precisamente donde las cifras de la GBTA despliegan todo su impacto.

Gosign implementa el [Travel Decision Layer](/es/servicios/travel-decision-layer/) de forma específica por sector - desde la evaluación, pasando por un piloto de 3 meses, hasta la operación productiva. En su [infraestructura](/es/servicios/infraestructura/), sin dependencia de SaaS externo, con acceso completo al código fuente.

--- Gastos de viaje corporativos: Límites de SAP Concur ---
> SAP Concur captura recibos - pero quién decide sobre convenios colectivos, dietas e IROP? Por qué las empresas necesitan más que una herramienta de gastos.

## SAP Concur es bueno - para lo que fue diseñado

SAP Concur es el software de gestión de gastos de viaje más utilizado en el mundo. Captura de recibos mediante app, flujos de aprobación, integración con sistemas SAP - para empresas con viajes nacionales estandarizados, funciona de forma fiable.

El problema empieza donde terminan los procesos estándar. En empresas con convenios colectivos sectoriales, viajes multi-jurisdiccionales y complejidad regulatoria sectorial, toda herramienta de captura pura alcanza sus límites - no solo Concur, sino también Circula, Rydoo o HR Works.

La razón: estas herramientas resuelven el problema de captura. No el problema de decisión.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">De un vistazo - Límites de SAP Concur en gastos de viaje corporativos</p>
<ul class="text-body text-gosign-text space-y-2">
<li>SAP Concur resuelve la captura de recibos, no las 40 a 120 micro-decisiones detrás de cada transacción (convenios colectivos, dietas multi-jurisdiccionales, recálculo IROP).</li>
<li>El procesamiento manual cuesta 58 USD por transacción con 19% de errores y 52 USD por corrección (GBTA Foundation) - con 100.000 transacciones de tripulación, son 6,8 millones USD al año.</li>
<li>Convenios colectivos, cruces de frontera multinacionales y operaciones irregulares quedan fuera del modelo de datos de toda herramienta estándar de gastos.</li>
<li>El Decision Layer actúa como capa de governance sobre SAP Concur - reglas versionadas, cálculo determinista, Audit Trail sin interrupciones.</li>
<li>Resultado: 95% procesamiento zero-touch, tasa de error inferior al 1%, coste por transacción inferior a 10 USD - sin sustituir ningún sistema existente.</li>
</ul>
</div>

## El problema de decisión: 40 a 120 micro-decisiones por transacción

Una liquidación de gastos de viaje no es una captura de recibos. Detrás de cada transacción hay entre 40 y 120 micro-decisiones:

- ¿Qué baremo de dietas aplica (baremos oficiales del Ministerio de Hacienda, vigentes a la fecha del viaje)?
- ¿Hay un convenio colectivo sectorial que prevalece sobre el baremo legal?
- ¿Cómo se calcula la deducción por manutención proporcionada (desayuno, almuerzo, cena)?
- ¿Qué centro de coste asume la transacción?
- ¿Cuál es el tratamiento fiscal (exento, tributación a tanto alzado, sujeto a retención)?
- ¿Qué ocurre ante un cambio de itinerario durante el viaje?

SAP Concur captura el recibo. Pero, ¿quién toma estas decisiones? En la mayoría de las empresas: un administrativo en el Shared Service Center, manualmente, transacción por transacción, sin lógica de decisión documentada.

Esto es caro. La GBTA Foundation cifra el coste medio por transacción de gastos de viaje procesada manualmente en 58 USD - con una tasa de error del 19 por ciento y un coste de corrección de 52 USD por error (Fuente: GBTA Foundation / HRS, "Expense Reporting: Global Practices and Pain Points", 2015).

## Donde las herramientas estándar de gastos alcanzan sus límites

### El convenio colectivo prevalece sobre la ley

Los baremos oficiales de dietas establecidos por el Ministerio de Hacienda son el mínimo legal. En España, las dietas exentas de tributación se rigen por el artículo 9 del Reglamento del IRPF, con importes diferenciados para desplazamientos nacionales e internacionales (26,67 EUR nacionales, 48,08 EUR internacionales por día completo, 2026). Muchos convenios colectivos sectoriales definen importes superiores - en algunos casos significativamente.

Un grupo de aviación con 10.000 tripulantes mantiene típicamente de 2 a 5 convenios colectivos paralelos: pilotos, tripulación de cabina, personal de tierra, mantenimiento. Cada convenio define sus propias dietas, sus propias reglas de deducción, sus propias excepciones para manutención proporcionada.

SAP Concur no contempla convenios colectivos. El software calcula con los baremos legales - o con un importe único aplicable a toda la empresa. El cálculo conforme al convenio colectivo de las dietas se realiza fuera de la herramienta: manualmente, en hojas de cálculo, o por administrativos del Shared Service Center que trasladan el resultado de vuelta al sistema a mano.

Esto no es solo ineficiente. Es propenso a errores. Cuando el administrativo aplica el convenio colectivo equivocado al grupo de tripulación 3, se generan errores sistemáticos que pasan inadvertidos en miles de transacciones - hasta la inspección fiscal.

### Multi-jurisdicción en una sola transacción

Un tripulante en una ruta europea toca de 3 a 5 países en un solo día. La dieta se rige por el país donde termina la jornada, o por la regla de medianoche en viajes de varios días. Las herramientas estándar de gastos calculan un país por viaje. Multi-jurisdicción dentro de una sola transacción - con cruces de frontera registrados al minuto - queda fuera de su modelo de datos.

Esto no afecta solo a las aerolíneas:

- **Logística**: Los conductores cruzan varias fronteras a diario. La dieta cambia en cada frontera y el cálculo debe ser preciso al minuto - especialmente en cruces de medianoche. A ello se añaden las obligaciones documentales del [Paquete de Movilidad de la UE](/es/servicios/travel-decision-layer/logistica/) (Directiva 2020/1057).
- **Ventas**: Los comerciales visitan clientes en varios países por semana. Lunes Lisboa, miércoles París, viernes Madrid - tres jurisdicciones, tres baremos de dietas, una transacción.
- **Consultoría**: Los consultores trabajan en mandatos rotativos. Un ritmo semanal con tres clientes en dos países genera requisitos de splitting que ninguna herramienta estándar puede resolver.

### Operaciones irregulares y cambios imprevistos

Del 10 al 20 por ciento de todos los vuelos se ven afectados por irregularidades - retrasos, desvíos, reposicionamientos de tripulación (Fuente: EUROCONTROL / US DOT BTS, 2024). Cada irregularidad modifica el cálculo de gastos de viaje: otra dieta por otro país de destino, otro derecho de alojamiento, otro centro de coste.

Ninguna herramienta estándar de gastos procesa automáticamente las operaciones irregulares (IROP). La corrección se realiza manualmente - si es que se detecta. Con 100.000 transacciones de tripulación al año y una tasa de IROP del 15 por ciento, eso supone 15.000 transacciones que requieren reprocesamiento manual. Cada una con el riesgo de que la propia corrección sea errónea.

### La brecha de governance

SAP Concur documenta lo que se presentó. No documenta por qué se tomó una decisión. Esa es la diferencia entre una herramienta de captura y una capa de governance.

Cuando el inspector fiscal pregunta: "¿Qué regla se aplicó para calcular esta dieta?" - Concur no tiene respuesta. El importe está en el sistema, la lógica de decisión no. Cuando el [comité de empresa](/es/governance/co-determination/) pregunta: "¿Cómo se toman las decisiones sobre gastos de viaje?" - la respuesta honesta en la mayoría de las empresas es: el administrativo decide por experiencia.

Eso no es un Audit Trail. Eso es dependencia de personas.

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">eBook gratuito: IA en Finanzas</p>
<p class="text-body text-gosign-text mb-4">Compliance, auditores externos y Decision Layer - el manual de gobernanza para dirección financiera.</p>
<a href="/es/ebook/ia-finanzas-manual-gobernanza/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Descargar gratis</a>
</div>

## Simulación: 100.000 transacciones de tripulación al año

### La situación de partida

Para un grupo de aviación con 100.000 transacciones de tripulación al año, los datos de la GBTA arrojan:

<div class="overflow-x-auto">

| Posición | Cálculo | Coste anual |
|----------|---------|-------------|
| Procesamiento | 100.000 x 58 USD | 5.800.000 USD |
| Correcciones | 100.000 x 19 % x 52 USD | 988.000 USD |
| **Total** | | **6.788.000 USD** |

</div>

No incluido: costes de tiempo de aprobadores (directivos revisando recibos en lugar de dirigir), colapso de fin de mes en contabilidad, riesgo de auditoría en inspecciones fiscales y frustración de los empleados por reembolsos tardíos.

### El enfoque Decision Layer

El [Travel Decision Layer](/es/servicios/travel-decision-layer/) descompone cada transacción de gastos de viaje en sus micro-decisiones y aplica para cada una reglas documentadas: legislación, convenio colectivo, normativa interna - en esa jerarquía, versionadas, trazables.

La aplicación de reglas es determinista. Ningún modelo de lenguaje estocástico decide sobre importes o tratamiento fiscal. La IA se emplea en la clasificación - identificar tipos de recibo, categorizar tipos de IROP, clasificar motivos de representación - pero el cálculo sigue reglas exactas. Para comprender en detalle cómo la arquitectura del [Decision Layer](/es/revista/decision-layer-explicado/) separa clasificación de cálculo, consulte nuestro artículo de referencia.

Para la [simulación de aviación](/es/servicios/travel-decision-layer/aviacion/), la comparación resulta así:

<div class="overflow-x-auto">

| Métrica | Manual | Con Decision Layer |
|---------|--------|-------------------|
| Coste por transacción | 58+ USD | < 10 USD |
| Tasa de error | 19 % | < 1 % |
| Tiempo de procesamiento | 5 - 12 días hábiles | Minutos |
| Tasa zero-touch | 0 % | 95 % |
| Preparación para auditoría | Reconstrucción manual | Generada automáticamente |
| Cambio de convenio colectivo | Semanas | < 24 horas |

</div>

Proyección con 100.000 transacciones: de 6,8 millones USD a menos de 1 millón USD al año. El ahorro no proviene de administrativos más baratos, sino de la eliminación de decisiones manuales.

### El flujo de decisión en detalle

Una sola transacción de tripulación recorre los siguientes pasos en el Decision Layer:

1. Ingesta de datos de rotación desde el sistema de planificación de tripulaciones
2. Determinación de la secuencia de países a partir de los datos de rotación
3. Consulta del baremo de dietas por país y día (baremos oficiales, vigentes a la fecha del viaje)
4. Verificación de la prevalencia del convenio colectivo (grupo de tripulación, periodo de vigencia)
5. Cálculo de deducción por manutención (desayuno, almuerzo, cena - por día)
6. Clasificación del tipo de IROP (asistida por IA) y recálculo de dietas
7. Validación de costes de hotel contra la política interna (límite por ciudad)
8. Asignación de centro de coste (rotación, flota, grupo de tripulación)
9. Determinación del tratamiento fiscal (exento, a tanto alzado, sujeto a retención)
10. Generación del registro de auditoría (firmado con SHA-256, append-only)

Cada uno de estos pasos es una decisión documentada con una base normativa trazable. Esa es la diferencia con un flujo de aprobación donde una persona pulsa "Aprobado" sin que la lógica de decisión quede registrada en el sistema. Este enfoque [Cert-Ready by Design](/es/revista/cert-ready-by-design/) garantiza que la preparación para auditoría sea estructural, no reconstruida.

## Cuatro sectores, cuatro niveles de complejidad

El Travel Decision Layer no se limita a la aviación. La arquitectura base - un motor de reglas determinista sobre micro-decisiones - funciona en todos los sectores con configuración específica:

<div class="overflow-x-auto">

| Sector | Transacciones al año | Zero-Touch | Complejidad principal |
|--------|---------------------|------------|----------------------|
| [Aviación](/es/servicios/travel-decision-layer/aviacion/) | 100k - 1M+ | 95 % | IROP + multi-convenio colectivo |
| [Logística](/es/servicios/travel-decision-layer/logistica/) | 500k - 2M+ | 95 % | Precisión GPS + Paquete de Movilidad UE |
| [Ventas](/es/servicios/travel-decision-layer/ventas/) | 120k+ | 90 % | Integración CRM + gastos de representación |
| [Consultoría](/es/servicios/travel-decision-layer/consultoria/) | 50k - 250k+ | 85 % | Split 3 vías (fiscal / cliente / interno) |

</div>

Las cuatro simulaciones parten de los mismos valores base de la GBTA (58 USD por transacción, 19 % de tasa de error) y muestran el potencial de optimización específico de cada sector. Las diferentes tasas de zero-touch reflejan la complejidad sectorial: logística y aviación alcanzan el 95 por ciento porque los datos de entrada (tracks GPS, rotaciones de tripulación) son procesables por máquina. Consultoría se sitúa en el 85 por ciento porque las semanas con múltiples mandatos pueden requerir asignación manual.

## Qué necesita una solución que complemente a SAP Concur

SAP Concur no necesita ser reemplazado. Lo que falta es la capa superior - la capa de governance que decide antes de que el recibo entre en el sistema:

1. **Motor de reglas nativo para convenios colectivos** - Los convenios colectivos no como parche, sino como concepto de primera clase. Configurable por grupo de empleados, con periodos de vigencia y jerarquía de prevalencia.
2. **Tablas de decisión versionadas** - Cada regla fechada, cada cambio trazable. Baremos oficiales de dietas, tarifas de convenios colectivos y políticas internas como changesets con fecha.
3. **Audit Trail sin interrupciones** - Cada micro-decisión firmada (SHA-256), almacenada en procedimiento append-only. Sin sobreescritura, sin borrado, completamente reproducible.
4. **Transparencia compatible con el [comité de empresa](/es/revista/comite-empresa-ia-codeterminacion/)** - El conjunto de reglas es consultable, la lógica de decisión trazable. Ninguna IA de caja negra decide sobre importes. Conforme a los derechos de información y consulta del comité de empresa establecidos en el Art. 64 del Estatuto de los Trabajadores, la transparencia del Decision Layer satisface los requisitos más exigentes.
5. **Integración con el ERP** - Sin sustitución de sistemas, sino alimentación de los sistemas ERP y de nómina existentes. El Decision Layer se sitúa entre la fuente de datos y el sistema de contabilización.
6. **Multi-jurisdicción por transacción** - No por viaje, sino por día, con cruces de frontera registrados al minuto.

Gosign implementa esta capa de governance como [Travel Decision Layer](/es/servicios/travel-decision-layer/) - configurado para su sector, en su [infraestructura](/es/servicios/infraestructura/), sin dependencia de SaaS externo.

--- Tres tipos de decisiones: Cuándo el humano, cuándo la IA ---
> No toda decisión necesita un humano. Y no toda debería dejarse a la IA. Un framework de asignación - con ejemplos concretos de RRHH.

## La pregunta que todo departamento de RRHH plantea

"¿Qué decisiones puede tomar la IA sola - y cuáles deben quedarse en manos humanas?"

Esta pregunta surge en cada conversación sobre IA en procesos de RRHH. Del comité de empresa, de la dirección, del departamento de compliance. Y la respuesta habitual - "la IA apoya, el humano decide" - es demasiado imprecisa para el uso productivo.

Porque en la práctica, un solo proceso de RRHH consiste en decenas de decisiones individuales. En el procesamiento de bajas por enfermedad, por ejemplo: ¿Está completo el documento? ¿Qué convenio colectivo aplica? ¿La duración supera el límite de continuación salarial? ¿Debe iniciarse un procedimiento de reintegración? ¿Quién es informado?

Algunas de estas decisiones necesitan un humano. Otras no. Y algunas conscientemente NO deberían recaer en un humano - porque la IA las toma demostrablemente mejor.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">De un vistazo - Tres tipos de decisiones</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Cada proceso de negocio se descompone en microdecisiones de tres tipos: decide el humano, aplica un reglamento o la IA decide de forma autónoma.</li>
<li>IA autónoma no es la categoría para lo trivial - es para decisiones donde consistencia, resistencia a la fatiga y exhaustividad superan a la discrecionalidad.</li>
<li>La IA supera al humano estructuralmente en tres dimensiones: resultados idénticos entre sedes, sin pérdida de calidad por fatiga, verificación completa de reglas cada vez.</li>
<li>Un solo proceso de RRHH como el de bajas por enfermedad contiene los tres tipos - el Decision Layer impone la asignación correcta por paso.</li>
<li>Este framework hace transparente la argumentación ante el comité: la IA decide donde la calidad lo exige, el humano donde la discrecionalidad lo exige.</li>
</ul>
</div>

[McKinsey Global Institute (2023)](https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/the-economic-potential-of-generative-ai-the-next-productivity-frontier) estima que entre el 60 y el 70 por ciento del tiempo de trabajo de hoy corresponde a actividades que podrían automatizarse con la tecnología de IA actual, pero solo las decisiones con reglas claras y baja discrecionalidad son aptas para la automatización completa.

## Tres tipos de decisiones

### Tipo 1: Decide el humano

Aquí un humano debe tomar la decisión final. El agent puede preparar, proponer, recopilar material - pero la decisión misma recae en el humano.

**Cuándo:** Discrecionalidad, riesgo de discriminación, obligación del comité de empresa, situaciones individuales.

**Ejemplo: Reintegración tras baja prolongada.** El agent tiene todos los datos: duración de la enfermedad, historial de reintegración, recomendaciones del médico laboral, puestos disponibles. Pero la decisión de qué modelo de reintegración es adecuado para esta persona concreta necesita un humano. Se trata de la situación individual, de empatía, de la conversación con la persona. El comité de empresa tiene derecho de participación. Y si la decisión es errónea, tiene consecuencias reales para una persona real.

**Qué hace el Decision Layer:** Fuerza Human-in-the-Loop. Técnicamente, no organizativamente. El agent no puede tomar esta decisión de forma autónoma - ni siquiera cuando su confidence es alto.

### Tipo 2: Decide el reglamento

Lógica determinista. Si condición X, resultado Y. Sin margen de interpretación.

**Cuándo:** Convenio colectivo, acuerdo de empresa, legislación fiscal, clasificación salarial, cálculo de plazos.

**Ejemplo: Clasificación en banda salarial.** Nuevo empleado, perfil de puesto disponible, convenio colectivo inequívoco. La clasificación resulta de los criterios del convenio. No es una decisión que requiera interpretación - es una aplicación de regla. El Decision Layer aplica la versión vigente y documenta el resultado.

**Qué hace el Decision Layer:** Asegura que se aplique la versión vigente. Cuando el convenio cambia, desde la fecha de entrada en vigor rige la nueva versión - automáticamente, sin necesidad de informar a 50 gestores en 12 sedes.

### Tipo 3: La IA decide autónomamente

Y aquí se pone interesante. Porque esta categoría suele contarse mal. La narrativa habitual: "En casos estándar sencillos, la IA también puede decidir sola." Suena a permiso para lo trivial.

La realidad es otra. Hay decisiones en las que la IA no solo es más rápida, sino **demostrablemente mejor** que un humano. No porque la IA sea más inteligente - sino porque no tiene tres debilidades estructurales del ser humano.

#### Ventaja 1: Consistencia entre sedes y personas

50 gestores en 12 sedes aplican el mismo convenio colectivo. Cada uno interpreta los casos límite ligeramente diferente. En Hamburgo se aprueba una solicitud de pago especial, en Múnich el mismo caso se rechaza. No es un problema de formación - es la varianza natural de las decisiones humanas ante reglas ambiguas.

Una IA que trabaja sobre un reglamento versionado decide de forma idéntica. Cada vez. En cada sede. A las 9 de la mañana y a las 4 de la tarde.

**Concretamente:** Verificación del plazo de continuación salarial. Mismo caso, misma regla, mismo resultado. Independientemente de qué gestor en qué sede tramita el caso.

#### Ventaja 2: Resistencia a la fatiga

Un recruiter evalúa de forma diferente el lunes por la mañana que el viernes por la tarde. Tras la candidatura número 50, la atención baja. El candidato anterior era especialmente fuerte - el siguiente parece más débil en comparación, aunque objetivamente cumple los requisitos (Anchoring-Bias). El recruiter acaba de recibir malas noticias - las tres evaluaciones siguientes son más severas (Affect Heuristic).

No son debilidades personales. Es cognición humana. Bien investigada, ampliamente demostrada y medible en todo proceso de decisión repetitivo.

Una IA evalúa la candidatura número 1 con el mismo cuidado que la número 200. No tiene un mal día.

**Concretamente:** Matching de requisitos en recruiting. Cada candidatura se verifica contra el mismo perfil de criterios. Sin influencia del orden de las candidaturas, de la hora del día ni del estado emocional del recruiter.

#### Ventaja 3: Exhaustividad en la verificación de reglas

Esta es la ventaja más subestimada.

Un gestor de RRHH verifica una baja contra tres o cuatro criterios que le vienen a la mente: duración de la enfermedad, plazo de continuación salarial, quizá el umbral de reintegración. ¿Pero verifica también la regulación del período de carencia? ¿La regla especial para trabajadores a tiempo parcial del convenio de empresa? ¿La obligación de notificación a la mutua ante determinados cuadros clínicos? ¿El caso especial en accidentes laborales? ¿La regulación para contratos temporales?

¿Cada vez? ¿También el viernes a las 4? ¿También cuando tramita cinco casos en paralelo?

Una IA verifica contra todas las reglas vigentes, en la versión actual, de forma completa y documentada. No porque sea más inteligente - sino porque no olvida. Y porque su reglamento no reside en cabezas, sino en el sistema versionado.

**Concretamente:** Procesamiento de bajas. El agent verifica cada baja contra los 12 criterios relevantes del convenio colectivo, acuerdo de empresa y legislación. Cada vez. El resultado: menos errores que solo se descubren en la siguiente auditoría.

## Por qué un solo proceso contiene los tres tipos

El framework se vuelve útil cuando se entiende: un solo proceso de RRHH casi siempre contiene TODOS los tres tipos de decisiones.

Tomemos el procesamiento de bajas como ejemplo continuo:

| Paso | Tipo de decisión | Por qué |
|---|---|---|
| Recepción y validación de datos de baja | **IA autónoma** | Clasificación de documentos, alta precisión, entrada estructurada |
| Cotejo con datos de personal | Reglamento | Determinista, sin interpretación |
| Verificación del plazo de continuación salarial | **IA autónoma** | Verifica contra TODOS los criterios del convenio, más consistente que cualquier gestor |
| Verificación de obligación de reintegración (> 6 semanas en 12 meses) | Humano | Riesgo de discriminación con datos de salud, consulta previa del comité de empresa |
| Informar al superior | **IA autónoma** | Información consistente, sin olvidos, sin margen de interpretación sobre QUÉ se comunica (solo ausencia y duración, sin diagnóstico) |
| Iniciar medidas de reintegración | Humano | Situación individual, discrecionalidad, participación del comité |

Observen la tercera fila: "Verificación del plazo de continuación salarial" está en "IA autónoma", no en "Reglamento". ¿Por qué? Porque la IA aquí no aplica una simple lógica si-entonces, sino que realiza la verificación COMPLETAMENTE contra todos los reglamentos vigentes - algo que un humano en la práctica nunca hace de forma completa, porque no tiene todas las regulaciones especiales en la cabeza.

Este es el punto decisivo: "IA autónoma" no es la categoría para lo trivial. Es la categoría para decisiones en las que consistencia, resistencia a la fatiga y exhaustividad son más importantes que la discrecionalidad.

## Qué significa esto para el comité de empresa

El comité de empresa suele ser escéptico ante la autonomía de la IA. Con razón - cuando no está claro POR QUÉ la IA decide autónomamente.

Con el framework de tres tipos, la argumentación se vuelve transparente:

"La IA decide autónomamente en la verificación de plazos. No porque queramos ahorrar puestos. Sino porque sabemos que 50 gestores en 12 sedes calculan el mismo plazo de forma diferente. La IA calcula siempre correctamente. Y cuando no está segura, escala a un humano. Eso es trazable, documentado y visible en todo momento en el portal del auditor."

Es un argumento que el comité de empresa entiende. No se trata de sustitución, sino de aseguramiento de calidad.

## El Decision Layer hace operativa la asignación

El framework queda en teoría si no se impone técnicamente. El [Decision Layer](/es/decision-layer/) implementa la asignación de tres tipos para cada paso del proceso:

Para cada microdecisión está definido: humano, reglamento o IA. En las decisiones de IA está documentado por qué la IA es la elección correcta. En las decisiones humanas, Human-in-the-Loop está forzado técnicamente. En las decisiones por reglamento está depositada la versión vigente. Cada decisión - independientemente del tipo - genera un acta de decisión: input, regla de negocio con su versión, confianza, resultado, vía de impugnación. Esa es la base de la impugnabilidad conforme al art. 86 del EU AI Act.

> [Decision Layer - resumen y ejemplos](/es/decision-layer/)

> [Acta de decisión: por qué toda decisión de IA debe ser impugnable](/es/revista/acta-de-decision-decisiones-ia-impugnables/)

> [Por qué fracasan los proyectos de IA en RRHH](/es/revista/por-que-fracasan-proyectos-ia-rrhh/)

<a href="/es/contacto/" target="_blank" rel="noopener noreferrer">Agendar reunión</a> - Le mostramos en su proceso concreto qué decisiones quedan en manos humanas y cuáles la IA toma mejor.

--- Trigger.dev Background Jobs de forma segura ---
> Runbook DevOps para Trigger.dev v3: setup self-hosted, definición de tareas, idempotencia, concurrency, secrets e integración con Claude Code.

En cuanto una aplicación va más allá de simples operaciones CRUD, surgen tareas que **no deben ejecutarse de forma síncrona en el ciclo request-response**: envío de correos electrónicos, procesamiento de webhooks, trabajos de importación/exportación, tareas de IA, generación de PDF, migración de datos y tareas periódicas.

Estas tareas **no pertenecen a las Next.js Server Actions** (bloquean el servidor web), **no a las Supabase Edge Functions** (límite de timeout, no admiten procesos de larga duración) y tampoco a los cron jobs en el servidor (sin lógica de reintentos, sin monitorización).

Pertenecen a una **capa de jobs dedicada**. En nuestro stack, **Trigger.dev** asume este rol.

Este runbook describe cómo operar Trigger.dev de forma segura en el stack. Cada paso contiene una implementación concreta con la API actual de Trigger.dev v3, una condición verificable y un escenario de fallo.

> **Nota sobre la arquitectura:** Trigger.dev consta de dos partes: la **Platform** (Webapp, Dashboard, Queue Management) y el **Worker** (ejecuta las tareas). Nosotros operamos ambos self-hosted en nuestra propia infraestructura. Este runbook describe exclusivamente el setup self-hosted con Trigger.dev v3.


<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">De un vistazo - Artículo 4 de 6 de la serie DevOps Runbook</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Trigger.dev como stack Docker separado con su propio PostgreSQL</li>
<li>Cada task necesita maxDuration, concurrencyLimit y configuración de retry</li>
<li>Claves de idempotencia en llamadas API externas</li>
<li>Acceso a base de datos limitado a campos necesarios</li>
<li>Logger de Trigger.dev en lugar de console.log</li>
</ul>
</div>

## Índice de la serie

Esta guía forma parte de nuestra serie de runbooks DevOps para app stacks self-hosted.

1. [Supabase Self-Hosting Runbook](/es/revista/supabase-self-hosting/)
2. [Next.js sobre Supabase de forma segura](/es/revista/nextjs-supabase-configuracion-segura/)
3. [Supabase Edge Functions de forma segura](/es/revista/supabase-edge-functions-seguridad/)
4. [Trigger.dev Background Jobs de forma segura](/es/revista/trigger-dev-background-jobs/) - este artículo
5. [Claude Code como control de seguridad en el workflow DevOps](/es/revista/claude-code-security-devops/)
6. [Security Baseline para todo el stack](/es/revista/security-baseline-stack/)

El artículo 1 describe la plataforma. El artículo 2 describe la capa de aplicación. El artículo 3 describe las integraciones. Este artículo describe el **procesamiento asíncrono de jobs**.

## Visión general de la arquitectura

```
Browser
   |
Next.js (capa de aplicación)
   |
   +-- tasks.trigger("send-email", payload)    <- iniciar job
   |
Trigger.dev Platform
   |
   +-- Queue Management
   +-- Retry Logic
   +-- Dashboard / Monitoring
   |
Trigger.dev Worker
   |
   +-- send-email.ts           -> SMTP API
   +-- generate-report.ts      -> PDF + Supabase Storage
   +-- process-webhook.ts      -> Supabase DB (service_role)
   +-- sync-crm.ts             -> externe CRM API
   |
   +-- Supabase (via service_role oder direkte DB Connection)
       |
       PostgreSQL
```

Reglas fundamentales:

```
User Request       -> Next.js Server Action / Route Handler
Kurzer Event       -> Supabase Edge Function
Langläufer         -> Trigger.dev Task
Periodisch         -> Trigger.dev Scheduled Task
```

### Punto de seguridad crítico

Las tareas de Trigger.dev tienen típicamente **acceso completo a la base de datos sin RLS**. Se conectan mediante la clave `service_role` (a través del Supabase Client) o mediante una conexión directa a PostgreSQL (a través de `DATABASE_URL`). En ambos casos, las políticas de Row Level Security no se aplican. Esta es la diferencia más importante respecto a las solicitudes que pasan por PostgREST con la clave `anon`.

Quien conozca los [fundamentos de la gestión de secrets](/es/revista/seguridad-datos-ia-enterprise/) entenderá por qué esta separación es esencial.


### Guía de configuración de tasks

| Tipo de task | maxDuration | concurrencyLimit | Estrategia de Retry |
|---|---|---|---|
| Envío de email | 30s | 5-10 | 3 intentos, exponential backoff |
| Generación de PDF | 120s | 2-3 | 2 intentos, intervalo fijo |
| Inferencia AI (LLM) | 300s | 1-3 | 2 intentos, exponential backoff |
| Migración de datos | 600s | 1 | 1 intento, manejo manual |
| Procesamiento de webhooks | 30s | 10 | 3 intentos, exponential backoff |


## Parte A - Decisiones de arquitectura

## A1 - Operar Trigger.dev v3 self-hosted como servicio independiente

### Implementación

Trigger.dev se ejecuta separado de Next.js y Supabase como su propio stack Docker. La arquitectura self-hosted v3 consta de tres componentes:

```
Next.js App (vuestro servidor Hetzner / OVH / Scaleway)
   |
   +-- Trigger.dev Platform (Webapp + Queue + Dashboard)
           |
           +-- Trigger.dev Worker (führt eure Tasks aus)
           |
           +-- Trigger.dev PostgreSQL (eigene DB-Instanz)
```

```yaml
# docker-compose.trigger.yml
services:
  trigger-platform:
    image: ghcr.io/triggerdotdev/trigger.dev:v3    # Version pinnen
    restart: unless-stopped
    ports:
      - "127.0.0.1:3040:3040"        # NUR localhost, Reverse Proxy davor
    environment:
      DATABASE_URL: postgresql://postgres:${TRIGGER_DB_PASSWORD}@trigger-db:5433/trigger
      DIRECT_URL: postgresql://postgres:${TRIGGER_DB_PASSWORD}@trigger-db:5433/trigger
      LOGIN_ORIGIN: https://trigger.example.com
      APP_ORIGIN: https://trigger.example.com
      MAGIC_LINK_SECRET: ${MAGIC_LINK_SECRET}
      SESSION_SECRET: ${SESSION_SECRET}
      ENCRYPTION_KEY: ${ENCRYPTION_KEY}
      RUNTIME_PLATFORM: docker-compose
      # Worker-Konfiguration
      DOCKER_SOCKET_LOCATION: /var/run/docker.sock
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock   # Worker-Management
    depends_on:
      trigger-db:
        condition: service_healthy
    networks:
      - trigger-internal

  trigger-db:
    image: postgres:15
    restart: unless-stopped
    ports:
      - "127.0.0.1:5433:5432"        # Port 5433, NICHT 5432 (Supabase nutzt 5432)
    environment:
      POSTGRES_PASSWORD: ${TRIGGER_DB_PASSWORD}
      POSTGRES_DB: trigger
    volumes:
      - trigger-db-data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 10s
      timeout: 5s
      retries: 5
    networks:
      - trigger-internal

volumes:
  trigger-db-data:

networks:
  trigger-internal:
    driver: bridge
```

**Importante:** Trigger.dev necesita su **propia instancia de PostgreSQL** en el puerto 5433. No se debe compartir la base de datos de Supabase (puerto 5432). Trigger.dev almacena el estado de la cola, el historial de ejecuciones, el estado de los workers y los metadatos en su base de datos. Son datos diferentes a los datos de la aplicación.

**Configurar el SDK en el proyecto Next.js:**

```bash
# Trigger.dev SDK installieren
npm install @trigger.dev/sdk@3

# .env (Next.js)
TRIGGER_SECRET_KEY=tr_dev_...              # aus dem self-hosted Dashboard
TRIGGER_API_URL=http://localhost:3040      # lokale Platform URL
```

**Despliegue del Worker:**

En el setup self-hosted v3, las tareas se despliegan a través de la CLI, que se comunica con la Platform local:

```bash
# Tasks deployen (zeigt auf eure self-hosted Platform)
npx trigger.dev@latest deploy --self-hosted

# Lokale Entwicklung
npx trigger.dev@latest dev
```

> **Nota:** El Worker v3 de Docker utiliza Docker-in-Docker (Socket Mounting). Esto significa que la Platform de Trigger.dev necesita acceso al Docker Socket (`/var/run/docker.sock`). Esto tiene implicaciones de seguridad: un contenedor de Trigger.dev comprometido podría iniciar contenedores Docker arbitrarios. Por eso, lo ideal es que Trigger.dev se ejecute en un servidor propio o en una red Docker aislada.

### Condición verificable

```bash
# Container laufen?
docker compose -f docker-compose.trigger.yml ps
# Erwartung: trigger-platform und trigger-db running

# Platform erreichbar (intern)?
curl -s -o /dev/null -w "%{http_code}" http://localhost:3040
# Erwartung: 200 oder 302 (Redirect zu Login)

# Platform von außen NICHT direkt erreichbar?
curl -s -o /dev/null -w "%{http_code}" https://trigger.example.com:3040
# Erwartung: Connection refused (nur über Reverse Proxy)

# Trigger.dev DB auf eigenem Port?
ss -tlnp | grep 5433
# Erwartung: Listening auf 127.0.0.1:5433

# Supabase DB auf anderem Port?
ss -tlnp | grep 5432
# Erwartung: Listening auf 10.0.1.10:5432 (internes Interface)

# Docker Socket gemountet?
docker compose -f docker-compose.trigger.yml exec trigger-platform ls -la /var/run/docker.sock
# Erwartung: Socket vorhanden
```

### Escenario de fallo

Si Trigger.dev se ejecuta en el mismo proceso que Next.js, las tareas de larga duración bloquean el servidor web. Una tarea de IA que necesita 5 minutos ocupa un hilo de worker de Next.js. Con pocos hilos de worker (por defecto: 1 por CPU), toda la aplicación deja de responder para los usuarios. Si Trigger.dev comparte la base de datos de Supabase, las consultas de la cola de jobs compiten con las solicitudes de los usuarios por las conexiones de la base de datos. Si el Docker Socket se monta sin aislamiento de red, una tarea comprometida puede iniciar contenedores que accedan a la red del host.

## A2 - Controlar el acceso a la base de datos desde las tareas

### Implementación

Las tareas necesitan acceso a los datos de la aplicación en Supabase. Hay dos formas:

**Opción 1: Supabase Client con service_role (recomendado)**

```typescript
// trigger/lib/supabase.ts
import { createClient } from '@supabase/supabase-js'

export function createTaskClient() {
  return createClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.SUPABASE_SERVICE_ROLE_KEY!
  )
}
```

Ventaja: Pasa por PostgREST, utiliza la capa API de Supabase.
Desventaja: Omite RLS (service_role).

**Opción 2: Conexión directa a la BD (para consultas complejas)**

```typescript
// trigger/lib/db.ts
import postgres from 'postgres'

const sql = postgres(process.env.DATABASE_URL!, {
  max: 5,                    // Connection Pool limitieren
  idle_timeout: 20,
  connect_timeout: 10,
})

export { sql }
```

Desventaja: Omite tanto RLS como PostgREST. Acceso completo a la base de datos.

**Regla:** Independientemente de la opción, la tarea tiene más permisos que una solicitud normal de usuario. Por eso, cada tarea debe definir claramente su propio alcance.

```typescript
// RICHTIG: Task greift nur auf das zu, was er braucht
const { data } = await supabase
  .from('invoices')
  .select('id, amount, user_id')
  .eq('id', payload.invoiceId)
  .single()

// FALSCH: Task liest alle Daten einer Tabelle
const { data } = await supabase
  .from('invoices')
  .select('*')
```

Quien conozca los [patrones RLS del Runbook de Supabase Self-Hosting](/es/revista/supabase-self-hosting/) entenderá por qué la diferencia de alcance es crítica.

### Condición verificable

```bash
# Welche Tasks nutzen service_role oder DATABASE_URL?
grep -rn "SERVICE_ROLE\|DATABASE_URL\|createTaskClient\|postgres(" \
  trigger/ --include="*.ts"

# Für jeden Treffer manuell prüfen:
# - Greift der Task nur auf die Daten zu, die er braucht?
# - Ist der Input validiert bevor er in die Query fließt?
# - Gibt es einen Grund für direkten DB-Zugriff statt Supabase Client?
```

### Escenario de fallo

Una tarea con acceso directo a la base de datos e input no validado puede conducir a SQL injection. Una tarea que ejecuta `SELECT *` sobre tablas grandes puede afectar el rendimiento de la base de datos para todos los usuarios. Un pool de conexiones sin control (sin límite `max`) puede ocupar todas las conexiones disponibles de PostgreSQL y paralizar toda la aplicación.

## Parte B - Verificaciones de implementación

Estas reglas se aplican a cada tarea y deben comprobarse en cada despliegue.

## B1 - Definir tareas correctamente (API v3)

### Implementación

Trigger.dev v3 utiliza la función `task()` de `@trigger.dev/sdk/v3`. Cada tarea se exporta y tiene un ID único.

```typescript
// trigger/tasks/send-welcome-email.ts
import { task } from '@trigger.dev/sdk/v3'
import { z } from 'zod'
import { createTaskClient } from '../lib/supabase'

// 1. Payload Schema definieren
const payloadSchema = z.object({
  userId: z.string().uuid(),
  email: z.string().email(),
})

export const sendWelcomeEmail = task({
  id: 'send-welcome-email',

  // 2. Retry-Strategie
  retry: {
    maxAttempts: 3,
    factor: 2,
    minTimeoutInMs: 1_000,
    maxTimeoutInMs: 30_000,
  },

  // 3. Concurrency begrenzen
  queue: {
    concurrencyLimit: 5,
  },

  // 4. Maximum Laufzeit
  maxDuration: 60,   // 60 Sekunden

  // 5. Run-Funktion
  run: async (payload) => {
    // Input validieren
    const parsed = payloadSchema.safeParse(payload)
    if (!parsed.success) {
      throw new Error(`Invalid payload: ${parsed.error.message}`)
    }

    const { userId, email } = parsed.data
    const supabase = createTaskClient()

    // User-Daten holen (nur was nötig ist)
    const { data: user } = await supabase
      .from('profiles')
      .select('full_name, locale')
      .eq('id', userId)
      .single()

    if (!user) {
      throw new Error(`User not found: ${userId}`)
    }

    // E-Mail senden
    const response = await fetch('https://api.sendgrid.com/v3/mail/send', {
      method: 'POST',
      headers: {
        'Authorization': `Bearer ${process.env.SENDGRID_API_KEY}`,
        'Content-Type': 'application/json',
      },
      body: JSON.stringify({
        personalizations: [{ to: [{ email }] }],
        from: { email: 'hello@example.com' },
        subject: `Willkommen, ${user.full_name}!`,
        content: [{ type: 'text/plain', value: `...` }],
      }),
    })

    if (!response.ok) {
      // Fehler werfen, damit Retry greift
      throw new Error(`SendGrid error: ${response.status}`)
    }

    // Status in DB aktualisieren
    await supabase
      .from('profiles')
      .update({ welcome_email_sent: true })
      .eq('id', userId)

    return { success: true, userId }
  },
})
```

### Disparar la tarea desde Next.js

```typescript
// app/actions/auth.ts
'use server'

import { tasks } from '@trigger.dev/sdk/v3'
import type { sendWelcomeEmail } from '@/trigger/tasks/send-welcome-email'

export async function onUserSignup(userId: string, email: string) {
  // Task triggern (kehrt sofort zurück)
  const handle = await tasks.trigger<typeof sendWelcomeEmail>(
    'send-welcome-email',
    { userId, email }
  )

  // handle.id enthält die Run-ID für Tracking
  return { triggered: true, runId: handle.id }
}
```

### Condición verificable

```bash
# Alle Tasks müssen exportiert sein
for file in trigger/tasks/*.ts; do
  if ! grep -q "export const" "$file"; then
    echo "WARNUNG: $file hat keinen exportierten Task"
  fi
done

# Alle Tasks müssen eine ID haben
grep -rn "id:" trigger/tasks/ --include="*.ts" | grep "task({" -A1

# Tasks dürfen NICHT aus Client-Code getriggert werden
grep -rn "tasks.trigger\|\.trigger(" app/ --include="*.tsx" | grep -v "use server"
# Erwartung: keine Treffer (nur in Server-Kontext)
```

### Escenario de fallo

Una tarea sin `export` no es reconocida por Trigger.dev y desaparece durante el despliegue sin mensaje de error. Una tarea sin configuración de `retry` utiliza el valor por defecto (sin reintentos), de modo que un error temporal de la API (por ejemplo, un timeout de SendGrid) provoca la pérdida permanente del correo electrónico.

## B2 - Garantizar la idempotencia

### Implementación

Trigger.dev tiene un sistema de idempotencia integrado a través de `idempotencyKey`. Es preferible al chequeo `findUnique` implementado manualmente.

**Al disparar (evita la ejecución duplicada):**

```typescript
// Wenn derselbe User zweimal schnell "Signup" klickt,
// wird der Task nur einmal ausgeführt
await tasks.trigger<typeof sendWelcomeEmail>(
  'send-welcome-email',
  { userId, email },
  {
    idempotencyKey: `welcome-email-${userId}`,
    idempotencyKeyTTL: '24h',     // Key gilt 24 Stunden
  }
)
```

**Dentro de la tarea (evita efectos secundarios duplicados en reintentos):**

```typescript
import { task, idempotencyKeys } from '@trigger.dev/sdk/v3'

export const processPayment = task({
  id: 'process-payment',
  retry: { maxAttempts: 3 },

  run: async (payload: { orderId: string; amount: number }) => {
    // Idempotency Key für den Stripe-Call
    // Bei Retry wird der Stripe-Call NICHT wiederholt
    const stripeKey = await idempotencyKeys.create(
      `stripe-charge-${payload.orderId}`
    )

    const charge = await stripe.charges.create(
      {
        amount: payload.amount,
        currency: 'eur',
        source: 'tok_...',
      },
      { idempotencyKey: stripeKey }
    )

    // DB-Update ist idempotent (upsert statt insert)
    await supabase
      .from('payments')
      .upsert({
        order_id: payload.orderId,
        stripe_charge_id: charge.id,
        status: 'completed',
      }, { onConflict: 'order_id' })

    return { chargeId: charge.id }
  },
})
```

### Condición verificable

```bash
# Tasks mit externen API-Calls sollten Idempotency Keys haben
for file in trigger/tasks/*.ts; do
  if grep -qE "fetch\(|stripe\.|sendgrid\.|resend\." "$file"; then
    if ! grep -qE "idempotencyKey|idempotencyKeys" "$file"; then
      echo "WARNUNG: $file hat externe API-Calls ohne Idempotency Key"
    fi
  fi
done
```

### Escenario de fallo

Sin protección de idempotencia al disparar, un webhook duplicado (Stripe reintenta ante un timeout) puede activar la misma tarea dos veces. Sin idempotencia dentro de la tarea, un reintento tras un error parcial puede provocar pagos duplicados o correos electrónicos duplicados.

## B3 - Configurar correctamente timeouts y concurrency

### Implementación

Trigger.dev v3 incluye `maxDuration` (límite de tiempo de ejecución por tarea) y `concurrencyLimit` (ejecuciones paralelas). Ambos deben configurarse conscientemente para cada tarea.

```typescript
import { task, queue } from '@trigger.dev/sdk/v3'

// Shared Queue für E-Mail-Tasks (verhindert SMTP Rate Limiting)
const emailQueue = queue({
  name: 'email-processing',
  concurrencyLimit: 5,       // max. 5 parallele E-Mail-Tasks
})

export const sendEmail = task({
  id: 'send-email',
  queue: emailQueue,
  maxDuration: 30,            // 30 Sekunden max

  run: async (payload) => {
    // ...
  },
})

// AI-Tasks brauchen mehr Zeit, aber weniger Parallelität
export const analyzeDocument = task({
  id: 'analyze-document',
  queue: { concurrencyLimit: 2 },   // max. 2 parallele AI-Calls
  maxDuration: 300,                  // 5 Minuten max

  run: async (payload) => {
    // ...
  },
})

// Kritische Tasks die sequentiell laufen müssen
export const processInvoice = task({
  id: 'process-invoice',
  queue: { concurrencyLimit: 1 },    // strikt sequentiell
  maxDuration: 60,

  run: async (payload) => {
    // ...
  },
})
```

**Valores de referencia:**

```
E-Mail senden:        maxDuration 30s,    concurrency 5-10
PDF generieren:       maxDuration 120s,   concurrency 2-3
AI-Inference (LLM):   maxDuration 300s,   concurrency 1-3
Datenbank-Migration:  maxDuration 600s,   concurrency 1
Webhook verarbeiten:  maxDuration 30s,    concurrency 10
```

### Condición verificable

```bash
# Alle Tasks müssen maxDuration haben
for file in trigger/tasks/*.ts; do
  if ! grep -q "maxDuration" "$file"; then
    echo "WARNUNG: $file hat kein maxDuration"
  fi
done

# Alle Tasks müssen concurrencyLimit haben (oder eine shared Queue nutzen)
for file in trigger/tasks/*.ts; do
  if ! grep -qE "concurrencyLimit|queue:" "$file"; then
    echo "WARNUNG: $file hat kein Concurrency Limit"
  fi
done
```

### Escenario de fallo

Sin `maxDuration`, una tarea puede ejecutarse indefinidamente si una llamada API queda colgada, bloqueando un slot de worker de forma permanente. Sin `concurrencyLimit`, 100 tareas de envío de correo disparadas simultáneamente pueden sobrecargar el proveedor SMTP y provocar Rate Limiting. Sin Concurrency Limit en tareas intensivas de base de datos, todas las conexiones de PostgreSQL pueden quedar ocupadas simultáneamente.

> **Estadística:** Según datos de Trigger.dev, más del 40% de las instancias de producción self-hosted tienen tasks sin maxDuration configurado, lo que provoca bloqueo silencioso de workers.


## B4 - Secrets y variables de entorno

### Implementación

Las tareas de Trigger.dev se ejecutan en un entorno separado. Los secrets deben pasarse explícitamente a través de la configuración de Docker Compose.

```bash
# .env.trigger (nur auf dem Server, nicht im Git)
TRIGGER_DB_PASSWORD=...
MAGIC_LINK_SECRET=...
SESSION_SECRET=...
ENCRYPTION_KEY=...

# Secrets für eure Tasks (werden an Worker weitergereicht)
SUPABASE_SERVICE_ROLE_KEY=eyJ...
DATABASE_URL=postgresql://...
SENDGRID_API_KEY=SG.xxx
OPENAI_API_KEY=sk-xxx
STRIPE_SECRET_KEY=sk_live_xxx
```

Los secrets de las tareas se pasan en el setup self-hosted a través del Dashboard de Trigger.dev (Environment Variables) o del entorno Docker a los contenedores de workers.

En el código:

```typescript
// RICHTIG: Environment Variable
const apiKey = process.env.SENDGRID_API_KEY

// FALSCH: Hardcoded
const apiKey = 'SG.xxx...'
```

### Condición verificable

```bash
# Hardcoded Secrets?
grep -rn "sk_live\|sk_test\|SG\.\|sk-\|Bearer ey" \
  trigger/ --include="*.ts"
# Erwartung: keine Treffer

# .env.trigger nicht im Git?
git ls-files .env.trigger
# Erwartung: leer

# Alle benötigten Env Vars gesetzt?
for var in SUPABASE_SERVICE_ROLE_KEY SENDGRID_API_KEY; do
  if [ -z "${!var}" ]; then
    echo "FEHLT: $var"
  fi
done
```

### Escenario de fallo

Los secrets en archivos de tareas acaban en el repositorio Git y en el artefacto de compilación (imagen del Worker). En el setup self-hosted, las imágenes de los workers se construyen y almacenan localmente. Los secrets hardcoded en estas imágenes son visibles para cualquiera con acceso al host Docker o al registro.

## B5 - Manejo de errores y logging

### Implementación

Las tareas deben gestionar los errores de forma limpia y no registrar datos sensibles.

```typescript
import { task, logger } from '@trigger.dev/sdk/v3'

export const processOrder = task({
  id: 'process-order',

  retry: {
    maxAttempts: 3,
    factor: 2,
    minTimeoutInMs: 1_000,
    maxTimeoutInMs: 30_000,
  },

  run: async (payload: { orderId: string }) => {
    // Trigger.dev Logger (strukturiert, im Dashboard sichtbar)
    logger.info('Processing order', { orderId: payload.orderId })

    try {
      const result = await processOrderInternal(payload.orderId)

      logger.info('Order processed', {
        orderId: payload.orderId,
        status: result.status,
      })

      return result

    } catch (error) {
      // Strukturiert loggen (ohne sensible Details)
      logger.error('Order processing failed', {
        orderId: payload.orderId,
        errorMessage: error instanceof Error ? error.message : 'Unknown error',
        // NICHT: error.stack, payload Details, User-Daten
      })

      // Fehler weiterwerfen, damit Retry greift
      throw error
    }
  },

  // onFailure Hook: wird nach allen Retries aufgerufen
  onFailure: async (payload, error, params) => {
    logger.error('Order permanently failed after all retries', {
      orderId: payload.orderId,
      attemptNumber: params.run.attemptNumber,
    })

    // Alert senden (z.B. Slack Notification)
    await sendAlertToOps({
      task: 'process-order',
      orderId: payload.orderId,
      error: error.message,
    })
  },
})
```

**Lo que NO debe registrarse:**

```typescript
// FALSCH
logger.info('Processing user', { user })             // vollständiges User-Objekt
logger.info('API call', { headers: req.headers })     // Auth-Header mit Token
logger.info('DB query', { connectionString })         // Datenbank-URL
console.log(process.env.SUPABASE_SERVICE_ROLE_KEY)    // Secret
```

### Condición verificable

```bash
# console.log statt logger?
grep -rn "console\.log\|console\.error" trigger/tasks/ --include="*.ts"
# Erwartung: keine Treffer (immer logger von @trigger.dev/sdk verwenden)

# Sensible Daten in Logs?
grep -rn "logger\.\(info\|error\|warn\)" trigger/ --include="*.ts" | \
  grep -iE "password|secret|key|token|email.*:" | \
  grep -v "orderId\|taskId\|runId"
# Erwartung: keine Treffer
```

### Escenario de fallo

Trigger.dev almacena todos los logs y los muestra en el Dashboard. Si `console.log(user)` registra un objeto de usuario completo con correo electrónico y metadatos, estos datos son visibles en el Dashboard de Trigger.dev para cualquiera con acceso, incluso meses después, ya que el historial de ejecuciones es persistente.

## Parte C - Operación y monitorización

## C1 - Monitorización y alertas

### Implementación

Trigger.dev tiene un Dashboard integrado con historial de ejecuciones, logs y trazas. Adicionalmente, deben monitorizarse activamente estas métricas:

```
Kritische Metriken:
  - Failed Runs (letzte 24h)        -> Alert wenn > 5
  - Queue Length                     -> Alert wenn > 100
  - Average Run Duration             -> Alert wenn > 2x Baseline
  - Runs in WAITING State            -> Info, kein sofortiger Alert
```

**Asegurar el Dashboard self-hosted:**

```
# Das Trigger.dev Dashboard darf NICHT öffentlich erreichbar sein
# Zugang nur über:
# - Reverse Proxy mit Basic Auth
# - VPN / WireGuard
# - SSH Tunnel

# Beispiel: SSH Tunnel zum Dashboard
ssh -L 3040:localhost:3040 deploy@trigger-server

# Dann im Browser: http://localhost:3040
```

**Health Check automatizado:**

```bash
#!/bin/bash
# scripts/check-trigger-health.sh

# Trigger.dev Platform erreichbar?
HEALTH=$(curl -s -o /dev/null -w "%{http_code}" http://localhost:3040/healthcheck)
if [ "$HEALTH" != "200" ]; then
  echo "KRITISCH: Trigger.dev Platform nicht erreichbar"
fi

# Worker-Container läuft?
WORKER_STATUS=$(docker compose -f docker-compose.trigger.yml ps trigger-worker --format '{{.State}}')
if [ "$WORKER_STATUS" != "running" ]; then
  echo "KRITISCH: Trigger.dev Worker nicht running ($WORKER_STATUS)"
fi

# Failed Runs der letzten 24h (über Trigger.dev DB)
FAILED=$(docker compose -f docker-compose.trigger.yml exec -T trigger-db \
  psql -U postgres -d trigger -t -c \
  "SELECT count(*) FROM task_runs WHERE status = 'FAILED' AND created_at > now() - interval '24 hours';" 2>/dev/null)

if [ "${FAILED:-0}" -gt 5 ]; then
  echo "WARNUNG: $FAILED fehlgeschlagene Runs in den letzten 24h"
fi
```

### Condición verificable

```bash
# Dashboard nur intern erreichbar?
curl -s -o /dev/null -w "%{http_code}" https://trigger.example.com:3040
# Erwartung: Connection refused oder 401

# Health Check Script läuft täglich?
crontab -l | grep "check-trigger-health"
# Erwartung: Eintrag vorhanden
```

## C2 - Manejo de Dead Letters

### Implementación

Las tareas que fallan después de todos los reintentos quedan en estado `FAILED`. Deben gestionarse activamente.

```typescript
import { task, logger } from '@trigger.dev/sdk/v3'
import { createTaskClient } from '../lib/supabase'

export const criticalTask = task({
  id: 'critical-task',

  retry: {
    maxAttempts: 5,
    factor: 2,
    minTimeoutInMs: 2_000,
    maxTimeoutInMs: 60_000,
  },

  run: async (payload: { orderId: string }) => {
    // ... Task-Logik
  },

  onFailure: async (payload, error, params) => {
    const supabase = createTaskClient()

    // Failed Job in eigene Tabelle schreiben
    await supabase
      .from('failed_jobs')
      .insert({
        task_id: 'critical-task',
        payload: JSON.stringify(payload),
        error_message: error.message,
        attempts: params.run.attemptNumber,
        failed_at: new Date().toISOString(),
        resolved: false,
      })

    // Alert
    logger.error('Critical task permanently failed', {
      orderId: payload.orderId,
      attempts: params.run.attemptNumber,
    })
  },
})
```

```sql
-- Migration: failed_jobs Tabelle
CREATE TABLE IF NOT EXISTS failed_jobs (
  id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
  task_id TEXT NOT NULL,
  payload JSONB NOT NULL,
  error_message TEXT,
  attempts INTEGER,
  failed_at TIMESTAMPTZ NOT NULL,
  resolved BOOLEAN DEFAULT false,
  resolved_at TIMESTAMPTZ,
  resolved_by TEXT
);

-- RLS: nur service_role darf zugreifen
ALTER TABLE failed_jobs ENABLE ROW LEVEL SECURITY;
-- Keine Policy für anon/authenticated = kein Zugriff über PostgREST
```

### Condición verificable

```bash
# Gibt es unresolvierte Failed Jobs?
# Über Supabase Client oder direkte DB-Query
psql -c "SELECT count(*) FROM failed_jobs WHERE resolved = false;"
# Erwartung: 0 (oder aktiv in Bearbeitung)

# Haben alle kritischen Tasks einen onFailure Hook?
grep -L "onFailure" trigger/tasks/*.ts
# Erwartung: nur unkritische Tasks ohne onFailure
```

## C3 - Integración con Claude Code

### Arquitectura

```
Git Push / PR
   |
   +-- Deterministische Checks (CI/CD)
   |   +-- Alle Tasks haben maxDuration?
   |   +-- Alle Tasks haben concurrencyLimit?
   |   +-- Externe API-Calls haben Idempotency Keys?
   |   +-- Keine hardcoded Secrets?
   |   +-- Kein console.log (nur logger)?
   |
   +-- Claude Code Analyse (wöchentlich oder bei PR)
       +-- Neue Tasks ohne Retry-Strategie?
       +-- DB-Zugriff korrekt eingeschränkt?
       +-- Idempotenz-Patterns konsistent?
       +-- onFailure für kritische Tasks vorhanden?
       +-- Concurrency Limits angemessen?
```

### Script CI

```bash
#!/bin/bash
# scripts/check-trigger-tasks.sh

REPORT=""

# 1. Tasks ohne maxDuration
for file in trigger/tasks/*.ts; do
  name=$(basename "$file" .ts)
  if ! grep -q "maxDuration" "$file"; then
    REPORT+="WARNUNG: $name hat kein maxDuration\n"
  fi
done

# 2. Tasks ohne Concurrency
for file in trigger/tasks/*.ts; do
  name=$(basename "$file" .ts)
  if ! grep -qE "concurrencyLimit|queue:" "$file"; then
    REPORT+="WARNUNG: $name hat kein Concurrency Limit\n"
  fi
done

# 3. Externe API-Calls ohne Idempotency
for file in trigger/tasks/*.ts; do
  name=$(basename "$file" .ts)
  if grep -qE "fetch\(|stripe\.|resend\." "$file"; then
    if ! grep -qE "idempotencyKey|idempotencyKeys" "$file"; then
      REPORT+="WARNUNG: $name hat externe API-Calls ohne Idempotency\n"
    fi
  fi
done

# 4. Hardcoded Secrets
SECRETS=$(grep -rn "sk_live\|sk_test\|SG\.\|sk-" trigger/ --include="*.ts" 2>/dev/null)
if [ -n "$SECRETS" ]; then
  REPORT+="KRITISCH: Hardcoded Secrets:\n$SECRETS\n\n"
fi

# 5. console.log statt logger
CONSOLE=$(grep -rn "console\.\(log\|error\|warn\)" trigger/tasks/ --include="*.ts" 2>/dev/null)
if [ -n "$CONSOLE" ]; then
  REPORT+="WARNUNG: console.log statt Trigger.dev logger:\n$CONSOLE\n\n"
fi

# 6. Nicht exportierte Tasks
for file in trigger/tasks/*.ts; do
  name=$(basename "$file" .ts)
  if ! grep -q "export const" "$file"; then
    REPORT+="KRITISCH: $name Task ist nicht exportiert\n"
  fi
done

if [ -n "$REPORT" ]; then
  echo -e "=== Trigger.dev Task Security Check ===\n$REPORT"
else
  echo "Alle Trigger.dev Checks bestanden."
fi
```

Claude **no ejecuta cambios automáticos en producción**.

## Lista de verificación de despliegue

Comprobar antes de cada despliegue de tareas de Trigger.dev:

```
Arquitectura
  [ ] Trigger.dev se ejecuta como servicio independiente (no en el proceso de Next.js)
  [ ] Instancia de PostgreSQL propia (no la BD de Supabase)
  [ ] Dashboard accesible solo internamente

Definición de tareas
  [ ] Cada tarea está exportada
  [ ] Cada tarea tiene un ID único
  [ ] Cada tarea tiene maxDuration
  [ ] Cada tarea tiene concurrencyLimit o shared Queue
  [ ] Cada tarea tiene configuración de retry

Idempotencia
  [ ] Las llamadas de trigger tienen idempotencyKey donde sea necesario
  [ ] Las llamadas a APIs externas dentro de las tareas tienen Idempotency
  [ ] Las operaciones de BD son idempotentes (upsert en lugar de insert donde sea posible)

Acceso a la base de datos
  [ ] service_role solo a través de createTaskClient()
  [ ] Las consultas acceden solo a los datos necesarios (sin SELECT *)
  [ ] Connection Pool limitado (max: 5-10)

Secrets
  [ ] Sin secrets hardcoded en el código
  [ ] Secrets a través de Environment Variables / Dashboard
  [ ] .env.trigger no está en Git

Logging
  [ ] Trigger.dev logger en lugar de console.log
  [ ] Sin datos sensibles en los logs (objetos de usuario, tokens, keys)

Manejo de errores
  [ ] Las tareas críticas tienen hook onFailure
  [ ] Los Failed Jobs se almacenan en la tabla failed_jobs
  [ ] Alertas configuradas para errores permanentes
```

## Conclusión

Trigger.dev constituye la capa de procesamiento en segundo plano del stack. Utilizado correctamente, procesa jobs asíncronos de forma fiable, con reintentos, idempotencia y monitorización.

El punto de seguridad más crítico es el acceso a la base de datos: las tareas tienen típicamente más permisos que las solicitudes normales de usuario, porque trabajan con `service_role` o conexiones directas a la base de datos. Por eso, la validación de entrada, la limitación de alcance y la idempotencia deben implementarse conscientemente en cada tarea.

La combinación de la lógica de reintentos integrada de Trigger.dev, Concurrency Limits conscientes y análisis contextual de Claude Code conduce a workflows de Background estables que funcionan correctamente incluso ante fallos parciales.

Quien aplique estos principios junto con una [arquitectura Cert-Ready-by-Design](/es/revista/cert-ready-by-design/) construye seguridad verificable en lugar de auditorías posteriores.

<div class="not-prose my-12 border border-gosign-border bg-gosign-light rounded-card p-6 lg:p-8">
<div class="flex items-start gap-4">
<div class="flex-shrink-0 w-12 h-12 bg-gosign-dark rounded-card flex items-center justify-center">
<svg width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="white" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 15v4a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2v-4"/><polyline points="7 10 12 15 17 10"/><line x1="12" y1="15" x2="12" y2="3"/></svg>
</div>
<div>
<h2 class="text-h3 font-bold text-gosign-dark mb-2" id="descarga-de-la-lista-de-verificacion">Descarga de la lista de verificación</h2>
<p class="text-body text-gosign-text mb-2">Prompt preparado para Claude Code. Suba el archivo a su servidor e inicie Claude Code en el directorio del proyecto de su configuración Trigger.dev. Claude Code verificará automáticamente todos los puntos de seguridad de este runbook e informará APROBADO, ADVERTENCIA o CRÍTICO.</p>
<p class="text-sm text-gosign-text mb-4 font-mono">claude -p "$(cat claude-check-artikel-4-trigger-dev-es.md)" --allowedTools Read,Grep,Glob,Bash</p>
<a href="/downloads/claude-check-artikel-4-trigger-dev-es.md" download class="inline-flex items-center px-6 py-3 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-small uppercase tracking-wider">Descargar checklist</a>
</div>
</div>
</div>

## Índice de la serie

Este artículo forma parte de nuestra serie DevOps para app stacks self-hosted.

1. [Supabase Self-Hosting Runbook](/es/revista/supabase-self-hosting/)
2. [Next.js sobre Supabase de forma segura](/es/revista/nextjs-supabase-configuracion-segura/)
3. [Supabase Edge Functions de forma segura](/es/revista/supabase-edge-functions-seguridad/)
4. [Trigger.dev Background Jobs de forma segura](/es/revista/trigger-dev-background-jobs/) - este artículo
5. [Claude Code como control de seguridad en el workflow DevOps](/es/revista/claude-code-security-devops/)
6. [Security Baseline para todo el stack](/es/revista/security-baseline-stack/)

El próximo artículo describe cómo se utiliza **Claude Code como control de seguridad en el workflow DevOps** - como la capa de análisis transversal sobre todos los artículos anteriores.

--- Por qué Pair Programming no es opcional ---
> 15% más esfuerzo, 60% menos defectos, 40% más rápido en onboarding. La evidencia científica del Pair Programming - con KPIs y fuentes.

Dos desarrolladores, una pantalla, un problema. Lo que suena a desperdicio es el método mejor documentado de la ingeniería de software - y sin embargo la mayoría de organizaciones lo ignoran. En este artículo hemos recopilado 25 años de datos de investigación: desde los estudios pioneros de Williams en la University of Utah, pasando por los experimentos de campo de Cockburn, hasta los estudios controlados de Arisholm en Simula Research. La conclusión es inequívoca. El Pair Programming cuesta un 15% más de tiempo - y ahorra múltiplos de eso mediante menos bugs, onboarding más rápido y código que más de una persona comprende. Quien tras leer esto siga dejando programar en solitario, lo hace por costumbre, no por convicción.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">De un vistazo - 25 años de investigación sobre Pair Programming</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Las parejas necesitan solo un 15% más de tiempo - no el doble - mientras producen un 15-60% menos de defectos (Williams & Kessler, 2000; Arisholm et al., 2007).</li>
<li>Las tareas complejas se completan un 29% más rápido en parejas, y el onboarding se acelera un 30-50% gracias a la transferencia de conocimiento.</li>
<li>La carga cognitiva se distribuye entre dos memorias de trabajo, detectando un 40% más de casos límite y alcanzando un 99% de detección en bugs críticos.</li>
<li>En la era de la IA, el Pair Programming contrarresta el aislamiento profesional - el 68% de los desarrolladores reportan días sin interacción con su equipo (Microsoft, 2024).</li>
<li>Cálculo modelo enterprise: un proyecto con 10 desarrolladores ahorra aproximadamente 345.000 EUR netos al año en costes de defectos y conocimiento.</li>
</ul>
</div>

## El mito del genio solitario

La imagen romántica persiste: un desarrollador brillante sentado solo frente a la pantalla, pensando intensamente y produciendo código elegante. Linus Torvalds escribió Git en un fin de semana. John Carmack construyó motores de Doom en solitario.

Estas historias son ciertas. También son irrelevantes.

El software enterprise no es un proyecto de fin de semana. Consiste en cientos de integraciones, requisitos regulatorios, traspasos entre equipos y sistemas que han crecido durante años. En este contexto, trabajar solo no es una señal de productividad. Es un factor de riesgo.

La investigación de los últimos 25 años es sorprendentemente clara. Los números:

- **15%** más de tiempo total de desarrollo - no 100% <sup>[1]</sup>
- **15-60%** menos defectos en el código <sup>[1][4]</sup>
- **29%** más rápido en completar tareas complejas <sup>[2]</sup>
- **30-50%** más rápido en onboarding de nuevos miembros del equipo <sup>[1]</sup>
- **95%** de los participantes en pairing reportan mayor satisfacción <sup>[2]</sup>
- **48%** menos líneas de código para la misma funcionalidad <sup>[1]</sup>
- **30x** costes más altos cuando los bugs se encuentran en producción <sup>[6]</sup>

Esto no es intuición. Son resultados de estudios replicados en experimentos controlados con cientos de desarrolladores profesionales.

## La colección de KPIs: 25 años de investigación en cifras

### Densidad de defectos y calidad de código

<table>
<thead><tr><th>Estudio</th><th>n</th><th>KPI</th><th>Resultado</th></tr></thead>
<tbody>
<tr><td>Williams & Kessler (2000) <sup>[1]</sup></td><td>41</td><td>Tests aprobados a la primera</td><td><strong>+15%</strong> vs. solo</td></tr>
<tr><td>Williams & Kessler (2000) <sup>[1]</sup></td><td>41</td><td>Densidad de defectos</td><td><strong>significativamente menor</strong></td></tr>
<tr><td>Nosek (1998) <sup>[2]</sup></td><td>15</td><td>Corrección funcional</td><td><strong>mayor</strong> en parejas</td></tr>
<tr><td>Nosek (1998) <sup>[2]</sup></td><td>15</td><td>Legibilidad del código</td><td><strong>mayor</strong> en parejas</td></tr>
<tr><td>Arisholm et al. (2007) <sup>[4]</sup></td><td>295</td><td>Tasa de errores (tareas complejas)</td><td><strong>-60%</strong> vs. solo</td></tr>
<tr><td>Arisholm et al. (2007) <sup>[4]</sup></td><td>295</td><td>Tasa de errores (tareas simples)</td><td><strong>marginal</strong></td></tr>
<tr><td>Dyba et al. (2007) <sup>[5]</sup></td><td>18 estudios</td><td>Calidad de código general</td><td><strong>mejora estadísticamente significativa</strong></td></tr>
<tr><td>Jensen (2003) <sup>[16]</sup></td><td>120</td><td>Defectos post-aceptación</td><td><strong>-40%</strong></td></tr>
<tr><td>Padberg & Mueller (2003) <sup>[17]</sup></td><td>Simulación</td><td>Defectos post-release</td><td><strong>-20 a -40%</strong></td></tr>
</tbody>
</table>

### Esfuerzo temporal y productividad

| Estudio | n | KPI | Resultado |
|---------|---|-----|-----------|
| Williams & Kessler (2000) <sup>[1]</sup> | 41 | Tiempo total de desarrollo | **+15%** (no +100%) |
| Nosek (1998) <sup>[2]</sup> | 15 | Tiempo transcurrido (tarea compleja) | **-29%** más rápido |
| Arisholm et al. (2007) <sup>[4]</sup> | 295 | Esfuerzo (tareas simples) | **+84%** |
| Arisholm et al. (2007) <sup>[4]</sup> | 295 | Esfuerzo (tareas complejas) | **+18%** |
| Cockburn & Williams (2001) <sup>[3]</sup> | Revisión | Punto de equilibrio en reducción de defectos | **a partir de 3-5%** |
| Lui & Chan (2006) <sup>[18]</sup> | 40 | Rendimiento de tareas | **+43%** vs. solo |

### Satisfacción y dinámica de equipo

| Estudio | n | KPI | Resultado |
|---------|---|-----|-----------|
| Nosek (1998) <sup>[2]</sup> | 15 | Satisfacción con el resultado | **+95%** en parejas |
| Williams et al. (2000) <sup>[1]</sup> | 41 | Recomendaría a colegas | **96%** volverían a trabajar en pareja |
| Begel & Nagappan (2008) <sup>[19]</sup> | 106 | Satisfacción con el pairing (Microsoft) | **65%** satisfechos |
| Begel & Nagappan (2008) <sup>[19]</sup> | 106 | Perciben mejora de calidad (Microsoft) | **74%** |

### Eficiencia del código

| Estudio | KPI | Resultado |
|---------|-----|-----------|
| Williams & Kessler (2000) <sup>[1]</sup> | Líneas de código (misma funcionalidad) | **-48%** menos líneas |
| Mueller (2004) <sup>[20]</sup> | Complejidad ciclomática | **menor** en parejas |

La conclusión central de todos los estudios: el Pair Programming cuesta algo más de tiempo. Produce menos código que tiene menos errores, es más fácil de mantener y es comprendido por más personas.

## "Pero soy más rápido solo" - lo que realmente molesta a los desarrolladores

Hablemos del elefante en la habitación. La mayoría de los desarrolladores que rechazan el Pair Programming no tienen cifras en contra. Tienen una sensación. Y esa sensación no es irracional - simplemente es incompleta.

### "No puedo concentrarme cuando alguien me observa"

Esto es real. Sin embargo, la investigación sobre Social Facilitation <sup>[10]</sup> demuestra que la presencia de un observador solo perturba el rendimiento en **tareas nuevas y no practicadas**. En tareas que se dominan - es decir, la programación en sí - la presencia **mejora** el rendimiento un 15-20%.

Lo que experimentas como "perturbación" es tu cerebro cambiando del Sistema 1 (piloto automático) al Sistema 2 (pensamiento analítico) <sup>[9]</sup>. Esto se siente más agotador. Pero produce mejor código. Todo desarrollador conoce la sensación de escribir una solución "genial" a las 23:00 en soledad - que a la mañana siguiente resulta vergonzosa. El compañero previene las decisiones de las 23:00 en tiempo real.

### "Necesito pensar solo antes de poder programar"

Cierto. Y precisamente por eso el Pair Programming no significa que dos personas se sienten juntas 8 horas. La práctica más efectiva según un estudio de Chong y Hurlbutt (2007) <sup>[21]</sup>: **sesiones de 2-4 horas** con pausas para exploración individual.

El modelo: pensar solo, trabajar en pareja para construir, pensar solo, trabajar en pareja para revisar. Los estudios que miden un 15% de esfuerzo adicional con un 60% menos de defectos se basan en este ritmo - no en 8 horas de pairing continuo.

### "Mi compañero es demasiado lento / demasiado rápido"

El desajuste de habilidades es el problema más común en la práctica <sup>[19]</sup>. Begel y Nagappan (2008) descubrieron en su estudio de Microsoft: el **73% de los desarrolladores** que rechazaban el pairing citaban el desajuste de habilidades como razón. No el pairing en sí.

La solución no es no hacer pairing. La solución es un mejor emparejamiento. Sus datos también mostraron: con parejas bien emparejadas, la satisfacción era del **90%** - y la productividad percibida superaba incluso el trabajo en solitario <sup>[19]</sup>.

Y aquí el punto que nadie quiere escuchar: si siempre eres el "más rápido", también eres el monopolista del conocimiento. Eres el bus factor de 1. Tu equipo depende de ti. Hacer pairing con alguien "más lento" no es un freno - es transferencia de conocimiento. Es el seguro más barato que tu equipo puede contratar.

### "Pierdo mi estado de flow"

La teoría del flow de Csikszentmihalyi <sup>[22]</sup> describe el estado de absorción completa en una tarea. La programación en solitario puede generar flow. Pero el flow tiene un problema: suprime el pensamiento crítico. En estado de flow, las señales de advertencia se ignoran, los casos límite se omiten, se toman atajos que "se sienten correctos" <sup>[9]</sup>.

Lo que los desarrolladores experimentan como "flow" es a menudo el Sistema 1 a toda velocidad - rápido, intuitivo y ciego a sus propios errores. El Pair Programming reemplaza el flow descontrolado por **enfoque productivo**: alta concentración con control de calidad simultáneo.

Los estudios muestran: las parejas reportan **igual o mayor satisfacción laboral** que los desarrolladores en solitario <sup>[2]</sup>. El flow no es la única receta para un buen trabajo. El Shared Focus es la variante más sostenible.

### "Los code reviews son suficientes"

Fagan (1976) <sup>[14]</sup> demostró: las revisiones formales de código detectan un **60-70% de los defectos**. Suena bien. El Pair Programming detecta un **85-95%** <sup>[1]</sup>. Pero la diferencia decisiva no es la tasa - es el momento.

Un code review encuentra errores horas o días después de escribirse. El contexto ha desaparecido. El revisor debe reconstruir el proceso de pensamiento - y lo hace incorrectamente en el **60% de los casos** (Bacchelli & Bird, 2013) <sup>[23]</sup>. Aprueba código que no comprende completamente porque la presión social es demasiado grande para hacer esperar a un colega horas por una aprobación.

El Pair Programming no tiene este problema. El navegador estuvo presente durante todo el proceso de pensamiento. Sin pérdida de contexto. Sin presión social. Y sin cola en el PR review que ralentiza a todo el equipo.

### "Es socialmente agotador"

Sí. Para los desarrolladores introvertidos, el pairing continuo es extenuante. Esto no es un argumento contra el pairing - es un argumento a favor del **pairing dosificado**. La investigación <sup>[21]</sup> recomienda un 50-70% de tiempo en pairing, no un 100%. Tareas críticas (arquitectura, integración, seguridad) en parejas. Trabajo rutinario (configuración, bugs simples) en solitario.

El hallazgo clave: los desarrolladores que "nunca" querían hacer pairing cambiaron de opinión tras **2 semanas de pairing consistente** - el 96% lo recomendaría <sup>[1]</sup>. El rechazo inicial es casi siempre una defensa de la zona de confort, no una posición basada en evidencia.

## La explicación cognitiva: por qué dos cerebros rinden más que uno

### Cognitive Load Theory (Sweller, 1988) <sup>[7]</sup>

Toda persona tiene una capacidad limitada para el procesamiento simultáneo de información en la memoria de trabajo. Miller (1956) <sup>[8]</sup> cuantificó esta capacidad en **7 más/menos 2 unidades**. Al programar, hasta **12-15 demandas paralelas** compiten por esta capacidad: sintaxis, lógica, arquitectura del sistema, casos límite, convenciones de nomenclatura, requisitos de pruebas, contratos de API, implicaciones de rendimiento.

En el Pair Programming, esta carga se distribuye entre dos memorias de trabajo. El driver se concentra en el nivel táctico: sintaxis, nombres de variables, función actual. El navegador mantiene el nivel estratégico a la vista: ¿la solución encaja en la arquitectura general? ¿Falta un caso límite? ¿Existe una variante más simple?

Medible: las parejas consideran un **40% más de casos límite** que los desarrolladores en solitario en la misma tarea <sup>[17]</sup>. No porque sean más inteligentes. Sino porque su capacidad cognitiva combinada es mayor.

### Efecto de verbalización (Chi et al., 1989) <sup>[11]</sup>

Una de las herramientas de debugging más potentes es el Rubber Duck Debugging: explicar el problema en voz alta, aunque solo escuche un pato de goma. Chi et al. demostraron el Self-Explanation Effect: los estudiantes que explicaron sus pasos de resolución en voz alta obtuvieron en tests de resolución de problemas **puntuaciones 2,5 veces mayores** que los que resolvían en silencio. La tasa de errores bajó un **30%** <sup>[11]</sup>.

El Pair Programming institucionaliza este efecto. Cada decisión debe explicarse al compañero. "Uso aquí un HashMap en lugar de un ArrayList porque..." - la frase obliga a justificar. Y las justificaciones que no convencen son cuestionadas. Antes de escribir el código, no semanas después en code review.

### Dual Process Theory (Kahneman, 2011) <sup>[9]</sup>

La Teoría del Proceso Dual de Daniel Kahneman distingue dos modos de pensamiento: Sistema 1 (rápido, intuitivo, propenso a errores) y Sistema 2 (lento, analítico, preciso). En la programación en solitario domina el Sistema 1 - los desarrolladores copian patrones conocidos, omiten verificaciones porque "eso siempre ha funcionado".

El compañero activa el Sistema 2. No mediante control, sino mediante la mera presencia. La psicología social lo llama Social Facilitation <sup>[10]</sup>: la presencia de un observador competente mejora el rendimiento en tareas bien dominadas un **15-20%**.

### Working Memory Complement (Flor & Hutchins, 1991) <sup>[24]</sup>

Dos programadores no simplemente se reparten el trabajo. Complementan sus memorias de trabajo. Lo que la persona A pasa por alto, lo nota la persona B - no porque B sea más atenta, sino porque la atención se dispersa estadísticamente.

La consecuencia matemática: si un desarrollador en solitario detecta una clase específica de errores con un **90% de probabilidad**, dos desarrolladores independientes detectan la misma clase con un **99% de probabilidad** (1 - 0,1 x 0,1). Con una tasa de detección del 80%, la tasa del par sube al **96%**. Solo este efecto estadístico explica gran parte de la reducción de defectos observada.

## La dimensión psicológica: seguridad, conocimiento, pertenencia

### Psychological Safety (Edmondson, 1999) <sup>[12]</sup>

Amy Edmondson acuñó el término Psychological Safety: la convicción de que en un equipo se pueden admitir errores, hacer preguntas y asumir riesgos sin ser castigado.

- **Google Project Aristotle (2015)** <sup>[13]</sup>: Psychological Safety fue el **predictor n.1** del rendimiento del equipo - más importante que estructura, claridad, significado o fiabilidad
- **Edmondson (1999)** <sup>[12]</sup>: los equipos con alto Psychological Safety **reportaban un 70% más de errores** y podían corregirlos más rápido
- **Rozovsky (2015)** <sup>[13]</sup>: los equipos en el cuartil superior de Psychological Safety tenían un **17% más de productividad** y un **40% menos de rotación**

El Pair Programming crea un marco natural para esto. "No entiendo qué devuelve esta API" es una afirmación normal en una sesión de pairing. En un entorno de trabajo en solitario, la misma incertidumbre a menudo permanece sin expresar - y se convierte en un bug.

### Distribución del conocimiento y bus factor

El coste de la pérdida de conocimiento en cifras:

- **Bus factor de 1** (solo una persona conoce el código): riesgo de **fallo total del proyecto** ante un cambio de personal
- **Pérdida de conocimiento por rotación**: con cada salida se pierde un **42% del conocimiento relevante del proceso** - del cual un **70% es tácito**, es decir, no documentado <sup>[15]</sup>
- **Coste de re-onboarding**: **6-12 meses** hasta que un nuevo desarrollador es productivo en un proyecto enterprise, **3-6 meses** con pair onboarding <sup>[1]</sup>
- **Costes de rotación**: 50-200% del salario anual por salida (SHRM, 2019)

El Pair Programming es el mecanismo más fiable que conocemos para [distribuir el conocimiento tácito desde cabezas individuales al equipo](/es/revista/por-que-fracasan-proyectos-ia-rrhh/).

### Aceleración del onboarding

- **30-50% más rápido en productividad** con pair onboarding vs. autoestudio <sup>[1]</sup>
- **75% de las parejas de onboarding** se sienten "listas para trabajo independiente" después de 2 semanas vs. **25% con onboarding en solitario** <sup>[21]</sup>
- **Cognitive Apprenticeship** (Collins, Brown & Newman, 1989) <sup>[25]</sup>: el aprendizaje mediante observación y asunción gradual es **2-3 veces más efectivo** que el aprendizaje basado en instrucciones para tareas complejas

## El business case: el cálculo completo

### Error 1: La asunción del 100%

Las parejas no tardan el doble:

- Tareas simples: **+84% de esfuerzo** <sup>[4]</sup> - aquí el pairing rara vez compensa
- Tareas medias: **+15% de esfuerzo** <sup>[1]</sup>
- Tareas complejas: **+18% de esfuerzo** con simultáneamente **-60% de defectos** <sup>[4]</sup>
- Tiempo transcurrido (tarea compleja): **-29%** más rápido <sup>[2]</sup>

Las parejas descartan enfoques erróneos **4 veces más rápido** porque el navegador detecta el error de pensamiento antes <sup>[18]</sup>.

### Error 2: Los costes de defectos se ignoran

La curva de escalación de costes según Boehm y Basili (2001) <sup>[6]</sup>:

| Fase | Coste de corrección (relativo) | Ejemplo (con 500 EUR de coste base) |
|------|--------------------------------|---------------------------------------|
| Codificación | 1x | 500 EUR |
| Code review | 2x | 1.000 EUR |
| Integración/pruebas | 5x | 2.500 EUR |
| Pruebas del sistema | 10x | 5.000 EUR |
| Producción | 30x | 15.000 EUR |
| Post-release (cliente afectado) | 100x | 50.000 EUR |

El **National Institute of Standards and Technology (NIST)** <sup>[26]</sup> estimó los costes anuales de defectos de software en EE.UU. en **59.500 millones de USD**. De estos, **22.200 millones de USD** (37%) podrían haberse evitado mediante una detección más temprana de errores.

### Error 3: Los costes de conocimiento se ignoran

Cuando un desarrollador se va y nadie conoce su código:

- **Ingeniería inversa**: 2-6 meses de esfuerzo
- **Tasa de errores elevada** durante la transición: +200-300%
- **Entrega de funcionalidades retrasada**: 3-9 meses hasta el estado normal
- **Coste total de rotación**: 50-200% del salario anual (SHRM, 2019)

### El cálculo completo (proyecto modelo)

Para un proyecto enterprise con 10 desarrolladores, 12 meses de duración:

| Partida | Solo | Pairing | Delta |
|---------|------|---------|-------|
| Esfuerzo de desarrollo | Base | +15% | +105.000 EUR |
| Corrección de defectos (pruebas) | Base | -40% | -120.000 EUR |
| Corrección de defectos (producción) | Base | -50% | -225.000 EUR |
| Transferencia de conocimiento/onboarding | Base | -40% | -80.000 EUR |
| Esfuerzo de documentación | Base | -30% | -25.000 EUR |
| **Ahorro neto** | | | **-345.000 EUR** |

Las cifras varían según el proyecto. La dirección no. En el desarrollo enterprise - donde un error en producción en un [sistema de nómina](/es/servicios/hr-agent/payroll-decision-layer/) o una interfaz con SAP afecta a miles de empleados - el desarrollo en solitario es el modelo más caro.

## Real-Time Review vs. Post-Hoc Review

| KPI | Code review post-hoc | Pair Programming | Fuente |
|-----|---------------------|-----------------|--------|
| Detección de defectos | 60-70% | 85-95% | <sup>[14]</sup> <sup>[1]</sup> |
| Tiempo hasta detección | Horas a días | Segundos | Estructural |
| Pérdida de contexto | Alta | Cero | <sup>[23]</sup> |
| Malentendidos en review | 60% (revisor malinterpreta la intención) | 0% | <sup>[23]</sup> |
| Tiempo de espera de PR | 4-24 horas (bloqueador del equipo) | 0 | Estructural |
| Transferencia de conocimiento | Baja (solo visible el código) | Alta (visible el proceso de decisión) | <sup>[24]</sup> |

Bacchelli y Bird (2013) <sup>[23]</sup> analizaron code reviews en Microsoft y encontraron: en el **60% de los casos**, el revisor no comprendió correctamente la intención del autor. Las revisiones que debían encontrar errores degeneraban en discusiones de estilo. La razón principal: falta de contexto.

## El factor humano: por qué el Pair Programming importa más en la era de la IA, no menos

Existe un argumento a favor del Pair Programming que no aparece en ningún estudio de los años 2000 - porque el problema no existía entonces.

En 2026, los desarrolladores pasan una parte creciente de su jornada laboral en diálogo con asistentes de IA. El código se genera con Copilot, las preguntas de arquitectura se dirigen a Claude, el debugging se realiza con ChatGPT. Las ganancias de productividad son reales. Pero está surgiendo un efecto secundario que nadie planificó: el **aislamiento profesional**.

Las cifras son alarmantes:

- **Gallup State of the Global Workplace (2024)**: solo el **23% de los empleados** a nivel mundial se sienten comprometidos en el trabajo. Entre los trabajadores remotos del conocimiento, la cifra es del **18%**
- **Microsoft Work Trend Index (2024)**: el **68% de los desarrolladores** reportan que algunos días **no hablan con nadie de su equipo** sobre trabajo
- **Buffer State of Remote Work (2024)**: el **23% de los trabajadores remotos** mencionan la **soledad** como su mayor desafío - por delante de "distracciones" y "motivación"
- **Murthy (2023)**: el Surgeon General de EE.UU. declaró la soledad en el trabajo una **crisis de salud pública** con efectos medibles sobre productividad, creatividad y tasa de errores

Un desarrollador que pasa 8 horas al día hablando con un LLM y con nadie de su equipo toma decisiones en un vacío. El LLM no objeta desde la experiencia. No conoce la dinámica del equipo. No sabe que el último desarrollador que "rápidamente" cambió la estructura de la base de datos causó tres semanas de limpieza. No tiene opiniones basadas en cicatrices.

### Social Cognition vs. Tool Cognition

La neurociencia distingue dos redes en el cerebro <sup>[27]</sup>: la **Task-Positive Network** (activada durante la resolución de problemas, uso de herramientas, trabajo enfocado) y la **Default Mode Network** (activada durante la cognición social, el cambio de perspectiva, la empatía). Durante la programación en solitario con asistentes de IA, está activa casi exclusivamente la Task-Positive Network. La Default Mode Network - responsable de "¿Cómo vería esto mi colega?" - permanece en silencio.

El Pair Programming activa **ambas redes simultáneamente**: resolución de problemas y cognición social. El resultado son decisiones que no solo son técnicamente correctas, sino que también consideran el contexto del equipo.

### La confianza se construye trabajando juntos, no con mensajes de Slack

Dutton y Heaphy (2003) <sup>[28]</sup> estudiaron las "High-Quality Connections" en el trabajo: interacciones breves e intensas que generan confianza, energía y aprecio mutuo. Su investigación muestra:

- **Un solo día de colaboración intensa** genera más confianza que **semanas de comunicación asíncrona**
- Los equipos con High-Quality Connections regulares tienen un **25% menos de rotación** y un **30% más de compromiso** <sup>[28]</sup>
- La confianza construida mediante la resolución conjunta de problemas es **3 veces más estable** que la confianza construida mediante eventos sociales <sup>[12]</sup>

El Pair Programming es la forma más densa de interacción profesional que existe. Dos personas resuelven juntas un problema, comparten frustración y éxito, conocen la forma de pensar del otro. Esto no es un bonus de habilidades blandas. Es el adhesivo que mantiene unidos a los equipos funcionales.

### El contracálculo: qué sucede cuando los equipos dejan de comunicarse

- **Formación de silos**: sin intercambio profesional regular, se forman islas de conocimiento. Cada desarrollador construye su propio modelo mental del sistema - y esos modelos divergen con el tiempo <sup>[15]</sup>
- **Trabajo duplicado**: sin visibilidad del trabajo de otros, el **15-25% de las funcionalidades se implementan de forma redundante** (Herbsleb & Grinter, 1999) <sup>[29]</sup>
- **Pérdida de calidad**: los desarrolladores que se sienten socialmente aislados muestran un **33% más de defectos** que los miembros integrados del equipo (Begel & Nagappan, 2008) <sup>[19]</sup>
- **Burnout**: el aislamiento profesional es uno de los predictores más fuertes de burnout entre los trabajadores del conocimiento (Maslach & Leiter, 2016) <sup>[30]</sup>

La ironía: los asistentes de IA hacen más productivos a los desarrolladores individuales. Pero hacen más frágiles a los equipos - cuando falta el pairing como contrapeso. La solución no es menos IA. La solución es la interacción humana intencional como proceso estándar. El Pair Programming es el camino más simple y efectivo para lograrlo.

## Qué significa esto para el desarrollo enterprise

En el [desarrollo de software enterprise](/es/servicios/software-engineering/) todos los efectos mencionados se potencian:

**Complejidad de integración.** Cuando un agente debe conectarse a SAP, Microsoft Graph y sistemas locales, la carga cognitiva por tarea sube a **15+ contextos paralelos**. Exactamente la situación donde el Pair Programming muestra la mayor ventaja: +18% de esfuerzo con -60% de defectos <sup>[4]</sup>.

**Requisitos regulatorios.** El código relevante para compliance exige corrección. La **tasa de detección del 99%** (vs. 90% en solitario) para clases críticas de errores no es un nice-to-have. Es un requisito de negocio.

**Principio de cuatro ojos.** En sectores regulados, el compliance exige un principio de cuatro ojos (ISO 27001). El Pair Programming cumple este requisito de forma nativa - **cero esfuerzo adicional** para la revisión de compliance.

**Co-Build como modelo.** En Gosign trabajamos en un [modelo Co-Build](/es/servicios/ai-agents/): los equipos de clientes desarrollan con nosotros, no junto a nosotros. Esto es Pair Programming a nivel organizativo - **100% de transferencia de conocimiento** al equipo del cliente, sin vendor lock-in.

## El resumen en cifras

| KPI | Solo | Pair Programming | Fuente |
|-----|------|-----------------|--------|
| Tiempo de desarrollo | Base | +15% | <sup>[1]</sup> |
| Tiempo transcurrido (complejo) | Base | -29% | <sup>[2]</sup> |
| Densidad de defectos | Base | -15 a -60% | <sup>[1]</sup> <sup>[4]</sup> |
| Líneas de código (misma función) | Base | -48% | <sup>[1]</sup> |
| Tests aprobados a la primera | Base | +15% | <sup>[1]</sup> |
| Duración del onboarding | 3-6 meses | 1,5-3 meses | <sup>[1]</sup> |
| Satisfacción | Base | +95% | <sup>[2]</sup> |
| Volverían a hacer pairing | n/a | 96% | <sup>[1]</sup> |
| Bus factor | 1 | Mínimo 2 | Estructural |
| Defectos post-release | Base | -20 a -40% | <sup>[17]</sup> |
| Detección de defectos (críticos) | 90% | 99% | Estadístico |
| Coste por defecto (producción) | 30x codificación | Evitado | <sup>[6]</sup> |
| Tiempo espera PR review | 4-24h | 0 | Estructural |
| Malentendidos code review | 60% | 0% | <sup>[23]</sup> |

## Conclusión

La pregunta no es si una organización puede permitirse el Pair Programming. La pregunta es si puede permitirse prescindir de él.

**15% más de tiempo de desarrollo. 60% menos defectos. 40% más rápido en onboarding. 48% menos código. 99% de tasa de detección en errores críticos. 345.000 EUR de ahorro neto al año en el proyecto modelo.**

Y a los desarrolladores a quienes les molesta el pairing: el 96% de vuestros colegas cambiaron de opinión tras dos semanas de pairing consistente <sup>[1]</sup>. La evidencia no dice que el pairing sea cómodo. Dice que funciona mejor. Para el código, para el equipo y para vosotros.

El Pair Programming no es una preferencia. Es una decisión de ingeniería con ROI medible.

> [Software Engineering en Gosign - Co-Build en vez de Black Box](/es/servicios/software-engineering/)

> [Por qué fracasan los proyectos de IA - y qué tiene que ver la arquitectura de decisiones](/es/revista/por-que-fracasan-proyectos-ia-rrhh/)

> [AI Agents - soluciones personalizadas en el modelo Co-Build](/es/servicios/ai-agents/)

---

## Referencias

<small>

**[1]** Williams, L. & Kessler, R. (2000). "All I Really Need to Know About Pair Programming I Learned in Kindergarten." *Communications of the ACM*, 43(5), 108-114. University of Utah.

**[2]** Nosek, J.T. (1998). "The Case for Collaborative Programming." *Communications of the ACM*, 41(3), 105-108.

**[3]** Cockburn, A. & Williams, L. (2001). "The Costs and Benefits of Pair Programming." *Proceedings of the First International Conference on Extreme Programming and Flexible Processes in Software Engineering (XP2000)*, 223-243.

**[4]** Arisholm, E., Gallis, H., Dyba, T. & Sjoberg, D.I.K. (2007). "Evaluating Pair Programming with Respect to System Complexity and Programmer Expertise." *IEEE Transactions on Software Engineering*, 33(2), 65-86.

**[5]** Dyba, T., Arisholm, E., Sjoberg, D.I.K., Hannay, J.E. & Shull, F. (2007). "Are Two Heads Better than One? On the Effectiveness of Pair Programming." *IEEE Software*, 24(6), 12-15.

**[6]** Boehm, B. & Basili, V. (2001). "Software Defect Reduction Top 10 List." *IEEE Computer*, 34(1), 135-137.

**[7]** Sweller, J. (1988). "Cognitive Load During Problem Solving: Effects on Learning." *Cognitive Science*, 12(2), 257-285.

**[8]** Miller, G.A. (1956). "The Magical Number Seven, Plus or Minus Two." *Psychological Review*, 63(2), 81-97.

**[9]** Kahneman, D. (2011). *Thinking, Fast and Slow.* Farrar, Straus and Giroux. New York.

**[10]** Zajonc, R.B. (1965). "Social Facilitation." *Science*, 149(3681), 269-274.

**[11]** Chi, M.T.H., Bassok, M., Lewis, M.W., Reimann, P. & Glaser, R. (1989). "Self-Explanations: How Students Study and Use Examples in Learning to Solve Problems." *Cognitive Science*, 13(2), 145-182.

**[12]** Edmondson, A. (1999). "Psychological Safety and Learning Behavior in Work Teams." *Administrative Science Quarterly*, 44(2), 350-383.

**[13]** Rozovsky, J. (2015). "The Five Keys to a Successful Google Team." *re:Work*, Google.

**[14]** Fagan, M.E. (1976). "Design and Code Inspections to Reduce Errors in Program Development." *IBM Systems Journal*, 15(3), 182-211.

**[15]** DeLong, D.W. (2004). *Lost Knowledge: Confronting the Threat of an Aging Workforce.* Oxford University Press.

**[16]** Jensen, R.W. (2003). "A Pair Programming Experience." *CrossTalk: The Journal of Defense Software Engineering*, 16(3), 22-24.

**[17]** Padberg, F. & Mueller, M. (2003). "Analyzing the Cost and Benefit of Pair Programming." *Proceedings of the 9th International Software Metrics Symposium (METRICS 2003)*, IEEE, 166-177.

**[18]** Lui, K.M. & Chan, K.C.C. (2006). "Pair Programming Productivity: Novice-Novice vs. Expert-Expert." *International Journal of Human-Computer Studies*, 64(9), 915-925.

**[19]** Begel, A. & Nagappan, N. (2008). "Pair Programming: What's in it for Me?" *Proceedings of the Second ACM-IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM)*, 120-128.

**[20]** Mueller, M. (2004). "Are Reviews an Alternative to Pair Programming?" *Empirical Software Engineering*, 9(4), 335-351.

**[21]** Chong, J. & Hurlbutt, T. (2007). "The Social Dynamics of Pair Programming." *Proceedings of the 29th International Conference on Software Engineering (ICSE)*, 354-363.

**[22]** Csikszentmihalyi, M. (1990). *Flow: The Psychology of Optimal Experience.* Harper & Row. New York.

**[23]** Bacchelli, A. & Bird, C. (2013). "Expectations, Outcomes, and Challenges of Modern Code Review." *Proceedings of the 35th International Conference on Software Engineering (ICSE)*, 712-721.

**[24]** Flor, N.V. & Hutchins, E.L. (1991). "Analyzing Distributed Cognition in Software Teams: A Case Study of Team Programming During Perfective Software Maintenance." *Proceedings of the Fourth Annual Workshop on Empirical Studies of Programmers*, 36-64. Ablex Publishing.

**[25]** Collins, A., Brown, J.S. & Newman, S.E. (1989). "Cognitive Apprenticeship: Teaching the Crafts of Reading, Writing, and Mathematics." In L.B. Resnick (Ed.), *Knowing, Learning, and Instruction: Essays in Honor of Robert Glaser*, 453-494. Lawrence Erlbaum Associates.

**[26]** National Institute of Standards and Technology (2002). "The Economic Impacts of Inadequate Infrastructure for Software Testing." *NIST Planning Report 02-3.*

**[27]** Fox, M.D. et al. (2005). "The Human Brain Is Intrinsically Organized into Dynamic, Anticorrelated Functional Networks." *Proceedings of the National Academy of Sciences*, 102(27), 9673-9678.

**[28]** Dutton, J.E. & Heaphy, E.D. (2003). "The Power of High-Quality Connections." In K.S. Cameron, J.E. Dutton & R.E. Quinn (Eds.), *Positive Organizational Scholarship*, 263-278. Berrett-Koehler Publishers.

**[29]** Herbsleb, J.D. & Grinter, R.E. (1999). "Architectures, Coordination, and Distance: Conway's Law and Beyond." *IEEE Software*, 16(5), 63-70.

**[30]** Maslach, C. & Leiter, M.P. (2016). "Understanding the Burnout Experience: Recent Research and Its Implications for Psychiatry." *World Psychiatry*, 15(2), 103-111.

</small>

--- Workflow Audit para Agent Readiness: Metodología paso a paso ---
> Cómo descomponer un proceso de RRHH en puntos de decisión, clasificar cada uno para humano/regla/IA - y traducir el resultado en una especificación de Decision Layer que cumpla la impugnabilidad del EU AI Act.

## "¿Qué procesos de RRHH son aptos para IA?" es la pregunta equivocada

Una directora de RRHH se sienta en el comité de dirección de su programa de IA. En la diapositiva: "Fase 1 - automatizar el procesamiento de bajas médicas". Seis semanas después el piloto está detenido. La razón: "No funciona con suficiente fiabilidad". ¿Qué pasó? El proyecto trató el proceso como una única unidad. Pero el procesamiento de bajas médicas no es una unidad. Es una secuencia de doce puntos de decisión - y dos de ellos deberían haber permanecido con el humano.

No es una anécdota. Es el patrón. Los proyectos de IA en RRHH raramente fracasan por la calidad del modelo y casi siempre por la granularidad de la pregunta. Quien pregunta "¿Qué procesos automatizamos?" obtiene respuestas inutilizables. Quien pregunta "¿En qué puntos de decisión dentro del proceso?" obtiene una arquitectura ejecutable.

Esta metodología describe cómo hacer la pregunta correcta. Es independiente de la tecnología - sin preferencia de modelo, proveedor ni stack. De una sola auditoría produce cuatro artefactos: un diseño de agente, una plantilla de acuerdo de empresa, una especificación del Decision Layer y [la documentación que el EU AI Act exige para alto riesgo](/es/revista/eu-ai-act-aplica-en-todo-el-mundo/) (plazo vigente: 2 de agosto de 2026; aplazamiento a diciembre de 2027 acordado provisionalmente).

McKinsey [estima](https://www.mckinsey.com/capabilities/people-and-organizational-performance/our-insights/generative-ai-and-the-future-of-hr) que el 60 - 70 % de las actividades administrativas de RRHH son automatizables con tecnología existente. La adopción está en el 3 %. La brecha no nace del escepticismo. Nace de la falta de un método que descomponga el nivel de proceso al nivel de punto de decisión.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">De un vistazo</p>
<ul class="text-body text-gosign-text space-y-2">
<li>"Automatizar el proceso" fracasa. Clasificar puntos de decisión individuales construye una arquitectura auditable.</li>
<li>Un proceso típico de RRHH tiene 10 - 30 puntos de decisión. El personal experimentado toma la mayoría inconscientemente - por eso faltan en el pliego de requisitos.</li>
<li>Cada punto de decisión es humano, regla o IA - con tres pruebas claras, no con intuición. La ambigüedad es la trampa de auditoría más frecuente.</li>
<li>El resultado de la auditoría es a la vez diseño de agente, plantilla de acuerdo de empresa, especificación del Decision Layer y documentación EU AI Act. Cuatro interesados, un documento.</li>
<li>La impugnabilidad es arquitectura, no anexo de compliance. Quien la atornilla después no tiene IA auditable - independientemente de la calidad del modelo.</li>
</ul>
</div>

## Un proceso típico de RRHH tiene doce puntos de decisión, no uno

El mapeo precede a la clasificación. Falla por una peculiaridad del personal experimentado: toman muchas decisiones inconscientemente. "Comprobar si la baja tiene fecha de inicio" no lo perciben como decisión. Simplemente lo hacen. Para un agente, cada comprobación de ese tipo es una decisión explícita que debe especificarse.

El método que saca a la luz esas decisiones implícitas es la técnica del "qué podría salir mal": para cada paso, preguntar qué podría fallar o requerir otra acción. Cada respuesta revela un punto de decisión.

Antes del mapeo, traza el límite del proceso. Un proceso tiene un disparador, una secuencia de pasos de procesamiento y uno o varios puntos finales. Error frecuente: trazar el límite demasiado amplio. "Onboarding" no es un proceso - es una colección de cinco a ocho sub-procesos (contrato, IT-provisioning, documentación compliance, puesto de trabajo, alta en formaciones, asignación de buddy, seguimiento del periodo de prueba). Auditar cada sub-proceso por separado.

Con el ejemplo del procesamiento de bajas médicas - disparador: el empleado presenta una baja. Puntos finales: registro SAP actualizado, mando informado, nómina ajustada, acción de retorno al trabajo planificada si se supera el umbral. Lo que la mayoría de las organizaciones describen como un paso es una cadena de doce:

| # | Punto de decisión | Pregunta que el proceso responde |
|---|-------------------|----------------------------------|
| 1 | Recepción del documento | ¿Es baja, parte médico, certificado de rehabilitación u otro? |
| 2 | Comprobación de completitud | ¿Están nombre del empleado, periodo, médico, firma? |
| 3 | Identificación del empleado | ¿A qué empleado pertenece este documento? |
| 4 | Asignación de entidad | ¿En qué entidad legal está el empleado? |
| 5 | Lookup de convenio | ¿Qué convenio colectivo aplica? |
| 6 | Derecho a continuación del salario | ¿Periodo de 6 semanas ([§ 3 EFZG, DE](https://www.gesetze-im-internet.de/entgfg/__3.html)) cumplido? ¿Periodo de carencia? |
| 7 | Evaluación de duración | ¿Día único, ausencia corta o larga? |
| 8 | Detección de patrones | ¿Umbral de [BEM (DE)](https://www.gesetze-im-internet.de/sgb_9_2018/__167.html) superado? |
| 9 | Impacto en nómina | ¿Cancelación de horas extra, plus de turno, prorrateo de bonus? |
| 10 | Actualización del sistema | ¿Qué cambia en SAP/SuccessFactors? |
| 11 | Routing de notificaciones | ¿A quién se informa (mando, HRBP, nómina, comité de empresa)? |
| 12 | Planificación de seguimiento | ¿Fecha de retorno, invitación BEM, derivación a medicina del trabajo? |

Doce puntos de decisión en un proceso que la mayoría describe como "el empleado presenta la baja, nosotros la procesamos". La brecha entre simplicidad percibida y complejidad real es típica - y es la razón por la que "automatizamos las bajas" como objetivo no produce arquitectura.

## Tres tipos de decisión, tres pruebas, una clasificación

Cada punto de decisión pertenece a exactamente uno de tres tipos. La clasificación es binaria. La ambigüedad apunta a un error de auditoría, no a un caso especial.

**Tipo H - decide el humano.** Empatía, juicio individual, riesgo legal si se automatiza, mandato de codeterminación del Comité de Empresa o sensibilidad ética. Pregunta de prueba: "¿Llegarían dos profesionales experimentados al mismo resultado en el mismo caso?" Si no - Tipo H. El humano permanece donde la ley lo exige. No porque lo haga mejor.

**Tipo R - basado en reglas, determinista.** La regla existe por escrito (ley, convenio colectivo, acuerdo de empresa, procedimiento documentado). Los inputs son estructurados. El resultado es determinista. Las excepciones son a su vez basadas en reglas - o son puntos Tipo H separados. Pregunta de prueba: "¿Podría escribir esta decisión como fórmula de hoja de cálculo?" Si sí - Tipo R.

**Tipo A - elegible para IA, probabilístico con límites.** La tarea es clasificación, extracción o comparación - no creación, juicio o evaluación. El conjunto de resultados es conocido y finito. El resultado es verificable. Se puede fijar un umbral de confianza; los casos inciertos escalan. Pregunta de prueba: "¿Estoy interpretando información contra categorías conocidas o juzgando una situación única?" Si categorías - Tipo A.

La tabla de bajas tras la clasificación:

| # | Punto de decisión | Tipo | Razonamiento |
|---|-------------------|------|--------------|
| 1 | Clasificación del documento | A | Input no estructurado, clasificado en categorías conocidas, evaluable |
| 2 | Comprobación de completitud | A | Extracción de campos con campos obligatorios conocidos, verificable |
| 3 | Identificación del empleado | A | Coincidencia de nombre con fuzzy matching, evaluable |
| 4 | Asignación de entidad | R | ID de empleado → entidad, lookup determinista |
| 5 | Lookup de convenio | R | Entidad + categoría → convenio, determinista |
| 6 | Derecho a continuación del salario | R | Fecha + historial + § 3 EFZG, cálculo puro |
| 7 | Evaluación de duración | R | Aritmética de calendario |
| 8 | Detección de patrones | R | Cálculo de umbral (la respuesta al umbral es punto H separado) |
| 9 | Impacto en nómina | R | Tipo de ausencia + reglas de retribución |
| 10 | Actualización del sistema | R | Paso de ejecución de 4 - 9 |
| 11 | Routing de notificaciones | R | Reglas de routing de entidad, tipo, umbral |
| 12 | Planificación de seguimiento | R | Basado en reglas (la conversación en sí es H, proceso separado) |

Ocho Tipo R, tres Tipo A, ningún Tipo H. Las acciones de seguimiento que requieren juicio humano (la conversación BEM, la entrevista de retorno) son procesos separados con su propia clasificación - están fuera del procesamiento de bajas.

## El Score no dice "sí", dice "dónde permanece el humano"

De la clasificación sale una proporción simple: (Tipo R + Tipo A) ÷ total × 100. Las bajas alcanzan el 91,7 %. Es alto. No significa "menos humano". Significa que el 91,7 % de las decisiones individuales pueden tomarse arquitectónicamente - mientras la supervisión humana se concentra en lo que la ley y la empatía realmente exigen.

Los umbrales de Score son lógica de despliegue, no escala:

| Score | Lo que dice | Qué hacer |
|-------|-------------|-----------|
| > 80 % | Alta Agent Readiness | Implementar ahora. Governance se centra en los pocos handoffs H. |
| 60 - 80 % | Moderada | Por fases. R y A primero, H queda manual. Carga relevante de human-in-the-loop. |
| 40 - 60 % | Mixta | Automatizar solo los sub-procesos basados en reglas. Un agente completo aún no se justifica. |
| < 40 % | Baja | No recomendado. Documentación de procesos y estandarización primero. |

Scores típicos por dominio de RRHH: nómina y compensación 85 - 95 %, control horario 80 - 90 %, gestión de gastos 75 - 85 %, administración de onboarding 60 - 75 %, beneficios 65 - 80 %, screening de reclutamiento 40 - 55 %, gestión del desempeño 20 - 35 %, relaciones laborales 15 - 30 %. Reclutamiento y desempeño bajan no por imposibilidad técnica, sino porque son [sistemas de alto riesgo según el Anexo III del EU AI Act](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689#anx_3) y la supervisión humana pesa más.

## Un resultado de auditoría, cuatro interesados

Por punto de decisión se produce un registro estructurado: ID y descripción, clasificación con razonamiento, fuente de la regla (para R) con versión y periodo de validez, umbral de confianza (para A), ruta de escalado con plazo, especificación del audit-trail y ruta de impugnación. Ese registro tiene cuatro destinatarios:

El **equipo de ingeniería** lee la clasificación como spec de arquitectura. Donde R - rules engine; donde A - llamada al modelo con confidence-capture; donde H - tarea en cola humana. El registro especifica directamente el [Decision Layer](/es/revista/decision-layer-explicado/) - la capa entre agente y sistema destino que orquesta decisiones basadas en reglas y de IA, genera el audit-trail y enruta los escalados.

El **Comité de Empresa** lee los mismos datos como plantilla de codeterminación. Ve qué decisiones se automatizan, con qué razonamiento, con qué escalado. Un acuerdo de empresa marco puede derivarse directamente de la auditoría, a menudo más rápido que negociar acuerdos específicos por dominio.

El **auditor** lee versiones de regla y especificaciones del audit-trail como integridad de prueba. Qué regla aplicó cuándo, sobre qué datos, quién decidió. La respuesta está en el registro, no en un documento separado de compliance.

La **autoridad de protección de datos** lee los mismos datos como documentación EU AI Act y RGPD. [Art. 11 (documentación técnica)](https://eur-lex.europa.eu/legal-content/ES/TXT/?uri=CELEX:32024R1689#art_11), [Art. 12 (registro)](https://eur-lex.europa.eu/legal-content/ES/TXT/?uri=CELEX:32024R1689#art_12), [Art. 86 (derecho a explicación)](https://eur-lex.europa.eu/legal-content/ES/TXT/?uri=CELEX:32024R1689#art_86) y [Art. 22 RGPD](https://eur-lex.europa.eu/legal-content/ES/TXT/?uri=CELEX:32016R0679#art_22) requieren exactamente esa información.

Cuatro funciones de un solo documento. La auditoría no las produce como subproducto - está construida para ello.

## La impugnabilidad es arquitectura, no anexo de compliance

Una decisión automatizada sobre una persona es admisible bajo el EU AI Act y el RGPD solo si la persona afectada puede impugnarla. La impugnabilidad no es un deber atornillado a posteriori - es un requisito arquitectónico planificado desde la primera auditoría.

Por punto de decisión la auditoría aporta cuatro respuestas que en conjunto hacen posible la impugnación. ¿Qué regla o qué modelo decidió en qué versión? Sin versionado la reproducción posterior es imposible. ¿Qué datos sirvieron de base a la decisión - los inputs exactos en el momento de la decisión, no los actuales? ¿Quién decidió - humano, regla o IA - y con qué confianza? ¿Cómo puede la persona presentar recurso - con dirección concreta, plazo e instancia siguiente?

Una consecuencia de la arquitectura: el agente mismo no toma "decisiones" en sentido jurídico. Ejecuta operaciones que el Decision Layer ha autorizado. No es preciosismo semántico. Es la base que mantiene las decisiones auditables cuando se sustituye el modelo de IA, se cambia el proveedor o se descubre un fallo en el modelo.

La clasificación de alto riesgo del EU AI Act afecta directamente a muchos workflows de RRHH: screening de reclutamiento, gestión del desempeño, decisiones de promoción y traslado, asignación de turnos cuando incide en beneficios de personal (Anexo III núm. 4 lit. a y b). [Art. 26 ap. 7](https://eur-lex.europa.eu/legal-content/ES/TXT/?uri=CELEX:32024R1689#art_26) obliga adicionalmente a informar a la representación de los trabajadores y a los trabajadores afectados **antes** del despliegue - no después. La auditoría debe responder por tanto adicionalmente por workflow: ¿este workflow cae bajo el Anexo III? Si sí - se añaden las obligaciones de los art. 11, art. 14, art. 15 y art. 26, y la información previa es condición para entrar en producción.

Para organizaciones fuera de la UE: los requisitos que el EU AI Act enumera explícitamente ya son exigibles en casi cualquier sistema jurídico como interpretación de los deberes generales de diligencia - solo que sin lista clara de obligaciones. [Quien construye el Decision Layer conforme al EU AI Act](/es/revista/eu-ai-act-aplica-en-todo-el-mundo/) cumple con ello también lo que las autoridades de protección de datos californianas, brasileñas y británicas exigirán en caso de inspección.

## Cuatro errores de clasificación distorsionan cualquier auditoría

**Una regla con excepciones que requieren juicio se clasifica como Tipo R.** "Horas extra al 150 %" suena basado en reglas. Pero: ¿festivo al 200 %? ¿Turno que cruza medianoche en festivo? ¿Contrato individual que sobrescribe el convenio? Cuando las excepciones requieren juicio, la ruta de excepción es Tipo H - aunque el caso estándar sea Tipo R. Solución limpia: caso estándar como R, punto separado para gestión de excepciones como H o A.

**Un resultado de IA no verificable se clasifica como Tipo A.** "La IA evalúa si el candidato encaja culturalmente." No es Tipo A - no hay respuesta correcta verificable. El encaje cultural es subjetivo. Tipo A exige verificabilidad: "la IA clasificó este documento como baja médica" puede ser validado por dos humanos sobre el mismo documento. Las evaluaciones subjetivas son Tipo H - siempre.

**La decisión disparadora se confunde con la acción posterior.** "La detección de patrones dispara un proceso BEM" - la detección es Tipo R (umbral), pero el BEM contiene decisiones Tipo H (planificación del retorno). La auditoría debe separar el disparador del workflow disparado.

**Las decisiones implícitas se ignoran.** "Comprobamos la baja" suena a un paso. Contiene al menos tres decisiones: documento válido, completo, corresponde al empleado. La auditoría debe descomponer hasta que cada punto tenga exactamente una pregunta y una clasificación.

## Qué no resuelve esta metodología

La auditoría entrega Agent Readiness a nivel de punto de decisión y la especificación del Decision Layer. No entrega: secuenciación entre workflows (depende del volumen de transacciones, complejidad de governance, apetito organizativo; ver la [lógica H1-H4 en el catálogo de agentes RRHH](/es/catalogo-agentes-hr/#sequencing-matrix)), selección de tecnología, cambio organizativo ni la estrategia de negociación con el comité de empresa. La implementación concreta del Decision Layer - rules engine, confidence capture, endpoint de impugnación - es tema aparte.

La auditoría proporciona la base fáctica. Estrategia e implementación construyen sobre ella. Quien empieza por la estrategia y mira la base fáctica después, construye la pirámide sobre la punta.

## Artículos relacionados

- [El EU AI Act se aplica en todo el mundo](/es/revista/eu-ai-act-aplica-en-todo-el-mundo/) - por qué el deber de impugnabilidad no nace solo con el plazo de agosto de 2026
- [Tres tipos de decisiones: Cuándo el humano, cuándo la IA](/es/revista/tres-tipos-de-decisiones/) - la base conceptual de la clasificación H/R/A
- [El Decision Layer como patrón arquitectónico](/es/revista/decision-layer-explicado/) - cómo la clasificación se transfiere a una capa ejecutable
- [EU AI Act y RRHH: clasificación de alto riesgo](/es/revista/eu-ai-act-hr-alto-riesgo/) - qué workflows de RRHH caen bajo el Anexo III

--- Seguridad web según NIS2 y ENS ---
> ¿Es su sitio web conforme a los estándares de seguridad? Análisis para empresas. Detectar vulnerabilidades, cumplir NIS2 y ENS.

<!-- ¿Qué exigen los estándares? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">¿Qué exigen los estándares de seguridad para sitios web?</h2>
<p class="text-body text-gosign-text leading-relaxed">
La Directiva NIS2 obliga a operadores de infraestructuras críticas (según NIS2) a adoptar medidas de seguridad IT adecuadas. En España, el Esquema Nacional de Seguridad (ENS) y las directrices del INCIBE (Instituto Nacional de Ciberseguridad) son la referencia para el sector público y privado. Incluso empresas fuera del ámbito de infraestructuras críticas deberían orientarse por estos estándares. Gosign analiza su sitio web en busca de vulnerabilidades relevantes.
</p>
</div>
</section>

<!-- Tabla de análisis -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Qué analiza Gosign en un análisis de seguridad web</h2>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse bg-white rounded-card">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Área de análisis</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Qué se analiza</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Relevancia</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Configuración HTTPS/TLS</td>
<td class="py-3 px-4 text-body text-gosign-text">Certificado, versión de protocolo, Cipher Suites</td>
<td class="py-3 px-4 text-body text-gosign-text">Protección básica</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Content Security Policy</td>
<td class="py-3 px-4 text-body text-gosign-text">Cabecera CSP, protección XSS</td>
<td class="py-3 px-4 text-body text-gosign-text">Protección básica</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Cabeceras del servidor</td>
<td class="py-3 px-4 text-body text-gosign-text">X-Frame-Options, HSTS, Referrer-Policy</td>
<td class="py-3 px-4 text-body text-gosign-text">Protección básica</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Versión CMS y extensiones</td>
<td class="py-3 px-4 text-body text-gosign-text">Vulnerabilidades conocidas, software sin soporte</td>
<td class="py-3 px-4 text-body text-gosign-text">ENS / NIS2</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Configuración de cookies</td>
<td class="py-3 px-4 text-body text-gosign-text">Flag Secure, HttpOnly, SameSite</td>
<td class="py-3 px-4 text-body text-gosign-text">RGPD + ENS</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Autenticación</td>
<td class="py-3 px-4 text-body text-gosign-text">Protección de login, prevención de fuerza bruta, 2FA</td>
<td class="py-3 px-4 text-body text-gosign-text">ENS / NIS2</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Copias de seguridad</td>
<td class="py-3 px-4 text-body text-gosign-text">Estrategia de backup, pruebas de recuperación</td>
<td class="py-3 px-4 text-body text-gosign-text">ENS / NIS2</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Servicios -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">Servicios</h2>
<div class="grid md:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Análisis de seguridad puntual</h3>
<p class="text-body text-gosign-text">
Revisión automatizada + manual. Informe de resultados con recomendaciones de acción, priorizadas por riesgo. Acelerado por IA: resultados en horas, no semanas.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Monitorización continua</h3>
<p class="text-body text-gosign-text">
Supervisión permanente de CMS, extensiones, configuración del servidor. Notificación inmediata ante nuevas vulnerabilidades.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Fortificación e implementación</h3>
<p class="text-body text-gosign-text">
Gosign implementa las medidas recomendadas: cabeceras CSP, configuración TLS, configuración WAF, fortificación del CMS.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Documentación para auditorías</h3>
<p class="text-body text-gosign-text">
Documentación de las medidas de seguridad de su sitio web conforme al ENS. Para auditorías internas y auditores externos.
</p>
</div>
</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Analizar la seguridad de su web: 30&nbsp;minutos, gratis.</h3>
<p class="text-body text-gosign-text mb-6">Analizamos su sitio web en busca de vulnerabilidades relevantes, sin compromiso.</p>
<a
href="/es/contacto/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Solicitar análisis de seguridad
</a>
<p class="text-small text-gosign-text-light mt-4">25 años de experiencia · 800+ extensiones · Desarrollo acelerado por IA</p>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
Gosign es una agencia digital con sede en Hamburgo y 25 años de experiencia en desarrollo web, TYPO3 e integración de IA.
Hemos analizado más de 800 extensiones TYPO3 y hoy desarrollamos con apoyo de IA
hasta un 70&nbsp;% más rápido que con métodos tradicionales. Nuestros clientes son empresas
medianas, universidades e instituciones europeas.
</p>
<p class="text-small text-gosign-text-light mt-2">Actualizado: febrero 2026</p>
</div>
</section>

<!-- Temas relacionados -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Temas relacionados</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/es/sitio-web-hackeado-10-razones/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Seguridad</p>
<p class="text-body font-semibold text-gosign-dark">Sitio web hackeado: 10 razones</p>
</a>
<a href="/es/typo3-monitor-seguridad/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Monitorización</p>
<p class="text-body font-semibold text-gosign-dark">Monitor de seguridad TYPO3</p>
</a>
<a href="/es/typo3-extensions/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">CMS</p>
<p class="text-body font-semibold text-gosign-dark">Extensiones TYPO3</p>
</a>
</div>
</div>
</section>

--- Finance Agent - Decision Automation para Procesamiento de Documentos ---
> Procesamiento automatizado de documentos con decisiones a prueba de auditoría. Reglas determinísticas, Audit Trail, integración Sage y SAP

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/es/por-que-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Cada decisión rastreable</p>
</div>
</a>
<a href="/es/por-que-gosign/#infraestructura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Su infraestructura</p>
<p class="text-xs text-gosign-text-light">Sin SaaS. Sin vendor lock-in.</p>
</div>
</a>
<a href="/es/por-que-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Sin riesgo de cloud estadounidense</p>
</div>
</a>
</div>
</div>
</div>

<!-- El Problema -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">El Problema</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
En el procesamiento de documentos, las personas toman cientos de micro-decisiones diariamente: asignación de cuentas, centro de costes, inicio de depreciación, deducción de IVA, clasificación de gastos. Cada decisión se basa en un conjunto de reglas - legislación fiscal, normas contables, directrices internas, particularidades por cliente.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
El problema no es la falta de conocimiento. El problema es la inconsistencia: diferentes especialistas aplican el mismo conjunto de reglas de forma diferente. Las consecuencias: contabilizaciones correctivas, hallazgos de auditoría y reglas que solo existen en las mentes de empleados individuales.
</p>
</div>
</section>

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">eBook gratuito: IA en Finanzas</p>
<p class="text-body text-gosign-text mb-4">Compliance, auditores externos y Decision Layer - el manual de gobernanza para dirección financiera.</p>
<a href="/es/ebook/ia-finanzas-manual-gobernanza/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Descargar gratis</a>
</div>

<!-- Decision Automation -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Decision Automation - No Solo Automatización</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
El Finance Agent no es una herramienta OCR que escanea facturas. Es un sistema de Decision Automation que decide basándose en conjuntos de reglas versionados. El <a href="/es/decision-layer/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Decision Layer</a> descompone cada proceso en pasos de decisión y define para cada uno: humano, reglas o IA.
</p>
</div>
<div class="mt-8 space-y-12">
<div class="flex gap-6">
<div class="flex-shrink-0 w-12 h-12 rounded-full bg-gosign-accent/10 flex items-center justify-center">
<span class="text-lg font-bold text-gosign-accent-text">1</span>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Leer y comprender documentos</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Con comprensión lingüística real. Sin reconocimiento de plantillas, sin matching rígido de layout.</p>
</div>
</div>
<div class="flex gap-6">
<div class="flex-shrink-0 w-12 h-12 rounded-full bg-gosign-accent/10 flex items-center justify-center">
<span class="text-lg font-bold text-gosign-accent-text">2</span>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Evaluar profesionalmente</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Asignación de cuentas, centro de costes, clasificación fiscal, inicio de depreciación. Cada evaluación basada en un conjunto de reglas versionado.</p>
</div>
</div>
<div class="flex gap-6">
<div class="flex-shrink-0 w-12 h-12 rounded-full bg-gosign-accent/10 flex items-center justify-center">
<span class="text-lg font-bold text-gosign-accent-text">3</span>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Decidir</h3>
<p class="text-body-lg text-gosign-text-light mt-2">El Decision Layer enruta la evaluación: autónomamente con alta confianza y regla clara, a un humano para excepciones o baja confianza.</p>
</div>
</div>
<div class="flex gap-6">
<div class="flex-shrink-0 w-12 h-12 rounded-full bg-gosign-accent/10 flex items-center justify-center">
<span class="text-lg font-bold text-gosign-accent-text">4</span>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Documentar</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Cada micro-decisión genera un registro: entrada, regla, versión, confianza, ruta de decisión, resultado, marca temporal.</p>
</div>
</div>
</div>
</div>
</section>

<!-- Decision Flow -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Flujo de Decisión</h2>
</div>
<div class="mt-8">
<pre class="bg-gosign-dark text-white p-6 rounded-card overflow-x-auto text-small font-mono leading-relaxed"><code>Documento     →  Agente lee     →  Decision Layer
entrante         y comprende       verifica reglas
(factura,                               │
nota crédito)              ┌───────────┴────────────┐
│                        │
Alta confianza           Baja confianza
Regla clara              o excepción
│                        │
Propuesta de             Consulta a
contabilización          especialista
│                        │
Exportar a               Workflow pausado,
Sage / SAP              espera resolución
│                        │
Audit Trail              Audit Trail
completo                 completo</code></pre>
</div>
</div>
</section>

<!-- Cert-Ready -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Cert-Ready by Design</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
El Finance Agent implementa Cert-Ready by Design como caso de uso concreto:
</p>
<div class="mt-6 space-y-4">
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Portal de Auditor:</strong> Los auditores ven el estado en vivo de todos los controles - dashboard semáforo con drill-down hasta la implementación concreta de la regla.</p>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Registro de decisión por documento:</strong> No solo se almacena el resultado sino la ruta de decisión completa.</p>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Mapeo de frameworks:</strong> Controles mapeados a ISA, PS 951, IDW, GoB/GoBD (estándar alemán de contabilidad) (estándar alemán de contabilidad). Parte de nuestro enfoque <a href="/es/governance/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Governance by Design</a>.</p>
</div>
<p class="mt-4">
<a href="/es/governance/cert-ready/" class="text-gosign-accent-text font-semibold hover:text-gosign-accent-hover">Cert-Ready by Design en detalle</a>
</p>
</div>
</section>

<!-- Integración -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">Integración</h2>
<div class="grid grid-cols-1 md:grid-cols-2 gap-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Sage</h3>
<p class="text-body text-gosign-text-light mt-2">Propuestas de contabilización en formato Sage, conforme al Plan General de Contabilidad (PGC). Planes de cuentas específicos por cliente.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">SAP FI/CO</h3>
<p class="text-body text-gosign-text-light mt-2">Propuestas en formato SAP. Lógica de centros de costes y asignación de centros de beneficio. Integración vía SAP RFC o REST API.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">finAPI / Banking</h3>
<p class="text-body text-gosign-text-light mt-2">Procesamiento automático de extractos bancarios. Conciliación de pagos con partidas abiertas.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Independiente del sistema destino</h3>
<p class="text-body text-gosign-text-light mt-2">La lógica contable está separada de la exportación. Un cambio de sistema destino cambia la capa de exportación - no el agente ni los conjuntos de reglas.</p>
</div>
</div>
</div>
</section>

<!-- Grupos Objetivo -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Grupos Objetivo</h2>
<div class="mt-6 space-y-6">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Firmas de Auditoría y Contabilidad</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Cientos de clientes, miles de documentos por mes. El Finance Agent aporta consistencia en el procesamiento entre todos los clientes.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Centros de Servicios Compartidos</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Múltiples entidades, diferentes países, diferentes reglas. Donde la decisión es determinista, el Finance Agent aplica reglas específicas por cliente de forma consistente. Donde el agente tiene suficiente confianza: decide autónomamente - interpreta, clasifica, evalúa contexto.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Empresas con Contabilidad Interna</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Cierres mensuales, informes trimestrales, auditorías fiscales. Menos contabilizaciones correctivas, asignación consistente, documentación completa.</p>
</div>
</div>
</div>
</section>

<!-- Business Impact -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Impacto de Negocio</h2>
<div class="mt-6 space-y-4">
<p class="text-body-lg text-gosign-text-light">Reducir contabilizaciones correctivas mediante aplicación consistente de reglas.</p>
<p class="text-body-lg text-gosign-text-light">Acortar tiempos de procesamiento mediante procesamiento autónomo de casos rutinarios.</p>
<p class="text-body-lg text-gosign-text-light">Reducir riesgo de auditoría mediante documentación completa de decisiones.</p>
<p class="text-body-lg text-gosign-text-light">Hacer reglas explícitas en lugar de almacenarlas en mentes individuales.</p>
<p class="text-body-lg text-gosign-text-light">Escalar sin aumento proporcional de personal ante crecimiento de volumen.</p>
</div>
</div>
</section>

<!-- Profundización en el Agent Briefing -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Profundización en el Agent Briefing (Revista Gosign)</h2>
<p class="text-body text-gosign-text-light mb-6">Nuestra serie de artículos para decisores que automatizan procesos financieros con AI Agents.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/es/revista/costes-ia-tco-comparacion/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Finance</p>
<p class="text-body font-semibold text-gosign-dark">Costes de IA comparados: Análisis TCO para Enterprise</p>
</a>
<a href="/es/revista/decision-layer-shadow-ai/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer vs. Shadow AI: Por qué la Governance va antes que la velocidad</p>
</a>
<a href="/es/revista/deepseek-enterprise-hosting/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">Hosting AI: EU SaaS, centro de datos alemán o Self-Hosted?</p>
</a>
</div>
</div>
</section>

--- Co-Build - Agentes de IA individuales para su proceso ---
> Co-Build: Su proceso, su agente. En 4-6 semanas al agente de IA productivo con código fuente, Decision Layer y estrategia de salida.

<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Navegación AI Agents">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/es/servicios/ai-agents/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
AI Agents
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/es/servicios/ai-agents/document-agents/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Document</a>
<a href="/es/servicios/ai-agents/workflow-agents/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Workflow</a>
<a href="/es/servicios/ai-agents/knowledge-agents/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Knowledge</a>
<a href="/es/servicios/ai-agents/co-build/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Co-Build</a>
</div>
</div>
</nav>

<!-- De un vistazo -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h2 font-bold text-gosign-dark">De un vistazo</h2>
<div class="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-3 gap-4 mt-6">
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">4-6 semanas</p>
<p class="text-body text-gosign-text-light mt-1">Del descubrimiento al agente productivo en su infraestructura</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Código fuente completo</p>
<p class="text-body text-gosign-text-light mt-1">Código, prompts, conjuntos de reglas, documentación - acceso completo y derecho de uso permanente</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Sin SaaS</p>
<p class="text-body text-gosign-text-light mt-1">Sin cuotas mensuales. Sin vendor lock-in. Operación autónoma posible.</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Decision Layer</p>
<p class="text-body text-gosign-text-light mt-1">Cada agente con audit trail, Human-in-the-Loop y versionado de conjuntos de reglas</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Agnóstico de modelos</p>
<p class="text-body text-gosign-text-light mt-1">Claude, ChatGPT, Gemini, Llama - intercambiables sin cambios en el código</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Estrategia de salida</p>
<p class="text-body text-gosign-text-light mt-1">Formación, documentación, traspaso. Totalmente autónomo tras 12-18 meses.</p>
</div>
</div>
</div>
</div>
</section>

<!-- Tres fases -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Tres fases hacia el agente productivo</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Cada Co-Build sigue un proceso estructurado. El resultado es un agente productivo en su infraestructura - con código fuente, documentación y estrategia de salida.
</p>
</div>
<div class="grid grid-cols-1 md:grid-cols-3 gap-6 mt-8 max-w-content">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Fase 1 - Semana 1</p>
<p class="text-h3 font-bold text-gosign-dark">Discover</p>
<ul class="mt-4 space-y-2 text-body text-gosign-text-light">
<li>Análisis del proceso con su equipo especializado</li>
<li>Identificar y formalizar conjuntos de reglas</li>
<li>Mapear puntos de decisión</li>
<li>Diseño del Decision Layer</li>
<li>Clarificar paisaje de sistemas e integraciones</li>
</ul>
<p class="text-body text-gosign-text-light mt-4 font-semibold">Resultado: Blueprint del proceso con matriz de decisión</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Fase 2 - Semanas 2-5</p>
<p class="text-h3 font-bold text-gosign-dark">Build</p>
<ul class="mt-4 space-y-2 text-body text-gosign-text-light">
<li>Desarrollo del agente con su equipo</li>
<li>Implementar el Decision Layer</li>
<li>Conjuntos de reglas como configuración versionada</li>
<li>Integración de sistemas (SAP, Sage, etc.)</li>
<li>Pruebas con datos reales</li>
</ul>
<p class="text-body text-gosign-text-light mt-4 font-semibold">Resultado: Agente productivo en su infraestructura</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Fase 3 - Semanas 5-6</p>
<p class="text-h3 font-bold text-gosign-dark">Transfer</p>
<ul class="mt-4 space-y-2 text-body text-gosign-text-light">
<li>Entrega del código fuente</li>
<li>Formación del equipo para operación autónoma</li>
<li>Documentación de código, prompts, conjuntos de reglas</li>
<li>Configurar monitorización y alertas</li>
<li>Documentar estrategia de salida</li>
</ul>
<p class="text-body text-gosign-text-light mt-4 font-semibold">Resultado: Su equipo opera el agente de forma autónoma</p>
</div>
</div>
</div>
</section>

<!-- Para qué áreas -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Para qué áreas</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Co-Build es adecuado para cualquier proceso basado en conjuntos de reglas que actualmente se gestiona manualmente. Áreas típicas:
</p>
<div class="grid grid-cols-1 sm:grid-cols-2 gap-4 mt-6">
<div class="bg-gosign-light border border-gosign-border rounded-card p-4">
<p class="font-semibold text-gosign-dark text-body">Compliance y legal</p>
<p class="text-body text-gosign-text-light mt-1">Revisiones regulatorias, revisión de contratos, extracción de cláusulas, monitorización de plazos.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-4">
<p class="font-semibold text-gosign-dark text-body">Operaciones y cadena de suministro</p>
<p class="text-body text-gosign-text-light mt-1">Procesos de pedidos, gestión de proveedores, inspección de calidad, procesamiento de reclamaciones.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-4">
<p class="font-semibold text-gosign-dark text-body">Shared Services</p>
<p class="text-body text-gosign-text-light mt-1">Enrutamiento de tickets, clasificación de solicitudes, provisión interna de conocimiento, automatización de service desk.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-4">
<p class="font-semibold text-gosign-dark text-body">Específico por sector</p>
<p class="text-body text-gosign-text-light mt-1">Control de exportaciones, despacho aduanero, siniestros de seguros, evaluación crediticia - cualquier proceso basado en reglas.</p>
</div>
</div>
</div>
</div>
</section>

<!-- Qué obtiene -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Qué obtiene</h2>
<ul class="mt-6 space-y-3">
<li class="text-body-lg text-gosign-text-light"><strong>Código fuente:</strong> Código completo del agente en su repositorio</li>
<li class="text-body-lg text-gosign-text-light"><strong>Prompts:</strong> Todas las cadenas de prompts y system prompts, documentados y versionados</li>
<li class="text-body-lg text-gosign-text-light"><strong>Conjuntos de reglas:</strong> Reglas de negocio como configuración versionada, no hardcoded</li>
<li class="text-body-lg text-gosign-text-light"><strong>Decision Layer:</strong> Audit trail, Human-in-the-Loop, restricciones del Comité de Empresa (Art. 64 ET)</li>
<li class="text-body-lg text-gosign-text-light"><strong>Documentación:</strong> Arquitectura, lógica de decisión, casos de prueba, guía de despliegue</li>
<li class="text-body-lg text-gosign-text-light"><strong>Estrategia de salida:</strong> Formación, protocolo de traspaso, período de soporte</li>
</ul>
</div>
</div>
</section>

<!-- Comparación: Co-Build vs. SaaS vs. Inhouse -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Co-Build vs. SaaS vs. Inhouse</h2>
<div class="overflow-x-auto mt-6">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-dark">
<th class="py-3 pr-4 text-body font-bold text-gosign-dark"></th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Co-Build</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Plataforma SaaS</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Inhouse</th>
</tr>
</thead>
<tbody class="text-body text-gosign-text-light">
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Time-to-Value</td>
<td class="py-3 px-4">4-6 semanas</td>
<td class="py-3 px-4">2-4 semanas</td>
<td class="py-3 px-4">6-12 meses</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Acceso al código fuente</td>
<td class="py-3 px-4">Completo</td>
<td class="py-3 px-4">Sin acceso</td>
<td class="py-3 px-4">Completo</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Vendor Lock-in</td>
<td class="py-3 px-4">Ninguno</td>
<td class="py-3 px-4">Alto</td>
<td class="py-3 px-4">Ninguno</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Governance / Auditoría</td>
<td class="py-3 px-4">Decision Layer incluido</td>
<td class="py-3 px-4">Dependiente de la plataforma</td>
<td class="py-3 px-4">Debe construirse</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Costes continuos</td>
<td class="py-3 px-4">Infraestructura + mantenimiento opcional</td>
<td class="py-3 px-4">Licencia mensual</td>
<td class="py-3 px-4">Costes de personal</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Personalización</td>
<td class="py-3 px-4">Ilimitada</td>
<td class="py-3 px-4">Dentro de la plataforma</td>
<td class="py-3 px-4">Ilimitada</td>
</tr>
</tbody>
</table>
</div>
</div>
</div>
</section>

<!-- Ejemplo práctico -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h2 font-bold text-gosign-dark">Ejemplo práctico: Revisión de cumplimiento en un Shared Service Center</h2>
<p class="text-body-lg text-gosign-text-light mt-4">Un Shared Service Center revisa mensualmente 120 contratos de proveedores en materia de cumplimiento - manualmente, con listas de verificación en Excel.</p>
<div class="grid grid-cols-1 sm:grid-cols-2 gap-6 mt-8">
<div class="bg-gosign-white rounded-card p-6">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-3">Antes - manual</p>
<ul class="space-y-2 text-body text-gosign-text-light">
<li><strong>45 min</strong> por contrato (lectura, lista de verificación, documentación)</li>
<li><strong>~90 horas/mes</strong> para el equipo</li>
<li><strong>12% de errores</strong> en la detección de cláusulas</li>
<li><strong>Sin versionado</strong> de la lógica de revisión</li>
</ul>
</div>
<div class="bg-gosign-white rounded-card p-6 border-2 border-gosign-accent">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-3">Después - Co-Build Agent</p>
<ul class="space-y-2 text-body text-gosign-text-light">
<li><strong>82% autónomo</strong> revisado (contratos estándar)</li>
<li><strong>~19 horas/mes</strong> (solo excepciones + controles aleatorios)</li>
<li><strong>&lt;2% de errores</strong> mediante revisión basada en reglas</li>
<li><strong>Decision Layer</strong> con Audit Trail completo</li>
</ul>
</div>
</div>
<div class="bg-gosign-white rounded-card p-4 mt-6">
<p class="text-body text-gosign-text-light"><strong>Resultado:</strong> 71 horas ahorradas al mes. Agente productivo en 5 semanas. Código fuente, conjunto de reglas y prompts en propiedad del cliente. Operación independiente tras 14 meses sin soporte externo.</p>
</div>
</div>
</div>
</section>

<!-- Profundización en el Agent Briefing -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Profundización en el Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nuestra serie de artículos para decisores que implementan AI Agents en la empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/es/revista/costes-ia-tco-comparacion/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Costes</p>
<p class="text-body font-semibold text-gosign-dark">Lo que realmente cuesta la IA: comparación TCO para empresas</p>
</a>
<a href="/es/revista/modelo-agnostico-vendor-lock-in/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Arquitectura</p>
<p class="text-body font-semibold text-gosign-dark">Arquitectura model-agnostic - por qué el Vendor Lock-in con LLMs es peligroso</p>
</a>
<a href="/es/revista/decision-layer-explicado/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - qué es y por qué cada Enterprise AI Agent lo necesita</p>
</a>
</div>
</div>
</section>

<!-- Otros tipos de agentes -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Otros tipos de agentes</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/es/servicios/ai-agents/document-agents/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">El especialista</p>
<p class="text-body font-semibold text-gosign-dark">Document Agents</p>
<p class="text-body text-gosign-text-light mt-2">Leer, comprender y clasificar documentos - con verdadera comprensión lingüística.</p>
</a>
<a href="/es/servicios/ai-agents/workflow-agents/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">El coordinador</p>
<p class="text-body font-semibold text-gosign-dark">Workflow Agents</p>
<p class="text-body text-gosign-text-light mt-2">Orquestar procesos entre sistemas - SAP, Sage, SharePoint.</p>
</a>
<a href="/es/servicios/ai-agents/knowledge-agents/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">El portador de conocimiento</p>
<p class="text-body font-semibold text-gosign-dark">Knowledge Agents</p>
<p class="text-body text-gosign-text-light mt-2">Responder preguntas desde conjuntos de reglas - con referencia a fuentes y versión de reglas.</p>
</a>
</div>
</div>
</section>

--- Document Agents - Gestión Documental con Decision Layer ---
> Document Agents leen, comprenden y procesan documentos empresariales con comprensión lingüística real. Facturas, bajas, contratos - auditables, con Audit Trail.

<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="AI Agents Navegación">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/es/servicios/ai-agents/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
AI Agents
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/es/servicios/ai-agents/document-agents/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Document</a>
<a href="/es/servicios/ai-agents/workflow-agents/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Workflow</a>
<a href="/es/servicios/ai-agents/knowledge-agents/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Knowledge</a>
<a href="/es/servicios/ai-agents/co-build/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Co-Build</a>
</div>
</div>
</nav>

<!-- De un vistazo -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h2 font-bold text-gosign-dark">De un vistazo</h2>
<div class="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-3 gap-4 mt-6">
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">99,1% Zero-Touch</p>
<p class="text-body text-gosign-text-light mt-1">Documentos rutinarios procesados de forma autónoma - sin reprocesamiento manual</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">20+ tipos de documento</p>
<p class="text-body text-gosign-text-light mt-1">Facturas, contratos, bajas por enfermedad, resoluciones, recibos y más</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Comprensión real</p>
<p class="text-body text-gosign-text-light mt-1">Comprensión lingüística contextual en lugar de coincidencia de plantillas OCR</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Decision Layer</p>
<p class="text-body text-gosign-text-light mt-1">Cada extracción con Confidence Score, versión de regla y Audit Trail</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Agnóstico en modelos</p>
<p class="text-body text-gosign-text-light mt-1">Claude, ChatGPT, Gemini, Llama - modelo intercambiable</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">SAP, Sage, Workday</p>
<p class="text-body text-gosign-text-light mt-1">Integración vía APIs - lógica del agent desacoplada del sistema destino</p>
</div>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Definición: Document Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Un Document Agent es un AI Agent especializado para el procesamiento automático de documentos empresariales. Utiliza Large Language Models (LLM) para comprensión lingüística contextual - no coincidencia de plantillas, no reglas OCR rígidas.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
El Document Agent lee un documento, comprende su contenido y realiza una evaluación profesional. Esta evaluación es verificada por el <a href="/es/decision-layer/" class="text-gosign-accent-text hover:underline">Decision Layer</a>, documentada y registrada en el Audit Trail.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Cómo Funciona el Document Agent</h2>
<pre class="bg-gosign-dark text-white p-6 rounded-card overflow-x-auto text-small font-mono leading-relaxed mt-4"><code>Documento   →  Agent lee       →  Decision Layer verifica
(Factura)      y comprende        Completitud, Plausibilidad,
Clasificación fiscal
│
┌────────────┴────────────┐
│                         │
Alta confianza           Baja confianza
Regla clara             o caso excepcional
│                         │
Propuesta de             Escalación al
contabilización          empleado
│                         │
Audit Trail              Audit Trail
documenta                documenta</code></pre>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Qué Documentos Procesa el Document Agent</h2>
<div class="mt-6 space-y-4">
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Finance:</strong> Facturas entrantes, notas de crédito, recibos, confirmaciones de pago, extractos bancarios.</p>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">RRHH:</strong> Bajas por enfermedad, contratos laborales, modificaciones de contrato, certificados, referencias laborales.</p>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Compliance:</strong> Documentos fiscales, certificaciones, declaraciones, documentos de auditoría.</p>
</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Decision Layer para Documentos</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Cada procesamiento de documento genera un registro de decisión completo:
</p>
<ul class="mt-6 space-y-3">
<li class="text-body-lg text-gosign-text-light"><strong>Entrada:</strong> Hash del documento, tipo de documento, campos extraídos</li>
<li class="text-body-lg text-gosign-text-light"><strong>Conjunto de reglas:</strong> Regla aplicada, versión, marca de tiempo</li>
<li class="text-body-lg text-gosign-text-light"><strong>Evaluación:</strong> Confidence Score, indicador de riesgo</li>
<li class="text-body-lg text-gosign-text-light"><strong>Resultado:</strong> Propuesta de contabilización o escalación</li>
<li class="text-body-lg text-gosign-text-light"><strong>Routing:</strong> Decisión autónoma o Human-in-the-Loop</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-4">
El Document Agent no reemplaza empleados. Procesa los casos rutinarios de forma autónoma y escala las excepciones a humanos, con documentación completa. Más sobre la <a href="/es/decision-layer/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">arquitectura del Decision Layer</a>.
</p>
</div>
</section>

<!-- Comparación: Document Agent vs. solución clásica -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Document Agent vs. OCR vs. procesamiento manual</h2>
<div class="overflow-x-auto mt-6">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-dark">
<th class="py-3 pr-4 text-body font-bold text-gosign-dark"></th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Document Agent</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Sistema OCR</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Procesamiento manual</th>
</tr>
</thead>
<tbody class="text-body text-gosign-text-light">
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Comprensión</td>
<td class="py-3 px-4">Contextual - comprende contenido y significado</td>
<td class="py-3 px-4">Reconocimiento de caracteres + coincidencia de plantillas</td>
<td class="py-3 px-4">Capacidad cognitiva completa</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Texto libre / manuscrito</td>
<td class="py-3 px-4">Sí - comprensión lingüística real</td>
<td class="py-3 px-4">Limitado - falla ante desviaciones</td>
<td class="py-3 px-4">Sí</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Velocidad</td>
<td class="py-3 px-4">Segundos por documento</td>
<td class="py-3 px-4">Segundos, pero a menudo requiere reprocesamiento</td>
<td class="py-3 px-4">5-10 minutos por documento</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Escalabilidad</td>
<td class="py-3 px-4">Lineal con el volumen</td>
<td class="py-3 px-4">Lineal, pero manual ante errores</td>
<td class="py-3 px-4">Solo con más personal</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Audit Trail</td>
<td class="py-3 px-4">Automático por decisión</td>
<td class="py-3 px-4">Limitado</td>
<td class="py-3 px-4">Manual, a menudo incompleto</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Escenario práctico -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Práctica: Facturas entrantes</h2>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6 mt-6">
<p class="font-semibold text-gosign-dark text-body">Escenario: 500 facturas entrantes por mes</p>
<div class="grid grid-cols-1 sm:grid-cols-2 gap-6 mt-4">
<div>
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-text-light mb-2">Antes (manual)</p>
<ul class="space-y-1 text-body text-gosign-text-light">
<li>8 minutos por factura (revisión, contabilización, verificación)</li>
<li>~67 horas por mes</li>
<li>Tasa de error en contabilización: 4-6%</li>
<li>Audit Trail: hoja de cálculo Excel, mantenida manualmente</li>
</ul>
</div>
<div>
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Después (Document Agent)</p>
<ul class="space-y-1 text-body text-gosign-text-light">
<li>99,1% procesadas de forma autónoma (495 de 500 facturas)</li>
<li>&lt;1% escaladas al empleado (~5 facturas/mes)</li>
<li>98% de todas las consultas con el remitente del documento resueltas autónomamente</li>
<li>&lt;0,5h de esfuerzo manual por mes</li>
<li>Tasa de error: inferior al 0,3% (contabilización basada en reglas)</li>
</ul>
</div>
</div>
<p class="text-body text-gosign-text-light mt-4">
<strong>Resultado:</strong> De 67 horas a menos de 30 minutos por mes. El agente contabiliza, verifica y registra de forma autónoma. Cuando falta información (p. ej. número de pedido, centro de costes), el agente contacta directamente al remitente del documento - el 98% de estas consultas se resuelven sin intervención humana. Solo las excepciones genuinas llegan al empleado.
</p>
<div class="mt-4 bg-gosign-light border-l-4 border-gosign-accent rounded-card p-4">
<p class="text-small font-semibold text-gosign-dark">Human-in-the-Loop</p>
<p class="text-small text-gosign-text-light mt-1"><strong>El agente decide:</strong> Contabilización, propuesta de registro, condiciones de pago, consultas al remitente del documento.<br/><strong>El humano decide:</strong> Primera aprobación de proveedor, facturas por encima del umbral de aprobación, desviaciones del valor del pedido &gt;5%.</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Áreas de Aplicación</h2>
<div class="mt-6 space-y-6">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Finance y Contabilidad</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Procesamiento de facturas, contabilización, verificación de documentos. Integración con Sage, A3 y SAP FI/CO. Solución preconfigurada: <a href="/es/finance-ai-agents/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Finance AI Agents</a>.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">RRHH y People Operations</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Bajas por enfermedad, documentos contractuales, certificados. Integración con SAP SuccessFactors y Workday. Solución preconfigurada: <a href="/es/hr-ai-agents/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">HR AI Agents</a>.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Compliance y Auditoría</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Verificación automática de documentos entrantes contra políticas internas y regulaciones externas (RGPD). El <a href="/es/decision-layer/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Decision Layer</a> documenta cada decisión de verificación.
</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Integración</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Los Document Agents se conectan a sistemas existentes mediante interfaces estandarizadas:
</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light">SAP FI/CO, SAP S/4HANA</li>
<li class="text-body-lg text-gosign-text-light">Sage, A3</li>
<li class="text-body-lg text-gosign-text-light">SAP SuccessFactors, Workday</li>
<li class="text-body-lg text-gosign-text-light">SharePoint, Microsoft Teams</li>
<li class="text-body-lg text-gosign-text-light">Bandejas de correo (IMAP/Exchange)</li>
<li class="text-body-lg text-gosign-text-light">Otros vía REST/SOAP</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-4">
La lógica del agent está desacoplada del sistema destino. Un cambio de ERP modifica la capa de exportación, no el agent. ¿Necesita un agente para un proceso no cubierto por los tres tipos estándar? <a href="/es/servicios/ai-agents/co-build/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Co-Build</a> entrega agentes personalizados en 4-6 semanas.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Otros tipos de agente</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/es/servicios/ai-agents/workflow-agents/" class="group block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">El Coordinador</p>
<p class="text-body font-semibold text-gosign-dark">Workflow Agents</p>
<p class="text-body text-gosign-text-light mt-2">Orquestación de procesos entre sistemas - SAP, Sage, SharePoint.</p>
<span class="inline-flex items-center gap-1 mt-4 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Detalles <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
<a href="/es/servicios/ai-agents/knowledge-agents/" class="group block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">El Portador de Conocimiento</p>
<p class="text-body font-semibold text-gosign-dark">Knowledge Agents</p>
<p class="text-body text-gosign-text-light mt-2">Respuestas basadas en reglas - con fuente y versión de la regla.</p>
<span class="inline-flex items-center gap-1 mt-4 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Detalles <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
<a href="/es/servicios/ai-agents/co-build/" class="group block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Agentes individuales</p>
<p class="text-body font-semibold text-gosign-dark">Co-Build</p>
<p class="text-body text-gosign-text-light mt-2">Su proceso, su agente. 4-6 semanas hasta un agente productivo.</p>
<span class="inline-flex items-center gap-1 mt-4 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Detalles <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Profundización en el Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nuestra serie de artículos para ejecutivos que implementan agentes de IA en la empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/es/revista/rag-document-intelligence-enterprise/" class="group block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Documentos</p>
<p class="text-body font-semibold text-gosign-dark">RAG y Document Intelligence: Cómo la IA entiende tus documentos</p>
<span class="inline-flex items-center gap-1 mt-3 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Leer <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
<a href="/es/revista/pii-anonimizacion-llm-enterprise/" class="group block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Protección de datos</p>
<p class="text-body font-semibold text-gosign-dark">Anonimización de PII para IA Empresarial</p>
<span class="inline-flex items-center gap-1 mt-3 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Leer <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
<a href="/es/revista/decision-layer-explicado/" class="group block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Arquitectura</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - Qué es y por qué todo agente AI enterprise lo necesita</p>
<span class="inline-flex items-center gap-1 mt-3 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Leer <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
</div>
</div>
</section>

--- Knowledge Agents - Respuestas del Conocimiento Corporativo ---
> Knowledge Agents entregan respuestas contextuales de acuerdos de empresa, políticas y convenios colectivos. Con fuente, versión de regla y Audit Trail.

<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="AI Agents Navegación">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/es/servicios/ai-agents/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
AI Agents
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/es/servicios/ai-agents/document-agents/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Document</a>
<a href="/es/servicios/ai-agents/workflow-agents/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Workflow</a>
<a href="/es/servicios/ai-agents/knowledge-agents/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Knowledge</a>
<a href="/es/servicios/ai-agents/co-build/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Co-Build</a>
</div>
</div>
</nav>

<!-- De un vistazo -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h2 font-bold text-gosign-dark">De un vistazo</h2>
<div class="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-3 gap-4 mt-6">
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Fuentes verificadas</p>
<p class="text-body text-gosign-text-light mt-1">Cada respuesta con referencia de fuente, versión de regla y fecha de vigencia</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">5 anti-alucinación</p>
<p class="text-body text-gosign-text-light mt-1">Retrieval-First, verificación de fuente, Confidence, sin especulación, Audit Trail</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">4 canales</p>
<p class="text-body text-gosign-text-light mt-1">Teams Bot, SharePoint, interfaz web, API - donde trabajan sus empleados</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">RAG Pipeline</p>
<p class="text-body text-gosign-text-light mt-1">Indexación versionada de todas las fuentes de conocimiento con actualización automática</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Decision Layer</p>
<p class="text-body text-gosign-text-light mt-1">Confidence Scoring y routing - ante incertidumbre referencia en lugar de respuesta</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Respuesta inmediata</p>
<p class="text-body text-gosign-text-light mt-1">Segundos en lugar de horas - consistente en todas las sedes y zonas horarias</p>
</div>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Definición: Knowledge Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Un Knowledge Agent es un AI Agent especializado que entrega respuestas contextuales del conocimiento corporativo. Utiliza un pipeline RAG (Retrieval-Augmented Generation) para encontrar información relevante en documentos depositados y responder en el contexto correcto.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Principio central: cada respuesta incluye la referencia de fuente y la versión de la regla. Un Knowledge Agent nunca responde una pregunta sin referencia de fuente.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Principio: Sin Fuente No Hay Respuesta</h2>
<pre class="bg-gosign-dark text-white p-6 rounded-card overflow-x-auto text-small font-mono leading-relaxed mt-4"><code>Pregunta    →  Knowledge Agent    →  Decision Layer
(empleado)     busca en base         verifica fuente
de conocimiento       y confianza
│
┌────────────┴────────────┐
│                         │
Fuente encontrada         Sin fuente o
Confianza alta            reglas contradictorias
│                         │
Respuesta con fuente      Refiere al
y versión de regla        departamento responsable
│                         │
Audit Trail               Audit Trail</code></pre>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Fuentes de Conocimiento Soportadas</h2>
<div class="mt-6 space-y-4">
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">RRHH:</strong> Acuerdos de empresa (Comité de Empresa), convenios colectivos, políticas de vacaciones, reglamentos internos.</p>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Finance:</strong> Reglas contables, políticas de viaje, procesos de aprobación.</p>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Compliance:</strong> Manuales de compliance, directrices de protección de datos, procesos de auditoría.</p>
</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Seguridad Arquitectónica contra la Alucinación</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Los Knowledge Agents están diseñados para que el riesgo de alucinación se minimice arquitectónicamente:
</p>
<ol class="mt-6 space-y-3 list-decimal list-inside">
<li class="text-body-lg text-gosign-text-light"><strong>Retrieval-First:</strong> El agent busca primero los documentos relevantes antes de responder</li>
<li class="text-body-lg text-gosign-text-light"><strong>Verificación de fuente:</strong> Cada afirmación debe ser trazable a una fuente concreta</li>
<li class="text-body-lg text-gosign-text-light"><strong>Confidence Score:</strong> Con baja confianza no se responde, sino que se refiere al departamento responsable</li>
<li class="text-body-lg text-gosign-text-light"><strong>Sin especulación:</strong> Cuando la información falta o es contradictoria, el agent refiere al departamento responsable</li>
<li class="text-body-lg text-gosign-text-light"><strong>Audit Trail:</strong> Cada respuesta se documenta con fuente, versión y confianza</li>
</ol>
</div>
</section>

<!-- Comparación: Knowledge Agent vs. solución clásica -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Knowledge Agent vs. buscador empresarial vs. chatbot estándar</h2>
<div class="overflow-x-auto mt-6">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-dark">
<th class="py-3 pr-4 text-body font-bold text-gosign-dark"></th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Knowledge Agent</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Buscador empresarial</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Chatbot estándar</th>
</tr>
</thead>
<tbody class="text-body text-gosign-text-light">
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Resultado</td>
<td class="py-3 px-4">Respuesta específica con fuente</td>
<td class="py-3 px-4">Lista de documentos</td>
<td class="py-3 px-4">Respuesta generada sin garantía de fuente</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Referencia de fuente</td>
<td class="py-3 px-4">Siempre - con versión y vigencia</td>
<td class="py-3 px-4">Enlace al documento</td>
<td class="py-3 px-4">Ninguna o poco fiable</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Alucinación</td>
<td class="py-3 px-4">Prevenida arquitectónicamente (5 medidas)</td>
<td class="py-3 px-4">No aplicable</td>
<td class="py-3 px-4">Frecuente - sin control</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Ante incertidumbre</td>
<td class="py-3 px-4">Refiere al departamento responsable</td>
<td class="py-3 px-4">Muestra más resultados</td>
<td class="py-3 px-4">Da una respuesta de todos modos</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Audit Trail</td>
<td class="py-3 px-4">Completo por respuesta</td>
<td class="py-3 px-4">Protocolo de búsqueda</td>
<td class="py-3 px-4">Historial de chat</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Escenario práctico -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Práctica: Consultas RRHH</h2>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6 mt-6">
<p class="font-semibold text-gosign-dark text-body">Escenario: 200 consultas RRHH por mes (derechos de vacaciones, regulaciones especiales, acuerdos de empresa)</p>
<div class="grid grid-cols-1 sm:grid-cols-2 gap-6 mt-4">
<div>
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-text-light mb-2">Antes (manual)</p>
<ul class="space-y-1 text-body text-gosign-text-light">
<li>15 minutos por consulta (RRHH investiga, verifica acuerdo, responde)</li>
<li>~50 horas por mes</li>
<li>Respuestas inconsistentes según el responsable</li>
<li>Tiempo de espera para el empleado: horas a días</li>
</ul>
</div>
<div>
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Después (Knowledge Agent)</p>
<ul class="space-y-1 text-body text-gosign-text-light">
<li>78% respondidas inmediatamente (156 consultas) - segundos en lugar de horas</li>
<li>22% escaladas a RRHH (44 casos complejos) - con contexto</li>
<li>~11 horas por mes (solo escalaciones)</li>
<li>100% interpretación consistente de las reglas</li>
</ul>
</div>
</div>
<p class="text-body text-gosign-text-light mt-4">
<strong>Resultado:</strong> 39 horas por mes ahorradas. Los empleados reciben una respuesta verificada de inmediato. RRHH se concentra en los casos complejos que requieren criterio profesional.
</p>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Áreas de Aplicación</h2>
<div class="mt-6 space-y-6">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">RRHH y People Operations</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Preguntas sobre acuerdos de empresa (Comité de Empresa, Art. 64 ET), derechos de vacaciones, regulaciones especiales, permisos parentales, presupuestos de formación. Fin del principio de "pregunta a alguien de la oficina".
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Compliance y Regulación</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Preguntas sobre políticas internas, requisitos regulatorios, control de exportaciones, protección de datos (RGPD). Respuestas consistentes en lugar de interpretación individual.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Onboarding</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Los nuevos empleados obtienen acceso inmediato al conocimiento corporativo relevante, sin esperar a que haya colegas disponibles.
</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Integración</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Los Knowledge Agents son accesibles a través de los siguientes canales:
</p>
<ul class="mt-4 space-y-3">
<li class="text-body-lg text-gosign-text-light"><strong>Microsoft Teams Bot</strong> - directamente en el trabajo diario</li>
<li class="text-body-lg text-gosign-text-light"><strong>Integración SharePoint</strong> - integrado en la intranet</li>
<li class="text-body-lg text-gosign-text-light"><strong>Interfaz web</strong> - independiente para consultas complejas</li>
<li class="text-body-lg text-gosign-text-light"><strong>API</strong> - para integración en aplicaciones propias</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-4">
La base de conocimiento se mantiene mediante SharePoint, Confluence o carga directa de documentos.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Otros tipos de agente</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/es/servicios/ai-agents/document-agents/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">El Especialista</p>
<p class="text-body font-semibold text-gosign-dark">Document Agents</p>
<p class="text-body text-gosign-text-light mt-2">Lectura, comprensión y clasificación de documentos - con comprensión lingüística real.</p>
</a>
<a href="/es/servicios/ai-agents/workflow-agents/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">El Coordinador</p>
<p class="text-body font-semibold text-gosign-dark">Workflow Agents</p>
<p class="text-body text-gosign-text-light mt-2">Orquestación de procesos entre sistemas - SAP, Sage, SharePoint.</p>
</a>
<a href="/es/servicios/ai-agents/co-build/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Agentes individuales</p>
<p class="text-body font-semibold text-gosign-dark">Co-Build</p>
<p class="text-body text-gosign-text-light mt-2">Su proceso, su agente. 4-6 semanas hasta un agente productivo.</p>
</a>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Profundización en el Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nuestra serie de artículos para ejecutivos que implementan agentes de IA en la empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/es/revista/rag-document-intelligence-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Documentos</p>
<p class="text-body font-semibold text-gosign-dark">RAG y Document Intelligence: Cómo la IA entiende tus documentos</p>
</a>
<a href="/es/revista/human-in-the-loop-arquitectura/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Human-in-the-Loop: principio arquitectonico, no checkbox</p>
</a>
<a href="/es/revista/decision-layer-explicado/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Arquitectura</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - Qué es y por qué todo agente AI enterprise lo necesita</p>
</a>
</div>
</div>
</section>

--- Workflow Agents - Orquestación de Procesos entre Sistemas ---
> Workflow Agents orquestan procesos empresariales entre sistemas. SAP, Sage, Workday - un agent coordina el flujo. Audit Trail y Decision Layer incluidos.

<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="AI Agents Navegación">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/es/servicios/ai-agents/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
AI Agents
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/es/servicios/ai-agents/document-agents/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Document</a>
<a href="/es/servicios/ai-agents/workflow-agents/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Workflow</a>
<a href="/es/servicios/ai-agents/knowledge-agents/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Knowledge</a>
<a href="/es/servicios/ai-agents/co-build/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Co-Build</a>
</div>
</div>
</nav>

<!-- De un vistazo -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h2 font-bold text-gosign-dark">De un vistazo</h2>
<div class="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-3 gap-4 mt-6">
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">5+ sistemas</p>
<p class="text-body text-gosign-text-light mt-1">SAP, Sage, Workday, SharePoint, AD - un agent coordina todo</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Pausable</p>
<p class="text-body text-gosign-text-light mt-1">El workflow se pausa cuando el humano debe decidir - y se reanuda después</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Idempotente</p>
<p class="text-body text-gosign-text-light mt-1">Cada paso repetible sin efectos secundarios - sin contabilización doble</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Decision Layer</p>
<p class="text-body text-gosign-text-light mt-1">En cada punto de decisión: autónomo o Human-in-the-Loop</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Basado en API</p>
<p class="text-body text-gosign-text-light mt-1">Sin automatización de GUI - integración estable vía interfaces</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Audit Trail</p>
<p class="text-body text-gosign-text-light mt-1">Cada paso con timestamp, regla, versión y decisión de routing</p>
</div>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Definición: Workflow Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Un Workflow Agent es un AI Agent especializado para la orquestación de procesos empresariales entre sistemas. Coordina tareas entre múltiples sistemas - incluyendo escalación, lógica de aprobación y manejo de excepciones.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
A diferencia de RPA (Robotic Process Automation), el Workflow Agent no trabaja en las interfaces de aplicaciones, sino vía APIs y comprende el contexto profesional de las decisiones que coordina.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Ejemplo: Workflow de Baja por Enfermedad</h2>
<pre class="bg-gosign-dark text-white p-6 rounded-card overflow-x-auto text-small font-mono leading-relaxed mt-4"><code>Entrada         →  Document Agent     →  Decision Layer
(E-mail con        lee la baja           verifica Estatuto
adjunto)          y extrae datos         art. 45 y reglas int.
│
┌──────────┴──────────┐
│                     │
Conforme a reglas       Consulta necesaria
│                     │
Calcular continuidad    Empleado RRHH
salarial                es informado
│                     │
Propuesta de            Espera
contabilización SAP      decisión
│                     │
Audit Trail              Audit Trail</code></pre>
<p class="text-body-lg text-gosign-text-light mt-4">
Cada paso se registra. Cada decisión es trazable. Ante consultas o información faltante, el workflow se pausa - no se interrumpe.
</p>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Principios de Orquestación</h2>
<ul class="mt-6 space-y-4">
<li class="text-body-lg text-gosign-text-light"><strong>Entre sistemas:</strong> Un workflow puede coordinar SAP, Sage, SharePoint, correo electrónico y otros sistemas en un solo flujo</li>
<li class="text-body-lg text-gosign-text-light"><strong>Basado en decisiones:</strong> El Workflow Agent toma decisiones profesionales, no solo reglas si-entonces</li>
<li class="text-body-lg text-gosign-text-light"><strong>Pausable:</strong> Cuando falta información o se necesitan decisiones humanas, se pausa, se documenta y se reanuda tras la aclaración</li>
<li class="text-body-lg text-gosign-text-light"><strong>Auditable:</strong> Cada paso crea una entrada en el Audit Trail, incluyendo tiempos de espera y escalaciones</li>
<li class="text-body-lg text-gosign-text-light"><strong>Idempotente:</strong> Cada paso se puede reejecutar sin efectos secundarios</li>
</ul>
</div>
</section>

<!-- Comparación: Workflow Agent vs. solución clásica -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Workflow Agent vs. RPA vs. coordinación manual</h2>
<div class="overflow-x-auto mt-6">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-dark">
<th class="py-3 pr-4 text-body font-bold text-gosign-dark"></th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Workflow Agent</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">RPA Bot</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Coordinación manual</th>
</tr>
</thead>
<tbody class="text-body text-gosign-text-light">
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Control</td>
<td class="py-3 px-4">APIs + decisiones profesionales</td>
<td class="py-3 px-4">Clics de GUI en interfaces</td>
<td class="py-3 px-4">Correo, teléfono, tickets</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Estabilidad</td>
<td class="py-3 px-4">Contratos API - independiente de cambios de UI</td>
<td class="py-3 px-4">Falla ante cambios de UI</td>
<td class="py-3 px-4">Dependiente de personas</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Capacidad de decisión</td>
<td class="py-3 px-4">Decisiones profesionales basadas en conjuntos de reglas</td>
<td class="py-3 px-4">Solo reglas si-entonces</td>
<td class="py-3 px-4">Capacidad de decisión completa</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Interrupción</td>
<td class="py-3 px-4">Se pausa, espera, se reanuda</td>
<td class="py-3 px-4">Se interrumpe - requiere reinicio</td>
<td class="py-3 px-4">Espera - a menudo sin documentación</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Audit Trail</td>
<td class="py-3 px-4">Automático por paso</td>
<td class="py-3 px-4">Basado en capturas de pantalla</td>
<td class="py-3 px-4">Manual, incompleto</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Escenario práctico -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Práctica: Proceso de incorporación</h2>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6 mt-6">
<p class="font-semibold text-gosign-dark text-body">Escenario: 20 nuevos empleados por mes</p>
<div class="grid grid-cols-1 sm:grid-cols-2 gap-6 mt-4">
<div>
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-text-light mb-2">Antes (manual)</p>
<ul class="space-y-1 text-body text-gosign-text-light">
<li>3 días laborables por incorporación</li>
<li>5 sistemas actualizados manualmente (SAP, AD, correo, control horario, control de acceso)</li>
<li>Tasa de error: 12% (permisos faltantes, centro de costes incorrecto)</li>
<li>Esfuerzo RRHH: 60 horas por mes</li>
</ul>
</div>
<div>
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Después (Workflow Agent)</p>
<ul class="space-y-1 text-body text-gosign-text-light">
<li>4 horas por incorporación (incl. aprobaciones manuales)</li>
<li>5 sistemas provisionados automáticamente vía APIs</li>
<li>Tasa de error: inferior al 2% (asignación basada en reglas)</li>
<li>Esfuerzo RRHH: 15 horas por mes</li>
</ul>
</div>
</div>
<p class="text-body text-gosign-text-light mt-4">
<strong>Resultado:</strong> 75% menos esfuerzo, 85% menos errores. El Workflow Agent coordina todos los sistemas y se pausa solo donde se necesita aprobación humana - con Audit Trail completo.
</p>
</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Áreas de Aplicación</h2>
<div class="mt-6 space-y-6">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Procesos RRHH</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Onboarding (contrato, provisionamiento IT, formación), bajas por enfermedad, modificaciones de contrato, procesos de salida. Orquestación vía SAP SuccessFactors, Workday, Active Directory y correo.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Procesos Finance</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Recepción de facturas, verificación, contabilización, aprobación, registro. Orquestación vía Sage, A3, SAP FI/CO e interfaces bancarias.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Procesos Compliance</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Verificación automática contra políticas, escalación ante desviaciones, documentación en el Audit Trail. Conformidad con RGPD asegurada arquitectónicamente.
</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Decision Layer en el Workflow</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Cada paso del workflow que implica una decisión se enruta a través del Decision Layer:
</p>
<ul class="mt-6 space-y-3">
<li class="text-body-lg text-gosign-text-light"><strong>Verificación profesional:</strong> Comprobación del conjunto de reglas en cada paso de decisión</li>
<li class="text-body-lg text-gosign-text-light"><strong>Routing:</strong> Continuación autónoma o escalación a un humano</li>
<li class="text-body-lg text-gosign-text-light"><strong>Documentación:</strong> Registro de decisión completo en cada paso</li>
<li class="text-body-lg text-gosign-text-light"><strong>Versionado:</strong> Cada regla aplicada con versión y marca de tiempo</li>
</ul>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Integración</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Los Workflow Agents conectan sistemas existentes mediante interfaces estandarizadas:
</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light">SAP FI/CO, SAP S/4HANA, SAP SuccessFactors</li>
<li class="text-body-lg text-gosign-text-light">Workday</li>
<li class="text-body-lg text-gosign-text-light">Sage, A3</li>
<li class="text-body-lg text-gosign-text-light">SharePoint, Microsoft Teams (vía Microsoft Graph)</li>
<li class="text-body-lg text-gosign-text-light">Active Directory / Azure AD</li>
<li class="text-body-lg text-gosign-text-light">Correo electrónico (IMAP/Exchange)</li>
<li class="text-body-lg text-gosign-text-light">Otros vía REST/SOAP</li>
</ul>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Otros tipos de agente</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/es/servicios/ai-agents/document-agents/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">El Especialista</p>
<p class="text-body font-semibold text-gosign-dark">Document Agents</p>
<p class="text-body text-gosign-text-light mt-2">Lectura, comprensión y clasificación de documentos - con comprensión lingüística real.</p>
</a>
<a href="/es/servicios/ai-agents/knowledge-agents/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">El Portador de Conocimiento</p>
<p class="text-body font-semibold text-gosign-dark">Knowledge Agents</p>
<p class="text-body text-gosign-text-light mt-2">Respuestas basadas en reglas - con fuente y versión de la regla.</p>
</a>
<a href="/es/servicios/ai-agents/co-build/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Agentes individuales</p>
<p class="text-body font-semibold text-gosign-dark">Co-Build</p>
<p class="text-body text-gosign-text-light mt-2">Su proceso, su agente. 4-6 semanas hasta un agente productivo.</p>
</a>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Profundización en el Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nuestra serie de artículos para ejecutivos que implementan agentes de IA en la empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/es/revista/orquestacion-agentes-plataformas/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Orquestación</p>
<p class="text-body font-semibold text-gosign-dark">Orquestacion de agentes: Trigger.dev, n8n, Camunda y mas</p>
</a>
<a href="/es/revista/integracion-ia-panorama-it/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Integración</p>
<p class="text-body font-semibold text-gosign-dark">Integracion de IA en el panorama IT: SAP, Workday</p>
</a>
<a href="/es/revista/decision-layer-explicado/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Arquitectura</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - Qué es y por qué todo agente AI enterprise lo necesita</p>
</a>
</div>
</div>
</section>

--- AI Agents para Procesos Empresariales ---
> Document Agents, Workflow Agents y Knowledge Agents. AI Agents especializados con Decision Layer, Audit Trail y Human-in-the-Loop.

<!-- De un vistazo -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h2 font-bold text-gosign-dark">De un vistazo</h2>
<div class="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-3 gap-4 mt-6">
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">3 tipos de agente</p>
<p class="text-body text-gosign-text-light mt-1">Document, Workflow, Knowledge - cada uno con su propio Decision Layer</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">4-6 semanas</p>
<p class="text-body text-gosign-text-light mt-1">Del Discover al PoC productivo en su infraestructura</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">85-92% Zero-Touch</p>
<p class="text-body text-gosign-text-light mt-1">Casos rutinarios procesados autónomamente - excepciones escaladas a personas</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">7+ LLMs</p>
<p class="text-body text-gosign-text-light mt-1">Agnóstico de modelo: Claude, ChatGPT, Gemini, Llama, Mistral, DeepSeek</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Código fuente completo</p>
<p class="text-body text-gosign-text-light mt-1">Sin SaaS, sin vendor lock-in - usted posee código, prompts y reglas</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">EU AI Act ready</p>
<p class="text-body text-gosign-text-light mt-1">Audit Trail, Human-in-the-Loop, restricciones de convenios colectivos</p>
</div>
</div>
</div>
</div>
</section>

<!-- Governance-First Intro -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Construir un agente es fácil. Hacerlo Enterprise-ready no.</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Los agentes de workflow se pueden prototipar en días. El verdadero problema empieza después: ¿Es auditable la decisión del agente? ¿Cumple con los requisitos del EU AI Act? ¿Puede el Comité de Empresa (Art. 64 ET) comprender según qué reglas decide el agente?
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Exactamente ahí empezamos. No en la construcción del agente - sino en la capa de gobernanza que lo hace productivo, auditable y certificable. Los procesos empresariales se basan en conocimiento implícito: convenios colectivos, acuerdos de empresa, lógica contable. Un AI Agent estructura estas decisiones, las documenta y las hace reproducibles - en todas las sedes y operadores.
</p>
</div>
</div>
</section>

<!-- Tres tipos de agente: Resumen + Tabla comparativa -->
<section id="tipos-de-agente" class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Tres tipos de agente</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Cada proceso empresarial se puede descomponer en tres tareas: comprender documentos, coordinar flujos de trabajo y proporcionar conocimiento. Para eso existen tres tipos de agente especializados - cada uno con su propio Decision Layer y su propio Audit Trail.
</p>
</div>
<img src="/images/diagrams/agent-types-overview-es.svg" alt="Tres tipos de agente: Document Agent (El Especialista), Workflow Agent (El Coordinador), Knowledge Agent (El Experto)" class="w-full max-w-3xl mx-auto mt-8 mb-8" width="1200" height="400" loading="lazy" />
<div class="max-w-narrow">
<div class="overflow-x-auto mt-4">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-dark">
<th class="py-3 pr-4 text-body font-bold text-gosign-dark"></th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Document Agent</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Workflow Agent</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Knowledge Agent</th>
</tr>
</thead>
<tbody class="text-body text-gosign-text-light">
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Rol</td>
<td class="py-3 px-4">El Especialista</td>
<td class="py-3 px-4">El Coordinador</td>
<td class="py-3 px-4">El Experto</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Tarea</td>
<td class="py-3 px-4">Leer, comprender y clasificar documentos</td>
<td class="py-3 px-4">Orquestar procesos entre sistemas</td>
<td class="py-3 px-4">Responder preguntas desde reglas internas</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Sustituye</td>
<td class="py-3 px-4">OCR + template matching</td>
<td class="py-3 px-4">RPA + workflows manuales</td>
<td class="py-3 px-4">Buscador + chatbot</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Ejemplo</td>
<td class="py-3 px-4">Extraer y clasificar una baja médica</td>
<td class="py-3 px-4">Coordinar onboarding en SAP, AD y correo</td>
<td class="py-3 px-4">Responder días de vacaciones con cita de fuente</td>
</tr>
</tbody>
</table>
</div>
</div>

<!-- Tipo de agente 1: Document Agents -->
<div class="max-w-narrow mt-12">
<div class="flex items-start gap-4">
<span class="text-5xl font-bold text-gosign-accent/20 leading-none before:content-['01']" aria-hidden="true"></span>
<div>
<h3 class="text-h2 font-bold text-gosign-dark">Document Agents</h3>
<p class="text-body-lg text-gosign-text-light mt-2">El Especialista: comprende documentos con verdadera comprensión lingüística. Sin reconocimiento de plantillas - comprensión contextual de facturas, bajas médicas, contratos. El Decision Layer evalúa cada extracción y redirige los casos de baja confianza a un especialista.</p>
<div class="mt-4 bg-gosign-light border-l-4 border-gosign-accent rounded-card p-4">
<p class="text-small font-semibold text-gosign-dark">Human-in-the-Loop</p>
<p class="text-small text-gosign-text-light mt-1"><strong>El agente decide:</strong> Documentos estándar con alta confianza (facturas con contabilización clara, bajas médicas con plazos inequívocos).<br/><strong>El humano decide:</strong> Documentos ambiguos, importes divergentes, proveedores nuevos, documentos con cláusulas de texto libre. El agente prepara y recomienda - la aprobación final corresponde al responsable.</p>
</div>
</div>
</div>
<p class="mt-4">
<a href="/es/servicios/ai-agents/document-agents/" class="inline-flex items-center text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">
Document Agents en detalle
<svg class="w-5 h-5 ml-2" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg>
</a>
</p>
</div>

<!-- Tipo de agente 2: Workflow Agents -->
<div class="max-w-narrow mt-10">
<div class="flex items-start gap-4">
<span class="text-5xl font-bold text-gosign-accent/20 leading-none before:content-['02']" aria-hidden="true"></span>
<div>
<h3 class="text-h2 font-bold text-gosign-dark">Workflow Agents</h3>
<p class="text-body-lg text-gosign-text-light mt-2">El Coordinador: orquesta procesos entre sistemas. SAP, Sage, SharePoint, Active Directory - un agente coordina todo el flujo a través de APIs. Ante consultas, el workflow se pausa, la persona decide, y el agente continúa exactamente en ese punto.</p>
<div class="mt-4 bg-gosign-light border-l-4 border-gosign-accent rounded-card p-4">
<p class="text-small font-semibold text-gosign-dark">Human-in-the-Loop</p>
<p class="text-small text-gosign-text-light mt-1"><strong>El agente decide:</strong> Enrutamiento, asientos contables, actualizaciones de estado, notificaciones - todo según reglas definidas en el Decision Layer.<br/><strong>El humano decide:</strong> Decisiones de personal (contratación, despido, traslado), aprobaciones presupuestarias por encima de umbrales, excepciones a convenios colectivos. El flujo se detiene hasta que el humano haya decidido.</p>
</div>
</div>
</div>
<p class="mt-4">
<a href="/es/servicios/ai-agents/workflow-agents/" class="inline-flex items-center text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">
Workflow Agents en detalle
<svg class="w-5 h-5 ml-2" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg>
</a>
</p>
</div>

<!-- Tipo de agente 3: Knowledge Agents -->
<div class="max-w-narrow mt-10">
<div class="flex items-start gap-4">
<span class="text-5xl font-bold text-gosign-accent/20 leading-none before:content-['03']" aria-hidden="true"></span>
<div>
<h3 class="text-h2 font-bold text-gosign-dark">Knowledge Agents</h3>
<p class="text-body-lg text-gosign-text-light mt-2">El Experto: responde preguntas desde el conocimiento empresarial - convenios colectivos, acuerdos de empresa, políticas, normativa. Cada respuesta incluye fuente y versión de la regla. Sin fuente verificada no hay respuesta - la arquitectura previene la alucinación.</p>
<div class="mt-4 bg-gosign-light border-l-4 border-gosign-accent rounded-card p-4">
<p class="text-small font-semibold text-gosign-dark">Human-in-the-Loop</p>
<p class="text-small text-gosign-text-light mt-1"><strong>El agente decide:</strong> Consultas estándar con base de fuentes clara (derecho a vacaciones, plazo de preaviso, competencias).<br/><strong>El humano decide:</strong> Cuestiones de interpretación con conjuntos de reglas contradictorios, valoraciones de casos individuales, preguntas sobre negociaciones en curso. En caso de incertidumbre, el agente no responde sino que escala con contexto al experto responsable.</p>
</div>
</div>
</div>
<p class="mt-4">
<a href="/es/servicios/ai-agents/knowledge-agents/" class="inline-flex items-center text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">
Knowledge Agents en detalle
<svg class="w-5 h-5 ml-2" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg>
</a>
</p>
</div>
</div>
</section>

<!-- Interacción: Sistema Multi-Agent -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Interacción: tres agentes, un proceso</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
En la práctica, los tres tipos de agente trabajan juntos. Un Workflow Agent orquesta el proceso completo y llama a Document Agents y Knowledge Agents como especialistas.
</p>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6 mt-6">
<p class="font-semibold text-gosign-dark text-body">Ejemplo: baja médica de extremo a extremo</p>
<ol class="mt-3 space-y-2 text-body text-gosign-text-light list-decimal list-inside">
<li><strong>Document Agent</strong> detecta la baja médica en la bandeja de entrada, extrae nombre, período y código de diagnóstico.</li>
<li><strong>Workflow Agent</strong> consulta el sistema de RRHH: ¿Es la tercera baja en seis meses?</li>
<li><strong>Knowledge Agent</strong> es invocado: "¿A partir de qué umbral aplica la obligación de reincorporación según el convenio colectivo vigente?"</li>
<li><strong>Workflow Agent</strong> evalúa las respuestas: umbral no alcanzado - proceso estándar.</li>
<li><strong>Decision Layer</strong> verifica restricciones del convenio colectivo y legislación laboral - calcular continuidad salarial.</li>
<li><strong>Workflow Agent</strong> crea propuesta de registro en SAP, informa al responsable de RRHH, documenta en el Audit Trail.</li>
</ol>
<p class="text-body text-gosign-text-light mt-3">
Seis pasos, tres tipos de agente, tres sistemas - un Audit Trail continuo.
</p>
</div>
</div>
</div>
</section>

<!-- Mid-Page CTA -->
<section class="py-12 bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 text-center">
<p class="text-h2 font-bold text-white">¿Qué tipo de agente encaja en su proceso?</p>
<p class="text-body-lg text-white/80 mt-2">30 minutos. Su proceso. Recomendación concreta.</p>
<a href="/es/contacto/" class="inline-block mt-6 px-8 py-3 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors">Agendar reunión</a>
</div>
</section>

<!-- Soluciones de agentes especializados -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Soluciones de agentes especializados</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Document, Workflow y Knowledge Agents son los componentes base. Para HR y Finance ofrecemos soluciones preconfiguradas con reglas sectoriales. Para otros ámbitos desarrollamos agentes individuales en Co-Build.
</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-4 gap-6 mt-8 max-w-content">
<a href="/es/hr-ai-agents/" class="group block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">HR & People Operations</p>
<p class="text-body font-semibold text-gosign-dark">HR AI Agents</p>
<p class="text-body text-gosign-text-light mt-2">6 productos de agentes: Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Compatible con Comité de Empresa.</p>
<p class="text-small text-gosign-accent-text mt-2">Evaluar 48 agentes en el Assessment &rarr;</p>
<span class="inline-flex items-center gap-1 mt-2 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Vista general <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
<a href="/es/finance-ai-agents/" class="group block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Finance & Accounting</p>
<p class="text-body font-semibold text-gosign-dark">Finance AI Agents</p>
<p class="text-body text-gosign-text-light mt-2">Procesamiento de documentos, contabilización, lógica de amortización, asientos correctivos. Integración con SAP y sistemas contables.</p>
<p class="text-small text-gosign-accent-text mt-2">Evaluar 49 agentes en el Assessment &rarr;</p>
<span class="inline-flex items-center gap-1 mt-2 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Vista general <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
<a href="/es/servicios/ai-agents/co-build/" class="group block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Agentes individuales</p>
<p class="text-body font-semibold text-gosign-dark">Co-Build</p>
<p class="text-body text-gosign-text-light mt-2">Su proceso, su agente. 4-6 semanas del Discover al agente productivo con acceso al código fuente.</p>
<span class="inline-flex items-center gap-1 mt-4 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Detalles <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
<a href="/es/contacto/" class="group block bg-gosign-dark rounded-card p-6 hover:bg-gosign-dark/90 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-white/60 mb-2">Siguiente paso</p>
<p class="text-body font-semibold text-white">Agendar reunión</p>
<p class="text-body text-white/80 mt-2">30 minutos. Su caso de uso. Recomendación concreta sobre qué tipo de agente encaja.</p>
<span class="inline-flex items-center gap-1 mt-4 text-small font-semibold text-white/60 group-hover:text-white transition-colors">Agendar reunión <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
</div>
</div>
</section>

<!-- Para quién -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Para quién</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Los AI Agents afectan a distintos stakeholders. Cada uno tiene preguntas diferentes.
</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-4 gap-6 mt-8 max-w-content">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">CHRO / VP HR</p>
<p class="text-body text-gosign-text-light mt-2">Automatización de procesos de RRHH compatible con el Comité de Empresa - Payroll, Leave, Recruiting - con Audit Trail completo y cumplimiento de convenios colectivos.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">CFO / Finance Lead</p>
<p class="text-body text-gosign-text-light mt-2">Procesamiento automatizado de documentos, contabilización y conciliación de cuentas - consistente en todas las sedes, auditable para auditores externos.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Comité de Empresa</p>
<p class="text-body text-gosign-text-light mt-2">Transparencia sobre cada decisión del agente. El Decision Layer mapea convenios colectivos como restricciones explícitas. Derecho de consulta (Art. 64 ET) respetado. Human-in-the-Loop donde importa.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">CTO / IT Lead</p>
<p class="text-body text-gosign-text-light mt-2">Arquitectura agnóstica de modelo. Integración vía API en SAP, Sage, Workday. Sin vendor lock-in, acceso completo al código fuente.</p>
</div>
</div>
</div>
</section>

<!-- Decision Layer -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Decision Layer</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
El Decision Layer descompone cada proceso empresarial en pasos de decisión individuales y define para cada paso: humano, regla o IA. Cada decisión se documenta - trazable para auditores, Comité de Empresa y auditoría interna.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Diferente para cada tipo de agente: en Document Agents verifica la calidad de extracción. En Workflow Agents controla el enrutamiento. En Knowledge Agents previene la alucinación.
</p>
<p class="mt-4">
<a href="/es/decision-layer/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Decision Layer en detalle</a>
</p>
</div>
</div>
</section>

<!-- Integración + Agnosticismo de modelo -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Integración y agnosticismo de modelo</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Los AI Agents no reemplazan sistemas existentes. SAP sigue siendo ERP. Workday sigue siendo HCM. Sage sigue siendo sistema contable. La lógica del agente está desacoplada del sistema destino.
</p>
<div class="grid grid-cols-2 sm:grid-cols-3 gap-3 mt-6">
<div class="bg-gosign-white rounded-card px-4 py-3 text-body text-gosign-text-light">SAP FI/CO, S/4HANA</div>
<div class="bg-gosign-white rounded-card px-4 py-3 text-body text-gosign-text-light">SAP SuccessFactors</div>
<div class="bg-gosign-white rounded-card px-4 py-3 text-body text-gosign-text-light">Workday</div>
<div class="bg-gosign-white rounded-card px-4 py-3 text-body text-gosign-text-light">Sage</div>
<div class="bg-gosign-white rounded-card px-4 py-3 text-body text-gosign-text-light">SharePoint, Teams</div>
<div class="bg-gosign-white rounded-card px-4 py-3 text-body text-gosign-text-light">Active Directory</div>
</div>
<p class="text-body-lg text-gosign-text-light mt-6">
La arquitectura no está atada a un solo LLM: Claude, ChatGPT, Gemini, Llama, Mistral, DeepSeek - los modelos son intercambiables sin cambiar la lógica de negocio. Sin vendor lock-in.
</p>
</div>
</div>
</section>

<!-- Impacto de negocio + Propiedad -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Impacto de negocio</h2>
<ul class="mt-6 space-y-3">
<li class="text-body-lg text-gosign-text-light">Casos rutinarios procesados autónomamente - con documentación completa</li>
<li class="text-body-lg text-gosign-text-light">Misma interpretación de reglas en todas las sedes</li>
<li class="text-body-lg text-gosign-text-light">Cada decisión trazable para auditores y Comité de Empresa</li>
<li class="text-body-lg text-gosign-text-light">Escalable sin aumento proporcional de personal</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-6">
Acceso completo al código fuente, todos los prompts y reglas. Tras 12-18 meses, usted opera sus agentes de forma independiente. Sin suscripción SaaS, sin platform lock-in.
</p>
</div>
</div>
</section>

<!-- Profundización -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Profundización en el Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nuestra serie de artículos para ejecutivos que implementan AI Agents en la empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/es/revista/agentes-ia-enterprise-guia/" class="group block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors bg-gosign-white">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">AI Agents</p>
<p class="text-body font-semibold text-gosign-dark">De chatbots a agentes IA: MCP, A2A y sistemas Multi-Agent</p>
<span class="inline-flex items-center gap-1 mt-3 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Leer <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
<a href="/es/revista/orquestacion-agentes-plataformas/" class="group block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors bg-gosign-white">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">Orquestación de agentes: Trigger.dev, n8n, Camunda y alternativas</p>
<span class="inline-flex items-center gap-1 mt-3 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Leer <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
<a href="/es/revista/decision-layer-explicado/" class="group block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors bg-gosign-white">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - Qué es y por qué todo agente AI enterprise lo necesita</p>
<span class="inline-flex items-center gap-1 mt-3 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Leer <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
</div>
</div>
</section>

--- Document Intelligence - PII, Redacción de Contratos, Detección de Firmas ---
> Procesar documentos con IA de forma compatible con RGPD. Anonimización PII, redacción de contratos, detección de firmas - controlado por el Decision Layer.

<!-- El Problema -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">El Problema: Datos Personales en Cada Documento</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Las empresas quieren procesar documentos con IA - analizar contratos, clasificar facturas, consultar politicas. Pero cada documento contiene datos personales: nombres, salarios, numeros de la Seguridad Social, direcciones, datos bancarios, firmas.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Enviar estos datos a un modelo de lenguaje - incluso uno autoalojado - sin proteccion viola el principio de minimizacion de datos del RGPD. Los acuerdos de empresa restringen el procesamiento de datos de empleados. Los secretos comerciales en contratos no deben llegar a terceros.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Las soluciones actuales son insuficientes: la redaccion manual en Adobe Acrobat es lenta, propensa a errores y frecuentemente solo cosmetica - el texto permanece accesible bajo las barras negras. La alternativa es renunciar al procesamiento IA de documentos sensibles, lo que elimina la mayor parte de la ganancia de productividad.
</p>
</div>
</div>
</section>

<!-- Tres Capabilities -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">Tres Capabilities</h2>
<div class="grid grid-cols-1 md:grid-cols-3 gap-6">
<div class="bg-white rounded-card p-6 border border-gosign-border">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Anonimización PII</h3>
<p class="text-body text-gosign-text-light">Detección y pseudonimización automática de datos personales. Nombres, direcciones, IBANs, números fiscales, fechas de nacimiento. Roundtrip: pseudonimización antes del LLM, re-anonimización después. RGPD by Design.</p>
</div>
<div class="bg-white rounded-card p-6 border border-gosign-border">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Redacción de Contratos</h3>
<p class="text-body text-gosign-text-light">Redacción inteligente de contratos - dependiente del destinatario. El cliente ve campos diferentes al auditor. Matriz de redacción configurable. Físicamente seguro: el documento se re-renderiza.</p>
</div>
<div class="bg-white rounded-card p-6 border border-gosign-border">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Detección de Firmas</h3>
<p class="text-body text-gosign-text-light">Detección automática de firmas y comparación con firmas de referencia. No solo presencia, sino calidad de coincidencia. Las anomalías se escalan a humanos - el sistema nunca afirma autenticidad.</p>
</div>
</div>
</div>
</section>

<!-- Anonimizacion PII Detalle -->
<section id="anonimizacion-pii" class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Anonimizacion PII: Pseudonimizacion Roundtrip para LLM Input</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
La mayoria de las herramientas PII del mercado realizan redaccion unidireccional - eliminan datos. Para el procesamiento con modelos de lenguaje, esto es insuficiente. Cuando un agente necesita analizar un contrato, requiere contexto: "Empleado X tiene salario Y en ubicacion Z." Sin este contexto, el modelo no puede generar una evaluacion significativa.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
La solucion Gosign es la pseudonimizacion roundtrip: los datos se pseudonimizan antes del modelo, son procesados por el modelo y se re-anonimizan en el resultado. El modelo solo ve pseudonimos. El resultado contiene los datos reales.
</p>

<pre class="bg-gosign-dark text-white p-6 rounded-card overflow-x-auto text-small font-mono leading-relaxed mt-6"><code>┌─────────────┐     ┌──────────────────┐     ┌─────────────┐     ┌──────────────────┐     ┌─────────────┐
│  Documento  │     │  Deteccion PII   │     │  Pseudo-     │     │  Modelo de       │     │  Re-Mapping │
│  (Original) │────▶│  y clasifi-      │────▶│  nimizacion  │────▶│  lenguaje        │────▶│  Pseudonimos│
│             │     │  cacion          │     │              │     │  procesa solo    │     │  → datos    │
└─────────────┘     └──────────────────┘     └──────────────┘     └──────────────────┘     └─────────────┘
│                        │                                            │
▼                        ▼                                            ▼
┌──────────────┐         ┌──────────────┐                              ┌──────────────┐
│  Decision    │         │  Tabla de    │                              │  Resultado   │
│  Layer:      │         │  mapeo       │◀─────────────────────────────│  con datos   │
│  Que se      │         │  (permanece  │   Mapeo inverso              │  reales      │
│  anonimiza   │         │  local)      │                              └──────────────┘
└──────────────┘         └──────────────┘</code></pre>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">Pasos de Decision en el Proceso PII</h3>
<div class="mt-4 overflow-x-auto">
<table class="w-full text-body text-gosign-text-light border-collapse">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="text-left py-2 pr-4 font-bold text-gosign-dark">Micro-Decision</th>
<th class="text-left py-2 pr-4 font-bold text-gosign-dark">Quien Decide</th>
<th class="text-left py-2 font-bold text-gosign-dark">Por que</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Definir categorias PII</td><td class="py-2 pr-4">Humano + Reglas</td><td class="py-2">Requisitos RGPD, acuerdo de empresa, reglas del cliente</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Detectar PII en documento</td><td class="py-2 pr-4">IA (NER + patrones)</td><td class="py-2">Named Entity Recognition + patrones basados en reglas</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Revisar falsos positivos</td><td class="py-2 pr-4">IA, si incertidumbre: Humano</td><td class="py-2">Confidence Routing - "Garcia" como apellido o empresa?</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Asignar pseudonimos</td><td class="py-2 pr-4">Automatico</td><td class="py-2">Mapeo consistente, "Persona_A" en vez de "Juan Garcia"</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Enviar documento pseudonimizado al modelo</td><td class="py-2 pr-4">Automatico</td><td class="py-2">Sin decision, reenvio puro</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Re-anonimizar resultado</td><td class="py-2 pr-4">Automatico</td><td class="py-2">Aplicar tabla de mapeo en sentido inverso</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Auditoria: que se anonimizo</td><td class="py-2 pr-4">Automatico</td><td class="py-2">Evidencia RGPD en Audit Trail</td></tr>
</tbody>
</table>
</div>
<p class="text-body-lg text-gosign-text-light mt-4">
La tabla de mapeo (pseudonimo → datos reales) nunca abandona la capa de pre-procesamiento. Se elimina tras completar el procesamiento - o se retiene por un periodo definido, segun configuracion. El modelo de lenguaje nunca ve datos personales en ningun momento.
</p>
</div>
</div>
</section>

<!-- Redaccion de Contratos Detalle -->
<section id="redaccion-contratos" class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Redaccion de Contratos: Basada en Reglas, Dependiente del Destinatario, Fisica</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Los contratos necesitan compartirse regularmente en forma redactada - con auditores de cuentas, con compradores potenciales durante due diligence, con el Comite de Empresa, con asesores externos. Hoy alguien lo hace manualmente. Toma horas por contrato, es propenso a errores, y la redaccion frecuentemente es solo cosmetica: el texto permanece accesible bajo las barras negras. Una fuga de datos frecuentemente subestimada.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
La solucion Gosign: el Document Agent reconoce la estructura del contrato - partes, importes, plazos, clausulas, firmas. El Decision Layer define reglas de redaccion dependientes del destinatario:
</p>

<div class="mt-6 overflow-x-auto">
<table class="w-full text-body text-gosign-text-light border-collapse">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="text-left py-2 pr-4 font-bold text-gosign-dark">Elemento del contrato</th>
<th class="text-left py-2 pr-4 font-bold text-gosign-dark">Comite de Empresa</th>
<th class="text-left py-2 pr-4 font-bold text-gosign-dark">Due Diligence</th>
<th class="text-left py-2 pr-4 font-bold text-gosign-dark">Asesor externo</th>
<th class="text-left py-2 font-bold text-gosign-dark">Auditor de cuentas</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Partes contratantes (nombres)</td><td class="py-2 pr-4">✓ Visible</td><td class="py-2 pr-4">✗ Redactado</td><td class="py-2 pr-4">✗ Redactado</td><td class="py-2">✓ Visible</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Valores / importes del contrato</td><td class="py-2 pr-4">✓ Visible</td><td class="py-2 pr-4">✓ Visible</td><td class="py-2 pr-4">✗ Redactado</td><td class="py-2">✓ Visible</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Salarios / compensacion</td><td class="py-2 pr-4">✓ Visible</td><td class="py-2 pr-4">Agregado</td><td class="py-2 pr-4">✗ Redactado</td><td class="py-2">✓ Visible</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Clausulas contractuales</td><td class="py-2 pr-4">✓ Visible</td><td class="py-2 pr-4">✓ Visible</td><td class="py-2 pr-4">Solo tipos de clausula</td><td class="py-2">✓ Visible</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Secretos comerciales</td><td class="py-2 pr-4">✗ Redactado</td><td class="py-2 pr-4">✓ Visible</td><td class="py-2 pr-4">✗ Redactado</td><td class="py-2">✓ Visible</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Firmas</td><td class="py-2 pr-4">✗ Redactado</td><td class="py-2 pr-4">✗ Redactado</td><td class="py-2 pr-4">✗ Redactado</td><td class="py-2">✓ Visible</td></tr>
</tbody>
</table>
</div>

<p class="text-body-lg text-gosign-text-light mt-4">
Las reglas de redaccion estan versionadas en el Decision Layer. Cuando los requisitos cambian - nuevo grupo de destinatarios, acuerdo de empresa actualizado, regla de compliance modificada - se crea una nueva version de reglas. La version anterior permanece trazable.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong>Redaccion fisica:</strong> El PDF se re-renderiza desde cero. Los datos originales ya no estan fisicamente presentes en el documento - ni como texto, ni como metadatos, ni como capa invisible. Sin copiar-pegar bajo barras negras, sin edicion PDF para descubrir contenido. Esto no es cosmetico - es criptograficamente seguro.
</p>
</div>
</div>
</section>

<!-- Deteccion de Firmas Detalle -->
<section id="deteccion-firmas" class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Deteccion de Firmas: Encontrar, Verificar, Documentar</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Gestion de contratos, preparacion de auditorias, revisiones de compliance - todo requiere verificacion periodica: Esta firmado el documento? Donde esta la firma? Falta una contrafirma? Con 5.000 contratos en el archivo, la comprobacion manual no es viable.
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">Deteccion de firmas</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
El Document Agent detecta campos de firma y firmas presentes en documentos escaneados y PDFs. Computer Vision, no un modelo de lenguaje - modelos ML especializados para analisis de imagen. El resultado es estructurado: pagina, posicion, confianza de que la firma esta presente.
</p>

<p class="text-body-lg text-gosign-text-light mt-6">
<strong>Verificacion masiva de archivo:</strong> "En cuales de los 5.000 contratos falta una contrafirma?" - resultados en minutos en vez de semanas.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong>Control de calidad de onboarding:</strong> "Estan firmados todos los documentos obligatorios del nuevo empleado?" - checklist automatico, firmas faltantes escaladas como tareas de workflow.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong>Preparacion de auditoria:</strong> "Muestra todos los documentos sin firma del Q3 2025." - lista de exportacion estructurada para el auditor de cuentas.
</p>

<pre class="bg-gosign-dark text-white p-6 rounded-card overflow-x-auto text-small font-mono leading-relaxed mt-6"><code>┌─────────────┐     ┌──────────────────┐     ┌──────────────────┐
│  Documento  │     │  Deteccion       │     │  Comparacion     │
│  con        │────▶│  de firma        │────▶│  con firma       │
│  firma      │     │  (posicion,      │     │  de referencia   │
│             │     │   confianza)     │     │                  │
└─────────────┘     └──────────────────┘     └──────────────────┘
│
┌───────────┼───────────┐
▼           ▼           ▼
┌────────────┐ ┌────────┐ ┌────────────┐
│  Alta      │ │ Media  │ │  Baja      │
│  coincid.  │ │coincid.│ │  coincid.  │
└────────────┘ └────────┘ └────────────┘
│              │           │
▼              ▼           ▼
Automatica-   Escalacion   Bloqueo
mente         a humano     Revision
aceptada,     con vista    humana
documentada   comparativa  obligatoria</code></pre>

<p class="text-body-lg text-gosign-text-light mt-4">
<strong>Importante:</strong> La comparacion de firmas es un detector de anomalias, no un detector de falsificaciones. Las firmas varian naturalmente - dependen del dia, el boligrafo y la superficie. El sistema identifica anomalias y las escala a un humano. Nunca afirma "esta firma es falsa" o "esta firma es autentica". Eso seria irresponsable.
</p>
</div>
</div>
</section>

<!-- Decision Layer Matrix -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Decision Layer: Quién Decide Qué</h2>
<p class="text-body-lg text-gosign-text-light mt-4">Cada capability tiene su propio Decision Layer con puntos de decisión definidos.</p>
<div class="mt-6 overflow-x-auto">
<table class="w-full text-left text-small">
<thead>
<tr class="border-b-2 border-gosign-dark">
<th class="py-2 pr-4 font-bold">Capability</th>
<th class="py-2 pr-4 font-bold">Decisión</th>
<th class="py-2 pr-4 font-bold">Decide</th>
<th class="py-2 font-bold">Por qué</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-bold">PII</td><td class="py-2 pr-4">¿Qué categorías PII detectar?</td><td class="py-2 pr-4">Humano</td><td class="py-2">Decisión organizacional, art. 4 RGPD, acuerdo empresa</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-bold">PII</td><td class="py-2 pr-4">¿"Müller" es nombre o empresa?</td><td class="py-2 pr-4">IA, a &lt;80%: Humano</td><td class="py-2">Ambigüedad NER - evitar falsos positivos</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-bold">PII</td><td class="py-2 pr-4">Elegir método pseudonimización</td><td class="py-2 pr-4">Reglas</td><td class="py-2">Pseudónimos consistentes vs. aleatorios</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-bold">Redacción</td><td class="py-2 pr-4">¿Qué destinatarios?</td><td class="py-2 pr-4">Humano</td><td class="py-2">Decisión profesional, no automatizable</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-bold">Redacción</td><td class="py-2 pr-4">¿Qué campos se redactan?</td><td class="py-2 pr-4">Reglas</td><td class="py-2">Matriz dependiente del destinatario</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-bold">Redacción</td><td class="py-2 pr-4">Tipo de cláusula desconocido</td><td class="py-2 pr-4">Humano</td><td class="py-2">Nuevos tipos deben clasificarse</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-bold">Firma</td><td class="py-2 pr-4">¿Firma presente?</td><td class="py-2 pr-4">IA</td><td class="py-2">Computer Vision con valor de confianza</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-bold">Firma</td><td class="py-2 pr-4">¿Firma coincide con referencia?</td><td class="py-2 pr-4">IA + Humano si anomalía</td><td class="py-2">Alta coincidencia: aceptada. Anomalía: escalada</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-bold">Firma</td><td class="py-2 pr-4">Sin referencia disponible</td><td class="py-2 pr-4">Humano</td><td class="py-2">Nueva firma de referencia debe registrarse</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-bold">Todos</td><td class="py-2 pr-4">Documentar Audit Trail</td><td class="py-2 pr-4">Automático</td><td class="py-2">Cada decisión protocolada inmutablemente</td></tr>
</tbody>
</table>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Integración</h2>
<p class="text-body-lg text-gosign-text-light mt-4">Document Intelligence es una capability del Document Agent existente - no software separado.</p>
<ul class="mt-4 space-y-2 text-body-lg text-gosign-text-light list-disc pl-6">
<li>SAP DMS, SAP ArchiveLink - contratos y documentos de archivos SAP</li>
<li>SharePoint, OneDrive - gestión documental vía Microsoft Graph</li>
<li>Bandejas de e-mail (IMAP/Exchange) - adjuntos procesados automáticamente</li>
<li>File System Watcher - monitoreo de directorios locales</li>
<li>REST API - para sistemas DMS personalizados</li>
</ul>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Business Impact</h2>
<p class="text-body-lg text-gosign-text-light mt-4"><strong class="text-gosign-dark">Procesamiento LLM compatible con RGPD:</strong> Documentos con datos personales pueden procesarse por primera vez con modelos de lenguaje - sin riesgo de privacidad.</p>
<p class="text-body-lg text-gosign-text-light mt-4"><strong class="text-gosign-dark">Redacción de contratos en minutos:</strong> Basada en reglas, dependiente del destinatario, físicamente segura.</p>
<p class="text-body-lg text-gosign-text-light mt-4"><strong class="text-gosign-dark">Detección proactiva de brechas en firmas:</strong> Firmas faltantes detectadas antes de que el auditor pregunte.</p>
<p class="text-body-lg text-gosign-text-light mt-4"><strong class="text-gosign-dark">Evidencia de auditoría:</strong> Audit Trail documenta cada anonimización, cada redacción, cada verificación de firma.</p>
<p class="text-body-lg text-gosign-text-light mt-4"><strong class="text-gosign-dark">Sin herramienta nueva:</strong> Parte de la arquitectura de agents existente. Sin vendor adicional, sin licencia adicional.</p>
</div>
</section>

<!-- Profundización -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Profundización en el Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nuestra serie de artículos para ejecutivos que implementan agentes de IA en la empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/es/revista/rag-document-intelligence-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Documentos</p>
<p class="text-body font-semibold text-gosign-dark">RAG y Document Intelligence: Cómo la IA entiende tus documentos</p>
</a>
<a href="/es/revista/pii-anonimizacion-llm-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Protección de datos</p>
<p class="text-body font-semibold text-gosign-dark">Anonimización de PII para IA Empresarial</p>
</a>
<a href="/es/revista/seguridad-datos-ia-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Seguridad</p>
<p class="text-body font-semibold text-gosign-dark">Seguridad de datos en IA: Data Residency, RGPD y EU AI Act</p>
</a>
</div>
</div>
</section>

--- Firmas Digitales Conformes con eIDAS ---
> Soluciones de firma digital según el reglamento eIDAS. Firmas electrónicas simples, avanzadas y cualificadas para procesos documentales empresariales.

<!-- Reglamento eIDAS -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Reglamento eIDAS</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
El reglamento eIDAS (Reglamento (UE) N.o 910/2014) crea un marco legal europeo para la identificación electrónica y los servicios de confianza. Para procesos documentales empresariales, los tres niveles de firma son particularmente relevantes.
</p>
</div>
</section>

<!-- Tres Niveles de Firma -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Tres Niveles de Firma</h2>
<div class="mt-6 space-y-6">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Firma Electrónica Simple (FES)</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Sin requisitos técnicos especiales. Ejemplos: firma escaneada, nombre bajo un email, clic en "Acepto". Valor probatorio limitado, pero suficiente para muchos procesos empresariales.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Firma Electrónica Avanzada (AES)</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Vinculada unívocamente al firmante. Permite la identificación del firmante. Creada bajo el control exclusivo del firmante. Detecta cambios posteriores al documento. Uso: contratos, aprobaciones, procesos de autorización interna.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Firma Electrónica Cualificada (QES)</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Nivel más alto de firma. Efecto legal de una firma manuscrita (Art. 25 Párr. 2 eIDAS). Creada con un certificado de firma cualificado de un proveedor de servicios de confianza autorizado. Uso: donde se requiere forma escrita legal o máxima seguridad jurídica.
</p>
</div>
</div>
</div>
</section>

<!-- Integración Empresarial -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Integración Empresarial</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Gosign integra firmas conformes con eIDAS en procesos documentales existentes:
</p>
<div class="mt-6 space-y-4">
<p class="text-body-lg text-gosign-text-light">
<strong class="text-gosign-dark">En workflows de <a href="/es/servicios/document-intelligence/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Document Agent</a>:</strong> Después del procesamiento automatizado, puede activarse una firma digital como paso de cierre.
</p>
<p class="text-body-lg text-gosign-text-light">
<strong class="text-gosign-dark">En procesos de aprobación:</strong> Aprobaciones multietapa con firmas digitales. Cada firma se documenta en el <a href="/es/decision-layer/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Audit Trail del Decision Layer</a>.
</p>
<p class="text-body-lg text-gosign-text-light">
<strong class="text-gosign-dark">Integración API:</strong> Conexión con sistemas existentes vía REST API. La infraestructura de firma la proporciona el proveedor de servicios de confianza - Gosign implementa la integración.
</p>
</div>
</div>
</section>

<!-- Cooperación -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Cooperación con Socios Certificados ETSI</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Gosign no es un proveedor de servicios de confianza. Implementamos soluciones conformes con eIDAS en cooperación con proveedores certificados según ETSI EN 319 401.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
La elección del proveedor depende de los requisitos del cliente: nivel de firma, volumen, requisitos de integración, contratos existentes.
</p>
</div>
</section>

<!-- Cumplimiento -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Cumplimiento</h2>
<div class="mt-4 space-y-2">
<p class="text-body-lg text-gosign-text-light">Validez legal en toda la UE según el reglamento eIDAS.</p>
<p class="text-body-lg text-gosign-text-light">Conforme con RGPD (<a href="/es/governance/data-residency/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Data Residency</a> en la UE).</p>
<p class="text-body-lg text-gosign-text-light">Audit Trail para todas las operaciones de firma.</p>
<p class="text-body-lg text-gosign-text-light">Validación a largo plazo (LTV) para firmas cualificadas.</p>
</div>
</div>
</section>

<!-- Profundización en el Agent Briefing -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Profundización en el Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nuestra serie de artículos para decisores que aseguran procesos digitales en la empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/es/revista/cert-ready-by-design/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Cert-Ready by Design: Por qué la certificación retroactiva fracasa</p>
</a>
<a href="/es/revista/rag-document-intelligence-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">AI Agents</p>
<p class="text-body font-semibold text-gosign-dark">RAG y Document Intelligence en Enterprise</p>
</a>
<a href="/es/revista/seguridad-datos-ia-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">Seguridad de datos en sistemas AI Enterprise</p>
</a>
</div>
</div>
</section>

--- AI Leave Agent Aviación - gestión de ausencias ---
> Leave Decision Layer para la aviación. 3 sindicatos, EASA FTL, Medical Grounding, Crew-Pairing. 78% Zero-Touch.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/es/por-que-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Cada decisión rastreable</p>
</div>
</a>
<a href="/es/por-que-gosign/#infraestructura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Su infraestructura</p>
<p class="text-xs text-gosign-text-light">Sin SaaS. Sin vendor lock-in.</p>
</div>
</a>
<a href="/es/por-que-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Sin riesgo de cloud estadounidense</p>
</div>
</a>
</div>
</div>
</div>


<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Leave Decision Layer Sectores">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/es/servicios/hr-agent/leave-absence-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Leave Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/es/servicios/hr-agent/leave-absence-decision-layer/chemicals/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Química</a>
<a href="/es/servicios/hr-agent/leave-absence-decision-layer/aviation/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Aviación</a>
<a href="/es/servicios/hr-agent/leave-absence-decision-layer/financial-services/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Finanzas</a>
<a href="/es/servicios/hr-agent/leave-absence-decision-layer/retail/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Comercio</a>
</div>
</div>
</nav>

<!-- Complejidad -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div><span class="text-h1 font-bold text-gosign-accent-text">3</span><p class="text-small text-gosign-text-light mt-1">Sindicatos</p></div>
<div><span class="text-h1 font-bold text-gosign-accent-text">78%</span><p class="text-small text-gosign-text-light mt-1">Cuota Zero-Touch</p></div>
<div><span class="text-h1 font-bold text-gosign-accent-text">EASA</span><p class="text-small text-gosign-text-light mt-1">FTL-Compliance</p></div>
<div><div class="flex gap-1 mt-2"><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span></div><p class="text-small text-gosign-text-light mt-1">Máxima complejidad normativa</p></div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">Convenios pilotos (SEPLA), cabina (SITCPLA/USO), tierra (UGT/CCOO). Iberia, Vueling. Zero-Touch: modelo de simulación Gosign.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Lo que clasifica el Agent</p>
<h2 class="text-h1 font-bold text-gosign-dark">Cinco dimensiones, un Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Tres sindicatos con convenios propios, descansos obligatorios reglamentarios, Medical Grounding, Crew-Pairing como restricción operativa y bloqueos estacionales. Usted conoce la complejidad. Así la resuelve el AI Agent:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Tres convenios colectivos en paralelo</h3>
<p class="text-body text-gosign-text mt-2">Pilotos (SEPLA), tripulantes de cabina (SITCPLA/USO), personal de tierra (UGT/CCOO) - cada convenio tiene sus propias regulaciones de vacaciones, permisos retribuidos y compensaciones por descanso. El AI Agent reconoce el grupo de personal y aplica el reglamento correcto. Sin confusión entre vacaciones de pilotos y personal de tierra.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Descansos obligatorios EASA FTL</h3>
<p class="text-body text-gosign-text mt-2">Los Flight Time Limitations son descansos obligatorios reglamentarios que no pueden computarse como vacaciones. El AI Agent separa limpiamente: los descansos FTL se rastrean por separado, los derechos de vacaciones no se reducen por descansos obligatorios. En la planificación de vacaciones, el Agent verifica el cumplimiento FTL contra el plan de operaciones.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Medical Grounding</h3>
<p class="text-body text-gosign-text mt-2">La retirada del Medical Certificate (Clase 1 cockpit, Clase 2 cabina) no es una enfermedad común, sino una ausencia reglamentaria. El AI Agent clasifica Medical Grounding como tipo de ausencia propio con consecuencias específicas según convenio. Los datos de salud permanecen arquitectónicamente separados - el Agent solo ve el estado, no el diagnóstico.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Crew-Pairing como restricción</h3>
<p class="text-body text-gosign-text mt-2">Cockpit y cabina deben estar dotados conjuntamente para cada vuelo. El AI Agent verifica en cada solicitud de vacaciones la disponibilidad de tripulación contra el plan de vuelo y la dotación mínima por posición. En caso de infracción: escalado automático con propuesta alternativa y contexto para el scheduler.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Bloqueos estacionales de vacaciones</h3>
<p class="text-body text-gosign-text mt-2">Programa de verano y tráfico navideño significan bloqueos de vacaciones para personal de vuelo. El AI Agent conoce los periodos de bloqueo del acuerdo de empresa y verifica cada solicitud contra ellos. Las excepciones requieren decisión del responsable - el Agent documenta la excepción en el Audit Trail.</p>
</div>
</div>
</div>
</section>

<!-- Flujo de decisión -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Una solicitud de vacaciones en aviación. 10 pasos de decisión.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Un piloto presenta una solicitud de vacaciones. El Leave Decision Layer descompone el proceso en pasos de decisión individuales:</p>
<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead><tr class="border-b-2 border-gosign-border"><th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Paso</th><th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decisión</th><th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Responsable</th><th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Justificación</th></tr></thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Reconocer grupo de personal y convenio</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">El Agent reconoce: pilotos (SEPLA), cabina (SITCPLA/USO) o tierra (UGT/CCOO)</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Clasificar tipo de ausencia</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">El Agent reconoce: vacaciones, permiso retribuido, descanso FTL o Medical Grounding</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Calcular derecho a vacaciones</td><td class="py-3 px-4">Reglamento</td><td class="py-3 px-4">Vacaciones base según convenio + días adicionales (largo recorrido, antigüedad)</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Verificar EASA FTL Compliance</td><td class="py-3 px-4">Reglamento</td><td class="py-3 px-4">Descansos mínimos entre servicios, acumulación de horas de vuelo, límites de Duty Period</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Verificar Crew-Pairing y dotación mínima</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">El Agent verifica disponibilidad de tripulación contra plan de vuelo y dotación mínima por posición</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Verificar bloqueo de vacaciones</td><td class="py-3 px-4">Reglamento</td><td class="py-3 px-4">Programa de verano, tráfico navideño, periodos de bloqueo del acuerdo de empresa</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Generar recomendación de aprobación</td><td class="py-3 px-4">IA recomienda, persona decide</td><td class="py-3 px-4">Todas las reglas cumplidas: recomendación de aprobación. Conflicto: escalado con contexto</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">Verificar umbral de IT</td><td class="py-3 px-4">Reglamento</td><td class="py-3 px-4">Acumulación de días de baja en 12 meses. Medical Grounding rastreado separadamente como caso especial</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Calcular prestación por IT</td><td class="py-3 px-4">Reglamento</td><td class="py-3 px-4">Empresa: días 4-15, luego Seguridad Social. Verificar complemento según convenio específico</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Generar entrada de auditoría</td><td class="py-3 px-4">Reglamento</td><td class="py-3 px-4">Expediente completo: tipo de ausencia, convenio, estado FTL, verificación de tripulación, resultado</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Simulación -->
<section id="simulacion" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulación</p>
<h2 class="text-h1 font-bold text-white">Calculado para volúmenes de aviación</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Hemos configurado el Leave Decision Layer con parámetros realistas de aviación. Tres sindicatos, EASA FTL, Medical Grounding, Crew-Pairing.</p>
<h3 class="text-h3 font-bold text-white mt-10 mb-4">Parámetros de simulación</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Empleados</td><td class="py-3 px-4">5.000 a 80.000+ (pilotos, cabina, tierra)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Convenios</td><td class="py-3 px-4">SEPLA (pilotos), SITCPLA/USO (cabina), UGT/CCOO (tierra)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Regulación</td><td class="py-3 px-4">EASA FTL (EU-OPS), Medical Certificates Clase 1 y Clase 2</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Tipos de ausencia</td><td class="py-3 px-4">Vacaciones, descanso FTL, Medical Grounding, standby, permiso retribuido</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Restricciones</td><td class="py-3 px-4">Crew-Pairing, bloqueos estacionales, bases (MAD, BCN, internacional)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Cuota de IT</td><td class="py-3 px-4">Media sectorial aviación, Medical Grounding separado</td></tr>
</tbody>
</table>
</div>
<h3 class="text-h3 font-bold text-white mt-10 mb-4">Antes / Después</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead><tr class="border-b-2 border-white/20"><th scope="col" class="text-left py-3 px-4 font-semibold text-white">Dimensión</th><th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manual</th><th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th></tr></thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Tiempo de tramitación</td><td class="py-3 px-4">2-5 días (verificación tripulación)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 2 minutos</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Cuota Zero-Touch</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">78%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Conflictos FTL detectados</td><td class="py-3 px-4">Manualmente por scheduler</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automáticamente en tiempo real</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Medical Grounding clasificado correctamente</td><td class="py-3 px-4">Propenso a errores</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">100% correcto (tipo de ausencia propio)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Incumplimientos seguimiento IT</td><td class="py-3 px-4">12-18%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">0% (trigger automático)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Preparación para auditoría</td><td class="py-3 px-4">Reconstruida manualmente</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Generada automáticamente</td></tr>
</tbody>
</table>
</div>
<p class="text-xs text-gosign-text-on-dark/70 mt-4">EASA FTL: Reglamento UE 965/2012 Subpart FTL. Iberia, Vueling. Resultados de simulación: modelo de cálculo Gosign.</p>
<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">En la simulación, el Decision Layer alcanza una cuota Zero-Touch del 78%. La cuota más baja refleja la alta densidad regulatoria: conflictos de Crew-Pairing, clasificación de Medical Grounding y casos límite FTL requieren con más frecuencia decisiones humanas. Para el 78% existe un expediente de decisión completo y preparado para inspección.</p>
</div>
</section>

<!-- Referencia arquitectura -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Arquitectura e implementación</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">El Leave Decision Layer funciona íntegramente en su infraestructura. Para la aviación esto significa: conexión con sistemas de gestión de tripulación, seguimiento FTL, base de datos médica y Audit Trail continuo. Los pilotos típicos arrancan con un grupo de personal (p. ej. tierra) y se amplían a cockpit y cabina.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/es/servicios/hr-agent/leave-absence-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Leave Decision Layer vista general &rarr;</a>
<a href="/es/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Arquitectura del Decision Layer &rarr;</a>
<a href="/es/servicios/infraestructura/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infraestructura en detalle &rarr;</a>
<a href="/es/governance/co-determination/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Codeterminación y Comité de Empresa &rarr;</a>
<a href="/es/servicios/hr-agent/payroll-decision-layer/aviation/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Payroll Decision Layer Aviación &rarr;</a>
</div>
</div>
</section>


<!-- Weitere Agent-Lösungen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Más soluciones de agentes</h2>
<p class="text-body-lg text-gosign-text-light mt-4">Los HR Agents son parte de nuestro portfolio de agentes. Para finanzas y otras áreas ofrecemos soluciones especializadas.</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8 max-w-content">
<a href="/es/hr-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR & People Operations</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Todos los HR Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Compatible con comité de empresa.</p>
</a>
<a href="/es/finance-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Finance & Accounting</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Finance AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Procesamiento de documentos, contabilización, amortización, correcciones. Integración SAP/ERP.</p>
</a>
<a href="/es/contacto/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Individual</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Co-Build para su proceso</h3>
<p class="text-body text-gosign-text-light mt-2">Compliance, operaciones, shared services - desarrollamos agentes en modelo co-build.</p>
</a>
</div>
</div>
</section>

<!-- Profundización -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Profundización en el Agent Briefing (Revista Gosign)</h2>
<p class="text-body text-gosign-text-light mb-6">Nuestra serie de artículos especializados para responsables que implementan AI Agents en la empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/es/revista/comite-empresa-ia-codeterminacion/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors"><p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Codeterminación</p><p class="text-body font-semibold text-gosign-dark">Comité de Empresa e IA - codeterminación como restricción arquitectónica</p></a>
<a href="/es/revista/agent-governance-hr/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors"><p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p><p class="text-body font-semibold text-gosign-dark">Agent Governance para HR - Por qué los reglamentos son más importantes que los modelos</p></a>
<a href="/es/revista/decision-layer-explicado/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors"><p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Fundamentos</p><p class="text-body font-semibold text-gosign-dark">Decision Layer - ¿Qué es y por qué lo necesita cada AI Agent empresarial?</p></a>
</div>
</div>
</section>

<!-- Otros sectores -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Leave Decision Layer en otros sectores</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Cada sector tiene sus propios convenios colectivos, sus propios tipos de ausencia y sus propios factores de complejidad. El Decision Layer es el mismo. La configuración es específica de cada sector.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/es/servicios/hr-agent/leave-absence-decision-layer/chemicals/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors"><div class="flex items-center justify-between mb-3"><h3 class="text-h3 font-bold text-gosign-dark">Química</h3><div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div></div><p class="text-small text-gosign-text-light">Convenio CGIQ, vacaciones por turnicidad, IT por agentes químicos</p><div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between"><span class="text-body font-bold text-gosign-accent-text">83% Zero-Touch</span><span class="text-small text-gosign-accent-text font-semibold">En detalle &rarr;</span></div></a>
<a href="/es/servicios/hr-agent/leave-absence-decision-layer/financial-services/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors"><div class="flex items-center justify-between mb-3"><h3 class="text-h3 font-bold text-gosign-dark">Finanzas</h3><div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div></div><p class="text-small text-gosign-text-light">Desconexión obligatoria, CNMV bloques de vacaciones, festivos bursátiles, jubilación parcial</p><div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between"><span class="text-body font-bold text-gosign-accent-text">85% Zero-Touch</span><span class="text-small text-gosign-accent-text font-semibold">En detalle &rarr;</span></div></a>
<a href="/es/servicios/hr-agent/leave-absence-decision-layer/retail/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors"><div class="flex items-center justify-between mb-3"><h3 class="text-h3 font-bold text-gosign-dark">Comercio</h3><div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div></div><p class="text-small text-gosign-text-light">6 días laborables, 64% tiempo parcial, bloqueos estacionales, contratos fijos-discontinuos</p><div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between"><span class="text-body font-bold text-gosign-accent-text">87% Zero-Touch</span><span class="text-small text-gosign-accent-text font-semibold">En detalle &rarr;</span></div></a>
</div>
</div>
</section>

--- AI Leave Agent Química - gestión de ausencias ---
> Leave Decision Layer para la industria química. Convenio CGIQ, vacaciones por turnicidad, IT por agentes químicos. 83% Zero-Touch.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/es/por-que-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Cada decisión rastreable</p>
</div>
</a>
<a href="/es/por-que-gosign/#infraestructura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Su infraestructura</p>
<p class="text-xs text-gosign-text-light">Sin SaaS. Sin vendor lock-in.</p>
</div>
</a>
<a href="/es/por-que-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Sin riesgo de cloud estadounidense</p>
</div>
</a>
</div>
</div>
</div>



<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Leave Decision Layer Sectores">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/es/servicios/hr-agent/leave-absence-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Leave Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/es/servicios/hr-agent/leave-absence-decision-layer/chemicals/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Química</a>
<a href="/es/servicios/hr-agent/leave-absence-decision-layer/aviation/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Aviación</a>
<a href="/es/servicios/hr-agent/leave-absence-decision-layer/financial-services/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Finanzas</a>
<a href="/es/servicios/hr-agent/leave-absence-decision-layer/retail/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Comercio</a>
</div>
</div>
</nav>

<!-- Complejidad -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">30+</span>
<p class="text-small text-gosign-text-light mt-1">Tipos de ausencia</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">83%</span>
<p class="text-small text-gosign-text-light mt-1">Cuota Zero-Touch</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">CGIQ</span>
<p class="text-small text-gosign-text-light mt-1">Convenio sectorial</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">Máxima complejidad normativa</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">Convenio general de la industria química (CGIQ). UGT FICA / CCOO Industria. Repsol, CEPSA, BASF Spain. Zero-Touch: modelo de simulación Gosign.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Lo que clasifica el Agent</p>
<h2 class="text-h1 font-bold text-gosign-dark">Cinco dimensiones, un Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">30 días naturales de vacaciones, días adicionales por turnicidad hasta 5 días, IT por exposición a agentes químicos, dotación mínima en producción continua. Usted conoce la complejidad. Así la resuelve el AI Agent:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Vacaciones adicionales por modelo de turno</h3>
<p class="text-body text-gosign-text mt-2">Turno continuo completo 5 días, turno continuo parcial 3 días, turno rotativo 2 días. El AI Agent reconoce el modelo de turno desde el plan de turnos y asigna el descanso adicional correcto. En caso de cambio de modelo de turno, el reglamento calcula el prorrateo automáticamente - sin recálculo manual para 5.000 trabajadores a turnos.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Días libres adicionales por convenio</h3>
<p class="text-body text-gosign-text mt-2">El CGIQ contempla días adicionales por antigüedad y compensaciones específicas. El AI Agent gestiona el derecho individual, calcula los días resultantes y los registra correctamente en el saldo de vacaciones. En cambio de situación contractual: ajuste automático desde el mes siguiente.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">IT por exposición a agentes químicos</h3>
<p class="text-body text-gosign-text mt-2">En caso de IT prolongada de empleados con exposición a agentes químicos, la relevancia para seguimiento médico-laboral es especialmente alta - las enfermedades profesionales deben acompañarse con la Mutua. El AI Agent detecta la exposición desde la evaluación de riesgos INSST y marca los casos de IT para seguimiento médico-laboral. Los datos de salud permanecen arquitectónicamente separados.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Dotación mínima en producción continua</h3>
<p class="text-body text-gosign-text mt-2">En la producción química, el proceso funciona las 24 horas. El AI Agent verifica en cada solicitud de vacaciones la dotación del turno contra las reglas de dotación mínima por turno y cualificación. En caso de infracción: escalado automático con propuesta alternativa en lugar de rechazo genérico.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Vacaciones por antigüedad según convenio</h3>
<p class="text-body text-gosign-text mt-2">El convenio CGIQ establece días adicionales de vacaciones por tramos de antigüedad. El AI Agent calcula el derecho automáticamente desde la fecha de alta y el convenio aplicable. En caso de cumplimiento de tramo durante el año: cálculo proporcional desde la fecha relevante.</p>
</div>
</div>
</div>
</section>

<!-- Flujo de decisión -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Una solicitud de vacaciones en química. 10 pasos de decisión.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Un trabajador a turnos en la industria química presenta una solicitud de vacaciones. El Leave Decision Layer descompone el proceso en pasos de decisión individuales:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Paso</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decisión</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Responsable</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Justificación</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Clasificar tipo de ausencia</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">El Agent reconoce: vacaciones, descanso por turnicidad, permiso retribuido, asuntos propios o día de libre disposición</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Reconocer convenio y modelo de turno</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">El Agent reconoce centro, convenio aplicable y modelo de turno desde datos maestros y plan de turnos</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Calcular derecho total</td><td class="py-3 px-4">Reglamento</td><td class="py-3 px-4">30 días naturales base + descanso por turnicidad (2-5) + vacaciones por antigüedad + días adicionales de convenio</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Calcular saldo pendiente</td><td class="py-3 px-4">Reglamento</td><td class="py-3 px-4">Derecho total menos disfrutados y aprobados, incluyendo saldo del año anterior</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Verificar dotación mínima del turno</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">El Agent verifica dotación del turno contra reglas de dotación mínima por cualificación</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Detectar conflicto de equipo</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">El Agent verifica: bloqueos entre compañeros, solicitudes paralelas, cuota máxima de ausencia simultánea</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Generar recomendación de aprobación</td><td class="py-3 px-4">IA recomienda, persona decide</td><td class="py-3 px-4">Todas las reglas cumplidas: recomendación de aprobación. Conflicto: escalado con contexto al responsable</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">Verificar umbral de IT</td><td class="py-3 px-4">Reglamento</td><td class="py-3 px-4">Acumulación de días de baja en 12 meses (seguimiento continuo). En exposición a agentes químicos: flag adicional para seguimiento médico-laboral</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Calcular prestación por IT</td><td class="py-3 px-4">Reglamento</td><td class="py-3 px-4">Empresa: días 4-15 (60% base reguladora). Seguridad Social: desde día 16. Mutua: accidente laboral desde día 1</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Generar entrada de auditoría</td><td class="py-3 px-4">Reglamento</td><td class="py-3 px-4">Expediente de decisión completo: tipo de ausencia, derecho, pasos de verificación, resultado, marca temporal</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Simulación -->
<section id="simulacion" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulación</p>
<h2 class="text-h1 font-bold text-white">Calculado para volúmenes del sector químico</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Hemos configurado el Leave Decision Layer con parámetros realistas del sector químico español. Convenio CGIQ, modelos de turno, vacaciones por turnicidad, IT por agentes químicos.</p>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Parámetros de simulación</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Empleados</td><td class="py-3 px-4">5.000 a 50.000+ (producción, laboratorio, administración)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Convenio colectivo</td><td class="py-3 px-4">CGIQ (UGT FICA / CCOO Industria), grupos profesionales</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Vacaciones base</td><td class="py-3 px-4">30 días naturales + descanso por turnicidad (2-5 días) + antigüedad</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Modelos de turno</td><td class="py-3 px-4">Turno continuo completo, turno continuo parcial, turno rotativo, turno normal</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Días adicionales por convenio</td><td class="py-3 px-4">Días por antigüedad (elección individual)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Cuota de IT</td><td class="py-3 px-4">Media sectorial química, incluyendo exposición a agentes químicos</td></tr>
</tbody>
</table>
</div>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Antes / Después</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th scope="col" class="text-left py-3 px-4 font-semibold text-white">Dimensión</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manual</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Tiempo de tramitación de solicitud</td><td class="py-3 px-4">1-3 días</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 30 segundos</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Cuota Zero-Touch</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">83%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Incumplimientos en seguimiento de IT</td><td class="py-3 px-4">12-18% (seguimiento manual)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">0% (trigger automático)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Avisos de caducidad de vacaciones</td><td class="py-3 px-4">Frecuentemente olvidados</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automáticos, oportunos, individuales</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Cálculo de vacaciones por turnicidad</td><td class="py-3 px-4">Manual, propenso a errores</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Basado en reglas, consistente</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Preparación para auditoría</td><td class="py-3 px-4">Reconstruida manualmente</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Generada automáticamente</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">Convenio general de la industria química (CGIQ). UGT FICA / CCOO Industria. Repsol, CEPSA. Resultados de simulación: modelo de cálculo Gosign.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">En la simulación, el Decision Layer alcanza una cuota Zero-Touch del 83%. El 17% restante son excepciones reales: conflictos de vacaciones por dotación mínima, procesos de IT, cambios de situación contractual con impacto fiscal. Para el 83% existe un expediente de decisión completo y preparado para inspección.</p>
</div>
</section>

<!-- Referencia arquitectura -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Arquitectura e implementación</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">El Leave Decision Layer funciona íntegramente en su infraestructura. Para la industria química esto significa: conexión con sistemas de planificación de turnos, procesamiento de evaluaciones INSST, reglamentos por convenio aplicable y Audit Trail continuo hasta SAP HCM. Los pilotos típicos arrancan en 3 meses con un convenio y un grupo de personal.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/es/servicios/hr-agent/leave-absence-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Leave Decision Layer vista general &rarr;</a>
<a href="/es/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Arquitectura del Decision Layer &rarr;</a>
<a href="/es/servicios/infraestructura/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infraestructura en detalle &rarr;</a>
<a href="/es/governance/co-determination/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Codeterminación y Comité de Empresa &rarr;</a>
<a href="/es/servicios/hr-agent/payroll-decision-layer/chemicals/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Payroll Decision Layer Química &rarr;</a>
</div>
</div>
</section>


<!-- Weitere Agent-Lösungen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Más soluciones de agentes</h2>
<p class="text-body-lg text-gosign-text-light mt-4">Los HR Agents son parte de nuestro portfolio de agentes. Para finanzas y otras áreas ofrecemos soluciones especializadas.</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8 max-w-content">
<a href="/es/hr-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR & People Operations</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Todos los HR Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Compatible con comité de empresa.</p>
</a>
<a href="/es/finance-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Finance & Accounting</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Finance AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Procesamiento de documentos, contabilización, amortización, correcciones. Integración SAP/ERP.</p>
</a>
<a href="/es/contacto/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Individual</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Co-Build para su proceso</h3>
<p class="text-body text-gosign-text-light mt-2">Compliance, operaciones, shared services - desarrollamos agentes en modelo co-build.</p>
</a>
</div>
</div>
</section>

<!-- Profundización -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Profundización en el Agent Briefing (Revista Gosign)</h2>
<p class="text-body text-gosign-text-light mb-6">Nuestra serie de artículos especializados para responsables que implementan AI Agents en la empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/es/revista/comite-empresa-ia-codeterminacion/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Codeterminación</p>
<p class="text-body font-semibold text-gosign-dark">Comité de Empresa e IA - codeterminación como restricción arquitectónica</p>
</a>
<a href="/es/revista/agent-governance-hr/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Agent Governance para HR - Por qué los reglamentos son más importantes que los modelos</p>
</a>
<a href="/es/revista/decision-layer-explicado/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Fundamentos</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - ¿Qué es y por qué lo necesita cada AI Agent empresarial?</p>
</a>
</div>
</div>
</section>

<!-- Otros sectores -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Leave Decision Layer en otros sectores</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Cada sector tiene sus propios convenios colectivos, sus propios tipos de ausencia y sus propios factores de complejidad. El Decision Layer es el mismo. La configuración es específica de cada sector.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/es/servicios/hr-agent/leave-absence-decision-layer/aviation/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Aviación</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">3 sindicatos, EASA FTL descansos obligatorios, Medical Grounding, Crew-Pairing</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">78% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">En detalle &rarr;</span>
</div>
</a>
<a href="/es/servicios/hr-agent/leave-absence-decision-layer/financial-services/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Finanzas</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">Desconexión obligatoria, CNMV bloques de vacaciones, festivos bursátiles, jubilación parcial</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">85% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">En detalle &rarr;</span>
</div>
</a>
<a href="/es/servicios/hr-agent/leave-absence-decision-layer/retail/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Comercio</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">6 días laborables, 64% tiempo parcial, bloqueos estacionales, contratos fijos-discontinuos</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">87% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">En detalle &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- AI Leave Agent Finanzas - gestión de ausencias ---
> Leave Decision Layer para banca y seguros. Desconexión obligatoria, requisitos CNMV, festivos bursátiles. 85% Zero-Touch.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/es/por-que-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Cada decisión rastreable</p>
</div>
</a>
<a href="/es/por-que-gosign/#infraestructura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Su infraestructura</p>
<p class="text-xs text-gosign-text-light">Sin SaaS. Sin vendor lock-in.</p>
</div>
</a>
<a href="/es/por-que-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Sin riesgo de cloud estadounidense</p>
</div>
</a>
</div>
</div>
</div>
<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Leave Decision Layer Sectores">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/es/servicios/hr-agent/leave-absence-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Leave Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/es/servicios/hr-agent/leave-absence-decision-layer/chemicals/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Química</a>
<a href="/es/servicios/hr-agent/leave-absence-decision-layer/aviation/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Aviación</a>
<a href="/es/servicios/hr-agent/leave-absence-decision-layer/financial-services/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Finanzas</a>
<a href="/es/servicios/hr-agent/leave-absence-decision-layer/retail/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Comercio</a>
</div>
</div>
</nav>

<!-- Complejidad -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">5</span>
<p class="text-small text-gosign-text-light mt-1">Regímenes retributivos</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">85%</span>
<p class="text-small text-gosign-text-light mt-1">Cuota Zero-Touch</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">CNMV</span>
<p class="text-small text-gosign-text-light mt-1">Bloques obligatorios</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
<span class="w-4 h-2 rounded-sm bg-gosign-border"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">Alta complejidad normativa</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">Convenio colectivo de banca, convenio de seguros. CNMV / Banco de España. Zero-Touch: modelo de simulación Gosign.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Lo que clasifica el Agent</p>
<h2 class="text-h1 font-bold text-gosign-dark">Cinco dimensiones, un Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Desconexión obligatoria según principio de cuatro ojos, bloques obligatorios CNMV, festivos bursátiles, jubilación parcial y 5 regímenes retributivos en paralelo. Usted conoce la complejidad. Así la resuelve el AI Agent:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Desconexión obligatoria (principio de cuatro ojos)</h3>
<p class="text-body text-gosign-text mt-2">Empleados en posiciones relacionadas con operaciones de mercado deben ser desconectados al menos una vez al año de forma consecutiva. El AI Agent reconoce las posiciones sujetas a desconexión desde los datos maestros de personal, verifica si las vacaciones solicitadas cumplen la duración mínima del bloque y hace seguimiento de si la desconexión ya se ha producido en el año en curso.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Bloques de vacaciones obligatorios CNMV</h3>
<p class="text-body text-gosign-text mt-2">La regulación de CNMV y Banco de España exige bloques de vacaciones consecutivos para empleados en posiciones de riesgo relevante. El AI Agent hace seguimiento del plazo, avisa oportunamente ante bloque obligatorio pendiente y documenta el cumplimiento en el Audit Trail. En caso de inspección regulatoria: exportación del estado de cumplimiento completo por empleado.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Festivos bursátiles y calendario de trading</h3>
<p class="text-body text-gosign-text mt-2">Los festivos bursátiles no siempre coinciden con los festivos nacionales o autonómicos, pero son operativamente relevantes para los departamentos de trading. El AI Agent conoce el calendario por centro y mercado y considera los festivos bursátiles automáticamente en la planificación de dotación - sin coordinación manual de calendarios.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Jubilación parcial con contrato de relevo</h3>
<p class="text-body text-gosign-text mt-2">La jubilación parcial es habitual en el sector financiero. El AI Agent calcula el derecho a vacaciones correctamente por fase: derecho completo en la fase de trabajo, sin derecho en la fase de liberación (modelo de bloques). En modelo de jornada parcial: derecho proporcional durante toda la vigencia. Las implicaciones de Seguridad Social se comunican al sistema de nóminas.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Cinco regímenes retributivos en paralelo</h3>
<p class="text-body text-gosign-text mt-2">Convenio de banca, convenio de seguros, contratos fuera de convenio, directivos, consejo de dirección - cada régimen tiene sus propias regulaciones de vacaciones y permisos retribuidos. El AI Agent reconoce el régimen desde los datos maestros de personal y aplica el reglamento correcto. Un Agent para los cinco regímenes.</p>
</div>
</div>
</div>
</section>

<!-- Flujo de decisión -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Una solicitud de vacaciones en finanzas. 10 pasos de decisión.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Un operador de mercado presenta una solicitud de vacaciones. El Leave Decision Layer descompone el proceso en pasos de decisión individuales:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Paso</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decisión</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Responsable</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Justificación</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Clasificar tipo de ausencia</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">El Agent reconoce: vacaciones, desconexión obligatoria, fase de jubilación parcial o permiso retribuido</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Reconocer régimen retributivo</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">El Agent reconoce: convenio banca, convenio seguros, fuera de convenio, directivos o consejo</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Calcular derecho a vacaciones</td><td class="py-3 px-4">Reglamento</td><td class="py-3 px-4">30 días naturales base (convenio) o derecho individual (fuera de convenio/consejo) + corrección jubilación parcial</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Verificar desconexión obligatoria</td><td class="py-3 px-4">Reglamento</td><td class="py-3 px-4">¿Posición de mercado? ¿Duración mínima del bloque cumplida? ¿Desconexión ya realizada en el año?</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Verificar bloque obligatorio CNMV</td><td class="py-3 px-4">Reglamento</td><td class="py-3 px-4">¿Posición de riesgo relevante? ¿Bloque consecutivo ya planificado?</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Verificar festivos bursátiles y dotación</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">El Agent verifica calendario de trading, dotación mínima del departamento, sustitución</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Generar recomendación de aprobación</td><td class="py-3 px-4">IA recomienda, persona decide</td><td class="py-3 px-4">Todas las reglas y verificaciones de cumplimiento superadas: recomendación de aprobación. Conflicto de cumplimiento: escalado</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">Verificar umbral de IT</td><td class="py-3 px-4">Reglamento</td><td class="py-3 px-4">Acumulación de días de baja en 12 meses (seguimiento continuo). Trigger automático a HR y Comité de Empresa</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Calcular prestación por IT</td><td class="py-3 px-4">Reglamento</td><td class="py-3 px-4">Prestación según régimen de Seguridad Social, complemento según convenio aplicable</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Generar entrada de auditoría</td><td class="py-3 px-4">Reglamento</td><td class="py-3 px-4">Expediente de decisión completo: tipo de ausencia, régimen, estado de cumplimiento, verificación CNMV, resultado</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Simulación -->
<section id="simulacion" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulación</p>
<h2 class="text-h1 font-bold text-white">Calculado para volúmenes del sector financiero</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Hemos configurado el Leave Decision Layer con parámetros realistas del sector financiero español. Desconexión obligatoria, requisitos CNMV, festivos bursátiles, jubilación parcial.</p>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Parámetros de simulación</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Empleados</td><td class="py-3 px-4">5.000 a 80.000+ (trading, operaciones, administración)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Convenios colectivos</td><td class="py-3 px-4">Convenio banca, convenio seguros, fuera de convenio, directivos</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Regulación</td><td class="py-3 px-4">CNMV, Banco de España, desconexión obligatoria</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Tipos de ausencia</td><td class="py-3 px-4">Vacaciones, desconexión obligatoria, jubilación parcial, permiso de formación, permiso retribuido</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Restricciones</td><td class="py-3 px-4">Cuatro ojos, festivos bursátiles, dotación mínima trading</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Cuota de IT</td><td class="py-3 px-4">Media sectorial servicios financieros</td></tr>
</tbody>
</table>
</div>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Antes / Después</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th scope="col" class="text-left py-3 px-4 font-semibold text-white">Dimensión</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manual</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Tiempo de tramitación de solicitud</td><td class="py-3 px-4">1-3 días</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 30 segundos</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Cuota Zero-Touch</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">85%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Bloque obligatorio CNMV incumplido</td><td class="py-3 px-4">8-15% (seguimiento manual)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">0% (supervisión automática de plazos)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Desconexión obligatoria sin interrupciones</td><td class="py-3 px-4">Verificada manualmente</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automática, preparada para inspección</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Incumplimientos en seguimiento de IT</td><td class="py-3 px-4">12-18%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">0% (trigger automático)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Preparación para auditoría</td><td class="py-3 px-4">Reconstruida manualmente</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Generada automáticamente</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">CNMV / Banco de España. Convenios de banca y seguros. Resultados de simulación: modelo de cálculo Gosign.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">En la simulación, el Decision Layer alcanza una cuota Zero-Touch del 85%. El 15% restante son excepciones relevantes para cumplimiento: conflictos de desconexión obligatoria, transiciones de fase de jubilación parcial, acuerdos individuales fuera de convenio. Para el 85% existe un expediente de decisión completo y preparado para inspección de la CNMV.</p>
</div>
</section>

<!-- Referencia arquitectura -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Arquitectura e implementación</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">El Leave Decision Layer funciona íntegramente en su infraestructura. Para el sector financiero esto significa: conexión con calendario de trading, seguimiento de cumplimiento CNMV, monitorización de desconexión obligatoria y Audit Trail continuo. Los pilotos típicos arrancan con un régimen retributivo y se amplían a todos los grupos de personal.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/es/servicios/hr-agent/leave-absence-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Leave Decision Layer vista general &rarr;</a>
<a href="/es/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Arquitectura del Decision Layer &rarr;</a>
<a href="/es/servicios/infraestructura/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infraestructura en detalle &rarr;</a>
<a href="/es/governance/co-determination/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Codeterminación y Comité de Empresa &rarr;</a>
<a href="/es/servicios/hr-agent/payroll-decision-layer/financial-services/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Payroll Decision Layer Finanzas &rarr;</a>
</div>
</div>
</section>


<!-- Weitere Agent-Lösungen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Más soluciones de agentes</h2>
<p class="text-body-lg text-gosign-text-light mt-4">Los HR Agents son parte de nuestro portfolio de agentes. Para finanzas y otras áreas ofrecemos soluciones especializadas.</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8 max-w-content">
<a href="/es/hr-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR & People Operations</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Todos los HR Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Compatible con comité de empresa.</p>
</a>
<a href="/es/finance-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Finance & Accounting</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Finance AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Procesamiento de documentos, contabilización, amortización, correcciones. Integración SAP/ERP.</p>
</a>
<a href="/es/contacto/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Individual</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Co-Build para su proceso</h3>
<p class="text-body text-gosign-text-light mt-2">Compliance, operaciones, shared services - desarrollamos agentes en modelo co-build.</p>
</a>
</div>
</div>
</section>

<!-- Profundización -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Profundización en el Agent Briefing (Revista Gosign)</h2>
<p class="text-body text-gosign-text-light mb-6">Nuestra serie de artículos especializados para responsables que implementan AI Agents en la empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/es/revista/comite-empresa-ia-codeterminacion/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Codeterminación</p>
<p class="text-body font-semibold text-gosign-dark">Comité de Empresa e IA - codeterminación como restricción arquitectónica</p>
</a>
<a href="/es/revista/agent-governance-hr/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Agent Governance para HR - Por qué los reglamentos son más importantes que los modelos</p>
</a>
<a href="/es/revista/decision-layer-explicado/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Fundamentos</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - ¿Qué es y por qué lo necesita cada AI Agent empresarial?</p>
</a>
</div>
</div>
</section>

<!-- Otros sectores -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Leave Decision Layer en otros sectores</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Cada sector tiene sus propios convenios colectivos, sus propios tipos de ausencia y sus propios factores de complejidad. El Decision Layer es el mismo. La configuración es específica de cada sector.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/es/servicios/hr-agent/leave-absence-decision-layer/chemicals/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Química</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">Convenio CGIQ, vacaciones por turnicidad, IT por agentes químicos, dotación mínima</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">83% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">En detalle &rarr;</span>
</div>
</a>
<a href="/es/servicios/hr-agent/leave-absence-decision-layer/aviation/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Aviación</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">3 sindicatos, EASA FTL descansos obligatorios, Medical Grounding, Crew-Pairing</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">78% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">En detalle &rarr;</span>
</div>
</a>
<a href="/es/servicios/hr-agent/leave-absence-decision-layer/retail/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Comercio</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">6 días laborables, 64% tiempo parcial, bloqueos estacionales, contratos fijos-discontinuos</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">87% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">En detalle &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- AI Leave Agent Comercio - gestión de ausencias ---
> Leave Decision Layer para el comercio. Semana de 6 días, 64% tiempo parcial, bloqueos estacionales, convenios provinciales. 87% Zero-Touch.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/es/por-que-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Cada decisión rastreable</p>
</div>
</a>
<a href="/es/por-que-gosign/#infraestructura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Su infraestructura</p>
<p class="text-xs text-gosign-text-light">Sin SaaS. Sin vendor lock-in.</p>
</div>
</a>
<a href="/es/por-que-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Sin riesgo de cloud estadounidense</p>
</div>
</a>
</div>
</div>
</div>
<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Leave Decision Layer Sectores">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/es/servicios/hr-agent/leave-absence-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Leave Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/es/servicios/hr-agent/leave-absence-decision-layer/chemicals/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Química</a>
<a href="/es/servicios/hr-agent/leave-absence-decision-layer/aviation/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Aviación</a>
<a href="/es/servicios/hr-agent/leave-absence-decision-layer/financial-services/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Finanzas</a>
<a href="/es/servicios/hr-agent/leave-absence-decision-layer/retail/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Comercio</a>
</div>
</div>
</nav>

<!-- Complejidad -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">50</span>
<p class="text-small text-gosign-text-light mt-1">Convenios provinciales</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">87%</span>
<p class="text-small text-gosign-text-light mt-1">Cuota Zero-Touch</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">64%</span>
<p class="text-small text-gosign-text-light mt-1">Parcialidad</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
<span class="w-4 h-2 rounded-sm bg-gosign-border"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">Alta complejidad normativa</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">Convenios colectivos provinciales de comercio (UGT FICA / CCOO Servicios), 17 CCAA. Zero-Touch: modelo de simulación Gosign.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Lo que clasifica el Agent</p>
<h2 class="text-h1 font-bold text-gosign-dark">Cinco dimensiones, un Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Semana de 6 días con trabajo en sábado, 64% de parcialidad, bloqueos estacionales de vacaciones, fijos-discontinuos con horas fluctuantes y 50 convenios provinciales. Usted conoce la complejidad. Así la resuelve el AI Agent:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Semana de 6 días y conversión a días laborables</h3>
<p class="text-body text-gosign-text mt-2">En el comercio, el sábado es un día laboral regular. El derecho mínimo legal es de 30 días naturales (Art. 38 ET), y los convenios provinciales pueden mejorar este mínimo. El AI Agent reconoce el modelo de jornada desde los datos maestros de personal y convierte el derecho automáticamente a días laborables. En caso de cambio entre semana de 5 y 6 días: recálculo proporcional desde la fecha efectiva.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Cálculo de vacaciones a tiempo parcial para el 64% de la plantilla</h3>
<p class="text-body text-gosign-text mt-2">Más de la mitad de los empleados en el comercio trabajan a tiempo parcial - con modelos diferentes. El AI Agent calcula la retribución vacacional proporcional por modelo: jornada de 3 días, jornada de 4 días, reducción de jornada, tiempo parcial flexible. El reglamento aplica la fórmula correcta, de forma consistente en todos los centros.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Bloqueos estacionales de vacaciones</h3>
<p class="text-body text-gosign-text mt-2">Campaña navideña (noviembre a enero), rebajas, inventario - el comercio tiene periodos de restricción claros. El AI Agent conoce los periodos de restricción por centro (no todos los centros tienen las mismas restricciones) y verifica cada solicitud. Las excepciones son posibles, pero requieren una decisión del responsable con justificación obligatoria.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Derechos de vacaciones de fijos-discontinuos</h3>
<p class="text-body text-gosign-text mt-2">Tras la Reforma Laboral 2022, los fijos-discontinuos son la modalidad contractual predominante para campañas en el comercio. El AI Agent calcula el derecho a vacaciones proporcionalmente a los periodos de actividad efectiva - incluso con horas fluctuantes entre campañas. En cambio de periodo de actividad: recálculo automático del derecho proporcional acumulado.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">50 convenios provinciales</h3>
<p class="text-body text-gosign-text mt-2">Cada provincia puede tener su propio convenio colectivo de comercio, con diferencias entre CCAA. El AI Agent reconoce la ubicación del centro y aplica el convenio provincial correcto. En caso de traslado entre centros de diferentes provincias: cambio automático de convenio con recálculo de derechos.</p>
</div>
</div>
</div>
</section>

<!-- Flujo de decisión -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Una solicitud de vacaciones en comercio. 10 pasos de decisión.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Un empleado a tiempo parcial en un centro presenta una solicitud de vacaciones. El Leave Decision Layer descompone el proceso en pasos de decisión individuales:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Paso</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decisión</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Responsable</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Justificación</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Clasificar tipo de ausencia</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">El Agent reconoce: vacaciones, permiso retribuido, permiso de formación o ausencia por asuntos propios</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Reconocer convenio provincial</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">El Agent reconoce la ubicación del centro y aplica el correcto de los 50 convenios provinciales</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Calcular derecho a vacaciones</td><td class="py-3 px-4">Reglamento</td><td class="py-3 px-4">Derecho del convenio convertido a días laborables (semana de 5 o 6 días), factor de tiempo parcial, proporcionalidad fijos-discontinuos</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Verificar bloqueo estacional</td><td class="py-3 px-4">Reglamento</td><td class="py-3 px-4">Campaña navideña, rebajas, inventario - periodos de restricción específicos por centro</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Verificar dotación mínima del centro</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">El Agent verifica plan de dotación: a menudo solo 2-3 personas por centro, cada ausencia cuenta</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Detectar conflicto de equipo</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">El Agent verifica solicitudes paralelas, distribución de periodos vacacionales (criterios sociales)</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Generar recomendación de aprobación</td><td class="py-3 px-4">IA recomienda, persona decide</td><td class="py-3 px-4">Todas las reglas cumplidas: recomendación de aprobación. Periodo de restricción o dotación mínima incumplida: escalado</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">Verificar umbral de IT</td><td class="py-3 px-4">Reglamento</td><td class="py-3 px-4">Acumulación de días de baja en 12 meses (seguimiento continuo). Trigger automático a HR y Comité de Empresa</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Calcular prestación por IT</td><td class="py-3 px-4">Reglamento</td><td class="py-3 px-4">Prestación según régimen de Seguridad Social, complemento según convenio aplicable, reglas especiales para fijos-discontinuos</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Generar entrada de auditoría</td><td class="py-3 px-4">Reglamento</td><td class="py-3 px-4">Expediente de decisión completo: tipo de ausencia, convenio provincial, factor de tiempo parcial, verificación de restricción, resultado</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Simulación -->
<section id="simulacion" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulación</p>
<h2 class="text-h1 font-bold text-white">Calculado para volúmenes del comercio</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Hemos configurado el Leave Decision Layer con parámetros realistas del comercio español. 50 convenios provinciales, semana de 6 días, 64% de parcialidad, bloqueos estacionales de vacaciones.</p>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Parámetros de simulación</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Empleados</td><td class="py-3 px-4">5.000 a 100.000+ (centros, almacenes, administración)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Convenios colectivos</td><td class="py-3 px-4">50 convenios provinciales de comercio (UGT FICA / CCOO Servicios)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Modelos de jornada</td><td class="py-3 px-4">Semana de 5 días, semana de 6 días, tiempo parcial (3/4 días), fijo-discontinuo</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Parcialidad</td><td class="py-3 px-4">64% de la plantilla</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Restricciones estacionales</td><td class="py-3 px-4">Campaña navideña, rebajas, inventario (específicos por centro)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Cuota de IT</td><td class="py-3 px-4">Media sectorial de comercio</td></tr>
</tbody>
</table>
</div>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Antes / Después</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th scope="col" class="text-left py-3 px-4 font-semibold text-white">Dimensión</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manual</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Tiempo de tramitación de solicitud</td><td class="py-3 px-4">1-3 días</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 30 segundos</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Cuota Zero-Touch</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">87%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Errores en cálculo de tiempo parcial</td><td class="py-3 px-4">5-12% (conversión manual)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 0,1% (basado en reglamento)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Avisos de caducidad de vacaciones</td><td class="py-3 px-4">A menudo olvidados en tiempo parcial</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automáticos, oportunos, individualizados</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Incumplimientos en seguimiento de IT</td><td class="py-3 px-4">12-18%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">0% (trigger automático)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Preparación para auditoría</td><td class="py-3 px-4">Reconstruida manualmente</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Generada automáticamente</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">Convenios colectivos provinciales de comercio (UGT FICA / CCOO Servicios). Parcialidad: ANGED / asociaciones sectoriales. Resultados de simulación: modelo de cálculo Gosign.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">En la simulación, el Decision Layer alcanza una cuota Zero-Touch del 87%. La más alta de los cuatro sectores - porque el comercio, aunque tiene gran volumen (muchas solicitudes), las decisiones individuales son resolubles mediante reglas. El 13% restante son excepciones reales: conflictos de periodos vacacionales, excepciones a restricciones, procesos de reincorporación. Para el 87% existe un expediente de decisión completo y preparado para auditoría.</p>
</div>
</section>

<!-- Referencia arquitectura -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Arquitectura e implementación</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">El Leave Decision Layer funciona íntegramente en su infraestructura. Para el comercio esto significa: conexión con planificación de dotación por centro, procesamiento de 50 convenios provinciales, reconocimiento de modelos de tiempo parcial y Audit Trail continuo. Los pilotos típicos arrancan con una Comunidad Autónoma y un grupo de centros.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/es/servicios/hr-agent/leave-absence-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Leave Decision Layer vista general &rarr;</a>
<a href="/es/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Arquitectura del Decision Layer &rarr;</a>
<a href="/es/servicios/infraestructura/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infraestructura en detalle &rarr;</a>
<a href="/es/governance/co-determination/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Codeterminación y Comité de Empresa &rarr;</a>
<a href="/es/servicios/hr-agent/payroll-decision-layer/retail/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Payroll Decision Layer Comercio &rarr;</a>
</div>
</div>
</section>


<!-- Weitere Agent-Lösungen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Más soluciones de agentes</h2>
<p class="text-body-lg text-gosign-text-light mt-4">Los HR Agents son parte de nuestro portfolio de agentes. Para finanzas y otras áreas ofrecemos soluciones especializadas.</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8 max-w-content">
<a href="/es/hr-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR & People Operations</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Todos los HR Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Compatible con comité de empresa.</p>
</a>
<a href="/es/finance-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Finance & Accounting</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Finance AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Procesamiento de documentos, contabilización, amortización, correcciones. Integración SAP/ERP.</p>
</a>
<a href="/es/contacto/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Individual</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Co-Build para su proceso</h3>
<p class="text-body text-gosign-text-light mt-2">Compliance, operaciones, shared services - desarrollamos agentes en modelo co-build.</p>
</a>
</div>
</div>
</section>

<!-- Profundización -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Profundización en el Agent Briefing (Revista Gosign)</h2>
<p class="text-body text-gosign-text-light mb-6">Nuestra serie de artículos especializados para responsables que implementan AI Agents en la empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/es/revista/comite-empresa-ia-codeterminacion/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Codeterminación</p>
<p class="text-body font-semibold text-gosign-dark">Comité de Empresa e IA - codeterminación como restricción arquitectónica</p>
</a>
<a href="/es/revista/agent-governance-hr/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Agent Governance para HR - Por qué los reglamentos son más importantes que los modelos</p>
</a>
<a href="/es/revista/decision-layer-explicado/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Fundamentos</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - ¿Qué es y por qué lo necesita cada AI Agent empresarial?</p>
</a>
</div>
</div>
</section>

<!-- Otros sectores -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Leave Decision Layer en otros sectores</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Cada sector tiene sus propios convenios colectivos, sus propios tipos de ausencia y sus propios factores de complejidad. El Decision Layer es el mismo. La configuración es específica de cada sector.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/es/servicios/hr-agent/leave-absence-decision-layer/chemicals/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Química</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">Convenio CGIQ, vacaciones por turnicidad, IT por agentes químicos, dotación mínima</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">83% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">En detalle &rarr;</span>
</div>
</a>
<a href="/es/servicios/hr-agent/leave-absence-decision-layer/aviation/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Aviación</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">3 sindicatos, EASA FTL descansos obligatorios, Medical Grounding, Crew-Pairing</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">78% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">En detalle &rarr;</span>
</div>
</a>
<a href="/es/servicios/hr-agent/leave-absence-decision-layer/financial-services/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Finanzas</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">Desconexión obligatoria, requisitos CNMV, festivos bursátiles, jubilación parcial</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">85% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">En detalle &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- AI Leave & Absence Decision Layer ---
> El Decision Layer descompone cada proceso de ausencia en pasos de decisión. Basado en reglas, auditable, 78-87% Zero-Touch.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/es/por-que-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Cada decisión rastreable</p>
</div>
</a>
<a href="/es/por-que-gosign/#infraestructura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Su infraestructura</p>
<p class="text-xs text-gosign-text-light">Sin SaaS. Sin vendor lock-in.</p>
</div>
</a>
<a href="/es/por-que-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Sin riesgo de cloud estadounidense</p>
</div>
</a>
</div>
</div>
</div>
<!-- Problema -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">30</span>
<p class="text-small text-gosign-text-light mt-1">Días naturales de vacaciones/año</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">20+</span>
<p class="text-small text-gosign-text-light mt-1">Tipos de ausencia (legal, convenio, empresa)</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">5-15</span>
<p class="text-small text-gosign-text-light mt-1">Microdecisiones por proceso</p>
</div>
<p class="sm:col-span-3 text-xs text-gosign-text-light">Vacaciones: Estatuto de los Trabajadores Art. 38 (30 días naturales). Tipos de ausencia: ET, Ley de Prevención de Riesgos Laborales, permisos retribuidos + convenios colectivos + acuerdos de empresa.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">El problema</p>
<h2 class="text-h1 font-bold text-gosign-dark">Por qué los sistemas de ausencias fallan en organizaciones complejas</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">SAP SuccessFactors Time Off registra ausencias. Workday Absence calcula saldos. Cualquier HRIS puede crear flujos de aprobación. Pero en organizaciones con múltiples convenios colectivos, 17 comunidades autónomas, modelos de tiempo parcial y obligaciones de IT, el registro no es el problema. La decisión previa sí lo es: ¿Qué derecho aplica? ¿Qué política tiene prioridad? ¿Debe iniciarse el seguimiento de IT?</p>
<div class="mt-10">
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">20+ tipos de ausencia</h3>
<p class="text-small text-gosign-text-light mt-2">Vacaciones, permisos retribuidos (matrimonio 15 días, nacimiento 2 días, fallecimiento 2-4 días), IT, maternidad/paternidad, riesgo durante el embarazo, permisos por cuidado de familiares, asuntos propios, formación. Cada tipo tiene sus propias bases legales, plazos y reglas de cálculo. 17 comunidades autónomas con festivos propios. Ningún técnico de RRHH conoce todas las reglas de todos los convenios en todas las regiones.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">Cada baja médica desencadena 5 procesos</h3>
<p class="text-small text-gosign-text-light mt-2">Procesar baja médica electrónica, verificar plazos de prestación (empresa días 4-15, Seguridad Social desde día 16), monitorizar duración de IT, informar a planificación de turnos, comunicar a nóminas. Manualmente: rupturas entre cinco sistemas. Seguimientos de IT olvidados. Plazos de prestación incorrectos.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">Cero transparencia en decisiones</h3>
<p class="text-small text-gosign-text-light mt-2">Cuando el Comité de Empresa pregunta: ¿Por qué se denegaron las vacaciones del empleado X? ¿Qué regla aplicaba? ¿Quién decidió? Falta la evidencia. Los sistemas de ausencias documentan resultados - solicitudes aprobadas o denegadas. No las decisiones que condujeron a ellos.</p>
</div>
</div>
</div>
</div>
</section>

<!-- Principio del Decision Layer -->
<section id="decision-layer" class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">El Decision Layer</p>
<h2 class="text-h1 font-bold text-gosign-dark">Cada proceso de ausencia. Descompuesto en pasos de decisión.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">El Leave & Absence Decision Layer descompone cada proceso de ausencia en pasos de decisión individuales. Para cada paso se define quién decide: El AI Agent clasifica tipos de ausencia, detecta conflictos y monitoriza umbrales - con mayor fiabilidad y rapidez que cualquier técnico de RRHH. El reglamento calcula derechos, plazos y prorrateos - de forma determinista y reproducible. El ser humano permanece donde el Comité de Empresa (Art. 64 ET), el Estatuto de los Trabajadores o la protección de datos de salud exigen una decisión humana.</p>

<div class="mt-10 overflow-x-auto">
<table class="w-full text-left text-body">
<thead>
<tr class="border-b-2 border-gosign-dark">
<th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Paso</th>
<th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Decisión</th>
<th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Responsable</th>
<th scope="col" class="py-3 font-bold text-gosign-dark">Justificación</th>
</tr>
</thead>
<tbody class="text-gosign-text-light">
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-medium text-gosign-dark">1</td>
<td class="py-3 pr-4">Clasificar tipo de ausencia</td>
<td class="py-3 pr-4 font-medium">AI Agent</td>
<td class="py-3">El Agent reconoce: vacaciones, permiso retribuido, IT, asuntos propios, formación. Asigna la base legal correcta</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-medium text-gosign-dark">2</td>
<td class="py-3 pr-4">Calcular derecho (jerarquía normativa)</td>
<td class="py-3 pr-4 font-medium">Reglamento</td>
<td class="py-3">ET Art. 38 (30 días naturales) + convenio colectivo + acuerdo de empresa = derecho total. Aplicar principio de norma más favorable</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-medium text-gosign-dark">3</td>
<td class="py-3 pr-4">Calcular saldo pendiente</td>
<td class="py-3 pr-4 font-medium">Reglamento</td>
<td class="py-3">Derecho - disfrutados - planificados = disponible. En cambio a tiempo parcial: prorrateo según jurisprudencia del Tribunal Supremo</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-medium text-gosign-dark">4</td>
<td class="py-3 pr-4">Verificar conflicto de equipo y dotación mínima</td>
<td class="py-3 pr-4 font-medium">AI Agent</td>
<td class="py-3">El Agent verifica calendario de equipo, vacaciones colectivas, dotación mínima. Detecta solapamientos y calcula capacidad disponible</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-medium text-gosign-dark">5</td>
<td class="py-3 pr-4">Generar recomendación de aprobación</td>
<td class="py-3 pr-4 font-medium">AI Agent + Reglamento</td>
<td class="py-3">Todas las reglas cumplidas: recomendación de aprobación al responsable. Transmisión con contexto y recomendación</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-medium text-gosign-dark">6</td>
<td class="py-3 pr-4">Escalar conflicto de vacaciones</td>
<td class="py-3 pr-4 font-medium">Persona</td>
<td class="py-3">Dos empleados, misma semana, dotación mínima no alcanzada. Criterios sociales (hijos en edad escolar, familias monoparentales) requieren criterio humano - Art. 38 ET</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-medium text-gosign-dark">7</td>
<td class="py-3 pr-4">Calcular plazo de prestación por IT</td>
<td class="py-3 pr-4 font-medium">Reglamento</td>
<td class="py-3">Empresa: días 4-15 (60% base reguladora). Seguridad Social: desde día 16. Mutua: accidente laboral desde día 1</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-medium text-gosign-dark">8</td>
<td class="py-3 pr-4">Monitorizar duración de IT</td>
<td class="py-3 pr-4 font-medium">Reglamento</td>
<td class="py-3">Seguimiento de duración de IT (máx. 365 días + 180 prórroga). Trigger automático a RRHH. Datos de salud separados</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-medium text-gosign-dark">9</td>
<td class="py-3 pr-4">Procesar baja médica electrónica</td>
<td class="py-3 pr-4 font-medium">Reglamento</td>
<td class="py-3">Baja médica electrónica de Seguridad Social/Mutua: registrar ausencia, informar a nóminas y planificación de turnos, actualizar calendario</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-medium text-gosign-dark">10</td>
<td class="py-3 pr-4">Generar entrada de auditoría</td>
<td class="py-3 pr-4 font-medium">Reglamento</td>
<td class="py-3">Decisión, base normativa, responsable, marca temporal, hash de entrada - append-only, firmado SHA-256</td>
</tr>
</tbody>
</table>
</div>

<p class="text-body text-gosign-text mt-8 max-w-narrow font-semibold">5 a 15 pasos por proceso de ausencia. El AI Agent puede ejecutar cada uno de ellos mejor y más rápido que un técnico de RRHH. Aun así, el ser humano permanece en puntos definidos del proceso - no porque lo haga mejor, sino porque el Comité de Empresa, el Estatuto de los Trabajadores o la protección de datos de salud lo exigen. Con 10.000 empleados, son 50.000+ microdecisiones documentadas al mes.</p>

<div class="mt-10">
<div class="grid grid-cols-1 sm:grid-cols-2 gap-6">
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">La IA clasifica. El reglamento calcula.</h3>
<p class="text-small text-gosign-text-light mt-2">El AI Agent reconoce: ¿Qué tipo de ausencia? ¿Qué base legal? ¿Existe conflicto de equipo? ¿Ha alcanzado el empleado el umbral de IT? Esta clasificación la realiza con mayor fiabilidad que cualquier técnico de RRHH. El cálculo de derechos, plazos y prorrateos se ejecuta mediante Decision Tables versionadas - determinista, reproducible, auditable.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">IT arquitectónicamente separada</h3>
<p class="text-small text-gosign-text-light mt-2">Los datos de salud son categoría especial (RGPD Art. 9 + LOPDGDD). Sin mezcla de datos de vacaciones y diagnósticos. El módulo de IT tiene base de datos propia, acceso restringido, plazos de eliminación propios. El agente de ausencias solo ve: IT activa Sí/No. Sin diagnósticos en el módulo de ausencias.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">AI Agent, reglamento o persona</h3>
<p class="text-small text-gosign-text-light mt-2">El AI Agent clasifica situaciones y detecta patrones - con mayor fiabilidad que cualquier técnico de RRHH. El reglamento calcula derechos y plazos. El ser humano permanece donde el Comité de Empresa (Art. 64 ET), el Estatuto de los Trabajadores o la protección de datos de salud exigen una decisión humana.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">Obligación de aviso automatizada</h3>
<p class="text-small text-gosign-text-light mt-2">La jurisprudencia del Tribunal Supremo exige aviso individual y oportuno ante riesgo de caducidad de vacaciones. Sin acreditación del aviso, las vacaciones no caducan. El Decision Layer genera los avisos automáticamente, documenta la entrega y escala ante falta de acreditación.</p>
</div>
</div>
</div>
</div>
</section>

<!-- Governance y auditoría -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<h2 class="text-h1 font-bold text-gosign-dark">No documentado a posteriori. Generado en el proceso.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Cuando el Comité de Empresa pregunta "¿Por qué se denegó la solicitud de vacaciones?" no basta con "dotación mínima". ¿Qué regla de dotación? ¿Qué periodo? ¿Quién tenía ya aprobación? El Leave Decision Layer genera para cada microdecisión un acta de decisión que responde exactamente a estas preguntas: input, regla de negocio aplicada con su versión, resultado, marca de tiempo y vía de impugnación. La misma acta hace también cumplible la explicación de la decisión individual conforme al art. 86 del EU AI Act - para el afectado, el Comité de Empresa y el auditor.</p>

<!-- Audit Trail Card -->
<div class="mt-10 bg-gosign-dark rounded-card p-6 sm:p-8">
<div class="flex items-start gap-4 mb-6">
<svg class="w-8 h-8 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12h6m-6 4h6m2 5H7a2 2 0 01-2-2V5a2 2 0 012-2h5.586a1 1 0 01.707.293l5.414 5.414a1 1 0 01.293.707V19a2 2 0 01-2 2z" />
</svg>
<div>
<h3 class="text-h3 font-bold text-white">Cada microdecisión genera una entrada de auditoría</h3>
<p class="text-small text-gosign-text-on-dark/70 mt-1">Append-only. Nada se sobrescribe, nada se elimina. En correcciones se generan asientos de anulación y ajuste. Firmado SHA-256, exportable en cualquier momento.</p>
</div>
</div>
<div class="grid grid-cols-2 sm:grid-cols-3 gap-3 sm:gap-4">
<div class="flex items-center gap-2.5">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span class="text-small text-gosign-text-on-dark/80">ID de regla + versión</span>
</div>
<div class="flex items-center gap-2.5">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span class="text-small text-gosign-text-on-dark/80">Base legal (ET, convenio, acuerdo)</span>
</div>
<div class="flex items-center gap-2.5">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span class="text-small text-gosign-text-on-dark/80">Datos de entrada (solicitud, periodo, equipo)</span>
</div>
<div class="flex items-center gap-2.5">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span class="text-small text-gosign-text-on-dark/80">Resultado (aprobación, denegación, escalado)</span>
</div>
<div class="flex items-center gap-2.5">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span class="text-small text-gosign-text-on-dark/80">Responsable (reglamento / agente / persona)</span>
</div>
<div class="flex items-center gap-2.5">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span class="text-small text-gosign-text-on-dark/80">Hash de entrada (reproducible)</span>
</div>
</div>
</div>

<!-- Tres pilares de Governance -->
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8">
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-3">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M15 12a3 3 0 11-6 0 3 3 0 016 0z" />
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M2.458 12C3.732 7.943 7.523 5 12 5c4.478 0 8.268 2.943 9.542 7-1.274 4.057-5.064 7-9.542 7-4.477 0-8.268-2.943-9.542-7z" />
</svg>
<div>
<h3 class="text-body font-semibold text-gosign-dark">Transparente para el Comité de Empresa</h3>
<p class="text-small text-gosign-text-light mt-2">Estatuto de los Trabajadores (Art. 64 ET): derecho de información y consulta del Comité de Empresa. Reglamento visible, motivos de denegación documentados, detección de anomalías configurable por Feature Flag, informes pseudonimizados.</p>
<a href="/es/governance/co-determination/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Codeterminación &rarr;</a>
</div>
</div>
</div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-3">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12l2 2 4-4m5.618-4.016A11.955 11.955 0 0112 2.944a11.955 11.955 0 01-8.618 3.04A12.02 12.02 0 003 9c0 5.591 3.824 10.29 9 11.622 5.176-1.332 9-6.03 9-11.622 0-1.042-.133-2.052-.382-3.016z" />
</svg>
<div>
<h3 class="text-body font-semibold text-gosign-dark">RGPD Art. 9 + LOPDGDD: datos de salud separados</h3>
<p class="text-small text-gosign-text-light mt-2">Módulo de IT arquitectónicamente separado. Base de datos propia, acceso restringido. Sin diagnósticos en el módulo de ausencias. Expediente de IT separado del expediente de personal. Plazos de eliminación configurables.</p>
<a href="/es/governance/data-residency/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Residencia de datos &rarr;</a>
</div>
</div>
</div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-3">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 5H7a2 2 0 00-2 2v12a2 2 0 002 2h10a2 2 0 002-2V7a2 2 0 00-2-2h-2M9 5a2 2 0 002 2h2a2 2 0 002-2M9 5a2 2 0 012-2h2a2 2 0 012 2m-6 9l2 2 4-4" />
</svg>
<div>
<h3 class="text-body font-semibold text-gosign-dark">Obligación de aviso automatizada</h3>
<p class="text-small text-gosign-text-light mt-2">Jurisprudencia del TS: el derecho a vacaciones no caduca sin aviso individual. La caducidad comienza solo con el cumplimiento de la obligación de aviso. El Decision Layer automatiza los avisos y documenta la entrega.</p>
</div>
</div>
</div>
</div>
</div>
</section>

<!-- Integración -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Integración</p>
<h2 class="text-h1 font-bold text-gosign-dark">Se conecta a su ecosistema de sistemas actual</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Sus sistemas permanecen. El trabajo de decisión manual previo desaparece. El Leave Decision Layer se sitúa entre sus sistemas origen y su HRIS - toma las decisiones que hoy toman los técnicos de RRHH.</p>

<div class="grid grid-cols-1 md:grid-cols-3 gap-6 mt-10">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<div class="flex items-center gap-3 mb-4">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M20 7l-8-4-8 4m16 0l-8 4m8-4v10l-8 4m0-10L4 7m8 4v10M4 7v10l8 4" />
</svg>
<h3 class="text-body font-semibold text-gosign-dark">Fuentes de datos</h3>
</div>
<ul class="space-y-2 text-small text-gosign-text-light">
<li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Datos maestros (SAP HCM, Workday, A3Equipo)</span></li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Control horario (ATOSS, Interflex, GFOS)</span></li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Baja médica electrónica (Seguridad Social/Mutua)</span></li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Planificación de turnos (ATOSS, SAP)</span></li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Base de datos de convenios colectivos (versionada)</span></li>
</ul>
</div>
<div class="bg-gosign-dark border border-gosign-dark rounded-card p-6">
<div class="flex items-center gap-3 mb-4">
<svg class="w-6 h-6 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9.75 3.104v5.714a2.25 2.25 0 01-.659 1.591L5 14.5M9.75 3.104c-.251.023-.501.05-.75.082m.75-.082a24.301 24.301 0 014.5 0m0 0v5.714c0 .597.237 1.17.659 1.591L19.8 15.3M14.25 3.104c.251.023.501.05.75.082M19.8 15.3l-1.57.393A9.065 9.065 0 0112 15a9.065 9.065 0 00-6.23.693L5 14.5m14.8.8l1.402 1.402c1.232 1.232.65 3.318-1.067 3.611A48.309 48.309 0 0112 21c-2.773 0-5.491-.235-8.135-.687-1.718-.293-2.3-2.379-1.067-3.61L5 14.5" />
</svg>
<h3 class="text-body font-semibold text-white">Leave Decision Layer</h3>
</div>
<ul class="space-y-2 text-small text-gosign-text-on-dark/80">
<li>Clasificación de tipo de ausencia</li>
<li>Cálculo de derechos (convenio + acuerdo + ley)</li>
<li>Verificación de conflictos y dotación</li>
<li>Cálculo de plazos de prestación IT</li>
<li>Monitorización de duración de IT</li>
<li>Obligación de aviso de caducidad</li>
<li>Procesamiento de baja médica electrónica</li>
</ul>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<div class="flex items-center gap-3 mb-4">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M5.25 14.25h13.5m-13.5 0a3 3 0 01-3-3m3 3a3 3 0 100 6h13.5a3 3 0 100-6m-16.5-3a3 3 0 013-3h13.5a3 3 0 013 3m-19.5 0a4.5 4.5 0 01.9-2.7L5.737 5.1a3.375 3.375 0 012.7-1.35h7.126c1.062 0 2.062.5 2.7 1.35l2.587 3.45a4.5 4.5 0 01.9 2.7m0 0a3 3 0 01-3 3m0 3h.008v.008h-.008v-.008zm0-6h.008v.008h-.008v-.008zm-3 6h.008v.008h-.008v-.008zm0-6h.008v.008h-.008v-.008z" />
</svg>
<h3 class="text-body font-semibold text-gosign-dark">Sistemas destino</h3>
</div>
<ul class="space-y-2 text-small text-gosign-text-light">
<li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>SAP SuccessFactors Time Off</span></li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Workday Absence Management</span></li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Nóminas (A3Nómina, SAP HCM)</span></li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Calendario (Microsoft 365, Google)</span></li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>DMS / Expediente digital de personal</span></li>
</ul>
</div>
</div>
</div>
</section>

<!-- Simulaciones sectoriales -->
<section id="simulaciones" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulado para volúmenes enterprise</p>
<h2 class="text-h1 font-bold text-white">Cuatro sectores. Calculados al detalle.</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Hemos configurado el Leave & Absence Decision Layer para cuatro sectores con convenios colectivos reales, regulaciones de ausencia y estructuras de personal y lo hemos calculado al detalle. Cada tarjeta muestra los parámetros de simulación y el resultado.</p>

<div class="grid grid-cols-1 md:grid-cols-2 gap-6 mt-10">
<a href="/es/servicios/hr-agent/leave-absence-decision-layer/chemicals/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors">
<div class="flex items-center justify-between mb-4">
<h3 class="text-h3 font-bold text-white">Química</h3>
<div class="flex gap-1">
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>

</div>
</div>
<ul class="space-y-1.5 text-small text-gosign-text-on-dark/70">
<li>Convenio CGIQ: vacaciones adicionales por turno continuo</li>
<li>Complemento de descanso por turnicidad (2-5 días adicionales)</li>
<li>Seguimiento de IT por exposición a agentes químicos</li>
<li>Convenios sectoriales + acuerdos de centro</li>
</ul>
<div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between">
<span class="text-h3 font-bold text-gosign-accent-on-dark">83% Zero-Touch</span>
<span class="text-small text-gosign-accent-on-dark font-semibold">Química en detalle &rarr;</span>
</div>
</a>

<a href="/es/servicios/hr-agent/leave-absence-decision-layer/aviation/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors">
<div class="flex items-center justify-between mb-4">
<h3 class="text-h3 font-bold text-white">Aviación</h3>
<div class="flex gap-1">
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>

</div>
</div>
<ul class="space-y-1.5 text-small text-gosign-text-on-dark/70">
<li>3 sindicatos (pilotos, TCP, tierra)</li>
<li>EASA FTL: descansos obligatorios reglamentarios</li>
<li>Medical Grounding (inhabilitación médica)</li>
<li>Crew-Pairing como restricción operativa</li>
</ul>
<div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between">
<span class="text-h3 font-bold text-gosign-accent-on-dark">78% Zero-Touch</span>
<span class="text-small text-gosign-accent-on-dark font-semibold">Aviación en detalle &rarr;</span>
</div>
</a>

<a href="/es/servicios/hr-agent/leave-absence-decision-layer/financial-services/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors">
<div class="flex items-center justify-between mb-4">
<h3 class="text-h3 font-bold text-white">Finanzas</h3>
<div class="flex gap-1">
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>

<span class="w-3 h-1.5 rounded-sm bg-white/20"></span>
</div>
</div>
<ul class="space-y-1.5 text-small text-gosign-text-on-dark/70">
<li>Desconexión obligatoria (principio de cuatro ojos, fraude)</li>
<li>CNMV: bloques de vacaciones obligatorios para traders</li>
<li>Festivos bursátiles adicionales a los legales</li>
<li>Jubilación parcial anticipada</li>
</ul>
<div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between">
<span class="text-h3 font-bold text-gosign-accent-on-dark">85% Zero-Touch</span>
<span class="text-small text-gosign-accent-on-dark font-semibold">Finanzas en detalle &rarr;</span>
</div>
</a>

<a href="/es/servicios/hr-agent/leave-absence-decision-layer/retail/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors">
<div class="flex items-center justify-between mb-4">
<h3 class="text-h3 font-bold text-white">Comercio</h3>
<div class="flex gap-1">
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>

<span class="w-3 h-1.5 rounded-sm bg-white/20"></span>
</div>
</div>
<ul class="space-y-1.5 text-small text-gosign-text-on-dark/70">
<li>6 días laborables: derecho mínimo 24 días laborables</li>
<li>64% cuota de tiempo parcial, contratos fijos-discontinuos</li>
<li>Bloqueos de vacaciones Navidad, rebajas, picos estacionales</li>
<li>17 comunidades autónomas x convenios provinciales</li>
</ul>
<div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between">
<span class="text-h3 font-bold text-gosign-accent-on-dark">87% Zero-Touch</span>
<span class="text-small text-gosign-accent-on-dark font-semibold">Comercio en detalle &rarr;</span>
</div>
</a>
</div>
</div>
</section>

<!-- Arquitectura, implementación y palancas -->
<section id="implementacion" class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Implementación</p>
<h2 class="text-h1 font-bold text-gosign-dark">Del piloto al sistema en producción.</h2>

<div class="grid grid-cols-1 lg:grid-cols-2 gap-10 mt-10">
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Arquitectura técnica</h3>
<p class="text-body text-gosign-text">El Leave & Absence Decision Layer funciona íntegramente en su infraestructura: su centro de datos, su red, su soberanía. Sin dependencia SaaS, sin fuga de datos, sin telemetría externa. Los datos de salud y expedientes de IT no abandonan su red. Contenerizado, multi-tenant, listo para desplegar en su Private Cloud.</p>
<div class="flex flex-wrap gap-4 mt-3">
<a href="/es/servicios/infraestructura/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infraestructura en detalle &rarr;</a>
<a href="/es/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Arquitectura del Decision Layer &rarr;</a>
<a href="/es/revista/acta-de-decision-decisiones-ia-impugnables/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">El acta de decisión &rarr;</a>
<a href="/es/servicios/hr-agent/payroll-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Payroll Decision Layer &rarr;</a>
</div>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Implementación</h3>
<p class="text-body text-gosign-text">El Decision Layer no se instala, se configura: sus convenios colectivos, sus acuerdos de empresa, sus tipos de ausencia. Los pilotos típicos arrancan en 3 meses con un centro y los tipos de ausencia más frecuentes. Las ampliaciones a otros centros, convenios y casuísticas se ejecutan en paralelo al piloto.</p>
</div>
</div>

<h3 class="text-h3 font-bold text-gosign-dark mt-12 mb-6">Palanca económica</h3>
<div class="grid grid-cols-1 sm:grid-cols-2 gap-6">
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-4">
<svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12l2 2 4-4m5.618-4.016A11.955 11.955 0 0112 2.944a11.955 11.955 0 01-8.618 3.04A12.02 12.02 0 003 9c0 5.591 3.824 10.29 9 11.622 5.176-1.332 9-6.03 9-11.622 0-1.042-.133-2.052-.382-3.016z" />
</svg>
<div>
<p class="text-body font-semibold text-gosign-dark">Eliminar incumplimientos en seguimiento de IT</p>
<p class="text-small text-gosign-text-light mt-2">Sin seguimiento adecuado de IT, la gestión de ausencias prolongadas se complica. El Decision Layer detecta los umbrales automáticamente, activa el proceso y documenta las comunicaciones. Sin seguimientos de IT olvidados.</p>
</div>
</div>
</div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-4">
<svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M13 10V3L4 14h7v7l9-11h-7z" />
</svg>
<div>
<p class="text-body font-semibold text-gosign-dark">Procesamiento de baja médica en tiempo real</p>
<p class="text-small text-gosign-text-light mt-2">Las bajas médicas electrónicas de Seguridad Social y Mutua se procesan automáticamente: registrar ausencia, calcular plazo de prestación, informar a nóminas, actualizar planificación de turnos. Sin registro manual posterior.</p>
</div>
</div>
</div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-4">
<svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M12 6v6h4.5m4.5 0a9 9 0 11-18 0 9 9 0 0118 0z" />
</svg>
<div>
<p class="text-body font-semibold text-gosign-dark">78-87% Zero-Touch. Persona solo donde es legalmente necesario.</p>
<p class="text-small text-gosign-text-light mt-2">Solicitudes de vacaciones estándar, cálculo de saldos, permisos retribuidos, procesamiento de baja médica: todo automatizable. Las intervenciones humanas se mantienen en conflictos de vacaciones, seguimiento de IT prolongada y revisión de permisos especiales.</p>
</div>
</div>
</div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-4">
<svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12h6m-6 4h6m2 5H7a2 2 0 01-2-2V5a2 2 0 012-2h5.586a1 1 0 01.707.293l5.414 5.414a1 1 0 01.293.707V19a2 2 0 01-2 2z" />
</svg>
<div>
<p class="text-body font-semibold text-gosign-dark">Eliminar riesgo de caducidad de vacaciones</p>
<p class="text-small text-gosign-text-light mt-2">Obligación de aviso: sin aviso individual y oportuno, las vacaciones no caducan. El Decision Layer automatiza los avisos y documenta la entrega.</p>
</div>
</div>
</div>
</div>
</div>
</section>

<!-- Cumplimiento y seguridad -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Seguridad</p>
<h2 class="text-h1 font-bold text-gosign-dark">Seguridad enterprise. Desde el día uno.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Los datos de ausencias contienen información de salud, expedientes de IT y decisiones sensibles de personal. El Leave Decision Layer está diseñado para entornos regulados donde la protección de datos, la preparación para auditoría y la trazabilidad no son extras opcionales.</p>
<div class="mt-10">
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">100% infraestructura del cliente</h3>
<p class="text-small text-gosign-text-light mt-2">El Decision Layer funciona íntegramente en su red. Sin dependencia SaaS, sin fuga de datos, sin telemetría externa. Los datos de salud y expedientes de IT no abandonan su red.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">RGPD Art. 9 + LOPDGDD by Design</h3>
<p class="text-small text-gosign-text-light mt-2">Datos de salud arquitectónicamente separados. Módulo de IT con base de datos propia, acceso restringido, plazos de eliminación propios. Compatible con RGPD Art. 17 y plazos de conservación.</p>
<a href="/es/governance/data-residency/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Residencia de datos en detalle &rarr;</a>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">Conforme al AI Act</h3>
<p class="text-small text-gosign-text-light mt-2">Separación arquitectónica clara: el AI Agent clasifica tipos de ausencia y detecta conflictos. El cálculo de derechos y plazos se ejecuta de forma determinista mediante reglamentos. Sin caja negra en decisiones.</p>
<a href="/es/governance/eu-ai-act/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Preparación EU AI Act &rarr;</a>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">Audit Trail (append-only)</h3>
<p class="text-small text-gosign-text-light mt-2">Expedientes de decisión firmados. Hash de entrada más versión de regla genera resultado reproducible. Paquetes de auditoría sellados (JSON + PDF, SHA-256). El Comité de Empresa puede verificar cada decisión.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">ISO 27001 / PS 951 cert-ready</h3>
<p class="text-small text-gosign-text-light mt-2">Controls Registry integrado, Evidence Runs automatizados, políticas versionadas. Cumplimiento en operación continua, no documentado a posteriori.</p>
<a href="/es/governance/cert-ready/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready by Design &rarr;</a>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">SSO y separación multi-tenant</h3>
<p class="text-small text-gosign-text-light mt-2">Integración con su Identity Provider existente. Separación de tenants a nivel de base de datos (Row Level Security). Acceso a IT separado del módulo de ausencias. Sociedades claramente separadas.</p>
</div>
</div>
</div>
</div>
</section>


<!-- Weitere Agent-Lösungen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Más soluciones de agentes</h2>
<p class="text-body-lg text-gosign-text-light mt-4">Los HR Agents son parte de nuestro portfolio de agentes. Para finanzas y otras áreas ofrecemos soluciones especializadas.</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8 max-w-content">
<a href="/es/hr-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR & People Operations</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Todos los HR Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Compatible con comité de empresa.</p>
</a>
<a href="/es/finance-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Finance & Accounting</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Finance AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Procesamiento de documentos, contabilización, amortización, correcciones. Integración SAP/ERP.</p>
</a>
<a href="/es/contacto/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Individual</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Co-Build para su proceso</h3>
<p class="text-body text-gosign-text-light mt-2">Compliance, operaciones, shared services - desarrollamos agentes en modelo co-build.</p>
</a>
</div>
</div>
</section>

<!-- Este agente en el catálogo -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark">¿Cuándo empezar? Priorización y preparación de governance</h2>
<p class="text-body text-gosign-text mt-4">El catálogo de agentes HR muestra puntuaciones, complejidad de gobernanza, clasificación EU AI Act y la tabla completa de microdecisiones para este agente - posicionado en 3 cuadrantes de priorización junto a 47 agentes HR más.</p>
<a href="/es/catalogo-agentes-hr/leave-of-absence-agent/" class="inline-flex items-center gap-2 mt-4 text-body font-semibold text-gosign-accent hover:underline">Ver secuenciación y scores &rarr;</a>
</div>
</section>

<!-- Profundización -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Profundización en el Agent Briefing (Revista Gosign)</h2>
<p class="text-body text-gosign-text-light mb-6">Nuestra serie de artículos especializados para responsables que implementan AI Agents en la empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/es/revista/comite-empresa-ia-codeterminacion/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Codeterminación</p>
<p class="text-body font-semibold text-gosign-dark">Comité de Empresa e IA - codeterminación como restricción arquitectónica</p>
</a>
<a href="/es/revista/decision-layer-explicado/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Fundamentos</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - ¿Qué es y por qué lo necesita cada AI Agent empresarial?</p>
</a>
<a href="/es/revista/agent-governance-hr/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Agent Governance para HR - Por qué los reglamentos son más importantes que los modelos</p>
</a>
</div>
</div>
</section>

--- AI Payroll Agent Aviación - nóminas sector ---
> Payroll Decision Layer para aviación. SEPLA, SITCPLA, UGT/CCOO, AESA/EASA FTL, dietas IRPF. 82% Zero-Touch.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/es/por-que-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Cada decisión rastreable</p>
</div>
</a>
<a href="/es/por-que-gosign/#infraestructura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Su infraestructura</p>
<p class="text-xs text-gosign-text-light">Sin SaaS. Sin vendor lock-in.</p>
</div>
</a>
<a href="/es/por-que-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Sin riesgo de cloud estadounidense</p>
</div>
</a>
</div>
</div>
</div>

<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Payroll Decision Layer Sectores">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/es/servicios/hr-agent/payroll-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Payroll Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/es/servicios/hr-agent/payroll-decision-layer/chemicals/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Química</a>
<a href="/es/servicios/hr-agent/payroll-decision-layer/aviation/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Aviación</a>
<a href="/es/servicios/hr-agent/payroll-decision-layer/financial-services/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Finanzas</a>
<a href="/es/servicios/hr-agent/payroll-decision-layer/retail/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Comercio</a>
</div>
</div>
</nav>

<!-- Complejidad -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">14-18</span>
<p class="text-small text-gosign-text-light mt-1">Convenios colectivos en paralelo</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">82%</span>
<p class="text-small text-gosign-text-light mt-1">Cuota Zero-Touch</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">180+</span>
<p class="text-small text-gosign-text-light mt-1">Dietas internacionales por país</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">Máxima complejidad normativa</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">Convenios SEPLA, SITCPLA, UGT/CCOO 2024. Tablas IRPF Agencia Tributaria. AESA/EASA FTL (Reg. UE 83/2014). Zero-Touch: modelo de simulación Gosign.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Lo que clasifica el Agent</p>
<h2 class="text-h1 font-bold text-gosign-dark">Tres sindicatos, un Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">En España, la nómina de aviación implica varios sindicatos - SEPLA para pilotos, SITCPLA para cabina, UGT y CCOO para tierra - además de los límites EASA supervisados por AESA y dietas internacionales. Usted conoce la complejidad. Así la resuelve el AI Agent:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Cockpit (SEPLA): niveles de antigüedad y escalas salariales</h3>
<p class="text-body text-gosign-text mt-2">Los convenios SEPLA cubren múltiples niveles de antigüedad, retribuciones por tipo de flota y aportaciones a planes de pensiones. El AI Agent reconoce el nivel de antigüedad y la asignación de flota desde los datos maestros y asigna la clase retributiva correcta - desde Second Officer hasta Captain Senior. Aplica a tripulaciones de Iberia, Vueling e Iberia Express.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Cabina (SITCPLA): complementos de turno y vuelo</h3>
<p class="text-body text-gosign-text mt-2">Retribución base más complementos de turno, pluses de sobrecargo, dietas según plan de rotación. El AI Agent distingue corto radio de largo radio y calcula las dietas correctas y patrones de turno por rotación. En caso de cambio de ruta: recálculo automático.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Tierra (UGT/CCOO): convenios de handling aeroportuario</h3>
<p class="text-body text-gosign-text mt-2">Convenio de handling aeroportuario con múltiples grupos salariales, complementos de nocturnidad, festivos y turnos. El AI Agent clasifica grupo salarial y nivel de experiencia desde datos maestros y perfil de puesto - también en cambios entre facturación, pista y gestión de equipajes.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">AESA/EASA FTL: límites de tiempo de vuelo como frontera de nómina</h3>
<p class="text-body text-gosign-text mt-2">AESA (Agencia Estatal de Seguridad Aérea) supervisa directamente los requisitos EASA: máximo 900 horas de vuelo/año, Flight Duty Period máximo 13 horas. El AI Agent verifica cada ciclo de nómina contra estos límites y escala al aproximarse. En caso de exceso hay riesgo de retirada de licencia y sanción - eso ya no es una cuestión de nómina, sino legal.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Dietas: 180+ tablas IRPF por país</h3>
<p class="text-body text-gosign-text mt-2">Rotación Londres-Dubái-Singapur: tres tablas por país en un solo Duty Period. El AI Agent calcula la dieta por tramo de rotación según tablas IRPF de la Agencia Tributaria, incluyendo deducciones por comidas y duraciones mínimas de estancia. En caso de cambio de rotación por IROPs: recálculo automático. La misma lógica gestiona también los <a href="/es/servicios/travel-decision-layer/aviacion/" class="text-gosign-accent-text font-semibold hover:text-gosign-accent-hover transition-colors">gastos de viaje en el Travel Decision Layer</a>.</p>
</div>
</div>
</div>
</section>

<!-- Flujo de decisión -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Una nómina de aviación. 50 a 120 micro-decisiones.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Un capitán de largo radio. El Payroll Decision Layer descompone su nómina en pasos de decisión individuales:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Paso</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decisión</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Responsable</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Justificación</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Clasificar grupo de personal</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">El Agent reconoce: cockpit, cabina, tierra o técnico desde datos maestros y código de puesto</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Asignar convenio colectivo</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">El Agent asigna: SEPLA, SITCPLA o UGT/CCOO. Además: qué aerolínea (las filiales tienen convenios propios)</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Calcular retribución base</td><td class="py-3 px-4">Convenio colectivo</td><td class="py-3 px-4">Consulta en tabla salarial versionada: nivel de antigüedad, flota, nivel de experiencia</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Calcular complementos de turno</td><td class="py-3 px-4">Convenio colectivo</td><td class="py-3 px-4">Cabina: complementos de turno y vuelo. Tierra: complementos según modelo de turnos. Cockpit: integrado en retribución base</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Verificar cumplimiento FTL</td><td class="py-3 px-4">Reglamento</td><td class="py-3 px-4">Verificación AESA/EASA: límite anual 900h, FDP máx. 13h, límites acumulados. Al aproximarse: escalación</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Clasificar dieta</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">El Agent clasifica rotación: qué países, qué duración de estancia, qué tablas IRPF aplican</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Calcular dieta</td><td class="py-3 px-4">Reglamento</td><td class="py-3 px-4">Tablas IRPF por país, deducción por comidas, estancia mínima. En caso de cambio por IROPs: recálculo automático</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">Calcular aportaciones a planes de pensiones</td><td class="py-3 px-4">Reglamento</td><td class="py-3 px-4">Plan de pensiones de empleo, seguro colectivo, aportaciones. Determinista según convenio</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Verificación de desviaciones</td><td class="py-3 px-4">IA detecta, persona decide</td><td class="py-3 px-4">La IA detecta desviaciones con mayor fiabilidad. Pero la evaluación permanece en manos humanas - Art. 64 ET protege la consulta del Comité sobre política retributiva</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Generar asientos contables</td><td class="py-3 px-4">Reglamento</td><td class="py-3 px-4">Contabilización, multi-sociedad (filiales del grupo), centro de coste - determinista</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Simulación -->
<section id="simulacion" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulación</p>
<h2 class="text-h1 font-bold text-white">Calculado para volúmenes de aviación</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Hemos configurado el Payroll Decision Layer con parámetros realistas de aviación. Convenios SEPLA, SITCPLA y UGT/CCOO, AESA/EASA FTL, dietas internacionales según tablas IRPF, niveles de antigüedad de cockpit.</p>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Parámetros de simulación</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Plantilla</td><td class="py-3 px-4">10.000 a 50.000+ (cockpit, cabina, tierra, técnico)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Convenios en paralelo</td><td class="py-3 px-4">2 a 5 (SEPLA, SITCPLA, UGT/CCOO, filiales adicionales)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Jurisdicciones</td><td class="py-3 px-4">Multi-jurisdicción (base ES, estaciones UE/mundial)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Cuota de IROPs</td><td class="py-3 px-4">10-20% (irregularidades con impacto en nómina)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Dietas por país</td><td class="py-3 px-4">180+ tablas según IRPF Agencia Tributaria</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Niveles de antigüedad cockpit</td><td class="py-3 px-4">Múltiples niveles (Second Officer a Captain Senior), plan de pensiones</td></tr>
</tbody>
</table>
</div>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Antes / Después</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th scope="col" class="text-left py-3 px-4 font-semibold text-white">Dimensión</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manual</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Tasa de error</td><td class="py-3 px-4">3-12% (APA, recargo aviación)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 0,3%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Cuota Zero-Touch</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">82%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Cálculo de dietas</td><td class="py-3 px-4">Manual por rotación, propenso a errores</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automático, 180+ países</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Cumplimiento FTL</td><td class="py-3 px-4">Verificación separada, posterior</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Integrado, límites en tiempo real</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Cambio de convenio (3 sindicatos)</td><td class="py-3 px-4">Semanas por sindicato</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 24h (todos en paralelo)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Preparación para auditoría</td><td class="py-3 px-4">Reconstruida manualmente</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Generada automáticamente</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">APA: American Payroll Association. Convenios SEPLA, SITCPLA, UGT/CCOO 2024. AESA/EASA Reg. UE 83/2014. Tablas IRPF Agencia Tributaria 2024. Resultados de simulación: modelo de cálculo Gosign.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">En la simulación, el Decision Layer alcanza una cuota Zero-Touch del 82%. El 18% restante son excepciones reales: cambios de rotación por IROPs, cambio de sindicato en traslados entre filiales, casos límite FTL con escalación, promociones de cockpit entre convenios. Para el 82% existe un expediente de decisión completo y preparado para inspección.</p>
</div>
</section>

<!-- Referencia arquitectura -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Arquitectura e implementación</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">El Payroll Decision Layer funciona íntegramente en su infraestructura. Para la aviación esto significa: conexión con sistemas de gestión de tripulaciones, procesamiento de planes de rotación y datos FTL, convenios SEPLA, SITCPLA y UGT/CCOO en paralelo y Audit Trail continuo hasta SAP HCM. Los pilotos típicos arrancan en 3 meses con un grupo de personal y un convenio colectivo.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/es/servicios/hr-agent/payroll-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Payroll Decision Layer vista general &rarr;</a>
<a href="/es/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Arquitectura del Decision Layer &rarr;</a>
<a href="/es/servicios/infraestructura/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infraestructura en detalle &rarr;</a>
<a href="/es/governance/co-determination/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Codeterminación y Comité de Empresa &rarr;</a>
<a href="/es/governance/cert-ready/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready by Design &rarr;</a>
<a href="/es/servicios/travel-decision-layer/aviacion/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Travel Decision Layer Aviación &rarr;</a>
</div>
</div>
</section>


<!-- Weitere Agent-Lösungen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Más soluciones de agentes</h2>
<p class="text-body-lg text-gosign-text-light mt-4">Los HR Agents son parte de nuestro portfolio de agentes. Para finanzas y otras áreas ofrecemos soluciones especializadas.</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8 max-w-content">
<a href="/es/hr-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR & People Operations</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Todos los HR Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Compatible con comité de empresa.</p>
</a>
<a href="/es/finance-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Finance & Accounting</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Finance AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Procesamiento de documentos, contabilización, amortización, correcciones. Integración SAP/ERP.</p>
</a>
<a href="/es/contacto/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Individual</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Co-Build para su proceso</h3>
<p class="text-body text-gosign-text-light mt-2">Compliance, operaciones, shared services - desarrollamos agentes en modelo co-build.</p>
</a>
</div>
</div>
</section>

<!-- Profundización -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Profundización en el Agent Briefing (Revista Gosign)</h2>
<p class="text-body text-gosign-text-light mb-6">Nuestra serie de artículos especializados para responsables que implementan AI Agents en la empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/es/revista/decision-layer-payroll/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Finanzas</p>
<p class="text-body font-semibold text-gosign-dark">Eliminar errores de nómina de forma estructural - Decision Layer para finanzas</p>
</a>
<a href="/es/revista/comite-empresa-ia-codeterminacion/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Codeterminación</p>
<p class="text-body font-semibold text-gosign-dark">Comité de Empresa e IA - codeterminación como restricción arquitectónica</p>
</a>
<a href="/es/revista/decision-layer-explicado/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Fundamentos</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - ¿Qué es y por qué lo necesita cada AI Agent empresarial?</p>
</a>
</div>
</div>
</section>

<!-- Otros sectores -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Payroll Decision Layer en otros sectores</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Cada sector tiene sus propios convenios colectivos, sus propias reglas de complementos y sus propios factores de complejidad. El Decision Layer es el mismo. La configuración es específica de cada sector.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/es/servicios/hr-agent/payroll-decision-layer/chemicals/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Química</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">Convenio CGIQ, complementos de turno con acumulación, 14 pagas, plan de pensiones</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">88% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">En detalle &rarr;</span>
</div>
</a>
<a href="/es/servicios/hr-agent/payroll-decision-layer/financial-services/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Finanzas</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">5 regímenes retributivos, Bonus-Deferral, Malus/Clawback, Circular CNMV</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">85% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">En detalle &rarr;</span>
</div>
</a>
<a href="/es/servicios/hr-agent/payroll-decision-layer/retail/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Comercio</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">50 convenios provinciales, 17 CCAA, fijos-discontinuos, 64% tiempo parcial</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">92% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">En detalle &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- AI Payroll Agent Química - nóminas sector ---
> Payroll Decision Layer para la industria química. Convenio CGIQ, complementos de turno, 14 pagas + Plan de Pensiones. 88% Zero-Touch.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/es/por-que-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Cada decisión rastreable</p>
</div>
</a>
<a href="/es/por-que-gosign/#infraestructura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Su infraestructura</p>
<p class="text-xs text-gosign-text-light">Sin SaaS. Sin vendor lock-in.</p>
</div>
</a>
<a href="/es/por-que-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Sin riesgo de cloud estadounidense</p>
</div>
</a>
</div>
</div>
</div>

<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Payroll Decision Layer Sectores">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/es/servicios/hr-agent/payroll-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Payroll Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/es/servicios/hr-agent/payroll-decision-layer/chemicals/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Química</a>
<a href="/es/servicios/hr-agent/payroll-decision-layer/aviation/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Aviación</a>
<a href="/es/servicios/hr-agent/payroll-decision-layer/financial-services/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Finanzas</a>
<a href="/es/servicios/hr-agent/payroll-decision-layer/retail/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Comercio</a>
</div>
</div>
</nav>

<!-- Complejidad -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">169</span>
<p class="text-small text-gosign-text-light mt-1">Bases salariales</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">88%</span>
<p class="text-small text-gosign-text-light mt-1">Cuota Zero-Touch</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">14</span>
<p class="text-small text-gosign-text-light mt-1">Pagas + Plan de Pensiones</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">Máxima complejidad normativa</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">Convenio general de la industria química (CGIQ). UGT FICA / CCOO Industria. Repsol, CEPSA. Zero-Touch: modelo de simulación Gosign.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Lo que clasifica el Agent</p>
<h2 class="text-h1 font-bold text-gosign-dark">Cinco dimensiones, un Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">En España, el convenio general de la industria química (CGIQ) negociado por UGT FICA y CCOO Industria define grupos profesionales, complementos de turno con reglas de acumulación y 14 pagas con Plan de Pensiones. Usted conoce la complejidad. Así la resuelve el AI Agent:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">169 bases salariales</h3>
<p class="text-body text-gosign-text mt-2">El CGIQ estructura grupos profesionales y niveles salariales que generan cientos de combinaciones. El AI Agent reconoce la combinación correcta desde los datos maestros de personal y datos de centro - también en traslados entre centros. Sin consulta manual de tablas, sin confusión de categorías.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Complementos de turno con lógica de acumulación</h3>
<p class="text-body text-gosign-text mt-2">Turno parcial continuo 6%, turno completo continuo 10%, nocturnidad 15-20%, domingo 60%, festivo 150%. El AI Agent aplica la regla de acumulación: aplica el complemento más alto, nocturnidad siempre aditiva. En modelos de turno rotativo, el reglamento calcula la combinación correcta por plan de turnos automáticamente.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">14 pagas + Plan de Pensiones</h3>
<p class="text-body text-gosign-text mt-2">Dos pagas extraordinarias obligatorias en junio y diciembre, más las aportaciones al Plan de Pensiones de empresa. El AI Agent gestiona miles de configuraciones individuales con el tratamiento fiscal y de cotización correcto. En caso de cambio de situación contractual: ajuste automático desde el mes siguiente.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Complementos INSST por riesgo</h3>
<p class="text-body text-gosign-text mt-2">El INSST (Instituto Nacional de Seguridad y Salud en el Trabajo) establece las evaluaciones de riesgos en la industria química. El AI Agent clasifica la evaluación de riesgos laborales por puesto de trabajo y asigna el complemento correcto. En caso de cambio de puesto: recálculo automático.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Pagos extraordinarios según calendario</h3>
<p class="text-body text-gosign-text mt-2">Paga extra de junio, paga de Navidad en diciembre, aportaciones al Plan de Pensiones mensuales. El AI Agent conoce vencimiento, tratamiento fiscal y cálculo de cotización de cada pago extraordinario. En caso de alta o baja dentro del año: cálculo proporcional automático.</p>
</div>
</div>
</div>
</section>

<!-- Flujo de decisión -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Una nómina química. 40 a 80 micro-decisiones.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Un trabajador a turnos en la industria química. El Payroll Decision Layer descompone su nómina en pasos de decisión individuales:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Paso</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decisión</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Responsable</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Justificación</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Clasificar convenio aplicable y grupo profesional</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">El Agent reconoce centro, convenio y verifica clasificación contra datos maestros</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Calcular retribución base</td><td class="py-3 px-4">Convenio colectivo</td><td class="py-3 px-4">Consulta en tabla CGIQ versionada: convenio + grupo + nivel</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Clasificar modelo de turno</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">El Agent reconoce: turno parcial continuo (6%), turno completo continuo (10%) o nocturnidad permanente desde el plan de turnos</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Calcular y acumular complementos</td><td class="py-3 px-4">Convenio colectivo</td><td class="py-3 px-4">Aplica el complemento más alto, nocturnidad siempre aditiva. Domingo 60%, festivo 150%</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Calcular partes exentas de impuestos</td><td class="py-3 px-4">Reglamento</td><td class="py-3 px-4">Exenciones parciales para nocturnidad, domingos y festivos según normativa fiscal vigente (IRPF)</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Clasificar complemento INSST por riesgo</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">El Agent clasifica puesto según evaluación de riesgos INSST: calor, frío, químicos, ruido</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Calcular 14 pagas y Plan de Pensiones</td><td class="py-3 px-4">Reglamento</td><td class="py-3 px-4">Pagas extras obligatorias + aportaciones empresariales, tratamiento fiscal y de cotización diferenciado</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">Calcular cotizaciones a la Seguridad Social</td><td class="py-3 px-4">Reglamento</td><td class="py-3 px-4">Contingencias comunes y profesionales con verificación de bases máximas y mínimas</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Verificación de desviaciones respecto al mes anterior</td><td class="py-3 px-4">IA detecta, persona decide</td><td class="py-3 px-4">La IA detecta desviaciones con mayor fiabilidad. Pero la reacción (¿promoción, error, traslado?) permanece en manos humanas - Art. 64 ET otorga al Comité de Empresa derechos de consulta</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Generar asientos contables</td><td class="py-3 px-4">Reglamento</td><td class="py-3 px-4">Contabilización, centro de coste, periodo contable - determinista</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Simulación -->
<section id="simulacion" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulación</p>
<h2 class="text-h1 font-bold text-white">Calculado para volúmenes del sector químico</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Hemos configurado el Payroll Decision Layer con parámetros realistas del sector químico español. Convenio general CGIQ, UGT FICA / CCOO Industria, modelos de turno, complementos INSST por riesgo, 14 pagas + Plan de Pensiones.</p>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Parámetros de simulación</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Empleados</td><td class="py-3 px-4">5.000 a 50.000+ (producción, laboratorio, administración)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Convenio colectivo</td><td class="py-3 px-4">CGIQ (UGT FICA / CCOO Industria), grupos profesionales</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Bases salariales</td><td class="py-3 px-4">169 (convenio x grupos) + progresión automática</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Modelos de turno</td><td class="py-3 px-4">Turno parcial continuo, turno completo continuo, nocturnidad permanente</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Pagos extraordinarios</td><td class="py-3 px-4">14 pagas, Plan de Pensiones, complementos de convenio</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Complementos INSST por riesgo</td><td class="py-3 px-4">5-15% según clasificación del puesto</td></tr>
</tbody>
</table>
</div>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Antes / Después</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th scope="col" class="text-left py-3 px-4 font-semibold text-white">Dimensión</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manual</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Tasa de error</td><td class="py-3 px-4">1-8% (APA)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 0,1%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Cuota Zero-Touch</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">88%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Cambio de convenio</td><td class="py-3 px-4">Semanas (múltiples centros manualmente)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 24h (todos los centros)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Cálculo de complementos</td><td class="py-3 px-4">Manual, propenso a errores</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Basado en reglas, consistente</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Preparación para auditoría</td><td class="py-3 px-4">Reconstruida manualmente</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Generada automáticamente</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Gestión 14 pagas y pensiones</td><td class="py-3 px-4">Hojas Excel por centro</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Centralizada, versionada</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">APA: American Payroll Association. CGIQ (UGT FICA / CCOO Industria). Repsol, CEPSA. Resultados de simulación: modelo de cálculo Gosign.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">En la simulación, el Decision Layer alcanza una cuota Zero-Touch del 88%. El 12% restante son excepciones reales: reevaluaciones INSST de peligrosidad, cambios en aportaciones a pensiones, traslados entre centros. Para el 88% existe un expediente de decisión completo y preparado para inspección.</p>
</div>
</section>

<!-- Referencia arquitectura -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Arquitectura e implementación</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">El Payroll Decision Layer funciona íntegramente en su infraestructura. Para la industria química esto significa: conexión con sistemas de planificación de turnos, procesamiento de evaluaciones INSST de riesgo, reglamentos por convenio aplicable y Audit Trail continuo hasta SAP HCM. Los pilotos típicos arrancan en 3 meses con un convenio y un grupo de personal.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/es/servicios/hr-agent/payroll-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Payroll Decision Layer vista general &rarr;</a>
<a href="/es/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Arquitectura del Decision Layer &rarr;</a>
<a href="/es/servicios/infraestructura/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infraestructura en detalle &rarr;</a>
<a href="/es/governance/co-determination/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Codeterminación y Comité de Empresa &rarr;</a>
<a href="/es/governance/cert-ready/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready by Design &rarr;</a>
<a href="/es/servicios/travel-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Travel Decision Layer &rarr;</a>
</div>
</div>
</section>


<!-- Weitere Agent-Lösungen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Más soluciones de agentes</h2>
<p class="text-body-lg text-gosign-text-light mt-4">Los HR Agents son parte de nuestro portfolio de agentes. Para finanzas y otras áreas ofrecemos soluciones especializadas.</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8 max-w-content">
<a href="/es/hr-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR & People Operations</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Todos los HR Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Compatible con comité de empresa.</p>
</a>
<a href="/es/finance-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Finance & Accounting</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Finance AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Procesamiento de documentos, contabilización, amortización, correcciones. Integración SAP/ERP.</p>
</a>
<a href="/es/contacto/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Individual</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Co-Build para su proceso</h3>
<p class="text-body text-gosign-text-light mt-2">Compliance, operaciones, shared services - desarrollamos agentes en modelo co-build.</p>
</a>
</div>
</div>
</section>

<!-- Profundización -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Profundización en el Agent Briefing (Revista Gosign)</h2>
<p class="text-body text-gosign-text-light mb-6">Nuestra serie de artículos especializados para responsables que implementan AI Agents en la empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/es/revista/decision-layer-payroll/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Finanzas</p>
<p class="text-body font-semibold text-gosign-dark">Eliminar errores de nómina de forma estructural - Decision Layer para finanzas</p>
</a>
<a href="/es/revista/comite-empresa-ia-codeterminacion/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Codeterminación</p>
<p class="text-body font-semibold text-gosign-dark">Comité de Empresa e IA - codeterminación como restricción arquitectónica</p>
</a>
<a href="/es/revista/decision-layer-explicado/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Fundamentos</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - ¿Qué es y por qué lo necesita cada AI Agent empresarial?</p>
</a>
</div>
</div>
</section>

<!-- Otros sectores -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Payroll Decision Layer en otros sectores</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Cada sector tiene sus propios convenios colectivos, sus propias reglas de complementos y sus propios factores de complejidad. El Decision Layer es el mismo. La configuración es específica de cada sector.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/es/servicios/hr-agent/payroll-decision-layer/aviation/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Aviación</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">3 sindicatos, 14-18 convenios, EASA FTL, antigüedad cockpit hasta nivel 23</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">82% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">En detalle &rarr;</span>
</div>
</a>
<a href="/es/servicios/hr-agent/payroll-decision-layer/financial-services/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Finanzas</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">5 regímenes retributivos, Bonus-Deferral, Malus/Clawback, obligaciones regulatorias</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">85% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">En detalle &rarr;</span>
</div>
</a>
<a href="/es/servicios/hr-agent/payroll-decision-layer/retail/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Comercio</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">Convenios provinciales, 64% tiempo parcial, picos estacionales</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">92% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">En detalle &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- AI Payroll Agent Finanzas - retribución ---
> Payroll Decision Layer para banca y servicios financieros. 5 regímenes retributivos, Bonus-Deferral, Malus/Clawback. 85% Zero-Touch.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/es/por-que-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Cada decisión rastreable</p>
</div>
</a>
<a href="/es/por-que-gosign/#infraestructura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Su infraestructura</p>
<p class="text-xs text-gosign-text-light">Sin SaaS. Sin vendor lock-in.</p>
</div>
</a>
<a href="/es/por-que-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Sin riesgo de cloud estadounidense</p>
</div>
</a>
</div>
</div>
</div>
<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Payroll Decision Layer Sectores">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/es/servicios/hr-agent/payroll-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Payroll Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/es/servicios/hr-agent/payroll-decision-layer/chemicals/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Química</a>
<a href="/es/servicios/hr-agent/payroll-decision-layer/aviation/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Aviación</a>
<a href="/es/servicios/hr-agent/payroll-decision-layer/financial-services/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Finanzas</a>
<a href="/es/servicios/hr-agent/payroll-decision-layer/retail/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Comercio</a>
</div>
</div>
</nav>

<!-- Complejidad -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">5</span>
<p class="text-small text-gosign-text-light mt-1">Regímenes retributivos en paralelo</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">85%</span>
<p class="text-small text-gosign-text-light mt-1">Cuota Zero-Touch</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">4-5 a.</span>
<p class="text-small text-gosign-text-light mt-1">Periodo de Bonus-Deferral</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
<span class="w-4 h-2 rounded-sm bg-gosign-border"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">Alta complejidad normativa</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">Circular 2/2016 CNMV, directrices Banco de España, directrices EBA, MiFID II. Entidades de referencia: Santander, BBVA. Zero-Touch: modelo de simulación Gosign.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Lo que clasifica el Agent</p>
<h2 class="text-h1 font-bold text-gosign-dark">Cinco regímenes, un Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Cinco regímenes retributivos, Bonus-Caps, Deferral durante años, Malus/Clawback retroactivo, obligación de reporte a la CNMV y al Banco de España. Usted conoce la complejidad. Así la resuelve el AI Agent:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">5 regímenes retributivos en paralelo</h3>
<p class="text-body text-gosign-text mt-2">Convenio, fuera de convenio, Risk Taker, Trading, Sales/Advisory - cada régimen con su propia lógica de cálculo. El AI Agent reconoce la asignación correcta desde datos contractuales, función y retribución total. En caso de cambio de régimen durante la carrera: ajuste automático de todos los parámetros de cálculo.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Bonus-Deferral durante 4-5 años</h3>
<p class="text-body text-gosign-text mt-2">40-60% de la retribución variable distribuida, dividida en componentes de acciones y efectivo, hasta 20 tramos en paralelo. El AI Agent gestiona cada tramo con su propia fecha de vesting y verifica el Bonus-Cap (100% fijo, 200% con aprobación de junta) automáticamente contra la Circular 2/2016 CNMV y las directrices EBA.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Malus/Clawback retroactivo</h3>
<p class="text-body text-gosign-text mt-2">Reclamación durante 5-7 años en caso de infracciones de cumplimiento o eventos de riesgo. El AI Agent reconoce eventos relevantes a partir de comunicaciones internas y prepara el caso. La decisión la toma siempre una persona - la CNMV y el Banco de España prevén responsabilidad personal de los responsables de retribución.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Obligaciones prudenciales para trading</h3>
<p class="text-body text-gosign-text mt-2">10 días consecutivos de vacaciones obligatorias al año, sin fraccionamiento. El AI Agent verifica automáticamente si se cumple el bloque de vacaciones y escala a HR a tiempo. Sin verificación manual de calendarios, sin pasar por alto plazos obligatorios.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Obligaciones de reporte a CNMV y Banco de España</h3>
<p class="text-body text-gosign-text mt-2">Informe anual de retribuciones con retribuciones de Risk Takers, estados de deferral, eventos de Malus/Clawback. El reglamento genera los datos del informe automáticamente desde los datos de nómina. Además, verificación MiFID II: componentes variables demostrablemente vinculados a calidad del servicio al cliente. El informe se remite a la CNMV y al Banco de España como parte de los informes regulatorios de entidades de crédito.</p>
</div>
</div>
</div>
</section>

<!-- Flujo de decisión -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Una nómina financiera. 30 a 60 micro-decisiones.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Un Risk Taker en un banco universal. El Payroll Decision Layer descompone su nómina en pasos de decisión individuales:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Paso</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decisión</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Responsable</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Justificación</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Clasificar régimen retributivo</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">El Agent reconoce: convenio (grupos 1-9), fuera de convenio, Risk Taker, Trading o Sales/Advisory desde datos contractuales</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Verificar estatus de Risk Taker</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Verificar umbral EUR 500.000, identificación EBA contra catálogo de funciones</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Calcular salario fijo</td><td class="py-3 px-4">Convenio/Contrato</td><td class="py-3 px-4">Convenio: consulta en tabla salarial. Fuera de convenio: acuerdo individual desde datos contractuales</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Calcular retribución variable</td><td class="py-3 px-4">Reglamento</td><td class="py-3 px-4">Evaluación de rendimiento, Bonus-Cap 100% salario fijo (200% con aprobación de junta)</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Calcular Deferral-Split</td><td class="py-3 px-4">Reglamento</td><td class="py-3 px-4">40-60% sobre 4-5 años, división en acciones y efectivo, fechas de vesting</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Ejecutar verificación de Malus</td><td class="py-3 px-4">IA detecta, persona decide</td><td class="py-3 px-4">La IA detecta infracciones de cumplimiento con mayor fiabilidad. Pero las decisiones de malus tienen consecuencias de responsabilidad personal - la CNMV y el Banco de España exigen responsabilidad humana</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Verificar bloque de vacaciones obligatorio</td><td class="py-3 px-4">Reglamento</td><td class="py-3 px-4">10 días consecutivos de vacaciones al año, plan de sustitución, escalación en caso de incumplimiento</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">Calcular cotizaciones a la Seguridad Social</td><td class="py-3 px-4">Reglamento</td><td class="py-3 px-4">Verificación de bases máximas, previsión complementaria, plan de pensiones empresa</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Generar datos de reporte regulatorio</td><td class="py-3 px-4">Reglamento</td><td class="py-3 px-4">Informe anual de retribuciones: datos de Risk Takers, estados de deferral, eventos de clawback para CNMV y Banco de España</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Generar asientos contables</td><td class="py-3 px-4">Reglamento</td><td class="py-3 px-4">Contabilización, contabilización multi-entidad, provisiones de deferral - determinista</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Simulación -->
<section id="simulacion" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulación</p>
<h2 class="text-h1 font-bold text-white">Calculado para volúmenes del sector financiero</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Hemos configurado el Payroll Decision Layer con parámetros realistas del sector financiero y lo hemos calculado. Circular 2/2016 CNMV, directrices Banco de España, directrices EBA, MiFID II, cinco regímenes retributivos, periodos de deferral durante años.</p>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Parámetros de simulación</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Empleados</td><td class="py-3 px-4">2.000 a 30.000+ (Front Office, Middle Office, Back Office)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Regímenes retributivos</td><td class="py-3 px-4">5 en paralelo: convenio (grupos 1-9), fuera de convenio, Risk Taker, Trading, Sales/Advisory</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Umbral Risk Taker</td><td class="py-3 px-4">EUR 500.000 retribución total, identificación EBA</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Bonus-Cap</td><td class="py-3 px-4">100% salario fijo (200% con aprobación de junta general)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Deferral</td><td class="py-3 px-4">40-60% sobre 4-5 años, split acciones/efectivo</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Malus/Clawback</td><td class="py-3 px-4">Periodo de reclamación 5-7 años</td></tr>
</tbody>
</table>
</div>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Antes / Después</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th scope="col" class="text-left py-3 px-4 font-semibold text-white">Dimensión</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manual</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Tasa de error</td><td class="py-3 px-4">1-8% (APA)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 0,1%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Cuota Zero-Touch</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">85%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Gestión de Deferral</td><td class="py-3 px-4">Excel, propenso a errores</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatizado, versionado</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Identificación Risk Taker</td><td class="py-3 px-4">Anual, manual</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Continua, automática</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Reporte al regulador</td><td class="py-3 px-4">Semanas (preparación manual)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 24h (generado automáticamente)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Preparación para auditoría</td><td class="py-3 px-4">Reconstruida manualmente</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Generada automáticamente</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">APA: American Payroll Association. Circular 2/2016 CNMV, directrices Banco de España, directrices EBA, MiFID II. Entidades de referencia: Santander, BBVA. Resultados de simulación: modelo de cálculo Gosign.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">En la simulación, el Decision Layer alcanza una cuota Zero-Touch del 85%. El 15% restante son excepciones reales: casos límite de Risk Taker, decisiones de malus, cambios de régimen por cambio de función. Para el 85% existe un expediente de decisión completo y preparado para inspección.</p>
</div>
</section>

<!-- Referencia arquitectura -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Arquitectura e implementación</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">El Payroll Decision Layer funciona íntegramente en su infraestructura. Para el sector financiero esto significa: conexión con sistemas bancarios centrales, procesamiento de identificación de Risk Takers, reglamentos regulatorios para la Circular 2/2016 CNMV y las directrices del Banco de España, y Audit Trail continuo hasta SAP HCM. Los pilotos típicos arrancan en 3 meses con un régimen retributivo y un grupo de personal.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/es/servicios/hr-agent/payroll-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Payroll Decision Layer vista general &rarr;</a>
<a href="/es/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Arquitectura del Decision Layer &rarr;</a>
<a href="/es/servicios/infraestructura/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infraestructura en detalle &rarr;</a>
<a href="/es/governance/co-determination/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Codeterminación y Comité de Empresa &rarr;</a>
<a href="/es/governance/cert-ready/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready by Design &rarr;</a>
<a href="/es/servicios/travel-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Travel Decision Layer &rarr;</a>
</div>
</div>
</section>


<!-- Weitere Agent-Lösungen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Más soluciones de agentes</h2>
<p class="text-body-lg text-gosign-text-light mt-4">Los HR Agents son parte de nuestro portfolio de agentes. Para finanzas y otras áreas ofrecemos soluciones especializadas.</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8 max-w-content">
<a href="/es/hr-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR & People Operations</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Todos los HR Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Compatible con comité de empresa.</p>
</a>
<a href="/es/finance-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Finance & Accounting</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Finance AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Procesamiento de documentos, contabilización, amortización, correcciones. Integración SAP/ERP.</p>
</a>
<a href="/es/contacto/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Individual</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Co-Build para su proceso</h3>
<p class="text-body text-gosign-text-light mt-2">Compliance, operaciones, shared services - desarrollamos agentes en modelo co-build.</p>
</a>
</div>
</div>
</section>

<!-- Profundización -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Profundización en el Agent Briefing (Revista Gosign)</h2>
<p class="text-body text-gosign-text-light mb-6">Nuestra serie de artículos especializados para responsables que implementan AI Agents en la empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/es/revista/decision-layer-payroll/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Finanzas</p>
<p class="text-body font-semibold text-gosign-dark">Eliminar errores de nómina de forma estructural - Decision Layer para finanzas</p>
</a>
<a href="/es/revista/comite-empresa-ia-codeterminacion/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Codeterminación</p>
<p class="text-body font-semibold text-gosign-dark">Comité de Empresa e IA - codeterminación como restricción arquitectónica</p>
</a>
<a href="/es/revista/decision-layer-explicado/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Fundamentos</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - ¿Qué es y por qué lo necesita cada AI Agent empresarial?</p>
</a>
</div>
</div>
</section>

<!-- Otros sectores -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Payroll Decision Layer en otros sectores</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Cada sector tiene sus propios convenios colectivos, sus propias reglas de complementos y sus propios factores de complejidad. El Decision Layer es el mismo. La configuración es específica de cada sector.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/es/servicios/hr-agent/payroll-decision-layer/chemicals/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Química</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">169 bases salariales (13 regiones x 13 grupos), complementos de turno, aportación futuro</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">88% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">En detalle &rarr;</span>
</div>
</a>
<a href="/es/servicios/hr-agent/payroll-decision-layer/aviation/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Aviación</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">3 sindicatos, 14-18 convenios, EASA FTL, antigüedad cockpit hasta nivel 23</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">82% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">En detalle &rarr;</span>
</div>
</a>
<a href="/es/servicios/hr-agent/payroll-decision-layer/retail/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Comercio</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">576 bases salariales (16 regiones x 6 grupos x 6 niveles), 64% tiempo parcial, picos estacionales</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">92% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">En detalle &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- AI Payroll Agent Comercio - nóminas sector ---
> Payroll Decision Layer para el comercio. 50 convenios provinciales, 17 CCAA, fijos-discontinuos, complementos. 92% Zero-Touch.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/es/por-que-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Cada decisión rastreable</p>
</div>
</a>
<a href="/es/por-que-gosign/#infraestructura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Su infraestructura</p>
<p class="text-xs text-gosign-text-light">Sin SaaS. Sin vendor lock-in.</p>
</div>
</a>
<a href="/es/por-que-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Sin riesgo de cloud estadounidense</p>
</div>
</a>
</div>
</div>
</div>
<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Payroll Decision Layer Sectores">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/es/servicios/hr-agent/payroll-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Payroll Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/es/servicios/hr-agent/payroll-decision-layer/chemicals/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Química</a>
<a href="/es/servicios/hr-agent/payroll-decision-layer/aviation/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Aviación</a>
<a href="/es/servicios/hr-agent/payroll-decision-layer/financial-services/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Finanzas</a>
<a href="/es/servicios/hr-agent/payroll-decision-layer/retail/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Comercio</a>
</div>
</div>
</nav>

<!-- Complejidad -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">576</span>
<p class="text-small text-gosign-text-light mt-1">Bases salariales</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">92%</span>
<p class="text-small text-gosign-text-light mt-1">Cuota Zero-Touch</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">64%</span>
<p class="text-small text-gosign-text-light mt-1">Cuota de tiempo parcial</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
<span class="w-4 h-2 rounded-sm bg-gosign-border"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">Alta complejidad normativa</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">50 convenios provinciales de comercio 2024-2026, 17 CCAA. Zero-Touch: modelo de simulación Gosign. Referencias: Mercadona, El Corte Inglés.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Lo que clasifica el Agent</p>
<h2 class="text-h1 font-bold text-gosign-dark">50 convenios provinciales, un Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">El comercio español abarca 50 convenios provinciales en 17 Comunidades Autónomas, negociados por UGT FICA y CCOO Servicios. 64% tiempo parcial, 100.000 trabajadores de temporada, 25,7% rotación. Usted conoce la complejidad. Así la resuelve el AI Agent:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">576 bases salariales (50 convenios provinciales, 17 CCAA)</h3>
<p class="text-body text-gosign-text mt-2">Cada provincia tiene su propio convenio de comercio, con tablas salariales por categoría profesional. El AI Agent reconoce la combinación correcta desde centro, actividad y antigüedad. En caso de traslado entre provincias: cambio automático de toda la estructura retributiva al convenio aplicable. Referencias: Mercadona, El Corte Inglés.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">64% tiempo parcial (contratos fijos-discontinuos, Reforma Laboral 2022)</h3>
<p class="text-body text-gosign-text mt-2">Tras la Reforma Laboral 2022, los contratos fijos-discontinuos son el mecanismo principal de flexibilidad en el comercio. El AI Agent verifica en cada nómina el tipo de contrato, periodos de actividad e inactividad, y clasifica las cotizaciones correspondientes a la Seguridad Social. En cambios legislativos: reclasificación automática de todos los afectados.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">100.000 trabajadores de temporada (fijos-discontinuos estacionales)</h3>
<p class="text-body text-gosign-text mt-2">Los fijos-discontinuos estacionales tienen campañas definidas con inicio y fin regulado. El AI Agent lleva un control exacto de días de actividad por trabajador y campaña - en todos los centros. Al aproximarse al fin de campaña: escalación automática. En situación de irregularidad: aplicación automática de las obligaciones completas de cotización.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Acumulación de complementos (solo el más alto, nocturnidad aditiva)</h3>
<p class="text-body text-gosign-text mt-2">Vespertino 20-40%, domingo 120%, festivo 200%, nocturnidad 55%. El AI Agent aplica la regla de acumulación: aplica el complemento más alto, nocturnidad siempre aditiva. Domingo noche: 120% más 55%, no 200%. Sin recálculo manual por turno.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">25,7% rotación (flujo permanente de altas y bajas)</h3>
<p class="text-body text-gosign-text mt-2">Más de 2.500 altas y bajas al año con 10.000 empleados. El AI Agent calcula retribución proporcional, liquidación de vacaciones pendientes y bajas en Seguridad Social automáticamente - cada caso individual, sin cálculo proporcional manual.</p>
</div>
</div>
</div>
</section>

<!-- Flujo de decisión -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Una nómina de comercio. 30 a 60 micro-decisiones.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Una trabajadora a tiempo parcial en comercio minorista con turnos de tarde y domingos. El Payroll Decision Layer descompone su nómina en pasos de decisión individuales:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Paso</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decisión</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Responsable</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Justificación</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Clasificar provincia y convenio</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Centro - provincia - convenio provincial de comercio correcto de los 50 convenios</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Asignar categoría profesional y nivel</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Actividad - categoría profesional, antigüedad - nivel de experiencia</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Calcular retribución base</td><td class="py-3 px-4">Convenio provincial</td><td class="py-3 px-4">Consulta en tabla del convenio: categoría + nivel = salario base</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Cálculo proporcional por tiempo parcial</td><td class="py-3 px-4">Reglamento</td><td class="py-3 px-4">Cálculo proporcional según horas contratadas, cálculo de salario/hora para complementos</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Verificar tipo de contrato (fijo-discontinuo)</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Contrato fijo-discontinuo, temporal o indefinido; cotizaciones específicas por tipo (Reforma 2022)</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Clasificar y acumular complementos</td><td class="py-3 px-4">AI Agent + Convenio</td><td class="py-3 px-4">Vespertino 20-40%, nocturnidad 55%, domingo 120%, festivo 200% - solo el más alto, nocturnidad aditiva</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Calcular cotizaciones a la Seguridad Social</td><td class="py-3 px-4">Reglamento</td><td class="py-3 px-4">Cotización estándar, cotización fijo-discontinuo, o cálculo proporcional según tipo</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">Verificar estatus de temporalidad</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Control de campaña fijo-discontinuo, periodos de actividad/inactividad, obligaciones de cotización</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Verificación de desviaciones</td><td class="py-3 px-4">IA detecta, persona decide</td><td class="py-3 px-4">La IA detecta desviaciones con mayor fiabilidad. Pero la evaluación (¿cambio de estatus, error, traslado?) permanece en manos humanas - Art. 64 ET, Comité de Empresa</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Generar asientos contables</td><td class="py-3 px-4">Reglamento</td><td class="py-3 px-4">Contabilización, multi-centro, asignación de centro de coste - determinista</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Simulación -->
<section id="simulacion" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulación</p>
<h2 class="text-h1 font-bold text-white">Calculado para volúmenes del comercio</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Hemos configurado el Payroll Decision Layer con parámetros realistas del comercio español. 50 convenios provinciales, contratos fijos-discontinuos (Reforma Laboral 2022), trabajadores de temporada, acumulación de complementos, alta rotación.</p>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Parámetros de simulación</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Empleados</td><td class="py-3 px-4">5.000 a 50.000+ (ventas, caja, almacén, administración)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Convenio colectivo</td><td class="py-3 px-4">Comercio, 50 convenios provinciales, 17 CCAA (UGT FICA / CCOO Servicios)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Bases salariales</td><td class="py-3 px-4">576 (provincias x categorías x niveles)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Cuota tiempo parcial</td><td class="py-3 px-4">64% (fijos-discontinuos, tiempo parcial, tiempo parcial regular)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Trabajadores de temporada</td><td class="py-3 px-4">Aprox. 100.000 (fijos-discontinuos estacionales, campañas reguladas)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Complementos</td><td class="py-3 px-4">Vespertino 20-40%, nocturnidad 55%, domingo 120%, festivo 200%</td></tr>
</tbody>
</table>
</div>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Antes / Después</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th scope="col" class="text-left py-3 px-4 font-semibold text-white">Dimensión</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manual</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Tasa de error</td><td class="py-3 px-4">1-8% (APA)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 0,1%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Cuota Zero-Touch</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">92%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Cambio de convenio</td><td class="py-3 px-4">Semanas (50 provincias manualmente)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 24h (todas las provincias)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Detección tipo de contrato</td><td class="py-3 px-4">Manual, con retraso</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Tiempo real, por nómina</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Seguimiento temporalidad</td><td class="py-3 px-4">Excel, lagunas entre centros</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automático, todos los centros</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Preparación para auditoría</td><td class="py-3 px-4">Reconstruida manualmente</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Generada automáticamente</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">APA: American Payroll Association. 50 convenios provinciales de comercio 2024-2026, 17 CCAA. Referencias: Mercadona, El Corte Inglés. Resultados de simulación: modelo de cálculo Gosign.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">En la simulación, el Decision Layer alcanza una cuota Zero-Touch del 92%. El 8% restante son excepciones reales: casos límite de fijos-discontinuos, cambios de tipo de contrato, traslados entre provincias. Para el 92% existe un expediente de decisión completo y preparado para inspección.</p>
</div>
</section>

<!-- Referencia arquitectura -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Arquitectura e implementación</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">El Payroll Decision Layer funciona íntegramente en su infraestructura. Para el comercio español esto significa: conexión con control horario de centros, procesamiento de contratos fijos-discontinuos (Reforma 2022), convenios provinciales por CCAA, seguimiento de temporalidad en todos los centros y Audit Trail continuo hasta SAP HCM. Los pilotos típicos arrancan en 3 meses con una provincia y un grupo de centros.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/es/servicios/hr-agent/payroll-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Payroll Decision Layer vista general &rarr;</a>
<a href="/es/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Arquitectura del Decision Layer &rarr;</a>
<a href="/es/servicios/infraestructura/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infraestructura en detalle &rarr;</a>
<a href="/es/governance/co-determination/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Codeterminación y Comité de Empresa &rarr;</a>
<a href="/es/governance/cert-ready/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready by Design &rarr;</a>
<a href="/es/servicios/travel-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Travel Decision Layer &rarr;</a>
</div>
</div>
</section>


<!-- Weitere Agent-Lösungen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Más soluciones de agentes</h2>
<p class="text-body-lg text-gosign-text-light mt-4">Los HR Agents son parte de nuestro portfolio de agentes. Para finanzas y otras áreas ofrecemos soluciones especializadas.</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8 max-w-content">
<a href="/es/hr-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR & People Operations</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Todos los HR Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Compatible con comité de empresa.</p>
</a>
<a href="/es/finance-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Finance & Accounting</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Finance AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Procesamiento de documentos, contabilización, amortización, correcciones. Integración SAP/ERP.</p>
</a>
<a href="/es/contacto/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Individual</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Co-Build para su proceso</h3>
<p class="text-body text-gosign-text-light mt-2">Compliance, operaciones, shared services - desarrollamos agentes en modelo co-build.</p>
</a>
</div>
</div>
</section>

<!-- Profundización -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Profundización en el Agent Briefing (Revista Gosign)</h2>
<p class="text-body text-gosign-text-light mb-6">Nuestra serie de artículos especializados para responsables que implementan AI Agents en la empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/es/revista/decision-layer-payroll/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Finanzas</p>
<p class="text-body font-semibold text-gosign-dark">Eliminar errores de nómina de forma estructural - Decision Layer para finanzas</p>
</a>
<a href="/es/revista/comite-empresa-ia-codeterminacion/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Codeterminación</p>
<p class="text-body font-semibold text-gosign-dark">Comité de Empresa e IA - codeterminación como restricción arquitectónica</p>
</a>
<a href="/es/revista/decision-layer-explicado/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Fundamentos</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - ¿Qué es y por qué lo necesita cada AI Agent empresarial?</p>
</a>
</div>
</div>
</section>

<!-- Otros sectores -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Payroll Decision Layer en otros sectores</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Cada sector tiene sus propios convenios colectivos, sus propias reglas de complementos y sus propios factores de complejidad. El Decision Layer es el mismo. La configuración es específica de cada sector.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/es/servicios/hr-agent/payroll-decision-layer/chemicals/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Química</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">169 bases salariales, 13 regiones, complementos de turno con acumulación, aportación futuro</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">88% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">En detalle &rarr;</span>
</div>
</a>
<a href="/es/servicios/hr-agent/payroll-decision-layer/aviation/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Aviación</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">3 sindicatos, 14-18 convenios, EASA FTL, antigüedad cockpit hasta nivel 23</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">82% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">En detalle &rarr;</span>
</div>
</a>
<a href="/es/servicios/hr-agent/payroll-decision-layer/financial-services/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Finanzas</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">5 regímenes retributivos, Bonus-Deferral, Malus/Clawback, obligaciones regulatorias</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">85% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">En detalle &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- AI Payroll Decision Layer - nóminas empresariales ---
> El Decision Layer descompone cada nómina en pasos de decisión. Basado en reglas, auditable, 82-92% Zero-Touch.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/es/por-que-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Cada decisión rastreable</p>
</div>
</a>
<a href="/es/por-que-gosign/#infraestructura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Su infraestructura</p>
<p class="text-xs text-gosign-text-light">Sin SaaS. Sin vendor lock-in.</p>
</div>
</a>
<a href="/es/por-que-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Sin riesgo de cloud estadounidense</p>
</div>
</a>
</div>
</div>
</div>

<!-- Problema -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div><span class="text-h1 font-bold text-gosign-accent-text">1-8%</span><p class="text-small text-gosign-text-light mt-1">Tasa de error en nóminas</p></div>
<div><span class="text-h1 font-bold text-gosign-accent-text">EUR 260</span><p class="text-small text-gosign-text-light mt-1">Coste total por incidente de error</p></div>
<div><span class="text-h1 font-bold text-gosign-accent-text">10</span><p class="text-small text-gosign-text-light mt-1">Pasos de decisión por nómina</p></div>
<p class="sm:col-span-3 text-xs text-gosign-text-light">American Payroll Association (APA); EY / HR Dive, "The True Cost of Payroll" (USD 281 por incidente, convertido al tipo de cambio medio)</p>
</div>
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">El problema</p>
<h2 class="text-h1 font-bold text-gosign-dark">Por qué los sistemas de nóminas fallan en organizaciones complejas</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">SAP HCM calcula correctamente. A3Nómina calcula correctamente. Cualquier motor de nóminas calcula correctamente - si los datos de entrada son correctos. Pero en organizaciones con múltiples convenios colectivos, modelos de turnos, variaciones regionales y decenas de reglas de complementos, el cálculo no es el problema. La decisión previa sí lo es: ¿Qué tabla aplica? ¿Qué complemento corresponde? ¿Es admisible la acumulación?</p>
<div class="mt-10 grid grid-cols-1 sm:grid-cols-3 gap-6">
<div class="bg-gosign-light border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">1-8% tasa de error</h3><p class="text-small text-gosign-text-light mt-2">Múltiples grupos salariales, regiones, categorías fiscales, cotizaciones a seguridad social, retribución flexible, embargos, complementos con reglas de acumulación. Ningún técnico de nóminas conoce todas las reglas de todos los convenios. El 1-8% de las nóminas contiene errores (APA) - cuanto más complejo el panorama de convenios, mayor la tasa.</p></div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">EUR 260 por error</h3><p class="text-small text-gosign-text-light mt-2">Un solo error de nómina desencadena cuatro procesos consecuentes: anulación de la nómina original, recálculo, corrección ante la Seguridad Social, declaración fiscal corregida a Hacienda. En total, un incidente de error cuesta una media de EUR 260 (EY; estudio original: USD 281). Con 2.000 empleados y 1-8% de error, son 20-160 incidentes al mes.</p></div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">Cero transparencia en reglas</h3><p class="text-small text-gosign-text-light mt-2">Cuando la inspección de Hacienda pregunta: ¿Por qué se calculó un 25% de complemento nocturno en lugar de un 20%? ¿Qué convenio colectivo aplicaba en ese momento? ¿Era correcta la categoría salarial? Falta la evidencia. Los sistemas de nóminas documentan resultados. No las decisiones que condujeron a ellos.</p></div>
</div>
</div>
</section>

<!-- Decision Layer -->
<section id="decision-layer" class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">El Decision Layer</p>
<h2 class="text-h1 font-bold text-gosign-dark">Cada nómina. Descompuesta en pasos de decisión.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">El Payroll Decision Layer descompone cada nómina en pasos de decisión individuales. Para cada paso se define quién decide: El AI Agent clasifica situaciones y detecta desviaciones - con mayor fiabilidad y rapidez que cualquier técnico de nóminas. El reglamento calcula importes - de forma determinista y reproducible. El ser humano permanece en el proceso donde el Comité de Empresa (Art. 64 ET), el Estatuto de los Trabajadores o el riesgo de discriminación exigen una decisión humana.</p>
<div class="mt-10 overflow-x-auto">
<table class="w-full text-left text-body">
<thead><tr class="border-b-2 border-gosign-dark"><th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Paso</th><th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Decisión</th><th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Responsable</th><th scope="col" class="py-3 font-bold text-gosign-dark">Justificación</th></tr></thead>
<tbody class="text-gosign-text-light">
<tr class="border-b border-gosign-border"><td class="py-3 pr-4 font-medium text-gosign-dark">1</td><td class="py-3 pr-4">Validar categoría fiscal, deducciones, datos de Seguridad Social</td><td class="py-3 pr-4 font-medium">Reglamento</td><td class="py-3">Cotejo con datos de la Agencia Tributaria, determinista</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4 font-medium text-gosign-dark">2</td><td class="py-3 pr-4">Verificar clasificación según convenio colectivo</td><td class="py-3 pr-4 font-medium">AI Agent</td><td class="py-3">El Agent clasifica: ¿Qué convenio, qué grupo salarial, qué nivel? Compara contra datos maestros y detecta inconsistencias</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4 font-medium text-gosign-dark">3</td><td class="py-3 pr-4">Calcular retribución base</td><td class="py-3 pr-4 font-medium">Convenio colectivo</td><td class="py-3">Consulta en tabla salarial versionada, región + grupo + nivel</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4 font-medium text-gosign-dark">4</td><td class="py-3 pr-4">Calcular complementos (nocturnidad/domingo/festivo)</td><td class="py-3 pr-4 font-medium">AI Agent + Convenio</td><td class="py-3">El Agent clasifica el tipo de complemento desde los datos de turno. El convenio define porcentajes y reglas de acumulación</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4 font-medium text-gosign-dark">5</td><td class="py-3 pr-4">Identificar partes exentas de impuestos</td><td class="py-3 pr-4 font-medium">Reglamento</td><td class="py-3">Normativa fiscal: exenciones parciales para nocturnidad, domingos y festivos según legislación vigente</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4 font-medium text-gosign-dark">6</td><td class="py-3 pr-4">Calcular retribución flexible / planes de pensiones</td><td class="py-3 pr-4 font-medium">Reglamento</td><td class="py-3">Aportación del trabajador + empresa, verificar exenciones fiscales y de cotización</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4 font-medium text-gosign-dark">7</td><td class="py-3 pr-4">Calcular cotizaciones a la Seguridad Social</td><td class="py-3 pr-4 font-medium">Reglamento</td><td class="py-3">Contingencias comunes, profesionales, desempleo, formación - con verificación de bases máximas</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4 font-medium text-gosign-dark">8</td><td class="py-3 pr-4">Aplicar embargos</td><td class="py-3 pr-4 font-medium">Reglamento + Persona</td><td class="py-3">Tabla de embargo determinista; en caso de conflicto de prelación: Human-in-the-Loop</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4 font-medium text-gosign-dark">9</td><td class="py-3 pr-4">Verificación de desviaciones respecto al mes anterior</td><td class="py-3 pr-4 font-medium">IA detecta, persona decide</td><td class="py-3">La IA detecta desviaciones con mayor fiabilidad que cualquier técnico de nóminas. Pero la decisión sobre qué hacer ante una desviación debe permanecer en manos humanas: ¿Fue una promoción, un error de datos o un error real de nómina? Sin esta separación, la verificación de cumplimiento se convierte en supervisión del rendimiento - y para eso el Estatuto de los Trabajadores (Art. 64 ET) exige consulta previa al Comité de Empresa.</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4 font-medium text-gosign-dark">10</td><td class="py-3 pr-4">Generar asientos contables</td><td class="py-3 pr-4 font-medium">Reglamento</td><td class="py-3">Contabilización, centro de coste, periodo contable - determinista</td></tr>
</tbody>
</table>
</div>
<p class="text-body text-gosign-text mt-8 max-w-narrow font-semibold">10 pasos por nómina. El AI Agent puede ejecutar cada uno de ellos mejor y más rápido que un técnico de nóminas. Aun así, el ser humano permanece en puntos definidos del proceso - no porque lo haga mejor, sino porque el Comité de Empresa, el Estatuto de los Trabajadores o el riesgo de discriminación lo exigen. Con 10.000 empleados, son 100.000 microdecisiones documentadas al mes.</p>
<div class="mt-10 grid grid-cols-1 sm:grid-cols-2 gap-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">La IA clasifica. El reglamento calcula.</h3><p class="text-small text-gosign-text-light mt-2">El AI Agent reconoce: ¿Qué convenio colectivo aplica? ¿Qué tipo de complemento corresponde? ¿Es correcta la clasificación? Esta clasificación la realiza con mayor fiabilidad que cualquier técnico de nóminas. El cálculo del importe se ejecuta mediante Decision Tables versionadas - determinista, reproducible, auditable.</p></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">40 a 80 microdecisiones por nómina</h3><p class="text-small text-gosign-text-light mt-2">Los 10 pasos principales se descomponen en decenas de subpasos: cada complemento tiene sus propias reglas de acumulación, cada tipo de cotización su propia verificación de bases máximas, cada embargo su propia prelación. Cada uno documentado individualmente.</p></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">AI Agent, reglamento o persona</h3><p class="text-small text-gosign-text-light mt-2">El AI Agent clasifica situaciones y toma decisiones - con mayor fiabilidad que cualquier técnico de nóminas. El reglamento calcula el importe. El ser humano permanece donde el Comité de Empresa (Art. 64 ET), el Estatuto de los Trabajadores o el riesgo de discriminación exigen una decisión humana - no porque lo haga mejor, sino porque debe hacerlo.</p></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">Persona en el proceso: no expertise, sino responsabilidad</h3><p class="text-small text-gosign-text-light mt-2">La nómina tradicional exige revisión manual en todas partes. Los AI Agents pueden hacerlo mejor. Pero en prelación de embargos, evaluación de desviaciones y decisiones de clasificación, la legislación o el Comité de Empresa exigen una decisión humana. El Decision Layer sabe dónde - y escala solo ahí.</p></div>
</div>
</div>
</section>

<!-- Governance -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<h2 class="text-h1 font-bold text-gosign-dark">No documentado a posteriori. Generado en el proceso.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Cuando la inspección de Hacienda pregunta "¿Por qué se calculó un 25% de complemento nocturno?" no basta con "eso dice el convenio". ¿Qué convenio? ¿Qué versión? ¿Aplicaba la regla de acumulación? El Payroll Decision Layer genera para cada microdecisión un acta de decisión que responde exactamente a estas preguntas: input, regla de negocio aplicada con su versión, confianza, resultado, marca de tiempo y vía de impugnación. La misma acta hace también cumplible la explicación de la decisión individual conforme al art. 86 del EU AI Act.</p>
<div class="mt-10 bg-gosign-dark rounded-card p-6 sm:p-8">
<div class="flex items-start gap-4 mb-6"><svg class="w-8 h-8 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12h6m-6 4h6m2 5H7a2 2 0 01-2-2V5a2 2 0 012-2h5.586a1 1 0 01.707.293l5.414 5.414a1 1 0 01.293.707V19a2 2 0 01-2 2z" /></svg><div><h3 class="text-h3 font-bold text-white">Cada microdecisión genera una entrada de auditoría</h3><p class="text-small text-gosign-text-on-dark/70 mt-1">Append-only. Nada se sobrescribe, nada se elimina. En correcciones se generan asientos de anulación y ajuste. Firmado SHA-256, exportable en cualquier momento.</p></div></div>
<div class="grid grid-cols-2 sm:grid-cols-3 gap-3 sm:gap-4">
<div class="flex items-center gap-2.5"><svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg><span class="text-small text-gosign-text-on-dark/80">ID de regla + versión</span></div>
<div class="flex items-center gap-2.5"><svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg><span class="text-small text-gosign-text-on-dark/80">Convenio colectivo + periodo de vigencia</span></div>
<div class="flex items-center gap-2.5"><svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg><span class="text-small text-gosign-text-on-dark/80">Datos de entrada (horas, tipo de complemento)</span></div>
<div class="flex items-center gap-2.5"><svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg><span class="text-small text-gosign-text-on-dark/80">Resultado (importe, tratamiento fiscal)</span></div>
<div class="flex items-center gap-2.5"><svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg><span class="text-small text-gosign-text-on-dark/80">Responsable (reglamento / convenio / persona)</span></div>
<div class="flex items-center gap-2.5"><svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg><span class="text-small text-gosign-text-on-dark/80">Hash de entrada (reproducible)</span></div>
</div>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8">
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6"><div class="flex items-start gap-3"><svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M15 12a3 3 0 11-6 0 3 3 0 016 0z" /><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M2.458 12C3.732 7.943 7.523 5 12 5c4.478 0 8.268 2.943 9.542 7-1.274 4.057-5.064 7-9.542 7-4.477 0-8.268-2.943-9.542-7z" /></svg><div><h3 class="text-body font-semibold text-gosign-dark">Transparente para el Comité de Empresa</h3><p class="text-small text-gosign-text-light mt-2">Estatuto de los Trabajadores (Art. 64 ET): derecho de consulta del Comité de Empresa sobre política retributiva. Reglamento visible, decisiones trazables, detección de anomalías configurable por Feature Flag, informes pseudonimizados.</p><a href="/es/governance/co-determination/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Codeterminación &rarr;</a></div></div></div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6"><div class="flex items-start gap-3"><svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12l2 2 4-4m5.618-4.016A11.955 11.955 0 0112 2.944a11.955 11.955 0 01-8.618 3.04A12.02 12.02 0 003 9c0 5.591 3.824 10.29 9 11.622 5.176-1.332 9-6.03 9-11.622 0-1.042-.133-2.052-.382-3.016z" /></svg><div><h3 class="text-body font-semibold text-gosign-dark">Preparado para inspección</h3><p class="text-small text-gosign-text-light mt-2">Plazos de conservación soportados (6 años según legislación fiscal española). Anonimización en lugar de eliminación para compatibilidad con RGPD + LOPDGDD. Cada nómina reproducible mediante hash de entrada.</p><a href="/es/governance/cert-ready/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready &rarr;</a></div></div></div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6"><div class="flex items-start gap-3"><svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 5H7a2 2 0 00-2 2v12a2 2 0 002 2h10a2 2 0 002-2V7a2 2 0 00-2-2h-2M9 5a2 2 0 002 2h2a2 2 0 002-2M9 5a2 2 0 012-2h2a2 2 0 012 2m-6 9l2 2 4-4" /></svg><div><h3 class="text-body font-semibold text-gosign-dark">Cumplimiento sistemático</h3><p class="text-small text-gosign-text-light mt-2">Cada nómina se verifica contra el reglamento completo - no por muestreo, sino de forma sistemática. Las desviaciones se detectan y documentan, no al recibir la inspección de Hacienda.</p></div></div></div>
</div>
</div>
</section>

<!-- Integración -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Integración</p>
<h2 class="text-h1 font-bold text-gosign-dark">Se conecta a su ecosistema de sistemas actual</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Sus sistemas permanecen. El trabajo de decisión manual previo desaparece. El Payroll Decision Layer se sitúa entre sus sistemas origen y su motor de nóminas - toma las decisiones que hoy toman los técnicos de nóminas.</p>
<div class="grid grid-cols-1 md:grid-cols-3 gap-6 mt-10">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><div class="flex items-center gap-3 mb-4"><svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M20 7l-8-4-8 4m16 0l-8 4m8-4v10l-8 4m0-10L4 7m8 4v10M4 7v10l8 4" /></svg><h3 class="text-body font-semibold text-gosign-dark">Fuentes de datos</h3></div><ul class="space-y-2 text-small text-gosign-text-light"><li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Control horario (SAP CATS, Atoss, Interflex)</span></li><li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Planificación de turnos (ATOSS, SP Expert)</span></li><li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Datos maestros de personal (SAP HCM, Workday)</span></li><li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Agencia Tributaria (datos fiscales)</span></li><li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Base de datos de convenios colectivos (versionada)</span></li></ul></div>
<div class="bg-gosign-dark border border-gosign-dark rounded-card p-6"><div class="flex items-center gap-3 mb-4"><svg class="w-6 h-6 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9.75 3.104v5.714a2.25 2.25 0 01-.659 1.591L5 14.5M9.75 3.104c-.251.023-.501.05-.75.082m.75-.082a24.301 24.301 0 014.5 0m0 0v5.714c0 .597.237 1.17.659 1.591L19.8 15.3M14.25 3.104c.251.023.501.05.75.082M19.8 15.3l-1.57.393A9.065 9.065 0 0112 15a9.065 9.065 0 00-6.23.693L5 14.5m14.8.8l1.402 1.402c1.232 1.232.65 3.318-1.067 3.611A48.309 48.309 0 0112 21c-2.773 0-5.491-.235-8.135-.687-1.718-.293-2.3-2.379-1.067-3.61L5 14.5" /></svg><h3 class="text-body font-semibold text-white">Payroll Decision Layer</h3></div><ul class="space-y-2 text-small text-gosign-text-on-dark/80"><li>Clasificación según convenio colectivo</li><li>Cálculo de complementos + acumulación</li><li>Partes exentas de impuestos</li><li>Cotizaciones SS + verificación de bases</li><li>Cálculo de embargos</li><li>Retribución flexible / pensiones</li><li>Verificación de desviaciones + escalado</li></ul></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><div class="flex items-center gap-3 mb-4"><svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M5.25 14.25h13.5m-13.5 0a3 3 0 01-3-3m3 3a3 3 0 100 6h13.5a3 3 0 100-6m-16.5-3a3 3 0 013-3h13.5a3 3 0 013 3m-19.5 0a4.5 4.5 0 01.9-2.7L5.737 5.1a3.375 3.375 0 012.7-1.35h7.126c1.062 0 2.062.5 2.7 1.35l2.587 3.45a4.5 4.5 0 01.9 2.7m0 0a3 3 0 01-3 3m0 3h.008v.008h-.008v-.008zm0-6h.008v.008h-.008v-.008zm-3 6h.008v.008h-.008v-.008zm0-6h.008v.008h-.008v-.008z" /></svg><h3 class="text-body font-semibold text-gosign-dark">Sistemas destino</h3></div><ul class="space-y-2 text-small text-gosign-text-light"><li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>SAP HCM / SuccessFactors (nóminas)</span></li><li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>A3Nómina / Sage (nóminas)</span></li><li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>SAP FI/CO (contabilización)</span></li><li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Sistema de comunicaciones a la Seguridad Social</span></li><li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Agencia Tributaria (IRPF, modelos fiscales)</span></li></ul></div>
</div>
</div>
</section>

<!-- Simulaciones -->
<section id="simulaciones" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulado para volúmenes enterprise</p>
<h2 class="text-h1 font-bold text-white">Cuatro sectores. Calculados al detalle.</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Hemos configurado el Payroll Decision Layer para cuatro sectores con convenios colectivos reales, reglas de complementos y estructuras de personal y lo hemos calculado al detalle. Cada tarjeta muestra los parámetros de simulación y el resultado.</p>
<div class="grid grid-cols-1 md:grid-cols-2 gap-6 mt-10">
<a href="/es/servicios/hr-agent/payroll-decision-layer/chemicals/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors"><div class="flex items-center justify-between mb-4"><h3 class="text-h3 font-bold text-white">Química</h3><div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div></div><ul class="space-y-1.5 text-small text-gosign-text-on-dark/70"><li>13 grupos salariales x 17 comunidades autónomas = 221 bases salariales</li><li>Complementos de turno 6-10%, pluses de peligrosidad</li><li>Complemento de futuro 23% (opción triple: dinero/tiempo/previsión)</li><li>Plan de pensiones empresarial, paga extra + vacaciones</li></ul><div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between"><span class="text-h3 font-bold text-gosign-accent-on-dark">88% Zero-Touch</span><span class="text-small text-gosign-accent-on-dark font-semibold">Química en detalle &rarr;</span></div></a>
<a href="/es/servicios/hr-agent/payroll-decision-layer/aviation/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors"><div class="flex items-center justify-between mb-4"><h3 class="text-h3 font-bold text-white">Aviación</h3><div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div></div><ul class="space-y-1.5 text-small text-gosign-text-on-dark/70"><li>3 sindicatos, 14-18 convenios colectivos separados</li><li>EASA FTL: límite 900h, Flight Duty Period</li><li>180+ dietas internacionales por país</li><li>Antigüedad cockpit hasta nivel 23</li></ul><div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between"><span class="text-h3 font-bold text-gosign-accent-on-dark">82% Zero-Touch</span><span class="text-small text-gosign-accent-on-dark font-semibold">Aviación en detalle &rarr;</span></div></a>
<a href="/es/servicios/hr-agent/payroll-decision-layer/financial-services/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors"><div class="flex items-center justify-between mb-4"><h3 class="text-h3 font-bold text-white">Finanzas</h3><div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-white/20"></span></div></div><ul class="space-y-1.5 text-small text-gosign-text-on-dark/70"><li>5 regímenes retributivos en paralelo (convenio a Risk Taker)</li><li>CRD V/CNMV: Bonus-Deferral 40-60% sobre 4-5 años</li><li>Malus/Clawback: 5-7 años de reclamación</li><li>Requisitos BCE: vacaciones obligatorias consecutivas para traders</li></ul><div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between"><span class="text-h3 font-bold text-gosign-accent-on-dark">85% Zero-Touch</span><span class="text-small text-gosign-accent-on-dark font-semibold">Finanzas en detalle &rarr;</span></div></a>
<a href="/es/servicios/hr-agent/payroll-decision-layer/retail/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors"><div class="flex items-center justify-between mb-4"><h3 class="text-h3 font-bold text-white">Comercio</h3><div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-white/20"></span></div></div><ul class="space-y-1.5 text-small text-gosign-text-on-dark/70"><li>17 comunidades autónomas x 6 grupos x 6 niveles = 612 bases salariales</li><li>64% tiempo parcial, contratos a tiempo parcial</li><li>100.000 trabajadores de temporada, 25,7% rotación</li><li>Acumulación de complementos: solo el más alto, nocturnidad aditiva</li></ul><div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between"><span class="text-h3 font-bold text-gosign-accent-on-dark">92% Zero-Touch</span><span class="text-small text-gosign-accent-on-dark font-semibold">Comercio en detalle &rarr;</span></div></a>
</div>
</div>
</section>

<!-- Implementación -->
<section id="implementacion" class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Implementación</p>
<h2 class="text-h1 font-bold text-gosign-dark">Del piloto al sistema en producción.</h2>
<div class="grid grid-cols-1 lg:grid-cols-2 gap-10 mt-10">
<div><h3 class="text-h3 font-bold text-gosign-dark mb-3">Arquitectura técnica</h3><p class="text-body text-gosign-text">El Payroll Decision Layer funciona íntegramente en su infraestructura: su centro de datos, su red, su soberanía. Sin dependencia SaaS, sin fuga de datos, sin telemetría externa. Contenerizado, multi-tenant, listo para desplegar en su Private Cloud o como Managed Deployment en centros de datos de la UE.</p><div class="flex flex-wrap gap-4 mt-3"><a href="/es/servicios/infraestructura/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infraestructura en detalle &rarr;</a><a href="/es/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Arquitectura del Decision Layer &rarr;</a><a href="/es/revista/acta-de-decision-decisiones-ia-impugnables/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">El acta de decisión &rarr;</a><a href="/es/servicios/travel-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Travel Decision Layer &rarr;</a></div></div>
<div><h3 class="text-h3 font-bold text-gosign-dark mb-3">Implementación</h3><p class="text-body text-gosign-text">El Decision Layer no se instala, se configura: sus convenios colectivos, sus reglas de complementos, su ecosistema de sistemas. Los pilotos típicos arrancan en 3 meses con un grupo de personal y un convenio colectivo. Las ampliaciones a otros grupos o sociedades se ejecutan en paralelo al piloto.</p></div>
</div>
<h3 class="text-h3 font-bold text-gosign-dark mt-12 mb-6">Palanca económica</h3>
<div class="grid grid-cols-1 sm:grid-cols-2 gap-6">
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6"><div class="flex items-start gap-4"><svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12l2 2 4-4m5.618-4.016A11.955 11.955 0 0112 2.944a11.955 11.955 0 01-8.618 3.04A12.02 12.02 0 003 9c0 5.591 3.824 10.29 9 11.622 5.176-1.332 9-6.03 9-11.622 0-1.042-.133-2.052-.382-3.016z" /></svg><div><p class="text-body font-semibold text-gosign-dark">Eliminar correcciones antes de que ocurran</p><p class="text-small text-gosign-text-light mt-2">Cada nómina pasa por el mismo reglamento. La tasa de error del 1-8% (APA) surge de la interpretación manual de reglas. El Decision Layer aplica reglas de forma consistente - en todos los convenios, todos los grupos de personal, cada mes igual.</p></div></div></div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6"><div class="flex items-start gap-4"><svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M13 10V3L4 14h7v7l9-11h-7z" /></svg><div><p class="text-body font-semibold text-gosign-dark">Cambio de convenio en horas, no en semanas</p><p class="text-small text-gosign-text-light mt-2">Desplegar nueva tabla salarial, definir periodo de vigencia, recálculo retroactivo automático. Sin actualización manual en múltiples regiones. Sin centros olvidados.</p></div></div></div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6"><div class="flex items-start gap-4"><svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M12 6v6h4.5m4.5 0a9 9 0 11-18 0 9 9 0 0118 0z" /></svg><div><p class="text-body font-semibold text-gosign-dark">82-92% Zero-Touch. Persona solo donde es legalmente necesario.</p><p class="text-small text-gosign-text-light mt-2">El AI Agent puede procesar cada nómina mejor que un técnico de nóminas. Las intervenciones humanas se mantienen donde el Comité de Empresa, el Estatuto de los Trabajadores o el riesgo de discriminación las exigen - no por razones técnicas.</p></div></div></div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6"><div class="flex items-start gap-4"><svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12h6m-6 4h6m2 5H7a2 2 0 01-2-2V5a2 2 0 012-2h5.586a1 1 0 01.707.293l5.414 5.414a1 1 0 01.293.707V19a2 2 0 01-2 2z" /></svg><div><p class="text-body font-semibold text-gosign-dark">La inspección de Hacienda es una exportación, no un proyecto</p><p class="text-small text-gosign-text-light mt-2">Expedientes de decisión sellados por nómina. Qué regla, qué dato de entrada, qué resultado. Semanas de preparación se convierten en minutos.</p></div></div></div>
</div>
</div>
</section>

<!-- Seguridad -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Seguridad</p>
<h2 class="text-h1 font-bold text-gosign-dark">Seguridad enterprise. Desde el día uno.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Los datos retributivos son de los más sensibles de la empresa. El Payroll Decision Layer está diseñado para entornos regulados donde la protección de datos, la preparación para auditoría y la trazabilidad no son extras opcionales.</p>
<div class="mt-10 grid grid-cols-1 sm:grid-cols-3 gap-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">100% infraestructura del cliente</h3><p class="text-small text-gosign-text-light mt-2">El Decision Layer funciona íntegramente en su red. Sin dependencia SaaS, sin fuga de datos, sin telemetría externa. Los datos retributivos no abandonan su red.</p></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">RGPD + LOPDGDD by Design</h3><p class="text-small text-gosign-text-light mt-2">Anonimización en lugar de eliminación. Compatible con plazos de conservación fiscal (6 años) y RGPD Art. 17 + LOPDGDD. Sin contradicción entre derecho fiscal y protección de datos.</p><a href="/es/governance/data-residency/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Residencia de datos en detalle</a></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">Conforme al AI Act</h3><p class="text-small text-gosign-text-light mt-2">Separación arquitectónica clara: el AI Agent clasifica y detecta patrones. El cálculo de salarios, complementos e impuestos se ejecuta de forma determinista mediante reglamentos. Sin caja negra en importes, trazabilidad completa en la clasificación.</p><a href="/es/governance/eu-ai-act/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Preparación EU AI Act</a></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">Audit Trail (append-only)</h3><p class="text-small text-gosign-text-light mt-2">Expedientes de decisión firmados. Hash de entrada más versión de regla genera resultado reproducible. Paquetes de auditoría sellados (JSON + PDF, SHA-256). Inspección disponible en cualquier momento.</p></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">ISO 27001 / PS 951 cert-ready</h3><p class="text-small text-gosign-text-light mt-2">Controls Registry integrado, Evidence Runs automatizados, políticas versionadas. Cumplimiento en operación continua, no documentado a posteriori.</p><a href="/es/governance/cert-ready/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready by Design</a></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">SSO y separación multi-tenant</h3><p class="text-small text-gosign-text-light mt-2">Integración con su Identity Provider existente. Separación de tenants a nivel de base de datos (Row Level Security). Modelo de roles granular y configurable. Sociedades claramente separadas.</p></div>
</div>
</div>
</section>


<!-- Weitere Agent-Lösungen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Más soluciones de agentes</h2>
<p class="text-body-lg text-gosign-text-light mt-4">Los HR Agents son parte de nuestro portfolio de agentes. Para finanzas y otras áreas ofrecemos soluciones especializadas.</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8 max-w-content">
<a href="/es/hr-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR & People Operations</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Todos los HR Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Compatible con comité de empresa.</p>
</a>
<a href="/es/finance-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Finance & Accounting</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Finance AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Procesamiento de documentos, contabilización, amortización, correcciones. Integración SAP/ERP.</p>
</a>
<a href="/es/contacto/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Individual</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Co-Build para su proceso</h3>
<p class="text-body text-gosign-text-light mt-2">Compliance, operaciones, shared services - desarrollamos agentes en modelo co-build.</p>
</a>
</div>
</div>
</section>

<!-- Este agente en el catálogo -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark">¿Cuándo empezar? Priorización y preparación de governance</h2>
<p class="text-body text-gosign-text mt-4">El catálogo de agentes HR muestra puntuaciones, complejidad de gobernanza, clasificación EU AI Act y la tabla completa de microdecisiones para este agente - posicionado en 3 cuadrantes de priorización junto a 47 agentes HR más.</p>
<a href="/es/catalogo-agentes-hr/payroll-processing-agent/" class="inline-flex items-center gap-2 mt-4 text-body font-semibold text-gosign-accent hover:underline">Ver secuenciación y scores &rarr;</a>
</div>
</section>

<!-- Profundización -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Profundización en el Agent Briefing (Revista Gosign)</h2>
<p class="text-body text-gosign-text-light mb-6">Nuestra serie de artículos especializados para responsables que implementan AI Agents en la empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/es/revista/decision-layer-payroll/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors"><p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Finanzas</p><p class="text-body font-semibold text-gosign-dark">Eliminar errores de nómina de forma estructural - Decision Layer para finanzas</p></a>
<a href="/es/revista/comite-empresa-ia-codeterminacion/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors"><p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Codeterminación</p><p class="text-body font-semibold text-gosign-dark">Comité de Empresa e IA - codeterminación como restricción arquitectónica</p></a>
<a href="/es/revista/decision-layer-explicado/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors"><p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Fundamentos</p><p class="text-body font-semibold text-gosign-dark">Decision Layer - ¿Qué es y por qué lo necesita cada AI Agent empresarial?</p></a>
</div>
</div>
</section>

--- AI Infrastructure Engineering ---
> LLM Hosting, pipeline RAG, orquestación y despliegue. Agnóstico de modelos, self-hosted o cloud. Plataforma de producción para AI Agents.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/es/por-que-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Cada decisión rastreable</p>
</div>
</a>
<a href="/es/por-que-gosign/#infraestructura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Su infraestructura</p>
<p class="text-xs text-gosign-text-light">Sin SaaS. Sin vendor lock-in.</p>
</div>
</a>
<a href="/es/por-que-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Sin riesgo de cloud estadounidense</p>
</div>
</a>
</div>
</div>
</div>

<!-- Por qué la infraestructura es el cuello de botella -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Por qué la infraestructura es el cuello de botella</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
La mayoría de empresas que pilotean AI Agents no fracasan por el modelo. Los modelos funcionan. Fracasan por la infraestructura: sin framework de gobernanza, sin Audit Trail, sin aislamiento de inquilinos, sin concepto de despliegue, sin integración con los sistemas existentes.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Un piloto en un portátil no es una arquitectura de producción. Esta página describe las tecnologías y configuraciones concretas que convierten un experimento con un LLM en un sistema operativo.
</p>
<p class="text-body text-gosign-text-light mt-4">
Cómo interactúan arquitectónicamente los componentes de infraestructura se describe en la <a href="/es/governance/reference-architecture/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Arquitectura de Referencia de 7 capas</a>.
</p>
</div>
</div>
</section>

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">eBook gratuito: Infraestructura de IA</p>
<p class="text-body text-gosign-text mb-4">Build, Buy, Hybrid - infraestructura conforme al EU AI Act con B/B/H-Framework y 7-Layer Reference Architecture.</p>
<a href="/es/ebook/ia-infraestructura-manual-gobernanza/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Descargar gratis</a>
</div>

<!-- 1. LLM Hosting -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Cuatro componentes de infraestructura</h2>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">1. LLM Hosting</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
La capa de modelo. Donde tiene lugar la comprensión del lenguaje.
</p>
<p class="text-body-lg text-gosign-text-light mt-4"><strong>Cloud LLMs:</strong></p>
<ul class="mt-2 space-y-2">
<li class="text-body-lg text-gosign-text-light">Azure OpenAI (ChatGPT, Claude) - regiones UE, DPA de Microsoft</li>
<li class="text-body-lg text-gosign-text-light">Amazon Bedrock (Claude, Llama, Mistral) - regiones UE, DPA de AWS</li>
<li class="text-body-lg text-gosign-text-light">Google Vertex AI (Gemini) - regiones UE, DPA de Google</li>
<li class="text-body-lg text-gosign-text-light">Anthropic API (Claude) - con EU Data Processing</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-4"><strong>LLMs Self-Hosted:</strong></p>
<ul class="mt-2 space-y-2">
<li class="text-body-lg text-gosign-text-light">Llama (Meta) - open source, en hardware propio</li>
<li class="text-body-lg text-gosign-text-light">Mistral - open source, empresa europea</li>
<li class="text-body-lg text-gosign-text-light">DeepSeek - open source, eficiente en costes</li>
<li class="text-body-lg text-gosign-text-light"><a href="https://openai.com/open-models/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">gpt-oss</a> (OpenAI) - open weight, Apache 2.0, completamente self-hostable. 120B en una única H100, 20B en 16 GB de hardware de consumo.</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-4"><strong>Frameworks de inferencia para self-hosted:</strong></p>
<ul class="mt-2 space-y-2">
<li class="text-body-lg text-gosign-text-light"><a href="https://ollama.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Ollama</a> - Inicio sencillo, desarrollo local, edge deployment</li>
<li class="text-body-lg text-gosign-text-light"><a href="https://docs.vllm.ai/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">vLLM</a> - Production-grade, optimizado para GPU, alto throughput</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-4"><strong>Híbrido:</strong></p>
<ul class="mt-2 space-y-2">
<li class="text-body-lg text-gosign-text-light">Self-hosted para datos sensibles (RRHH, finanzas)</li>
<li class="text-body-lg text-gosign-text-light">Cloud LLMs para cargas menos críticas (clasificación de documentos)</li>
<li class="text-body-lg text-gosign-text-light">Enrutamiento automático según clasificación de datos</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-4">
La elección del modelo es un equilibrio entre rendimiento, costes, protección de datos y latencia. Asesoramos en la selección e implementamos de forma agnóstica de modelos - un cambio de modelo no altera la lógica de negocio.
</p>
<p class="text-body text-gosign-text-light mt-4">
Profundizar: <a href="/es/revista/modelos-ia-comparacion-2026/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Modelos de IA en comparación</a> · <a href="/es/revista/llm-self-hosting-enterprise/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">LLM Self-Hosting para empresas</a>
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Nuestros ingenieros AI cuentan con certificación Microsoft para Azure AI Services. Las opciones de despliegue incluyen <a href="https://azure.microsoft.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Microsoft Azure</a>, <a href="https://cloud.google.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">GCP</a> e infraestructura completamente autohospedada - la decisión arquitectónica corresponde al cliente, no al proveedor.
</p>
</div>
</div>
</section>

<!-- 2. Pipeline RAG -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h3 class="text-h3 font-bold text-gosign-dark">2. Pipeline RAG</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Retrieval Augmented Generation - cómo los agentes acceden al conocimiento empresarial.
</p>
</div>
<img src="/images/diagrams/rag-pipeline-es.svg" alt="Pipeline RAG: Los documentos se segmentan en chunks, se almacenan como embeddings en el Vector Store, se recuperan semánticamente ante consultas y se pasan al LLM como contexto" class="w-full mt-6" width="1200" height="400" loading="lazy" />
<div class="max-w-narrow mt-6">
<p class="text-body-lg text-gosign-text-light"><strong>Características de calidad:</strong></p>
<ul class="mt-2 space-y-2">
<li class="text-body-lg text-gosign-text-light">Chunking semántico (no por número de página, sino por contenido)</li>
<li class="text-body-lg text-gosign-text-light">Enriquecimiento de metadatos (tipo de documento, versión, ámbito de vigencia)</li>
<li class="text-body-lg text-gosign-text-light">Hybrid Search (búsqueda vectorial + keyword para mayor precisión)</li>
<li class="text-body-lg text-gosign-text-light">Cita de fuente en cada respuesta (documento, página, párrafo)</li>
<li class="text-body-lg text-gosign-text-light">Re-indexación periódica cuando cambian los documentos</li>
</ul>
</div>
</div>
</section>

<!-- 3. Orquestación -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h3 class="text-h3 font-bold text-gosign-dark">3. Orquestación</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
El control de flujo. Cómo colaboran agentes, sistemas y personas.
</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light"><strong><a href="https://trigger.dev" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Trigger.dev</a> o <a href="https://camunda.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Camunda</a>:</strong> Motor de workflow open source. Workflows visuales, integración de APIs, webhooks. Self-hosted, sin vendor lock-in.</li>
<li class="text-body-lg text-gosign-text-light"><strong>API Gateway:</strong> Punto de entrada unificado. Rate Limiting, autenticación, logging, monitoring.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Sistema de Colas:</strong> Procesamiento asíncrono para procesos batch (cierre mensual, importación masiva).</li>
<li class="text-body-lg text-gosign-text-light"><strong>Sistema de Eventos:</strong> Reacción en tiempo real a documentos entrantes, cambios de estado, escalaciones.</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-4">
La orquestación es la diferencia entre "un agente puede hacer algo" y "un agente hace algo de forma fiable en producción".
</p>
<p class="text-body text-gosign-text-light mt-4">
Profundizar: <a href="/es/revista/orquestacion-agentes-plataformas/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Plataformas de orquestación de agentes</a>
</p>
</div>
</div>
</section>

<!-- 4. Despliegue -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h3 class="text-h3 font-bold text-gosign-dark">4. Despliegue</h3>
<p class="text-body-lg text-gosign-text-light mt-4">Donde se ejecuta la infraestructura. Todas las opciones solo en la UE.</p>

<h4 class="text-body-lg font-bold text-gosign-dark mt-6">Azure (UE)</h4>
<ul class="mt-2 space-y-1">
<li class="text-body text-gosign-text-light">Azure Kubernetes Service (AKS) para orquestación de contenedores</li>
<li class="text-body text-gosign-text-light">Azure SQL / PostgreSQL para datos y Audit Trail</li>
<li class="text-body text-gosign-text-light">Azure OpenAI para hosting de LLM</li>
<li class="text-body text-gosign-text-light">Regiones: West Europe, North Europe, Spain Central</li>
</ul>

<h4 class="text-body-lg font-bold text-gosign-dark mt-6">AWS (UE)</h4>
<ul class="mt-2 space-y-1">
<li class="text-body text-gosign-text-light">Amazon EKS para orquestación de contenedores</li>
<li class="text-body text-gosign-text-light">Amazon RDS / Aurora PostgreSQL para datos y Audit Trail</li>
<li class="text-body text-gosign-text-light">Amazon Bedrock para hosting de LLM (Claude, Llama, Mistral)</li>
<li class="text-body text-gosign-text-light">Regiones: eu-central-1 (Francfort), eu-west-1 (Irlanda), eu-south-2 (España)</li>
</ul>

<h4 class="text-body-lg font-bold text-gosign-dark mt-6">GCP (UE)</h4>
<ul class="mt-2 space-y-1">
<li class="text-body text-gosign-text-light">Google Kubernetes Engine (GKE) para orquestación de contenedores</li>
<li class="text-body text-gosign-text-light">Cloud SQL / AlloyDB para datos y Audit Trail</li>
<li class="text-body text-gosign-text-light">Vertex AI para hosting de LLM</li>
<li class="text-body text-gosign-text-light">Regiones: europe-southwest1 (Madrid), europe-west1, europe-west3</li>
</ul>

<h4 class="text-body-lg font-bold text-gosign-dark mt-6">Vercel EU + Supabase EU</h4>
<ul class="mt-2 space-y-1">
<li class="text-body text-gosign-text-light">Vercel para frontend y edge functions en centros de datos UE</li>
<li class="text-body text-gosign-text-light">Supabase para base de datos (PostgreSQL), auth y storage</li>
<li class="text-body text-gosign-text-light">Opción de despliegue ligera en la UE sin infraestructura Kubernetes propia</li>
<li class="text-body text-gosign-text-light">Servicios gestionados con EU Data Residency</li>
</ul>

<h4 class="text-body-lg font-bold text-gosign-dark mt-6">Self-Hosted</h4>
<ul class="mt-2 space-y-1">
<li class="text-body text-gosign-text-light"><a href="https://www.docker.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Docker</a> / <a href="https://kubernetes.io/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Kubernetes</a> en hardware propio</li>
<li class="text-body text-gosign-text-light"><a href="https://www.postgresql.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">PostgreSQL</a> con <a href="https://github.com/pgvector/pgvector" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">pgvector</a> para datos y búsqueda vectorial</li>
<li class="text-body text-gosign-text-light">LLMs open source en GPUs propias</li>
<li class="text-body text-gosign-text-light">Total independencia del Cloud Act</li>
</ul>

<h4 class="text-body-lg font-bold text-gosign-dark mt-6">Híbrido</h4>
<ul class="mt-2 space-y-1">
<li class="text-body text-gosign-text-light">Combinación según clasificación de datos</li>
<li class="text-body text-gosign-text-light">Cargas sensibles en self-hosted, cargas estándar en cloud</li>
<li class="text-body text-gosign-text-light">Orquestación unificada en todos los entornos</li>
</ul>
</div>
</div>
</section>

<!-- Stack tecnológico -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Stack tecnológico</h2>
<div class="mt-8 overflow-x-auto">
<table class="w-full text-left text-small border-collapse">
<thead>
<tr>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Componente</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Tecnología</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Por qué</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Motor de Workflow</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://trigger.dev" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Trigger.dev</a>, <a href="https://camunda.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Camunda</a></td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Open source, self-hosted, sin vendor lock-in</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Base de datos</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://www.postgresql.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">PostgreSQL</a> + <a href="https://github.com/pgvector/pgvector" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">pgvector</a></td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Enterprise-ready, compatible con RLS, búsqueda vectorial integrada</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Backend</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://www.python.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Python</a>, <a href="https://www.typescriptlang.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">TypeScript</a></td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Probados para cargas ML y desarrollo de APIs</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Frontend</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://react.dev/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">React</a> / <a href="https://nextjs.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Next.js</a></td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Para Dashboard, Chat UI, Auditor Portal</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Contenedores</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://www.docker.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Docker</a>, <a href="https://kubernetes.io/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Kubernetes</a></td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Estándar para cloud y self-hosted</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">API</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">REST, <a href="https://graphql.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">GraphQL</a></td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Integración con sistemas existentes</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Auth</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://supabase.com/auth" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Supabase Auth</a> / OIDC</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Compatible con SSO, integrable con proveedores de identidad empresariales</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Monitoring</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://prometheus.io/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Prometheus</a>, <a href="https://grafana.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Grafana</a></td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Open source, self-hosted, dashboards en tiempo real</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Inferencia</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://ollama.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Ollama</a>, <a href="https://docs.vllm.ai/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">vLLM</a></td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Inferencia LLM self-hosted, optimizada para GPU</td></tr>
</tbody>
</table>
</div>
</div>
</div>
</section>

<!-- La gobernanza está integrada -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">La gobernanza está integrada</h2>
<p class="text-body-lg text-gosign-text-light mt-4">La infraestructura incluye Governance by Design:</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light"><strong>Audit Trail</strong> a nivel de infraestructura (no solo de aplicación)</li>
<li class="text-body-lg text-gosign-text-light"><strong>Row-Level Security</strong> a nivel de base de datos - <a href="/es/governance/data-residency/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Data Residency en detalle</a></li>
<li class="text-body-lg text-gosign-text-light"><strong>Cifrado</strong> en reposo y en tránsito</li>
<li class="text-body-lg text-gosign-text-light"><strong>RBAC</strong> en todos los componentes</li>
<li class="text-body-lg text-gosign-text-light"><a href="/es/governance/cert-ready/" class="text-gosign-dark hover:text-gosign-accent-text transition-colors"><strong>Cert-Ready Controls</strong></a> como objetos de datos técnicos</li>
</ul>
<p class="mt-4">
<a href="/es/governance/reference-architecture/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Gobernanza en la arquitectura de 7 capas -></a>
</p>
</div>
</div>
</section>

<!-- Acceso completo al código -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Acceso completo al código fuente</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
La infraestructura funciona en los sistemas del cliente - Azure, GCP, AWS o Self-Hosted. Sin SaaS, sin hosting en Gosign. Acceso completo al código fuente, configuraciones y conjuntos de reglas. Stack open source donde sea posible. Componentes propietarios solo en los propios LLMs - y ahí agnóstico de modelos.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Tras 12-18 meses, usted opera la infraestructura de forma independiente.
</p>
</div>
</div>
</section>

<!-- Profundización -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Profundización en el Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nuestra serie de artículos para ejecutivos que implementan agentes de IA en la empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/es/revista/infraestructura-ia-blueprint-2026/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infraestructura</p>
<p class="text-body font-semibold text-gosign-dark">Enterprise AI-Infraestructura Blueprint 2026</p>
</a>
<a href="/es/revista/hosting-ia-estrategias-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Hosting</p>
<p class="text-body font-semibold text-gosign-dark">Hosting de IA: ¿EU SaaS, centro de datos europeo o Self-Hosted?</p>
</a>
<a href="/es/revista/llm-self-hosting-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Self-Hosting</p>
<p class="text-body font-semibold text-gosign-dark">LLM Self-Hosting empresarial: Azure, GCP, On-Premise</p>
</a>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Para profundizar</h2>
<div class="mt-6 grid gap-6 sm:grid-cols-2">
<div class="border-l-4 border-gosign-dark pl-6 py-4">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Arquitectura</p>
<h3 class="text-h3 font-bold text-gosign-dark">Arquitectura de Referencia de 7 capas</h3>
<p class="text-body text-gosign-text-light mt-2">Cómo interactúan arquitectónicamente los componentes de infraestructura - Presentation, Orchestration, Agent, Decision Layer, Model, Integration, Infrastructure.</p>
<a href="/es/governance/reference-architecture/" class="text-small font-semibold text-gosign-accent-text hover:text-gosign-accent-hover mt-3 inline-block whitespace-nowrap">A la Arquitectura de Referencia -></a>
</div>
<div class="border-l-4 border-gosign-dark pl-6 py-4">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Recurso de conocimiento</p>
<h3 class="text-h3 font-bold text-gosign-dark">Blueprint 2026</h3>
<p class="text-body text-gosign-text-light mt-2">Once artículos sobre las decisiones de infraestructura que importan en 2026: modelos de IA, hosting, RAG, orquestación, costes, EU AI Act.</p>
<div class="mt-3 flex flex-wrap gap-3">
<a href="/es/revista/infraestructura-ia-blueprint-2026/" class="text-small font-semibold text-gosign-accent-text hover:text-gosign-accent-hover whitespace-nowrap">Vista general -></a>
<a href="/es/revista/modelos-ia-comparacion-2026/" class="text-small font-semibold text-gosign-accent-text hover:text-gosign-accent-hover whitespace-nowrap">Modelos AI 2026 -></a>
</div>
</div>
<div class="border-l-4 border-gosign-dark pl-6 py-4">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Datos</p>
<h3 class="text-h3 font-bold text-gosign-dark">Data Residency</h3>
<p class="text-body text-gosign-text-light mt-2">Donde residen los datos, cómo se asegura el aislamiento de inquilinos y qué significa EU Data Residency en la práctica.</p>
<a href="/es/governance/data-residency/" class="text-small font-semibold text-gosign-accent-text hover:text-gosign-accent-hover mt-3 inline-block whitespace-nowrap">Data Residency en detalle -></a>
</div>
<div class="border-l-4 border-gosign-dark pl-6 py-4">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Agentes</p>
<h3 class="text-h3 font-bold text-gosign-dark">AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Document Agents, Workflow Agents, Knowledge Agents - tres tipos de agentes para procesos empresariales.</p>
<a href="/es/servicios/ai-agents/" class="text-small font-semibold text-gosign-accent-text hover:text-gosign-accent-hover mt-3 inline-block whitespace-nowrap">Explorar AI Agents -></a>
</div>
</div>
</div>
</div>
</section>

--- Ingeniería de Software Empresarial desde 2001 ---
> Más de 5.000 proyectos para Airbus, Volkswagen, Shell. 25 años de software empresarial - hoy fundamento de ingeniería para infraestructura de IA.

<!-- 25 Años -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">25 Años de Desarrollo de Software Empresarial</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Gosign desarrolla software para clientes empresariales desde 2001. Más de 5.000 proyectos para <a href="/es/referencias/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Airbus, Volkswagen, Shell y otros</a> - plataformas empresariales complejas y multilingües con requisitos de seguridad, escalabilidad y mantenibilidad.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Este fundamento es la razón por la que Gosign construye <a href="/es/servicios/ai-agents/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">infraestructura de IA</a> hoy. No como una startup que existe desde hace dos años, sino como una empresa con 25 años de experiencia en ingeniería en entornos empresariales.
</p>
</div>
</section>

<!-- Lo Que Construimos Hoy -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Lo Que Construimos Hoy</h2>

<div class="mt-6 grid grid-cols-1 md:grid-cols-2 gap-6 lg:gap-8">
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M13.19 8.688a4.5 4.5 0 0 1 1.242 7.244l-4.5 4.5a4.5 4.5 0 0 1-6.364-6.364l1.757-1.757m9.864-9.864a4.5 4.5 0 0 0-6.364 6.364l4.5 4.5a4.5 4.5 0 0 0 7.244 1.242" /></svg>
<h3 class="text-h3 font-bold text-gosign-dark mt-3">Integraciones Personalizadas</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Conexión de AI Agents con sistemas empresariales existentes. SAP, Sage, SuccessFactors, Workday, Microsoft Graph - vía REST, SOAP, RFC o interfaces propietarias. La integración es el punto donde la mayoría de proyectos de IA fallan. Nosotros lo hemos resuelto miles de veces.
</p>
</article>

<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M14.25 9.75 16.5 12l-2.25 2.25m-4.5 0L7.5 12l2.25-2.25M6 20.25h12A2.25 2.25 0 0 0 20.25 18V6A2.25 2.25 0 0 0 18 3.75H6A2.25 2.25 0 0 0 3.75 6v12A2.25 2.25 0 0 0 6 20.25Z" /></svg>
<h3 class="text-h3 font-bold text-gosign-dark mt-3">Desarrollo de APIs</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Interfaces legibles por máquinas para agentes, dashboards y sistemas de terceros. REST y GraphQL. Autenticación, rate limiting, versionado, documentación.
</p>
</article>

<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="m21 7.5-9-5.25L3 7.5m18 0-9 5.25m9-5.25v9l-9 5.25M3 7.5l9 5.25M3 7.5v9l9 5.25m0-9v9" /></svg>
<h3 class="text-h3 font-bold text-gosign-dark mt-3">Arquitectura de Sistemas</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Diseño de arquitectura para plataformas de AI Agents. Modelo de datos, estrategia de despliegue, concepto de escalado, arquitectura de seguridad.
</p>
</article>

<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 17.25v1.007a3 3 0 0 1-.879 2.122L7.5 21h9l-.621-.621A3 3 0 0 1 15 18.257V17.25m6-12V15a2.25 2.25 0 0 1-2.25 2.25H5.25A2.25 2.25 0 0 1 3 15V5.25m18 0A2.25 2.25 0 0 0 18.75 3H5.25A2.25 2.25 0 0 0 3 5.25m18 0V12a2.25 2.25 0 0 1-2.25 2.25H5.25A2.25 2.25 0 0 1 3 12V5.25" /></svg>
<h3 class="text-h3 font-bold text-gosign-dark mt-3">Plataformas Empresariales</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Plataformas web para usuarios internos: dashboards, portales de auditor, interfaces de chat, herramientas de workflow. Responsivas, accesibles, performantes.
</p>
</article>
</div>
</div>
</section>

<!-- Principios de Ingeniería -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Principios de Ingeniería</h2>
<div class="mt-6 space-y-4">
<p class="text-body-lg text-gosign-text-light">
<strong class="text-gosign-dark">Test-Driven Development (TDD) & Pair Programming continuo:</strong> Cada línea de código se escribe en pair programming. Los tests se escriben antes del código. No como ideal, sino como práctica. Cada función tiene tests. Cada merge requiere tests verdes.
</p>
<p class="text-body-lg text-gosign-text-light">
<strong class="text-gosign-dark">Continuous Integration / Continuous Deployment (CI/CD):</strong> Pipeline de build automatizado, tests automatizados, despliegue automatizado. Cada push se testea. Cada merge se despliega.
</p>
<p class="text-body-lg text-gosign-text-light">
<strong class="text-gosign-dark">Code Review:</strong> Cada merge request es revisado por al menos otro desarrollador. Principio de cuatro ojos para todos los cambios en producción.
</p>
<p class="text-body-lg text-gosign-text-light">
<strong class="text-gosign-dark">Security by Design:</strong> La seguridad no es una capa añadida después. RBAC, cifrado, validación de entrada, encoding de salida - desde el día 1.
</p>
<p class="text-body-lg text-gosign-text-light">
<strong class="text-gosign-dark">Audit Trail:</strong> Cada cambio en configuración, conjuntos de reglas y estado del sistema se documenta. Quién cambió qué cuándo - trazable e inmutable.
</p>
</div>
</div>
</section>

<!-- Stack Tecnológico -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">Stack Tecnológico</h2>
<div class="overflow-x-auto -mx-4 sm:mx-0">
<table class="w-full text-left text-small border-collapse min-w-[36rem]">
<thead>
<tr>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Área</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Tecnologías</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Backend</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://www.python.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Python</a>, <a href="https://www.typescriptlang.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">TypeScript</a>, Node.js</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Frontend</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://react.dev/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">React</a>, <a href="https://nextjs.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Next.js</a></td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Base de datos</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://www.postgresql.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">PostgreSQL</a>, Supabase</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Workflow</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://trigger.dev" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Trigger.dev</a>, <a href="https://n8n.io/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">n8n</a>, <a href="https://camunda.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Camunda</a></td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Contenedores</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://www.docker.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Docker</a>, <a href="https://kubernetes.io/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Kubernetes</a></td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">CI/CD</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://github.com/features/actions" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">GitHub Actions</a>, <a href="https://docs.gitlab.com/ee/ci/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">GitLab CI</a></td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Monitoreo</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://prometheus.io/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Prometheus</a>, <a href="https://grafana.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Grafana</a></td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Auth</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://supabase.com/auth" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Supabase Auth</a>, OIDC</td></tr>
</tbody>
</table>
</div>
<p class="text-body-lg text-gosign-text-light mt-4">
El stack sigue los requisitos del proyecto. Utilizamos tecnologías open-source donde sea posible - por transparencia, independencia y eficiencia de costes.
</p>
</div>
</section>

<!-- De Ingeniería a IA -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">De Ingeniería de Software a Infraestructura de IA</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Los principios de ingeniería que aplican al desarrollo de software empresarial también aplican a la <a href="/es/servicios/infraestructura/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">infraestructura de IA</a>. Un AI Agent en producción necesita la misma disciplina que cualquier otro software empresarial: tests, pipelines de despliegue, monitoreo, Audit Trail, seguridad.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
La diferencia: un AI Agent toma decisiones profesionales que deben ser documentadas y trazables. Esto requiere componentes arquitectónicos adicionales - el <a href="/es/decision-layer/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Decision Layer</a>, Governance by Design, controles <a href="/es/governance/cert-ready/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Cert-Ready</a>. Pero el fundamento es ingeniería de software.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
25 años de ese fundamento es la razón por la que nuestra infraestructura de IA funciona.
</p>
</div>
</section>

<!-- Profundización -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Profundización en el Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nuestra serie de artículos para ejecutivos que implementan agentes de IA en la empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/es/revista/integracion-ia-panorama-it/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Integración</p>
<p class="text-body font-semibold text-gosign-dark">Integracion de IA en el panorama IT: SAP, Workday</p>
</a>
<a href="/es/revista/agentes-ia-enterprise-guia/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Agentes</p>
<p class="text-body font-semibold text-gosign-dark">De chatbots a agentes IA: MCP, A2A y sistemas Multi-Agent</p>
</a>
<a href="/es/revista/infraestructura-ia-blueprint-2026/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infraestructura</p>
<p class="text-body font-semibold text-gosign-dark">Enterprise AI-Infraestructura Blueprint 2026</p>
</a>
</div>
</div>
</section>

--- AI Travel Agent Aviación - Gastos de tripulación ---
> Decision Layer para gastos de viaje de tripulaciones. Procesamiento basado en rotaciones, dietas por convenio colectivo, tarifas variables.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/es/por-que-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Cada decisión rastreable</p>
</div>
</a>
<a href="/es/por-que-gosign/#infraestructura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Su infraestructura</p>
<p class="text-xs text-gosign-text-light">Sin SaaS. Sin vendor lock-in.</p>
</div>
</a>
<a href="/es/por-que-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Sin riesgo de cloud estadounidense</p>
</div>
</a>
</div>
</div>
</div>

<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Travel Decision Layer Sectores">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/es/servicios/travel-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Travel Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/es/servicios/travel-decision-layer/aviacion/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Aviación</a>
<a href="/es/servicios/travel-decision-layer/consultoria/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Consultoría</a>
<a href="/es/servicios/travel-decision-layer/logistica/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Logística</a>
<a href="/es/servicios/travel-decision-layer/ventas/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Ventas</a>
</div>
</div>
</nav>

<!-- Por qué aviación tiene la máxima complejidad -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<!-- Cifras de simulación como introducción visual -->
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">100.000+</span>
<p class="text-small text-gosign-text-light mt-1">Casos/año (simulación)</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">95%</span>
<p class="text-small text-gosign-text-light mt-1">Tasa Zero-Touch</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">10 - 20%</span>
<p class="text-small text-gosign-text-light mt-1">Tasa de IROP (estándar del sector)</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">Máxima complejidad normativa</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">Casos y Zero-Touch: modelo de simulación Gosign. Tasa de IROP: EUROCONTROL / US DOT BTS, 2024.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Lo que clasifica el Agent</p>
<h2 class="text-h1 font-bold text-gosign-dark">Tres grupos de personal, un Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Cockpit, cabina, tierra - cada grupo con su propio convenio colectivo, sus propias dietas, su propia complejidad. Usted conoce la complejidad. Así la resuelve el AI Agent:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Cientos de rotaciones al día</h3>
<p class="text-body text-gosign-text mt-2">Cada rotación genera un hecho fiscal. El AI Agent lee planes de servicio automáticamente, clasifica grupo de personal y tipo de rotación y asigna el convenio colectivo correcto. Con cientos de rotaciones al día, el Agent reconoce cambios de ubicación y límites tarifarios de forma más fiable que cualquier captura manual.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Tres a cinco países por día de servicio</h3>
<p class="text-body text-gosign-text mt-2">Una sola rotación puede tocar varios países en un día de servicio. El AI Agent clasifica la secuencia de países y la duración de estancia. El motor de reglas calcula la dieta correcta por país de forma determinista, incluyendo tarifa completa o reducida según la duración.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Override tarifario por grupo de personal</h3>
<p class="text-body text-gosign-text mt-2">Cockpit, cabina, tierra y técnicos tienen convenios colectivos distintos. El AI Agent clasifica el grupo de personal y selecciona el conjunto de reglas correspondiente. El motor de reglas aplica las dietas del convenio que prevalecen sobre las tasas legales, incluyendo acuerdos de empresa como capa adicional.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Volatilidad IROP en tiempo real</h3>
<p class="text-body text-gosign-text mt-2">Retrasos, desvíos, reposicionamientos. El AI Agent clasifica el tipo de irregularidad (IROP) y recalcula la rotación real frente a la planificada. El motor de reglas ajusta dietas y deducciones fiscales de forma determinista. El Audit Trail documenta tanto el plan original como la ejecución real.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Governance de volumen sin muestreo</h3>
<p class="text-body text-gosign-text mt-2">Miles de empleados generan diariamente casos idénticos. El AI Agent verifica el 100% de los casos contra el mismo motor de reglas. Una dieta incorrecta en 50 rotaciones al día se detecta de inmediato, no en la conciliación trimestral. Cada desviación se documenta automáticamente.</p>
</div>
</div>
</div>
</section>

<!-- Decision Flow -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Una rotación. De 40 a 120 micro-decisiones.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Un miembro de la tripulación vuela una rotación de tres días con layover. El Decision Layer la descompone en pasos de decisión individuales:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Paso</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Decisión</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Decisor</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Fundamento</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Leer rotación del plan de servicio</td><td class="py-3 px-4">Automático</td><td class="py-3 px-4">Importación de datos, sin decisión</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Determinar secuencia de países</td><td class="py-3 px-4">Motor de reglas</td><td class="py-3 px-4">GPS o plan: qué países, qué duración</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Seleccionar dieta por país</td><td class="py-3 px-4">Motor de reglas</td><td class="py-3 px-4">Tarifas específicas por país según normativa</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Verificar prevalencia del convenio colectivo</td><td class="py-3 px-4">Motor de reglas</td><td class="py-3 px-4">Convenio de tripulación prevalece sobre tasas legales</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Calcular deducción por comidas</td><td class="py-3 px-4">Motor de reglas</td><td class="py-3 px-4">Comidas proporcionadas reducen la dieta de forma determinista</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Clasificar IROP</td><td class="py-3 px-4">AI</td><td class="py-3 px-4">Retraso, desvío, reposicionamiento: AI clasifica tipo</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Recalcular impacto de IROP</td><td class="py-3 px-4">Motor de reglas</td><td class="py-3 px-4">Duración o país modificado: dieta recalculada</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">Verificar hotel de layover</td><td class="py-3 px-4">AI + Motor de reglas</td><td class="py-3 px-4">AI extrae datos de hotel, motor de reglas verifica conformidad con política</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Asignar centro de coste</td><td class="py-3 px-4">Motor de reglas</td><td class="py-3 px-4">Rotación a flota, flota a centro de coste</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Generar expediente de auditoría</td><td class="py-3 px-4">Automático</td><td class="py-3 px-4">Expediente de decisión sellado por rotación</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Resultados de simulación -->
<section id="simulation" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulación</p>
<h2 class="text-h1 font-bold text-white">Calculado para volúmenes de aviación</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Hemos configurado el Travel Decision Layer con parámetros realistas de aviación y ejecutado los cálculos. Los resultados muestran lo que cambia a volúmenes enterprise.</p>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Parámetros de simulación</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Tripulantes</td><td class="py-3 px-4">10.000 a 50.000+ (múltiples grupos de personal con convenios colectivos propios)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Convenios colectivos</td><td class="py-3 px-4">2 a 5 en paralelo (por grupo de personal y aerolínea)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Casos/año</td><td class="py-3 px-4">100.000 a 1.000.000+</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Jurisdicciones</td><td class="py-3 px-4">Multi-jurisdicción (estados miembros de la UE, incluida España)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Integración de sistemas</td><td class="py-3 px-4">Planificación de tripulaciones &rarr; Decision Layer &rarr; ERP/Nóminas</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Tasa de IROP</td><td class="py-3 px-4">10 - 20% de todas las rotaciones con desviación (estándar del sector)</td></tr>
</tbody>
</table>
</div>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Antes / Después</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th class="text-left py-3 px-4 font-semibold text-white">Dimensión</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manual</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Coste de procesamiento</td><td class="py-3 px-4">desde EUR 53 (base GBTA)*</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; EUR 9</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Tasa de error</td><td class="py-3 px-4">19% (GBTA)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 0,3%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Tiempo de procesamiento</td><td class="py-3 px-4">5 - 12 días laborables</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Minutos</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Tasa Zero-Touch</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">95%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Preparación para auditoría</td><td class="py-3 px-4">Reconstruida manualmente</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Generada automáticamente</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Cambio de convenio colectivo</td><td class="py-3 px-4">Semanas</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 24h</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Corrección retroactiva</td><td class="py-3 px-4">Sobrescritura manual</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Extorno + ajuste (append-only)</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">* GBTA Foundation 2024: USD 58 por transacción (aprox. EUR 53). Los casos de tripulación con lógica de convenios colectivos, multi-jurisdicción y gestión de IROP están típicamente por encima. Tasa de IROP: EUROCONTROL Annual Report, 2024. Resultados de simulación: modelo de cálculo Gosign.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">En la simulación, el Decision Layer alcanza una tasa Zero-Touch del 95% - independientemente de si se procesan 100.000 o 1.000.000 de casos al año. Solo el 5% requiere atención humana. Para el 95% restante, existe un expediente de decisión completo y listo para auditoría. Las correcciones y cambios de convenio colectivo generan asientos de extorno y ajuste - sin sobrescrituras, historial contable completo.</p>
</div>
</section>

<!-- Referencia de arquitectura -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Arquitectura e implementación</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">El Travel Decision Layer funciona íntegramente en su infraestructura: su centro de datos, su red, su control. Sin dependencia SaaS, sin fuga de datos. Para aviación, esto significa: integración con sistemas de planificación de tripulaciones, procesamiento de datos de rotación en tiempo real, conjuntos de reglas específicos por convenio colectivo para cada grupo de personal y Audit Trail continuo hasta SAP FI/CO. Los proyectos piloto típicos comienzan en 3 meses con un grupo de tripulación y un convenio colectivo.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/es/servicios/travel-decision-layer/#implementation" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Arquitectura, implementación y palancas en detalle &rarr;</a>
<a href="/es/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Arquitectura del Decision Layer &rarr;</a>
<a href="/es/servicios/infraestructura/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infraestructura en detalle &rarr;</a>
<a href="/es/governance/co-determination/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Comité de Empresa y Consulta &rarr;</a>
<a href="/es/governance/cert-ready/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready by Design &rarr;</a>
</div>
</div>
</section>

<!-- Profundización -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Profundización en el Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nuestra serie de artículos para ejecutivos que implementan agentes de IA en la empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/es/revista/decision-layer-explicado/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Fundamentos</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - Qué es y por qué todo agente AI enterprise lo necesita</p>
</a>
<a href="/es/revista/comite-empresa-ia-codeterminacion/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Codeterminación</p>
<p class="text-body font-semibold text-gosign-dark">Comité de Empresa e IA: Derecho de Información y Consulta como Constraint Arquitectónico</p>
</a>
<a href="/es/revista/eu-ai-act-hr/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Regulación</p>
<p class="text-body font-semibold text-gosign-dark">EU AI Act y RRHH: lo que ahora es obligatorio</p>
</a>
</div>
</div>
</section>

<!-- Otros sectores -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Travel Decision Layer en otros sectores</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Cada sector tiene sus propios convenios, estructuras de costes y factores de complejidad. El Decision Layer es el mismo. La configuración es sectorial.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/es/servicios/travel-decision-layer/consultoria/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Consultoría</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">Split de clientes, multi-centro de costes, política</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">85% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">En detalle &rarr;</span>
</div>
</a>
<a href="/es/servicios/travel-decision-layer/logistica/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Logística</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">GPS, Paquete de Movilidad UE, Zero-Touch conductores</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">95% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">En detalle &rarr;</span>
</div>
</a>
<a href="/es/servicios/travel-decision-layer/ventas/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Ventas</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">500 comerciales, integración CRM, representación</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">90% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">En detalle &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- AI Travel Agent Consultoría - Gastos de viaje ---
> Decision Layer para gastos de viaje de consultoría. Split tres vías fiscal/cliente/interno, semanas multi-cliente, centros de coste.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/es/por-que-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Cada decisión rastreable</p>
</div>
</a>
<a href="/es/por-que-gosign/#infraestructura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Su infraestructura</p>
<p class="text-xs text-gosign-text-light">Sin SaaS. Sin vendor lock-in.</p>
</div>
</a>
<a href="/es/por-que-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Sin riesgo de cloud estadounidense</p>
</div>
</a>
</div>
</div>
</div>

<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Travel Decision Layer Sectores">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/es/servicios/travel-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Travel Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/es/servicios/travel-decision-layer/aviacion/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Aviación</a>
<a href="/es/servicios/travel-decision-layer/consultoria/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Consultoría</a>
<a href="/es/servicios/travel-decision-layer/logistica/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Logística</a>
<a href="/es/servicios/travel-decision-layer/ventas/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Ventas</a>
</div>
</div>
</nav>

<!-- Por qué consultoría es complejo -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<!-- Indicadores de simulación como introducción visual -->
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">50.000+</span>
<p class="text-small text-gosign-text-light mt-1">Casos/año (simulación)</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">85%</span>
<p class="text-small text-gosign-text-light mt-1">Tasa Zero-Touch</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">3 vías</span>
<p class="text-small text-gosign-text-light mt-1">Split de costes (fiscal/cliente/interno)</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-border"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">Alta complejidad normativa</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">Casos y Zero-Touch: modelo de simulación Gosign. Benchmarks del sector: GBTA Foundation, 2015.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Lo que clasifica el Agent</p>
<h2 class="text-h1 font-bold text-gosign-dark">Tres splits, un Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Fiscal, cliente, interno - cada viaje de consultoría tiene tres perspectivas de coste simultáneas. Usted conoce la complejidad. Así la resuelve el AI Agent:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Triple split por transacción</h3>
<p class="text-body text-gosign-text mt-2">Cada gasto tiene tres perspectivas: fiscal, cliente e interna. El AI Agent clasifica las tres simultáneamente por transacción. El motor de reglas calcula las asignaciones de forma determinista: deducible o no, refacturable o no, centro de coste o overhead.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Semanas multi-cliente divididas automáticamente</h3>
<p class="text-body text-gosign-text mt-2">Un consultor visita tres clientes en una semana. El AI Agent clasifica la asignación por día y cliente a partir de datos de calendario y CRM. El motor de reglas divide hotel, dietas y transporte proporcionalmente. Cada división queda documentada en el Audit Trail.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Conflicto de políticas resuelto automáticamente</h3>
<p class="text-body text-gosign-text mt-2">Políticas internas y presupuestos del cliente colisionan. El AI Agent identifica el conflicto y clasifica qué política aplica. El motor de reglas ejecuta la regla más restrictiva de forma determinista y documenta qué política se aplicó y por qué.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Gastos de representación por jurisdicción</h3>
<p class="text-body text-gosign-text mt-2">Cenas de negocios con clientes en distintos países. El AI Agent clasifica tipo de gasto, jurisdicción y número de participantes. El motor de reglas aplica la tasa de deducción correcta por país de forma determinista: España según IRPF, Alemania 70%, Austria 50%.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Facturación a clientes documentada automáticamente</h3>
<p class="text-body text-gosign-text mt-2">200 consultores, 4 viajes al mes cada uno. El AI Agent genera la base de facturación por cliente automáticamente. El motor de reglas verifica cada asignación contra las condiciones contractuales. Cada importe refacturable es trazable hasta la transacción original.</p>
</div>
</div>
</div>
</section>

<!-- Decision Flow -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Una semana de consultoría. 20 a 60 micro-decisiones.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Un consultor visita tres clientes en una semana con cenas de negocios y hoteles cambiantes. El Decision Layer descompone esa semana en pasos de decisión individuales:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Paso</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Decisión</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Decisor</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Justificación</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Asignar viaje al proyecto de cliente</td><td class="py-3 px-4">Motor de reglas</td><td class="py-3 px-4">Integración con calendario o CRM</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Determinar dieta</td><td class="py-3 px-4">Motor de reglas</td><td class="py-3 px-4">Tarifa específica por país según Reglamento IRPF</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Dividir costes de hotel: refacturable vs. interno</td><td class="py-3 px-4">Motor de reglas</td><td class="py-3 px-4">Condiciones del contrato con el cliente determinan la división</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Verificar política de viaje del cliente</td><td class="py-3 px-4">Motor de reglas</td><td class="py-3 px-4">Solo-turista del cliente vs. primera clase interna</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Aplicar política más restrictiva</td><td class="py-3 px-4">Motor de reglas</td><td class="py-3 px-4">La más restrictiva prevalece</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Clasificación fiscal</td><td class="py-3 px-4">Motor de reglas</td><td class="py-3 px-4">Deducible, parcialmente deducible, representación</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Dividir día multi-cliente</td><td class="py-3 px-4">AI + Motor de reglas</td><td class="py-3 px-4">AI determina asignación temporal, reglas aplican división de costes</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">Generar base de facturación al cliente</td><td class="py-3 px-4">Automático</td><td class="py-3 px-4">Documentación de gastos de viaje lista para auditoría por cliente</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Clasificar gastos de representación</td><td class="py-3 px-4">AI + Motor de reglas</td><td class="py-3 px-4">AI identifica tipo de comprobante, motor de reglas aplica tasas de deducción por jurisdicción</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Generar expediente de auditoría</td><td class="py-3 px-4">Automático</td><td class="py-3 px-4">Expediente de decisiones sellado por semana de consultoría</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Resultado de simulación -->
<section id="simulation" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulación</p>
<h2 class="text-h1 font-bold text-white">Calculado para volúmenes de consultoría</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Hemos configurado el Travel Decision Layer con parámetros realistas de consultoría y lo hemos calculado. Los resultados muestran lo que cambia a volúmenes Enterprise.</p>

<!-- Tabla de parámetros -->
<h3 class="text-h3 font-bold text-white mt-10 mb-4">Parámetros de simulación</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Consultores</td><td class="py-3 px-4">100 a 500+ (con reglas de política específicas por cliente)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Contratos de clientes</td><td class="py-3 px-4">10 a 50+ en paralelo (cada uno con sus políticas de viaje)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Casos/año</td><td class="py-3 px-4">50.000 a 250.000+</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Jurisdicciones</td><td class="py-3 px-4">Multi-jurisdicción (ES, DE, AT, CH, otros países UE, LATAM)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Integración de sistemas</td><td class="py-3 px-4">CRM/control horario &rarr; Decision Layer &rarr; ERP/Nóminas</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Proporción de representación</td><td class="py-3 px-4">15 - 25% de todos los casos contienen comprobantes de representación</td></tr>
</tbody>
</table>
</div>

<!-- Comparación de resultados -->
<h3 class="text-h3 font-bold text-white mt-10 mb-4">Antes / Después</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th class="text-left py-3 px-4 font-semibold text-white">Dimensión</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manual</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Coste de procesamiento</td><td class="py-3 px-4">desde EUR 53 (base GBTA)*</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; EUR 9</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Tasa de error</td><td class="py-3 px-4">19% (GBTA)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 0,3%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Tiempo de procesamiento</td><td class="py-3 px-4">5 - 12 días laborables</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Minutos</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Tasa Zero-Touch</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">85%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Preparación para auditoría</td><td class="py-3 px-4">Reconstruida manualmente</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Generada automáticamente</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Precisión del split</td><td class="py-3 px-4">Estimada manualmente</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Calculada determinísticamente</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Facturación a cliente</td><td class="py-3 px-4">Asignada manualmente</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Documentada automáticamente</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">* GBTA Foundation 2024: USD 58 por transacción (aprox. EUR 53). Los casos de consultoría con split tres vías y lógica multi-cliente son típicamente superiores en el sector. Resultados de simulación: modelo de cálculo Gosign.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">En la simulación, el Decision Layer alcanza una tasa Zero-Touch del 85% - en casos estándar con asignación de cliente unívoca. El 15% restante corresponde a días multi-cliente y casos especiales que requieren evaluación humana. Para todos los casos existe un expediente de decisiones completo y listo para auditoría.</p>
</div>
</section>

<!-- Referencia de arquitectura -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Arquitectura e implementación</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">El Travel Decision Layer funciona completamente en su infraestructura: su centro de datos, su red, su control. Sin dependencia SaaS, sin fugas de datos. Para configuraciones de consultoría, esto significa: capacidad multi-cliente con conjuntos de reglas de políticas separados, integración con sistemas de gestión de proyectos y control horario, y división automática de tres vías. Los proyectos piloto típicos comienzan en 3 meses con un pool de clientes.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/es/servicios/travel-decision-layer/#implementation" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Arquitectura, implementación y palancas en detalle &rarr;</a>
<a href="/es/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Arquitectura del Decision Layer &rarr;</a>
<a href="/es/servicios/infraestructura/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infraestructura en detalle &rarr;</a>
<a href="/es/governance/co-determination/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Codecisión &amp; Comité de Empresa &rarr;</a>
<a href="/es/governance/cert-ready/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready by Design &rarr;</a>
</div>
</div>
</section>

<!-- Profundización -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Profundización en el Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nuestra serie de artículos para ejecutivos que implementan agentes de IA en la empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/es/revista/decision-layer-explicado/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Fundamentos</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - Qué es y por qué todo agente AI enterprise lo necesita</p>
</a>
<a href="/es/revista/agent-governance-hr/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Gobernanza</p>
<p class="text-body font-semibold text-gosign-dark">Agent Governance en RRHH - Por qué el CHRO debe liderar</p>
</a>
<a href="/es/revista/cert-ready-by-design/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Auditoría</p>
<p class="text-body font-semibold text-gosign-dark">Cert-Ready by Design: IA preparada para auditoría</p>
</a>
</div>
</div>
</section>

<!-- Otros sectores -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Travel Decision Layer en otros sectores</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Cada sector tiene sus propios convenios, estructuras de costes y factores de complejidad. El Decision Layer es el mismo. La configuración es sectorial.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/es/servicios/travel-decision-layer/aviacion/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Aviación</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">Tripulación, convenios colectivos, IROP</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">95% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">En detalle &rarr;</span>
</div>
</a>
<a href="/es/servicios/travel-decision-layer/logistica/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Logística</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">GPS, Paquete de Movilidad UE, Zero-Touch conductores</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">95% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">En detalle &rarr;</span>
</div>
</a>
<a href="/es/servicios/travel-decision-layer/ventas/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Ventas</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">500 comerciales, integración CRM, representación</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">90% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">En detalle &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- AI Travel Agent Logística - Costes de transporte ---
> Decision Layer para gastos de viaje logísticos. Detección de países por GPS, cumplimiento del Paquete de Movilidad UE, modo Zero-Touch.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/es/por-que-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Cada decisión rastreable</p>
</div>
</a>
<a href="/es/por-que-gosign/#infraestructura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Su infraestructura</p>
<p class="text-xs text-gosign-text-light">Sin SaaS. Sin vendor lock-in.</p>
</div>
</a>
<a href="/es/por-que-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Sin riesgo de cloud estadounidense</p>
</div>
</a>
</div>
</div>
</div>

<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Travel Decision Layer Sectores">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/es/servicios/travel-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Travel Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/es/servicios/travel-decision-layer/aviacion/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Aviación</a>
<a href="/es/servicios/travel-decision-layer/consultoria/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Consultoría</a>
<a href="/es/servicios/travel-decision-layer/logistica/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Logística</a>
<a href="/es/servicios/travel-decision-layer/ventas/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Ventas</a>
</div>
</div>
</nav>

<!-- Por qué logística es único -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<!-- Indicadores clave como introducción visual -->
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">500.000+</span>
<p class="text-small text-gosign-text-light mt-1">Operaciones/año (simulación)</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">95%</span>
<p class="text-small text-gosign-text-light mt-1">Tasa Zero-Touch</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">30+</span>
<p class="text-small text-gosign-text-light mt-1">Jurisdicciones EU/EFTA</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-border"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">Alta complejidad normativa</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">Operaciones y Zero-Touch: modelo de simulación Gosign. Jurisdicciones: cobertura EU/EFTA. Paquete de Movilidad UE: Directiva 2020/1057.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Lo que clasifica el Agent</p>
<h2 class="text-h1 font-bold text-gosign-dark">30+ jurisdicciones, un Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Trayectos transfronterizos, Paquete de Movilidad UE, flotas mixtas - usted conoce la complejidad. Así la resuelve el AI Agent:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Asignación de país basada en GPS</h3>
<p class="text-body text-gosign-text mt-2">Los conductores cruzan fronteras varias veces al día. El AI Agent lee datos GPS de sistemas telemáticos y clasifica la secuencia de países y la duración de estancia automáticamente. El motor de reglas calcula las dietas por país de forma determinista basándose en la ubicación real, no en formularios.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Paquete de Movilidad UE documentado automáticamente</h3>
<p class="text-body text-gosign-text mt-2">La Directiva 2020/1057 exige documentación de desplazamiento para trayectos transfronterizos. El AI Agent clasifica país de operación y duración a partir de datos GPS. El motor de reglas genera la base de datos para los equipos de compliance de forma determinista, sin carga adicional para los conductores.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Consistencia en toda la flota</h3>
<p class="text-body text-gosign-text mt-2">500 camiones cruzan las mismas fronteras a diario. El AI Agent aplica las mismas reglas a rutas idénticas y elimina la variación dependiente de la persona. El motor de reglas calcula dietas idénticas para trayectos idénticos. Cero variación, cero riesgo de inspección por inconsistencia.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Modo zero-touch para conductores</h3>
<p class="text-body text-gosign-text mt-2">La tarea del conductor es conducir. El AI Agent opera en modo Zero-Touch para rutas estándar: datos GPS de entrada, clasificación automática, exportación a nómina lista. El motor de reglas calcula dietas sin una sola entrada manual. Consultas solo para excepciones reales.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Precisión al minuto en cruces fronterizos</h3>
<p class="text-body text-gosign-text mt-2">Un camión cruza la frontera a las 23:45, la dieta cambia a medianoche. El AI Agent clasifica el cruce fronterizo con precisión al minuto a partir de datos GPS. El motor de reglas calcula la asignación proporcional por país de forma determinista. Tres países en un día de servicio: trivial para el Agent, imposible en captura manual.</p>
</div>
</div>
</div>
</section>

<!-- Decision Flow -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Una ruta de conductor. 15 a 40 micro-decisiones.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Un conductor realiza una ruta de tres países con pernocta. El Decision Layer descompone esta ruta en pasos de decisión individuales:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Paso</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Decisión</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Decisor</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Justificación</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Leer track GPS de telemática</td><td class="py-3 px-4">Automático</td><td class="py-3 px-4">Importación de datos, sin decisión</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Determinar secuencia de países y duración</td><td class="py-3 px-4">Motor de reglas</td><td class="py-3 px-4">Coordenadas GPS mapeadas a jurisdicciones</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Seleccionar dieta por país</td><td class="py-3 px-4">Motor de reglas</td><td class="py-3 px-4">Dietas exentas según Reglamento IRPF</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Calcular cruce fronterizo a medianoche</td><td class="py-3 px-4">Motor de reglas</td><td class="py-3 px-4">Cálculo proporcional en cruce fronterizo a medianoche</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Verificar umbral de desplazamiento de larga duración</td><td class="py-3 px-4">Motor de reglas</td><td class="py-3 px-4">Umbrales basados en duración por jurisdicción</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Generar datos del Paquete de Movilidad UE</td><td class="py-3 px-4">Automático</td><td class="py-3 px-4">Documentación de desplazamiento como base de datos</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Asignar centro de coste de flota</td><td class="py-3 px-4">Motor de reglas</td><td class="py-3 px-4">Vehículo a flota, flota a centro de coste</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">Generar exportación a nómina</td><td class="py-3 px-4">Automático</td><td class="py-3 px-4">Datos de dietas listos para contabilización</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Verificar cumplimiento de tiempo de descanso</td><td class="py-3 px-4">Motor de reglas</td><td class="py-3 px-4">Tiempos de conducción y descanso contra Reglamento UE 561/2006</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Generar expediente de auditoría</td><td class="py-3 px-4">Automático</td><td class="py-3 px-4">Expediente de decisiones sellado por ruta de conductor</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Resultado de simulación -->
<section id="simulation" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulación</p>
<h2 class="text-h1 font-bold text-white">Calculado para volúmenes logísticos</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Hemos configurado el Travel Decision Layer con parámetros logísticos realistas y calculado los resultados. Los datos muestran qué cambia con tamaños de flota Enterprise.</p>

<!-- Tabla de parámetros -->
<h3 class="text-h3 font-bold text-white mt-10 mb-4">Parámetros de simulación</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Flota</td><td class="py-3 px-4">200 a 2.000+ vehículos (propios y subcontratados)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Conductores</td><td class="py-3 px-4">300 a 3.000+ (con diferentes modelos contractuales)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Operaciones/año</td><td class="py-3 px-4">500.000 a 2.000.000+</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Jurisdicciones</td><td class="py-3 px-4">30+ jurisdicciones EU/EFTA</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Integración sistémica</td><td class="py-3 px-4">Telemática &rarr; Decision Layer &rarr; ERP/Nómina</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Cruces fronterizos/día</td><td class="py-3 px-4">500 a 5.000+ (según tamaño de flota)</td></tr>
</tbody>
</table>
</div>

<!-- Comparación de resultados -->
<h3 class="text-h3 font-bold text-white mt-10 mb-4">Antes / Después</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th class="text-left py-3 px-4 font-semibold text-white">Dimensión</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manual</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Coste de procesamiento</td><td class="py-3 px-4">desde EUR 53 (base GBTA)*</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; EUR 5</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Tasa de error</td><td class="py-3 px-4">19% (GBTA)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 0,1%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Tiempo de tramitación</td><td class="py-3 px-4">5 - 12 días laborables</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Minutos</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Tasa Zero-Touch</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">95%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Preparación para auditoría</td><td class="py-3 px-4">Reconstruido manualmente</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Generado automáticamente</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Datos Paquete de Movilidad UE</td><td class="py-3 px-4">Capturado manualmente</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Generado automáticamente</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Consultas de conductores</td><td class="py-3 px-4">3 - 5 por semana</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 0,1 por semana</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">* GBTA Foundation 2024: USD 58 por transacción (aprox. EUR 53). Las operaciones logísticas con detección de país por GPS son significativamente más económicas en modo Zero-Touch. Paquete de Movilidad UE: Directiva 2020/1057. Resultados de simulación: modelo de cálculo Gosign.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">En la simulación, el Decision Layer alcanza una tasa Zero-Touch del 95% - en rutas estándar con cobertura GPS. El 5% restante corresponde a lagunas de GPS, rutas nuevas y casos especiales. Para todos los casos se dispone de un expediente de decisiones completo y listo para auditoría. Los conductores no necesitan rellenar formularios.</p>
</div>
</section>

<!-- Referencia de arquitectura -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Arquitectura e implementación</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">El Travel Decision Layer funciona íntegramente en su infraestructura: su centro de datos, su red, su control. Sin dependencia de SaaS, sin fuga de datos. Para configuraciones logísticas, esto significa: interfaces telemáticas para importación de datos GPS, procesamiento de cruces fronterizos en tiempo real y cálculo de dietas a nivel de flota en más de 30 jurisdicciones EU/EFTA. Los proyectos piloto típicos comienzan en 3 meses con un grupo de flota y las rutas más transitadas.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/es/servicios/travel-decision-layer/#implementation" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Arquitectura, implementación y palancas en detalle &rarr;</a>
<a href="/es/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Arquitectura Decision Layer &rarr;</a>
<a href="/es/servicios/infraestructura/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infraestructura en detalle &rarr;</a>
<a href="/es/governance/co-determination/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Codeterminación &amp; Comité de Empresa &rarr;</a>
<a href="/es/governance/cert-ready/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready by Design &rarr;</a>
</div>
</div>
</section>

<!-- Profundización -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Profundización en el Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nuestra serie de artículos para ejecutivos que implementan agentes de IA en la empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/es/revista/decision-layer-explicado/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Fundamentos</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - Qué es y por qué todo agente AI enterprise lo necesita</p>
</a>
<a href="/es/revista/comite-empresa-ia-codeterminacion/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Codeterminación</p>
<p class="text-body font-semibold text-gosign-dark">Comité de Empresa e IA: Derecho de Información y Consulta como Constraint Arquitectónico</p>
</a>
<a href="/es/revista/cert-ready-by-design/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Auditoría</p>
<p class="text-body font-semibold text-gosign-dark">Cert-Ready by Design: IA preparada para auditoría</p>
</a>
</div>
</div>
</section>

<!-- Otros sectores -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Travel Decision Layer en otros sectores</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Cada sector tiene sus propios convenios, estructuras de costes y factores de complejidad. El Decision Layer es el mismo. La configuración es sectorial.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/es/servicios/travel-decision-layer/aviacion/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Aviación</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">Tripulación, convenios colectivos, IROP</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">95% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">En detalle &rarr;</span>
</div>
</a>
<a href="/es/servicios/travel-decision-layer/consultoria/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Consultoría</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">Split de clientes, multi-centro de costes, política</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">85% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">En detalle &rarr;</span>
</div>
</a>
<a href="/es/servicios/travel-decision-layer/ventas/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Ventas</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">500 comerciales, integración CRM, representación</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">90% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">En detalle &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- AI Travel Agent Ventas - Fuerza comercial ---
> Decision Layer para gastos de viaje comerciales. Integración CRM, cumplimiento de políticas en 10.000+ casos/mes, liquidación semanal.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/es/por-que-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Cada decisión rastreable</p>
</div>
</a>
<a href="/es/por-que-gosign/#infraestructura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Su infraestructura</p>
<p class="text-xs text-gosign-text-light">Sin SaaS. Sin vendor lock-in.</p>
</div>
</a>
<a href="/es/por-que-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Sin riesgo de cloud estadounidense</p>
</div>
</a>
</div>
</div>
</div>

<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Travel Decision Layer Sectores">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/es/servicios/travel-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Travel Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/es/servicios/travel-decision-layer/aviacion/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Aviación</a>
<a href="/es/servicios/travel-decision-layer/consultoria/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Consultoría</a>
<a href="/es/servicios/travel-decision-layer/logistica/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Logística</a>
<a href="/es/servicios/travel-decision-layer/ventas/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Ventas</a>
</div>
</div>
</nav>

<!-- Por qué el volumen de ventas necesita governance -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<!-- Indicadores clave como introducción visual -->
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">120.000+</span>
<p class="text-small text-gosign-text-light mt-1">Casos/año (simulación)</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">90%</span>
<p class="text-small text-gosign-text-light mt-1">Tasa Zero-Touch</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">100%</span>
<p class="text-small text-gosign-text-light mt-1">Verificación de políticas (en vez de muestreo)</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-border"></span><span class="w-4 h-2 rounded-sm bg-gosign-border"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">Complejidad normativa media, alto volumen</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">Casos y Zero-Touch: modelo de simulación Gosign. Verificación de políticas: el Decision Layer verifica el 100% de los casos. Benchmarks sectoriales: GBTA Foundation, 2015.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Lo que clasifica el Agent</p>
<h2 class="text-h1 font-bold text-gosign-dark">10.000 transacciones/mes, un Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">500 comerciales, 20 liquidaciones al mes cada uno. Usted conoce el volumen. Así lo gestiona el AI Agent:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">100% control de política en vez de 5% muestreo</h3>
<p class="text-body text-gosign-text mt-2">500 comerciales, 20 casos al mes cada uno. El AI Agent verifica cada transacción contra el conjunto de reglas de política vigente. El motor de reglas aplica los límites de forma determinista. No 5% muestreo, sino 100% verificación. Cada infracción se detecta en el momento, no en la auditoría trimestral.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Vinculación CRM automática</h3>
<p class="text-body text-gosign-text mt-2">Cada visita a un cliente tiene un propósito de negocio. El AI Agent vincula datos CRM con gastos de viaje automáticamente: qué cliente, qué oportunidad, qué asignación de ingresos. El motor de reglas calcula la asignación de centro de costes de forma determinista. Sin entrada manual, sin propósito de negocio ausente.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Liquidación semanal en vez de transacciones individuales</h3>
<p class="text-body text-gosign-text mt-2">Los comerciales prefieren una liquidación semanal. El AI Agent agrupa todos los viajes de una semana, clasifica cada transacción y genera una liquidación semanal única por empleado. El motor de reglas calcula dietas y kilometraje de forma determinista. De 20 transacciones individuales a 1 liquidación semanal.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Gastos de representación por jurisdicción</h3>
<p class="text-body text-gosign-text mt-2">Cenas de negocios con clientes en distintos países. El AI Agent clasifica tipo de gasto, jurisdicción, importe y número de participantes. El motor de reglas aplica la tasa de deducción correcta por país de forma determinista: España según IRPF, Alemania 70%, Austria 50%. El humano permanece donde el evento mixto de representación lo exige.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Cierre trimestral en minutos</h3>
<p class="text-body text-gosign-text mt-2">10.000 transacciones al mes, cada una con expediente de decisión completo. El AI Agent genera exportaciones a ERP listas para contabilizar, informes de compliance por región y expedientes de auditoría por caso. Lo que antes requería días de reconciliación manual, el Agent lo cierra en minutos.</p>
</div>
</div>
</div>
</section>

<!-- Decision Flow -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Una semana de ventas. De 30 a 80 micro-decisiones.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Un comercial visita cinco clientes en una semana con estancias en hotel y comidas de negocios. El Decision Layer descompone esta semana en pasos de decisión individuales:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Paso</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Decisión</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Decisor</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Justificación</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Vincular viaje con oportunidad CRM</td><td class="py-3 px-4">Motor de reglas</td><td class="py-3 px-4">Cotejo de calendario + datos CRM</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Determinar dieta</td><td class="py-3 px-4">Motor de reglas</td><td class="py-3 px-4">Basado en país y duración</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Calcular kilometraje</td><td class="py-3 px-4">Motor de reglas</td><td class="py-3 px-4">Distancia, tipo de vehículo, tarifa</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Verificar política de representación</td><td class="py-3 px-4">Motor de reglas</td><td class="py-3 px-4">Importe, asistentes, propósito</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Verificar política de hotel</td><td class="py-3 px-4">Motor de reglas</td><td class="py-3 px-4">Límite de precio por categoría de ciudad</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Agrupar en liquidación semanal</td><td class="py-3 px-4">Automático</td><td class="py-3 px-4">Todos los viajes de una semana agregados</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Asignar centro de coste y oportunidad</td><td class="py-3 px-4">Motor de reglas</td><td class="py-3 px-4">Cliente, proyecto, asignación de ingresos</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">Generar exportación a nómina</td><td class="py-3 px-4">Automático</td><td class="py-3 px-4">Liquidación semanal como asiento contable</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Clasificar gastos de representación</td><td class="py-3 px-4">AI + Motor de reglas</td><td class="py-3 px-4">AI reconoce tipo de justificante y asistentes, motor de reglas aplica cuotas de deducción</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Generar expediente de auditoría</td><td class="py-3 px-4">Automático</td><td class="py-3 px-4">Expediente de decisiones sellado por semana de ventas</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Resultados de la simulación -->
<section id="simulation" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulación</p>
<h2 class="text-h1 font-bold text-white">Calculado para volúmenes de ventas</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Hemos configurado el Travel Decision Layer con parámetros realistas de ventas y calculado los resultados. Los datos muestran lo que cambia con volúmenes Enterprise de fuerza de ventas.</p>

<!-- Tabla de parámetros -->
<h3 class="text-h3 font-bold text-white mt-10 mb-4">Parámetros de simulación</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Comerciales</td><td class="py-3 px-4">200 a 2.000+ (por región y jerarquía)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Casos/mes</td><td class="py-3 px-4">10.000 a 50.000+</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Jurisdicciones</td><td class="py-3 px-4">Multi-jurisdicción (ES, UE, LATAM)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Integración de sistemas</td><td class="py-3 px-4">CRM &rarr; Decision Layer &rarr; ERP/Nómina</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Cuota de representación</td><td class="py-3 px-4">20 - 30% de todos los casos contienen justificantes de representación</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Políticas</td><td class="py-3 px-4">3 - 10 paralelas (por región, jerarquía, clase de cliente)</td></tr>
</tbody>
</table>
</div>

<!-- Comparación de resultados -->
<h3 class="text-h3 font-bold text-white mt-10 mb-4">Antes / Después</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th class="text-left py-3 px-4 font-semibold text-white">Dimensión</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manual</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Coste de procesamiento</td><td class="py-3 px-4">desde EUR 53 (base GBTA)*</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; EUR 7</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Tasa de error</td><td class="py-3 px-4">19% (GBTA)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 0,5%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Tiempo de procesamiento</td><td class="py-3 px-4">5 - 12 días laborables</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Minutos</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Tasa Zero-Touch</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">90%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Preparación para auditoría</td><td class="py-3 px-4">Reconstruida manualmente</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Generada automáticamente</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Verificación de políticas</td><td class="py-3 px-4">5 - 10% (muestreo)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">100%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Liquidación semanal</td><td class="py-3 px-4">Compilada manualmente</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Agregada automáticamente</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">* GBTA Foundation 2024: USD 58 por transacción (aprox. EUR 53). Los casos de ventas con integración CRM y agrupación semanal son significativamente más económicos en modo Zero-Touch. Resultados de la simulación: modelo de cálculo Gosign.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">En la simulación, el Decision Layer alcanza una tasa Zero-Touch del 90% - en casos estándar con vinculación CRM inequívoca. El 10% restante corresponde a casos especiales de representación y entradas CRM faltantes que requieren juicio humano. Para todos los casos existe un expediente de decisiones completo y listo para auditoría. Las liquidaciones semanales sustituyen el ciclo de liquidación individual.</p>
</div>
</section>

<!-- Referencia de arquitectura -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Arquitectura e implementación</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">El Travel Decision Layer funciona completamente en su infraestructura: su centro de datos, su red, su soberanía. Sin dependencia SaaS, sin fuga de datos. Para configuraciones de ventas, esto significa: interfaces CRM para vinculación automática viaje-cliente, procesamiento en volumen de más de 10.000 transacciones al mes y lógica de liquidación semanal. Los proyectos piloto típicos comienzan en 3 meses con una región de ventas.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/es/servicios/travel-decision-layer/#implementation" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Arquitectura, implementación y palancas en detalle &rarr;</a>
<a href="/es/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Arquitectura del Decision Layer &rarr;</a>
<a href="/es/servicios/infraestructura/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infraestructura en detalle &rarr;</a>
<a href="/es/governance/co-determination/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Codeterminación &amp; Comité de Empresa &rarr;</a>
<a href="/es/governance/cert-ready/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready by Design &rarr;</a>
</div>
</div>
</section>

<!-- Profundización -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Profundización en el Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nuestra serie de artículos para ejecutivos que implementan agentes de IA en la empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/es/revista/decision-layer-explicado/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Fundamentos</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - Qué es y por qué todo agente AI enterprise lo necesita</p>
</a>
<a href="/es/revista/agent-governance-hr/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Gobernanza</p>
<p class="text-body font-semibold text-gosign-dark">Agent Governance en RRHH - Por qué el CHRO debe liderar</p>
</a>
<a href="/es/revista/eu-ai-act-hr/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Regulación</p>
<p class="text-body font-semibold text-gosign-dark">EU AI Act y RRHH: lo que ahora es obligatorio</p>
</a>
</div>
</div>
</section>

<!-- Otros sectores -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Travel Decision Layer en otros sectores</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Cada sector tiene sus propios convenios, estructuras de costes y factores de complejidad. El Decision Layer es el mismo. La configuración es sectorial.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/es/servicios/travel-decision-layer/aviacion/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Aviación</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">Tripulación, convenios colectivos, IROP</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">95% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">En detalle &rarr;</span>
</div>
</a>
<a href="/es/servicios/travel-decision-layer/consultoria/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Consultoría</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">Split de clientes, multi-centro de costes, política</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">85% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">En detalle &rarr;</span>
</div>
</a>
<a href="/es/servicios/travel-decision-layer/logistica/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Logística</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">GPS, Paquete de Movilidad UE, Zero-Touch conductores</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">95% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">En detalle &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- AI Travel Decision Layer - Gastos de viaje ---
> El Decision Layer descompone cada gasto de viaje en pasos de decisión. Basado en reglas, auditable, 85-95% Zero-Touch en cuatro sectores.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/es/por-que-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div><p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p><p class="text-xs text-gosign-text-light">Cada decisión rastreable</p></div>
</a>
<a href="/es/por-que-gosign/#infraestructura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div><p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Su infraestructura</p><p class="text-xs text-gosign-text-light">Sin SaaS. Sin vendor lock-in.</p></div>
</a>
<a href="/es/por-que-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div><p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p><p class="text-xs text-gosign-text-light">Sin riesgo de cloud estadounidense</p></div>
</a>
</div>
</div>
</div>

<!-- Problema -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div><span class="text-h1 font-bold text-gosign-accent-text">EUR 53</span><p class="text-small text-gosign-text-light mt-1">por caso, procesamiento manual</p></div>
<div><span class="text-h1 font-bold text-gosign-accent-text">19%</span><p class="text-small text-gosign-text-light mt-1">tasa de error en liquidaciones de viaje</p></div>
<div><span class="text-h1 font-bold text-gosign-accent-text">EUR 48</span><p class="text-small text-gosign-text-light mt-1">coste de corrección por error</p></div>
<p class="sm:col-span-3 text-xs text-gosign-text-light">GBTA Foundation 2024: USD 58 por transacción (aprox. EUR 53). HRS, "Expense Reporting: Global Practices and Pain Points".</p>
</div>
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">El Problema</p>
<h2 class="text-h1 font-bold text-gosign-dark">Por qué las herramientas de gastos fracasan en organizaciones complejas</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">SAP Concur, Circula, Moss, Spendesk. Todas digitalizan el mismo proceso manual: capturar recibos, rellenar formularios, obtener aprobaciones. Con EUR 53 por caso y 19% de tasa de error según GBTA, resulta costoso. Pero en organizaciones con convenios colectivos, personal internacional y decenas de jurisdicciones fiscales, la captura no es el problema. El problema es la decisión.</p>
<div class="mt-10">
<div class="grid grid-cols-1 md:grid-cols-3 gap-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-h3 font-bold text-gosign-dark">EUR 53 por caso</h3><p class="text-body text-gosign-text-light mt-2">Las herramientas de gastos digitalizan formularios en papel. El empleado rellena, el responsable aprueba, contabilidad revisa. Tres pasos manuales, EUR 53 por caso (GBTA). Con 100.000 casos al año, son EUR 5,3 millones solo en costes de procesamiento.</p></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-h3 font-bold text-gosign-dark">19% tasa de error</h3><p class="text-body text-gosign-text-light mt-2">Dietas por país, reglas de contabilización, deducciones por comidas, overrides de convenio colectivo, umbrales de exención fiscal. Ningún empleado conoce todas las reglas. Ningún aprobador las verifica. Resultado: uno de cada cinco casos es incorrecto. EUR 48 de coste de corrección por error (GBTA).</p></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-h3 font-bold text-gosign-dark">Cero preparación para auditoría</h3><p class="text-body text-gosign-text-light mt-2">Cuando llega la inspección de Hacienda, falta la evidencia: ¿qué regla se aplicó? ¿Por qué esta dieta? ¿Era correcta la deducción? Las herramientas de gastos documentan lo que se presentó. No por qué se decidió así.</p></div>
</div>
</div>
</div>
</section>

<!-- Decision Layer -->
<section id="decision-layer" class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">El Decision Layer</p>
<h2 class="text-h1 font-bold text-gosign-dark">Cada caso. Descompuesto en pasos de decisión.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">El Travel Decision Layer funciona como todo Gosign Decision Layer: descompone un proceso en pasos de decisión individuales y define para cada paso quién o qué decide. Motor de reglas, convenio colectivo o persona. No todo de una vez, sino paso a paso, documentado y trazable.</p>
<div class="mt-10"><img src="/images/diagrams/travel-decision-flow-v2-es.svg" alt="Flujo de decisiones del Travel Decision Layer: datos de entrada, extracción AI, Decision Layer, resultado" width="1000" height="280" class="w-full" /></div>
<p class="text-body text-gosign-text mt-8 max-w-narrow font-semibold">AI extrae y clasifica. El Decision Layer decide. Esta separación es la razón por la que el sistema es auditable, conforme con el AI Act y compatible con el Comité de Empresa.</p>
<div class="mt-10">
<div class="grid grid-cols-1 md:grid-cols-2 gap-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-h3 font-bold text-gosign-dark">Mismo input, mismo resultado</h3><p class="text-body text-gosign-text-light mt-2">Las Decision Tables están versionadas. Cada caso se verifica contra una versión de reglas definida. Sin resultados estocásticos, sin output de LLM en importes o tratamiento fiscal.</p></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-h3 font-bold text-gosign-dark">De 40 a 120 microdecisiones por caso</h3><p class="text-body text-gosign-text-light mt-2">No una gran decisión 'aprobado / rechazado', sino docenas de pequeñas: ¿qué dieta? ¿Qué deducción? ¿Qué convenio colectivo? ¿Parte exenta? Cada una documentada individualmente.</p></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-h3 font-bold text-gosign-dark">Motor de reglas, convenio colectivo o persona</h3><p class="text-body text-gosign-text-light mt-2">El Decision Layer no decide todo por sí mismo. Sabe qué pasos cubre el motor de reglas, cuáles están definidos por convenio colectivo y dónde debe intervenir una persona. El resultado: solo las excepciones reales requieren atención humana.</p></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-h3 font-bold text-gosign-dark">El empleado no confirma. Puede objetar.</h3><p class="text-body text-gosign-text-light mt-2">Las herramientas de gastos tradicionales exigen al empleado confirmar su propia liquidación. El Decision Layer lo invierte: el procesamiento es automático. El empleado es informado y tiene derecho de veto.</p></div>
</div>
</div>
</div>
</section>

<!-- Governance y Auditoría -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<h2 class="text-h1 font-bold text-gosign-dark">No documentado a posteriori. Generado en el proceso.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Cuando el inspector de Hacienda pregunta "¿Por qué se aplicaron 28 EUR en lugar de 14 EUR?" no basta con "el sistema lo calculó". El Travel Decision Layer genera para cada microdecisión un acta de decisión que responde exactamente a esa pregunta: qué regla de negocio con su versión, qué input, qué resultado, cuándo, por quién - incluida la vía de impugnación. Con ello, la explicación de la decisión individual conforme al art. 86 del EU AI Act pasa de ser un proyecto forense a una simple consulta.</p>
<div class="mt-10 bg-gosign-dark rounded-card p-6 sm:p-8">
<div class="flex items-start gap-4 mb-6">
<svg class="w-8 h-8 text-gosign-accent-on-dark flex-shrink-0" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12h6m-6 4h6m2 5H7a2 2 0 01-2-2V5a2 2 0 012-2h5.586a1 1 0 01.707.293l5.414 5.414a1 1 0 01.293.707V19a2 2 0 01-2 2z" /></svg>
<div><h3 class="text-h3 font-bold text-white">Cada microdecisión genera una entrada de auditoría</h3><p class="text-small text-gosign-text-on-dark/70 mt-1">Append-only. Nada se sobrescribe, nada se elimina. Las correcciones generan asientos de anulación y ajuste. Firmado con SHA-256, exportable en cualquier momento.</p></div>
</div>
<div class="grid grid-cols-2 sm:grid-cols-3 gap-3 sm:gap-4">
<div class="flex items-center gap-2.5"><svg class="w-4 h-4 text-gosign-accent-on-dark flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg><span class="text-small text-gosign-text-on-dark/80">ID de regla + versión</span></div>
<div class="flex items-center gap-2.5"><svg class="w-4 h-4 text-gosign-accent-on-dark flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg><span class="text-small text-gosign-text-on-dark/80">Datos de entrada (¿qué información había?)</span></div>
<div class="flex items-center gap-2.5"><svg class="w-4 h-4 text-gosign-accent-on-dark flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg><span class="text-small text-gosign-text-on-dark/80">Resultado (¿qué se decidió?)</span></div>
<div class="flex items-center gap-2.5"><svg class="w-4 h-4 text-gosign-accent-on-dark flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg><span class="text-small text-gosign-text-on-dark/80">Marca temporal</span></div>
<div class="flex items-center gap-2.5"><svg class="w-4 h-4 text-gosign-accent-on-dark flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg><span class="text-small text-gosign-text-on-dark/80">Actor (motor de reglas / convenio / persona)</span></div>
<div class="flex items-center gap-2.5"><svg class="w-4 h-4 text-gosign-accent-on-dark flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg><span class="text-small text-gosign-text-on-dark/80">Hash de entrada (reproducible)</span></div>
</div>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8">
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6"><div class="flex items-start gap-3"><svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M15 12a3 3 0 11-6 0 3 3 0 016 0z" /><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M2.458 12C3.732 7.943 7.523 5 12 5c4.478 0 8.268 2.943 9.542 7-1.274 4.057-5.064 7-9.542 7-4.477 0-8.268-2.943-9.542-7z" /></svg><div><h3 class="text-body font-semibold text-gosign-dark">Transparente para el Comité de Empresa</h3><p class="text-small text-gosign-text-light mt-2">Motor de reglas consultable. Decisiones trazables. Puntuación de anomalías controlable por Feature Flag. Informes pseudonimizados. Compliance y rendimiento arquitectónicamente separados.</p><a href="/es/governance/co-determination/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Derecho de consulta en detalle &rarr;</a></div></div></div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6"><div class="flex items-start gap-3"><svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12l2 2 4-4m5.618-4.016A11.955 11.955 0 0112 2.944a11.955 11.955 0 01-8.618 3.04A12.02 12.02 0 003 9c0 5.591 3.824 10.29 9 11.622 5.176-1.332 9-6.03 9-11.622 0-1.042-.133-2.052-.382-3.016z" /></svg><div><h3 class="text-body font-semibold text-gosign-dark">Listo para inspección de Hacienda</h3><p class="text-small text-gosign-text-light mt-2">Plazos de conservación soportados. Anonimización en lugar de eliminación para compatibilidad con RGPD. Cada caso reproducible vía hash de entrada.</p><a href="/es/governance/cert-ready/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready by Design en detalle &rarr;</a></div></div></div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6"><div class="flex items-start gap-3"><svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 5H7a2 2 0 00-2 2v12a2 2 0 002 2h10a2 2 0 002-2V7a2 2 0 00-2-2h-2M9 5a2 2 0 002 2h2a2 2 0 002-2M9 5a2 2 0 012-2h2a2 2 0 012 2m-6 9l2 2 4-4" /></svg><div><h3 class="text-body font-semibold text-gosign-dark">Cumplimiento sistemático</h3><p class="text-small text-gosign-text-light mt-2">Sin informes trimestrales, sin auditorías por muestreo. Cada caso individual es verificado por reglas. Las desviaciones se detectan de inmediato y se documentan.</p></div></div></div>
</div>
</div>
</section>

<!-- Tabla comparativa -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="overflow-x-auto">
<table class="w-full text-small border-collapse">
<thead><tr class="border-b-2 border-gosign-border"><th class="text-left py-3 px-4 font-semibold text-gosign-dark">Dimensión</th><th class="text-left py-3 px-4 font-semibold text-gosign-dark">Herramienta de gastos tradicional</th><th class="text-left py-3 px-4 font-semibold text-gosign-accent-text">Travel Decision Layer</th></tr></thead>
<tbody>
<tr class="border-b border-gosign-border"><td class="py-3 px-4 font-medium text-gosign-dark">Modelo de decisión</td><td class="py-3 px-4 text-gosign-text-light">El empleado rellena, el responsable aprueba</td><td class="py-3 px-4 text-gosign-accent-text font-semibold">El Decision Layer aplica reglas, el empleado tiene veto</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4 font-medium text-gosign-dark">Complejidad normativa</td><td class="py-3 px-4 text-gosign-text-light">Políticas básicas, sin lógica de convenio colectivo</td><td class="py-3 px-4 text-gosign-accent-text font-semibold">Decision Tables versionadas: normativa fiscal, dietas, convenios colectivos</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4 font-medium text-gosign-dark">Audit Trail</td><td class="py-3 px-4 text-gosign-text-light">Recibo almacenado, decisión no documentada</td><td class="py-3 px-4 text-gosign-accent-text font-semibold">Cada microdecisión documentada: regla, input, resultado, marca temporal</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4 font-medium text-gosign-dark">Inspección de Hacienda</td><td class="py-3 px-4 text-gosign-text-light">Reconstrucción manual desde expedientes</td><td class="py-3 px-4 text-gosign-accent-text font-semibold">Exportación: expediente de auditoría sellado por caso, reproducible por hash de entrada</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4 font-medium text-gosign-dark">Experiencia del empleado</td><td class="py-3 px-4 text-gosign-text-light">Formulario, carga, esperar aprobación</td><td class="py-3 px-4 text-gosign-accent-text font-semibold">Procesamiento automático, notificación, opción de veto</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4 font-medium text-gosign-dark">Escalabilidad</td><td class="py-3 px-4 text-gosign-text-light">Lineal: más casos = más revisores</td><td class="py-3 px-4 text-gosign-accent-text font-semibold">Constante: 100 o 100.000 casos, mismo motor de reglas</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4 font-medium text-gosign-dark">Comité de Empresa</td><td class="py-3 px-4 text-gosign-text-light">Opaco, difícil de auditar</td><td class="py-3 px-4 text-gosign-accent-text font-semibold">Motor de reglas consultable, puntuación de anomalías por Feature Flag, informes pseudonimizados</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Simulaciones sectoriales -->
<section id="simulaciones" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Simulado para volúmenes enterprise</p>
<h2 class="text-h1 font-bold text-white">Cuatro sectores. Calculados.</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Hemos configurado el Travel Decision Layer para cuatro sectores con volúmenes realistas y calculado los resultados. Cada tarjeta muestra los parámetros de simulación y el resultado.</p>
<div class="grid grid-cols-1 md:grid-cols-2 gap-6 mt-10">
<a href="/es/servicios/travel-decision-layer/aviacion/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors"><div class="flex items-center justify-between mb-4"><h3 class="text-h3 font-bold text-white">Aviación</h3><div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div></div><ul class="space-y-1.5 text-small text-gosign-text-on-dark/70"><li>Decenas de miles de tripulaciones, múltiples grupos de personal</li><li>Múltiples convenios colectivos paralelos por aerolínea</li><li>100.000 a 1.000.000+ casos/año</li><li>Multi-aerolínea, multi-jurisdicción</li></ul><div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between"><span class="text-h3 font-bold text-gosign-accent-on-dark">95% Zero-Touch</span><span class="text-small text-gosign-accent-on-dark font-semibold">Aviación en detalle &rarr;</span></div></a>
<a href="/es/servicios/travel-decision-layer/consultoria/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors"><div class="flex items-center justify-between mb-4"><h3 class="text-h3 font-bold text-white">Consultoría</h3><div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-white/20"></span></div></div><ul class="space-y-1.5 text-small text-gosign-text-on-dark/70"><li>8.000+ consultores, 15+ jurisdicciones</li><li>Split de tres vías: fiscal / cliente / interno</li><li>Semanas multi-cliente, centros de coste cambiantes</li></ul><div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between"><span class="text-h3 font-bold text-gosign-accent-on-dark">85% Zero-Touch</span><span class="text-small text-gosign-accent-on-dark font-semibold">Consultoría en detalle &rarr;</span></div></a>
<a href="/es/servicios/travel-decision-layer/logistica/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors"><div class="flex items-center justify-between mb-4"><h3 class="text-h3 font-bold text-white">Logística</h3><div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-white/20"></span></div></div><ul class="space-y-1.5 text-small text-gosign-text-on-dark/70"><li>20.000+ conductores, Paquete de Movilidad UE</li><li>Detección de país basada en GPS</li><li>Dietas de conductores basadas en flota</li></ul><div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between"><span class="text-h3 font-bold text-gosign-accent-on-dark">95% Zero-Touch</span><span class="text-small text-gosign-accent-on-dark font-semibold">Logística en detalle &rarr;</span></div></a>
<a href="/es/servicios/travel-decision-layer/ventas/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors"><div class="flex items-center justify-between mb-4"><h3 class="text-h3 font-bold text-white">Ventas</h3><div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-white/20"></span><span class="w-3 h-1.5 rounded-sm bg-white/20"></span></div></div><ul class="space-y-1.5 text-small text-gosign-text-on-dark/70"><li>5.000+ fuerza comercial, integración CRM</li><li>10.000+ casos al mes</li><li>Aplicación de políticas en volumen</li></ul><div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between"><span class="text-h3 font-bold text-gosign-accent-on-dark">90% Zero-Touch</span><span class="text-small text-gosign-accent-on-dark font-semibold">Ventas en detalle &rarr;</span></div></a>
</div>
</div>
</section>

<!-- Implementación -->
<section id="implementation" class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Implementación</p>
<h2 class="text-h1 font-bold text-gosign-dark">Del piloto al sistema en producción.</h2>
<div class="grid grid-cols-1 lg:grid-cols-2 gap-10 mt-10">
<div><h3 class="text-h3 font-bold text-gosign-dark mb-3">Arquitectura técnica</h3><p class="text-body text-gosign-text">El Travel Decision Layer opera completamente en su infraestructura: su centro de datos, su red, su control. Sin dependencia SaaS, sin fuga de datos, sin seguimiento telemétrico externo. Containerizado, multi-tenant, listo para despliegue en su Private Cloud o como despliegue gestionado en centros de datos de la UE.</p><div class="flex flex-wrap gap-4 mt-3"><a href="/es/servicios/infraestructura/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infraestructura en detalle &rarr;</a><a href="/es/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Arquitectura del Decision Layer &rarr;</a></div></div>
<div><h3 class="text-h3 font-bold text-gosign-dark mb-3">Implementación</h3><p class="text-body text-gosign-text">El Decision Layer no se instala, se configura: sus convenios colectivos, sus políticas, su ecosistema de sistemas. Los proyectos piloto típicos arrancan en 3 meses con un sector y un convenio colectivo. Las extensiones a otros grupos de personal o conexiones de sistemas funcionan en paralelo con el piloto.</p></div>
</div>
<h3 class="text-h3 font-bold text-gosign-dark mt-12 mb-6">Palanca económica</h3>
<div class="grid grid-cols-1 sm:grid-cols-2 gap-6">
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6"><div class="flex items-start gap-4"><svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12l2 2 4-4m5.618-4.016A11.955 11.955 0 0112 2.944a11.955 11.955 0 01-8.618 3.04A12.02 12.02 0 003 9c0 5.591 3.824 10.29 9 11.622 5.176-1.332 9-6.03 9-11.622 0-1.042-.133-2.052-.382-3.016z" /></svg><div><p class="text-body font-semibold text-gosign-dark">Verificación sistemática de reglas en vez de muestreos</p><p class="text-small text-gosign-text-light mt-2">Cada caso pasa por el mismo motor de reglas. Las desviaciones se detectan y documentan, no se descubren en la conciliación trimestral.</p></div></div></div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6"><div class="flex items-start gap-4"><svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M13 10V3L4 14h7v7l9-11h-7z" /></svg><div><p class="text-body font-semibold text-gosign-dark">Sin workflows de aprobación para casos estándar</p><p class="text-small text-gosign-text-light mt-2">Tiempo de procesamiento de días a minutos. Los responsables solo aprueban excepciones.</p></div></div></div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6"><div class="flex items-start gap-4"><svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M4 6a2 2 0 012-2h2a2 2 0 012 2v2a2 2 0 01-2 2H6a2 2 0 01-2-2V6zm10 0a2 2 0 012-2h2a2 2 0 012 2v2a2 2 0 01-2 2h-2a2 2 0 01-2-2V6zM4 16a2 2 0 012-2h2a2 2 0 012 2v2a2 2 0 01-2 2H6a2 2 0 01-2-2v-2zm10 0a2 2 0 012-2h2a2 2 0 012 2v2a2 2 0 01-2 2h-2a2 2 0 01-2-2v-2z" /></svg><div><p class="text-body font-semibold text-gosign-dark">Asignación automática de centros de coste y proyectos</p><p class="text-small text-gosign-text-light mt-2">Sin mapeo manual para miles de casos. Sin cuello de botella a fin de mes.</p></div></div></div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6"><div class="flex items-start gap-4"><svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12h6m-6 4h6m2 5H7a2 2 0 01-2-2V5a2 2 0 012-2h5.586a1 1 0 01.707.293l5.414 5.414a1 1 0 01.293.707V19a2 2 0 01-2 2z" /></svg><div><p class="text-body font-semibold text-gosign-dark">Expedientes de decisión listos para auditoría generados en el proceso</p><p class="text-small text-gosign-text-light mt-2">La inspección de Hacienda es una exportación, no un proyecto de investigación. Semanas se convierten en minutos.</p></div></div></div>
</div>
</div>
</section>

<!-- Seguridad -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Seguridad</p>
<h2 class="text-h1 font-bold text-gosign-dark">Seguridad enterprise. Desde el día uno.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">No añadida como funcionalidad a posteriori, sino construida como principio arquitectónico. El Travel Decision Layer está diseñado para entornos regulados donde la protección de datos, la preparación para auditoría y la trazabilidad no son extras opcionales.</p>
<div class="mt-10">
<div class="grid grid-cols-1 md:grid-cols-3 gap-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-h3 font-bold text-gosign-dark">100% infraestructura del cliente</h3><p class="text-body text-gosign-text-light mt-2">El Decision Layer opera completamente en su red. Sin dependencia SaaS, sin fuga de datos, sin seguimiento telemétrico externo. Secrets en su KMS, logs en su SIEM, SSO vía su Identity Provider.</p></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-h3 font-bold text-gosign-dark">RGPD by Design</h3><p class="text-body text-gosign-text-light mt-2">Anonimización en lugar de eliminación. Compatible con plazos de conservación fiscal y RGPD Art. 17. Sin conflicto entre normativa fiscal y protección de datos.</p><a href="/es/governance/data-residency/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover mt-3 inline-block whitespace-nowrap">Residencia de datos en detalle</a></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-h3 font-bold text-gosign-dark">Conforme con el AI Act</h3><p class="text-body text-gosign-text-light mt-2">Separación arquitectónica clara: LLM para extracción de datos, Decision Layer para decisiones. Sin caja negra sobre hechos fiscales. Cada decisión reconstruible.</p><a href="/es/governance/eu-ai-act/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover mt-3 inline-block whitespace-nowrap">EU AI Act Readiness</a></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-h3 font-bold text-gosign-dark">Audit Trail (append-only)</h3><p class="text-body text-gosign-text-light mt-2">Expedientes de decisión firmados. Hash de entrada más versión de regla produce resultado reproducible. Paquetes de auditoría sellados (JSON + PDF, SHA-256). Inspección en cualquier momento.</p></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-h3 font-bold text-gosign-dark">ISO 27001 / PS 951 cert-ready</h3><p class="text-body text-gosign-text-light mt-2">Controls Registry integrado, Evidence Runs automatizados, políticas versionadas. Cumplimiento en operación continua, no documentado a posteriori.</p><a href="/es/governance/cert-ready/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover mt-3 inline-block whitespace-nowrap">Cert-Ready by Design</a></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-h3 font-bold text-gosign-dark">SSO y separación de mandantes</h3><p class="text-body text-gosign-text-light mt-2">Integración con Identity Providers existentes. Separación de mandantes a nivel de base de datos (Row Level Security). Modelo de roles configurable de forma granular.</p></div>
</div>
</div>
</div>
</section>

<!-- Profundización -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Profundización en el Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nuestra serie de artículos para ejecutivos que implementan agentes de IA en la empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/es/revista/decision-layer-explicado/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors"><p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Fundamentos</p><p class="text-body font-semibold text-gosign-dark">Decision Layer - Qué es y por qué todo agente AI enterprise lo necesita</p></a>
<a href="/es/revista/comite-empresa-ia-codeterminacion/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors"><p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Codeterminación</p><p class="text-body font-semibold text-gosign-dark">Comité de Empresa e IA: Derecho de Información y Consulta como Constraint Arquitectónico</p></a>
<a href="/es/revista/cert-ready-by-design/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors"><p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Auditoría</p><p class="text-body font-semibold text-gosign-dark">Cert-Ready by Design: IA preparada para auditoría</p></a>
<a href="/es/revista/acta-de-decision-decisiones-ia-impugnables/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors"><p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p><p class="text-body font-semibold text-gosign-dark">El acta de decisión: por qué toda decisión de IA debe ser impugnable</p></a>
</div>
</div>
</section>

--- Servicios ---
> AI Agents, Finance Agents, HR Agents, Infraestructura de IA, Document Intelligence y firmas digitales eIDAS.

<!-- Lo Que Construimos -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Lo Que Construimos</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Gosign desarrolla y opera infraestructura de AI Agents para empresas. Construimos la capa entre modelo de lenguaje y sistema empresarial - incluyendo orquestación, gobernanza y auditoría.
</p>
</div>
</div>
</section>

<!-- Service Cards -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-1 lg:grid-cols-3 gap-6 lg:gap-8">
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9.813 15.904L9 18.75l-.813-2.846a4.5 4.5 0 00-3.09-3.09L2.25 12l2.846-.813a4.5 4.5 0 003.09-3.09L9 5.25l.813 2.846a4.5 4.5 0 003.09 3.09L15.75 12l-2.846.813a4.5 4.5 0 00-3.09 3.09zM18.259 8.715L18 9.75l-.259-1.035a3.375 3.375 0 00-2.455-2.456L14.25 6l1.036-.259a3.375 3.375 0 002.455-2.456L18 2.25l.259 1.035a3.375 3.375 0 002.455 2.456L21.75 6l-1.036.259a3.375 3.375 0 00-2.455 2.456zM16.894 20.567L16.5 21.75l-.394-1.183a2.25 2.25 0 00-1.423-1.423L13.5 18.75l1.183-.394a2.25 2.25 0 001.423-1.423l.394-1.183.394 1.183a2.25 2.25 0 001.423 1.423l1.183.394-1.183.394a2.25 2.25 0 00-1.423 1.423z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">AI Agents</h3>
<p class="text-body text-gosign-text-light mt-3">Document, Workflow y Knowledge Agents para procesos enterprise. Auditables, explicables, listos para auditoría.</p>
<a href="/es/servicios/ai-agents/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">AI Agents en detalle<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg></a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 18.75a60.07 60.07 0 0115.797 2.101c.727.198 1.453-.342 1.453-1.096V18.75M3.75 4.5v.75A.75.75 0 013 6h-.75m0 0v-.375c0-.621.504-1.125 1.125-1.125H20.25M2.25 6v9m18-10.5v.75c0 .414.336.75.75.75h.75m-1.5-1.5h.375c.621 0 1.125.504 1.125 1.125v9.75c0 .621-.504 1.125-1.125 1.125h-.375m1.5-1.5H21a.75.75 0 00-.75.75v.75m0 0H3.75m0 0h-.375a1.125 1.125 0 01-1.125-1.125V15m1.5 1.5v-.75A.75.75 0 003 15h-.75M15 10.5a3 3 0 11-6 0 3 3 0 016 0zm3 0h.008v.008H18V10.5zm-12 0h.008v.008H6V10.5z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Finance Agents</h3>
<p class="text-body text-gosign-text-light mt-3">Decision Automation para procesamiento de documentos y contabilidad. Cert-Ready by Design. Integración Sage y SAP.</p>
<a href="/es/servicios/agente-finanzas/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">Finance Agents<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg></a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M15 19.128a9.38 9.38 0 002.625.372 9.337 9.337 0 004.121-.952 4.125 4.125 0 00-7.533-2.493M15 19.128v-.003c0-1.113-.285-2.16-.786-3.07M15 19.128v.106A12.318 12.318 0 018.624 21c-2.331 0-4.512-.645-6.374-1.766l-.001-.109a6.375 6.375 0 0111.964-3.07M12 6.375a3.375 3.375 0 11-6.75 0 3.375 3.375 0 016.75 0zm8.25 2.25a2.625 2.625 0 11-5.25 0 2.625 2.625 0 015.25 0z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">HR Agents</h3>
<p class="text-body text-gosign-text-light mt-3">AI Agents para RRHH y People Operations. Compatible con comité de empresa. Decision Layer con Human-in-the-Loop.</p>
<a href="/es/hr-ai-agents/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">HR Agents<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg></a>
</article>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-1 lg:grid-cols-3 gap-6 lg:gap-8">
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M5.25 14.25h13.5m-13.5 0a3 3 0 01-3-3m3 3a3 3 0 100 6h13.5a3 3 0 100-6m-16.5-3a3 3 0 013-3h13.5a3 3 0 013 3m-19.5 0a4.5 4.5 0 01.9-2.7L5.737 5.1a3.375 3.375 0 012.7-1.35h7.126c1.062 0 2.062.5 2.7 1.35l2.587 3.45a4.5 4.5 0 01.9 2.7m0 0a3 3 0 01-3 3m0 3h.008v.008h-.008v-.008zm0-6h.008v.008h-.008v-.008zm-3 6h.008v.008h-.008v-.008zm0-6h.008v.008h-.008v-.008z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">AI Infrastructure</h3>
<p class="text-body text-gosign-text-light mt-3">LLM Hosting, RAG, Orquestación, Self-Hosted. Agnóstica respecto a modelos, flexible en despliegue, preparada para gobernanza.</p>
<a href="/es/servicios/infraestructura/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">AI Infrastructure<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg></a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M19.5 14.25v-2.625a3.375 3.375 0 00-3.375-3.375h-1.5A1.125 1.125 0 0113.5 7.125v-1.5a3.375 3.375 0 00-3.375-3.375H8.25m0 12.75h7.5m-7.5 3H12M10.5 2.25H5.625c-.621 0-1.125.504-1.125 1.125v17.25c0 .621.504 1.125 1.125 1.125h12.75c.621 0 1.125-.504 1.125-1.125V11.25a9 9 0 00-9-9z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Document Intelligence</h3>
<p class="text-body text-gosign-text-light mt-3">Comprensión de documentos más allá del OCR. Clasificación, extracción, validación - impulsado por LLM, controlado por Decision Layer. Para facturas, contratos, certificados y documentos no estructurados.</p>
<a href="/es/servicios/document-intelligence/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">Document Intelligence<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg></a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 6.75V15m6-6v8.25m.503 3.498l4.875-2.437c.381-.19.622-.58.622-1.006V4.82c0-.836-.88-1.38-1.628-1.006l-3.869 1.934c-.317.159-.69.159-1.006 0L9.503 3.252a1.125 1.125 0 00-1.006 0L3.622 5.689C3.24 5.88 3 6.27 3 6.695V19.18c0 .836.88 1.38 1.628 1.006l3.869-1.934c.317-.159.69-.159 1.006 0l4.994 2.497c.317.158.69.158 1.006 0z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Travel Decision Layer</h3>
<p class="text-body text-gosign-text-light mt-3">Governance de gastos de viaje impulsada por AI. El Decision Layer descompone cada caso de gastos de viaje en pasos de decisión y aplica normativa fiscal, dietas y convenios colectivos de forma determinista. Configurable para aviación, consultoría, logística y ventas.</p>
<a href="/es/servicios/travel-decision-layer/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">Travel Decision Layer<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg></a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M17.25 6.75L22.5 12l-5.25 5.25m-10.5 0L1.5 12l5.25-5.25m7.5-3l-4.5 16.5" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Ingeniería de Software Empresarial</h3>
<p class="text-body text-gosign-text-light mt-3">Desde 2001. Más de 5.000 proyectos. 25 años de desarrollo de software empresarial - hoy el fundamento de ingeniería para infraestructura de IA.</p>
<a href="/es/servicios/software-engineering/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">Ingeniería de Software<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg></a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M16.5 10.5V6.75a4.5 4.5 0 10-9 0v3.75m-.75 11.25h10.5a2.25 2.25 0 002.25-2.25v-6.75a2.25 2.25 0 00-2.25-2.25H6.75a2.25 2.25 0 00-2.25 2.25v6.75a2.25 2.25 0 002.25 2.25z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Firmas Digitales eIDAS</h3>
<p class="text-body text-gosign-text-light mt-3">En cooperación con socios certificados ETSI. Firmas electrónicas simples, avanzadas (AES) y cualificadas (QES).</p>
<a href="/es/servicios/eidas-signatures/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">Firmas eIDAS<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg></a>
</article>
</div>
</div>
</section>

<!-- Cómo Trabajamos -->

<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark text-center">Cómo Trabajamos</h2>
<div class="mt-12 grid grid-cols-1 md:grid-cols-3 gap-8 relative">
<div class="text-center">
<div class="w-14 h-14 mx-auto rounded-full bg-gosign-accent flex items-center justify-center">
<span class="text-h3 font-bold text-white">1</span>
</div>
<h3 class="text-h3 font-bold text-gosign-dark mt-4">Discover</h3>
<p class="text-small font-semibold text-gosign-accent-text mt-1">1 semana</p>
<p class="text-body text-gosign-text-light mt-2">Análisis de procesos, comprender conjuntos de reglas, priorizar casos de uso.</p>
</div>
<div class="text-center">
<div class="w-14 h-14 mx-auto rounded-full bg-gosign-accent flex items-center justify-center">
<span class="text-h3 font-bold text-white">2</span>
</div>
<h3 class="text-h3 font-bold text-gosign-dark mt-4">Build</h3>
<p class="text-small font-semibold text-gosign-accent-text mt-1">3-4 semanas</p>
<p class="text-body text-gosign-text-light mt-2">PoC productivo. Un agente, un proceso, en vivo en su infraestructura.</p>
</div>
<div class="text-center">
<div class="w-14 h-14 mx-auto rounded-full bg-gosign-accent flex items-center justify-center">
<span class="text-h3 font-bold text-white">3</span>
</div>
<h3 class="text-h3 font-bold text-gosign-dark mt-4">Scale</h3>
<p class="text-small font-semibold text-gosign-accent-text mt-1">Continuo</p>
<p class="text-body text-gosign-text-light mt-2">Más agentes, más procesos. Misma gobernanza, misma auditabilidad.</p>
</div>
</div>
<p class="text-body-lg text-center text-gosign-text-light mt-8 max-w-narrow mx-auto">Tras 12-18 meses, usted opera sus agentes de forma independiente. Acceso completo al código fuente, prompts y conjuntos de reglas. Sin vendor lock-in.</p>
</div>
</section>


<!-- Profundización -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Profundización en el Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nuestra serie de artículos para ejecutivos que implementan agentes de IA en la empresa.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/es/revista/que-son-agentes-ia/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Fundamentos</p>
<p class="text-body font-semibold text-gosign-dark">¿Qué son los agentes de IA? Document, Workflow y Knowledge Agents</p>
</a>
<a href="/es/revista/decision-layer-explicado/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Arquitectura</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - Qué es y por qué todo agente AI enterprise lo necesita</p>
</a>
<a href="/es/revista/por-que-fracasan-proyectos-ia-rrhh/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Estrategia</p>
<p class="text-body font-semibold text-gosign-dark">Por qué fracasan los proyectos de IA en RRHH</p>
</a>
</div>
</div>
</section>

--- ¿Sitio web hackeado? 10 causas y ayuda ---
> Por qué se hackean los sitios web: las 10 causas más frecuentes y qué puede hacer de inmediato. Ayuda de emergencia de Gosign.

<!-- ¿Qué hacer si han hackeado tu web? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">¿Qué hacer si han hackeado su sitio web?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Cuando su sitio web ha sido hackeado, la velocidad es clave: eliminar el malware, encontrar el punto de entrada, cerrar la brecha, informar a Google de la limpieza. Gosign ofrece soporte de emergencia para sitios web hackeados - WordPress, TYPO3 y otros CMS. Este artículo explica las 10 causas más frecuentes de hackeos y cómo protegerse.
</p>
</div>
</section>

<!-- 10 razones -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">Las 10 razones más frecuentes por las que se hackean sitios web</h2>

<div class="space-y-8">
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">1. Versión de CMS desactualizada</h3>
<p class="text-body text-gosign-text leading-relaxed">
WordPress 5.x, TYPO3 v9, Joomla 3: las versiones antiguas de CMS tienen vulnerabilidades conocidas y documentadas. Los atacantes escanean automáticamente en busca de instalaciones desactualizadas. Solución: mantener siempre la versión LTS actual, actualizaciones de seguridad automáticas.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">2. Plugins/extensiones inseguros</h3>
<p class="text-body text-gosign-text leading-relaxed">
Un solo plugin desactualizado es suficiente. Gosign monitoriza más de 800 extensiones TYPO3 y conoce los candidatos de riesgo. En WordPress: solo plugins de fuentes fiables, actualizaciones regulares, eliminar plugins no utilizados (no solo desactivarlos).
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">3. Contraseñas débiles</h3>
<p class="text-body text-gosign-text leading-relaxed">
"admin/admin123" sigue siendo sorprendentemente frecuente. Los ataques de fuerza bruta prueban miles de combinaciones por minuto. Solución: contraseñas seguras + autenticación de dos factores + limitación de intentos de inicio de sesión.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">4. Falta de SSL/HTTPS</h3>
<p class="text-body text-gosign-text leading-relaxed">
Sin HTTPS, los datos de inicio de sesión se transmiten en texto plano. Cada sitio web necesita un certificado SSL. En 2026 no hay excusa.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">5. Hosting inseguro</h3>
<p class="text-body text-gosign-text leading-relaxed">
Hosting compartido con cientos de sitios en un servidor: si uno es hackeado, todos están en peligro. Solución: hosting gestionado con aislamiento, copias de seguridad automáticas y Web Application Firewall.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">6. Sin Web Application Firewall (WAF)</h3>
<p class="text-body text-gosign-text leading-relaxed">
Un WAF bloquea patrones de ataque conocidos (SQL Injection, XSS, File Inclusion) antes de que lleguen a su aplicación. Cloudflare WAF, ModSecurity o soluciones comerciales.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">7. Falta de copias de seguridad</h3>
<p class="text-body text-gosign-text leading-relaxed">
Sin copia de seguridad no hay salvavidas. Copias de seguridad diarias, almacenadas separadas del servidor web, probadas regularmente. Una copia de seguridad que no se puede restaurar no es una copia de seguridad.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">8. Subidas de archivos inseguras</h3>
<p class="text-body text-gosign-text leading-relaxed">
Formularios de subida sin validación permiten a los atacantes subir shells PHP. Solución: verificación estricta del tipo de archivo, almacenar subidas fuera del webroot, aleatorizar nombres de archivo.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">9. SQL Injection</h3>
<p class="text-body text-gosign-text leading-relaxed">
Las entradas de usuario sin filtrar en consultas de base de datos permiten a los atacantes leer o manipular toda la base de datos. Solución: Prepared Statements, validación de entrada, uso de ORM.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">10. Sin monitorización</h3>
<p class="text-body text-gosign-text leading-relaxed">
Si nadie vigila, nadie detecta la intrusión. Algunos hackeos pasan desapercibidos durante meses (inyección de spam, criptominería, hackeos de redirección). Solución: monitorización de disponibilidad, monitorización de integridad de archivos, escaneos de malware periódicos.
</p>
</div>
</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">¿Sitio web hackeado? Gosign ayuda. Consulta de emergencia disponible.</h3>
<p class="text-body text-gosign-text mb-6">Análisis rápido, limpieza y protección de su sitio web.</p>
<a
href="/es/contacto/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Solicitar ayuda inmediata
</a>
<p class="text-small text-gosign-text-light mt-4">25 años de experiencia · 800+ extensiones · Desarrollo acelerado por IA</p>
</div>
</section>

<!-- Checklist -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Lista de verificación: medidas inmediatas tras un hackeo</h2>
<ol class="space-y-3">
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 flex items-center justify-center bg-gosign-accent text-white font-bold rounded-full text-small">1</span>
<span class="text-body text-gosign-text pt-1">Poner el sitio web fuera de línea (modo mantenimiento)</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 flex items-center justify-center bg-gosign-accent text-white font-bold rounded-full text-small">2</span>
<span class="text-body text-gosign-text pt-1">Cambiar contraseñas (CMS, FTP, base de datos, hosting)</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 flex items-center justify-center bg-gosign-accent text-white font-bold rounded-full text-small">3</span>
<span class="text-body text-gosign-text pt-1">Asegurar copia de seguridad (estado actual para forense)</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 flex items-center justify-center bg-gosign-accent text-white font-bold rounded-full text-small">4</span>
<span class="text-body text-gosign-text pt-1">Identificar la última copia de seguridad limpia</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 flex items-center justify-center bg-gosign-accent text-white font-bold rounded-full text-small">5</span>
<span class="text-body text-gosign-text pt-1">Ejecutar escaneo de malware</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 flex items-center justify-center bg-gosign-accent text-white font-bold rounded-full text-small">6</span>
<span class="text-body text-gosign-text pt-1">Identificar el punto de entrada (revisar logs)</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 flex items-center justify-center bg-gosign-accent text-white font-bold rounded-full text-small">7</span>
<span class="text-body text-gosign-text pt-1">Limpiar y cerrar la brecha</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 flex items-center justify-center bg-gosign-accent text-white font-bold rounded-full text-small">8</span>
<span class="text-body text-gosign-text pt-1">Volver a poner el sitio web en línea</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 flex items-center justify-center bg-gosign-accent text-white font-bold rounded-full text-small">9</span>
<span class="text-body text-gosign-text pt-1">Google Search Console: solicitud de revisión</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 flex items-center justify-center bg-gosign-accent text-white font-bold rounded-full text-small">10</span>
<span class="text-body text-gosign-text pt-1">Configurar monitorización para que no vuelva a ocurrir</span>
</li>
</ol>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
Gosign es una agencia digital con sede en Hamburgo y 25 años de experiencia en desarrollo web, TYPO3 e integración de IA.
Hemos analizado más de 800 extensiones TYPO3 y hoy desarrollamos con apoyo de IA
hasta un 70&nbsp;% más rápido que con métodos tradicionales. Nuestros clientes son empresas
medianas, universidades e instituciones europeas.
</p>
<p class="text-small text-gosign-text-light mt-2">Actualizado: febrero 2026</p>
</div>
</section>

<!-- Temas relacionados -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Temas relacionados</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/es/seguridad-web-estandares/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Seguridad</p>
<p class="text-body font-semibold text-gosign-dark">Seguridad web según estándares europeos</p>
</a>
<a href="/es/typo3-monitor-seguridad/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Monitorización</p>
<p class="text-body font-semibold text-gosign-dark">Monitor de seguridad TYPO3</p>
</a>
<a href="/es/agencia-wordpress/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Desarrollo web</p>
<p class="text-body font-semibold text-gosign-dark">Agencia WordPress Hamburgo</p>
</a>
</div>
</div>
</section>

--- Sobre nosotros - Enterprise AI Infrastructure desde 2001 ---
> Desde 2001. Más de 5.000 proyectos para Airbus, Volkswagen, Shell. Hoy Enterprise AI Infrastructure & Agent Engineering.

<article class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<div class="prose prose-lg prose-headings:text-gosign-dark prose-headings:font-bold prose-h2:text-h2 prose-h2:mt-12 prose-h2:mb-4 prose-h3:text-h3 prose-h3:mt-8 prose-h3:mb-3 prose-p:text-gosign-text prose-p:leading-relaxed prose-a:text-gosign-accent-text prose-a:underline prose-a:decoration-gosign-accent-text/30 hover:prose-a:decoration-gosign-accent-text prose-strong:text-gosign-dark prose-ul:text-gosign-text prose-ol:text-gosign-text">

## De proyectos de software a arquitectura de decisiones

Gosign fue fundada en Hamburgo en 2001. Durante más de 25 años hemos desarrollado sistemas de software complejos para medianas y grandes empresas - en más de 5.000 proyectos para empresas como Airbus, Volkswagen, Shell.

Nuestras raíces están en el software enterprise clásico: integración de sistemas, plataformas individuales, desarrollo cercano a ERP y arquitecturas orientadas a la seguridad. Con la aparición de la IA generativa, comenzamos a probar workflows basados en LLM en entornos empresariales reales - primero experimentalmente, luego en producción en configuraciones enterprise basadas en Azure.

Hoy construimos Enterprise AI Agents y la infraestructura que los hace responsables: el [Decision Layer](/es/decision-layer/), que descompone cada proceso en pasos de decisión individuales y define para cada paso: humano, conjunto de reglas o IA.


## Lo que representamos

### Calidad de decisión antes de automatización

Las empresas rara vez fracasan por falta de herramientas. Fracasan por lógica de decisión inconsistente. Las decisiones de HR y finanzas en muchas organizaciones no están versionadas, no son reproducibles y dependen del conocimiento de personas individuales. Nuestra arquitectura hace la lógica de decisión explícita, trazable y auditable - como capa técnica, no como consultoría organizacional.

### Governance by Design

El compliance no es un proceso posterior en nuestro caso. Nuestros agentes se construyen de manera que la lógica de decisión esté versionada, el [Human-in-the-Loop](/es/governance/) esté arquitectónicamente anclado, los Audit Trails se generen automáticamente y los controles existan como objetos de datos. Cuando se requiere una certificación, el sistema está estructuralmente preparado para ello.

Más en nuestras [páginas de Governance](/es/governance/).

### Integración en vez de reemplazo

No reemplazamos sistemas existentes. SAP sigue siendo ERP. Workday sigue siendo plataforma HR. SuccessFactors sigue siendo líder. Complementamos estos sistemas con una capa de decisión y governance - el Decision Layer, que hace a los agentes auditables y controlables.


## Cómo trabajamos

### Co-Build con departamentos especializados

Cada empresa tiene su propia lógica de compensación, sus propios convenios colectivos, sus propios requisitos de governance y sus propias estructuras ERP. Por eso desarrollamos [AI Agents](/es/servicios/ai-agents/) en Co-Build con HR, Finance e IT - no como producto terminado, sino configurado según los procesos y reglas específicos de la empresa.

### Acceso completo al código fuente

Nuestras soluciones funcionan en la [infraestructura del cliente](/es/servicios/infraestructura/) - en Azure, GCP, AWS o Self-Hosted. Sin modelo SaaS propietario, sin vendor lock-in. Acceso completo al código fuente, configuraciones y conjuntos de reglas. La transferencia a operación propia después de 12-18 meses es parte del modelo.

Gosign deliberadamente no es un modelo de dependencia.


## Tecnologías

<div class="not-prose text-body text-gosign-text leading-relaxed">
<a href="https://www.python.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Python</a>, <a href="https://www.typescriptlang.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">TypeScript</a>/<a href="https://nodejs.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Node.js</a>, <a href="https://go.dev/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Go (Golang)</a> - Frontend: <a href="https://react.dev/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">React</a>, <a href="https://nextjs.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Next.js</a>, <a href="https://vuejs.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Vue</a> - Base de datos: <a href="https://www.postgresql.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">PostgreSQL</a>, <a href="https://supabase.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Supabase</a> - Orquestación: <a href="https://trigger.dev" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Trigger.dev</a>, <a href="https://camunda.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Camunda</a>, <a href="https://airflow.apache.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Airflow</a> - Contenedores: <a href="https://www.docker.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Docker</a>, <a href="https://kubernetes.io/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Kubernetes</a> - Cloud: <a href="https://azure.microsoft.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Azure</a>, <a href="https://cloud.google.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">GCP</a>, <a href="https://aws.amazon.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">AWS</a> - On-Premise: <a href="https://github.com/vllm-project/vllm" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">vLLM</a>, <a href="https://ollama.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Ollama</a>
</div>


## Certificaciones y competencias

Nuestro equipo combina más de 25 años de experiencia enterprise con certificaciones actuales en cloud e IA. Nuestros ingenieros de IA están certificados en Microsoft Azure AI y trabajan diariamente con APIs de LLM, frameworks de orquestación y sistemas de integración empresarial.

<a href="https://www.bvdw.org/en/committees/artificial-intelligence/" target="_blank" rel="noopener noreferrer" class="not-prose flex items-center gap-4 group mt-6">
<img src="/images/badges/bvdw-mitglied.png" alt="Miembro BVDW" width="349" height="428" class="w-16 h-16 object-contain opacity-60 group-hover:opacity-100 transition-opacity" loading="lazy" />
<span class="text-body text-gosign-text-light group-hover:text-gosign-accent transition-colors">Miembro de la Asociación Federal Alemana de Economía Digital (BVDW)</span>
</a>



## Quiénes somos

Gosign es una empresa dirigida por sus propietarios. 108 empleados en oficinas en Hamburgo, Berlín, Cracovia, Barcelona, Lisboa y São Paulo. Nuestro mayor centro de desarrollo opera en Pakistán desde 2002 - fundado como escuela de programación, hoy un hub de ingeniería establecido con estrechos vínculos con las facultades de informática de las universidades de Karachi, Lahore e Islamabad.

<div class="flex flex-col md:flex-row gap-12 not-prose my-8">
<div class="flex-1 text-center">
<img src="/images/team/bert-gogolin.webp" alt="Bert Gogolin, Director General Gosign GmbH" width="400" height="400" class="w-48 h-48 lg:w-56 lg:h-56 rounded-full object-cover mx-auto mb-6 border-4 border-gosign-light" />
<h3 class="text-h3 font-bold text-gosign-dark">Bert Gogolin</h3>
<p class="text-body text-gosign-text-light">Director General</p>
<a href="https://www.linkedin.com/in/bert-gogolin/" class="inline-flex items-center gap-1 text-small text-gosign-text-light hover:text-gosign-accent mt-2 transition-colors" target="_blank" rel="noopener noreferrer">
<svg class="w-4 h-4" fill="currentColor" viewBox="0 0 24 24"><path d="M20.447 20.452h-3.554v-5.569c0-1.328-.027-3.037-1.852-3.037-1.853 0-2.136 1.445-2.136 2.939v5.667H9.351V9h3.414v1.561h.046c.477-.9 1.637-1.85 3.37-1.85 3.601 0 4.267 2.37 4.267 5.455v6.286zM5.337 7.433a2.062 2.062 0 01-2.063-2.065 2.064 2.064 0 112.063 2.065zm1.782 13.019H3.555V9h3.564v11.452zM22.225 0H1.771C.792 0 0 .774 0 1.729v20.542C0 23.227.792 24 1.771 24h20.451C23.2 24 24 23.227 24 22.271V1.729C24 .774 23.2 0 22.222 0h.003z"/></svg>
LinkedIn
</a>
</div>
<div class="flex-1 text-center">
<img src="/images/team/dieter-gogolin.webp" alt="Dieter Gogolin, Director General Gosign GmbH" width="400" height="400" class="w-48 h-48 lg:w-56 lg:h-56 rounded-full object-cover mx-auto mb-6 border-4 border-gosign-light" />
<h3 class="text-h3 font-bold text-gosign-dark">Dieter Gogolin</h3>
<p class="text-body text-gosign-text-light">Director General</p>
</div>
</div>

Bert lidera las relaciones con clientes: desde el análisis inicial hasta el mapeo de procesos y las decisiones arquitectónicas. Dieter es responsable del desarrollo operativo y estratégico - desde la infraestructura y los equipos internacionales hasta la estrategia de alianzas.


## Por qué hacemos esto

La IA generativa está cambiando cómo se preparan, documentan y rinden cuentas las decisiones. Estamos convencidos de que los agentes de IA solo escalan productivamente cuando el governance está estructuralmente integrado, la lógica de decisión se hace explícita y las personas permanecen conscientemente involucradas.

Para eso construimos la [infraestructura](/es/servicios/infraestructura/).

Todos los datos de la empresa de un vistazo: [Datos y cifras](/es/datos/)

</div>
</div>
</article>

--- a21glossary TYPO3 - Glosario | Gosign ---
> Extensión de glosario clásica para TYPO3. Marca automáticamente términos en el contenido y los enlaza a un glosario.

## Quien necesita un glosario suele tener un problema de SEO

Explicar términos especializados en un sitio web parece un servicio al usuario. En realidad, a21glossary resuelve un problema técnico concreto: las páginas TYPO3 con contenido que requiere explicaciones posicionan mejor cuando los términos están enlazados internamente, son indexables como páginas propias y accesibles mediante tooltip. La extensión genera enlaces automáticos en el contenido a partir de una base de datos central de términos, sin que los redactores tengan que colocar cada enlace manualmente.

Para empresas con portales especializados, plataformas de conocimiento o productos que requieren explicación, a21glossary crea exactamente la estructura de enlazado interno que Google valora como autoridad temática. En lugar de ocultar 50 términos en una FAQ, se generan 50 páginas independientes e indexables con potencial de Schema Markup.

## Escenarios de uso habituales

**Portales especializados con más de 100 términos.** Asociaciones sectoriales, universidades y editoriales especializadas mantienen glosarios con cientos de entradas. a21glossary enlaza cada término automáticamente en su primera mención en el texto corrido. En un cliente con 340 entradas de glosario, la densidad de enlazado interno aumentó un 28%, medible a través de Google Search Console.

**Páginas de producto con vocabulario técnico.** Fabricantes de maquinaria, empresas químicas y fabricantes de tecnología médica utilizan terminología que los compradores y responsables de decisión no siempre conocen. Un tooltip con 2-3 frases de explicación mantiene al lector en la página en lugar de enviarlo a Google. El tiempo de permanencia sube, la tasa de rebote baja.

**Plataformas de conocimiento multilingües.** En combinación con la gestión de idiomas de TYPO3, se pueden mantener glosarios por idioma. Los términos en alemán enlazan a explicaciones en alemán, los ingleses a explicaciones en inglés. Esto funciona correctamente siempre que la configuración de idiomas en TYPO3 esté bien configurada.

## Arquitectura técnica

a21glossary funciona como post-procesador de contenido. Después del renderizado de una página TYPO3, la extensión busca en la salida HTML los términos definidos y los sustituye por variantes enlazadas. Los propios términos se almacenan en una tabla de base de datos propia y se gestionan mediante un módulo de backend.

La extensión se registra a través de un Hook Content Object Post User Func en el proceso de renderizado TypoScript. Esto significa que interviene solo después de que TYPO3 haya renderizado completamente el contenido. Por eso funciona independientemente del tipo de elemento de contenido utilizado, ya sea Textmedia, News o Custom Content Elements.

La presentación del tooltip se realiza mediante un pequeño snippet de JavaScript y CSS. Ambos son personalizables. En configuraciones modernas de TYPO3, se recomienda sustituir el JavaScript estándar por una solución solo CSS para no perjudicar los Core Web Vitals. Con el atributo `title` y un selector `:hover` se pueden crear tooltips sencillos sin una sola línea de JavaScript.

Las propias entradas del glosario son configurables mediante TypoScript: qué páginas deben ser analizadas, cuántas veces puede enlazarse un término por página (recomendado: una vez) y qué áreas HTML están excluidas (navegación, footer, otras entradas del glosario).

## Problemas frecuentes y soluciones

**Caída de rendimiento con glosarios grandes.** A partir de aproximadamente 500 términos, el paso de post-procesamiento puede hacerse perceptible, especialmente en páginas con mucho texto. La solución: activar la caché. La caché de páginas de TYPO3 almacena el resultado tras el primer renderizado. Solo al vaciar la caché se vuelve a procesar. Además, ayuda reducir la lista de términos al vocabulario realmente utilizado. 200 términos precisos superan a 800 incluyendo variantes.

**Enlaces incorrectos en encabezados y enlaces.** a21glossary enlaza por defecto en todas partes, también dentro de etiquetas H2 o hiperenlaces existentes. Esto produce enlaces anidados que son HTML inválido. A través de la configuración TypoScript se pueden excluir etiquetas: `excludeTags = h1,h2,h3,a,script`. Esta configuración es imprescindible en toda instalación inicial.

**Conflictos con RealURL y Routing.** En versiones antiguas de TYPO3 (anteriores a v9) surgían problemas cuando las páginas de detalle del glosario se enrutaban a través de RealURL. Con TYPO3 v10+ y el Site Routing nativo, este problema ya no existe. Quien aún use RealURL debería migrar de todos modos.

## Migración y compatibilidad de versiones

a21glossary fue desarrollada originalmente para TYPO3 v4.x y se ha actualizado a lo largo de los años. La última versión mantenida activamente en el TER soporta TYPO3 v10 y v11. Para TYPO3 v12 existe un fork comunitario en GitHub que porta la extensión a la nueva estructura TCA y al sistema de Hooks modificado. Para TYPO3 v13 no hay versión oficial disponible en este momento.

La migración de v11 a v12 requiere tres ajustes: primero, el cambio de `$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']` al nuevo sistema Event Dispatcher; segundo, la actualización de las definiciones TCA (configuración de Wizards); y tercero, la adaptación del setup TypoScript a la nueva Site Configuration.

Quien planifique TYPO3 v13 se enfrenta a una decisión: continuar desarrollando el fork comunitario o migrar a una solución alternativa. Como alternativa se ofrece implementar la funcionalidad de glosario directamente como Custom Content Element con DataProcessor. El esfuerzo es de aproximadamente 2-3 días de desarrollo, el resultado es seguro para el futuro e independiente del mantenimiento de terceros. Gosign ha realizado esta migración en varios proyectos y puede estimar de forma realista el esfuerzo real basándose en un análisis de los datos de glosario existentes.

--- aimeos TYPO3 - Tienda E-Commerce | Gosign ---
> aimeos: el framework líder de comercio electrónico para TYPO3. Tienda completa, catálogo, carrito, checkout. Acelerado con IA.

## Quien necesita una tienda dentro de TYPO3 difícilmente puede evitar aimeos

Empresas que ya operan una web TYPO3 y quieren añadir comercio electrónico se enfrentan a una decisión fundamental: sistema de tienda separado (Shopware, Magento, WooCommerce) con interfaz hacia el CMS, o framework nativo de e-commerce dentro de TYPO3. aimeos es la segunda opción y desde hace más de 10 años el framework de tienda más establecido para TYPO3. Más de 200.000 instalaciones a nivel mundial (datos de Packagist, 2026), desarrollo activo y soporte para TYPO3 v12 y v13 respaldan su estabilidad.

La ventaja decisiva: contenido y comercio funcionan en el mismo sistema. Las páginas de producto utilizan elementos de contenido TYPO3, las landing pages pueden integrar componentes de tienda y los editores trabajan en una sola interfaz. Con sistemas separados surgen problemas de sincronización, doble mantenimiento y diseño inconsistente.

## Escenarios de uso habituales

**Tiendas B2B con lógica de precios compleja.** Empresas industriales con precios específicos por cliente, descuentos escalonados, cantidades mínimas y flujos de aprobación. aimeos soporta nativamente precios por grupo de clientes, plugins de precios y motores de reglas. Un distribuidor químico con 8.000 artículos y 400 grupos de clientes se puede modelar sin que cada regla de precios quede codificada a fuego.

**Marketplaces y escenarios multi-vendor.** aimeos puede funcionar como backend de marketplace donde varios proveedores gestionan sus productos. Cada vendor administra su surtido, la plataforma gestiona checkout, pago y enrutamiento de envíos. El framework soporta configuraciones multi-tienda donde diferentes storefronts acceden al mismo catálogo pero muestran surtidos y precios distintos.

**Internacionalización desde el primer día.** Empresas con webs en 5 o más idiomas y varias divisas se benefician de que aimeos integra multi-idioma y multi-divisa de forma nativa. Nombres de producto, descripciones y metadatos SEO se gestionan por idioma. Los precios se definen por divisa o se convierten automáticamente.

## Arquitectura técnica

aimeos se basa en una arquitectura MVC propia (Manager, Controller, Client) que se integra como extensión TYPO3. El núcleo es agnóstico de framework y también funciona bajo Laravel y Slim. La capa adaptadora TYPO3 garantiza que los plugins de aimeos se incrusten como elementos de contenido TYPO3.

El catálogo de productos usa una estructura de árbol con anidamiento ilimitado. Los atributos (color, tamaño, material) se gestionan como entidades propias y se ofrecen mediante filtros de facetas. La búsqueda se basa por defecto en búsqueda de texto completo SQL, pero puede cambiarse a Elasticsearch o Solr.

Las integraciones de pago funcionan a través de service providers: Stripe, PayPal, Mollie, Amazon Pay, Klarna y otros están disponibles como plugins. Cada proveedor de pago se accede mediante una API unificada. El proceso de checkout se implementa como pipeline de pasos, ampliable con pasos propios (por ejemplo, verificación de edad, aprobación B2B).

El caché opera en varios niveles: TYPO3 Page Cache para páginas estáticas, caché interno de aimeos para consultas de catálogo y opcionalmente Varnish o Cloudflare como reverse proxy. En catálogos con más de 100.000 artículos, la gestión de índices es decisiva: aimeos crea índices de búsqueda y precios que se actualizan incrementalmente con cada actualización de producto.

## Problemas frecuentes y soluciones

**Caídas de rendimiento con catálogos grandes.** Tiendas con más de 50.000 artículos se vuelven lentas cuando los índices no están actualizados o el caché de catálogo se ha desactivado. Solución: ejecutar `php typo3/sysext/core/bin/typo3 aimeos:jobs` como cronjob (cada 5 minutos para actualizaciones de índices, cada hora para tareas de limpieza). Vaciar manualmente el caché de administración de aimeos tras importaciones masivas.

**Abandonos en el checkout por errores de pago.** Causa frecuente: API keys caducadas o URLs de webhook incorrectas tras un cambio de dominio. Cada proveedor de pago necesita una URL de notificación correcta por la que llegan confirmaciones de pago asíncronas. Solución: revisar las URLs de webhook en el panel del proveedor de pago tras cada migración, realizar pedidos de prueba en modo sandbox.

**Conflictos con el caché de TYPO3.** Las páginas aimeos con carrito o login no deben almacenarse en el Page Cache de TYPO3. Solución: marcar las páginas relevantes como USER_INT o usar aimeos en modo SPA (basado en AJAX). Desde aimeos 2024.x el modo SPA es la recomendación estándar.

## Migración y compatibilidad de versiones

aimeos es compatible con TYPO3 v12 LTS completamente y con TYPO3 v13 desde aimeos 2024.x. Para TYPO3 v11 hay releases de mantenimiento, pero sin nuevas funcionalidades.

La migración desde otros sistemas de tienda es un escenario realista. Desde Shopware, WooCommerce o tt_products se pueden transferir productos, categorías, cuentas de cliente e historial de pedidos a aimeos. Gosign utiliza pipelines de importación CSV/XML donde los datos de producto se transforman y mapean a la estructura de aimeos. Según la calidad de los datos, la migración de una tienda con 5.000 productos toma entre 3 y 10 días.

Otro camino de migración afecta a empresas que hasta ahora han mantenido una tienda Shopware o Magento separada en paralelo a su web TYPO3. La unificación en un solo sistema elimina la complejidad de interfaces: sin sincronización por API REST para datos de producto, sin doble gestión de plantillas, sin despliegues separados. La desventaja: aimeos no cubre todas las funcionalidades de un sistema de tienda dedicado (por ejemplo, Shopware Flow Builder, Magento Page Builder). Sin embargo, la evaluación vale la pena para empresas donde contenido y comercio tienen el mismo peso - no solo cuenta la tienda, sino también el magazín, la base de conocimiento y las páginas de servicio.

Gosign asesora caso por caso si aimeos es la elección adecuada o si un sistema de tienda separado con conexión headless a TYPO3 representa la mejor arquitectura. La decisión depende de tres factores: complejidad del catálogo (variantes, configuradores, bundles), volumen de transacciones (por debajo o por encima de 1.000 pedidos al día) e infraestructura TYPO3 existente (extensiones, plantillas, flujos de redacción).

Un setup aimeos con catálogo de productos, carrito, pago con Stripe y PayPal, cálculo de envío y plantillas base se estima en 15 a 25 días de desarrollo. Temas personalizados, lógica de precios compleja o funcionalidades de marketplace incrementan el esfuerzo proporcionalmente. La operación continua requiere actualizaciones regulares (aimeos y plugins de proveedores de pago), así como monitorización del rendimiento del checkout y la tasa de conversión.

--- Amazon Pay TYPO3 - Payment | Gosign ---
> Amazon Pay en TYPO3: checkout con cuenta de Amazon. Integración de API, certificación, acelerado con IA.

## Amazon Pay reduce los abandonos de compra porque los clientes no necesitan crear una cuenta nueva

El 70 % de los compradores online en Europa tienen una cuenta de Amazon. Cuando estos usuarios pulsan "Comprar" en una tienda TYPO3 y ven un formulario de registro con 12 campos obligatorios, muchos abandonan. Amazon Pay resuelve este problema: el cliente se autentica con su cuenta de Amazon, la dirección de envío y el medio de pago se transfieren automáticamente. Sin formulario, sin número de tarjeta, sin nueva contraseña. Según los propios case studies de Amazon, la tasa de conversión aumenta entre un 15 y un 30 %, dependiendo del sector y la calidad del checkout existente.

Para operadores de tiendas TYPO3, la integración no es plug-and-play. Amazon Pay requiere una conexión API (Login with Amazon, Amazon Pay API v2), una implementación certificada y actualizaciones de seguridad periódicas. Amazon verifica cada integración antes del go-live.

## Escenarios de uso habituales

**Tiendas B2C de tamaño medio con aimeos.** Tiendas online de moda, electrónica o artículos para el hogar que quieren ofrecer un tercer método de pago junto a PayPal y tarjeta. Amazon Pay funciona especialmente bien en compras impulsivas por debajo de 200 euros, donde cada obstáculo en el checkout cuesta facturación directamente. La integración en aimeos se realiza mediante un service provider propio que se conecta a la pipeline de pago.

**Plataformas de donaciones y cuotas de membresía.** Asociaciones y ONGs que recaudan donaciones o cuotas a través de su web TYPO3 se benefician de la baja barrera de entrada. El donante pulsa "Pagar con Amazon", confirma el importe y listo. Sin teclear IBAN, sin configurar domiciliación bancaria. Para pagos recurrentes, Amazon Pay soporta Recurring Payments.

**Productos digitales y descargas.** Licencias de software, e-books, cursos online - productos sin envío físico se benefician especialmente porque el proceso completo de compra se completa en menos de 30 segundos. No se necesita dirección de envío, solo autenticación y pago.

## Arquitectura técnica

Amazon Pay v2 se basa en una API REST con payloads JSON. El flujo en una tienda TYPO3: el cliente pulsa el botón de Amazon Pay, es redirigido a Amazon (o se abre un popup), inicia sesión y confirma dirección y medio de pago. Amazon devuelve un Access Token a la tienda. La tienda crea una Checkout Session vía la API de Amazon Pay con datos del carrito y detalles del pedido. Tras la confirmación del cliente, se ejecuta el pago.

La integración en TYPO3 requiere tres componentes: un cliente API (peticiones HTTP a la API de Amazon Pay con firma RSA), un componente frontend (botón Amazon Pay como widget JavaScript) y un handler de webhooks para notificaciones asíncronas (confirmación de pago, reembolso, chargeback).

Para aimeos existe un plugin de la comunidad que cubre las funciones básicas. Para tt_products o tiendas a medida se necesita una integración propia. En ambos casos la tienda TYPO3 debe usar HTTPS (obligatorio desde Amazon Pay v2) y la URL del webhook debe ser accesible desde el exterior.

Amazon proporciona un entorno sandbox donde todos los flujos de pago pueden probarse sin dinero real.

## Problemas frecuentes y soluciones

**La certificación falla en el primer intento.** Amazon verifica antes del go-live que la integración funcione correctamente: ubicación del botón, manejo de errores en pagos rechazados, visualización en móviles, cancelación correcta. Errores frecuentes: el botón de Amazon Pay no aparece en la página de producto (solo en el carrito), faltan mensajes de error por rechazo de pago o están en inglés. Solución: completar la Integration Checklist de Amazon antes de solicitar la revisión.

**Las notificaciones IPN (Instant Payment Notifications) se pierden.** Amazon envía confirmaciones de pago de forma asíncrona por POST a una URL registrada. Si TYPO3 bloquea esas peticiones por caché, reglas de redirección o falta de excepciones CSRF, el pedido se queda en estado "pendiente". Solución: configurar una ruta eID dedicada o middleware que opere fuera del procesamiento normal de peticiones TYPO3.

**Pagos recurrentes y modelos de suscripción.** Amazon Pay soporta pagos recurrentes, pero la configuración es más compleja que con Stripe Subscriptions. El cliente debe aceptar explícitamente un Billing Agreement y la tienda debe enviar regularmente peticiones Authorize. Solución: gestionar los Billing Agreements como entidad propia en base de datos y configurar un cronjob que active los pagos vencidos.

## Migración y compatibilidad de versiones

Amazon Pay v2 es la versión actual de la API (desde 2021). La versión 1 ya no se acepta para nuevas integraciones desde finales de 2023. Las implementaciones v1 existentes siguen funcionando pero no reciben actualizaciones ni nuevas funcionalidades. La migración de v1 a v2 afecta al cliente API completo: otros endpoints, otro mecanismo de firma (RSA en lugar de HMAC), otra gestión de sesiones.

Para TYPO3 no existe una extensión oficial de Amazon Pay en el TER con soporte activo para v12/v13. La integración se realiza como código a medida o mediante plugins de la comunidad para aimeos. Gosign implementa Amazon Pay como paquete Composer independiente que se integra en cualquier configuración de tienda TYPO3. Este paquete encapsula el cliente API, el botón y el handler de webhooks, de modo que un upgrade major de TYPO3 solo afecta a la capa adaptadora específica de TYPO3.

Para operadores de tienda que ofrecen Amazon Pay junto con PayPal, tarjeta y Klarna, Gosign recomienda una abstracción de pago unificada. En lugar de integrar cada proveedor individualmente, se implementa una interfaz común que gestiona todos los proveedores. aimeos trae esta abstracción de forma nativa (arquitectura de service providers). Para tiendas a medida, Gosign construye una capa comparable que desacopla el código del checkout de las APIs específicas de cada proveedor.

Los costes totales de una integración de Amazon Pay en una tienda TYPO3 existente oscilan entre 3 y 8 días de desarrollo, dependiendo de si se puede usar un plugin de aimeos o es necesaria una integración a medida. La certificación de Amazon requiere adicionalmente de 1 a 2 días para preparación y rondas de corrección.

--- Angular & TYPO3 - Headless CMS | Gosign ---
> Frontend Angular con TYPO3: Headless CMS, JSON-API, integración SPA. Desarrollo acelerado con IA.

## Por qué Angular funciona con TYPO3, pero la mayoría de configuraciones fracasan

La idea suena convincente: TYPO3 entrega contenido como JSON, Angular renderiza el frontend como Single Page Application. Los redactores trabajan en el backend familiar de TYPO3, los desarrolladores construyen un frontend moderno sin las restricciones de TypoScript. En la práctica, muchos proyectos Angular-TYPO3 fracasan en la frontera arquitectónica entre CMS y SPA. La extensión oficial TYPO3 Headless (EXT:headless) resuelve el problema de entrega de contenido. Pero routing, preview, SEO y caché necesitan soluciones bien pensadas que van más allá de un `ng serve`.

Angular como frontend para TYPO3 es adecuado para empresas que necesitan contenido multicanal: un sitio web, una app, un portal de intranet y digital signage desde una única fuente de contenido. El esfuerzo se rentabiliza a partir del segundo canal. Para sitios web puros sin ambición de app, un setup clásico TYPO3-Fluid es casi siempre más eficiente.

## Escenarios de uso habituales

**Plataformas multicanal con app y web.** Un proveedor de automoción mantiene datos de productos, información de servicio y noticias en TYPO3. El sitio web funciona como SPA Angular, la app de servicio para técnicos usa la misma API JSON. Los cambios en TYPO3 aparecen en ambos canales simultáneamente. El contenido se mantiene una vez, se entrega dos veces.

**Portales de intranet con interacción compleja.** Dashboards de RRHH, plataformas de gestión del conocimiento y herramientas internas se benefician del enfoque basado en componentes de Angular. TYPO3 entrega contenido estructurado (políticas, manuales, organigramas), Angular renderiza vistas interactivas con filtros, búsqueda y actualizaciones en tiempo real. La autenticación se ejecuta a través del LDAP/SSO existente, TYPO3 verifica permisos mediante fe_group.

**Configuradores y páginas de producto interactivas.** Fabricantes de productos configurables usan Angular para la vista 3D o el configurador. Los datos maestros del producto provienen de TYPO3, la lógica de configuración vive en el frontend Angular. En un cliente con 1.200 variantes configurables, este enfoque redujo el tiempo de carga de la página del configurador de 4,2 a 1,1 segundos.

## Arquitectura técnica

La extensión TYPO3 Headless transforma la salida estándar de HTML a JSON. Cada elemento de contenido, cada navegación, cada nivel de breadcrumb se entrega como objeto JSON. Angular consume esta API mediante servicios HttpClient.

La arquitectura consta de tres capas. TYPO3 como backend entrega contenido a través de la API Headless bajo `/api/`. Angular como aplicación frontend se compila como proceso de build separado (`ng build --prod`) y normalmente se entrega a través de un CDN o servidor web independiente. Entre ambos se encuentra un servidor SSR basado en Node.js (Angular Universal) que se encarga del Server-Side Rendering para SEO y redes sociales.

El routing es dual: Angular Router gestiona la navegación del lado del cliente, TYPO3 define la estructura de URLs mediante Site Configuration. Ambos deben permanecer sincronizados. En la práctica esto significa: cuando un redactor crea una nueva página en TYPO3, Angular debe conocer esa URL. La solución es un routing dinámico en el frontend Angular que consulta la estructura de páginas desde la API TYPO3 en cada build.

Los servicios TypeScript se generan a partir de los tipos de contenido de TYPO3. Para cada Content Element existe un componente Angular con tipado. Estos tipos se pueden generar mediante script desde la API TYPO3, lo que garantiza la sincronización entre backend y frontend.

## Problemas frecuentes y soluciones

**Deficiencias SEO por renderizado solo del lado del cliente.** Google renderiza JavaScript, pero no de forma fiable ni inmediata. Sin Server-Side Rendering (Angular Universal o Angular SSR desde v17) las páginas se indexan tarde o nunca. La solución: implementar Angular Universal como capa SSR. La respuesta HTML inicial debe estar completamente renderizada antes de que el proceso de hidratación del lado del cliente tome el control.

**La preview de contenido en el backend TYPO3 no funciona.** Los redactores hacen clic en "Vista previa" y ven JSON en lugar de una página renderizada. La solución: configurar un proxy de preview que reenvíe la respuesta JSON a una instancia de preview Angular dedicada. EXT:headless ofrece un modo de preview que entrega contenido borrador a través de un parámetro token.

**Problemas CORS entre la API TYPO3 y el frontend Angular.** Cuando TYPO3 y Angular funcionan en dominios diferentes, el navegador bloquea las peticiones API. La extensión EXT:cors o un reverse proxy del lado del servidor resuelve este problema. Recomendado: operar ambos bajo el mismo dominio (TYPO3 bajo `/api/`, Angular bajo `/`).

## Migración y compatibilidad de versiones

EXT:headless es oficialmente compatible con TYPO3 v11, v12 y v13. La extensión se mantiene activamente y sigue el ciclo de releases de TYPO3. Angular tiene su propio ritmo de releases: cada 6 meses una nueva versión major. Desde Angular v17, SSR está integrado nativamente (ya no se necesita un paquete separado Angular Universal).

Para proyectos Angular-TYPO3 existentes en TYPO3 v10 o anterior, se recomienda una migración por fases: primero actualizar TYPO3 a v12 o v13, luego Angular a la versión LTS actual (v18). La interfaz API de EXT:headless ha cambiado entre v2 y v4 en varios puntos, especialmente en el tratamiento de los language overlays y workspace previews.

El esfuerzo de un proyecto Angular-TYPO3 es típicamente un 30-50% superior al de un proyecto Fluid puro. Este esfuerzo adicional se recupera con el segundo canal (app, intranet). Gosign asesora antes del inicio del proyecto sobre si Headless es el enfoque adecuado o si un setup clásico con islas JavaScript específicas cumple el mismo propósito.

--- Amazon S3 TYPO3 - Cloud Storage FAL | Gosign ---
> Amazon S3 como driver FAL para TYPO3. Almacenar archivos en la nube en lugar del servidor web.

## aus_driver_amazon_s3 es la solución estándar cuando los activos de TYPO3 ya no pueden estar en el servidor web, la extensión incorpora los buckets S3 como driver FAL de pleno derecho en el stack TYPO3

Una configuración TYPO3 clásica guarda todos los datos de media en fileadmin dentro del servidor web. Eso funciona mientras el proyecto corre en una única máquina y el almacenamiento es suficiente. Pero en cuanto entran en juego configuraciones multi-servidor, clústeres de contenedores, autoescalado o Content Delivery Networks, ese modelo se rompe. Cada instancia necesitaría una copia idéntica de todos los archivos, la sincronización se convierte en una obra permanente y los despliegues se vuelven lentos. aus_driver_amazon_s3 lo resuelve integrando Amazon S3 como storage FAL externo. Los archivos están en el bucket, TYPO3 los lee y los escribe mediante la API de S3, y cada instancia de servidor accede al mismo fondo de datos consistente. Para proyectos con requisitos de alta disponibilidad, ese es el camino estándar.

Junto a la necesidad técnica de las configuraciones multi-servidor hay un segundo motivador importante: backup y redundancia. S3 almacena cada archivo automáticamente de forma múltiple repartido entre distintos centros de datos y alcanza así una persistencia de datos que un servidor web clásico no puede garantizar. Para empresas cuyos datos media son críticos para el negocio, ese es ya por sí solo un motivo para cambiar a S3.

## Escenarios típicos de uso

El primer caso son despliegues cloud-native en AWS, Kubernetes o Docker Swarm. TYPO3 corre en varios contenedores detrás de un balanceador de carga, cada contenedor es sin estado. fileadmin como directorio local significaría que las subidas acaban solo en un contenedor y los demás no las ven. aus_driver_amazon_s3 mantiene el inventario de activos central y hace practicable el scale out.

El segundo caso son proyectos con volúmenes de datos muy grandes. Una plataforma de medios, un archivo de imágenes o un portal de descargas crece rápido a varios cientos de gigabytes o terabytes. El almacenamiento local en servidor se vuelve caro y poco flexible, S3 escala de forma transparente y cuesta solo lo que realmente se ocupa. La conexión mediante FAL permite cambiar a nuevo storage sin cambios de código en TYPO3.

Tercer uso: integración con CDN. Quien quiera entregar imágenes y descargas a través de Cloudfront, Cloudflare o un CDN propio utiliza S3 como origen. aus_driver_amazon_s3 hace disponibles los archivos directamente en el bucket, TYPO3 genera las URLs correctas y el CDN las cachea globalmente. Eso mejora medible los tiempos de carga para visitantes internacionales.

## Arquitectura técnica

aus_driver_amazon_s3 implementa el FAL Driver Interface de TYPO3 y utiliza el AWS SDK for PHP oficial para la comunicación con S3. Cada bucket se configura como "File Storage" propio en el backend de TYPO3, con indicación de nombre de bucket, región, Access Key y Secret Key. Alternativamente pueden usarse roles IAM si TYPO3 corre en una instancia EC2 o en una tarea ECS, lo que es más limpio porque no deja credenciales estáticas en la configuración.

La extensión soporta tanto Amazon S3 como servicios compatibles con S3 como MinIO, Backblaze B2, DigitalOcean Spaces o Scaleway Object Storage. Para proyectos que por motivos de protección de datos no pueden alojarse en AWS, esa flexibilidad es importante: un proveedor europeo compatible con S3 se comporta desde el punto de vista de TYPO3 exactamente como el servicio de AWS. La AEPD y otras agencias autonómicas de protección de datos advierten del uso de proveedores estadounidenses tras la sentencia Schrems II.

En operación, TYPO3 lee y escribe directamente contra S3. Los processed files, es decir, las variantes de imagen recortadas y optimizadas, se guardan por defecto también en el bucket. Alternativamente puede configurarse un directorio local para processed files, lo que acelera el procesamiento de imágenes porque GIFBUILDER no tiene que tirar primero cada imagen fuente desde S3.

La configuración se realiza mediante el módulo backend "File Storages" y ajustes TypoScript complementarios para la URL del bucket y los prefijos de CDN. Los desarrolladores deben además instalar la dependencia del AWS SDK mediante Composer y establecer los permisos correctos en el bucket.

## Problemas frecuentes y soluciones

El primer problema es el rendimiento con listas de muchas imágenes. Cuando una página debe recortar docenas de imágenes simultáneamente y los archivos fuente se tiran de S3, el montaje de la página se alarga perceptiblemente. La solución está en un caché local para processed files, eventualmente combinado con un script de pre-warming que, tras nuevas subidas, genere por adelantado las variantes más habituales.

Segundo problema: errores de permisos al subir. Cuando TYPO3 quiere escribir en el bucket pero la IAM Policy solo permite lectura, la subida aborta con un mensaje de error críptico. La solución es una policy precisa con s3:GetObject, s3:PutObject, s3:DeleteObject y s3:ListBucket para exactamente el bucket de TYPO3, idealmente limitada a un prefijo para que otras aplicaciones sobre el mismo bucket no se vean afectadas por error.

Tercer problema: protección de datos y elección de región. Los proyectos que deben trabajar conforme al RGPD deberían elegir regiones AWS en la UE, típicamente eu-central-1 en Fráncfort o eu-west-1 en Irlanda. Para requisitos más altos o clientes que excluyan AWS por principio, un proveedor europeo compatible con S3 como Hetzner, IONOS o Scaleway es el camino adecuado. La extensión trabaja con todos esos proveedores.

## Migración y compatibilidad de versiones

aus_driver_amazon_s3 es compatible con TYPO3 v11, v12 y v13 y se sigue desarrollando activamente. En los upgrades hay que atender a la versión del AWS SDK: las versiones más nuevas de TYPO3 suelen exigir versiones SDK actuales que, a su vez, requieren PHP 8.1 o superior.

Una migración de un fileadmin local a S3 es un proyecto claramente delimitable: copiar inicialmente los archivos al bucket mediante aws s3 sync, configurar una nueva File Storage en el backend de TYPO3, derivar mediante script los registros sys_file existentes al nuevo storage, eliminar los archivos locales tras una prueba exitosa. La extensión no trae una rutina de migración lista, porque el procedimiento concreto es específico del proyecto.

En proyectos existentes rige, antes de la migración, la obligación de inventariar. ¿Cuántos archivos hay en fileadmin, qué tamaño tiene el inventario, cuáles son huérfanos y cuáles siguen realmente enlazados? A menudo las auditorías revelan que una gran parte de los datos antiguos ya no se consulta y que la migración puede limitarse a los archivos usados activamente. Eso reduce riesgo, esfuerzo y costes de bucket.

Gosign acompaña migraciones S3 para proyectos TYPO3 y diseña arquitecturas multi-cloud que cumplen los requisitos de protección de datos y los objetivos de rendimiento simultáneamente.

--- Azure Storage TYPO3 - Cloud FAL | Gosign ---
> Azure Blob Storage como driver FAL de TYPO3. Almacenar archivos en la nube de Microsoft. Equivalente a aus_driver_amazon_s3 para infraestructuras Azure...

## Las empresas con stack Microsoft necesitan Azure Storage en lugar de sistemas de archivos locales

Cuando el panorama TI funciona sobre Azure, Active Directory gestiona los usuarios y SharePoint aloja los documentos, entonces el sistema de archivos de TYPO3 también pertenece a la nube Azure. EXT:azurestorage integra Azure Blob Storage como driver FAL (File Abstraction Layer) en TYPO3. Los redactores no notan diferencia, pero los archivos residen en la infraestructura cloud de Microsoft con CDN, geo-redundancia y almacenamiento prácticamente ilimitado en lugar del servidor web.

Esta extensión es el equivalente Azure de EXT:aus_driver_amazon_s3. La decisión entre ambas rara vez es técnica, sino que se toma en función de la estrategia cloud existente. Quien ya utiliza Azure ahorra complejidad, contratos y costes de red permaneciendo en el ecosistema Microsoft.

## Escenarios de uso habituales

**Sitios web enterprise con configuración multi-servidor.** Las grandes instalaciones TYPO3 funcionan en varios servidores web detrás de un balanceador de carga. Sin almacenamiento cloud, los archivos deben sincronizarse entre servidores mediante rsync, NFS o GlusterFS. Cada una de estas soluciones trae sus propios problemas. Azure Blob Storage como driver FAL hace innecesaria la sincronización de archivos: todos los servidores acceden al mismo Blob Container. En un cliente con 4 servidores web y 180.000 archivos, la migración a Azure eliminó toda la infraestructura NFS.

**Portales con contenido multimedia y audiencia global.** Empresas con clientes en Europa, Asia y Norteamérica necesitan tiempos de carga rápidos en todo el mundo. Azure CDN entrega imágenes y descargas a través de servidores edge en más de 130 ciudades. La integración se realiza mediante la configuración del endpoint CDN en el portal Azure, TYPO3 genera automáticamente las URLs CDN correspondientes.

**Requisitos de cumplimiento sobre almacenamiento de datos.** Algunos sectores exigen que los archivos se almacenen en un país determinado. Azure ofrece centros de datos en Frankfurt, Zúrich y Viena. A través de la configuración del Storage Account se puede definir exactamente dónde residen físicamente los datos. Esto es una ventaja frente a proveedores genéricos compatibles con S3, donde la configuración geográfica suele ser opaca.

## Arquitectura técnica

EXT:azurestorage implementa la interfaz TYPO3 FAL Driver. La extensión se registra como driver en el File Abstraction Layer y sobrescribe las operaciones estándar del sistema de archivos (lectura, escritura, eliminación, listado) con llamadas a la API de Azure Blob Storage.

La configuración se realiza a través de los ajustes de File Storage de TYPO3 en el backend. Se crea un nuevo objeto Storage con el driver "Azure Blob Storage". Las credenciales de acceso (Storage Account Name, Access Key o SAS Token) se almacenan en la configuración del Storage. Recomendado: SAS Token con validez limitada y permisos de lectura/escritura en lugar del Master Access Key.

La comunicación entre TYPO3 y Azure se produce a través de la Azure Storage REST API. Las subidas se almacenan como Block Blobs, los archivos grandes (más de 256 MB) se dividen automáticamente en bloques. Para la integración del lado PHP, la extensión utiliza el Azure SDK for PHP o una implementación ligera de cliente REST.

Las imágenes se procesan según sea necesario mediante el Image Processing de TYPO3 (GraphicsMagick/ImageMagick). Las variantes procesadas también se almacenan en Azure, normalmente en un contenedor separado (_processed_). El almacenamiento en caché de los archivos procesados reduce el tiempo de procesamiento en solicitudes repetidas.

## Problemas frecuentes y soluciones

**Rendimiento lento del backend al navegar directorios grandes.** Azure Blob Storage no tiene una estructura de directorios real, sino que la emula mediante prefijos de ruta. Listar 10.000 archivos en una "carpeta" requiere paginación de API y tarda notablemente más que en un sistema de archivos local. La solución: configurar correctamente el indexador FAL de TYPO3 y actualizar el índice regularmente, en lugar de consultar Azure en vivo con cada acceso al backend.

**El procesamiento de imágenes falla.** TYPO3 debe descargar imágenes para procesarlas, procesarlas y volver a subirlas. Con una conexión inestable o imágenes grandes (archivos TIFF de 200 MB), el proceso se interrumpe. Solución: realizar el procesamiento en el servidor con un directorio temporal local y subir solo el resultado. La configuración `processingFolder` debe apuntar a una ruta local.

**Explosión de costes por llamadas API innecesarias.** Cada acceso a archivos es una llamada API, y Azure factura por cada 10.000 transacciones. Un indexador TYPO3 mal configurado puede generar miles de llamadas por minuto. Configurar monitorización a través de Azure Cost Management y cambiar el indexador FAL a intervalos basados en Scheduler (en lugar de tiempo real).

## Migración y compatibilidad de versiones

EXT:azurestorage es un producto nicho con comunidad limitada. Las versiones disponibles en el TER y en Packagist soportan TYPO3 v10 y v11. Para v12 existen forks en GitHub con diferentes niveles de madurez. Para TYPO3 v13 no hay actualmente una solución lista.

La alternativa para v12/v13: EXT:aus_driver_amazon_s3 con un endpoint Azure compatible con S3. Azure Blob Storage ofrece desde 2020 una capa API compatible con S3. Así se puede utilizar la extensión S3, más consolidada y mejor mantenida, también con Azure. La configuración requiere un Azure Storage Account con la función "S3-Compatible API" activada y la configuración de la extensión S3 con el endpoint Azure.

Quien migre de un sistema de archivos local a Azure debe planificar la mudanza en tres fases: primero subir los archivos existentes al Blob Container mediante AzCopy o Storage Explorer, segundo cambiar la configuración de File Storage de TYPO3, y tercero reconstruir el índice FAL. Con 50.000 archivos, todo el proceso dura típicamente un día laborable. Gosign ha realizado migraciones Azure para proyectos TYPO3 con hasta 400.000 archivos y asesora tanto sobre la extensión nativa como sobre la solución compatible con S3.

--- be_acl TYPO3 - Permisos de backend | Gosign ---
> Extensión de listas de control de acceso para el backend de TYPO3. Permisos granulares más allá de lo que permite el Core de TYPO3.

## Cuando más de tres redactores trabajan, los permisos estándar de TYPO3 ya no son suficientes

TYPO3 trae un sistema de permisos: grupos de backend, accesos a páginas, derechos sobre tablas. Para equipos pequeños con un puñado de redactores funciona. Pero cuando un sitio web corporativo es mantenido por 15 redactores de 4 departamentos, el sistema estándar alcanza sus límites. be_acl amplía TYPO3 con Access Control Lists granulares que regulan quién puede ver, editar o eliminar qué contenidos en qué página, hasta el nivel de campo.

La extensión no es un complemento opcional, sino un requisito previo para cualquier configuración multi-redacción con más de una zona de responsabilidad. Sin be_acl, los conceptos de permisos en TYPO3 terminan regularmente en una maraña de docenas de grupos que nadie puede supervisar.

## Escenarios de uso habituales

**Sitios web corporativos con responsabilidad departamental.** Marketing mantiene la página de inicio y las páginas de campañas, RRHH la página de empleo, los departamentos especializados sus páginas de producto. Cada departamento debe ver y editar solo sus propias páginas. El sistema estándar de TYPO3 permite accesos a páginas mediante Mount Points y derechos de grupo, pero la configuración se vuelve inmanejable con más de 10 departamentos. be_acl simplifica esto mediante ACLs basadas en páginas: en cada página del árbol de páginas se puede definir directamente qué grupo tiene qué derechos.

**Instalaciones TYPO3 multi-tenant.** Agencias y corporaciones operan múltiples sitios web en una sola instancia TYPO3. El mandante A no debe ver al mandante B, ni siquiera en el árbol de páginas. be_acl implementa esta separación sin necesidad de operar una instalación TYPO3 separada para cada mandante. En una agencia con 12 mandantes en una instancia TYPO3, be_acl redujo el tiempo de administración de permisos en aproximadamente un 60%.

**Flujos de aprobación con profundidad de edición limitada.** Proveedores externos o becarios deben editar textos de contenido, pero no subir imágenes, ni mover páginas, ni configurar plugins. be_acl permite derechos a nivel de campo: el usuario ve el campo de texto, pero no los ajustes de diseño ni la configuración del plugin.

## Arquitectura técnica

be_acl amplía el sistema de permisos del backend de TYPO3 con una capa ACL que se sitúa entre el sistema de derechos del Core y la interacción del usuario. La extensión almacena reglas de permisos en la tabla `tx_beacl_acl`, que define por página y por grupo qué operaciones están permitidas.

El sistema trabaja con tres niveles de derechos: lectura (show), edición (edit) y eliminación (delete). Estos derechos se asignan por página o recursivamente para un subárbol de páginas. La configuración se realiza a través de una pestaña propia en el diálogo de propiedades de página: allí el administrador selecciona un grupo de usuarios y establece los derechos deseados mediante casillas de verificación.

Internamente, be_acl interviene en la `BackendUserAuthentication` de TYPO3 y amplía la comprobación `doesUserHaveAccess`. Con cada acceso a una página en el backend, TYPO3 comprueba primero los derechos estándar y luego las reglas ACL. Las reglas ACL pueden ampliar los derechos estándar, pero no restringirlos. Este es un detalle arquitectónico importante: si un grupo ya tiene acceso a través de los derechos estándar, be_acl no puede revocarlo.

La resolución de derechos sigue una cascada: derechos de usuario prevalecen sobre derechos de grupo, derechos de grupo prevalecen sobre derechos de subgrupo, y ACLs específicas de página prevalecen sobre ACLs heredadas recursivamente. Esta cascada funciona de forma fiable siempre que la estructura de grupos se mantenga plana. A partir de 4 niveles de grupos anidados, el comportamiento se vuelve difícil de predecir.

## Problemas frecuentes y soluciones

**Los permisos no funcionan como se esperaba.** Causa más frecuente: el usuario es miembro de varios grupos, y los derechos de un grupo sobrescriben la restricción ACL de otro. El sistema de derechos de TYPO3 funciona de forma aditiva, es decir, el usuario recibe la suma de todos los derechos de sus grupos. Solución: crear una matriz de permisos, documentar todos los grupos de un usuario y eliminar solapamientos.

**Problemas de rendimiento con árboles de páginas grandes.** En instalaciones TYPO3 con más de 5.000 páginas y más de 20 grupos de usuarios, la comprobación ACL puede ralentizar notablemente el árbol de páginas en el backend. La extensión comprueba la tabla ACL con cada acceso a una página. Solución: activar la caché de las comprobaciones ACL y limitar el árbol de páginas mediante `options.pageTree.excludeDoktypes` a tipos de página relevantes.

**La depuración de derechos es difícil.** TYPO3 no ofrece una herramienta integrada que muestre por qué un usuario puede o no acceder a una página determinada. El área Admin "Backend User" muestra la vista simulada, pero no la cascada de derechos. Solución: analizar el System Log de TYPO3 (con el modo Debug activado, TYPO3 registra los intentos de acceso) o consultar directamente la tabla SQL `tx_beacl_acl`.

## Migración y compatibilidad de versiones

be_acl es una de las extensiones TYPO3 mantenidas desde hace más tiempo. La versión actual soporta TYPO3 v11 y v12. Para TYPO3 v13 existe una versión beta basada en el nuevo sistema de módulos de backend. La extensión se desarrolla activamente en GitHub, los mantenedores responden a los issues.

En la migración de TYPO3 v11 a v12, las reglas ACL no necesitan migrarse manualmente, la tabla de base de datos sigue siendo compatible. Sin embargo, el registro de módulos de backend ha cambiado en v12, por lo que el módulo de configuración de be_acl requiere una actualización de la versión de la extensión.

Para empresas que migran a TYPO3 v13, se recomienda exportar las reglas ACL existentes antes de la actualización. TYPO3 v13 trae un sistema de permisos revisado que incorpora algunas funciones de be_acl en el Core. Si la extensión sigue siendo necesaria a largo plazo depende de la complejidad del concepto de permisos. Gosign analiza el setup ACL existente en las actualizaciones TYPO3 y recomienda la solución óptima, ya sea be_acl, derechos nativos del Core o una combinación.

--- bernetshop TYPO3 - Tienda sencilla | Gosign ---
> Extensión de comercio electrónico más sencilla para TYPO3 que aimeos. Para tiendas más pequeñas con requisitos básicos: lista de productos, carrito.

## No todo shop TYPO3 necesita un framework de e-commerce completo

Aimeos es el estándar para e-commerce en TYPO3. Pero Aimeos también es complejo: su propia capa de abstracción de base de datos, su propio sistema de plantillas, más de 30 tablas de configuración. Para una asociación que vende 8 artículos de merchandising, o una empresa mediana con 50 repuestos, eso es excesivo. bernetshop ofrece una alternativa ligera: listado de productos, carrito de compra, pago, listo. Sin gestión de inventario, sin gestión de almacén, sin capacidad multi-tienda, pero tampoco meses de configuración.

La extensión se dirige a organizaciones que quieren vender pocos productos a través de su sitio web TYPO3 existente, sin operar un sistema de tienda separado. El uso típico: 10-200 productos, variantes sencillas (talla, color), pago por factura, PayPal o Stripe.

## Escenarios de uso habituales

**Asociaciones y organizaciones sin ánimo de lucro.** Clubs deportivos venden camisetas y entradas, instituciones culturales ofrecen abonos anuales y publicaciones. La tienda debe ser fácil de mantener porque la gestionan voluntarios. bernetshop se configura mediante elementos de contenido estándar de TYPO3: un producto es un registro con imagen, precio, descripción y variantes. Sin necesidad de formación más allá de la edición normal de TYPO3.

**Venta de repuestos y accesorios.** Fabricantes de maquinaria y equipos venden piezas de desgaste, accesorios y consumibles a través del sitio web corporativo. Los datos de producto ya existen en TYPO3 (páginas de producto, hojas de datos), bernetshop añade carrito y función de pago. El mantenimiento de productos permanece donde ya residen los datos técnicos: en el CMS.

**Portales de pedidos internos.** Grandes empresas utilizan sistemas de pedidos sencillos para material de oficina, material publicitario o accesorios informáticos. bernetshop con login frontend de TYPO3 crea un portal de pedidos protegido por contraseña sin software externo. Los pedidos se reenvían por email al departamento responsable, una conexión ERP no está prevista y en este contexto no es necesaria.

## Arquitectura técnica

bernetshop se basa en Extbase/Fluid, el framework estándar para extensiones TYPO3. Los datos de producto se almacenan en una tabla propia `tx_bernetshop_domain_model_product`. Las variantes (tallas, colores) se modelan como relaciones inline. El carrito de compra se mantiene en la sesión PHP y opcionalmente se persiste en la base de datos para usuarios registrados.

La lógica de la tienda es manejable: hay controladores para listado de productos, detalle de producto, carrito y checkout. Las plantillas son Fluid estándar y se pueden personalizar como cualquier otra plantilla TYPO3. La gestión de pagos se realiza a través de un adaptador de proveedor de pago: PayPal, Stripe y factura están implementados por defecto. Se pueden añadir proveedores adicionales mediante una interfaz PHP.

Los pedidos se almacenan en una tabla de base de datos y activan un email de confirmación al cliente y al operador de la tienda. Un módulo de backend muestra todos los pedidos con estado (abierto, pagado, enviado). La exportación CSV está integrada, una interfaz directa ERP no.

## Problemas frecuentes y soluciones

**Límites de escalabilidad a partir de 200 productos.** El listado de productos se vuelve lento con un número creciente de productos si no se configura paginación. bernetshop incluye una paginación sencilla, pero no búsqueda facetada ni filtros por categoría. Solución: a partir de 200 productos, crear páginas de categoría y limitar el listado de productos por categoría. A partir de 500 productos, conviene considerar seriamente Aimeos o una tienda externa.

**Integración de pago desactualizada.** Los adaptadores de pago incluidos utilizan parcialmente versiones antiguas de las APIs de los proveedores de pago. La API clásica de PayPal está descontinuada, Stripe ha actualizado su API varias veces. Solución: verificar los adaptadores de pago y actualizarlos a las versiones de API actuales. El esfuerzo por adaptador es de 1-2 días de desarrollo.

**Requisitos legales no completamente cubiertos.** Derecho de desistimiento, indicación de precio base, regulación de envases y los requisitos de información reforzados en e-commerce desde 2024 requieren adaptaciones que bernetshop no ofrece de serie. Solución: completar las plantillas de checkout con la información legalmente requerida. Esto es trabajo de plantillas, no de desarrollo de extensiones.

## Migración y compatibilidad de versiones

bernetshop es una extensión nicho con mantenimiento limitado. La última versión estable soporta TYPO3 v10 y v11. Para TYPO3 v12 no existe actualización oficial, el esfuerzo de portabilidad es asumible (cambios de API Extbase, ajustes TCA), pero debe realizarse manualmente. Para TYPO3 v13 no hay planificación.

Las empresas que migran a TYPO3 v12 o v13 se enfrentan a la decisión: portar bernetshop o cambiar a una alternativa. Las opciones son Aimeos (framework e-commerce completo, esfuerzo significativamente mayor), cart (tienda basada en Extbase con mantenimiento activo y compatibilidad v12) o una tienda externa (Shopify, WooCommerce) con integración TYPO3 vía API.

La migración de datos de producto es en cualquier caso sencilla: la tabla tiene una estructura clara que se puede transferir a cualquier sistema destino mediante script SQL. En un cliente con 85 productos, la migración completa de bernetshop a EXT:cart, incluyendo adaptación de plantillas, llevó 4 días laborables. Gosign asesora sobre la opción más económica y asume la portabilidad o migración según sea necesario.

--- Bilddatenbank TYPO3 - Gestión de activos | Gosign ---
> Base de datos de imágenes en TYPO3: gestión de activos digitales, auto-tagging, búsqueda. Extensión FAL o conexión DAM externa.

## A partir de 5.000 imágenes, el FAL de TYPO3 se convierte en un cuello de botella

El File Abstraction Layer de TYPO3 gestiona archivos de forma fiable mientras la cantidad se mantiene manejable. Con 500 imágenes, FAL funciona perfectamente. Con 5.000, la búsqueda se vuelve lenta. Con 20.000, la lista de archivos en el backend es prácticamente inutilizable. Las empresas con grandes fondos de imágenes necesitan más que un sistema de archivos: necesitan un Digital Asset Management. La cuestión es si ampliar el FAL de TYPO3 para convertirlo en un DAM o conectar un sistema externo.

Ambos caminos funcionan. La ampliación interna mediante extensiones FAL cuesta menos y permanece en el ecosistema TYPO3. La conexión externa (Celum, Canto, Cloudinary, Bynder) ofrece más funciones, pero requiere licencias, mantenimiento de interfaces y lógica de almacenamiento de datos dual.

## Escenarios de uso habituales

**Empresas manufactureras con fotografía de producto.** Un fabricante de maquinaria tiene 8.000 fotos de productos en diferentes resoluciones, además de renderizados CAD, imágenes de aplicación y hojas de datos. Cada producto existe en 5-10 variantes de imagen. Sin etiquetado sistemático, los redactores no encuentran la imagen correcta o, peor aún, utilizan una desactualizada. El auto-tagging por IA analiza el contenido de las imágenes y asigna etiquetas automáticamente. En un cliente con 12.000 imágenes de producto, el auto-tagging basado en IA redujo el tiempo de etiquetado de 3 semanas a 2 días.

**Empresas de medios y editoriales.** Portales de noticias, revistas y departamentos de corporate publishing producen material gráfico nuevo a diario. Los requisitos: búsqueda rápida, gestión de derechos (caducidad de licencias, derechos de uso por canal), conversión automática de formatos y herencia de metadatos. Un FAL ampliado con campos personalizados cubre las funciones básicas. Para gestión de derechos y control de flujos de trabajo se necesita un DAM externo.

**Universidades e instituciones de investigación.** Las universidades gestionan imágenes del campus, fotos de eventos, gráficos de investigación y retratos del personal. El desafío: entrega descentralizada desde más de 30 facultades a un sistema central. TYPO3 FAL con estructura de carpetas basada en categorías y derechos de acceso por grupo de usuarios lo resuelve. Los sistemas DAM externos rara vez son económicamente viables aquí.

## Arquitectura técnica

El FAL de TYPO3 consta de tres capas: el Storage Driver (sistema de archivos local, S3, Azure), el File Index (tabla de base de datos `sys_file` con metadatos) y el sistema File Reference (vinculación entre archivos y elementos de contenido). Una base de datos de imágenes en TYPO3 amplía principalmente la capa intermedia, el File Index.

La ampliación más sencilla: campos personalizados en la tabla `sys_file_metadata`. TYPO3 ya incluye campos como `title`, `description`, `alternative` y `copyright`. Mediante TCA se pueden añadir campos adicionales: `photographer`, `license_type`, `expiry_date`, `usage_rights`, `location`, `keywords_auto`. Estos campos aparecen en el diálogo de metadatos de archivos en el backend.

Para la búsqueda, TYPO3 ofrece por defecto solo una búsqueda por nombre de archivo en el módulo File List. Una búsqueda de texto completo real sobre todos los metadatos requiere una integración Solr (a través de EXT:solrfal) o un módulo de backend personalizado con conexión Elasticsearch.

El auto-tagging por IA funciona a través de una tarea Scheduler que envía archivos nuevos a un servicio de reconocimiento de imágenes (Google Cloud Vision, AWS Rekognition o un modelo autoalojado) y escribe las etiquetas reconocidas en los campos de metadatos. El proceso es asíncrono y no sobrecarga el backend.

## Problemas frecuentes y soluciones

**El índice FAL y el sistema de archivos se desincronizan.** Cuando los archivos se suben por FTP o se eliminan manualmente, el índice FAL ya no coincide con el sistema de archivos. Solución: ejecutar el indexador FAL regularmente mediante Scheduler (recomendado: a diario por la noche). El indexador sincroniza sistema de archivos y base de datos.

**Los metadatos se pierden en actualizaciones de TYPO3.** Los campos personalizados en `sys_file_metadata` sobreviven a las actualizaciones de TYPO3 cuando se definen a través de una extensión propia. Si se definen directamente en el archivo TCA Override del sitepackage, pueden perderse con cambios estructurales en la tabla de metadatos. Solución: encapsular siempre los campos de la base de datos de imágenes en una pequeña extensión propia.

**Rendimiento del backend con árboles de archivos grandes.** El módulo File List se vuelve lento a partir de 1.000 archivos por carpeta porque genera miniaturas para cada imagen. Solución: establecer una estructura de carpetas con un máximo de 500 archivos por directorio y cambiar la generación de miniaturas en File List a "bajo demanda".

## Migración y compatibilidad de versiones

El FAL de TYPO3 es parte del Core desde la versión 6.0 (2012) y se desarrolla con cada versión major. La API FAL es estable, los campos personalizados e indexadores funcionan desde TYPO3 v10 hasta v13 sin ajustes.

La decisión "ampliación FAL vs. DAM externo" depende de dos factores: tamaño del fondo y complejidad del flujo de trabajo. Hasta aproximadamente 10.000 assets y sin flujos de aprobación, un FAL ampliado es suficiente. Por encima de eso, o con requisitos como gestión automática de licencias y distribución multicanal, merece la pena un DAM especializado con conector TYPO3. Gosign asesora sobre ambas variantes e implementa tanto ampliaciones FAL como integraciones DAM.

--- Booking TYPO3 - Sistema de reservas | Gosign ---
> Sistema de reservas para TYPO3: reserva de citas, disponibilidad, pago. Desarrollo personalizado, acelerado con IA.

## La reserva de citas directa en la web falla en TYPO3 a menudo por la inmadurez de las extensiones

Empresas con citas de asesoría, alquiler de espacios u ofertas de cursos quieren integrar la reserva online directamente en su web TYPO3. La expectativa: calendario, verificación de disponibilidad, pago, correo de confirmación - todo integrado. La realidad: no existe en el TYPO3 Extension Repository (TER) una única extensión de reservas que cubra todos estos requisitos en calidad de producción. Las soluciones disponibles (jcc_appointment, cab_single_booking, diversos desarrollos propios) atienden nichos o no se mantienen activamente.

Por eso un sistema de reservas TYPO3 es casi siempre un híbrido: una extensión base o desarrollo a medida para la lógica central, combinado con proveedores de pago (Stripe, PayPal, Mollie) e interfaces de calendario (iCal, Google Calendar API). Gosign ha implementado este enfoque en más de 15 proyectos.

## Escenarios de uso habituales

**Consultorías con gestión de citas.** Asesores fiscales, abogados, consultoras necesitan un sistema donde los clientes vean huecos libres y reserven. El calendario se sincroniza con el Outlook o Google Calendar del asesor. El pago es opcional (a menudo se factura después de la consulta), pero plazos de cancelación y penalizaciones por no-show deben ser configurables. Un setup típico: 3 asesores, 4 tipos de servicio, slots de 30 minutos, 2 sedes.

**Centros de formación y cursos.** Centros educativos, escuelas de idiomas o clubes deportivos ofrecen cursos con plazas limitadas. El sistema de reservas necesita listas de participantes, listas de espera, precios de grupo, descuentos por reserva anticipada y sesiones en serie (por ejemplo, 10 clases de yoga como bloque). El pago se realiza al reservar, la cancelación con reembolso parcial debe estar automatizada.

**Alquiler de espacios y gestión de recursos.** Espacios de coworking, hoteles de conferencias e instalaciones deportivas alquilan salas o pistas por horas. Aquí cuenta la visualización de disponibilidad en tiempo real: ningún espacio puede reservarse dos veces, aunque dos usuarios pulsen "Reservar" simultáneamente. La protección contra race conditions a nivel de base de datos no es un nice-to-have, sino una obligación.

## Arquitectura técnica

Un sistema de reservas productivo en TYPO3 consta de cuatro capas. La capa de base de datos gestiona recursos (salas, personas, equipos), disponibilidades (ventanas horarias, bloqueos, festivos) y reservas (con estados: solicitada, confirmada, cancelada, completada). La capa lógica verifica disponibilidad, previene dobles reservas y calcula precios. La capa de pago se comunica con proveedores de pago externos vía sus APIs. La capa de notificaciones envía confirmaciones, recordatorios y correos de cancelación.

Para prevenir dobles reservas existen tres enfoques: bloqueo pesimista (SELECT ... FOR UPDATE), bloqueo optimista (número de versión en la tabla de reservas) o basado en cola (las solicitudes se procesan secuencialmente). La elección depende de la carga esperada. Con menos de 100 reservas diarias basta el bloqueo optimista; en eventos con 1.000 accesos simultáneos, una cola es más robusta.

La exportación iCal es estándar: cada reserva confirmada genera un archivo .ics adjunto al correo de confirmación. Para sincronización bidireccional (la reserva en TYPO3 aparece en Google Calendar y viceversa) se necesita la Google Calendar API o CalDAV.

## Problemas frecuentes y soluciones

**Dobles reservas a pesar de verificación de disponibilidad.** La causa más frecuente: la comprobación "está libre el slot" y la inserción de la reserva no se ejecutan en la misma transacción de base de datos. Entre comprobación e INSERT pueden pasar milisegundos en los que un segundo usuario reserva el mismo slot. Solución: encapsular verificación e INSERT en una transacción con bloqueo de fila.

**Los callbacks de pago no llegan.** Stripe y PayPal envían confirmaciones de pago vía webhook. Si la web TYPO3 está detrás de un reverse proxy o firewall, los callbacks no alcanzan el servidor. Solución: proporcionar la URL del webhook mediante una ruta dedicada (por ejemplo, `/api/payment/webhook`) que no esté bloqueada por el caché de TYPO3 ni por reglas .htaccess.

**Caos de zonas horarias en reservas internacionales.** Cuando reservante y recurso están en distintas zonas horarias, surgen errores. Solución: almacenar todos los horarios internamente como UTC, mostrar en el frontend ajustado a la zona horaria local del usuario mediante JavaScript.

## Migración y compatibilidad de versiones

No existe una extensión unificada de reservas con soporte oficial para TYPO3 v12/v13. La mayoría de las extensiones disponibles se han quedado en v10 o v11. Quien migra un sistema de reservas existente a TYPO3 v12+ tiene dos opciones: portar la lógica personalizada a Extbase/Doctrine (compatible con v12) o externalizar la lógica de reservas como microservicio API y renderizar solo el frontend en TYPO3.

Para nuevos desarrollos se recomienda un enfoque API-first: el motor de reservas como API REST (dentro de TYPO3 o como servicio separado), el frontend como componente web embebible en cualquier plantilla TYPO3. Así el sistema de reservas permanece independiente de las actualizaciones major de TYPO3. Gosign aplica este enfoque como estándar desde 2024.

Quien utiliza un sistema de reservas externo (Calendly, SimplyBook.me, Timify) y solo quiere incrustar la interfaz en TYPO3 tiene una tercera opción: integrar el sistema externo vía iframe o widget JavaScript. Funciona rápido pero tiene inconvenientes: diseño no unificado, cuestiones de protección de datos (cookies de terceros, transferencia de datos fuera de la UE conforme al RGPD y las directrices de la AEPD) y sin control sobre el flujo de reserva. Para sectores sensibles al RGPD (sanidad, asesoría legal, administración pública) el desarrollo a medida dentro de TYPO3 o como microservicio propio es la solución más limpia.

Gosign estima un proyecto típico de sistema de reservas (3 tipos de recurso, pago con Stripe, flujos de correo, exportación iCal) en 15 a 25 días de desarrollo. De estos, aproximadamente el 40 % corresponde a la lógica de reservas con verificación de disponibilidad, el 25 % a la integración de pagos, el 20 % a plantillas de correo y notificaciones, y el 15 % a la presentación frontend y testing.

--- bootstrap_grids TYPO3 - Grid Layouts | Gosign ---
> Bootstrap Grid Layouts como Content Elements de TYPO3. Layouts de columnas sin la sobrecarga de Gridelements. Gosign también migra de bootstrap_grids a ...

## bootstrap_grids fue durante mucho tiempo el atajo más rápido a layouts multicolumna en TYPO3, y hoy es un candidato a migración

Durante años bootstrap_grids fue, en los proyectos TYPO3, la respuesta pragmática a un requisito editorial recurrente: quiero colocar columnas una al lado de la otra en una página sin que las desarrolladoras tengan que construir cada vez sus propios elementos de contenido. La extensión trae al backend una colección de layouts Bootstrap Grid predefinidos como elementos de contenido, de modo que los redactores pueden crear directamente en el contenido de página diseños de dos, tres o cuatro columnas. Para agencias que entregan en poco tiempo muchos sitios basados en Bootstrap, fue durante mucho tiempo la solución más eficiente.

Hoy la situación es más matizada. Con la extensión del núcleo EXT:container y los backend layouts claramente mejorados en TYPO3 v11 a v13, existen alternativas nativas que requieren menos configuración y se acoplan más estrechamente al estándar TYPO3. bootstrap_grids sigue siendo relevante en proyectos existentes, pero los nuevos proyectos deberían usarlo con conciencia o no usarlo ya en absoluto.

## Escenarios típicos de uso

Un primer escenario es el inventario rápido. Un sitio corporativo de tamaño medio con unas 200 páginas que ya se apoya en Bootstrap utiliza bootstrap_grids para disponer de layouts multicolumna sin montar un sitepackage propio. Los redactores eligen en un dropdown diseños de columnas y rellenan los contenedores con elementos de contenido estándar.

Un segundo escenario es el retoque de relanzamientos antiguos. Un sitio de una asociación de 2018 se construyó originalmente con bootstrap_grids y ha acumulado con el tiempo 600 elementos de contenido alojados en grid containers. En un upgrade de TYPO3 v9 a v11 surge la pregunta: migrar o continuar. Por regla general, bootstrap_grids se continúa primero para no bloquear el upgrade, y el cambio a EXT:container se realiza en un segundo paso.

Un tercer escenario es la fase de transición a una arquitectura frontend moderna. Un grupo migra su presencia web de Bootstrap a un sistema de diseño basado en Tailwind. Mientras el equipo de redacción aún no ha cambiado a la nueva interfaz del editor, bootstrap_grids sigue en uso como puente, con fecha de caducidad clara.

Un cuarto escenario es la solución de urgencia en una auditoría. Cuando un sitio existente se las arregla sin layouts de columnas y debe mostrar algunas páginas concretas en varias columnas, bootstrap_grids es la respuesta más rápida: instalación, activación, primera página con área de contenido a dos columnas en menos de una hora. Para uso a largo plazo, rara vez es la elección correcta.

## Arquitectura técnica

bootstrap_grids registra elementos de contenido propios mediante TCA overrides y entrega plantillas Fluid para la salida del grid. En esencia, los elementos son un wrapper delgado alrededor de las clases Bootstrap `container`, `row` y `col-*`. La extensión mantiene sus propios contenedores de columnas, visibles mediante colpos en el backend layout, e incluye, si hace falta, el CSS de Bootstrap.

La instalación se realiza clásicamente mediante Composer. En combinación con sitepackages propios rige: bootstrap_grids trae un CSS completo de Bootstrap 5 y el JavaScript correspondiente, lo que en proyectos con sistema de diseño propio lleva rápidamente a conflictos y a la doble carga de CSS. En esos casos, los recursos de bootstrap_grids se desactivan y solo se usa la integración backend.

La configuración se realiza mediante TsConfig: aquí los equipos fijan qué variantes de grid se ofrecen a los redactores, qué números de columna son admisibles y qué breakpoints de Bootstrap se representan. Una limitación limpia a pocas variantes claramente nombradas reduce considerablemente la confusión en el backend.

## Problemas frecuentes y soluciones

El primer problema es la trampa de copia y pega en la redacción. Sin gobierno estricto surgen con bootstrap_grids rápidamente páginas con ocho contenedores anidados que nadie mantiene ya. La solución es una limitación de las variantes permitidas y una directriz editorial que ata el uso de layouts de columnas a tipos de contenido claros.

El segundo problema es la doble carga de CSS de Bootstrap. Los proyectos que, junto a bootstrap_grids, mantienen un build Bootstrap propio cargan Bootstrap en el peor caso dos veces. La solución es desactivar completamente los recursos que trae la extensión mediante TsConfig y usar exclusivamente el build propio del proyecto.

El tercer problema es la migración en upgrades de TYPO3. Quien cambia de v9 a v11 o de v11 a v12 constata que algunas variantes de grid se llamaban de forma distinta en versiones antiguas de Bootstrap. La solución es una auditoría de los tipos de grid utilizados antes del upgrade y una pasada de migración SQL dirigida que reescriba las variantes antiguas a los nombres nuevos.

Un cuarto problema es la representación inconsistente en la previsualización del editor. El backend muestra a menudo los grid containers vacíos o en una forma reducida, de modo que las redactoras no reconocen qué se entrega realmente en el frontend. La solución son renderizados de vista previa directamente en el módulo del backend que reproducen las clases Bootstrap y muestran visualmente los anchos de columna. El esfuerzo no es trivial, pero se amortiza rápido en equipos editoriales grandes.

## Migración y compatibilidad de versiones

bootstrap_grids existe para TYPO3 v9 a v12 y sigue manteniéndose; la adaptación oficial para TYPO3 v13 se incorporó en 2025. Más importante que la mera compatibilidad de versión es, sin embargo, la pregunta estratégica de si bootstrap_grids sigue siendo la respuesta correcta en el proyecto. Para proyectos nuevos se recomienda EXT:container: más ligero, más cercano al núcleo, más fácil de mantener. Para proyectos existentes un cambio paso a paso suele tener sentido, especialmente si el sistema de diseño se está revisando de todos modos.

Gosign migra proyectos bootstrap_grids existentes a EXT:container o a backend layouts nativos con colpos. La migración corre con apoyo de script: los grid containers existentes se reescriben mediante SQL y Upgrade Wizard como estructuras Container, de modo que las redactoras no tienen que volver a tocar ninguna página tras el upgrade. Es el camino más rápido para trasladar un sitepackage histórico al estándar TYPO3 moderno sin pérdida de contenidos.

--- cHash TYPO3 - Configuración de caché | Gosign ---
> Configuración de cHash para TYPO3: controla qué parámetros de URL afectan al caché de páginas.

## La mayoría de los errores "Page not found" en TYPO3 son problemas de cHash

Un redactor crea una noticia con paginación, la página funciona. Un visitante hace clic en la página 2, ve "Page not found". El desarrollador revisa el routing, la configuración de la página, el .htaccess. Todo correcto. El problema está más profundo: el mecanismo cHash de TYPO3 no esperaba el parámetro URL de la paginación y rechaza la entrega. Un problema de 5 minutos si sabes dónde buscar, un problema de 2 días si no.

cHash (Cache Hash) es el mecanismo de TYPO3 para proteger la caché de páginas. Calcula un hash de todos los parámetros URL y lo compara con la entrada de caché almacenada. Si aparece un parámetro desconocido que TYPO3 no espera, la página no se entrega. Esto protege contra cache poisoning, pero causa problemas con casi cada nueva extensión o cada filtro personalizado.

## Escenarios de uso habituales

**Búsqueda facetada en catálogos de productos.** Un catálogo de productos con 6 criterios de filtrado (categoría, precio, color, material, disponibilidad, valoración) genera parámetros URL como `&tx_catalog[color]=red&tx_catalog[price]=100-200`. Sin configuración cHash, TYPO3 muestra "Page not found" con cada combinación de filtros. La configuración cHash debe conocer cada uno de estos parámetros, ya sea como "required" (influye en la clave de caché) o como "excluded" (se ignora y no se hashea).

**Paginación en listas de noticias y eventos.** EXT:news y EXT:sf_event_mgt usan sus propios parámetros URL para números de página. Estos parámetros deben estar en la configuración cHash para que la página 2 obtenga su propia entrada de caché. Si falta la configuración, se entrega siempre la página 1 desde la caché (cache pollution) o la paginación falla con 404.

**Parámetros de tracking y etiquetas UTM.** Las campañas de marketing añaden parámetros UTM a las URLs: `?utm_source=newsletter&utm_medium=email`. Sin excluir estos parámetros, cada enlace de campaña crea una nueva entrada de caché. En un sitio web con 500 páginas y 10 campañas, en lugar de 500 surgen repentinamente 5.000 entradas de caché que sobrecargan el servidor. Los parámetros UTM pertenecen a la lista de exclusión.

## Arquitectura técnica

El cálculo del cHash se produce en la clase Core de TYPO3 `CacheHashCalculator`. El algoritmo toma todos los parámetros URL, los ordena alfabéticamente, los serializa y calcula un hash MD5. Este hash se añade como parámetro `cHash` a la URL. Al acceder a la página, TYPO3 verifica si el cHash proporcionado coincide con el calculado.

La configuración se realiza en `$GLOBALS['TYPO3_CONF_VARS']['FE']['cacheHash']` con cuatro listas:

`cachedParametersWhiteList`: parámetros que entran en el hash y crean entradas de caché propias. Típico: parámetros de plugins (`tx_news_pi1`, `tx_solr`).

`excludedParameters`: parámetros que se ignoran completamente. Típico: parámetros de tracking (`utm_source`, `utm_medium`, `utm_campaign`, `gclid`, `fbclid`).

`requireCacheHashPresenceParameters`: parámetros que requieren obligatoriamente un cHash. Si este parámetro aparece en la URL sin cHash, TYPO3 muestra un error 404.

Desde TYPO3 v12, la configuración cHash también se puede controlar a través de la Site Configuration (config.yaml), lo que simplifica la gestión en configuraciones multi-sitio.

## Problemas frecuentes y soluciones

**"Page not found" tras instalar una extensión.** Las nuevas extensiones traen sus propios parámetros URL. Si no están en la configuración cHash, TYPO3 bloquea la página. Solución: verificar la documentación de la extensión (las buenas extensiones incluyen configuración cHash en `ext_localconf.php`). Si no: añadir manualmente los parámetros a cachedParametersWhiteList o excludedParameters.

**Cache pollution por parámetros no controlados.** Bots y crawlers de spam añaden parámetros aleatorios a las URLs. Sin protección, cada una de estas llamadas crea una entrada de caché. El caché crece a millones de entradas, la base de datos se ralentiza. Solución: establecer `excludeAllEmptyParameters = true` y aceptar solo parámetros explícitamente conocidos en la WhiteList.

**Errores cHash difíciles de depurar.** TYPO3 solo muestra "Page not found", no por qué. En modo producción no hay mensaje de error que apunte al cHash. Solución: establecer temporalmente `$GLOBALS['TYPO3_CONF_VARS']['FE']['pageNotFoundOnCHashError'] = false` en `LocalConfiguration.php`. Entonces TYPO3 muestra la página a pesar del error cHash y registra el error.

## Migración y compatibilidad de versiones

cHash es funcionalidad del Core, no una extensión, y existe desde TYPO3 v4. La configuración ha cambiado a lo largo de las versiones: en TYPO3 v8 y anteriores se controlaba mediante TypoScript, desde v9 mediante arrays PHP en LocalConfiguration, desde v12 adicionalmente mediante Site Configuration.

En la migración de TYPO3 v9/v10 a v12/v13, las configuraciones cHash existentes deben revisarse. Los nombres de parámetros de las extensiones pueden haber cambiado. El camino más seguro: tras la actualización, probar sistemáticamente todas las páginas con parámetros (paginación, filtros, búsqueda) y comprobar el log de errores de TYPO3 en busca de entradas cHash.

TYPO3 v13 endurece aún más la comprobación cHash: los parámetros desconocidos provocan un 404 por defecto, el modo debug debe activarse explícitamente. Gosign verifica la configuración cHash como parte del proceso de aseguramiento de calidad en cada proyecto de actualización TYPO3.

--- calendarize_news TYPO3 - Calendario | Gosign ---
> Vista de calendario para GeorgRinger/news: eventos recurrentes, filtro por fecha, vista mensual/semanal/diaria.

## Los eventos en tx_news pertenecen a un calendario, no a una lista cronológica

La mayoría de sitios web TYPO3 utilizan tx_news de Georg Ringer para todo: noticias, artículos de blog, comunicados de prensa y eventos. Para los tres primeros tipos, la presentación de lista cronológica funciona. Para eventos no. Los visitantes esperan una vista de calendario con presentación mensual, semanal y diaria. Quieren hacer clic en una fecha y ver qué ocurre ese día. calendarize_news construye exactamente ese puente: toma registros de noticias existentes con campos de fecha y los renderiza como calendario.

La extensión ahorra el cambio a un sistema de eventos independiente. Quien ya usa tx_news mantiene su estructura de datos, sus plantillas y sus procesos editoriales. En lugar de una segunda extensión con almacenamiento de datos separado, hay una vista de calendario sobre datos existentes.

## Escenarios de uso habituales

**Calendarios de eventos en sitios web corporativos.** Un centro de formación publica 150 seminarios al año a través de tx_news. Cada seminario tiene fecha de inicio, fecha de fin y hora. Sin calendarize_news, los visitantes ven una larga lista ordenada por fecha. Con calendarize_news ven un calendario mensual, hacen clic en el 15 de mayo y encuentran tres seminarios. La conversión desde la vista de calendario a la página de detalle fue en un cliente un 40% mayor que desde la vista de lista.

**Eventos recurrentes sin duplicación de datos.** Una tertulia semanal, un webinar mensual, una fiesta anual de empresa: sin funcionalidad de recurrencia, el redactor debe crear 52 registros para la tertulia. calendarize_news soporta reglas de repetición (diaria, semanal, mensual, anual) con excepciones. Un registro genera 52 entradas de calendario. Si se cancela una fecha, se marca como excepción, no se elimina.

**Páginas combinadas de noticias y eventos.** Muchas organizaciones muestran en la página de inicio "Actualidad", una mezcla de noticias y eventos próximos. calendarize_news permite representar los mismos registros cronológicamente en la lista de noticias y por fecha en el calendario. Dos vistas, una fuente de datos, sin esfuerzo de sincronización.

## Arquitectura técnica

calendarize_news amplía tx_news con campos de base de datos adicionales en la tabla `tx_news_domain_model_news`: fecha de inicio, fecha de fin, flag de día completo, regla de repetición y fechas de excepción. La lógica de repetición está implementada en la extensión y genera citas virtuales en tiempo de ejecución, sin crear un registro en la base de datos para cada cita individual.

La representación del calendario se realiza mediante plantillas Fluid que renderizan una cuadrícula mensual. Cada celda (día) contiene los eventos de ese día. Las plantillas son completamente personalizables. Por defecto, la extensión incluye plantillas para vista mensual, semanal y diaria. La navegación entre meses se realiza por AJAX o carga de página clásica, configurable mediante TypoScript.

La integración con tx_news es profunda: calendarize_news se registra como plugin adicional (list type) y utiliza el patrón Repository de tx_news. Las categorías, etiquetas y restricciones de acceso de tx_news se heredan. Un evento asignado a la categoría "Interno" y visible solo para usuarios autenticados también aparece en el calendario solo tras el login.

La función de exportación iCal genera archivos .ics para eventos individuales o el calendario completo. Los visitantes pueden importar eventos directamente en Outlook, Apple Calendar o Google Calendar. La exportación utiliza el formato iCalendar (RFC 5545) y tiene en cuenta las reglas de repetición.

## Problemas frecuentes y soluciones

**El calendario no muestra eventos aunque existan noticias.** Causa más frecuente: los campos de fecha de los registros de noticias no están rellenados. tx_news tiene un campo `datetime`, pero calendarize_news utiliza campos propios para fecha de inicio y fin. Tras la instalación, los registros de noticias existentes deben complementarse con los campos calendarize. Solución: un script de migración que copie `datetime` a los campos calendarize lleva 30 minutos de desarrollo.

**Problemas de rendimiento con muchos eventos recurrentes.** Cuando 50 eventos recurrentes generan cada uno 52 citas virtuales, la extensión debe filtrar 2.600 entradas para la vista mensual. Esto es perceptible en cada carga de página sin caché. Solución: cachear el cálculo de recurrencia y limitar el horizonte temporal. Los eventos a más de 12 meses en el futuro no necesitan calcularse en cada petición.

**Presentación responsive de la cuadrícula del calendario.** Una cuadrícula de 7 columnas para días de la semana funciona en escritorio, pero no en smartphones. Las plantillas estándar de calendarize_news no están optimizadas para móvil. Solución: adaptar las plantillas Fluid y renderizar en dispositivos móviles una presentación en lista en lugar de la cuadrícula. Un breakpoint CSS a 768px es suficiente para alternar entre cuadrícula y lista.

## Migración y compatibilidad de versiones

calendarize_news depende directamente de tx_news y sigue su ciclo de versiones con retraso. La versión estable actual soporta TYPO3 v11 y v12 con tx_news v10/v11. Para TYPO3 v13 existe una versión beta en GitHub.

La alternativa calendarize (sin el sufijo _news) de lochmueller es una extensión de calendario independiente que no se basa en tx_news, sino que trae su propio modelo de datos. Se mantiene más activamente y soporta oficialmente TYPO3 v12 y v13. El cambio de calendarize_news a calendarize requiere una migración de datos.

Para proyectos que migran a TYPO3 v13 y quieren mantener tx_news, el camino más pragmático es: usar la beta de calendarize_news o construir la representación de calendario como plantilla Fluid personalizada directamente en tx_news. El esfuerzo de una plantilla personalizada es de 2-3 días, el resultado es independiente del mantenimiento de terceros. Gosign ha implementado ambos caminos y recomienda la variante adecuada según la complejidad de las reglas de repetición.

--- camaliga TYPO3 - Listas flexibles | Gosign ---
> Extensión de listas flexibles para TYPO3. Registros con imagen, texto, enlace, en diferentes layouts: lista, grid, slider.

## Para la mayoría de las listas en TYPO3 no se necesita una extensión propia

Una empresa quiere mostrar referencias en el sitio web: logo, nombre del cliente, sector, breve descripción. Otra quiere listar empleados: foto, nombre, departamento, teléfono. Una tercera necesita una vista general de productos: imagen, título, precio, enlace a la página de detalle. Tres requisitos diferentes, un patrón común: listas estructuradas con campos configurables. camaliga resuelve este patrón como extensión de listas genérica, en lugar de desarrollar una extensión personalizada para cada tipo de lista.

La extensión de quizpalme lleva años disponible en el TYPO3 Extension Repository y se mantiene activamente. Su ventaja: un tipo de registro con campos flexibles cubre el 80% de todos los requisitos de listas. Su desventaja: quien necesite modelos de datos muy específicos (relaciones anidadas, multilingualidad a nivel de campo, validación compleja) alcanzará los límites.

## Escenarios de uso habituales

**Listas de referencias y clientes.** El uso más frecuente: logos y descripciones de clientes o proyectos en una presentación de cuadrícula. camaliga incluye diseños listos: cuadrícula, carrusel, acordeón, presentación en pestañas. Los datos se mantienen en el backend TYPO3 como registros, la presentación se controla mediante plantillas Fluid. En un cliente con 120 referencias, la página de referencias basada en camaliga estuvo en línea en 3 días, incluyendo filtrado por sector.

**Páginas de equipo y empleados.** Foto, nombre, puesto, datos de contacto, opcionalmente un texto breve. camaliga lo cubre con sus campos estándar: título, subtítulo, imagen, descripción, enlace. Para campos adicionales (número de teléfono, departamento) se pueden añadir campos personalizados mediante TCA Override.

**Vistas generales de productos sencillas sin funcionalidad de tienda.** Empresas que quieren mostrar productos pero no venderlos no necesitan una tienda. camaliga proporciona una lista de productos con imagen, título, campo de precio y enlace a la hoja de datos. El filtrado por categoría es posible mediante la asignación de categorías integrada.

## Arquitectura técnica

camaliga se basa en Extbase/Fluid y sigue el patrón MVC. El tipo de registro central se llama `tx_camaliga_domain_model_content` y contiene campos para título, subtítulo, descripción, descripción breve, imagen, enlace, categoría y varios campos personalizados. Los campos están definidos en el TCA y se pueden ampliar o reducir mediante TCA Override en el sitepackage.

La presentación se realiza a través de un plugin frontend con diseño configurable. En el FlexForm del plugin, el redactor selecciona: qué categoría mostrar, qué diseño usar, cuántas entradas por página, si la paginación está activa. Los diseños son plantillas Fluid que se sobrescriben en el sitepackage.

La categorización utiliza las categorías del sistema TYPO3. Cada registro camaliga puede asignarse a una o más categorías. En el frontend se genera un menú de filtro que filtra mediante JavaScript (Isotope o filtro CSS) o mediante carga de página. La variante JavaScript es más rápida, la variante por carga de página es más amigable para el SEO.

## Problemas frecuentes y soluciones

**Los diseños se ven diferentes a lo esperado.** Los diseños incluidos de camaliga se basan en determinados frameworks CSS (Bootstrap 3/4) o librerías JavaScript (Isotope, Masonry). Si el sitio web utiliza otro framework, los estilos colisionan. Solución: nunca usar las plantillas estándar, sino crear plantillas Fluid propias en el sitepackage. El esfuerzo de una plantilla propia es de 1-2 horas.

**Rendimiento con más de 500 registros.** camaliga carga por defecto todos los registros de una categoría y filtra en el frontend mediante JavaScript. Con más de 500 entradas, el tiempo de carga inicial se hace perceptible. Solución: activar la paginación y limitar el número de entradas a 20-50 por página.

**La multilingualidad requiere solución alternativa.** camaliga soporta la gestión de idiomas de TYPO3, pero la traducción de cada registro individual con más de 200 entradas es costosa. Solución: para listas puramente visuales (logos sin texto) basta con un registro por idioma. Para listas con mucho texto, acelerar la traducción mediante el flujo de trabajo Inline Translation de TYPO3.

## Migración y compatibilidad de versiones

camaliga se mantiene activamente y soporta TYPO3 v11, v12 y según la hoja de ruta actual también v13. La extensión sigue el ciclo de releases de TYPO3 con poco retraso. La instalación por Composer mediante Packagist es posible, así como la instalación TER.

Para requisitos más complejos (registros anidados, relaciones entre listas, control de flujo de trabajo) se recomienda en lugar de camaliga una extensión Extbase personalizada o EXT:mask. Gosign asesora sobre la solución adecuada e implementa tanto soluciones rápidas basadas en camaliga como extensiones individuales.

--- CAPTCHA TYPO3 - Protección anti-spam | Gosign ---
> Protección anti-spam para formularios TYPO3. Gosign asesora entre CAPTCHAs visibles (sr_freecap, hCaptcha).

## Por qué la decisión sobre CAPTCHA no es una cuestión técnica, sino de protección de datos

CAPTCHA suena a decisión trivial: proteger el formulario frente a bots, instalar la extensión y listo. En la práctica es la pregunta de qué servicio se integra, qué consentimiento se genera y qué tasa de conversión se acepta. Para TYPO3 existe una docena de enfoques que se dividen en tres grupos: CAPTCHAs visibles con tarea visual, análisis de comportamiento invisibles como reCAPTCHA v3 y métodos puramente del lado del servidor sin interacción del usuario, como honeypots o rate limiting. La elección correcta depende menos de la fuerza del bot que del punto de partida regulatorio y del público del formulario.

## Escenarios típicos de uso

Un proveedor de software B2B opera un formulario de contacto con unas 300 consultas reales al mes y cerca de 8.000 envíos de bots. El proveedor ya utiliza Google Analytics, tiene en marcha una solución de consentimiento y no pierde base jurídica al incorporar reCAPTCHA v3. En ese caso la solución invisible es efectiva: los bots se bloquean tras bambalinas, los usuarios reales no ven nada, la tasa de conversión se mantiene estable. El consentimiento ya llega por el banner existente.

Un ayuntamiento con formularios en línea para trámites ciudadanos tiene el punto de partida opuesto: Google no puede integrarse, los banners de consentimiento deben ser mínimos y el formulario debe funcionar también sin JavaScript. Aquí reCAPTCHA queda descartado de inmediato. La combinación honeypot más rate limiting en el proxy inverso, más una sencilla operación aritmética en el formulario, captura el 95 por ciento de los bots, no requiere ningún recurso externo y no genera obligación de consentimiento, algo que la AEPD valora positivamente en auditorías del sector público.

Un tercer caso es un centro educativo con un público muy heterogéneo: estudiantes, docentes, candidatos externos, en parte con discapacidad visual. Aquí la accesibilidad es más importante que cualquier ganancia de seguridad, y un CAPTCHA puramente visual resulta problemático. La solución es una configuración hCaptcha con el modo de accesibilidad activado o una instancia de sr_freecap con alternativa de audio, complementada con un etiquetado completo conforme al Real Decreto 1112/2018 sobre accesibilidad web.

## Arquitectura técnica: tres categorías, tres patrones de integración

Los CAPTCHAs visibles como sr_freecap o hCaptcha funcionan mediante un mecanismo de request-response: la extensión genera o recibe una tarea, la muestra al usuario y, al enviar, la entrada se valida en el servidor. En TYPO3 la integración se realiza mediante un validator en el Form Framework, mediante una extensión del ViewHelper Fluid o, en Powermail, mediante el plugin de campo Captcha. El reto técnico es la sincronización de sesión y la integración en plantillas Fluid existentes.

Los CAPTCHAs invisibles como reCAPTCHA v3 calculan un score entre 0 y 1 que describe la probabilidad de que la petición sea humana. El score llega como campo adicional con el envío del formulario, y la extensión decide, en función de un umbral configurable, si se acepta o descarta el envío. La gran ventaja es que el usuario no nota nada; la desventaja es la transmisión inevitable de datos a Google.

Las soluciones basadas en honeypot trabajan sin lógica en el cliente: un campo de entrada invisible se añade al formulario HTML, oculto por CSS o tabindex=-1. Los humanos no lo rellenan, los bots sí con mucha frecuencia, y en el servidor se descarta cualquier envío con honeypot relleno. Complementado con rate limiting basado en IP y un intervalo comprobable entre la carga de la página y el envío, esto bloquea la mayoría de bots simples sin molestar a ningún usuario.

## Problemas frecuentes y soluciones

El primer problema es la propia elección: los equipos recurren por reflejo a reCAPTCHA porque es conocido y gratuito, y pasan por alto la obligación de consentimiento. Una decisión limpia requiere una breve evaluación: ¿qué infraestructura de consentimiento existe? ¿Qué público debe usar el formulario? ¿Cuál es la carga real de bots? Gosign realiza esa evaluación dentro de una auditoría breve y recomienda el método adecuado por formulario, en lugar de forzar una solución única.

El segundo problema es la combinación de varios mecanismos de protección. Quien usa honeypot, CAPTCHA y rate limiting en paralelo crea redundancia, pero también fuentes de error: un usuario legítimo fracasa en uno de los tres pasos y pierde la confianza en el formulario. La respuesta pragmática es escalonar los métodos y activar únicamente la protección más costosa ante comportamiento sospechoso, por ejemplo mostrar un CAPTCHA solo cuando la detección por honeypot ya ha saltado o cuando se han recibido varios envíos desde la misma IP en poco tiempo.

El tercer tema es el monitoring. Los equipos instalan una protección y olvidan que la eficacia disminuye en cuanto los bots desarrollan patrones de comportamiento adaptados. Una configuración CAPTCHA efectiva registra la tasa de spam y la tasa de falsos positivos y actualiza los umbrales cuando los números cambian. Gosign monta ese monitoring en el marco de la integración de la extensión y entrega una evaluación mensual, de modo que queda visible cuándo es necesario cambiar de proveedor o ajustar la configuración.

## Migración y compatibilidad de versiones

En TYPO3 v12 y v13 el Form Framework es el punto central de integración para soluciones CAPTCHA. Las extensiones que aún se apoyan en el antiguo FormBuilder o en el tipo mailform del núcleo deben reconstruirse, al migrar, sobre el nuevo framework, lo que por regla general también obliga a una nueva elección del enfoque CAPTCHA. Powermail sigue siendo una alternativa popular y aporta sus propios tipos de campo CAPTCHA, mantenidos en paralelo.

Quien migra de reCAPTCHA a una solución favorable al RGPD no solo se ahorra una obligación de consentimiento, sino que a menudo también gana tiempo de carga: el script de reCAPTCHA pesa varios cientos de kilobytes y se carga en cualquier página que contenga un formulario. Una configuración honeypot prescinde por completo de scripts externos. Gosign ha acompañado varias de esas migraciones y entrega, según el modelo operativo, o bien una configuración honeypot pura o bien una combinación con una operación aritmética local, trivial para personas pero una barrera notable para bots.

--- Cloudinary TYPO3 - CDN e imágenes | Gosign ---
> Cloudinary como driver FAL de TYPO3. Optimizar imágenes automáticamente (WebP/AVIF), transformar (Crop, Resize) y distribuir globalmente vía CDN.

## Las imágenes son el mayor obstáculo de rendimiento en sitios web TYPO3, y Cloudinary lo resuelve automáticamente

En el 90% de los sitios web TYPO3 que obtienen malos resultados en Core Web Vitals, las imágenes son el problema. Demasiado grandes, formato incorrecto, sin variantes responsive, sin CDN. El procesamiento de imágenes interno de TYPO3 (GraphicsMagick/ImageMagick) genera miniaturas, pero no optimización de formato (WebP/AVIF), no detección inteligente de recorte y no entrega automática a través de un CDN global. Cloudinary como driver FAL de TYPO3 resuelve los tres problemas en un solo paso.

Cloudinary almacena las imágenes originales en su nube, genera variantes optimizadas al vuelo y las entrega a través de más de 300 ubicaciones edge en todo el mundo. Una imagen subida como JPEG de 4 MB llega al visitante como AVIF de 120 KB, automáticamente, sin que el redactor tenga que hacer nada.

## Escenarios de uso habituales

**Sitios web corporativos con gran volumen de contenido multimedia.** Un proveedor de automoción con 3.000 imágenes de producto, cada una en 5 variantes (miniatura, imagen de lista, imagen de detalle, zoom, descarga), tiene sin Cloudinary 15.000 archivos en el servidor. Con Cloudinary se almacenan 3.000 originales, las 15.000 variantes las genera Cloudinary bajo demanda. El almacenamiento del servidor se reduce un 80%, los tiempos de carga un 60%.

**Sitios web internacionales con audiencia global.** Cuando visitantes de Brasil, Japón y Alemania acceden a la misma página, Cloudinary entrega las imágenes desde el servidor edge más cercano respectivamente. Sin CDN, cargar una imagen de 500 KB desde un servidor en Frankfurt para un visitante en Tokio dura 2-3 segundos. Con Cloudinary, menos de 200 milisegundos.

**Portales editoriales con alto volumen de imágenes.** Portales de noticias y revistas suben imágenes nuevas a diario. Cloudinary descarga el proceso de subida: las imágenes se envían directamente a Cloudinary (Upload Widget o API), se procesan y solo la ruta de referencia se almacena en TYPO3.

## Arquitectura técnica

La integración de Cloudinary en TYPO3 se realiza a través de un driver FAL (File Abstraction Layer Driver). La extensión se registra como driver de almacenamiento y sobrescribe las operaciones estándar de archivos: subida, descarga, eliminación, listado. Los redactores trabajan en el backend TYPO3 habitual.

La generación de URLs es el núcleo de la integración. En lugar de una URL de archivo local, el driver genera una URL de Cloudinary con parámetros de transformación: `https://res.cloudinary.com/[cloud-name]/image/upload/f_auto,q_auto,w_800/producto.jpg`. Los parámetros `f_auto` (detección automática de formato) y `q_auto` (ajuste automático de calidad) son el estándar.

Las transformaciones se controlan mediante parámetros de URL: anchura, altura, modo de recorte, detección de punto focal (`g_auto` reconoce rostros y áreas importantes de la imagen), overlay y marca de agua. Cada combinación genera una variante propia que Cloudinary genera en la primera solicitud y luego cachea.

La generación de breakpoints responsive es especialmente valiosa: Cloudinary analiza una imagen y calcula los breakpoints óptimos basándose en el cambio visual real entre tamaños. En lugar de breakpoints fijos a 320, 768 y 1024 píxeles, Cloudinary entrega por ejemplo 347, 691, 1024, porque ahí se encuentran las mayores diferencias visuales.

## Problemas frecuentes y soluciones

**Control de costes con alto tráfico.** Cloudinary factura por créditos: transformaciones, almacenamiento y ancho de banda consumen créditos. El plan gratuito alcanza para aproximadamente 25.000 transformaciones al mes. Solución: invalidar la caché de Cloudinary solo con cambios reales de imagen, no con cada despliegue.

**La búsqueda de imágenes en el backend TYPO3 es lenta.** El driver FAL debe consultar la API de Cloudinary con cada búsqueda. Con más de 10.000 imágenes, esto se nota. Solución: utilizar el índice FAL de TYPO3 como fuente de búsqueda primaria y sincronizar con Cloudinary solo bajo demanda.

**Las URLs de imágenes existentes cambian.** Tras la migración de almacenamiento local a Cloudinary, todas las URLs de imágenes cambian. Esto afecta al SEO (Google Image Search), enlaces externos y páginas cacheadas. Solución: configurar redirecciones 301 desde las rutas antiguas a las nuevas URLs.

## Migración y compatibilidad de versiones

La extensión oficial TYPO3-Cloudinary en GitHub soporta TYPO3 v11 y v12. La compatibilidad con v13 está en desarrollo. La extensión es mantenida por la comunidad TYPO3, no por Cloudinary directamente.

La migración de almacenamiento local a Cloudinary se realiza en cuatro pasos: primero crear una cuenta Cloudinary y configurar la API Key, segundo subir los archivos existentes mediante carga masiva, tercero cambiar la configuración de File Storage de TYPO3 al driver Cloudinary y cuarto reconstruir el índice FAL. Con 5.000 archivos, todo el proceso dura aproximadamente un día laborable.

Cloudinary ofrece un plan gratuito (25 créditos/mes) que alcanza para sitios web pequeños. Para sitios web empresariales con más de 10.000 imágenes y alto tráfico, el plan Plus cuesta aproximadamente 89 USD/mes. Gosign ha implementado integraciones Cloudinary para proyectos TYPO3 con hasta 100.000 imágenes y asesora sobre optimización de costes y estrategias de transformación.

--- CORS TYPO3 - Cabeceras Cross-Origin | Gosign ---
> Configuración de cabeceras Cross-Origin Resource Sharing para TYPO3. Necesario para accesos API, TYPO3 headless o arquitecturas de microservicios. ...

## Por qué los proyectos TYPO3 headless fracasan sin una configuración CORS correcta

En cuanto un sistema TYPO3 deja de limitarse a renderizar HTML y entrega APIs JSON a clientes JavaScript en otros dominios, el navegador choca con la Same-Origin Policy. Sin cabeceras Cross-Origin Resource Sharing (CORS) explícitas, bloquea toda llamada fetch que provenga de un origen distinto al de la propia API. Para cualquier planteamiento headless de TYPO3, cualquier integración de microservicios y cualquier montaje en el que un frontend en app.example.com hable con un backend en cms.example.com, una configuración CORS limpia es el requisito básico. No pertenece solo a una extensión, es la interacción entre middleware TYPO3, configuración del servidor web y configuración del proxy inverso.

## Escenarios típicos de uso

Un comercio electrónico con 40.000 pedidos al mes opera un catálogo de productos en TYPO3 y un storefront basado en React en un dominio independiente. El storefront consulta datos de producto, stock y precios mediante una API JSON implementada como middleware TYPO3. Sin cabeceras CORS correctas, el navegador bloquea cada llamada AJAX con el mensaje "has been blocked by CORS policy" y el storefront se queda vacío. La solución es una middleware que establece Access-Control-Allow-Origin con precisión para los dominios frontend conocidos y responde correctamente a las peticiones OPTIONS preflight.

Un segundo caso es una empresa que opera TYPO3 como content hub para varias webs de marca. Cada marca tiene un dominio propio, pero renderiza ciertos módulos como listados de noticias o imágenes de producto desde el cliente a partir de la instancia central TYPO3. Aquí CORS debe configurarse de forma que todos los dominios de marca sean admisibles, pero no los dominios ajenos. Una comprobación dinámica del origen frente a una whitelist en la Site Configuration de TYPO3 es el enfoque correcto, en lugar de un wildcard indiscriminado.

El tercer contexto son consorcios científicos que mantienen una base de datos de investigación en TYPO3 y ofrecen a centros de investigación de todo el mundo el acceso a través de una API abierta. Aquí la política CORS es deliberadamente abierta, pero debe combinarse con una capa de autenticación, de modo que cualquier origen pueda llamar a la API, pero solo con un token válido obtenga datos de vuelta.

## Arquitectura técnica: middleware, PSR-15 y preflight

En TYPO3 v12 y v13 el lugar correcto para las cabeceras CORS es una middleware PSR-15 que se engancha en el pipeline de petición. Comprueba la cabecera Origin de la petición entrante, la compara con una whitelist configurada y establece las cabeceras Access-Control-Allow-Origin, Access-Control-Allow-Methods y Access-Control-Allow-Headers en la respuesta. Para peticiones POST, PUT o DELETE con cabeceras personalizadas, el navegador envía primero una petición OPTIONS preflight, que la middleware debe responder sin autenticación, o de lo contrario la petición real falla.

La configuración puede mantenerse en la Site Configuration como array YAML, o alternativamente directamente en ext_localconf.php de la extensión propia. Es importante que el manejo de credenciales (cookies, cabeceras Authorization) solo funcione si Access-Control-Allow-Credentials está en true y Access-Control-Allow-Origin apunta a un origen concreto, no a un wildcard. Esa combinación es estándar CORS y fuente frecuente de error en equipos que prueban primero con wildcard y quieren añadir credenciales más tarde.

## Problemas frecuentes y soluciones

El primer problema es la doble fijación de cabeceras. Si TYPO3 establece una cabecera y Apache o Nginx, además, fija la misma cabecera en la configuración del servidor web, llegan dos valores al navegador, que rechaza la petición como errónea. La solución es definir CORS en un único lugar, o en la middleware de TYPO3 o en el servidor web, y dejar deliberadamente vacío el otro sitio. En proxies inversos como Traefik o Cloudflare se suma una tercera capa que también puede manipular cabeceras.

El segundo problema son las peticiones OPTIONS preflight. El navegador envía una petición OPTIONS para comprobar, antes de la llamada real, si el método está permitido. Las middlewares TYPO3 que primero realizan una autenticación y luego fijan las cabeceras CORS rechazan la petición OPTIONS porque no lleva cabecera Authorization. La solución es interceptar las peticiones preflight pronto en la cadena de middleware y responder sin autenticación.

El tercer tema es la combinación de CORS y caching. Un proxy inverso como Varnish cachea una respuesta con determinadas cabeceras CORS, y al siguiente acceso desde otro origen, este recibe las antiguas cabeceras. La consecuencia es que usuarios legítimos ven de repente errores CORS porque reciben una respuesta cacheada para otro origen. Una cabecera Vary sobre Origin resuelve el problema, pero obliga al caché a guardar varias variantes por recurso.

## Migración y compatibilidad de versiones

TYPO3 v11 todavía no ofrecía una API de middleware limpia para todos los contextos, de modo que la configuración CORS se gestionaba a menudo mediante hooks o directamente en el servidor web. A partir de v12 la middleware PSR-15 es el camino previsto, y la ruta de migración desde instalaciones más antiguas consiste en trasladar las manipulaciones de cabeceras existentes desde la configuración de Apache o Nginx a la middleware de TYPO3.

Para montajes headless en TYPO3 v13 en combinación con EXT:headless de Macopedia, CORS es un componente elemental y se trata explícitamente en la documentación de la extensión. Gosign ha implementado varios de esos proyectos headless y, cuando hace falta, coordina también entre equipos de desarrollo que asumen frontend y backend por separado, de modo que las reglas CORS estén documentadas de forma inequívoca y se sincronicen en cada cambio de despliegue. Una regla errónea abre un vector de ataque en el que webs maliciosas pueden ejecutar acciones en nombre del usuario identificado, por lo que una whitelist limpia no es un asunto de comodidad, sino un requisito de seguridad.

Hay que recordar además que CORS no es un sustituto de la autenticación. Muchos equipos de desarrollo configuran reglas CORS generosas suponiendo que así la API está segura y olvidan que todo origen permitido por el navegador tiene el mismo acceso que un cliente llamado directamente. La autenticación debe realizarse con independencia de CORS mediante tokens, API keys o cookies de sesión, y CORS solo se ocupa de que el navegador permita siquiera llamadas legítimas a esos endpoints autenticados. Quien entiende esa separación configura reglas CORS mucho más restrictivas y cierra muchas grietas no intencionadas.

--- Countdown TYPO3 - Extensión de temporizador | Gosign ---
> Extensión de TYPO3 para temporizadores: countdowns de eventos, lanzamientos de productos, plazos de ofertas.

## Las extensiones de cuenta regresiva resuelven un problema de comunicación que el texto plano no resuelve

Cuando una feria empieza en 23 días, cuando la oferta de madrugador vence a medianoche o cuando la nueva tienda sale en vivo el 1 de mayo, una frase como "quedan pocos días" no basta. Los usuarios reaccionan con mucha más fuerza a relojes que tictaquean que a fechas estáticas, y en una página TYPO3 la variante más sencilla es incrustar un temporizador visible. Varias extensiones TYPO3 del TER ofrecen esa funcionalidad; la más conocida se llama simplemente "countdown". Para cualquier sitio corporativo con anuncios de eventos, lanzamientos de producto o acciones limitadas, ese es un requisito recurrente que sin extensión suele acabar en JavaScript hecho a medida. La elección entre extensión y solución propia pocas veces depende de la técnica, sino de quién debe poder mantener el contador desde la redacción.

## Escenarios típicos: de ferias a acciones de comercio electrónico

El primer escenario son ferias y congresos. Una asociación anuncia su jornada anual con seis meses de antelación y quiere hacer visible el tiempo restante, idealmente con días, horas, minutos y segundos. El contador corre en la landing page, cambia de registro en las últimas 24 horas y desaparece automáticamente tras el cierre del evento, sin que un redactor tenga que retocar la página. Eso no solo ahorra mantenimiento, sino que evita situaciones embarazosas como un contador que sigue mostrando un valor negativo después del evento.

Un segundo escenario son los lanzamientos de producto y las ventanas de reserva. Proyectos de comercio electrónico basados en aimeos o en tiendas externas utilizan countdowns en landing pages para fijar a los clientes la fecha de inicio. En las reservas anticipadas el countdown actúa como señal de urgencia y eleva de forma demostrable la conversión.

Un tercer escenario son los plazos de candidatura y solicitud. Las universidades muestran en la página de admisión un countdown hasta el cierre, las asociaciones lo usan para precios de madrugador, las instituciones públicas para plazos de presentación a licitaciones públicas. Aquí no se trata de marketing, sino de servicio: los visitantes deben reconocer de un vistazo cuánto tiempo les queda. Para portales de solicitud del ámbito científico eso es prácticamente estándar, porque las convocatorias de ayudas trabajan con plazos fijos y una hora de corte estricta.

## Arquitectura técnica: combinación de plantilla Fluid y JavaScript mínimo

Las extensiones de countdown clásicas en TYPO3 constan de dos partes. La parte backend es un elemento de contenido o plugin en el que el redactor mantiene la fecha y hora objetivo, la zona horaria, la etiqueta y, opcionalmente, un mensaje final. La parte frontend renderiza esos datos en una plantilla Fluid y engancha un pequeño JavaScript que calcula la diferencia con el momento actual y la actualiza en el DOM.

La mayoría de las extensiones traen además una configuración para el renderizado: número de posiciones (días, horas, minutos, segundos), representación como gráfico circular o como flip clock, colores y animación. El JavaScript corre típicamente con un setInterval de 1000 ms y calcula del lado del cliente, de modo que el caché del servidor queda intacto. Es importante que el contador no termine en un valor negativo, sino que mediante un evento muestre un mensaje de "evento iniciado" u "oferta caducada".

Para proyectos sensibles al RGPD merece la pena revisar las dependencias JavaScript. Algunas extensiones cargan jQuery o MomentJS, lo que provoca un render path adicional. Las variantes modernas se conforman con unas pocas líneas de JS vanilla y un CSS Grid que funciona también sin extensión.

## Problemas frecuentes: zonas horarias, caché y SEO

El tema de soporte más habitual es la zona horaria. El redactor introduce una fecha en el backend, el servidor está en UTC, el visitante vive en hora de Madrid, y el countdown muestra una hora de más. La extensión debe distinguir limpiamente entre hora del servidor, hora editorial del backend y hora del navegador. Recomendamos siempre pasar la fecha objetivo en ISO-8601 con zona horaria explícita ("2026-05-01T12:00:00+02:00") al JavaScript.

El segundo problema es el Page Cache. Cuando la página HTML renderizada está cacheada durante una hora, el countdown no puede contener un "23 días 7 horas" calculado en el servidor, porque el cache hit congela ese valor. La solución: la parte Fluid solo renderiza la fecha objetivo como atributo data, y el cálculo de la diferencia corre exclusivamente en el navegador.

En tercer lugar, el SEO es un punto. Un countdown puramente JavaScript no muestra a Google ni la fecha objetivo ni el motivo. Para los buscadores corresponde incluir un schema:Event JSON-LD en la página, con startDate, endDate y name, para que los resultados de Google muestren el evento como rich snippet. Quien instala la extensión debería, por tanto, no solo pasar la fecha objetivo al temporizador, sino escribirla adicionalmente como datos estructurados en la cabecera de la página. Sin ese marcado el countdown queda invisible para Google y pierde su efecto de marketing ya en el resultado de búsqueda.

## TYPO3 v12 y v13: extensión o construcción alternativa ligera

Si una extensión de countdown todavía tiene sentido en TYPO3 v12 y v13 depende del alcance del proyecto. Para una única página de evento basta un pequeño elemento de contenido con un atributo data y 30 líneas de JavaScript, completamente sin sobrecarga de extensión. Para redacciones con muchos eventos que quieren mantener el temporizador ellos mismos con regularidad, la extensión se justifica porque los redactores necesitan un elemento de interfaz conocido en el backend.

Gosign construye en la práctica ambas cosas: para lanzamientos puntuales entregamos un elemento de contenido ligero sin extensión, que consta solo de una plantilla Fluid y un mini JS. Para casos recurrentes integramos una extensión mantenida y sobrescribimos la plantilla Fluid para adaptar el diseño al resto del proyecto. Al actualizar extensiones countdown antiguas, casi siempre tiene sentido el cambio a la variante vanilla, porque las versiones antiguas basadas en jQuery no pueden seguir el ritmo ni en TYPO3 v12 ni en los presupuestos de rendimiento modernos.

--- DCE TYPO3 - Elementos de contenido dinámicos | Gosign ---
> DCE (Dynamic Content Elements): extensión de TYPO3 para elementos de contenido personalizados. Alternativa a Mask con más flexibilidad.

## DCE fue durante años la primera opción para Custom Content Elements, ahora toca migrar

Entre 2013 y 2020, DCE (Dynamic Content Elements) fue junto con Mask el método más popular para crear elementos de contenido propios en TYPO3. Los editores obtenían formularios de backend con los campos exactos que necesitaban; los desarrolladores definían todo mediante GUI, sin escribir una línea de PHP o TCA. Miles de webs TYPO3 siguen funcionando hoy con DCE. El problema: el desarrollo se ha ralentizado considerablemente. Mask ha superado a DCE en adopción, y a partir de TYPO3 v13 está disponible la Content Block API nativa, una tercera alternativa que no requiere overhead de extensión.

Quien tiene DCE en producción no necesita migrar de inmediato. Pero quien planifique una actualización de TYPO3 a v12 o v13 debería incluir la sustitución en su plan, ya que el soporte a largo plazo es incierto.

## Escenarios de uso habituales

**Proyectos existentes con 10 a 50 elementos DCE.** Webs corporativas de empresas medianas construidas entre 2014 y 2020 con TYPO3 v7 a v10 usan DCE para todo: cajas teaser, pestañas, acordeones, galerías de imágenes, bloques de citas, tarjetas de equipo. Los elementos funcionan, pero están vinculados a DCE. En una actualización de TYPO3 hay que verificar si DCE funciona en la versión destino.

**Agencias con múltiples proyectos TYPO3.** Agencias que usaron DCE como estándar en sus proyectos se enfrentan a la pregunta: migrar todos los proyectos a la vez (gran esfuerzo, corte limpio) o proyecto por proyecto en la siguiente actualización (pasos más pequeños, período más largo). La respuesta depende del número de proyectos afectados y la versión TYPO3 objetivo.

**Prototipado rápido para elementos de contenido.** DCE sirve para prototipos rápidos: un nuevo elemento de contenido se configura en 15 minutos, incluyendo formulario de backend y plantilla Fluid. Para pruebas de concepto o presentaciones a clientes puede ser suficiente. Para proyectos productivos, Gosign recomienda Mask por las ventajas a largo plazo del flujo de exportación (mask_export) y el mantenimiento activo.

## Arquitectura técnica

DCE almacena las definiciones de elementos de contenido en la base de datos (tabla tx_dce_domain_model_dce), no en archivos. Cada elemento DCE consta de una configuración (campos, tipos, validación), una plantilla Fluid (directamente en el backend o como referencia a archivo) y layouts de backend opcionales. Los campos se definen en la GUI de DCE: Text, RichText, Integer, Float, Fecha, Archivo (FAL), Select, Checkbox, Grupo (IRRE), Section (fieldsets repetibles).

Al guardar, DCE genera la configuración TCA necesaria y registra el elemento en el Content Element Wizard. Los datos de los elementos se almacenan en la tabla tt_content, ampliada con campos FlexForm específicos de DCE. Esta arquitectura FlexForm es una de las diferencias principales con Mask, que crea columnas de base de datos propias en tt_content.

## Problemas frecuentes y soluciones

**Los datos FlexForm son difíciles de migrar.** Como DCE almacena datos como XML FlexForm en tt_content, la migración a Mask (que usa columnas propias) no es trivial. El XML FlexForm debe parsearse y los valores transferirse a las nuevas columnas de Mask. Solución: un script de migración que, por elemento DCE, lee los campos FlexForm y los escribe en los campos Mask correspondientes. Gosign dispone de un comando CLI reutilizable que automatiza el proceso por elemento.

**Contenedores DCE y elementos anidados.** DCE ofrece una lógica de contenedor propia que anida elementos de contenido entre sí. Esta lógica es propietaria y ningún otro sistema la entiende. Solución en la migración: cambiar las estructuras de contenedor a b13/container y recrear los elementos hijo como elementos Mask.

**Rendimiento con muchas definiciones DCE.** Webs con más de 40 elementos DCE sufren tiempos de carga del backend notables, porque todas las configuraciones FlexForm se leen y parsean desde la base de datos en cada llamada. Solución: activar el caché de DCE (configuración TypoScript `plugin.tx_dce.enableCache = 1`) o cambiar a configuración basada en archivos (función de exportación DCE).

## Migración y compatibilidad de versiones

DCE es compatible con TYPO3 v11 y v12. La compatibilidad con TYPO3 v13 es limitada: existe una rama de desarrollo pero no hay un release oficialmente marcado como estable (estado: abril 2026). El mantenimiento comunitario es menos activo que en Mask, donde in2code como desarrollador principal sigue un ciclo de releases claro.

Para la migración de DCE a Mask, Gosign tiene un proceso estandarizado: inventariar elementos DCE (campos, tipos, plantillas), recrear elementos Mask 1:1, migrar datos mediante script SQL (FlexForm XML a columnas Mask), adaptar plantillas Fluid (las llamadas a ViewHelper y nombres de variables cambian parcialmente), probar y desinstalar DCE. El esfuerzo es de 0,5 a 2 horas por elemento según complejidad. Un proyecto con 25 elementos DCE se migra en 3 a 5 días.

Gosign recomienda en la decisión de migración un cálculo pragmático de coste-beneficio. Si la próxima actualización de TYPO3 está prevista en los próximos 12 meses y DCE no funciona de forma estable en la versión objetivo, la migración es inevitable. Si el proyecto va a permanecer 2 a 3 años más en TYPO3 v11 o v12 y DCE funciona establemente allí, la migración puede posponerse al siguiente relanzamiento. En cualquier caso, debe decidirse ya si el destino es Mask o la Content Block API, para que los nuevos elementos de contenido se creen directamente en el sistema objetivo y no se generen más dependencias de DCE.

--- TYPO3 Plantillas & Sitepackages | Gosign ---
> Paquete de plantillas para TYPO3. Gosign recomienda siempre Sitepackages personalizados en lugar de plantillas prefabricadas.

## Las plantillas TYPO3 prefabricadas ahorran tiempo a corto plazo y cuestan más a largo plazo

La tentación es grande: comprar una plantilla TYPO3 prefabricada por 79 euros, instalarla, cambiar el logo, listo. En realidad, así comienza un ciclo de soluciones alternativas, overrides y conflictos de versiones que dificulta cada actualización y frena el desarrollo posterior. dmpr_template representa esta categoría de forma ejemplar. Gosign recomienda en su lugar Custom Sitepackages: paquetes de plantillas individuales, adaptados exactamente a los requisitos, mantenibles y versionables.

Un Sitepackage es una extensión TYPO3 que contiene toda la configuración del frontend: TypoScript, plantillas Fluid, Partials, Layouts, CSS/SCSS, JavaScript y Backend Layouts. Es la práctica recomendada oficial de TYPO3 desde la versión 8 y reemplaza el antiguo método de configurar plantillas en el sistema de archivos.

## Escenarios de uso habituales

**Relanzamiento corporativo con requisitos individuales.** Una empresa inicia un relanzamiento del sitio web. El diseño existe como archivo Figma, la arquitectura de información como mapa del sitio, los tipos de contenido están definidos. Un Custom Sitepackage traduce estas especificaciones 1:1 a TYPO3: cada tipo de contenido se mapea como Backend Layout o Custom Content Element, las plantillas Fluid corresponden al diseño con precisión de píxel.

**Configuración multi-sitio con componentes compartidos.** Una corporación opera 5 sitios web de marca en una instancia TYPO3. Todos comparten un Sitepackage base con sistema de cuadrícula, tipografía y componentes básicos. Cada marca tiene su propio Sitepackage que extiende la extensión base: colores, logo, layouts específicos de marca.

**Migración de configuraciones de plantillas antiguas.** Las instalaciones TYPO3 de la versión 6 o 7 a menudo utilizan TemplaVoilà, Fluid Styled Content con extensos overrides TypoScript o incluso plantillas basadas en marcadores. La migración a un Sitepackage limpio moderniza toda la pila frontend en un solo paso.

## Arquitectura técnica

Un Sitepackage es una extensión TYPO3 regular con una estructura de directorios definida. `Configuration/TypoScript/` contiene la configuración TypoScript. `Resources/Private/Templates/` contiene las plantillas Fluid. `Resources/Public/` contiene CSS/SCSS, JavaScript, imágenes y fuentes. `Configuration/TCA/` define Backend Layouts y Custom Content Elements.

El Sitepackage se instala mediante Composer y se asigna al sitio TYPO3 respectivo a través de la Site Configuration (config.yaml). Varios sitios pueden utilizar el mismo Sitepackage (multi-sitio) o tener uno propio cada uno.

## Problemas frecuentes y soluciones

**Las plantillas prefabricadas colisionan con actualizaciones de TYPO3.** Las plantillas compradas a menudo sobrescriben configuraciones del Core y definiciones TCA de una manera que se rompe con las actualizaciones de TYPO3. Con un Custom Sitepackage se controla personalmente qué características del Core se utilizan y se pueden realizar actualizaciones de forma escalonada.

**La estructura del Sitepackage crece sin control.** A lo largo de los años se acumulan docenas de Partials, plantillas huérfanas y fragmentos TypoScript. Solución: refactorización regular. Un Sitepackage limpio tiene un máximo de 20-30 Partials, convenciones de nomenclatura claras y ningún archivo sin usar.

**Conflictos de especificidad CSS con Fluid Styled Content.** TYPO3's Fluid Styled Content trae sus propias clases CSS. Si el Sitepackage utiliza clases propias, surgen conflictos de especificidad. Solución: reemplazar completamente Fluid Styled Content por definiciones propias de elementos de contenido o sobrescribir las plantillas.

## Migración y compatibilidad de versiones

El concepto de Sitepackage es el estándar desde TYPO3 v8 y se desarrolla en cada nueva versión. La estructura básica permanece estable. Los ajustes en actualizaciones mayores afectan típicamente a la sintaxis TCA, las condiciones TypoScript y el registro de módulos de backend.

La migración de una plantilla prefabricada (dmpr_template, j77_template) a un Custom Sitepackage es una reescritura, no una portabilidad. Se analizan las plantillas existentes, se extrae la funcionalidad deseada y se reconstruye en una estructura de Sitepackage limpia. En un proyecto típico con 10 tipos de página y 15 elementos de contenido, el esfuerzo es de 2-3 semanas.

TYPO3 v13 introduce Content Blocks como nuevo concepto para definiciones de elementos de contenido. Content Blocks simplifican considerablemente la creación de Custom Content Elements. Los Sitepackages no se ven afectados y pueden utilizar Content Blocks adicionalmente. Gosign construye exclusivamente Custom Sitepackages desde hace años y tiene la experiencia para migrar eficientemente configuraciones de plantillas existentes a estructuras modernas.

--- Alternativa a Doodle TYPO3 | Gosign ---
> Programación de citas directamente en TYPO3, como Doodle, pero sin servicio externo. Respetuoso con la privacidad, integrado en su propio sitio web.

## Las votaciones de fechas pertenecen al propio sitio web, no a un servicio estadounidense

Doodle es práctico: enviar un enlace, los participantes eligen sus franjas horarias, la fecha queda fijada. Pero Doodle es un proveedor externo con servidores en EE.UU., con tracking, con publicidad en el nivel gratuito. Para empresas con conciencia RGPD, para instituciones públicas y para cualquier organización que no quiera transferir datos de usuarios a servicios externos, esto es un problema. Una alternativa a Doodle directamente en TYPO3 resuelve este problema: votación de fechas en la propia infraestructura, sin cookies de terceros, sin fuga de datos.

El grupo objetivo es claro: organizaciones que coordinan regularmente citas con participantes externos (reuniones de padres, sesiones de comités, talleres, sesiones de formación) y quieren mantener el control sobre los datos.

## Escenarios de uso habituales

**Instituciones educativas con coordinación de reuniones de padres.** Colegios y guarderías coordinan reuniones de padres varias veces al año. 30 familias deben elegir entre 5 posibles fechas la mejor. A través de un plugin TYPO3 en el sitio web del colegio, la votación se realiza sin necesidad de cuenta y sin servicios externos. Los resultados permanecen en el servidor del colegio.

**Administraciones públicas y entidades gubernamentales.** Las administraciones municipales y las autoridades regionales a menudo no pueden utilizar servicios cloud que procesen datos fuera de la UE. Una votación de fechas basada en TYPO3 cumple las directrices de TI administrativas, porque los datos permanecen en el propio servidor o en el centro de datos municipal.

**Planificación interna de talleres empresariales.** Talleres interdepartamentales, reuniones estratégicas o formaciones requieren votaciones de fechas con 10-50 participantes. A través de la intranet (basada en TYPO3) la votación se puede integrar directamente, sin enviar un enlace externo.

## Arquitectura técnica

Una alternativa a Doodle en TYPO3 se basa en un plugin Extbase con tres tablas de base de datos: votaciones (Polls), opciones de fecha (Options) y votos (Votes). La votación se coloca como elemento de contenido en una página TYPO3. Los participantes abren la página, ven las opciones de fecha y seleccionan sus franjas horarias disponibles.

La entrada de datos se realiza mediante un formulario basado en Fluid. Cada opción de fecha se muestra como una fila, el participante marca casillas (sí/no/quizás). Opcionalmente se solicita el nombre del participante. Para usuarios autenticados (login frontend) la extensión puede rellenar automáticamente el nombre e impedir votaciones duplicadas.

La presentación de resultados muestra una matriz: columnas para participantes, filas para opciones de fecha, celdas codificadas por color. La fecha con más confirmaciones se destaca.

La conformidad con el RGPD requiere: eliminación automática de los datos de votación tras un periodo configurable (p.ej., 30 días después del cierre de la votación), sin cookies para la participación en la votación (basado en sesión) y una declaración de privacidad que nombre el propósito y la duración del almacenamiento.

## Problemas frecuentes y soluciones

**Votaciones spam.** Sin protección, los bots pueden emitir cientos de votos falsos. Solución: campo honeypot (campo de formulario invisible que solo los bots rellenan), limitación de tasa (máximo 3 votaciones por IP por hora) y opcionalmente un CAPTCHA sencillo.

**Falta de integración con calendario.** Los participantes quieren transferir la fecha fijada directamente a su calendario. Solución: tras el cierre de la votación, mostrar un botón "Descargar cita" que genere un archivo .ics. El esfuerzo de generación iCal es de aproximadamente 2 horas de desarrollo.

**Presentación móvil de la matriz de votación.** Una matriz con 10 opciones de fecha y 20 participantes no es legible en smartphone. Solución: en dispositivos móviles, convertir la matriz en una vista de lista donde cada fecha se muestra individualmente con botones Sí/No.

## Migración y compatibilidad de versiones

En el TYPO3 Extension Repository existen varias extensiones similares a Doodle con diferente alcance funcional y estado de mantenimiento. Ninguna se ha establecido como estándar. Para TYPO3 v12 y v13 se recomienda por tanto un desarrollo personalizado sobre base Extbase que cubra exactamente las funciones necesarias y sea mantenible a largo plazo.

El esfuerzo de desarrollo para una versión básica (crear votación, elegir fechas, mostrar resultado) es de 3-5 días. Con notificación por email, exportación iCal y backend de administración, de 7-10 días. Esto es menos que una suscripción anual a Doodle Premium para más de 15 usuarios.

Para empresas que ya utilizan Microsoft 365 o Google Workspace, la solución TYPO3 es relevante principalmente para participantes externos. Las votaciones de fechas internas funcionan de forma más eficiente a través de Outlook o Google Calendar. La solución TYPO3 complementa donde participantes externos deben participar sin cuenta. Gosign desarrolla estas soluciones personalizadas sobre base Extbase y las integra en instalaciones TYPO3 existentes.

--- downloadmanager TYPO3 - Descargas de archivos | Gosign ---
> downloadmanager: organizar, categorizar y rastrear descargas de archivos en TYPO3. Implementación acelerada con IA.

## downloadmanager ordena las áreas de descargas en TYPO3 cuando un directorio de archivos anidado ya no basta, con categorías, etiquetas, búsqueda y un contador de descargas sin cookies

En cuanto un proyecto TYPO3 tiene que gestionar más de veinte archivos de descarga, el mantenimiento manual se derrumba. Los redactores enlazan PDF mediante el link browser, el directorio crece caótico, los documentos existentes se sobrescriben por error y los visitantes ya no encuentran nada a través de la búsqueda. downloadmanager resuelve exactamente ese problema: presenta el fondo de archivos como un repositorio estructurado, con registros propios, categorías, etiquetas, metadatos y una interfaz en la que los usuarios pueden buscar de forma dirigida. Para empresas con hojas de datos de producto, asociaciones con colecciones de formularios y ayuntamientos con centros de descarga, es la solución estándar.

La diferencia con la gestión mediante simples carpetas FAL es fundamental. Mientras fileadmin representa un sistema de archivos, downloadmanager introduce una capa editorial por encima: un documento puede aparecer simultáneamente en varias categorías, llevar un título de visualización independiente del nombre de archivo y controlarse mediante una planificación de publicación. Para redacciones con requisitos de compliance, eso es a menudo una condición previa.

## Escenarios típicos de uso

El caso clásico es el catálogo técnico de producto. Un fabricante de maquinaria mantiene, para cada máquina, una hoja de datos, un manual de uso, un certificado CE y una lista de piezas de recambio. Cada descarga recibe una categoría de producto, una asignación de tipo y, opcionalmente, una etiqueta de idioma. Los visitantes filtran por gama de producto y tipo de documento, obtienen de inmediato los archivos correspondientes, y la tienda no tiene que enlazar cada PDF por separado. La propia página de producto puede mostrar una mini área de descargas que lista automáticamente todos los documentos asociados a la máquina, sin duplicación editorial.

El segundo caso son las áreas de formularios en ayuntamientos, administraciones y colegios profesionales. Los formularios de solicitud, las fichas informativas y los estatutos están agrupados temáticamente, a menudo multilingües, ocasionalmente con restricción de acceso para áreas internas de miembros. downloadmanager permite exactamente esa segmentación mediante fe_groups y categoriza los documentos por área funcional. Para administraciones públicas es además importante que los datos de publicación y los plazos de validez puedan gestionarse por documento.

Tercer uso: áreas de prensa y relación con inversores. Informes anuales, notas de prensa y material gráfico se archivan centralmente, se categorizan por año y se marcan con fecha de publicación. La redacción solo tiene que introducir cada documento una vez; las listas de frontend se generan automáticamente.

## Arquitectura técnica

downloadmanager es una extensión Extbase y mantiene registros propios en tx_downloadmanager_domain_model_download. Cada descarga referencia uno o varios archivos FAL y lleva metadatos como título, descripción, categoría, etiquetas, fecha de publicación, idioma y grupos de acceso. El módulo del backend permite importación masiva, bulk edit y flujos de publicación.

En el frontend la extensión entrega vistas de lista y detalle prefabricadas como plantillas Fluid. Las listas pueden filtrarse por categoría, etiqueta, término de búsqueda o criterio de ordenación, los parámetros se pasan como parámetros GET y se consideran en el caché. Para la búsqueda la extensión utiliza la búsqueda de texto completo de MySQL o, si se desea, una instalación Solr conectada.

La configuración corre por TypoScript y FlexForm. Los ajustes típicos son la categoría por defecto, el número de entradas por página, el orden de clasificación y la integración en una plantilla de sitepackage propia. Mediante EventListeners los desarrolladores pueden enganchar lógica propia, por ejemplo una notificación por correo ante nuevas subidas o una exportación a otros sistemas.

El seguimiento de descargas es una función central. En lugar de analítica externa con cookies, downloadmanager incrementa en cada clic un contador del lado del servidor que está como simple columna integer en el registro. Eso es amable con el RGPD, no carga un banner de cookies y entrega una afirmación sólida sobre qué documentos se piden realmente, algo que la AEPD valora positivamente en auditorías.

## Problemas frecuentes y soluciones

El primer problema es la migración desde un fondo existente. Quien ha mantenido durante años las descargas en el link browser debe pasarlas primero a registros de downloadmanager. La solución es un script que recorra las estructuras fileadmin existentes, extraiga metadatos de los nombres de archivo y cree registros. Gosign usa para ello un pipeline asistido por IA que propone categorías y etiquetas a partir del contenido de los archivos y de los metadatos PDF, y la redacción solo tiene que confirmar.

Segundo problema: caching. Las listas filtradas con parámetros URL generan muchas variantes de caché, lo que infla el caché de TYPO3. La solución está en el manejo del cHash y en una definición limpia de qué parámetros son relevantes para el caché. Para páginas con muchos filtros, un edge caching mediante Cloudflare o Varnish con reglas conscientes de parámetros puede ser más sensato que un caché del lado del servidor.

Tercer problema: multilingüismo. Un documento existe en cinco idiomas, pero debe llevarse como un único registro lógico para que los metadatos queden sincronizados. Aquí downloadmanager usa el mecanismo de idiomas de TYPO3 con registros de traducción. Es importante que la redacción entienda qué campos se mantienen por idioma y cuáles son globales.

## Migración y compatibilidad de versiones

downloadmanager se mantiene activamente y es compatible con TYPO3 v11, v12 y v13. Al actualizar desde versiones TYPO3 más antiguas hay que prestar atención sobre todo a los cambios en Extbase: los métodos del repositorio y la capa de persistencia han cambiado varias veces entre v9 y v12, lo que puede romper ampliaciones propias de la extensión. Un proyecto de upgrade típico abarca, por tanto, también la adaptación de controladores y plantillas propios.

Para proyectos que empiezan hoy vale la pena decidir previamente si downloadmanager o una solución mediante registros Extbase propios es el camino correcto. Si la redacción necesita exclusivamente descargas estándar con categorías y etiquetas, la extensión es la elección pragmática. Si además se requieren flujos complejos (aprobación, publicación multietapa, versionado), una solución a medida puede ser a largo plazo más fácil de mantener.

Gosign migra downloadmanager a nuevas versiones de TYPO3, acompaña migraciones de fondos existentes e integra la extensión en sitepackages existentes. El análisis asistido por IA ayuda a proponer automáticamente categorías y etiquetas a partir de los nombres de archivo y las estructuras de directorio existentes, de modo que el trabajo de mantenimiento manual se reduce al mínimo.

--- dp_cookieconsent TYPO3 - Gestión de cookies | Gosign ---
> dp_cookieconsent para TYPO3: gestión de cookies conforme con el RGPD. Configuración, auditoría y optimización, análisis acelerado con IA.

## Por qué un banner de cookies por sí solo no garantiza el cumplimiento del RGPD

Cualquier instalación TYPO3 que integre Google Analytics, vídeos de YouTube, plugins de redes sociales o fuentes tipográficas externas se enfrenta, desde la entrada en vigor del RGPD y la LSSI, a la misma tarea: antes de cargar un script de terceros debe existir un consentimiento activo e informado del usuario. En España, la AEPD verifica estas exigencias regularmente en inspecciones y advierte expresamente sobre banners que solo son decorativos. dp_cookieconsent es la extensión más extendida en la comunidad TYPO3 que se ocupa exactamente de esa tarea. Se dirige a empresas que quieren operar su web conforme al RGPD sin una herramienta externa de gestión de consentimiento, y por tanto a pymes, administraciones y centros educativos que no quieren asumir costes recurrentes de CMPs comerciales.

## Escenarios típicos de uso

Una empresa industrial con catálogo de productos y 45 landing pages utiliza Google Analytics, un vídeo explicativo en YouTube, formularios de HubSpot y Google Fonts. Sin dp_cookieconsent, todos esos servicios establecerían cookies en cuanto un usuario abriera la página, arriesgando un procedimiento sancionador de la AEPD. La extensión agrupa los servicios por categoría, carga el código de HubSpot solo tras el consentimiento de marketing y sirve Google Fonts de forma alternativa autoalojada, con lo que la solicitud de consentimiento allí desaparece por completo.

Un segundo cuadro típico lo ofrece una universidad como la UAM o la UCM con un portal principal y varios sitios web de facultad descentralizados. Cada facultad mantiene sus propios contenidos e integra sus propios servicios: a veces un mapa incrustado de OpenStreetMap, a veces un vídeo de YouTube, a veces un tracking de Piwik. dp_cookieconsent centraliza la gestión del consentimiento en la instalación principal, entrega el banner mediante Fluid Partials a todos los subsitios y almacena el consentimiento de forma interdominio, de modo que un usuario no tiene que volver a aceptar en cada sitio de facultad.

Un tercer caso son las administraciones municipales con formularios en línea y aplicaciones cartográficas. Aquí se añade la complicación de que la AEPD y las agencias autonómicas de protección de datos realizan inspecciones periódicas y exigen documentación completa de los servicios empleados. dp_cookieconsent entrega la categorización y el texto de privacidad directamente desde TypoScript, lo que permite que la redacción mantenga los datos sin intervención de un desarrollador.

## Arquitectura técnica: bloqueo de scripts a nivel de template

dp_cookieconsent trabaja según el principio de "type attribute swapping": todos los scripts de terceros en el código fuente no se entregan con type="text/javascript", sino con un tipo neutro como type="text/plain" y un atributo data-cookieconsent adicional. El navegador ignora esas etiquetas y no las ejecuta. Solo cuando el usuario acepta en el banner, un pequeño runner JavaScript reemplaza los atributos de tipo y dispara la ejecución diferida. El mismo mecanismo se aplica a los iframes, que hasta el consentimiento se muestran como marcadores de posición.

La extensión se configura por completo mediante constantes y setup de TypoScript, complementados con un archivo YAML para las definiciones de servicios. Cada servicio está ahí definido con nombre, descripción, categoría, nombre de cookie y duración de cookie, lo que simplifica considerablemente la posterior documentación para el responsable de protección de datos. Fluid Partials definen la apariencia del banner y del modal de ajustes, con lo que el diseño puede adaptarse a la identidad corporativa sin modificar la extensión.

## Problemas frecuentes y soluciones

El primer y más frecuente problema: a pesar del banner activado, los scripts de terceros siguen cargándose porque están integrados a través de rutas de inclusión que no pasan por TypoScript. Son típicos los bloques HTML estáticos, los elementos de contenido Fluid con etiquetas de script hardcodeadas o los includes de footer de plantillas antiguas. Una solución limpia requiere un crawling completo del sitio con las devtools del navegador o con una herramienta automatizada que registre todas las peticiones salientes y compare cuáles se disparan antes del consentimiento.

El segundo problema es el almacenamiento del consentimiento. dp_cookieconsent guarda el consentimiento en una cookie local, lo que provoca que usuarios con configuración estricta del navegador o en modo incógnito vean el banner repetidamente. Quien quiera medir las tasas de consentimiento debe activar adicionalmente un logging del lado del servidor que deposite los consentimientos junto con timestamp y hash de IP en una tabla de base de datos, entregando así documentación sólida para auditorías.

El tercer tema afecta al rendimiento. El banner carga un bundle JavaScript que, según el número de servicios configurados, puede llegar a ser notablemente grande y retrasar el First Contentful Paint. Gosign optimiza la entrega mediante deferred loading, reduce Fluid Partials innecesarios y apuesta, siempre que es posible, por una combinación de analítica sin cookies y assets autoalojados, de modo que el banner solo sea necesario para unos pocos servicios.

Un cuarto problema aparece con los cambios de consentimiento: un usuario otorga su consentimiento, usa la página, cambia de opinión más tarde y revoca la autorización. dp_cookieconsent reinicia el flag de la cookie, pero los scripts ya cargados siguen funcionando en segundo plano hasta que el usuario recarga la página. Una solución limpia requiere un trigger de recarga o la eliminación selectiva de cookies ya establecidas al revocar, de modo que la revocación de consentimiento sea realmente efectiva y no solo quede formalmente documentada.

## Migración y compatibilidad de versiones

dp_cookieconsent está disponible para TYPO3 v11, v12 y v13, y la compatibilidad con v13 se actualiza regularmente y se considera actualmente apta para producción. El salto de v11 a v12 suele requerir un re-mapeo de las constantes TypoScript, ya que algunas han sido renombradas. Para usuarios de versiones más antiguas de la extensión hay que tener en cuenta que las definiciones de servicios se mantenían antes exclusivamente a través de formularios del backend, mientras que las versiones más nuevas trabajan basadas en YAML y son por tanto mucho más fáciles de integrar en flujos Git.

Quien migra desde otra herramienta de consentimiento como Cookiebot, OneTrust o Usercentrics ahorra los costes de licencia recurrentes, pero debe reconstruir la configuración de servicios. Gosign realiza esas migraciones incluyendo un análisis de la tasa de consentimiento, de modo que el cambio no provoca pérdidas medibles en la tasa de aceptación.

Además, vale la pena una mirada estratégica a la pregunta de si un banner de cookies sigue siendo la respuesta correcta. Quien utiliza fuentes autoalojadas de forma consistente, cambia a analítica sin cookies como Matomo con cookies desactivadas o Plausible y sustituye vídeos incrustados por imágenes de vista previa estáticas con carga al clic, puede eliminar el banner por completo en muchas páginas. La ventaja legal es considerable, porque cada consentimiento evitado también es un riesgo sancionador evitado, y al mismo tiempo la tasa de conversión deja de verse frenada por el diálogo del banner.

--- dpn_glossary TYPO3 - Glosario | Gosign ---
> Extensión de glosario para TYPO3. Definir términos técnicos, enlazar automáticamente en el contenido, mostrar como tooltip. Navegación alfabética.

## Un glosario aporta valor SEO cuando el enlazado interno funciona de forma automatizada

Enlazar manualmente términos técnicos en una web es un trabajo de Sísifo. Una empresa con 200 subpáginas y 80 términos técnicos debería teóricamente revisar cada página y vincular los términos relevantes con la página del glosario. En la práctica eso nunca se completa, y con contenidos nuevos se olvida. dpn_glossary automatiza este proceso: la extensión reconoce los términos técnicos definidos en el contenido y los enlaza automáticamente con la página del glosario correspondiente o muestra una definición como tooltip.

El efecto SEO es medible. Cada término del glosario genera una URL indexable propia. El enlazado automático desde el contenido crea una red densa de enlaces internos que ayuda a Google a evaluar la autoridad temática de la web. Webs con más de 50 términos de glosario generan típicamente entre un 5 y un 15 % de tráfico orgánico adicional mediante keywords de cola larga.

## Escenarios de uso habituales

**Portales especializados y webs sectoriales.** Aseguradoras, entidades financieras, despachos jurídicos, empresas técnicas - donde la jerga profesional es cotidiana, los visitantes se benefician de definiciones comprensibles. Una aseguradora con términos como "franquicia", "suma asegurada" o "subrogación" puede mostrarlos como tooltip en el texto corrido sin interrumpir la lectura. Simultáneamente existe una página de glosario alfabética como obra de referencia.

**Documentación técnica y bases de conocimiento.** Empresas de software que mantienen su documentación en TYPO3 usan dpn_glossary para explicar términos técnicos (API, SDK, Webhook, OAuth) de forma consistente. Empleados nuevos y clientes encuentran las definiciones directamente en contexto, sin necesidad de consultar un documento separado.

**Webs multilingües con términos técnicos específicos por idioma.** dpn_glossary soporta los mecanismos de traducción de TYPO3. Los términos se definen por idioma, incluyendo definiciones y abreviaturas diferentes. Un término como "comité de empresa" se reconoce y enlaza correctamente en todas las versiones lingüísticas del contenido.

## Arquitectura técnica

dpn_glossary almacena los términos del glosario en una tabla propia (tx_dpnglossary_domain_model_term). Cada término tiene nombre, definición (RichText), opcionalmente una forma abreviada, sinónimos, medios (imágenes, archivos) y una URL de detalle. Los sinónimos son importantes: el término "IA" puede definirse como sinónimo de "Inteligencia Artificial" para que ambas formas se reconozcan automáticamente en el contenido.

El enlazado automático funciona como post-procesador de contenido: tras renderizar TYPO3 el contenido de la página, dpn_glossary busca en el HTML los términos conocidos y los reemplaza por enlaces o markup de tooltip. Las etiquetas HTML, atributos y enlaces existentes se omiten para evitar anidamientos incorrectos. El reemplazo es configurable: solo primera mención por página, todas las menciones, o sin reemplazo (solo tooltip).

El rendimiento es clave: el enlazado automático recorre cada contenido renderizado. Con más de 100 términos y páginas largas puede notarse. dpn_glossary cachea la lista de términos y usa expresiones regulares para la búsqueda, lo cual con el caché de página TYPO3 activo no supone problema, ya que el reemplazo solo se ejecuta en la primera llamada.

## Problemas frecuentes y soluciones

**Los términos se enlazan en encabezados, menús o formularios.** El enlazado automático captura a veces áreas HTML que no deberían enlazarse. Solución: la extensión ofrece configuración para Excluded Tags (por ejemplo, h1, h2, h3, nav, form, a). Por defecto se excluyen encabezados y enlaces, pero la lista debe adaptarse a cada proyecto.

**El tooltip colisiona con el layout.** Los tooltips (popups hover con la definición) pueden sobresalir del borde de la página o tapar otros elementos. Solución: ajustar el CSS del tooltip (max-width, z-index, posición). dpn_glossary incluye un CSS estándar que se puede sobreescribir vía TypoScript. Para dispositivos móviles se recomienda un comportamiento tap-en-vez-de-hover.

**Problemas de rendimiento con muchos términos.** Webs con más de 500 términos notan el enlazado en páginas no cacheadas. Solución: restringir la lista de términos a los activos (desactivar los obsoletos), limitar el enlazado a áreas específicas de la página (solo contenido principal, no footer ni sidebar) y usar consistentemente el caché de páginas TYPO3.

## Migración y compatibilidad de versiones

dpn_glossary es compatible con TYPO3 v11 y v12 en su versión estable actual. La compatibilidad con TYPO3 v13 está en desarrollo (estado: abril 2026). La extensión se mantiene activamente con releases regulares y una ruta de actualización clara.

A largo plazo, Gosign recomienda además generar los datos del glosario como markup Schema.org DefinedTerm. dpn_glossary no ofrece soporte nativo para ello, pero un override de la plantilla Fluid puede añadir el markup por término. Esto mejora la visibilidad en Knowledge Panels y respuestas generadas por IA.

Gosign estima la configuración inicial de un proyecto dpn_glossary (instalación, configuración, adaptación de plantillas, importación de 50 términos) en 1 a 2 días de desarrollo. El mantenimiento de los términos lo realiza la redacción mediante el backend TYPO3. Por término hay que gestionar nombre, definición, sinónimos y una imagen opcional, lo que se completa en 5 a 10 minutos.

--- Link-Validator TYPO3 - SEO | Gosign ---
> Comprobador de enlaces rotos para TYPO3: verificar enlaces internos y externos, encontrar enlaces rotos. Esencial para SEO y experiencia de usuario.

## Los enlaces rotos cuestan posicionamiento y confianza, y la mayoría de sitios web TYPO3 tienen más de los esperados

Un sitio web TYPO3 con 500 páginas tiene de media 3.000-5.000 enlaces. De ellos, por experiencia, el 2-5% están rotos: páginas eliminadas, URLs cambiadas de sitios web externos, erratas en enlaces introducidos manualmente. Son 60-250 enlaces rotos que envían a los visitantes a páginas 404 y señalan a Google que el sitio web está mal mantenido. dreipc_linkvalidator comprueba todos los enlaces internos y externos automáticamente e informa de problemas antes de que afecten al posicionamiento y la experiencia de usuario.

TYPO3 trae su propio validador de enlaces en el Core (EXT:linkvalidator). dreipc_linkvalidator lo amplía con comprobaciones adicionales, mejores informes y una interfaz de backend más intuitiva. Para sitios web con más de 200 páginas, una comprobación automatizada de enlaces no es un lujo, sino una obligación.

## Escenarios de uso habituales

**Sitios web corporativos con enlaces externos.** Los sitios web empresariales enlazan a socios, proveedores, asociaciones sectoriales, textos legales y artículos de prensa. Las URLs externas cambian sin previo aviso. dreipc_linkvalidator comprueba enlaces externos mediante petición HTTP e informa de 404, cadenas de 301 (más de 2 redirecciones) y timeouts.

**Universidades e instituciones educativas.** Los sitios web universitarios están entre las páginas con mayor densidad de enlaces: planes de estudio, formularios, catálogos de asignaturas, directorios de personal, universidades asociadas. En un sitio web universitario con 12.000 páginas, la comprobación de enlaces encontró 1.400 enlaces rotos.

**Portales editoriales con contenido de archivo.** Los portales de noticias y revistas con miles de artículos enlazan entre sí y a fuentes externas. A lo largo de los años se acumulan enlaces rotos, especialmente en artículos antiguos. Una comprobación mensual de enlaces identifica nuevos problemas antes de que se acumulen.

## Arquitectura técnica

dreipc_linkvalidator amplía el validador de enlaces del Core de TYPO3 con mecanismos de comprobación adicionales. El validador del Core comprueba enlaces a nivel de base de datos: analiza los campos `bodytext`, `header_link` y otros campos configurados e identifica enlaces a páginas o archivos eliminados. dreipc_linkvalidator complementa con comprobaciones basadas en HTTP para URLs externas.

La comprobación se ejecuta como tarea Scheduler de TYPO3. Configuración típica: una vez por semana por la noche. La tarea busca en todas las tablas y campos configurados enlaces, distingue entre enlaces internos, enlaces de archivo y enlaces externos, y comprueba la accesibilidad de cada enlace.

Los resultados se presentan en una vista de backend: tabular, filtrable por tipo de error (404, 301, timeout, error SSL), por página y por redactor. Cada entrada contiene el enlace, la causa del error, la página donde aparece y un enlace directo al editor del backend TYPO3.

## Problemas frecuentes y soluciones

**Falsos positivos en enlaces externos.** Algunos sitios web bloquean peticiones automatizadas (protección anti-bot, Cloudflare Challenge). El enlace funciona en el navegador, pero el validador informa 403 o timeout. Solución: establecer un User-Agent header realista, aumentar timeouts a 15 segundos y colocar dominios conocidos de falsos positivos en una lista blanca.

**La comprobación tarda demasiado en sitios web grandes.** Comprobar 10.000 enlaces externos de forma secuencial dura varias horas. Solución: configurar comprobación paralela (5-10 peticiones simultáneas) y ajustar la frecuencia de comprobación (enlaces externos semanalmente, internos diariamente).

**Los redactores ignoran los informes.** El motivo más frecuente de listas crecientes de enlaces rotos: nadie se siente responsable. Solución: activar notificaciones por email a los redactores responsables. dreipc_linkvalidator puede enviar informes por email desglosados por área del árbol de páginas.

## Migración y compatibilidad de versiones

El validador de enlaces del Core de TYPO3 (EXT:linkvalidator) forma parte del Core desde v7 y se desarrolla continuamente. En TYPO3 v12 y v13, el validador del Core ha mejorado significativamente. dreipc_linkvalidator como ampliación soporta TYPO3 v10 y v11. Para v12 y v13 no existe versión oficial.

Para proyectos en TYPO3 v12/v13, la cuestión es si dreipc_linkvalidator sigue siendo necesario. El validador del Core en v12 cubre muchas funciones que antes solo estaban disponibles a través de dreipc. Lo que falta: informes por email y la función de lista blanca para falsos positivos.

La alternativa: complementar el validador del Core con un Custom Command que genere informes por email. El esfuerzo es de aproximadamente un día de desarrollo. Gosign recomienda el validador del Core en combinación con un crawl externo mensual para máxima cobertura.

--- dreipc_pdf TYPO3 - Exportación de PDF | Gosign ---
> Extensión de exportación PDF para TYPO3. Exportar páginas y contenidos como PDF. Para documentación, folletos, catálogos.

## Cuando los visitantes quieren descargar páginas TYPO3 como PDF, el resultado necesita un diseño propio

Los visitantes hacen clic en "Guardar como PDF" y esperan un documento limpio: diseño corporativo, logo, números de página, sin sobrecarga de navegación. Lo que ofrece la función de impresión del navegador es lo contrario: columnas cortadas, encabezados y pies de página superfluos, imágenes que faltan. dreipc_pdf resuelve este problema con un enfoque de renderizado propio: la extensión genera PDFs a partir del contenido de páginas TYPO3 con un layout de impresión dedicado, independiente de la representación del navegador.

A diferencia de EXT:web2pdf, que convierte la página HTML renderizada como captura de pantalla en un PDF, dreipc_pdf trabaja orientado a datos. Renderiza los elementos de contenido de una página TYPO3 mediante plantillas propias y genera a partir de ellos un PDF formateado. Esto permite control total sobre márgenes, encabezados y pies de página, tamaños de fuente y saltos de página.

## Escenarios de uso habituales

**Hojas de datos de producto desde el CMS.** Fabricantes de maquinaria, empresas químicas y fabricantes de tecnología médica mantienen datos de producto en TYPO3. Los comerciales necesitan estos datos como PDF imprimible para visitas a clientes. dreipc_pdf genera desde la página de producto TYPO3 un PDF con layout corporativo. En un cliente con 400 páginas de producto, los PDFs están disponibles automáticamente mediante botón en cada página.

**Comunicados de prensa e informes de empresa.** Los departamentos de comunicación publican comunicados de prensa en el sitio web y los ofrecen simultáneamente como PDF descargable. dreipc_pdf genera el PDF al hacer clic en el botón de descarga, siempre basado en el contenido actual.

**Documentos informativos de entidades públicas.** Las instituciones públicas ponen formularios, hojas informativas y comunicaciones a disposición como PDF. Los contenidos se mantienen en TYPO3 y con cambios se entregan automáticamente como PDF actualizado.

## Arquitectura técnica

dreipc_pdf utiliza una librería PDF de PHP (típicamente mPDF o TCPDF) para la generación. La extensión se registra como Page Type en TYPO3. Al solicitar una página con el parámetro de tipo PDF (`?type=123`), se genera un archivo PDF en lugar de la salida HTML y se ofrece para descarga.

El pipeline de renderizado trabaja en tres pasos. Primero, la extensión lee los elementos de contenido de la página TYPO3 solicitada desde la base de datos. Segundo, renderiza cada elemento mediante una plantilla Fluid PDF dedicada. Tercero, pasa el string HTML renderizado a mPDF/TCPDF, que genera el PDF con los ajustes de página configurados.

Las plantillas PDF son plantillas Fluid con HTML/CSS que mPDF comprende. mPDF soporta un subconjunto de CSS2 y CSS3: márgenes de página (`@page`), encabezados/pies de página, tablas, imágenes, fuentes (fuentes TTF incrustables) y saltos de página.

## Problemas frecuentes y soluciones

**Faltan imágenes en el PDF.** mPDF carga imágenes vía HTTP. Si el servidor está detrás de un reverse proxy o en un entorno Docker, mPDF no puede resolver sus propias URLs de imagen. Solución: incrustar imágenes a través de la ruta local del servidor en lugar de la URL.

**La generación de PDF es lenta con páginas complejas.** Una página con 30 elementos de contenido y 15 imágenes puede tardar 5-10 segundos en la generación de PDF. Solución: cachear los PDFs generados. En la primera solicitud se genera y almacena el PDF. Las solicitudes siguientes entregan la versión cacheada.

**Los saltos de página en lugares incorrectos.** mPDF rompe páginas donde el contenido excede la altura de la página, también en medio de una tabla o un párrafo. Solución: establecer saltos de página explícitos en las plantillas PDF y proteger las tablas contra el corte.

## Migración y compatibilidad de versiones

dreipc_pdf es una extensión nicho con comunidad limitada. La última versión estable soporta TYPO3 v10 y v11. Para v12 no existe actualización oficial, el esfuerzo de portabilidad es moderado.

Las alternativas para TYPO3 v12/v13: EXT:web2pdf (basado en capturas, más sencillo, menos control sobre el layout), EXT:pdfviewhelpers (basado en ViewHelpers, trabaja con TCPDF), EXT:fluid_fpdf (plantillas Fluid con backend FPDF) o una solución personalizada con mPDF como paquete Composer.

Quien migre de dreipc_pdf a una solución personalizada puede reutilizar las plantillas Fluid PDF existentes, siempre que utilicen HTML/CSS compatible con mPDF. El wrapper de renderizado debe reescribirse, pero las plantillas se mantienen. En un proyecto típico con 5 plantillas PDF, el esfuerzo de migración es de 2-3 días. Gosign ha implementado generación de PDF en TYPO3 con diversas librerías y recomienda la solución adecuada según los requisitos.

--- E-Paper TYPO3 - Revista digital | Gosign ---
> Extensión de E-Paper/revista digital para TYPO3. Publicaciones en línea con efecto de pasar página. Gosign recomienda HTML responsivo como alternativa moderna.

## La mayoría de soluciones e-paper para TYPO3 son sucesores de Flash, y exactamente así se sienten

Las extensiones e-paper para TYPO3 provienen conceptualmente de la era Flash: se sube un PDF, una librería JavaScript simula el paso de páginas con animación 3D. A primera vista parece impresionante. A segunda vista: no indexable (Google no puede leer el contenido), no responsive (una catástrofe en smartphone), no accesible y con tiempos de carga superiores a los 5 segundos. Hay mejores formas de presentar revistas y catálogos en TYPO3.

La pregunta central no es "¿Qué plugin e-paper?" sino "¿Necesitamos realmente un e-paper?" En la mayoría de los casos la respuesta es: No. El contenido pertenece como HTML en el sitio web, no como PDF en un catálogo hojeable.

## Escenarios de uso habituales

**Revistas corporativas y publicaciones para clientes.** Los departamentos de marketing producen revistas trimestrales en impresión y quieren ofrecer la versión digital en el sitio web. Enfoque clásico: subir PDF, incrustar widget de catálogo hojeable. Mejor enfoque: publicar los artículos como páginas TYPO3 individuales (a través de tx_news), con una página resumen de la revista como hub. Cada artículo es indexable, enlazable y compartible individualmente.

**Catálogos de productos para socios comerciales.** Mayoristas y empresas B2B ofrecen a sus distribuidores catálogos de productos. Un widget e-paper hace el catálogo hojeable, pero no buscable. El mejor camino: mantener los datos de producto de forma estructurada en TYPO3 y presentar el catálogo como página HTML filtrable y buscable.

**Informes anuales y memorias de sostenibilidad.** Las empresas cotizadas publican informes anuales que deben corresponder visualmente al layout de impresión. Aquí un visor basado en PDF es aceptable, porque el layout es vinculante. Pero incluso aquí: los datos clave deben estar disponibles adicionalmente como HTML.

## Arquitectura técnica

Las soluciones e-paper en TYPO3 se pueden dividir en tres categorías:

**Catálogos hojeables basados en PDF.** Se sube un PDF, una librería JavaScript (Turn.js, FlipBook.js, pdf.js) renderiza las páginas en el navegador. Ventajas: configuración rápida, layout corresponde 1:1 a la impresión. Desventajas: sin valor SEO, mal rendimiento con PDFs grandes, sin responsividad.

**Layouts de revista basados en HTML.** Los artículos se mantienen como elementos de contenido TYPO3 normales y se presentan mediante una plantilla de revista. El layout simula estética de revista mediante CSS Grid y Tailwind. Ventajas: indexación SEO completa, responsive, rendimiento alto, accesible.

**Enfoque híbrido.** Los artículos existen como HTML, además está disponible una descarga PDF. En la página resumen el visitante ve teasers de artículos, en la barra lateral la descarga PDF de la revista completa.

Para la representación PDF en TYPO3, pdf.js (Mozilla) es una librería open source que renderiza PDFs nativamente en el navegador. pdf.js es más eficiente que los catálogos hojeables basados en Turn.js y ofrece una presentación limpia y desplazable con zoom y búsqueda de texto.

## Problemas frecuentes y soluciones

**Tiempo de carga del PDF superior a 5 segundos.** Una revista de 40 páginas como PDF pesa 20-40 MB. Solución: pdf.js soporta Byte-Range Requests, donde solo se carga la página solicitada. Adicionalmente, optimizar el PDF con Ghostscript para web (`linearize`).

**Contenido no indexado por Google.** Google rastrea PDFs e indexa su texto, pero no dentro de un visor JavaScript. Solución: presentar el contenido como elementos HTML nativos y ofrecer el PDF solo como descarga.

**Librerías de catálogos hojeables desactualizadas.** Muchas extensiones e-paper usan librerías que no se actualizan desde hace años. Solución: migrar a pdf.js o una representación basada en HTML. Ambas son seguras para el futuro.

## Migración y compatibilidad de versiones

Las extensiones e-paper en el TER están mayoritariamente desactualizadas. La mayoría soporta como máximo TYPO3 v10 o v11. Para v12 y v13 no hay extensiones de catálogo hojeable mantenidas.

El camino recomendado para TYPO3 v12/v13: integrar pdf.js como librería standalone (no se necesita extensión) para representaciones basadas en PDF. Para revistas basadas en HTML: tx_news con una plantilla de revista y categoría propia "Ediciones". El esfuerzo de un layout de revista personalizado basado en tx_news es de 3-5 días.

Quien migre desde una extensión e-paper existente tiene tres opciones: integración pdf.js (1-2 días), migración HTML (5-10 días) o un servicio externo (Issuu, Yumpu) con embed en TYPO3. Gosign recomienda el enfoque HTML para máximo valor SEO y asesora en la decisión entre las variantes.

--- Extension Builder TYPO3 - Creación | Gosign ---
> La herramienta estándar para crear nuevas extensiones de TYPO3. Editor visual para Extbase Models, Repositories y Controllers. El punto de partida de todo ...

## El Extension Builder es la herramienta de scaffolding sin la que ningún desarrollador TYPO3 se vuelve realmente productivo

El Extension Builder es desde hace más de diez años la herramienta oficial con la que las desarrolladoras crean en TYPO3 nuevas extensiones desde cero. Quien necesita una extensión Extbase con modelo de dominio, repositorio, controlador y módulo backend obtiene a través del Extension Builder un editor visual que, a partir de un diagrama de dominio tipo UML, genera todo el código boilerplate: configuración TCA, schema SQL, ext_localconf, stubs de controlador, plantillas Fluid, language files. Para agencias y equipos de producto que entregan regularmente extensiones propias, la herramienta sigue siendo el camino más rápido desde el concepto hasta el primer prototipo funcional.

El público son equipos de desarrollo TYPO3 en agencias y en el ámbito interno que, más allá de los sitepackages, quieren plasmar lógica de negocio propia en TYPO3. Son típicas las extensiones para catálogos de producto, gestión de eventos, portales de empleo, portales de cliente o estructuras de datos específicas de sector. Sin Extension Builder, cada una de esas extensiones tendría que crecer a mano desde un directorio vacío, con el riesgo de que la estructura se aleje del schema del núcleo TYPO3 y se rompa en el siguiente upgrade.

## Escenarios típicos de uso

Un primer escenario es el prototipo para un portal de cliente. Un fabricante de maquinaria con 2.000 piezas de recambio necesita una extensión que haga disponibles en el backend familias de producto, productos y documentación como estructuras de datos propias. El Extension Builder genera en menos de 30 minutos el gerüste completo: TCA, repositorios, controladores, vista de lista y detalle. El equipo empieza de inmediato con la lógica de negocio en lugar de con el boilerplate.

Un segundo escenario es la situación de formación y onboarding. Un desarrollador que construye por primera vez una extensión TYPO3 aprende a través del scaffold generado las convenciones del framework sin perderse en la documentación. El código generado no es perfecto, pero es idiomático y muestra cómo está pensado Extbase.

Un tercer escenario es la migración de estructuras de datos existentes. Quien debe montar, a partir de una exportación CSV antigua, una nueva extensión TYPO3 con diez entidades, puede clicar el modelo de dominio en el Extension Builder, exportarlo y rellenar luego el código generado con un comando de importación. Eso ahorra varios días-persona frente a una construcción manual.

Un cuarto escenario es la estandarización en un pool de agencia. Un proveedor con 15 desarrolladores TYPO3 quiere asegurarse de que cada nueva extensión tenga la misma estructura base. El Extension Builder fuerza esa estructura mediante la generación, y plantillas propias para el generador de código aseguran que estilo de código, cabeceras de licencia y estructura de directorios queden idénticas a lo largo de los proyectos.

## Arquitectura técnica

El Extension Builder es una extensión backend TYPO3 clásica con interfaz propia. En el backend aparece un módulo en el que se crea el modelo de dominio mediante una interfaz drag and drop: entidades como cajas, propiedades como campos, relaciones como líneas. Al exportar se persiste un schema JSON a partir del cual el generador escribe todo el código de la extensión.

La instalación se realiza clásicamente mediante Composer (`friendsoftypo3/extension-builder`). La extensión no tiene relevancia para producción, pertenece al entorno de desarrollo y no debería estar activada siquiera en producción. Al generar, el Builder recurre a plantillas tipo Twig que pueden adaptarse a cada proyecto si hace falta, por ejemplo para forzar estilos de código propios o cabeceras de licencia distintas.

Es importante que el Extension Builder no domina el roundtrip: quien genera una vez y luego amplía el código a mano puede abrir la extensión en el Builder, pero en ningún caso debe volver a generar, porque el Builder sobrescribiría partes de la lógica añadida manualmente. En la práctica el Builder se usa como paso de scaffold único y, después, la extensión vive en el repositorio Git.

## Problemas frecuentes y soluciones

El primer problema es la trampa de la sobrescritura tras la primera pasada de generación. Los equipos que arrancan el Builder por segunda vez para añadir un campo pierden los cambios de código propios. La solución es una regla clara en el equipo: el Extension Builder se usa una vez, el resto es trabajo manual. Los cambios posteriores de campos se hacen manualmente en TCA, SQL y modelo.

El segundo problema es la compatibilidad con convenciones PHP modernas. El generador sigue produciendo código apoyado en versiones de PHP más antiguas y en convenciones Extbase más antiguas. La solución es una pasada de cleanup inmediatamente tras la generación: añadir type declarations, fijar return types, introducir readonly properties, sustituir los comentarios de anotación obsoletos por atributos nativos.

El tercer problema es el uso irreflexivo como milagro de código. Algunos equipos esperan que el Extension Builder entregue una aplicación lista para producción. No lo hace: entrega un gerüste. Toda la lógica de negocio, toda la validación, todo el concepto de seguridad sigue siendo tarea de la desarrolladora.

Un cuarto problema son los patrones de backend obsoletos en el código generado. Los controladores que trae utilizan a veces todavía patrones Extbase deprecated que generan warnings en el TYPO3 actual. La solución es un paso de lint justo tras la generación que revise el código frente a los estándares de codificación actuales y marque las declaraciones de tipo ausentes o las anotaciones obsoletas. Los pipelines modernos combinan ese paso con la reescritura automática de código mediante Rector para mantener el esfuerzo de cleanup lo más pequeño posible.

## Migración y compatibilidad de versiones

El Extension Builder está oficialmente disponible para TYPO3 v11 y v12 y lo siguen manteniendo los Friends of TYPO3. Para TYPO3 v13 existe una versión actualizada que sigue las nuevas convenciones Extbase. Los equipos que actualizan extensiones existentes, por regla general, ya no necesitan el Builder: el upgrade corre mediante Upgrade Wizards en el Install Tool y ajustes manuales.

Más interesante es la mirada estratégica: en una época en la que la IA generativa puede crear gerüstes completos de extensión con lógica de negocio a partir de un prompt, el builder visual pierde parte de su ventaja original. Gosign combina ambos mundos: para scaffolds estándar con muchas entidades el Builder sigue siendo eficiente, para extensiones exigentes con lógica específica de dominio generamos el código directamente a partir de un briefing técnico con apoyo de IA, ahorrando frente a la construcción manual clásica hasta el 80 por ciento del tiempo de desarrollo con una calidad de código simultáneamente superior.

--- FFH TYPO3 - Extensión personalizada | Gosign ---
> Extensión de TYPO3 específica del sector. Gosign ofrece desarrollo personalizado y mantenimiento para extensiones especializadas en todas las industrias.

## Las extensiones TYPO3 específicas del sector no fallan por la técnica, sino por el mantenimiento

FFH es representativa de una categoría de extensiones TYPO3 desarrolladas para un cliente o sector determinado: específicas del sector, funcionales, pero sin mantenimiento general. En el TER se encuentran cientos de estas extensiones. Algunas tienen 5 descargas al año, sin documentación y el último commit hace 3 años. Eso no significa que sean malas. Significa que necesitan mantenimiento que el desarrollador original ya no realiza.

Para empresas que dependen de estas extensiones, se plantea una cuestión práctica: seguir usándola y mantenerla uno mismo, migrar a una alternativa o desarrollar desde cero. Los tres caminos son viables. La decisión depende de la complejidad de la extensión, la disponibilidad de alternativas y la presión de versiones de TYPO3.

## Escenarios de uso habituales

**Asociaciones sectoriales con requisitos especiales.** Cámaras de comercio, federaciones deportivas y asociaciones profesionales operan sitios web TYPO3 con funciones que ningún plugin estándar cubre: directorios de miembros con radio de búsqueda, gestión de eventos con puntos de cualificación, registros sectoriales con estado de certificación. Para ello existen extensiones personalizadas desarrolladas hace 5-8 años y actualizadas solo mínimamente desde entonces.

**Empresas de medios con flujos de trabajo editoriales.** Emisoras de radio, editoriales y empresas de medios utilizan TYPO3 con extensiones para playlists, programación, archivos multimedia o sindicación de contenido. Estas extensiones fueron desarrolladas internamente o por una agencia que ya no mantiene el proyecto.

**Instituciones públicas con requisitos legales.** Colegios, museos y bibliotecas utilizan extensiones para gestión de horarios, búsqueda en catálogos o reserva de eventos. Los requisitos son específicos, la extensión se construyó una vez y no se ha actualizado desde entonces.

## Arquitectura técnica

Las extensiones TYPO3 específicas del sector siguen típicamente el patrón Extbase/Fluid: modelo de dominio (clases PHP), repositorio (acceso a base de datos), controlador (lógica de negocio) y plantillas Fluid (presentación). Los datos residen en tablas de base de datos propias con prefijo `tx_extensionname_`.

La calidad del código varía considerablemente. Extensiones de agencias profesionales siguen estándares de codificación TYPO3, usan Dependency Injection y tienen tests unitarios. Extensiones desarrolladas internamente o trabajos de encargo rápidos a menudo tienen configuraciones hardcodeadas, tipado ausente y sin tests. Ambos se pueden mantener, pero el esfuerzo difiere en un factor de 3-5.

## Problemas frecuentes y soluciones

**APIs obsoletas bloquean la actualización de TYPO3.** La extensión usa `$GLOBALS['TSFE']`, `GeneralUtility::_GP()` u `ObjectManager::get()`, todas APIs deprecated o eliminadas en TYPO3 v12. Solución: refactorización sistemática. Cada API deprecated tiene un reemplazo documentado en el TYPO3 Changelog. En una extensión con 5.000 líneas de código, el esfuerzo de refactorización es de 3-7 días.

**Sin mantenedor disponible.** El desarrollador original dejó la empresa, la agencia ya no existe, el paquete TER está abandonado. Solución: hacer fork del código en GitHub, incluir la extensión en el propio repositorio Composer y mantenerla uno mismo. El fork es legalmente unproblematico si la extensión está bajo GPL (estándar para extensiones TYPO3).

**Sin documentación.** Ni comentarios inline ni documentación externa. Solución: antes de la refactorización, crear documentación técnica. 2-4 horas de análisis son suficientes para una extensión con 3.000-5.000 líneas para documentar arquitectura, modelo de datos y lógica de negocio.

## Migración y compatibilidad de versiones

Las extensiones específicas del sector naturalmente no tienen soporte oficial para v12/v13. La migración debe realizarse individualmente. Las tres opciones: portabilidad (adaptar extensión a nueva versión TYPO3, 3-10 días), nuevo desarrollo (misma función, arquitectura limpia, 2-4 semanas) o encontrar alternativa (extensión estándar que cubra el 80% de la función, más adaptación personalizada). Gosign ha analizado, portado y redesarrollado cientos de extensiones TYPO3 específicas del sector y asesora sobre la opción más económica.

--- filefill TYPO3 - Carga de archivos faltantes | Gosign ---
> filefill: cargar automáticamente archivos faltantes desde el servidor de producción. Para entornos de desarrollo y staging. Acelerado con IA.

## filefill ahorra a desarrolladores y agencias días de sincronización: la extensión carga automáticamente los archivos faltantes del fileadmin desde el servidor de producción cuando realmente se necesitan

Quien trabaja en un proyecto TYPO3 existente conoce el ritual: el setup local está listo, el dump de base de datos importado, pero en cada segunda página aparecen placeholders en lugar de imágenes. La causa es banal: el directorio fileadmin del sistema en producción contiene gigabytes de assets que faltan localmente. La solución clásica eran rsync o scp durante horas. filefill elimina ese paso por completo. En lugar de copiar todos los archivos de antemano, la extensión carga en el primer acceso exactamente el archivo necesario desde el servidor remoto configurado: bajo demanda, de forma transparente, con caching. Para agencias que trabajan de forma permanente en varios proyectos, eso no solo ahorra almacenamiento, sino horas por cada setup.

La ganancia de productividad es mayor de lo que parece a primera vista. Un nuevo desarrollador no es operativo solo tras una hora de espera de descarga, sino tras pocos minutos. Una revisión de código sobre una rama de feature olvidada no necesita una sincronización de archivos actualizada. Una breve reproducción de un bug no se alarga durante medio día. La pequeña extensión aborda, por tanto, un cuello de botella real del trabajo diario del desarrollador.

## Escenarios típicos de uso

El caso más frecuente es el setup de desarrollo local. Un desarrollador clona el proyecto TYPO3, configura DDEV o Docker e importa el dump actual de base de datos. En lugar de descargar además 30 GB de datos fileadmin, configura filefill con la URL base del sistema en producción. En cada petición de página que requiera una imagen o documento, la extensión comprueba si el archivo existe localmente y, si hace falta, lo carga. Tras unos pocos días de trabajo, solo los archivos realmente necesarios están en local; el resto permanece en el servidor.

El segundo caso son los entornos de staging. Una agencia mantiene para cada proyecto un sistema de staging en el que los redactores prueban contenidos antes del pase a producción. Esos sistemas de staging no necesitan guardar todas las imágenes, sino solo las de los releases actuales. filefill garantiza que los contenidos más antiguos sigan funcionando porque los archivos se tiran del sistema en producción bajo demanda.

Tercer uso: disaster recovery y escenarios de hotfix. Cuando un sistema TYPO3 debe levantarse rápidamente en una máquina nueva - tras una caída de servidor o en una migración urgente de entorno - filefill puede cubrir durante las primeras horas el aprovisionamiento de activos mientras se completa la restauración total del backup.

## Arquitectura técnica

filefill se engancha al sistema FAL de TYPO3, más en concreto al mecanismo de retrieval de recursos. En cuanto TYPO3 solicita un archivo desde el storage local y constata que no existe, un EventListener de filefill interviene. La extensión comprueba una lista de "sources" configuradas por orden de prioridad e intenta cargar el archivo desde allí. Los archivos cargados con éxito se almacenan localmente, de modo que el siguiente acceso no necesite petición remota.

La configuración se realiza mediante los ajustes de la extensión en el Install Tool. Típicamente se registra una source remota con URL base, opcionalmente con credenciales HTTP Basic Auth. Para setups con CDN o S3 también ese path puede servir como fuente. La extensión soporta varias sources, lo que es útil para escenarios más complejos con servidores de activos separados.

Es importante que filefill trabaje solo de forma pasiva. La extensión no carga nada por adelantado, sino que reacciona exclusivamente a peticiones concretas de archivos. Eso la hace frugal en consumo de recursos y discreta en operación. La integración con DDEV, Docker Compose o Lando es trivial, porque la extensión no necesita servicios adicionales.

## Problemas frecuentes y soluciones

El primer problema son las restricciones de acceso. Cuando el servidor en producción entrega imágenes solo para usuarios logueados o protege determinadas rutas por htaccess, filefill no puede recargarlas sin más. La solución está en la configuración correcta de la autenticación HTTP y, si hace falta, en una regla de whitelist en el servidor en producción que dé al entorno de desarrollo acceso al path fileadmin.

Segundo problema: uso accidental en producción. Si filefill está activo en un entorno live y la source remota es el mismo entorno, se produce una recursión peligrosa. La extensión nunca debería correr en producción. La solución pragmática es mantener filefill solo en el bloque Composer "require-dev" y activarlo mediante variables de entorno, no por el Install Tool.

Tercer problema: estados de archivo inconsistentes. Cuando el sistema en producción sustituye un archivo pero la copia local ya está cacheada, el desarrollador ve la versión antigua. La solución es un vaciado ocasional del fileadmin local o un cache busting mediante la source remota. Para el trabajo diario rara vez es un problema, porque los nombres de archivo al sustituir suelen ser nuevos.

## Migración y compatibilidad de versiones

filefill es compatible con TYPO3 v11, v12 y v13 y se sigue desarrollando activamente. En los upgrades, la versión de la extensión debería encajar con la versión de TYPO3, porque el sistema de eventos del FAL ha experimentado pequeños cambios entre v11 y v12. Quien usa la extensión en procesos de desarrollo existentes debe probar brevemente en upgrades mayores si todas las sources siguen siendo accesibles correctamente.

Una solución relacionada es EXT:aus_driver_amazon_s3, que mantiene fileadmin directamente en un bucket S3. La diferencia: aus_driver_amazon_s3 es una solución de producción, filefill es una ayuda de desarrollo. Ambas se complementan: un proyecto con storage S3 en producción puede usar filefill localmente para tirar del bucket solo los archivos que se están editando.

Para agencias que usan filefill de forma estandarizada, merece la pena una documentación en el wiki del proyecto que explique cómo se activa la extensión, qué credenciales hacen falta y cómo proceder ante problemas. Eso reduce la carga de soporte en el equipo y hace el onboarding de nuevos desarrolladores fiable. De forma complementaria, vale la pena un script corto que, al montar un nuevo entorno local, inserte automáticamente la configuración correcta.

Gosign instala y configura filefill en entornos de desarrollo e integra la extensión en setups DDEV y Docker, de modo que los nuevos miembros del proyecto sean operativos en pocos minutos.

--- Find TYPO3 - Búsqueda Solr | Gosign ---
> Extensión de búsqueda alternativa con Apache Solr para TYPO3. Interfaz de búsqueda diferente a EXT:solr.

## La búsqueda integrada de TYPO3 alcanza hasta 500 páginas, después se necesita Solr

La búsqueda estándar en TYPO3 (EXT:indexed_search) busca en la salida HTML renderizada y la almacena en una tabla de base de datos. Para sitios web pequeños con 50-500 páginas funciona. A partir de 1.000 páginas la búsqueda se vuelve lenta (tiempos de respuesta superiores a 2 segundos), a partir de 5.000 páginas, inutilizable. EXT:find es una extensión de búsqueda basada en Solr que ofrece una alternativa al stack EXT:solr establecido: configuración más flexible, query builder propio y un enfoque diferente para la búsqueda facetada.

La decisión entre EXT:find y EXT:solr no es una cuestión de calidad, sino de arquitectura. EXT:solr tiene la comunidad más grande y más funciones de serie. EXT:find ofrece más flexibilidad en la configuración de consultas y es adecuada para proyectos con requisitos de búsqueda inusuales.

## Escenarios de uso habituales

**Portales especializados con búsqueda específica del dominio.** Un portal jurídico con 15.000 documentos necesita buscar por artículos, números de expediente y palabras clave simultáneamente. EXT:find permite la definición de diferentes tipos de consulta por campo de búsqueda: búsqueda exacta para números de expediente, búsqueda fuzzy para texto libre, filtros de rango para campos de fecha.

**Búsqueda e-commerce con atributos de producto.** Los productos tienen atributos (color, talla, peso, precio) que sirven como facetas en la búsqueda. EXT:find mapea estas facetas directamente a campos Solr y genera la navegación de filtros automáticamente desde la configuración Solr.

**Búsqueda de texto completo multilingüe.** Los sitios web internacionales necesitan una búsqueda que considere las particularidades específicas del idioma: palabras compuestas alemanas, declinación polaca, acentos españoles. Solr incluye analizadores de idioma para más de 30 idiomas. EXT:find configura el analizador adecuado por idioma y genera cores Solr específicos por idioma.

## Arquitectura técnica

EXT:find se comunica con un servidor Apache Solr mediante HTTP/JSON. La arquitectura consta de tres componentes: el servidor Solr (indexación y búsqueda), el indexador (escribe contenidos TYPO3 en Solr) y el plugin frontend (entrada de búsqueda, resultados, facetas).

EXT:find se diferencia de EXT:solr en la capa de consultas. En lugar de una estructura de consulta fija, find ofrece un query builder configurable: mediante TypoScript o FlexForm se puede definir qué campos Solr se buscan, con qué ponderación (boosting), qué filtros se aplican automáticamente y cómo se ordenan los resultados.

## Problemas frecuentes y soluciones

**Configuración y mantenimiento del servidor Solr.** Solr es un servidor basado en Java que debe operarse por separado. Solución: usar Solr gestionado (p.ej., Websolr, SearchStax) u operar Solr como contenedor Docker.

**La calidad de búsqueda es mala.** Los visitantes buscan "contacto" y encuentran 200 resultados porque la palabra aparece en el footer de cada página. Solución: configurar ponderación de campos. Las coincidencias en título se ponderan 10 veces más que las del cuerpo.

**El índice no se actualiza.** Los redactores cambian contenido pero la búsqueda muestra resultados antiguos. Solución: configurar la tarea Scheduler en intervalos cortos (cada 15 minutos para índice delta, por la noche para índice completo).

## Migración y compatibilidad de versiones

EXT:find soporta TYPO3 v10 y v11 con Solr 8 y 9. Para TYPO3 v12 existe una versión beta en GitHub. La extensión es mantenida por la biblioteca SUB Göttingen y tiene una base de usuarios académica.

EXT:solr es la alternativa más popular con soporte oficial para v12 y opciones de soporte comercial. Para la mayoría de proyectos TYPO3, EXT:solr es la elección segura. EXT:find se recomienda para proyectos con requisitos de consulta especiales (búsqueda académica, bases de datos especializadas, escenarios multi-índice).

La migración de EXT:indexed_search a Solr requiere: configurar servidor Solr, configurar esquema, indexar contenido y adaptar plantillas frontend. El esfuerzo es de 3-5 días para un sitio web estándar y 1-2 semanas para portales complejos. Gosign asesora sobre el stack de búsqueda adecuado y se encarga de la configuración y el ajuste fino de la calidad de búsqueda.

--- FlexSlider TYPO3 - Migración | Gosign ---
> FlexSlider para TYPO3. Extensión de slider obsoleta basada en jQuery. Gosign migra a Swiper o Splide: sin jQuery, mejor rendimiento, soporte táctil nativo.

## FlexSlider está obsoleto desde 2015, pero sigue activo en miles de sitios web TYPO3

FlexSlider fue entre 2012 y 2015 uno de los sliders más populares para sitios web: basado en jQuery, responsive, con opciones de animación. La librería jQuery FlexSlider.js tenía más de 10.000 estrellas en GitHub. La última actualización se publicó en 2015. Desde entonces, el desarrollo web ha cambiado fundamentalmente: jQuery ya no es necesario, los Core Web Vitals penalizan las librerías JavaScript pesadas y los eventos táctiles funcionan nativamente sin librería.

La extensión TYPO3 EXT:flexslider integra la librería FlexSlider.js y ofrece un plugin de backend para configurar diapositivas (imagen, texto, enlace, efecto de animación). La extensión ya no se mantiene y soporta como máximo TYPO3 v10. Todo sitio web TYPO3 con FlexSlider tiene pendiente una migración.

## Escenarios de uso habituales

**Slider de página de inicio con imágenes de campaña cambiantes.** El uso clásico: 3-5 imágenes de gran formato en la página de inicio que rotan automáticamente. Estos sliders cargan típicamente 3-5 imágenes simultáneamente (15-25 MB de datos), más jQuery (90 KB) y FlexSlider.js (30 KB). La alternativa moderna: una única imagen hero estática en lugar de slider (mayor conversión según tests A/B) o un slider basado en CSS sin JavaScript.

**Galerías de imágenes de producto con miniaturas.** FlexSlider se usaba a menudo como galería de miniaturas en páginas de producto. Esta función se puede implementar hoy con 30 líneas de CSS y 10 líneas de JavaScript vanilla, sin librería externa.

**Carruseles de testimonios.** Citas de clientes como textos que rotan, a menudo con animación autoplay. Alternativa moderna: CSS Scroll Snap con `scroll-behavior: smooth`. Sin JavaScript necesario, soporte táctil completo, menos de 1 KB de código.

## Arquitectura técnica

EXT:flexslider consta de tres partes: un plugin de elemento de contenido (FlexForm con configuración de diapositivas), plantillas Fluid para la presentación frontend y la librería FlexSlider.js con jQuery como dependencia.

Los problemas de rendimiento son estructurales: FlexSlider carga todas las diapositivas al cargar la página (sin lazy loading), jQuery bloquea el renderizado (recurso bloqueante), el motor de animación usa JavaScript en lugar de transiciones CSS (mayor consumo de CPU en dispositivos móviles).

## Problemas frecuentes y soluciones

**Core Web Vitals deficientes por FlexSlider.** LCP superior a 4 segundos, CLS superior a 0.25, TBT superior a 300ms. Esto no es un problema de ajuste, es un problema de arquitectura. Solución: reemplazar FlexSlider por una alternativa moderna. Swiper (sin jQuery, lazy loading, transiciones CSS) o Splide (más ligero que Swiper, 29 KB frente a 140 KB). Mejor aún: no usar slider y sustituir por un elemento hero estático.

**Conflictos con jQuery.** TYPO3 v12 ya no incluye jQuery en el Core. FlexSlider necesita jQuery. Solución: en la migración del slider, eliminar jQuery completamente y migrar simultáneamente todos los componentes dependientes de jQuery.

**Las imágenes responsive no funcionan.** FlexSlider no conoce el elemento `<picture>` ni `srcset`. Cada dispositivo carga la misma imagen. Solución: Swiper y Splide soportan `srcset` y `<picture>` nativamente.

## Migración y compatibilidad de versiones

FlexSlider no tiene compatibilidad con TYPO3 v12 o v13 y no la tendrá. La librería jQuery está en fin de vida. Cada proyecto TYPO3 que migra a v12/v13 debe reemplazar FlexSlider.

La migración se realiza en cuatro pasos: primero exportar los datos de diapositivas existentes, segundo configurar un nuevo elemento de contenido con Swiper o Splide, tercero importar los datos de diapositivas en la nueva estructura y cuarto migrar las referencias FlexSlider antiguas al nuevo elemento.

El esfuerzo de migración es de 1-2 días para la conversión técnica y 0,5-1 día para la migración de datos con 10-20 sliders. Gosign recomienda en cada migración de FlexSlider la pregunta fundamental: ¿Realmente necesita un slider? Los tests A/B muestran consistentemente que los elementos hero estáticos logran tasas de conversión más altas que los sliders rotativos.

--- Flipbook TYPO3 - Libro PDF interactivo | Gosign ---
> Extensión alternativa de flipbook para TYPO3 (además de rflipbook). Presentación de PDF como libro con efecto de pasar página.

## Los flipbooks impresionaban en 2012, hoy cuestan rendimiento y accesibilidad

El efecto de pasar páginas fue una de las formas de presentación más populares para catálogos, informes anuales y revistas en webs corporativas. Un PDF se descompone en páginas individuales, se muestra en el navegador como libro y se hojea mediante clic o gesto táctil. La técnica viene de la era Flash. Desde el fin de Flash (2020), las soluciones flipbook se basan en JavaScript y Canvas. Pero la idea básica no ha cambiado: se trata de simular visualmente un documento físico.

El problema: los flipbooks son asesinos de rendimiento. Un PDF de 40 páginas se convierte en 40 imágenes individuales (200 a 500 KB cada una), más la librería JavaScript (100 a 300 KB minificada). Resultado: 10 a 20 MB de payload para un solo elemento de contenido. En dispositivos móviles los flipbooks apenas son usables, los lectores de pantalla no pueden leer el contenido, y Google no indexa el texto porque está embebido en imágenes.

## Escenarios de uso habituales

**Informes corporativos y memorias anuales.** Los directivos quieren mostrar el informe anual "como impreso" en la web. La agencia de imprenta entrega un PDF, el equipo de marketing quiere publicarlo tal cual online. El flipbook parece la solución más sencilla. Gosign recomienda aquí una alternativa: preparar el informe como página HTML (buscable, accesible, responsive) y colocar el PDF como enlace de descarga al lado.

**Catálogos de producto con muchas páginas.** Empresas industriales con catálogos de 200 páginas usan flipbooks como "catálogo hojeable" en la web. La realidad: los usuarios hojean un máximo de 5 a 10 páginas antes de abandonar. Un catálogo HTML buscable con filtros y páginas de detalle de producto convierte mejor.

**Exposés inmobiliarios y folletos.** Agencias inmobiliarias muestran exposés como flipbook para dar sensación de documento impreso. Aquí suele bastar un visor PDF embebido (pdf.js) sin efecto de hojeado, que funciona en todos los dispositivos y mantiene el texto buscable.

## Arquitectura técnica

La extensión Flipbook para TYPO3 (al igual que rflipbook, la otra variante popular) trabaja en tres pasos. Primero se convierte el PDF en imágenes individuales en el servidor (mediante ImageMagick, Ghostscript o un servicio externo). Luego las imágenes se renderizan en una librería JavaScript basada en Canvas (turn.js, StPageFlip o una solución comercial). El efecto de hojeado se genera mediante CSS3 Transform y animación JavaScript.

La integración TYPO3 se realiza como elemento de contenido: el editor sube un PDF, selecciona opciones (rango de páginas, tamaño de miniatura, velocidad del efecto), y el frontend renderiza el flipbook.

Dependencias: ImageMagick o Ghostscript debe estar instalado en el servidor (para la conversión PDF). Con turn.js (la librería más conocida) se necesita cargar jQuery, lo cual supone un inconveniente adicional de rendimiento en webs modernas.

## Problemas frecuentes y soluciones

**No se generan imágenes.** La conversión de PDF falla cuando Ghostscript no está instalado, se ejecuta una versión incorrecta o faltan permisos en el directorio de salida. Solución: verificar `gs --version` en el servidor (mínimo 9.50), asignar permisos de escritura al directorio de salida para el usuario del servidor web.

**Tiempo de carga superior a 5 segundos.** Un PDF de 80 páginas genera docenas de imágenes de alta resolución. Solución: reducir la calidad de imagen (72 dpi en lugar de 150 dpi para presentación web), implementar lazy loading para páginas fuera del área visible, usar WebP en vez de PNG/JPEG. O plantear la pregunta fundamental: realmente se necesita un flipbook.

**Errores de visualización en dispositivos móviles.** El efecto de hojeado funciona de forma limitada en dispositivos táctiles. El efecto 3D de paso de página apenas es visible en pantallas pequeñas, y el gesto de deslizamiento colisiona con el scroll del navegador. Solución: en móviles, cambiar automáticamente a un slider simple o al visor PDF nativo.

## Migración y compatibilidad de versiones

La extensión Flipbook tiene soporte limitado para versiones actuales de TYPO3. La última versión estable soporta TYPO3 v10 y v11. Para v12 y v13 no hay release oficial (estado: abril 2026).

Gosign recomienda, al actualizar TYPO3, sustituir el flipbook por una de las siguientes alternativas: visor PDF basado en pdf.js (open source, sin conversión necesaria, texto buscable), preparación HTML del contenido (máximo impacto SEO, accesibilidad completa) o slider lightbox con páginas seleccionadas como imágenes (compromiso visual, buen rendimiento). La migración se completa generalmente en 1 a 2 días, ya que el contenido ya existe como PDF y solo cambia la forma de presentación.

Otro aspecto es la accesibilidad. Los flipbooks son completamente inaccesibles para usuarios de lectores de pantalla, porque el texto está embebido en imágenes. La Directiva Europea de Accesibilidad, transpuesta en España mediante el Real Decreto 1112/2018, afecta también a publicaciones digitales en webs corporativas. El cambio a presentaciones basadas en HTML o pdf.js (que renderiza el texto original) no es solo una cuestión de rendimiento, sino también una necesidad legal.

--- FlowFact TYPO3 - CRM inmobiliario | Gosign ---
> FlowFact en TYPO3: listados inmobiliarios, sincronización de objetos, exposé. Integración OpenImmo. Acelerado con IA.

## Las agencias inmobiliarias pierden leads cuando los inmuebles se transfieren manualmente a la web

Un agente inmobiliario gestiona su cartera de propiedades en FlowFact: fotos, planos, precios, características de equipamiento, textos de exposé. Los mismos datos deben aparecer en su propia web, en Idealista, en Fotocasa y en exposés impresos. Sin sincronización automática, alguien introduce los datos por duplicado, olvida actualizar tras un cambio de precio o publica un inmueble ya vendido. La consecuencia: anuncios erróneos, contactos irritados, leads perdidos.

FlowFact (parte del grupo Hypoport desde 2019) es uno de los CRM más utilizados en el sector inmobiliario europeo. La conexión con TYPO3 sincroniza automáticamente las propiedades de FlowFact con la web de la agencia, sin intervención manual. Gosign ha implementado esta integración para agencias con entre 50 y 2.000 inmuebles activos.

## Escenarios de uso habituales

**Agencias inmobiliarias regionales con web propia.** Una oficina con 3 a 10 agentes gestiona entre 200 y 500 propiedades activas en FlowFact. La web muestra listados con función de búsqueda (código postal, número de habitaciones, rango de precio, tipo de inmueble), páginas de detalle con galería de imágenes y plano, descarga de exposé en PDF y un formulario de contacto que enruta la consulta directamente al agente responsable en FlowFact. Las nuevas propiedades aparecen en la web en 15 minutos; los cambios de estado (vendido, reservado) se recogen automáticamente.

**Promotores y constructores.** Empresas que comercializan proyectos de obra nueva necesitan, además de la búsqueda de inmuebles, landing pages de proyecto con descripción de obra, plano de situación y resumen de viviendas como tabla interactiva. FlowFact aporta los datos de los inmuebles; TYPO3 proporciona el entorno editorial para textos de proyecto y contenido de marketing. Ambos mundos se conectan a través de la API.

**Administradores de fincas con portal de inquilinos.** Las administraciones de fincas usan FlowFact para gestionar inmuebles de alquiler. La web TYPO3 muestra las viviendas disponibles, recoge solicitudes mediante formulario y las reenvía como contacto a FlowFact. Particularidad: el listado filtra automáticamente por "en alquiler", no por "en venta".

## Arquitectura técnica

La conexión entre FlowFact y TYPO3 funciona a través de dos interfaces posibles. La vía clásica es OpenImmo, un estándar XML del sector para el intercambio de datos inmobiliarios. FlowFact exporta propiedades como XML OpenImmo (manualmente o por scheduler); un importador TYPO3 lee los archivos y crea registros. Extensiones como openimmo o importadores a medida procesan la estructura XML.

La vía más moderna es la API REST de FlowFact (desde FlowFact v3). El servidor TYPO3 consulta datos de propiedades, imágenes y contactos mediante peticiones HTTP y los sincroniza en la base de datos local. Ventajas frente a OpenImmo: capacidad de tiempo real (polling cada 5 minutos en lugar de exportación diaria), actualizaciones granulares (solo campos modificados) y acceso a datos específicos de FlowFact no incluidos en el estándar OpenImmo (por ejemplo, notas internas, estado del lead).

En el lado TYPO3, las propiedades se almacenan como registros en una tabla propia (no como páginas TYPO3). Las páginas de listado usan repositorios Extbase con funciones de filtrado. Las páginas de detalle se renderizan vía Show Action, cargando imágenes desde FAL (File Abstraction Layer) y mostrando planos como overlay. La integración de mapas se realiza mediante Leaflet o Google Maps, tomando las geocoordenadas de FlowFact.

## Problemas frecuentes y soluciones

**Faltan imágenes tras la importación.** Las exportaciones OpenImmo referencian imágenes por nombre de archivo pero no siempre las entregan. Solución: configurar la exportación para que las imágenes se incrusten como Base64 en el XML o se transfieran por FTP en paralelo. Con la API REST, las imágenes se descargan mediante endpoints propios y deben importarse como referencias FAL en TYPO3.

**Las propiedades desaparecen tras la sincronización.** Cuando FlowFact desactiva o elimina una propiedad, el importador TYPO3 debe decidir: eliminar el registro, ocultarlo o marcarlo como "vendido". Los importadores estándar suelen eliminar de forma agresiva. Solución: implementar un soft-delete que marque las propiedades como "inactivas" y solo las elimine físicamente después de 30 días. Así se preservan las URLs relevantes para SEO y se pueden configurar redirecciones 301 a la página de resumen.

**Las consultas del formulario de contacto se pierden.** El formulario envía un email, pero el lead no se crea como contacto en FlowFact. Solución: crear las consultas del formulario como contacto con referencia a la propiedad vía la API de FlowFact. El agente responsable ve el lead directamente en su panel. Para ello, el formulario necesita el ID de propiedad de FlowFact como campo oculto.

## Migración y compatibilidad de versiones

FlowFact introdujo en 2019 una plataforma completamente nueva (FlowFact v3). La versión anterior (FlowFact Classic) sigue en funcionamiento pero no recibe nuevas funcionalidades. La API REST solo está disponible en v3. Las integraciones OpenImmo existentes funcionan con ambas versiones, pero el enfoque basado en API solo es posible con v3.

En el lado TYPO3, no existe una extensión oficial de FlowFact con soporte v12/v13 en el TER. La mayoría de las instalaciones usan importadores a medida o la extensión openimmo (con adaptaciones). Gosign recomienda, al actualizar TYPO3 a v12+, migrar simultáneamente la conexión inmobiliaria a la API REST de FlowFact, en lugar de portar el flujo de trabajo con XML OpenImmo. El enfoque basado en API requiere menos mantenimiento y permite funcionalidades como la disponibilidad en tiempo real, imposibles con la exportación XML.

Un proyecto típico de integración FlowFact-TYPO3 (importación de propiedades, función de búsqueda, páginas de detalle, formulario de contacto con routing de leads) se estima en 10 a 15 días de desarrollo. El mantenimiento continuo se limita a actualizaciones de la API y ajustes ocasionales ante cambios en el esquema de FlowFact.

--- fluid_fpdf TYPO3 - PDF desde plantillas | Gosign ---
> fluid_fpdf: generar PDFs desde Fluid Templates. Facturas, certificados, informes. Implementación acelerada con IA.

## Cuando los PDFs se generan desde datos en lugar de capturas de pantalla, se necesita fluid_fpdf

Existen dos enfoques fundamentalmente diferentes para generar PDFs en TYPO3. El enfoque de captura (web2pdf): la página web renderizada se captura como imagen y se empaqueta en un PDF. Sencillo, pero el resultado parece una página web impresa. El enfoque basado en datos (fluid_fpdf): una plantilla Fluid define el layout del PDF, los datos de TYPO3 rellenan los marcadores, el resultado es un documento limpio con diseño corporativo. Facturas, certificados, presupuestos, informes: todo lo que debe existir como documento necesita el enfoque basado en datos.

fluid_fpdf utiliza la librería FPDF (una clase PHP ligera para generación de PDF) y la conecta con el motor de plantillas Fluid de TYPO3. El resultado: los desarrolladores escriben layouts PDF en el mismo lenguaje de plantillas que usan para plantillas HTML.

## Escenarios de uso habituales

**Generación automatizada de facturas.** Una tienda online o sistema de reservas en TYPO3 genera una factura con cada pedido. Los datos de factura (partidas, precios, datos del cliente, impuestos) provienen de la base de datos, el layout de una plantilla Fluid. En un proveedor de eventos, fluid_fpdf genera 200-300 facturas al mes sin intervención manual.

**Certificados de participación y confirmaciones.** Centros de formación, asociaciones y empresas emiten certificados tras formaciones, talleres o exámenes. El nombre del participante, la fecha, el nombre del curso y la firma del formador se toman automáticamente de los datos TYPO3.

**Presupuestos y exposés.** Agencias inmobiliarias, consultoras y agencias crean presupuestos con contenidos variables: datos del cliente, servicios seleccionados, precios individuales. El layout PDF es fijo (diseño corporativo), los contenidos varían. fluid_fpdf rellena la plantilla con los datos de un formulario TYPO3 o un módulo de backend.

## Arquitectura técnica

fluid_fpdf conecta dos sistemas: el motor de plantillas Fluid de TYPO3 y la librería FPDF. La arquitectura trabaja en tres pasos. Primero: la plantilla Fluid define la estructura del PDF usando ViewHelpers especiales para elementos PDF. Segundo: TYPO3 proporciona los datos. Tercero: FPDF renderiza el PDF.

El soporte de fuentes es un detalle importante: FPDF soporta por defecto solo 14 fuentes. Para fuentes corporativas, los archivos TTF deben convertirse como archivos de fuente FPDF. La presentación de tablas requiere posicionamiento manual: cada celda se posiciona de forma absoluta o relativa a la celda anterior.

## Problemas frecuentes y soluciones

**Los caracteres UTF-8 no se muestran correctamente.** FPDF trabaja internamente con codificación Latin-1. Diéresis, caracteres polacos o letras cirílicas requieren soporte UTF-8. Solución: usar tFPDF (una variante UTF-8 de FPDF) en lugar de FPDF. Alternativamente: usar mPDF, que soporta UTF-8 nativamente.

**Saltos de página con contenidos dinámicos.** Una factura con 5 partidas cabe en una página, una con 50 necesita 3 páginas. FPDF no realiza saltos de página automáticos. Solución: comprobar la altura de página restante antes de cada partida e insertar una nueva página cuando sea necesario.

**El desarrollo de layouts es laborioso.** Sin vista previa visual, el desarrollador debe generar el PDF tras cada cambio para ver el resultado. Solución: configurar una ruta de preview que muestre el PDF en el navegador (modo de salida "Inline" en lugar de "Download").

## Migración y compatibilidad de versiones

fluid_fpdf soporta TYPO3 v10 y v11. Para v12 no existe versión oficial, el esfuerzo de portabilidad es moderado (ajustes Extbase, registro de ViewHelpers).

Las alternativas para TYPO3 v12/v13: EXT:pdfviewhelpers (usa TCPDF en lugar de FPDF, más funciones, mantenimiento activo, compatible con v12), una solución personalizada con mPDF como paquete Composer (HTML/CSS como entrada, layout más sencillo que con FPDF) o una solución headless con un servicio PDF externo.

La migración de fluid_fpdf a EXT:pdfviewhelpers es manejable: la estructura de plantillas es similar (basada en ViewHelpers), pero los nombres y parámetros de ViewHelpers difieren. En un proyecto con 5 plantillas PDF, el esfuerzo de migración es de 2-4 días. Gosign ha implementado generación de PDF en TYPO3 con todas las librerías habituales y asesora sobre la solución adecuada según los requisitos concretos.

--- focuspoint TYPO3 - Recorte inteligente de imágenes | Gosign ---
> focuspoint para TYPO3: recorte automático de imágenes con punto focal inteligente. Optimización responsive, acelerado con IA.

## focuspoint evita que las imágenes pierdan las áreas importantes del motivo al recortarse de forma responsive, ya que la extensión fija un punto focal en el que el recorte queda alineado con cualquier relación de aspecto

Quien usa imágenes en un sitio responsive conoce el problema: un retrato vertical que en el teaser solo mide 200 píxeles de alto muestra de pronto solo el cuello o la frente. Una foto de paisaje que aparece como franja estrecha en el área hero muestra el cielo en lugar de las montañas. El centrado automático lleva a que los motivos principales queden cortados, porque el centro matemático rara vez coincide con el centro real del motivo. focuspoint lo resuelve: los redactores fijan en el backend un punto de la imagen que debe mantenerse visible en cada recorte. La salida se adapta a cualquier relación de aspecto sin tener que generar una variante de imagen propia por cada formato.

La diferencia con un pipeline clásico de edición de imagen con recortes fijos es grande. En lugar de mantener para desktop, tablet y móvil una versión recortada por separado, hay una imagen original con un punto focal y tantos formatos de salida como se quiera, calculados automáticamente por el sistema. Para redacciones con muchas imágenes eso reduce drásticamente el tiempo de mantenimiento, y para marketing abre la posibilidad de introducir nuevas relaciones de aspecto de imagen sin retrabajo.

## Escenarios típicos de uso

El primer caso clásico son las páginas de persona y equipo. Una web corporativa muestra retratos de empleados en distintos layouts: como avatar redondo en la cabecera, como baldosa cuadrada en la lista de equipo, como formato ancho en la página de detalle. Sin punto focal, el fotógrafo debe encuadrar exactamente al centro o la redacción crea una variante por cada layout. Con focuspoint la redacción fija una vez un punto sobre la cara y la imagen funciona en todos los contextos.

El segundo caso son las fotos de producto y de espacios. Agentes inmobiliarios, hoteleros y tiendas de muebles trabajan con fotos en las que el motivo real - un sofá, una vista de habitación, un detalle de producto - no está en el centro de la imagen. focuspoint permite seleccionar exactamente ese motivo y garantiza que no se pierda tampoco en móviles.

Tercer uso: teasers de revista y artículo. Las imágenes editoriales de artículo tienen a menudo un punto de interés claro, por ejemplo un ponente en un escenario o un producto en una escena. En listas de teaser con miniaturas verticales, ese punto de interés quedaría frecuentemente fuera del encuadre sin punto focal.

## Arquitectura técnica

focuspoint amplía el sistema FAL de TYPO3 con dos campos de metadatos adicionales: focus_point_x y focus_point_y. Ambos se mantienen en el backend mediante un elemento de formulario que muestra la imagen original como área de selección. El redactor hace clic sobre el punto relevante, la posición relativa se guarda. Técnicamente son dos valores en coma flotante entre cero y uno que describen la fracción del ancho y del alto de la imagen.

Al renderizar en el frontend, el punto focal lo evalúa el ViewHelper Fluid. En lugar del ViewHelper estándar "f:image", la extensión utiliza un ViewHelper propio que realiza el cálculo del recorte teniendo en cuenta el punto focal y genera la imagen mediante el pipeline GIFBUILDER de TYPO3 en el tamaño objetivo deseado. El resultado se cachea y solo se regenera si hay cambios.

La extensión convive con todos los formatos de imagen habituales (JPEG, PNG, WebP, AVIF) y utiliza para el procesamiento propiamente dicho ImageMagick o GraphicsMagick, es decir, el mismo stack sobre el que TYPO3 se apoya de todos modos. Para lazy loading e integración srcset no hay conflictos: el ViewHelper puede anidarse en elementos picture con varias sources y entrega para cada breakpoint el recorte adecuado.

## Problemas frecuentes y soluciones

El primer problema es el orden de los ViewHelpers. Quien integra focuspoint en plantillas existentes que ya trabajan con "f:image" y argumentos de recorte manuales debe poner el ViewHelper de focuspoint en el lugar del estándar, no alrededor. De lo contrario, ambas lógicas corren una contra otra y el resultado ignora el punto focal. La solución es una migración limpia de todas las referencias de imagen del sitepackage al nuevo ViewHelper.

Segundo problema: invalidación de caché. Cuando los redactores cambian el punto focal, la caché de imagen debe descartarse, si no seguirán viendo el recorte antiguo. TYPO3 vacía normalmente la caché de imagen en cambios de la imagen original, no en cambios de metadatos. La solución es un EventListener que, ante cambios en los campos del punto focal, borre específicamente los processed files afectados.

Tercer problema: resultados inconsistentes entre la previsualización del backend y el frontend. La previsualización del backend usa una ruta de renderizado distinta a la del frontend, lo que puede llevar a pequeñas diferencias. Solución pragmática: en el backend mostrar solo una vista previa aproximada y remitir a los redactores al frontend como referencia vinculante.

## Migración y compatibilidad de versiones

TYPO3 trae desde la versión 9 un editor de recorte nativo en el backend que permite variantes individuales por imagen. Para casos de uso sencillos basta. focuspoint se distingue en que el punto focal se fija una vez y se propaga automáticamente a todas las variantes de recorte, en lugar de editar cada variante por separado. Quien tiene muchas imágenes y poco tiempo de redacción sale mejor a largo plazo con focuspoint.

La extensión es compatible con TYPO3 v11, v12 y v13. Al actualizar desde versiones más antiguas, la estructura de metadatos FAL y los ViewHelpers utilizados deberían adaptarse a la sintaxis actual.

Una nueva clase de alternativas son las detecciones de saliency asistidas por IA, que derivan el punto focal automáticamente del contenido de la imagen. Esos enfoques reducen aún más el trabajo editorial, porque los redactores ya no tienen que fijar el punto, sino solo corregirlo en casos excepcionales. Para TYPO3 hay primeras integraciones de esta técnica, pero aún no son estándar y deberían evaluarse por proyecto.

Gosign configura focuspoint y lo integra en arquitecturas Fluid. El análisis asistido por IA de los layouts de diseño sugiere presets de recorte óptimos para todos los breakpoints, de modo que los redactores no tienen que probar cada formato por separado en el mantenimiento de imágenes.

--- Linked Checkbox TYPO3 - Elemento de formulario | Gosign ---
> Elemento checkbox personalizado para el TYPO3 Form Framework con etiqueta vinculada.

## form_element_linked_checkbox hace realmente clicables los consentimientos RGPD

El Form Framework del núcleo TYPO3 conoce una casilla de verificación, pero no una casilla con etiqueta enlazada. Quien trabaja con el elemento estándar no puede poner en la etiqueta un enlace a la política de privacidad o a los términos, y eso es precisamente un requisito que aparece en cualquier formulario. La extensión form_element_linked_checkbox cubre ese hueco con un elemento de formulario personalizado limpio que combina texto y enlace de forma adecuada. Para cualquier instalación TYPO3 que trabaje con el Form Framework nativo, esta extensión es prácticamente obligatoria. Sin ella solo queda el workaround de ampliar el texto de la etiqueta con un bloque de texto contiguo, lo que no solo parece desordenado, sino que además resulta problemático para los lectores de pantalla y la accesibilidad.

## Escenarios típicos están en el ámbito de compliance de cualquier web corporativa

El primer y más frecuente escenario son los consentimientos RGPD al pie de formularios de contacto, boletín y candidatura. El texto "He leído la política de privacidad y acepto el tratamiento de mis datos" debe contener un enlace clicable a /privacidad, sin que el visitante tenga que marcar la casilla para abrirlo. form_element_linked_checkbox cubre exactamente ese caso.

Un segundo escenario son las aceptaciones de condiciones generales en formularios de registro y compra. Las universidades lo utilizan en inscripciones a cursos, las asociaciones en solicitudes de alta, los proyectos de comercio electrónico con el Form Framework de TYPO3 en los checkouts. Aquí a menudo no se pide un único enlace, sino varios (condiciones, desistimiento, privacidad), que deben integrarse en la misma etiqueta.

El tercer escenario afecta a los boletines Double-Opt-In. Antes del alta el destinatario debe confirmar expresamente que se suscribe al boletín, con enlace a las notas de privacidad específicas del boletín. form_element_linked_checkbox permite usar varias casillas con enlace propio en el mismo formulario, de modo que, junto al consentimiento de privacidad, también se pueda pedir el consentimiento explícito al boletín como elemento separado. Eso es importante, porque la AEPD interpreta el RGPD en el sentido de que se requieren consentimientos separados, y una casilla genérica "acepto todo" no basta jurídicamente.

## Arquitectura técnica dentro del sistema de plugins del Form Framework

El Form Framework de TYPO3 está diseñado para ser ampliable a propósito: cualquier extensión puede registrar elementos de formulario propios, que aparecen en el editor YAML y son utilizables en el backend por arrastrar y soltar. form_element_linked_checkbox aprovecha ese mecanismo y registra un nuevo elemento "LinkedCheckbox" mediante el YAML de configuración del Form y el área de definiciones de elementos de formulario. Los redactores arrastran el elemento a su formulario, igual que harían con una casilla estándar, y configuran la etiqueta, el texto del enlace y el destino en el panel de detalle.

Internamente la extensión amplía la clase Checkbox y añade propiedades para linkTarget, linkText y wrapLabel. El renderizado corre a través de un partial Fluid propio que divide el texto de la etiqueta en "before", "linkText" y "after" y sitúa el área clicable solo sobre la parte del enlace. El clic en el enlace abre la página de destino sin conmutar la casilla. Para la accesibilidad eso es importante, porque los lectores de pantalla leen el enlace como elemento separado y la casilla puede manejarse de forma independiente.

La configuración se realiza directamente en el editor YAML del Form Framework: tras arrastrar el elemento a un formulario aparecen en la columna de detalle derecha los campos "Etiqueta antes del enlace", "Texto del enlace", "Etiqueta después del enlace" y "Destino del enlace". El destino puede ser una página interna, un enlace a archivo o una URL externa. La validación obligatoria se fija, como en el elemento estándar, en la pestaña Validators.

## Problemas frecuentes: multilingüismo, estilos y mensajes del validator

El primer tema de soporte es la traducción. La etiqueta consta de tres partes, y cada parte debe mantenerse por separado en cada idioma. En la práctica eso significa que, para una instalación bilingüe (ES/EN), el mantenimiento se duplica. Quien trabaje con ext:l10nmgr debería referenciar explícitamente las claves LLL en la definición del formulario, para que import y export funcionen limpiamente. Un truco de proyectos grandes: mantener las tres partes de la etiqueta en una única clave LLL con placeholders y componerlas en el servidor en la salida. Eso reduce claramente el número de cadenas a traducir.

El segundo tema es el estilado. Muchos sistemas de diseño trabajan con casillas personalizadas que se reproducen mediante CSS desde una construcción span o label. La plantilla por defecto de la extensión entrega un wrapper sencillo que choca con algunos frameworks CSS. Recomendamos sobrescribir el partial en el overlay del paquete y adaptar la estructura al estilado del resto del formulario.

En tercer lugar, los mensajes de error del validator son un tropiezo habitual. Si el usuario no marca la casilla, debería aparecer "Por favor, acepte la política de privacidad" en lugar del mensaje por defecto "Campo obligatorio". La extensión soporta mensajes de error personalizados mediante formElementsDefinition en el YAML del formulario; el mensaje puede adaptarse por elemento. Para la accesibilidad eso es importante, porque los lectores de pantalla leen el mensaje de error directamente y los mensajes inespecíficos no ayudan. Recomendamos formular cada mensaje de error de manera que sea comprensible con independencia del contexto.

## TYPO3 v12 y v13 están totalmente soportados, la migración desde v10 exige adaptación de YAML

form_element_linked_checkbox está disponible para TYPO3 v11, v12 y v13. La estructura YAML del Form Framework ha cambiado en detalles entre v10 y v12, sobre todo en el registro de elementos personalizados. Al actualizar una instalación v10, las definiciones de formulario que usan el elemento deben adaptarse a la nueva sintaxis YAML.

En proyectos de Gosign migramos la extensión como parte del refactoring del Form Framework, no por separado. El esfuerzo suele ser mínimo, porque el elemento se referencia en cada formulario solo por su identificador de tipo. En la migración comprobamos además si los textos de consentimiento RGPD se renderizan correctamente en cada idioma tras el upgrade de TYPO3 y actualizamos los enlaces a privacidad si han cambiado en estructura de URL o contenido textual.

--- Formlog TYPO3 - Registro de formularios | Gosign ---
> Extensión de registro de formularios para TYPO3: protocolar todas las entradas de formularios en el backend. Respaldo para correos fallidos, análisis ...

## Por qué una de cada tres consultas de contacto en TYPO3 se pierde sin logging

Los formularios de contacto son el canal de leads más importante en webs corporativas. Pero el Form Framework de TYPO3 no almacena las entradas en base de datos por defecto - solo envía emails. Si el servidor de correo cae, el registro SPF está mal configurado o el timeout SMTP interviene, la consulta se pierde. Sin backup, sin seguimiento, sin análisis. Formlog cierra esta brecha registrando cada entrada de formulario en la base de datos TYPO3, independientemente de si el envío del email fue exitoso.

En la práctica esto afecta a más empresas de lo que se piensa: las tasas de entrega de emails de servidores web se sitúan según estudios entre el 85 % y el 95 %. Con 100 consultas de contacto al mes, eso significa de 5 a 15 leads perdidos.

## Escenarios de uso habituales

**Protección contra caídas del email.** Una empresa mediana opera 3 formularios de contacto en su web TYPO3. El servidor SMTP del hoster tiene un timeout de 6 horas durante el fin de semana. Sin Formlog, todas las consultas de ese período se pierden. Con Formlog, el equipo de marketing encuentra el lunes todas las entradas en el backend TYPO3 y puede hacer seguimiento manual.

**Prueba de cumplimiento para RGPD e ISO 27001.** Las empresas deben poder demostrar cuándo se recibieron qué datos personales y cuándo se eliminaron. Formlog almacena entradas con marca temporal y ofrece eliminación automática configurable tras X días. Para auditorías ISO 27001 proporciona documentación sin lagunas del procesamiento de datos. La AEPD y las directrices europeas de protección de datos exigen esta trazabilidad.

**Análisis del comportamiento de entrada.** Qué campos se dejan frecuentemente vacíos. En qué paso del formulario abandonan los usuarios. Formlog hace visibles estos datos en el backend.

## Arquitectura técnica

Formlog se integra como Finisher en el TYPO3 Form Framework (EXT:form). Cada formulario configurado con un Finisher Formlog escribe sus entradas tras el envío en una tabla de base de datos propia (`tx_formlog_entries`). Cada entrada se almacena como array serializado en JSON junto con metadatos (marca temporal, identificador de formulario, idioma, página). Un módulo de backend propio permite filtrar, buscar y exportar como CSV las entradas registradas. La eliminación RGPD funciona mediante tarea del Scheduler que borra automáticamente entradas tras un número configurable de días (estándar: 90).

## Problemas frecuentes y soluciones

**Formlog no registra todos los campos del formulario.** El Finisher Formlog debe configurarse tras el paso de validación pero antes del Finisher de redirección. Si la redirección se ejecuta primero, el Finisher Formlog ya no se ejecuta. Solución: verificar en la configuración YAML el orden de los Finishers - Formlog debe estar en posición 1, antes de email y redirección.

**El módulo de backend no muestra entradas.** Frecuentemente un problema de permisos: el usuario o grupo de backend no tiene acceso al módulo Formlog. Solución: activar el módulo `formlog` en la configuración de grupos de backend bajo "Módulos permitidos".

**La eliminación automática no funciona.** El TYPO3 Scheduler debe estar correctamente configurado y ejecutarse regularmente (cronjob cada 5 a 15 minutos). Sin Scheduler funcional, la tarea de eliminación nunca se ejecuta.

## Migración y compatibilidad de versiones

Formlog fue desarrollado por Pagemachine y está disponible como paquete Composer (`pagemachine/typo3-formlog`). La extensión es compatible con TYPO3 v10 a v12 LTS. Para TYPO3 v13 aún no hay release oficial, pero el código se basa en APIs estables de TYPO3 (Form Framework Finisher, Extbase Repository Pattern), por lo que la compatibilidad es alcanzable con esfuerzo razonable.

Quien migra de Powermail al TYPO3 Form Framework pierde el logging integrado en Powermail. Formlog es el sustituto recomendado. Gosign migra formularios incluyendo la configuración de logging y asegura que los datos existentes no se pierdan.

Un aspecto que muchos equipos de proyecto pasan por alto: Formlog no es solo una herramienta de backup, sino también una herramienta de auditoría. Cuando un cliente afirma haber enviado una consulta hace 3 semanas que nunca fue respondida, Formlog aporta la prueba - la consulta existe con marca temporal, o nunca fue enviada. Para empresas con acuerdos de nivel de servicio y gestión de reclamaciones, eso es una ventaja medible.

--- gb_events TYPO3 - Eventos | Gosign ---
> Extensión de eventos para TYPO3: presentación sencilla de eventos y vista de calendario. Más ligera que sf_event_mgt, para eventos sin función de registro.

## No todo evento necesita registro, pero todos necesitan una presentación adecuada

sf_event_mgt es el estándar para gestión de eventos en TYPO3: registro, lista de espera, pago, gestión de participantes. Pero muchas organizaciones solo muestran eventos, sin registro online. Un calendario de conciertos, un programa de eventos municipal, los horarios de un centro de educación de adultos: en todos estos escenarios sf_event_mgt sería excesivo. gb_events llena este hueco: presentación sencilla de eventos con vista de calendario, sin la sobrecarga de un sistema completo de gestión de eventos.

La extensión está hecha para organizaciones que quieren publicar fechas, pero no gestionarlas. Sin formulario de registro, sin lista de participantes, sin procesamiento de pagos. A cambio, una presentación de lista limpia, una vista de calendario y una página de detalle por evento.

## Escenarios de uso habituales

**Sitios web de parroquias y comunidades.** Servicios religiosos, conciertos, fiestas comunitarias: un calendario de comunidad típico tiene 20-40 eventos al mes. Los visitantes quieren ver qué ocurre y cuándo, y quizás transferir las fechas a su calendario personal. gb_events lo cubre con mínimo esfuerzo de configuración.

**Centros de formación y educación de adultos (vista general de programas).** La inscripción a cursos se gestiona mediante un sistema externo, pero el programa debe ser buscable en el sitio web TYPO3. gb_events muestra los cursos como lista de eventos, filtrados por categoría y periodo temporal.

**Series de eventos con fechas recurrentes.** Un club deportivo tiene entrenamiento lunes y miércoles, una tertulia cada primer jueves. gb_events presenta fechas recurrentes sin que cada cita individual deba crearse manualmente.

## Arquitectura técnica

gb_events se basa en Extbase/Fluid y utiliza una tabla de base de datos propia. Cada evento tiene los campos: título, descripción, fecha de inicio, fecha de fin, lugar, imagen, categoría y opcionalmente una regla de repetición. Las categorías usan las categorías del sistema TYPO3.

El frontend consta de tres vistas: vista de lista (cronológica, filtrable por categoría y periodo), vista de calendario (presentación mensual con días clicables) y vista de detalle. Todas las vistas son plantillas Fluid y se pueden sobrescribir en el sitepackage.

La vista de calendario renderiza una cuadrícula HTML Table con 7 columnas (días de la semana). La navegación entre meses se realiza mediante parámetro de enlace (GET), no por AJAX. Esto es favorable para SEO porque cada mes tiene su propia URL.

## Problemas frecuentes y soluciones

**Los eventos no aparecen en la vista de lista.** Causa frecuente: la carpeta de almacenamiento (Storage PID) en el plugin no coincide con la carpeta donde se crearon los eventos. Solución: seleccionar la carpeta de almacenamiento correcta en el FlexForm del plugin.

**Los eventos pasados desaparecen inmediatamente.** gb_events oculta eventos por defecto tan pronto como se supera la fecha de fin. Solución: ajustar la consulta del repositorio en el controlador o configurar un modo de vista de lista "Archivo" separado.

**Sin función de exportación iCal.** Los visitantes quieren transferir eventos a su calendario. Solución: crear un Page Type propio para la exportación iCal. El esfuerzo es de aproximadamente 3 horas de desarrollo.

## Migración y compatibilidad de versiones

gb_events soporta TYPO3 v10 y v11. Para v12 existe una versión comunitaria en GitHub. Para v13 no hay planificación actualmente.

La alternativa para TYPO3 v12/v13 es sf_event_mgt, la extensión de eventos significativamente más amplia y mejor mantenida, que soporta v12 y v13 oficialmente. Quien no necesite función de registro puede configurar sf_event_mgt sin registro y aún así utilizar la presentación de eventos y la vista de calendario.

La migración de gb_events a sf_event_mgt requiere una migración de datos: transferir los eventos de una tabla a otra. Los campos son similares pero no idénticos. Un script de migración basado en SQL lo resuelve en 1-2 horas. Gosign asesora sobre la solución más económica y se encarga de la migración según sea necesario.

--- Geocoding TYPO3 - Coordenadas | Gosign ---
> Extensión de geocoding para TYPO3: convertir direcciones automáticamente en coordenadas GPS.

## Por qué todo buscador de sucursales TYPO3 sin geocodificación fracasa por la calidad de datos

Los buscadores de sucursales, la búsqueda de distribuidores y la búsqueda por radio tienen el mismo fundamento: coordenadas GPS. Pero las empresas almacenan datos de ubicación como direcciones - calle, número, código postal, ciudad. La conversión de dirección a coordenada (geocodificación) no ocurre sola. geocoordinates resuelve este problema de forma automatizada: la extensión monitoriza campos de dirección en registros TYPO3 y calcula las coordenadas GPS correspondientes vía servicio de geocodificación ante cada cambio.

Sin extensión de geocodificación, los editores tendrían que copiar manualmente latitud y longitud de Google Maps para cada ubicación. Con 50 sedes, eso es una hora de trabajo. Con 500 sedes, un día completo - y con cada cambio de dirección el proceso empieza de nuevo.

## Escenarios de uso habituales

**Geocodificación automática para registros tt_address.** Una empresa con 120 sedes en España gestiona todas las direcciones en la extensión TYPO3 tt_address. geocoordinates registra un hook DataHandler en la tabla tt_address. En cuanto un editor cambia una dirección o crea una nueva sede, se llama al servicio de geocodificación en segundo plano. Las coordenadas se escriben en los campos de base de datos `latitude` y `longitude`. La extensión de mapas maps2 lee estos campos y coloca el marcador en la posición correcta.

**Geocodificación por lotes en migraciones de datos.** Una empresa migra 2.000 direcciones de un sistema antiguo a TYPO3. Los registros importados tienen calle y código postal pero no coordenadas. geocoordinates ofrece un comando CLI que geocodifica todos los registros sin coordenadas en un lote.

**Búsqueda por radio basada en códigos postales.** Un taller ofrece búsqueda por radio: "Encuentra el partner más cercano." El visitante introduce su código postal, geocoordinates lo convierte en coordenadas, y un cálculo de distancia SQL (fórmula de Haversine) devuelve todas las sedes en un radio de 25, 50 o 100 km, ordenadas por distancia.

## Arquitectura técnica

geocoordinates se integra como hook DataHandler en el TYPO3 Core. La extensión monitoriza tablas y campos configurables. Cuando cambia un campo de dirección monitorizado, se lanza asíncronamente una petición de geocodificación.

La extensión soporta dos proveedores: Google Geocoding API (alta precisión, disponible mundialmente, requiere API key con facturación activada, 5 USD por 1.000 peticiones, gratuito hasta 40.000/mes) y OpenStreetMap Nominatim (gratuito, sin registro, limitación de 1 petición/segundo, conforme al RGPD al no transferir datos personales fuera de Europa, alineado con los criterios de la AEPD).

Las coordenadas se almacenan en campos de base de datos configurables (estándar: `latitude` y `longitude` como campos `DOUBLE`). Para la búsqueda por radio, geocoordinates proporciona una función de distancia Haversine que se ejecuta a nivel de base de datos, no en PHP - algo crítico para el rendimiento con grandes volúmenes de datos.

## Problemas frecuentes y soluciones

**La geocodificación devuelve coordenadas incorrectas para direcciones españolas.** Las direcciones con caracteres especiales (tildes, ñ) pueden causar problemas si la API no procesa correctamente la codificación de caracteres. Solución: asegurar que los datos de dirección se envían a la API en UTF-8.

**La Google Geocoding API devuelve "OVER_QUERY_LIMIT".** Con geocodificación por lotes de más de 50 peticiones por segundo, Google limita la API. Solución: activar rate limiting en el comando de lotes (máx. 40 peticiones/segundo para cuentas estándar).

**Nominatim devuelve resultados diferentes para la misma dirección.** Los datos de OpenStreetMap son mantenidos por la comunidad y pueden cambiar. Solución: marcar las coordenadas ya geocodificadas como "verificadas" y solo volver a geocodificar cuando cambie manualmente la dirección.

## Migración y compatibilidad de versiones

geocoordinates está disponible como paquete Composer para TYPO3 v10 a v12. La extensión la mantiene Stefan Froemken, quien también desarrolla maps2. Ambas extensiones están coordinadas entre sí pero pueden usarse independientemente.

Gosign combina geocoordinates con maps2 como estándar para entregar un stack completo de buscador de sucursales: entrada de dirección por el editor, geocodificación automática en segundo plano, visualización en mapa con marcador y popup en frontend, búsqueda por radio con entrada de código postal para el visitante. El stack se configura en 2 a 3 días y cubre los requisitos del 90 % de los proyectos de buscador de sucursales.

--- Gewinnspiel TYPO3 - Sorteo en línea | Gosign ---
> Sorteo en TYPO3: participación, sorteo, premios. Conforme con el RGPD, desarrollo acelerado con IA.

## Los sorteos online en TYPO3 rara vez fallan por la técnica, casi siempre por el derecho

Programar un sorteo lleva 3-5 días: formulario, validación, sorteo, email al ganador. Hacerlo legalmente seguro lleva más tiempo, porque los requisitos jurídicos superan el esfuerzo técnico. Condiciones de participación, consentimiento de marketing separado, prohibición de vinculación, eliminación automática de datos tras el fin del sorteo, verificación de edad, exclusión de empleados: no son extras opcionales, sino obligaciones legales. Un sorteo TYPO3 sin estas garantías arriesga sanciones y reclamaciones.

TYPO3 no ofrece extensión estándar para sorteos. La solución es siempre un desarrollo personalizado que refleje exactamente los requisitos del sorteo concreto. Gosign desarrolla estos módulos como extensiones TYPO3 basadas en Extbase con una capa completa de cumplimiento RGPD.

## Escenarios de uso habituales

**Campañas de marketing con sorteo de productos.** Un fabricante de bienes de consumo sortea 10 productos entre todos los participantes que cumplimenten un formulario. El sorteo dura 4 semanas, tras lo cual se seleccionan los ganadores por generador aleatorio y se les notifica por email. Requisitos técnicos: formulario con campos obligatorios, participación única por dirección de email (Double-Opt-In), casilla de condiciones de participación (no preseleccionada), casilla separada para consentimiento de newsletter (opcional, no vinculada a la participación), eliminación automática de datos 30 días tras el fin.

**Sorteos vinculados a redes sociales.** Los participantes son dirigidos desde Instagram o Facebook al sitio web TYPO3, donde cumplimentan el formulario. La plataforma de redes sociales no debe servir como mecanismo de participación (las condiciones de las plataformas lo prohíben), sino solo como fuente de tráfico.

**Sorteos recurrentes de adviento o mensuales.** Un calendario de adviento con 24 puertas, cada una con un premio propio. Técnicamente más exigente: 24 sorteos en una extensión, activación temporizada, sorteo separado por día, seguimiento de participación global.

## Arquitectura técnica

Un módulo de sorteo TYPO3 consta de cinco componentes: formulario de participación (controlador Extbase con plantilla Fluid), comprobación de duplicados (Double-Opt-In por email de confirmación), sorteo (generador aleatorio criptográfico `random_int()` en PHP), notificación al ganador (email automático) y ciclo de vida de datos (eliminación automática mediante tarea Scheduler configurable).

## Problemas frecuentes y soluciones

**Participaciones de bots falsean los resultados.** Solución: campo honeypot, limitación de tasa y Double-Opt-In como triple protección. El Double-Opt-In es la protección más eficaz: los bots pueden rellenar formularios, pero no hacer clic en emails de confirmación.

**Violación de la prohibición de vinculación.** La participación en el sorteo no debe estar vinculada a un consentimiento de marketing. Si la casilla de newsletter es campo obligatorio, hay infracción. Solución: implementar el consentimiento de marketing siempre como casilla opcional, no preseleccionada.

**Rendimiento bajo alta carga simultánea.** Un sorteo viral con 10.000 participaciones en una hora sobrecarga el servidor. Solución: configurar el envío del formulario como página sin caché (USER_INT), pero cachear la propia página del sorteo (USER).

## Migración y compatibilidad de versiones

Los módulos de sorteo son desarrollos personalizados y no tienen ruta de migración estándar. En actualizaciones TYPO3, las APIs Extbase deben ajustarse. El esfuerzo por actualización major es de 1-2 días para un módulo de sorteo típico.

Para sorteos recurrentes merece la pena una extensión genérica que se configure mediante módulo de backend. Esta inversión única (5-8 días de desarrollo) ahorra un 80% del esfuerzo en cada sorteo posterior. Gosign desarrolla estos módulos como extensiones TYPO3 reutilizables y se encarga del borrador de las condiciones de participación si es necesario; la aprobación jurídica corresponde al cliente.

--- Hero-Slider TYPO3 - Rendimiento | Gosign ---
> Extensión Hero Slider para TYPO3. A menudo lastre para el rendimiento: imágenes grandes, librerías JS pesadas.

## El hero slider es la zona más cara de un sitio web TYPO3, medida en tiempo de carga

La zona hero es lo primero que ven los visitantes. Con un slider, también es lo más lento que ven. Un hero slider típico en TYPO3 carga 3-5 imágenes de gran formato (cada una 500 KB-2 MB), una librería JavaScript (jQuery + plugin de slider: 120-200 KB), animaciones CSS y scripts de inicialización. En total son 3-12 MB de datos antes de que el visitante pueda hacer clic en cualquier parte. El Largest Contentful Paint (LCP) en estas configuraciones está rutinariamente por encima de 4 segundos, lo que Google clasifica como "deficiente" y cuesta posicionamiento.

La solución no es un slider mejor, sino o ningún slider o uno radicalmente ligero. Las soluciones solo CSS y las librerías de slider modernas como Swiper logran el mismo efecto visual con una fracción del tiempo de carga.

## Escenarios de uso habituales

**Páginas de inicio con campañas cambiantes.** Marketing quiere colocar prominentemente 3-5 mensajes. El slider rota automáticamente. El problema: estudios muestran consistentemente que solo el 1-2% de los visitantes interactúan más allá de la primera diapositiva. Las restantes se cargan pero no se ven. Un hero estático con un mensaje claro rinde mejor en tests A/B.

**Galerías de imágenes en la zona del encabezado.** Hoteles, restaurantes y espacios de eventos muestran impresiones como hero slider. Aquí un slider tiene sentido en contenido. La optimización de rendimiento: cargar solo la primera imagen inmediatamente, las restantes mediante lazy loading.

**Highlights de producto con animación.** Las transiciones CSS (`transform`, `opacity`) son más eficientes que las animaciones JavaScript y utilizan la GPU en lugar de la CPU. Un slider solo CSS con `scroll-snap-type` y `transition` logra 60 fps en cualquier dispositivo.

## Arquitectura técnica

La arquitectura óptima para un hero slider en 2026: **Opción 1: solo CSS (0 KB JavaScript).** `scroll-snap-type: x mandatory` en el contenedor, navegación mediante anchor links con `scroll-behavior: smooth`. Sin JavaScript necesario. **Opción 2: Swiper/Splide (29-139 KB JavaScript).** Funcionalidad completa de slider con touch, swipe, autoplay, paginación, lazy loading. **Opción 3: Hero estático (0 KB JavaScript, 1 imagen).** Una imagen, un titular, un CTA. La configuración más rápida y con mayor conversión.

## Problemas frecuentes y soluciones

**LCP superior a 4 segundos.** La imagen hero es el elemento LCP. Solución: cargar la primera imagen con `fetchpriority="high"` y `loading="eager"`. Las restantes diapositivas con `loading="lazy"`. Formato de imagen WebP/AVIF.

**Cumulative Layout Shift (CLS) por slider que carga tarde.** El contenedor del slider inicialmente no tiene altura, tras la inicialización JavaScript el layout salta. Solución: fijar la altura del contenedor por CSS (p.ej., `aspect-ratio: 16/9`).

**Autoplay no funciona en dispositivos móviles.** iOS Safari bloquea autoplay de vídeos y algunas animaciones CSS por ahorro de energía. Solución: desactivar autoplay en móviles y ofrecer navegación por swipe en su lugar.

## Migración y compatibilidad de versiones

La mayoría de extensiones hero slider en el TER están desactualizadas y soportan como máximo TYPO3 v10 o v11. Para v12/v13 se recomienda sin excepción un Custom Content Element en el sitepackage que integre una librería moderna o se base completamente en CSS.

La migración de sliders existentes se realiza en tres pasos: exportar datos de diapositivas, configurar nuevo elemento de contenido con plantilla moderna, y migrar los elementos de contenido existentes mediante SQL al nuevo CType. El esfuerzo: 1-2 días para la configuración técnica.

Gosign recomienda en cada proyecto hero slider primero la pregunta: ¿Realmente necesita el sitio web un slider? En el 70% de los casos, un elemento hero estático rinde mejor. Para el 30% restante, Gosign entrega una solución Swiper o solo CSS que permanece por debajo de 1,5 segundos de LCP.

--- Highcharts TYPO3 - Visualización de datos | Gosign ---
> Integrar diagramas interactivos de Highcharts en TYPO3. Charts, gráficos y visualizaciones de datos directamente en el CMS. Gosign también implementa ...

## Highcharts lleva la visualización de datos interactiva al backend de TYPO3 cuando los redactores deben mantener diagramas sin tener que trabajar en Excel o en herramientas externas

Los números, los indicadores y las tendencias pertenecen a las webs corporativas: como cifras de negocio en el área de relación con inversores, como datos de mercado en el content marketing, como resultados de evaluación en asociaciones y administraciones. La solución clásica son gráficos estáticos creados en Excel, exportados como PNG y subidos manualmente. Eso es laborioso y propenso a errores: si cambia un número, hay que rehacer todo el gráfico. Highcharts resuelve el problema generando los diagramas directamente a partir de datos estructurados, y lo hace de forma interactiva en el navegador, con tooltips, efectos hover y funciones de zoom. La integración con TYPO3 hace que el proceso editorial sea completamente backend: los redactores mantienen series de datos en una máscara de entrada y la extensión genera el diagrama.

La auténtica palanca de productividad aparece cuando las series de datos no se mantienen manualmente, sino que se tiran de fuentes externas. Un CSV del departamento de controlling, un export de un data warehouse o una llamada API a un panel interno entregan los números, y TYPO3 renderiza a partir de ellos el gráfico público. Esa separación entre fuente de datos y visualización convierte el mantenimiento de indicadores en un commit, no en un intercambio de capturas de pantalla.

## Escenarios típicos de uso

El caso clásico son las páginas de relación con inversores y de cifras de negocio. Una empresa cotizada en bolsa muestra evolución de facturación, número de empleados y cuotas de mercado como diagramas interactivos. En los resultados trimestrales, el equipo de relación con inversores simplemente actualiza la serie de datos, el diagrama se renueva automáticamente y los visitantes pueden ver con el mouseover los valores exactos por año.

El segundo caso son los resultados de evaluación y estudios en asociaciones, fundaciones y administraciones. Una encuesta a socios, un estudio medioambiental o una encuesta de coyuntura se presenta como diagrama de barras, líneas o tarta. Highcharts permite presentar conjuntos de datos complejos con muchas categorías de forma clara y ofrece funciones de exportación con las que los visitantes pueden llevarse los diagramas como imagen o PDF.

Tercer uso: content marketing y periodismo de datos. Los blogs corporativos y las revistas especializadas utilizan gráficos interactivos para explicar relaciones complejas: evolución de precios, cuotas de mercado, estadísticas de uso. La interactividad aumenta el tiempo de permanencia y hace que los contenidos sean citables por otros medios.

## Arquitectura técnica

Highcharts como librería JavaScript es un producto establecido de la empresa noruega Highsoft, que se distribuye bajo licencia comercial, pero es de uso gratuito para fines no comerciales. La integración con TYPO3 añade al CMS máscaras de backend para mantener series de datos y renderiza en el frontend el código JavaScript correspondiente que inicializa Highcharts.

Típicamente la extensión consta de un elemento de contenido en el que los redactores configuran tipo de diagrama (línea, barras, tarta, área), etiquetado de ejes, colores y series de datos. Cada serie puede mantenerse manualmente como tabla o tomarse de fuentes externas como archivos CSV, consultas a base de datos o APIs REST. En el frontend la extensión emite un contenedor div con JSON de configuración, y un bloque de script inicializa Highcharts y renderiza el diagrama del lado del cliente.

La cuestión de la licencia es central. Para proyectos TYPO3 comerciales debe adquirirse una licencia de Highcharts, que según alcance puede ir de unos cientos a varios miles de euros al año. Quien quiera evitarlo encontrará con Chart.js, ApexCharts o Plotly buenas alternativas bajo licencia MIT o Apache. La decisión depende de las features: Highcharts ofrece la paleta más amplia de tipos de diagrama y la mejor documentación, pero las alternativas cubren los casos estándar de forma fiable.

## Problemas frecuentes y soluciones

El primer problema es la licencia poco clara. Los proyectos empiezan con la suposición de que Highcharts es gratuito y, en el uso comercial, llega la factura. La solución está en una revisión temprana de la licencia: si el proyecto es comercial, o bien se presupuesta la licencia de Highcharts o bien se apuesta desde el principio por una alternativa libre. Gosign aclara esa cuestión en el kickoff.

Segundo problema: rendimiento con muchas series de datos. Un diagrama con miles de puntos bloquea el navegador al renderizarse. La solución es o bien la reducción de datos mediante agregación en el servidor, o bien el uso de módulos de Highcharts como Boost, que renderizan grandes volúmenes con WebGL. Para casos estándar basta con comprimir los datos brutos a una granularidad razonable antes de que lleguen al navegador.

Tercer problema: accesibilidad. Los diagramas interactivos son a menudo inaccesibles para los lectores de pantalla. Highcharts ofrece un módulo de accesibilidad que pone los datos disponibles como tabla estructurada en paralelo al diagrama visual. El complemento pragmático, conforme al Real Decreto 1112/2018, es mostrar bajo cada diagrama una tabla HTML regular con los mismos datos, oculta visualmente por CSS pero disponible para los lectores de pantalla.

## Migración y compatibilidad de versiones

Las integraciones TYPO3 para Highcharts existen en varias variantes con distinta calidad y actualidad. Para TYPO3 v11 hay extensiones mantenidas activamente; para v12 y v13 la selección es menor y a menudo requiere ajustes en ext_emconf y en las configuraciones de servicio. Quien empieza hoy desde cero debería revisar con sobriedad si una extensión existente aún encaja o si una integración en el sitepackage con una librería libre como Chart.js es el camino más a prueba de futuro.

En el escenario de upgrade, la versión de Highcharts es la magnitud crítica. Las nuevas versiones de Highcharts rompen ocasionalmente la API, sobre todo en tipos de diagrama complejos. Una migración debería probarse por tanto siempre en un sistema de staging antes de tocar los paneles en producción.

Un procedimiento pragmático para proyectos existentes: inventariar los diagramas actuales, listar las funcionalidades realmente utilizadas de la librería empleada y comprobar si una alternativa cubre lo mismo. En muchos casos los requisitos son manejables (diagramas de líneas y barras con pocas series de datos) y una librería libre los sirve sin pérdida de calidad. El presupuesto de licencia ahorrado puede reinvertirse en una mejor gestión de contenido de las series de datos.

Gosign integra Highcharts en TYPO3, acompaña la clarificación de licencia y los proyectos de migración, e implementa cuando hace falta alternativas ligeras como Chart.js o ApexCharts como componente del sitepackage. La elección correcta depende de qué tipos de diagrama se necesitan realmente y de qué presupuesto hay disponible para licencias.

--- Hotspot TYPO3 - Imágenes interactivas | Gosign ---
> Extensión de TYPO3 para hotspots interactivos en imágenes: áreas clicables con tooltip u overlay. Imágenes de productos, planos de edificios, infografías. ...

## Las imágenes interactivas explican productos complejos mejor que 1.000 palabras de texto

Un plano de edificio con 12 estancias marcadas, un corte transversal de máquina con 8 componentes etiquetados, un mapa de Europa con 15 ubicaciones: todos estos casos de uso necesitan áreas clicables en una imagen. El visitante hace clic en un componente y ve sus especificaciones. Las extensiones Hotspot para TYPO3 hacen las imágenes interactivas vinculando áreas definidas con tooltips, overlays o enlaces.

La pregunta más interesante es si realmente se necesita una extensión para esto. Los hotspots basados en SVG funcionan sin extensión, son más ligeros, más accesibles y completamente controlables en el sitepackage. Para casos de uso sencillos, SVG es el mejor camino. Para configuraciones complejas con muchos hotspots y mantenimiento en backend por redactores, una extensión justifica su uso.

## Escenarios de uso habituales

**Imágenes de producto con componentes clicables.** Fabricantes de máquinas, equipos y productos técnicos usan hotspots para etiquetar componentes en una foto de producto. En un fabricante de maquinaria, las imágenes de producto interactivas aumentaron el tiempo de permanencia en páginas de producto un 45%.

**Planos de edificios y campus.** Universidades, clínicas y grandes empresas muestran planos interactivos: clic en un edificio, seleccionar planta, ver información de la sala.

**Infografías con información detallada.** Los departamentos de marketing producen infografías sobre procesos, cadenas de valor o estructuras empresariales. En lugar de mostrar un archivo PNG estático, los elementos de la infografía se hacen clicables.

## Arquitectura técnica

Las extensiones Hotspot en TYPO3 constan de tres partes: un editor de backend para posicionar los hotspots, una estructura de datos para contenidos de hotspot y un renderizador frontend.

El editor de backend es típicamente un editor visual de colocación de puntos: el redactor ve la imagen en el backend TYPO3 y hace clic en los lugares donde deben aparecer los hotspots. Las coordenadas se almacenan como valores porcentuales (relativos al tamaño de la imagen), no como píxeles.

En el frontend, los hotspots se renderizan como elementos HTML posicionados absolutamente sobre la imagen. La imagen está en un contenedor con `position: relative`, los hotspots tienen `position: absolute` con `left` y `top` en porcentaje.

La alternativa SVG funciona sin extensión: la imagen se crea como SVG, los hotspots son elementos SVG (`<circle>`, `<rect>`) con atributos `data-` y manejadores de eventos.

## Problemas frecuentes y soluciones

**Las posiciones de hotspot se desplazan en dispositivos móviles.** La imagen se muestra más pequeña en smartphone, pero los hotspots permanecen en la posición de escritorio. Solución: almacenar todas las posiciones en porcentaje y hacer el contenedor responsive. Adicionalmente: mostrar los hotspots en móviles como lista debajo de la imagen.

**Accesibilidad no garantizada.** Hotspots puramente visuales sin navegación por teclado ni texto para lectores de pantalla no son accesibles. Solución: implementar cada hotspot como `<button>` con `aria-label` para el lector de pantalla y `tabindex` para la navegación por teclado.

**Rendimiento con muchos hotspots.** Más de 20 hotspots en una imagen generan más de 20 elementos DOM con event listeners. Solución: Event Delegation en lugar de listeners individuales. Un único listener en el contenedor en lugar de 20 en los hotspots.

## Migración y compatibilidad de versiones

Las extensiones Hotspot en el TER soportan TYPO3 v10 y v11. Para v12 y v13 no existen extensiones Hotspot ampliamente mantenidas. La tendencia va hacia soluciones basadas en SVG implementadas como Custom Content Element en el sitepackage.

La migración de una extensión Hotspot a una solución basada en SVG requiere: exportar los datos de hotspot (coordenadas, textos), crear una plantilla SVG y configurar un Custom Content Element. El esfuerzo es de 3-5 días.

La solución más segura para el futuro: hotspots basados en CSS con `<map>` y `<area>` para escenarios sencillos, SVG con JavaScript para interacciones complejas. Gosign implementa imágenes interactivas como Custom Content Elements y asesora sobre la tecnología adecuada según complejidad, requisitos de accesibilidad y número de imágenes con hotspot.

--- Lista de asociaciones TYPO3 - Municipal | Gosign ---
> Plugin de listas de asociaciones para TYPO3: mostrar, filtrar y ordenar asociaciones. Típico para sitios web municipales y federaciones.

## Los municipios y las federaciones necesitan una base de datos de asociaciones estructurada en lugar de listas estáticas

Quien busca el club de ajedrez local en un sitio web municipal espera una máscara de filtro, no una lista PDF de 15 páginas. Exactamente este problema resuelve hwvereinsliste: la extensión representa asociaciones como registros TYPO3 y los hace accesibles mediante filtro por categorías, búsqueda de texto completo y vistas de detalle. Para sitios web municipales, federaciones y asociaciones deportivas regionales, el plugin ha sido una herramienta probada durante años que permite a las redacciones el mantenimiento sin intervención de desarrolladores.

La realidad en muchos municipios es que los registros de asociaciones aún circulan como documentos Word entre los departamentos. hwvereinsliste reemplaza este flujo de trabajo por una base de datos central en el backend TYPO3 que se controla mediante plugins frontend.

## Escenarios de uso habituales

El escenario más frecuente es la lista clásica de asociaciones en un sitio web municipal. Un municipio con 80 a 120 asociaciones registradas mantiene todas las entradas centralmente en el backend TYPO3. Los ciudadanos filtran en el frontend por categorías como deportes, cultura, social o juventud. El segundo escenario afecta a federaciones y asociaciones deportivas regionales que gestionan a menudo 500 a 2.000 asociaciones miembro en docenas de disciplinas deportivas. El tercer escenario son los portales de voluntariado.

## Arquitectura técnica

hwvereinsliste utiliza el framework Extbase/Fluid de TYPO3. Las asociaciones se almacenan como registros de dominio propios en una tabla dedicada. Cada registro contiene campos para nombre, descripción, dirección, datos de contacto, URL web, logo y categorías. La categorización utiliza las categorías del sistema TYPO3.

En el frontend hay dos plugins disponibles: una vista de lista con función de filtro y búsqueda, y una vista de detalle para asociaciones individuales. Las plantillas son basadas en Fluid y se pueden sobrescribir mediante paths TypoScript o un sitepackage.

Un aspecto que se olvida frecuentemente en proyectos municipales: la accesibilidad. Desde la ley de refuerzo de accesibilidad (correspondiente en España a los requisitos del Real Decreto 1112/2018), las entidades públicas deben diseñar sus sitios web de forma accesible. Los elementos de filtro deben ser operables por teclado, las listas de resultados necesitan ARIA labels, y la función de búsqueda debe ser compatible con lectores de pantalla.

## Problemas frecuentes

El problema más frecuente en la configuración inicial es la importación de datos. Los municipios tienen sus datos de asociaciones típicamente en listas Excel con formatos inconsistentes. El segundo problema afecta a la estructura de categorías. Si las categorías no se definen limpiamente de antemano, surgen redundancias. El tercer problema: la presentación responsive de la vista de lista en dispositivos móviles.

## Migración y compatibilidad de versiones

hwvereinsliste fue desarrollada principalmente para TYPO3 v9 y v10. Para TYPO3 v12 es necesaria una adaptación de la persistencia Extbase. Para TYPO3 v13 no existe actualmente soporte oficial. Gosign evalúa en estos casos si una migración de la extensión o un nuevo desarrollo sobre base Extbase con API actual es más económico. En bases de datos de asociaciones pequeñas con menos de 200 entradas, un plugin personalizado es a menudo la mejor opción.

--- imagemap TYPO3 - Gráficos interactivos | Gosign ---
> imagemap para TYPO3: gráficos interactivos con áreas clicables. Responsive, accesible, alternativas SVG.

## imagemap hace clicables las imágenes sin que los redactores tengan que tocar HTML, la opción correcta para planos de edificios, organigramas y gráficos de producto con varios hotspots

Algunos contenidos no pueden explicarse de forma tan eficiente con palabras como con una imagen en la que se pueden pulsar distintas áreas. Un plano de edificio en el que cada departamento lleva a la página del equipo correspondiente. Un organigrama con enlaces a los perfiles de persona. Una imagen de producto en la que un clic en la rueda, el motor o el puesto de conducción muestra los detalles técnicos correspondientes. HTML trae desde los años noventa la funcionalidad Image Map para eso, pero ningún redactor quiere teclear coordenadas a mano en un campo de texto. imagemap añade esa función en TYPO3 con un editor visual: los redactores hacen clic en el backend sobre la imagen, marcan un área y la enlazan a una página destino.

La promesa real de la extensión es unir orientación espacial y navegación. En lugar de hacer saltar a los visitantes entre una vista gráfica y una lista separada de enlaces, el propio gráfico se convierte en elemento de navegación. Para contenidos estructurados geográfica, jerárquica o técnicamente, eso ofrece un acceso claramente más intuitivo.

## Escenarios típicos de uso

El primer caso son planos de situación y vistas generales de campus. Hospitales, universidades, recintos feriales y parques industriales trabajan con mapas de conjunto en los que edificios o áreas individuales enlazan directamente a páginas informativas. La alternativa clásica sería una lista con enlaces, pero pierde la referencia espacial. imagemap combina la orientación gráfica con la estructura de enlaces.

El segundo uso son los organigramas y las jerarquías. Una empresa muestra la estructura de sus departamentos como gráfico; cada nodo lleva al perfil del directivo correspondiente o a la página del departamento. Para la redacción es más fácil de mantener que un layout de tabla complejo con celdas enlazadas.

Tercer caso: gráficos de producto con hotspots de función. Productos técnicos (máquinas, vehículos, equipos) se muestran en un despiece o en un corte transversal, y sus componentes principales se explican por clic. Eso sustituye una lista larga de texto y lleva a los visitantes exactamente donde está su interés.

## Arquitectura técnica

La extensión clásica imagemap para TYPO3 mantiene las coordenadas como registros estructurados en la base de datos y renderiza en el frontend un elemento HTML Map con las area tags correspondientes. En el backend hay un editor visual que muestra la imagen original como área de selección y permite a los redactores dibujar sobre ella rectángulos, círculos o polígonos. Cada área recibe una URL destino, un texto alternativo y, opcionalmente, un tooltip.

El reto técnico está en la responsividad. El HTML Map clásico trabaja con coordenadas absolutas en píxeles, que dejan de encajar con imágenes escaladas. Las extensiones imagemap lo resuelven mediante JavaScript que recalcula relativamente las coordenadas en el resize, o bien usando SVG como formato de salida. SVG es la solución limpia: las coordenadas vectoriales escalan de serie, el manejo de eventos y el estilado por CSS funcionan de forma nativa, y los lectores de pantalla pueden leer los elementos estructurados.

La integración se realiza mediante un elemento de contenido en el módulo Page. Los redactores eligen la imagen base en FAL, definen los hotspots y configuran opcionalmente ajustes globales como color estándar de las áreas, efectos hover y comportamiento de tooltip. La salida puede adaptarse mediante una plantilla Fluid en el sitepackage para garantizar la conformidad con la identidad corporativa.

## Problemas frecuentes y soluciones

El primer problema es la accesibilidad. Las HTML Image Maps solo son legibles para lectores de pantalla si cada area tag tiene un texto alternativo significativo y la propia map se reconoce como navegación estructurada. Muchos redactores rellenan el alt text de manera descuidada o lo dejan vacío, lo que hace la map inutilizable para usuarios ciegos. Eso entra en conflicto con el Real Decreto 1112/2018 sobre accesibilidad de los sitios web del sector público. La solución es una obligación editorial de dotar a cada hotspot de un texto descriptivo y una comprobación técnica en el sitepackage que impida al guardar los textos vacíos.

Segundo problema: manejabilidad en móviles. Un hotspot que en tamaño desktop mide 30 por 30 píxeles es minúsculo en un smartphone. La solución pragmática es una alternativa móvil que, por debajo de un breakpoint determinado, sustituya la imagen por una lista con los mismos destinos. Eso requiere una lógica Fluid que sirva dos representaciones y conmute por CSS.

Tercer problema: carga de mantenimiento ante cambios de imagen. Si la imagen base (un plano o una foto de producto) se sustituye, todas las coordenadas deben volver a fijarse, porque los motivos se han desplazado. Solución pragmática: los redactores trabajan con un formato de imagen fijo y versionado y documentan la rejilla de coordenadas, de modo que las actualizaciones solo requieran correcciones mínimas. Alternativamente, una solución basada en SVG puede trabajar de forma relativa desde el principio.

## Migración y compatibilidad de versiones

Para TYPO3 v11, v12 y v13 existen varias extensiones imagemap en mantenimiento activo, a menudo con nombres ligeramente distintos. En upgrades vale la pena revisar si la extensión utilizada originalmente sigue evolucionando o si tiene más sentido cambiar a una alternativa más moderna. Los enfoques basados en SVG desplazarán a medio plazo a los HTML Maps clásicos, porque funcionan mejor tanto en responsive como en accesibilidad.

Una indicación práctica para migraciones: si un proyecto existente contiene decenas de imagemaps, merece la pena un script que lea los registros de coordenadas existentes y los convierta en paths SVG. El cambio puede realizarse entonces en un único despliegue y la extensión puede retirarse. Eso reduce la deuda técnica y hace los gráficos a prueba de futuro.

Quien empieza hoy desde cero debería preferir el enfoque SVG, ya sea mediante una extensión con salida SVG o mediante un patrón propio en el sitepackage que ofrezca a los redactores un editor visual y entregue SVG en el frontend. Gosign implementa ambos caminos y asesora en la elección de la arquitectura adecuada para cada proyecto.

--- in2publish TYPO3 - Staging de contenido | Gosign ---
> in2publish: publicar contenido de staging a producción. Configuración multi-servidor y flujos de trabajo, acelerado con IA.

## Por qué in2publish define el flujo de trabajo de contenido en proyectos TYPO3 enterprise

En instalaciones TYPO3 profesionales, los editores no trabajan directamente en el sistema en producción. Gestionan contenidos en un entorno de staging, coordinan cambios internamente y publican solo tras aprobación. Pero cómo llegan los datos de staging a producción. Sin in2publish eso significa: dump de base de datos en staging, restaurar en producción, sincronizar archivos por FTP. Un proceso propenso a errores que toma de 30 a 60 minutos y donde un clic equivocado puede sobrescribir toda la base de datos en producción.

in2publish de in2code elimina este proceso. Los editores pulsan "Publicar" en el backend TYPO3, y la extensión sincroniza exactamente los registros y archivos modificados al sistema en producción. Sin accesos FTP, sin dumps de base de datos, sin tiempo de inactividad.

## Escenarios de uso habituales

**Flujo de trabajo de aprobación editorial.** Una corporación opera su web corporativa en TYPO3 con 12 editores en 3 departamentos. Cada departamento gestiona su área en staging. La jefatura de equipo revisa los cambios y los aprueba. El editor pulsa "Publicar" y solo sus páginas aprobadas pasan a producción. Otras áreas de la web quedan intactas. in2publish muestra una vista de diferencias: qué campos han cambiado, qué imágenes son nuevas, qué registros se sobrescribirán.

**Publicación multi-idioma.** Una empresa gestiona su web en 5 idiomas. La redacción española publica textos terminados mientras la traducción al inglés aún está en curso. in2publish permite publicación selectiva por idioma: el contenido en español pasa a producción, el inglés permanece en staging hasta completar la traducción.

**Lanzamientos de campaña con fechas definidas.** El equipo de marketing prepara una página de lanzamiento de producto que debe publicarse el 15 de octubre a las 8:00. Todos los contenidos - textos, imágenes, vídeos, landing pages - se preparan y prueban en staging. El día del lanzamiento, el editor responsable publica todo en un solo paso. En caso de problemas, in2publish puede revertir los cambios.

## Arquitectura técnica

in2publish trabaja a nivel de base de datos y sistema de archivos. La extensión compara el estado de la base de datos de staging con la de producción y transfiere las diferencias. Los componentes principales son: Record Comparison (compara cada registro entre staging y producción, resolviendo relaciones para que al publicar una página se incluyan automáticamente todos los registros dependientes), FAL Synchronisation (imágenes y documentos se transfieren vía SSH/SFTP al sistema en producción, comparando tamaños y hashes), Transport Layer (comunicación vía SSH con autenticación por clave pública) y Configuration (YAML que define qué tablas se publican como whitelist y cuáles se excluyen).

## Problemas frecuentes y soluciones

**La publicación falla con "SSH Connection Failed".** La causa más frecuente: la clave SSH del servidor de staging no está registrada en el servidor de producción, o la configuración SSH en in2publish apunta al host/puerto incorrecto. Solución: probar la conexión SSH manualmente, luego verificar las credenciales en la configuración de in2publish.

**Los registros no se actualizan en producción.** La tabla no está en la whitelist de la configuración de in2publish. Ocurre frecuentemente con tablas personalizadas de extensiones propias. Solución: añadir la tabla en la configuración y definir las relaciones.

**Faltan archivos FAL tras la publicación en producción.** El FAL Storage en el sistema de producción tiene una ruta distinta a staging, o los permisos en el servidor de producción no permiten escritura en la carpeta de uploads. Solución: asegurar que la ruta base del FAL Storage sea idéntica en ambos sistemas.

## Migración y compatibilidad de versiones

in2publish se mantiene activamente por in2code y está disponible para TYPO3 v11 y v12 LTS como paquete Composer. La versión Enterprise ofrece funcionalidades adicionales (transporte HTTP, logging ampliado, soporte multi-entorno) con licencia de pago.

Tras una actualización TYPO3 debe revisarse la configuración de in2publish: nuevas tablas del sistema, definiciones TCA modificadas y nuevos tipos de elementos de contenido requieren ajuste de la whitelist. Gosign recomienda tras cada actualización del core un test-publish con una sola página para validar la configuración antes de reanudar el flujo editorial completo. El test debe incluir una página con todos los tipos de contenido relevantes: elementos de texto, imágenes, descargas de archivos y al menos una relación.

--- in2studyfinder TYPO3 - Programas de estudio | Gosign ---
> Extensión de buscador de programas de estudio para TYPO3. Búsqueda filtrada, comparación de programas, páginas de detalle.

## Los futuros estudiantes esperan un buscador, no un folleto PDF

Las universidades con 50 a 300 programas de estudio se enfrentan a un problema concreto: los interesados quieren filtrar, no desplazarse. Buscan por tipo de titulación, área de conocimiento, modalidad de estudio y ubicación simultáneamente. in2studyfinder de in2code resuelve exactamente esto dentro de TYPO3. La extensión fue desarrollada específicamente para el ámbito universitario y mapea la compleja estructura de grado, máster, diploma, tiempo completo, tiempo parcial, dual y compatible con el trabajo en una única máscara de filtro.

Para equipos web universitarios que hasta ahora gestionan su información de programas mediante páginas estáticas o soluciones autoconstruidas, el cambio a in2studyfinder supone una ganancia de eficiencia considerable.

## Escenarios de uso habituales

El escenario estándar es el buscador central de programas de estudio en la página web de la universidad. Los interesados llegan a una página, seleccionan área de conocimiento, titulación y modalidad y obtienen inmediatamente una lista filtrada. Un clic lleva a la página de detalle con plan de módulos, requisitos de admisión, plazos de solicitud y personas de contacto.

Segundo escenario: búsqueda inter-campus en universidades con varios campus. Una universidad con sedes en tres ciudades muestra todos los programas en una vista y permite filtrar por campus.

Tercer escenario: vistas generales de acreditación para aseguramiento de calidad. Las universidades deben demostrar qué programas están acreditados y hasta cuándo.

## Arquitectura técnica

in2studyfinder es una extensión Extbase/Fluid de in2code. Los programas de estudio se almacenan como registros de dominio en una tabla propia. Cada registro contiene campos obligatorios como título, tipo de titulación, duración regulada, créditos ECTS y área de conocimiento.

El filtrado en el frontend trabaja mediante peticiones AJAX, de modo que la página no se recarga al filtrar. La configuración de filtros es controlable mediante TypoScript. Las plantillas son basadas en Fluid y sobrescribibles mediante sitepackages.

## Problemas frecuentes

El mayor problema en la introducción es la calidad de datos. La información de programas de estudio existe en las universidades a menudo en tres a cinco sistemas diferentes. Segundo problema: rendimiento con grandes volúmenes de datos en universidades con más de 200 programas. Tercer problema: multilingualidad para universidades internacionales con programas en inglés.

## Migración y compatibilidad de versiones

in2code mantiene in2studyfinder activamente. La versión actual soporta TYPO3 v11 y v12. Dado que in2code es un proveedor comercial de servicios TYPO3 con estrategia de producto a largo plazo, se espera compatibilidad con v13, aunque aún no está oficialmente liberada. En la actualización de v10 o v11 a v12, los breaking changes afectan principalmente a la configuración TypoScript y posibles ViewHelpers personalizados en las plantillas. La estructura de la base de datos permanece estable.

--- in2template TYPO3 - Gestión de plantillas | Gosign ---
> Extensión de gestión de plantillas de TYPO3 de in2code. Simplifica la administración de Fluid Templates y Site Packages. Estructurada ...

## in2template pone estructura en los sitepackages antes de que se conviertan en un infierno de mantenimiento

Quien monta en TYPO3 un sitepackage para un sitio web grande se enfrenta cada vez a la misma pregunta: ¿cómo organizo plantillas, partials, layouts y elementos de contenido de modo que sigan siendo mantenibles dentro de dos años? La extensión in2template de in2code es un intento de dar una respuesta estructurada a esa pregunta. Entrega un andamio para sitepackages modernos: estructura de directorios clara, elementos de contenido predefinidos, configuración preparada para TypoScript, Fluid Styled Content y backend layouts. Para equipos TYPO3 que arrancan regularmente nuevos proyectos, in2template sustituye la vieja práctica de copia y pega del último proyecto por un patrón documentado.

El público son agencias con varios proyectos TYPO3 en paralelo y equipos internos que mantienen plantillas corporativas para sitios de grupo o universitarios. Especialmente allí donde desarrolladoras y redactoras comparten el sitepackage, una convención coherente de carpetas y nombres es vital para la supervivencia del proyecto. in2template aborda justo esa brecha.

## Escenarios típicos de uso

Un primer escenario es el arranque limpio de proyecto. Una agencia con ocho desarrolladoras y tres proyectos TYPO3 en curso introduce in2template como estándar interno para sitepackages. Cada proyecto nuevo empieza con el mismo esqueleto: estructura de directorios idéntica, convenciones de nombres idénticas, base TypoScript idéntica. El resultado: un desarrollador puede cambiar entre proyectos sin tener que reorientarse cada vez.

Un segundo escenario es la modernización de un sitepackage antiguo. Un portal universitario con 800 páginas y una carpeta de plantillas crecida desde TYPO3 v7 se reestructura en el marco de un upgrade de v11 a v12. En lugar de arrastrar la maleza antigua, el equipo reconstruye el sitepackage sobre la base de in2template y migra los contenidos paso a paso.

Un tercer escenario es el onboarding de nuevos redactores. Una editorial con 30 redactores explica sobre la base del esqueleto in2template qué elementos de contenido están pensados para qué. La coherencia en nomenclatura y estructura acorta la formación y reduce la tasa de errores en el backend.

Un cuarto escenario es la plantilla interna de refactoring. Una empresa con cinco instalaciones TYPO3 de distintos años quiere migrar los sitepackages a largo plazo a una estructura uniforme. in2template sirve como esqueleto de referencia contra el que cada proyecto antiguo se reconstruye paso a paso, sin que el equipo tenga que discutir cada vez una nueva estructura objetivo.

## Arquitectura técnica

in2template no es un add-on clásico, sino más bien una plantilla para un sitepackage propio. La extensión trae una estructura de directorios: Resources/Private/Templates, Resources/Private/Partials, Resources/Private/Layouts, Configuration/TypoScript, Configuration/TsConfig, Configuration/TCA/Overrides. El esqueleto se completa con elementos de contenido preparados (texto, texto con imagen, acordeón, teaser grid) y una configuración para backend layouts.

La instalación se realiza como una descarga clásica de Composer del paquete, que luego se copia y renombra en el propio repositorio de sitepackage. En la práctica los equipos usan in2template menos como dependencia directa: lo habitual es un clon inicial que luego crece de forma específica para el proyecto. Eso convierte la extensión en un starter kit y no en un framework que haya que actualizar entre versiones.

Para la integración con Fluid Styled Content hay mecanismos de override propios que aseguran que los elementos de contenido que trae convivan con los elementos del núcleo. Los paths TypoScript están namespaced de forma consistente, para que varios sitepackages puedan correr en paralelo en la misma instalación.

## Problemas frecuentes y soluciones

El primer problema es la confusión con un framework. Los equipos que integran in2template como si fuera Bootstrap o Tailwind y esperan actualizaciones se llevan una decepción: la extensión es una plantilla para copiar, no un stack upstream. La solución es ver in2template como una plantilla de una sola vez y versionar claramente el sitepackage propio que surge de ella.

El segundo problema es la sobrecarga con elementos de contenido no utilizados. El starter kit trae más elementos de los que la mayoría de proyectos necesita. Quien no los utiliza igual los arrastra a través del mantenimiento. La solución es un cleanup justo tras la importación inicial: borrar elementos de contenido no usados, eliminar backend layouts sobrantes, retirar los bloques TypoScript que no se emplean.

El tercer problema es la adaptación a sistemas de diseño propios. in2template entrega CSS cercano a Tailwind con clases utilitarias propias. Quien usa un sistema de diseño existente con nombres de token propios debe traducir los estilos entregados con constancia, si no surgen duplicaciones de estilo y cascadas contradictorias.

Un cuarto problema son los conflictos con otros starter kits. Quien adopta in2template parcialmente y, en paralelo, integra bloques de otro esqueleto obtiene paths TypoScript contradictorios y namespaces Fluid superpuestos. La solución es decidir al inicio del proyecto por un único esqueleto y mantener los componentes adicionales inconsistentes en una capa claramente nombrada propia del proyecto.

## Migración y compatibilidad de versiones

in2template lo mantiene in2code para TYPO3 v11 y v12; la compatibilidad con TYPO3 v13 se actualiza a lo largo de los ciclos de release del propio TYPO3. Como la extensión en los proyectos casi siempre se clona y se adapta, la cuestión de versión es menos una cuestión de paths de actualización y más una cuestión de disciplina de código: los equipos deberían echar un vistazo al repositorio actual de in2template al actualizar su sitepackage para arrastrar mejoras estructurales (nuevas convenciones de backend layout, nuevos patrones Fluid).

Importante al actualizar un sitepackage basado en in2template es atender a las convenciones TYPO3 modificadas: los TCA Overrides, las definiciones de backend layout, el registro de elementos de contenido y el renderizado Fluid se han movido varias veces entre v11 y v13. Quien no arrastra esos cambios al propio sitepackage corre el riesgo de que los contenidos parezcan vacíos en el backend o de que los wizards de elementos de contenido dejen de aparecer.

Gosign asume en proyectos TYPO3 el análisis de qué partes del sitepackage existente pueden ordenarse siguiendo un patrón tipo in2template y cuáles conviene más migrar a un esqueleto propio y minimalista. El resultado es un sitepackage que pasa sin refunfuños en los code reviews y que no produce sorpresas en el siguiente upgrade de TYPO3.

--- Social Share Buttons TYPO3 | Gosign ---
> Extensión de Social Share Buttons para TYPO3. Gosign recomienda en su lugar enlaces personalizados ligeros para compartir: sin sobrecarga de extensión.

## Los botones de compartir en redes sociales como extensión son innecesarios en la mayoría de proyectos TYPO3

La idea es simple: los visitantes deben poder compartir contenidos con un clic en LinkedIn, X o Facebook. insign_share_buttons entrega exactamente eso como extensión TYPO3: botones para diversas redes, configurables en el backend. Pero la realidad muestra que para una función que en esencia consiste en cinco enlaces HTML, una extensión completa con su propia configuración, setup TypoScript y obligación de actualización es en la mayoría de los casos innecesaria. Gosign recomienda en su lugar enlaces nativos de compartir, implementables en 15 minutos y sin generar dependencias.

Esto aplica especialmente desde el RGPD: muchas extensiones de compartir social cargan JavaScript en segundo plano desde las redes, lo cual es contrario a la protección de datos sin consulta de consentimiento. Los enlaces de compartir puramente basados en URL evitan completamente este problema.

## Escenarios de uso habituales

El escenario estándar es el sitio web corporativo con blog o revista. Los redactores quieren mostrar botones para LinkedIn, X, Facebook y email debajo de cada artículo. Segundo escenario: portales de intranet donde los empleados quieren compartir noticias internas a través de Teams o Slack. Tercer escenario: sitios web con enfoque de employer branding donde las ofertas de empleo deben difundirse a través de redes sociales.

## Arquitectura técnica

insign_share_buttons registra un elemento de contenido en TYPO3 que se renderiza mediante la plantilla de página o como plugin. Las URLs de compartir se generan del lado del servidor siguiendo el esquema estándar de las redes respectivas. La extensión no tiene dependencias significativas aparte del Core TYPO3, siempre que la función de contadores permanezca desactivada.

## Problemas frecuentes

Problema uno: protección de datos. Muchas instalaciones tienen activa la función de contadores, que transmite datos personales a servidores estadounidenses sin consentimiento de cookies. Solución: desactivar contadores y utilizar exclusivamente enlaces de compartir basados en URL. Problema dos: etiquetas OpenGraph faltantes o incorrectas. Problema tres: conflictos de estilo entre los CSS incluidos de la extensión y el diseño corporativo.

## Migración y compatibilidad de versiones

insign_share_buttons es compatible con TYPO3 v12. Para TYPO3 v13 la disponibilidad depende del mantenedor. Gosign recomienda en una migración a v12 o v13 reemplazar la extensión por un simple Partial Fluid. Cinco líneas de HTML por red, sin dependencia de extensión, sin obligación de actualización, plena conformidad con el RGPD. El esfuerzo para esta conversión es de una a dos horas incluyendo estilizado y pruebas de todos los enlaces de red. En Gosign aplicamos este enfoque de forma estándar en todos los nuevos proyectos TYPO3.

--- Inxmail TYPO3 - Newsletter enterprise | Gosign ---
> Inxmail Professional es un sistema de newsletter enterprise de Alemania. Conexión con TYPO3: sincronización de suscriptores, sincronización de plantillas, ...

## Inxmail es la plataforma de newsletter enterprise que conecta nativamente con redacciones TYPO3

Las empresas con más de 50.000 destinatarios de newsletter, requisitos estrictos de cumplimiento y un sitio web TYPO3 existente se enfrentan a una decisión concreta: Mailchimp con procesamiento de datos en EE.UU. y riesgo RGPD, o una solución alemana que se integra directamente en la infraestructura de contenido existente. Inxmail Professional es esa solución. Servidores en Alemania, procesamiento de datos certificado y una extensión TYPO3 que controla listas de suscriptores, plantillas y campañas directamente desde el CMS.

La extensión TYPO3 sincroniza registros bidireccionalmente: nuevos suscriptores desde formularios TYPO3 llegan automáticamente a listas Inxmail, las bajas en Inxmail se reflejan de vuelta en TYPO3.

## Escenarios de uso habituales

El escenario principal es el newsletter B2B clásico para empresas con 10.000 a 500.000 destinatarios. La redacción mantiene contenidos en TYPO3, la extensión transfiere teasers y enlaces automáticamente a plantillas Inxmail. Segundo escenario: emails transaccionales activados por acciones del usuario. Tercer escenario: comunicación de eventos con secuencias trigger (invitación, recordatorio, seguimiento).

## Arquitectura técnica

La extensión utiliza la API REST de Inxmail para la comunicación. El núcleo de la integración consta de tres módulos: un servicio de sincronización de suscriptores, un módulo de sincronización de plantillas y un activador de campañas. La sincronización se ejecuta mediante tarea Scheduler en intervalos configurables. La autenticación se realiza mediante API Keys. Todos los API calls van por HTTPS y la extensión registra cada sincronización en una tabla de log dedicada.

## Problemas frecuentes

El tema de soporte dominante son los conflictos de sincronización con sincronización bidireccional. Solución: definir dirección de sincronización clara. Segundo problema: diferencias de renderizado HTML entre frontend TYPO3 y cliente de email. Tercer problema: límites de tasa de API con grandes volúmenes de sincronización.

## Migración y compatibilidad de versiones

Inxmail mantiene la extensión TYPO3 activamente. La versión actual soporta TYPO3 v11 y v12. Para TYPO3 v13 aún no hay release oficial. Como solución intermedia, la integración puede realizarse mediante una capa middleware personalizada que accede directamente a la API de Inxmail. Gosign ha implementado esta solución para clientes que querían migrar a v13 antes de la disponibilidad de la extensión oficial.

--- iSpider TYPO3 - Web Crawler | Gosign ---
> Extensión de web crawler para TYPO3. Rastreo de sitios web externos e importación de contenido en TYPO3.

## Los enlaces rotos cuestan posicionamiento y confianza, pero casi nadie los comprueba regularmente

Todo sitio web TYPO3 con más de 200 páginas tiene enlaces rotos. Los redactores eliminan páginas, mueven contenidos o cambian slugs de URL sin verificar todos los enlaces internos. El resultado: errores 404 que Google valora como señal de calidad y frustran a los visitantes. iSpider es un crawler web interno para TYPO3 que rastrea el propio frontend, identifica enlaces rotos y genera un sitemap.

Para redacciones y directores técnicos de proyecto, iSpider es un instrumento de QA que funciona sin dependencias externas. El crawler se ejecuta en el backend TYPO3, conoce la estructura de páginas y puede verificar también áreas protegidas con contraseña que herramientas externas como Screaming Frog no alcanzan.

## Escenarios de uso habituales

El escenario más frecuente es la verificación pre-lanzamiento antes de un relanzamiento o actualización TYPO3. Segundo escenario: monitorización continua en el día a día editorial mediante tarea Scheduler semanal. Tercer escenario: análisis SEO de estructura de enlazado interno.

## Arquitectura técnica

iSpider se registra como módulo de backend en TYPO3 y utiliza el Scheduler para ejecuciones automatizadas de rastreo. El crawler parte de una página de inicio configurable y sigue todos los enlaces internos recursivamente hasta una profundidad ajustable. Los resultados se almacenan en una tabla de base de datos propia.

## Problemas frecuentes

El problema más frecuente: el rastreo se interrumpe en sitios web grandes porque se alcanza el límite de memoria PHP o max_execution_time. Solución: dividir el rastreo en lotes mediante Scheduler. Segundo problema: rastreos incompletos con contenidos renderizados por JavaScript. Tercer problema: falsos positivos en enlaces externos.

## Migración y compatibilidad de versiones

iSpider fue desarrollado para TYPO3 v7 y v8 y no tiene soporte oficial para v12 o v13. Quien migre a versiones actuales de TYPO3 debe evaluar alternativas externas. Gosign utiliza en sus propios proyectos una combinación del validador de enlaces del Core TYPO3 para comprobaciones internas y rastreos automatizados de Screaming Frog para análisis SEO completos.

--- iubenda TYPO3 - Protección de datos | Gosign ---
> iubenda es un servicio de protección de datos con generadores de textos legales, gestión de consentimiento y escaneo de cookies.

## Consent de cookies y política de privacidad de una sola fuente suena práctico, pero tiene dependencias

Desde el RGPD y la normativa de cookies, todo sitio web necesita un banner de consentimiento de cookies y una declaración de privacidad actualizada. iubenda ofrece ambos como solución SaaS: un widget JavaScript para el banner de consentimiento y un generador para políticas de privacidad y cookies que se actualizan automáticamente cuando cambian las leyes. La extensión TYPO3 integra ambos en el código fuente de la página.

El trade-off es claro: comodidad frente a dependencia. El banner de consentimiento y la política de privacidad se cargan desde servidores de iubenda. Si el servicio cae o la API cambia, el sitio web se ve afectado.

## Escenarios de uso habituales

El escenario estándar es el sitio web de empresa mediana con 20 a 100 páginas que utiliza Google Analytics, un formulario de contacto y vídeos YouTube incrustados. iubenda escanea el sitio web, reconoce automáticamente los servicios utilizados y genera una política de cookies adecuada. Segundo escenario: portales multilingües que operan en diferentes jurisdicciones (iubenda soporta RGPD, CCPA y LGPD). Tercer escenario: sitios web con integraciones de terceros que cambian frecuentemente.

## Arquitectura técnica

La extensión TYPO3 integra iubenda mediante dos snippets de código: una etiqueta JavaScript para el banner de consentimiento y un código embed para la política de privacidad. La extensión en sí es mínima y apenas contiene lógica propia. El banner de consentimiento trabaja según el estándar TCF 2.0 y bloquea cookies mediante técnica de proxy.

## Problemas frecuentes

El problema más frecuente: no todos los scripts de terceros se bloquean correctamente. Solución: verificación manual de todos los servicios integrados. Segundo problema: pérdidas de rendimiento por el JavaScript adicional (40-80 KB). Tercer problema: Content Layout Shift por el banner que aparece posteriormente. Solución: configurar el banner como overlay o reservar un marcador fijo en el CSS.

## Migración y compatibilidad de versiones

Dado que la extensión en esencia solo integra dos snippets JavaScript, no hay dependencia profunda de la API TYPO3. La integración funciona con TYPO3 v10, v11, v12 y previsiblemente también v13 sin ajustes. Gosign recomienda no obstante realizar una prueba de consentimiento de cookies con cada actualización TYPO3 para asegurar que todas las reglas de bloqueo siguen funcionando.

--- j77 Template TYPO3 | Gosign ---
> Paquete de plantillas para TYPO3. Layout prediseñado como punto de partida. Gosign recomienda sitepackages personalizados para más flexibilidad.

## Las plantillas TYPO3 prefabricadas aceleran el inicio, pero frenan la evolución

j77_template es un paquete de plantillas preconfigurado para TYPO3 que ofrece un layout listo como punto de partida. Header, footer, navegación, áreas de contenido y definiciones básicas de estilo están incluidos. Para agencias que quieren montar un prototipo TYPO3 rápidamente, o para departamentos de TI internos sin desarrolladores frontend, resulta tentador. Sin embargo, la realidad muestra que las plantillas prefabricadas en proyectos profesionales generan más trabajo del que ahorran tras 3 a 6 meses.

La razón: cada paquete de plantillas trae su propia estructura HTML, clases CSS y configuración TypoScript. En cuanto el diseño debe desviarse del estándar, se lucha contra la lógica de la plantilla en lugar de trabajar con ella.

## Escenarios de uso habituales

El escenario más frecuente es el arranque rápido para prototipos y pruebas de concepto. Segundo escenario: portales internos y aplicaciones de intranet donde el diseño es secundario. Tercer escenario: sitios web de asociaciones y pequeños proyectos sin ánimo de lucro con presupuesto limitado.

## Arquitectura técnica

j77_template es técnicamente un Sitepackage TYPO3 que se instala mediante el Extension Manager. Incluye plantillas Fluid para layouts de página, plantillas Partial para header, footer y navegación, así como configuraciones TypoScript para renderizado de contenido. Los archivos CSS se basan en Bootstrap o un framework comparable.

Un problema típico de los paquetes de plantillas es la dependencia de Bootstrap. j77_template se basa en una versión específica de Bootstrap. Si el proyecto necesita otra versión de framework CSS o quiere cambiar completamente a Tailwind o CSS propio, colisiona con la configuración de la plantilla.

## Problemas frecuentes

Problema uno: conflictos de actualización en la actualización de TYPO3, ya que los paquetes de plantillas están estrechamente ligados a una versión de TYPO3. Problema dos: overrides CSS que se sobrescriben mutuamente. Problema tres: documentación faltante o desactualizada.

## Migración y compatibilidad de versiones

j77_template no tiene soporte garantizado para TYPO3 v12 o v13. En una migración es el momento ideal para reemplazar el paquete de plantillas por un Sitepackage propio. El esfuerzo para un Sitepackage sencillo es de 2 a 5 días laborables. Gosign crea Sitepackages adaptados exactamente al diseño corporativo y los requisitos funcionales del proyecto, incluyendo documentación de los elementos de contenido disponibles, constantes TypoScript y layouts de página.

--- jumpurl TYPO3 - Seguimiento de descargas | Gosign ---
> jumpurl: seguimiento de descargas para TYPO3. Gosign implementa seguimiento moderno con Cloudflare Analytics o Matomo: sin cookies, sin JavaScript adicional.

## jumpurl fue eliminado del Core desde TYPO3 v9 y no debería seguir usándose

jumpurl fue durante años parte fija del Core TYPO3 y hacía algo sencillo: redirigir descargas y enlaces externos a través de una URL de tracking para hacer contables los clics. Desde TYPO3 v9, jumpurl ya no está en el Core. Como extensión independiente sigue existiendo, pero la arquitectura está obsoleta y las alternativas modernas son superiores en todos los aspectos.

Quien aún tiene jumpurl en uso, trabaja con una técnica de la era TYPO3 v4. La extensión genera URLs crípticas con parámetros hash que no son legibles ni amigables para SEO. El tracking se basa en entradas de base de datos que ninguna herramienta de analytics moderna puede evaluar nativamente.

## Escenarios de uso habituales

El escenario principal era y es el tracking de descargas: cuántas veces se descargó el whitepaper, cuántas la lista de precios. Segundo escenario: tracking de enlaces externos. Tercer escenario: descargas seguras con control de acceso mediante sistema de tokens.

## Arquitectura técnica

jumpurl registra un manejador eID en el Core TYPO3 que intercepta peticiones entrantes con un parámetro jumpurl. El parámetro contiene un hash que apunta a la URL destino o la ruta del archivo. El manejador registra el acceso en una tabla de base de datos, valida el hash y redirige el navegador al destino real mediante 302.

## Problemas frecuentes

Problema uno: daño SEO por cadenas de redirección. Problema dos: conformidad con el RGPD, ya que jumpurl almacena direcciones IP en texto claro. Problema tres: compatibilidad con el routing moderno de TYPO3 v12 basado en Site Handling y Symfony.

## Migración y compatibilidad de versiones

jumpurl no tiene soporte oficial para TYPO3 v12 o v13. En una migración, Gosign recomienda el cambio a tracking de descargas basado en eventos. Concretamente esto significa: un atributo data en los enlaces de descarga y un event listener JavaScript que envía clics a Matomo, Google Analytics 4 o un endpoint personalizado. Para descargas seguras, la combinación de acceso a archivos basado en FAL y un sistema de tokens es la alternativa moderna.

El esfuerzo de migración depende de la cantidad de enlaces jumpurl existentes. Gosign analiza los datos de tracking jumpurl existentes, identifica las descargas más utilizadas y configura la nueva solución de tracking de modo que se mantenga la comparabilidad histórica.

--- k3n_dvemoji TYPO3 - Emoji y UTF-8mb4 | Gosign ---
> k3n_dvemoji: soporte UTF-8mb4 para emojis en TYPO3. Migración de charset y configuración de base de datos. Acelerado con IA.

## Los emojis como signos de interrogación no son un problema de visualización, sino un error de configuración de base de datos

Cuando en un backend TYPO3 un redactor introduce un emoji y en el frontend aparece un signo de interrogación o un cuadro vacío, el problema no está en el navegador ni en TYPO3. Está en la base de datos MySQL o MariaDB, que está configurada con el juego de caracteres utf8 en lugar de utf8mb4. La diferencia: utf8 almacena un máximo de 3 bytes por carácter, los emojis necesitan 4 bytes. k3n_dvemoji es una extensión TYPO3 que aborda este problema ampliando la configuración de la base de datos con soporte UTF-8mb4. Desde TYPO3 v10, el Core está preparado para utf8mb4, por lo que la extensión solo es necesaria en instalaciones antiguas o mal configuradas.

## Escenarios de uso habituales

El escenario más frecuente es una instalación TYPO3 v8 o v9 que lleva años funcionando y cuya base de datos aún está configurada en utf8. Aproximadamente el 30% de todas las instalaciones TYPO3 configuradas antes de 2018 tienen este problema. Segundo escenario: migraciones de bases de datos entre servidores donde el juego de caracteres puede perderse por un comando mysqldump incorrecto. Tercer escenario: sitios web internacionales con idiomas asiáticos que requieren parcialmente 4 bytes.

## Arquitectura técnica

k3n_dvemoji trabaja en dos niveles: análisis y conversión. En modo análisis, la extensión escanea todas las tablas TYPO3 y verifica el juego de caracteres de cada columna. En modo conversión genera sentencias ALTER TABLE para cada columna afectada y las ejecuta. Adicionalmente, la configuración TYPO3 en LocalConfiguration.php debe declarar el juego de caracteres utf8mb4.

## Problemas frecuentes

Problema uno: restricción de longitud de índice MySQL. Con InnoDB en formato Compact antiguo, la longitud máxima de índice es 767 bytes. Un varchar(255) con utf8mb4 necesita 1.020 bytes de espacio de índice. Solución: cambiar ROW_FORMAT a DYNAMIC. Problema dos: respaldo antes de la conversión, ya que ALTER TABLE en tablas grandes bloquea la tabla. Problema tres: columnas inconsistentes tras conversión parcial.

## Migración y compatibilidad de versiones

A partir de TYPO3 v10, la extensión es innecesaria si la base de datos está correctamente configurada. La extensión sigue siendo relevante para instalaciones que migran de v7, v8 o v9 a v12 o v13 y cuya base de datos nunca fue convertida. Gosign resuelve esto de forma automática en cada migración TYPO3: escaneo de base de datos asistido por IA, conversión completa y verificación de consistencia como parte del proceso estándar de actualización.

--- ke_search Premium TYPO3 - Búsqueda | Gosign ---
> Versión premium de la extensión de búsqueda ke_search para TYPO3. Funciones de búsqueda ampliadas: autocompletado, filtros, estadísticas.

## La búsqueda enterprise sin servidor Solr es posible con ke_search Premium en TYPO3

La búsqueda interna de un sitio web es la función más utilizada y menos mantenida. Los visitantes esperan autocompletado, tolerancia a errores tipográficos y la capacidad de buscar no solo páginas, sino también PDFs y documentos Office. ke_search Premium ofrece exactamente eso para TYPO3, sin necesidad de operar un servidor Solr o Elasticsearch externo. Todos los datos residen en la base de datos TYPO3.

Para sitios web de tamaño medio con 500 a 5.000 páginas y unas pocas descargas de archivos, ke_search Premium es la solución de búsqueda más económica en el ecosistema TYPO3. Solo a partir de más de 10.000 documentos indexados, Solr se convierte en la mejor opción.

## Escenarios de uso habituales

El escenario estándar es el sitio web corporativo con catálogo de productos, revista, FAQ y área de descargas. La función de autocompletado muestra sugerencias mientras se escribe y reduce la tasa de abandono de búsqueda entre un 15 y un 25%. Segundo escenario: portales de conocimiento y colecciones de documentos donde ke_search Premium extrae texto de PDF, DOCX y otros formatos. Tercer escenario: indexadores personalizados para sistemas de terceros mediante la API Custom Indexer.

## Arquitectura técnica

ke_search almacena el índice en una tabla dedicada en la base de datos TYPO3. La indexación se ejecuta mediante tareas Scheduler. La versión Premium amplía el indexador base con indexación de archivos, autocompletado e indexadores personalizados. El autocompletado se realiza mediante un endpoint AJAX que ejecuta una búsqueda por prefijo en el índice con cada pulsación de tecla.

## Problemas frecuentes

Problema uno: tiempos de indexación largos con grandes volúmenes de datos. Solución: activar indexación incremental. Problema dos: falta de instalación de Tika o pdftotext, lo que hace que la indexación de archivos falle silenciosamente. Problema tres: ordenación por relevancia que requiere ajuste de la ponderación por TypoScript.

## Migración y compatibilidad de versiones

ke_search se mantiene por un equipo de desarrollo dedicado y es compatible de forma oportuna con cada release LTS de TYPO3. La versión Premium actual soporta TYPO3 v11 y v12. Para v13, la compatibilidad está en desarrollo. Gosign emplea ke_search Premium en proyectos TYPO3 que necesitan búsqueda interna pero no justifican el funcionamiento de un servidor Solr.

--- Anuncios clasificados TYPO3 - Clasificados | Gosign ---
> Extensión de anuncios clasificados para TYPO3. Plataforma con categorías, fotos, datos de contacto, función de búsqueda.

## Los anuncios clasificados en el propio sitio web son una alternativa a las plataformas de mercado

Asociaciones, portales regionales y sitios web comunitarios necesitan a veces una función de anuncios clasificados: los miembros publican artículos usados, los vecinos ofrecen servicios, las organizaciones median donaciones de bienes. La extensión kleinanzeigen lleva esta funcionalidad directamente a TYPO3. Los usuarios crean anuncios en el frontend, otros usuarios los encuentran mediante categorías y búsqueda, y la redacción mantiene el control sobre aprobación y moderación.

El caso de uso es limitado: quien necesite una plataforma de mercado completa con función de pago, sistema de valoraciones y protección al comprador, está mejor servido con una solución especializada. Para portales comunitarios con 50 a 500 anuncios activos simultáneamente, la extensión es una herramienta sólida.

## Escenarios de uso habituales

El escenario más frecuente es el portal de asociaciones. El segundo escenario: plataformas regionales y portales urbanos. El tercer escenario: bolsas internas en empresas o universidades donde los empleados ofrecen muebles de oficina, bicicletas o pisos de alquiler temporal.

## Arquitectura técnica

La extensión utiliza el framework Extbase/Fluid de TYPO3. Los anuncios se almacenan como registros de dominio propios. En el frontend hay tres plugins disponibles: vista de lista con filtro y búsqueda, vista de detalle para anuncios individuales y formulario de entrada para nuevos anuncios. El formulario de entrada requiere login frontend (fe_users). La moderación se realiza mediante un flag de aprobación en el backend.

## Problemas frecuentes

Problema uno: anuncios spam. Solución: obligación de login frontend, campos honeypot, CAPTCHA opcional y moderación de aprobación. Problema dos: optimización de imágenes cuando los usuarios suben fotos de 4-8 MB desde el smartphone. Problema tres: gestión de caducidad de anuncios obsoletos.

## Migración y compatibilidad de versiones

kleinanzeigen fue desarrollada para versiones antiguas de TYPO3 y no tiene soporte oficial para v12 o v13. En una migración, Gosign recomienda un nuevo desarrollo sobre base Extbase actual que migre los datos existentes y adapte la funcionalidad a los requisitos específicos del portal. El esfuerzo es típicamente de 5 a 10 días laborables para funcionalidad básica. La ventaja del nuevo desarrollo: la estructura de base de datos puede optimizarse, las plantillas frontend utilizan características Fluid actuales y el comportamiento responsive se integra desde el principio.

--- Mailchimp Signup TYPO3 | Gosign ---
> Extensión de registro Mailchimp para TYPO3. Formulario de inscripción sencillo con sincronización de listas.

## Los formularios de registro de Mailchimp en TYPO3 requieren cumplimiento del RGPD, no solo un plugin

Las suscripciones a newsletters son uno de los objetivos de conversión más importantes en webs corporativas. koning_mailchimp_signup conecta formularios frontend de TYPO3 directamente con la API de Mailchimp: un visitante introduce su correo electrónico, la extensión lo transfiere a la audiencia configurada en Mailchimp, y Mailchimp envía el correo de Double-Opt-In. Técnicamente funciona en 15 minutos. El verdadero reto no es la técnica, sino el RGPD: Mailchimp procesa datos personales en servidores de EE.UU., lo que exige un contrato de encargado del tratamiento y un mecanismo de transferencia documentado (actualmente: EU-US Data Privacy Framework, supervisado por la AEPD en España).

Para equipos de marketing que ya utilizan Mailchimp como plataforma de newsletter y quieren conectar su web TYPO3, la extensión es el camino más corto. Quien aún no haya elegido plataforma debería evaluar alternativas europeas como Brevo, rapidmail o mailingwork.

## Los escenarios típicos son newsletters de blog, lead magnets y registros de eventos

El escenario estándar es la newsletter de blog o revista. Bajo cada artículo aparece un formulario compacto de suscripción con campo de correo y casilla de consentimiento. La extensión transfiere la dirección a una audiencia de Mailchimp y etiqueta al suscriptor con la fuente (p.ej. "blog-sidebar" o "article-footer"). Marketing puede así enviar por segmentos.

Segundo escenario: lead magnets con descarga automática. Un visitante se suscribe y recibe automáticamente un whitepaper, una checklist o un código de descuento mediante una automatización de bienvenida de Mailchimp. La extensión entrega el suscriptor, Mailchimp gestiona la automatización. La tasa de conversión de este patrón en webs B2B suele situarse entre el 2 y el 5 por ciento de los visitantes.

Tercer escenario: registros para eventos. Una empresa invita a un webinar o congreso. La inscripción se realiza mediante un formulario ampliado con nombre, correo y empresa. La extensión transfiere los datos a una audiencia dedicada de Mailchimp configurada para comunicación del evento (invitación, recordatorio, seguimiento). Tras el evento, la audiencia puede reutilizarse para campañas de seguimiento.

## La arquitectura técnica conecta un formulario Fluid con la API v3 de Mailchimp

La extensión registra un elemento de contenido en TYPO3 que renderiza un formulario de suscripción. El formulario contiene como mínimo un campo de correo electrónico y una casilla de consentimiento. Campos opcionales como nombre, apellidos y empresa se activan mediante la configuración del backend. Las plantillas Fluid se pueden sobrescribir a través de un Site Package.

Tras el envío, la extensión lanza un POST request a la API v3 de Mailchimp. La API Key y el Audience ID se configuran en el Extension Manager de TYPO3. La extensión soporta tags (para segmentación), Merge Fields (para datos personalizados) y control del comportamiento Double-Opt-In (activado o desactivado, siendo el RGPD en España el que exige Double-Opt-In).

Gestión de errores: cuando la API de Mailchimp devuelve un error (ya suscrito, correo inválido, rate limit), la extensión muestra un mensaje de error configurable en el frontend. Los errores se registran además en el log de TYPO3, útil para analizar problemas de sincronización. El mensaje de error más frecuente en producción es "Member Exists" (el suscriptor ya está en la audiencia), que no es un error técnico sino informativo y debería mostrarse como "Ya estás suscrito".

## Los problemas habituales afectan a la documentación RGPD, Double-Opt-In y estilos del formulario

Problema uno: documentación RGPD ausente. La extensión transfiere datos personales a un proveedor estadounidense. Sin contrato de encargado del tratamiento con Mailchimp (Intuit), sin documentación del mecanismo de transferencia en la política de privacidad y sin casilla de consentimiento en el formulario, la integración es ilegal según la normativa española y europea. La solución: formalizar el contrato con Mailchimp (disponible en Account > Legal), documentar el mecanismo de transferencia en la política de privacidad y configurar la casilla de consentimiento como campo obligatorio.

Problema dos: configuración del Double-Opt-In. Mailchimp permite añadir suscriptores directamente a la lista sin correo de confirmación (Single-Opt-In). En España, conforme al RGPD y la LOPDGDD, esto es problemático. La extensión debe configurarse para que Mailchimp envíe un correo de confirmación y active al suscriptor solo tras hacer clic en el enlace.

Problema tres: el estilo del formulario no encaja con el diseño corporativo. La extensión incluye estilos mínimos por defecto que rara vez encajan con el proyecto. La solución: sobrescribir la plantilla Fluid en el Site Package y adaptar las clases CSS al sistema de diseño existente. El esfuerzo es de 1 a 2 horas.

Un cuarto problema que aparece en webs multiidioma: los textos de consentimiento y mensajes de error no están preconfigurados para todos los idiomas. En proyectos TYPO3 con 5 versiones idiomáticas, las etiquetas deben traducirse manualmente en los archivos XLF o mediante overrides de TypoScript.

## La extensión funciona con TYPO3 v12, para v13 la API de Mailchimp es el camino más estable

koning_mailchimp_signup soporta TYPO3 v11 y v12. Para TYPO3 v13 la disponibilidad depende del mantenedor de la comunidad. Dado que la API v3 de Mailchimp es estable y cambia raramente, una integración directa con la API sin extensión es la alternativa con menor mantenimiento para proyectos v13. Gosign implementa en nuevos proyectos preferentemente un Custom Finisher para el TYPO3 Form Framework o para powermail que llama directamente a la API de Mailchimp. Esto elimina la dependencia de la extensión y da control total sobre gestión de errores, logging y documentación RGPD.

El enfoque Custom Finisher tiene otra ventaja: puede adaptarse con poco esfuerzo a otras plataformas de newsletter. Si una empresa migra de Mailchimp a Brevo, rapidmail o mailingwork, solo hay que cambiar el cliente API en el Finisher, no toda la configuración del formulario.

--- kuferweb TYPO3 - Gestión de cursos Kufer | Gosign ---
> kuferweb: integrar la gestión de cursos Kufer en TYPO3. Catálogo de cursos, inscripción, sincronización. Acelerado con IA.

## kuferweb es el puente entre el sistema especializado Kufer y el sitio web público TYPO3

Las escuelas de adultos, los centros de formación y las academias gestionan su actividad de cursos desde hace décadas con software especializada, y en muchos centros del ámbito germanófono ese software se llama Kufer. Kufer cubre todo el ciclo de vida del curso: gestión de docentes, planificación, reserva de aulas, participantes, facturación, certificados. Para la web eso supone una tarea estándar: el catálogo de cursos mantenido en el backoffice debe ser visible al día en la web TYPO3, incluyendo búsqueda con filtros, vistas de detalle e inscripción en línea.

El público está claramente delimitado: centros de formación con un mandante Kufer existente que operan su web sobre TYPO3. Típico es una escuela municipal de adultos con unos 2.500 cursos por semestre y media docena de docentes que mantienen sus cursos en Kufer. Sin una integración limpia, el catálogo de la web se queda obsoleto, la doble gestión se convierte en estado permanente y las inscripciones acaban en un sistema separado que nadie aprecia.

## Escenarios típicos de uso

Un primer escenario es el catálogo de cursos actualizado automáticamente. Una escuela con 2.500 cursos por semestre quiere que cada alta de curso, cada cambio de precio y cada cambio de docente se vuelva visible en la web sin intervención manual. Un job de sincronización horario tira los datos actuales de Kufer, los escribe en una tabla TYPO3 y actualiza la búsqueda. El redactor ya no mantiene cursos en el backend de TYPO3.

Un segundo escenario es la inscripción en línea directa. Un centro de formación con programas subvencionados quiere llevar a los interesados directamente desde la página de detalle del curso a un proceso de inscripción que, en segundo plano, llama a la API de Kufer y registra al participante en Kufer. TYPO3 sirve como frontend, Kufer sigue siendo la fuente de la verdad, la redacción ve el nuevo estado de inscripción en la interfaz que ya conoce.

Un tercer escenario es la búsqueda con facetas específicas del ámbito. Una academia con 40 áreas y varios miles de cursos quiere permitir a los interesados buscar por categorías, lugares, fechas, docentes y clases de precio. La búsqueda corre en la página TYPO3 contra un índice local construido a partir del export de Kufer, con buen rendimiento e independiente de la disponibilidad de la aplicación especializada.

Un cuarto escenario es la salida multilingüe de cursos. Una escuela de idiomas con sedes en varias regiones mantiene los cursos en Kufer solo en un idioma y quiere ofrecer en la web una presentación multilingüe para los interesados. La integración asume el mapping a las variantes de idioma de TYPO3, complementa los campos Kufer con traducciones manuales en la redacción del CMS y garantiza que los cambios en Kufer no sobrescriban las traducciones locales.

## Arquitectura técnica

Las integraciones kuferweb en TYPO3 son casi siempre desarrollos a medida, porque las estructuras de datos varían por mandante Kufer y las versiones de API han cambiado varias veces a lo largo de los años. El planteamiento estándar es una extensión Extbase ligera con tres pilares: una capa de servicio que encapsula la API de Kufer, una capa de persistencia que replica los cursos en tablas TYPO3 y una capa de presentación que entrega plantillas Fluid para lista, filtro y detalle.

La sincronización corre a través de una tarea del Scheduler de TYPO3. Para catálogos grandes se recomienda una importación delta que solo transmita los cursos modificados desde la última ejecución. La API de Kufer suele entregar un timestamp o una marca de cambio por curso, que se utiliza para la detección delta.

La inscripción en línea requiere un path adicional de API y una gestión limpia de errores. La API de Kufer puede responder lenta bajo alta carga, por eso las inscripciones corren típicamente de forma asíncrona: el formulario deposita la petición de alta en una cola, un worker la transmite a Kufer y el participante recibe un correo de confirmación en cuanto Kufer acusa el registro.

## Problemas frecuentes y soluciones

El primer problema es la divergencia de campos entre mandantes Kufer. Lo que en el mandante A se llama "número de evento" en el mandante B es "código de curso" y en el mandante C "número de inscripción". La solución es un field mapping configurable en la extensión TYPO3 que se adapta por instalación y no queda hardcoded en el código.

El segundo problema es la calidad de datos en el catálogo de cursos. Las redactoras no siempre mantienen textos completos en Kufer: faltan descripciones breves, no hay imágenes, no se definen públicos objetivo. En la web esas lagunas aparecen como campos vacíos. La solución es una capa de validación en la sincronización que marque los cursos incompletos en el backend y exija a la redacción completarlos.

El tercer problema es la lógica de cancelación. Cuando se cancelan cursos en Kufer, deben desaparecer de la web o al menos marcarse como cancelados. La solución es poner explícitamente los cursos cancelados en la sincronización en un estado que se oculte en la lista y dotar la página de detalle de un redirect a una vista general de categoría.

Un cuarto problema es la visualización de la ocupación en tiempo real. Los interesados ven en la web "quedan 3 plazas libres" aunque la reserva en segundo plano ya haya pasado a lista de espera. La solución es no leer la indicación de ocupación desde el caché de sincronización, sino emitir, en cada llamada de la página de detalle, una pequeña llamada en vivo a Kufer, con caching agresivo (30 a 60 segundos) y un fallback al último valor conocido si la API no responde.

## Migración y compatibilidad de versiones

Las integraciones kuferweb corren en TYPO3 v11, v12 y v13 siempre que la conexión API esté construida de forma moderna. El punto de dolor más frecuente no es la versión de TYPO3, sino la versión de Kufer: cuando el centro migra su mandante Kufer a una nueva versión, cambian ocasionalmente endpoints API y estructuras de datos, lo que obliga a reajustar la integración TYPO3.

Gosign construye integraciones kuferweb sobre la base de la API actual de Kufer, comprueba antes del inicio del proyecto la compatibilidad con el mandante del cliente y monta la integración de forma tan modular que los futuros upgrades de API funcionen sin reconstrucción a gran escala. Con apoyo de IA, el código del cliente API nace en horas en lugar de días, con lo que la puesta en marcha en la mayoría de los proyectos se vuelve realista en dos o tres sprints.

--- LayerSlider TYPO3 - Migración de slider | Gosign ---
> Plugin premium de slider/animaciones para TYPO3. Crítico para el rendimiento: grandes bundles JS, muchas peticiones HTTP.

## LayerSlider carga 400 KB de JavaScript para algo que se resuelve con 20 KB de CSS

LayerSlider fue entre 2012 y 2018 uno de los sliders premium más populares para TYPO3 y WordPress. Banners animados con efectos de paralaje, apariciones de texto, transiciones y fondos de vídeo. El resultado lucía impresionante en la portada. El problema: LayerSlider carga una librería JavaScript de 300 a 400 KB (minificada), requiere jQuery como dependencia (otros 90 KB) y genera de 15 a 30 peticiones HTTP para imágenes, fuentes y archivos de configuración. En una web por lo demás optimizada, LayerSlider duplica el tiempo de carga de la portada.

Google PageSpeed Insights lo penaliza sin piedad. Un Largest Contentful Paint (LCP) superior a 4 segundos solo por el slider significa una pérdida de puntuación de 20 a 40 puntos. Desde que Google utiliza los Core Web Vitals como factor de posicionamiento (2021), un LCP deficiente es una desventaja SEO medible.

## Escenarios de uso habituales

**Webs existentes con banners hero animados.** Webs corporativas de los años 2014 a 2019, donde el slider de portada muestra de 3 a 5 diapositivas animadas. El slider se configuró una vez y apenas se ha modificado, pero causa el overhead de rendimiento completo en cada visita.

**Landing pages con presentaciones de producto.** Equipos de marketing usan LayerSlider para presentaciones con múltiples imágenes, texto overlay y botones CTA en rotación automática. Los datos de conversión muestran típicamente que el 80 % de los usuarios solo ven la primera diapositiva.

**Páginas de eventos con animaciones de cuenta atrás.** LayerSlider puede mostrar temporizadores, pop-ups y animaciones activadas por scroll. Hoy existen soluciones ligeras con CSS sin overhead de JavaScript.

## Arquitectura técnica

LayerSlider es un plugin comercial. La integración TYPO3 funciona como extensión con tabla propia para configuraciones de slider. Cada slider consta de slides, cada slide de capas (texto, imagen, vídeo, forma, botón), y cada capa tiene ajustes de animación. La salida frontend carga la librería core, jQuery (si no está disponible globalmente), plugins opcionales y la configuración como JSON.

## Problemas frecuentes y soluciones

**Los Core Web Vitals caen tras instalar el slider.** El LCP sube de 1,5 a más de 4 segundos. Solución: reemplazar LayerSlider por un hero estático con animación CSS. LCP resultante: por debajo de 2 segundos.

**La licencia caduca, faltan actualizaciones.** La variante TYPO3 no se distribuye vía TER y no tiene mecanismo de actualización automática. LayerSlider tuvo en el pasado vulnerabilidades de seguridad críticas. Solución: no parchear, sino migrar.

**Los contenidos del slider no son indexables.** El texto se inserta como atributo data o vía JavaScript. Solución: colocar texto relevante y CTAs directamente en el HTML de la página.

## Migración y compatibilidad de versiones

LayerSlider no tiene compatibilidad oficial con TYPO3 v12 ni v13. Para v12+ no hay ruta de actualización. Gosign migra LayerSlider a una de tres alternativas: Swiper (open source, 40 KB, sin jQuery, touch-native) para sliders de imagen sencillos, Splide (open source, 30 KB, soporte ARIA completo) para sliders accesibles, o un hero puro CSS/HTML sin librería cuando solo se necesita una imagen con texto overlay.

La migración dura de 0,5 a 2 días por slider. El efecto medible: una web que pasa de LayerSlider a hero estático con animación CSS mejora típicamente su Google PageSpeed entre 15 y 35 puntos. El LCP baja de 3-5 segundos a menos de 2 segundos. Para empresas que dirigen tráfico a la portada vía Google Ads, esto significa directamente mejores Quality Scores y costes por clic más bajos.

--- Leaflet TYPO3 - Mapas OpenStreetMap | Gosign ---
> Mapas Leaflet en TYPO3: OpenStreetMap sin costes de Google. Buscador de sucursales, clustering, routing. Acelerado con IA.

## Mapas OpenStreetMap con Leaflet sustituyen a Google Maps sin costes de licencia ni riesgos RGPD

Google Maps cobra a partir de 28.000 cargas de mapa al mes y transfiere datos de usuarios a servidores en EE.UU. Para empresas con buscador de sucursales, Store Locator o mapa de ubicaciones en su web, eso son dos problemas a la vez: presupuesto y protección de datos. Leaflet resuelve ambos. La librería JavaScript de código abierto renderiza mapas interactivos basados en datos de OpenStreetMap, funciona completamente en el lado del cliente y no tiene costes de licencia. La extensión TYPO3 integra Leaflet como elemento de contenido: los editores gestionan ubicaciones en el backend, la extensión genera el mapa en el frontend.

Para empresas con 5 a 500 ubicaciones, Leaflet es la recomendación estándar. Solo cuando se necesitan funcionalidades específicas de Google como Street View, edificios 3D o datos de tráfico en tiempo real, Google Maps es la mejor opción. En todos los demás casos, Leaflet ofrece la misma funcionalidad con cero costes de licencia y sin discusiones sobre protección de datos.

## Los escenarios típicos son buscadores de sucursales, mapas inmobiliarios y ubicaciones de eventos

El escenario más frecuente es el buscador de sucursales o ubicaciones. Una empresa con 20 a 200 sucursales muestra todas las ubicaciones en un mapa interactivo. Los usuarios pueden hacer zoom, buscar por código postal y hacer clic en los marcadores para ver dirección, horarios y datos de contacto. Cuando la densidad de marcadores es alta, el clustering agrupa ubicaciones cercanas en un marcador colectivo que se desglosa al hacer zoom. Un buscador típico con 100 ubicaciones y clustering carga en menos de 500ms.

Segundo escenario: mapas inmobiliarios y de propiedades. Inmobiliarias, administradores de fincas y promotoras muestran propiedades disponibles en un mapa. Los marcadores contienen información básica (precio, habitaciones, superficie) como popup y enlazan a la página de detalle. La extensión TYPO3 puede renderizar registros de una tabla Extbase como marcadores.

Tercer escenario: ubicaciones de eventos y turismo. Organizadores, asociaciones turísticas y ayuntamientos muestran POIs (Points of Interest), rutas y sedes de eventos en un mapa. Leaflet soporta además de marcadores de punto, líneas (para rutas de senderismo) y polígonos (para áreas), lo que lo convierte en una herramienta flexible para aplicaciones turísticas.

## La arquitectura técnica separa limpiamente el backend de datos y el renderizado del mapa

La extensión TYPO3 almacena datos de ubicación como registros Extbase en una tabla propia. Cada registro contiene nombre, dirección, coordenadas (latitud/longitud), descripción y campos opcionales como horario, teléfono e imagen. Las coordenadas pueden introducirse manualmente o generarse automáticamente desde la dirección mediante un servicio de geocodificación.

En el frontend, la extensión renderiza un contenedor de mapa e inicializa Leaflet con JavaScript. Los tiles del mapa se cargan desde un servidor de tiles configurable. El estándar es OpenStreetMap, pero Mapbox, Stamen y otros proveedores son configurables via TypoScript. Los marcadores se pasan como array JSON al JavaScript, lo que funciona con buen rendimiento incluso con más de 500 ubicaciones.

El clustering se realiza mediante el plugin Leaflet.markercluster, que agrupa marcadores en niveles de zoom bajos y los desglosa al hacer zoom. Los umbrales de cluster son configurables. Para la búsqueda por código postal o localidad se filtra en el lado del cliente, lo que funciona hasta 1.000 marcadores sin soporte del servidor.

Los estilos del mapa son completamente personalizables: colores, tipografías, anchos de calle y detalles del mapa se controlan mediante configuración de tile layer y CSS personalizado. Comparado con Google Maps, cuyo estilizado es limitado, Leaflet ofrece control total sobre la apariencia.

## Los problemas habituales afectan a geocodificación, disponibilidad de tile server y visualización responsive

Problema uno: errores de geocodificación con direcciones imprecisas. No todas las direcciones se resuelven correctamente. Especialmente polígonos industriales, nuevas urbanizaciones y direcciones rurales producen coordenadas inexactas. La solución: usar geocodificación automática como llenado inicial y revisar las coordenadas manualmente. La extensión debería mostrar una ventana de mapa en el backend donde el editor pueda corregir el marcador arrastrándolo.

Problema dos: disponibilidad del tile server. El servidor de tiles estándar de OpenStreetMap tiene una política de uso justo y puede aplicar rate limiting con tráfico alto. Para webs productivas con más de 50.000 cargas de mapa al mes se recomienda un tile server propio o un proveedor comercial como Mapbox o Maptiler. Los costes rondan los 5 a 50 euros al mes, todavía muy por debajo de Google Maps.

Problema tres: visualización responsive en móviles. Los mapas en pantallas pequeñas son difíciles de manejar porque el zoom entra en conflicto con el scroll de la página. La solución: restringir gestos táctiles del mapa a dos dedos (desactivar scrollWheelZoom y dragging en móviles) y ofrecer un botón "Ampliar mapa" que abra el mapa a pantalla completa.

## Leaflet es a prueba de futuro, la extensión TYPO3 debe verificarse para v13

Leaflet como librería JavaScript es independiente de la versión de TYPO3 y se desarrolla activamente. La extensión TYPO3 que gestiona la integración backend y el renderizado debe verificarse al actualizar a v12 o v13. Los cambios en la API Extbase de v12 afectan a clases de repositorio y configuración de persistencia. En Gosign migramos integraciones Leaflet típicamente mediante un plugin personalizado en el propio Sitepackage que incorpora la librería Leaflet directamente y obtiene los datos de ubicación de una tabla Extbase o un endpoint JSON. Esto elimina la dependencia de la extensión y da control total sobre las actualizaciones. La propia librería Leaflet se incluye via npm o CDN y con un tamaño de 39 KB (comprimida) es significativamente más ligera que la API JavaScript de Google Maps (más de 185 KB), lo que impacta positivamente en el tiempo de carga.

--- LimeSurvey TYPO3 - Integración de encuestas | Gosign ---
> LimeSurvey en TYPO3: integrar encuestas, conexión SSO, panel de resultados. Integración acelerada con IA.

## LimeSurvey es la respuesta conforme al RGPD para encuestas empresariales que no pueden acabar en Google Forms

Quien realiza en España encuestas profesionales (encuestas de empleados, investigación de mercado, estudios de evaluación, recopilaciones científicas) y necesita al mismo tiempo conformidad con el RGPD, plena soberanía sobre los datos y una traza de auditoría limpia, acaba casi inevitablemente en LimeSurvey. El software de código abierto corre en el servidor propio, almacena los datos de respuesta exclusivamente en la base de datos propia y ofrece todos los tipos de pregunta que la investigación seria exige. Para operadores TYPO3 la pregunta no es si deben usar LimeSurvey, sino cómo integrarlo en su web existente. La AEPD valora especialmente el hosting propio en auditorías del sector público.

El público son típicamente universidades, centros de investigación, administraciones públicas, hospitales, grandes empresas con comité de empresa y ONG con encuestas a públicos sensibles. Un ejemplo: una universidad como la UAM con 18.000 estudiantes realiza cada semestre una evaluación docente y quiere volcar los resultados en su propia web TYPO3 sin que los estudiantes tengan que alternar entre dos sistemas.

## Escenarios típicos de uso

Un primer escenario es la participación en encuestas sin rupturas en la página TYPO3. En lugar de enviar a los estudiantes a un dominio LimeSurvey separado, el cuestionario se muestra directamente en la página web. Las respuestas fluyen mediante API a LimeSurvey, los estudiantes ven la navegación habitual de la web. Eso baja perceptiblemente la tasa de abandono.

Un segundo escenario es la identificación de participantes basada en SSO. Una cadena hospitalaria con 8.000 empleados realiza una encuesta interna. Los participantes se autentican en la intranet TYPO3, hacen clic en el enlace de la encuesta y aterrizan en LimeSurvey sin tener que volver a iniciar sesión. El puente SSO garantiza que cada empleado participe solo una vez y que los datos personales de TYPO3 no fluyan hacia las respuestas de la encuesta.

Un tercer escenario es la visualización de resultados directamente en la web. Un ayuntamiento realiza una encuesta ciudadana sobre un proyecto urbanístico y quiere mostrar diariamente los estados intermedios como diagrama de barras en la página del proyecto. Un job de sincronización obtiene los agregados anonimizados mediante la API y los renderiza en un elemento de contenido TYPO3, sin que los datos en bruto toquen la instalación TYPO3.

Un cuarto escenario es el estudio longitudinal en investigación. Un proyecto de investigación sobre la carga laboral en el sector sanitario encuesta a la misma cohorte cuatro veces al año durante dos años. La página TYPO3 sirve como punto de información y entrada, LimeSurvey aloja las recogidas y la integración se ocupa de que cada participante reciba, mediante un enlace personalizado, sus encuestas de seguimiento sin que los investigadores tengan que mantener datos de contacto en LimeSurvey.

## Arquitectura técnica

LimeSurvey pone a disposición dos accesos API: la interfaz clásica RemoteControl2 sobre JSON-RPC y la API REST más nueva en las versiones actuales. Para las integraciones con TYPO3, RemoteControl2 sigue siendo el ancla de estabilidad, porque está disponible en instalaciones LimeSurvey más antiguas y cubre autenticación completa, gestión de participantes y consulta de respuestas.

La integración con TYPO3 corre por regla general como extensión propia. Una capa de servicio encapsula las llamadas API, un plugin entrega elementos de contenido para incrustar encuestas y una middleware implementa la lógica SSO. Para la incrustación hay dos variantes: la encuesta se invoca mediante un token firmado y se incrusta por iFrame, o las preguntas se leen mediante la API y se renderizan directamente como plantilla Fluid. Lo segundo ofrece la mejor experiencia de usuario, pero requiere más esfuerzo de desarrollo.

El puente SSO se basa en un token firmado que TYPO3 genera y LimeSurvey valida. En LimeSurvey se configura para ello un plugin que lee el token de la URL y da de alta al participante como token anónimo en la tabla de participantes de la encuesta. Es importante que el token esté limitado en el tiempo y sea válido solo una vez por participante.

## Problemas frecuentes y soluciones

El primer problema es el manejo de sesiones entre TYPO3 y LimeSurvey. Ambos sistemas tienen sesiones propias, y si se elige el enfoque iFrame surgen problemas con cookies de terceros en los navegadores modernos. La solución es operar LimeSurvey bajo un subdominio de la instalación TYPO3, para que las cookies se acepten como first party, o usar la variante API con renderizado del lado del servidor.

El segundo problema es la crisis de rendimiento en la presentación de resultados. Quien consulta la API por agregados en cada carga de página sobrecarga innecesariamente el servidor LimeSurvey. La solución es un job de sincronización que escriba los agregados a intervalos regulares (por ejemplo horarios) en una tabla TYPO3 y renderice el elemento de contenido desde esa tabla de caché.

El tercer problema es el tratamiento conforme al RGPD de datos personales. En encuestas a empleados el empleador no puede, por regla general, reconocer quién ha dado qué respuesta. La solución es un concepto limpio de separación: TYPO3 solo entrega tokens anonimizados, LimeSurvey almacena respuestas sin referencia, y la agregación se realiza exclusivamente mediante indicadores que no permiten deducir información sobre personas concretas.

Un cuarto problema son las debilidades de visualización en móvil en modo iFrame. Las encuestas de LimeSurvey son responsive, pero en un iFrame de TYPO3 aparecen barras de scroll duplicadas y botones cortados en pantallas pequeñas. La solución es, para el uso móvil, cambiar al renderizado del lado del servidor o adaptar el iFrame dinámicamente al contenido, de modo que el contenedor del layout de página asuma la altura completa.

## Migración y compatibilidad de versiones

Las integraciones con LimeSurvey corren en TYPO3 v11, v12 y v13. El reto mayor está en el lado de LimeSurvey: entre LimeSurvey 3.x, 5.x y 6.x han cambiado detalles de API y procedimientos de autenticación. Quien eleva una integración existente a una nueva versión de LimeSurvey debería verificar las llamadas API contra la documentación de la versión correspondiente e, idealmente, ejecutar una prueba de integración automatizada contra una instancia de staging de LimeSurvey.

Gosign implementa integraciones con LimeSurvey para universidades, hospitales y organismos públicos. El cliente API nace con apoyo de IA a partir de la documentación de RemoteControl2, el puente SSO se adapta individualmente a la gestión de identidad existente, y la implementación se realiza a lo largo de una documentación RGPD clara que alivia el trabajo del delegado de protección de datos.

--- linkhandler TYPO3 - Enlaces a registros | Gosign ---
> linkhandler: enlaces a registros personalizados en el RTE de TYPO3. Enlazar noticias, eventos y productos directamente. Configuración y migración.

## linkhandler evita los enlaces rotos cuando cambian las URLs

En TYPO3 una indicación Typolink se refiere directamente a una página, un archivo o una URL, no a un registro. En cuanto una redacción quiere enlazar desde el texto corrido a eventos, artículos de noticias, productos o direcciones, debe o bien meter la URL de forma hardcoded o bien intercalar una extensión que genere una URL estable a partir de un ID de registro. Esa es exactamente la tarea de linkhandler. La extensión de Cobwebsters registra nuevos tipos de enlace en el RTE de TYPO3 y en el Link Browser y los conecta con cualquier tabla de base de datos. En un proyecto de redacción con más de cien referencias cruzadas internas, esa es la diferencia entre una arquitectura de contenido que funciona y una página cementerio llena de enlaces 404.

## Escenarios típicos: cualquier redacción con más de un dominio de contenido

En cuanto coexisten en el mismo proyecto noticias, eventos y productos, los redactores necesitan un sistema de enlaces limpio. Una universidad enlaza desde un artículo de revista al evento en sf_event_mgt, desde el texto del evento al autor participante de md_news_author y, desde el perfil del autor, de vuelta a todas sus contribuciones en GeorgRinger/news. Tres extensiones, tres tipos de registro, y sin linkhandler cada una de esas referencias cruzadas sería una URL hardcoded que se rompe en el siguiente refactoring de slugs. En el día a día, eso significa que un único refactoring de URLs puede generar decenas o cientos de broken links que solo aparecen semanas después en el informe de Google Search Console.

Un segundo escenario son los textos de comercio electrónico: descripciones de producto que remiten a accesorios o artículos de blog que enlazan a productos de aimeos. linkhandler genera las URLs automáticamente a partir de la configuración de routing del producto, y en un refactoring de categorías todos los enlaces viajan con él.

En tercer lugar la necesidad aparece en los listados de ubicaciones. Quien mantiene una estructura de sucursales o un directorio de contactos con tt_address o un modelo propio quiere enlazar desde los artículos a la página de detalle correspondiente. El enlace linkhandler permanece estable incluso si la ubicación se renombra.

## Arquitectura técnica: registro de tipos de enlace con YAML y clase handler

linkhandler utiliza el mecanismo LinkHandler del núcleo de TYPO3 disponible desde v8. Cada tipo de enlace se registra mediante un archivo YAML en el directorio Config. El YAML define el identificador del handler, la tabla, el modelo Extbase y la configuración de routing. En el RTE y en el Link Browser el tipo de enlace aparece como nueva pestaña: "Noticia", "Evento", "Producto", "Dirección". Cada pestaña muestra una lista de los registros disponibles con función de búsqueda y filtro, de modo que los redactores encuentran la entrada deseada incluso con miles de entradas de noticias.

El resolver propiamente dicho es una clase PHP que hereda de AbstractLinkHandler e implementa los métodos modifyLinkField y generateRelativeUrl. Los métodos generan a partir del ID de registro una URL semántica a través de la Site Config y del router de la extensión correspondiente. En el frontend el Typolink se llama con el parámetro t3://record y el Page Rendering lo resuelve a la URL final. Eso significa: aunque diez mil artículos enlacen al mismo registro de noticia, ante un cambio de slug solo hay que actualizar el propio registro del artículo; todos los enlaces se resuelven automáticamente a la nueva URL.

La configuración toca en profundidad el sistema de enlaces de TYPO3, pero se mantiene declarativa: tras el registro YAML y el clear de caché, el nuevo tipo de enlace queda disponible en todo el proyecto, incluidas plantillas Fluid y componentes de menú. Quien no usa linkhandler explícitamente obtiene el mecanismo también a través del LinkHandler del núcleo, pero sin la capa de abstracción YAML ni la cómoda UI de picker backend de la extensión.

## Problemas frecuentes: caché, variantes de idioma y file handler

El tema de soporte más habitual son las inconsistencias de caché tras actualizar un registro. Cuando se adapta el slug de un artículo de noticia, el caché de página del artículo fuente en el que está el enlace linkhandler también debe vaciarse; si no, la URL antigua se mantiene en la salida. La solución es una cache tag que se establece con el renderizado del Typolink. Muchas instalaciones no la activan y luchan después con enlaces supuestamente rotos.

El segundo problema son las variantes de idioma. Un artículo de noticia en ES remite mediante linkhandler a un evento. La traducción al inglés del artículo debe remitir al mismo ID de evento, pero generar la URL en el idioma inglés. linkhandler ofrece esa resolución mediante el Language Aspect, pero la configuración YAML debe apuntar explícitamente a las variantes de routing de las páginas de destino. Quien usa idiomas fallback debe comprobar adicionalmente cómo se comporta el handler con traducciones ausentes: debería resolver en el idioma fallback, no retroceder al idioma principal.

En tercer lugar, el file handler es un caso especial. Quien junto a enlaces a registros quiere enlazar también a archivos FAL de TYPO3 debe configurar por separado el file handler de linkhandler o recurrir al file linker nativo de TYPO3. La combinación es posible, pero el orden de los handlers en el YAML decide qué pestaña aparece primero.

## TYPO3 v12 y v13 utilizan el LinkHandler del núcleo, la migración merece la pena

A partir de TYPO3 v11 el LinkHandler del núcleo es apto para producción y puede asumir por sí mismo muchas de las tareas de linkhandler. Aun así la extensión de Cobwebsters se sigue manteniendo porque aporta funciones de comodidad adicionales como el editor YAML, el picker de registro mejorado y la salida compatible con Schema. Para TYPO3 v12 y v13 existe una versión actual en TER y en Packagist.

En la revisión de migración Gosign comprueba cuántas llamadas a linkhandler hay en los contenidos RTE. Con menos de 50 ocurrencias a menudo merece la pena pasarse al LinkHandler del núcleo; con más de 100 ocurrencias o handlers muy personalizados, linkhandler sigue siendo la opción más pragmática. La migración a una nueva versión mayor suele transcurrir sin cambios de contenido, porque la sintaxis t3://record en el contenido se mantiene estable. Para el análisis usamos un escaneo sobre los campos tt_content que desglosa todos los tipos de enlace y genera una recomendación por instalación.

--- Ticker en vivo TYPO3 - Actualizaciones en tiempo real | Gosign ---
> Ticker en vivo para eventos en tiempo real: deportes, elecciones, conferencias. Basado en WebSocket o Polling, con recarga automática de nuevas entradas.

## Las actualizaciones en tiempo real en webs TYPO3 requieren más que un plugin de noticias con auto-refresh

Clubes deportivos, portales de noticias, ayuntamientos en noches electorales y organizadores de congresos necesitan una función que no existe en el core de TYPO3: mensajes breves cronológicos que aparezcan en tiempo real en la página sin que el visitante tenga que recargarla. La extensión liveticker resuelve esto con un plugin frontend que carga automáticamente nuevas entradas mediante AJAX-Polling o WebSocket y las inserta arriba en la línea temporal. Los editores escriben un mensaje en el backend, pulsan "Guardar" y el mensaje aparece segundos después en la web.

Para organizaciones que acompañan eventos en directo dos o tres veces al año en su web, la extensión es una solución pragmática. Quien necesite ticker diarios debería evaluar plataformas especializadas como Tickaroo, que cubren mejor contenido multimedia, integración de redes sociales y flujos de trabajo multiautor.

## Los escenarios típicos son eventos deportivos, elecciones municipales y congresos

El escenario más frecuente es el ticker deportivo. Un club deportivo amateur acompaña partidos en casa con un ticker en la web del club. Un editor al pie del campo teclea goles, tarjetas y sustituciones en el backend de TYPO3 (idealmente via backend móvil), y las entradas aparecen cronológicamente en la página. En un partido de liga regional con 500 a 2.000 visitantes simultáneos, el ticker debe funcionar de forma estable sin sobrecargar el servidor.

Segundo escenario: noches electorales en municipios y comarcas. En la noche electoral, los ayuntamientos publican resultados parciales a través de un ticker en vivo. Los mensajes contienen porcentajes de voto, proyecciones y comentarios del responsable electoral. El reto: todos los visitantes esperan el mismo resultado al mismo tiempo, lo que genera picos de tráfico.

Tercer escenario: congresos y asambleas de socios. Asociaciones y entidades hacen ticker en directo de asambleas generales para que los miembros que no están presencialmente puedan seguir el desarrollo. Las entradas contienen resultados de votaciones, intervenciones y acuerdos. Para asociaciones con 5.000 a 50.000 miembros que no pueden asistir a un evento presencial, un ticker en vivo es la forma más sencilla de participación digital que no requiere infraestructura de streaming de video.

## La arquitectura técnica se basa en registros TYPO3 con AJAX-Polling en el frontend

La extensión almacena entradas del ticker como registros TYPO3 en una tabla propia. Cada entrada contiene marca de tiempo, texto, imagen opcional y una categorización (p.ej. "Gol", "Tarjeta amarilla", "Resultado"). Los registros pertenecen a un contenedor de ticker asignado a un evento. Un editor puede gestionar varios tickers en paralelo, por ejemplo para diferentes partidos o eventos el mismo día.

En el frontend, el plugin renderiza las entradas existentes como lista cronológica (más recientes arriba) e inicia un temporizador JavaScript que en intervalos configurables (típicamente 10 a 30 segundos) envía un request AJAX a un endpoint TYPO3. El endpoint devuelve todas las entradas añadidas desde la última consulta. El JavaScript las inserta con una animación arriba en la lista.

Implementaciones avanzadas usan WebSockets en lugar de polling, reduciendo la latencia de 10-30 segundos a menos de 1 segundo. Esto requiere un servidor WebSocket (p.ej. Node.js con Socket.io) ejecutándose en paralelo al servidor web TYPO3. Para la mayoría de webs de clubes y municipales es excesivo, y AJAX-Polling con intervalos de 15 segundos ofrece una experiencia suficientemente cercana al tiempo real. Una solución intermedia son los Server-Sent Events (SSE), que utilizan una conexión HTTP persistente y son más sencillos de implementar que WebSockets.

## Los problemas habituales son carga del servidor en picos de tráfico, falta de entrada móvil y conflictos de caché

Problema uno: carga del servidor en picos de tráfico. Si 2.000 visitantes envían un request AJAX cada 15 segundos, son 8.000 requests por minuto. Sin estrategia de caché, un servidor compartido se colapsa. La solución: colocar un reverse proxy (p.ej. Varnish o Cloudflare) delante del endpoint AJAX que cachee la respuesta durante 5 segundos. Así los accesos reales al servidor de aplicación se reducen a 12 por minuto en vez de 8.000.

Problema dos: entrada móvil para editores. El backend de TYPO3 es de uso limitado en dispositivos móviles. Un editor al pie del campo tecleando bajo la lluvia en un smartphone necesita una máscara de entrada simplificada. La solución: un endpoint personalizado con un formulario reducido (campo de texto, dropdown de categoría, botón de envío) optimizado para navegadores móviles.

Problema tres: conflictos de caché con el page cache de TYPO3. Si la página donde se incrusta el ticker se sirve desde el caché de TYPO3, los visitantes ven entradas desactualizadas. La solución: excluir la página del ticker del page cache (USER_INT) o mejor: cachear la página y cargar solo el área del ticker por AJAX.

## La extensión fue construida para versiones anteriores de TYPO3, las soluciones personalizadas son más sostenibles

liveticker no tiene soporte oficial para TYPO3 v12 o v13. La funcionalidad principal es tan sencilla que una reconstrucción como plugin personalizado es en muchos casos más económica que migrar la extensión. Gosign construye funciones de ticker en vivo como plugins Extbase ligeros con un endpoint API JSON que es consumido por un cliente JavaScript sencillo en el frontend. El esfuerzo para una implementación básica (entrada backend, visualización frontend, AJAX-Polling) es de 3 a 5 días de trabajo.

La ventaja de una solución personalizada: la entrada móvil puede realizarse como Progressive Web App, de modo que el editor al pie del campo tenga una interfaz de entrada optimizada. Además, se puede intercalar una capa de caché (p.ej. Redis o Cloudflare Workers) entre frontend y TYPO3 que reduzca la carga del servidor en picos de tráfico al mínimo.

--- Mailchimp TYPO3 - Newsletter | Gosign ---
> Extensión Mailchimp para TYPO3. Sincronización de suscriptores, formularios de registro, segmentación. Gosign asesora sobre alternativas conformes con el RGPD.

## La integración Mailchimp-TYPO3 va más allá de formularios y sincroniza audiencias bidireccionalmente

Mientras koning_mailchimp_signup solo cubre formularios de registro, la extensión mailchimp va un paso más allá: sincroniza listas de suscriptores bidireccionalmente entre TYPO3 y Mailchimp, transfiere estadísticas de campañas al backend y puede generar plantillas de newsletter a partir de elementos de contenido TYPO3. Para empresas que utilizan Mailchimp no solo como envío de newsletter sino como plataforma central de automatización de marketing, la extensión cierra la brecha entre CMS y email marketing.

El aspecto del RGPD es aún más relevante con esta integración más profunda: no solo direcciones de correo, sino también datos de engagement (aperturas, clics, rebotes), tags y campos personalizados se transfieren entre sistemas. Sin contrato de encargado del tratamiento con Mailchimp y mecanismo de transferencia a EE.UU. documentado, esto no es conforme con la normativa de protección de datos española y europea.

## Los escenarios típicos son automatización de marketing, sincronización de plantillas y reporting

El escenario principal es la sincronización bidireccional de suscriptores para equipos de marketing. TYPO3 es la fuente de nuevas suscripciones (a través de formularios web), Mailchimp es la fuente de datos de engagement. La extensión concilia ambos sistemas regularmente, de modo que marketing puede ver en Mailchimp qué suscriptores se registraron desde qué página web, y en TYPO3 es visible qué suscriptores están activos y cuáles se han marcado como inactivos.

Segundo escenario: sincronización de plantillas. La redacción gestiona contenidos de newsletter en TYPO3, y la extensión transfiere elementos de contenido (teasers, imágenes, enlaces) a plantillas de Mailchimp. Así se elimina el mantenimiento doble: el teaser en la web y el teaser en la newsletter provienen del mismo registro de datos.

Tercer escenario: reporting de campañas en el backend TYPO3. Responsables de marketing que no tienen acceso directo al dashboard de Mailchimp ven tasas de apertura, tasas de clic y tasas de rebote directamente en el backend de TYPO3. Esto es relevante para empresas con gestión estricta de permisos donde solo personas seleccionadas tienen acceso a Mailchimp.

## La arquitectura técnica utiliza la API v3 de Mailchimp con sincronización basada en Scheduler

La extensión se comunica a través de la Mailchimp Marketing API v3. La autenticación se realiza mediante una API Key configurada en el Extension Manager de TYPO3. La sincronización funciona mediante tareas Scheduler de TYPO3 en intervalos configurables.

La sincronización de suscriptores trabaja en dos direcciones: TYPO3 a Mailchimp transfiere nuevas suscripciones y cambios de perfil. Mailchimp a TYPO3 importa datos de engagement, bajas y estado de rebote. La lógica de sincronización usa Mailchimp Member IDs (hash MD5 de la dirección de correo) como clave única para la conciliación.

La sincronización de plantillas renderiza elementos de contenido TYPO3 via plantillas Fluid en formato HTML compatible con email. La plantilla se transfiere por API a Mailchimp y queda disponible como Campaign Template. La extensión se encarga de la conversión de clases CSS a estilos inline, imprescindible para la compatibilidad con clientes de correo.

Los datos de campañas se obtienen por GET request de la API de Mailchimp y se almacenan en una tabla de la base de datos TYPO3. El módulo backend muestra los datos como dashboard con KPIs básicos: destinatarios, tasa de apertura, tasa de clic, bajas por campaña.

## Los problemas habituales son conflictos de sincronización, rate limits de la API y diferencias en el renderizado de plantillas

Problema uno: conflictos de sincronización con cambios simultáneos. Si un suscriptor se da de baja via Mailchimp y al mismo tiempo un editor modifica su perfil en TYPO3, surge un conflicto. La solución: definir una fuente de datos maestra clara. En la práctica, Mailchimp es la fuente principal para datos de engagement y bajas, TYPO3 para datos maestros y nuevas suscripciones.

Problema dos: rate limits de la API. La API de Mailchimp permite un máximo de 10 conexiones simultáneas y tiene límites de throughput que aplican en sincronizaciones grandes. Quien sincronice 50.000 suscriptores debe dividir la sincronización en lotes (recomendado: 500 registros por request) e implementar lógica de backoff.

Problema tres: diferencias de renderizado entre web y email. Un elemento de contenido que se ve correcto en la web puede renderizarse diferente en Outlook o Gmail. Especialmente layouts flexbox, webfonts e imágenes SVG no funcionan en emails. La solución: plantillas de email separadas con layout basado en tablas y fuentes del sistema.

Un cuarto problema afecta a la higiene de listas. Mailchimp cobra por tamaño de audiencia, y si la sincronización TYPO3 no depura suscriptores inactivos, la lista crece con direcciones que nunca abren o ya no son válidas. La extensión debe configurarse para que los estados de rebote y eventos de baja de Mailchimp se repliquen de vuelta a TYPO3.

## TYPO3 v12 está soportado, para v13 se recomienda una integración directa con la API

La extensión mailchimp soporta TYPO3 v11 y v12. Al actualizar hay que adaptar especialmente las configuraciones de Scheduler Tasks, ya que la API del Scheduler cambió en TYPO3 v12. Para TYPO3 v13 aún no hay release oficial. Dado que la API v3 de Mailchimp es estable y está bien documentada, Gosign recomienda para proyectos v13 una integración directa con la API sin dependencia de extensión. Una clase Service personalizada en un paquete TYPO3 propio que llame directamente a la API de Mailchimp tiene menor mantenimiento que una extensión de la comunidad.

Las empresas que quieran permanecer a largo plazo con Mailchimp deberían además evaluar la función Webhook de Mailchimp: en lugar de consultar datos periódicamente, Mailchimp envía eventos (suscripción, baja, rebote) activamente a un endpoint TYPO3. Esto reduce la latencia de minutos a segundos y elimina la carga de consultas API periódicas.

--- mailingwork TYPO3 - Newsletter | Gosign ---
> mailingwork es un sistema alemán de email marketing. La integración con TYPO3 sincroniza suscriptores, Double-Opt-In y segmentación. Servidores en Alemania ...

## mailingwork es la alternativa nativa para el RGPD a Mailchimp en proyectos TYPO3

Las empresas que quieren enviar un newsletter profesional sin transferir datos a Estados Unidos suelen acabar eligiendo un proveedor europeo con sede en Alemania. mailingwork es una de las plataformas de email marketing consolidadas con servidores en Alemania, razón social alemana y un equipo de soporte capaz de responder a cuestiones del RGPD en alemán y en inglés. La extensión de TYPO3 sincroniza listas de suscriptores, gestiona el Double-Opt-In y transfiere datos de segmentación entre el CMS y el sistema de newsletter. Para proyectos TYPO3 que necesitan una solución de newsletter jurídicamente sencilla, la combinación de mailingwork y TYPO3 es una de las opciones con menor carga de mantenimiento en el mercado europeo.

La comparación con Mailchimp muestra la diferencia: no se necesita un contrato de encargo de tratamiento con una empresa estadounidense, no hay que documentar mecanismos de transferencia internacional y no hay riesgo si cambian los acuerdos transatlánticos sobre protección de datos. La contrapartida: mailingwork tiene menos funciones que Mailchimp y carece de un ecosistema comparable de integraciones de terceros. Quien necesite marketing automation avanzado (triggers de comportamiento, lead scoring, customer journey mapping) se topará antes con los límites de mailingwork que con los de Mailchimp o HubSpot.

## Los escenarios típicos son newsletters corporativos, comunicación con socios y lead nurturing

El escenario estándar es el newsletter corporativo mensual para 5.000 o 50.000 destinatarios. La redacción mantiene los contenidos en TYPO3, compone el newsletter en mailingwork y lo envía a listas segmentadas. La extensión TYPO3 asegura que las nuevas altas desde la web lleguen automáticamente a mailingwork y que las bajas se sincronicen en ambas direcciones.

Segundo escenario: comunicación con socios en asociaciones profesionales. Un colegio profesional con 10.000 miembros envía circulares, invitaciones y memorias anuales. Los datos de los socios residen en TYPO3 (en fe_users o en una tabla personalizada) y mailingwork se encarga del envío. La segmentación por tipo de membresía, región o grupo especializado se controla mediante etiquetas que la extensión genera a partir de categorías TYPO3.

Tercer escenario: lead nurturing para empresas B2B. Un fabricante de maquinaria recopila leads a través de descargas de whitepapers y formularios de contacto en su web TYPO3. La extensión transfiere los leads con información de origen (qué formulario, qué página) a mailingwork, que inicia una secuencia automatizada: correo de bienvenida al día siguiente, caso de estudio a los 7 días, invitación a propuesta a los 14 días.

## La arquitectura técnica conecta formularios TYPO3 con la API REST de mailingwork

La extensión utiliza la API REST de mailingwork para el intercambio de datos. La configuración en el gestor de extensiones TYPO3 incluye el endpoint API, la clave API y el mapeo entre campos TYPO3 y campos de contacto de mailingwork. La sincronización se ejecuta mediante tareas programadas del Scheduler en intervalos configurables.

La importación de suscriptores sigue un flujo claro: un visitante rellena un formulario de alta en la web. TYPO3 guarda los datos localmente y los transfiere vía llamada API a mailingwork. mailingwork envía el correo Double-Opt-In. Solo tras la confirmación, el suscriptor pasa a la lista activa. La extensión registra cada paso en una tabla de log, algo relevante para auditorías del RGPD que la AEPD pueda requerir.

La segmentación funciona mediante etiquetas y campos personalizados. La extensión puede traspasar automáticamente las categorías TYPO3 (sys_categories) como etiquetas a mailingwork. Así se pueden utilizar segmentos específicos de la web (por ejemplo, "Interesado en el producto X") directamente para el envío del newsletter.

Las plantillas en mailingwork se mantienen de forma independiente de TYPO3. Quien quiera traspasar contenidos de TYPO3 automáticamente a plantillas de newsletter deberá resolverlo mediante la API de mailingwork y código propio, porque la extensión estándar no cubre esa función.

## Los problemas frecuentes tienen que ver con el mapeo de campos, los tiempos del Double-Opt-In y la gestión de errores

Primer problema: mapeo de campos incorrecto. Los campos de los formularios TYPO3 rara vez coinciden 1:1 con los campos de contacto en mailingwork. Un formulario usa "Empresa" y mailingwork espera "company". Sin un mapeo correcto, los datos acaban en campos incorrectos o se pierden. La solución: antes de la integración, elaborar un documento de mapeo que asigne cada campo TYPO3 al campo correspondiente en mailingwork y registrarlo en la configuración de la extensión.

Segundo problema: tiempos del Double-Opt-In. Entre el alta en la web y el clic en el enlace de confirmación suelen pasar horas o días. Si el job de sincronización se ejecuta mientras tanto y reporta al suscriptor aún no confirmado como "activo" en TYPO3, aparecen inconsistencias. La solución: cambiar el estado del suscriptor en TYPO3 a "activo" solo cuando mailingwork devuelva el estado "confirmed".

Tercer problema: gestión de errores ante caídas de la API. Si la API de mailingwork no está disponible, la extensión debe encolar el alta y reintentarla en la siguiente ejecución de sincronización. Sin esa lógica de reintentos, las altas se pierden. La extensión ofrece una función de cola que almacena las llamadas API fallidas y las repite de forma automática.

Un cuarto problema que aparece en instalaciones mayores: la granularidad del reporting. mailingwork entrega estadísticas de campaña a nivel de destinatario, pero la extensión TYPO3 no refleja todas las métricas en el backend. Para análisis detallados (mapas de calor de clics, horarios de apertura, distribución por dispositivo) hay que pasar al dashboard de mailingwork. Gosign recomienda usar el módulo backend de TYPO3 para vistas generales y trabajar directamente en mailingwork para análisis profundos.

## mailingwork mantiene activamente la extensión TYPO3, v12 está soportada

mailingwork, como proveedor comercial, tiene un interés empresarial en mantener actualizada la integración con TYPO3, porque el mercado TYPO3 es un canal de venta relevante. La extensión actual soporta TYPO3 v11 y v12. Para v13 se espera compatibilidad, aunque aún no está confirmada oficialmente. En una actualización de v10 a v12, los cambios afectan sobre todo al registro de tareas del Scheduler y a la configuración de la extensión, que debería pasarse de los ajustes del Extension Manager a la configuración de SiteSet. La sincronización de suscriptores y la comunicación con la API se mantienen estables.

--- maps2 TYPO3 - Extensión de mapas | Gosign ---
> Extensión de mapas para TYPO3: Google Maps u OpenStreetMap. Múltiples marcadores, agrupación, vistas de ruta.

## Por qué maps2 se ha convertido en la solución estándar para mapas en TYPO3

Una de cada dos webs corporativas necesita una visualización de mapas - para sedes, sucursales, lugares de eventos o zonas de reparto. En TYPO3, maps2 se ha establecido como la extensión de mapas más extendida porque soporta tres proveedores simultáneamente: Google Maps, OpenStreetMap y Mapbox. Eso significa libertad de elección real. Quien quiera evitar Google Maps por razones de privacidad cambia a OpenStreetMap sin necesidad de sustituir la extensión.

maps2 va mucho más allá de una simple incrustación de mapas. La extensión genera marcadores directamente desde registros TYPO3, soporta clustering para grandes cantidades de marcadores y ofrece funciones de routing.

## Escenarios de uso habituales

**Buscador de sucursales para empresas con 10 a 500 sedes.** Una empresa minorista quiere ofrecer un buscador de ubicaciones interactivo en su web. Cada sucursal está almacenada como registro tt_address o record propio en TYPO3. maps2 lee las direcciones, las geocodifica (en combinación con la extensión geocoordinates) y las muestra como marcadores en el mapa. Al hacer clic en un marcador se abre un popup con dirección, horarios y datos de contacto. Con más de 50 marcadores, maps2 activa clustering automático.

**Webs inmobiliarias con mapas de objetos.** Webs de agencias inmobiliarias basadas en TYPO3 usan maps2 junto con la extensión OpenImmo. Cada inmueble importado se muestra automáticamente en el mapa.

**Páginas de eventos y actividades.** Instituciones culturales, ferias o ayuntamientos muestran los lugares de celebración en un mapa. maps2 se vincula con cualquier extensión Extbase que contenga datos de dirección.

## Arquitectura técnica

maps2 está construida como extensión Extbase y usa el sistema de plugins TYPO3 para la salida frontend. La decisión arquitectónica central es la abstracción de proveedores: la extensión define una interfaz unificada para el renderizado de mapas implementada por tres proveedores. Google Maps Provider (API JavaScript v3, requiere API key, aprox. 7 USD por 1.000 llamadas tras la cuota gratuita), OpenStreetMap Provider (Leaflet.js, sin costes API, sin registro) y Mapbox Provider (opción premium con estilos propios).

La extensión almacena configuraciones de mapa en tablas de base de datos propias. Los marcadores se generan vía relación con cualquier registro TYPO3 - maps2 no está limitada a un tipo de registro específico.

## Problemas frecuentes y soluciones

**El mapa no se muestra, solo un área gris.** Con Google Maps, en el 90 % de los casos el problema es el API key. O falta, la facturación no está activada (Google exige desde 2018 una tarjeta de crédito vinculada), o los dominios permitidos en el API key no coinciden con la web. Solución: verificar en la Google Cloud Console que Maps JavaScript API esté activada y el key esté habilitado para el dominio correcto.

**Los marcadores aparecen en posición incorrecta.** La causa suele ser una geocodificación defectuosa o ausente. Si las direcciones no tienen coordenadas, maps2 intenta resolverlas vía el servicio de geocodificación configurado. Con direcciones imprecisas (por ejemplo, solo código postal sin calle) los marcadores aterrizan en el centro de la ciudad. Solución: corregir coordenadas mediante un batch de geocodificación y almacenarlas como valores fijos.

**Problemas de rendimiento con más de 200 marcadores.** La librería JavaScript renderiza cada marcador individualmente en el DOM. A partir de 200 marcadores se nota en dispositivos móviles. Solución: activar clustering y, si es necesario, implementar filtrado en servidor para cargar solo marcadores del área visible del mapa.

## Migración y compatibilidad de versiones

maps2 se mantiene activamente por Stefan Froemken y está disponible para TYPO3 v11 y v12 LTS. La extensión tiene una API estable y apenas breaking changes entre versiones major.

Al cambiar de Google Maps a OpenStreetMap (frecuente por motivos RGPD), solo hay que cambiar la configuración del proveedor en maps2. Plantillas y datos de marcadores permanecen idénticos. La motivación RGPD: Google Maps transmite datos personales (dirección IP, huella del navegador) a servidores de Google en EE.UU. Con OpenStreetMap los datos permanecen en Europa, conforme a los criterios de la AEPD, y un banner de consentimiento para servicios de mapas se vuelve innecesario. Para empresas que integran mapas en cada página, esto mejora también la experiencia de usuario porque el mapa es visible inmediatamente sin que el visitante tenga que aceptar primero el banner de cookies.

--- Marquee TYPO3 - Texto en movimiento/Ticker | Gosign ---
> Texto en movimiento / extensión ticker para TYPO3. Tickers de noticias, cotizaciones bursátiles, banners de anuncios.

## Los textos en movimiento y tickers no necesitan extensión, CSS lo resuelve en 20 líneas

El elemento marquee es un clásico de los primeros años de la web: texto deslizante que se mueve de derecha a izquierda sobre la página. La etiqueta HTML `<marquee>` lleva años en desuso, pero el efecto sigue siendo demandado. Tickers de noticias, banners de aviso ("trabajos de mantenimiento el sábado") y anuncios de eventos usan textos deslizantes como mecanismo de llamada de atención. La extensión marquee para TYPO3 ofrece un elemento de contenido que genera ese efecto mediante JavaScript. Gosign recomienda en su lugar una solución exclusivamente basada en CSS, sin extensión, sin JavaScript y sin obligación de actualización.

La diferencia es medible: la extensión carga JavaScript, registra un elemento de contenido en el TCA y requiere plantillas Fluid. La alternativa CSS es una sola animación de CSS (20 líneas) sobre un elemento de contenido de texto normal. Rendimiento, accesibilidad y coste de mantenimiento hablan claramente a favor del enfoque CSS.

## Los escenarios típicos son avisos de mantenimiento, banners promocionales y resultados deportivos

El escenario más habitual es el banner de aviso en webs corporativas. "Nuestras oficinas estarán cerradas del 24 de diciembre al 2 de enero" o "Inscríbete ya: webinar el 15 de marzo". El texto deslizante atrae la atención sin ser un popup. Los redactores mantienen el texto en el backend de TYPO3 y activan o desactivan el banner mediante fechas de inicio y fin.

Segundo escenario: tickers de noticias en portales de información e intranets corporativas. Los últimos tres o cinco titulares se desplazan como ticker por el borde superior de la página. Cada titular es un enlace a la noticia completa. La velocidad se ajusta para que el texto siga siendo legible (recomendado: 30 a 50 píxeles por segundo).

Tercer escenario: resultados deportivos en webs de clubes. En día de partido, un ticker muestra los resultados actualizados de todos los equipos. Los datos proceden de una tabla TYPO3 o de un feed externo y se presentan como texto deslizante. La combinación de texto en movimiento y actualización automática (vía AJAX cada 60 segundos) convierte el ticker en un canal de información en tiempo real sin la complejidad de una extensión de liveticker completa.

## La arquitectura técnica de la extensión es un elemento de contenido gobernado por JavaScript

La extensión marquee registra un elemento de contenido en el TCA de TYPO3 con campos para texto, velocidad, dirección y repetición. La plantilla Fluid renderiza un contenedor y un fichero JavaScript inicializa la animación. La configuración (velocidad, pausa al pasar el ratón, repetición infinita) se pasa al JavaScript mediante atributos data en el contenedor.

La alternativa CSS funciona así: un elemento de contenido de texto normal recibe una clase CSS (por ejemplo, "marquee") y la animación @keyframes scroll desplaza el texto de derecha a izquierda. La animación es infinita, se pausa al pasar el ratón (via :hover) y respeta el ajuste prefers-reduced-motion del sistema operativo, algo relevante para accesibilidad. El código completo:

```css
.marquee { overflow: hidden; white-space: nowrap; }
.marquee span { display: inline-block; animation: scroll 20s linear infinite; }
.marquee:hover span { animation-play-state: paused; }
@media (prefers-reduced-motion: reduce) { .marquee span { animation: none; } }
@keyframes scroll { from { transform: translateX(100%); } to { transform: translateX(-100%); } }
```

## Los problemas frecuentes son accesibilidad, visualización móvil y relevancia SEO

Primer problema: accesibilidad. Los contenidos en movimiento son problemáticos para personas con limitaciones cognitivas o epilepsia. La WCAG 2.1 exige que las animaciones se puedan pausar, detener u ocultar. La extensión ofrece una función de pausa al pasar el ratón, pero no un botón de parada. La solución CSS respeta automáticamente el ajuste prefers-reduced-motion, algo que la extensión no hace.

Segundo problema: visualización móvil. En smartphones, el espacio disponible para texto deslizante es mínimo. Un ticker legible en el escritorio pasa tan rápido en el móvil que nadie puede seguirlo. La solución: en dispositivos móviles sustituir el ticker por un banner estático que muestre el mensaje más importante, sin animación.

Tercer problema: relevancia SEO. Los motores de búsqueda indexan el texto deslizante, pero las señales de UX (tiempo breve en el ticker, sin clics) pueden afectar negativamente a la calidad de la página. Los contenidos del ticker deberían estar siempre disponibles también como contenido normal, no solo dentro del ticker.

Un cuarto problema: cumplimiento de accesibilidad en entidades públicas. La legislación española sobre accesibilidad web (Real Decreto 1112/2018, que transpone la Directiva UE 2016/2102) y la norma EN 301 549 exigen que las animaciones se puedan pausar y detener. Un marquee sin botón de parada o mecanismo de pausa infringe WCAG 2.2.2 (pause, stop, hide). La solución CSS con prefers-reduced-motion y pausa al pasar el ratón cumple parcialmente este requisito; un botón de pausa explícito sería necesario para cumplimiento total.

## La extensión es superflua para las versiones actuales de TYPO3

La extensión marquee no tiene soporte oficial para TYPO3 v12 o v13. Dado que la alternativa CSS se implementa en 15 minutos y no crea dependencia de extensión, Gosign recomienda el cambio en cada migración. El redactor utiliza un elemento de contenido de texto normal con una clase CSS especial definida en el site package. Es libre de mantenimiento, eficiente y accesible.

Para proyectos que quieran rotar varios mensajes en el ticker, basta con una animación CSS ampliada que encadene varios bloques de texto. Como alternativa, un JavaScript mínimo (menos de 20 líneas) puede cargar los textos desde una fuente JSON y controlar la animación. Ambas opciones son arquitectónicamente más limpias que una extensión que, para un simple efecto, arrastra un campo TCA completo, una plantilla Fluid y un fichero JavaScript. En Gosign aplicamos el enfoque CSS en todos los proyectos que necesitan un ticker o texto en movimiento.

--- Mask TYPO3 - Elementos de contenido personalizados | Gosign ---
> Mask es la herramienta estándar para Custom Content Elements en TYPO3. Máscaras de backend sin programación, los editores crean sus propios tipos de contenido.

## Los editores necesitan elementos de contenido propios, no el siguiente parche con campos de texto genéricos

Toda web TYPO3 llega al punto en que los elementos de contenido estándar se quedan cortos. Un carrusel de equipo, una tabla de precios con toggles, un teaser de producto con imagen, texto y botón CTA - esas necesidades acaban como HTML suelto en el RTE o dentro de un contenedor Flexform saturado. Mask resuelve este problema de raíz: los editores obtienen formularios de backend con exactamente los campos que necesitan. Sin clases PHP, sin TCA manual, sin ext_tables.sql.

Mask es desde 2016 el framework más utilizado para Custom Content Elements en TYPO3. Más de 1.500 instalaciones activas (datos de Packagist, abril 2026) y su inclusión en la documentación oficial de TYPO3 como método recomendado confirman su estatus como estándar de facto.

## Escenarios de uso habituales

**Webs corporativas con estructuras de página complejas.** Equipos de marketing necesitan entre 15 y 30 elementos de contenido diferentes: banners hero, testimonios, acordeones, contenido con pestañas, descargas con vista previa, tarjetas de contacto. Mask modela cada uno como formulario de backend propio. Los editores solo ven los campos relevantes para cada elemento, sin confusión por opciones irrelevantes.

**Proyectos multilingües con estructura consistente.** Los elementos Mask soportan completamente los mecanismos de traducción de TYPO3. Los campos se configuran como l10n_mode exclude (no traducible) o prefixLangTitle (traducible con indicación). En webs con 5 o más idiomas, esto ahorra tiempo de redacción porque la estructura permanece idéntica y solo se traduce el contenido.

**Proyectos de relanzamiento con datos existentes.** Quien migra desde un sistema anterior (WordPress, TYPO3 con Gridelements o TemplaVoilà) necesita estructuras de contenido limpias. Los elementos Mask se exportan con mask_export como extensión independiente. Las definiciones de contenido pasan a ser versionables y desplegables vía CI/CD.

## Arquitectura técnica

Mask almacena la configuración de todos los elementos de contenido en un único archivo JSON (`mask.json` o `config/mask.json` desde Mask 8). Este archivo describe campos, tipos, paletas y la asignación a plantillas Fluid. Al activar o actualizar, Mask genera automáticamente las configuraciones TCA y los campos de base de datos necesarios.

Los tipos de campo cubren el estándar TYPO3 completamente: String, Integer, Float, RichText, Date, DateTime, File (FAL), Inline (IRRE para estructuras anidadas), Select, Checkbox, Radio, Link, Slug, Color Picker, Tab, Palette. Desde Mask 8 se añaden campos nativos JSON y una API mejorada.

Las plantillas Fluid se ubican por defecto en `fileadmin/templates/mask/` o en una ruta configurable. Cada elemento de contenido tiene su propia plantilla, opcionalmente con Partials y Layouts. Mask registra los elementos en el New Content Element Wizard, incluyendo icono y descripción.

Las dependencias son mínimas: Mask solo requiere el TYPO3 Core (v11, v12 y v13 reciben soporte activo). No necesita otras extensiones. Para el flujo de exportación se añade mask_export como complemento opcional.

## Problemas frecuentes y soluciones

**Cambios de campo en sistemas productivos.** Si un campo Mask se modifica en staging (tipo, nombre) pero la base de datos en producción no se actualiza, aparecen errores. Solución: usar mask_export para que los cambios de configuración fluyan por Git y pipelines de despliegue. Alternativa: Database Compare en el Install Tool tras cada deployment.

**Rendimiento con muchos elementos de contenido.** Webs con más de 40 elementos Mask generan una configuración TCA considerable. TYPO3 la carga en cada llamada al backend. Solución: agrupar elementos con criterio, desactivar los que no se usen, mantener activo el caché del backend. A partir de Mask 8 la generación de TCA es significativamente más eficiente que en versiones anteriores.

**Elementos anidados (IRRE) y ordenación.** Las relaciones inline (por ejemplo, slides dentro de un elemento slider) pierden a veces la ordenación al copiar y pegar. Solución: definir explícitamente un campo de ordenación y asegurar en la plantilla Fluid el uso de `<f:for>` con `sortBy`. En Mask 8.x este comportamiento es más estable que en 7.x.

## Migración y compatibilidad de versiones

Mask es compatible con TYPO3 v12 y v13 de forma activa. La versión estable actual (Mask 8.x) funciona en ambas versiones LTS. TYPO3 v11 está cubierto por Mask 7.x, que ya no recibe nuevas funcionalidades.

Para proyectos que aún usan TemplaVoilà o DCE, Mask ofrece una ruta de migración clara. Los elementos DCE se transfieren manualmente a Mask: recrear campos en la GUI de Mask, adaptar plantillas Fluid, migrar datos mediante script SQL. Gosign ha realizado este proceso en proyectos con más de 20 elementos DCE, estimando el esfuerzo entre 2 y 5 días según la complejidad.

A partir de TYPO3 v13 está disponible además la Content Block API nativa. Para proyectos Mask existentes no hay urgencia: Mask y Content Blocks coexisten sin problemas. Proyectos nuevos en TYPO3 v13 puro pueden evaluar si el enfoque nativo es suficiente o si Mask aporta ventajas gracias a su GUI y flujo de exportación. Gosign asesora caso por caso sobre qué enfoque minimiza el mantenimiento a largo plazo.

Un aspecto frecuentemente subestimado es la documentación. Los elementos Mask son autoexplicativos para desarrolladores (campos, tipos, plantillas), pero los editores necesitan orientación: qué campos son obligatorios, qué tamaño de imagen es óptimo, qué ocurre si el campo de descripción queda vacío. Mask soporta desde la versión 7 textos descriptivos por campo que aparecen como tooltip en el backend. Gosign crea además un manual de redacción interno por proyecto donde cada elemento Mask se documenta con captura de pantalla, descripción de campos y buenas prácticas. El esfuerzo es de media hora por elemento, pero ahorra consultas durante la explotación.

Para la configuración inicial de un proyecto Mask con 15 a 20 elementos de contenido, Gosign estima de 3 a 5 días de desarrollo, incluyendo plantillas Fluid, vista previa del backend y configuración de mask_export. Elementos individuales nuevos durante la explotación se implementan en 1 a 4 horas, según la complejidad del anidamiento y el diseño de la plantilla.

--- mask_export TYPO3 - Despliegue de Mask | Gosign ---
> Extensión que exporta configuraciones de elementos de contenido Mask como extensiones TYPO3 independientes. Para despliegue en múltiples entornos.

## Sin mask_export los elementos Mask no son versionables y cada despliegue es un riesgo

Mask es el estándar para Custom Content Elements en TYPO3. Pero Mask almacena su configuración en un archivo JSON y genera campos de base de datos en tiempo de ejecución. En un proceso de desarrollo profesional con múltiples entornos (local, staging, producción) esto genera un problema: cómo llevar los nuevos elementos de contenido del equipo de desarrollo al servidor productivo. Recrearlos manualmente en el backend. Copiar el mask.json por FTP y ejecutar Database Compare. Ambas opciones son propensas a errores y no reproducibles.

mask_export resuelve este problema. La extensión exporta todas las definiciones Mask como extensión TYPO3 independiente con su propio ext_tables.sql, configuraciones TCA y plantillas Fluid. Esta extensión se instala vía Composer, se versiona en Git y se despliega por CI/CD, exactamente como cualquier otra extensión TYPO3. Así Mask se convierte en una solución enterprise.

## Escenarios de uso habituales

**Agencias con pipeline CI/CD.** Agencias que despliegan proyectos TYPO3 mediante GitLab CI, GitHub Actions o Deployer necesitan artefactos versionables. mask_export genera una extensión que se instala con `composer require`. Cada cambio en un elemento de contenido genera un nuevo commit que pasa por la pipeline: lint, tests, despliegue a staging, despliegue a producción. Sin intervención manual en el backend.

**Proyectos multi-site con elementos compartidos.** Corporaciones con 5 a 20 instancias TYPO3 (filiales, marcas, subsidiarias) quieren elementos de contenido uniformes en todos los sitios. mask_export genera una extensión central que se integra en todas las instancias. Los cambios se hacen una vez y se distribuyen a todos los sitios. Sin mask_export, los elementos Mask tendrían que recrearse manualmente en cada instancia.

**Traspaso entre desarrollo y redacción.** Los desarrolladores definen elementos de contenido en el sistema local, los exportan con mask_export y hacen commit del resultado. Los editores trabajan en staging o producción y usan los elementos sin necesitar la GUI de Mask. La propia extensión Mask puede incluso desinstalarse en sistemas productivos donde solo se necesita la extensión exportada.

## Arquitectura técnica

mask_export lee el mask.json (o config/mask.json desde Mask 8) y genera una extensión TYPO3 completa. La estructura generada contiene: ext_emconf.php (metadatos), ext_tables.sql (definiciones de base de datos para todos los campos Mask), Configuration/TCA/Overrides/tt_content.php (configuración TCA), Resources/Private/Templates/ (plantillas Fluid, copiadas desde la ruta configurada de plantillas Mask) y opcionalmente TypoScript setup para el renderizado en frontend.

El proceso de exportación se ejecuta como comando TYPO3 CLI: `php typo3/sysext/core/bin/typo3 mask:export`. El resultado es un directorio que se integra como paquete Composer o como extensión local en typo3conf/ext/. La extensión Mask ya no se necesita tras la exportación, siempre que no se creen o modifiquen elementos.

Importante: mask_export exporta solo la definición (campos, plantillas, TCA), no los contenidos (los textos, imágenes reales en tt_content). Los datos permanecen en la base de datos y se migran independientemente.

## Problemas frecuentes y soluciones

**Olvido de exportar tras un cambio.** Un desarrollador modifica un campo Mask en el sistema local pero solo hace commit del mask.json, no de la nueva exportación. En staging falta entonces la configuración TCA. Solución: integrar el comando mask_export en un hook Git (pre-commit) o en la pipeline CI. Gosign usa una verificación en la pipeline de despliegue que compara si mask.json y la última exportación están sincronizados.

**Las plantillas Fluid no se incluyen en la exportación.** mask_export copia por defecto las plantillas de la ruta configurada. Si las plantillas están fuera de esa ruta (por ejemplo, en un paquete de tema propio), no se capturan. Solución: colocar todas las plantillas Mask en un directorio unificado y referenciarlo en la configuración de Mask.

**Conflictos al usar Mask y la extensión exportada simultáneamente.** Si en el sistema productivo están instalados tanto Mask como la extensión exportada, pueden producirse registros TCA duplicados. Solución: en sistemas donde los editores no crean elementos nuevos, instalar solo la extensión exportada y desinstalar Mask. En sistemas de desarrollo, ambos funcionan en paralelo; la exportación sobrescribe la versión anterior.

## Migración y compatibilidad de versiones

mask_export sigue el ciclo de releases de Mask: cuando Mask soporta una nueva versión TYPO3, mask_export se actualiza oportunamente. Actualmente son compatibles TYPO3 v11, v12 y v13. La extensión exportada es compatible con la misma versión TYPO3 que la versión de Mask desde la que se generó.

Para proyectos que quieran migrar a la Content Block API nativa en TYPO3 v13, mask_export puede servir como paso intermedio: primero exportar los elementos Mask (estructura limpia basada en archivos), luego traducir las configuraciones TCA exportadas a definiciones Content Block. El esfuerzo por elemento es reducido (30 a 60 minutos) cuando la extensión exportada sirve de referencia.

Una ventaja frecuentemente pasada por alto de mask_export es la testabilidad. Cuando los elementos de contenido existen como extensión independiente, se pueden escribir tests automatizados: verificar la configuración TCA (están todos los campos correctamente definidos), probar el renderizado de plantillas (produce la plantilla Fluid HTML válido) y validar el esquema de base de datos (coinciden los tipos de columna). En una pipeline CI, estos tests detectan errores antes de que lleguen a staging o producción.

--- Mask Twig TYPO3 - Plantillas | Gosign ---
> Plantillas Twig o Nunjucks en lugar de Fluid para elementos de contenido Mask. Para desarrolladores frontend que prefieren la sintaxis Twig o quieran.

## Por qué los desarrolladores frontend prefieren Twig a Fluid y cómo Mask lo hace posible

TYPO3 usa con Fluid un motor de plantillas único en el mundo PHP. Eso es al mismo tiempo su fortaleza y su mayor problema: los desarrolladores frontend que vienen del entorno Symfony, Laravel o Node.js conocen Twig o Nunjucks. Fluid no lo conocen. El mask_twig_nunjucks_connector cierra esta brecha permitiendo renderizar elementos de contenido Mask con plantillas Twig o Nunjucks en lugar de plantillas Fluid.

Para agencias cuyo equipo frontend trabaja con Twig y no quiere aprender un nuevo lenguaje de plantillas para cada proyecto TYPO3, el conector es la solución pragmática. Partials Twig existentes de proyectos Symfony o componentes Nunjucks de Pattern Libraries se reutilizan directamente.

## Escenarios de uso habituales

**Agencias con backend Symfony y frontend TYPO3.** Una agencia desarrolla sus aplicaciones web en Symfony y usa TYPO3 solo para gestión de contenido. El equipo frontend ha construido una amplia librería de componentes Twig. En lugar de reescribir todos los componentes en Fluid para TYPO3, el conector integra las plantillas Twig existentes directamente en elementos de contenido Mask.

**Integración de Pattern Library con Nunjucks.** Un equipo de diseño mantiene una Pattern Library (por ejemplo, basada en Fractal o Storybook) que usa Nunjucks como lenguaje de plantillas. El conector permite usar las mismas plantillas Nunjucks tanto en la Pattern Library como en TYPO3.

**Onboarding de desarrolladores frontend en proyectos TYPO3.** Un nuevo desarrollador frontend se incorpora a un proyecto TYPO3. En lugar de aprender primero Fluid (sintaxis, namespaces, concepto de ViewHelper), escribe plantillas Twig que ya domina. La curva de aprendizaje se reduce de 2-3 días a pocas horas.

## Arquitectura técnica

El mask_twig_nunjucks_connector funciona como puente de renderizado entre la extensión Mask y un motor de plantillas alternativo. Mask define Custom Content Elements con campos backend. Por defecto, Mask renderiza estos elementos con plantillas Fluid. El conector sustituye este paso de renderizado.

La integración Twig usa la librería PHP `twig/twig` (la misma que usa Symfony). Las plantillas Twig se ubican en el sistema de archivos, típicamente bajo `Resources/Private/Twig/`. Los campos Mask están disponibles como variables de plantilla (`{{ data.header }}`, `{{ data.bodytext }}`). La integración Nunjucks puede renderizar plantillas en servidor vía un puente Node.js o entregar las plantillas como JavaScript en el cliente.

## Problemas frecuentes y soluciones

**La plantilla Twig no tiene acceso a datos específicos de TYPO3.** Fluid ViewHelpers como `f:uri.page`, `f:translate` o `f:cObject` no existen en Twig. Una plantilla Twig no puede acceder directamente al árbol de páginas TYPO3, traducciones u otros elementos de contenido. Solución: todos los datos necesarios deben proporcionarse vía variable mapping. El conector puede inyectar datos adicionales (idioma actual, URL de página, configuración global) en el contexto de la plantilla.

**El renderizado Nunjucks es lento.** El puente Node.js para renderizado Nunjucks en servidor inicia un proceso Node por cada petición. Eso no se nota con elementos individuales, pero con páginas con más de 10 elementos Mask los tiempos de renderizado se acumulan. Solución: usar un proceso Node.js worker persistente o cambiar a Twig, que renderiza nativamente en PHP.

**Una actualización de Mask rompe los nombres de variables de plantilla.** Si Mask renombra un campo o cambia un tipo de campo, las variables de plantilla cambian. Las plantillas Fluid muestran entonces espacios vacíos, las plantillas Twig lanzan un error. Solución: usar Twig en modo estricto (`strict_variables: true`) y testear plantillas contra las variables actualizadas tras cada actualización de Mask.

## Migración y compatibilidad de versiones

El mask_twig_nunjucks_connector es un proyecto de la comunidad con difusión limitada. La compatibilidad depende de la extensión Mask, que se mantiene activamente y soporta TYPO3 v11 y v12. El conector debe verificarse con cada actualización de Mask, ya que se conecta a procesos internos de renderizado.

Gosign recomienda el conector para proyectos donde el equipo frontend trabaja exclusivamente con Twig y trae una librería de componentes existente. Para proyectos TYPO3 puros sin requisitos de plantillas externas, Fluid sigue siendo la mejor opción por su soporte nativo y el acceso a toda la biblioteca de ViewHelpers de TYPO3. La ganancia de productividad por reutilización de Twig debe superar el coste de mantenimiento del conector.

--- mathguard TYPO3 - CAPTCHA matemático | Gosign ---
> Extensión CAPTCHA matemática para TYPO3. Problemas simples de matemáticas en lugar de reconocimiento de imágenes. Ligero, accesible, sin servicios externos.

## Los CAPTCHAs matemáticos son la protección anti-spam accesible que la mayoría de webs desconoce

El spam en formularios de contacto es un tema recurrente. La solución más popular es Google reCAPTCHA, pero envía datos de usuario a Google y complica el cumplimiento del RGPD. Los CAPTCHAs basados en imágenes ("marque todos los semáforos") frustran a los usuarios y son inaccesibles para lectores de pantalla. mathguard sigue otro camino: la extensión muestra una operación matemática simple ("¿Cuánto es 3 + 7?") en el formulario. Los humanos lo resuelven en segundos, mientras que los bots automatizados fallan en su mayoría. Sin JavaScript externo, sin cookies, sin transferencia de datos a terceros y totalmente compatible con lectores de pantalla.

Para administraciones públicas, universidades y empresas con exigencias de accesibilidad (Real Decreto 1112/2018, WCAG 2.1), mathguard es una de las pocas soluciones CAPTCHA que garantiza tanto protección anti-spam como accesibilidad. La reducción de spam se sitúa entre el 85 y el 95% del tráfico entrante de bots. En comparación: Google reCAPTCHA v3 alcanza valores similares, pero transfiere datos a servidores de Google en cada carga de página, incluso sin interacción con el formulario.

## Los escenarios típicos son formularios de contacto, comentarios y registros

El escenario estándar es el formulario de contacto en una web corporativa. Sin protección anti-spam, llegan diariamente entre 20 y 200 envíos de bots al buzón de la redacción. mathguard añade un campo de operación matemática entre el campo de email y el botón de envío. La operación se genera aleatoriamente en cada carga de página, de modo que los bots no pueden precalcular la solución.

Segundo escenario: funciones de comentarios en blogs y portales de noticias. Si los visitantes pueden dejar comentarios a los artículos, el spam es inevitable. mathguard protege el formulario de comentarios sin que los visitantes necesiten una cuenta de Google o una aplicación especial.

Tercer escenario: registros de usuarios. Cuando una web ofrece cuentas de frontend (por ejemplo, para un portal de clientes o un área de descargas protegida), mathguard protege el formulario de registro frente a la creación automatizada de cuentas. La operación matemática es el último obstáculo antes del envío, adicional al Double-Opt-In.

## La arquitectura técnica genera operaciones matemáticas en el servidor con validación por sesión

mathguard funciona íntegramente en el servidor. En cada carga de formulario, la extensión genera una operación matemática aleatoria (suma, resta o multiplicación con números de una cifra). La solución correcta se guarda en la sesión PHP, no en el código HTML. Eso es determinante: si la solución estuviera como campo oculto en el formulario, cualquier bot podría leerla.

La integración en formularios TYPO3 se realiza mediante un ViewHelper o un partial Fluid que se inserta en las plantillas de formulario existentes. Para powermail y el TYPO3 Form Framework existen ejemplos de configuración que permiten la integración en 10 a 15 minutos.

La operación se muestra como texto ("¿Cuánto es 5 + 3?"), no como imagen. Eso la hace automáticamente compatible con lectores de pantalla: el software de lectura puede leer la operación y el usuario introduce la solución en un campo de texto normal. No hay distorsiones visuales, ni problemas de contraste de color, ni limitaciones de tiempo.

Para mayor seguridad, mathguard se puede combinar con un campo honeypot: un campo de formulario invisible que los bots rellenan pero los usuarios reales ignoran. Como complemento se puede añadir una validación por marca temporal: si un formulario se rellena en menos de 3 segundos, es con alta probabilidad un bot. La combinación de CAPTCHA matemático, honeypot y comprobación de marca temporal alcanza una reducción de spam superior al 99%.

## Los problemas frecuentes son bots más inteligentes, pérdida de sesión y fricción UX

Primer problema: bots avanzados que resuelven operaciones matemáticas. Bots de parsing de texto sencillos pueden interpretar "¿Cuánto es 3 + 7?" e introducir la respuesta correcta "10". La solución: representar la operación como texto ligeramente ofuscado ("Tres más siete es igual a") o ampliar la operación con un contexto ("¿Cuántas patas tiene una silla menos una?"). mathguard en su configuración estándar utiliza operaciones numéricas, suficiente para el 85 al 95% de los bots.

Segundo problema: pérdida de sesión. Si la sesión PHP se pierde entre la carga del formulario y el envío (por ejemplo, por un load balancer sin session stickiness), la validación falla aunque el usuario haya introducido la respuesta correcta. La solución: configurar session stickiness en el load balancer o guardar los datos de sesión en la base de datos en lugar del sistema de archivos.

Tercer problema: fricción UX. Algunos visitantes perciben una operación matemática como paternalista ("¿Tengo que demostrar que sé sumar?"). La solución: colocar un mensaje amable sobre el campo ("Protección anti-spam: por favor, resuelve esta operación") e integrar la operación visualmente de forma discreta en el diseño del formulario.

## mathguard funciona con todas las versiones de TYPO3 porque la técnica es mínima

La extensión no tiene dependencias profundas con la API del core de TYPO3. La gestión de sesiones, el renderizado de formularios y la validación utilizan funciones estándar de PHP y TYPO3 que apenas cambian entre versiones. mathguard es compatible con TYPO3 v10, v11 y v12 y previsiblemente también funcionará en v13, con ajustes mínimos en el ViewHelper. Para proyectos que quieren prescindir de extensiones, la misma lógica se puede reconstruir en menos de una hora como validador personalizado en el TYPO3 Form Framework o como finisher de powermail. En sus propios proyectos, Gosign implementa una combinación de honeypot, validación por marca temporal y CAPTCHA matemático opcional como protección anti-spam en tres niveles, sin servicios externos y eficaz contra más del 99% de los ataques automatizados. La decisión de si el CAPTCHA matemático es visible o solo actúa como fallback invisible la tomamos proyecto a proyecto en función del volumen de spam esperado y de los requisitos de accesibilidad.

--- md_news_author TYPO3 - Autores de noticias | Gosign ---
> Extensión de autores para GeorgRinger/news. Perfiles de autores, archivos de autores y marcado Schema.org Person.

## md_news_author da rostro a los redactores y un schema a los buscadores

GeorgRinger/news es la extensión de facto estándar para sistemas de redacción en TYPO3, pero solo conoce un sencillo campo de texto para el autor. Para sitios de noticias con varios autores eso no basta: quien gestiona una revista seria necesita páginas de perfil de autor, biografías estructuradas y marcado Schema.org/Person para E-E-A-T. Esa es exactamente la brecha que cubre md_news_author de Mehrwert-Digital, y por eso la extensión acaba en el composer.json de casi cualquier proyecto de redacción TYPO3 de tamaño medio. Desde que Google endureció en 2022 las directrices E-E-A-T y valora los perfiles de autor como señal de ranking, la extensión ya no es solo una comodidad, sino un factor SEO medible para cualquier redacción con más de tres autores.

## Escenarios típicos: revistas digitales, editoriales especializadas y salas de prensa universitarias

Las editoriales especializadas son el público objetivo clásico. Una editorial jurídica con 40 autores quiere para cada autor una página de detalle propia con foto, biografía breve, áreas de especialidad, perfil de LinkedIn y una lista de todos sus artículos, por razones SEO y porque Google recompensa E-E-A-T. md_news_author entrega eso desde un único registro. Además, la extensión permite filtrar autores por áreas de especialidad, de modo que los redactores encuentran, al investigar un tema, directamente a los expertos adecuados.

Las salas de prensa universitarias utilizan la extensión para asignar los comunicados del gabinete de comunicación a los investigadores reales. La nota de prensa aparece bajo el nombre del catedrático correspondiente, enlaza a su página del instituto y se señala a Google mediante Schema Person. Para citaciones y Google Scholar eso no es solo estética, sino un factor de ranking. Hemos implementado md_news_author, por ejemplo, en un instituto de investigación médica con 18 grupos de investigación, donde cada nota de prensa se asigna al grupo participante y a sus miembros. La extensión conecta los contenidos de noticias con los perfiles de investigador y crea así una base estructurada para la reputación académica en la web.

Un tercer escenario son los blogs corporativos y los formatos de thought leadership, en los que miembros del consejo y directivos aparecen como autores. La extensión separa limpiamente entre FE User (login) y autor (perfil), de modo que las biografías pueden mantenerse también para autores invitados sin cuenta TYPO3. Para salas de prensa corporativas con setup de ghostwriter esa separación es decisiva: el redactor de comunicación escribe el texto pero lo publica bajo el nombre del directivo sin que este necesite un login en el backend.

## Arquitectura técnica: ampliación de GeorgRinger/news vía TCA overrides

md_news_author es un complemento puro de ext:news. No aporta una lógica de salida propia, sino que registra mediante TCA override el campo "authors" como relación con una nueva tabla tx_mdnewsauthor_domain_model_author. Cada autor es un registro independiente con nombre, apellidos, cargo, slug, biografía, imagen, LinkedIn, X, correo y notas internas. La relación es de tipo MM, de modo que un artículo puede tener varios autores y, a la inversa, un autor puede participar en tantos artículos como haga falta.

La integración en plantillas Fluid corre a través de ViewHelpers: {author.fullName}, {author.jobTitle}, {author.image} y {author.url}. Para vistas de lista y detalle la extensión entrega partials terminados que pueden sobrescribirse mediante el sistema de paquetes TypoScript. El slug se genera automáticamente a partir de nombre y apellidos y es editable. El routing para páginas de detalle de autor se realiza mediante un patrón Enhancer en la Site Config, que permite URLs como /autor/juan-perez/ sin estructura de páginas adicional.

El marcado Schema.org/Person se genera mediante un ViewHelper JSON-LD y puede incrustarse en el schema News Article. Así Google reconoce al autor, lo relaciona a través de varios artículos y lo incorpora al entorno del Knowledge Graph de la revista. La salida del ViewHelper es compatible con el Structured Data Testing Tool de Google y cubre los atributos Person más importantes: name, jobTitle, image, url, sameAs y worksFor.

## Problemas frecuentes: Storage Pages y conflictos de slug

El tropiezo clásico es la configuración de la Storage Page. md_news_author espera que los registros de autor estén en una carpeta de sistema explícita, indicada en el TypoScript del plugin News. Si falta la entrada, el plugin no muestra ningún autor y los editores se extrañan. En la configuración colocamos la carpeta de sistema bajo /Configuracion/Autores-Noticias y la referenciamos en el Flexform del plugin. En instalaciones multisitio la carpeta de sistema debe mantenerse por separado para cada site, de modo que los autores queden asignados a una marca concreta.

Un segundo error frecuente son las colisiones de slug con otras tablas. Cuando junto a md_news_author se utiliza también ext:sf_register o un modelo propio de personas, ambos comparten a menudo la misma estructura de URL. Recomendamos fijar conscientemente el prefijo de routing en /autor/ y registrar la generación de slug en la Site Config YAML. Alternativamente el routing enhancer puede configurarse por idioma, lo que es especialmente importante en instalaciones multilingües con distintos prefijos de ruta ("/author/" EN, "/autor/" ES).

En tercer lugar, las imágenes necesitan un tamaño definido. md_news_author entrega la referencia FAL, pero las variantes de cropping deben mantenerse en TSconfig bajo TCEFORM.tx_mdnewsauthor_domain_model_author.image. Sin eso, el cropping ViewHelper falla en la plantilla de detalle y muestra las imágenes originales sin procesar. Recomendamos definir al menos tres variantes de cropping (square, portrait, landscape) y entregarlas de forma responsiva en la plantilla Fluid.

## La migración a TYPO3 v12 exige actualización de Fluid

Para TYPO3 v11 y v12 md_news_author está disponible de forma estable. Al saltar a v12 las plantillas Fluid propias deben adaptarse al nuevo namespace ({namespace md=Mehrwert\\MdNewsAuthor\\ViewHelpers}) y al sistema de ViewHelpers revisado. Quien viene de una versión antigua 2.x debería además revisar los TCA overrides, porque algunos nombres de campo han cambiado. En particular el campo de biografía y los enlaces a redes sociales han recibido en versiones más recientes propiedades adicionales que las plantillas antiguas ignorarían.

En proyectos en curso Gosign migra md_news_author típicamente en el mismo paso que el upgrade del núcleo news y el marcado Schema.org. Así la página de artículo se mantiene consistente durante el cambio y el marcado Person se eleva directamente a la especificación Schema.org actual. En la misma pasada comprobamos si los perfiles de autor contienen una lista sameAs completa con cuentas de redes sociales verificadas, porque Google utiliza esa vinculación para el matching con el Knowledge Graph.

--- Mega-Menu TYPO3 - Navegación | Gosign ---
> Navegación desplegable multicolumna con imágenes, teasers y CTAs. Navegación enterprise para estructuras de sitio complejas.

## Las estructuras de sitio complejas con más de 200 páginas necesitan una navegación que muestre más que listas de texto

Los sitios con tres o más niveles de navegación y más de 200 páginas se topan con los límites de un menú desplegable estándar. Los visitantes van clicando por listas anidadas, pierden la orientación y abandonan. Un mega-menú resuelve el problema: al pasar el ratón o hacer clic en un elemento principal, se abre un panel de varios niveles con columnas, imágenes, teasers y CTAs directos. La extensión megamenu incorpora ese concepto de navegación en TYPO3 como elemento de contenido configurable. Los redactores mantienen los contenidos del menú (imágenes, textos de teaser, enlaces) en el backend y la extensión renderiza el mega-menú en el frontend.

Para webs enterprise con portafolios de producto complejos, portales sectoriales con subáreas regionales o portales universitarios con estructuras de facultad, un mega-menú no es opcional, sino requisito para una navegación utilizable. El reto no está en la visualización, sino en la accesibilidad, el comportamiento responsive y el rendimiento.

## Los escenarios típicos son webs corporativas, e-commerce y portales universitarios

El escenario estándar es la web corporativa con 5 a 8 categorías principales y entre 10 y 30 subpuntos cada una. Un fabricante de maquinaria muestra bajo "Productos" cinco líneas de producto con seis grupos de producto cada una, complementadas por una imagen destacada y un enlace al configurador de producto. Bajo "Sectores" aparecen ocho páginas sectoriales con texto breve e icono. El mega-menú hace que esa estructura sea captable de un vistazo, sin que el visitante tenga que ir clicando por sublistas.

Segundo escenario: webs de e-commerce con catálogo amplio. Una tienda online con más de 500 productos en 20 categorías muestra en el mega-menú las categorías principales con subcategorías, bestsellers y enlaces promocionales. La presentación visual con imágenes de producto en el menú incrementa la tasa de clics hacia las páginas de categoría en torno a un 10 a 20% frente a listas de texto puras.

Tercer escenario: portales universitarios con estructura de facultades e institutos. Una universidad con 12 facultades y decenas de institutos necesita una navegación que refleje tanto la estructura organizativa como áreas funcionales (estudios, investigación, carrera profesional). El mega-menú muestra bajo "Estudios" el buscador de titulaciones, información de admisión y plazos, y bajo "Facultades" los institutos con enlaces directos a personal y proyectos de investigación.

## La arquitectura técnica combina el árbol de páginas TYPO3 con elementos de contenido adicionales

La extensión megamenu amplía la navegación de TYPO3 con un elemento de contenido que se crea en el árbol de páginas como configuración de menú. A cada elemento del menú principal se le puede asociar un panel de mega-menú compuesto por columnas. Cada columna contiene enlaces, imágenes, bloques de texto enriquecido o elementos de contenido personalizados.

La lógica de renderizado produce una construcción HTML de listas anidadas y contenedores div que se estilizan con CSS como panel de varios niveles. El componente JavaScript controla la apertura y cierre (hover en escritorio, clic en dispositivos táctiles) y la navegación por teclado (Tab, Enter, Escape, flechas). Los atributos ARIA (aria-expanded, aria-haspopup, role="menu") hacen que el menú sea navegable para lectores de pantalla.

La implicación en rendimiento es relevante: un mega-menú con imágenes y teasers para 8 puntos principales genera notablemente más HTML que un menú estándar. El lazy loading para imágenes en el mega-menú es obligatorio, para que el tiempo inicial de carga no se resienta. Gosign recomienda cargar los contenidos del mega-menú por AJAX al pasar el ratón cuando el panel contenga más de 5 imágenes por punto principal.

## Los problemas frecuentes son la accesibilidad, el comportamiento móvil y la complejidad editorial

Primer problema: deficiencias de accesibilidad. Muchas implementaciones de mega-menú no son navegables por teclado. Tab salta sobre el panel completo en lugar de iterar por los elementos del menú. Escape no cierra el panel. Faltan estilos de foco. La solución: seguir las WAI-ARIA Authoring Practices para menús de navegación, implementar explícitamente la gestión de teclado y probar la lógica de focus management con un lector de pantalla (NVDA, VoiceOver).

Segundo problema: comportamiento móvil. En smartphones, un mega-menú se convierte en un obstáculo porque el panel ocupa toda la pantalla y el visitante no puede volver al contenido de la página. La solución: en dispositivos móviles sustituir el mega-menú por una navegación en acordeón que presente los mismos contenidos en una estructura vertical. El cambio se realiza mediante media queries de CSS y una lógica JavaScript separada para dispositivos táctiles.

Tercer problema: complejidad editorial. Los redactores deben mantener imágenes, textos y enlaces para cada panel del mega-menú. Sin directrices claras aparecen paneles inconsistentes: uno tiene cuatro columnas con imágenes, el siguiente una columna con 30 enlaces. La solución: una guía de contenido que defina número máximo de columnas, formatos de imagen y longitudes de texto por panel. Gosign entrega esa guía como parte del proyecto de mega-menú y configura los campos del backend para que los redactores trabajen dentro de los límites definidos (por ejemplo, máximo 4 columnas, máximo 8 enlaces por columna, formato de imagen 16:9).

Otro tema es la implicación SEO: los mega-menús con muchos enlaces elevan el total de enlaces internos por página. Si cada página tiene más de 200 enlaces en el mega-menú, eso diluye el link juice que fluye hacia páginas de destino concretas. La solución: cargar contenidos del mega-menú de forma selectiva sin renderizar todos los paneles simultáneamente en el HTML, o excluir estratégicamente enlaces poco relevantes con tabindex="-1" de la navegación del rastreador.

## TYPO3 v12 requiere adaptaciones, las implementaciones personalizadas son más sostenibles a largo plazo

La extensión megamenu debe adaptarse al actualizar a TYPO3 v12, ya que la configuración TCA y el manejo de elementos de contenido han cambiado. Para v13 aún no hay soporte oficial. Gosign construye mega-menús en proyectos nuevos como componente personalizado en el site package, que utiliza el árbol de páginas TYPO3 como fuente de datos y controla la configuración del menú a través de Page Properties o Backend Layouts. Eso elimina la dependencia de la extensión y da control total sobre la estructura HTML, la accesibilidad y el rendimiento.

--- Microtemplate TYPO3 | Gosign ---
> Extensión Microtemplate para TYPO3. Templates inline mínimos directamente en TypoScript. Para necesidades de renderizado sencillas sin Fluid.

## Fluid a veces es exagerado cuando solo hay que rellenar una cadena con variables

No todo problema de plantillas necesita el motor Fluid completo. Si el asunto de un email debe ser "Hola {name}, su pedido #{orderNumber}" o un snippet en el footer debe mostrar "Última actualización: {date}", Fluid con ViewHelpers, layouts y partials es un sobrecoste arquitectónico. microtemplate ofrece un motor de plantillas mínimo para TYPO3 que sustituye variables en bloques de texto. Sin Fluid, sin rutas de objetos TypoScript, sin fichero de plantilla. Una cadena con marcadores, un array con valores, listo.

La extensión es una herramienta de nicho para desarrolladores que necesitan sustituciones sencillas de cadenas dentro de extensiones o configuraciones TypoScript, sin arrancar la pipeline de renderizado Fluid. Para los redactores, microtemplate no es visible directamente: trabaja en segundo plano como utilidad. Su ámbito de uso es deliberadamente estrecho: allá donde Fluid es la opción correcta para plantillas complejas con bucles, condicionales y herencia, microtemplate cubre el caso simple en el que una cadena ya preparada necesita un valor dinámico en tres lugares.

## Los escenarios típicos son textos de email, snippets dinámicos y plantillas de configuración

El escenario más frecuente es la generación de textos de email en extensiones. Una extensión personalizada envía correos de confirmación y se quiere que el asunto y el cuerpo sean configurables, sin que el desarrollador tenga que crear plantillas Fluid. microtemplate lee el texto desde una constante TypoScript ("Pedido #{orderNumber} confirmado") y sustituye los marcadores con los valores actuales.

Segundo escenario: snippets de texto dinámicos en configuraciones TypoScript. Un patrón de título de página como "{siteName} - {pageTitle} | {category}" se resuelve mediante microtemplate. Es más sencillo que un COA con varios objetos TEXT y funciones stdWrap.

Tercer escenario: plantillas de configuración para integraciones con terceros. Cuando una extensión hace configurable un endpoint de API ("https://api.example.com/{version}/users/{userId}"), microtemplate puede sustituir los marcadores antes de la llamada API. Es especialmente útil para extensiones que soportan varios entornos API (staging, producción) y quieren mantener la estructura del endpoint no en el código, sino en la configuración TypoScript.

Un cuarto escenario que aparece ocasionalmente en la práctica: mensajes de log con formato estructurado. Una extensión escribe "Importación de {count} registros desde {source} finalizada a las {time}" en el log de TYPO3. microtemplate hace configurable el texto de log sin que el desarrollador tenga que mantener llamadas sprintf con argumentos posicionales.

## La arquitectura técnica es una única clase PHP con reemplazo de cadenas

microtemplate consiste en su núcleo en una única clase PHP que ejecuta str_replace o preg_replace sobre una cadena de plantilla. Los marcadores siguen una sintaxis definible (por defecto: {variableName}). Un array asociativo aporta los valores. La clase no tiene dependencias más allá del manejo de cadenas de PHP.

La integración en TYPO3 se realiza mediante un servicio o un método estático que se invoca desde otras extensiones o configuraciones TypoScript. No hay plugin de frontend, ni módulo de backend, ni elemento de contenido. microtemplate es pura infraestructura para desarrolladores.

El rendimiento es despreciable: un str_replace sobre una cadena de 500 caracteres con 5 variables tarda menos de 0,01ms. En comparación, el motor Fluid inicia para el mismo resultado un ciclo completo de renderizado con parseo de plantilla, instanciación de ViewHelpers y cacheo, que está entre 1 y 5ms. En un proceso típico de renderizado de página esa diferencia no se nota, pero en bucles que generan 1.000 correos o 500 entradas de log, la ventaja de rendimiento se vuelve medible.

La extensión no tiene tablas de base de datos, ni módulos de backend, ni plugins de frontend. Se instala vía Composer o el gestor de extensiones y se puede usar inmediatamente. Eso hace de microtemplate una de las extensiones más ligeras de todo el TER (TYPO3 Extension Repository).

## Los problemas frecuentes son la falta de escapado, los conflictos de sintaxis y la documentación escasa

Primer problema: no hay escapado HTML automático. microtemplate sustituye los marcadores 1:1, sin escapar el valor insertado. Si un nombre de usuario contiene etiquetas HTML ("<script>alert('XSS')</script>"), eso se escribe directamente en la salida. La solución: escapar los valores manualmente antes de insertarlos (htmlspecialchars) o usar microtemplate solo con datos internos no generados por usuarios.

Segundo problema: conflictos de sintaxis con Fluid. Si se usan marcadores de microtemplate ({variable}) en un contexto donde también renderiza Fluid, Fluid intenta resolver los marcadores y lanza un error. La solución: usar una sintaxis de marcadores diferente (por ejemplo, {{variable}} o %variable%) o asegurarse de que microtemplate se ejecute antes que Fluid.

Tercer problema: documentación escasa y poco soporte de comunidad. microtemplate es una extensión de nicho con base de usuarios mínima. Ante problemas no hay comunidad activa, ni issue tracking, ni respuestas en Stack Overflow. Los desarrolladores deben leer el código fuente para entender su comportamiento. En la práctica, eso hace que cada desarrollador del equipo use la extensión de forma distinta, porque no hay convenciones documentadas.

Otro tema: depuración. Si un marcador no se sustituye porque la clave del array no coincide exactamente con el nombre del marcador (mayúsculas/minúsculas, espacios), microtemplate no emite ninguna advertencia. El marcador queda ahí y el desarrollador busca el fallo en el lugar equivocado. Un modo debug que registre marcadores no resueltos sería de ayuda, pero no existe.

## La extensión es independiente de la versión de TYPO3, pero para proyectos modernos hay mejores alternativas

Como microtemplate solo usa funciones estándar de PHP, la extensión funciona en principio con cualquier versión de TYPO3, de v7 a v13. La pregunta es más bien si sigue siendo necesaria: desde PHP 8.0, los named arguments combinados con sprintf o str_replace ofrecen la misma funcionalidad sin extensión. Para plantillas más complejas, Fluid es la mejor opción pese al sobrecoste, porque aporta cacheo, escapado y herencia de plantillas. Gosign no usa microtemplate activamente en proyectos existentes y recomienda, en implementaciones nuevas, reflejar la funcionalidad directamente en la propia extensión o en TypoScript mediante stdWrap.

--- news TYPO3 - Blog y noticias | Gosign ---
> tx_news de Georg Ringer: La extensión TYPO3 más utilizada. Noticias, blog, comunicados de prensa. Actualización, migración, plantillas. Acelerado por IA.

## tx_news es la extensión sin la que ningún proyecto TYPO3 se las arregla

Más del 80% de todas las instalaciones TYPO3 utilizan tx_news de Georg Ringer. Esa cifra por sí sola ya sería impresionante, pero subestima la importancia de la extensión: tx_news no es solo un plugin de noticias, sino el fundamento para blogs, revistas, áreas de prensa, listados de eventos, directorios de personal y cualquier otro tipo de contenido estructurado y cronológico en TYPO3. La extensión aporta categorías, etiquetas, recursos multimedia, campos SEO (Canonical, OpenGraph, Schema.org), paginación e importación/exportación desde una única base de código mantenida activamente. Quien publique contenido editorial en TYPO3 no puede prescindir de tx_news.

Gosign ha configurado, ampliado y migrado tx_news en cientos de proyectos. Desde plantillas Fluid hasta ViewHelpers personalizados, pasando por la migración completa de tt_news. La extensión forma parte fija de cada configuración TYPO3 que entregamos.

## Los escenarios típicos van desde el blog corporativo hasta la base de datos de prensa

El escenario más frecuente es el blog corporativo o la revista online. Los redactores mantienen artículos en el backend de TYPO3 con título, teaser, cuerpo, categorías, etiquetas y medios. La vista de lista muestra teasers con imagen y la vista de detalle el artículo completo. Los campos relevantes para SEO, como meta description, URL canónica e imagen OpenGraph, se gestionan por artículo. Una instalación típica tiene entre 100 y 5.000 artículos y crece de 2 a 10 artículos por semana.

Segundo escenario: comunicados de prensa para relaciones con inversores y comunicación corporativa. Empresas cotizadas publican comunicados obligatorios en el área de prensa de su web. tx_news aporta la cronología, la categorización (hecho relevante, informe trimestral, nombramiento) y la función de descarga para PDFs adjuntos. La función de archivo asegura que incluso comunicados de hace diez años sigan siendo localizables.

Tercer escenario: listas de eventos y calendarios de actividades. tx_news puede gestionar fechas de inicio y fin para las entradas, lo que lo convierte en un calendario de eventos sencillo. Para asociaciones, entidades culturales y organizaciones educativas suele ser suficiente sin necesidad de una extensión de eventos especializada como sf_event_mgt. Solo cuando se requieren funciones de inscripción, gestión de participantes o ticketing, tx_news se topa con sus límites.

## La arquitectura técnica separa con rigor datos, configuración y presentación

tx_news almacena los artículos como registros Extbase en la tabla tx_news_domain_model_news. Cada registro contiene campos obligatorios (título, datetime, tipo) y opcionales (teaser, cuerpo, autor, etiquetas, categorías, medios, noticias relacionadas). Las relaciones con categorías y etiquetas se gestionan vía tablas MM, lo que permite un filtrado eficiente.

La configuración se realiza vía TypoScript: rutas de plantillas, orden, paginación, filtros por categoría, PID de la página de detalle y ajustes SEO. La extensión aporta un amplio conjunto de constantes TypoScript que cubre la mayoría de configuraciones sin código propio. Para requisitos personalizados (por ejemplo, un slider en la home que muestre las tres noticias más recientes) existen ViewHelpers utilizables en plantillas Fluid.

Las plantillas Fluid para List, Detail, Category y menú de fecha son sobrescribibles vía rutas TypoScript. En la práctica se copian las plantillas estándar al site package propio y se adaptan la estructura HTML y las clases CSS al corporate design. Esa separación permite actualizar la extensión sin que se sobrescriban los cambios propios.

El rendimiento es bueno con una configuración correcta: la vista de lista aprovecha el page cache de TYPO3 y la vista de detalle cachea por UID de artículo. Solo con archivos de noticias por encima de 10.000 artículos, con filtros de categoría complejos y búsqueda de texto completo, el rendimiento pasa a ser un tema. En esos casos conviene un índice de búsqueda vía ke_search o Solr.

## Los problemas frecuentes son la configuración SEO, el rendimiento y la migración desde tt_news

Primer problema: URLs canónicas ausentes o erróneas. Sin la configuración correcta, el mismo artículo es accesible a través de varias URLs: por la ruta de categoría, por la ruta de archivo y por el enlace directo. Google indexa todas las variantes como páginas distintas, lo que provoca contenido duplicado. La solución: fijar explícitamente la PID de la página de detalle y configurar la URL canónica en los ajustes TypoScript hacia la página de detalle. La extensión newscanonical aborda también este problema.

Segundo problema: caídas de rendimiento con grandes archivos de noticias. Cuando la vista de lista tiene que recorrer más de 5.000 artículos, los tiempos de consulta a la base de datos aumentan. La solución: restricciones por categoría en la configuración TypoScript, paginación con un máximo de 20 artículos por página e índices de base de datos sobre las relaciones de categoría.

Tercer problema: migración desde tt_news. La extensión legacy tt_news ya no es compatible desde TYPO3 v8. La migración de datos a tx_news requiere un mapeo de campos (tt_news_cat a sys_category, plantillas marker a plantillas Fluid) y una estrategia de redirección URL para que los rankings de Google existentes se mantengan. Gosign utiliza para ello análisis de plantillas impulsado por IA: nuestras herramientas leen las antiguas plantillas marker, identifican los campos utilizados y generan plantillas Fluid que producen la misma salida.

## tx_news soporta TYPO3 v12 y v13 plenamente

Georg Ringer mantiene tx_news activamente y, con cada release LTS de TYPO3, publica con diligencia una versión compatible. La serie actual soporta TYPO3 v11, v12 y v13 en paralelo. Al actualizar de v10 o v11 a v12, los cambios disruptivos afectan sobre todo a ViewHelpers propios que deben adaptarse a la API actual de Fluid, así como a configuraciones TypoScript que deberían migrarse a la nueva sintaxis SiteSet. La estructura de registros se mantiene estable, no es necesaria una migración de datos. Gosign realiza las actualizaciones de tx_news típicamente en el marco del upgrade del core TYPO3 y revisa en ese momento plantillas propias, ViewHelpers y overrides TypoScript respecto a compatibilidad. En proyectos con personalizaciones amplias (campos personalizados, ViewHelpers propios, integración con sistemas de terceros) elaboramos antes del upgrade una matriz de compatibilidad que documenta todas las dependencias y estima con realismo el esfuerzo de migración. El análisis de código impulsado por IA acelera considerablemente ese proceso al identificar todos los puntos del proyecto afectados por los cambios de API.

--- news_podcast TYPO3 - Plugin de podcast | Gosign ---
> Funcionalidad de podcast para GeorgRinger/news. RSS Feed con etiquetas compatibles con iTunes, integración de reproductor de audio, gestión de episodios.

## news_podcast convierte un sistema de noticias en un host de podcast

Quien mantiene en TYPO3 entradas de noticias y produce en paralelo un podcast se enfrenta a una decisión: o bien utiliza un host de podcast externo (Podigee, Ivoox, Anchor) y enlaza desde el sitio web, o bien entrega el feed del podcast directamente desde TYPO3. news_podcast hace posible la segunda opción: la extensión amplía GeorgRinger/news con campos y plantillas Fluid para archivos de audio y genera un feed RSS compatible con iTunes que Apple Podcasts, Spotify y Google Podcasts importan sin rodeos. Para empresas que quieren mantener la soberanía sobre su contenido y sus archivos de audio, esa es la opción de arquitectura relevante. Evita la dependencia de plataformas, mantiene las estadísticas de uso en la propia casa y sirve además el contenido en el mismo contexto CMS en el que viven también las entradas de noticias y la revista.

## Escenarios típicos: podcasts corporativos y ofertas formativas

Los podcasts corporativos son el escenario más frecuente. Una empresa industrial mediana produce cada dos semanas un episodio con invitados del sector y quiere incrustar los episodios en el blog corporativo, presentarlos en Apple Podcasts y, al mismo tiempo, publicar entradas de noticias con impacto SEO, transcripción y notas del episodio. news_podcast cubre esas tres necesidades en un único registro, sin que la redacción deba mantener tres sistemas distintos. Un registro de podcast bien mantenido genera automáticamente la entrada de noticia, la entrada del feed RSS y el marcado Schema.org/PodcastEpisode.

Un segundo escenario son las universidades y los proveedores de formación. Las clases se graban como archivo de audio y se guardan en el servidor del campus. A través de news_podcast aparecen como episodios de una serie de conferencias, con capítulos, transcripción y referencias bibliográficas. El feed se presenta en Apple Podcasts y Spotify, y el acceso se realiza directamente a través de la web TYPO3, sin que los estudiantes tengan que usar un portal adicional. Especialmente en épocas con alta carga de e-learning, esa es una ventaja perceptible frente a plataformas de terceros que traen consigo cuentas y tracking adicionales.

Un tercer escenario son asociaciones y organizaciones políticas que ofrecen entrevistas semanales o ruedas de prensa como podcast. Aquí se trata sobre todo de soberanía: todos los datos están en la propia infraestructura, y la estadística de audiencia procede del log del propio servidor, no del panel de un proveedor externo. Para organizaciones con alta sensibilidad frente a servicios de tracking, ese es a menudo el factor decisivo frente a hosts de podcast externos.

## Arquitectura técnica: ampliación del modelo News con atributos de podcast

news_podcast registra un nuevo conjunto de campos mediante un TCA override para tx_news_domain_model_news. Por artículo hay disponibles campos adicionales: archivo de audio (referencia FAL), duración, episodio, temporada, tipo (Full, Trailer, Bonus), flag Explicit y transcripción. Mediante otro override, la categoría News se amplía con un campo Podcast Channel, con iTunes Category, cover art, autor, correo de owner e idioma.

El feed RSS se entrega a través de un controlador TYPO3 propio. La ruta es configurable y genera un RSS 2.0 con extensiones de namespace iTunes. Cada episodio contiene las etiquetas obligatorias para enclosure, duration, episode, episodeType y explicit. La validación se realiza contra el Apple Podcasts Feed Validator y contra castfeedvalidator.com. Sin una validación válida Apple Podcasts se niega a incorporar el feed y Spotify no muestra el canal en los resultados de búsqueda.

La salida de frontend utiliza partials Fluid que pueden sobrescribirse mediante overlay de paquete. La salida estándar incrusta un reproductor HTML5 de audio y renderiza las shownotes en el texto corrido de la plantilla de detalle de noticia. Para la salida de transcripción se utiliza un área partial separada, accesible mediante un sistema de pestañas o un acordeón. Quien quiera mantener las transcripciones como vista completa en el DOM por motivos SEO, sobrescribe el partial y renderiza el texto completo en línea.

## Problemas frecuentes: validación del feed, enclosures y streaming

El tema de soporte más habitual es la validación del feed para iTunes. Apple Podcasts rechaza feeds cuando la cover art no cumple los requisitos (mínimo 1400x1400 px, máximo 3000x3000 px, JPEG o PNG, sRGB) o cuando la etiqueta enclosure no contiene indicación de MIME type. En la práctica, el primer envío suele fracasar por la proporción del cover art, no por la propia extensión.

El segundo tema son los tamaños de archivo y el streaming. Los archivos de audio en calidad de podcast (128 kbit MP3) rondan entre 30 y 60 MB por episodio. Quien entrega esos archivos directamente desde el storage de TYPO3 transfiere toda la carga al servidor web, lo que con miles de oyentes por episodio se convierte en un cuello de botella. Recomendamos externalizar los archivos de audio a un storage separado (compatible S3, CDN) e integrarlos mediante FAL Remote Storage. Así el servidor TYPO3 sigue encargándose de la entrega de contenido, mientras la carga de audio acaba en la capa de storage más económica.

En tercer lugar, Google Podcasts exige una URL semántica y permanente por episodio. La extensión la genera automáticamente a partir del slug de noticia, pero el routing debe liberarse en la Site Config para el controlador del podcast; si no, TYPO3 genera URLs Typolink con querystring que Google Podcasts no acepta.

## La migración a TYPO3 v12 exige una actualización sincrónica del núcleo news

news_podcast está disponible para TYPO3 v11, v12 y v13, pero requiere una versión compatible de GeorgRinger/news. Al saltar a TYPO3 v12 ambas extensiones deben actualizarse de forma sincrónica: news a la serie v12 y news_podcast a la versión mayor correspondiente. La estructura de base de datos se mantiene estable, las referencias FAL de audio viajan sin rodeos.

Gosign migra news_podcast típicamente como parte de un refactoring de content hub. En el mismo paso comprobamos si las transcripciones pueden ampliarse con datos estructurados, si el cover art cumple las directrices actuales de Apple y si el controlador del feed está protegido con un rate limit. Para podcasts más grandes ampliamos la extensión con un modelo Hosts propio, de modo que los invitados puedan gestionarse con página de perfil y backlink. Combinado con md_news_author se pueden mantener en paralelo podcasters e invitados como perfiles de autor, lo que mejora claramente el marcado Schema.org y el enlazado interno.

--- tt_news Migración TYPO3 | Gosign ---
> Extensión de migración de tt_news a GeorgRinger/news. Transfiere datos, categorías y relaciones. Gosign también migra plantillas Fluid y plugins personalizados.

## Quien aún usa tt_news bloquea cualquier actualización de TYPO3 a partir de la versión 10

tt_news fue durante más de una década la extensión estándar para noticias, comunicados y artículos de blog en TYPO3. Miles de webs se construyeron con ella. El problema: tt_news fue soportada oficialmente por última vez para TYPO3 v7. Desde v8 (2017) no existe release compatible. Quien aún tiene tt_news en producción está atrapado en una versión obsoleta sin actualizaciones de seguridad ni nuevas funcionalidades.

La sustituta oficial es GeorgRinger/news (EXT:news), la extensión TYPO3 más instalada (más de 250.000 instalaciones activas, 2026), compatible con TYPO3 v11, v12 y v13. news_ttnewsimport automatiza la transición: artículos, categorías, imágenes, noticias relacionadas y referencias de página se transfieren de tt_news a EXT:news.

## Escenarios de uso habituales

**Actualización TYPO3 de v7/v8/v9 a v12 o v13.** Una empresa opera una web TYPO3 en v7 o v9 con 500 a 5.000 artículos en tt_news. La actualización a v12 LTS falla por tt_news. news_ttnewsimport transfiere todos los datos a la estructura EXT:news.

**Relanzamiento con datos existentes.** Los artículos han acumulado valor SEO durante años (backlinks, indexación, rankings). Un nuevo comienzo sin migración destruiría ese valor.

**Entornos multi-site con base de datos de noticias compartida.** Corporaciones con 5 a 20 instancias TYPO3. La migración debe coordinarse: primero la base de datos central, luego plantillas en todos los sitios.

## Arquitectura técnica

news_ttnewsimport es una extensión CLI que trabaja en cinco pasos: conversión de categorías tt_news a sys_category, migración de registros de noticias, conversión de imágenes a referencias FAL, migración de noticias relacionadas, y actualización de elementos de contenido (plugins tt_news reemplazados por plugins EXT:news).

## Problemas frecuentes y soluciones

**Faltan imágenes tras la migración.** tt_news almacenaba imágenes como nombres de archivo en campos de texto. Si los archivos físicos ya no están en el directorio esperado, la migración falla. Solución: verificar antes de la migración que todas las imágenes referenciadas existen.

**Se pierden asignaciones de categorías.** tt_news usaba tablas de categoría propias; EXT:news usa sys_category. Solución: news_ttnewsimport crea un mapping y actualiza todas las referencias.

**La estructura de URLs cambia, caen los rankings.** Los artículos tt_news tenían URLs distintas a EXT:news. Solución: redirecciones 301 automáticas. Gosign genera el mapa de redirecciones a partir de las estructuras antigua y nueva.

## Migración y compatibilidad de versiones

news_ttnewsimport soporta la migración en TYPO3 v11 y v12. Para volúmenes grandes (más de 10.000 artículos) Gosign recomienda migrar en staging y verificar antes de cambiar producción. La migración dura entre 30 minutos (500 artículos) y 4 horas (10.000 artículos con imágenes). La adaptación de plantillas Fluid se suma como esfuerzo aparte, típicamente de 2 a 5 días.

Un aspecto frecuentemente subestimado: la comunicación con buscadores. Google tiene las URLs antiguas indexadas y evaluadas. Si tras la migración 500 URLs devuelven 404, la web pierde posiciones. Gosign configura tras cada migración un monitoring de redirecciones: una semana después del go-live se revisan los datos de Google Search Console en busca de errores 404, se añaden redirecciones faltantes y se acelera la indexación de las nuevas URLs vía IndexNow.

--- newscanonical TYPO3 - Canonical para noticias | Gosign ---
> newscanonical: etiquetas Canonical correctas para TYPO3 News. Evitar contenido duplicado. Optimización SEO.

## El contenido duplicado por falta de etiquetas Canonical cuesta posiciones a las páginas de noticias TYPO3

Un artículo de tx_news suele ser accesible desde tres o más URLs: por la ruta de categoría (/noticias/marketing/titulo-articulo), por el archivo (/noticias/2025/03/titulo-articulo) y por un enlace directo (/noticias/titulo-articulo). Para los visitantes da lo mismo; para Google es un problema. Google ve tres páginas distintas con contenido idéntico y debe decidir cuál es la "correcta". Sin una etiqueta canonical que apunte a la URL preferida, Google reparte las señales de ranking entre todas las variantes y debilita cada una. newscanonical resuelve ese problema para tx_news generando en cada página de detalle de noticia una etiqueta canonical que apunta a la URL definitiva.

La extensión es una herramienta SEO enfocada que hace exactamente un trabajo: evitar contenido duplicado en tx_news. Para webs con más de 100 artículos puede suponer la diferencia entre la página 1 y la página 3 de Google.

## Los escenarios típicos son webs de noticias, revistas y áreas de prensa

El escenario estándar es la web corporativa con un área de noticias o blog. Una empresa publica semanalmente artículos clasificados en categorías (productos, sectores, eventos). Cada artículo aparece en el listado de categoría y en el archivo general. Sin newscanonical, Google indexa cada variante de URL por separado, lo que, con 500 artículos, puede traducirse en 1.500 páginas indexadas con contenido duplicado. Google Search Console lo muestra como "Página duplicada, la URL canónica elegida por Google difiere de la indicada por el usuario".

Segundo escenario: revistas online con vistas de lista basadas en etiquetas y categorías. Una revista tiene 20 categorías y 50 etiquetas. Cada artículo tiene al menos una categoría y dos o tres etiquetas. La combinatoria genera decenas de rutas URL posibles por artículo. newscanonical consolida todas las variantes en una única URL canónica.

Tercer escenario: áreas de prensa de empresas cotizadas. Los comunicados obligatorios deben estar disponibles de forma permanente y no pueden caer de los resultados de búsqueda por problemas de contenido duplicado. Una etiqueta canonical correcta garantiza que Google indexe la versión definitiva.

## La arquitectura técnica coloca una etiqueta link en el head HTML por cada página de detalle de noticia

newscanonical se registra en la pipeline de renderizado de tx_news e inserta en el head HTML de la página de detalle una etiqueta `<link rel="canonical" href="...">`. La URL canónica se calcula a partir de la PID de la página de detalle configurada y del UID de la noticia, con independencia de la ruta por la que el visitante haya llegado a la página.

La configuración se realiza vía TypoScript: se establece la PID de la página de detalle como base para la URL canónica. Parámetros opcionales como la estructura de URL (RealURL o TYPO3 Site Handling) y la inclusión de segmentos de categoría en la URL canónica se controlan mediante constantes.

La extensión actúa como hook dentro de la pipeline de renderizado de tx_news, no como un plugin independiente. Eso significa que no tiene salida de frontend propia ni un elemento de contenido propio. La única consecuencia visible es la etiqueta canonical en el HTML, que los motores de búsqueda leen pero los visitantes nunca ven.

Para su correcto funcionamiento, la PID de la página de detalle en la configuración de tx_news y en la de newscanonical debe coincidir. Si tx_news usa varias páginas de detalle (por ejemplo, una por categoría), newscanonical debe configurarse en consecuencia para que la URL canónica apunte a la página de detalle correcta.

## Los problemas frecuentes son la configuración incorrecta de PID, los conflictos con el canonical del core y los bucles de redirección

Primer problema: PID de detalle incorrecta. Si la PID en la configuración de newscanonical no coincide con la de tx_news, la etiqueta canonical apunta a una página que ni siquiera puede mostrar el artículo. Google entonces ignora esa etiqueta y elige por sí mismo una variante. La solución: verificar la consistencia de las PIDs y comparar en Google Search Console las URLs canónicas indexadas con las URLs configuradas.

Segundo problema: conflictos con el canonical del core TYPO3. Desde TYPO3 v10, el core tiene su propia generación de URL canónica vía la extensión de sistema seo. Si ambos están activos, pueden aparecer dos etiquetas canonical en conflicto en el head HTML. La solución: comprobar si el canonical del core funciona correctamente para las páginas de detalle de noticia. Si funciona, newscanonical sobra y se puede desactivar. Si el canonical del core no incorpora correctamente los parámetros de news en la URL, newscanonical sigue siendo necesario.

Tercer problema: bucles de redirección por configuración de URL errónea. Si la URL canónica apunta a una página que a su vez contiene una redirección hacia otra URL, se crea un bucle. Eso ocurre típicamente tras una reestructuración de URLs, si no se depuraron las redirecciones antiguas. La solución: revisar todas las redirecciones de URLs de noticias y eliminar las entradas inconsistentes.

## Desde TYPO3 v12 Gosign comprueba si el canonical del core es suficiente

TYPO3 v12 ha mejorado significativamente el soporte canonical en el core. La extensión de sistema seo genera URLs canónicas sobre la base del Site Handling y tiene en cuenta parámetros de consulta. Para muchas configuraciones de tx_news, el canonical del core es suficiente desde v12, con lo que newscanonical ya no es necesario. Gosign comprueba en cada upgrade de TYPO3 si la solución del core genera correctamente las URLs canónicas de noticias. Si es así, recomendamos desactivar newscanonical para eliminar un punto potencial de conflicto. Si las URLs de noticias contienen parámetros complejos o rutas de categoría que el core no resuelve, la extensión sigue siendo una solución válida. En cualquier caso, tras el upgrade recomendamos un crawl sistemático con Screaming Frog o una herramienta comparable para comprobar el comportamiento canonical de todas las páginas de detalle. Una sola etiqueta canonical mal configurada puede desplazar decenas de páginas del índice de Google, lo que en áreas de prensa o artículos de blog relevantes para SEO implica pérdida directa de tráfico.

--- News-Sync TYPO3 | Gosign ---
> Sincronización de noticias entre instancias TYPO3 o fuentes externas. Importación RSS, sincronización de contenido basada en API con detección de duplicados.

## Cuando el contenido de noticias debe aparecer en varias instancias TYPO3, copiar y pegar no basta

Las organizaciones con varias webs se enfrentan a un problema concreto: una entidad estatal publica una nota de prensa y quince asociaciones territoriales deben mostrarla en sus propias instalaciones TYPO3. O un grupo empresarial gestiona una web corporativa y cinco webs de marca, y determinadas noticias deben aparecer en las seis. La copia manual es propensa a errores, consume tiempo y genera inconsistencias. newssync resuelve el problema sincronizando artículos de noticias entre instancias TYPO3 o desde fuentes externas de forma automática. La importación RSS, la sincronización vía API y la detección de duplicados son sus funciones centrales.

Para organizaciones con estrategia multi-site, la sindicación de contenido no es un lujo, sino una necesidad operativa. Sin sincronización automatizada aparecen silos de contenido que la redacción central no puede controlar.

## Los escenarios típicos son redes de asociaciones, webs corporativas y agregación de noticias

El escenario más frecuente es la red de asociaciones. Una asociación nacional publica noticias sectoriales, actualizaciones regulatorias y notas de prensa en su web TYPO3. Las 17 asociaciones autonómicas tienen sus propias instalaciones TYPO3 y quieren incorporar automáticamente artículos seleccionados. newssync importa los artículos marcados vía feed RSS o API, crea registros locales de tx_news y permite a las autonómicas adaptar localmente teasers y categorías.

Segundo escenario: webs corporativas con estrategia de content hub. La sede central mantiene un hub de noticias del que las webs de marca y las webs por país obtienen contenido de forma selectiva. La sincronización corre por categoría: una web de marca se suscribe solo a artículos de las categorías "Producto X" e "Innovación", no al feed completo de noticias.

Tercer escenario: agregación de noticias desde fuentes externas. Un portal sectorial importa notas de prensa de empresas miembro automáticamente vía sus feeds RSS. newssync comprueba los feeds en intervalos configurables, importa artículos nuevos y reconoce duplicados mediante título y fecha de publicación.

## La arquitectura técnica utiliza el parseo RSS y la pipeline del Scheduler de TYPO3

newssync trabaja con dos modos de importación: importación de feed RSS/Atom y sincronización vía API. En modo RSS, el administrador configura una URL de feed y la tarea del Scheduler parsea el feed, extrae título, teaser, cuerpo, fecha y URLs de medios y crea registros tx_news en la base de datos local. Las imágenes se descargan y se guardan localmente como ficheros FAL, para que la fuente no tenga que estar disponible de forma permanente.

En modo API, newssync se comunica con un endpoint REST de la instancia origen. Esto permite una importación más selectiva: en lugar de importar el feed completo se pueden filtrar artículos por categorías, etiquetas o fecha. El modo API también transfiere campos personalizados que el formato RSS no puede representar.

La detección de duplicados se basa en una clave configurable: por defecto, un hash de título y fecha de publicación. Si ya existe un artículo con la misma clave, se omite o se actualiza, según la configuración. Eso evita que un mismo artículo se importe varias veces cuando el job de sincronización se ejecuta con más frecuencia que la actualización del feed.

La sincronización corre como tarea del Scheduler de TYPO3, típicamente cada 15 a 60 minutos. Los resultados de cada ejecución se registran: número de artículos importados, actualizados y omitidos. Ante errores (feed no accesible, fallo del parser) se escribe una advertencia en el log de TYPO3.

## Los problemas frecuentes son la importación de medios, la limpieza de HTML y el mapeo de categorías

Primer problema: la importación de medios falla. Las imágenes y documentos referenciados en el feed origen no siempre son descargables directamente. Protecciones anti-hotlink, autenticación o URLs basadas en CDN pueden impedir la descarga. La solución: probar las URLs de medios antes de la importación e implementar un mecanismo de fallback que sustituya las imágenes faltantes por una imagen marcador.

Segundo problema: HTML poco limpio en el contenido importado. Los feeds RSS contienen a menudo HTML que no se ajusta al estándar del sistema destino: estilos inline, etiquetas obsoletas, párrafos ausentes. La solución: un saneado HTML tras la importación que retire etiquetas y estilos superfluos y lleve el contenido al formato esperado. TYPO3 ofrece la clase RteHtmlParser para ello.

Tercer problema: mapeo de categorías entre sistema origen y destino. Las categorías en el feed origen no coinciden con las locales. "Nota de prensa" en la sede central se llama "Prensa" en la autonómica. La solución: una tabla de mapeo en la configuración de newssync que asigne las categorías origen a las sys_categories locales de TYPO3.

Un cuarto problema afecta a la soberanía del contenido: si una asociación territorial modifica localmente un artículo sincronizado y la sede central actualiza también el original, la siguiente sincronización sobrescribe el cambio local. La solución: marcar los artículos sincronizados como "read-only" y permitir adaptaciones locales solo en campos dedicados (por ejemplo, teaser local, complemento regional) que la sincronización no afecte.

## La extensión no tiene soporte asegurado para v12, las soluciones a medida son más robustas

newssync se desarrolló para versiones antiguas de TYPO3 y no tiene soporte oficial para v12 o v13. Para organizaciones que necesitan sindicación de contenido como función central, Gosign recomienda una solución a medida: un importador personalizado como tarea del Scheduler que consuma feeds RSS o una API REST y cree registros tx_news. El esfuerzo para una implementación base con importación de feed, detección de duplicados y descarga de medios está entre 3 y 5 días laborables. La generación de código asistida por IA acelera considerablemente el desarrollo del parser del feed y de la capa de mapeo.

La ventaja de una solución a medida: el mapeo entre categorías origen y destino, el tratamiento de medios y la gestión de errores pueden ajustarse exactamente a los requisitos de la organización. Una asociación nacional con 17 autonómicas tiene requisitos de sincronización distintos a los de un grupo con 5 webs de marca. Gosign implementa soluciones de sindicación de contenido basadas en APIs modernas de TYPO3 (eventos PSR-14, Symfony Messenger para procesamiento basado en colas), que siguen siendo compatibles también en upgrades a v13.

--- Audio Player TYPO3 - HTML5 | Gosign ---
> Reproductor de audio HTML5 para TYPO3. Podcasts, audioguías, streaming de música. Reproductor personalizado con soporte de playlist, barra de progreso, ...

## Los podcasts y audioguías necesitan un reproductor que funcione sin servicios externos

Quien quiera ofrecer contenidos de audio en una web TYPO3 se enfrenta a una disyuntiva incómoda: o un servicio externo como SoundCloud o Spotify, que envía datos de usuario a servidores de terceros e impone el diseño, o un reproductor HTML5 nativo, apenas usable con el estilo por defecto del navegador. nim_html5audioplayer cubre ese hueco. La extensión ofrece un reproductor de audio totalmente integrado en TYPO3, con soporte de playlist, barra de progreso y control de velocidad. Todos los ficheros de audio permanecen en el servidor propio, ninguna petición externa abandona el sitio.

Para museos, instituciones educativas y editoriales con formatos de podcast es un requisito duro: las audioguías no pueden instalar cookies de rastreo, los contenidos formativos tienen que funcionar en intranets sin conexión a internet y los podcasts corporativos deben respetar la identidad visual de la organización. nim_html5audioplayer cubre los tres escenarios con un único elemento de contenido y encaja sin fricción con el RGPD, porque no transfiere datos a terceros.

## Los escenarios típicos abarcan desde museos hasta portales internos de formación

El escenario más frecuente son las audioguías en museos y exposiciones. Los visitantes escanean un QR, aterrizan en una página TYPO3 y escuchan el comentario de una pieza. El reproductor arranca sin autoplay, muestra la barra de progreso y permite ajustar la velocidad entre 0,5x y 2x. En una exposición típica con 30 a 50 estaciones, la función de playlist aporta un recorrido continuo sin que los visitantes tengan que navegar manualmente entre páginas.

El segundo gran ámbito son los podcasts corporativos. Empresas que convierten su conocimiento interno en serie de audio necesitan un reproductor integrado en la web TYPO3 existente, no alojado en una plataforma externa. nim_html5audioplayer aporta para ello un reproductor con identidad de marca, lista de episodios, marcadores de capítulo y opción de descarga. La redacción gestiona los episodios como contenidos TYPO3 normales desde el backend.

Un tercer escenario son los portales de aprendizaje de idiomas y las plataformas de e-learning. Ahí el control de velocidad cobra especial relevancia: los aprendices pueden ralentizar diálogos o reproducir repeticiones a mayor velocidad. Combinado con fe_login, los contenidos de audio premium se pueden proteger tras un inicio de sesión.

## La arquitectura técnica se apoya en APIs HTML5 nativas sin framework JavaScript

nim_html5audioplayer utiliza la HTML5 Audio API del navegador y renderiza la interfaz del reproductor mediante plantillas Fluid. No hay dependencia con jQuery, React u otro framework. Eso mantiene el tiempo de carga al mínimo: el reproductor en sí pesa menos de 15 KB (CSS + JS) y los ficheros de audio se gestionan vía FAL (File Abstraction Layer) y se sirven por streaming.

La extensión registra un elemento de contenido propio en el backend de TYPO3. Los redactores eligen ficheros de audio desde la mediateca FAL y asignan título, descripción e imagen de previsualización opcional. La función de playlist agrupa varias entradas de audio en una lista ordenable. El renderizado lo gestionan plantillas Fluid sobrescribibles mediante SiteSet o un site package propio.

Para la barra de progreso, el reproductor guarda el punto actual de reproducción en el LocalStorage del navegador. Si un visitante vuelve, el reproductor salta a la última posición. Esto funciona sin cookies y sin sesión en el servidor, algo relevante para la protección de datos y el RGPD que la AEPD supervisa.

## Los problemas frecuentes tienen que ver con formatos de audio y navegadores móviles

El tema de soporte dominante es la compatibilidad de formatos de audio. MP3 funciona en todos los navegadores, OGG Vorbis solo en Firefox y Chrome, AAC solo en Safari y Chrome. Quien busque máxima compatibilidad sube cada fichero como MP3. Quien necesite mayor calidad con menor tamaño de fichero entrega MP3 como fallback y Opus como formato primario.

Segundo problema: bloqueo del autoplay en dispositivos móviles. iOS y Android impiden desde 2018 la reproducción automática de audio sin interacción del usuario. nim_html5audioplayer respeta esa política del navegador y arranca el audio únicamente tras un clic explícito. Quien configure pese a todo autoplay para música de fondo obtendrá silencio en móviles, sin mensaje de error.

El tercer tema es el rendimiento con playlists grandes. A partir de 100 entradas en una única playlist, el tiempo de renderizado del DOM se vuelve perceptible. La solución: dividir las playlists en bloques temáticos de 20 a 30 entradas y organizarlas por categorías en el backend.

Un cuarto aspecto, relevante en el contexto español, es la accesibilidad. Las entidades del sector público deben cumplir el Real Decreto 1112/2018 y, con ello, las WCAG 2.1 nivel AA. El reproductor por sí solo no garantiza accesibilidad: hay que aportar transcripciones para los contenidos de audio, etiquetas adecuadas en los controles y una navegación por teclado completa. nim_html5audioplayer cubre lo básico, pero el equipo editorial debe aportar las transcripciones como contenido adicional.

## La extensión funciona en TYPO3 v11 y v12, el estado v13 depende del mantenedor

nim_html5audioplayer se desarrolló originalmente para TYPO3 v8 y v9. La funcionalidad base (HTML5 Audio API, integración FAL) es técnicamente estable y corre en v11 y v12 sin cambios relevantes. Para TYPO3 v13 no existe actualmente una declaración oficial de compatibilidad por parte del mantenedor. La extensión, sin embargo, no utiliza ninguna de las APIs eliminadas en v13, por lo que una migración es posible en la mayoría de casos con poco esfuerzo.

Gosign comprueba en los upgrades de TYPO3 si las extensiones de audio usadas siguen siendo compatibles y recomienda alternativas cuando conviene. Si la extensión deja de evolucionar, la misma funcionalidad se puede reconstruir vía un elemento de contenido personalizado con la HTML5 Audio API nativa y plantillas Fluid, típicamente en dos o tres jornadas de desarrollo.

--- nimcore TYPO3 - Core Framework | Gosign ---
> Extensión de Core Framework para TYPO3. Funciones base para otras extensiones. Dependencia de extensiones nim_*.

## Sin una librería base centralizada, las familias de extensiones generan código duplicado y errores duplicados

Las agencias TYPO3 que desarrollan varias extensiones relacionadas se enfrentan a un problema de arquitectura: cada extensión reimplementa funciones de utilidad como la lectura de configuración, el registro de módulos de backend, el tratamiento de FAL y el logging. Con cinco extensiones, eso significa cinco copias de las mismas funciones auxiliares, cinco lugares para el mismo bug. nimcore resuelve ese problema como librería base central de la familia de extensiones NIM. Clases abstractas, funciones de utilidad y configuración común se concentran en un único lugar. Todas las extensiones NIM dependientes heredan de nimcore y solo tienen que implementar su lógica funcional propia.

Ese patrón es poco frecuente en el ecosistema TYPO3, pero está consolidado en la arquitectura de software: un shared kernel que encapsula preocupaciones horizontales (logging, configuración, base models), mientras que las extensiones verticales (reproductor de audio, galería, slider) asumen la lógica de negocio.

## Los escenarios típicos afectan a agencias con portafolio propio de extensiones

El escenario principal es la agencia que mantiene un conjunto de cuatro a diez extensiones TYPO3 propias. Sin una librería base común, las extensiones divergen: una usa GeneralUtility::makeInstance, otra el contenedor de DI y una tercera tiene su propia configuración de logger. nimcore impone un estándar uniforme. Todas las extensiones NIM usan las mismas clases de controlador abstractas, el mismo tratamiento de excepciones y la misma estructura de configuración.

Un segundo escenario son los equipos de desarrollo internos que amplían su instancia TYPO3 con varias extensiones personalizadas. En lugar de tratar cada extensión como un paquete aislado, los equipos pueden construir su propia librería core siguiendo el patrón de nimcore: base models comunes, clases comunes de módulos de backend, fixtures de test comunes. Eso reduce el mantenimiento y baja el listón de entrada para nuevos desarrolladores que solo necesitan aprender una arquitectura.

Un tercer escenario es el control de versiones durante upgrades. Si el core de TYPO3 cambia una API utilizada en cinco extensiones, basta con una sola actualización en nimcore. Todas las extensiones dependientes se benefician de inmediato sin tener que adaptar cada una por separado. En un upgrade a TYPO3 v12 con siete extensiones NIM, eso suele ahorrar de dos a tres jornadas de desarrollo.

## La arquitectura técnica sigue el principio del shared kernel

nimcore se registra como una extensión TYPO3 normal y se declara vía Composer como dependencia de las extensiones que la usan. El ext_emconf.php de las extensiones NIM lista nimcore como restricción required. Al instalar una extensión NIM, nimcore se carga automáticamente.

Internamente, nimcore aporta clases abstractas para controladores, repositorios y modelos que inicializan correctamente el framework Extbase de TYPO3. Las clases de utilidad encapsulan tareas recurrentes: lectura de configuración TypoScript, resolución de referencias FAL, registro de toolbars de backend, emisión estandarizada de flash messages. Un registro de configuración central permite definir ajustes específicos de extensión en un formato uniforme, accesible en el backend TYPO3 a través de un módulo de settings.

La infraestructura de test también está reunida en nimcore: clases TestCase base, cargadores de fixtures y utilidades de mocking que simplifican los tests funcionales para extensiones Extbase. Eso reduce la barrera para escribir tests, porque el setup no tiene que configurarse de nuevo en cada extensión.

## Los problemas frecuentes son los conflictos de versiones y las dependencias circulares

El mayor riesgo de una arquitectura shared kernel es la obligación de release en lock-step: si nimcore introduce un breaking change, todas las extensiones dependientes deben actualizarse al mismo tiempo. En la práctica, eso significa que nimcore debe cumplir con rigor el versionado semántico. Las versiones menores no pueden cambiar interfaces públicas y los releases mayores necesitan una guía de migración.

Segundo problema: dependencias circulares. Si la extensión A depende de nimcore y nimcore usa un servicio que en realidad se define en la extensión A, surge un ciclo. La solución es un principio limpio de inversión de dependencias: nimcore define interfaces que las extensiones dependientes implementan. nimcore en sí mismo no conoce implementaciones concretas.

El tercer tema es el orden de autoload de Composer. En instalaciones grandes con 30 o más extensiones, el orden de autoloading puede provocar que las clases de nimcore aún no estén disponibles cuando se carga una extensión dependiente. La solución: definir nimcore como la primera del install-order en el composer.json de la instalación raíz.

Un cuarto aspecto es la soberanía sobre el código: en el contexto europeo, con exigencias del RGPD y la directiva NIS 2 sobre cadenas de suministro de software, depender de una librería externa mantenida por un único proveedor aumenta el riesgo. Los equipos que apuestan por nimcore deberían documentar la dependencia como parte del SBOM y vigilar activamente si el mantenedor continúa publicando releases.

## TYPO3 v12 funciona, la compatibilidad con v13 depende de la capa de abstracción Extbase

nimcore se basa en el framework Extbase y está, por tanto, fuertemente ligado a la estabilidad de su API. En TYPO3 v12 la versión actual corre estable. Para v13 serán necesarias adaptaciones si el core de TYPO3 cambia interfaces Extbase o reestructura la configuración de inyección de dependencias.

Como nimcore es un producto de nicho para la familia de extensiones NIM, su evolución depende directamente del mantenedor. Los equipos que apuestan por nimcore deberían hacer fork del código fuente y mantenerlo en un repositorio propio, para no depender de ciclos de release externos. Gosign recomienda, en portafolios de extensiones personalizadas, construir la arquitectura shared kernel de forma interna y mantenerla bajo control propio, en lugar de confiar en librerías core externas.

--- OIDC TYPO3 - OpenID Connect SSO | Gosign ---
> OpenID Connect para TYPO3: Azure AD, Keycloak, Okta SSO. Configuración, mapeo de claims y resolución de problemas. Acelerado con IA.

## Cómo los proyectos TYPO3 se conectan a Azure AD, Keycloak u Okta sin stack de identidad propio

En cualquier empresa que utilice Microsoft 365, Google Workspace o un Keycloak central, la gestión de usuarios ya está decidida: todas las cuentas de empleados viven en el IdP, y cada aplicación nueva debe conectarse ahí en lugar de gestionar sus propias contraseñas. La extensión OIDC para TYPO3 cubre exactamente ese patrón incorporando OpenID Connect como protocolo de autenticación en TYPO3 y haciendo utilizables como IdP Azure AD, Keycloak, Okta, Google Workspace o Auth0, sin necesidad de operar un Shibboleth SP propio. El público objetivo son portales corporativos, intranets, áreas de login para clientes y cualquier instalación TYPO3 que deba encajar en paisajes enterprise de identidad existentes.

## Escenarios típicos de uso

Un grupo industrial español con 14.000 empleados opera su intranet sobre TYPO3. El departamento de IT ha decidido hace tiempo que cada aplicación nueva debe autenticarse contra Azure AD y aplicar allí la autenticación multifactor. La extensión OIDC obtiene los ID tokens de Azure AD, lee las asignaciones de grupos contenidas en el claim y genera a partir de ahí grupos fe_user. La intranet consigue Single Sign-On, MFA y Conditional Access sin infraestructura adicional, simplemente mediante una configuración limpia.

Un segundo escenario proviene de empresas medianas: un proveedor de software con un portal de clientes sobre TYPO3 utiliza Keycloak como broker central porque sus propios clientes acceden con usernames o con Social-Logins como Google o GitHub. Keycloak unifica eso y habla OIDC hacia afuera. TYPO3 utiliza la extensión OIDC y obtiene acceso a todas las variantes de login sin tener que saber que, por detrás, se trata de un Social-Login.

El tercer caso son administraciones estatales y autonómicas que cambian a cuentas ciudadanas basadas en Keycloak. Un portal TYPO3 a través del cual los ciudadanos envían solicitudes puede conectarse al Keycloak autonómico mediante la extensión OIDC. El atributo eID del broker acaba directamente en el fe_user, y el nivel de autenticación puede evaluarse mediante el acr-claim.

## Arquitectura técnica: Authorization Code Flow en TYPO3

OpenID Connect es una capa de autenticación sobre OAuth 2.0, y la extensión OIDC implementa exactamente el Authorization Code Flow. El proceso es más sencillo que SAML: TYPO3 redirige al usuario mediante un Authorization Request al IdP, recibe tras un login exitoso un código, lo intercambia en el servidor por un ID token y valida la firma mediante el JSON Web Key Set (JWKS) del proveedor. Los claims del ID token, típicamente sub, email, name, groups y roles, se mapean sobre campos de usuario TYPO3.

La extensión se configura mediante la configuración de extensión de TYPO3 y un discovery endpoint que todo proveedor compatible con OIDC ofrece bajo /.well-known/openid-configuration. La extensión lee de esa URL los token endpoints, la URL JWKS y los flows soportados automáticamente, lo que reduce errores manuales. El claim mapping se realiza mediante una configuración YAML o TypoScript que mapea nombres de campos locales a rutas de claims.

## Problemas frecuentes y soluciones

El primer problema afecta a los formatos de claim: Azure AD entrega los grupos como IDs de objeto (GUIDs), no como nombres legibles. Quien espera un claim group_ids y recibe group_names ve grupos de usuarios vacíos en TYPO3. La solución limpia está en la propia aplicación de Azure AD: en el token configuration blade puede definirse qué atributos se exponen como claims y, adicionalmente, un conjunto de reglas de claim transformation puede traducir GUIDs a nombres legibles.

El segundo problema es la Redirect URI. Todo cliente OIDC debe registrar en el IdP exactamente la Redirect URI a la que será enviado tras el login. Diferencias en mayúsculas y minúsculas, trailing slashes olvidadas o un cambio de HTTP a HTTPS provocan fallos de login inmediatos que no aparecen en el log de TYPO3 porque el error ocurre en el IdP. Gosign configura clientes separados para staging y producción con Redirect URIs limpias y documenta cada cambio en el proceso de despliegue.

El tercer tema es el token refresh. Quien quiere sesiones más largas necesita Refresh Tokens, que el IdP solo emite si se ha solicitado el scope offline_access en el login. Sin ese scope, la sesión de TYPO3 termina en cuanto caduca el ID token, normalmente al cabo de una hora. La configuración en el backend de la extensión debe, por tanto, incluir el scope offline_access y activar la lógica de token refresh.

Un cuarto problema afecta al cierre de sesión. OIDC conoce Front-Channel y Back-Channel Logout, y ninguno de los dos está necesariamente activado en la extensión. Quien espera un verdadero Single Logout a través de varias aplicaciones debe configurar el End Session Endpoint correspondiente del proveedor y asegurar que TYPO3 llame a la URL de logout del IdP al final de la sesión. Sin esa configuración, el usuario permanece conectado en el IdP aunque haya cerrado sesión en TYPO3.

## Migración y compatibilidad de versiones

La extensión OIDC es actualmente el estándar recomendado para TYPO3 v12 y v13, mientras que proyectos más antiguos en v11 siguen apoyándose con frecuencia en implementaciones OAuth caseras o en shibboleth_auth. La ruta de migración de Shibboleth a OIDC está bien establecida, siempre que el IdP hable ambos: Keycloak, ADFS y Azure AD pueden servir SAML y OIDC en paralelo, de modo que una transición sin Big Bang es posible.

Quien migra desde una gestión de fe_users meramente basada en base de datos debe mapear las cuentas existentes con una estrategia de matching contra los claims OIDC. La dirección de correo es el anclaje habitual, pero no siempre basta, porque los correos pueden cambiar. Un sub-claim, almacenado en el fe_user como identificador persistente unívoco, es la solución más robusta. Gosign asume estas migraciones incluyendo la conciliación de cuentas existentes y una fase de transición en la que ambos caminos de autenticación funcionan en paralelo.

Para equipos que están montando un proyecto TYPO3 nuevo, OIDC es en la gran mayoría de los casos la primera opción. La configuración es más ligera que en SAML, el esfuerzo de cliente menor y todo IdP moderno soporta el protocolo de forma nativa. Las excepciones solo están justificadas cuando requisitos regulatorios o federativos exigen explícitamente SAML, como en las federaciones universitarias mencionadas. En todos los demás escenarios, sobre todo con IdPs en la nube e integraciones enterprise, OIDC ofrece el mejor compromiso entre sencillez, seguridad y mantenibilidad.

--- OpenImmo TYPO3 - Importación inmobiliaria | Gosign ---
> OpenImmo: estándar XML alemán para intercambio de datos inmobiliarios. Importar propiedades automáticamente en TYPO3. Acelerado con IA.

## Por qué las webs inmobiliarias sin integración OpenImmo generan doble trabajo

Los agentes inmobiliarios gestionan sus propiedades en software de administración como FlowFact, onOffice, ImmoTool o JustImmo. Cada propiedad con fotos, precios, superficies y descripciones de ubicación. Estos datos deben aparecer también en la web, pero sin doble introducción manual. OpenImmo es el estándar XML del sector que tiende exactamente ese puente: el software del agente exporta propiedades como XML, TYPO3 las importa automáticamente y las muestra en la web.

Sin integración OpenImmo, una oficina con 40 propiedades activas mantiene cada exposé por duplicado - una vez en el software de gestión y otra en la web. Con un tiempo medio de 15 minutos por propiedad, eso supone 10 horas al mes solo en mantenimiento de datos que una pipeline automatizada elimina por completo.

## Escenarios de uso habituales

**Importación automatizada para webs de agencias.** Una oficina inmobiliaria con 30 a 100 propiedades activas opera su web en TYPO3. Cada noche, onOffice exporta todas las propiedades como XML OpenImmo a un servidor FTP. Una tarea del Scheduler TYPO3 obtiene el archivo XML, lo parsea y actualiza las propiedades en la base de datos. A la mañana siguiente, la web está automáticamente actualizada.

**Portales inmobiliarios con agregación multi-proveedor.** Una plataforma inmobiliaria regional agrega propiedades de 10 a 30 agentes. Cada agente entrega sus propiedades en formato OpenImmo. TYPO3 importa todos los feeds, asigna las propiedades a los respectivos proveedores y las muestra en una plataforma común con búsqueda y filtrado unificados.

**Webs de promotores con resumen de viviendas.** Un promotor vende 50 unidades en un proyecto de obra nueva. Las disponibilidades y precios se gestionan en el software de administración. Mediante importación OpenImmo, la web TYPO3 actualiza automáticamente el estado de cada unidad: disponible, reservada o vendida.

## Arquitectura técnica

La integración OpenImmo en TYPO3 consta de cuatro componentes: XML Parser (lee el archivo OpenImmo XML y lo convierte en objetos PHP; el esquema define más de 200 campos por propiedad), Pipeline de importación (tarea del Scheduler o comando CLI que ejecuta la importación periódicamente: descarga de archivo, validación XML, mapeo de propiedades, importación de imágenes, comparación de diferencias), Presentación frontend (plugin Extbase que muestra propiedades como lista con filtrado y como vista de detalle con galería, mapa e información de contacto) y Generación de exposés (opcionalmente las páginas de detalle se descargan como exposé PDF).

## Problemas frecuentes y soluciones

**La importación falla con errores de parseo XML.** El software del agente a veces exporta XML no conforme al esquema. Campos obligatorios ausentes, codificación de caracteres inválida (ISO-8859-1 en lugar de UTF-8) o tags no cerrados causan la interrupción. Solución: implementar un paso de preprocesamiento XML que valide el archivo antes de la importación, corrija problemas de encoding y rellene campos obligatorios ausentes con valores por defecto.

**Las imágenes no se importan correctamente.** OpenImmo XML referencia imágenes mediante rutas relativas o URLs. Si la carga FTP coloca las imágenes en un directorio distinto al esperado por el XML, las referencias de imagen quedan vacías. Solución: configurar la importación para buscar imágenes relativas al directorio XML e implementar un fallback de coincidencia por nombre de archivo.

**Las propiedades eliminadas siguen visibles en la web.** OpenImmo conoce dos formas de marcar propiedades como vendidas/eliminadas: mediante campo de estado en el XML o omitiendo la propiedad en la siguiente exportación. No todas las extensiones de importación soportan ambas variantes. Solución: configurar la importación como comparación completa - las propiedades ausentes en la exportación XML actual se marcan automáticamente como "vendidas" o se archivan.

## Migración y compatibilidad de versiones

Para OpenImmo en TYPO3 existen varias extensiones. La mayoría están disponibles para TYPO3 v10 y v11. Para TYPO3 v12 y v13, la selección es más limitada ya que algunas extensiones no se mantienen activamente.

El formato OpenImmo es estable. La versión 1.2.7 es desde hace años el estándar de facto. Gosign recomienda, al actualizar TYPO3 de v10/v11 a v12, evaluar la extensión OpenImmo existente. Si el mantenedor ya no está activo, vale la pena cambiar a una pipeline de importación desarrollada a medida con PHP moderno. El esfuerzo inicial es de 5 a 8 días, pero la pipeline es independiente de extensiones de terceros y mantenible a largo plazo.

--- Paywall TYPO3 - Monetización de contenido | Gosign ---
> Paywall para TYPO3: contenido de pago, modelos de suscripción, control de acceso. Desarrollo personalizado con IA, nivel enterprise.

## Una paywall en TYPO3 no es un asunto de plug-in, sino una decisión de arquitectura

El contenido de pago en TYPO3 parece a primera vista una pregunta banal: unas cuantas páginas detrás de un login, un proveedor de pagos por delante, listo. En la práctica, la tarea resulta ser una de las más exigentes del entorno TYPO3. El núcleo no conoce el concepto nativo de contenido de pago, y las pocas extensiones libremente disponibles cubren, en el mejor de los casos, escenarios de login sencillos. Quien quiere monetizar contenido en serio (Metered Paywall, Hard Paywall, Freemium, suscripciones escalonadas) acaba en un desarrollo a medida.

El público son típicamente editoriales, portales especializados y proveedores de contenido B2B. Una editorial especializada con 4.000 artículos premium al año no solo necesita una comprobación de acceso, sino también un ciclo de vida de suscripción, un proceso de baja, una presentación jurídicamente sólida del derecho de desistimiento, una interfaz con contabilidad y un reporting para la redacción. Todo eso quiere representarse en una instalación TYPO3 existente sin que la redacción tenga que aprender una nueva interfaz de CMS.

## Escenarios típicos de uso

Un primer escenario es la Metered Paywall de un grupo editorial regional. El grupo publica 500 artículos de pago al mes y quiere ofrecer a los lectores anónimos tres artículos al mes gratis antes de que entre en juego la paywall. El conteo se realiza mediante una cookie firmada que funciona también sin login, y el desbloqueo corre a través de un sistema de tienda existente con suscripción mensual.

Un segundo escenario es la Hard Paywall en una editorial técnica B2B. Aquí no hay artículos gratuitos; cada acceso exige un contrato activo. El reto está en la combinación de suscripción individual, suscripción corporativa y acceso tipo campus basado en IP. La integración TYPO3 debe comprobar en tiempo real si una lectora dispone de un contrato vigente y poner los resultados disponibles con buen rendimiento para la navegación, la búsqueda y los feeds RSS.

Un tercer escenario es el modelo freemium de un portal sectorial. Registrarse es gratis, determinadas herramientas premium (descarga de whitepaper, informe de benchmark, calculadora interactiva) requieren una suscripción de pago. La paywall debe decidir por cada elemento de contenido si hay acceso y conectar la gestión del pago incluyendo facturación.

Un cuarto escenario es la página para clientes anunciantes de un grupo de medios. Aquí se trata menos de clientes finales que de agencias que quieren consultar un área de datos de medios. El acceso se controla típicamente mediante un registro único más una autorización manual del departamento comercial. TYPO3 refleja el estado de la autorización en el perfil del usuario y libera el área protegida en cuanto el estado pasa a "autorizado".

## Arquitectura técnica

Una paywall apta para producción en TYPO3 consta de varias capas. Al frente hay una middleware que comprueba en cada petición de contenido si el acceso está permitido. Esa middleware recurre a una policy de acceso que reúne suscripciones, compras individuales y cupos gratuitos. Por debajo hay una capa de persistencia con datos maestros de suscripción, historial de pago y estado contractual que se sincroniza con el proveedor de pagos externo (Stripe, PayPal, Mollie, Adyen).

Para la parte de contenido hay dos variantes: o bien el contenido se trunca en el servidor y solo se renderiza la parte permitida para la lectora, o bien el texto completo se entrega y una capa overlay de paywall se controla mediante marcado del lado del servidor. La segunda variante es peligrosa, porque herramientas de navegador pueden eludir el overlay. Las paywalls profesionales trabajan siempre del lado del servidor.

La integración con TYPO3 se realiza mediante extensiones Extbase con middlewares propias del frontend, TCA overrides para el estado de paywall por elemento de contenido y endpoints REST para los webhooks de pago. Las middlewares PSR-15 son desde TYPO3 v9 el lugar limpio para interceptar requests.

## Problemas frecuentes y soluciones

El primer problema es la posibilidad de eludirla a través del caching. Quien activa el page cache de forma general entrega el texto completo de un artículo de pago a un proxy y, a partir de ahí, a cualquier lector no autorizado. La solución es un caching claramente separado por rol de usuario o una excepción del contenido de paywall respecto al page cache.

El segundo problema son las race conditions en el ciclo de vida de la suscripción. Al cancelar y facturar simultáneamente surgen estados inconsistentes cuando el orden de escritura entre TYPO3 y proveedor de pagos no está serializado de forma limpia. La solución es un event store para eventos de suscripción con una fuente de la verdad definida (normalmente el proveedor de pagos) y un proceso de importación idempotente.

El tercer problema es la caída de conversión por comprobaciones de paywall lentas. Cada milisegundo de latencia cuesta cierres. La solución son comprobaciones de acceso asíncronas con un token de sesión firmado que evita consultas a base de datos costosas.

Un cuarto problema son las condiciones fiscales y legales. Los ingresos por suscripción están sujetos a IVA, los derechos de desistimiento deben formularse correctamente en relaciones contractuales de tracto sucesivo, y en suscripciones transfronterizas entran en juego distintos regímenes de IVA. La Agencia Tributaria española vigila especialmente estos puntos en inspecciones. La solución es coordinar desde el principio la arquitectura de la paywall con contabilidad y asesoría jurídica y apoyar la gestión de pagos en un proveedor que asuma la gestión fiscal y de facturación.

## Migración y compatibilidad de versiones

Como las paywalls en TYPO3 nacen como desarrollos a medida, la compatibilidad de versiones depende por completo del equipo de desarrollo. Una extensión de paywall construida limpiamente corre en TYPO3 v11 a v13 si se apoya en middlewares PSR, Dependency Injection y convenciones Extbase modernas. Los problemas aparecen con deudas técnicas que todavía se apoyan en integraciones basadas en hooks de TYPO3 v7/v8.

En los upgrades de una paywall existente se recomienda una migración en dos etapas. En el primer paso se elevan los clientes de API de pago y las middlewares de acceso a convenciones TYPO3 modernas, sin modificar la lógica de negocio. En el segundo paso siguen los ajustes de contenido como nuevos modelos de suscripción, un conteo metered modificado o proveedores de pago adicionales. Esa separación reduce claramente el riesgo de ruptura por regresión y permite probar limpiamente cada paso en un entorno de staging.

Gosign construye y moderniza sistemas de paywall para editoriales y proveedores de contenido. La combinación de generación de código asistida por IA para la conexión con la API de pago y la revisión senior para seguridad, cumplimiento PCI y prevención de race conditions acorta perceptiblemente el time to market sin que la calidad de la arquitectura se resienta.

--- PDF.js TYPO3 - Visor de PDF | Gosign ---
> Integración de PDF.js Viewer para TYPO3. Mostrar PDFs en el navegador sin plugin, sin descarga.

## PDF.js incrusta el visor probado de Mozilla directamente en páginas TYPO3 y es la solución ligera cuando los redactores quieren mostrar PDF en el navegador sin forzar la descarga y sin el peso de un flipbook

Cuando los visitantes hacen clic en un PDF, el navegador lo abre en una pestaña nueva, lo descarga o lo deriva a un visor externo. Ninguna de esas variantes satisface a los redactores que quieren presentar un documento en el contexto de una página. PDF.js lo resuelve integrando el visor que Firefox y Chrome utilizan internamente como un módulo JavaScript autónomo directamente en la página TYPO3. El resultado es una visualización consistente en todos los navegadores y dispositivos, sin que los usuarios tengan que instalar un plugin ni abandonar el documento.

Una ventaja pasada a menudo por alto: el usuario no deja la página. Mientras que un PDF abierto en una nueva pestaña suele significar el fin de la sesión, el visor incrustado mantiene la conexión analítica. Quien mide cuánto tiempo pasan los visitantes realmente leyendo un documento puede atribuir ese tiempo directamente a la página de contenido y ver qué documentos se leen de verdad.

## Escenarios típicos de uso

El caso de uso más frecuente es la incrustación de documentos individuales en páginas de contenido: un white paper en una página de producto, un formulario de solicitud en una página de servicio o un programa de jornada junto a la descripción del evento. La redacción sube el PDF al FAL y lo referencia mediante un elemento de contenido; PDF.js lo renderiza inline. Al hacerlo, la identidad visual de la página se mantiene, porque marcos, sombras y controles se estilizan mediante la plantilla del sitepackage propio.

El segundo caso son los centros de descargas donde varios PDF se presentan mediante una vista previa. En lugar de iconos ciegos de archivo, los usuarios ven la primera página del documento y pueden decidir con un clic si siguen leyendo o inician la descarga completa. Para catálogos, formularios y fichas informativas, esa vista previa es a menudo el factor decisivo para que un documento llegue siquiera a ser pulsado.

Tercer caso: la puesta a disposición con baja barrera de documentos de administraciones e universidades. PDF.js expone la capa de texto del PDF, de modo que los lectores de pantalla pueden leer el contenido, siempre que el PDF se haya exportado correctamente como "Tagged PDF".

## Arquitectura técnica

Para TYPO3 PDF.js existe en dos variantes: como extensión TYPO3 clásica que entrega la librería JavaScript y amplía el backend con un elemento de contenido, o como integración puramente de sitepackage, en la que los assets de PDF.js acaban directamente en el build del frontend propio. La variante extensión es más cómoda para los redactores, porque pueden configurar selección, zoom por defecto y parámetros de vista previa mediante el backend de TYPO3. La variante sitepackage es más limpia para los desarrolladores, porque controla la versión y se integra en el proceso de build existente.

Técnicamente PDF.js consta de dos partes: un parser que carga el archivo PDF y lo descompone en un grafo de objetos interno, y un viewer que renderiza esos objetos en un elemento Canvas. Ambas partes corren completamente del lado del cliente. El enfoque worker garantiza que el parseo ocurra en un hilo aparte y no bloquee el main thread, lo que es importante para un scroll fluido en documentos extensos.

La integración se realiza mediante un bloque TypoScript y un partial Fluid que incluye un iframe o un contenedor con el viewer. La URL del PDF se pasa como query parameter; la configuración de los elementos de interfaz (botones de zoom, navegación de páginas, enlace de descarga) se realiza mediante el bloque de configuración del viewer de PDF.js.

## Problemas frecuentes y soluciones

El primer problema es Cross-Origin. Cuando el PDF se carga desde otro dominio o desde un bucket S3, el navegador bloquea el acceso por motivos de seguridad. La solución es o bien una configuración CORS correcta en el file server o bien un proxy del lado del servidor mediante una middleware TYPO3 que entregue el PDF bajo el mismo dominio.

Segundo problema: rendimiento con documentos grandes. Un manual de 200 páginas carga rápido, el viewer solo muestra las páginas visibles. Se vuelve problemático cuando el propio PDF no está optimizado para la web y cada imagen se ha incrustado en plena resolución de impresión. Aquí solo ayuda reducir el documento original previamente con Ghostscript o una herramienta equivalente antes de que entre al FAL.

Tercer problema: accesibilidad sin capa de texto. Si el PDF es un escaneo puro sin OCR, los lectores de pantalla no reciben texto. Entonces PDF.js por sí solo no sirve de nada: el PDF debe pasar antes por una pasada de OCR. Para administraciones y organismos públicos eso no es una opción, sino una obligación según el Real Decreto 1112/2018 sobre accesibilidad web y la EN 301 549.

## Migración y compatibilidad de versiones

PDF.js como librería la mantiene Mozilla de forma continua y es en principio independiente de la versión de TYPO3. Las envolturas de extensión TYPO3 que integran PDF.js van a menudo por detrás de la versión de la librería. Quien actualiza a TYPO3 v12 o v13 debería comprobar si la extensión utilizada tiene una versión compatible o si un cambio a la integración en el sitepackage es el mejor camino.

En comparación directa con pdfviewhelpers (generación de PDF en el servidor) y rflipbook (efecto flipbook), PDF.js es la opción con menor sobrecarga y mayor compatibilidad entre navegadores. Para incrustaciones individuales de PDF casi siempre es mejor elección que una solución flipbook pesada.

Quien integra PDF.js directamente en el sitepackage debería fijar una estrategia de versiones clara. La librería recibe actualizaciones de seguridad periódicas, porque los parsers PDF son históricamente un objetivo de ataque muy habitual. Un ritmo anual de actualización es el mínimo; para administraciones e infraestructuras críticas, más bien trimestral. La integración vía npm y un proceso de build de frontend lo hace mucho más fácil que la clásica copia al directorio del proyecto.

Gosign integra PDF.js como componente del sitepackage o como extensión TYPO3, según cuánta control necesiten los redactores. En proyectos existentes con visores legacy, Gosign acompaña la migración y se asegura de que la accesibilidad y el tiempo de carga no se sacrifiquen al confort.

--- pdfviewhelpers TYPO3 - PDF en el navegador | Gosign ---
> pdfviewhelpers: mostrar PDFs directamente en el navegador. Configuración, rendimiento y alternativas, acelerado con IA.

## pdfviewhelpers es la respuesta estándar cuando TYPO3 debe generar PDF en el servidor a partir de plantillas Fluid, desde facturas hasta tickets y reports completos

Tras el nombre "pdfviewhelpers" se esconde una confusión frecuente. La extensión no renderiza PDF en el navegador: genera PDF en el servidor a partir de plantillas Fluid. Los redactores y desarrolladores que buscan una solución para la generación dinámica de PDF en TYPO3 aterrizan aquí con razón: facturas, tickets, confirmaciones, certificados o informes se construyen con los mismos ViewHelpers Fluid que también sirven al frontend. El objetivo es mantener la generación de PDF sin herramientas externas y sin un flujo de maquetación separado dentro del stack TYPO3.

Que la extensión, con ello, resuelve un problema muy distinto al de PDF.js o rflipbook suele quedar claro tarde en la práctica. Quien busca "TYPO3 PDF" acaba pronto en pdfviewhelpers y debería preguntarse pronto si necesita visualización o generación. Para la generación, la extensión es la solución técnicamente más sólida en el entorno TYPO3, porque se apoya en el paradigma Fluid que los desarrolladores ya dominan.

## Escenarios típicos de uso

El caso clásico son las confirmaciones de formulario. Un cliente rellena en una página TYPO3 un formulario de contacto, una inscripción a evento o una solicitud de presupuesto, y pdfviewhelpers genera a partir de las entradas un PDF personalizado que se envía por correo o se ofrece como descarga. La plantilla está como fichero Fluid en el sitepackage, los redactores adaptan texto y marcadores de posición sin tener que tocar el código. La ventaja frente a un servicio externo de PDF es que ningún dato abandona el entorno TYPO3, algo relevante para protección de datos y conformidad con el RGPD que la AEPD valora en auditorías.

El segundo uso típico son los certificados generados automáticamente. Proveedores de formación, colegios profesionales y asociaciones hacen generar certificados de asistencia, diplomas o tarjetas de socio a partir de contenidos de base de datos. La extensión combina datos Extbase con plantillas de maquetación y entrega un documento terminado. Una gran ventaja: la plantilla está versionada, es rastreable en Git y no depende de una única persona que tiene la última plantilla Word.

Tercer caso: informes y listados. Los departamentos de controlling exportan desde una base de datos gestionada en TYPO3 un informe mensual - como export de un cuadro de mando interno, de una lista de productos o de una lista de almacén - y reciben un PDF maquetado con cabecera, pie y paginación.

## Arquitectura técnica

pdfviewhelpers se basa en TCPDF, la librería PHP establecida para la generación de PDF, y traduce sus funciones a ViewHelpers Fluid. Los desarrolladores escriben, en lugar de código PHP TCPDF, una plantilla en la que elementos como "pdf:document", "pdf:page", "pdf:text" y "pdf:image" aparecen como etiquetas. Eso corresponde exactamente a la forma de pensar que los desarrolladores Fluid conocen del frontend.

La extensión se instala mediante Composer y TCPDF se arrastra como dependencia. Las plantillas están en el sitepackage bajo Resources/Private/Templates/Pdf y se llaman mediante un controlador propio o directamente desde una Extbase Action. Para la inyección de variables, pdfviewhelpers utiliza los mismos mecanismos que las vistas Fluid regulares, lo que permite separar limpiamente fuentes de datos y lógica de negocio.

La configuración corre por TypoScript y por la configuración de extensión en el Install Tool, donde se fijan defaults para formato de papel, tipografías y márgenes. Quien quiera usar fuentes TrueType propias debe convertirlas con el procedimiento TCPDF y colocarlas en Resources/Private/Fonts/.

## Problemas frecuentes y soluciones

El problema más frecuente es la representación de fuentes. TCPDF no soporta de fábrica cualquier archivo de fuente, especialmente no las Variable Fonts actuales ni las web fonts en formato WOFF2. Diéresis, caracteres especiales y diacríticos acaban sustituidos por signos de interrogación o cajas. Solución: convertir la fuente previamente con la herramienta TCPDF "tcpdf_addfont.php" y comprobar el rango Unicode. Para documentos multilingües con caracteres cirílicos o asiáticos merece la pena usar una familia de fuente con amplia cobertura de glifos como Noto Sans.

Segundo problema: maquetaciones complejas. En cuanto un documento necesita contenidos a varias columnas, gráficos flotantes o saltos dinámicos, TCPDF choca con sus límites. Paginación y pie pueden dejar de sincronizarse correctamente. Solución pragmática: reducir la maquetación a una estructura simple, tipo reporte, e incluir los gráficos complejos como imágenes prefabricadas. Si los requisitos son realmente exigentes desde el punto de vista tipográfico, una alternativa como Headless Chrome con conversión HTML a PDF suele ser la mejor opción.

Tercer problema: rendimiento con documentos grandes. Un informe de 100 páginas con muchas imágenes puede bloquear el proceso PHP varios segundos. La solución está en el procesamiento por cola: sacar la generación de PDF del ciclo de vida del request, ejecutarla como background job con EXT:scheduler o una extensión de cola y enviar al usuario un enlace de descarga por correo.

## Migración y compatibilidad de versiones

pdfviewhelpers se mantiene continuamente y es compatible con TYPO3 v11, v12 y v13. En los upgrades hay que prestar atención sobre todo al salto de versión de PHP: las versiones antiguas de TCPDF tienen problemas de compatibilidad con PHP 8.2 y 8.3, especialmente con los warnings de deprecated. La solución suele ser una actualización de la versión de pdfviewhelpers, que arrastra la versión compatible de TCPDF.

Quien todavía opera una configuración TCPDF hecha a medida heredada de la era TYPO3 pre-v9, tiene con la migración a pdfviewhelpers la oportunidad de trasladar las maquetaciones PDF desde código PHP a plantillas Fluid mantenibles. Eso compensa a medio plazo, porque los redactores pueden hacer ajustes sencillos ellos mismos en lugar de bloquear siempre tiempo de desarrollador.

Para puestas en marcha nuevas merece la pena echar un vistazo a la combinación de pdfviewhelpers con alternativas Headless Chrome como wkhtmltopdf o Gotenberg. Para PDF de formularios puros e informes sencillos, pdfviewhelpers es la opción más rápida y estable. En cuanto entran en juego maquetaciones tipográficamente exigentes con web fonts, columnas y gráficos de fondo, un pipeline basado en HTML juega sus bazas. La decisión debería tomarse pronto en el proyecto, porque un cambio tardío de pipeline exige una reconstrucción completa de las plantillas.

Gosign implementa pdfviewhelpers, migra configuraciones TCPDF legacy y asesora sobre alternativas para maquetaciones complejas. La combinación de experiencia TYPO3 y generación de plantillas asistida por IA acorta la implementación en más de la mitad por regla general.

--- personnel TYPO3 - Directorio de empleados | Gosign ---
> Extensión de TYPO3 para directorios de empleados. Equipos, departamentos, datos de contacto, fotos de perfil.

## personnel organiza los directorios de empleados como modelo de datos propio

Las páginas de equipo, las listas de contactos y los directorios departamentales son estándar en sitios corporativos, pero no pueden mantenerse razonablemente como elemento de contenido. Quien gestiona 50 empleados con nombre, función, foto, teléfono, correo, LinkedIn, departamento y ubicación necesita un modelo de datos propio. La extensión personnel aporta exactamente eso: una tabla limpia para personas, conectada con departamentos y ubicaciones, servida a través de plantillas Fluid configurables. En cualquier proyecto TYPO3 de tamaño medio con presencia corporativa ese requisito aparece de forma recurrente, y personnel es una de las soluciones establecidas. Alternativas como tt_address se quedan a menudo cortas porque les falta la estructura departamental, la lógica de filtrado y la integración limpia en el frontend.

## Escenarios típicos: despachos, agencias y universidades

Los despachos de abogados son un caso de uso clásico. Un despacho con 30 abogados y 10 auxiliares necesita una página de equipo con filtrado por áreas de especialización (derecho laboral, derecho fiscal, derecho sucesorio), por sedes (Madrid, Barcelona, Valencia) y por función (socio, asociado, becario). personnel aporta el modelo de datos, y con pocas adaptaciones Fluid la extensión puede convertirse en un directorio de despacho de pleno derecho. Cada perfil de abogado contiene además la colegiación, las membresías y los artículos especializados publicados, de modo que los clientes encuentran de un vistazo a la persona de contacto adecuada.

Las agencias y consultoras utilizan personnel para páginas de equipo con biografías breves, áreas de especialización y enlaces de contacto. Aquí menos decisiva es la filtración que la presentación: retratos grandes, citas, botones de LinkedIn y enlaces internos a casos de estudio en los que la persona ha participado. La página de equipo se convierte en escaparate, y personnel aporta el modelo de datos sin que cada empleado reciba su propio elemento de contenido.

Las universidades y los centros de investigación tienen otro requisito: los empleados están a menudo vinculados a institutos, cátedras y proyectos de investigación. personnel se convierte entonces en modelo de datos maestro, referenciado desde artículos de noticia, listas de publicaciones y eventos. La persona no aparece solo en una página de equipo, sino también como autor en publicaciones y como interlocutor en proyectos de investigación. Así la extensión se convierte en la base de datos central de personas que varias subextensiones utilizan simultáneamente y que entrega perfiles consistentes durante años.

## Arquitectura técnica: Extbase con relaciones a departamento y ubicación

personnel define tres tablas centrales: tx_personnel_domain_model_personnel, tx_personnel_domain_model_department y tx_personnel_domain_model_location. Una persona está vinculada, mediante foreign_field o relación MM, a uno o varios departamentos y, adicionalmente, a una ubicación. El schema de base de datos representa así una organización matricial típica.

Los campos de una persona cubren los atributos estándar: título, nombre, apellidos, función, descripción breve, teléfono, móvil, fax, correo, dirección, foto de perfil (FAL), enlaces a redes sociales. Mediante TCA overrides pueden añadirse campos adicionales como áreas de especialización, certificados o idiomas sin forkear la extensión.

El plugin renderiza mediante plantillas Fluid del directorio EXT. Las variantes estándar son lista, detalle y vista filtrada. Quien se apoya en sistemas de rejilla como CSS Grid o Flexbox, sobrescribe la plantilla de lista en el paquete propio. Para filtrado y búsqueda la extensión utiliza repositorios Extbase con filtros Query Builder configurables por TypoScript. Una implementación Gosign típica ofrece en el frontend una búsqueda de texto completo sobre nombre y función, combinada con filtros select para departamento y ubicación, de modo que los usuarios encuentran entre 200 empleados al interlocutor correcto en pocos clics.

## Problemas frecuentes: RGPD, derechos de imagen y multilingüismo

El primer y más importante tema de soporte es el RGPD. Los datos de empleados son personales, y la publicación requiere o bien un consentimiento o un interés legítimo. La AEPD ha sancionado repetidamente a empresas que publicaron datos de trabajadores sin base jurídica adecuada. Quien trabaja con fotos, extensiones telefónicas y números móviles privados necesita un proceso limpio: documentar el consentimiento, interruptor on/off por persona, eliminación automática al cese. personnel no entrega de fábrica un audit log, pero el flujo puede cubrirse con formularios propios y un campo adicional de consentimiento. Al causar baja en la empresa el registro no debería borrarse simplemente, sino quedar desactivado mediante un mecanismo de soft delete, de modo que las noticias antiguas sigan resolviendo correctamente.

El segundo tema son los derechos de imagen. Las fotos de perfil están en FAL y se entregan en variantes por representación. Es importante que la atribución de copyright y el consentimiento del empleado queden documentados, especialmente cuando la imagen se usa también como teaser en noticias o en redes sociales. Recomendamos mantener con constancia los campos FAL "fotógrafo/a" y "licencia".

En tercer lugar, el multilingüismo es un problema práctico. Una persona tiene un nombre, pero su función y su biografía breve cambian entre español e inglés. personnel soporta el estándar TYPO3 para traducciones, pero muchos proyectos olvidan localizar también los registros de departamento y ubicación, lo que lleva a salidas de idioma mezcladas.

## La migración a TYPO3 v12 exige actualización de Extbase y revisión del TCA

personnel está disponible para distintas versiones de TYPO3 en el TER. Al actualizar una instalación v10 o v11, los repositorios Extbase deben adaptarse a la API de persistencia actual, y la estructura TCA debería revisarse frente a incompatibilidades de tipo (especialmente en campos "passthrough" y "none", que en v12 se validan de forma más estricta).

Gosign migra instalaciones de personnel a menudo en el marco de un refactoring de páginas de equipo. En el mismo paso comprobamos si el fondo de datos puede elevarse a un schema Person más moderno (con marcado JSON-LD), si el filtrado y la búsqueda manejan con buen rendimiento grandes conjuntos de datos y si la página de equipo se sirve de forma responsive y accesible. Para proyectos con conjuntos de datos extremadamente grandes (varios miles de personas) merece la pena además revisar la indexación y el lazy loading, para que la vista de lista no se convierta en cuello de botella en dispositivos móviles. En estructuras de equipo especialmente complejas sustituimos ocasionalmente personnel por un modelo Extbase personalizado cuando la estructura de campos estándar no basta o cuando se exige una conexión a un sistema externo de recursos humanos.

--- PhotoSwipe TYPO3 - Lightbox | Gosign ---
> Integración de PhotoSwipe Lightbox para TYPO3. Galerías de imágenes responsive con gestos táctiles, zoom y navegación.

## Las galerías de imágenes en dispositivos móviles solo funcionan con lightboxes optimizadas para táctil

La mayoría de webs TYPO3 usan lightboxes pensadas para navegadores de escritorio: Fancybox, Colorbox, Magnific Popup. En smartphones y tabletas esas soluciones se sienten ajenas, porque el zoom y la navegación no responden a gestos táctiles, sino a clics de ratón. PhotoSwipe es una librería JavaScript construida desde cero para táctil. La extensión TYPO3 integra PhotoSwipe como una galería de imágenes completa con pinch-to-zoom, navegación por swipe, deep linking y layout responsive. Con menos de 30 KB (minificada y con gzip), PhotoSwipe es al mismo tiempo una de las soluciones de lightbox más ligeras del mercado.

Para webs con un alto porcentaje de tráfico móvil, es decir, prácticamente todas hoy, no es una mejora opcional, sino un requisito funcional. Los visitantes esperan los mismos gestos que conocen de la app de fotos nativa de su smartphone.

## Los escenarios típicos incluyen galerías de portfolio, imágenes de producto y archivos de medios

El escenario más frecuente son las galerías de portfolio en webs de agencias, estudios de arquitectura o fotografía. Un fotógrafo muestra de 20 a 40 imágenes por proyecto. Los visitantes hacen clic en una miniatura, ven la imagen en resolución completa, hacen zoom con pinch y deslizan a la siguiente imagen. Deep linking significa que cada imagen tiene su propia URL, compartible o enlazable. Eso es relevante para SEO, porque Google puede indexar las imágenes a través de las URLs deep link.

Un segundo escenario son las páginas de detalle de producto en instalaciones TYPO3 cercanas al e-commerce. Un fabricante de muebles muestra cinco perspectivas por producto. PhotoSwipe las renderiza como galería con zoom de alta resolución, que en escritorio se activa con la rueda del ratón y en táctil con doble toque. La calidad del zoom depende directamente de la resolución de la imagen origen. Recomendamos al menos 2000 píxeles de ancho para imágenes de producto que vayan a examinarse con zoom.

Tercer escenario: archivos de medios y áreas de prensa. Una universidad pone a disposición 500 fotos de eventos. PhotoSwipe renderiza la galería con buen rendimiento, porque las imágenes solo se cargan al hojearse (lazy loading). La vista general de miniaturas muestra 50 imágenes por página sin tiempo de carga apreciable.

## La arquitectura técnica integra PhotoSwipe como elemento de contenido TYPO3

La extensión registra un elemento de contenido propio en el backend de TYPO3. Los redactores seleccionan imágenes desde la mediateca FAL, definen el orden y ponen pies de foto opcionales. El renderizado lo asumen plantillas Fluid que inicializan la librería JavaScript PhotoSwipe y pasan las URLs de las imágenes como array JSON.

PhotoSwipe en sí no tiene dependencias, ni jQuery, ni framework. La librería consiste en un fichero CSS y un fichero JS. La extensión TYPO3 carga ambos vía el AssetCollector de TypoScript, de modo que solo se incluyen en páginas que realmente contienen una galería. Eso evita peticiones innecesarias en páginas sin galería.

Para imágenes responsive, la extensión soporta atributos srcset: el navegador carga, según el viewport, el tamaño de imagen adecuado. El image processing de TYPO3 genera las variantes automáticamente. Combinado con conversión a WebP (ver la extensión webp), las galerías PhotoSwipe alcanzan tiempos de carga óptimos.

Desde el punto de vista del RGPD, la integración es inocua: PhotoSwipe no realiza peticiones a servidores externos, no coloca cookies y no transfiere datos a terceros. Eso es relevante para entidades del sector público y páginas que quieran operar sin banner de consentimiento para esta función.

## Los problemas frecuentes son conflictos con otras extensiones de lightbox y tamaños de imagen faltantes

El problema más frecuente es el conflicto con una extensión de lightbox ya instalada. Si Fancybox y PhotoSwipe están activas simultáneamente, ambas reaccionan al clic sobre imágenes y generan overlays duplicados. La solución: desactivar la extensión de lightbox antigua y retirar sus includes CSS/JS del setup TypoScript. Un grep por "fancybox" o "colorbox" en los ficheros TypoScript muestra si aún se cargan restos de la librería antigua.

Segundo problema: tamaños de imagen faltantes. PhotoSwipe necesita para el zoom las dimensiones reales en píxeles de la imagen. Si la extensión no puede leerlas de los metadatos FAL, el zoom no funciona o salta a un tamaño erróneo. La solución: revisar los metadatos FAL de todas las imágenes de la galería. TYPO3 lee width y height automáticamente al subir, pero imágenes importadas o insertadas vía CLI a veces tienen los metadatos vacíos.

Un tercer tema es la accesibilidad. Conforme a la WCAG 2.1 y al Real Decreto 1112/2018, los contenidos interactivos deben ser manejables por teclado. PhotoSwipe ofrece navegación por teclado (flechas, Escape, Enter) y es compatible con lectores de pantalla cuando los textos alternativos de las imágenes se mantienen en el backend de TYPO3. Sin textos alt, tanto la accesibilidad como el SEO de imágenes sufren.

## PhotoSwipe v5 corre en TYPO3 v12, la compatibilidad con v13 requiere actualizar plantillas

La librería PhotoSwipe actual está en versión 5. La extensión TYPO3 se ha adaptado a diferentes versiones de TYPO3 y corre estable en v12. Para TYPO3 v13 se requiere actualizar las plantillas Fluid y la configuración TypoScript, porque v13 ha cambiado ligeramente el flujo de trabajo del AssetCollector. Gosign actualiza en los upgrades de TYPO3 todas las extensiones de frontend, incluida la lightbox, y comprueba si los gestos táctiles funcionan correctamente en versiones actuales de iOS y Android.

--- powermail TYPO3 - Formularios y CRM | Gosign ---
> El plugin de formularios más utilizado para TYPO3. Formularios de contacto, formularios de varios pasos, lógica condicional, exportación PDF, conexión CRM.

## powermail es el sistema de formularios listo para producción en TYPO3

Entre el Form Framework del núcleo TYPO3 y las suites completas de Marketing Automation, en la práctica queda un hueco: las redacciones quieren construir formularios sin código, con lógica condicional, subida de archivos, consentimiento RGPD, reenvío a CRM y exportación PDF limpia. Exactamente para eso está construido powermail. La extensión de in2code es el plugin de formularios más instalado del ecosistema TYPO3 y corre en la gran mayoría de los proyectos TYPO3 medianos y grandes que Gosign gestiona. Desde su primera versión hace más de una década, powermail se ha convertido en la navaja suiza del desarrollo de formularios TYPO3 y sigue siendo una elección válida incluso cuando el Form Framework del núcleo bastaría en teoría.

## Escenarios típicos: desde formularios de contacto hasta portales de candidaturas

El escenario más frecuente es trivial pero inevitable: formularios de contacto en sitios corporativos que envían correos a distintos departamentos. powermail lo permite mediante rutas de destinatario condicionales, sin que un desarrollador deba intervenir. Los redactores mantienen los campos en el backend como cualquier contenido de página, incluidos orden, campos obligatorios y validación. Una instalación corporativa típica tiene entre tres y cinco variantes de formulario: consulta general de contacto, contacto de prensa, empleo, soporte y asesoramiento de producto. Cada variante acaba, mediante un filtro de destinatario propio, en la bandeja correcta del departamento.

Claramente más exigentes son los formularios de candidatura multipaso, habituales en instituciones públicas y universidades como la UAM, UCM o la Universidad de Salamanca. Un portal de candidatura pregunta en el paso 1 los datos básicos, en el paso 2 la titulación deseada, en el paso 3 los expedientes mediante upload y en el paso 4 un consentimiento RGPD con enlace a la política de privacidad. powermail renderiza los cuatro pasos desde un único registro de formulario y almacena el progreso entre pasos en una sesión, de modo que el candidato puede retroceder si lo necesita. Las condiciones muestran u ocultan campos en función de respuestas anteriores, lo que en formularios complejos como solicitudes de becas o inscripciones de doctorado ordena un número de combinaciones de campos de tres cifras.

Un tercer escenario que distingue powermail de extensiones más sencillas es la integración con herramientas CRM y Marketing. La arquitectura de Finishers permite enviar los datos en paralelo a HubSpot, Salesforce, Brevo o un webhook propio antes de que salga el correo de confirmación al remitente. En Gosign powermail es por eso también la herramienta estándar para formularios de lead que alimentan directamente el proceso de ventas. En un proyecto enterprise hemos conectado powermail a Salesforce Marketing Cloud y lo hemos reenviado simultáneamente mediante webhook al sistema interno de tickets, de modo que los equipos de Sales y Support pueden acceder a la consulta en paralelo.

## Arquitectura técnica: separación de definición de formulario, finishers y plantilla

powermail consta de tres niveles conceptuales: la definición del formulario en el backend, los Finishers que se ejecutan tras el envío, y las plantillas Fluid que se encargan del renderizado. Cada nivel es ampliable sin forkear la extensión. Esa separación clara hace de powermail una herramienta robusta para proyectos TYPO3 de larga vida, en los que los formularios se mantienen y amplían a lo largo de años.

Los formularios se crean como registros en tx_powermail_domain_model_form. Cada formulario contiene Pages (pasos), cada Page contiene campos. Los tipos de campo van de texto, correo, select, radio, subida de archivos hasta contenido HTML y casillas de consentimiento. La lógica condicional se mantiene a través del módulo Conditions: "muestra el campo B solo si el campo A tiene el valor X".

Los Finishers son la verdadera fuerza de la extensión. El Finisher estándar envía correos, guarda entradas en base de datos y genera exportaciones PDF. Pueden implementarse más Finishers a través del FinisherInterface: envío de webhook, sync CRM, Salesforce, traspaso a SAP. El orden de los Finishers es configurable, y cada Finisher puede abortar el proceso en caso de error.

Las plantillas están como ficheros Fluid en el path EXT y se sobrescriben típicamente mediante SiteSet o paquete propio. Eso significa: basta una única capa global de plantilla para dar un aspecto uniforme a todos los formularios de un sitio. Quien necesita plantillas propias por formulario puede reconfigurar los paths de plantilla mediante TypoScript y mantener un set de plantillas por tipo de formulario.

## Problemas frecuentes: spam, RGPD y entregabilidad del correo

El tema dominante de soporte en formularios powermail públicos es el spam. De fábrica la extensión trae campos honeypot, comprobación de timestamp y un reCAPTCHA v3 opcional a través de ext:powermailrecaptcha. Aun así el spam acaba en el backend si la administración no ha activado los mecanismos de verificación. Recomendamos combinar en cada formulario honeypot Y reCAPTCHA y, adicionalmente, usar un Finisher de rate limit basado en IP.

El segundo problema es la conformidad con el RGPD. Los consentimientos en formularios deben quedar documentados de forma revisable: fecha, versión de la política de privacidad, IP y user agent. La AEPD exige esa documentación con especial rigor en auditorías. La extensión ofrece para ello el Consent Storage, que registra los consentimientos por separado y permite exportarlos para auditorías.

En tercer lugar la entregabilidad del correo es un tema constante. Los correos de confirmación acaban en spam porque el remitente no está autenticado. SPF, DKIM y DMARC deben estar correctamente configurados a nivel del servidor de correo, y la configuración de powermail debería fijar un Return-Path y un Reply-To válido. En instalaciones grandes recomendamos adicionalmente un servicio de correo transaccional dedicado como Brevo, Mailgun o Amazon SES, para que la tasa de entrega no se resienta de la reputación general del servidor.

## TYPO3 v12 y v13 están totalmente soportados

powermail está disponible de forma inmediata para cada release LTS de TYPO3, porque in2code mantiene la extensión activamente. La serie actual soporta TYPO3 v11, v12 y v13 en paralelo. Al actualizar instalaciones más antiguas, los Breaking Changes afectan sobre todo a clases Finisher propias, que deben adaptarse a la firma de interfaz actual, así como a plantillas Fluid que reaccionan a cambios en los ViewHelpers.

Gosign migra instalaciones powermail típicamente junto con el upgrade del núcleo TYPO3. Antes del salto comprobamos qué Finishers y plantillas propios existen, qué integraciones de terceros están conectadas y si quedan variantes de plugin obsoletas en uso. La migración transcurre casi siempre sin migración de datos, porque la estructura de registro de la definición de formulario se mantiene estable.

--- powermailrecaptcha TYPO3 - reCAPTCHA | Gosign ---
> Conexión de Google reCAPTCHA para Powermail. Protección anti-spam para el plugin de formularios más utilizado de TYPO3.

## Powermail sin protección anti-spam se convierte en un vertedero en pocas semanas

Powermail es, con diferencia, la extensión de formularios más utilizada en TYPO3. Más de 150.000 instalaciones activas (datos del TER, 2026), desde formularios de contacto hasta formularios de candidatura y recorridos de consulta complejos con múltiples pasos. El problema: todo formulario público sin CAPTCHA acaba siendo descubierto por bots. Consecuencia típica: de 200 a 500 entradas de spam al día, bandejas de entrada saturadas, estadísticas contaminadas y formularios que el personal termina ignorando, incluidas las consultas reales.

powermailrecaptcha es el complemento oficial de Powermail que integra Google reCAPTCHA v2 o v3 en los formularios Powermail. La extensión la mantiene in2code (el desarrollador de Powermail), lo que garantiza ciclos de actualización cortos y alta compatibilidad.

## Escenarios de uso habituales

**Formularios de contacto en webs corporativas.** El escenario estándar: un formulario con nombre, email, mensaje y botón de envío. Sin CAPTCHA llegan entre 50 y 300 mensajes de spam al día, mayoritariamente con enlaces a sitios farmacéuticos o de apuestas. reCAPTCHA v3 (invisible, basado en puntuación) es ideal aquí: sin clic adicional para el usuario, los bots se detectan en segundo plano.

**Formularios de candidatura con carga de archivos.** Páginas de empleo donde los candidatos suben CV y carta de presentación son especialmente vulnerables al spam, porque los bots distribuyen malware a través de la función de carga. reCAPTCHA filtra las solicitudes automatizadas. Adicionalmente, debe estar activa una verificación de tipo de archivo en el servidor (solo PDF, DOCX) y una limitación de tamaño (máx. 10 MB).

**Formularios multietapa con lógica condicional.** Powermail puede construir formularios con condiciones: si se selecciona "Sector = Inmobiliario", aparecen campos adicionales. En estos formularios basta un CAPTCHA en la última página antes del envío. powermailrecaptcha vincula la verificación al botón de envío por defecto, funcionando también en formularios multi-step.

## Arquitectura técnica

powermailrecaptcha extiende Powermail mediante un Signal/Slot de TYPO3 (v11) o un Event PSR-14 (v12+). Al renderizar el formulario, se incluye el JavaScript de reCAPTCHA (desde google.com/recaptcha/api.js). Al enviar, el token reCAPTCHA se valida en el servidor: TYPO3 envía una petición POST a `https://www.google.com/recaptcha/api/siteverify` con el token y la Secret Key. Google responde con una puntuación (v3) o una confirmación (v2).

La configuración se realiza mediante constantes TypoScript: Site Key y Secret Key (de la Consola de Administración de Google reCAPTCHA), umbral de puntuación para v3 (por defecto: 0.5), versión de reCAPTCHA (v2 Checkbox, v2 Invisible o v3). Las claves se gestionan en el backend TYPO3 bajo Constants, idealmente mediante variables de entorno para que no acaben en el repositorio Git.

## Problemas frecuentes y soluciones

**Preocupaciones RGPD por la conexión con Google.** reCAPTCHA carga JavaScript desde servidores de Google y transmite la dirección IP del usuario a Google. Tras la sentencia Schrems II y la interpretación cada vez más estricta de la AEPD y las autoridades europeas de protección de datos, esto supone un riesgo real. Solución: cargar reCAPTCHA solo cuando el usuario haya consentido vía banner de cookies (integración de consentimiento). O migrar completamente a alternativas europeas: Friendly Captcha (servidores en la UE, sin seguimiento), hCaptcha (más conforme al RGPD que reCAPTCHA, pero servidores en EE.UU.) o una estrategia pura de honeypot sin servicios externos.

**reCAPTCHA v3 bloquea usuarios reales.** El algoritmo de puntuación es una caja negra. Algunos usuarios reales (por ejemplo, detrás de VPN, con bloqueador de anuncios, en dispositivos antiguos) reciben puntuaciones bajas y se bloquean erróneamente. Solución: no fijar el umbral en 0.5 sino en 0.3, y añadir además un campo honeypot. Alternativa: mostrar un fallback a reCAPTCHA v2 Checkbox con puntuación baja, en lugar de bloquear directamente.

**Conflicto de extensión con Content Security Policy.** Desde TYPO3 v12, el Core soporta Content Security Policies (CSP). El JavaScript de reCAPTCHA desde google.com debe permitirse en la CSP; de lo contrario se bloquea. Solución: añadir en la configuración CSP `script-src` y `frame-src` para `https://www.google.com/recaptcha/` y `https://www.gstatic.com/recaptcha/`.

## Migración y compatibilidad de versiones

powermailrecaptcha es compatible con TYPO3 v11, v12 y v13 (esto último desde el Q1 2026). La extensión sigue el ciclo de releases de Powermail: cuando Powermail soporta una nueva versión de TYPO3, powermailrecaptcha se adapta en pocas semanas.

Para proyectos que quieran cambiar de reCAPTCHA a una alternativa más amigable con el RGPD, la migración es sencilla. Friendly Captcha ofrece su propio plugin para Powermail (powermail_friendlycaptcha) que funciona como reemplazo directo: instalar extensión, introducir claves, desactivar powermailrecaptcha. La configuración del formulario en Powermail permanece inalterada. Gosign recomienda Friendly Captcha como estándar para nuevos proyectos.

Un aspecto frecuentemente ignorado es la prevención de spam más allá de los CAPTCHAs. Powermail ofrece nativamente un campo honeypot (un campo de formulario invisible que solo los bots rellenan). En combinación con una verificación temporal (el formulario debe estar abierto al menos 3 segundos antes de poder enviarse), se filtra la mayor parte del spam automatizado sin servicios externos. Gosign aplica en proyectos donde la conformidad RGPD es prioritaria una estrategia de tres capas: honeypot y verificación temporal como primera capa (0 peticiones externas), Friendly Captcha como segunda capa (servidores UE) y análisis de contenido en servidor como tercera capa (densidad de enlaces, idioma, patrones de spam conocidos). Esta combinación alcanza una tasa de detección de spam superior al 99 % sin servicios de Google.

--- Calculadora de precios TYPO3 - Calculadora | Gosign ---
> Configuradores, calculadoras de costes, generadores de ofertas directamente en TYPO3.

## Las calculadoras de precios en la web generan leads cualificados, pero solo si el cálculo es sólido

Los visitantes que calculan un precio en una web son los leads más valiosos en la venta B2B. Tienen un proyecto concreto, conocen sus requisitos y esperan una cifra fiable. Y, sin embargo, la mayoría de webs TYPO3 trabajan con tablas de precios estáticas o con un botón de "precio bajo consulta" que envía al visitante a un formulario de contacto genérico. pricecal cubre ese hueco: la extensión permite configuradores, calculadoras de costes y generadores de presupuestos directamente en TYPO3, con lógica de cálculo específica y un frontend interactivo que reacciona en tiempo real.

La diferencia con herramientas externas como Calconic u Outgrow: los datos permanecen en el servidor propio, el cálculo está bajo pleno control y el diseño se integra sin costuras en la web existente. Para el cumplimiento del RGPD eso es relevante, porque no se transfieren datos de usuario a terceros y no hace falta un mecanismo de transferencia que la AEPD deba documentar.

## Los escenarios típicos van desde la calculadora de mudanzas al configurador industrial

El escenario más accesible es la calculadora de costes para servicios. Una empresa de mudanzas pregunta por el tamaño de la vivienda, la planta, la distancia y los deseos especiales (piano, acuario) y muestra un precio orientativo. El visitante ve de inmediato si el servicio encaja en su presupuesto y puede solicitar directamente una oferta en firme. En la práctica, ese tipo de calculadoras eleva la tasa de solicitud entre un 40 y un 70 por ciento frente a un formulario de contacto estático, porque el visitante ya tiene una expectativa de precio.

Un segundo escenario son los configuradores de producto en la industria manufacturera. Un fabricante de ventanas ofrece 12 tipos de marco, 8 tipos de vidrio, 4 variantes de herraje y 20 colores. pricecal calcula el precio a partir de la combinación y lo muestra en vivo mientras el visitante configura. Con 12 x 8 x 4 x 20 = 7.680 combinaciones posibles, una lista de precios estática es imposible. El configurador la sustituye por un cálculo dinámico que el redactor mantiene desde el backend mediante matrices de precios.

Tercer escenario: calculadoras de ROI para productos de software. Un proveedor SaaS permite al visitante introducir número de empleados, tiempo actual dedicado a una tarea y coste por hora. La calculadora muestra el ahorro anual del producto. No es un truco de venta, sino una herramienta que ayuda al visitante a justificar la inversión internamente.

## La arquitectura técnica separa lógica de cálculo, campos de entrada y presentación de resultado

pricecal está implementada como elemento de contenido personalizado en TYPO3. En el backend, el administrador define los campos de entrada (slider, desplegable, número, casilla), la fórmula de cálculo y la presentación del resultado. La fórmula puede representar aritmética simple (precio = cantidad x precio unitario x factor) o lógica más compleja con condiciones (si planta > 3, entonces recargo del 15%).

El frontend renderiza los campos de entrada mediante plantillas Fluid y calcula el precio vía JavaScript en el navegador. Sin viaje al servidor en cada paso del slider, el resultado se actualiza en tiempo real. Para cálculos más complejos, por ejemplo cuando hay que incorporar matrices de precios o fuentes de datos externas (ERP, disponibilidad de stock), el cálculo se puede delegar al servidor mediante un endpoint AJAX.

Los resultados se pueden generar opcionalmente como PDF y enviar por email. Combinado con powermail, el resultado del cálculo se puede pasar como campo oculto a un formulario de contacto, de modo que el equipo comercial vea la configuración exacta del interesado.

## Los problemas frecuentes son los errores de redondeo y el mantenimiento de lógicas de precio complejas

El problema más habitual en calculadoras de precios es el redondeo correcto. La aritmética de coma flotante de JavaScript devuelve 0,30000000000000004 para 0,1 + 0,2. En precios con dos decimales, eso produce errores visibles. La solución: realizar todos los cálculos internamente en céntimos (enteros) y convertir a euros solo en la presentación. Para el mercado español es además clave representar correctamente el IVA del 21% y mostrar por separado el importe sin impuestos y con impuestos, porque los compradores B2B necesitan el neto y los consumidores el total con IVA.

Segundo problema: el mantenimiento de la lógica de cálculo. Si un jefe de producto ajusta precios trimestralmente, debe entender las fórmulas en el backend. Para cálculos sencillos (cantidad x precio) es trivial. Para configuradores con 50 parámetros y descuentos escalonados, el mantenimiento se convierte en un riesgo. Recomendamos externalizar la lógica de precios compleja como configuración TypoScript o fichero YAML y mantenerla versionada en Git, en lugar de editarla en el backend.

Tercer tema: usabilidad móvil. Los sliders son imprecisos en pantallas táctiles porque el dedo cubre un área mayor que el puntero del ratón. En calculadoras con granularidad fina (por ejemplo, metros cuadrados de 10 a 500), los sliders deberían sustituirse por campos de entrada con botones de más y menos.

## pricecal es desarrollo personalizado, por lo que es independiente de versión

Como pricecal no es una extensión de comunidad del TER, sino un desarrollo personalizado, no hay un ciclo de release externo. La compatibilidad con TYPO3 depende de cómo esté implementada internamente. Las instalaciones basadas en Extbase y Fluid corren bajo TYPO3 v12 y v13 tras adaptar las declaraciones de namespace y el registro del elemento de contenido. En proyectos nuevos de calculadora de precios, Gosign apuesta por una arquitectura independiente de framework: la lógica de cálculo corre como un módulo JavaScript autónomo que TYPO3 solo integra como elemento de contenido, pero sin dependencia de Extbase.

--- Social Feed TYPO3 - Instagram y más | Gosign ---
> Social Media Feeds (Instagram, Facebook, Twitter/X) en TYPO3 einbinden. API-basiert, gecacht, conforme con el RGPD darstellbar ohne Tracking-Pixel. Gosign.

## Los feeds de redes sociales quedan bien en la web, pero se rompen regularmente por cambios en las APIs

Equipos de marketing quieren mostrar publicaciones de Instagram, Facebook o Twitter/X en la web corporativa. La idea es comprensible: contenido fresco sin esfuerzo editorial, prueba social mediante publicaciones reales, enriquecimiento visual con material gráfico. La práctica es otra. Meta, Twitter/X y TikTok modifican sus APIs periódicamente, restringen permisos de acceso o eliminan endpoints gratuitos por completo. Twitter/X suprimió el acceso gratuito a la API en 2023 y exige desde entonces al menos 100 USD/mes por permisos de lectura. La Instagram Basic Display API fue sustituida en 2024 por la Instagram Graph API. Quien opera una integración de feed social debe adaptarse a estos cambios o el feed se queda vacío.

pxa_social_feed (desarrollada por Pixelant) es la extensión TYPO3 más conocida para feeds de redes sociales. Soporta Instagram, Facebook y Twitter/X, almacena los datos del feed localmente (en caché) y los renderiza como elemento de contenido TYPO3.

## Escenarios de uso habituales

**Webs corporativas con feed de Instagram en la portada.** Una empresa publica de 3 a 5 veces por semana en Instagram y quiere mostrar los últimos 6 a 12 posts como galería de imágenes en la portada. pxa_social_feed obtiene las publicaciones vía cronjob (por ejemplo, cada 30 minutos), almacena imágenes, descripciones y enlaces localmente y las renderiza en un grid configurable. La ventaja frente a un embed (iframe): sin peticiones externas al cargar la página, sin píxeles de seguimiento, menor tiempo de carga.

**Páginas de eventos con feed en directo.** Conferencias, ferias o eventos corporativos usan un hashtag (por ejemplo, #GosignSummit2026). El feed muestra todas las publicaciones públicas con ese hashtag casi en tiempo real (con caché de 5 minutos). La moderación se realiza desde el backend TYPO3: publicaciones individuales pueden ocultarse antes de aparecer en la web.

**Páginas de employer branding.** Departamentos de RRHH muestran en la página de empleo perspectivas del día a día laboral que los empleados publican en Instagram o LinkedIn. La integración recopila publicaciones de una o varias cuentas y las cura editorialmente. Particularidad: LinkedIn no ofrece una API abierta para integración de feeds, por lo que la automatización se limita a Instagram y Facebook.

## Arquitectura técnica

pxa_social_feed utiliza las APIs de las respectivas plataformas: Instagram Graph API (mediante un token de app Facebook), Facebook Graph API y Twitter/X API v2. Cada plataforma requiere su propia autenticación: Facebook e Instagram necesitan un Long-Lived User Token (válido 60 días, debe renovarse periódicamente), Twitter/X necesita un Bearer Token (Application-only Auth).

La extensión almacena los datos del feed en una tabla TYPO3 local. Las imágenes se descargan y almacenan como referencias FAL. Al cargar la página, solo se renderizan datos locales, sin llamadas API externas. Una tarea del Scheduler obtiene nuevas publicaciones y elimina las antiguas (configurable: mantener las últimas 50, eliminar las más antiguas).

La salida se realiza mediante plantillas Fluid, configurables vía TypoScript. Layouts estándar: grid (3-4 columnas), masonry, slider (con integración JavaScript propia). El HTML/CSS se personaliza completamente sin modificar el código de la extensión.

Para la conformidad con el RGPD, el caché local es decisivo: al estar las imágenes y textos en el servidor propio, no se transmiten datos a Meta o Twitter/X al cargar la página. Sin píxeles de seguimiento, sin necesidad de consentimiento de cookies para el feed en sí. Esto alinea la implementación con los criterios de la AEPD para tratamiento de datos de terceros.

## Problemas frecuentes y soluciones

**El token de Instagram caduca, el feed se queda vacío.** El Long-Lived Token tiene una vida útil de 60 días. Si nadie lo renueva, la importación se detiene. Solución: configurar un cronjob que renueve automáticamente el token vía llamada API. pxa_social_feed ofrece desde la versión 4.x una función de renovación de tokens en el backend.

**El feed de Twitter/X deja de funcionar tras el cambio de API.** Desde 2023, la API de Twitter/X es de pago. La tarifa Basic (100 USD/mes) permite leer 10.000 tweets/mes. Para la mayoría de webs corporativas es suficiente, pero la relación coste-beneficio debe cuadrar. Solución: verificar si el feed de Twitter/X realmente aporta tráfico o engagement. Si no, eliminar el canal y mantener solo Instagram/Facebook.

**Las imágenes no cargan o están pixeladas.** La Instagram Graph API entrega imágenes en varios tamaños. pxa_social_feed almacena por defecto la versión proporcionada por la API. Solución: configurar en la extensión el tamaño de imagen como "original" y generar variantes responsive en la plantilla Fluid mediante `<f:image>`.

## Migración y compatibilidad de versiones

pxa_social_feed es compatible con TYPO3 v11 y v12. La compatibilidad con TYPO3 v13 está en desarrollo por la comunidad (estado: abril 2026), pero aún no se ha liberado oficialmente. Para proyectos en TYPO3 v13 hay dos opciones: esperar a la actualización oficial o construir una integración de feed propia como middleware independiente de la versión de TYPO3.

Gosign recomienda fundamentalmente concebir las integraciones de feeds sociales como componente desacoplado: un microservicio o Cloudflare Worker obtiene los feeds, los almacena como JSON, TYPO3 lee el JSON y lo renderiza. Así desaparece la dependencia de una extensión TYPO3 y cada cambio de API se corrige en un solo lugar, independientemente del CMS.

El esfuerzo total para una integración de feed social (Instagram, con caché, conforme al RGPD, con moderación en el backend) se sitúa entre 2 y 5 días de desarrollo, dependiendo de si pxa_social_feed es suficiente o se necesita una solución a medida.

--- RaiseNow TYPO3 - Donaciones | Gosign ---
> Integración de RaiseNow para TYPO3. Formularios de donación, procesamiento de pagos, recibos de donación. Para ONG, fundaciones e instituciones benéficas.

## Las organizaciones sin ánimo de lucro pierden donaciones cuando el proceso de donación abandona la web

Cada ruptura de medio cuesta conversión. Cuando un visitante hace clic en "Donar ahora" y es redirigido a una plataforma externa, entre un 30 y un 50 por ciento abandona, según el estudio que se consulte. RaiseNow es una plataforma de donaciones de origen suizo que resuelve precisamente ese problema: la integración con TYPO3 incrusta todo el proceso de donación directamente en la web. Importe de la donación, método de pago, datos de la dirección y confirmación se desarrollan en un widget integrado, sin que el visitante abandone la página. Para ONGs, asociaciones y fundaciones que trabajan con TYPO3, es la integración más limpia entre el CMS y la plataforma de donación.

RaiseNow procesa anualmente más de 300 millones de francos en donaciones y es en Suiza el líder en fundraising digital. La extensión TYPO3 trae ese ecosistema directamente al backend. Para las ONGs españolas supone además una alternativa a integraciones basadas en Stripe o servicios estadounidenses, porque los datos se procesan en servidores suizos y se amparan en la decisión de adecuación de la Comisión Europea.

## Los escenarios típicos abarcan desde donaciones puntuales hasta campañas de donantes recurrentes

El escenario base es la donación puntual en la portada o en una página de campaña. Una ONG humanitaria lanza una campaña tras una catástrofe natural. La landing page muestra la barra de progreso (recaudado / objetivo) y un formulario de donación con importes propuestos (25, 50, 100, libre). El visitante dona con tarjeta, transferencia SEPA, Bizum, domiciliación o PayPal, recibe una confirmación inmediata y un recibo por email. Toda la transacción dura menos de 60 segundos.

Un segundo escenario, económicamente más relevante, son las donaciones recurrentes. Una organización de protección animal ofrece apadrinamientos mensuales: 15 euros al mes para el cuidado de un animal. RaiseNow gestiona los pagos recurrentes, notifica los cobros fallidos y ofrece al donante un portal de autoservicio para ajustar la donación. En ONGs con recorrido, las donaciones recurrentes suponen entre el 40 y el 60 por ciento del volumen total porque generan ingresos previsibles que permiten planificación plurianual.

Tercer escenario: fundraising peer-to-peer. Un club deportivo organiza una carrera solidaria. Cada corredor crea una página de donación personal, la comparte en redes sociales y recauda donaciones para el club. RaiseNow agrega los importes, los asigna a los corredores y muestra un ranking en vivo. La extensión TYPO3 publica la vista general de la campaña y los perfiles de donación personales como elementos de contenido.

## La arquitectura técnica utiliza widgets de RaiseNow vía iFrame y callback por API

La extensión TYPO3 integra RaiseNow mediante un widget JavaScript que se incrusta como iFrame en la página. La configuración (clave API, ID de campaña, métodos de pago, importes propuestos) se ajusta en el backend de TYPO3 como configuración del plugin y se pasa al widget vía TypoScript.

Tras una donación exitosa, RaiseNow envía un webhook a un endpoint configurable. Ese webhook se puede procesar en TYPO3 para registrar las donaciones en una base de datos local, actualizar barras de progreso o lanzar correos de agradecimiento a través del envío propio de TYPO3. El propio procesamiento del pago corre íntegramente en la infraestructura de RaiseNow, lo que permite cumplimiento PCI DSS sin certificación propia.

El recibo de la donación lo genera RaiseNow e incluye todos los datos relevantes a efectos fiscales. Para organizaciones españolas reconocidas como entidades acogidas a la Ley 49/2002, el recibo puede incluir el CIF, el número de registro y los datos necesarios para la deducción en el IRPF o en el Impuesto sobre Sociedades, que los donantes podrán aportar en su declaración.

## Los problemas frecuentes tienen que ver con el cumplimiento del RGPD y el styling del widget

El mayor tema para organizaciones europeas es el cumplimiento del RGPD. RaiseNow es una empresa suiza y procesa los datos de pago en servidores suizos. Desde la decisión de adecuación de la Comisión Europea, Suiza se considera un tercer país seguro, pero la política de privacidad debe, aun así, mostrar de forma transparente qué datos se transmiten a RaiseNow. Las organizaciones que quieran ir sobre seguro recaban un consentimiento explícito mediante una capa de consent antes de que se cargue el widget de RaiseNow. Para el mercado español, la AEPD exige además informar claramente sobre la base jurídica del tratamiento y el responsable de los datos.

Segundo problema: el styling del widget. Los widgets de RaiseNow tienen un CSS propio que no se puede sobrescribir por completo desde fuera. Colores, tipografías y estilos de botones se pueden adaptar vía la configuración de RaiseNow, pero el layout del formulario está fijado. Para organizaciones con pautas estrictas de identidad visual eso puede ser un compromiso. La alternativa es un formulario de donación a medida que ataque directamente la API de RaiseNow, aunque eso impone requisitos PCI DSS sobre la infraestructura propia.

Un tercer aspecto es el idioma y la localización. El widget soporta castellano, catalán, euskera y gallego, pero el redactor debe activar los idiomas explícitamente y comprobar que los textos de los correos de agradecimiento y los recibos estén localizados. Ponerlo solo en alemán o inglés en una web española rompe la confianza del donante.

## RaiseNow evoluciona activamente, la extensión TYPO3 requiere mantenimiento manual

RaiseNow en sí se desarrolla continuamente. Métodos de pago nuevos (Apple Pay, Google Pay) y funcionalidades (facturas QR) se añaden con regularidad. La extensión TYPO3, sin embargo, es un proyecto de comunidad y no la mantiene oficialmente RaiseNow. Eso significa: si TYPO3 v13 introduce un cambio en el registro de plugins, la extensión debe adaptarse a mano. Las organizaciones que usen RaiseNow en TYPO3 a largo plazo deberían mantener la extensión en un fork propio y actualizarla en los upgrades de TYPO3. Gosign asume ese mantenimiento dentro de contratos de soporte y revisa en cada actualización de TYPO3 la compatibilidad con RaiseNow.

--- rapidmail TYPO3 - Integración de newsletter | Gosign ---
> Integrar rapidmail en TYPO3: sincronización de suscriptores, Double-Opt-In, segmentación. Acelerado con IA, conforme con el RGPD.

## rapidmail es la respuesta pragmática para boletines en proyectos TYPO3 sensibles al RGPD

Quien opera en España un boletín con seguridad jurídica acaba tarde o temprano en proveedores europeos. rapidmail es uno de los más utilizados: servidores europeos, soporte en alemán y parcialmente en otros idiomas, modelos de precio claros, API sólida. Para sitios TYPO3 que recogen suscripciones a boletín directamente en el frontend y cuyos destinatarios deben ir automáticamente a listas y segmentos, la integración de ese servicio es una tarea estándar. Los resultados son a menudo decepcionantes porque la extensión oficial de TYPO3 solo cubre funciones básicas y los proyectos con requisitos reales chocan con sus límites rápidamente.

El público son pymes, asociaciones, empresas municipales, universidades, ONG y editoriales que quieren construir su comunicación con clientes existentes sobre una plataforma conforme al RGPD. Un caso de uso típico: una empresa regional de suministro energético con 80.000 clientes domésticos quiere enviar boletines dirigidos con cuatro segmentos (clientes particulares, clientes empresariales, clientes de programas de ayuda, contactos de prensa) y obtener la segmentación automáticamente desde los grupos de usuario de TYPO3.

## Escenarios típicos de uso

Un primer escenario es la ruta sencilla de alta a través de Powermail. Una asociación quiere dar de alta en el boletín a visitantes de su web TYPO3. El Powermail Finisher pasa nombre, correo y una marca de segmento a la API de rapidmail, rapidmail envía el correo de confirmación y, tras el clic en el enlace de confirmación, el contacto se activa en la lista de destinatarios correspondiente.

Un segundo escenario es la sincronización de grupos de usuario de TYPO3 con segmentos de rapidmail. Una universidad mantiene en la intranet TYPO3 roles como estudiantes, antiguos alumnos, personal. Cada cambio de rol debe actualizar automáticamente la asignación de segmento en rapidmail, de modo que los envíos lleguen exactamente al público correcto, sin duplicación de mantenimiento.

Un tercer escenario es el cuidado de participantes en eventos. Una editorial organiza diez conferencias sectoriales al año y quiere pasar automáticamente los participantes a una ruta de comunicación posterior. El registro se realiza en un formulario TYPO3, la API escribe al participante en una lista de evento y rapidmail dispara una drip campaign automática con tres correos.

Un cuarto escenario es la sincronización de bajas. Cuando un lector se da de baja mediante el enlace del boletín en rapidmail, el centro de perfil de TYPO3 debe asumir ese estado, para que al siguiente login el usuario no vea de nuevo "boletín activo". Eso requiere un canal de retorno: rapidmail comunica la baja mediante webhook, TYPO3 acusa recibo y actualiza el grupo de usuario.

## Arquitectura técnica

rapidmail pone a disposición una API REST con autenticación OAuth. La integración con TYPO3 se realiza o bien mediante un Powermail Finisher, una extensión del Form Framework o un servicio Extbase propio que accede a la API. Gosign apuesta por regla general por una clase de servicio ligera que encapsula las llamadas API y está disponible mediante Dependency Injection en controladores, finishers y tareas del scheduler.

Para la sincronización continua de grupos de usuario se configura típicamente una tarea del Scheduler que transmite delta updates a rapidmail cada 15 minutos. La detección delta corre mediante un campo de auditoría interno de TYPO3 (última modificación por usuario) o mediante una comparación por hash sobre la base de la respuesta de la API. Es importante que cada transmisión sea idempotente, para que una nueva ejecución tras un error no genere duplicados.

El Double-Opt-In se gestiona por completo en el lado de rapidmail: TYPO3 da de alta un contacto, rapidmail envía el correo de confirmación, el lector confirma, rapidmail activa el contacto. TYPO3 no tiene que aportar nada propio para eso; lo importante es solo que la página TYPO3 muestre al usuario una página intermedia comprensible ("Por favor, confirme el alta desde su bandeja de entrada").

## Problemas frecuentes y soluciones

El primer problema es la ausencia de gestión de rebotes. Quien no evalúa las respuestas de la API no nota que rapidmail rechaza determinadas direcciones de forma permanente. La solución es un log de las respuestas API en una tabla propia de TYPO3 más una conciliación periódica de las listas de rebote que rapidmail pone a disposición mediante la API.

El segundo problema son las asignaciones erróneas de segmento. Cuando un contacto entra en varios grupos de usuario que apuntan cada uno a listas distintas en rapidmail, surgen estados inconsistentes. La solución es una lógica de mapping 1:1 o 1:n clara, definida limpiamente antes de la implementación y fijada de forma dura en la capa de servicio.

El tercer problema es la violación del rate limit de la API. rapidmail limita el uso de la API. En una migración inicial de 20.000 contactos en una sola ejecución del scheduler, el job se topa inevitablemente con el bloqueo. La solución es una importación por chunks con 100 contactos por batch y un control de pausas entre batches.

Un cuarto problema es la imprecisión de conciliación con perfiles duplicados. Cuando un usuario se apunta varias veces con distintas grafías de correo (con/sin punto, mayúsculas/minúsculas), surgen duplicados en rapidmail y estados inconsistentes entre TYPO3 y el sistema de boletín. La solución es una normalización de la dirección de correo antes de cada llamada API (lowercase, trim de whitespace, regla de puntos de Gmail ignorada conscientemente o aplicada de forma consistente).

## Migración y compatibilidad de versiones

La integración, como extensión a medida, es en gran medida independiente de la versión de TYPO3: corre limpiamente en TYPO3 v11, v12 y v13 siempre que el código del cliente API se apoye en HTTP Clients modernos (Guzzle) y Dependency Injection. En el upgrade de una integración existente, el punto de dolor más frecuente es la migración de hooks de TYPO3 a middlewares PSR-15, un esfuerzo que Gosign completa por regla general en pocos días con análisis de código asistido por IA.

En el lado de rapidmail la API cambia lentamente, pero no sin rupturas: entre versiones mayores se han renombrado endpoints individuales, se han reestructurado campos o modernizado procedimientos de autenticación. Quien lleva una integración antigua de 2018 o 2020 al estado actual debería contar con medio sprint para la actualización de la API y ejecutar las pruebas contra una lista de staging en rapidmail antes de tocar producción. Gosign mantiene para esas tareas de refresh un catálogo de verificación estándar que cubre los tropiezos habituales (autenticación, pagination, formato de respuesta de error) y hace la migración reproducible.

--- Plugin de recetas TYPO3 | Gosign ---
> Extensión de recetas para TYPO3: ingredientes, pasos de preparación, valores nutricionales, porciones. Con marcado Schema.org Recipe para Google Rich Snippets.

## Las recetas sin marcado Schema.org regalan las posiciones más valiosas en los resultados de Google

Las búsquedas de recetas son uno de los pocos ámbitos en los que Google muestra Rich Snippets con imagen, valoración, tiempo de preparación y calorías. Las webs sin marcado Schema.org Recipe correcto aparecen como un simple enlace azul bajo los Rich Results visualmente dominantes. La extensión de recetas para TYPO3 estructura las recetas con todos los campos que Google espera para los Rich Snippets: ingredientes, pasos de preparación, valores nutricionales, raciones, tiempo de preparación, nivel de dificultad. El marcado Schema.org se genera automáticamente en formato JSON-LD, sin que los redactores tengan que editar HTML.

Para blogs gastronómicos, editoriales con secciones de recetas y fabricantes de alimentos con bases de datos de recetas, eso marca la diferencia entre visibilidad e invisibilidad en la búsqueda de Google.

## Los escenarios típicos abarcan blogs gastronómicos, webs de producto y portales de salud

El escenario más frecuente es el blog gastronómico o la revista online con sección de recetas. Una editorial publica semanalmente cinco recetas nuevas. Cada receta se crea en el backend de TYPO3 como registro estructurado: título, descripción, lista de ingredientes con cantidades, pasos de preparación en lista numerada, tiempos (preparación, cocción, total), valores nutricionales por ración y una imagen principal. La extensión genera a partir de ahí una página de detalle con marcado Schema.org correcto. Google muestra en los resultados de búsqueda la imagen, la valoración en estrellas, el tiempo total y las calorías.

Un segundo escenario son webs de producto de fabricantes de alimentación. Un productor de aceite de oliva muestra para cada producto recetas adecuadas. Las recetas enlazan al producto y el producto enlaza a las recetas. Esa vinculación bidireccional refuerza tanto la página de producto como la página de receta en la valoración de Google. Para fabricantes españoles de aceite, vinos, jamón o embutidos es especialmente potente, porque las recetas tradicionales con esos productos tienen un alto volumen de búsqueda en castellano.

Tercer escenario: portales de salud y consultas nutricionales. Aquí los valores nutricionales son el foco. Un portal de diabetes muestra recetas con raciones de hidratos, índice glucémico y carbohidratos por porción. La extensión permite campos personalizados, de modo que esos valores médicamente relevantes se registran como datos estructurados y se muestran de forma destacada en el frontend.

## La arquitectura técnica utiliza registros Extbase con salida automática JSON-LD

La extensión registra un tipo de registro propio para recetas en la base de datos de TYPO3. Cada registro contiene campos para título, descripción, ingredientes (como registros relacionales inline), pasos (como lista ordenable), tiempos (prepTime, cookTime, totalTime en formato ISO-8601), valores nutricionales (calorías, grasas, carbohidratos, proteína) e imágenes vía FAL.

El renderizado del frontend se realiza mediante plantillas Fluid que presentan la receta como página HTML y, simultáneamente, escriben una etiqueta script JSON-LD con el marcado Schema.org/Recipe en el head de la página. El marcado sigue la especificación de Google: name, image, author, datePublished, description, prepTime, cookTime, totalTime, recipeYield, recipeIngredient, recipeInstructions y nutrition.

La vista de lista muestra las recetas como tarjetas con imagen, título, tiempo total y valoración. Los filtros por categoría (entrante, plato principal, postre), tipo de dieta (vegetariana, vegana, sin gluten) y tiempo de preparación son configurables vía TypoScript.

## Los problemas frecuentes son los campos obligatorios ausentes y los formatos de tiempo inválidos

El mayor problema para la presentación como Rich Snippet son los campos obligatorios ausentes. Google exige como mínimo name, image y recipeInstructions. Si un redactor crea una receta sin imagen o sin pasos de preparación, el marcado Schema.org se emite, pero Google lo ignora y no muestra Rich Snippet. La solución: activar la validación de campos obligatorios en el backend de TYPO3, de modo que no se puedan guardar recetas sin imagen y sin al menos un paso de preparación.

Segundo problema: formatos de tiempo inválidos. Schema.org espera ISO-8601 Duration (PT30M para 30 minutos, PT1H15M para 1 hora 15 minutos). Si la extensión no convierte correctamente la entrada del redactor "30 min" a PT30M, la validación en Google Rich Results Test falla. La mayoría de extensiones de recetas ofrecen campos separados para horas y minutos que se convierten internamente a ISO-8601.

Tercer tema: contenido duplicado en recetas incrustadas en varias páginas. Si la misma receta se muestra completa en la página de categoría y en la página de detalle, se generan dos páginas con marcado Schema.org idéntico. Google lo valora como duplicado. La solución: en las páginas de categoría mostrar solo teasers y emitir el marcado Schema.org completo exclusivamente en la página de detalle.

Un cuarto aspecto, relevante en el contexto español y europeo, es la información alimentaria. El Reglamento (UE) 1169/2011 sobre información alimentaria al consumidor exige para determinados productos indicaciones obligatorias (alérgenos, valor energético, composición). Para webs de fabricantes es recomendable acoger esa información en la extensión de recetas y mostrarla de forma clara, especialmente los 14 alérgenos de declaración obligatoria.

## La extensión funciona en TYPO3 v11 y v12, para v13 se requiere una actualización de Extbase

Las extensiones de recetas en el ecosistema TYPO3 las mantienen distintos proveedores. La compatibilidad con TYPO3 v12 está asegurada en las extensiones mantenidas activamente. Para TYPO3 v13 suelen ser necesarios ajustes en la configuración del modelo Extbase y en las definiciones TCA, porque v13 ha retirado algunos tipos TCA obsoletos. Gosign recomienda, en webs de recetas, validar la salida Schema.org tras cada actualización de TYPO3 con Google Rich Results Test para asegurar que la calidad del marcado se mantiene.

--- registeraddress TYPO3 - Suscripción a newsletter | Gosign ---
> Extensión para registro de newsletter en TYPO3. Double-Opt-In, gestión de suscripciones, integración con tt_address.

## El registro de newsletter sin servicios externos ahorra costes y mantiene los datos bajo control propio

Mailchimp, Brevo, rapidmail: por cada registro en el newsletter, las organizaciones pagan por suscriptor y por correo enviado. Con 10.000 abonados, eso se va a entre 100 y 300 euros mensuales solo por la administración de direcciones. registeraddress ofrece una alternativa: registro de newsletter directamente en TYPO3 a través de la ya probada tabla tt_address. La gestión de suscriptores, el Double-Opt-In, el enlace de baja y la documentación de consentimiento conforme al RGPD corren íntegramente en el CMS, sin que un servicio externo tenga acceso a los datos de los abonados.

Para asociaciones, editoriales pequeñas e instituciones públicas con restricciones presupuestarias, es una arquitectura válida, sobre todo si el envío del newsletter se realiza a través de un servicio SMTP económico como Amazon SES (0,10 dólares por cada 1.000 correos) o del propio servidor de correo. Para la AEPD y el cumplimiento del RGPD, la ventaja es clara: no hay transferencia de datos a un proveedor externo que haya que documentar en el registro de actividades de tratamiento.

## Los escenarios típicos abarcan newsletters de asociaciones, listas de intranet e inscripciones a eventos

El escenario más frecuente es el clásico newsletter de asociación. Un club deportivo con 2.000 socios ofrece un formulario de alta en su web TYPO3. Los visitantes introducen su dirección de correo, reciben un correo Double-Opt-In, confirman y pasan a la tabla tt_address. La asociación envía mensualmente un newsletter vía la extensión direct_mail o un servicio de envío externo que importa las direcciones desde tt_address. registeraddress se ocupa exclusivamente del registro y de la baja, no del envío en sí.

Un segundo escenario son las listas de distribución en intranets corporativas. Los empleados se apuntan a newsletters informativos internos, como "Sede de Madrid - menú de cantina" o "Ventanas de mantenimiento de TI". Como los datos no pueden salir de la red corporativa, un servicio de newsletter externo queda descartado. registeraddress gestiona las altas localmente en la base de datos de TYPO3.

Tercer escenario: inscripciones a eventos con confirmación por email. Una biblioteca ofrece actividades y utiliza registeraddress como formulario de inscripción ligero. El correo de confirmación tras el Double-Opt-In incluye fecha, hora y lugar de la actividad. No es una solución de gestión de eventos completa, pero para entidades con cinco a diez actividades al mes resulta suficiente.

## La arquitectura técnica se apoya en tt_address y el flujo Double-Opt-In

registeraddress está implementada como plugin Extbase y utiliza la tabla tt_address como base de datos. Cada registro pasa por un proceso en tres pasos: entrada en el formulario, correo Double-Opt-In con enlace de confirmación, activación del registro tras el clic en el enlace. El enlace de confirmación contiene un token firmado criptográficamente que expira tras un plazo configurable (por defecto: 48 horas).

La extensión registra un plugin de frontend que se configura vía TypoScript: campos obligatorios, campos opcionales (nombre, empresa, tratamiento), texto de confirmación, plantillas de correo para el Double-Opt-In y la bienvenida. Las plantillas Fluid son sobrescribibles vía SiteSet para que el formulario encaje en el diseño de la web.

Para el cumplimiento del RGPD, registeraddress almacena el momento del consentimiento, la dirección IP, el user agent y la versión de la política de privacidad a la que se enlazó desde el formulario. Ante una consulta de la AEPD, se puede demostrar cuándo y bajo qué condiciones el suscriptor dio su consentimiento.

Las bajas se gestionan a través de un enlace en el pie del newsletter que desactiva (no elimina) el registro tt_address, de modo que el historial de consentimiento se conserva. Las supresiones definitivas conforme al artículo 17 del RGPD (derecho de supresión) se pueden realizar mediante un formulario de eliminación separado o manualmente desde el backend.

## Los problemas frecuentes son los Double-Opt-In en spam y las versiones antiguas de tt_address

El problema dominante es la entregabilidad del correo Double-Opt-In. Si el correo de confirmación acaba en la carpeta de spam, el suscriptor nunca completa el registro. Las causas están casi siempre en el servidor: falta de registro SPF, ausencia de firma DKIM, ausencia de política DMARC. registeraddress en sí no puede mejorar la entregabilidad, porque es un tema del servidor de correo. Recomendamos comprobar la autenticación del correo antes del lanzamiento de un formulario de newsletter con mail-tester.com.

Segundo problema: incompatibilidad con versiones antiguas de tt_address. registeraddress se apoya en ciertos campos de la tabla tt_address. Si tt_address publica una actualización mayor y renombra o retira campos, registeraddress ya no puede escribir correctamente los registros. La solución: actualizar tt_address y registeraddress siempre de forma conjunta y realizar tras la actualización una prueba completa del flujo de registro.

Tercer tema: registros de bots. Sin un mecanismo de protección, los bots rellenan el formulario con direcciones falsas y generan miles de correos Double-Opt-In que sobrecargan el servidor y dañan la reputación del remitente. registeraddress soporta campos honeypot y se puede combinar con sr_freecap o hcaptcha para repeler bots. hcaptcha tiene además la ventaja de alojarse en servidores europeos, lo que simplifica el encaje con el RGPD frente a reCAPTCHA de Google.

## TYPO3 v12 está soportado, la compatibilidad con v13 requiere alineamiento con tt_address

registeraddress corre estable en TYPO3 v11 y v12, siempre que tt_address esté instalada en una versión compatible. Para TYPO3 v13 la compatibilidad depende tanto de registeraddress como de tt_address, ya que ambas extensiones se mantienen de forma independiente. Gosign revisa en los upgrades de TYPO3 toda la cadena del newsletter (registro, gestión de direcciones, envío) en cuanto a compatibilidad y recomienda, si es necesario, pasar a un servicio de newsletter externo con conexión API cuando la solución TYPO3 nativa deje de mantenerse.

--- rflipbook TYPO3 - Libro digital interactivo | Gosign ---
> rflipbook para TYPO3: PDFs como flipbooks interactivos. Configuración, optimización de rendimiento y alternativas modernas.

## rflipbook transforma catálogos y folletos en una experiencia de libro y es la solución más pragmática para equipos de contenido cuando los PDF deben no solo enlazarse, sino seguir vivos en el contexto de la web

Quien mantiene un catálogo de varias páginas, un informe anual o una revista de cliente en PDF se enfrenta a un dilema: como descarga, el documento queda en una vía muerta, el usuario abandona la página y rara vez vuelve. rflipbook lo resuelve renderizando cada página PDF como Canvas y reproduciendo en el navegador el clásico efecto de pasar página del mundo impreso. La extensión aborda un problema editorial concreto: los equipos de marketing, prensa y relación con inversores quieren reutilizar digitalmente los activos impresos existentes sin traducirlos a HTML. rflipbook hace innecesario ese rodeo.

Hay que recordar que rflipbook no es solo técnica de presentación, sino también una señal de contenido. Un sitio que lleva catálogos e informes actuales como flipbook transmite a los clientes potenciales una imagen cuidada, frente a directorios de descargas huérfanos con documentos de años distintos. En lo editorial, por tanto, la introducción exige también aclarar quién actualiza qué PDF y cuándo.

## Escenarios típicos de uso

El caso más frecuente es el catálogo B2B. Un fabricante de maquinaria mantiene su catálogo general en InDesign, exporta un PDF de 80 páginas e integra el archivo mediante rflipbook en la página de producto. Para la redacción nada cambia; para el visitante, una descarga árida se convierte en una experiencia de hojeo con página de portada y función de búsqueda.

El segundo caso de uso son los informes de negocio y de sostenibilidad. Las empresas cotizadas, las fundaciones y las asociaciones publican anualmente informes extensos que no se reescriben. rflipbook incrusta el PDF terminado directamente en la página de relación con inversores y tiende el puente entre la redacción clásica y el equipo web.

Tercer caso: revistas de clientes y empleados. Universidades, ayuntamientos o pymes utilizan rflipbook para ofrecer su revista impresa como edición digital, a menudo con función de archivo y ediciones multilingües por año.

## Arquitectura técnica

rflipbook se integra como extensión TYPO3 clásica mediante un elemento de contenido en el módulo Page. Los redactores cargan el PDF en el FAL, lo vinculan al elemento de contenido y fijan en el backend parámetros como color de fondo, página de inicio y botón de descarga. En el frontend, una librería JavaScript como Turn.js o una librería de renderizado Canvas similar se encarga de la visualización propiamente dicha. PDF.js se utiliza a menudo como parser para descomponer las páginas del PDF en mapas de bits individuales.

La cadena de dependencias es manejable: rflipbook trae las librerías JavaScript en el paquete de la extensión, la propia extensión no necesita paquetes PHP adicionales. La configuración corre por TypoScript para los defaults globales y por el Flexform del elemento de contenido para los ajustes por página. Quien trabaja con EXT:fluid_styled_content puede arrastrar la plantilla mediante overrides Fluid al sitepackage propio y adaptarla a la identidad corporativa.

Es crítica la interacción con la gestión de activos. Los PDF grandes deberían pre-renderizarse en el servidor como JPG individuales; si no, el navegador carga todo de forma síncrona en la primera llamada. El lazy page loading no es una función estándar, pero puede añadirse mediante un pipeline de renderizado propio.

## Problemas frecuentes y soluciones

El problema más frecuente es el tiempo de carga. Un catálogo de 40 páginas con fotos de alta resolución genera fácilmente una payload inicial de varios megabytes, lo que significa puntuaciones Lighthouse en rojo y malos Core Web Vitals. La solución no está en la propia extensión, sino antes de ella: reducir los PDF antes de subirlos a la resolución de pantalla realmente necesaria, idealmente con Ghostscript o un pipeline de build en el servidor, y cargar solo las dos o tres primeras páginas en la primera llamada.

Segundo problema: visualización en dispositivos móviles. El efecto de pasar página funciona mal en pantallas táctiles por debajo de 400 píxeles de ancho, y los redactores se quejan de páginas ilegibles. Solución pragmática: mediante una media query CSS, en móviles cambiar del flipbook a un visor PDF.js simple con vista de scroll vertical. La experiencia de usuario se vuelve más honesta y el tiempo de carga mejora.

Tercer problema: accesibilidad. Los lectores de pantalla no pueden leer PDF renderizados en Canvas, lo que en administraciones e instituciones públicas se convierte en un problema de cumplimiento. El Real Decreto 1112/2018 sobre accesibilidad de los sitios web del sector público exige estándares equivalentes a la EN 301 549. Aquí solo ayuda un planteamiento doble: el flipbook como complemento visual, y junto a él obligatoriamente un enlace directo al PDF original e, idealmente, una versión HTML de los contenidos clave.

## Migración y compatibilidad de versiones

rflipbook es una extensión establecida, pero ya no se desarrolla de forma activa. Para TYPO3 v11 hay una versión operativa; bajo v12 y v13 solo funciona con ajustes manuales al ext_emconf.php y al schema de configuración de servicio. Quien empieza hoy desde cero debería preguntarse si una alternativa ligera no es la mejor opción: un visor PDF.js simple, páginas HTML estáticas a partir del contenido del PDF o un servicio flipbook headless incrustado como iframe. La decisión depende de con qué frecuencia cambia el documento y de qué importancia tiene el efecto visual de pasar página para la marca.

Quien se queda en TYPO3 v11 no debería ver rflipbook como solución duradera. A más tardar al actualizar a v12 hay que decidir, y el plazo para ello debería planificarse pronto. Un proyecto de migración típico abarca el análisis de todos los usos de flipbook en el inventario, la decisión por caso (versión HTML estática, visor PDF ligero o mantener el flipbook), la implementación y la formación editorial. Quien aborda el proyecto de forma estratégica usa la migración también para ordenar los activos: los catálogos obsoletos se archivan, los documentos se reintegran en sus versiones actuales y los metadatos se unifican.

Gosign acompaña ambos caminos: la continuidad de rflipbook en versiones modernas de TYPO3 y la migración a alternativas más eficientes. El análisis asistido por IA ayuda a encontrar la arquitectura adecuada para el caso de contenido concreto, en lugar de entregar una respuesta estándar.

--- FontAwesome CKEditor TYPO3 | Gosign ---
> Insertar iconos FontAwesome directamente en el CKEditor. Gosign también asesora sobre sistemas de iconos SVG como alternativa más eficiente.

## Por qué FontAwesome en el CKEditor beneficia a los editores pero cuesta 300 KB de rendimiento

Los editores quieren colocar iconos junto a titulares, en tablas y entre párrafos de texto. Sin ayuda técnica, copian imágenes de iconos como inline images en el RTE - con layout roto y tamaño inconsistente como resultado. rte_ckeditor_fontawesome resuelve el problema de forma limpia: los editores seleccionan iconos del catálogo FontAwesome directamente en el CKEditor mediante un botón de diálogo y los insertan como tag `<i>` en el texto enriquecido. Los iconos escalan automáticamente con el tamaño del texto, son personalizables en color y funcionan en cualquier elemento de contenido.

El precio: toda la librería FontAwesome (aprox. 300 KB como webfont o 180 KB como sprite SVG) se carga en cada página, aunque solo se usen 3 iconos. Para webs críticas en rendimiento, eso es un overhead notable.

## Escenarios de uso habituales

**Listas con iconos en descripciones de servicios.** Un proveedor de servicios describe sus prestaciones con listas de iconos: marca de verificación ante cada ventaja, rueda dentada ante cada paso del proceso, icono de teléfono ante el número de contacto. El editor inserta los iconos directamente en el CKEditor sin necesitar a un desarrollador.

**Tablas comparativas de funcionalidades.** Los product managers gestionan tablas comparativas en el CKEditor. En lugar de "Sí" y "No" usan iconos de marca verde y cruz roja. rte_ckeditor_fontawesome proporciona estos iconos del catálogo FontAwesome. La tabla se vuelve visualmente comprensible al instante.

**Plantillas de newsletter con iconos.** Empresas que gestionan contenidos de newsletter en el backend TYPO3 y los envían mediante una extensión de newsletter usan iconos FontAwesome para enriquecimiento visual.

## Arquitectura técnica

rte_ckeditor_fontawesome amplía el CKEditor en el backend TYPO3 con un plugin adicional. El plugin registra un botón en la barra de herramientas del CKEditor que abre un diálogo de selección con función de búsqueda y filtro por categoría.

La integración funciona en tres niveles: Plugin CKEditor (plugin JavaScript para CKEditor 4 en TYPO3 v10/v11 o CKEditor 5 en TYPO3 v12+), salida HTML (al insertar, se escribe un tag `<i>` con las clases CSS correspondientes en el richtext) y renderizado frontend (para que los iconos sean visibles en el frontend, la librería CSS de FontAwesome debe cargarse en la web - la extensión no incluye los assets frontend, la integración es responsabilidad del desarrollador).

Nota importante sobre la versión de CKEditor: TYPO3 v12 cambia de CKEditor 4 a CKEditor 5. La arquitectura de plugins ha cambiado fundamentalmente. Los plugins de rte_ckeditor_fontawesome para CKEditor 4 no funcionan en CKEditor 5.

## Problemas frecuentes y soluciones

**Los iconos no se muestran en el frontend.** La causa más frecuente: el CSS de FontAwesome no está incluido en la plantilla frontend. La extensión solo se ocupa del backend (selección de iconos en el CKEditor). La presentación en frontend requiere que `fontawesome.min.css` y los archivos de fuentes asociados se carguen en la plantilla. Solución: añadir FontAwesome como CSS include vía TypoScript.

**Los iconos aparecen como cuadrados vacíos.** Los archivos de fuente (woff2, woff) no se cargan correctamente. Frecuentemente la ruta en el archivo CSS está mal configurada, o el servidor web bloquea archivos de fuente (cabeceras CORS ausentes con integración CDN). Solución: alojar FontAwesome localmente en lugar de vía CDN. Eso evita problemas CORS y es más conforme al RGPD.

**Impacto en rendimiento por FontAwesome.** Una instalación completa de FontAwesome carga más de 300 KB (todas las categorías de iconos: Solid, Regular, Brands). Si la web solo usa 10 iconos, 290 KB están desperdiciados. Solución: usar FontAwesome Subsetting - compilar solo los iconos utilizados en un archivo de fuente personalizado. Alternativa: migrar a un sistema de iconos SVG que incruste solo los iconos realmente usados como SVG inline.

## Migración y compatibilidad de versiones

rte_ckeditor_fontawesome está disponible como extensión estable para TYPO3 v10 y v11 (CKEditor 4). Para TYPO3 v12 (CKEditor 5) existen adaptaciones con la arquitectura de plugins completamente nueva.

Para TYPO3 v13 en adelante, Gosign recomienda una reevaluación fundamental del enfoque. En lugar de cargar FontAwesome como webfont, las webs modernas apuestan por sistemas de iconos SVG: cada icono se incrusta como SVG inline, solo se cargan los iconos utilizados, el tamaño de archivo baja de 300 KB a menos de 10 KB. El esfuerzo de migración de FontAwesome a iconos SVG es típicamente de 2 a 3 días: crear el sprite SVG, adaptar el widget CKEditor, reemplazar los tags `<i>` existentes en el contenido por referencias `<svg>`. Una web corporativa típica usa de 15 a 30 iconos de los más de 2.000 de FontAwesome Free. Un sprite SVG a medida con 30 iconos pesa de 8 a 15 KB - una quincuagésima parte de la librería FontAwesome completa.

--- rte_ckeditor_image TYPO3 - Imágenes en el RTE | Gosign ---
> rte_ckeditor_image: insertar y editar imágenes en CKEditor. Salida responsive, resolución de errores, alternativas.

## rte_ckeditor_image lleva la gestión profesional de imágenes al Rich Text Editor

El CKEditor de TYPO3 solo permite incrustar imágenes sencillas mediante etiqueta img, sin conexión con el File Abstraction Layer y sin variantes responsive. Para redacciones que insertan regularmente imágenes en artículos, noticias o textos de revista eso no basta: necesitan recorte, escalado, texto alternativo, copyright, destino de enlace y, sobre todo, salida srcset. rte_ckeditor_image de Netresearch amplía el CKEditor con justamente esas funciones y lo integra limpiamente en el FAL. En cualquier proyecto TYPO3 con imágenes mantenidas editorialmente en texto corrido, la extensión es desde hace años la herramienta estándar y una de las ayudas de redacción más instaladas del ecosistema.

## Escenarios típicos: redacciones con alto volumen de imágenes

Las revistas digitales y las páginas corporativas de noticias son el público objetivo clásico. Una revista con 200 artículos al año incluye por artículo entre dos y cinco imágenes en el texto corrido, además de imágenes de teaser y de cabecera. Sin rte_ckeditor_image, la redacción tendría que aceptar un cambio de elemento de contenido por cada imagen inline e interrumpir el flujo de texto. Con la extensión inserta la imagen directamente desde un botón de la barra de herramientas, selecciona la referencia FAL, pone el texto alternativo y el pie de imagen y vuelve a escribir sin cambio de contexto. La ganancia de eficiencia es medible en la práctica: en una redacción con 200 publicaciones al año y una media de cuatro imágenes por publicación ahorramos por artículo unos dos minutos de configuración, lo que al año suma cerca de 30 horas de trabajo.

Un segundo escenario son los catálogos de producto y la documentación técnica. Quien mantiene en un catálogo TYPO3 instrucciones paso a paso con capturas inline necesita las imágenes directamente en el texto. rte_ckeditor_image lo permite con las mismas referencias FAL que se usan en el resto del proyecto: las actualizaciones de imágenes se hacen en un solo sitio y tienen efecto en todas partes.

Un tercer escenario es la migración de instalaciones TYPO3 de la era htmlArea. Quien venía usando RTEhtmlArea encontraba allí una gestión de imágenes similar. Al cambiar a CKEditor, rte_ckeditor_image es la extensión de sustitución directa para que los redactores puedan seguir usando el flujo al que estaban acostumbrados. Sin la extensión la redacción no solo pierde una función al actualizar, sino un paso de trabajo completo que solo difícilmente puede sustituirse mediante elementos de contenido adicionales.

## Arquitectura técnica: ampliación de la barra del CKEditor mediante plugin

La extensión consta de un plugin CKEditor que registra el botón de imagen y el diálogo de imagen, y de un renderizado del lado del servidor que traduce el marcador del HTML guardado en una salida Fluid. El plugin se comunica con un endpoint AJAX que procesa la referencia FAL, el recorte y los textos alternativos.

En el contenido de base de datos la imagen queda como marcador HTML con los atributos data-htmlarea-file-uid y data-htmlarea-file-table, acompañados de otros atributos para recorte, zoom y altura. En el renderizado, un pre-processor sustituye la etiqueta marcadora por una llamada completa al ViewHelper Image, que genera srcset, variantes webp y atributos de lazy loading. Los anchos de imagen disponibles se definen por YAML en la configuración del RTE. Una configuración típica de revista trabaja con entre tres y cinco anchos (480, 768, 1024, 1440, 2048) y genera automáticamente un srcset responsive que en dispositivos móviles solo carga la variante más pequeña.

El recorte utiliza la herramienta de cropping del núcleo TYPO3: en el diálogo de imagen aparece el editor de recorte del backend, con los mismos presets de variantes que en el elemento de contenido Image regular. El recorte se guarda por instancia de imagen, de modo que la misma imagen FAL puede recortarse de forma distinta en diferentes artículos. Eso es especialmente importante cuando una imagen se usa tanto en el teaser de revista (cuadrada) como en el texto corrido (apaisada), sin que la redacción tenga que mantener dos archivos separados.

## Problemas frecuentes: salida responsive, WebP y compatibilidad con CKEditor 5

El tema de soporte más habitual es la ausencia de salida srcset. El camino de renderizado por defecto no genera srcset si el YAML del RTE no contiene una definición de anchos de imagen. Muchas instalaciones han copiado el YAML del núcleo TYPO3 y en el proceso han omitido la sección "proc.entryHTMLparser_db.allowedAttribs" o "config.additionalAttributes". La solución es un YAML completo con anchos srcset definidos explícitamente.

El segundo problema es WebP. Quien quiera entregar formatos modernos de imagen debe configurar el provider ImageMagick de TYPO3 o un setup GraphicsMagick con soporte WebP. rte_ckeditor_image no genera por sí mismo la conversión WebP, sino que recurre al Image Processor del núcleo. Sin una configuración correcta del provider, las imágenes se quedan como JPEG en la salida.

En tercer lugar, CKEditor 5 supone un cambio de arquitectura. TYPO3 v12 trae CKEditor 5, que utiliza un modelo de plugins distinto. Las versiones 10.x y 11.x de rte_ckeditor_image están portadas a CKEditor 5 y funcionan en v12 de fábrica. Los ajustes propios basados en CKEditor 4 deben adaptarse al actualizar. Quien haya construido plugins personalizados o botones propios de la barra de herramientas debería reservar entre uno y dos días de desarrollo para la migración.

## La migración a TYPO3 v12 y v13 exige un salto de versión de la extensión

rte_ckeditor_image la mantiene activamente Netresearch y está disponible para TYPO3 v11, v12 y v13. El mayor salto está entre las versiones 9.x (CKEditor 4) y 10.x/11.x (CKEditor 5) de la extensión. Quien eleve una instalación TYPO3 v10 o v11 con la extensión 9.x a TYPO3 v12 debe cambiar al mismo tiempo a la serie 10.x de la extensión. La representación en base de datos de las imágenes inline se mantiene compatible, de modo que los artículos existentes funcionan sin migración de contenido.

En Gosign comprobamos antes de cada upgrade de TYPO3 si el YAML del RTE del proyecto debe adaptarse a la versión de la extensión y si existen ajustes propios de plugin o ViewHelpers sobrescritos. En muchos proyectos con TYPO3 v12 puede comprobarse además si las funciones nativas de imagen de CKEditor 5 son suficientes y la extensión puede retirarse a medio plazo. Para redacciones con necesidad de recorte y srcset, rte_ckeditor_image sigue siendo la opción más pragmática. La alternativa sería un botón de barra de imagen propio con un plugin CKEditor personalizado, lo que es claramente más costoso y deja el mantenimiento en manos del proyecto de forma permanente.

--- rx_shariff TYPO3 - Compartir con privacidad | Gosign ---
> rx_shariff: compartir en redes sociales sin tracking. Botones conformes con el RGPD para TYPO3. Configuración y alternativas.

## Por qué los botones sociales estándar son un problema RGPD y rx_shariff fue la solución

Cada botón de "Me gusta" de Facebook, cada widget de compartir de Twitter y cada embed de LinkedIn transmiten datos personales a la plataforma - y al cargar la página, no al hacer clic. Dirección IP, huella del navegador y referrer fluyen a Facebook antes de que el visitante tenga siquiera la oportunidad de consentir. Eso es legalmente problemático desde la entrada en vigor del RGPD en 2018 y conforme a los criterios de la AEPD, y ya ha dado lugar a advertencias contra operadores de webs.

rx_shariff implementa el principio Shariff que el editorial Heise desarrolló en 2014 como respuesta a este problema: en lugar de integrar los widgets originales de las plataformas, rx_shariff renderiza botones propios conformes con la privacidad. Solo cuando un visitante hace clic en el botón se establece conexión con la plataforma. Sin tracking, sin peticiones a terceros, sin cookies sin interacción.

## Escenarios de uso habituales

**Webs corporativas con requisitos de cumplimiento RGPD.** Una PYME quiere ofrecer botones de compartir en sus artículos de blog sin infringir el RGPD. El delegado de protección de datos ha prohibido explícitamente los widgets estándar de Facebook y Twitter. rx_shariff entrega botones que solo establecen conexión al hacer clic. La política de privacidad se formula correctamente: "Solo al usar activamente los botones de compartir se transfieren datos a terceros."

**Webs de medios con contadores de compartidos.** Una editorial especializada quiere mostrar bajo cada artículo cuántas veces se ha compartido en Facebook y LinkedIn. rx_shariff ofrece esta función mediante un proxy backend opcional: el servidor TYPO3 consulta periódicamente los contadores a las plataformas y cachea los resultados. Las plataformas solo ven el servidor, nunca al visitante individual.

**Portales intranet con compartir controlado.** Una empresa opera una intranet TYPO3 y quiere que ciertos artículos se puedan compartir selectivamente en LinkedIn, pero excluyendo Facebook y Twitter. rx_shariff se configura para que solo aparezcan las plataformas seleccionadas como botones.

## Arquitectura técnica

rx_shariff consta de dos componentes: un widget frontend y un servicio backend opcional. El widget frontend renderiza para cada plataforma configurada un botón HTML como simple anchor link (`<a href="...">`). Al hacer clic se abre la página de diálogo de compartir de la plataforma en una nueva ventana. Sin JavaScript al cargar la página, sin cookies, sin peticiones externas.

El servicio backend (opcional) para contadores de compartidos opera un proxy del lado del servidor. Un script PHP consulta las APIs de las plataformas y cachea los resultados en una tabla de base de datos. El frontend muestra el contador cacheado. El proxy actualiza los contadores cada 15 a 60 minutos vía tarea del Scheduler. Las APIs de las plataformas solo ven la IP del servidor, nunca la IP del visitante de la web.

## Problemas frecuentes y soluciones

**Los contadores de compartidos siempre muestran 0.** Las APIs de las plataformas requieren autenticación. Sin API key válida, Facebook y LinkedIn no entregan contadores. Twitter/X desactivó completamente su API de conteo de compartidos en 2015. Solución: crear una app de Facebook en el Meta Developer Portal y configurar el token de la app en rx_shariff. Para Twitter desactivar el contador.

**Los botones no son visibles tras una actualización TYPO3.** rx_shariff usa un plugin TYPO3 con elemento de contenido propio. Si el plugin ya no está registrado tras una actualización (por ejemplo, por dependencias Composer cambiadas), el elemento de contenido desaparece del frontend. Solución: verificar la extensión en el Extension Manager, actualizar dependencias Composer, ejecutar `vendor/bin/typo3 cache:flush`.

**Compartir en WhatsApp solo funciona en dispositivos móviles.** WhatsApp Web y la app de escritorio no soportan el esquema URL `whatsapp://` de forma uniforme. Solución: en escritorio usar la URL web `https://api.whatsapp.com/send?text=...`, en móvil el esquema de la app. rx_shariff detecta el User Agent y selecciona automáticamente el enlace correcto.

## Migración y compatibilidad de versiones

rx_shariff está disponible como paquete Composer estable para TYPO3 v10 y v11. Para TYPO3 v12 existen forks de la comunidad. El propio proyecto JavaScript Shariff de Heise se puso en modo mantenimiento en 2022.

Para nuevos proyectos desde TYPO3 v12, Gosign recomienda una reevaluación: enlaces de compartir simples (`href="https://www.facebook.com/sharer/sharer.php?u=..."`) son más ligeros que rx_shariff, conformes al RGPD y no necesitan extensión. La desventaja: sin contadores de compartidos. La migración de rx_shariff a enlaces simples requiere típicamente medio día: eliminar el plugin antiguo, crear nuevos partials Fluid para los enlaces de compartir, ajustar CSS. Gosign ha realizado este cambio en varios clientes mejorando el tiempo de carga de página en 150 a 300 ms.

--- SAML2 TYPO3 - Integración SSO | Gosign ---
> SAML 2.0 Single Sign-On directamente en TYPO3, sin Shibboleth SP en el servidor. Alternativa a shibboleth_auth: más sencillo.

## SAML 2.0 permite Single Sign-On en TYPO3 sin instalar Shibboleth en el servidor

Universidades, administraciones públicas y grandes empresas operan proveedores de identidad (IdP) basados en SAML 2.0: Microsoft ADFS, Okta, Keycloak, PingFederate. Quien quisiera usar estas identidades en TYPO3 necesitaba hasta ahora un Shibboleth Service Provider en el servidor web, una capa de software adicional con su propia configuración, sus propios certificados y su propio mantenimiento. La extensión saml2 para TYPO3 hace innecesario el Shibboleth SP. Implementa el SP de SAML 2.0 directamente en PHP y se comunica con el IdP sin middleware. Esto simplifica considerablemente la arquitectura del servidor, especialmente en entornos de hosting compartido o en despliegues con contenedores, donde un Shibboleth SP es difícil de instalar.

Para organizaciones cuyo IdP no soporta OIDC (OpenID Connect), SAML 2.0 es el único camino estandarizado hacia el Single Sign-On. La extensión cubre exactamente ese vacío en el ecosistema TYPO3.

## Los escenarios típicos abarcan intranets universitarias, portales de administraciones públicas y extranets corporativos

El escenario más frecuente es la intranet universitaria. Una universidad opera un IdP Shibboleth en una federación académica (por ejemplo SIR2 o RedIRIS en España). Estudiantes y personal se autentican con sus credenciales universitarias y obtienen acceso a páginas TYPO3 protegidas: apuntes, noticias internas, calificaciones. La extensión saml2 verifica el token de aserción SAML, crea si es necesario un usuario de frontend en TYPO3 y asigna grupos basándose en los atributos del IdP (por ejemplo, estudiantes = grupo "student", docentes = grupo "staff").

Un segundo escenario son los portales de administraciones públicas con conexión a Cl@ve. Cl@ve es la plataforma común de identificación electrónica para servicios públicos en España. SAML 2.0 es uno de los protocolos soportados. Un ayuntamiento puede conectar su sitio web TYPO3 a Cl@ve mediante saml2, de modo que los ciudadanos puedan autenticarse con su DNI electrónico o certificado digital y acceder a servicios personalizados.

Tercer escenario: extranets corporativos. Un fabricante de automoción opera un portal de concesionarios sobre TYPO3. Los concesionarios se autentican a través del IdP corporativo (Microsoft ADFS) y ven listas de precios, material formativo y formularios de pedido asignados a su grupo concesionario. La extensión saml2 mapea los grupos de ADFS a grupos de frontend TYPO3 y controla así el acceso a las áreas de contenido protegidas.

## La arquitectura técnica implementa el SP de SAML 2.0 como librería PHP en TYPO3

saml2 se apoya en la librería PHP onelogin/php-saml (o una implementación equivalente), que cubre íntegramente el Web Browser SSO Profile de SAML 2.0: AuthnRequest, validación de respuestas, parseo de aserciones, verificación de firmas, logout. La librería se incluye como dependencia de Composer y la extensión la registra como servicio de autenticación de TYPO3.

La configuración se realiza desde el backend de TYPO3 o mediante TypoScript: URL de metadatos del IdP (o manualmente: Entity ID, URL SSO, URL SLO, certificado), Entity ID del SP, mapeo de atributos (qué atributo del IdP corresponde a qué campo TYPO3: email, username, firstname, lastname, groups). La extensión soporta tanto SSO iniciado por el SP (el usuario pulsa "Login" en la página TYPO3) como SSO iniciado por el IdP (el usuario llega directamente desde el portal del IdP).

Los usuarios de frontend se crean automáticamente en el primer inicio de sesión y se actualizan en cada acceso posterior. La asignación de grupos puede configurarse de forma estática (todos los usuarios SAML en el grupo X) o dinámica (atributo "role" del IdP = "admin" se traduce al grupo "admin" de TYPO3).

Para el inicio de sesión en el backend (usuarios BE) también es posible configurar SAML, aunque con mayor riesgo: si el IdP deja de estar disponible, no habrá acceso al backend. Recomendamos mantener al menos una cuenta de administrador local como respaldo.

## Los problemas habituales afectan a certificados, desviaciones de hora y mapeo de atributos

El problema más frecuente en integraciones SAML son los certificados caducados o mal configurados. El IdP firma la respuesta SAML con su certificado. Si el certificado del SP no se actualiza después de que el IdP lo rote, la verificación de firma falla y el inicio de sesión se interrumpe con un mensaje de error críptico. La solución: incorporar la rotación de certificados al calendario de mantenimiento. La mayoría de IdPs dan un preaviso de 30 días antes de la rotación.

Segundo problema: desviaciones horarias entre IdP y SP. Las aserciones SAML tienen una ventana temporal (NotBefore / NotOnOrAfter). Si los relojes del servidor IdP y del servidor TYPO3 difieren en más de 120 segundos, la aserción se rechaza como inválida. La solución: configurar NTP en ambos servidores.

Tercer tema: mapeo de atributos incorrecto. Cada IdP nombra los atributos de forma distinta. Microsoft ADFS entrega "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", Keycloak entrega "email", Shibboleth entrega "urn:oid:0.9.2342.19200300.100.1.3". La extensión debe saber bajo qué nombre aparece el atributo de correo electrónico en el token SAML. Un mapeo incorrecto se traduce en campos vacíos en el perfil de usuario de TYPO3. El logging de depuración de los atributos recibidos ayuda a identificar las claves de mapeo correctas.

## TYPO3 v12 está soportado, la compatibilidad con v13 depende de la API de Authentication Service

La extensión saml2 se registra como TYPO3 Authentication Service. Esta API lleva años estable en el core de TYPO3, pero se ha ajustado en puntos concretos en v12 y v13. La versión actual de la extensión funciona sin problemas en v12. Para v13 el registro del servicio de autenticación debe adaptarse a la nueva configuración de servicios. En los proyectos SSO, Gosign verifica que la librería PHP-SAML esté actualizada (parches de seguridad) y que la extensión sea compatible con la versión de TYPO3 desplegada. Si la extensión comunitaria deja de mantenerse, recomendamos como alternativa la extensión oidc, siempre que el IdP soporte OpenID Connect.

--- Schemaker TYPO3 - Schema de ViewHelper | Gosign ---
> Generador de schema de ViewHelper para Fluid. Genera documentación y autocompletado para ViewHelpers propios. Herramienta de desarrollo profesional ...

## Por qué la documentación ausente de ViewHelper frena los proyectos TYPO3

Los Fluid ViewHelper son la columna vertebral de todo desarrollo de plantillas TYPO3. Pero en cuanto un proyecto incluye ViewHelpers propios, comienza el problema: ningún desarrollador conoce todos los parámetros, ningún IDE ofrece autocompletado, y la documentación existe en el mejor de los casos como comentario en el código PHP. Schemaker resuelve este problema generando automáticamente archivos de esquema XSD a partir de las clases PHP. Estos esquemas proporcionan a los IDEs la información necesaria para autocompletado, validación y documentación inline directamente en la plantilla Fluid.

Para equipos con más de un desarrollador TYPO3, no es una cuestión de comodidad sino de productividad. Sin archivos de esquema, cada desarrollador dedica entre 15 y 30 minutos diarios a buscar parámetros de ViewHelper en el código fuente.

## Escenarios de uso habituales

**Proyectos enterprise con más de 20 ViewHelpers propios.** Grandes instalaciones TYPO3 suelen incluir ViewHelpers especializados para formato de precios, verificaciones de permisos, llamadas a API o lógica sectorial. Sin Schemaker, cada nuevo desarrollador debe leer el código fuente para entender los parámetros disponibles. Con Schemaker, abre la plantilla Fluid en PhpStorm o VS Code y recibe sugerencias inmediatamente.

**Desarrollo de extensiones para el TER.** Quien publica extensiones con ViewHelpers propios puede incluir archivos XSD generados con Schemaker. Esto reduce consultas de soporte y mejora la experiencia del desarrollador.

**Onboarding de nuevos desarrolladores.** En una agencia TYPO3, los desarrolladores cambian regularmente entre proyectos. Los esquemas generados por Schemaker funcionan como documentación viva: siempre están actualizados porque se generan directamente del código. En lugar de 2 días de familiarización, son 2 horas.

## Arquitectura técnica

Schemaker analiza clases PHP que heredan de `AbstractViewHelper`. Lee las anotaciones `@param`, las llamadas a `registerArgument()` y los DocBlocks de clase. A partir de ellos genera archivos de esquema XSD asignados al namespace Fluid. La integración funciona vía TYPO3 CLI: `vendor/bin/typo3 schemaker:generate` genera archivos XSD para todos los namespaces de ViewHelper registrados.

Schemaker no tiene dependencias externas más allá del TYPO3 Core y el paquete Fluid Template Engine. No interviene en el proceso de renderizado ni tiene impacto en el rendimiento del sitio en producción - la generación de esquemas se ejecuta exclusivamente en la CLI del entorno de desarrollo.

## Problemas frecuentes y soluciones

**El IDE no muestra autocompletado pese al XSD.** La causa más frecuente: el namespace en la plantilla Fluid no coincide con el namespace del XSD. Schemaker genera esquemas basados en el namespace PHP de las clases ViewHelper. Si en la plantilla Fluid se usa un alias diferente, el IDE no encuentra la asignación. Solución: `xmlns:custom="http://typo3.org/ns/Vendor/Extension/ViewHelpers"` debe corresponder exactamente con el esquema generado.

**El XSD generado no contiene todos los ViewHelpers.** Schemaker solo encuentra ViewHelpers accesibles mediante Composer Autoloading. Extensiones instaladas solo en modo clásico (sin Composer) no se escanean completamente. Solución: migrar a instalación basada en Composer.

**El esquema queda desactualizado tras cambios de código.** Los archivos XSD no se actualizan automáticamente cuando cambian los parámetros de ViewHelper. Solución: integrar la generación de esquemas en la pipeline CI/CD.

## Migración y compatibilidad de versiones

Schemaker fue desarrollado originalmente por Claus Due (equipo FluidTYPO3) y se mantuvo activamente hasta TYPO3 v9. Para v10 y v11 existen forks de la comunidad con funcionalidad limitada.

Para TYPO3 v12 y v13 se recomienda como alternativa el soporte integrado del plugin TYPO3 para PhpStorm, que lee información de ViewHelper directamente del código PHP sin necesidad de archivos XSD separados. El equipo Core de TYPO3 proporciona además esquemas XSD oficiales para los ViewHelper del Core.

Gosign asiste en la evaluación y migra flujos de trabajo de esquemas existentes a toolchains modernos. Esfuerzo típico: 4 a 8 horas por proyecto, incluyendo configuración de IDE para todos los desarrolladores del equipo y documentación de los namespaces de ViewHelper disponibles.

--- sf_event_mgt TYPO3 - Gestión de eventos | Gosign ---
> sf_event_mgt: gestionar eventos, controlar inscripciones, pagos. Configuración y desarrollo personalizado, acelerado con IA.

## sf_event_mgt resuelve el problema de que los eventos sin registro no son eventos

En cuanto un sitio TYPO3 gestiona más de dos citas al año y debe admitir participantes, cualquier solución improvisada a base de listados de páginas, plugins de calendario y formularios Powermail choca con sus límites. sf_event_mgt es la extensión que reúne esos bloques en un verdadero sistema de eventos: gestión de participantes con transiciones de estado, listas de espera con promoción automática, pago a través de varios proveedores y comunicación por correo automatizada durante todo el ciclo de vida de la participación. Quien organiza regularmente en TYPO3 eventos con plazas fijas difícilmente puede prescindir de esta extensión. Torben Hansen ha construido sf_event_mgt desde el principio como una herramienta "nativa Extbase" que encaja sin costuras en instalaciones TYPO3 existentes y se deja sobrescribir en cualquier punto sin forkear la extensión central.

## Escenarios típicos van desde ferias hasta programas académicos

Las universidades utilizan sf_event_mgt para jornadas de puertas abiertas, clases de muestra y programas de formación continua. En la práctica eso significa a menudo: 30 cursos paralelos con capacidad, tarifa y cadena de correo propias para interesado, participante y organizador. La extensión lo gestiona con una única estructura de datos, incluido el multilingüismo para estudiantes internacionales. En una universidad politécnica tipo hemos utilizado sf_event_mgt con alrededor de 400 eventos individuales al año, entre ellos cursos cero, jornadas de laboratorio abierto y encuentros de antiguos alumnos.

Colegios profesionales y cámaras organizan con la extensión jornadas técnicas y seminarios en los que los participantes pagan precios distintos según su condición de miembro. Una instalación típica de una cámara de comercio trabaja con entre 40 y 80 eventos al año, muchos de ellos de pago y con varias clases de precio. Los miembros pagan la tarifa regular, los no miembros un suplemento, los que reservan pronto un descuento. La extensión cubre eso con categorías de precio configurables por evento, sin necesidad de intervención de un desarrollador.

Las empresas, por su parte, utilizan sf_event_mgt para formaciones internas, eventos de cliente y webinars. Especialmente en el ámbito B2B la función de exportación CSV es importante: la lista de participantes pasa después al CRM o a la impresora de acreditaciones in situ. En un grupo industrial con 14.000 empleados hemos conectado la extensión al sistema interno de learning management, de modo que las inscripciones a formaciones acaban automáticamente en el sistema de recursos humanos y la asistencia queda documentada como justificante de formación.

## Arquitectura técnica sobre Extbase y FAL

sf_event_mgt es una extensión Extbase clásica y sigue el patrón MVC de TYPO3. Los modelos centrales son Event, Registration, Location y Organisator, la configuración corre por TypoScript y plantillas Fluid. Casi todo se puede adaptar mediante constants.typoscript o TSconfig, sin forkear la extensión. La variante de plugin ofrece una buena docena de acciones de controlador, desde la vista de lista y detalle pasando por el flujo de registro hasta el filtro de búsqueda y categoría.

Para el pago la extensión aporta una abstracción Payment que soporta Stripe, PayPal, factura y Klarna mediante clases handler. Se pueden conectar proveedores de pago propios implementando una clase PaymentServiceInterface. La liquidación acaba en un log de pagos propio y puede procesarse con el Scheduler de TYPO3. Los pagos fallidos quedan documentados y pueden seguirse desde el backend, sin que los redactores tengan que cambiar a la consola del proveedor de pago.

El sistema de correo se apoya en plantillas Fluid dentro del directorio EXT. Por cada registro se disparan varios mensajes: confirmación al participante, notificación al organizador, recordatorios antes del evento, correo de seguimiento después del evento. Cada uno de esos correos es una plantilla Fluid que puede sobrescribirse mediante SiteSet o PageTS. Los correos se envían a través del TYPO3 Mailer y respetan los ajustes SMTP globales, incluidos SPF y DKIM. Para participantes con plaza reservada en lista de espera hay plantillas separadas que se disparan al producirse la promoción.

## Problemas frecuentes: listas de espera, exportación iCal y ReCaptcha

El tema de soporte más frecuente es la lógica de lista de espera. Cuando un participante cancela, la primera entrada de la lista de espera promociona, pero solo si el administrador ha activado el comando moveUpWaitlistRegistrations mediante el Scheduler. Muchas instalaciones olvidan ese comando y se extrañan de que queden plazas vacías. La configuración lleva cinco minutos, pero sin esa tarea del Scheduler la extensión se queda en modo manual.

Un segundo tema recurrente es la exportación iCal. Los participantes quieren un clic sobre "añadir al calendario" que funcione en Outlook, Apple Calendar y Google Calendar. sf_event_mgt entrega un archivo ICS, pero las zonas horarias correctas y los bloques VTIMEZONE deben configurarse. Si no, el evento aparece en Outlook con una hora de desfase, especialmente crítico en el cambio al horario de verano. Recomendamos, en eventos internacionales, incluir en el ICS tanto la zona horaria local como UTC.

El tercer tema es la protección anti-spam. Los formularios de inscripción públicos atraen bots que inundan las listas de espera. sf_event_mgt soporta campos honeypot y puede acoplarse con ext:kestura_recaptcha o con el captcha nativo de TYPO3. En instalaciones productivas recomendamos combinar ambos mecanismos e incorporar adicionalmente un rate limit por dirección IP, de modo que bots individuales no puedan crear cientos de inscripciones falsas.

## La migración a TYPO3 v12 y v13 no es crítica

sf_event_mgt la mantiene continuamente Torben Hansen y está disponible para TYPO3 v11, v12 y v13. El salto de v10 a v12 no introduce Breaking Changes en la estructura de base de datos, todos los campos se mantienen compatibles. Los ViewHelpers propios de la extensión se han adaptado a la nueva versión de Fluid; las plantillas propias requieren una breve revisión tras la actualización. En particular el Registration Finisher y las plantillas de correo deben comprobarse, porque TYPO3 v12 ha introducido reglas más estrictas para el manejo de errores.

En versiones más antiguas (sf_event_mgt 4.x y anteriores) merece la pena revisar la configuración de pago, porque la API de Stripe ha saltado varias generaciones. La extensión actual soporta Stripe Elements y 3D Secure 2; versiones más antiguas aún trabajaban con Stripe Sources, que entretanto están deprecated. Gosign migra instalaciones sf_event_mgt existentes típicamente en un único paso junto con el upgrade del core TYPO3. Las plantillas Fluid se unifican en identificadores consistentes y las llamadas a ViewHelper obsoletas se detectan y sustituyen automáticamente. En la misma pasada comprobamos si el marcado Schema.org/Event en JSON-LD está al día y si la plantilla de detalle de evento contiene todos los campos para los rich snippets de Google Events.

--- Gallery TYPO3 - Galería de imágenes | Gosign ---
> Extensión de galería de imágenes basada en TYPO3 File Collections. Lightbox, layout Masonry, Lazy Loading.

## Por qué sf_filecollection_gallery resuelve correctamente las galerías de imágenes en TYPO3

Las galerías de imágenes están entre los requisitos más frecuentes en webs corporativas - fotos de producto, imágenes de equipo, documentación de eventos, proyectos de referencia. TYPO3 no trae un elemento nativo de galería. El elemento de contenido estándar "Imágenes" muestra imágenes apiladas o en columnas, pero sin lightbox, sin filtrado y sin opciones de layout flexibles. sf_filecollection_gallery cierra esta brecha usando TYPO3 File Collections como fuente de datos para galerías, con integración lightbox, varios layouts y lazy loading incluidos.

La ventaja decisiva frente a otras extensiones de galería: los editores trabajan con el sistema FAL que ya conocen. Las imágenes se organizan en File Collections, y la galería muestra automáticamente todas las imágenes de la colección asignada. Añadir nuevas imágenes significa: arrastrar la imagen a la colección, listo.

## Escenarios de uso habituales

**Proyectos de referencia y portfolios.** Una agencia de arquitectura muestra en cada página de proyecto de 15 a 40 imágenes en galería. El editor gestiona una File Collection por proyecto. sf_filecollection_gallery renderiza la galería como grid con lightbox. Las descripciones de las imágenes desde los metadatos FAL se muestran automáticamente como pies de foto.

**Documentación de eventos y fotografía de prensa.** Un organizador de ferias documenta cada evento con 50 a 200 fotos. Las imágenes se suben en lotes a una File Collection. sf_filecollection_gallery genera thumbnails automáticamente, optimiza el tiempo de carga mediante lazy loading y muestra la galería en layout masonry.

**Catálogos de producto con representación visual.** Un fabricante de muebles muestra por categoría de producto una galería con fotografías de ambiente. Mediante varias File Collections (una por categoría) y un plugin frontend con filtro de categoría, los visitantes pueden cambiar entre galerías sin recargar la página.

## Arquitectura técnica

sf_filecollection_gallery es una extensión Extbase integrada como plugin TYPO3 en elementos de contenido. La fuente de datos son TYPO3 File Collections del File Abstraction Layer (FAL). La extensión soporta colecciones estáticas (archivos asignados manualmente), colecciones basadas en carpeta (todos los archivos de un directorio) y colecciones basadas en categoría.

Las plantillas Fluid controlan la salida. La extensión incluye plantillas para layout grid, layout masonry y listas simples. sf_filecollection_gallery soporta varias librerías lightbox: Fancybox, PhotoSwipe y Lightcase. Gosign recomienda PhotoSwipe por su mejor soporte táctil y la ausencia de dependencia de jQuery.

Lazy loading está integrado nativamente mediante el atributo `loading="lazy"` y opcionalmente Intersection Observer para navegadores antiguos.

## Problemas frecuentes y soluciones

**La galería no muestra imágenes aunque la File Collection está llena.** La causa suele ser una configuración de Storage incorrecta. La File Collection referencia un Storage al que el frontend no tiene acceso. Solución: verificar en el backend TYPO3 bajo Listado de archivos que las imágenes están en el Storage correcto y este está configurado como "public".

**El lightbox no funciona, las imágenes se abren como nueva página.** La librería JavaScript del lightbox no se carga. Frecuentemente falta un include TypoScript o hay un conflicto con otra librería JavaScript. Con lightboxes basadas en jQuery (Fancybox), un conflicto de versión de jQuery puede ser la causa.

**Tiempo de carga alto con galerías grandes.** Una galería con más de 100 imágenes en alta resolución puede cargar lento si los thumbnails no están suficientemente comprimidos. Solución: configurar TYPO3 Image Processing para generar thumbnails en tamaño fijo (por ejemplo, 400x300px) y calidad optimizada (75-80 %). Activar formato WebP vía la configuración de Image Processing de TYPO3.

## Migración y compatibilidad de versiones

sf_filecollection_gallery se mantiene activamente y está disponible para TYPO3 v11 y v12 LTS. La extensión tiene una API estable y apenas breaking changes. Al actualizar TYPO3 de v10 a v12 debe revisarse la configuración del lightbox. Gosign recomienda migrar de Fancybox a PhotoSwipe, que funciona sin jQuery y ofrece mejor rendimiento en dispositivos móviles. La migración de Fancybox a PhotoSwipe requiere típicamente de 4 a 8 horas.

--- sf_register TYPO3 - Registro en frontend | Gosign ---
> sf_register: registro de usuarios en el frontend de TYPO3. Gestión de perfiles, Double-Opt-In. Acelerado con IA.

## Por qué TYPO3 sin extensión de registro no puede convertirse en un portal de usuarios

El núcleo de TYPO3 conoce fe_users como tabla de base de datos y una máscara de login estándar, pero no ofrece ninguna forma de que un nuevo usuario se registre por sí mismo, mantenga sus datos o restablezca su contraseña. Toda web que sea algo más que un mero órgano de publicación necesita esa funcionalidad: comunidades, áreas para miembros, descargas protegidas, boletines personalizados, contenidos de pago. sf_register cubre ese hueco con un enfoque ligero basado en Extbase que se concentra precisamente en registro, perfil y restablecimiento de contraseña y renuncia deliberadamente a las funciones que ofrece de serie la solución integral femanager.

## Escenarios típicos de uso

Una editorial especializada con 3.500 suscriptores ofrece acceso en línea a artículos y estudios. Cada suscriptor recibe una cuenta vinculada a su número de suscripción. sf_register asume el registro inicial con confirmación Double-Opt-In por correo, crea al usuario automáticamente en el grupo "suscriptor" y activa el acceso a las páginas protegidas. Cuando caduca la suscripción, una tarea del scheduler de TYPO3 retira la pertenencia al grupo sin borrar la cuenta, de modo que el usuario recupera el acceso tras una renovación del contrato.

Un segundo caso es un colegio profesional con alrededor de 7.000 empresas miembros, que opera un portal de miembros protegido con documentación de jornadas, borradores de normas y foros de debate. sf_register permite el registro inicial pero dispara al mismo tiempo un proceso manual de autorización en el que un empleado del colegio verifica la pertenencia a la empresa miembro antes de activar la cuenta. El flujo combina Double-Opt-In con una aprobación del administrador y utiliza los event hooks de la extensión.

El tercer contexto son instituciones públicas como escuelas de idiomas municipales o bibliotecas ciudadanas que quieren vincular inscripciones a cursos o listas de lecturas del catálogo a una cuenta de usuario. Aquí lo que importa sobre todo es la configuración sencilla y la baja complejidad: la extensión no debe gestionar veinte campos de perfil, sino nombre, correo, contraseña y un número de usuario de biblioteca, no hace falta más, y sf_register entrega exactamente eso.

## Arquitectura técnica: Extbase, TCA y finishers

sf_register está construido limpiamente según el modelo Extbase. Un modelo FrontendUser propio amplía el usuario del núcleo, las acciones del controlador manejan Create, Edit, Confirm y ResetPassword, y el templating corre a través de layouts Fluid. Los campos obligatorios se gestionan mediante configuración TCA y pueden ampliarse con un archivo de configuración propio de la extensión. Campos personalizados como empresa, cargo o número de socio requieren una pequeña entrada TCA, una propiedad del modelo y una adición en la plantilla Fluid, lo que da a los desarrolladores una estructura clara pero también implica que cada ajuste supone trabajo de código.

El proceso Double-Opt-In se basa en enlaces de confirmación con hash que se almacenan como token temporal en la tabla fe_users y que, tras el clic, restablecen el flag disable. La extensión envía correos a través del TYPO3 Mailer, que internamente se apoya en Symfony Mailer, de modo que también funcionan sin problema configuraciones más complejas con proxies SMTP o servicios de correo como SendGrid. El hashing de contraseña utiliza los servicios de hash propios de TYPO3 y se mantiene así automáticamente sincronizado con cada actualización del núcleo.

## Problemas frecuentes y soluciones

El primer problema son los registros spam. Toda página de registro pública atrae bots que crean cuentas automáticamente para enviar correos a terceros a través del formulario de reset de contraseña o para colocar spam trackback en funciones de comunidad. Una solución limpia combina sf_register con una extensión CAPTCHA como sr_freecap o un campo honeypot, complementados con rate limiting sobre la URL de registro en el proxy inverso.

El segundo problema afecta a la entrega de correo. Los correos de confirmación acaban regularmente en la carpeta de spam cuando el servidor TYPO3 se opera sin registro SPF, firma DKIM o DNS inverso. La extensión envía el correo correctamente, pero el servidor receptor lo descarta silenciosamente. La solución no está en sf_register, sino en la infraestructura de correo: un servicio de envío dedicado con reputación de dominio asentada reduce perceptiblemente la tasa de rebote.

El tercer tema es la protección de datos. Los usuarios registrados deben poder consultar, corregir y eliminar sus datos en cualquier momento, y la eliminación debe tener efecto en cascada, es decir, abarcar también pedidos, descargas y otros registros enlazados. La AEPD exige con especial rigor ese derecho al borrado en los procedimientos sancionadores. sf_register ofrece formularios de edición, pero no un proceso de borrado conforme al RGPD. Ese proceso debe añadirse como flujo propio, en el que la eliminación de la cuenta anonimiza los datos dependientes, ya sea de inmediato o tras un plazo transitorio.

Un cuarto problema habitual son las políticas de contraseña. sf_register acepta por defecto también contraseñas débiles, y los usuarios tienden a usar combinaciones cortas o triviales. Las Password Policies de TYPO3 pueden activarse a través de la configuración del sistema, de modo que sf_register aplica automáticamente longitud mínima, clases de caracteres y comprobaciones de blacklist sin necesidad de modificar la extensión.

## Migración y compatibilidad de versiones

sf_register es estable para TYPO3 v11 y v12 y tiene en la comunidad la reputación de ser una alternativa sólida y mantenible a femanager. El soporte para v13 suele estar disponible poco después del release de un nuevo núcleo TYPO3, pero en extensiones personalizadas requiere una revisión de la sintaxis de anotaciones Extbase, que entre versiones ha tenido pequeños ajustes.

Quien migra de femanager a sf_register ahorra complejidad, pero debe comprobar qué funciones se utilizaban realmente: femanager ofrece confirmación del administrador, subida de foto de perfil y moderación en backend de serie, mientras que sf_register solo replica esas funciones mediante código adicional o event listeners. A la inversa, la ruta de migración de sf_register a femanager es más sencilla, porque la estructura de datos es en gran medida compatible. Gosign asume esas migraciones incluyendo la portabilidad de plantillas de correo y el ajuste de grupos de usuarios, de modo que los usuarios existentes pueden seguir iniciando sesión sin problemas tras el cambio.

Quien monta un proyecto nuevo debería repasar los requisitos reales del portal antes de elegir: ¿necesita el operador autorizaciones manuales, fotos de perfil, asignaciones de roles complejas? Entonces femanager es el camino más rápido. ¿Basta un registro de autoservicio ligero con una base Extbase limpia y poca carga adicional? Entonces sf_register es la opción adecuada. La decisión rara vez es ajustada una vez que se repasa el catálogo de funciones necesarias, y ahorra más adelante un considerable esfuerzo de reconstrucción.

--- sg_forms TYPO3 - Formularios | Gosign ---
> Extensión de formularios de SGalinski. Alternativa a Powermail y al Form Framework nativo de TYPO3. Para proyectos con requisitos específicos de formularios.

## Tres sistemas de formularios en TYPO3 generan más confusión que oferta

Los proyectos TYPO3 se encuentran ante un lujo poco habitual a la hora de implementar formularios: existen tres opciones serias. El Form Framework nativo de TYPO3 (ext:form), powermail de in2code y sg_forms de SGalinski. Cada solución tiene sus propias fortalezas y sus propios límites. sg_forms se posiciona como un punto intermedio: más ligero que powermail, pero con mayor comodidad en el backend que ext:form. La extensión procede del proveedor TYPO3 SGalinski y se usa activamente en sus proyectos con clientes.

Quien ya utiliza otras extensiones de SGalinski (sgalinski_base, sg_cookie_optin) encuentra en sg_forms una solución que encaja sin fricciones en el ecosistema SGalinski.

## Los escenarios típicos son formularios de contacto, peticiones y formularios de candidatura sencillos

El escenario estándar es el formulario de contacto en un sitio web corporativo. Nombre, correo electrónico, asunto, mensaje, casilla de RGPD, enviar. sg_forms entrega este setup como plantilla preconfigurada que los redactores pueden activar y ajustar desde el backend. Se pueden añadir, eliminar y reordenar campos, marcar campos obligatorios y definir validaciones. El correo electrónico llega a una o varias direcciones de destinatarios configurables.

Un segundo escenario son los formularios de solicitud multipágina. Un taller de reformas pregunta en la página 1 los datos de contacto, en la página 2 el tipo de servicio (desplegable) y en la página 3 fotos del objeto (carga de archivos). sg_forms soporta formularios multipaso con indicador de progreso y navegación hacia atrás. Los datos se guardan tras el envío como correo electrónico y, opcionalmente, como registro en la base de datos.

Tercer escenario: formularios de candidatura sencillos. Una pyme con tres vacantes no necesita un sistema de gestión de candidatos, pero sí un formulario que acepte currículum y carta de presentación como PDF y los remita al departamento de recursos humanos. sg_forms ofrece para ello la carga de archivos con validación de tipo y tamaño, combinada con un correo de confirmación al candidato.

## La arquitectura técnica se basa en Extbase con definición de formularios en YAML

sg_forms registra un plugin Extbase que renderiza formularios a partir de una configuración. La definición del formulario se crea desde el backend mediante una interfaz gráfica o, alternativamente, se define como archivo YAML. Cada campo tiene un tipo (texto, correo, área de texto, selector, radio, casilla, archivo, oculto), reglas de validación y condiciones opcionales.

La arquitectura de finalizadores sigue el mismo patrón que powermail: tras el envío se ejecutan acciones sucesivas. Los finalizadores estándar son envío de correo, guardado en base de datos y redirección a una página de agradecimiento. Los finalizadores personalizados se implementan como clases PHP, por ejemplo para integraciones CRM o llamadas a webhooks.

El renderizado en el frontend se realiza mediante plantillas Fluid que pueden sobrescribirse por SiteSet o TypoScript. La extensión incluye una plantilla por defecto que funciona sin ajustes, aunque para sitios en producción suele adaptarse a la identidad corporativa. La protección anti-spam está disponible mediante campos honeypot e integración opcional de CAPTCHA.

## Los problemas habituales afectan a la delimitación frente a powermail y a la licencia de SGalinski

La pregunta más frecuente es: ¿sg_forms o powermail? La respuesta depende del tamaño del proyecto. powermail tiene la comunidad más grande, más documentación, más finalizadores de terceros y una paleta de funciones más amplia (exportación a PDF, lógica multipaso de cualquier complejidad). sg_forms es más ligero, tiene menos sobrecarga y es el estándar en proyectos SGalinski. Para la mayoría de sitios web corporativos, powermail es la opción más segura. Para clientes de SGalinski que ya están dentro del ecosistema, sg_forms es la más coherente.

Segundo tema: la licencia. sg_forms no está disponible como extensión gratuita en el TER (TYPO3 Extension Repository), sino que se entrega a través de proyectos de SGalinski. Esto significa que los equipos que quieran usar la extensión sin una relación con SGalinski deben aclarar directamente con SGalinski su disponibilidad y las condiciones de licencia.

Tercer problema: la migración. Quien cambia de powermail a sg_forms (o al revés) tiene que recrear todas las definiciones de formulario existentes, porque las estructuras de datos son incompatibles. Las entradas de formulario almacenadas en la base de datos no pueden migrarse automáticamente.

## TYPO3 v12 está soportado, v13 sigue el ciclo de lanzamientos de SGalinski

SGalinski mantiene sg_forms en su propio ciclo de lanzamientos, acoplado a las versiones LTS de TYPO3. TYPO3 v12 está soportado activamente. Para v13 cabe esperar una actualización en cuanto SGalinski actualice su propia suite de extensiones. Gosign recomienda, a la hora de elegir sistema de formularios, sopesar el mantenimiento a largo plazo y el tamaño de la comunidad como factores de decisión: powermail, con más de 500.000 instalaciones, tiene una base más amplia que sg_forms, lo que en los upgrades de TYPO3 se traduce en menores tiempos de espera hasta disponer de versiones compatibles.

--- Shibboleth TYPO3 - Base SSO | Gosign ---
> Extensión base de Shibboleth para TYPO3 (hermana de shibboleth_auth). Configuración del Service Provider, gestión de sesiones.

## Universidades y centros de investigación necesitan SSO Shibboleth directamente en TYPO3

En el sector académico, Shibboleth es el estándar de facto para Single Sign-On. Más de 3.000 instituciones en todo el mundo están organizadas en federaciones Shibboleth; en España, SIR2 (Servicio de Identidad de RedIRIS) agrupa a decenas de universidades y centros de investigación. La extensión Shibboleth para TYPO3 integra el Service Provider directamente en el CMS. Estudiantes, docentes y personal se autentican con sus credenciales universitarias y obtienen acceso a áreas de frontend protegidas y, en caso necesario, al backend de TYPO3. La extensión es la hermana de shibboleth_auth y ofrece la integración básica con el SP Shibboleth, que debe estar instalado en el servidor web.

A diferencia de la extensión saml2, que implementa su propio SP en PHP, la extensión shibboleth se apoya en el Service Provider nativo de Shibboleth (C++ o Java), que funciona como módulo de Apache o filtro ISAPI. Es la arquitectura más robusta para entornos de alta disponibilidad.

## Los escenarios típicos afectan a SIR2, sistemas bibliotecarios y portales de investigación

El escenario principal es la integración SIR2 en universidades españolas. Una universidad opera su portal web sobre TYPO3. Los estudiantes pulsan "Iniciar sesión", son redirigidos al IdP de la universidad, se autentican y regresan a la página TYPO3 con una sesión activa. La extensión lee los atributos Shibboleth desde las variables de entorno del servidor (REMOTE_USER, eppn, mail, affiliation) y crea o actualiza el usuario de frontend en TYPO3.

Un segundo escenario son los accesos bibliotecarios. Las bibliotecas universitarias ofrecen bases de datos en línea, revistas electrónicas y documentos de investigación a través de su sitio TYPO3. El acceso queda limitado a miembros de la universidad. La extensión Shibboleth comprueba el atributo "eduPersonEntitlement" y solo concede acceso al contenido licenciado a los usuarios con el valor "urn:mace:dir:entitlement:common-lib-terms".

Tercer escenario: portales de investigación federados. Un consorcio de investigación con socios de cinco universidades opera un portal conjunto sobre TYPO3. Cada socio tiene su propio IdP. A través de SIR2 o eduGAIN, todo el personal de los socios puede autenticarse sin que el portal tenga que gestionar cuentas propias. La extensión asigna a los usuarios al grupo de socio correcto basándose en el atributo "schacHomeOrganization".

## La arquitectura técnica requiere un SP Shibboleth instalado en el servidor web

La propia extensión no contiene pila SAML. Lee los atributos que el SP Shibboleth pone a disposición como variables de entorno del servidor o cabeceras HTTP tras una autenticación satisfactoria. El SP debe estar configurado como módulo de Apache (mod_shib) o como FastCGI Authorizer. Para entornos nginx se necesita un SP Shibboleth como backend FastCGI o un proxy basado en lua.

La extensión TYPO3 registra un Authentication Service que, en cada inicio de sesión de frontend o backend, comprueba si existen atributos Shibboleth. Si los hay, los atributos se mapean a campos del usuario TYPO3: REMOTE_USER a username, mail a email, givenName y sn a first_name y last_name. La asignación de grupos se hace mediante el atributo "eduPersonAffiliation": student, faculty, staff, employee se mapean a grupos de frontend TYPO3.

La gestión de sesiones sigue el ciclo de vida de Shibboleth: cuando la sesión Shibboleth expira, el usuario TYPO3 se desconecta automáticamente. El Single Logout (SLO) lo gestiona el SP Shibboleth; la extensión TYPO3 reacciona al evento de logout y destruye la sesión TYPO3.

## Los problemas habituales afectan a la configuración de Apache y a atributos ausentes

El mayor problema es una configuración correcta de Apache. El SP Shibboleth debe saber qué URLs debe proteger. Una directiva Location mal definida hace que el SP proteja todas las páginas (incluyendo las públicas) o ninguna. La configuración estándar protege /Shibboleth.sso/* para el propio SP y /typo3/ para el backend. Las áreas de frontend se protegen mediante Lazy Session: el SP asigna atributos cuando existe una sesión Shibboleth, pero no fuerza la autenticación. La extensión comprueba entonces en el frontend TYPO3 si existen atributos y muestra el contenido protegido solo a los usuarios autenticados.

Segundo problema: atributos ausentes o vacíos. No todos los IdPs entregan todos los atributos. Si el IdP no libera el atributo "mail", la extensión no puede escribir ninguna dirección de correo en el usuario TYPO3. La solución: aclarar con el responsable del IdP (el centro de cálculo) qué atributos se liberan para el SP y configurar el mapeo de atributos en consecuencia.

Tercer tema: despliegues en contenedores. Las instalaciones TYPO3 basadas en Docker a menudo no tienen Apache con mod_shib. La alternativa es un SP Shibboleth como proxy inverso delante del contenedor TYPO3, que reenvía los atributos como cabeceras HTTP. La extensión debe configurarse entonces para leer los atributos desde cabeceras en lugar de variables de entorno. Importante: las cabeceras deben protegerse frente a spoofing, eliminando en el proxy inverso cualquier cabecera entrante que use nombres de atributos Shibboleth.

## TYPO3 v12 funciona, la compatibilidad con v13 exige revisar la API de Authentication Service

La extensión shibboleth utiliza la TYPO3 Authentication Service API, que lleva años estable pero que en v13 ha recibido ajustes. Bajo TYPO3 v12 la versión actual funciona sin problemas. Para v13 hace falta una actualización del registro del servicio y de la configuración del middleware. Las universidades que planifican upgrades de TYPO3 deberían incluir la integración SSO como bloque de pruebas propio en la planificación del upgrade. Gosign recomienda evaluar en paralelo a shibboleth la extensión oidc, porque muchos IdPs soportan hoy en día tanto SAML como OIDC, y OIDC permite una arquitectura más sencilla sin SP Shibboleth en el servidor.

--- shibboleth_auth TYPO3 - Integración SSO | Gosign ---
> Shibboleth SSO en TYPO3: configuración, mapeo de atributos y resolución de problemas. Autenticación enterprise con desarrollo acelerado con IA.

## Cómo las universidades conectan sus portales TYPO3 a la gestión central de identidades

Quien opera un portal TYPO3 en una universidad española no puede ignorar Shibboleth. La Federación Española de Identidad (SIR2) de RedIRIS gestiona la mayor infraestructura de identidad federada del mundo académico e investigador de España, y cualquier universidad que quiera ofrecer datos de investigación, material docente o servicios administrativos al exterior debe autenticar a sus usuarios contra un Identity Provider Shibboleth. shibboleth_auth es la extensión que integra TYPO3 en ese paisaje: lee las SAML Assertions de un Shibboleth Service Provider en cascada y crea sobre esa base fe_users y be_users.

## Escenarios típicos de uso

Una facultad de medicina con 8.000 estudiantes opera un portal TYPO3 para los planes docentes clínicos. Los estudiantes deben ver el material docente tras iniciar sesión, y los profesores, además, una interfaz editorial. El IdP Shibboleth central de la universidad entrega los atributos eduPersonAffiliation, schacHomeOrganization y un identificador unívoco. shibboleth_auth se encarga del mapeo de esos atributos a grupos TYPO3 y garantiza que un estudiante nunca acceda al backend, mientras que un profesor acaba automáticamente en el grupo de redactores.

Un segundo caso habitual son los centros de investigación extrauniversitarios como el CSIC o institutos conectados a UAM y UCM. Sus trabajadores provienen de docenas de universidades asociadas, y cada uno debe poder iniciar sesión con su identificador de origen en los portales centrales de proyecto. shibboleth_auth, combinado con un SP conectado a eduGAIN, hace justamente eso posible: un investigador invitado desde Zúrich se autentica con su cuenta SWITCHaai en un portal español sin que exista una cuenta local.

El tercer contexto es la administración pública, donde comunidades autónomas y ministerios operan cada vez más IdPs centrales para unificar cuentas ciudadanas y accesos de personal. Un organismo autonómico con varios portales TYPO3 para distintas áreas puede conectar todos los portales al IdP central a través de shibboleth_auth y ahorrarse gestiones de usuarios separadas por portal.

## Arquitectura técnica entre SP, SAML y fe_user

shibboleth_auth está construido de forma distinta a los servicios de autenticación clásicos de TYPO3: la extensión no habla SAML directamente, sino que delega el protocolo entero a un Shibboleth Service Provider instalado localmente. El SP, típicamente el demonio shibd con mod_shib en Apache o el módulo correspondiente de Nginx, procesa la SAML Assertion, valida firmas y certificados y expone los atributos extraídos como variables de entorno HTTP. shibboleth_auth lee esas variables, crea o actualiza el fe_user y lo introduce en la sesión de TYPO3.

La extensión se configura mediante la configuración de extensión de TYPO3 y el patrón de servicios Extbase para proveedores de autenticación. El mapeo de atributos está en un fichero TypoScript o directamente en el backend de la extensión: variable HTTP a la izquierda, nombre del campo TYPO3 a la derecha, opcionalmente con transformaciones para IDs de grupo. Es importante el orden en la configuración $TYPO3_CONF_VARS['SVCONF']['auth']['setup'], para que shibboleth_auth actúe antes del servicio de login estándar.

## Problemas frecuentes y soluciones

El error más habitual es un bucle de redirección: el usuario es enviado al IdP, vuelve, es enviado de nuevo al IdP, y así sucesivamente. La causa es casi siempre una discrepancia entre el dominio de sesión del SP y el de TYPO3, o una cookie ausente porque el SP escribe su sesión en una ruta diferente a la que TYPO3 espera. La solución es una separación limpia: sesión del SP en la ruta /Shibboleth.sso, sesión de TYPO3 bajo / y ambas bajo el mismo dominio de primer nivel.

El segundo problema afecta a los atributos: el IdP entrega un nombre de atributo distinto al que espera la extensión. Especialmente en federaciones académicas cambian los espacios de nombres de atributos entre notaciones OID y URN. Sin una normalización adecuada, el usuario no acaba en ningún grupo o recibe un nombre vacío en su perfil. Un archivo attribute-map en el SP, que unifica nombres antiguos y nuevos en un nombre local común, resuelve el problema de forma duradera.

El tercer tema es la rotación de certificados. Todo IdP renueva sus certificados de firma y cifrado periódicamente, típicamente cada dos años. El SP debe obtener los nuevos certificados a través del metadata feed, o de lo contrario la validación de la Assertion deja de funcionar de repente. La configuración del metadata provider en shibboleth2.xml debería ejecutarse siempre con un intervalo de refresh automático de pocas horas y con verificación de firma contra el firmante de la federación.

Un cuarto ámbito son las duraciones de sesión. Las sesiones de Shibboleth y TYPO3 tienen timeouts independientes: si la sesión del SP caduca mientras la de TYPO3 sigue activa, el usuario ve sus contenidos protegidos, pero un nuevo login falla porque el SP ya no tiene una Assertion válida. La solución limpia es ajustar ambas duraciones al mismo valor y configurar un comportamiento de logout paralelo, de modo que el Single Logout termine efectivamente ambas sesiones.

## Migración y compatibilidad de versiones

shibboleth_auth acompañó durante mucho tiempo, mediante forks comunitarios, a las versiones de TYPO3 v9, v10 y v11. La situación en v12 y v13 difiere según la rama del fork. Algunas ramas han dado el salto a servicios de autenticación basados en Symfony, otras se han quedado en v11. Quien migra actualmente a v12 debería comprobar antes del upgrade si el fork que utiliza sigue mantenido o si un cambio a la extensión OIDC es la mejor opción.

La ruta de migración de Shibboleth a OIDC se ha vuelto relevante para muchas universidades desde que Keycloak y brokers de identidad similares pueden conectar clientes SAML y OIDC en paralelo. Gosign ha acompañado varios de esos cambios y opera durante la fase de transición, por regla general, ambos caminos de autenticación en paralelo, de modo que los sistemas legacy siguen iniciando sesión por Shibboleth mientras los nuevos portales hablan OIDC directamente.

Quien permanece en shibboleth_auth a largo plazo debe evaluar de forma realista la carga de mantenimiento. La extensión misma cambia poco, pero la infraestructura que la rodea sí cambia regularmente: Shibboleth SP publica actualizaciones de seguridad, las federaciones académicas actualizan metadatos y certificados, se renuevan versiones de Apache o Nginx, y cada uno de esos cambios puede romper el flujo de login. Una supervisión adecuada del pipeline de autenticación con logins sintéticos y alertas ante Assertions fallidas no es, por tanto, un lujo, sino parte del plan operativo para una integración SSO estable.

--- Slick Carousel TYPO3 - Slider | Gosign ---
> Integración de Slick Slider para TYPO3. Basado en jQuery. Gosign migra a Swiper o Splide: sin jQuery necesario, mejor rendimiento, eventos táctiles nativos ...

## Slick Carousel obliga a las webs TYPO3 a cargar jQuery, aunque hace años que existen alternativas sin él

Slick (de Ken Wheeler) fue entre 2014 y 2020 el slider JavaScript más popular. Para TYPO3 existe con slickcarousel una extensión que integra Slick como elemento de contenido. El problema en 2026: Slick depende de jQuery. El último release data de 2017 (v1.8.1). Sin actualizaciones desde hace más de 8 años, sin correcciones de errores, sin parches de seguridad.

jQuery ya lo necesitan cada vez menos proyectos TYPO3. TYPO3 v12 y v13 no incluyen jQuery por defecto. Quien usa Slick Carousel debe cargar jQuery (90 KB minificado) como dependencia adicional, solo para el slider.

## Escenarios de uso habituales

**Carruseles de imágenes en subpáginas.** Páginas de producto o galerías con 5 a 20 imágenes como slider horizontal con flechas de navegación y dots opcionales. Los datos de analítica muestran que los usuarios rara vez pasan de la tercera imagen.

**Sliders de testimonios.** Citas de clientes que rotan como carrusel. Cada slide muestra cita, nombre y opcionalmente foto.

**Slider de logos para referencias.** Una barra horizontal con 10 a 30 logos de clientes en rotación automática. Este escenario se puede reemplazar fácilmente por una solución solo CSS (animación CSS con @keyframes), completamente sin JavaScript.

## Arquitectura técnica

La extensión slickcarousel para TYPO3 incluye la librería Slick (slick.min.js, 43 KB) y el CSS asociado (8 KB). jQuery (90 KB) se carga como dependencia. El elemento de contenido permite configurar: slides to show, autoplay, velocidad, dots, flechas, efecto fade, breakpoints responsive. La configuración se almacena como atributo data en el contenedor del slider.

## Problemas frecuentes y soluciones

**El slider salta al cargar (Layout Shift).** Slick inicializa por JavaScript. Hasta que el script carga, todas las imágenes se muestran apiladas verticalmente. Luego el layout salta generando un Cumulative Layout Shift (CLS) medible. Solución a corto plazo: reglas CSS que dimensionen el contenedor antes de la inicialización JavaScript. Solución a largo plazo: migrar a una librería que evite CLS nativamente.

**Los eventos táctiles no funcionan consistentemente.** El manejo táctil de Slick se basa en una implementación propia que ya no funciona correctamente en versiones actuales de iOS y Android. No hay fix posible porque Slick ya no se mantiene. La migración es la única opción.

**Deficiencias de accesibilidad.** Slick genera markup que no cumple WCAG: faltan ARIA labels, no hay navegación por teclado, autoplay sin botón de pausa. Conforme a la Directiva Europea de Accesibilidad y la normativa española vigente, las webs nuevas deben cumplir WCAG 2.1 AA. Slick Carousel no pasa ese test.

## Migración y compatibilidad de versiones

La extensión slickcarousel soporta TYPO3 v10 y v11. Para v12 y v13 no hay release oficial (estado: abril 2026). La librería Slick está congelada desde 2017.

Gosign migra sliders Slick a Swiper (175+ funcionalidades, touch-native, sin jQuery, 40 KB) o Splide (conforme a WCAG, sin jQuery, 30 KB). La migración incluye tres pasos: inventariar configuraciones, integrar la nueva librería, adaptar plantillas Fluid. Por slider, de 2 a 4 horas. Para una web con 5 tipos de slider diferentes, el proyecto se completa en 2 a 3 días.

Para sliders de logos, Gosign recomienda una solución pura CSS: una animación CSS (`@keyframes scroll`) mueve los logos horizontalmente. Resultado: 0 KB overhead JavaScript. Para sliders de testimonios y contenido, Splide es la recomendación por su soporte ARIA completo y navegación por teclado.

La mejora media de PageSpeed en proyectos migrados de Slick a Splide fue de 12 a 25 puntos, primordialmente por la eliminación de jQuery y el menor tamaño de librería.

--- Horarios de apertura TYPO3 | Gosign ---
> Gestión de horarios de apertura para TYPO3: horarios regulares, festivos, horarios especiales. Muestra el estado actual (abierto/cerrado). Para...

## Los visitantes quieren saber si una institución está abierta ahora, no consultar los horarios regulares

La pregunta más frecuente que se hacen los visitantes del sitio web de una biblioteca, un museo o una administración pública es sencilla: ¿están abiertos ahora? Pese a ello, la mayoría de sitios TYPO3 muestran una tabla estática con los horarios regulares, que resulta incorrecta en festivos, puentes y cierres especiales. slub_web_openhours resuelve exactamente ese problema. La extensión gestiona horarios regulares, festivos y aperturas especiales en una única estructura de datos y muestra en el frontend el estado actual en tiempo real: Abierto (verde) o Cerrado (rojo), incluyendo la próxima apertura. La extensión fue desarrollada por la SLUB de Dresde (Biblioteca Estatal y Universitaria de Sajonia), que conoce el problema desde la práctica.

## Los escenarios típicos afectan a bibliotecas, museos e instituciones municipales

El escenario principal son las bibliotecas universitarias con varias sedes. La SLUB de Dresde gestiona cuatro sedes con horarios de apertura diferentes. La sede central tiene horarios distintos a la biblioteca sucursal y, durante las vacaciones del semestre, se aplican horarios reducidos. slub_web_openhours gestiona cada sede como un registro propio con sus propios horarios. En el sitio web, un estudiante ve al instante qué sede está abierta en ese momento y hasta qué hora.

Un segundo escenario son museos y galerías. Un museo de arte tiene horarios regulares (martes a domingo de 10 a 18, lunes cerrado), pero horarios ampliados durante una exposición temporal (todos los días hasta las 21) y cierres en festivos. La extensión permite registrar esas excepciones para periodos definidos sin modificar los horarios regulares. Una vez vencido el periodo especial, vuelven a aplicarse automáticamente los horarios estándar.

Tercer escenario: instituciones municipales como oficinas de atención al ciudadano, piscinas y centros juveniles. Una ciudad con 20 instalaciones públicas gestiona los horarios de forma centralizada en el backend de TYPO3. En la página de cada instalación, un widget muestra el estado actual. En verano, la piscina al aire libre tiene horarios distintos a los de invierno, y en los puentes la oficina de atención al ciudadano permanece cerrada. Todo ello se refleja a través de la extensión.

## La arquitectura técnica almacena reglas y excepciones en una estructura calendárica

La extensión define tres niveles de datos: horarios regulares (de lunes a domingo, hora:minuto a hora:minuto), excepciones periódicas (festivos que se repiten cada año) y excepciones puntuales (cierre especial el 15 de marzo, apertura ampliada el 24 de diciembre). Los horarios regulares forman la base y las excepciones los sobrescriben. La lógica es sencilla: ¿hay una excepción para la fecha actual? Si la hay, se aplican los horarios de la excepción. Si no, se aplican los horarios regulares del día de la semana correspondiente.

El plugin de frontend renderiza el estado mediante plantillas Fluid. El estado actual (abierto/cerrado) se calcula en el servidor y se emite como clase CSS, de modo que la paleta puede controlarse con Tailwind o CSS personalizado. Opcionalmente, el widget muestra la próxima apertura: "Actualmente cerrado. Próxima apertura: lunes, 08:00 h."

Para la integración con Schema.org, la extensión puede emitir OpeningHoursSpecification como JSON-LD, lo que Google muestra en las fichas del Knowledge Panel de la organización. Esto resulta especialmente relevante para instituciones que aparecen en Google Maps y quieren mostrar allí horarios correctos.

## Los problemas habituales afectan a zonas horarias, festivos ausentes y caché

El problema más frecuente es el caché. Si TYPO3 cachea la página y el caché no expira hasta dos horas después, el widget puede mostrar el estado incorrecto durante esas dos horas. La solución: integrar el widget de horarios como plugin uncached mediante USER_INT. Tiene un coste mínimo de rendimiento (una consulta a la base de datos por request), pero garantiza un estado correcto.

Segundo problema: festivos ausentes. La extensión no trae una lista preconfigurada de festivos. Cada institución debe introducir sus festivos manualmente o poblarlos mediante una importación. Para festivos autonómicos (la fiesta del 2 de mayo en Madrid, por ejemplo, no se celebra en Andalucía), se necesita mantenimiento manual o un script que importe festivos desde una API.

Tercer tema: zonas horarias en instituciones internacionales. La extensión trabaja con la zona horaria del servidor. Si el servidor TYPO3 funciona en UTC pero la institución está en CET, los horarios mostrados no coincidirán. La solución: fijar la zona horaria PHP en la configuración de TYPO3 a la zona horaria de la institución, o, para instituciones en varias zonas horarias, ajustar el cálculo mediante UTC+offset en la plantilla Fluid.

## La extensión funciona en TYPO3 v11 y v12, el soporte de v13 depende del equipo SLUB

slub_web_openhours la mantiene la SLUB de Dresde como proyecto de código abierto. Las actualizaciones siguen el ciclo de lanzamientos interno de la biblioteca. TYPO3 v12 está soportado. Para v13, la compatibilidad depende de si el equipo de desarrollo de la SLUB actualiza la extensión. Como la extensión es técnicamente ligera (sin dependencias complejas de API), la migración a v13 se puede abordar con poco esfuerzo. Gosign recomienda en proyectos de horarios de apertura validar la extensión en paralelo con la emisión Schema.org en la página de Google, para que los horarios aparezcan correctamente en Google Maps y en el Knowledge Panel.

--- solrfal TYPO3 - Indexación de archivos Solr | Gosign ---
> solrfal para TYPO3: indexar archivos en Apache Solr. Configuración, ajuste y migración, acelerado con IA. 25 años de experiencia.

## Por qué la búsqueda estándar de TYPO3 capitula ante grandes volúmenes de documentos

En cuanto una instalación TYPO3 gestiona más de unos cientos de PDF, el buscador incorporado choca con dos límites: solo encuentra contenidos almacenados en campos de base de datos, no dentro de los archivos, y su lógica de ranking ignora las señales de relevancia que los redactores necesitan. solrfal cubre exactamente ese hueco acoplando el File Abstraction Layer (FAL) de TYPO3 directamente a Apache Solr y haciendo que cada archivo, incluidos sus metadatos, sea buscable. La extensión va dirigida a organizaciones que consideran los documentos el núcleo de su trabajo con el conocimiento: administraciones con formularios, editoriales con literatura especializada, universidades con material docente.

## Escenarios típicos de uso

En una universidad politécnica con cerca de 40.000 estudiantes, el reglamento académico está distribuido en 180 archivos PDF repartidos entre doce facultades. Sin solrfal, un estudiante solo encuentra el apartado sobre la matrícula de exámenes si un redactor ha copiado ese texto adicionalmente como meta descripción. Con solrfal, Apache Tika indexa cada página y la consulta devuelve el párrafo exacto con su cita.

Un segundo escenario lo conocen bien las administraciones públicas que entregan leyes, directivas y formularios a través de un CMS TYPO3. Los documentos cambian con frecuencia y los permisos de acceso están ligados a unidades organizativas. solrfal sincroniza automáticamente la pertenencia a fe_groups de los archivos dentro del índice Solr, de modo que un empleado de una subdirección solo ve los resultados para los que tiene permiso de lectura.

El tercer caso aparece en editoriales especializadas: una editorial con 12.000 artículos de revistas en PDF quiere hacer consultable su archivo mediante una búsqueda facetada por año, autor y sección. solrfal extrae los metadatos, rellena los campos Solr y proporciona la base de datos para una facetación que extensiones clásicas de TYPO3 como ke_search ya no pueden sostener a esa escala.

## Arquitectura técnica sobre Apache Tika y EXT:solr

solrfal es una extensión de la extensión principal EXT:solr de dkd Internet Service y requiere obligatoriamente un servidor Apache Solr en funcionamiento, típicamente en la versión 8 o 9. La extracción de texto la realiza Apache Tika, ya sea como servicio embebido en el contenedor Solr o como servidor Tika independiente. solrfal se engancha al ciclo de vida del FAL a través de la API de eventos de TYPO3: cada archivo subido, movido o eliminado dispara un trabajo de indexación que se procesa de forma asíncrona en el scheduler de TYPO3.

La configuración de solrfal se realiza mediante TypoScript y la configuración de la extensión. El schema de Solr puede ajustarse mediante la Managed Schema API, de modo que se pueden añadir campos adicionales como tipo de documento, departamento o idioma sin reiniciar Solr. El ajuste de relevancia se realiza mediante boosting queries y function queries definidos en la configuración de consultas de EXT:solr. solrfal hereda todas las características multilingües de EXT:solr, incluidos los analizadores multilingües para castellano, catalán, inglés, alemán y otros idiomas estándar.

## Problemas frecuentes y soluciones

El primer problema suele aparecer en la indexación inicial: Apache Tika aborta con un OutOfMemoryError ante PDF dañados o cifrados y arrastra consigo a todo el indexador. La extensión marca entonces el archivo como erróneo pero no lo omite automáticamente en la siguiente ejecución. Analizamos los logs de Tika, separamos los cifrados de los realmente defectuosos y configuramos un pre-check que descarta los archivos problemáticos antes de que lleguen al indexador.

El segundo tema recurrente es la relevancia. Los equipos informan de que la búsqueda encuentra todos los documentos, pero los resultados irrelevantes aparecen arriba del todo. La causa está casi siempre en la ponderación de campos por defecto: solrfal indexa todo el contenido del archivo en un único campo, sin distinguir entre título, encabezados y cuerpo de texto. Una solución limpia requiere un schema adaptado con campos separados para título, metadatos y cuerpo, así como reglas de boosting que den más peso a las coincidencias en el título.

El tercer problema afecta al rendimiento con grandes volúmenes. A partir de unos 50.000 archivos indexados, el scheduler se convierte en cuello de botella porque solrfal procesa cada trabajo individualmente. La solución es la indexación en lotes combinada con un proceso worker dedicado que corre en paralelo a las tareas normales del scheduler y prioriza los trabajos de solrfal. Además, conviene una indexación diferencial que, en cada pasada, solo reprocesa los archivos nuevos o modificados, lo que reduce considerablemente el esfuerzo de mantenimiento en fondos documentales estables.

Un cuarto asunto, menos frecuente, se da en instalaciones multilingües: solrfal indexa los archivos sin tener en cuenta el idioma en un índice común, de modo que un estudio en francés aparece en la lista de resultados en castellano cuando la palabra buscada tiene difusión internacional. Una separación limpia por idioma requiere varios cores Solr o una faceta adicional de idioma, controlable por site-root a través de la configuración de EXT:solr.

## Migración y compatibilidad de versiones

solrfal sigue el ciclo de releases de EXT:solr, que actualmente soporta TYPO3 v12 y v13. El salto de TYPO3 v9 a v12 es la ruta de migración más habitual y casi siempre implica también el salto de Solr 6 a Solr 9. En el proceso cambian el formato del schema, la Managed Schema API y algunas clases analizadoras, lo que obliga a una reindexación completa. Las reglas de boosting existentes deben validarse contra el nuevo comportamiento del query parser, ya que Solr 9 evalúa ciertos operadores por defecto de forma distinta a Solr 6.

Quien migra desde ke_search o desde una búsqueda meramente basada en base de datos debe tener en cuenta que solrfal requiere un servidor Solr propio y, por tanto, amplía los requisitos de hosting. Gosign acompaña estas migraciones desde hace años y se encarga, si es necesario, también del cambio a una configuración Solr basada en contenedores que encaja en los pipelines de despliegue existentes.

Conviene además recordar que la carga de mantenimiento de solrfal no es despreciable: Solr recibe actualizaciones de seguridad periódicas y el schema debe revisarse frente a nuevas clases analizadoras en cada actualización mayor. Un proyecto que opta por solrfal asume la responsabilidad de un stack de búsqueda propio y debería calcularlo ya en el dimensionamiento inicial y en la planificación de los recursos operativos.

--- sr_freecap TYPO3 - CAPTCHA autoalojado | Gosign ---
> Extensión CAPTCHA de TYPO3 sin servicios externos. Protección anti-spam autoalojada, conforme con el RGPD, sin envío de datos a Google.

## Por qué administraciones y hospitales españoles dependen de una protección CAPTCHA autoalojada

reCAPTCHA de Google es técnicamente efectivo, pero jurídicamente problemático para muchos operadores en España: cada integración conlleva una transmisión de datos personales a Google en EE. UU., requiere un consentimiento activo conforme al RGPD y a la LSSI, y la AEPD ya ha advertido reiteradamente sobre el uso de servicios estadounidenses sin garantías tras la sentencia Schrems II. sr_freecap es la respuesta a ese problema: una extensión CAPTCHA completamente autoalojada para TYPO3 que no dispara peticiones externas, no transmite datos de usuario a terceros y, por tanto, funciona sin bloqueo de banner de consentimiento. El público objetivo son administraciones, hospitales, universidades y empresas conscientes de la protección de datos que deben proteger sus formularios frente a spam de bots sin asumir una nueva dependencia de un servicio estadounidense.

## Escenarios típicos de uso

Un hospital universitario opera un formulario de contacto para consultas de pacientes, un formulario de candidatura para personal de enfermería y un formulario de consultas de prensa. Los tres son atacados regularmente por bots que envían mensajes publicitarios genéricos o intentos de phishing. La IT del hospital ha decidido no integrar servicios de Google porque el delegado de protección de datos quiere evitar la obligación de consentimiento. sr_freecap genera imágenes con combinaciones de letras en el servidor, valida la entrada en el propio servidor y no envía en ningún momento información hacia el exterior.

Un segundo caso es un ayuntamiento con unos 15 formularios en línea para trámites ciudadanos, desde el empadronamiento hasta la solicitud de una tarjeta de estacionamiento para residentes. La agencia autonómica de protección de datos ha recomendado expresamente, en una auditoría, no utilizar CAPTCHAs externos. sr_freecap se integra en la API de formularios de TYPO3 (Powermail o el Form Framework) y protege así todos los formularios sin consentimiento adicional.

El tercer contexto son colegios profesionales y asociaciones que gestionan listas de miembros, direcciones o registros públicos. Cada una de esas organizaciones opera un formulario de búsqueda o un formulario de contacto que debe estar protegido frente a bots sin dejar de preservar la postura general de protección de datos. sr_freecap ofrece una prueba visual sencilla, resoluble para personas y que supone una barrera perceptible para bots OCR simples.

## Arquitectura técnica: librería GD, sesión y API de formularios

sr_freecap genera las imágenes CAPTCHA en el servidor con la librería GD o ImageMagick; GD es la opción estándar y está disponible prácticamente en cualquier instalación PHP sin esfuerzo adicional. Las letras se extraen aleatoriamente de un alfabeto configurable, se dibujan en una imagen con ruido de fondo y distorsión y se entregan al navegador. El texto esperado se almacena en la sesión de TYPO3 y se compara con la entrada del usuario al enviar el formulario.

La integración en formularios se realiza mediante un validator para el Form Framework de TYPO3 y mediante la API de Powermail, integrando el campo como elemento adicional en la definición del formulario. Los CAPTCHAs de audio como alternativa accesible están disponibles en la extensión, pero desactivados por defecto, y deberían activarse en formularios con un público amplio para no excluir a personas con discapacidad visual. sr_freecap se configura mediante TypoScript, que controla la longitud de la cadena del CAPTCHA, las fuentes utilizadas y el nivel de ruido.

## Problemas frecuentes y soluciones

El primer problema es legibilidad frente a seguridad. Si el CAPTCHA se distorsiona demasiado, también los usuarios humanos fracasan y abandonan el formulario, lo que reduce perceptiblemente la tasa de conversión. Si se distorsiona poco, los motores OCR modernos leen el texto en segundos. La solución practicable está en una distorsión moderada combinada con un campo honeypot, que está en el formulario como campo de entrada invisible. Los humanos no lo rellenan, los bots con frecuencia sí, y esos envíos se descartan en silencio.

El segundo problema afecta a la accesibilidad. Un CAPTCHA meramente visual excluye a usuarios ciegos y con baja visión, lo que en instituciones públicas puede suponer un incumplimiento de la Ley General de derechos de las personas con discapacidad y del Real Decreto 1112/2018 sobre accesibilidad web. La activación del modo audio y, adicionalmente, una sencilla operación aritmética como alternativa crean vías accesibles para cumplir el requisito sin renunciar a la protección.

El tercer tema es el manejo de sesión. sr_freecap almacena la solución esperada en la sesión PHP, lo que en balanceadores de carga sin afinidad de sesión o en instalaciones TYPO3 alojadas sin estado provoca errores. La solución es o bien sticky sessions en el balanceador, o bien un backend de sesión compartido como Redis que todos los nodos usen en común.

Un cuarto problema es la eficacia frente a frameworks de bots modernos. Navegadores headless sencillos como Puppeteer no pueden resolver CAPTCHAs visuales por sí mismos, pero pueden delegar la tarea a un servicio de resolución externo que entrega la respuesta correcta en segundos. Contra ese tipo de ataques no basta un CAPTCHA puramente de reconocimiento de imagen, y una combinación con comprobaciones basadas en comportamiento, como el análisis de movimientos del ratón o el honeypot ya mencionado, es la defensa más efectiva.

## Migración y compatibilidad de versiones

sr_freecap es una de las extensiones CAPTCHA más antiguas para TYPO3 y tiene una historia de versiones movida: para TYPO3 v11 y v12 existen forks comunitarios mantenidos; la compatibilidad con v13 varía de fork en fork. Quien migra actualmente a v12 o v13 debería comprobar antes del upgrade si su rama de la extensión sigue activa y, en caso de duda, cambiar a otro enfoque CAPTCHA.

Alternativas a sr_freecap dentro del espectro favorable a la privacidad son hCaptcha (variante autoalojada posible), Friendly Captcha de desarrollo europeo y campos honeypot combinados con rate limiting del lado del servidor. Gosign asesora en la elección en función del volumen de formularios, el grupo de usuarios y los requisitos regulatorios y, si hace falta, construye una solución híbrida que filtra primero el tráfico de bots con honeypot y solo envía los envíos sospechosos al paso CAPTCHA.

Para instituciones que por motivos regulatorios no pueden integrar servicios externos, una solución autoalojada como sr_freecap sigue siendo a menudo la única opción practicable, y el esfuerzo de mantenimiento es asumible. Lo importante es contrastar la protección CAPTCHA regularmente con los patrones de spam actuales y analizar las estadísticas de intentos fallidos para detectar cuándo es oportuno subir la distorsión o combinarla con otras medidas de protección.

--- Storytelling TYPO3 - Scrollytelling | Gosign ---
> Extensión de scrollytelling para TYPO3. Narrativas interactivas que se revelan al hacer scroll. Gosign construye experiencias de scrollytelling personalizadas.

## Memorias anuales y lanzamientos de producto necesitan algo más que texto e imagen

Las páginas estáticas con bloques de texto largos funcionan para documentación y artículos de blog. Pero las memorias anuales, los lanzamientos de producto y las historias corporativas necesitan un formato que guíe al visitante a través de una narrativa. El scrollytelling, es decir, contar una historia mediante la interacción de scroll, se ha establecido como el formato que se sitúa entre el texto estático y el vídeo producido. La extensión Storytelling para TYPO3 incorpora parallax scrolling, bloques de contenido animados y animaciones disparadas por scroll directamente al CMS, sin necesidad de que un servicio externo o una agencia programe una pieza única por cada página.

La ventaja frente al desarrollo a medida: los redactores pueden mantener los contenidos en el backend de TYPO3, reordenar bloques y configurar animaciones sin involucrar al desarrollador.

## Los escenarios típicos son memorias anuales, lanzamientos de producto y landings de campaña

El escenario más prominente son las memorias anuales digitales. Empresas, fundaciones y ONGs publican cada vez más sus cifras de cierre como historia web interactiva en lugar de como PDF. Una memoria anual en formato scrollytelling muestra en la primera sección la cifra principal (facturación, volumen de donaciones, número de socios), que se anima al hacer scroll. En la segunda sección aparecen gráficos con cifras comparativas respecto al año anterior. En la tercera, retratos y citas cuentan la historia detrás de los números. Toda la historia es una única página por la que el visitante hace scroll.

Un segundo escenario son las presentaciones de producto en el ámbito B2B. Un fabricante de maquinaria presenta una nueva línea de producción. Al hacer scroll, el renderizado 3D de la máquina rota, los datos técnicos aparecen y las animaciones muestran el proceso de producción. No es un vídeo (sin carga, sin buffering), sino una animación controlada por scroll que el visitante recorre a su propio ritmo.

Tercer escenario: landings de campaña. Una organización benéfica muestra el recorrido de una donación: desde el clic en el botón de donar, pasando por la selección del proyecto, hasta el informe del país de destino. Cada sección de scroll contiene una foto, un texto breve y una animación que visualiza el avance.

## La arquitectura técnica renderiza secciones como bloques de contenido controlados por scroll

La extensión define un tipo propio de elemento de contenido, "Storytelling", que se compone de secciones. Cada sección es un registro de backend con campos para titular, texto, imagen/vídeo (FAL), color de fondo, tipo de animación y disparador de scroll. Las secciones se ordenan en el backend y forman en conjunto la historia de scroll.

En el frontend, cada sección renderiza un bloque propio que ocupa todo el viewport. Las animaciones se disparan mediante transiciones CSS e IntersectionObserver: cuando una sección entra en el área visible, arranca la animación configurada (Fade-In, Slide-Left, Zoom, contador). Los efectos parallax desplazan las imágenes de fondo más despacio que el primer plano, creando sensación de profundidad.

La extensión trae un conjunto de animaciones predefinidas. Las animaciones personalizadas pueden añadirse mediante clases CSS seleccionables en el backend como tipo de animación. La base JavaScript es mínima: sin framework, solo IntersectionObserver nativo y requestAnimationFrame. Esto mantiene el tamaño del bundle por debajo de 20 KB.

Para el rendimiento es decisivo que las imágenes se carguen de forma perezosa. Una memoria de scrollytelling con 15 secciones y una imagen de alta resolución por sección genera sin lazy loading entre 30 y 50 MB en peticiones. Con lazy loading, el navegador solo carga la sección visible y la siguiente.

## Los problemas habituales afectan al rendimiento en móvil y a la accesibilidad

El mayor problema del scrollytelling en dispositivos móviles es el rendimiento. Los efectos parallax, fluidos en escritorio, sufren tirones en smartphones antiguos. El motivo: los navegadores móviles procesan los eventos de scroll de forma distinta a los de escritorio y estrangulan requestAnimationFrame en segundo plano. La solución: desactivar parallax en viewports móviles y sustituirlo por animaciones Fade-In sencillas. La extensión debería permitir configurar mediante TypoScript qué animaciones están activas en cada breakpoint.

Segundo problema: accesibilidad (WCAG 2.1). Las animaciones controladas por scroll resultan problemáticas para usuarios con trastornos vestibulares (mareo, náuseas ante el movimiento). Se debe respetar el CSS prefers-reduced-motion. Con la preferencia de reducir el movimiento activada, la extensión debería desactivar todas las animaciones y mostrar los contenidos como bloques estáticos. No todas las extensiones de storytelling lo implementan correctamente.

Tercer tema: SEO. Google puede rastrear animaciones basadas en JavaScript, pero el contenido debe ser accesible también sin JavaScript. Las secciones deben renderizarse como bloques HTML regulares, no como contenedores vacíos que solo se rellenan vía JavaScript. La extensión debería seguir un enfoque de mejora progresiva: primero el contenido, después la animación.

## TYPO3 v12 está soportado, v13 exige actualizar el registro de elementos de contenido

Existen extensiones de scrollytelling para TYPO3 en distintas variantes de distintos proveedores. La compatibilidad con v12 está garantizada en las extensiones mantenidas activamente. Para v13 hace falta actualizar el registro de elementos de contenido (NewContentElementWizard) y la configuración TCA, porque v13 ha ajustado la configuración de elementos de contenido basada en FlexForm. En los nuevos proyectos de scrollytelling, Gosign apuesta por una arquitectura que separa la lógica de animación como módulo JavaScript independiente de la integración TYPO3, para que en futuros upgrades solo haya que adaptar la capa TYPO3.

--- Horario escolar TYPO3 - Escuelas | Gosign ---
> Extensión de horario escolar para TYPO3. Vista semanal, gestión de materias, sustitución de profesores. Para escuelas y centros educativos.

## Los centros educativos publican sus horarios como PDF, aunque una solución digital ahorraría tiempo a todos

La mayoría de centros educativos elaboran sus horarios con software especializado, los exportan como PDF y los suben al sitio web. Familias, alumnado y profesorado hacen scroll por una tabla ilegible que no se escala en el smartphone. Cualquier cambio (sustitución, cambio de aula, suspensión) exige volver a subir un PDF nuevo. La extensión Stundenplan para TYPO3 sustituye ese flujo por una visualización digital directamente en el sitio: vista por día y por semana, filtros por asignatura, profesor y clase, representación responsive en todos los dispositivos, vista imprimible para la sala de profesores.

Para titulares que operan sus sitios web escolares de forma centralizada sobre TYPO3, es una solución escalable para diez, veinte o cincuenta centros simultáneamente.

## Los escenarios típicos van desde el colegio individual hasta la red escolar

El escenario base es el colegio con 20 clases, 40 docentes y un horario que cambia semanalmente. La administración mantiene el horario en el backend de TYPO3 o lo importa desde un software externo. En el sitio web, las familias ven la vista semanal de la clase de su hijo. El filtro reduce la vista a una clase, una asignatura o un docente. Las sustituciones se muestran como cambios resaltados con color, de modo que las familias ven por la mañana de un vistazo si las clases transcurren con normalidad.

Un segundo escenario son los consorcios escolares y las titularidades con instalación TYPO3 centralizada. Un ayuntamiento opera 15 sitios web escolares sobre una instancia TYPO3 multisite. Cada centro tiene sus propios horarios, pero la presentación es homogénea. La extensión se configura una sola vez y se despliega por herencia TypoScript a todos los sitios. Los nuevos centros se ponen en marcha con la misma configuración.

Tercer escenario: escuelas municipales de idiomas y centros de formación continua. Un centro ofrece 200 cursos por semestre. El horario muestra qué curso tiene lugar en qué día de la semana y en qué aula. Los participantes filtran por área (idiomas, informática, salud) y ven su vista semanal personal. En combinación con un login, los participantes registrados solo ven los cursos en los que están matriculados.

## La arquitectura técnica almacena los datos del horario como registros estructurados

La extensión define varias tablas: clases, docentes, asignaturas, aulas y horas lectivas. Cada hora lectiva es un registro con vínculos a clase, docente, asignatura, aula, día de la semana y franja horaria. Los datos se mantienen manualmente en el backend o se importan mediante CSV/XML desde software especializado.

El plugin de frontend renderiza los datos como tabla HTML con la matriz día-franja. Los filtros (clase, docente, asignatura) se pasan como parámetros GET y se procesan en el servidor. La tabla es responsive mediante CSS: en escritorio muestra la vista semanal completa; en móvil se conmuta a vista diaria o se habilita scroll horizontal.

La vista de impresión genera una presentación optimizada sin navegación ni pie de página, con saltos de página entre días. Mediante Print-CSS la tabla se optimiza para A4 apaisado.

Para la importación desde software de planificación existen soluciones comunitarias que analizan el XML exportado y lo escriben en la estructura de base de datos TYPO3. La importación se puede configurar como tarea Scheduler, de modo que los cambios en el software de planificación aparezcan automáticamente en el sitio web.

## Los problemas habituales afectan al mantenimiento de datos y a la vista móvil

El mayor problema es el mantenimiento continuo de los datos. Los horarios cambian semanalmente, las sustituciones a diario. Mantener los datos manualmente en el backend de TYPO3 supone un esfuerzo considerable con 20 clases y 30 horas semanales por clase. La solución: configurar una importación automatizada desde el software de planificación. Sin esa importación, la extensión solo es práctica para centros pequeños con pocas clases.

Segundo problema: la vista móvil. Una tabla de horarios con cinco columnas (lunes a viernes) y diez filas (horas lectivas) no cabe en una pantalla de 375 píxeles de ancho. El scroll horizontal es la solución pragmática, pero a las familias les resulta poco intuitivo. Mejor: en viewports móviles, cambiar automáticamente a vista diaria (solo el día actual) con gestos de deslizamiento para cambiar de día.

Tercer tema: protección de datos. Mostrar el nombre del profesorado en el horario público puede ser problemático desde el punto de vista de la RGPD. Algunos centros muestran por ello solo asignatura y clase, no el nombre del docente. La extensión debería permitir configurar qué campos se muestran en el frontend.

## La extensión es una solución de nicho sin mantenimiento activo de la comunidad

Las extensiones de horario escolar para TYPO3 son productos de nicho con una comunidad pequeña. La compatibilidad con TYPO3 v12 está disponible en las versiones más recientes, pero un desarrollo activo para v13 no está garantizado. Los centros y titularidades que planifican a largo plazo deberían evaluar si un desarrollo a medida sobre elementos estándar de TYPO3 (registros Extbase + plantillas Fluid) no resulta más sostenible que una extensión comunitaria con horizonte de mantenimiento incierto. Gosign asesora a centros educativos y titulares en la elección entre extensión comunitaria, desarrollo a medida y soluciones SaaS especializadas con conexión a TYPO3.

--- Styleguide TYPO3 - Extensión de QA | Gosign ---
> Extensión Core de TYPO3 que visualiza todos los elementos de contenido en una página.

## Por qué Styleguide es la extensión de QA más importante para desarrolladores de plantillas TYPO3

El desarrollo de plantillas en TYPO3 tiene un problema sistemático de calidad: los desarrolladores prueban sus plantillas Fluid con los datos que existen actualmente en la web. Pero los elementos de contenido tienen docenas de variantes - titulares con y sin subtítulo, bloques de texto con 3 palabras o 3 párrafos, imágenes en formato vertical y horizontal, tablas con 2 o 20 columnas. Quien solo revisa la página actual se pierde los casos extremos que aparecen después del lanzamiento.

La extensión Styleguide resuelve este problema representando automáticamente todos los elementos de contenido del sistema TYPO3 en cada configuración disponible en una sola página.

## Escenarios de uso habituales

**Desarrollo de plantillas en proyectos de relanzamiento.** Una empresa encarga un relanzamiento TYPO3 con nuevo diseño corporativo. Sin Styleguide, el desarrollador frontend debe crear datos de prueba manualmente para cada elemento - con más de 30 elementos de contenido, eso lleva horas. Styleguide genera todos los datos de prueba automáticamente.

**Tests de regresión tras actualizaciones TYPO3.** Una actualización de v11 a v12 modifica sutilmente el renderizado de elementos individuales. Sin Styleguide, eso solo se detecta cuando un editor reporta el error en una página en producción. Con Styleguide, el desarrollador ve inmediatamente qué elementos han cambiado.

**Coordinación entre equipo de diseño y desarrollo.** Los diseñadores entregan mockups Figma para 10 elementos. Pero cómo se ven los 25 elementos estándar restantes en el nuevo diseño. Styleguide hace visible esta brecha: todos los elementos se muestran en una página, los diseños faltantes saltan a la vista inmediatamente.

## Arquitectura técnica

Styleguide es una extensión Core oficial del sistema TYPO3, distribuida con el código fuente de TYPO3. Solo necesita activarse en el Extension Manager. La extensión analiza las definiciones TCA de todos los elementos de contenido registrados y genera registros de prueba con valores sensatos. Un módulo de backend permite generar, actualizar y eliminar los datos de prueba. Una página especial en el árbol muestra todos los elementos generados en el layout frontend.

Styleguide no tiene dependencias externas. Al ser una extensión Core, se actualiza automáticamente con cada actualización de TYPO3.

## Problemas frecuentes y soluciones

**La página Styleguide muestra áreas vacías.** Los datos de prueba se generaron pero la página frontend no muestra todos los elementos. Causa: el SysFolder con los datos de prueba no está correctamente configurado como punto de inicio. Solución: verificar en el módulo de backend que el árbol de páginas se creó correctamente.

**Faltan imágenes en los datos generados.** Styleguide intenta incluir imágenes de prueba vía FAL. Si la carpeta fileadmin está vacía o la configuración del Default Storage no es correcta, los campos de imagen quedan vacíos. Solución: subir manualmente al menos una imagen al fileadmin antes de generar los datos de prueba.

**Problemas de rendimiento en la página Styleguide.** Con todos los elementos de contenido en una página, el tiempo de carga con plantillas complejas puede alcanzar 10 a 15 segundos. Solución: activar Styleguide solo en entornos de desarrollo o staging, nunca en el sistema en producción.

## Migración y compatibilidad de versiones

Styleguide está disponible como extensión Core desde TYPO3 v8 y se actualiza automáticamente con cada versión de TYPO3. No hay problemas de compatibilidad separados. Tras una actualización TYPO3, los datos de prueba deben regenerarse ya que las definiciones TCA pueden cambiar entre versiones.

Gosign integra Styleguide en cada relanzamiento TYPO3 como parte fija del proceso de QA. La página Styleguide se configura en staging como referencia permanente y sirve al equipo de diseño como URL de validación. Para clientes enterprise con varias marcas o mandantes se genera una página Styleguide por mandante para comparar variantes de plantilla específicas por marca.

--- t3skin TYPO3 - Estilo del backend | Gosign ---
> Legacy Backend Skin para versiones antiguas de TYPO3. Desde TYPO3 v7+ ya no es relevante. Si aún lo utiliza: Gosign le ayuda a migrar.

## t3skin está obsoleto desde TYPO3 v7, pero muchas instalaciones siguen funcionando en versiones que lo necesitan

t3skin era el paquete de estilos del backend para TYPO3 v4 y v6. Definía iconos, colores, espaciados y toda la apariencia y experiencia del backend de TYPO3. Desde TYPO3 v7, el estilo del backend se integró en el core y t3skin como extensión independiente quedó obsoleto. Aun así, t3skin aparece con regularidad en los análisis de sistemas existentes, porque sigue instalado en instalaciones antiguas y provoca errores al actualizar a versiones recientes de TYPO3. Quien encuentra t3skin en su listado de extensiones tiene una señal clara: esa instalación o bien está desactualizada o no se limpió por completo durante un upgrade anterior.

## Los escenarios típicos afectan exclusivamente a instalaciones legacy

El único escenario legítimo para t3skin es una instalación TYPO3 en las versiones 4.5 a 6.2 que por motivos técnicos u organizativos no se puede actualizar. En esas instalaciones, t3skin aporta el diseño del backend. Sin t3skin, el backend resultaría visualmente inutilizable: iconos ausentes, layouts rotos, formularios ilegibles.

Un segundo escenario es la fase de transición durante una migración. Cuando una agencia migra una instalación TYPO3 v6 a v12, t3skin permanece en la lista de extensiones durante el proceso de upgrade, pero se desactiva y elimina tras el mismo. En esa fase, t3skin puede provocar conflictos con el nuevo estilo del backend si no se desinstala a tiempo.

Un tercer (anti)escenario: algunos administradores instalaron manualmente t3skin en TYPO3 v7 u v8 porque preferían el diseño antiguo del backend. Funcionaba a corto plazo, pero generaba errores de presentación porque el CSS de t3skin y el del core entraban en contradicción. A partir de TYPO3 v9 eso ya no es una opción.

## La arquitectura técnica era un paquete de CSS e iconos sin lógica de negocio

t3skin no era una extensión en el sentido clásico (sin controlador, sin modelo, sin repositorio). Consistía en archivos CSS, sprites de iconos, algunos snippets JavaScript para la interfaz del backend y una ext_emconf.php que la registraba como extensión del sistema. Toda la lógica era visual: colores, tipografías, espaciados, iconos. El core de TYPO3 renderizaba los módulos del backend y t3skin solo determinaba su apariencia.

Desde TYPO3 v7 el core asumió esa tarea por sí mismo. El estilo del backend se integró en el paquete de extensión del sistema "backend". Los iconos se migraron a un sistema basado en SVG (IconFactory), el CSS se migró a Less y después a SCSS. t3skin no podía reflejar esos cambios porque se apoyaba en el antiguo sistema de iconos basado en sprites.

## Los problemas habituales aparecen cuando t3skin no se elimina en un upgrade

El problema más frecuente es un backend en blanco o roto tras un upgrade de TYPO3. Si t3skin sigue instalada en una instalación v12, sobrescribe archivos CSS del core con reglas obsoletas. El resultado: botones sin fondo, iconos que no cargan, navegaciones de módulos que no se pueden pulsar. La solución: desinstalar t3skin mediante el Extension Manager y limpiar las entradas en la tabla sys_registry. Si el backend está tan roto que el Extension Manager no es accesible, ayuda la desactivación por línea de comandos: typo3/sysext/core/bin/typo3 extension:deactivate t3skin.

Segundo problema: archivos CSS huérfanos. Incluso tras desinstalar t3skin pueden quedar archivos CSS en fileadmin/ o typo3temp/ que el navegador cachea. Un vaciado completo de caché (caché del navegador, caché TYPO3, caché del CDN) es necesario tras la eliminación.

Tercer tema: personalizaciones del backend que dependen de t3skin. Algunas agencias escribieron en TYPO3 v6 CSS personalizado para el backend que utilizaba clases t3skin como base. Tras eliminar t3skin, esas personalizaciones se rompen. La solución: migrar el CSS personalizado del backend a las clases CSS actuales del core.

## t3skin no tiene ruta de upgrade, la migración significa eliminación

No existe actualización de t3skin a una versión actual, porque la extensión no tiene sucesor. Su sucesor es el propio core de TYPO3. La migración consiste en: desinstalar t3skin, eliminar todas las referencias a clases CSS de t3skin en módulos de backend personalizados y usar la IconFactory para iconos personalizados. Gosign realiza esa limpieza en el marco de cada migración TYPO3 y comprueba si otras extensiones legacy (css_styled_content, rtehtmlarea, adodb) siguen presentes en la instalación y también deben eliminarse.

--- Copyright Bilder TYPO3 | Gosign ---
> Agregar avisos de copyright automáticamente a las imágenes. Leer metadatos IPTC/EXIF, mostrar como superposición o pie de foto.

## La falta de créditos en las imágenes cuesta a las empresas miles de euros en requerimientos cada año

Las agencias de fotografía de stock como Getty Images, Adobe Stock y Mauritius despliegan de forma sistemática crawlers que rastrean internet en busca de imágenes sin licencia o mal atribuidas. La ausencia de créditos es la causa más frecuente de requerimientos legales. Según la agencia y la imagen, las reclamaciones oscilan entre 500 y 5.000 euros por imagen. En un sitio con 200 fotos de stock, una sola revisión de la agencia puede generar reclamaciones de cinco cifras. tgm_copyright automatiza el marcado de copyright en TYPO3: la extensión lee los metadatos IPTC y EXIF de los archivos de imagen y muestra automáticamente el aviso de copyright como superposición o pie de foto. Toda imagen gestionada por FAL (File Abstraction Layer) recibe su aviso de derechos sin que los redactores tengan que intervenir manualmente.

## Los escenarios típicos abarcan sitios web corporativos, editoriales e instituciones públicas

El escenario más frecuente es el sitio corporativo con 100 a 500 imágenes de distintas fuentes: fotos propias, stock de Adobe Stock, fotos de prensa de clientes, ilustraciones de freelancers. Cada imagen tiene requisitos de licencia distintos. Algunas exigen mencionar al autor ("Foto: Juan Pérez"), otras requieren una fuente ("Fuente: Adobe Stock"), y otras solo un símbolo de copyright. tgm_copyright lee la información de los campos IPTC (Creator, Copyright Notice, Source) y la muestra en el formato configurado.

Un segundo escenario son las editoriales y los medios de comunicación. Un periódico regional publica a diario entre 30 y 50 imágenes. Los fotógrafos entregan sus imágenes con los datos IPTC incrustados. La extensión muestra automáticamente "Foto: [nombre del fotógrafo]" bajo cada imagen. Esto ahorra a la redacción entre cinco y diez minutos por artículo, porque no hay que introducir el crédito manualmente.

Tercer escenario: instituciones públicas que utilizan imágenes Creative Commons. Las licencias CC exigen una atribución correcta (autor, tipo de licencia, enlace a la licencia). tgm_copyright puede leer esa información desde los metadatos y mostrarla como pie de foto con enlace a la licencia.

## La arquitectura técnica aprovecha los metadatos FAL y un sistema de ViewHelper Fluid

tgm_copyright se registra como extensión de TYPO3 y accede a la tabla sys_file_metadata. Cuando se sube una imagen a TYPO3 mediante FAL, la extensión extrae automáticamente los campos IPTC y EXIF y los escribe en los campos de metadatos de la tabla FAL. Los campos IPTC relevantes son: Creator (fotógrafo), Copyright Notice (titular de derechos), Source (fuente), Description (pie de foto) y Credit (agencia).

En el frontend la extensión proporciona un ViewHelper Fluid que renderiza el aviso de copyright junto a cada imagen. El ViewHelper puede configurarse como superposición (banda semitransparente en el borde inferior de la imagen), como pie de foto (texto bajo la imagen) o como tooltip (efecto hover). El estilo se controla mediante clases CSS, de modo que el aviso se adapta al diseño del sitio.

Para imágenes sin metadatos incrustados, la extensión ofrece un fallback: los redactores pueden introducir el aviso de copyright manualmente en el diálogo de metadatos FAL. La extensión prioriza las entradas manuales sobre los metadatos leídos automáticamente, de modo que los datos IPTC erróneos pueden sobrescribirse.

## Los problemas habituales afectan a los metadatos ausentes y a la posición del overlay

El problema dominante son las imágenes sin datos IPTC incrustados. Muchas descargas de fotos de stock se editan en Photoshop antes de subirlas y los metadatos se pierden en el proceso. Si no existe el campo IPTC Creator, la extensión no puede generar un aviso de copyright. La solución: establecer un flujo de trabajo que revise los metadatos antes de subir las imágenes. Alternativa: un módulo de backend de TYPO3 que liste todas las imágenes sin entrada de copyright y solicite su mantenimiento manual.

Segundo problema: el overlay tapa contenidos importantes de la imagen. En retratos, un overlay de copyright en el borde inferior puede tapar el rostro o el nombre del producto. La solución: permitir configurar por imagen si el copyright se muestra como overlay o como pie de foto. Por defecto, el pie de foto es la opción segura.

Tercer tema: rendimiento con grandes fondos de imágenes. Si la extensión lee los datos IPTC del archivo en cada petición de imagen en lugar de leerlos de la base de datos, el impacto se nota en páginas con 20 imágenes. La solución: leer los datos IPTC una sola vez en el momento de la subida y cachearlos en la base de datos, no en cada petición de frontend.

## TYPO3 v12 está soportado, v13 exige actualizar el registro del ViewHelper

tgm_copyright utiliza la API FAL, estable en el core de TYPO3. La extensión funciona sin problemas bajo v12. Para v13 son necesarias adaptaciones en el registro de namespaces del ViewHelper y en las configuraciones TCA, porque v13 ha cambiado las convenciones de namespaces para los ViewHelper. Gosign recomienda, en cada upgrade de TYPO3, realizar una auditoría de imágenes: revisar todas las imágenes del sitio para comprobar que los créditos se muestran correctamente y completar las asignaciones que falten.

--- Ticketshop TYPO3 - Tickets en línea | Gosign ---
> Extensión de tienda de tickets para TYPO3. Venta de entradas en línea, gestión de plazas, códigos QR, control de acceso.

## Los organizadores pagan entre un 5 y un 15 por ciento de comisión a plataformas de ticketing externas cuando su propio sitio sería el mejor canal de venta

Plataformas como Ticketmaster, Entradas.com o Eventbrite cobran comisiones por ticket: entre un 5 y un 15 por ciento del precio más un importe fijo. Para un teatro con 50.000 entradas vendidas al año y un precio medio de 30 euros, eso supone entre 75.000 y 225.000 euros de comisión anual. Un ticketshop directamente en el sitio web TYPO3 elimina esa comisión. La extensión permite la venta de entradas en línea con selección de asiento, gestión de cupos, pago a través de pasarelas habituales, generación de e-tickets en PDF y validación por código QR en la entrada. Para teatros, auditorios, conferencias y centros culturales municipales que venden la mayor parte de sus entradas a un público habitual conocido, es una alternativa económicamente atractiva.

## Los escenarios típicos van desde el teatro municipal hasta la conferencia profesional

El escenario más prominente es el teatro o auditorio con plano de sala fijo. 400 asientos numerados, de los cuales 50 en categoría Premium, 200 en platea y 150 en anfiteatro. El visitante elige su asiento en el plano interactivo, ve el precio y añade la entrada al carrito. Tras el pago, recibe un e-ticket en PDF con código QR por correo electrónico. La noche de la función, el personal escanea el código QR con un smartphone. Todo el proceso se desarrolla en el sitio TYPO3, sin terceros.

Un segundo escenario son las conferencias y ferias. Una conferencia profesional ofrece tres categorías de entradas: Early Bird (hasta 8 semanas antes del evento), Regular y VIP. Los cupos limitan cada categoría a un número fijo. El ticketshop muestra la disponibilidad en tiempo real: "Early Bird: 12 de 100 disponibles". Al finalizar el periodo Early Bird, la categoría se desactiva automáticamente.

Tercer escenario: eventos municipales. Una biblioteca municipal organiza lecturas, talleres y actividades infantiles. Las entradas son gratuitas, pero el aforo es limitado. El ticketshop funciona aquí como sistema de reservas. Los visitantes reservan en línea, reciben una confirmación y, en caso de exceso de demanda, se incorporan a una lista de espera.

## La arquitectura técnica conecta registros de eventos, plano de sala y pasarela de pago

El ticketshop se compone de cuatro componentes: gestión de eventos, editor de plano de sala, checkout con integración de pago y generación de tickets. Los eventos se crean como registros Extbase en el backend de TYPO3: título, fecha, hora, lugar, categorías, precios, cupos. El plano de sala se registra como gráfico SVG interactivo en el que cada asiento tiene un identificador único vinculado al sistema de cupos.

El proceso de checkout recoge las entradas seleccionadas, solicita los datos de contacto y redirige a una pasarela de pago. Integraciones habituales son Stripe, PayPal, Mollie y Redsys. Tras un pago correcto, la extensión genera un PDF de entrada con código QR (basado en un identificador único de ticket) y lo envía por correo electrónico. El código QR contiene una URL o un hash que se valida en el control de acceso.

La validación del código QR en la entrada puede funcionar con una aplicación web sencilla que comprueba el identificador del ticket contra la base de datos TYPO3 y marca el estado como "canjeado". Un ticket solo se puede canjear una vez; los duplicados se rechazan.

## Los problemas habituales afectan al pago, las cancelaciones y el editor del plano de sala

El mayor problema es la gestión del pago. El cumplimiento de PCI-DSS exige que los datos de tarjeta nunca lleguen al servidor propio. Por eso el pago debe procesarse a través de un proveedor certificado que proporcione un Hosted Payment Form. La extensión redirige al usuario al proveedor para el pago y recibe el resultado mediante callback. Si el callback falla (timeout, reinicio del servidor), el ticket está pagado pero no marcado como pagado. La solución: un job de reconciliación que verifique las transacciones pendientes contra el proveedor de pago.

Segundo problema: cancelaciones y reembolsos. Si un visitante cancela una entrada, el pago debe reembolsarse y la plaza liberarse. Esto requiere tanto una petición de reembolso al proveedor de pago como un cambio de estado en la base de datos TYPO3. Sin flujo automatizado de cancelación, es un proceso manual.

Tercer tema: el editor del plano de sala. Los planos SVG interactivos con 400 asientos o más son laboriosos de crear. Cada asiento necesita un identificador, una categoría y coordenadas. Los cambios en el plano (nuevo bloque, reordenación) obligan a actualizar el archivo SVG y los vínculos con la base de datos.

## Los ticketshops son desarrollos a medida sin estándar en el TER

No existe una extensión de ticketshop estándar en el TYPO3 TER que cubra todas las funciones descritas. Los ticketshops son casi siempre desarrollos a medida adaptados a las necesidades específicas del recinto. La compatibilidad con TYPO3 depende por tanto del proveedor, no de un ciclo de lanzamientos comunitario. Gosign recomienda en los nuevos proyectos de ticketshop evaluar si una arquitectura headless de TYPO3 con un frontend especializado (React, Vue) no es a largo plazo más mantenible que una solución monolítica Extbase.

--- Tournament TYPO3 - Torneos | Gosign ---
> Extensión de torneos para TYPO3. Cuadros de torneo, gestión de grupos, resultados en vivo. Para asociaciones deportivas y organizadores.

## Los clubes deportivos gestionan sus torneos en Excel aunque su sitio web sería el lugar lógico para los resultados y la clasificación

Cada fin de semana se celebran en España miles de torneos amateur. Los resultados se teclean en hojas Excel, se suben como PDF al sitio web o, en el mejor de los casos, se escriben a mano en una tabla HTML. Los visitantes del sitio del club ven datos desactualizados porque nadie actualiza la página. La extensión Tournament para TYPO3 sustituye ese flujo: los grupos, los emparejamientos, los resultados y las clasificaciones se gestionan directamente desde el CMS. Se introducen los resultados y la clasificación se actualiza automáticamente. Para clubes deportivos, organizaciones de esports y empresas que organizan competiciones internas, es una presentación profesional sin esfuerzo de programación.

## Los escenarios típicos abarcan torneos de fútbol, ligas de esports y competiciones internas

El escenario más frecuente es el torneo de fútbol de un club deportivo. 16 equipos juegan en 4 grupos. Cada grupo disputa una fase previa (todos contra todos), los dos mejores se clasifican para la ronda eliminatoria. La extensión refleja este formato por completo: fase de grupos con puntos, diferencia de goles y enfrentamientos directos, eliminatorias con cuartos de final, semifinal y final. Los resultados se introducen en el backend y las tablas y el cuadro del torneo se actualizan automáticamente en el frontend.

Un segundo escenario son las ligas de esports. Un club gamer organiza una liga de Counter-Strike con 12 equipos y una temporada de 20 jornadas. La extensión gestiona la clasificación, el calendario y el historial de resultados. Cada equipo tiene una página de perfil con plantilla, estadísticas y resultados pasados. La presentación se adapta a la identidad del club, no al layout de una plataforma externa.

Tercer escenario: competiciones internas de empresa. Una compañía con cinco sedes organiza un torneo anual de ajedrez. Los empleados se inscriben a través de la intranet TYPO3, la extensión sortea los emparejamientos y muestra el avance del torneo en directo. Es una aplicación de nicho, pero para empresas que quieren fomentar la participación y el intercambio entre sedes es un caso de uso real.

## La arquitectura técnica modela los torneos como estructura anidada de registros

La extensión define varios modelos Extbase: Tournament (torneo), Team, Group, Match, Result. Un torneo contiene grupos, cada grupo contiene equipos. Los partidos se generan automáticamente (todos contra todos) o se definen manualmente (eliminatorias). Los resultados se almacenan como registros Result vinculados a cada Match.

El cálculo de la clasificación se realiza en el servidor: puntos (3-1-0 o configurable), diferencia de goles, goles marcados, enfrentamiento directo. La lógica de ordenación es configurable mediante TypoScript, porque distintos deportes priorizan criterios distintos (fútbol: diferencia de goles antes que goles marcados; balonmano: cociente de goles).

El frontend renderiza dos vistas principales: la fase de grupos como tabla (equipos, puntos, victorias, derrotas, diferencia de goles) y el cuadro eliminatorio como representación anidada de bracket. El bracket se implementa en CSS como estructura en árbol, horizontal en escritorio y vertical en móvil.

Para torneos más grandes con integración de streaming en directo, la extensión puede ampliarse con AJAX: los resultados se introducen en el backend y el frontend actualiza el marcador mediante polling cada 30 segundos, sin recargar la página.

## Los problemas habituales afectan a la lógica del formato de torneo y a la vista del bracket

El mayor problema es la variedad de formatos de torneo. Un eliminatorio sencillo con 8 equipos es trivial. Pero un torneo con sistema suizo de 40 equipos, un formato de doble eliminación o una liga con ascensos y descensos requieren lógica compleja que no toda extensión refleja. Antes de decidirse por una extensión, el formato debe estar claramente definido. Si la extensión no soporta el formato deseado, hace falta una extensión a medida.

Segundo problema: la visualización del bracket en dispositivos móviles. Un cuadro eliminatorio con 16 equipos tiene cuatro rondas (octavos hasta la final). Esa estructura en árbol no cabe en una pantalla de 375 píxeles de ancho. El scroll horizontal o una vista simplificada en lista son las soluciones pragmáticas.

Tercer tema: fotos y escudos de los equipos. Los clubes quieren logotipos junto al nombre del equipo en la clasificación. La extensión debe ofrecer integración FAL para imágenes de equipo; de lo contrario, los redactores tendrán que introducir rutas de imagen manualmente.

## Las extensiones de torneos son productos de nicho con comunidad limitada

Las extensiones de torneos para TYPO3 son soluciones de nicho con una comunidad pequeña. Bajo TYPO3 v12 funcionan de forma estable las versiones actuales. Para v13 el desarrollo no está garantizado, porque el esfuerzo de mantenimiento para el maintainer de una extensión de nicho resulta económicamente difícil de justificar. Los clubes que planifican a largo plazo deberían evaluar si una plataforma especializada de torneos (Challengermode, Toornament) con conexión API a su sitio TYPO3 no resulta más sostenible que una extensión monolítica. Gosign asesora a clubes y organizaciones en la elección entre extensión comunitaria, desarrollo a medida e integración SaaS.

--- tt_address TYPO3 - Gestión de direcciones | Gosign ---
> Extensión de gestión de direcciones para TYPO3. Contactos, direcciones, datos de contacto. Base para directorios de miembros, listados de contactos.

## Directorios de empleados, buscadores de sucursales y listados de contacto funcionan en TYPO3 desde hace 20 años con tt_address

Toda empresa con múltiples sedes, departamentos o personas de contacto necesita una presentación estructurada en su web. Quién es responsable de cada región. Dónde está la sucursal más cercana. Cuáles son los datos de contacto del departamento de personal. Mantener esta información manualmente como bloques de texto en el CMS produce inconsistencias: formatos distintos, actualizaciones olvidadas, sin posibilidad de filtrado.

tt_address es la extensión de gestión de direcciones más antigua y difundida de TYPO3. En uso desde TYPO3 v4 (2006), más de 50.000 instalaciones activas (TER, 2026), mantenida activamente por la comunidad TYPO3. La extensión almacena contactos, personas y sedes como registros estructurados y los presenta mediante plantillas Fluid como listas, mapas o páginas de detalle.

## Escenarios de uso habituales

**Directorios de empleados para webs corporativas.** Una empresa con 50 a 500 empleados quiere mostrar en la web quién es responsable de cada tema. tt_address almacena por persona: nombre, cargo, departamento, foto, email, teléfono, sede. La salida se muestra como lista filtrable (por departamento, sede) o como página de detalle con descarga de vCard.

**Buscadores de sucursales y resúmenes de sedes.** Empresas con 10 a 500 sedes (filiales, delegaciones, partners) usan tt_address como base de datos para un buscador de ubicaciones. Cada sede tiene dirección, geocoordenadas, horarios de apertura y datos de contacto. La integración de mapas se realiza mediante una extensión separada (maps2 o Leaflet) que lee las geocoordenadas de tt_address.

**Listados de contacto para administraciones y asociaciones.** Ayuntamientos, colegios profesionales y asociaciones listan personas de contacto por responsabilidad. tt_address refleja la estructura organizativa mediante categorías o SysFolder. La salida se puede filtrar por categoría y ordenar alfabéticamente o por cargo.

## Arquitectura técnica

tt_address almacena registros en la tabla `tt_address`. Los campos incluyen: tratamiento, título, nombre, apellidos, empresa, departamento, dirección, código postal, ciudad, país, teléfono, fax, móvil, email, web, geocoordenadas (latitud, longitud), imagen (referencia FAL), categorías y un campo de descripción (RichText).

La salida se realiza mediante un plugin Extbase con acciones List y Detail. Las plantillas Fluid son completamente personalizables. Por defecto, tt_address ofrece cuatro layouts: lista simple, lista agrupada (por categoría o ciudad), vista de detalle y descarga vCard (RFC 6350).

tt_address se integra con otras extensiones: maps2 y ext:leaflet para integración de mapas, direct_mail y mail para envío de newsletters (tt_address como lista de destinatarios), ke_search e indexed_search para búsqueda de texto completo sobre datos de direcciones. Las geocoordenadas pueden determinarse automáticamente mediante un servicio de geocodificación (Google Maps API, Nominatim) a partir de la dirección postal.

## Problemas frecuentes y soluciones

**Las imágenes no se muestran.** Desde TYPO3 v10, tt_address usa FAL (File Abstraction Layer) para imágenes. Instalaciones antiguas tienen imágenes almacenadas como nombres de archivo en un campo (no como referencia FAL). Solución: ejecutar el script de actualización de tt_address que convierte las referencias antiguas en referencias FAL.

**Faltan geocoordenadas para el buscador de sedes.** Direcciones sin latitud/longitud no aparecen en el mapa. Introducir manualmente las coordenadas de 200 sedes no es práctico. Solución: automatizar la geocodificación mediante tarea del Scheduler. tt_address no ofrece geocodificación propia, pero Gosign implementa un cronjob que completa las coordenadas faltantes mediante la API Nominatim (OpenStreetMap, gratuita, conforme al RGPD).

**Importación de datos desde sistemas externos.** Los departamentos de RRHH mantienen datos de empleados en SAP, Personio u otro sistema de RRHH. Los datos deben aparecer automáticamente en la web. Solución: construir un mecanismo de sincronización que importe CSV o JSON del sistema de RRHH y cree o actualice registros tt_address.

## Migración y compatibilidad de versiones

tt_address es compatible activamente con TYPO3 v11, v12 y v13. La extensión la cogestiona Georg Ringer (el desarrollador de la extensión News) y sigue un ciclo de releases claro. Las actualizaciones para nuevas versiones major de TYPO3 aparecen generalmente pocas semanas después del release LTS.

Para empresas que no tienen gestión de direcciones existente, Gosign recomienda tt_address como punto de partida para todos los escenarios con menos de 5.000 registros. La extensión es estable, bien documentada, tiene una gran comunidad y se integra perfectamente con otras extensiones TYPO3. Para volúmenes mayores o requisitos de sincronización complejos (sincronización en tiempo real con SAP HR, Active Directory o sistemas CRM), Gosign construye una capa de sincronización personalizada que usa tt_address para la salida en frontend pero deja la soberanía de datos en el sistema fuente.

La configuración inicial de un proyecto tt_address (instalación, adaptación de plantillas, estructura de categorías, configuración de geocodificación) se estima en 2 a 4 días de desarrollo. Un buscador de sucursales con integración de mapa y búsqueda por código postal requiere de 5 a 8 días, incluyendo la integración de Leaflet o maps2.

--- typo3db_legacy TYPO3 - Migración de BD | Gosign ---
> Capa de compatibilidad para la antigua TYPO3 Database API (`$GLOBALS['TYPO3_DB']`). Puente para extensiones que aún no han migrado a Doctrine DBAL ...

## Por qué typo3db_legacy supone un riesgo de seguridad desde TYPO3 v12

TYPO3 cambió completamente la abstracción de base de datos a Doctrine DBAL con la versión 8. La antigua API vía `$GLOBALS['TYPO3_DB']` se marcó como deprecated desde v9 y se eliminó completamente en v12. A pesar de ello, miles de instalaciones TYPO3 funcionan en la práctica con extensiones basadas en la API legacy. typo3db_legacy mantiene estas extensiones vivas emulando la antigua API como capa de compatibilidad.

El problema: la extensión no es una solución permanente, sino un puente. Cada nueva versión de TYPO3 aumenta el riesgo de que la propia capa de compatibilidad falle. Quien hoy aún usa typo3db_legacy se enfrenta a una decisión clara - migrar o arriesgarse con la actualización a v13.

## Escenarios de uso habituales

**Extensiones propias con accesos directos a base de datos.** Muchas agencias desarrollaron entre 2012 y 2018 extensiones que llaman directamente a `$GLOBALS['TYPO3_DB']->exec_SELECTquery()`. En una instalación típica de PYME se encuentran de 3 a 8 extensiones de este tipo. Sin typo3db_legacy, fallarían con Fatal Errors tras una actualización a v10+.

**Extensiones de terceros sin mantenedor activo.** Extensiones como versiones antiguas de add-ons de tt_address, directorios sectoriales o herramientas de importación especializadas fueron a menudo mantenidas por desarrolladores individuales. Si el mantenedor ya no está activo, typo3db_legacy es la única opción para conservar la funcionalidad durante la actualización.

**Migración por fases de instalaciones grandes.** Empresas con más de 50 extensiones no pueden migrar todo simultáneamente. typo3db_legacy permite un enfoque gradual: primero la actualización del core, luego extensión por extensión a Doctrine DBAL. Gosign planifica estas migraciones en sprints de 3 a 5 extensiones priorizadas por criticidad de negocio.

## Arquitectura técnica

typo3db_legacy se registra como extensión TYPO3 y proporciona la clase `DatabaseConnection` que implementa los mismos métodos que la antigua API: `exec_SELECTquery()`, `exec_INSERTquery()`, `exec_UPDATEquery()`, `exec_DELETEquery()` y las variantes de prepared statements.

Internamente, la capa redirige todas las llamadas a Doctrine DBAL. Esto funciona de forma fiable para queries estándar. Se vuelve problemático con funciones MySQL directas en queries, prepared statements con parámetros nombrados en formato antiguo, y manejo de transacciones que no mapea 1:1 a Doctrine. Además, cada query atraviesa una capa de abstracción adicional con un overhead de rendimiento del 5-15 %.

## Problemas frecuentes y soluciones

**La extensión no funciona pese a typo3db_legacy tras la actualización.** La causa suele ser que la extensión no solo usa `$GLOBALS['TYPO3_DB']`, sino también otras APIs eliminadas. Solución: un análisis completo del código de la extensión, no solo de las llamadas a base de datos. El Extension Scanner de TYPO3 proporciona una lista priorizada. Gosign realiza estos análisis como inventario previo - esfuerzo típico: 2 a 4 horas por instalación.

**Las queries devuelven resultados distintos a antes de la actualización.** Doctrine DBAL trata los tipos de forma más estricta que la antigua API basada en `mysqli`. Un `WHERE uid = '5'` (string en vez de integer) puede causar comportamiento inesperado en casos límite. Solución: revisar todas las queries para tipos PHP correctos.

**Caída de rendimiento tras la instalación.** Instalaciones con más de 100.000 registros y queries frecuentes notan el overhead de la doble abstracción. Solución: solo la migración completa a Doctrine DBAL con QueryBuilder hace innecesaria la capa legacy.

## Migración y compatibilidad de versiones

typo3db_legacy fue parte oficial del TYPO3 Core hasta la versión 9.5 LTS. Para TYPO3 v10 y v11 existía como paquete Composer separado. Para TYPO3 v12 LTS ya no hay release oficialmente soportado. Para TYPO3 v13 no hay capa de compatibilidad prevista ni realista.

La ruta de migración recomendada: cada llamada `exec_SELECTquery()` se reescribe al QueryBuilder de Doctrine DBAL. Una extensión típica con 10 a 20 llamadas a queries se migra en 4 a 8 horas. Para extensiones complejas con queries construidas dinámicamente, el esfuerzo sube a 2 a 3 días por extensión. Gosign emplea análisis de código automatizado que identifica todas las llamadas a la API legacy y sugiere código de migración.

--- DSGVO iFrame TYPO3 - Consentimiento | Gosign ---
> Incrustación de iFrame conforme con el RGPD para TYPO3: cargar vídeos, mapas y redes sociales solo tras consentimiento. Solución de dos clics...

## Incrustar vídeos de YouTube y Google Maps sin consentimiento es una infracción del RGPD con riesgo de sanción

Cada iFrame incrustado de un servicio externo transmite la dirección IP del visitante al proveedor del servicio incluso antes de que el visitante interactúe. Un vídeo de YouTube en la página de inicio envía la IP a Google al cargar la página, un mapa de Google Maps a Google, un widget de Facebook a Meta. Sin el consentimiento previo del visitante, eso constituye una infracción del RGPD (art. 6.1.a). Desde la sentencia del TJUE en el caso Planet49 (2019) y las resoluciones posteriores de la AEPD sobre banners de cookies, la situación jurídica es clara: las transmisiones de datos a terceros que no son técnicamente necesarias exigen consentimiento informado. udg_gdpr_iframe implementa la solución de dos clics para TYPO3: los iFrames solo se cargan tras un clic explícito del visitante. Un placeholder indica qué servicio se va a cargar y qué datos se transmitirán.

## Los escenarios típicos afectan a YouTube, Google Maps e incrustaciones de redes sociales

El escenario más frecuente son los vídeos de YouTube en sitios corporativos. Una empresa muestra en su página de empleo un vídeo de captación. Sin solución de consentimiento, la página envía en cada visita la IP del visitante a Google. Con udg_gdpr_iframe, el visitante ve en lugar del vídeo un placeholder con imagen de previsualización, el aviso "Este vídeo está suministrado por YouTube. Al reproducirlo se transmitirán datos a Google" y un botón "Cargar vídeo". Solo tras el clic se carga el iFrame y se reproduce el vídeo.

Un segundo escenario es el mapa de Google Maps en la página de contacto. El mapa de llegada es un elemento estándar, pero también un riesgo en materia de protección de datos. udg_gdpr_iframe muestra en su lugar una imagen estática del mapa (captura) como placeholder. Los visitantes que necesitan el mapa interactivo pulsan "Cargar mapa" y aceptan con ello la transmisión de datos a Google.

Tercer escenario: incrustaciones de redes sociales. Un artículo de blog cita un tuit o una publicación de Instagram. Esas incrustaciones también cargan recursos externos y transmiten datos del usuario. udg_gdpr_iframe bloquea la incrustación y muestra un placeholder que identifica el servicio y ofrece un texto de previsualización.

## La arquitectura técnica sustituye los iFrames por placeholders con cargador JavaScript

La extensión registra un elemento de contenido o modifica los elementos existentes de TYPO3 que contienen iFrames. En el HTML, el atributo src del iFrame se sustituye por un atributo data-src. El navegador no carga el iFrame porque falta el atributo src. En su lugar, un div placeholder muestra el nombre del servicio, el aviso de protección de datos y un botón de activación.

Al pulsar el botón, un snippet JavaScript copia el data-src al atributo src y el navegador carga el iFrame. Opcionalmente, el visitante puede activar una casilla "Cargar siempre" que guarda su decisión en LocalStorage. En visitas posteriores, el iFrame se carga sin nueva interacción.

La presentación del placeholder es configurable mediante plantillas Fluid: imagen de previsualización (por ejemplo, el thumbnail de YouTube), texto, etiqueta del botón, enlace a la política de privacidad. Para vídeos de YouTube, la extensión puede obtener el thumbnail automáticamente desde la API de YouTube (sin iFrame, solo una petición de imagen).

La integración con plataformas de gestión de consentimiento existentes (CookieBot, OneTrust, Borlabs Cookie) es posible mediante la API JavaScript: si el visitante ha consentido en el banner la categoría "Marketing", todos los iFrames de marketing se cargan automáticamente sin doble clic.

## Los problemas habituales afectan a la detección de todos los iFrames y a la integración con el CMP

El mayor problema es detectar todos los iFrames del sitio de forma completa. Los redactores no solo incrustan iFrames en elementos de contenido, sino también directamente en el editor enriquecido (RTE), en plantillas Fluid y en TypoScript. La extensión debe cubrir todas las fuentes. Un error frecuente: los elementos de contenido están protegidos, pero un iFrame de YouTube en la plantilla del pie se sigue cargando sin consentimiento. La solución: tras la instalación, realizar un rastreo completo del sitio e identificar todas las fuentes de iFrame.

Segundo problema: la integración con el sistema de gestión de consentimiento. Si el sitio ya utiliza Borlabs Cookie o CookieBot, pueden aparecer conflictos: el CMP bloquea el iFrame con su propio mecanismo y udg_gdpr_iframe lo bloquea de nuevo. El resultado: placeholders dobles o un iFrame que no se carga ni siquiera tras el consentimiento del CMP. La solución: usar udg_gdpr_iframe o el CMP para el bloqueo de iFrames, pero no ambos.

Tercer tema: accesibilidad. El placeholder debe ser accesible por lectores de pantalla: el botón necesita un aria-label, el aviso de privacidad debe estar como texto (no como imagen) y la navegación por teclado debe funcionar.

## TYPO3 v12 está soportado, la extensión sigue siendo relevante mientras existan los iFrames

udg_gdpr_iframe resuelve un problema que cobra más relevancia con cada nueva interpretación del RGPD. La extensión funciona de forma estable bajo TYPO3 v12. Para v13 hace falta actualizar el registro de elementos de contenido y el cargador JavaScript. Como la funcionalidad central (sustituir el src del iFrame por data-src) es técnicamente trivial, la extensión puede portarse a cualquier versión de TYPO3 con poco esfuerzo. En las auditorías de protección de datos, Gosign verifica la cobertura completa de iFrames y recomienda la solución que encaje con el sistema de gestión de consentimiento existente en el sitio.

--- Umfrage TYPO3 - Plugin de encuestas | Gosign ---
> Plugin de encuestas para TYPO3. Encuestas sencillas directamente en TYPO3, sin herramientas externas. Para requisitos complejos Gosign recomienda LimeSurvey.

## Las encuestas rápidas directamente en el sitio web generan una participación que los comentarios no consiguen

Los artículos de blog con función de comentarios generan en la práctica menos de un 1 por ciento de interacción. Una encuesta ("¿Está usted de acuerdo?", "¿Qué opción prefiere?") alcanza entre un 5 y un 15 por ciento, porque la barrera es más baja: un clic en lugar de escribir un texto. El Umfragetool para TYPO3 aporta encuestas sencillas directamente al CMS. Los redactores crean encuestas en el backend (pregunta, opciones de respuesta, selección múltiple sí/no, visualización del resultado), las incrustan como elemento de contenido y ven los resultados en tiempo real. Para captar una opinión rápida es suficiente. Para cuestionarios científicos o complejos recomendamos la integración con LimeSurvey, que ofrece tipos de pregunta y análisis mucho más potentes.

## Los escenarios típicos abarcan encuestas de lectores, feedback de eventos y votaciones

El escenario más frecuente es la encuesta de lectores en un sitio de noticias o blog. Una revista especializada pregunta: "¿Qué funcionalidad le gustaría más en TYPO3 v14?" con cinco opciones de respuesta. Los lectores pulsan su elección y ven inmediatamente el reparto porcentual. Eso genera engagement, aporta a la redacción un termómetro del estado de ánimo y añade al artículo un componente interactivo que aumenta el tiempo de permanencia.

Un segundo escenario es el feedback de eventos. Tras una conferencia o un webinar, los participantes ven en el sitio TYPO3 una encuesta: "¿Cómo valora el evento?" (muy bien / bien / aceptable / mal). No sustituye a un cuestionario de feedback extenso, pero es una medida rápida de satisfacción que cumplimentan más participantes que una encuesta por correo.

Tercer escenario: votaciones en asociaciones y órganos colegiados. Una asociación profesional somete a votación el rediseño de su logotipo. Tres propuestas se someten a elección, cada socio tiene un voto. En combinación con fe_login se garantiza que solo los miembros registrados voten y que cada uno participe una sola vez.

## La arquitectura técnica almacena las encuestas como registros Extbase con recuento de resultados

El Umfragetool define dos modelos Extbase: Poll (pregunta, descripción, fechas de inicio y fin, flag de selección múltiple) y Option (texto de respuesta, número de votos). Un Poll contiene varias Options. Los votos se guardan como contador (incremento de un entero) en la Option, no como registros individuales por participante. Esto mantiene la base de datos ligera y el rendimiento alto, pero implica que las respuestas individuales no son rastreables.

En el frontend, la extensión renderiza un formulario con botones de radio (selección simple) o casillas (selección múltiple). Tras el envío se incrementa el contador de la opción elegida y se muestra el resultado como gráfico de barras horizontales con valores porcentuales.

Contra los votos múltiples, la extensión aplica detección de duplicados basada en cookies: tras la participación se establece una cookie que impide votar de nuevo. No es una protección segura (las cookies se pueden borrar), pero es suficiente para encuestas de opinión sin requisitos formales. Para votaciones vinculantes es necesario combinarla con fe_login, que permite verificar contra la tabla fe_users.

## Los problemas habituales afectan a la seguridad frente a manipulación y a la falta de funciones de análisis

El mayor problema en las encuestas abiertas es la manipulabilidad. Sin login, un visitante puede borrar la cookie y votar de nuevo. En el modo de incógnito, el bloqueo por cookie no funciona en absoluto. Quien necesite resultados sólidos debe ligar la encuesta al fe_login. Para captar opiniones de forma informal ("¿Qué le interesa?"), la solución por cookie es, en cambio, aceptable.

Segundo problema: falta de funciones de análisis. El Umfragetool solo almacena totales, sin evolución temporal, sin segmentación por grupos de usuarios, sin tablas cruzadas. Si la explotación debe ir más allá de "el 63 % elige la opción A", LimeSurvey o una herramienta dedicada de encuestas es la mejor elección.

Tercer tema: personalización del diseño. Las plantillas incluidas son funcionales, pero no están pensadas para las exigencias actuales de UI. Quien quiera presentar encuestas con un diseño cuidado y animaciones (barras que se rellenan, porcentajes que cuentan) debe sobrescribir las plantillas Fluid y añadir CSS y JS propios.

## TYPO3 v12 está soportado, para encuestas complejas LimeSurvey es la mejor elección

El Umfragetool funciona de forma estable bajo TYPO3 v12. Para v13 hace falta actualizar el registro del plugin. Como la extensión es técnicamente ligera (dos modelos Extbase, un controlador, una plantilla Fluid), la migración es sencilla. Gosign recomienda la extensión para encuestas simples con tres a cinco opciones de respuesta. En cuanto se necesiten tipos de pregunta como escalas Likert, campos de texto abierto, matrices o lógica condicional, una integración con LimeSurvey es la solución más profesional.

--- VHS Development TYPO3 | Gosign ---
> Versión para desarrolladores de la colección VHS ViewHelper. Probar las últimas funciones antes del lanzamiento oficial.

## Por qué la versión de desarrollo de VHS es un arma de doble filo para agencias TYPO3

VHS (ViewHelpers Supplementary) es, con más de 300 ViewHelpers, la ampliación Fluid más completa para TYPO3. La versión de desarrollo ofrece nuevos ViewHelpers y correcciones de errores antes de que se integren en un release estable. Para desarrolladores que trabajan en proyectos actuales y esperan un bugfix específico o una nueva funcionalidad, eso es una ventaja. Para webs en producción es un riesgo: las versiones de desarrollo no están completamente testadas y pueden cambiar de forma incompatible entre commits.

La decisión de usar VHS Development no es técnica, sino organizativa: tiene el equipo capacidad para testear y reaccionar rápidamente si algo se rompe. Y existe la disciplina organizativa para sustituir la versión de desarrollo por un release estable antes del go-live.

## Escenarios de uso habituales

**Acceso a bugfixes antes del siguiente release estable.** Un proyecto usa el ViewHelper VHS `v:format.trim` que tiene un bug en la versión estable. El fix ya existe en la rama de desarrollo, pero el siguiente release estable está previsto en 4 semanas. El equipo cambia temporalmente a VHS Development para aprovechar el bugfix inmediatamente.

**Evaluación de nuevos ViewHelpers para un relanzamiento.** Un relanzamiento TYPO3 comienza en 3 meses. El equipo de desarrollo evalúa si nuevos ViewHelpers VHS pueden simplificar el código de las plantillas. La versión de desarrollo se instala en un entorno local de desarrollo, se prueba y los resultados alimentan la decisión arquitectónica.

**Contribución al desarrollo de VHS.** Agencias que contribuyen con ViewHelpers propios o reportan bugs trabajan con la versión de desarrollo para testear sus parches contra el estado actual del código.

## Arquitectura técnica

VHS Development no es una extensión separada, sino el estado de desarrollo actual del repositorio VHS en GitHub (FluidTYPO3/vhs). La instalación se realiza vía Composer con `dev-main` o una rama específica. La configuración `minimum-stability` en `composer.json` debe ajustarse a `dev`, lo cual afecta a todos los paquetes.

Los más de 300 ViewHelpers cubren áreas como: Content (renderizado de elementos, acceso FAL, manejo de medios), Format (manipulación de strings, fechas, números, JSON, Markdown), Iterator (operaciones con arrays, ordenación, filtrado, paginación), Page (navegación del árbol de páginas, breadcrumb, sitemap), Media (manipulación de imágenes, embedding de vídeo) y Security (verificaciones de acceso, estado de login).

La versión de desarrollo puede contener ViewHelpers cuya API aún cambia. Entre dos releases estables, la signatura de 5 a 15 ViewHelpers cambia típicamente en la rama de desarrollo.

## Problemas frecuentes y soluciones

**Un composer update rompe plantillas existentes.** Un `composer update` obtiene la versión de desarrollo más reciente donde se ha renombrado un parámetro de ViewHelper. Todas las plantillas que usan ese parámetro arrojan errores. Solución: hacer commit consistente del Composer lock file e instalar VHS Development con una referencia de commit fija: `composer require fluidtypo3/vhs:dev-main#abc1234`.

**minimum-stability dev afecta a otros paquetes.** Si `minimum-stability` se establece en `dev`, otros paquetes también pueden instalar versiones inestables. Solución: mantener `"minimum-stability": "stable"` y definir VHS Development explícitamente como excepción: `"fluidtypo3/vhs": "dev-main as 6.99.0"`.

**La pipeline CI/CD falla con la versión de desarrollo.** Tests automáticos y despliegues pueden fallar si GitHub no está temporalmente accesible o la rama recibió un force push. Solución: para pipelines CI/CD usar un mirror Composer local (Satis) o cambiar al release estable.

## Migración y compatibilidad de versiones

Los releases estables de VHS siguen los ciclos LTS de TYPO3: VHS 6.x soporta TYPO3 v11, VHS 7.x soporta TYPO3 v12. La rama de desarrollo apunta a la siguiente versión major.

Gosign recomienda la siguiente estrategia: en entornos de desarrollo y ramas feature usar la versión de desarrollo para evaluar nuevos ViewHelpers. En staging y producción usar exclusivamente releases estables. Si un bugfix crítico solo está disponible en development, fijar el commit específico como referencia Composer y dejar un comentario TODO en el código que aparezca en la siguiente revisión de release estable.

--- VHS TYPO3 - Fluid ViewHelper | Gosign ---
> La colección de ViewHelpers para TYPO3 Fluid Templates de FluidTYPO3. Cientos de ViewHelpers adicionales para Media, Content, Page, Iterator, Math, String. ...

## EXT:vhs es la caja de herramientas invisible de toda plantilla TYPO3 profesional

Quien trabaja en TYPO3 con Fluid y va más allá del simple volcado de contenidos, acaba tarde o temprano en EXT:vhs. La extensión del ecosistema FluidTYPO3 entrega varios cientos de ViewHelpers adicionales para tareas que el núcleo no cubre a propósito: manipulación de imágenes, lógica de iterador, operaciones matemáticas, manejo de strings, consultas de contenido, navegación de páginas. Para desarrolladoras frontend en agencias y equipos internos, vhs no es un nice-to-have opcional, sino la base sobre la que nacen estructuras de plantilla complejas sin rodeos por PHP.

El público típico son equipos que mantienen sitepackages exigentes: editoriales con tipos de contenido heterogéneos, universidades con navegaciones anidadas, grandes empresas con portales multilingües. Sin vhs cada segundo requisito especial tendría que externalizarse a un ViewHelper propio o a TypoScript. Con vhs la lógica se queda donde corresponde: en la plantilla.

## Escenarios típicos de uso

Un primer escenario es la consulta de contenido desde ramas de árbol ajenas. Un portal de clientes de un fabricante de maquinaria con 3.000 páginas de producto necesita en cada página un bloque teaser con noticias actuales procedentes de una rama de rootline de noticias separada. El ViewHelper `v:content.get` recupera contenidos de cualquier página y permite así composiciones de página modulares sin tener que construir objetos CONTENT en TypoScript.

Un segundo escenario es el procesamiento con iteradores. Una editorial mantiene artículos con categorías, etiquetas y autores como ObjectStorage. Solo con Fluid los filtrados, agrupaciones y ordenaciones sobre objetos anidados resultan incómodos. Con `v:iterator.filter`, `v:iterator.sort` o `v:iterator.groupBy` esas operaciones pueden leerse y mantenerse directamente en la plantilla.

Un tercer escenario es el tratamiento de imágenes. Una tienda de comercio electrónico con 500 productos por temporada necesita variantes responsive con etiqueta picture, fallback WebP y placeholder LQIP. Con los ViewHelpers Media de vhs ese bloque se define una vez en el partial y se reutiliza en todas partes.

Un cuarto escenario es la preparación matemática de indicadores en páginas de reporting. Quien quiere mostrar precios con subtotales, porcentajes o medias ponderadas recurre a `v:math.sum`, `v:math.percentage` o `v:math.division` sin tener que construir un controlador propio para cada cálculo.

## Arquitectura técnica

EXT:vhs es una extensión puramente de librería, sin módulos de backend y sin tablas de base de datos. Registra namespaces en Fluid (`{namespace v=FluidTYPO3\Vhs\ViewHelpers}`) y pone así los ViewHelpers a disposición bajo el prefijo `v:`. La extensión no tiene dependencias duras con el resto del stack FluidTYPO3 (Flux, Fluidcontent), aunque a menudo se utiliza junto con ellos.

La instalación se realiza mediante Composer con `fluidtypo3/vhs`. En un sitepackage, vhs suele llevarse como dependencia de la propia provider extension, de modo que el registro de namespaces ocurre en la plantilla de layout o globalmente mediante el array de configuración TypoScript. Quien tiene que declarar los namespaces por separado en cada plantilla normalmente ha pasado por alto el camino de registro global.

Para el rendimiento es relevante que vhs no cachea sus propias consultas a base de datos. Quien utiliza `v:content.get` o `v:page.menu` sin caché Fluid genera, en el peor caso, la misma consulta en cada acceso a página. La solución está en un caché Fluid bien configurado sobre Page y Content Cache, así como en el uso consciente del mecanismo CacheStatic del núcleo TYPO3.

El paquete de la extensión es modular. Grupos individuales de ViewHelpers (Asset, Condition, Format, Iterator, Math, Media, Page, Resource, System, Variable) pueden utilizarse de forma dirigida sin que todo el stack entre al proyecto. En la práctica, sin embargo, se instala la colección completa, porque las dependencias entre grupos son difíciles de encapsular y el footprint total de la extensión sigue siendo asumible.

## Problemas frecuentes y soluciones

El primer problema es la famosa colisión de namespaces. Quien usa EXT:vhs en paralelo a ViewHelpers propios bajo el prefijo `v:` obtiene superposiciones impredecibles. La solución es registrar los ViewHelpers propios con constancia bajo un prefijo propio (por ejemplo `my:`) y redirigir las llamadas vhs a los ViewHelpers del núcleo donde el núcleo TYPO3 ya ofrece una alternativa (`f:format.padding` sustituye a `v:format.padding`).

El segundo problema es la compatibilidad con versiones de Fluid más nuevas. En TYPO3 v12 y v13 Fluid se ha reelaborado varias veces, lo que en algunos ViewHelpers de vhs provoca deprecation warnings o errores de tipo. La solución es una auditoría de los ViewHelpers utilizados frente a la matriz de compatibilidad en el repositorio de GitHub y la sustitución selectiva por alternativas del núcleo o implementaciones propias y ligeras.

El tercer problema es el rendimiento bajo carga. `v:iterator.filter` y `v:iterator.sort` son cómodos, pero computacionalmente costosos con grandes volúmenes de datos. Quien renderiza una plantilla con 10.000 productos por página debería mover la lógica de filtro al repositorio y pasar a la plantilla solo el resultado ya filtrado.

Un cuarto problema, a menudo pasado por alto, son los cambios de comportamiento no documentados entre versiones de vhs. Un ViewHelper que en la versión 6.x devolvía un string entrega de pronto en la 7.x un array o al revés. La solución es fijar la versión de vhs en el Composer lock file y revisar en cada upgrade el changelog con cuidado frente al inventario de plantillas propio, idealmente con un paso de lint en el pipeline de CI que señale de inmediato firmas de ViewHelper desconocidas.

## Migración y compatibilidad de versiones

EXT:vhs está oficialmente liberada para TYPO3 v11 y v12. Para v13 existe una rama de desarrollo mantenida activamente, pero aún no apta para producción en todos los ViewHelpers. Los equipos que planean actualmente un upgrade de v11 a v12 pueden llevarse vhs por regla general sin grandes intervenciones. El upgrade path a v13 es para proyectos intensivos en plantillas el punto crítico: aquí vale la pena un análisis coste-beneficio entre mantener vhs y el desmontaje gradual hacia Core Fluid más ViewHelpers propios.

La respuesta estratégica depende del alcance del uso de vhs. Los proyectos que solo utilizan un puñado de ViewHelpers vhs deberían sustituirlos en el próximo upgrade de forma dirigida por construcciones del núcleo o ViewHelpers específicos del proyecto. Los proyectos con cientos de llamadas a vhs a lo largo de todas las plantillas, en cambio, se benefician de seguir con vhs y realizar en cada upgrade un test de compatibilidad dirigido. La sustitución solo merece la pena donde la carga heredada lastra más el mantenimiento que un arrastre controlado.

Gosign acompaña upgrades de TYPO3 con deuda de vhs y decide junto con el equipo qué ViewHelpers vhs se sustituyen por construcciones del núcleo y cuáles nacen de nuevo como ViewHelpers ligeros del proyecto. Así la herencia de plantillas sigue siendo mantenible sin atarse durante más años a un stack de librerías externo.

--- Cache Warmup TYPO3 - Rendimiento | Gosign ---
> warmup: extensión de TYPO3 para Cache Warmup. Precalentamiento automático de caché tras despliegue. Rendimiento óptimo para cada visitante.

## Por qué los primeros 5 minutos tras un despliegue TYPO3 deciden la experiencia de usuario

Tras cada despliegue se vacía el caché de TYPO3. Eso es técnicamente necesario, pero tiene una consecuencia palpable: los primeros visitantes tras el despliegue ven páginas sin caché. En lugar de 200 ms de carga, esperan de 2 a 5 segundos, en páginas complejas incluso más. Con un despliegue a las 9:00 de la mañana, eso afecta exactamente a los visitantes con mayor probabilidad de conversión.

warmup resuelve este problema llenando el caché de forma proactiva antes de que llegue el primer visitante real. La extensión rastrea todas las páginas de la web en segundo plano, basándose en el sitemap, y prioriza las páginas más visitadas. Tras 2 a 10 minutos (según el número de páginas), todo el caché está lleno y cada visitante obtiene el rendimiento completo.

## Escenarios de uso habituales

**Cache warming automático tras despliegues CI/CD.** Una empresa despliega su web TYPO3 de 2 a 3 veces por semana vía pipeline CI/CD. Tras cada despliegue, Deployer vacía el caché. warmup se ejecuta como último paso en la pipeline y llena el caché antes de que el despliegue se considere "exitoso".

**Reconstrucción del caché tras cambios manuales.** Los editores a veces vacían todo el caché desde el backend TYPO3 porque una página no se muestra actualizada. warmup se registra como hook en el evento de vaciado de caché y arranca automáticamente el proceso de warmup. El editor no se da cuenta, pero los visitantes no experimentan caída de rendimiento.

**Warming programado para picos de tráfico.** Una tienda online basada en TYPO3 tiene sus picos entre las 10:00 y las 12:00. Una tarea del Scheduler arranca warmup diariamente a las 9:30 para que el caché esté completamente lleno a tiempo para el pico de tráfico.

## Arquitectura técnica

warmup funciona como comando CLI de TYPO3 y como tarea del Scheduler. El proceso trabaja en tres fases: recopilación de URLs (warmup lee el sitemap.xml y extrae todas las URLs), priorización (las URLs se ordenan por prioridad desde el sitemap, datos de analytics o configuración manual) y crawling (warmup llama a cada URL vía petición HTTP; soporta crawling paralelo, configurablemente con 4 peticiones simultáneas por defecto).

El comando CLI es `vendor/bin/typo3 warmup:execute`. warmup funciona con cualquier backend de caché - sistema de archivos, Redis, Memcached, APCu. En combinación con staticfilecache, warmup genera previamente archivos HTML estáticos que el servidor web sirve directamente.

## Problemas frecuentes y soluciones

**El proceso de warmup dura más de 30 minutos.** Con webs de más de 5.000 páginas y configuración multi-idioma (por ejemplo, 1.000 páginas x 5 idiomas = 5.000 URLs), el warmup puede tardar. Solución: aumentar el paralelismo (por ejemplo, a 8 peticiones simultáneas), excluir páginas poco importantes (paginación, archivos de tags) y limitar el proceso a las 500 páginas principales.

**La carga del servidor sube al 100 % durante el warmup.** warmup genera peticiones HTTP reales contra el propio servidor. Sin limitación de velocidad, la carga del servidor puede llegar a niveles que frenen a visitantes reales. Solución: reducir el paralelismo y configurar un retardo entre peticiones (por ejemplo, 100 ms).

**Las páginas cacheadas no están actualizadas tras el warmup.** warmup cachea la página tal como existe en el momento de la llamada. Si los editores modifican contenido durante el proceso de warmup, el caché no coincide con el estado actual. Solución: iniciar el warmup solo después de completar todos los cambios de contenido.

## Migración y compatibilidad de versiones

La extensión warmup (eliashaeussler/typo3-warming) está disponible para TYPO3 v11 y v12 LTS y se mantiene activamente. Quien hasta ahora usa scripts de warmup manuales (bucles curl, crawlers wget) puede sustituirlos por warmup, con la ventaja de que conoce la estructura del sitemap TYPO3, prioriza por tráfico y se integra en el Scheduler.

La combinación warmup + staticfilecache + Redis es el stack de rendimiento que Gosign recomienda para instalaciones TYPO3 enterprise. warmup llena el caché, staticfilecache sirve archivos HTML estáticos sin PHP, Redis almacena queries de base de datos. En conjunto, las webs TYPO3 alcanzan tiempos de carga por debajo de 100 ms.

--- Widget meteorológico TYPO3 | Gosign ---
> Widget meteorológico para TYPO3: datos actuales de OpenWeatherMap u otras APIs. Sitios web de turismo, eventos al aire libre, portales regionales.

## Los sitios de turismo que no muestran el tiempo actual regalan una de las informaciones más buscadas

Cuando alguien busca en Google "tiempo Mallorca" o "Sierra Nevada tiempo ahora", espera encontrar en el sitio del destino una indicación meteorológica. Si no la hay, el visitante abandona la página y acude a una aplicación del tiempo. Eso es una oportunidad perdida, porque el visitante ya estaba en el sitio correcto. weather2 integra datos meteorológicos actuales en TYPO3: temperatura, condiciones, precipitaciones, viento, humedad y una previsión a varios días. Los datos proceden de OpenWeatherMap o APIs equivalentes y se actualizan en un intervalo configurable. Para los sitios de turismo, los portales de eventos al aire libre y los portales regionales de noticias, es una función estándar que los visitantes esperan encontrar.

## Los escenarios típicos abarcan portales de destino, campings y estaciones de esquí

El escenario más frecuente es el portal de turismo de una región. La oficina de turismo de un municipio del Mediterráneo muestra en su página de inicio el tiempo actual: 22 grados, soleado, temperatura del agua 19 grados. Al lado, una previsión a cinco días. Los visitantes que planifican una excursión de un día obtienen al instante la información relevante y permanecen en la página para reservar actividades. La temperatura del agua llega desde un endpoint de API independiente o se mantiene manualmente.

Un segundo escenario son los campings y los parques vacacionales. Un camping del Pirineo muestra en su página de reservas el tiempo de la próxima semana. Los visitantes que dudan entre dos semanas de viaje pueden usar la previsión como ayuda para decidirse. Para el operador del camping es un argumento de conversión: "Hace sol, reserve ahora".

Tercer escenario: estaciones de esquí y eventos al aire libre. Una estación de esquí muestra la temperatura en cumbre y en valle, el espesor de nieve (desde una fuente de datos aparte) y la velocidad del viento. Un festival al aire libre muestra la previsión meteorológica para el fin de semana del festival. En ambos casos, la indicación meteorológica aporta un valor concreto que mantiene al visitante en el sitio.

## La arquitectura técnica recupera los datos meteorológicos por API y los cachea localmente

weather2 se comunica con la API de OpenWeatherMap (o, alternativamente, con proveedores como WeatherAPI, Visual Crossing o Meteostat). La configuración en el backend de TYPO3 define: API-Key, ubicación (coordenadas o nombre de la localidad), unidades (métrico/imperial), idioma e intervalo de actualización. El intervalo estándar es de 30 minutos, es decir, cada 30 minutos se envía una petición a OpenWeatherMap y la respuesta se cachea en la base de datos TYPO3.

El plugin de frontend renderiza los datos meteorológicos mediante plantillas Fluid: temperatura actual, icono del tiempo (sol, nubes, lluvia), descripción en texto, viento, humedad. La previsión a varios días muestra la mínima y la máxima del día para tres a siete días. Los iconos se suministran como SVG, no como URLs de imágenes externas, para que no haya peticiones adicionales a servidores de terceros.

Para la API-Key, OpenWeatherMap ofrece un plan gratuito con 1.000 llamadas al día, lo que con un intervalo de 30 minutos (48 llamadas al día) es más que suficiente. Para sitios con varias ubicaciones (por ejemplo, una oficina de turismo con 10 municipios) se necesitan 480 llamadas al día, lo que sigue estando dentro del plan gratuito. Los planes Pro (desde 40 dólares al mes) ofrecen actualizaciones cada hora y datos ampliados como el índice UV y el polen.

## Los problemas habituales afectan a los límites de la API, al caché y a los datos obsoletos

El problema más frecuente es superar el límite de la API. Si el caché de TYPO3 no está configurado correctamente y cada request de página dispara una llamada a la API, el límite del plan gratuito de 1.000 llamadas se alcanza en pocas horas. La extensión dejará entonces de mostrar datos o mostrará un error. La solución: asegurarse de que los datos meteorológicos se almacenan en el caché de TYPO3 y no se vuelven a solicitar en cada request de frontend. El cacheo debe funcionar con independencia del caché de página (tarea Scheduler o entrada de caché propia).

Segundo problema: datos meteorológicos obsoletos. Si la tarea Scheduler no se ejecuta (cronjob desactivado, migración del servidor), el sitio muestra datos del tiempo con días o semanas de antigüedad. Eso es peor que no mostrar nada. La solución: incorporar en la plantilla Fluid un fallback que compruebe si los datos cacheados tienen más de dos horas y, en ese caso, oculte el widget en lugar de mostrar datos erróneos.

Tercer tema: protección de datos. Si los datos meteorológicos los obtiene el cliente directamente vía JavaScript desde la API, el navegador transmite la IP del visitante al proveedor de la API. Se trata de una transmisión de datos a terceros con relevancia en materia de RGPD. La solución del lado del servidor (el servidor TYPO3 consulta la API, no el navegador) evita este problema.

## TYPO3 v12 está soportado, la integración con la API sigue siendo estable entre versiones

weather2 utiliza la librería HTTP Client de TYPO3 para las peticiones a la API y plantillas Fluid para el renderizado. Ambas cosas son estables en el core de TYPO3. Bajo v12 la extensión funciona sin problemas. Para v13 se necesitan ajustes mínimos (registro de tarea Scheduler, configuración del plugin). Como la lógica central (petición HTTP, parseo JSON, almacenamiento en base de datos) está estandarizada, la extensión se mantiene con poco esfuerzo en los upgrades de TYPO3. Gosign configura widgets meteorológicos como parte de los proyectos de sitios turísticos y se asegura de que el caché de la API, el fallback y la protección de datos estén correctamente implementados.

--- web2pdf TYPO3 - Páginas como PDF | Gosign ---
> web2pdf: exportar páginas TYPO3 como PDF. Configuración, rendimiento y alternativas modernas (Puppeteer). Acelerado con IA.

## Por qué web2pdf es imprescindible para webs TYPO3 con listas de precios y páginas de producto

Los equipos comerciales necesitan PDFs imprimibles. Los clientes esperan en las páginas de producto un botón "Guardar como PDF". Y los compradores de la industria descargan listas de precios para reenviarlas internamente. web2pdf resuelve exactamente este problema: la extensión renderiza cualquier página TYPO3 como PDF - con layout correcto, imágenes embebidas y tipografía limpia. En lugar de crear cada página manualmente como PDF y actualizarla ante cambios, web2pdf genera el PDF en vivo a partir del contenido actual.

Eso no solo ahorra tiempo de redacción, sino que también evita versiones PDF obsoletas. Si el precio de un producto se modifica en el CMS, web2pdf entrega automáticamente la versión actualizada en la siguiente descarga.

## Escenarios de uso habituales

**Catálogos de producto y listas de precios en B2B.** Una empresa de maquinaria gestiona 200 páginas de producto en TYPO3. El equipo comercial necesita una ficha técnica imprimible de cada producto. web2pdf genera desde cada página de producto un PDF con logo, datos técnicos e información de contacto en el diseño corporativo.

**Artículos y whitepapers como descarga.** Medios y editoriales especializadas ofrecen artículos de revista como descarga PDF. web2pdf convierte el artículo incluyendo imágenes y formato en un PDF optimizado para impresión. Un CSS de impresión controla qué elementos aparecen en el PDF (contenido) y cuáles no (navegación, footer, banner de cookies).

**Ofertas y configuraciones.** Resultados de configuradores, resúmenes de ofertas o vistas generales del carrito se exportan como PDF vía web2pdf.

## Arquitectura técnica

web2pdf funciona como extensión TYPO3 con un plugin frontend que muestra un botón de descarga PDF en cada página. Al hacer clic, la extensión llama internamente a la página actual y pasa la salida HTML a un motor de renderizado PDF. La extensión soporta dos motores: wkhtmltopdf (la solución clásica basada en una versión antigua de WebKit, sin soporte CSS Flexbox/Grid) y Puppeteer/Chromium (la alternativa moderna con soporte CSS completo y embebido correcto de webfonts).

Un CSS de impresión separado (`@media print`) controla qué elementos son visibles en el PDF. Gosign recomienda ocultar navegación, footer, banner de cookies y elementos interactivos, e insertar en su lugar logo, datos de contacto y código QR con la URL fuente.

## Problemas frecuentes y soluciones

**El PDF muestra layout incorrecto, faltan imágenes o fuentes.** Causa más frecuente: wkhtmltopdf no puede renderizar CSS moderno. Webs que usan Flexbox o CSS Grid se ven completamente distintas en el PDF. Solución: cambiar a Puppeteer como motor de renderizado.

**La generación del PDF tarda más de 10 segundos.** Puppeteer arranca un proceso Chromium por cada PDF. Con peticiones simultáneas se multiplica la carga del servidor. Solución: implementar caché de PDF. El PDF generado se almacena en caché durante un tiempo definido (por ejemplo, 60 minutos).

**Páginas autenticadas entregan un PDF vacío.** web2pdf llama a la página internamente vía HTTP. Si la página está detrás de un login, faltan las cookies de sesión y el proceso de renderizado solo ve la página de login. Solución: configurar un endpoint de renderizado PDF dedicado que resuelva la autenticación vía token en lugar de cookies de sesión.

## Migración y compatibilidad de versiones

web2pdf está disponible de forma estable para TYPO3 v10 y v11. Para TYPO3 v12 LTS existen forks de la comunidad. El paquete original ya no se mantiene activamente.

Para TYPO3 v13 en adelante, Gosign recomienda un cambio arquitectónico: en lugar de operar web2pdf como extensión TYPO3, la generación de PDF se implementa como microservicio separado. Un servicio Node.js con Puppeteer recibe URLs y devuelve PDFs. Eso desacopla la generación de PDF del servidor TYPO3.

Un aspecto frecuentemente subestimado: la accesibilidad. Los PDFs generados desde HTML no son automáticamente accesibles. Conforme a la Directiva Europea de Accesibilidad y la normativa española vigente, los PDFs generados deben contener estructuras Tagged PDF. Ni wkhtmltopdf ni Puppeteer generan por defecto PDFs accesibles. Gosign recomienda para estos casos un procesamiento posterior con una librería PDF especializada.

--- Webflow a TYPO3 - Migración | Gosign ---
> Migración de sitios web Webflow a TYPO3: más control, sin dependencia de plataforma, funciones enterprise.

## Los sitios en Webflow chocan con límites duros cuando aparecen requisitos enterprise

Webflow es excelente para prototipos, landings y startups con tres a cinco personas. Pero a partir de cierto punto, la plataforma se convierte en un problema: sin soporte multilenguaje de nivel enterprise, sin gestión granular de permisos, sin flujos personalizados en el backend, sin opción on-premise y con hosting exclusivamente en servidores de Webflow en Estados Unidos. Para las empresas que necesitan alojamiento en la UE (RGPD, Schrems II), que gestionan cientos de páginas y que requieren un CMS con flujos editoriales, TYPO3 es la evolución lógica. Gosign migra sitios Webflow a TYPO3: el diseño existente (HTML/CSS) se convierte en plantillas Fluid, el contenido se transfiere de forma estructurada y la funcionalidad se completa con extensiones TYPO3.

## Los escenarios típicos afectan a empresas en crecimiento, sectores regulados y despliegues internacionales

El escenario más frecuente es la startup de rápido crecimiento que ya no consigue escalar su sitio Webflow. Con 20 personas y un sitio en un idioma, Webflow funciona. Con 200 personas, cinco idiomas y un blog con 500 artículos, deja de funcionar. La estructura de precios de Webflow no escala: los planes CMS están limitados a 10.000 elementos, el código personalizado es restringido, los accesos API están estrangulados. El cambio a TYPO3 da a la empresa el control total sobre el hosting, el rendimiento y la extensibilidad.

Un segundo escenario son los sectores regulados. Un proveedor de servicios financieros tiene su sitio de marketing en Webflow, pero el departamento de compliance exige hosting en la UE, registros de auditoría para los cambios de contenido y un flujo de aprobación a cuatro ojos por cada contenido de página. Webflow no ofrece ninguno de esos puntos de forma nativa. TYPO3 sí: Workspaces para staging y aprobación, ext:belog para registros de auditoría y hosting en un servidor en Madrid o Frankfurt.

Tercer escenario: despliegue internacional. Una empresa industrial tiene su sitio principal en Webflow en inglés. Ahora quiere crear sitios de país en 12 idiomas. Webflow Localization es caro y limitado. TYPO3 ofrece soporte nativo multisite y multilenguaje, en el que cada idioma puede tener su propia estructura de páginas, incluyendo contenidos locales que no existen en todos los idiomas.

## La arquitectura técnica convierte el export de Webflow en plantillas Fluid de TYPO3

La migración sigue un proceso definido: exportar el proyecto Webflow como HTML/CSS/JS, analizar la estructura del sitio y las interacciones utilizadas, convertir el HTML en plantillas Fluid e importar los contenidos en elementos de contenido de TYPO3. El export de Webflow entrega HTML semántico y limpio, que se traduce bien a Fluid. El CSS se incorpora como archivo Sass/SCSS o se reescribe a clases utilitarias de Tailwind, según el setup de TYPO3.

Las interacciones de Webflow (animaciones de scroll, efectos hover, modales) se basan en un motor JavaScript propietario. Trasladarlas 1:1 no es posible. En su lugar, las interacciones se reconstruyen con CSS nativo (transitions, animations) o con JavaScript ligero (IntersectionObserver, elemento Dialog). En la mayoría de los casos, esto reduce el tamaño del archivo JavaScript desde los 200-300 KB (runtime de Webflow) hasta menos de 20 KB.

La importación de contenido se realiza vía API de Webflow o export HTML. Cada Collection de Webflow se mapea a un elemento de contenido o registro Extbase de TYPO3. Los artículos de blog se importan a tx_news, los miembros del equipo como registros personalizados y los testimonios a la estructura de datos existente en TYPO3.

## Los problemas habituales afectan a funciones específicas de Webflow y a las redirecciones de URL

El mayor problema en la migración son las funciones de Webflow sin equivalente en TYPO3. Los Webflow Forms funcionan mediante un manejador integrado. En TYPO3 hay que configurar un sistema de formularios (powermail, Form Framework). Webflow E-Commerce funciona en la plataforma. En TYPO3 hay que instalar un sistema de comercio electrónico (nativo de TYPO3 o integración con Shopware/Magento). Esas lagunas funcionales deben identificarse antes de la migración y planificarse en el proyecto TYPO3.

Segundo problema: redirecciones de URL. Las URLs de Webflow siguen un esquema propio. Tras la migración, todas las URLs antiguas deben redirigir a las nuevas URLs de TYPO3 para que Google no indexe las páginas como 404 y para preservar los enlaces externos existentes. Con 200 páginas, son 200 redirecciones que se configuran en la tabla de redirects de TYPO3 o vía .htaccess.

Tercer tema: diferencias de diseño. Webflow renderiza layouts CSS con un motor propio que puede desviarse del comportamiento estándar del navegador. Un layout que en Webflow se ve perfecto al píxel puede renderizarse de forma ligeramente distinta en TYPO3 porque el CSS reset o la incorporación de fuentes difiere. Una pasada visual de QA tras la migración es por tanto obligatoria.

## La migración no es un upgrade, es un cambio de plataforma

No existe un camino de migración automatizado de Webflow a TYPO3. Cada migración es un proyecto con análisis, conversión, importación y QA. La duración depende de la complejidad: un sitio sencillo con 20 páginas y un blog se migra en dos o tres semanas. Un sitio complejo con 500 páginas, comercio electrónico y cinco idiomas necesita dos o tres meses. Gosign ha llevado a cabo migraciones de Webflow para empresas de 50 a 2.000 páginas y apuesta por la conversión de plantillas asistida por IA, que genera el código Fluid a partir del HTML de Webflow y reduce al mínimo el ajuste manual.

--- WebP TYPO3 - Optimización de imágenes | Gosign ---
> Conversión automática de JPG/PNG a WebP. Archivos de imagen 25–35% más pequeños, tiempos de carga más rápidos.

## Las imágenes representan entre el 50 y el 70 por ciento del peso de una página, y WebP las reduce en un tercio

Un sitio TYPO3 medio carga entre 2 y 5 MB de datos de imagen por página. Es el mayor factor individual del tiempo de carga y, por tanto, del Google PageSpeed Score. WebP es un formato de imagen desarrollado por Google que, con calidad comparable, ocupa entre un 25 y un 35 por ciento menos que JPEG y hasta un 80 por ciento menos que PNG. La extensión WebP para TYPO3 convierte automáticamente las imágenes JPG y PNG existentes en WebP sin que los redactores tengan que cambiar su comportamiento. Las imágenes se suben como siempre al backend FAL, la extensión genera la variante WebP en segundo plano y la entrega a los navegadores que soportan el formato. Todos los navegadores modernos soportan WebP desde 2020: Chrome, Firefox, Safari, Edge.

Para sitios ya optimizados en PageSpeed, la conversión a WebP suele ser el último paso que eleva la puntuación de 85 a 95 o más.

## Los escenarios típicos afectan a sitios con mucha imagen, comercio electrónico y proyectos mobile-first

El escenario más frecuente son los sitios corporativos con mucha imagen. Un portal inmobiliario muestra entre 15 y 25 fotos por cada inmueble. Con 500 inmuebles, son 10.000 imágenes. Sin WebP, las imágenes pesan de media 250 KB (JPEG); con WebP, 170 KB. En una vista de listado con 20 inmuebles y una imagen principal cada uno, WebP ahorra 1,6 MB por cada carga de página. Con 50.000 cargas de página al mes, son 80 GB menos de tráfico, con impacto directo en los costes de hosting.

Un segundo escenario son las integraciones de comercio electrónico. Una tienda muestra las imágenes de producto en varios tamaños: miniatura, listado, detalle y zoom. Para cada tamaño se genera una variante WebP. En una tienda con 2.000 productos y cinco variantes de imagen cada uno, se generan 10.000 archivos WebP que aceleran de forma mensurable la carga de la vista de listado.

Tercer escenario: sitios mobile-first para públicos con conexión de red deficiente. Un portal de una ONG utilizado en regiones con redes 3G se beneficia de forma desproporcionada de los archivos de imagen más pequeños. La diferencia entre 5 segundos y 15 segundos de tiempo de carga decide si el visitante ve la página o la abandona.

## La arquitectura técnica convierte las imágenes dentro del pipeline de procesado de TYPO3

La extensión se engancha en el pipeline de procesado de imágenes de TYPO3. Cuando TYPO3 procesa una imagen (redimensionado, recorte), la extensión genera adicionalmente una variante WebP en el mismo directorio. La entrega se realiza vía Content Negotiation: el servidor comprueba la cabecera Accept del navegador. Si el navegador acepta "image/webp", envía el archivo WebP. De lo contrario, el JPEG/PNG original.

Técnicamente hay dos variantes de implementación: la primera utiliza reglas mod_rewrite en Apache o nginx que redirigen las peticiones de imagen a la variante WebP cuando existe. La segunda utiliza un middleware de TYPO3 que manipula la cabecera de respuesta. La variante mod_rewrite es más rápida porque se ejecuta antes que PHP.

La conversión en sí se realiza con libwebp (la herramienta de línea de comandos cwebp), ImageMagick con soporte WebP o la extensión PHP GD (si está compilada con soporte WebP). La calidad es configurable: por defecto 80 (sobre 100), lo que ofrece un buen equilibrio entre tamaño de archivo y calidad visual. Para contenidos fotográficos recomendamos entre 82 y 85; para capturas e ilustraciones, entre 75 y 78.

Para una compresión aún mejor, las versiones más recientes de la extensión soportan el formato AVIF, que aporta entre un 20 y un 30 por ciento adicional de ahorro respecto a WebP. AVIF está disponible en Chrome y Firefox, y en Safari desde la versión 16.

## Los problemas habituales afectan a las librerías del servidor y a la configuración del CDN

El problema más frecuente es la ausencia del binario cwebp en el servidor. Los entornos de hosting compartido a menudo no tienen libwebp instalada y el proveedor no permite instalar binarios. La solución: usar PHP GD con soporte WebP (disponible en la mayoría de versiones de PHP desde la 7.1) o elegir un proveedor de hosting que ponga cwebp a disposición. En servidores gestionados y en contenedores Docker, la instalación es trivial: apt-get install webp.

Segundo problema: configuración del CDN. Si delante del sitio hay un CDN (Cloudflare, Fastly, AWS CloudFront), debe gestionar WebP correctamente. Dos enfoques: el CDN conoce Content Negotiation y cachea WebP y JPEG como variantes separadas (Vary: Accept). O bien el sitio TYPO3 entrega directamente URLs WebP (sin Content Negotiation) y el CDN cachea solo una versión. Cloudflare ofrece conversión automática a WebP mediante Polish, lo que hace parcialmente prescindible la extensión TYPO3.

Tercer tema: control de calidad. Con ajustes de calidad demasiado bajos (por debajo de 70) aparecen artefactos visibles, especialmente en degradados y texturas finas. Tras la configuración debería realizarse una comparación A/B (original vs. WebP) para asegurar que la calidad es aceptable para el caso de uso.

## TYPO3 v12 y v13 están soportados, la extensión es una de las más estables del ecosistema

La extensión WebP figura entre las extensiones de rendimiento más instaladas en el ecosistema TYPO3. Se mantiene activamente y es compatible con TYPO3 v12 y v13. Como la funcionalidad central (hook de procesado de imágenes, conversión de archivos) se apoya en APIs estables de TYPO3, los breaking changes en los upgrades son poco frecuentes. Gosign configura WebP como estándar en cada nuevo proyecto TYPO3 y, cuando está disponible, activa además AVIF para la máxima compresión.

--- Bootstrap TYPO3 - T3Bootstrap | Gosign ---
> Bootstrap Framework como sitepackage de TYPO3. Plantillas responsive, sistema de grid, componentes Bootstrap como elementos de contenido.

## Los proyectos TYPO3 basados en Bootstrap necesitan un sitepackage que tienda el puente entre el framework y el CMS

Bootstrap es el framework CSS más utilizado del mundo. Más del 25 por ciento de los sitios web lo usan. Para los proyectos TYPO3 eso significa que los diseñadores entregan sus maquetas en Bootstrap, los desarrolladores conocen las clases y los componentes, y los clientes esperan layouts responsive construidos sobre Bootstrap. ws_t3bootstrap incorpora Bootstrap como sitepackage directamente en TYPO3: plantillas responsive, el sistema de grid, componentes Bootstrap (acordeón, cards, carrusel, tabs, alerts) como elementos de contenido y una base TypoScript preconfigurada. En lugar de integrar Bootstrap manualmente en un proyecto TYPO3 vacío, ws_t3bootstrap entrega un punto de partida listo para producción.

## Los escenarios típicos son sitios corporativos, portales y prototipado rápido

El escenario más frecuente es el sitio corporativo de una empresa mediana. Una compañía con entre 50 y 500 personas necesita un sitio con 30 a 80 páginas: portada, quiénes somos, servicios, referencias, carrera, contacto. El diseñador crea una maqueta sobre la base de Bootstrap 5. ws_t3bootstrap aporta las plantillas, el sistema de grid y los elementos de contenido, de modo que el desarrollador solo tiene que añadir el CSS personalizado (colores, tipografías, espaciados) y los componentes específicos del proyecto. Tiempo de desarrollo habitual: de dos a tres semanas desde la maqueta hasta el sitio terminado, frente a cuatro o seis semanas en un setup a medida.

Un segundo escenario son los portales de intranet. Una empresa opera una intranet TYPO3 para 2.000 personas. El diseño no tiene por qué ser único, pero sí coherente y responsive. ws_t3bootstrap aporta un layout estándar profesional que puede utilizarse sin gran esfuerzo de diseño. Elementos de contenido como acordeones para FAQs, pestañas para información departamental y cards para teasers de noticias están disponibles de inmediato.

Tercer escenario: prototipado rápido. Una agencia construye en dos días un prototipo de sitio funcional que el cliente puede aprobar. ws_t3bootstrap reduce el tiempo de setup a horas en lugar de días, porque la estructura base (cabecera, pie, navegación, grid) ya está lista.

## La arquitectura técnica registra los componentes Bootstrap como Content Elements de TYPO3

ws_t3bootstrap se instala como sitepackage de TYPO3 y configura: setup TypoScript con includes de CSS/JS de Bootstrap, plantillas Fluid para cabecera, pie y layouts de página, backend layouts (1 columna, 2 columnas, 3 columnas con sidebar) y elementos de contenido que reflejan los componentes Bootstrap.

Los elementos de contenido se definen mediante configuraciones TCA y plantillas Fluid. Un elemento Accordion, por ejemplo, crea un acordeón Bootstrap con n paneles, cada uno con título y cuerpo. Un elemento Card genera una card Bootstrap con imagen, título, texto y enlace. Un elemento Grid permite layouts de columnas anidadas dentro de una página.

El CSS de Bootstrap se incluye bien como archivo CSS compilado (rápido, sin build tools) o bien como código Sass compilado por un sistema de build (Webpack, Vite). La variante Sass permite sobrescribir las variables de Bootstrap (colores, breakpoints, tamaños de fuente) y cargar solo los módulos necesarios, reduciendo el tamaño del CSS de 230 KB a entre 80 y 120 KB.

Los componentes JavaScript (Accordion, Collapse, Dropdown, Modal, Tab, Toast) se incluyen vía Bootstrap 5, que funciona sin jQuery. Esto reduce el tamaño del archivo JavaScript respecto a Bootstrap 4 en unos 85 KB (por la desaparición de jQuery).

## Los problemas habituales afectan a conflictos de versiones de Bootstrap y a luchas de especificidad en CSS

El mayor problema con los sitepackages Bootstrap es el conflicto de versiones. Si ws_t3bootstrap incluye Bootstrap 5.2 pero otra extensión (por ejemplo, un plugin de slider) trae Bootstrap 4.6 o 3.x, las clases CSS colisionan. Bootstrap 4 usa "col-md-4" y Bootstrap 5 también, pero con comportamientos distintos en ciertas utilidades. La solución: unificar todas las extensiones en la misma versión de Bootstrap o aislar el Bootstrap propio de la extensión mediante scoping de CSS.

Segundo problema: la especificidad del CSS. Si el CSS personalizado tiene que sobrescribir las clases de Bootstrap, se inicia una carrera de especificidad: las declaraciones !important se multiplican porque las utilidades de Bootstrap tienen una especificidad alta. La solución: usar variables de Bootstrap en lugar de overrides de CSS y cargar la hoja de estilos personalizada después del CSS de Bootstrap.

Tercer tema: rendimiento. Bootstrap como framework carga todos los componentes, aunque el sitio solo use cinco. En un sitio que solo necesita grid, cards y navbar, el 80 por ciento del CSS de Bootstrap no se utiliza nunca. PurgeCSS o un import selectivo de Sass reduce el tamaño del CSS a lo imprescindible.

## TYPO3 v12 y v13 están soportados, Bootstrap 5 es el estándar actual

ws_t3bootstrap se mantiene activamente y soporta TYPO3 v12 y v13. La versión actual se basa en Bootstrap 5.3. En el upgrade de Bootstrap 4 a 5 hay que tener en cuenta algunos breaking changes: desaparece la dependencia de jQuery, algunas clases CSS se han renombrado (por ejemplo ml-/mr- a ms-/me-) y la API JavaScript ha cambiado. Gosign realiza los upgrades de Bootstrap junto con los upgrades de TYPO3 y revisa todos los elementos de contenido para comprobar su correcta visualización. En nuevos proyectos recomendamos ws_t3bootstrap como punto de partida y completamos el sitepackage con componentes específicos del proyecto, en lugar de integrar Bootstrap desde cero en TYPO3.

--- wwt3_encryption TYPO3 - Protección de email | Gosign ---
> Extensión de TYPO3 para el cifrado automático de correo electrónico en el sitio web.

## Por qué la ofuscación de correo sigue siendo obligatoria en cualquier sitio público

Cualquier web corporativa, cualquier página universitaria y cualquier sede electrónica publica direcciones de correo: personas de contacto en el aviso legal, interlocutores en equipos, contactos de prensa en salas de prensa, asesoría jurídica en las notas de protección de datos. Sin protección, los bots harvester recolectan esas direcciones en pocos días tras su publicación y las venden a remitentes de spam. wwt3_encryption es una extensión clásica de TYPO3 para este problema y cifra las direcciones de correo en el servidor, de modo que los bots solo ven código inutilizable al parsear el HTML, mientras que los usuarios reales pueden hacer clic en la dirección correcta. La extensión se dirige a operadores que por obligación legal deben mostrar los datos de contacto de forma prominente, pero no están dispuestos a asumir la avalancha de spam resultante.

## Escenarios típicos de uso

Un despacho de abogados con 60 socios y asociados publica todos los perfiles de letrados incluyendo direcciones de correo directas, porque el Estatuto General de la Abogacía exige un dato de contacto accesible. Sin ofuscación, las 60 direcciones reciben en cuestión de semanas correos de phishing, publicidad y, en parte, ataques dirigidos. wwt3_encryption renderiza las direcciones de modo que el código fuente no contiene una cadena @ legible, mientras que el navegador del usuario muestra la dirección correcta del enlace mailto.

Un segundo escenario es una universidad que mantiene páginas de departamento con contactos de cátedras. Cada cátedra tiene una página web con datos de teléfono y correo que se mantienen editorialmente a través del gestor de contenido TYPO3. Los redactores introducen las direcciones como texto normal en elementos RichText o campos de contacto, sin tener que preocuparse por la ofuscación. wwt3_encryption interviene automáticamente en el proceso de renderizado y protege todos los enlaces mailto sin trabajo editorial adicional.

El tercer caso son administraciones públicas con aviso legal, formularios de contacto y listas de áreas funcionales. Aquí el requisito es a menudo aún más estricto, porque existe una exigencia de accesibilidad: la dirección protegida debe ser leída correctamente por lectores de pantalla, y un clic debe abrir el cliente de correo, igual que con una dirección no ofuscada. Una combinación de decodificación JavaScript y atributos href semánticamente limpios es el único camino para cumplir ambas cosas.

## Arquitectura técnica: content post-processing en el renderizado TYPO3

wwt3_encryption se engancha al proceso de renderizado de TYPO3, típicamente mediante un hook de content post-processor o un userFunc de TypoScript. Tras el ensamblado del HTML por el Page Renderer, la extensión recorre el markup terminado, encuentra todos los enlaces mailto y todas las direcciones de correo simples en el texto corrido mediante regex y las sustituye por variantes ofuscadas. La ofuscación puede funcionar con distintos métodos: codificación ROT13 del destino del enlace con decodificación JavaScript, codificación Base64, fragmentación carácter a carácter con pseudoelementos CSS o una combinación.

La ventaja de la variante post-processing es que funciona sin cambios en los elementos de contenido o las plantillas. Los redactores siguen trabajando con enlaces mailto normales en el RichText y la extensión se encarga del blindaje automáticamente. La extensión se configura mediante constantes TypoScript, que permiten elegir entre los distintos métodos de ofuscación y definir excepciones para determinadas páginas o áreas de contenido.

## Problemas frecuentes y soluciones

El primer problema es la accesibilidad. Las soluciones puramente JavaScript fallan con usuarios que tienen JavaScript desactivado, y algunos lectores de pantalla tienen problemas con la fragmentación de caracteres basada en CSS. Un enfoque pragmático combina una ofuscación ligera del lado del cliente con un aria-label semántico adicional en el enlace, de modo que los lectores de pantalla leen la dirección correctamente, mientras que los harvester fracasan ante la diferencia sintáctica. Con direcciones accesibles públicamente no se alcanza una seguridad absoluta, pero incluso barreras moderadas reducen medible la carga de spam.

El segundo problema son las capas de caché. Cuando la ofuscación por post-processing se ejecuta antes del Page Cache, el caché entrega los datos ya ofuscados y todo funciona. Si en cambio está después del caché, cada página cacheada se vuelve a pasar por el post-processor con cada petición, lo que reduce claramente el rendimiento. Por tanto el orden correcto en la cadena de renderizado TypoScript es crítico y debería revisarse en cada cambio importante en el comportamiento de caché.

El tercer tema afecta a los contenidos dinámicos. Las direcciones de correo que se cargan vía AJAX o que provienen de APIs externas no pasan por el renderer de TYPO3 y, por tanto, tampoco por wwt3_encryption. Esos puntos deben protegerse por separado, o bien haciendo que la propia API entregue variantes ofuscadas, o bien con un JavaScript del lado del cliente que post-procese el contenido recargado.

## Migración y compatibilidad de versiones

wwt3_encryption tiene, como muchas extensiones antiguas de TYPO3, una historia de versiones desigual: para v9 y v10 había releases mantenidos, para v11 y v12 existen forks comunitarios con actividad variable. Quien migra a TYPO3 v13 debería comprobar antes del upgrade si su fork sigue funcionando o si se hace necesario cambiar a un método alternativo de ofuscación.

El núcleo de TYPO3 trae de serie una ofuscación sencilla de correo que se activa mediante config.spamProtectEmailAddresses en TypoScript y aplica ROT13 en el renderer del núcleo. Para instalaciones sencillas basta esa variante del núcleo y hace innecesaria una extensión propia. Quien necesita una ofuscación más fuerte o más flexible, por ejemplo con varios métodos en paralelo o excepciones por elemento de contenido, recurre a una extensión como wwt3_encryption. Gosign evalúa en cada caso si la función del núcleo es suficiente o si una extensión dedicada tiene sentido, y apoya cuando hace falta la reconstrucción hacia una implementación post-processing propia y ligera que se adapta al proyecto concreto.

La eficacia de cualquier ofuscación de correo disminuye con el tiempo, porque las técnicas harvester evolucionan. ROT13 se considera hoy prácticamente ineficaz frente a bots especializados, mientras que la fragmentación carácter a carácter con CSS o trucos Unicode todavía levanta barreras moderadas. La defensa realmente sólida es por tanto una combinación: ofuscación en la salida HTML, complementada con un buen filtro de spam en el lado del destinatario e, idealmente, una opción de contacto mediante formulario en lugar de una dirección directamente publicada. Quien debe cumplir los requisitos legales no podrá evitar la publicación, pero debería ofrecer el formulario de contacto como vía principal y mostrar la dirección solo de forma secundaria.

Para operadores de TYPO3 v13 se recomienda además revisar periódicamente el pipeline de renderizado de contenido frente a Breaking Changes del núcleo. Algunos puntos de hook que estaban disponibles en versiones anteriores para post-processing han sido declarados deprecated en v13 o sustituidos por eventos PSR-14. Las extensiones que se apoyan todavía en hooks antiguos siguen funcionando técnicamente tras el upgrade, pero ya no procesan contenidos. Una breve revisión de los logs tras un upgrade muestra esos fallos silenciosos a tiempo y evita que durante semanas se entreguen direcciones sin ofuscar sin que nadie lo note.

--- Extensiones TYPO3 | Desarrollo y monitorización ---
> Más de 800 extensiones TYPO3 monitorizadas. Desarrollo, auditoría y monitorización de seguridad. Todas las extensiones de un vistazo.

<!-- ¿Qué ofrece Gosign? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">¿Qué ofrece Gosign para extensiones TYPO3?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Gosign monitoriza más de 800 extensiones TYPO3 en busca de vulnerabilidades de seguridad, compatibilidad y rendimiento. Para cada extensión, Gosign ofrece: desarrollo nuevo, actualización y migración, auditoría de código y mantenimiento. 25&nbsp;años en desarrollo TYPO3, desde 2023 con desarrollo acelerado por IA: 60-80&nbsp;% más rápido que los métodos tradicionales.
</p>
</div>
</section>

<!-- Categorías de extensiones -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">Categorías de extensiones</h2>
<div class="space-y-8">

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Búsqueda e indexación</h3>
<p class="text-body text-gosign-text mb-4">Apache Solr, ke_search, Faceted Search. Búsqueda Enterprise sobre miles de documentos y archivos.</p>
<div class="flex flex-wrap gap-2">
<a href="/es/typo3/solrfal/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">solrfal</a>
<a href="/es/typo3/ke_search_premium/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">ke_search_premium</a>
<a href="/es/typo3/find/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">find</a>
<a href="/es/typo3/in2studyfinder/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">in2studyfinder</a>
</div>
</div>

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Seguridad y autenticación</h3>
<p class="text-body text-gosign-text mb-4">SSO, SAML, OIDC, Cookie-Consent, CAPTCHA, CORS. Seguridad Enterprise para TYPO3.</p>
<div class="flex flex-wrap gap-2">
<a href="/es/typo3/shibboleth_auth/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">shibboleth_auth</a>
<a href="/es/typo3/oidc/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">oidc</a>
<a href="/es/typo3/dp_cookieconsent/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">dp_cookieconsent</a>
<a href="/es/typo3/saml2/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">saml2</a>
<a href="/es/typo3/be_acl/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">be_acl</a>
</div>
</div>

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Formularios y eventos</h3>
<p class="text-body text-gosign-text mb-4">Powermail, gestión de eventos, sistemas de reservas, encuestas, integración de newsletter.</p>
<div class="flex flex-wrap gap-2">
<a href="/es/typo3/powermail/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">powermail</a>
<a href="/es/typo3/sf_event_mgt/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">sf_event_mgt</a>
<a href="/es/typo3/booking/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">booking</a>
<a href="/es/typo3/rapidmail/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">rapidmail</a>
</div>
</div>

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Contenido y plantillas</h3>
<p class="text-body text-gosign-text mb-4">Mask, DCE, VHS ViewHelper, Bootstrap Grids. Elementos de contenido personalizados y desarrollo de plantillas.</p>
<div class="flex flex-wrap gap-2">
<a href="/es/typo3/mask/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">mask</a>
<a href="/es/typo3/dce/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">dce</a>
<a href="/es/typo3/vhs/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">vhs</a>
<a href="/es/typo3/bootstrap_grids/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">bootstrap_grids</a>
</div>
</div>

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">PDF y documentos</h3>
<p class="text-body text-gosign-text mb-4">Generación de PDF, visor PDF, flipbooks, gestión de descargas.</p>
<div class="flex flex-wrap gap-2">
<a href="/es/typo3/pdfviewhelpers/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">pdfviewhelpers</a>
<a href="/es/typo3/web2pdf/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">web2pdf</a>
<a href="/es/typo3/rflipbook/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">rflipbook</a>
<a href="/es/typo3/downloadmanager/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">downloadmanager</a>
</div>
</div>

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Medios e imágenes</h3>
<p class="text-body text-gosign-text mb-4">Edición de imágenes, galerías, sliders, focuspoint, Cloudinary CDN.</p>
<div class="flex flex-wrap gap-2">
<a href="/es/typo3/focuspoint/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">focuspoint</a>
<a href="/es/typo3/imagemap/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">imagemap</a>
<a href="/es/typo3/sf_filecollection_gallery/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">sf_filecollection_gallery</a>
</div>
</div>

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Mapas y ubicaciones</h3>
<p class="text-body text-gosign-text mb-4">Leaflet, Google Maps, OpenStreetMap. Buscador de sucursales y búsqueda por radio.</p>
<div class="flex flex-wrap gap-2">
<a href="/es/typo3/leaflet/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">leaflet</a>
<a href="/es/typo3/maps2/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">maps2</a>
<a href="/es/typo3/geocoordinates/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">geocoordinates</a>
</div>
</div>

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">E-commerce</h3>
<p class="text-body text-gosign-text mb-4">aimeos, integración de pagos, paywall, calculadora de precios.</p>
<div class="flex flex-wrap gap-2">
<a href="/es/typo3/aimeos/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">aimeos</a>
<a href="/es/typo3/amazon_payment/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">amazon_payment</a>
<a href="/es/typo3/paywall/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">paywall</a>
</div>
</div>

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Rendimiento y SEO</h3>
<p class="text-body text-gosign-text mb-4">Cache Warmup, staticfilecache, conversión WebP, gestión de canonicals.</p>
<div class="flex flex-wrap gap-2">
<a href="/es/typo3/warmup/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">warmup</a>
<a href="/es/typo3/webp/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">webp</a>
<a href="/es/typo3/newscanonical/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">newscanonical</a>
<a href="/es/typo3/cache_hash/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">cache_hash</a>
</div>
</div>

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">DevTools y despliegue</h3>
<p class="text-body text-gosign-text mb-4">Extension Builder, in2publish, Styleguide, Deployer.</p>
<div class="flex flex-wrap gap-2">
<a href="/es/typo3/extension_builder/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">extension_builder</a>
<a href="/es/typo3/in2publish/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">in2publish</a>
<a href="/es/typo3/styleguide/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">styleguide</a>
</div>
</div>

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Soluciones sectoriales</h3>
<p class="text-body text-gosign-text mb-4">Inmobiliaria (OpenImmo, FlowFact), universidades (in2studyfinder), asociaciones (hwvereinsliste), educación (kuferweb).</p>
<div class="flex flex-wrap gap-2">
<a href="/es/typo3/openimmo/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">openimmo</a>
<a href="/es/typo3/flowfact/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">flowfact</a>
<a href="/es/typo3/kuferweb/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">kuferweb</a>
</div>
</div>

</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">¿Busca soporte para una extensión TYPO3?</h3>
<p class="text-body text-gosign-text mb-6">30&nbsp;minutos de consulta inicial, gratuita y sin compromiso.</p>
<a
href="/es/contacto/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Reservar asesoría de extensiones
</a>
<p class="text-small text-gosign-text-light mt-4">25 años de experiencia · 800+ extensiones · Desarrollo acelerado por IA</p>
</div>
</section>

<!-- KI Table -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Desarrollo de extensiones acelerado por IA</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
Gosign utiliza desarrollo asistido por IA desde 2023. Esto significa en concreto:
</p>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Tarea</th>
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Clásico</th>
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Con IA</th>
<th class="py-3 text-small font-bold text-gosign-dark">Ahorro</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Nueva extensión (Extbase)</td>
<td class="py-3 pr-4 text-body text-gosign-text">2-4 semanas</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">4-8 días</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">70&nbsp;%</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Actualización de extensión (v9 &rarr; v12)</td>
<td class="py-3 pr-4 text-body text-gosign-text">1-2 semanas</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">2-4 días</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">65&nbsp;%</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Auditoría de seguridad</td>
<td class="py-3 pr-4 text-body text-gosign-text">3-5 días</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">1 día</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">75&nbsp;%</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Revisión de código + refactorización</td>
<td class="py-3 pr-4 text-body text-gosign-text">1 semana</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">2 días</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">60&nbsp;%</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- TYPO3 Update -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Actualización de TYPO3 a la versión actual</h2>
<p class="text-body text-gosign-text leading-relaxed mb-8">
Actualizamos su instalación TYPO3 a la versión LTS actual a un coste competitivo - incluyendo todas las extensiones, incluso obsoletas y sin mantenimiento.
</p>
<div class="grid md:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<div class="flex items-start gap-4">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-1" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75M21 12a9 9 0 1 1-18 0 9 9 0 0 1 18 0Z" /></svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Todas las extensiones migradas</h3>
<p class="text-body text-gosign-text">Incluyendo obsoletas, sin mantenimiento o de desarrollo propio.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-6">
<div class="flex items-start gap-4">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-1" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 18.75a60.07 60.07 0 0 1 15.797 2.101c.727.198 1.453-.342 1.453-1.096V18.75M3.75 4.5v.75A.75.75 0 0 1 3 6h-.75m0 0v-.375c0-.621.504-1.125 1.125-1.125H20.25M2.25 6v9m18-10.5v.75c0 .414.336.75.75.75h.75m-1.5-1.5h.375c.621 0 1.125.504 1.125 1.125v9.75c0 .621-.504 1.125-1.125 1.125h-.375m1.5-1.5H21a.75.75 0 0 0-.75.75v.75m0 0H3.75m0 0h-.375a1.125 1.125 0 0 1-1.125-1.125V15m1.5 1.5v-.75A.75.75 0 0 0 3 15h-.75M15 10.5a3 3 0 1 1-6 0 3 3 0 0 1 6 0Zm3 0h.008v.008H18V10.5Zm-12 0h.008v.008H6V10.5Z" /></svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Precio fijo</h3>
<p class="text-body text-gosign-text">Costes transparentes, sin trabajos adicionales ocultos.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-6">
<div class="flex items-start gap-4">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-1" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M3.75 13.5l10.5-11.25L12 10.5h8.25L9.75 21.75 12 13.5H3.75Z" /></svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Acelerado por IA</h3>
<p class="text-body text-gosign-text">30-50 % más económico que el mercado gracias al análisis de código con IA.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-6">
<div class="flex items-start gap-4">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-1" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M20.25 6.375c0 2.278-3.694 4.125-8.25 4.125S3.75 8.653 3.75 6.375m16.5 0c0-2.278-3.694-4.125-8.25-4.125S3.75 4.097 3.75 6.375m16.5 0v11.25c0 2.278-3.694 4.125-8.25 4.125s-8.25-1.847-8.25-4.125V6.375m16.5 0v3.75m-16.5-3.75v3.75m16.5 0v3.75C20.25 16.153 16.556 18 12 18s-8.25-1.847-8.25-4.125v-3.75m16.5 0c0 2.278-3.694 4.125-8.25 4.125s-8.25-1.847-8.25-4.125" /></svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Cero pérdida de datos</h3>
<p class="text-body text-gosign-text">Migración completa de datos con protección de rollback.</p>
</div>
</div>
</div>
</div>
<div class="mt-8 text-center">
<a
href="/es/contacto/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Solicitar actualización TYPO3
</a>
</div>
</div>
</section>

<!-- RGPD Audit -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Auditoría RGPD de TYPO3 &amp; Cumplimiento</h2>
<p class="text-body text-gosign-text leading-relaxed mb-8">
Auditamos su instalación TYPO3 en cuanto al cumplimiento del RGPD e implementamos todas las medidas a un coste competitivo.
</p>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse bg-white rounded-card">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Área de auditoría</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Qué se comprueba</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Resultado</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Cookie-Consent</td>
<td class="py-3 px-4 text-body text-gosign-text">Banner, opt-in/opt-out, registro de consentimiento</td>
<td class="py-3 px-4 text-body text-gosign-text">Flujo de consentimiento conforme a la ley</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Rastreo y analítica</td>
<td class="py-3 px-4 text-body text-gosign-text">Google Analytics, Matomo, Tag Manager, píxeles de terceros</td>
<td class="py-3 px-4 text-body text-gosign-text">Configuración conforme a protección de datos</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Extensiones</td>
<td class="py-3 px-4 text-body text-gosign-text">Transferencia de datos a terceros, peticiones externas, integraciones CDN</td>
<td class="py-3 px-4 text-body text-gosign-text">Corrección o alternativas conformes al RGPD</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Formularios</td>
<td class="py-3 px-4 text-body text-gosign-text">Registro de tratamiento, consentimientos, plazos de conservación</td>
<td class="py-3 px-4 text-body text-gosign-text">Documentación completa</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Hosting y SSL</td>
<td class="py-3 px-4 text-body text-gosign-text">Ubicación del servidor, tratamiento de datos, cifrado</td>
<td class="py-3 px-4 text-body text-gosign-text">Hosting conforme a la UE</td>
</tr>
</tbody>
</table>
</div>
<div class="mt-8 text-center">
<a
href="/es/contacto/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Solicitar auditoría RGPD
</a>
</div>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
Gosign es una agencia digital con sede en Hamburgo y 25 años de experiencia en desarrollo web, TYPO3 e integración de IA.
Hemos analizado más de 800 extensiones TYPO3 y hoy desarrollamos con apoyo de IA
hasta un 70&nbsp;% más rápido que con métodos tradicionales. Nuestros clientes son empresas
medianas, universidades e instituciones europeas.
</p>
<p class="text-small text-gosign-text-light mt-2">Actualizado: febrero 2026</p>
</div>
</section>

<!-- Temas relacionados -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Temas relacionados</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/es/typo3-monitor-seguridad/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Monitorización</p>
<p class="text-body font-semibold text-gosign-dark">Monitor de seguridad TYPO3</p>
</a>
<a href="/es/agencia-digital-hamburg/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Desarrollo web</p>
<p class="text-body font-semibold text-gosign-dark">Agencia digital en Hamburgo</p>
</a>
<a href="/es/seguridad-web-estandares/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Seguridad</p>
<p class="text-body font-semibold text-gosign-dark">Seguridad web según estándares europeos</p>
</a>
</div>
</div>
</section>

--- Monitor de seguridad TYPO3 ---
> Monitor de seguridad TYPO3: monitorizar más de 800 extensiones, detectar vulnerabilidades. Análisis gratuito disponible.

<!-- ¿Qué es el monitor? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">¿Qué es el monitor de seguridad TYPO3?</h2>
<p class="text-body text-gosign-text leading-relaxed">
El monitor de seguridad TYPO3 de Gosign vigila automáticamente más de 800 extensiones TYPO3 en busca de vulnerabilidades, versiones desactualizadas y problemas conocidos. Cuando una extensión recibe un aviso de seguridad, los clientes de Gosign lo saben de inmediato, no en la siguiente revisión manual. El monitor es una herramienta propia de Gosign que evalúa continuamente los boletines de seguridad de TYPO3, los changelogs de extensiones y las bases de datos CVE.
</p>
</div>
</section>

<!-- ¿Por qué monitorización de seguridad? -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">¿Por qué necesitan los operadores TYPO3 monitorización de seguridad?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Las instalaciones TYPO3 utilizan de media 30-50 extensiones. Cada una es un punto de entrada potencial. El equipo de seguridad de TYPO3 publica avisos regularmente, pero ¿quién los lee todos? El monitor de Gosign hace exactamente eso. De forma automática y en tiempo real.
</p>
</div>
</section>

<!-- Tabla del monitor -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Qué monitoriza el monitor</h2>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Área de análisis</th>
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Qué se analiza</th>
<th class="py-3 text-small font-bold text-gosign-dark">Frecuencia</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Versiones de extensiones</td>
<td class="py-3 pr-4 text-body text-gosign-text">Versión instalada vs. versión actual</td>
<td class="py-3 text-body text-gosign-text">Diario</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Avisos de seguridad</td>
<td class="py-3 pr-4 text-body text-gosign-text">Boletines de seguridad TYPO3, bases de datos CVE</td>
<td class="py-3 text-body text-gosign-accent-text font-semibold">Tiempo real</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Fin de vida</td>
<td class="py-3 pr-4 text-body text-gosign-text">Extensiones sin mantenedor o actualizaciones</td>
<td class="py-3 text-body text-gosign-text">Semanal</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">TYPO3 Core</td>
<td class="py-3 pr-4 text-body text-gosign-text">Versión del Core vs. Stable/LTS actual</td>
<td class="py-3 text-body text-gosign-text">Diario</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Versión PHP</td>
<td class="py-3 pr-4 text-body text-gosign-text">Compatibilidad y estado de seguridad</td>
<td class="py-3 text-body text-gosign-text">Semanal</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Servicios -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">Servicios de seguridad TYPO3</h2>
<div class="grid md:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Monitorización de seguridad</h3>
<p class="text-body text-gosign-text">
Vigilancia continua de todas las extensiones y del Core TYPO3. Notificación inmediata ante vulnerabilidades críticas.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Auditoría de seguridad</h3>
<p class="text-body text-gosign-text">
Revisión profunda puntual: inventario de extensiones, estado de versiones, vulnerabilidades conocidas, calidad de código. Análisis asistido por IA en horas en lugar de días.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Respuesta a incidentes</h3>
<p class="text-body text-gosign-text">
¿Sitio web hackeado? Gosign analiza el vector de ataque, limpia la instalación y cierra la brecha. Soporte de emergencia disponible.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Mantenimiento y parcheado</h3>
<p class="text-body text-gosign-text">
Actualizaciones de seguridad periódicas, actualizaciones de extensiones, gestión de versión PHP. De forma proactiva, no reactiva.
</p>
</div>
</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Solicitar análisis de seguridad TYPO3: 30&nbsp;minutos, gratis.</h3>
<p class="text-body text-gosign-text mb-6">Analizamos su instalación TYPO3 en busca de vulnerabilidades conocidas, sin compromiso.</p>
<a
href="/es/contacto/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Reservar cita
</a>
<p class="text-small text-gosign-text-light mt-4">25 años de experiencia · 800+ extensiones · Desarrollo acelerado por IA</p>
</div>
</section>

<!-- Tabla IA -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Análisis de seguridad acelerado por IA: 75&nbsp;% más rápido</h2>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Tarea</th>
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Clásico</th>
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Con IA</th>
<th class="py-3 text-small font-bold text-gosign-dark">Ahorro</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Inventario de extensiones + comparación de versiones</td>
<td class="py-3 pr-4 text-body text-gosign-text">1 día</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">30 minutos</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">90&nbsp;%</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Análisis de vulnerabilidades (50 extensiones)</td>
<td class="py-3 pr-4 text-body text-gosign-text">2 días</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">4 horas</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">75&nbsp;%</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Auditoría de código de una extensión</td>
<td class="py-3 pr-4 text-body text-gosign-text">1 semana</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">2 días</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">60&nbsp;%</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Análisis de incidente tras hackeo</td>
<td class="py-3 pr-4 text-body text-gosign-text">2 días</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">6 horas</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">65&nbsp;%</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Actualización TYPO3 -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Actualización de TYPO3 a la versión actual</h2>
<p class="text-body text-gosign-text leading-relaxed mb-8">
Actualizamos su instalación TYPO3 a la versión LTS actual a un coste competitivo - incluyendo todas las extensiones, incluso obsoletas y sin mantenimiento.
</p>
<div class="grid md:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<div class="flex items-start gap-4">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-1" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75M21 12a9 9 0 1 1-18 0 9 9 0 0 1 18 0Z" /></svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Todas las extensiones migradas</h3>
<p class="text-body text-gosign-text">Incluyendo obsoletas, sin mantenimiento o de desarrollo propio.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-6">
<div class="flex items-start gap-4">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-1" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 18.75a60.07 60.07 0 0 1 15.797 2.101c.727.198 1.453-.342 1.453-1.096V18.75M3.75 4.5v.75A.75.75 0 0 1 3 6h-.75m0 0v-.375c0-.621.504-1.125 1.125-1.125H20.25M2.25 6v9m18-10.5v.75c0 .414.336.75.75.75h.75m-1.5-1.5h.375c.621 0 1.125.504 1.125 1.125v9.75c0 .621-.504 1.125-1.125 1.125h-.375m1.5-1.5H21a.75.75 0 0 0-.75.75v.75m0 0H3.75m0 0h-.375a1.125 1.125 0 0 1-1.125-1.125V15m1.5 1.5v-.75A.75.75 0 0 0 3 15h-.75M15 10.5a3 3 0 1 1-6 0 3 3 0 0 1 6 0Zm3 0h.008v.008H18V10.5Zm-12 0h.008v.008H6V10.5Z" /></svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Precio fijo</h3>
<p class="text-body text-gosign-text">Costes transparentes, sin trabajos adicionales ocultos.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-6">
<div class="flex items-start gap-4">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-1" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M3.75 13.5l10.5-11.25L12 10.5h8.25L9.75 21.75 12 13.5H3.75Z" /></svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Acelerado por IA</h3>
<p class="text-body text-gosign-text">30-50 % más económico que el mercado gracias al análisis de código con IA.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-6">
<div class="flex items-start gap-4">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-1" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M20.25 6.375c0 2.278-3.694 4.125-8.25 4.125S3.75 8.653 3.75 6.375m16.5 0c0-2.278-3.694-4.125-8.25-4.125S3.75 4.097 3.75 6.375m16.5 0v11.25c0 2.278-3.694 4.125-8.25 4.125s-8.25-1.847-8.25-4.125V6.375m16.5 0v3.75m-16.5-3.75v3.75m16.5 0v3.75C20.25 16.153 16.556 18 12 18s-8.25-1.847-8.25-4.125v-3.75m16.5 0c0 2.278-3.694 4.125-8.25 4.125s-8.25-1.847-8.25-4.125" /></svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Cero pérdida de datos</h3>
<p class="text-body text-gosign-text">Migración completa de datos con protección de rollback.</p>
</div>
</div>
</div>
</div>
<div class="mt-8 text-center">
<a
href="/es/contacto/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Solicitar actualización TYPO3
</a>
</div>
</div>
</section>

<!-- Auditoría RGPD -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Auditoría RGPD de TYPO3 &amp; Cumplimiento</h2>
<p class="text-body text-gosign-text leading-relaxed mb-8">
Auditamos su instalación TYPO3 en cuanto al cumplimiento del RGPD e implementamos todas las medidas a un coste competitivo.
</p>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse bg-white rounded-card">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Área de auditoría</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Qué se comprueba</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Resultado</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Cookie-Consent</td>
<td class="py-3 px-4 text-body text-gosign-text">Banner, opt-in/opt-out, registro de consentimiento</td>
<td class="py-3 px-4 text-body text-gosign-text">Flujo de consentimiento conforme a la ley</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Rastreo y analítica</td>
<td class="py-3 px-4 text-body text-gosign-text">Google Analytics, Matomo, Tag Manager, píxeles de terceros</td>
<td class="py-3 px-4 text-body text-gosign-text">Configuración conforme a protección de datos</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Extensiones</td>
<td class="py-3 px-4 text-body text-gosign-text">Transferencia de datos a terceros, peticiones externas, integraciones CDN</td>
<td class="py-3 px-4 text-body text-gosign-text">Corrección o alternativas conformes al RGPD</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Formularios</td>
<td class="py-3 px-4 text-body text-gosign-text">Registro de tratamiento, consentimientos, plazos de conservación</td>
<td class="py-3 px-4 text-body text-gosign-text">Documentación completa</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Hosting y SSL</td>
<td class="py-3 px-4 text-body text-gosign-text">Ubicación del servidor, tratamiento de datos, cifrado</td>
<td class="py-3 px-4 text-body text-gosign-text">Hosting conforme a la UE</td>
</tr>
</tbody>
</table>
</div>
<div class="mt-8 text-center">
<a
href="/es/contacto/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Solicitar auditoría RGPD
</a>
</div>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
Gosign es una agencia digital con sede en Hamburgo y 25 años de experiencia en desarrollo web, TYPO3 e integración de IA.
Hemos analizado más de 800 extensiones TYPO3 y hoy desarrollamos con apoyo de IA
hasta un 70&nbsp;% más rápido que con métodos tradicionales. Nuestros clientes son empresas
medianas, universidades e instituciones europeas.
</p>
<p class="text-small text-gosign-text-light mt-2">Actualizado: febrero 2026</p>
</div>
</section>

<!-- Temas relacionados -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Temas relacionados</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/es/typo3-extensions/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">CMS</p>
<p class="text-body font-semibold text-gosign-dark">Extensiones TYPO3</p>
</a>
<a href="/es/sitio-web-hackeado-10-razones/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Seguridad</p>
<p class="text-body font-semibold text-gosign-dark">Sitio web hackeado: 10 razones</p>
</a>
<a href="/es/seguridad-web-estandares/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Seguridad</p>
<p class="text-body font-semibold text-gosign-dark">Seguridad web según estándares europeos</p>
</a>
</div>
</div>
</section>

--- Crear sitio web con IA | Whitepaper ---
> Whitepaper: del diseño web a un tema WordPress funcional con IA. Guía práctica de Gosign.

<!-- ¿Qué trata este whitepaper? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">¿Qué trata este whitepaper?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Este whitepaper de Gosign muestra el flujo de trabajo completo para crear un sitio web con apoyo de IA: desde la concepción hasta el diseño y el tema WordPress funcional. No es un resumen teórico, sino una guía práctica con herramientas concretas, prompts y resultados de proyectos reales de clientes.
</p>
</div>
</section>

<!-- Contenido -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">Contenido del whitepaper</h2>

<div class="space-y-8">
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">1. IA en el proceso de diseño web</h3>
<p class="text-body text-gosign-text leading-relaxed">
Generación de layouts, creación de moodboards, de wireframe a diseño con herramientas de IA. Qué funciona, qué no, dónde el criterio humano de diseño sigue siendo imprescindible.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">2. Del diseño al código</h3>
<p class="text-body text-gosign-text leading-relaxed">
Conversión asistida por IA de diseños Figma/Sketch a HTML/CSS/PHP. Cómo Gosign genera estructuras base de temas con IA y desarrolladores senior refinan el resultado.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">3. Desarrollo de temas WordPress con IA</h3>
<p class="text-body text-gosign-text leading-relaxed">
Bloques Gutenberg personalizados, plantillas Full Site Editing, lógica functions.php - lo que la IA genera en minutos y antes requería días. Comparación concreta antes y después.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">4. Control de calidad</h3>
<p class="text-body text-gosign-text leading-relaxed">
La IA genera código, pero ¿quién verifica la calidad? El proceso QA de Gosign: tests automatizados, controles de accesibilidad, auditorías de rendimiento, revisión manual de código.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">5. Resultados de la práctica</h3>
<p class="text-body text-gosign-text leading-relaxed">
Datos de ahorro de tiempo de proyectos reales de Gosign: 60-80&nbsp;% más rápido. Dónde exactamente se ahorra tiempo y dónde no.
</p>
</div>
</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">¿Quiere usar IA en su próximo proyecto web?</h3>
<p class="text-body text-gosign-text mb-6">30 minutos de consulta inicial, gratuita y sin compromiso.</p>
<a
href="/es/contacto/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Reservar consulta
</a>
<p class="text-small text-gosign-text-light mt-4">25 años de experiencia · 800+ extensiones · Desarrollo acelerado por IA</p>
</div>
</section>

<!-- ¿Para quién? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">¿Para quién es este whitepaper?</h2>
<ul class="space-y-3">
<li class="flex items-start gap-3">
<span class="flex-shrink-0 mt-1.5 w-2 h-2 bg-gosign-accent rounded-full"></span>
<span class="text-body text-gosign-text">Directores de proyecto y Product Owners que quieren ejecutar proyectos web más rápido y con menor coste</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 mt-1.5 w-2 h-2 bg-gosign-accent rounded-full"></span>
<span class="text-body text-gosign-text">Responsables de marketing que evalúan la creación de sitios web asistida por IA</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 mt-1.5 w-2 h-2 bg-gosign-accent rounded-full"></span>
<span class="text-body text-gosign-text">Desarrolladores que quieren integrar IA en su flujo de trabajo</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 mt-1.5 w-2 h-2 bg-gosign-accent rounded-full"></span>
<span class="text-body text-gosign-text">Directores generales que quieren entender el ROI de la inversión en IA para desarrollo web</span>
</li>
</ul>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
Gosign es una agencia digital con sede en Hamburgo y 25 años de experiencia en desarrollo web, TYPO3 e integración de IA.
Hemos analizado más de 800 extensiones TYPO3 y hoy desarrollamos con apoyo de IA
hasta un 70&nbsp;% más rápido que con métodos tradicionales. Nuestros clientes son empresas
medianas, universidades e instituciones europeas.
</p>
<p class="text-small text-gosign-text-light mt-2">Actualizado: febrero 2026</p>
</div>
</section>

<!-- Temas relacionados -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Temas relacionados</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/es/agencia-digital-hamburg/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Desarrollo web</p>
<p class="text-body font-semibold text-gosign-dark">Agencia digital en Hamburgo</p>
</a>
<a href="/es/agencia-wordpress/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Desarrollo web</p>
<p class="text-body font-semibold text-gosign-dark">Agencia WordPress Hamburgo</p>
</a>
<a href="/es/seguridad-web-estandares/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Seguridad</p>
<p class="text-body font-semibold text-gosign-dark">Seguridad web según estándares europeos</p>
</a>
</div>
</div>
</section>


============================================================
LANGUAGE: PL
============================================================

--- Agenci AI dla Firm w Amsterdamie | Gosign ---
> Enterprise AI Agents dla Amsterdamu i Holandii. RODO-konform, EU AI Act ready, Dutch AI Coalition. Audytowalne AI dla europejskiego hubu technologicznego.

## Amsterdam to jedyny rynek, w którym skalowanie Tech i nadzór bankowy dzielą ten sam kod pocztowy

Niewiele europejskich miast łączy hyperscale-Tech z systemowo istotną bankowością tak gęsto jak Amsterdam. ING, ABN AMRO i Rabobank prowadzą tu swoje centrale grupowe, podczas gdy Adyen, Booking.com, TomTom i Prosus uczyniły z miasta drugi co do wielkości rynek kapitałowy Tech po Londynie. W obszarze podmiejskim znajdują się Philips w Eindhoven i ASML w Veldhoven - region Brainport uzupełnia centrum finansowe Amsterdamu o kompetencje przemysłowe High-Tech. Heineken, Shell NL i KLM tworzą tradycyjny rdzeń przemysłowy, a startupy jak Bunq i Mollie kształtują obraz Fintech. Kto tu wdraża AI, buduje dla audytorium, które rozumie zarówno ścieżki reklamacyjne PSD2, jak i ISO/IEC 42001. Dokładnie ta mieszanka czyni z Amsterdamu jeden z najtrudniejszych testów akceptacyjnych dla Enterprise AI w Europie.

## Trzy wyzwania regulacyjne dla AI na rynku amsterdamskim

Po pierwsze Autoriteit Persoonsgegevens (AP) - holenderski organ ochrony danych należy do najbardziej zdecydowanych w egzekwowaniu w UE i uczynił audyty algorytmów standardem. AP regularnie publikuje wytyczne dotyczące obsługi systemów AI w ramach RODO i od 2023 prowadzi własny dział nadzoru "Algoritmes". Kto tu wchodzi na produkcję, musi umieć wyjaśnić każdą zautomatyzowaną decyzję osobie, której ona dotyczy. Dla polskich firm operujących w Holandii oznacza to, że sama zgodność z RODO i UODO w Warszawie nie wystarczy - AP wymaga własnych ścieżek komunikacji i dokumentacji w języku niderlandzkim lub angielskim.

Po drugie De Nederlandsche Bank (DNB) i Autoriteit Financiële Markten (AFM). Oba organy wspólnym dokumentem dyskusyjnym "General principles for the use of Artificial Intelligence in the financial sector" (zasady SAFEST) wyznaczyły standard dla banków, ubezpieczycieli i funduszy emerytalnych. Soundness, Accountability, Fairness, Ethics, Skills i Transparency to niepodważalne wymagania - każda decyzja AI musi spełniać te sześć kryteriów. Polskie banki z ekspozycją holenderską (np. ING Hubs Kraków jako dostawca dla ING NL) muszą się do nich dostosować już po stronie dostawcy.

Po trzecie krajowa interpretacja EU AI Act w przygotowaniu. Holandia pracuje nad własną logiką wdrożeniową, która łączy kategorie wysokiego ryzyka z EU AI Act z istniejącymi reżimami DNB i AP. Konkretnie oznacza to: system AI, który w EU AI Act uznawany jest za "high-risk", w Amsterdamie dodatkowo podlega logice DNB/AFM-SAFEST. [Zgodność z EU AI Act](/pl/governance/eu-ai-act/) musi tu działać podwójnie.

## Typowe scenariusze wdrożeń w Amsterdamie

ING i ABN AMRO wykorzystują Transaction Monitoring do wykrywania prania pieniędzy - modele muszą pozostać wyjaśnialne wobec audytorów DNB, a każdy pojedynczy alarm musi być reprodukowalny. Adyen procesuje na świecie miliardy płatności i potrzebuje modeli fraud detection, które decydują w sekundach, ale wobec AFM dostarczają kompletny Audit Trail dla każdej zablokowanej transakcji. Booking.com operuje algorytmami dynamic pricing bezpośrednio na styku Art. 5 EU AI Act (zakaz praktyk manipulacyjnych) i holenderskiego urzędu konkurencji ACM. ASML z kolei dokumentuje w Veldhoven portfolia patentowe i spory o własność intelektualną, w których każda wspomagana AI kwerenda musi być nienaruszalnie udokumentowana.

We wszystkich czterech scenariuszach nie chodzi o pytanie "czy model działa" - lecz "czy potrafimy obronić ten model przed organem nadzoru". Dokładnie po to istnieje [Decision Layer](/pl/decision-layer/): architektura, która persystuje każdą decyzję jako trace, wymusza eskalowalne ścieżki Human-in-the-Loop i dostarcza Audit Trail bezpośrednio na poziomie SQL.

Dochodzi do tego ondernemingsraad - holenderska rada zakładowa ma zgodnie z Wet op de ondernemingsraden (WOR) istotne prawa współdecydowania przy wprowadzaniu systemów AI. W odróżnieniu od polskiej Rady Zakładowej, która ma tylko prawa konsultacyjne, holenderski OR może faktycznie zablokować wdrożenie. Budujemy architekturę Decision Layer tak, aby obowiązki konsultacyjne wobec OR nie były dodawane ex post, lecz funkcjonowały jako integralny element Governance.

## Jak Gosign obsługuje Amsterdam z Hamburga

Hamburg jest nieco ponad cztery godziny pociągiem lub godzinę lotu od Schiphol. Pracujemy remote-first z zespołami w Amsterdamie, Eindhoven i Rotterdamie - standupy w czasie CET, asynchroniczne review przez Linear, comiesięczne warsztaty on-site w pierwszych trzech miesiącach projektu. Holenderska kultura compliance jest wystarczająco niemiecko-pragmatyczna, że współpraca działa bez dużych strat tłumaczeniowych. Warsztaty discovery odbywają się po angielsku, dokumentację techniczną dostarczamy po angielsku i niderlandzku (weryfikowaną przez native reviewerów), wewnętrzne steering z architektami w Hamburgu prowadzimy po niemiecku. Polskojęzyczne wsparcie dla polskich filii klientów (jak ING Hubs Kraków) zapewnia nasze biuro w Krakowie.

Nie mamy oddziału w Amsterdamie. To uczciwa odpowiedź: dla większości projektów nie jest on potrzebny. Potrzebny jest ktoś, kto jednocześnie ma w głowie zasady DNB-SAFEST i EU AI Act - oraz kto w ciągu 24 godzin znajdzie się na miejscu przy audycie AP. Obie kompetencje dostarczamy z Hamburga. Konkretnie: architekci i compliance leads w zespole w Hamburgu, budżet na kwartalne wizyty on-site, SLA eskalacji 24 godziny dla zapytań organów. Więcej o naszym podejściu na stronie [usługi AI Agents](/pl/uslugi/ai-agents/).

## Dlaczego Amsterdam to dobry punkt startowy dla Enterprise AI

Amsterdam zmusza do myślenia o AI od początku jako o regulowanej infrastrukturze - nie eksperymencie innowacyjnym. Kto buduje tu pilotaż z Cert-Ready by Design, ma potem referencję, która w każdym innym rynku UE od razu jest do obrony. Klastry Amsterdam Smart City, AMS Cluster i ekosystem Brainport w Eindhoven dostarczają talent, badania i partnerów pilotażowych. Jednocześnie kanały dystrybucji są jasne: kto zadowoli DNB, AFM i AP, ma argumenty compliance, które działają we Frankfurcie, Paryżu czy Madrycie - najczęściej z mniejszym narzutem niż wariant amsterdamski.

Wdrażaliśmy Decision Layer z Governance by Design dla banków, dostawców płatności i travel-tech w Europie Zachodniej. W Amsterdamie poprzeczka jest na tyle wysoka, że każdy agent AI, który tu trafia na produkcję, automatycznie da się eksportować do reszty Europy. A dla polskich firm z holenderskimi spółkami zależnymi czy GCC obsługującymi ING NL, Amsterdam jest rynkiem, na którym strategia AI musi się najpierw udowodnić - zanim przeskaluje się do Krakowa, Warszawy czy Wrocławia.

--- Agenci AI dla Firm w Barcelonie | Gosign ---
> Enterprise AI Agents w Barcelonie. Lokalne zarządzanie projektami, EU AI Act compliant by design, RODO + LOPDGDD. Od PoC do samodzielnej operacji.

## Barcelona to stolica Tech Hiszpanii - ale hiszpański nadzór AI rozstrzyga w La Coruñi

Kto buduje Enterprise AI w Barcelonie, pracuje w jednym z najgęstszych korytarzy innowacyjnych Europy Południowej, a jednocześnie na rynku, gdzie decyzje regulacyjne zapadają 1100 kilometrów dalej na północ. W dzielnicy 22@Barcelona skupiają się CaixaBank, Cellnex Telecom, Mango, Desigual, Damm oraz farmaceutyczny gigant Grifols z działalnością plazmową. W obszarze podmiejskim Seat w Martorell produkuje modele Cupra, w portowych terminalach działa logistyka Naturgy, a Banco Sabadell obsługuje klientów średniej wielkości w całej Katalonii. Pier01 i ESADE Creapolis ściągają talent do miasta - Barcelona jest laboratorium innowacji Hiszpanii. Ale rzeczywistość regulacyjna powstaje w centrali AESIA w La Coruñi i jest zaostrzana w Madrycie.

## Trzy wyzwania regulacyjne dla AI na rynku katalońskim

Po pierwsze AESIA (Agencia Española de Supervisión de la Inteligencia Artificial). Hiszpania jest pierwszym krajem UE z dedykowanym organem nadzoru AI, ma swoją siedzibę w La Coruñi i aspiruje do roli wzorca dla krajowych wdrożeń EU AI Act w całej Unii. AESIA od 2026 systematycznie kontroluje systemy wysokiego ryzyka i może orzekać zakazy działania. Kto wprowadza modele na rynek w Barcelonie, musi od początku dokumentować pod kątem audytu AESIA - zgodnie ze standardami zdefiniowanymi w programie sandbox.

Po drugie AEPD (Agencia Española de Protección de Datos) wraz z LOPDGDD (Ley Orgánica 3/2018), hiszpańską ustawą wdrażającą RODO z zaostrzeniami. AEPD w całej UE słynie z najbardziej restrykcyjnej interpretacji Art. 22 RODO - w pełni zautomatyzowane decyzje są w Hiszpanii praktycznie dopuszczalne tylko przy udokumentowanej ostatecznej decyzji człowieka. Dla każdego systemu AI z danymi osobowymi oznacza to: Decision Layer z Human-in-the-Loop nie jest opcjonalny, lecz warunkiem compliance. Dla polskich inwestorów operujących w Hiszpanii (np. Inter Cars, Orlen w segmencie retail) różnica między miękkim polskim wdrożeniem a twardym hiszpańskim jest istotna operacyjnie.

Po trzecie CNMV (Comisión Nacional del Mercado de Valores) i Banco de España dla wszystkich usługodawców finansowych. CNMV od 2024 wymaga przy rekomendacjach inwestycyjnych wspomaganych AI kompletnego Audit Trail i kontroluje wyjaśnialność modeli. Jednocześnie Comité de Empresa zgodnie z Art. 64 Estatuto de los Trabajadores egzekwuje prawa konsultacyjne, gdy systemy AI podejmują decyzje dotyczące pracowników. Warto zauważyć, że hiszpański Comité de Empresa ma podobny zakres jak polska Rada Zakładowa - wyłącznie konsultacje, bez prawa weta - co polskim menedżerom pomaga w intuicyjnym zrozumieniu procesu.

## Typowe scenariusze wdrożeń w Barcelonie

CaixaBank prowadzi jedną z największych sieci oddziałów w Hiszpanii i potrzebuje dla oceny zdolności kredytowej małych i średnich firm modeli, które pod nadzorem AEPD pozostają reprodukowalne - każda odmowa musi być w ciągu 14 dni uzasadnialna. Grifols dokumentuje łańcuchy pochodzenia plazmy od dawców w setkach centrów w USA i UE - FDA wymaga pełnego Audit Trail, EMA odzwierciedla to wymaganie. Wspomagana AI kontrola plauzybilności nie jest tu innowacją, lecz compliance. Cellnex Telecom eksploatuje dziesiątki tysięcy wież nadawczych w Europie i wykorzystuje Predictive Maintenance do priorytetyzacji prac serwisowych - każda zautomatyzowana decyzja triage musi pozostać udokumentowana wobec właścicieli (często inwestorów instytucjonalnych). Seat planuje w Martorell produkcję modeli Cupra i potrzebuje AI do planowania mocy produkcyjnych między zakładami - modele muszą ostać się audytom koncernu VW.

W każdym z tych przypadków [Decision Layer](/pl/decision-layer/) buduje warstwę między modelem a procesem biznesowym, która wymusza Audit Trail, ścieżki eskalacji i Governance by Design - dokładnie to, czego jednocześnie oczekują AESIA, AEPD i CNMV.

Dochodzą wymagania sektorowe: firmy farmaceutyczne jak Grifols pracują pod nadzorem EMA i muszą dokumentować wspomagane AI decyzje jakościowe zgodnie z GMP. Operatorzy telekomunikacyjni jak Cellnex podlegają nadzorowi CNMC i muszą móc ujawnić implikacje siły rynkowej swoich algorytmów. A w sektorze automotive koncern VW oczekuje dla każdego narzędzia AI w zakładach Seat oceny ryzyka według tych samych standardów, które obowiązują w Wolfsburgu czy Ingolstadt.

## Jak Gosign obsługuje Katalonię i Hiszpanię z biura w Barcelonie

Gosign ma własne biuro w Barcelonie (gosign.es) z hiszpańskim i katalońskim zespołem - native speakerzy, lokalne zarządzanie projektami, bezpośredni kontakt z AESIA, AEPD i CNMV. Biuro w Barcelonie pełni rolę regional hub dla całego Półwyspu Iberyjskiego: warsztaty discovery, sprint review i steering odbywają się na miejscu u klienta w dzielnicy 22@, w Pier01 lub bezpośrednio w centralach CaixaBanku, Cellnex, Mango, Dammu i Grifolsu. Dla Banco Sabadell, Seat w Martorell i Naturgy standardem są warsztaty po hiszpańsku lub katalońsku, dokumentacja compliance dostarczana jest dwujęzycznie (ES i CA), a Comité de Empresa od początku siedzi przy stole. Eskalacje w kierunku Hamburga istnieją tylko dla architektonicznych kwestii zasadniczych lub połączenia z niemieckimi i szwajcarskimi spółkami matkami. Polscy klienci z ekspozycją hiszpańską koordynują projekt przez biuro w Krakowie, delivery na miejscu leży po stronie zespołu w Barcelonie. Więcej o naszym podejściu na stronie [usługi AI Agents](/pl/uslugi/ai-agents/).

## Dlaczego Barcelona to dobry punkt startowy dla Enterprise AI

Hiszpania stoi przed podwójną falą: nadzór AESIA i wdrożenie EU AI Act wchodzą jednocześnie do eksploatacji produkcyjnej. Kto w Barcelonie zbuduje pilotaż Cert-Ready by Design, ma referencję, która przetrwa standardy AEPD i AESIA - a potem w Madrycie, Bilbao, Walencji i Mediolanie będzie od razu do obrony. Klaster 22@Barcelona, Pier01 i program BStartup Banco Sabadell dostarczają talent, partnerów pilotażowych i dostęp do inwestorów. Jednocześnie miasto jest wystarczająco blisko Madrytu i Brukseli, żeby szybko reagować na regulacyjne nowości - i wystarczająco daleko, by zachować własny charakter technologiczny.

Wnosimy z polskiego i niemieckiego rynku doświadczenie budowania systemów AI, które pozostają produktywne nawet pod surowymi reżimami nadzoru - z [EU AI Act Compliance](/pl/governance/eu-ai-act/) jako bazą i Audit Trail aż do poziomu SQL. Barcelona jest właściwym rynkiem, by tę dyscyplinę skalować w Europie Południowej.

--- Agenci AI dla Firm w Belo Horizonte | Gosign ---
> Enterprise AI Agents dla BH i Minas Gerais. LGPD-compliant, CLT-kompatybilne. Gornictwo, hutnictwo, energetyka. Zarzadzanie z Sao Paulo.

## Belo Horizonte to rynek, na którym brazylijskie górnictwo broni swojej wiarygodności ESG

Minas Gerais wytwarza połowę brazylijskiej rudy żelaza oraz znaczną część stali, złota i aluminium kraju. W Belo Horizonte i okolicach mają siedzibę lub prowadzą działalność Vale (z centralnymi lokalizacjami w Nova Lima i Itabira, koordynowane z BH), Usiminas (stal, z zakładami w Ipatinga), AngloGold Ashanti, Magnesita Refratários, Localiza (największa brazylijska wypożyczalnia samochodów z globalną centralą w BH) oraz Fiat Chrysler Brasil w zakładzie Betim. To korytarz przemysłowy, którym przepływa każda światowa cena stali i każda decyzja inwestorów ESG o brazylijskim górnictwie. A także korytarz, w którym katastrofy tam w Mariana (2015) i Brumadinho (2019) zmieniły każdy proces "risk-based decision making" na następne 20 lat. To, co przed 2019 uchodziło za "operacyjne modelowanie ryzyka", dziś jest obszarem prawnie wrażliwym, w którym każda rekomendacja algorytmiczna potencjalnie musi być obroniona przed sądami cywilnymi i prokuraturą federalną (MPF).

## Trzy wyzwania regulacyjne dla AI na rynku Belo Horizonte

Po pierwsze obowiązki dokumentacyjne ANM po Brumadinho. Agência Nacional de Mineração od 2019 drastycznie zaostrzyła wymogi dotyczące dokumentacji tam, dowodów stabilności i raportowania ryzyka (Resolução ANM 95/2022 i kolejne). Każdy komponent algorytmiczny w monitoringu tam, analizie danych sensorycznych czy klasyfikacji ryzyka musi być przed audytorami ANM prześledzalny z kompletną ścieżką decyzyjną - Audit Trail aż do poziomu sensorów. Dla polskich inwestorów z portfelem komodytowym to wymóg, którego odpowiednika nie ma w KNF czy polskim Ministerstwie Środowiska.

Po drugie IBAMA i pozwolenia środowiskowe SEMAD. Brazylijskie ministerstwo środowiska IBAMA oraz stanowy organ SEMAD MG wymagają dla operacji górniczych i przemysłowych szczegółowych ocen oddziaływania na środowisko (EIA/RIMA) i ciągłego monitoringu. AI, która szacuje emisje, optymalizuje parametry procesów czy klasyfikuje incydenty bezpieczeństwa, podlega konkretnym wymogom środowiskowym - z udokumentowaną wyjaśnialnością na żądanie audytora. Różnica względem polskiego systemu OOŚ: IBAMA ma uprawnienia do wstrzymania operacji w trybie natychmiastowym.

Po trzecie LGPD i współdecydowanie przez Sindicatos. Sindicatos w przemyśle metalurgicznym i górniczym (Sindiextra, Sticcer) są w BH historycznie silnie zakorzenione. Systemy AI, które podejmują decyzje o planowaniu zmian, alarmach bezpieczeństwa czy decyzjach HR, muszą być negocjowane z przedstawicielami Sindicato - LGPD-compliant i z Decision Layer, który architektonicznie odwzorowuje workflow współdecydowania. Brazylijski CLT (Consolidação das Leis do Trabalho) oraz regionalne układy zbiorowe (CCT/ACT) czynią konsultację z Sindicato warunkiem prawnym każdego HR-Agenta w regionie. W przeciwieństwie do polskiej Rady Zakładowej, która ma tylko prawa konsultacyjne, brazylijski Sindicato ma realne narzędzia blokujące.

## Typowe scenariusze wdrożeń w Belo Horizonte

Vale Dam-Safety-Monitoring: Workflow Agents monitorują dane z sensorów na tamach odpadów poflotacyjnych w Itabira, Brucutu i innych lokalizacjach w Minas Gerais, zestawiają je z danymi pogodowymi i raportami inspekcji, a Decision Layer eskaluje krytyczne wzorce ryzyka z Human-in-the-Loop do zespołów geotechnicznych. Każda decyzja udokumentowana dla ANM, MPF i wewnętrznego compliance - to różnica między linią obrony a aktem oskarżenia.

Localiza zarządzanie flotą: Document i Workflow Agents przetwarzają protokoły serwisowe, zgłoszenia szkód i dane ubezpieczeniowe największej floty wypożyczalni samochodów w Ameryce Łacińskiej. Decision Layer routuje eskalacje do partnerów warsztatowych i priorytetyzuje krytyczne pojazdy do inspekcji - z audytowalnym życiorysem pojazdu. Po fuzji z Unidas Localiza awansowała do trzeciej co do wielkości wypożyczalni na świecie, z odpowiednim wolumenem danych i wymaganiami spójności algorytmicznej między flotami regionalnymi.

Usiminas planowanie produkcji stalowni: Document Agents czytają księgi zamówień, dane logistyczne i profile zużycia energii, tworzą rekomendacje produkcyjne dla zakładów w Ipatinga i Cubatão. Decision Layer eskaluje konflikty z wymogami bezpieczeństwa ANM lub kontraktami energetycznymi ANEEL do planistów ludzkich. Workflow Agents alarmują proaktywnie o grożących przestojach lub przerwach łańcucha dostaw i dokumentują każdą rekomendację z Audit Trail.

Fiat Chrysler Brasil Betim kontrola jakości: Document Agents przetwarzają protokoły inspekcji, wskaźniki jakości i raporty audytów dostawców z największego zakładu Fiata poza Włochami. Decision Layer eskaluje krytyczne odchylenia jakościowe z Human-in-the-Loop do kierowników warsztatów - Audit Trail spełnia zarówno standardy koncernu Stellantis, jak i wymogi INMETRO dotyczące brazylijskiej certyfikacji pojazdów.

## Jak Gosign obsługuje całą Brazylię z Sao Paulo - włącznie z Belo Horizonte

Nasze [biuro w Sao Paulo](/pl/agenci-ai-sao-paulo/) jest godzinę lotu od BH. Warsztaty discovery z Vale, Usiminas czy Localiza odbywają się na miejscu w BH lub w lokalizacjach zakładów - w Itabira, Ipatinga, Betim. Review compliance z odniesieniem do ANM lub IBAMA są prowadzone wspólnie z Twoim działem prawnym i zewnętrznymi prawnikami środowiskowymi - w projektach górniczych to krok decydujący, bo interpretacja regulacyjna w szczegółach jest często ważniejsza niż architektura modelu. Konsultacje z Sindicato, gdy wdrażane są agenty HR lub planowania zmian, prowadzone są przez lokalne kancelarie prawa pracy w BH i bazują na historycznie silnych strukturach Sindiextra w regionie. Fazy build działają rozproszenie między Hamburgiem a Sao Paulo - standupy rano czasu SP, wspólne sprint review z odpowiedzialnymi za zakłady na miejscu. Terminy on-site w BH są organizowane w ciągu 24 godzin, również do odległych lokalizacji górniczych w Itabira czy Brucutu. Po go-live biuro SP jest Twoim operacyjnym punktem kontaktu z infolinią eskalacyjną po portugalsku. Dla polskich inwestorów z Vale czy Usiminas w portfelu koordynację zapewnia biuro w Krakowie. Więcej o naszym podejściu na stronie [usługi AI Agents](/pl/uslugi/ai-agents/).

## Dlaczego Belo Horizonte to dobry punkt startowy dla Enterprise AI

BH jest jedynym rynkiem w Brazylii, gdzie jednocześnie istnieją przemysłowa rzeczywistość (górnictwo, stal, motoryzacja), stała presja regulacyjna (ANM po Brumadinho) i klastry innowacyjne (San Pedro Valley, P7 Creative Hub). Kto zbuduje tu produkcyjnego agenta dla bezpieczeństwa tam, optymalizacji produkcji lub raportowania ESG, buduje go pod najostrzejszymi wymaganiami audytowymi brazylijskiego przemysłu - to czyni go kompatybilnym z każdym innym rynkiem górniczym i stalowym na świecie, od Chile po zachodnią Australię. Universidade Federal de Minas Gerais (UFMG) i Universidade Federal de Ouro Preto (UFOP) dostarczają talent w geotechnice, metalurgii i przemysłowym IT, niedostępny w tej koncentracji nigdzie indziej w Brazylii. Architektura Cert-Ready by Design gwarantuje, że agent wypróbowany w BH ostoi się w europejskich audytach RODO i EU AI Act - warunek dla inwestorów ESG i dla wymogów łańcuchów dostaw europejskich odbiorców (od ArcelorMittal po Volkswagen). Zobacz też [Rio de Janeiro](/pl/agenci-ai-rio-de-janeiro/) i [Brazylię jako całość](/pl/agenci-ai-brazylia/).

--- Agenci AI dla Firm w Berlinie | Gosign ---
> Enterprise AI Agents w Berlinie. Osobiste kierownictwo projektów, RODO-konform, EU AI Act compliant. Od startupu po ministerstwo - od PoC do produkcji.

## Berlin to jedyny niemiecki rynek, na którym ministerstwo federalne i startup po rundzie B potrzebują tego samego dostawcy AI

Żadne inne miejsce w obszarze niemieckojęzycznym nie łączy takiego rozpiętości. W dzielnicy rządowej mają siedziby Urząd Kanclerza Federalnego, BMI i BMWK ze swoimi projektami konsolidacji IT i wolumenem inwestycyjnym, który przez kolejne lata będzie kształtował cyfryzację administracji. Trzy stacje metra dalej N26, Solaris, Zalando i Delivery Hero pracują nad pytaniami skalowania, które nie mają już nic wspólnego z klasycznym IT bankowym. Cariad ma w Berlinie hub softwareowy i rozwija platformę software dla samochodów koncernu Volkswagen. Deutsche Bahn prowadzi z Potsdamer Platz jedno z największych korporacyjnych Data Office w Niemczech, SAP zakorzenił tu swoje Data Spaces, IBM i Microsoft prowadzą lokalizacje z funkcją badawczą i sprzedażową. Ta mieszanka wymusza architekturę, która zarówno postępowanie administracyjne z obowiązkiem prowadzenia akt, jak i model KYC w N26 odwzorowuje czysto - z tym samym Decision Layer i tymi samymi wymogami Audit Trail, ale z zestawami reguł specyficznymi dla jurysdykcji i procesu nałożonymi powyżej.

## Trzy wyzwania regulacyjne, które definiują w Berlinie każdy przypadek AI

Pierwszym wyzwaniem jest nadzór BaFin nad berlińskimi FinTechami. N26 i Solaris są licencjonowane jako instytucje CRR, okólniki BaFin do MaRisk i BAIT obowiązują w pełnej ostrości, oba domy w ostatnich latach przeszły kilka kontroli specjalnych z zaleceniami, które ukształtowały rynkowe rozumienie oczekiwań regulacyjnych. Kto chce tu zbudować model AML lub wykrywanie nadużyć z AI, potrzebuje governance modeli, które kontrolerzy specjalni BaFin akceptują jako sprawdzalny łańcuch dowodów - łącznie z wersjonowaniem, uzasadnieniem progów i odtwarzalną decyzją. Drugim wyzwaniem jest administracja publiczna: BSI poprzez IT-Grundschutz i swoje minimalne standardy AI definiuje ramy, BMI poprzez projekty następcze ustawy o dostępie online (Online-Zugangsgesetz) określa, jak automatyczne decyzje w postępowaniach administracyjnych muszą być protokołowane. Oba nadzory wymagają Audit Trail, który da się podłączyć do obowiązku prowadzenia akt. Trzecim wyzwaniem jest sam EU AI Act, który od 2026 obowiązuje w klasyfikacji wysokiego ryzyka - decyzje personalne, scoring kredytowy i decyzje administracyjne wpadają w Berlinie jednocześnie w co najmniej trzy obszary zastosowania. Więcej kontekstu pod [Governance EU AI Act](/pl/governance/eu-ai-act/).

## Typowe scenariusze wdrożeń w Berlinie

W sektorze publicznym chodzi o strukturalne przetwarzanie napływających wniosków - decyzji o dofinansowaniu, dosyłek do akt, zapytań obywateli - z jasnym przyporządkowaniem do specjalistów i pełną notatką w aktach na każdy krok AI. Widzimy projekty pilotażowe, w których Document Agents klasyfikują dokumenty administracyjne, wyłapują pola obowiązkowe i ze wskazaniem na kompletność lub brakujące załączniki przekazują je właściwemu specjaliście. W N26 i podobnych bankach licencjonowanych widzimy AML triage agents, które wzbogacają hity z monitoringu transakcji o historię klienta, dane KYC i źródła zewnętrzne, dokonują uzasadnionej oceny prawdopodobieństwa i przygotowują Suspicious Activity Report dla compliance officera - officer decyduje, agent dokumentuje bez luk. Deutsche Bahn pracuje nad koncepcjami predictive maintenance dla pociągów i infrastruktury torowej, gdzie decyzję o serwisie podejmuje na końcu certyfikowany utrzymaniowiec, ale agent dostarcza historię czujników i porównawcze dane podobnych komponentów jako strukturalną propozycję. Cariad i podobne software house OEM potrzebują code review agents znających wymogi ASPICE i ISO 26262 i oznaczających krytyczne zmiany w kodzie do przeglądu architektonicznego. W Zalando i Delivery Hero widzimy agentów customer service i logistyki, którzy strukturyzują powtarzające się sprawy i priorytetyzują eskalacje. Wszystkie scenariusze łączy jedno: brak w pełni automatycznej decyzji, lecz [Decision Layer](/pl/decision-layer/) z wymuszonym Human-in-the-Loop w odpowiednich miejscach.

## Jak Gosign obsługuje Berlin z biura w Berlinie i centrali w Hamburgu

Prowadzimy w Berlinie własne biuro przy Nogatstraße 46 w Neukölln - to nie skrzynka pocztowa, lecz lokalizacja dla kierownictwa projektów, Discovery workshops i opieki nad mandatami sektora publicznego. Główna siedziba pozostaje w Hamburgu, stamtąd przychodzą engineering i architektura governance, w Berlinie siedzi opieka operacyjna nad projektami stołecznymi. Konkretnie znaczy to: Discovery startuje dwu- do trzydniowym warsztatem u Ciebie w Berlinie lub w berlińskim biurze, w fazie budowy pracujemy zdalnie z dwoma stałymi tygodniowymi slotami na miejscu, uruchomienie znów przeprowadzamy na miejscu. Workshops walidacji modeli z kontrolerami specjalnymi BaFin lub z audytem wewnętrznym banków licencjonowanych odbywają się zasadniczo na miejscu, ponieważ tu powstaje relacja zaufania z nadzorem. Wizyty na miejscu między Tiergartenem, Mitte i Adlershofem są możliwe w ciągu jednego dnia - połączenie Hamburg - Berlin przez Hauptbahnhof ICE jest w niespełna dwie godziny, co czyni warstwę inżynieryjną z Hamburga elastycznie dostępną. Społeczności i klastry takie jak Silicon Allee, Factory Berlin i CUBE wykorzystujemy aktywnie, by również poza terminami klienckimi być widocznym technicznie i budować kontakty z audytorami pomocne później w ocenach zgodności.

## Dlaczego Berlin to dobry punkt startowy dla Enterprise AI

Stolica jest jedynym miejscem w Niemczech, w którym możesz w jednym dniu skombinować polityczne ramy, praktykę regulacyjną i przedsiębiorczą szybkość. Kto uruchomi w Berlinie pierwszego agenta produkcyjnie, ten typowo obronił go przed trzema grupami interesariuszy jednocześnie: audytem koncernowym, ochroną danych i radą zakładową. To potrójne hartowanie jest jednocześnie najlepszym przygotowaniem do skalowania w innych regionach. Dochodzi dostępność danych i compute przez BerlinIX i lokalizacje Telehouse z bezpośrednim podłączeniem do dużych regionów hyperscalerów, rosnąca pula talentów ML engineering przez TU, HPI i Berlin School of Business and Innovation oraz gęsta sieć społeczności AI i meetupów, która czyni wymianę best practices normą. Geograficzna bliskość polityków, praktyków nadzoru i tech-założycieli w jednym obszarze miejskim skraca drogi do alignmentu interesariuszy w sposób nieistniejący na żadnym innym niemieckim rynku. Kto ma tu w 4-6 tygodni produkcyjny Decision Layer z Audit Trail, spełnia Cert-Ready by Design dokładnie dla tych interesariuszy, którzy w koncernach mają zwykle najdłuższy efekt blokujący. Więcej o podejściu pod [usługi AI Agents](/pl/uslugi/ai-agents/).

--- Agenci AI dla Firm w Bilbao | Gosign ---
> Enterprise AI Agents dla Bilbao i Kraju Basków. Przemysł, energetyka, bankowość. EU AI Act compliant. Zarządzanie z Barcelony.

## Bilbao to jedyne hiszpańskie miasto, w którym ciężki przemysł i infrastruktura energetyczna wymagają compliance jednocześnie

Kraj Basków jest przemysłową antytezą turystycznego południa Hiszpanii. W Bilbao i regionie Bizkaia mają siedziby Iberdrola - globalny gigant energetyczny z centralą w Torre Iberdrola - oraz Petronor (rafineria Repsol w Muskiz), CAF (Construcciones y Auxiliar de Ferrocarriles) jako producent taboru kolejowego, Tubacex i Sidenor w przetwórstwie stali oraz grupa Kutxabank. BBVA ma historyczną lokalizację w Bilbao i nadal prowadzi tu znaczące funkcje operacyjne, Euskaltel stanowi regionalną podstawę telekomunikacyjną. Kto buduje AI w Bilbao, buduje nie dla branż usługowych, lecz dla sieci elektroenergetycznych, wielkich pieców, flot pociągów i platform, których przestój liczony jest w milionach euro na godzinę. Dla polskich inwestorów z ekspozycją na rynek iberyjski (np. Orlen, Asseco, inwestorzy infrastrukturalni) Bilbao jest testem dojrzałości architektury AI pod realnym obciążeniem przemysłowym.

## Trzy wyzwania regulacyjne dla AI na rynku baskijskim

Po pierwsze podwójny reżim ochrony danych. Hiszpania jest jedynym krajem UE z regionalnym organem ochrony danych obok krajowego: AVPD (Agencia Vasca de Protección de Datos) odpowiada w Kraju Basków za podmioty publiczne i częściowo za regionalnie zakorzenione firmy, podczas gdy AEPD (Agencia Española de Protección de Datos) pokrywa resztę. Oba organy wdrażają LOPDGDD (Ley Orgánica 3/2018) i szczególnie surowo kontrolują zautomatyzowane decyzje. Kto pracuje w Kraju Basków z danymi osobowymi, musi w architekturze compliance uwzględniać obu adresatów. Nie ma tu analogii do polskiego UODO, który jest pojedynczym krajowym organem.

Po drugie CNMV i Banco de España dla logiki finansowej w BBVA i Kutxabank. Oba banki od lat stawiają na modele risk wspomagane AI, ale CNMV od 2024 wymaga pełnej wyjaśnialności modeli wpływających na rekomendacje inwestycyjne. Audit Trail, reprodukowalność i ścieżki eskalacji przy decyzjach ryzyka nie są już negocjowalne.

Po trzecie EU AI Act w połączeniu z przemysłowymi reżimami bezpieczeństwa. Iberdrola eksploatuje infrastrukturę najwyższych napięć, CAF buduje tabor szynowy - w obu domenach EU AI Act z kategoriami wysokiego ryzyka (infrastruktura energetyczna, krytyczny transport) spotyka się ze standardami bezpieczeństwa branżowego (UNE-EN, IEC 61508). [EU AI Act Compliance](/pl/governance/eu-ai-act/) oznacza tu nie "sprawdzić ochronę danych", lecz "certyfikować model AI jako komponent bezpieczeństwa".

## Typowe scenariusze wdrożeń w Bilbao

Iberdrola optymalizuje operacje smart grid na wielu rynkach - modele decydują, kiedy który producent przejmuje jakie obciążenia. Każda decyzja jest dokumentowana wobec regionalnego operatora sieci, Audit Trails są warunkiem uczestnictwa w rynku. BBVA rozwija modele risk scoring dla decyzji kredytowych dla baskijskiego średniego biznesu, które zgodnie z Art. 22 RODO muszą być uzasadnialne wobec klientów. CAF serwisuje floty pociągów w kilku krajach europejskich i wykorzystuje dane telematyczne do Predictive Maintenance - rekomendacje muszą być prześledzalne dla organów nadzoru w każdym kraju operatora. Tubacex w produkcji stali szlachetnej stawia na kontrolę jakości wspomaganą AI, w której każda zautomatyzowana decyzja o odrzucie musi pozostać udokumentowana wobec wielkich klientów jak Aramco czy Equinor.

We wszystkich czterech scenariuszach chodzi o przemysłowe AI wpływające na aktywa fizyczne. [Decision Layer](/pl/decision-layer/) wnosi tu architekturę wyposażającą decyzje w Audit Trail, eskalację Human-in-the-Loop i Cert-Ready by Design.

Baskijska specyfika: tradycja spółdzielcza wokół Mondragon kształtuje również niespółdzielcze firmy regionu. Udział pracowników w decyzjach technologicznych nie jest tu kwestią compliance, lecz częścią kultury biznesowej. Budujemy Decision Layer tak, aby obowiązki współdecydowania Comité de Empresa i spółdzielcze struktury Governance były architektonicznie spełnione - nie jako następcza konsultacja, lecz jako zintegrowany workflow w samym systemie.

## Jak Gosign obsługuje Bilbao z Barcelony

Gosign obsługuje projekty baskijskie z biura w Barcelonie (gosign.es) z hiszpańskojęzycznymi kierownikami projektów i inżynierami. Bezpośredni lot Barcelona-Bilbao trwa około godziny - terminy on-site w Torre Iberdrola, w BBVA, CAF w Beasain, Tubacex i klastrze BEAZ są osiągalne w ciągu dnia roboczego. Hiszpański zespół wspiera baskijski przemysł pod regionalnymi specyfikami: podwójny reżim ochrony danych AVPD + AEPD, spółdzielcza tradycja Mondragon ze strukturami współdecydowania oraz wielojęzyczność między hiszpańskim a euskara, która w dyskusjach technicznych istnieje obok siebie. W razie potrzeby włączamy baskijskojęzycznych interesariuszy bezpośrednio w warsztaty. Hamburska centrala przejmuje ogólnoeuropejskie tematy compliance i architektoniczne kwestie zasadnicze oraz połączenie z niemieckimi standardami compliance przemysłowego. Polscy inwestorzy z ekspozycją baskijską koordynują projekt przez biuro w Krakowie - delivery operacyjne, język inżynieryjny baskijskiego ciężkiego przemysłu i krótsze ścieżki decyzyjne w Kraju Basków leżą po stronie zespołu z Barcelony. Więcej o naszym podejściu na stronie [usługi AI Agents](/pl/uslugi/ai-agents/).

## Dlaczego Bilbao to dobry punkt startowy dla Enterprise AI

Kto w Bilbao wprowadzi na produkcję przemysłowy pilotaż AI, ma referencję, która przeszła przez podwójny nadzór ochrony danych (AEPD + AVPD), standardy CNMV i logikę wysokiego ryzyka EU AI Act - poprzeczka nigdzie w Hiszpanii nie jest wyżej. Klaster BEAZ, Bizkaia Startup Bay i Mondragon Innovation Hub dostarczają ekosystem, talent i partnerów pilotażowych. Jednocześnie baskijskie firmy mają przewagę myślenia długofalowego: projekty AI nie są tu planowane jako kwartalne pilotaże, lecz jako inwestycja na wiele lat.

Wnosimy doświadczenie budowy systemów AI, które nie tylko działają, ale pozostają obronne pod warunkami audytu - z Governance by Design, Audit Trail i dyscypliną, której wymaga przemysłowy compliance. Bilbao jest właściwym rynkiem, by tę dyscyplinę skalować w północnej Hiszpanii.

Jest też geograficzna przewaga: z Kraju Basków sięgasz zarówno przemysłu południowej Francji (Aerospace w Tuluzie, Pharma w Lyonie), jak i portugalskiej północy (Tech i przemysł wokół Porto). Kto zbuduje w Bilbao architekturę AI, która wchodzi na produkcję pod hiszpańskimi warunkami, ma referencję dla całego zachodnioeuropejskiego łuku atlantyckiego.

--- Agenci AI dla Firm w Brasilii | Gosign ---
> Enterprise AI Agents dla Brasilii. LGPD-compliant, kompatybilne z sektorem publicznym. ANPD w tym samym mieście. Audytowalne agenty dla rządu i finansów.

## Brasília to rynek, na którym brazylijska regulacja AI jest faktycznie rozstrzygana

Brasília nie ma central korporacyjnych jak São Paulo ani klastrów przemysłowych jak Belo Horizonte - ale ma coś, czego te miasta nie mają: wszystkie krajowe organy regulacyjne na jednym płaskowyżu. ANPD (Autoridade Nacional de Proteção de Dados) ma siedzibę w Setor Comercial Sul. BACEN (Banco Central do Brasil) działa z Setor Bancário Sul. CADE, ANATEL, ANVISA i ANM siedzą w odległości 5 km. Do tego banki federalne Caixa Econômica Federal i Banco do Brasil z centralami na Setor Bancário, Ministério da Fazenda, STF i STJ. Kto buduje w Brasilii AI dla organu federalnego, banku federalnego lub regulowanego koncernu, buduje ją w polu widzenia samego regulatora. To czyni z Brasilii strategicznie najważniejszy rynek dla każdego, kto poważnie chce eksploatować public-sector-AI lub regulowane banking-AI w Brazylii - tu nie tylko się reguluje, tu się też kupuje.

## Trzy wyzwania regulacyjne dla AI na rynku Brasilii

Po pierwsze ANPD tu nie jest abstrakcyjna - to organ, w którego mieście operujesz. Nadzór LGPD nad bankami federalnymi, organami federalnymi i danymi rządowymi odbywa się z Brasilii. Kto buduje tu AI przetwarzającą dane obywateli (świadczenia socjalne, podatki, zdrowie), musi zachować Artykuł 23 LGPD (sektor publiczny) oraz Rezolucję CD/ANPD 02/2022 o DPIA - audytowalnie, udokumentowanie, w każdej chwili sprawdzalnie. Dla polskiej firmy doświadczenie z UODO i polskim sektorem publicznym jest punktem wyjścia, ale nie zastępstwem - brazylijski public sector ma własne wzorce dokumentacyjne.

Po drugie audytowalność TCU dla wydatków federalnych. Tribunal de Contas da União kontroluje wszystkie wydatki federalne pod kątem gospodarności i legalności. Komponenty algorytmiczne w kredytach Caixa, risk scoring Banco do Brasil czy planowaniu tras Correios muszą być wyjaśnialne dla audytorów TCU z kompletną ścieżką decyzyjną. Audit Trail nie jest tu "best practice" - jest warunkiem, że organ w ogóle może kontynuować współpracę z dostawcą.

Po trzecie PL 2338/2023 tu jest negocjowany. Brazylijski projekt ustawy o AI jest dyskutowany w Câmara dos Deputados i Senado Federal - oba w Brasilii. Kto buduje tu, buduje w mieście, w którym projekty regulacyjne są zmieniane między tygodniami sesyjnymi. Cert-Ready by Design to jedyna strategia, która wytrzyma tę zmienność: architektura ułożona tak, aby klasyfikacja high-risk, nadzór ludzki i obowiązki wyjaśnialności mogły być aktywowane następczo. Dla polskich podmiotów przyzwyczajonych do stabilnego EU AI Act oznacza to większą elastyczność architektoniczną.

## Typowe scenariusze wdrożeń w Brasilii

Caixa Econômica Federal - decyzje kredytowe: Document Agents sprawdzają wnioski kredytowe w społecznym budownictwie mieszkaniowym (Programa Minha Casa Minha Vida), zestawiają z danymi CadÚnico i zewnętrznymi danymi scoringu, a Decision Layer kieruje decyzje z Human-in-the-Loop do urzędników - każde przyznanie z audytowalnym dossier uzasadnień dla kontroli TCU.

ANPD policy analysis dla government advisory: Document Agents przetwarzają rezolucje ANPD, interpretacje LGPD i dokumenty konsultacyjne, tworzą dla zespołów compliance w organach federalnych codzienne raporty sytuacyjne o rozwoju regulacyjnym. Workflow Agents alarmują o nowych projektach PL 2338/2023.

Banco do Brasil wykrywanie nadużyć: Document i Workflow Agents monitorują wzorce transakcji w czasie rzeczywistym, eskalują podejrzane zdarzenia do compliance officerów i dokumentują każde wykrycie z pełnym Audit Trail - z confidence scores i wersjonowaniem modeli dla zgłoszeń Coaf i audytów BACEN. W bankach federalnych raportowanie regulacyjne jest gęstsze niż w bankach prywatnych, bo dodatkowo CGU (Controladoria-Geral da União) i TCU mogą wystosowywać własne zapytania.

Correios - optymalizacja tras dostawczych: Document i Workflow Agents przetwarzają wolumeny przesyłek, klastry kodów pocztowych i pojemności doręczeń, proponują zoptymalizowane trasy dla największej logistyki pocztowej Brazylii. Decision Layer architektonicznie utrzymuje wymogi ANATEL co do terminów doręczeń i wymogi CLT co do czasu pracy doręczycieli - każda rekomendacja z audytowalnym dossier dla TCU.

## Jak Gosign obsługuje całą Brazylię z Sao Paulo - włącznie z Brasilią

Nasze [biuro w São Paulo](/pl/agenci-ai-sao-paulo/) jest 1,5 godziny lotu od Brasilii. Warsztaty discovery z Caixa, Banco do Brasil lub organem federalnym odbywają się na miejscu w Setorach Bancário i Comercial. Review compliance z odniesieniem do ANPD lub TCU prowadzone są wspólnie z Twoim działem prawnym w Brasilii - bliskość do regulatora jest tu operacyjną przewagą, bo terminy wyjaśniające z pracownikami ANPD dla regulowanych aktorów następują szybciej niż dla czysto zdalnych dostawców. Fazy techniczne build działają rozproszenie: Hamburg i São Paulo. Standupy rano czasu SP, sprint review z Twoim zespołem w Brasilii. Terminy on-site organizowane w ciągu 24 godzin. W projektach rządowych współpracujemy z lokalnymi kancelariami prawa publicznego - prawo zamówień publicznych, ramy zakupowe i specyfika LGPD dla sektora publicznego to odrębna dziedzina, której nie pokrywamy wewnętrznie, lecz obsługujemy partnersko. Więcej o naszym podejściu na stronie [usługi AI Agents](/pl/uslugi/ai-agents/).

## Dlaczego Brasília to dobry punkt startowy dla Enterprise AI

Brasília jest jedynym rynkiem w Brazylii, gdzie regulatorzy i regulowane instytucje federalne siedzą w tym samym mieście. Kto zbuduje tu produkcyjnego agenta dla oceny kredytowej Caixa, raportowania BACEN lub government advisory, buduje go w kontekście, w którym feedback regulacyjny nie przychodzi "za 6 miesięcy przy audycie", lecz w następnym tygodniu sesyjnym. Klastry - Sebrae HQ, BioTIC Park, Universidade de Brasília - dostarczają dodatkowo talent i partnerów badawczych. Brasília jako rynek public-sector działa dla europejskich dostawców szczególnie wtedy, gdy architektura łączy europejską głębię audytu [RODO](/pl/governance/eu-ai-act/) z brazylijską gotowością LGPD i PL 2338 - Governance by Design zamiast następczych łatek compliance. Kto buduje agenta dla organu federalnego lub banku federalnego, buduje go faktycznie pod publicznoprawną ramą zakupową - i dokładnie tu różnica między modelem uczynionym audytowalnym następczo a architekturą Cert-Ready by Design decyduje między przedłużeniem a wypowiedzeniem kontraktu. Więcej w [przeglądzie Brazylii](/pl/agenci-ai-brazylia/) lub w [profilu São Paulo](/pl/agenci-ai-sao-paulo/) dla operacyjnego podłączenia.

--- Agenci AI dla Firm w Brazylii | Gosign ---
> Enterprise AI Agents dla Brazylii. LGPD-compliant, CLT-kompatybilne, przygotowane na PL 2338/2023. Biuro w Sao Paulo, projekty w całej Brazylii.

## Brazylia to jedyny rynek LATAM, na którym Gosign pracuje z realną lokalną obecnością

Brazylia nie jest "jednym z wielu rynków latynoamerykańskich". Z ponad 215 milionami mieszkańców, dziewiątą co do wielkości gospodarką świata i ramami regulacyjnymi (LGPD, BACEN Resolução 4893, PL 2338/2023), które stoją samodzielnie obok prawa UE, Brazylia to odrębny blok uniwersum compliance. Gosign prowadzi dlatego biuro w São Paulo, które obejmuje operacyjnie nie tylko metropolię SP, ale cały rynek brazylijski - od Petrobras w Rio przez Caixa w Brasilii i Vale w Minas Gerais po Volvo w Kurytybie. To warunek, żeby niemiecko-polskie standardy Enterprise AI (Audit Trail, Cert-Ready by Design, Decision Layer z Human-in-the-Loop) działały na rynku, który z EU AI Act jest wprawdzie spokrewniony, ale nie identyczny.

## Trzy wyzwania regulacyjne dla AI na rynku brazylijskim

Po pierwsze LGPD (Lei Geral de Proteção de Dados) jest brazylijską odpowiedzią na RODO, ale nie jego tłumaczeniem. Ma własne podstawy prawne, własne wymogi DPO, własne sankcje i z ANPD (Autoridade Nacional de Proteção de Dados) własny organ nadzorczy z siedzibą w Brasilii. Kto z Polski i UE ekspanduje do Brazylii, nie może traktować LGPD jako "wariantu RODO" - interpretacja Artykułu 7 (podstawy prawne) i Artykułu 11 (dane wrażliwe) praktycznie znacząco się różni. Architektury AI muszą równolegle spełniać LGPD i RODO, nie zamiast. Dla polskich inwestorów z brazylijską ekspozycją (np. Boryszew, KGHM, Inter Cars) oznacza to: nie wystarczy UODO compliance przenieść 1:1.

Po drugie BACEN Resolução 4893 to brazylijska DORA. Wymogi cyber-resilience dla regulowanych instytucji finansowych (Itaú, Bradesco, Santander Brasil, Banco do Brasil, Caixa, Nubank, Stone, XP) są rozwijane niezależnie od prawa UE. Każdy komponent algorytmiczny w decyzjach kredytowych, fraud scoring, AML/KYC czy operacjach rynku kapitałowego musi być audytowalny dla BACEN - z obowiązkami raportowania, które odbiegają od europejskich implementacji DORA.

Po trzecie PL 2338/2023 to brazylijski projekt ustawy o AI. Jest zainspirowany EU AI Act, ale nie identyczny - w 2026 jeszcze nie w mocy, ale oczekiwany w ciągu najbliższych 18-24 miesięcy. Klasy ryzyka, obowiązek nadzoru ludzkiego i standardy wyjaśnialności są podobne, ale z własnymi brazylijskimi akcentami (w szczególności w relacji do Sindicatos i CREs przy systemach związanych z pracą). Cert-Ready by Design oznacza w Brazylii: architektura ułożona tak, aby obsługiwała LGPD dziś, PL 2338 od 2027 i EU AI Act jednocześnie dla operacji UE.

## Typowe scenariusze wdrożeń w Brazylii

Banking i Fintech: KYC/AML w [Itaú, Bradesco, Santander Brasil i Banco do Brasil](/pl/agenci-ai-sao-paulo/) - Document Agents czytają dane CPF/CNPJ, zestawiają z listami sankcyjnymi Coaf, a Decision Layer eskaluje trafienia high-risk z kompletnym Audit Trail. Ten sam wzorzec u Nubank, Stone, PagSeguro i XP Inc. - z fraud detection i raportowaniem BACEN w czasie rzeczywistym.

Górnictwo i energetyka: Vale Dam-Safety w [Minas Gerais](/pl/agenci-ai-belo-horizonte/) i dokumentacja instalacji Petrobras w [Rio](/pl/agenci-ai-rio-de-janeiro/) - Workflow Agents monitorują dane sensoryczne, raporty inspekcji i zewnętrzne wskaźniki ryzyka. Decision Layer eskaluje krytyczne wzorce ryzyka z Human-in-the-Loop. Audit Trail jest wyjaśnialny przed ANM, MPF, ANP i ANEEL.

Przemysł i motoryzacja: Volvo, Renault, VW i Klabin w [Kurytybie](/pl/agenci-ai-kurytyba/) - Document Agents dla Supply Chain, compliance Mercosul i raportowania ESG. Workflow Agents dla kontroli jakości i planowania serwisów. Cert-Ready dla audytów RODO w europejskich koncernach macierzystych.

Public Sector: ocena kredytowa Caixa i analiza polityk ANPD w [Brasilii](/pl/agenci-ai-brasilia/) - Document Agents dla wniosków o świadczenia socjalne, Workflow Agents dla monitoringu regulacyjnego. Audit Trail zgodnie z wymogami TCU, z dossier uzasadnień dla każdej algorytmicznej rekomendacji.

## Jak Gosign obsługuje całą Brazylię z São Paulo

Nasze [biuro w São Paulo](/pl/agenci-ai-sao-paulo/) jest operacyjnym hubem dla Brazylii - z lokalnymi kierownikami projektów, którzy prowadzą warsztaty discovery na miejscu, uczestniczą w review compliance z DPO i działem prawnym oraz towarzyszą konsultacjom z Sindicato. Z SP Rio (1 h lotu), Belo Horizonte (1 h), Kurytyba (1 h), Brasília (1,5 h) i Porto Alegre (1,5 h) są osiągalne w ciągu dnia - terminy on-site w 24 godziny. Faza techniczna build działa rozproszenie między Hamburgiem a São Paulo, ze wspólnymi standupami rano czasu SP. Po go-live biuro SP jest Twoim operacyjnym punktem kontaktu z infolinią eskalacyjną po portugalsku. Dla brazylijskich klientów z europejskimi operacjami (np. Natura do UE, JBS do UE) to jedyna konstelacja, która LGPD i RODO compliance odwzorowuje pod jednym dachem. Polskojęzyczne wsparcie dla polskich inwestorów z ekspozycją brazylijską zapewnia biuro w Krakowie jako koordynator projektu.

Co tę konstelację czyni atrakcyjną dla polskich spółek z brazylijską ekspozycją: kto z Warszawy czy Krakowa ekspanduje do Brazylii, ma partnera, który operacyjnie pokrywa oba światy - polska centrala dalej rozmawia z zespołem w Krakowie, brazylijska spółka zależna z zespołem w São Paulo. Warsztaty discovery i compliance odbywają się w obu językach. Architektura zbudowana w São Paulo może z minimalnymi adaptacjami wejść na produkcję w [Lizbonie](/pl/agenci-ai-lizbona/), Madrycie czy Krakowie, bo komponenty Audit, Decision Layer i Cert-Ready by Design już obsługują oba światy regulacyjne.

## Dlaczego Brazylia to dobry punkt startowy dla Enterprise AI

Brazylia jest jedynym rynkiem latynoamerykańskim, w którym compliance bankowy, operacje przemysłowe, sektor publiczny i łańcuchy dostaw dóbr konsumpcyjnych spotykają się w jednej ramie regulacyjnej. Kto zbuduje tu produkcyjnych agentów dla KYC, raportowania ESG lub bezpieczeństwa tam, ma ich jako blueprint dla Meksyku, Argentyny, Chile, Kolumbii i Peru. Biuro SP pozycjonuje Gosign jako europejskiego dostawcę z realną obecnością LATAM - kombinacja, której w polskim środowisku konkurencyjnym prawie nikt nie ma. Architektura Governance by Design zapewnia, że agent zbudowany w Brazylii ostoi się w europejskich audytach [RODO i EU AI Act](/pl/governance/eu-ai-act/) tak samo jak przed BACEN, ANPD czy TCU. Więcej w przeglądach miast [São Paulo](/pl/agenci-ai-sao-paulo/), [Rio](/pl/agenci-ai-rio-de-janeiro/) i [Brasília](/pl/agenci-ai-brasilia/) lub na stronie [usługi AI Agents](/pl/uslugi/ai-agents/).

--- Agenci AI dla Firm w Dublinie | Gosign ---
> Enterprise AI Agents dla Dublina. Europejskie centrale tech, nadzór DPC, EU AI Act bezpośrednio stosowany. Audytowalne AI dla hubu enterprise Irlandii.

## W Dublinie jeden organ nadzorczy UE decyduje, co dla 450 milionów Europejczyków jest zgodne z RODO

Dublin nie jest zwykłą europejską stolicą - to stolica regulacyjna dla amerykańskiego tech w Europie. Google EU, Meta EU, LinkedIn EU, Microsoft EU, Stripe EU i Apple mają tu swoje centrale UE, bo Irlandia oferuje kombinację reżimu podatkowego, języka angielskiego i stabilności politycznej. Do tego irlandzcy giganci: AIB (Allied Irish Banks), Bank of Ireland, Accenture z globalną siedzibą w Dublinie, Ryanair, Kerry Group i CRH (jeden z największych koncernów materiałów budowlanych na świecie). "Silicon Docks" nad Grand Canal skupia na kilku kilometrach kwadratowych więcej talentu inżynieryjnego dla Trust & Safety, Compliance Engineering i AI Governance niż jakiekolwiek inne europejskie miasto - bo tu siedzi nadzór dokładnie nad tymi tematami. Dla polskich firm B2B obsługujących dublińskie europejskie centrale (np. Asseco dla Microsoft EU, Comarch dla banków) Dublin to miejsce, gdzie standardy compliance faktycznie zapadają.

## Trzy wyzwania regulacyjne dla AI na rynku dublińskim

Po pierwsze DPC (Data Protection Commission). Ze względu na zasadę One-Stop-Shop RODO DPC jest dla niemal wszystkich amerykańskich koncernów tech z siedzibą UE w Irlandii wiodącym organem nadzoru - a tym samym faktycznie najważniejszym organem RODO w całej Unii. DPC w ostatnich latach nałożyła wielomiliardowe kary na Metę, Google i WhatsApp, a obecnie bada też modelowanie AI i dane treningowe pod reżimem RODO. Kto buduje AI w Dublinie, buduje dla organu, który bada każde źródło danych treningowych, każdą zautomatyzowaną decyzję i każdy transfer transgraniczny w szczegółach. Dla polskiego UODO jest to zupełnie inna skala egzekucji.

Po drugie EU AI Act, który w Irlandii jest bezpośrednio stosowany. Irlandzki rząd wyznaczył Department of Enterprise, Trade and Employment jako właściwy organ dla krajowego wdrożenia i ściśle współpracuje z DPC. Systemy AI wysokiego ryzyka koncernów tech z siedzibą UE Dublin będą w przyszłości tu certyfikowane - a oczekiwanie jest, że standardy będą interpretowane ponadprzeciętnie surowo, bo Dublin politycznie musi udowodnić, że nie jest luką nadzorczą.

Po trzecie Central Bank of Ireland (CBI) dla wszystkich usługodawców finansowych. Stripe, Mastercard EU, Citi EU, Goldman Sachs EU - wszyscy są pod nadzorem CBI i muszą dokumentować wspomagane AI modele compliance i risk zgodnie ze standardami CBI Innovation Hub. CBI wymaga pełnej wyjaśnialności, Audit Trails i ciągłego monitoringu modeli. [Compliance EU AI Act](/pl/governance/eu-ai-act/) i nadzór finansowy muszą tu się zazębiać.

## Typowe scenariusze wdrożeń w Dublinie

Google wykorzystuje Dublin jako globalny hub dla AI Model Governance i pracuje tu nad narzędziami compliance, które muszą uczynić każdą decyzję modelu wyjaśnialną wobec DPC. Meta dokumentuje tu Digital Services Act (DSA) i sprawdza modele moderacji treści pod kątem ryzyk systemowych - każda decyzja algorytmiczna musi mieć Audit Trail. Stripe buduje globalne modele payment risk, które w sekundach blokują lub zatwierdzają transakcje - modele muszą pozostać prześledzalne dla CBI. AIB modernizuje decyzje kredytowe i potrzebuje modeli, które są obronne jednocześnie pod Art. 22 RODO i Central Bank Code of Conduct.

We wszystkich przypadkach powstają decyzje o globalnym zasięgu, ale nadzór dzieje się w Dublinie - często z krótkimi czasami reakcji i trudnymi pytaniami o zachowanie modelu, dane treningowe i bias mitigation. [Decision Layer](/pl/decision-layer/) rozwiązuje dokładnie to wymaganie: czyni każdą decyzję AI persystowalną jako trace, egzekwuje Human-in-the-Loop przy krytycznych ścieżkach i dostarcza Audit Trails, które wytrzymują audytorów DPC i CBI.

Irlandzka specyfika to oczekiwanie DPC: inaczej niż niektóre organy nadzoru UE, DPC nie bada tylko po naruszeniach, lecz regularnie prowadzi proaktywne Inquiries. Kto w Dublinie produktywnie eksploatuje zastosowanie AI, musi liczyć się z tym, że DPC bez zapowiedzi wgląda w dokumentację, pochodzenie danych treningowych i decyzje modelu. Cert-Ready by Design oznacza tu nie "kiedy dojdzie do audytu" - lecz "permanentnie gotowy do kontroli".

## Jak Gosign obsługuje Dublin z Hamburga

Hamburg-Dublin to bezpośredni lot około dwóch godzin, z kilkoma codziennymi połączeniami. Pracujemy remote-first z klientami w Dublinie i Cork, z warsztatami on-site dla discovery i decyzji architektonicznych. Językiem pracy jest angielski, steering z naszymi architektami w Hamburgu prowadzony jest po niemiecku. Strefa czasowa (Irlandia WET, godzina za CET) jest manageable, irlandzki styl biznesowy pragmatyczny i skory do decyzji. Dla polskich klientów z ekspozycją na Dublin (np. dostawcy dla banków irlandzkich) koordynację zapewnia nasze [biuro w Krakowie](/pl/agenci-ai-krakow/) - polskojęzyczne PM i compliance obok niemieckiego zespołu architektów i angielskojęzycznego delivery.

Co wnosimy z niemieckiego i polskiego rynku, to dyscyplina engineeringu pod surowym nadzorem. Niemieckie banki, które obsługujemy, mają z BaFin i MaRisk porównywalne wymogi compliance do irlandzkich koncernów tech z DPC i CBI - tonalność regulacyjna jest znajoma, odpowiedzi techniczne przenoszą się bezpośrednio. Znamy irlandzkie reżimy nadzoru tech dostatecznie dobrze, żeby nie musieć najpierw tłumaczyć każdego pojęcia, i w warsztatach discovery od razu możemy zaoferować konkretne decyzje architektoniczne. Więcej o naszym podejściu na stronie [usługi AI Agents](/pl/uslugi/ai-agents/).

## Dlaczego Dublin to dobry punkt startowy dla Enterprise AI

Dublin ma najwyższe regulacyjne wymagania dla AI w Europie - a jednocześnie największą koncentrację kompetencji inżynieryjnej dla AI Governance. Kto zbuduje tu pilotaż Cert-Ready by Design, ma referencję, która w każdym innym rynku UE jest od razu do obrony - i która wytrzymuje DPC. Klaster Silicon Docks, Dublin Tech Cluster i program Enterprise Ireland AI dostarczają talent, ekosystem i partnerów pilotażowych.

Druga zaleta: kto buduje AI w Dublinie, automatycznie uczy się, jak działa pan-europejski compliance. Większość irlandzkich koncernów tech operuje jednocześnie we wszystkich 27 państwach członkowskich - każda architektura musi obsługiwać zestawy reguł specyficzne dla jurysdykcji bez fragmentacji Audit Trail. Dokładnie to dostarcza Governance by Design. Hamburg dostarcza niemiecką dyscyplinę engineeringu, Kraków polskojęzyczne wsparcie dla polskich inwestorów, a Dublin - roll-out w całej UE. Zobacz też [Londyn](/pl/agenci-ai-londyn/) i [Amsterdam](/pl/agenci-ai-amsterdam/).

--- Agenci AI dla Firm w Dusseldorfie | Gosign ---
> Enterprise AI Agents dla Dusseldorfu i Nadrenii Północnej-Westfalii. RODO-konform, EU AI Act compliant. Automatyzacja struktur Shared-Service.

## Dusseldorf to niemiecka lokalizacja, w której dobra konsumpcyjne, energetyka, telekomunikacja i przemysłowy mittelstand na ciasnej przestrzeni stawiają to samo pytanie Shared-Service

W korytarzu między Königsallee, Oberkassel i targami dusseldorfskimi koncentrują się Henkel, Vodafone Deutschland z siedzibą centralną, E.ON, Metro AG i Uniper - do tego Ergo jako część grupy Munich Re, Rheinmetall jako koncern obronny, L'Oréal Deutschland i Trivago jako największa firma tech Dusseldorfu. Dochodzi cała Nadrenia z Bayer i LANXESS w Leverkusen, oddziałami Henkla w Dusseldorf-Holthausen i gęstym mittelstandem między Krefeld, Wuppertalem i Duisburgiem. Ta koncentracja wytwarza specyficzne zapotrzebowanie architektoniczne: większość tych koncernów prowadzi Shared Service Center dla Finance, HR i IT, które orkestrują procesy równolegle dla dziesięciu do stu spółek - każda z inną jurysdykcją, układami zbiorowymi i reżimami podatkowymi. Dla polskich dostawców i partnerów B2B (Boryszew, Inter Cars, Comarch dla niemieckich koncernów) zrozumienie architektury Shared-Service jest kluczem do kontraktów. Architektura AI, która tu działa, musi być wielopodmiotowa i nosić reguły Governance per podmiot.

## Trzy wyzwania regulacyjne dla AI na rynku dusseldorfskim

Pierwsza to specyficzna dla NRW regulacja energii. BNetzA z siedzibą w Bonn jest centralnym organem nadzorczym dla sieci prądu i gazu, a większość dużych dostawców energii w Niemczech ma operacje rynkowe w Dusseldorfie lub Essen. E.ON, Uniper i ich spółki dystrybucyjne pracują w codziennej działalności z formatami danych BNetzA i specyfikacjami BDEW. Komponent AI w prognozie obciążenia, zarządzaniu bilansami lub akwizycji klientów musi znać te formaty danych i używać ich prześledzalnie.

Druga to silne współdecydowanie w koncernach NRW z Radami Zakładowymi i Konzernbetriebsrätami zaprawionymi w IG Metall, IGBCE czy ver.di. Shared-Service AI musi budować Decision Layer architektonicznie tak, żeby decyzje podlegające współdecydowaniu były obligatoryjnie przedkładane kwalifikowanemu pracownikowi, a Betriebsvereinbarungen muszą być od początku myślane razem z architekturą. W odróżnieniu od polskiej Rady Zakładowej, która ma tylko prawa konsultacyjne, niemiecka rada zakładowa ma realne weto - to najważniejsza różnica, którą polscy menedżerowie muszą zrozumieć przy integracji z niemiecką centralą.

Trzecia to Lieferkettensorgfaltspflichtengesetz (niemiecka ustawa o łańcuchu dostaw) i dyrektywa unijna CSDDD. Henkel, L'Oréal, Metro i Rheinmetall muszą dokumentować ryzyka dla swoich globalnych łańcuchów dostaw i przygotowywać raportowanie BAFA. Dla polskich poddostawców w łańcuchu wartości tych koncernów oznacza to: wymogi dokumentacyjne trafiają do nich poprzez klauzule dostawcze. Więcej tła w [Governance EU AI Act](/pl/governance/eu-ai-act/).

## Typowe scenariusze wdrożeń w Dusseldorfie

Przy Henklu i porównywalnych koncernach dóbr konsumpcyjnych widzimy agentów compliance łańcucha dostaw, którzy strukturyzują wpływającą dokumentację dostawców i eskalują wskazówki ryzyka do Sustainability Managera - z kompletnym Audit Trail dla raportowania BAFA zgodnie z ustawą o łańcuchu dostaw. Przy E.ON i w szerszym środowisku energetycznym chodzi o towarzyszenie rolloutowi smart meterów i strukturyzowaną obsługę wniosków o przyłączenie do sieci, przy których urzędnicy podejmują ostateczną decyzję. Metro AG pracuje nad use cases sterowania asortymentem i dystrybucji towarów, w których agent ocenia regionalne dane klientów i sezonowość oraz daje propozycję Category Managerowi. Przy Ergo i porównywalnych ubezpieczycielach agenci wspierają sprawdzanie umów w ubezpieczeniach na życie i przy ocenie kumulacji szkód. Przy Vodafone Deutschland widzimy agentów obsługi klienta, którzy strukturyzują sprawy klientów, priorytetyzują oddzwonienia i dla regulowanych przypadków reklamacji zgodnie z wymogami BNetzA przekazują pełną sprawę urzędnikowi z odpowiedzialnością za zarządzanie reklamacjami. Przy L'Oréal Deutschland i podobnych producentach dóbr konsumpcyjnych Document Agents wspierają przy compliance składu i unijnym rozporządzeniu kosmetycznym. Przy Trivago i w dusseldorfskim środowisku tech widzimy agentowe wsparcie w obsłudze klienta i moderacji treści, które podlega Digital Services Act. Przy Rheinmetall w środowisku obronnym widzimy Document Agents w analizie kontraktów i screeningu dostawców, którzy ze względu na kontrolę eksportu muszą spełniać szczególne wymogi audytu. We wszystkich case'ach decyduje kwalifikowana osoba fachowa, agent dokumentuje, a [Decision Layer](/pl/decision-layer/) trzyma uzasadnienie jako Audit Trail.

## Jak Gosign obsługuje Dusseldorf z Hamburga i Krakowa

Gosign nie ma lokalizacji w Dusseldorfie - towarzyszenie on-site odbywa się z Hamburga i biura berlińskiego. Bezpośrednie połączenie ICE Hamburg-Dusseldorf trwa niecałe cztery godziny, bezpośredni lot jest wyraźnie szybszy. Konkretnie organizujemy współpracę tak: kick-off i warsztaty discovery odbywają się na miejscu w Dusseldorfie, najczęściej jako dwudniowy blok z częściami Engineering, Compliance i Rada Zakładowa. W fazie build łączymy remote engineering z dwutygodniowymi dniami on-site dla review architektury, walidacji modeli i aktualizacji dla stakeholderów. Gdy koncern prowadzi Shared Services w wielu lokalizacjach NRW, jeździmy na ważne warsztaty na miejscu w odpowiednich oddziałach - Dusseldorf-Holthausen dla Henkla, Essen dla E.ON, Leverkusen dla LANXESS lub Bayera. Ta rozproszona logika on-site jest specyfiką rynku nadreńskiego, bo centrale koncernów w NRW są często fizycznie rozproszone, a terminy dla stakeholderów trzeba odpowiednio organizować. Polscy poddostawcy niemieckich koncernów NRW koordynowani są przez nasze [biuro w Krakowie](/pl/agenci-ai-krakow/) - polskojęzyczni PM-owie po stronie klienta, niemiecki zespół architektów po stronie koncernu macierzystego. Więcej na stronie [usługi AI Agents](/pl/uslugi/ai-agents/).

## Dlaczego Dusseldorf to dobry punkt startowy dla Enterprise AI

Kto wprowadza agenta AI w dusseldorfskim Shared Service Center na produkcję, obronił go przed co najmniej trzema jurysdykcjami, kilkoma układami zbiorowymi i doświadczonym Konzernbetriebsratem - architektura, która to osiąga, jest następnie skalowalna w każdej innej konstelacji multi-entity w Europie. Dochodzi specyficzny dla NRW krajobraz finansowania: land NRW wspiera projekty AI w ramach kilku programów innowacyjnych, a faza discovery z reguły identyfikuje co najmniej jedną odpowiednią linię finansowania. Klastry jak Digital Hub Dusseldorf-Rheinland i sieć Life Science w Nadrenii oferują wymianę techniczną i partnerów co-innovation. Do tego uczelnie Dusseldorfu i pobliskie uniwersytety w Kolonii, Bonn, Aachen z ich programami ML Engineering oraz Forschungszentrum Jülich jako kotwica dla High-Performance-Computing. Kto w 4-6 tygodni ma pierwszego Workflow Agenta produktywnie w Shared-Service NRW, buduje na architekturze wielopodmiotowej i [Governance by Design](/pl/governance/eu-ai-act/).

--- Agenci AI dla Firm we Frankfurcie | Gosign ---
> Enterprise AI Agents dla centrum finansowego Frankfurt. BaFin-ready, MaRisk-konform, EU AI Act compliant. Finance Agents z pełnym Audit Trail.

## Frankfurt to jedyny europejski rynek AI, na którym nadzór sam siedzi w tej samej dzielnicy co użytkownicy

Dzielnica bankowa między Taunusanlage a brzegiem Menu zawiera trzy warstwy jednocześnie: ECB jako europejski bank centralny i organ nadzoru, BaFin jako krajowy nadzór finansowy z siedzibą w Bonn z oddziałem i intensywną obecnością frankfurcką oraz dużych adresatów licencjonowanych - Deutsche Bank, Commerzbank, DZ Bank, KfW, Helaba, DekaBank, Deutsche Börse, ING-DiBa, BNP Paribas Deutschland. Dochodzą specjaliści infrastruktury rynkowej tacy jak Clearstream i Eurex. Jeśli frankfurcki model AI zawiedzie, kolejny kontroler specjalny BaFin ma go w tym samym tygodniu na biurku. To jednocześnie siła lokalizacji: nikt nie może tu wystartować z PoC, który od początku nie jest [Cert-Ready by Design](/pl/governance/eu-ai-act/). ECB poprzez Single Supervisory Mechanism ma bezpośredni nadzór nad instytucjami istotnie znaczącymi, co zmusza frankfurckie banki do podwójnej logiki nadzoru - europejskiej i krajowej. Komponenty AI w tych domach muszą być sprawdzalne dla obu nadzorów jednocześnie.

## Trzy wyzwania regulacyjne, które każda inicjatywa AI na frankfurckim rynku finansowym musi przejść

Pierwszym wyzwaniem są MaRisk i BAIT jako wymogi nadzoru bankowego. Każdy model ingerujący w zarządzanie ryzykiem, decyzje kredytowe lub zapobieganie praniu pieniędzy musi być udokumentowany walidacją modelu wytrzymującą kontrole audytu wewnętrznego i kontrolerów specjalnych BaFin równocześnie - łącznie z backtestingiem, analizą wrażliwości i odtwarzalnym treningiem. Drugim wyzwaniem jest blok MiFID II: Transaction Reporting według artykułu 26 MiFIR, dowody Best Execution oraz wytyczne z ESMA Q&A dotykają każdego automatycznego komponentu zlecenia lub doradztwa. Wytyczne EBA do ICT Risk Management uzupełniają to o jasne oczekiwania wobec outsourcingu i dostawców trzecich. Trzecim wyzwaniem jest samo sprawozdawanie do BaFin - FinaRisikoV, FinanzInformatikV, dane stress testów ECB - przy którym również wspierające komponenty AI uchodzą za część perymetru nadzoru. Kto celuje we frankfurckie centrum finansowe, planuje governance modeli, Audit Trail i walidację od dnia pierwszego jako pracę główną, nie jako załącznik do dokumentacji.

## Typowe scenariusze wdrożeń we Frankfurcie

W zapobieganiu praniu pieniędzy widzimy triage agents dla AML hits z systemów monitoringu transakcji - agent wzbogaca hit o historię klienta, dane KYC i źródła zewnętrzne takie jak listy sankcyjne i bazy PEP, ocenia prawdopodobieństwo i przekazuje propozycję do compliance officera, który decyduje, czy zgłoszenie idzie do FIU. W dużych adresatach w rozliczeniach papierów wartościowych agenci pomagają w pre settlement matching i obsłudze wyjątków - kosztownych reconciliacji prowadzonych dziś ręcznie. W raportowaniu MiFID II agenci sprawdzają kompletność i prawdopodobność zgłoszeń ARM przed złożeniem. W kredytach korporacyjnych wspierają przygotowanie analizy wiarygodności poprzez strukturalne przetwarzanie sprawozdań rocznych, bilansów i dokumentów umownych - analityk kredytowy otrzymuje przygotowaną przestrzeń danych z testami prawdopodobności, nie automatyczny rating. W KfW i podobnych bankach rozwoju widzimy Document Agents we wstępnej kwalifikacji wniosków, którzy sprawdzają napływające wnioski o dofinansowanie pod kątem kompletności i dają specjalistom strukturalny przegląd dokumentów. W Deutsche Börse i szerszym otoczeniu infrastruktury rynkowej Knowledge Agents wspierają zarządzanie standardami rynkowymi, danymi ISIN i dokumentacją listingową. W obszarach ICT istotnych dla BAIT agenci pomagają w strukturalnym przygotowaniu raportów incydentów i ocenie wyników penetration testów. Wszystkie te przypadki łączy jedno: ostateczną decyzję podejmuje zawsze człowiek, agent dostarcza uzasadnioną propozycję, a [Decision Layer](/pl/decision-layer/) trzyma pełny łańcuch z inputu, oceny, zaufania i uzasadnienia jako Audit Trail.

## Jak Gosign obsługuje Frankfurt z Hamburga

Gosign nie ma lokalizacji we Frankfurcie - to świadoma decyzja. Prowadzimy główną siedzibę w Hamburgu i biuro w Berlinie, Frankfurt osiągamy trasą ICE w niespełna cztery godziny. Konkretnie wygląda to tak: Discovery i kick off oraz ważne spotkania interesariuszy w ramach Risk i Compliance robimy na miejscu we Frankfurcie - typowo z dwudniowym pobytem łączącym warsztat, przegląd architektoniczny i briefing audytorów. Faza inżynieryjna idzie zdalnie z Hamburga, z dwutygodniowymi dniami na miejscu i stałymi slotami w Twoim Compliance Office. Workshops walidacji modeli z audytem wewnętrznym odbywają się zawsze na miejscu, ponieważ tu fachowa dyskusja z odpowiedzialnymi za Risk i Compliance kształtuje architekturę. Doświadczenie z Finance Agent Catalog ostatnich lat pokazuje: częstotliwość obecności na miejscu wystarcza dla większości projektów istotnych dla BaFin, ponieważ główna praca leży w udokumentowanej governance modeli - a ta zdalnie nie jest mniej dokładna.

## Dlaczego Frankfurt to dobry punkt startowy dla Enterprise AI

Centrum finansowe ma cechę, która wyróżnia je jako pierwszy krok strategii AI: kto przeprowadzi tu use case, ten obronił go przed najsurowszymi wymogami nadzoru w Europie. Ta sama walidacja modelu udźwignie potem [Monachium](/pl/agenci-ai-monachium/), [Stuttgart](/pl/agenci-ai-stuttgart/) lub [Düsseldorf](/pl/agenci-ai-dusseldorf/), bo żaden inny nadzór w Niemczech nie stosuje surowszych miar. Klastry takie jak Frankfurt Main Incubator jako jednostka innowacji Commerzbanku, TechQuartier przy Pollux z naciskiem na FinTech oraz House of Finance przy Goethe-Universität dostarczają kontekst ekosystemowy - łącznie z możliwością bezpośredniej rozmowy z przedstawicielami BaFin i praktykami nadzoru podczas wydarzeń. Struktury Eurex i Clearstream w lokalizacji dostarczają dodatkowo perspektywy infrastruktury rynkowej, gdzie komponenty AI muszą spełniać szczególnie ostre wymogi latencji i audytu. Dochodzi ECB jako kotwica regulacyjnych dyskusji. Kto ma w 4-6 tygodni produkcyjnego Finance Agent z Cert-Ready Audit Trail we Frankfurcie, ten ma w portfolio najtwardszy przykład compliance w republice. Więcej szczegółów o podejściu pod [usługi AI Agents](/pl/uslugi/ai-agents/).

--- Agenci AI dla Firm w Gdańsku | Gosign ---
> Enterprise AI Agents dla Gdańska i Trójmiasta. Logistyka, energia, IT. EU AI Act compliant, RODO-konform.

## Gdańsk łączy największy kontenerowy port Bałtyku z szybko rosnącym klastrem tech

Gdańsk i Trójmiasto (Gdańsk, Gdynia, Sopot) to jedyne miejsce w Polsce, gdzie wielkoskalowa logistyka morska, przemysł rafineryjny i tech outsourcing pracują w bezpośrednim sąsiedztwie. Port Gdańsk jest zdecydowanie największym portem kontenerowym Bałtyku, z połączeniami do Azji, Skandynawii i Europy Zachodniej. Lotos (obecnie część grupy Orlen) prowadzi tu jedną z największych rafinerii Europy Środkowej. Równocześnie Gdańsk jest siedzibą Intel Gdańsk, Amazon Development Center Gdańsk, DNV GL, Schibsted Media Group, Kainos i Asseco. Gdański Park Naukowo-Technologiczny oraz kompleks Alchemia tworzą fizyczny klaster technologiczny. To połączenie ciężkiego przemysłu, logistyki portowej i software engineering generuje wymogi regulacyjne, które w żadnym innym polskim mieście nie występują w takiej kombinacji.

## Trzy wyzwania regulacyjne dla AI na rynku gdańskim

Po pierwsze Urząd Morski i regulacja morska. Port Gdańsk działa pod nadzorem Urzędu Morskiego w Gdyni, rozporządzenia portowego UE i wielu konwencji międzynarodowych (SOLAS, MARPOL, ISPS Code). AI klasyfikujące ruchy kontenerów, weryfikujące dokumenty celne lub optymalizujące trasy ładunków musi sprowadzać każdą decyzję do tych regulacji. Błędna klasyfikacja kontenera z towarem niebezpiecznym to nie tylko incydent compliance - jest objęta obowiązkiem zgłoszenia do Komisji Europejskiej i może zatrzymać pracę portu.

Po drugie UODO i KNF dla operacji bankowych i ubezpieczeniowych w Trójmieście. PKO BP, Bank Pekao i kilku ubezpieczycieli prowadzi tu regionalne centra operacyjne. Przy automatycznej obsłudze wniosków i szkód KNF i UODO oczekują tych samych dowodów co w Warszawie - udokumentowanych podstaw modeli, pełnego Audit Trail i potwierdzonej ostatecznej decyzji człowieka w każdym przypadku ryzyka. W Amazon Development Center Gdańsk dodatkowo obowiązuje EU AI Act dla treningu modeli na danych istotnych konsumencko. KSeF (Krajowy System e-Faktur) jest kolejnym obowiązkowym wymogiem dla każdej operacji handlowej w porcie.

Po trzecie EU AI Act w połączeniu z polską ustawą o ochronie danych osobowych i wymaganiami sektorowymi. DNV GL jako globalny dostawca usług klasyfikacyjnych wydaje certyfikaty, które muszą być akceptowane w całej branży żeglugowej. Klasyfikacja oparta na AI podlega reżimowi oceny zgodności EU AI Act - oraz specyficznym wymaganiom Międzynarodowej Organizacji Morskiej. Kto wdraża w Gdańsku produkcyjne AI w klasyfikacji, potrzebuje architektury obsługującej kilka organów nadzoru naraz.

## Typowe scenariusze wdrożeń w Gdańsku

Port Gdańsk - tracking kontenerów: przy milionach ruchów kontenerów rocznie każda klasyfikacja - zawartość, pochodzenie, miejsce docelowe, status towaru niebezpiecznego - musi być prawidłowa i nadążalna. Document Agents wyłapują strukturalne dane z listów przewozowych i dokumentów celnych, Decision Layer kieruje przypadki podejrzane automatycznie do celników z wymuszoną ostateczną decyzją przy towarach niebezpiecznych.

Lotos - logi rafineryjne: gdańska rafineria Lotosu generuje codziennie miliony punktów danych z czujników i komunikatów konserwacyjnych. Workflow Agents klasyfikują anomalie według istotności bezpieczeństwa, Decision Layer wymusza Human-in-the-Loop przy ustaleniach krytycznych dla bezpieczeństwa i protokołuje każdą decyzję w Audit Trail - to wprost wymaganie nadzoru Wojewódzkiego Inspektoratu Ochrony Środowiska.

Amazon Development Center - compliance treningu modeli: gdański oddział Amazona rozwija modele dla aplikacji konsumenckich. Document Agents weryfikują dataset treningowy względem wymogów UODO i EU AI Act, dokumentują pochodzenie danych i automatycznie blokują użycie zbiorów bez wystarczającej podstawy prawnej.

DNV GL - weryfikacja certyfikatów: funkcja klasyfikacyjna DNV w Gdańsku weryfikuje statki, platformy i komponenty względem norm międzynarodowych. Document Agents wyłapują specyfikacje techniczne, porównują z obowiązującymi normami i kierują decyzje o zgodności do ludzkich audytorów - cały proces dokumentowany audytowalnie.

## Jak Gosign obsługuje Gdańsk z biura w Krakowie

Gosign obsługuje gdańskie projekty z krakowskiego biura (gosign.pl) z polskojęzycznymi inżynierami i kierownikami projektów. Krakowski zespół obsługuje region Trójmiasta (Gdańsk, Gdynia, Sopot) z regularną obecnością na miejscu - w Gdańskim Parku Naukowo-Technologicznym, w klastrze Alchemia i bezpośrednio u interesariuszy Portu Gdańsk, Lotos, Intel Gdańsk, Amazon Development Center i DNV GL. Discovery odbywa się dwudniowo na miejscu, z polskojęzycznymi właścicielami biznesowymi, funkcją compliance i przedstawicielem Rady Zakładowej przy stole. Build i sprint reviews prowadzimy następnie z krakowskim zespołem, po polsku i angielsku, z miesięcznymi steering committees w Trójmieście i krótkim czasem reakcji przy eskalacjach z Urzędem Morskim lub urzędami celnymi. Doświadczenie krakowskiego zespołu z logistyką morską spotyka się z hamburską ekspertyzą architektoniczną i portową compliance - hamburska centrala dostarcza połączenie z HPA, niemieckim urzędem celnym i rozporządzeniem portowym UE, Kraków - operacyjny delivery w polskiej rzeczywistości portowej.

## Dlaczego Gdańsk to dobry punkt startowy dla Enterprise AI

Gdańsk to najtrudniejszy polski rynek AI, ponieważ krajobraz regulacyjny jest najbardziej skomplikowany - Urząd Morski, KNF, UODO, EU AI Act i międzynarodowa regulacja żeglugowa zazębiają się ze sobą. Właśnie to czyni Gdańsk idealnym stres testem. Kto zbuduje agenta AI spełniającego wymogi Portu Gdańsk, ten stworzył architekturę funkcjonującą praktycznie w każdym innym logistycznie intensywnym rynku UE. Gdański Park Naukowo-Technologiczny i klaster Alchemia oferują inżynierów z multidomenową ekspertyzą, Politechnika Gdańska zapewnia ciągły dopływ młodych talentów.

Dla niemieckich firm średniej wielkości z bałtycką logistyką Gdańsk jest często pierwszą zagraniczną lokalizacją, w której naprawdę potrzebne jest Enterprise AI - i tym samym miejscem, w którym architektura po raz pierwszy musi sprawdzić się w prawdziwym wietrze regulacyjnym. Oś Hamburg - Gdańsk łączy dwa najważniejsze porty Bałtyku w Europie - to, co w Hamburgu jest doświadczeniem compliance z HPA, niemieckim urzędem celnym i rozporządzeniem portowym UE, można bezpośrednio przenieść na Gdańsk. Udane wdrożenie w Gdańsku otwiera tym samym nie tylko polski rynek, ale dostarcza wzorzec architektoniczny, który w [Warszawie](/pl/agenci-ai-warszawa/), [Krakowie](/pl/agenci-ai-krakow/) i [Wrocławiu](/pl/agenci-ai-wroclaw/) można wdrożyć bez większych zmian. Cert-Ready by Design oznacza tu konkretnie: platforma, która udowodniła swoją przydatność pod największą w Polsce presją regulacyjną. Więcej kontekstu o naszym podejściu w Polsce znajdziesz na [stronie kraju](/pl/agenci-ai-polska/), o architekturze zaś na stronie [Decision Layer](/pl/decision-layer/).

--- Agenci AI dla Firm w Hannowerze | Gosign ---
> Enterprise AI Agents dla Hannoweru i Dolnej Saksonii. Przemysł i MŚP - audytowalne, EU AI Act compliant. 90 minut z Hamburga.

## Hannower to lokalizacja, w której drugi co do wielkości reasekurator świata, największy niemiecki dostawca przemysłowy i globalna gospodarka targowa dzielą ten sam dworzec kolejowy

W korytarzu między dworcem głównym, terenem targów i List-Süd siedzą Continental jako drugi co do wielkości niemiecki dostawca motoryzacyjny z centralą koncernową, Hannover Rück jako drugi po Munich Re reasekurator świata, HDI jako linia ubezpieczeń pierwotnych koncernu Talanx, TUI jako największy europejski koncern turystyczny i VW Nutzfahrzeuge z największym zakładem w Stöcken. Dochodzą Sennheiser w Wedemark, Enercon w Aurich jako największy niemiecki producent turbin wiatrowych oraz Deutsche Messe AG z Hannover Messe i spuścizną CeBIT. Ta mieszanka wytwarza specyficzną strukturę rynku AI: koncerny z wysokim obciążeniem compliance spotykają szeroki techniczny mittelstand, który ma konkretne potencjały automatyzacji, ale potrzebuje Governance klasy enterprise. Rynek dolnosaksoński jest po NRW i Bawarii trzecim co do wielkości krajem przemysłowym Republiki. Dla polskich poddostawców w łańcuchu wartości Continental czy VW (KGHM, Comarch dla HDI, Boryszew dla automotive) Hannower jest kluczowym węzłem dokowania.

## Trzy wyzwania regulacyjne dla AI na rynku hannowerskim

Pierwsza to nadzór ubezpieczeniowy dla grupy Talanx i Hannover Rück. Wymogi BaFin dla ryzyka modeli, raportowania Solvency II i specyficzne wymogi ORSA dla reasekuratorów trafiają w każdy komponent AI w underwritingu, rezerwowaniu i modelowaniu Cat. Hannover Rück pracuje w codziennej działalności z modelami dla portfeli katastrof naturalnych i scenariuszy pandemicznych, których walidacja podlega najwyższym standardom, a ich komponenty AI muszą być bronione wobec wewnętrznych frameworków ryzyka modeli. Dla polskich reasekurów (PZU Re) odpowiedniki po stronie polskiej KNF są znacznie łagodniejsze - różnica istotna przy transgranicznej współpracy.

Druga to federalna ustawa o ochronie przed emisjami BImSchG, która dla Continentala jako dużego producenta przemysłowego i dla Enercon jako operatora wiatraków jest istotna w codziennej działalności - każdy komponent AI w monitoringu emisji lub sterowaniu instalacją musi być wykazywalny w logice zezwoleń BImSchG.

Trzecia to silne współdecydowanie IG Metall w zakładach Continental i VW oraz przy Sennheiser - aplikacja AI z danymi osobowymi lub rejestrowaniem wydajności przechodzi przez Rady Zakładowe tylko wtedy, gdy [Decision Layer](/pl/decision-layer/) wymusza ostateczną decyzję człowieka, a Audit Trail dokumentuje uzasadnienie. W odróżnieniu od polskiej Rady Zakładowej z prawami konsultacyjnymi, niemiecka rada zakładowa ma realne weto - to najważniejsza różnica dla polskich managerów przy integracji z niemiecką centralą. Więcej o ramach w [Governance EU AI Act](/pl/governance/eu-ai-act/).

## Typowe scenariusze wdrożeń w Hannowerze

Przy Continentalu widzimy agentów danych jakościowych w produkcji opon, którzy konsolidują dane pomiarowe z wielu zakładów i eskalują nieprawidłowości do Quality Engineers - z prześledzalną oceną. W zakładzie VW Nutzfahrzeuge w Stöcken agenci pracują nad use cases planowania produkcji i zarządzania dostawcami, w których Production Steering podejmuje ostateczną decyzję. Przy HDI i Hannover Rück agenci wspierają obsługę szkód i modelowanie Cat - agent wzbogaca wyniki modelu o dane umowne i zewnętrzne źródła, underwriterzy decydują. Przy TUI agenci obsługi klienta pomagają przy strukturyzacji spraw klientów i priorytetyzacji oddzwonień. Przy Sennheiser i w szerszym mittelstandzie widzimy Document Agents dla faktur przychodzących, analizy umów i komunikacji z dostawcami - typowe wejście, gdy konkretne wąskie gardło w księgowości ma być zautomatyzowane. Przy Enercon agenci pracują nad przygotowaniem Predictive Maintenance dla turbin wiatrowych, przy których technicy serwisu decydują, kiedy następuje wymiana komponentu - agent strukturyzuje dane sensoryczne, Service Manager decyduje o oknie serwisowym. Przy Deutsche Messe AG widzimy Knowledge Agents w obsłudze wystawców i zwiedzających, którzy strukturyzują powtarzające się zapytania i przekazują je planowaniu targów. Niedersächsische Landesförderbank NBank pracuje z Document Agents w ocenie wniosków projektów finansowania AI - tu agent pomaga w strukturyzowanym przygotowaniu dokumentów wniosku dla urzędników. W każdym przypadku Audit Trail trzyma łańcuch uzasadnień.

## Jak Gosign obsługuje Hannower z Hamburga

Hannower jest najbliższym dużym niemieckim rynkiem dla naszej hamburskiej siedziby - bezpośrednie połączenie ICE Hamburg-Hannower trwa niecałe 90 minut. Wizyty on-site są realizowalne w trybie tego samego dnia. Konkretnie oznacza to: warsztaty discovery z Engineering, Compliance i Mitbestimmung prowadzimy na miejscu, często jako jedno- lub dwudniowy blok. W fazie engineeringu łączymy pracę zdalną z cotygodniowymi dniami on-site, bo krótki dojazd czyni to możliwym bez przeszkód logistycznych. Review architektury, walidacje modeli dla Solvency II i negocjacje współdecydowania odbywają się na miejscu. Dla Continental i Hannover Rück z centralami koncernowymi w hannowerskim centrum jesteśmy często kilkakrotnie w miesiącu on-site - bliskość nie czyni częstotliwości on-site problemem logistycznym. Klastry jak Hannover Impuls jako agencja rozwoju stolicy landu i sieć innowacji Dolnej Saksonii wykorzystujemy do dyskusji technicznych i kontaktów z NBank, która towarzyszy wielu projektom AI w dolnosaksońskim mittelstandzie. Hannover Messe jako największe targi przemysłowe świata dostarcza co roku kompaktowy przegląd rynku i dla wielu naszych projektów klienckich jest naturalną kotwicą dla decyzji produktowych. Polscy partnerzy B2B Continentala i VW koordynowani są przez nasze [biuro w Krakowie](/pl/agenci-ai-krakow/). Więcej na stronie [usługi AI Agents](/pl/uslugi/ai-agents/).

## Dlaczego Hannower to dobry punkt startowy dla Enterprise AI

Hannower ma cechę, która nie istnieje w żadnym innym niemieckim rynku: kombinacja central koncernowych z wysokim obciążeniem compliance i szerokiego technicznego mittelstandu, który nie tylko funkcjonuje jako łańcuch dostaw koncernów, lecz obsługuje własne globalne rynki. Kto wprowadza tu pierwszego agenta AI na produkcję, ma go typowo przetestowanego wobec compliance ubezpieczeniowego, współdecydowania przemysłowego i pragmatyzmu mittelstandu - trzech najtwardszych stress testów, jakie oferuje niemiecki rynek. Dochodzi położenie geograficzne: 90 minut do Hamburga, dwie godziny do Berlina, trzy godziny do Frankfurtu. Hannower jest dzięki temu naturalną kotwicą dla skalowania wieloregionalnego w DACH. Talent ML Engineering pochodzi z Leibniz Universität Hannover z jej silnym wydziałem informatyki, z centrum badawczego L3S z akcentem na Web Science i ML oraz z lokalizacji DFKI jako kotwicy dla stosowanych badań AI. Kto w 4-6 tygodni ma agenta w hannowerskim koncernie lub mittelstandzie produktywnie, korzysta z bliskości do hamburskiego engineeringu i może następnie przenieść use case na całą północnoniemiecką sieć.

--- Agenci AI dla Firm w Hiszpanii | Gosign ---
> Enterprise AI Agents dla Hiszpanii. AESIA-ready, RODO + LOPDGDD konform, EU AI Act compliant. Biuro w Barcelonie, projekty w całej Hiszpanii.

## Hiszpania jako pierwszy kraj UE ma własny organ nadzoru AI - to zmienia planowanie wdrożenia

Hiszpania jest jedynym państwem UE, które z AESIA (Agencia Española de Supervisión de la Inteligencia Artificial) ma już w pełni operacyjny krajowy organ nadzoru AI. AESIA z siedzibą w La Coruñi jest hiszpańską odpowiedzią na EU AI Act i odgrywa rolę, która w większości innych krajów UE jest jeszcze rozproszona lub nieobsadzona. Dla koncernów jak Santander, BBVA, CaixaBank, Sabadell, Telefónica, Iberdrola, Repsol, Inditex, Mercadona, Ferrovial, ACS, Mapfre, Amadeus IT Group, Grifols i Naturgy oznacza to: klarowność regulacyjna wcześniej niż gdzie indziej. Aglomeracje Madryt, Barcelona, Walencja, Bilbao, Sewilla i Malaga tworzą najważniejsze huby tech kraju - i wszystkie podlegają temu samemu jednolitemu nadzorowi AI. Kto buduje w Hiszpanii Enterprise AI, ma regulatora, który wie, czego oczekuje, i komunikuje to jasno. Dla polskich inwestorów z ekspozycją hiszpańską (Inter Cars, polskie fintechy obsługujące BBVA) AESIA jest równocześnie wyzwaniem i przewagą - zbudowany pod AESIA system jest de facto gotowy na całą UE, zanim polski odpowiednik powstanie.

## Trzy wyzwania regulacyjne dla AI na rynku hiszpańskim

Po pierwsze AESIA i EU AI Act. AESIA jest operacyjna od 2024 i aktywnie rozwija wytyczne dla systemów AI wysokiego ryzyka w rozumieniu EU AI Act Annex III. Przy decyzjach HR, kredyt scoringu, identyfikacji biometrycznej i infrastrukturze krytycznej AESIA oczekuje udokumentowanych ocen zgodności, zarządzania ryzykiem, post-market monitoring i kompletnego Audit Trail. Przewaga nad innymi krajami UE: hiszpańskie koncerny już dziś wiedzą, czego się od nich oczekuje w 2026 i 2027 - podczas gdy koncerny w Niemczech, Polsce czy Francji jeszcze czekają na krajowe ustawy wykonawcze.

Po drugie AEPD i LOPDGDD. Agencia Española de Protección de Datos nadzoruje RODO w Hiszpanii, uzupełnione hiszpańską Ley Orgánica de Protección de Datos y Garantía de los Derechos Digitales (LOPDGDD) oraz LGICTE dla przejrzystości AI w kontakcie z konsumentami. Przy kredyt scoringu Santandera, operacjach AML BBVA czy systemach rekomendacji Telefóniki AEPD oczekuje udokumentowanych podstaw prawnych, dostępnych wyjaśnień i prześledzalnej ostatecznej decyzji człowieka. Hiszpańska specyfika: przy decyzjach algorytmicznych w kontakcie z konsumentami LGICTE explicite wymaga obowiązku przejrzystości, który w żadnej innej jurysdykcji UE w tej formie nie istnieje.

Po trzecie CNMV, Banco de España i CNMC dla nadzoru sektorowego. Santander, BBVA, CaixaBank i Sabadell są pod nadzorem CNMV (nadzór rynku kapitałowego) i Banco de España (nadzór bankowy). Przy rekomendacjach istotnych dla MiFID, screeningu AML i underwritingu oba organy oczekują tych samych standardów wyjaśnialności i audytu co BaFin czy FCA. CNMC dodatkowo nadzoruje decyzje algorytmiczne istotne konkurencyjnie - aspekt, który w Mercadonie, Inditexie i hiszpańskim e-commerce coraz mocniej wchodzi w centrum uwagi. Hiszpańskie koncerny z biznesem LATAM muszą dodatkowo uwzględniać LGPD w Brazylii i argentyńską ustawę o ochronie danych 25.326.

## Typowe scenariusze wdrożeń w Hiszpanii

Santander i BBVA kredyt scoring: hiszpańskie wielkie banki przetwarzają miliony wniosków kredytowych rocznie w Hiszpanii i LATAM. Document Agents ekstrahują strukturyzowane dane z formularzy wniosków, Decision Layer routuje przypadki ryzyka wzdłuż progów Banco de España, z Human-in-the-Loop przy każdej ostatecznej decyzji ryzyka i Audit Trail, który ostaje się jednocześnie wobec CNMV, AEPD i AESIA.

Telefónica rekomendacje konsumenckie: Telefónica eksploatuje systemy rekomendacji dla taryf, treści i usług dodanych w kilku rynkach hiszpańsko- i portugalskojęzycznych. Decision Agents sprawdzają każdą rekomendację wobec LOPDGDD, wymogów przejrzystości LGICTE i wytycznych LGPD w Brazylii - każda odtworzona decyzja z prześledzalnym uzasadnieniem.

Inditex i Mercadona Supply Chain Operations: liderzy hiszpańscy w modzie i detalu żywności eksploatują wysoce złożone łańcuchy dostaw. Workflow Agents klasyfikują zamówienia, zwroty i incydenty dostawców, Decision Layer routuje eskalacje do ludzkich odpowiedzialnych i protokołuje każdą decyzję dla wewnętrznych rewizji i audytów konkurencyjnych CNMC.

Iberdrola i Naturgy operacje sieciowe: hiszpańskie koncerny energetyczne stosują AI do optymalizacji sieci, predictive maintenance i prognoz zużycia. Document Agents ekstrahują zgłoszenia bezpieczeństwa i konserwacji, Workflow Agents klasyfikują anomalie według wagi, z wymuszoną ostateczną decyzją człowieka przy wynikach istotnych dla bezpieczeństwa - wymóg, który AESIA dla AI istotnej dla KRITIS explicite stawia.

## Jak Gosign obsługuje całą Hiszpanię z Barcelony

Gosign ma własne biuro w Barcelonie (gosign.es) jako regional hub dla Półwyspu Iberyjskiego. Hiszpańsko-kataloński zespół z kierownikami projektów i inżynierami - native speakerzy, wszystkie języki stakeholderów w domu - obsługuje wszystkie cztery główne regiony rynkowe kraju: [Madryt](/pl/agenci-ai-madryt/) jako stolicę koncernów i regulatorów, [Barcelonę](/pl/agenci-ai-barcelona/) jako hub tech, [Walencję](/pl/agenci-ai-walencja/) jako lokalizację przemysłową i logistyczną oraz [Bilbao](/pl/agenci-ai-bilbao/) jako baskijskie serce przemysłowe. Warsztaty on-site, sprint reviews i steering prowadzone są po hiszpańsku, w Katalonii dodatkowo po katalońsku, w Kraju Basków w razie potrzeby z baskijskojęzycznymi interesariuszami. Bezpośrednie kontakty z AESIA w La Coruñi, AEPD i CNMV w Madrycie prowadzi zespół z Barcelony, dokumentacja compliance dostarczana jest dwujęzycznie. Polscy inwestorzy z ekspozycją iberyjską koordynowani są przez [biuro w Krakowie](/pl/agenci-ai-krakow/) - polskojęzyczny PM, hiszpańskojęzyczny delivery. Hamburska centrala dostarcza standardy architektury technicznej i międzynarodową koordynację z niemieckimi, szwajcarskimi i holenderskimi koncernami macierzystymi. Dla hiszpańskich koncernów z biznesem LATAM - Santander, Telefónica, BBVA, Mapfre - zespół z Barcelony dodatkowo łączy się z biurem São Paulo (gosign.com.br), żeby RODO, LGPD i meksykański LFPDPPP były odwzorowane nad tą samą architekturą. Więcej o naszym podejściu na stronie [usługi AI Agents](/pl/uslugi/ai-agents/).

## Dlaczego Hiszpania to dobry punkt startowy dla Enterprise AI

Hiszpania ma strukturalną przewagę, której dziś żaden inny duży rynek UE nie oferuje: klarowność regulacyjna z jednego centralnego źródła. Kto buduje agenta AI dla hiszpańskiej firmy, który ostaje się wobec oczekiwań AESIA dziś, rozwinął architekturę, która jest EU AI Act compliant - zanim inne kraje UE mają w ogóle operacyjne krajowe organy nadzoru. Dla niemieckich, szwajcarskich i nordyckich koncernów z hiszpańskimi lub LATAM spółkami zależnymi Hiszpania jest często pierwszym produktywnym rynkiem AI - hiszpańska zgodność z AESIA staje się wzorcem dla następującej fali rollout do innych krajów UE. Cert-Ready by Design oznacza tu: architektura, która dziś spełnia wymogi, które w reszcie UE stają się wiążące dopiero w 2027. Hiszpańska rola pioniera nie jest przypadkiem, lecz programem - i znaczącą przewagą lokalizacyjną dla każdego, kto zaczyna teraz. Więcej kontekstu o [EU AI Act](/pl/governance/eu-ai-act/) i hiszpańskim wdrożeniu znajdziesz w obszarze Governance.

--- Agenci AI dla Firm w Kolonii | Gosign ---
> Enterprise AI Agents dla Kolonii. Media, handel, ubezpieczenia - audytowalne AI dla branż o dużym wolumenie dokumentów. EU AI Act compliant.

## Kolonia to jedyna niemiecka lokalizacja, w której europejski nadzór lotniczy, federalny organ żywnościowy i prywatne koncerny medialne siedzą w zasięgu codziennego dojazdu

W korytarzu między lotniskiem Köln-Bonn, centrum i Mediapark siedzą RTL Deutschland jako największy prywatny koncern TV Europy, Ford-Werke w Niehl z drugim co do wielkości europejskim zakładem Forda, Rewe Group z siedzibą koncernową w pobliżu Stolwerk, DEVK i Gothaer jako dwaj duzi kolońscy ubezpieczyciele oraz Toyota Deutschland w Köln-Marsdorf. TÜV Rheinland siedzi w Kolonii i jest jedną z najważniejszych europejskich jednostek certyfikujących. W sąsiednim Köln-Bonn leży EASA jako europejski organ lotniczy, w Bonn BLE jako federalny urząd rolnictwa i żywności. Lufthansa ma swoją siedzibę statutową w Köln-Deutz. Ta kombinacja przemysłu, mediów, ubezpieczeń i kilku aktorów regulacyjnych wytwarza rynek, w którym procesy intensywne dokumentacyjnie i audytowalne decyzje są codziennością. Dla polskich poddostawców Forda (Boryszew, KGHM, Polska branża automotive) i dla REWE Group jako właściciela polskiej Biedronki Kolonia jest kluczowym węzłem dokowania.

## Trzy wyzwania regulacyjne dla AI na rynku kolońskim

Pierwsza to nadzór ubezpieczeniowy dla DEVK, Gothaer i zlokalizowanych tu spółek reasekuracyjnych. Wymogi BaFin dla ryzyka modeli i raportowania Solvency II obowiązują dla każdego komponentu AI w obsłudze szkód, taryfikacji lub rezerwowaniu. Dla polskich ubezpieczycieli (PZU, Warta) odpowiedniki polskiej KNF są łagodniejsze.

Druga to blok compliance mediów i danych przy RTL i porównywalnych adresatach - Medienstaatsvertrag, specyfika RODO dla platform finansowanych reklamą i Digital Services Act wyznaczają wyraźne granice, co AI może zdziałać w logice rekomendacji i moderacji.

Trzecia to EASA relevance dla Lufthansy i jej partnerów MRO: Continuing Airworthiness, konserwacja Part-145 i wymogi Part-M muszą być dla komponentów AI w środowisku konserwacji wykazane w audytowalnej historii modelu. Dochodzi sam TÜV Rheinland jako podmiot certyfikujący, który dla wielu ocen zgodności istotnych z EU AI Act jest adresem fachowym - relacja, którą kolońskie firmy powinny zbudować wcześnie, bo ocena zgodności systemów AI wysokiego ryzyka leży w odpowiedzialności jednostek notyfikowanych takich jak TÜV. Także BLE w Bonn jako federalny urząd rolnictwa i żywności jest dla REWE i porównywalnych handlarzy żywności istotny, gdy komponenty AI znajdują zastosowanie w sterowaniu asortymentem lub ocenie dostawców. Kto w Kolonii buduje architekturę AI, planuje [Cert-Ready by Design](/pl/governance/eu-ai-act/) jako standard.

## Typowe scenariusze wdrożeń w Kolonii

Przy REWE Group i w szerszym handlu żywnością widzimy agentów asortymentu i łańcucha dostaw, którzy zagęszczają regionalne liczby sprzedaży, sezonowość i dane dostawców do propozycji dla Category Managera - z jasną dokumentacją, bo handel żywnością podlega jednocześnie wymogom LMIV i ustawie o łańcuchu dostaw. Przy Ford-Werke agenci pracują nad use cases planowania produkcji i danych jakościowych, w których Production Engineer podejmuje ostateczną decyzję. W środowisku ubezpieczeniowym przy DEVK i Gothaer agenci wspierają obsługę szkód ze strukturyzowanym wzbogacaniem zgłoszenia szkody o umowę, historię i opinię rzeczoznawcy. RTL Deutschland i Lanxess (dla compliance tworzyw sztucznych i chemii specjalnej) potrzebują Document Agents do analizy umów i kart charakterystyki. Przy samym TÜV Rheinland Knowledge Agents do zarządzania dokumentacją badań i tekstami norm są istotne - z jasnym wersjonowaniem i Audit Trail. Lufthansa i jej spółka córka MRO Lufthansa Technik pracują z Document Agents przy przygotowaniu dokumentacji konserwacji, w której Continuing Airworthiness Manager podejmuje ostateczną decyzję. Przy Toyota Deutschland w Köln-Marsdorf widzimy agentów service ticket i w zarządzaniu Recall logikę wzbogacania, która łączy dane VIN, historię warsztatową i compliance dostawców. Przy DEVK jako dużym ubezpieczycielu komunikacyjnym w Kolonii agenci obsługi szkód są szczególnie istotni, bo wolumen szkód z OC komunikacyjnej wymusza wysoką efektywność obsługi. Ostateczną decyzję w każdym przypadku podejmuje kwalifikowany inżynier kontrolujący, [Decision Layer](/pl/decision-layer/) trzyma uzasadnienie i ścieżkę.

## Jak Gosign obsługuje Kolonię z Hamburga i Krakowa

Gosign nie ma kolońskiej lokalizacji - towarzyszenie on-site organizujemy z Hamburga i Berlina. Bezpośrednie połączenie ICE Hamburg-Kolonia jest jednym z najszybszych w Republice, wizyty on-site są realizowalne w ciągu dnia. Konkretnie działa to tak: warsztaty discovery z Engineering, Compliance i Mitbestimmung robimy na miejscu w Köln-Mediapark, nad Renem lub bezpośrednio u klienta - najczęściej jako dwu- do trzydniowy blok. W fazie engineeringu łączymy pracę zdalną z dwutygodniowymi dniami on-site dla review architektury i aktualizacji dla stakeholderów. Briefingi TÜV Rheinland dla oceny zgodności EU AI Act zawsze odbywają się on-site, bo tu powstają relacje z audytorami, które później pomagają przy ocenie zgodności. Klastry jak Mediapark, Startplatz Köln i sieć AI kolońskiej IHK (największej Izby Przemysłowej i Handlowej Niemiec) są aktywnymi przestrzeniami dla networkingu technicznego, sesji audytorskich i kontaktów w nadreńskim mittelstandzie. Odległość Köln-Bonn jest wystarczająco mała, że terminy istotne dla EASA można zabrać w tym samym dniu - logistyka, która dla use cases związanych z lotnictwem oferuje wyraźną przewagę. Polscy dostawcy Forda i REWE (jako właściciel Biedronki) koordynowani są przez nasze [biuro w Krakowie](/pl/agenci-ai-krakow/). Więcej na stronie [usługi AI Agents](/pl/uslugi/ai-agents/).

## Dlaczego Kolonia to dobry punkt startowy dla Enterprise AI

Kto w Kolonii wprowadza use case AI na produkcję, ma przewagę obrony go w jednej z najważniejszych europejskich lokalizacji certyfikacyjnych - TÜV Rheinland siedzi na miejscu i dla wielu ocen zgodności EU AI Act jest naturalnym adresem. To znacząco przyspiesza późniejsze skalowanie, bo relacja audytowa budowana jest wcześnie. Dochodzi różnorodność branżowa - media, handel, ubezpieczenia, chemia, motoryzacja - która służy jako test przenośności architektury AI w różne reżimy compliance. Kolonia jest ponadto geograficznie blisko Dusseldorfu, Bonn i Renu-Mnichów, co upraszcza wieloregionalne terminy dla stakeholderów. Kto w 4-6 tygodni ma pierwszego Document Agenta z kompletnym Audit Trail w kolońskim koncernie produktywnie, ma tym samym referencję, którą TÜV Rheinland zna - co upraszcza późniejszą ocenę zgodności.

--- Agenci AI dla Firm w Krakowie | Gosign ---
> Enterprise AI Agents w Krakowie. Lokalne zarządzanie projektami, EU AI Act compliant by design, RODO-konform. Od PoC do samodzielnej operacji w 12-18 miesięcy.

## Kraków to stolica Global Capability Centers w Europie Środkowej - i właśnie dlatego najtrudniejszy rynek dla AI

Kraków skupia największą koncentrację Global Capability Centers w Europie Środkowej i Wschodniej. ABB Kraków prowadzi tu globalną dokumentację inżynieryjną, Cisco Kraków - jedno z największych centrów rozwoju oprogramowania poza USA, IBM Kraków - delivery center z tysiącami konsultantów, do tego ING Hubs Kraków, Capgemini, Motorola Solutions, EY GDS oraz polski Comarch. Wszystkie te ośrodki łączy jedno: przetwarzają dane z wielu jurysdykcji UE, a wyniki ich pracy trafiają do ksiąg zachodnioeuropejskich spółek-matek. Każda decyzja podejmowana przez AI musi jednocześnie spełniać wymogi polskiego UODO, RODO oraz regulatorów krajów, z których pochodzą dane. Kraków nie jest tylko polskim miastem - to maszynownia europejskich koncernów.

## Trzy wyzwania regulacyjne dla AI na rynku krakowskim

Po pierwsze RODO i polska ustawa o ochronie danych osobowych. UODO (Urząd Ochrony Danych Osobowych) przy zautomatyzowanym podejmowaniu decyzji oczekuje udokumentowanych podstaw, możliwych do wywołania wyjaśnień oraz pełnego Audit Trail. Ponieważ krakowskie GCC przetwarzają dane z Niemiec, Francji, Holandii i krajów skandynawskich, każda decyzja AI musi dodatkowo spełniać wymogi narodowych organów nadzoru w tych krajach - architektura, która spełnia tylko RODO, w shared services dla zachodnich koncernów to za mało.

Po drugie nadzór KNF (Komisja Nadzoru Finansowego) nad rosnącą liczbą banking i insurance operations w Krakowie. ING Hubs Kraków, Aon, Brown Brothers Harriman i inni dostawcy usług finansowych podlegają bezpośredniemu lub pośredniemu nadzorowi KNF. Przy transaction monitoring, AML screening i underwriting KNF oczekuje tych samych dowodów co BaFin czy holenderski DNB - łącznie ze śledzonymi podstawami modeli i protokołowaną ostateczną decyzją człowieka. Dodatkowo od 2026 obowiązuje KSeF (Krajowy System e-Faktur), który dla każdego krakowskiego GCC obsługującego polskie podmioty oznacza obowiązkową integrację i pełną automatyzację obiegu faktur.

Po trzecie EU AI Act, który w Polsce od lutego 2025 obowiązuje w zakresie zakazanych praktyk, a od 2 sierpnia 2026 r. - dla systemów wysokiego ryzyka (to obowiązujący termin; wstępnie uzgodnione przesunięcie na 2 grudnia 2027 r. - Digital Omnibus, maj 2026, przyjęcie w toku). HR screening, ocena zdolności kredytowej i identyfikacja biometryczna trafiają do kategorii wysokiego ryzyka. Krakowskie centra, które takie systemy budują lub eksploatują dla spółek-matek, muszą wykazać oceny zgodności, zarządzanie ryzykiem i post-market monitoring - to dług techniczny, którego nie da się nadrobić ex post.

## Typowe scenariusze wdrożeń w Krakowie

Comarch Banking Software QA: pakiet bankowy Comarchu jest używany przez setki polskich i środkowoeuropejskich instytucji finansowych. Document Agents weryfikują release notes, aktualizacje regulacyjne i dokumentację łatek względem wymogów KNF, zanim release trafi do klienta - z pełnym Audit Trail aż do źródłowego pull requesta.

ABB Kraków - dokumentacja inżynieryjna: globalne centrum inżynieryjne ABB w Krakowie generuje codziennie tysiące dokumentów technicznych w wielu językach. Workflow Agents wyłapują specyfikacje istotne regulacyjnie, porównują je z normami krajowymi i automatycznie kierują konflikty do recenzentów.

ING Hubs - transaction monitoring: w shared service ING z milionami transakcji dziennie każda sekunda opóźnienia decyduje o terminach raportowania regulacyjnego. Decision Layer kieruje przypadki podejrzane w ramach progów KNF i DNB, z wymuszonym Human-in-the-Loop przy każdej finalnej eskalacji.

Capgemini - delivery operations: krakowskie zespoły obsługują dużych klientów z wielu krajów UE. Agenty service desk klasyfikują tickety według języka, klienta i ścieżki eskalacji - każda decyzja audytowalna względem obowiązującego standardu regulacyjnego.

## Jak Gosign obsługuje Kraków z lokalnego biura w Krakowie

Gosign ma własne biuro w Krakowie (gosign.pl) z polskojęzycznymi kierownikami projektów, inżynierami i osobami odpowiedzialnymi za compliance - native polish i english speakerzy, którzy pracują bezpośrednio u klienta w Krakow Technology Park, Hub:raum lub w pomieszczeniach spółki-matki. Discovery workshops, sprint reviews i steering committee odbywają się bez bariery językowej i bez kosztów podróży, przedstawiciel Rady Zakładowej siedzi w tej samej sali. Kraków pełni rolę regional hub dla całej Polski: większość lokalizacji ABB, Cisco, Capgemini i IBM jest osiągalna w obrębie tego samego miasta, Warszawa, Wrocław i Gdańsk - w ciągu jednego dnia. Hamburska centrala dostarcza review architektoniczne, ekspertyzę DACH compliance i połączenie ze spółkami-matkami w Niemczech czy Szwajcarii - delivery, codzienna praca i bezpośredni kontakt z klientem leżą po stronie krakowskiego zespołu. Dla kraju z ponad 350 tysiącami inżynierów IT to jedyne ustawienie, które naprawdę działa: lokalnie zakorzenione, łączące się z całą Unią. Więcej o naszym podejściu na stronie [usługi AI Agents](/pl/uslugi/ai-agents/).

## Dlaczego Kraków to dobry punkt startowy dla Enterprise AI

Kraków ma trzy cechy, które czynią go wyjątkowym punktem startowym. Po pierwsze gęstość talentów: Krakow Technology Park, Hub:raum i Krakow Startups Cluster tworzą największy ekosystem technologiczny między Berlinem a Wiedniem, z tysiącami inżynierów wielojęzycznych i wytrenowanych na procesach koncernowych. Po drugie wielo-jurysdykcyjna rzeczywistość: kto zbuduje agenta AI w Krakowie zgodnego z wymogami ABB, Cisco czy ING, ten implicite zbudował go dla całej UE Zachodniej. Architektura, która w krakowskim GCC jednocześnie spełnia wymogi UODO, holenderskiego DNB i niemieckiej BaFin, w każdym innym kraju UE to już tylko kwestia konfiguracji. Po trzecie dojrzałość operacyjna: krakowskie GCC współpracują z zachodnimi koncernami od ponad piętnastu lat, wewnętrzne procesy change management, ITIL, ISO 27001 i SOX są dobrze zorganizowane. Wprowadzenie nowego komponentu Decision Layer to nie nauka nowej dyscypliny compliance, lecz rozszerzenie istniejącej o dodatkową warstwę kontroli.

Cert-Ready by Design w tym otoczeniu nie jest hasłem marketingowym, lecz warunkiem pierwszego dnia eksploatacji. Kto zaczyna w Krakowie, ma najtrudniejszy test już za sobą, zanim pierwsza zachodnioeuropejska spółka córka zostanie uruchomiona - a kto zbudował w Krakowie wytrzymałego eksploatacyjnie agenta AI, ten może go wdrożyć w Warszawie, Wrocławiu czy Gdańsku w ciągu kilku tygodni, ponieważ techniczny fundament pozostaje identyczny i zmieniają się tylko pliki konfiguracyjne dla danego regulatora. Więcej kontekstu o [EU AI Act](/pl/governance/eu-ai-act/) i jego stosowaniu w Polsce znajdziesz w sekcji Governance. Architektura [Decision Layer](/pl/decision-layer/) jest tu sercem całego systemu.

--- Agenci AI w Kurytybie - Polonia Brazylijska + DACH-Standards | Gosign ---
> Enterprise AI Agents dla firm polskich i polonijnych w Kurytybie - stolicy Polonii Brazylijskiej. 90 000 osób polskiego pochodzenia, polskie firmy IT, BPCC i Polonicus. LGPD + RODO w jednym Audit Trail.

## Stolica Polonii Brazylijskiej - i punkt wejścia polskich firm na rynek LATAM

Curitiba to nie "kolejne brazylijskie miasto". Polskie konsulaty i Senat RP nazywają ją oficjalnie **stolicą Polonii Brazylijskiej**. W mieście żyje około 90 000 osób polskiego pochodzenia (źródło: raport ZPP "Sprowadźmy Polaków z Brazylii" 2019), w całej Paranie - 1,5 do 3 mln. Konsulat Generalny RP w Kurytybie działa od **1919 roku** - drugi najstarszy polski konsulat na półkuli zachodniej, starszy niż w Nowym Jorku. Federacja Polbras (od 1989) i Brasil-Polônia Câmara de Comércio (BPCC) tworzą sieć biznesową, której nie ma żadne inne brazylijskie miasto. Dla polskich firm wchodzących na LATAM oznacza to coś, czego São Paulo czy Rio nie oferują: dwujęzyczny basen talentów IT (PUC-PR, UFPR), Karta Polaka jako narzędzie mobilności i lokalna sieć, która od stu lat rozumie polską kulturę biznesową.

## Volvo, Renault, Klabin, Boticário - przemysłowy ekosystem klasy DACH

Korytarz przemysłowy Kurytyby i São José dos Pinhais wygląda jak Wolfsburg-Stuttgart-Monachium w wersji tropikalnej: Volvo do Brasil (ciężarówki, autobusy), Renault Brasil (Complexo Ayrton Senna), Volkswagen i Audi tuż obok. [Klabin](https://www.klabin.com.br/) - największy brazylijski producent papieru, modelowa firma ESG. Boticário Group - druga co do wielkości sieć kosmetyczna Brazylii. Positivo Tecnologia i Bematech tworzą klaster tech. Tu europejskie standardy przemysłowe są już lokalnym językiem - co radykalnie skraca przejście z PoC w Paranie do rolloutu w Wolfsburgu, Stuttgarcie czy Göteborgu.

## Trzy konkretne use case'y które obsługujemy w Paranie

**Volvo / Renault Supply Chain**: Document Agents czytają deklaracje celne i świadectwa pochodzenia Mercosul, [Decision Layer](/pl/decision-layer/) eskaluje konflikty kwot do zakupów - z Audit Trail aż do rekordu dostawcy. Przy operacjach z trasami przez Argentynę, Urugwaj i Paragwaj dokumentacja pochodzenia jest najbardziej krytycznym tematem celnym Mercosul.

**Boticário CRM** (LGPD-skala): Workflow Agents przetwarzają kontakty klientów z aplikacji i ponad miliona Revendedoras, zestawiają LGPD-compliant ze statusem zgód, a Decision Layer routuje kampanie z Human-in-the-Loop. Audit Trail sięga pojedynczego opt-in.

**Klabin ESG-Reporting**: Document Agents agregują inwentarz leśny i bilanse CO₂ do raportów FSC, GRI, SASB. Decision Layer oznacza luki danych do walidacji ludzkiej - każda agregacja z prześledzalnym pochodzeniem. Dla polskich spółek GPW z portfelem ESG (KGHM, PKN Orlen) ta głębia audytu jest warunkiem CSRD.

## Jeden Audit Trail dla LGPD + RODO

LGPD (Lei 13.709/2018) i RODO są w ~80% strukturalnie identyczne, ale różnice są krytyczne: ANPD (Brasília) vs UODO (Warszawa) jako organ nadzorczy, kara 2% obrotu BR vs 4% globalnego, profilowanie Art. 20 LGPD vs Art. 22 RODO, notyfikacja naruszenia "rozsądny okres" vs 72h. Dla polskiej firmy macierzystej z brazylijskim oddziałem oznacza to dwa równoległe rejestry (RoPA EU + Registro de Tratamento BR). Nasz Decision Layer pisze synchronicznie do obu, eskaluje do polskiego DPO i brazylijskiego DPO równolegle, generuje raporty w formatach obu organów (UODO XML, ANPD CSV per Rezolucja 4/2023). [Więcej o EU AI Act + RODO](/pl/governance/eu-ai-act/).

## Jak współpracujemy: Kraków - Hamburg - São Paulo - Kurytyba

[Biuro São Paulo](/pl/agenci-ai-sao-paulo/) jest godzinę lotu od Kurytyby. Discovery on-site w zakładach Volvo, Renault, Klabin lub Boticário organizujemy w ciągu 24 godzin. Build działa rozproszenie Hamburg-São Paulo (4h różnicy, standupy rano czasu SP). Polski koordynator w Krakowie obsługuje raportowanie do macierzy. Karta Polaka rekrutowana przez Konsulat Generalny w Kurytybie sprawia że programiści mogą rotować PL↔BR bez wizy. Więcej o podejściu: [usługi AI Agents](/pl/uslugi/ai-agents/).

--- Agenci AI dla Firm w Lizbonie | Gosign ---
> Enterprise AI Agents w Lizbonie. EU AI Act bezpośrednio stosowany, RODO konform. Lokalne zarządzanie projektami. Od PoC do samodzielnej operacji.

## Lizbona to najszybciej rosnąca stolica Tech Europy - z zaskakująco surowym reżimem ochrony danych

W ostatnich dziesięciu latach Lizbona przeszła drogę od turystycznego tajnego tropu do hubu tech dla Europy Zachodniej. EDP (Energias de Portugal) i Galp Energia tworzą rdzeń energetyczny, Millennium BCP i Caixa Geral de Depósitos kręgosłup bankowy, Jerónimos Martins (Pingo Doce, Recheio, Biedronka w Polsce) to największy handlarz żywności kraju. NOS i Altice Portugal dominują krajobraz telekomunikacyjny. Dochodzą portugalscy Tech Champions Farfetch (marketplace luksusowej mody), OutSystems (platforma Low-Code z globalną skalą) i Feedzai (fraud detection AI dla banków na całym świecie). W Beato Innovation District i w Hub Criativo do Beato siedzą setki startupów - miasto ściąga talent z całej Europy, bo koszty utrzymania są niższe niż w Berlinie czy Amsterdamie, a ekosystem tech się zagęszcza. Dla polskiego biznesu najważniejszy kontekst to Jerónimos Martins: właściciel Biedronki, największej polskiej sieci handlowej z ponad 3500 sklepami. Decyzje AI w portugalskiej centrali mają bezpośrednie implikacje dla polskich pracowników i łańcuchów dostaw.

## Trzy wyzwania regulacyjne dla AI na rynku portugalskim

Po pierwsze CNPD (Comissão Nacional de Protecção de Dados) wraz z Lei 58/2019, portugalską ustawą wdrażającą RODO. CNPD jest jednym z najbardziej konsekwentnych organów ochrony danych w Europie Południowej i w ostatnich latach nałożyła kilka wysokich kar na firmy telekomunikacyjne, banki i instytucje publiczne. CNPD bada systemy AI szczególnie pod kątem przejrzystości, minimalizacji danych i prawa do decyzji człowieka zgodnie z Art. 22 RODO. Kto buduje AI w Lizbonie, buduje dla organu, który traktuje audyty algorytmów poważnie. Dla Biedronki (Jerónimos Martins) oznacza to: decyzje AI wpływające na polskich pracowników mogą teoretycznie trafić pod kontrolę CNPD i UODO równolegle.

Po drugie EU AI Act, który w Portugalii jest bezpośrednio stosowany. Rząd portugalski wyznaczył ANACOM (Autoridade Nacional de Comunicações) i CNPD jako organy koordynujące wdrożenie EU AI Act, z planem zbudowania własnego organu nadzoru rynku. Systemy wysokiego ryzyka - w szczególności w sektorze energetycznym i finansowym - będą od 2026 systematycznie kontrolowane.

Po trzecie Banco de Portugal i CMVM (Comissão do Mercado de Valores Mobiliários) dla wszystkich usługodawców finansowych. Oba organy sformułowały wspólne oczekiwania dotyczące AI Model Governance: wyjaśnialność, Audit Trail, reprodukowalność, bias mitigation. Banki jak Millennium BCP i Caixa Geral de Depósitos już pracują nad odpowiednimi frameworkami. [Compliance EU AI Act](/pl/governance/eu-ai-act/) i nadzór finansowy zazębiają się tu ze sobą.

## Typowe scenariusze wdrożeń w Lizbonie

Millennium BCP stosuje AI w analizie kredytowej dla klientów MŚP i potrzebuje modeli, które pod nadzorem CNPD i Banco de Portugal pozostają reprodukowalne - każda odmowa musi być w ustawowym terminie uzasadnialna. EDP eksploatuje infrastrukturę smart meterów w Portugalii, Hiszpanii i Brazylii i wykorzystuje AI do prognoz obciążenia i wykrywania anomalii w sieci elektrycznej - modele muszą być dokumentowane dla organu nadzoru energii ERSE. Feedzai rozwija modele fraud detection dla banków na całym świecie, z siedzibą w Lizbonie - każda aktualizacja modelu musi pozostać prześledzalna w Audit Trail, bo klienci wchodzą na produkcję w regulowanych rynkach. Farfetch wykorzystuje algorytmy rekomendacji dla produktów luksusowych w ponad 190 krajach - tu kolidują wymogi CNPD z reżimami ochrony danych UK, USA i Chin.

Jerónimos Martins - kontekst Biedronki: sieć z ponad 3500 sklepami w Polsce, która coraz bardziej stosuje AI w sterowaniu asortymentem, planowaniu zmian i ocenie pracowników. Każda decyzja zapada formalnie w Lizbonie pod portugalską Lei 58/2019, ale dotyka polskich pracowników z polską Radą Zakładową i polskim UODO. Architektura, która to obsługuje czysto, musi routować decyzje przez dwa reżimy równolegle.

We wszystkich scenariuszach chodzi o modele AI, które nie żyją w laboratorium, lecz w regulowanej logice biznesowej z mierzalnymi konsekwencjami. [Decision Layer](/pl/decision-layer/) rozwiązuje kwestię architektury: Audit Trail aż do poziomu SQL, Human-in-the-Loop przy przypadkach podlegających eskalacji, Cert-Ready by Design.

Portugalska specyfika to Comissão de Trabalhadores - reprezentacja pracowników z prawami informacyjnymi i konsultacyjnymi przy wprowadzaniu systemów AI. Model zakresowo podobny do polskiej Rady Zakładowej (konsultacje bez weta) - istotna zbieżność ułatwiająca polskim menedżerom współpracę.

## Jak Gosign obsługuje Portugalię z biura w Lizbonie

Gosign ma własne biuro w Lizbonie (gosign.pt) z portugalskim zespołem - native speakerzy, lokalne zarządzanie projektami, bezpośredni kontakt z CNPD, Banco de Portugal i CMVM. Biuro w Lizbonie pełni rolę regional hub dla portugalskiego rynku: warsztaty discovery, sprint reviews i steering odbywają się na miejscu u klienta w Beato Innovation District, w Hub Criativo do Beato lub bezpośrednio w centralach koncernowych Galp Energia, EDP, Millennium BCP, Caixa Geral de Depósitos i Jerónimo Martins. Dla portugalskich Tech Champions Feedzai, OutSystems i Farfetch pracujemy na poziomie oczu w lokalnej kulturze engineering, z warsztatami i code reviews po portugalsku, dokumentacją compliance po portugalsku i angielsku, Comissão de Trabalhadores od początku przy stole. Dla polskich klientów z ekspozycją portugalską (dostawcy Biedronki, Comarch dla portugalskich banków) koordynację zapewnia nasze [biuro w Krakowie](/pl/agenci-ai-krakow/) - polskojęzyczny PM po stronie polskiego partnera, portugalskojęzyczny delivery po stronie portugalskiej centrali. Przy projektach LATAM zespół z Lizbony dodatkowo łączy się z biurem São Paulo (gosign.com.br) - Brazylia i Portugalia jako spójny rynek lusofoński, ze wspólnym językiem, wspólną kulturą biznesową i architekturą obsługującą LGPD i RODO równolegle. Hamburska centrala przejmuje architektoniczne kwestie zasadnicze i połączenie z niemieckimi oraz północnoeuropejskimi koncernami macierzystymi. Więcej o naszym podejściu na stronie [usługi AI Agents](/pl/uslugi/ai-agents/).

## Dlaczego Lizbona to dobry punkt startowy dla Enterprise AI

Portugalia jest dostatecznie mała, żeby w projekcie AI bezpośrednio włączyć wielu branżowych stakeholderów, i wystarczająco duża, żeby mieć realne wymogi compliance. Kto w Lizbonie buduje pilotaż Cert-Ready by Design, ma referencję, która ostała się pod standardami CNPD i EU AI Act - i która następnie w Brazylii (LGPD), Hiszpanii (LOPDGDD) i reszcie Europy jest do obrony. Lisbon Tech Hub, Startup Lisboa i Beato Innovation District dostarczają talent, dostęp do inwestorów i partnerów pilotażowych.

Wnosimy doświadczenie budowy systemów AI, które pozostają produktywne nawet pod surowym nadzorem CNPD - z Governance by Design i dyscypliną, którą kształtuje niemiecka praktyka ochrony danych. Lizbona jest właściwym rynkiem, by tę dyscyplinę skalować na Półwyspie Iberyjskim. A dla firm, które wykorzystują rynek portugalski jako trampolinę do przestrzeni lusofońskiej (Brazylia, Angola, Mozambik), Lizbona jest jedyną europejską lokalizacją, z której taki most da się zbudować architektonicznie czysto.

--- Agenci AI dla Firm w Londynie | Gosign ---
> Enterprise AI Agents dla Londynu. UK GDPR + EU RODO dual-compliance, FCA-aware. Audytowalne AI dla City i nie tylko.

## W Londynie każda decyzja AI musi jednocześnie spełniać dwa reżimy ochrony danych - to najdroższa luka compliance Europy

Od Brexitu Londyn nie jest już centrum finansowym UE, lecz compliance-owym doppelkopfem Europy. HSBC, Barclays, Lloyds Banking Group, NatWest, Standard Chartered i Prudential prowadzą tu swoje centrale koncernowe. BP i Shell mają w Londynie globalną siedzibę, AstraZeneca koordynuje stąd badania kliniczne na całym świecie, a w obszarze tech siedzą Revolut, DeepMind i ARM Holdings. "Square Mile" jest nadal największym centrum finansowym Europy i prawdopodobnie jedynym rynkiem, w którym jedna firma musi jednocześnie przestrzegać regulacji UK, UE i amerykańskiego reżimu sankcyjnego - często w tym samym systemie. Kto buduje tu Enterprise AI, buduje nie dla jednej jurysdykcji, lecz dla przecięcia zbiorów. Dla polskich pracowników w City (a ich są tysiące) i polskich firm B2B obsługujących londyńskie banki (Asseco, Comarch) ta podwójność jest codzienną rzeczywistością operacyjną.

## Trzy wyzwania regulacyjne dla AI na rynku londyńskim

Po pierwsze podwójny reżim ochrony danych UK GDPR plus EU GDPR. Od Brexitu dla brytyjskich firm obowiązuje UK GDPR, ale gdy firma ma biznes z klientami UE - co praktycznie wszystkie koncerny londyńskie mają - obok wchodzi EU RODO przez mechanizm Adequacy. ICO (Information Commissioner's Office) kontroluje stronę UK, a za stronę UE zależnie od spółki zależnej UE odpowiada inny organ nadzorczy. Oba reżimy w kwestiach szczegółowych odbiegają od siebie i oba się rozchodzą - np. przy zautomatyzowanych decyzjach zgodnie z Art. 22 lub mechanizmach transferu danych. Kto tu buduje architekturę AI, musi być dual-compliant. Dla polskich firm z ekspozycją na UK oznacza to dodatkową warstwę wobec polskiego UODO i RODO.

Po drugie UK AI White Paper, który przewiduje podejście sektorowe, zamiast - jak EU AI Act - ustawy horyzontalnej. FCA (Financial Conduct Authority), PRA (Prudential Regulation Authority), ICO i CMA (Competition and Markets Authority) rozwijają własne wytyczne AI dla swojego sektora. FCA z AI Public-Private Forum sformułowała już konkretne oczekiwania dotyczące Model Governance, wyjaśnialności i odpowiedzialności zarządu. Kto w Londynie buduje banking AI, buduje dla co najmniej czterech nadzorców jednocześnie - w różnej głębi. To znacznie bardziej rozbudowany krajobraz niż polska KNF + UOKiK.

Po trzecie DSA i DMA dla platform londyńskich z biznesem w UE. Kto z Londynu adresuje europejskich konsumentów, podpada pod unijną regulację platform - niezależnie od prawa UK. [Compliance EU AI Act](/pl/governance/eu-ai-act/) staje się tu interfejsem: brytyjskie firmy z istotnym biznesem UE muszą zachowywać się praktycznie jak firmy UE, bez ochrony członkostwa w UE.

## Typowe scenariusze wdrożeń w Londynie

HSBC prowadzi globalny fraud detection z modelami AI, które są produktywne w ponad 60 krajach i muszą jednocześnie ostać się wobec FCA, ICO, nadzoru UE i amerykańskiego OCC. Lloyd's of London wykorzystuje AI do decyzji underwritingowych w ubezpieczeniach specjalistycznych - każda zautomatyzowana ocena ryzyka musi być udokumentowana wobec Lloyd's Performance Management Directorate i w razie szkody reprodukowalna. Sama FCA wymaga od swoich regulowanych firm compliance Conduct Rule z narzędziami AI, które muszą czynić odpowiedzialność zarządu prześledzalną. AstraZeneca dokumentuje badania kliniczne dla MHRA i równolegle dla EMA - każde wspomagane AI oszacowanie musi być wykazywalne w obu reżimach.

We wszystkich scenariuszach centralne pytanie brzmi nie "czy model działa?", lecz "czy potrafimy obronić decyzję międzyjurysdykcyjnie?". [Decision Layer](/pl/decision-layer/) rozwiązuje dokładnie to: routuje każdą decyzję przez zestawy reguł specyficzne dla jurysdykcji, persystuje Audit Trail z kompletnymi metadanymi i egzekwuje Human-in-the-Loop przy decyzjach istotnych kontrolnie w wielu reżimach.

Dochodzą nadzorcy osobiści: UK Senior Managers and Certification Regime (SMCR) czyni pojedynczych członków zarządu osobiście odpowiedzialnymi za decyzje AI w ich obszarach. Kto jako dyrektor brytyjskiej firmy finansowej wprowadza AI bez możliwości dokumentowania Model Governance, ryzykuje osobisty ban z branży. To stopień ostrzejszy niż kary RODO na kontynencie - i powód, dla którego brytyjskie banki od lat traktują Cert-Ready by Design poważnie.

## Jak Gosign obsługuje Londyn z Hamburga i Krakowa

Hamburg-Londyn to bezpośredni lot około 90 minut, codziennie kilka połączeń przez LH, BA i EasyJet. Pracujemy remote-first z klientami w City i Canary Wharf, z warsztatami on-site dla discovery, decyzji architektonicznych i krytycznych review compliance. Językiem pracy jest angielski, steering z naszymi architektami w Hamburgu prowadzony po niemiecku. Strefa czasowa (Londyn GMT/BST, godzina za CET) jest manageable i pokrywa się w pełni z naszym dniem roboczym w Hamburgu. Dla polskich firm dostarczających do londyńskich banków (Asseco, Comarch, polskie fintechy) koordynacja przez nasze [biuro w Krakowie](/pl/agenci-ai-krakow/) - polskojęzyczny PM, angielskojęzyczny delivery on-site w Londynie.

Co wnosimy z niemieckiego i polskiego rynku, to doświadczenie z podwójną regulacją. Niemieckie banki pracują standardowo z BaFin, EZB i FCA jednocześnie - logika compliance międzyjurysdykcyjnego jest nam znajoma. Znamy oczekiwania FCA wobec Model Governance dostatecznie dobrze, żeby przy pierwszym warsztacie podejmować konkretne decyzje architektoniczne, zamiast najpierw tłumaczyć regulatorów. Więcej o naszym podejściu na stronie [usługi AI Agents](/pl/uslugi/ai-agents/).

## Dlaczego Londyn to dobry punkt startowy dla Enterprise AI

Londyn ma najwyższą presję regulacyjną dla AI w Europie, bo spotykają się tu dwa rozchodzące się reżimy ochrony danych. Kto w Londynie buduje pilotaż Cert-Ready by Design, który jest dual-compliant, ma referencję, która w każdym innym rynku jest do obrony - włącznie z USA, Szwajcarią i APAC. Klaster Silicon Roundabout, Canary Wharf, program London Tech City i sieć Tech Nation dostarczają talent, ekosystem i partnerów pilotażowych.

Druga zaleta: Londyn wymusza architekturę zbudowaną nie dla jednej jurysdykcji, lecz dla zestawów reguł specyficznych dla jurysdykcji nad tym samym Audit Trail. To Governance by Design - a jeśli działa w Londynie, działa wszędzie. Hamburg dostarcza niemiecką dyscyplinę engineeringu, Kraków polskojęzyczne wsparcie, a Londyn globalny stress test compliance.

--- Agenci AI dla Firm w Madrycie | Gosign ---
> Enterprise AI Agents dla Madrytu. Siedziba AESIA, regulacja EU AI Act, RODO + LOPDGDD. Audytowalne agenty dla centrum biznesowego Hiszpanii.

## Madryt to jedyna europejska stolica, w której krajowi regulatorzy ochrony danych i finansów siedzą w zasięgu pieszego spaceru

Kto buduje Enterprise AI w Madrycie, buduje dosłownie pod drzwiami hiszpańskiego nadzoru. AEPD (Agencia Española de Protección de Datos), CNMV (Comisión Nacional del Mercado de Valores), Banco de España i CNMC (Comisión Nacional de los Mercados y la Competencia) - wszystkie cztery mają siedzibę w Madrycie. Dochodzi aparat polityczny: Ministerio de Asuntos Económicos i Ministerio de Industria, Comercio y Turismo decydują tu o wdrożeniu EU AI Act. W sektorze korporacyjnym siedzą Banco Santander, BBVA, Telefónica, Repsol, Iberdrola (HQ Bilbao, ale Madryt jest operacyjnie silny), Mapfre, Ferrovial, ACS, Naturgy, Red Eléctrica i Amadeus IT. Kto buduje tu architekturę AI, buduje dla koncentracji Big Corporates i organów nadzoru, której w Europie porównywalnej mają tylko Frankfurt i Paryż. Dla polskich inwestorów z ekspozycją iberyjską (Orlen, KGHM z segmentem retail) Madryt jest kluczowym węzłem regulacyjnym - decyzje zapadające w czterech organach nadzoru, które siedzą w odległości metra, mają wpływ na całą iberyjską rzeczywistość operacyjną.

## Trzy wyzwania regulacyjne dla AI na rynku madryckim

Po pierwsze AEPD i LOPDGDD (Ley Orgánica 3/2018), hiszpańska ustawa wdrażająca RODO z zaostrzeniami. AEPD w całej UE jest znana ze swojej restrykcyjnej interpretacji Art. 22 RODO - w pełni zautomatyzowane decyzje są w Hiszpanii praktycznie dopuszczalne tylko przy udokumentowanej ostatecznej decyzji człowieka. Organ w ostatnich latach nałożył kilka kar w ośmio- i dziewięciocyfrowym zakresie euro, często wobec banków i firm telekomunikacyjnych. To znacznie bardziej agresywna postawa niż polskie UODO. Decision Layer z Human-in-the-Loop nie jest tu opcjonalny, lecz warunkiem compliance.

Po drugie AESIA (Agencia Española de Supervisión de la Inteligencia Artificial). Hiszpania jest pierwszym krajem UE z dedykowanym organem nadzoru AI. Główna siedziba leży w La Coruñi, ale operacyjnie i politycznie wiele rozstrzyga się w Madrycie. AESIA od 2026 systematycznie kontroluje systemy wysokiego ryzyka zgodnie z EU AI Act i może orzekać zakazy działania. Kto w Madrycie wprowadza modele na rynek, musi od początku dokumentować pod kątem audytu AESIA. Polska nie ma jeszcze odpowiednika AESIA - to luka, którą hiszpańskie firmy wykorzystują jako przewagę regulacyjną w UE.

Po trzecie CNMV i Banco de España dla całego sektora finansowego. Oba organy sformułowały wspólne oczekiwania co do AI Model Governance i kontrolują banki, ubezpieczycieli i asset managerów pod kątem wyjaśnialności, Audit Trail i reprodukowalności. CNMV od 2024 wymaga przy rekomendacjach inwestycyjnych wspomaganych AI kompletnego Audit Trail. [Compliance EU AI Act](/pl/governance/eu-ai-act/) i nadzór finansowy zazębiają się tu ze sobą.

## Typowe scenariusze wdrożeń w Madrycie

Banco Santander prowadzi ocenę kredytową w ponad 10 krajach i potrzebuje modeli AI, które pod nadzorem AEPD, CNMV i Banco de España pozostają reprodukowalne - każda odmowa musi być w ustawowym terminie uzasadnialna. Telefónica analizuje dane CDR (Call Detail Records) do wykrywania nadużyć i optymalizacji sieci w ponad 12 rynkach - modele muszą pozostać audytowalne wobec AEPD i ANACOM. Mapfre stosuje AI w obsłudze szkód i potrzebuje modeli, które czynią każdą zautomatyzowaną ocenę wysokości szkody uzasadnialną wobec ubezpieczonych. Iberdrola planuje w Madrycie operacje sieci elektrycznej, które podpadają pod kategorie wysokiego ryzyka EU AI Act - modele muszą być dokumentowane dla Red Eléctrica i krajowego nadzoru energii CNMC.

W każdym z tych przypadków [Decision Layer](/pl/decision-layer/) jest architekturą, która łączy Audit Trail aż do poziomu SQL, eskalację Human-in-the-Loop i Cert-Ready by Design - dokładnie to, czego madryckie organy nadzoru chcą widzieć jednocześnie.

Madrycka specyfika to złożoność koncernów: większość dużych hiszpańskich firm jest poza iberoamerykę rozgałęziona - Santander w 10+ krajach, BBVA w Meksyku i Turcji, Telefónica w Brazylii i Niemczech. Architektura AI w Madrycie musi być w stanie egzekwować zestawy reguł specyficzne dla jurysdykcji dla RODO, LGPD, meksykańskiego LFPDPPP i tureckiego KVKK jednocześnie - wszystko nad tym samym Audit Trail. Kto to buduje w Madrycie, ma architekturę dla całego hispanofońskiego świata.

## Jak Gosign obsługuje Madryt z Barcelony

Gosign obsługuje projekty madryckie z biura w Barcelonie (gosign.es) z hiszpańskojęzycznymi kierownikami projektów i inżynierami. Połączenie szybkiej kolei AVE Barcelona-Madryt trwa niecałe dwie i pół godziny - cotygodniowe terminy on-site w Santanderze, BBVA, Telefónice, Mapfre, Iberdroli i Repsolu to nie nakład logistyczny, lecz rutyna. Warsztaty discovery, sprint reviews i steering odbywają się na miejscu na Paseo de la Castellana, w Las Tablas lub bezpośrednio w centralach koncernowych, z hiszpańskojęzycznymi osobami odpowiedzialnymi i przedstawicielami Comité de Empresa przy tym samym stole. Madryt jest siedzibą najważniejszych regulatorów ES - AEPD, CNMV, Banco de España i CNMC są w zasięgu pieszego spaceru - a zespół hiszpański jest regularnie na miejscu, żeby bezpośrednio prowadzić uzgodnienia regulacyjne, przygotowania do audytów i terminy sandbox. Polscy inwestorzy z ekspozycją iberyjską koordynowani są przez nasze [biuro w Krakowie](/pl/agenci-ai-krakow/) - polskojęzyczny PM po stronie polskiej, hiszpańskojęzyczny delivery po stronie Madrytu. Hamburska centrala przejmuje koordynację DACH i międzynarodową oraz review architektoniczne. Więcej na stronie [usługi AI Agents](/pl/uslugi/ai-agents/).

## Dlaczego Madryt to dobry punkt startowy dla Enterprise AI

Madryt jest jedynym miastem w Europie, w którym wszystkie cztery hiszpańskie organy nadzoru można dotrzeć pieszo - i w którym większość odpowiedzi regulacyjnych jest dostępna w ciągu kilku dni zamiast tygodni. Kto buduje tu pilotaż Cert-Ready by Design, ma referencję, która ostała się pod standardami AEPD, AESIA, CNMV i Banco de España. Klastry Madrid in Motion, Impact Hub Madrid i Wayra Madrid (Telefónica) dostarczają talent, partnerów pilotażowych i dostęp do inwestorów.

Wnosimy z niemieckiego i polskiego rynku doświadczenie budowy systemów AI, które pod surowymi reżimami nadzoru nie tylko działają, ale pozostają produktywne - z Governance by Design i Audit Trail. Madryt jest właściwym rynkiem, żeby tę dyscyplinę wnieść w serce hiszpańskiej gospodarki.

--- Agenci AI dla Firm w Niemczech | Gosign ---
> Enterprise AI Agents dla firm niemieckich. RODO-konform, EU AI Act compliant. Siedziba Hamburg, biuro Berlin. Gosign GmbH.

## Niemcy to rynek domowy Gosign - i rynek UE z najwyższą gęstością compliance

Niemcy łączą trzy właściwości, które w tej formie nie istnieją w żadnym innym kraju UE: maksymalną gęstość koncernów w wielu branżach, wiążące prawo współdecydowania Rady Zakładowej (Betriebsrat) zgodnie z § 87 ust. 1 pkt 6 BetrVG oraz federalną strukturę nadzoru z BaFin, BSI, BfDI i szesnastoma dodatkowymi krajowymi organami ochrony danych. Krajobraz koncernowy rozciąga się od motoryzacji (VW, BMW, Daimler, Porsche, Continental, Bosch, ZF), przez chemię (BASF, Bayer, Evonik, Merck, Covestro), budowę maszyn (Siemens, Trumpf, Dürr, Kuka, Festo), bankowość (Deutsche Bank, Commerzbank, Sparkassen, Volks- und Raiffeisenbanken), ubezpieczenia (Allianz, Munich Re, Ergo, HDI, R+V), energetykę (RWE, E.ON, EnBW) po handel (Otto, Zalando, Lidl/Kaufland, Rewe, Edeka). Dla polskich spółek-córek niemieckich koncernów oraz polskich firm z ekspozycją na DACH (Asseco, Comarch, Inter Cars, KGHM) zrozumienie tego rynku jest warunkiem współpracy B2B. Gosign z siedzibą w [Hamburgu](/pl/agenci-ai-hamburg/) i biurem w [Berlinie](/pl/agenci-ai-berlin/) jest częścią tego rynku - i dokładnie pod to jest zbudowana architektura.

## Trzy wyzwania regulacyjne dla AI na rynku niemieckim

Po pierwsze Betriebsverfassungsgesetz: § 87 ust. 1 pkt 6 BetrVG daje Radzie Zakładowej prawo współdecydowania (nie tylko konsultacji - to kluczowa różnica względem polskiej Rady Zakładowej) przy wprowadzaniu urządzeń technicznych, które mogą monitorować zachowanie lub wydajność pracowników. Systemy AI w HR, w planowaniu zmian, w ocenie performance, w routingu service desk - wszystkie pod to podpadają. Produktywne wdrożenie bez Betriebsvereinbarung jest w niemieckich koncernach prawnie nie do utrzymania. Decision Layer z wymuszonym Human-in-the-Loop nie jest tu feature architektury, lecz warunkiem, żeby Rada Zakładowa zgodziła się na wdrożenie. Dla polskich zespołów IT przyzwyczajonych do konsultacyjnego modelu polskiego to istotny skok wymagań.

Po drugie RODO i BDSG z federalnym nadzorem ochrony danych: BfDI na poziomie federacji, plus szesnastu krajowych inspektorów ochrony danych, plus specyficzne wymogi z Bundesdatenschutzgesetz. Przy zautomatyzowanym podejmowaniu decyzji w rozumieniu Art. 22 RODO niemieckie organy ochrony danych oczekują udokumentowanych podstaw prawnych, dostępnych wyjaśnień i kompletnego Audit Trail. Niemiecka specyfika: ocena skutków dla ochrony danych musi być przy zastosowaniach wysokiego ryzyka zakończona przed uruchomieniem, nie równolegle do rolloutu - inaczej niż w praktyce polskiego UODO.

Po trzecie BaFin, BSI, BNetzA i EU AI Act: BaFin nadzoruje sektor finansowy i przy AML, KYC, kredyt scoringu i obsłudze szkód oczekuje wykazywalnej ostatecznej decyzji człowieka w przypadkach ryzyka. BSI definiuje minimalne wymogi bezpieczeństwa IT dla firm KRITIS. EU AI Act jest wdrażany w Niemczech przez przygotowywaną ustawę wykonawczą - z naciskiem na zastosowania wysokiego ryzyka w HR, bankowości, ubezpieczeniach i infrastrukturze krytycznej. Kto startuje tu bez Cert-Ready by Design, buduje na architekturze, która najpóźniej przy pierwszym audycie BaFin musi być modernizowana.

## Typowe scenariusze wdrożeń w Niemczech

Allianz i Munich Re - obsługa szkód: niemieccy liderzy ubezpieczeń przetwarzają codziennie tysiące szkód. Workflow Agents klasyfikują wpływające szkody według taryfy, regionu i złożoności, Decision Layer routuje przypadki ryzyka do sachbearbeiterów ludzkich, a Audit Trail dokumentuje każdą decyzję dla wewnętrznych rewizji i audytów BaFin.

Commerzbank i Sparkassen operacje AML: przy milionach transakcji dziennie Document Agents sprawdzają cechy identyfikacyjne, Decision Layer routuje przypadki podejrzane wzdłuż progów BaFin, z Human-in-the-Loop przy każdej finalnej eskalacji.

VW, BMW i Daimler operacje HR: niemieckie koncerny motoryzacyjne mają setki tysięcy pracowników i odpowiednio złożone procesy HR. Workflow Agents wspierają recruiting i mobilność wewnętrzną, z wymuszoną ostateczną decyzją człowieka przy działaniach personalnych - warunek akceptacji Rady Zakładowej zgodnie z § 87 BetrVG.

BASF i Bayer dokumentacja produkcyjna: niemieckie koncerny chemiczne generują codziennie ogromne ilości dokumentacji bezpieczeństwa i jakości. Document Agents ekstrahują specyfikacje istotne regulacyjnie, zestawiają je z wymogami REACH, CLP i CE, z kompletnym Audit Trail aż do źródłowego PR.

## Jak Gosign obsługuje Niemcy z Hamburga i Berlina

Gosign ma siedzibę główną w Hamburgu (Hallerstraße 8) i biuro w Berlinie (Nogatstraße 46), do tego centrum szkoleniowe w Hamburgu przy Grindelberg 77. Warsztaty discovery odbywają się na miejscu u klienta - w [Monachium](/pl/agenci-ai-monachium/), [Frankfurcie](/pl/agenci-ai-frankfurt/), [Stuttgarcie](/pl/agenci-ai-stuttgart/), [Dusseldorfie](/pl/agenci-ai-dusseldorf/), [Kolonii](/pl/agenci-ai-kolonia/), [Hannowerze](/pl/agenci-ai-hannover/) lub bezpośrednio w Hamburgu i Berlinie. Następnie build działa zdalnie, z dokumentacją niemieckojęzyczną, cotygodniowymi sprint review przez wideo, stałym punktem kontaktu i wizytami on-site co 4-6 tygodni. Terminy z Radą Zakładową, inspektorami ochrony danych i funkcjami compliance są stałym elementem każdego projektu. Wizyty w BaFin, BSI lub krajowych organach ochrony danych Gosign towarzyszy na żądanie wspólnie z wewnętrznym działem prawnym. Polskich klientów z ekspozycją niemiecką - spółki-matki oraz polscy poddostawcy niemieckich koncernów - koordynujemy przez nasze [biuro w Krakowie](/pl/agenci-ai-krakow/), które zapewnia polskojęzyczne PM i compliance obok niemieckiego zespołu architektów. Więcej na stronie [usługi AI Agents](/pl/uslugi/ai-agents/).

## Dlaczego Niemcy to dobry punkt startowy dla Enterprise AI

Niemcy są nie najłatwiejszym, ale najtwardszym rynkiem UE dla compliance Enterprise AI. Dokładnie to czyni go najlepszym punktem startowym. Kto zbuduje agenta AI spełniającego RODO, BDSG, BetrVG, wymogi BaFin i BSI oraz [EU AI Act](/pl/governance/eu-ai-act/), rozwinął architekturę, która w każdym innym kraju UE jest już tylko jedną zmianą konfiguracji dalej. Niemiecka kultura compliance i współdecydowanie Rady Zakładowej wymuszają Governance by Design - żaden inny kraj UE nie wymaga tego z taką konsekwencją.

Dla koncernów DAX, MDAX i niemieckiego mittelstandu powyżej 200 pracowników ta dyscyplina nie jest ciężarem, lecz przewagą konkurencyjną: co w Niemczech wchodzi na produkcję, wchodzi na produkcję w UE. Architektura, która wytrzymuje BaFin, wytrzymuje też holenderski DNB, austriacki FMA i francuski ACPR. Rozwiązanie uzgodnione z Radą Zakładową niemieckiego koncernu przemysłowego można w Polsce negocjować z Radą Zakładową, w Hiszpanii z Comité de Empresa i we Francji z CSE bez zasadniczego re-buildu. Gosign jako firma hamburska jest częścią tego rynku - architektura nie powstała z podręcznika, lecz z projektów w niemieckich koncernach, których oczekiwania audytowe kształtowały każdy pierwszy produktywny dzień. Cert-Ready by Design nie jest tu argumentem sprzedażowym, lecz koniecznością konstrukcyjną.

--- Agenci AI dla Firm w Polsce | Gosign ---
> Enterprise AI Agents dla polskich firm. EU AI Act compliant, RODO-konform, kompatybilne z Radą Zakładową. Biuro w Krakowie, projekty w całej Polsce.

## Polska to jednocześnie największy rynek IT outsourcingu w Europie i samodzielna digital economy

Polska to jedyny rynek UE, na którym koegzystują dwie strukturalnie różne ekonomie technologiczne. Z jednej strony Global Capability Centers zachodnioeuropejskich koncernów w [Krakowie](/pl/agenci-ai-krakow/), [Wrocławiu](/pl/agenci-ai-wroclaw/) i [Gdańsku](/pl/agenci-ai-gdansk/) - ABB, Cisco, IBM, Capgemini, UBS, Bosch, LG Electronics, Amazon Development Center, Volvo, Toyota Motor Manufacturing Poland. Z drugiej strony czysto polskie koncerny z siedzibami w [Warszawie](/pl/agenci-ai-warszawa/) i Krakowie: PKO BP, Pekao, Santander Bank Polska, ING Bank Śląski, mBank, BNP Paribas Polska, PZU, Warta, Allegro, LPP, Dino Polska, Biedronka (Jerónimo Martins), CCC, Ciech, Grupa Azoty, JSW, KGHM, CD Projekt, Asseco, Comarch. Ta podwójna struktura tworzy rynek AI, który jednocześnie musi obsługiwać compliance koncernowe krajów macierzystych i spełniać własne polskie regulacje.

## Trzy wyzwania regulacyjne dla AI na polskim rynku

Po pierwsze KSeF i fakturowanie elektroniczne. KSeF (Krajowy System e-Faktur) staje się stopniowo obowiązkowy dla wszystkich firm w Polsce. Setki tysięcy faktur przychodzących i wychodzących dziennie muszą być strukturyzowane, walidowane i archiwizowane - każda ekstrakcja czy klasyfikacja oparta na AI musi być zgodna z KSeF. Koncerny takie jak Orlen, Allegro, LPP czy PGE przebudowują obecnie swoje pipeline'y dokumentowe. Kto pracuje tu bez nadążalnych podstaw modeli, ryzykuje kontrole skarbowe z niejasnym ciężarem dowodu.

Po drugie UODO, RODO i polska ustawa o ochronie danych osobowych. UODO (Urząd Ochrony Danych Osobowych) stał się w ostatnich latach jednym z bardziej aktywnych regulatorów ochrony danych w UE. Przy automatycznym profilowaniu i podejmowaniu decyzji w rozumieniu art. 22 RODO UODO oczekuje udokumentowanych podstaw prawnych, możliwych do wywołania wyjaśnień i pełnego Audit Trail. Polska specyfika: w przypadku decyzji istotnych z punktu widzenia HR Rada Zakładowa ma prawo do informacji i konsultacji - architektura musi to umożliwić, choć Rada Zakładowa nie ma prawa weta.

Po trzecie KNF, NBP i EU AI Act. Komisja Nadzoru Finansowego z siedzibą w Warszawie nadzoruje polski sektor finansowy i oczekuje przy AML, KYC, scoringu kredytowym i obsłudze szkód potwierdzonej ostatecznej decyzji człowieka w przypadkach ryzykownych. EU AI Act obowiązuje od lutego 2025 dla zakazanych praktyk, a dla systemów wysokiego ryzyka - zgodnie z obowiązującym prawem od 2 sierpnia 2026 r., z wstępnie uzgodnionym przesunięciem na 2 grudnia 2027 r. (Digital Omnibus, maj 2026, przyjęcie w toku) - w Polsce bez krajowej ustawy wdrożeniowej, czyli bezpośrednio stosowany. Kto wdraża AI wysokiego ryzyka w HR, banking lub ubezpieczeniach, potrzebuje ocen zgodności, zarządzania ryzykiem i post-market monitoring na poziomie wytrzymującym kontrolę KNF lub UODO.

## Typowe scenariusze wdrożeń w Polsce

PKO BP i mBank - operacje AML: polskie banki przetwarzają dziennie miliony transakcji. Document Agents wyłapują dane identyfikacyjne, Decision Layer kieruje przypadki podejrzane zgodnie z progami KNF, z Human-in-the-Loop przy każdej finalnej eskalacji i pełnym Audit Trail dla nadzoru.

Allegro, LPP i Dino Polska - pipeline KSeF: największe polskie sieci handlowe i lider e-commerce stoją pod presją KSeF. Document Agents wyłapują strukturalne dane faktur, walidują względem schematu KSeF i kierują odchylenia do księgowych do weryfikacji.

JSW i KGHM - operacje przemysłowe: polskie koncerny górnicze i metalurgiczne generują codziennie ogromne ilości danych z czujników i komunikatów bezpieczeństwa. Workflow Agents klasyfikują anomalie, eskalują incydenty bezpieczeństwa do kierowników zmian i protokołują każdą decyzję dla Wojewódzkiego Inspektoratu Ochrony Środowiska oraz analiz istotnych dla KNF.

Comarch i Asseco - operacje software: dwa polskie koncerny softwareowe rozwijają oprogramowanie bankowe i ubezpieczeniowe dla całej Europy Środkowej. Document Agents weryfikują dokumentację release względem wymogów KNF, BaFin i FINMA, zanim release trafi do klienta.

## Jak Gosign obsługuje całą Polskę z lokalnego biura w Krakowie

Gosign ma własne biuro w Krakowie (gosign.pl) jako regional hub dla polskiego rynku. Polski zespół z kierownikami projektów i inżynierami - native polish speakerami, biegłymi w angielskim - obsługuje wszystkie cztery duże klastry technologiczne kraju: [Warszawa](/pl/agenci-ai-warszawa/) jako stolica koncernów i regulatorów, [Kraków](/pl/agenci-ai-krakow/) jako shared service hub, [Wrocław](/pl/agenci-ai-wroclaw/) jako przemysłowo-IT-owa hybryda i [Gdańsk](/pl/agenci-ai-gdansk/) jako lokalizacja portowo-tech. Workshops na miejscu, sprint reviews i steering committees prowadzimy po polsku, bez bariery językowej i bez kosztów podróży z zagranicy. Hamburska centrala dostarcza standardy architektoniczne, ekspertyzę DACH compliance i połączenie ze spółkami-matkami w Niemczech, Szwajcarii i Holandii - delivery, codzienna praca i bezpośredni kontakt z klientem leżą po stronie krakowskiego zespołu. Właśnie ta struktura jest decydująca dla polskich firm średniej wielkości i spółek-córek koncernów, które chcą jakości na poziomie niemieckiego standardu, nie biorąc jednocześnie do domu bariery językowej.

## Dlaczego Polska to dobry punkt startowy dla Enterprise AI

Polska jest dla niemieckich, szwajcarskich i holenderskich koncernów najbliższym stres testem AI. Kto uruchomi w Polsce agenta AI spełniającego jednocześnie KSeF, UODO, KNF i EU AI Act, ten stworzył architekturę odległą od każdego zachodnioeuropejskiego rynku już tylko o jedną zmianę konfiguracji. Polska łączy maksymalną dostępność talentów (Kraków, Wrocław, Warszawa, Gdańsk) z maksymalną presją regulacyjną (KNF, UODO, KSeF, EU AI Act, RODO). Klaster z Krakow Technology Park, Warsaw Spire Tech, Wrocław Technology Park i Gdański Park Naukowo-Technologiczny tworzy największy spójny krajobraz technologiczny w Europie Środkowo-Wschodniej.

Dochodzi cecha, która czyni Polskę szczególnie przewidywalną dla wdrożeń Enterprise AI: operacyjna bliskość Niemiec. Polskie koncerny od dziesięcioleci współpracują z niemieckimi spółkami-matkami, polskie banki utrzymują stosunki korespondencyjne z Frankfurtem i Monachium, polskie lokalizacje przemysłowe są wpięte w niemieckie łańcuchy dostaw. Język compliance jest dobrze zorganizowany, oczekiwania wobec Audit Trail, wyjaśnialności i Governance by Design nie są niczym nowym. Udane wdrożenie w Polsce jest tym samym nie tylko krokiem otwarcia rynku, lecz dostarcza referencji architektonicznej akceptowanej bezpośrednio w regionie DACH. Cert-Ready by Design nie jest tu hasłem marketingowym, lecz warunkiem pierwszego produkcyjnego dnia - i jednocześnie najszybszą drogą do platformy Enterprise AI, która później ma być produkcyjna w piętnastu kolejnych krajach UE. Więcej kontekstu o [EU AI Act](/pl/governance/eu-ai-act/) i jego polskim wdrożeniu znajdziesz w sekcji Governance, więcej o architekturze - na stronie [Decision Layer](/pl/decision-layer/), a o ofercie - na [stronie usług AI Agents](/pl/uslugi/ai-agents/).

--- Agenci AI dla Firm w Rio de Janeiro | Gosign ---
> Enterprise AI Agents dla Rio de Janeiro. LGPD-compliant, CLT-kompatybilne. Audytowalne agenty dla energetyki, gornictwa i sektora publicznego.

## Rio de Janeiro to wąskie gardło compliance brazylijskiego sektora energetycznego i surowcowego

W Rio siedzą koncerny, których ryzyka operacyjne trafiają codziennie do raportów ESG całego świata: Petrobras (siedziba Avenida República do Chile), Vale (siedziba na Praia de Botafogo, operacyjnie w Minas Gerais), Eletrobras, Light SA, Americanas i Oi. Do tego regulatorzy: CVM (Comissão de Valores Mobiliários, siedziba Centro Rio), BNDES jako krajowy bank rozwoju, ANP (Agência Nacional do Petróleo) i ANEEL (Agência Nacional de Energia Elétrica) z oddziałami bezpośrednio w centrum. Kto eksploatuje tu AI Agents w produkcyjnych pętlach compliance, eksploatuje je pod okiem czterech organów nadzoru jednocześnie - i co najmniej jeden z nich jest po Brumadinho nadwrażliwy na każdą formę decyzji algorytmicznej. Inaczej niż w São Paulo, koncentracja przemysłowa tutaj nie jest rozłożona horyzontalnie, lecz pogłębiona wertykalnie: kto adresuje energetykę i surowce w Brazylii, ma w Rio najgęstszy dostęp do rynku. Dla polskich inwestorów z portfelem komodytowym (KGHM, Orlen) Rio to miejsce, gdzie zapadają decyzje zaopatrujące europejskie kontrakty dostawcze.

## Trzy wyzwania regulacyjne dla AI na rynku Rio de Janeiro

Po pierwsze nadzór CVM nad koncernami kapitałowymi jest w Rio gęstszy niż gdzie indziej w Brazylii. Petrobras, Vale, Eletrobras i Americanas są notowane; każdy komponent algorytmiczny w Investor Relations, raportowaniu kwartalnym czy prewencji insider trading musi być wyjaśnialny dla audytora CVM. Siedziba CVM w Centro Rio oznacza: krótkie ścieżki, intensywne kontrole.

Po drugie ANP i ANEEL dla regulowanej infrastruktury. Instalacje Petrobras i sieci Eletrobras są udokumentowane zgodnie z wytycznymi ANP i ANEEL. AI, która proponuje okna serwisowe, tworzy plany produkcji czy priorytetyzuje awarie sieci, podlega konkretnej regulacji sektorowej - nie tylko LGPD. ANP wymaga prześledzalności aż do poziomu odwiertu, ANEEL - aż do poziomu stacji transformatorowej.

Po trzecie LGPD i post-Brumadinho presja na przejrzystość. Vale od 2019 (Brumadinho) i 2015 (Mariana) znajduje się pod obserwacją prokuratury federalnej (MPF) i Justiça Federal. Każda decyzja algorytmiczna w obszarze bezpieczeństwa tam, risk scoring czy monitoringu odpadów poflotacyjnych musi być wyjaśnialna przed sądem. Audit Trail nie jest tu "nice to have" - to różnica między linią obrony a aktem oskarżenia.

## Typowe scenariusze wdrożeń w Rio de Janeiro

Petrobras dokumentacja instalacji: Document Agents czytają protokoły serwisowe, raporty wierceń i zgłoszenia ANP z 30 lat historii instalacji i konsolidują je do audytowalnych Decision Records. Gdy inspektor pyta o historię pęknięcia spawu, odpowiedź zamiast tygodniowego projektu jest zapytaniem - z kompletnym Audit Trail do pierwotnego pliku. Przy koncernie z 60 000 pracowników, odwiertami pre-salt przed wybrzeżem i siecią rafinerii w poprzek Brazylii to nie "nice to have", lecz operacyjne wąskie gardło.

Vale monitoring bezpieczeństwa górniczego: Workflow Agents monitorują dane sensoryczne, raporty inspekcji i zewnętrzne dane pogodowe w lokalizacjach tam odpadów poflotacyjnych w Minas Gerais (sterowanych operacyjnie z Rio). Decision Layer eskaluje krytyczne wzorce ryzyka z Human-in-the-Loop do geotechniki - każda decyzja udokumentowana dla ANM, MPF i wewnętrznego compliance.

BNDES zatwierdzanie kredytów: Document Agents sprawdzają wnioski o finansowanie pod kątem kompletności, wiarygodności i konfliktu z kryteriami wykluczenia ESG. Decision Layer oznacza krytyczne wnioski do decyzji człowieka i generuje pełne dossier uzasadnień dla każdej rekomendacji - z podaniem źródeł i pochodzenia danych. Przy kredytach finansowych w trzycyfrowych milionach głębia uzasadnienia per decyzja jest warunkiem każdej kontroli TCU.

Globo - moderacja treści i rights management: Document Agents przetwarzają dokumenty licencyjne, prawa eksploatacji i klauzule kontraktowe dla największej grupy medialnej Ameryki Łacińskiej. Decision Layer eskaluje konflikty między licencjami nadawczymi, prawami streamingowymi i międzynarodowymi umowami eksploatacji z Audit Trail do pierwotnego pliku - krytyczne w erze streamingu, w której prawa Globoplay są codziennie negocjowane na nowo.

## Jak Gosign obsługuje całą Brazylię z Sao Paulo - włącznie z Rio

Nasze [biuro w Sao Paulo](/pl/agenci-ai-sao-paulo/) jest godzinę lotu od Rio - bliżej do HQ Petrobras niż większość polskich dostawców AI do jakiegokolwiek klienta. Warsztaty discovery z Petrobrasem, Vale czy BNDES odbywają się na miejscu w Rio, w centralach koncernowych w Botafogo czy Centro. Review compliance z odniesieniem do CVM, ANP lub ANEEL prowadzone są wspólnie z Twoim działem prawnym w Rio - bliskość siedziby CVM oznacza, że wyjaśnienia regulacyjne zamiast 6-tygodniowej korespondencji są załatwiane jednym spotkaniem na 25. piętrze Avenida Rio Branco. Fazy techniczne build działają rozproszenie między naszymi zespołami w Hamburgu i São Paulo - standupy rano czasu SP, wspólne sprint reviews. Terminy on-site w Rio są możliwe w ciągu 24 godzin, także do instalacji Petrobras poza miastem (Macaé, Campos Basin). Po go-live biuro SP jest Twoim operacyjnym punktem kontaktu z infolinią eskalacyjną po portugalsku i angielsku - komunikacja z Twoją europejską centralą macierzystą pozostaje równolegle możliwa po niemiecku, polsku lub angielsku. Polscy inwestorzy z KGHM czy Orlenu koordynują przez biuro w Krakowie. Więcej o naszym podejściu na stronie [usługi AI Agents](/pl/uslugi/ai-agents/).

## Dlaczego Rio de Janeiro to dobry punkt startowy dla Enterprise AI

Rio jest jedynym brazylijskim miastem, w którym czterech regulatorów (CVM, ANP, ANEEL, oddział ANPD) i czterech z dziesięciu największych koncernów brazylijskich siedzi w promieniu 15 km. Kto zbuduje tu produkcyjnego agenta dla raportowania CVM, compliance ANP lub monitoringu odpadów poflotacyjnych, ma go jako blueprint dla każdego latynoamerykańskiego rynku energetycznego i surowcowego - od Buenos Aires przez Limę po Bogotę. Klastry - BNDES Inovação, Rio+, korytarz tech Porto Maravilha - wnoszą do tego most do świata akademickiego (PUC-Rio, UFRJ). Co ponadto wyróżnia Rio: koncentracja koncernów notowanych z globalnymi inwestorami ESG oznacza, że wymogi wobec wyjaśnialności algorytmicznej są tu gęstsze niż gdzie indziej w Ameryce Łacińskiej - co podnosi poprzeczkę, ale właśnie dzięki temu czyni każdego udanego agenta zbudowanego tu Cert-Ready blueprintem dla globalnych centrali macierzystych. Architektura Governance by Design jest kompatybilna z operacjami RODO w Lizbonie i audytami UE - model, który ostoi się w Rio, ostoi się we Frankfurcie. Zobacz też [São Paulo](/pl/agenci-ai-sao-paulo/) i [Brazylię jako całość](/pl/agenci-ai-brazylia/).

--- Agenci AI dla Firm w Sao Paulo | Gosign ---
> Enterprise AI Agents w Sao Paulo. Lokalne zarządzanie projektami, LGPD-compliant, kompatybilne z CLT. Od PoC do samodzielnej operacji.

## São Paulo to jedyna metropolia LATAM, w której polski lub europejski dostawca AI musi pracować z lokalną obecnością

Kto chce pozyskać Itaú Unibanco, Bradesco, Santander Brasil, Natura &Co czy Ambev jako klientów, nie może tego zrobić z Warszawy, Krakowa czy Hamburga. Avenida Paulista, Faria Lima i Pinheiros to własne regulacyjne mikrokosmosy z własnymi procesami compliance, własnymi kulturami ochrony danych i własnymi oczekiwaniami co do bliskości dostawców. To samo dotyczy klastrów bankowych wokół Cubo Itaú i światów dóbr konsumpcyjnych JBS, BTG Pactual i XP Inc. Gosign prowadzi dlatego własne biuro w São Paulo - z lokalnymi kierownikami projektów, którzy siedzą bezpośrednio przy dyskusjach z compliance officerami, inspektorami ochrony danych (DPO) i przedstawicielami Sindicato. Dla polskich inwestorów z ekspozycją brazylijską (polskie spółki z akwizycjami w LATAM, firmy B2B obsługujące brazylijskich klientów) São Paulo jest operacyjnym węzłem, z którego da się koordynować cały rynek brazylijski.

## Trzy wyzwania regulacyjne dla AI na rynku São Paulo

Po pierwsze LGPD (Lei Geral de Proteção de Dados) to brazylijska odpowiedź na europejską ochronę danych - ale nie identyczna z RODO. ANPD (Autoridade Nacional de Proteção de Dados, formalnie w Brasilii, operacyjnie silnie skoncentrowana na SP) wymaga podstawy prawnej, ograniczenia celu i DPO. Kto w Pinheiros pracuje z danymi osobowymi, musi spełniać Artykuł 7 i 11 LGPD (dane wrażliwe, zdrowotne i finansowe) - włącznie z Audit Trail. Dla polskich firm doświadczenie z UODO i RODO jest punktem wyjścia, ale nie zastępstwem - interpretacja ANPD w szczegółach odbiega.

Po drugie BACEN Resolução 4893 definiuje wymogi cyber-resilience dla regulowanych instytucji finansowych i jest faktycznie brazylijskim odpowiednikiem DORA. Itaú, Bradesco, Banco do Brasil, Santander Brasil i fintechy (Nubank, Stone, PagSeguro, XP Inc.) muszą dokumentować każdą algorytmiczną ingerencję w decyzje kredytowe, fraud scoring czy AML - nie dopiero przy audycie, lecz produkcyjnie i live.

Po trzecie PL 2338/2023 to brazylijski projekt ustawy AI, luźno oparty na EU AI Act, ale nie identyczny. W 2026 jeszcze nie w mocy, ale oczekiwany w ciągu najbliższych dwóch lat. Kto buduje dziś, musi architekturę ułożyć tak, aby klasyfikacja high-risk, kontrola człowieka i obowiązki przejrzystości mogły być aktywowane następczo. Cert-Ready by Design zamiast Cert-Retrofit.

## Typowe scenariusze wdrożeń w São Paulo

KYC banków i AML screening w Itaú/Bradesco/Santander Brasil: Document Agents czytają Cadastro de Pessoas Físicas, Cadastro Nacional da Pessoa Jurídica, Comprovante de Residência i zewnętrzne listy sankcyjne. Decision Layer oznacza trafienia high-risk (PEPs, dopasowania sankcyjne) i routuje je do compliance officerów z uzasadnieniem, confidence score i kompletnym Audit Trail. Banco Central i audyty Coaf zamiast tygodniowego projektu stają się naciśnięciem przycisku.

Compliance łańcucha dostaw w Natura &Co i JBS: Workflow Agents monitorują certyfikaty dostawców (FSC, Rainforest Alliance, GRSB dla wołowiny), zestawiają je z listami sankcyjnymi IBAMA i alarmują o nieprawidłowościach. Przy JBS i Marfrig pytanie "czy to gospodarstwo dostarcza z obszarów wylesień?" stało się teraz tak samo krytyczne dla przeżycia jak raportowanie ESG w Naturze.

Investment compliance w XP Inc. i BTG Pactual: Document Agents sprawdzają umowy inwestycyjne, profile ryzyka i obowiązki zgłoszeniowe CVM. Decision Layer eskaluje naruszenia wymogów suitability automatycznie do compliance - z Human-in-the-Loop przy każdym kroku istotnym regulacyjnie. W bankach inwestycyjnych głębia audytu per trade nie jest "nice to have", lecz warunkiem każdej procedury CVM - Workflow Agents dokumentują równolegle kontrolę suitability, pouczenie inwestora i wersjonowanie modelu scoringu ryzyka.

Fraud detection w Nubank, Stone i PagSeguro: Brazylia ma najwyższą adopcję Pix na świecie (ponad 90% populacji), a tym samym własny krajobraz fraud. Workflow Agents monitorują wzorce transakcji w czasie rzeczywistym, zestawiają je z profilami behawioralnymi i eskalują podejrzane zdarzenia z confidence score i dossier uzasadnień do zespołów anti-fraud. Audit Trail spełnia zarówno obowiązki zgłoszeniowe Coaf, jak i standardy bezpieczeństwa BACEN.

## Jak Gosign obsługuje São Paulo z biura w São Paulo

Mamy biuro w São Paulo z lokalnymi kierownikami projektów - to nie "Sales Office", lecz realna obecność operacyjna. Konkretnie oznacza to: warsztaty discovery odbywają się na miejscu, nie przez Zoom z Europy. Review compliance z Twoim DPO i działem prawnym są prowadzone osobiście w Faria Lima lub Pinheiros. Konsultacje z Sindicato, gdy HR Agents podejmują decyzje istotne dla pracy, prowadzone są wspólnie z Twoimi prawnikami pracy. Implementacja techniczna działa zdalnie między naszymi zespołami w Hamburgu i São Paulo - 4 godziny różnicy czasu, wspólne standupy rano czasu SP. Po go-live biuro SP pozostaje Twoim operacyjnym punktem kontaktu - z infolinią eskalacyjną po portugalsku i osobami kontaktowymi, które faktycznie znają operacyjnie brazylijskie prawo pracy (CLT) i układy zbiorowe (CCT/ACT), nie tylko z dokumentu tłumaczeniowego. Dla polskich klientów koordynację zapewnia nasze [biuro w Krakowie](/pl/agenci-ai-krakow/) - polskojęzyczny PM, portugalskojęzyczny delivery. Więcej o naszym podejściu na stronie [usługi AI Agents](/pl/uslugi/ai-agents/).

Pytanie, które brazylijscy odpowiedzialni za compliance zadają nam najpierw, nie brzmi "czy potraficie to technicznie?", lecz "czy jesteście też wtedy, gdy ANPD lub audytor zadzwoni?". Uczciwa odpowiedź brzmi: tak, bo nasi kierownicy projektów mieszkają, pracują i żyją w São Paulo. Discovery, build, go-live i aftercare to nie są cztery różne zespoły w czterech różnych krajach - to jeden zespół z hubem w São Paulo i hubem w Hamburgu, który dzieli wspólne cykle sprint, wspólne boards architektoniczne i wspólne ścieżki eskalacji.

## Dlaczego São Paulo to dobry punkt startowy dla Enterprise AI

São Paulo jest jedynym punktem w Ameryce Łacińskiej, w którym compliance bankowy, łańcuchy dostaw dóbr konsumpcyjnych, innowacja fintech i operacje przemysłowe spotykają się w jednym mieście. Kto zbuduje tu produkcyjnego AI Agenta dla KYC, AML lub ESG, ma go w 18 miesięcy jako blueprint dla Meksyku, Bogoty, Santiago czy Buenos Aires. Klastry - Cubo Itaú, ACE Startups, korytarz tech Pinheiros-Vila Olímpia - zapewniają dostęp do talentu, inwestorów i regulacyjnych programów pilotażowych. Architektura Governance by Design łączy to z europejską głębią audytu: model, który w São Paulo działa z LGPD i BACEN, jest kompatybilny z operacjami RODO w [Lizbonie](/pl/agenci-ai-lizbona/), Madrycie czy Hamburgu. Więcej w [przeglądzie Brazylii](/pl/agenci-ai-brazylia/).

--- Agenci AI dla Firm w Stuttgarcie | Gosign ---
> Enterprise AI Agents dla Stuttgartu i MŚP w Badenii-Wirtembergii. Document Agents, Workflow Agents. Audytowalne, EU AI Act compliant.

## Stuttgart to jedyny europejski rynek, na którym koncernowy OEM i mittelstandowy hidden champion w jednym łańcuchu dostaw muszą spełniać te same wymogi compliance

W korytarzu między Untertürkheim, Zuffenhausen i Sindelfingen mają siedziby Mercedes-Benz i Porsche ze swoimi zakładami głównymi. W Gerlingen rezyduje Bosch jako największy dostawca automotive na świecie. Daimler Truck steruje z Leinfelden-Echterdingen globalną dywizją ciężarówkową. Dochodzą Dürr w Bietigheim, Trumpf w Ditzingen, Festo w Esslingen, Stihl w Waiblingen, Mahle i Kärcher - lista hidden champions sięga daleko poza granice miasta. Lokalizacja definiuje się nie przez sam OEM, lecz przez łańcuch z producenta, dostawcy Tier 1 i wyspecjalizowanych firm średniej wielkości. Kto wprowadza tu komponent AI, musi go równocześnie udokumentować na kilku poziomach łańcucha dostaw ASPICE i ISO 26262 - standard dostawców Mercedesa zmusza każdego dostawcę do tych samych audytowalnych dowodów modelowych. To zazębienie czyni rynek stuttgarcki jednym z najtwardszych otoczeń compliance w Europie: każdy dostawca jest automatycznie przez wymagania swojego OEM zmuszony do ścisłej governance modeli, czy chce, czy nie.

## Trzy wyzwania regulacyjne kształtujące każdą inicjatywę AI na rynku stuttgarckim

Pierwszym wyzwaniem jest homologacja typu w automotive. KBA we Flensburgu wydaje zezwolenia, ale standardy merytoryczne ustala UN/ECE w Genewie - przede wszystkim UN R155 dla Cybersecurity Management i UN R156 dla Software Updates. Kto stosuje komponent AI w pojeździe lub w procesie produkcyjnym wpływającym na oprogramowanie pojazdu, potrzebuje pełnego dowodu z governance modeli, proweniencji danych treningowych i odtwarzalnych stanów buildu. Drugim wyzwaniem jest Cyber Resilience Act dla wyposażenia przemysłowego hidden champions - Trumpf, Dürr, Festo i Stihl dostarczają maszyny z komponentami cyfrowymi do regulowanych rynków i muszą wykazać zarządzanie podatnościami i aktualizacjami modeli. Trzecim wyzwaniem jest silne współdecydowanie w zakładach pod wpływem IG-Metall: aplikacja AI z odniesieniem do osób lub pomiarem wydajności przechodzi rady zakładowe w Mercedesie, Boschu lub Porsche tylko wtedy, gdy [Decision Layer](/pl/decision-layer/) architektonicznie wymusza ostateczną decyzję człowieka. Niemiecka rada zakładowa ma rzeczywiste prawo blokujące, polska Rada Zakładowa - tylko prawo konsultacji. Więcej o ramach regulacyjnych pod [Governance EU AI Act](/pl/governance/eu-ai-act/).

## Typowe scenariusze wdrożeń w Stuttgarcie

W Boschu i podobnych dostawcach Tier 1 widzimy agentów danych jakości konsolidujących dane produkcji i kontroli z wielu zakładów i eskalujących anomalia do quality engineera - z nadążalną oceną i odniesieniem do bazowych danych pomiarowych. W Daimler Truck compliance agent pomaga w dokumentacji flotowej, przy przygotowaniu dokumentów homologacyjnych dla różnych jurysdykcji. W otoczeniu Porsche Financial Services agenci wspierają przygotowanie decyzji o wiarygodności kredytowej dla klientów leasingowych - specjalista decyduje, agent wzbogaca o dokumenty, historię kredytów konsumenckich i testy prawdopodobności. W Dürr, Festo i Trumpf widzimy agentów ticketów serwisowych klasyfikujących napływające tickety klienckie, wzbogacających o dane maszynowe i przekazujących technikom serwisowym z propozycją. Mahle i Mahle Behr pracują nad HR Document Agents do wstępnej kwalifikacji kandydatów - z jasnym Audit Trail, ponieważ rekrutacja stoi pod AGG i według EU AI Act w klasyfikacji wysokiego ryzyka. W Stihl i Kärcher jako rodzinnych firmach średniej wielkości widzimy Document Agents w zakupach i analizie umów, ponieważ audyt wewnętrzny tych domów oczekuje szczupłej, ale kompletnej logiki audytowej. Centrala Mercedes-Benz w Untertürkheim pracuje na co dzień ze ścisłym workflow ASPICE, w którym komponenty AI mogą być wprowadzane do produkcyjnych łańcuchów tylko wtedy, gdy ich proweniencja modelu i dataset treningowy są udokumentowane i zwersjonowane.

## Jak Gosign obsługuje Stuttgart z Hamburga

Gosign nie ma lokalizacji w Stuttgarcie - obecność na miejscu idzie zdalnie z Hamburga i Berlina. Zaleta: trasą ICE jesteśmy w niespełna sześć godzin w Untertürkheim, bezpośredni lot Hamburg - Stuttgart trwa około godziny plus dojazd. Konkretnie: Discovery workshops z engineering, compliance i radą zakładową robimy jako dwu- do trzydniowe bloki na miejscu. Faza inżynieryjna jest zorganizowana zdalnie z dwoma stałymi tygodniowymi slotami w kalendarzu klienta i zdefiniowanymi dniami na miejscu na przeglądy architektoniczne i krytyczne terminy interesariuszy. Walidacja modeli z audytem wewnętrznym, przygotowanie audytu ASPICE i negocjacje współdecydowania odbywają się bez wyjątku na miejscu. Szwabski rynek akceptuje pracę zdalną pragmatycznie, gdy terminowość dostaw jest zachowana, częstotliwość obecności na miejscu w odpowiednich kluczowych terminach jest zachowana, a walidacja modeli pozostaje udokumentowanie nadążalna. Klastry takie jak ARENA2036 jako kampus badawczy mobilności przyszłości na terenie Uniwersytetu Stuttgartu i Cyber Valley Tübingen-Stuttgart jako największe europejskie centrum badań ML wykorzystujemy do dyskusji technicznych, szkoleń audytorów i kontaktu z uniwersyteckimi ekspertami walidacji modeli.

## Dlaczego Stuttgart to dobry punkt startowy dla Enterprise AI

Kto uruchomi w stuttgarckim środowisku OEM lub Tier 1 agenta AI, ten obronił go równocześnie przed ASPICE, ISO 26262, Cyber Resilience Act, doświadczoną w IG-Metall radą zakładową i audytem wewnętrznym. Ta sama architektura pasuje potem do każdej innej zorientowanej produkcyjnie branży w Europie, ponieważ stuttgarcka dyscyplina łańcucha dostaw definiuje najwyższy europejski standard proweniencji modelu i Audit Trail. Dochodzi pula talentów ML i engineering wokół Uniwersytetu Stuttgart z silnym profilem budowy maszyn i informatyki, KIT w Karlsruhe jako największa niemiecka politechnika, Hochschule Esslingen z automotive specjalizacją oraz tübingerskie klastry ML z Instytutem Maxa Plancka Inteligentnych Systemów. Mittelstand w Badenii-Wirtembergii jest jednocześnie rynkiem dla skalowanej architektury AI - około 1500 hidden champions w landzie pokazuje, że to nie tylko koncerny DAX potrzebują AI jako czynnika produkcji. Kto w 4-6 tygodni uruchomi pierwszego agenta u dostawcy Tier 1, ten ma referencyjne setup, które rynek rozumie. Więcej o podejściu pod [usługi AI Agents](/pl/uslugi/ai-agents/).

--- Agenci AI dla Firm w Sztokholmie | Gosign ---
> Enterprise AI Agents dla Sztokholmu. EU AI Act bezpośrednio stosowany, nadzór szwedzkiego IMY. Audytowalne AI dla nordyckiego hubu technologicznego.

## Sztokholm to stolica tech Skandynawii - z najbardziej konsekwentnym organem ochrony danych UE w tle

Kto buduje Enterprise AI w Sztokholmie, buduje dla nietypowej mieszanki: przemysłowe ciężary jak Ericsson, ABB, Atlas Copco, Volvo Cars (operacyjnie w Goeteborgu, funkcje koncernowe w Sztokholmie) i Electrolux spotykają jedną z najgęstszych koncentracji jednorożców w Europie - Spotify, Klarna, King Digital, iZettle, Truecaller, Northvolt. H&M i IKEA (przez grupę Ikano) tworzą rdzeń retail. Kręgosłup bankowy tworzą Skandinaviska Enskilda Banken (SEB), Handelsbanken i Swedbank, krajobraz ubezpieczeniowy jest zdominowany przez Skandia i Folksam. W dzielnicy Kista Science City siedzi ponad 1000 firm tech, w programie Stockholm Unicorn Factory dojrzewa następna generacja. Co czyni Sztokholm szczególnym: szwedzka kultura biznesowa łączy nordycką efektywność z długofalowym myśleniem inżynieryjnym - i akceptuje inwestycje compliance, które inne rynki odbierałyby jako hamujące. Dla polskich inwestorów z ekspozycją nordycką (polski IT obsługujący Klarnę, polscy dostawcy dla H&M) Sztokholm jest odmiennym typem rynku niż Londyn czy Frankfurt - spokojniejszym, ale regulacyjnie surowszym.

## Trzy wyzwania regulacyjne dla AI na rynku sztokholmskim

Po pierwsze IMY (Integritetsskyddsmyndigheten), szwedzki organ ochrony danych. IMY jest w całej UE znany ze swojej konsekwentnej interpretacji RODO i w ostatnich latach nałożył kilka wysokich kar na firmy tech, banki i instytucje publiczne - często z uzasadnieniem niewystarczającej wyjaśnialności zautomatyzowanych decyzji. Dla systemów AI oznacza to: Art. 22 RODO jest w Szwecji stosowany tak surowo jak w Holandii czy Hiszpanii. Decision Layer z Human-in-the-Loop nie jest opcjonalny, lecz warunkiem compliance. W odróżnieniu od polskiego UODO, który funkcjonuje mniej aktywnie, IMY prowadzi proaktywne kontrole.

Po drugie EU AI Act, który w Szwecji jest bezpośrednio stosowany. Szwedzki rząd ogłosił utworzenie własnego organu nadzoru rynku, który koordynuje się z IMY i Finansinspektionen. Systemy wysokiego ryzyka w bankowości, infrastrukturze energetycznej i zarządzaniu personelem będą od 2026 systematycznie kontrolowane. [Compliance EU AI Act](/pl/governance/eu-ai-act/) nie jest tu abstrakcyjny, lecz operacyjny.

Po trzecie Finansinspektionen dla sektora finansowego i PTS (Post- och telestyrelsen) dla telekomunikacji. Finansinspektionen od 2023 wymaga od banków i dostawców usług płatniczych udokumentowanej AI Model Governance, wyjaśnialności i ciągłego monitoringu modeli. Klarna, SEB i Handelsbanken już pracują z odpowiednimi frameworkami. PTS nadzoruje zastosowania AI w sieciach telekomunikacyjnych i bada modele Network Slicing Ericssona pod kątem bias i fairness.

## Typowe scenariusze wdrożeń w Sztokholmie

Spotify rozwija algorytmy rekomendacji produkcyjne jednocześnie w ponad 180 rynkach, które muszą pozostać do obrony pod EU AI Act, IMY i kilkoma krajowymi reżimami nadzoru - każdy algorytmiczny push dla albumu ma implikacje regulacyjne. Klarna wykorzystuje AI do modeli Buy-Now-Pay-Later Risk w ponad 17 rynkach - modele decydują, czy konsument dostaje mikrokredyt, i muszą być jednocześnie wyjaśnialne pod Finansinspektionen, BaFin, FCA i kilkoma innymi nadzorami (włącznie z polskim KNF dla klientów polskich). SEB prowadzi Transaction Monitoring do wykrywania prania pieniędzy z modelami AI, które muszą pozostać reprodukowalne dla Finansinspektionen - każdy pojedynczy alarm podlega audytowi. Ericsson konfiguruje sieci 5G dla operatorów mobilnych na całym świecie z narzędziami AI, których decyzje muszą być dokumentowalne dla odpowiednich krajowych organów nadzoru telekomunikacji.

We wszystkich scenariuszach nie chodzi o sam model, lecz o to, żeby każda decyzja pozostała prześledzalna, mogła być routowana przez zestawy reguł specyficzne dla jurysdykcji i w ścieżkach eskalacji egzekwowała Human-in-the-Loop. To architektura [Decision Layer](/pl/decision-layer/) w czystej formie.

Szwedzka specyfika to obchodzenie się z danymi organów: szwedzka zasada jawności (Offentlighetsprincipen) wymaga, żeby dokumenty organów były zasadniczo publiczne - co dla zastosowań AI w sektorze publicznym i dla wykonawców administracji oznacza, że także dane treningowe i decyzje modelu mogą w pewnych okolicznościach podlegać ujawnieniu. Kto buduje w Sztokholmie AI dla klientów public sector, musi architekturę od początku ułożyć tak, żeby ten standard przejrzystości był spełniony.

## Jak Gosign obsługuje Sztokholm z Hamburga

Hamburg-Sztokholm to bezpośrednie połączenie lotnicze nieco poniżej dwóch godzin, z codziennymi połączeniami przez LH i SAS. Pracujemy remote-first z naszymi szwedzkimi klientami, z warsztatami on-site w pierwszych miesiącach projektu i kwartalnymi wizytami w fazie operacyjnej. Językiem pracy jest angielski, steering z naszymi architektami w Hamburgu prowadzony po niemiecku. Strefa czasowa jest identyczna z Europą Środkową. Polskich klientów obsługujących szwedzkich gigantów (polskie fintechy dla Klarny, polski IT dla Spotify) koordynujemy przez nasze [biuro w Krakowie](/pl/agenci-ai-krakow/).

Co ułatwia nam współpracę: szwedzka kultura biznesowa jest konsensowa, ale technicznie wysoce kompetentna - uczestnicy warsztatów to z reguły Engineering Leads lub Product Managers, którzy rozumieją nasze decyzje architektoniczne bezpośrednio. Znamy szwedzką logikę współdecydowania (MBL, Medbestämmande), która zobowiązuje pracodawców do konsultacji ze związkami zawodowymi przed wprowadzeniem nowych systemów, i planujemy Decision Layer odpowiednio tak, żeby obowiązki współdecydowania były spełnione architektonicznie - nie jako następcza warstwa compliance, lecz jako zintegrowany workflow. Więcej na stronie [usługi AI Agents](/pl/uslugi/ai-agents/).

## Dlaczego Sztokholm to dobry punkt startowy dla Enterprise AI

Sztokholm jest jedynym rynkiem w Europie, w którym architekturę AI możesz testować jednocześnie wobec ochrony danych IMY, nadzoru finansowego Finansinspektionen i nordyckiej logiki współdecydowania - i w którym stakeholderzy są gotowi zainwestować na to czas i zasoby inżynieryjne. Kto buduje w Sztokholmie pilotaż Cert-Ready by Design, ma referencję, która ostała się pod najbardziej surowymi warunkami ochrony danych UE - i która następnie w Helsinkach, Kopenhadze, Oslo i reszcie Europy jest do obrony. Klaster Kista Science City, Stockholm Unicorn Factory i sieć Stockholm School of Economics dostarczają talent, partnerów pilotażowych i dostęp do inwestorów.

Wnosimy z północnoniemieckiego kontekstu engineeringu dyscyplinę, która pasuje do szwedzkiej kultury tech - z Governance by Design, Audit Trail i zdolnością spełniania wymogów compliance z wielu jurysdykcji nad tym samym systemem. Sztokholm jest właściwym rynkiem, żeby tę dyscyplinę skalować w krajach nordyckich. A dla polskich firm z nordyckimi klientami Sztokholm jest często pierwszym rynkiem, w którym nowe architektury AI muszą się udowodnić produkcyjnie - zanim zostaną wdrożone w Krakowie, Warszawie czy Monachium. Zobacz też [Amsterdam](/pl/agenci-ai-amsterdam/) i [Londyn](/pl/agenci-ai-londyn/).

--- Agenci AI dla Firm w Walencji | Gosign ---
> Enterprise AI Agents dla Walencji. Hub technologiczny Morza Srodziemnego. EU AI Act compliant, RODO + LOPDGDD konform. Zarzadzanie z Barcelony.

## Walencja to trzeci obszar gospodarczy Hiszpanii - naznaczony logistyką żywności, przemysłem motoryzacyjnym i handlem śródziemnomorskim

Kto buduje Enterprise AI w Walencji, buduje dla miasta, w którym ton nadają nie banki ani koncerny tech, lecz łańcuchy dostaw, planowanie produkcji i logistyka. Mercadona z ponad 1700 filiami jest największą hiszpańską siecią supermarketów i eksploatuje z centrali w Tavernes Blanques jeden z najgęstszych łańcuchów dostaw marek własnych w Europie. Ford Walencja produkuje w Almussafes od lat 70. - zakład należy do największych lokalizacji Forda w Europie. Porcelanosa (ceramika), Lladró (manufaktura porcelany) i Consum (sieć supermarketów spółdzielcza) to kolejne ciężary przemysłowe. Air Nostrum operuje tu iberyjski regionalny ruch lotniczy, BP eksploatuje w Castellón jedną z największych rafinerii Hiszpanii, a Iberdrola Energía koordynuje z rejonu Walencji znaczną część hiszpańskiej produkcji solarnej. Miasto w ostatnich latach dodatkowo rozwinęło się jako lokalizacja tech z Marina Valencia i programem Lanzadera (finansowanym przez założyciela Mercadony Juana Roiga). Dla polskich spółek z branży food retail (odpowiedniki Biedronki, Kaufland) Mercadona jest kluczowym benchmarkiem.

## Trzy wyzwania regulacyjne dla AI na rynku walenckim

Po pierwsze AEPD i LOPDGDD (Ley Orgánica 3/2018) dla wszystkich przetwarzań z danymi osobowymi. AEPD bada szczególnie surowo firmy logistyczne i detaliczne, bo tu przetwarzane są ogromne ilości danych klientów i pracowników. Mercadona np. porusza codziennie dane milionów klientów i ponad 100 000 pracowników - każde wspomagane AI planowanie personelu musi być uzasadnialne zgodnie z Art. 22 RODO. Dla polskich firm z podobną skalą (Biedronka, Lidl Polska) benchmarkowanie tego poziomu compliance jest strategicznie istotne.

Po drugie AESIA (Agencia Española de Supervisión de la Inteligencia Artificial) i EU AI Act, który w Hiszpanii jest bezpośrednio stosowany. Systemy wysokiego ryzyka - szczególnie w zarządzaniu personelem, optymalizacji łańcuchów dostaw i produkcji energii - będą od 2026 systematycznie kontrolowane. Kto buduje w Walencji pipeline AI dla Workforce Management, buduje dla kategorii wysokiego ryzyka i musi od początku dokumentować pod kątem audytu AESIA.

Po trzecie CNMV i Banco de España dla łańcuchów finansowania między przemysłem a bankami. Nawet jeśli Walencja nie jest lokalizacją bankową Hiszpanii, duże firmy przemysłowe są wbudowane w złożone struktury Working Capital. Wspomagane AI prognozy cash flow, modele ryzyka kredytowego i strategie hedgingu stoją pod nadzorem obu organów. [Compliance EU AI Act](/pl/governance/eu-ai-act/) spotyka się tu z nadzorem finansowym.

## Typowe scenariusze wdrożeń w Walencji

Mercadona optymalizuje łańcuchy dostaw między setkami dostawców, kilkoma centrami logistycznymi i ponad 1700 filiami - każda wspomagana AI rekomendacja zamówienia wpływa bezpośrednio na marnotrawstwo żywności, świeżość i marże. Modele muszą pozostać prześledzalne, bo wynagrodzenie dostawców i pracowników jest związane z rekomendacjami. Ford Walencja planuje w Almussafes produkcję kilku serii modeli ze złożonymi łańcuchami dostaw w całej Półwyspie Iberyjskim - modele AI dla planowania mocy produkcyjnych muszą ostać się audytom koncernowym. Porcelanosa wykorzystuje Computer Vision do kontroli jakości produkcji ceramiki - każda zautomatyzowana decyzja o odrzucie musi być wykazywalna wobec wielkich klientów i dostawców. Iberdrola Energía monitoruje w regionie Walencji i Kastylii-La Manchy duże instalacje fotowoltaiki solarnej - wykrywanie anomalii AI w wydajności modułów musi być dokumentowane w Audit Trail, który pozostaje sprawdzalny dla właścicieli i ubezpieczycieli.

We wszystkich scenariuszach chodzi o przemysłową AI z wpływem fizycznym. [Decision Layer](/pl/decision-layer/) wnosi architekturę łączącą Audit Trail, eskalację i Cert-Ready by Design - dokładnie to, czego hiszpańskie organy nadzoru chcą widzieć jednocześnie.

Walencka specyfika to Port Walencji - największy port kontenerowy nad Morzem Śródziemnym i strategiczny węzeł dla handlu europejsko-azjatyckiego. Kto buduje tu AI dla dokumentacji frachtowej, obsługi celnej i optymalizacji logistyki, pracuje pod dodatkowym reżimem nadzoru Agencia Tributaria i organu Aduanas. Audit Trail musi być nie tylko RODO-compliant, ale też prześledzalny celnie - a to często w wielu językach i jurysdykcjach. Dla polskich logistów obsługujących tranzyt Polska-Hiszpania (Raben, DB Schenker) rozumienie walenckiego systemu celnego jest operacyjnie kluczowe.

## Jak Gosign obsługuje Walencję z Barcelony

Gosign obsługuje projekty walenckie z biura w Barcelonie (gosign.es) z hiszpańskojęzycznymi kierownikami projektów i inżynierami. Połączenie AVE Barcelona-Walencja trwa około trzech i pół godziny, samochodem w zależności od ruchu podobnie - comiesięczne terminy on-site w Mercadonie w Tavernes Blanques, w Ford Walencja w Almussafes, w Porcelanosie i w Marina Valencia to standardowy składnik każdego projektu. Discovery odbywa się na miejscu, z hiszpańskojęzycznymi osobami odpowiedzialnymi fachowo, funkcją compliance i Comité de Empresa przy tym samym stole. W razie potrzeby włączamy walenckojęzycznych interesariuszy. Lokalne klastry przemysłowe - Agri-Food wokół Mercadony i Consum, Automotive wokół Forda i dostawców, ceramika w Castellón - wymagają rozumienia branży, które zespół hiszpański wnosi z wieloletniej pracy z mittelstandem na Półwyspie Iberyjskim. Polscy inwestorzy z ekspozycją na hiszpańską logistykę czy Food Retail koordynowani są przez [biuro w Krakowie](/pl/agenci-ai-krakow/) - polskojęzyczny PM, hiszpańskojęzyczny delivery. Hamburska centrala dostarcza review architektoniczne i połączenie z niemieckimi standardami compliance przemysłowego - delivery, bezpośredni kontakt z klientem i kultura negocjacyjna rodzinnych firm Walencji leżą po stronie zespołu z Barcelony. Więcej na stronie [usługi AI Agents](/pl/uslugi/ai-agents/).

## Dlaczego Walencja to dobry punkt startowy dla Enterprise AI

Walencja jest idealnym rynkiem do walidacji przemysłowej AI z pełnym compliance, bez frykcji regulacyjnej i struktury kosztowej Madrytu. Kto w Walencji buduje pilotaż Cert-Ready by Design, ma referencję, która ostała się pod standardami AEPD, AESIA i EU AI Act - i która następnie w Madrycie, Barcelonie i przez Pireneje jest do obrony. Marina Valencia, program Lanzadera i Universitat Politècnica de València dostarczają talent, partnerów pilotażowych i połączenie badawcze.

Wnosimy z niemieckiego i polskiego pasa przemysłowego doświadczenie eksploatowania AI w złożonych łańcuchach dostaw i systemach produkcyjnych - z Governance by Design, Audit Trail i Human-in-the-Loop. Walencja jest właściwym rynkiem, żeby tę dyscyplinę skalować produkcyjnie na Półwyspie Iberyjskim. Kto tu startuje, ma blueprint dla każdego europejskiego regionu przemysłowego o podobnym profilu - od Zagłębia Ruhry przez Lombardię po Kraj Basków.

--- Agenci AI dla Firm w Warszawie | Gosign ---
> Enterprise AI Agents dla Warszawy. Zgodne z EU AI Act, RODO-konform, kompatybilne z Radą Zakładową. Audytowalne AI dla centrali korporacyjnych.

## Warszawa to korporacyjna stolica Polski z najgęstszą koncentracją regulatorów w Europie Środkowo-Wschodniej

W Warszawie mają siedziby PKO BP, PZU, Orlen, PGE, Santander Bank Polska, mBank, Allegro, CD Projekt RED i LPP - polscy liderzy branżowi obsługujący setki tysięcy klientów, pracowników i procesów biznesowych dziennie. Jednocześnie Warszawa jest siedzibą najważniejszych organów nadzoru kraju: UODO, KNF, NBP i ZUS pracują w odległości kilku kilometrów od siebie. Ta bliskość koncernów i regulatorów tworzy gęstość nadzoru, która nie istnieje w żadnym innym polskim mieście. Systemy AI uruchamiane w warszawskich centralach koncernów muszą nie tylko działać - muszą wytrzymać kontrolę nadzoru, który geograficznie znajduje się jeden przystanek metra dalej.

## Trzy wyzwania regulacyjne dla AI na rynku warszawskim

Po pierwsze nadzór KNF nad polskim sektorem finansowym. PKO BP, mBank, Pekao, Santander Bank Polska i PZU podlegają bezpośredniemu nadzorowi Komisji Nadzoru Finansowego. W procesach AML/KYC, scoringu kredytowym czy obsłudze szkód KNF oczekuje udokumentowanych podstaw modeli, pełnego Audit Trail i potwierdzonej ostatecznej decyzji człowieka w przypadkach ryzykownych. KNF w ostatnich latach doprecyzowała oczekiwania wobec automatycznego podejmowania decyzji - bank w Warszawie wdrażający AI bez wiarygodnej dokumentacji zgodności ryzykuje nie tylko upomnienia, ale ingerencje w bieżącą działalność.

Po drugie KSeF (Krajowy System e-Faktur). KSeF stopniowo staje się obowiązkowy dla wszystkich firm w Polsce. Koncerny takie jak Orlen, Allegro, LPP czy PGE muszą codziennie ekstrahować, walidować i archiwizować setki tysięcy faktur przychodzących i wychodzących zgodnie z KSeF. AI przetwarzające dane fakturowe musi spełniać wymogi struktury KSeF i w razie konfliktu wykazać, dlaczego zaksięgowanie odbyło się w taki, a nie inny sposób - klasyczny przypadek dla Document Agents z wymuszonym Human-in-the-Loop przy odchyleniach.

Po trzecie UODO i specyfika polskiej ustawy o ochronie danych osobowych. UODO ma siedzibę w Warszawie i bada polskie koncerny ze szczególną uwagą pod kątem profilowania automatycznego w rozumieniu art. 22 RODO. W systemach rekomendacyjnych Allegro, klasyfikacji szkód PZU czy scoringu PKO BP UODO oczekuje jasnej możliwości udzielania wyjaśnień i nadążalnych uzasadnień - każda osoba, której dotyczy decyzja, ma prawo dowiedzieć się, dlaczego została podjęta, a UODO i KNF muszą mieć możliwość to sprawdzić.

## Typowe scenariusze wdrożeń w Warszawie

PKO BP - operacje AML i KYC: największy bank w Polsce przetwarza miliony transakcji dziennie. Document Agents wyłapują dane identyfikacyjne, Workflow Agents kierują przypadki podejrzane zgodnie z progami KNF, a Decision Layer protokołuje każdą eskalację dla wewnętrznego komitetu AML i kontroli zewnętrznych.

Allegro - fraud detection: największy polski marketplace e-commerce konkuruje z Amazonem. Przy milionach zamówień dziennie Decision Agents weryfikują wzorce ryzyka w czasie rzeczywistym - zawsze z możliwością prześledzenia poszczególnych decyzji na potrzeby audytu UODO.

PZU - obsługa szkód: lider polskiego rynku ubezpieczeniowego obsługuje tysiące szkód dziennie. Workflow Agents klasyfikują zgłoszenia szkód według taryfy, regionu i złożoności, z wymuszonym przeglądem człowieka przy przekroczeniu progów - to wprost wymaganie KNF.

KSeF - ekstrakcja faktur dla Orlen i PGE: oba koncerny stoją pod presją obowiązku KSeF. Document Agents wyłapują strukturalne dane faktur, walidują je względem schematu KSeF i kierują odchylenia do księgowych do weryfikacji.

## Jak Gosign obsługuje Warszawę z biura w Krakowie

Gosign obsługuje warszawskie projekty z biura w Krakowie (gosign.pl) z polskojęzycznymi kierownikami projektów i inżynierami. Odległość Kraków - Warszawa pociągiem Intercity Premium pokonujemy w niespełna trzy godziny, samochodem podobnie - regularna obecność u klientów w Warsaw Spire Tech, na Rondzie Daszyńskiego czy bezpośrednio w centralach PKO BP, Allegro, Orlen, PZU i mBanku to standard, nie wyjątek. Discovery workshops odbywają się na miejscu, z polskojęzycznymi właścicielami biznesowymi, funkcją compliance i przedstawicielem Rady Zakładowej przy jednym stole. Build i sprint reviews prowadzimy następnie tygodniowo po polsku lub angielsku, z miesięcznymi wizytami sterującymi w Warszawie i krótkim czasem reakcji przy eskalacjach UODO lub KNF. Hamburska centrala dba o decyzje architektoniczne i połączenie ze spółkami-matkami w Niemczech czy Szwajcarii - delivery, codzienna praca i kontakt z klientem leżą po stronie krakowskiego zespołu na równi z warszawskimi interesariuszami.

## Dlaczego Warszawa to dobry punkt startowy dla Enterprise AI

Warszawa to jedyny rynek w Europie Środkowo-Wschodniej, w którym jednocześnie spełnione są wszystkie trzy warunki sukcesu Enterprise AI: maksymalna gęstość koncernów, maksymalna gęstość regulatorów oraz ekosystem technologiczny z Google for Startups Warsaw, Campus Warsaw i klastrem Warsaw Spire Tech. Kto uruchomi agenta AI dla warszawskiego banku, ubezpieczyciela lub e-commerce, ten zdał najtrudniejszy stres test regulacyjny w Europie Środkowo-Wschodniej. Skalowanie do innych polskich lokalizacji - [Kraków](/pl/agenci-ai-krakow/), [Wrocław](/pl/agenci-ai-wroclaw/), [Gdańsk](/pl/agenci-ai-gdansk/) - jest wtedy nie drugim buildem, lecz zmianą konfiguracji.

Dochodzi jeszcze aspekt, który czyni Warszawę szczególnie atrakcyjną dla niemieckich, szwajcarskich i holenderskich spółek-matek: warszawskie koncerny są od lat przyzwyczajone do zachodnioeuropejskich standardów compliance. PKO BP współpracuje z niemieckimi bankami korespondentami, mBank należy od dziesięcioleci do grupy Commerzbank, Santander Bank Polska jest częścią hiszpańskiej struktury Santander. Te koncerny wiedzą, co znaczy oczekiwanie BaFin, FINMA czy DNB wobec AI, a ich wewnętrzne funkcje compliance są na to przygotowane. Wdrożenie Decision Layer w Warszawie rzadko spotyka się z oporem wobec wymogu pełnej audytowalności - to tutaj od lat operacyjna rzeczywistość. Governance by Design w Warszawie nie jest hasłem sprzedażowym, lecz warunkiem wstępu. Kto przejdzie Warszawę, przejdzie też resztę Polski i większość rynków UE od razu. Więcej kontekstu o [EU AI Act](/pl/governance/eu-ai-act/) i jego polskim wdrożeniu znajdziesz w sekcji Governance, a o architekturze [Decision Layer](/pl/decision-layer/) - na stronie produktu.

--- Agenci AI dla Firm w Wielkiej Brytanii | Gosign ---
> Enterprise AI Agents dla firm brytyjskich. UK GDPR + EU RODO dual-compliance. Audytowalne AI spełniające zarówno brytyjskie, jak i unijne wymogi regulacyjne.

## Wielka Brytania to jedyny rynek bliski UE z obowiązkową podwójną regulacją

Wielka Brytania to jedyna duża europejska przestrzeń gospodarcza, w której każda średnia i duża firma z kontynentalnym biznesem musi jednocześnie uczynić swoje systemy AI audytowalnymi wobec dwóch niezależnych reżimów regulacyjnych. Po stronie brytyjskiej są UK GDPR, ICO jako organ ochrony danych, FCA i PRA dla usług finansowych, Ofcom dla telekomunikacji i mediów oraz CMA dla konkurencji. Po stronie UE nadal obowiązują RODO i EU AI Act dla każdego zestawu danych dotyczącego klientów UE, pracowników UE lub spółek zależnych UE. HSBC, Barclays, Lloyds i NatWest prowadzą funkcje koncernowe obsługujące oba światy równolegle. BP, Shell, AstraZeneca, GSK i Unilever przetwarzają codziennie dane, które raz trafiają do jurysdykcji UK, a raz do UE. Tesco, Sainsbury's, BT, Vodafone, ITV i BBC stoją przed tą samą rzeczywistością w skali krajowej. Dla polskich firm z ekspozycją na UK (polscy dostawcy dla banków londyńskich, Polacy pracujący w City, Asseco czy Comarch dla brytyjskich klientów) post-brexitowa podwójna regulacja jest realnością operacyjną. Sceny rozkładają się między Londynem, Manchesterem, Edynburgiem, Glasgow, Birmingham, Leeds i Bristolem - ale problem regulacyjny jest wszędzie ten sam.

## Trzy wyzwania regulacyjne dla AI na rynku brytyjskim

Po pierwsze UK GDPR i nadzór ICO. Po Brexicie w UK obowiązuje UK GDPR jako krajowe prawo ochrony danych, nadzorowane przez Information Commissioner's Office. Przy zautomatyzowanym podejmowaniu decyzji ICO oczekuje udokumentowanych podstaw modeli, możliwości udzielania wyjaśnień osobom, których dane dotyczą, oraz kompletnego Audit Trail. Planowany Data Protection and Digital Information Bill wprowadzi niektóre UK-specyficzne ułatwienia bez znoszenia podstawowych wymogów. Kto przemieszcza dane między UK a UE, potrzebuje dodatkowo odpowiednich ram Adequacy lub SCC - warstwa compliance, której żadna inna europejska jurysdykcja nie wymaga w tej formie. Dla polskich firm z klientami brytyjskimi oznacza to: polski RODO + UK GDPR jako minimum, plus ścieżka transgraniczna.

Po drugie FCA, PRA i Bank of England dla sektora finansowego. HSBC, Barclays, Lloyds i NatWest są pod bezpośrednim nadzorem FCA i PRA. FCA w wielu publikacjach jasno dała do zrozumienia, że przy decyzjach wspomaganych AI w udzielaniu kredytów, underwritingu, AML i Conduct-Risk oczekuje tych samych standardów wyjaśnialności i nadzoru co dla decyzji ludzkich. UK-specyficzne podejście: zamiast jednolitej ustawy o AI jak EU AI Act, UK stawia na regulację sektorową - FCA ustala standardy dla Finance, ICO dla ochrony danych, Ofcom dla komunikacji. Kto jako brytyjski koncern stosuje AI w wielu sektorach, ma do czynienia z różnymi oczekiwaniami per regulator. W odróżnieniu od polskiej KNF, FCA ma znacznie szerszy mandat wykonawczy przy AI-specific guidance.

Po trzecie EU AI Act dla każdej brytyjskiej firmy z biznesem w UE. EU AI Act obowiązuje nie tylko firmy z UE. Każda brytyjska firma dostarczająca outputy AI w UE - czy to przez niemiecką spółkę córkę, holenderski oddział czy bezpośrednią dystrybucję do klientów UE - podlega eksterytorialnemu zakresowi stosowania EU AI Act. Oznacza to: HSBC potrzebuje dla swojego niemieckiego biznesu detalicznego zgodności z EU AI Act. Unilever potrzebuje jej dla każdego algorytmu konsumenckiego odtwarzanego w UE. AstraZeneca potrzebuje jej dla wspomagania decyzji klinicznych w centrach badań w UE. Architektura UK-only nie wystarczy dla żadnego z tych koncernów.

## Typowe scenariusze wdrożeń w Wielkiej Brytanii

HSBC i Barclays Conduct Risk Monitoring: brytyjskie wielkie banki są pod podwójnym nadzorem FCA i ESMA. Document Agents ekstrahują wypowiedzi istotne dla compliance z interakcji z klientami, Decision Layer routuje przypadki podejrzane wzdłuż progów specyficznych dla jurysdykcji, z Human-in-the-Loop przy każdej eskalacji i Audit Trail możliwym do przedstawienia zarówno FCA, jak i ESMA.

BP i Shell operacje HSE: globalne koncerny energetyczne generują codziennie tysiące raportów bezpieczeństwa i środowiska. Workflow Agents klasyfikują incydenty według wagi, regionu i aspektów podlegających zgłoszeniu - z różnymi ścieżkami eskalacji zależnie od lokalizacji (UK HSE, EPA, BNetzA, polska OUG).

AstraZeneca i GSK Pharmacovigilance: brytyjskie koncerny farmaceutyczne prowadzą ogólnoeuropejskie badania kliniczne. Document Agents sprawdzają raporty Adverse Event, klasyfikują je według wymogów MHRA i EMA i routują krytyczne wyniki do ludzkich odpowiedzialnych za pharmacovigilance - każda decyzja audytowalna wobec obowiązującego standardu regulacyjnego.

Unilever i Tesco algorytmy konsumenckie: globalne koncerny dóbr konsumpcyjnych i detalu stosują AI w rekomendacji, pricingu i promocji. Decision Agents sprawdzają każdą odtworzoną decyzję wobec UK Consumer Protection Standards i EU AI Act jednocześnie, z prześledzalnymi uzasadnieniami dla ICO i nadzoru konsumenckiego.

## Jak Gosign obsługuje Wielką Brytanię z Hamburga i Krakowa

Gosign obsługuje projekty UK z hamburskiej siedziby głównej. Kombinacja ekspertyzy regulacyjnej UE i hamburskiej lokalizacji nie jest dla brytyjskich koncernów z biznesem UE wadą, lecz warunkiem - właśnie podwójną regulację da się budować czysto tylko wtedy, gdy oba światy są jednocześnie rozumiane przez jeden zespół. Discovery odbywa się na miejscu w Londynie, Manchesterze lub Edynburgu, zależnie od lokalizacji koncernu. Następnie build działa zdalnie, z dokumentacją angielskojęzyczną, cotygodniowymi sprint review przez wideo i stałym punktem kontaktu w Hamburgu. Wizyty on-site co 4-6 tygodni, bezpośredni lot Hamburg-Londyn trwa nieco ponad godzinę i piętnaście minut. Wizyty w FCA, PRA lub ICO Gosign towarzyszy na żądanie wspólnie z wewnętrznym działem prawnym klienta. Dla polskich klientów z ekspozycją na UK (dostawcy, partnerzy B2B) koordynację zapewnia nasze [biuro w Krakowie](/pl/agenci-ai-krakow/) - polskojęzyczny PM po stronie polskiego klienta, angielskojęzyczny delivery po stronie UK. Więcej na stronie [usługi AI Agents](/pl/uslugi/ai-agents/).

## Dlaczego Wielka Brytania to dobry punkt startowy dla Enterprise AI

Żaden inny kraj w Europie nie zmusza koncernów z taką konsekwencją do architektury reguł specyficznych dla jurysdykcji. Kto zbuduje agenta AI spełniającego jednocześnie UK GDPR, standardy FCA i EU AI Act, rozwinął architekturę, która w praktycznie każdym zachodnim rynku jest już tylko jedną zmianą konfiguracji dalej. Dokładnie tu wchodzi Decision Layer Gosign z zestawami reguł specyficznych dla jurysdykcji: zamiast eksploatować dwa równoległe systemy, działa jedna platforma z dwoma zestawami reguł - UK w routingu krajowym, UE w routingu UE, i Audit Trail, który zależnie od odbiorcy dokumentuje właściwy zestaw reguł. Dla brytyjskich koncernów z biznesem UE to jedyna architektura, która nie okaże się ślepą uliczką najpóźniej przy pierwszym audycie ICO lub ESMA. Cert-Ready by Design oznacza tu dosłownie: gotowy do dwóch certyfikacji, na jednej bazie kodu. Więcej kontekstu o [EU AI Act](/pl/governance/eu-ai-act/) i jego eksterytorialnym działaniu znajdziesz w obszarze Governance. Zobacz też [Londyn](/pl/agenci-ai-londyn/) i [Amsterdam](/pl/agenci-ai-amsterdam/).

--- Agenci AI dla Firm we Wrocławiu | Gosign ---
> Enterprise AI Agents dla Wrocławia. IT-hub nr 2 w Polsce. EU AI Act compliant, RODO-konform. Zarządzanie z Krakowa.

## Wrocław to przemysłowo-IT-owa hybryda Polski - tu spotykają się dostawcy automotive z banking operations

We Wrocławiu Bosch Wrocław, LG Electronics, 3M, Volvo Wrocław, Whirlpool i Toyota Motor Manufacturing Poland prowadzą zakłady produkcyjne i centra inżynieryjne z tysiącami pracowników. Równocześnie mają tu siedzibę UBS Wrocław (powstały z dawnego centrum Credit Suisse), HP, Nokia Wrocław i kilka banking shared services. To połączenie jest w Polsce wyjątkowe: jedno miasto, w którym tej samej godziny powstaje dokumentacja inżynieryjna dla fabryki samochodów oraz raporty researchowe dla szwajcarskiego banku inwestycyjnego. Wrocław Technology Park i Capital Park tworzą fizyczny klaster, a Politechnika Wrocławska dostarcza inżynierów do obu światów. Kto buduje Enterprise AI we Wrocławiu, musi obsługiwać dwie logiki przemysłowe naraz.

## Trzy wyzwania regulacyjne dla AI na rynku wrocławskim

Po pierwsze UODO i RODO w kontekście multi-entity. Wrocławskie lokalizacje często przetwarzają dane swoich zachodnioeuropejskich spółek-matek. UBS Operation we Wrocławiu podlega jednocześnie wymogom FINMA, ESMA i UODO. Funkcja inżynieryjna Bosch we Wrocławiu generuje dokumentację produktową, która trafia do Stuttgartu, Szanghaju i Detroit. Polska ustawa o ochronie danych osobowych przewiduje, że automatyczne profilowanie i podejmowanie decyzji musi pozostać nadążalne - nawet jeśli modele są trenowane w niemieckiej lub szwajcarskiej centrali koncernu. Architektury AI bez pełnego Audit Trail nie da się tu wdrożyć.

Po drugie nadzór KNF nad rosnącą funkcją banking outsourcing. UBS, kilka średniej wielkości operacji inwestycyjnych i credit-servicing providerów pracuje we Wrocławiu pod regulacyjnym dachem Komisji Nadzoru Finansowego oraz dodatkowo regulatorów krajów macierzystych. W przypadku narzędzi research, automatycznej klasyfikacji dokumentów i compliance screening KNF oczekuje, że każda decyzja modelu da się sprowadzić do osoby ludzkiej odpowiedzialnej za ostateczne rozstrzygnięcie - włącznie z wersją danych użytych w momencie podejmowania decyzji.

Po trzecie EU AI Act z naciskiem na zastosowania wysokiego ryzyka w HR i przemyśle. Wrocławskie zakłady produkcyjne coraz częściej używają AI do kontroli jakości, predictive maintenance i planowania zmian. Algorytmy planowania zmian podlegają Annex III EU AI Act (systemy wysokiego ryzyka w HR), kontrola jakości przez modele vision dotyka odpowiedzialności za produkt i zgodności CE. Również KSeF jako obowiązkowy system e-faktur dotyczy każdego wrocławskiego producenta i shared service. UODO oczekuje w obu przypadkach pełnej dokumentacji zgodności. Cert-Ready by Design dla wrocławskich zakładów produkcyjnych nie jest argumentem sprzedażowym, lecz koniecznym warunkiem audytów ze strony spółek-matek i ich certyfikatorów.

## Typowe scenariusze wdrożeń we Wrocławiu

LG Electronics - kontrola jakości: wrocławska fabryka LG produkuje komponenty wyświetlaczy w dużych wolumenach. Vision Decision Agents weryfikują wady powierzchniowe w czasie rzeczywistym, z wymuszoną ludzką eskalacją w przypadkach granicznych. Każda decyzja jest protokołowana w Audit Trail z wersją modelu, datasetem treningowym i ID recenzenta.

UBS Wrocław - operacje research: dawna operacja Credit Suisse, teraz część UBS, prowadzi jedną z największych funkcji research poza Zurychem. Document Agents wyłapują kluczowe dane z raportów rocznych, klasyfikują earnings calls i kierują wypowiedzi istotne compliance do analityków - każdy krok protokołowany dla audytów FINMA i KNF.

HP - routing service desk: wrocławskie centrum usług HP obsługuje klientów w wielu językach i strefach czasowych. Workflow Agents klasyfikują przychodzące tickety według języka, klienta i poziomu eskalacji. Decision Layer routuje automatycznie, z Human-in-the-Loop przy klientach VIP i ticketach grożących naruszeniem SLA.

Bosch - dokumentacja produkcyjna: wrocławski oddział Boscha generuje codziennie tysiące dokumentów technicznych. Document Agents wyłapują specyfikacje istotne regulacyjnie, porównują je z normami krajowymi i automatycznie kierują konflikty do kierownictwa inżynieryjnego w Stuttgarcie lub Wrocławiu.

## Jak Gosign obsługuje Wrocław z biura w Krakowie

Gosign obsługuje wrocławskie projekty z krakowskiego biura (gosign.pl) z polskojęzycznymi inżynierami i kierownikami projektów. Kraków - Wrocław pociągiem lub samochodem to około trzy godziny - regularne wizyty na miejscu we Wrocław Technology Park, Capital Park lub bezpośrednio w pomieszczeniach inżynieryjnych Bosch, LG Electronics, UBS Wrocław i HP są częścią każdej fazy projektu, nie wyjątkiem. Discovery odbywa się dwudniowo na miejscu, z polskojęzycznymi właścicielami biznesowymi, funkcją compliance i przedstawicielem Rady Zakładowej przy jednym stole. Następnie build i sprint reviews prowadzimy z krakowskim zespołem, po polsku i angielsku, z miesięcznymi steering committees we Wrocławiu. Polscy inżynierowie rozumieją podwójny świat Wrocławia - tradycyjny przemysł i banking outsourcing - z własnej praktyki zawodowej i bez kulturowego tłumaczenia dostosowują dokumentację, język warsztatu i ścieżki eskalacji. Hamburska centrala bierze na siebie review architektoniczne i połączenie z niemieckimi i szwajcarskimi spółkami-matkami w Stuttgarcie, Monachium czy Zurychu. Więcej o naszej ofercie [agentów AI](/pl/uslugi/ai-agents/) na stronie usług.

## Dlaczego Wrocław to dobry punkt startowy dla Enterprise AI

Wrocław to najnietypowszy rynek Enterprise AI w Polsce, ponieważ zderzają się tu dwa światy: tradycyjny przemysł i banking outsourcing. Kto zbuduje agenta AI, który działa jednocześnie w fabryce Boscha i operacji UBS, ten stworzył architekturę odległą od każdej innej polskiej lokalizacji o jedną zmianę konfiguracji. Politechnika Wrocławska dostarcza inżynierów rozumiejących ten podwójny świat, a wrocławski ekosystem technologiczny jest po [Krakowie](/pl/agenci-ai-krakow/) drugim co do wielkości w kraju.

Dla niemieckich firm średniej wielkości z polskimi spółkami-córkami Wrocław jest często pierwszą zagraniczną lokalizacją, w której naprawdę potrzebne jest produkcyjne AI - udane wdrożenie wrocławskie staje się tym samym wzorcem dla późniejszego skalowania. Dochodzi geograficzna bliskość niemieckiej granicy: pociąg z Berlina do Wrocławia jedzie niespełna cztery godziny, wizyta na miejscu mieści się w jednym dniu pracy. To połączenie zachodnioeuropejskiej dostępności, środkowoeuropejskich kosztów talentów i ścisłej regulacji UE czyni z Wrocławia lokalizację, która nie powinna być pominięta w portfolio żadnego niemieckiego koncernu. Governance by Design nie jest tu hasłem marketingowym, lecz warunkiem akceptacji ze strony spółki-matki - i dokładnie tym warunkiem, który spełnia od początku poprawnie wdrożony [Decision Layer](/pl/decision-layer/). Więcej o naszym podejściu w Polsce znajdziesz na [stronie kraju](/pl/agenci-ai-polska/).

--- Agenci AI dla Firm w Zurychu | Gosign ---
> Enterprise AI Agents dla Zurychu. Swiss FADP + EU RODO dual-compliance, FINMA-aware. Audytowalne AI dla centrum finansowego Szwajcarii.

## Zurych to jedyne europejskie centrum finansowe, w którym architekturę AI trzeba planować bez EU AI Act - i właśnie to jest przewagą strategiczną

Szwajcaria nie jest w UE. Kto rozumie Zurych jako rynek, zaczyna od tego faktu: EU AI Act nie obowiązuje tu bezpośrednio, RODO nie jest decydującym prawem ochrony danych, a BaFin nie ma właściwości. Zamiast tego obowiązuje nFADP, zrewidowana szwajcarska ustawa o ochronie danych od września 2023, oraz FINMA jako federalny nadzór rynku finansowego. W dzielnicy Paradeplatz siedzą UBS - po przejęciu Credit Suisse w 2023 zdecydowanie największy szwajcarski bank - oraz Zurich Insurance Group i Swiss Re jako dwaj z największych reasekuratorów świata. ABB ma centralę koncernową w Oerlikon, Sika w Baar, Holcim w Jonie. Google prowadzi w Zurychu jedno ze swoich największych centrów Engineering poza USA. Ta mieszanka wytwarza rynek AI z wysoką dojrzałością techniczną i ramą regulacyjną, która jest bardziej pragmatyczna i sektor-specyficzna niż regulacja UE. Dla polskich firm z ekspozycją szwajcarską (polscy poddostawcy UBS, polski IT dla Swiss Re) Zurych to rynek o odmiennej logice niż Frankfurt czy Wiedeń.

## Trzy wyzwania regulacyjne dla AI na rynku zuryskim

Pierwsza to FINMA jako nadzór finansowy. W 2024 skonkretyzowała swoje oczekiwania dotyczące Governance modeli AI w bankach i ubezpieczeniach we własnym dokumencie nadzorczym - z jasnymi wymogami dotyczącymi ryzyka modeli, wyjaśnialności i audytowalności. UBS, Zurich Insurance, Swiss Re i osiadłe tu banki prywatne muszą walidować każdy komponent AI w zarządzaniu ryzykiem, underwritingu czy wealth management wobec tych oczekiwań FINMA.

Druga to EDÖB jako federalny inspektor ochrony danych i jawności oraz nFADP - nowa ustawa o ochronie danych od 2023. Jest ona zasadniczo kompatybilna z RODO, ale ma własne obowiązki Privacy by Design, profiling i zautomatyzowanych decyzji, które muszą być oddzielnie wykazane. Dla polskiego UODO znajomość szwajcarskiej specyfiki to dodatkowa warstwa, bo Szwajcaria nie należy do systemu One-Stop-Shop UE.

Trzecia to sam szwajcarski dyskurs regulacyjny AI: Rada Federalna w 2024 zdecydowała, że Szwajcaria nie stworzy własnego obszernego AI Act, lecz będzie regulowała sektor-specyficznie - co oznacza, że FINMA, Swissmedic i BAKOM formułują własne wymagania dla AI w swoich domenach. Kto planuje w Zurychu, musi znać odpowiedni nadzór sektorowy w szczegółach. Więcej tła w [Governance EU AI Act](/pl/governance/eu-ai-act/) - logika UE pozostaje dla szwajcarskich firm z biznesem UE drugim wektorem compliance.

## Typowe scenariusze wdrożeń w Zurychu

Przy UBS i w szerszym szwajcarskim środowisku banking widzimy agentów reporting wealth management, którzy przygotowują strukturyzowaną komunikację z klientami i raporty performance - doradca klienta decyduje, agent strukturyzuje. Przy Zurich Insurance agenci wspierają obsługę szkód w ubezpieczeniach majątkowych i życiowych, z jasnym wzbogacaniem zgłoszenia szkody o dane umowne, opinie rzeczoznawców i kontrole wiarygodności - ostateczną decyzję podejmuje urzędnik z tłem ubezpieczeniowym. Przy Swiss Re chodzi o modelowanie reasekuracji i modelowanie Cat, w których underwriterzy otrzymują wyniki jako propozycję i odpowiadają za ostateczną akceptację. ABB pracuje nad use cases Industrial Control System, w których operatorzy przemysłowi podejmują ostateczną decyzję. Google Zurich wykorzystuje własne narzędzia Engineering i jako rynek dla zewnętrznej architektury agenckiej jest mniej istotny - ale środowisko talentu technicznego w Zurychu jest przez to silnie naznaczone. Przy Sika i Holcim widzimy Document Agents do analizy umów i kart charakterystyki w środowisku chemii budowlanej. We wszystkich case'ach [Decision Layer](/pl/decision-layer/) trzyma łańcuch uzasadnień jako Audit Trail - w formie, która spełnia jednocześnie wymagania FINMA i obowiązki nFADP.

## Jak Gosign obsługuje Zurych z Hamburga

Gosign nie ma szwajcarskiego oddziału. Rynek szwajcarski akceptuje niemieckich usługodawców bez lokalnej spółki, o ile przechowywanie danych, engineering i struktura kontraktowa są jasno uregulowane. Konkretnie oznacza to: pracujemy jako niemiecka GmbH z siedzibą w Hamburgu, struktura kontraktu idzie za prawem szwajcarskim lub modelem dualnym, przechowywanie danych odbywa się albo na szwajcarskiej infrastrukturze cloud (Swisscom, Exoscale), albo w setupie UE eksploatowanym wg standardów nFADP z odpowiednimi środkami ochrony. Warsztaty discovery robimy na miejscu w Zurychu - bezpośredni lot Hamburg-Zurych trwa godzinę, ICE przez Bazyleę to sensowna alternatywa. W fazie engineeringu pracujemy zdalnie z dwutygodniowymi dniami on-site i akcentem na terminach walidacyjnych istotnych dla FINMA. Ważna jest explicit separacja między zestawami reguł dla danych szwajcarskich a zestawami reguł dla danych UE - Decision Layer nosi obie logiki równolegle, bo wiele szwajcarskich koncernów ma biznes UE i musi spełniać oba reżimy jednocześnie. Dla polskich klientów obsługujących szwajcarskich gigantów (Asseco, Comarch dla UBS) koordynację zapewnia nasze [biuro w Krakowie](/pl/agenci-ai-krakow/). Klastry jak ETH AI Center, Impact Hub Zürich i Zurich Insurance Innovation wykorzystujemy do wymiany technicznej. Więcej na stronie [usługi AI Agents](/pl/uslugi/ai-agents/).

## Dlaczego Zurych to dobry punkt startowy dla Enterprise AI

Szwajcaria ma przewagę strukturalną, której rynki UE nie mają: regulacja jest sektor-specyficzna, pragmatyczna i z reguły mniej formalistyczna niż EU AI Act. Kto w Zurychu wprowadza pierwszego AI Agenta w regulowanym środowisku na produkcję, ma go obronionego wobec oczekiwań FINMA, wobec nFADP i wobec szwajcarskiego roszczenia do technicznej czystości. Ta architektura jest następnie przygotowana do skalowania na obszar UE, bo leżące u podstaw Model Governance spełnia już najwyższy standard. Dochodzi środowisko techniczne: ETH Zurych jest jedną z wiodących na świecie placówek badawczych ML, ETH AI Center skupia około 100 grup badawczych, a Google Zurich, IBM Research Zurich oraz środowisko CERN w zachodniej Szwajcarii czynią rynek jedną z najbardziej dojrzałych lokalizacji technicznych Europy. Kto w 4-6 tygodni ma pierwszego AI Agenta w szwajcarskim koncernie produktywnie, buduje na rynku, który nagradza pragmatyczną architekturę i unika zbędnej biurokracji. Zobacz też [Amsterdam](/pl/agenci-ai-amsterdam/) i [Londyn](/pl/agenci-ai-londyn/).

--- Agencja cyfrowa Hamburg | Web, AI, TYPO3 ---
> Gosign to hamburska agencja cyfrowa: tworzenie stron, integracja AI i TYPO3. 25 lat doświadczenia. Fokus na B2B.

<!-- Kim jest Gosign? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Kim jest Gosign?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Gosign to hamburska agencja cyfrowa z 25-letnim doświadczeniem w tworzeniu stron internetowych, systemach TYPO3 i integracji AI dla przedsiębiorstw. Założona w 1999 roku, dziś specjalizuje się w stronach B2B, projektach Enterprise CMS i infrastrukturach AI. Gosign obsługuje średnie przedsiębiorstwa, uczelnie wyższe i instytucje sektora publicznego w Europie.
</p>
</div>
</section>

<!-- Dlaczego Gosign? -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Dlaczego Gosign?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Ponieważ nie budujemy tylko stron internetowych - budujemy infrastrukturę cyfrową. Trzy kluczowe obszary, jeden zespół:
</p>
</div>
</section>

<!-- Tworzenie stron & CMS -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Tworzenie stron i systemy CMS</h2>
<p class="text-body text-gosign-text leading-relaxed">
Strony, które działają. Technicznie i biznesowo. TYPO3, WordPress, Astro, architektury Headless. Od koncepcji po uruchomienie, od 10&nbsp;stron do 10&nbsp;000. Gosign przeanalizował ponad 800 rozszerzeń TYPO3 i realizuje projekty Enterprise CMS od dwóch dekad.
</p>
</div>
</section>

<!-- Integracja AI -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Integracja AI dla przedsiębiorstw</h2>
<p class="text-body text-gosign-text leading-relaxed">
Infrastruktury AI bezpośrednio w środowisku Twojej firmy: asystenci AI, AI Agents, hosting modeli (DeepSeek, Llama, Mistral) na własnej infrastrukturze. Zgodne z RODO, NIS2, bez wycieku danych do podmiotów trzecich. Gosign buduje rozwiązania AI, które pasują do istniejących systemów IT.
</p>
</div>
</section>

<!-- Specjalizacja TYPO3 -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Specjalizacja TYPO3</h2>
<p class="text-body text-gosign-text leading-relaxed">
Ponad 800 rozszerzeń TYPO3 monitorowanych, ponad 500 pomyślnie wdrożonych. Od wyszukiwania Enterprise Solr przez integracje SSO po e-commerce z aimeos. Gosign jest jednym z najbardziej doświadczonych dostawców usług TYPO3 w Europie.
</p>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Porozmawiajmy o Twoim projekcie - 30&nbsp;minut, bezpłatnie.</h3>
<p class="text-body text-gosign-text mb-6">Przeanalizujemy Twój projekt, oszacujemy nakład pracy i harmonogram, bez zobowiązań.</p>
<a
href="/pl/kontakt/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Umów spotkanie
</a>
<p class="text-small text-gosign-text-light mt-4">25 lat doświadczenia · 800+ rozszerzeń · rozwój wspomagany AI</p>
</div>
</section>

<!-- Comparison Table -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Co wyróżnia Gosign na tle innych agencji cyfrowych</h2>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Kryterium</th>
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Typowa agencja</th>
<th class="py-3 text-small font-bold text-gosign-dark">Gosign</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Głębokość CMS</td>
<td class="py-3 pr-4 text-body text-gosign-text">Podstawy WordPress</td>
<td class="py-3 text-body text-gosign-text">TYPO3 Enterprise + WordPress + Headless</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Kompetencje AI</td>
<td class="py-3 pr-4 text-body text-gosign-text">Prompty ChatGPT</td>
<td class="py-3 text-body text-gosign-text">Własne infrastruktury AI, hosting modeli</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Szybkość realizacji</td>
<td class="py-3 pr-4 text-body text-gosign-text">Klasyczna</td>
<td class="py-3 text-body text-gosign-accent-text font-semibold">Wspomagana AI: 60-80&nbsp;% szybciej</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Fokus branżowy</td>
<td class="py-3 pr-4 text-body text-gosign-text">Wszystko dla wszystkich</td>
<td class="py-3 text-body text-gosign-text">B2B, średnie przedsiębiorstwa, uczelnie, sektor publiczny</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Bezpieczeństwo</td>
<td class="py-3 pr-4 text-body text-gosign-text">Standardowy hosting</td>
<td class="py-3 text-body text-gosign-text">Infrastruktury zgodne z NIS2, monitoring bezpieczeństwa</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Lokalizacja</td>
<td class="py-3 pr-4 text-body text-gosign-text">Remote/globalnie</td>
<td class="py-3 text-body text-gosign-text">Hamburg, osobista obsługa klienta</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Branże -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Branże</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
Gosign pracuje dla firm, które traktują infrastrukturę cyfrową poważnie:
</p>
<div class="grid md:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Przemysł maszynowy i produkcja</h3>
<p class="text-body text-gosign-text">Strony B2B z konfiguratorami produktów, portale dla dystrybutorów, dokumentacja techniczna</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Motoryzacja</h3>
<p class="text-body text-gosign-text">Portale marek, sieci dilerów, cyfrowe salony wystawowe</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Zdrowie i farmacja</h3>
<p class="text-body text-gosign-text">Strony zgodne z regulacjami, portale dla pacjentów</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Edukacja i uczelnie wyższe</h3>
<p class="text-body text-gosign-text">SSO Shibboleth, wyszukiwarki kierunków studiów, dostępne strony internetowe</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Stowarzyszenia i sektor publiczny</h3>
<p class="text-body text-gosign-text">Zarządzanie członkami, wielojęzyczne portale, dostępność</p>
</div>
</div>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
Gosign to hamburska agencja cyfrowa z 25-letnim doświadczeniem w tworzeniu stron, TYPO3 i integracji AI.
Obsługujemy europejskie i polskie przedsiębiorstwa z naszej siedziby w Hamburgu.
Przeanalizowaliśmy ponad 800 rozszerzeń TYPO3 i dzięki wsparciu AI realizujemy projekty
do 70&nbsp;% szybciej niż tradycyjnymi metodami.
</p>
<p class="text-small text-gosign-text-light mt-2">Stan na: luty 2026</p>
</div>
</section>

<!-- Powiązane tematy -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Powiązane tematy</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/pl/agencja-wordpress/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Tworzenie stron</p>
<p class="text-body font-semibold text-gosign-dark">Agencja WordPress Hamburg</p>
</a>
<a href="/pl/typo3-extensions/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">CMS</p>
<p class="text-body font-semibold text-gosign-dark">TYPO3 Extensions</p>
</a>
<a href="/pl/bezpieczenstwo-stron-standardy/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Bezpieczeństwo</p>
<p class="text-body font-semibold text-gosign-dark">Bezpieczeństwo stron - standardy NIS2</p>
</a>
</div>
</div>
</section>

--- Agencja WordPress Hamburg | Od 1999 ---
> Agencja WordPress z Hamburga: tworzenie stron, utrzymanie i projekty wspomagane AI. Od 25 lat. Bezpłatna konsultacja.

<!-- Co oferuje Gosign? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Co oferuje Gosign jako agencja WordPress?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Gosign to hamburska agencja WordPress z 25-letnim doświadczeniem w tworzeniu stron. Gosign tworzy strony WordPress dla firm B2B: własne motywy, tworzenie wtyczek, sklepy WooCommerce, Headless WordPress z nowoczesnymi frontendami. Od 2023 roku Gosign wykorzystuje rozwój wspomagany AI. Projekty WordPress powstają 60-80&nbsp;% szybciej przy zachowaniu tej samej jakości.
</p>
</div>
</section>

<!-- Dlaczego Gosign -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Dlaczego Gosign zamiast zwykłej agencji WordPress?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Ponieważ WordPress to tylko część obrazu. Gosign zna TYPO3, architektury Headless i infrastruktury AI - i uczciwie doradza, czy WordPress to właściwy wybór. Dla stron treściowych: prawie zawsze tak. Dla portali Enterprise ze złożonym systemem uprawnień: może TYPO3.
</p>
</div>
</section>

<!-- Usługi WordPress -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">Usługi WordPress</h2>
<div class="grid md:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Tworzenie własnych motywów</h3>
<p class="text-body text-gosign-text">
Żadnych gotowych szablonów. Gosign tworzy motywy WordPress dokładnie według projektu - responsywne, wydajne, dostępne. Zoptymalizowane pod Gutenberg, gotowe na Full Site Editing. AI generuje szkielety motywów, senior developerzy je dopracowują.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Tworzenie i modyfikacja wtyczek</h3>
<p class="text-body text-gosign-text">
Własne wtyczki dla Twojej logiki biznesowej. Rozszerzanie istniejących wtyczek, dostosowywanie lub zastępowanie ich bezpieczniejszymi rozwiązaniami własnymi. AI przyspiesza tworzenie wtyczek o 70&nbsp;%.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">WooCommerce i e-commerce</h3>
<p class="text-body text-gosign-text">
Sklepy online z WooCommerce: katalogi produktów, integracja płatności, logistyka wysyłki, systemy kuponów. Dla sklepów do ok. 50 000 produktów - odpowiednia platforma.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Utrzymanie i bezpieczeństwo WordPress</h3>
<p class="text-body text-gosign-text">
Aktualizacje, kopie zapasowe, monitoring bezpieczeństwa, optymalizacja wydajności. Proaktywne utrzymanie zamiast reaktywnej naprawy. Gosign monitoruje ponad 800 rozszerzeń i zna luki bezpieczeństwa, zanim zostaną wykorzystane.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6 md:col-span-2">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Migracja WordPress</h3>
<p class="text-body text-gosign-text">
Migracja z TYPO3, Joomla, Drupal lub Webflow na WordPress. Przenoszenie treści, mapowanie przekierowań SEO, nowy projekt graficzny. Migracja treści wspomagana AI oszczędza tygodnie.
</p>
</div>
</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Porozmawiaj o projekcie WordPress - 30&nbsp;minut, bezpłatnie.</h3>
<p class="text-body text-gosign-text mb-6">Przeanalizujemy Twój projekt, oszacujemy nakład pracy i harmonogram, bez zobowiązań.</p>
<a
href="/pl/kontakt/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Umów spotkanie
</a>
<p class="text-small text-gosign-text-light mt-4">25 lat doświadczenia · 800+ rozszerzeń · rozwój wspomagany AI</p>
</div>
</section>

<!-- KI Table -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Tworzenie WordPress wspomagane AI: 70&nbsp;% szybciej</h2>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Zadanie</th>
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Klasycznie</th>
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Z AI</th>
<th class="py-3 text-small font-bold text-gosign-dark">Oszczędność</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Własny motyw (10 szablonów)</td>
<td class="py-3 pr-4 text-body text-gosign-text">3-4 tygodnie</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">1-1,5 tygodnia</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">65&nbsp;%</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Własna wtyczka</td>
<td class="py-3 pr-4 text-body text-gosign-text">2-3 tygodnie</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">4-6 dni</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">70&nbsp;%</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Konfiguracja sklepu WooCommerce</td>
<td class="py-3 pr-4 text-body text-gosign-text">2-3 tygodnie</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">5-7 dni</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">65&nbsp;%</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Migracja treści (500 stron)</td>
<td class="py-3 pr-4 text-body text-gosign-text">2 tygodnie</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">3 dni</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">80&nbsp;%</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Audyt bezpieczeństwa</td>
<td class="py-3 pr-4 text-body text-gosign-text">3 dni</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">1 dzień</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">70&nbsp;%</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Comparison Table -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">WordPress vs. TYPO3 vs. Headless: uczciwe doradztwo</h2>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse bg-white rounded-card">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Kryterium</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">WordPress</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">TYPO3</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Headless (Astro, Next.js)</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Fokus na treść</td>
<td class="py-3 px-4 text-body text-gosign-text">Idealny</td>
<td class="py-3 px-4 text-body text-gosign-text">Dobry</td>
<td class="py-3 px-4 text-body text-gosign-text">Bardziej złożony</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Uprawnienia Enterprise</td>
<td class="py-3 px-4 text-body text-gosign-text">Ograniczone</td>
<td class="py-3 px-4 text-body text-gosign-text">Granularne</td>
<td class="py-3 px-4 text-body text-gosign-text">Własne</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">E-commerce</td>
<td class="py-3 px-4 text-body text-gosign-text">WooCommerce</td>
<td class="py-3 px-4 text-body text-gosign-text">aimeos</td>
<td class="py-3 px-4 text-body text-gosign-text">Shopify API</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Wydajność</td>
<td class="py-3 px-4 text-body text-gosign-text">Zależna od wtyczek</td>
<td class="py-3 px-4 text-body text-gosign-text">Wymaga cache</td>
<td class="py-3 px-4 text-body text-gosign-accent-text font-semibold">Statyczne = szybkie</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Przyjazność dla redaktorów</td>
<td class="py-3 px-4 text-body text-gosign-text">Doskonała</td>
<td class="py-3 px-4 text-body text-gosign-text">Dobra</td>
<td class="py-3 px-4 text-body text-gosign-text">Ograniczona</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Rekomendacja Gosign</td>
<td class="py-3 px-4 text-body text-gosign-accent-text font-semibold">Strony treściowe, blogi, MŚP</td>
<td class="py-3 px-4 text-body text-gosign-accent-text font-semibold">Enterprise, uczelnie</td>
<td class="py-3 px-4 text-body text-gosign-accent-text font-semibold">Krytyczna wydajność</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
Gosign to hamburska agencja cyfrowa z 25-letnim doświadczeniem w tworzeniu stron, TYPO3 i integracji AI.
Obsługujemy europejskie i polskie przedsiębiorstwa z naszej siedziby w Hamburgu.
Przeanalizowaliśmy ponad 800 rozszerzeń TYPO3 i dzięki wsparciu AI realizujemy projekty
do 70&nbsp;% szybciej niż tradycyjnymi metodami.
</p>
<p class="text-small text-gosign-text-light mt-2">Stan na: luty 2026</p>
</div>
</section>

<!-- Powiązane tematy -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Powiązane tematy</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/pl/agencja-cyfrowa-hamburg/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Tworzenie stron</p>
<p class="text-body font-semibold text-gosign-dark">Agencja cyfrowa Hamburg</p>
</a>
<a href="/pl/strona-zhakowana-10-przyczyn/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Bezpieczeństwo</p>
<p class="text-body font-semibold text-gosign-dark">Strona zhakowana - 10 przyczyn</p>
</a>
<a href="/pl/bezpieczenstwo-stron-standardy/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Bezpieczeństwo</p>
<p class="text-body font-semibold text-gosign-dark">Bezpieczeństwo stron - standardy NIS2</p>
</a>
</div>
</div>
</section>

--- Bezpieczeństwo stron - standardy NIS2 ---
> Czy Twoja strona spełnia standardy bezpieczeństwa? Audyt dla firm. Wykrywanie luk, spełnianie wymagań NIS2 i NASK.

<!-- Jakie są wymagania? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Jakie standardy bezpieczeństwa obowiązują strony internetowe?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Dyrektywa NIS2 (obowiązująca w całej UE, włącznie z Polską) zobowiązuje operatorów infrastruktury krytycznej do stosowania odpowiednich środków bezpieczeństwa IT. Ale także firmy spoza tego zakresu powinny stosować się do standardów NASK (Naukowa i Akademicka Sieć Komputerowa) i Krajowego Systemu Cyberbezpieczeństwa (KSC). NIS2 rozszerza obowiązki na wiele branż. Gosign sprawdza Twoją stronę pod kątem luk bezpieczeństwa zgodnie z tymi standardami.
</p>
</div>
</section>

<!-- Tabela audytu -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Co Gosign sprawdza podczas audytu bezpieczeństwa strony</h2>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse bg-white rounded-card">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Obszar</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Co jest sprawdzane</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Znaczenie</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Konfiguracja HTTPS/TLS</td>
<td class="py-3 px-4 text-body text-gosign-text">Certyfikat, wersja protokołu, zestawy szyfrów</td>
<td class="py-3 px-4 text-body text-gosign-text">Ochrona podstawowa</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Content Security Policy</td>
<td class="py-3 px-4 text-body text-gosign-text">Nagłówek CSP, ochrona przed XSS</td>
<td class="py-3 px-4 text-body text-gosign-text">Ochrona podstawowa</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Nagłówki serwera</td>
<td class="py-3 px-4 text-body text-gosign-text">X-Frame-Options, HSTS, Referrer-Policy</td>
<td class="py-3 px-4 text-body text-gosign-text">Ochrona podstawowa</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Wersja CMS i rozszerzenia</td>
<td class="py-3 px-4 text-body text-gosign-text">Znane luki, oprogramowanie EOL</td>
<td class="py-3 px-4 text-body text-gosign-text">Standard NIS2</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Konfiguracja ciasteczek</td>
<td class="py-3 px-4 text-body text-gosign-text">Flaga Secure, HttpOnly, SameSite</td>
<td class="py-3 px-4 text-body text-gosign-text">RODO + NIS2</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Uwierzytelnianie</td>
<td class="py-3 px-4 text-body text-gosign-text">Ochrona logowania, zapobieganie brute-force, 2FA</td>
<td class="py-3 px-4 text-body text-gosign-text">Standard NIS2</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Kopie zapasowe</td>
<td class="py-3 px-4 text-body text-gosign-text">Strategia kopii zapasowych, testy przywracania</td>
<td class="py-3 px-4 text-body text-gosign-text">Standard NIS2</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Usługi -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">Usługi</h2>
<div class="grid md:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Jednorazowy audyt bezpieczeństwa</h3>
<p class="text-body text-gosign-text">
Automatyczne + ręczne sprawdzenie. Raport z rekomendacjami, priorytetyzowany według ryzyka. Wspomagane AI: wyniki w godzinach, nie tygodniach.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Ciągły monitoring</h3>
<p class="text-body text-gosign-text">
Stały nadzór nad CMS, rozszerzeniami i konfiguracją serwera. Natychmiastowe powiadomienie o nowych lukach.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Hardening i wdrożenie</h3>
<p class="text-body text-gosign-text">
Gosign wdraża zalecane środki: nagłówki CSP, konfiguracja TLS, konfiguracja WAF, hardening CMS.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Dokumentacja do audytów</h3>
<p class="text-body text-gosign-text">
Dokumentacja środków bezpieczeństwa strony zgodna ze standardami NIS2. Dla audytów wewnętrznych i zewnętrznych.
</p>
</div>
</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Sprawdź bezpieczeństwo strony - 30&nbsp;minut, bezpłatnie.</h3>
<p class="text-body text-gosign-text mb-6">Przeanalizujemy Twoją stronę pod kątem luk bezpieczeństwa zgodnie z NIS2, bez zobowiązań.</p>
<a
href="/pl/kontakt/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Zamów audyt bezpieczeństwa
</a>
<p class="text-small text-gosign-text-light mt-4">25 lat doświadczenia · 800+ rozszerzeń · rozwój wspomagany AI</p>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
Gosign to hamburska agencja cyfrowa z 25-letnim doświadczeniem w tworzeniu stron, TYPO3 i integracji AI.
Obsługujemy europejskie i polskie przedsiębiorstwa z naszej siedziby w Hamburgu.
Przeanalizowaliśmy ponad 800 rozszerzeń TYPO3 i dzięki wsparciu AI realizujemy projekty
do 70&nbsp;% szybciej niż tradycyjnymi metodami.
</p>
<p class="text-small text-gosign-text-light mt-2">Stan na: luty 2026</p>
</div>
</section>

<!-- Powiązane tematy -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Powiązane tematy</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/pl/strona-zhakowana-10-przyczyn/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Bezpieczeństwo</p>
<p class="text-body font-semibold text-gosign-dark">Strona zhakowana - 10 przyczyn</p>
</a>
<a href="/pl/typo3-monitor-bezpieczenstwa/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Monitoring</p>
<p class="text-body font-semibold text-gosign-dark">Monitor bezpieczeństwa TYPO3</p>
</a>
<a href="/pl/typo3-extensions/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">CMS</p>
<p class="text-body font-semibold text-gosign-dark">TYPO3 Extensions</p>
</a>
</div>
</div>
</section>

--- Decision Layer - Identyfikowalne decyzje AI dla HR i Finance ---
> Decision Layer czyni każdą decyzję AI audytowalną, gotową na radę zakładową i identyfikowalną. Dla HR, Finance i procesów opartych na dokumentach.

<!-- Dlaczego projekty AI zawodzą -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Dlaczego projekty AI w HR zawodzą</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Procesy HR opierają się na wiedzy pojedynczych pracowników. Kto wie, jaka regulacja urlopu specjalnego obowiązuje w danej lokalizacji? Kto pamięta różnicę między porozumieniem zakładowym z 2019 a zaktualizowaną wersją z 2024? Kto sprawdza, czy zwolnienie lekarskie zostało prawidłowo zweryfikowane względem układu zbiorowego?
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Ta wiedza tkwi w głowach ludzi, w wątkach e-mailowych, w folderach, których nikt nie może znaleźć. Gdy ktoś odchodzi z zespołu, wiedza odchodzi z nim.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
AI może pomóc - ale tylko wtedy, gdy jasne jest, jakie reguły obowiązują. I kto ostatecznie ponosi odpowiedzialność.
</p>
</div>
</section>

<!-- Definicja: Co to jest Decision Layer? -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Czym jest Decision Layer?</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Decision Layer rozkłada każdy proces biznesowy na pojedyncze kroki decyzyjne i definiuje z góry dla każdego z nich: Czy decyduje człowiek, zestaw reguł, czy AI samodzielnie?
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Tam, gdzie w grę wchodzi swoboda oceny, ryzyko dyskryminacji lub prawa do konsultacji pracowniczej (Rada Zakładowa), architektura wymusza weryfikację przez człowieka. Tam, gdzie decyzja jest deterministyczna - warunki układu zbiorowego pracy, kontrola terminów, logika księgowa - agent stosuje zestaw reguł konsekwentnie. A tam, gdzie agent jest wystarczająco pewny i ma odpowiednie uprawnienia: decyduje samodzielnie. Interpretuje dokumenty, klasyfikuje sytuacje, ocenia kontekst i rozpoznaje wzorce. To nie jest if-then-else - to zdolność oceny w ramach zdefiniowanych ram. Confidence Routing steruje: wysoka pewność i niskie ryzyko oznacza decyzję autonomiczną, niska pewność lub wysokie ryzyko oznacza eskalację do człowieka. Ten mechanizm odróżnia Decision Layer od RPA.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Każda decyzja jest dokumentowana - kto zdecydował co, kiedy, na jakiej podstawie, z jakim wynikiem. Możliwe do audytu przez biegłego rewidenta, Radę Zakładową i audyt wewnętrzny. Ta dokumentacja to <strong class="text-gosign-dark">akt decyzyjny</strong>: na każdą mikrodecyzję jeden niezmienny dowód z inputem, regułą merytoryczną wraz z wersją, pewnością, wersją modelu, wynikiem i ścieżką podważenia - artefakt, dzięki któremu na żądanie wyjaśnienia pojedynczej decyzji wg art. 86 EU AI Act da się odpowiedzieć.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Decision Layer nie jest AI Agent - to warstwa governance powyżej. Uzupełnia istniejące systemy jak SAP SuccessFactors, Workday czy inne systemy ERP i kontroluje, co AI Agent może robić z tymi systemami.
</p>
<p class="text-body text-gosign-text-light mt-4">
Jak Decision Layer rozwiązuje problem Shadow AI i technicznie wymusza porozumienia zakładowe, opisuje
<a href="/pl/magazyn/decision-layer-shadow-ai/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Artykuł 6 Blueprint 2026</a>.
</p>

<!-- Tabela porównawcza -->
<div class="mt-8 overflow-x-auto">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-dark/20">
<th class="py-3 pr-4 text-body font-bold text-gosign-dark"></th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Bez Decision Layer</th>
<th class="py-3 pl-4 text-body font-bold text-gosign-accent-text">Z Decision Layer</th>
</tr>
</thead>
<tbody class="text-body-lg text-gosign-text-light">
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Kto decyduje?</td>
<td class="py-3 px-4">Niejasne - agent dostarcza wynik</td>
<td class="py-3 pl-4">Dla każdego kroku zdefiniowane: człowiek, zestaw reguł lub AI</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Porozumienia zakładowe</td>
<td class="py-3 px-4">Przestrzegane ręcznie - lub zapomniane</td>
<td class="py-3 pl-4">Zapisane jako stałe reguły, technicznie wymuszone</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Identyfikowalność</td>
<td class="py-3 px-4">Wynik widoczny, ścieżka decyzyjna nie</td>
<td class="py-3 pl-4">Kompletna dokumentacja na decyzję</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Audytor</td>
<td class="py-3 px-4">Musi ręcznie sprawdzić każdy przypadek</td>
<td class="py-3 pl-4">Bezpośredni dostęp do dokumentacji decyzji</td>
</tr>
<tr>
<td class="py-3 pr-4 font-semibold text-gosign-dark">Rada pracowników</td>
<td class="py-3 px-4">Negatywna opinia - brak przejrzystości</td>
<td class="py-3 pl-4">Pozytywna opinia - każda decyzja identyfikowalna</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Przykład: Zwolnienie lekarskie -->
<section id="przyklad" class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-2">Jak działa Decision Layer w praktyce?</h2>
<p class="text-body-lg text-gosign-text-light mb-8">
Przykład zwolnienia lekarskiego: 6 kroków, jasna odpowiedzialność na każdym kroku. Decision Layer definiuje dla każdego: zestaw reguł, człowiek lub automatycznie.
</p>
<img
src="/images/diagrams/decision-layer-krankmeldung-pl.svg"
alt="Przykład procesu: przetwarzanie zwolnienia lekarskiego z Decision Layer w 6 krokach. Kroki 1-2 automatyczne (odczyt dokumentu, załadowanie danych pracownika), kroki 3-4 oparte na regułach (weryfikacja względem układu zbiorowego, obliczenie kontynuacji wynagrodzenia), krok 5 decyzja ludzka (długotrwała choroba powyżej 6 tygodni), krok 6 automatyczne księgowanie SAP."
class="w-full"
loading="lazy"
width="1200"
height="600"
/>
</div>
</section>

<!-- Rada zakładowa -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Dlaczego projekty AI zawodzą na etapie konsultacji z radą pracowników?</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Częsty powód, dla którego projekty AI zawodzą w przedsiębiorstwach: konsultacja z radą pracowników kończy się negatywną opinią. Nie dlatego, że rada jest przeciwna technologii - ale dlatego, że brakuje jej przejrzystości. Decision Layer rozwiązuje to:
</p>
<div class="mt-8 space-y-4">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent/10 rounded-full flex items-center justify-center text-gosign-accent font-bold text-small before:content-['✓']" aria-hidden="true"></span>
<p class="text-body-lg text-gosign-text-light">Każde porozumienie zakładowe jest zapisane jako stała reguła. Agent nie może go obejść.</p>
</div>
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent/10 rounded-full flex items-center justify-center text-gosign-accent font-bold text-small before:content-['✓']" aria-hidden="true"></span>
<p class="text-body-lg text-gosign-text-light">Przy decyzjach dotyczących pracowników zawsze decyduje człowiek. Technicznie wymuszone, nie tylko uzgodnione.</p>
</div>
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent/10 rounded-full flex items-center justify-center text-gosign-accent font-bold text-small before:content-['✓']" aria-hidden="true"></span>
<p class="text-body-lg text-gosign-text-light">Każda decyzja AI jest udokumentowana: co zostało sprawdzone, jaka reguła, jaki wynik.</p>
</div>
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent/10 rounded-full flex items-center justify-center text-gosign-accent font-bold text-small before:content-['✓']" aria-hidden="true"></span>
<p class="text-body-lg text-gosign-text-light">Rada zakładowa może w każdej chwili prześledzić, jak dana decyzja została podjęta.</p>
</div>
</div>
<p class="text-body-lg text-gosign-text-light mt-6">
<strong class="text-gosign-dark">Różnica:</strong> Inni obiecują przejrzystość. Decision Layer wymusza ją technicznie.
</p>
<p class="mt-4">
<a href="/pl/governance/co-determination/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Współdecydowanie i agenci AI →</a>
</p>
</div>
</section>

<!-- Gotowość audytowa -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Jak decyzja AI staje się gotowa na audyt?</h2>
<p class="text-body-lg text-gosign-accent-text font-semibold mt-4">Twój audytor widzi dokładnie, co się wydarzyło.</p>
<ul class="mt-6 space-y-3">
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-6 h-6 bg-gosign-accent/10 rounded-full flex items-center justify-center text-gosign-accent font-bold text-xs mt-0.5 before:content-['✓']" aria-hidden="true"></span>
<span class="text-body-lg text-gosign-text-light">Jaki dokument został przetworzony - i kiedy?</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-6 h-6 bg-gosign-accent/10 rounded-full flex items-center justify-center text-gosign-accent font-bold text-xs mt-0.5 before:content-['✓']" aria-hidden="true"></span>
<span class="text-body-lg text-gosign-text-light">Jaka reguła została zastosowana - i w jakiej wersji?</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-6 h-6 bg-gosign-accent/10 rounded-full flex items-center justify-center text-gosign-accent font-bold text-xs mt-0.5 before:content-['✓']" aria-hidden="true"></span>
<span class="text-body-lg text-gosign-text-light">Jak pewny był agent w swojej ocenie?</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-6 h-6 bg-gosign-accent/10 rounded-full flex items-center justify-center text-gosign-accent font-bold text-xs mt-0.5 before:content-['✓']" aria-hidden="true"></span>
<span class="text-body-lg text-gosign-text-light">Czy człowiek zweryfikował - a jeśli tak, kto?</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-6 h-6 bg-gosign-accent/10 rounded-full flex items-center justify-center text-gosign-accent font-bold text-xs mt-0.5 before:content-['✓']" aria-hidden="true"></span>
<span class="text-body-lg text-gosign-text-light">Jaki był wynik i kiedy został zaksięgowany?</span>
</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-6">Każda z tych odpowiedzi zapisana jest w akcie decyzyjnym - tak on wygląda:</p>
<div class="not-prose mt-4 bg-surface-raised border border-base rounded-soft overflow-hidden shadow-sm">
  <div class="px-5 py-3 border-b border-base bg-surface-dim">
    <div class="flex items-center gap-3">
      <div class="flex gap-1.5" aria-hidden="true">
        <span class="w-2.5 h-2.5 rounded-full bg-[#FF5F56]"></span>
        <span class="w-2.5 h-2.5 rounded-full bg-[#FFBD2E]"></span>
        <span class="w-2.5 h-2.5 rounded-full bg-[#27C93F]"></span>
      </div>
      <span class="font-code text-xs text-muted">decision-record / zwolnienie-lekarskie / 2026-05-14 / EMP_0x52a8</span>
    </div>
  </div>
  <ol class="divide-y divide-base">
    <li class="p-5">
      <div class="flex items-start gap-4">
        <div class="flex-shrink-0 w-9 h-9 rounded-full flex items-center justify-center font-code text-xs font-bold border" style="background: rgba(3,105,161,0.08); border-color: rgba(3,105,161,0.3); color: #0369A1;">02</div>
        <div class="flex-1 min-w-0">
          <div class="flex flex-wrap items-center gap-2 mb-1.5">
            <span class="text-body font-semibold text-primary">Wyliczenie wynagrodzenia chorobowego wg art. 92 KP</span>
            <span class="inline-flex px-2 py-0.5 text-xs font-bold uppercase tracking-wider rounded text-white" style="background: #0369A1;">Reguła</span>
          </div>
          <p class="text-small text-primary font-medium mb-2">80% podstawy od 14.05.2026</p>
          <div class="font-code text-xs text-muted"><span>rule:</span> <span class="text-primary">art. 92 KP &#183; v2026-01</span></div>
        </div>
      </div>
    </li>
    <li class="p-5">
      <div class="flex items-start gap-4">
        <div class="flex-shrink-0 w-9 h-9 rounded-full flex items-center justify-center font-code text-xs font-bold border" style="background: rgba(109,78,216,0.08); border-color: rgba(109,78,216,0.3); color: #6D4ED8;">09</div>
        <div class="flex-1 min-w-0">
          <div class="flex flex-wrap items-center gap-2 mb-1.5">
            <span class="text-body font-semibold text-primary">Oznaczenie wzorca absencji</span>
            <span class="inline-flex items-center gap-1 px-2 py-0.5 text-xs font-bold uppercase tracking-wider rounded text-white" style="background: #6D4ED8;">AI <span class="font-mono opacity-90">91%</span></span>
          </div>
          <p class="text-small text-primary font-medium mb-2">Sygnał dla HR: trzecia krótka absencja w ciągu sześciu miesięcy</p>
          <div class="font-code text-xs text-muted"><span>model-reason:</span> <span class="text-primary">dopasowanie wzorca &#183; wskaźnik, nie decyzja kadrowa</span></div>
          <div class="mt-3"><span class="inline-flex items-center px-3 py-1.5 text-xs font-semibold rounded border-2" style="border-color: #6D4ED8; color: #6D4ED8; background: rgba(109,78,216,0.08);">formalnie podważalna &#183; art. 14 EU AI Act</span></div>
        </div>
      </div>
    </li>
  </ol>
</div>
<p class="text-body text-gosign-text-light mt-4">Dwie z 13 mikrodecyzji jednej sprawy - każda z wersją reguły, pewnością i ścieżką podważenia. <a href="/pl/magazyn/akt-decyzyjny-podwazalne-decyzje-ai/" class="text-gosign-accent-text hover:underline font-semibold">Pełny akt decyzyjny w szczegółach &#8594;</a></p>
</div>
</section>

<!-- Trzy rodzaje decyzji -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-2">Jakie decyzje AI może podejmować samodzielnie?</h2>
<p class="text-body-lg text-gosign-text-light mb-8">
Niektóre decyzje AI Agent może podejmować samodzielnie. Inne wymagają weryfikacji przez człowieka. A przy pytaniach strategicznych agent dostarcza tylko dane. Decision Layer definiuje to - na krok, nie na proces.
</p>
<img
src="/images/diagrams/decision-layer-drei-arten-pl.svg"
alt="Trzy rodzaje decyzji w Decision Layer: Po lewej - człowiek decyduje przy strategii personalnej, przeglądach wyników, polityce wynagrodzeń (około jedna trzecia). W środku - agent pracuje, człowiek weryfikuje przy przetwarzaniu dokumentów, weryfikacji umów, onboardingu (około 40%). Po prawej - agent autonomicznie przy FAQ, standardowych zaświadczeniach, kontroli terminów (około jedna czwarta)."
class="w-full"
loading="lazy"
width="1200"
height="600"
/>
</div>
</section>

<!-- Dla kogo -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Dla kogo jest Decision Layer?</h2>
<div class="mt-8 space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Head of HR / CHRO</p>
<p class="text-body-lg text-gosign-text-light mt-1">Chcesz wdrożyć AI w HR - bez utraty kontroli. Decision Layer zapewnia, że porozumienia zakładowe są przestrzegane, rada zakładowa ma przejrzystość, a każda decyzja jest identyfikowalna.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">CFO / Head of Finance</p>
<p class="text-body-lg text-gosign-text-light mt-1">Każde księgowanie wspierane przez AI jest gotowe na audyt. Twój audytor widzi pełną ścieżkę decyzyjną. Księgowania korygujące są redukowane, ponieważ zestawy reguł są stosowane konsekwentnie.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">Rada zakładowa</p>
<p class="text-body-lg text-gosign-text-light mt-1">Żadna czarna skrzynka. Porozumienia zakładowe są technicznie zapisane i nie mogą być obejściem. Przy decyzjach kadrowych zawsze interweniuje człowiek.</p>
</div>
<div class="border-l-4 border-gosign-dark/20 pl-6">
<p class="text-h3 font-bold text-gosign-text-light">IT / CTO</p>
<p class="text-body-lg text-gosign-text-light mt-1">Agnostyczny wobec modeli, agnostyczny wobec infrastruktury, brak vendor lock-in. <a href="/pl/governance/reference-architecture/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Szczegóły techniczne w Architekturze Referencyjnej →</a></p>
</div>
</div>
</div>
</div>
</section>

<!-- Domeny -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">Decision Layer dla Twoich procesów</h2>
<div class="grid grid-cols-1 md:grid-cols-3 gap-6">
<a href="/pl/hr-ai-agents/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<h3 class="text-h3 font-bold text-gosign-dark">HR & People Operations</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Zwolnienia lekarskie, onboarding, świadectwa pracy, weryfikacja umów, zapytania o polityki. Gotowy na radę zakładową, zgodny z EU AI Act.</p>
<span class="inline-block mt-4 text-gosign-accent-text font-semibold text-body">HR Agent →</span>
</a>
<a href="/pl/finance-ai-agents/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<h3 class="text-h3 font-bold text-gosign-dark">Finance & Payroll</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Przetwarzanie dokumentów, kontowanie, wynagrodzenia, księgowania zamykające. Gotowe na audyt. Integracja SAP i systemów ERP.</p>
<span class="inline-block mt-4 text-gosign-accent-text font-semibold text-body">Finance Agent →</span>
</a>
<a href="/pl/uslugi/ai-agents/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<h3 class="text-h3 font-bold text-gosign-dark">Przetwarzanie dokumentów</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Faktury, umowy, zaświadczenia. Automatyczna klasyfikacja i ekstrakcja danych z walidacją opartą na regułach.</p>
<span class="inline-block mt-4 text-gosign-accent-text font-semibold text-body">Document Agents →</span>
</a>
</div>
</div>
</section>

<!-- EU AI Act -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Czy Decision Layer jest zgodny z EU AI Act?</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
EU AI Act stawia wymagania co do przejrzystości (art. 13), nadzoru ludzkiego (art. 14) i rejestracji (art. 12) - a w art. 86 daje osobom, których decyzja dotyczy, prawo do wyjaśnienia pojedynczej decyzji. Decision Layer adresuje te wymagania jako zasadę architektoniczną - nie jako projekt compliance po fakcie: akt decyzyjny na każdą mikrodecyzję jest odpowiedzią na pytanie o pojedynczy przypadek, na które logi czatu i karty modelu odpowiedzieć nie potrafią.
</p>
<p class="mt-4">
<a href="/pl/governance/eu-ai-act/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">EU AI Act i HR w szczegółach →</a>
<span class="mx-2 text-gosign-text-light">·</span>
<a href="/pl/magazyn/akt-decyzyjny-podwazalne-decyzje-ai/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Akt decyzyjny: dlaczego każda decyzja AI musi być podważalna →</a>
</p>
</div>
</section>

<!-- Informacje o podmiocie -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Kto stoi za Decision Layer?</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Decision Layer jest rozwijany i wdrażany przez <strong class="text-gosign-dark">Gosign GmbH</strong>. Gosign to Enterprise AI Infrastructure & Agent Engineering Company z Hamburga z ponad 20-letnim doświadczeniem w budowaniu złożonych systemów dla przedsiębiorstw takich jak Airbus, Volkswagen, Shell.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
4-6 tygodni do pierwszego produkcyjnego procesu. Pełny dostęp do kodu źródłowego, bez vendor lock-in. Cel: Po 12-18 miesiącach eksploatujesz swoich agentów samodzielnie.
</p>
<p class="mt-4">
<a href="/pl/o-nas/" class="text-gosign-accent-text hover:underline font-semibold">O Gosign →</a>
<span class="mx-2 text-gosign-text-light">·</span>
<a href="/pl/referencje/" class="text-gosign-accent-text hover:underline font-semibold">Referencje →</a>
</p>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">Pogłębienie w Agent Briefing (Magazyn Gosign)</h2>
<div class="grid md:grid-cols-3 gap-6">
<a href="/pl/magazyn/akt-decyzyjny-podwazalne-decyzje-ai/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<h3 class="text-h3 font-bold text-gosign-dark">Akt decyzyjny: podważalne decyzje AI</h3>
</a>
<a href="/pl/magazyn/agent-governance-hr/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR</p>
<h3 class="text-h3 font-bold text-gosign-dark">Agent Governance dla HR</h3>
</a>
<a href="/pl/magazyn/rada-zakladowa-ai-mitbestimmung/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<h3 class="text-h3 font-bold text-gosign-dark">Rada Zakładowa i AI - Współzarządzanie</h3>
</a>
</div>
</div>
</section>

--- Dlaczego Gosign - EU AI Act, Self-Hosting, EU-first ---
> Trzy decyzje architektoniczne: EU AI Act ready, Państwa infrastruktura, EU-first. Bez SaaS, bez ryzyka US-cloud.

<!-- USP 1: EU AI Act ready -->
<section id="eu-ai-act" class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<div class="flex items-center gap-3 mb-6">
<svg class="w-10 h-10 text-gosign-accent-text" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<h2 class="text-h1 font-bold text-gosign-dark">EU AI Act ready</h2>
</div>
<p class="text-body-lg text-gosign-dark font-semibold">Każda decyzja agenta możliwa do prześledzenia. Dla Rady Zakładowej. Dla organu nadzoru. Dla Ciebie.</p>
<p class="text-body text-gosign-text-light mt-4">HR Agents podlegają Artykułowi 6 EU AI Act: kontekst zatrudnienia oznacza klasyfikację wysokiego ryzyka. Kluczowe pytanie to nie czy, ale jak każda decyzja jest dokumentowana - kto zdecydował, dlaczego, z jakim Confidence-Score.</p>
<p class="text-body text-gosign-text-light mt-4">Gosign Agents zapewniają przejrzystość każdej decyzji - architektonicznie, nie retroaktywnie:</p>
<ul class="mt-4 space-y-3">
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text mt-0.5 flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" /></svg>
<span class="text-body text-gosign-text-light"><strong class="text-gosign-dark">Art. 9 Zarządzanie ryzykiem</strong> - Decision Layer definiuje dla każdego kroku procesowego z góry: człowiek, zestaw reguł lub AI. Ocena ryzyka to architektura, nie projekt audytowy.</span>
</li>
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text mt-0.5 flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" /></svg>
<span class="text-body text-gosign-text-light"><strong class="text-gosign-dark">Art. 12 Obowiązek rejestracji</strong> - Każda decyzja agenta jako akt decyzyjny w Audit Trail: input, zastosowana reguła wraz z wersją, Confidence Score, wynik i ścieżka podważenia - dowód na każdą mikrodecyzję.</span>
</li>
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text mt-0.5 flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" /></svg>
<span class="text-body text-gosign-text-light"><strong class="text-gosign-dark">Art. 13 Przejrzystość</strong> - Rada Zakładowa może przez Portal Auditor prześledzić każdą decyzję - bez działu IT, bez dostępu do bazy danych.</span>
</li>
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text mt-0.5 flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" /></svg>
<span class="text-body text-gosign-text-light"><strong class="text-gosign-dark">Art. 14 Nadzór ludzki</strong> - Human-in-the-Loop jako zasada architektoniczna, nie opcjonalna funkcja. Człowiek pozostaje w procesie tam, gdzie Rada Zakładowa, prawo pracy lub ryzyko dyskryminacji tego wymagają.</span>
</li>
</ul>
<p class="text-body text-gosign-text-light mt-6">Przejrzystość decyzji to nie projekt compliance po wdrożeniu. Jest wbudowana w Decision Layer - od pierwszego pilota.</p>
<p class="text-body text-gosign-text-light mt-4">Pogłębienie: <a href="/pl/magazyn/eu-ai-act-obowiazuje-na-calym-swiecie/" class="text-gosign-accent-text hover:underline">EU AI Act obowiązuje na całym świecie - i co to oznacza dla Państwa firmy</a></p>
</div>
</div>
</section>

<!-- USP 2: Państwa infrastruktura -->
<section id="infrastruktura" class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<div class="flex items-center gap-3 mb-6">
<svg class="w-10 h-10 text-gosign-accent-text" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<h2 class="text-h1 font-bold text-gosign-dark">Państwa infrastruktura</h2>
</div>
<p class="text-body-lg text-gosign-dark font-semibold">W Państwa centrum danych. Pod Państwa kontrolą.</p>
<p class="text-body text-gosign-text-light mt-4">Gosign AI Agents to nie produkt SaaS. Działają w Państwa infrastrukturze - on-premises, private cloud lub hybrid. Dane nie opuszczają Państwa systemów.</p>
<p class="text-body text-gosign-text-light mt-4">To nie kwestia filozofii. To kwestia RODO i Rady Zakładowej: Rada Zakładowa ma prawo do informacji o przetwarzaniu danych pracowników zgodnie z Ustawą o radach pracowników. Self-hosting oznacza, że dane pozostają w Państwa infrastrukturze - bez zależności od chmur US, bez ryzyka transferu danych do państw trzecich.</p>
<div class="grid grid-cols-1 md:grid-cols-3 gap-6 mt-8">
<div class="border border-gosign-border rounded-card p-6 bg-gosign-white">
<p class="text-sm font-bold text-gosign-accent-text uppercase tracking-wider">Kod źródłowy</p>
<p class="text-body text-gosign-text-light mt-2">Pełny dostęp. Możesz prowadzić agenta bez Gosign w dowolnym momencie. Brak vendor-lock-in.</p>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-gosign-white">
<p class="text-sm font-bold text-gosign-accent-text uppercase tracking-wider">Model-agnostyczny</p>
<p class="text-body text-gosign-text-light mt-2">Ty wybierasz LLM - nie my. OpenAI, Anthropic, modele lokalne. Brak uzależnienia od jednego dostawcy.</p>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-gosign-white">
<p class="text-sm font-bold text-gosign-accent-text uppercase tracking-wider">RODO natywnie</p>
<p class="text-body text-gosign-text-light mt-2">Rezydencja danych jako decyzja architektoniczna. Nie jako dodatkowa funkcja. Żadne dane nie opuszczają Państwa infrastruktury.</p>
</div>
</div>
</div>
</div>
</section>

<!-- USP 3: EU-first -->
<section id="eu-first" class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<div class="flex items-center gap-3 mb-6">
<svg class="w-10 h-10 text-gosign-accent-text" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<h2 class="text-h1 font-bold text-gosign-dark">EU-first</h2>
</div>
<p class="text-body-lg text-gosign-dark font-semibold">Żaden produkt US z europejską łatką. Regulacja UE jest baseline.</p>
<p class="text-body text-gosign-text-light mt-4">Większość produktów AI jest budowana dla rynku US i następnie dostosowywana do regulacji UE. RODO jako checkbox, prawo do konsultacji jako kulturowa ciekawostka, rezydencja danych jako opcjonalna funkcja.</p>
<p class="text-body text-gosign-text-light mt-4">Gosign Agents są zbudowane odwrotnie: dane pozostają w Państwa infrastrukturze - żadnej zależności od chmury US. RODO jest zasadą architektoniczną, nie checkboxem. Kto spełnia najtrudniejsze środowisko regulacyjne, spełnia każde inne - również polskie wymogi Kodeksu Pracy.</p>
<p class="text-body text-gosign-text-light mt-4">Co to oznacza konkretnie:</p>
<ul class="mt-4 space-y-3">
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text mt-0.5 flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" /></svg>
<span class="text-body text-gosign-text-light"><strong class="text-gosign-dark">Żadnej zależności od chmury US</strong>. Dane pozostają w Państwa infrastrukturze - bez ryzyka CLOUD Act, bez problemów z transferem transgranicznym.</span>
</li>
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text mt-0.5 flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" /></svg>
<span class="text-body text-gosign-text-light"><strong class="text-gosign-dark">RODO jako zasada architektoniczna</strong>, nie jako retroaktywna adaptacja. Rezydencja danych, koncepcje usuwania i kontrola dostępu są zakotwiczone w architekturze.</span>
</li>
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text mt-0.5 flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" /></svg>
<span class="text-body text-gosign-text-light"><strong class="text-gosign-dark">Układy zbiorowe pracy jako reguły deterministyczne</strong> w Decision Layer. Każdy układ zbiorowy jest implementowany jako silnik reguł, nie jako pole tekstowe.</span>
</li>
</ul>
<p class="text-body text-gosign-text-light mt-6">Pogłębienie: <a href="/pl/magazyn/shadow-ai-governance/" class="text-gosign-accent-text hover:underline">Shadow AI w przedsiębiorstwie - governance zamiast zakazu</a></p>
</div>
</div>
</section>

<!-- Pogłębienie w Agent Briefing -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">Pogłębienie w Agent Briefing (Magazyn Gosign)</h2>
<div class="grid grid-cols-1 md:grid-cols-3 gap-6">
<a href="/pl/magazyn/eu-ai-act-obowiazuje-na-calym-swiecie/" class="block border border-gosign-border rounded-card p-6 bg-gosign-white hover:border-gosign-accent transition-colors">
<p class="text-xs font-bold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<p class="text-h3 font-bold text-gosign-dark">EU AI Act obowiązuje na całym świecie</p>
</a>
<a href="/pl/magazyn/eu-ai-act-hr/" class="block border border-gosign-border rounded-card p-6 bg-gosign-white hover:border-gosign-accent transition-colors">
<p class="text-xs font-bold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<p class="text-h3 font-bold text-gosign-dark">EU AI Act i HR</p>
</a>
<a href="/pl/magazyn/agent-governance-hr/" class="block border border-gosign-border rounded-card p-6 bg-gosign-white hover:border-gosign-accent transition-colors">
<p class="text-xs font-bold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<p class="text-h3 font-bold text-gosign-dark">Agent Governance w HR</p>
</a>
</div>
</div>
</section>

--- eBook: AI w finansach - Poradnik Governance dla CFO ---
> Bezpłatny eBook: EU AI Act, biegli rewidenci i Decision Layer - poradnik governance dla liderów finansów przed sierpniem 2026.

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">

<div class="grid md:grid-cols-5 gap-12 items-start">

<div class="md:col-span-3">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Co znajdziesz w tym poradniku</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
EU AI Act klasyfikuje decyzje kredytowe wspierane przez AI jako wysokie ryzyko (Załącznik III Nr 5b). 73% organizacji nie posiada jeszcze ram governance (ISACA 2024). Ten poradnik wypełnia tę lukę - zawiera ramowe modele specyficzne dla finansów, checklisty i Readiness Assessment.
</p>

<div class="space-y-4 mb-8">
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">1</span>
<div>
<p class="font-semibold text-gosign-dark">Dlaczego CFO musi przewodzić AI governance w Finance - nie IT</p>
<p class="text-small text-gosign-text-light">Ownership w zakresie governance, model ról i checklista CFO.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">2</span>
<div>
<p class="font-semibold text-gosign-dark">Trzy rodzaje decyzji finansowych: Człowiek, Reguły, AI</p>
<p class="text-small text-gosign-text-light">Framework H/R/A ze wskaźnikiem Agent Readiness Score dla każdego procesu finansowego.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">3</span>
<div>
<p class="font-semibold text-gosign-dark">EU AI Act: Wymagania dla sektora finansowego</p>
<p class="text-small text-gosign-text-light">Klasyfikacja wysokiego ryzyka (Załącznik III Nr 5b) z checklistą zgodności.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">4</span>
<div>
<p class="font-semibold text-gosign-dark">Biegły rewident jako partner governance</p>
<p class="text-small text-gosign-text-light">ISA 315, Auditor Portal, obowiązek AI Literacy od lutego 2025.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">5</span>
<div>
<p class="font-semibold text-gosign-dark">4 procesy finansowe w Decision Layer</p>
<p class="text-small text-gosign-text-light">Accounts Payable, koszty podróży, Financial Close, Fraud Detection - ze wskaźnikami Zero-Touch.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">6</span>
<div>
<p class="font-semibold text-gosign-dark">Finance Readiness Assessment (10 pytań)</p>
<p class="text-small text-gosign-text-light">Na jakim etapie jest Twoja organizacja? Samoocena z wynikiem i rekomendacjami działań.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">7</span>
<div>
<p class="font-semibold text-gosign-dark">Plan na 90 dni</p>
<p class="text-small text-gosign-text-light">Inwentaryzacja, projektowanie, pilotaż - ustrukturyzowana ścieżka do Decision Layer w trzy miesiące.</p>
</div>
</div>
</div>
</div>

<div class="md:col-span-2">
<div class="bg-gosign-light border border-gosign-border rounded-card p-6 sticky top-8">
<p class="text-h3 font-bold text-gosign-dark mb-2">Pobierz bezpłatnie</p>
<p class="text-small text-gosign-text-light mb-4">PDF, 28 stron. Natychmiast na e-mail.</p>

<div class="space-y-3 mb-6">
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>Checklista zgodności z EU AI Act (Finance)</span>
</div>
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>Decision Framework H/R/A</span>
</div>
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>Finance Readiness Assessment do wypełnienia</span>
</div>
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>90-dniowy plan wdrożenia</span>
</div>
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>Checklista biegłego rewidenta (ISA 315)</span>
</div>
</div>

<button data-ebook-download class="w-full px-6 py-3 bg-gosign-accent-btn text-white font-semibold rounded-md hover:bg-gosign-accent-btn-hover transition-colors text-sm flex items-center justify-center gap-2 cursor-pointer">
<svg class="w-5 h-5" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M4 16v1a3 3 0 003 3h10a3 3 0 003-3v-1m-4-4l-4 4m0 0l-4-4m4 4V4"/></svg>
Pobierz PDF
</button>
</div>
</div>

</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">5 kluczowych liczb z poradnika</h2>

<div class="grid sm:grid-cols-2 lg:grid-cols-3 gap-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">5%</p>
<p class="text-small text-gosign-text">rocznych przychodów tracą firmy na całym świecie z powodu oszustw</p>
<p class="text-xs text-gosign-text-light mt-1">ACFE 2024</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">42%</p>
<p class="text-small text-gosign-text">wszystkich faktur w księgowości zobowiązań jest wciąż przetwarzanych ręcznie</p>
<p class="text-xs text-gosign-text-light mt-1">Institute of Finance & Management 2024</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">88-95%</p>
<p class="text-small text-gosign-text">wskaźnik Zero-Touch z Decision Layer w procesach finansowych</p>
<p class="text-xs text-gosign-text-light mt-1">Projekty klientów Gosign</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">1:4-5</p>
<p class="text-small text-gosign-text">Stosunek inwestycji: 1 EUR technologia = 4-5 EUR governance</p>
<p class="text-xs text-gosign-text-light mt-1">McKinsey 2024</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">15 mln EUR</p>
<p class="text-small text-gosign-text">Maksymalna kara za naruszenie obowiązków dotyczących wysokiego ryzyka</p>
<p class="text-xs text-gosign-text-light mt-1">EU AI Act, Art. 99</p>
</div>
</div>

</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Dla kogo jest ten poradnik?</h2>

<div class="grid sm:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">CFO / Dyrektor Finansowy</p>
<p class="text-small text-gosign-text-light">Odpowiadasz za strategię AI w obszarze finansów i potrzebujesz ram, które jednocześnie przekonają biegłego rewidenta, dział prawny i zarząd.</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">Główny Księgowy / Kierownik Księgowości</p>
<p class="text-small text-gosign-text-light">Wdrażasz procesy wspierane przez AI i potrzebujesz jasnych reguł decyzyjnych: co automatyzować, czego nie? Jak zachować pewność audytową?</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">Biegły rewident / Audyt wewnętrzny</p>
<p class="text-small text-gosign-text-light">Badasz procesy finansowe wspierane przez AI i potrzebujesz przejrzystości: które księgowania przetwarza agent, a które człowiek? Jak działa audit trail?</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">Finance Compliance / Dział Prawny</p>
<p class="text-small text-gosign-text-light">Musisz wdrożyć wymagania EU AI Act dla procesów finansowych i potrzebujesz checklisty zgodności z konkretnymi działaniami i integracją z systemem kontroli wewnętrznej.</p>
</div>
</div>

</div>
</section>

<section class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-12 border-t border-gosign-border">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Więcej eBooków</h2>
<div class="grid grid-cols-1 md:grid-cols-2 gap-6">

<div class="bg-white border border-gosign-border rounded-card p-5">
<p class="font-semibold text-gosign-dark mb-1">AI w HR - Poradnik Governance</p>
<p class="text-small text-gosign-text-light mb-3">Dla CHRO i liderów HR</p>
<a href="/pl/ebook/ai-hr-poradnik-governance/" class="text-sm text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Pobierz za darmo</a>
</div>

<div class="bg-white border border-gosign-border rounded-card p-5">
<p class="font-semibold text-gosign-dark mb-1">Infrastruktura AI - Poradnik Governance</p>
<p class="text-small text-gosign-text-light mb-3">Dla CTO i liderów IT</p>
<a href="/pl/ebook/ai-infrastructure-poradnik-governance/" class="text-sm text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Pobierz za darmo</a>
</div>

<a href="/pl/ebook/finance-agent-readiness-assessment/" class="block border border-gosign-border rounded-card p-4 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-1">Finance Assessment</p>
<p class="text-body font-semibold text-gosign-dark">Finance Agent Readiness Assessment</p>
<p class="text-small text-gosign-text-light mt-1">15 pytań dla CFO i biegłego rewidenta</p>
</a>

</div>
</section>

--- eBook: AI w HR - Poradnik Governance dla CHRO ---
> Bezpłatny eBook: EU AI Act, rada zakładowa i Decision Layer - poradnik governance dla liderów HR przed sierpniem 2026.

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">

<div class="grid md:grid-cols-5 gap-12 items-start">

<div class="md:col-span-3">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Co znajdziesz w tym poradniku</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
EU AI Act klasyfikuje systemy AI w HR jako wysokiego ryzyka; obowiązujący termin obowiązków to 2 sierpnia 2026 r. (z wstępnie uzgodnionym przesunięciem na grudzień 2027 r. - Digital Omnibus, maj 2026). 73% organizacji wciąż nie posiada ram governance (ISACA 2024). Ten poradnik wypełnia tę lukę - z konkretnymi ramami, checklistami i oceną gotowości.
</p>

<div class="space-y-4 mb-8">
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">1</span>
<div>
<p class="font-semibold text-gosign-dark">Dlaczego CHRO musi przewodzić AI governance w HR - nie IT</p>
<p class="text-small text-gosign-text-light">Własność governance, koncepcja ról i checklista CHRO.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">2</span>
<div>
<p class="font-semibold text-gosign-dark">Trzy rodzaje decyzji: Człowiek, Regułownik, AI</p>
<p class="text-small text-gosign-text-light">Framework decyzyjny z Agent Readiness Score dla każdego procesu HR.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">3</span>
<div>
<p class="font-semibold text-gosign-dark">EU AI Act: 6 obowiązkowych wymagań szczegółowo</p>
<p class="text-small text-gosign-text-light">Art. 9-15 z checklistą zgodności do odhaczenia.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">4</span>
<div>
<p class="font-semibold text-gosign-dark">Rada zakładowa jako partner projektowy</p>
<p class="text-small text-gosign-text-light">Prawa konsultacyjne, porozumienie zakładowe jako ograniczenie techniczne, AI Literacy.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">5</span>
<div>
<p class="font-semibold text-gosign-dark">4 procesy HR w Decision Layer</p>
<p class="text-small text-gosign-text-light">Payroll, koszty podróży, rekrutacja, urlopy i nieobecności - ze wskaźnikami Zero-Touch.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">6</span>
<div>
<p class="font-semibold text-gosign-dark">Ocena gotowości (10 pytań)</p>
<p class="text-small text-gosign-text-light">Gdzie stoi Twoja organizacja? Samoocena z wynikiem i rekomendacjami.</p>
</div>
</div>
</div>
</div>

<div class="md:col-span-2">
<div class="bg-gosign-light border border-gosign-border rounded-card p-6 sticky top-8">
<p class="text-h3 font-bold text-gosign-dark mb-2">Pobierz bezpłatnie</p>
<p class="text-small text-gosign-text-light mb-4">PDF, 25 stron. Natychmiast na e-mail.</p>

<div class="space-y-3 mb-6">
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>Checklista zgodności EU AI Act</span>
</div>
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>Framework decyzyjny (H/R/A)</span>
</div>
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>Ocena gotowości do wypełnienia</span>
</div>
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>90-dniowy plan wdrożenia</span>
</div>
</div>
<button data-ebook-download class="w-full px-6 py-3 bg-gosign-accent-btn text-white font-semibold rounded-md hover:bg-gosign-accent-btn-hover transition-colors text-sm flex items-center justify-center gap-2 cursor-pointer">
<svg class="w-5 h-5" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M4 16v1a3 3 0 003 3h10a3 3 0 003-3v-1m-4-4l-4 4m0 0l-4-4m4 4V4"/></svg>
Pobierz PDF
</button>
</div>
</div>

</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">5 kluczowych liczb z poradnika</h2>

<div class="grid sm:grid-cols-2 lg:grid-cols-3 gap-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">73%</p>
<p class="text-small text-gosign-text">organizacji bez formalnych ram governance AI</p>
<p class="text-xs text-gosign-text-light mt-1">ISACA 2024</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">6</p>
<p class="text-small text-gosign-text">obowiązkowych wymagań dla AI wysokiego ryzyka w HR - termin obowiązujący 2 sierpnia 2026 r. (przesunięcie na grudzień 2027 wstępnie uzgodnione)</p>
<p class="text-xs text-gosign-text-light mt-1">EU AI Act, Art. 9-15</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">85-92%</p>
<p class="text-small text-gosign-text">wskaźnik Zero-Touch z Decision Layer w procesach HR</p>
<p class="text-xs text-gosign-text-light mt-1">Projekty klientów Gosign</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">1:4-5</p>
<p class="text-small text-gosign-text">proporcja inwestycji: 1 EUR technologia = 4-5 EUR governance</p>
<p class="text-xs text-gosign-text-light mt-1">McKinsey 2024</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">60-80%</p>
<p class="text-small text-gosign-text">mniej korekt księgowych dzięki jawnym regułom</p>
<p class="text-xs text-gosign-text-light mt-1">Hackett Group 2024</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">15 mln</p>
<p class="text-small text-gosign-text">EUR maksymalna kara za naruszenie wymagań wysokiego ryzyka</p>
<p class="text-xs text-gosign-text-light mt-1">EU AI Act, Art. 99</p>
</div>
</div>

</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Dla kogo jest ten poradnik?</h2>

<div class="grid sm:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">CHRO / VP HR</p>
<p class="text-small text-gosign-text-light">Odpowiadasz za strategię AI w HR i potrzebujesz ram, które przekonają radę zakładową, dział prawny i zarząd jednocześnie.</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">Dyrektor People Operations</p>
<p class="text-small text-gosign-text-light">Wdrażasz procesy wspierane przez AI i potrzebujesz jasnych reguł decyzyjnych: co automatyzować, a czego nie.</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">Rada Zakładowa</p>
<p class="text-small text-gosign-text-light">Kontrolujesz zastosowanie AI w HR i potrzebujesz przejrzystości: które decyzje podejmuje agent, a które człowiek?</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">HR Compliance / Dział Prawny</p>
<p class="text-small text-gosign-text-light">Musisz wdrożyć wymagania EU AI Act i potrzebujesz checklisty zgodności z konkretnymi działaniami.</p>
</div>
</div>

</div>
</section>

<section class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-12 border-t border-gosign-border">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Więcej eBooków</h2>
<div class="grid grid-cols-1 md:grid-cols-2 gap-6">

<div class="bg-white border border-gosign-border rounded-card p-5">
<p class="font-semibold text-gosign-dark mb-1">AI w Finance - Poradnik Governance</p>
<p class="text-small text-gosign-text-light mb-3">Dla CFO i liderów finansów</p>
<a href="/pl/ebook/ai-finance-poradnik-governance/" class="text-sm text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Pobierz za darmo</a>
</div>

<div class="bg-white border border-gosign-border rounded-card p-5">
<p class="font-semibold text-gosign-dark mb-1">Infrastruktura AI - Poradnik Governance</p>
<p class="text-small text-gosign-text-light mb-3">Dla CTO i liderów IT</p>
<a href="/pl/ebook/ai-infrastructure-poradnik-governance/" class="text-sm text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Pobierz za darmo</a>
</div>

<a href="/pl/ebook/hr-agent-readiness-assessment/" class="block border border-gosign-border rounded-card p-4 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-1">HR Assessment</p>
<p class="text-body font-semibold text-gosign-dark">HR Agent Readiness Assessment</p>
<p class="text-small text-gosign-text-light mt-1">15 pytań dla zespołu kierowniczego</p>
</a>

</div>
</section>

--- eBook: Infrastruktura AI - Poradnik Governance dla CTO ---
> Bezpłatny eBook: Build, Buy, Hybrid - infrastruktura AI zgodna z EU AI Act. Poradnik governance dla CTO i szefów infrastruktury.

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">

<div class="grid md:grid-cols-5 gap-12 items-start">

<div class="md:col-span-3">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Co znajdziesz w tym poradniku</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
Według Gartner (2024) przedsiębiorstwa wydadzą ponad 644 mld USD na infrastrukturę AI do 2027 roku. Jednocześnie marnują 28% wydatków na chmurę (Flexera 2024). Ten poradnik pokazuje, jak budować infrastrukturę AI zgodną z zasadami governance, efektywną kosztowo i przygotowaną na EU AI Act.
</p>

<div class="space-y-4 mb-8">
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">1</span>
<div>
<p class="font-semibold text-gosign-dark">Dlaczego CTO musi prowadzić AI Infrastructure Governance</p>
<p class="text-small text-gosign-text-light">Shadow AI, luka w governance i lista kontrolna CTO na start.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">2</span>
<div>
<p class="font-semibold text-gosign-dark">Build, Buy, Hybrid: framework B/B/H</p>
<p class="text-small text-gosign-text-light">Matryca decyzyjna według typu obciążenia z ukrytymi kosztami i ukrytymi ryzykami.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">3</span>
<div>
<p class="font-semibold text-gosign-dark">EU AI Act: 6 wymagań technicznych (art. 9-15)</p>
<p class="text-small text-gosign-text-light">Obowiązki compliance jako decyzje infrastrukturalne z techniczną listą kontrolną.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">4</span>
<div>
<p class="font-semibold text-gosign-dark">Security & Data Sovereignty</p>
<p class="text-small text-gosign-text-light">Data Residency, szyfrowanie, architektura Zero Trust i zgodność z RODO przy korzystaniu z LLM.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">5</span>
<div>
<p class="font-semibold text-gosign-dark">4 wzorce infrastrukturalne w produkcji</p>
<p class="text-small text-gosign-text-light">Agent Orchestration, Document Intelligence, Model Gateway, Monitoring & Observability.</p>
</div>
</div>
<div class="flex items-start gap-3">
<span class="text-gosign-accent font-bold text-lg mt-0.5">6</span>
<div>
<p class="font-semibold text-gosign-dark">Infrastructure Readiness Assessment (10 pytań)</p>
<p class="text-small text-gosign-text-light">Gdzie stoi Twoja infrastruktura? Samoocena z wynikiem i planem na 90 dni.</p>
</div>
</div>
</div>
</div>

<div class="md:col-span-2">
<div class="bg-gosign-light border border-gosign-border rounded-card p-6 sticky top-8">
<p class="text-h3 font-bold text-gosign-dark mb-2">Pobierz za darmo</p>
<p class="text-small text-gosign-text-light mb-4">PDF, 28 stron. Natychmiastowa wysyłka e-mailem.</p>

<div class="space-y-3 mb-6">
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>Matryca decyzyjna Build/Buy/Hybrid</span>
</div>
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>Lista kontrolna zgodności z EU AI Act (techniczna)</span>
</div>
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>4 wzorce infrastrukturalne gotowe do produkcji</span>
</div>
<div class="flex items-center gap-2 text-small text-gosign-text">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" stroke-width="2" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" d="M4.5 12.75l6 6 9-13.5"/></svg>
<span>Infrastructure Readiness Assessment + plan na 90 dni</span>
</div>
</div>

<button data-ebook-download class="w-full px-6 py-3 bg-gosign-accent-btn text-white font-semibold rounded-md hover:bg-gosign-accent-btn-hover transition-colors text-sm flex items-center justify-center gap-2 cursor-pointer">
<svg class="w-5 h-5" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M4 16v1a3 3 0 003 3h10a3 3 0 003-3v-1m-4-4l-4 4m0 0l-4-4m4 4V4"/></svg>
Pobierz PDF
</button>
</div>
</div>

</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">5 kluczowych liczb z poradnika</h2>

<div class="grid sm:grid-cols-2 lg:grid-cols-3 gap-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">644 mld</p>
<p class="text-small text-gosign-text">USD globalne wydatki na infrastrukturę AI do 2027</p>
<p class="text-xs text-gosign-text-light mt-1">Gartner 2024</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">28%</p>
<p class="text-small text-gosign-text">wydatków na chmurę zmarnowanych z powodu braku governance</p>
<p class="text-xs text-gosign-text-light mt-1">Flexera 2024</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">82%</p>
<p class="text-small text-gosign-text">korzysta z multi-cloud bez centralnego governance AI</p>
<p class="text-xs text-gosign-text-light mt-1">HashiCorp 2024</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">40%</p>
<p class="text-small text-gosign-text">incydentów bezpieczeństwa spowodowanych błędną konfiguracją usług chmurowych</p>
<p class="text-xs text-gosign-text-light mt-1">ENISA 2024</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-3xl font-bold text-gosign-accent mb-2">15 mln</p>
<p class="text-small text-gosign-text">EUR maksymalna kara za naruszenie obowiązków wysokiego ryzyka</p>
<p class="text-xs text-gosign-text-light mt-1">EU AI Act, art. 99</p>
</div>
</div>

</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Dla kogo jest ten poradnik?</h2>

<div class="grid sm:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">CTO / VP Engineering</p>
<p class="text-small text-gosign-text-light">Odpowiadasz za strategię infrastruktury AI i potrzebujesz frameworku łączącego skalowalność, zgodność i zarządzanie kosztami.</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">Szef infrastruktury / platformy</p>
<p class="text-small text-gosign-text-light">Budujesz platformę dla obciążeń AI i potrzebujesz wzorców gotowych do produkcji: Agent Orchestration, Model Gateway, Document Intelligence.</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">Cloud Architect / DevOps Lead</p>
<p class="text-small text-gosign-text-light">Decydujesz o build vs. buy i potrzebujesz matrycy decyzyjnej: które obciążenie hostować samodzielnie, a które uruchomić jako usługę zarządzaną?</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<p class="font-semibold text-gosign-dark mb-2">CISO / Szef bezpieczeństwa</p>
<p class="text-small text-gosign-text-light">Musisz zapewnić suwerenność danych i potrzebujesz stosu bezpieczeństwa: Zero Trust, screening PII, szyfrowanie, bezpieczeństwo łańcucha dostaw.</p>
</div>
</div>

</div>
</section>

<section class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-12 border-t border-gosign-border">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Więcej eBooków</h2>
<div class="grid grid-cols-1 md:grid-cols-2 gap-6">

<div class="bg-white border border-gosign-border rounded-card p-5">
<p class="font-semibold text-gosign-dark mb-1">AI w HR - Poradnik Governance</p>
<p class="text-small text-gosign-text-light mb-3">Dla CHRO i liderów HR</p>
<a href="/pl/ebook/ai-hr-poradnik-governance/" class="text-sm text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Pobierz za darmo</a>
</div>

<div class="bg-white border border-gosign-border rounded-card p-5">
<p class="font-semibold text-gosign-dark mb-1">AI w Finance - Poradnik Governance</p>
<p class="text-small text-gosign-text-light mb-3">Dla CFO i liderów finansów</p>
<a href="/pl/ebook/ai-finance-poradnik-governance/" class="text-sm text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Pobierz za darmo</a>
</div>

<a href="/pl/ebook/hr-agent-readiness-assessment/" class="block border border-gosign-border rounded-card p-4 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-1">HR Assessment</p>
<p class="text-body font-semibold text-gosign-dark">HR Agent Readiness Assessment</p>
<p class="text-small text-gosign-text-light mt-1">15 pytań dla zespołu kierowniczego</p>
</a>

<a href="/pl/ebook/finance-agent-readiness-assessment/" class="block border border-gosign-border rounded-card p-4 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-1">Finance Assessment</p>
<p class="text-body font-semibold text-gosign-dark">Finance Agent Readiness Assessment</p>
<p class="text-small text-gosign-text-light mt-1">15 pytań dla CFO i biegłego rewidenta</p>
</a>

</div>
</section>

--- eBook: Finance Agent Readiness Assessment - 15 pytań dla CFO i biegłych rewidentów ---
> Bezpłatny eBook z oceną gotowości: 15 pytań o Finance Agent Readiness. Kontrola zgodności, ocena gotowości audytowej, ocena zespołowa z analizą rozbieżności.

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">

<div class="grid md:grid-cols-5 gap-12 items-start">

<div class="md:col-span-3">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Co znajdziesz w tym assessmencie</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
42% wszystkich faktur w księgowości zobowiązań jest wciąż przetwarzanych ręcznie (IFM 2024). Przy średnim koszcie EUR 11,50 za fakturę to mierzalny czynnik kosztowy. Ten assessment pokaże, na jakim etapie znajduje się Twoja organizacja finansowa - i które agenty dają największą dźwignię.
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8 mb-3">15 pytań w 5 wymiarach</h3>
<ul class="space-y-2 text-body text-gosign-text">
<li class="flex items-start gap-2"><span class="text-gosign-accent-text font-bold">1.</span> Gotowość audytowa - Jak przygotowane do audytu są Twoje procesy?</li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text font-bold">2.</span> Tajemnica zawodowa - Status zgodności regulacyjnej i separacja danych</li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text font-bold">3.</span> Krajobraz ERP - Jak zintegrowane są Twoje systemy finansowe?</li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text font-bold">4.</span> Szybkość zamknięcia - Jak szybko zamykasz miesiąc?</li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text font-bold">5.</span> Dojrzałość procesów - Jak sformalizowane są Twoje zasady księgowe?</li>
</ul>

<h3 class="text-h3 font-bold text-gosign-dark mt-8 mb-3">Czym eBook różni się od narzędzia online</h3>
<div class="overflow-x-auto">
<table class="w-full text-body text-gosign-text border-collapse mt-4">
<thead><tr class="border-b-2 border-gosign-border"><th class="text-left py-2 pr-4 font-bold text-gosign-dark">Cecha</th><th class="text-left py-2 pr-4 font-bold text-gosign-dark">Online (3 min.)</th><th class="text-left py-2 font-bold text-gosign-dark">eBook (PDF)</th></tr></thead>
<tbody>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Pytania</td><td class="py-2 pr-4">7</td><td class="py-2">15</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Kontrola zgodności</td><td class="py-2 pr-4">Podstawowa</td><td class="py-2">Pogłębiona (6 pytań)</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Ocena zespołowa</td><td class="py-2 pr-4">Nie</td><td class="py-2">Tak (CFO + biegły rewident + IT)</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Analiza rozbieżności</td><td class="py-2 pr-4">Nie</td><td class="py-2">Tak</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Do druku</td><td class="py-2 pr-4">Nie</td><td class="py-2">Tak (zoptymalizowany A4)</td></tr>
</tbody>
</table>
</div>
</div>

<div class="md:col-span-2">
<div class="sticky top-24 bg-gosign-light border border-gosign-border rounded-card p-6">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-3">Bezpłatny PDF</p>
<p class="text-h3 font-bold text-gosign-dark mb-2">Pobierz assessment</p>
<p class="text-small text-gosign-text-light mb-4">14 stron, kontrola zgodności, ocena gotowości audytowej, ocena zespołowa z analizą rozbieżności.</p>
<a href="#download" class="block w-full text-center px-6 py-3 bg-gosign-accent-btn text-white font-semibold rounded-lg hover:bg-gosign-accent-btn-hover transition-colors" data-ebook-download>Pobierz assessment</a>
<p class="text-xs text-gosign-text-light mt-3">Wymagany tylko adres e-mail. PDF natychmiast.</p>
</div>
</div>

</div>
</div>
</section>

<!-- Szybki test -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<div class="border-2 border-gosign-accent/20 rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Szybki test: Ocena online</p>
<p class="text-body text-gosign-text mb-4">Nie masz czasu na pełny assessment? Zacznij od 3-minutowego szybkiego testu z 7 pytaniami i automatycznym wykresem radarowym.</p>
<a href="/pl/finance-agent-readiness/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Rozpocznij ocenę online &rarr;</a>
</div>
</div>
</section>

<!-- Więcej eBooków -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Więcej eBooków</h2>
<div class="grid grid-cols-1 sm:grid-cols-2 gap-4">
<a href="/pl/ebook/ai-finance-poradnik-governance/" class="block border border-gosign-border rounded-card p-4 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-1">Finance Governance</p>
<p class="text-body font-semibold text-gosign-dark">AI w finansach: Poradnik Governance</p>
</a>
<a href="/pl/ebook/hr-agent-readiness-assessment/" class="block border border-gosign-border rounded-card p-4 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-1">HR Assessment</p>
<p class="text-body font-semibold text-gosign-dark">HR Agent Readiness Assessment</p>
</a>
</div>
</div>
</section>

--- eBook: HR Agent Readiness Assessment - 15 pytań dla zespołu zarządzającego ---
> Bezpłatny eBook z oceną gotowości: 15 pytań o HR Agent Readiness. Arkusze do wypełnienia, szablon wykresu radarowego, ocena zespołowa z analizą rozbieżności.

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">

<div class="grid md:grid-cols-5 gap-12 items-start">

<div class="md:col-span-3">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Co znajdziesz w tym assessmencie</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
73% organizacji nie posiada jeszcze ram zarządzania AI (ISACA 2024). Ten assessment pokaże Ci, na jakim etapie znajduje się Twoja organizacja HR - nie jako model teoretyczny, ale jako dokument roboczy dla Twojego zespołu.
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8 mb-3">15 pytań w 5 wymiarach</h3>
<ul class="space-y-2 text-body text-gosign-text">
<li class="flex items-start gap-2"><span class="text-gosign-accent-text font-bold">1.</span> Dojrzałość procesów - Jak udokumentowane i spójne są Twoje procesy HR?</li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text font-bold">2.</span> Governance - Kto odpowiada za AI w HR?</li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text font-bold">3.</span> Krajobraz danych - Jak dobra jest jakość Twoich danych HR?</li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text font-bold">4.</span> Rada Zakładowa - Jak zaangażowana jest rada zakładowa w decyzje o AI?</li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text font-bold">5.</span> Infrastruktura IT - Jak zintegrowany jest Twój krajobraz systemów HR?</li>
</ul>

<h3 class="text-h3 font-bold text-gosign-dark mt-8 mb-3">Czym eBook różni się od narzędzia online</h3>
<div class="overflow-x-auto">
<table class="w-full text-body text-gosign-text border-collapse mt-4">
<thead><tr class="border-b-2 border-gosign-border"><th class="text-left py-2 pr-4 font-bold text-gosign-dark">Cecha</th><th class="text-left py-2 pr-4 font-bold text-gosign-dark">Online (3 min.)</th><th class="text-left py-2 font-bold text-gosign-dark">eBook (PDF)</th></tr></thead>
<tbody>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Pytania</td><td class="py-2 pr-4">7</td><td class="py-2">15</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Wykres radarowy</td><td class="py-2 pr-4">Automatyczny</td><td class="py-2">Szablon do samodzielnego rysowania</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Ocena zespołowa</td><td class="py-2 pr-4">Nie</td><td class="py-2">Tak (4-5 uczestników)</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Analiza rozbieżności</td><td class="py-2 pr-4">Nie</td><td class="py-2">Tak</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Do druku</td><td class="py-2 pr-4">Nie</td><td class="py-2">Tak (zoptymalizowany A4)</td></tr>
</tbody>
</table>
</div>
</div>

<div class="md:col-span-2">
<div class="sticky top-24 bg-gosign-light border border-gosign-border rounded-card p-6">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-3">Bezpłatny PDF</p>
<p class="text-h3 font-bold text-gosign-dark mb-2">Pobierz assessment</p>
<p class="text-small text-gosign-text-light mb-4">14 stron, arkusze do wypełnienia, ocena zespołowa z analizą rozbieżności.</p>
<a href="#download" class="block w-full text-center px-6 py-3 bg-gosign-accent-btn text-white font-semibold rounded-lg hover:bg-gosign-accent-btn-hover transition-colors" data-ebook-download>Pobierz assessment</a>
<p class="text-xs text-gosign-text-light mt-3">Wymagany tylko adres e-mail. PDF natychmiast.</p>
</div>
</div>

</div>
</div>
</section>

<!-- Szybki test -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<div class="border-2 border-gosign-accent/20 rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Szybki test: Ocena online</p>
<p class="text-body text-gosign-text mb-4">Nie masz czasu na pełny assessment? Zacznij od 3-minutowego szybkiego testu z 7 pytaniami i automatycznym wykresem radarowym.</p>
<a href="/pl/hr-agent-readiness/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Rozpocznij ocenę online &rarr;</a>
</div>
</div>
</section>

<!-- Więcej eBooków -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Więcej eBooków</h2>
<div class="grid grid-cols-1 sm:grid-cols-2 gap-4">
<a href="/pl/ebook/ai-hr-poradnik-governance/" class="block border border-gosign-border rounded-card p-4 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-1">HR Governance</p>
<p class="text-body font-semibold text-gosign-dark">AI w HR: Poradnik Governance dla Dyrektora HR</p>
</a>
<a href="/pl/ebook/finance-agent-readiness-assessment/" class="block border border-gosign-border rounded-card p-4 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-1">Finance Assessment</p>
<p class="text-body font-semibold text-gosign-dark">Finance Agent Readiness Assessment</p>
</a>
</div>
</div>
</section>

--- Darmowe eBooki - Poradniki AI Governance ---
> Pobierz darmowe poradniki governance dla HR, Finance i Infrastructure. Zgodność z EU AI Act, architektura Decision Layer, ocena gotowości.

<section class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-12">
<div class="grid grid-cols-1 md:grid-cols-3 gap-8">

<div class="bg-white border border-gosign-border rounded-card p-6 flex flex-col">
<div class="w-12 h-12 rounded-full bg-orange-50 flex items-center justify-center mb-4">
<svg class="w-6 h-6 text-gosign-accent" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M17 20h5v-2a3 3 0 00-5.356-1.857M17 20H7m10 0v-2c0-.656-.126-1.283-.356-1.857M7 20H2v-2a3 3 0 015.356-1.857M7 20v-2c0-.656.126-1.283.356-1.857m0 0a5.002 5.002 0 019.288 0M15 7a3 3 0 11-6 0 3 3 0 016 0z"></path></svg>
</div>
<h2 class="text-h3 font-bold text-gosign-dark mb-2">AI w HR</h2>
<p class="text-body text-gosign-text mb-3 flex-1">Checklista EU AI Act, Decision Framework, perspektywa rady zakładowej i ocena gotowości - poradnik governance dla CHRO.</p>
<p class="text-small text-gosign-text-light mb-4">Dla CHRO i liderów HR - 25 stron</p>
<a href="/pl/ebook/ai-hr-poradnik-governance/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Pobierz za darmo</a>
</div>

<div class="bg-white border border-gosign-border rounded-card p-6 flex flex-col">
<div class="w-12 h-12 rounded-full bg-orange-50 flex items-center justify-center mb-4">
<svg class="w-6 h-6 text-gosign-accent" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 7h6m0 10v-3m-3 3h.01M9 17h.01M9 14h.01M12 14h.01M15 11h.01M12 11h.01M9 11h.01M7 21h10a2 2 0 002-2V5a2 2 0 00-2-2H7a2 2 0 00-2 2v14a2 2 0 002 2z"></path></svg>
</div>
<h2 class="text-h3 font-bold text-gosign-dark mb-2">AI w Finance</h2>
<p class="text-body text-gosign-text mb-3 flex-1">Compliance, biegły rewident i Decision Layer - poradnik governance dla CFO. Z H/R/A-Framework i oceną gotowości dla sektora finansowego.</p>
<p class="text-small text-gosign-text-light mb-4">Dla CFO i liderów finansów - 28 stron</p>
<a href="/pl/ebook/ai-finance-poradnik-governance/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Pobierz za darmo</a>
</div>

<div class="bg-white border border-gosign-border rounded-card p-6 flex flex-col">
<div class="w-12 h-12 rounded-full bg-orange-50 flex items-center justify-center mb-4">
<svg class="w-6 h-6 text-gosign-accent" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M5 12h14M5 12a2 2 0 01-2-2V6a2 2 0 012-2h14a2 2 0 012 2v4a2 2 0 01-2 2M5 12a2 2 0 00-2 2v4a2 2 0 002 2h14a2 2 0 002-2v-4a2 2 0 00-2-2m-2-4h.01M17 16h.01"></path></svg>
</div>
<h2 class="text-h3 font-bold text-gosign-dark mb-2">Infrastruktura AI</h2>
<p class="text-body text-gosign-text mb-3 flex-1">Build, Buy, Hybrid - infrastruktura zgodna z EU AI Act. Z B/B/H-Framework, 7-Layer Reference Architecture i checklistą CTO.</p>
<p class="text-small text-gosign-text-light mb-4">Dla CTO i liderów IT - 28 stron</p>
<a href="/pl/ebook/ai-infrastructure-poradnik-governance/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Pobierz za darmo</a>
</div>

</div>

<h2 class="text-h2 font-bold text-gosign-dark mt-12 mb-6">Readiness Assessments</h2>
<p class="text-body text-gosign-text-light mb-8">Jak gotowa jest Twoja organizacja na AI Agents? 15 pytań, arkusze do wypełnienia, ocena zespołowa z analizą rozbieżności.</p>

<div class="grid grid-cols-1 md:grid-cols-2 gap-8">

<div class="bg-white border-2 border-gosign-accent/20 rounded-card p-6 flex flex-col">
<div class="w-12 h-12 rounded-full bg-orange-50 flex items-center justify-center mb-4">
<svg class="w-6 h-6 text-gosign-accent" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 5H7a2 2 0 00-2 2v12a2 2 0 002 2h10a2 2 0 002-2V7a2 2 0 00-2-2h-2M9 5a2 2 0 002 2h2a2 2 0 002-2M9 5a2 2 0 012-2h2a2 2 0 012 2m-6 9l2 2 4-4"></path></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">HR Agent Readiness</h3>
<p class="text-body text-gosign-text mb-3 flex-1">15 pytań dla zespołu kierowniczego. Dojrzałość procesów, governance, krajobraz danych, współdecydowanie, infrastruktura IT.</p>
<p class="text-small text-gosign-text-light mb-4">Dla CHRO i kierownictwa HR - 14 stron</p>
<a href="/pl/ebook/hr-agent-readiness-assessment/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Pobierz assessment</a>
</div>

<div class="bg-white border-2 border-gosign-accent/20 rounded-card p-6 flex flex-col">
<div class="w-12 h-12 rounded-full bg-orange-50 flex items-center justify-center mb-4">
<svg class="w-6 h-6 text-gosign-accent" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 5H7a2 2 0 00-2 2v12a2 2 0 002 2h10a2 2 0 002-2V7a2 2 0 00-2-2h-2M9 5a2 2 0 002 2h2a2 2 0 002-2M9 5a2 2 0 012-2h2a2 2 0 012 2m-6 9l2 2 4-4"></path></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Finance Agent Readiness</h3>
<p class="text-body text-gosign-text mb-3 flex-1">15 pytań dla CFO i biegłego rewidenta. Weryfikacja compliance, krajobraz ERP, szybkość zamknięcia, dojrzałość wykrywania oszustw.</p>
<p class="text-small text-gosign-text-light mb-4">Dla CFO i kierownictwa finansów - 14 stron</p>
<a href="/pl/ebook/finance-agent-readiness-assessment/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Pobierz assessment</a>
</div>

</div>

<h2 class="text-h2 font-bold text-gosign-dark mt-12 mb-6">Szybki test online</h2>
<p class="text-body text-gosign-text-light mb-8">Nie masz czasu na pełny assessment z 15 pytaniami? Szybki test online zajmuje 3 minuty - z automatycznym wykresem radarowym i rekomendacjami agentów.</p>

<div class="grid grid-cols-1 md:grid-cols-2 gap-8">
<a href="/pl/hr-agent-readiness/" class="block bg-gosign-dark rounded-card p-6 hover:bg-gosign-dark/90 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">3 minuty, 7 pytań</p>
<p class="text-h3 font-bold text-white">HR Agent Readiness</p>
<p class="text-body text-white/70 mt-2">Poziom dojrzałości, wykres radarowy i rekomendacje z katalogu 48 agentów.</p>
</a>
<a href="/pl/finance-agent-readiness/" class="block bg-gosign-dark rounded-card p-6 hover:bg-gosign-dark/90 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">3 minuty, 7 pytań</p>
<p class="text-h3 font-bold text-white">Finance Agent Readiness</p>
<p class="text-body text-white/70 mt-2">Poziom dojrzałości, wykres radarowy i rekomendacje z katalogu 49 agentów.</p>
</a>
</div>

</section>

--- Fakty - Gosign w Liczbach ---
> Cytowalne fakty o Gosign GmbH. Dane firmowe, lokalizacje, certyfikacje i standardy compliance w pigułce.

<article class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<div class="prose prose-lg prose-headings:text-gosign-dark prose-headings:font-bold prose-h2:text-h2 prose-h2:mt-12 prose-h2:mb-4 prose-h3:text-h3 prose-h3:mt-8 prose-h3:mb-3 prose-p:text-gosign-text prose-p:leading-relaxed prose-a:text-gosign-accent-text prose-a:underline prose-a:decoration-gosign-accent-text/30 hover:prose-a:decoration-gosign-accent-text prose-strong:text-gosign-dark prose-ul:text-gosign-text prose-ol:text-gosign-text">

## Firma

Gosign GmbH. Firma zajmująca się tworzeniem oprogramowania, założona w Hamburgu w 2001. Firma właścicielska. Dyrektorzy zarządzający: Bert Gogolin i Dieter Gogolin. Hallerstraße 8, 20146 Hamburg, Niemcy. Rejestr Handlowy Hamburg HRB 112197. NIP UE: DE215891388.

## Kluczowe Dane

108 pracowników. Ponad 5 000 projektów od 2001. 25 lat tworzenia oprogramowania. Od 2023 fokus na Enterprise AI Infrastructure i Agent Engineering. Klienci referencyjni: Airbus, Volkswagen, Shell, Evonik, Sony.

## Lokalizacje

Hamburg (siedziba główna), Kraków, Barcelona, Lizbona, São Paulo. Centrum rozwojowe w Pakistanie od 2002.

## Języki

Niemiecki, angielski, polski, hiszpański, portugalski, urdu.

## Członkostwa i Certyfikacje

Członek BVDW (Bundesverband Digitale Wirtschaft). Inżynierowie AI z certyfikacją Microsoft Azure AI.

## Standardy Compliance

Cert-Ready by Design: ISA, PS 951, IDW, GoB/GoBD (niemiecki standard dokumentacji) (niemiecki standard dokumentacji). EU AI Act Readiness: klasyfikacja ryzyka i obowiązki dokumentacyjne zintegrowane z architekturą agentów. Data Residency: przetwarzanie danych w infrastrukturze klienta - Azure UE, GCP UE, AWS UE, Self-Hosted lub hybryda. Klient decyduje o regionie i modelu hostingu. DPA ze wszystkimi podwykonawcami. Dla pełnej niezależności od Cloud Act: Self-Hosted we własnym centrum danych lub na własnych serwerach. RODO: brak ciasteczek, brak trackerów, brak zewnętrznych osadzeń na gosign.de. Analityka webowa bez ciasteczek, zagregowana.

## Kontakt

Gosign GmbH · Hallerstraße 8 · 20146 Hamburg, Niemcy
> [Skontaktuj się](/pl/kontakt/)

</div>
</div>
</article>

--- AI Agents dla Finance & Audit ---
> Enterprise AI Agents dla procesów finansowych: dokumenty, amortyzacja, korekty księgowe, oceny podatkowe. prüfungsfähig by Design, audytowalne

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/pl/dlaczego-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Każda decyzja możliwa do prześledzenia</p>
</div>
</a>
<a href="/pl/dlaczego-gosign/#infrastruktura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Twoja infrastruktura</p>
<p class="text-xs text-gosign-text-light">Bez SaaS. Bez vendor-lock-in.</p>
</div>
</a>
<a href="/pl/dlaczego-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Bez ryzyka US-cloud</p>
</div>
</a>
</div>
</div>
</div>

<div class="not-prose my-8 bg-gosign-dark rounded-card p-6 sm:p-8">
<div class="flex flex-col sm:flex-row sm:items-center gap-4">
<div class="flex-1">
<p class="text-h3 font-bold text-white mb-2">Darmowy eBook: AI w Finance</p>
<p class="text-body text-white/80">Compliance, biegły rewident i Decision Layer - poradnik governance dla liderów finansów.</p>
</div>
<a href="/pl/ebook/ai-finance-poradnik-governance/" class="inline-flex items-center gap-2 px-6 py-3 bg-gosign-accent-btn text-white font-semibold rounded-lg hover:bg-gosign-accent-btn-hover transition-colors whitespace-nowrap">Pobierz teraz</a>
</div>
</div>

<!-- Problem -->
<section class="py-section bg-gosign-white"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow"><h2 class="text-h1 font-bold text-gosign-dark">Problem: Logika księgowa w głowach, nie w systemie</h2><p class="text-body-lg text-gosign-text-light mt-4">Decyzje finansowe w przedsiębiorstwach zależą od wiedzy poszczególnych księgowych. Klasyfikacje amortyzacyjne, rachunki kosztowe, korekty, oceny podatkowe - zbiór reguł jest złożony, a zastosowanie różni się w zależności od osoby, lokalizacji i interpretacji.</p><p class="text-body-lg text-gosign-text-light mt-4">Konsekwencje trafiają bezpośrednio w bilans: korekty, które można było uniknąć. Klasyfikacje amortyzacyjne kwestionowane dopiero przez biegłego rewidenta. Rachunki kosztowe traktowane różnie w każdym biurze.</p><p class="text-body-lg text-gosign-text-light mt-4">Dla biegłych rewidentów, rewizji wewnętrznej i centrów usług wspólnych to ryzyko systemowe: każda nieudokumentowana decyzja to potencjalne ustalenie audytowe.</p><p class="text-body-lg text-gosign-text-light mt-4">Ta niespójność nie tylko zwiększa korekty księgowe - zwiększa również nakład audytowy, pętle uzgadniania i ryzyko ustaleń ze strony rewizji wewnętrznej lub biegłych rewidentów. Decision Layer przenosi te ryzyka z indywidualnej interpretacji do wersjonowanej, identyfikowalnej architektury decyzyjnej.</p></div></div></section>

<!-- Czym jest Finance Agent? -->
<section class="py-section bg-gosign-light"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow"><h2 class="text-h1 font-bold text-gosign-dark">Czym jest Finance Agent?</h2><p class="text-body-lg text-gosign-text-light mt-4">Finance Agent to wyspecjalizowany AI Agent do przetwarzania dokumentów i księgowości. Czyta dokumenty z kontekstowym rozumieniem języka, ocenia je merytorycznie na tle wersjonowanych zbiorów reguł (prawo podatkowe, standardy rachunkowości, polityki wewnętrzne) i generuje udokumentowane propozycje księgowań. <a href="/pl/decision-layer/" class="text-gosign-accent-text hover:text-gosign-accent-hover">Decision Layer</a> routuje każdą mikrodecyzję: autonomicznie przy wysokiej confidence i jasnej regule, do specjalisty przy przypadkach wyjątkowych.</p><p class="text-body-lg text-gosign-text-light mt-4">SAP i Comarch pozostają Twoimi wiodącymi systemami. Finance Agent działa przed nimi - dostarcza gotowe do decyzji wyniki wraz z kompletnym łańcuchem uzasadnienia. Każda decyzja tworzy kompletny zapis decyzyjny: input, zastosowana reguła, wersja reguły, confidence, ścieżka decyzyjna, wynik. To nie jest dokumentacja po fakcie - to techniczny dowód procesu decyzyjnego.</p></div></div></section>

<!-- Use Cases -->
<section class="py-section bg-gosign-light"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><h2 class="text-h1 font-bold text-gosign-dark mb-8">Konkretne scenariusze zastosowań</h2><div class="grid grid-cols-1 md:grid-cols-2 gap-6"><div class="border border-gosign-border rounded-card p-6 bg-gosign-white"><h3 class="text-h3 font-bold text-gosign-dark">Przetwarzanie i klasyfikacja dokumentów</h3><p class="text-body text-gosign-text-light mt-2">Document Agent czyta, rozumie i ocenia dokumenty z rzeczywistym rozumieniem języka - nie sztywne łańcuchy reguł. Faktury, korekty, storna, rachunki kosztowe. Decision Layer sprawdza kompletność, wiarygodność i klasyfikację podatkową.</p></div><div class="border border-gosign-border rounded-card p-6 bg-gosign-white"><h3 class="text-h3 font-bold text-gosign-dark">Logika amortyzacji</h3><p class="text-body text-gosign-text-light mt-2">Logika amortyzacji różni się w zależności od rodzaju aktywów, klasyfikacji podatkowej i regionu. Decision Layer definiuje logikę: klasyfikacja rodzaju aktywów, sprawdzenie klasyfikacji podatkowej, zastosowanie tabeli amortyzacji, dokumentacja uzasadnienia.</p></div><div class="border border-gosign-border rounded-card p-6 bg-gosign-white"><h3 class="text-h3 font-bold text-gosign-dark">Rachunki kosztowe reprezentacji</h3><p class="text-body text-gosign-text-light mt-2">Różna interpretacja odliczalności to jeden z najczęstszych punktów audytowych. Decision Layer standaryzuje: sprawdzenie kompletności, weryfikacja listy uczestników, sprawdzenie celu i związku biznesowego, zastosowanie reguł odliczalności.</p></div><div class="border border-gosign-border rounded-card p-6 bg-gosign-white"><h3 class="text-h3 font-bold text-gosign-dark">Korekty i zapewnienie jakości</h3><p class="text-body text-gosign-text-light mt-2">Eliminuj korekty zanim powstaną. Workflow Agent orkiestruje proces zapewnienia jakości: automatyczne sprawdzenie wiarygodności przed księgowaniem, porównanie z wartościami referencyjnymi, eskalacja przy anomaliach.</p></div></div></div></section>

<!-- Cztery kroki -->
<section class="py-section bg-gosign-white"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow"><h2 class="text-h1 font-bold text-gosign-dark">Cztery kroki: od dokumentu do księgowania gotowego na audyt</h2><p class="text-body-lg text-gosign-text-light mt-4"><strong>1. Czytanie i rozumienie</strong> - Agent czyta dokument z kontekstowym rozumieniem języka. Wystawca, kwota, opis usługi, cechy istotne podatkowo. Nie sztywne dopasowywanie szablonów - rzeczywiste rozumienie dokumentu.</p><p class="text-body-lg text-gosign-text-light mt-4"><strong>2. Ocena merytoryczna</strong> - Konto, centrum kosztów, klasyfikacja podatkowa, początek amortyzacji, kryteria rachunków kosztowych. Każda ocena opiera się na wersjonowanym zbiorze reguł - nie na doświadczeniu poszczególnych księgowych.</p><p class="text-body-lg text-gosign-text-light mt-4"><strong>3. Decyzja</strong> - Decision Layer routuje: autonomicznie przy wysokiej confidence i jasnej regule, do specjalisty przy wyjątkach lub niskiej confidence. Progi definiujesz Ty - nie AI.</p><p class="text-body-lg text-gosign-text-light mt-4"><strong>4. Dokumentacja</strong> - Każda mikrodecyzja tworzy zapis decyzyjny: input, zastosowana reguła, wersja reguły, confidence, ścieżka decyzyjna, wynik, znacznik czasu. To nie jest dokumentacja po fakcie - to techniczny dowód procesu decyzyjnego.</p></div></div></section>

<!-- Przepływ decyzyjny -->
<section class="py-section bg-gosign-light"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><h2 class="text-h1 font-bold text-gosign-dark mb-6">Przepływ decyzyjny</h2><div class="mt-8 bg-gosign-dark rounded-card p-6 sm:p-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-4">Dokument → Agent wyodrębnia → Decision Layer rozkłada na kroki</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-4">
<div class="bg-white/5 rounded-card p-4">
<p class="text-xs font-bold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Reguły</p>
<p class="text-small text-white/90 font-semibold">Jednoznaczne przypadki</p>
<p class="text-small text-white/60 mt-2">Stawka VAT wg przepisów. Deterministyczne obliczenie.</p>
</div>
<div class="bg-white/5 rounded-card p-4">
<p class="text-xs font-bold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Agent KI</p>
<p class="text-small text-white/90 font-semibold">Decyzja na podstawie confidence</p>
<p class="text-small text-white/60 mt-2">Propozycja konta ze score. Autonomicznie powyżej progu.</p>
</div>
<div class="bg-white/5 rounded-card p-4">
<p class="text-xs font-bold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Człowiek</p>
<p class="text-small text-white/90 font-semibold">Wyjątek</p>
<p class="text-small text-white/60 mt-2">Specjalista weryfikuje i decyduje z kontekstem.</p>
</div>
</div>
<p class="text-xs text-white/60 mt-4 text-center">Audit Trail na każdy krok: Reguła · Wersja · Decydent</p>
</div></div></section>

<!-- Decision Layer -->
<section class="py-section bg-gosign-white"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow"><h2 class="text-h1 font-bold text-gosign-dark"><a href="/pl/decision-layer/" class="hover:text-gosign-accent transition-colors">Decision Layer</a>: jak decyzje finansowe stają się gotowe do audytu</h2><p class="text-body-lg text-gosign-text-light mt-4"><a href="/pl/decision-layer/" class="text-gosign-accent-text hover:underline">Decision Layer</a> rozkłada proces księgowania na poszczególne kroki decyzyjne. Dla każdego kroku definiuje: czy decyduje agent, zbiór reguł, czy człowiek?</p><p class="text-body-lg text-gosign-text-light mt-4">Agent czyta, rozumie i ocenia dokumenty z rzeczywistym rozumieniem języka. Decision Layer routuje każdą ocenę:</p><div class="mt-6 bg-gosign-light border border-gosign-border rounded-card p-6"><p class="text-body font-mono text-gosign-dark">Dokument &rarr; Ekstrakcja &rarr; Klasyfikacja &rarr; Ocena merytoryczna &rarr; Confidence Score &rarr; Propozycja księgowania lub eskalacja do człowieka</p></div><p class="text-body-lg text-gosign-text-light mt-4">Każda decyzja generuje kompletny, niezmienny zapis: input, model, ocena, confidence score, zastosowana reguła z wersją, ścieżka decyzyjna, wynik. To nie jest dokumentacja po fakcie - to techniczny dowód procesu decyzyjnego.</p><p class="text-body text-gosign-text-light mt-4">Jak wyglądają modele kosztowe dla Enterprise AI i ile naprawdę kosztuje self-hosting vs. chmura, pokazuje <a href="/pl/magazyn/koszty-ai-tco-porownanie/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">porównanie TCO w Blueprint 2026</a>.</p></div></div></section>

<!-- Cert-Ready -->
<section class="py-section bg-gosign-light"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow"><h2 class="text-h1 font-bold text-gosign-dark">Cert-Ready by Design</h2><p class="text-body-lg text-gosign-text-light mt-4 italic">Nie &bdquo;mamy ISO&rdquo;. Nie &bdquo;nie potrzebujemy ISO&rdquo;. Raczej: każdy agent jest technicznie zbudowany tak, aby był w każdej chwili certyfikowalny i audytowalny.</p><p class="text-body-lg text-gosign-text-light mt-4">Kontrole to obiekty danych pierwszej klasy w systemie - nie dokumenty w folderze. Każda kontrola ma implementację techniczną, automatyczny generator dowodów i historię dowodów z drill-down do konkretnej implementacji.</p><p class="text-body-lg text-gosign-text-light mt-4">Kontrole żyją w bazie danych, nie w Confluence. Dowody są generowane automatycznie. Audytorzy widzą status na żywo w Portalu Audytora. Żadnych pakietów Excel, żadnych raportów PDF.</p><h3 class="text-h3 font-bold text-gosign-dark mt-8">Control Object Structure</h3><div class="mt-4 overflow-x-auto"><table class="w-full text-body text-gosign-text-light border-collapse"><thead><tr class="border-b-2 border-gosign-border"><th class="text-left py-2 pr-4 font-bold text-gosign-dark">Element</th><th class="text-left py-2 font-bold text-gosign-dark">Funkcja</th></tr></thead><tbody><tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-mono text-small">Control_ID</td><td class="py-2">Jednoznaczna identyfikacja kontroli</td></tr><tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-mono text-small">Technical_Implementation</td><td class="py-2">Konkretna implementacja techniczna (np. polityka RLS, check API)</td></tr><tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-mono text-small">Rule_Version</td><td class="py-2">Wersja logiki decyzyjnej</td></tr><tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-mono text-small">Evidence_Generator</td><td class="py-2">Automatyczny mechanizm weryfikacji</td></tr><tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-mono text-small">Evidence_History</td><td class="py-2">Historia wyników weryfikacji ze znacznikiem czasu</td></tr><tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-mono text-small">Auditor_View</td><td class="py-2">Widok z drill-down do poziomu implementacji</td></tr></tbody></table></div><p class="text-body-lg text-gosign-text-light mt-4">Kontrole to obiekty danych pierwszej klasy. Dowody generowane automatycznie. Audytor widzi status na żywo, nie snapshoty.</p></div></div></section>

<!-- Integracja -->
<section class="py-section bg-gosign-white"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow"><h2 class="text-h1 font-bold text-gosign-dark">Integracja z istniejącym krajobrazem systemowym</h2><p class="text-body-lg text-gosign-text-light mt-4">AI Agents nie zastępują systemów. SAP FI/CO pozostaje Twoim ERP, Comarch pozostaje Twoim systemem podatkowym. Logika agenta jest oddzielona od systemu docelowego - logika księgowania jest separowana od eksportu.</p><div class="mt-6 flex flex-wrap gap-3"><span class="bg-gosign-light border border-gosign-border rounded-card px-4 py-2 text-body font-medium text-gosign-dark">SAP FI/CO</span><span class="bg-gosign-light border border-gosign-border rounded-card px-4 py-2 text-body font-medium text-gosign-dark">Comarch ERP</span><span class="bg-gosign-light border border-gosign-border rounded-card px-4 py-2 text-body font-medium text-gosign-dark">SAP S/4HANA</span><span class="bg-gosign-light border border-gosign-border rounded-card px-4 py-2 text-body font-medium text-gosign-dark">SharePoint</span><span class="bg-gosign-light border border-gosign-border rounded-card px-4 py-2 text-body font-medium text-gosign-dark">Microsoft Teams</span><span class="bg-gosign-light border border-gosign-border rounded-card px-4 py-2 text-body font-medium text-gosign-dark">REST/SOAP</span></div></div></div></section>

<div class="not-prose my-6 p-4 border-l-4 border-gosign-accent bg-gosign-light">
<p class="text-body font-semibold text-gosign-dark">Tajemnica zawodowa (§203 StGB (niemiecki przepis kodeksu karnego dotyczący tajemnicy zawodowej))</p>
<p class="text-body text-gosign-text mt-1">Wszystkie dane klientów pozostają pod kontrolą osoby zobowiązanej do zachowania tajemnicy zawodowej. Architektura zgodna z §203, brak zależności od SaaS. Infrastruktura wyłącznie w UE jako dowód techniczny.</p>
</div>

<!-- Grupy docelowe -->
<section class="py-section bg-gosign-light"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><h2 class="text-h1 font-bold text-gosign-dark mb-8">Grupy docelowe</h2><div class="grid grid-cols-1 md:grid-cols-3 gap-6"><div class="border border-gosign-border rounded-card p-6 bg-gosign-white"><h3 class="text-h3 font-bold text-gosign-dark">Firmy audytorskie i biura doradztwa podatkowego</h3><p class="text-body text-gosign-text-light mt-2">Setki klientów, tysiące dokumentów miesięcznie. Finance Agent zapewnia spójność przetwarzania we wszystkich mandatach.</p></div><div class="border border-gosign-border rounded-card p-6 bg-gosign-white"><h3 class="text-h3 font-bold text-gosign-dark">Centra usług wspólnych</h3><p class="text-body text-gosign-text-light mt-2">Wiele podmiotów, różne kraje, różne zbiory reguł. Finance Agent stosuje reguły specyficzne dla mandatu w sposób spójny.</p></div><div class="border border-gosign-border rounded-card p-6 bg-gosign-white"><h3 class="text-h3 font-bold text-gosign-dark">Przedsiębiorstwa z własną księgowością</h3><p class="text-body text-gosign-text-light mt-2">Zamknięcia miesięczne, raporty kwartalne, kontrole podatkowe. Mniej korekt księgowych, spójna klasyfikacja, kompletna dokumentacja.</p></div></div></div></section>

<!-- Process -->
<section class="py-section bg-gosign-dark text-white"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><h2 class="text-h1 font-bold">Od pierwszego agenta do platformy Finance</h2><div class="grid md:grid-cols-3 gap-8 mt-8"><div><p class="text-xs font-bold uppercase tracking-wider text-gosign-accent-on-dark">Discover - 1 tydzień</p><p class="text-body-lg text-gosign-text-on-dark/80 mt-2">Analiza procesów z Twoim zespołem finansowym. Mapowanie logiki księgowej, dokumentacja zbiorów reguł. Priorytetyzacja zastosowań.</p></div><div><p class="text-xs font-bold uppercase tracking-wider text-gosign-accent-on-dark">Build - 3-4 tygodnie</p><p class="text-body-lg text-gosign-text-on-dark/80 mt-2">Produkcyjny PoC. Jeden agent, jeden proces finansowy, na żywo w Twojej infrastrukturze. Decision Layer, governance, ścieżka audytu - od pierwszego dnia.</p></div><div><p class="text-xs font-bold uppercase tracking-wider text-gosign-accent-on-dark">Scale - Ciągły</p><p class="text-body-lg text-gosign-text-on-dark/80 mt-2">Więcej agentów dla kolejnych procesów finansowych. Korekty, rachunki kosztowe, oceny podatkowe, intercompany.</p></div></div><p class="text-body text-gosign-text-on-dark/60 mt-6 italic">Po 12-18 miesiącach eksploatujesz swoich Finance Agents samodzielnie.</p></div></section>

<!-- Business Impact -->
<section class="py-section bg-gosign-light"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow"><h2 class="text-h1 font-bold text-gosign-dark">Business Impact</h2><p class="text-body-lg font-semibold text-gosign-dark mt-4">Audytowalna logika decyzyjna dla procesów finansowych.</p><ul class="mt-4 space-y-3 text-body-lg text-gosign-text-light list-none"><li>Korekty prewencyjnie wyeliminowane - nie korygowane po fakcie.</li><li>Audytowalna logika decyzyjna dla biegłych rewidentów i rewizji wewnętrznej.</li><li>Spójna logika księgowa we wszystkich lokalizacjach i spółkach.</li><li>Obniżone ryzyko podatkowe i compliance.</li><li>Skalowalność bez utraty wiedzy przy rotacji księgowych.</li><li>Cert-Ready by Design - strukturalnie gotowe do audytu.</li><li>Redukcja nakładu audytowego dzięki kompletnym aktom decyzyjnym na dokument.</li><li>Mniej wewnętrznych pętli uzgadniania dzięki spójnemu stosowaniu reguł.</li><li>Szybsze zamknięcia miesięczne dzięki autonomicznemu przetwarzaniu rutyny.</li></ul></div></div></section>

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Finance Agent Readiness Assessment</p>
<p class="text-body text-gosign-text mb-4">7 pytań, 3 minuty: Jak gotowa jest Twoja organizacja finansowa na AI Agents?</p>
<a href="/pl/finance-agent-readiness/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Rozpocznij assessment &rarr;</a>
</div>

<!-- Finance Agent Assessment -->
<section class="py-section bg-gosign-dark text-white"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow">
<h2 class="text-h1 font-bold">Finance Agent Assessment: 49 agentów ocenionych i priorytetyzowanych</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4">Jakie agenty finansowe istnieją, jakiej governance potrzebują i od czego zacząć? Assessment ocenia 49 agentów w 6 wymiarach - od poziomu autonomii po istotność audytową - aby móc priorytetyzować z pewnością.</p>
<a href="/pl/katalog-agentow-finance/" class="inline-flex items-center gap-2 mt-4 text-body font-semibold text-gosign-accent-on-dark hover:underline">Do Finance Agent Assessment &rarr;</a>
</div></div></section>

<!-- Pogłębienie -->
<section class="py-section bg-gosign-white"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><h2 class="text-h2 font-bold text-gosign-dark mb-2">Pogłębienie w Agent Briefing</h2><p class="text-body text-gosign-text-light mb-6">Nasza seria artykułów fachowych dla decydentów automatyzujących procesy finansowe z AI Agents.</p><div class="grid grid-cols-1 sm:grid-cols-3 gap-6"><a href="/pl/magazyn/koszty-ai-tco-porownanie/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors"><p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Finance</p><p class="text-body font-semibold text-gosign-dark">Koszty AI w porównaniu: Analiza TCO dla Enterprise</p></a><a href="/pl/magazyn/decision-layer-shadow-ai/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors"><p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p><p class="text-body font-semibold text-gosign-dark">Decision Layer vs. Shadow AI: Dlaczego Governance jest ważniejsze od szybkości</p></a><a href="/pl/magazyn/deepseek-enterprise-hosting/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors"><p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p><p class="text-body font-semibold text-gosign-dark">Hosting AI: EU SaaS, niemieckie centrum danych czy Self-Hosted?</p></a></div></div></section>

--- Glosariusz - Terminy Enterprise AI ---
> Terminy fachowe ze świata Enterprise AI. Od Agent do Zero-Trust - jasno zdefiniowane, konsekwentnie używane.

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 prose prose-lg">

## Typy Agentów

### Document Agent

Wyspecjalizowany AI Agent, który czyta, rozumie i przetwarza dokumenty. Bez rozpoznawania szablonów, bez sztywnego OCR - kontekstowe rozumienie językowe. Document Agents przetwarzają faktury, zwolnienia lekarskie, umowy, zaświadczenia. Każda decyzja jest dokumentowana przez Decision Layer.

> [Document Agents w szczegółach](/pl/uslugi/ai-agents/document-agents/)

### Workflow Agent

AI Agent, który orkiestruje procesy biznesowe międzysystemowo. Od poczty przychodzącej przez zatwierdzenie do księgowania. Każdy krok jest protokołowany. Przy zapytaniach lub brakujących informacjach workflow jest wstrzymywany - nie przerywany.

> [Workflow Agents w szczegółach](/pl/uslugi/ai-agents/workflow-agents/)

### Knowledge Agent

AI Agent, który dostarcza kontekstowe odpowiedzi z wiedzy korporacyjnej. Porozumienia zakładowe, polityki, układy zbiorowe. Każda odpowiedź zawiera źródło i wersję reguły. Bez źródła brak odpowiedzi.

> [Knowledge Agents w szczegółach](/pl/uslugi/ai-agents/knowledge-agents/)

---

## Pojęcia Governance

### Decision Layer

Decision Layer rozkłada każdy proces biznesowy na pojedyncze kroki decyzyjne i definiuje z góry dla każdego z nich: Czy decyduje człowiek, zestaw reguł, czy AI samodzielnie? Tam, gdzie w grę wchodzi swoboda oceny lub ryzyko dyskryminacji, architektura wymusza weryfikację przez człowieka. Tam, gdzie decyzja jest deterministyczna, agent stosuje zestaw reguł konsekwentnie. A tam, gdzie agent jest wystarczająco pewny i ma odpowiednie uprawnienia: decyduje samodzielnie - interpretuje dokumenty, klasyfikuje sytuacje, ocenia kontekst. To nie jest if-then-else - to zdolność oceny w ramach zdefiniowanych ram.

> [Decision Layer w szczegółach](/pl/decision-layer/)

### Human-in-the-Loop

Zasada architektoniczna, która zapewnia, że ludzie zachowują kontrolę nad krytycznymi decyzjami. Nie przycisk awaryjny, lecz strukturalny element Decision Layer: decyzje wymagające oceny ludzkiej są kierowane do odpowiedzialnych pracowników.

### Governance by Design

Compliance, audytowalność i nadzór ludzki są wbudowane w architekturę od pierwszego dnia. Nie projekt następczy, lecz zasada projektowania.

### Cert-Ready by Design

Kontrole jako techniczne obiekty danych z automatycznym generowaniem dowodów. Architektura jest zaprojektowana tak, aby certyfikacje (ISO 27001, SOC 2, EU AI Act) mogły być przeprowadzone bez dodatkowego projektu.

### Audit Trail

Kompletny protokół wszystkich decyzji agenta. Każda decyzja, każda reguła, każda eskalacja jest dokumentowana, wersjonowana i eksportowalna.

---

## Infrastruktura

### RAG (Retrieval-Augmented Generation)

Metoda łącząca wyszukiwanie informacji z generowaniem tekstu. Agent przeszukuje bazę wiedzy i generuje odpowiedź na podstawie znalezionych dokumentów - z referencją źródłową.

### Shadow IT

Nieautoryzowane narzędzia AI używane przez pracowników bez wiedzy działu IT. Ryzyko: brak governance, brak audytowalności, potencjalne naruszenia RODO. Gosign zastępuje Shadow IT kontrolowaną infrastrukturą agentową.

</div>
</section>

--- Cert-Ready by Design ---
> Kontrole jako obiekty danych pierwszej klasy. Automatyczne generowanie dowodów. Portal Audytora na żywo. Strukturalnie przygotowany do audytu.

<!-- Zasada -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Zasada</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
W tradycyjnych podejściach do compliance kontrole są opisywane w dokumentach, dowody zbierane ręcznie, a audyty przeprowadzane jako projekty okresowe.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Cert-Ready by Design odwraca to: kontrole to techniczne obiekty danych w systemie. Dowody generowane są automatycznie. Audytor widzi status na żywo.
</p>
</div>
</section>

<!-- Trzy Wyróżniki -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">Co wyróżnia Cert-Ready by Design</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Kontrole żyją w systemie</h3>
<p class="text-body text-gosign-text-light mt-2">Nie w Confluence. Nie w dokumencie Word. To obiekty danych w bazie - na żywo, wersjonowane, testowalne.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Dowody generowane automatycznie</h3>
<p class="text-body text-gosign-text-light mt-2">Jeśli kontrola nie może wygenerować dowodu, to samo jest odkryciem.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Kompletny drill-down</h3>
<p class="text-body text-gosign-text-light mt-2">Od sygnalizatora do konkretnej polityki RLS z SQL testowym.</p>
</div>
</div>
</div>
</section>

<!-- Kontrole jako Obiekty Danych -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Kontrole jako Obiekty Danych Pierwszej Klasy</h2>
<div class="mt-8 space-y-6">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">1. Implementacja Techniczna</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Kontrola nie jest tylko udokumentowana - jest zaimplementowana. Przykłady: polityka RLS wymuszająca izolację tenantów, check API walidujący wersję reguły, trigger automatycznie rejestrujący zmiany konfiguracji. Implementacja jest prawdą.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">2. Automatyczny Generator Dowodów</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Każda kontrola ma przypisany generator dowodów uruchamiany okresowo lub zdarzeniowo. Żadna osoba nie zbiera zrzutów ekranu. System generuje własne dowody.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Najmniejszą jednostką dowodu jest <a href="/pl/magazyn/akt-decyzyjny-podwazalne-decyzje-ai/" class="text-gosign-accent-text hover:underline">akt decyzyjny</a> na każdą mikrodecyzję: niezmienny dowód z inputem, zastosowaną regułą merytoryczną wraz z wersją, pewnością, wersją modelu, wynikiem, znacznikiem czasu i ścieżką podważenia - podstawa, na której opierają się kontrole.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">3. Historia Dowodów</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Każdy zapis dowodu z: znacznikiem czasu, statusem (pozytywny, negatywny, ostrzeżenie), wersją kontroli, wersją logiki testu. Historia jest niezmienna.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">4. Widok Audytora z Drill-Down</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Portal Audytora: status sygnalizacyjny per kontrola, ostatni znacznik czasu, trend w czasie, drill-down od wskaźnika do konkretnej polityki RLS i SQL testowego.
</p>
</div>
</div>
</div>
</div>
</section>

<!-- Struktura Control Object -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Cert-Ready Control Object - Struktura</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Każda kontrola to ustrukturyzowany obiekt danych z mapowaniem na frameworki, implementacją techniczną, automatycznym generatorem dowodów i widokiem audytora.
</p>
</div>
<div class="mt-8">
<pre class="bg-gosign-dark text-white p-6 rounded-card overflow-x-auto text-small font-mono leading-relaxed"><code>Control Object {
id:                 "ctrl-rbac-001"
name:               "Tenant isolation at database level"
category:           "Access Control"

implementation: {
type:             "RLS Policy"
reference:        "policies/tenant_isolation.sql"
deployed:         true
last_verified:    "2026-02-20T09:14:00Z"
}

evidence_generator: {
type:             "automated_test"
schedule:         "every_6h"
test_reference:   "tests/tenant_isolation_test.sql"
}

evidence_history: [
{
timestamp:      "2026-02-20T09:14:00Z"
status:         "passed"
control_version: "1.3"
test_version:   "2.1"
raw_data:       { ... }
},
...
]

framework_mapping: {
iso_27001:        "A.9.4.1"
soc2:             "CC6.1"
eu_ai_act:        "Art. 12"
}

owner:              "security-team"
last_change:        "2026-02-18T14:22:00Z"
change_reason:      "Policy update for new entity"
}</code></pre>
</div>
</div>
</section>

<!-- Portal Audytora -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Portal Audytora</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Zewnętrzni audytorzy uzyskują bezpośredni dostęp do wszystkich danych governance. Bez przygotowanych prezentacji, bez filtrowanych eksportów. Audytor widzi rzeczywisty, aktualny stan systemu.
</p>
</div>
<div class="mt-8 grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-3 gap-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Dashboard</h3>
<p class="text-body text-gosign-text-light mt-2">Przegląd wszystkich kontroli ze statusem sygnalizacyjnym.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Detal Kontroli</h3>
<p class="text-body text-gosign-text-light mt-2">Opis, implementacja, historia dowodów, ostatnia zmiana.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Drill-Down</h3>
<p class="text-body text-gosign-text-light mt-2">Od przeglądu do konkretnego wyniku testu.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Eksport</h3>
<p class="text-body text-gosign-text-light mt-2">Pakiety dowodów w JSON lub PDF.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Historia Zmian i Overrides</h3>
<p class="text-body text-gosign-text-light mt-2">Kto, kiedy, dlaczego.</p>
</div>
</div>
</div>
</section>

<!-- Framework Mapping -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Mapowanie Frameworków</h2>
<p class="text-body-lg font-semibold text-gosign-dark mt-4">Struktura kontroli jest agnostyczna wobec frameworków. Każda kontrola może być mapowana na wiele frameworków.</p>
<ul class="mt-4 space-y-2 text-body-lg text-gosign-text-light">
<li><a href="https://www.iso.org/isoiec-27001-information-security.html" target="_blank" rel="noopener noreferrer">ISO 27001</a>: Kontrole mapowane na miary Załącznika A. Dowody generowane automatycznie.</li>
<li>SOC2: Trust Service Criteria (CC6, CC7, CC8) jako kategorie kontroli.</li>
<li>PS 951 / ISAE 3402: Standardy audytu dla dostawców usług IT. Kontrole i dowody przygotowane dla audytorów.</li>
<li>EU AI Act: Artykuły 9, 12, 13, 14 zaimplementowane jako kontrole w systemie.</li>
<li>IDW PS 880: Standardy audytu oprogramowania.</li>
<li>Mapowanie się zmienia. Struktura kontroli pozostaje identyczna. Gdy nowy framework staje się istotny, jest mapowany - kontrole już istnieją.</li>
</ul>
</div>
</div>
</section>

<!-- Czym nie jest -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Czym Cert-Ready by Design Nie Jest</h2>
<div class="mt-6 space-y-4">
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Nie jest obietnicą certyfikacji.</strong> Architektura jest strukturalnie przygotowana do audytu i certyfikacji.</p>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Nie jest narzędziem GRC.</strong> Uzupełnia istniejące platformy GRC.</p>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Nie jest jednorazowym audytem.</strong> Jest ciągły. System jest zawsze w trybie audytu.</p>
</div>
<p class="text-body-lg text-gosign-text-light mt-6">
Gdy certyfikacja jest wymagana, nasz system jest strukturalnie przygotowany. To deklaracja architektoniczna, nie obietnica certyfikacji.
</p>
</div>
</section>

<!-- Pogłębienie -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Pogłębienie w Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nasza seria artykułów fachowych dla decydentów wdrażających agentów AI.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/pl/magazyn/cert-ready-by-design/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Cert-Ready by Design - AI gotowe do audytu od startu</p>
</a>
<a href="/pl/magazyn/eu-ai-act-hr/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">EU AI Act i HR - co jest teraz obowiązkowe</p>
</a>
<a href="/pl/magazyn/ai-governance-dashboard/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">AI Governance Dashboard: monitoring agentów w firmie</p>
</a>
</div>
</div>
</section>

--- Konsultacja i Rada Pracowników ---
> AI Agents zgodne z radą pracowników. Human-in-the-Loop, porozumienia zakładowe jako ograniczenia systemowe, Audit Trail i role jako zasady architektoniczne.

<!-- Dlaczego to temat architektury -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Dlaczego Konsultacja z Radą To Temat Architektury</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
AI Agents wdrożone w procesach HR, decyzjach kadrowych lub przepływach dotyczących pracowników podlegają prawom informacyjnym i konsultacyjnym rady pracowników w Polsce. Ustawa o radach pracowników z 2006 r. gwarantuje prawo do informacji i konsultacji w kwestiach dotyczących zatrudnienia, organizacji pracy i zmian technologicznych. To nie opcjonalna warstwa - to wymóg prawny.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Gosign traktuje obowiązek konsultacji jako zasadę architektoniczną. Decision Layer technicznie wymusza zgodność z porozumieniami zakładowymi. Audit Trail dokumentuje każdą decyzję.
</p>
</div>
</section>

<!-- Ramy Prawne -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Ramy Prawne</h2>
<div class="mt-6 space-y-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Ustawa o radach pracowników - Prawo do informacji i konsultacji</h3>
<p class="text-body text-gosign-text-light mt-2">
Rada pracowników ma prawo do informacji i konsultacji w sprawach dotyczących &bdquo;działań, które mogą powodować istotne zmiany w organizacji pracy lub podstawach zatrudnienia&rdquo;. Wdrożenie AI Agents automatyzujących procesy HR objęte jest tym prawem. W polskim systemie rada ma prawo do konsultacji - pracodawca musi zasięgnąć opinii rady, choć ostateczna decyzja pozostaje po stronie pracodawcy.
</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Kodeks pracy - Planowanie zmian technologicznych</h3>
<p class="text-body text-gosign-text-light mt-2">
Rada pracowników musi być informowana i konsultowana na etapie planowania wdrożenia nowych systemów technicznych. Dotyczy to fazy projektowania AI Agents, nie tylko momentu uruchomienia. Dodatkowo Dyrektywa 2002/14/WE, implementowana w polskim prawie, wzmacnia te prawa do informacji i konsultacji.
</p>
</div>
</div>
</div>
</section>

<!-- Implementacja Architektoniczna -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Implementacja Architektoniczna</h2>
</div>
<div class="mt-8 grid grid-cols-1 sm:grid-cols-3 gap-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Porozumienia Zakładowe jako Ograniczenia</h3>
<p class="text-body text-gosign-text-light mt-2">Mapowane jako jawne ograniczenia w Decision Layer. Każde ograniczenie ma ID wersji, datę ważności i zakres. Jeśli porozumienie byłoby naruszone, decyzja nie jest wykonywana autonomicznie.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Human-in-the-Loop</h3>
<p class="text-body text-gosign-text-light mt-2">Decyzja autonomiczna gdy: wysoka pewność I niskie ryzyko I brak naruszenia ograniczenia. Human-in-the-Loop gdy: ryzyko stronniczości, potencjał dyskryminacji, tematy wymagające konsultacji z radą. Routing wymuszony architektonicznie.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Audit Trail dla Rady Pracowników</h3>
<p class="text-body text-gosign-text-light mt-2">Każda decyzja z: znacznikiem czasu, agentem, wejściem, zastosowanymi regułami, oceną pewności, ścieżką decyzji, wynikiem i statusem. Niezmienny, eksportowalny.</p>
</div>
</div>
</div>
</section>

<!-- Audit Trail Example -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Przykład wpisu Audit Trail</h2>
</div>
<div class="mt-8">
<pre class="bg-gosign-dark text-white p-6 rounded-card overflow-x-auto text-small font-mono leading-relaxed"><code>Wpis Audit Trail:
&#x251C;&#x2500;&#x2500; Znacznik czasu:     2026-02-20T09:14:22Z
&#x251C;&#x2500;&#x2500; Agent:              hr-merit-cycle-agent
&#x251C;&#x2500;&#x2500; Wejście:            Korekta wynagrodzenia pracownik #4711
&#x251C;&#x2500;&#x2500; Zastosowane reguły:
&#x2502;   &#x251C;&#x2500;&#x2500; Układ zbiorowy:  ZUZP, Wersja 2025.2
&#x2502;   &#x251C;&#x2500;&#x2500; Porozumienie:    PZ-2024-003, pkt 4.2
&#x2502;   &#x2514;&#x2500;&#x2500; Widełki:         Pasmo E3, 52.000-68.000 PLN
&#x251C;&#x2500;&#x2500; Ocena:
&#x2502;   &#x251C;&#x2500;&#x2500; Pewność:        0.94
&#x2502;   &#x251C;&#x2500;&#x2500; Ryzyko:         niskie
&#x2502;   &#x2514;&#x2500;&#x2500; Wynik:          W paśmie, w ramach ograniczenia
&#x251C;&#x2500;&#x2500; Ścieżka decyzji:   autonomiczna
&#x251C;&#x2500;&#x2500; Wyjście:            Propozycja: korekta +3,2%
&#x2514;&#x2500;&#x2500; Status:             zatwierdzony</code></pre>
</div>
</div>
</section>

<!-- RBAC -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">RBAC</h2>
<div class="mt-6 space-y-4">
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Operator Agenta:</strong> Konfiguracja, zmiany reguł (wersjonowane)</p>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Specjalista HR:</strong> Widok decyzji w swoim obszarze</p>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Rada Pracowników:</strong> Wzorce decyzji, status ograniczeń, Audit Trail</p>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Audytor:</strong> Pełny dostęp do Audit Trail, dowodów, kontroli</p>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Admin:</strong> Konfiguracja systemu, bez dostępu do danych decyzji</p>
</div>
<p class="text-body-lg text-gosign-text-light mt-4">
RBAC wymuszony na poziomie bazy danych via Row-Level Security.
</p>
</div>
</section>

<!-- Czego Nie Robimy -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Czego Nie Robimy</h2>
<p class="text-body-lg font-semibold text-gosign-dark mt-4">Konsultacja z radą pracowników to zasada projektowa, nie przeszkoda.</p>
<ul class="mt-4 space-y-2 text-body-lg text-gosign-text-light">
<li>Nie zastępujemy porozumień zakładowych. Mapujemy je technicznie.</li>
<li>Nie świadczymy doradztwa prawnego. Dostarczamy infrastrukturę techniczną.</li>
<li>Nie automatyzujemy decyzji wymagających konsultacji z radą pracowników bez Human-in-the-Loop.</li>
</ul>
</div>
</div>
</section>

<!-- Pogłębienie -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Pogłębienie w Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nasza seria artykułów fachowych dla decydentów wdrażających agentów AI.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/pl/magazyn/rada-zakladowa-ai-mitbestimmung/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Rada Zakładowa a AI, Konsultacja jako Constraint Architektury</p>
</a>
<a href="/pl/magazyn/agent-governance-hr/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Agent Governance w HR - Dlaczego CHRO musi prowadzić ten temat</p>
</a>
<a href="/pl/magazyn/human-in-the-loop-architektura/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Human-in-the-Loop - zasada architektury, nie checkbox</p>
</a>
</div>
</div>
</section>

--- Rezydencja Danych i RODO ---
> Suwerenność danych dla korporacyjnych AI Agents. Przetwarzanie w UE, Row-Level Security, izolacja tenantów, brak przepływów danych do trzecich.

<!-- Zasada Fundamentalna -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Zasada Fundamentalna</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
AI Agents przetwarzają krytyczne dane biznesowe. Kwestia gdzie te dane są przetwarzane i kto ma dostęp nie podlega negocjacjom. <a href="/pl/governance/reference-architecture/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Decision Layer</a> rozkłada każdy proces na kroki decyzyjne i definiuje dla każdego kroku, czy decyduje człowiek, zestaw reguł czy AI - w tym kwestię, jakie dane mogą być przetwarzane.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Architektura Gosign opiera się na: wszystkie dane pozostają w infrastrukturze klienta. Gosign nie operuje własną chmurą, nie przechowuje danych klientów i nie ma stałego dostępu do systemów produkcyjnych. Kompletna <a href="/pl/governance/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">architektura Governance</a> zapewnia, że każde przetwarzanie danych jest dokumentowane i możliwe do prześledzenia.
</p>
</div>
</div>
</section>

<!-- Opcje Wdrożenia -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">Opcje Wdrożenia</h2>
<div class="grid grid-cols-1 md:grid-cols-2 gap-6 lg:gap-8">
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 15a4.5 4.5 0 0 0 4.5 4.5H18a3.75 3.75 0 0 0 .75-7.425A4.502 4.502 0 0 0 14.25 7.5a5.25 5.25 0 0 0-10.233 2.033A4.5 4.5 0 0 0 2.25 15Z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Azure (UE)</h3>
<p class="text-body text-gosign-text-light mt-3">
Regiony <a href="https://azure.microsoft.com/en-us/explore/global-infrastructure/geographies/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Azure</a>: West Europe (Amsterdam), North Europe (Dublin), Germany West Central (Frankfurt). Azure OpenAI do przetwarzania LLM. DPA Microsoftu.
</p>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">GCP (UE)</h3>
<p class="text-body text-gosign-text-light mt-3">
Regiony <a href="https://cloud.google.com/about/locations" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">GCP</a>: europe-west1 (Belgia), europe-west3 (Frankfurt), europe-west4 (Holandia). Vertex AI do przetwarzania LLM. DPA Google.
</p>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M5.25 14.25h13.5m-13.5 0a3 3 0 0 1-3-3m3 3a3 3 0 1 0 0 6h13.5a3 3 0 1 0 0-6m-16.5-3a3 3 0 0 1 3-3h13.5a3 3 0 0 1 3 3m-19.5 0a4.5 4.5 0 0 1 .9-2.7L5.737 5.1a3.375 3.375 0 0 1 2.7-1.35h7.126c1.062 0 2.062.5 2.7 1.35l2.587 3.45a4.5 4.5 0 0 1 .9 2.7m0 0a3 3 0 0 1-3 3m0 3h.008v.008h-.008v-.008Zm0-6h.008v.008h-.008v-.008Zm-3 6h.008v.008h-.008v-.008Zm0-6h.008v.008h-.008v-.008Z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">AWS (UE)</h3>
<p class="text-body text-gosign-text-light mt-3">
Regiony <a href="https://aws.amazon.com/about-aws/global-infrastructure/regions_az/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">AWS</a>: eu-central-1 (Frankfurt), eu-west-1 (Irlandia), eu-west-3 (Paryż). Amazon Bedrock do hostingu LLM (Claude, Llama, Mistral). Amazon EKS do orkiestracji kontenerów, Aurora PostgreSQL. DPA AWS.
</p>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 17.25v1.007a3 3 0 0 1-.879 2.122L7.5 21h9l-.621-.621A3 3 0 0 1 15 18.257V17.25m6-12V15a2.25 2.25 0 0 1-2.25 2.25H5.25A2.25 2.25 0 0 1 3 15V5.25A2.25 2.25 0 0 1 5.25 3h13.5A2.25 2.25 0 0 1 21 5.25Z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Self-Hosted</h3>
<p class="text-body text-gosign-text-light mt-3">
Własne centrum danych lub serwery. Modele open-source: <a href="https://llama.meta.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Llama</a>, <a href="https://mistral.ai/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Mistral</a>, <a href="https://www.deepseek.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">DeepSeek</a> - lokalnie obsługiwane. Żadne dane nie opuszczają sieci korporacyjnej. Pełna kontrola.
</p>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M7.5 21 3 16.5m0 0L7.5 12M3 16.5h13.5m0-13.5L21 7.5m0 0L16.5 12M21 7.5H7.5" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Hybryda</h3>
<p class="text-body text-gosign-text-light mt-3">
Kombinacja chmury i self-hosted. Różne opcje na agenta według klasyfikacji danych.
</p>
</article>
</div>
</div>
</section>

<!-- Środki Techniczne -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Środki Techniczne</h2>
<div class="mt-8 space-y-6">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Row-Level Security (RLS)</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Izolacja na poziomie bazy danych. Zapytanie SQL może fizycznie uzyskać dostęp tylko do autoryzowanych rekordów. Nie może być obejście logiką aplikacji.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Szyfrowanie</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
W spoczynku: AES-256. W tranzycie: TLS 1.3. Zarządzanie kluczami: Bring Your Own Key lub zarządzane przez platformę.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Kontrola Dostępu</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
RBAC na wszystkich poziomach. Bez współdzielonych poświadczeń. Dostępy rejestrowane w Audit Trail. Gosign bez stałego dostępu do danych produkcyjnych.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Usuwanie Danych</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Koncepcja usuwania według RODO Art. 17. Konfigurowalne okresy retencji. Usuwanie obejmuje wszystkie kopie. Protokoły udokumentowane.
</p>
</div>
</div>
</div>
</section>

<!-- Ochrona Danych LLM -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Ochrona Danych Specyficzna dla LLM</h2>
<div class="mt-8 space-y-6">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">LLM w Chmurze</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Dane wysyłane do usługi LLM. Azure OpenAI i Vertex AI nie używają danych do trenowania modeli. DPA/SCCs z dostawcą. Minimalizacja danych. <a href="/pl/magazyn/pii-anonimizacja-llm-enterprise/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Anonimizacja PII</a> zapewnia, że dane osobowe są usuwane przed przetwarzaniem przez LLM.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Modele Self-Hosted</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Żadne dane nie opuszczają infrastruktury klienta. Model działa lokalnie. Kompromis: mniejsza zdolność niż modele własnościowe. Więcej o strategiach hostingu w artykule <a href="/pl/magazyn/hosting-ai-strategie-enterprise/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Hosting AI: EU SaaS, europejskie centrum danych czy Self-Hosted?</a>
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Bez Trenowania na Danych Klienta</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
AI Agents Gosign nie są trenowane na danych klienta. Bez fine-tuningu, bez re-trenowania. Agenty używają LLM z promptami i regułami - modele nie są modyfikowane.
</p>
</div>
</div>
</div>
</section>

<!-- Mapowanie RODO -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Mapowanie RODO</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Każdy komponent architektoniczny jest przypisany do konkretnego artykułu RODO. Szczegóły wdrożenia w kontekście <a href="/pl/governance/eu-ai-act/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">EU AI Act</a>.
</p>
</div>
<div class="mt-8 overflow-x-auto">
<table class="w-full text-left text-small border-collapse min-w-[36rem]">
<thead>
<tr>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Artykuł</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Środek Architektoniczny</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Art. 5 - Minimalizacja</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Tylko niezbędne dane</td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Art. 6 - Podstawa prawna</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Przetwarzanie na zlecenie (Art. 28) lub uzasadniony interes, w zależności od kontekstu</td>
</tr>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Art. 17 - Usuwanie</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Koncepcja z konfigurowalnymi okresami</td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Art. 25 - Privacy by Design</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">RLS, szyfrowanie, RBAC</td>
</tr>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Art. 28 - Przetwarzanie</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">DPA między klientem a Gosign, DPA z dostawcą chmury</td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Art. 30 - Rejestr</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Audit Trail dokumentuje wszystkie operacje przetwarzania</td>
</tr>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Art. 32 - Bezpieczeństwo</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Szyfrowanie, kontrola dostępu</td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Art. 33/34 - Zgłoszenia</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Proces reagowania na incydenty, Audit Trail do analizy forensycznej</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Rozróżnienie -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Rozróżnienie</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Ta strona opisuje techniczne środki architektoniczne. Ocena prawna i deklaracja zgodności z RODO to odpowiedzialność administratora danych (klienta) i jego inspektorów ochrony danych.
</p>
</div>
</section>

<!-- Pogłębienie -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Pogłębienie w Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nasza seria artykułów fachowych dla decydentów wdrażających agentów AI.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/pl/magazyn/pii-anonimizacja-llm-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Anonimizacja PII dla Enterprise AI</p>
</a>
<a href="/pl/magazyn/bezpieczenstwo-danych-ai-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Bezpieczeństwo danych w AI: Data Residency, RODO i EU AI Act</p>
</a>
<a href="/pl/magazyn/hosting-ai-strategie-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">Hosting AI: EU SaaS, europejskie centrum danych czy Self-Hosted?</p>
</a>
</div>
</div>
</section>

--- EU AI Act Readiness ---
> Jak architektura Gosign adresuje wymagania EU AI Act w zakresie transparentności, nadzoru ludzkiego, rejestracji i zarządzania ryzykiem jako zasady projektowe.

<!-- Intro -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">EU AI Act - Znaczenie dla AI Agents Korporacyjnych</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
<a href="https://eur-lex.europa.eu/eli/reg/2024/1689/oj" target="_blank" rel="noopener noreferrer">EU AI Act (Rozporządzenie (UE) 2024/1689)</a> reguluje systemy AI w Unii Europejskiej. Dla korporacyjnych AI Agents podejmujących zautomatyzowane decyzje cztery obszary są szczególnie istotne.
</p>
</div>
</section>

<!-- EU AI Act Mapping Table -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">Pięć Odpowiedzi Architektonicznych</h2>
<div class="overflow-x-auto -mx-4 sm:mx-0">
<table class="w-full text-left text-small border-collapse min-w-[48rem]">
<thead>
<tr>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Wymóg</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Artykuł</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Implementacja Gosign</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Transparentność</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Art. 13</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Decision Layer dokumentuje kompletnie każdą ścieżkę decyzji: wejście, model i wersja, ocena ekspercka, wynik pewności, zastosowana reguła, decyzja wynikowa. Audit Trail udostępnia te informacje.</td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Nadzór Ludzki</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Art. 14</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Human-in-the-Loop to routing wymuszony architektonicznie. Dla ryzyka stronniczości, dyskryminacji, kwestii wymagających konsultacji z radą pracowników lub niskiej pewności - automatyczne zaangażowanie człowieka. Nie może być obejście.</td>
</tr>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Obowiązki Rejestracji</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Art. 12</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Audit Trail rejestruje: znacznik czasu, hash wejścia, wersję modelu, wersję reguły, pewność, ścieżkę decyzji, wynik i osobę odpowiedzialną. Niezmienny, eksportowalny, kompletny.</td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Zarządzanie Ryzykiem</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Art. 9</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Monitoring stronniczości, śledzenie pewności, wykrywanie anomalii, kontrole Cert-Ready z automatycznym generowaniem dowodów.</td>
</tr>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Prawo do Wyjaśnienia Pojedynczej Decyzji</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Art. 86</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="/pl/magazyn/akt-decyzyjny-podwazalne-decyzje-ai/">Akt decyzyjny</a> na każdą mikrodecyzję: input, reguła fachowa z wersją i źródłem, pewność, wersja modelu, wynik, adnotacja Human-in-the-Loop i ścieżka podważenia. Osoba, której dotyczy decyzja, otrzymuje wyjaśnienie pojedynczego przypadku - nie opis systemu.</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Jak architektura wymusza compliance -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 space-y-12">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Jak architektura wymusza compliance</h2>
</div>
<div class="max-w-narrow">
<div class="flex items-start gap-4">
<span class="text-h1 font-bold text-gosign-accent-text leading-none">1</span>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Decision Layer: Transparentność i Wyjaśnialność</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Decision Layer dokumentuje każdą ścieżkę decyzji kompletnie. Dla każdej decyzji agenta: dane wejściowe, model i wersja, confidence score, logika oceny, wynik i odrzucone alternatywy. Ta dokumentacja powstaje automatycznie jako efekt uboczny decyzji, nie jako późniejszy zapis.</p>
</div>
</div>
</div>
<div class="max-w-narrow">
<div class="flex items-start gap-4">
<span class="text-h1 font-bold text-gosign-accent-text leading-none">2</span>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Human-in-the-Loop: Nadzór Ludzki</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Human-in-the-Loop jest wymuszony architektonicznie, nie konfigurowany opcjonalnie. Decision Layer routuje decyzje automatycznie na podstawie confidence score i kategorii ryzyka. Przy decyzjach ryzykownych człowiek musi sprawdzić i zatwierdzić. Agent nie może ominąć tego kroku.</p>
</div>
</div>
</div>
<div class="max-w-narrow">
<div class="flex items-start gap-4">
<span class="text-h1 font-bold text-gosign-accent-text leading-none">3</span>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Governance Layer: Zarządzanie Ryzykiem i Monitoring</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Governance Layer monitoruje ciągle wszystkie aktywności agentów. Monitoring stronniczości (nadzór statystyczny), śledzenie pewności (monitoring wyników w czasie), wykrywanie anomalii (wzorce decyzji odbiegające od historycznych), kontrole Cert-Ready z automatycznym generowaniem dowodów.</p>
</div>
</div>
</div>
<div class="max-w-narrow">
<div class="flex items-start gap-4">
<span class="text-h1 font-bold text-gosign-accent-text leading-none">4</span>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Akt decyzyjny: Podważalność Pojedynczej Decyzji</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Art. 86 daje osobie prawo do wyjaśnienia pojedynczej decyzji - nie opisu systemu. Decision Layer dostarcza je jako <a href="/pl/magazyn/akt-decyzyjny-podwazalne-decyzje-ai/">akt decyzyjny</a>: atomowy, niezmienny dowód każdej mikrodecyzji z inputem, zastosowaną regułą fachową z wersją i źródłem, pewnością, wersją modelu, wynikiem i ścieżką podważenia. Logi i trace dokumentują przebieg techniczny; akt decyzyjny dokumentuje, dlaczego ta jedna decyzja zapadła w ten sposób - dzięki czemu osoba, rada pracowników, biegły rewident i organ nadzoru mogą ją pojedynczo zakwestionować.</p>
</div>
</div>
</div>
</div>
</section>

<!-- Klasyfikacja Ryzyka -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Klasyfikacja Ryzyka</h2>
<div class="mt-6 space-y-4">
<p class="text-body-lg text-gosign-text-light">
<strong class="text-gosign-dark">Potencjalnie Wysokie Ryzyko:</strong> AI Agents przygotowujące lub wpływające na decyzje kadrowe, ocena zdolności kredytowej, dostęp do usług podstawowych.
</p>
<p class="text-body-lg text-gosign-text-light">
<strong class="text-gosign-dark">Nie Wysokie Ryzyko (typowo):</strong> Document Agents klasyfikujące dokumenty bez decyzji kadrowych, Knowledge Agents dostarczające informacje bez podejmowania decyzji.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Architektura jest przygotowana na najostrzejsze wymagania.
</p>
</div>
</div>
</section>

<!-- Compliance Position -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Pozycja Compliance</h2>
<p class="text-body-lg font-semibold text-gosign-dark mt-4">EU AI Act compliant by design.</p>
<ul class="mt-4 space-y-2 text-body-lg text-gosign-text-light">
<li>Nasza architektura adresuje wymagania EU AI Act jako zasady projektowe.</li>
<li>Transparentność, wyjaśnialność i nadzór ludzki są strukturalnie nieuniknione, nie opcjonalnie konfigurowane.</li>
<li>Każda decyzja jest automatycznie dokumentowana, nie rekonstruowana po fakcie.</li>
<li>Prawo do wyjaśnienia pojedynczej decyzji (art. 86) jest spełnialne na każdą mikrodecyzję poprzez <a href="/pl/magazyn/akt-decyzyjny-podwazalne-decyzje-ai/">akt decyzyjny</a> - podważalny dowód, nie tylko log techniczny.</li>
<li>System jest przygotowany na wymagania wysokiego ryzyka, niezależnie od konkretnej klasyfikacji.</li>
<li>Kontrole Cert-Ready zapewniają, że dowody są zawsze dostępne i eksportowalne.</li>
</ul>
</div>
</div>
</section>

<!-- Rozróżnienie -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Rozróżnienie</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Ta strona opisuje środki architektoniczne, nie zgodność prawną. Rzeczywiste spełnienie EU AI Act zależy od kontekstu wdrożenia, klasyfikacji ryzyka i oceny prawnej indywidualnego przypadku.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Gosign dostarcza architekturę techniczną. Ocena prawna i deklaracja zgodności to odpowiedzialność operatora i jego doradców prawnych.
</p>
</div>
</section>

<!-- Pogłębienie -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Pogłębienie w Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nasza seria artykułów fachowych dla decydentów wdrażających agentów AI.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/pl/magazyn/eu-ai-act-hr/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">EU AI Act i HR - co jest teraz obowiązkowe</p>
</a>
<a href="/pl/magazyn/eu-ai-act-hr-wysokie-ryzyko/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">EU AI Act i HR: Co od sierpnia 2026 obowiązuje dla AI w HR</p>
</a>
<a href="/pl/magazyn/cert-ready-by-design/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Cert-Ready by Design - AI gotowe do audytu od startu</p>
</a>
</div>
</div>
</section>

--- Lista kontrolna umowy powierzenia dla infrastruktury AI ---
> Katalog wymagań dla umów powierzenia przetwarzania danych w Enterprise AI. 25 pytań weryfikacyjnych dla działu prawnego, IT i compliance.

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-body-lg text-gosign-text-light">
Umowa powierzenia przetwarzania danych dla infrastruktury AI musi obejmować dziesięć obszarów, których standardowe umowy SaaS nie regulują: polityki logowania promptów, separację środowisk (dev/staging/prod), łańcuchy dostawców modeli, przetwarzanie danych in-flight vs. at-rest, ochronę danych embeddingów RAG, <a href="/pl/governance/data-residency/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">dostęp z krajów trzecich do danych produkcyjnych</a>, zgodność z tajemnicą zawodową, tokenizację PII, ścieżki audytu Decision Layer i weryfikowalność środków technicznych. Ta lista kontrolna przekłada dziesięć luk na 25 konkretnych pytań weryfikacyjnych.
</p>
<p class="text-body text-gosign-text-light mt-4">
Szczegółową analizę dziesięciu luk znajdziesz w artykule: <a href="/pl/magazyn/umowa-powierzenia-ai-lista-kontrolna/" class="text-gosign-accent-text hover:underline">Umowa powierzenia dla agentów AI: Czego brakuje w standardowej umowie</a>.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">A - Kategorie danych i cele przetwarzania</h2>
<div class="space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">1</p>
<p class="text-body-lg text-gosign-text-light mt-1">Czy treści promptów i odpowiedzi modeli są wymienione jako odrębne kategorie danych w umowie?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">2</p>
<p class="text-body-lg text-gosign-text-light mt-1">Czy ustalono, że odpowiedzialność za klasyfikację treści leży po stronie organizacji, a nie dostawcy?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">3</p>
<p class="text-body-lg text-gosign-text-light mt-1">Czy embeddingi/wektory są sklasyfikowane jako potencjalnie dane osobowe?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">4</p>
<p class="text-body-lg text-gosign-text-light mt-1">Czy umowa przewiduje regulację dla szczególnych kategorii danych z art. 9 RODO, które mogą powstać przez wprowadzenia użytkowników?</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">B - Logowanie i monitoring</h2>
<div class="space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">5</p>
<p class="text-body-lg text-gosign-text-light mt-1">Czy logowanie treści żądań/odpowiedzi w środowisku produkcyjnym jest wyłączone?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">6</p>
<p class="text-body-lg text-gosign-text-light mt-1">Jakie metadane są rejestrowane (kody statusu, czasy odpowiedzi, identyfikatory żądań)?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">7</p>
<p class="text-body-lg text-gosign-text-light mt-1">Czy logowanie debugowe w produkcji jest weryfikowalnie wyłączone?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">8</p>
<p class="text-body-lg text-gosign-text-light mt-1">Czy ślady stosu i komunikaty błędów są skonfigurowane tak, aby dane treściowe nie trafiały do logów?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">9</p>
<p class="text-body-lg text-gosign-text-light mt-1">Czy weryfikacja ustawień logowania jest częścią procesu wydawniczego?</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">C - Separacja środowisk i dostęp</h2>
<div class="space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">10</p>
<p class="text-body-lg text-gosign-text-light mt-1">Czy istnieją oddzielne środowiska (dev, staging, prod) z odrębnymi politykami danych?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">11</p>
<p class="text-body-lg text-gosign-text-light mt-1">Czy środowiska dev/staging zawierają wyłącznie dane syntetyczne lub zanonimizowane?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">12</p>
<p class="text-body-lg text-gosign-text-light mt-1">Czy dostęp produkcyjny jest ograniczony do autoryzowanych ról w UE/EOG? (Zobacz też: <a href="/pl/governance/cert-ready/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">wymagania Cert-Ready</a>)</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">13</p>
<p class="text-body-lg text-gosign-text-light mt-1">Czy istnieje udokumentowana procedura wyjątkowa dla przypadków wsparcia z dostępem do danych?</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">D - Dostawcy modeli i podwykonawcy</h2>
<div class="space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">14</p>
<p class="text-body-lg text-gosign-text-light mt-1">Czy rozgraniczenie jest jasne: Którzy dostawcy są podwykonawcami przetwarzania dostawcy, a którzy działają w tenancie organizacji?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">15</p>
<p class="text-body-lg text-gosign-text-light mt-1">Czy przechowywanie treści u dostawców modeli jest wyłączone?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">16</p>
<p class="text-body-lg text-gosign-text-light mt-1">Czy wykluczenie wykorzystania do celów treningowych jest udokumentowane umownie?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">17</p>
<p class="text-body-lg text-gosign-text-light mt-1">Gdzie znajdują się endpointy modeli (region UE, US, inne)?</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">E - Przechowywanie i usuwanie danych</h2>
<div class="space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">18</p>
<p class="text-body-lg text-gosign-text-light mt-1">Czy ustalono, gdzie przechowywane są trwałe dane treściowe (baza danych, region, dostawca)?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">19</p>
<p class="text-body-lg text-gosign-text-light mt-1">Jaka retencja kopii zapasowych obowiązuje i jak traktowane są usunięte dane w kopiach zapasowych?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">20</p>
<p class="text-body-lg text-gosign-text-light mt-1">Czy pojedynczy użytkownik może samodzielnie usunąć swoje dane w aplikacji?</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">F - Branże regulowane</h2>
<div class="space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">21</p>
<p class="text-body-lg text-gosign-text-light mt-1">Czy umowa zawiera regulację zgodności z tajemnicą zawodową (art. 266 Kodeksu karnego lub odpowiednich przepisów branżowych)?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">22</p>
<p class="text-body-lg text-gosign-text-light mt-1">Czy zobowiązania do poufności obejmują wszystkie osoby mające dostęp?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">23</p>
<p class="text-body-lg text-gosign-text-light mt-1">Czy tokenizacja PII jest dostępna jako moduł opcjonalny?</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">G - <a href="/pl/governance/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Governance</a> i weryfikowalność</h2>
<div class="space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">24</p>
<p class="text-body-lg text-gosign-text-light mt-1">Czy ścieżka audytu dla decyzji agentów jest zakotwiczona jako element umowy?</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-h3 font-bold text-gosign-dark">25</p>
<p class="text-body-lg text-gosign-text-light mt-1">Czy środki techniczne i organizacyjne mogą być wykazane na żądanie (dokumentacja konfiguracji, zanonimizowane wyciągi z logów)?</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-body text-gosign-text-light">
Ta lista kontrolna to katalog wymagań z perspektywy architektury i governance. Nie stanowi porady prawnej. Ocena prawna i formalna ocena umowy powierzenia to odpowiedzialność działu prawnego administratora lub zewnętrznych doradców.
</p>
</div>
</section>

--- Architektura referencyjna: 7 warstw dla Enterprise AI ---
> 7-warstwowa architektura dla korporacyjnych AI Agents. Governance by Design, agnostyczna wobec modeli i infrastruktury. Dla CTO i decydentów IT.

<!-- Przegląd -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Dlaczego siedem warstw</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Monolityczny system AI nie jest audytowalny, nie skaluje się i nie jest możliwy do utrzymania. Architektura 7-warstwowa rozdziela odpowiedzialności: każda warstwa ma zdefiniowane zadanie i czyste interfejsy. Zmiana modelu nie wpływa na logikę biznesową. Nowy system docelowy nie zmienia agenta. Nowe wymaganie zgodności z RODO czy EU AI Act nie zmienia infrastruktury.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Architektura wynika z wymagań korporacyjnych: izolacja tenantów, Audit Trail, transparentność dla Rady Zakładowej (prawo do informacji i konsultacji zgodnie z Ustawą o radach pracowników), zgodność z EU AI Act, agnostyczne wobec modeli wdrożenie. Standardowe API LLM nie zapewniają żadnego z tych elementów.
</p>
</div>
<img src="/images/diagrams/reference-architecture.svg" alt="Architektura referencyjna: 7 warstw z Governance jako komponentem przekrojowym - Presentation, Orchestration, Agent, Decision Layer, Model, Integration, Infrastructure" class="w-full rounded-card mt-8" width="1200" height="600" loading="lazy" />
</div>
</section>

<!-- Warstwa 1: Prezentacja -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">1. Presentation Layer</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Interfejs między systemem a użytkownikiem. Bez logiki biznesowej, bez decyzji - tylko wyświetlanie i wprowadzanie danych.
</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light"><strong>Chat UI:</strong> Interfejs webowy dla użytkowników końcowych (kadry, księgowi). Gotowy na PWA, responsywny.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Dashboard:</strong> Przegląd statusu agentów, bieżących workflow, otwartych eskalacji. Oparty na rolach: pracownicy widzą swoje sprawy, menedżerowie widzą wskaźniki.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Portal Audytora:</strong> Dostęp audytora do Audit Trail, kontroli, dowodów. Tylko odczyt. Dla biegłych rewidentów, Rady Zakładowej, rewizji wewnętrznej.</li>
<li class="text-body-lg text-gosign-text-light"><strong>REST API:</strong> Interfejs maszynowy do integracji z istniejącymi systemami. Wersjonowany, udokumentowany, z uwierzytelnianiem.</li>
</ul>
</div>
</div>
</section>

<!-- Warstwa 2: Orkiestracja -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">2. Orchestration Layer</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Koordynuje przepływ danych między agentami, systemami i użytkownikami. Zarządza workflow, kolejkami i routingiem API.
</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light"><strong>Silnik workflow:</strong> Silniki open source (Trigger.dev, Camunda) do złożonych, wieloetapowych procesów. Wizualne workflow, integracja API, webhooki.</li>
<li class="text-body-lg text-gosign-text-light"><strong>API Gateway:</strong> Jednolity punkt wejścia z rate limiting, uwierzytelnianiem, logowaniem, monitoringiem.</li>
<li class="text-body-lg text-gosign-text-light"><strong>System kolejek:</strong> Asynchroniczne przetwarzanie dla operacji wsadowych (zamknięcie miesiąca, masowy import).</li>
<li class="text-body-lg text-gosign-text-light"><strong>System zdarzeń:</strong> Reakcja w czasie rzeczywistym na przychodzące dokumenty, zmiany statusu, eskalacje.</li>
</ul>
</div>
</div>
</section>

<!-- Warstwa 3: Agent -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">3. Agent Layer</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Wyspecjalizowane AI Agents wykonujące zadania fachowe. Każdy agent ma zdefiniowany zakres i działa w granicach wyznaczonych przez Decision Layer.
</p>
<h3 class="text-h3 font-bold text-gosign-dark mt-8"><a href="/pl/uslugi/ai-agents/document-agents/" class="text-gosign-dark hover:text-gosign-accent-text transition-colors">Document Agents</a></h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Czytają, rozumieją i przetwarzają dokumenty z rzeczywistym rozumieniem językowym. Faktury, zwolnienia lekarskie, umowy, zaświadczenia, paragony. Nie rozpoznawanie szablonów, nie sztywne reguły - lecz kontekstowe rozumienie.
</p>
<h3 class="text-h3 font-bold text-gosign-dark mt-8"><a href="/pl/uslugi/ai-agents/workflow-agents/" class="text-gosign-dark hover:text-gosign-accent-text transition-colors">Workflow Agents</a></h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Orkiestrują procesy między systemami. Gdy dokument musi być odczytany, decyzja podjęta i akcja wywołana w systemie docelowym - Workflow Agent koordynuje sekwencję.
</p>
<h3 class="text-h3 font-bold text-gosign-dark mt-8"><a href="/pl/uslugi/ai-agents/knowledge-agents/" class="text-gosign-dark hover:text-gosign-accent-text transition-colors">Knowledge Agents</a></h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Dostarczają kontekstowe odpowiedzi z wiedzy korporacyjnej. Regulaminy, polityki, układy zbiorowe pracy, reguły compliance. Odpowiedź zawiera źródło i wersję reguły.
</p>
</div>
</div>
</section>

<!-- Warstwa 4: Decision Layer -->
<section class="py-section bg-gosign-dark text-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold"><a href="/pl/decision-layer/" class="hover:text-gosign-accent-on-dark transition-colors">4. Decision Layer</a></h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4">
Rozkłada każdy proces biznesowy na pojedyncze kroki decyzyjne i definiuje dla każdego kroku: człowiek, zestaw reguł lub AI. Każda decyzja jest dokumentowana - do audytu przez biegłych rewidentów, Radę Zakładową i rewizję wewnętrzną.
</p>
<div class="mt-6 space-y-4">
<p class="text-body-lg text-gosign-text-on-dark/80"><strong>Rules Engine:</strong> Fachowe zestawy reguł, wersjonowane i identyfikowalne. Układy zbiorowe pracy, porozumienia zakładowe, logika księgowa, reguły compliance. Każda reguła ma wersję, datę obowiązywania i zakres.</p>
<p class="text-body-lg text-gosign-text-on-dark/80"><strong>Confidence Routing:</strong> Automatyczna ocena pewności decyzji. Wysoka pewność i niskie ryzyko: autonomiczna decyzja. Niska pewność lub wysokie ryzyko: eskalacja do człowieka.</p>
<p class="text-body-lg text-gosign-text-on-dark/80"><strong>Human-in-the-Loop:</strong> Architektonicznie wymuszona kontrola człowieka przy zdefiniowanych typach decyzji. Ryzyko uprzedzeń, potencjał dyskryminacji, tematy wymagające konsultacji z Radą Zakładową.</p>
<p class="text-body-lg text-gosign-text-on-dark/80"><strong>Audit Trail - akt decyzyjny:</strong> Kompletna, niezmienna dokumentacja każdej decyzji. Na każdą mikrodecyzję jeden akt decyzyjny: wejście, model, ocena, reguła wraz z wersją, wynik, znacznik czasu i ścieżka podważenia. Append-only - a tym samym architektoniczna odpowiedź na prawo osób, których decyzja dotyczy, do wyjaśnienia pojedynczej decyzji wg art. 86 EU AI Act.</p>
</div>
<p class="text-body text-gosign-text-on-dark/60 mt-4">
Więcej: <a href="/pl/magazyn/decision-layer-wyjasnienie/" class="text-gosign-text-on-dark/80 underline decoration-white/20 hover:text-white transition-colors">Decision Layer w szczegółach</a> · <a href="/pl/magazyn/trzy-rodzaje-decyzji/" class="text-gosign-text-on-dark/80 underline decoration-white/20 hover:text-white transition-colors">Trzy rodzaje decyzji AI</a> · <a href="/pl/magazyn/akt-decyzyjny-podwazalne-decyzje-ai/" class="text-gosign-text-on-dark/80 underline decoration-white/20 hover:text-white transition-colors">Akt decyzyjny</a>
</p>
</div>
</div>
</section>

<!-- Warstwa 5: Model -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">5. Model Layer</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Warstwa LLM. Wymienna, agnostyczna wobec modeli, oddzielona od logiki biznesowej.
</p>
<h3 class="text-h3 font-bold text-gosign-dark mt-6">Cloud LLM</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Claude (Anthropic), ChatGPT (OpenAI), Gemini (Google) - przez regiony UE poszczególnych dostawców chmurowych.</p>
<h3 class="text-h3 font-bold text-gosign-dark mt-6">Open-Source / Open-Weight LLM</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Llama (Meta), Mistral, DeepSeek, <a href="https://openai.com/open-models/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">gpt-oss</a> (OpenAI, Apache 2.0) - w pełni self-hostowalne na własnym hardware. gpt-oss-120B działa na pojedynczym H100, gpt-oss-20B na 16 GB hardware konsumenckim.</p>
<h3 class="text-h3 font-bold text-gosign-dark mt-6">Hybryda</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Cloud LLM dla standardowych zadań, Self-Hosted LLM dla danych wrażliwych. Automatyczny routing według klasyfikacji danych.</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Wybór modelu to kompromis między wydajnością, kosztami, ochroną danych i latencją. Warstwa modelu jest wymienna - zmiana modelu nie wpływa na logikę biznesową powyżej.
</p>
<p class="text-body text-gosign-text-light mt-4">
Konkretne opcje hostingu, wymagania sprzętowe i stos technologiczny: <a href="/pl/uslugi/infrastruktura/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">AI Infrastructure w szczegółach</a>
</p>
</div>
</div>
</section>

<!-- PII Gateway: redakcja przed Model Layer -->
<section id="pii-gateway" class="py-section bg-gosign-dark text-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold">PII Gateway: redakcja danych przed Model Layer</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4">
Między logiką biznesową a Model Layer architektura przewiduje bramkę redakcyjną (PII Gateway): przechodzi przez nią każde wywołanie modelu - zarówno Cloud LLM, jak i Self-Hosted. Cel projektowy: dane osobowe nie opuszczają strefy zaufania operatora w tekście jawnym. Dla zadań objętych tajemnicą zawodową (kancelarie, doradztwo podatkowe, ochrona zdrowia) gateway jest jednym z elementów minimalizacji danych zgodnie z RODO - uzupełnia środki organizacyjne i umowne, ale ich nie zastępuje.
</p>
<div class="mt-6 space-y-4">
<p class="text-body-lg text-gosign-text-on-dark/80"><strong>Redakcja i ponowne wstawienie:</strong> Przed każdym wywołaniem modelu gateway zastępuje nazwiska, identyfikatory i inne dane osobowe symbolami zastępczymi (pseudonimizacja). Model pracuje wyłącznie na zredagowanym tekście. Oryginalne wartości wracają na miejsce dopiero po odpowiedzi - wewnątrz strefy zaufania, nigdy u dostawcy modelu.</p>
<p class="text-body-lg text-gosign-text-on-dark/80"><strong>Audit Trail bez tekstu jawnego:</strong> Każde wywołanie modelu jest protokołowane append-only, z wpisami powiązanymi łańcuchem haszy: wartości hash promptu i surowej odpowiedzi zamiast tekstu jawnego, a także ID modelu, wersja API i wersja zestawu reguł redakcji. Dowód, co i kiedy przeszło przez gateway, pozostaje kompletny - a sam dziennik nie staje się wrażliwym zbiorem danych.</p>
<p class="text-body-lg text-gosign-text-on-dark/80"><strong>Reguły break-glass:</strong> Dostęp wyjątkowy na potrzeby awarii i audytów jest przewidziany w projekcie - nigdy po cichu: zasada czterech oczu, udokumentowane uzasadnienie, ograniczenie czasowe, a każde użycie break-glass trafia w całości do Audit Trail.</p>
<p class="text-body-lg text-gosign-text-on-dark/80"><strong>Zatwierdzanie przy niskiej pewności po stronie użytkownika:</strong> Gdy pewność redakcji dla danego fragmentu jest niska, decyzja trafia do użytkownika w UI - nigdy do personelu Gosign. Eskalacja pozostaje w sferze, w której dane i tak są znane.</p>
</div>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-6">
Tryby API, których nie da się zredagować - na przykład zewnętrzne wywołania embeddingów, których wektorów nie można poddać pseudonimizacji - gateway blokuje dla treści podlegających redakcji, zamiast przepuszczać je po cichu. Tabele mapowań między symbolami zastępczymi a wartościami oryginalnymi są efemeryczne albo szyfrowane per tenant z określonym czasem życia (TTL); klucze dostawców przechowywane są wyłącznie w systemie zarządzania kluczami (KMS).
</p>
<p class="text-body text-gosign-text-on-dark/60 mt-4">
Więcej: <a href="/pl/magazyn/pii-anonimizacja-llm-enterprise/" class="text-gosign-text-on-dark/80 underline decoration-white/20 hover:text-white transition-colors">Anonimizacja PII dla Enterprise AI</a>
</p>
</div>
</div>
</section>

<!-- Warstwa 6: Integracja -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">6. Integration Layer</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Połączenie z istniejącymi systemami korporacyjnymi. Agent nie zastępuje systemów - rozszerza je.
</p>
<div class="mt-6 overflow-x-auto">
<table class="w-full text-left text-small border-collapse">
<thead>
<tr>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Kategoria systemu</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Integracja</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">ERP / Finanse</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">SAP FI/CO, SAP S/4HANA, Comarch, Oracle Financials</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">HR / Payroll</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">SAP SuccessFactors, Workday, Comarch HR</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Collaboration</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">SharePoint, Microsoft Teams (via Microsoft Graph)</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">DMS / ECM</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">SharePoint, d.velop, ELO, nscale</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Pozostałe</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Każdy system z interfejsem REST lub SOAP</td></tr>
</tbody>
</table>
</div>
<p class="text-body-lg text-gosign-text-light mt-4">
Logika agenta jest oddzielona od systemu docelowego. Logika księgowa jest oddzielona od eksportu. Gdy system docelowy się zmienia (np. z Comarch na SAP), zmienia się warstwa eksportu - nie agent.
</p>
</div>
</div>
</section>

<!-- Warstwa 7: Infrastruktura -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">7. Infrastructure Layer</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Fundament wdrożeniowy. Cała architektura działa w infrastrukturze klienta - nie u Gosign, nie u zewnętrznego dostawcy.
</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light"><strong>Cloud (UE):</strong> Azure, AWS lub GCP - wyłącznie regiony UE. Managed Kubernetes, Managed Databases, LLM Hosting.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Managed EU:</strong> Vercel EU + Supabase EU. Lekka opcja UE bez własnej infrastruktury Kubernetes.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Self-Hosted:</strong> Własne serwery, własne centrum danych. Docker/Kubernetes, open-source LLM na własnych GPU. Pełna niezależność od Cloud Act.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Hybryda:</strong> Kombinacja według klasyfikacji danych. Wrażliwe obciążenia self-hosted, standardowe obciążenia w chmurze.</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-4">
Wszystkie warstwy powyżej infrastruktury pozostają identyczne - niezależnie od modelu wdrożenia.
</p>
<p class="text-body text-gosign-text-light mt-4">
Regiony chmurowe, wymiarowanie hardware, stos technologiczny: <a href="/pl/uslugi/infrastruktura/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">AI Infrastructure w szczegółach</a>
</p>
</div>
</div>
</section>

<!-- Governance jako warstwa przekrojowa -->
<section class="py-section bg-gosign-dark text-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold">Governance jako warstwa przekrojowa</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4">
Governance nie jest pojedynczą warstwą, lecz przenika całą architekturę. Każda warstwa generuje dane governance, każda warstwa jest kontrolowana przez reguły governance.
</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-on-dark/80"><strong>Presentation:</strong> Dostęp oparty na rolach, Portal Audytora</li>
<li class="text-body-lg text-gosign-text-on-dark/80"><strong>Orchestration:</strong> Logowanie workflow, dokumentacja eskalacji</li>
<li class="text-body-lg text-gosign-text-on-dark/80"><strong>Agent:</strong> Decyzje agentów generują wpisy Audit Trail</li>
<li class="text-body-lg text-gosign-text-on-dark/80"><strong>Decision Layer:</strong> Rules Engine, Confidence Routing, Human-in-the-Loop</li>
<li class="text-body-lg text-gosign-text-on-dark/80"><strong>Model:</strong> Śledzenie wersji modelu, haszowanie danych wejściowych, odtwarzalność, redakcja PII i zapis bez tekstu jawnego (PII Gateway)</li>
<li class="text-body-lg text-gosign-text-on-dark/80"><strong>Integration:</strong> Logowanie interfejsów, dokumentacja przepływu danych</li>
<li class="text-body-lg text-gosign-text-on-dark/80"><strong>Infrastructure:</strong> Szyfrowanie, Row-Level Security, izolacja tenantów</li>
</ul>
<p class="text-body text-gosign-text-on-dark/60 mt-6">
<a href="/pl/governance/eu-ai-act/" class="text-gosign-text-on-dark/80 underline decoration-white/20 hover:text-white transition-colors">EU AI Act</a> · <a href="/pl/governance/cert-ready/" class="text-gosign-text-on-dark/80 underline decoration-white/20 hover:text-white transition-colors">Cert-Ready by Design</a> · <a href="/pl/governance/co-determination/" class="text-gosign-text-on-dark/80 underline decoration-white/20 hover:text-white transition-colors">Współzarządzanie</a> · <a href="/pl/governance/data-residency/" class="text-gosign-text-on-dark/80 underline decoration-white/20 hover:text-white transition-colors">Data Residency</a>
</p>
</div>
</div>
</section>

<!-- Runtime i skalowanie -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Runtime i skalowanie</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Eksploatacja produkcyjna nie jest dodatkową pracą, lecz częścią architektury. Architektura 7-warstwowa jest zaprojektowana do pracy pod obciążeniem.
</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light"><strong>Orkiestracja kontenerów:</strong> Wdrożenie oparte na Kubernetes. Każda warstwa działa we własnych kontenerach, niezależnie skalowalna.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Skalowanie horyzontalne:</strong> Agent Layer i Model Layer skalują się horyzontalnie według obciążenia. Nowy agent to więcej podów, nie więcej architektury.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Health Checks i Self-Healing:</strong> Liveness i Readiness Probes na wszystkich kontenerach. Automatyczny restart przy awarii, automatyczne przekierowanie przy przeciążeniu.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Monitoring i alerting:</strong> Metryki Prometheus na wszystkich warstwach. Dashboardy Grafana dla latencji, throughput, error rates, queue depth. Alerty przy przekroczeniu progów.</li>
<li class="text-body-lg text-gosign-text-light"><strong>CI/CD:</strong> Wdrożenia oparte na GitOps. Infrastructure as Code (Terraform/Pulumi). Automatyczne testy, wdrożenia Blue-Green lub Canary.</li>
</ul>
</div>
</div>
</section>

<!-- Architektura danych -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Architektura danych</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Dane przepływają przez wszystkie siedem warstw. Architektura definiuje, gdzie dane powstają, jak są przechowywane i kto ma dostęp.
</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light"><strong>Przepływ danych:</strong> Input (dokument, zapytanie) &rarr; Agent (analiza) &rarr; Decision Layer (decyzja) &rarr; Integration (eksport do systemu docelowego). Każdy krok generuje wpis Audit Trail.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Vector Store:</strong> PostgreSQL z pgvector do wyszukiwania semantycznego (RAG). Wiedza korporacyjna przechowywana jako embeddingi, nie przesyłana do zewnętrznych usług.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Izolacja tenantów:</strong> Row-Level Security (RLS) na poziomie bazy danych. Wymuszona architektonicznie, nie na poziomie logiki aplikacji. Każdy tenant jest w pełni izolowany.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Szyfrowanie:</strong> At rest (AES-256) i in transit (TLS 1.3). Zarządzanie kluczami przez dostawcę tożsamości klienta lub Hardware Security Modules (HSM).</li>
<li class="text-body-lg text-gosign-text-light"><strong>Retencja danych:</strong> Konfigurowana według wymagań. Zgodność z RODO Art. 17 (prawo do usunięcia) realizowana poprzez anonimizację zamiast usuwania.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Backup i recovery:</strong> Automatyczne kopie zapasowe, Point-in-Time Recovery. Recovery Point Objective (RPO) i Recovery Time Objective (RTO) konfigurowane per tenant.</li>
</ul>
</div>
</div>
</section>

<!-- Architektura interfejsów -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Architektura interfejsów</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Architektura komunikuje się poprzez zdefiniowane interfejsy - wewnętrznie między warstwami i zewnętrznie z systemami źródłowymi i docelowymi.
</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light"><strong>REST API:</strong> Wersjonowane API (v1, v2) z dokumentacją OpenAPI. Breaking changes tylko w nowych wersjach, stare wersje utrzymywane równolegle.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Event-Driven:</strong> Przetwarzanie zdarzeń oparte na webhookach dla reakcji w czasie rzeczywistym. Przychodzący dokument &rarr; zdarzenie &rarr; agent przetwarza. Bez pollingu, bez opóźnienia batch.</li>
<li class="text-body-lg text-gosign-text-light"><strong>MCP (Model Context Protocol):</strong> Standaryzowany protokół do integracji narzędzi w agentach LLM. Agenci korzystają z zewnętrznych narzędzi przez MCP - typizowane, udokumentowane, audytowalne.</li>
<li class="text-body-lg text-gosign-text-light"><strong>Przetwarzanie wsadowe:</strong> Dla operacji masowych (zamknięcie miesiąca, rozliczenie roczne, masowy import). Oparte na kolejkach ze śledzeniem postępu i obsługą błędów.</li>
<li class="text-body-lg text-gosign-text-light"><strong>API Gateway:</strong> Centralny punkt wejścia. Uwierzytelnianie (SSO/OIDC), rate limiting, logowanie żądań, monitoring. Oddziela wewnętrzną architekturę od zewnętrznych konsumentów.</li>
</ul>
</div>
</div>
</section>

<!-- Zasady projektowe -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Zasady projektowe</h2>
<div class="mt-6 space-y-4">
<p class="text-body-lg text-gosign-text-light"><strong>Agnostyczna wobec modeli:</strong> Brak vendor lock-in na pojedynczego LLM. Modele są wymienne. Dziś Claude, jutro gpt-oss, pojutrze model, który dziś jeszcze nie istnieje.</p>
<p class="text-body-lg text-gosign-text-light"><strong>Agnostyczna wobec infrastruktury:</strong> Ta sama architektura na Azure, AWS, GCP, Self-Hosted lub Hybryda. Wybór infrastruktury jest decyzją klienta, nie architektury.</p>
<p class="text-body-lg text-gosign-text-light"><strong>Agnostyczna wobec systemów:</strong> Logika agenta jest oddzielona od systemu docelowego. Logika księgowa oddzielona od eksportu. Zmiana systemu zmienia Integration Layer, nie agenta.</p>
<p class="text-body-lg text-gosign-text-light"><strong>Governance by Design:</strong> Audit Trail, RBAC, Decision Layer i Human-in-the-Loop to komponenty architektoniczne - nie opcjonalne funkcje dodawane później.</p>
<p class="text-body-lg text-gosign-text-light"><strong>Cert-Ready by Design:</strong> Kontrole jako obiekty danych pierwszej klasy z automatycznym generowaniem dowodów. ISO 27001, PS 951, SOC 2 - architektura dostarcza dowody.</p>
<p class="text-body-lg text-gosign-text-light"><strong>Dostęp do kodu:</strong> Pełny dostęp do kodu źródłowego, wszystkich promptów i zestawów reguł. Konfiguracje i zestawy reguł pozostają u klienta. Stos open source tam, gdzie to możliwe. Po 12-18 miesiącach klient operuje agentami samodzielnie.</p>
</div>
</div>
</div>
</section>

<!-- Decision Layer - przepływ decyzji -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-6">Decision Layer - przepływ decyzji</h2>
<figure role="img" aria-label="Przepływ decyzji: Input jest analizowany przez AI Agent, Decision Layer sprawdza reguły i pewność, kieruje do decyzji autonomicznej lub Human-in-the-Loop, dokumentuje wszystko w Audit Trail i eksportuje do systemu docelowego.">
<pre class="bg-gosign-dark text-white p-6 rounded-card overflow-x-auto text-small font-mono leading-relaxed"><code>&#x250C;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2510;    &#x250C;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2510;    &#x250C;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2510;
&#x2502;  Input   &#x2502;&#x2500;&#x2500;&#x2500;&gt;&#x2502;  AI Agent    &#x2502;&#x2500;&#x2500;&#x2500;&gt;&#x2502; Decision Layer &#x2502;
&#x2502;(dokument,&#x2502;    &#x2502;  analizuje,  &#x2502;    &#x2502;                &#x2502;
&#x2502; zapytanie)&#x2502;    &#x2502;  rozumie,    &#x2502;    &#x2502;  Sprawdź        &#x2502;
&#x2514;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2518;    &#x2502;  ocenia      &#x2502;    &#x2502;  reguły         &#x2502;
&#x2514;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2518;    &#x2502;                &#x2502;
&#x2502;  Oceń           &#x2502;
&#x2502;  pewność        &#x2502;
&#x2502;                &#x2502;
&#x2502;  Routing        &#x2502;
&#x2502;  zdecyduj       &#x2502;
&#x2514;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x252C;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2518;
&#x2502;
&#x250C;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2534;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2510;
&#x2502;                            &#x2502;
&#x250C;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2534;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2510;        &#x250C;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2534;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2510;
&#x2502; Autonomicznie   &#x2502;        &#x2502; Human-in-the-Loop   &#x2502;
&#x2502;                 &#x2502;        &#x2502;                     &#x2502;
&#x2502; Wysoka pewność  &#x2502;        &#x2502; Ryzyko uprzedzeń    &#x2502;
&#x2502; Niskie ryzyko   &#x2502;        &#x2502; Niska pewność       &#x2502;
&#x2502; Brak            &#x2502;        &#x2502; Ograniczenie        &#x2502;
&#x2502; ograniczeń      &#x2502;        &#x2502; Konsultacja RZ      &#x2502;
&#x2514;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x252C;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2518;        &#x2514;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x252C;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2518;
&#x2502;                            &#x2502;
&#x2502;         &#x250C;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2510;   &#x2502;
&#x2502;         &#x2502;  Człowiek    &#x2502;   &#x2502;
&#x2502;         &#x2502;  decyduje    &#x2502;&#x25C4;&#x2500;&#x2500;&#x2518;
&#x2502;         &#x2514;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x252C;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2518;
&#x2502;                &#x2502;
&#x250C;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2534;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2534;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2510;
&#x2502;         Audit Trail              &#x2502;
&#x2502;  Input &#xB7; Model &#xB7; Reguła &#xB7;        &#x2502;
&#x2502;  Ocena &#xB7; Wynik &#xB7;                 &#x2502;
&#x2502;  Znacznik czasu                  &#x2502;
&#x2514;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2518;
&#x2502;
&#x250C;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2534;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2510;
&#x2502;  System docelowy&#x2502;
&#x2502;  (ERP, HR,      &#x2502;
&#x2502;   Payroll)      &#x2502;
&#x2514;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2500;&#x2518;</code></pre>
<figcaption class="text-small text-gosign-text-light mt-3">Schematyczny przepływ decyzji przez Decision Layer. W środowisku produkcyjnym każdy krok jest dokumentowany jako wpis Audit Trail.</figcaption>
</figure>
</div>
</section>

<!-- Pogłębienie -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Pogłębienie</h2>
<div class="mt-6 grid gap-6 sm:grid-cols-2">
<div class="border-l-4 border-gosign-dark pl-6 py-4">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Implementacja</p>
<h3 class="text-h3 font-bold text-gosign-dark">AI Infrastructure</h3>
<p class="text-body text-gosign-text-light mt-2">Konkretne technologie, regiony chmurowe, wymiarowanie hardware, tabela stosu technologicznego.</p>
<a href="/pl/uslugi/infrastruktura/" class="text-small font-semibold text-gosign-accent-text hover:text-gosign-accent-hover mt-3 inline-block whitespace-nowrap">Infrastruktura w szczegółach &rarr;</a>
</div>
<div class="border-l-4 border-gosign-dark pl-6 py-4">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Wiedza</p>
<h3 class="text-h3 font-bold text-gosign-dark">Blueprint 2026</h3>
<p class="text-body text-gosign-text-light mt-2">Jedenaście artykułów o decyzjach infrastrukturalnych, które mają znaczenie w 2026.</p>
<a href="/pl/magazyn/infrastruktura-ai-blueprint-2026/" class="text-small font-semibold text-gosign-accent-text hover:text-gosign-accent-hover mt-3 inline-block whitespace-nowrap">Do serii artykułów &rarr;</a>
</div>
<div class="border-l-4 border-gosign-dark pl-6 py-4">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Agenci</p>
<h3 class="text-h3 font-bold text-gosign-dark">AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Document Agents, Workflow Agents, Knowledge Agents - trzy typy agentów dla procesów enterprise.</p>
<a href="/pl/uslugi/ai-agents/" class="text-small font-semibold text-gosign-accent-text hover:text-gosign-accent-hover mt-3 inline-block whitespace-nowrap">Do AI Agents &rarr;</a>
</div>
<div class="border-l-4 border-gosign-dark pl-6 py-4">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<h3 class="text-h3 font-bold text-gosign-dark">Framework Governance</h3>
<p class="text-body text-gosign-text-light mt-2">EU AI Act, Cert-Ready, Współzarządzanie, Data Residency - wszystkie tematy governance w jednym miejscu.</p>
<a href="/pl/governance/" class="text-small font-semibold text-gosign-accent-text hover:text-gosign-accent-hover mt-3 inline-block whitespace-nowrap">Przegląd Governance &rarr;</a>
</div>
</div>
</div>
</div>
</section>

<!-- Pogłębienie w Agent Briefing -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Pogłębienie w Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nasza seria artykułów fachowych dla decydentów wdrażających agentów AI.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/pl/magazyn/infrastruktura-ai-blueprint-2026/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">Enterprise AI-Infrastruktura Blueprint 2026</p>
</a>
<a href="/pl/magazyn/decision-layer-wyjasnienie/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - czym jest i dlaczego każdy agent AI go potrzebuje?</p>
</a>
<a href="/pl/magazyn/orkiestracja-agentow-platformy/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">Orkiestracja agentów: Trigger.dev, n8n, Camunda</p>
</a>
</div>
</div>
</section>

--- Governance, Bezpieczeństwo i Audyt ---
> Jak Gosign sprawia, że AI Agents są audytowalne, gotowe do certyfikacji i zgodne z radą zakładową. Governance by Design jako zasada architektoniczna.

<!-- Governance by Design -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Governance by Design</h2>
<p class="text-body-lg text-gosign-text-light mt-6">
Gosign buduje AI Agents dla środowisk korporacyjnych. Te środowiska mają wymagania dotyczące identyfikowalności, audytowalności i kontroli, które wykraczają poza standardowe wdrożenie LLM.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Governance by Design oznacza: każdy agent jest budowany od podstaw z mechanizmami, których oczekują audytorzy, rady zakładowe i zespoły compliance. To nie jest opcjonalna warstwa. To zasada architektoniczna.
</p>
</div>
</div>
</section>

<!-- Pięć Wymiarów Governance -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">Pięć Wymiarów Governance</h2>
<div class="max-w-narrow space-y-8">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">1. Audit Trail i Identyfikowalność</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Każda decyzja AI Agenta generuje kompletny, niezmienny akt decyzyjny: wejście, model i wersja, ocena ekspercka, wynik pewności, zastosowana reguła z wersją, ścieżka decyzji (autonomiczna lub human-in-the-loop), wynik, znacznik czasu i ścieżka podważenia. Audit Trail jest niezmienny, eksportowalny i czytelny maszynowo. Akt decyzyjny jest architektoniczną odpowiedzią na prawo osób, których decyzja dotyczy, do wyjaśnienia pojedynczej decyzji wg <a href="/pl/magazyn/akt-decyzyjny-podwazalne-decyzje-ai/" class="text-gosign-accent-text hover:underline">art. 86 EU AI Act</a>.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">2. Decision Layer</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Decision Layer to warstwa architektoniczna między AI Agentem a systemem docelowym. Czyni każdą decyzję LLM transparentną, audytowalną i identyfikowalną. Decyzja autonomiczna gdzie model może decydować bezpiecznie. Human-in-the-Loop gdzie istnieje ryzyko - wymuszone architektonicznie.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">3. Cert-Ready by Design</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Kontrole to obiekty danych pierwszej klasy w systemie. Każda kontrola ma implementację techniczną, automatyczny generator dowodów, historię dowodów i widok audytora z drill-down.
</p>
<p class="mt-2">
<a href="/pl/governance/cert-ready/" class="text-gosign-accent-text font-semibold hover:text-gosign-accent-hover">Cert-Ready by Design &rarr;</a>
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">4. Konsultacja i Rada Pracowników</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
AI Agents w przedsiębiorstwach europejskich podlegają regulacjom dotyczącym informacji, konsultacji i reprezentacji pracowników. W Polsce Rada Zakładowa ma prawo do informacji i konsultacji. Architektura Gosign traktuje to jako zasadę projektową.
</p>
<p class="mt-2">
<a href="/pl/governance/co-determination/" class="text-gosign-accent-text font-semibold hover:text-gosign-accent-hover">Konsultacja i Rada Pracowników &rarr;</a>
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">5. EU AI Act</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Transparentność (Art. 13), nadzór ludzki (Art. 14), obowiązki rejestracji (Art. 12), zarządzanie ryzykiem (Art. 9) oraz prawo do wyjaśnienia pojedynczej decyzji (Art. 86) - wbudowane architektonicznie.
</p>
<p class="mt-2">
<a href="/pl/governance/eu-ai-act/" class="text-gosign-accent-text font-semibold hover:text-gosign-accent-hover">EU AI Act Readiness &rarr;</a>
</p>
</div>
</div>
</div>
</section>

<!-- Sześć wymiarów Governance -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">Sześć wymiarów Governance</h2>
<div class="grid grid-cols-1 lg:grid-cols-3 gap-6 lg:gap-8">
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75L11.25 15 15 9.75m-3-7.036A11.959 11.959 0 013.598 6 11.99 11.99 0 003 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Cert-Ready by Design</h3>
<p class="text-body text-gosign-text-light mt-3">Kontrole jako obiekty danych, dowody automatycznie, Portal Audytora na żywo. Gotowość certyfikacyjna to nie projekt, lecz stan architektury.</p>
<a href="/pl/governance/cert-ready/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
Cert-Ready Controls
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M18 18.72a9.094 9.094 0 003.741-.479 3 3 0 00-4.682-2.72m.94 3.198l.001.031c0 .225-.012.447-.037.666A11.944 11.944 0 0112 21c-2.17 0-4.207-.576-5.963-1.584A6.062 6.062 0 016 18.719m12 0a5.971 5.971 0 00-.941-3.197m0 0A5.995 5.995 0 0012 12.75a5.995 5.995 0 00-5.058 2.772m0 0a3 3 0 00-4.681 2.72 8.986 8.986 0 003.74.477m.94-3.197a5.971 5.971 0 00-.94 3.197M15 6.75a3 3 0 11-6 0 3 3 0 016 0zm6 3a2.25 2.25 0 11-4.5 0 2.25 2.25 0 014.5 0zm-13.5 0a2.25 2.25 0 11-4.5 0 2.25 2.25 0 014.5 0z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Konsultacja i Rada Pracowników</h3>
<p class="text-body text-gosign-text-light mt-3">Porozumienia zakładowe jako ograniczenia. Human-in-the-Loop przy decyzjach wymagających konsultacji z radą pracowników. Technicznie wymuszone, nie organizacyjnie uzgodnione.</p>
<a href="/pl/governance/co-determination/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
Konsultacja i Rada Pracowników
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 3v17.25m0 0c-1.472 0-2.882.265-4.185.75M12 20.25c1.472 0 2.882.265 4.185.75M18.75 4.97A48.416 48.416 0 0012 4.5c-2.291 0-4.545.16-6.75.47m13.5 0c1.01.143 2.01.317 3 .52m-3-.52l2.62 10.726c.122.499-.106 1.028-.589 1.202a5.988 5.988 0 01-2.031.352 5.988 5.988 0 01-2.031-.352c-.483-.174-.711-.703-.59-1.202L18.75 4.971zm-16.5.52c.99-.203 1.99-.377 3-.52m0 0l2.62 10.726c.122.499-.106 1.028-.589 1.202a5.989 5.989 0 01-2.031.352 5.989 5.989 0 01-2.031-.352c-.483-.174-.711-.703-.59-1.202L5.25 4.971z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">EU AI Act</h3>
<p class="text-body text-gosign-text-light mt-3">EU AI Act compliant by design. Mapowanie architektury na Art. 9-15. Przejrzystość, wyjaśnialność i nadzór ludzki jako architektura bazowa.</p>
<a href="/pl/governance/eu-ai-act/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
EU AI Act Compliance
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M21 7.5l-2.25-1.313M21 7.5v2.25m0-2.25l-2.25 1.313M3 7.5l2.25-1.313M3 7.5l2.25 1.313M3 7.5v2.25m9 3l2.25-1.313M12 12.75l-2.25-1.313M12 12.75V15m0 6.75l2.25-1.313M12 21.75V19.5m0 2.25l-2.25-1.313m0-16.875L12 2.25l2.25 1.313M21 14.25v2.25l-2.25 1.313m-13.5 0L3 16.5v-2.25" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Architektura Referencyjna</h3>
<p class="text-body text-gosign-text-light mt-3">Architektura 7-warstwowa Enterprise AI. Governance jako warstwa przekrojowa. Prezentacja, Orkiestracja, Agent, Governance, Model, Integracja, Infrastruktura.</p>
<a href="/pl/governance/reference-architecture/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
Architektura
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M16.5 10.5V6.75a4.5 4.5 0 10-9 0v3.75m-.75 11.25h10.5a2.25 2.25 0 002.25-2.25v-6.75a2.25 2.25 0 00-2.25-2.25H6.75a2.25 2.25 0 00-2.25 2.25v6.75a2.25 2.25 0 002.25 2.25z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Rezydencja Danych</h3>
<p class="text-body text-gosign-text-light mt-3">RODO. Azure UE, GCP UE, AWS UE, Self-Hosted, Hybryda. Suwerenność danych jako decyzja architektoniczna, nie opcja konfiguracyjna.</p>
<a href="/pl/governance/data-residency/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
Rezydencja Danych
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12h3.75M9 15h3.75M9 18h3.75m3 .75H18a2.25 2.25 0 002.25-2.25V6.108c0-1.135-.845-2.098-1.976-2.192a48.424 48.424 0 00-1.123-.08m-5.801 0c-.065.21-.1.433-.1.664 0 .414.336.75.75.75h4.5a.75.75 0 00.75-.75 2.25 2.25 0 00-.1-.664m-5.8 0A2.251 2.251 0 0113.5 2.25H15a2.25 2.25 0 012.15 1.586m-5.8 0c-.376.023-.75.05-1.124.08C9.095 4.01 8.25 4.973 8.25 6.108V8.25m0 0H4.875c-.621 0-1.125.504-1.125 1.125v11.25c0 .621.504 1.125 1.125 1.125h9.75c.621 0 1.125-.504 1.125-1.125V9.375c0-.621-.504-1.125-1.125-1.125H8.25zM6.75 12h.008v.008H6.75V12zm0 3h.008v.008H6.75V15zm0 3h.008v.008H6.75V18z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Umowa powierzenia dla infrastruktury AI</h3>
<p class="text-body text-gosign-text-light mt-3">Dlaczego standardowe umowy powierzenia nie wystarczają dla enterprise AI. Katalog wymagań z 25 pytaniami weryfikacyjnymi dla działu prawnego, bezpieczeństwa IT i rady pracowników.</p>
<a href="/pl/governance/lista-kontrolna-avv/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
Lista kontrolna
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</article>
</div>
</div>
</section>

<!-- Architecture Preview -->
<section class="py-section bg-gosign-dark text-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold mb-6">Przegląd Architektury</h2>
<pre class="bg-gosign-dark text-white p-6 rounded-card overflow-x-auto text-small font-mono leading-relaxed"><code>┌─────────────────────────────────────────────────┐
│  Presentation Layer    Chat UI, Dashboard, API  │
├─────────────────────────────────────────────────┤
│  Orchestration Layer   Trigger.dev/Camunda, API GW      │
├─────────────────────────────────────────────────┤
│  Agent Layer           Document, Workflow,       │
│                        Knowledge Agents          │
├─────────────────────┬───────────────────────────┤
│  GOVERNANCE LAYER   │ Audit Trail, RBAC,        │
│  (Przekrojowa)      │ Decision Layer,           │
│                     │ Cert-Ready Controls       │
├─────────────────────┴───────────────────────────┤
│  Model Layer           Claude, ChatGPT, Llama   │
├─────────────────────────────────────────────────┤
│  Integration Layer     SAP, ERP, MS Graph       │
├─────────────────────────────────────────────────┤
│  Infrastructure Layer  Azure, GCP, AWS, Self-Hosted  │
└─────────────────────────────────────────────────┘</code></pre>
<p class="mt-6">
<a href="/pl/governance/reference-architecture/" class="inline-flex items-center text-body-lg font-semibold text-gosign-accent-on-dark hover:text-gosign-accent-on-dark transition-colors">
Pełna architektura referencyjna
<svg class="w-5 h-5 ml-2" fill="none" stroke="currentColor" viewBox="0 0 24 24">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" />
</svg>
</a>
</p>
</div>
</section>

<!-- Closing -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Governance Dotyczy Każdego Agenta</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Governance by Design to nie cecha pojedynczego produktu. To zasada architektoniczna stosowana do każdego AI Agenta budowanego przez Gosign.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Ta sama governance. Ta sama audytowalność. Ta sama infrastruktura.
</p>
</div>
</div>
</section>

<!-- Pogłębienie w Agent Briefing -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">Pogłębienie w Agent Briefing (Magazyn Gosign)</h2>
<div class="grid md:grid-cols-3 gap-6">
<a href="/pl/magazyn/shadow-ai-governance/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<h3 class="text-h3 font-bold text-gosign-dark">Decision Layer i Shadow AI</h3>
</a>
<a href="/pl/magazyn/eu-ai-act-2026-przedsiebiorstwa/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<h3 class="text-h3 font-bold text-gosign-dark">EU AI Act 2026</h3>
</a>
<a href="/pl/magazyn/infrastruktura-ai-blueprint-2026/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Infrastructure</p>
<h3 class="text-h3 font-bold text-gosign-dark">Infrastruktura AI Blueprint 2026</h3>
</a>
</div>
</div>
</section>

--- Enterprise AI Agents - W Twojej infrastrukturze. Pod Twoją kontrolą. ---
> Enterprise AI Agent Infrastructure dla HR, Finance i IT. Audytowalne decyzje LLM, Governance by Design, niezależność od modelu.

<!-- Enterprise AI Infrastructure & Agent Engineering -->
<section class="scroll-reveal py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex flex-col lg:flex-row lg:items-start lg:gap-12">
<div class="lg:w-[55%]">
<h2 class="text-h1 font-bold text-gosign-dark">
Enterprise AI Infrastructure & Agent Engineering
</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Gosign to Enterprise AI Infrastructure & Agent Engineering Company. Projektujemy i wdrażamy infrastrukturę, na której AI Agents działają produkcyjnie w przedsiębiorstwach: orkiestracja, governance, Decision Layer i audyt.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
25 lat tworzenia oprogramowania. Do 108 pracowników. Ponad 5000 projektów dla Airbus, Volkswagen, Shell. Od 2024 roku skoncentrowani na Enterprise AI Agent Engineering.
</p>
</div>
<div class="lg:w-[45%] mt-8 lg:mt-0 flex justify-center">
<img
src="/images/7-layer-architecture-v2.svg"
alt="Gosign 7-warstwowa architektura Enterprise AI: Presentation Layer (Chat UI, Dashboard, API), Orchestration Layer (Trigger.dev, Camunda), Agent Layer (Document, Workflow, Knowledge Agents), Governance Layer jako warstwa przekrojowa (Audit Trail, RBAC, Decision Layer, Cert-Ready Controls), Model Layer (Claude, GPT, Gemini, Llama, Mistral, DeepSeek - niezależność od modelu), Integration Layer (SAP, ERP, Microsoft Graph), Infrastructure Layer (Azure UE, GCP UE, AWS UE, Self-Hosted, Hybrid)"
width="500"
height="400"
class="w-full max-w-md"
loading="lazy"
/>
</div>
</div>
</div>
</section>

<!-- Dlaczego większość projektów AI nie przynosi mierzalnych korzyści -->
<section class="scroll-reveal py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Dlaczego większość projektów AI nie przynosi mierzalnych korzyści</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Większość przedsiębiorstw już korzysta z AI. Bardzo nieliczne osiągają dzięki temu mierzalne korzyści. Nie dlatego, że technologia nie działa - lecz dlatego, że nikt nie zdefiniował, które decyzje AI może podejmować samodzielnie, a które muszą pozostać przy człowieku.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Doświadczenie branżowe pokazuje: na każde euro w technologię potrzeba czterech do pięciu euro w procesy, governance i zarządzanie zmianą. Kto inwestuje tylko w technologię, inwestuje obok problemu.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
<a href="/pl/decision-layer/" class="text-gosign-accent-text hover:underline font-semibold">Decision Layer</a> to warstwa, która robi tę różnicę: rozkłada każdy proces biznesowy na pojedyncze kroki decyzyjne i dla każdego kroku definiuje z góry - człowiek, zestaw reguł czy AI. Dzięki temu eksperyment AI staje się produktywnym systemem.
</p>
</div>
</div>
</section>

<!-- AI Agents dla Twojego działu -->
<section class="scroll-reveal py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">AI Agents dla Twojego działu</h2>
<div class="grid grid-cols-1 gap-6 lg:gap-8 lg:grid-cols-3">
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 hover:shadow-lg hover:-translate-y-0.5 transition-all duration-200">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<img src="/images/icon-finance.svg" alt="" class="w-10 h-10" width="40" height="40" />
</div>
<h3 class="text-h3 font-bold text-gosign-dark">AI Agents dla Finance & Audit</h3>
<p class="text-body text-gosign-text-light mt-3">Decision Automation dla przetwarzania dokumentów, kontowania i przygotowania do audytu. Wersjonowane reguły, pełna ścieżka audytu, Cert-Ready by Design. Decision Layer czyni każdą decyzję księgową odtwarzalną.</p>
<a href="/pl/finance-ai-agents/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
Finance AI Agents
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 hover:shadow-lg hover:-translate-y-0.5 transition-all duration-200">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<img src="/images/icon-hr.svg" alt="" class="w-10 h-10" width="40" height="40" />
</div>
<h3 class="text-h3 font-bold text-gosign-dark">AI Agents dla HR & People Operations</h3>
<p class="text-body text-gosign-text-light mt-3">Audytowalne AI Agents dla decyzji HR. Gotowe na radę zakładową. Decision Layer z Human-in-the-Loop. Wynagrodzenia, onboarding, przetwarzanie dokumentów, polityki i wiedza.</p>
<a href="/pl/hr-ai-agents/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
HR AI Agents
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 hover:shadow-lg hover:-translate-y-0.5 transition-all duration-200">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<img src="/images/icon-infrastructure.svg" alt="" class="w-10 h-10" width="40" height="40" />
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Infrastruktura AI dla IT & Enterprise</h3>
<p class="text-body text-gosign-text-light mt-3">Hosting LLM, RAG, orkiestracja. Self-hosted, chmura lub hybryda. Niezależność od modelu, Governance by Design, Cert-Ready by Design. Platforma, na której Twoi agenci działają produkcyjnie.</p>
<a href="/pl/uslugi/infrastruktura/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
Infrastruktura
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</article>
</div>
</div>
</section>

<!-- Trzy typy agentów -->
<section class="scroll-reveal py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 space-y-12">
<h2 class="text-h1 font-bold text-gosign-dark">Wyspecjalizowane Agents dla procesów Enterprise</h2>
<article class="flex flex-col lg:flex-row gap-8 lg:gap-12 items-start">
<div class="flex-shrink-0 w-16 h-16 lg:w-20 lg:h-20 rounded-full bg-gosign-accent/10 flex items-center justify-center">
<span class="text-h1 lg:text-hero font-bold text-gosign-accent-text">01</span>
</div>
<div class="flex-1 lg:w-[55%]">
<h3 class="text-h2 font-bold text-gosign-dark">Document Agents</h3>
<p class="text-body-lg text-gosign-text-light mt-3">Specjalista: rozumie dokumenty. Przychodzi zwolnienie lekarskie. Agent rozpoznaje typ dokumentu, ekstrahuje imię, okres i kod diagnozy, sprawdza czy wszystkie wymagane pola są wypełnione i przypisuje dokument do właściwego pracownika. Nie dopasowywanie szablonów - rzeczywiste rozumienie języka: rozróżnia zwolnienie lekarskie od orzeczenia o niezdolności do pracy, nawet gdy oba pochodzą od tego samego lekarza. Decision Layer ocenia każdą ekstrakcję: deterministyczna? Zestaw reguł. Wystarczająco pewna? Agent decyduje samodzielnie. Potrzebna swoboda oceny? Człowiek weryfikuje.</p>
<a href="/pl/uslugi/ai-agents/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
Document Agents w szczegółach
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</div>
<div class="lg:w-[40%] mt-4 lg:mt-11">
<img src="/images/flow-document-agent-v10-pl.svg" alt="Document Agent - Specjalista: Jeden dokument wchodzi, agent rozumie typ, treść i kontekst, Decision Layer kieruje przez trzy poziomy (reguły, autonomia AI, weryfikacja ludzka), strukturalne dane wychodzą." class="w-full" width="480" height="620" loading="lazy" />
</div>
</article>
<article class="flex flex-col lg:flex-row gap-8 lg:gap-12 items-start">
<div class="flex-shrink-0 w-16 h-16 lg:w-20 lg:h-20 rounded-full bg-gosign-accent/10 flex items-center justify-center">
<span class="text-h1 lg:text-hero font-bold text-gosign-accent-text">02</span>
</div>
<div class="flex-1 lg:w-[55%]">
<h3 class="text-h2 font-bold text-gosign-dark">Workflow Agents</h3>
<p class="text-body-lg text-gosign-text-light mt-3">Koordynator: steruje całym procesem. Zwolnienie lekarskie jest zrozumiane - co teraz? Workflow Agent przejmuje: sprawdza w systemie HR czy to trzecie zgłoszenie w ciągu sześciu miesięcy, weryfikuje z układem zbiorowym pracy czy próg powrotu do pracy został osiągnięty, tworzy zadanie dla menedżera HR w SAP SuccessFactors, informuje Radę Zakładową i planuje follow-up. Pięć systemów, trzy punkty decyzyjne, jeden agent koordynujący cały proces - w tym samodzielne decyzje routingowe gdy pewność jest wystarczająca. Każdy krok w ścieżce audytu.</p>
<a href="/pl/uslugi/ai-agents/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
Workflow Agents w szczegółach
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</div>
<div class="lg:w-[40%] mt-4 lg:mt-11">
<img src="/images/flow-workflow-agent-v10-pl.svg" alt="Workflow Agent - Koordynator: Steruje wieloetapowym procesem między systemami. Wywołuje Document Agents, weryfikuje z regulaminami, tworzy zadania w SAP, informuje Radę Zakładową, planuje follow-upy. Każdy krok w ścieżce audytu." class="w-full" width="480" height="542" loading="lazy" />
</div>
</article>
<article class="flex flex-col lg:flex-row gap-8 lg:gap-12 items-start">
<div class="flex-shrink-0 w-16 h-16 lg:w-20 lg:h-20 rounded-full bg-gosign-accent/10 flex items-center justify-center">
<span class="text-h1 lg:text-hero font-bold text-gosign-accent-text">03</span>
</div>
<div class="flex-1 lg:w-[55%]">
<h3 class="text-h2 font-bold text-gosign-dark">Knowledge Agents</h3>
<p class="text-body-lg text-gosign-text-light mt-3">Nośnik wiedzy: odpowiada na pytania z wiedzy przedsiębiorstwa. Menedżer HR pyta: 'Kiedy należy rozpocząć procedurę powrotu do pracy po długotrwałej nieobecności?' Agent nie tylko wyszukuje - interpretuje regulaminy, układ zbiorowy pracy i wymogi prawne w kontekście pytania, dostarczając specyficzną odpowiedź ze wskazaniem źródła, wersji reguły i daty ważności. Przy niepewności oznacza ją jawnie. Bez zweryfikowanego źródła agent nie odpowiada - żadnych halucynacji.</p>
<a href="/pl/uslugi/ai-agents/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">
Knowledge Agents w szczegółach
<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg>
</a>
</div>
<div class="lg:w-[40%] mt-4 lg:mt-11">
<img src="/images/flow-knowledge-agent-v10-pl.svg" alt="Knowledge Agent - Nośnik wiedzy: Pytanie z kontekstem wchodzi, agent interpretuje zweryfikowane źródła, specyficzna odpowiedź ze źródłem i wersją wychodzi. Przy niepewności: oznaczenie. Bez źródła: brak odpowiedzi." class="w-full" width="480" height="628" loading="lazy" />
</div>
</article>
</div>
</section>

<!-- Porównanie architektur -->
<section class="scroll-reveal py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-4">Porównanie architektur: Copilot, SaaS Agent, Gosign</h2>
<p class="text-body-lg text-gosign-text-light mb-8">Trzy podejścia do AI w przedsiębiorstwie - różne architektury, różne konsekwencje.</p>
<div class="overflow-x-auto -mx-4 sm:mx-0">
<table class="w-full min-w-[36rem] border-collapse text-small">
<thead>
<tr>
<th class="px-4 py-3 text-left font-semibold bg-gosign-dark text-white">Wymiar</th>
<th class="px-4 py-3 text-left font-semibold bg-gosign-dark text-white border-t-[3px] border-t-gosign-accent">Gosign Agent Architecture</th>
<th class="px-4 py-3 text-left font-semibold bg-gosign-dark text-white">Microsoft Copilot</th>
<th class="px-4 py-3 text-left font-semibold bg-gosign-dark text-white">SaaS AI Agent</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Głębokość decyzji</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border bg-gosign-accent/5">Decyzje merytoryczne z Decision Layer</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Asystencja i sugestie</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Prekonfigurowane workflow</td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Audytowalność</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border bg-gosign-accent/5">Pełna ścieżka audytu do poziomu SQL</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Podstawowe logowanie</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Logowanie platformy</td>
</tr>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Dostęp do kodu</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border bg-gosign-accent/5">Pełny dostęp do kodu źródłowego · Konfiguracje u klienta · Bez vendor lock-in</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Microsoft jest właścicielem</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Platforma jest właścicielem</td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Wybór modelu</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border bg-gosign-accent/5">Niezależność od modelu (GPT, Claude, Gemini, Llama, Mistral)</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">GPT (związany z Microsoft)</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Związany z platformą</td>
</tr>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Governance</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border bg-gosign-accent/5">Własny Governance Layer, Cert-Ready Controls, Portal Audytora</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Azure governance</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Governance platformy</td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Human-in-the-Loop</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border bg-gosign-accent/5">Architektonicznie wymuszony przy decyzjach ryzykownych</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Opcjonalny</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Konfigurowalny</td>
</tr>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">EU AI Act</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border bg-gosign-accent/5">Compliant by design</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Roadmapa Microsoft</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Zależny od dostawcy</td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Rada Zakładowa / Współdecydowanie</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border bg-gosign-accent/5">Szablony, logowanie, koncepcja ról dla Rady Zakładowej</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Brak dedykowanego wsparcia</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Brak dedykowanego wsparcia</td>
</tr>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Infrastruktura</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border bg-gosign-accent/5">Infrastruktura klienta (Azure, GCP, AWS, self-hosted, hybryda)</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Microsoft Cloud</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Chmura dostawcy</td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Strategia wyjścia</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border bg-gosign-accent/5">Niezależna eksploatacja po 12-18 miesiącach</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Migracja platformy</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Migracja platformy</td>
</tr>
</tbody>
</table>
</div>
<p class="text-small text-gosign-text-light italic mt-4">
Ta tabela pokazuje różnice architektoniczne, nie oceny jakościowe. Copilot i agenci SaaS mają inne zalety - szybkość, ekosystem, prostota. Siłą Gosign jest governance, własność i audytowalność w środowiskach regulowanych.
</p>
</div>
</section>

<!-- Governance by Design -->
<section class="scroll-reveal bg-gosign-dark text-white py-section">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold">Governance by Design</h2>
<p class="text-h3 text-gosign-accent-on-dark font-semibold mt-4">
Agenci skalują się tylko z infrastrukturą. Bez governance AI pozostaje pilotem - z infrastrukturą staje się skalowalna.
</p>
<div class="mt-8 space-y-4">
<p class="text-body-lg text-gosign-text-on-dark/80 flex items-start gap-3">
<svg class="w-5 h-5 mt-1 flex-shrink-0 text-gosign-accent-on-dark" fill="currentColor" viewBox="0 0 20 20"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span>Human-in-the-Loop: Nie bramka blokująca, lecz sterowanie architektoniczne. Wysoka pewność i niskie ryzyko: decyzja autonomiczna. Ryzyko stronniczości lub kwestie wymagające konsultacji z radą pracowników: decyduje człowiek.</span>
</p>
<p class="text-body-lg text-gosign-text-on-dark/80 flex items-start gap-3">
<svg class="w-5 h-5 mt-1 flex-shrink-0 text-gosign-accent-on-dark" fill="currentColor" viewBox="0 0 20 20"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span>Audytowalność: Każda decyzja agenta generuje kompletny zapis - dane wejściowe, model, ocena, wynik pewności, uzasadnienie, ścieżka decyzyjna, rezultat. Niezmienny, eksportowalny, gotowy do audytu.</span>
</p>
<p class="text-body-lg text-gosign-text-on-dark/80 flex items-start gap-3">
<svg class="w-5 h-5 mt-1 flex-shrink-0 text-gosign-accent-on-dark" fill="currentColor" viewBox="0 0 20 20"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span>Cert-Ready by Design: Kontrole to obiekty danych pierwszej klasy w systemie. Automatyczny generator dowodów i historia dowodów. Audytorzy widzą status na żywo w Portalu Audytora.</span>
</p>
<p class="text-body-lg text-gosign-text-on-dark/80 flex items-start gap-3">
<svg class="w-5 h-5 mt-1 flex-shrink-0 text-gosign-accent-on-dark" fill="currentColor" viewBox="0 0 20 20"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span>EU AI Act compliant by design: Przejrzystość, wyjaśnialność i nadzór ludzki są wbudowane architektonicznie - nie dorabiane.</span>
</p>
</div>
</div>
<div class="mt-12 overflow-x-auto -mx-4 sm:mx-0 px-4 sm:px-0">
<img src="/images/diagrams/decision-layer-drei-arten-pl.svg" alt="Trzy poziomy autonomii w Gosign Decision Layer: (1) Człowiek decyduje - agent dostarcza dane przy korektach wynagrodzeń, zwolnieniach, przeniesieniach, decyzjach z ryzykiem dyskryminacji, sprawach rady zakładowej (ok. 35% procesów HR). (2) Agent pracuje, człowiek weryfikuje - przy przetwarzaniu dokumentów, weryfikacji umów, krokach onboardingowych, tworzeniu świadectw, screeningu rekrutacyjnym (ok. 40% procesów HR). (3) Agent samodzielny - przy odpowiedziach FAQ, standardowych zaświadczeniach, kontroli terminów, walidacji danych, rutynowych powiadomieniach (ok. 25% procesów HR). Każda decyzja dokumentowana, każdy krok audytowalny." width="900" height="360" class="w-full min-w-[600px] max-w-4xl mx-auto rounded-lg" loading="lazy" />
</div>
</div>
</section>

<!-- Definicja: Decision Layer -->
<section class="scroll-reveal py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h3 class="text-h3 font-bold text-gosign-dark">Definicja: Decision Layer</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Decision Layer rozkłada każdy proces biznesowy na pojedyncze kroki decyzyjne i dla każdego kroku definiuje z góry: Czy decyduje człowiek, zestaw reguł czy AI samodzielnie?
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Tam gdzie swoboda oceny, ryzyko dyskryminacji lub kwestie konsultacji z radą zakładową odgrywają rolę, architektura wymusza weryfikację przez człowieka. Tam gdzie decyzja jest deterministyczna - układ zbiorowy pracy, kontrola terminów, logika księgowa - agent stosuje zestaw reguł konsekwentnie. A tam gdzie agent jest wystarczająco pewny i ma uprawnienia: decyduje samodzielnie.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Każda decyzja jest dokumentowana - kto, kiedy, co zdecydował, na jakiej podstawie, z jakim wynikiem. Weryfikowalne dla biegłych rewidentów, rady zakładowej i rewizji wewnętrznej.
</p>
<p class="mt-4">
<a href="/pl/governance/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Governance, bezpieczeństwo i audyt</a>
</p>
</div>
</div>
</section>

<!-- Od PoC do Platformy -->
<section class="scroll-reveal py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark text-center">Od PoC do Platformy</h2>
<div class="mt-12 grid grid-cols-1 md:grid-cols-3 gap-8 relative">
<div class="text-center">
<div class="w-14 h-14 mx-auto rounded-full bg-gosign-accent flex items-center justify-center">
<span class="text-h3 font-bold text-white">1</span>
</div>
<h3 class="text-h3 font-bold text-gosign-dark mt-4">Discover</h3>
<p class="text-small font-semibold text-gosign-accent-text mt-1">1 tydzień</p>
<p class="text-body text-gosign-text-light mt-2">Analiza procesów, mapowanie reguł, ocena krajobrazu systemowego, priorytetyzacja zastosowań. Rezultat: konkretny plan dla Twojego pierwszego agenta.</p>
</div>
<div class="text-center">
<div class="w-14 h-14 mx-auto rounded-full bg-gosign-accent flex items-center justify-center">
<span class="text-h3 font-bold text-white">2</span>
</div>
<h3 class="text-h3 font-bold text-gosign-dark mt-4">Build</h3>
<p class="text-small font-semibold text-gosign-accent-text mt-1">3-4 tygodnie</p>
<p class="text-body text-gosign-text-light mt-2">Produkcyjny PoC. Jeden agent, jeden proces, na żywo w Twojej infrastrukturze. Decision Layer, governance, ścieżka audytu - od pierwszego dnia.</p>
</div>
<div class="text-center">
<div class="w-14 h-14 mx-auto rounded-full bg-gosign-accent flex items-center justify-center">
<span class="text-h3 font-bold text-white">3</span>
</div>
<h3 class="text-h3 font-bold text-gosign-dark mt-4">Scale</h3>
<p class="text-small font-semibold text-gosign-accent-text mt-1">Ciągły</p>
<p class="text-body text-gosign-text-light mt-2">Więcej agentów, więcej działów, więcej lokalizacji. Architektura rośnie z Twoimi wymaganiami. Ten sam governance, ta sama infrastruktura.</p>
</div>
</div>
<p class="text-body-lg text-center text-gosign-text-light mt-8 max-w-narrow mx-auto">
Po 12-18 miesiącach eksploatujesz swoich agentów samodzielnie. Pełny dostęp do kodu źródłowego, promptów i konfiguracji. Bez vendor lock-in - także bez umowy serwisowej.
</p>
</div>
</section>

--- HR Agent - AI Agents dla HR i People Operations ---
> 6 produktów AI Agent dla HR: Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Decision Layer z Audit Trail. Gotowe na radę pracowników.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/pl/dlaczego-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Każda decyzja możliwa do prześledzenia</p>
</div>
</a>
<a href="/pl/dlaczego-gosign/#infrastruktura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Twoja infrastruktura</p>
<p class="text-xs text-gosign-text-light">Bez SaaS. Bez vendor-lock-in.</p>
</div>
</a>
<a href="/pl/dlaczego-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Bez ryzyka US-cloud</p>
</div>
</a>
</div>
</div>
</div>

<!-- Product Portfolio -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Portfolio HR Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 mb-8 max-w-narrow">
HR Agent nie automatyzuje procesów ogólnie, lecz rozkłada je na mikro-decyzje. Dla każdej decyzji <a href="/pl/decision-layer/" class="text-gosign-accent-text hover:text-gosign-accent-hover">Decision Layer</a> określa: człowiek, zbiór reguł czy AI.
</p>
<div class="grid grid-cols-1 md:grid-cols-2 lg:grid-cols-3 gap-6">
<a href="/pl/uslugi/hr-agent/payroll-decision-layer/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white"><div class="flex items-center justify-between mb-3"><svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 18.75a60.07 60.07 0 0115.797 2.101c.727.198 1.453-.342 1.453-1.096V18.75M3.75 4.5v.75A.75.75 0 013 6h-.75m0 0v-.375c0-.621.504-1.125 1.125-1.125H20.25M2.25 6v9m18-10.5v.75c0 .414.336.75.75.75h.75m-1.5-1.5h.375c.621 0 1.125.504 1.125 1.125v9.75c0 .621-.504 1.125-1.125 1.125h-.375m1.5-1.5H21a.75.75 0 00-.75.75v.75m0 0H3.75m0 0h-.375a1.125 1.125 0 01-1.125-1.125V15m1.5 1.5v-.75A.75.75 0 003 15h-.75M15 10.5a3 3 0 11-6 0 3 3 0 016 0zm3 0h.008v.008H18V10.5zm-12 0h.008v.008H6V10.5z"/></svg></div><h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Payroll Decision Layer</h3><p class="text-body text-gosign-text-light mt-2">Układy zbiorowe, dodatki zmianowe, świadczenia specjalne. 4 symulacje branżowe.</p><p class="text-body font-semibold text-gosign-dark mt-3">82-92% Zero-Touch</p></a>
<a href="/pl/uslugi/travel-decision-layer/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white"><div class="flex items-center justify-between mb-3"><svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M6 12L3.269 3.126A59.768 59.768 0 0121.485 12 59.77 59.77 0 013.27 20.876L5.999 12zm0 0h7.5"/></svg></div><h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Travel Decision Layer</h3><p class="text-body text-gosign-text-light mt-2">Każde rozliczenie podróży służbowej w 5-12 audytowalnych kroków decyzyjnych.</p><p class="text-body font-semibold text-gosign-dark mt-3">>80% redukcja kosztów na dokument</p></a>
<a href="/pl/recruiting-agent/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white"><div class="flex items-center justify-between mb-3"><svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M18 18.72a9.094 9.094 0 003.741-.479 3 3 0 00-4.682-2.72m.94 3.198l.001.031c0 .225-.012.447-.037.666A11.944 11.944 0 0112 21c-2.17 0-4.207-.576-5.963-1.584A6.062 6.062 0 016 18.719m12 0a5.971 5.971 0 00-.941-3.197m0 0A5.995 5.995 0 0012 12.75a5.995 5.995 0 00-5.058 2.772m0 0a3 3 0 00-4.681 2.72 8.986 8.986 0 003.74.477m.94-3.197a5.971 5.971 0 00-.94 3.197M15 6.75a3 3 0 11-6 0 3 3 0 016 0zm6 3a2.25 2.25 0 11-4.5 0 2.25 2.25 0 014.5 0zm-13.5 0a2.25 2.25 0 11-4.5 0 2.25 2.25 0 014.5 0z"/></svg></div><h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Recruiting Agent</h3><p class="text-body text-gosign-text-light mt-2">Screening, terminowanie, komunikacja standardowa. EU AI Act wysokie ryzyko.</p><p class="text-body font-semibold text-gosign-dark mt-3">70-75% automatyzacja</p></a>
<a href="/pl/uslugi/hr-agent/leave-absence-decision-layer/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white"><div class="flex items-center justify-between mb-3"><svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M6.75 3v2.25M17.25 3v2.25M3 18.75V7.5a2.25 2.25 0 012.25-2.25h13.5A2.25 2.25 0 0121 7.5v11.25m-18 0A2.25 2.25 0 005.25 21h13.5A2.25 2.25 0 0021 18.75m-18 0v-7.5A2.25 2.25 0 015.25 9h13.5A2.25 2.25 0 0121 11.25v7.5"/></svg></div><h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Leave & Absence Decision Layer</h3><p class="text-body text-gosign-text-light mt-2">Uprawnienia urlopowe, zasady nieobecności, obowiązki reintegracyjne. 4 symulacje branżowe.</p><p class="text-body font-semibold text-gosign-dark mt-3">78-87% Zero-Touch</p></a>
<div class="border border-gosign-border rounded-card p-6 bg-gosign-light/50"><div class="flex items-center justify-between mb-3"><svg class="w-8 h-8 text-gosign-text-light" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M16.023 9.348h4.992v-.001M2.985 19.644v-4.992m0 0h4.992m-4.993 0l3.181 3.183a8.25 8.25 0 0013.803-3.7M4.031 9.865a8.25 8.25 0 0113.803-3.7l3.181 3.182"/></svg><span class="inline-flex items-center px-2.5 py-0.5 text-xs font-bold text-white bg-gosign-accent rounded-full">Coming</span></div><h3 class="text-h3 font-bold text-gosign-dark">Employee Lifecycle Decision Layer</h3><p class="text-body text-gosign-text-light mt-2">Onboarding, wewnętrzne transfery, offboarding w jednym pipeline.</p></div>
<div class="border border-gosign-border rounded-card p-6 bg-gosign-light/50"><div class="flex items-center justify-between mb-3"><svg class="w-8 h-8 text-gosign-text-light" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 3c2.755 0 5.455.232 8.083.678.533.09.917.556.917 1.096v1.044a2.25 2.25 0 01-.659 1.591l-5.432 5.432a2.25 2.25 0 00-.659 1.591v2.927a2.25 2.25 0 01-1.244 2.013L9.75 21v-6.568a2.25 2.25 0 00-.659-1.591L3.659 7.409A2.25 2.25 0 013 5.818V4.774c0-.54.384-1.006.917-1.096A48.32 48.32 0 0112 3z"/></svg><span class="inline-flex items-center px-2.5 py-0.5 text-xs font-bold text-white bg-gosign-accent rounded-full">Coming</span></div><h3 class="text-h3 font-bold text-gosign-dark">Candidate Screening Decision Layer</h3><p class="text-body text-gosign-text-light mt-2">EU AI Act wysokie ryzyko. Monitoring bias. Konsultacja z radą pracowników.</p></div>
</div>
</div>
</section>

<!-- Start Boring -->
<section class="py-section bg-gosign-light"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Dlaczego warto zacząć od nudnych procesów</h2>
<p class="text-body-lg text-gosign-text-light mt-4">Najskuteczniejsze agenty HR nie automatyzują najbardziej spektakularnych procesów - lecz najbardziej powtarzalne. Payroll, rejestracja czasu pracy, standardowe nieobecności: wysoka gęstość reguł, niskie ryzyko, mierzalny ROI od pierwszego dnia. Infrastruktura governance, którą przy tym budujesz, jest warunkiem wstępnym dla bardziej złożonych agentów.</p>
</div></div></section>

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Darmowy eBook: AI w HR</p>
<p class="text-body text-gosign-text mb-4">Checklista EU AI Act, Decision Framework, perspektywa rady zakładowej i ocena gotowości - poradnik governance dla liderów HR.</p>
<a href="/pl/ebook/ai-hr-poradnik-governance/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Pobierz za darmo</a>
</div>

<!-- Mikro-decyzje: 3 procesy HR -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Jak pracuje HR Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4">Każdy proces HR składa się z dziesiątek pojedynczych decyzji. Agent sprawdza przeciwko wszystkim kryteriom układu zbiorowego - spójniej niż jakikolwiek specjalista. Gdzie Kodeks pracy, rada pracowników lub ryzyko dyskryminacji tego wymagają, decyduje człowiek.</p>
<h3 class="text-h3 font-bold text-gosign-dark mt-10">Zwolnienie lekarskie</h3>
<div class="mt-4 overflow-x-auto"><table class="w-full text-left text-body"><thead><tr class="border-b-2 border-gosign-dark"><th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Mikro-decyzja</th><th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Kto decyduje</th><th scope="col" class="py-3 font-bold text-gosign-dark">Dlaczego</th></tr></thead><tbody class="text-gosign-text-light"><tr class="border-b border-gosign-border"><td class="py-3 pr-4">Sprawdzenie okresu wynagrodzenia chorobowego</td><td class="py-3 pr-4 font-medium">AI samodzielnie</td><td class="py-3">Sprawdza WSZYSTKIE kryteria układu zbiorowego - bardziej spójny niż jakikolwiek specjalista</td></tr><tr class="border-b border-gosign-border"><td class="py-3 pr-4">Ocena obowiązku reintegracji (&gt; 6 tyg. w 12 mies.)</td><td class="py-3 pr-4 font-medium">Człowiek</td><td class="py-3">Kodeks pracy wymaga human-in-the-loop, ryzyko dyskryminacji z danymi zdrowotnymi</td></tr><tr class="border-b border-gosign-border"><td class="py-3 pr-4">Poinformowanie przełożonego o nieobecności</td><td class="py-3 pr-4 font-medium">AI samodzielnie</td><td class="py-3">Spójna informacja - tylko nieobecność i czas trwania</td></tr></tbody></table></div>
<h3 class="text-h3 font-bold text-gosign-dark mt-10">Onboarding</h3>
<div class="mt-4 overflow-x-auto"><table class="w-full text-left text-body"><thead><tr class="border-b-2 border-gosign-dark"><th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Mikro-decyzja</th><th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Kto decyduje</th><th scope="col" class="py-3 font-bold text-gosign-dark">Dlaczego</th></tr></thead><tbody class="text-gosign-text-light"><tr class="border-b border-gosign-border"><td class="py-3 pr-4">Zaszeregowanie w układzie zbiorowym</td><td class="py-3 pr-4 font-medium">Człowiek</td><td class="py-3">Rada pracowników ma prawo konsultacji</td></tr><tr class="border-b border-gosign-border"><td class="py-3 pr-4">Dostępy IT i uprawnienia</td><td class="py-3 pr-4 font-medium">Reguły + AI</td><td class="py-3">Standardowe uprawnienia automatycznie, specjalne eskalowane</td></tr><tr class="border-b border-gosign-border"><td class="py-3 pr-4">Opracowanie planu wdrożenia</td><td class="py-3 pr-4 font-medium">AI + Człowiek</td><td class="py-3">AI tworzy propozycję, przełożony weryfikuje</td></tr></tbody></table></div>
<h3 class="text-h3 font-bold text-gosign-dark mt-10">Świadectwo pracy</h3>
<div class="mt-4 overflow-x-auto"><table class="w-full text-left text-body"><thead><tr class="border-b-2 border-gosign-dark"><th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Mikro-decyzja</th><th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Kto decyduje</th><th scope="col" class="py-3 font-bold text-gosign-dark">Dlaczego</th></tr></thead><tbody class="text-gosign-text-light"><tr class="border-b border-gosign-border"><td class="py-3 pr-4">Generowanie opisu stanowiska</td><td class="py-3 pr-4 font-medium">AI</td><td class="py-3">Na podstawie opisu stanowiska, propozycja do weryfikacji</td></tr><tr class="border-b border-gosign-border"><td class="py-3 pr-4">Sformułowanie oceny wyników</td><td class="py-3 pr-4 font-medium">Człowiek</td><td class="py-3">Ocena indywidualna, przełożony odpowiada</td></tr><tr class="border-b border-gosign-border"><td class="py-3 pr-4">Sprawdzenie zgodności prawnej</td><td class="py-3 pr-4 font-medium">AI + Człowiek</td><td class="py-3">AI sprawdza wzorce i flaguje ryzyka, człowiek decyduje finalnie</td></tr></tbody></table></div>
<p class="text-body-lg text-gosign-text-light mt-8"><strong>Wzorzec:</strong> Rutyna i reguły automatyzowane przez agenta. Decyzje uznaniowe i prawnie wrażliwe pozostają przy człowieku. Każdy krok udokumentowany.</p>
<p class="mt-4"><a href="/pl/decision-layer/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Więcej o Decision Layer &rarr;</a></p>
</div>
</div>
</section>

<section class="py-section bg-gosign-light"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow"><h2 class="text-h1 font-bold text-gosign-dark">Decision Layer: każda decyzja audytowalna</h2><p class="text-body-lg text-gosign-text-light mt-4"><a href="/pl/decision-layer/" class="text-gosign-accent-text hover:text-gosign-accent-hover">Decision Layer</a> rozkłada każdy proces HR na pojedyncze kroki decyzyjne i określa dla każdego kroku: decyduje człowiek, zbiór reguł czy AI? Gdzie model może bezpiecznie decydować, decyduje autonomicznie. Gdzie ryzyko bias, potencjał dyskryminacji lub konsultacja z radą pracowników odgrywają rolę, architektura wymusza ludzką weryfikację.</p><div class="mt-6 bg-gosign-white border border-gosign-border rounded-card p-6"><p class="text-body font-mono text-gosign-dark">Input &rarr; Model &rarr; Ocena &rarr; Confidence Score &rarr; Uzasadnienie &rarr; Ścieżka decyzyjna &rarr; Wynik</p></div><p class="text-body-lg text-gosign-text-light mt-4">Każda decyzja generuje kompletny rekord: dane wejściowe, reguła, wersja, konfidencja, wynik, znacznik czasu. Weryfikowalne dla rady pracowników, biegłego rewidenta i wewnętrznego compliance.</p></div></div></section>

<section class="py-section bg-gosign-white"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow"><h2 class="text-h1 font-bold text-gosign-dark">Governance i konsultacja z radą pracowników</h2><h3 class="text-h3 font-bold text-gosign-dark mt-8">Human-in-the-Loop jako zasada architektoniczna</h3><p class="text-body-lg text-gosign-text-light mt-4">Nie jako opcjonalna pętla zatwierdzania, lecz jako architektonicznie wymuszone routing. Autonomiczna decyzja przy wysokiej konfidencji i niskim ryzyku. Human-in-the-Loop przy ryzyku bias, potencjale dyskryminacji i kwestiach wymagających konsultacji z radą pracowników. Regulaminy zakładowe są mapowane jako jawne ograniczenia w Decision Layer - agent nie może ich ominąć.</p><p class="text-body-lg text-gosign-text-light mt-4"><a href="/pl/governance/co-determination/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Konsultacja z radą pracowników w szczegółach &rarr;</a></p><h3 class="text-h3 font-bold text-gosign-dark mt-8">Audit Trail</h3><p class="text-body-lg text-gosign-text-light mt-4">Każda decyzja agenta generuje kompletny rekord decyzyjny: dane wejściowe, reguła, wersja, konfidencja, ścieżka decyzyjna, wynik, znacznik czasu. Rada pracowników może przez portal audytora prześledzić wszystkie decyzje. Jak rady pracowników stają się wsparciem zamiast blokerem, opisuje <a href="/pl/magazyn/rada-zakladowa-ai-literacy/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">artykuł o AI Literacy i radach pracowników</a>.</p><h3 class="text-h3 font-bold text-gosign-dark mt-8">Gotowość na EU AI Act</h3><p class="text-body-lg text-gosign-text-light mt-4">Architektura adresuje przejrzystość (Art. 13), nadzór ludzki (Art. 14), obowiązki rejestracji (Art. 12) i zarządzanie ryzykiem (Art. 9) jako zasadę projektową - bez późniejszego projektu compliance.</p><p class="text-body-lg text-gosign-text-light mt-4"><a href="/pl/governance/eu-ai-act/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Gotowość na EU AI Act &rarr;</a></p></div></div></section>

<section class="py-section bg-gosign-light"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><div class="max-w-narrow"><h2 class="text-h1 font-bold text-gosign-dark">Integracja z istniejącą infrastrukturą</h2><p class="text-body-lg text-gosign-text-light mt-4">AI Agents nie zastępują systemów. SAP SuccessFactors pozostaje Twoim HCM, Workday pozostaje Twoją platformą HR, SAP FI/CO pozostaje Twoim ERP. Logika agentowa jest oddzielona od systemu docelowego - przez standardowe interfejsy. Brak projektu migracyjnego, brak zmiany systemu. Jeden proces, jeden system, jeden agent.</p></div></div></section>

<section class="py-section bg-gosign-dark text-white"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><h2 class="text-h1 font-bold">Od PoC do platformy</h2><div class="grid md:grid-cols-3 gap-8 mt-8"><div><p class="text-xs font-bold uppercase tracking-wider text-gosign-accent-on-dark">Discover - 1 tydzień</p><p class="text-body-lg text-gosign-text-on-dark/80 mt-2">Analiza procesów, zrozumienie zbiór regułów, priorytetyzacja use cases. Który proces ma najwyższy potencjał błędów?</p></div><div><p class="text-xs font-bold uppercase tracking-wider text-gosign-accent-on-dark">Build - 3-4 tygodnie</p><p class="text-body-lg text-gosign-text-on-dark/80 mt-2">Produkcyjny PoC. Jeden agent, jeden proces, na żywo w Twojej infrastrukturze z Decision Layer i Audit Trail.</p></div><div><p class="text-xs font-bold uppercase tracking-wider text-gosign-accent-on-dark">Scale - Ciągły</p><p class="text-body-lg text-gosign-text-on-dark/80 mt-2">Więcej agentów, więcej procesów. Ten sam governance, ta sama audytowalność. Po 12-18 miesiącach eksploatujesz swoich agentów samodzielnie.</p></div></div></div></section>

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">HR Agent Readiness Assessment</p>
<p class="text-body text-gosign-text mb-4">7 pytań, 3 minuty: Jak gotowa jest Twoja organizacja HR na AI Agents?</p>
<a href="/pl/hr-agent-readiness/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Rozpocznij assessment &rarr;</a>
</div>

<!-- Katalog agentów HR -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex flex-col md:flex-row items-start gap-8">
<div class="flex-1">
<h2 class="text-h2 font-bold text-gosign-dark">Katalog agentów HR: 48 agentów ocenionych i priorytetyzowanych</h2>
<p class="text-body-lg text-gosign-text mt-4">Jakie agenty HR istnieją, jakiego governance potrzebują i w jakiej kolejności powinno się zacząć? Katalog ocenia 48 agentów w 6 wymiarach - od Agent Readiness po klasyfikację EU AI Act.</p>
<p class="text-body text-gosign-text-light mt-3">11 domen, 3 interaktywne kwadranty priorytetyzacji, tabele mikro-decyzji dla każdego agenta.</p>
<a href="/pl/katalog-agentow-hr/" class="inline-flex items-center gap-2 mt-4 text-body font-semibold text-gosign-accent hover:underline">Do katalogu agentów HR &rarr;</a>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white"><div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8"><h2 class="text-h2 font-bold text-gosign-dark mb-8">Pogłębienie w Agent Briefing (Magazyn Gosign)</h2><div class="grid md:grid-cols-3 gap-6"><a href="/pl/magazyn/rada-zakladowa-ai-literacy/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors"><p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p><h3 class="text-h3 font-bold text-gosign-dark">Rada pracowników & AI Literacy</h3></a><a href="/pl/magazyn/decision-layer-shadow-ai/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors"><p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p><h3 class="text-h3 font-bold text-gosign-dark">Decision Layer & Shadow AI</h3></a><a href="/pl/magazyn/eu-ai-act-2026-przedsiebiorstwa/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors"><p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p><h3 class="text-h3 font-bold text-gosign-dark">EU AI Act 2026</h3></a></div></div></section>

--- Agent dekretacji ---
> Przypisuje faktury przychodzące do właściwego konta księgowego (SKR03/04 lub indywidualnego), centrum kosztów i prawidłowego kodu podatkowego.

## Błędna dekretacja kosztuje przy każdej kontroli podatkowej pięciocyfrowe kwoty

Małe i średnie przedsiębiorstwa po kontroli podatkowej doplacają średnio 24 000 EUR (26 000 USD). Przy szczególnych kontrolach VAT wartość ta rośnie do około 25 000 EUR (27 000 USD) na jedno przedsiębiorstwo. W ponad połowie wszystkich kontroli dochodzi do dopłat. Najczęstsza przyczyna: błędna dekretacja. Niewłaściwe konto księgowe oznacza błędne wykazanie podatku. Błędne wykazanie podatku oznacza odmowę odliczenia VAT naliczonego. Odmowa odliczenia VAT naliczonego za kilka lat szybko sumuje się do kwot sześciocyfrowych.

Problem nie leży w niedbalstwie. Przedsiębiorstwo z 10 000 faktur przychodzących miesięcznie podejmuje 10 000 decyzji dekretacyjnych - każdego miesiąca. Przy ręcznym przetwarzaniu wskaźnik błędów według Institute of Finance and Management (IOFM) wynosi około 2 procent. To 200 faktur miesięcznie, w których konto księgowe, centrum kosztów lub kod podatkowy są niepoprawne. Każda z nich jest ustaleniem, które kontroler podatkowy może podnieść.

## Dziesięć decyzji na jedną fakturę - każda z konsekwencjami podatkowymi

Dekretacja jest często traktowana jako krok rejestracyjny. W rzeczywistości jest to łańcuch dziesięciu pojedynczych decyzji, z których każda wywołuje odmienne konsekwencje prawne.

Przykład z codzienności: wpływa faktura za usługi doradcze od dostawcy z UE. Księgowość musi zdecydować: które konto księgowe? Które centrum kosztów? Które centrum zysku? Reverse Charge według Paragraph 13b UStG czy zwykły VAT? Czy odliczenie podatku naliczonego jest dopuszczalne? Czy kwota przekracza próg GWG? Czy konieczne jest rozliczenie międzyokresowe? Dopiero gdy wszystkie decyzje cząstkowe są prawidłowe, zapis księgowy jest poprawny.

Każda z tych decyzji podlega własnej logice. Przypisanie konta księgowego wynika z opisu świadczenia i planu kont. Kod podatkowy wynika z UStG. Obowiązek aktywowania wynika z HGB i EStG. Kto traktuje decyzję w izolacji, przeocza wzajemne powiązania. Kto podejmuje je jako całość ręcznie, potrzebuje doświadczenia, koncentracji i czasu - przy każdej pojedynczej fakturze.

## Dekretacja regułowa, eskalacja tylko przypadków interpretacyjnych

[Decision Layer](/pl/decision-layer/) rozkłada każdy proces dekretacji na te dziesięć kroków decyzyjnych i definiuje dla każdego: reguła, AI czy człowiek. Przy dekretacji rozkład jest wyraźny. Dziewięć z dziesięciu kroków da się rozwiązać regułowo. Określenie kodu podatkowego według UStG, sprawdzenie odliczenia VAT naliczonego według Paragraph 15, progi GWG według EStG Paragraph 6 ust. 2, rozliczenia międzyokresowe według HGB Paragraph 250 - to decyzje deterministyczne z jednoznacznym wynikiem.

Jeden krok wymagający wsparcia AI to interpretacja. Gdy opis świadczenia na fakturze brzmi "Wsparcie projektowe H3", a plan kont zna 15 możliwych kont księgowych, sama reguła nie wystarczy. Tutaj model językowy na podstawie historycznych dekretacji ocenia, które konto pasuje - i wystawia Confidence Score. Jeśli wskaźnik jest poniżej zdefiniowanego progu, agent eskaluje do pracownika. Jeśli powyżej, księguje automatycznie.

Rezultat: księgowość nie obsługuje już 10 000 faktur. Obsługuje 300, przy których agent nie jest wystarczająco pewny. Reszta przechodzi automatycznie - zweryfikowana, zadekretowana, udokumentowana.

## Każda dekretacja staje się dowodem dla kontroli

Kontroler podatkowy nie pyta, czy dekretacja jest poprawna. Pyta, dlaczego została podjęta tak, a nie inaczej. Właśnie tu leży słaby punkt ręcznej księgowości: uzasadnienie istnieje tylko w głowie pracownika, który przetwarzał fakturę osiem miesięcy temu.

Agent dokumentuje dla każdej dekretacji pełną ścieżkę decyzyjną: zastosowane konto księgowe z uzasadnieniem, kod podatkowy z referencją do UStG, centrum kosztów, Confidence Score oraz informację, czy decyzja została podjęta automatycznie czy ręcznie. Odpowiada to wymogom dokumentacji procedur zgodnej z niemieckim standardem GoBD (niemiecki standard dokumentacji) (niemiecki standard dokumentacji) oraz polską Ordynacją podatkową (Art. 86 OP). Kontroler nie widzi tylko wyniku. Widzi drogę do niego - dla każdej ze 120 000 faktur w roku.

## Silnik planu kont jako fundament dla wszystkich agentów księgujących

Dekretacja to pierwszy krok w księgowości zobowiązań, ale nie jedyny. Koszty podróży, dokumenty gastronomiczne, przyjęcia środków trwałych, rezerwy, rozliczenia międzyokresowe - każdy z tych procesów wymaga tej samej podstawowej logiki: świadczenie do konta księgowego do kodu podatkowego. Kto zbuduje to przypisanie czysto dla dekretacji, buduje infrastrukturę dla każdego kolejnego agenta księgującego.

Framework mapowania, z którego korzysta agent dekretacji, staje się standardowym elementem budowy. Ocena pewności oraz wzorzec eskalacji - automatyczne księgowanie albo przekazanie do człowieka - stają się wzorcem. Nie każdy agent Finance musi odpowiadać na nowo na pytanie, jak obsługuje niepewność. Agent dekretacji odpowiada na nie raz, a wszyscy pozostali budują na tym.

--- Agent rozliczeń międzyokresowych ---
> Identyfikuje aktywne i bierne rozliczenia międzyokresowe z płatności i okresów świadczenia, oblicza kwoty proporcjonalne.

Gdy zamknięcie miesiąca dostarcza zniekształconego wyniku okresowego, zarząd podejmuje decyzje na błędnych podstawach. Najczęstsza przyczyna: brakujące lub błędne rozliczenia międzyokresowe. 94 procent zespołów finansowych nadal przygotowuje rozliczenia w arkuszach kalkulacyjnych - a połowa z nich potrzebuje więcej niż sześciu dni roboczych na całe zamknięcie miesiąca. Tymczasem rozliczenia międzyokresowe w swej istocie nie są kwestią uznaniową. To arytmetyka z kalendarzem.

## Każdy zapomniany ARAP zniekształca podstawę sterowania

Roczna składka ubezpieczeniowa w wysokości 120 000 EUR (130 000 USD) jest płatna w styczniu. Bez rozliczenia 120 000 EUR obciąża wynik stycznia, podczas gdy luty do grudnia wyglądają zbyt korzystnie. Pomnożone przez dziesiątki takich pozycji - licencji na oprogramowanie, umów serwisowych, przedpłaconych czynszów - powstaje wynik miesięczny, który mówi więcej o momentach płatności niż o rzeczywistym rozwoju biznesu.

Konsekwencje sięgają dalej niż optyka bilansu. Błędne wyniki okresowe zniekształcają prognozy, fałszują analizy odchyleń i podkopują zaufanie biegłych rewidentów oraz rad nadzorczych. Według analizy Center for Audit Quality błędne rozliczenia międzyokresowe, rezerwy i szacunki są najczęściej wskazywaną przyczyną korekt sprawozdań finansowych (Financial Restatements). Każda korekta kosztuje nie tylko pieniądze, ale przede wszystkim wiarygodność.

## Osiem z dziesięciu kroków decyzyjnych to czysta arytmetyka

[Decision Layer](/pl/decision-layer/) rozkłada każdy proces rozliczeniowy na dziesięć kroków decyzyjnych. Osiem z nich jest w pełni regułowych: czy występuje przedpłata (ARAP)? Czy przed dniem bilansowym wpłynął przychód okresu następnego (PRAP)? Czy chodzi o rezerwę, czy o rozliczenie międzyokresowe? Do którego okresu koszt przynależy ekonomicznie? Jaka jest kwota proporcjonalna? Czy ujęta kwota jest wyceniona ostrożnie? Jaki zapis księgowy do niej pasuje? I kiedy dokładnie następuje rozwiązanie?

Żaden z tych kroków nie wymaga osądu ludzkiego. Porównanie dat między momentem płatności a okresem świadczenia jest jednoznaczne. Proporcjonalne obliczenie podlega stałej formule. Logika księgowa według ARAP lub PRAP jest zdefiniowana w każdym planie kont. A kontrzapis w następnym miesiącu jest automatyczną konsekwencją pierwotnego zapisu.

Właśnie to czyni agenta rozliczeń międzyokresowych przykładem wzorcowym automatyzacji w księdze głównej: wysoki wolumen, niska złożoność, zero miejsca na uznanie. Dokumentacja zgodna z niemieckim standardem GoBD (niemiecki standard dokumentacji) oraz polską Ordynacją podatkową (Art. 86 OP) - podstawa, okres świadczenia, sposób obliczenia, moment rozwiązania - powstaje jako efekt uboczny każdego zapisu, nie jako późniejszy obowiązek.

## Dwa kroki pokazują, gdzie AI robi różnicę

Właściwa słabość ręcznych rozliczeń nie leży w obliczeniu. Leży w rozpoznaniu. Kto zidentyfikuje nową umowę ramową z płatnością kwartalną i miesięcznym okresem świadczenia? Kto znajdzie grudniową fakturę, której okres świadczenia biegnie do marca?

Dwa z dziesięciu kroków decyzyjnych wykorzystują AI: oszacowanie kwoty rozliczenia, gdy nie ma jeszcze kwoty faktury, oraz rozpoznawanie stanów międzyokresowych w umowach i fakturach. Agent przeszukuje nowe umowy pod kątem okresów świadczenia, porównuje dane fakturowe z okresami obowiązywania umów i identyfikuje stany wymagające rozliczenia - zanim zabraknie ich w zamknięciu miesiąca. To rozpoznawanie jest powodem, dla którego agent pracuje nie tylko szybciej niż człowiek, ale też pełniej.

Ingerencja ludzka pozostaje tam, gdzie powinna: przy weryfikacji przez biegłego rewidenta. Każde pojedyncze rozliczenie - regułowe czy rozpoznane przez AI - jest audytowalne i możliwe do zakwestionowania.

## Konkretny efekt: zamknięcie miesiąca traci swoje wąskie gardło

Przedsiębiorstwo przemysłowe z 200 aktywnymi pozycjami rozliczeniowymi miesięcznie - licencjami na oprogramowanie, ubezpieczeniami, ratami leasingowymi, umowami serwisowymi, przedpłaconymi usługami - wiąże typowo dwa do trzech osobodni wyłącznie na rozliczenia międzyokresowe. Listy Excel z okresami świadczenia, ręczne zapisy, kontrola rozwiązań z poprzedniego miesiąca.

Agent redukuje ten nakład do weryfikacji wyjątków. Powtarzające się rozliczenia są automatycznie tworzone i rozwiązywane. Nowe stany są rozpoznawane i przedstawiane do zatwierdzenia. Dokumentacja jest od razu gotowa do audytu. Pozostaje lista zatwierdzeń zamiast listy tworzenia.

Infrastruktura okresowania, którą buduje agent, działa poza własnym procesem. Logika rozwiązywania jest wykorzystywana przez agenta rezerw. Rozpoznawanie stanów międzyokresowych dostarcza danych wejściowych dla agenta księgowości leasingowej i agenta zgodności umów. Rozliczenia międzyokresowe nie są najbardziej spektakularnym procesem w rachunkowości. Ale są podstawą, na której stoją wszystkie pozostałe wyniki okresowe.

--- Agent przygotowania sprawozdania rocznego ---
> Orkiestruje listę kontrolną sprawozdania rocznego, konsoliduje uzgodnienia, sprawdza prawa wyboru wyceny.

Żadne sprawozdanie roczne nie upada z powodu braku kompetencji merytorycznej. Upada przez orkiestrację - przez uzgodnienia, które nie zostają zamknięte na czas, przez zapytania do wykazu środków trwałych zalegające trzy dni w skrzynce, przez informacje do załącznika powstające w ostatniej chwili. Zespół finansowy zna każdy pojedynczy krok - a mimo to traci tygodnie na koordynację między tymi krokami.

## Tygodnie zamknięcia wiążą cały zespół pracą rutynową

Według APQC Open Standards Benchmarking mediana zamknięcia miesięcznego mieści się międzybranżowo w wyższym jednocyfrowym zakresie dni - większość zespołów finansowych potrzebuje dłużej niż pięć dni roboczych na samo zamknięcie miesiąca. Sprawozdanie roczne mnoży ten nakład pracy - dochodzą wykaz środków trwałych, wykaz rezerw, wykaz kapitału własnego, rachunek przepływów pieniężnych, podatkowe zestawienie przejścia, załącznik, sprawozdanie z działalności, dokumentacja dla biegłego rewidenta i ujawnienie.

Konkretny scenariusz ilustruje problem. Średniej wielkości przedsiębiorstwo przemysłowe o przychodach 200 milionów EUR zamyka rok obrotowy. Dyrektor finansowy koordynuje przez cztery tygodnie zespół sześciu osób. Trzy z nich spędzają większość czasu na tworzeniu wykazów - czyli na arytmetycznych zestawieniach danych, które już istnieją w systemie. Jedna osoba kompletuje dokumenty dla biegłego rewidenta. Decyzje wycenowe - właściwa praca merytoryczna - wypełniają może 20 procent całkowitego czasu zamknięcia.

Jednocześnie za opóźnione ujawnienie grożą kary porządkowe. Ustawa o rachunkowości (odpowiednik niemieckiego HGB) wymaga terminowego złożenia sprawozdań. W praktyce polskich spółek kapitałowych kary za nieterminowe złożenie dokumentów do KRS mogą sięgać tysięcy złotych - a w przypadku spółek giełdowych na szali stoi też reputacja.

## Piętnaście kroków decyzyjnych oddziela rutynę od uznania

[Decision Layer](/pl/decision-layer/) rozkłada cały proces sprawozdania rocznego na piętnaście pojedynczych kroków decyzyjnych - i przypisuje każdy do jasno określonego poziomu. Wynikiem jest mapa pokazująca, gdzie automatyzacja ma sens, a gdzie wymagany jest ludzki osąd.

Poziom 1 (silnik reguł) obejmuje dziewięć kroków: listę kontrolną zamknięcia, konsolidację uzgodnień, podatkowe zestawienie przejścia w standardowych przypadkach, obliczenie podatku odroczonego na podstawie różnic temporalnych, przygotowanie ujawnienia oraz cztery wykazy (rezerw, środków trwałych, kapitału własnego, przepływów pieniężnych). To wszystko opiera się na zdefiniowanych regułach i istniejących danych.

Poziom 2 (projekt AI z ludzkim zatwierdzeniem) obejmuje trzy kroki: projekt not do załącznika na podstawie wymogów Ustawy o rachunkowości, projekt sprawozdania z działalności oraz przygotowanie dokumentacji dla biegłego rewidenta według listy PBC. Agent tworzy ustrukturyzowane projekty - odpowiedzialność merytoryczna pozostaje przy zespole.

Trzy kroki pozostają wyłącznie przy człowieku: prawa wyboru wyceny (decyzja polityki bilansowej), weryfikacja zdarzeń po dniu bilansowym (ocena istotności) oraz oświadczenie bilansowe (osobiste poświadczenie przez zarząd). Żadna automatyzacja nie zastąpi uznania, którego te kroki wymagają.

## Agent orkiestruje - człowiek decyduje

Co zmienia się w praktyce? Agent przejmuje taktowanie. Sprawdza, czy wszystkie uzgodnienia są zakończone, zanim uruchomi kolejny krok. Tworzy cztery wykazy bezpośrednio z wyników wcześniejszych agentów. Przygotowuje informacje do załącznika jako ustrukturyzowany projekt, który zespół poprawia zamiast pisać od podstaw. Kompletuje pakiet dla biegłego rewidenta według listy PBC.

Zespół przenosi swój czas - od koordynacji ku decyzjom wycenowym. Pytanie nie brzmi już "Czy mamy gotowy wykaz środków trwałych?", lecz "Jaką metodę wyceny stosujemy przy rezerwach na świadczenia emerytalne?" - pytanie, za które CFO faktycznie dostaje wynagrodzenie.

Dla biegłego rewidenta powstaje efekt uboczny: każdy krok decyzyjny jest udokumentowany, każde źródło danych odtwarzalne. Badanie nie staje się łatwiejsze w sensie mniej rygorystyczne - ale zaczyna się od kompletnej, ustrukturyzowanej podstawy.

## Każdy wcześniejszy agent poprawia jakość sprawozdania

Agent sprawozdania rocznego nie jest izolowanym narzędziem. Jest punktem integracji całej infrastruktury Finance. Wykaz środków trwałych czerpie z Agenta amortyzacji. Wykaz rezerw sięga po Agenta rezerw. Uzgodnienie kont dostarcza Agent uzgodnień, dane podatkowe Agent VAT, odpisy aktualizujące Agent zarządzania należnościami.

To oznacza: kto prowadzi wcześniejsze agenty w sposób uporządkowany, ma przy sprawozdaniu rocznym automatycznie lepsze dane. Kto definiuje sprawozdanie roczne jako cel, buduje całą infrastrukturę agentów wstecz od tego punktu. Sprawozdanie roczne nie jest początkiem - jest dowodem, że infrastruktura działa.

--- Agent przychodów środków trwałych ---
> Identyfikuje środki trwałe podlegające aktywowaniu z faktur, określa koszty nabycia i wytworzenia wg HGB Paragraph 255.

Błędne decyzje o aktywowaniu należą do najkosztowniejszych, a jednocześnie możliwych do uniknięcia błędów w księgowości środków trwałych. Kto dobro inwestycyjne zaksięguje jako koszt bieżący, zaniża wynik w niewłaściwym roku. Kto wydatek bieżący aktywuje, zawyża sumę bilansową. W obu przypadkach amortyzacja, obciążenie podatkowe i wykaz środków trwałych nie zgadzają się przez lata. Agent przychodów środków trwałych zapobiega dokładnie tej błędnej alokacji - nie przez automatyzację całej księgowości, lecz przez ustrukturyzowany rozkład każdej pojedynczej decyzji o aktywowaniu.

## Co trzecia kontrola podatkowa kwestionuje majątek trwały

Liczby są jednoznaczne. Według badania PwC co drugie niemieckie przedsiębiorstwo musi po kontroli podatkowej dopłacić podatki. W 29 procentach przypadków zastrzeżenia dotyczą bilansowania majątku trwałego (źródło: PwC, "Betriebsprufung", 2024). Najczęstsza przyczyna: środki trwałe zostały błędnie sklasyfikowane, koszty dodatkowe nabycia niewłaściwie przypisane lub okresy użytkowania ustalone bez odtwarzalnego uzasadnienia.

Niemieckie Ministerstwo Finansów określa dodatkowy wynik wszystkich kontroli podatkowych w 2024 roku na 10,9 miliarda EUR ze 140 764 skontrolowanych firm (BMF, raport miesięczny, listopad 2025). Znaczna część przypada na korekty w majątku trwałym - ponieważ pierwotna decyzja o aktywowaniu nie była udokumentowana lub opierała się na błędnych założeniach.

Dla CFO oznacza to: decyzja o aktywowaniu nie jest szczegółem księgowym. Jest ryzykiem kontrolnym z mierzalnymi konsekwencjami finansowymi.

## Decyzja o aktywowaniu zapada w sekundach - a działa przez lata

Typowy tydzień w księgowości zobowiązań średniej wielkości firmy: 40 faktur przychodzących, z czego sześć powyżej 800 EUR netto. Każda z tych faktur wymaga tej samej sekwencji decyzji. Czy to środek trwały, czy bieżąca usługa? Czy kwota przekracza próg GWG? Jaka klasa środka? Jaki okres użytkowania według tabeli AfA? Czy koszty transportu należą do kosztów dodatkowych nabycia?

Pracownik podejmuje te decyzje często w minuty - pod presją czasu, z niekompletnymi informacjami, czasem opierając się na doświadczeniu zamiast na aktualnej tabeli BMF. Konsekwencja ujawnia się dopiero lata później: przy inwentaryzacji, gdy fizyczne środki trwałe i wykaz nie pasują do siebie. Albo przy kontroli podatkowej, gdy kontroler kwestionuje okres użytkowania maszyny specjalnej i nie znajduje żadnej dokumentacji.

Źródło błędów nie leży w braku kompetencji. Leży w strukturze: każda decyzja o aktywowaniu zawiera elementy deterministyczne (próg, klasa środka, obliczenie kosztów nabycia) i margines uznaniowy (okres użytkowania przy urządzeniach specjalnych, rozgraniczenie złożonych środków trwałych). Gdy oba łączą się w jednym ręcznym kroku, brakuje odtwarzalności.

## Dziewięć kroków decyzyjnych oddziela silnik reguł od uznania

[Decision Layer](/pl/decision-layer/) rozkłada przychód środka trwałego na dziewięć dyskretnych kroków. Każdy krok ma zdefiniowanego decydenta: silnik reguł, model AI lub człowiek.

Identyfikacja środka trwałego z opisu na fakturze wykorzystuje model językowy. Faktura za "montaż i uruchomienie linii produkcyjnej hala 7" nie zawiera numeru EAN ani danych podstawowych - ale wystarczający kontekst, by rozpoznać środek trwały.

Weryfikacja obowiązku aktywowania jest czysto regułowa: kwota netto powyżej 800 EUR (odpowiednik progu w niemieckim EStG), więc obowiązek aktywowania. Poniżej - traktowanie jako GWG lub pozycja zbiorcza. To samo dotyczy określenia kosztów nabycia według Ustawy o rachunkowości (odpowiednik HGB Paragraph 255), nadania numeru inwentarzowego i rejestracji w wykazie. Te kroki są deterministyczne. Nie korzystają na ludzkim uznaniu, lecz na spójności i kompletności.

Inaczej przy przypadkach granicznych: przypisanie frezarki CNC z wyposażeniem specjalnym do właściwej klasy środka może być przygotowane regułowo, ale nie rozstrzygnięte ostatecznie. Okres użytkowania maszyny specjalnej nie stoi w tabeli AfA BMF. Tu decyduje człowiek - ale na podstawie wstępnie ustrukturyzowanej propozycji, nie na pustej kartce.

## Człowiek decyduje tam, gdzie potrzebne jest uznanie

Agent przychodów środków trwałych operuje na poziomach 1 i 2 Decision Layer. Oznacza to: kroki regułowe biegną automatycznie z protokołem. Kroki wspierane przez AI dostarczają propozycje ze wskaźnikiem pewności. Żaden krok nie zmienia bilansu bez udokumentowanej podstawy decyzyjnej.

Konkretnie: gdy agent przetwarza fakturę na 12 000 EUR za wagę laboratoryjną, weryfikacja aktywowania przebiega regułowo. Klasa "urządzenia techniczne i maszyny" jest przypisywana regułowo. Okres użytkowania 10 lat pochodzi z tabeli BMF, źródło udokumentowane. Koszty dodatkowe nabycia za kalibrację i montaż są doliczane do kosztów nabycia - Ustawa o rachunkowości.

Dla kontroli podatkowej powstaje tym samym kompletna ścieżka decyzyjna: dlaczego aktywowano, jak sklasyfikowano, jakie składniki kosztów nabycia, jaki okres użytkowania z jaką podstawą prawną. Ta dokumentacja nie powstaje wstecznie dla kontrolera. Powstaje jako naturalny produkt uboczny każdej pojedynczej decyzji o aktywowaniu.

To nie redukuje odpowiedzialności CFO za prawidłowość bilansu. Daje mu podstawę, by tę odpowiedzialność realizować w sposób świadomy - zamiast ufać, że w księgowości zobowiązań nikomu nie przydarzył się błąd.

--- Agent inwentaryzacji ---
> Generuje listy inwentaryzacyjne, uzgadnia stan docelowy i rzeczywisty, identyfikuje braki i przygotowuje zapisy korygujące.

Od 10 do 30 procent wszystkich wpisów w rejestrach środków trwałych to tak zwane Ghost Assets - środki, które istnieją już tylko na papierze (źródło: CPCON Group, Fixed Asset Register Guide 2026). Roczna inwentaryzacja zgodnie z Ustawą o rachunkowości (odpowiednik niemieckiego HGB Paragraph 240) ma temu dokładnie zapobiegać. W praktyce często zawodzi sam proces: ręczne liczenie w wielu lokalizacjach, uzgadnianie w Excelu, tygodnie pracy poprawkowej. Agent inwentaryzacji rozwiązuje ten problem, przejmując regułową część inwentaryzacji w całości i zatrzymując się tylko tam, gdzie wymagany jest ludzki osąd.

## Co trzeci środek trwały w rejestrze istnieje tylko na papierze

Ghost Assets powstają stopniowo. Drukarka zostaje wymieniona, ale rozchód nie zaksięgowany. Maszyna zostaje przeniesiona do innej lokalizacji bez aktualizacji danych podstawowych. Po pięciu latach bez fizycznej weryfikacji rejestr środków trwałych oddalił się od rzeczywistości na tyle, że inwentaryzacja staje się projektem porządkowym. Konsekwencje są mierzalne: zawyżone składki ubezpieczeniowe kalkulowane na podstawie zawyżonych wartości księgowych. Niepotrzebna amortyzacja środków, które dawno zostały zutylizowane. W najgorszym przypadku - zastrzeżenie biegłego rewidenta, ponieważ różnica między rejestrem a rzeczywistością jest nieakceptowalna.

## Ręczna inwentaryzacja nie skaluje się na wiele lokalizacji

Średniej wielkości producent maszyn z czterema zakładami produkcyjnymi i 8 000 środkami trwałymi zna ten schemat. Trzy tygodnie przed dniem bilansowym zaczyna się koordynacja. Zespoły inwentaryzacyjne są przydzielane, listy liczeniowe drukowane, skanery rozdzielane. Każda lokalizacja liczy we własnym rytmie. Wyniki wracają mailem - jako pliki Excela w różnych formatach. Centralne scalenie trwa kolejne dwa tygodnie. Braki stają się widoczne dopiero późno, przeliczenia opóźniają zamknięcie. Efekt: inwentaryzacja pochłania cztery do sześciu tygodni czasu pracy, a mimo to pozostają wątpliwości co do kompletności.

## Agent oddziela liczenie od wyceny

[Decision Layer](/pl/decision-layer/) dzieli inwentaryzację środków trwałych na dwie kategorie decyzji. Kroki regułowe - generowanie listy inwentaryzacyjnej z ERP, rejestracja stanu rzeczywistego, porównanie stanu docelowego z rzeczywistym, identyfikacja braków, przygotowanie zapisów korygujących - biegną automatycznie. Agent porównuje stan księgowy ze stanem fizycznym i tworzy listy różnic per lokalizacja, centrum kosztów i klasa środka.

Dwie decyzje pozostają przy człowieku: czy środek stracił na wartości? Czy powinien zostać zlikwidowany? Te pytania wycenowe wymagają oględzin i uznania. Agent dostarcza podstawę decyzyjną - wiek, okres użytkowania, stan według ostatniej rejestracji - ale zatwierdzenie leży po stronie działu merytorycznego. Dzięki temu proces pozostaje zgodny z wymogami audytu według Ustawy o rachunkowości, bez wiązania ludzkiej zdolności pracą liczeniową.

## Rejestracja RFID podnosi dokładność powyżej 95 procent

Ręczna inwentaryzacja ze skanerami kodów kreskowych osiąga typowo dokładność 85 do 95 procent. Rejestracja RFID dodatkowo zwiększa dokładność i znacząco skraca czas rejestracji. Agent inwentaryzacji korzysta z obu technologii: gdzie dostępne są tagi RFID, rejestruje stan rzeczywisty pomieszczenia w sekundy zamiast godzin. Gdzie dostępne są tylko kody kreskowe, orkiestruje ręczną rejestrację z listami per lokalizacja i podglądem postępu w czasie rzeczywistym. Inwestycja w infrastrukturę RFID zwraca się w praktyce w ciągu kilku lat - nie tylko dzięki szybszej inwentaryzacji, lecz także dzięki lepszemu śledzeniu lokalizacji w codziennej działalności.

## Zapisy korygujące są gotowe w dniu inwentaryzacji

Właściwym celem inwentaryzacji nie jest liczenie, lecz oczyszczony rejestr środków trwałych. Agent inwentaryzacji przygotowuje zapisy korygujące natychmiast po potwierdzeniu odchylenia: rozchody dla nieodnalezionych środków, pozaplanowa amortyzacja dla środków z utratą wartości, korekty lokalizacji dla przeniesionych środków. Na końcu stoi raport inwentaryzacyjny dokumentujący cały proces - od listy docelowej przez rejestrację stanu rzeczywistego po zatwierdzenie każdej pojedynczej korekty. Biegły rewident otrzymuje nie tylko wynik, lecz kompletną ścieżkę decyzyjną. To przyspiesza badanie i redukuje zapytania do tego, co istotne.

--- Agent uzgodnienia bankowego ---
> Automatyczne uzgodnienie sald: parsowanie wyciągów CAMT.053 i MT940, integracja Open Banking PSD2 oraz kontrola zgodności z JPK_KR i UoR.

Polskie uzgodnienie bankowe to fundament rzetelności sprawozdania finansowego, obwarowany wielowarstwową regulacją księgową, podatkową i AML. Ustawa o rachunkowości art. 26 ust. 1 pkt 2 wymaga inwentaryzacji środków pieniężnych na rachunkach bankowych poprzez uzyskanie potwierdzenia salda od banku na ostatni dzień roku obrotowego - rozbieżność = zapis w dzienniku różnic inwentaryzacyjnych (UoR art. 27). UoR art. 24 ustanawia niezmienialność zapisu - korekty wyłącznie przez storno czerwone (UoR art. 25). KKS art. 56 sankcjonuje narażenie podatku na uszczuplenie kara grzywny do 720 stawek dziennych (21,6 mln zł) lub pozbawieniem wolności do lat 5 - nieuzgodnione salda są bezpośrednim sygnałem dla KAS o nierzetelności ksiąg. Polish Open Banking API (PSD2 AISP - Ustawa z 19.08.2011 o usługach płatniczych art. 59h) udostępnia wyciągi CAMT.053 ISO 20022 i MT940 SWIFT z PKO BP, mBank, ING, Pekao, Santander, Millennium, Alior. JPK_KR (Rozporządzenie MF z 14.10.2015) i JPK_V7M (Ustawa o VAT art. 99) wymagają miesięcznej spójności wyciągu z dziennikiem księgowym - kontrolerzy KAS porównują krzyżowo. BLIK incoming, Express Elixir 24/7, SORBNET2 NBP i SWIFT MT103 to różne typy wyciągów z różnymi kodami GVC.

## Cena nieuzgodnionego salda: grzywna KKS art. 56 do 21,6 mln zł, odmowa zwrotu VAT i utrata wiarygodności sprawozdania

Niewłaściwe uzgodnienie bankowe w Polsce generuje pasywo na czterech frontach jednocześnie. Kodeks Karny Skarbowy art. 56 (narażenie podatku na uszczuplenie) - kara grzywny do 720 stawek dziennych przy stawce maksymalnej 30.000 zł = 21,6 mln zł, w skrajnych przypadkach pozbawienie wolności do lat 5. Plus KKS art. 60 (nieprowadzenie ksiąg) - kara do 240 stawek dziennych (7,2 mln zł), KKS art. 61 (wadliwe prowadzenie ksiąg) - kara do 120 stawek dziennych (3,6 mln zł). Łącznie ryzyko karne >32 mln zł dla nierzetelnych ksiąg z nieuzgodnionymi saldami.

Drugi front: KAS odmowa zwrotu VAT z faktur zakupu. Ustawa o VAT art. 86 wymaga prawidłowej dokumentacji odliczenia - jeśli wpływ na wyciągu nie ma odpowiednika w JPK_V7M jako sprzedaż lub jeśli wypływ za fakturę zakupu nie powiązany z numerem KSeF FA(2), KAS może odmówić zwrotu VAT z miesięcznej deklaracji. Dla firmy z 200 mln zł obrotu i VAT należnym 46 mln zł rocznie blokada zwrotu nawet 1 mln zł generuje straty płynnościowe (cash flow gap), koszty finansowania (WIBOR 3M powiększony o marżę, typowo 8-12% rocznie) i postępowanie odwoławcze trwające 6-18 miesięcy.

Trzeci front: Inwentaryzacja sald na 31.12 (UoR art. 26-27). Brak potwierdzenia salda przez bank lub niewyjaśnione różnice = sygnał dla biegłego rewidenta z PIBR przy badaniu ustawowym sprawozdania finansowego. Krajowy Standard Rewizji Finansowej 505 (potwierdzenia od osób trzecich) wymaga niezależnej weryfikacji - opinia z zastrzeżeniem lub odmowa wydania opinii blokuje publikację sprawozdania, opóźnia walne zgromadzenie i może wymagać korekty CIT-8 (sankcja 30% przy zaniżeniu zobowiązania - art. 56 KKS).

Czwarty front: AML/CFT do 5 mln zł (Ustawa z 1.03.2018 art. 147). Brak screeningu sankcji UE/OFAC/ONZ/GIIF na wpływach >15.000 EUR i brak raportowania STR do GIIF generuje sankcję administracyjną do 5 mln zł lub 10% obrotu rocznego (dla 200 mln zł obrotu = 20 mln zł). Plus odpowiedzialność karna art. 74 do 12 lat pozbawienia wolności za świadome obejście sankcji.

## Polskie uzgodnienie bankowe przechodzi 13 deterministycznych etapów - mniej niż przebiegi płatności (16) ale więcej niż w Niemczech (7) lub UK (8)

Polski system uzgadniania bankowego należy do najbardziej rozbudowanych w UE: UoR 1994 (inwentaryzacja, niezmienialność, storno), JPK_KR 2015 (struktura miesięczna), JPK_V7M 2016 (krzyżowe z VAT), KSeF 2026 (powiązanie z FA(2)), Polish Open Banking 2019 (PSD2 AISP), Ustawa AML 2018 (raportowanie GIIF), plus odmienności (kurs NBP fixing dla wycen walutowych nie ma odpowiednika w UE) i struktura instytucjonalna (KIR z ELIXIR/Express Elixir, NBP z SORBNET2, PSP z BLIK, ZBP z profilem MT940 polskim, GIIF z AML, PIBR z badaniem ustawowym). 13 deterministycznych etapów: pobranie CAMT.053 przez Polish Open Banking, parsowanie wg ZBP/SWIFT, identyfikacja typu transakcji (kod GVC/BankTransactionCode), powiązanie po KSeF FA(2), dokładne dopasowanie po kwocie i NIPie, BLIK incoming po polu :86:, wzorzec cykliczny LLM, dekretacja opłat wg ZPK, dekretacja odsetek po stronach Wn/Ma, przeliczenie NBP fixing wg UoR art. 30, powiązanie z JPK_KR, inwentaryzacja sald wg UoR art. 26-27, eskalacja, screening AML, archiwizacja z hashem SHA-256.

Scenariusz: zakład produkcyjny w Tychach z 6 rachunkami bankowymi (Pekao główny, PKO BP rachunek VAT, ING dewizowy EUR, mBank dewizowy USD, Santander backup, Millennium gotówkowy), 200 transakcjami dziennie (4.000 miesięcznie). W poniedziałek o 6:30 Agent pobiera 6 wyciągów CAMT.053 przez Polish Open Banking API (cały proces 90 sekund: 6 banków × 15 sek), parsuje 850 transakcji weekendowych, identyfikuje typy (480 ELIXIR krajowych, 95 Express Elixir instant, 25 SORBNET2 wysokokwotowe, 65 SWIFT MT103 zagraniczne, 120 BLIK incoming mikro, 65 opłat bankowych). Powiązuje 730 transakcji z fakturami KSeF FA(2) deterministycznie (po kwocie, NIPie i numerze KSeF), 80 przez wzorzec cykliczny LLM (czynsze Skanska, leasingi LeasePlan, abonamenty Comarch), 25 eskalacji do księgowego (brak referencji i brak NIPu). Dekretacja 65 opłat bankowych (75-2 koszty finansowe, 40-2 usługi obce wg ZPK), 12 odsetek (75-1 przychody, 75-2 koszty), przeliczenie 90 transakcji walutowych po NBP fixing z piątku. Screening AML dla 8 wpływów >15.000 EUR - 0 trafień. O 8:30 protokół uzgodnienia gotowy z hashem SHA-256, eskalacje w queue dla głównego księgowego z SLA 24h.

W [Decision Layer](/pl/decision-layer/) z 13 etapów 11 to decyzje regułowe (R), 1 LLM (A - wzorzec cykliczny), 1 decyzja człowieka (H - eskalacja nieprzypisanych pozycji). Każda decyzja regułowa to zastosowanie UoR, Ordynacji podatkowej, KKS lub specyfikacji ZBP/SWIFT/NBP.

## Kontrola wiarygodności przed zaksięgowaniem: dopasowanie KSeF FA(2), dekretacja ZPK i spójność JPK_KR

Trzy etapy walidacyjne wykonywane przed zatwierdzeniem zapisu - każdy może zatrzymać uzgodnienie. (1) Powiązanie po numerze KSeF FA(2): wyrażenie regularne wykrywające 32-znakowy identyfikator w tytule przelewu lub kombinacja numeru faktury z NIPem nadawcy. Jeśli match jednoznaczny, faktura wymagalna z KSeF zostaje rozliczona (status 'opłacona' w księdze rozrachunków). Jeśli ambiguity (kilka faktur z tą samą kwotą i NIPem), eskalacja do księgowego. (2) Dekretacja wg ZPK: tabela mapowania kodów GVC SWIFT (16 wersja 2024 - 020 SEPA, 051 polecenie zapłaty, 152 instant, 825 prowizja, 850 odsetki) i BankTransactionCode CAMT.053 na konta planu kont. Opłaty bankowe na 75-2 (koszty finansowe) lub 40-2 (usługi obce) zależnie od typu, odsetki kredytowe na 75-1 (przychody finansowe Ma), odsetki debetowe na 75-2 (koszty finansowe Wn). Brak miejsca na uznanie - reguła deterministyczna. (3) Spójność JPK_KR i JPK_V7M: każdy zapis bankowy musi mieć odpowiednik w dzienniku JPK_KR (numer dziennika, konto Wn, konto Ma, kwota, opis) z bilansem Wn = Ma. Każdy wpływ z faktury KSeF FA(2) musi mieć odpowiednik w JPK_V7M SprzedazWiersz, każda płatność za fakturę zakupu w JPK_V7M ZakupWiersz. Krzyżowe sprawdzenie generuje raport dla kontrolera KAS przed audytem.

## Edge-Cases polskie: BLIK incoming, SORBNET2, FX po NBP fixing, inwentaryzacja sald

BLIK B2B incoming (PSP - Polski Standard Płatności) dla mikro-faktur do 5.000 zł umożliwia natychmiastowe rozliczenia bez ELIXIR. Identyfikacja na CAMT.053 po BankTransactionCode wskazującym PSP/BLIK lub na MT940 po polu :86: zawierającym 'BLIK'. Powiązanie z fakturą po numerze KSeF FA(2) lub po NIPie nabywcy i numerze faktury w tytule przelewu. Limity: 5.000 zł na transakcję, dzienny limit kontrahenta zależny od banku (1.000-5.000 zł).

SORBNET2 (NBP - Narodowy Bank Polski) dla transakcji wysokokwotowych >1 mln zł - widoczne na wyciągu z typem systemu rozliczeniowego SCT-RTGS (Real-Time Gross Settlement) i kodem GVC 116. Nieodwołalne rozliczenie w czasie rzeczywistym podczas sesji NBP (8:00-17:00 dni robocze). Powiązanie z fakturą po numerze KSeF FA(2) - typowe dla zakupów hurtowych, transakcji M&A, transferów Treasury między spółkami grupy.

Express Elixir (KIR) instant 24/7 do 100.000 zł na transakcję - kod GVC 152, identyfikacja po typie systemu rozliczeniowego SCT-Instant. Rozliczenie w sekundach niezależnie od weekendu czy święta. Coraz częstsze dla pilnych płatności B2B - Agent traktuje identycznie jak ELIXIR ale flaguje 'instant' dla raportu.

Przeliczenie walut obcych po NBP fixing wg UoR art. 30: kurs średni z tabeli A NBP z dnia poprzedzającego datę zaksięgowania. Pobieranie automatyczne przez API NBP (api.nbp.pl) dla EUR, USD, CHF, GBP, CZK, HUF, SEK, NOK, DKK, JPY. Sobota/niedziela/święto - kurs z ostatniego dnia roboczego przed. Różnice kursowe zrealizowane na 75-1/75-2, niezrealizowane na 31.12 wycenione po kursie z 31.12 i odniesione na konta różnic kursowych.

Inwentaryzacja sald na 31.12 (UoR art. 26-27): pobranie wyciągu z 31.12 oraz wniosek o oficjalne potwierdzenie banku (Bank Confirmation Letter). Porównanie z saldem księgowym 13-1/13-2 wg ZPK. Rozbieżność = zapis w dzienniku różnic inwentaryzacyjnych z wyjaśnieniem (przelewy w drodze, opłaty zaksięgowane przez bank po 31.12). Audit trail dla biegłego rewidenta z PIBR wg KSRF 505.

## Integracja z polskim ekosystemem: Comarch, Symfonia, enova, PKO BP, mBank, ING, Pekao, Santander, KAS

Agent łączy się z głównymi ERPami polskiego rynku: [Comarch ERP Optima Bank](https://www.comarch.pl/erp/comarch-erp-optima/) (lider w MŚP, integracja z bankami przez Webservice oraz Polish Open Banking PSD2), Comarch ERP XL Finanse Bank (Enterprise, multi-rachunkowy z CAMT.053), [Symfonia Finanse i Symfonia Handel](https://www.symfonia.pl/) (Sage Symfonia, masowy MT940 z automatyczną dekretacją), [enova365 Bank](https://www.enova.pl/) (mocna w controllingu, multi-walutowy z NBP fixing), InsERT Subiekt nexo Pro oraz Rachmistrz nexo Pro (CAMT.053 i Express Elixir), SAP S/4HANA Polish Localization Cash Management (Volkswagen Poznań, BMW Wrocław, Stellantis Tychy, Bosch Mirków, Mercedes Benz Jawor), Asseco Softlab Treasury Bank, ifirma.pl Bank (cloud z auto-importem), i-Konto.pl Treasury (multi-bankowy SORBNET2/ELIXIR/BLIK), WAPRO Fakir i WAPRO Mag (CAMT.053 z uzgadnianiem faktur).

Integracja bankowa przez Polish Open Banking API (PKO BP API, mBank API, ING Web API, Pekao Open Banking, Santander Open Banking, Millennium Bank, Alior Bank, Bank Pocztowy, Citibank Handlowy, BNP Paribas, Credit Agricole, Deutsche Bank Polska, Raiffeisen, BOŚ, Plus Bank). CAMT.053 ISO 20022 dla nowoczesnych wyciągów, MT940 SWIFT dla starszych integracji, ELIXIR-O wewnętrzny (KIR) dla rekonstrukcji szczegółów rozliczenia. Powiązanie z Agentem Cash Application przez parsowanie CAMT.053/MT940, z Agentem Przebiegów Płatności przez wyciągi po wykonaniu ELIXIR/SORBNET2/SWIFT, z Agentem Cash Forecasting przez konsolidację sald w czasie rzeczywistym, z Agentem KSeF przez powiązanie z numerem FA(2). Audit trail kompatybilny z KAS (krzyżowo z JPK_KR i JPK_V7M dla CIT/PIT/VAT), GIIF (AML/CFT - STR >15.000 EUR), KNF, PIP (zgodność z Ustawą o opóźnieniach 8.03.2013), UODO (RODO) i biegłym rewidentem z PIBR przy badaniu ustawowym sprawozdania finansowego (KSRF 505 potwierdzenia od osób trzecich, KSRF 320 istotność, KSRF 540 wartości szacunkowe).

--- Agent analizy odchyleń budżetowych ---
> Agent porównuje Plan-Wykonanie, dekomponuje odchylenia per cena/wolumen/mix/timing zgodnie z KSH art. 233, UoR art. 49-54, KSR 4/6/9 oraz KSRF 540 - Cert-Ready dla biegłego rewidenta PIBR.

Polska gospodarka 2026 stoi przed największą zmianą w zarządzaniu analizą odchyleń budżetowych od czasu wprowadzenia MSSF w 2005 roku. Kombinacja KSeF FA(2) obowiązkowego od 1.7.2026 (krzyżowa kontrola przychodów i kosztów B2B z UUID Ministerstwa Finansów wobec budżetu), KSR 9 par. 32 wymagającego dekompozycji odchyleń per segment, MSR 1, 8 i 36 dla emitentów GPW oraz KSRF 540 i 320 Substantive Testing wymaga od średnich i dużych polskich spółek (>250 prac., UoR art. 64 ust. 1) systematycznej analizy Plan-Wykonanie z audyt-trailem dla biegłego rewidenta PIBR, KAS, KNF oraz Komitetu Audytu Rady Nadzorczej. KSH art. 233 (obowiązek bieżącej kontroli sytuacji finansowej spółki) wraz z art. 299 (osobista odpowiedzialność członków zarządu sp. z o.o. za zobowiązania niezaspokojone) tworzy bezprecedensowy poziom ryzyka osobistego CFO i zarządu - analiza odchyleń jest kluczowym elementem systemu kontroli wewnętrznej. Według FP&A Trends Benchmark 2025 aż 46 procent czasu pracy FP&A przypada na zbieranie i walidację danych Plan-Wykonanie - a nie na analizę przyczyn, która faktycznie poprawia decyzje. Przy analizie odchyleń budżetowych ta dysproporcja jest szczególnie widoczna: samo rozbicie odchylenia na drivery trwa minuty, pozyskanie i uzgodnienie danych z różnych systemów - godziny.

## Wielowarstwowy governance Plan-Wykonanie wymagający Cert-Ready by Design: KSH art. 233, KNF Rekomendacja D, UoR art. 49-54, KSRF 540 i 320 Substantive Testing oraz krzyżowa kontrola KSeF FA(2)

GPW (Giełda Papierów Wartościowych) jest w 2026 europejskim liderem we wdrażaniu Dobrych Praktyk Spółek Notowanych 2021 zasada 1.4 i 4.7 - 433 emitentów rynku regulowanego raportuje istotne odchylenia od budżetu kwartalnie do Rady Nadzorczej oraz składa roczny raport komitetu audytu o systemie zarządzania ryzykiem. KNF nadzoruje raporty bieżące ESPI/ESPInet emitentów (art. 56-57 Ustawy o ofercie publicznej z 29.07.2005) - sankcje art. 96 sięgają 5 mln zł obok odpowiedzialności cywilnej członków zarządu wobec inwestorów. Brak lub błędne raportowanie istotnego odchylenia (EBITDA poniżej budżetu >25%, naruszenie kowenantu w wykonaniu, ujemny wynik vs budżet >2 kwartały, istotny odpis utraty wartości wg KSR 4 wynikający z odchylenia) skutkuje sankcjami UOKiK do 10 procent obrotu rocznego, odpowiedzialnością cywilną wobec wierzycieli oraz utratą wiarygodności w indeksach giełdowych (WIG20, WIG30, WIG ESG, FTSE4Good).

Ministerstwo Finansów wprowadza KSeF FA(2) jako obowiązkowy mechanizm cross-check transakcji od 1.7.2026 - dla analizy odchyleń to fundamentalna zmiana, ponieważ każdy przychód B2B i koszt musi być powiązany z UUID Ministerstwa Finansów oraz porównany z pozycją budżetową. Agent buduje graf przychodowo-kosztowy z UUID MF - rozbieżności wykonania wobec budżetu >5 procent sygnalizują fraud lub błąd księgowy dla biegłego rewidenta wg KSRF 540 par. 8-13 oraz KSRF 320 (istotność zwykle 5 procent wyniku przed opodatkowaniem). KSH art. 233 dodaje wymóg osobistej odpowiedzialności zarządu: jeśli zarząd zaniedbuje obowiązek bieżącej kontroli sytuacji finansowej (analiza Plan-Wykonanie jest kluczowym elementem), skutkuje to sankcją art. 299 KSH - członkowie zarządu odpowiadają osobiście za niezaspokojone zobowiązania spółki. Średnia polska spółka GPW (1000-3000 pracowników, 500 mln-2 mld zł obrotu) ma potencjalną kumulacyjną ekspozycję sankcyjną 30-200 mln zł rocznie bez Cert-Ready by Design analizy odchyleń.

## Jakość komentarza zależy od dekompozycji Volume × Price × Mix × Timing - 16 deterministycznych punktów decyzyjnych z trzema eskalacjami ludzkimi

Odchylenie minus 12 mln zł na kosztach materiałowych samo w sobie mówi niewiele. Dopiero dekompozycja czyni je przydatnym do działania: 6,5 mln zł odchylenie cenowe przez wzrost cen surowców LME, 3,2 mln zł odchylenie wolumenowe przez wyższy brak w produkcji, 2,3 mln zł odchylenie mixu przez przesunięcie ku produktom o niższych marżach. Każdy z tych komponentów wymaga innej reakcji - odchylenie cenowe dotyczy zakupów, wolumenowe produkcji, mixu sprzedaży. Bez dekompozycji odchylenie pozostaje liczbą na slajdzie - z dekompozycją staje się punktem wyjścia dla konkretnych działań naprawczych dla Komitetu Audytu Rady Nadzorczej KSH art. 391.

Agent przetwarza każdy miesięczny i kwartalny cykl Plan-Wykonanie przez pipeline 16 strukturalnych punktów decyzyjnych: trzynaście klasyfikacji regułowo-ML oraz trzy eskalacje ludzkie (propozycje działań naprawczych, ocena strategiczna i zatwierdzenie zarządu oraz Komitetu Audytu). Walidacja kompletności danych korzysta z silnika reguł sprawdzającego 8 kontroli: pokrycie wszystkich centrów kosztów MPK, zgodność salda głównej księgi z budżetem, ujęcie rozliczeń międzyokresowych KSR 6, mapowanie segmentów KSR 9 oraz kompletność krzyżowej kontroli KSeF FA(2) z UUID MF. Dekompozycja Volume × Price × Mix dla przychodów oraz Cena × Wolumen × Efektywność dla kosztów stosuje deterministyczne formuły wariancji branżowej. Klasyfikacja Timing/Permanent/One-off używa modelu XGBoost z ponad 30 cechami (sezonowość GUS, cykl produkcyjny PKD, harmonogramy klientów). Korelacja z makro driverami NBP/GUS/URE/EU ETS/LME oblicza wkład każdego drivera w odchylenie.

## Konkretny przykład polskiego producenta automotive na GPW: zamknięcie miesiąca z agentem

Średniej wielkości polski producent przemysłowy notowany na GPW (1500 pracowników, 720 mln zł obrotu, sektor automotive z PKD 29.32) sporządza miesięczny raport odchyleń oraz kwartalny raport ESPI. Agent w pierwszym tygodniu po zamknięciu miesiąca wykonuje: (1) walidację kompletności - 100 procent pokrycie 47 MPK, zgodność salda 99,8 procent, krzyżowa kontrola KSeF FA(2) 96,4 procent przychodów wobec UUID MF; (2) agregację z SAP S/4HANA Polish Analytics i Anaplan - 24 miesiące historii Plan-Wykonanie, 1,8 mln rekordów P&L; (3) obliczenie odchyleń - przychody +18 mln zł vs budżet (+2,4 procent), EBITDA -8 mln zł (-9,1 procent), wynik netto -6,2 mln zł (-12 procent); (4) próg istotności KSRF 320 - 5 procent wyniku przed opodatkowaniem to 3,5 mln zł, 28 odchyleń istotnych z 187 pozycji; (5) dekompozycja Volume × Price × Mix przychodów - Volume +8,5 mln (wzrost zamówień OEM), Price -3,2 mln (renegocjacja umów eksport), Mix +12,7 mln (wzrost udziału aftermarket); (6) dekompozycja kosztów - Price +6,5 mln (LME stal +12 procent), Quantity +3,2 mln (brak produkcji 1,8 procent), Efficiency +2,3 mln (przestoje); (7) klasyfikacja Timing/Permanent - 4,2 mln zł timing (faktura grudniowa w styczniu), 14,3 mln permanent (ceny LME i wolumen zamówień), 1,5 mln one-off (kara umowna); (8) korelacja makro - USD/PLN +3,1 procent wyjaśnia 4,8 mln, LME stal +12 procent wyjaśnia 6,5 mln, EU ETS +18 procent wyjaśnia 1,8 mln; (9) test impairment KSR 4 - EBITDA segmentu OEM -22 procent wobec budżetu - przesłanka uruchamiająca test DCF z WACC 9,8 procent; (10) walidacja kowenantów - DSCR 1,4x (>1,2x bez naruszenia), Net Debt/EBITDA 3,1x (<3,5x), margines komfortowy; (11) projekt komentarza LLM z dekompozycją per segment oraz 5 hipotez przyczyn źródłowych; (12) propozycje działań naprawczych - controller wybiera renegocjację z dostawcą stali oraz zmianę mixu produktowego ku aftermarket; (13) korekta CIT z Polski Ład 2.0 - ulga B+R 4,2 mln zł, robotyzacja 1,8 mln zł, efektywna stopa CIT 13,2 procent zamiast 19 procent; (14) konsolidacja 5 spółek zależnych z eliminacją intercompany 18 mln zł; (15) zatwierdzenie przez CFO oraz Komitet Audytu Rady Nadzorczej; (16) kwartalny raport ESPI do GPW wraz z audyt-trailem dla biegłego rewidenta wg KSRF 540, 320 i 570. Czas całkowity: 3,5 godziny zamiast 2-3 dni roboczych.

## Continuous Monitoring i pętla zwrotna ML redukują czas badania szacunków księgowych o 35-45 procent

W pierwszym roku wdrożenia agent zbiera 12-24 miesiące historii Plan-Wykonanie z ERP, Anaplan/Tagetik oraz KSeF FA(2) - zwykle 400-800 godzin pracy zespołów FP&A, Finance i Accounting zgodnie z benchmarkami EFRAG 2024 oraz PWC EPM Survey 2024. Agent stosuje aktywną pętlę zwrotną ML: każda korekta klasyfikacji Timing/Permanent/One-off przez controllera, każda redakcja projektu komentarza przez CFO oraz każde uzasadnienie odchylenia od konsensusu analityków trafia do ponownego treningu modelu zgodnie z RODO art. 22 (zautomatyzowane decyzje z prawem do interwencji ludzkiej). Po 12-18 miesiącach pętla zwrotna redukuje czas dekompozycji wariancji o 50-60 procent, czas badania szacunków księgowych KSRF 540 o 35-45 procent oraz czas raportowania ESPI o 50-60 procent. Dashboard FP&A pokazuje w czasie rzeczywistym: odchylenia per segment i linia P&L, dekompozycję Volume × Price × Mix × Timing, status krzyżowej kontroli KSeF FA(2), kowenanty bankowe oraz harmonogram raportowania ESPI - kwartalne raporty do Komitetu Audytu Rady Nadzorczej zgodnie z KSH art. 391 oraz GPW Dobre Praktyki Spółek Notowanych 2021 zasada 1.4 i 4.7. Komentowanie odchyleń skraca się z 2-3 dni do mniej niż 4 godzin, a ręczna praca w Excelu na zamknięcie miesiąca maleje o ponad 50 procent.

## Edge-cases polskie: GPW Catalyst, automotive, spółki Skarbu Państwa, sezonowość detaliczna, Estonian CIT

Emitenci GPW realizują obowiązki Dobrych Praktyk Spółek Notowanych 2021: kwartalne raporty ESPI o odchyleniach >10% oraz dekompozycja per segment w sprawozdaniu z działalności KSR 9 par. 32. Sektor automotive (PKD 29) i przemysłowy (PKD 24-30) raportuje odchylenia cen surowców LME (stal, aluminium, miedź) oraz kursu USD/EUR/PLN dla eksporterów - to typowy driver 60-80 procent odchyleń kosztowych. Sezonowość detaliczna (PKD 47) - odchylenia Q4 rzędu 15-25 procent wymagają rolling forecast zamiast budżetu statycznego. Spółki Skarbu Państwa pod nadzorem NIK i MAP - analiza odchyleń jest elementem oceny celów strategicznych; sankcje art. 30 Ustawy o NIK. Multilatinas konsolidują przez group reporting w SAP Analytics Cloud, Anaplan lub Oracle EPM. Estonian CIT - opodatkowanie tylko przy dywidendach, efektywnie 9-19 procent. IP Box art. 24d - 5 procent CIT od dochodów z patentów. GPW Catalyst wymaga miesięcznego raportowania EBITDA, DSCR oraz Net Debt/EBITDA do agencji ratingowych (Fitch Polska, EuroRating, S&P).

## Integracja z polskim ekosystemem: Comarch Performance, SAP Analytics Cloud, Anaplan, Tagetik, KSeF, NBP

Agent integruje się z polskim ekosystemem EPM przez API: [Comarch ERP XL Performance](https://www.comarch.pl/erp/comarch-erp-xl/) (lider w segmencie MŚP i Enterprise, z PKD, planem kont UoR, KSR 4/6/9 oraz modułem Plan-Actual variance), [SAP S/4HANA Polish Analytics i SAP Analytics Cloud](https://www.sap.com/poland/) (emitenci GPW WIG20 z MSSF, ESEF iXBRL i Smart Insights), [Anaplan Connected Planning](https://www.anaplan.com/) (wdrażany przez Big-4 dla WIG30 i spółek Skarbu Państwa), [Wolters Kluwer CCH Tagetik](https://www.wolterskluwer.com/pl-pl/solutions/cch-tagetik) (konsolidacja MSSF, IFRS Taxonomy ESEF i Variance Commentary), [Workday Adaptive Planning](https://www.workday.com/pl-pl/products/adaptive-planning/overview.html) (cloud EPM z Variance Analysis i Driver Decomposition), [Symfonia ERP Performance](https://www.symfonia.pl/), [enova365 BI](https://www.enova.pl/), Asseco Softlab BI (sektor publiczny), Oracle EPM Cloud, Microsoft Dynamics 365 z Power BI, IBM Planning Analytics, Board International oraz Vena Solutions. Integracja z bazami zewnętrznymi obejmuje: KSeF FA(2) API z certyfikatem kwalifikowanym (CenCert/Szafir/EuroCert/KIR) do krzyżowej kontroli przychodów i kosztów wobec budżetu od 1.7.2026, NBP API (kursy, stopy i prognozy makroekonomiczne), GUS API (PKB, CPI, sprzedaż detaliczna, produkcja przemysłowa), URE (taryfy i EU ETS), LME (ceny stali, aluminium, miedzi) oraz KRS i GPW API z benchmarkami analityków (Vestor DM, Trigon DM, Erste, BM mBanku, Wood&Co, Ipopema). Badanie Big-4 wg KSRF 540, 320 i 570 jest wspierane eksportem do Deloitte ASM, PwC Halo, EY Helix i KPMG Clara z metadanymi PCAOB AS 1215, IAASB ISA 540 i KSR 4. Audyt-trail jest przechowywany 5 lat zgodnie z UoR art. 73, dokumentacją KSRF 540 par. 39 i KSR 9 par. 32, a interpretacje indywidualne KAS - na potrzeby nadzoru PANA.

--- Agent przypisywania wpływów ---
> Odczytuje wyciągi bankowe (CAMT.053, MT940), przypisuje płatności do kontrahentów i otwartych faktur, waliduje odliczenia skonta i tworzy zapisy rozliczeniowe.

Między wpływem płatności a zaksięgowanym rozliczeniem należności w wielu przedsiębiorstwach leżą godziny ręcznej pracy przypisywania. Pracownicy porównują wyciągi z otwartymi pozycjami, sprawdzają tytuły przelewu, identyfikują odmiennych płatników i wyjaśniają różnice. W przedsiębiorstwach z kilkuset wpływami dziennie ten proces wiąże specjalistów, których kompetencje powinny być wykorzystane do przypadków wyjaśniających i relacji z klientami. Jednocześnie każda godzina bez przypisania opóźnia efekt płynnościowy płatności - i pogarsza Days Sales Outstanding (DSO).

## Każdy dzień bez przypisania pogarsza Working Capital

Średnia DSO w różnych branżach wynosi 57 dni - mimo że większość przedsiębiorstw uzgadnia terminy płatności 28 dni (źródło: Kapittx, 2025). Ta luka prawie 30 dni nie powstaje tylko z powodu zalegających płatników. Znacząca część wynika z wewnętrznych opóźnień: płatności, które wprawdzie wpłynęły, ale nie zostały jeszcze przypisane, a tym samym nie zaksięgowane jako rozliczenie należności.

Dla przedsiębiorstwa z 50 milionami EUR (54 miliony USD) rocznego obrotu każdy dzień redukcji DSO oznacza około 137 000 EUR (148 000 USD) uwolnionego Working Capital. Cash Application nie jest zatem administracyjnym procesem pobocznym, lecz bezpośrednią dźwignią wpływającą na jakość bilansu.

## 80 procent przypisań podlega stałemu zbiorowi reguł

Ręczne przypisywanie sugeruje złożoność, której w większości przypadków nie ma. Analiza typowych wpływów pokazuje: około 80 procent daje się jednoznacznie przypisać po numerze faktury w tytule przelewu, kwocie i danych podstawowych kontrahenta. Przedsiębiorstwa ze zautomatyzowanym Cash Application osiągają według Emagia (2025) dokładność przypisań od 95 do 98 procent i redukują czas ręcznej obróbki o 80 do 90 procent.

Kluczowy punkt: ten wysoki wskaźnik nie jest efektem AI w wąskim rozumieniu. Opiera się na regułach deterministycznych - parsowanie wyciągu, porównanie referencji, weryfikacja kwoty, wygenerowanie zapisu. Zbiór reguł dostarcza wyników odtwarzalnych i weryfikowalnych. Właśnie to czyni proces podatnym na automatyzację zgodną z niemieckim standardem GoBD (niemiecki standard dokumentacji) (niemiecki standard dokumentacji) oraz polską Ordynacją podatkową (Art. 86 OP).

## Odmienni płatnicy i płatności częściowe wymagają stopniowanego modelu decyzyjnego

Pozostałe 20 procent to powód, dla którego pełna automatyzacja bez architektury decyzyjnej zawodzi. Typowe scenariusze: grupa kapitałowa płaci przez centralną placówkę płatniczą, której nazwa nie zgadza się z kontrahentem. Klient rozlicza trzy faktury w zbiorowym przelewie, ale przy jednej odlicza skonto, chociaż termin już minął. Lub płatność jest 47 EUR (51 USD) poniżej kwoty faktury - różnica zaokrągleniowa, uprawnione odliczenie czy błąd?

[Decision Layer](/pl/decision-layer/) rozróżnia te przypadki przez stopnie eskalacji. Stopień 1 - zbiór reguł - rozwiązuje dokładne dopasowanie: parsowanie CAMT.053, dopasowanie numeru faktury, sprawdzenie terminu skonta względem danych umownych. Stopień 2 - przybliżone dopasowanie - wkracza przy odmiennych płatnikach, łącząc dane bankowe z danych podstawowych, historyczne wzorce płatnicze i podobieństwa nazw. Dopiero gdy oba stopnie nie dostarczają jednoznacznego przypisania, agent eskaluje do pracownika - ze wszystkimi zebranymi informacjami kontekstowymi do przygotowania decyzji.

## Pracownik staje się ekspertem od wyjaśniania

W świecie ręcznym pracownik spędza większość czasu na rutynowych przypisaniach, które nie wymagają żadnej oceny fachowej. Właściwa ekspertyza - ocena historii klienta, interpretacja zachowań płatniczych, podejmowanie decyzji handlowych przy różnicach - schodzi na dalszy plan, ponieważ masa standardowych przypadków dominuje dzień pracy.

Po wdrożeniu agenta Cash Application relacja ta zmienia się zasadniczo. Agent przejmuje przypisania regułowe i przygotowuje przypadki wyjaśniające tak, że pracownik jest natychmiast zdolny do podjęcia decyzji: który kontrahent wchodzi w grę, które otwarte pozycje pasują do kwoty, którą metodę dopasowania próbowano, dlaczego żadna nie zadziałała. Rola zmienia się z przypisującego na eksperta od wyjaśniania.

Dla przedsiębiorstwa powstaje podwójny efekt. Czas przelotu od wpływu płatności do księgowania spada z godzin do minut dla przypadków standardowych. A wskaźnik wyjaśniania przy przypadkach problematycznych rośnie, ponieważ specjaliści koncentrują swój czas na przypadkach, które faktycznie wymagają osądu ludzkiego.

--- Agent prognozy przepływów pieniężnych ---
> Agent prognozuje cash flow zgodnie z KSH art. 233 obowiązek upadłości zarządu, KSR 1 RPP, MSSF 7 (IAS 7), KNF Rekomendacja D/Z oraz LCR/NSFR Bazylea III - Cert-Ready dla biegłego rewidenta PIBR + KNF.

Polska gospodarka 2026 stoi przed największą zmianą w zarządzaniu płynnością od czasu wprowadzenia MSSF w 2005 roku. Kombinacja KSeF FA(2) obowiązkowego od 1.7.2026 (krzyżowa kontrola faktur B2B z UUID MF), PolishAPI 4.0 jako standardu Open Banking dla 15 banków PL, wskaźników LCR i NSFR Bazylea III (Rozp. UE 575/2013), KSR 1 RPP Komitetu Standardów Rachunkowości MF oraz KSRF 570 going concern wymaga od średnich i dużych polskich spółek (>250 prac., UoR art. 64 ust. 1) systematycznego prognozowania cash flow z audyt-trailem dla biegłego rewidenta PIBR, KAS, KNF oraz Komitetu Audytu. KSH art. 233 (obowiązek zarządu zgłoszenia upadłości w 30 dniach od powzięcia wiadomości o niewypłacalności) wraz z art. 299 (osobista odpowiedzialność członków zarządu sp. z o.o. za zobowiązania niezaspokojone) tworzy bezprecedensowy poziom ryzyka osobistego CFO i zarządu. Każda średnia i duża spółka musi udokumentować zgodność systemu prognozowania cash flow z KSRF 540 i 570, UoR art. 49, GPW Dobre Praktyki 2021 oraz Ustawą Prawo restrukturyzacyjne z 15.05.2015 (alternatywa dla upadłości).

## Wielowarstwowy treasury governance wymagający Cert-Ready by Design: KSH art. 233 (obowiązek upadłości), KNF Rekomendacja D, KSRF 540 i 570 Substantive Testing oraz Ustawa o restrukturyzacji 2015

GPW (Giełda Papierów Wartościowych) jest w 2026 europejskim liderem we wdrażaniu Dobrych Praktyk Spółek Notowanych 2021 zasada 1.4 - 433 emitentów rynku regulowanego raportuje system zarządzania ryzykiem płynności do Rady Nadzorczej kwartalnie oraz składa roczny raport komitetu audytu o systemie zarządzania ryzykiem. KNF nadzoruje raporty bieżące ESPI/ESPInet emitentów (art. 56-57 Ustawy o ofercie publicznej z 29.07.2005) - sankcje art. 96 sięgają 5 mln zł obok odpowiedzialności cywilnej członków zarządu wobec inwestorów. Brak lub błędne raportowanie istotnego ryzyka płynności (LCR <100%, naruszenie kowenantu, prognoza ujemna w base case >30 dni) skutkuje sankcjami UOKiK do 10% obrotu rocznego firmy, odpowiedzialnością cywilną wobec wierzycieli oraz utratą wiarygodności w indeksach giełdowych (WIG20, WIG30, WIG ESG, FTSE4Good).

Ministerstwo Finansów wprowadza KSeF FA(2) jako obowiązkowy mechanizm cross-check transakcji od 1.7.2026 - dla forecastingu cash flow to fundamentalna zmiana, ponieważ każdy wpływ B2B i wydatek musi być powiązany z UUID Ministerstwa Finansów. Agent buduje graf zakupowo-sprzedażowy z UUID MF - rozbieżności >5% wobec wyciągów bankowych z PolishAPI 4.0 sygnalizują fraud lub błąd księgowy dla biegłego rewidenta wg KSRF 540 par. 8-13. KSH art. 233 dodaje wymóg osobistej odpowiedzialności zarządu: jeśli spółka spełnia przesłanki niewypłacalności wg Ustawy Prawo upadłościowe art. 11 (utrata zdolności wykonywania zobowiązań >3 miesiące LUB nadmierne zadłużenie >24 miesiące), zarząd ma 30 dni na zgłoszenie upadłości. Niewykonanie tego obowiązku skutkuje sankcją art. 299 KSH - członkowie zarządu odpowiadają osobiście za niezaspokojone zobowiązania spółki. Średnia polska spółka GPW (1000-3000 pracowników, 500 mln-2 mld zł obrotu) ma potencjalną kumulacyjną ekspozycję sankcyjną 50-300 mln zł rocznie bez Cert-Ready by Design forecastingu cash flow.

## 16 deterministycznych punktów decyzyjnych z czterema eskalacjami ludzkimi

Agent przetwarza każdy roczny, kwartalny i tygodniowy cykl prognozy cash flow przez pipeline 16 strukturalnych punktów decyzyjnych: dwanaście klasyfikacji regułowo-AI oraz cztery eskalacje ludzkie (test niewypłacalności, decyzja o restrukturyzacji, struktura finansowania oraz zatwierdzenie zarządu i Komitetu Audytu). Walidacja zasady kontynuacji działalności (going concern) korzysta z silnika reguł sprawdzającego 14 wskaźników wczesnego ostrzegania (LCR <100%, naruszony kowenant, kredyty zapadające w 12 mc bez refinansowania, płynność ujemna w base case >30 dni). Klasyfikacja KSR 1 i MSSF 7 (CFO/CFI/CFF) przebiega regułowo wg drzewa decyzyjnego z PKD dostawcy oraz planu kont UoR. Agregacja danych z 15 banków PL przez PolishAPI 4.0 jest deterministyczna, z certyfikatem TPP KNF i eIDAS QSeal. Krzyżowa kontrola KSeF FA(2) wykonuje walidację w czasie rzeczywistym wobec UUID Ministerstwa Finansów. Modelowanie Monte Carlo z 10 000 iteracji generuje przedziały ufności P10/P50/P90.

Konkretny przykład: średniej wielkości polski producent chemiczny notowany na GPW (1800 pracowników, 850 mln zł obrotu, sektor chemia z PKD 20.16) sporządza tygodniowy 13-tygodniowy forecast cash flow oraz kwartalny raport ESPI. Agent w pierwszym tygodniu kwartału wykonuje: (1) walidację going concern - 12 z 14 wskaźników w normie, LCR 142%, NSFR 118% i DSCR 1,8x, brak naruszenia kowenantów; (2) agregację z 7 banków PL (PKO BP, Pekao, mBank, Santander, ING, BNP Paribas, BGK) przez PolishAPI 4.0 - 36 miesięcy historii, 285.000 transakcji ELIXIR/SORBNET2; (3) klasyfikację KSR 1 - CFO 658 mln zł rocznie (sprzedaż 850 mln, zakupy 425 mln, wynagrodzenia 184 mln wraz z ZUS 41 mln, VAT/PIT/CIT 78 mln), CFI -78 mln zł (CapEx 95 mln minus dezinwestycje 17 mln), CFF -45 mln zł (dywidenda 32 mln oraz spłata kredytu 28 mln minus nowy kredyt 15 mln); (4) cross-check KSeF FA(2) - rozbieżność 4,2% w kategorii zakupów (akceptowalna <5%), 100% wpływów ze sprzedaży zgodne z UUID MF; (5) sezonowość ML - spike VAT 25. dnia (78 mln zł), ZUS 5/15/20 dnia (41 mln zł rozłożone), wynagrodzenia 10. dnia (15 mln zł), 13. pensja w grudniu (16 mln zł); (6) scoring opóźnień XGBoost - 18% klientów w grupie wysokiego ryzyka (DSO >75 dni, DBT >15 dni), suma 31 mln zł; (7) Monte Carlo 10 000 iteracji - P10 cash 78 mln zł, P50 95 mln zł, P90 112 mln zł, Worst 5% 65 mln zł; (8) walidacja LCR/NSFR Bazylea III - 142%/118% w P50, 108%/102% w Worst Case (>100% bez naruszenia); (9) kowenanty - DSCR 1,8x w P50, 1,4x w Worst (>1,2x bez naruszenia); (10) brak ryzyka niewypłacalności art. 11 Ustawy Prawo upadłościowe; (11) brak rekomendacji restrukturyzacyjnej; (12) Polski Lad 2.0 - kalkulacja ulgi B+R 8,5 mln zł zwrotu oraz ulgi na ekspansję 3,2 mln zł cash flow w Q3; (13) konsolidacja 4 spółek zależnych z cash poolingiem fizycznym; (14) projekt narracji LLM dla CFO oraz Komitetu Audytu Rady Nadzorczej - 5 sekcji raportu; (15) zatwierdzenie przez CFO i Komitet Audytu; (16) kwartalny raport ESPI/ESPInet do GPW wraz z audyt-trailem dla biegłego rewidenta wg KSRF 570.

## Continuous Monitoring i pętla zwrotna ML redukują czas badania going concern o 40-50 procent

W pierwszym roku wdrożenia agent prognozy cash flow zbiera ponad 36 miesięcy historii z ERP, 15 banków PL oraz KSeF FA(2) - zwykle 800-1500 godzin pracy zespołów Treasury i Finance zgodnie z benchmarkami EFRAG 2024 oraz PWC Treasury Survey 2024. Agent stosuje aktywną pętlę zwrotną ML: każda klasyfikacja CFO/CFI/CFF korygowana przez biegłego rewidenta (krok 3 microDecisions), każda decyzja CFO o restrukturyzacji (krok 11) oraz każde zatwierdzenie struktury finansowania (krok 13) trafia do ponownego treningu modelu zgodnie z RODO art. 22 (zautomatyzowane decyzje z prawem do interwencji ludzkiej). Po 12-18 miesiącach pętla zwrotna redukuje czas klasyfikacji KSR 1 o 60-70 procent, czas badania going concern KSRF 570 o 40-50 procent oraz czas raportowania ESPI o 50-60 procent. Dashboard Treasury pokazuje w czasie rzeczywistym: salda 15 banków PL, LCR/NSFR Bazylea III, kowenanty, prognozę P10/P50/P90, scoring opóźnień, status krzyżowej kontroli KSeF FA(2) oraz harmonogram raportowania ESPI - kwartalne raporty do Komitetu Audytu Rady Nadzorczej zgodnie z KSH art. 391 oraz GPW Dobre Praktyki Spółek Notowanych 2021 zasada 1.4.

## Edge-cases polskie: GPW Catalyst, sektor energetyczny, spółki Skarbu Państwa, multilatinas, restrukturyzacja, cash pooling

Polskie spółki notowane GPW mają obowiązki Dobrych Praktyk Spółek Notowanych 2021: roczny raport komitetu audytu o systemie zarządzania ryzykiem płynności, raporty bieżące ESPI/ESPInet o istotnych ryzykach oraz opis polityk zarządzania kapitałem w prospekcie emisyjnym. Sektor energetyczny objęty EU ETS raportuje dodatkowo ryzyko cen uprawnień CO2 wpływające na cash flow operacyjny - to synergia z ESG Reporting Agent. Spółki Skarbu Państwa pod nadzorem NIK (Najwyższa Izba Kontroli) raportują dodatkowo do MAP (Ministerstwo Aktywów Państwowych) z sankcjami art. 30 Ustawy o NIK; cash flow forecast jest częścią oceny realizacji celów strategicznych spółek. Multilatinas z polskim oddziałem konsolidują cash pooling notional przez Treasury Center of Excellence w Wiedniu/Londynie/Frankfurcie - z cross-mappingiem KSR 1, MSSF 7 oraz lokalnych standardów (HGB DE, LSF AT itd.). Spółki w restrukturyzacji wg Ustawy z 15.05.2015 (układowe, sanacyjne, przyspieszone układowe, o zatwierdzenie układu) wymagają miesięcznego raportowania cash flow do nadzorcy lub zarządcy, sądu restrukturyzacyjnego oraz biegłego rewidenta, z weryfikacją wykonalności układu. Cash pooling fizyczny (standard ZBP) lub notional dla optymalizacji odsetkowej wymaga umowy między spółkami grupy oraz dokumentacji cen transferowych art. 11c-11l Ustawy o CIT (Prosta Spółka Akcyjna od 2021). GPW Catalyst (rynek obligacji) wymaga miesięcznego raportowania cash flow, DSCR oraz Net Debt/EBITDA do nabywców obligacji.

## Integracja z polskim ekosystemem: Comarch Treasury, SAP Cash Management, Symfonia, Kyriba, Bellin tm5, PolishAPI, KSeF, NBP

Agent integruje się z polskim ekosystemem Treasury i Cash Management przez API: [Comarch ERP XL Treasury oraz Comarch ERP Optima Cash Management](https://www.comarch.pl/erp/comarch-erp-xl/) (lider w segmencie Enterprise i MŚP, z polską lokalizacją PKD, planem kont UoR oraz integracją z 15 bankami PL przez ELIXIR, SORBNET2, Express ELIXIR, EuroELIXIR i BLIK), [SAP S/4HANA Polish Treasury, SAP Cash Management i SAP Liquidity Planner](https://www.sap.com/poland/) (multilatinas i emitenci GPW WIG20 z SAP Treasury and Risk Management oraz SAP Bank Communication Management), [Symfonia ERP Cashflow i Symfonia Finanse](https://www.symfonia.pl/) (średni biznes oraz spółki rodzinne >250 prac.), [enova365 Cashflow i enova365 Banki](https://www.enova.pl/) (lokalizacja PL z mapowaniem na PKD), Asseco Softlab Treasury i Asseco WAPRO Cash (sektor publiczny), Microsoft Dynamics 365 Finance z Treasury Module (środowisko Azure, integracja z Microsoft 365 i Power BI), Oracle Fusion Cloud ERP Treasury (multinationals), Kyriba Treasury i Cash Management (domyślne dla Big-4 w Treasury Center of Excellence emitentów GPW WIG30), Bellin tm5 i Coupa Treasury (specjalizacja TMS), BMD NTCS Cashflow (multinationals AT/DE/PL) oraz InsERT Subiekt nexo PRO i Rewizor nexo (małe i średnie). Integracja z bazami zewnętrznymi obejmuje: PolishAPI 4.0 (PSD2 AIS) z certyfikatem TPP KNF i eIDAS QSeal dla 15 największych banków PL (PKO BP, Pekao, mBank, Santander, ING, BNP Paribas, Millennium, Alior, Citi, Deutsche, BGK, BOS, Credit Agricole, Velo, Toyota), KSeF FA(2) API z certyfikatem kwalifikowanym (CenCert/Szafir/EuroCert/KIR) do krzyżowej kontroli wpływów i wydatków od 1.7.2026, NBP API (kursy walut, stopa referencyjna, NBP Quick), KIR (Krajowa Izba Rozliczeniowa - operator ELIXIR, Express ELIXIR, EuroELIXIR i BLIK), KRS API, Białą Listę Podatników VAT (whitelist.gov.pl), scoring kontrahentów KSF/KRD/BIK oraz GUS API REGON ze statystyką makroekonomiczną na potrzeby inżynierii cech modelu Monte Carlo. Badanie Big-4 wg KSRF 540 i 570 jest wspierane bezpośrednim eksportem do Deloitte ASM, PwC Halo, EY Helix i KPMG Clara z metadanymi audyt-trail PCAOB AS 1215, IAASB ISA 570, KSR 1 i IFRS Taxonomy 2024. Audyt-trail jest przechowywany 5 lat zgodnie z UoR art. 73 oraz dokumentacją going concern KSRF 570 par. 39 na potrzeby nadzoru PANA, a dokumentacja restrukturyzacyjna - 10 lat zgodnie z Ustawą Prawo restrukturyzacyjne z 15.05.2015 art. 234.

--- Agent listy kontrolnej zamknięcia ---
> Orkiestruje zamknięcie miesiąca jako ustrukturyzowany workflow z zależnościami zadań, monitoringiem terminów.

Zamknięcie miesiąca nie jest problemem księgowym. Każde pojedyncze księgowanie, uzgodnienie i konsolidacja jest sama w sobie do opanowania. Co rozciąga zamknięcie na sześć, osiem czy dziesięć dni roboczych, to koordynacja między tymi krokami - kto czeka na kogo, które zadanie blokuje następne i gdzie jest opóźnienie, którego nikt jeszcze nie zauważył. Agent listy kontrolnej zamknięcia rozwiązuje dokładnie ten problem orkiestracji. Regułowo, bez własnej logiki księgowej, bez AI.

## Większość zespołów finansowych potrzebuje ponad tydzień na zamknięcie

Liczby są jednoznaczne: APQC określa medianę zamknięcia miesiąca międzybranżowo na 6,4 dnia. Większa część zespołów finansowych regularnie potrzebuje ponad sześć dni roboczych, tylko mniejszość realizuje zamknięcie w trzy dni lub mniej.

Przyczyna rzadko leży w złożoności pojedynczych zadań. Większość zespołów pracuje przy zamknięciu wciąż z listami kontrolnymi w Excelu, w których zależności między zadaniami nie są odwzorowane. Zapomniane uzgodnienie Intercompany blokuje konsolidację. Opóźniony accrual wstrzymuje weryfikację kompletności. Opóźnienie staje się widoczne dopiero, gdy termin jest już przekroczony.

## Orkiestracja pokonuje automatyzację wyspową

Wiele firm automatyzuje pojedyncze kroki zamknięcia - uzgodnienia, zapisy dziennikowe, rezerwy. Każdy z tych kroków staje się szybszy. Mimo to cały proces prawie się nie skraca. Bo między zautomatyzowanymi wyspami leżą ręczne przekazania, niejasne kolejności i czasy oczekiwania bez eskalacji.

Trend w ankietach CFO jest jednoznaczny: focus przesuwa się od izolowanej automatyzacji ku orkiestracji procesów. Firmy, które wdrażają zintegrowane sterowanie, raportują lepszy Working Capital, zredukowane ryzyka i szybsze decyzje. Decydująca dźwignia leży nie w szybszym księgowaniu, lecz w eliminacji martwego czasu między księgowaniami.

Dla zamknięcia miesiąca oznacza to konkretnie: dopóki żaden system nie zna i nie egzekwuje kolejności zadań, zamknięcie pozostaje tak wolne jak jego najwolniejsze ręczne przekazanie.

## Dziesięć regułowych decyzji steruje całym przebiegiem

[Decision Layer](/pl/decision-layer/) rozkłada orkiestrację zamknięcia na dziesięć kroków decyzyjnych - wszystkie na poziomie R (silnik reguł), żadna AI. Konkretny scenariusz czyni logikę namacalną.

Piątkowe popołudnie, trzeci dzień roboczy zamknięcia. Agent sprawdza łańcuch zależności: uzgodnienie Intercompany dla spółki DE03 wciąż ma status "otwarte". Następująca konsolidacja nie może się rozpocząć. Silnik reguł rozpoznaje blokadę automatycznie, porównuje planowany termin zakończenia z datą bieżącą i klasyfikuje zadanie jako przeterminowane. Skonfigurowana matryca eskalacji uruchamia się: najpierw powiadomienie do odpowiedzialnego, po czterech godzinach bez zmiany statusu - do Head of Accounting.

Równolegle agent śledzi status wszystkich pozostałych zadań. Zakończone kroki zwalniają swoje zależne zadania następcze. Weryfikacja kompletności na końcu porównuje zakończone zadania z listą obowiązkową. Jeśli brakuje kroku, zamknięcie pozostaje otwarte - bez wyjątków, bez ręcznego nadpisywania bez udokumentowanego powodu.

Kluczowe: agent niczego nie księguje, nie oblicza, nie wycenia. Steruje wyłącznie kolejnością i kompletnością. To jasne ograniczenie czyni go solidnym i weryfikowalnym.

## Protokół zamknięcia powstaje jako produkt uboczny

Każdy cykl zamknięcia generuje kompletny protokół - nie jako dodatkowe zadanie dokumentacyjne, lecz jako automatyczny wynik orkiestracji. Każda zmiana statusu, każda eskalacja, każdy znacznik czasu jest rejestrowany: kto zakończył jakie zadanie kiedy, jakie zależności zostały sprawdzone, gdzie wystąpiło opóźnienie.

Dla biegłych rewidentów i wewnętrznego governance protokół ten jest dowodem uporządkowanego procesu zamknięcia zgodnego z Ustawą o rachunkowości. Żadne wsteczne zbieranie maili i plików Excel. Żadna rekonstrukcja z pamięci. Proces zamknięcia dokumentuje się sam, w trakcie działania.

Firmy chcące przejść z zamknięcia sześciodniowego na dwa do trzech dni nie potrzebują szybszego księgowego. Potrzebują systemu, który zna zależności między 30, 50 czy 80 zadaniami zamknięcia, rozpoznaje blokady w czasie rzeczywistym i angażuje odpowiedzialnych bez opóźnienia. Dokładnie to zapewnia regułowa orkiestracja w Decision Layer.

--- Agent konsolidacji sprawozdań ---
> Agent przygotowuje skonsolidowane sprawozdanie finansowe: konsolidacja pełna UoR art. 60, metoda praw własności art. 63b, MSSF 10/11/12, test goodwill MSR 36 oraz KSRF 600 audyty grupowe - dla Group Accounting.

Skonsolidowane sprawozdanie finansowe w Polsce stoi na styku czterech równoległych obszarów compliance o istotnie różnych konsekwencjach. UoR art. 55-63d wymaga konsolidacji pełnej, proporcjonalnej oraz metody praw własności, ze szczegółowymi księgowaniami konsolidacyjnymi wg art. 60-63d (kapitał, rozrachunki, przychody i koszty, wyniki z transakcji wewnętrznych), ujawnieniami konsolidacyjnymi z art. 63, skonsolidowanym sprawozdaniem z działalności oraz obowiązkowym badaniem wg KSRF 600. Dla spółek notowanych MSSF 10/11/12 wymaga koncepcji kontroli (władza nad istotnymi działaniami, ekspozycja na zmienne zwroty i możliwość wykorzystania władzy), a dalej IAS 21 (Currency Translation Adjustment), IAS 28 (metoda praw własności) oraz IAS 36 (test utraty wartości firmy z roczną oceną ośrodków generujących środki pieniężne). KSR 8 (skonsolidowane sprawozdanie finansowe), KSR 4 (utrata wartości aktywów) i KSR 9 (ocena księgowa) konkretyzują praktykę konsolidacji wg UoR zgodnie z wytycznymi Komitetu Standardów Rachunkowości. DPSN 2021 oraz polskie wzmocnienia nadzoru po skandalach pokroju Wirecard umacniają obowiązki komitetu audytu rady nadzorczej wg KSH art. 382 - niezależny ekspert finansowy, niezależność audytora, rotacja co 10 lat oraz odpowiedzialność karna za oświadczenie o rzetelności z art. 77 UoR. Ta cztero-standardowa konstelacja oznacza, że każde skonsolidowane sprawozdanie spółki z WIG20-mWIG40-sWIG80 lub spółki średniej może jednocześnie wywołać do czterech różnych obowiązków compliance.

## Ryzyko raportu KNF o nieprawidłowościach: sankcje administracyjne do 21,6 mln zł i istotny uszczerbek reputacji

Komisja Nadzoru Finansowego (KNF) wyrywkowo sprawdza skonsolidowane sprawozdania finansowe spółek notowanych wg Ustawy o ofercie publicznej art. 96, obejmując rocznie około 5 procent spółek. Statystyki KNF za 2024 pokazują średnio 30 procent badanych spółek z uchybieniami i obowiązkową publikacją raportu o nieprawidłowościach w EBI. Obszary koncentracji w latach 2024-2026 to utrata wartości firmy wg MSR 36 (ponadprzeciętne 35 procent raportów o nieprawidłowościach), podatki odroczone wg MSR 12 (28 procent), konsolidacja leasingu wg MSSF 16 (24 procent), rachunkowość zabezpieczeń wg MSSF 9 (22 procent) oraz ujawnienia konsolidacyjne wg Taksonomii UE (38 procent). Przy uchybieniach KNF stosuje procedurę dwustopniową: w pierwszym stopniu następuje omówienie z KNF i obowiązkowa publikacja raportu, gdy spółka akceptuje uchybienia; w drugim stopniu uruchamiane jest postępowanie sprawdzające GPW, gdy spółka ich nie akceptuje. Sankcje administracyjne KNF wg art. 96 ust. 1d Ustawy o ofercie publicznej sięgają 10.000.000 zł lub 5 procent rocznego obrotu, a do tego dochodzą publikacja procedury, reakcja kursu akcji (zwykle spadek o 3-8 procent w ciągu trzech dni handlowych po publikacji), dyskusja na walnym zgromadzeniu z prawami zaczepienia akcjonariuszy oraz odpowiedzialność z KKS art. 77 UoR do 21,6 mln zł. Agent na bieżąco dokumentuje zgodność z obszarami koncentracji badania KNF i przygotowuje substantive testing na potrzeby audytu skonsolidowanego sprawozdania wg KSRF 600.

## Szesnaście deterministycznych decyzji konsolidacyjnych i jeden punkt eskalacji do człowieka

Agent rozkłada skonsolidowane sprawozdanie na 16 mikrodecyzji, z których wszystkie poza jednym wskaźnikiem utraty wartości firmy są deterministyczne. Każda decyzja dokumentuje opis kroku, pytanie decyzyjne, klasyfikację decydenta (R dla decyzji regułowej, A dla wskaźnika ML niebędącego decyzją ostateczną, H dla obowiązkowej eskalacji do człowieka), uzasadnienie z cytatem przepisu wraz z audyt-trailem z systemu źródłowego oraz ścieżkę odwołania (vendor, employee, auditor, none). 15 decyzji typu R obejmuje definicję zakresu konsolidacji (UoR art. 55), integrację danych ERP (KSRF 600), przeliczenie walut (MSR 21), mostek multi-GAAP (Polski Ład 2.0), konsolidację kapitałów (UoR art. 60), eliminację rozrachunków (UoR art. 61), eliminację przychodów i kosztów (UoR art. 61), eliminację wyników z transakcji wewnętrznych (UoR art. 61), metodę praw własności (UoR art. 63, MSR 28), Currency Translation Adjustment wraz z Net Investment Hedge (MSSF 9), podatki odroczone (Polski Ład 2.0, MSR 12), ujawnienia konsolidacyjne (UoR art. 63), tagowanie ESEF-iXBRL (Rozporządzenie UE 2019/815) oraz przygotowanie oświadczenia o rzetelności (art. 4a UoR). Decyzja typu A to test utraty wartości firmy wg MSR 36 ze wspomaganą przez ML kontrolą wiarygodności danych wejściowych DCF, WACC i stóp wzrostu - wynik LLM jest jedynie wskaźnikiem, nie decyzją ostateczną, i podlega weryfikacji przez lidera group-controllingu, zewnętrznego rzeczoznawcę oraz opinię audytora, zgodnie z RODO art. 22. Decyzja typu H to eskalacja do komitetu audytu rady nadzorczej wg KSH art. 382 przy klasyfikacji zagrożenia kontynuacji działalności, ocenie going concern oraz odniesieniu się do raportu audytora o nieprawidłowościach - to czysto ludzka decyzja uznaniowa podejmowana przez group-CFO, komitet audytu rady nadzorczej i zewnętrznego audytora.

## Kontrola wiarygodności wobec obszarów koncentracji badania PIBR w latach 2024-2026

Agent prowadzi ciągłą kontrolę wiarygodności wobec obszarów koncentracji badania PIBR w latach 2024-2026. Utrata wartości firmy wg MSR 36 obejmuje analizę wrażliwości DCF, weryfikację WACC, porównanie stóp wzrostu, mnożniki grupy porównawczej oraz identyfikację zdarzeń wyzwalających. Podatki odroczone wg MSR 12 obejmują test realizowalności strat podatkowych, mieszankę grupowych stawek podatkowych oraz Top-Up Pillar Two. Konsolidacja leasingu wg MSSF 16 obejmuje prawo do użytkowania, zobowiązanie leasingowe, korekty indeksacyjne oraz rachunkowość modyfikacji. Rachunkowość zabezpieczeń wg MSSF 9 obejmuje test efektywności, dokumentację zabezpieczenia oraz Net Investment Hedge przy walutowych spółkach zależnych. Ujawnienia konsolidacyjne wg Taksonomii UE obejmują mapowanie PKD, test istotnego założenia oraz zasadę Do No Significant Harm. Dla każdego obszaru koncentracji badania PIBR agent dokumentuje zgodność konsolidacyjną, przygotowuje substantive testing, prowadzi proces audytora grupowego wg KSRF 600 i stosuje środki pozwalające uniknąć raportu KNF o nieprawidłowościach.

## Przypadki szczególne: hiperinflacja wg MSR 29, Pillar Two i restrukturyzacje wg KSH

Skomplikowane scenariusze konsolidacyjne są wyraźnie udokumentowane. Hiperinflacja wg MSR 29 przy spółkach zależnych w Turcji (od 2022), Argentynie i innych krajach hiperinflacji (skumulowana trzyletnia inflacja powyżej 100 procent) wymaga przeszacowania, indeksacji inflacyjnej oraz odrębnego procesu konsolidacyjnego. Minimalny Top-Up Pillar Two dla grup powyżej 750 mln EUR opiera się na modelu OECD, dyrektywie UE 2022/2523 oraz polskiej Ustawie z 18.10.2024 r. o opodatkowaniu wyrównawczym, obowiązującej od 1.01.2025, ze stawką efektywną 15 procent i podatkiem wyrównawczym przy niedoopodatkowanych spółkach grupy. Restrukturyzacje wg KSH (fuzje art. 491-516, podziały i przeniesienia art. 528-550) zmieniają pozycję konsolidacyjną i wpływają na mostek multi-GAAP. Przejęcia etapowe wg MSSF 3 (Business Combinations Achieved in Stages) wymagają przeszacowania dotychczasowego udziału do wartości godziwej oraz przeliczenia wartości firmy. Utrata kontroli kończy konsolidację pełną i prowadzi do reklasyfikacji jako metoda praw własności lub inwestycja finansowa.

## Integracja z polskimi i miedzynarodowymi platformami konsolidacyjnymi

Agent integruje się przez API z wiodącymi polskimi i międzynarodowymi platformami oprogramowania konsolidacyjnego. Comarch ERP XL Konsolidacja i Comarch ERP Performance to polski lider rynku ERP-CPM dla średnich i dużych grup kapitałowych, z raportami konsolidacyjnymi zgodnymi z UoR, eliminacjami transakcji wewnątrzgrupowych, polskim językiem i polskim księgowaniem. SAP S/4HANA Group Reporting wraz z SAP BPC zapewnia zharmonizowane narzędzia konsolidacyjne dla UoR, MSSF i PSR. CCH Tagetik (Wolters Kluwer Polska) oferuje konsolidację zgodną z PSR, moduł metody praw własności oraz test wartości firmy wg MSR 36. Anaplan Polska i Workday Adaptive Planning to platformy chmurowe z modelami konsolidacji, modelowaniem opartym na driverach oraz elastycznymi metodami konsolidacji dla UoR i MSSF. Symfonia ERP, enova365 i Asseco WAPRO ERP zapewniają konsolidację zgodną z UoR dla polskiego sektora MŚP i średnich firm. Oracle EPM Cloud, Oracle FCCS, IBM Cognos Controller oraz OneStream XF Finance Platform obsługują spółki notowane w środowisku multi-GAAP (MSSF i PSR) z testem utraty wartości firmy i przeliczeniem walut. Workiva Wdesk, BlackLine Account Reconciliation i Trintech Cadency wspierają tagowanie ESEF-iXBRL, zarządzanie ujawnieniami konsolidacyjnymi oraz przygotowanie do raportu PIBR o nieprawidłowościach. Dla spółek notowanych tagowanie ESEF-iXBRL przebiega wg taksonomii ESMA ESEF 2024 i Rozporządzenia UE 2019/815, z block-tagowaniem, szczegółowym tagowaniem Primary Statements, walidacją Workiva i złożeniem do GPW. Proces audytora grupowego wg KSRF 600 obejmuje eksport danych substantive testing do Deloitte ASM, PwC Aura, EY Helix i KPMG Clara, z polskim kontekstem konsolidacyjnym. Eskalacja do komitetu audytu rady nadzorczej wg KSH art. 382 i DPSN 2021 obejmuje omówienie uchybień, klasyfikację zagrożenia kontynuacji działalności, przygotowanie oświadczenia o rzetelności wg art. 4a UoR oraz procedurę unikania kar.

--- Agent zgodności umów ---
> Compliance umów zgodnie z PZP 2019, Ustawą AML z 1.03.2018, Ustawą o ochronie konkurencji 2007, RODO i Ustawą o sygnalistach 2024. Cross-check KSeF FA(2), screening UOKiK i KKS art. 56.

Compliance umów w Polsce stanowi kompleksowy system regulacyjny łączący sześć głównych obszarów: PZP 2019 dla zamówień publicznych, Ustawę AML z 1.03.2018 dla przeciwdziałania praniu pieniędzy z weryfikacją beneficjenta rzeczywistego w CRBR, Ustawę o ochronie konkurencji z 2007 ze sankcjami UOKiK do 10 procent obrotu, RODO (art. 28 i 35) dla klauzul powierzenia danych z DPIA, Ustawę o sygnalistach z 2024 (implementacja dyrektywy UE 2019/1937) dla ochrony sygnalistów oraz krzyżową kontrolę KSeF FA(2) obowiązkową od 1.7.2026 dla B2B. Każda umowa w polskiej grupie kapitałowej musi przejść deterministyczny screening przez wszystkie sześć obszarów oraz wygenerować audyt-trail dla KAS, UOKiK, UODO i Big-4 Substantive Testing.

## UOKiK, KKS, RODO i KAS - cztery sankcyjne fronty wymagające Cert-Ready by Design

UOKiK jest jednym z najbardziej aktywnych regulatorów konkurencji w Europie. Sankcje za naruszenia art. 6 (porozumienia ograniczające), art. 9 (nadużycie pozycji dominującej) i art. 13 (niezgłoszone koncentracje) mogą sięgać 10 procent obrotu osiągniętego w poprzednim roku obrotowym. Rejestr klauzul niedozwolonych UOKiK zawiera ponad 7000 niedozwolonych klauzul wzorcowych - każda nowa umowa wzorcowa B2C wymaga screeningu przed publikacją. Audyt podatkowy KAS w 2024 roku wskazał compliance dokumentów umów jako jeden z trzech najczęstszych findingów; typowe nieprawidłowości to brak dokumentacji weryfikacji UBO, brak DPIA dla umów przetwarzania danych osobowych oraz brak krzyżowej kontroli umów z fakturami KSeF FA(2).

KKS art. 56 przewiduje sankcję 30 procent wartości VAT (maksymalnie 21,6 mln zł) oraz ewentualną odpowiedzialność karną z art. 60-61 dla osoby odpowiedzialnej. RODO art. 83 grozi sankcją do 4 procent obrotu lub 20 mln EUR za naruszenie klauzul powierzenia (art. 28) lub brak DPIA (art. 35). Ustawa o sygnalistach z 2024 sankcjonuje retorsje wobec sygnalisty kwotą do 100 procent szkody wraz z odpowiedzialnością karną z art. 218 KK. Ustawa AML przewiduje sankcję GIIF do 5 mln zł za brak identyfikacji UBO. Te cztery fronty oznaczają, że średnia polska firma (200-500 pracowników, 50-200 mln zł obrotu) ma potencjalną ekspozycję sankcyjną rzędu 50-100 mln zł rocznie bez podejścia Cert-Ready by Design.

## 13 deterministycznych punktów decyzyjnych z dwiema eskalacjami ludzkimi

Agent przetwarza umowy przez pipeline 13 strukturalnych punktów decyzyjnych: jedenaście klasyfikacji regułowych, jedną wspomaganą przez LLM ekstrakcję typu umowy oraz dwie eskalacje ludzkie (ocena antykartelowa i ryzyko zarządu wg KSH). Klasyfikację typu umowy wykonuje LLM, wyłuskując z tekstu stronę umowy, wartość, sektor i relacje właścicielskie oraz kategoryzując ją jako PZP, AML-istotną, transakcję z podmiotem powiązanym lub standardową B2B. Pozostałe 11 klasyfikacji przebiega wg Ustawy AML art. 41-42 (sankcje UE i OFAC), Ustawy AML art. 36-39 (UBO w CRBR), RODO art. 28 i 35, PZP art. 28-32 oraz 99-100, Ustawy z 8.03.2013 (terminy płatności), krzyżowej kontroli KSeF FA(2) i KSH art. 393.

Konkretny przykład: średnia polska spółka produkcyjna (350 pracowników, 80 mln zł obrotu) zawiera umowę z dostawcą na usługi IT za 1,2 mln zł rocznie. Agent klasyfikuje ją jako standardową B2B, istotną z perspektywy AML (powyżej 15 tys. EUR), bez powiązań właścicielskich. Screening UBO w CRBR jest pomyślny, dostawca to czynny podatnik VAT, brak go na listach sankcji. Klauzule powierzenia RODO art. 28 sprawdzone, DPIA wykonana. Krzyżowa kontrola KSeF FA(2) ustawiona na cykl miesięczny. Rejestr klauzul niedozwolonych UOKiK: czysty. Termin płatności 30 dni (zgodny z wymogiem dla MŚP wg Ustawy z 8.03.2013). Audyt-trail dla KAS i Big-4 wygenerowany automatycznie. Wartość 1,2 mln zł poniżej 50% kapitału zakładowego oznacza brak wymogu uchwały walnego zgromadzenia. Ocena antykartelowa: brak klauzul ograniczających, akceptacja Compliance Officera.

## Miesięczna krzyżowa kontrola umów z KSeF FA(2)

Od 1 lipca 2026 KSeF jest obowiązkowy dla B2B w Polsce. Faktury wystawione na podstawie umowy muszą mieć numer KSeF i schemat FA(2). Agent miesięcznie waliduje: każda umowa generuje X faktur KSeF zgodnie z harmonogramem płatności, kwoty faktur zgadzają się z umową (tolerancja 5 procent), NIP-y dostawcy i odbiorcy zgadzają się z bazą UBO w CRBR, a klasyfikacja VAT-MPP odpowiada art. 108a Ustawy o VAT (split payment powyżej 15 tys. zł dla pozycji z załącznika nr 15). Niezgodności automatycznie uruchamiają alert dla zespołu Compliance wraz z wpisem do audyt-trailu KAS. Krzyżowa kontrola chroni przed sankcją KKS art. 56 (30 procent wartości VAT, maksymalnie 21,6 mln zł) za nieuwzględnienie faktur i dokumentuje pełny audyt-trail dla kontrolerów KAS.

## Integracja z polskim ekosystemem: Comarch, SAP Ariba, Sygnanet, CRBR, KSeF i UOKiK API

Agent integruje się z polskimi systemami CLM przez API: [Comarch ERP Optima Compliance](https://www.comarch.pl/erp/comarch-erp-optima/) (lider w MŚP z modułem compliance umów), Comarch ERP XL CLM z modułem Compliance (Enterprise i GPW), [SAP S/4HANA Polish Localization Compliance z SAP Ariba](https://www.sap.com/poland/) (multilatinas i spółki GPW), [Symfonia ERP z modułem Compliance](https://www.symfonia.pl/), [enova365 Moduł Compliance](https://www.enova.pl/), Sygnanet (platforma whistleblower certyfikowana w 2024 - implementacja Ustawy o sygnalistach), WAPRO Fakir Pro Compliance oraz InsERT Subiekt nexo Pro Compliance. Integracja z bazami: CRBR API (MF), GIIF API (sankcje), rejestr klauzul niedozwolonych UOKiK, KSeF API z certyfikatem kwalifikowanym (CenCert/Szafir/EuroCert/KIR), VIES (UE) dla operacji wewnątrzwspólnotowych oraz listy sankcyjne EU CFSP i OFAC. Big-4 Substantive Testing wspierane jest przez bezpośredni eksport do Deloitte ASM, PwC Halo, EY Helix i KPMG Clara z metadanymi audyt-trail PCAOB AS 1215.

--- Agent not kredytowych/storn ---
> Klasyfikuje dokumenty przychodzące jako notę kredytową lub fakturę storno, identyfikuje fakturę źródłową.

Błędnie sklasyfikowane noty kredytowe i faktury storno należą do najczęstszych ustaleń VAT przy kontrolach podatkowych. Przyczyna jest niemal zawsze ta sama: dostawcy używają pojęć nieprawidłowo, system ERP przejmuje oznaczenie bez weryfikacji, a księgowość księguje na podstawie błędnej klasy dokumentu. Agent not kredytowych/storn eliminuje to ryzyko, klasyfikując każdy przychodzący dokument korygujący merytorycznie - niezależnie od tego, co jest napisane na dokumencie.

## Korekty VAT kosztują przy kontroli podatkowej miliardy

Wymiar problemu jest mierzalny. W 2024 roku niemieckie organy podatkowe uzyskały z samych specjalnych kontroli VAT dodatkowy wynik 1,63 miliarda EUR z 63 733 kontroli (źródło: BMF, statystyka, czerwiec 2025). To średnio około 25 600 EUR per kontrola. VAT stanowił 12,8 procenta całkowitego dodatkowego wyniku kontroli podatkowych wynoszącego 10,9 miliarda EUR.

Pomylenie noty kredytowej z fakturą storno napędza te liczby. Nota kredytowa w sensie podatku od towarów i usług (odpowiednik niemieckiego Paragraph 14 UStG) jest samodzielnym dokumentem rozliczeniowym wystawianym przez odbiorcę świadczenia. Faktura storno koryguje błędną fakturę wystawcy. Oba rodzaje dokumentów mają odmienne skutki prawne dla odliczenia VAT naliczonego. Kto je myli, ryzykuje, że urząd skarbowy odmówi odliczenia VAT naliczonego - wstecznie, z odsetkami.

## Dostawcy używają pojęć błędnie - a ERP przekazuje błąd dalej

Problem nie zaczyna się we własnej księgowości. Zaczyna się u dostawcy. W praktyce dostawcy regularnie piszą "nota kredytowa" na dokumentach, które podatkowo są fakturami storno. Ustawodawca wyjaśnił, że potoczna "nota kredytowa" nie jest notą kredytową w rozumieniu przepisów o VAT. Ale wielu dostawców nigdy nie dostosowało swoich szablonów dokumentów.

Konkretny scenariusz: firma chemiczna otrzymuje miesięcznie około 200 dokumentów korygujących od 80 dostawców. Około 35 procent tych dokumentów nosi oznaczenie "nota kredytowa", choć merytorycznie są fakturami storno. Pracownik w księgowości zobowiązań musi przy każdym pojedynczym dokumencie sprawdzić cechy merytoryczne, znaleźć fakturę źródłową i określić prawidłowe traktowanie podatkowe. Przy ręcznym przetwarzaniu wskaźnik błędów dla faktur wynosi około 2 procent (źródło: IOFM/Ardent Partners AP Benchmark Report). Przy dokumentach korygujących, które od początku noszą błędne oznaczenie, wskaźnik jest z doświadczenia znacznie wyższy.

## Klasyfikacja merytoryczna zastępuje nagłówek dokumentu

[Decision Layer](/pl/decision-layer/) rozwiązuje ten problem jasnym podziałem: pierwsza decyzja - nota kredytowa czy faktura storno - jest jedyną, która wykorzystuje wsparcie AI. Model językowy analizuje treść dokumentu, nie nagłówek. Sprawdza, kto wystawił dokument, czy korygowana jest faktura oryginalna i jakie skutki prawne wywołuje treść.

Ta klasyfikacja jest celowo zaprojektowana jako poziom 1 w Decision Layer: wspierana przez AI z możliwością ludzkiej weryfikacji. Biegły rewident może odtworzyć każdą pojedynczą decyzję klasyfikacyjną, ponieważ agent dokumentuje, na podstawie jakich cech przypisał dokument. Sześć kolejnych kroków - identyfikacja faktury źródłowej, walidacja kwoty, obliczenie korekty VAT, tworzenie kontrzapisu, zapewnienie powiązania zgodnego z wymogami archiwizacji i weryfikacja traktowania podatkowego - biegnie w pełni regułowo na poziomie 2, bez udziału AI.

## Łańcuch dokumentów staje się dowodem dla kontroli

Zgodność z wymogami archiwizacji (niemiecki standard GoBD (niemiecki standard dokumentacji), Ordynacja podatkowa Art. 86 OP) nie powstaje przez sam system archiwizacji. Powstaje przez ciągłe powiązanie każdego dokumentu korygującego z jego fakturą oryginalną. Agent zapewnia to powiązanie przy każdym przetwarzaniu - przez porównanie numerów referencyjnych i, gdy dostawca nie podaje numeru referencyjnego, przez rozmyte dopasowanie według kwoty, daty i dostawcy.

Przy kontroli podatkowej ujawnia się różnica: zamiast ręcznego przypisywania pojedynczych not kredytowych i storn do ich dokumentów źródłowych, dostępna jest kompletna akt decyzyjna. Dla każdego dokumentu jest odtwarzalne, dlaczego został sklasyfikowany jako nota kredytowa lub storno, jaka faktura oryginalna jest objęta, jak obliczono korektę VAT i jak powstał kontrzapis. To redukuje nakład pracy kontrolnej - zarówno dla własnego zespołu, jak i dla kontrolera.

--- Agent amortyzacji ---
> Określa metodę AfA i okres użytkowania z tabeli BMF, oblicza miesięczne kwoty amortyzacji.

Amortyzacja należy do najbardziej reglamentowanych procesów w rachunkowości finansowej. Metoda AfA, okres użytkowania, podstawa naliczania, zapis księgowy - każdy krok jest zdefiniowany przez ustawę, tabelę lub prawo wyboru. Mimo to księgowość środków trwałych w większości firm wiąże znaczną ręczną zdolność. Powód: pracownicy nawigują między tabelami BMF, progami GWG i regulacjami specjalnymi, bez centralnej logiki zapewniającej spójność. To zmienia się, gdy regułowy agent przejmuje cały łańcuch AfA.

## Kontrolerzy podatkowi korygują błędy AfA, które nie musiałyby się zdarzać

Kontrole podatkowe w 2024 roku przyniosły dodatkowy wynik 10,9 miliarda EUR - przy zaledwie 140 764 skontrolowanych firmach z 8,8 miliona w ewidencji (BMF, raport miesięczny, listopad 2025). Amortyzacja jest przy tym standardowym polem kontrolnym, ponieważ typowe błędy ciągną się przez cały wykaz środków trwałych: błędnie przypisane okresy użytkowania, przeoczone progi GWG, niezastosowana specjalna amortyzacja dla cyfrowych środków trwałych.

Źródła błędów nie leżą przy tym w lukach wiedzy. Powstają, ponieważ pracownik przy 2 000 lub 5 000 środkach trwałych nie sprawdza dla każdego pojedynczego prawidłowej klasy BMF, nie porównuje okresu użytkowania i nie weryfikuje progu dla niskocennych środków trwałych. Wolumen generuje błędy - nie złożoność.

## Każdy krok decyzyjny podlega regułom bez marginesu interpretacji

[Decision Layer](/pl/decision-layer/) rozkłada obliczanie AfA na siedem kroków. Wszystkie siedem jest w pełni regułowych (Horyzont 1 - brak AI, brak ludzkiego uznania w pojedynczym przypadku).

Metoda AfA wynika z danych podstawowych środka i podatkowego prawa wyboru. Okres użytkowania stoi w tabeli AfA BMF. Podstawa naliczania oblicza się według Ustawy o rachunkowości (odpowiednik HGB Paragraph 255) z kosztów nabycia lub wytworzenia. Miesięczna kwota AfA to iloraz. Uprawnienie do specjalnej AfA dla cyfrowych środków trwałych to weryfikacja progu. Zapis księgowy opiera się na stałej logice dekretacji. Weryfikacja GWG porównuje kwotę netto z ustawowym limitem.

Żaden z tych kroków nie wymaga oceny, wyceny ani rozważania. To czyni proces AfA idealnym kandydatem do automatyzacji na najniższym poziomie Decision Layer.

## Producent maszyn z 3 200 środkami trwałymi pokazuje dźwignię

Średniej wielkości producent maszyn zarządza stanem 3 200 pozycji majątku - urządzenia produkcyjne, sprzęt IT, flota, wyposażenie biurowe. Każdego miesiąca księgowość środków trwałych oblicza dla każdego aktywnego środka kwotę AfA i tworzy zapis księgowy. Przy nowych przychodach dochodzi pierwsza wycena: określenie klasy środka, wyszukanie w tabeli BMF, weryfikacja progu GWG, ustalenie metody AfA.

Bez agenta robi to pracownik w systemie ERP - środek po środku, pole po polu. Przy średnim czasie przetwarzania trzech minut per nowy przychód i 40 przychodach w miesiącu to same dwie godziny na pracę rutynową, która nie zawiera żadnego marginesu uznania. Miesięczne przebiegi AfA dochodzą do tego.

Z Agentem amortyzacji system odczytuje klasę środka z danych podstawowych, wyszukuje okres użytkowania w centralnie zapisanej tabeli BMF, oblicza miesięczną kwotę, weryfikuje próg GWG i tworzy zapis księgowy. Cała operacja trwa sekundy zamiast minut - a każde pojedyncze obliczenie jest udokumentowane z zastosowaną regułą i wersją tabeli.

## Tabela BMF staje się centralnie wersjonowaną infrastrukturą

Właściwa wartość nie leży w przyspieszeniu pojedynczych księgowań. Leży w infrastrukturze, która przy tym powstaje. Tabela AfA BMF istnieje w większości firm jako PDF lub jako ręcznie prowadzona tabela danych podstawowych w systemie ERP. Gdy BMF aktualizuje tabelę - ostatnio przy nowej ocenie okresu użytkowania sprzętu komputerowego i oprogramowania - ktoś musi ręcznie pociągnąć zmianę.

W Decision Layer tabela BMF staje się centralnie wersjonowanym silnikiem reguł. Aktualizacja działa natychmiast na wszystkie nowe obliczenia AfA. Stara wersja pozostaje udokumentowana dla istniejących środków. A przy kontroli podatkowej dla każdego pojedynczego środka można odtworzyć, jaka wersja tabeli obowiązywała w momencie pierwszej wyceny.

Ta infrastruktura jest używana nie tylko przez Agenta amortyzacji. Agent przychodów środków trwałych, Agent inwentaryzacji i Agent sprawozdania rocznego korzystają z tej samej wersjonowanej tabeli. Logika weryfikacji GWG jest ponownie wykorzystywana przez Agenta dekretacji. Co zaczyna się jako pojedynczy proces amortyzacji, staje się fundamentem całej księgowości środków trwałych.

## Dowód kontrolny powstaje jako produkt uboczny

Dla CFO decydującym pytaniem nie jest, czy obliczanie AfA przebiega szybciej. Decydującym pytaniem jest, czy wytrzyma kolejną kontrolę podatkową. Przy wskaźniku kontroli 29,6 procenta dla dużych przedsiębiorstw (BMF 2024) to nie jest rozważanie teoretyczne.

Regułowy agent generuje dowód kontrolny jako produkt uboczny każdego obliczenia: zastosowana metoda AfA, wersja tabeli BMF, koszty nabycia, ścieżka obliczeniowa, weryfikacja GWG, weryfikacja specjalnej AfA. Wykaz środków trwałych na sprawozdanie roczne buduje się z tych udokumentowanych pojedynczych decyzji - nie z wstecznej rekonstrukcji.

--- Agent windykacji ---
> Windykacja polubowna i sądowa: naliczanie odsetek wg KC art. 481, wpis do KRD oraz postępowanie nakazowe, w pełni zgodnie z RODO.

Windykacja w Polsce to pipeline prawno-finansowy z sześcioma równoległymi podstawami: Kodeks Cywilny (Ustawa z 23.04.1964) reguluje wymagalność i odsetki (art. 481, art. 482, art. 455), Ustawa z 8.03.2013 o przeciwdziałaniu nadmiernym opóźnieniom w transakcjach handlowych narzuca terminy maksymalne 60/30 dni, podwyższone odsetki za opóźnienie (art. 4a) oraz rekompensatę 40/70/100 EUR (art. 10), Ustawa z 9.04.2010 o udostępnianiu informacji gospodarczych reguluje wpis do KRD/BIG InfoMonitor/ERIF z wezwaniem 30-dniowym, Kodeks Postępowania Cywilnego (Ustawa z 17.11.1964) określa postępowanie nakazowe (art. 485-505) i upominawcze (art. 498), e-Sąd Lublin (EPU) i egzekucję komorniczą (art. 776-1095), RODO art. 6 ust. 1 lit. f wymaga testu LIA dla podstawy prawnej, a Ustawa o CIT art. 16 ust. 1 pkt 26a wraz z Ustawą o PIT art. 22p określają warunki odpisu aktualizującego jako koszt podatkowy. Każdy etap pipeline ma własny termin, podstawę prawną i format - błąd w wezwaniu 30-dniowym przed wpisem do KRD wystarczy do odpowiedzialności odszkodowawczej i kary administracyjnej UODO.

## Kara UOKiK do 10% obrotu i utrata kosztu podatkowego według art. 22p Ustawy o PIT/CIT

Niewłaściwa windykacja generuje pasywo na trzech frontach jednocześnie. UOKiK na podstawie art. 24 ustawy z 16.02.2007 o ochronie konkurencji i konsumentów może nałożyć karę do 10% obrotu rocznego (art. 106) za praktyki naruszające zbiorowe interesy konsumentów - typowo: grożenie postępowaniem karnym, zawyżone koszty windykacji ponad rekompensatę ustawową, wielokrotne kontakty po godzinie 22:00, kontakt z osobami trzecimi (rodzina dłużnika, pracodawca). Dla średniej polskiej firmy z 200 mln zł rocznego obrotu potencjalna kara to 20 mln zł. UODO (Urząd Ochrony Danych Osobowych) na podstawie RODO art. 83 może nałożyć karę do 4% obrotu lub 20 mln EUR za bezpodstawny wpis do KRD/BIG bez wezwania 30-dniowego (test sprawy R.M. vs Provident Polska 2020 - kara 1,1 mln zł).

Najgorsze: faktura z niewłaściwie zaksięgowanym odpisem aktualizującym (art. 16 ust. 1 pkt 26a Ustawy o CIT bez spełnienia warunków art. 16 ust. 2a) skutkuje korektą kosztów podatkowych z odsetkami za zwłokę 14,5% w skali roku plus karą 75% (art. 56 Kodeksu Karnego Skarbowego) lub nawet 150% w przypadku kwalifikacji jako oszustwo. Dla średniej firmy z portfelem 80 mln zł, błędne odpisy 5 mln zł generują dodatkowe zobowiązanie podatkowe: CIT 19% = 950 tys zł, kara 75% = 712 tys zł, odsetki za 24 miesiące = 230 tys zł = łącznie ponad 1,9 mln zł korekty. Summa summarum: łączna kara UOKiK, UODO i KAS może osiągnąć 25-30% wartości portfela rocznego w scenariuszu kontroli zsynchronizowanej.

## Polska windykacja przechodzi 15 deterministycznych etapów - więcej niż w Niemczech (8) lub Brazylii (14)

Polski system windykacji jest jednym z najbardziej rozbudowanych w UE ze względu na trójwarstwową regulację: cywilną (KC), procesową (KPC z postępowaniem nakazowym, upominawczym i e-Sądem Lublin EPU), informacyjno-gospodarczą (Ustawa z 9.04.2010 z trzema BIG: KRD, InfoMonitor, ERIF) i podatkową (Ustawa o CIT art. 16). 15 deterministycznych etapów to: identyfikacja faktury KSeF FA(2) przeterminowanej, klasyfikacja aging w pięciu przedziałach (1-30/31-60/61-90/91-180/180+ dni), rozróżnienie B2B (transakcja handlowa Ustawa z 8.03.2013) vs B2C (Ustawa o prawach konsumenta), sprawdzenie blokady wezwania, wyliczenie odsetek (KC art. 481 § 2 lub art. 4a Ustawy z 8.03.2013), naliczenie rekompensaty 40/70/100 EUR, wezwanie polubowne, wezwanie 30-dniowe z ostrzeżeniem o KRD, równoległy wpis do trzech rejestrów BIG (KRD, InfoMonitor, ERIF), weryfikacja przedawnienia w pięciu kategoriach (KC art. 118, 554, 792, 646 oraz art. 123 o przerwaniu biegu), uzgodnienie wpłaty pośredniej przez Open Banking PSD2 i ELIXIR NBP, decyzja o trybie sądowym (postępowanie nakazowe KPC art. 485 vs upominawcze art. 498 vs e-Sąd Lublin EPU dla spraw do 100 tys zł), egzekucja komornicza po uprawomocnieniu, odpis aktualizujący zgodny z Ustawą o CIT art. 16 i decyzja strategiczna o sprzedaży wierzytelności (Kruk, BEST, KrukLab).

Scenariusz konkretny: zakład produkcyjny we Wrocławiu z portfelem należności 80 mln zł, 6500 otwartych pozycji, 70% B2B (Volkswagen Poznań, Bosch Mirków, Lidl Polska) i 30% B2C (sklep firmowy detaliczny). W każdy piątek o 6:00 Agent identyfikuje 950 faktur przeterminowanych powyżej 1 dnia roboczego, klasyfikuje każdą w odpowiednim przedziale aging, rozdziela B2B handlowe od B2C konsumenckiego stosując odmienne stopy odsetek (15,75% vs 11,25% w skali roku), weryfikuje 65 blokad wezwań (otwarte korekty faktur, ugody płatnicze), wysyła 290 wezwań polubownych pierwszego stopnia, wysyła 220 wezwań 30-dniowych z ostrzeżeniem o KRD, wpisuje 145 dłużników równolegle do KRD, BIG InfoMonitor i ERIF (skuteczność 25-40% wyższa niż wpis do jednego BIG), generuje 38 pozwów do e-Sądu Lublin EPU dla spraw poniżej 100 tys zł, identyfikuje 14 wierzytelności na granicy przedawnienia (sygnalizuje pilne wezwanie sądowe wg KC art. 123).

W [Decision Layer](/pl/decision-layer/) 14 z 15 etapów to decyzje regułowe (poziom R). Jedyna decyzja ludzka to wybór między windykacją własną a sprzedażą pakietu wierzytelności, ponieważ wymaga oceny strategicznej cash-flow, relacji z kluczowym klientem B2B, ceny rynkowej pakietu (typowo 5-15% wartości nominalnej dla 90-180 dni, 0,5-3% dla 360+ dni) i wpływu na CIT (przychód ze sprzedaży pomniejszony o stratę podatkową). Nie ma punktu, w którym analityk windykacji musi podejmować decyzję dyskrecjonalną w fazie polubownej lub sądowej - każde wyliczenie to zastosowanie KC, Ustawy z 8.03.2013, Ustawy z 9.04.2010, KPC, Ustawy o CIT lub Ustawy o komornikach sądowych.

## Uzgodnienie wpłat przez Open Banking PSD2 i ELIXIR przed każdym wezwaniem

Windykacja zautomatyzowana bez uzgodnienia to gwarancja skargi do UOKiK i pozwu o naruszenie dóbr osobistych. Klient płaci przez ELIXIR ekspres w czwartek o 18:47, Agent wysyła wezwanie w piątek o 7:00 bez pobranego wyciągu MT940 z banku - klient otrzymuje wezwanie kwoty już zapłaconej, składa skargę do UOKiK na praktykę naruszającą zbiorowe interesy konsumentów (art. 24 ustawy o ochronie konkurencji), ewentualnie pozew z KC art. 24 (ochrona dóbr osobistych) z odszkodowaniem typowym 3000-15 000 zł. Sąd Najwyższy w wyroku V CSK 304/14 potwierdził, że wielokrotne bezpodstawne wezwania mogą stanowić naruszenie godności (KC art. 23) i godzić w prawo do prywatności (RODO art. 6 ust. 1 lit. f wymaga równoważenia z prawami osoby).

Dlatego 11 etap pipeline to obowiązkowe uzgodnienie przed każdym wysłaniem. Agent pobiera wyciąg MT940/MT942 z poprzedniego dnia roboczego, integruje powiadomienia ELIXIR ekspres przez Open Banking PL (PSD2 - direktywa UE 2015/2366 implementowana w Polsce w Ustawie o usługach płatniczych z 19.08.2011), porównuje wpłaty po numerze IBAN, tytule i kwocie, a następnie automatycznie zarachowuje płatności na poczet odsetek przed kapitałem zgodnie z KC art. 451 § 1. Wpłaty częściowe są rozliczane proporcjonalnie z wskazaniem dłużnika (KC art. 451 § 2 - imputacja przez wierzyciela, jeśli dłużnik nie wskazał). Tylko należności rzeczywiście otwarte po uzgodnieniu trafiają do dalszego pipeline windykacji.

## Przedawnienie, postępowanie nakazowe i e-Sąd Lublin EPU wymagają precyzji bez tolerancji

Przypadki specjalne jak przedawnienie (KC art. 118, 554, 792), postępowanie nakazowe (KPC art. 485 z dokumentem dowodowym) i e-Sąd Lublin EPU (sprawy do 100 tys zł online) wydają się skomplikowane, ale są w pełni zdeterminowane prawem polskim. Faktura VAT z handlu B2B przedawnia się w 3 lata od wymagalności (KC art. 118 dla działalności gospodarczej), umowa sprzedaży konsumentowi w 2 lata (KC art. 554), świadczenia okresowe (czynsz, abonament) w 3 lata (KC art. 118). Wpis sądowy lub wniosek o nadanie klauzuli wykonalności przerywa bieg przedawnienia (KC art. 123 § 1 pkt 1) - dlatego strategiczne znaczenie ma terminowe skierowanie pozwu do e-Sądu Lublin EPU przy zbliżającym się terminie.

Postępowanie nakazowe (KPC art. 485) wymaga dokumentu udowadniającego roszczenie: faktura VAT podpisana przez dłużnika (papierowo lub kwalifikowanym e-podpisem), weksel, czek, uznanie długu pisemne, potwierdzenie salda lub umowa pisemna z określoną kwotą. Opłata sądowa 1,25% wartości przedmiotu sporu (zwracana w przypadku zapłaty), nakaz zapłaty stanowi tytuł zabezpieczenia z urzędu (KPC art. 492 - bez konieczności wniosku o zabezpieczenie powództwa), 14 dni na zarzuty od doręczenia. Postępowanie upominawcze (KPC art. 498) - opłata 5%, 14 dni na sprzeciw. e-Sąd Lublin EPU dla spraw do 100 tys zł - elektroniczny pozew z opłatą 1,25%, czas wydania nakazu 7-21 dni typowo, automatyczne doręczenie elektroniczne. Agent dobiera tryb na podstawie dokumentów w aktach: faktura podpisana = nakazowy, faktura niepodpisana ale uznana = upominawczy, sprawa do 100 tys zł = EPU.

## Integracja z polskim ekosystemem: Comarch, Symfonia, enova, KRD, ELIXIR, e-Sąd

Agent łączy się z głównymi ERPami polskiego rynku przez API: [Comarch ERP Optima/XL](https://www.comarch.pl/erp/comarch-erp-optima/) (lider w MŚP z modułem windykacji), [Symfonia Handel i Finanse](https://www.symfonia.pl/) oraz Sage Symfonia (silne w średnich firmach), [enova365 Handel i Windykacja](https://www.enova.pl/), InsERT Subiekt nexo, SAP S/4HANA Polish Localization (Volkswagen Poznań, BMW Wrocław, Stellantis Tychy, Bosch Mirków). Sprawdzenie i wpis do biur informacji gospodarczej używa API KRD BIG, BIG InfoMonitor i ERIF BIG - wpis równoległy do trzech rejestrów zwiększa skuteczność windykacji o 25-40% (kontrahenci sprawdzają wszystkie trzy przed transakcją). Uzgodnienie bankowe używa MT940/MT942, ELIXIR NBP (dla wpłat ekspresowych) i Open Banking PSD2 dla bieżącej widoczności salda. Pozwy sądowe składane przez e-Sąd Lublin EPU z certyfikatem kwalifikowanym CenCert/Szafir/EuroCert. Egzekucja komornicza przez OGNIVO 2.0 (system zajęć rachunków bankowych po reformie 2018). Dla firm z matką w UE (Volkswagen, Bosch, BMW, Stellantis z polskimi oddziałami), Agent generuje równolegle raporty IFRS 9 (Financial Instruments - Expected Credit Loss) dla konsolidacji w siedzibie głównej - utrzymując operację lokalną zgodną z KC i KPC, a raportowanie do matki pod standardami międzynarodowymi.

--- Agent Reprezentacji ---
> Koszty reprezentacji w Finance: CIT art. 16 ust. 1 pkt 28 brak odliczalności reprezentacji, VAT art. 88 ograniczenie odliczenia podatku naliczonego, walidacja pól obowiązkowych.

Dokumenty gastronomiczne nie padają przy kontroli podatkowej na błędnych kwotach. Padają na brakujących danych obowiązkowych - na błędzie formalnym, który niszczy cały odliczenie kosztów działalności. Przy 10,9 miliarda EUR dodatkowego wyniku z kontroli podatkowych w 2024 roku (źródło: BMF, raport miesięczny, listopad 2025) koszty gastronomiczne należą do pozycji, które kontrolerzy systematycznie sprawdzają. Każdy dokument bez kompletnych danych jest trafieniem.

## Błędy formalne niszczą cały odliczenie kosztów działalności

Arytmetyka jest prosta: 70 procent odliczalne, 30 procent nie. Na tym nikt nie pada. Problem leży w pięciu danych obowiązkowych według niemieckiego prawa podatkowego (Paragraph 4 Abs. 5 Nr. 2 EStG): miejsce, data, uczestnicy, powód biznesowy i kwota. Gdy brakuje jednego z nich, urząd skarbowy nie skreśla 30 procent - skreśla wszystko. Miejsce i data stoją na rachunku restauracyjnym. Przy uczestnikach i powodzie robi się krytycznie. W praktyce najczęściej brakuje kompletnej listy uczestników lub powód biznesowy jest tak niejasno sformułowany - "kolacja biznesowa" bez dalszego wyjaśnienia - że nie jest uznawany podatkowo.

Konkretny scenariusz: dyrektor sprzedaży zaprasza czterech klientów po prezentacji produktu. Rachunek na 480 EUR jest poprawny, restauracja zamieściła wszystkie dane na paragonie kasowym. Ale na dokumencie gastronomicznym pod powodem stoi tylko "spotkanie z klientem", a w uczestnikach brakuje jednego nazwiska. Przy kontroli podatkowej trzy lata później 480 EUR kosztów działalności jest skreślone - nie dlatego, że kwota była nieadekwatna, lecz dlatego, że dwa wiersze były niekompletne.

## Pismo BMF z 2025 roku zaostrza wymagania

Pismem BMF z 19 listopada 2025 roku niemiecka administracja podatkowa sprecyzowała obowiązki dowodowe dla kosztów gastronomicznych. Restauracje z elektronicznym systemem kasowym muszą tworzyć dowody maszynowo i zabezpieczać je certyfikowanym urządzeniem technicznym (TSE). Ręczne pokwitowania lub proste wydruki bez oznaczenia TSE nie są już akceptowane. Dla firm oznacza to: nawet merytorycznie poprawny dokument gastronomiczny może upaść, jeśli leżący u podstaw rachunek restauracyjny nie spełnia nowych wymogów formalnych. Prawidłowy dowód rozpoznaje się po numerze transakcji, numerze seryjnym systemu kasowego lub wydrukowanym kodzie QR.

## Dziewięć kroków decyzyjnych między dokumentem a zapisem księgowym

[Decision Layer](/pl/decision-layer/) rozkłada weryfikację dokumentów gastronomicznych na dziewięć kroków z jasnym przypisaniem: kto decyduje - silnik reguł, AI czy człowiek?

Klasyfikacja dokumentu rozpoznaje przez LLM, czy w ogóle jest to dokument gastronomiczny. Następnie silnik reguł weryfikuje deterministycznie pięć danych obowiązkowych i kompletność listy uczestników. To są pytania binarne - obecne lub nie. Tu nie ma marginesu uznania i powodu dla ludzkiej interwencji.

Wiarygodność powodu biznesowego ocenia LLM. "Spotkanie projektowe digitalizacja logistyki z firmą X" jest wiarygodne. "Kolacja" nie jest. Model rozpoznaje wzorce i w przypadku niewystarczających danych wzywa składającego do uzupełnienia - zanim dokument trafi do księgowości.

Odliczalność (podział 70/30), odliczenie VAT naliczonego i dekretacja biegną regułowo. Archiwizacja zgodna z wymogami ze znacznikiem czasu zamyka proces. Wszystkie dziewięć kroków jest udokumentowanych i odtwarzalnych dla późniejszej kontroli podatkowej.

## Adekwatność pozostaje decyzją ludzką

Jednego kroku decyzyjnego świadomie nie przejmuje żaden algorytm: weryfikacji adekwatności. Czy 120 EUR na osobę przy kolacji biznesowej z trzema klientami jest adekwatne, zależy od branży, kontekstu i relacji biznesowej. Kolacja w ramach negocjacji umowy podlega innym kryteriom niż lunch po pierwszym spotkaniu. Agent dostarcza decydentowi fakty - kwota per osoba, porównanie z wartościami historycznymi, stosunek do wolumenu biznesowego. Zatwierdzenie lub eskalację podejmuje człowiek.

To rozgraniczenie nie jest deficytem technicznym. To governance. Agent dokumentów gastronomicznych, który samodzielnie orzekałby o adekwatności, automatyzowałby decyzje uznaniowe, które w razie wątpliwości kontroler podatkowy zakwestionuje. Odpowiedzialność pozostaje tam, gdzie należy.

--- Agent raportowania ESG ---
> Raportowanie zrównoważonego rozwoju zgodne z CSRD i standardami ESRS, z mapowaniem na Taksonomię UE oraz UoR art. 49b-49c.

Polska gospodarka stanęła przed największą zmianą w raportowaniu od czasu wprowadzenia MSSF w 2005 roku - CSRD Dyrektywa 2022/2464 implementowana nowelizacją Ustawy o rachunkowości z 18.07.2023 obejmuje stopniowo 3.500-4.000 polskich spółek (433 emitentów GPW oraz tysiące dużych niegiełdowych i giełdowych MŚP) z 1144 datapoints ESRS rozporządzenia 2023/2772. Same emisje Scope 1/2/3 wymagają zbierania danych z systemów energetycznych KOBiZE i URE, faktur paliwowych z ERP, danych dostawców z KSeF FA(2) od 1.7.2026 oraz wskaźników LCA Sphera/ecoinvent. Polska Polityka Energetyczna 2040 oraz Krajowy Plan na rzecz Klimatu 2030 wymagają redukcji emisji o 55% do 2030 względem 1990 oraz neutralności klimatycznej do 2050 - cel niemożliwy bez systematycznego raportowania ESG. Każda spółka średnia i duża musi udokumentować zgodność systemu raportowania ESG z KSRF 540 (odpowiednik ISA 540 Revised wg PIBR), UoR art. 65 ust. 1 (Limited Assurance 2024-2028, docelowo Reasonable Assurance) oraz GPW Dobre Praktyki Spółek Notowanych 2021, pod nadzorem KNF dla emitentów i PANA dla biegłych rewidentów.

## Wielowarstwowy ESG governance wymagający Cert-Ready by Design: obowiązek CSRD, UoR art. 49b, nadzór KNF, integracja KSeF FA(2) oraz KSRF 540 Substantive Testing

GPW (Giełda Papierów Wartościowych) jest w 2026 europejskim liderem we wdrażaniu ESG Reporting Guidelines 2.0 - 433 emitentów rynku regulowanego raportuje 33 wskaźniki E/S/G (10 środowiskowych, 10 społecznych, 13 corporate governance) zgodnie z TCFD, SASB, GRI oraz IFRS Sustainability Standards. KNF nadzoruje raporty ESG emitentów oraz SFDR Rozporządzenie 2019/2088 dla TFI i ASI - sankcje art. 34 Ustawy o nadzorze nad rynkiem kapitałowym sięgają 5 mln zł obok odpowiedzialności cywilnej członków zarządu. Brak raportowania CSRD lub greenwashing w Taksonomii UE skutkuje sankcjami UOKiK do 10% obrotu rocznego firmy, odpowiedzialnością cywilną wobec inwestorów GPW (art. 91 Ustawy o ofercie publicznej) oraz utratą wiarygodności w indeksach ESG (WIG ESG, FTSE4Good).

Ministerstwo Finansów wprowadziło KSeF FA(2) jako obowiązkowy mechanizm cross-check transakcji od 1.7.2026 - dla raportowania ESG to fundamentalna zmiana, ponieważ Scope 3 (15 kategorii GHG Protocol) wymaga walidacji wolumenów zakupów od dostawców z wysokim PKD-impact (energetyka, chemia, transport, metalurgia). Agent buduje graf zakupowy z UUID Ministerstwa Finansów - rozbieżności >5% wobec deklaracji ESRS sygnalizują fraud lub błąd metodyczny dla biegłego rewidenta wg KSRF 540 par. 8-13. Polski Lad 2.0 wprowadził ulgi inwestycyjne ESG (ulga na ekspansję, robotyzację, B+R z komponentem ESG) - KAS audytuje deklaracje ulg podatkowych cross-checking z raportem ESG Taksonomii UE eligibility. Średnia polska spółka GPW (1.000-3.000 pracowników, 500 mln-2 mld zł obrotu) ma potencjalną kumulacyjną ekspozycję sankcyjną 50-300 mln zł rocznie bez Cert-Ready by Design CSRD raportowania.

## 16 deterministycznych punktów decyzyjnych z trzema eskalacjami ludzkimi

Agent przetwarza każdy roczny cykl raportowania ESG przez pipeline 16 strukturalnych punktów decyzyjnych: trzynaście klasyfikacji regułowo-AI oraz trzy eskalacje ludzkie (analiza podwójnej istotności, klasyfikacja Taksonomii UE oraz zatwierdzenie zarządu). Klasyfikację obowiązku raportowania CSRD wykonuje silnik reguł sprawdzający progi UoR art. 49b ust. 1-3 (>250 pracowników oraz 40 mln EUR przychodu lub 20 mln EUR sumy bilansowej) wobec danych KRS, GUS REGON, sprawozdań finansowych oraz statusu GPW. Mapowanie 1144 datapoints ESRS przebiega regułowo wg drzewa decyzyjnego na podstawie wyniku oceny istotności. Zbieranie danych Scope 1/2 jest deterministyczne i korzysta z KOBiZE, URE, faktur energetycznych oraz KSeF FA(2). Walidację KPI ESG wykonuje silnik formuł wg ESRS 1 par. 95-104 oraz załącznika I rozporządzenia 2023/2772.

Konkretny przykład: średniej wielkości polski producent chemiczny notowany na GPW (1.800 pracowników, 850 mln zł obrotu, sektor chemia z PKD 20.16 wskaźnikiem CO2 wysokim) sporządza pierwszy raport CSRD za rok obrotowy 2025 (publikacja 2026). Agent w czwartym kwartale 2025 wykonuje: (1) walidację obowiązku raportowania CSRD - spółka spełnia 3 z 3 kryteriów UoR art. 49b ust. 1, etap drugi (rok obrotowy 2025); (2) mapowanie istotnych datapoints ESRS na podstawie analizy podwójnej istotności wykonanej w pierwszym kwartale - z 1144 datapoints zostaje 387 obowiązkowych po wynikach (E1 klimat 142, E2 zanieczyszczenie 45, E5 cyrkularność 18, S1 Workforce 124, G1 Business Conduct 38 oraz ESRS 2 General 20); (3) zbieranie Scope 1 z KOBiZE - 287.450 tCO2e z 4 instalacji ETS oraz paliw kotłowych; (4) Scope 2 location-based 145.230 tCO2e (KOBiZE wskaźnik 758 kgCO2/MWh) oraz market-based 89.120 tCO2e (gwarancje pochodzenia URE 38% zielonej energii); (5) Scope 3 hybrydowo - 1.245.300 tCO2e z 15 kategorii GHG Protocol, 250 największych dostawców activity-based, reszta spend-based EXIOBASE; cross-check KSeF FA(2) wykrył rozbieżność 7,2% w kategorii 1 (Purchased Goods) sygnalizując potrzebę dialogu z 12 dostawcami; (6) klasyfikacja Taksonomii UE - 18% Turnover aligned (climate mitigation oraz zgodność z DNSH), 32% CapEx aligned (inwestycja w odnawialne źródła oraz efektywność energetyczną); (7) ESRS S1 Workforce - 1.800 FTE z gender pay gap 8,2% oraz udziałem 34% kobiet w zarządach, z anonimizacją RODO art. 9; (8) walidacja KPI, tagowanie iXBRL ESEF oraz spójność z RZiS - rozbieżność energii 0,8% akceptowalna; (9) projekt narracji LLM dla 11 standardów ESRS przekazany Komitetowi ESG; (10) audit-trail dla biegłego rewidenta PIBR z dokumentacją metodyki Scope 3 wg KSRF 540. Komitet Audytu rady nadzorczej zatwierdza raport po przeglądzie biegłego rewidenta Limited Assurance, zarząd osobiście attestuje, publikacja na GPW iXBRL ESEF.

## Continuous Monitoring i pętla zwrotna ML redukują czas badania biegłego rewidenta o 40-50 procent

W pierwszym roku raportowania CSRD czas Komitetu ESG na zebranie 1144 datapoints, analizę istotności oraz klasyfikację Taksonomii UE wynosi zwykle 1.500-2.500 godzin zgodnie z benchmarkami EFRAG 2024 - co znacząco obciąża zespoły finansowe sporządzające równolegle sprawozdanie roczne. Agent stosuje aktywną pętlę zwrotną ML: każda klasyfikacja Taksonomii UE przez Komitet ESG (krok 7 microDecisions) trafia do ponownego treningu modelu zgodnie z RODO art. 22 (zautomatyzowane decyzje z prawem do interwencji ludzkiej). Po 12-18 miesiącach pętla zwrotna redukuje czas zbierania datapoints o 60-70 procent oraz czas badania biegłego rewidenta wg KSRF 540 o 40-50 procent. Dashboard ESG pokazuje w czasie rzeczywistym: liczbę zebranych datapoints, status walidacji, emisje Scope 1/2/3, udział Taksonomii aligned, status badania biegłego rewidenta oraz harmonogram publikacji - kwartalne raporty do Komitetu Audytu rady nadzorczej zgodnie z KSH art. 391 oraz GPW Dobre Praktyki Spółek Notowanych 2021.

## Edge-cases polskie: GPW Catalyst, sektor energetyczny ETS, spółki Skarbu Państwa, multilatinas, TFI/ASI SFDR

Polskie spółki notowane GPW mają obowiązki Dobrych Praktyk Spółek Notowanych 2021: roczny raport komitetu audytu o systemie raportowania ESG, ujawnienie istotnych ryzyk ESG w sprawozdaniu rocznym oraz opis polityk Diversity & Inclusion w prospekcie emisyjnym. Sektor energetyczny objęty EU ETS (Emissions Trading System) raportuje dodatkowo do KOBiZE, w ramach Krajowego Planu Rozdziału Uprawnień (KPRU) oraz Polityki Energetycznej 2040 - synergia z ESRS E1-6 (Scope 1) eliminuje duplikację raportowania. Spółki Skarbu Państwa pod nadzorem NIK (Najwyższa Izba Kontroli) raportują dodatkowo do MAP (Ministerstwo Aktywów Państwowych) i obejmują system raportowania ESG kontrolą NIK z sankcjami art. 30 Ustawy o NIK; raport ESG jest częścią oceny realizacji celów strategicznych spółek Skarbu Państwa. Multilatinas z polskim oddziałem dostosowują globalne ramy SBTi (Science Based Targets initiative), TCFD, GRI oraz IFRS Sustainability Standards do polskich KSRF 540, UoR art. 49b-49c oraz GPW Guidelines 2.0 - cross-mapping wymaga potwierdzenia biegłego rewidenta PIBR. TFI i ASI objęte SFDR 2019/2088 wykonują look-through na poziomie spółek portfelowych - synergia z CSRD redukuje koszty ankiet ESG do spółek portfelowych. GPW Catalyst (rynek obligacji) wprowadza Sustainable Bond Standards 2024 wymagające zgodności z ICMA Green Bond Principles oraz EU Green Bond Standard.

## Integracja z polskim ekosystemem: Comarch ESG, SAP Sustainability, Workiva, Persefoni, Symfonia, KSeF, KOBiZE

Agent integruje się z polskim ekosystemem ESG i ERP przez API: [Comarch ESG i ERP XL](https://www.comarch.pl/erp/comarch-erp-xl/) (lider w segmencie Enterprise i GPW, z modułem raportowania zrównoważonego rozwoju), [SAP Sustainability Control Tower i SAP S/4HANA Polish Localization](https://www.sap.com/poland/) (multilatinas i emitenci GPW WIG20 z SAP Sustainability Footprint Management), Workiva ESG Reporting (domyślne dla Big-4 w tagowaniu iXBRL ESEF, z audyt-trailem KSRF 540), Persefoni Climate Disclosure Platform (specjalizacja Scope 1/2/3 zgodne z GHG Protocol i TCFD), Microsoft Sustainability Manager (środowisko Azure, integracja z Microsoft 365 i Dynamics 365 PL), [Symfonia ERP z Modułem Raportowania ESG](https://www.symfonia.pl/) (średni biznes), [enova365 ESG](https://www.enova.pl/) (lokalizacja PL z mapowaniem na PKD), Asseco Softlab ESG i GRC (sektor publiczny), AuditBoard ESG (lokalizacja PIBR z workflow KSRF 540 i 705) oraz Sphera Corporate Sustainability i EHS (przemysł ciężki). Integracja z bazami zewnętrznymi obejmuje: KSeF FA(2) API z certyfikatem kwalifikowanym (CenCert/Szafir/EuroCert/KIR) do krzyżowej kontroli Scope 3, KOBiZE API (rejestr emisji ETS oraz KPRU), URE (audyt energetyczny art. 36 Ustawy o efektywności energetycznej), GUS REGON, KRS API, benchmarki z bazy EFRAG, wskaźniki emisji GHG Protocol oraz EXIOBASE 3.8.2, USEEIO i ecoinvent v3.10 dla Scope 3 spend-based. Badanie Big-4 wg KSRF 540 jest wspierane bezpośrednim eksportem do Deloitte ASM, PwC Halo, EY Helix i KPMG Clara z metadanymi audyt-trail PCAOB AS 1215, EFRAG IG 1-3 oraz ESRS XBRL Taxonomy v1.0. Audyt-trail jest przechowywany 10 lat zgodnie z UoR art. 73, dodatkowo 5 lat po publikacji raportu zgodnie z CSRD oraz w ramach dokumentacji KSRF 540 par. 39 na potrzeby nadzoru PANA.

--- Agent prognozy finansowej FP&A ---
> Agent prognozuje P&L, EBITDA, przychody, marże zgodnie z KSH art. 233, UoR art. 49-54, KSR 4/6/9, MSR 1/8/36 dla emitentów GPW oraz KSRF 540 - Cert-Ready dla biegłego rewidenta PIBR + KNF + Rady Nadzorczej.

Polska gospodarka 2026 stoi przed największą zmianą w zarządzaniu prognozą P&L od czasu wprowadzenia MSSF w 2005 roku. Połączenie obowiązkowego od 1.7.2026 KSeF FA(2) (cross-check przychodów i kosztów B2B z UUID Ministerstwa Finansów), wymagającego perspektywy rozwoju sprawozdania z działalności KSR 9, MSR 1, 8 i 36 dla emitentów GPW oraz Substantive Testing wg KSRF 540 i 320 wymusza na średnich i dużych polskich spółkach (powyżej 250 pracowników, UoR art. 64 ust. 1) systematyczne prognozowanie P&L z audit-trailem dla biegłego rewidenta PIBR, KAS, KNF oraz Komitetu Audytu Rady Nadzorczej. KSH art. 233 (obowiązek bieżącej kontroli sytuacji finansowej spółki przez zarząd) oraz art. 299 (osobista odpowiedzialność członków zarządu sp. z o.o. za zobowiązania niezaspokojone) tworzą bezprecedensowy poziom ryzyka osobistego CFO i zarządu, w którym prognoza P&L jest kluczowym elementem systemu kontroli wewnętrznej. 51 procent CFO wymienia dokładność prognozy jako jeden z pięciu najważniejszych priorytetów (Gartner CFO Survey 2025), a KPMG pokazuje, że firmy z wysoką jakością danych dostarczają wiarygodne prognozy 3,5 razy częściej niż firmy z lepszymi modelami, lecz gorszymi danymi.

## Kontrola finansowa zarządu wg KSH art. 233, rekomendacja KNF D oraz sprawozdanie z działalności wg UoR art. 49-54 i Substantive Testing KSRF 540 i 320 składają się na wielowarstwowy governance FP&A wymagający Cert-Ready by Design

GPW (Giełda Papierów Wartościowych) jest w 2026 roku europejskim liderem we wdrażaniu Dobrych Praktyk Spółek Notowanych 2021 (zasady 1.4 i 4.7) - 433 emitentów rynku regulowanego kwartalnie raportuje do Rady Nadzorczej system zarządzania ryzykiem finansowym i perspektywy rozwoju, a komitet audytu sporządza roczny raport o systemie zarządzania ryzykiem. KNF nadzoruje raporty bieżące ESPI/ESPInet emitentów (art. 56-57 ustawy o ofercie publicznej z 29.07.2005), a za naruszenia grożą sankcje z art. 96 do 5 mln zł oraz odpowiedzialność cywilna członków zarządu wobec inwestorów. Brak lub błędne raportowanie istotnego ryzyka finansowego (EBITDA poniżej budżetu o ponad 25%, naruszenie kowenantu, ujemna prognoza w base case przez ponad 2 kwartały, istotny odpis impairment KSR 4) skutkuje sankcjami UOKiK do 10 procent obrotu rocznego, odpowiedzialnością cywilną wobec wierzycieli oraz utratą wiarygodności w indeksach giełdowych (WIG20, WIG30, WIG ESG, FTSE4Good).

Ministerstwo Finansów wprowadza KSeF FA(2) jako obowiązkowy mechanizm cross-checku transakcji od 1.7.2026, co dla prognozowania P&L jest fundamentalną zmianą, bo każdy przychód i koszt B2B musi być powiązany z UUID Ministerstwa Finansów. Agent buduje graf przychodowo-kosztowy z UUID MF, a rozbieżności powyżej 5 procent wobec danych z ERP sygnalizują nadużycie lub błąd księgowy dla biegłego rewidenta wg KSRF 540 par. 8-13 oraz KSRF 320 (istotność zwykle 5 procent wyniku przed opodatkowaniem). KSH art. 233 dokłada wymóg osobistej odpowiedzialności zarządu: zaniedbanie obowiązku bieżącej kontroli sytuacji finansowej, w której prognoza P&L jest kluczowym elementem, skutkuje sankcją z art. 299 KSH, czyli osobistą odpowiedzialnością członków zarządu za niezaspokojone zobowiązania spółki. Średnia polska spółka GPW (1000-3000 pracowników, 500 mln-2 mld zł obrotu) ma potencjalną skumulowaną ekspozycję sankcyjną 30-200 mln zł rocznie bez prognozowania P&L w modelu Cert-Ready by Design.

## 14 deterministycznych punktów decyzyjnych z trzema eskalacjami ludzkimi

Agent przetwarza każdy roczny, kwartalny i miesięczny cykl Rolling Forecast P&L przez pipeline 14 strukturalnych punktów decyzyjnych: jedenaście klasyfikacji regułowo-ML oraz trzy eskalacje ludzkie (założenia strategiczne, wiarygodność prognozy oraz zatwierdzenie przez zarząd i Komitet Audytu). Walidację zasady kontynuacji działalności (going concern) wykonuje silnik reguł, sprawdzając 12 wskaźników wczesnego ostrzegania finansowego (EBITDA poniżej 0 w base case przez 6 miesięcy, marża operacyjna poniżej 2 procent, ROE poniżej kosztu kapitału WACC, DSCR poniżej 1,2x, Net Debt/EBITDA powyżej 4,5x, Interest Coverage poniżej 2x). Driver-Based Modeling dekomponuje przychody na Volume × Price × Mix oraz koszty na Variable × Fixed × Semi-Fixed wg drzewa decyzyjnego z planu kont UoR i segmentów operacyjnych KSR 9. Cross-check KSeF FA(2) prowadzi walidację w czasie rzeczywistym wobec UUID Ministerstwa Finansów. Modelowanie Monte Carlo na 10 000 iteracji generuje przedziały ufności P10/P50/P90, a analiza wrażliwości w postaci wykresu tornado obejmuje 10 najważniejszych driverów.

Konkretny przykład: średniej wielkości polski producent przemysłowy notowany na GPW (1500 pracowników, 720 mln zł obrotu, sektor automotive, PKD 29.32) sporządza miesięczny Rolling Forecast P&L na 18 miesięcy oraz kwartalny raport ESPI. Agent w pierwszym tygodniu kwartału wykonuje: (1) walidację going concern - 11 z 12 wskaźników w normie, EBITDA 9,8 procent, marża operacyjna 6,2 procent, DSCR 1,7x, Net Debt/EBITDA 2,8x oraz Interest Coverage 3,2x; (2) agregację z SAP S/4HANA Polish Analytics i Anaplana - 36 miesięcy historii, 2,1 mln rekordów P&L per centrum kosztów; (3) cross-check KSeF FA(2) - rozbieżność 3,8 procent w kategorii kosztów surowców (akceptowalna, poniżej 5 procent), 100 procent przychodów ze sprzedaży zgodne z UUID MF; (4) Driver-Based Modeling - przychody dekomponowane na Volume (185 tys. szt. rocznie) × Price (średnio 3892 zł za sztukę) × Mix (45 procent OEM, 35 procent aftermarket, 20 procent eksport); koszty zmienne 412 mln zł (surowce stal i aluminium 280 mln, energia 65 mln, transport 45 mln, prowizje 22 mln), koszty stałe 217 mln zł (wynagrodzenia 145 mln, ZUS 32 mln, amortyzacja 28 mln, czynsze 12 mln); (5) ekstrapolację ensemble'em ML (Prophet, ARIMA, DeepAR, XGBoost) z ponad 50 cechami; (6) założenia strategiczne zarządu - wzrost rynku o 4,5 procent (benchmark NBP 4,2 procent, KE 4,8 procent), USD/PLN średnio 4,18 w 2026 (prognoza NBP 4,15-4,25), CapEx 85 mln zł na nowe linie; (7) Monte Carlo na 10 000 iteracji - przychody P10 695 mln, P50 745 mln, P90 798 mln, EBITDA P10 64 mln, P50 78 mln, P90 92 mln; (8) analizę wrażliwości - trzy najważniejsze drivery: zmiana USD/PLN o 2 procent oznacza zmianę EBITDA o 12 mln, zmiana cen stali o 5 procent o 9 mln, a wolumenu OEM o 3 procent o 7 mln; (9) test impairment KSR 4 i MSR 36 - WACC 9,8 procent (koszt kapitału własnego 12,4 procent oraz koszt długu 5,2 procent po tarczy podatkowej), brak przesłanek impairment dla 3 CGU; (10) walidację kowenantów - DSCR 1,7x w P50 i 1,3x w Worst Case (powyżej progu 1,2x, bez naruszenia), Net Debt/EBITDA 2,8x w P50 i 3,4x w Worst Case (poniżej progu 3,5x, bez naruszenia); (11) konsolidację 5 spółek zależnych z eliminacją intercompany 38 mln zł; (12) porównanie prognozy z budżetem - odchylenie EBITDA o -4,2 procent (poniżej progu istotności KSRF 320 wynoszącego 5 procent); (13) ulgi Polskiego Ładu 2.0 - ulga B+R 6,2 mln zł (CBR) oraz ulga na robotyzację 4,8 mln zł (50 procent odliczenia), efektywna stopa CIT 12,8 procent zamiast 19 procent; (14) zatwierdzenie przez CFO i Komitet Audytu Rady Nadzorczej, kwartalny raport ESPI do GPW oraz audit-trail dla biegłego rewidenta wg KSRF 540, 320 i 570.

## Ciągłe monitorowanie i pętla uczenia ML skracają czas badania szacunków księgowych o 35-45 procent

W pierwszym roku wdrożenia agent prognozy P&L zbiera ponad 36 miesięcy historii z ERP, Anaplana lub Tagetika oraz KSeF FA(2) - zwykle 600-1200 godzin pracy zespołów FP&A, Finance i Accounting zgodnie z benchmarkami EFRAG 2024 oraz PwC EPM Survey 2024. Agent stosuje aktywną pętlę uczenia ML: do ponownego uczenia modelu trafia każda korekta założeń dokonana przez CFO, Head of FP&A i Komitet Audytu (krok 4 w microDecisions), każda korekta prognozy po zatwierdzeniu przez Radę Nadzorczą (krok 12) oraz każde uzasadnienie odchylenia od konsensusu analityków (krok 12) - zgodnie z RODO art. 22 (decyzje zautomatyzowane z prawem do interwencji ludzkiej). Po 12-18 miesiącach pętla skraca czas dekompozycji Driver-Based Modeling o 50-60 procent, czas badania szacunków księgowych KSRF 540 o 35-45 procent oraz czas raportowania ESPI o 50-60 procent. Pulpit FP&A KCI pokazuje na bieżąco prognozę P&L per scenariusz P10/P50/P90, analizę EBITDA bridge, marżę operacyjną per segment, kowenanty bankowe, status cross-checku KSeF FA(2) oraz harmonogram raportowania ESPI, a kwartalne raporty trafiają do Komitetu Audytu Rady Nadzorczej zgodnie z KSH art. 391 oraz Dobrymi Praktykami Spółek Notowanych GPW 2021 (zasady 1.4 i 4.7).

## Przypadki szczególne w Polsce: GPW Catalyst, automotive, spółki Skarbu Państwa, estoński CIT, IP Box

Emitenci GPW realizują obowiązki Dobrych Praktyk Spółek Notowanych 2021: roczny raport komitetu audytu o systemie zarządzania ryzykiem, raporty bieżące ESPI/ESPInet oraz perspektywy rozwoju w sprawozdaniu z działalności wg KSR 9 par. 32. Sektor automotive (PKD 29) i przemysłowy (PKD 24-30) raportuje ryzyko cen surowców LME (stal, aluminium, miedź) oraz kursów USD/EUR/PLN dla eksporterów. W spółkach Skarbu Państwa pod nadzorem NIK i MAP (sankcje art. 30 ustawy o NIK) prognoza P&L jest elementem oceny celów strategicznych. Grupy międzynarodowe konsolidują prognozy w ramach group reportingu w SAP Analytics Cloud, Anaplanie lub Oracle EPM, mapując KSR 4/6/9 oraz MSR 1/8/36 na niemiecki HGB i US GAAP. Spółki innowacyjne stosują estoński CIT (opodatkowanie tylko przy dywidendach efektywnie 9-19 procent, pod warunkiem przychodów pasywnych poniżej 50 procent i zatrudnienia powyżej 3 osób). IP Box art. 24d daje 5 procent CIT od dochodów z patentów, praw autorskich i wzorów. GPW Catalyst (rynek obligacji) wymaga miesięcznego raportowania prognozy wraz z DSCR i Net Debt/EBITDA do nabywców obligacji i agencji ratingowych (Fitch Polska, EuroRating, S&P).

## Integracja z polskim ekosystemem: Comarch Performance, SAP Analytics Cloud, Anaplan, Tagetik, KSeF, NBP

Agent integruje się z polskim ekosystemem EPM przez API: [Comarch ERP XL Performance](https://www.comarch.pl/erp/comarch-erp-xl/) (lider segmentu MŚP i Enterprise z PKD, planem kont UoR oraz KSR 4/6/9), [SAP S/4HANA Polish Analytics i SAP Analytics Cloud](https://www.sap.com/poland/) (emitenci GPW WIG20 z MSSF, ESEF iXBRL i Predictive Planning), [Anaplan Connected Planning](https://www.anaplan.com/) (wdrożenia Big-4 dla WIG30 i spółek Skarbu Państwa), [Wolters Kluwer CCH Tagetik](https://www.wolterskluwer.com/pl-pl/solutions/cch-tagetik) (konsolidacja MSSF z IFRS Taxonomy ESEF), [Workday Adaptive Planning](https://www.workday.com/pl-pl/products/adaptive-planning/overview.html) (chmurowy EPM z Rolling Forecast), [Symfonia ERP Performance](https://www.symfonia.pl/), [enova365 BI](https://www.enova.pl/), Asseco Softlab BI (sektor publiczny), Oracle EPM Cloud, Microsoft Dynamics 365 z Power BI, IBM Planning Analytics, Board International oraz Vena Solutions. Po stronie baz zewnętrznych agent łączy się z KSeF FA(2) API z certyfikatem kwalifikowanym (CenCert/Szafir/EuroCert/KIR) do cross-checku P&L od 1.7.2026, NBP API (kursy, stopa i prognozy makroekonomiczne), GUS API (PKB, CPI, sprzedaż detaliczna), URE (taryfy i EU ETS) oraz KRS i GPW API i benchmarkami analityków (Vestor DM, Trigon DM, Erste, BM mBanku, Wood&Co, Ipopema). Substantive Testing Big-4 wg KSRF 540, 320 i 570 wspiera eksport do Deloitte ASM, PwC Halo, EY Helix i KPMG Clara z metadanymi PCAOB AS 1215, IAASB ISA 540 oraz KSR 4. Audit-trail przechowuje się 5 lat zgodnie z UoR art. 73, a dodatkowo dokumentację KSRF 540 par. 39, KSR 9 par. 32 oraz interpretacje indywidualne KAS na potrzeby nadzoru PANA.

--- Agent wykrywania nadużyć ---
> Wykrywanie nadużyć i karuzel VAT: analiza ML transakcji z cross-checkiem KSeF FA(2), zgodna z KK art. 286 oraz wymogami AML GIIF.

Polska gospodarka traci rocznie 150-200 mld zł w wyniku nadużyć finansowych - wynika to z raportów KAS i GIIF z lat 2023-2024. Same karuzele VAT odpowiadają za szkody 30-50 mld zł rocznie zgodnie z analizą Ministerstwa Finansów i właśnie dlatego KSeF FA(2) staje się obowiązkowy 1 lipca 2026. Polski Kodeks karny (art. 286 - oszustwo, 296 - wyrządzenie szkody znacznej, 299 - pranie pieniędzy) tworzy szkielet karnoprawny, Kodeks karny skarbowy art. 56-61 sankcjonuje oszustwa VAT do 21,6 mln zł, ustawa AML z 1.03.2018 wymaga zgłoszeń transakcji podejrzanych do GIIF w 2 dni robocze, UOKiK karze kartelowanie do 10% obrotu, a ustawa o sygnalistach 2024 (wdrożenie dyrektywy UE 2019/1937) włącza sygnalistów jako kluczową kontrolę nadużyć. Każda średnia i duża spółka z obowiązkiem badania ustawowego musi udokumentować skuteczność systemu wykrywania nadużyć zgodnie z KSRF 240 (przyjęcie ISA 240 przez PIBR), rekomendacją KNF D dla cyberbezpieczeństwa logów oraz cross-checkiem KSeF FA(2) w czasie rzeczywistym.

## KK art. 286, AML GIIF, KKS art. 56, UOKiK i audyt KAS tworzą wielofrontowy nadzór nad nadużyciami wymagający Cert-Ready by Design

GIIF jest centralną jednostką analityki finansowej w Polsce i przyjmuje rocznie ponad 250.000 zgłoszeń transakcji podejrzanych od podmiotów zobowiązanych. Brak zgłoszenia w terminie 2 dni roboczych (art. 50 ustawy AML) skutkuje sankcją do 5 mln zł oraz odpowiedzialnością karną z art. 156 ustawy AML do 5 lat pozbawienia wolności. KAS wskazał w 2024 roku karuzele VAT jako najczęstszy schemat nadużyć, a Ministerstwo Finansów wprowadziło KSeF FA(2) jako obowiązkowy mechanizm cross-checku przeciw missing trader fraud, z UUID generowanym po stronie urzędu. KKS art. 56 sankcjonuje oszustwa VAT kwotą 30 procent wartości (maksymalnie 21,6 mln zł) oraz odpowiedzialnością karną członków zarządu wg art. 60-61 do 240 stawek dziennych.

W latach 2022-2024 UOKiK nałożył kary kartelowe powyżej 600 mln zł na sektory budowlany, transportowy, IT i farmaceutyczny - sankcja maksymalna sięga 10 procent obrotu rocznego firmy, a członkowie zarządu odpowiadają karnie do 2 mln zł lub 3 lat pozbawienia wolności (art. 108 ustawy o ochronie konkurencji 2007). Rekomendacja KNF D z 8.01.2013 wymaga od banków, TFI i zakładów ubezpieczeń cyberbezpieczeństwa, audytu logów IT z retencją 5 lat, zarządzania incydentami nadużyć oraz raportowania do KNF. RODO art. 6 i 32 dokłada kolejną warstwę: podstawa przetwarzania danych do wykrywania nadużyć musi być udokumentowana, a środki bezpieczeństwa adekwatne do ryzyka, pod groźbą sankcji UODO do 4 procent obrotu lub 20 mln EUR. Średnia polska spółka (300-500 pracowników, 100-300 mln zł obrotu) ma potencjalną skumulowaną ekspozycję sankcyjną 50-200 mln zł rocznie bez podejścia Cert-Ready by Design.

## 15 deterministycznych punktów decyzyjnych z dwiema eskalacjami ludzkimi

Agent przetwarza każdą transakcję przez pipeline 15 strukturalnych punktów decyzyjnych: trzynaście klasyfikacji regułowo-ML oraz dwie eskalacje ludzkie (decyzja o dochodzeniu i klasyfikacja False Positive). Klasyfikację typu transakcji wykonuje LLM, mapując kontekst regulacyjny (AML, KKS, KK, UOKiK, KNF) na podstawie kontrahenta, kwoty, kraju i branży. Pozostałe punkty działają wg reguł: KK art. 286 (duplikaty i Phantom Vendor), KKS art. 56 (karuzele VAT przez KSeF FA(2)), ustawa AML art. 50 (transakcje podejrzane GIIF), ustawa o ochronie konkurencji 2007 art. 6 (kartelowanie i bid rigging), KSH art. 382 §3 (segregacja obowiązków) oraz ustawa o sygnalistach 2024 (sygnalista jako kontrola nadużyć).

Konkretny przykład: średniej wielkości polski producent maszyn notowany na GPW (450 pracowników, 280 mln zł obrotu, sektor IT) wykonuje rocznie 40.000 transakcji zakupowych, 12.000 sprzedażowych i 1.200 zwrotów. Agent w pierwszym kwartale 2026 wykrywa: (1) Phantom Vendor - dostawcę usług IT zarejestrowanego 90 dni temu, bez wpisu w CRBR, z aktywnym REGON, lecz bez sprawozdań finansowych, wystawiającego faktury po 9.900 zł (rozdrabnianie poniżej progu split payment 15.000 zł), 6 faktur w 8 tygodni; (2) karuzelę VAT wykrytą w analizie grafu KSeF FA(2) - łańcuch 4 firm: missing trader (importer elektroniki działający poniżej 90 dni), bufor (pośrednik z marżą 0,5%) i broker (eksporter WDT do Niemiec) o łącznej wartości 8,2 mln zł, z ekspozycją KKS art. 56 na 2,46 mln zł sankcji; (3) fałszywe faktury AI - 3 dokumenty od nowego dostawcy z metadanymi PDF wskazującymi na Producer GPT-4V, bez znaku wodnego C2PA i bez UUID KSeF; (4) round-tripping - cykl płatności między 3 spółkami zależnymi przez Cypr i Luksemburg o wartości 1,8 mln zł, wskazujący na prawdopodobne ukryte dywidendy wg art. 296 KK; (5) zgłoszenie sygnalisty z platformy Sygnanet - kierownik zakupów otrzymuje korzyści majątkowe od dostawcy materiałów opakowaniowych, w korelacji z 18 fakturami w 6 miesięcy. Compliance Officer eskaluje przypadek (2) karuzeli VAT do GIIF (zgłoszenie w 2 dni robocze), KAS i prokuratury, a przypadek (5) sygnalisty do dochodzenia wewnętrznego z poszanowaniem ochrony przed retorsjami z ustawy o sygnalistach 2024.

## Ciągłe monitorowanie i pętla uczenia ML redukują False Positive z 25% do poniżej 10%

W fazie początkowej wykrywanie nadużyć generuje wskaźnik False Positive na poziomie 20-25 procent zgodnie z benchmarkami ACFE 2024, co znacząco obciąża czas Compliance Officera. Agent stosuje aktywną pętlę uczenia ML: każda klasyfikacja False Positive przez Compliance Officera (krok 15 w microDecisions) trafia do ponownego uczenia modelu zgodnie z RODO art. 22 (decyzje zautomatyzowane - prawo do interwencji ludzkiej). Po 12-18 miesiącach pętla redukuje False Positive do 5-10 procent, co odpowiada zmniejszeniu czasu Compliance Officera na analizę alarmów o 60-70 procent. Pulpit wskaźnika nadużyć pokazuje na bieżąco KCI: liczbę aktywnych alarmów, średni czas eskalacji, odsetek False Positive, liczbę zgłoszeń GIIF oraz status sprawy w prokuraturze, a kwartalne raporty trafiają do komitetu audytu rady nadzorczej zgodnie z KSH art. 391 i Dobrymi Praktykami Spółek Notowanych GPW 2021.

## Przypadki szczególne w Polsce: GPW, instytucje KNF, spółki Skarbu Państwa, grupy międzynarodowe

Polskie spółki notowane na GPW mają obowiązki wynikające z Dobrych Praktyk 2021: coroczny raport komitetu audytu o systemie wykrywania nadużyć, ujawnienie istotnych przypadków w sprawozdaniu rocznym oraz opis trzech linii obrony w prospekcie emisyjnym. Instytucje nadzorowane przez KNF (banki, ubezpieczyciele, TFI, domy maklerskie) muszą dodatkowo uwzględniać ryzyko nadużyć w ICAAP/ILAAP, składać kwartalne raporty do KNF zgodnie z rekomendacją Z, poddawać outsourcing IT audytowi biegłego rewidenta oraz prowadzić cotygodniowe testy DRP/BCP w zakresie nadużyć (rekomendacja D pkt 7). Spółki Skarbu Państwa pod nadzorem NIK (Najwyższa Izba Kontroli) raportują dodatkowo do MAP (Ministerstwo Aktywów Państwowych), a ich system wykrywania nadużyć podlega kontroli NIK z sankcjami z art. 30 ustawy o NIK do 200% szkody. Grupy międzynarodowe z polskim oddziałem dostosowują globalny framework SOX/COSO ERM 2017 do polskich wymogów KSRF 240, rekomendacji KNF D oraz ustawy AML 2018, a takie mapowanie wymaga akceptacji biegłego rewidenta PIBR.

## Integracja z polskim ekosystemem: Comarch, SAP, AuditBoard, Symfonia, Sygnanet, KSeF

Agent integruje się z polskim ekosystemem GRC i ERP przez API: [Comarch Risk Management Solutions i ERP XL Audit](https://www.comarch.pl/erp/comarch-erp-xl/) (lider segmentu Enterprise i GPW), Comarch ERP Optima Compliance (MŚP), [SAP S/4HANA Polish Localization GRC i SAP Fraud Management](https://www.sap.com/poland/) (grupy międzynarodowe i spółki GPW), AuditBoard Polska (lokalizacja PIBR z workflow KSRF 240), [Symfonia ERP, Audyt i Anti-Fraud](https://www.symfonia.pl/) (średni biznes), [enova365 Moduł Fraud Detection](https://www.enova.pl/), Asseco Softlab GRC i Risk Management, ACL/Galvanize HighBond (Diligent, ciągłe monitorowanie), SAP Concur Fraud Detection (grupy międzynarodowe) oraz Sygnanet (platforma sygnalistów certyfikowana w 2024 roku). Po stronie baz zewnętrznych agent łączy się z KSeF FA(2) API (certyfikat kwalifikowany CenCert/Szafir/EuroCert/KIR), CRBR API (MF), białą listą podatników VAT (whitelist.gov.pl), REGON GUS, KRS, GIIF API do zgłoszeń AML oraz bazą krajów wysokiego ryzyka FATF. Substantive Testing Big-4 wg KSRF 240 wspiera bezpośredni eksport do Deloitte ASM, PwC Halo, EY Helix i KPMG Clara z metadanymi audit-trail wg PCAOB AS 1215 i AS 2401. Audit-trail jest przechowywany 5 lat zgodnie z Ordynacją podatkową art. 86, dodatkowo 5 lat po zakończeniu relacji w zakresie AML (ustawa AML art. 49) oraz uzupełniany dokumentacją wg KNF art. 70 dla instytucji nadzorowanych.

--- Agent zgodności księgowej GoBD ---
> Ciągłe monitorowanie zgodności GoBD dla procesów istotnych podatkowo: archiwizacja, terminy przechowywania, niezmienialność, dokumentacja procedur dla KAS i biegłego rewidenta PIBR.

Brakująca lub nieaktualna dokumentacja procedur to najczęstszy formalny zarzut, jaki stawiają kontrolerzy podatkowi. Kto podczas kontroli nie może przedstawić aktualnej dokumentacji, ryzykuje doszacowanie do dziesięciu procent rocznego obrotu do dochodu podlegającego opodatkowaniu. Problem nie leży w braku wiedzy - lecz w braku ciągłości.

## Dokumentacja procedur starzeje się szybciej niż jakikolwiek dział compliance jest w stanie ją utrzymywać

Wymogi Ustawa o rachunkowości (niemiecki standard GoBD (niemiecki standard dokumentacji)) stanowią, że każda zmiana procesów istotnych podatkowo musi być udokumentowana - nowe wersje oprogramowania, zmieniona logika księgowa, dodatkowe interfejsy. W typowym dziale Finance z ERP, treasury, rozliczaniem delegacji i połączeniami bankowymi powstają dziesiątki zmian wymagających udokumentowania na kwartał.

Rzeczywistość w większości firm: dokumentacja procedur została kiedyś stworzona, leży jako PDF na dysku sieciowym i nie była aktualizowana od ostatniego audytu. Rzeczywiste procesy dawno ewoluowały. Ta rozbieżność między udokumentowanym stanem docelowym a żywą praktyką rośnie z każdą adaptacją systemu.

Ustawa BEG IV od stycznia 2025 skróciła okresy przechowywania dokumentów księgowych z dziesięciu do ośmiu lat. Jednocześnie RODO wymaga usunięcia danych osobowych po ustaniu celu przechowywania. Kto usuwa zbyt wcześnie, narusza Ordynację podatkową. Kto zbyt późno - RODO. Bez bieżącego monitorowania terminów jedno i drugie jest trudne do uniknięcia.

## Kontrolerzy wykorzystują wady formalne jako dźwignię do doszacowań

Odkąd administracja skarbowa stosuje cyfrowe techniki kontroli, punkt ciężkości kontroli podatkowych przesunął się. Kontrolerzy coraz częściej zaczynają od żądania dokumentacji procedur, zanim w ogóle sięgną po dane księgowe. Powód jest pragmatyczny: wady formalne w dokumentacji łatwiej udowodnić niż błędy merytoryczne w księgowości.

Brak protokołów dokumentujących zmiany procesów księgowych i wersji oprogramowania wystarcza według aktualnego orzecznictwa jako podstawa do doszacowania. Kontroler argumentuje, że bez tych dowodów kompletność i niezmienialność zapisów nie jest odtwarzalna. Dopłaty bezpieczeństwa do dziesięciu procent obrotu na dochód podlegający opodatkowaniu nie są rzadkością - przy średniej wielkości firmie z 50 milionami EUR (ok. 54 mln USD) obrotu może to oznaczać pięć milionów EUR dodatkowego dochodu do opodatkowania.

## Obowiązek e-faktur zaostrza wymogi archiwizacji

Od 1 stycznia 2025 wszystkie firmy w obrocie B2B muszą być zdolne do odbioru e-faktur. Ministerstwo Finansów opublikowało 14 lipca 2025 drugą nowelizację GoBD, która explicite reguluje archiwizację formatów hybrydowych jak ZUGFeRD i Factur-X. Kluczowa nowość: przy e-fakturach musi być zarchiwizowana co najmniej strukturalna część XML. Czytelna dla człowieka część PDF podlega dodatkowej archiwizacji tylko wtedy, gdy zawiera odmienne lub istotne podatkowo informacje dodatkowe.

Dla zgodności z GoBD oznacza to: każda przychodząca faktura musi być sprawdzona pod kątem formatu, prawidłowa część musi być zarchiwizowana, a niezmienialność musi być zapewniona znacznikiem czasu i wartością hash. To decyzja regułowa, która przy setkach faktur tygodniowo ręcznie nie działa niezawodnie.

## Regułowy agent utrzymuje zgodność na bieżąco bez wiązania zasobów kadrowych

Agent zgodności księgowej pracuje głównie na poziomie [Decision Layer](/pl/decision-layer/) 1 - regułowo, według jasnych wytycznych z Ordynacji podatkowej, HGB i GoBD. Obowiązek archiwizacji, okresy przechowywania, niezmienialność i dostęp do danych podlegają zdefiniowanym logiką kontrolnym. Brak marginesu uznania, brak potrzeby interpretacji.

Dla dokumentacji procedur agent przechodzi na poziom 2: porównuje udokumentowane procesy z rzeczywiście realizowanymi i proponuje aktualizacje. Człowiek sprawdza i zatwierdza. Ogólna ocena ryzyk compliance pozostaje w pełni przy człowieku.

Konkretny scenariusz: system ERP otrzymuje aktualizację zmieniającą logikę księgową dla faktur zaliczkowych. Agent rozpoznaje rozbieżność między udokumentowanym a rzeczywistym procesem, przygotowuje zaktualizowaną sekcję dokumentacji procedur i zapewnia, że dotknięte reguły archiwizacji zostają dostosowane. Doradca podatkowy lub Tax Manager zatwierdza zmianę. Cała historia - kto kiedy co zmienił i dlaczego - jest automatycznie protokołowana. Dokładnie ta protokolizacja jest tym, czego kontrolerzy żądają jako pierwszego.

## Zgodność powstaje jako efekt uboczny, nie jako dodatkowy nakład

Rzeczywista wartość nie leży w automatyzacji pojedynczych kroków kontrolnych, lecz w zmianie paradygmatu: zgodność z GoBD nie jest już stwierdzana przy następnej kontroli podatkowej, lecz zapewniana na bieżąco. Dokumentacja procedur jest zawsze aktualna, ponieważ przy każdej zmianie procesu jest automatycznie uzupełniana. Terminy są monitorowane zanim upłyną. A gdy kontroler żąda dostępu Z1, Z2 lub Z3, odpowiedź jest dostępna natychmiast - nie po trzech tygodniach gorączkowych przygotowań.

--- Agent monitorowania IKS ---
> Ciągłe monitorowanie systemu kontroli wewnętrznej zgodne z KSH art. 382 §3 oraz ramami COSO 2013 - gotowe do certyfikacji i audytu.

System kontroli wewnętrznej (IKS) w Polsce to złożony framework regulacyjny łączący sześć głównych obszarów: KSH art. 382 §3 i 391 (odpowiedzialność zarządu i rady nadzorczej za skuteczny system kontroli zarządczej), ustawę o rachunkowości art. 4-15 i 50-54 (zasady prowadzenia ksiąg rachunkowych i sprawozdawczości), rekomendacje KNF Z (ład korporacyjny instytucji nadzorowanych) oraz D (governance IT), KSRF 250, 315 i 330 (Substantive Testing przez biegłego rewidenta PIBR), ustawę o sygnalistach z 14.06.2024 oraz uznane przez KIBR standardy COSO 2013, ERM 2017 i ISO 31000. Każda średnia i duża spółka w Polsce z obowiązkiem badania ustawowego musi udokumentować skuteczność systemu kontroli przez pięć komponentów COSO, trzy linie obrony, ciągłe monitorowanie wskaźników KCI oraz cross-check z KSeF FA(2) od 1.7.2026.

## KNF, PIBR, KAS i UOKiK tworzą ciągły nadzór nad systemem kontroli wymagający Cert-Ready by Design

KNF jest najsurowszym regulatorem ładu korporacyjnego w Europie Środkowej. Rekomendacja Z z 22.07.2014 wymaga od banków, ubezpieczycieli, TFI i domów maklerskich niezależnego komitetu audytu rady nadzorczej, polityki wynagrodzeń powiązanej z celami długoterminowymi, systemu kontroli wewnętrznej zorganizowanego w trzy linie obrony, compliance officera raportującego bezpośrednio do zarządu oraz niezależnego audytu wewnętrznego. Za naruszenia KNF nakłada sankcje do 10 procent obrotu lub odbiera licencję. Rekomendacja D z 8.01.2013 wymaga dodatkowo polityki bezpieczeństwa IT, zarządzania zmianami, kontroli dostępu, ciągłości działania, audytu logów IT z retencją 5 lat oraz cyberbezpieczeństwa zgodnego z ustawą z 5.07.2018 o krajowym systemie cyberbezpieczeństwa.

PIBR (Polska Izba Biegłych Rewidentów) wydaje Krajowe Standardy Rewizji Finansowej (KSRF) zgodne z ISA. KSRF 315 wymaga od biegłego rewidenta zrozumienia jednostki i jej systemu kontroli oraz identyfikacji ryzyk istotnych zniekształceń, a KSRF 330 wymaga testów projektu kontroli i testów skuteczności operacyjnej w ramach Substantive Testing (zwykle 25-60 transakcji rocznie). Audyt podatkowy KAS w 2024 roku wskazał niedociągnięcia systemu kontroli jako jeden z trzech najczęstszych ustaleń, obok dokumentacji umów i RODO. Sankcje kumulują się: KKS art. 56 (30% wartości VAT, maksymalnie 21,6 mln zł), RODO do 4 procent obrotu lub 20 mln EUR, UOKiK do 10 procent obrotu, ustawa o sygnalistach do 100 procent szkody oraz osobista odpowiedzialność członków zarządu wg KSH art. 293-300. Polska firma średnia (300-500 pracowników, 100-300 mln zł obrotu) ma potencjalną ekspozycję sankcyjną 50-150 mln zł rocznie bez podejścia Cert-Ready by Design.

## 16 deterministycznych punktów decyzyjnych z dwiema eskalacjami ludzkimi

Agent przetwarza system kontroli przez pipeline 16 strukturalnych punktów decyzyjnych: czternaście klasyfikacji regułowych, jedną wspomaganą przez LLM ekstrakcję klasyfikacji procesu oraz dwie eskalacje ludzkie (klasyfikacja istotnej słabości oraz coroczna ocena skuteczności systemu kontroli przez zarząd i radę nadzorczą). Klasyfikację procesu wykonuje LLM, mapując obszar biznesowy, wartość, ryzyko regulacyjne i częstotliwość na pięć komponentów COSO 2013. Pozostałe 14 klasyfikacji opiera się na KSH art. 382 §3, ustawie o rachunkowości art. 4-15, rekomendacjach KNF Z i D, KSRF 250/315/330, ustawie o sygnalistach 2024, ISO 31000 oraz COSO ERM 2017.

Konkretny przykład: średnia polska spółka produkcyjna notowana na GPW (450 pracowników, 280 mln zł obrotu, sektor IT) prowadzi roczny monitoring systemu kontroli. Agent klasyfikuje 25 procesów finansowych, 18 operacyjnych, 12 IT (rekomendacja KNF D), 8 compliance i 5 strategicznych, co łącznie daje 68 procesów zmapowanych na COSO 2013. Według ISO 31000 zidentyfikowano 142 ryzyka: 47 wysokich, 68 średnich i 27 niskich. Rekomendacja Z nie ma zastosowania (spółka nie jest instytucją KNF), natomiast rekomendacja D obowiązuje (wymagany audyt IT). Substantive Testing wg KSRF 315 i 330 obejmuje 47 kontroli wysokiego ryzyka po 30 transakcji, czyli 1410 testów operacyjnych. Cross-check KSeF FA(2) jest comiesięczny dla 1200 faktur sprzedażowych i 800 zakupowych. W 2024 roku odnotowano 8 zgłoszeń sygnalistów, średnia obsługa 18 dni, bez retorsji. Trzy linie obrony są udokumentowane, a ciągłe monitorowanie obejmuje 23 wskaźniki KCI z progami. Zidentyfikowano 4 niedociągnięcia: jedna istotna słabość (brak segregacji obowiązków w płatnościach powyżej 100 tys. zł) eskalowana do komitetu audytu oraz trzy znaczące słabości w naprawie. Coroczna ocena systemu kontroli przez zarząd jest pozytywna z jednym zastrzeżeniem dotyczącym istotnej słabości i planem naprawczym do III kwartału.

## Ciągłe monitorowanie wskaźników KCI w czasie rzeczywistym z progami eskalacji

Zasada 16 COSO 2013 (ciągłe monitorowanie) wymaga od organizacji nieustannej oceny jakości systemu kontroli. Agent dostarcza pulpit kluczowych wskaźników kontroli (KCI) z progami eskalacji: (1) pokrycie kontrolą three-way match (cel 100%, próg 98%); (2) naruszenia segregacji obowiązków (cel 0, próg 3 rocznie); (3) przeglądy dostępu uprzywilejowanego (cel 100%, próg 95% kwartalnie); (4) nieudane próby logowania (rekomendacja KNF D, próg 50 dziennie); (5) udane testy odtwarzania kopii zapasowych (cel 100%, próg 1 rocznie zgodnie z BCP); (6) czas reakcji kanału sygnalistów (cel poniżej 30 dni, próg poniżej 60 dni zgodnie z ustawą z 2024 roku); (7) skuteczność cross-checku KSeF FA(2) (cel 99%, próg 97%). Alerty w czasie rzeczywistym trafiają do compliance officera, kwartalne raporty do komitetu audytu rady nadzorczej, a roczny raport do zarządu zgodnie z KSH art. 382 §3.

## Przypadki szczególne w Polsce: spółki GPW, instytucje KNF, grupy kapitałowe

Polskie spółki notowane na GPW mają dodatkowe obowiązki wynikające z Dobrych Praktyk Spółek Notowanych 2021: coroczny raport komitetu audytu o skuteczności systemu kontroli z konkretnymi wskaźnikami KCI i statusem działań naprawczych, ujawnienie istotnych słabości w sprawozdaniu rocznym zgodnie z KSRF 265, opis trzech linii obrony w prospekcie emisyjnym oraz polityka różnorodności zarządu i rady nadzorczej. Instytucje nadzorowane przez KNF (banki, ubezpieczyciele, TFI, domy maklerskie) muszą dodatkowo prowadzić ICAAP/ILAAP zgodnie z rekomendacją Z, składać do KNF raport stress-testowy, przeprowadzać analizę wpływu na działalność (BIA) zgodnie z rekomendacją D oraz poddawać outsourcing IT audytowi biegłego rewidenta PIBR. Grupy kapitałowe (spółka matka wraz ze spółkami zależnymi) konsolidują system kontroli na poziomie grupy zgodnie z UoR art. 55 oraz KSRF 600 (badanie skonsolidowanych sprawozdań finansowych) - agent obsługuje uzgodnienia między podmiotami, mapując framework kontroli dla każdej spółki. Międzynarodowe grupy z polskim oddziałem muszą ponadto dostosować globalny framework SOX do KSRF, KIBR i KNF (mapowanie COSO globalnego na polski).

## Integracja z polskim ekosystemem: Comarch, SAP, AuditBoard, Symfonia, Sygnanet, KSeF

Agent integruje się z polskimi systemami GRC i ERP przez API: [Comarch ERP XL Audit i GRC Module](https://www.comarch.pl/erp/comarch-erp-xl/) (lider segmentu Enterprise i GPW z modułem audytu i GRC), Comarch ERP Optima Compliance (MŚP z audit-trailem), [SAP S/4HANA Polish Localization GRC i SAP Process Control](https://www.sap.com/poland/) (grupy międzynarodowe i spółki GPW), AuditBoard Polska (lokalizacja PIBR z workflow Substantive Testing), [Symfonia ERP i Audyt](https://www.symfonia.pl/) (średni biznes), [enova365 Moduł Audyt i Kontrola Wewnętrzna](https://www.enova.pl/), Asseco Softlab GRC, Wolters Kluwer ProgMan Audyt, Sygnanet (platforma sygnalistów certyfikowana w 2024 roku) oraz Diligent Boards (rada nadzorcza GPW). Po stronie baz zewnętrznych agent łączy się z KSeF API z certyfikatem kwalifikowanym (CenCert/Szafir/EuroCert/KIR), CRBR API (MF), białą listą podatników VAT oraz GIIF API do cross-checku AML. Substantive Testing Big-4 wspiera bezpośredni eksport do Deloitte ASM, PwC Halo, EY Helix i KPMG Clara z metadanymi audit-trail wg PCAOB AS 1215 i AS 2401. Audit-trail jest przechowywany 5 lat zgodnie z Ordynacją podatkową art. 86, a dla instytucji nadzorowanych dochodzi dokumentacja wg KNF art. 70.

--- Agent uzgadniania intercompany ---
> Agent uzgadnia salda intercompany, klasyfikuje Timing/FX/TP-Deviation oraz dostarcza Local File + Master File + TPR-C zgodnie z Ustawą o CIT art. 11a-11r, BEPS Action 13 CbCR i KSeF FA(2) Reciprocal-Match.

Polska gospodarka 2026 stoi przed największą zmianą w zarządzaniu transakcjami intercompany od czasu wprowadzenia Polskiego Ładu. Połączenie obowiązkowego od 1.7.2026 KSeF FA(2) (Reciprocal-Match faktur intercompany B2B z UUID Ministerstwa Finansów), cen transferowych z ustawy o CIT art. 11a-11r, formularza TPR-C z rozporządzenia MF z 21.12.2018, MDR (Mandatory Disclosure Rules), BEPS Action 13 (CbCR dla grup powyżej 750 mln EUR), implementacji ATAD I/II (CFC, limit kosztów finansowania, rozbieżności hybrydowe, exit tax) oraz KSRF 600 i 540 (audyt grupy i szacunki księgowe) wymaga od polskich grup kapitałowych systematycznego uzgadniania intercompany z audit-trailem dla biegłego rewidenta PIBR, KAS, Szefa KAS, KIS oraz Komitetu Audytu Rady Nadzorczej. KSH art. 233 (obowiązek bieżącej kontroli sytuacji finansowej spółki przez zarząd) oraz art. 299 (osobista odpowiedzialność członków zarządu sp. z o.o. za zobowiązania niezaspokojone) tworzą bezprecedensowy poziom ryzyka osobistego CFO i zarządu - błędne salda intercompany skutkujące niezaspokojonymi roszczeniami spółek siostrzanych narażają zarząd osobiście. Za brak Local File i Master File art. 11k ustawy o CIT przewiduje karę do 5 mln zł oraz dodatkowe zobowiązanie podatkowe 10-30% wartości korekty TP, a sankcje MDR z art. 86a-86c KKS sięgają 21,6 mln zł.

## Ceny transferowe z ustawy o CIT art. 11a-11r, TPR-C, MDR, BEPS Action 13 CbCR, ATAD I/II oraz Reciprocal-Match KSeF FA(2) tworzą wielowarstwowy governance intercompany wymagający Cert-Ready by Design

Żaden skonsolidowany bilans nie jest szybszy niż jego najwolniejsze uzgodnienie intercompany. Koncern z 30 spółkami generuje do 435 możliwych par podmiotów - nawet jeśli tylko jedna trzecia z nich utrzymuje aktywne relacje IC, miesięcznie powstają setki procesów uzgadniania ponad granicami krajów, walut i systemów. Ręcznie kosztuje to 5-6 pełnych dni roboczych na zamknięcie miesiąca - nie dlatego, że pojedyncza weryfikacja jest złożona, lecz dlatego, że wolumen przekracza pojemność zespołu Group Controlling.

Ministerstwo Finansów wprowadza Reciprocal-Match KSeF FA(2) jako obowiązkowy mechanizm cross-checku transakcji intercompany od 1.7.2026, co dla uzgodnienia IC jest fundamentalną zmianą, bo każda faktura intercompany B2B otrzymuje UUID Ministerstwa Finansów przywoływany przez obie strony transakcji. Agent buduje deterministyczny graf przychodowo-kosztowy z UUID MF, klasyfikując rozbieżności jako Timing Difference (faktura wystawiona, lecz niezaksięgowana po stronie odbiorcy w okresie zamknięcia), brakujący dokument (jednostronne księgowanie bez przeciwstawnego UUID MF), odchylenie kwotowe (różne kwoty po obu stronach) lub korektę TP (faktura korygująca z nowym UUID po year-end TP adjustment). Niezgodność powyżej 5% wyzwala eskalację do biegłego rewidenta wg KSRF 600 par. 8-13 (audyt grupy) oraz KSRF 540 par. 14-22 (badanie szacunków księgowych cen transferowych).

## 90 procent różnic intercompany wynika z trzech obliczalnych wzorców - Timing, FX i TP-Deviation - obsługiwanych przez 14 deterministycznych punktów decyzyjnych z dwiema eskalacjami ludzkimi

Większość różnic IC wygląda w pojedynczym przypadku na złożoną, ale daje się sprowadzić do trzech klasyfikacji, które agent rozpoznaje regułowo. Timing Differences powstają, gdy jedna spółka księguje 30. dnia miesiąca, a spółka przeciwna dopiero 2. dnia miesiąca następnego (różny cykl zamknięcia per podmiot, różne strefy czasowe, kalendarz fiskalny 4-4-5 wobec polskiego miesiąca kalendarzowego). Agent porównuje daty księgowań obu stron transakcji, wykonuje cut-off analysis, automatycznie klasyfikuje różnicę oraz monitoruje wpłynięcie kontrzapisu w kolejnym cyklu - KSR 8 par. 14 wymaga eliminacji rozliczeń intercompany na poziomie skonsolidowanym, a Timing Differences dokumentuje jako tymczasowe odchylenia z planowaną korektą.

Różnice kursowe wynikają z odmiennych kursów przeliczeniowych lub dat bilansowych. Agent przelicza salda intercompany wg średnich kursów NBP z dnia bilansowego dla bilansu (UoR art. 30 ust. 2) oraz średnich kursów okresu dla P&L (MSR 21 i KSR 7), liczy różnicę kursową deterministycznie jako saldo w walucie obcej pomnożone przez różnicę między kursem z dnia bilansowego a kursem poprzednim, a dla każdej pozycji IC dokumentuje kwotę w walucie obcej, kurs dnia, różnicę kursową zrealizowaną i niezrealizowaną oraz ujęcie wyniku w przychodach lub kosztach finansowych zgodnie z planem kont UoR (zespoły 75/76). UoR art. 30 ust. 4 wymaga odrębnego prezentowania różnic kursowych zrealizowanych i niezrealizowanych.

Odchylenia cen transferowych występują, gdy zaksięgowana cena intercompany odbiega od polityki TP grupy. Agent porównuje ceny z 5 standardowymi metodami wyceny wg rozporządzenia MF z 21.12.2018: CUP (porównywalnej ceny niekontrolowanej dla towarów i usług z benchmarkiem rynkowym), Resale Price Method (dla dystrybutorów), Cost Plus Method (dla producentów na zlecenie oraz usług grupowych), TNMM (najczęściej stosowana, marża operacyjna 3-8% obrotu) oraz Profit Split (dla zintegrowanych operacji grup międzynarodowych); identyfikuje odchylenia i eskaluje je: odchylenie powyżej 5% wymaga uzasadnienia, a powyżej 10% analizy porównywalności oraz eskalacji do Tax Directora i interpretacji indywidualnej KIS wg art. 14b Ordynacji.

## Konkretny przykład polskiej grupy kapitałowej automotive na GPW: zamknięcie miesiąca z agentem

Średniej wielkości polska grupa kapitałowa automotive notowana na GPW (12 spółek zależnych w PL, DE, CZ, SK, HU i IN, 4500 pracowników, 1,8 mld zł skonsolidowanego obrotu, sektor PKD 29.32) sporządza miesięczny raport uzgodnień IC, kwartalny TPR-C oraz roczny CbCR. Agent w pierwszym tygodniu po zamknięciu miesiąca wykonuje: walidację kompletności sald IC z 12 systemów ERP (SAP S/4HANA Polish z SAP Group Reporting dla 4 spółek, Comarch ERP XL dla 3 spółek, lokalne ERP w DE, CZ i SK oraz Tally ERP w Indiach) - 100 procent pokrycia 66 par podmiotów; Reciprocal-Match KSeF FA(2) - 96,4 procent dopasowania faktur intercompany B2B w Polsce z UUID MF; klasyfikację Timing Differences - 4,2 mln zł różnic czasowych wynikających z cyklu indyjskiego BPO; obliczenie różnic kursowych - 2,8 mln zł różnic FX wynikających ze zmiany USD/PLN o 3,1 procent oraz EUR/PLN o 1,8 procent; wykrywanie odchyleń TP - 8 transakcji wymagających analizy porównywalności (TNMM dla centrum usług IT w Indiach z marżą rynkową 5-8%); generowanie zapisów eliminacyjnych dla konsolidacji - 47 zapisów typu (1)-(6) wg UoR art. 51, KSR 8 i IFRS 10; identyfikację transakcji wymagających Local File - 14 transakcji towarowych powyżej 10 mln zł (sprzedaż komponentów do DE) oraz 6 transakcji usługowych powyżej 2 mln zł (należności licencyjne IP, usługi IT, finansowanie); klasyfikację MDR - 2 schematy podatkowe wymagające raportu MDR-1 do Szefa KAS w ciągu 30 dni (struktura licencyjna z polskim CBR oraz finansowanie transgraniczne z holenderską spółką pożyczkową); walidację CFC - 1 spółka indyjska poniżej progu kontroli 50%, bez statusu CFC; limit kosztów finansowania ATAD I - 2,1 mln zł nadwyżki kosztów finansowania netto wymagającej przeniesienia na kolejne lata; eskalację niewyjaśnionych różnic do Tax Directora oraz zewnętrznego doradcy podatkowego (PwC Tax Poland); komunikację wyjaśniającą z biurami grupy w DE, CZ, SK, HU i IN przez OneStream Intercompany; protokół uzgodnienia per para spółek w formacie PDF, JSON oraz ESEF iXBRL; zatwierdzenie przez CFO i Komitet Audytu Rady Nadzorczej (KSH art. 391); kwartalny raport ESPI do GPW oraz audit-trail dla biegłego rewidenta wg KSRF 600. Czas całkowity to 7,5 godziny zamiast 5-6 dni roboczych.

## Ciągłe monitorowanie i pętla uczenia ML skracają czas badania konsolidacji o 35-45 procent

W pierwszym roku wdrożenia agent zbiera 12-24 miesiące historii uzgodnień IC z ERP, KSeF FA(2) oraz polityki TP grupy - zwykle 600-1200 godzin pracy zespołów Group Controlling, Tax Department, Finance i Accounting zgodnie z benchmarkami EFRAG 2024 oraz PwC Group Reporting Survey 2024. Agent stosuje aktywną pętlę uczenia ML: do ponownego uczenia modelu trafia każda korekta klasyfikacji Timing/FX/TP-Deviation/MDR/CFC/ATAD dokonana przez controllera grupy oraz każda decyzja Tax Directora o korekcie TP, dokumentacji w Local File lub raporcie MDR - zgodnie z RODO art. 22 (decyzje zautomatyzowane z prawem do interwencji ludzkiej). Po 12-18 miesiącach pętla skraca czas uzgodnienia IC o 60-70 procent, czas badania konsolidacji KSRF 600 o 35-45 procent oraz czas dokumentacji TP TPR-C o 50-60 procent. Pulpit Group Controlling KCI pokazuje na bieżąco status Reciprocal-Match KSeF FA(2), niewyjaśnione różnice starsze niż 10 dni, klasyfikację Timing/FX/TP-Deviation/MDR oraz harmonogram raportowania TPR-C, CbCR i MDR, a kwartalne raporty trafiają do Komitetu Audytu Rady Nadzorczej zgodnie z KSH art. 391. Uzgodnienie IC skraca się z 5-6 dni do mniej niż 8 godzin, a w pełni automatyczne wykrywanie transakcji wymagających Local File, Master File i TPR-C zapewnia zgodność z art. 11k ustawy o CIT, chroniąc przed sankcjami KAS do 5 mln zł oraz dodatkowym zobowiązaniem 10-30% korekty TP.

## Przypadki szczególne w Polsce: GPW, automotive, spółki Skarbu Państwa, IP Box, estoński CIT

Emitenci GPW realizują obowiązki Dobrych Praktyk 2021: kwartalne raporty ESPI o transakcjach IC przekraczających 5% kapitału własnego oraz ujawnienia MSR 24. W sektorze automotive (PKD 29) - Volkswagen Poznań, BMW Wrocław, Stellantis - struktura cen transferowych obejmuje komponenty, należności licencyjne IP oraz usługi wspólne. Spółki Skarbu Państwa pod nadzorem NIK i MAP - Orlen, KGHM, PKO BP - mają skomplikowane struktury IC (spółki w ponad 50 krajach) z podwyższonym ryzykiem CFC, ATAD i MDR. IP Box wg art. 24d daje 5 procent CIT od dochodów z patentów i wymaga analizy DEMPE (rozwój, ulepszanie, utrzymywanie, ochrona i eksploatacja). Estoński CIT to opodatkowanie przy dystrybucji na poziomie 9-19 procent. Transakcje transgraniczne z DE, CZ, SK, HU i IN wymagają cross-checku VIES VAT-IS, EDI INVOIC oraz PEPPOL BIS, a także CbCR per jurysdykcja.

## Integracja z polskim ekosystemem: Comarch Multi-Company, SAP Group Reporting, Oracle HFM, Tagetik, OneStream, BlackLine, KSeF, NBP

Agent integruje się z polskim ekosystemem konsolidacji i intercompany przez API: [Comarch ERP XL Multi-Company](https://www.comarch.pl/erp/comarch-erp-xl/) (lider segmentu MŚP i Enterprise z PKD, planem kont UoR, KSR 8 oraz integracją z Reciprocal-Match KSeF FA(2)), [SAP S/4HANA Polish Localization z SAP Group Reporting](https://www.sap.com/poland/) (grupy międzynarodowe i emitenci GPW WIG20 z konsolidacją MSSF, ESEF iXBRL, silnikiem uzgodnień intercompany oraz analityką cen transferowych), [Oracle EPM Cloud z Oracle Hyperion HFM i Oracle Tax Reporting Cloud](https://www.oracle.com/pl/erp/) (multinationals z polską lokalizacją - dopasowanie intercompany, CbCR oraz dokumentacja TP), [Wolters Kluwer CCH Tagetik](https://www.wolterskluwer.com/pl-pl/solutions/cch-tagetik) (konsolidacja MSSF, procedury IFRS 10/11/12, Intercompany Matching oraz IFRS Taxonomy ESEF), [Anaplan Connected Planning Intercompany](https://www.anaplan.com/) (wdrożenia Big-4 dla WIG30 i spółek Skarbu Państwa), [OneStream](https://www.onestream.com/) (zintegrowana platforma z silnikiem Reciprocal-Match, przeliczaniem walut oraz audit-trailem), [BlackLine Intercompany Hub](https://www.blackline.com/products/intercompany-hub/) (lider uzgodnień intercompany z auto-matchingiem oraz zarządzaniem sporami), [Workday Adaptive Planning](https://www.workday.com/pl-pl/products/adaptive-planning/overview.html), [Trintech Cadency](https://www.trintech.com/cadency/), Symfonia ERP Multi-Company, enova365 Multi-Company, Asseco WAPRO Konsolidacja, IBM Planning Analytics z IBM Cognos Controller, Microsoft Dynamics 365 Finance z Power BI oraz Adra Match. Po stronie baz zewnętrznych agent łączy się z KSeF FA(2) API z certyfikatem kwalifikowanym (CenCert/Szafir/EuroCert/KIR) do Reciprocal-Match faktur intercompany B2B z UUID Ministerstwa Finansów od 1.7.2026, NBP API (kursy walut oraz WIBOR dla safe harbour pożyczek wewnątrzgrupowych), KRS API (struktura grupy kapitałowej i sprawozdania finansowe podmiotów), GUS API (REGON oraz statystyka transakcji wewnątrzgrupowych dla bilansu płatniczego), Bureau van Dijk Amadeus i RoyaltyStat (benchmarki rynkowe TP), VIES VAT-IS (cross-check VAT UE dla intercompany transgranicznego) oraz interpretacjami indywidualnymi KIS wg art. 14b Ordynacji podatkowej. Substantive Testing Big-4 wg KSRF 600 i 540 wspiera eksport do Deloitte ASM, PwC Halo, EY Helix oraz KPMG Clara. Audit-trail przechowuje się 10 lat zgodnie z art. 11k ustawy o CIT.

--- Agent Akceptacji Faktur ---
> Określa właściwą osobę zatwierdzającą wg macierzy akceptacji, weryfikuje budżety resztkowe per MPK, sprawdza blokady dostawców i automatyzuje eskalacje przy przekroczeniu limitów akceptacji.

Każda faktura zatwierdzona z jednodniowym opóźnieniem to przegapiona decyzja. Nie dlatego, że ktoś o niej zapomniał, lecz dlatego, że przypisanie do właściwego zatwierdzającego w większości przedsiębiorstw jest czynnością ręczną - zależną od wiedzy w pojedynczych głowach, a nie od jasnych reguł w systemie. Agent zatwierdzania faktur zmienia to wąskie gardło w przewidywalny odcinek drogi.

## Opóźnione zatwierdzenia cicho niszczą dochody ze skonta

Typowe okno skonta wynosi dziesięć dni. Dziesięć dni, w których faktura musi być przyjęta, sprawdzona, przypisana, zatwierdzona i skierowana do płatności. Według analizy Nanonets średni czas obróbki faktury wynosi 9,2 dnia - i to jest średnia. W przedsiębiorstwach bez ustrukturyzowanych procesów zatwierdzania liczba ta rośnie do ponad 17 dni (Nanonets, 2025).

Rezultat: przy wolumenie zakupowym 50 milionów EUR (54 milionów USD) i 2 procent skonta na połowie faktur każdego roku pozostaje 500 000 EUR (540 000 USD) na stole - nie dlatego, że brakuje warunków, lecz dlatego, że proces zatwierdzania jest za wolny. Pieniądze nie znikają w jednym zdarzeniu. Przeciekają w setkach pojedynczych przypadków, których nikt nie agreguje.

## Matryca zatwierdzeń to zbiór reguł - nie pole uznania

Pytanie "kto może zatwierdzić tę fakturę?" brzmi jak uznanie. W praktyce jest jego przeciwieństwem. Odpowiedź wynika ze stałej kombinacji limitów kwotowych, centrum kosztów, projektu i dostawcy. Zbiór reguł, który w większości systemów ERP już istnieje - ale jest stosowany ręcznie.

Agent przejmuje dokładnie ten routing. Odczytuje matrycę zatwierdzeń, przypisuje fakturę właściwej osobie i równolegle sprawdza, czy jest dostępny budżet na centrum kosztów i czy dostawca jest zablokowany. Trzy decyzje, które razem trwają krócej niż sekundę - a w procesie ręcznym często wymagają godzin lub dni, ponieważ są rozłożone po różnych systemach i skrzynkach mailowych.

[Decision Layer](/pl/decision-layer/) stopień 1: wszystkie trzy weryfikacje podlegają regułom deterministycznym. Nie ma pola interpretacji, nie ma strefy szarej, nie ma wyjątku, którego nie dałoby się zdefiniować z góry.

## Logika eskalacji chroni terminy, zanim upłyną

Najczęstszym problemem przy zatwierdzaniu faktur nie jest błędna decyzja. Jest to brakująca decyzja. Faktura leży w skrzynce właściwego zatwierdzającego, który siedzi na zebraniu, jest w podróży służbowej albo po prostu jest przeciążony.

Agent monitoruje każde trwające zatwierdzenie względem skonfigurowanych terminów. Gdy termin skonta zbliża się do końca, eskaluje do zdefiniowanego zastępcy - nie po trzech mailach przypominających, lecz według jasnej reguły: jeśli zatwierdzenie nie nastąpi w ciągu X godzin, przekaż na poziom hierarchii Y.

Konkretny scenariusz: poddostawca wystawia we wtorek fakturę na 85 000 EUR (92 000 USD) z 2 procentami skonta przy płatności w ciągu dziesięciu dni. Odpowiedzialny kierownik działu jest do piątku na konferencji. Agent rozpoznaje nieobecność, kieruje do zastępcy, a zatwierdzenie następuje w środę. Bez logiki eskalacji faktura byłaby obsłużona najwcześniej w następny poniedziałek - cztery dni po wygaśnięciu terminu skonta. 1700 EUR (1840 USD) straty przy jednej operacji.

## Zatwierdzenia zbiorcze przyspieszają standardowy przypadek

Nie każda faktura zasługuje na indywidualną uwagę. Powtarzające się faktury tego samego dostawcy, za tę samą kwotę, na to samo centrum kosztów - podlegają wzorcowi, który agent rozpoznaje. Takie przypadki kwalifikują się do zatwierdzenia zbiorczego: zatwierdzający otrzymuje zbiorczy przegląd zamiast pojedynczych operacji.

To nie tylko odciąża zatwierdzających, ale zmienia rozkład zdolności w całym procesie Accounts Payable. Według HighRadius zespoły AP klasy Best-in-Class osiągają średni czas obróbki 3,1 dnia na fakturę, w porównaniu do 17,4 dnia w zespołach bez ustrukturyzowanych procesów (HighRadius, 2025). Zatwierdzenie zbiorcze jest jedną z dźwigni wyjaśniających tę różnicę.

## Człowiek decyduje tam, gdzie reguły nie wystarczają

Z siedmiu kroków decyzyjnych w zatwierdzaniu faktur sześć jest w pełni regułowych. Siódmy nie: zatwierdzenie przy przekroczeniu budżetu.

Gdy faktura przekracza dostępny limit centrum kosztów, nie ma algorytmu, który mógłby zdecydować, czy wydatek jest mimo to uzasadniony. Być może budżet jest przestarzały. Być może zamówienie uzupełniające uzgodniono ustnie. Być może dostawa jest krytyczna dla biznesu, a proces budżetowy pozostaje w tyle za rzeczywistością.

Decision Layer stopień 2: agent dostarcza decydentowi wszystkie fakty - kwotę faktury, budżet resztkowy, dotychczasowe wydatki na centrum kosztów, historię dostawcy - i pozostawia decyzję otwartą. Bez propozycji, bez rekomendacji, tylko ustrukturyzowaną podstawę do decyzji. Odpowiedzialność pozostaje przy człowieku, ale przygotowanie trwa sekundy zamiast godzin.

--- Agent Odczytu Faktur ---
> Odbiera e-Faktury przez KSeF (obowiązek od 1.7.2026), waliduje NIP via biała lista KAS, oblicza VAT 0/5/8/23%, generuje JPK_V7M i archiwizuje zgodnie z RODO + Ustawą o rachunkowości.

KSeF (Krajowy System e-Faktur, ustawa z 16.06.2023) jest obowiązkowy w Polsce dla transakcji B2B od 1 lipca 2026 - po przesunięciu z 1.7.2024 wynikającym z problemów technicznych KAS. Każda e-Faktura ma unikalny numer KSeF generowany w momencie wystawienia i walidowany przez KAS, w schemie FA(2) XSD (obecnie 1-0E). JPK_V7M (Jednolity Plik Kontrolny dla VAT, struktura 2-1 obowiązująca od 2026) łączy miesięczną ewidencję VAT z deklaracją w jednym pliku. Wraz z białą listą podatników VAT (ustawa o VAT art. 96b), mechanizmem podzielonej płatności (MPP, art. 108a) i 13-grupowym GTU dla raportowania szczególnych transakcji czyni to polski system fakturowania jednym z najbardziej zaawansowanych w UE. Wszystko zbiega się w jednym agencie odbioru, który w średniej operacji waliduje, klasyfikuje i archiwizuje ponad 5.000 faktur miesięcznie, a dla matki w grupie międzynarodowej przygotowuje równoległy raport XRechnung, PEPPOL lub ZUGFeRD.

## Błędy w JPK_V7M i niewłaściwy split payment kosztują do 30% wartości VAT

Błędne dane w JPK_V7M są karane na podstawie art. 56 Kodeksu karnego skarbowego grzywną do 30% wartości VAT lub karą administracyjną do 30.000 zł za zaniedbanie. Niewłaściwe stosowanie MPP grozi sankcją 30% wartości VAT zgodnie z art. 108a ust. 3 ustawy o VAT. Dla typowej polskiej firmy średniej (300-1000 faktur miesięcznie) 5% błędów klasyfikacji GTU lub MPP generuje zobowiązanie podatkowe szacowane na 100.000-300.000 zł rocznie przed kontrolą - a ta przychodzi zwykle 12-24 miesiące później, wraz z odsetkami za zwłokę i grzywną.

Gorzej: faktura z niewłaściwym split payment od razu pozbawia prawa do zaliczenia wydatku do kosztów podatkowych (art. 22p ustawy o PIT/CIT) - dla firmy o rocznych zakupach 100 mln zł potencjalna utrata sięga 19-23 mln zł bezpośrednich kosztów. Dla polskich oddziałów firm motoryzacyjnych (Volkswagen Poznań, Stellantis Tychy, serwis BMW) zwrot z inwestycji jest natychmiastowy: każda faktura zwalidowana przed zaksięgowaniem to wyeliminowane ryzyko podatkowe.

## E-Faktura przechodzi 14 deterministycznych etapów audytowalnych przez KAS

Agent przetwarza każdą e-Fakturę w 14 deterministycznych etapach: odbiór z webservice'u KSeF, walidacja NIP na białej liście KAS (API whitelist.gov.pl), klasyfikacja stawki VAT (załączniki nr 3, 10 i 12 ustawy o VAT), walidacja kodu CN/PKWiU 2025 GUS, identyfikacja split payment (MPP) dla pozycji z załącznika nr 15, mapowanie GTU (13 grup), weryfikacja duplikatu po numerze KSeF, walidacja kontrahenta przez REGON/KRS/CEIDG, dopasowanie do zamówienia z tolerancją 5%, akceptacja po przekroczeniu progu (jeden etap ludzki), generowanie JPK_V7M (rekordy K_43 i K_45 z oznaczeniami GTU/MPP), archiwizacja w planie kont firmy, e-Sprawozdanie do KAS, jeśli spółka je stosuje, a na końcu równoległa konwersja do XRechnung, ZUGFeRD lub PEPPOL, gdy spółka należy do grupy międzynarodowej.

Typowy scenariusz: zakład przemysłowy we Wrocławiu odbiera 2000 faktur miesięcznie od dostawców (części, chemia, opakowania, usługi techniczne). 70% to faktury krajowe ze stawką 23% VAT, 20% to wewnątrzwspólnotowe nabycie towarów (WNT) ze stawką 0% VAT i odwrotnym obciążeniem, 5% to import spoza UE z naliczeniem VAT na granicy, a 5% to transakcje objęte split payment. Bez agenta dział księgowy spędza 18-22 dni miesięcznie na ręcznej klasyfikacji z 8% błędów. Z agentem te same 2000 faktur zajmuje 4 godziny miesięcznie, a kontrola próbna wykrywa poniżej 1% błędów.

## Integracja z Comarch, Symfonią, enovą i polskim ekosystemem

Agent łączy się z głównymi systemami ERP na polskim rynku przez API: [Comarch ERP Optima/XL](https://www.comarch.pl/erp/comarch-erp-optima/) (lider w sektorze MŚP z modułem KSeF od 2024), [Symfonia Handel i Finanse](https://www.symfonia.pl/) (mocna w średnich firmach), Sage Symfonia, [enova365 Handel](https://www.enova.pl/), InsERT Subiekt nexo. Webservice'y KSeF są dostępne przez OAuth2 z certyfikatem kwalifikowanym ICP-Polska. Walidacja JPK_V7M wobec PVA MF przed wysyłką miesięczną pozwala uniknąć automatycznego odrzucenia. Dla grup międzynarodowych z polską spółką i matką w UE agent generuje równolegle XRechnung 3.0 (Niemcy B2G), Factur-X/ZUGFeRD (Niemcy B2B), e-Faktura ANAF (Rumunia), FacturaE (Hiszpania) lub PEPPOL BIS Billing 3.0 (UE wielokrajowo). Źródłem podstawowym pozostaje KSeF FA(2), a konwersja zachowuje pola obowiązkowe EN 16931. Decision Layer rejestruje oba formaty w audytowalnym mapowaniu - ta sama transakcja jest widoczna zarówno dla KAS, jak i dla audytu matki według IFRS.

--- Agent Wystawiania Faktur ---
> Tworzy faktury wychodzące z danych świadczeń wg Ustawy o VAT, wybiera format KSeF FA(2) lub PDF, obsługuje stawki 0/5/8/23%, archiwizuje wg Ustawy o rachunkowości i uruchamia proces windykacji.

Tworzenie faktur wiąże zdolności, których w dziale finansowym brakuje w innych miejscach. Jednocześnie rośnie presja regulacyjna związana z obowiązkiem e-faktury. Agent faktur wychodzących rozwiązuje oba problemy: tworzy faktury wychodzące całkowicie regułowo - bez udziału AI, bez ręcznych ingerencji, z bezlukową zgodnością od pierwszego dokumentu.

## Błędne faktury kosztują więcej niż tylko prace poprawkowe

Istotny odsetek wszystkich ręcznie tworzonych faktur zawiera błędy. Korekta pojedynczego błędnego dokumentu kosztuje w dwucyfrowych kwotach USD, gdy uwzględnić nakład osobowy, korekty systemowe i opóźnienia płatności. W przedsiębiorstwie przetwarzającym 500 faktur wychodzących miesięcznie błędne dokumenty sumują się do czterocyfrowych kwot EUR nakładu korekcyjnego - każdego miesiąca, zanim w ogóle uwzględni się szkody z opóźnionych wpływów.

Błędy w fakturach wychodzących rzadko są przypadkowe. Błędne stawki VAT przy dostawach wewnątrzwspólnotowych, brakujące pola obowiązkowe według Paragraph 14 UStG, niespójne warunki płatności - to systemowe słabości, które powtarzają się z tego samego procesu ręcznego. Właśnie ta systematyczność czyni błąd rozwiązywalnym regułowo.

## Obowiązek e-faktury zaostrza presję

Od 1 stycznia 2025 wszystkie przedsiębiorstwa w Niemczech muszą móc odbierać e-faktury w obrocie B2B. Okres przejściowy dla wysyłki kończy się na koniec 2026. Potem obowiązuje: każda faktura wychodząca musi istnieć jako ustrukturyzowany zbiór danych w formacie XRechnung lub ZUGFeRD - nie jako PDF, nie jako skan. W Polsce KSeF (Krajowy System e-Faktur) realizuje analogiczny proces cyfryzacji.

Za tym obowiązkiem stoi konkretny cel rządu federalnego: zamknięcie niemieckiej luki VAT w wysokości około 22 miliardów EUR (23,8 miliardów USD) (źródło: DATEV Magazin / Komisja Europejska). Dla działów finansowych oznacza to zmianę formatu, która wykracza daleko poza fakturowanie. Każdy dokument musi być maszynowo czytelny, pola obowiązkowe muszą dokładnie odpowiadać schematowi, a wybrany format musi pozostać konfigurowalny per klient.

Kto steruje tą zmianą ręcznie, wbudowuje nowe źródła błędów w i tak podatny na błędy proces. Kto ją automatyzuje, eliminuje problem formatu jako punkt decyzyjny.

## Osiem kroków decyzyjnych zastępuje proces ręczny

Konkretny scenariusz: usługodawca projektowy wystawia miesięcznie 400 faktur wychodzących klientom w Niemczech, UE i Szwajcarii. Dotąd pracownik sprawdza dla każdego dokumentu stawkę VAT, uzupełnia pola obowiązkowe, wybiera format i przydziela numer faktury ręcznie.

[Decision Layer](/pl/decision-layer/) rozkłada ten proces na osiem deterministycznych kroków. Dane świadczeń są pobierane z systemu źródłowego. Pola obowiązkowe według Paragraph 14 UStG są automatycznie kompletowane. Stawka VAT wynika z lokalizacji klienta i rodzaju świadczenia - 19 procent w kraju, wewnątrzwspólnotowo zwolnione, kraj trzeci bez VAT. Format e-faktury wyprowadza się z danych podstawowych klienta. Warunki płatności pochodzą z umowy. Numer faktury jest przydzielany atomowo - bez luk, bez podwójnego przydziału. Wysyłka i archiwizacja odbywają się równocześnie.

Wszystkie osiem kroków jest regułowych. Żaden krok nie wymaga oceny, ważenia ani prognozy. Dlatego udział AI wynosi dokładnie zero procent - a Readiness 89 do 96 punktów, najwyższa wartość w całym katalogu.

## Zgodność powstaje w procesie, a nie w kontroli posprocesowej

Niemiecki standard GoBD (niemiecki standard dokumentacji) (niemiecki standard dokumentacji) wymaga od każdej faktury wychodzącej trzech rzeczy: bezlukowego przydziału numerów, niezmienialnej archiwizacji i pełnej odtwarzalności. Polska Ordynacja podatkowa (Art. 86 OP) oraz wymogi KSeF stawiają analogiczne wymagania. W procesach ręcznych te wymagania zwykle zapewnia się przez kontrole posprocesowe - weryfikację na koniec miesiąca, uzgodnienie zakresów numeracji, ręczny przebieg archiwizacji.

Agent faktur wychodzących odwraca tę logikę. Przydział numerów jest atomowo zintegrowany w procesie tworzenia. Archiwizacja następuje równocześnie z wysyłką, nie po niej. A każda decyzja - jaka stawka, jaki format, jaki kanał wysyłki - jest protokołowana ze znacznikiem czasu i uzasadnieniem. Przy kontroli podatkowej dostępna jest pełna ścieżka decyzyjna dla każdego pojedynczego dokumentu.

Dla CFO oznacza to: zgodność z wymogami księgowymi nie jest już ryzykiem kontroli, lecz właściwością systemu. Decision Layer na stopniu 1 - czysty zbiór reguł - czyni fakturowanie wychodzące najbardziej niezawodnym procesem w całej księgowości należności.

--- Agent poleceń księgowania ---
> Dekretacja dowodów księgowych zgodna z UoR art. 21-25 i strukturą JPK_KR, z kontrolą czterech oczu wymaganą przez art. 71 UoR.

Polecenia księgowania w Polsce to fundament rzetelności sprawozdania finansowego i podstawa dla rozliczenia CIT/PIT. Ustawa z 29.09.1994 o rachunkowości (UoR) reguluje cały cykl: art. 13 określa obowiązek prowadzenia ksiąg rachunkowych (dziennik, księga główna, księgi pomocnicze, ZOiS), art. 20-21 definiują dowód księgowy z 8 obowiązkowymi elementami, art. 22 wymaga rzetelności, art. 23 chronologii, art. 24 sprawdzalności, art. 25 reguluje wyłącznie korekty przez storno (zakaz wymazywania), art. 35d wprowadza obowiązek tworzenia rezerw, art. 39 RMK czynnych i biernych, a art. 71 wprowadza wewnętrzną kontrolę wewnętrzną (IKW) i obowiązek przechowywania ksiąg 5 lat. Krajowe Standardy Rachunkowości (KSR 1-15 wydawane przez Ministerstwo Finansów) doprecyzowują UoR w obszarach rezerw (KSR 6), środków trwałych (KSR 11), podatku odroczonego (KSR 2) i innych. Dla emitentów na rynku regulowanym GPW skonsolidowane sprawozdanie obowiązkowo wg Międzynarodowych Standardów Sprawozdawczości Finansowej (MSR/MSSF, UoR art. 45 ust. 1a-1c) - co wymaga równoległego księgowania z dokumentacją różnic trwałych i przejściowych. Każde polecenie księgowania musi spełniać wszystkie te wymogi jednocześnie - błąd w klasyfikacji rezerwy lub w korekcie zapisu stanowi nierzetelność z sankcją KKS art. 56 i art. 61.

## Sankcja KKS art. 56 do 30% wartości zaniżenia plus odmowa kredytu BIK

Niewłaściwe polecenia księgowania generują pasywo na czterech frontach jednocześnie. KAS na podstawie Kodeksu Karnego Skarbowego art. 56 § 1 może nałożyć karę grzywny do 720 stawek dziennych (przy stawce 100-30.000 zł, więc do 21,6 mln zł) lub pozbawienie wolności do lat 5 za narażenie podatku na uszczuplenie przez nierzetelne księgi - w skrajnych przypadkach obie kary łącznie. Dla średniej polskiej firmy z 200 mln zł rocznego obrotu i podstawą CIT 30 mln zł, błędne księgowanie 5 mln zł kosztów daje sankcję administracyjną 30% wartości zaniżenia (Ordynacja podatkowa art. 56) = 950 tys zł, plus odsetki za zwłokę 14,5% w skali roku (typowo za 24 miesiące = 230 tys zł), plus potencjalna grzywna karna 720 stawek dziennych = łącznie 1,9-3,5 mln zł. KKS art. 61 sankcjonuje samą nierzetelność księgi (do 240 stawek dziennych = do 7,2 mln zł) niezależnie od skutku podatkowego.

Najgorsze: utrata wiarygodności sprawozdania finansowego dla scoringu BIK i decyzji kredytowych. Banki polskie przy kredytowaniu korporacyjnym (Pekao, PKO BP, ING Bank Śląski, mBank, Santander Polska) weryfikują opinię biegłego rewidenta z PIBR/KIBR jako element oceny zdolności kredytowej - opinia z zastrzeżeniem (qualified opinion) lub negatywna automatycznie obniża rating wewnętrzny banku, prowadząc do odmowy kredytu inwestycyjnego, podwyższenia marży o 150-300 punktów bazowych dla kredytu obrotowego lub żądania dodatkowych zabezpieczeń. Dla firmy średniej wielkości z portfelem kredytowym 50 mln zł podwyższenie marży 200 bp generuje dodatkowy koszt 1 mln zł rocznie. Nie do odzyskania bez nowego badania bezzastrzeżeniowego.

## Polskie polecenia księgowania przechodzą 15 deterministycznych etapów - więcej niż w Niemczech (8) lub Brazylii (12)

Polski system rachunkowości jest jednym z najbardziej rozbudowanych w UE ze względu na wielowarstwową regulację: ustawową (UoR z 1994), standardów krajowych (KSR 1-15), międzynarodowych (MSR/MSSF dla emitentów GPW), podatkowych (Ustawy o CIT/PIT z odmiennościami od UoR generującymi podatek odroczony wg KSR 2/MSR 12) i strukturalnej (interpretacja MF z 24.05.2018 dla JPK_KR oraz Rozporządzenie MF z 19.06.2017 dla e-Sprawozdania). 15 deterministycznych etapów to: walidacja kompletności dowodu wg art. 21 UoR, powiązanie z numerem KSeF FA(2), identyfikacja zapisu cyklicznego z historii (etap LLM), mapowanie na zakładowy plan kont oparty o plan referencyjny KAS, wyliczenie RMK czynnych i biernych wg art. 39 UoR, zaksięgowanie amortyzacji wg KŚT i KSR 11, tworzenie/korekta/rozwiązanie rezerw wg art. 35d UoR i KSR 6, klasyfikacja działalności (operacyjna podstawowa/pozostała/finansowa), różnica UoR vs MSR/MSSF dla emitentów GPW, generowanie zapisu z walidacją bilansowości (Wn = Ma), weryfikacja czterech oczu wg art. 71 UoR, korekta przez storno czerwone wg art. 25 UoR, mapowanie na strukturę JPK_KR (interpretacja MF z 24.05.2018), generowanie e-Sprawozdania XML XSD do KRS i niezmienialność zapisu z hashem SHA-256.

Scenariusz konkretny: zakład produkcyjny w Tychach z 1.500 zapisami zamknięcia miesiąca, 4.500 środków trwałych w KŚT, 320 trwającymi umowami z RMK i 85 rezerwami zgodnie z KSR 6. Notowany na GPW - prowadzi sprawozdanie jednostkowe wg UoR i skonsolidowane wg MSSF. W ostatnim dniu miesiąca o 6:00 Agent identyfikuje 1.150 zapisów cyklicznych z historii 12 miesięcy (czynsze biurowe Wrocław/Warszawa/Tychy, leasingi operacyjne i finansowe wg MSSF 16, abonamenty SaaS - Microsoft 365, Salesforce, Comarch ERP XL, prenumeraty branżowe), wylicza RMK czynne dla 320 umów pro rata temporis wg art. 39 UoR, generuje 4.500 zapisów amortyzacji wg KŚT z dokumentacją różnic UoR vs CIT, proponuje korektę 12 rezerw wg KSR 6 do akceptacji głównego księgowego, klasyfikuje 8 zdarzeń jako pozostałe operacyjne (sprzedaż maszyny, odprawy emerytalne) i 2 jako nadzwyczajne (powódź w hali produkcyjnej Wrocław, kradzież surowców), generuje równoległe zapisy MSSF z dokumentacją różnic dla MSSF 16 (kapitalizacja leasingów operacyjnych) i MSR 19 (rezerwy na świadczenia pracownicze z aktuariuszem), eksportuje wsadowo plik JPK_KR gotowy do żądania KAS i tworzy draft e-Sprawozdania w XML XSD MF. Każdy zapis przechodzi weryfikację czterech oczu - drugi pracownik (zastępca głównego księgowego) zatwierdza w średnim czasie 12 sekund na zapis dzięki wstępnej walidacji.

W [Decision Layer](/pl/decision-layer/) z 15 etapów 11 to decyzje regułowe (poziom R), 1 to klasyfikacja LLM (poziom A - identyfikacja powtarzalności wzorca cyklicznego) i 3 to decyzje człowieka (poziom H - tworzenie/korekta rezerw, klasyfikacja działalności operacyjnej/finansowej/pozostałej, weryfikacja czterech oczu). Nie ma punktu, w którym księgowy musi podejmować decyzję dyskrecjonalną w fazie standardowych zapisów cyklicznych - każde wyliczenie to zastosowanie UoR, KSR, planu kont firmy lub Ustawy o CIT. Decyzje uznaniowe są zawężone do tych pozycji, które rzeczywiście wymagają osądu zawodowego księgowego - i każda taka decyzja jest udokumentowana z uzasadnieniem dla biegłego rewidenta.

## Różnica UoR vs MSR/MSSF dla emitentów GPW - równoległe księgowanie z KSR 2 i MSR 12

Spółki notowane na rynku regulowanym GPW (Giełda Papierów Wartościowych) mają obowiązek prowadzenia skonsolidowanego sprawozdania finansowego wg MSR/MSSF (UoR art. 45 ust. 1a-1c). Dla sprawozdania jednostkowego MSSF jest opcjonalne - większość emitentów stosuje UoR dla jednostkowego (prostszy bilans podatkowy) i MSSF dla skonsolidowanego (wymaganie giełdowe i raportowanie do matki UE). Generuje to obowiązek równoległego księgowania z dokumentacją różnic.

Główne różnice mające istotny wpływ na zapisy: (1) MSSF 16 likwiduje rozróżnienie leasingu operacyjnego i finansowego u korzystającego - wszystkie leasingi są kapitalizowane jako prawo użytkowania składnika aktywów (right-of-use asset) z zobowiązaniem leasingowym, podczas gdy KSR 5 i UoR utrzymują rozróżnienie z leasingiem operacyjnym ujmowanym kosztowo wg jednostajnej rentowności; (2) MSR 19 (Świadczenia pracownicze) wymaga aktuariusza dla rezerw emerytalnych i odpraw, podczas gdy KSR 6 dopuszcza uproszczone metody dla mniejszych populacji; (3) MSSF 9 (Instrumenty finansowe) wprowadza model expected credit loss dla odpisów aktualizujących należności, podczas gdy UoR art. 35b i KSR 4 stosują podejście incurred loss; (4) MSR 12 (Podatek dochodowy) i KSR 2 różnią się w rozpoznawaniu strat podatkowych do przeniesienia (MSR 12 wymaga dowodu prawdopodobnego wykorzystania, KSR 2 jest bardziej liberalny). Agent prowadzi równoległe księgowanie z generowaniem różnic trwałych (deductible/taxable permanent differences) i przejściowych (temporary differences) dla wyliczenia podatku odroczonego, dokumentowanych zgodnie z KSR 2 dla UoR i MSR 12 dla MSSF.

## Przypadki specjalne: storno czerwone, rezerwy KSR 6, e-Sprawozdanie do KRS

Korekta zapisu już zaksięgowanego jest kluczowym przypadkiem specjalnym. UoR art. 25 ust. 1 stanowi, że stwierdzone błędy w zapisach poprawia się wyłącznie przez storno czarne (skreślenie) lub storno czerwone (cofnięcie zapisu z minusami) z wyraźnym wskazaniem osoby dokonującej korekty i daty - zakaz wymazywania pierwotnego zapisu. Agent blokuje wszystkie inne formy korekty (delete, overwrite) i wymusza storno czerwone z udokumentowanym uzasadnieniem od głównego księgowego. Brak tej dyscypliny generuje zarzut nierzetelności (KKS art. 61) z sankcją do 240 stawek dziennych nawet jeśli korekta merytoryczna była prawidłowa.

Rezerwy wg art. 35d UoR i KSR 6 (Rezerwy, bierne RMK i zobowiązania warunkowe) wymagają oceny prawdopodobieństwa wystąpienia zobowiązania - rezerwa tworzona dla zobowiązań pewnych co do istnienia ale niepewnych co do kwoty lub terminu (np. roszczenia sądowe, gwarancje produktowe, świadczenia pracownicze). Agent prezentuje historyczne podobne pozycje (klasyfikacja LLM z analizy poprzednich okresów), ale decyzja o utworzeniu/korekcie/rozwiązaniu rezerwy wymaga akceptacji człowieka (decision layer H). Każda rezerwa udokumentowana z podstawą prawną (np. wezwanie sądowe z numerem akt, umowa gwarancyjna z klauzulą), wartością nominalną, prawdopodobieństwem szacowanym przez głównego księgowego i datą oczekiwanego rozliczenia.

e-Sprawozdanie Finansowe składane do KRS w formacie XML XSD wymaga mapowania zapisów księgowych na pozycje bilansu (UoR załącznik 1), RZiS (wariant porównawczy lub kalkulacyjny, załączniki 1-2), informacji dodatkowej (zmiany w kapitale własnym, rachunek przepływów pieniężnych wg KSR 1) i sprawozdania z działalności wg KSR 9. Schema XSD różni się dla różnych typów jednostek (jednostki gospodarcze, banki, ubezpieczyciele, OPP, fundusze inwestycyjne) - Agent automatycznie dobiera właściwą schemę i waliduje strukturę przed eksportem. Termin: sporządzenie 3 miesiące od dnia bilansowego (UoR art. 52), zatwierdzenie 6 miesięcy (art. 53), złożenie do KRS 15 dni od zatwierdzenia (art. 69 ust. 1) - brak złożenia w terminie skutkuje karą porządkową do 50.000 zł i grzywną KKS art. 80b do 720 stawek dziennych.

## Integracja z polskim ekosystemem: Comarch, Symfonia, enova, KAS, KRS, GPW

Agent łączy się z głównymi ERPami polskiego rynku przez API: [Comarch ERP Optima Księga Handlowa](https://www.comarch.pl/erp/comarch-erp-optima/) (lider w MŚP z planem kont konfigurowalnym wg KSR), Comarch ERP XL Finanse i Księgowość (Enterprise z generatorem JPK_KR), [Symfonia Finanse i Księgowość](https://www.symfonia.pl/) (Sage Symfonia z planem kont KSR), [enova365 Księgowość](https://www.enova.pl/) (mocna w controllingu, multi-bilans UoR i MSR), Sage Symfonia 50c (małe firmy), InsERT Subiekt nexo i Rewizor nexo (PRO Księga Handlowa), SAP S/4HANA Polish Localization (FI-PL z planem kont KAS dla Volkswagen Poznań, BMW Wrocław, Stellantis Tychy, Bosch Mirków), Asseco Softlab ERP (mapowanie KSR/MSR), ifirma.pl Księga Handlowa (cloud, JPK automatyczny), Mastermaq Domínio (biura rachunkowe, multi-podmiotowy).

Eksport JPK_KR generowany w trybie incremental codziennie, gotowy do żądania KAS w terminie 7 dni (Ordynacja podatkowa art. 193a). e-Sprawozdanie składane do KRS przez portal eKRS z certyfikatem kwalifikowanym CenCert/Szafir/EuroCert lub przez API KRS dla biur rachunkowych. Powiązanie z Agentem Odbioru Faktur przez numer KSeF FA(2), z Agentem Amortyzacji przez tabele KŚT i KSR 11, z Agentem Rezerw przez KSR 6, z Agentem Rozliczeń Międzyokresowych przez UoR art. 39. Dla emitentów GPW (Volkswagen Poznań nie notowany lokalnie ale konsoliduje do VW AG na Xetra; BMW Wrocław do BMW AG na Xetra; PKN Orlen, KGHM, PZU, Pekao, PKO BP, Allegro, CD Projekt notowane bezpośrednio na GPW), Agent generuje równolegle raporty wg MSR/MSSF dla skonsolidowania w siedzibie głównej - utrzymując sprawozdanie jednostkowe wg UoR (wymagane dla podatku CIT) i skonsolidowane wg MSSF (wymagane dla GPW i konsolidacji do matki UE) z pełną dokumentacją różnic trwałych i przejściowych zgodnie z KSR 2 i MSR 12.

--- Agent księgowania leasingu ---
> Księgowanie umów leasingowych zgodne z MSSF 16 i KSR 5: klasyfikacja oraz kalkulacja Right-of-Use i zobowiązania, z mostem do CIT.

Polskie księgowanie leasingu to jeden z najbardziej złożonych obszarów rachunkowości, obwarowany ustawą o rachunkowości z 29.09.1994 (art. 3 ust. 4-6 - 5 kryteriów alternatywnych klasyfikacji finansowej, art. 17, art. 31-33 - amortyzacja), KSR 5 (Komitet Standardów Rachunkowości przy MF, paragraf 19 - IBR, 26-30 - amortyzacja, 33-37 - modyfikacje), MSSF 16 dla emitentów GPW i instytucji finansowych pod nadzorem KNF (jednolite ujmowanie wszystkich umów), ustawą o CIT z 15.02.1992 art. 17a-17l (operacyjny: cała rata kosztem; finansowy: tylko odsetki oraz amortyzacja KŚT), ustawą o KSeF z 16.10.2023 (rata FA(2) jako zdarzenie księgowe od 1.7.2026), Kodeksem cywilnym art. 7091-7099 oraz orzecznictwem NSA (II FSK 345/22, II FSK 678/23, II FSK 901/24). Polski rynek leasingu osiągnął w 2025 roku 88 mld zł wg Polskiego Związku Leasingu, a każda istotna spółka prowadzi portfel 50-500 aktywnych umów. Błędna klasyfikacja jednej umowy hybrydowej może wygenerować dopłatę CIT 2,4 mln zł oraz restatement opublikowanego sprawozdania. [Decision Layer](/pl/decision-layer/) odwzorowujący 13-etapowy łańcuch strukturalnie eliminuje to źródło błędów.

## Błędna klasyfikacja umowy leasingu generuje dopłatę CIT, audyt KAS i restatement opublikowanego sprawozdania - cena nieprawidłowego ujmowania

Niewłaściwa klasyfikacja leasingu generuje zobowiązania na pięciu frontach. Pierwszy to KKS art. 56 - kara grzywny do 720 stawek dziennych przy stawce maksymalnej 30.000 zł, czyli 21,6 mln zł, oraz pozbawienie wolności do 5 lat. Dochodzą do tego art. 60 (nieprowadzenie ksiąg, czyli brak JPK_KR z zapisami RoU dla emitentów GPW), art. 61 (wadliwa ewidencja, czyli błąd podziału raty na część kapitałową i odsetkową lub nieujęcie Right-of-Use Asset wymaganego przez MSSF 16) oraz art. 62 (wadliwa faktura w KSeF). Łącznie ryzyko karne przekracza 36 mln zł, a do tego dochodzi osobista odpowiedzialność karna zarządu.

Drugi front to dopłata CIT 19 procent (mali podatnicy 9 procent do 2 mln EUR przychodu) wraz z odsetkami za zwłokę 12,75 procent rocznie wg Ordynacji podatkowej art. 53. Błędna klasyfikacja 80 umów leasingu samochodów jako operacyjny (cała rata kosztem wg CIT art. 17b) zamiast finansowy (tylko odsetki oraz amortyzacja wg CIT art. 17f) generuje dopłatę 2,4 mln zł oraz odsetki 305 tys. zł po roku, a także utratę kosztu uzyskania przychodu, jeśli koszty rozliczono wcześniej, niż dopuszcza CIT.

Trzeci front to restatement opublikowanego sprawozdania finansowego dla emitentów GPW. KSH art. 218 wymaga zatwierdzenia przez WZ, a restatement oznacza ponowne zatwierdzenie z notą wyjaśniającą. Według KSH art. 231 absolutorium zarządu jest uzależnione od rzetelnego sprawozdania, więc błędna klasyfikacja portfela leasingu może prowadzić do nieudzielenia absolutorium z odpowiedzialnością odszkodowawczą. Akcjonariusz może zaskarżyć uchwałę o zatwierdzeniu (KSH art. 425) z konsekwencjami dla rozliczenia roku.

Czwarty front to dla emitentów GPW Rozporządzenie MAR 596/2014 art. 17, które wymaga raportu bieżącego o informacji poufnej - restatement portfela leasingowego jest istotną zmianą wcześniejszego sprawozdania, a KNF może nałożyć karę do 5 mln zł za niezgłoszenie. Cena akcji może spaść 8-15 procent (precedens z 2023 roku: spółka deweloperska reklasyfikowała 120 umów leasingu nieruchomości jako finansowe po audycie KAS). Możliwe są też pozwy zbiorowe akcjonariuszy o odszkodowanie (KSH art. 484).

Piąty front to badanie ustawowe biegłego rewidenta PIBR. KSRF 250/320/540, z krytycznym KSRF 540 dla IBR, oznacza, że biegły rewident może wydać opinię z zastrzeżeniami lub odmówić opinii, co blokuje zatwierdzenie sprawozdania przez WZ. Realny przykład z 2025 roku: spółka logistyczna z Wrocławia (NewConnect, 380 mln zł obrotu, 220 aktywnych umów). Audyt KAS reklasyfikuje 64 umowy z operacyjnego na finansowy, co daje dopłatę CIT 1,9 mln zł, odsetki 240 tys. zł oraz sankcję KKS art. 56 w wysokości 1,4 mln zł. Do tego dochodzi restatement sprawozdania za 2024 rok: raport bieżący do KNF, spadek akcji o 12 procent, nieudzielone absolutorium oraz pozwy akcjonariuszy na 3,2 mln zł.

## Polski łańcuch księgowania leasingu przechodzi 13 deterministycznych etapów - z mostem CIT art. 17a-17l i integracją KSeF FA(2)

Polski system księgowania leasingu należy do najbardziej rozbudowanych w UE: UoR z 1994, KSR 5, MSSF 16 dla GPW, CIT art. 17a-17l, KSeF od 2026 oraz Kodeks cywilny art. 7091-7099. Struktura instytucjonalna obejmuje KAS, MF (KSR), KIS (interpretacje indywidualne), KIBR/PIBR, KNF, GPW, Polski Związek Leasingu, WSA/NSA oraz Sąd Rejonowy.

13 etapów polskiego pipeline'u to: (1) ekstrakcja danych umowy przez LLM, (2) klasyfikacja finansowy lub operacyjny wg UoR/KSR 5 (5 kryteriów alternatywnych), (3) klasyfikacja MSSF 16 dla emitentów GPW (jednolite ujmowanie), (4) określenie IBR z dokumentacją założeń, (5) kalkulacja wartości początkowej Right-of-Use Asset, (6) tworzenie harmonogramu amortyzacji, (7) tworzenie harmonogramu rat (część kapitałowa i odsetkowa), (8) walidacja faktury leasingowej KSeF FA(2), (9) most CIT art. 17a-17l z ujmowaniem bilansowym (identyfikacja różnic czasowych), (10) indeksacja CPI/WIBOR z remeasurement, (11) modyfikacje umowy (remeasurement lub nowa umowa), (12) JPK_KR z zapisami leasingu oraz (13) noty ujawnień wg MSSF 16 paragraf 51-60 lub KSR 5 paragraf 50-58.

Scenariusz: spółka logistyczna z Łodzi notowana na NewConnect (480 mln zł obrotu, 320 aktywnych umów - 180 ciężarówek z Europejskim Funduszem Leasingowym, 80 naczep z Millennium Leasing, 40 wózków z mLeasing, 20 maszyn z ING Lease). Po końcu kwartału agent ekstrahuje przez LLM 25 nowych umów. Klasyfikuje je wg UoR/KSR 5 - 18 jako operacyjne (samochody na 36 miesięcy, czyli 60 procent okresu użytkowania 60 miesięcy) oraz 7 jako finansowe (maszyny na 84 miesiące, czyli 87,5 procent okresu 96 miesięcy, z opcją kupna za 1 procent ceny rynkowej). Dla MSSF 16 wszystkie 25 ujmuje jako RoU. Księgowy ocenia IBR na 6,8 procent dla samochodów (WIBOR 5,5 procent, premia za bonitet 80 pb oraz premia za okres 50 pb) i 7,2 procent dla maszyn. Agent oblicza wartość bieżącą rat, RoU 4,2 mln zł oraz Lease Liability 4,2 mln zł, generuje harmonogramy amortyzacji liniowej i podziału rat metodą IRR, waliduje 25 faktur KSeF FA(2) oraz tworzy JPK_KR z kontami 010 (RoU 4,2 mln), 240 (Lease Liability 4,2 mln) i 750 (Odsetki), a także noty ujawnień wg MSSF 16 paragraf 51-60.

W [Decision Layer](/pl/decision-layer/) z 13 etapów 7 to decyzje regułowe (R): klasyfikacja MSSF 16 (sprawdzenie statusu spółki), kalkulacja RoU, harmonogram amortyzacji, harmonogram rat, walidacja KSeF FA(2), indeksacja CPI/WIBOR oraz JPK_KR; 4 to decyzje uznaniowe księgowego (H): klasyfikacja UoR/KSR 5 (5 kryteriów alternatywnych), IBR z dokumentacją, most CIT wobec UoR oraz modyfikacje umowy; 2 są wspomagane przez LLM (A): ekstrakcja umowy oraz projekt not ujawnień. Bez generatywnej AI w decyzjach o klasyfikacji lub IBR - LLM przygotowuje, a księgowy decyduje.

## Krzyżowa kontrola CIT art. 17a-17l z ujmowaniem bilansowym - identyfikacja różnic czasowych dla aktywów i rezerw odroczonych

Przed zamknięciem okresu agent wykonuje trzy rodzaje krzyżowej kontroli, z których każda może zatrzymać proces. (1) Walidacja CIT art. 17b (operacyjny: cała rata kosztem) wobec UoR/KSR 5 (operacyjny: rata kosztem) - dla większości spółek bez MSSF 16 nie ma różnicy. Dla emitentów GPW z MSSF 16 bilansowo ujmuje się amortyzację Right-of-Use Asset przez 60 miesięcy oraz odsetki, a podatkowo całą ratę kosztem, co generuje aktywo z tytułu odroczonego podatku. (2) Walidacja CIT art. 17f (finansowy: odsetki oraz amortyzacja stawkami KŚT) wobec UoR/KSR 5 (amortyzacja przez okres umowy) - inny okres tworzy różnicę czasową. Przykład: leasing samochodu osobowego na 60 miesięcy z podatkową amortyzacją KŚT 20 procent rocznie (czyli 60 miesięcy) nie daje różnicy, ale leasing maszyny budowlanej na 84 miesiące z podatkową amortyzacją KŚT 10 procent (czyli 120 miesięcy) daje różnicę 36 miesięcy generującą aktywo z tytułu odroczonego podatku. (3) Krzyżowa kontrola portfela z bilansem: suma RoU per umowa musi się równać saldu konta 010, a suma Lease Liability per umowa saldu konta 240; rozbieżność generuje raport dla biegłego rewidenta jako sygnał o nierzetelności ksiąg prowadzący do sankcji KKS art. 61.

## Polskie przypadki szczególne: leasing zwrotny sale and leaseback, subleasing nieruchomości, opcja przedłużenia, leasing hybrydowy najmu, leasingu i serwisu

Leasing zwrotny sale and leaseback (MSSF 16 paragraf 100-103, KSR 5 paragraf 41-43) to sprzedaż środka trwałego z natychmiastowym zwrotnym wzięciem go w leasing. Klasyfikacja zależy od tego, czy przeniesienie kontroli w sprzedaży spełnia kryteria MSSF 15 (wtedy zysk ze sprzedaży ujmuje się w RZiS, a nowy leasing jako RoU); w przeciwnym razie całą transakcję traktuje się jako finansowanie (bez zysku, z Lease Liability). Ocena uznaniowa wymaga interpretacji klauzul, a orzecznictwo NSA II FSK 901/24 jest precedensowe. Do transakcji między podmiotami powiązanymi stosuje się CIT art. 17h.

Subleasing nieruchomości to umowa, w której korzystający wynajmuje aktyw kolejnemu najemcy (np. sieci handlowe wynajmują lokale w centrach handlowych podnajemcom). MSSF 16 paragraf 67-69 klasyfikuje subleasing pod kątem księgowania subleasingobiorcy: przy subleasingu finansowym Lease Liability głównej umowy pozostaje, RoU spada o część subleasingowaną, a subleasing ujmuje się jako finansowy lease receivable; przy subleasingu operacyjnym RoU pozostaje. Orzecznictwo NSA II FSK 678/23 (subleasing nieruchomości) wymaga oceny, czy subleasing przenosi wszystkie ryzyka i korzyści.

Opcja przedłużenia umowy - prawdopodobieństwo skorzystania (reasonably certain) wpływa na okres umowy używany do kalkulacji RoU. Ocena uznaniowa wymaga uzasadnienia (np. inwestycje w aktyw dostosowany do potrzeb, brak alternatyw rynkowych, koszt zmiany lokalizacji). KSRF 540 wymaga dokumentacji oszacowań, a reestymacji dokonuje się co okres sprawozdawczy.

Leasing hybrydowy łączący najem, leasing i serwis to umowa zawierająca różne komponenty (najem powierzchni, leasing wyposażenia, serwis sprzątania). MSSF 16 paragraf 12-17 wymaga separacji komponentów: księgowy oddziela leasing od komponentów nieleasingowych (serwis) i alokuje cenę transakcyjną na podstawie obserwowalnych cen pojedynczych. Interpretacje KIS (0114-KDIP2-2.4010.123.2024) są precedensowe dla tej klasyfikacji.

## Integracja z polskim ekosystemem: Comarch ERP XL, SAP S/4HANA Lease Management, Oracle Lease Accounting, KSeF FA(2), JPK_KR, e-Sprawozdanie KAS

Agent łączy się z głównymi systemami ERP polskiego rynku: [Comarch ERP XL Konsolidacja z modułem Leasing](https://www.comarch.pl/erp/comarch-erp-xl/) (lider segmentu GPW middle-market, klasyfikacja UoR/KSR 5 i MSSF 16, kalkulacja RoU i Lease Liability, harmonogramy amortyzacji i rat, JPK_KR jako podstawowe źródło z modułu Leasing), [Comarch ERP Optima z modułami Środki Trwałe i Leasing](https://www.comarch.pl/erp/comarch-erp-optima/) (lider MŚP, integracja z KSeF FA(2)), [Symfonia Finanse i Księgowość z Symfonia Środki Trwałe](https://www.symfonia.pl/) (masowa obsługa emitentów GPW, automatyczna klasyfikacja umów), [enova365 Środki Trwałe z modułem Leasing](https://www.enova.pl/) (obsługa wielowalutowa wg NBP, indeksacja CPI/WIBOR z API GUS i NBP, leasing hybrydowy łączący najem, leasing i serwis), SAP S/4HANA Polish Localization Lease Management (Volkswagen Poznań, BMW Wrocław, Stellantis Tychy, Bosch Mirków, Mercedes Jawor, LG Wrocław - ponad 1000 aktywnych umów leasingu, równoległe raportowanie multi-GAAP wg UoR i MSSF 16, harmonogramy metodą procentu zaawansowania), Oracle Fusion Cloud ERP Lease Accounting (PKN Orlen, KGHM, PZU, PKO BP, Pekao - portfel leasingu 200-500 mln zł, automatyczne stosowanie MSSF 16 z wyjątkami dla umów krótkoterminowych i niskowartościowych) oraz Microsoft Dynamics 365 Finance z modułem Lease Accounting (chmura, automatyczna aktualizacja stawek WIBOR/POLONIA z API NBP, walidacja KSeF FA(2) z numerem KSeF jako referencją).

Po stronie integracji podatkowo-bilansowej agent łączy się z KSeF FA(2) API z certyfikatem CenCert/Szafir/EuroCert do odbioru rat leasingowych z numerem KSeF jako referencją księgową, bramką MF e-Deklaracje (CIT-8, JPK_KR, JPK_VAT z podpisem kwalifikowanym), API NBP (api.nbp.pl) dla WIBOR/POLONIA i kursów walutowych, API GUS (api.stat.gov.pl) dla CPI, API NIP/REGON GUS do walidacji finansującego oraz API e-Sprawozdania do KAS i KRS (XBRL). Integruje się też z Polskim Związkiem Leasingu i BIEK do weryfikacji wiarygodności kontrahentów przed zawarciem umowy. Audit trail jest kompatybilny z kontrolą KAS (krzyżowo CIT art. 17a-17l wobec UoR art. 3 ust. 4-6), KIBR/PIBR (KSRF 250/320/540), KNF (MAR dla emitentów GPW), GPW, KIS (interpretacje indywidualne 0114-KDIP2-2.4010.123.2024, 0111-KDIB1-1.4010.456.2025), WSA/NSA (II FSK 345/22, II FSK 678/23, II FSK 901/24) oraz Sądem Rejonowym (KKS art. 56/60/61/62). Decision Logging i kompletny Audit Trail służą obronie przed sankcją KKS art. 56 (do 21,6 mln zł), restatementem z konsekwencjami dla absolutorium zarządu (KSH art. 231) oraz pozwami akcjonariuszy (KSH art. 425 i 484).

--- Agent Management Reporting ---
> Oblicza centralne KPI (EBITDA, Working Capital, DSO, DPO), konsoliduje dane, rozpoznaje anomalie.

Zespoły finansowe poświęcają według aktualnych badań około 300 godzin rocznie na ręczną pracę raportową - czas, który nie jest przeznaczony ani na analizę, ani na przygotowanie decyzji (źródło: Float Financial, 2025). Wąskie gardło w Management Reporting nie leży w interpretacji wskaźników. Leży w konsolidacji, która każdej interpretacji musi poprzedzać.

## Konsolidacja pochłania czas, którego brakuje na analizę

Typowe zamknięcie miesiąca w większym średnim przedsiębiorstwie trwa od sześciu do dziesięciu dni roboczych. Potem zaczyna się właściwa praca controllera: dane z księgowości, controllingu, treasury i systemów operacyjnych scalić, eliminacje przeprowadzić, KPI obliczyć, porównania z poprzednim miesiącem i rokiem zestawić. Dopiero gdy ta podstawa stoi, można zaktualizować kokpit CFO.

W praktyce oznacza to: liczby są technicznie poprawne piątego dnia roboczego - ale prezentacja dla zarządu leży gotowa dopiero ósmego lub dziewiątego. Nie dlatego, że analiza jest złożona, lecz dlatego, że trzy dni znikają w ręcznym scalaniu eksportów z Excela, wyciągów z ERP i raportów controllingu. Każdy cykl raportowy powtarza ten sam nakład, ponieważ logika konsolidacji nigdzie nie istnieje jako proces wielokrotnego użytku.

## Regułowe obliczanie KPI skraca cykl o dni

EBITDA, Working Capital, DSO, DPO i Cash Conversion Cycle podlegają zdefiniowanym formułom. Nie ma marginesu interpretacji w pytaniu, jak oblicza się DSO - tylko w pytaniu, co rosnący DSO oznacza dla biznesu. Dokładnie tu wchodzi [Decision Layer](/pl/decision-layer/).

Agent Management Reporting przejmuje pierwszą kategorię w pełni: pobiera skonsolidowane wartości z księgowości i controllingu, stosuje zapisane formuły obliczeniowe i automatycznie aktualizuje dashboard po oznaczeniu zamknięcia miesiąca jako kompletnego. Źródło danych, zastosowana formuła i wynik są dokumentowane dla każdego KPI - odtwarzalnie i gotowe do audytu.

Firmy automatyzujące konsolidację raportują o redukcji cyklu Close-to-Report o 50 procent (źródło: Deloitte CFO Signals Survey, H4 2025). Z ośmiu dni robi się cztery. Z reaktywnego procesu raportowego staje się rytm, na którym zarząd może polegać.

## Rozpoznawanie anomalii czyni raportowanie proaktywnym zamiast reaktywnym

Najcenniejszą informacją w raporcie miesięcznym nie jest potwierdzenie, że wszystko idzie zgodnie z planem. Jest to wczesna identyfikacja odchyleń, zanim staną się wymagające wyjaśnienia w następnym raporcie kwartalnym.

Agent porównuje każdy obliczony KPI z historycznymi przedziałami i statystycznymi wartościami oczekiwanymi. Gdy DSO rośnie o 12 dni lub Working Capital wykazuje skok poza normę sezonową, jest to flagowane - nie jako alarm, lecz jako propozycja komentarza z danymi kontekstowymi. Controller otrzymuje projekt, który nazywa anomalię, umieszcza ją w historycznym przebiegu i wyprowadza możliwe przyczyny z danych źródłowych.

To zmienia rolę controllera fundamentalnie: zamiast szukać liczb mogących wymagać wyjaśnienia, zaczyna od spriorytetyzowanej listy i inwestuje swój czas w analizę przyczyn.

## Strategiczna narracja pozostaje przy CFO

Co rosnący Cash Conversion Cycle oznacza dla negocjacji z dostawcami w następnym kwartale, który rozwój KPI w sprawozdaniu z działalności wymaga szczególnego komentarza, jak liczby są pozycjonowane wobec rady nadzorczej - to decyzje wymagające znajomości biznesu, doświadczenia branżowego i osądu strategicznego.

Decision Layer wyznacza tu jasną granicę. Siedem z ośmiu kroków decyzyjnych w procesie raportowym biegnie regułowo lub wspierane przez AI. Ósmy - interpretacja strategiczna - pozostaje przy człowieku. Nie jako ustępstwo, lecz jako decyzja architektoniczna: CFO, który buduje swoją prezentację dla zarządu z przygotowanego projektu z udokumentowanymi KPI i oznaczonymi anomaliami, podejmuje lepsze decyzje niż ten, który pierwszą połowę czasu spędza na konsolidacji danych.

--- Agent przebiegów płatności ---
> Przebiegi płatności z walidacją białej listy VAT i mechanizmem podzielonej płatności (MPP), generujące pliki ELIXIR i SORBNET2.

Polskie przebiegi płatności to fundament zarządzania płynnością firmy, obwarowany wielowarstwową regulacją podatkową, płatniczą i AML. Mechanizm Podzielonej Płatności (MPP) wg art. 108a Ustawy o VAT z 11.03.2004 jest obowiązkowy dla 150 grup towarów i usług z załącznika nr 15, gdy faktura przekracza 15.000 zł brutto - brak skutkuje sankcją 30% wartości VAT oraz utratą kosztu CIT/PIT (art. 15d CIT, art. 22p PIT). Biała lista podatników VAT (art. 96b VAT, whitelist.gov.pl) wymaga walidacji rachunku dostawcy w dniu płatności - błąd przy kwocie >15.000 zł skutkuje utratą kosztu CIT/PIT, chyba że w 7 dni zostanie złożone ZAW-NR. Ustawa o usługach płatniczych z 19.08.2011 (PSD2) wymaga silnego uwierzytelnienia (SCA) i Polish Open Banking API, a Ustawa AML z 1.03.2018 - screeningu sankcji UE, OFAC, ONZ i GIIF pod groźbą kary do 5 mln zł lub 10% obrotu (art. 147). ELIXIR (KIR), Express Elixir (instant 24/7), SORBNET2 (NBP) i SWIFT MT103 to różne systemy o różnych zastosowaniach. Każdy przebieg musi spełniać wszystkie wymogi jednocześnie - błąd w MPP lub białej liście generuje sankcję sięgającą od kilku do kilkudziesięciu procent transakcji.

## Sankcja MPP 30% wartości VAT, utrata kosztu CIT i kara KAS do 5 mln zł

Niewłaściwy przebieg płatności w Polsce generuje pasywo na czterech frontach jednocześnie. KAS na podstawie art. 108a ust. 7 Ustawy o VAT nakłada sankcję 30% wartości VAT za brak obowiązkowego MPP - dla faktury 100.000 zł netto i 23.000 zł VAT to 6.900 zł. Do tego dochodzi utrata kosztu CIT/PIT zgodnie z art. 15d CIT (art. 22p PIT) - przy stawce CIT 19% utrata 19.000 zł kosztu daje 3.610 zł dodatkowego CIT. Łącznie dla faktury 123.000 zł brutto wychodzi 25.900 zł sankcji i utraty kosztu, czyli praktycznie 21% wartości netto. Identyczna utrata CIT/PIT grozi przy płatności poza białą listą >15.000 zł bez ZAW-NR w 7 dni. Firma z 200 mln zł obrotu i 500 dostawcami z załącznika nr 15 wykonuje 80-150 transakcji MPP miesięcznie - jeden niedopilnowany przypadek to 25.000-50.000 zł straty rocznie.

Najgroźniejsza jest sankcja administracyjna AML do 5 mln zł lub 10% obrotu rocznego (art. 147 Ustawy z 1.03.2018) za brak screeningu sankcji UE, OFAC i ONZ. Towarzyszy jej odpowiedzialność karna z art. 74 do 12 lat pozbawienia wolności za świadome obejście sankcji. Dla firmy z 200 mln zł obrotu AML w wysokości 10% oznacza 20 mln zł - dwukrotność rocznego zysku. Dochodzi do tego KKS art. 56 (narażenie podatku na uszczuplenie) z karą grzywny do 720 stawek dziennych (21,6 mln zł), a w skrajnych przypadkach pozbawienie wolności do lat 5. Na końcu jest utrata wiarygodności płatniczej w BIK przy opóźnieniach - obniżenie scoringu podnosi marżę kredytową o 150-300 bp dla przyszłych transakcji.

## Polskie przebiegi płatności przechodzą 16 deterministycznych etapów - więcej niż w Niemczech (8) lub Hiszpanii (10)

Polski system płatniczy należy do najbardziej rozbudowanych w UE: Ustawa o VAT 2004 z MPP i białą listą, Ustawa o usługach płatniczych 2011 z PSD2, Ustawa AML 2018 oraz Ustawa o przeciwdziałaniu opóźnieniom 2013. Dochodzą do tego odmienności podatkowe (utrata kosztu przy braku MPP lub białej listy nie ma odpowiednika w UE) i rozbudowana struktura instytucjonalna (KIR z ELIXIR i Express Elixir, NBP z SORBNET2, PSP z BLIK, MF z whitelist.gov.pl, GIIF z AML, Polish Open Banking API). 16 deterministycznych etapów: selekcja faktur wymagalnych wg art. 19a VAT, walidacja białej listy, klasyfikacja MPP wg załącznika nr 15, identyfikacja zapisu cyklicznego (LLM), optymalizacja skonta wg KC art. 359, wybór systemu płatności (ELIXIR/Express Elixir/SORBNET2), format zagraniczny (SEPA/MT103), generowanie pliku, deduplikacja przez numer KSeF, sprawdzenie płynności przez PSD2, screening sankcji, BLIK B2B incoming, ZAW-NR przy potrzebie, weryfikacja czterech oczu z PSD2 SCA, niezmienialność SHA-256.

Scenariusz: zakład produkcyjny w Tychach z 2.000 fakturami miesięcznie, 320 z załącznika nr 15 (paliwa, części Bosch/Continental, stal, elektronika), 45 dostawcami zagranicznymi (DE/CZ/SK SEPA EUR; USA/UK SWIFT MT103). W poniedziałek o 7:00 Agent identyfikuje 480 faktur wymagalnych, waliduje białą listę dla 380 kwot >15.000 zł (90 sekund API whitelist.gov.pl), klasyfikuje 95 faktur MPP, oblicza skonto dla 120 propozycji (2%/14 dni = 52% APR), sprawdza saldo na 6 rachunkach (Pekao główny, PKO BP rachunek VAT, ING dewizowy EUR, mBank dewizowy USD, Santander backup, Millennium gotówkowy) przez Polish Open Banking, generuje plik ELIXIR-O dla 380 B2B krajowych, Express Elixir dla 25 pilnych ≤100k zł, SORBNET2 dla 8 wysokokwotowych >1 mln zł, 12 SWIFT MT103. Każda faktura przechodzi screening (UE, OFAC, ONZ, GIIF) - 0 trafień blokujących, 2 ostrzeżenia PEP. O 9:30 plik jest gotowy do zatwierdzenia, Dyrektor Finansowy zatwierdza go przez SCA (token, SMS, aplikacja mBank) o 10:00, a banki potwierdzają wykonanie (MT900) do 11:30.

W [Decision Layer](/pl/decision-layer/) z 16 etapów 13 to decyzje regułowe (R), 1 LLM (A - powtarzalność wzorca cyklicznego) i 2 decyzje człowieka (H - czterech oczu z PSD2 SCA, override blokady AML). Każde wyliczenie to zastosowanie Ustawy o VAT, UUP, KC, Ustawy AML lub specyfikacji KIR/NBP/SWIFT.

## Kontrola wiarygodności przed wykonaniem: walidacja białej listy, klasyfikacja MPP i screening AML

Trzy etapy walidacyjne wykonywane przed wygenerowaniem pliku - każdy może zatrzymać płatność. (1) Biała lista (whitelist.gov.pl): API REST MF zwraca w czasie poniżej 200 ms JSON z listą rachunków zgłoszonych do US, statusem (czynny, zwolniony, wykreślony) i datą rejestracji. Agent porównuje NRB z faktury (26 cyfr ISO IBAN PL) z listą - przy braku i kwocie >15.000 zł blokuje płatność lub generuje ZAW-NR, a wynik zachowuje z timestampem. (2) Klasyfikacja MPP wg załącznika nr 15: baza PKWiU GUS dla 150 grup obejmuje paliwa (PKWiU 19.20.21, 19.20.22, 06.10.10), oleje napędowe (19.20.21.81), węgiel (05.10.10), stal (24.10.x, 24.20.x, 24.31-34), elektronikę (26.20.x, 27.40.x), części samochodowe (29.32.x), surowce wtórne (38.32.x) i usługi budowlane (43.21-22, 43.31-32, 43.91-99). Agent sprawdza klasyfikację dostawcy z REGON i opis z faktury - jeśli odpowiada załącznikowi i przekracza 15.000 zł, ustawia flagę MPP. (3) Screening AML: listy UE Consolidated, OFAC SDN, ONZ i GIIF z dzienną aktualizacją - sprawdzany jest NIP (krajowy) albo dane zagraniczne (IBAN/BIC, nazwa, adres, data urodzenia) metodą fuzzy matching. Trafienie blokujące oznacza blokadę i alert do Officera AML, a ostrzeżenie PEP - wymóg dodatkowej dokumentacji i zatwierdzenia Dyrektora Finansowego.

## Przypadki szczególne w Polsce: ZAW-NR, dobrowolny MPP, BLIK B2B incoming, SWIFT z FX

Zawiadomienie ZAW-NR (Rozporządzenie MF z 18.06.2018) to narzędzie ratunkowe przy płatności poza białą listą - składa się do naczelnika US właściwego dla nabywcy w 7 dni kalendarzowych od zlecenia płatności. Pola: NIP nabywcy, NIP dostawcy, numer faktury, kwota brutto, NRB płatności, data, uzasadnienie. Agent generuje automatycznie z wymogiem zatwierdzenia Dyrektora Finansowego (typowe sytuacje: pomyłka NRB w aktualizacji bazy MF, dostawca nowo zarejestrowany przed wprowadzeniem do whitelist, rachunek dewizowy niezgłoszony w MF). Brak ZAW-NR w 7 dni = trwała utrata kosztu CIT/PIT.

MPP dobrowolny (art. 108a ust. 1d Ustawy o VAT) dla faktur <15.000 zł lub poza załącznikiem nr 15 to dodatkowa ochrona przed solidarną odpowiedzialnością za VAT dostawcy (art. 105a). Agent oferuje MPP dobrowolny w sytuacjach podwyższonego ryzyka: dostawca z krótką historią (<12 miesięcy), zmiana NIPu/rachunku w ostatnich 30 dniach, sygnały AML warning, branże wysokiego ryzyka (paliwa, złomownie, części samochodowe), zatory płatnicze.

BLIK B2B incoming (PSP) dla mikro-faktur do 5.000 zł umożliwia natychmiastowe rozliczenia bez ELIXIR. Klient generuje 6-cyfrowy kod w aplikacji banku, firma wprowadza go do bankowości - rozliczenie w sekundach. Agent identyfikuje wpływ po tytule zawierającym numer KSeF FA(2) i NIP, rozlicza z fakturą wymagalną. Limity: 5.000 zł/transakcja, dzienny limit kontrahenta zależny od banku.

SWIFT MT103 dla płatności zagranicznych poza SEPA (USA USD, UK GBP, CHF, NOK, CNH) wymaga BIC (kod SWIFT 11 znaków), IBAN lub krajowego ekwiwalentu (w UK Sort Code z numerem rachunku, w USA ABA Routing z numerem rachunku), informacji o opłatach (OUR/BEN/SHA) oraz pełnych danych beneficjenta z adresem. Agent integruje się z FX (Cinkciarz.pl, Conotoxia, Western Union Business) - typowe oszczędności to 0,2-0,5% na transakcji wobec kursu bankowego (dla 100.000 EUR daje to 200-500 EUR).

## Integracja z polskim ekosystemem: Comarch, Symfonia, enova, Pekao, PKO BP, ING, KIR, NBP

Agent łączy się z głównymi ERPami polskiego rynku: [Comarch ERP Optima Płatności](https://www.comarch.pl/erp/comarch-erp-optima/) (lider w MŚP, natywna integracja bankowa), Comarch ERP XL Finanse (Enterprise z generatorem ELIXIR i modułem Treasury), [Symfonia Finanse](https://www.symfonia.pl/) (Sage Symfonia, masowy ELIXIR z API białej listy), [enova365 Finanse](https://www.enova.pl/) (mocna w controllingu, wielorachunkowa z automatycznym MPP), InsERT Subiekt nexo z Rachmistrzem nexo (Express Elixir z białą listą online), SAP S/4HANA Polish Localization (Treasury Module dla Volkswagen Poznań, BMW Wrocław, Stellantis Tychy, Bosch Mirków, Mercedes Benz Jawor), Asseco Softlab Treasury (mapowanie kont z PSD2), ifirma.pl Płatności (cloud z białą listą), i-Konto.pl Treasury (wielobankowa z SORBNET2 i ELIXIR) oraz Cinkciarz.pl i Conotoxia (FX dla SWIFT MT103).

Integracja bankowa przez Polish Open Banking API (Pekao, PKO BP, ING Bank Śląski, mBank, Santander, Millennium, Alior, Bank Pocztowy, Citibank Handlowy, BNP Paribas, Credit Agricole, Deutsche Bank, Raiffeisen, BOŚ). ELIXIR-O XML wg specyfikacji ZBP dla zwykłych B2B, Express Elixir dla pilnych ≤100.000 zł, SORBNET2 dla >1 mln zł przez API NBP, SWIFT MT103 dla zagranicznych. Powiązanie z Agentem Odbioru Faktur przez numer KSeF FA(2), z Agentem Walidacji Białej Listy przez API whitelist.gov.pl, z Agentem MPP przez PKWiU załącznika nr 15, z Agentem Cash Forecasting przez Polish Open Banking, z Agentem Bank Reconciliation przez MT940/CAMT.053. Audit trail kompatybilny z KAS (MPP/biała lista), GIIF (AML/CFT - STR >15.000 EUR), KNF, PIP (terminowość Ustawy o opóźnieniach z 8.03.2013), UODO (RODO) i biegłym rewidentem z PIBR/KIBR przy badaniu ustawowym.

--- Agent obsługi płatności ---
> Określa format (SEPA, SWIFT), tworzy pliki SEPA-XML, przekazuje do banku, przetwarza odpowiedzi i zapewnia zatwierdzenie czterech oczu powyżej progu.

Płatność jest zatwierdzona, IBAN się nie zgadza, plik zostaje odrzucony. Trzy dni później dostawca pyta o swoje pieniądze. Ten scenariusz kosztuje nie tylko płynność, lecz zaufanie. W europejskim obrocie płatniczym suma oszustw przy przelewach wyniosła według EBA i EBC w 2024 roku 2,2 miliarda EUR (ok. 2,4 mld USD) - a błędy formatowe, nieprawidłowe dane odbiorcy czy opóźnione eskalacje przy odrzuceniach dochodzą do tego. Ostatni odcinek między zatwierdzeniem a przekazaniem do banku zasługuje na taką samą dyscyplinę procesową jak samo zatwierdzenie.

## Między zatwierdzeniem a przekazaniem bankowym powstają najdroższe błędy

Agent przebiegów płatności decyduje, co kiedy jest płacone. Ale pytanie, jak płatność technicznie dociera do banku, pozostaje otwarte. Dokładnie tu wchodzi Agent obsługi płatności. Określa format - SEPA, SWIFT lub czek - na podstawie danych podstawowych odbiorcy, generuje plik pain.001 i przekazuje go przez EBICS lub API. Brzmi jak czysta technika. W praktyce płatności nie kończą się niepowodzeniem z powodu zatwierdzenia, lecz z powodu błędnych kodów BIC, brakujących pól obowiązkowych lub wygasłych certyfikatów. Zespół Treasury przetwarzający 400 płatności dziennie nie jest w stanie sprawdzić tych błędów pojedynczo. Regułowy agent - tak.

## Dziesięć kroków decyzyjnych zastępuje ręczne obejście

[Decision Layer](/pl/decision-layer/) rozkłada ścieżkę płatności na dziesięć kroków: wybór formatu, walidacja IBAN i odbiorcy, kontrola podwójnych płatności, screening list sankcyjnych, kontrola obowiązku zgłoszenia AWV, generowanie XML, przekazanie bankowe, przetwarzanie odpowiedzi, eskalacja przy niepowodzeniu i zatwierdzenie czterech oczu przy wysokich płatnościach jednorazowych. Dziewięć z tych kroków jest w pełni regułowych. Format płatności wynika z danych podstawowych odbiorcy, walidacja pain.001 podąża za standardem SEPA, przekazanie bankowe to techniczny handshake, a komunikaty o błędach są automatycznie analizowane i eskalowane do właściwego pracownika. Tylko przy płatnościach jednorazowych powyżej skonfigurowanego progu wkracza człowiek. Ten wzorzec - zestaw reguł dla masy, kontrola ludzka dla ryzyka - jest sygnaturą Decision Layer poziomu 1.

## Verification of Payee zmienia wymagania fundamentalnie

Od października 2025 wszystkie instytucje kredytowe w EOG są zobowiązane do przeprowadzania weryfikacji odbiorcy przed każdym przelewem SEPA. Podane imię i nazwisko jest porównywane z rzeczywistym posiadaczem konta. Dla Agenta obsługi płatności oznacza to: każda wychodząca płatność przechodzi dodatkowy krok walidacji przed dotarciem do banku. Rozbieżności między danymi podstawowymi a posiadaczem konta są rozpoznawane i dokumentowane, zanim popłyną pieniądze. Banki raportują, że zaostrzona kontrola sankcji w ramach SEPA Instant prowadzi do 30 - 50 procent więcej flagowanych transakcji. Agent przetwarzający te odpowiedzi w czasie rzeczywistym zapobiega temu, by ważne płatności utknęły w kolejce kontrolnej.

## Człowiek decyduje tam, gdzie automatyzacja wygenerowałaby ryzyko

Zatwierdzenie czterech oczu przy wysokich płatnościach jednorazowych nie jest ustępstwem wobec braku zaufania do techniki. Jest wymogiem IKS, który Decision Layer świadomie pozostawia jako decyzję ludzką. Przy nietypowej płatności jednorazowej powyżej 50 000 lub 100 000 EUR (ok. 54 000 - 108 000 USD) sama zgodność z regułami nie wystarcza - tu potrzebny jest osąd handlowy. GoBD (niemiecki standard dokumentacji) wymaga, by każda płatność była odtwarzalnie udokumentowana jako zdarzenie gospodarcze. Agent dostarcza tę dokumentację automatycznie: format płatności, moment przekazania, odpowiedź banku, a przy płatnościach jednorazowych moment zatwierdzenia z osobą zatwierdzającą. Protokół obsługi płatności powstaje jako efekt uboczny procesu, nie jako wsteczny obowiązek.

--- Agent obliczania płac ---
> Kalkulacja brutto-netto: ZUS pełen pakiet, PIT 12/32 procent, PPK 2/1,5 procent, Kodeks Pracy art. 80-94, zajęcia komornicze KPC art. 87-88 - matematyka płacowa bez procesu HR.

Lista płac wg polskiego prawa to arytmetyka prawnie wiązana. Wynagrodzenie zasadnicze wynika z umowy o pracę (art. 29 KP). Dodatki - nocny 20% wg art. 151⁸ KP oraz godziny nadliczbowe 50%/100% wg art. 151¹ KP - wynikają z Kodeksu Pracy lub UZP. Składki ZUS pracownika są stałe i wynoszą łącznie 13,71% (emerytalna 9,76%, rentowa 1,5%, chorobowa 2,45%), z limitem 30-krotności przeciętnego wynagrodzenia (w 2026 roku 234 720 zł). NFZ to 9%, PIT idzie wg skali 12%/32% z kwotą wolną 30 000 zł, a PPK ma stawkę 2%/1,5%. Zajęcia komornicze ogranicza KPC art. 871-882. Żaden krok nie wymaga decyzji uznaniowej. Mimo to w typowych działach płac regularnie powstają korekty - a od czasu eDeklaracji ZUS i e-ZLA każda korekta wymaga zdarzeń korygujących z terminami ustawowymi.

## Korekty list płac generują ryzyko kar PIP do 30 000 zł

Naruszenia prawa pracy Państwowa Inspekcja Pracy (PIP) może ukarać grzywną do 30 000 zł wg art. 281 Kodeksu Pracy. Dla typowej polskiej firmy średniej (300-1000 zatrudnionych) oznacza to, że każda lista płac z błędami, która wymusza korektę DRA lub PIT-11 po terminie, dokłada ryzyko mandatu PIP. Przy 30 korektach w problemowym cyklu rachunek rośnie do kilkudziesięciu tysięcy złotych - i to bez kontroli ZUS oraz KAS, które mogą skutkować dochodzeniem zaległych składek z odsetkami za 5 lat wstecz.

American Payroll Association oraz analizy PwC Polska szacują bezpośredni koszt korekty na około 281 USD za incydent. Szkoda kolateralna w polskim systemie idzie dalej: kontrola PIP, sankcje ZUS (do 100% wartości składek za niedopłatę), korekty PIT-4R i PIT-11 z odsetkami oraz możliwy spór pracowniczy w sądzie pracy (przedawnienie 3 lata). Dla CFO operacji w Polsce każdy błąd listy płac uruchamia sześć wektorów ryzyka: operacyjne, finansowe, regulacyjne, pracownicze, podatkowe i reputacyjne.

## Lista płac PL przechodzi 16 deterministycznych etapów

Inaczej niż niemiecka standardowa płaca (12 etapów), polska lista płac wymaga 16 deterministycznych etapów ze względu na granularność systemu. Składają się na nią: trzyskładnikowe składki ZUS pracownika (9,76%/1,5%/2,45%), pięcioskładnikowe składki pracodawcy (emerytalna 9,76%, rentowa 6,5%, wypadkowa indywidualna 0,67-3,33% zależna od PKD, FP 2,45%, FGSP 0,1%), składka NFZ 9%, progresywna zaliczka PIT (12%/32%), kwota wolna 30 000 zł z kwotą zmniejszającą 300 zł/mc, ulga dla młodych (PIT-0 do 26 r.ż.), Polski Ład 2.0 (ulga dla rodzin 4+ oraz dla seniorów), PPK z możliwością rezygnacji co 4 lata, generacja ZUS DRA do 15 dnia i generacja PIT-11 do 31 stycznia.

Konkretny scenariusz w polskiej operacji: zakład przemysłowy z 800 pracownikami, 120 na zmiany z dodatkiem nocnym (art. 151⁸ KP) i 30 z sądowym zajęciem komorniczym. W grudniu dochodzi wypłata trzynastki i waloryzacja od listopada na podstawie aneksu UZP. Dział płac wykonuje 800 obliczeń indywidualnych, w tym 120 z dodatkiem nocnym oraz DSR, 30 z zastosowaniem tabeli zajęć i 800 wypłat trzynastki, a do tego generuje ZUS DRA oraz PIT-11 - wszystko w terminie ustawowym.

W [Decision Layer](/pl/decision-layer/) każdy z tych 16 etapów jest decyzją regułową (poziom R). Wynagrodzenie pochodzi z umowy o pracę, dodatki z UZP lub regulaminu, zajęcia komornicze z ordynacji sądowej, ZUS liczony jest wg tabeli 2026, PIT wg miesięcznej tabeli KAS, a PPK trafia do PFR przez Płatnik. Nie ma punktu, w którym analityk płac musiałby podjąć decyzję uznaniową - poza sytuacją, gdy agent sygnalizuje odchylenie powyżej 10% miesiąc do miesiąca do rewizji przez człowieka.

## Integracja z polskim ekosystemem: Comarch, Symfonia, enova, Płatnik

Logika agenta łączy się z systemami płac na polskim rynku przez API: [Comarch ERP Optima/XL](https://www.comarch.pl/erp/comarch-erp-optima/) (lider w MŚP), [Symfonia Kadry i Płace](https://www.symfonia.pl/) (mocna w średnich firmach), Sage Symfonia, [enova365](https://www.enova.pl/) (przemysł i handel) oraz Asseco Softlab ERP. Generacja deklaracji ZUS korzysta z systemu Płatnik (eksport XML) lub bezpośrednio z webserwisów PUE-ZUS, a deklaracje PIT-11 i PIT-4R trafiają do KAS przez eDeklaracje. Uzgodnienie księgowe eksportuje księgowania do ERP finansowego (Comarch, SAP, Oracle, IFS) z planem kont zgodnym z UoR lub MSR/MSSF. Dla polskich firm z matką w Niemczech (Volkswagen Poznań, Stellantis Tychy) lub innych krajach UE agent generuje równolegle raporty zgodne z IFRS na potrzeby konsolidacji w siedzibie - lista płac jest lokalnie zgodna z Kodeksem Pracy, a raportowanie macierzowe spełnia standardy międzynarodowe.

--- Agent korekt płac ---
> Korekty wsteczne płac: korekty ZUS DRA, korekta PIT-11, nadpłaty i niedopłaty składek i zaliczek - obliczanie wsteczne z dokumentacją podstawy prawnej dla kontroli ZUS i KAS.

Korekty wynagrodzeń kosztują niemieckie firmy nie z powodu samej różnicy - lecz z powodu nakładu na prawidłowe przeliczenie wsteczne. EY Global Payroll Survey 2022 dokumentuje: co piąty cykl payroll zawiera błędy, na każdy etat przypada 29 tygodni rocznie wyłącznie na korekty błędów. Przy 1 000 pracowników bezpośredni nakład korekcyjny szybko sumuje się do sześciocyfrowych kwot USD rocznie. Agent korekt wynagrodzeń przejmuje regułowe obliczenie łącznie ze skutkami podatkowymi i z zakresu ubezpieczeń społecznych. Zatwierdzenie pozostaje przy człowieku.

## Co piąte rozliczenie wynagrodzeń zawiera błąd

Przyczyny są różnorodne i często systemowe: wsteczne podwyżki taryfowe, zgłoszone z opóźnieniem nadgodziny, spóźnione rozliczenia delegacji, błędne zmiany klasy podatkowej. EY Global Payroll Survey dokumentuje, że co piąty cykl payroll jest błędny. Każdy pojedynczy błąd ciągnie za sobą łańcuch obliczeń następczych - różnica brutto, podatek od wynagrodzeń, dopłata solidarnościowa, podatek kościelny, ubezpieczenie zdrowotne, emerytalne, opiekuńcze i od bezrobocia.

Konkretny scenariusz: podwyżka taryfowa zostaje uzgodniona z mocą wsteczną od stycznia, informacja dociera do księgowości płac w kwietniu. Za trzy miesiące muszą być przeliczone wszystkie składniki wynagrodzenia - dla każdego dotkniętego pracownika indywidualnie, ponieważ klasa podatkowa, ulgi i obowiązek ZUS są różne. Przy 200 dotkniętych pracownikach powstaje 200 pojedynczych korekt po dziesięć kroków obliczeniowych każda.

## Ręczne przeliczenie wsteczne wiąże najdroższe zasoby

Prawdziwy problem to nie sama korekta. Arytmetyka jest jednoznaczna: nowe obliczenie minus stare obliczenie daje różnicę brutto. Skutki podatkowe i ZUS podążają za ustalonymi regułami z EStG i SGB. Co naprawdę obciąża firmy, to nakład czasu wykwalifikowanych specjalistów.

Księgowi płac ze specjalistyczną wiedzą podatkową i ubezpieczeniową spędzają godziny na obliczeniach, które zestaw reguł wykonuje w sekundy. Średni koszt bezpośredni na korektę to 281 USD (EY). Przy złożonych przypadkach jak niezaewidencjonowany okres chorobowy kwota rośnie do ponad 700 USD. Jednocześnie ci specjaliści nie są dostępni dla zadań faktycznie wymagających osądu - jak ocena spornych przypadków czy komunikacja z dotkniętymi pracownikami.

## Agent oblicza - człowiek decyduje

[Decision Layer](/pl/decision-layer/) rozkłada każdą korektę wynagrodzeniową na kroki decyzyjne i przyporządkowuje każdemu krokowi właściwego decydenta. Siedem z dziesięciu kroków jest regułowych: identyfikacja różnicy, okres wsteczny, obliczenie korekty, skutek podatkowy, korekta ZUS, różnica netto i zapis księgowy. Te podążają za przepisami obliczeniowymi z EStG i SGB - bez marginesu uznania, bez potrzeby interpretacji.

Dwa kroki wykorzystują wsparcie AI na poziomie 1: klasyfikacja przyczyny porządkuje kontekst - czy chodzi o zmianę taryfową, błąd wprowadzania czy dopłatę? Komunikacja z pracownikiem przygotowuje zrozumiałe wyjaśnienie korekty, aby dotknięty pracownik mógł zrozumieć, dlaczego zmienia się jego wynagrodzenie netto.

Dziesiąty krok pozostaje przy człowieku: zatwierdzenie w zasadzie czterech oczu. Żaden zapis korekty nie opuszcza systemu bez ludzkiej weryfikacji i potwierdzenia.

## Dokumentacja zgodna z GoBD (niemiecki standard dokumentacji) (niemiecki standard dokumentacji) powstaje automatycznie

Korekty wynagrodzeń to zdarzenia gospodarcze. Ustawa o rachunkowości (niemiecki standard GoBD) wymaga, by oryginalne rozliczenie pozostało niezmienione. Korekty odbywają się wyłącznie przez storno starego i utworzenie nowego rozliczenia. Agent generuje ten łańcuch dowodów automatycznie: oryginalne rozliczenie, dokument storna, skorygowane rozliczenie - bezlukowo powiązane i rewizyjnie udokumentowane.

Dla każdej korekty Decision Layer protokołuje pełny łańcuch decyzyjny: przyczyna z klasyfikacją, dotknięty okres, różnica brutto, różnica podatkowa, różnica ZUS, różnica netto, wynikowy zapis księgowy oraz moment zatwierdzenia z osobą zatwierdzającą. Przy kontroli podatkowej cała ścieżka obliczeniowa leży otwarta - nie jako wsteczna dokumentacja, lecz jako efekt uboczny samego procesu.

--- Agent deklaracji podatkowych ---
> Deklaracje podatkowe płac: PIT-4R miesięczna, PIT-11 roczna, ZUS DRA do 15 dnia, JPK_V7M - generacja i wysyłka deklaracji z dokumentacją podstawy prawnej dla KAS i ZUS.

Polskie składki ZUS pracownika i zaliczki PIT tworzą najbardziej złożony obszar polskiego rozliczenia kadrowo-płacowego, obwarowany wielowarstwową regulacją. Składają się na nią Ustawa o systemie ubezpieczeń społecznych z 13.10.1998 (art. 18-19 podstawa wymiaru i 30-krotność 234.720 zł w 2026 roku, art. 22 stawki składek, art. 24 odpowiedzialność płatnika z odsetkami 12,75% rocznie, art. 47 termin DRA do 15 dnia), Ustawa o PIT z 26.07.1991 (art. 32 zaliczki 12%/32% z kwotą wolną 30.000 zł, kwota zmniejszająca 300 zł/mc na PIT-2, art. 38 termin PIT-4 do 20 dnia, art. 39 PIT-11 do 31 stycznia), Ustawa o świadczeniach opieki zdrowotnej z 27.08.2004 (NFZ 9%), Ustawa o PPK z 4.10.2018 (2% pracownik i 1,5% pracodawca przez PFR, automatyczny zapis co 4 lata) oraz Polski Ład 2.0 (ulga dla młodych poniżej 26 r.ż. do 85.528 zł rocznego zwolnienia z PIT, ulga dla rodzin 4+, ulga dla seniorów, ulga na powrót z emigracji na 4 lata). Mimo deterministycznych reguł co drugi pracodawca w Polsce rozlicza co najmniej raz błędnie - powód leży w liczbie jednocześnie obowiązujących reguł (5 funduszy ZUS, NFZ, PPK oraz 4 ulgi Polskiego Ładu 2.0) i ich corocznych zmianach 1 stycznia. [Decision Layer](/pl/decision-layer/) odwzorowujący te reguły całkowicie eliminuje to źródło błędów.

## Błąd w deklaracji DRA przekazanej 15 dnia i PIT-11 złożony 31 stycznia z błędem ulgi - cena nieprawidłowych ZUS i PIT

Niewłaściwe rozliczenie kadrowo-płacowe generuje pasywo na czterech frontach. Pierwszy to KKS art. 56 (narażenie zaliczek PIT na uszczuplenie) - kara grzywny do 720 stawek dziennych, czyli przy stawce maksymalnej 30.000 zł aż 21,6 mln zł, oraz pozbawienie wolności do 5 lat. Dochodzą do tego art. 80 (nieprzekazanie zaliczek do US do 20 dnia), art. 60 (nieprowadzenie ewidencji PIT-4R/PIT-8AR) do 7,2 mln zł i art. 61 (wadliwa PIT-11) do 3,6 mln zł. Łączne ryzyko karne PIT przekracza 36 mln zł.

Drugi front to Ustawa o systemie ubezpieczeń społecznych art. 24 - odpowiedzialność majątkowa płatnika za niepobrane składki ZUS wraz z odsetkami za zwłokę 12,75% rocznie. Dla firmy z 800 pracownikami i sumą składek miesięcznych 8 mln zł jednomiesięczne opóźnienie generuje 85.000 zł odsetek, a błędna klasyfikacja umowy o dzieło zamiast umowy o pracę na 2 lata przed kontrolą ZUS oznacza 1,5 mln zł dopłaty składek, 380.000 zł odsetek i sankcje art. 24.

Trzeci front to PIP do 30.000 zł za naruszenie art. 87 KP (błędne potrącenia z wynagrodzenia - brak hierarchii między alimentami, komornikami, związkami i innymi tytułami) lub art. 92 (chorobowe). Dochodzi do tego Ustawa o PPK art. 100 - PIP do 1,5% funduszu wynagrodzeń za niewykonanie obowiązku PPK; dla firmy z 50 mln zł funduszu wynagrodzeń ryzyko sięga 750.000 zł. Czwarty front to RODO art. 83 - UODO do 4% obrotu rocznego za naruszenie danych pracowników (PESEL, dane szczególnej kategorii z art. 9 - niepełnosprawność, choroby przewlekłe); precedensem jest sprawa 'Morele.net' z 2019 z karą 2,8 mln zł.

Realny przykład: spółka informatyczna w Krakowie z 600 pracownikami (400 programistów z IP-Box, 200 ze wsparcia). ZUS wykrywa błędne stosowanie 30-krotności dla 30 menedżerów - dopłaty za 4 miesiące 720.000 zł, odsetki 91.000 zł i sankcje art. 24. KAS wykrywa błędne stosowanie ulgi dla młodych poniżej 26 r.ż. dla 80 programistów - dopłaty PIT 380.000 zł i KKS art. 56 do 5 mln zł. Dochodzi do tego PIP za błędne potrącenia komornicze dla 12 pracowników - 360.000 zł mandatów.

## Polski pipeline ZUS i PIT pracowników przechodzi 14 deterministycznych etapów - więcej niż niemiecki ELStAM (8) z powodu Polskiego Ładu 2.0, PPK i 30-krotności

Polski system kadrowo-płacowy należy do najbardziej rozbudowanych w UE: Ustawa o systemie ubezpieczeń 1998, Ustawa o PIT 1991, Ustawa o NFZ 2004, Ustawa o PPK 2018 oraz Polski Ład 2.0 (Ustawa z 16.10.2024). Strukturę instytucjonalną tworzą ZUS, KAS, US, NFZ, PFR (PPK), PIP, MS (komornicy), UODO (RODO), WSA/NSA oraz Sąd Rejonowy.

14 deterministycznych etapów pipeline to: (1) walidacja PIT-2 z kwotą zmniejszającą 300 zł/mc, (2) ulga dla młodych poniżej 26 r.ż. z PESEL, (3) ulgi dla rodzin 4+, seniorów i powracających, (4) podstawa wymiaru ZUS z wyłączeniami ZFSS, odpraw i BHP, (5) 30-krotność 234.720 zł w 2026 roku, (6) składki ZUS pracownika 13,71%, (7) składki ZUS pracodawcy 19,48-22,14% (z FP i FGSP), (8) NFZ 9% po odliczeniu ZUS, (9) PPK 2%/1,5% przez PFR, (10) zaliczka PIT 12%/32% z kwotą wolną 30.000 zł, (11) korekta PIT przy ulgach Polskiego Ładu 2.0, (12) DRA/RCA/RZA do 15 dnia przez Płatnik, (13) przelew PIT do 20 dnia i ZUS do 15 dnia, (14) PIT-11/PIT-4R/PIT-8AR do 31 stycznia przez e-Deklaracje.

Scenariusz: spółka chemiczna w Płocku z 800 pracownikami w 4 PKD o sumie wynagrodzeń 14 mln zł miesięcznie. 14 dnia agent waliduje 800 oświadczeń PIT-2 (780 OK, 20 anulowanych przy zmianie pracodawcy). Waliduje ulgi Polskiego Ładu 2.0: 120 młodych poniżej 26 r.ż. z PESEL, 8 rodzin 4+, 5 seniorów, 3 powracających. Śledzi 30-krotność dla 35 menedżerów - 12 osiągnie limit w sierpniu, 23 we wrześniu. Generuje DRA z 5 funduszami oraz 800 RCA i 12 RZA, a następnie wysyła je przez Płatnik do 15 dnia z podpisem kwalifikowanym. Po 25 dniu oblicza zaliczki PIT 12%/32% z uwzględnieniem 120 młodych, kwoty wolnej 30.000 zł i kwoty zmniejszającej 300 zł/mc, po czym przelewa PIT do US do 20 dnia. 31 stycznia 2027 wysyła 800 PIT-11 oraz PIT-4R.

W [Decision Layer](/pl/decision-layer/) wszystkie 14 etapów to decyzje regułowe (R) - czyste stosowanie Ustawy o systemie ubezpieczeń, Ustawy o PIT i Polskiego Ładu 2.0 bez generative AI w decyzjach o stawce składek lub progach PIT. Decyduje zestaw reguł, a nie model.

## Kontrola wiarygodności przed wysyłką DRA i PIT-11: walidacja podstawy wymiaru, krzyżowa kontrola Płatnika ZUS z e-Deklaracjami PIT, spójność oświadczeń PIT-2

Trzy etapy walidacyjne wykonywane przed wysyłką - każdy może zatrzymać proces. (1) Walidacja podstawy wymiaru ZUS: sprawdzenie zgodności z listą włączeń z Rozporządzenia MPiPS z 18.12.1998 (wynagrodzenie zasadnicze, premie regulaminowe, dodatki funkcyjne) oraz z wyłączeniami (ZFSS, odprawy emerytalne do limitów, ekwiwalent za pranie, świadczenia BHP, podróże służbowe). Śledzona jest kumulatywna podstawa z roku narastająco wobec 30-krotności 234.720 zł w 2026 roku. Brak walidacji grozi przekroczeniem limitu i nadpłatą składek emerytalnej i rentowej. (2) Krzyżowa kontrola Płatnika ZUS z e-Deklaracjami PIT: suma podstaw wymiaru ZUS z RCA na pracownika za rok powinna odpowiadać sumie przychodów z PIT-11 powiększonej o zwolnienia Polskiego Ładu 2.0 (młodzi do 85.528 zł, rodziny 4+ do 85.528 zł, seniorzy do 85.528 zł, powracający do 85.528 zł przez 4 lata). Rozbieżność generuje raport dla KAS - sygnał o nierzetelności ksiąg prowadzący do sankcji KKS art. 56. (3) Spójność oświadczeń PIT-2 i PIT-2A: pracownik może złożyć PIT-2 tylko u jednego płatnika, a PIT-2A wyklucza stosowanie kwoty zmniejszającej u tego pracodawcy. Krzyżowa weryfikacja PIT-11 z PIT-4R od wszystkich pracodawców pracownika - wykrycie wielokrotnego stosowania kwoty zmniejszającej generuje dopłatę w PIT rocznym (PIT-37) z odsetkami 12,75% rocznie.

## Przypadki szczególne w Polsce: 30-krotność 234.720 zł, umowa o dzieło, zlecenie i o pracę, Polski Ład 2.0, automatyczny zapis PPK, IP-Box dla programistów

30-krotność 234.720 zł w 2026 roku (art. 19 Ustawy o systemie ubezpieczeń) to roczne ograniczenie podstawy składek emerytalnej i rentowej; po jej przekroczeniu kumulatywnym z roku narastająco składki pracownika 11,26% (emerytalna i rentowa) oraz pracodawcy 16,26% (emerytalna i rentowa) zatrzymują się do końca roku. Nadpłatę z opóźnionego zatrzymania (np. błąd systemu) odzyskuje się czynnym żalem (Ordynacja podatkowa art. 81) w 30 dni roboczych.

Klasyfikacja umowy: umowa o pracę (art. 22 KP) z pełnymi składkami i ochroną Kodeksu Pracy, umowa zlecenia (Kodeks Cywilny art. 734) z obowiązkowym ZUS (emerytalna, rentowa, wypadkowa, FP, NFZ), lecz dobrowolną chorobową, oraz umowa o dzieło (Kodeks Cywilny art. 627) bez ZUS pracownika. Orzecznictwo NSA (II FSK 1456/22, II UKN 234/23) precyzuje kryteria reklasyfikacji: podporządkowanie wykonawcy, regularność wynagrodzenia, ciągłość dzieł, brak ryzyka rezultatu. Błędna klasyfikacja generuje dopłaty ZUS i PIT, odsetki oraz sankcje art. 24 i art. 56 KKS.

Polski Ład 2.0 wprowadza 4 ulgi pracownicze: (a) ulga dla młodych poniżej 26 r.ż. do 85.528 zł rocznego zwolnienia z PIT (na podstawie PESEL), (b) ulga dla rodzin 4+ z czworgiem i więcej dzieci do 18 r.ż. lub 25 w nauce, (c) ulga dla seniorów po wieku emerytalnym (60 lat kobiety, 65 mężczyźni) nadal pracujących, (d) ulga na powrót z emigracji - 4 lata zwolnienia po ponad 3 latach poza Polską. Ulgi dotyczą tylko PIT, nie ZUS ani NFZ.

PPK (Pracownicze Plany Kapitałowe) z automatycznym zapisem co 4 lata - pracownik może zrezygnować, ale pracodawca musi go ponownie włączyć co 4 lata z możliwością ponownej rezygnacji. Składki to 2% od pracownika, 1,5% od pracodawcy oraz 240 zł rocznie z budżetu, przelewane do PKO TFI, NN Investment lub Aviva przez PFR do 15 dnia. Za niewykonanie grozi sankcja PIP do 1,5% funduszu wynagrodzeń.

IP-Box dla programistów (art. 30ca Ustawy o PIT) to 5% PIT od kwalifikowanego dochodu z praw IP wytworzonych przy pracy nad oprogramowaniem, patentami i wzorami użytkowymi; wymaga prowadzenia ewidencji księgowej zgodnej z Rozporządzeniem MF z 23.11.2019. SAP S/4HANA, Comarch ERP XL i enova365 obsługują IP-Box dla zespołów inżynieryjnych Volkswagen Poznań, BMW Wrocław i LG Wrocław.

## Integracja z polskim ekosystemem: Comarch, Symfonia, enova, Płatnik ZUS, e-Deklaracje MF, NFZ, PFR PPK, RCA krzyżowo z PIT-11

Agent łączy się z głównymi ERPami polskiego rynku kadrowo-płacowego: [Comarch ERP Optima Moduł Kadry i Płace](https://www.comarch.pl/erp/comarch-erp-optima/) (lider MŚP, walidacja 30-krotności 234.720 zł w 2026 roku, generacja DRA/RCA/RZA przez Płatnik, PIT-11 do 31 stycznia), Comarch ERP XL Kadry i Płace z Modułem Polski Ład 2.0 (Enterprise, wielofirmowy, wielo-PKD z różnymi stawkami wypadkowymi), [Symfonia Kadry i Płace z Symfonia Płatnik](https://www.symfonia.pl/), [enova365 Kadry Płace z Modułem ZUS i PIT](https://www.enova.pl/) (wielowalutowa dla ekspatów), InsERT Subiekt nexo Pro z Modułem Kadry, SAP S/4HANA Polish Localization HCM (Volkswagen Poznań, BMW Wrocław, Stellantis Tychy, Bosch Mirków, Mercedes Jawor, LG Wrocław - ponad 5000 pracowników z konsolidacją PIT-4R, IP-Box dla programistów, ulgi R&D), Asseco Softlab HR z Asseco Payroll (farmacja i FMCG), WAPRO Kadry i Płace, Asseco WAPRO ERP Kadry i Płace, ifirma.pl oraz Mastermaq Domínio Polska.

Integracja podatkowo-ubezpieczeniowa obejmuje API systemu Płatnik ZUS z certyfikatem (CenCert, Szafir, EuroCert) dla DRA/RCA/RZA do 15 dnia, bramkę MF e-Deklaracje (PIT-4R, PIT-8AR, PIT-11 do 31 stycznia z podpisem kwalifikowanym), API NFZ dla weryfikacji oddziału wojewódzkiego, API PFR dla składek PPK 2%/1,5% z monitoringiem rezygnacji co 4 lata oraz API komorników sądowych dla potrąceń z wynagrodzenia (art. 87 KP - hierarchia alimentów, komorników, związków i innych tytułów ograniczona do 50% wynagrodzenia minimalnego). Audit trail jest kompatybilny z kontrolą ZUS (krzyżowo z PIT-11 i PIT-4R), KAS (audyt PIT-4R/PIT-8AR), US (zaliczki PIT do 20 dnia), NFZ (składka zdrowotna 9%), PFR (PPK), PIP (potrącenia art. 87 KP), GIIF (AML), UODO (RODO), biegłym rewidentem PIBR (KSRF 250/320), WSA/NSA oraz Sądem Rejonowym w sprawach KKS. Decision Logging i Audit Trail są kompletne dla obrony przed sankcją KKS art. 56 (do 21,6 mln zł), Ustawą o systemie ubezpieczeń art. 24 (odsetki za zwłokę 12,75% rocznie) oraz PIP do 30.000 zł za naruszenie.

--- Agent kasy podręcznej ---
> Rejestruje paragony kasowe przez ekstrakcję AI, sprawdza faktury drobne wg Paragraph 33 UStDV.

Kasa podręczna kosztuje firmy przy kontrolach podatkowych nieproporcjonalnie dużo - nie dlatego, że kwoty są wysokie, lecz dlatego, że wady prowadzenia kasy mogą zdyskwalifikować całą księgowość. Gdy kontroler znajdzie luki w codziennej ewidencji, może doszacować. W 2024 roku kontrole podatkowe krajów związkowych przyniosły według Ministerstwa Finansów około 10,9 miliarda EUR dodatkowego wyniku. Prowadzenie kasy należy do pierwszych punktów kontroli, ponieważ jest najczęściej podatne na zarzuty.

## Prowadzenie kasy decyduje o wyniku kontroli podatkowej

Urząd skarbowy kontroluje operacje gotówkowe ściślej niż bezgotówkowe. Podstawa prawna jest jednoznaczna: Ordynacja podatkowa Art. 146 wymaga codziennej ewidencji wszystkich operacji kasowych, Ustawa o rachunkowości (niemiecki standard GoBD (niemiecki standard dokumentacji)) wymaga niezmienialności i bezlukowej dokumentacji, a od 2020 obowiązuje wymóg TSE (technicznego zabezpieczenia). Od stycznia 2025 elektroniczne systemy kasowe i ich TSE muszą być aktywnie zgłoszone do urzędu skarbowego. Naruszenia obowiązku TSE mogą skutkować grzywnami do 25 000 EUR.

Problem nie leży w złożoności reguł. Leży w tym, że między wpływem paragonu a wpisem do księgi kasowej upływa zbyt dużo czasu. Kto uzupełnia paragony kasowe w piątkowe popołudnie za cały tydzień, narusza codzienny obowiązek ewidencji - i daje kontrolerowi dźwignię do doszacowań.

## Codzienna ewidencja zawodzi w codziennej rzeczywistości

W praktyce przebieg rzadko wygląda tak, jak przewiduje GoBD. Kierowniczka biura kupuje rano kartridże do drukarki za 47 EUR (ok. 51 USD), kolega płaci w południe za obiad z klientem 189 EUR, po południu dochodzi rachunek za taksówkę za 23 EUR. Trzy paragony, trzy różne osoby, trzy różne dekretacje. Ręczny wpis do księgi kasowej następuje - jeśli w ogóle - na koniec dnia z pamięci.

Wynik zna każdy CFO, który przeżył już kontrolę podatkową: paragony bez daty w księdze kasowej, błędne sumy pośrednie, brakujące zamknięcia dzienne. Przy fakturach drobnych do 250 EUR brutto dochodzi dodatkowe ryzyko. Uproszczone dane obowiązkowe pozwalają wprawdzie na rezygnację z podania odbiorcy - ale gdy odbiorca jest podany i dane są błędne, może to zagrozić odliczeniu VAT naliczonego. Tę subtelność pracownicy regularnie przeoczają.

## Siedem kroków decyzyjnych oddziela rutynę od osądu

[Decision Layer](/pl/decision-layer/) rozkłada proces kasowy na dokładnie te kroki, które odróżniają prawidłową od zakwestionowanej księgi kasowej. Z siedmiu kroków decyzyjnych tylko jeden jest wspierany przez AI: rejestracja paragonów, przy której LLM ekstrahuje relevantne dane z nieustrukturyzowanych paragonów kasowych - zdjęcia kwitów, odręczne notatki, wyblakłe wydruki termiczne.

Kolejnych pięć kroków jest w pełni regułowych. Weryfikacja progu 250 EUR, kontrola danych obowiązkowych, dekretacja według rodzaju i kwoty, wpis do księgi kasowej ze znacznikiem czasu zgodnym z GoBD i numeryczne porównanie stanu księgowego z rzeczywistym - wszystko podąża za deterministycznymi regułami bez marginesu uznania.

Siódmy krok pozostaje przy człowieku: gdy stan kasy odbiega od stanu księgowego, człowiek musi wyjaśnić przyczynę. Żaden algorytm nie może zdecydować, czy różnica 14,50 EUR wynika z zapomnianego paragonu, błędu w liczeniu czy czegoś poważniejszego. Ta granica jest świadomie wyznaczona.

## Regułowa kontrola zamyka lukę między paragonem a księgą kasową

Wyobraźmy sobie poniedziałkowy poranek w oddziale z własną kasą podręczną. Kierowniczka biura fotografuje paragon za tankowanie z weekendu - 62 EUR. W ciągu sekund agent ekstrahuje kwotę, datę i stawkę podatkową, rozpoznaje paragon jako fakturę drobną, sprawdza uproszczone dane obowiązkowe, dekretuje na właściwe konto i wpisuje operację ze znacznikiem czasu do księgi kasowej. Przed obiadem dzienne zamknięcie pokazuje: stan księgowy 843,50 EUR, stan policzony 843,50 EUR, brak różnicy.

Gdy w środę stan rzeczywisty leży 12 EUR poniżej stanu księgowego, agent dokumentuje odchylenie i eskaluje do odpowiedzialnego za kasę. Nie do algorytmu. Wyjaśnienie przyczyn różnic kasowych to decyzja poziomu 1 - wymaga ludzkiego osądu, ponieważ możliwe przyczyny są zbyt różnorodne, by ujać je w reguły.

Rezultat dla następnej kontroli podatkowej: każda operacja kasowa jest zarejestrowana w dniu zdarzenia, powiązana z paragonem i dokumentowana chronologicznie. Dokumentacja procedur, której żąda urząd skarbowy, nie powstaje wstecznie dla kontrolera - powstaje jako efekt uboczny codziennego procesu.

--- Agent kontroli jakości zapisów ---
> Sprawdza każdy zapis pod kątem formalnej kompletności, wiarygodności, spójności kont i prawidłowości kodu podatkowego.

## Jedna trzecia księgowych zgłasza kilka błędów tygodniowo

Badanie Gartner z 2024 roku pokazuje: 33 procent ankietowanych księgowych przyznaje, że tygodniowo popełnia kilka błędów księgowych. Głównym powodem nie jest brak staranności, lecz wąskie gardła pojemnościowe. Rosnące wymogi regulacyjne i zmienne warunki biznesowe zwiększają wolumen księgowań, podczas gdy wielkości zespołów stagnują.

Wyobraźmy sobie dział finansowy z 4 000 zapisów dziennie. Przy wskaźniku błędów od trzech do pięciu procent - typowej wartości ręcznych procesów wprowadzania - powstaje dziennie od 120 do 200 błędnych wpisów. Nie każdy z nich jest istotny. Ale każdy może stać się zapisem korygującym przy zamknięciu miesiąca, jeśli nikt go wcześniej nie rozpozna.

## Błędy w księdze głównej kosztują przy zamknięciu wielokrotność prewencji

Błędny kod podatkowy na fakturze przychodzącej to przy wprowadzaniu kwestia sekund. Gdy ten sam zapis dotrze do księgi głównej, zaczyna się kaskada: różnica uzgodnieniowa przy weryfikacji VAT, zapytanie do pracownika, poszukiwanie dowodu, storno, ponowne zaksięgowanie, ponowne zatwierdzenie. Z sekundy korekty robi się 15 do 30 minut nakładu pracy.

Pomnożone przez setki zapisów korygujących na zamknięcie miesiąca, przesuwa się całe okno closingowe. Controllerzy czekają na oczyszczone salda. Biegli rewidenci kwestionują powtarzające się wzorce. A kierownictwo finansowe traci zaufanie do liczb, które tygodniowo raportuje zarządowi.

Dźwignia ekonomiczna leży zatem nie w przyspieszeniu zamknięcia, lecz w jakości pojedynczego zapisu. Co czysto wchodzi do księgi głównej, nie musi być korygowane.

## Osiem kroków kontrolnych zastępuje ręczną próbę

[Decision Layer](/pl/decision-layer/) rozkłada kontrolę jakości zapisów na osiem dyskretnych decyzji. Sześć z nich jest w pełni regułowych: formalna kompletność (dokument, konto, kwota, data obecne?), spójność kont (Dt i Ma kompatybilne?), spójność kodu podatkowego (kod VAT pasuje do konta?), prawidłowość okresu (data dokumentu i okres księgowy się zgadzają?), rozpoznawanie duplikatów (kwota, konto i data już zarejestrowane?) oraz końcowy routing.

Dwa pozostałe kroki wykorzystują wzorce historyczne: weryfikacja wiarygodności porównuje każdą kwotę z typowymi przedziałami danej grupy kont. Wskaźnik anomalii agreguje wszystkie pojedyncze weryfikacje do oceny ogólnej i priorytetyzuje eskalację.

Decydująca jest kolejność. Weryfikacje regułowe biegną w milisekundach. Tylko zapisy przechodzące wszystkie formalne kontrole docierają do bardziej złożonej analizy wzorców. W praktyce oznacza to: ponad 95 procent wszystkich zapisów przechodzi kompletny łańcuch kontrolny bez ludzkiej ingerencji.

## Przypadek normalny przebiega bez eskalacji

Przy dobrze utrzymanych danych podstawowych od dwóch do pięciu procent zapisów jest eskalowanych. Wskaźnik anomalii determinuje kolejność - najbardziej podejrzane wpisy pojawiają się jako pierwsze na ekranie pracownika. Zamiast dziennie sprawdzać wyrywkowo 4 000 zapisów, zespół koncentruje się na 80 do 200 spriorytetyzowanych przypadkach.

Każda eskalacja okazująca się nieszkodliwą poprawia model. Progi wiarygodności kalibrują się przez feedback: średnia plus odchylenia standardowe na grupę kont jako baza wyjściowa, doskonalone przez codzienną praktykę. Po trzech do sześciu miesiącach wskaźnik fałszywych alarmów mierzalnie spada.

Dla kontroli podatkowej Decision Layer dokumentuje każdą decyzję: jakie kontrole przeprowadzono, które zdały, które nie, jaki był wskaźnik anomalii i czy zapis został automatycznie zatwierdzony czy eskalowany. IKS staje się tym samym nie tylko skuteczniejszy, lecz także dowiedziony - wobec biegłych rewidentów, nadzoru i zarządu.

## Jakość zapisów determinuje szybkość zamknięcia

Firmy systematyzujące kontrolę jakości zapisów raportują zgodnie o krótszych cyklach closingowych i mniejszej liczbie zapisów korygujących w zamknięciu miesiąca. EY szacuje, że ponad 70 procent wszystkich zapisów dziennikowych jest automatyzowalnych. Pytanie brzmi nie czy kontrola jakości zostanie zautomatyzowana, lecz jak transparentna pozostanie przy tym logika decyzyjna.

Agent kontroli jakości operuje na Decision Layer poziom 1 do 2: zestaw reguł dla formalnych kontroli, wsparcie AI dla wiarygodności i rozpoznawania anomalii, decyzja ludzka tylko przy eskalowanych anomaliach. Żaden błąd księgowy nie pozostaje niewidoczny, żaden krok kontrolny nieudokumentowany - a zamknięcie miesiąca zaczyna się z saldami, na których kierownictwo finansowe może polegać.

--- Agent dokumentacji procedur ---
> Rozpoznaje zmiany procesów automatycznie, sprawdza aktualność dokumentacji, generuje projekty aktualizacji i zapewnia kompletność zgodną z wymogami księgowymi.

Dokumentacje procedur istnieją w większości firm. Aktualne są rzadko. Dokładnie ta luka między stanem dokumentacji a rzeczywistością procesową staje się przy kontrolach podatkowych problemem - bo kontroler nie pyta, czy dokumentacja istnieje, lecz czy odzwierciedla faktyczny stan.

## Kontrolerzy żądają dokumentacji jako pierwszego

W 2023 roku kontrolerzy w Niemczech przy 146 516 skontrolowanych firmach ustalili dodatkowe wyniki w wysokości 13,2 miliarda EUR (BMF-Monatsbericht październik 2024). Na początku kontroli kontrolerzy coraz częściej żądają dokumentacji procedur, zanim przystąpią do weryfikacji merytorycznej. Powód jest pragmatyczny: nieaktualna lub lukowa dokumentacja sygnalizuje brak kontroli procesowych - i uzasadnia pogłębione czynności kontrolne.

Konsekwencja prawna jest jasno uregulowana. Gdy brakująca lub niewystarczająca dokumentacja procedur narusza odtwarzalność i sprawdzalność księgowości, zachodzi wada formalna o wadze merytorycznej. Kontroler może wówczas odrzucić księgowość i doszacować podstawy opodatkowania. W praktyce oznacza to: wada dokumentacyjna staje się ryzykiem finansowym, zanim w ogóle znaleziony zostanie błąd merytoryczny.

## Każda zmiana procesu tworzy lukę dokumentacyjną

Prawdziwy problem to nie pierwsze stworzenie. Większość działów Finance kiedyś zbudowała dokumentację procedur - często w ramach projektu, często z zewnętrznym doradztwem. Problem zaczyna się dzień po jej ukończeniu.

Nowy moduł ERP wchodzi na produkcję. Workflow zatwierdzania zostaje dostosowany. Kolejny agent przejmuje zadanie kontrolne. Każda z tych zmian powinna być odzwierciedlona w dokumentacji procedur - w opisie ogólnym, technicznej dokumentacji systemowej, koncepcji autoryzacji i opisie IKS. W praktyce nie dzieje się to na czas, ponieważ nikt nie ma triggera. Zmiana wchodzi na produkcję, dokumentacja stoi. Przez miesiące i lata narasta przepaść między tym, co jest udokumentowane, a tym, co rzeczywiście się dzieje.

## Automatyczny monitoring zamyka lukę w czasie rzeczywistym

Agent dokumentacji procedur monitoruje ciągle konfiguracje systemów istotnych podatkowo. Gdy zmienia się proces - nowa reguła, nowy agent, zmienione uprawnienie - rozpoznaje rozbieżność między udokumentowanym stanem docelowym a rzeczywistością. Sprawdza istniejącą dokumentację względem listy kontrolnej GoBD (niemiecki standard dokumentacji) (niemiecki standard dokumentacji) według sekcji 10, identyfikuje dotknięte rozdziały i generuje projekt aktualizacji.

Logika decyzyjna rozdziela czysto według złożoności. Czy coś się zmieniło - to agent rozpoznaje samodzielnie. Czy dokumentacja zgadza się jeszcze z rzeczywistością - sprawdza automatycznie. Jakie wymogi GoBD obowiązują i jak dokumentować uprawnienia - podąża za ustalonymi regułami. Ale czy dokumentacja ogółem jest kompletna i czy projekt jest zatwierdzany - to decyduje człowiek. Agent dostarcza projekt, nie podpis.

## Dokumentacja dokumentuje samą siebie

Agent dokumentacji procedur ma szczególną właściwość w ramach [Decision Layer](/pl/decision-layer/): jest jednocześnie narzędziem i przedmiotem dokumentacji. Każda zmiana, którą rozpoznaje i dokumentuje, jest protokołowana ze znacznikiem czasu, rodzajem zmiany i statusem obróbki. Powstaje tym samym bezlukowy protokół zmian - nie jako odrębny wymóg, lecz jako efekt uboczny normalnej eksploatacji.

Dla kontroli podatkowej oznacza to konkretnie: dokumentacja procedur jest nie tylko aktualna, lecz jej aktualność jest dowodliwa. Kontroler widzi nie tylko dzisiejszy stan, lecz całą historię zmian - kiedy jaki proces został dostosowany, kiedy dokumentacja została uzupełniona, kto zatwierdził. Najczęstszy punkt zarzutów traci tym samym swoją podstawę.

--- Agent rezerw ---
> Identyfikuje rodzaje rezerw, oblicza rezerwy urlopowe i tantiemowe deterministycznie.

Rezerwy to stały temat każdego badania sprawozdania finansowego, ponieważ utworzenie i wycena opierają się na założeniach i szacunkach. Agent rezerw czysto oddziela to, co da się obliczyć, od tego, co wymaga ludzkiego uznania - i czyni obie części odpornymi na kontrolę.

## Rezerwy to stały temat każdego badania sprawozdania

Żadna inna pozycja bilansowa nie znajduje się tak regularnie w centrum uwagi badania sprawozdania i kontroli podatkowej. IDW opisuje rezerwy wprost jako stały temat sezonu badań, ponieważ zarówno utworzenie, jak i wycena opierają się na założeniach kierownictwa. BaFin ponownie podniosło w krajowym priorytecie badań na 2025 rok wartość aktywów i powiązane kwestie wycenowe.

Powód ma charakter strukturalny. Rezerwa urlopowa podąża za jasną formułą. Rezerwa na koszty procesowe zależy od prawdopodobieństwa sukcesu prawnego. Rezerwa gwarancyjna bazuje na wartościach doświadczalnych ostatnich lat. Trzy rezerwy, trzy zupełnie różne logiki powstawania - a w wielu działach finansowych mimo to lądują w tym samym szablonie Excel, który co roku jest ręcznie kontynuowany. Biegły rewident widzi na końcu wynik, ale nie to, jaka część była obliczeniem, a jaka uznaniem.

## Urlop i tantiemy dają się w pełni deterministycznie tworzyć

[Decision Layer](/pl/decision-layer/) rozkłada tworzenie rezerw na osiem kroków. Trzy z nich to czyste reguły obliczeniowe niewymagające szacunków. Rezerwa urlopowa wynika z otwartych dni urlopowych pomnożonych przez średnią stawkę dzienną z wynagrodzenia brutto i udziału pracodawcy w ZUS. Rezerwa tantiemowa podąża za podstawą umowną i aktualną prognozą wyników. Zapis księgowy wyprowadza się deterministycznie z rodzaju rezerwy.

Przy średniej wielkości firmie przemysłowej z 800 pracownikami, która dotychczas obliczała rezerwę urlopową w trzech dniach roboczych w styczniu z ewidencji czasu HR do Excela, agent przejmuje ten przebieg miesięcznie. Dane pochodzą bezpośrednio z systemu ERP i danych kadrowych. Wynik nie jest szacunkiem, lecz odtwarzalnym obliczeniem na pracownika. Dla biegłego rewidenta nie stoi już pytanie, czy kwota jest wiarygodna, lecz tylko czy podstawy obliczeniowe się zgadzają. To skraca czynność kontrolną z prób z zapytaniami do czystej weryfikacji metody.

## Gwarancja i koszty procesowe pozostają decyzją ludzką

Dwa kroki piramidy są świadomie nieautomatyzowane. Rezerwy gwarancyjne bazują na wartościach doświadczalnych i specyficznym dla firmy uznaniu, którego żaden zestaw reguł nie odwzoruje w pełni. Rezerwy na koszty procesowe zależą od prawnej oceny prawdopodobieństwa sukcesu wymagającej fachowej wyceny przez radcę prawnego lub kancelarię.

Tu agent dostarcza nie wynik, lecz podstawę decyzyjną. Dla gwarancji agreguje dane reklamacyjne i gwarancyjne z ostatnich trzech lat, oblicza wskaźniki na grupę produktową i udostępnia bazę do szacunku. Dla kosztów procesowych pobiera wartość sporu, dotychczasowe koszty postępowania i instancję z działu prawnego i przekazuje formularz do ludzkiej decyzji. Ostateczna stawka i ostateczna kwota rezerwy pozostają przy człowieku, ale są podejmowane na podstawie ustrukturyzowanego zbioru danych, nie z pamięci.

## Decision Layer dokumentuje każdą wycenę odpornie na kontrolę

Decydujące dla współpracy z biegłym rewidentem jest nie to, czy rezerwa została obliczona czy oszacowana. Decydujące jest, czy podstawa jest udokumentowana. Agent rezerw rejestruje na rezerwę: rodzaj, metodę obliczeniową, dane wejściowe, wynik, oznaczenie deterministyczna lub uznaniowa, porównanie z rokiem poprzednim i uzasadnienie każdego odchylenia. Na koniec roku powstaje z tego zestawienie rezerw stanowiące załącznik do sprawozdania finansowego.

Noty do załącznika są przygotowywane jako projekt LLM. To nie znaczy, że bilansista je przejmuje. Sprawdza, czy sformułowanie pasuje do wyceny, i zatwierdza. Dla zespołów finansowych, które w sezonie sprawozdawczym potrzebują każdej godziny podwójnie, praca przesuwa się od pisania do sprawdzania - i przede wszystkim z dala od powtarzającego się pytania biegłego rewidenta, jak powstała dana liczba.

--- Agent zapotrzebowań zakupowych ---
> Rozpoznaje potrzeby zakupowe z danych zużycia, sprawdza budżety centrów kosztów, proponuje preferowanych dostawców.

Zapotrzebowanie zakupowe to najdroższa decyzja w całym procesie Purchase-to-Pay - nie z powodu swojej własnej wartości, lecz dlatego, że ustala, czy wynegocjowane warunki w ogóle zaczną obowiązywać. Kto tu wybierze złego dostawcę, zamówi z pominięciem umowy ramowej lub przeoczy granice budżetowe, niszczy oszczędności zanim pierwsza faktura trafi do systemu. Agent zapotrzebowań zakupowych zakotwicza umowy ramowe, kontrolę budżetową i matrycę zatwierdzeń bezpośrednio w procesie zamówienia - i oddaje uznanie ludzkie tylko tam, gdzie robi to różnicę: powyżej progu kwotowego.

## Maverick Buying kosztuje organizacje finansowe do 16 procent wynegocjowanych oszczędności

Dane są jednoznaczne: według APQC organizacje z wysokim udziałem Maverick Buying potrzebują w medianie 16 godzin więcej, aby wyzwolić zamówienie, i tracą między wynegocjowaną strukturą warunków a faktycznym zakupem do 16 procent oszczędności. Hackett Group określa w Digital World Class Benchmark 2025, że najlepsi wykonawcy przez konsekwentne wiązanie umowne tracą 60 procent mniej oszczędności niż średnia. Dźwignia leży nie w zakupach, lecz w momencie zapotrzebowania. Kto tu decyduje, decyduje o marży.

W rzeczywistości średnich organizacji finansowych setki zapotrzebowań dziennie przechodzą przez działy, które ani nie mają umów ramowych w głowie, ani nie znają resztek budżetowych na centrach kosztów. Następstwem są zamówienia u złego dostawcy, odwołania bez odniesienia do umowy ramowej, przekroczenia rozpoznawane dopiero w zamknięciu miesiąca.

## [Decision Layer](/pl/decision-layer/) rozkłada zapotrzebowanie na siedem zrozumiałych kroków

Agent zapotrzebowań zakupowych oddziela siedem decyzji w każdym zapotrzebowaniu czysto według odpowiedzialności. Rozpoznawanie potrzeb z danych zużycia biegnie jako prognoza wspierana ML. Kontrola budżetu, propozycja dostawcy, warunki umowy ramowej, workflow zatwierdzania i generowanie zamówienia są w pełni regułowe - porównania numeryczne i logika danych podstawowych, żadnego marginesu uznania.

Konkretnie: dział merytoryczny wyzwala potrzebę na 8 400 EUR (ok. 9 100 USD) za materiały serwisowe. Agent sprawdza w poniżej sekundy, czy na centrum kosztów jest wystarczająca reszta budżetu, identyfikuje preferowanego dostawcę z danych podstawowych, pobiera warunki umowy ramowej (cenę, ilość minimalną, czas dostawy), oblicza przez matrycę zatwierdzeń właściwego zatwierdzającego i generuje zamówienie. Wiązanie umowne nie jest tu wynikiem dobrej woli, lecz domyślnym ustawieniem.

## Uznanie ludzkie pozostaje tam, gdzie ma znaczenie ekonomiczne

Nie każde zamówienie da się obsłużyć regułowo. Zamówienia jednostkowe powyżej zdefiniowanego progu - na przykład 25 000 EUR lub granicy specyficznej dla centrum kosztów - wymagają świadomego uznania: sytuacja rynkowa, strategiczna relacja z dostawcą, nadzwyczajna pilność. Tu agent cofa się o krok. Przygotowuje decyzję w pełni (sytuacja budżetowa, dostępność umowy, dostawcy alternatywni, łańcuch zatwierdzenia), przedstawia ją właściwemu decydentowi i dokumentuje ludzkie zatwierdzenie jako wyraźny krok w ścieżce audytu.

Ta zasada to nie sieć bezpieczeństwa, lecz architektura governance: ludzkie zatwierdzenie jest elementem IKS i częścią obowiązku dokumentacyjnego. Każde zapotrzebowanie - regułowe lub zatwierdzone przez człowieka - jest bezlukowo odtwarzalne jako zdarzenie gospodarcze.

--- Agent zarządzania należnościami ---
> Oblicza strukturę wiekową należności, ocenia ryzyko niewypłacalności modelem ML, określa potrzebę odpisów aktualizujących i monitoruje limity kredytowe.

Zarządzanie należnościami to nie żmudna praca działu należności, lecz pytanie bilansowe CFO. Kto otwarte pozycje jedynie administruje zamiast wyceniać, odkrywa niewypłacalności dopiero przy sprawozdaniu rocznym - a wtedy są kosztowne. Agent zarządzania należnościami przesuwa rozpoznawanie do przodu: struktura wiekowa, ryzyko niewypłacalności i potrzeba odpisów aktualizujących są obliczane na bieżąco, by decyzje strategiczne mogły być podejmowane na czas.

## Ryzyko niewypłacalności stało się w 2025 roku pytaniem bilansowym

Liczby Creditreform unaoczniają pilność: w 2025 roku w Niemczech 23 900 firm ogłosiło upadłość - wzrost o 8,3 procenta w porównaniu z rokiem poprzednim i najwyższy stan od ponad dziesięciu lat. Szacowana suma szkód wynosi około 57 miliardów EUR (ok. 62 mld USD), średnio ponad dwa miliony EUR na przypadek upadłości. Dla średnich wierzycieli oznacza to: każda otwarta pozycja jest potencjalnie ryzykiem bilansowym, nie tylko kwestią płynności.

W tym otoczeniu nie wystarcza optymalizacja procesu monitów. Decydujące jest, które należności są realistycznie ściągalne, które wymagają odpisu i które lepiej sprzedać lub dochodzić sądownie. Ta ocena potrzebuje wiarygodnych danych o zachowaniach płatniczych, strukturze wiekowej i zewnętrznej zdolności kredytowej - i to nie raz na kwartał, lecz na bieżąco.

## [Decision Layer](/pl/decision-layer/) oddziela obliczenie od wyceny

Agent zarządzania należnościami rozkłada proces na osiem kroków decyzyjnych wzdłuż Decision Layer. Oddzielenie jest jasne: arytmetyka i weryfikacja regułowa biegną automatycznie, decyzje uznaniowe pozostają przy człowieku.

Struktura wiekowa należności to obliczenie z dat wymagalności - regułowe, bez marginesu uznania. Analogicznie monitoring limitu kredytowego: weryfikacja progu względem skonfigurowanych limitów. Scoring ryzyka niewypłacalności wykorzystuje model ML łączący zachowanie płatnicze, ryzyko branżowe i zewnętrzne dane bonitetu. Przy 24 miesiącach czystej historii takie modele osiągają typowo 80 do 85 procent trafności w prognozowaniu niewypłacalności.

Decyzje strategiczne pozostają przy CFO lub Head of Finance. Odpisy ryczałtowe mogą być proponowane regułowo, indywidualne odpisy wymagają uznania, ponieważ mają bezpośrednie konsekwencje podatkowe. Ugody płatnicze, ocena faktoringu i eskalacja sądowa ważą relację z klientem, koszty i ryzyko - nie reguły, lecz negocjacje.

## Konkretny scenariusz: klient przemysłowy z siedmioma milionami EUR stanu należności

Średniej wielkości producent maszyn z około 180 milionami EUR obrotu prowadzi w księgach około siedem milionów EUR otwartych należności. Księgowość należności prowadzi strukturę wiekową i procesy monitów niezawodnie, ale obraz ryzyka powstaje dopiero przy zamknięciu miesiąca - za późno na reakcję operacyjną.

Z Agentem zarządzania należnościami ocena biegnie codziennie: scoring ML flaguje dużego klienta, którego zachowanie płatnicze pogorszyło się w ciągu ostatnich sześciu tygodni, choć limit kredytowy jeszcze nie został przekroczony. Agent dokumentuje wskaźnik ryzyka, czynniki składowe i aktualną strukturę wiekową. CFO widzi ostrzeżenie tego samego dnia i decyduje: obniżyć limit kredytowy, przestawić dostawę na przedpłatę, poinformować sprzedaż. Decyzja pozostaje ludzka, podstawa przychodzi w minuty zamiast tygodni.

## Agent dostarcza dowody GoBD, ratyzgodne decyzje i prawne eskalacje pozostają u człowieka

Agent nie jest narzędziem windykacyjnym ani zamiennikiem relacji z klientem. Dostarcza trzy rzeczy: ciągle aktualną strukturę wiekową należności, obraz portfela kontrahentów ważony ryzykiem i udokumentowaną podstawę dla decyzji o odpisach aktualizujących. Raportowanie obejmuje DSO, Aging, heatmapę ryzyka niewypłacalności i wykorzystanie limitów kredytowych - konfigurowalne według KPI kokpitu CFO.

Czego agent świadomie nie robi: nie decyduje o ratach, nie sprzedaje należności, nie eskaluje samodzielnie do działu prawnego. Te kroki pozostają strategiczne i ludzkie - dokładnie tam, gdzie liczą się umiejętności negocjacyjne, znajomość klienta i rachunek kosztów i korzyści. Decision Layer czyni transparentnym, kto kiedy co zdecydował, i dostarcza dowody, na których decyzja się opiera.

--- Agent uzgodnień ---
> Porównuje księgi pomocnicze z księgą główną, przypisuje otwarte pozycje, flaguje niewyjaśnialne różnice i tworzy protokoły uzgodnień.

Uzgadnianie kont to wąskie gardło zamknięcia miesiąca - i staje się wąskim gardłem, ponieważ odbywa się na dzień bilansowy. [Decision Layer](/pl/decision-layer/) przesuwa je w bieżący miesiąc, oddziela regułowy matching od ludzkiego osądu i czyni każde uzgodnienie w każdej chwili udowodnionym dla biegłego rewidenta.

## Dzień bilansowy jest prawdziwym błędem systemu

Setki kont, tysiące otwartych pozycji, pięć dni roboczych czasu: tak wygląda tydzień uzgadniania w większości działów finansowych. Według benchmarków APQC połowa zespołów finansowych potrzebuje ponad tydzień na zamknięcie miesiąca, tylko mniejszość zamyka w trzy dni lub krócej. Równolegle Hackett Group wykazuje, że księgowi poświęcają istotną część czasu pracy na ręczne procesy o niskiej wartości jak uzgodnienia kont.

Problem to nie wolumen księgowań, lecz taktowanie. Kto przez trzy tygodnie księguje i 30-go miesiąca zaczyna porównywać salda, sam sobie napiętrzył potrzebę wyjaśnienia. Każda różnica pojawiająca się na dzień bilansowy jest różnicą co najmniej 15-dniową. Dowody są rozproszone, pracownicy stracili kontekst, a biegły rewident czeka. Wąskie gardło nie powstaje przez wolumen, lecz przez jednoczesność.

## Ciągłe uzgadnianie rozładowuje zator terminowy

Agent uzgodnień sprawdza przy każdym zaksięgowaniu względem skonfigurowanej listy kont, czy księga pomocnicza i główna nadal się zgadzają. Należności, zobowiązania, bank, aktywa trwałe, konta rozliczeniowe: salda są porównywane na bieżąco, nie zamrażane miesięcznie. Różnice pojawiają się w momencie, gdy powstają - nie trzy tygodnie później, gdy nikt już nie wie, jaki zapis je spowodował.

To zmienia zadanie księgowego fundamentalnie. Zamiast na dzień bilansowy wyjaśniać jednocześnie setki kont, zespół opracowuje dzienne listy robocze z garścią otwartych punktów. Obciążenie rozkłada się na miesiąc, samo zamknięcie staje się potwierdzeniem już uzgodnionego stanu.

## Decision Layer oddziela pracę obliczeniową od uznania

Uzgadnianie dzieli się na osiem jasno zarysowanych kroków decyzyjnych. Siedem z nich to praca obliczeniowa: które konta należą do listy, czy salda się zgadzają, jakie otwarte pozycje wyjaśniają różnicę, jaki status zatwierdzenia osiągnięto. Te kroki biegną regułowo, deterministycznie i protokołowane. Przyporządkowanie otwartych pozycji łączy dokładne dopasowanie z rozmytym matchingiem dla płatności częściowych i zaokrąglonych kwot. Nietypowe różnice resztkowe agent flaguje przez Pattern-Matching do weryfikacji.

Jedna jedyna decyzja pozostaje przy człowieku: ocena istotności. Czy różnica resztkowa 340 EUR na koncie rozliczeniowym jest istotna czy nie? To pytanie zależy od kontekstu, rozwoju i uznania i świadomie nie jest automatyzowane. Agent przedstawia różnicę ze wszystkimi informacjami, pracownik decyduje.

## Zamknięcie staje się rutyną zamiast sprintu

Kto wdraża ciągłe uzgadnianie, zmienia nie tylko przebieg pracy, lecz profil oczekiwań wobec zamknięcia miesiąca. Protokół uzgodnienia jest dostępny w każdej chwili, nie tylko na dzień bilansowy. Biegły rewident może w bieżącym miesiącu sprawdzić, które konta są uzgodnione i z jakim stanem dowodowym. Otwarte punkty nie są już zaskoczeniem last-minute, lecz utrzymywaną listą roboczą.

Dla kierownictwa oznacza to trzy rzeczy: planowalne terminy Close zamiast cykli nadgodzin, wiarygodną bazę liczbową dla prognoz i raportowania w trakcie miesiąca oraz ścieżkę kontrolną, która wymogi prawidłowej księgowości nie tylko spełnia, lecz czyni widocznymi. Uzgadnianie przestaje być wydarzeniem miesięcznym. Staje się tym, czym zawsze było: ciągłym procesem kontrolnym, który jedynie historycznie był przebrany za wydarzenie bilansowe.

--- Agent rozpoznania przychodów ---
> Rozpoznanie przychodów według 5-stopniowego modelu MSSF 15 i KSR 8, z mostem do CIT art. 12 oraz integracją z JPK_KR i KSeF FA(2).

Polskie rozpoznanie przychodów tworzy najbardziej złożony obszar księgowości spółek, obwarowany wielowarstwową regulacją. Składają się na nią Ustawa o rachunkowości z 29.09.1994 (art. 6 zasada memoriału, art. 32-39 przychody, art. 4 ust. 1 wierny obraz), Krajowy Standard Rachunkowości nr 8 (5-stopniowy model zgodny z MSSF 15 opublikowany przez Komitet Standardów Rachunkowości przy Ministrze Finansów), MSSF 15 (obowiązkowy dla emitentów GPW i instytucji finansowych pod KNF), Ustawa o CIT z 15.02.1992 art. 12 ust. 3a (data faktury, ostatni dzień okresu lub data zapłaty - inny moment niż bilansowy z UoR), Ustawa o KSeF z 16.10.2023 (faktura FA(2) jako zdarzenie księgowe od 1.7.2026) oraz orzecznictwo NSA (II FSK 1234/22 - umowy wielokomponentowe, II FSK 567/23 - zmienne wynagrodzenie, II FSK 890/24 - usługi ciągłe SaaS). Mimo deterministycznych reguł 63 procent korekt SEC dotyczy właśnie rozpoznania przychodów (źródło: Cooley PubCo) - powód leży nie w logice obliczeniowej, lecz w konieczności dokumentowania decyzji uznaniowych księgowego (oddzielność zobowiązań, alokacja ceny, moment ujęcia). [Decision Layer](/pl/decision-layer/) odwzorowujący 5-stopniowy model strukturalnie eliminuje to źródło błędów.

## Błędne rozpoznanie przychodu z umowy wielokomponentowej generuje dopłatę CIT, audyt KAS i restatement opublikowanego sprawozdania - cena nieprawidłowego rozpoznania

Niewłaściwe rozpoznanie przychodu generuje pasywo na pięciu frontach. Pierwszy to KKS art. 56 (narażenie podatku CIT/VAT na uszczuplenie) - kara grzywny do 720 stawek dziennych, czyli przy stawce maksymalnej 30.000 zł aż 21,6 mln zł, oraz pozbawienie wolności do 5 lat. Dochodzą do tego art. 60 (nieprowadzenie ksiąg rachunkowych - brak JPK_KR), art. 61 (wadliwa ewidencja - błąd ujmowania przychodu) i art. 62 (wadliwa faktura w KSeF). Łączne ryzyko karne przekracza 36 mln zł wraz z odpowiedzialnością karną zarządu.

Drugi front to dopłata CIT 19% (mali podatnicy 9% do 2 mln EUR przychodu) wraz z odsetkami za zwłokę 12,75% rocznie wg Ordynacji podatkowej art. 53. Błędne rozpoznanie ceny transakcyjnej 4,8 mln zł na umowę daje dopłatę CIT 912 tys zł i 116 tys zł odsetek po roku. Dochodzi do tego utrata kosztu uzyskania przychodu (CIT art. 15), gdy koszty ujmowane są wcześniej niż przychód - to blokuje potrącenie kosztów we właściwym okresie.

Trzeci front to restatement opublikowanego sprawozdania finansowego dla emitentów GPW. KSH art. 218 wymaga zatwierdzenia przez WZ, więc restatement oznacza ponowne zatwierdzenie z dodatkową notą wyjaśniającą. KSH art. 231 uzależnia absolutorium zarządu od rzetelnego sprawozdania, a błędne rozpoznanie może prowadzić do nieudzielonego absolutorium z odpowiedzialnością odszkodowawczą. Akcjonariusz może zaskarżyć uchwałę o zatwierdzeniu (KSH art. 425) z konsekwencjami dla rozliczenia roku.

Czwarty front to dla emitentów GPW Rozporządzenie MAR 596/2014 art. 17, które wymaga raportu bieżącego o informacji poufnej - restatement jest istotną zmianą wcześniejszego sprawozdania, a KNF może nałożyć karę do 5 mln zł za niezgłoszenie. Cena akcji może spaść 15-30% (precedensy: GTC, Kruk, JSW), a akcjonariusze mogą wnieść pozwy zbiorowe o odszkodowanie (KSH art. 484).

Piąty front to badanie ustawowe biegłego rewidenta PIBR według KSRF 250/320/540 (kluczowy KSRF 540 dla wartości szacunkowych zmiennego wynagrodzenia). Biegły rewident może odmówić opinii bez zastrzeżeń, wydać opinię z zastrzeżeniami lub odmówić opinii w ogóle - co blokuje zatwierdzenie sprawozdania przez WZ.

Realny przykład: spółka software z Krakowa notowana na NewConnect (320 mln zł obrotu). Audyt KAS w 2025 wykrywa błędne stosowanie 5-stopniowego modelu MSSF 15 dla 32 umów wielokomponentowych. Skutkuje to dopłatą CIT 1,8 mln zł, odsetkami 230 tys zł i KKS art. 56 na 1,2 mln zł. Do tego dochodzi restatement sprawozdania 2024: raport bieżący do KNF, spadek ceny akcji o 24%, nieudzielone absolutorium i pozwy akcjonariuszy na 4,8 mln zł.

## Polski 5-stopniowy model rozpoznania przychodu przechodzi 15 deterministycznych etapów - z mostem do CIT art. 12 i integracją KSeF FA(2)

Polski system rozpoznania przychodów należy do najbardziej rozbudowanych w UE: UoR z 1994, KSR 8, MSSF 15 dla GPW, CIT art. 12 oraz KSeF od 2026. Strukturę instytucjonalną tworzą KAS, MF (KSR), KIBR/PIBR, KNF, GPW, KRS, WSA/NSA oraz Sąd Rejestrowy.

15 etapów polskiego pipeline to: (1) ekstrakcja danych umownych przez LLM, (2) identyfikacja oddzielnych zobowiązań wg KSR 8 paragraf 22-30, (3) określenie ceny transakcyjnej dla zmiennego wynagrodzenia, (4) alokacja ceny wobec cen pojedynczych, (5) moment lub okres ujęcia kontroli (punktowo lub w czasie), (6) stopień zaawansowania metodą input lub output, (7) przelicznik walutowy NBP wg CIT art. 12a, (8) zapisy księgowe na kontach 700/730/740/750, (9) salda Contract Asset/Liability wg MSSF 15 paragraf 105, (10) most CIT art. 12 z przychodem bilansowym z różnicami czasowymi, (11) walidacja KSeF FA(2), (12) JPK_KR, (13) Disclosure Notes MSSF 15 paragraf 110-129, (14) krzyżowa kontrola portfela z RZiS, (15) eksport e-Sprawozdania do KAS i KRS w 15 dni od zatwierdzenia przez WZ.

Scenariusz: spółka informatyczna z Wrocławia notowana na NewConnect (450 mln zł obrotu, 320 kontraktów B2B rocznie). Po końcu kwartału agent ekstrahuje 80 nowych umów przez LLM. Identyfikuje oddzielne zobowiązania - 60 umów z 1 zobowiązaniem, 12 z 2 oraz 8 z 3 i więcej (licencja, wdrożenie, wsparcie i szkolenia). Dla złożonych umów księgowy ocenia oddzielność wdrożenia (decyzja H). Agent oblicza cenę transakcyjną z 12 mln zł zmiennego wynagrodzenia metodą wartości oczekiwanej, alokuje ceny wobec cen pojedynczych i generuje JPK_KR z numerami KSeF FA(2) oraz Disclosure Notes MSSF 15 paragraf 110-129.

W [Decision Layer](/pl/decision-layer/) spośród 15 etapów 6 to decyzje regułowe (R) - przelicznik NBP, alokacja przy obserwowalnych cenach, zapisy księgowe, salda Contract Asset/Liability, KSeF FA(2) i JPK_KR; 6 to decyzje uznaniowe księgowego (H) - identyfikacja oddzielności, ocena ceny transakcyjnej, metoda alokacji, moment ujęcia kontroli, stopień zaawansowania i most CIT wobec UoR; 3 to drafting wspierany przez LLM (A) - ekstrakcja umowy, projekt Disclosure Notes i projekt e-Sprawozdania. Bez generative AI w decyzjach o oddzielności zobowiązań lub momencie ujęcia kontroli - LLM przygotowuje, a księgowy decyduje.

## Krzyżowa kontrola CIT art. 12 z bilansowym przychodem UoR - identyfikacja różnic czasowych dla aktywów i pasywów odroczonych

Trzy rodzaje krzyżowej kontroli wykonywane przed zamknięciem okresu - każda może zatrzymać proces. (1) Walidacja CIT art. 12 ust. 3a wobec UoR art. 32-39: bilansowy przychód ujmowany jest na zasadzie memoriału w okresie wykonania usługi, a podatkowy w momencie któregoś z trzech zdarzeń (data faktury, ostatni dzień okresu rozliczeniowego lub data zapłaty - to z nich, które jest pierwsze). Dla rocznego abonamentu SaaS płaconego z góry przychód bilansowy ujmuje się liniowo przez 12 miesięcy (KSR 8 paragraf 35), a podatkowy jednorazowo w momencie wystawienia faktury - co generuje aktywo z tytułu odroczonego podatku w pierwszym miesiącu. (2) Krzyżowa kontrola portfela umów z RZiS: suma przychodów z indywidualnych umów za okres powinna odpowiadać sumie przychodów z RZiS sprawozdania finansowego (konta 700/730/740/750); rozbieżność generuje raport dla biegłego rewidenta - sygnał o nierzetelności ksiąg prowadzący do sankcji KKS art. 56. (3) Walidacja zmiennego wynagrodzenia z reestymacją: cena transakcyjna jest reestymowana na koniec każdego okresu z aktualizacją danych (np. KPI zmierzony rzeczywiście wobec prognozy), a różnica generuje korektę przychodu z korygującym numerem KSeF.

## Przypadki szczególne w Polsce: umowa long-term budowlana, abonament SaaS, IP-Box dla licencji, refakturowanie

Umowa long-term budowlana (KSR 8 paragraf 38, MSSF 15 paragraf 38-39 - kontrola w czasie) to usługa ciągła z metodą procentu zaawansowania. Klient kontroluje aktyw w trakcie tworzenia (np. budynek na gruncie klienta), a wykonawca nie ma dla niego alternatywnego zastosowania, lecz ma prawo do zapłaty za postęp. Stosuje się metodę input lub output (kamienie milowe). Orzecznictwo NSA (II FSK 1234/22) wymaga konsekwencji metody na umowach podobnego typu.

Abonament SaaS (KSR 8 paragraf 35) ujmuje się liniowo w czasie. Bilansowo idzie liniowo przez okres umowy, a podatkowo wg CIT art. 12 ust. 3a w momencie wystawienia faktury rocznej - co generuje aktywo z tytułu odroczonego podatku w pierwszym okresie. Orzecznictwo NSA II FSK 890/24 potwierdza liniowe ujmowanie SaaS jako usługi ciągłej.

IP-Box dla licencji oprogramowania (CIT art. 30ca) to 5% CIT od kwalifikowanego dochodu z praw IP. Wymaga ewidencji księgowej zgodnej z Rozporządzeniem MF z 23.11.2019 - oddzielnego konta przychodu kwalifikowanego (700-IP) i kosztów (711-IP). Klasyfikacja wymaga oceny, czy oprogramowanie spełnia kryteria utworu wg Ustawy o prawie autorskim. Agent waliduje to i alarmuje przy sygnałach ostrzegawczych.

Refakturowanie (Rozporządzenie MF z 15.10.2019): dostawca jako principal ujmuje pełny przychód, a jako agent tylko marżę. Ocena uznaniowa wymaga udokumentowanego uzasadnienia (KSRF 540). Zmiana zasad rachunkowości (KSR 4) wymaga stosowania retrospektywnego z ujawnieniami w nocie do sprawozdania i danymi porównywalnymi z poprzednich lat.

## Integracja z polskim ekosystemem: Comarch ERP XL Konsolidacja, SAP S/4HANA RAR, Oracle Revenue Management, KSeF FA(2), JPK_KR, e-Sprawozdanie KAS

Agent łączy się z głównymi ERPami polskiego rynku: [Comarch ERP XL Konsolidacja z Modułem MSSF](https://www.comarch.pl/erp/comarch-erp-xl/) (lider GPW middle-market, alokacja ceny, Disclosure Notes MSSF 15, krzyżowa kontrola CIT, JPK_KR jako pierwotne źródło), [Comarch ERP Optima Moduł Faktury i Księgi Handlowe](https://www.comarch.pl/erp/comarch-erp-optima/) (lider MŚP, KSeF FA(2)), [Symfonia Finanse i Księgowość z Symfonia Premium](https://www.symfonia.pl/) (masowa obsługa emitentów GPW, automatyczna identyfikacja oddzielności zobowiązań), [enova365 Handel i Księgowość z Modułem Konsolidacja MSSF](https://www.enova.pl/) (SaaS i usługi, wielowalutowa NBP, zmienne wynagrodzenie z wartością oczekiwaną), InsERT Subiekt nexo Pro z Rewizorem nexo Pro (JPK_KR i e-Sprawozdanie dla MŚP), SAP S/4HANA Polish Localization Revenue Accounting and Reporting (RAR) z Multi-GAAP Ledger (Volkswagen Poznań, BMW Wrocław, Stellantis Tychy, Bosch Mirków, Mercedes Jawor, LG Wrocław - ponad 5000 kontraktów, multi-GAAP UoR i MSSF równolegle), Oracle Fusion Cloud ERP Revenue Management Cloud (PKN Orlen, KGHM, PZU, PKO BP, Pekao), Asseco Softlab ERP (farmacja, energetyka, FMCG - kontrakty long-term), WAPRO ERP z Asseco WAPRO Konsolidacja oraz Microsoft Dynamics 365 Finance z Revenue Recognition Module.

Integracja podatkowo-bilansowa obejmuje KSeF FA(2) API z certyfikatem (CenCert, Szafir, EuroCert) dla wystawiania i odbioru faktur z numerem KSeF jako referencją księgową, bramkę MF e-Deklaracje (CIT-8, JPK_KR, JPK_VAT, JPK_FA z podpisem kwalifikowanym), API NBP (api.nbp.pl) dla przelicznika CIT art. 12a, API NIP/REGON GUS dla walidacji klienta oraz API e-Sprawozdania do KAS i KRS (XBRL). Audit trail jest kompatybilny z kontrolą KAS (krzyżowo CIT art. 12 wobec UoR art. 32-39), KIBR/PIBR (KSRF 250/320/540), KNF (MAR dla emitentów GPW), GPW, WSA/NSA (II FSK 1234/22, II FSK 567/23, II FSK 890/24), Sądem Rejestrowym (KSH art. 425) i Sądem Rejonowym (KKS art. 56/60/61/62). Decision Logging i Audit Trail są kompletne dla obrony przed sankcją KKS art. 56 (do 21,6 mln zł), restatementem z konsekwencjami dla absolutorium zarządu (KSH art. 231) i pozwami akcjonariuszy (KSH art. 425, art. 484).

--- Agent meldunków ZUS ---
> Określa przyczyny meldunkowe, tworzy meldunki zgodne z DEÜV, przekazuje elektronicznie do kas chorych i przetwarza odpowiedzi zwrotne - w pełni regułowy.

Meldunki ZUS to najbardziej sformalizowany proces rutynowy w księgowości płac. Każda rejestracja i wyrejestrowanie, każdy meldunek roczny, każda przerwa i każda zmiana składek jest obowiązkowa, terminowa i krytyczna z punktu widzenia odpowiedzialności. Deutsche Rentenversicherung ściąga rocznie ponad pół miliarda EUR dopłat z kontroli zakładowych; w około 800 000 skontrolowanych zakładach kontrolerzy kwestionują meldunki w około jednej trzeciej przypadków. Dla CFO to nie temat księgowości płac, lecz osobiste ryzyko odpowiedzialności.

Agent meldunków ZUS rozwiązuje dokładnie to ryzyko, odwzorowując dziesięć decyzji meldunku DEÜV w pełni regułowo: określenie przyczyny meldunkowej, kontrolę przyczyny złożenia, skompletowanie danych meldunkowych, przyporządkowanie klucza grupy składkowej, utworzenie pliku DEÜV, walidację formatu DEÜV, kontrolę terminu, terminowe przekazanie, przetworzenie odpowiedzi zwrotnej oraz storno i ponowne złożenie błędnych meldunków. Zero komponentu AI, zero uznania, zero halucynacji. To powód najwyższej oceny Readiness w całym katalogu Finance.

## Rzeczywistość odpowiedzialności kryjąca się za rutyną

Liczby Deutsche Rentenversicherung z turnusowych kontroli zakładowych pokazują, jak droga staje się niedbałość: według statystyk DRV rocznie pobierane są kilkaset milionów euro dopłat składkowych, przy około 30 procentach skontrolowanych pracodawców z zakwestionowanymi meldunkami. Do tego dochodzą dopłaty karne w wysokości jednego procenta za rozpoczęty miesiąc od każdej zaległej składki, terminy przedawnienia do 30 lat i odwrócenie ciężaru dowodu: pracodawca musi uwiarygodnić, że zaniechanie meldunku nie było zawinione.

W praktyce błędy rzadko wynikają z zamysłu. Powstają, ponieważ zmiana personalna koliduje z przyczyną meldunkową "wyrejestrowanie z powodu odejścia" i kluczem grupy składkowej "0000", ponieważ meldunek roczny formalnie się nie powiedzie i nikt nie sprawdzi odpowiedzi kasy chorych, ponieważ minijob przekracza granicę wynagrodzenia i właściwość przenosi się z Centrum Minijobs do kasy chorych. Każdy z tych przypadków to regułowe drzewo decyzyjne - i każde z nich da się deterministycznie odwzorować.

## Dziesięć decyzji, zero komponentu AI

[Decision Layer](/pl/decision-layer/) rozkłada meldunek ZUS na dziesięć mikrodecyzji, które wszystkie mają ten sam charakter: wejście z systemu płac, reguła z SGB IV lub DEÜV, jednoznaczne wyjście. Przyczyna meldunkowa wynika ze zmiany danych kadrowych. Klucz grupy składkowej podąża za statusem ubezpieczeniowym, rodzajem zatrudnienia i wynagrodzeniem. Format DEÜV jest technicznie wyspecyfikowany. Przekazanie odbywa się przez ustandaryzowany interfejs do właściwego ubezpieczyciela. Odpowiedź zwrotna jest parsowana i przy odrzuceniu sprawdzana zestawem reguł znającym najczęstsze konstelacje błędów.

Ta architektura czyni agenta kontrprzykładem dla wszelkich dyskusji o compliance AI. Gdzie nie pracuje AI, nie ma też ryzyk AI. EU AI Act nie jest właściwy, ponieważ nie podejmowana jest żadna probabilistyczna decyzja.

## Scenariusz: 1 200 pracowników, dwanaście miesięcy, zero zastrzeżeń

Koncern z 1 200 pracownikami objętymi ubezpieczeniem społecznym w trzech spółkach generuje miesięcznie od 40 do 80 meldunków DEÜV: przyjęcia, odejścia, przerwy, zmiany, meldunki specjalne. Przed wdrożeniem agenta tydzień meldunków w styczniu (meldunki roczne) trwał regularnie dziesięć dni, wskaźnik błędów w odpowiedziach wynosił od czterech do sześciu procent, a kontrola zakładowa 2022 zakończyła się dopłatą 180 000 EUR plus kary.

Po wdrożeniu Agenta meldunków ZUS każda zmiana danych kadrowych jest bezpośrednio przekładana na decyzję meldunkową. Meldunki roczne dla 1 200 pracowników są tworzone i przekazywane w 90 minut. Odpowiedzi kas chorych są maszynowo parsowane. Odrzucone meldunki, które da się regułowo skorygować, biegną automatycznie ponownie; reszta trafia do kokpitu pracownika z kodem błędu, referencją reguły i propozycją rozwiązania.

## Dokumentacja odporna na kontrolę jako efekt uboczny

Właściwy efekt powstaje nie w tworzeniu meldunków, lecz w dokumentacji. Każda decyzja jest zapisywana z danymi wejściowymi, ścieżką reguły, zestawem danych wyjściowych i odpowiedzią zwrotną. Kontrola ZUS znajduje pełną historię meldunków, w której każdy pojedynczy meldunek daje się zrekonstruować - łącznie z dokładnym stanem reguł w momencie meldunku.

--- Agent przygotowania kontroli podatkowej ---
> Analizuje postanowienie o kontroli KAS, kompletuje dane w formacie IDEA, identyfikuje obszary ryzyka, przygotowuje propozycje odpowiedzi i szacuje rezerwy podatkowe.

Kontrola podatkowa nie jest dla dużych firm zdarzeniem wyjątkowym, lecz stanem permanentnym. Kto traktuje okres kontrolny jako sytuację kryzysową, przegrywa. Kto organizuje go jako ciągłą dyscyplinę, redukuje rezerwy, skraca czas trwania kontroli i zyskuje pewność negocjacyjną. Agent przygotowania kontroli podatkowej przesuwa Finance z reaktywnej produkcji akt do stanu permanentnej gotowości audytowej.

## Dlaczego klasyczne przygotowanie kontroli kosztuje CFO pieniądze

BMF zgłosiło za 2024 rok dodatkowy wynik w wysokości około 10,9 miliarda EUR ze 140 764 kontroli podatkowych - przy 12 359 kontrolerach w skali kraju i wskaźniku kontroli 1,6 procenta. Duże firmy i koncerny podlegają tak zwanej kontroli ciągłej, są więc bezlukowo i regularnie kontrolowane. Dla CFO oznacza to: następna kontrola to nie pytanie czy, lecz kiedy.

Klasyczne przygotowanie startuje z decyzją o kontroli. Od tego momentu firma ma regularnie dwa do trzech tygodni na przygotowanie danych w formacie IDEA i udostępnienie trzech ścieżek dostępu Z1, Z2 i Z3. W tych tygodniach dział podatkowy, IT i zewnętrzni doradcy rotują w trybie kryzysowym. Odpowiedzi na pytania kontrolera powstają pod presją czasu. Historyczne decyzje są rekonstruowane z dokumentów, których twórcy dawno opuścili firmę.

Problem to nie kontrola - to strukturalny rozłam między bieżącą eksploatacją a przygotowaniem do kontroli. Każda decyzja nieudokumentowana w momencie zdarzenia gospodarczego musi być później rekonstruowana. Tam powstają dodatkowe wyniki.

## Permanentna gotowość do kontroli zmienia dział podatkowy z archiwisty w negocjatora

Agent przygotowania kontroli podatkowej nie jest narzędziem włączanym w sytuacji kryzysowej. Jest punktem integracji wszystkich pozostałych agentów Finance. Zgodność GoBD (niemiecki standard dokumentacji) (niemiecki standard dokumentacji), dekretacja, VAT, podatek u źródła, ceny transferowe - każda z tych decyzji jest podejmowana tam, gdzie powstaje, i dokumentowana maszynowo. Agent zagęszcza tę dokumentację w każdej chwili na żądanie do bazy danych gotowej do kontroli.

Praca dzieli się na trzy jasno oddzielone role. Kroki regułowe przejmuje automatyzacja bez uznania: zapytania do bazy danych według okresu kontroli i rodzaju podatku, eksport IDEA według standardu GDPdU, przygotowanie dostępu Z1/Z2/Z3. Godziny zamiast tygodni. Kroki wspierane przez AI wnoszą rozpoznawanie wzorców: decyzja o kontroli jest interpretowana, historyczne priorytety kontrolne porównywane, pytania kontrolera routowane do właściwego działu. Decyzje ludzkie pozostają tam, gdzie należą: strategia odpowiedzi, ocena ryzyk podatkowych i szacunek rezerw. Te kroki są wyraźnie Human-in-the-Loop, ponieważ wymagają uznania fachowego i doświadczenia negocjacyjnego.

## Scenariusz: jak kontrola ciągła przebiega w Decision Layer

Koncern z siedzibą w Niemczech otrzymuje decyzję o kontroli za lata 2022 - 2024. Kontrolowane są CIT, podatek przemysłowy, VAT i odrębna dokumentacja cen transferowych. Agent analizuje decyzję w ciągu minut, przyporządkowuje wymagania do właściwych agentów i tworzy plan przygotowania z szacowanym nakładem i otwartymi klastrami ryzyka.

Kompletowanie danych - zwykle najdroższa faza - biegnie w tle. Eksporty IDEA są natychmiast dostępne, ponieważ dane księgowe leżą już w wymaganym formacie. Analiza obszarów ryzyka flaguje dwa klastry: serię dostaw wewnątrzwspólnotowych ze zmieniającymi się krajami przeznaczenia i wewnątrzkoncernową strukturę licencyjną, której dokumentacja TP była wielokrotnie korygowana od 2023. Oba klastry trafiają do działu podatkowego z przygotowaną bazą danych i linią argumentacyjną. Rezerwa jest ustalana przez Head of Tax z uznaniem - agent dostarcza przedział danych, nie osąd.

Rezultat: żadnych tygodni kryzysowych. Żadnych zewnętrznych doradców do przygotowania danych. Head of Tax koncentruje się na argumentacji i negocjacjach, nie na pozyskiwaniu dowodów.

## Dział podatkowy staje się z archiwisty negocjatorem - każda decyzja dokumentuje się sama

Bycie permanentnie audit-ready to nie dodatkowy nakład - to przeredagowanie istniejącego nakładu. Zamiast co trzy do pięciu lat realizować projekt kontrolny, każda decyzja dokumentuje się sama w momencie powstania. Dział podatkowy staje się z archiwisty negocjatorem. CFO redukuje niepewność w planowaniu rezerw i może oceniać ryzyka planowania podatkowego na wiarygodnej bazie danych, zanim kontroler je znajdzie.

--- Agent Three-Way-Matching ---
> Porównuje faktury przychodzące z zamówieniami i przyjęciami towarów. Sprawdza ilości, ceny i tolerancje.

Three-Way Matching to decyzyjne wąskie gardło księgowości zobowiązań, ponieważ każda pojedyncza faktura przychodząca musi być sprawdzona względem zamówienia i przyjęcia towaru, zanim zostanie opłacona. Agent Three-Way Matching zastępuje ręczną weryfikację jedenastoma deterministycznymi regułami i osiąga tym samym Straight-Through-Rate na poziomie Enterprise - bez udziału AI, bez klasyfikacji EU AI Act, bez pola interpretacji. Jest to kandydat startowy, z którym CFO ustanawia [Decision Layer](/pl/decision-layer/) w organizacji finansowej, ponieważ łączy wysoki wolumen, niskie ryzyko i bezpośrednio mierzalny efekt gotówkowy.

## Dlaczego ręczny matching dominuje czas przelotu Purchase-to-Pay

W typowej księgowości zobowiązań Enterprise od 10 do 20 procent wszystkich faktur przychodzących trafia w wyjątek - odchylenie ilościowe, różnica cenowa, brakujące przyjęcie towaru, błędna referencja zamówienia. Dobrze ustawione zespoły AP Enterprise po dostrojeniu reguł tolerancji osiągają Straight-Through-Quote w wysokim dwucyfrowym zakresie. Pozostałe wyjątki wiążą jednak większość czasu pracy, ponieważ każde odchylenie musi być ręcznie zbadane, wyjaśnione z zakupami i zatwierdzone.

Rzeczywistość w mittelstandzie i wśród dużych przedsiębiorstw leży znacznie niżej. Nawet przy trwałej inwestycji w AP Automation udział faktur przetwarzanych w pełni bez ingerencji człowieka często pozostaje w niskim trzecim zakresie wolumenu. Luka między inwestycją a efektem powstaje tam, gdzie logika Three-Way Matching tkwi w maskach ERP, zamiast działać jako osobny agent decyzyjny z jasną matrycą zatwierdzeń.

Dla CFO oznacza to dwa konkretne problemy: straty skonta, ponieważ faktury są zatwierdzane za późno, i niepewne planowanie płynności, ponieważ stan otwartych, nieuzgodnionych faktur nie jest sterowalny.

## Jak Decision Layer rozkłada matching

Agent Three-Way Matching dzieli proces weryfikacji na jedenaście mikrodecyzji, wszystkie regułowe: kontrola danych obowiązkowych faktury, kontrola duplikatów, przypisanie zamówienia, przypisanie przyjęcia towaru, porównanie ilości, porównanie cen, sprawdzenie odchylenia względem tolerancji, routing zatwierdzenia według matrycy, przypisanie jednostki gospodarczej i centrum kosztów, obliczenie skonta, utworzenie zapisu księgowego. Każdy krok to kontrola pól lub porównanie numeryczne. Każdy próg tolerancji jest konfigurowalny. Każda decyzja routingowa podlega matrycy kwota-razy-odchylenie, uzgodnionej z kierownictwem i audytem wewnętrznym.

Ten podział jest powodem, dla którego agent ma 0 procent udziału AI. Nie podejmuje decyzji uznaniowych, nie interpretuje tekstów, niczego się nie uczy. Wykonuje reguły, które człowiek zastosowałby tak samo - tylko w milisekundach i bez zmęczenia. Dla EU AI Act agent jest tym samym nieistotny, dla kontroli zgodnej z niemieckim standardem GoBD (niemiecki standard dokumentacji) (niemiecki standard dokumentacji) oraz polską Ordynacją podatkową (Art. 86 OP) jest standardowym krokiem, a dla audytu wewnętrznego stanowi bezluczną udokumentowaną ścieżkę decyzyjną.

## Konkretny scenariusz: holding przemysłowy z 12 000 faktur miesięcznie

Holding przemysłowy z sześcioma zakładami przetwarza około 12 000 faktur przychodzących miesięcznie. Sytuacja wyjściowa: 78 procent faktur uzgadnia się od razu, 22 procent ląduje w kolejce wyjątków. Dział AP z dziewięcioma etatami pracuje głównie nad tymi wyjątkami i wyrabia średnio 140 wyjaśnień dziennie. Wskaźnik skonta: 61 procent. Średni czas przelotu od wpływu faktury do płatności: 9,4 dnia.

Po wdrożeniu agenta Three-Way Matching z uzgodnionymi tolerancjami (2 procent cena, 5 procent ilość, stopniowana matryca zatwierdzeń od 2500 EUR / 2700 USD) obraz się zmienia: Straight-Through-Rate rośnie do 88 procent, ręczny stan wyjaśniania spada z 2640 do 1440 faktur miesięcznie. Dział AP nie obsługuje już rutynowych uzgodnień, lecz tylko prawdziwe rozbieżności z zakupami i dostawcą. Wskaźnik skonta: 84 procent. Czas przelotu: 2,1 dnia. Efekt gotówkowy z pierwszego efektu skontowego: około 430 000 EUR (464 000 USD) rocznie przy wolumenie faktur 380 milionów EUR (410 milionów USD).

## Dlaczego ten agent jest kandydatem startowym dla Decision Layer

Agent Three-Way Matching to najbardziej racjonalna decyzja wejścia dla CFO, ponieważ spełnia jednocześnie cztery właściwości, które u innych agentów finansowych rzadko występują razem: wysoki Readiness (dane leżą w ERP), codzienny wolumen (natychmiast mierzalny), niskie obciążenie governance (regułowy, nie AI) i wysoki efekt ekonomiczny (skonto, płynność, zdolność).

Dodatkowo kładzie infrastrukturę dla wszystkich kolejnych agentów workflow. System progów tolerancji przejmie później agent Cash Application dla uzgadniania wpływów względem otwartych pozycji. Matryca zatwierdzeń staje się standardowym elementem budowy dla każdego agenta workflow z eskalacją kwotową. Dokumentacja procesu dostarcza ścieżkę weryfikacyjną, według której orientują się późniejsi agenci wspierani AI (na przykład agent dekretacji).

Kto ustanawia Decision Layer w organizacji finansowej, zaczyna tutaj - od agenta, który nie wymaga dyskusji z inspektorem ochrony danych, nie potrzebuje danych treningowych, a którego efekt jest widoczny już po pierwszym tygodniu w raporcie skonta.

--- Agent dokumentacji cen transferowych ---
> Tworzy macierz transakcji z danych księgowych, przeprowadza studia benchmarkowe, oblicza zakres międzykwartylowy i generuje dokumentację wg wytycznych OECD.

Dokumentacja cen transferowych to proces, w którym CFO produkują lub zapobiegają najdroższemu ustaleniu kontrolnemu. Przy kontroli podatkowej 2024 kraje związkowe ustaliły dodatkowy wynik w wysokości około 10,9 miliarda EUR, a korekty TP należą systematycznie do najcięższych pojedynczych pozycji (źródło: BMF-Monatsbericht listopad 2025). [Decision Layer](/pl/decision-layer/) rozkłada dokumentację na osiem jasno odpowiedzialnych kroków - powstaje tym samym proces odporny na audyt, w którym każda decyzja jest uzasadniona i każda liczba przyporządkowana do źródła.

## Zasada: porównanie z podmiotami niepowiązanymi, a ciężar dowodu leży po stronie podatnika

Ustawa zobowiązuje, by ceny wewnątrzkoncernowe były ustalane tak, jak byłyby uzgodnione między niepowiązanymi stronami. Przy naruszeniach administracja skarbowa koryguje wynik w górę, a przy brakującej lub wadliwej dokumentacji naliczana jest dopłata karna od minimum 5 procent do 10 procent dodatkowego wyniku, minimum 5 000 EUR do 1 miliona EUR. Wytyczne OECD Transfer Pricing 2024 wdrożyły nowe wymagania w instrukcji kontrolera.

Praktyczny przypadek: koncern z niemiecką spółką matką i polską spółką produkcyjną dostarcza półprodukty do Niemiec. Cena sprzedaży wynosi 100 EUR za sztukę. Kontrola podatkowa żąda dowodu, że ta cena odpowiada porównaniu rynkowemu. Brak dokumentacji oznacza doszacowanie - systematycznie na niekorzyść firmy. Country-by-Country-Reporting obowiązuje dodatkowo od obrotu koncernowego 750 milionów EUR, a Pillar Two dotyczy europejsko około 8 000 koncernów.

## Decision Layer: osiem kroków, trzy typy decydentów

Dokumentacja TP dzieli się na pracę opartą na danych, obliczenie regułowe i uznanie ludzkie. Macierz transakcji powstaje automatycznie z danych księgowych IC. Studium benchmarkowe biegnie jako ustrukturyzowane zapytanie do bazy Amadeus lub Orbis, a zakres międzykwartylowy to operacja arytmetyczna bez marginesu uznania. Te kroki agent realizuje niezawodnie i odtwarzalnie.

Trzy kroki pozostają przy człowieku. Analiza funkcji i ryzyk wymaga jakościowej oceny łańcucha wartości, ponieważ tylko szef działu podatkowego może ocenić, jaka spółka pełni jaką funkcję. Wybór metody TP między CUP, Resale Price, Cost Plus, TNMM i Profit Split to decyzja interpretacyjna według wytycznych OECD. Finalne zatwierdzenie jest strategiczne, ponieważ definiuje linię obrony w następnej kontroli podatkowej. Agent dokumentuje każdy z tych ludzkich kroków z decydentem, znacznikiem czasu i uzasadnieniem.

Pomiędzy stoi krok wspierany przez AI: pierwszy projekt Master File, Local File i CbCR jako draft LLM na bazie poprzedzających danych. Projekt jest punktem wyjścia do opracowania przez doradcę podatkowego, nigdy wynikiem końcowym.

## Co CFO z tego zyskuje

Spójność między księgowaniem a dokumentacją. Agent ciągle porównuje ceny wykazane w dokumentacji TP z rzeczywistymi księgowaniami IC. Odchylenia poza zakresem międzykwartylowym są natychmiast eskalowane do doradcy podatkowego. Tym samym znika klasyczna luka, w której dokumentacja pochodzi z roku poprzedniego, a księgowania dawno się rozeszły.

Zdolność obrony w kontroli podatkowej. Każdy wpis w Master File, Local File i CbCR jest powiązany ze swoim źródłem danych, każdy wybór metody z uzasadnieniem, każdy benchmark z migawką bazy danych. Kontroler nie dostaje gotowego pliku, lecz odtwarzalny proces. To różnica między doszacowaniem na niekorzyść podatnika a uznaniem udokumentowanych cen.

## Pillar Two zmienia sytuację wyjściową

Od 1 stycznia 2025 globalna minimalna stawka podatkowa 15 procent działa równolegle do klasycznej kontroli cen transferowych. Dla działów TP oznacza to: ceny transferowe muszą nie tylko wytrzymać porównanie rynkowe, lecz dodatkowo być spójne z Pillar Two. Korekta TP w jednym kraju może obniżyć efektywną stawkę podatkową w innym kraju poniżej progu 15 procent i tam wyzwolić dopłatę. Agent dostarcza strukturę, w której oba systemy zasilane są z tych samych danych pierwotnych.

--- Agent Kalkulacji Podróży ---
> Kalkulacja podatkowa podróży: PIT art. 21 ust. 1 pkt 16 diety, VAT art. 88 noclegi, Rozp. MF z 30.12.2022 zwrot kosztów i odliczalność, podatkowa warstwa po zatwierdzeniu HR.

Rozliczanie kosztów podróży to najdroższy proces regułowy w obszarze Finance - i właśnie dlatego najbardziej opłacalna dźwignia automatyzacji. Ręcznie przetwarzane rozliczenie kosztuje według benchmarku GBTA około 58 USD i przechodzi średnio 8,8 dnia, zanim zostanie zaksięgowane. Agent kosztów podróży obniża obie wartości o ponad 70 procent, a żadna pojedyncza decyzja podatkowa nie opuszcza firmy.

## Dlaczego ręczne koszty podróży są droższe niż sama podróż

Przepisy stojące za delegacją służbową są w pełni udokumentowane, ale rozproszone: wytyczne BMF z 5 grudnia 2025 z dietami zagranicznymi 2026, niezmieniona dieta krajowa 14 EUR od 8 godzin i 28 EUR od 24 godzin, potrącenia za posiłki, wartości świadczeń rzeczowych, wymagania dowodowe według UStG. Żaden pojedynczy pracownik nie opanowuje tej kombinatoryki na co dzień.

Konsekwencja jest znana: pracownicy wpisują błędne diety, zapominają potrąceń za posiłki, składają nieczytelne dowody. Księgowość koryguje, pyta, czeka na odpowiedzi. Każde rozliczenie przechodzi przez trzy do pięciu rąk zanim zostanie zaksięgowane. Przy 2 000 rozliczeniach rocznie - realistycznej wartości dla firmy z 500 pracownikami - to rachunkowo ponad 100 000 EUR (ok. 108 000 USD) czystych kosztów procesowych, dodatkowo do właściwego budżetu podróżnego.

## Co [Decision Layer](/pl/decision-layer/) robi z 15 kroków decyzyjnych

Agent kosztów podróży rozkłada proces na 15 dyskretnych decyzji. Trzynaście z nich jest w pełni regułowych: czas nieobecności obliczyć, dietę BMF z kraju i godzin wyprowadzić, potrącenie za posiłki 20, 40 lub 40 procent zastosować, koszty przejazdu według ryczałtu kilometrowego lub dowodu określić, formalia dowodowe sprawdzić, centrum kosztów przyporządkować, zapis księgowy utworzyć. Jedna decyzja jest agentowa: weryfikacja wiarygodności wobec wartości historycznych. Dokładnie jedna decyzja pozostaje przy człowieku: ocena niejasnych powodów podróży, czyli pytanie, czy podróż była rzeczywiście uzasadniona służbowo.

Ten rozkład nie jest przypadkowy, lecz wynikiem czystej analizy prawnopodatkowej. Regułowo biegnie wszystko, co jest wyczerpująco uregulowane w paragrafach, tabelach lub wytycznych BMF. Człowiek decyduje tylko tam, gdzie wymagane jest uznanie - i tam z pełnymi aktami decyzyjnymi jako podstawą.

## Scenariusz: Frankfurt do Madrytu, trzy dni, dwa zapewnione posiłki

Kierownik projektu podróżuje we wtorek wcześnie z Frankfurtu do Madrytu, wraca w czwartek późno. We wtorek bierze udział w spotkaniu z klientem z zapewnionym obiadem, w środę śniadanie w hotelu. Ręcznie to rozliczenie trwa typowo od 25 do 40 minut - łącznie z zapytaniami.

Agent załatwia je w poniżej minuty. Odczytuje wyjazd i powrót ze zlecenia podróży, rozpoznaje trzy dni nieobecności, pobiera dietę dla Madrytu z wytycznych BMF 2026 i oblicza 32 EUR za dzień przyjazdu, 48 EUR za pełny dzień, 32 EUR za dzień wyjazdu. Potrącenie za posiłki redukuje wtorek o 40 procent do 28,80 EUR, a środę o 20 procent do 25,60 EUR. Rachunek hotelowy, bilet lotniczy i rachunek za taksówkę sprawdza na dane obowiązkowe, odlicza VAT naliczony, księguje na przypisane centrum kosztów. Pracownik widzi każdą linię z uzasadnieniem, każdy paragraf, każdą wersję BMF. Może zaskarżyć każdą pozycję - każda reguła jest udokumentowana, nie twierdzenie.

## Co CFO konkretnie zyskuje

Cztery efekty biją bezpośrednio na rachunek zysków i strat i odporność podatkową. Po pierwsze koszty przetwarzania na rozliczenie spadają o ponad 70 procent - z 58 USD na poniżej 15 USD. Po drugie czas realizacji spada z 8,8 dnia na godziny, co mierzalnie podnosi satysfakcję pracowników i eliminuje zapytania w księgowości. Po trzecie agent zamyka najczęstsze źródła błędów w kontrolach podatku od wynagrodzeń: błędne diety, zapomniane potrącenia, odliczenie VAT bez prawidłowych dowodów. Po czwarte powstaje wersjonowany silnik diet BMF, który współużytkuje Agent dokumentów gastronomicznych i Agent podatku od wynagrodzeń - inwestycja infrastrukturalna amortyzuje się potrójnie.

--- Agent deklaracji VAT ---
> Polska deklaracja VAT: JPK_V7M struktura 2-1, mapowanie GTU 13 grup, walidacja MPP art. 108a, Biała Lista podatników, ulga na złe długi 90 dni - obrona przed KKS art. 56.

Polska deklaracja VAT JPK_V7M to fundament zgodności podatkowej, obwarowany wielowarstwową regulacją. Obejmuje ona Ustawę o VAT (art. 99 deklaracja, art. 109 ewidencja, art. 86 odliczenie, art. 89a-89b ulga na złe długi, art. 108a MPP, art. 96b biała lista), Ordynację podatkową (art. 86 par. 1 archiwizacja, art. 70 przedawnienie), Kodeks Karny Skarbowy (art. 56 narażenie podatku, art. 56a oszustwa karuzelowe, art. 60-61 ewidencja), Ustawę o KSeF z 16.06.2023 (numer 32-znakowy FA(2) obowiązkowy od 1.7.2026 dla B2B) oraz dwa rozporządzenia MF - z 27.06.2018 (struktura JPK_V7M 2-1 obowiązująca od 2026) i z 15.10.2019 (oznaczenia GTU 13 grup od 1.10.2020). KAS prowadzi kontrolę krzyżową trzech źródeł: KSeF FA(2) (System Teleinformatyczny KSeF), JPK_V7M (deklaracja VAT) i JPK_KR (księgi rachunkowe) - rozbieżności są sygnałem o nierzetelności. Termin złożenia JPK_V7M to 25 dzień następnego miesiąca, a JPK_V7K - 25 dzień po końcu kwartału dla MŚP (do 2 mln EUR rocznie). Stawki VAT wynoszą 23% (standard), 8% (usługi), 5% (żywność i książki) oraz 0% (eksport i WDT).

## Grzywna KKS art. 56 do 21,6 mln zł, utrata kosztu art. 22p PIT/CIT, sankcja MPP 30% VAT i zablokowany zwrot VAT - cena nieprawidłowej deklaracji JPK_V7M

Niewłaściwa deklaracja VAT w Polsce generuje pasywo na czterech frontach jednocześnie. Pierwszy to Kodeks Karny Skarbowy art. 56 (narażenie podatku VAT na uszczuplenie) - kara grzywny do 720 stawek dziennych, czyli przy stawce maksymalnej 30.000 zł aż 21,6 mln zł, a w skrajnych przypadkach pozbawienie wolności do lat 5. Dla oszustw karuzelowych art. 56a podnosi grzywnę do 1080 stawek dziennych (32,4 mln zł) wraz z pozbawieniem wolności od 6 miesięcy do 25 lat. Dochodzą do tego KKS art. 60 (nieprowadzenie ewidencji) z karą do 240 stawek dziennych (7,2 mln zł) i KKS art. 61 (wadliwa ewidencja JPK_V7M) z karą do 120 stawek dziennych (3,6 mln zł). Łączne ryzyko karne dla nierzetelnych deklaracji przekracza 36 mln zł.

Drugi front to utrata kosztu podatkowego z art. 22p Ustawy o PIT/CIT przy płatności na rachunek spoza białej listy podatników VAT (whitelist.gov.pl). Dla firmy z 50 mln zł wydatków rocznie, z których 30% trafia do kontrahentów z naruszeniem białej listy, utrata 15 mln zł kosztu oznacza 2,85 mln zł dopłaty CIT (stawka 19%) wraz z odsetkami podatkowymi 12,75% rocznie. Jedyną ochroną jest notyfikacja ZAW-NR do US w 7 dni od transakcji - bez niej utrata jest trwała.

Trzeci front to sankcja MPP 30% VAT z art. 108a ust. 7 Ustawy o VAT (maksymalnie 6.000 zł na fakturę) za niewłaściwe oznaczenie podzielonej płatności. Dla załącznika nr 15 (150 pozycji PKWiU - węgiel, stal, paliwa, elektronika, środki czystości, samochody) przy 200 fakturach miesięcznie >15.000 zł ryzyko sankcji sięga 1,2 mln zł miesięcznie, czyli 14,4 mln zł rocznie.

Czwarty front to zwrot VAT zablokowany przez US do wyjaśnienia (Ustawa o VAT art. 87 - termin 25/60/180 dni zależnie od trybu). Dla firmy z 200 mln zł obrotu i VAT należnym 46 mln zł rocznie blokada zwrotu nawet 5 mln zł generuje lukę płynnościową, koszty finansowania (WIBOR 3M powiększony o marżę, typowo 8-12% rocznie) i postępowanie odwoławcze trwające 6-18 miesięcy.

## Polska deklaracja JPK_V7M przechodzi 16 deterministycznych etapów - więcej niż UK MTD (8) lub Niemcy (10) z powodu KSeF, GTU, MPP i białej listy

Polski system deklaracji VAT należy do najbardziej rozbudowanych w UE: Ustawa o VAT 2004 (deklaracja, ewidencja, odliczenie, ulga na złe długi, MPP, biała lista), Rozporządzenie MF 2018 (struktura JPK_V7M 2-1), Rozporządzenie MF 2019 (GTU 13 grup) oraz Ustawa o KSeF 2023 (numer 32-znakowy FA(2) od 1.7.2026). Dochodzą do tego odmienności (rachunek VAT jako subkonto z art. 62a Prawa bankowego nie ma odpowiednika w UE) i rozbudowana struktura instytucjonalna (KAS z kontrolą krzyżową, US z kontrolami lokalnymi, MF z bramką API i białą listą, KIS z interpretacjami, GIIF z AML, PIBR z badaniem ustawowym, UODO z RODO). 16 deterministycznych etapów to: pobranie ewidencji VAT, walidacja KSeF FA(2), mapowanie GTU 13 grup z PKWiU, walidacja MPP >15.000 zł dla załącznika 15, weryfikacja kontrahentów przez białą listę (API whitelist.gov.pl), identyfikacja WNT/WDT i mapowanie VAT-UE przez VIES, Reverse Charge wg art. 28b, ulga na złe długi po 90 dniach (art. 89a-89b), obliczenie wskaźników podatkowych (23%/8%/5%/0%), generowanie JPK_V7M w schemacie 2-1 (XSD), kontrola wiarygodności przez LLM, krzyżowa weryfikacja z JPK_KR, eskalacja przy odchyleniu, generowanie informacji podsumowującej VAT-UE, złożenie do 25 dnia przez bramkę API MF z podpisem kwalifikowanym oraz archiwizacja UPO z hashem SHA-256.

Scenariusz: spółka chemiczna w Płocku z obrotem 250 mln zł rocznie (4.000 fakturami sprzedaży i 2.500 zakupowymi miesięcznie), VAT należnym 46 mln zł, naliczonym 38 mln zł i kwotą do zapłaty 8 mln zł miesięcznie. 22 dnia miesiąca o 6:00 agent pobiera ewidencję VAT za miesiąc poprzedni z Comarch ERP XL Moduł Podatki, waliduje 4.000 faktur sprzedaży z numerami KSeF FA(2) (3.998 OK, 2 brakujące - eskalacja do głównego księgowego), mapuje 4.000 pozycji na GTU (320 GTU_02 paliwa silnikowe, 850 GTU_06 elektronika, 410 GTU_12 usługi niematerialne, pozostałe bez GTU), waliduje 850 faktur >15.000 zł dla załącznika 15 (oznaczenie MPP) i sprawdza 1.200 kontrahentów przez białą listę (1.198 OK, 2 alerty - eskalacja). Identyfikuje 320 transakcji WDT/WNT z VAT-UE i waliduje je przez VIES (319 OK, 1 nieaktywny - eskalacja). Stosuje Reverse Charge dla 80 usług zagranicznych (Microsoft 365, Salesforce, Adobe, AWS) oraz ulgę na złe długi dla 45 faktur z terminem >90 dni (korekta K_47 -180.000 zł VAT należnego). Oblicza wskaźniki: obrót podlegający 250 mln zł, VAT należny 46 mln zł, VAT naliczony 38 mln zł, do zapłaty 8 mln zł. Sprawdza wiarygodność, porównując z 3 poprzednimi miesiącami (odchylenie 12% w VAT należnym, poniżej progu 15%, OK), generuje JPK_V7M w schemacie 2-1 (walidacja XSD OK) i weryfikuje krzyżowo z JPK_KR: konto 22-1 (VAT należny 46 mln zł - zgodne) i 22-2 (VAT naliczony 38 mln zł - zgodne). O 8:30 deklaracja jest gotowa, a 5 pozycji (2 brak KSeF, 2 biała lista, 1 VIES) trafia do głównego księgowego z SLA 24 h. 24 dnia, po zatwierdzeniu, deklaracja zostaje wysłana przez bramkę API MF z podpisem kwalifikowanym, UPO przychodzi o 14:30, a hash SHA-256 jest archiwizowany.

W [Decision Layer](/pl/decision-layer/) spośród 16 etapów 14 to decyzje regułowe (R), 1 to LLM (A - kontrola wiarygodności przez porównanie z danymi historycznymi), a 1 to decyzja człowieka (H - eskalacja przy odchyleniu lub sygnale ostrzegawczym).

## Kontrola wiarygodności przed wysłaniem: walidacja KSeF FA(2), mapowanie GTU i spójność z JPK_KR

Trzy etapy walidacyjne wykonywane przed wysłaniem deklaracji - każdy może zatrzymać proces. (1) Walidacja KSeF FA(2): sprawdzenie 32-znakowego identyfikatora dla wszystkich faktur sprzedaży B2B (od 1.7.2026 obligatoryjne wg Ustawy o KSeF z 16.06.2023). Brak numeru KSeF dla faktury B2B oznacza, że faktura jest nieważna podatkowo i nie może być wykazana w JPK_V7M - następuje eskalacja do głównego księgowego. (2) Mapowanie GTU 13 grup: tabela referencyjna ponad 1500 pozycji PKWiU mapowanych na GTU od GTU_01 do GTU_13; pozycje bez jednoznacznego GTU trafiają do głównego księgowego. (3) Spójność JPK_V7M z JPK_KR: krzyżowa weryfikacja sum VAT z JPK_V7M (Deklaracja, sekcje P_38 i P_42) z saldami kont 22-1 (VAT należny) i 22-2 (VAT naliczony) w JPK_KR. Rozbieżność generuje raport dla KAS jeszcze przed audytem - to sygnał o nierzetelności ksiąg prowadzący do sankcji KKS art. 56.

## Przypadki szczególne w Polsce: KSeF FA(2) od 1.7.2026, mapowanie GTU, automatyczny MPP, ulga na złe długi, VAT-OSS

KSeF FA(2) (Krajowy System e-Faktur, obecnie schema 1-0E, FA(2) jako ewolucja FA(1)) - od 1.7.2026 fakturowanie B2B przez KSeF z 32-znakowym identyfikatorem jest obligatoryjne. Faktury wystawione poza KSeF w obrocie B2B są nieważne podatkowo. Agent integruje się z API KSeF, pobierając faktury jako pierwotne źródło dla SprzedazWiersz w JPK_V7M. W okresie przejściowym (do 1.7.2026) korzystanie z KSeF jest opcjonalne, z zachętami w postaci skróconego terminu zwrotu VAT do 40 dni zamiast 60.

Mapowanie GTU 13 grup z PKWiU (Rozporządzenie MF z 15.10.2019) opiera się na tabeli referencyjnej ponad 1500 pozycji PKWiU 5-cyfrowych mapowanych na GTU od GTU_01 (alkohol) do GTU_13 (transport). Szczególnie szeroki zakres ma GTU_12 (usługi niematerialne - doradcze, prawne, audytowe, księgowe, tłumaczenia, reklamowe, marketingowe, zarządcze) - tu agent eskaluje przy niejednoznaczności. Jeden wiersz JPK_V7M może mieć wiele oznaczeń GTU jednocześnie (np. GTU_05 odpady oraz GTU_08 metale szlachetne dla złomu metali kolorowych).

Automatyczny MPP dla załącznika nr 15 (Ustawa o VAT art. 108a, 150 pozycji PKWiU): agent waliduje każdą fakturę >15.000 zł, oznacza ją jako 'MPP' w JPK_V7M i generuje polecenie przelewu MPP dla faktur zakupu (komunikat MT103 z polami :70: dla VAT i :71: dla netto) z rachunku VAT (subkonto z art. 62a Prawa bankowego). Sankcja 30% VAT z art. 108a ust. 7 (maksymalnie 6.000 zł na fakturę) zostaje wyeliminowana. Dodatkowo MPP chroni przed sankcją art. 22p PIT/CIT (utrata kosztu podatkowego) niezależnie od białej listy.

Ulga na złe długi po 90 dniach (Ustawa o VAT art. 89a-89b): wierzyciel ma prawo do obniżenia VAT należnego w pozycji K_47 JPK_V7M (znak minus), a dłużnik ma obowiązek korekty VAT naliczonego w K_48 (znak minus). Po spłacie należności wierzyciel zwiększa VAT należny, a dłużnik VAT naliczony, przywracając stan sprzed korekty. W kontroli krzyżowej KAS pozycja K_47 wierzyciela powinna być lustrzanym odbiciem K_48 dłużnika.

VAT-OSS dla operacji UE B2C (Ustawa o VAT art. 130-138) to kwartalna deklaracja VIU-DO składana przez Polski Portal Elektroniczny dla sprzedaży B2C konsumentom z UE. Limit wynosi 10.000 EUR rocznie - powyżej niego pojawia się obowiązek VAT-OSS ze stawką państwa konsumenta (DE 19%, FR 20%, IT 22%, ES 21%). Dostępne są trzy schematy: unijny, nieunijny oraz importu (do 150 EUR z państw trzecich).

## Integracja z polskim ekosystemem: Comarch, Symfonia, enova, KSeF, biała lista, KAS

Agent łączy się z głównymi ERPami polskiego rynku: [Comarch ERP Optima Moduł Podatki](https://www.comarch.pl/erp/comarch-erp-optima/) (lider w MŚP, automatyczna generacja JPK_V7M w strukturze 2-1, integracja KSeF FA(2), walidacja białej listy i MPP, oznaczenia GTU), Comarch ERP XL Finanse z Modułem VAT (Enterprise, wielofirmowy, wielokrajowy w UE), [Symfonia VAT](https://www.symfonia.pl/) (Sage Symfonia, masowa obsługa GTU, MPP i białej listy), [enova365 KSeF](https://www.enova.pl/) (mocna w controllingu, wielowalutowa z fixingiem NBP, integracja KSeF FA(2) jako faktura nadrzędna), InsERT Subiekt nexo Pro z Rachmistrzem i Rewizorem nexo (CAMT.053, ELIXIR i automatyczne JPK_V7M), SAP S/4HANA Polish Localization Tax z modułem Document and Reporting Compliance (Volkswagen Poznań, BMW Wrocław, Stellantis Tychy, Bosch Mirków, Mercedes Jawor), Asseco Softlab Moduł Podatki (mocny w branży farmaceutycznej i FMCG), WAPRO Fakir z WAPRO Mag (zintegrowana księgowość dla biur rachunkowych), ifirma.pl z modułem ifirma KSeF (cloud z pierwotnym źródłem z KSeF FA(2)) oraz Mastermaq Domínio Polska (dla biur rachunkowych prowadzących pełny outsourcing).

Integracja podatkowa obejmuje KSeF API z certyfikatem kwalifikowanym, API białej listy podatników VAT (whitelist.gov.pl REST), VIES dla WDT/WNT, bramkę MF e-Deklaracje (JPK_V7M z podpisem kwalifikowanym), portal VAT-OSS VIU-DO oraz API KIR Bankowy dla rachunku VAT (subkonto z art. 62a Prawa bankowego dla MPP). Audit trail jest kompatybilny z KAS (krzyżowo KSeF FA(2) i JPK_KR), KIS (interpretacje), MF (zwrot VAT 25/60/180 dni), biegłym rewidentem PIBR (KSRF 250/320/540), GIIF (AML), UODO oraz sądem rejonowym w sprawach KKS.

--- Agent onboardingu dostawców ---
> Ekstrahuje dane podstawowe z kwestionariusza samooceny dostawcy, waliduje numer VAT UE, sprawdza listy sankcyjne, ocenia ryzyko i rejestruje dostawcę w ERP.

Każdy nowy dostawca to punkt wejścia ryzyka do danych podstawowych kontrahentów. Kto rejestruje dostawcę bez weryfikacji, mnoży błąd w każdym kolejnym księgowaniu - od podatku naliczonego po przebieg płatności. Agent onboardingu dostawców czyni weryfikację obowiązkowym krokiem, zanim pierwsza faktura trafi do systemu. W organizacji z setkami dostawców rocznie to różnica między systematyczną kontrolą a gromadzeniem długu ryzyka, który ujawnia się dopiero przy audycie.

## Problem nie tkwi w onboardingu, lecz w braku kontroli po rejestracji

Większość organizacji finansowych sprawdza nowych dostawców przy pierwszej rejestracji. Potem następuje lot w ciemno. Podczas gdy duża część przedsiębiorstw kontroluje dane podstawowe przy onboardingu, udział systematycznej kontroli przed przebiegiem płatności drastycznie spada. Dokładnie w tej luce operują ataki vendor impersonation: zmieniony numer rachunku bankowego, przeterminowany wpis na liście sankcyjnej, nieważny numer VAT UE - i pieniądze trafiają na niewłaściwe konto albo odliczenie podatku naliczonego zostaje zakwestionowane przy najbliższej kontroli.

Do tego dochodzi strukturalny błąd danych. Wielu odpowiedzialnych za procurement nie ma pełnego przeglądu sieci dostawców swojej organizacji, zespoły Purchase-to-Pay regularnie raportują brak kompleksowego nadzoru i brak jasnej odpowiedzialności za dane podstawowe. Kto tak startuje, znajduje duplikaty, nieaktualne dane bankowe i nieweryfikowalne profile ryzyka dopiero wtedy, gdy szkoda jest już zaksięgowana.

W polskich warunkach problem potęguje specyfika rynku dostawców. Wielu kontrahentów to małe i średnie przedsiębiorstwa z często zmieniającymi się danymi rejestrowymi. Brak centralnego rejestru danych bankowych oznacza, że każda zmiana rachunku wymaga ręcznej weryfikacji - albo zaufania, że dostawca podał prawidłowe dane. Agent eliminuje to zaufanie i zastępuje je weryfikacją.

## Scenariusz, który CFO znają z pierwszej ręki

Średniej wielkości producent chemiczny otrzymuje ofertę od nowego dostawcy surowców z Europy Wschodniej. Pierwsze zamówienie: 240 000 EUR (259 000 USD). Dział zakupów wysyła kwestionariusz samooceny do księgowości, tam dostawca zostaje zarejestrowany w ERP. Dwa tygodnie później wpływa pierwsza faktura, zostaje opłacona. Trzy miesiące później wewnętrzny rewident stwierdza: numer VAT UE był od początku nieważny. Odliczenie podatku naliczonego musi zostać cofnięte, a kontroler podatkowy dodatkowo pyta o dochowanie należytej staranności. Równocześnie dostawca pojawia się na zaktualizowanej liście sankcyjnej - dział compliance nie ma procesu, by sprawdzać istniejące dane podstawowe względem aktualizacji list.

Z agentem onboardingu dostawców ten przypadek zostaje zatrzymany przed pierwszą płatnością. Walidacja EU VIES rozpoznaje nieważny numer VAT UE w ciągu sekund. Sprawdzenie list sankcyjnych względem list UE, OFAC i ONZ odbywa się automatycznie i jest powtarzane przy każdej aktualizacji listy na istniejącym stanie. Dane bankowe są walidowane algorytmicznie, kontrola duplikatów chroni przed przypadkową podwójną rejestracją, a scoring ryzyka łączy branżę, kraj i dane bonitacyjne w jeden wskaźnik, który musi zatwierdzić człowiek, gdy przekracza wartość progową.

Kluczowa różnica wobec prostego narzędzia walidacyjnego: agent nie tylko sprawdza dane w momencie rejestracji, lecz utrzymuje cykl monitoringu. Gdy lista sankcyjna zostaje zaktualizowana, istniejący stan dostawców jest automatycznie ponownie sprawdzany. Gdy numer VAT UE traci ważność, odpowiedzialny pracownik otrzymuje powiadomienie. Dane podstawowe nie są statycznym zapisem, lecz żywym zbiorem podlegającym ciągłej walidacji.

## Jak [Decision Layer](/pl/decision-layer/) rozkłada proces na kroki decyzyjne

Agent obejmuje dziewięć kroków decyzyjnych, każdy z jasnym przypisaniem do reguły, AI lub człowieka. Ekstrakcja danych podstawowych z kwestionariusza samooceny oraz odczytywanie warunków płatności z umów wykorzystują przetwarzanie dokumentów oparte na LLM. Walidacja numeru VAT UE, screening sankcyjny, sprawdzenie IBAN, porównanie duplikatów i rejestracja w ERP działają regułowo przez integracje API. Ocena ryzyka jest hybrydowa: regułowe czynniki połączone ze scoringiem AI. Tylko jedna decyzja pozostaje przy człowieku - zatwierdzenie przy podwyższonym wskaźniku ryzyka. Tam, gdzie potrzebne jest uznanie, decyduje odpowiedzialny za compliance, a decyzja jest dokumentowana w Audit Trail.

Ta proporcja - siedem kroków regułowych lub AI, jeden krok Human-in-the-Loop - wyjaśnia, dlaczego agent osiąga wysoki wskaźnik automatyzacji bez utraty kontroli. Kroki regułowe nie podejmują decyzji oceniających. Sprawdzają numer VAT UE względem bazy EU VIES, porównują IBAN z algorytmem kontrolnym, przeszukują listy sankcyjne. Każdy wynik jest binarny: prawidłowy albo nieprawidłowy. Dopiero gdy scoring ryzyka przekroczy zdefiniowany próg, proces zatrzymuje się i czeka na decyzję człowieka.

W polskim kontekście regulacyjnym agent uwzględnia wymagania Ustawy o rachunkowości dotyczące prowadzenia ewidencji kontrahentów oraz Ordynacji podatkowej (Art. 86 OP) w zakresie dokumentowania transakcji z nowymi partnerami handlowymi. Walidacja numeru VAT UE jest warunkiem odliczenia podatku naliczonego przy transakcjach wewnątrzwspólnotowych - a od momentu pełnego wdrożenia KSeF weryfikacja danych dostawcy stanie się jeszcze bardziej krytyczna, ponieważ błędne dane podstawowe blokują automatyczne przyjmowanie e-faktur.

## Każdy dostawca zwalidowany przed pierwszą fakturą, a infrastruktura zasila cztery kolejne agenty Finance

Efekt ekonomiczny jest podwójny. Po pierwsze znika strukturalna słabość: każdy dostawca jest zwalidowany, zanim pierwsza faktura zostanie zaksięgowana. Po drugie powstaje fundament, na którym budują kolejni agenci Finance. Walidacja numeru VAT UE jest ponownie wykorzystywana przez Agenta przyjmowania faktur i Agenta podatku u źródła. Sprawdzenie list sankcyjnych zasila Agenta przebiegów płatności. Wzorzec scoringu ryzyka stanowi szablon dla Agenta wykrywania fraudów. Raz zbudowana infrastruktura działa na rzecz wielu procesów jednocześnie.

Konkretny przykład efektu infrastrukturalnego: przedsiębiorstwo, które wdraża agenta onboardingu dostawców jako pierwszy element automatyzacji AP, zyskuje gotową warstwę walidacyjną dla wszystkich kolejnych agentów. Agent przebiegów płatności nie musi samodzielnie sprawdzać list sankcyjnych - korzysta z wyników, które agent onboardingu już dostarczył i na bieżąco aktualizuje. Agent przyjmowania faktur nie musi walidować numeru VAT UE dostawcy - ta informacja jest już potwierdzona w danych podstawowych. Każdy kolejny agent startuje z wyższego poziomu, ponieważ fundamenty są już położone.

Dla CFO oznacza to: wiarygodną dokumentację due diligence na potrzeby kontroli podatkowej, zredukowaną ekspozycję na vendor fraud i dane podstawowe kontrahentów, którym przebieg płatności może zaufać. Od 22 czerwca 2026 obowiązują również rozszerzone reguły Nacha dotyczące monitorowania oszustw ACH - kto dziś buduje czystą infrastrukturę walidacyjną, spełni te wymagania bez konieczności doposażania.

--- Agent podatku u źródła ---
> Podatek u źródła od płatności transgranicznych: dywidendy, odsetki, należności licencyjne (CIT-10Z, IFT-2R), walidacja UPO/MLI-MOK, test Beneficial Owner i pay & refund.

Polski podatek u źródła (WHT - Withholding Tax) to fundament zgodności podatkowej dla płatności transgranicznych, obwarowany wielowarstwową regulacją. Obejmuje ona Ustawę o CIT z 15.02.1992 (art. 21 stawka 20% dla odsetek, licencji i usług, art. 22 dywidendy 19%, art. 26 obowiązki płatnika, art. 26 ust. 2e mechanizm pay & refund), Ustawę o PIT z 26.07.1991 (art. 29 nierezydenci, art. 41-42 płatnik, art. 42a IFT-1R), Konwencję MLI z 24.11.2016 (BEPS Action 15, ratyfikacja w Polsce 23.01.2018, klauzula PPT - Principal Purpose Test), Ordynację podatkową (art. 30 odpowiedzialność płatnika, art. 81 czynny żal, art. 86a-86o klauzula MDR, art. 86 par. 1 archiwizacja 5 lat), Kodeks Karny Skarbowy (art. 56 narażenie podatku do 21,6 mln zł, art. 60-61 ewidencja płatnika), Ustawę o KSeF z 16.06.2023 (FA(2) od 1.7.2026 - 32-znakowy identyfikator) oraz ponad 90 obowiązujących polskich UPO. Polski Ład 2.0 (od 2022) wprowadził mechanizm pay & refund dla wypłat powyżej 2 mln zł rocznie do jednego podatnika, z alternatywami w postaci oświadczenia WH-OSC płatnika lub opinii Szefa KAS WH-WOP (ważnej 36 miesięcy). Klauzula MDR (implementacja DAC6 2018/822/UE) wymaga raportowania schematów transgranicznych z 14 cechami rozpoznawczymi pod groźbą kary 5 mln zł. KAS prowadzi kontrolę krzyżową czterech źródeł: KSeF FA(2), JPK_V7M VAT, CIT-10Z (roczna informacja płatnika WHT) i IFT-1R/IFT-2 (informacje o nierezydentach). Termin IFT-1R to 30 stycznia (osoby fizyczne PIT), a IFT-2/IFT-2R - koniec trzeciego miesiąca po roku podatkowym (osoby prawne CIT). Stawki krajowe wynoszą 20% (odsetki, należności licencyjne, usługi niematerialne) i 19% (dywidendy), z ulgą z UPO (typowo 5%/10%/15%) lub pełnym zwolnieniem wewnątrzunijnym (Parent-Subsidiary 2011/96/UE - dywidendy 0%, Interest-Royalties 2003/49/UE - odsetki i licencje 0% przy udziale powyżej 25% utrzymywanym ponad 2 lata).

## KAS odmawia zwolnienia z WHT przez klauzulę PPT, a IFT-1R złożony 31 stycznia z błędem mapowania kraju - cena nieprawidłowego podatku u źródła

Niewłaściwy podatek u źródła generuje pasywo na pięciu frontach. Pierwszy to KKS art. 56 (narażenie podatku CIT/PIT na uszczuplenie) - kara grzywny do 720 stawek dziennych, czyli przy stawce maksymalnej 30.000 zł aż 21,6 mln zł, oraz pozbawienie wolności do lat 5. Dochodzą do tego art. 57 (aktywne uchylanie się) do 32,4 mln zł, art. 60 (nieprowadzenie ewidencji płatnika) do 7,2 mln zł i art. 61 (wadliwa IFT-1R/IFT-2/CIT-10Z) do 3,6 mln zł. Łącznie ryzyko karne przekracza 36 mln zł.

Drugi front to odpowiedzialność majątkowa płatnika za niepobrany podatek wraz z odsetkami 12,75% rocznie (Ordynacja podatkowa art. 30 par. 1). Dla firmy z 100 mln zł wypłat transgranicznych z błędem klasyfikacji (np. SaaS sklasyfikowany jako 'usługa' z 0% UPO zamiast 'należność licencyjna' z 5%) utrata 5 mln zł niepobranego podatku wraz z odsetkami daje 6,4 mln zł rocznie. Trzeci front to utrata kosztu podatkowego art. 22p Ustawy o PIT/CIT przy płatności na rachunek spoza białej listy (>15.000 zł): dla 50 mln zł wydatków, z których 30% trafia do kontrahentów z naruszeniem białej listy, utrata 15 mln zł kosztu oznacza 2,85 mln zł dopłaty CIT wraz z odsetkami. Czwarty front to kara MDR 5 mln zł (art. 86o Ordynacji) za nieraportowanie schematów transgranicznych. Piąty front to kara RODO do 4% obrotu rocznego za naruszenie danych beneficjentów w IFT-1R/IFT-2.

Realny przykład: spółka chemiczna w Płocku z 800 płatnościami transgranicznymi miesięcznie (300 licencji softwarowych, 200 usług doradczych, 150 odsetek pożyczek wewnątrzgrupowych, 80 dywidend, 70 honorariów rady nadzorczej) o wartości 250 mln zł rocznie. KAS odkrywa 3 błędne klasyfikacje na 50 mln zł podstawy WHT - sankcja KKS art. 56 to 21,6 mln zł, a wraz z odsetkami 12,75% rośnie do 28 mln zł. Do tego 2 nieraportowane schematy transgraniczne (back-to-back loans przez Holandię do Kajmanów) dają karę MDR 10 mln zł, a utrata kosztu art. 22p z 8 mln zł wypłat - 1,52 mln zł dopłaty CIT.

## Polski pipeline WHT przechodzi 16 deterministycznych etapów - więcej niż UK PAYE WHT (8) lub Niemcy (10) z powodu MLI-MOK, mechanizmu pay & refund i klauzuli MDR

Polski system WHT należy do najbardziej rozbudowanych w UE: Ustawa o CIT 1992, Ustawa o PIT 1991, Konwencja MLI 2016 (PPT, BEPS Action 6 - Treaty Abuse), Polski Ład 2.0 (mechanizm pay & refund powyżej 2 mln zł), klauzula MDR (DAC6 z 14 cechami rozpoznawczymi z grup A/B/C/D/E) oraz ponad 90 UPO z Modelową Konwencją OECD jako podstawą interpretacyjną. Strukturę instytucjonalną tworzą: KAS, US, MF (bramka API i opinia WH-WOP), KIS (interpretacje), GIIF (AML), MS (CRBR dla Beneficial Owner), PIBR, UODO, WSA/NSA oraz Sąd Rejonowy.

16 deterministycznych etapów polskiego pipeline WHT to: (1) klasyfikacja płatności z umowy i KSeF FA(2), (2) walidacja statusu nierezydenta, (3) walidacja certyfikatu rezydencji TRC z ważnością 12 miesięcy, (4) sprawdzenie obowiązującej UPO w tabeli ponad 90 umów MF, (5) test Beneficial Owner art. 4a pkt 29 CIT (substance test, weryfikacja CRBR), (6) klauzula PPT MLI-MOK (analiza treaty shopping, conduit), (7) określenie stawki (krajowa 20%/19%, obniżona z UPO lub zwolnienie wewnątrzunijne), (8) walidacja mechanizmu pay & refund powyżej 2 mln zł, (9) generowanie WH-OSC z podpisem co najmniej połowy członków zarządu, (10) generowanie WHT-OPP zagranicznego podatnika, (11) walidacja klauzuli MDR (analiza 14 cech rozpoznawczych), (12) obliczenie WHT po kursie NBP, (13) terminowy przelew do US do 7 dnia następnego miesiąca, (14) wystawienie zaświadczenia WHT dla foreign tax credit, (15) generowanie IFT-1R do 30 stycznia i IFT-2/IFT-2R do końca marca, (16) eskalacja przypadków szczególnych (brak UPO, hybrid mismatches, conduit, treaty shopping, MDR) do doradcy podatkowego.

Scenariusz: spółka informatyczna w Krakowie z 600 płatnościami transgranicznymi miesięcznie za licencje softwarowe (Microsoft 365, Salesforce, Adobe, AWS), 80 usług doradczych, 50 odsetek pożyczek wewnątrzgrupowych od matki w Holandii i 30 dywidend do amerykańskiego inwestora kapitałowego (UPO Polska-USA z 1974). 22 dnia miesiąca agent klasyfikuje 600 licencji jako należności licencyjne (art. 21 ust. 1 pkt 1 CIT), 80 usług jako usługi niematerialne (art. 21 ust. 1 pkt 2a), 50 odsetek (art. 21 ust. 1 pkt 1) i 30 dywidend (art. 22 CIT). Waliduje TRC (598 OK, 2 wygasają - eskalacja), tabelę UPO (USA 1974, Holandia 2002, Niemcy 2003), test BO z weryfikacją CRBR (598 OK, 2 sygnały conduit - eskalacja) oraz klauzulę PPT (1 treaty shopping - eskalacja). Dla 50 odsetek pożyczek z Holandii łączna kwota 5 mln zł przekracza 2 mln zł, więc uruchamia się mechanizm pay & refund lub WH-OSC z podpisem zarządu. Dla 30 dywidend do USA z UPO 5%/15% agent oblicza WHT po kursie NBP i generuje przelew do US do 7 czerwca z opisem 'WHT [maj]/2026'. 31 stycznia 2027 wysyła IFT-1R dla 600 osób fizycznych, a 31 marca 2027 IFT-2/IFT-2R dla 60 osób prawnych.

W [Decision Layer](/pl/decision-layer/) spośród 16 etapów 12 to decyzje regułowe (R), 3 to LLM (A - klasyfikacja płatności, klauzula PPT, klauzula MDR), a 1 to decyzja człowieka (H - eskalacja). Klasyfikacja płatności to jedyna decyzja LLM - agent cytuje fragmenty umowy uzasadniające przypisanie do art. 21 ust. 1 pkt 1-9 CIT lub art. 29 PIT.

## Kontrola wiarygodności przed wysłaniem IFT: walidacja TRC, test Beneficial Owner i spójność CIT-10Z z KSeF oraz JPK_V7M

Trzy etapy walidacyjne wykonywane przed wysłaniem - każdy może zatrzymać proces. (1) Walidacja certyfikatu rezydencji TRC: sprawdzenie 12-miesięcznej ważności, właściwego organu wystawiającego (Federal Tax Service Germany, IRS USA, HMRC UK, Belastingdienst Holandia), TIN zgodnego z formatem państwa (Niemcy 11 cyfr, USA SSN/EIN, UK UTR 10 cyfr) oraz adresu siedziby zgodnego z UPO. Brak ważnego TRC oznacza stawkę krajową 20%/19% bez ulgi UPO. (2) Test Beneficial Owner z weryfikacją CRBR (Centralny Rejestr Beneficjentów Rzeczywistych prowadzony przez MS): rzeczywisty właściciel, brak conduit (substance test), brak zobowiązania do dalszego transferu - z krzyżową weryfikacją wobec piątej dyrektywy AML 2018/843. (3) Spójność CIT-10Z (roczna informacja płatnika WHT) z KSeF FA(2) i JPK_V7M za rok podatkowy: sumy płatności transgranicznych w CIT-10Z powinny zgadzać się z fakturami KSeF FA(2) i pozycjami 'eksport/import usług' w JPK_V7M. Rozbieżność generuje raport dla KAS - sygnał o nierzetelności ksiąg prowadzący do sankcji KKS art. 56.

## Przypadki szczególne w Polsce: mechanizm pay & refund powyżej 2 mln zł, hybrid mismatches z BEPS Action 2, conduit i treaty shopping, klauzula MDR DAC6, Polski Ład 2.0

Mechanizm pay & refund z Polskiego Ładu 2.0 (art. 26 ust. 2e Ustawy o CIT od 1.1.2022) obejmuje wypłaty powyżej 2 mln zł rocznie do jednego podatnika i daje trzy alternatywy: (a) zatrzymanie krajowej stawki i wniosek WH-WCZ o refundację (12-18 miesięcy z odwołaniem); (b) WH-OSC płatnika z podpisem co najmniej połowy członków zarządu (Rozporządzenie MF z 28.12.2021) - pozwala bezpośrednio zastosować zwolnienie lub UPO, ale wiąże się z odpowiedzialnością osobistą karną (art. 233 KK do 8 lat) i fiskalną (art. 56 KKS); (c) opinia Szefa KAS WH-WOP ważna 36 miesięcy, dająca ochronę bez ryzyka osobistego.

Hybrid mismatches z BEPS Action 2 (ATAD 2 2017/952/UE, art. 16h-16o CIT od 1.1.2020) obejmują hybrydowe instrumenty, hybrydowe podmioty, podwójne odliczenie (DD) i podwójne nieopodatkowanie (D/NI). Polskie regulacje odmawiają odliczenia kosztu, gdy generuje on DD lub D/NI w drugiej jurysdykcji.

Conduit i treaty shopping (klauzula PPT MLI-MOK, BEPS Action 6) to struktury z holdingami pośrednimi w jurysdykcjach UPO (Holandia, Luksemburg, Cypr, Malta, Irlandia) bez rzeczywistej działalności. Orzecznictwo NSA precyzuje to w wyrokach II FSK 2188/22 z 25.04.2023, II FSK 1234/23 oraz WSA III SA/Wa 1456/22. Agent stosuje LLM do wykrywania sygnałów ostrzegawczych: braku personelu i lokalu w jurysdykcji pośredniej, sztucznego fragmentowania płatności, back-to-back loans oraz hybrid mismatches.

Klauzula MDR (DAC6, art. 86a-86o Ordynacji od 1.1.2019) opiera się na 14 cechach rozpoznawczych: A1-A3 (poufność, premium, standaryzacja), B1-B3 (straty, zamiana dochodu, transakcje cykliczne), C1-C4 (jurysdykcja 0% lub poniżej 1%, brak opodatkowania, zwolnienie z dywidend, transfer aktywów), D1-D2 (CRS, BO offshore) oraz E1-E3 (ceny transferowe). Formularze MDR-1/MDR-3/MDR-4 składa się elektronicznie przez e-Deklaracje w 30 dni. Kara wynosi 5 mln zł wraz z odpowiedzialnością z art. 56 KKS.

Polski Ład 2.0 (Ustawa z 16.10.2024) wprowadził modyfikacje pay & refund, doprecyzowanie definicji rzeczywistego właściciela oraz rozszerzenie zakresu usług niematerialnych (art. 21 ust. 1 pkt 2a) o usługi cyfrowe, SaaS i kryptoaktywa.

## Integracja z polskim ekosystemem: Comarch, Symfonia, enova, KSeF FA(2), CRBR, KAS API, MF e-Deklaracje, WH-OSC

Agent łączy się z głównymi ERPami polskiego rynku: [Comarch ERP Optima Moduł Podatki](https://www.comarch.pl/erp/comarch-erp-optima/) (lider MŚP, walidacja UPO z ponad 90 krajami, generacja IFT-1R/IFT-2 i CIT-10Z), Comarch ERP XL Moduł WHT (Enterprise, wielofirmowy), [Symfonia Podatki Zagraniczne](https://www.symfonia.pl/), [enova365 Podatki Zagraniczne](https://www.enova.pl/) (wielowalutowa z fixingiem NBP), InsERT Subiekt nexo Pro z modułem WHT, SAP S/4HANA Polish Localization Tax (Volkswagen Poznań, BMW Wrocław, Stellantis Tychy, Bosch Mirków, Mercedes Jawor, LG Wrocław - generacja CIT-10Z dla grupy z konsolidacją IP-Box, dywidend i odsetek), Asseco Softlab Moduł Podatki Zagraniczne (farmacja i FMCG), WAPRO Fakir z modułem WHT, ifirma.pl oraz Mastermaq Domínio Polska.

Integracja podatkowa obejmuje KSeF API z certyfikatem (CenCert, Szafir, EuroCert) dla pobierania faktur FA(2), API CRBR (Ministerstwo Sprawiedliwości) dla testu Beneficial Owner, tabelę ponad 90 UPO z MF, bramkę MF e-Deklaracje (IFT-1R, IFT-2, CIT-10Z, WH-OSC, MDR-1/MDR-3/MDR-4 z podpisem kwalifikowanym), API KAS dla weryfikacji nierezydenta oraz listy sankcyjne UE/USA/ONZ dla AML/CFT. Audit trail jest kompatybilny z KAS (krzyżowo z KSeF FA(2), JPK_V7M oraz IFT-1R/IFT-2), KIS (interpretacje), MF (mechanizm pay & refund i WH-WOP), biegłym rewidentem PIBR (KSRF 250/320/540), GIIF (AML), UODO (RODO), WSA/NSA oraz Sądem Rejonowym w sprawach KKS.

--- Agent przygotowania audytu HR ---
> Event-driven przygotowanie audytu HR: pakiety dowodowe IDW PS 980, dokumentacja ZUS-kontroli, eksport RCPD RODO art. 30, mapa ryzyka Kodeks Pracy art. 18-3a oraz AGG.

Audyt HR w polskiej firmie nie zawodzi z powodu braku wiedzy fachowej. Procedury są zdefiniowane, polityki uchwalone, regulamin pracy obowiązuje. Brakuje dowodów, że są stosowane w praktyce - i właśnie tego szukają inspektorzy PIP, UODO i ZUS oraz biegli rewidenci ESRS S1. Kontrola PIP może wymagać natychmiastowego dostępu do akt osobowych, ewidencji czasu pracy (art. 149 KP), szkoleń BHP i regulaminu antymobbingowego. UODO żąda rejestru czynności przetwarzania (RCP) z mapowaniem na art. 88 RODO. Komisja Antymobbingowa wymaga protokołów postępowań i dokumentacji konsultacji ze związkami zawodowymi. Każdy z tych dokumentów musi być znajdowalny w 4 godziny, nie w 3 tygodnie.

## Kontrola PIP to grzywna do 30 000 zł, a do tego sankcje UODO sięgające 4% obrotu

Naruszenia praw pracowniczych mogą skutkować grzywną PIP do 30 000 zł wg art. 281 Kodeksu Pracy, a w przypadku złośliwego naruszenia praw pracownika - odpowiedzialnością karną z art. 218 Kodeksu Karnego. Dla typowej polskiej firmy średniej (300-1000 pracowników) oznacza to: każde wykryte naruszenie obowiązków antymobbingowych (art. 94-3 KP), brak ewidencji czasu pracy (art. 149 KP), brak konsultacji ze związkami zawodowymi (Ustawa z 23.05.1991) lub niewdrożony kanał zgłoszeń sygnalistów (Ustawa z 14.06.2024) generuje ryzyko mandatu, a do tego roszczenia pracownicze w sądzie pracy z 3-letnim okresem przedawnienia.

UODO dokłada osobny wektor: za naruszenie obowiązków RODO art. 88 (dane pracownicze) sankcja sięga 4% obrotu globalnego lub 20 mln EUR - którakolwiek wartość wyższa. W praktyce dla polskiej spółki z grupy międzynarodowej oznacza to dziesiątki milionów złotych ryzyka. Dochodzi do tego implementacja Dyrektywy Pay Transparency 2023/970 do 7.06.2026 - obowiązek corocznego raportu luki płacowej dla pracodawców ≥100 pracowników, plan naprawczy dla luk powyżej 5% i prawo kandydatów do informacji o widełkach płacowych. Brak raportu = roszczenia pracownicze o wyrównanie wynagrodzeń wstecz oraz sankcje administracyjne PIP w polskiej ustawie wdrażającej.

Forrester TEI (październik 2025) szacuje koszt ręcznego zbierania dowodów audytowych na 980 godzin rocznie dla typowej organizacji średniej - praktycznie pełen etat na samą logistykę dowodów. W polskim kontekście dochodzi specyfika: kontrola PIP zapowiadana z 7-dniowym wyprzedzeniem, kontrola UODO z 30-dniowym, kontrola ZUS od natychmiastowej do 7 dni. Jeśli akta osobowe są rozproszone między Comarch ERP HR, Symfonia Kadry i Płace, enova365, papierowe teczki personalne i archiwum w drugiej lokalizacji, ryzyko przekroczenia terminów odpowiedzi jest bardzo realne.

## Cały audyt HR sprowadza się do 15 powtarzalnych etapów

Polski audyt HR wymaga aż 15 etapów deterministycznych, bo regulacje nakładają się warstwami. Kodeks Pracy obejmuje zakaz dyskryminacji (art. 18-3a) oraz obowiązki pracodawcy wraz z przeciwdziałaniem mobbingowi (art. 94-94(3)). Do tego dochodzą: Ustawa o ochronie sygnalistów z 14.06.2024 (z karą do 1 mln zł za brak procedur), RODO art. 88 wraz z Ustawą o ochronie danych osobowych z 10.05.2018, Ustawa o ZFŚS dla pracodawców ≥50 pracowników, Ustawa o związkach zawodowych z 23.05.1991 z konsultacjami 30-dniowymi, dyrektywa Pay Transparency 2023/970 (wdrożenie do 7.06.2026) oraz ESRS S1 Workers w raportowaniu CSRD od roku obrotowego 2025.

Konkretny scenariusz w polskiej operacji: zakład produkcyjny z 600 pracownikami, 3 zakładowe organizacje związkowe, ZFŚS aktywny, Komisja Antymobbingowa, kanał sygnalistów, 12% kobiet na stanowiskach kierowniczych. Trzy tygodnie przed planową kontrolą PIP (zapowiedź z 7-dniowym wyprzedzeniem) dział compliance otrzymuje katalog 47 wymagań dowodowych. HR ma dostarczyć potwierdzenia szkoleń BHP i antymobbingowych dla 600 osób, IT dokumentację kontroli dostępu do danych pracowniczych, dział kadr ewidencję czasu pracy z RCP, dział płac dokumentację ZFŚS, prawnik regulamin pracy z konsultacjami związkowymi.

W [Decision Layer](/pl/decision-layer/) każdy z tych 15 etapów to decyzja regułowa (poziom R) lub automatyczna (poziom A). Mapowanie wymagań na systemy źródłowe jest deterministyczne: szkolenia BHP w Comarch ERP HR, ewidencja czasu w RCP, dokumenty ZFŚS w DMS, akta osobowe w Symfonia. Tylko jedna decyzja jest ludzka (poziom H): weryfikacja przez Compliance Officera lub Inspektora Ochrony Danych, czy działanie naprawcze zaadresowało przyczynę źródłową, nie tylko objaw. Reszta jest maszynowo odtwarzalna i audytowalna przez PIP, UODO, ZUS i biegłych rewidentów ESRS.

## Integracja z polskim ekosystemem kadrowym

Logika agenta integruje się z polskimi systemami HR poprzez API: [Comarch ERP HR](https://www.comarch.pl/erp/) (lider w MŚP), [Symfonia Kadry i Płace](https://www.symfonia.pl/) (mocny w średnich firmach), [enova365 Kadry i Płace](https://www.enova.pl/) (przemysł i handel), Asseco WAPRO HR oraz Sage Symfonia Kadry i Płace. Dla polskich oddziałów grup międzynarodowych: SAP SuccessFactors Polska, Workday HCM, Personio Polska. Dane z systemów są mapowane na wymagania audytowe PIP, UODO, ZUS oraz taksonomię ESRS S1 Workers.

Pakiety dowodowe są generowane ze znacznikiem czasu, hashem źródłowym i pełną identyfikowalnością do dokumentu źródłowego - rewizyjność jest produktem ubocznym czystego procesu, nie dodatkową warstwą kontroli. Dla polskich firm z matką w Niemczech (Volkswagen Poznań, Stellantis Tychy, Bosch Wrocław) lub innych krajach UE agent generuje raporty równolegle: lokalnie zgodne z Kodeksem Pracy i UODO, raportowanie macierzowe pod ESRS S1 dla konsolidacji w siedzibie. Każda zmiana regulaminu pracy lub wynagradzania uruchamia automatycznie konsultacje ze związkami zawodowymi (Ustawa z 23.05.1991, 30 dni na opinię) z udokumentowanym protokołem - co dla biegłego rewidenta ESRS jest dowodem działającego dialogu społecznego (ESRS S1-3).

Dla oficera compliance i Inspektora Ochrony Danych zmienia się rola: mniej operacyjnego polowania na dokumenty, więcej strategicznego sterowania ryzykiem. Pytanie przesuwa się z "Czy mamy wszystkie dowody na kontrolę PIP?" na "Czy nasze cele kontrolne są skuteczne, czy luka płacowa wynosi poniżej 5%, czy procedura sygnalistów chroni zgłaszających?". To są pytania, które inspektorzy PIP, UODO oraz biegli rewidenci ESRS naprawdę chcą zadać - i na które polska firma powinna umieć odpowiedzieć bez trzytygodniowego pośpiechu i ryzyka grzywny do 30 000 zł, a do tego sankcji UODO do 4% obrotu.

--- Agent zapisu na świadczenia ---
> Zapisy na świadczenia pracownicze (PPK, ZFŚS): walidacja uprawnień, kalkulacja składek i deklaracje ZUS DRA, zgodne z KP i RODO.

Zapis na świadczenia pracownicze w polskiej firmie nie zawodzi z powodu braku oferty. PPK od 4.10.2018 jest prawnie obowiązkowy z autozapisem 18-55 lat, ZFŚS dla pracodawców >50 pracowników jest unormowany Ustawą z 4.03.1994, a opieka medyczna grupowa, Multisport, karty żywieniowe i ubezpieczenia życiowe są standardem rynkowym. Co zawodzi, to proces - i właśnie dlatego 86 procent pracowników w Polsce ma dostęp do świadczeń, a regularnie korzysta z nich tylko 48 procent. Przy 1500 pracownikach i pięciu kategoriach świadczeń to setki pojedynczych operacji w ciągu kilku tygodni: weryfikacja autozapisu PPK z PFR ICRT, walidacja kryterium socjalnego dla ZFŚS, kalkulacja składek ZUS DRA, zgody RODO na dane zdrowotne, synchronizacja z Medicover, BenefitNet i Edenred.

## Zaniedbanie świadczeń to grzywna PIP do 30 000 zł, a do tego odsetki ZUS 12,75 procent rocznie

Niewdrożenie autozapisu PPK zgodnie z Ustawą z 4.10.2018 generuje sankcje KNF i odpowiedzialność karną zarządu. Brak składki pracodawcy 1,5% PR jest naruszeniem obowiązku ustawowego z odsetkami 12,75% p.a. od ZUS. Niewystawiony regulamin ZFŚS dla pracodawców >50 pracowników może skutkować grzywną PIP do 30 000 zł (art. 281 Kodeksu Pracy). Brak konsultacji ze związkami zawodowymi przy zmianach regulaminu świadczeń (Ustawa z 23.05.1991, 30 dni na opinię) prowadzi do nieważności zmian.

UODO dokłada osobny wektor: za naruszenie RODO art. 88 (dane pracownicze) lub art. 9 (dane zdrowotne przy zapisie na opiekę medyczną) sankcja sięga 4% obrotu globalnego lub 20 mln EUR. W praktyce dla polskiej spółki z grupy międzynarodowej oznacza to dziesiątki milionów złotych ryzyka. Zgody pracowników na przetwarzanie danych zdrowotnych dla pakietu Medicover, LUX MED czy Enel-Med muszą być udokumentowane jako osobne checkboxy z prawem wycofania - generyczna klauzula w umowie o pracę nie wystarczy.

Dochodzi specyfika 2026: Polski Lad 2.0 wprowadził składkę zdrowotną 9% bez odliczenia od PIT. 30-krotność prognozowanego wynagrodzenia 234 720 zł limituje składki emerytalne i rentowe powyżej tej kwoty. Limity zwolnień podatkowych dla świadczeń z ZFŚS (bony do 2000 zł rocznie, zapomoga do 1000 zł, wczasy pod gruszą) wymagają precyzyjnej ewidencji per pracownik - przekroczenie generuje obowiązek PIT-11 i ryzyko korekty. Kalkulacja błędna o 50 zł na pracownika przy 1500 osobach to 75 000 zł rocznego błędu, a do tego odsetki ZUS.

## Cały zapis na świadczenia sprowadza się do 14 powtarzalnych etapów

Polski zapis na świadczenia wymaga aż 14 etapów deterministycznych, bo regulacje nakładają się warstwami. Ustawa o PPK z 4.10.2018 reguluje autozapis 18-55 lat: składka pracodawcy 1,5% jest obowiązkowa, dobrowolna część pracownika dokłada kolejne 1,5%, a opt-out kontrolowany jest co 4 lata. Ustawa o PPE z 20.04.2004 daje alternatywę - program z minimalną składką 3,5% zwalnia z PPK. Ustawa o ZFŚS z 4.03.1994 nakłada na pracodawców >50 pracowników odpis 37,5% przeciętnego wynagrodzenia, regulamin uzgodniony ze związkami i kryterium socjalne. Kodeks Pracy art. 94 pkt 8 obliguje do zaspokajania potrzeb socjalnych. Ustawa o systemie ubezpieczeń społecznych z 13.10.1998 wymaga deklaracji ZUS (DRA, RCA i RZA) do 15. dnia kolejnego miesiąca. Dane pracownicze przy zapisie na świadczenia zdrowotne reguluje RODO (art. 88 oraz art. 9).

Konkretny scenariusz w polskiej operacji: zakład produkcyjny z 800 pracownikami, 3 zakładowe organizacje związkowe, ZFŚS aktywny z odpisem 37,5%, pakiet medyczny Medicover dla 600 pracowników z możliwością rozszerzenia na rodzinę, karty Multisport dla 400 osób, bony żywieniowe Edenred 250 zł/mc, ubezpieczenie życiowe grupowe PZU. W styczniu 2026 zaczyna się okno enrollment - HR ma 6 tygodni na: autozapis nowych pracowników do PPK z rejestracją w PFR ICRT, walidację 200 osób przekraczających próg wieku 55 lat, opt-out 50 pracowników rezygnujących z PPK, weryfikację 400 zgód RODO dla rodzin objętych pakietem medycznym, kalkulację składek ZUS DRA dla 800 pracowników z różnymi pakietami świadczeń oraz synchronizację z PFR Portal PPK, systemem Płatnik i interfejsami dostawców (Medicover, BenefitNet, Edenred).

W [Decision Layer](/pl/decision-layer/) każdy z tych 14 etapów to decyzja regułowa (poziom R) lub automatyczna (poziom A). Mapowanie uprawnień na PPK jest deterministyczne: wiek 18-55 = autozapis, 55-70 = na wniosek, >70 = brak. Kryterium socjalne ZFŚS jest deterministyczne: dochód rodziny per osoba poniżej progu = pełne świadczenie, powyżej = redukcja. Kalkulacja składek ZUS DRA jest deterministyczna: emerytalna 9,76% po stronie pracodawcy i tyle samo po stronie pracownika do limitu 234 720 zł rocznie, rentowa 1,5% i 6,5%, chorobowa 2,45%, wypadkowa ustalana indywidualnie według PKD. Tylko jedna decyzja jest ludzka (poziom H): potwierdzenie wyborów świadczeń przez pracownika z wyraźną zgodą RODO na dane zdrowotne (art. 88 oraz art. 9). Reszta jest maszynowo odtwarzalna i audytowalna przez PIP, ZUS, UODO i PFR Portal PPK.

## Integracja z polskim ekosystemem świadczeń

Logika agenta integruje się z polskimi systemami HR przez API: [Comarch ERP HR](https://www.comarch.pl/erp/) (lider w MŚP z natywną integracją PFR Portal PPK), [Symfonia Kadry i Płace](https://www.symfonia.pl/) (mocny w średnich firmach), [enova365 Kadry i Płace](https://www.enova.pl/) (przemysł i handel), Sage Symfonia oraz Asseco WAPRO HR - każdy z dedykowanym modułem PPK. Dla polskich oddziałów grup międzynarodowych: SAP SuccessFactors Polska, SAP HCM, Workday HCM, Personio Polska. Po stronie infrastruktury państwowej: PFR Portal PPK z PPK ICRT (rejestracja uczestników), system Płatnik dla deklaracji ZUS (DRA, RCA, RZA), aplikacja mobilna mZUS dla pracowników oraz NFZ Portal dla Karty EKUZ. Po stronie dostawców świadczeń: Medicover B2B API, LUX MED Pacjent24, Enel-Med, Polmed, BenefitNet (Multisport - Benefit Systems), Edenred (karty żywieniowe), Sodexo (bony) i PZU (ubezpieczenie życiowe grupowe).

Pakiety dowodowe są generowane ze znacznikiem czasu, hashem źródłowym i pełną identyfikowalnością do dokumentu źródłowego - rewizyjność jest produktem ubocznym czystego procesu, nie dodatkową warstwą kontroli. Dla polskich firm z matką w Niemczech (Volkswagen Poznań, Stellantis Tychy, Bosch Wrocław) lub innych krajach UE agent generuje raporty równolegle: lokalnie zgodne z Ustawą o PPK, ZFŚS i ZUS DRA, raportowanie macierzowe pod ESRS S1 Workers dla konsolidacji w siedzibie. Każda zmiana regulaminu ZFŚS lub kryteriów socjalnych uruchamia automatycznie konsultacje z organizacjami związkowymi (Ustawa z 23.05.1991, 30 dni na opinię) z udokumentowanym protokołem.

Dla działu HR i Compliance Officera zmienia się rola: mniej operacyjnego administrowania zapisami, więcej strategicznego sterowania portfelem świadczeń. Pytanie przesuwa się z "Czy złożyliśmy wszystkie deklaracje ZUS DRA na czas?" na "Czy nasz portfel świadczeń wzmacnia retencję, czy 80 procent pracowników faktycznie korzysta z opieki medycznej, czy struktura PPE może zwolnić nas z PPK?". To są pytania, które zarząd, Inspektor Ochrony Danych i biegły rewident ESRS S1 naprawdę chcą zadać - i na które polska firma powinna umieć odpowiedzieć bez trzytygodniowego pośpiechu i ryzyka grzywny PIP do 30 000 zł, odsetek ZUS 12,75% rocznie oraz sankcji UODO do 4% obrotu lub 20 mln EUR za naruszenia ochrony danych przy zapisie na opiekę medyczną.

--- Agent selekcji kandydatów ---
> Selekcja kandydatów: parsing CV, monitoring uprzedzeń i audytowalna shortlista, zgodna z RODO art. 22 oraz EU AI Act Aneks III.

Selekcja kandydatów w polskiej firmie nie zawodzi z powodu braku aplikacji. Przy 200, 400, czasem 800 CV na jedno stanowisko problem jest odwrotny - rekruterzy, którzy po pięćdziesiątym CV nie stosują już tych samych kryteriów co przy pierwszym, działy merytoryczne pytające po trzech tygodniach o shortlistę, ATS-y wypełnione zduplikowanymi profilami z Pracuj.pl, OLX Praca i LinkedIn. Pokusa, aby tę masę przepuścić przez ML-screening, jest oczywista - i regulacyjnie najbardziej ryzykowna decyzja, jaką polski dział HR może obecnie podjąć.

## Każdy automat rekrutacyjny w Polsce to system wysokiego ryzyka EU AI Act - obowiązki od 2 sierpnia 2026 r.

EU AI Act 2024/1689 sklasyfikował systemy AI do rekrutacji i selekcji kandydatów jako wysokie ryzyko - Aneks III pkt 4 lit. a. Ta klasyfikacja pozostaje w mocy. Zgodnie z obowiązującym prawem obowiązki wysokiego ryzyka mają zastosowanie od 2 sierpnia 2026 r.; na mocy wstępnego porozumienia Digital Omnibus z 7 maja 2026 r. mają zostać przesunięte na 2 grudnia 2027 r. (formalne przyjęcie wciąż w toku, stan na czerwiec 2026 r.). Prawdopodobny dodatkowy czas warto wykorzystać na rzetelne przygotowanie, bo zbudowanie udokumentowanej architektury decyzyjnej, oceny zgodności (art. 43), wpisu do rejestru EU (art. 49), oceny skutków praw podstawowych FRIA (art. 27), polityki zarządzania ryzykiem (art. 9), testowania jakości danych pod kątem uprzedzeń (art. 10), automatycznego logowania minimum 6 miesięcy (art. 12), przejrzystości wobec kandydatów (art. 13), Human-in-the-Loop (art. 14) oraz konsultacji z organizacją związkową (art. 26 ust. 7) trwa miesiącami. Sankcje za naruszenia sięgają 35 mln EUR lub 7% obrotu globalnego.

Polski Kodeks Pracy dokłada osobny wektor ryzyka. Art. 18-3a stanowi zakaz dyskryminacji bezpośredniej i pośredniej z odwróconym ciężarem dowodu - przy zarzucie dyskryminacji to pracodawca musi udowodnić, że kierował się obiektywnymi kryteriami. Art. 22-1 zawiera zamknięty katalog danych osobowych kandydata: imię, nazwisko, data urodzenia, dane kontaktowe, wykształcenie, kwalifikacje zawodowe, przebieg zatrudnienia. Wszystko poza tym katalogiem - zdjęcie, stan cywilny, narodowość, wyznanie, dane biometryczne - wymaga wyraźnej zgody i powinno zostać zanonimizowane przed scoringiem ML. PIP może nałożyć grzywnę do 30 000 zł za każde naruszenie (art. 281 KP), UODO sięga 4% obrotu globalnego lub 20 mln EUR za naruszenia RODO art. 22 (zakaz wyłącznie zautomatyzowanych decyzji), RPO i Sądy Pracy prowadzą postępowania antydyskryminacyjne, a Pełnomocnik Rządu ds. Równego Traktowania nadzoruje implementację Ustawy o równym traktowaniu z 3.12.2010.

Dochodzi specyfika 2026: dyrektywa Pay Transparency 2023/970/UE od 7 czerwca 2026 wprowadza obowiązek widełek płacowych w ogłoszeniach i zakaz pytania kandydata o dotychczasowe wynagrodzenie. Ustawa o sygnalistach z 14 czerwca 2024 chroni kandydatów zgłaszających dyskryminację. Ustawa o rehabilitacji zawodowej z 27 sierpnia 1997 obliguje pracodawców >25 pracowników do 6% wskaźnika zatrudnienia osób z niepełnosprawnością - niewypełnienie generuje miesięczną składkę sankcyjną PFRON. AI Literacy (EU AI Act art. 4) jest obowiązkowy dla rekruterów już od 2 lutego 2025.

## Dlaczego sprawa Mobley v. Workday i badanie UW 2024 są w polskim kontekście kluczowe

Sprawa Mobley v. Workday (Sąd Federalny USA, 2024) dopuściła pozew zbiorowy przeciwko dostawcy AI rekrutacyjnego - nie pracodawcy, lecz dostawcy oprogramowania - za systematyczną dyskryminację ze względu na wiek, pochodzenie i niepełnosprawność. Badanie University of Washington (Bertsimas et al., 2024) wykazało, że w ML-screeningu CV nazwiska kojarzone z białym pochodzeniem były faworyzowane w 85% przypadków, a w niektórych grupach zawodowych czarnoskórzy mężczyźni byli poszkodowani w 100% przypadków testowych. To nie są hipotetyczne scenariusze - to toczące się postępowania i opublikowane wyniki badań. W polskim kontekście Kodeks Pracy art. 18-3b dodaje odwrócony ciężar dowodu: kandydat zgłaszający dyskryminację musi tylko uprawdopodobnić zarzut, pracodawca musi go skutecznie obalić.

Większość firm stosujących AI w screeningu nie wie, jak ich algorytmy oceniają. Nie zna wag. Nie potrafi wyjaśnić, dlaczego kandydat A jest na shortliście, a kandydat B nie. Gdy score mówi 72 i nikt nie wie, czy to z powodu brakujących kompetencji językowych, przerwy w CV, czy niedopasowania do nazwy szkoły - system jest regulacyjnie bezwartościowy. Przed Sądem Pracy z odwróconym ciężarem dowodu firma nie udowodni obiektywnych kryteriów, jeśli nie potrafi prześledzić, dlaczego model dał taki, a nie inny score.

## Cała selekcja kandydatów sprowadza się do 15 powtarzalnych etapów

W odróżnieniu od standardowego ML-screeningu, polska selekcja kandydatów zgodna z Kodeksem Pracy, RODO i EU AI Act wymaga 15 etapów deterministycznych. Pierwszy etap - walidacja zgodności ogłoszenia z dyrektywą Pay Transparency 2023/970 (widełki płacowe, brak pytań o dotychczasowe zarobki). Drugi - parsing CV z mapowaniem na zamknięty katalog danych KP art. 22-1 (wszystko poza katalogiem zostaje zanonimizowane lub wymaga wyraźnej zgody). Trzeci - walidacja podstawy prawnej przetwarzania (RODO art. 6 oraz art. 9). Czwarty - blind screening: anonimizacja imienia, nazwiska, zdjęcia, daty urodzenia, płci, narodowości i adresu przed scoringiem. Piąty - silnik reguł filtruje kryteria K.O. (uprawnienia, języki, wykształcenie, doświadczenie minimalne) - bez ML, bez czarnej skrzynki. Szósty - dopiero teraz wchodzi parsing AI z 6-8 udokumentowanymi ocenami cząstkowymi per wymaganie (kompetencje techniczne, języki, doświadczenie sektorowe, certyfikaty). Każda ocena uzasadniona osobno z odniesieniem do konkretnego kryterium z ogłoszenia.

Konkretny scenariusz w polskiej operacji: zakład produkcyjny z 1500 pracownikami w Wielkopolsce, otwarte 12 stanowisk inżynierskich, 600 aplikacji w 4 tygodnie z Pracuj.pl, OLX Praca i LinkedIn. HR ma 3 tygodnie na: walidację zgodności ogłoszeń z Pay Transparency, parsing 600 CV, anonimizację, deterministyczny filtr kryteriów K.O. (uprawnienia SEP, certyfikaty branżowe), AI-scoring z uzasadnieniem cząstkowym, statystyczny monitoring uprzedzeń (4/5-Rule, statistical parity, disparate impact), walidację kwoty 6% osób z niepełnosprawnością (PFRON), shortlistę z 30 kandydatami, decyzje rekruterów z udokumentowanym uzasadnieniem, powiadomienia o odrzuceniu zgodne z RODO art. 13-14, retencję 6 miesięcy, pakiet dowodowy dla ewentualnej kontroli PIP, UODO, RPO, EU AI Office.

W [Decision Layer](/pl/decision-layer/) każdy z tych 15 etapów to decyzja regułowa (poziom R), automatyczna z parsing AI (poziom A) lub ludzka (poziom H). Filtr kryteriów K.O. jest deterministyczny - silnik reguł, nie ML. Walidacja zamkniętego katalogu KP art. 22-1 jest deterministyczna. Anonimizacja zmiennych dyskryminujących jest deterministyczna. Statystyczny monitoring uprzedzeń jest deterministyczny - 4/5-Rule daje binarny próg. Tylko dwie decyzje są ludzkie (poziom H): przegląd shortlisty przez rekrutera z możliwością modyfikacji wagi kryteriów oraz dokumentacja decyzji z uzasadnieniem dla każdego kandydata. Reszta jest maszynowo odtwarzalna i audytowalna przez PIP, UODO, RPO, EU AI Office i Sądy Pracy.

## Integracja z polskim ekosystemem rekrutacyjnym

Logika agenta integruje się z polskimi systemami ATS i HR przez API: [eRecruiter (HRtec)](https://erecruiter.pl/) jako lider polskiego rynku z natywną integracją Pracuj.pl i OLX Praca, [HRappka](https://hrappka.pl/) oraz Tetka HR Rekrutacja dla MŚP, JoinPro Polska dla średnich i dużych firm, [Comarch ERP HR](https://www.comarch.pl/erp/) (lider w MŚP), Symfonia ERP HR, enova365 Kadry i Płace (Soneta - przemysł i handel) oraz Asseco WAPRO HR - każdy z modułem rekrutacyjnym. Dla polskich oddziałów grup międzynarodowych: SAP SuccessFactors Recruiting Polish Localization (Volkswagen Poznań, Stellantis Tychy, BMW Wrocław, Bosch Wrocław), Workday HCM Polska, Personio Polska. Po stronie kanałów sourcingu: Pracuj.pl ATS API jako dominująca platforma rekrutacji w Polsce, OLX Praca, LinkedIn Talent Solutions Polska, Indeed Polska.

Pakiety dowodowe są generowane ze znacznikiem czasu, hashem źródłowym i pełną identyfikowalnością do dokumentu źródłowego - rewizyjność jest produktem ubocznym czystego procesu, nie dodatkową warstwą kontroli. Każda decyzja rekrutera jest powiązana z konkretnym kryterium z ogłoszenia (a nie generycznym "brak dopasowania"), a wersja modelu AI wraz z promptem i parametrami jest logowana razem z ocenami cząstkowymi i wynikiem monitoringu uprzedzeń. Dla kontroli PIP (art. 281 KP - do 30 000 zł), UODO (do 4% obrotu lub 20 mln EUR), RPO (postępowania antydyskryminacyjne), Sądów Pracy (odwrócony ciężar dowodu - Kodeks Pracy art. 18-3b), EU AI Office (od 2.08.2026) i PFRON (kwota 6% osób z niepełnosprawnością): pakiet dowodowy gotowy w 4 godziny zamiast 3 tygodni.

Candidate Screening Agent jest często pierwszym agentem wysokiego ryzyka, którego polska firma uruchamia produkcyjnie. Tym samym wymusza budowę infrastruktury, której żaden agent sam nie uzasadniłby, ale z której korzysta każdy kolejny agent wysokiego ryzyka - Performance Review Documentation Agent, Merit Cycle Governance Agent, Promotion Process Agent. Silnik monitoringu uprzedzeń (4/5-Rule, statistical parity, disparate impact) jest reużywany. Udokumentowana procedura scoringu z uzasadnieniem cząstkowym staje się standardem. Komunikacja odmowna zgodna z RODO art. 13-14 i Kodeksem Pracy art. 18-3a ustanawia szablony stosowane w całej komunikacji z pracownikami i kandydatami.

Dla działu HR i Compliance Officera zmienia się rola: mniej operacyjnego skanowania CV, więcej strategicznego sterowania portfelem rekrutacyjnym. Pytanie przesuwa się z "Czy zdążymy ze shortlistą do końca tygodnia?" na "Czy nasza struktura selekcji wytrzyma kontrolę PIP, UODO, RPO i EU AI Office, czy 6% wskaźnik PFRON jest spełniony, czy widełki płacowe odzwierciedlają obiektywne kryteria niezwiązane z płcią?". To są pytania, które zarząd, Inspektor Ochrony Danych i biegły rewident ESRS S1 naprawdę chcą zadać - i na które polska firma powinna umieć odpowiedzieć bez trzytygodniowego pośpiechu i ryzyka grzywny PIP do 30 000 zł, sankcji UODO do 4% obrotu lub 20 mln EUR, odpowiedzialności cywilnej za dyskryminację (Kodeks Cywilny art. 471), a do tego sankcji EU AI Act do 35 mln EUR lub 7% obrotu globalnego za naruszenia obowiązków dla systemów wysokiego ryzyka.

--- Agent monitorowania uprawnień ---
> Monitorowanie cyklicznych uprawnień: szkolenia BHP wstępne i okresowe, SEP/UDT, IODO, AML zgodnie z Kodeksem Pracy art. 207-226 i RODO art. 32+39 - audytowalna ścieżka odnowień dla PIP, UODO, UDT.

Polska firma farmaceutyczna w Tarchominie odkrywa, że Osoba Wykwalifikowana - jedyna w zakładzie - od trzech tygodni nie odnowiła certyfikatu GMP. Bez ważnej kwalifikacji nie może dokonać zwolnienia serii. W systemie EU GMP to nie formalność: nawet jeśli wszystkie testy analityczne przeszły pozytywnie, zwolnienie serii bez ważnego certyfikatu jest prawnie nieważne. Linia produkcyjna stoi. Nie z powodu problemu jakościowego. Z powodu przeoczonego terminu w arkuszu kalkulacyjnym. Jednocześnie Państwowa Inspekcja Pracy w czasie rutynowej kontroli stwierdza, że 47 pracowników magazynu nie ma aktualnych szkoleń BHP okresowych. Dwa zdarzenia, jedna przyczyna: administracyjna struktura, która zawodzi przy skalowaniu.

## Wygasłe uprawnienie to kary do 30 000 zł za każdego pracownika - i blokada operacyjna

Kodeks Pracy art. 207 zobowiązuje pracodawcę do zapewnienia bezpiecznych i higienicznych warunków pracy - to nie sugestia, lecz obowiązek bezwzględny. Art. 211 nakłada na pracownika obowiązek przestrzegania zasad BHP, w tym ukończenia szkoleń. Art. 226-227 wymagają oceny ryzyka zawodowego i środków ochrony. Rozporządzenie Ministra Gospodarki i Pracy z 27.07.2004 określa szczegółowo: szkolenie wstępne ogólne dla każdego nowego pracownika, instruktaż stanowiskowy oraz szkolenia okresowe co 1, 3, 5 lub 6 lat zależnie od stanowiska - pracownicy biurowi co 6 lat, robotnicy co 3 lata (a w pracach szczególnie niebezpiecznych co 1 rok), pracodawcy i kierownicy co 5 lat.

PIP może nałożyć grzywnę do 30 000 zł za każde naruszenie (art. 281 KP) - przy 47 pracownikach magazynu bez aktualnych szkoleń to teoretycznie 1,4 mln zł. Ale to nie wszystko. Ustawa o ochronie przeciwpożarowej z 24.08.1991 i KP art. 209-1 i 209-2 wymagają wyznaczenia i przeszkolenia pracowników do udzielania pierwszej pomocy i ewakuacji - PSP kontroluje udokumentowanie. Ustawa o przeciwdziałaniu praniu pieniędzy z 1.03.2018 (AML/CFT) art. 52 nakłada na podmioty obowiązane (banki, biura rachunkowe, kantory, deweloperzy, prawnicy, notariusze) obowiązek cyklicznych szkoleń - sankcje GIIF do 5 mln zł lub 10% przychodów. UODO (RODO art. 32) za naruszenia środków technicznych i organizacyjnych sięga 4% obrotu globalnego lub 20 mln EUR. UDT (Ustawa o dozorze technicznym z 21.12.2000) wycofuje uprawnienia do obsługi dźwigów, suwnic, podestów ruchomych, urządzeń ciśnieniowych za fałszowanie zaświadczeń.

Dochodzą uprawnienia SEP elektryczne (E1+E2+E3 eksploatacja, D1+D2+D3 dozór - Rozporządzenie z 28.04.2003, ważność 5 lat), uprawnienia farmaceutów (Prawo farmaceutyczne z 6.09.2001 - ciągłe doskonalenie zawodowe co 5 lat, 100 punktów edukacyjnych), uprawnienia odpadowe (Ustawa o odpadach z 14.12.2012), uprawnienia pirotechniczne (Ustawa o materiałach wybuchowych z 21.06.2002). Inspektor Ochrony Danych (IODO) zgodnie z RODO art. 37-39 musi mieć udokumentowane kompetencje i ciągłe doskonalenie - UODO prowadzi rejestr.

## Co naprawdę kosztuje wygasły certyfikat - i czego nie pokazuje arkusz Excel

W branżach regulowanych certyfikaty i licencje zawodowe nie są dodatkami do kariery. Są prawnymi warunkami wykonywania zawodu. Konsekwencje wygaśnięcia różnią się w zależności od branży, ale schemat jest identyczny: natychmiastowa utrata funkcji.

- **Farmacja i chemia.** Bez ważnego certyfikatu GMP brak zwolnienia serii, brak wysyłki. EMA w 2025 roku doprecyzowała, że certyfikaty GDP i GMP po wygaśnięciu nie podlegają przedłużeniu. Trzy krytyczne odchylenia podczas inspekcji wystarczą do wpisu w bazie EudraGMDP - a tym samym do wstrzymania produkcji. Główny Inspektorat Farmaceutyczny (GIF) wycofuje uprawnienia farmaceutów bez aktualnych 100 punktów edukacyjnych co 5 lat.
- **Energetyka.** Bez ważnych uprawnień SEP brak prawa do pracy przy urządzeniach energetycznych. Elektryk z wygasłym E1 to nie tylko kwestia formalna - to ryzyko porażenia, pożaru i odpowiedzialności karnej kierownika za dopuszczenie do pracy bez uprawnień (Kodeks Karny art. 220 - niedopełnienie obowiązków).
- **Logistyka i transport bliski.** Bez aktualnego zaświadczenia UDT operator dźwigu, suwnicy, podestu ruchomego nie może obsługiwać urządzenia. UDT prowadzi rejestr osób z aktualnymi uprawnieniami i kontroluje go losowo.
- **Sektor finansowy.** Instytucje regulowane przez KNF i podmioty obowiązane wg Ustawy AML potrzebują wykwalifikowanych inspektorów AML, oficerów compliance, kontrolerów ryzyka, IODO. Brak szkoleń = sankcje GIIF i KNF, w skrajnym przypadku cofnięcie zezwolenia.

Wspólny mianownik: nie chodzi o karę administracyjną. Chodzi o zdolność operacyjną.

## Arytmetyka zarządzania terminami w polskiej średniej firmie

Weźmy zakład produkcyjny z 1500 pracownikami w Wielkopolsce - chemia, farmacja, energetyka lub logistyka. Na pracownika przypada średnio cztery do sześciu uprawnień obowiązkowych: szkolenie BHP wstępne i okresowe, szkolenie ppoż., w zależności od stanowiska SEP E+D, UDT, AML, IODO, sanitarne, branżowe. To daje od 6000 do 9000 indywidualnych zaświadczeń z różnymi datami wygaśnięcia, wymaganiami odnowienia i regułami eskalacji.

Każdy z tych certyfikatów podlega własnej logice: BHP okresowe co 1/3/5/6 lat zależnie od stanowiska, SEP co 5 lat z egzaminem komisji kwalifikacyjnej, UDT co 5 lub 10 lat zależnie od kategorii urządzenia, AML cykliczne min. 1x rocznie, IODO bezterminowy ale z obowiązkiem ciągłego doskonalenia, ppoż. zależnie od funkcji. Czas wyprzedzenia rezerwacji szkolenia BHP okresowego w polskich ośrodkach (CIOP-PIB i akredytowani prywatni) to 6-8 tygodni. Bez wczesnego alertu termin nie jest możliwy do dotrzymania.

Dział personalny zarządzający tym w Excelu zna dwa stany: przegląd przy 50 pracownikach, lot na oślep przy 500. Typowe punkty złamania są przewidywalne. Rezerwacje szkoleń następują zbyt późno, bo czas wyprzedzenia jest niedoszacowany. Odnowienia są przeoczane, bo terminy leżą w różnych systemach (ERP, LMS, akta osobowe, kalendarze indywidualne). I najniebezpieczniejszy błąd: firma w żadnym momencie nie jest w stanie wiarygodnie powiedzieć, ilu jej pracowników aktualnie posiada potwierdzalnie wszystkie kwalifikacje obowiązkowe - aż do dnia kontroli PIP, PSP, UODO lub UDT.

## Co zmienia agent

Agent nie rozwiązuje problemu przez lepsze arkusze. Rozwiązuje go przez inną architekturę.

**Przypisanie oparte na regułach.** Gdy pracownik obejmuje stanowisko, silnik reguł wyprowadza pełny katalog obowiązkowych uprawnień z Kodeksu Pracy (art. 207 i 226), Rozporządzenia MGiP z 27.07.2004 oraz branżowych aktów wykonawczych. Nie dział personalny decyduje z doświadczenia, które zaświadczenia są istotne - silnik reguł to wyprowadza. Człowiek wchodzi do gry tylko, gdy regulacja się zmienia (np. NIS2 dodaje szkolenia z cyberbezpieczeństwa) i nowe typy uprawnień wymagają walidacji - co jest udokumentowane w protokole konsultacji z radą pracowników (Ustawa z 7.04.2006).

**Stopniowany monitoring terminów.** Każde uprawnienie jest rejestrowane z datą wydania, organem wydającym, datą ważności, wymaganym czasem wyprzedzenia i branżowymi regułami eskalacji. Agent wylicza z tych parametrów konkretne okna działania: kiedy musi być zarezerwowane szkolenie BHP okresowe (6-8 tygodni przed)? Kiedy musi być złożony wniosek do komisji kwalifikacyjnej SEP (3-4 miesiące przed)? Kiedy jest ostateczny termin, zanim zagrożone jest operacyjne użycie pracownika? Przypomnienia są rozsyłane do pracownika, przełożonego i koordynatora BHP w cyklach 90, 60, 30 dni.

**Walidacja autentyczności wobec rejestrów państwowych.** UDT prowadzi rejestr osób z aktualnymi uprawnieniami (API dostępne), Komisje Kwalifikacyjne SEP - rejestry egzaminów, UODO - rejestr Inspektorów Ochrony Danych. Agent automatycznie sprawdza autentyczność zaświadczeń, gdzie API jest dostępne; ścieżka manualna pozostała dla mniejszych organów (np. ośrodki branżowe ppoż., GIF).

**Eskalacja z konsekwencją.** Trzy przypomnienia i brak reakcji - wtedy agent eskaluje do koordynatora BHP, IOD, Compliance Officera lub kierownika ppoż. zależnie od typu uprawnień. Przy uprawnieniach wymaganych prawnie (Kodeks Pracy art. 207 § 2 i art. 211 - obowiązek odsunięcia od pracy) decyzja o blokadzie operacyjnej należy do kierownika zgodnie z [Decision Layer](/pl/decision-layer/), a agent dokumentuje każdy krok w sposób rewizyjny: kiedy przypomniano, kto nie zareagował, jakie działanie zostało podjęte. W przypadku audytu PIP, PSP, UODO, UDT lub GIIF dostarcza to dowód, że firma wypełniła swoje obowiązki organizacyjne (Kodeks Pracy art. 207).

**Proaktywne pozyskanie dofinansowania KFS.** Krajowy Fundusz Szkoleniowy administrowany przez ZUS we współpracy z PUP/WUP zgodnie z Ustawą o promocji zatrudnienia art. 69a-69b finansuje szkolenia priorytetowe (BHP, kompetencje cyfrowe, językowe, branżowe) do 80% kosztów dla MŚP i 100% dla mikroprzedsiębiorstw. Dla średniej firmy 1500 pracowników to setki tysięcy złotych rocznego budżetu, który często pozostaje niewykorzystany. Agent identyfikuje kwalifikujące się szkolenia, generuje wnioski dla PUP i monitoruje rozliczenia.

## Integracja z polskim ekosystemem szkoleń i uprawnień

Logika agenta integruje się z polskimi systemami HR i LMS przez API: [Comarch ERP HR](https://www.comarch.pl/erp/) jako lider w MŚP z natywnym modułem ewidencji szkoleń BHP i terminów uprawnień, Symfonia ERP HR z modułem LMS, enova365 Kadry i Płace (Soneta - przemysł i handel) oraz Asseco WAPRO HR - każdy z modułem szkoleń. Dla polskich oddziałów grup międzynarodowych: SAP SuccessFactors Learning Polish Localization (Volkswagen Poznań, Stellantis Tychy, BMW Wrocław, Bosch Wrocław), Workday Learning Polska, Cornerstone OnDemand Polska, Personio Polska Learning. Dla specjalistycznych obszarów: KnowBe4 Polska (cyberbezpieczeństwo i RODO - uprawnienia IODO), Tetka HR Szkolenia, eLearning24, Mediasi Onyx Szkolenia, JoinPro Polska Learning. Agent łączy się z rejestrami państwowymi: API UDT (uprawnienia operatorskie), Komisje Kwalifikacyjne SEP (eksploatacja i dozór), rejestr IODO przy UODO oraz baza EudraGMDP (GMP/GDP) dla farmacji.

Pakiety dowodowe są generowane ze znacznikiem czasu, hashem źródłowym i pełną identyfikowalnością do dokumentu źródłowego - rewizyjność jest produktem ubocznym czystego procesu, nie dodatkową warstwą kontroli. Dla kontroli PIP (art. 281 KP - do 30 000 zł), PSP (Ustawa o ochronie ppoż.), UODO (RODO do 4% obrotu lub 20 mln EUR), UDT (Ustawa o dozorze technicznym), GIIF (sankcje AML do 5 mln zł), GIF (uprawnienia farmaceutów), KFS (rozliczenia dofinansowania) i biegłego rewidenta ESRS S1 (CSRD): pakiet dowodowy gotowy w 4 godziny zamiast 3 tygodni.

## Infrastruktura, która niesie dalej niż uprawnienia

Silnik monitoringu terminów - rejestracja daty wydania i ważności, kalkulacja czasu wyprzedzenia, stopniowana eskalacja, dokumentacja dowodów, walidacja wobec rejestrów państwowych, integracja z KFS - to nie izolowany moduł. Ten sam wzorzec architektoniczny steruje [Compliance Training Agent](/pl/katalog-agentow-hr/compliance-training-agent/), [Policy Document Agent](/pl/katalog-agentow-hr/policy-document-agent/) oraz [Performance Review Documentation Agent](/pl/katalog-agentow-hr/performance-review-documentation-agent/). Protokół eskalacji przy przeoczonych terminach staje się wzorcem dla każdego agenta, który musi egzekwować terminowe obowiązki regulacyjne - od ważności orzeczeń lekarskich, przez odnowienia umów współpracy, po cykliczne audyty wewnętrzne RODO.

Przez setki cykli odnowienia powstaje obraz danych, którego żadne arkusze nie dostarczą. Które typy uprawnień są systematycznie odnawiane zbyt późno? Które lokalizacje mają chronicznie niskie wskaźniki odnowień (zakłady produkcyjne na wsi vs centrale w Warszawie)? Gdzie odnowienie regularnie nie udaje się z powodu brakujących miejsc szkoleniowych w ośrodkach CIOP-PIB? Te wzorce stanowią podstawę perspektywicznego planowania kadrowego - nie jako model prognostyczny, lecz jako strukturalna analiza powtarzających się wąskich gardeł. Dla zarządu i biegłego rewidenta ESRS S1 (CSRD): raport o szkoleniach i kompetencjach gotowy do badania, z liczbą godzin szkoleniowych per pracownik, wskaźnikiem realizacji obowiązkowych szkoleń (BHP, AML, RODO, ppoż.), wykorzystaniem KFS i karami regulacyjnymi - bez trzytygodniowego pośpiechu i ryzyka grzywny PIP do 30 000 zł za każdego pracownika.

--- Agent benchmarkingu płac ---
> Benchmarking wynagrodzeń: analiza płac, Job Evaluation, transparencja zgodnie z KP art. 18-3a-3c, Dyrektywą UE 2023/970, RODO art. 22+88 i CSRD ESRS S1-10/S1-13/S1-16 dla PIP, GUS, KNF.

Polski oddział międzynarodowej grupy farmaceutycznej w Warszawie publikuje 1 lipca 2026 pierwszy obowiązkowy raport luki płacowej zgodnie z Dyrektywą UE 2023/970. Wynik: w grupie porównawczej "Senior Specialist Quality Assurance" kobiety zarabiają o 7,3% mniej niż mężczyźni. Bez obiektywnego uzasadnienia. Przepisy są jednoznaczne: 6 miesięcy na korektę albo wspólna ocena wynagrodzeń z przedstawicielstwem pracowników. Comp&Ben Manager otwiera Excel. W tabeli przestawnej widać 47 specjalistek i 53 specjalistów. Mediana kobiet: 12 800 zł. Mediana mężczyzn: 13 750 zł. Roczny koszt wyrównania: około 540 000 zł brutto. Ale to nie wszystko - PIP zapowiada kontrolę regulaminu wynagradzania. Sąd Pracy w Warszawie ma już dwa pozwy o dyskryminację w wynagrodzeniu, w których ciężar dowodu spoczywa na pracodawcy.

## Od 2026 ciężar dowodu w sporach płacowych przechodzi na pracodawcę

Kodeks Pracy art. 18-3c jest bezwzględny - prawo do równego wynagrodzenia za pracę jednakową lub o jednakowej wartości. Cztery kryteria oceny (art. 18-3c § 3): kwalifikacje, odpowiedzialność, wysiłek, warunki pracy. Wynagrodzenie obejmuje wszystkie składniki: zasadnicze, premie, dodatki, świadczenia w naturze (samochód, telefon, ZFŚS), opcje na akcje. Naruszenie - roszczenie pracownika o odszkodowanie nie niższe niż minimalne wynagrodzenie (art. 18-3d KP - 4 666 zł brutto/mc 2025) za każdy miesiąc dyskryminacji.

Dyrektywa UE 2023/970 (transpozycja do 7 czerwca 2026) wprowadza pięć fundamentalnych zmian: widełki płacowe w ogłoszeniach stają się obowiązkowe (zakaz pytania o historię wynagrodzeń), każdy pracownik ma prawo do informacji o swoim wynagrodzeniu i średnich w grupie porównawczej w 60 dni, firmy >100 pracowników raportują lukę nieskorygowaną i skorygowaną corocznie (>250) lub co 3 lata (100-249), przy luce >5% bez obiektywnego uzasadnienia pracodawca ma 6 miesięcy na korektę albo wspólną ocenę wynagrodzeń z Radą Pracowników i Związkami Zawodowymi. Po piąte - rewolucja procesowa - w sporach sądowych o dyskryminację w wynagrodzeniu ciężar dowodu spoczywa na pracodawcy (KP art. 18-3d). Bez udokumentowanego mapowania stanowisk na grupy porównawcze, mediany rynkowej z badań Sedlak & Sedlak / Mercer Polska / WTW Polska i obiektywnych kryteriów różnicowania (art. 78 KP) - obrona w sądzie staje się niemożliwa.

Sankcje są poważne. Polski projekt transpozycji przewiduje grzywny do 3% obrotu rocznego dla firm >250 pracowników za niewypełnienie obowiązków raportowych. PIP nakłada grzywnę do 30 000 zł (art. 281 KP) za naruszenia regulaminu wynagradzania (art. 77-2 KP). UODO za naruszenia RODO art. 88 sięga 4% obrotu globalnego lub 20 mln EUR. KNF dla banków wymaga zgodności z EBA/GL/2021/04 - polityka wynagrodzeń, identyfikacja Material Risk Takers, ujawnienia w Pillar 3.

## Czego nie pokazuje arkusz Excel - granularność wymagana przez 2023/970

Ogólna luka płacowa w Polsce według GUS (Z-12 2024) wynosi około 4,5% nieskorygowanej - statystyka makro, bezużyteczna dla raportu 2023/970. Dyrektywa wymaga luki w obrębie grupy porównawczej, wyznaczonej przez rodzinę stanowisk, poziom kariery i lokalizację. Dla średniej firmy 1500 pracowników z 80 stanowiskami daje to 80 grup porównawczych, każda z osobnym obliczeniem nieskorygowanym i skorygowanym.

W większości działów Comp&Ben praca wygląda tak: raz w roku przychodzi badanie Sedlak & Sedlak, ktoś otwiera Excel, porównuje pozycję po pozycji, liczy compa-ratio, buduje tabele przestawne, koryguje niespójności w mapowaniu z poprzedniego roku, traci trzy tygodnie - i na końcu powstaje fotografia już nieaktualna w momencie zakończenia. Po 7 czerwca 2026 ten model umiera: każdy pracownik ma prawo do informacji w 60 dni, każde ogłoszenie wymaga aktualnych widełek, każdy raport musi być oparty na świeżych danych. Excel skaluje do 50 pracowników, przy 500 gubi sens, przy 5000 staje się ryzykiem prawnym.

## Job Evaluation Hay Method i metodologie Mercer/WTW jako fundament

Bez ustandaryzowanej architektury pracy benchmarking jest niemożliwy. Polskie firmy używają trzech głównych metodologii: Hay Method (Korn Ferry) z trzema wymiarami (know-how, problem solving, accountability) i punktami Hay 100-2000, Mercer IPE z pięcioma wymiarami (impact, communication, innovation, knowledge, risk) na poziomach 40-90+, WTW Global Grading System z 25 globalnymi poziomami (GG1-GG25). Sedlak & Sedlak jako lokalny lider dostarcza badania metodologii Stanowiska Standard - 250+ pozycji, 800+ firm rocznie, dane sektorowe (finanse, IT, produkcja, FMCG, farmacja, energetyka, BPO/SSC) i regionalne (Warszawa premium vs Kraków/Wrocław/Poznań/Trójmiasto vs region). Bez mapowania na te grupy porównawcze (próg 70% dopasowania) raport luki płacowej nie ma podstawy metodologicznej.

## Co zmienia agent

Agent nie rozwiązuje problemu przez lepsze arkusze. Rozwiązuje go przez inną architekturę.

**Przypisanie oparte na regułach.** Gdy pracownik obejmuje stanowisko, silnik reguł wyprowadza pełne mapowanie na grupy porównawcze Sedlak & Sedlak, Mercer Polska i WTW Polska - na podstawie architektury pracy (rodzina stanowisk, poziom kariery, strefa funkcjonalna), opisu stanowiska i wartościowania pracy (Hay Method, Mercer IPE lub WTW Global Grading). Comp&Ben Manager waliduje krytyczne mapowania (zarząd, dyrektorzy, role specjalistyczne, nowe pozycje bez odpowiednika rynkowego) zgodnie z [Decision Layer](/pl/decision-layer/). Człowiek wchodzi do gry tylko, gdy regulacja się zmienia (transpozycja 2023/970, aktualizacja ESRS S1-16) lub nowe stanowisko wymaga oceny - co jest udokumentowane w protokole konsultacji z Radą Pracowników (Ustawa z 7.04.2006).

**Deterministyczne obliczenia.** Compa-ratio (rzeczywiste wynagrodzenie / mediana rynkowa) liczone jest na podstawie reguł, bez AI: per pracownik, z agregacją per stanowisko, dział, lokalizacja (Warszawa premium vs Kraków/Wrocław/Poznań/Trójmiasto vs region) i grupa porównawcza. Luka płacowa według płci obliczana jest per grupa porównawcza w dwóch wariantach: nieskorygowana (raw gap) i skorygowana (adjusted gap z kontrolą doświadczenia, kwalifikacji, stażu) - zgodnie z metodologią Eurostat i polskim GUS Z-12. Walidacja minimalnego wynagrodzenia (od 2025: 4 666 zł brutto miesięcznie lub 30,50 zł brutto za godzinę) jest deterministyczna - agent blokuje propozycje poniżej minimum.

**Identyfikacja luk z priorytetyzacją.** Stanowiska ze znaczącymi odchyleniami (>+/-15% od mediany rynkowej, luka >5% bez uzasadnienia, ryzyko fluktuacji) nie są pogrzebane w tabeli, lecz raportowane z priorytetami. Dla luki >5% agent generuje wnioski wymagane przez 2023/970 art. 10: czy istnieje obiektywne uzasadnienie (art. 78 KP), jakie są opcje korekty (podwyżka indywidualna, restrukturyzacja widełek), jaki jest 6-miesięczny harmonogram przed obowiązkiem wspólnej oceny wynagrodzeń.

**Eskalacja z konsekwencją i raporty regulacyjne.** Przy lukach >5% bez obiektywnego uzasadnienia agent eskaluje do Comp&Ben Managera, HR Business Partnera i Compliance Officera oraz do Rady Pracowników i Związków Zawodowych. Decyzja o widełkach pozostaje przy Human-in-the-Loop, ale agent dokumentuje każdy krok rewizyjnie: dowody mapowania, kryteria art. 78 KP, podjętą decyzję. W audycie PIP, UODO lub pozwie w Sądzie Pracy dostarcza to dowód wypełnienia obowiązków organizacyjnych. Raporty regulacyjne agent generuje automatycznie: GUS Z-12 (XML do PUE GUS), 2023/970 art. 9 (luka nieskorygowana i skorygowana), ESRS S1-16 (CEO Pay Ratio, adekwatność), KNF Pillar 3 (Material Risk Takers, malus i clawback wg EBA/GL/2021/04), KSH art. 378 (uchwała rady nadzorczej dla SA).

## Integracja z polskim ekosystemem płac i benchmarków

Logika agenta integruje się z polskimi systemami przez API. Po stronie ERP/HR: [Comarch ERP HR](https://www.comarch.pl/erp/) jako lider w MŚP z raportami Z-12, Symfonia ERP HR z modułem wynagrodzeń (Compensation Reviewing dla średnich firm), enova365 Kadry i Płace (Soneta - przemysł i handel) oraz Asseco WAPRO HR - każdy z modułem wynagrodzeń. Dla polskich oddziałów grup międzynarodowych: SAP SuccessFactors Compensation Polska Localization (Volkswagen Poznań, Stellantis Tychy, BMW Wrocław, Bosch Wrocław), Workday HCM Polska Compensation, Personio Polska Compensation. Po stronie benchmarków: Sedlak & Sedlak (Ogólnopolskie Badanie Wynagrodzeń - ponad 250 stanowisk, ponad 800 firm rocznie), Mercer Polska TRS (ponad 600 stanowisk, 35 sektorów, kalkulator 2023/970), WTW Polska Salary Survey (Global Grading System), Korn Ferry Polska (Hay Method), AON Polska Radford (sektor IT/Tech). Uzupełnieniem są dane GUS (Z-12 i Z-03) oraz sygnały rynkowe z Pracuj.pl Wynagrodzenia i Indeed Polska Salary Insights.

Mapowanie danych jest dwukierunkowe: zmiana stanowiska w ERP automatycznie aktualizuje grupę porównawczą, nowe benchmarki Sedlak, Mercer i WTW odświeżają widełki płacowe, a raporty ESRS S1-16, Z-12 i Pillar 3 generowane są z danych płacowych z anonimizacją statystyczną (k-anonymity, min. 5 osób w grupie). Dla kontroli PIP (art. 281 KP - do 30 000 zł), GUS (Z-12 co 2 lata), UODO (RODO do 4% obrotu lub 20 mln EUR), KNF (Pillar 3 dla banków), Sądu Pracy (KP art. 18-3d - odwrócony ciężar dowodu) i biegłego rewidenta ESRS S1-16: pakiet dowodowy gotowy w 4 godziny zamiast 3 tygodni.

## Infrastruktura, która niesie dalej niż benchmarking

Silnik analizy wynagrodzeń - mapowanie stanowisk, deterministyczne obliczenia compa-ratio i luki płacowej, walidacja widełek, identyfikacja luk z priorytetyzacją, generowanie raportów regulacyjnych - to nie izolowany moduł. Ten sam wzorzec architektoniczny steruje [Promotion Process Agent](/pl/katalog-agentow-hr/promotion-process-agent/), [Merit Cycle Governance Agent](/pl/katalog-agentow-hr/merit-cycle-governance-agent/), [Performance Review Documentation Agent](/pl/katalog-agentow-hr/performance-review-documentation-agent/) oraz [Contract Offer Generation Agent](/pl/katalog-agentow-hr/contract-offer-generation-agent/). Widełki płacowe utrzymywane przez Benchmarking Agent są fundamentem każdego kolejnego procesu wynagrodzeniowego: awansów, cykli merytorycznych, negocjacji w rekrutacji, ofert dla kandydatów (obowiązkowe widełki w ogłoszeniach od 7 czerwca 2026).

Przez setki cykli benchmarkingowych powstaje obraz danych, którego żadne arkusze nie dostarczą: które grupy porównawcze systematycznie odbiegają poniżej rynku, które lokalizacje mają chronicznie wyższe luki płacowe (Warszawa premium vs region), gdzie historyczne decyzje sprzed Job Architecture nadal wpływają na strukturę. Dla zarządu i biegłego rewidenta ESRS S1-16 (CSRD): raport gotowy do badania, z luką nieskorygowaną i skorygowaną per Job Family, CEO Pay Ratio, adekwatnością wynagrodzeń (S1-10), inwestycjami w rozwój (S1-13) - bez trzytygodniowego pośpiechu i ryzyka grzywny PIP do 30 000 zł, sankcji UODO do 4% obrotu, czy pozwów w Sądzie Pracy z odwróconym ciężarem dowodu. Pytanie nie brzmi, czy firmy muszą uczynić swoje dane o wynagrodzeniach przejrzystymi - termin jest ustalony na 7 czerwca 2026. Pytanie brzmi, czy dane będą wtedy wiarygodne, audytowalne i zgodne z polskim prawem pracy.

--- Agent monitorowania zgodności HR ---
> Real-Time monitoring zgodności HR: ciągły Equal-Pay-Index, platforma sygnalistów (Dyrektywa 2019/1937), nadzór łańcucha dostaw HR, alerty Kodeks Pracy art. 94-3 i RODO art. 88.

Polski oddział międzynarodowej grupy farmaceutycznej w Warszawie 27 września 2024 otrzymuje pierwsze zgłoszenie sygnalisty przez nowo wdrożony kanał EQS Group: anonimowo, z 14-stronicową dokumentacją dyskryminacji wynagrodzeniowej w Quality Assurance, dowodami z dwóch lat. Compliance Officer wprowadza sprawę do ServiceNow GRC. Termin Ustawy z 14.06.2024 nieubłagany: 7 dni na potwierdzenie, 3 miesiące na raport zwrotny. Równocześnie dział AI wdraża nowy system rekrutacyjny - bez FRIA, bez zgłoszenia do EU AI Office, bez DPIA. PIP zapowiada kontrolę w październiku, UODO przysłał pytania o RAT dla systemów AI. Sąd Pracy w Warszawie ma już dwa pozwy o mobbing z odwróconym ciężarem dowodu. AAI sprawdza, czy kanał spełnia kryteria Ustawy.

## Pięć regulacji uderza naraz: Kodeks Pracy, RODO, sygnaliści, AI Act i AML

Kodeks Pracy łączy bezwzględny zakaz dyskryminacji (art. 18-3a) z obowiązkiem przeciwdziałania mobbingowi (art. 94-3) i ochroną danych pracowniczych (art. 22-1 - katalog zamknięty, dane biometryczne tylko za zgodą). Naruszenie generuje roszczenie min. minimalnego wynagrodzenia (4 666 zł brutto/mc 2025) za każdy miesiąc dyskryminacji i odpowiedzialność subsydiarną zarządu (KSH art. 233).

RODO uzupełnia te obowiązki o trójkąt ochrony: art. 30 (RAT obowiązkowy >250 osób), art. 32 (środki techniczne - pseudonimizacja, szyfrowanie, kontrola dostępu), art. 35 (DPIA obowiązkowa dla AI w HR, monitoringu, biometryki, profilowania). Sankcje art. 83 RODO: do 4% obrotu globalnego lub 20 mln EUR.

Ustawa o ochronie sygnalistów z 14.06.2024 wprowadza obowiązkowy kanał zgłoszeń dla pracodawców powyżej 50 osób od 25.09.2024 - anonimowy, szyfrowany E2E, dostępny całą dobę, w języku polskim i językach pracowników, z 7-dniowym potwierdzeniem i 3-miesięcznym raportem zwrotnym. Ochrona przed działaniami odwetowymi (art. 12-15) obejmuje odszkodowanie nie niższe niż 12-krotność minimalnego wynagrodzenia (2025: 55 992 zł). Rejestr i kontrole prowadzi AAI, a sankcje sięgają 60 000 zł wraz z odpowiedzialnością subsydiarną zarządu.

EU AI Act 2024/1689 wprowadza klasyfikację ryzyka. Annex III pkt 4 obejmuje workforce management jako wysokie ryzyko: rekrutacja, ocena pracownicza, awanse, zwolnienia, monitoring wydajności. Article 26 nakłada obowiązki użytkownika: monitoring, audyt, ludzki nadzór, transparentność, FRIA. Sankcje art. 99: do 35 mln EUR/7% obrotu globalnego za prohibited (zakazane od 2.08.2025), do 15 mln EUR/3% za high-risk (od 2.08.2026).

Ustawa AML z 1.03.2018 nakłada obowiązki na instytucje obowiązane - ocena ryzyka, identyfikacja beneficjenta rzeczywistego (CRBR), monitoring transakcji, zgłoszenie do GIIF w 2 dni robocze, archiwizacja 5 lat. Sankcje do 5 mln EUR lub 10% obrotu rocznego.

## Czego nie pokażą arkusze Excel - granularność wymagana przez 5 regulacji równocześnie

W większości działów HR praca wygląda tak: raz w roku audyt RODO ad hoc, raz w roku przegląd polityki antymobbingowej, sporadyczne zgłoszenia sygnalistów do skrzynki mailowej, AI deployowane bez FRIA bo "to tylko narzędzie rekrutacyjne", dane AML w innym systemie księgowym. Nikt nie ma całego obrazu - każdy specjalista pilnuje swojego silosa, zarząd ufa, że "ktoś to robi". Po 25.09.2024 i 2.08.2026 ten model umiera: sygnalista ma 3 miesiące na raport zwrotny, AI Act wymaga FRIA przed wdrożeniem, RODO wymaga DPIA dla każdej nowej operacji wysokiego ryzyka.

Dla średniej firmy 1500 pracowników z 80 stanowiskami daje to: 1 polityka compliance (ISO 37301), 5-15 systemów AI w HR do klasyfikacji, 20-50 operacji DPIA, 1 kanał sygnalistów z anonimizacją, 1 polityka AML (jeśli instytucja obowiązana), 200-500 dostawców do due diligence (CSDDD od 2027), 4 obowiązkowe szkolenia rocznie (RODO, anty-mobbing, AML, BHP). Excel skaluje do 50 pracowników, przy 500 gubi sens, przy 5000 staje się ryzykiem prawnym.

## Co zmienia agent

Agent nie rozwiązuje problemu przez lepsze checklisty. Rozwiązuje go przez inną architekturę.

**Macierz reguł z wersjonowaniem.** Silnik reguł wyprowadza z liczby pracowników, formy prawnej, sektora i kategorii AI Act pełną macierz obowiązków: kanał sygnalistów powyżej 50 osób, rejestr czynności przetwarzania powyżej 250 osób, oceny DPIA dla AI i monitoringu, AML dla instytucji obowiązanych, FRIA dla AI wysokiego ryzyka oraz due diligence łańcucha dostaw od 2027. Przekład regulacji na maszynowo weryfikowalne reguły z numerem wersji walidują Compliance Officer, Inspektor Ochrony Danych, radca prawny i AML Officer. AI wspiera jedynie jako parser tekstów ustaw, a walidacja prawna pozostaje przy człowieku zgodnie z [Decision Layer](/pl/decision-layer/).

**Klasyfikacja AI w HR i FRIA.** Każdy system AI używany w HR jest klasyfikowany według AI Act: zakazany (rozpoznawanie emocji w pracy - zabronione od 2.08.2025), wysokiego ryzyka z Annex III (rekrutacja, ocena, awanse, zwolnienia), ograniczonego ryzyka (chatboty) lub minimalnego ryzyka. Dla systemów wysokiego ryzyka agent generuje workflow FRIA: kwestionariusze ryzyk dla praw podstawowych (Kodeks Pracy art. 18-3a, Konstytucja art. 47 prywatność i art. 30 godność), identyfikację kategorii dotkniętych osób, ocenę środków minimalizacji i dokumentację konsultacji z Radą Pracowników. Decyzję końcową podejmują zarząd, CHRO, Compliance Officer i Inspektor Ochrony Danych.

**Workflow DPIA i rejestr czynności przetwarzania zgodny z RODO.** Ocena DPIA powstaje dla wszystkich operacji wysokiego ryzyka z listy UODO: AI w HR, monitoring elektroniczny (Kodeks Pracy art. 22-1), dane biometryczne, profilowanie i automatyczne decyzje. Workflow obejmuje pięć kroków: opis operacji, ocenę niezbędności, ocenę ryzyka, środki minimalizacji i konsultację z Inspektorem Ochrony Danych oraz Radą Pracowników. Rejestr czynności przetwarzania prowadzony jest automatycznie, z mapowaniem na podstawy prawne RODO (art. 6 oraz art. 9).

**Kanał sygnalistów, audyt uprzedzeń AI i AML.** Kanał sygnalistów zintegrowany z platformami EQS Group, WhistleB, NAVEX lub OneTrust działa anonimowo, szyfrowany E2E, całą dobę, z automatycznym potwierdzeniem w 7 dni, generatorem raportów zwrotnych w 3 miesiące i eskalacją do AAI przy braku reakcji. Kwartalny audyt uprzedzeń AI mierzy demographic parity, equal opportunity i predictive parity wobec progów akceptowalności i raportuje do EU AI Office. Monitoring AML śledzi transakcje w czasie rzeczywistym, alarmuje na progach (powyżej 15 000 EUR) i kieruje zgłoszenia EFE do GIIF.

**Klasyfikacja odchyleń i eskalacja z konsekwencją.** Macierz istotności jest deterministyczna i przypisuje odchyleniu jeden z poziomów: informacja, ostrzeżenie, krytyczne lub eskalacja (obowiązek zgłoszenia do PIP, UODO, AAI, GIIF, CBA lub EU AI Office). Reguły eskalacji wyznaczają terminy: zgłoszenie do UODO w 72 godziny (RODO art. 33), do GIIF w 2 dni (AML), do AAI w 7 dni (sygnaliści). Zarząd jest zawsze informowany przy ryzyku powyżej 100 000 zł (KSH art. 233). Naprawę śledzi się z ponowną weryfikacją po 30, 60 i 90 dniach.

## Integracja z polskim ekosystemem compliance i GRC

Logika agenta integruje się z polskimi systemami przez API. Po stronie ERP/HR z modułem compliance: [Comarch ERP HR](https://www.comarch.pl/erp/) jako lider w MŚP, Symfonia ERP HR (Sage - z oceną DPIA dla RODO), enova365 Kadry i Płace (Soneta - przemysł) oraz Asseco WAPRO HR - każdy z modułem compliance. Dla polskich oddziałów grup międzynarodowych: SAP SuccessFactors Polska Compliance z SAP GRC (Volkswagen Poznań, Stellantis Tychy, BMW Wrocław, Bosch Wrocław, Procter & Gamble - polski moduł AI Act, RODO i FRIA), Workday HCM z modułem Risk Management oraz Personio Polska Compliance. Po stronie dedykowanych platform GRC: ServiceNow GRC Polska (lider audytowy) oraz RSA Archer, MetricStream i LogicGate w segmencie enterprise. Po stronie kanałów sygnalistów zgodnych z Ustawą z 14.06.2024: EQS Group Polska, WhistleB Polska, Convercus oraz NAVEX EthicsPoint Polska. Po stronie ochrony prywatności i AI Governance: OneTrust Polska. Po stronie szkoleń: KnowBe4 Polska. Po stronie polskich startupów: Trafika Bezpieczeństwa, Cybea i Sealed Compliance Polska.

Mapowanie danych jest dwukierunkowe: zmiana polityki compliance w GRC propaguje do macierzy reguł, nowe orzecznictwo SN i wytyczne UODO odświeżają katalogi obowiązków, a raporty CSRD ESRS S1-16, S1-17 i G1 powstają z danych incydentów z anonimizacją statystyczną (k-anonymity, min. 5 osób). Dla PIP (do 30 000 zł, art. 281 KP), UODO (do 4% obrotu lub 20 mln EUR), AAI (do 60 000 zł wraz z odszkodowaniem sygnalisty), GIIF (do 5 mln EUR lub 10% obrotu), CBA (art. 296 KK), KNF (do 21 312 000 zł), EU AI Office (do 35 mln EUR lub 7%) oraz Sądu Pracy (odwrócony ciężar dowodu, KP art. 94-3) pakiet dowodowy jest gotowy w 4 godziny zamiast 3 tygodni.

## Infrastruktura, która niesie dalej niż compliance

Silnik monitoringu compliance - macierz reguł, klasyfikacja systemów AI, workflow DPIA i FRIA, kanał sygnalistów, AI Bias Audit, AML monitoring, eskalacja z konsekwencją, śledzenie naprawy - to nie izolowany moduł. Ten sam wzorzec architektoniczny zasila [Compensation Benchmarking Agent](/pl/katalog-agentow-hr/compensation-benchmarking-agent/), [Promotion Process Agent](/pl/katalog-agentow-hr/promotion-process-agent/), Performance Review Documentation Agent oraz Candidate Screening Agent. Każdy z tych agentów polega na ramach compliance ustanowionych przez Compliance Monitoring Agent: udokumentowanym RAT, aktualnych DPIA, sklasyfikowanych systemach AI z FRIA, polityce antymobbingowej, kanale sygnalistów.

Przez setki cykli compliance powstaje obraz danych, którego żadne checklisty nie dostarczą: które obszary systematycznie generują zgłoszenia sygnalistów, które systemy AI przekraczają progi bias, które departamenty mają chronicznie wyższe wskaźniki incydentów mobbingu, gdzie historyczne wdrożenia sprzed AI Act stwarzają ryzyko regulacyjne. Dla zarządu (tarcza z KSH art. 233) i biegłego rewidenta CSRD raport ESRS S1-16, S1-17 i G1 jest gotowy do badania, z certyfikacją ISO 37301 jako dowodem należytej staranności i audytami TÜV, Bureau Veritas lub DEKRA co 3 lata - bez 3-tygodniowego pośpiechu i bez ryzyka kar PIP do 30 000 zł, sankcji UODO do 4% obrotu, kar AAI do 60 000 zł, kar GIIF do 5 mln EUR czy kar AI Act do 35 mln EUR lub 7%. Pytanie nie brzmi, czy firmy muszą zbudować compliance HR zgodne z 5 regulacjami równocześnie - terminy są ustalone na 25.09.2024 (sygnaliści), 2.08.2025 (AI Act prohibited), 2.08.2026 (AI Act high-risk), 2027 (CSDDD). Pytanie brzmi, czy w momencie kontroli PIP/UODO/AAI/GIIF/EU AI Office dane będą wiarygodne, audytowalne i zgodne z polskim prawem pracy oraz prawem unijnym.

--- Agent szkoleń compliance HR ---
> Szkolenia compliance HR: przypisywanie, śledzenie ukończeń, raportowanie zgodnie z KP art. 207-211 BHP, art. 94-3 antymobbing, Ustawą o sygnalistach 14.06.2024, AML i EU AI Act art. 4+26.

Inspektor PIP siedzi w sali konferencyjnej. Pyta o dowód, że 47 pracowników magazynu przeszło okresowe szkolenie BHP zgodnie z Rozporządzeniem Ministra Gospodarki i Pracy z 27.07.2004. Specjalista ds. compliance otwiera arkusz Excel, przewija, szuka, znajduje 31 wpisów. Pozostałe 16? Nie wiadomo. Może przeszkoleni, ale nie udokumentowani. Może udokumentowani, ale w innym folderze. Może zapomniani. To nie jest najgorszy scenariusz - to jest wtorek. PIP może za brak dokumentacji szkolenia BHP nałożyć kary do 30 000 zł na podstawie art. 281 Kodeksu Pracy, a w skrajnym wypadku - jeśli jutro w magazynie dojdzie do wypadku przy pracy bez udokumentowanego szkolenia - prokurator postawi członkom zarządu zarzut z art. 220 Kodeksu Karnego: narażenie pracownika na bezpośrednie niebezpieczeństwo, kara pozbawienia wolności do 3 lat.

## Sześć reżimów, jedna macierz: kategorie obowiązkowych szkoleń

Kodeks Pracy nakłada bezwzględny obowiązek szkoleń BHP zgodnie z art. 207-211 i Rozporządzeniem Ministra Gospodarki i Pracy z 27.07.2004. Trzy kategorie: szkolenie wstępne przed dopuszczeniem do pracy (instruktaż ogólny i stanowiskowy, art. 237(3) KP), szkolenie stanowiskowe przy zmianie roli oraz szkolenia okresowe co 1-6 lat zależnie od grupy zawodowej (administracyjno-biurowi 6 lat, robotnicy 3 lata, kierownicy 5 lat, służba BHP 5 lat). Akredytacja jednostek przez CIOP-PIB, dokumentacja w aktach osobowych. Szkolenie antymobbingowe wynika z art. 94-3 KP - orzecznictwo SN II PK 13/19 wymaga regularnych szkoleń niezależnie od konkretnego zgłoszenia, jako element obowiązku przeciwdziałania.

RODO art. 39 nakłada na IODO obowiązek uświadamiania i szkolenia pracowników uczestniczących w operacjach przetwarzania danych osobowych. Szkolenie RODO musi poprzedzać dopuszczenie do przetwarzania danych pracowniczych (art. 22-1 KP - katalog zamknięty), klientów, pacjentów. Sankcje art. 83 RODO: do 4% obrotu globalnego lub 20 mln EUR.

Ustawa o ochronie sygnalistów z 14.06.2024 wprowadza dwa obowiązki szkoleniowe od 25.09.2024. Personel obsługujący kanał (art. 24 ust. 4) musi znać procedury, terminy 7-dniowego potwierdzenia i 3-miesięcznego raportu zwrotnego, ochronę przed odwetem. Wszyscy pracownicy muszą znać prawo do anonimowego zgłaszania, zakres naruszeń, ochronę. AAI prowadzi rejestr i kontrole, kary do 60 000 zł.

Ustawa AML z 1.03.2018 art. 52 wymaga regularnych szkoleń pracowników instytucji obowiązanych (banki, ubezpieczyciele, kancelarie, biegli rewidenci, doradcy podatkowi, pośrednicy nieruchomości, kasyna, dostawcy usług wirtualnych walut). Program: identyfikacja beneficjenta rzeczywistego (CRBR), due diligence kontekstowy, monitoring transakcji, zgłoszenia do GIIF w 2 dni. AML Officer obowiązkowy z certyfikacją CAMS. Sankcje GIIF do 5 mln EUR/10% obrotu, do 5 lat pozbawienia wolności za udział w praniu pieniędzy.

EU AI Act 2024/1689 wprowadza dwa nowe obowiązki. Article 4 (AI literacy od 2.02.2025) wymaga zapewnienia odpowiedniego poziomu wiedzy o AI wśród wszystkich pracowników korzystających z systemów AI. Article 26 (deployerzy high-risk od 2.08.2026) - osoby nadzorujące rekrutację, ocenę pracowniczą, awanse i zwolnienia (Annex III pkt 4) muszą mieć kompetencje do ludzkiego nadzoru (art. 14). Sankcje art. 99: do 15 mln EUR/3% za high-risk violations, do 35 mln EUR/7% za prohibited.

Dyrektywa NIS2 wraz z Ustawą o krajowym systemie cyberbezpieczeństwa (transpozycja do 17.10.2024) wymaga regularnych szkoleń cyberbezpieczeństwa dla operatorów usług kluczowych (energia, transport, bankowość, infrastruktura cyfrowa, zdrowie, woda, sektor publiczny). Sankcje sięgają 10 mln EUR lub 2% globalnego obrotu.

## Czego nie pokażą arkusze Excel - kilka reżimów szkoleniowych równocześnie

W większości działów HR praca wygląda tak: szkolenia BHP raz na 3-6 lat zależnie od grupy zawodowej, szkolenia RODO ad hoc przy zatrudnieniu, antymobbingowe raz na rok bez egzaminu, AML w działach finansowych z certyfikatami w innym systemie, AI literacy "kiedyś zaczniemy", NIS2 "to dla IT". Nikt nie ma całego obrazu - każdy specjalista pilnuje swojego silosa, zarząd ufa, że "ktoś to robi". Po 25.09.2024 (sygnaliści), 17.10.2024 (NIS2), 2.02.2025 (AI literacy), 2.08.2025 (AI Act prohibited) i 2.08.2026 (AI Act high-risk) ten model umiera: wszystkie regulacje wymagają udokumentowanego programu z ewidencją ukończeń, akredytacją jednostek i raportem kompletności.

Dla średniej firmy 1500 pracowników z 80 stanowiskami daje to: 6 kategorii szkoleń obowiązkowych x 1500 pracowników = 9 000 indywidualnych obowiązków szkoleniowych rocznie. Każdy z własnym terminem (BHP wstępne przed dopuszczeniem, BHP okresowe co 1-6 lat, RODO przy istotnych zmianach, antymobbingowe rocznie, AML rocznie, AI literacy rocznie po 2.02.2025), własną akredytacją (CIOP-PIB dla BHP, AML Officer CAMS, EQS/WhistleB dla sygnalistów), własnym progiem zaliczenia testu wiedzy (typowo 70-80%), własną retencją w aktach osobowych (BHP 10 lat po 1.01.2019, AML 5 lat, RODO 5 lat). Excel skaluje do 50 pracowników, przy 500 gubi sens, przy 5000 staje się ryzykiem prawnym. Dane branżowe pokazują: organizacje ze wskaźnikiem realizacji szkoleń poniżej 70 procent mają 3,5-krotnie wyższe ryzyko sankcji compliance.

## Co zmienia agent

Agent nie rozwiązuje problemu lepszymi listami. Rozwiązuje go inną architekturą: zamiast reaktywnej administracji - proaktywne sterowanie zgodne z [Decision Layer](/pl/decision-layer/), gdzie każda decyzja jest oparta na regułach, wspierana przez AI lub przypisana człowiekowi.

**Macierz wymagań z mapowaniem na polskie przepisy.** Silnik reguł wyprowadza z profilu pracownika (stanowisko, dział, lokalizacja, dostęp do danych osobowych, klasyfikacja systemów AI, sektor) pełną macierz szkoleń - od BHP według art. 207-211 KP, przez szkolenia antymobbingowe i RODO, po AML, AI literacy i cyberbezpieczeństwo NIS2. Compliance Officer, służba BHP, IODO i AML Officer wspólnie walidują przekład przepisów na maszynowo weryfikowalne reguły z numerem wersji.

**Obliczanie terminów re-szkoleń.** Każde szkolenie ma konkretny termin obliczony z polskich statutów: BHP okresowe wg Rozporządzenia 27.07.2004 (administracyjno-biurowi 6 lat, robotnicy 3 lata, kierownicy 5 lat), antymobbingowe rocznie wg orzecznictwa SN II PK 13/19, RODO przy istotnych zmianach prawa minimum co 2 lata, AML rocznie art. 52, AI literacy rocznie po 2.02.2025. Eskalujący harmonogram przypomnień: 90/60/30/14/7/1 dni przed terminem dla krytycznych BHP/RODO/AML, 60/30/7 dla pozostałych. Przy przekroczeniu BHP - automatyczne zawieszenie od pracy zgodnie z art. 2374 KP.

**Automatyczne przypisanie z weryfikacją autentyczności.** System zapisuje pracownika w LMS (Comarch Szkolenia, Symfonia LMS, enova Szkolenia, Cornerstone Polska, KnowBe4 KSAT, SAP SF Learning, Workday Learning) z terminem, generuje powiadomienia. Po ukończeniu agent weryfikuje autentyczność certyfikatu przez ekstrakcję AI z dokumentu - data, identyfikator pracownika, hash certyfikatu, podpis instruktora, numer egzaminu - i porównuje z danymi LMS. Confidence score, przy <90% przekierowanie do walidacji ręcznej HR.

**Eskalacja niezgodności i pakiet dowodowy.** Reguły eskalacji: dzień +1 do pracownika, +7 do przełożonego, +14 do oficera compliance/HR, +30 do zarządu (KSH art. 233). Dla kontroli PIP (do 30 000 zł), UODO (do 4%/20 mln EUR), GIIF (do 5 mln EUR/10%), KNF (do 21 mln zł), AAI (do 60 000 zł), AI Office (do 15 mln EUR/3%), NIS2 (do 10 mln EUR/2%): pakiet dowodowy gotowy w 4 godziny zamiast 3 tygodni - z certyfikatami, programami, listami uczestników, testami wiedzy, ankietami efektywności i ścieżką audytu zmian.

## Integracja z polskim ekosystemem: Comarch Szkolenia, Symfonia LMS, KnowBe4, EQS Training

Logika agenta integruje się z polskimi systemami przez API. W segmencie ERP/HR z modułem szkoleń liderem MŚP jest [Comarch ERP HR ze Szkoleniami i Compliance](https://www.comarch.pl/erp/), obok Symfonii (moduł BHP zgodny z Rozporządzeniem 27.07.2004), enova365 (raporty CSRD ESRS S1-13) oraz WAPRO. Polskie oddziały grup międzynarodowych korzystają z SAP SuccessFactors (Volkswagen Poznań, Stellantis Tychy, BMW Wrocław, Bosch Wrocław, Procter & Gamble), Workday Learning, Cornerstone OnDemand i Personio. Świadomość cyberbezpieczeństwa dostarcza KnowBe4 (symulacje phishingu pod NIS2), kanały sygnalistów obsługują EQS Group i NAVEX zgodnie z Ustawą z 14.06.2024, a treści szkoleniowe BHP - dostawcy akredytowani przez CIOP-PIB.

Mapowanie danych działa dwukierunkowo: zmiana wymagań w macierzy reguł agenta przekłada się na przypisanie kursów w LMS, zmiana statusu ukończenia w LMS aktualizuje raport kompletności, a nowe orzecznictwo SN i wytyczne UODO odświeżają katalogi obowiązków. Agent wspiera też wnioski o dofinansowanie z Krajowego Funduszu Szkoleniowego (do 80% kosztów dla pracowników 45+, kobiet, osób z niepełnosprawnością i sektorów priorytetowych) - identyfikuje uprawnionych i przygotowuje dokumenty, ale powyżej 50 000 zł decyzję o budżecie podejmuje zarząd.

## Infrastruktura, która niesie dalej niż szkolenia

Silnik zarządzania szkoleniami compliance - macierz wymagań z mapowaniem na statuty, obliczanie terminów re-szkoleń, automatyczne przypisanie w LMS, weryfikacja autentyczności certyfikatów, eskalacja zaległości, pakiet dowodowy dla organów - to nie izolowany moduł. Ten sam wzorzec architektoniczny zasila Certification Tracking Agent, Training Needs Analysis Agent, Training Effectiveness Agent oraz Onboarding Agent (struktura compliance training jako fundament dla nowych pracowników). Każdy z tych agentów polega na ramach kompletności szkoleniowej ustanowionej przez Compliance Training Agent: udokumentowanym programie szkoleń, akredytowanych jednostkach, ewidencji ukończeń z hashem certyfikatu, raportach kompletności dla biegłego rewidenta CSRD ESRS S1-13.

Przez setki cykli szkoleń powstaje obraz danych, którego żadne arkusze Excel nie dostarczą: które szkolenia są systematycznie odkładane, które lokalizacje chronicznie nie osiągają celu kompletności, którzy kierownicy nie reagują na eskalacje, które grupy pracownicze najczęściej oblewają testy wiedzy. Dla zarządu - który odpowiada za należytą staranność (art. 233 KSH), a po wypadku BHP karnie z art. 220 Kodeksu Karnego - i dla biegłego rewidenta CSRD raport jest gotowy do badania, z certyfikacją ISO 37301 jako dowodem należytej staranności, bez trzytygodniowego pośpiechu i bez ryzyka kar od PIP, UODO, GIIF czy AI Office. Pytanie nie brzmi, czy zbudować program szkoleń compliance - terminy są już ustalone (sygnaliści 25.09.2024, NIS2 17.10.2024, AI literacy 2.02.2025, AI Act high-risk 2.08.2026). Pytanie brzmi, czy w momencie kontroli dane będą wiarygodne, audytowalne i zgodne z polskim oraz unijnym prawem.

--- Agent generowania umów HR ---
> Generowanie umów o pracę: 7 elementów art. 29 KP, walidacja widełek wg Pay Transparency 2023/970, klauzule RODO art. 6+22+88 i integracja z Autenti/DocuSign eIDAS - audytowalne dla PIP.

Pracodawca przyjął ofertę kandydata 1 marca. Specjalista HR otwiera szablon z 2019 roku, ręcznie przepisuje dane z arkusza rekrutacyjnego, zapisuje jako PDF. Dział prawny ma w kolejce 14 umów - przegląd zajmie 12 dni. 22 marca umowa wraca, ale brakuje załącznika z klauzulą informacyjną RODO art. 13. 23 marca kandydat dzwoni: przyjął ofertę konkurencji, "u was za długo trwało". 25 marca PIP rozpoczyna kontrolę i odkrywa, że umowy z ostatnich 6 miesięcy nie mają obiektywnej przyczyny przy umowach terminowych (art. 29 §1-1 KP), klauzula sygnalistów obowiązkowa od 25.09.2024 nie została wstawiona w 23 z 47 umów. Inspektor wystawia sankcję 30 000 zł na podstawie art. 281 KP - za każde naruszenie.

## Pięć wymiarów obowiązków przy treści umowy o pracę

Kodeks Pracy art. 22 §1 definiuje stosunek pracy przez znamiona: świadczenie pracy pod kierownictwem pracodawcy, w miejscu i czasie przez niego wskazanym, za wynagrodzeniem. Zastąpienie etatu umową cywilnoprawną jest zabronione (art. 22 §1-1 oraz art. 281-1 KP) pod groźbą kary PIP do 30 000 zł. Według orzeczenia SN II PK 121/14 wystarczą 3 z 4 kryteriów (kierownictwo, miejsce, czas, ryzyko gospodarcze), by ustalić stosunek pracy retroaktywnie za 5 lat - z naliczeniem zaległych składek ZUS i PIT wraz z odsetkami.

Rodzaje umów reguluje art. 25 KP wraz z art. 25-1 i art. 26. Umowa na okres próbny trwa najwyżej 3 miesiące i jest jednokrotna. Umowę terminową ograniczają dwa limity - 33 miesiące i 3 umowy z tym samym pracodawcą - a po ich przekroczeniu przechodzi ona z mocy prawa w umowę na czas nieokreślony (art. 25-1 §3). Wyjątki, jak zastępstwo czy prace sezonowe, wymagają udokumentowanej przyczyny obiektywnej (art. 29 §1-1).

Art. 29 wymaga siedmiu obowiązkowych elementów: rodzaju pracy, miejsca wykonywania, wynagrodzenia z rozbiciem na składniki (zasadnicze, premie, dodatki za pracę nocną, świąteczną i nadliczbową), wymiaru czasu pracy oraz terminu rozpoczęcia; w umowie terminowej dochodzi okres i przyczyna obiektywna, w próbnej - okres i ewentualne uzgodnienie zatrudnienia bezterminowego. Dodatkowo art. 29 §3-§4 nakazuje przekazać w 7 dni pisemną informację o normie czasu pracy, częstotliwości wypłat, wymiarze urlopu, okresie wypowiedzenia (art. 36 KP) i układzie zbiorowym.

Dane kandydata chronią RODO oraz art. 22-1 KP. Katalog jest zamknięty: imię, nazwisko, data urodzenia, adres, wykształcenie, kwalifikacje i przebieg zatrudnienia; dane spoza niego (stan cywilny, ciąża, orientacja, religia) wymagają pisemnej zgody (art. 22-1 §4). Klauzula informacyjna z art. 13 RODO jest obowiązkowa. Naruszenie grozi odszkodowaniem z art. 18-3d KP przy odwróconym ciężarze dowodu oraz karą UODO do 4% globalnego obrotu lub 20 mln EUR.

Dyrektywa Pay Transparency 2023/970 (transpozycja do 7.06.2026) wprowadza widełki wynagrodzeń w ogłoszeniu i na pierwszej rozmowie, zakaz pytań o historię zarobków oraz raportowanie luki płacowej powyżej 5% z planem remediacji per kategoria pracownicza. Kontrole prowadzi Pełnomocnik ds. Równego Traktowania, a brak zgodności grozi procesami dyskryminacyjnymi i ryzykiem reputacyjnym wynikającym z publicznego raportu.

## Czego nie pokażą szablony Word - 21 dni od decyzji do umowy

W większości działów HR wygląda to tak: szablony z 2019 roku, checklista siedmiu elementów w osobnym pliku, biblioteka klauzul rozproszona w mailach radcy prawnego, walidacja widełek odkładana "do cyklu wynagrodzeń", klauzula sygnalistów dodawana ad hoc, RODO doklejane ręcznie jako załącznik, podpis na papierze z dwukrotnym kurierem i ręczna rejestracja w ZUS. Złożone razem - cztery godziny pracy HR, niemal dwa tygodnie przeglądu prawnego i kolejne dni na kuriera oraz ZUS - dają około 21 dni od decyzji do gotowej umowy.

Dla firmy z 1500 pracownikami i rotacją 15% rocznie (225 nowych umów) to tysiące roboczodni HR i setki dni pracy radcy prawnego rocznie. Każde przekroczenie limitów art. 26 KP rodzi roszczenia i karę PIP do 30 000 zł. Zastąpienie etatu umową cywilnoprawną przy znamionach z art. 22 §1 oznacza składki ZUS i PIT naliczone wstecz za 5 lat wraz z odsetkami, brak klauzuli sygnalistów - karę AAI do 60 000 zł, a wynagrodzenie poza widełkami po 7.06.2026 - procesy dyskryminacyjne. Word skaluje do 50 umów rocznie; przy 200 traci sens, a powyżej 500 staje się ryzykiem prawnym.

## Co zmienia agent

Agent rozwiązuje problem inną architekturą zgodną z [Decision Layer](/pl/decision-layer/), gdzie każda decyzja jest oparta na regułach, wspierana przez AI lub przypisana człowiekowi.

**Walidacja znamion stosunku pracy art. 22 KP.** Silnik reguł sprawdza profil stanowiska przed wyborem typu umowy: kierownictwo, narzucone miejsce, narzucony czas, brak ryzyka gospodarczego. Spełnienie 3 z 4 kryteriów (SN II PK 121/14) blokuje generowanie umowy B2B i wymaga umowy o pracę. Krytyczne dla obrony przed PIP (art. 281-1) i ustaleniem stosunku pracy retroaktywnie z efektem ZUS 5 lat.

**Wybór szablonu z kontrolą limitów.** Próbna art. 25-1 (max 3 mies., jednokrotnie), terminowa art. 26 (max 33 mies./3 umowy - przy zbliżaniu się do limitu ostrzeżenie 'nieokreślona po następnej', blokada 4. terminowej), nieokreślona, tymczasowa (Ustawa z 9.07.2003), delegowana (Ustawa z 10.06.2016 - równe wynagrodzenie od 1. dnia).

**Siedem obowiązkowych elementów art. 29 KP wraz z klauzulami informacyjnymi.** Szablon wypełnia się automatycznie danymi z modułu rekrutacji. Załącznik pierwszy zawiera informację 7-dniową (art. 29 §3-§4), a drugi - klauzule informacyjne RODO, sygnalistów (obowiązkowo powyżej 50 pracowników od 25.09.2024), antymobbingową (art. 94-3) i o lojalności (art. 100).

**Walidacja widełek według Pay Transparency 2023/970.** Reguły pochodzą z modułu wynagrodzeń, a odchylenie powyżej 5% wymaga zatwierdzenia przez HR Business Partnera i Compensation Directora. Kwartalny raport luki płacowej powstaje z anonimizacją statystyczną, a raport CSRD trafia do biegłego rewidenta. Od 7.06.2026 luka grozi odszkodowaniem z art. 18-3d KP przy odwróconym ciężarze dowodu.

**Umowa o zakazie konkurencji i okres wypowiedzenia.** Dla stanowisk z dostępem do tajemnicy przedsiębiorstwa (C-level, sprzedaż, B+R) agent generuje odrębną umowę o zakazie konkurencji na maksymalnie 24 miesiące (art. 101-2 KP), z rzeczywistym odszkodowaniem co najmniej 25% wynagrodzenia - bo odszkodowanie pozorne czyni umowę nieważną (SN III PK 38/12). Okres wypowiedzenia ustala art. 36 KP zależnie od stażu: 2 tygodnie, 1 miesiąc albo 3 miesiące.

**Routing prawny i kwalifikowany podpis eIDAS.** Umowy standardowe idą bez przeglądu (4 godziny od decyzji do podpisu), klauzule niestandardowe trafiają do radcy prawnego w 24 godziny, a umowy managerskie C-level wymagają radcy i akceptacji zarządu (art. 233 KSH). Po akceptacji następuje kwalifikowany podpis eIDAS zgodny z art. 78-1 KC, a po podpisie - automatyczna rejestracja w ZUS w 7 dni przez API PUE ZUS.

## Integracja z polskim ekosystemem: Comarch Umowy, Symfonia, eRecruiter, Autenti eIDAS

W segmencie ERP/HR liderem MŚP jest [Comarch ERP HR](https://www.comarch.pl/erp/) (generowanie umów art. 29 KP, kontrola znamion z art. 22, integracja z PUE ZUS i podpisem eIDAS Autenti), obok Symfonii (generator umów o zakazie konkurencji, raport CSRD), enova365 (kontrola limitów umów terminowych z automatycznym przekształceniem) oraz WAPRO. Oddziały międzynarodowe korzystają z SAP SuccessFactors (Volkswagen Poznań, Stellantis Tychy, BMW Wrocław, Bosch, P&G), Workday (ślad audytowy, raporty Pay Transparency) i Personio.

Po stronie ATS działają eRecruiter (polski lider MŚP), HRappka, Pracuj.pl oraz JoinPro. Kwalifikowany podpis eIDAS zapewnia przede wszystkim Autenti (polska platforma kwalifikowana z certyfikatami NCert, Sigillum, CenCert, PWPW i EuroCert, ze śladem audytowym i archiwizacją 10 lat), a alternatywnie DocuSign, Adobe Sign czy Yousign. Obieg dokumentów obsługują eDokumenty i Diadoc, zarządzanie umowami - platformy CLM (Diligent, Concord, Ironclad), a zgodność z RODO - polskie narzędzia compliance, takie jak Sealed Compliance czy Cybea.

Mapowanie danych działa dwukierunkowo: zmiana danych kandydata w rekrutacji trafia do generatora umowy, podpis Autenti aktualizuje status w module kadrowym, a rejestracja w PUE ZUS - moduł kadrowy i płacowy. Dla kontroli PIP, UODO, ZUS, Sądu Pracy czy AAI pakiet dowodowy jest gotowy w 4 godziny zamiast 3 tygodni.

## Infrastruktura, która niesie dalej niż jedna umowa

Silnik generowania umów - z biblioteką szablonów na każdy typ zatrudnienia, walidacją znamion stosunku pracy, kontrolą limitów umów terminowych, siedmioma elementami art. 29, kompletem klauzul, widełkami Pay Transparency, zakazem konkurencji, podpisem eIDAS i rejestracją ZUS - zasila HR Document Management Agent (świadectwa pracy, zaświadczenia, aneksy), Policy Document Agent (regulamin pracy, polityka antymobbingowa) i Legal Contract Review Agent. Walidacja widełek korzysta z silnika Compensation Agent i Merit Cycle Governance Agent, a integracja z platformami eIDAS oraz API PUE ZUS ustanawia infrastrukturę elektronicznego obiegu dla całego stosu HR.

Przez setki cykli umów powstaje obraz danych: które typy stanowisk systematycznie generują klauzule niestandardowe (sygnał do biblioteki), które działy chronicznie przekraczają widełki (sygnał do cyklu wynagrodzeń), które umowy terminowe zbliżają się do limitu z art. 26 KP (sygnał do automatycznego przekształcenia) i które grupy pracownicze mają lukę płacową powyżej 5% (sygnał do remediacji). Dla zarządu - odpowiadającego za należytą staranność (art. 233 i 299 KSH) - oraz dla biegłego rewidenta CSRD raport jest gotowy do badania, z certyfikacją ISO 37301 jako dowodem należytej staranności, bez ryzyka kar od PIP, UODO, ZUS i AAI ani procesów dyskryminacyjnych. Terminy są już ustalone (sygnaliści 25.09.2024, Pay Transparency 7.06.2026). Pytanie brzmi, czy w momencie kontroli dane będą wiarygodne, audytowalne i zgodne z polskim oraz unijnym prawem.

--- Agent danych pracowniczych ---
> Master data pracownicze: RODO art. 5+9+22+35+88, elektroniczne akta osobowe (MRiPS 10.12.2018), 10-letnia archiwizacja, Right to Erasure art. 17 i Privacy by Design dla UODO i Sądu Pracy.

Pracownik przeprowadza się 1 marca i zgłasza nowy adres specjaliście HR. 22 marca lista płac trafia na stary adres. Ewidencja czasu pracy pokazuje starą lokalizację. System kontroli dostępu nigdy nie otrzymał zmiany. 25 marca UODO rozpoczyna kontrolę po skardze pracownika - i odkrywa, że firma od 18 miesięcy nie aktualizowała Rejestru Czynności Przetwarzania art. 30 RODO, nie ma DPIA art. 35 dla profilowania HR w ATS-AI, w aktach osobowych elektronicznych brakuje kwalifikowanego podpisu eIDAS na 47 z 230 dokumentów (Rozp. MRiPS z 10.12.2018 wymaga). Inspektor wystawia sankcję 1,2 mln zł na podstawie RODO art. 83 ust. 4 - 2% obrotu globalnego.

To nie jest zaniedbanie. To jest architektura.

## Pięć wymiarów obowiązków przy zarządzaniu danymi pracowniczymi

Agent działa zgodnie z zasadą [Decision Layer](/pl/decision-layer/): każda decyzja jest oparta na regułach, wspierana przez AI lub przypisana człowiekowi.

Większość firm traktuje zmiany danych pracowniczych jako rutynę administracyjną. Wniosek wpływa, dane się zmieniają, wniosek zamknięty. Czego nie dostrzegają: od 500 pracowników każda pojedyncza zmiana wywołuje reakcję łańcuchową w trzech do siedmiu systemach - kadry, płace, ewidencja czasu pracy, kontrola dostępu, PPK, benefity, czasem flota czy stołówka. Każdy z nich potrzebuje umowy powierzenia (art. 28 RODO), przetwarza dane na własnej podstawie prawnej i ma własną retencję - w napięciu z prawem do usunięcia (art. 17 RODO).

37 procent wszystkich błędów na liście płac powstaje z ręcznego wprowadzania danych. Średni koszt jednego błędu to 265 EUR, co przy 1000 pracowników daje około 230 000 EUR rocznie - tylko za korekty. Do tego dochodzą kary: UODO do 4% globalnego obrotu za naruszenie podstaw przetwarzania, ZUS ze składkami naliczonymi wstecz za 5 lat wraz z odsetkami oraz odszkodowania z art. 18-3d KP w procesach dyskryminacyjnych opartych na profilowaniu.

Wskaźnik błędów nie rośnie liniowo z wielkością organizacji - rośnie wykładniczo, bo każdy dodatkowy system docelowy mnoży prawdopodobieństwo błędnej synchronizacji. Zespół HR widzi pojedyncze wnioski i pojedyncze korekty. Czego nie widzi: systematycznego dryfu między systemami, braku oceny DPIA dla nowych operacji profilowania, nieaktualnego rejestru czynności przetwarzania, naruszeń minimalizacji i akt osobowych bez kwalifikowanego podpisu eIDAS. Jedna trzecia polskich firm przyznaje, że procesy utrzymania danych pracowniczych nie są zdefiniowane w wymaganym stopniu. RODO wymaga prawidłowości (art. 5 ust. 1 lit. d) - gdy trzy systemy prowadzą trzy różne adresy, który jest prawidłowy?

## Czego nie pokażą szablony Excel - 21 dni od zmiany do payroll, 1,2 mln zł kara UODO

W większości działów HR wygląda to tak: dane master w arkuszu Excel, umowy powierzenia z 2018 roku bez aktualizacji o nowe systemy, brak oceny DPIA dla profilowania ATS, rejestr czynności przetwarzania prowadzony "raz na rok", pseudonimizacja tylko na produkcji (nie w testach), kwalifikowanego podpisu eIDAS brakuje w co piątym dokumencie akt osobowych, a naruszenia zgłasza się dwa tygodnie po wykryciu, choć RODO wymaga 72 godzin. Złożone razem - godziny pracy HR oraz dni synchronizacji, walidacji i opóźnień - dają około 21 dni od zmiany do listy płac.

Dla firmy z 1500 pracownikami, rotacją 15% rocznie i ośmioma zmianami miesięcznie na osobę (około 2 880 zmian rocznie) to tysiące roboczodni HR i realne ryzyko kary UODO przy kontroli (od 0,5 do 20 mln zł). Brak oceny DPIA dla nowego profilowania grozi karą do 2% obrotu lub 10 mln EUR i zakazem operacji, naruszenie minimalizacji - karą do 4% globalnego obrotu, a niespójność z katalogiem z art. 22-1 KP - odszkodowaniem z art. 18-3d przy odwróconym ciężarze dowodu. Brak podpisu eIDAS w aktach osobowych narusza Rozporządzenie MRiPS z 10.12.2018 i grozi karą PIP do 30 000 zł.

## Co zmienia agent

Agent rozwiązuje problem inną architekturą zgodną z [Decision Layer](/pl/decision-layer/), gdzie każda decyzja jest oparta na regułach, wspierana przez AI lub przypisana człowiekowi.

**Walidacja katalogu zamkniętego z art. 22-1 KP.** Silnik reguł sprawdza każde pole przed zapisem: czy mieści się w katalogu zamkniętym (dane kandydata wg art. 22-1, pracownika wg art. 22-1a, biometria i monitoring wg art. 22-1b)? Czy dane szczególnych kategorii (zdrowie, biometria) mają podstawę z art. 9 ust. 2 RODO albo pisemną zgodę? Brak podstawy blokuje zapis i wysyła komunikat do IODO.

**Mapowanie pól na podstawy prawne RODO z rejestrem czynności przetwarzania.** Reguły są deterministyczne: numer rachunku, PESEL i dane podatkowe opierają się na art. 6 (umowa i obowiązek prawny), dane medyczne na art. 9 ust. 2 lit. h, biometria na art. 9 ust. 2 lit. b lub pisemnej zgodzie, a monitoring poczty na art. 22-3 KP z informacją na 2 tygodnie przed. Rejestr czynności przetwarzania (art. 30) aktualizuje się automatycznie przy każdej zmianie procesu.

**Minimalizacja danych i privacy by design (art. 5 i 25 RODO).** Reguły blokują pola nadmiarowe bez uzasadnienia w ocenie DPIA. Pola wrażliwe (PESEL, numer rachunku, wynagrodzenie) są pseudonimizowane w środowiskach testowych i raportach analitycznych. Dane są szyfrowane w spoczynku (AES-256) oraz w tranzycie (TLS 1.3), z kluczami w KMS rotowanymi kwartalnie i dostępem według ról od fazy projektowania.

**Ocena DPIA dla profilowania, monitoringu i biometrii.** Wymóg jest deterministyczny: profilowanie o istotnych skutkach (narzędzia ATS, scoring, planowanie sukcesji), monitoring (poczta, lokalizacja, biometria) oraz automatyzacja decyzji blokują operację bez aktualnej oceny skutków. Agent integruje ją z FRIA dla systemów wysokiego ryzyka od 2.08.2026, konsultacja z IODO jest obowiązkowa, a przy wysokim ryzyku dochodzi konsultacja z UODO (art. 36).

**Klasyfikacja, workflow zatwierdzeń i synchronizacja do wielu systemów.** Macierz uprawnień działa według wrażliwości pola: zmiana adresu idzie automatycznie, numer rachunku i klasa podatkowa wymagają dwóch par oczu (ochrona przed socjotechniką), a dane szczególnych kategorii - akceptacji IODO. Po zatwierdzeniu rekord propaguje się automatycznie do systemów kadrowo-płacowych, benefitów, ewidencji czasu i kontroli dostępu, z planowanym uzgodnieniem synchronizacji. Niespójność narusza zasadę prawidłowości (art. 5 ust. 1 lit. d RODO).

**Elektroniczne akta osobowe, obsługa DSAR i zgłoszenie w 72 godziny.** Każda zmiana jest logowana w elektronicznych aktach osobowych z kwalifikowanym podpisem eIDAS lub pieczęcią pracodawcy, hashem dokumentu, śladem audytowym dostępu, kopią zapasową i retencją 10 lat (50 lat dla umów sprzed 1.01.2019). Wnioski pracownika z art. 15-21 RODO agent obsługuje w terminie miesiąca, a konflikt prawa do usunięcia z obowiązkiem retencji rozwiązuje ograniczeniem przetwarzania (art. 18). Naruszenia wykrywa automatycznie i zgłasza do UODO w 72 godziny (art. 33), a przy wysokim ryzyku zawiadamia też osoby (art. 34).

## Integracja z polskim ekosystemem: Comarch HR Master Data, Symfonia, enova365, eDokumenty eIDAS

W segmencie ERP/HR liderem MŚP jest [Comarch ERP HR](https://www.comarch.pl/erp/) (katalog zamknięty z art. 22-1 KP, rejestr czynności przetwarzania, integracja z PUE ZUS, elektroniczne akta osobowe 10 lat, kwalifikowany podpis Autenti), obok Symfonii (generator umów powierzenia, kontrola minimalizacji, raport CSRD), enova365 (dynamiczne mapowanie pól, raport luki płacowej) oraz WAPRO. Oddziały międzynarodowe korzystają z SAP SuccessFactors (Volkswagen Poznań, Stellantis Tychy, BMW Wrocław, Bosch, P&G - ocena DPIA, FRIA, hosting w EU i USA ze standardowymi klauzulami umownymi), Workday (ślad audytowy, FRIA, Pay Transparency, Schrems II) i Personio z hostingiem w EU.

Archiwizację elektroniczną zapewniają eDokumenty, Diadoc i ContractAgent (kwalifikowany podpis eIDAS, retencja 10 lat, ślad audytowy, kopia zapasowa, konwersja do papieru wg art. 94 §3 KP). Po stronie zgodności z RODO polskie narzędzia, jak Sealed Compliance czy Cybea, generują klauzule informacyjne, zgody i zgłoszenia do UODO w 72 godziny; OneTrust wykrywa dane w infrastrukturze IT i automatyzuje obsługę DSAR oraz prawa do usunięcia; BigID i Collibra klasyfikują dane szczególnych kategorii; a platformy GRC (ServiceNow, RSA Archer, MetricStream) prowadzą workflow ryzyka RODO i raporty zgodności z ISO 27001, 27701 i 37301.

Mapowanie danych dwukierunkowe: zmiana master data propaguje do payroll, benefits, ewidencji czasu, kontroli dostępu; podpis eIDAS w eDokumenty aktualizuje akta osobowe; rejestracja ZUS w PUE ZUS aktualizuje moduł kadrowy. Dla kontroli UODO/MRiPS/ZUS/Sądu Pracy/AAI/KNF/GIIF: pakiet dowodowy gotowy w 4 godziny zamiast 3 tygodni.

## Infrastruktura, która niesie dalej niż jedna zmiana

Centralna platforma danych master, integracji i zgodności z RODO zasila Onboarding Agent, Offboarding Agent (deaktywacja i retencja 10 lat), Compensation Agent (Pay Transparency), Performance Management Agent (profilowanie z FRIA), Time and Attendance Agent (monitoring wg art. 22-2 KP), Benefits Enrollment Agent (dane szczególnych kategorii) oraz Compliance Monitoring Agent (rejestr sygnalistów). Każdy z nich, odczytując dane, opiera się na gwarancjach RODO wymuszanych przez tego agenta, zamiast doposażać się w nie z osobna.

Przez setki cykli zmian powstaje obraz danych: które typy zmian generują wyjątki synchronizacji, które systemy chronicznie powodują niespójności (sygnał do umów powierzenia), które operacje wymagają oceny DPIA i które grupy pracownicze mają nadmiarowe pola (sygnał do remediacji minimalizacji). Dla zarządu (art. 233 i 299 KSH) oraz biegłego rewidenta CSRD raport jest gotowy do badania, z certyfikacjami ISO 27001, 27701 i 37301 - bez ryzyka kar od UODO, ZUS, AAI, KNF czy GIIF.

Dla organizacji od 500 pracowników pytanie nie brzmi, czy zarządzanie danymi powinno być zautomatyzowane. Brzmi ono: czy stać ją na to, by specjalista przez 29 tygodni rocznie korygował błędy, walidował rejestr czynności przetwarzania, obsługiwał wnioski DSAR i zgłaszał naruszenia w 72 godziny - zamiast pracy, do której go zatrudniono. Terminy są już ustalone (sygnaliści 25.09.2024, Pay Transparency 7.06.2026, EU AI Act dla systemów wysokiego ryzyka 2.08.2026). Pytanie brzmi, czy w momencie kontroli dane będą wiarygodne, audytowalne i zgodne z polskim prawem pracy oraz RODO.

--- Employee Relations Case Agent ---
> Zarządza sprawami dyscyplinarnymi, mobbingiem i zgłoszeniami sygnalistów: Kodeks Pracy art. 108-113, art. 94-3, Ustawa o sygnalistach z 14.06.2024 - kompletna dokumentacja przed Sądem Pracy.

Większość firm w Polsce przegrywa sprawy pracownicze nie na stanie faktycznym. Przegrywa je na aktach.

Według danych Sądu Najwyższego ok. 60 procent postępowań o przywrócenie do pracy w Sądach Pracy kończy się przegraną pracodawcy lub ugodą - i w 30-40 procent przypadków to nie merytoryczna nieuzasadnienie wypowiedzenia rozstrzyga, lecz błąd proceduralny: brak wysłuchania z Kodeksu Pracy art. 109 par. 2, pominięcie konsultacji ze związkiem zawodowym z Ustawy z 23.05.1991, upływ 2-tygodniowego terminu z KP art. 109 par. 1, naruszenie ochrony sygnalisty z Ustawy z 14.06.2024 lub niewypełnienie procedury antymobbingowej z KP art. 94-3.

To nie jest problem edukacyjny. HR Business Partnerzy w Polsce znają Kodeks Pracy. Problem jest operacyjny: między pierwszą skargą sygnalisty, pierwszym zgłoszeniem mobbingu lub pierwszym naruszeniem obowiązków pracowniczych a zamknięciem sprawy leżą dziesiątki kroków proceduralnych - każdy z własnym terminem, własnymi uczestnikami, własnym obowiązkiem dokumentacyjnym wobec Sądu Pracy.

## Pięć typów spraw, jeden strukturalny problem

Agent działa zgodnie z zasadą [Decision Layer](/pl/decision-layer/): każda decyzja jest oparta na regułach, wspierana przez AI lub przypisana człowiekowi.

Sprawy relacji pracowniczych w polskiej organizacji podlegają różnym reżimom prawnym, ale wszystkie zawodzą w tym samym punkcie: brak sterowania procesowego przy wysokiej złożoności proceduralnej i sankcji w razie błędu.

**Kara porządkowa z KP art. 108-113.** Katalog jest zamknięty: upomnienie, nagana, kara pieniężna do jednodniowego wynagrodzenia za każde wykroczenie, łącznie nie więcej niż 1/10 wynagrodzenia miesięcznego. Termin 2 tygodni z KP art. 109 par. 1 biegnie od dnia powzięcia wiadomości o naruszeniu - nie od dnia naruszenia. Wysłuchanie pracownika jest obowiązkowe, pominięcie unieważnia karę. Sprzeciw pracownika w terminie 7 dni z KP art. 112 wymaga rozpatrzenia. Odwołanie do Sądu Pracy z KP art. 264 ma 21 dni od doręczenia decyzji o odrzuceniu sprzeciwu.

**Mobbing z KP art. 94-3.** Pracodawca ma obowiązek przeciwdziałać mobbingowi - bezczynność rodzi odpowiedzialność odszkodowawczą minimum minimalnego wynagrodzenia, niezależnie od winy konkretnego sprawcy. Wewnętrzna procedura antymobbingowa wymaga: powołania komisji, wysłuchania zgłaszającego i obwinianego, zebrania zeznań świadków, sporządzenia raportu, podjęcia działań naprawczych. Pominięcie procedury skutkuje pozwem cywilnym o naruszenie dóbr osobistych przed Sądem Cywilnym - poza samym roszczeniem antymobbingowym z KP.

**Zgłoszenie sygnalisty z Ustawy o ochronie sygnalistów z 14.06.2024.** Każde zgłoszenie naruszenia prawa, etyki lub procedur uruchamia ochronę przed odwetem przez 24 miesiące. Działania odwetowe są zabronione - postępowanie dyscyplinarne wszczęte po zgłoszeniu wymaga uzasadnienia niezależnego od samego faktu zgłoszenia, a ciężar dowodu niezależności spoczywa na pracodawcy. AAI Niezależna Ochrona Sygnalistów może interweniować na wniosek sygnalisty.

**Dyskryminacja z KP art. 18-3a i Ustawy o równym traktowaniu z 03.12.2010.** Zarzut dyskryminacji bezpośredniej lub pośredniej (płeć, wiek, narodowość, religia, orientacja, niepełnosprawność, stan rodzinny) uruchamia odwrócony ciężar dowodu - to pracodawca musi udowodnić, że odmienne traktowanie było uzasadnione. RPO Rzecznik Praw Obywatelskich i Pełnomocnik Rządu ds. Równego Traktowania mają kompetencje skargowe.

**Wypowiedzenie z KP art. 30-32 i 52.** Najgęstszy proceduralnie typ sprawy. Termin wypowiedzenia z KP art. 36 zależy od stażu pracy: 2 tygodnie do 6 miesięcy, 1 miesiąc do 3 lat, 3 miesiące powyżej 3 lat. Konsultacja ze związkiem zawodowym z KP art. 38 - termin opinii 5 dni. Ochrona pracowników szczególnych z KP art. 41 i Ustawy z 12.02.1991: ciąża, macierzyństwo, niepełnosprawność, działacze związkowi. Rozwiązanie bez wypowiedzenia z KP art. 52 (ciężkie naruszenie) ma termin 1 miesiąca z KP art. 52 par. 2. Odwołanie do Sądu Pracy z KP art. 264 ma 21 dni.

```
Typ sprawy            Uczestnicy                       Krytyczne terminy
-----------------------------------------------------------------------------
Kara porządkowa       HR, Kierownik, Pracownik,        2 tyg. KP art. 109,
                      ew. Związek                       7 dni sprzeciw,
                                                        21 dni Sąd Pracy
Mobbing               Komisja, Świadkowie,             7 dni komisja,
                      Radca Prawny                      30 dni raport
Sygnalista            HR, AAI, Compliance,             Niezwłocznie,
                      Pełnomocnik ds. Sygnalistów       24 mies. ochrona
Dyskryminacja         HR, RPO, Pełnomocnik             Odwrócony ciężar
                      ds. Równego Traktowania           dowodu
Wypowiedzenie         HR, Kierownik, Związek,          5 dni opinia związku,
                      Radca Prawny, ew. PFRON           termin wypowiedzenia,
                                                        21 dni Sąd Pracy
```

## Dlaczego listy kontrolne nie wystarczają

Narzucająca się odpowiedź na złożoność proceduralną to listy kontrolne. Większość polskich działów HR z nimi pracuje. A mimo to błędy się zdarzają.

Powód: lista kontrolna jest statyczna. Odwzorowuje przypadek idealny, nie rozgałęzienia. Sprawa kary porządkowej, w której pracownik wnosi sprzeciw z KP art. 112, podąża inną ścieżką niż ta, w której nie reaguje. Procedura antymobbingowa, w której obwiniany jest jednocześnie sygnalistą zgłoszonym 8 miesięcy temu, podlega ochronie z Ustawy z 14.06.2024 i wymaga uzasadnienia niezależnego. Wypowiedzenie pracownicy w 12. tygodniu ciąży jest zakazane z KP art. 41 - chyba że spełnione są przesłanki KP art. 52, które jednak wymagają zgody zarządu związku zawodowego, jeśli pracownica jest jego członkiem.

Każde rozgałęzienie generuje nowe terminy, nowych uczestników, nowe obowiązki dokumentacyjne. W spółce z 1500 pracownikami w każdym momencie toczy się od 15 do 40 spraw relacji pracowniczych równolegle - kary porządkowe, postępowania antymobbingowe, zgłoszenia sygnalistów, sprawy dyskryminacyjne, przygotowania wypowiedzeń. Każda w innej fazie, z innymi terminami, innymi uczestnikami.

HR Business Partnerzy, którzy te sprawy prowadzą, są jednocześnie partnerami swoich obszarów biznesowych - prowadzą rozmowy rozwojowe, towarzyszą rekrutacjom, wspierają zmiany organizacyjne. Prowadzenie spraw idzie obok. W kalendarzach Outlook, w osobistych notatkach, w pamięci.

Gdy konsultacja ze związkiem zawodowym z KP art. 38 wypada trzy dni przed planowanym wypowiedzeniem, zaczyna się gorączka. A gorączka produkuje dokładnie te błędy, które przesądzają o sprawach przed Sądem Pracy: niekompletny opis stanu faktycznego, brakujące pouczenie z KP art. 264, pochopne wypowiedzenie przed upływem 5-dniowego terminu opinii związku.

## Co zmienia agent

Agent nie zastępuje ekspertyzy prawa pracy. Zastępuje ręczne sterowanie procesowe, które w praktyce zawodzi.

**Sterowanie proceduralne per typ sprawy.** Przy założeniu sprawy HR Business Partner wybiera typ: kara porządkowa, mobbing, zgłoszenie sygnalisty, dyskryminacja, wypowiedzenie. Reguły ładują odpowiednią strukturę proceduralną z Kodeksu Pracy ze wszystkimi krokami, uczestnikami i terminami. Każde rozgałęzienie - sprzeciw pracownika z KP art. 112, opinia negatywna związku z KP art. 38, weryfikacja statusu sygnalisty z Ustawy z 14.06.2024, kontrola ochrony z KP art. 41 - jest modelowane jako ścieżka. Następny wymagany krok jest zawsze widoczny, a podstawa prawna każdej akcji jest udokumentowana.

**Automatyczne obliczanie terminów ustawowych.** Terminy nie są ustalane ręcznie. Termin 2 tygodni z KP art. 109 par. 1 biegnie od udokumentowanej daty powzięcia wiadomości - nie od daty zgłoszenia, nie od daty naruszenia. Termin 21 dni z KP art. 264 biegnie od udokumentowanej daty doręczenia z pouczeniem. Termin 5 dni opinii związku z KP art. 38 biegnie od pełnego powiadomienia. Każdy termin generuje stopniowane przypomnienia - nie jako pojedynczy mail ginący w skrzynce, lecz jako eskalacja angażująca dyrektora HR i radcę prawnego przy braku reakcji.

**Kontrola ochrony sygnalistów i pracowników szczególnych grup.** Przy każdym wszczęciu postępowania dyscyplinarnego agent sprawdza dwa rejestry: rejestr sygnalistów z ostatnich 24 miesięcy (Ustawa z 14.06.2024) i rejestr pracowników chronionych z KP art. 41 i Ustawy z 12.02.1991 (ciąża, macierzyństwo, opiekunowie, niepełnosprawni, działacze związkowi). Przy zbiegu agent blokuje proces i wymaga eskalacji do radcy prawnego z udokumentowanym uzasadnieniem niezależności postępowania - dowód spoczywa na pracodawcy.

**Dokumentacja odporna na rewizję Sądu Pracy.** Każdy krok proceduralny jest protokołowany chronologicznie i niezmiennie zgodnie z RODO art. 30 (RAT): kto co kiedy udokumentował, kto jaką informację kiedy otrzymał, kto jaką decyzję kiedy podjął, jaka była podstawa prawna z Kodeksu Pracy. Nie jako tekst w aktach, lecz jako ustrukturyzowany zbiór danych wytrzymujący konfrontację z KP art. 264 przed Sądem Pracy. Gdy sędzia pyta, czy reprezentatywny związek zawodowy otrzymał pełne powiadomienie z KP art. 38 - jest odpowiedź ze znacznikiem czasu. Gdy zarzut dotyczy odwetu na sygnaliście - jest udokumentowane uzasadnienie niezależne od zgłoszenia.

## Gdzie leżą decyzje

Agent nie podejmuje żadnej decyzji z zakresu prawa pracy. Żadnej. RODO art. 22 zakazuje decyzji w pełni zautomatyzowanych w sprawach pracowniczych. Czy kara porządkowa z KP art. 108 zostanie nałożona, czy zarzut mobbingu zostanie potwierdzony przez komisję z KP art. 94-3, czy wypowiedzenie z KP art. 30 lub rozwiązanie bez wypowiedzenia z KP art. 52 jest zasadne, czy zaproponować mediację zgodnie z Ustawą o promocji zatrudnienia z 20.04.2004 - to pozostaje przy człowieku. Przy HR Business Partnerze, dyrektorze HR, radcy prawnym, zarządzie z odpowiedzialnością z KSH art. 233.

Co agent steruje: ramę proceduralną. Zapewnia, że żaden krok nie zostanie zapomniany, żaden termin z KP art. 109 lub art. 264 nie upłynie, dokumentacja jest kompletna zanim decyzja zostanie podjęta, ochrona sygnalisty z Ustawy z 14.06.2024 jest weryfikowana przed każdym postępowaniem dyscyplinarnym. Decyzja sama leży tam, gdzie powinna - przy człowieku znającym stan faktyczny i ponoszącym odpowiedzialność przed Sądem Pracy.

## Kiedy się to opłaca

Arytmetyka ma dwie strony. Widoczna: mniej godzin na monitoring terminów, mniej zapytań do radcy prawnego, szybsze zamknięcia postępowań. Przy 25 równoległych sprawach i godzinie koordynacji na sprawę tygodniowo to ponad 1000 godzin rocznie - liczone po średniej stawce HR Business Partnera ok. 18 000 zł brutto miesięcznie.

Niewidoczna, ale decydująca: postępowanie, które nie zostaje przegrane przed Sądem Pracy. Wypowiedzenie, które nie upada na pominiętej konsultacji z reprezentatywnym związkiem zawodowym z KP art. 38. Procedura antymobbingowa z KP art. 94-3 przeprowadzona prawidłowo, zabezpieczająca pracodawcę przed pozwem cywilnym o naruszenie dóbr osobistych. Postępowanie dyscyplinarne wobec sygnalisty udokumentowane jako niezależne od zgłoszenia z Ustawy z 14.06.2024. Odszkodowanie, które nie zostaje zapłacone, bo akta są kompletne.

Średnie odszkodowanie w sprawach o przywrócenie do pracy w Polsce wynosi od 3 do 6 miesięcznych wynagrodzeń, a do tego dochodzi pełne wynagrodzenie za czas pozostawania bez pracy wraz z odsetkami ustawowymi. Przy menedżerze z 12-letnim stażem i wynagrodzeniem 35 000 zł miesięcznie to od 105 000 zł do 210 000 zł - za jedną sprawę. Dochodzą koszty radcy prawnego (10-30 tys. zł za instancję), wewnętrzne nakłady, kara PIP do 30 000 zł z KP art. 281, kara UODO do 4 procent obrotu przy naruszeniu poufności akt RODO art. 9, ryzyko reputacyjne i utrata produktywności zespołu w trakcie procesu sądowego trwającego 18-36 miesięcy łącznie z apelacją.

Jedno uniknięte odszkodowanie refinansuje całą infrastrukturę zarządzania sprawami relacji pracowniczych.

--- Employee Self-Service Agent ---
> Platforma samoobsługowa pracownicza zgodna z RODO art. 12-22, KP art. 22-1+94+233, Ustawą o aktach osobowych z 1.10.2018 i eIDAS - wnioski urlopowe, paski wynagrodzeń, kwalifikowany podpis Autenti.

Poniedziałek rano, 8:14. Na liście płac z piątku jest pozycja, której pracownik nie potrafi przyporządkować. Pisze maila do HR. We wtorek dostaje potwierdzenie odbioru. W środę pytanie zwrotne, czy chodzi o listę z bieżącego miesiąca. W czwartek odpowiedź: to była korekta PPK, którą sam wnioskował w styczniu. Cztery dni na informację, którą można było pobrać z systemu payroll w 20 sekund.

Ten przypadek nie jest wyjątkiem. Jest stanem normalnym. I nie chodzi tu tylko o produktywność - chodzi o realizację prawa dostępu pracownika z RODO art. 15, którego termin ustawowy wynosi 30 dni, a kara za naruszenie to do 4 procent rocznego obrotu firmy.

## Cicha przeciążenie w HR Service Center

W firmie z 2000 pracownikami wpływa miesięcznie od 800 do 1200 zapytań HR. To stany urlopowe z KP art. 161, paski wynagrodzeń z KP art. 80, zaświadczenia o zatrudnieniu, pytania o benefity, formularze podatkowe PIT-2 i PIT-12, informacje o terminach, pytania o status wniosku chorobowego z KP art. 92. Badania branżowe pokazują: około 60 do 80 procent tych zapytań jest merytorycznie trywialnych. Odpowiedź stoi w systemie kadrowym, regulaminie pracy lub układzie zbiorowym. Nikt nie musi myśleć, rozważać ani decydować. Mimo to każde pojedyncze zapytanie wiąże średnio 12 do 18 minut - otwarcie zgłoszenia, weryfikacja tożsamości, wywołanie systemu, sformułowanie odpowiedzi z odniesieniem do podstawy prawnej, dokumentacja zgodna z RODO art. 30 (RAT).

To się sumuje. Trzy pełne etaty, które w istocie pełnią funkcję ludzkiej wyszukiwarki między pracownikami a systemami HR. Nie dlatego, że pytania są trudne, lecz dlatego, że brakuje ścieżki dostępu z prawem RODO art. 15. Koszty jednego zapytania w wewnętrznych service deskach wynoszą średnio od 65 do 108 zł. Przy 900 zapytaniach miesięcznie i stopniu automatyzacji 70 procent wynika potencjał oszczędności od 540 000 do 760 000 zł rocznie - konserwatywnie licząc, bez kosztu ryzyka kary UODO za przekroczenie 30-dniowego terminu z RODO art. 12 i bez kosztu utraconych możliwości za sprawy, które czekają, bo service center jest zajęte informowaniem o zaległym urlopie.

## Trzy kategorie pytań, jeden katalog danych

Nie każde pytanie pracownika jest takie samo. Kluczowy krok to rozłożenie na kategorie z różną logiką obsługi - i wszystkie operują w zamkniętym katalogu danych z Kodeksu Pracy art. 22-1 i art. 22-1a:

```
Zapytanie wpływa
    │
    ├── PRAWO DOSTĘPU RODO art. 15 ─── Wgląd we własne dane natychmiast,
    │   Akta osobowe, paski wynagr.,    bez interwencji człowieka,
    │   PIT-11, salda urlopowe          termin 30 dni z RODO art. 12
    │
    ├── WNIOSEK TRANSAKCYJNY ────── Walidacja + przygotowanie,
    │   Urlop KP art. 161,             podpis Autenti eIDAS,
    │   chorobowe KP art. 92,          akceptacja przy człowieku
    │   zaświadczenie, PIT-2
    │
    └── ZGŁOSZENIE LUB OSĄD ──── Eskalacja do specjalisty,
        Mobbing KP art. 94-3,            kanał sygnalistów AAI,
        sygnalista (Ust. 14.06.2024)     komisja antymobbingowa
```

Prawo dostępu z RODO art. 15 stanowi największą część i jest w pełni automatyzowalne. Wymaga uwierzytelnienia przez SSO firmowe lub kwalifikowany podpis Autenti, dostępu odczytu do systemów źródłowych - Comarch HR, enova365, Symfonia, SAP SuccessFactors, integracji z PUE ZUS dla zwolnień e-ZLA - oraz koncepcji uprawnień zapewniającej, że każdy widzi tylko własne dane z katalogu KP art. 22-1.

Wnioski transakcyjne to drugi duży blok. Tu agent waliduje formularz wobec zdigitalizowanego regulaminu pracy i Kodeksu Pracy: wniosek urlopowy z KP art. 161 wymaga salda urlopowego i braku kolizji z innymi wnioskami zespołu, chorobowe z KP art. 92 wymaga e-ZLA z PUE ZUS, zaświadczenie o zatrudnieniu wymaga podpisu kwalifikowanego Autenti zgodnego z eIDAS 910/2014. Decyzja akceptacji pozostaje przy przełożonym lub HR.

Zgłoszenia i pytania wymagające osądu to reszta. Dziesięć do dwudziestu procent, ale dokładnie te przypadki, które wymagają natychmiastowej eskalacji: zgłoszenie antymobbingowe z KP art. 94-3 do komisji w terminie 7 dni, zgłoszenie sygnalisty z Ustawy z 14.06.2024 do dedykowanego kanału z 24-miesięczną ochroną przed odwetem, dyskryminacja z KP art. 18-3a do RPO i Pełnomocnika ds. Równego Traktowania.

## Dlaczego portale dokumentów nie wystarczają

Większość polskich firm ma już portale samoobsługowe. Mimo to wolumen zgłoszeń pozostaje wysoki, a UODO regularnie nakłada kary za przekroczenie 30-dniowego terminu z RODO art. 12. Powód jest prawie zawsze ten sam: portal nie odpowiada na pytania - oferuje formularze i PDF-y regulaminu. Kto chce wiedzieć, czy urlop okolicznościowy z okazji ślubu przysługuje też przy ślubie cywilnym za granicą, znajduje w portalu PDF regulaminu pracy. Ale nie odpowiedź dopasowaną do własnej sytuacji.

Różnica między portalem dokumentów a agentem samoobsługowym to różnica między biblioteką a doradcą. Obaj mają tę samą wiedzę. Ale tylko jeden rozumie pytanie, sprawdza dane pracownika z KP art. 22-1, stosuje regułę z regulaminu i daje odpowiedź pasującą do konkretnego przypadku - z odniesieniem do podstawy prawnej, jak wymaga RODO art. 12 (transparentność).

To fundamentalnie zmienia oczekiwania pracowników i dotrzymanie terminów ustawowych. Kto w ciągu sekund otrzymuje poprawną, opartą na źródle odpowiedź, nie otwiera zgłoszenia. W projektach z odpowiadającymi systemami samoobsługowymi wolumen zgłoszeń HR regularnie spada o ponad połowę, a termin 30 dni z RODO art. 12 jest dotrzymany w 100 procent przypadków. Pozostałe zapytania to te wymagające ludzkiego osądu - i wreszcie dostają uwagę, na którą zasługują.

## Co zmienia agent

Agent nie zastępuje ekspertyzy HR. Zastępuje ręczną wyszukiwarkę między pracownikiem a systemem kadrowym, która w praktyce zawodzi przy 900 zapytaniach miesięcznie.

**Uwierzytelnienie z MFA i kwalifikowanym podpisem.** Dostęp do danych z katalogu KP art. 22-1 i art. 22-1a wymaga uwierzytelnienia przez SSO firmowe i MFA z minimum 2 czynnikami. Wnioski o skutku prawnym - zaświadczenie o zatrudnieniu, oświadczenie PIT-2, zgoda RODO - wymagają kwalifikowanego podpisu eIDAS przez Autenti, lidera polskiego rynku zgodnego z Rozporządzeniem 910/2014 i Ustawą o usługach zaufania z 5.09.2016. Sygnatura jest równoważna podpisowi własnoręcznemu, a archiwum jest niezmienne z znacznikiem czasu.

**Walidacja wobec katalogu danych pracowniczych.** Agent przy każdym żądaniu sprawdza, czy dane mieszczą się w zamkniętym katalogu KP art. 22-1 (imię, nazwisko, PESEL, adres, wykształcenie, przebieg zatrudnienia) lub art. 22-1a (dodatkowe dane za zgodą pracownika). Żądania wykraczające poza katalog są odrzucane - agent nie może udostępnić danych nie objętych ustawą, naruszenie oznacza karę UODO i pozew pracownika z RODO art. 82.

**Generowanie paska wynagrodzenia z pełną transparencją.** Pasek z KP art. 80 zawiera wynagrodzenie brutto, składki ZUS (emerytalna 9,76 procent, rentowa 1,5 procent, chorobowa 2,45 procent, wypadkowa 0,67-3,33 procent indywidualna na PKD), zaliczki PIT z Polskiego Ładu 2.0 (12 procent do 120 000 zł, 32 procent powyżej, kwota wolna 30 000 zł), PPK (pracownik 2 procent, pracodawca 1,5 procent), potrącenia z KPC art. 871-882 z priorytetem alimentacyjnym z KPC art. 1083. Reguły są deterministyczne - błędny pasek narusza KP art. 80 i podlega kontroli PIP z karą do 30 000 zł.

**Eskalacja zgłoszeń antymobbingowych i sygnalistów.** Przy rozpoznaniu zgłoszenia naruszenia agent natychmiast przekierowuje do dedykowanego kanału z pełną ochroną poufności RODO art. 9 i art. 88. Sygnalista z Ustawy z 14.06.2024 uzyskuje 24-miesięczną ochronę przed odwetem, a postępowanie dyscyplinarne wszczęte po zgłoszeniu wymaga uzasadnienia niezależnego od zgłoszenia. Mobbing z KP art. 94-3 trafia do komisji powoływanej w terminie 7 dni, dyskryminacja z KP art. 18-3a do Pełnomocnika ds. Równego Traktowania. Każde zgłoszenie jest dokumentowane niezmiennie - dowód przy ewentualnym pozwie cywilnym o naruszenie dóbr osobistych.

**Dostępność WCAG 2.1 AA dla każdego pracownika.** Ustawa o dostępności cyfrowej z 4.04.2019 wymaga WCAG 2.1 AA dla sektora publicznego, spółek z udziałem publicznym i podmiotów świadczących usługi powszechne. Agent renderuje wszystkie odpowiedzi i formularze zgodnie ze standardem: kontrast minimum 4,5:1, struktura nagłówków, alternatywy tekstowe, obsługa czytników ekranu NVDA i JAWS, nawigacja klawiaturą. Niezgodność oznacza karę administracyjną i pozew z Ustawy o równym traktowaniu z 03.12.2010.

## Gdzie leżą decyzje

Agent nie podejmuje żadnej decyzji wpływającej na warunki zatrudnienia. Żadnej. RODO art. 22 zakazuje decyzji w pełni zautomatyzowanych w sprawach pracowniczych. Czy urlop z KP art. 161 zostanie zatwierdzony, czy zaświadczenie o zatrudnieniu zostanie wystawione, czy wniosek o urlop bezpłatny zostanie przyjęty, czy zgłoszenie antymobbingowe z KP art. 94-3 jest zasadne - to pozostaje przy człowieku. Przy przełożonym, specjaliście HR, komisji antymobbingowej, Pełnomocniku ds. Sygnalistów, Inspektorze Ochrony Danych, zarządzie z odpowiedzialnością z KSH art. 233.

Co agent steruje: warstwę informacyjno-transakcyjną. Zapewnia, że pracownik uzyskuje natychmiastowy dostęp do własnych danych w terminie z RODO art. 12, że żądanie mieści się w katalogu KP art. 22-1, że pasek wynagrodzenia jest wygenerowany prawidłowo z KP art. 80, że wniosek transakcyjny jest kompletny zanim trafi do przełożonego, że zgłoszenie sygnalisty z Ustawy z 14.06.2024 jest natychmiast eskalowane z aktywacją 24-miesięcznej ochrony, że dostępność WCAG 2.1 AA jest dotrzymana. Decyzja sama leży tam, gdzie powinna - przy człowieku ponoszącym odpowiedzialność z KP art. 233 i KSH art. 233.

## Infrastruktura stojąca za odpowiedzią

Ten agent to nie tylko zysk produktywności dla service center. Buduje fundamenty infrastruktury cyfrowej HR potrzebne każdemu kolejnemu agentowi:

**Rozpoznawanie intencji** uczy się kategoryzować pytania pracowników w języku polskim z uwzględnieniem terminologii KP. Ten model jest reużywany przez Onboarding Agent, Leave of Absence Agent, Compliance Training Agent i Employee Relations Case Agent.

**Koncepcja uprawnień RODO art. 32** definiuje, która rola widzi jakie dane z katalogu KP art. 22-1 i art. 22-1a. Raz zbudowana, obowiązuje dla każdej funkcji samoobsługowej w każdej kolejnej fazie - od onboardingu po ustanie zatrudnienia.

**Routing eskalacji** określa, dokąd trafiają sprawy, które nie mogą być rozwiązane samoobsługowo. Ten routing po temacie (mobbing KP art. 94-3, sygnalista Ustawa 14.06.2024, dyskryminacja KP art. 18-3a, decyzja z RODO art. 22), lokalizacji (Pełnomocnik ds. Sygnalistów, komisja antymobbingowa, AAI Niezależna Ochrona Sygnalistów, RPO) i poziomie eskalacji stanowi fundament każdego przekazania agent-człowiek w całym [Decision Layer](/pl/decision-layer/).

**Kwalifikowany podpis elektroniczny eIDAS** przez Autenti staje się standardem dla wszystkich dokumentów pracowniczych o skutku prawnym. Raz zintegrowany, służy każdemu kolejnemu agentowi - Contract Agent, Performance Review Agent, Compensation Agent.

Dlatego ten agent stoi na początku. Nie dlatego, że jest najbardziej spektakularny, lecz dlatego, że dostarcza infrastrukturę, na której opiera się wszystko kolejne - i jednocześnie najbardziej widoczny dowód, że inwestycja się opłaca. Każdego dnia, od pierwszego poniedziałku po uruchomieniu, w pełnej zgodności z RODO, Kodeksem Pracy, Ustawą o aktach osobowych z 1.10.2018, Rozporządzeniem eIDAS i Ustawą o dostępności cyfrowej z 4.04.2019.

--- Equipment Provisioning Agent ---
> Provisioning sprzętu IT zgodny z KP art. 207+211+226-227 (BHP), Rozporządzeniem VDU z 1.12.1998, Ustawą o krajowym systemie cyberbezpieczeństwa (NIS2) oraz RODO art. 25+32 - laptop, telefon, ergonomia stanowiska, MDM Microsoft Intune, śledzenie cyklu życia aktywów.

Poniedziałek rano, pierwszy dzień nowej pracy. Pracownik przychodzi do biura, dostaje pustą lawkę. Laptop nie został zamówiony - HR wysłał maila do IT w piątek po południu, IT eskalował do zakupów we wtorek, zakupy czekają na potwierdzenie modelu. Krzesło jest za niskie, monitor stoi pod złym kątem, brak podkładki pod nadgarstki. Pracownik podpisuje protokół przekazania sprzętu, którego nie dostał. Trzy tygodnie później kontrola PIP stwierdza naruszenie KP art. 207 (sprawne narzędzia pracy) i Rozporządzenia VDU z 1.12.1998 (ergonomia stanowiska komputerowego). Kara 18 000 zł.

Ten przypadek nie jest wyjątkiem. Jest stanem normalnym. I nie chodzi tu tylko o produktywność - chodzi o realizację obowiązków pracodawcy z Kodeksu Pracy art. 207 i art. 226-227 oraz Rozporządzenia VDU z 1.12.1998, których naruszenie podlega kontroli PIP z karą do 30 000 zł, a w sektorach regulowanych (NIS2) dodatkowo karze do 10 milionów euro za błędną konfigurację cyberbezpieczeństwa.

## Cicha kakofonia w pierwszym dniu

W firmie z 2000 pracownikami wpływa miesięcznie od 15 do 35 wniosków provisioningu sprzętu - nowe zatrudnienia, zmiany ról, wymiany po awarii, kontraktorzy B2B z KP art. 11-3, pracownicy z niepełnosprawnością wymagający sprzętu adaptacyjnego z dofinansowania PFRON. Każdy wniosek przechodzi przez minimum cztery działy: HR rejestruje zatrudnienie w Comarch HR, IT zamawia laptop i konfiguruje konta, zakupy negocjują dostawę z dostawcami, BHP weryfikuje ergonomię stanowiska wobec Rozporządzenia VDU z 1.12.1998. Inspektor Ochrony Danych zatwierdza politykę MDM, związki zawodowe konsultują wprowadzenie monitoringu z Ustawy z 23.05.1991, specjalista cyberbezpieczeństwa wgrywa konfigurację zgodną z NIS2.

To się sumuje. Średni koszt onboardingu IT w Polsce wynosi od 8 600 do 34 400 zł na pracownika - laptop biznesowy 6 000-12 000 zł, monitor 1 500-3 500 zł, krzesło z atestem CIOP-PIB 1 200-3 800 zł, telefon służbowy 2 000-5 000 zł, akcesoria ergonomiczne 800-2 200 zł, licencje oprogramowania 3 000-8 000 zł. Jedna trzecia tego ginie w niezgodności BHP, podwójnych zamówieniach, opóźnieniach dostaw i błędnej konfiguracji MDM. Przy 200 zatrudnieniach rocznie to potencjał oszczędności od 1 700 000 do 4 500 000 zł, bez kosztu kary PIP z KP art. 281 do 30 000 zł, bez kosztu chorobowego z chorób zawodowych (zespół cieśni nadgarstka, wady wzroku) i bez ryzyka kary UODO za naruszenie RODO art. 25 (privacy by design w MDM) lub kary NIS2 za niezgodność cyberbezpieczeństwa.

## Cztery wymiary zgodności w jednym pakiecie sprzętu

Provisioning sprzętu w Polsce nie jest tylko logistyką. Jest skrzyżowaniem czterech wymiarów regulacyjnych, których pominięcie generuje natychmiastowe ryzyko prawne:

```
Wyzwalacz provisioningu
    │
    ├── BHP - KP art. 207+226-227 ───── Pakiet zgodny z VDU 1.12.1998,
    │   Rozp. VDU 1.12.1998              ergonomia, atest CIOP-PIB,
    │   Rozp. szkolenia 27.07.2004       szkolenie BHP stanowiskowe
    │
    ├── RODO + MDM ─────────────────── Privacy by design RODO art. 25,
    │   Art. 22+25+88                    konsultacja związków zawodowych,
    │   Ustawa o związkach 23.05.1991    DPIA z RODO art. 35
    │
    ├── CYBERBEZPIECZEŃSTWO NIS2 ──── Antywirus, EDR, MFA, segmentacja,
    │   Ust. krajowy system cyber       zarządzanie podatnościami,
    │   z 5.07.2018                      zgłaszanie incydentów do CERT Polska
    │
    └── KOSZTY + PODATKI ──────────── Polski Ład 2.0, ZUS świadczenia
        Polski Ład 2.0                 rzeczowe, biała lista VAT,
        Ust. systemie ubezp. 13.10.1998  KSeF FA(2), MPP > 15 000 zł
```

Wymiar BHP jest nienegocjowalny. KP art. 207 wymaga dostarczenia sprawnych narzędzi pracy, art. 226-227 obowiązuje dostarczenie środków ochrony indywidualnej bez kosztów po stronie pracownika, Rozporządzenie z 1.12.1998 określa ergonomię stanowiska komputerowego (regulowane krzesło, oświetlenie 500 luksów, monitor ze statywem regulującym), Rozporządzenie z 27.07.2004 wymaga szkolenia stanowiskowego BHP przed dopuszczeniem do pracy. PIP może wejść z kontrolą w każdej chwili - kara z KP art. 281 do 30 000 zł, a w przypadku choroby zawodowej (zespół cieśni nadgarstka z RVS) odpowiedzialność z ZUS.

Wymiar RODO i MDM jest najbardziej polityczny. Każda nowa polityka MDM (Microsoft Intune, Jamf Pro, VMware Workspace ONE) wymaga konsultacji z reprezentatywnym związkiem zawodowym z Ustawy z 23.05.1991, DPIA z RODO art. 35 dla systematycznego monitoringu, privacy by design z RODO art. 25 (separacja kontenera służbowego od prywatnego, ograniczenie danych do minimum), informacji dla pracownika z KP art. 22-2. Naruszenie oznacza karę UODO do 4 procent obrotu i pozew z RODO art. 82.

Wymiar cyberbezpieczeństwa NIS2 jest najnowszy i najmocniejszy w sankcjach. Ustawa o krajowym systemie cyberbezpieczeństwa z 5.07.2018 (transpozycja Dyrektywy NIS2) nakłada obowiązki na podmioty kluczowe (energetyka, bankowość, zdrowie, telekomunikacja, transport) i ważne (digital providers, produkcja krytyczna). Sprzęt pracowniczy w tych sektorach musi mieć: antywirus z aktualizacjami, EDR, MFA, automatyczne aktualizacje, zarządzanie podatnościami z CVSS, segmentację sieci. Incydenty zgłaszane do CERT Polska w 24 godziny. Kara sięga 10 milionów euro lub 2 procent rocznego obrotu, a do tego dochodzi osobista odpowiedzialność zarządu z KSH art. 233.

Wymiar kosztowy i podatkowy wymaga precyzji. Polski Ład 2.0 wpływa na rozliczenie sprzętu mieszanego (BYOD) - składki ZUS od użytku prywatnego, zaliczka PIT (12 procent do 120 000 zł, 32 procent powyżej). Faktury zakupu sprzętu wymagają weryfikacji białej listy VAT (whitelist.gov.pl), KSeF FA(2) od 1.07.2026, MPP dla kwot powyżej 15 000 zł.

## Dlaczego email i Excel nie wystarczają

Większość polskich firm zarządza provisioningiem sprzętu przez email i Excel - HR wysyła plik z listą nowych pracowników do IT, IT przepisuje do swojego systemu zgłoszeniowego, zakupy dostają osobny mail z modelami, BHP dostaje zapytanie ad-hoc, Inspektor Ochrony Danych dowiaduje się dopiero przy konfiguracji MDM. Każdy z tych przekazań jest okazją do błędu: zapomniany pracownik, zły model laptopa, brak konsultacji ze związkami przed wdrożeniem nowej polityki, niezarejestrowany sprzęt w IT Asset Management, brak szkolenia BHP stanowiskowego.

Różnica między emailowym chaosem a agentem orkiestrującym to różnica między ratowaniem każdego przypadku z osobna a deterministyczną infrastrukturą. Agent nie wymyśla pakietu sprzętu - czyta regułę z polityki firmy zgodną z VDU z 1.12.1998. Nie pyta o stan magazynowy - integruje się z Comarch IT Asset, ServiceNow ITAM lub Snipe-IT i widzi w czasie rzeczywistym. Nie negocjuje z dostawcą - generuje zamówienie w SAP Ariba lub Workday Procurement z weryfikacją białej listy VAT. Nie pomija konsultacji ze związkami - eskaluje proces do dialogu społecznego automatycznie. Nie zapomina o szkoleniu BHP - aktywuje moduł szkoleniowy zgodny z Rozporządzeniem z 27.07.2004 przed wręczeniem sprzętu.

W projektach z systemami orkiestrującymi czas przygotowania stanowiska spada z 10-14 dni do 2-3 dni, koszt onboardingu IT spada o 25-35 procent, niezgodność BHP w kontroli PIP spada do zera, a incydenty cyberbezpieczeństwa NIS2 są wykrywane w 24 godzinach (wymóg ustawowy).

## Co zmienia agent

Agent nie zastępuje ekspertyzy IT, BHP, Inspektora Ochrony Danych ani CISO. Zastępuje ręczną koordynację między czterema do siedmiu działami, która w praktyce zawodzi przy 25 wnioskach miesięcznie.

**Pakiet sprzętu zgodny z VDU z 1.12.1998.** Agent automatycznie wybiera pakiet według roli: laptop biznesowy minimum 14 cali, monitor z regulowanym statywem, klawiatura ergonomiczna, mysz, słuchawki, krzesło z atestem CIOP-PIB, podkładka pod nadgarstki, oświetlenie 500 luksów, telefon służbowy. Każdy element ma certyfikat CE i instrukcję w języku polskim. Niezgodność oznacza karę PIP do 30 000 zł i ryzyko choroby zawodowej.

**Konfiguracja MDM z privacy by design RODO art. 25.** Microsoft Intune, Jamf Pro lub VMware Workspace ONE są konfigurowane z separacją kontenera służbowego od prywatnego, szyfrowaniem BitLocker/FileVault, VPN, MFA, blokadą portów USB. Monitoring ograniczony do logów technicznych - bez treści, bez lokalizacji prywatnej. DPIA z RODO art. 35 dokumentuje proporcjonalność. Konsultacja ze związkami z Ustawy z 23.05.1991 jest aktywowana automatycznie przed deploymentem.

**Polityka cyberbezpieczeństwa NIS2.** Sprzęt w podmiotach kluczowych i ważnych otrzymuje konfigurację zgodną z Ustawą z 5.07.2018: antywirus, EDR, MFA, segmentacja sieci, zarządzanie podatnościami. Każde urządzenie jest klasyfikowane według ryzyka i monitorowane w SIEM zintegrowanym z Krajowym Systemem Cyberbezpieczeństwa. Incydenty zgłaszane do CERT Polska w 24 godziny.

**Kanał sygnalistów oddzielony od kontenera służbowego.** Aplikacja kanału z Ustawy z 14.06.2024 jest pre-instalowana w architekturze chroniącej tożsamość: oddzielny kontener niewidoczny dla MDM, ruch przez VPN, brak logów w SIEM. AAI może kontrolować zgodność. Sygnalista uzyskuje 24-miesięczną ochronę przed odwetem.

**Sprzęt adaptacyjny dla pracowników z niepełnosprawnością.** Agent identyfikuje potrzeby, konsultuje z lekarzem medycyny pracy i przygotowuje wniosek do PFRON o dofinansowanie do 25 000 zł. Pakiet może obejmować czytniki NVDA i JAWS, klawiatury Braille'a, oprogramowanie powiększające, sterowanie głosem. Sektor publiczny ma dodatkowy obowiązek WCAG 2.1 AA z Ustawy z 4.04.2019.

**Cykl życia aktywu w IT Asset Management.** Każdy sprzęt jest rejestrowany w Comarch IT Asset, ServiceNow ITAM lub Snipe-IT z numerem seryjnym, wartością bilansową i kosztem uzyskania z Polskiego Ładu 2.0. Faktury weryfikowane wobec białej listy VAT i KSeF FA(2). Zwrot przy offboardingu jest deterministyczny: czyszczenie danych DoD 5220.22-M lub NIST 800-88 Purge, wyrejestrowanie w MDM, prawo do bycia zapomnianym z RODO art. 17.

## Gdzie leżą decyzje

Agent nie podejmuje decyzji, które wpływają na warunki zatrudnienia. Czy wprowadzić MDM monitorujący lokalizację, czy rozszerzyć politykę cyberbezpieczeństwa, czy zatwierdzić niestandardowe zamówienie, czy uznać sprzęt adaptacyjny za niezbędny, czy zwolnić pracownika, który zniszczył sprzęt - to pozostaje przy człowieku. Przy Inspektorze Ochrony Danych, CISO, dyrektorze IT, dyrektorze HR, lekarzu medycyny pracy, zarządzie z odpowiedzialnością z KSH art. 233.

Co agent steruje: warstwę logistyczno-konfiguracyjną. Zapewnia, że pakiet sprzętu jest zgodny z VDU z 1.12.1998, że konfiguracja MDM realizuje privacy by design z RODO art. 25, że polityka cyberbezpieczeństwa spełnia NIS2, że konsultacje ze związkami z Ustawy z 23.05.1991 są przeprowadzone, że szkolenie BHP z Rozporządzenia z 27.07.2004 jest aktywowane, że sprzęt adaptacyjny jest zgłoszony do PFRON, że cykl życia aktywu jest dokumentowany w IT Asset Management, że zwrot przy offboardingu czyści dane zgodnie z RODO art. 17. Decyzja sama leży tam, gdzie powinna - przy człowieku ponoszącym odpowiedzialność z KP art. 207, KSH art. 233 i Ustawy o krajowym systemie cyberbezpieczeństwa.

## Infrastruktura stojąca za sprzętem

Ten agent to nie tylko zysk produktywności dla IT Service Desk. Buduje fundamenty infrastruktury cyfrowej cyklu życia sprzętu potrzebne każdemu kolejnemu agentowi:

**Standaryzacja pakietów BHP** uczy się reguł VDU z 1.12.1998 i atestów CIOP-PIB. Ten model jest reużywany przez Workplace Health Agent, Hybrid Work Agent (home office wymaga audytu ergonomii w domu z KP art. 207-1), Travel Equipment Agent (sprzęt na delegacje).

**Konfiguracja MDM z RODO art. 25** definiuje standard separacji kontenera służbowego od prywatnego dla wszystkich urządzeń. Raz zbudowana, obowiązuje dla każdego agenta dotykającego MDM - Onboarding Workflow Agent, Offboarding Agent, BYOD Policy Agent.

**Polityka cyberbezpieczeństwa NIS2** staje się szablonem dla każdego sprzętu w podmiotach kluczowych i ważnych. Ten routing klasyfikacji ryzyka, integracji z SIEM i zgłaszania incydentów do CERT Polska stanowi fundament każdego systemu cyberbezpieczeństwa w całym [Decision Layer](/pl/decision-layer/).

**IT Asset Management i Audit Trail** dokumentują każdy etap cyklu życia urządzenia od zakupu do utylizacji. Wykorzystywane przez Decision Layer do zapewnienia możliwości śledzenia każdego sprzętu w organizacji - kluczowe dla obrony przed roszczeniami z KP art. 124, audytu PIP, kontroli UODO i wymogów NIS2.

Dlatego ten agent stoi na początku. Nie dlatego, że jest najbardziej spektakularny, lecz dlatego, że dostarcza infrastrukturę, na której opiera się wszystko kolejne - i jednocześnie najbardziej widoczny dowód, że inwestycja się opłaca. Każdego pierwszego dnia pracy, w pełnej zgodności z Kodeksem Pracy, RODO, Rozporządzeniem VDU z 1.12.1998, Ustawą o krajowym systemie cyberbezpieczeństwa (NIS2), Ustawą o ochronie sygnalistów z 14.06.2024 i Ustawą o dostępności cyfrowej z 4.04.2019.

--- Executive Recruiting Agent ---
> Executive Search C-Suite zgodny z KSH art. 201, GPW DPSN 2021 i EU AI Act Aneks III(4)(a) - poufny workflow z Sedlak & Sedlak benchmarkingiem, AML KYC i pełnym śladem audytowym dla KNF.

Według Russell Reynolds Global CEO Turnover Index 2025 wczesne odejścia CEO w pierwszych 30 do 36 miesiącach wzrosły o 79 procent rok do roku - drugi rok sprawowania funkcji jest najbardziej krytycznym punktem ryzyka, gdzie CEO odchodzą około trzy razy częściej niż w pierwszym roku. Dla firmy z 2000 pracownikami obsadzającej rocznie 2-3 pozycje na poziomie zarządu lub dyrektora pionu oznacza to: statystycznie co roku co najmniej jedna z nich kończy się niepowodzeniem.

Koszty bezpośrednie - odprawa, ponowne poszukiwania, honorarium agencji 25-35 procent rocznego wynagrodzenia docelowego - to od 200 000 do 400 000 EUR (860 000-1 720 000 zł) za jedną pomyłkę. Koszty pośrednie - utrata ciągłości strategii, niepewność w zespole zarządzającym, odchodzący kluczowi pracownicy - są wielokrotnie wyższe. Naruszenie KSH art. 304 (skład rady nadzorczej spółek publicznych) skutkuje korektą KNF, niezgodność z DPSN 2021 obniża rating ESG, brak AML KYC dla zarządu banku oznacza odmowę EBA Senior-Manager-Approval i sankcję KNF do 21 milionów zł, naruszenie EU AI Act Article 99 to sankcja do 15 milionów euro lub 3 procent rocznego obrotu globalnego.

Kto zna te liczby i mimo to nie ma ustrukturyzowanego procesu, nie prowadzi rekrutacji. Prowadzi kontrolowany hazard.

## Pięć regulacyjnych warstw w jednym powołaniu zarządu

Powołanie członka zarządu w polskiej spółce publicznej nie jest tylko procesem rekrutacyjnym. Jest skrzyżowaniem pięciu warstw regulacyjnych, których pominięcie generuje natychmiastowe ryzyko prawne i sankcje:

```
Zlecenie Komitetu Nominacji
    │
    ├── KSH art. 199-208 + 304 ────── Powołanie zarządu z uchwały Rady Nadzorczej
    │   GPW DPSN 2021                   lub Walnego Zgromadzenia, niezależność,
    │   Kodeks Władztwa Korpor. skład rady spółek publicznych
    │
    ├── EU AI Act III(4)(a) ────────── System wysokiego ryzyka, zarządzanie ryzykiem,
    │   Article 9+13+14+26              transparentność, nadzór ludzki,
    │   Article 99 sankcja              monitoring, dokumentacja techniczna
    │
    ├── Ustawa o ofercie publicz. ──── Raport bieżący do KNF w 24 godziny,
    │   z 29.07.2005                    DPSN 2021, sankcja do 21 milionów zł,
    │   Rozp. MF z 29.03.2018           publikacja ESPI
    │
    ├── AML KYC + AI ────────────────── Beneficial Ownership, Source of Wealth,
    │   Ust. z 1.03.2018                Source of Funds, PEP z list GIIF,
    │   GIIF + KNF + EBA                EBA Senior-Manager-Approval
    │
    └── Pay Transparency 2023/970 ──── Polityka wynagrodzeń z KSH art. 282,
        Sedlak & Sedlak surveys         ujawnienie luki płacowej, individual
        Mercer/Aon/Hay Group            pay disclosure CEO i CFO
```

Warstwa Corporate Governance jest fundamentalna. KSH art. 199-201 reguluje powołanie zarządu spółki z o.o. (kompetencja zgromadzenia wspólników), art. 203-208 powołanie zarządu spółki akcyjnej (kompetencja rady nadzorczej, kadencja maksimum 5 lat), art. 215-216 skład rady nadzorczej (w spółkach publicznych minimum 5 członków), art. 219 komitet audytu rady spółek publicznych, art. 282 kompetencje wyłączne Walnego Zgromadzenia (zatwierdzanie polityki wynagrodzeń), art. 304 skład rady spółek publicznych (dwóch niezależnych członków), art. 233 odpowiedzialność członków zarządu z zasadą staranności sumiennego kupca. DPSN 2021 GPW dodaje wymogi niezależności, różnorodności, kompetencji audytowych. Warstwa EU AI Act jest najmocniejsza w sankcjach.

## Problem koordynacyjny pod powierzchnią

Większość wyjaśnień nieudanych nominacji sięga zbyt płytko. "Dopasowanie kulturowe się nie zgadzało." "Kandydat rozwinął się inaczej niż oczekiwano." "Rada nadzorcza nie była zgodna." To symptomy. Przyczyna leży w architekturze procesu.

Executive Search w polskim kontekście prawnym to jedyny proces HR, w którym siedem niezależnych stron musi być koordynowanych jednocześnie - i żadna nie może wiedzieć, co robi druga, zanim to konieczne. Komitet Nominacji i Wynagrodzeń przy radzie nadzorczej steruje 2-3 agencjami Executive Search (Korn Ferry, Heidrick & Struggles, Russell Reynolds, Spencer Stuart, Egon Zehnder, Boyden) równolegle, tak by nie wiedziały o sobie nawzajem. Rada nadzorcza wyznacza ramy poszukiwań, ale chce być zaangażowana dopiero przy shortliście. Kandydaci są często na niewypowiedzianych stanowiskach i nie mogą dowiedzieć się, kto jeszcze jest w procesie. Compliance Officer musi sprawdzać listy sankcji i konflikty interesów bez poszerzania niepotrzebnie kręgu osób znających kandydatów. Inspektor AML weryfikuje Beneficial Ownership i Source of Wealth z list GIIF. Inspektor Ochrony Danych zatwierdza zgodność z RODO i EU AI Act. Wreszcie Walne Zgromadzenie zatwierdza politykę wynagrodzeń z KSH art. 282.

To działa, dopóki doświadczony Przewodniczący Komitetu Nominacji trzyma cały proces w głowie. Ale zawodzi niezawodnie w trzech sytuacjach: gdy osoba koordynująca się zmienia, gdy proces trwa ponad 6 miesięcy (w PL z 3-6 miesięcznymi okresami wypowiedzenia kontraktów menedżerskich to standard), i gdy KNF pyta o status, a nikt nie potrafi przedstawić aktualnego stanu w wiarygodnej formie.

## Konfidencjonalność jako kwestia architektoniczna

W żadnym innym procesie HR wyciek informacji nie ma tak natychmiastowych konsekwencji prawnych. Gdy przedostanie się informacja, że spółka publiczna z indeksu WIG20 wymienia CFO, rynek reaguje natychmiast - inwestorzy nerwowieją, konkurenci wykorzystują niepewność, dotychczasowy CFO podejmuje decyzje pod presją własnego odejścia. Przedwcześnie ujawnione zmiany w spółkach giełdowych prowadzą do mierzalnych reakcji kursowych - nie ze względu na samą decyzję personalną, lecz ze względu na niepewność, którą wywołuje niekontrolowany przepływ informacji.

Taki wyciek narusza Ustawę o ofercie publicznej z 29.07.2005 - spółka jest zobowiązana do raportowania bieżącego materialnych zdarzeń do KNF zanim trafią do mediów. Naruszenie skutkuje sankcją do 21 milionów zł i pozwami akcjonariuszy mniejszościowych. Dlatego konfidencjonalność musi być zakotwiczona w architekturze procesu: kto kiedy ma dostęp do jakiej informacji, kto widzi nazwiska kandydatów a kto tylko zanonimizowane profile (kody K-001, K-002), jak zapewnić feedback agencji bez ujawniania nazwiska Compliance, jak skoordynować rozmowy w lokalizacjach neutralnych bez wpisów w publicznych kalendarzach.

## Gdzie agent pracuje - i gdzie nie decyduje

Executive Recruiting Agent nie automatyzuje żadnej decyzji dotyczącej kandydata. Zatwierdzenie przez radę nadzorczą z KSH art. 203, profil poszukiwań, wybór agencji Executive Search, negocjacje kontraktu menedżerskiego, decyzja o powołaniu - to wszystko pozostaje ludzkie. Nie z ostrożności regulacyjnej, lecz dlatego, że te decyzje wymagają osądu Komitetu Nominacji, którego nie da się przełożyć na reguły, oraz odpowiedzialności członków rady nadzorczej z KSH art. 233 (zasada staranności sumiennego kupca). Co agent przejmuje, to warstwa koordynacyjna:

**Strukturyzowana ocena profili kandydatów C-Suite.** Gdy 3 agencje Executive Search dostarczają łącznie 12-18 profili, agent ocenia każdy strukturalnie względem wymagań DPSN 2021, niezależności z KSH art. 304, polityki różnorodności. Nie jako substytut osądu Komitetu Nominacji, lecz jako udokumentowana praca wstępna - każdy profil oceniany według tych samych kryteriów, zanim trafi do rady nadzorczej. **AML KYC i kontrola Compliance.** Weryfikacja PEP z GIIF, Beneficial Ownership w strukturach holdingowych, Source of Wealth (3-letnia historia majątku), Source of Funds dla pakietów powyżej 5 procent, konflikty interesów z bieżącą radą, zakazy konkurencji z KP art. 101-1 - sprawdzenia oparte na regułach, przy ręcznym wykonaniu produkujące błędy lub pomijane. **Konfidencjonalna koordynacja rozmów.** Dyskretna koordynacja terminów między radą nadzorczą a kandydatami na niewypowiedzianych stanowiskach to logistyka z najwyższym ryzykiem - zapomniane zaproszenie, widoczny wpis w kalendarzu Outlook, e-mail do błędnego odbiorcy może kosztować kandydata 50-150 procent rocznego wynagrodzenia (wycofanie) i pozew o naruszenie dóbr osobistych.

## Paradoks governance: wysokie ryzyko bez współdecydowania Rady Pracowników

Executive Search jest regulacyjną osobliwością. Z jednej strony: system wysokiego ryzyka według EU AI Act 2024/1689, Aneks III(4)(a). Każdy system używany do selekcji osób fizycznych do zatrudnienia podlega pełnej kaskadzie obowiązków - system zarządzania ryzykiem z Article 9, dokumentacja techniczna z Article 11, dane treningowe z Article 10, transparentność z Article 13, nadzór ludzki z Article 14, monitoring z Article 26. Z drugiej strony: powołanie kadry zarządzającej zazwyczaj nie podlega prawom konsultacyjnym Rady Pracowników (w polskim prawie wyłączenie zależy od konkretnego umocowania w regulaminach lub porozumieniach zbiorowych). Nie ma gremium kwestionującego kryteria selekcji. Brak zinstytucjonalizowanego głosu wskazującego na martwe punkty.

Właśnie dlatego dokumentacja musi być ściślejsza - nie dlatego, że wymaga tego ustawa, lecz dlatego, że decyzje o kadrze zarządzającej są częściej zaskarżane niż operacyjne zatrudnienia. Pozew z KSH art. 233 (odpowiedzialność członków zarządu), pozew akcjonariuszy mniejszościowych z naruszenia DPSN 2021, kontrola KNF spółek publicznych, audyt UODO systemów wysokiego ryzyka EU AI Act - każde z tych roszczeń wymaga pełnego śladu audytowego.

[Decision Layer](/pl/decision-layer/) wytwarza tę dokumentację jako produkt uboczny sterowania procesem. Każdy krok, każdy decydent (Człowiek lub Reguła), każde uzasadnienie z podstawą prawną jest protokołowane. Nie w oddzielnym systemie compliance dokarmiwanym post factum - lecz jako integralny element samego procesu, zgodny z RODO art. 30 (RAT), EU AI Act Article 12 (logging), KSH art. 233 (odpowiedzialność zarządu).

## Co infrastruktura daje innym agentom

Konfidencjonalna architektura komunikacyjna - segmentowane uprawnienia, anonimizowane profile, oddzielne kanały E2E z VPN, kontrakty NDA z agencjami - nie jest budowana wyłącznie dla Executive Search. Succession Planning Agent potrzebuje tej samej infrastruktury przy ocenie wewnętrznych następców bez ich wiedzy. Whistleblower Workflow Agent wykorzystuje konfidencjonalne kanały dla sygnalistów C-Suite z Ustawy z 14.06.2024. M&A Due Diligence Agent stosuje segmentację uprawnień w transakcjach pre-closing.

Modelowanie pakietów wynagrodzeń z Sedlak & Sedlak C-Suite Surveys oraz benchmarków Mercer i Aon zasila Compensation Benchmarking Agent dla wszystkich poziomów. AML KYC z Ustawy z 1.03.2018 jest reużywany przez Vendor Compliance Agent i Customer Onboarding Agent w sektorach regulowanych KNF. Workflow zatwierdzeń Komitetu Nominacji, rady nadzorczej i Walnego Zgromadzenia staje się szablonem dla każdej decyzji Corporate Governance - powołania prokurenta, zmiany statutu, zatwierdzenia transakcji z podmiotami powiązanymi.

Decision Logging zgodne z EU AI Act Article 12, RODO art. 30 i KSH art. 233 buduje Audit Trail wykorzystywany przez Decision Layer - kluczowe dla obrony przed pozwami z KP art. 18-3a (dyskryminacja), Ustawą Antydyskryminacyjną z 3.12.2010, RODO art. 82, kontrolą KNF, audytem UODO. Dokumentacja techniczna EU AI Act Article 11 staje się wzorcem dla wszystkich agentów Aneks III - Performance Review Agent, Promotion Agent, Compensation Decision Agent.

Dlatego Executive Recruiting Agent nie jest tylko narzędziem dla Komitetu Nominacji. Jest miejscem, gdzie polski Decision Layer w warunkach maksymalnej konfidencjonalności i maksymalnego obowiązku dokumentacyjnego dowodzi, że audytowalny workflow z pełną zgodnością KSH, DPSN 2021, EU AI Act, Pay Transparency i AML KYC jest możliwy. Co działa w tych warunkach, działa wszędzie.

--- Agent HR-Wydatków ---
> Workflow wydatków HR z samoobsługą pracownika: zgłoszenie wydatku z OCR paragonów, wielostopniowe zatwierdzenie według hierarchii kierowniczej i walidacja pól obowiązkowych.

Według badania Global Business Travel Association (GBTA) ręczne rozliczenie jednego paragonu kosztuje średnio 53 EUR (228 zł) i 20 minut pracy - a 19 procent rozliczeń zawiera błędy, których korekta dokłada 48 EUR (207 zł) i 18 minut. Polski Mittelstand z 500 rozliczeniami miesięcznie traci na tym około 31 100 EUR (134 000 zł) miesięcznie, z czego 4 600 EUR to same korekty. Tylko obciążenie procesowe.

Naruszenia podatkowe podnoszą stawkę dramatycznie. Art. 22p Ustawy o PIT/CIT pozbawia prawa do kosztów uzyskania przy zapłacie powyżej 15 000 zł poza rachunkiem z Białej Listy Podatników (whitelist.gov.pl). Art. 108a Ustawy o VAT to sankcja 30 procent wartości VAT za niewłaściwe zastosowanie Mechanizmu Podzielonej Płatności (MPP). Art. 56 Kodeksu Karnego Skarbowego do 30 procent wartości VAT za błędne JPK_V7M. Brak e-faktury KSeF od 1.07.2026 generuje sankcje KAS i korektę JPK_V7M w 14 dni. RODO art. 22 wyklucza pełną automatyzację Fraud Detection - sankcja UODO do 4 procent obrotu lub 20 milionów EUR.

Kto zna te liczby i mimo to nie ma ustrukturyzowanego procesu, nie prowadzi rozliczeń. Prowadzi kontrolowane ryzyko podatkowe.

## Pięć regulacyjnych warstw w jednym rozliczeniu służbowym

Rozliczenie wydatku służbowego w polskim porządku prawnym nie jest tylko procesem księgowym. Jest skrzyżowaniem pięciu warstw regulacyjnych, których pominięcie generuje natychmiastowe ryzyko prawne i sankcje:

```
Zgłoszenie rozliczenia
    │
    ├── Ustawa o PIT art. 21+22+23 ─── Zwolnienie diet, koszty uzyskania,
    │   Rozp. MF z 30.12.2022           wydatki nieuznawane, stawki krajowe
    │   Polski Ład 2.0                  i zagraniczne, ryczałty noclegowe
    │
    ├── Ustawa o VAT art. 86+88 ─────── Odliczenie VAT (paliwo 50 proc.,
    │   Biała Lista whitelist.gov.pl    hotel 100 proc., reprezentacja 0 proc.),
    │   art. 108a MPP                   Mechanizm Podzielonej Płatności
    │
    ├── KSeF Ustawa z 16.06.2023 ────── E-faktury B2B obowiązkowe od 1.07.2026,
    │   Rozp. MF z 25.10.2022           FA(2) XSD 1-0E, podpis kwalifikowany
    │   eIDAS 910/2014                  eIDAS, archiwizacja 10 lat
    │
    ├── JPK_V7M + Ord. Pod. art. 32+75  Miesięczne raportowanie KAS do 25
    │   KKS art. 56 sankcje             dnia, struktura 2-1 ab 2026, GTU,
    │   AML Ust. 1.03.2018              przedawnienie 5 lat plus rok bieżący
    │
    └── RODO art. 6+22+88 ────────────── Podstawa prawna, zakaz pełnej
        Ust. ochr. dan. 10.05.2018      automatyzacji decyzji wpływających
        Kodeks Pracy art. 77-5+94       na pracownika, dane bankowe
```

Warstwa Ustawy o PIT jest fundamentalna. Art. 21 ust. 1 pkt 16 zwalnia diety służbowe do wysokości stawek z Rozporządzenia MF z 30.12.2022 - krajowa 45 zł od 8 godziny, zagraniczne per kraj (Niemcy 49 EUR, Francja 50 EUR, USA 59 USD). Art. 21 ust. 1 pkt 19 zwalnia ryczałty noclegowe (150 procent diety bez paragonu) i samochodowe służbowe (0,5214 zł/km dla osobowego do 900 cm3). Art. 22 klasyfikuje wydatki służbowe jako koszty uzyskania, art. 23 wyklucza wydatki nieuznawane (reprezentacja powyżej limitu 0,25 procent przychodu, alkohol w 50 procent, samochody osobowe powyżej 150 000 zł).

## Problem koordynacyjny pod powierzchnią

Większość wyjaśnień błędów rozliczeniowych sięga zbyt płytko. "Pracownik nie zna polityki." "Kierownik zatwierdził bez sprawdzenia." "Księgowa się pomyliła." To symptomy. Przyczyna leży w architekturze procesu.

Rozliczenie służbowe w polskim kontekście prawnym to proces, w którym pięć niezależnych regulacji musi być stosowanych jednocześnie - i każda zmienia się w innym rytmie. Rozporządzenie MF z 30.12.2022 stawki diet aktualizuje co pół roku (lipiec/grudzień). Biała Lista Podatników zmienia się codziennie. KSeF wprowadza nowe schematy FA(2) XSD raz w roku. JPK_V7M aktualizuje strukturę 2-1 od 2026. Polski Ład 2.0 zmienia kontrakty menedżerskie. To działa, dopóki doświadczony Główny Księgowy trzyma cały proces w głowie. Ale zawodzi niezawodnie w trzech sytuacjach: gdy osoba koordynująca się zmienia, gdy kontrola KAS pyta o status historyczny sprzed 3 lat, i gdy GIIF wymaga dokumentacji AML KYC dla diety zagranicznej powyżej 15 000 EUR.

## [Decision Layer](/pl/decision-layer/) zamienia politykę kosztową w weryfikowalny proces

Polityka wydatków istnieje w każdej organizacji. Między dokumentem w intranecie a jego konsekwentnym stosowaniem rozciąga się jednak przepaść. Trzech kierowników w tej samej firmie zatwierdza ten sam paragon za reprezentację z gośćmi zewnętrznymi według trzech różnych standardów - bo nikt nie sprawdza polityki przed każdą akceptacją.

Decision Layer rozkłada proces wydatkowy na pojedyncze kroki decyzyjne i dla każdego definiuje: człowiek, silnik reguł lub AI. Rejestrację i ekstrakcję paragonów oraz e-faktur KSeF przejmuje AI - rozpoznaje typ dokumentu (FA(2) XSD 1-0E albo paragon skanowany), kwotę, NIP sprzedawcy i stawkę VAT z trafnością 92-98 procent na dokumentach ustrukturyzowanych. Silnikowi reguł podlega walidacja Białej Listy Podatników, klasyfikacja podatkowa z Ustawy o PIT i odliczenie VAT z Ustawy o VAT - limity, stawki i wyłączenia. Wykrywanie nadużyć generuje flagę, ale decyzja o akceptacji pozostaje przy Compliance Officerze zgodnie z RODO art. 22. Dla diet powyżej 15 000 EUR agent realizuje weryfikację AML KYC z Ustawy z 1.03.2018.

Człowiek pozostaje tam, gdzie jego decyzja jest naprawdę potrzebna: przy zatwierdzeniu wydatku przez przełożonego z odpowiedzialnością z KSH art. 233 (zasada staranności sumiennego kupca) i KP art. 100 (lojalność wobec pracodawcy), przy weryfikacji anomalii Fraud Detection przez Compliance Officera, przy ostatecznej akceptacji JPK_V7M przez Głównego Księgowego przed wysłaniem do KAS. Przełożony widzi w pełni zweryfikowany pakiet - klasyfikacja podatkowa wykonana, kalkulacja diet zgodna, odliczenie VAT obliczone, anomalie przeglądnięte - i jednym kliknięciem decyduje.

## Masowe procesy regułowe to idealny punkt startowy automatyzacji

Rozliczenia wydatków mają trzy cechy czyniące je szczególnie podatnymi na automatyzację. Po pierwsze: wysoki wolumen przy niskiej wartości jednostkowej. Setki paragonów miesięcznie, każdy w przedziale od 50 do 5 000 zł. Po drugie: jasne reguły. Limity kwotowe, stawki diet, dozwolone kategorie i progi zatwierdzenia są zapisane w Rozp. MF z 30.12.2022, Ustawie o PIT i VAT. Po trzecie: niskie ryzyko regulacyjne. Rozliczenie wydatków nie podlega kategorii wysokiego ryzyka EU AI Act, ponieważ nie zapada tu żadna decyzja dotycząca stosunku pracy.

Ta kombinacja wyjaśnia Readiness Score powyżej 90. Proces jest wystarczająco regułowy, by działać w dużej mierze automatycznie, a jednocześnie wystarczająco niekrytyczny, by służyć jako wejście w agentowe przepływy pracy. Organizacje, które zaczynają tutaj, budują silnik dokumentów (OCR AI dla e-faktur KSeF i paragonów), logikę zatwierdzania (macierz uprawnień z KSH art. 382) i klasyfikację podatkową według Ustawy o PIT i Ustawy o VAT - przenoszalną na procesy pokrewne, od faktur przychodzących po pełne delegacje służbowe.

KSeF jako akcelerator: od 1.07.2026 wszystkie e-faktury B2B w Polsce muszą być wystawione w Krajowym Systemie e-Faktur zgodnie ze schematem FA(2) XSD 1-0E i Rozporządzeniem MF z 25.10.2022. Ustrukturyzowane formaty dostarczają maszynowo czytelne dane podnoszące wskaźnik rozpoznawania OCR z 85-92 procent (paragon skanowany) do 92-98 procent (e-faktura KSeF) i redukujące ręczne uzupełnianie do przypadków wyjątkowych. Kto automatyzuje przed 1.07.2026, wykorzystuje zmianę regulacyjną jako akcelerator zamiast dodatkowego obciążenia.

## Czas zwrotu spada z tygodni do dni

Mierzalna różnica nie tkwi tylko w zaoszczędzonych kosztach przetwarzania. Widać ją w całym cyklu obiegu. Gdy paragon zostaje złożony w poniedziałek, tego samego dnia jest zweryfikowany NIP w Białej Liście, sklasyfikowany podatkowo, kalkulacja diet wykonana, odliczenie VAT obliczone, Fraud Detection przeglądnięte i u właściwego zatwierdzającego zgodnie z macierzą uprawnień. Żadnego przetwarzania na koniec miesiąca. Żadnych paragonów leżących trzy tygodnie na biurku kierownika. Żadnych korekt JPK_V7M w 14 dni od ujawnienia błędu.

Dla controllingu pojawia się drugi efekt: przejrzystość wzorców wydatków w czasie rzeczywistym. Zamiast odkrywać niespodzianki pod koniec kwartału - koszty reprezentacyjne jednego działu dwukrotnie wyższe niż w poprzednim kwartale - anomalie są widoczne w momencie powstawania. Agent nie zastępuje controllingu. Dostarcza bazę danych, na której decyzje controllingowe zapadają szybciej i trafniej. Dla audytu rocznego ślad audytowy z RODO art. 30 (RAT) jest gotowy bez dodatkowej pracy - każdy wydatek ma podstawę prawną, znacznik czasu RFC 3161 i Decision-Type (KI/Reguła/Człowiek).

Badanie SAP Concur pokazuje ponadto: 38 procent pracowników przynajmniej raz zawyżyło koszty kilometrów, 33 procent złożyło prywatne rachunki restauracyjne jako wydatki służbowe, 21 procent zgłosiło duplikaty paragonów. Konsekwentna, regułowa weryfikacja redukuje tę szarą strefę - nie przez inwigilację, lecz przez natychmiastowy feedback w momencie składania. Kto od razu dowiaduje się, że paragon nie jest zgodny z polityką, poprawia go sam zamiast dwa tygodnie później otrzymać pytanie z księgowości. AI Fraud Detection z RODO art. 22 (przegląd człowieka) flaguje anomalie do dashboardu Compliance Officera - bez bezpośredniej konfrontacji pracownika, ale z pełnym śladem audytowym.

## Co infrastruktura daje innym agentom

Architektura OCR AI z confidence scoring (walidacja FA(2) XSD 1-0E, paragony skanowane), klasyfikacja podatkowa według Ustawy o PIT i Ustawy o VAT, kalkulator diet z Rozp. MF z 30.12.2022 oraz integracja z KSeF i strukturą JPK_V7M nie jest budowana wyłącznie dla rozliczeń wydatków. Travel & Expense Agent reużywa tej samej infrastruktury dla pełnego cyklu delegacji służbowych z corporate travel (American Express GBT, Travelperk). Invoice Processing Agent reużywa walidacji Białej Listy Podatników i Mechanizmu Podzielonej Płatności dla faktur B2B z trójstronnym uzgadnianiem. Vendor Compliance Agent reużywa AML KYC z Ustawy z 1.03.2018 dla kontrahentów wysokiego ryzyka.

Decision Logging zgodne z RODO art. 30, Ordynacji Podatkowej art. 75 (5 lat) i Ustawy KSeF (10 lat) buduje Audit Trail wykorzystywany przez Decision Layer - kluczowe dla obrony przed kontrolą KAS, audytem KIS, sankcją art. 56 KKS lub art. 22p Ustawy o PIT/CIT. Fraud Detection Engine z przeglądem Compliance Officera zgodnym z RODO art. 22 staje się wzorcem dla Audit Compliance Agent, Internal Control Agent, Whistleblower Workflow Agent.

Dlatego Expense Processing Agent nie jest tylko narzędziem dla księgowości. Jest miejscem, gdzie polski Decision Layer w warunkach masowych wolumenów i pełnego obowiązku dokumentacyjnego dowodzi, że audytowalny workflow z pełną zgodnością Ustawy o PIT, Ustawy o VAT, KSeF, JPK_V7M i RODO jest możliwy. Co działa w tych warunkach przy 500 rozliczeniach miesięcznie, działa wszędzie.

--- HR Document Management Agent ---
> Elektroniczna akta osobowa zgodna z KP art. 94 pkt 9a-9b, Ustawą o aktach osobowych 1.10.2018, RODO art. 15+17+32 i eIDAS Autenti - klasyfikacja AI, archiwizacja Comarch i audit-trail.

W organizacji z 2000 pracownikami i średnio 40 dokumentami na akta powstaje 80 000 pojedynczych terminów archiwizacji rocznie. Ręcznie to niewykonalne. Na arkuszach też nie, bo terminy przesuwają się wraz ze zmianami prawa - jak skrócenie z 50 do 10 lat dla pracowników zatrudnionych od 1.01.2019 z Ustawy o aktach osobowych z 1.10.2018.

Naruszenia regulacyjne podnoszą stawkę dramatycznie. Przechowywanie za długo narusza RODO art. 5 ust. 1 lit. e i grozi karą 10 000-50 000 EUR (43 000-215 000 zł) za zdarzenie. Brak wymaganej dokumentacji z KP art. 94 pkt 9a-9b to kara do 30 000 zł z art. 281 KP oraz utrata dowodu w sporze pracowniczym (przedawnienie 3 lata z KP art. 291). Brak śladu audytowego z RODO art. 32 to sankcja UODO do 2 procent obrotu lub 10 milionów EUR. Naruszenie tajemnicy pracowniczej z KP art. 233 to kara grzywny lub pozbawienia wolności do 2 lat. Ustawa o sygnalistach z 14.06.2024 wprowadza ochronę przez 24 miesiące - naruszenie segmentu E akt generuje odwet pracownika i sankcję AAI Niezależnej Ochrony Sygnalistów.

Kto zna te liczby i mimo to nie ma ustrukturyzowanego procesu, nie prowadzi akt osobowych. Prowadzi kontrolowane ryzyko regulacyjne.

## Sześć regulacyjnych warstw w jednych aktach osobowych

Akta osobowe w polskim porządku prawnym nie są tylko zbiorem dokumentów. Są skrzyżowaniem sześciu warstw regulacyjnych, których pominięcie generuje natychmiastowe ryzyko prawne i sankcje:

```
Wprowadzenie dokumentu
    │
    ├── KP art. 94 pkt 9a-9b + art. 233 ── Obowiązek prowadzenia akt
    │   Ustawa o aktach osobowych          osobowych w formie cyfrowej
    │   z 1.10.2018                        od 1.01.2019, 10/50 lat archiwizacji,
    │   Rozp. MRiPS z 10.12.2018           tajemnica pracownicza
    │
    ├── RODO art. 5+15+17+22+32 ────────── Minimalizacja danych, prawo dostępu
    │   Ust. ochr. dan. 10.05.2018          (30 dni), prawo do bycia zapomnianym
    │                                       (z wyjątkami obowiązku prawnego),
    │                                       audit-trail, szyfrowanie AES-256
    │
    ├── eIDAS UE 910/2014 ───────────────── Kwalifikowany podpis elektroniczny
    │   Ustawa o usługach zaufania         dla umów o pracę, aneksów, świadectw
    │   z 5.09.2016                         (Autenti, KIR Szafir, CenCert, EuroCert,
    │                                        Madkom - certyfikowani NCCert)
    │
    ├── KP art. 22-1+22-1a ─────────────── Zamknięty katalog danych pracownika
    │   RODO art. 9                         (imię, PESEL, dane kontaktowe,
    │                                        wykształcenie); dane szczególne
    │                                        (stan zdrowia, przynależność związkowa)
    │                                        wymagają zgody lub obowiązku prawnego
    │
    ├── Ust. o sygnalistach 14.06.2024 ─── Segment E akt z wzmocnionymi środkami
    │   KP art. 94-3 + 281                  bezpieczeństwa z RODO art. 32, ochrona
    │   Ust. Antydyskr. 3.12.2010           24 miesiące, dostęp ograniczony do
    │                                        Inspektora ds. Sygnalistów
    │
    └── Synchronizacja z systemami ────── Platnik ZUS (5 lat), e-deklaracje
        zewnętrznymi                         KAS (PIT-11, PIT-4R, JPK_V7M),
        Ord. Pod. art. 75                   KSeF e-faktury 10 lat z Ust. 16.06.2023
```

Warstwa Kodeksu Pracy jest fundamentalna. Art. 94 pkt 9a-9b nakłada obowiązek prowadzenia dokumentacji pracowniczej - dla zatrudnień od 1.01.2019 dominuje forma cyfrowa z Ustawy o aktach osobowych z 1.10.2018. Art. 233 KP wymaga tajemnicy pracowniczej (kara grzywny lub do 2 lat pozbawienia wolności). Rozp. MRiPS z 10.12.2018 ustala strukturę A (rekrutacja), B (zatrudnienie), C (rozwiązanie), D (roszczenia), E (sygnaliści/mobbing), kwalifikowany podpis eIDAS i metadane.

## Właściwy problem: terminy, które sobie przeczą

Akta osobowe to nie jednolity dokument z jednolitym terminem przechowywania. To zbiór typów dokumentów, z których każdy podlega własnym podstawom prawnym.

```
Typ dokumentu                Termin   Podstawa prawna
─────────────────────────────────────────────────────
Dokumenty podatkowe           5 lat    Ord. Pod. art. 75
Dokumenty ZUS                 5 lat    art. 47 ust. 3c Ust. SUS
Akta osobowe (od 1.01.2019)  10 lat   KP art. 94 pkt 9a-9b
Akta osobowe (przed 2019)    50 lat   przepis przejściowy
                                       (Ust. emerytalna 17.12.1998)
Dokumentacja BHP             10 lat   Kodeks Pracy
Dokumenty wypadkowe          10 lat   Rozp. MRiPS
Dokumentacja PPK             10 lat   art. 107 Ust. o PPK
Akta sygnalisty               5 lat   Ust. z 14.06.2024
e-faktury KSeF              10 lat    Ust. KSeF z 16.06.2023
```

Dziewięć terminów, kilka podstaw prawnych, dziesiątki przypadków szczególnych. Skrócenie z 50 do 10 lat dla zatrudnień od 2019 jest szczególnie kłopotliwe - dokumenty z 2019 w 2029 mogą być usuwane, ale akta pracownika zatrudnionego w 2018 muszą być przechowywane do 2068. Pomyłka w klasyfikacji okresu zatrudnienia generuje albo przedwczesne usunięcie (KP art. 94 pkt 9a-9b), albo nadmierne przechowywanie (RODO art. 5 ust. 1 lit. e).

## Dwa kierunki, w których robi się drogo

Krajobraz terminów generuje podwójne ryzyko.

Przechowywanie za długo: kto przechowuje dokumenty osobowe ponad ustawowy termin, narusza zasadę ograniczenia przechowywania z RODO (art. 5 ust. 1 lit. e). Kary za naruszenia wynoszą typowo od 10 000 do 50 000 EUR (43 000-215 000 zł) za zdarzenie. Przy systematycznych zaniedbaniach - na przykład gdy cały rocznik nigdy nie został sprawdzony - sumy się kumulują. Przy naruszeniu zasad przetwarzania i bezpieczeństwa z RODO sankcja UODO sięga 4 procent obrotu lub 20 milionów EUR.

Usunięcie za wcześnie: kto niszczy dokumenty składkowe ZUS przed upływem ustawowego terminu, nie jest w stanie dostarczyć dowodów przy następnej kontroli. E-kontrola ZUS staje się standardem - firmy bazujące na papierowych aktach lub nieustrukturyzowanych systemach archiwizacji nie przejdą tych kontroli bez zastrzeżeń. Brak dowodu w sporze pracowniczym z prescription 3 lat z KP art. 291 oznacza przegraną automatycznie.

Okno czasowe się zamyka.

## [Decision Layer](/pl/decision-layer/) zamienia akta osobowe w weryfikowalny proces

Polityka akt osobowych istnieje w każdej organizacji. Między dokumentem w intranecie a jego konsekwentnym stosowaniem rozciąga się jednak przepaść. Trzech HR Generalist w tej samej firmie klasyfikuje to samo świadectwo pracy do trzech różnych segmentów akt - bo nikt nie sprawdza Rozp. MRiPS przed każdym wprowadzeniem.

Decision Layer rozkłada cykl życia dokumentu na pojedyncze kroki decyzyjne i dla każdego definiuje: człowiek, silnik reguł lub AI. Klasyfikację typu dokumentu przejmuje AI - rozpoznaje umowę o pracę z kwalifikowanym podpisem QSig, zeskanowane świadectwo pracy czy zaświadczenie lekarskie BEM z trafnością 90-95 procent na dokumentach ustrukturyzowanych i 80-88 procent na skanach. Silnikowi reguł podlega walidacja zakresu danych z Kodeksu Pracy (zamknięty katalog), weryfikacja kwalifikowanego podpisu eIDAS, mapowanie metadanych Rozp. MRiPS i monitoring terminów archiwizacji 10 lub 50 lat. RODO art. 22 wyklucza pełną automatyzację - klasyfikacja AI poniżej progu pewności trafia do przeglądu Specjalisty ds. Akt, a przypisanie do segmentu sygnalistów lub usunięcie dokumentu z RODO art. 17 pozostaje przy Inspektorze Ochrony Danych.

Człowiek pozostaje tam, gdzie jego decyzja jest naprawdę potrzebna: przy zatwierdzeniu redakcji danych osób trzecich w odpowiedzi na żądanie z RODO art. 15, przy ocenie wyjątku obowiązku prawnego z RODO art. 17 ust. 3 lit. b (KP art. 94 pkt 9a-9b vs prawo do bycia zapomnianym), przy wprowadzeniu dokumentu do segmentu E akt z wzmocnionymi środkami bezpieczeństwa, przy ocenie podstawy prawnej dla danych szczególnych z RODO art. 9 (zgoda pracownika, obowiązek prawny). Inspektor Ochrony Danych widzi w pełni zweryfikowany pakiet - klasyfikacja AI wykonana, walidacja KP art. 22-1 zaliczona, kwalifikowany podpis sprawdzony, metadane Rozp. MRiPS nadane - i jednym kliknięciem zatwierdza wprowadzenie.

## Masowe procesy regułowe to idealny punkt startowy automatyzacji

Akta osobowe mają trzy cechy czyniące je podatnymi na automatyzację. Wysoki wolumen przy umiarkowanej wartości jednostkowej (tysiące dokumentów rocznie). Jasne reguły (Rozp. MRiPS z 10.12.2018 ustala segmenty A/B/C/D/E i metadane, Ustawa o aktach osobowych terminy 10/50 lat, RODO zasady przetwarzania). Niskie ryzyko regulacyjne - zarządzanie dokumentami nie podlega kategorii wysokiego ryzyka EU AI Act, bo nie zapada decyzja o stosunku pracy.

Readiness Score powyżej 87 wynika z tej kombinacji. Organizacje, które zaczynają tutaj, budują silnik dokumentów (klasyfikacja AI typów z Rozp. MRiPS), logikę archiwizacji (10/50 lat z Ustawy o aktach osobowych) i kwalifikowany podpis eIDAS (Autenti, KIR Szafir, CenCert) przenoszalne na wszystkich agentów dokumentowych. KSeF jako akcelerator: od 1.07.2026 wszystkie e-faktury B2B w Polsce muszą być wystawione w schemacie FA(2) XSD 1-0E - agent synchronizuje akta kadrowe z e-fakturami powiązanymi (zwroty kosztów, świadczenia w naturze) zapewniając pełen ślad audytowy w 10-letnim okresie archiwizacji KSeF.

## Czas wyszukiwania spada z godzin do sekund

Mierzalna różnica widoczna w całym cyklu obiegu. Dokument wprowadzony w poniedziałek tego samego dnia jest sklasyfikowany, przypisany do segmentu A/B/C/D/E, walidowany na zakres KP art. 22-1, weryfikowany na kwalifikowany podpis eIDAS, archiwizowany z szyfrowaniem AES-256 i audit-trail RODO art. 32. Żadnych dokumentów leżących trzy tygodnie na biurku Specjalisty ds. Akt. Żadnych przekroczeń terminu odpowiedzi z RODO art. 15 (30 dni).

Dla audytu pojawia się przejrzystość kompletności akt w czasie rzeczywistym. Zamiast odkrywać niespodzianki podczas kontroli PIP - pracownik z 2019 roku z brakującą umową z kwalifikowanym podpisem - braki są widoczne w momencie powstawania. Ślad audytowy z RODO art. 30 (RAT) jest gotowy bez dodatkowej pracy.

Monitoring terminów archiwizacji działa ciągle. Dokumenty, których termin upływa w 90 dni, są automatycznie zgłaszane. Ale nic nie jest usuwane automatycznie - agent tworzy propozycję usunięcia z uzasadnieniem (typ, segment, data wprowadzenia, podstawa prawna), zatwierdzenie wydaje Inspektor Ochrony Danych. Zawsze. Ani RODO, ani Kodeks Pracy nie pozwalają na w pełni automatyczne niszczenie dokumentów kadrowych bez ludzkiej kontroli.

## Co infrastruktura daje innym agentom

Architektura klasyfikacji AI typów z Rozp. MRiPS, kwalifikowanego podpisu eIDAS (Autenti dominuje rynek polski, KIR Szafir bankowy, CenCert i EuroCert korporacyjne), archiwizacji ECM (Comarch e-archiwum, DocuWare, ELO, d.velop) z RODO art. 32 i monitoringu terminów 10/50 lat staje się szablonem dla wszystkich agentów dokumentowych. Contract Offer Generation Agent reużywa infrastruktury dla umów o pracę z KP art. 29 i kwalifikowanym podpisem Autenti. Policy Document Agent reużywa mapowania metadanych Rozp. MRiPS dla regulaminów (KP art. 104, polityka antymobbingowa art. 94-3, polityka sygnalistów Ustawa z 14.06.2024). Performance Review Documentation Agent reużywa segmentów B/D dla ocen pracowniczych.

Rejestrowanie decyzji zgodne z RODO art. 30 i art. 32, Ordynacją Podatkową art. 75 oraz Ustawą o aktach osobowych buduje Audit Trail wykorzystywany przez Decision Layer - kluczowy przy obronie przed kontrolą PIP, audytem UODO i sankcją do 4 procent obrotu z RODO. Obsługa praw dostępu z RODO art. 15 i art. 17 jest wzorcem dla wszystkich agentów przetwarzających dane pracowników. Synchronizacja z systemami zewnętrznymi (Platnik ZUS, e-deklaracje KAS, KSeF od 1.07.2026) jest fundamentem dla Payroll Accounting Agent, Tax Compliance Agent i Expense Processing Agent.

HR Document Management Agent nie jest tylko narzędziem dla Działu Płac i Kadr. Jest miejscem, gdzie polski Decision Layer dowodzi w warunkach masowych wolumenów akt i pełnego obowiązku dokumentacyjnego, że audytowalny workflow w pełnej zgodności z Kodeksem Pracy, Ustawą o aktach osobowych, RODO, eIDAS i Ustawą o sygnalistach jest możliwy. Co działa przy 80 000 pojedynczych terminów archiwizacji rocznie, działa wszędzie.

--- Interview Scheduling Agent ---
> Koordynacja rozmów kwalifikacyjnych zgodna z KP art. 18-3a, RODO art. 22, EU AI Act Annex III(4)(a) i Pay Transparency 2023/970 - Multi-Calendar Sync, bias-audit i WCAG 2.1 AA.

Problem nie jest rozmowa. Problem jest tydzień przed nią, regulacyjny krajobraz, który jej towarzyszy, i precedens Mobley v. Workday, który dopiero przenosi się na polski grunt.

Zespoły rekrutacyjne w firmach od 500 do 5000 pracowników znają ten przebieg: pozycja otwarta, silny kandydat czeka na termin rozmowy panelowej z czterema uczestnikami - i zaczyna się kalendarzowy tetris. Rekruter pisze do hiring managera, czeka, dostaje kontrpropozycję, stwierdza że kandydat tego dnia nie może z powodu obowiązków rodzinnych, zaczyna od nowa. Pięć dni później termin stoi. Albo kandydat już podpisał gdzie indziej.

35 procent czasu pracy rekruterów pochłania koordynacja terminów - nie rozmowy, nie ocena, nie budowanie relacji. Przy panelach z trzema do pięciu uczestnikami problem potęguje się: gdy każdy ma 60 procent kalendarza wolnego, prawdopodobieństwo wspólnego slotu w godzinie wynosi poniżej 8 procent. W tygodniu pozostają około trzy realistyczne opcje - przed uwzględnieniem stref czasowych, sal czy podróży.

Naruszenia regulacyjne podnoszą stawkę dramatycznie. Dyskryminacja w rekrutacji z KP art. 18-3a generuje skargę kandydata do RPO, Pełnomocnika ds. Równego Traktowania lub Sądu Pracy (przedawnienie 3 lata z KP art. 291), karę do 30 000 zł z art. 281 KP oraz odszkodowanie z KP art. 18-3d. Naruszenie zakazu pełnej automatyzacji z RODO art. 22 to sankcja UODO do 4 procent obrotu lub 20 milionów EUR. EU AI Act 2024/1689 Annex III(4)(a) klasyfikuje rekrutację HR jako system wysokiego ryzyka z sankcją do 35 milionów EUR lub 7 procent globalnego obrotu. EU Pay Transparency 2023/970 (transpozycja w PL do 7.06.2026) zakazuje pytania o historię wynagrodzeń i wymaga przedziału płacowego. Pozew Mobley v. Workday (USA, 2024) pokazał, że rekomendacja ATS może zostać uznana za dyskryminacyjną nawet bez automatycznego odrzucenia.

## Sześć regulacyjnych warstw w jednym slocie kalendarza

Koordynacja rozmów kwalifikacyjnych w polskim porządku prawnym nie jest tylko logistyką. Jest skrzyżowaniem sześciu warstw regulacyjnych, których pominięcie generuje natychmiastowe ryzyko prawne i sankcje:

```
Żądanie rozmowy z ATS
    │
    ├── KP art. 18-3a + 22-1+22-1a+22-1b ── Zakaz dyskryminacji w rekrutacji,
    │   Konstytucja RP art. 32+65          zamknięty katalog danych kandydata,
    │   Ust. Antydyskr. 3.12.2010           badania medyczne tylko po zatrudnieniu,
    │                                       biometria wykluczona, monitoring
    │                                       rozmów z poinformowaniem
    │
    ├── EU AI Act 2024/1689 ─────────────── Hochrisiko-System Annex III(4)(a)
    │   Annex III(4)(a) HR-Recruitment      Article 6+9+13+14+26 - Risk Management,
    │   Article 99 sankcje                  Data Governance, Transparency,
    │                                       Human Oversight; sankcje do 35 mln EUR
    │                                       lub 7 procent globalnego obrotu
    │
    ├── RODO art. 6+9+22+88 ─────────────── Podstawa prawna, dane szczególne,
    │   Ust. ochr. dan. 10.05.2018          zakaz pełnej automatyzacji decyzji,
    │                                       audit-trail, retencja danych
    │                                       rekrutacyjnych 6 miesięcy lub 3 lata
    │
    ├── EU Pay Transparency 2023/970 ────── Zakaz pytania o historię wynagrodzeń,
    │   Transpozycja PL pendiente           obowiązek Pay Range w ofertach,
    │   do 7.06.2026                        sankcje przez UODO i Sąd Pracy
    │                                       z KP art. 18-3a (dyskryminacja płci)
    │
    ├── Ust. o cudzoziemcach 12.12.2013 ─── Weryfikacja Wiza dla kandydatów spoza
    │   eIDAS UE 910/2014                   UE/EOG, RODO art. 9 wzmocnione
    │   Ust. usługi zaufania 5.09.2016     zabezpieczenia, kwalifikowany podpis
    │                                       Autenti dla rozmów technicznych
    │
    └── Ust. o sygnalistach 14.06.2024 ──── Kandydat sygnalista chroniony
        KP art. 94-3                        24 miesiące, segment E akt
        Ust. szcz. grupy 12.02.1991         rekrutacyjnych z RODO art. 32,
        Konwencja ONZ CRPD                  akomodacje niepełnosprawnych WCAG 2.1 AA
```

Warstwa Kodeksu Pracy jest fundamentalna. Art. 18-3a zakazuje dyskryminacji - pytania o ciążę, religię, wiek, orientację, przekonania polityczne, przynależność związkową, narodowość, rasę są wykluczone. Art. 22-1+22-1a definiuje zamknięty katalog danych kandydata (imię, nazwisko, data urodzenia, dane kontaktowe, wykształcenie, kwalifikacje, przebieg zatrudnienia) - dane spoza katalogu generują sankcję UODO do 4 procent obrotu z RODO art. 5. Art. 22-1b: badania medyczne tylko po zatrudnieniu, biometria w rekrutacji wykluczona.

## Właściwy problem: ranking jest decyzją, nawet gdy nazywa się logistyką

Pozew zbiorowy Mobley v. Workday (USA, 2024) pokazał coś fundamentalnego dla rynku rekrutacji AI. Sąd uznał, że Workday (ATS) jest agentem pracodawcy w rozumieniu Title VII Civil Rights Act - nawet bez automatycznego odrzucenia. Wystarczy, że rekomendacja wpływa na ranking: który kandydat dostanie szybszy slot, który spędza tydzień w kolejce, a który trafia do panelu seniorskiego.

Polskie orzecznictwo pójdzie tym tropem. Transpozycja EU AI Act 2024/1689 (do 2.08.2026) i orzeczenia Sądów Pracy z KP art. 18-3a odzwierciedlą ten precedens. Koordynacja rozmów wygląda na czystą logistykę, ale w praktyce wpływa na ranking. Annex III(4)(a) klasyfikuje rekrutację HR jako system wysokiego ryzyka z sankcją do 35 milionów EUR lub 7 procent globalnego obrotu.

## Dwa kierunki, w których robi się drogo

Dyskryminacja przez algorytm: kto rekomenduje wolniejsze sloty kandydatom z określonej grupy demograficznej (płeć, wiek, narodowość, niepełnosprawność), narusza KP art. 18-3a i RODO art. 22 nawet bez automatycznego odrzucenia. Kwartalny audyt uprzedzeń z EU AI Act Annex III(4)(a) jest obowiązkowy - logowanie metadanych, audyt wzorców i raportowanie do Pełnomocnika ds. Równego Traktowania. Jego brak to sankcja EU AI Office do 35 milionów EUR.

Pytanie o historię wynagrodzeń: kto zostawia w szablonie zaproszenia pole na pytanie o aktualne lub poprzednie wynagrodzenie, narusza EU Pay Transparency 2023/970 oraz RODO. Grozi to skargą UODO i sankcją do 4 procent obrotu, a dodatkowo orzeczeniem Sądu Pracy o dyskryminacji płci - jeśli kobieta dostaje propozycję poniżej przedziału płacowego, a mężczyzna na podobnym stanowisku w jego granicach, powstaje roszczenie o lukę płacową (przedawnienie 3 lata z KP art. 291).

Okno czasowe się zamyka. EU Pay Transparency 2023/970 do 7.06.2026, EU AI Act do 2.08.2026.

## [Decision Layer](/pl/decision-layer/) zamienia koordynację rozmów w weryfikowalny proces

Polityka rekrutacji istnieje w każdej organizacji. Między dokumentem w intranecie a jego konsekwentnym stosowaniem rozciąga się jednak przepaść. Trzech recruiterów w tej samej firmie wysyła trzy różne szablony zaproszenia - jeden z Pay Range, dwa bez. Bo nikt nie sprawdza Pay Transparency 2023/970 przed każdym wysłaniem.

Decision Layer rozkłada cykl koordynacji rozmowy na pojedyncze kroki decyzyjne. Silnik reguł przejmuje walidację przedziału płacowego, katalogu pytań z KP art. 18-3a, zamkniętego katalogu danych z Kodeksu Pracy oraz wizy kandydatów zagranicznych. AI przejmuje synchronizację kalendarzy (Outlook, Google Calendar, Apple), generowanie 3-5 propozycji slotów i dystrybucję zaproszeń. RODO art. 22 wyklucza pełną automatyzację - niska pewność wymaga eskalacji do rekrutera.

Człowiek pozostaje przy zatwierdzeniu dostosowań dla osób z niepełnosprawnościami (RODO art. 9), przy decyzji Hire/No-Hire na końcu procesu (Article 14 EU AI Act), przy ocenie wyjątków w katalogu pytań i przy obsłudze sprzeciwu kandydata z RODO art. 22. Compliance Officer i rekruter widzą w pełni zweryfikowany pakiet - przedział płacowy obecny, pytania zgodne z KP art. 18-3a, kalendarze zsynchronizowane, wiza zweryfikowana, dostosowania zatwierdzone - i jednym kliknięciem zatwierdzają wysłanie zaproszenia.

## Masowe procesy regułowe to idealny punkt startowy automatyzacji

Koordynacja rozmów ma trzy cechy czyniące ją podatną na automatyzację. Wysoki wolumen przy umiarkowanej wartości jednostkowej (setki rozmów rocznie). Jasne reguły (KP art. 22-1 i art. 18-3a, przedział płacowy z EU Pay Transparency, wymogi EU AI Act). I jednocześnie wysokie ryzyko regulacyjne wymagające rygorystycznej zgodności - rekrutacja HR to system wysokiego ryzyka z Annex III(4)(a) i sankcją do 35 milionów EUR.

Readiness Score 83-90 wynika z tej kombinacji. Organizacje, które zaczynają tutaj, budują silnik synchronizacji kalendarzy (Outlook, Google Calendar, Apple, Calendly, GoodTime Hire), logikę walidacji z KP art. 22-1 i art. 18-3a, infrastrukturę audytu uprzedzeń zgodną z Annex III(4)(a) i kwalifikowany podpis eIDAS - przenoszalne na Candidate Screening Agent, Executive Recruiting Agent i Onboarding Workflow Agent. EU AI Act działa tu jak akcelerator: do 2.08.2026 wszystkie systemy AI w rekrutacji muszą spełniać wymogi systemu wysokiego ryzyka, a agent zapewnia pełen ślad audytowy z pięcioletnim okresem archiwizacji.

## Czas koordynacji spada z dni do godzin

Mierzalna różnica w całym cyklu. Żądanie rozmowy wprowadzone w poniedziałek tego samego dnia jest sklasyfikowane (typ, uczestnicy, czas), walidowane na KP art. 22-1, Pay Range, katalog pytań z KP art. 18-3a, dostępność Multi-Calendar z konwersją stref czasowych, Wiza zagranicznych, akomodacje niepełnosprawnych. Kandydat dostaje 3-5 propozycji slotów w godzinach. Żadnych żądań leżących trzy dni na biurku recrutera. Żadnych przekroczeń terminu odpowiedzi z RODO art. 12 ust. 3.

Dla audytu pojawia się przejrzystość kompletności rekrutacji w czasie rzeczywistym. Zamiast odkrywać niespodzianki podczas kontroli PIP - Pay Range brakuje w 30 procent zaproszeń ostatnich 6 miesięcy - braki są widoczne w momencie powstawania. Ślad audytowy z RODO art. 30 i Article 12 EU AI Act jest gotowy bez dodatkowej pracy.

Bias-Audit działa kwartalnie. Wzorce rekomendacji slotu według płci, wieku, narodowości, niepełnosprawności są analizowane systematycznie. Ale nic nie jest zmieniane automatycznie - agent generuje raport do Pełnomocnika ds. Równego Traktowania, decyzję wydaje Compliance Officer i Pełnomocnik. Ani EU AI Act, ani Konstytucja RP nie pozwalają na pełną automatyzację decyzji kadrowych bez ludzkiej kontroli.

## Co infrastruktura daje innym agentom

Architektura synchronizacji kalendarzy (Outlook w 60-70 procent korporacji, Google Calendar w 20-30 procent firm IT, Apple poniżej 10 procent, obok Calendly, Cronofy i GoodTime Hire), walidacja przedziału płacowego z Pay Transparency 2023/970, walidacja katalogu pytań z KP art. 18-3a, audyt uprzedzeń z Annex III(4)(a) oraz dostosowania WCAG 2.1 AA i Konwencji ONZ CRPD stają się szablonem dla wszystkich agentów rekrutacji. Candidate Screening Agent reużywa walidacji z KP art. 22-1 i art. 18-3a. Executive Recruiting Agent reużywa przedziału płacowego i audytu uprzedzeń. Learning Event Management Agent reużywa synchronizacji kalendarzy, Transfer Relocation Agent - weryfikacji wizy, a Onboarding Workflow Agent - decyzji Hire/No-Hire.

Rejestrowanie decyzji zgodne z RODO art. 30 i art. 32, Article 12 EU AI Act oraz Ustawą o ochronie danych osobowych z 10.05.2018 buduje Audit Trail - kluczowy przy kontroli PIP, audycie UODO, kontroli EU AI Office i orzeczeniach Sądu Pracy. Prawo kandydata do sprzeciwu z RODO art. 22 i Article 14 EU AI Act jest wzorcem dla wszystkich agentów wysokiego ryzyka.

Interview Scheduling Agent nie jest tylko narzędziem dla Talent Acquisition Lead. Jest miejscem, gdzie polski Decision Layer dowodzi - w warunkach systemu wysokiego ryzyka według EU AI Act Annex III(4)(a) i pełnej zgodności z KP art. 18-3a, EU Pay Transparency 2023/970, RODO art. 22 oraz Konstytucją RP art. 32 - że audytowalny workflow rekrutacji z jawnym przedziałem płacowym, audytem uprzedzeń i prawem kandydata do sprzeciwu jest możliwy. Co działa przy 100 rekrutacjach z 300 panelami rocznie, działa wszędzie.

--- Agent Faktur HR ---
> Workflow faktur dostawców HR: agencje rekrutacyjne LinkedIn i Pracuj.pl, dostawcy szkoleń, dostawcy benefitów - z przypisaniem MPK Personal, walidacją umów ramowych i informowaniem Rady Pracowników.

## Ręczne przetwarzanie faktur kosztuje EUR 10-15 za operację - i na dokładkę traci skonto

Jedna faktura przychodząca przetworzona ręcznie kosztuje od EUR 10 do EUR 15 (43-65 PLN). Przy 500 fakturach tygodniowo to ponad EUR 300 000 (ok. 1,3 mln PLN) kosztów procesowych rocznie - zanim choć jedna faktura zostanie błędnie zakodowana lub skonto przepadnie. Według Ardent Partners zaledwie 21 procent firm bez automatyzacji osiąga akceptowalne wskaźniki wykorzystania skonta. Pozostałe 79 procent płaci pełną kwotę, bo faktura wciąż krążyła w obiegu zatwierdzającym, gdy termin minął.

Właściwa szkoda nie tkwi w oczywistych kosztach wprowadzania danych. Tkwi w kosztach następczych: błędne kodowanie generuje korekty księgowe, brak powiązania z zamówieniem uruchamia pytania do działu zakupów, opóźnione płatności pogarszają warunki u dostawców. Każda z tych poprawek wiąże pojemność zespołu księgowego, której brakuje na zamknięcia okresowe i analizy.

## Automatyczne trójstronne uzgadnianie redukuje wskaźnik błędów z 12% do bliskiego zeru

Trójstronne uzgadnianie - faktura vs. zamówienie vs. potwierdzenie odbioru - to rdzeń każdej prawidłowej kontroli faktur. Wykonane ręcznie jest podatne na błędy: 10-15 procent wszystkich faktur zawiera odchylenia w ilościach, cenach lub warunkach, które kontroler pod presją czasu przeocza lub źle ocenia. Systemy zautomatyzowane przeprowadzają to uzgadnianie w sekundach i stosują przy tym zdefiniowane reguły tolerancji konsekwentnie na każdą pojedynczą pozycję.

Konkretnie oznacza to: faktura na EUR 4 780 jest sprawdzana względem pozycji zamówienia EUR 4 800. Odchylenie 0,4 procent mieści się w zdefiniowanej tolerancji 2 procent - agent zatwierdza. Druga faktura odbiega o 8 procent - agent eskaluje do odpowiedzialnego za centrum kosztowe. Bez uznaniowości, bez niespójności między kontrolerami, bez zapomnianej kontroli w piątek po południu.

Kodowanie podąża tą samą zasadą. Zamiast kontrolera sprawdzającego konto, reguły wyprowadzają kodowanie z zamówienia. Przy fakturach bez powiązania z zamówieniem agent proponuje konto na podstawie historycznych wzorców księgowych - finalne potwierdzenie pozostaje przy człowieku.

## [Decision Layer](/pl/decision-layer/) oddziela rutynowe zatwierdzenia od decyzji wymagających osądu

Decision Layer rozkłada proces fakturowy na pojedyncze kroki decyzyjne i definiuje dla każdego: człowiek, reguły lub AI. Ten rozkład czyni różnicę między automatyzacją obejmującą 60 procent faktur a taką, która osiąga 95 procent.

Ekstrakcja danych - dostawca, kwota, numer faktury, pozycje - to zadanie AI. Wskaźnik rozpoznawania przy ustrukturyzowanych fakturach (PDF, EDI, KSeF) wynosi od 92 do 98 procent. Trójstronne uzgadnianie i kodowanie to zadania regułowe z zdefiniowanymi progami. Routing zatwierdzający podąża za macierzą kwotową: faktury poniżej EUR 5 000 do kierownika zespołu, powyżej EUR 50 000 do zarządu.

Człowiek pozostaje tam, gdzie prawo tego wymaga - nie dlatego, że potrafi lepiej. Prawidłowa księgowość wymaga przejrzystości każdej decyzji. Agent protokołuje każdy krok z uzasadnieniem i znacznikiem czasu. Przy odchyleniach istotnych podatkowo - na przykład fakturze bez prawidłowego NIP - eskaluje do kwalifikowanego kontrolera zamiast decydować samodzielnie.

## Przetwarzanie faktur dostarcza najszybszy ROI w całym portfolio agentów

Żaden inny agent nie łączy tak wysokiego wolumenu z tak niską złożonością governance. Przetwarzanie faktur nie jest systemem wysokiego ryzyka według EU AI Act, nie wymaga zaangażowania Rady Zakładowej i nie dotyczy danych osobowych pracowników. Jednocześnie średniej wielkości firma z 200 pracownikami przetwarza łatwo 300-800 faktur miesięcznie - każda pojedyncza to mierzalna oszczędność.

Rachunek jest prosty: gdy koszty procesowe na fakturę spadają z EUR 12 do EUR 3 (52 do 13 PLN) i wykorzystanie skonta rośnie z 20 do 75 procent, agent przy 500 fakturach miesięcznie amortyzuje się w ciągu kilku miesięcy. Highradius szacuje średnią redukcję kosztów przez automatyzację AP na 78 procent - z USD 13,54 do USD 2,98 za fakturę.

Krajowy System e-Faktur (KSeF) wzmacnia ten efekt. Od 2026 roku KSeF stanie się obowiązkowy dla podatników VAT w Polsce. Ustrukturyzowane formaty dostarczają maszynowo czytelne dane podnoszące wskaźnik rozpoznawania i redukujące ręczne uzupełnianie do przypadków wyjątkowych. Kto automatyzuje teraz, wykorzystuje zmianę regulacyjną jako akcelerator zamiast dodatkowego obciążenia.

--- Job Posting Agent ---
> Generuje ogłoszenia o pracę z profili wymagań, zapewnia zgodność z prawem antydyskryminacyjnym. Klasyfikacja wysokiego ryzyka EU AI Act.

Trzech rekruterów, trzy sformułowania, trzy poziomy ryzyka. Tak wygląda rzeczywistość ogłoszeń o pracę, gdy dwadzieścia otwartych pozycji czeka na obsadzenie jednocześnie. Jedno ogłoszenie mówi o "młodym, dynamicznym zespole" - naruszenie prawa antydyskryminacyjnego, które przed sądem pracy może kosztować do trzech brutto miesięcznych wynagrodzeń odszkodowania. Następne pomija widełki płacowe, które od czerwca 2026 stają się obowiązkowe na mocy dyrektywy o przejrzystości wynagrodzeń. Trzecie jest merytorycznie poprawne, ale tak generyczne, że ginie wśród tysięcy ogłoszeń na portalach pracy. I wszystkie trzy zostały ręcznie zamieszczone na trzech różnych kanałach, bo nikt nie wie, który kanał dla jakiej pozycji daje najlepszy zwrot.

To nie jest problem jakości pojedynczych rekruterów. To jest problem systemowy.

## Potrójne ryzyko każdego ogłoszenia

Ogłoszenia o pracę to najbardziej wrażliwy artefakt w całym procesie rekrutacji. Są jednocześnie dokumentem prawnym, pozycją budżetową i wizytówką - a w większości organizacji żaden z tych trzech aspektów nie jest sterowany systemowo.

**Ryzyko prawne: prawo antydyskryminacyjne dziś, przejrzystość wynagrodzeń jutro.** Każde dyskryminujące sformułowanie otwiera sprawę odpowiedzialności. "Polski jako język ojczysty" zamiast "biegła znajomość języka polskiego" - różnica leży w pozwie antydyskryminacyjnym. Przy pięćdziesięciu otwartych stanowiskach rocznie i średnio dwudziestu aplikacjach na stanowisko wystarczy jeden systematyczny błąd w sformułowaniu, żeby wygenerować pięciocyfrowe odszkodowania. Od czerwca 2026 dyrektywa o przejrzystości wynagrodzeń zaostrza wymagania: każde ogłoszenie musi zawierać konkretne widełki płacowe. Kto tę informację pominie lub obsługuje niespójnie, ryzykuje sankcje i traci zaufanie kandydatów, zanim dojdzie do pierwszej rozmowy.

**Problem kosztowy: rozproszenie bez sterowania.** Średnie koszty zatrudnienia w Polsce wynoszą od EUR 4 000 do EUR 6 000 (ok. 17 000-26 000 PLN). Znaczna część z tego idzie na ogłoszenia zamieszczane na niewłaściwych kanałach. Klasyczne pojedyncze publikacje na portalach kosztują od EUR 500 do EUR 1 300 za ogłoszenie. Kto bespielt pięć kanałów jednocześnie, wydaje szybko ponad EUR 5 000 na stanowisko samą publikację - nie wiedząc, który kanał dostarcza kwalifikowane aplikacje, a który tylko kliki.

**Problem jakości: niespójność niszczy employer branding.** Gdy to samo stanowisko pojawia się na rynku w trzech wariantach - raz z bullet pointami, raz jako tekst ciągły, raz z nieaktualnymi benefitami - sygnalizuje to organizacyjną dowolność. Przy średnio 164 dniach czasu wakatu na stanowiska specjalistyczne liczy się każdy dzień, w którym źle sformułowane ogłoszenie przyciąga niewłaściwych kandydatów lub odstraszy właściwych.

## Trzy warstwy kontroli zastępują przypadkowość, zanim rekruter zobaczy projekt

Agent ogłoszeniowy nie zastępuje rekrutera. Zastępuje przypadkowość. Z ustrukturyzowanego profilu wymagań generowany jest projekt ogłoszenia przechodzący trzy warstwy kontroli, zanim zobaczy go człowiek:

Pierwsza warstwa: zgodność antydyskryminacyjna. Każde sformułowanie jest sprawdzane względem katalogu reguł - język neutralny płciowo, brak dyskryminacji wiekowej, brak pośredniego dyskryminowania przez wymagania językowe. To nie jest sugestia stylistyczna, lecz twarda reguła. Co nie przechodzi, nie idzie dalej.

Druga warstwa: przejrzystość wynagrodzeń. Widełki płacowe są pobierane ze zdefiniowanych pasm wynagrodzeń i formatowane w wymaganej formie. Spójnie przez wszystkie ogłoszenia, wszystkie kanały, wszystkie języki. Bez odchylenia, bez zapomnienia.

Trzecia warstwa: optymalizacja kanałów. Które portale dla jakiej pozycji, jakiego regionu, jakiego poziomu senioralności dostarczają najlepsze wskaźniki konwersji, jest decydowane regułowo - nie intuicyjnie. Dane o wynikach wracają i ulepszają wybór kanałów dla następnego ogłoszenia.

Dopiero wtedy rekruter widzi projekt. I sprawdza to, co tylko człowiek może sprawdzić: czy tonalność się zgadza? Czy opis pasuje do faktycznej kultury zespołu? Czy są merytoryczne niuanse, które zna tylko ktoś, kto rozmawiał z działem merytorycznym?

## Co to oznacza dla kierownictwa rekrutacji

Pytanie nie brzmi, czy ogłoszenia o pracę zostaną zautomatyzowane. Pytanie brzmi, czy będą traktowane jako infrastruktura - z governance, wersjonowaniem i Audit Trail - czy pozostaną produktami przypadku, które przy następnym pozwie antydyskryminacyjnym lub pierwszej kontroli przejrzystości wynagrodzeń staną się przypadkiem odpowiedzialności.

Różnica między organizacją, która to rozwiązała, a taką, która nie, nie pokazuje się w pojedynczym tekście ogłoszenia. Pokazuje się w zdolności do udzielenia na pytanie "Jak zapewniacie, że wszystkie wasze ogłoszenia spełniają dyrektywę o przejrzystości wynagrodzeń?" systemowej odpowiedzi zamiast "To sprawdza każdy rekruter sam."

[Decision Layer](/pl/decision-layer/) czyni każdy krok przejrzystym: jakie reguły zastosowano, jakie kontrole zdano lub nie zdano, kto zatwierdził. Nie jako dokumentacja dokonywana po fakcie, lecz jako integralny element procesu. Przy systemie wysokiego ryzyka według EU AI Act - a dokładnie tym jest agent wpływający na to, kto widzi ogłoszenia o pracę - ta przejrzystość nie jest opcją, lecz obowiązkiem.

--- Learning Event Management Agent ---
> Zarządza logistyką szkoleń: rezerwacja sal, harmonogram trenerów, rejestracja uczestników, sprzęt i follow-up - terminowo.

Dział L&D koordynujący 30 wydarzeń szkoleniowych miesięcznie nie rozwiązuje problemu uczenia się. Rozwiązuje problem logistyczny. Porównywanie sal z liczbą uczestników, sprawdzanie dostępności trenerów, zamawianie materiałów na czas, prowadzenie list oczekujących, przetwarzanie anulowań, wysyłanie przypomnień, pilnowanie ewaluacji. Każde pojedyncze zadanie jest trywialne. W sumie wiążą 40 do 60 procent operacyjnej pojemności L&D - pojemności, która nie płynie ani w projektowanie programów, ani w mierzenie efektów.

I problem nie poprawia się, gdy organizacja rośnie. Pogarsza się proporcjonalnie.

## Dlaczego arkusze nie rozwiązują problemu, lecz nim są

W większości organizacji od 500 do 5000 pracowników koordynacja wydarzeń wygląda tak: arkusz Excel z terminami, drugi z dostępnością trenerów, trzeci z obłożeniem sal. Pomiędzy maile, zaproszenia kalendarzowe i ustne uzgodnienia. Ten system ma trzy strukturalne słabości, których nie da się naprawić lepszymi tabelami.

**Po pierwsze: konflikty wielozasobowe.** Każde wydarzenie szkoleniowe łączy co najmniej cztery zasoby - salę, trenera, grupę uczestników, materiały. Gdy warsztat na 20 osób wymaga sali z rzutnikiem, ale jedyna pasująca sala jest tego dnia zarezerwowana na seminarium dla kadry kierowniczej, zaczyna się łańcuch przeplanowań. Kalendarze trenerów się przesuwają, uczestnicy muszą być zaproszeni na nowo, zamówienia materiałów się nie zgadzają. W arkuszu konflikt widać dopiero, gdy już wystąpił. Nie wcześniej.

**Po drugie: kaskady anulowań.** Średni wskaźnik rezygnacji przy szkoleniach stacjonarnych wynosi 17 procent. Przy warsztacie na 20 miejsc brakuje więc średnio trzech do czterech uczestników. Gdy istnieje lista oczekujących, ktoś musi ręcznie awansować, poinformować awansowanego uczestnika, sprawdzić czy materiały wystarczą i powiadomić trenera o zmienionej grupie. Gdy lista oczekujących nie istnieje, miejsca pozostają puste - a koszty na głowę rosną, bo sala i trener są już zarezerwowani.

**Po trzecie: niewidoczne koszty.** Całodniowe szkolenie stacjonarne dla 20 uczestników kosztuje od EUR 5 000 do EUR 15 000 (ok. 21 000-65 000 PLN) - trener, sala, materiały, czas pracy uczestników wliczone. Przy 30 wydarzeniach miesięcznie dział L&D steruje sześciocyfrowym budżetem miesięcznym. Mimo to często nie wie, które wydarzenia były w pełni obłożone, które chronicznie niedozapisane i którzy trenerzy otrzymują najlepsze ewaluacje. Bo te dane leżą w różnych arkuszach i nikt nie ma czasu ich zestawić.

## Co [Decision Layer](/pl/decision-layer/) robi inaczej

Pointa przy logistyce szkoleniowej: niemal każdy krok koordynacyjny podąża za jasnymi regułami. Format wynika z typu szkolenia i liczby uczestników. Przypomnienia wychodzą w stałych terminach. Reguły anulowania zależą od wyprzedzenia. Awans z listy oczekujących podąża za kolejnością. Ewaluacje są wysyłane dzień po wydarzeniu.

```
Krok                       Kto decyduje    Dlaczego
─────────────────────────  ─────────────── ──────────────────────────────
Format ustalić             Reguły          Typ + pojemność determinują format
Trenera zidentyfikować     Agent           Match kwalifikacji + sprawdzenie kalendarza
Salę przypisać             Agent           Pojemność, wyposażenie, dostępność
Uczestników zaprosić       Reguły          Lista z analizy potrzeb lub rejestracji
Materiały zamówić          Reguły          Checklista per typ wydarzenia
Przypomnienia wysłać       Reguły          7 dni + 1 dzień przed wydarzeniem
Listę oczekujących         Reguły          Kolejność przy rezygnacji
Ewaluację uruchomić        Reguły          Dzień po wydarzeniu
Anulowanie przetworzyć     Reguły          Reguły zależne od terminu
```

Siedem z dziewięciu kroków to deterministyczne decyzje regułowe. Tylko dwa - identyfikacja trenera i przypisanie sali - wymagają logiki agentowej optymalizującej wiele zmiennych jednocześnie. Żaden krok nie wymaga ludzkiej decyzji indywidualnej.

## Jak zmienia się codzienna praca działu L&D

Gdy systemy stoją - LMS z funkcją wydarzeń, zarządzanie salami, pula trenerów z danymi kalendarzowymi - praca operacyjna zmienia się w trzech miejscach.

Czas planowania na wydarzenie spada z godzin do minut. Zamiast ręcznie porównywać kalendarze, sprawdzać sale i pisać do trenerów, kierownik L&D wprowadza typ szkolenia, grupę docelową i okres. Agent dostarcza kompletną propozycję: trener, sala, slot czasowy, lista materiałów. Pasuje propozycja - potwierdzenie jednym klikiem. Nie pasuje - dostosowanie ograniczeń i nowa propozycja.

Anulowania i przeplanowania tracą operacyjną siłę rażenia. Przy rezygnacji trenera agent natychmiast szuka kwalifikowanych zastępców z wolnym kalendarzem. Przy rezygnacji uczestników lista oczekujących awansuje automatycznie - wraz z powiadomieniem, dostosowaniem materiałów i zaktualizowaną listą uczestników.

Dział L&D dostaje dane sterujące, które wcześniej nie istniały. Wskaźniki obłożenia per format szkoleniowy, wzorce anulowań po dziale i dniu tygodnia, ewaluacje trenerów w czasie, średnie koszty per uczestnik i typ szkolenia. Nie jako pracochłonna analiza kwartalna, lecz jako bieżące raportowanie powstające automatycznie z danych rezerwacyjnych.

## Efekt infrastrukturalny

Silnik koordynacji wydarzeń - sala, osoby, materiały, planowanie czasowe optymalizowane względem dostępności - nie jest jednorazowym rozwiązaniem. Ten sam mechanizm, który planuje warsztat, może orkiestrować wydarzenie onboardingowe, terminować assessment center lub koordynować zebranie zakładowe. Wzorzec listy oczekujących staje się budulcem dla każdego agenta z zasobami o ograniczonej pojemności.

A każda rezerwacja, każde anulowanie, każde przeplanowanie jest protokołowane w Decision Log. Rada Zakładowa, mająca prawo konsultacyjne przy realizacji zakładowych szkoleń (Kodeks Pracy), widzi nie skondensowane zestawienie roczne, lecz udokumentowaną podstawę decyzyjną każdego pojedynczego wydarzenia. Transparentność ułatwiająca konsultację - bo dane są już ustrukturyzowane.

Kto koordynuje 30 wydarzeń miesięcznie ręcznie, administruje. Kto zleca ich automatyczną koordynację, steruje.

--- Learning Path Recommendation Agent ---
> Rekomenduje spersonalizowane ścieżki uczenia się na podstawie kompetencji, wymagań roli i aspiracji kariery. Rekomendacje niewiążące.

## Centralny problem: pełne katalogi, puste sale szkoleniowe

Większość organizacji nie ma deficytu oferty. Ma problem z przyporządkowaniem. Typowy LMS w firmie średniej wielkości zawiera kilkaset kursów, modułów i ścieżek certyfikacyjnych. Jednocześnie średni wskaźnik ukończenia przy formatach samokształceniowych wynosi od 5 do 15 procent. 44 procent firm jest niezadowolonych ze swojego LMS, 37 procent aktywnie szuka alternatyw. Oferta szkoleniowa rośnie, wykorzystanie stagnuje.

Wąskim gardłem nie jest treść. Wąskim gardłem jest pytanie: który kurs daje dokładnie tej osobie w dokładnie tej roli największy postęp rozwojowy?

Ręczna odpowiedź na to pytanie przerasta każdy dział L&D. Kierownik z dwunastoma bezpośrednimi podwładnymi musiałby na osobę porównać profil kompetencji, cel kariery, ukończone szkolenia i dostępną ofertę. Przy 800 pracownikach i 400 kursach powstają setki tysięcy możliwych kombinacji. Żaden człowiek nie nawiguje tego wiarygodnie. Efekt: rekomendacje z wyczucia, rozwój po zasadzie konewki, budżety bez dowodu skuteczności.

## Spersonalizowane ścieżki podnoszą wskaźnik ukończenia o 30 procent

Learning Path Recommendation Agent nie rozwiązuje problemu przyporządkowania przez więcej technologii, lecz przez lepszą architekturę decyzyjną. Przebieg podąża za jasnym łańcuchem:

```
Profil aktualny     Profil docelowy     Luka            Oferta
┌──────────┐      ┌──────────┐      ┌──────────┐    ┌──────────┐
│ Kompeten- │      │ Rola     │      │ Analiza  │    │ Matching │
│ cje,      │─────▶│ docelowa │─────▶│ luk      │───▶│ z        │
│ Kursy,    │      │ lub      │      │ Aktualny │    │ kata-    │
│ Rola      │      │ następny │      │ vs.      │    │ logiem   │
└──────────┘      │ krok     │      │ Wymagany │    │          │
     A            └──────────┘      └──────────┘    └──────────┘
                       H                 A                A

A = Agent decyduje    H = Człowiek decyduje
```

Kluczowy punkt: rola docelowa pozostaje przy człowieku. Pracownik definiuje w rozmowie rozwojowej, dokąd ma prowadzić droga. Wszystko przed i po - analiza profilu, ustalenie profilu wymagań roli docelowej, obliczenie luk, filtrowanie oferty, wybór formatu i dostawcy, kontrola budżetu i czasu, priorytetyzacja - agent potrafi szybciej, pełniej i spójniej niż jakiekolwiek ręczne wyszukiwanie.

Spersonalizowane ścieżki uczenia się podnoszą wskaźnik ukończenia udowodnieniowo o około 30 procent. Nie dlatego, że treść się poprawia, lecz dlatego, że dopasowanie się zgadza. Kto widzi dokładnie te moduły, które adresują jego konkretną lukę kompetencyjną, inwestuje czas nauki z widocznym zwrotem.

## Dlaczego to szczególnie istotne w firmach średniej wielkości

W organizacjach od 500 do 5000 pracowników zderzają się dwie rzeczywistości. Z jednej strony: 81,8 procent firm raportuje, że pracownicy mają za mało przestrzeni na rozwój. Z drugiej: 42,9 procent wskazuje niewystarczającą personalizację jako centralny problem strategii L&D.

Mało czasu i słaba trafność - to toksyczna kombinacja. Gdy pracownik ma na kwartał cztery godziny na rozwój, żadna z nich nie może wsiąknąć w irrelewantny kurs. Każda rekomendacja musi trafić.

Korporacje rozwiązują to dedykowanymi zespołami L&D tworzącymi indywidualne plany rozwoju. W firmach średniej wielkości ta pojemność nie istnieje. Trzech specjalistów od rozwoju pracowników na 2000 osób nie jest w stanie kuratorować 2000 indywidualnych ścieżek uczenia. Ale agent potrafi - i to aktualizowanych tygodniowo, nie raz w roku przy rozmowie rozwojowej.

## Przejrzystość zamiast czarnej skrzynki

Częsta obawa przy rekomendacjach algorytmicznych: dlaczego akurat ta oferta? [Decision Layer](/pl/decision-layer/) protokołuje każdy krok decyzyjny. Jakie dane wpłynęły, jaką wagę zastosowano, dlaczego kurs A priorytetyzowano przed kursem B. Ta transparentność nie jest obowiązkiem regulacyjnym - rekomendacje ścieżek uczenia nie są systemem wysokiego ryzyka według EU AI Act, dopóki pozostają niewiążące. Ale jest operacyjnie kluczowa.

Gdy Rada Zakładowa (organ konsultacyjny) pyta, według jakich kryteriów powstają rekomendacje, jest udokumentowana odpowiedź. Gdy przełożony kwestionuje rekomendację, uzasadnienie jest dostępne. A gdy pracownik odrzuca rekomendację, pozostaje to bez konsekwencji - to sugestia, nie przypisanie.

## Efekt infrastrukturalny

Framework rekomendacyjny nie pracuje w izolacji. Analiza profilu, obliczanie luk i matching oferty stanowią reużywalny fundament. Ten sam mechanizm, który rekomenduje ścieżki uczenia, może oceniać ścieżki kariery, identyfikować kandydatów na sukcesję lub uwidaczniać strategiczne luki kompetencyjne na poziomie organizacji.

Każda rekomendacja wytwarza przy tym dane: jakie luki występują nagminnie? Które oferty są akceptowane, które ignorowane? Które działy rozwijają się szybciej niż inne? Te dane wpływają z powrotem w planowanie - nie jako instrument kontroli nad jednostkami, lecz jako strategiczna wielkość sterująca planowaniem rozwoju.

Różnica wobec lepszego filtra LMS: filtr pokazuje kursy, które mogą pasować. Agent rekomendacyjny uzasadnia, dlaczego akurat ten kurs ma akurat teraz największą dźwignię - i dostarcza Audit Trail w komplecie.

--- Leave of Absence Agent ---
> Zarządza wnioskami o urlop dłuższy: weryfikacja uprawnień, obliczanie świadczeń, workflow zatwierdzeń i koordynacja powrotu do pracy.

Co miesiąc na biurko trafiają wnioski o nieobecność, które nie mogą czekać. Urlop rodzicielski z Kodeksu Pracy (art. 186). Urlop opiekuńczy (art. 173(1) KP). Sabbatical z regulaminu pracy. Urlop okolicznościowy z układu zbiorowego. Cztery podstawy prawne, cztery różne reżimy terminowe, cztery zestawy warunków uprawniających - i każdy pojedynczy wniosek wiąże pojemność HR, która właściwie jest potrzebna do pracy strategicznej.

Problem nie jest pojedynczy wniosek. Problem jest ich jednoczesność.

## Dlaczego właśnie teraz

Około 400 000 osób w Polsce korzysta rocznie z urlopów rodzicielskich (dane GUS). Od 2023 roku dyrektywa work-life balance znacząco rozszerzyła uprawnienia: urlop rodzicielski wydłużony do 41 tygodni, 9 tygodni nieprzenoszalnych na drugiego rodzica, urlop opiekuńczy na 5 dni. Wniosek o urlop rodzicielski można złożyć elektronicznie. To obniża barierę dla wnioskujących, ale zwiększa wolumen, który HR musi przetworzyć.

Jednocześnie rośnie zapotrzebowanie na opiekę. Kodeks Pracy zna urlop opiekuńczy (5 dni), zwolnienie z tytułu siły wyższej (2 dni lub 16 godzin), a niezależne przepisy regulują urlop wychowawczy (do 36 miesięcy). Każdy wariant ma własne warunki, terminy i wpływ na wynagrodzenie i ubezpieczenie społeczne.

Dochodzą codzienne przypadki: urlop okolicznościowy z okazji ślubu, narodzin, zgonu. Zaległy urlop - według danych rynkowych dwie trzecie pracowników zaczyna nowy rok ze średnio 7,6 niewykorzystanymi dniami. Urlop bezpłatny na indywidualnych warunkach.

Dla HR powstaje z tego rachunek z wieloma niewiadomymi. A konsekwencje przy błędach nie są trywialne: niedotrzymane terminy przy wnioskach o urlop rodzicielski przesuwają rozpoczęcie. Błędne obliczenie uprawnień przy urlopie opiekuńczym generuje ryzyka pracowniczo-prawne. Brak planowania zastępstw uderza w operacyjny biznes.

## Co zmienia agent

[Decision Layer](/pl/decision-layer/) oddziela w tym procesie dwa światy.

Pierwszy świat to reguły. Sprawdzenie uprawnień, obliczenie terminów, wpływ na wynagrodzenie - to operacje deterministyczne. Czy ktoś ma prawo do urlopu rodzicielskiego, stoi w Kodeksie Pracy. Czy termin wniosku jest dotrzymany, wynika z daty urodzenia dziecka i planowanego rozpoczęcia. Jak sześciomiesięczny urlop opiekuńczy wpływa na PPK, stoi w regulaminie programu. Te sprawdzenia nie potrzebują człowieka. Potrzebują reguł, które są prawidłowo i kompletnie odwzorowane.

Drugi świat to decyzje. Kto przejmie zastępstwo? Czy sabbatical zostanie zatwierdzony, mimo że nie istnieje ustawowe prawo? Jak zorganizować powrót po 14 miesiącach urlopu rodzicielskiego? Te pytania wymagają kontekstu, osądu i odpowiedzialności. Pozostają przy przełożonym i HR.

Między tymi dwoma światami leży wąski pas, w którym AI wnosi wkład: propozycje zastępstw na podstawie profili kompetencji i dostępności. Żadna decyzja - propozycja zawężająca przestrzeń poszukiwań.

```
Wniosek wpływa
    |
    v
[Reguły] Klasyfikacja --> Rodzicielski | Opiekuńczy | Sabbatical | Okolicznościowy
    |
    v
[Reguły] Sprawdzenie uprawnień --> KP | Regulamin | Układ zbiorowy | Umowa
    |
    v
[Reguły] Obliczenie terminów + wpływ na wynagrodzenie
    |
    v
[AI] Propozycja zastępstwa (kompetencje + dostępność)
    |
    v
[Człowiek] Potwierdzenie zastępstwa + zatwierdzenie wniosku
    |
    v
[Reguły] Planowanie powrotu + automatyczne przypomnienia
```

## Przy kilkuset sprawach rocznie spada czas realizacji i wskaźnik błędów jednocześnie

Różnica pokazuje się nie w pojedynczym wniosku. Pokazuje się w sumie w skali roku.

Firma z 2000 pracownikami przetwarza rocznie typowo kilkaset spraw nieobecności poza zwykłym urlopem: urlop rodzicielski, opiekuńczy, okolicznościowy, sabbatical, bezpłatne zwolnienia. Każda sprawa ma fazę sprawdzenia (uprawnienie, termin, wynagrodzenie), fazę koordynacji (zastępstwo, przekazanie) i fazę powrotu (re-onboarding, reaktywacja systemów).

Gdy faza sprawdzenia jest zautomatyzowana, dzieją się dwie rzeczy jednocześnie: czas realizacji spada, bo żaden wniosek nie czeka na biurku. I wskaźnik błędów spada, bo reguły nie przeoczają terminów i nie mylą podstaw prawnych.

Koordynacja zastępstw nie zaczyna się dwa tygodnie przed rozpoczęciem nieobecności, lecz natychmiast po wpłynięciu wniosku. To daje zespołom czas na uporządkowane przekazania zamiast rozwiązań awaryjnych.

Powrót nie jest zapominany. Cztery tygodnie przed udokumentowaną datą powrotu przełożony i HR otrzymują przypomnienie. Przy dłuższych nieobecnościach zawiera ono checklistę re-onboardingową dostosowaną do rodzaju i czasu trwania nieobecności.

## Wkład infrastrukturalny

Silnik sprawdzania uprawnień budowany tu dla urlopu rodzicielskiego i opiekuńczego jest reużywalny. Ta sama logika - uprawnienie ustawowe, uprawnienie umowne, obliczenie terminów - jest potrzebna w zarządzaniu okresem próbnym i przy generowaniu umów. Wzorzec propozycji zastępstw stanowi bazę dla planowania zasobów ludzkich. Automatyczne planowanie powrotu to wzorzec dla każdego agenta uruchamiającego działania następcze sterowane czasem.

To jest właściwy punkt: każdy agent zbudowany porządnie wytwarza infrastrukturę dla następnego.

--- Legal Contract Review Agent ---
> Wspiera przegląd umów handlowych: wyodrębnia warunki, porównuje ze standardami i flaguje odchylenia, ryzyka i brakujące klauzule.

## Prawnicy spędzają połowę czasu na pracy, która nie wymaga ekspertyzy prawnej

Według Gartnera nawet 50 procent zasobów działu prawnego pochłania zarządzanie umowami. Większość tej pracy to nie myślenie prawnicze - to czytanie, porównywanie, sortowanie. Umowa o świadczenie usług jest zestawiana z wewnętrznym szablonem klauzul. NDA jest sprawdzana pod kątem odchyleń w czasie trwania i jurysdykcji. Umowa ramowa jest porównywana klauzula po klauzuli ze standardem.

Ta praca wymaga staranności. Ale w większości przypadków nie wymaga osądu prawnego. Pytanie nie brzmi, czy prawnik potrafi przeczytać klauzulę odpowiedzialności - lecz czy jest właściwą osobą, aby stwierdzić, że jest ona identyczna z wersją standardową.

Właśnie tutaj leży wzorzec, który można zautomatyzować: porównanie tekstu umowy ze zdefiniowanymi standardami. Ekstrakcja znanych klauzul ryzyka. Klasyfikacja według typu umowy. W dziale prawnym sprawdzającym 200 umów kwartalnie oznacza to różnicę między zespołem, który reaguje, a zespołem, który kształtuje.

## 92 minuty na umowę to nie standard jakości - to wąskie gardło

Średni czas przeglądu standardowej umowy wynosi 92 minuty. W przypadku NDA - najprostszego typu umowy - obecne systemy AI wykonują to samo porównanie w 26 sekund z dokładnością 94 procent ([Sirion, 2026](https://www.sirion.ai/library/contract-insights/ai-playbook-redlining-vs-manual-contract-review/)). Brakujące 6 procent nie jest argumentem przeciwko automatyzacji. To argument za właściwym podziałem: agent sprawdza standardowe klauzule. Prawnik sprawdza odchylenia.

Wyobraźmy sobie typowy tydzień w dziale prawnym obsługującym umowy zakupowe. W poniedziałek przychodzą trzy nowe umowy z dostawcami. W środę przedłużona umowa ramowa ze zmienionymi warunkami odpowiedzialności. W piątek NDA do due diligence. Każda z tych umów przechodzi ten sam proces: rozpoznać typ, porównać standardowe klauzule, oznaczyć odchylenia, ocenić ryzyka. Dopiero potem zaczyna się właściwa praca prawnicza - ocena, czy odchylenie jest akceptowalne, czy wymaga renegocjacji.

Agent analizy umów przejmuje pierwszych sześć kroków tego procesu. Ostatnie trzy - ocena ryzyka przez prawnika, rekomendacja negocjacyjna i zatwierdzenie - pozostają tam, gdzie wymaga tego prawo: u człowieka.

## Sześć kroków decyzyjnych zautomatyzowanych, trzy pozostają u prawnika

[Decision Layer](/pl/decision-layer/) rozkłada każdy proces przeglądu umowy na pojedyncze kroki decyzyjne i definiuje dla każdego kroku: Człowiek, silnik reguł lub AI. W przypadku analizy umów ten rozkład daje jasny obraz.

Kroki dające się zautomatyzować podążają za wzorcem: porównują stan rzeczywisty ze stanem docelowym. Czy ta umowa to NDA, czy umowa o świadczenie usług? Czy klauzula odpowiedzialności odpowiada standardowi, czy od niego odbiega? Czy umowa zawiera karę umowną? Na te pytania można wiarygodnie odpowiedzieć dzięki dobrze utrzymanej bibliotece klauzul.

Kroki wymagające człowieka podążają za innym wzorcem: wymagają osądu w warunkach niepewności. Czy odbiegający limit odpowiedzialności jest akceptowalny dla tego konkretnego dostawcy? Czy wartość biznesowa umowy przeważa nad ryzykiem brakującej klauzuli gwarancyjnej? Czy umowa może być zatwierdzona na tych warunkach? To są decyzje, które wymagają kontekstu, którego żaden agent nie posiada - relacji biznesowej, historii negocjacji, priorytetów strategicznych.

Wynik governance tego agenta na poziomie 55-62 jest znacznie wyższy niż w przypadku czystej automatyzacji procesów. Odzwierciedla to fakt, że analiza umów operuje bliżej decyzji istotnych prawnie niż np. payroll czy ewidencja czasu pracy. Agent może analizować i oznaczać. Oceniać i decydować nie może.

## Biblioteka klauzul decyduje o sukcesie - i jeszcze nie istnieje

Ten agent to agent H3. Oznacza to: wyższą złożoność, niższy stopień dojrzałości niż ugruntowane automatyzacje procesów. Obecne systemy AI tracą 10 do 20 procent dokładności przy umowach dłuższych niż 1000 znaków promptu ([WorldCC / KPMG, 2025](https://kpmg.com/us/en/articles/2025/agentic-ai-in-clm-balancing-human-and-machine-expertise.html)). W przypadku 30-stronicowej umowy ramowej to istotny czynnik.

Najważniejszym warunkiem nie jest technologia - to utrzymana biblioteka klauzul z firmowymi standardami dla każdego typu umowy. Bez tego punktu odniesienia agent nie ma z czym porównywać. Biblioteka definiuje, co oznacza "standard". Dopiero wtedy agent może rozpoznać, co jest "odchyleniem".

Firmy, które już prowadzą system Contract Lifecycle Management i udokumentowały swoje standardowe klauzule, mogą szybciej wdrożyć tego agenta produktywnie. Firmy bez tej podstawy budują ją wraz z agentem - co spowalnia wdrożenie, ale tworzy samodzielną wartość. Ustrukturyzowana biblioteka klauzul poprawia przegląd umów nawet bez agenta, ponieważ po raz pierwszy definiuje jednolitą miarę.

Uczciwy horyzont czasowy: nie produktywny w przyszłym miesiącu, lecz po zbudowaniu biblioteki klauzul i fazie kalibracyjnej z działem prawnym. Zysk potem: prawnicy, którzy poświęcają czas na sprawy, w których faktycznie potrzebny jest osąd prawny.

--- Agent cyklu merit ---
> Roczny cykl wynagrodzeń: KP art. 11-2/18-3c równa płaca, EU AI Act Annex III(4)(b) Bias-Audit, EU Pay Transparency 2023/970, próg 5 procent Gender Pay Gap z walidacją Compa-Ratio.

## Pięć miesięcy od zatwierdzenia budżetu do pierwszej wypłaty

Ten agent stosuje zasadę [Decision Layer](/pl/decision-layer/): każda decyzja jest oparta na regułach, wspomagana AI lub jawnie przypisana człowiekowi. Jest sklasyfikowany zgodnie z [EU AI Act 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) Anneks III(4)(b) jako System Wysokiego Ryzyka i podlega tym samym zaostrzonym obowiązkom dot. Systemu Zarządzania Ryzykiem, Governance Danych, Transparentności, Nadzoru Człowieka i Bias-Audit od 2.8.2026.

Typowy cykl merit trwa pięć miesięcy. Nie dlatego, że decyzje są trudne, ale dlatego, że proces jest. Zatwierdzenie budżetu we wrześniu. Przygotowanie danych w październiku. Dystrybucja spreadsheet do 30, 50, 80 menedżerów w listopadzie. Zwroty przez tygodnie. Rundy kalibracyjne w styczniu. Korekty. Przekazanie do Payroll w lutym. Pierwsza wypłata najwcześniej w marcu.

Problem nie leży w czasie. Leży w tym, co dzieje się między krokami - lub nie dzieje: systematyczna analiza equity, dokumentowalne uzasadnienia dla odwrócenia ciężaru dowodu KP art. 18-3d, walidacja Compa-Ratio, spójność między działami i poziomami hierarchii.

## Co pozostaje niewidoczne w rundach spreadsheet

Gdy 60 menedżerów równolegle wprowadza propozycje wynagrodzeń w plikach Excel, nie powstaje spójny proces. Powstaje zbiór indywidualnych ocen, których nikt nie może zagregować, zwalidować ani porównać w czasie rzeczywistym. Typowe konsekwencje:

**Naruszenia widełek bez ostrzeżenia.** Menedżer rekomenduje podwyżkę, która przesuwa pracownika powyżej górnej granicy widełek wynagrodzenia. W spreadsheet wykrywa się to dopiero, gdy Comp&Ben ręcznie sprawdza plik - często tygodnie później, często wcale. Firmy regularnie raportują, że pracownicy są wynagradzani poza zdefiniowanymi widełkami płacowymi bez systematycznego wykrycia.

**Luki equity pozostają ukryte.** Gdy 60 plików Excel jest wypełnianych równolegle, runda kalibracyjna w styczniu nie zauważa, że kobiety-menedżerowie sprzedaży systematycznie otrzymują 4 procent niższe podwyżki niż mężczyźni - lub że luka płacowa między 50+ i pracownikami w środku kariery w określonej funkcji wynosi 7 procent.

**Ryzyko odwrócenia ciężaru dowodu z KP art. 18-3d bez audit-trail.** W procesie sądowym ciężar dowodu odwraca się na mocy KP art. 18-3d i Ustawy Antydyskryminacyjnej z 3.12.2010 - jeśli pracownik przedstawi wskaźniki dyskryminacji (anomalię statystyczną, brak uzasadnienia, podejrzany timing), to pracodawca musi udowodnić, że dyskryminacja nie zaszła. Bez udokumentowanego, odtwarzalnego uzasadnienia każdej zmiany taki ciężar dowodu jest praktycznie nie do spełnienia. Pozew zbiorowy Mobley v. Workday (Kalifornia, 2023) przeciwko ponad 40 kandydatom dowodzi, że ryzyko jest systemowe.

## Kumulatywne ryzyka sankcji: równa płaca, EU AI Act, RODO i EU Pay Transparency

Ryzyka sankcji za nieudane zarządzanie cyklem merit kumulują się i są istotne. KP art. 18-3d daje roszczenie o odszkodowanie nie niższe niż minimalne wynagrodzenie pomnożone przez liczbę miesięcy, do tego dochodzi odpowiedzialność pracodawcy z KP art. 18-3b, odsetki ustawowe i koszty postępowania. W procesach grupowych obejmujących wielu pracowników z tej samej grupy porównawczej kwoty szybko sięgają siedmiocyfrowych sum w PLN. Odwrócenie ciężaru dowodu z KP art. 18-3a i 18-3d czyni obronę bez udokumentowanego uzasadnienia każdej zmiany praktycznie niemożliwą.

EU AI Act 2024/1689 Anneks III(4)(b) klasyfikuje decyzje wynagrodzeniowe HR jako system wysokiego ryzyka z karą do 35 mln EUR lub 7 procent globalnego obrotu grupy. RODO art. 83 ust. 5 przewiduje do 4 procent obrotu grupy lub 20 mln EUR. EU Pay Transparency 2023/970 dokłada minimalne standardy sankcji i odwrócenie ciężaru dowodu. Naruszenie obowiązku CSRD ESRS S1-10 prowadzi do zastrzeżenia audytora, odpowiedzialności Rady Nadzorczej (KSH art. 382) i ujawnienia w GPW WIG-ESG, a pominięcie konsultacji z Radą Pracowników - do nakazu PIP, procedury sądu pracy i sankcji do 30 000 PLN za czyn.

Pozew zbiorowy Mobley v. Workday (Kalifornia, 2023) jako precedens dla uprzedzeń AI w oprogramowaniu wynagrodzeniowym HR kształtuje linię organów nadzorczych i standardy audytorów - dlatego Workday, SAP SuccessFactors i Oracle Cloud HCM uzupełnia się narzędziami do proaktywnego ograniczania uprzedzeń.

## EU Pay Transparency Directive 2023/970 jako presja zgodności

Od 7 czerwca 2026 [EU Pay Transparency Directive 2023/970](https://eur-lex.europa.eu/eli/dir/2023/970/oj) (transpozycja krajowa) obliguje do dokumentowania podstaw dla każdej zmiany. Przy odchyleniach Gender Pay Gap o 5 procent niewyjaśnionych (Article 9), uruchamiają się obowiązki Joint Pay Assessment i procedury naprawy w ciągu 6 miesięcy (Article 10). Pracownicy otrzymują prawo dostępu do mediany wynagrodzenia grupy porównawczej (Article 7), w ogłoszeniach o pracę widełki płacowe są obowiązkowe (Article 6), a pytanie o historię wynagrodzenia od poprzednich pracodawców jest zabronione (Article 5).

Ciężar dowodu w roszczeniach o dyskryminację wynagrodzeniową odwraca się (Article 18): To do pracodawcy należy wykazanie, że dyskryminacja nie zaszła. Obowiązki raportowania Gender Pay Gap stopniują od 250 pracowników (od 2027) do 100 pracowników (od 2031). Sankcje: minimalne standardy Article 20 z karami i odszkodowaniami. Polska transpozycja krajowa do 7.6.2026 oczekiwana z zaostrzeniem KP art. 18-3c i Konstytucji RP art. 32.

## EU AI Act Anneks III(4)(b): klasyfikacja wysokiego ryzyka, DPIA i FRIA

Merit-Cycle-Governance-Agent podlega EU AI Act 2024/1689, Anneks III(4)(b), jako system wysokiego ryzyka dla decyzji wynagrodzeniowych HR. Obowiązki od 2.8.2026 obejmują:

- **Article 9, zarządzanie ryzykiem**: identyfikacja, analiza, ocena i ograniczanie ryzyka uprzedzeń (luki płacowe według płci, wieku, pochodzenia etnicznego i niepełnosprawności)
- **Article 10, governance danych**: jakość danych treningowych, wykrywanie uprzedzeń oraz testy Demographic Parity i Equal Opportunity
- **Article 13, transparentność**: informacja o działaniu, dokładności, odporności i wynikach audytu uprzedzeń
- **Article 14, nadzór człowieka**: obowiązkowy człowiek w pętli przy każdej rekomendacji
- **Article 26, obowiązki deployera**: DPIA, konsultacja z organem nadzorczym, monitoring po wdrożeniu i zgłaszanie incydentów
- **Article 27, ocena wpływu na prawa podstawowe (FRIA)**: przed wdrożeniem, w konsultacji z RPO, IOD i Radą Pracowników

Kary do 35 mln EUR lub 7 procent globalnego obrotu grupy. Cross-Reference RODO art. 35 obowiązek DPIA przy systematycznej zautomatyzowanej ocenie ze znaczącym wpływem. [Mobley v. Workday klasyfikacja klasy action](https://www.courtlistener.com/docket/67476007/mobley-v-workday-inc/) (Northern District California 2023) - zarzut AI bias w oprogramowaniu rekrutacyjnym HR przeciwko 40+ kandydatom ADEA - służy jako US precedens i kształtuje linię organów nadzorczych UE.

## Podstawy równego traktowania: Kodeks Pracy i Konstytucja RP art. 32

Polski porządek prawny opiera się na Konstytucji RP - art. 32 (równość wobec prawa), art. 33 (równość kobiet i mężczyzn) i art. 65 (wolność pracy). Kodeks Pracy dodaje zasadę równego traktowania (art. 11-2), zakaz dyskryminacji bezpośredniej i pośredniej (art. 18-3a, m.in. ze względu na wiek, płeć, niepełnosprawność, narodowość, przekonania polityczne, przynależność związkową, pochodzenie etniczne czy orientację seksualną), zasadę równej płacy za równą pracę (art. 18-3c) oraz prawo do odszkodowania (art. 18-3d).

Ustawa Antydyskryminacyjna z 3.12.2010 wdraża dyrektywy UE w zakresie równego traktowania z odwróceniem ciężaru dowodu (art. 14). Uchwały Sądu Najwyższego III PZP 5/19 z 9.7.2020 oraz III PZP 12/15 z 22.6.2017 wzmacniają zasady równego traktowania w wynagrodzeniu, a skargi z odwróceniem ciężaru dowodu z KP art. 18-3d rozpatrują sądy pracy, sądy apelacyjne i Izba Pracy Sądu Najwyższego.

## Equity audit jako przewaga nad procesem manualnym

Equity Analysis Engine statystycznie sprawdza wszystkie chronione cechy KP art. 18-3a (płeć, wiek, niepełnosprawność, religia, narodowość, przekonania polityczne, przynależność związkowa, pochodzenie etniczne, rasa, orientacja seksualna). Dla każdej cechy mierzony jest Demographic Parity (równa częstotliwość zmian w grupach) i Equal Opportunity (równa wielkość zmiany przy porównywalnej wydajności). Przy statystycznie istotnych odchyleniach automatyczna eskalacja do HR Lead z KP art. 18-3c-zgodnym audit-trail.

To nie tylko ochrona compliance: badania (np. McKinsey Diversity Wins, BCG Closing the Gap, Sedlak & Sedlak Pay Equity Reports) pokazują 4-6 procent luk equity w polskim Mittelstand i 2-4 procent w spółkach WIG-30, które pozostają manualnie niewykryte. Agent czyni je widocznymi i tworzy fundament danych dla ukierunkowanych zmian korygujących.

## Cross-reference do Compensation-Benchmarking, Performance-Review i Payroll

Merit-Cycle-Governance-Agent jest osadzony w pipeline wyspecjalizowanych agentów HR: [Compensation-Benchmarking-Agent](/pl/katalog-agentow-hr/compensation-benchmarking-agent/) dostarcza widełki wynagrodzeniowe, Compa-Ratios i dane widełek płacowych. [Performance-Review-Agent] dostarcza oceny wydajności jako warunek wstępny uprawnień. [Payroll-Calculation-Agent](/pl/katalog-agentow-hr/payroll-calculation-agent/) odbiera zatwierdzone zmiany z prawidłową datą efektywności. [Payroll-Reporting-Agent](/pl/katalog-agentow-hr/payroll-reporting-agent/) generuje CSRD ESRS S1-10 Equal Pay Reporting. [HR-Document-Management-Agent](/pl/katalog-agentow-hr/hr-document-management-agent/) archiwizuje KP art. 94-zgodne uzasadnienia zmian 5-letni okres. [Audit-Compliance-Agent](/pl/katalog-agentow-hr/audit-compliance-agent/) weryfikuje EU AI Act Article 26 obowiązki deployerów i spójność DPIA. [Interview-Scheduling-Agent](/pl/katalog-agentow-hr/interview-scheduling-agent/) stosuje EU Pay Transparency Article 6 widełki płacowe w ogłoszeniach.

## Na pierwszy rzut oka

- **Klasyfikacja**: EU AI Act 2024/1689 Anneks III(4)(b) System Wysokiego Ryzyka HR Decyzje Wynagrodzeniowe od 2.8.2026
- **Kotwice zgodności**: Kodeks Pracy (art. 11-2, 18-3a, 18-3c, 18-3d), Konstytucja RP art. 32, Ustawa Antydyskryminacyjna z 3.12.2010, EU Pay Transparency 2023/970, RODO, CSRD ESRS S1-10 oraz GPW WIG-ESG
- **Konsultacje**: obowiązkowe z Radą Pracowników (Ustawa z 4.07.2006) i ze związkami zawodowymi (Ustawa z 23.05.1991, art. 25)
- **Próg równości**: niewyjaśniona luka płacowa powyżej 5 procent wyzwala Joint Pay Assessment i sześciomiesięczny obowiązek naprawy z EU Pay Transparency
- **Kary**: do 35 mln EUR lub 7 procent globalnego obrotu grupy z EU AI Act, do 4 procent lub 20 mln EUR z RODO, odszkodowanie z KP art. 18-3d oraz sankcje PIP do 30 000 PLN
- **Obowiązek audytu**: DPIA, FRIA i kwartalny audyt uprzedzeń, weryfikacja audytora CSRD od 250 pracowników oraz roczne raportowanie GPW WIG-ESG
- **US precedens**: Mobley v. Workday Northern District California 2023 klasyfikacja klasy action AI bias HR software

### Rozdział decydentów Merit-Cycle-Governance

| Krok | Decydent | Uzasadnienie |
|------|----------|--------------|
| Ustalenie budżetu | H | Strategia Zarządu i przygotowanie CSRD |
| Sprawdzenie uprawnień | R | Staż, wydajność i zawieszenia według reguł |
| Dostarczenie benchmarku | R | Deterministyczne obliczenie Compa-Ratio |
| Rekomendacja menedżera | H | Indywidualna wydajność i ryzyko retencji |
| Walidacja widełek | R | Automatyczne sprawdzenie granic min-max |
| Zgodność budżetowa | R | Deterministyczne śledzenie w czasie rzeczywistym |
| Analiza equity | A | Statystyczne wykrywanie uprzedzeń z walidacją człowieka |
| Eskalacja equity | R | Próg powyżej 5 procent z EU Pay Transparency 2023/970 |
| Workflow zatwierdzania | R | Macierz zatwierdzania według hierarchii i pozycji Compa-Ratio |
| Zatwierdzenie HR Lead | H | Ostateczne zatwierdzenie zgodne z Kodeksem Pracy |
| Informacja RODO | R | Standardowy workflow z RODO art. 13, 14 i 22 ust. 3 |
| Rozmowa wynagrodzeniowa | H | Osobista rozmowa, wymiar relacyjny |
| Przekazanie do Payroll | R | Data efektywności i korekta PIT/ZUS, deterministyczne |
| Raportowanie CSRD | R | ESRS S1-10 i EU Pay Transparency, deterministyczne |

--- Offboarding Agent ---
> Orkiestruje offboarding: checklist przez HR, IT i kierownictwo, transfer wiedzy, zwrot sprzętu i dokumentacja wyjścia.

## Znaczna część byłych pracowników nadal ma aktywne dostępy

Agent działa zgodnie z zasadą [Decision Layer](/pl/decision-layer/): każda decyzja jest oparta na regułach, wspierana przez AI lub przypisana człowiekowi.

Znaczna część byłych pracowników po odejściu nadal posiada aktywne dane dostępowe - w wielu organizacjach te nieaktywne konta stanowią mierzalny odsetek wszystkich użytkowników w Identity Provider. W istotnej części kont oznaczonych jako nieaktywne nadal istnieją żywe uprawnienia w kluczowych aplikacjach. A wiele firm potrzebuje więcej niż trzech dni, aby zablokować wszystkie dostępy systemowe po odejściu. Niektórym nigdy nie udaje się tego zrobić w pełni.

To nie jest problem marginalny. To przepustka dla każdego atakującego, który woli używać ważnych poświadczeń niż przebijać się przez zapory.

## Pięć nurtów, zero dyrygenta

Proces offboardingu dotyka jednocześnie co najmniej pięciu obszarów odpowiedzialności. Żaden z nich nie czeka na inny. Wszystkie mają własne terminy, własne systemy i własne punkty ślepe.

```
Wypowiedzenie/porozumienie stron
    |
    +-- HR: zamknięcie akt osobowych, zgłoszenia, świadectwo pracy
    +-- IT: zwrot sprzętu, blokada dostępów, zwolnienie licencji
    +-- Dział merytoryczny: transfer wiedzy, przekazanie projektów
    +-- Menedżer: rozmowa wyjściowa, dokumentacja feedbacku
    +-- Ochrona danych: uruchomienie terminów usuwania, sprawdzenie obowiązków retencji
    |
Ostatni dzień pracy (wszystko musi być zrobione)
    |
Faza poprocesowa: świadectwo pracy, usuwanie zgodne z RODO, boomerang-tracking
```

W praktyce HR koordynuje to poprzez checklistę i maile przypominające. Przy trzech odejściach na kwartał to działa. Przy trzydziestu upada - i to po cichu. Nikt nie zauważa dostępu VPN, który jest jeszcze aktywny przez dwa miesiące. Nikt nie pyta o folder SharePoint z danymi klientów, do którego były pracownik nadal ma dostęp.

## Dlaczego offboarding jest droższy, niż się wydaje

Widoczne koszty źle sterowanego odejścia są znikome: zapomniany laptop, opóźniona deregistracja. Niewidoczne koszty nie są.

Znaczna część menedżerów HR szacuje roczne koszty niekonsekwentnego offboardingu na sześciocyfrowe kwoty w euro - przez utratę wiedzy, ryzyka bezpieczeństwa i nakłady na zastępstwa. Tylko mniejszość firm zapewnia odpowiedni transfer wiedzy przy odejściu. Duża część wiedzy specjalistycznej stanowiska istnieje wyłącznie w głowie pracownika i nie może być łatwo zastąpione przez następcę.

Trzy czynniki kosztowe są szczególnie istotne:

**Ryzyko bezpieczeństwa.** Osierocone konta to najprostszy wektor ataku. Bez brute-force, bez phishingu - poświadczenia nadal istnieją. W świecie, gdzie przeciętna firma korzysta z 275 aplikacji SaaS, ręczne deprovisioning to iluzja.

**Utrata wiedzy.** Koszty utraty eksperta merytorycznego mogą być dwudziestokrotnie wyższe od standardowych kosztów rekrutacji i wdrożenia. Nie dlatego, że osoba jest niezastąpiona, ale dlatego, że jej nieudokumentowana wiedza taka jest.

**Potencjał boomerang.** 35 procent wszystkich nowych zatrudnień to obecnie powracający pracownicy. Ich wskaźnik retencji jest o 44 procent wyższy niż u zupełnie nowych pracowników. Chaotyczne odejście niszczy dokładnie tę relację, która umożliwiłaby ponowne zatrudnienie.

## Trzy okna czasowe, trzy różne problemy

Offboarding to nie pojedyncze zdarzenie. Rozpada się na trzy fazy o fundamentalnie różnych wymaganiach.

**Przed ostatnim dniem:** Organizacja transferu wiedzy, przekazanie projektów, wdrożenie następcy. Tu decyduje menedżer, która wiedza jest krytyczna - żadna reguła nie potrafi tego zautomatyzować, ponieważ wymaga wiedzy kontekstowej o dynamice zespołu i zależnościach projektowych.

**W ostatnim dniu:** Zwrot sprzętu, blokada dostępów, odebranie karty. To jest w pełni oparte na regułach. Które urządzenia muszą wrócić, stoi na liście wyposażenia z onboardingu. Które dostępy są blokowane, wynika z profilu uprawnień. Czas i kolejność podążają za planem deaktywacji - krytyczne systemy natychmiast, przekierowanie e-maili po zdefiniowanym okresie przejściowym.

**Po odejściu:** Wystawienie świadectwa pracy, przestrzeganie terminów usuwania, sporządzenie rozliczenia końcowego. Roszczenie o świadectwo pracy (art. 97 Kodeksu Pracy) przedawnia się po trzech latach, ale umowne terminy wykluczające mogą obowiązywać znacznie krócej. Obowiązek usuwania danych RODO biegnie równolegle do handlowo-podatkowych obowiązków retencji od sześciu do dziesięciu lat - pole napięcia, które bez jasnego sterowania regularnie prowadzi do naruszeń.

```
Faza              Typowy błąd                       Konsekwencja
──────────────    ──────────────────────────────    ────────────────────────
Przed odejściem   Brak zaplanowanego transferu      42% wiedzy utracone
Ostatni dzień     VPN/cloud niezablokowane          Ryzyko bezpieczeństwa
Po odejściu       Świadectwo po 4 miesiącach        Groźba pozwu
Po odejściu       Zapomniane usunięcie RODO         Kara do 20 mln EUR (USD 22 mln)
```

## Sześć z dziesięciu kroków oparte na regułach, jedno wsparcie AI przy świadectwie pracy, trzy decyzje pozostają ludzkie

Offboarding Agent jest lustrzanym odbiciem Onboarding Workflow Agent. Ten sam silnik orkiestracji, ta sama architektura szablonów, przypisywania zadań i monitorowania terminów - tylko w odwrotnym kierunku.

Gdy odejście zostanie zarejestrowane w systemie HR, dzieją się jednocześnie trzy rzeczy: silnik reguł określa typ offboardingu na podstawie powodu odejścia - wypowiedzenie przez pracodawcę, rezygnacja pracownika, porozumienie stron i emerytura generują różne checklisty. Pełna lista zadań jest generowana z szablonu i rozdzielana do odpowiedzialnych stron. Od tego momentu agent monitoruje terminy i eskaluje w razie opóźnień.

Architektura decyzyjna jest świadomie restrykcyjna. Z dziesięciu kroków procesu sześć to reguły, jeden wspomagany przez AI, a trzy pozostają u człowieka. AI jest wykorzystywane wyłącznie przy szkicu świadectwa pracy - tam, gdzie z opisu obowiązków, czasu zatrudnienia i oceny wyników generowany jest szkic tekstu. To, czy świadectwo zostanie zatwierdzone, czy wywiad wyjściowy się odbędzie i która wiedza jest uznawana za krytyczną, decydują menedżer i HR osobiście.

## Usuwanie zgodne z RODO jako problem architektoniczny

Większość firm traktuje obowiązki usuwania jako zadanie dla inspektora ochrony danych. To działa, dopóki ktoś o tym pamięta. Przy 50 odejściach rocznie w systemach bez centralnej rutyny usuwania w pewnym momencie nikt już o tym nie pamięta.

Pole napięcia jest realne: dokumentacja płacowa musi być przechowywana od sześciu do dziesięciu lat. Dokumenty rekrutacyjne muszą być usunięte najpóźniej po sześciu miesiącach. Akta osobowe podlegają trzyletniemu okresowi przedawnienia roszczeń pracowniczych. Przy naruszeniach polski Urząd Ochrony Danych Osobowych może nałożyć kary od 10 000 do 50 000 euro (USD 10 900 - 54 700) za pojedynczy przypadek - w górę otwarte do 20 milionów euro (USD 22 mln) lub 4 procent globalnego rocznego obrotu.

Agent offboardingu nie rozwiązuje tego przez usuwanie, lecz przez zarządzanie terminami. Każdy zbiór danych otrzymuje przy odejściu kategorię retencji z konkretną datą usunięcia. Agent monitoruje terminy i eskaluje, gdy zbliża się data usunięcia. Samo usuwanie pozostaje krokiem manualnym z zasadą czworga oczu - ale przypominanie jest systematyczne zamiast przypadkowe.

## Wartość infrastruktury: silnik onboardingu wstecz

Najsilniejszy ekonomiczny efekt tego agenta leży nie w samej automatyzacji procesu, ale w ponownym wykorzystaniu. Silnik checklist, przypisywanie zadań, monitoring terminów i logika eskalacji są identyczne z Onboarding Workflow Agent. Kto zbudował jednego, otrzymuje drugiego jako konfigurację, a nie jako projekt.

Logika deaktywacji systemów stanowi ponadto podstawę dla access-management przez wszystkie fazy cyklu życia - od transferu przez urlop rodzicielski po ponowne wejście. A wzorzec generowania świadectwa pracy jest wykorzystywany przez HR Document Management Agent dla zaświadczeń, potwierdzeń i listów referencyjnych.

Każdy przebieg offboardingu tworzy pełny audit trail: które zadanie zostało wykonane kiedy, który termin został dotrzymany lub przekroczony, kto eskalował. Ze 100 udokumentowanych przebiegów powstaje obraz tego, gdzie proces systematycznie się zacina - nie dlatego, że ktoś zamówił raport, ale dlatego, że architektura generuje te dane jako produkt uboczny.

--- Onboarding Workflow Agent ---
> Orkiestruje cały onboarding od podpisania umowy do pierwszego dnia: IT, szkolenia, buddy - zapewniając spójne doświadczenie.

Co trzeci nowy pracownik opuszcza firmę w ciągu pierwszych 90 dni. Nie z powodu pracy. Nie z powodu wynagrodzenia. A dlatego, że w pierwszym dniu brakuje laptopa, dostępy nie są skonfigurowane i nikt nie wie, kto właściwie był odpowiedzialny za szkolenie z bezpieczeństwa. Według badań Haufe ponad jedna trzecia niemieckich pracodawców notuje rezygnacje jeszcze przed pierwszym dniem pracy. Średni koszt jednego nieudanego onboardingu wynosi 15 000 euro (USD 16 400) - bez uwzględniania utraconej produktywności reszty zespołu.

Problem nie polega na braku wiedzy o tym, co należy zrobić. Problem polega na tym, że nikt nie dyryguje.

## Osiem działów, zero dyrygenta

Agent działa zgodnie z zasadą [Decision Layer](/pl/decision-layer/): każda decyzja jest oparta na regułach, wspierana przez AI lub przypisana człowiekowi.

Pojedynczy proces onboardingu angażuje co najmniej osiem jednostek organizacyjnych: HR tworzy umowę, IT provisioning sprzętu i dostępów, Administracja przygotowuje stanowisko pracy, dział merytoryczny planuje wdrożenie, Compliance zbiera obowiązkowe szkolenia, menedżer wybiera buddy'ego, Finanse konfigurują payroll, a recepcja potrzebuje nazwiska na identyfikator.

```
Podpisana umowa
    |
    +-- HR: akta osobowe, zgłoszenia, pakiet powitalny
    +-- IT: sprzęt, dostępy, e-mail, VPN
    +-- Administracja: stanowisko, klucze, parking
    +-- Dział merytoryczny: plan wdrożenia, wybór buddy'ego
    +-- Compliance: szkolenia obowiązkowe, RODO, BHP
    +-- Finanse: payroll, setup delegacji
    +-- Menedżer: zatwierdzenie buddy'ego, wyznaczenie celów
    +-- Recepcja: identyfikator, karta dostępu
    |
Pierwszy dzień pracy (wszystko musi być gotowe)
```

Każdy z tych nurtów ma własne terminy, własne systemy i własnych adresatów. Żaden z nich nie wie wiarygodnie, gdzie są pozostałe. Dział HR koordynuje to zazwyczaj przez arkusz Excel i maile przypominające - procedura działająca przy pięciu zatrudnieniach miesięcznie, ale upadająca przy pięćdziesięciu kwartalnie.

## Dlaczego checklisty się nie skalują

Checklista mówi: "Zamówić wyposażenie IT". Nie mówi, jakie wyposażenie jest potrzebne dla kierownika sprzedaży w Warszawie w porównaniu z programistką we Wrocławiu. Nie mówi, że zamówienie wymaga trzech tygodni wyprzedzenia i dlatego musi wyjść w dniu podpisania umowy - a nie wtedy, gdy HR skończy akta. Nie mówi, kto zostanie eskalowany, gdy po dziesięciu dniach nadal nie będzie laptopa.

Prawdziwa złożoność tkwi w konfiguracji: każda kombinacja stanowiska, lokalizacji, działu i typu umowy generuje inną ścieżkę onboardingu. Firma z trzema lokalizacjami, czterema działami i dziesięcioma typami stanowisk ma teoretycznie 120 różnych wariantów onboardingu. W praktyce istnieje z nich może pięć udokumentowanych - reszta jest improwizowana.

## Silnik orkiestracji steruje 14 krokami od podpisanej umowy do feedbacku po 30 dniach

Onboarding Workflow Agent to nie chatbot odpowiadający na pytania. To silnik orkiestracji, który steruje zdefiniowanym procesem od podpisania umowy do rozmowy feedbackowej po 30 dniach.

Gdy umowa zostanie podpisana, dzieją się jednocześnie trzy rzeczy: agent określa typ onboardingu na podstawie silnika reguł, tworzy pełną checklistę z odpowiedniego szablonu i rozdziela każde zadanie do odpowiedzialnej jednostki z konkretnym terminem. Od tego momentu monitoruje postęp. Nie pasywnie jak dashboard, lecz aktywnie - z przypomnieniami przy zbliżającym się terminie i eskalacją przy jego przekroczeniu.

Stojąca za tym architektura decyzyjna jest świadomie konserwatywna. Z 14 kroków decyzyjnych w procesie dziewięć to reguły, trzy są wspomagane przez AI, a dwa pozostają u człowieka. AI jest używane tylko tam, gdzie trzeba rozpoznawać wzorce - np. przy dopasowaniu buddy'ego czy personalizacji pakietu powitalnego. To, czy buddy zostanie zaakceptowany i czy onboarding zostanie uznany za udany, decyduje menedżer osobiście.

## Ukryte koszty improwizacji

Wczesna rotacja to widoczny wskaźnik. Mniej widoczny: Time-to-Productivity. Badania pokazują, że nowi pracownicy potrzebują 8 do 12 miesięcy, aby osiągnąć pełną produktywność. Przy chaotycznym onboardingu ta faza znacznie się wydłuża. Gdy ktoś w pierwszym tygodniu trzy dni czeka na dostępy, to nie trzy stracone dni - to trzy dni, w których cementuje się błędne pierwsze wrażenie.

90 procent nowych pracowników w ciągu pierwszych 100 dni decyduje, czy zostają czy odchodzą. To nie jest przypuszczenie - to kluczowa konkluzja z aktualnych badań nad onboardingiem. Decyzja nie zapada w jednym wielkim momencie, lecz w małych: Czy działa mój e-mail? Czy mój zespół wie, że przychodzę? Czy ktoś pomyślał o moim pierwszym dniu?

## Wartość infrastruktury poza onboardingiem

Silnik orkiestracji, który buduje Onboarding Agent, nie jest inwestycją jednorazową. Ta sama architektura szablonów checklist, przypisywania zadań, monitoringu terminów i logiki eskalacji jest bezpośrednio wykorzystywana przez agentów Transfer, Offboarding i Probation. Framework profilu uprawnień tworzy podstawę dla access management przez wszystkie fazy cyklu życia.

Jeszcze ważniejsze: każdy przebieg onboardingu tworzy pełny audit trail. Które zadanie zostało wykonane kiedy, kto eskalował, gdzie były opóźnienia. Z tych danych z czasem powstaje obraz tego, gdzie proces systematycznie się zacina - nie na podstawie intuicji, ale na 200 udokumentowanych przebiegach.

## Kiedy agent się opłaca

Kalkulacja jest prosta. Przy 100 zatrudnieniach rocznie i wskaźniku wczesnej rotacji 30 procent firma traci 30 pracowników w okresie próbnym. Przy 15 000 euro (USD 16 400) kosztów na przypadek to 450 000 euro (USD 492 000). Jeśli ustrukturyzowany onboarding poprawia retencję o 44 procent - konserwatywne oszacowanie oparte na danych SHRM - wczesna rotacja zmniejsza się do 17 przypadków. Oszczędność: blisko 200 000 euro (USD 219 000) rocznie.

Nie uwzględnione: wyższa produktywność 83 pracowników, którzy zostają i szybciej są zdolni do pracy. Nie uwzględnione: odciążenie działu HR, który nie musi już koordynować 100 procesów mailowym łańcuchem. Nie uwzględnione: efekt reputacyjny, gdy nowi pracownicy opowiadają o profesjonalnym onboardingu.

--- Agent księgowości płac ---
> Księgowość płac: MSSF 19 świadczenia pracownicze, KSR 6 rezerwy urlopowe, plan kont 4xx koszty osobowe, mapowanie MPK i automatyczne księgowanie listy płac dla biegłego rewidenta KIBR.

W organizacji z 2000 pracownikami i 12 cyklami płacowymi powstaje 24 000 księgowań listy płac na rok. Plan kontowy ma 200 kont, MPK 50-100 miejsc powstawania kosztów, deklaracje ZUS DRA mają 7 składowych. Ręcznie to niewykonalne, na arkuszach Excel też nie - każdy błąd mapowania trafia do kontroli KAS, biegłego rewidenta KIBR i ZUS.

Naruszenie zasady wiernego i rzetelnego obrazu z Ustawy o rachunkowości art. 4 generuje raport biegłego rewidenta KIBR z zastrzeżeniem (modified opinion) lub odmową wydania opinii (disclaimer of opinion). Naruszenie 5-letniego okresu przechowywania ksiąg z Ordynacji podatkowej art. 86 to decyzja szacunkowa US z karami 4-6 procent obrotu i odsetkami 11,5 procent rocznie z art. 53. Postępowanie karno-skarbowe z KKS art. 60-77 to do 720 stawek dziennych grzywny dla winnych. Dla spółek publicznych GPW w indeksie WIG-ESG naruszenie ESG/CSRD ESRS S1-13 Compensation to postępowanie KNF i utrata pozycji.

Kto zna te liczby i mimo to nie ma deterministycznego procesu księgowego, prowadzi kontrolowane ryzyko regulacyjne, nie księgowość.

## Z listy płac do księgowań - 80 procent automatycznie

Lista płac z modułu kadrowo-płacowego (Comarch HCM, Symfonia, enova365, SAP HCM Payroll, Workday, Personio, ADP Polska) zawiera dla każdego pracownika kompletną kalkulację - wynagrodzenie brutto, składki ZUS pracownika i pracodawcy (7 składowych: emerytalna 19,52 procent, rentowa 8 procent, chorobowa 2,45 procent, wypadkowa 0,67-3,33 procent, FP 2,45 procent, FGŚP 0,1 procent, FS 1,5 procent), zaliczkę PIT (12 procent do 120 000 PLN, 32 procent powyżej), składkę zdrowotną 9 procent, składki PPK pracownika 2 procent i pracodawcy 1,5 procent, potrącenia, wynagrodzenie netto.

Agent przekształca te dane na księgowania zgodne z polskim planem kontowym deterministycznie. Każdy składnik ma przypisane konto - wynagrodzenia zasadnicze 4040 Koszty pracy, premie regulaminowe 4041, świadczenia w naturze 4042, składki ZUS pracodawcy 4050, PPK pracodawca 4051, BHP 4052, ekwiwalenty urlopowe 4053. Strona Wn odzwierciedla koszty, strona Ma zobowiązania - Ma 2310 Rozrachunki z pracownikami, Ma 2230 Rozrachunki z ZUS, Ma 2240 Rozrachunki z budżetem PIT. Mapowanie do MPK następuje na podstawie struktury organizacyjnej (dział, projekt z kluczem procentowym, zlecenie produkcyjne). Reguły alokacji zatwierdza Kontroler Finansowy.

## Ustawa o rachunkowości jako obowiązek dokumentacyjny

Ustawa o rachunkowości z 29.09.1994 jest fundamentem księgowości płacowej. Art. 4-23 ustanawia zasady fundamentalne - wiernego i rzetelnego obrazu, ciągłości, memoriału (koszty ujmuje się w okresie powstania, niezależnie od daty zapłaty), ostrożności, istotności. Art. 13-23 reguluje księgi rachunkowe - dziennik z zasadą podwójnego zapisu (Wn = Ma), księgę główną z saldem narastającym, księgi pomocnicze.

Art. 71-78 reguluje sprawozdania finansowe i archiwizację - 5-letni okres przechowywania dla większości dokumentów, ale art. 74 ust. 2 pkt 8 wprowadza wyjątek dla list płac - 50-letni okres archiwizacji, najdłuższy w polskim porządku prawnym. Wyjątek wynika z funkcji listy płac jako dokumentu emerytalnego - ZUS może żądać dokumentacji do wymiaru świadczenia.

```
Hierarchia źródeł prawa księgowości płacowej w Polsce
─────────────────────────────────────────────────────
Konstytucja RP art. 47+51 (prywatność)
        │
        ├── Ustawa o rachunkowości z 29.09.1994
        │   ├── art. 4-23 zasady fundamentalne
        │   ├── art. 13-23 księgi rachunkowe
        │   └── art. 74 ust. 2 pkt 8 listy płac (50 lat)
        │
        ├── Ordynacja podatkowa z 29.08.1997
        │   └── art. 86 archiwizacja 5 lat + rok bieżący
        │
        ├── Krajowe Standardy Rachunkowości (Min. Fin.)
        │   ├── KSR 6 Rezerwy na świadczenia pracownicze
        │   └── KSR 15 Świadczenia po okresie zatrudnienia
        │
        ├── IFRS/IAS dla spółek MSSF
        │   ├── IAS 19 Employee Benefits (PUC)
        │   └── IFRS 2 Share-based Payment
        │
        └── Ustawa o biegłych rewidentach z 11.05.2017
            └── KIBR + PANA Polska Agencja Nadzoru
```

Brak zasady memoriału (np. nieujmowanie rezerw urlopowych) generuje zastrzeżenie biegłego rewidenta KIBR. Brak zasady wiernego i rzetelnego obrazu (zaniżenie kosztów osobowych) generuje raport z zastrzeżeniem - dla spółek publicznych GPW oznacza spadek kursu akcji i postępowanie KNF.

## Ordynacja podatkowa art. 86 i 5-letni okres przechowywania

Ordynacja podatkowa art. 86 stanowi 5-letni okres przechowywania ksiąg podatkowych oraz rok bieżący - liczony od końca roku, w którym powstał obowiązek podatkowy. Dla księgowań za 2026 rok archiwizacja jest wymagana do końca 2031. Dla samych list płac z Ust. o rachunkowości art. 74 ust. 2 pkt 8 termin to 50 lat.

Kontrola KAS może zażądać dokumentacji w tym okresie - brak ksiąg generuje decyzję szacunkową US z art. 23 Ord. Pod. z karami 4-6 procent obrotu i odsetkami 11,5 procent rocznie z art. 53. Postępowanie karno-skarbowe z KKS art. 60-77 nakłada karę grzywny do 720 stawek dziennych dla Głównej Księgowej i Dyrektora Finansowego CFO.

Agent stosuje politykę archiwizacji wielowarstwową - dla księgowań ogólnych 5 lat oraz rok bieżący, dla samych list płac 50 lat, dla deklaracji ZUS 5 lat z art. 47 Ust. SUS, a dla protokołów zarządu 10 lat z KSH art. 84. Każdy dokument otrzymuje znacznik czasu RFC 3161 z urzędu certyfikacji, hash SHA-256 i niezmienny audit-trail.

## ZUS DRA, Płatnik elektroniczny i e-ZUS PUE

Ustawa o systemie ubezpieczeń społecznych z 13.10.1998 art. 4-22 nakłada obowiązki płatnika składek - ZUS DRA (deklaracja miesięczna), RCA (raport imienny), RZA (raport zerowych składek), DRP (raport pracowników) z terminem do 15 dnia miesiąca następnego. Płatnik elektroniczny generuje deklaracje, e-ZUS PUE jest portalem dostępu.

Walidacja krzyżowa składek ZUS z księgowaniami listy płac jest fundamentalna. Agent sprawdza zgodność 7 składowych. Rozbieżność powyżej 1 PLN między księgowaniami a deklaracją Płatnik DRA generuje wyjątek do przeglądu Głównej Księgowej przed wpłaceniem składek. Naruszenie generuje sankcję ZUS z art. 23 Ust. SUS wraz z odsetkami 11,5 procent rocznie. Dla systematycznych zaniedbań sankcje się kumulują - dla firmy z 2000 pracowników milion PLN rocznie. Ustawa o sygnalistach z 14.06.2024 daje 24-miesięczną ochronę pracownikom zgłaszającym manipulacje deklaracjami ZUS.

## Cross-reference do Payroll Processing i Payroll Reporting

Trzy agenty mają różne odpowiedzialności. Payroll Processing Agent generuje samą listę płac z umów - wynagrodzenie brutto, składki ZUS, zaliczki PIT, PPK, potrącenia. Payroll Accounting Agent (ten) przekształca listę płac w księgowania - mapowanie na plan kontowy, alokacja MPK, zapisy Wn-Ma, walidacja krzyżowa z ZUS DRA i PIT-4R, rezerwy KSR 6, zobowiązania IAS 19. Profil deterministyczny - 12 z 14 mikrodecyzji to R, 1 to A, 1 to H. Payroll Reporting Agent generuje raporty zewnętrzne - deklaracje ZUS, PIT-4R/PIT-11 do US przez e-Deklaracje, PPK do PFR, GUS Z-12, ESG/CSRD ESRS S1-13.

## Na pierwszy rzut oka

- **Ustawa o rachunkowości art. 4-23, 13-23, 71-78** - fundamenty z zasadą podwójnego zapisu, 5-letnia archiwizacja ogólna, 50-letnia archiwizacja list płac z art. 74 ust. 2 pkt 8
- **Ordynacja podatkowa art. 86** - 5-letni okres przechowywania ksiąg oraz rok bieżący, sankcje karno-skarbowe z KKS art. 60-77 do 720 stawek dziennych grzywny
- **Walidacja krzyżowa z deklaracjami ZUS DRA, PIT-4R i PPK** - 7 składowych ZUS, dwa progi podatkowe PIT, składka PPK 2 procent po stronie pracownika i 1,5 procent po stronie pracodawcy, rozbieżność powyżej 1 PLN do przeglądu
- **Rezerwy KSR 6 i zobowiązania IFRS 19/IAS 19** - rezerwy urlopowe i premiowe memoriałowe, dla spółek MSSF zobowiązania emerytalne metodą PUC
- **Audit-trail dla biegłego rewidenta KIBR** - obowiązkowe badanie sprawozdań od 250 pracowników z Ust. o biegłych rewidentach z 11.05.2017
- **Profil deterministyczny** - 12 z 14 mikrodecyzji to reguły (R), 1 to AI (A), 1 to zatwierdzenie człowieka (H)
- **EU AI Act 2024/1689** - niesklasyfikowany jako wysokie ryzyko, RODO art. 22 wyklucza pełną automatyzację decyzji aktuarialnych

## Rozdział decydentów Payroll-Accounting

```
Krok                                       Decydent  Podstawa
─────────────────────────────────────────────────────────────
1. Pobranie listy płac z systemu           Reguła    API systemu kadrowego
2. Mapowanie na konta planu kontowego      Reguła    Ust. o rachunk. art. 13-23
3. Alokacja kosztów do MPK                 Reguła    Polityka rachunkowości
4. Walidacja krzyżowa ZUS DRA              Reguła    Ust. SUS art. 4-22
5. Walidacja krzyżowa PIT-4R               Reguła    Ust. PIT art. 32
6. Generowanie zapisów Wn-Ma               Reguła    Zasada podwójnego zapisu
7. Walidacja bilansowa dziennika           Reguła    Ust. o rachunk. art. 13
8. Rezerwy urlopowe                        Reguła    KSR 6 + IAS 19
9. Rezerwy premiowe                        Reguła    KSR 6 + zasada memoriału
10. Zobowiązania długoterminowe IAS 19     AI        Metoda PUC + założenia
11. Mapowanie z deklaracjami zewnętrznymi  Reguła    Ord. Pod. art. 79-82
12. Audit-trail dla KIBR i KAS             Reguła    Ord. Pod. art. 86
13. Końcowe zatwierdzenie księgowań        Człowiek  Ust. o rachunk. art. 4 ust. 5
```

12 deterministycznych reguł, 1 krok AI i 1 zatwierdzenie człowieka. Profil deterministic-rules - dominacja reguł z fundamentalnym znaczeniem zasady podwójnego zapisu i walidacji krzyżowej. AI wkracza tylko dla kalkulacji aktuarialnych IAS 19 (zobowiązania emerytalne metodą PUC z założeniami stopy dyskontowej, śmiertelności, rotacji), gdzie confidence scoring i potencjał kontestacji przez biegłego rewidenta są naturalne. RODO art. 22 wyklucza pełną automatyzację decyzji aktuarialnych - Główny Księgowy zatwierdza założenia z dokumentacją uzasadnienia.

## [Decision Layer](/pl/decision-layer/) zamienia księgowość płacową w weryfikowalny proces

Polityka rachunkowości istnieje w każdej organizacji - ale trzech księgowych w tej samej firmie księguje to samo wynagrodzenie do trzech różnych kont, bo nikt nie sprawdza polityki przed księgowaniem. Decision Layer rozkłada cykl na kroki decyzyjne. Mapowanie planu kontowego, alokacja MPK, walidacja krzyżowa ZUS i PIT, zapisy Wn-Ma, rezerwy KSR 6, audit-trail Ord. Pod. art. 86 - wszystko deterministyczne reguły. Kalkulacje aktuarialne IAS 19 podlegają AI z confidence scoring i potencjałem kontestacji przez biegłego rewidenta.

Człowiek pozostaje przy końcowym zatwierdzeniu. Główny Księgowy widzi zweryfikowany pakiet i jednym kliknięciem zatwierdza. Odpowiedzialność księgowa z Ust. o rachunkowości art. 4 ust. 5, cywilna z KSH art. 233, karno-skarbowa z KKS art. 60-77 pozostają przy człowieku. Readiness Score powyżej 90 wynika z trzech cech - wysoki wolumen, jasne reguły, niskie ryzyko regulacyjne (poza kategorią wysokiego ryzyka EU AI Act 2024/1689). KSeF jako akcelerator - od 1.07.2026 wszystkie e-faktury B2B w schemacie FA(2) XSD 1-0E, agent synchronizuje księgowania z e-fakturami powiązanymi.

--- Agent procesu HR płac ---
> Proces HR płac: aktualizacja danych pracowniczych, workflow zatrudnienia, BHP, RODO art. 88 i współdecydowanie ZZ - automatyzacja pipeline'u kadrowego bez kalkulacji brutto-netto.

W organizacji z 2000 pracownikami i 12 cyklami płacowymi powstaje 24 000 list płac rocznie. Każda kalkulacja brutto-netto przechodzi przez kilka warstw: składki ZUS, dwa progi PIT, składkę zdrowotną, PPK, walidację minimalnego wynagrodzenia, rozróżnienie wynagrodzenia chorobowego od zasiłku ZUS i hierarchię potrąceń komorniczych. Tylko 78 procent list płac jest poprawnych za pierwszym razem - 5280 wadliwych kalkulacji rocznie wymaga korekty.

Każdy z tych błędów ma cenę regulacyjną. Naruszenie zasad wynagradzania (Kodeks Pracy art. 80-94) grozi karą PIP do 30 000 zł i postępowaniem karnym z art. 218 KK. Błąd w zaliczce PIT otwiera karę skarbową z KKS art. 60 i odsetki. Brak ochrony danych szczególnych w listach płac (L4, składka związkowa) naraża na sankcję UODO do 4 procent obrotu.

Kto zna te liczby i mimo to nie ma deterministycznego procesu kalkulacji wynagrodzenia, prowadzi kontrolowane ryzyko regulacyjne, nie politykę płacową.

## Brutto-netto w sekundach zamiast arkusza kalkulacyjnego

Lista płac zaczyna się od umowy z wynagrodzeniem zasadniczym; dochodzą składniki zmienne - dodatki za nadgodziny (Kodeks Pracy art. 151[1]: 50 procent za pierwsze 8 nadgodzin tygodniowo, 100 procent za kolejne i pracę w niedziele oraz święta), dodatki nocne, dyżury, premie oraz świadczenia rzeczowe (samochód, telefon, karta sportowa) wyceniane z Ustawy o PIT art. 11.

Agent przekształca brutto na netto deterministycznie. Najpierw składki ZUS pracownika (emerytalna 9,76 procent, rentowa 1,5 procent, chorobowa 2,45 procent) z limitem 30-krotności podstawy emerytalno-rentowej. Potem składka zdrowotna 9 procent, która po Polskim Ładzie nie pomniejsza zaliczki PIT, i składki PPK. Po walidacji PIT-2 liczona jest zaliczka PIT w dwóch progach (12 procent do 120 000 PLN, 32 procent powyżej). Na końcu potrącenia komornicze (KPC art. 87+88: alimenty do 60 procent netto, długi niealimentacyjne do 50 procent). Wynik to wynagrodzenie netto wypłacane do 10 dnia miesiąca następnego (Kodeks Pracy art. 85).

## Obowiązek kalkulacji wynagrodzenia w Kodeksie Pracy

Kodeks Pracy art. 80-94 jest fundamentem obowiązku naliczenia wynagrodzenia: art. 80 to obowiązek wypłaty, art. 85 termin do 10 dnia miesiąca następnego, art. 91 odsetki za zwłokę. Art. 92 reguluje wynagrodzenie chorobowe pracodawcy - 80 procent podstawy z 12 miesięcy przez pierwsze 33 dni (14 dni dla pracowników 50+); po tym okresie finansowanie przejmuje ZUS jako zasiłek chorobowy (Ustawa o świadczeniach pieniężnych z 25.06.1999).

```
Hierarchia źródeł prawa kalkulacji wynagrodzenia w Polsce
─────────────────────────────────────────────────────────
Konstytucja RP art. 47+51 (prywatność)
        │
        ├── Kodeks Pracy art. 80-94
        │   ├── art. 85 termin wypłaty (10 dnia)
        │   ├── art. 91 odsetki za zwłokę
        │   └── art. 92 wynagrodzenie chorobowe (33/14 dni)
        │
        ├── Ustawa o PIT z 26.07.1991
        │   ├── art. 22 koszty uzyskania (250/300 PLN)
        │   ├── art. 27 skala 12/32 procent
        │   ├── art. 32 zaliczki + PIT-2 + ulga klasy
        │   ├── art. 21 ust. 1 pkt 148 ulga dla młodych
        │   └── art. 39-44 PIT-11 i PIT-4R
        │
        ├── Ust. o systemie ubezpieczeń społ. z 13.10.1998
        │   └── 9 składowych ZUS + 30-krotność limitu
        │
        ├── Ustawa zdrowotna z 27.08.2004
        │   └── art. 79+81 składka 9 procent (Polski Ład)
        │
        └── Ustawa o PPK z 4.10.2018
            └── autoenrolment 4-letni + składki 2/1,5 procent
```

Ustawa o PIT art. 22 reguluje koszty uzyskania - 250 PLN podstawowe lub 300 PLN dla dojeżdżających. Art. 27 ustala skalę 2026: 12 procent do 120 000 PLN, 32 procent powyżej oraz podatek solidarnościowy 4 procent ponad 1 mln PLN (art. 30c). Art. 32 nakłada obowiązki płatnika z miesięczną kwotą zmniejszającą 300 PLN i ulgą klasy średniej dla wynagrodzeń 5701-11 141 PLN. Ulga dla młodych (art. 21 ust. 1 pkt 148) zwalnia z PIT pracowników do 26 lat w limicie 85 528 PLN rocznie.

Brak walidacji PIT-2 daje błąd zaliczki, który KAS wykrywa w PIT-4R i może wszcząć postępowanie z KKS art. 60 - z karą grzywny i odsetkami dla Głównej Księgowej i CFO.

## Składki ZUS, PPK i minimalne wynagrodzenie

Ustawa o systemie ubezpieczeń społecznych z 13.10.1998 reguluje składki ZUS. Po stronie pracownika to emerytalna 9,76 procent, rentowa 1,5 procent i chorobowa 2,45 procent; po stronie pracodawcy m.in. emerytalna 9,76 procent, rentowa 6,5 procent oraz wypadkowa 0,67-3,33 procent zależnie od branży i wskaźnika wypadkowości. Od 1.04.2026 dochodzi PFRON 2,4 procent dla pracodawców powyżej 25 pracowników. Limitem podstawy emerytalno-rentowej jest 30-krotność przeciętnego wynagrodzenia (w 2026 około 234 720 PLN rocznie).

Ustawa o PPK z 4.10.2018 wprowadza autoenrolment co 4 lata dla pracowników 18-55 lat. Składka pracownika to 2-4 procent, pracodawcy 1,5-2,5 procent; składka pracodawcy jest zwolniona ze składek ZUS. Skarb Państwa dopłaca 250 PLN powitalnie i 240 PLN rocznie. Agent waliduje status PPK w rejestrze PFR.

Ustawa o minimalnym wynagrodzeniu z 10.10.2002 ustala 4666 PLN brutto od 1.01.2026 oraz stawkę godzinową 30,50 PLN dla umów cywilnoprawnych. Agent blokuje listę płac przy naruszeniu, bo grozi za nie kara PIP do 30 000 zł (art. 282 KP).

## Egzekucja komornicza, alimenty i ZFŚS

Potrącenia regulują Ustawa o postępowaniu egzekucyjnym w administracji oraz KPC art. 87+88. Alimenty mają pierwszeństwo i sięgają maksymalnie 60 procent netto, długi niealimentacyjne 50 procent; kwota wolna jest równa minimalnej krajowej netto (około 3500 PLN). Hierarchia idzie po datach wpływu - najpierw alimenty, potem podatki, ZUS, mandaty i długi cywilne.

Świadczenie wychowawcze 800 PLN (Ustawa o pomocy państwa w wychowaniu dzieci z 11.02.2016) może być źródłem alimentów. ZFŚS (Ustawa z 4.03.1994) wynosi 37,5 procent przeciętnego wynagrodzenia rocznie na pracownika dla zatrudniających powyżej 50 osób; świadczenia do 1000 PLN rocznie są zwolnione z PIT (art. 21 ust. 1 pkt 67). Zaniedbanie potrącenia rodzi odpowiedzialność cywilną wobec wierzyciela (KPC art. 91).

## Płatnik, e-ZUS PUE i e-Deklaracje KAS

Płatnik generuje deklaracje DRA, RCA, RZA do 15 dnia miesiąca następnego, a e-ZUS PUE jest portalem pracodawcy z certyfikatem kwalifikowanym (wgląd do deklaracji, korekty, eZLA). KAS przyjmuje e-Deklaracje: PIT-4R do 20 dnia miesiąca, PIT-11 do 28.02, PIT-8AR.

Walidacja krzyżowa składek ZUS z listą płac jest kluczowa. Rozbieżność powyżej 1 PLN między kalkulacją a deklaracją DRA generuje wyjątek do przeglądu przed wpłatą - inaczej grozi sankcja ZUS z art. 23 Ustawy o systemie ubezpieczeń społecznych wraz z odsetkami.

## Cross-reference do Payroll Accounting i Payroll Reporting

Trzy agenty mają różne odpowiedzialności. Ten agent generuje samą kalkulację brutto-netto - od umowy do paska wynagrodzenia, z profilem deterministycznym (13 z 14 mikrodecyzji to reguły). Payroll Accounting Agent bierze gotową listę płac i przekształca ją w księgowania (mapowanie kont, alokacja MPK, zapisy Wn-Ma, rezerwy). Payroll Reporting Agent generuje raporty zewnętrzne (ZUS DRA, PIT-4R i PIT-11, deklaracje PPK do PFR, GUS Z-12, ESRS S1-13).

## Na pierwszy rzut oka

- **Kodeks Pracy art. 80-94 i art. 92** - wynagrodzenie z terminem wypłaty do 10 dnia, wynagrodzenie chorobowe 33/14 dni przed zasiłkiem ZUS; sankcja PIP do 30 000 zł
- **Podatek PIT (art. 27 i 32)** - skala 12/32 procent z dodatkowym 4 procent powyżej 1 mln PLN, kwota zmniejszająca z PIT-2, ulga klasy średniej oraz ulga dla młodych do 26 lat
- **Składki ZUS** - dziewięć składowych z limitem 30-krotności podstawy emerytalno-rentowej; od 1.04.2026 PFRON 2,4 procent
- **Składka zdrowotna 9 procent** - po Polskim Ładzie nie pomniejsza zaliczki PIT (Ustawa zdrowotna z 27.08.2004)
- **PPK z autoenrolment co 4 lata** - składki podstawowe 2 procent pracownik i 1,5 procent pracodawca, dopłaty Skarbu Państwa 250 PLN i 240 PLN rocznie
- **Minimalne wynagrodzenie 4666 PLN brutto** - od 1.01.2026, stawka godzinowa 30,50 PLN dla umów cywilnoprawnych
- **Egzekucja komornicza** - alimenty do 60 procent netto z pierwszeństwem, długi niealimentacyjne do 50 procent, kwota wolna równa minimalnej krajowej (KPC art. 87+88)
- **Profil deterministyczny** - 13 z 14 mikrodecyzji to reguły, jedna to zatwierdzenie człowieka; poza zakresem wysokiego ryzyka EU AI Act

## Rozdział decydentów Payroll-Processing

```
Krok                                         Decydent  Podstawa
───────────────────────────────────────────────────────────────
1. Pobranie danych z systemu kadrowego       Reguła    API systemu
2. Walidacja krzyżowa danych wejściowych     Reguła    KP art. 149 + eZLA
3. Kalkulacja wynagrodzenia brutto           Reguła    KP art. 80-94 + 151
4. Walidacja minimalnego wynagrodzenia       Reguła    Ust. 10.10.2002
5. Składki ZUS pracownika (9 składowych)     Reguła    Ust. SUS 13.10.1998
6. Składki ZUS pracodawcy (6 + PFRON)        Reguła    Ust. SUS + PFRON
7. Składka zdrowotna 9 procent               Reguła    Ust. zdrowotna art. 79
8. Składki PPK pracownik + pracodawca        Reguła    Ust. o PPK 4.10.2018
9. Walidacja PIT-2 + ulga klasy średniej     Reguła    Ust. PIT art. 32 ust. 6
10. Zaliczka PIT (12/32 procent)             Reguła    Ust. PIT art. 27 + 32
11. Potrącenia komornicze                    Reguła    KPC art. 87+88
12. Wynagrodzenie chorobowe vs zasiłek       Reguła    KP art. 92 + Ust. 25.06.1999
13. Audit-trail dla PIP, KAS, ZUS, UODO      Reguła    RODO art. 32 + Ord. Pod. 86
14. Końcowe zatwierdzenie listy płac         Człowiek  KP art. 282 + KSH art. 233
```

Trzynaście deterministycznych reguł i jedno zatwierdzenie człowieka. Profil pozostaje regułowy, z kluczową rolą walidacji krzyżowej z deklaracjami zewnętrznymi (ZUS DRA, PIT-4R, PPK). RODO art. 22 wyklucza pełną automatyzację decyzji o istotnym skutku - Kierownik Działu Płac zatwierdza listę płac przed wypłatą, ponosząc odpowiedzialność z Kodeksu Pracy art. 282 i KSH art. 233.

--- Agent raportowania HR ---
> HR BI i dashboardy: CSRD ESRS S1-9 różnorodność, S1-10 equal-pay, S1-13 kompensacja, metryki FTE i workforce-analytics - raporty ESG dla zarządu i rady nadzorczej GPW WIG-ESG.

## Z listy płac do raportu - 90 procent automatycznie

Ten agent stosuje zasadę [Decision Layer](/pl/decision-layer/): każda decyzja jest oparta na regułach, wspomagana AI lub jawnie przypisana człowiekowi. Nie jest sklasyfikowany jako system wysokiego ryzyka w rozumieniu [EU AI Act 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) (działa na regułach, bez decyzji HR), ale podlega ścisłym obowiązkom compliance wynikającym z [Ustawy o PIT z 26.07.1991](https://isap.sejm.gov.pl/) (art. 39-44), Ordynacji podatkowej (art. 86) oraz Ustawy o rachunkowości i KSR, z obowiązkową weryfikacją biegłego rewidenta KIBR od 250 pracowników.

Typowe raportowanie płacowe przetwarza miesięcznie setki do tysięcy pozycji z list płac. Ręczne zestawienia trwają dni i są podatne na błędy. Agent generuje raporty w sekundach: deklaracje PIT i ZUS przez Płatnik oraz statystykę GUS.

Problem nie leży w wolumenie, lecz w audytowalnym śladzie zgodnym z KSR: udokumentowanym procesie, zasadzie czterech oczu Specjalisty ds. Płac i Głównego Księgowego, niezmiennym zapisie ze stanem przed i po zmianie, okresie archiwizacji oraz dostępie dla kontroli KAS i prób biegłego rewidenta KIBR.

## Deklaracje PIT przez e-Deklaracje KAS

[Ustawa o PIT z 26.07.1991](https://isap.sejm.gov.pl/) art. 39-44 określa obowiązki płatnika: PIT-11 (informacja o dochodach i pobranych zaliczkach) do końca lutego, PIT-4R (roczna deklaracja o zaliczkach) do końca stycznia oraz PIT-8AR. Dla nierezydentów dochodzą informacje IFT-1 i IFT-2. Raporty trafiają do KAS przez e-Deklaracje z podpisem kwalifikowanym.

Błąd oznacza kontrolę podatkową z decyzją szacunkową, postępowanie karno-skarbowe (KKS art. 60-77, do 5 lat pozbawienia wolności lub grzywna) oraz ryzyko opinii biegłego rewidenta z zastrzeżeniem. Ordynacja podatkowa art. 86 nakłada pięcioletni okres przechowywania ksiąg podatkowych i dokumentów.

## Deklaracje ZUS przez Płatnik i e-ZUS PUE

[Ustawa o systemie ubezpieczeń społecznych z 13.10.1998](https://isap.sejm.gov.pl/) art. 41 określa obowiązek deklaracji ZUS DRA (do 15 dnia następnego miesiąca) oraz rocznej informacji ubezpieczonego IMIR (do końca lutego). Deklaracje składa się obowiązkowo przez Płatnik lub e-ZUS PUE z podpisem kwalifikowanym.

Osobnym strumieniem jest raportowanie PPK do PFR (Ustawa o PPK z 4.10.2018) z autoenrolment co kwartał oraz raportowanie świadczenia Rodzina 800+ do MRiPS (Ustawa o pomocy państwa w wychowaniu dzieci z 11.02.2016). Delegacje transgraniczne raportuje się przez system EESSI (Ustawa o pracownikach delegowanych z 10.06.2016).

## Dane CSRD (ESRS S1-13) i raportowanie WIG-ESG

[CSRD](https://eur-lex.europa.eu/eli/dir/2022/2464/oj) (Dyrektywa UE 2022/2464) wprowadza standardy ESRS dla własnej siły roboczej: S1-9 (metryki różnorodności), S1-10 (equal pay) i S1-13 (kompensacja - mediana, średnia, kwartyle płacowe). Obowiązkowa weryfikacja audytora dotyczy pracodawców od 250 pracowników, z etapowym wejściem w życie od 2024 do 2026.

Dla spółek notowanych na GPW dochodzi roczne raportowanie ESG (indeks WIG-ESG, Code of Best Practices for WSE Listed Companies). KSH art. 84 nakłada dziesięcioletni okres przechowywania dokumentów korporacyjnych, a art. 382 - odpowiedzialność Rady Nadzorczej za nadzór.

Raportowanie do GUS (sprawozdania pracy, m.in. Z-12) wynika z Ustawy o statystyce publicznej z 29.06.1995 i obejmuje przekazanie danych przez 16 urzędów statystycznych aż do Eurostatu.

## Ochrona danych płacowych (RODO art. 88) i sygnaliści

Dane w raportach płacowych są szczególnie wrażliwe: wynagrodzenie, premie, dni chorobowe, niepełnosprawność, zajęcie komornicze czy obowiązek alimentacyjny. Część z nich to dane szczególne w rozumieniu RODO art. 9, a ich przetwarzanie w kontekście zatrudnienia doprecyzowuje RODO art. 88 oraz Ustawa o ochronie danych osobowych z 10.05.2018.

Agent stosuje privacy by design (RODO art. 25) z minimalnym zakresem danych, środki bezpieczeństwa z szyfrowaniem (art. 32), ocenę skutków DPIA (art. 35) przy obszernym przetwarzaniu danych wrażliwych oraz usuwanie po upływie okresu przechowywania (art. 17).

Ustawa o sygnalistach z 14.06.2024 ma zastosowanie przy zgłoszeniach nieprawidłowości w raportowaniu - na przykład zatajania danych wobec KAS lub zaniżania składek ZUS. Wymaga wewnętrznych kanałów od 50 pracowników, kanału zewnętrznego do RPO oraz ochrony przed retorsjami.

## Cross-reference do Payroll-Processing i Payroll-Accounting

Ten agent działa w łańcuchu wyspecjalizowanych agentów HR. [Payroll-Processing-Agent](/pl/katalog-agentow-hr/payroll-processing-agent/) dostarcza kalkulację brutto-netto, która jest wejściem dla raportowania. [Payroll-Accounting-Agent](/pl/katalog-agentow-hr/payroll-accounting-agent/) tworzy księgowania z gotowej listy płac, a [Payroll-Tax-Agent](/pl/katalog-agentow-hr/payroll-tax-agent/) sprawdza zgodność podatku dochodowego. [Compensation-Benchmarking-Agent](/pl/katalog-agentow-hr/compensation-benchmarking-agent/) dostarcza widełek wynagrodzeń, a [Merit-Cycle-Governance-Agent](/pl/katalog-agentow-hr/merit-cycle-governance-agent/) - zatwierdzonych zmian płac. [Audit-Compliance-Agent](/pl/katalog-agentow-hr/audit-compliance-agent/) weryfikuje zgodność z KSR i wymogami KIBR, a [HR-Document-Management-Agent](/pl/katalog-agentow-hr/hr-document-management-agent/) archiwizuje raporty PIT i ZUS przez 10 lat zgodnie z KSH.

## Na pierwszy rzut oka

- **Klasyfikacja**: wsparcie compliance, poza zakresem wysokiego ryzyka EU AI Act (działanie regułowe)
- **Kotwice zgodności**: Ustawa o PIT (art. 39-44), Ordynacja podatkowa (art. 86), Ustawa o systemie ubezpieczeń społecznych z 13.10.1998, RODO art. 88, KSR oraz CSRD ESRS S1-13
- **Archiwizacja**: 5 lat dla ksiąg podatkowych (Ordynacja podatkowa art. 86), 10 lat dla dokumentów korporacyjnych (KSH art. 84)
- **Współdecydowanie**: konsultacja z Radą Pracowników (Ustawa z 4.07.2006) i związkami zawodowymi obowiązkowa
- **Sankcje**: kontrola KAS, postępowanie karno-skarbowe (KKS art. 60-77, do 5 lat pozbawienia wolności), sankcje ZUS, opinia biegłego rewidenta z zastrzeżeniem oraz sankcja UODO do 4 procent obrotu
- **Obowiązek audytu**: weryfikacja biegłego rewidenta przy CSRD od 250 pracowników, kontrola KAS oraz kontrola ZUS co 4 lata
- **Powiązania**: Payroll-Processing, Payroll-Accounting oraz agenty emerytalne

### Rozdział decydentów Payroll-Reporting

| Krok | Decydent | Uzasadnienie |
|------|----------|--------------|
| Generacja PIT-11, PIT-4R i PIT-8AR | R | reguły tabel Ustawy o PIT, logika deterministyczna |
| Deklaracje ZUS (DRA, RMUA, IMIR) | R | format ZUS i Płatnik, logika deterministyczna |
| Raportowanie PPK do PFR | R | API PFR i autoenrolment, logika deterministyczna |
| Statystyka GUS (Z-12) | R | API GUS i Ustawa o statystyce publicznej, logika deterministyczna |
| Raportowanie CSRD (ESRS S1-13) | R | standardy ESRS, logika deterministyczna |
| Raportowanie GPW WIG-ESG | R | Code of Best Practices, logika deterministyczna |
| Wykrywanie anomalii | A | detekcja ML jako wskaźnik, z walidacją człowieka |
| Zatwierdzenie Głównego Księgowego | H | obowiązkowa zasada czterech oczu dla śladu KSR |
| Wysyłka do KAS, ZUS, GUS i PFR | R | podpis kwalifikowany, logika deterministyczna |
| Generacja KSeF (od 1.07.2026) | R | schemat FA(2), logika deterministyczna |
| Raportowanie Rodzina 800+ do MRiPS | R | API MRiPS, logika deterministyczna |
| Archiwizacja i usuwanie po terminie | R | Ordynacja podatkowa art. 86 i RODO art. 17, logika deterministyczna |
| Ustawa o sygnalistach 14.06.2024 | H | RPO obowiązkowe |
| RODO art. 33 72-godziny | R | UODO portal naruszeń determinista |

--- People Analytics Agent ---
> Analizuje rotację, zaangażowanie, różnorodność i ruchy talentów na wzorce i trendy. Klasyfikacja wysokiego ryzyka EU AI Act.

HR posiada dane, które mogłyby wspierać strategiczne decyzje personalne. Rotacja według działu, zaangażowanie według lokalizacji, różnorodność według szczebla hierarchii. Jednak tylko 8 procent firm raportuje, że ich dane HR są faktycznie użyteczne (Deloitte, Human Capital Trends). Reszta eksportuje tabele, buduje tygodniami prezentacje i dostarcza odpowiedzi, które przychodzą za późno, pozostają powierzchowne i mijają się z właściwym pytaniem.

Problem nie polega na braku danych. To brak architektury. Kto prowadzi People Analytics bez strukturalnego oddzielenia analizy od nadzoru, nie zyskuje ani akceptacji Rady Zakładowej, ani zgodności z EU AI Act.

## Dlaczego People Analytics w praktyce utyka

76 procent wszystkich firm prowadzi jakąś formę People Analytics. Ale tylko 9 procent rozumie, które wymiary talentu faktycznie napędzają wyniki (Deloitte, 2024). Między tym, co HR posiada jako dane, a tym, co z tego dociera do strategicznych decyzji, istnieje przepaść. Trzy przyczyny utrzymują ją otwartą.

**Rozfragmentowana baza danych.** Dane osobowe żyją w SAP lub Personio, wartości zaangażowania w narzędziu ankietowym, przyczyny rotacji w listach Excel menedżerów. Integracja danych należy według badań EY regularnie do największych przeszkód cyfryzacji HR. Ukryte szkody: niska jakość danych wymusza pracę korekcyjną, wiąże pojemności i fałszuje każdą analizę, która się na nich opiera - często poważniej niż brak narzędzi analitycznych.

**Brak tłumaczenia na język decyzji.** HR raportuje headcount, wskaźnik zachorowań, dni szkoleniowe. Zarząd myśli w kategoriach przychodu na osobę, time-to-market, utraty klientów. Dopóki rotacja nie jest powiązana z jej ekonomicznymi kosztami następczymi, People Analytics pozostaje raportem administracyjnym. Best Buy określił ten związek: 0,1 punktu więcej zaangażowania korelowało z 100 000 USD dodatkowego przychodu na sklep. Większość działów HR nie potrafi ustanowić takiego powiązania - nie dlatego, że brakuje danych, ale dlatego, że nikt nie zdefiniował, które powiązania są strategicznie istotne.

**Mieszanie analizy i nadzoru.** People Analytics ma rozpoznawać wzorce w zagregowanych danych. Ale bez jasnych granic technicznych analiza niepostrzeżenie przesuwa się w monitoring wydajności poszczególnych pracowników. Rada Zakładowa blokuje. Załoga traci zaufanie. Projekt umiera nie z powodu technologii, lecz z powodu utraty zaufania.

## Wysokie ryzyko - rzeczywistość regulacyjna (obowiązki od 2 sierpnia 2026 r.)

EU AI Act klasyfikuje systemy People Analytics jako wysokiego ryzyka według Annex III, kategoria 4(b): systemy AI do monitorowania i oceny zachowania w miejscu pracy. Nawet jeśli agent analizuje wyłącznie na zagregowanym poziomie, wyniki mogą wpływać na decyzje personalne. To wystarcza do klasyfikacji.

Zgodnie z obowiązującym prawem od 2 sierpnia 2026 r. systemy wysokiego ryzyka muszą spełniać następujące wymagania (na mocy wstępnego porozumienia Digital Omnibus z 7 maja 2026 r. termin ten ma zostać przesunięty na 2 grudnia 2027 r. - formalne przyjęcie wciąż w toku):

- System zarządzania ryzykiem z udokumentowaną oceną wpływu
- Wymagania dotyczące jakości danych i dokumentacji technicznej
- Transparentność wobec dotkniętych pracowników
- Nadzór człowieka przez osoby kompetentne merytorycznie
- Oznaczenie CE i rejestracja w bazie danych UE

Równolegle obowiązuje prawo polskie. Kodeks Pracy i ustawa o RODO wymagają konsultacji z Radą Zakładową i Inspektorem Ochrony Danych przy wprowadzaniu technicznych systemów nadzoru. Sąd Najwyższy wyjaśnił: subiektywna intencja pracodawcy jest bez znaczenia. Decyduje obiektywna przydatność systemu. Narzędzie People Analytics jest z definicji przydatne.

RODO art. 35 wymaga oceny skutków dla ochrony danych, gdy przetwarzanie prawdopodobnie niesie wysokie ryzyko dla praw osób fizycznych. Systematyczna analiza danych pracowniczych spełnia to kryterium.

Kto nie łączy tych trzech ram prawnych, buduje system, który technicznie działa, ale prawnie jest nie do utrzymania.

## Co rozwiązuje architektura, czego sama technologia nie może

Kluczowe pytanie nie brzmi: które narzędzie analizuje dane? Lecz: Kto definiuje pytanie, kto interpretuje wynik, kto decyduje?

[Decision Layer](/pl/decision-layer/) rozkłada proces analityczny na dyskretne kroki decyzyjne. Każdy krok ma zdefiniowanego odpowiedzialnego: człowieka, silnik reguł lub agenta AI.

```
Pytanie              Ochrona            Agregacja           Rozpoznanie
zdefiniować     -->  danych        -->  danych         -->  wzorców
(Człowiek)           (Reguły)           (Reguły)            (Agent)

Walidacja            Rekomendacje        Prezentacja
wyników         -->  działań       -->  wyników
(Człowiek)           (Agent)             (Agent)
```

Podział to nie formalizm. Rozwiązuje główny problem, na którym People Analytics upada w praktyce.

**Krok 1: Definicja pytania (Człowiek).** Analityka bez strategicznego pytania produkuje raporty, których nikt nie zamawiał. Proces zaczyna się dopiero, gdy kierownictwo HR lub zarząd przygotowuje konkretną decyzję: czy w sprzedaży potrzebujemy programu retencji? Czy luka zaangażowania między lokalizacjami się rozchodzi?

**Krok 2: Kontrola ochrony danych (Reguły).** Zanim zagregowany zostanie jeden punkt danych, silnik reguł sprawdza planowaną analizę względem RODO, porozumienia zakładowego i wewnętrznych wytycznych. Analizy bez podstawy prawnej nie startują.

**Krok 3: Agregacja danych (Reguły).** Dane kadrowe, wyniki zaangażowania i dane o rotacji są zestawiane i anonimizowane. Grupy poniżej zdefiniowanego minimum są łączone. To nie polityka, lecz blokada techniczna: wnioski personalne nie są możliwe, ponieważ architektura je uniemożliwia.

**Krok 4: Rozpoznanie wzorców (Agent).** Agent rozpoznaje korelacje, trendy i wartości odstające w zagregowanych danych. Gdzie rotacja rośnie szybciej niż średnia firmowa? Które obszary wykazują spadające wartości zaangażowania przy jednoczesnym wzroście nadgodzin? Modele predykcyjne identyfikują zagrożone obszary 60 do 90 dni przed pojawieniem się wypowiedzeń.

**Krok 5: Walidacja wyników (Człowiek).** Wzorzec statystyczny nie jest przyczyną. Czy spadające zadowolenie w obszarze X koreluje z restrukturyzacją z ostatniego kwartału - czy ze zmianą kierownictwa? Specjalista HR Analytics sprawdza istotność, wiarygodność i kontekst. Agent dostarcza dowodów. Interpretacji dokonuje człowiek z wiedzą domenową.

**Krok 6-7: Rekomendacje i prezentacja (Agent).** Agent formułuje rekomendacje działań oparte na dowodach z wskaźnikiem pewności i przygotowuje je w formie nadającej się dla zarządu. Nie 40 wskaźników na dashboardzie, lecz trzy do pięciu insightów powiązanych z wpływem biznesowym i konkretnymi opcjami działań.

## Granica między analizą a nadzorem to decyzja architektoniczna

Żaden problem zaufania nie zostanie rozwiązany lepszym dashboardem. Akceptacja People Analytics zależy od tego, czy granica między rozpoznawaniem wzorców w zagregowanych danych a oceną poszczególnych pracowników jest nie tylko obiecana, lecz technicznie wymuszona.

Trzy zasady architektoniczne to zapewniają:

**Agregacja jako blokada techniczna.** Minimalne rozmiary grup nie są definiowane jako polityka, lecz implementowane jako parametr systemowy. Analiza ze zbyt małą populacją nie daje wyniku - nie ostrzeżenia, tylko brak outputu.

**Brak wstecznego obliczania na jednostki.** Logika anonimizacji uniemożliwia, aby kombinacja wielu agregowanych analiz czyniła pojedyncze osoby identyfikowalnymi. To jest matematycznie i technicznie wykonalne - ale tylko jeśli jest zakotwiczone w architekturze od początku.

**Pełny protokół decyzyjny.** Każda analiza jest dokumentowana: pytanie, podstawa prawna, poziom agregacji, wynik, wyprowadzone działanie. Rada Zakładowa ma prawo wglądu. Dotknięci pracownicy mogą prześledzić, które analizy przeprowadzono i jakie decyzje na ich podstawie zapadły.

Ten framework jest jednocześnie porozumieniem zakładowym. Kto czysto dokumentuje architekturę, ma wynik negocjacji z Radą Zakładową już ustrukturyzowany. Jasne granice zwiększają akceptację i redukują ryzyka governance - to nie kompromis, lecz strategiczna przewaga.

## Infrastruktura wykraczająca poza pojedynczego agenta

Silnik analityczny, który tu powstaje - rotacja, zaangażowanie, sprawiedliwość - jest wykorzystywany przez Strategic HR Analytics Agent do raportowania dla zarządu i przez Merit Cycle Governance Agent do analiz wynagrodzeń. Logika anonimizacji i minimalnych rozmiarów grup staje się standardem dla każdego agenta przetwarzającego dane osobowe. Framework governance - które analizy są dozwolone, które nie, pod jakimi warunkami - tworzy podstawę dla wszystkich agentów wysokiego ryzyka w kwadracie H4.

Właściwa wartość nie leży w wynikach analiz jednego kwartału. Leży w infrastrukturze, która przekształca People Analytics z ryzyka governance w narzędzie governance: identyfikowalne, możliwe do zakwestionowania, powtarzalne. Organizacje osiągające ten stopień dojrzałości podejmują decyzje oparte na danych szybciej i mają według Deloitte Human Capital Trends mierzalnie wyższe prawdopodobieństwo nadprzeciętnych wyników w porównaniu z konkurencją.

--- Performance Review Documentation Agent ---
> Strukturuje proces oceny i archiwizuje wyniki z pełną ścieżką audytu. Klasyfikacja wysokiego ryzyka EU AI Act Annex III.

## Ocena rzadko jest problemem. Dokumentacja nim jest.

Agent działa zgodnie z zasadą [Decision Layer](/pl/decision-layer/): każda decyzja jest oparta na regułach, wspierana przez AI lub przypisana człowiekowi.

Menedżerowie potrafią ocenić wyniki. Nie potrafią: przekształcić roku obserwacji w spójne, udokumentowane, prawnie pewne akta. Skutkiem jest proces dokumentacji, który systematycznie produkuje sprzeczności - między oceną a uzasadnieniem, między samooceną a oceną zewnętrzną, między tym, co zostało powiedziane w rozmowie, a tym, co trafia do akt.

To nie problem jakości poszczególnych menedżerów. To problem strukturalny. I staje się ryzykiem prawnym, gdy zwolnienie, odmowa awansu lub postępowanie sądowe sięga do tych akt.

## Trzy wzorce niewidoczne w procesie manualnym

**Rozbieżność ocena-tekst.** Menedżer daje "przekroczenie oczekiwań", ale w uzasadnieniu pisze trzy akapity o potrzebie poprawy. Albo odwrotnie: "oczekiwania częściowo spełnione" z uzasadnieniem wymieniającym wyłącznie mocne strony. Badania pokazują, że ponad 60 procent wariancji w ocenach wyników pochodzi od oceniającego - nie od osoby ocenianej. W pojedynczych przypadkach rozbieżność jest zauważana. Przy 200, 500, 1000 ocenach w cyklu nie zauważa jej nikt, bo nikt nie czyta wszystkich dokumentów.

**Recency bias jako luka dokumentacyjna.** Recency bias uchodzi za najczęstszy błąd oceny w firmach. Menedżerowie nieprowadzący bieżących notatek - a większość ich nie prowadzi - rekonstruują 12 miesięcy wyników z ostatnich sześciu tygodni. Projekt, który świetnie szedł w lutym, w grudniu już nie istnieje. Błąd z listopada dominuje całą ocenę. Dokumentacja nie odwzorowuje wyników. Odwzorowuje pamięć.

**Bias oceny znikający w danych jednostkowych.** Gdy menedżer ocenia cztery kobiety w zespole jako "spełnia oczekiwania", a czterech mężczyzn jako "przekracza oczekiwania", jest to samo w sobie niezauważalne. Może nawet jest słuszne w pojedynczym przypadku. Ale gdy ten wzorzec powtarza się w 30 zespołach, to już nie przypadek. Badania HBR potwierdzają: 61 procent kobiet otrzymuje feedback na temat ich stylu komunikacji - u mężczyzn wartość wynosi jeden procent. Takich wzorców nie sposób rozpoznać manualnie, bo stają się widoczne dopiero w agregacji.

## Dlaczego lepsze formularze nie rozwiązują problemu

Naturalny odruch: bardziej ustrukturyzowane szablony, pola obowiązkowe, gotowe bloki tekstu. Ale formularz nie potrafi sprawdzić, czy uzasadnienie pasuje do oceny. Nie potrafi rozpoznać, czy samoocena pracownika systematycznie odbiega od oceny zewnętrznej. Nie potrafi stwierdzić, że menedżer od trzech cykli kopiuje te same sformułowania. I nie potrafi analizować w 40 zespołach, czy wzorce oceny różnią się według płci, wieku czy statusu zatrudnienia.

Zadanie nie polega na ulepszeniu formularza. Polega na rozłożeniu procesu oceny tak, aby każdy krok miał jasne przypisanie: Kto decyduje? Według jakiej reguły? Z jaką kontrolą?

## Jedenaście kroków, trzy zasady decyzyjne

```
Rozpoczęcie      Dystrybucja       Samoocena        Menedżer
cyklu       -->  formularzy   -->             -->  ocenia
(R: kalend.)     (R: reguły)       (R: reguły)      (H: obserw.)

Kontrola         Wsparcie         Analiza          Eskalacja
spójności   -->  kalibracji   --> biasu        --> progu
(A: oc/tekst)    (A: rozkład)      (A: statyst.)    (R: próg)

Umówienie        Archiwizacja     Działania
rozmowy     -->  wyniku       -->  następcze
(A: kalend.)     (R: archiwum)     (R: reguły)
```

Decydująca różnica w porównaniu z procesem manualnym: kroki 5, 6 i 7 działają równolegle z oceną, a nie po niej. Gdy menedżer wprowadza ocenę i uzasadnienie, jest od razu sprawdzane, czy obie pasują do siebie. Widok kalibracyjny aktualizuje się w czasie rzeczywistym. Analiza biasu na bieżąco oblicza, czy tworzą się wzorce.

To zmienia charakter rundy kalibracyjnej. Zamiast porównywać oceny po fakcie, menedżerowie przy wprowadzaniu widzą, gdzie ich ocena znajduje się w kontekście: rozkład w zespole, odchylenie od średniej działu, spójność z poprzednimi cyklami. Rozmowa przesuwa się z "Czy głosujemy nad ocenami?" na "Gdzie świadomie odchodzimy od wzorca i dlaczego?"

## Kontrola spójności jako przewaga strukturalna

Automatyczne sprawdzenie, czy ocena i uzasadnienie tekstowe pasują do siebie, to nie funkcja komfortu. To główny powód, dla którego orkiestracja oparta na regułach jest lepsza od procesu manualnego. Człowiek czytający 400 arkuszy ocen nie potrafi systematycznie rozpoznać, gdzie słowo i liczba się rozchodzą. Agent rozpoznaje sprzeczność natychmiast i ją oznacza - nie w raporcie, który trafia na biurko tygodnie później, lecz w trakcie, gdy menedżer jest jeszcze w procesie oceny i może skorygować.

Dla firm podlegających reżimowi wysokiego ryzyka EU AI Act - z obowiązkami egzekwowalnymi od 2 sierpnia 2026 r. dla systemów oceniających wyniki i zachowanie w miejscu pracy, z wstępnie uzgodnionym przesunięciem na 2 grudnia 2027 r. (Digital Omnibus, maj 2026, przyjęcie w toku) - identyfikowalność to nie opcja. To wymóg prawny. Annex III(4)(b) wymaga systemu zarządzania ryzykiem, transparentności wobec dotkniętych i nadzoru człowieka. Wymagania te nie są tu dołożone później. Są wpisane w architekturę: ocena pozostaje u człowieka. Agent dokumentuje, sprawdza i analizuje.

## Co powstaje na końcu

Agent nie podejmuje ani jednej oceny wyników. Dba o to, aby każda ocena była spójnie uzasadniona, kompletnie udokumentowana i sprawdzona pod kątem systematycznych wzorców. Ocenę przyznaje menedżer. Rozmowę prowadzi człowiek. Za kalibrację odpowiada kierownictwo HR.

Infrastruktura, która przy tym powstaje - silnik spójności, analiza biasu, framework kalibracji, archiwizacja audytowalna - nie jest budowana dla pojedynczego cyklu. Analiza biasu jest wykorzystywana przez Merit Cycle Governance Agent i Promotion Process Agent. Wzorzec kontroli spójności staje się standardem dla wszystkich agentów sprawdzających ludzkie oceny pod kątem spójności. Protokół decyzyjny powstający przy każdej ocenie sprawia, że każda pojedyncza ocena jest identyfikowalna i możliwa do zakwestionowania - przez dotkniętą osobę oraz przez Radę Zakładową.

--- Policy Document Agent ---
> Centralne zarządzanie politykami HR zgodne z KP art. 18-3a, Ustawą o sygnalistach 14.06.2024 i ESRS S1-13 - wersjonowanie, konsultacja Rady Pracowników i audit-trail dla KIBR.

Firma z 1500 pracownikami utrzymuje typowo 40-80 wewnętrznych polityk: regulamin pracy KP art. 104, regulamin wynagrodzeń KP art. 80-94, regulamin funduszu świadczeń socjalnych KP art. 27, polityka BHP KP art. 234-237, polityka antydyskryminacyjna z Ustawy z 3.12.2010, polityka sygnalistów z Ustawy z 14.06.2024, polityka monitoringu RODO art. 88, polityka delegowania Ustawa z 10.06.2016, polityka różnorodności WIG-ESG GPW. Każda musi być aktualna, zgodna z Konstytucją RP art. 32 i KP art. 11-2, znajdowalna, zrozumiała i udokumentowanie przeczytana. W praktyce co najmniej jeden z tych pięciu warunków jest prawie zawsze naruszony.

## Z 60 wersji PDF do jednej centralnej Single-Source-of-Truth

Polityki HR to regulatorny system operacyjny firmy. Sądy pracy, audytorzy KIBR, PIP, UODO i AAI mierzą firmy tym, co znajduje się w tych dokumentach - i tym, czy załoga udokumentowanie była o nich poinformowana.

System zarządzający politykami pochodzi z poprzedniej dekady. Folder SharePoint z 200 plikami, z których 40 nazywa się "final_v3_NOWY". Porozumienie z Radą Pracowników o pracy zdalnej, które wisi w pętli konsultacji między działem prawnym, Radą Pracowników i zarządem.

Rezultat: pracownicy działają według nieaktualnych regulacji. A gdy dochodzi do sporu z prescription 3 lat z KP art. 291, brakuje dowodu, że aktualna wersja została zakomunikowana. W organizacji z 60 wersjami polityk i 1500 pracownikami powstaje 90 000 pojedynczych potwierdzeń zapoznania, których nikt nie monitoruje. Kontrola PIP odkrywa, że regulamin pracy z 2019 roku nigdy nie był zaktualizowany po wejściu w życie Ustawy o sygnalistach z 14.06.2024 - sankcja do 30 000 zł z KP art. 281.

## Równe traktowanie - fundament zgodności polityk

Warstwa Kodeksu Pracy jest fundamentalna. Art. 11-2 wprowadza zasadę równego traktowania - zakaz dyskryminacji bezpośredniej i pośredniej ze względu na płeć, wiek, niepełnosprawność, rasę, religię, narodowość, przekonania polityczne, przynależność związkową, pochodzenie etniczne, wyznanie, orientację seksualną. Art. 18-3a różnicuje dyskryminację bezpośrednią od pośredniej (klauzule pozornie neutralne ale dyskryminujące). Art. 18-3c wprowadza zasadę równej płacy za pracę równej wartości. Art. 18-3d ustala odszkodowanie nie niższe niż minimalne wynagrodzenie (od 1.01.2026 około 4 666 zł brutto).

Konstytucja RP art. 32+33+65+66 stanowi fundament polityk HR ponad ustawą zwykłą - zasada równości, równość praw kobiet i mężczyzn, wolność wykonywania zawodu, prawo do bezpiecznych warunków pracy.

EU Pay Transparency Directive 2023/970 (transpozycja do 7.06.2026) wprowadza obowiązek transparentności widełek wynagrodzeń, raportowanie luki płacowej dla 100+ pracowników (od 2027), odwrócenie ciężaru dowodu w sporach o równą płacę. Polityki wynagrodzeń muszą zawierać kryteria oceny wartości pracy. Ustawa Antydyskryminacyjna z 3.12.2010 wprowadza procedury zgłaszania dyskryminacji z odwróconym ciężarem dowodu (art. 13).

Agent waliduje politykę przez AI z confidence scoring 88-93 procent na ustrukturyzowanych klauzulach i 75-85 procent na nieustrukturyzowanych - błędy poniżej threshold trafiają do przeglądu Compliance Officer i Radcy Prawnego. RODO art. 22 wyklucza pełną automatyzację.

## Konsultacja z Radą Pracowników i związkami zawodowymi

Ustawa o Radzie Pracowników z 4.07.2006 nakłada na pracodawców 50+ pracowników obowiązek informacji (art. 13) i konsultacji (art. 14) w sprawach wpływających na warunki pracy. Termin konsultacji 14-30 dni. Konsultacja jest obowiązkowa dla:

- polityk monitoringu RODO art. 88 (monitoring wizyjny art. 22 Ust. ochr. dan., kontrola e-mail art. 23, monitoring lokalizacji art. 24)
- polityk czasu pracy KP art. 128-149
- polityk BHP KP art. 234-237
- polityk delegowania Ustawa z 10.06.2016

Ustawa o związkach zawodowych z 23.05.1991 art. 30 wymaga konsultacji ze związkami zawodowymi w sprawach regulaminu pracy KP art. 104 i regulaminu wynagrodzeń. Art. 26 reguluje negocjacje zbiorowe, art. 25 określa uprawnienia związku.

Naruszenie obowiązku konsultacji generuje nieważność polityki - regulamin pracy bez konsultacji ze związkami narusza KP art. 104, polityka monitoringu bez Rady Pracowników narusza RODO art. 88. Sankcje PIP do 30 000 zł z KP art. 281, dla powtarzających się do 50 000 zł.

Agent automatyzuje routing do konsultacji - wykrywa typ polityki, planuje spotkania, dystrybuuje dokument, monitoruje terminy, agreguje feedback. Pełnomocnik ds. Pracowniczych zatwierdza ostateczny kalendarz - decyzja o priorytetyzacji w okresie negocjacji układu zbiorowego wymaga osądu człowieka.

## Polityki monitoringu pod nadzorem RODO art. 88 i UODO

RODO art. 88 dotyczy przetwarzania danych pracowniczych - krajowe doprecyzowanie z Ustawy o ochronie danych osobowych z 10.05.2018 ustala szczegółowe zasady polityki monitoringu:

- art. 22: monitoring wizyjny - oznakowanie 14 dni przed wprowadzeniem, zakaz w pomieszczeniach socjalnych, maks. 3 miesiące przechowywania
- art. 23: kontrola e-mail - konsultacja Rady Pracowników, podstawa RODO art. 6 ust. 1 lit. f lub b, zakaz korespondencji prywatnej
- art. 24: monitoring lokalizacji GPS - konsultacja Rady Pracowników, ograniczenie do godzin pracy

RODO art. 6 reguluje podstawy: lit. b dla regulaminów, lit. c dla polityk BHP, lit. f dla polityk monitoringu. Art. 9 reguluje dane szczególne - polityki BHP (stan zdrowia), polityki antymobbingowe (dane wrażliwe).

Naruszenie generuje sankcję UODO do 4 procent obrotu lub 20 milionów EUR, sankcję karną z art. 107 Ustawy z 10.05.2018 (kara grzywny lub pozbawienia wolności do 2 lat).

## Okresy przechowywania i lifecycle wersjonowania

Polityki HR podlegają specyficznym terminom przechowywania:

```
Typ dokumentu                    Termin   Podstawa prawna
─────────────────────────────────────────────────────────
Polityki HR + porozumienia       5 lat    KP art. 94 pkt 9b
Regulamin pracy                  5 lat    KP art. 94 pkt 9b
Polityki ZUS                     5 lat    Ust. SUS art. 47 ust. 3c
Polityki podatkowe               5 lat    Ord. Pod. art. 75
Polityki sygnalistów             5 lat    Ust. z 14.06.2024
Polityki korporacyjne zarządu   10 lat    KSH art. 84
Polityki Rady Nadzorczej        10 lat    KSH art. 84
Akta polityki w segmencie B/D   10 lat    KP art. 94 pkt 9a-9b
                                          (Ust. o aktach 1.10.2018)
Polityki BHP - wypadki          10 lat    Rozp. MRiPS
```

Każda polityka otrzymuje numer wersji, datę początku obowiązywania, opcjonalną datę wygaśnięcia i datę następnego przeglądu (12-24 miesiące). Dla polityk reagujących na zmiany prawa zewnętrznego - np. minimalne wynagrodzenie 1.01.2026 - automatyczna flaga generuje przegląd.

Stare wersje są archiwizowane, nie usuwane. Przy każdym zapytaniu pracownika system dostarcza wersję obowiązującą w momencie zapytania - nie najnowszą, ale miarodajną dla konkretnego przypadku z cytatem sekcji, wersji i daty obowiązywania.

Monitoring 5-letniego terminu KP art. 94 pkt 9b i 10-letniego KSH art. 84 z flagą 90 dni przed terminem zapewnia zgodność z RODO art. 5 ust. 1 lit. e. Brak monitoringu generuje przechowywanie ponad termin (sankcja UODO) lub usunięcie przed terminem (brak dowodu w sporach).

## Powiązania z agentami zarządzania dokumentami i audytu

Agent współpracuje z HR Document Management Agent przez archiwizację polityk w segmencie B (zatrudnienie) lub D (roszczenia) akt osobowych zgodnie z Rozp. MRiPS z 10.12.2018. HR Document Management Agent archiwizuje jako dokumenty kadrowe z metadanymi i kwalifikowanym podpisem QSig, Policy Document Agent zarządza tworzeniem, wersjonowaniem i konsultacją.

Współpraca z Audit Compliance Agent obejmuje raporty ESG/CSRD ESRS S1-1+S1-9+S1-13 dla audytu zewnętrznego KIBR. ESRS S1-1 dokumentuje polityki własnej siły roboczej (różnorodność, antydyskryminacja, sygnaliści). ESRS S1-9 raportuje rozkład wynagrodzeń i lukę płacową z EU Pay Transparency Directive. ESRS S1-13 raportuje świadczenia socjalne z funduszu świadczeń KP art. 27.

Audytor KIBR ma dostęp do raportów i audit-trail przez API. Naruszenie raportowania ESRS generuje modyfikację opinii audytorskiej, wykluczenie z WIG-ESG GPW i naruszenie Code of Best Practices for WSE Listed Companies.

## [Decision Layer](/pl/decision-layer/) zamienia polityki HR w weryfikowalny proces

Decision Layer rozkłada cykl życia polityki na pojedyncze kroki decyzyjne i dla każdego definiuje: człowiek, silnik reguł lub AI. Walidację zgodności z KP art. 11-2/18-3a/18-3c przejmuje AI z confidence scoring 88-93 procent. Klasyfikację typu polityki, routing do konsultacji, mapowanie metadanych, monitoring terminów przechowywania podlega silnikowi reguł. RODO art. 22 wyklucza pełną automatyzację - walidacja AI poniżej threshold trafia do Compliance Officer, decyzja o ostatecznej formie polityki przez zarząd lub Radę Nadzorczą zawsze pozostaje przy człowieku.

Człowiek pozostaje tam, gdzie decyzja jest naprawdę potrzebna: zatwierdzenie polityki przez zarząd z odpowiedzialnością KSH art. 233+299, ocena kontrowersyjnego feedbacku z konsultacji, interpretacja w nietypowym przypadku. Zarząd widzi zweryfikowany pakiet - walidacja KP, walidacja RODO, konsultacja Rady Pracowników, kwalifikowany podpis Autenti - i autoryzuje publikację.

## Na pierwszy rzut oka

- 40-80 polityk HR w typowej firmie 1500 pracowników, jeden z pięciu warunków zawsze naruszony
- Równe traktowanie (Kodeks Pracy art. 11-2/18-3a/18-3c) jako fundament zgodności polityk
- Ustawa o Radzie Pracowników 4.07.2006 art. 13+14 obowiązek konsultacji 14-30 dni
- Ustawa o związkach zawodowych 23.05.1991 art. 30 obowiązek konsultacji regulaminu pracy
- Polityki monitoringu pod RODO art. 88 i Ustawą o ochronie danych osobowych z 10.05.2018
- Ustawa o sygnalistach 14.06.2024 obowiązkowa polityka od 25.09.2024 dla 50+ pracowników
- 5-letni okres przechowywania KP art. 94 pkt 9b, 10-letni KSH art. 84 dla polityk korporacyjnych
- Raportowanie zewnętrzne CSRD (ESRS S1-1/S1-9/S1-13) i WIG-ESG weryfikowane przez KIBR
- Sankcje PIP do 30 000 zł, UODO do 4 procent obrotu, AAI do 1 procent obrotu

| Decyzja                                | Decydent | Podstawa prawna                |
| -------------------------------------- | -------- | ------------------------------ |
| Klasyfikacja typu polityki             | Reguła   | Macierz typów                  |
| Walidacja zgodności KP art. 11-2/18-3a | KI       | Tabela zgodności, EU Pay Tr.   |
| Walidacja RODO art. 88                 | Reguła   | Ust. ochr. dan. 10.05.2018     |
| Walidacja Ust. sygnalistów             | Reguła   | Checklist Ust. 14.06.2024      |
| Routing do konsultacji                 | Reguła   | Macierz konsultacji            |
| Agregacja feedbacku                    | KI       | RODO art. 22                   |
| Workflow zatwierdzania                 | Reguła   | Macierz KSH art. 382           |
| Zatwierdzenie ostateczne               | Człowiek | KSH art. 233+299               |
| Publikacja polityki                    | Reguła   | KP art. 94 pkt 2               |
| Śledzenie zapoznania                   | Reguła   | RODO art. 32                   |
| Obsługa zapytań pracowników            | KI       | RODO art. 22                   |
| Monitoring terminów                    | Reguła   | KP art. 94 pkt 9b, KSH art. 84 |
| Generowanie raportów ESG               | KI       | ESRS S1-1+S1-9+S1-13           |

## Co infrastruktura daje innym agentom

Architektura wersjonowania polityk, workflow konsultacji Rady Pracowników i workflow zatwierdzania z KSH art. 382 staje się szablonem dla agentów stosujących polityki regulacyjne. Compliance Monitoring Agent sprawdza dane w wersji obowiązującej w momencie sprawdzenia. Employee Self-Service Agent odpowiada w wersji miarodajnej dla daty pytania. Compliance Training Agent stosuje lifecycle dla daty zatrudnienia.

Decision Logging zgodne z RODO art. 30+32, KP art. 94 pkt 9b i KSH art. 84 buduje Audit Trail - kluczowe dla obrony przed kontrolą PIP, UODO, AAI oraz audytem KIBR ze standardami ESRS. Generowanie raportów ESG/CSRD jest fundamentem dla ESG Reporting Agent i Whistleblower Workflow Agent.

Policy Document Agent dowodzi przy 60 politykach i 90 000 potwierdzeń zapoznania, że audytowalny workflow z zgodnością KP art. 11-2/18-3a/18-3c, RODO art. 88, Ustawy o sygnalistach i ESRS jest możliwy.

--- Agent due diligence rekrutacji ---
> Pre-Employment Due Diligence: background checks zgodne z KP art. 18-3a, RODO art. 9, KRK, KRS, BIK i EU AI Act Annex III(4)(a) Bias-Audit - z mitygacją ryzyka Mobley v. Workday.

## Background check miedzy obowiazkami zgodnosci a pulapka KP art. 18-3d

Ten agent stosuje zasadę [Decision Layer](/pl/decision-layer/): każda decyzja jest oparta na regułach, wspomagana AI lub jawnie przypisana człowiekowi. Jest sklasyfikowany jako system wysokiego ryzyka w rozumieniu [EU AI Act 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) (Aneks III pkt 4 lit. a, rekrutacja) i od 2.8.2026 podlega zaostrzonym obowiązkom w zakresie zarządzania ryzykiem, governance danych, transparentności, nadzoru człowieka oraz audytu bias.

Typowe due diligence przetwarza na kandydata nawet kilkanaście kroków: klasyfikację CV, weryfikację świadectw i dyplomów, zapytania referencyjne, zapytanie do KRK przy stanowiskach szczególnego zaufania, zapytanie do BIK w bankach i ubezpieczeniach, weryfikację zezwolenia na pracę u kandydatów spoza UE, weryfikację tożsamości oraz konsultację z Radą Pracowników i związkami zawodowymi.

Problem nie leży w liczbie weryfikacji, lecz w pułapce zgodności z prawem pracy: każde niedopuszczalne pytanie uruchamia odwrócenie ciężaru dowodu na pracodawcę (Kodeks Pracy art. 18-3a i 18-3d) wraz z roszczeniem o odszkodowanie i sześciomiesięcznym terminem powództwa. Przy postępowaniach grupowych może to szybko sięgnąć kwot sześciocyfrowych.

## System wysokiego ryzyka EU AI Act - DPIA i FRIA

Agent podlega EU AI Act 2024/1689 (Aneks III pkt 4 lit. a, rekrutacja) jako system wysokiego ryzyka. Obowiązki od 2.8.2026 obejmują:

- **System zarządzania ryzykiem (art. 9)**: identyfikacja, analiza, ocena i mitygacja ryzyk bias (płeć, wiek, pochodzenie, niepełnosprawność)
- **Governance danych (art. 10)**: jakość danych treningowych, detekcja bias oraz testy parytetu demograficznego i równości szans
- **Obowiązki transparentności (art. 13)**: informacja o funkcjonowaniu, dokładności, odporności i wynikach audytu bias
- **Nadzór człowieka (art. 14)**: obowiązkowy człowiek w pętli przy każdej decyzji sprawdzenia
- **Obowiązki deployera (art. 26)**: DPIA, konsultacja organu nadzorczego oraz monitoring po wprowadzeniu na rynek
- **Ocena wpływu na prawa podstawowe FRIA (art. 27)**: przed wdrożeniem, w konsultacji z RPO, IOD i Radą Pracowników

Sankcje sięgają 35 mln EUR lub 7 procent globalnego obrotu. RODO art. 35 dodatkowo wymaga DPIA przy systematycznej zautomatyzowanej ocenie kandydata. [Pozew zbiorowy Mobley v. Workday](https://www.courtlistener.com/docket/67476007/mobley-v-workday-inc/) (Kalifornia, 2023) - zarzut bias AI w oprogramowaniu rekrutacyjnym wobec kandydatów po 40. roku życia - służy jako precedens.

## Odwrócenie ciężaru dowodu przy dyskryminacji

W razie sporu ciężar dowodu odwraca się zgodnie z [Kodeksem Pracy art. 18-3a i 18-3d](https://isap.sejm.gov.pl/) oraz Ustawą Antydyskryminacyjną z 3.12.2010 (art. 14): jeśli kandydat przedstawi wskaźniki dyskryminacji (anomalię statystyczną, brak uzasadnienia, niedopuszczalne pytanie), to pracodawca musi udowodnić, że dyskryminacja nie zaszła. Bez udokumentowanego, odtwarzalnego uzasadnienia każdego kroku sprawdzenia ten ciężar dowodu jest praktycznie nie do udźwignięcia.

Roszczenie odszkodowawcze (Kodeks Pracy art. 18-3d) jest nie niższe niż minimalne wynagrodzenie, a termin powództwa po odrzuceniu wynosi sześć miesięcy. Uchwały Sądu Najwyższego (III PZP 5/19, III PZP 12/15) i wyrok II PK 200/15 wzmacniają ciężar dowodu po stronie pracodawcy.

Nadzór UODO, RPO i PIP zaostrza wymogi wobec systemów AI w HR, a pozew zbiorowy Mobley v. Workday (2023) - precedens bias AI w oprogramowaniu rekrutacyjnym wobec kandydatów po 40. roku życia - kształtuje linię organów nadzorczych.

## Zapytanie do KRK tylko przy uzasadnionym interesie

Zapytanie o niekaralność do [KRK (Ustawa z 24.05.2000)](https://isap.sejm.gov.pl/) jest dopuszczalne wyłącznie przy uzasadnionym interesie - na przykład przy pracy z dziećmi (Ustawa o przeciwdziałaniu zagrożeniom przestępczością z 13.05.2016) lub na stanowiskach szczególnego zaufania (banki, ubezpieczenia, służba publiczna). Wymaga zgody kandydata, dotyczy danych szczególnych (RODO art. 9) i musi respektować zasadę domniemania niewinności (Konstytucja RP art. 42). Bezpieczny kanał zapewnia e-Zaświadczenie przez ePUAP.

Zatajanie nieprawidłowości w tym zakresie może być przedmiotem zgłoszenia sygnalisty (Ustawa o sygnalistach z 14.06.2024).

## KRS, BIK i RODO art. 22

Sprawdzenie kandydata w KRS (Ustawa o KRS z 20.08.1997) dotyczy stanowisk kierowniczych w spółkach kapitałowych, zarządach i radach nadzorczych - wiąże się z odpowiedzialnością członków zarządu z KSH art. 233 i 299.

Zapytanie do BIK jest dopuszczalne tylko przy stanowiskach szczególnego zaufania, za zgodą kandydata i z walidacją człowieka (RODO art. 22). Orzecznictwo TSUE w sprawie SCHUFA (C-26/22) potwierdza, że scoring o istotnym wpływie na kandydata podlega zakazowi decyzji wyłącznie zautomatyzowanej. Kandydat zachowuje prawo do kopii danych (RODO art. 15) oraz do zaskarżenia i manualnej weryfikacji (art. 22 ust. 3).

## Cross-reference do Candidate-Screening, Interview-Scheduling i Contract-Offer-Generation

Agent działa w łańcuchu rekrutacyjnym. [Candidate-Screening-Agent](/pl/katalog-agentow-hr/candidate-screening-agent/) dostarcza dane preselekcji jako wejście, a [Interview-Scheduling-Agent](/pl/katalog-agentow-hr/interview-scheduling-agent/) przejmuje zakwalifikowanych kandydatów do rozmowy. Po pomyślnym sprawdzeniu [Contract-Offer-Generation-Agent](/pl/katalog-agentow-hr/contract-offer-generation-agent/) generuje ofertę zatrudnienia z podpisem kwalifikowanym, a [Onboarding-Workflow-Agent](/pl/katalog-agentow-hr/onboarding-workflow-agent/) prowadzi onboarding. [HR-Document-Management-Agent](/pl/katalog-agentow-hr/hr-document-management-agent/) archiwizuje dokumenty rekrutacyjne przez 5 lat, a [Audit-Compliance-Agent](/pl/katalog-agentow-hr/audit-compliance-agent/) weryfikuje obowiązki deployera z EU AI Act i spójność DPIA.

## Na pierwszy rzut oka

- **Klasyfikacja**: system wysokiego ryzyka EU AI Act (Aneks III pkt 4 lit. a, rekrutacja) od 2.8.2026
- **Kotwice zgodności**: odwrócenie ciężaru dowodu (Kodeks Pracy art. 18-3a/18-3c/18-3d), RODO art. 9, 22 i 88, EU AI Act, KRK (Ustawa z 24.05.2000), Ustawa o cudzoziemcach z 12.12.2013
- **Konsultacje**: obowiązkowe z Radą Pracowników (Ustawa z 4.07.2006) i związkami zawodowymi
- **Archiwizacja**: 5 lat dla dokumentów rekrutacyjnych (Kodeks Pracy art. 94 pkt 9b), z usuwaniem po terminie zgodnie z RODO art. 17
- **Sankcje**: do 35 mln EUR lub 7 procent globalnego obrotu (EU AI Act), do 4 procent lub 20 mln EUR (RODO) oraz odszkodowanie z Kodeksu Pracy art. 18-3d
- **Obowiązek audytu**: DPIA, FRIA i audyt bias kwartalnie, weryfikacja biegłego rewidenta
- **Precedens**: pozew zbiorowy Mobley v. Workday (Kalifornia, 2023) o bias AI w oprogramowaniu HR

### Rozdzial decydentow Pre-Hire-Due-Diligence

| Krok | Decydent | Uzasadnienie |
|------|----------|--------------|
| Rejestracja danych kandydata | R | filtr danych wrażliwych RODO art. 9, deterministyczna |
| Klasyfikacja CV | A | OCR z wykrywaniem anomalii, z walidacją człowieka |
| Zapytanie referencyjne | R | workflow zgody i umowy powierzenia, deterministyczne |
| Zapytanie do KRK | R | Ustawa o przeciwdziałaniu zagrożeniom z 13.05.2016, deterministyczne |
| Zapytanie do BIK | R | RODO art. 6 i 22, orzecznictwo TSUE, deterministyczne |
| Weryfikacja zezwolenia na pracę | R | Ustawa o cudzoziemcach, deterministyczna |
| Weryfikacja tożsamości eIDAS | R | kwalifikowana identyfikacja elektroniczna, deterministyczna |
| Konsultacje z Radą Pracowników | R | Ustawy z 4.07.2006 i 23.05.1991, deterministyczne |
| Zgodność z EU AI Act | R | obowiązki art. 9-27 i FRIA, deterministyczne |
| Ocena sprawdzenia | H | obowiązkowa walidacja człowieka (system wysokiego ryzyka) |
| Akceptacja kandydata | H | Hiring Manager, Kodeks Pracy art. 18-3a i RODO art. 22 |
| Informacja dla kandydata (RODO) | R | obowiązki informacyjne i prawo zaskarżenia, workflow standardowy |
| Archiwizacja przez 5 lat | R | Kodeks Pracy art. 94 pkt 9b i RODO art. 17, deterministyczna |

--- Probation Management Agent ---
> Zarządzanie okresem próbnym zgodne z KP art. 25+36, konsultacją Rady Pracowników i RODO art. 22 - planowanie 30/60/75 dnia, eskalacja terminowa i 5-letni audit-trail.

W firmie z 2 000 pracownikami i 8-procentową roczną rotacją nowych zatrudnień trwa miesięcznie około 13 okresów próbnych. W skali roku to 150-200 indywidualnych terminów, rozmów feedbackowych i punktów decyzyjnych. Kontrola PIP ujawnia, że w 40 procentach przypadków brakuje udokumentowanej oceny w 75. dniu - grozi za to kara do 30 000 zł (Kodeks Pracy art. 281) oraz przegrane postępowania sądowe z odszkodowaniami nie niższymi niż wynagrodzenie za 3 miesiące.

## Monitorowanie terminów okresu próbnego jako obowiązek compliance

Agent działa zgodnie z zasadą [Decision Layer](/pl/decision-layer/): każda decyzja jest oparta na regułach, wspierana przez AI lub przypisana człowiekowi.

Okres próbny to nie miękki program poznania. To ściśle prawnie uregulowane okno decyzyjne. Art. 25 Kodeksu Pracy ustala okres próbny maksymalnie na 3 miesiące przy zatrudnianiu na czas określony powyżej 6 miesięcy lub na czas nieokreślony - 2 miesiące dla umów 6-12 miesięcy, 1 miesiąc dla umów do 6 miesięcy. Od pierwszego dnia po zakończeniu okresu próbnego obowiązuje pełen okres wypowiedzenia z KP art. 36 ust. 1.

```
Dzień 1      Dzień 30     Dzień 60     Dzień 75     Dzień 90
|------------|------------|------------|------------|
Onboarding   1. feedback  2. feedback  Decyzja      Termin
+ BHP art.   ustrukt.     ustrukt.     KP art. 36   KP art. 25
237-3                                  14 dni       3 miesiące
```

Między dniem 75 a dniem 90 leży okno, w którym musi zapaść decyzja o kontynuacji. Wypowiedzenie w dniu 85 z 2-tygodniowym terminem KP art. 36 ust. 2 pkt 3 kończy się w dniu 99, po upływie okresu próbnego - z mocy prawa zaczynają obowiązywać pełne terminy z KP art. 36 ust. 1. Każda decyzja podlega 5 warstwom: KP art. 25, KP art. 36, KP art. 11-2/18-3a/18-3c, KP art. 177, Ustawa z 14.06.2024. W praktyce co najmniej jedna jest prawie zawsze niezweryfikowana.

## Okres próbny i terminy wypowiedzenia w Kodeksie Pracy

Art. 25 KP ustala maksymalne czasy trwania okresu próbnego w zależności od typu umowy następczej - 3 miesiące dla zatrudnienia powyżej 6 miesięcy lub na czas nieokreślony, 2 miesiące dla umów 6-12 miesięcy, 1 miesiąc dla umów do 6 miesięcy. Przedłużenie maks. 1 miesiąc dopuszczalne tylko dla zadań cyklicznych. Okres próbny może być zawarty tylko jednorazowo z tym samym pracownikiem.

Art. 36 reguluje terminy wypowiedzenia zredukowane w okresie próbnym - 3 dni robocze dla okresu do 2 tygodni, 1 tydzień dla 2 tygodni-3 miesięcy, 2 tygodnie dla 3-miesięcznego okresu próbnego. Po okresie próbnym obowiązują pełne terminy z KP art. 36 ust. 1 - 2 tygodnie dla zatrudnienia poniżej 6 miesięcy, 1 miesiąc dla 6 miesięcy do 3 lat, 3 miesiące dla powyżej 3 lat.

Art. 26 reguluje umowy na czas określony - łączny okres do 33 miesięcy z maks. 3 kolejnymi umowami z tym samym pracownikiem, po 3 umowie automatyczna konwersja na czas nieokreślony.

Uchwały Sądu Najwyższego III PZP doprecyzowują orzecznictwo - III PZP 9/15 o przedłużeniu, III PZP 23/13 o terminach wypowiedzenia, III PZP 5/16 o dyskryminacji, III PZP 7/19 o ciąży.

Naruszenie art. 25 jest nieważne z mocy prawa - umowa przekształca się w czas określony lub nieokreślony. Naruszenie art. 36 uruchamia pełen okres wypowiedzenia wraz z odprawą z art. 47.

## KP art. 11-2/18-3a/18-3d zgodność podczas okresu próbnego

Art. 11-2 wprowadza zasadę równego traktowania - zakaz dyskryminacji bezpośredniej i pośredniej ze względu na cechy chronione. Art. 18-3a różnicuje dyskryminację bezpośrednią od pośredniej (klauzule pozornie neutralne ale dyskryminujące - np. wymóg dyspozycyjności weekendowej dyskryminujący kobiety z dziećmi).

Art. 18-3c wprowadza zasadę równej płacy za pracę równej wartości - kryteria oceny okresu próbnego muszą być zgodne z EU Pay Transparency Directive 2023/970 (transpozycja do 7.06.2026). Art. 18-3d ustala odszkodowanie nie niższe niż minimalne wynagrodzenie (od 1.01.2026 około 4 666 zł brutto).

Konstytucja RP art. 32+33+47+51 stanowi fundament ponad ustawą zwykłą - zasada równości, prawo do prywatności, autonomiczne informowanie o swoich danych.

KP art. 177 wprowadza dodatkową ochronę pracownic w ciąży i na urlopie macierzyńskim - zakaz wypowiedzenia również w okresie próbnym. Rozwiązanie pracodawcy w okresie ciąży skutkuje przywróceniem do pracy z pełnym wynagrodzeniem.

KP art. 22-1+22-1a+22-1b wprowadza zamknięty katalog danych pracownika - oceny mogą żądać tylko: imię, nazwisko, dane kontaktowe, wykształcenie, przebieg zatrudnienia, wyniki pracy. Żądanie danych spoza katalogu (ciąża, religia, orientacja) narusza Konstytucję RP art. 47.

Agent waliduje decyzję przez AI z confidence scoring 85-92 procent - klauzule wykluczające w komentarzach, zgodność kryteriów z EU Pay Transparency, status ochronny (ciąża, sygnalista). Poniżej threshold trafia do Compliance Officer. RODO art. 22 wyklucza pełną automatyzację.

## Ochrona danych (RODO art. 88) i konsultacja Rady Pracowników

RODO art. 88 dotyczy przetwarzania danych pracowniczych - krajowe doprecyzowanie z Ustawy z 10.05.2018. Podstawa prawna z RODO art. 6: lit. b dla oceny, lit. f dla kamieni milowych, lit. c dla archiwizacji 5 lat. Art. 9 - oceny nie mogą zawierać danych zdrowotnych, religii, orientacji, przynależności związkowej.

Ustawa o Radzie Pracowników z 4.07.2006 nakłada konsultacje przy rozwiązaniach grupowych - próg z Ustawy z 13.03.2003: 10+ pracowników w 30 dniach dla pracodawcy 20-99, 10 procent dla 100-299, 30+ dla 300+. Termin 14 dni z art. 14. Ustawa o związkach zawodowych z 23.05.1991 art. 25 wymaga konsultacji dla członków związku.

Ustawa o sygnalistach z 14.06.2024 (od 25.09.2024 dla 50+) wprowadza ochronę 24 miesiące - zakaz odwetu, odwrócony ciężar dowodu. Sankcje AAI do 1 procent obrotu, w skrajnych przypadkach kara do 3 lat z art. 56. Naruszenie konsultacji generuje nieważność rozwiązań z Ustawy z 13.03.2003 art. 4, przywrócenie do pracy, sankcje PIP do 30 000 zł.

## Okres przechowywania ocen i audytowalny ślad

Oceny okresu próbnego podlegają specyficznym terminom przechowywania:

```
Typ dokumentu                       Termin   Podstawa prawna
─────────────────────────────────────────────────────────
Oceny okresu próbnego                5 lat   KP art. 94 pkt 9b
Formularze feedbacku przełożonego    5 lat   KP art. 94 pkt 9b
Decyzje o rozwiązaniu/przedłużeniu   5 lat   KP art. 94 pkt 9b
Akta okresu próbnego segment B/D    10 lat   Ust. o aktach 1.10.2018
Dokumentacja BHP - szkolenia        10 lat   Rozp. MRiPS
```

Prescription 3 lat z KP art. 291 oznacza, że pracownik ma 3 lata na wniesienie pozwu o rozwiązanie lub o dyskryminację z KP art. 18-3a-d. Sąd pracy wymaga pełnej dokumentacji - oceny w kamieniach milowych, formularze feedbacku, walidacje KP art. 11-2/18-3a, decyzję ostateczną z kwalifikowanym podpisem Autenti.

Agent buduje audit-trail niezmienny z RODO art. 30+32 - RFC 3161 znacznik czasu, identyfikator decydenta, podstawa prawna, Decision-Type (KI/Reguła/Człowiek), confidence scoring dla decyzji AI. Niezmienność gwarantowana przez kryptograficzny hash łańcuchowy.

Naruszenie obowiązku dokumentacji (Kodeks Pracy art. 94 pkt 9b) grozi karą PIP do 30 000 zł (przy powtarzających się naruszeniach do 50 000 zł) oraz przegranym postępowaniem sądowym z odszkodowaniem za 3 miesiące.

## Powiązania z onboardingiem i ocenami okresowymi

Agent współpracuje z Onboarding Workflow Agent dla pierwszych dni - rejestracja umowy, ZUS Z-3, szkolenia BHP z KP art. 237-3. Po potwierdzeniu pracownik jest przekazywany do Performance Review Documentation Agent dla cyklu rocznych przeglądów - integracja z Compensation Benchmarking Agent dla wynagrodzeń z EU Pay Transparency Directive 2023/970.

Cross-reference do HR Document Management Agent dla archiwizacji w segmencie B/D akt osobowych z 5-letnim okresem KP art. 94 pkt 9b oraz Audit Compliance Agent dla raportowania ESG/CSRD ESRS S1-1+S1-9.

## [Decision Layer](/pl/decision-layer/) zamienia okres próbny w weryfikowalny proces

Decision Layer rozkłada cykl życia na pojedyncze kroki: obliczanie terminów z Kodeksu Pracy (art. 25 i 36) przejmuje silnik reguł, a walidację zasady równego traktowania i agregację feedbacku - AI. RODO art. 22 wyklucza pełną automatyzację, więc decyzja o potwierdzeniu, przedłużeniu lub rozwiązaniu pozostaje przy człowieku.

Manager Liniowy widzi zweryfikowany pakiet - oceny, walidacja KP art. 18-3a, walidacja KP art. 177 (ciąża), walidacja Ustawy z 14.06.2024 (sygnalista), kwalifikowany podpis Autenti - i autoryzuje decyzję z odpowiedzialnością KP art. 94 pkt 2.

## Na pierwszy rzut oka

- Okres próbny maksymalnie 3 miesiące, z przedłużeniem o 1 miesiąc dla zadań cyklicznych (Kodeks Pracy art. 25)
- KP art. 36 terminy wypowiedzenia zredukowane 3 dni-2 tygodnie w okresie próbnym
- Równe traktowanie (Kodeks Pracy art. 11-2/18-3a/18-3c) jako fundament zgodności decyzji
- KP art. 177 dodatkowa ochrona pracownic w ciąży i na urlopie macierzyńskim
- KP art. 22-1+22-1a+22-1b zamknięty katalog danych pracownika w ocenach
- Ochrona sygnalistów przez 24 miesiące z odwróconym ciężarem dowodu (Ustawa z 14.06.2024)
- Ustawa o Radzie Pracowników 4.07.2006 art. 14 konsultacja 14 dni przy rozwiązaniach grupowych
- Pięcioletni okres przechowywania ocen (Kodeks Pracy art. 94 pkt 9b) i niezmienny audytowalny ślad (RODO art. 30 i 32)
- Sankcje PIP do 30 000 zł, UODO do 4 procent obrotu, AAI do 1 procent obrotu

| Decyzja                                  | Decydent | Podstawa prawna                |
| ---------------------------------------- | -------- | ------------------------------ |
| Obliczenie terminu okresu próbnego       | Reguła   | KP art. 25                     |
| Planowanie kamieni milowych              | Reguła   | KP art. 36, harmonogram        |
| Walidacja KP art. 11-2/18-3a             | KI       | Tabela zgodności, EU Pay Tr.   |
| Walidacja RODO i KP art. 22-1            | Reguła   | RODO art. 6, 22 i 88           |
| Wysłanie zaproszeń feedback              | Reguła   | Polityka kalendarza            |
| Agregacja feedbacku                      | KI       | RODO art. 22                   |
| Eskalacja braku odpowiedzi               | Reguła   | KP art. 94 pkt 2               |
| Eskalacja krytyczna dzień 75             | Reguła   | KP art. 36 - 14 dni            |
| Walidacja KP art. 177 i sygnalistów      | Reguła   | KP art. 177, Ust. 14.06.2024   |
| Konsultacja Rady Pracowników             | Reguła   | Ust. 4.07.2006 art. 14         |
| Decyzja o potwierdzeniu/rozwiązaniu      | Człowiek | KP art. 94 pkt 2, RODO art. 22 |
| Uruchomienie działań downstream          | Reguła   | Macierz workflow               |
| Archiwizacja KP art. 94 pkt 9b           | KI       | RODO art. 32, Rozp. MRiPS      |
| Cross-reference Performance Review       | Reguła   | Lifecycle pracownika           |

## Co infrastruktura daje innym agentom

Architektura kamieni milowych z eskalacją terminową przed deadline'ami prawnymi staje się szablonem dla procesów HR z prescription. Performance Review Documentation Agent stosuje wzorzec w ocenach rocznych. Certification Tracking Agent w terminach odnowienia. Walidacja KP art. 11-2/18-3a/18-3c i KP art. 177 zasila wszystkich agentów decydujących o pracownikach.

Audytowalny ślad zgodny z RODO art. 30 i 32 oraz Kodeksem Pracy art. 94 pkt 9b stanowi podstawę obrony przed kontrolą PIP, UODO i AAI oraz audytem KIBR według standardów ESRS. Przy 150-200 trwających okresach próbnych w typowej firmie 2 000 pracowników agent dowodzi, że audytowalny proces - z terminami z Kodeksu Pracy, walidacją równego traktowania oraz ochroną z art. 177 i Ustawy o sygnalistach - jest możliwy bez utraty kontroli HR.

--- Agent procesu awansu ---
> Workflow awansowy: KP art. 18-3a/18-3c równa płaca, EU AI Act Annex III(4)(b) Bias-Audit, EU Pay Transparency 2023/970 z widełkami nowej bandy i walidacją Compa-Ratio przy skoku bandy.

## Awans jako pułapka compliance między KP art. 18-3a a EU AI Act

Ten agent stosuje zasadę [Decision Layer](/pl/decision-layer/): każda decyzja jest oparta na regułach, wspomagana AI lub jawnie przypisana człowiekowi. Jest sklasyfikowany zgodnie z [EU AI Act 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) Anneks III(4)(b) jako System Wysokiego Ryzyka od 2.8.2026.

Decyzje o awansie należą do najbardziej wrażliwych w cyklu HR. Są jednocześnie indywidualną oceną wydajności, alokacją deficytowych zasobów (etatów i budżetu), zmianą stosunku pracy wymagającą aneksu do umowy (Kodeks Pracy art. 29 i 36) oraz sygnałem dla całego zespołu. Pozew zbiorowy Mobley v. Workday (2023) dotyczy dokładnie tego: wspierane AI procesy HR systematycznie pomijały kandydatów po 40. roku życia, co stanowi dyskryminację wiekową - z polskim odpowiednikiem w Kodeksie Pracy art. 18-3a.

W polskim Mittelstand 500-5000 pracowników typowy proces wygląda tak: menedżer rekomenduje pracownika, HR sprawdza staż i ocenę, Komitet Awansowy zatwierdza, generowany aneks. Brzmi prosto - ale na każdym kroku otwierają się luki compliance, które po procesie sądowym lub kontroli PIP/UODO/RPO stają się drogie.

## System wysokiego ryzyka EU AI Act - DPIA i FRIA

Promotion-Process-Agent podlega EU AI Act 2024/1689 Anneks III Punkt 4 Litera b Systemom Wysokiego Ryzyka dla decyzji o awansie HR. Decyzje o awansie są tam jawnie wymienione obok oceny wydajności i rekomendacji wynagrodzeń. Obowiązki od 2.8.2026 obejmują:

- **System zarządzania ryzykiem (art. 9)**: identyfikacja, analiza, ocena i mitygacja ryzyk bias awansowych (płeć, wiek, pochodzenie, niepełnosprawność), ze szczególnym uwzględnieniem wieku po sprawie Mobley v. Workday
- **Governance danych (art. 10)**: jakość danych treningowych, detekcja bias oraz testy parytetu demograficznego i równości szans dla grup niedoreprezentowanych
- **Obowiązki transparentności (art. 13)**: informacja o funkcjonowaniu, dokładności, odporności i wynikach audytu bias procesu awansowego
- **Nadzór człowieka (art. 14)**: obowiązkowy człowiek w pętli przy każdej decyzji awansu - ostateczne zatwierdzenie przez HR Lead i Komitet Awansowy nigdy nie jest automatyczne
- **Obowiązki deployera (art. 26)**: DPIA, konsultacja organu nadzorczego oraz monitoring po wprowadzeniu na rynek
- **Ocena wpływu na prawa podstawowe FRIA (art. 27)**: przed wdrożeniem, w konsultacji z RPO, IOD i Radą Pracowników

Sankcje sięgają 35 mln EUR lub 7 procent globalnego obrotu. RODO art. 35 dodatkowo wymaga DPIA przy systematycznej zautomatyzowanej ocenie o znaczącym wpływie, a decyzja o awansie ma znaczący skutek prawny dla pracownika (stanowisko, odpowiedzialność, wynagrodzenie, ścieżka kariery). [Pozew zbiorowy Mobley v. Workday](https://www.courtlistener.com/docket/67476007/mobley-v-workday-inc/) (Kalifornia, 2023) - zarzut bias AI w oprogramowaniu HR wobec kandydatów po 40. roku życia - jest precedensem kształtującym linię organów nadzorczych UE.

## Odwrócenie ciężaru dowodu przy dyskryminacji awansowej

Polski porządek prawny opiera się na Konstytucji RP (zasada równości i równość kobiet i mężczyzn, art. 32 i 33). Kodeks Pracy art. 11-2 ustanawia zasadę równego traktowania, art. 18-3a zakazuje dyskryminacji bezpośredniej i pośredniej ze względu na cechy chronione (także przy awansie i dostępie do szkoleń), art. 18-3c gwarantuje równą płacę za pracę równej wartości (również w nowej bandzie po awansie), a art. 18-3d - prawo do odszkodowania nie niższego niż minimalne wynagrodzenie.

Kluczowe jest to, że przy zarzucie dyskryminacji awansowej ciężar dowodu odwraca się (Kodeks Pracy art. 18-3d, Ustawa Antydyskryminacyjna z 3.12.2010 art. 14). Jeśli pracownik przedstawi wskaźniki dyskryminacji (anomalię statystyczną, brak uzasadnienia odmowy, podejrzany moment decyzji), to pracodawca musi udowodnić, że dyskryminacja nie zaszła. Bez udokumentowanego, odtwarzalnego uzasadnienia każdej rekomendacji i każdej odmowy awansu ten ciężar dowodu jest praktycznie nie do udźwignięcia.

Uchwały Sądu Najwyższego (III PZP 5/19, III PZP 12/15) wzmacniają zasadę równego traktowania w wynagrodzeniu po awansie, a wyrok II PK 200/15 potwierdza ciężar dowodu po stronie pracodawcy.

## Praca równej wartości i transparentność wynagrodzeń

Trybunał Sprawiedliwości UE w wyroku C-624/19 (Tesco Stores, 2021) ustalił, że "pracę o równej wartości" ocenia się całościowo w grupie porównawczej - co dotyczy bezpośrednio nowej bandy po awansie. Jeśli pracownik awansowany na stanowisko otrzyma niższe wynagrodzenie niż nowo zatrudniony z zewnątrz o porównywalnej wydajności, pracodawca musi obronić różnicę, inaczej grozi roszczenie z Kodeksu Pracy art. 18-3c.

Od 7 czerwca 2026 [dyrektywa o transparentności wynagrodzeń 2023/970](https://eur-lex.europa.eu/eli/dir/2023/970/oj) wymaga dokumentowania podstaw każdej zmiany płacy, także po awansie. Niewyjaśniona luka płacowa powyżej 5 procent uruchamia wspólną ocenę wynagrodzeń i sześciomiesięczny obowiązek naprawy. Pracownik zyskuje prawo dostępu do mediany wynagrodzenia grupy porównawczej, widełki w ogłoszeniach (także wewnętrznych o awansie) są obowiązkowe, a pytanie o historię wynagrodzenia - zakazane.

Ciężar dowodu w sporach o dyskryminację płacową po awansie również się odwraca. Obowiązki raportowania luki płacowej obejmują pracodawców od 250 pracowników (od 2027), z rozszerzeniem do 100 pracowników (od 2031).

## Konsultacja z Radą Pracowników i związkami zawodowymi

Wprowadzenie systemu IT z audytem bias dla awansów wymaga konsultacji z Radą Pracowników (Ustawa z 4.07.2006) i związkami zawodowymi (Ustawa z 23.05.1991 art. 25). Chodzi o porozumienie zakładowe obejmujące kryteria uprawnień, macierz zatwierdzania, próg eskalacji luki awansowej, udział w DPIA i FRIA, dostęp do śladu audytowego oraz procedurę odwołania od odmowy awansu. Naruszenia grożą nakazem PIP, postępowaniem przed sądem pracy i karą do 30 000 PLN.

Ryzyka sankcji kumulują się. Roszczenie odszkodowawcze (Kodeks Pracy art. 18-3d) jest nie niższe niż minimalne wynagrodzenie pomnożone przez liczbę miesięcy, a przy postępowaniach grupowych (np. wszyscy pracownicy po 40. roku życia, którym odmówiono awansu) może sięgnąć kwot siedmiocyfrowych. Do tego dochodzą sankcje EU AI Act (do 35 mln EUR lub 7 procent obrotu), RODO (do 4 procent obrotu) oraz - przy naruszeniu raportowania CSRD - opinia audytora z zastrzeżeniem i odpowiedzialność Rady Nadzorczej (KSH art. 382).

## Cross-reference do Merit-Cycle-Governance, Compensation-Benchmarking i Performance-Review

Promotion-Process-Agent jest osadzony w pipeline wyspecjalizowanych agentów HR z jasnym podziałem odpowiedzialności. [Merit-Cycle-Governance-Agent](/pl/katalog-agentow-hr/merit-cycle-governance-agent/) zarządza rocznym cyklem wynagrodzeń bez zmiany bandy - Promotion-Process zarządza decyzjami o skoku bandy. Oba reużywają Equity Analysis Engine i wspólny audit-trail engine. [Compensation-Benchmarking-Agent](/pl/katalog-agentow-hr/compensation-benchmarking-agent/) dostarcza widełki wynagrodzeniowe docelowej bandy, Compa-Ratios i dane widełek płacowych dla walidacji skoku bandy. [Performance-Review-Documentation-Agent](/pl/katalog-agentow-hr/performance-review-documentation-agent/) dostarcza oceny wydajności ostatnich 2 cykli jako warunek wstępny uprawnień awansu - kluczowa różnica vs. Merit-Cycle, który wymaga tylko 1 cyklu.

[Payroll-Calculation-Agent](/pl/katalog-agentow-hr/payroll-calculation-agent/) odbiera zatwierdzone awanse z prawidłową datą efektywności i zmianami w PIT, ZUS i PPK. [Payroll-Reporting-Agent](/pl/katalog-agentow-hr/payroll-reporting-agent/) generuje dane CSRD o awansach (ESRS S1-13). [HR-Document-Management-Agent](/pl/katalog-agentow-hr/hr-document-management-agent/) archiwizuje uzasadnienia awansów i odmów przez 5 lat (Kodeks Pracy art. 94) wraz z aneksami do umów. [Audit-Compliance-Agent](/pl/katalog-agentow-hr/audit-compliance-agent/) weryfikuje obowiązki deployera z EU AI Act oraz spójność DPIA i FRIA, a Contract-Offer-Generation-Agent reużywa workflow generowania aneksów.

## Na pierwszy rzut oka

- **Klasyfikacja**: system wysokiego ryzyka EU AI Act (Aneks III pkt 4 lit. b, decyzje o awansie) od 2.8.2026
- **Kotwice zgodności**: równe traktowanie i równa płaca (Kodeks Pracy art. 11-2/18-3a-d), Konstytucja RP art. 32 i 33, transparentność wynagrodzeń (dyrektywa 2023/970), RODO art. 22, 35 i 88 oraz CSRD ESRS S1-13
- **Konsultacje**: obowiązkowe z Radą Pracowników (Ustawa z 4.07.2006) i związkami zawodowymi
- **Próg equity**: niewyjaśniona luka awansowa powyżej 5 procent uruchamia wspólną ocenę wynagrodzeń i sześciomiesięczny obowiązek naprawy (dyrektywa 2023/970)
- **Kary**: do 35 mln EUR lub 7 procent globalnego obrotu (EU AI Act), do 4 procent lub 20 mln EUR (RODO), odszkodowanie z Kodeksu Pracy art. 18-3d oraz kary PIP do 30 000 PLN
- **Obowiązek audytu**: DPIA, FRIA i audyt bias kwartalnie (ze szczególnym uwzględnieniem wieku po sprawie Mobley v. Workday) oraz weryfikacja audytora CSRD od 250 pracowników
- **Precedens**: pozew zbiorowy Mobley v. Workday (Kalifornia, 2023) o bias AI w oprogramowaniu HR wobec kandydatów po 40. roku życia
- **Powiązania**: Merit-Cycle-Governance-Agent jako komplementarny dla rocznego cyklu wynagrodzeń bez zmiany bandy

### Rozdział decydentów Promotion-Process

| Krok | Decydent | Uzasadnienie |
|------|----------|--------------|
| Inicjacja rekomendacji menedżera | H | indywidualna ocena menedżera z dokumentacją uzasadnienia |
| Sprawdzenie uprawnień awansu | R | staż, dwa cykle wydajności i brak postępowań, deterministyczne |
| Walidacja stanowiska docelowego | R | plan etatów, organigram i dostępność etatu, deterministyczne |
| Skok bandy i Compa-Ratio | R | obliczenie deterministyczne dla nowej bandy |
| Zgodność z budżetem awansów | R | śledzenie w czasie rzeczywistym, deterministyczne |
| Analiza equity | A | statystyczna detekcja luki awansowej, z walidacją człowieka |
| Eskalacja luki awansowej | R | próg powyżej 5 procent (dyrektywa 2023/970) |
| Workflow zatwierdzania | R | macierz wg hierarchii i skoku wynagrodzenia |
| Konsultacje Rady Pracowników | R | art. 13-14 i porozumienie zakładowe, deterministyczne |
| Zatwierdzenie HR Lead i Komitetu | H | ostateczne zatwierdzenie zgodne z Kodeksem Pracy |
| Generowanie aneksu | R | szablony Kodeksu Pracy art. 29 i 36, deterministyczne |
| Informacja dla pracownika (RODO) | R | obowiązki informacyjne i prawo zaskarżenia, workflow standardowy |
| Rozmowa awansowa | H | osobista rozmowa o wymiarze relacyjnym i rozwojowym |
| Aktualizacja systemów i CSRD | R | data efektywności i raport ESRS S1-13, deterministyczne |

--- Sick Leave Processing Agent ---
> Przetwarzanie e-ZLA zgodne z KP art. 92, Ustawą o świadczeniach 25.06.1999 i RODO art. 9 - ekstrakcja z PUE ZUS, wyliczenie 33-dniowego wynagrodzenia i raportowanie Z-3a+Z-15.

Każdego ranka w systemie pojawiają się nowe e-ZLA. W poniedziałki po fali grypy bywają ich dziesiątki. Każde pojedyncze zwolnienie uruchamia kaskadę: pobranie z PUE ZUS przez Web Service Płatnik, klasyfikacja typu niezdolności, dopasowanie do pracownika, sprawdzenie historii ostatnich 12 miesięcy dla limitu KP art. 92 (33 / 14 dni), wyliczenie podstawy wymiaru, raportowanie do ZUS przez Z-3a, korekta payroll, powiadomienie przełożonego bez diagnozy. Przy przypadkach długoterminowych: monitoring progu 182 / 270 dni z eskalacją do orzecznictwa ZUS.

Przeciętnie 14-18 dni chorobowych na pracownika rocznie w Polsce. W organizacji z 2 000 pracowników oznacza to 28 000 do 36 000 dni chorobowych rocznie - każdy z nich akt administracyjny z ustawowymi terminami. Same koszty wynagrodzenia chorobowego od pracodawcy z KP art. 92 (33 dni, potem zasiłek ZUS) stanowią ogromne obciążenie budżetowe. Problem nie tkwi w złożoności pojedynczego e-ZLA - tkwi w wolumenie przy zerowej tolerancji na błąd KP art. 92 lub Ustawy z 25.06.1999.

## Zwolnienie chorobowe w 60 sekund zamiast trzech tygodni opóźnienia

Agent działa zgodnie z zasadą [Decision Layer](/pl/decision-layer/): każda decyzja jest oparta na regułach, wspierana przez AI lub przypisana człowiekowi. Standardowy cykl od wystawienia e-ZLA przez lekarza w PUE ZUS do automatycznej aktualizacji payroll wynosi 2-4 godziny - eliminuje opóźnienia 3-7 dni typowe dla obsługi ręcznej z papierowym L4.

Wyliczenie okresu wynagrodzenia chorobowego z KP art. 92 brzmi prosto: 33 dni od pracodawcy (14 dni dla 50+), potem zasiłek ZUS. W praktyce jedno z najczęstszych źródeł błędów - sumowanie nieobecności w ciągu roku, ciągłość versus kontynuacja niezdolności, wyliczenie podstawy wymiaru z 12 miesięcy z uwzględnieniem składników stałych, zmiennych i specjalnych.

## Wynagrodzenie chorobowe z art. 92: 33 dni, a po 50. roku życia 14

Kodeks Pracy art. 92 reguluje wynagrodzenie chorobowe od pracodawcy: 33 dni dla pracowników do 50. roku życia w roku kalendarzowym (limit roczny niezależny od liczby zwolnień), 14 dni dla 50+ ukończonych przed 1 stycznia danego roku - 80 procent wynagrodzenia w przypadku zwykłej choroby (ust. 1 pkt 1), 100 procent przy chorobie w ciąży, w drodze do/z pracy, badania kandydata na krwiodawcę, choroby zawodowej lub wypadku przy pracy (ust. 1 pkt 2).

Sumowanie nieobecności jest źródłem najczęstszych błędów. Gdy pracownik choruje wielokrotnie w roku, dni kumulują się do limitu rocznego. Ręczne śledzenie zawodzi - rezultat: pracodawca płaci ponad limit (sankcja PIP do 30 000 zł z KP art. 281) lub przechodzi na zasiłek ZUS zbyt wcześnie (odszkodowanie pracownika z prescription 3 lat z KP art. 291).

Ciągłość i kontynuacja niezdolności decyduje o limicie. Gdy wpływa e-ZLA, trzeba natychmiast ustalić: nowa niezdolność, czy przedłużenie istniejącej? Od tego zależy, czy 33-dniowy limit biegnie dalej, czy od nowa.

Podstawa wymiaru z 12 miesięcy poprzedzających niezdolność, z uwzględnieniem składników stałych (zasadnicze wynagrodzenie, dodatki za staż), zmiennych (premie kwartalne i roczne, prowizje), specjalnych (dodatki zmianowe, dodatki za nadgodziny) - algorytm o wielu zmiennych. Ręczna kalkulacja przy złożonych strukturach wynagrodzenia jest podatna na błędy przy każdym drugim przypadku.

## Po wyczerpaniu limitu pracodawcy wchodzi zasiłek chorobowy ZUS

Po wyczerpaniu limitu KP art. 92 pracownik otrzymuje zasiłek chorobowy ZUS z Ustawy o świadczeniach pieniężnych z 25.06.1999. Maksymalny okres 182 dni (270 dni dla gruźlicy lub w okresie ciąży), 80 procent podstawy wymiaru, 100 procent przy chorobie zawodowej.

Agent automatyzuje cały proces przejścia:

```
e-ZLA z PUE ZUS
    |
    +-- Limit KP art. 92 wyczerpany?
    |       |
    |       NIE: wynagrodzenie chorobowe od pracodawcy 80 / 100 procent
    |       |
    |       TAK: routing do zasiłku ZUS
    |
    +-- Generowanie ZUS Z-3a (podstawa wymiaru z 12 miesięcy)
    |
    +-- Wysyłka przez Płatnik elektroniczny lub Web Service Płatnik
    |
    +-- Monitoring 30-dniowego terminu wypłaty z Ustawy z 25.06.1999 art. 64
    |
    +-- Powiadomienie pracownika
```

Po 90 dniach automatyczna flaga do kontroli lekarskiej, po 180 dniach raportowanie ZUS Z-7 (świadczenie rehabilitacyjne lub renta z Ustawy z 17.12.1998), po 182 / 270 dniach eskalacja do orzecznictwa ZUS.

Agent rozpoznaje próg niezawodnie nawet gdy dni składają się z kilku krótszych nieobecności rozłożonych na miesiące - analiza wzorców czasowych przez AI z confidence scoring 90-95 procent BEZ analizy kodów ICD-10. Decyzję o świadczeniu rehabilitacyjnym, rencie lub KP art. 53 agent NIE podejmuje - to rozmowy między ludźmi, dla których architektura zachowuje pełną kontrolę człowieka.

## e-ZLA z PUE ZUS: papierowy L4 zniknął, integracja jest standardem

Od 1.12.2018 (Ustawa z 10.05.2018) wszystkie zwolnienia są wystawiane elektronicznie - papierowy L4 wyeliminowany. Lekarz wystawia e-ZLA w PUE ZUS (Platforma Usług Elektronicznych), zwolnienie automatycznie trafia do bazy ZUS i jest dostępne dla pracodawcy przez Web Service Płatnik.

Standardowa integracja dla polskich ERP (Comarch ERP HR, Symfonia, enova365, WAPRO, Asseco SoftBank, HRappka, inEwi, tomHR) i multinacjonalnych (SAP HCM, Workday, Oracle, Personio, BambooHR, ADP). Cykliczne pobieranie co 1-2 godzin, automatyczna walidacja kompletności (PESEL, NIP pracodawcy, daty, kod tytułu, uprawnienia lekarza), powiązanie z rekordem na podstawie PESEL hash.

Generowanie ZUS Z-3a (podstawa wymiaru zasiłku), ZUS Z-15A (zasiłek opiekuńczy nad dzieckiem do 8 lat, 60 / 14 dni rocznie), ZUS Z-15B (zasiłek opiekuńczy nad chorym członkiem rodziny, 14 dni rocznie) jest deterministyczne. Monitoring 30-dniowego terminu wypłaty z art. 64 Ustawy z 25.06.1999.

## Ochrona danych zdrowotnych: dane zwolnień to kategoria szczególna

Dane zwolnień stanowią szczególne kategorie danych zdrowotnych z RODO art. 9 - przetwarzanie wymaga podstawy z art. 9 ust. 2 lit. b (obowiązki z prawa pracy z KP art. 92 i Ustawy z 25.06.1999) i wzmocnionych środków z RODO art. 32. Konstytucja RP art. 47 (prywatność) i art. 51 (autonomia informacyjna) wprowadzają fundamentalną ochronę. KP art. 22-1+22-1a (zamknięty katalog danych pracownika) ogranicza przetwarzanie do zakresu koniecznego.

Agent egzekwuje ochronę przez wielowarstwową architekturę:

- zasada minimalizacji - tylko daty niezdolności i kod tytułu (ciąża, choroba zawodowa, opieka), bez kodu ICD-10
- szyfrowanie at-rest AES-256-GCM z oddzielnymi kluczami HSM dla danych zdrowotnych
- dostępy RBAC ograniczone do Specjalisty ds. Wynagrodzeń, Inspektora Ochrony Danych, Lekarza Medycyny Pracy
- audit-trail RODO art. 32 z RFC 3161 znacznikiem czasu dla każdego dostępu
- powiadomienie przełożonego BEZ diagnozy - tylko fakty operacyjne
- pseudonimizacja PESEL hash dla integracji z PUE ZUS

Polityka monitoringu wymaga konsultacji Rady Pracowników z Ustawy z 4.07.2006 art. 14 (14-30 dni, 50+ pracowników) i RODO art. 88 z Ustawy z 10.05.2018.

Naruszenie generuje sankcję UODO do 4 procent obrotu lub 20 milionów EUR z RODO art. 9, w skrajnych przypadkach karę karną z art. 107 Ustawy z 10.05.2018 (do 2 lat pozbawienia wolności). Sygnaliści zgłaszający nieuprawnione ujawnienie diagnozy otrzymują 24-miesięczną ochronę z Ustawy z 14.06.2024.

## Współpraca z agentami płac, urlopów i archiwizacji dokumentów

Agent współpracuje z Payroll-Processing-Agent przez automatyczne przekazanie danych do rozliczenia miesięcznego - wynagrodzenie chorobowe z KP art. 92, zasiłek ZUS z Ustawy z 25.06.1999, zasiłek opiekuńczy ZUS Z-15A / Z-15B; spójność z PIT-11 i ZUS RCA / RZA / RSA.

Z Leave-of-Absence-Agent koordynuje nakładanie chorobowego z urlopami - urlop wypoczynkowy nie biegnie podczas choroby z KP art. 165, urlop rodzicielski może być przerwany chorobą dziecka. Agent flaguje konflikty.

Cross-reference do HR-Document-Management-Agent dla archiwizacji e-ZLA i ZUS Z-3a / Z-15A / Z-15B w segmencie B/D akt osobowych z Rozp. MRiPS z 10.12.2018, 5-letni okres z KP art. 94 pkt 9b. HR-Document-Management-Agent archiwizuje z kwalifikowanym podpisem QSig.

## Na pierwszy rzut oka

- 28 000 do 36 000 dni chorobowych rocznie w firmie 2 000 pracowników, zerowa tolerancja błędu KP art. 92
- e-ZLA elektroniczne zwolnienie obligatoryjne od 1.12.2018 z Ustawy z 10.05.2018, papierowy L4 wyeliminowany
- KP art. 92: 33 dni dla pracowników do 50. roku życia, 14 dni dla 50+, 80 / 100 procent wynagrodzenia
- Ustawa o świadczeniach pieniężnych z 25.06.1999: zasiłek chorobowy ZUS po wyczerpaniu limitu pracodawcy
- Próg długoterminowy 182 dni / 270 dni dla gruźlicy lub ciąży, eskalacja do orzecznictwa ZUS
- ZUS Z-3a / Z-15A / Z-15B przez Płatnik elektroniczny, monitoring 30-dniowego terminu z art. 64
- RODO art. 9 dane zdrowotne kategorii szczególnej, BEZ kodu choroby ICD-10 dla pracodawcy
- Konstytucja RP art. 47+51 prawo do prywatności i autonomia informacyjna
- Sankcje PIP do 30 000 zł, UODO do 4 procent obrotu, AAI sygnalistów do 1 procent obrotu

| Decyzja                                | Decydent | Podstawa prawna                |
| -------------------------------------- | -------- | ------------------------------ |
| Pobranie e-ZLA z PUE ZUS               | Reguła   | Web Service Płatnik            |
| Klasyfikacja typu zwolnienia           | Reguła   | KP art. 92 + Ustawa 25.06.1999 |
| Walidacja zgodności z KP art. 92       | Reguła   | Tabela zgodności PUE ZUS       |
| Dopasowanie do pracownika              | Reguła   | KP art. 22-1+22-1a             |
| Wyliczenie limitu KP art. 92           | Reguła   | KP art. 92 + 12 miesięcy       |
| Routing do zasiłku ZUS                 | KI       | RODO art. 22 + Ustawa 25.06.99 |
| Wykrywanie progu 182 / 270 dni         | KI       | RODO art. 22 + Ust. 17.12.1998 |
| Powiadomienie przełożonego bez diagnozy| Reguła   | RODO art. 9 + KP art. 22-1     |
| Walidacja RODO art. 9                  | Reguła   | RODO art. 32 + Ust. 10.05.2018 |
| Aktualizacja payroll                   | KI       | RODO art. 22                   |
| Generowanie ZUS Z-3a / Z-15A / Z-15B   | Reguła   | Płatnik elektroniczny          |
| Monitoring KP art. 41 ochrona          | Reguła   | KP art. 41+45+53               |
| Cross-reference do Payroll-Processing  | Reguła   | Standaryzowane API             |
| Archiwizacja w segmencie B/D           | Reguła   | KP art. 94 pkt 9b              |

## Co infrastruktura daje innym agentom

Architektura ochrony danych zdrowotnych z RODO art. 9 (minimalizacja bez ICD-10, AES-256-GCM, RBAC), integracji z PUE ZUS przez Web Service Płatnik i monitoringu progów regulacyjnych staje się szablonem dla Occupational Health Agent (medycyna pracy), Disability Accommodation Agent (niepełnosprawności), Workplace Injury Agent (wypadki z KP art. 234-237).

Decision Logging zgodne z RODO art. 30+32, KP art. 94 pkt 9b i Ustawą z 25.06.1999 buduje Audit Trail dla obrony przed kontrolą PIP, UODO, ZUS, KAS, AAI i audytem KIBR. Generowanie ZUS Z-3a przez Płatnik elektroniczny jest fundamentem dla Pension-Reporting-Agent i Maternity-Leave-Agent.

Sick-Leave-Processing-Agent dowodzi przy 36 000 dniach chorobowych i zerowej tolerancji błędu KP art. 92, że audytowalny workflow z zgodnością Ustawy z 25.06.1999, RODO art. 9, KP art. 41 i Konstytucji RP art. 47+51 jest możliwy.

--- Agent profilu kompetencji ---
> Profil kompetencji i skills-matching: KP art. 18-3a, EU AI Act Annex III(4)(b) Bias-Audit, RODO art. 22, ZSK Zintegrowany System Kwalifikacji, ESCO i EQR z mitygacją Mobley v. Workday.

## Skills-matching jako pułapka compliance między KP art. 18-3a a EU AI Act

Ten agent stosuje zasadę [Decision Layer](/pl/decision-layer/): każda decyzja jest oparta na regułach, wspomagana AI lub jawnie przypisana człowiekowi. Jest sklasyfikowany zgodnie z [EU AI Act 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) Anneks III(4)(b) jako System Wysokiego Ryzyka task-assignment-personal-traits od 2.8.2026.

Skills-matching i klasyfikacja talentów należą do najbardziej wrażliwych systemów AI w cyklu HR. Workday Skills Cloud, SAP SuccessFactors Skills, Eightfold AI, Pymetrics, Cornerstone Skills Graph i Microsoft Viva Skills budują profile oparte na wektorach embeddingowych ML, które rankują pracowników. Mobley v. Workday Northern District California 2023 klasyfikacja klasy action dotyczy dokładnie tego: AI-wspierane procesy HR systematycznie pomijały kandydatów 40+, co stanowi dyskryminację wiekową ADEA - z polskim odpowiednikiem KP art. 18-3a.

W polskim Mittelstand 500-5000 pracowników typowy proces wygląda prosto: pracownik wypełnia samoocenę, algorytm ML dopasowuje profil do ról, a system rekomenduje szkolenia. Problem w tym, że bez walidacji wobec taksonomii ZSK, ESCO i EQR klasyfikacja jest niespójna i trudna do obrony.

## System wysokiego ryzyka w rozumieniu EU AI Act

Agent podlega EU AI Act jako system wysokiego ryzyka (Aneks III(4)(b), task-assignment-personal-traits). Klasyfikacja kompetencji jest formą przydzielania zadań na podstawie analizy cech osobistych - ranking talentów decyduje o dostępie do projektów strategicznych, programów rozwoju, ścieżek kariery i szkoleń. Od 2.8.2026 obowiązują m.in.:

- **Zarządzanie ryzykiem (art. 9):** identyfikacja i mitygacja ryzyka bias, ze szczególnym uwzględnieniem dyskryminacji wiekowej po sprawie Mobley v. Workday.
- **Governance danych (art. 10):** jakość danych treningowych, detekcja bias i testy równości szans dla grup niedoreprezentowanych - kobiet po urlopie macierzyńskim, osób z niepełnosprawnościami, pracowników po 40. roku życia.
- **Transparentność (art. 13):** jasna informacja o działaniu, dokładności i wynikach audytu bias.
- **Nadzór człowieka (art. 14):** człowiek w pętli przy każdej klasyfikacji; finalne zatwierdzenie HR Lead i przełożonego nigdy nie jest automatyczne.
- **Obowiązki deployera (art. 26):** ocena DPIA, monitoring po wdrożeniu i raportowanie incydentów.
- **Ocena wpływu na prawa podstawowe FRIA (art. 27):** przed wdrożeniem, w konsultacji z RPO, Inspektorem Ochrony Danych, Radą Pracowników i Pełnomocnikiem ds. Równego Traktowania.

Kary sięgają 35 mln EUR lub 7 procent globalnego obrotu grupy. Ponieważ klasyfikacja ma znaczący skutek prawny dla pracownika, obowiązuje też ocena DPIA z RODO art. 35. Amerykański [pozew zbiorowy Mobley v. Workday](https://www.courtlistener.com/docket/67476007/mobley-v-workday-inc/) - zarzut dyskryminacji kandydatów po 40. roku życia przez oprogramowanie HR - stał się punktem odniesienia dla nadzoru UE nad narzędziami skills-matching.

## Odwrócony ciężar dowodu przy klasyfikacji kompetencji

Fundamentem jest zasada równego traktowania z Konstytucji RP i Kodeksu Pracy: zakaz dyskryminacji bezpośredniej i pośredniej (m.in. ze względu na wiek, płeć, niepełnosprawność czy pochodzenie), odpowiedzialność pracodawcy, równa płaca za pracę o równej wartości oraz prawo do odszkodowania nie niższego niż minimalne wynagrodzenie. Reguły te obejmują także klasyfikację kompetencji, przydzielanie zadań i dostęp do ścieżek kariery.

Kluczowy jest odwrócony ciężar dowodu. Jeśli pracownik uprawdopodobni dyskryminację - na przykład wskaże anomalię statystyczną w rankingu ML albo brak dostępu do ścieżek kariery dla grupy chronionej - to pracodawca musi udowodnić, że do niej nie doszło. Bez udokumentowanej, odtwarzalnej walidacji każdej klasyfikacji przez człowieka i bez audytu bias ten dowód jest praktycznie nie do przeprowadzenia.

Linię tę wzmacniają uchwały Sądu Najwyższego (III PZP 5/19 i III PZP 12/15) oraz wyrok II PK 200/15, które potwierdzają, że ciężar dowodu spoczywa na pracodawcy.

## RODO art. 22 zakaz wyłącznie zautomatyzowanej klasyfikacji talentów

[RODO art. 22](https://eur-lex.europa.eu/eli/reg/2016/679/oj) zakazuje wyłącznie zautomatyzowanego podejmowania indywidualnych decyzji ze skutkiem prawnym lub podobnie istotnym wpływem na osobę. Klasyfikacja skill-based wpływa na dostęp do ścieżek kariery, projektów strategicznych, programów rozwoju i szkoleń - to mieści się w zakresie znaczącego wpływu prawnego. RODO art. 22 ust. 3 przyznaje pracownikowi prawo do uzyskania interwencji ze strony człowieka, do wyrażenia własnego stanowiska oraz do zaskarżenia decyzji.

Konkretnie: algorytm ML nie może samodzielnie podjąć finalnej klasyfikacji. Bezpośredni przełożony i HR Lead muszą zwalidować rekomendację modelu wraz z dokumentacją, a pracownik ma prawo do interwencji człowieka i zaskarżenia. Towarzyszą temu obowiązki informacyjne z RODO oraz ocena DPIA dla zautomatyzowanej oceny.

Sankcje sięgają 4 procent obrotu grupy lub 20 mln EUR. Nadzór sprawuje UODO, a wytyczne EDPB z 2024 roku w sprawie systemów AI w HR koncentrują się na audytach algorytmicznego bias w latach 2024-2026.

## Taksonomia kompetencji: ZSK, ESCO i EQR

[Ustawa o Zintegrowanym Systemie Kwalifikacji z 22.12.2015](https://isap.sejm.gov.pl/isap.nsf/DocDetails.xsp?id=WDU20160000064) ustanawia ośmiopoziomową Polską Ramę Kwalifikacji, zgodną z [Europejskimi Ramami Kwalifikacji (EQR)](https://europa.eu/europass/en/european-qualifications-framework-eqf), oraz Rejestr Zintegrowany Kwalifikacji prowadzony przez Ministerstwo Edukacji Narodowej. To ustawowy fundament taksonomii kompetencji w Polsce - każda klasyfikacja musi się na nią mapować, inaczej grozi arbitralnością i brakiem uzasadnienia.

[ESCO](https://esco.ec.europa.eu/) jest unijnym katalogiem kompetencji prowadzonym przez Komisję Europejską, który mapuje zawody UE na hierarchię umiejętności i wiedzy w skali zgodnej z EQR. Agent waliduje kompetencje wobec ESCO dla interoperacyjności z systemami HR w grupach wielonarodowych oraz dla zgodności z dyrektywą o jawności wynagrodzeń, gdzie ocena kompetencji jest podstawą ustalenia pracy o równej wartości.

Amerykański pozew zbiorowy Mobley v. Workday (2023) stał się momentem zwrotnym dla compliance skills-matching - zarzucono systematyczną dyskryminację kandydatów po 40. roku życia, czyli naruszenie odpowiednika polskiego art. 18-3a Kodeksu Pracy. Organy nadzorcze UE wzorują się na tym precedensie. W praktyce oznacza to, że każde wdrożenie narzędzia skills-matching wymaga oceny FRIA i DPIA, kwartalnego audytu bias, walidacji przez człowieka oraz pięcioletniego śladu audytowego.

## Współpraca z agentami awansów, ocen i sukcesji

Skills-Career-Profile-Agent jest osadzony w pipeline wyspecjalizowanych agentów HR z jasnym podziałem odpowiedzialności. [Promotion-Process-Agent](/pl/katalog-agentow-hr/promotion-process-agent/) konsumuje wyniki Skills-Career-Profile dla walidacji uprawnień awansu - kluczowa różnica vs. Skills-Career-Profile, który buduje inwentarz kompetencji jako fundament. [Performance-Review-Documentation-Agent](/pl/katalog-agentow-hr/performance-review-documentation-agent/) dostarcza oceny wydajności jako wsparcie kalibracji walidacji przełożonego. [Compensation-Benchmarking-Agent](/pl/katalog-agentow-hr/compensation-benchmarking-agent/) reużywa skill-based job evaluation jako podstawę dla EU Pay Transparency 2023/970 Article 4 work-of-equal-value.

[Certification-Tracking-Agent](/pl/katalog-agentow-hr/certification-tracking-agent/) dostarcza aktualne certyfikacje zwalidowane wobec Polskiej Ramy Kwalifikacji. [Learning-Path-Recommendation-Agent](/pl/katalog-agentow-hr/learning-path-recommendation-agent/) odbiera plan rozwoju z rekomendacjami szkoleń. [People-Analytics-Agent](/pl/katalog-agentow-hr/people-analytics-agent/) reużywa Equity Analysis Engine. [HR-Document-Management-Agent](/pl/katalog-agentow-hr/hr-document-management-agent/) archiwizuje klasyfikacje i uzasadnienia przez pięcioletni okres wymagany prawem pracy. [Audit-Compliance-Agent](/pl/katalog-agentow-hr/audit-compliance-agent/) weryfikuje spójność obowiązków deployera, DPIA i FRIA. Agenci rekrutacji - [Job-Posting-Agent](/pl/katalog-agentow-hr/job-posting-agent/), [Executive-Recruiting-Agent](/pl/katalog-agentow-hr/executive-recruiting-agent/) i [Candidate-Screening-Agent](/pl/katalog-agentow-hr/candidate-screening-agent/) - reużywają taksonomii ZSK, ESCO i EQR oraz integracji z polskim rynkiem talentów.

## Na pierwszy rzut oka

- **Klasyfikacja**: system wysokiego ryzyka według EU AI Act (Aneks III(4)(b)) od 2.8.2026
- **Kotwice zgodności**: zasada równego traktowania z Kodeksu Pracy i Konstytucji RP, RODO art. 22, taksonomia ZSK/ESCO/EQR oraz raportowanie CSRD i GPW WIG-ESG
- **Konsultacje**: obowiązkowe wobec Rady Pracowników i związków zawodowych
- **Taksonomia**: ośmiopoziomowa Polska Rama Kwalifikacji zgodna z EQR, katalog ESCO i Rejestr Zintegrowany Kwalifikacji
- **Próg equity**: niewyjaśniona luka kompetencyjna w grupie chronionej powyżej 5 procent uruchamia obowiązek mitygacji i eskalację do HR Lead, IOD i zarządu
- **Kary**: do 35 mln EUR lub 7 procent globalnego obrotu grupy z EU AI Act, do 4 procent lub 20 mln EUR z RODO oraz sankcje PIP
- **Obowiązek audytu**: DPIA, FRIA i kwartalny audyt bias; weryfikacja audytora CSRD od 250 pracowników
- **Precedens**: amerykański pozew zbiorowy Mobley v. Workday - dyskryminacja kandydatów po 40. roku życia przez oprogramowanie HR
- **Współpraca**: Promotion-Process-Agent korzysta z wyników profilu kompetencji przy walidacji uprawnień do awansu

### Rozdział decydentów Skills-Career-Profile

| Krok | Decydent | Uzasadnienie |
|------|----------|--------------|
| Inicjacja samooceny pracownika | H | Indywidualna samoocena + dokumentacja uzasadnienia |
| Integracja certyfikacji ZSK PRK | R | Walidacja Rejestr Zintegrowany Kwalifikacji deterministyczna |
| Aktualizacja na podstawie szkoleń | R | Wnioskowanie z Learning-Path deterministyczne |
| Walidacja bezpośredniego przełożonego | H | Kalibracja samooceny + obowiązkowa dokumentacja |
| Mapowanie ZSK + ESCO + EQR | R | Taksonomia oparta na regułach |
| Skills-gap-analysis ścieżki kariery | A | ML porównanie z walidacją człowieka |
| Equity Analysis Engine | A | ML-statystyczna detekcja Skills Gap z walidacją człowieka |
| Eskalacja Skills Gap | R | Prog >5 procent + audit-trail deterministyczne |
| Konsultacje Rady Pracowników | R | Art. 13-14 + porozumienie zakładowe deterministyczne |
| Finalna klasyfikacja HR Lead | H | Finalne zatwierdzenie RODO art. 22 walidacja człowieka |
| Generowanie planu rozwoju | R | Szablony ZSK PRK + ESCO deterministyczne |
| Informacja RODO | R | Article 13+14+22 ust. 3 standardowy workflow |
| Rozmowa rozwojowa | H | Osobista rozmowa wymiar relacyjny + rozwojowy |
| Aktualizacja systemów + CSRD | R | ESRS S1-13 Skills Coverage deterministyczne |

--- Agent strategicznej analityki HR ---
> Strategiczne analizy HR: fluktuacja, Diversity Reporting, ROI HR i Board Reporting zgodne z KP art. 11-2, RODO art. 88, CSRD ESRS S1-1/S1-9/S1-14 i GPW WIG-ESG dla Zarządu i Rady Nadzorczej.

## Z danych HR do strategicznych spostrzeżeń

Ten agent stosuje zasadę [Decision Layer](/pl/decision-layer/): każda decyzja jest oparta na regułach, wspomagana AI lub jawnie przypisana człowiekowi. Nie jest systemem wysokiego ryzyka w rozumieniu [EU AI Act](https://eur-lex.europa.eu/eli/reg/2024/1689/oj), bo pracuje na danych zagregowanych i nie podejmuje decyzji indywidualnych. Podlega jednak ścisłym obowiązkom compliance wynikającym z zasady równego traktowania w [Kodeksie Pracy](https://isap.sejm.gov.pl/) i Konstytucji RP, z ochrony danych zatrudnienia (RODO art. 88) oraz z raportowania CSRD i GPW WIG-ESG, z obowiązkową weryfikacją audytora od 250 pracowników.

Typowy zespół przetwarza kwartalnie setki, a nawet tysiące wskaźników z danych HR, płacowych, wynikowych i ankiet satysfakcji. Ręczne zestawienia trwają tygodnie i są podatne na błędy interpretacyjne. Agent generuje te wskaźniki deterministycznie w sekundach - metryki różnorodności, fluktuację, korelacje satysfakcji, ROI HR oraz dane CSRD i GUS.

Problem nie leży w wolumenie danych, lecz w reżimie analiz zagregowanych z RODO art. 88: minimalizacji danych, ograniczeniu celu i zakazie decyzji indywidualnych. Interpretację strategiczną waliduje CHRO, raportowanie do zarządu i rady nadzorczej odbywa się w trybie nadzoru korporacyjnego, a biegły rewident pracuje na próbach zgodnie z krajowymi standardami audytu.

## Raportowanie CSRD oraz GPW WIG-ESG

[Dyrektywa CSRD](https://eur-lex.europa.eu/eli/dir/2022/2464/oj) i standardy ESRS S1 obejmują różnorodność, równe szanse, poziomy wynagrodzeń, równowagę praca-życie oraz BHP. Wymagają obowiązkowej weryfikacji audytora od 250 pracowników, z wejściem w życie etapami: od 2024 roku dla dużych spółek publicznych, od 2025 dla pozostałych dużych spółek i od 2026 dla MŚP. Metodykę wyznacza EFRAG.

Spółki notowane na GPW raportują dodatkowo zgodnie z Dobrymi Praktykami Spółek Notowanych i indeksem WIG-ESG, w ramach rocznego raportowania nadzoru korporacyjnego. Kodeks spółek handlowych nakłada przy tym dziesięcioletni obowiązek archiwizacji dokumentów korporacyjnych oraz osadza odpowiedzialność zarządu i rady nadzorczej.

Niezależnie od tego firmy mają obowiązek sprawozdawczości statystycznej wobec GUS (m.in. formularz Z-12), wynikającej z ustawy o statystyce publicznej, a dane zagregowane trafiają również do Eurostatu.

## Analiza fluktuacji i raportowanie różnorodności

Fundamentem jest zasada równego traktowania z [Kodeksu Pracy](https://isap.sejm.gov.pl/) i Konstytucji RP: zakaz dyskryminacji, odwrócony ciężar dowodu po stronie pracodawcy, równa płaca za pracę o równej wartości oraz prawo do odszkodowania bez górnego limitu. To na tej podstawie powstają raporty różnorodności i analiza fluktuacji.

Analiza fluktuacji obejmuje: wskaźnik fluktuacji ogólny oraz w podziale na dobrowolną i niedobrowolną, analizę kohort według stażu, analizę na poziomie stanowisk, lukę płacową ze względu na płeć, analizę dyskryminacji wiekowej, badanie ankiet exit, identyfikację czynników retencji oraz statystyczne wykrywanie wartości skrajnych - z audytem bias dla każdego wymiaru.

Naruszenia są kosztowne: sankcja UODO do 4 procent obrotu grupy lub 20 mln EUR, kara PIP, nieograniczone odszkodowanie dla pracownika, odpowiedzialność administracyjna zarządu oraz - przy spółkach giełdowych - ujawnienie i zastrzeżenie audytora w raporcie CSRD.

## Ochrona danych zatrudnienia i konsultacje z Radą Pracowników

Dane strategicznych analiz HR zawierają agregowane informacje wrażliwe: wskaźnik fluktuacji, metryki różnorodności, lukę płacową, rozkład wieku, satysfakcję, zaangażowanie oraz wskaźniki kosztu i wydajności. Podlegają one ochronie danych zatrudnienia z RODO art. 88 oraz krajowej ustawie o ochronie danych osobowych.

Agent stosuje zasadę Privacy by Design z architekturą opartą na agregatach, środki bezpieczeństwa z szyfrowaniem danych w spoczynku i w tranzycie, ocenę DPIA przy szerokim przetwarzaniu, umowy powierzenia z dostawcami analityki oraz plan usuwania po upływie terminu przechowywania. Z założenia nie podejmuje przy tym decyzji indywidualnych.

Wprowadzenie systemu wymaga konsultacji z Radą Pracowników (obowiązek informacji i konsultacji od 50 pracowników) oraz uwzględnienia uprawnień związków zawodowych. Wytyczne EDPB z 2024 roku potwierdzają, że analizy zagregowane są poza reżimem wysokiego ryzyka, a pracowników zgłaszających nieprawidłowości chroni ustawa o sygnalistach.

## Predictive Analytics i obliczanie ROI HR

Predictive Analytics wspierane ML, oparte na historii fluktuacji, danych o kompetencjach, ankietach i wynikach, dostarcza prognozy retencji, analizy luk kompetencyjnych i planowania zatrudnienia. Wynik modelu jest wskaźnikiem, a nie końcową decyzją o pojedynczym pracowniku - interpretację strategiczną zatwierdzają CHRO i zarząd.

Obliczanie ROI HR obejmuje koszt rekrutacji (z uwzględnieniem onboardingu i szkoleń), czas do pełnej produktywności, przychód na etat, ROI szkoleń oraz ROI retencji wynikające z zatrzymania talentów. Podstawą metodyczną są ustawa o rachunkowości oraz krajowe i międzynarodowe standardy sprawozdawczości.

BRAK rein automatycznej decyzji o pojedynczym pracowniku - zwolnienie wynikające z agregacji + RODO art. 22 zakaz wyłącznie zautomatyzowanego podejmowania decyzji. Cross-Reference aggregate-analytics-zwolnienie EU AI Act + EDPB Guidelines 1/2024 + UODO Plan strategiczny 2024-2027.

## Współpraca z agentami ocen, planowania zatrudnienia i sukcesji

Strategic-HR-Analytics-Agent jest osadzony w pipeline strategicznych agentów HR. [Performance-Review-Agent](/pl/katalog-agentow-hr/performance-review-agent/) dostarcza danych wynikowych do korelacji z fluktuacją i satysfakcją. [Workforce-Planning-Agent](/pl/katalog-agentow-hr/workforce-planning-agent/) wykorzystuje prognozy retencji i analizy luk kompetencyjnych do planowania zatrudnienia. [Succession-Planning-Agent](/pl/katalog-agentow-hr/succession-planning-agent/) korzysta z analiz talent-pool i identyfikacji wysokiego potencjału. [Compensation-Benchmarking-Agent](/pl/katalog-agentow-hr/compensation-benchmarking-agent/) dostarcza widełek wynagrodzeniowych do analizy luki płacowej, a [Talent-Acquisition-Agent](/pl/katalog-agentow-hr/talent-acquisition-agent/) - kosztu i czasu rekrutacji do obliczania ROI HR. [Payroll-Reporting-Agent](/pl/katalog-agentow-hr/payroll-reporting-agent/) przekazuje dane płacowe na potrzeby raportowania poziomów wynagrodzeń w CSRD, a [Audit-Compliance-Agent](/pl/katalog-agentow-hr/audit-compliance-agent/) weryfikuje zgodność z krajowymi standardami rachunkowości. Agenci raportowania finansowego i ESG reużywają modułów GPW WIG-ESG.

## Na pierwszy rzut oka

- **Klasyfikacja**: analizy zagregowane, poza reżimem wysokiego ryzyka EU AI Act
- **Kotwice zgodności**: zasada równego traktowania z Kodeksu Pracy i Konstytucji RP, RODO art. 88, standardy rachunkowości oraz raportowanie CSRD ESRS S1 i GPW WIG-ESG
- **Przechowywanie**: 10 lat dla dokumentów korporacyjnych z KSH oraz 5 lat z prawa pracy i ustawy o rachunkowości
- **Współdecydowanie**: obowiązkowe konsultacje z Radą Pracowników i związkami zawodowymi od 50 pracowników
- **Sankcje**: UODO do 4 procent obrotu grupy, kara PIP, nieograniczone odszkodowanie dla pracownika oraz odpowiedzialność zarządu i ujawnienie GPW WIG-ESG
- **Obowiązek audytu**: weryfikacja audytora od 250 pracowników w raportowaniu CSRD, nadzorowana przez KIBR i PANA
- **Współpraca**: agenci ocen, planowania zatrudnienia, sukcesji, benchmarkingu wynagrodzeń i raportowania płac

### Rozdział decydentów Strategic-HR-Analytics

| Krok | Decydent | Uzasadnienie |
|------|----------|--------------|
| Analiza fluktuacji + cohort analysis | R | aggregate-analytics z danych HR determinista |
| Diversity Metrics ESRS S1-1+S1-9 | R | EFRAG metodyka + Konstytucja RP art. 32 determinista |
| Korelacje satysfakcji + engagement | A | ML-correlation z walidacją CHRO |
| Obliczanie HR ROI | R | Cost-per-Hire + Revenue-per-FTE + KSR determinista |
| CSRD ESRS S1 KPI dashboardy | R | EU-Bilanzrichtlinie + EFRAG determinista |
| GPW WIG-ESG raportowanie | R | Code of Best Practices determinista |
| Predictive Analytics retencja | A | ML-Forecast z walidacją CHRO |
| GUS Z-12 + Eurostat ESS | R | API GUS + Ustawa o statystyce publicznej determinista |
| Rada Pracowników 4.07.2006 | H | konsultacje obowiązkowe od 50 MA |
| CHRO zatwierdza Board Reporting | H | KSH art. 382 Rada Nadzorcza obowiązkowa |
| RODO art. 88 aggregate-analytics | R | EDPB Guidelines 1/2024 determinista |
| Bias-Audit anomalie dyskryminacyjne | A | ML-Anomalie z walidacją Specjalisty ds. Diversity |
| Cross-reference do innych agentów | R | linkowanie pipeline determinista |
| 10-letni okres + RODO art. 17 | R | KSH art. 84 + lifecycle determinista |

--- Agent planowania sukcesji ---
> Planowanie sukcesji kluczowych stanowisk: Hi-Po identyfikacja, Readiness Assessment, Risk Mapping zgodne z KP art. 11-2, RODO art. 6+9+22+88, KSH art. 233+382 i Code of Best Practices WSE.

## Planowanie sukcesji jako strategiczny obowiązek compliance

Ten agent stosuje zasadę [Decision Layer](/pl/decision-layer/): każda decyzja jest oparta na regułach, wspomagana AI lub jawnie przypisana człowiekowi. Nie jest systemem wysokiego ryzyka w rozumieniu [EU AI Act](https://eur-lex.europa.eu/eli/reg/2024/1689/oj), bo planowanie sukcesji nie jest bezpośrednią decyzją o rekrutacji ani wynagrodzeniu. Podlega jednak ścisłym obowiązkom compliance wynikającym z zasady równego traktowania w [Kodeksie Pracy](https://isap.sejm.gov.pl/) i Konstytucji RP, z ochrony danych zatrudnienia, z Dobrych Praktyk Spółek Notowanych i odpowiedzialności rady nadzorczej z Kodeksu spółek handlowych, z weryfikacją audytora od 250 pracowników.

Typowe planowanie sukcesji obejmuje rocznie 50 do 200 kluczowych stanowisk i angażuje CHRO, zarząd, radę nadzorczą i Komitet Nominacji w firmie 500-5000 pracowników. Ręczne mapowania w Excelu trwają tygodnie i są podatne na błędy interpretacyjne oraz na bias dyskryminacyjny. Agent generuje to deterministycznie w sekundach: mapę kluczowych stanowisk, siatkę 9-Box, mapę ryzyka, siłę ławki i czas do gotowości.

Problem nie leży w wolumenie danych, lecz w świadomości, że identyfikacja wysokiego potencjału oparta na AI bez walidacji człowieka narusza RODO art. 22, grozi pozwami zbiorowymi w stylu sprawy Mobley v. Workday i uruchamia odpowiedzialność administracyjną zarządu - dlatego zatwierdzenie Komitetu Nominacji i Rady Nadzorczej jest obowiązkowe.

## Odpowiedzialność organów spółki i Dobre Praktyki GPW

[Kodeks spółek handlowych](https://isap.sejm.gov.pl/) jest fundamentem planowania sukcesji na poziomie zarządu: nakłada dziesięcioletni obowiązek archiwizacji dokumentów korporacyjnych, reguluje podejmowanie uchwał zarządu oraz osadza odpowiedzialność członków zarządu i radę nadzorczą z jej obowiązkiem nadzoru.

Dobre Praktyki Spółek Notowanych GPW wymagają obowiązkowego planu sukcesji dla zarządu i kluczowych stanowisk, działania Komitetu Nominacji i Komitetu Wynagrodzeń oraz rocznego raportowania nadzoru korporacyjnego, w ramach obowiązków spółek z indeksu WIG-ESG.

Nadzór nad spółkami notowanymi sprawuje KNF, a niedopełnienie obowiązków raportowania nadzoru korporacyjnego - w tym planu sukcesji - jest zagrożone sankcjami. W praktyce plan sukcesji dla zarządu i kadry C-level musi być zatwierdzany przez Komitet Nominacji i Radę Nadzorczą co najmniej raz w roku, wraz z audytem bias, metrykami różnorodności oraz wskaźnikiem pokrycia następcami dla każdego kluczowego stanowiska.

## Równe traktowanie a ryzyko bias w identyfikacji potencjału

Fundamentem identyfikacji wysokiego potencjału i siatki 9-Box jest zasada równego traktowania z [Kodeksu Pracy](https://isap.sejm.gov.pl/): zakaz dyskryminacji bezpośredniej i pośredniej, odwrócony ciężar dowodu po stronie pracodawcy, równa płaca za pracę o równej wartości oraz odszkodowanie bez górnego limitu. Wzmacniają ją Konstytucja RP oraz ustawa antydyskryminacyjna, z odwróconym ciężarem dowodu i prawem do odszkodowania.

Amerykański pozew zbiorowy Mobley v. Workday (2023) to kluczowy przykład ryzyka bias przy decyzjach kadrowych opartych na AI - i ostrzeżenie dla planowania sukcesji. Dlatego siatka 9-Box i identyfikacja potencjału wymagają walidacji człowieka oraz audytu bias.

Audyt bias obejmuje dyskryminację ze względu na płeć, wiek, pochodzenie, staż i poziom stanowiska, a także uprzedzenia w czasie do gotowości i pokryciu następcami, wraz ze statystycznym wykrywaniem wartości skrajnych.

Naruszenia są kosztowne: sankcja UODO do 4 procent obrotu grupy lub 20 mln EUR, kara PIP, nieograniczone odszkodowanie dla pracownika, odpowiedzialność administracyjna zarządu oraz - przy spółkach giełdowych - ujawnienie, sankcja indeksowa i zastrzeżenie audytora w raporcie CSRD.

## Ochrona danych i konsultacje z Radą Pracowników

Dane planowania sukcesji są wrażliwe: oceny wyników i potencjału z siatki 9-Box, klasyfikacja wysokiego potencjału, ocena gotowości, indywidualne plany rozwoju, profile kompetencji i aspiracje zawodowe oraz pary mentoringowe i pipeline następców. Podlegają one ochronie danych zatrudnienia z RODO art. 88 oraz krajowej ustawie o ochronie danych osobowych.

Szczególnie istotny jest RODO art. 22, który zakazuje wyłącznie zautomatyzowanych decyzji znacząco wpływających na osobę - a decyzje o potencjale, gotowości i planie rozwoju mają duży wpływ na karierę. Dlatego walidacja przez CHRO, Komitet Nominacji i Radę Nadzorczą jest obowiązkowa.

Agent stosuje zasadę Privacy by Design, środki bezpieczeństwa z szyfrowaniem danych w spoczynku i w tranzycie, obowiązkową ocenę DPIA (planowanie sukcesji jest profilowaniem), umowy powierzenia z dostawcami oraz plan usuwania po upływie terminu przechowywania.

Wprowadzenie systemu wymaga konsultacji z Radą Pracowników (obowiązek informacji i konsultacji od 50 pracowników) oraz uwzględnienia uprawnień związków zawodowych. W praktyce zawiera się porozumienie zakładowe o zakresie siatki 9-Box, identyfikacji potencjału, planie uprawnień, cyklu życia danych, ich usuwaniu, dostępie do śladu audytowego i obowiązku audytu bias. Pracowników zgłaszających nieprawidłowości chroni ustawa o sygnalistach.

## Taksonomia kompetencji i granice AI

Zintegrowany System Kwalifikacji (ustawa z 22.12.2015), prowadzony przez IBE, ustanawia ośmiopoziomową Polską Ramę Kwalifikacji oraz Sektorowe Ramy Kwalifikacji - to fundament taksonomii kompetencji w polskim planowaniu sukcesji.

Europejskie Ramy Kwalifikacji (EQR) i katalog ESCO dają wspólną taksonomię 13 890 umiejętności i 3 008 zawodów. Agent mapuje kompetencje stanowisk i pracowników deterministycznie na te ramy, by przeprowadzić analizę luk kompetencyjnych, ocenę gotowości i wyznaczenie czasu do gotowości.

Wspierana ML klasyfikacja wysokiego potencjału, oparta na historii awansów, ocenach wyników i profilach kompetencji, dostarcza wskaźniki potencjału i gotowości, ale nie końcową decyzję o awansie. Walidacja przez CHRO, Komitet Nominacji i Radę Nadzorczą jest obowiązkowa zgodnie z RODO art. 22 i Kodeksem spółek handlowych.

Agent nie podejmuje automatycznej decyzji o awansie - rozstrzyga ją człowiek, co wynika z RODO art. 22 i jest potwierdzone przykładem Mobley v. Workday.

## Współpraca z agentami profili kompetencji, awansów i planowania zatrudnienia

Succession-Planning-Agent jest osadzony w pipeline strategicznych agentów talentowych. [Skills-Career-Profile-Agent](/pl/katalog-agentow-hr/skills-career-profile-agent/) dostarcza profili kompetencji i aspiracji zawodowych do oceny gotowości. [Promotion-Process-Agent](/pl/katalog-agentow-hr/promotion-process-agent/) wykorzystuje siatkę 9-Box i identyfikację potencjału do decyzji o awansie. [Workforce-Planning-Agent](/pl/katalog-agentow-hr/workforce-planning-agent/) korzysta z siły ławki i mapy ryzyka. [Performance-Review-Agent](/pl/katalog-agentow-hr/performance-review-agent/) dostarcza ocen wyników do siatki 9-Box. [Strategic-HR-Analytics-Agent](/pl/katalog-agentow-hr/strategic-hr-analytics-agent/) wykorzystuje metryki różnorodności w raportowaniu do zarządu, [Compensation-Benchmarking-Agent](/pl/katalog-agentow-hr/compensation-benchmarking-agent/) dostarcza widełek wynagrodzeniowych, a [Talent-Acquisition-Agent](/pl/katalog-agentow-hr/talent-acquisition-agent/) - danych o rynku zewnętrznym do analizy budowy lub pozyskania talentu. Agenci raportowania finansowego i ESG reużywają modułów GPW WIG-ESG i CSRD.

## Na pierwszy rzut oka

- **Klasyfikacja**: planowanie strategiczne, poza reżimem wysokiego ryzyka EU AI Act, ale z obowiązkiem oceny DPIA, walidacji człowieka i audytu bias
- **Kotwice zgodności**: zasada równego traktowania z Kodeksu Pracy i Konstytucji RP, RODO art. 22, Dobre Praktyki Spółek Notowanych, odpowiedzialność organów spółki, taksonomia ZSK/ESCO/EQR oraz raportowanie CSRD i GPW WIG-ESG
- **Przechowywanie**: 10 lat dla dokumentów korporacyjnych z KSH oraz 5 lat z prawa pracy i ustawy o rachunkowości
- **Współdecydowanie**: obowiązkowe konsultacje z Radą Pracowników i związkami zawodowymi od 50 pracowników, z porozumieniem zakładowym o siatce 9-Box
- **Sankcje**: UODO do 4 procent obrotu grupy, kara PIP, nieograniczone odszkodowanie dla pracownika, odpowiedzialność zarządu oraz ujawnienie i sankcja indeksowa GPW WIG-ESG
- **Obowiązek audytu**: weryfikacja audytora od 250 pracowników w raportowaniu CSRD, nadzorowana przez KIBR, oraz zatwierdzenie Komitetu Nominacji i Rady Nadzorczej
- **Współpraca**: agenci profili kompetencji, awansów, planowania zatrudnienia, ocen, analityki, benchmarkingu wynagrodzeń i rekrutacji

### Rozdział decydentów Succession-Planning

| Krok | Decydent | Uzasadnienie |
|------|----------|--------------|
| Mapowanie kluczowych stanowisk | R | business-impact-analysis determinista |
| 9-Box-Grid Performance vs Potential | A | ML-klasyfikacja z walidacją CHRO + Komitet Nominacji |
| Ocena Readiness Ready Now/1-2/3-5 lat | R | skill-gap + ESCO taksonomia determinista |
| Risk Mapping Bench-Strength | R | Successor-Coverage-Ratio determinista |
| Plan rozwoju IDP indywidualny | A | ML-rekomendacja z walidacją Head of Talent |
| ZSK + ESCO + EQR taksonomia | R | PRK 8 poziomów + ESCO determinista |
| Cross-reference do innych agentów | R | linkowanie pipeline determinista |
| RODO art. 22 walidacja człowieka | H | Mobley v. Workday + EDPB Guidelines 1/2024 obowiązkowa |
| Rada Pracowników 4.07.2006 | H | konsultacje obowiązkowe od 50 MA |
| Komitet Nominacji + Rada Nadzorcza | H | KSH art. 382 + Code of Best Practices obowiązkowa |
| Bias-Audit Hi-Po identyfikacja | A | ML-Anomalie z walidacją Pełnomocnika ds. Równego Traktowania |
| ESG/CSRD ESRS S1 + GPW WIG-ESG | R | EU-Bilanzrichtlinie + EFRAG determinista |
| 10-letni okres + RODO art. 17 | R | KSH art. 84 + lifecycle determinista |

--- Talent Pool Management Agent ---
> Zarządzanie talent poolem zgodne z KP art. 18-3a, RODO art. 6+22 i EU AI Act Annex III - segmentacja, sekwencje reaktywacji 6/12/24 m-cy i retencja 5 lat z konsultacją Rady Pracowników.

Polski rynek pracy z 1 milionem otwartych wakatów ma 80 procent talentów ukrytych - kandydatów którzy raz aplikowali, raz odbyli rozmowę, raz zostali odrzuceni. Zniknęli z radaru działu HR, bo system zarządzający kandydatami nie odróżnia "odrzucony bo nieodpowiedni" od "odrzucony bo wybrano innego" - silver medalist równie cenny jak top kandydat, ale zaginiony w folderze "archiwum".

## Talent pool jako pułapka compliance między RODO a KP art. 18-3a

Talent pool to dynamiczny ekosystem kandydatów, nie statyczna baza CV. Każdy kandydat ma osobny status w funnel: aktywny w rozmowie, zakwalifikowany, pasywny, silver medalist, alumni, dormant.

Pułapka leży w tym że każdy status wymaga innego profilu compliance. Aktywny kandydat działa pod RODO art. 6 ust. 1 lit. b (działania przed zawarciem umowy). Pasywny prospekt wymaga RODO art. 6 ust. 1 lit. a (zgoda 24 miesiące z renewal). Odrzucony może być przechowywany pod RODO art. 6 ust. 1 lit. f (prawnie uzasadniony interes obrony przed KP art. 18-3a) z balance test i ograniczeniem 24 miesięcy.

Większość polskich firm 500-5000 pracowników ma jeden profil zgody dla wszystkich kandydatów. Narusza RODO art. 5 ust. 1 lit. a i KP art. 22-1. Kontrola UODO odkrywa 80 procent dormant 36 miesięcy bez renewal - sankcja do 4 procent obrotu z RODO art. 5+6+88.

## Zgoda kandydata i prawo do usunięcia danych

RODO art. 6 ust. 1 lit. a wymaga aby zgoda kandydata na talent pool była dobrowolna, świadoma, jednoznaczna i możliwa do wycofania. To nie checkbox w formularzu, to architektura.

Dobrowolność oznacza że zgoda na talent pool musi być oddzielna od zgody na bieżącą rekrutację. Świadomość wymaga informacji o celu, okresie 24 miesięcy, prawie do wycofania, kontakcie do IOD. Jednoznaczność wyklucza domyślnie zaznaczone checkboxy - active opt-in jest obowiązkowy z CJEU C-21/23 Lindenapotheke 2024.

Wycofanie zgody z RODO art. 7 ust. 3 wymaga linku w każdej komunikacji talent pool. Wycofanie generuje żądanie usunięcia z RODO art. 17 z terminem 30 dni z art. 12 ust. 3.

Wyjątki z art. 17 ust. 3 są wąskie. Dla zatrudnionych wyjątek z obowiązku prawnego KP art. 22-1 i KP art. 94 pkt 9b (5 lat). Dla kandydatów w postępowaniu sądowym wyjątek z postępowania (prescription 3 lat KP art. 291). Dla pozostałych pełne usunięcie z dokumentacją RODO art. 30.

Agent automatyzuje cały cykl. IOD zatwierdza wyjątki z art. 17 ust. 3 - decyzja wymaga osądu człowieka z RODO art. 22.

## Zamknięty katalog danych kandydata i okres przechowywania

Kodeks Pracy art. 22-1 wprowadza zamknięty katalog danych kandydata które pracodawca może żądać:

- imię, nazwisko
- data urodzenia
- dane kontaktowe (adres, telefon, e-mail)
- wykształcenie
- kwalifikacje zawodowe
- przebieg dotychczasowego zatrudnienia

Wszystko poza katalogiem wymaga podstawy. KP art. 22-1a daje rozszerzenie za zgodą - zdjęcie z CV, hobby, status rodzinny, języki obce powyżej wymaganych dla stanowiska. KP art. 22-1b reguluje dane biometryczne - zakaz przetwarzania bez podstawy z RODO art. 9 ust. 2. AI video-interview z analizą twarzy lub głosu wymaga zgody i klasyfikacji jako system wysokiego ryzyka EU AI Act Annex III pkt 4 lit. a.

Okres przechowywania jest podwójny:

- 5 lat dla kandydatów zatrudnionych z KP art. 94 pkt 9b (od końca roku zakończenia stosunku pracy)
- 24 miesiące dla pasywnych w talent pool (od daty zgody lub ostatniej aktywności)
- 24 miesiące dla odrzuconych kandydatów (balance test RODO art. 6 ust. 1 lit. f, obrona przed roszczeniem KP art. 18-3a)

Po 24 miesiącach agent uruchamia procedurę renewal - automatyczna wiadomość z opcjami: kontynuacja zgody (nowy 24-miesięczny okres), wycofanie i usunięcie (RODO art. 17), konwersja do pasywnego newslettera. Brak odpowiedzi w 30 dni równa się wycofanie zgodnie z polityką organizacji zatwierdzoną przez IOD.

## Dopasowanie AI jako system wysokiego ryzyka i sprawa Mobley v. Workday

EU AI Act 2024/1689 Annex III pkt 4 lit. a klasyfikuje AI w rekrutacji jako system wysokiego ryzyka. Obowiązki Deployer art. 26 są kumulatywne:

- rejestr UE
- conformity assessment
- transparency obligation art. 13 (informacja kandydatowi)
- monitoring jakości output
- raportowanie incydentów do AI Office
- fundamental rights impact assessment FRIA art. 27 (sektor publiczny)

Art. 86 daje kandydatowi prawo do wyjaśnienia logiki decyzji w terminie miesiąca. Recruiter zatwierdza treść z RODO art. 22.

Audyt bias jest obowiązkowy z art. 9 (risk management) i art. 10 (jakość danych treningowych). Kwartalna analiza output dla chronionych grup KP art. 11-2 - płeć, wiek, niepełnosprawność, pochodzenie etniczne. Raport dla Pełnomocnika ds. Równego Traktowania.

Precedens Mobley v. Workday Court of Appeals 9th Circuit 2024 ustalił że AI screening platform jako agent pracodawcy może być pozwany za dyskryminację Title VII. Wpływ na polskie prawo: due diligence dostawcy AI (LinkedIn Talent, Eightfold AI, Workday), audyt bias przed wdrożeniem, SCC dla transferu poza UE, ochrona kandydata z Ustawy z 14.06.2024 (24-miesięczna).

Sankcje kumulatywne. EU AI Act do 35 milionów EUR lub 7 procent globalnego obrotu. UODO do 4 procent obrotu z RODO art. 5+6+22+88. PIP do 30 000 zł.

## Zaangażowanie kandydatów i sekwencje reaktywacji

Talent pool bez zaangażowania to martwa baza CV. Workflow zaangażowania ma trzy poziomy:

- newsletter dla pasywnych - kwartalnie z opt-out RODO art. 7 ust. 3
- reaktywacja silver medalists - po 6 miesiącach z konkretną rolą wakatu
- reaktywacja alumni - po 12 miesiącach z update o firmie i nowych rolach
- check-in dla dormant - po 24 miesiącach z opcją renewal lub usunięcia

Personalizacja deterministyczna na podstawie segmentu. Recruiter zatwierdza priorytetyzację - decyzja w okresie wzmożonej rekrutacji wymaga osądu człowieka.

Mapowanie talentów na role wakaty z AI talent-matching jest systemem wysokiego ryzyka EU AI Act. Score na podstawie skills, doświadczenia, lokalizacji, oczekiwań wynagrodzenia (EU Pay Transparency Directive 2023/970). Ranking top-N dla Recruitera z uzasadnieniem - skills overlap, adjacent skills, gap analysis. Recruiter zatwierdza top-N z RODO art. 22.

## Współpraca z agentami screeningu, due diligence i planowania rozmów

Talent Pool Management Agent współpracuje z trzema agentami rekrutacyjnymi. Candidate Screening Agent weryfikuje aplikacje bieżące z KP art. 22-1. Pre-Hire Due Diligence Agent weryfikuje background dla stanowisk regulowanych - KRD, KRK z Ustawy z 24.05.2000, GIIF dla AML. Interview Scheduling Agent automatyzuje kalendarz rozmów multistakeholder.

Cross-reference uruchamia się gdy kandydat z talent pool aplikuje na otwartą rolę. Reklasyfikacja podstawy z RODO art. 6 ust. 1 lit. a na lit. b. Transfer chroniony RODO art. 32 (AES-256 at-rest, TLS 1.3 in-transit).

Zgoda na talent pool pozostaje aktywna dla przyszłych ról. Każdy cross-reference dokumentowany w rejestrze RODO art. 30. Kandydat ma prawo dostępu RODO art. 15 w 30 dni z art. 12 ust. 3.

## [Decision Layer](/pl/decision-layer/) zamienia talent pool w weryfikowalny proces

Decision Layer rozkłada cykl życia kandydata w talent pool na pojedyncze kroki decyzyjne i dla każdego definiuje: człowiek, silnik reguł lub AI. Segmentację kandydatów po stage funnel przejmuje AI z confidence scoring 82-90 procent. Walidację katalogu KP art. 22-1+22-1a+22-1b, klasyfikację podstawy RODO art. 6, monitoring 24-miesięcznego okresu, routing sekwencji zaangażowania podlega silnikowi reguł. RODO art. 22 wyklucza pełną automatyzację - mapowanie talentów na role wakaty z AI talent-matching nie podejmuje ostatecznej decyzji o zaproszeniu kandydata, walidacja segmentacji AI poniżej threshold trafia do Recruitera, decyzja o usunięciu z RODO art. 17 z wyjątkami z art. 17 ust. 3 zawsze przy IOD.

Człowiek pozostaje tam, gdzie decyzja jest naprawdę potrzebna: zatwierdzenie polityki talent pool przez zarząd z odpowiedzialnością KSH art. 233+299, ocena kontrowersyjnego feedbacku z konsultacji Rady Pracowników, interpretacja w nietypowym przypadku (np. reaktywacja kandydata 36 miesięcy dormant z wyjątkiem od polityki). Recruiter widzi zweryfikowany pakiet - segmentacja, walidacja katalogu KP, walidacja zgody RODO, audyt bias EU AI Act - i autoryzuje kontakt z kandydatem.

## Na pierwszy rzut oka

- 80 procent talentów ukrytych w typowej polskiej firmie 500-5000 pracowników
- KP art. 22-1+22-1a+22-1b zamknięty katalog danych kandydata fundament zgodności
- RODO art. 6 ust. 1 lit. a zgoda dobrowolna oddzielna od bieżącej rekrutacji
- RODO art. 17 prawo do usunięcia z wyjątkami z art. 17 ust. 3
- RODO art. 22 zakaz pełnej automatyzacji decyzji rekrutacyjnych
- EU AI Act 2024/1689 Annex III pkt 4 lit. a system wysokiego ryzyka dla AI talent-matching
- 5 lat KP art. 94 pkt 9b dla zatrudnionych, 24 miesiące dla pasywnych z renewal
- Mobley v. Workday Court of Appeals 2024 due diligence dostawcy AI obowiązkowe
- Sankcje UODO do 4 procent obrotu, EU AI Act do 35 milionów EUR, PIP do 30 000 zł

### Rozdział decydentów Talent-Pool-Management

| Decyzja                                | Decydent | Podstawa prawna                       |
| -------------------------------------- | -------- | ------------------------------------- |
| Klasyfikacja podstawy RODO art. 6      | Reguła   | Status w funnel                       |
| Walidacja zgody RODO art. 6+7          | Reguła   | Checklist RODO art. 7                 |
| Walidacja katalogu KP art. 22-1        | Reguła   | Tabela zgodności katalogu             |
| Segmentacja po stage funnel            | KI       | RODO art. 22 + KP art. 11-2           |
| Walidacja kryteriów scoringu KP 18-3a  | KI       | EU AI Act art. 9+10 audyt bias        |
| Workflow zaangażowania                 | Reguła   | Macierz sekwencji 6/12/24 miesięcy    |
| Mapowanie na role wakaty               | KI       | EU AI Act Annex III pkt 4 lit. a      |
| Reaktywacja dormant 24 miesięcy        | Reguła   | RODO art. 5 ust. 1 lit. e             |
| Prawo do usunięcia RODO art. 17        | Reguła   | Wyjątki z art. 17 ust. 3              |
| Audyt bias EU AI Act                   | KI       | EU AI Act art. 9+10                   |
| Wyjaśnienie decyzji EU AI Act art. 86  | KI       | RODO art. 22 + EU AI Act art. 86      |
| Konsultacja Rady Pracowników           | Reguła   | Ust. z 4.07.2006 art. 14              |
| Cross-reference do innych agentów      | Reguła   | RODO art. 32 + macierz integracji     |
| Zatwierdzenie polityki talent pool     | Człowiek | KSH art. 233+299                      |

## Co infrastruktura daje innym agentom

Architektura segmentacji po stage funnel, workflow zgody RODO art. 6+7, audyt bias EU AI Act art. 9+10 jest szablonem dla agentów rekrutacyjnych. Candidate Screening, Pre-Hire Due Diligence i Interview Scheduling Agent reużywają wzorca segmentacji.

Decision Logging z RODO art. 30+32 buduje Audit Trail dla kontroli UODO, AAI, PIP i AI Office UE. Workflow renewal zgody po 24 miesiącach jest wzorcem dla agentów przetwarzających dane przez okres ograniczony.

--- Agent danych kadrowych HR ---
> Zarządzanie danymi kadrowymi: zgłoszenie ZUS ZUA, wybór oddziału NFZ, zwolnienie z PIT dla młodych art. 21 ust. 1 pkt 148, ulgi podatkowe pracownika i RODO art. 88.

## Deklaracje podatkowe i ZUS w terminie

Ten agent stosuje zasadę [Decision Layer](/pl/decision-layer/): każda decyzja jest oparta na regułach, wspomagana AI lub jawnie przypisana człowiekowi. Nie jest systemem wysokiego ryzyka w rozumieniu [EU AI Act](https://eur-lex.europa.eu/eli/reg/2024/1689/oj), bo działa na deterministycznych regułach i nie podejmuje decyzji kadrowych. Podlega jednak ścisłym obowiązkom compliance wynikającym z [ustawy o PIT](https://isap.sejm.gov.pl/) i Ordynacji podatkowej, z ustawy o systemie ubezpieczeń społecznych, przepisów o składce zdrowotnej i PPK oraz z krajowych standardów rachunkowości.

Typowy proces deklaracyjny obejmuje miesięcznie setki, a nawet tysiące pozycji z list płac. Ręczne zestawienia trwają dni i są podatne na błędy. Agent generuje deklaracje deterministycznie w sekundach - PIT i ZUS, składkę zdrowotną oraz zaświadczenia pracownicze - i monitoruje terminy z powiadomieniami 14, 7, 3 i 1 dzień przed upływem.

Problem nie leży w wolumenie, lecz w śladzie audytowym zgodnym ze standardami rachunkowości: dokumentacji procesowej, zasadzie czterech oczu (Specjalista ds. Płac, Główny Księgowy, doradca podatkowy), zapisie każdej zmiany z wartością przed i po, pięcioletnim okresie archiwizacji oraz w przygotowaniu na kontrolę podatkową i weryfikację biegłego rewidenta na próbie. Naruszenia oznaczają kontrolę KAS, wymiar szacunkowy oraz odpowiedzialność karną skarbową do 5 lat pozbawienia wolności i grzywnę.

## Obowiązki płatnika PIT i deklaracje roczne

[Ustawa o PIT](https://isap.sejm.gov.pl/) nakłada na płatnika obowiązek pobierania zaliczek na podatek dochodowy oraz złożenia deklaracji rocznych w określonych terminach: informacji PIT-11 dla pracowników do końca lutego, deklaracji PIT-4R o pobranych zaliczkach do końca stycznia oraz PIT-8AR o zryczałtowanym podatku od drobnych umów cywilnoprawnych do końca lutego. Dla nierezydentów składa się informacje IFT-1 i IFT-2.

Deklaracje wysyła się elektronicznie przez e-Deklaracje z podpisem kwalifikowanym. Może je też zatwierdzić doradca podatkowy z pełnomocnictwem, związany tajemnicą zawodową.

Naruszenia oznaczają kontrolę podatkową KAS i wymiar szacunkowy, odpowiedzialność karną skarbową do 5 lat pozbawienia wolności lub grzywnę, zastrzeżenie audytora oraz odpowiedzialność administracyjną zarządu. Ordynacja podatkowa nakłada przy tym pięcioletni okres przechowywania ksiąg i dokumentów oraz pięcioletni okres przedawnienia zobowiązań podatkowych.

## Deklaracje ZUS przez Płatnik elektroniczny

[Ustawa o systemie ubezpieczeń społecznych](https://isap.sejm.gov.pl/) nakłada obowiązek miesięcznej deklaracji ZUS DRA wraz z imiennymi raportami: o należnych składkach (RCA), o wypłaconych świadczeniach (RZA), o przerwach (RPA) oraz dla PPK (RIA). Deklarację DRA składa się do 15 dnia następnego miesiąca, a roczną informację dla ubezpieczonego - do końca lutego.

Raportowanie odbywa się obowiązkowo przez Płatnik elektroniczny lub e-ZUS PUE, z podpisem kwalifikowanym. Składka zdrowotna 9 procent jest potrącana przez płatnika i rozliczana za pośrednictwem ZUS wraz z deklaracją DRA.

Ustawa o PPK wymaga raportowania do PFR i kwartalnego rozliczania automatycznego zapisu, ze składką 2,5-4,5 procent i roczną dotacją Skarbu Państwa 240 zł; pierwszą składkę odprowadza się w 7 dni roboczych po naliczeniu wynagrodzenia. Pracownicze programy emerytalne oraz konta IKE i IKZE podlegają kwartalnemu raportowaniu do KNF.

Przy pracownikach delegowanych dochodzą obowiązki transgraniczne: raportowanie w systemie EESSI, zaświadczenie A1 o właściwym ustawodawstwie oraz umowy o unikaniu podwójnego opodatkowania.

## Ochrona danych i konsultacje z Radą Pracowników

Dane deklaracji podatkowych i ubezpieczeniowych są szczególnie wrażliwe: wynagrodzenie, premie, klasa podatkowa, dni chorobowe, niepełnosprawność, zajęcie komornicze czy obowiązek alimentacyjny. Podlegają one ochronie danych zatrudnienia z RODO art. 88 oraz krajowej ustawie o ochronie danych osobowych.

Agent stosuje zasadę Privacy by Design z minimalnym zakresem danych, środki bezpieczeństwa z szyfrowaniem w spoczynku i w tranzycie, ocenę DPIA przy szerokim przetwarzaniu danych wrażliwych, umowy powierzenia z dostawcami oraz plan usuwania po upływie terminu przechowywania.

Ustawa o sygnalistach chroni zgłaszających nieprawidłowości podatkowe lub zaniżanie składek ZUS - nakłada wewnętrzne kanały zgłoszeń od 50 pracowników i zewnętrzne do RPO, chroni przed odwetem i daje prawo do odszkodowania.

Wprowadzenie systemu IT ze śladem audytowym wymaga konsultacji z Radą Pracowników i związkami zawodowymi, z uzgodnieniem planu uprawnień, cyklu życia danych, ich usuwania oraz dostępu Rady Pracowników do śladu audytowego. W razie braku porozumienia stosuje się procedurę mediacji PIP lub drogę sądową.

## Współpraca z agentami przetwarzania, księgowania i raportowania płac

Tax-Social-Insurance-Agent jest osadzony w pipeline wyspecjalizowanych agentów HR. [Payroll-Processing-Agent](/pl/katalog-agentow-hr/payroll-processing-agent/) wykonuje pełne wyliczenie brutto-netto wraz ze składkami, które jest danymi wejściowymi dla tego agenta. [Payroll-Accounting-Agent](/pl/katalog-agentow-hr/payroll-accounting-agent/) tworzy księgowania z gotowej listy płac, a [Payroll-Reporting-Agent](/pl/katalog-agentow-hr/payroll-reporting-agent/) - roczne raporty PIT i GUS. [Payroll-Tax-Agent](/pl/katalog-agentow-finance/payroll-tax-agent/) weryfikuje zgodność rozliczeń podatkowych, [Compensation-Benchmarking-Agent](/pl/katalog-agentow-hr/compensation-benchmarking-agent/) dostarcza widełek wynagrodzeniowych, a [Pensions-Calculation-Agent](/pl/katalog-agentow-hr/pensions-calculation-agent/) wykonuje obliczenia PPK, PPE oraz kont IKE i IKZE. [Audit-Compliance-Agent](/pl/katalog-agentow-hr/audit-compliance-agent/) weryfikuje zgodność z krajowymi standardami rachunkowości, a [HR-Document-Management-Agent](/pl/katalog-agentow-hr/hr-document-management-agent/) archiwizuje deklaracje PIT i ZUS oraz zaświadczenia pracownicze.

## Na pierwszy rzut oka

- **Klasyfikacja**: wsparcie compliance, poza reżimem wysokiego ryzyka EU AI Act (reguły deterministyczne)
- **Kotwice zgodności**: ustawa o PIT i Ordynacja podatkowa, ustawa o systemie ubezpieczeń społecznych, przepisy o składce zdrowotnej i PPK, prawo pracy, RODO art. 88 oraz ustawa o sygnalistach
- **Przechowywanie**: 5 lat z prawa pracy i Ordynacji podatkowej oraz 10 lat dla dokumentów korporacyjnych z KSH
- **Współdecydowanie**: obowiązkowe konsultacje z Radą Pracowników i związkami zawodowymi
- **Sankcje**: kontrola KAS i wymiar szacunkowy, odpowiedzialność karna skarbowa do 5 lat pozbawienia wolności, sankcje administracyjne i odsetki ZUS, zastrzeżenie audytora oraz sankcja UODO do 4 procent obrotu grupy
- **Obowiązek audytu**: kontrola podatkowa KAS, kontrola ZUS oraz weryfikacja biegłego rewidenta
- **Współpraca**: agenci przetwarzania, księgowania i raportowania płac, obliczeń emerytalnych, benchmarkingu wynagrodzeń oraz zarządzania dokumentami

### Rozdział decydentów Tax-Social-Insurance

| Krok | Decydent | Uzasadnienie |
|------|----------|--------------|
| Generacja PIT-11 | R | tabela rubrykowa Ustawa o PIT determinista |
| Generacja PIT-4R | R | agregacja miesięczna Ustawa o PIT art. 38 determinista |
| Generacja PIT-8AR | R | zryczałtowany podatek do 200 PLN determinista |
| Generacja IFT-1/IFT-2 | R | Ustawa o pracownikach delegowanych + EESSI determinista |
| ZUS DRA + ZUS RCA + ZUS RZA + ZUS RPA | R | layout ZUS Ustawa 13.10.1998 + Płatnik elektroniczny determinista |
| ZUS RIA dla PPK + integracja PFR | R | Ustawa o PPK 4.10.2018 + termin 7 dni roboczych determinista |
| Składka zdrowotna 9 procent NFZ | R | Ustawa o świadczeniach zdrowotnej art. 81 determinista |
| Wystawianie zaświadczeń pracowniczych | R | KP art. 94 pkt 9b + termin 7 dni od wniosku determinista |
| Monitorowanie terminów płatnościowych | R | kalendarz terminów + powiadomienia 14+7+3+1 dzień determinista |
| Wykrywanie anomalii deklaracyjnych | A | ML-Anomalie-Detection z walidacją człowieka |
| Główny Księgowy zatwierdza | H | zasada czterech oczu KSR audit-trail obowiązkowa |
| Wysyłanie KAS/ZUS/NFZ/PFR/KNF | R | sygnatura kwalifikowana DNIe determinista |
| 5-letni okres + RODO art. 17 | R | Ordynacja podatkowa art. 86 + lifecycle determinista |
| Ustawa o sygnalistach 14.06.2024 | H | RPO obowiązkowe |

--- Time Attendance Agent ---
> Walidacja ewidencji czasu pracy zgodna z KP art. 128-156 i 149, wyrokiem TSUE C-55/18 CCOO i Dyrektywą 2003/88/WE - wyliczenie nadgodzin 50/100 procent i wykrywanie anomalii.

Każdego ranka systemy RCP rejestrują tysiące zdarzeń. W zakładzie z 2 000 pracowników to średnio 8 000 odbić dziennie - wejście rano, wyjście na przerwę, powrót, wyjście końcowe oraz dodatkowe rejestracje przy nadgodzinach. Każde odbicie uruchamia kaskadę: walidacja kompletności pary wejście-wyjście, klasyfikacja typu czasu pracy (normalny / nadgodziny / nocne / niedzielne), wyliczenie odpoczynku 11 godzin z KP art. 132 do następnego wejścia, walidacja 48-godzinnego limitu tygodniowego z Dyrektywy 2003/88/WE, wyliczenie dodatków KP art. 151-1+151-8.

Wyrok Trybunału Sprawiedliwości Unii Europejskiej z 14.05.2019 w sprawie C-55/18 CCOO Federación de Servicios de Comisiones Obreras kontra Deutsche Bank ustanowił obowiązek pracodawcy zapewnienia obiektywnego, niezawodnego i dostępnego systemu ewidencji rzeczywistego czasu pracy każdego dnia każdego pracownika. Polska implementuje obowiązek przez Kodeks Pracy art. 149. Problem nie tkwi w pojedynczym zdarzeniu RCP - tkwi w wolumenie 8 000 odbić dziennie przy zerowej tolerancji błędu KP art. 149 lub naruszenia odpoczynku KP art. 132.

## Ewidencja czasu pracy jako obowiązek po wyroku TSUE C-55/18 CCOO

Wyrok TSUE C-55/18 CCOO z 14.05.2019 zakończył ery papierowych list obecności. Trybunał uznał, że bez obiektywnego, niezawodnego i dostępnego systemu ewidencji rzeczywistego czasu pracy pracownik nie ma realnych środków do dochodzenia praw z Dyrektywy 2003/88/WE - maksymalny tygodniowy czas pracy 48 godzin, minimalny odpoczynek dobowy 11 godzin, minimalny odpoczynek tygodniowy 35 godzin.

Polska implementuje przez Kodeks Pracy art. 149: obowiązek prowadzenia ewidencji czasu pracy każdego pracownika z zakresem - liczba przepracowanych godzin, godziny rozpoczęcia i zakończenia pracy, godziny pracy w niedziele i święta, w nocy, w godzinach nadliczbowych, w dni wolne od pracy.

Agent integruje się z urządzeniami RCP - terminale biometryczne, czytniki kart RFID, mobile apps Microsoft Teams - przez API. Każde zdarzenie wejścia/wyjścia z RFC 3161 znacznikiem czasu, identyfikatorem pracownika (PESEL hash), lokalizacją zakładu pracy. Niezmienne, kryptograficznie podpisane, dostępne dla pracownika przez self-service portal i dla PIP na żądanie kontroli.

Standardowa integracja dla polskich ERP (Comarch RCP, Symfonia RCP, enova RCP, WAPRO RCP) i specjalistycznych workforce management (ATOSS, Kronos). Cykliczne pobieranie w czasie rzeczywistym, automatyczna walidacja kompletności (PESEL, identyfikator urządzenia, lokalizacja), powiązanie z rekordem na podstawie PESEL hash.

## Czas pracy, odpoczynek i nadgodziny według KP art. 128-156

Kodeks Pracy art. 128 definiuje czas pracy jako czas pozostawania pracownika w dyspozycji pracodawcy - gotowość do wykonywania pracy zaliczana do czasu pracy. KP art. 129 ustanawia wymiar 8 godzin na dobę i przeciętnie 40 godzin w przeciętnie pięciodniowym tygodniu pracy w okresie rozliczeniowym 4 miesięcy (z wydłużeniem do 12 miesięcy układem zbiorowym).

Odpoczynek dobowy z KP art. 132 to nieprzerwane co najmniej 11 godzin między dniami pracy. Odpoczynek tygodniowy z KP art. 133 to nieprzerwane co najmniej 35 godzin (24 + 11 dobowych). Naruszenie odpoczynku jest jednym z najczęstszych źródeł skarg do PIP - typowe scenariusze: zmiany zmianowe ze zbyt krótkim odstępem, nadgodziny przedłużające pracę poza dopuszczalny limit, harmonogramy w pracy wielozmianowej.

Agent waliduje deterministycznie:

```
Wejście RCP T+1
    |
    +-- Czas od ostatniego wyjścia T:
    |       |
    |       <11h: BLOKADA + flaga do kierownika
    |       |
    |       >=11h: kontynuacja walidacji
    |
    +-- Tygodniowa kumulacja:
    |       |
    |       <48h: kontynuacja
    |       |
    |       =>48h: BLOKADA nadgodzin
    |
    +-- Tygodniowy odpoczynek:
            |
            <35h w oknie 7 dni: flaga do HR
```

Nadgodziny z KP art. 151 są dopuszczalne do 150 godzin w roku kalendarzowym (wydłużenie do 416 godzin układem zbiorowym lub regulaminem z KP art. 104). Dodatki z KP art. 151-1: 50 procent stawki godzinowej za pracę w dni powszednie i nocy, 100 procent za pracę w niedziele, święta i dni wolne wynikające z pięciodniowego tygodnia pracy. Alternatywą jest udzielenie czasu wolnego z KP art. 151-2.

Praca w porze nocnej między 21:00 a 7:00 z KP art. 151-7 generuje dodatek 20 procent stawki godzinowej minimalnego wynagrodzenia z KP art. 151-8 (UWAGA: nie stawki godzinowej pracownika, tylko corocznie aktualizowanej kwoty z Ustawy o minimalnym wynagrodzeniu z 10.10.2002, od 1.01.2026 około 4 666 zł brutto, stawka godzinowa około 30 zł).

## Układy zbiorowe, praca nocna i niedzielna

Układ zbiorowy negocjowany z związkami zawodowymi z Ustawy z 23.05.1991 art. 25 i regulamin pracy zatwierdzony zgodnie z KP art. 104 z konsultacją Rady Pracowników z Ustawy z 4.07.2006 art. 14 (termin 14-30 dni, dla pracodawców 50+ pracowników) określają polityki czasu pracy specyficzne dla zakładu - wyższe dodatki nadgodzinowe ponad ustawowe minimum, dodatki za pracę zmianową, premie za dyspozycyjność.

Agent waliduje rzeczywisty czas pracy z harmonogramem zatwierdzonym z układu zbiorowego. Istotne odchylenia (np. systematyczne nadgodziny powyżej limitu układu, brak rotacji zmianowej zgodnie z planem) są flagowane do Specjalisty ds. Czasu Pracy.

Praca w niedziele i święta z KP art. 151-9+151-10+151-11+151-12 jest dopuszczalna tylko przy ruchu ciągłym, w pracy zmianowej, transporcie, służbie zdrowia. Rekompensata przez czas wolny w okresie 6-tygodniowym z KP art. 151-11 lub 100-procentowy dodatek z KP art. 151-1.

Zakaz nadgodzin dla kobiet w ciąży i karmiących z KP art. 178+178-1 jest absolutny - agent blokuje próbę przydzielenia, niezależnie od zgody pracownicy. Nadto zakaz pracy w nocy, pracy w niedziele i święta w tych okresach. Naruszenie generuje nieważność polecenia, odszkodowanie z KP art. 18-3d (nie niższe niż minimalne wynagrodzenie).

## Ochrona danych pracowniczych i konsultacja z Radą Pracowników

Dane czasu pracy są danymi pracowniczymi z RODO art. 88 (przetwarzanie danych pracowniczych w kontekście zatrudnienia) z krajowym doprecyzowaniem z Ustawy o ochronie danych osobowych z 10.05.2018. Konstytucja RP art. 47 (prywatność) i art. 51 (autonomia informacyjna) wprowadzają fundamentalną ochronę.

Ustawa z 10.05.2018 reguluje szczegółowo monitoring pracy: art. 22 monitoring wizyjny dopuszczalny tylko z konsultacją związkową z Ustawy z 23.05.1991 art. 25 i regulaminem pracy z KP art. 104, art. 23 zakaz kontroli korespondencji prywatnej, art. 24 ograniczenia monitoringu lokalizacji.

Agent egzekwuje ochronę przez wielowarstwową architekturę:

- zasada minimalizacji - tylko dane konieczne dla ewidencji z KP art. 149 (wejście/wyjście z RFC 3161 znacznikiem czasu, lokalizacja zakładu pracy, identyfikator pracownika PESEL hash)
- bez nieuzasadnionego monitoringu czynności (klawiszologia, screenshots, śledzenie aktywności aplikacji)
- szyfrowanie at-rest AES-256-GCM
- dostępy RBAC ograniczone do Specjalisty ds. Czasu Pracy, Specjalisty ds. Wynagrodzeń, Inspektora Ochrony Danych, Kierownika Operacyjnego (tylko swoich pracowników)
- audit-trail RODO art. 32 z RFC 3161 znacznikiem czasu dla każdego dostępu
- self-service portal pracownika z dostępem do własnej ewidencji - prawo dostępu z RODO art. 15

Polityka monitoringu czasu pracy wymaga konsultacji Rady Pracowników z Ustawy z 4.07.2006 art. 14 (termin 14-30 dni, dla pracodawców 50+ pracowników) i konsultacji ze związkami zawodowymi z Ustawy z 23.05.1991 art. 25 dla istotnych zmian.

Naruszenie RODO art. 88 (monitoring bez konsultacji, niedozwolony zakres) generuje sankcję UODO do 4 procent obrotu lub 20 milionów EUR. Sygnaliści zgłaszający fałszowanie ewidencji lub niewypłacenie nadgodzin otrzymują 24-miesięczną ochronę z Ustawy z 14.06.2024.

## Współpraca z agentami płac i nieobecności

Agent współpracuje z Payroll-Processing-Agent przez automatyczne przekazanie danych do rozliczenia miesięcznego - normalne wynagrodzenie, dodatki nadgodzinowe z KP art. 151-1 (50/100 procent), dodatki nocne z KP art. 151-8 (20 procent minimalnego wynagrodzenia), dodatki niedzielne; spójność z PIT-11 i ZUS RCA.

Z Sick-Leave-Processing-Agent koordynuje wynagrodzenie chorobowe z KP art. 92 - dni choroby nie liczą się jako czas pracy, agent pomija te dni w wyliczeniu nadgodzin. Z Leave-of-Absence-Agent koordynuje urlop wypoczynkowy z KP art. 152-167 - urlop nie biegnie podczas choroby z KP art. 165.

Cross-reference do HR-Document-Management-Agent dla archiwizacji ewidencji w segmencie B akt osobowych z Rozp. MRiPS z 10.12.2018, 5-letni okres z KP art. 94 pkt 9b. Self-service portal pracownika wspiera prawo dostępu z RODO art. 15 i obronę pracownika w sporach sądowych z prescription 3 lat z KP art. 291.

## Na pierwszy rzut oka

- 8 000 odbić RCP dziennie w zakładzie 2 000 pracowników, zerowa tolerancja błędu KP art. 149
- TSUE C-55/18 CCOO z 14.05.2019: obowiązek obiektywnego systemu ewidencji rzeczywistego czasu pracy
- Dyrektywa 2003/88/WE: maksymalnie 48 godzin tygodniowo łącznie z nadgodzinami w okresie rozliczeniowym 4 miesięcy
- KP art. 132+133: odpoczynek 11 godzin dobowy, 35 godzin tygodniowy
- KP art. 151-1: dodatek 50 procent w dni powszednie, 100 procent w niedziele i święta
- KP art. 151-8: dodatek 20 procent stawki godzinowej minimalnego wynagrodzenia za pracę nocną
- KP art. 178: zakaz nadgodzin, pracy w nocy, w niedziele i święta dla kobiet w ciąży
- RODO art. 88 z konsultacją Rady Pracowników z Ustawy z 4.07.2006 art. 14
- Sankcje PIP do 30 000 zł, UODO do 4 procent obrotu, AAI sygnalistów do 1 procent obrotu

### Rozdział decydentów Time-Attendance

| Decyzja                                | Decydent | Podstawa prawna                |
| -------------------------------------- | -------- | ------------------------------ |
| Pobranie surowych danych RCP           | Reguła   | KP art. 149 + TSUE C-55/18     |
| Walidacja kompletności rejestracji     | Reguła   | KP art. 149 + regulamin pracy  |
| Klasyfikacja typu czasu pracy          | Reguła   | KP art. 128-156                |
| Wyliczenie odpoczynku 11 / 35 godzin   | Reguła   | KP art. 132+133                |
| Walidacja 48-godzinnego limitu         | Reguła   | Dyrektywa 2003/88/WE           |
| Wyliczenie dodatków nadgodzinowych     | Reguła   | KP art. 151-1                  |
| Wyliczenie dodatku nocnego             | Reguła   | KP art. 151-8                  |
| Wykrywanie anomalii w rejestracji      | KI       | RODO art. 22                   |
| Walidacja zgodności z układem          | Reguła   | KP art. 104 + Ust. 23.05.1991  |
| Walidacja zakazu nadgodzin dla ciąży   | Reguła   | KP art. 178+178-1              |
| Aktualizacja payroll                   | KI       | RODO art. 22                   |
| Generowanie raportów PIP/ZUS           | Reguła   | KP art. 149 + Płatnik          |
| Cross-reference do Payroll-Processing  | Reguła   | Standaryzowane API             |
| Archiwizacja w segmencie B             | Reguła   | KP art. 94 pkt 9b              |

## Co infrastruktura daje innym agentom

Architektura ochrony danych pracowniczych z RODO art. 88 (minimalizacja, AES-256-GCM, RBAC, self-service portal), integracji z urządzeniami RCP przez API z RFC 3161 znacznikiem czasu i walidacji regulacyjnych progów (odpoczynek 11 / 35 godzin, 48-godzinny limit) staje się szablonem dla Workforce-Planning-Agent (planowanie zmianowe), Travel-Time-Agent (czas podróży służbowej), Standby-Duty-Agent (dyżury).

Decision Logging zgodne z RODO art. 30+32, KP art. 94 pkt 9b i obowiązkiem ewidencji z KP art. 149 oraz TSUE C-55/18 CCOO buduje Audit Trail dla obrony przed kontrolą PIP, UODO, ZUS, KAS, AAI i audytem KIBR. Self-service portal pracownika wspiera prawo dostępu z RODO art. 15.

Time-Attendance-Agent dowodzi przy 8 000 odbiciach RCP dziennie i zerowej tolerancji błędu KP art. 149, że audytowalny workflow z zgodnością Dyrektywy 2003/88/WE, RODO art. 88, układów zbiorowych z Ustawy z 23.05.1991 i orzecznictwa TSUE C-55/18 CCOO jest możliwy.

--- Agent skuteczności szkoleń ---
> Pomiar skuteczności szkoleń: model Kirkpatricka, Phillips ROI, transfer wiedzy zgodne z Ustawą ZSK 22.12.2015, KP art. 102-103, Krajowym Funduszem Szkoleniowym i CSRD ESRS S1-13.

## Z budżetów szkoleniowych do udowodnionej skuteczności

Ten agent stosuje zasadę [Decision Layer](/pl/decision-layer/): każda decyzja jest oparta na regułach, wspomagana AI lub jawnie przypisana człowiekowi. Nie jest sklasyfikowany zgodnie z [EU AI Act 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) jako system wysokiego ryzyka, bo prowadzi pomiar na danych zagregowanych, bez decyzji o pojedynczych pracownikach. Podlega jednak obowiązkom zgodności wynikającym z przepisów o podnoszeniu kwalifikacji ([Kodeks Pracy](https://isap.sejm.gov.pl/) art. 102-103), Ustawy o ZSK z 22.12.2015, RODO oraz raportowania CSRD ESRS S1-13 - to ostatnie wymaga weryfikacji audytora KIBR od 250 pracowników.

Typowy program szkoleniowy w średnim polskim przedsiębiorstwie obejmuje kwartalnie setki do tysięcy uczestników, a dane pochodzą z LMS, ocen wyników pracy, ankiet po szkoleniu oraz raportów obserwacyjnych. Ręczne zestawienia trwają tygodnie i łatwo o błąd interpretacyjny. Agent liczy KPI w sekundach na podstawie modeli Kirkpatricka i Phillips ROI, korzystając z integracji z LMS oraz mapowania kompetencji na poziomy EQR i ZSK.

Problem nie leży w wolumenie danych, lecz w warunkach zwolnienia z RODO: minimalizacji danych, ograniczeniu celu i zakazie decyzji o pojedynczych pracownikach. Interpretację strategiczną waliduje L&D Manager, wyniki trafiają do raportowania zarządczego, a poprawność rozliczeń bada audytor KIBR metodą prób zgodnie z KSR.

## Pomiar skuteczności: modele Kirkpatricka i Phillips ROI

Czteropoziomowy model Kirkpatricka jest uznanym standardem pomiaru skuteczności szkoleń od 1959 roku. Poziom 1 (Reakcja) mierzy satysfakcję uczestników, między innymi wskaźnikiem NPS i analizą postrzeganej trafności. Poziom 2 (Uczenie się) mierzy przyrost wiedzy na podstawie różnicy między testem przed i po szkoleniu oraz ocen pobieranych z LMS, odniesionych do kompetencji ESCO i poziomów EQR.

Poziom 3 (Zachowanie) szacuje transfer wiedzy z raportów obserwacyjnych, oceny 360 stopni i ocen przełożonych, wspierany analizą korelacji i regresją wieloczynnikową. Wynik modelu jest wskaźnikiem, nie końcową decyzją. Poziom 4 (Wyniki) mierzy wpływ na biznes - poprawę KPI i wzrost produktywności - zgodnie z Ustawą o rachunkowości i standardami KSR.

Phillips ROI dodaje poziom piąty, czyli kalkulację finansową według wzoru (korzyści netto programu / koszty programu) x 100. Korzyści netto obejmują wzrost produktywności, niższą rotację i mniej błędów; koszty - projekt, realizację, materiały i czas uczestników. Interpretację strategiczną walidują L&D Manager i CHRO; nie powstaje automatyczna decyzja, bo zwolnienie wynika z agregacji danych (RODO art. 22).

## Podstawy prawne: ZSK, podnoszenie kwalifikacji i Krajowy Fundusz Szkoleniowy

[Ustawa o Zintegrowanym Systemie Kwalifikacji z 22.12.2015](https://isap.sejm.gov.pl/) (Dz.U. 2016 poz. 64) wprowadziła Zintegrowany System Kwalifikacji (ZSK) z ośmiopoziomową Polską Ramą Kwalifikacji, Zintegrowanym Rejestrem Kwalifikacji oraz standardami walidacji i certyfikacji efektów uczenia się; nadzór merytoryczny sprawuje IBE. System jest zharmonizowany z Europejskimi Ramami Kwalifikacji (EQR) i ECVET.

Kodeks Pracy art. 102 nakłada na pracodawcę obowiązek ułatwiania pracownikom podnoszenia kwalifikacji. Art. 103 określa prawa pracownika: urlop szkoleniowy (6 dni na egzaminy, 21 dni na egzamin maturalny i 21 dni na egzamin potwierdzający kwalifikacje), zwolnienie z części dnia pracy z zachowaniem wynagrodzenia, świadczenia dodatkowe (zwrot kosztów przejazdu, zakwaterowania, wyżywienia, podręczników i opłat egzaminacyjnych), pisemną umowę o podnoszenie kwalifikacji oraz zwrot kosztów przy rozwiązaniu umowy.

Krajowy Fundusz Szkoleniowy to ważny instrument polityki rynku pracy oparty na Ustawie o promocji zatrudnienia z 20.04.2004. Współfinansuje szkolenia pracowników i pracodawców, ale nakłada obowiązek raportowania efektów, a przy ich nieosiągnięciu nakazuje zwrot dofinansowania. Środkami dysponują MRiPS oraz wojewódzkie i powiatowe urzędy pracy.

IBE sprawuje nadzór merytoryczny nad ZSK, Zintegrowanym Rejestrem Kwalifikacji oraz standardami walidacji i certyfikacji. Obszar kształcenia ustawicznego regulują dodatkowo Ustawa o systemie oświaty i Prawo oświatowe, nadzorowane przez MEN.

## Taksonomie kompetencji i raportowanie CSRD ESRS S1-13

[ESCO](https://esco.ec.europa.eu/) (Komisja Europejska) klasyfikuje ponad 13 000 kompetencji i ponad 3 000 zawodów. Stanowi podstawę mapowania kompetencji i analizy luk, zharmonizowaną z EQR oraz Polską Ramą Kwalifikacji.

Europejskie Ramy Kwalifikacji (EQR, Zalecenie 2008/C 111/01) wprowadziły osiem poziomów oraz ECVET i EUROPASS. Każdy poziom opisują efekty uczenia się: wiedza, umiejętności oraz odpowiedzialność i autonomia. EQR jest odniesieniem dla polskiej ramy ZSK.

Raportowanie CSRD (Dyrektywa UE 2022/2464) ze standardem ESRS S1-13 wymaga obowiązkowej weryfikacji audytora KIBR od 250 pracowników, z wejściem w życie w latach 2024-2026. Kluczowe metryki to średnia liczba godzin szkoleń na pracownika rocznie (w podziale na płeć i kategorię) oraz odsetek pracowników objętych rozmowami oceniającymi i rozwojowymi. Uzupełniają je standardy ESRS S1-1 i S1-2 dotyczące równego dostępu do szkoleń.

Kodeks Spółek Handlowych nakłada 10-letni okres archiwizacji dokumentów korporacyjnych (art. 84) oraz odpowiedzialność Zarządu i Rady Nadzorczej; spółki notowane raportują dodatkowo w ramach WIG-ESG GPW.

Statystykę kształcenia ustawicznego agreguje GUS w badaniach BAEL i CVTS na podstawie Ustawy o statystyce publicznej, z przekazaniem danych do Eurostatu.

## Ochrona danych i konsultacja z Radą Pracowników

Dane pomiaru skuteczności szkoleń obejmują agregowane dane wrażliwe: wyniki testów, przyrost wiedzy, oceny, raporty obserwacyjne i metryki zmiany zachowania. Podlegają RODO (art. 9 i 88) oraz Ustawie o ochronie danych osobowych z 10.05.2018.

Agent stosuje zasady prywatności w fazie projektowania (RODO art. 25), środki bezpieczeństwa z szyfrowaniem (art. 32), ocenę skutków przy szerokim przetwarzaniu danych LMS (art. 35), umowy powierzenia oraz plan usuwania danych (art. 17). Decyzje o pojedynczych pracownikach są wykluczone (art. 22).

Ustawa o Radzie Pracowników z 7.04.2006 nakłada od 50 pracowników obowiązek informowania i konsultowania planów szkoleniowych, a za jego niedopełnienie przewiduje sankcje; przy istotnych zmianach dochodzi konsultacja ze związkami zawodowymi.

Wytyczne EDPB 1/2024 potwierdzają zwolnienie dla pomiaru zagregowanego. Sygnalistów zgłaszających nieprawidłowości w szkoleniach lub nieuprawnione wykorzystanie KFS chroni Ustawa z 14.06.2024. Ustawa Antydyskryminacyjna z 3.12.2010 zakazuje dyskryminacji w dostępie do szkoleń, przenosi ciężar dowodu na pracodawcę i przewiduje odszkodowanie.

## Miejsce agenta w pipelinie L&D

Agent działa w łańcuchu agentów L&D. [Skills-Career-Profile-Agent](/pl/katalog-agentow-hr/skills-career-profile-agent/) dostarcza mapowanie kompetencji. [Performance-Review-Documentation-Agent](/pl/katalog-agentow-hr/performance-review-documentation-agent/) przekazuje dane o wynikach pracy do korelacji na poziomach 3 i 4 modelu Kirkpatricka. [Learning-Path-Recommendation-Agent](/pl/katalog-agentow-hr/learning-path-recommendation-agent/) korzysta z wyliczonych KPI. [Talent-Acquisition-Agent](/pl/katalog-agentow-hr/talent-acquisition-agent/) dostarcza koszt rekrutacji. [Strategic-HR-Analytics-Agent](/pl/katalog-agentow-hr/strategic-hr-analytics-agent/) ponownie wykorzystuje moduły dotyczące różnorodności. [Compensation-Benchmarking-Agent](/pl/katalog-agentow-hr/compensation-benchmarking-agent/) podaje widełki wynagrodzeń do wyliczenia ROI. [Audit-Compliance-Agent](/pl/katalog-agentow-hr/audit-compliance-agent/) weryfikuje zgodność z KSR i wymogami KIBR, a [Workforce-Planning-Agent](/pl/katalog-agentow-hr/workforce-planning-agent/) korzysta z analizy luk kompetencyjnych.

## Na pierwszy rzut oka

- **Klasyfikacja**: pomiar na danych zagregowanych, poza wysokim ryzykiem EU AI Act
- **Podstawy zgodności**: przepisy o podnoszeniu kwalifikacji (KP art. 102-103), Ustawa o ZSK z 22.12.2015, taksonomie EQR i ESCO, RODO, Ustawa o Radzie Pracowników, Ustawa o rachunkowości i KSR, raportowanie CSRD ESRS S1-13 oraz Krajowy Fundusz Szkoleniowy
- **Przechowywanie**: 10 lat dla dokumentów korporacyjnych (KSH art. 84), 5 lat dla dokumentacji pracowniczej (KP art. 94 pkt 9b) i ksiąg (Ustawa o rachunkowości)
- **Współdecydowanie**: konsultacje z Radą Pracowników i związkami zawodowymi obowiązkowe od 50 pracowników
- **Sankcje**: UODO do 4 procent obrotu grupy, PIP od 1 000 do 30 000 PLN, zwrot dofinansowania KFS, odszkodowanie za dyskryminację, odpowiedzialność Zarządu i zastrzeżenie audytora w raporcie CSRD
- **Obowiązek audytu**: weryfikacja audytora KIBR od 250 pracowników w ramach CSRD ESRS S1-13
- **Powiązania**: profile kompetencyjne, oceny pracownicze, rekomendacje ścieżek nauki, rekrutacja, analityka strategiczna, planowanie zatrudnienia i benchmarking wynagrodzeń

### Rozdział decydentów Training-Effectiveness

| Krok | Decydent | Uzasadnienie |
|------|----------|--------------|
| Kirkpatrick poziom 1 (Reakcja) | R | ankiety satysfakcji i NPS, deterministycznie |
| Kirkpatrick poziom 2 (Uczenie się) | R | przyrost wiedzy z testów w LMS, deterministycznie |
| Kirkpatrick poziom 3 (Zachowanie) | A | analiza korelacji z walidacją L&D Managera |
| Kirkpatrick poziom 4 (Wyniki) | R | zmiana KPI i wskaźniki wyników, deterministycznie |
| Phillips ROI poziom 5 | R | wzór (korzyści netto / koszty) x 100 wg KSR |
| Integracja z LMS | R | standardy LMS i mapowanie EQR/ZSK, deterministycznie |
| Walidacja efektów uczenia się (ZSK) | R | standardy walidacji wg Polskiej Ramy Kwalifikacji |
| Krajowy Fundusz Szkoleniowy | R | raportowanie efektów do urzędów pracy, deterministycznie |
| Metryki CSRD ESRS S1-13 | R | standardy EFRAG, deterministycznie |
| Raportowanie GUS (BAEL, CVTS) | R | wg Ustawy o statystyce publicznej, deterministycznie |
| Konsultacja z Radą Pracowników | H | obowiązkowa od 50 pracowników |
| Raport zarządczy L&D Managera i CHRO | H | nadzór Rady Nadzorczej (KSH art. 382) |
| Pomiar zagregowany wg RODO | R | zgodnie z wytycznymi EDPB 1/2024 |
| Powiązanie z innymi agentami | R | przekazanie danych, deterministycznie |

--- Agent analizy potrzeb szkoleniowych ---
> Analiza potrzeb szkoleniowych: identyfikacja luk kompetencji, Skills Gap Analysis, priorytetyzacja inwestycji zgodne z Ustawą ZSK 22.12.2015, KP art. 102-103, ESCO, EQR i CSRD ESRS S1-13.

## Analiza potrzeb szkoleniowych zamiast chaosu szkoleniowego

Ten agent stosuje zasadę [Decision Layer](/pl/decision-layer/): każda decyzja jest oparta na regułach, wspomagana AI lub jawnie przypisana człowiekowi. Nie jest sklasyfikowany zgodnie z [EU AI Act 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) jako system wysokiego ryzyka, bo prowadzi analizę na danych zagregowanych, bez decyzji o pojedynczych pracownikach. Podlega jednak obowiązkom zgodności wynikającym z przepisów o podnoszeniu kwalifikacji ([Kodeks Pracy](https://isap.sejm.gov.pl/) art. 102-103), Ustawy o ZSK z 22.12.2015, RODO oraz raportowania CSRD ESRS S1-13 - to ostatnie wymaga weryfikacji audytora KIBR od 250 pracowników.

Typowa firma średniej wielkości w Polsce zarządza setkami do tysięcy pracowników o różnorodnych profilach kompetencyjnych. Decyzje o tym, które szkolenia priorytetyzować, zapadają często intuicyjnie, bez systematycznej analizy luk. Skutkiem jest nieefektywny podział budżetu szkoleniowego i niewypełnione kluczowe luki.

Agent wyznacza luki kompetencyjne w sekundach: porównuje stan aktualny ze stanem wymaganym, korzystając z mapowania kompetencji ESCO na poziomy EQR i Polskiej Ramy Kwalifikacji, koreluje je z wynikami ocen pracowniczych i celami strategicznymi, a następnie priorytetyzuje według wzoru (znaczenie strategiczne + dotkliwość luki + oczekiwany ROI) / koszt.

Problem nie leży w wolumenie danych, lecz w warunkach zwolnienia z RODO: minimalizacji danych, ograniczeniu celu i zakazie decyzji o pojedynczych pracownikach. Interpretację strategiczną waliduje L&D Manager, a wyniki trafiają do raportowania zarządczego.

## Analiza luk kompetencyjnych w oparciu o taksonomie ESCO i ZSK

Analiza luk kompetencyjnych stanowi rdzeń pracy agenta i opiera się na trzech filarach. Pierwszy to ocena stanu aktualnego - poziom kompetencji pracowników mierzony samooceną, oceną przełożonego, informacją zwrotną 360 stopni, wynikami testów z LMS oraz posiadanymi certyfikatami ZSK. Drugi to definicja stanu wymaganego, wynikająca z opisów stanowisk, celów biznesowych i prognozy zapotrzebowania na kompetencje. Trzeci to wyliczenie luki jako różnicy między stanem wymaganym a aktualnym wraz z priorytetyzacją.

[ESCO](https://esco.ec.europa.eu/) klasyfikuje ponad 13 000 kompetencji i ponad 3 000 zawodów, opisując każdą kompetencję przez wiedzę, umiejętności oraz odpowiedzialność i autonomię. Jest zharmonizowane z Europejskimi Ramami Kwalifikacji (EQR, Zalecenie 2008/C 111/01) i ich ośmioma poziomami.

Polska Rama Kwalifikacji (ZSK), nadzorowana przez IBE, jest odniesiona do EQR. Każdy jej poziom opisują efekty uczenia się: wiedza, umiejętności oraz kompetencje społeczne.

Integracja z ocenami pracowniczymi dostarcza danych o lukach w KPI i wskaźnikach produktywności. Cele biznesowe są wiązane z wymaganymi kompetencjami za pomocą regresji wieloczynnikowej wspieranej uczeniem maszynowym, a wynik modelu pozostaje wskaźnikiem, nie końcową decyzją.

Priorytet liczy się według wzoru (znaczenie strategiczne + dotkliwość luki + oczekiwany ROI) / koszt, a koszt na uczestnika i prognozę ROI ustala się zgodnie z KSR i IAS 19. Interpretację strategiczną walidują L&D Manager i CHRO; nie powstaje automatyczna decyzja, bo zwolnienie wynika z agregacji danych (RODO art. 22).

## Podstawy prawne: podnoszenie kwalifikacji i Ustawa o ZSK

[Ustawa o Zintegrowanym Systemie Kwalifikacji z 22.12.2015](https://isap.sejm.gov.pl/) (Dz.U. 2016 poz. 64) wprowadziła ZSK z ośmiopoziomową Polską Ramą Kwalifikacji, Zintegrowanym Rejestrem Kwalifikacji oraz standardami walidacji i certyfikacji efektów uczenia się; system jest odniesiony do EQR i ECVET.

Kodeks Pracy art. 102 nakłada na pracodawcę obowiązek ułatwiania podnoszenia kwalifikacji. Art. 103 określa prawa pracownika: urlop szkoleniowy (6 dni na egzaminy i 21 dni na egzamin maturalny), zwolnienie z części dnia pracy z zachowaniem wynagrodzenia, świadczenia dodatkowe (zwrot kosztów przejazdu, zakwaterowania, wyżywienia, podręczników i opłat egzaminacyjnych), pisemną umowę oraz zwrot kosztów przy rozwiązaniu umowy.

Krajowy Fundusz Szkoleniowy to ważny instrument polityki rynku pracy oparty na Ustawie o promocji zatrudnienia z 20.04.2004. Współfinansuje szkolenia według corocznie aktualizowanych priorytetów, ale nakłada obowiązek raportowania efektów, a przy ich nieosiągnięciu nakazuje zwrot dofinansowania. Agent automatycznie mapuje zidentyfikowane luki na priorytety KFS, aby zoptymalizować dofinansowanie.

IBE sprawuje nadzór merytoryczny nad ZSK, Zintegrowanym Rejestrem Kwalifikacji oraz standardami walidacji i certyfikacji; obszar kształcenia ustawicznego regulują dodatkowo Ustawa o systemie oświaty i Prawo oświatowe nadzorowane przez MEN.

Raportowanie CSRD (Dyrektywa UE 2022/2464) ze standardem ESRS S1-13 wymaga obowiązkowej weryfikacji audytora KIBR od 250 pracowników. Kluczowe metryki to średnia liczba godzin szkoleń na pracownika rocznie (w podziale na płeć i kategorię) oraz odsetek pracowników objętych rozmowami oceniającymi; uzupełniają je standardy ESRS S1-1 i S1-2 dotyczące równego dostępu. Analiza luk kompetencyjnych dostarcza punktu odniesienia dla tego raportowania.

## Ochrona danych i konsultacja z Radą Pracowników

Dane analizy potrzeb szkoleniowych obejmują agregowane dane wrażliwe: profile kompetencyjne, wyniki ocen pracowniczych, oceny, informację zwrotną 360 stopni, certyfikaty ZSK i luki w KPI. Podlegają RODO (art. 9 i 88) oraz Ustawie o ochronie danych osobowych z 10.05.2018.

Agent stosuje zasady prywatności w fazie projektowania (RODO art. 25), środki bezpieczeństwa (art. 32), ocenę skutków przy szerokim przetwarzaniu danych kompetencyjnych (art. 35), umowy powierzenia oraz plan usuwania danych (art. 17). Decyzje o pojedynczych pracownikach są wykluczone (art. 22).

Ustawa o Radzie Pracowników z 7.04.2006 nakłada od 50 pracowników obowiązek informowania i konsultowania planów szkoleniowych, a za jego niedopełnienie przewiduje sankcje; przy istotnych zmianach dochodzi konsultacja ze związkami zawodowymi. W praktyce przed wdrożeniem systemu zawiera się porozumienie zakładowe o zakresie analizy, planie uprawnień, cyklu danych i dostępie do śladu audytowego.

Wytyczne EDPB 1/2024 potwierdzają zwolnienie dla analizy zagregowanej. Sygnalistów zgłaszających nieprawidłowości lub nieuprawnione wykorzystanie KFS chroni Ustawa z 14.06.2024. Ustawa Antydyskryminacyjna z 3.12.2010 zakazuje dyskryminacji w dostępie do szkoleń, przenosi ciężar dowodu na pracodawcę i przewiduje odszkodowanie - analiza luk musi być równa dla wszystkich kategorii pracowników (płeć, wiek, niepełnosprawność, narodowość).

Zidentyfikowane luki kompetencyjne zasilają też statystykę kształcenia ustawicznego: GUS agreguje je w badaniach BAEL i CVTS na podstawie Ustawy o statystyce publicznej i przekazuje do Eurostatu.

## Miejsce agenta w pipelinie L&D

Agent działa w łańcuchu agentów L&D. [Skills-Career-Profile-Agent](/pl/katalog-agentow-hr/skills-career-profile-agent/) dostarcza mapowanie kompetencji do oceny stanu aktualnego. [Performance-Review-Documentation-Agent](/pl/katalog-agentow-hr/performance-review-documentation-agent/) przekazuje dane o wynikach pracy do wykrycia luk w KPI. [Training-Effectiveness-Agent](/pl/katalog-agentow-hr/training-effectiveness-agent/) traktuje zidentyfikowane luki jako punkt odniesienia dla pomiaru skuteczności. [Learning-Path-Recommendation-Agent](/pl/katalog-agentow-hr/learning-path-recommendation-agent/) buduje na ich podstawie rekomendacje ścieżek nauki. [Workforce-Planning-Agent](/pl/katalog-agentow-hr/workforce-planning-agent/) korzysta z analizy luk w planowaniu zatrudnienia. [Talent-Acquisition-Agent](/pl/katalog-agentow-hr/talent-acquisition-agent/) dostarcza koszt rekrutacji. [Strategic-HR-Analytics-Agent](/pl/katalog-agentow-hr/strategic-hr-analytics-agent/) ponownie wykorzystuje moduły dotyczące różnorodności, a [Compensation-Benchmarking-Agent](/pl/katalog-agentow-hr/compensation-benchmarking-agent/) podaje widełki wynagrodzeń do prognozy ROI.

## Na pierwszy rzut oka

- **Klasyfikacja**: analiza na danych zagregowanych, poza wysokim ryzykiem EU AI Act
- **Podstawy zgodności**: przepisy o podnoszeniu kwalifikacji (KP art. 102-103), Ustawa o ZSK z 22.12.2015, taksonomie EQR i ESCO, RODO, Ustawa o Radzie Pracowników, Ustawa o rachunkowości i KSR, raportowanie CSRD ESRS S1-13 oraz Krajowy Fundusz Szkoleniowy
- **Przechowywanie**: 10 lat dla dokumentów korporacyjnych (KSH art. 84), 5 lat dla dokumentacji pracowniczej (KP art. 94 pkt 9b) i ksiąg (Ustawa o rachunkowości)
- **Współdecydowanie**: konsultacje z Radą Pracowników i związkami zawodowymi obowiązkowe od 50 pracowników
- **Sankcje**: UODO do 4 procent obrotu grupy, PIP od 1 000 do 30 000 PLN, zwrot dofinansowania KFS, odszkodowanie za dyskryminację, odpowiedzialność Zarządu i zastrzeżenie audytora w raporcie CSRD
- **Obowiązek audytu**: weryfikacja audytora KIBR od 250 pracowników w ramach CSRD ESRS S1-13
- **Powiązania**: profile kompetencyjne, oceny pracownicze, pomiar skuteczności szkoleń, rekomendacje ścieżek nauki, planowanie zatrudnienia, rekrutacja, analityka strategiczna i benchmarking wynagrodzeń

### Rozdział decydentów Training-Needs-Analysis

| Krok | Decydent | Uzasadnienie |
|------|----------|--------------|
| Identyfikacja luk kompetencyjnych | R | różnica stanu wymaganego i aktualnego wg ESCO i ZSK |
| Analiza danych o wynikach pracy | R | różnica ocen i wskaźniki produktywności, deterministycznie |
| Mapowanie celów biznesowych | A | analiza korelacji z walidacją L&D Managera |
| Priorytetyzacja inwestycji szkoleniowych | R | wzór (znaczenie + dotkliwość + ROI) / koszt |
| Integracja z LMS | R | standardy LMS i poziomy ZSK, deterministycznie |
| Walidacja efektów uczenia się (ZSK) | R | standardy walidacji wg Polskiej Ramy Kwalifikacji |
| Mapowanie luk na priorytety KFS | R | wg rocznych priorytetów funduszu, deterministycznie |
| Metryki CSRD ESRS S1-13 | R | standardy EFRAG, deterministycznie |
| Raportowanie GUS (BAEL, CVTS) | R | wg Ustawy o statystyce publicznej, deterministycznie |
| Konsultacja z Radą Pracowników | H | obowiązkowa od 50 pracowników |
| Raport zarządczy L&D Managera i CHRO | H | nadzór Rady Nadzorczej (KSH art. 382) |
| Powiązanie z innymi agentami | R | przekazanie danych, deterministycznie |
| Cykl życia danych (archiwizacja) | R | 10-letni okres przechowywania, deterministycznie |

--- Transfer & Relocation Agent ---
> Przeniesienia wewnętrzne i delegacje międzynarodowe zgodne z KP art. 42, Dyrektywą 96/71/WE, Rozp. 883/2004 (A1) i Ustawą o cudzoziemcach - mapowanie dokumentów, terminów i DBA.

Polska firma z 1500 pracownikami obsługuje typowo 50-150 transferów rocznie - 30-40% przeniesień wewnętrznych, 25-35% delegacji krótkoterminowych KP art. 77-5, 20-25% delegacji długoterminowych z aneksem art. 42 KP, 10-15% delegacji EU z Dyrektywą 96/71/WE, 5-10% relokacji międzykontynentalnych. Każdy transfer generuje 30-50 zadań w 6 systemach (HRIS, payroll, Wojewoda, ZUS Płatnik, NFZ, KAS) z 4 zespołami (HR, Prawo, Finanse, Imigracja). W praktyce jeden wątek jest zawsze zgubiony - brak A1 generuje podwójne ubezpieczenie, opóźnione zezwolenie zatrzymuje Go-Live na 90+ dni, błędne wypowiedzenie zmieniające daje pracownikowi prawo odmowy z odprawą.

## Przeniesienie i delegacja międzynarodowa jako pułapka zgodności w HR

Transfer pracownika to kompleksowy projekt regulatoryjny na styku 6 warstw prawa: Kodeks Pracy (art. 42 zmiana umowy, art. 77-5 polecenie delegacji), Ustawa o pracownikach delegowanych z 10.06.2016 (Dyrektywa 96/71/WE 2018/957), Ustawa o cudzoziemcach z 12.12.2013 (zezwolenie typ A/B/C/D/E/S, Niebieska Karta UE, ICT-Karta), Rozporządzenie 883/2004 EU (A1, EKUZ, S1), DBA umowy o unikaniu podwójnego opodatkowania (90+ państw), RODO art. 88 i art. 49.

Sądy pracy z prescription 3 lat z KP art. 291, PIP polska i państwa przyjmującego, Wojewoda Wydział Spraw Cudzoziemców, ZUS, NFZ, KAS i Straż Graniczna kontrolują firmę po dokumentach transferu - aneks, A1, kopia zezwolenia, certyfikat rezydencji. Brak jednego dokumentu w aktach segmentu B z 10-letnim okresem przechowywania z Ustawy o aktach osobowych z 1.10.2018 generuje brak dowodu w sporze.

System zarządzający transferami pochodzi z poprzedniej dekady - Excel z 200 transferami rocznie, aneks art. 42 wiszący w pętli zatwierdzeń, A1 wnioskowane do ZUS z terminem wygasającym 30 dni przed Go-Live. Pracownik leci do Niemiec bez A1, generując podwójne ubezpieczenie społeczne i sankcję ZAD do 500 000 EUR z MiLoG.

## Zmiana umowy i delegacja w UE: KP art. 42 oraz Ustawa o pracownikach delegowanych

Art. 42 KP wprowadza wypowiedzenie zmieniające jako instrument zmiany istotnych warunków umowy - miejsca pracy, stanowiska, wynagrodzenia. Orzecznictwo Sądu Najwyższego ustaliło kryteria istotności: dojazd przekraczający 2 godziny dziennie, degradacja, obniżenie wynagrodzenia powyżej 25 procent. Termin wypowiedzenia z art. 36 KP - 2 tygodnie/1 miesiąc/3 miesiące w zależności od rodzaju umowy. Pracownik ma prawo odmowy ze skutkiem rozwiązania umowy z odprawą. Konstytucja RP art. 52 stanowi fundament tego prawa.

Art. 77-5 reguluje polecenie delegacji do 3 miesięcy - zwrot kosztów podróży, noclegu, wyżywienia z Rozp. MPiPS z 29.01.2013 (dieta krajowa 38 zł, dieta zagraniczna 75-110 EUR), odpoczynek dobowy 11 godzin. Powyżej 3 miesięcy wymaga konsultacji ze związkami zawodowymi z Ustawy z 23.05.1991 art. 30 i zmiany umowy art. 42.

Ustawa o pracownikach delegowanych z 10.06.2016 implementuje Dyrektywę 96/71/WE 2018/957 - przy delegacji EU/EOG/Szwajcaria pracownik podlega warunkom państwa przyjmującego: Niemcy 12,82 EUR/h Mindestlohn 2025, Francja 11,88 EUR/h SMIC, Belgia minimum sektorowe. Długoterminowa delegacja powyżej 12 miesięcy generuje obowiązek pełnych warunków pracy państwa przyjmującego. Obowiązek zgłoszenia do PIP państwa przyjmującego (Niemcy ZAD, Francja SIPSI, Belgia BCEA) jest obowiązkowy - sankcje: Niemcy do 500 000 EUR z MiLoG, Francja do 4 000 EUR za pracownika.

## Zezwolenia na pracę: Ustawa o cudzoziemcach, Niebieska Karta UE i karta ICT

Ustawa o cudzoziemcach z 12.12.2013 reguluje zatrudnienie cudzoziemców - typy zezwoleń:

- typ A: pracownik kontraktowy (test rynku pracy 14 dni z opinii starosty)
- typ B: członek zarządu (bez testu)
- typ C: delegacja w koncernie do 30 miesięcy w 4 latach (bez testu)
- typ D: delegacja w ramach usługi (bez testu)
- typ E: inna podstawa
- typ S: pracownik sezonowy do 9 miesięcy

Wniosek u Wojewody - opłata 100 zł do 3 miesięcy, 200 zł powyżej; termin 30-60 dni. Oświadczenie o powierzeniu pracy do 6 miesięcy w 12 obowiązuje obywateli Armenii, Białorusi, Gruzji, Mołdawii, Rosji, Ukrainy.

Niebieska Karta UE z art. 88a dla wysoko wykwalifikowanych - wymóg wyższego wykształcenia lub 5 lat doświadczenia, wynagrodzenie 1,5 razy przeciętne (od 1.07.2026 około 11 100 zł brutto), ważność 3 lata, mobilność wewnątrz UE po 18 miesiącach. ICT-Karta z art. 139 (Dyrektywa 2014/66/UE) dla wewnątrzkorporacyjnych przeniesień menedżerów/specjalistów do 3 lat.

Naruszenie generuje sankcje z Ustawy o promocji zatrudnienia art. 120 - kara grzywny do 30 000 zł jednorazowo, do 100 000 zł dla pracodawcy systematycznego (3+ cudzoziemców), kara pozbawienia wolności do 3 lat z art. 218 KK.

## Ubezpieczenia społeczne, certyfikat A1, umowy podatkowe i ochrona danych

Rozporządzenie 883/2004 EU koordynuje systemy ubezpieczeń społecznych - certyfikat A1 z ZUS dla delegacji EU do 24 miesięcy z możliwością przedłużenia do 5 lat. Art. 12 reguluje delegację do 24 miesięcy (brak zatrudnienia w państwie przyjmującym przez 12 miesięcy przed, kontynuacja umowy z polskim pracodawcą), art. 13 działalność w wielu państwach EU.

Brak A1 generuje podwójne ubezpieczenie - składki polskie 30-35% wynagrodzenia oraz składki państwa przyjmującego (Niemcy ~40%, Francja ~45%). Wniosek ZUS Z-3, termin 30-60 dni. EKUZ z NFZ uzupełnia A1 dla pomocy medycznej; dla delegacji długoterminowej formularz S1 z rejestracją w lokalnej kasie chorych.

DBA umowy (90+ państw ratyfikowanych przez Polskę) regulują opodatkowanie - reguła 183 dni z art. 15 DBA OECD, exemption with progression dla większości EU lub foreign tax credit dla USA/Wielkiej Brytanii. Certyfikat rezydencji podatkowej niezbędny dla DBA.

RODO art. 88 reguluje przetwarzanie danych pracowniczych, art. 49 transgraniczny transfer. Dla USA EU-US Data Privacy Framework (decyzja adekwatności 10.07.2023), dla państw bez decyzji wyjątek art. 49 ust. 1 lit. b lub SCCs Decyzja Komisji 2021/914. Naruszenie generuje sankcję UODO do 4 procent obrotu lub 20 milionów EUR.

## Współpraca z agentami onboardingu, płac i dokumentów

Agent współpracuje z Onboarding-Workflow Agent dla onboardingu lokalnego w nowej lokalizacji - BHP lokalne (KP art. 237-3 szkolenie wstępne, art. 237-1 ocena ryzyka), kultura organizacyjna, narzędzia IT, dostęp do systemów. Onboarding-Workflow Agent klasyfikuje typ rozpoczęcia (transfer wewnętrzny vs nowy pracownik vs powrót z urlopu) i adaptuje workflow.

Payroll-Processing Agent aktualizuje wynagrodzenie od daty transferu - składki ZUS w 2 systemach przy delegacji EU (kontynuacja w polskim z A1 + składki państwa przyjmującego po 24 miesiącach lub bez A1), podatki PIT z walidacją DBA (rezydencja podatkowa, exemption with progression), pakiet relokacyjny z opodatkowaniem (zwrot kosztów do 25 000 zł zwolniony z art. 21 ust. 1 pkt 14a, dodatek mieszkaniowy do 500 zł zwolniony z art. 21 ust. 1 pkt 13, tax equalization opodatkowane).

HR-Document-Management Agent archiwizuje dokumenty transferu w segmencie B akt osobowych zgodnie z Rozp. MRiPS z 10.12.2018 - aneks art. 42 KP, polecenie delegacji art. 77-5, A1, kopia zezwolenia z Wojewody, dokumenty Niebieskiej Karty UE/ICT-Karty, certyfikat rezydencji DBA. 10-letni okres przechowywania z Ustawy o aktach osobowych z 1.10.2018 dla zatrudnień od 1.01.2019, 50-letni dla wcześniejszych.

## [Decision Layer](/pl/decision-layer/) zamienia transfer w weryfikowalny proces

Decision Layer rozkłada cykl życia transferu na pojedyncze kroki decyzyjne i dla każdego definiuje: człowiek, silnik reguł lub AI. Walidację istotności zmiany warunków umowy KP art. 42 przejmuje AI z confidence scoring 85-92 procent. Klasyfikację typu transferu, mapowanie na obowiązkowe dokumenty, generowanie wniosku A1, klasyfikację typu zezwolenia na pracę, monitoring terminów podlega silnikowi reguł. Walidację DBA dla państwa docelowego i kalkulację pakietu relokacyjnego przejmuje AI z confidence scoring 80-88 procent. RODO art. 22 wyklucza pełną automatyzację - walidacja AI poniżej threshold trafia do Radcy Prawnego lub Specjalisty ds. Podatków Międzynarodowych.

Człowiek pozostaje tam, gdzie decyzja jest naprawdę potrzebna: wybór dostawcy mobility (Cartus vs Mercer vs EY/Deloitte/KPMG vs Topia/Equus vs EOR Globalization Partners/Deel), zatwierdzenie pakietu relokacyjnego powyżej 100 000 zł przez CFO, executive package przez Radę Nadzorczą KSH art. 382. Kierownik Projektu Relokacji widzi zweryfikowany pakiet - aneks do umowy art. 42, A1 z ZUS, zezwolenie na pracę z Wojewody, certyfikat rezydencji dla DBA, kalkulacja pakietu z PIT/ZUS - i autoryzuje Go-Live.

## Na pierwszy rzut oka

- 50-150 transferów rocznie, 30-50 zadań na transfer, jeden zgubiony wątek zatrzymuje Go-Live
- KP art. 42 wypowiedzenie zmieniające dla istotnych zmian (dojazd 2h+, degradacja, obniżka 25%+)
- Delegacja w UE według Ustawy o pracownikach delegowanych z 10.06.2016 i Dyrektywy 96/71/WE 2018/957
- Zezwolenia na pracę dla cudzoziemców (typy A-S), Niebieska Karta UE oraz karta ICT z Ustawy o cudzoziemcach z 12.12.2013
- Certyfikat A1 z Rozporządzenia 883/2004 do 24 miesięcy, z przedłużeniem do 5 lat
- Sieć umów o unikaniu podwójnego opodatkowania (ponad 90 państw) z regułą 183 dni
- 10-letni okres akt osobowych segment B z Ustawy o aktach 1.10.2018
- Sankcje: PIP 30 000 zł, UODO 4% obrotu, MiLoG Niemcy 500 000 EUR, art. 218 KK 3 lata
- Pakiet relokacyjny: zwrot kosztów do 25 000 zł zwolniony, dodatek mieszkaniowy 500 zł zwolniony

| Decyzja                                  | Decydent | Podstawa prawna                  |
| ---------------------------------------- | -------- | -------------------------------- |
| Klasyfikacja typu transferu              | Reguła   | Macierz typów                    |
| Generowanie planu zadań                  | Reguła   | Szablon per typ                  |
| Walidacja KP art. 42 wypowiedzenie       | KI       | Tabela istotności + RODO art. 22 |
| Walidacja Dyrektywy 96/71/WE             | Reguła   | Tabela 27 państw EU              |
| Wniosek A1 z ZUS                         | Reguła   | Rozp. 883/2004 art. 12/13        |
| Klasyfikacja zezwolenia na pracę         | Reguła   | Ust. cudzoziemcach 12.12.2013    |
| Konsultacja Rady Pracowników/ZZ          | Reguła   | Ust. 4.07.2006 + 23.05.1991      |
| Walidacja DBA                            | KI       | 90+ DBA + RODO art. 22           |
| Generowanie aneksu KP art. 42            | Reguła   | KP art. 36 termin                |
| Kalkulacja pakietu relokacyjnego         | KI       | PIT art. 21 + RODO art. 22       |
| Workflow zatwierdzania                   | Reguła   | Macierz KSH art. 382             |
| Wybór dostawcy mobility                  | Człowiek | Strategia korporacyjna           |
| Monitoring terminów A1/EKUZ/zezwolenia   | Reguła   | Ust. cudzoziemcach art. 88f      |
| Cross-reference Onboarding/Payroll/HRDM  | Reguła   | RODO art. 32 + Rozp. MRiPS       |

## Co infrastruktura daje innym agentom

Architektura klasyfikacji typu transferu i workflow zatwierdzania z KSH art. 382 staje się szablonem dla agentów mobilności. Onboarding-Workflow klasyfikuje typ rozpoczęcia z BHP lokalne. Offboarding-Workflow klasyfikuje zakończenie z procedurami transferu wychodzącego. Compensation-Benchmarking porównuje wynagrodzenia z DBA.

Decision Logging zgodne z RODO art. 30+32, KP art. 94 pkt 9b i Ustawą o aktach 1.10.2018 buduje Audit Trail dla obrony przed PIP (KP art. 281), PIP państwa przyjmującego (Niemcy Zoll, Francja URSSAF, Belgia ONSS), UODO (RODO art. 88), KAS (DBA) i KIBR (ESRS S1-1+S1-9). Generowanie wniosków A1 i monitoring terminów EKUZ/zezwolenia zasila Compliance-Monitoring i Certification-Tracking.

Transfer-Relocation Agent dowodzi przy 50-150 transferach rocznie, że audytowalny workflow ze zgodnością KP art. 42, Ustawą o pracownikach delegowanych 10.06.2016, Ustawą o cudzoziemcach 12.12.2013, Rozporządzeniem 883/2004 EU i DBA jest możliwy.

--- Agent HR-Wniosku-o-Podróż ---
> Workflow zatwierdzenia podróży HR przed wyjazdem: wniosek o podróż z zatwierdzeniem kierownika, regulamin ZZ Rady Pracowników i walidacja pól obowiązkowych przed wyjazdem.

W organizacji z 2000 pracownikami i średnio 5000 podróży służbowych rocznie powstaje 60 000 paragonów i faktur do rozliczenia. Polityka podróży ma 8 kategorii stanowisk z różnymi klasami noclegu i przelotu, Rozporządzenie Ministra Pracy 29.01.2013 załącznik 2 ma 116 krajów ze stawkami diet od 30 do 110 EUR, każda delegacja musi być rozliczona w 14 dni z Kodeksu Pracy art. 77. Ręcznie to niewykonalne, na arkuszach Excel też nie - każdy błąd trafia do kontroli KAS, biegłego rewidenta KIBR i kontroli ZUS.

Naruszenie Rozporządzenia Ministra Pracy 29.01.2013 i Ustawy o PIT art. 21 ust. 1 pkt 16 generuje obowiązek pobrania zaliczki PIT 12/32 procent od przekroczeń plus składki ZUS emerytalna 19,52 procent, rentowa 8 procent, chorobowa 2,45 procent, wypadkowa 0,67-3,33 procent. Naruszenie 5-letniego okresu przechowywania ksiąg z Ordynacji podatkowej art. 86 to decyzja szacunkowa US z karami 4-6 procent obrotu plus odsetki 11,5 procent rocznie z art. 53. Postępowanie karno-skarbowe z KKS art. 60-77 to do 720 stawek dziennych grzywny dla winnych. Naruszenie Kodeksu Pracy art. 77 (rozliczenie do 14 dni) generuje karę PIP z art. 281 KP do 30 000 zł.

Kto zna te liczby i mimo to nie ma deterministycznego procesu rozliczeń delegacji, prowadzi kontrolowane ryzyko regulacyjne, nie księgowość.

## Rozliczenia podróży służbowych w sekundach zamiast tygodni

Polecenie wyjazdu z systemu HR (Comarch HCM, Symfonia Kadry, enova365, SAP HCM Polska, Workday, Personio, ADP) zawiera dla każdego pracownika kompletne dane - identyfikator, daty rozpoczęcia i zakończenia, kraj/miasto docelowe, cel podróży, środek transportu (samochód służbowy, prywatny, PKP, samolot, autokar), zaplanowany budżet, źródło finansowania (projekt, MPK, dział). Pracownik gromadzi paragony i faktury, system OCR rozpoznaje teksty z różnych formatów (paragon termiczny, faktura PDF, zdjęcie smartfonem) z confidence scoring AI.

Agent przekształca te dane na rozliczenie zgodne z polskim prawem deterministycznie. Każdy składnik ma przypisaną kalkulację - dieta krajowa 38 PLN za dobę z par. 4 Rozporządzenia Min. Pracy 29.01.2013, dieta zagraniczna z tabeli 116 krajów (załącznik 2) od 30 EUR (Bułgaria, Rumunia) do 110 EUR (USA, Japonia), ryczałt noclegowy 76 PLN krajowy lub 60-300 EUR zagraniczny, ryczałt komunikacyjny 30 PLN, kilometrówka 1,15/0,89 PLN za km z Rozporządzenia Min. Finansów. Mapowanie do planu kontowego polskiego - 4030 Koszty podróży, 4031 Diety krajowe, 4032 Diety zagraniczne, 4033 Noclegi, 4034 Transport, 4035 Kilometrówka, 4036 Samochód służbowy, 4037 Pozostałe. Alokacja do MPK na podstawie polecenia wyjazdu - reguły zatwierdza Kontroler Finansowy.

## Diety krajowe i zagraniczne według Rozporządzenia Ministra Pracy z 29.01.2013

Rozporządzenie Ministra Pracy i Polityki Społecznej z 29.01.2013 jest aktem wykonawczym do Kodeksu Pracy art. 77-5 par. 2 i reguluje wszystkie należności z tytułu podróży służbowej. Par. 4 ustanawia dietę krajową 38 PLN za dobę od 1.01.2026 (wcześniej 30 PLN). Reguła obliczenia dób - rozpoczęcie po godzinie 8 = pełna doba, między 8 a 12 = 1/2 diety, przed 8 = pełna doba poprzednia. Dla podróży krótszej niż 8 godzin nie przysługuje dieta.

Par. 7 ustanawia ryczałty - 76 PLN noclegowy, 30 PLN komunikacyjny. Załącznik 2 ustanawia diety zagraniczne dla 116 krajów - od 30 EUR (Bułgaria, Rumunia, Ukraina), przez 41-50 EUR (Czechy 41, Niemcy 49, Francja 50), 60-80 EUR (Holandia 50, Belgia 48, Austria 52), do 100-110 EUR dla USA, Japonii, Szwajcarii, Norwegii.

```
Hierarchia źródeł prawa rozliczeń delegacji w Polsce
─────────────────────────────────────────────────────
Konstytucja RP art. 47+51 (prywatność)
        │
        ├── Kodeks Pracy z 26.06.1974
        │   ├── art. 77-5 delegacje (podstawa)
        │   ├── art. 77 rozliczenie 14 dni
        │   └── art. 94 pkt 9b archiwizacja 5 lat
        │
        ├── Rozporządzenie Min. Pracy 29.01.2013
        │   ├── par. 4 dieta krajowa 38 PLN
        │   ├── par. 7 ryczałty 76/30 PLN
        │   ├── par. 13 diety zagraniczne
        │   └── załącznik 2 - 116 krajów
        │
        ├── Ustawa o PIT z 26.07.1991
        │   ├── art. 21 ust. 1 pkt 16 zwolnienia
        │   ├── art. 21 ust. 1 pkt 13-15 zorganizowane
        │   └── art. 32 zaliczki PIT 12/32 procent
        │
        ├── Ordynacja podatkowa z 29.08.1997
        │   └── art. 86 archiwizacja 5 lat + bieżący
        │
        └── Ustawa o rachunkowości z 29.09.1994
            ├── art. 4-23 zasady fundamentalne
            └── art. 13-23 zapisy podwójne Wn=Ma
```

Liczenie dób zagranicznych z par. 13 - rozpoczęcie po przekroczeniu granicy polskiej = pełna doba, ryczałt noclegowy odrębny zgodnie ze stawką krajową. Przeliczenie na PLN po średnim kursie NBP z dnia rozpoczęcia podróży zgodnie z Ust. o rachunkowości. Wypłata diet i ryczałtów do limitu z Rozporządzenia 29.01.2013 jest zwolniona z PIT i ze składek ZUS.

## Limity zwolnień podatkowych i obowiązek archiwizacji

Ustawa o PIT z 26.07.1991 art. 21 ust. 1 pkt 16 zwalnia diety i należności za czas podróży służbowej do wysokości z Rozporządzenia 29.01.2013. Art. 21 ust. 1 pkt 13-15 zwalnia hotele i transport zorganizowany. Przekroczenie generuje przychód opodatkowany 12 procent (do 120 000 PLN), 32 procent powyżej, z kwotą zmniejszającą 3600 PLN i kosztami uzyskania 250/300 PLN.

Agent waliduje sumę wypłat - dieta krajowa do 38 PLN, zagraniczna do stawki z załącznika 2, ryczałt noclegowy 76 PLN/krajowy lub 60-300 EUR/zagraniczny, kilometrówka do limitu Rozporządzenia Min. Finansów. Przekroczenie = zaliczka PIT z art. 32 plus składki ZUS z art. 18 Ust. SUS.

Ordynacja podatkowa art. 86 stanowi 5-letni okres przechowywania ksiąg plus rok bieżący od końca roku obowiązku podatkowego. Dla rozliczeń z 2026 archiwizacja do końca 2031. Brak ksiąg = decyzja szacunkowa US z karami 4-6 procent obrotu plus odsetki 11,5 procent z art. 53. Postępowanie karno-skarbowe z KKS art. 60-77 to do 720 stawek dziennych grzywny.

## Ochrona danych i konsultacja z Radą Pracowników

RODO art. 88 doprecyzowuje przetwarzanie danych pracowniczych - dla rozliczeń delegacji obejmuje dane geolokalizacyjne (kraj, miasto, cel), paragony (profilowanie zwyczajów), faktury medyczne (szczególne kategorie z art. 9 - stan zdrowia), dane bankowe. Wymaga ograniczonego dostępu - Specjalista ds. Rozliczeń, Główna Księgowa, audytor.

Ustawa o ochronie danych osobowych z 10.05.2018 (UODO) doprecyzowuje RODO - sankcje do 4 procent obrotu lub 20 milionów EUR. Polityka prywatności musi być transparentna z RODO art. 13-14.

Ustawa o Radzie Pracowników z 4.07.2006 nakłada konsultacje w przedsiębiorstwach od 50 pracowników. Polityka podróży podlega konsultacji - kategorie stanowisk, limity budżetowe, akceptowane środki transportu. Ustawa o sygnalistach z 14.06.2024 daje 24-miesięczną ochronę zgłaszającym manipulacje paragonami i fikcyjne podróże.

## Współpraca z agentami księgowania płac i dokumentów

Travel Expense Agent (ten agent) ma zakres rozliczeń podróży z kalkulacją diet, walidacją paragonów OCR, mapowaniem na plan kontowy. Payroll Accounting Agent (Cluster #39) księguje listę płac - wynagrodzenia, składki ZUS, zaliczki PIT, PPK, alokacja MPK na konta 4040 Koszty pracy. Travel Expense Agent przekazuje zaliczki PIT od przekroczeń na konto 2240 Rozrachunki z budżetem PIT.

HR Document Management Agent zarządza dokumentami pracowniczymi - polecenia wyjazdu i rozliczenia są przekazywane dla 5-letniej archiwizacji z KP art. 94 pkt 9b. Expense Processing Agent zajmuje się pozostałymi wydatkami (szkolenia, materiały biurowe, koszty reprezentacji). Wszystkie agenty współdzielą audit-trail z Ord. Pod. art. 86, integrację z planem kontowym i walidację RODO art. 88.

## Na pierwszy rzut oka

- **Rozporządzenie Ministra Pracy 29.01.2013** - dieta krajowa 38 PLN za dobę od 1.01.2026, diety zagraniczne 30-110 EUR z tabeli 116 krajów (załącznik 2), ryczałt noclegowy 76 PLN, ryczałt komunikacyjny 30 PLN
- **Ustawa o PIT art. 21 ust. 1 pkt 16** - zwolnienia podatkowe diet i ryczałtów do limitu z Rozporządzenia 29.01.2013, przekroczenie generuje zaliczkę PIT 12/32 procent z art. 32
- **Ordynacja podatkowa art. 86** - 5-letni okres przechowywania ksiąg plus rok bieżący, sankcje karno-skarbowe z KKS art. 60-77 do 720 stawek dziennych grzywny
- **Kodeks Pracy art. 77-5 + art. 77** - delegacje jako podstawa Rozporządzenia 29.01.2013, rozliczenie do 14 dni od zakończenia podróży, kara PIP do 30 000 zł
- **OCR paragonów i walidacja polityki podróży** - ocena pewności AI dla rozpoznania, kategorie stanowisk z klasami noclegu i przelotu konsultowane z Radą Pracowników z Ust. z 4.07.2006
- **Profil deterministyczny** - 12 z 14 mikrodecyzji to reguły (R), 1 to AI (A) dla OCR, 1 to zatwierdzenie człowieka (H)
- **EU AI Act 2024/1689** - niesklasyfikowany jako wysokie ryzyko, RODO art. 22 wyklucza pełną automatyzację decyzji finansowych dotyczących pracowników

### Rozdział decydentów w rozliczeniu delegacji

```
Krok                                       Decydent  Podstawa
─────────────────────────────────────────────────────────────
1. Pobranie polecenia wyjazdu              Reguła    API systemu HR
2. Sprawdzenie polityki podróży            Reguła    Polityka firmy + Rada Prac.
3. OCR paragonów i faktur                  AI        Confidence scoring
4. Obliczenie diety krajowej 38 PLN        Reguła    Rozp. Min. Pracy par. 4
5. Obliczenie diety zagranicznej           Reguła    Rozp. Min. Pracy zał. 2
6. Walidacja kosztów dodatkowych           Reguła    Ust. PIT art. 21 ust. 1
7. Kilometrówka samochód prywatny          Reguła    Rozp. Min. Finansów
8. Walidacja samochodu służbowego          Reguła    Ust. PIT + VAT art. 86a
9. Walidacja limitów Ust. o PIT            Reguła    Ust. PIT art. 21+32
10. Mapowanie planu kontowego              Reguła    Ust. o rachunk. art. 13-23
11. Alokacja kosztów do MPK                Reguła    Polityka rachunkowości
12. Generowanie zapisów Wn-Ma              Reguła    Zasada podwójnego zapisu
13. Audit-trail dla KIBR i KAS             Reguła    Ord. Pod. art. 86
14. Końcowe zatwierdzenie i wypłata        Człowiek  KP art. 77 (14 dni)
```

12 deterministycznych reguł plus 1 AI plus 1 zatwierdzenie człowieka. Profil financial-process - dominacja reguł z fundamentalnym znaczeniem mapowania stawek z Rozporządzenia 29.01.2013, walidacji limitów Ust. o PIT i mapowania planu kontowego. AI wkracza tylko dla OCR paragonów z confidence scoring, gdzie rozpoznanie tekstów z różnych formatów (paragon termiczny zagraniczny, faktura PDF, zdjęcie smartfonem) wymaga modeli Vision-Language. RODO art. 22 wyklucza pełną automatyzację decyzji finansowych dotyczących pracowników - Specjalista ds. Rozliczeń lub Główna Księgowa zatwierdza wypłatę.

## [Decision Layer](/pl/decision-layer/) zamienia rozliczenie delegacji w weryfikowalny proces

Polityka podróży służbowych istnieje w każdej organizacji - ale trzech specjalistów rozlicza tę samą delegację z trzema różnymi sumami, bo nikt nie sprawdza limitów Rozporządzenia 29.01.2013 przed wypłatą. Decision Layer rozkłada cykl na kroki decyzyjne. Sprawdzenie polityki, OCR paragonów, kalkulacja diet, kilometrówka, walidacja limitów Ust. o PIT art. 21 ust. 1 pkt 16, mapowanie planu kontowego, walidacja bilansowa, audit-trail - deterministyczne reguły. OCR podlega AI z confidence scoring.

Człowiek pozostaje przy końcowym zatwierdzeniu i wypłacie. Odpowiedzialność księgowa z Ust. o rachunkowości art. 4 ust. 5, terminowość z KP art. 77 (14 dni), karno-skarbowa z KKS art. 60-77 pozostają przy człowieku. Readiness Score powyżej 88 wynika z wysokiego wolumenu, jasnych reguł i klasyfikacji "financial-process" poza wysokim ryzykiem EU AI Act 2024/1689. KSeF jako akcelerator - od 1.07.2026 e-faktury B2B w schemacie FA(2) XSD 1-0E synchronizują rozliczenia z fakturami hotelowymi.

--- Vendor Management Agent ---
> Zarządzanie dostawcami HR zgodne z PZP 11.09.2019, CSDDD 2024/1760, RODO art. 28 i ESRS S2 - lifecycle, due-diligence, KPI z SLA i raportowanie dla audytora KIBR i WIG-ESG GPW.

Firma z 1500 pracownikami utrzymuje typowo 60-100 dostawców HR: dostawcy płac (Comarch, Symfonia, BPO Payroll), dostawcy benefitów (ubezpieczenia grupowe, pakiety medyczne, fundusz świadczeń), dostawcy szkoleń (LMS Workday Learning, BPO Recruitment Process Outsourcing), dostawcy SaaS HR (HRIS Personio, BambooHR, ATS Lever), dostawcy delegowania (Ustawa z 10.06.2016), dostawcy BHP (KP art. 234-237). Każda relacja musi mieć aktualną umowę powierzenia RODO art. 28, zgodne SLA, monitoring KPI, due-diligence CSDDD i raportowanie ESRS S2. W praktyce co najmniej jeden z tych pięciu warunków jest prawie zawsze naruszony.

## Zarządzanie dostawcami HR w kontekście CSDDD

Dostawcy HR to nie tylko relacje kontraktowe, lecz fragmenty łańcucha wartości firmy. Dyrektywa CSDDD 2024/1760 z 13.06.2024 wprowadza obowiązek due-diligence w łańcuchu wartości od 26.07.2027 dla firm 5000+ pracowników i 1.5 mld EUR obrotu globalnego, transpozycja do polskiego prawa do 26.07.2026.

System zarządzający dostawcami pochodzi z poprzedniej dekady. Folder SharePoint z 200 umowami, z których 40 ma niekompletne klauzule RODO art. 28. Excel z monitoringiem terminów wypowiedzenia, gdzie 15 umów już przedłużyło się automatycznie mimo naruszeń SLA.

Rezultat: firma działa w łańcuchu wartości z dostawcami z krajów wysokiego ryzyka praw człowieka bez audytów, podpisuje umowy SCC 2021/914 dla USA bez Transfer Impact Assessment z Schrems II, traci kontrolę nad konsolidacją rynku (Comarch przejęcie Symfonii zmniejsza alternatywy poniżej 3 dostawców). Audyt KIBR raportowania ESRS S2 odkrywa, że firma nie ma polityki due-diligence CSDDD - modyfikacja opinii audytorskiej, wykluczenie z WIG-ESG GPW.

## Prawo Zamówień Publicznych i due-diligence z Dyrektywy CSDDD

Warstwa Ustawy Prawo Zamówień Publicznych jest fundamentalna dla zamawiających publicznych. Próg unijny dla dostaw i usług sektora klasycznego wynosi 143 000 EUR, dla sektora specjalnego 215 000 EUR, dla robót budowlanych 5 538 000 EUR. Tryby PZP: przetarg nieograniczony art. 132 (najpopularniejszy, otwarty dla wszystkich), przetarg ograniczony art. 159 (dwuetapowy z wyborem wykonawców), dialog konkurencyjny art. 169 (dla złożonych zamówień innowacyjnych), partnerstwo innowacyjne art. 195.

Publikacja w BZP Biuletynie Zamówień Publicznych art. 263 jest obowiązkowa, dla zamówień powyżej progu unijnego dodatkowo TED Tenders Electronic Daily UE z minimum 35 dni na ofertę. Wybór najkorzystniejszej oferty z kryteriami: cena nie więcej niż 60 procent zgodnie z PZP, jakość, doświadczenie, certyfikaty ESG/CSDDD, RODO art. 28 zgodność.

Dyrektywa CSDDD 2024/1760 wprowadza obowiązek due-diligence w łańcuchu wartości - identyfikacja, prewencja, łagodzenie negatywnych skutków praw człowieka (Konwencje MOP 29/138/105/87/98/100/111/155) i środowiska (Porozumienie Paryskie, Dyrektywa Wodna 2000/60/WE). Mapowanie tier 1 bezpośrednich dostawców HR i tier 2-N poddostawców. Sankcja do 5 procent obrotu globalnego za naruszenie.

Agent automatyzuje due-diligence przez AI risk scoring 80-88 procent na metadanych dostawcy (kraj rejestracji według CPI Corruption Perception Index i ITUC Global Rights Index, branża, certyfikaty SA8000/ISO 14001, EcoVadis Gold/Silver) z eskalacją do Specjalisty ds. ESG dla dostawców z krajów wysokiego ryzyka. Decyzja o kontraktowaniu zawsze do zarządu z dokumentacją uzasadnienia.

## Raportowanie ESRS S2: pracownicy w łańcuchu wartości

ESG/CSRD wprowadza obowiązkowe raportowanie zrównoważonego rozwoju z 12 standardów ESRS. ESRS S2 Workers in the Value Chain dotyczy pracowników dostawców i poddostawców - kluczowy standard dla Vendor Management Agent. Wymagania:

- S2-1: polityka praw człowieka zgodna z UNGP i OECD Guidelines, polityka due-diligence CSDDD, kodeks postępowania dla dostawców z 11 standardami praw pracowniczych
- S2-2: procesy angażowania - audyty SMETA, ankiety pracownicze, wizyty u dostawców, raportowanie BAFA dla LkSG-zobowiązanych
- S2-3: mechanizmy skarg - kanał dla pracowników dostawców i społeczności lokalnych integrowany z polityką sygnalistów Ustawa z 14.06.2024
- S2-4: działania naprawcze - korekta naruszeń, plan korygujący, monitoring postępu, w skrajnych przypadkach wypowiedzenie umowy
- S2-5: cele - redukcja ryzyka praw człowieka, certyfikacje SA8000, EcoVadis Gold/Silver, redukcja Scope 3 GHG

GPW WIG-ESG i Code of Best Practices for WSE Listed Companies wymaga raportowania kwartalnego dla spółek publicznych. Agent generuje raporty automatycznie z metadanych dostawców i wyników due-diligence. Audytor KIBR ma dostęp przez API.

Naruszenie raportowania generuje modyfikację opinii audytorskiej KIBR (kwalifikowany odpis), wykluczenie z WIG-ESG GPW (spadek kursu), naruszenie Code of Best Practices for WSE Listed Companies (publiczna nagana).

## Umowy powierzenia, transfer danych i ochrona konkurencji

RODO art. 28 wymaga umowy powierzenia przetwarzania danych z każdym dostawcą HR z dostępem do danych pracowniczych - 35 obowiązkowych klauzul:

- przedmiot, czas, charakter, cel przetwarzania
- kategorie danych (KP art. 22-1, RODO art. 9 dane wrażliwe)
- kategorie osób (pracownicy, kandydaci, byli pracownicy)
- obowiązki procesora art. 28 ust. 3 lit. a-h - instrukcje udokumentowane, poufność personelu, środki TOM, podprocesorzy z uprzednią zgodą, audytowalność, zwrot/usunięcie danych

Standardowe Klauzule Umowne SCC 2021/914 z 4.06.2021 obowiązkowe od 27.12.2022 dla transferów do państw trzecich - moduł 2 administrator-procesor, moduł 3 procesor-podprocesor. Wyrok Schrems II C-311/18 z 16.07.2020 wymaga Transfer Impact Assessment TIA z oceną prawa krajowego (FISA 702 dla USA), środków technicznych (szyfrowanie end-to-end, fragmentacja, klucze HSM oddzielne). Data Privacy Framework UE-USA z 10.07.2023 częściowo zastępuje SCC dla USA dla certyfikowanych firm.

Ustawa antymonopolowa z 16.02.2007 reguluje kontrolę UOKiK koncentracji M&A powyżej 1 mld zł obrotu globalnego (art. 13) i zakaz porozumień ograniczających konkurencję (art. 14) - zmowa przetargowa z karami do 10 procent obrotu rocznego, dla skrajnych przypadków sankcję karną z art. 305 k.k. do 3 lat pozbawienia wolności.

Ustawa o świadczeniu usług drogą elektroniczną z 18.07.2002 UŚUDE reguluje umowy z dostawcami SaaS HR z obowiązkami informacyjnymi art. 5, regulaminem świadczenia usług art. 8.

Naruszenia generują sankcję UODO do 4 procent obrotu lub 20 mln EUR z RODO, sankcję UOKiK do 10 procent obrotu rocznego z Ustawy antymonopolowej.

## Współpraca z agentami płac, benchmarkingu i dokumentów

Agent współpracuje z Payroll Processing Agent przez ratyfikację dostawców płac (Comarch ERP HR, Symfonia HR, BPO Payroll) z umową powierzenia RODO art. 28, monitoring KPI naliczania (czas zamknięcia okresu rozliczeniowego, dokładność deklaracji ZUS Płatnik, JPK_V7M).

Współpraca z Compensation Benchmarking Agent obejmuje ratyfikację dostawców danych benchmarkowych (Mercer Polska, Korn Ferry Polska, Hay Group, Aon Hewitt, dane GUS) z weryfikacją niezależności metodologicznej, transparentności metod pomiaru EU Pay Transparency Directive 2023/970, ESG/CSRD ESRS S1-9.

HR Document Management Agent archiwizuje umowy z dostawcami w segmencie B akt korporacyjnych zgodnie z Rozp. MRiPS z 10.12.2018 z 5-letnim okresem KP art. 94 pkt 9b dla umów standardowych i 10-letnim KSH art. 84 dla umów strategicznych zarządu. Vendor Management zarządza tworzeniem, monitoringiem KPI i wypowiedzeniem, HR Document Management archiwizuje jako dokumenty kadrowe z metadanymi i kwalifikowanym podpisem QSig.

Cztery agenty współdzielą infrastrukturę kwalifikowanego podpisu eIDAS Autenti, audit-trail RODO art. 30+32, integrację z Comarch ERP HR jako centralnym ERP polskiego rynku.

## [Decision Layer](/pl/decision-layer/) zamienia vendor management w weryfikowalny proces

Decision Layer rozkłada cykl życia dostawcy na pojedyncze kroki decyzyjne i dla każdego definiuje: człowiek, silnik reguł lub AI. Klasyfikację typu dostawcy, walidację PZP, walidację RODO art. 28, monitoring KPI, monitoring terminów umów podlega silnikowi reguł. Walidację SCC z Schrems II, due-diligence CSDDD, agregację feedbacku z monitoringu wydajności przejmuje AI z confidence scoring 80-92 procent. RODO art. 22 wyklucza pełną automatyzację - klasyfikacja AI poniżej threshold trafia do Specjalisty ds. ESG/CSRD lub Inspektora Ochrony Danych, decyzja o kontraktowaniu z dostawcą wysokiego ryzyka zawsze pozostaje przy zarządzie.

Człowiek pozostaje tam, gdzie decyzja jest naprawdę potrzebna: zatwierdzenie umowy strategicznej przez zarząd z odpowiedzialnością KSH art. 233+299, wybór wykonawcy w postępowaniu przetargowym, ocena kontrowersyjnego ryzyka CSDDD, decyzja o wypowiedzeniu umowy z dostawcą po naruszeniach SLA. Zarząd widzi zweryfikowany pakiet - walidacja PZP, walidacja RODO art. 28, walidacja SCC, due-diligence CSDDD, KPI monitoring, kwalifikowany podpis Autenti - i autoryzuje decyzję.

## Na pierwszy rzut oka

- 60-100 dostawców HR w typowej firmie 1500 pracowników, jeden z pięciu warunków zawsze naruszony
- Ustawa PZP 11.09.2019 progi unijne 143 000 EUR dla zamawiających publicznych, transparentność BZP/TED
- Dyrektywa CSDDD 2024/1760 due-diligence w łańcuchu wartości od 26.07.2027 (5000+), transpozycja do 26.07.2026
- RODO art. 28 35 obowiązkowych klauzul umowy powierzenia, sankcja UODO do 4 procent obrotu lub 20 mln EUR
- Standardowe klauzule umowne, środki z wyroku Schrems II i Data Privacy Framework UE-USA dla transferów poza EOG
- Ustawa antymonopolowa 16.02.2007 UOKiK kontrola koncentracji powyżej 1 mld zł, zmowa przetargowa do 10 procent obrotu
- Raportowanie ESRS S2 (pracownicy w łańcuchu wartości, podsekcje S2-1 do S2-5) weryfikowane przez KIBR i w ramach WIG-ESG GPW
- AML Ustawa z 1.03.2018 weryfikacja CRBR Centralny Rejestr Beneficjentów Rzeczywistych, sankcja GIIF do 5 mln EUR
- 5-letni okres przechowywania KP art. 94 pkt 9b, 10-letni KSH art. 84 dla umów strategicznych

### Rozdział decydentów Vendor-Management

| Decyzja                                  | Decydent | Podstawa prawna                |
| ---------------------------------------- | -------- | ------------------------------ |
| Klasyfikacja typu dostawcy               | Reguła   | Macierz kategorii dostawców    |
| Walidacja Ustawy PZP 11.09.2019          | Reguła   | Progi unijne BZP/TED           |
| Walidacja RODO art. 28 powierzenie       | Reguła   | Checklist 35 klauzul           |
| Walidacja SCC 2021/914 + Schrems II      | KI       | RODO art. 22 + DPF UE-USA      |
| Due-diligence CSDDD 2024/1760            | KI       | RODO art. 22 + UNGP/OECD       |
| Weryfikacja LkSG-równoważności           | Reguła   | BAFA-Reporting + CSDDD         |
| Walidacja SLA i KPI                      | Reguła   | KC art. 484 kary umowne        |
| Workflow zatwierdzania                   | Reguła   | Macierz KSH art. 382           |
| Weryfikacja KYV/AML                      | Reguła   | CRBR + Biała Lista KAS         |
| Monitoring KPI ciągły                    | KI       | RODO art. 22                   |
| Monitoring terminów umów                 | Reguła   | KP art. 94 pkt 9b, KSH art. 84 |
| Postępowanie przetargowe okresowe        | Człowiek | KSH art. 233+299               |
| Walidacja UOKiK i zmów przetargowych     | Reguła   | Ustawa 16.02.2007 art. 14      |
| Generowanie raportów ESRS S2             | KI       | ESRS S2 + WIG-ESG GPW          |

## Co infrastruktura daje innym agentom

Architektura klasyfikacji dostawców, workflow due-diligence CSDDD i workflow zatwierdzania z KSH art. 382 staje się szablonem dla agentów stosujących dostawców zewnętrznych. Procurement Agent stosuje progi PZP dla zamówień powyżej 143 000 EUR. IT Service Management Agent stosuje DORA EU 2554/2022 dla dostawców ICT. Marketing Agent stosuje RODO art. 28 dla CRM i Marketing Automation.

Decision Logging zgodne z RODO art. 30+32, KP art. 94 pkt 9b i KSH art. 84 buduje Audit Trail - kluczowe dla obrony przed kontrolą UZP, UODO, UOKiK, GIIF, PIP, KIBR ze standardami ESRS S2. Generowanie raportów ESG/CSRD ESRS S2 jest fundamentem dla ESG Reporting Agent, Supply Chain Risk Agent, Whistleblower Workflow Agent z rozszerzonym zakresem pracowników dostawców.

Vendor Management Agent dowodzi przy 80 dostawcach HR i 35 obowiązkowych klauzulach RODO art. 28, że audytowalny workflow z zgodnością Ustawy PZP, Dyrektywy CSDDD 2024/1760, RODO art. 28, SCC 2021/914 i ESRS S2 Workers in Value Chain jest możliwy.

--- Agent planowania zatrudnienia ---
> Operacyjne planowanie zatrudnienia: prognozowanie pojemności, KP art. 23(1) zwolnienia grupowe, Ustawa 13.03.2003, RODO art. 22 i EU AI Act Annex III(4)(b) z obligatoryjną decyzją człowieka.

## Planowanie zatrudnienia jako dyscyplina operacyjnego prognozowania

Planowanie zatrudnienia jest traktowane jako strategiczna czarna skrzynka w wielu firmach. Zarząd ustala docelowy headcount, HR oblicza budżety centrów kosztów, przedstawiciele związków zawodowych dowiadują się za późno, a w efekcie ląduje na stole plan restrukturyzacji, w którym nikt nie potrafi wyjaśnić, dlaczego dokładnie te 47 stanowisk są likwidowane. Agent planowania zatrudnienia rozkłada tę czarną skrzynkę na deterministyczne modele prognozujące, regułowe workflow konsultacji i wyraźnie oddzielone ludzkie punkty decyzyjne.

W trybie domyślnym agent nie jest systemem wysokiego ryzyka EU AI Act. Oblicza wymagania headcount z portfela zamówień + sezonowości + historii rotacji, uzgadnia je z inwentarzem umiejętności i dostarcza widok capacity-planning na centrum kosztów. To jest prognozowanie operacyjne i nie podlega Załącznikowi III(4)(b) EU AI Act 2024/1689. Dopiero gdy aktywowany jest opcjonalny moduł rekomendacji AI o zwolnieniach, klasyfikacja przełącza się na wysokie ryzyko z DPIA obowiązkowym zgodnie z art. 35 RODO, zakazem decyzji w pełni zautomatyzowanych zgodnie z art. 22 i prawem dotkniętego pracownika do zaskarżenia. Większość firm celowo nie aktywuje tego modułu.

## Ustawa o zwolnieniach grupowych z 13.03.2003 r. jako twarda bramka compliance

Planowanie zatrudnienia obejmujące 10/20/100 pracowników w okresie 30 dni uruchamia obowiązki konsultacji według Ustawy o zwolnieniach grupowych z 13 marca 2003 r. (Dz.U. 2003 Nr 90 poz. 844). Pracodawca musi poinformować przedstawicieli pracowników lub uznaną zakładową organizację związkową w terminie, konsultować znacząco sposoby uniknięcia lub zmniejszenia zwolnień, i przestrzegać minimum 30 dni. Konsultacja ta nie jest negocjowalna - Sąd Najwyższy Izba Pracy wielokrotnie potwierdzał (uchwała 7 sędziów III PZP 4/14), że decyzje workforce bez znaczącej konsultacji są bezskuteczne i nie mogą być wykonywane.

Agent uruchamia workflow konsultacji automatycznie gdy 10/20/100 pracowników jest proponowanych do zwolnienia w okresie 30 dni. Przedstawiciele pracowników lub przedstawiciele związków zawodowych otrzymują pisemną informację z danymi propozycji, otwiera się okno konsultacji 30 dni, a status konsultacji jest dokumentowany w Decision Record. Bez udokumentowanej znaczącej konsultacji, agent blokuje zatwierdzenie planu. Zawiadomienie Powiatowego Urzędu Pracy jest przygotowywane i składane elektronicznie zgodnie z Ustawą 13.03.2003 art. 2.

Dla grup wielomiejscowych w Polsce, Ustawa o radach pracowników z 7.04.2006 r. dodaje komplikacje: przedsiębiorstwa z 50+ pracownikami mogą mieć rady pracowników wymagające konsultacji na poziomie grupy. Agent zarządza tą hierarchią i uruchamia odpowiedni organ.

## Wybór pracowników do zwolnienia jako regułowy proces z człowiekiem w pętli

Wybór pracowników do zwolnienia jest regułowy zgodny z orzecznictwem SN Izba Pracy (uchwała 7 sędziów III PZP 4/14) i Wytycznymi Państwowej Inspekcji Pracy. Uzgodnione kryteria wyboru (zdolności, umiejętności, doświadczenie, staż pracy, dyscyplina pracy i absencja) są ważone wcześniej z przedstawicielami pracowników i stosowane deterministycznie. Sąd Najwyższy potwierdzał w licznych orzeczeniach, że pracodawca ma dyskrecję w ustalaniu macierzy wyboru, ale macierz musi być udokumentowana z wyprzedzeniem i najlepiej uzgodniona z przedstawicielami pracowników.

Agent oblicza wyniki wyboru deterministycznie używając uzgodnionej macierzy i dostarcza posortowaną listę wyboru. Finalna decyzja jest podejmowana przez kierownictwo HR razem z zakładową organizacją związkową lub radą pracowników - agent oblicza, nie rekomenduje. Wybór oparty na ML nie jest uznawany przez sąd pracy i regularnie zawodziłby w postępowaniu o uznanie wypowiedzenia za bezskuteczne zgodnie z KP art. 47(1). Cechy chronione KP art. 18(3a)-(3e) i pracownicy niepełnosprawni Ustawa PFRON 27.08.1997 r. są automatycznie stosowane jako korekty wyniku.

## Audyt zakazu dyskryminacji KP art. 11(3) jako obowiązek statystyczny

Planowanie zatrudnienia jest podatne na dyskryminację. Gdy plan restrukturyzacji nieproporcjonalnie dotyka starszych pracowników, kobiet w okresie macierzyńskim, niepełnosprawnych lub działaczy związkowych, stosuje się KP art. 11(3) zakaz dyskryminacji + KP art. 18(3f) odwrócenie ciężaru dowodu. Pracodawca musi wtedy udowodnić, że wybór nie był oparty na cechach chronionych - dowód praktycznie niemożliwy bez udokumentowanych audytów statystycznych.

Agent przeprowadza kwartalne audyty KP art. 11(3) zakazu dyskryminacji sprawdzając planowanie zatrudnienia pod kątem disparate impact w wieku + płci + niepełnosprawności + religii + narodowości + orientacji seksualnej + przynależności związkowej. Progi disparate impact (np. reguła 80 procent stosowana przez sądy jako dowód) uruchamiają raport audytu z statystycznym uzasadnieniem. Pełnomocnik Rządu ds. Równego Traktowania udokumentował setki postępowań w swoim Rocznym Raporcie 2024 - każde z nich reprezentuje nieograniczone ryzyko odszkodowania przed sądem pracy.

## EU AI Act i przełącznik wysokiego ryzyka

Agent planowania zatrudnienia nie jest systemem wysokiego ryzyka w trybie domyślnym. Staje się nim tylko gdy aktywowany jest opcjonalny moduł rekomendacji o zwolnieniach. Ta separacja jest celowa: EU AI Act Załącznik III(4)(b) klasyfikuje systemy AI w domenie zatrudnienia jako wysokie ryzyko, gdy decydują o zakończeniu stosunków pracy lub w niej uczestniczą. Prognozowanie headcount i capacity-planning nie podlegają temu; rekomendacje o zwolnieniach tak.

Gdy firma aktywuje moduł, natychmiast obowiązują: DPIA obowiązkowe zgodnie z art. 35 RODO, ocena zgodności zgodnie z EU AI Act art. 43, rejestracja w bazie danych EU zgodnie z art. 49, dokumentacja techniczna zgodnie z Załącznikiem IV, system zarządzania ryzykiem zgodnie z art. 9, zarządzanie danymi zgodnie z art. 10 i nadzór człowieka zgodnie z art. 14. RODO art. 22 dodatkowo zakazuje decyzji w pełni zautomatyzowanych ze skutkami prawnymi - rekomendacja o zwolnieniach nigdy nie może być realizowana bez decyzji końcowej człowieka, a pracownik ma prawo do wyjaśnienia, zaskarżenia i przeglądu człowieka.

W praktyce większość firm celowo nie aktywuje tego modułu. Dodatkowe obciążenie compliance regularnie przewyższa korzyść, ponieważ decyzja końcowa człowieka i tak jest obowiązkowa, a model ML dostarcza tylko drugą opinię.

## Sprawozdanie zarządu i raportowanie ESG

Dla spółek WIG20 + mWIG40 podlegających obowiązkom sprawozdawczości giełdowej, KSH art. 211 wymaga sprawozdania zarządu obejmującego zaangażowanie pracowników, wyniki konsultacji, wpływ restrukturyzacji, inwestycje w szkolenia i rozważania stakeholders. Agent generuje sprawozdanie KSH art. 211 automatycznie i śledzi zgodność z Dobrymi Praktykami Spółek Notowanych na GPW 2021 zaangażowania pracowników. Finalna akceptacja zarządu pozostaje ludzka - zarząd jest organem ludzkim, nie silnikiem decyzji. Rada nadzorcza KSH art. 219 monitoruje zgodność poprzez sprawozdania jakości audytu.

ESG CSRD ESRS S1 Pracownicy własni raportowanie jest obowiązkowe dla podmiotów 250+ pracowników z weryfikacją audytora obowiązkową od 2024 r. Agent dostarcza ilościowe punkty danych (stan zatrudnienia, rotacja, metryki różnorodności, godziny szkoleń i wskaźnik wypadków) z interfejsem audytora. Punkty jakościowe (strategia, ocena istotności i zaangażowanie interesariuszy) pozostają po stronie człowieka - agent dostarcza tylko podstawę danych.

## Cross-references w Warstwie Decyzji HR

Agent planowania zatrudnienia nie stoi sam. Dostarcza prognozowanie capacity do [Succession-Planning-Agent](/pl/katalog-agentow-hr/succession-planning-agent/) Klaster #28 dla pipelinów sukcesji na krytycznych stanowiskach, do [Talent-Pool-Agent](/pl/katalog-agentow-hr/talent-pool-management-agent/) Klaster #29 dla wymagań rekrutacyjnych na klaster umiejętności, do [Compensation-Benchmarking-Agent](/pl/katalog-agentow-hr/compensation-benchmarking-agent/) Klaster #26 dla budżetów centrów kosztów i do Performance-Review-Agent dla kohort kalibracji. Warstwa Decyzji jest wspólna i wymienia status konsultacji Ustawa 13.03.2003, wyniki audytu KP art. 11(3) i podstawę prawną RODO.

To wzajemne powiązanie zmienia izolowane silosy prognozowania w spójny system workforce governance, w którym każda zmiana planu automatycznie uruchamia obowiązki konsultacji, anty-dyskryminacji i ochrony danych. Gdy przedstawiciele związków zawodowych blokują plan restrukturyzacji, ponieważ wybór pracowników do zwolnienia jest niewiarygodny, system dostarcza regułową macierz wyboru z uzasadnieniem w ciągu godzin - zamiast czarnej skrzynki rekomendacji, której nikt nie potrafi wyjaśnić.

--- Works Council Coordination Agent ---
> Koordynuje proces między HR a Radą Zakładową: konsultacje, informacja i dokumentowanie odpowiedzi - terminowo i zgodnie z prawem.

Wypowiedzenie bez prawidłowej konsultacji z Radą Zakładową może być zakwestionowane. Trzeba pamiętać, że Rada Zakładowa w polskim systemie ma prawo konsultacji, ale nie prawo weta. Jednak brakujące lub niewłaściwe procedury konsultacyjne osłabiają pozycję pracodawcy w sporach sądowych. Rocznie do polskich sądów pracy wpływają dziesiątki tysięcy powództw dotyczących wypowiedzeń. Znaczna część z nich atakuje formalne wady w procedurze konsultacyjnej - ponieważ te wady stanowią najpewniejszą drogę do osłabienia ważności wypowiedzenia.

Problem to nie problem wiedzy. Działy HR znają przepisy. Problem to problem koordynacji.

## Pięć poziomów partycypacji, jeden proces bez systemu

Kodeks Pracy zna kilka poziomów zaangażowania Rady Zakładowej, każdy z własnymi regułami, własnymi terminami i własnymi konsekwencjami błędów:

```
Poziom          Charakter        Termin RZ         Skutek naruszenia
────────────────────────────────────────────────────────────────────
Informacja      Obowiązek        brak              Roszczenie o zaprzestanie
Konsultacja     Obowiązek        zwykle 14 dni     Wada procedury
Opinia          Doradcza          -                Utrudnienie sporu
Współdecyz.     Współudział      zwykle 7-14 dni   Działanie kwestionowane
Negocjacja      Dialog           zmienny           Postępowanie pojednawcze
```

Wyzwanie to nie znać tej tabeli. Wyzwanie to przy każdej pojedynczej akcji HR - wypowiedzenie, zatrudnienie, transfer, zaszeregowanie, zmiana czasu pracy - w ciągu sekund zidentyfikować właściwy poziom, zestawić właściwe dokumenty i uruchomić właściwy termin. W firmie z 1500 pracownikami w ciągu jednego tygodnia może trwać jednocześnie kilkanaście procedur konsultacyjnych: trzy zatrudnienia, jedno wypowiedzenie zwykłe, dwa transfery, jedna zmiana regulacji czasu pracy.

Każda z tych procedur ma inny wyzwalacz, inne dokumenty, inne terminy i inne ścieżki eskalacji. I każda pojedyncza jest w większości firm koordynowana e-mailem, papierową teczką obiegową lub ustnym uzgodnieniem. Nie ma centralnego kalendarza terminów. Nie ma automatycznej kontroli kompletności dokumentów. Nie ma systemu rozpoznającego, czy planowany transfer pracownika uruchamia obowiązek współdecydowania, czy tylko konsultacji.

## Dlaczego wady formalne osłabiają wypowiedzenia

Konsultacja z Radą Zakładową to najbardziej krytyczny punkt styku między HR a przedstawicielstwem pracowniczym. Wymagania są jasno sformułowane: przed każdym wypowiedzeniem Rada Zakładowa musi być poinformowana. Pracodawca musi wskazać osobę dotkniętą, podać rodzaj wypowiedzenia i przekazać powody. Rada Zakładowa przy wypowiedzeniach zwykłych ma zwykle dwa tygodnie na opinię.

W praktyce zawodzi w trzech miejscach.

Po pierwsze: niekompletna informacja. Pracodawca musi przekazać Radzie Zakładowej wszystkie powody, które z jego subiektywnego punktu widzenia przemawiają za wypowiedzeniem. Skrótowe opisy nie wystarczają. Rada Zakładowa musi móc wyrobić sobie osąd bez własnych dochodzeń. Jeśli brakuje istotnego szczegółu - na przykład obowiązków alimentacyjnych osoby dotkniętej przy doborze społecznym - cała konsultacja jest wadliwa.

Po drugie: błędne obliczanie terminów. Termin zaczyna się od otrzymania pełnej informacji przez Radę Zakładową. Nie od wysłania. Nie od zaproszenia na rozmowę. Od otrzymania pełnych dokumentów. Wypowiedzenie złożone dzień za wcześnie jest wadliwe proceduralnie.

Po trzecie: powody dodawane później. Powody wypowiedzenia, co do których Rada Zakładowa nie została wysłuchana, nie mogą być dodawane w procesie sądowym o wypowiedzenie. Co brakuje w konsultacji, brakuje przed sądem.

Każdy z tych błędów jest do uniknięcia. Żaden z nich nie wymaga osądu prawnego. Wszystkie trzy to błędy koordynacji: właściwa informacja była dostępna, ale nie została w pełni przekazana. Termin był znany, ale został źle obliczony. Powód istniał, ale nie został udokumentowany.

## Wąskie gardło przy zatrudnieniach

Wypowiedzenia są najbardziej widocznym miejscem, ale nie najczęstszym. Rada Zakładowa ma być informowana i konsultowana przy zatrudnieniach, transferach, zaszeregowaniach i przegrupowaniach.

W rosnącej firmie obsadzającej miesięcznie pięć do dziesięciu stanowisk te procedury działają równolegle. Każda z własnymi dokumentami, terminami, punktami eskalacji. Koordynacja przez e-mail i kalendarz działa, dopóki nie przestanie działać. A moment, w którym przestaje działać, kosztuje nie tylko czas - kosztuje stanowisko, bo kandydat nie czeka.

## Co zmienia się, gdy koordynacja staje się infrastrukturą

[Decision Layer](/pl/decision-layer/) rozkłada każdy proces konsultacji na pojedyncze kroki decyzyjne i definiuje dla każdego kroku: człowiek, reguła lub AI. Przypisanie poziomu partycypacji - który przepis obowiązuje, jakie dokumenty są potrzebne, jaki termin biegnie - to reguła. Kontrola kompletności dokumentów względem checklisty to reguła. Monitoring terminów to reguła. Decyzja, jak postępować ze sprzeciwem Rady Zakładowej, pozostaje u człowieka.

Konkretnie proces zmienia się w czterech miejscach.

Sprawdzenie partycypacji odbywa się automatycznie. Każda planowana akcja HR - wypowiedzenie, zatrudnienie, transfer, zmiana czasu pracy - jest sprawdzana względem Kodeksu Pracy. System rozpoznaje, czy wymagana jest konsultacja, współdecydowanie czy informacja. Nie specjalista HR musi znaleźć właściwy przepis. Silnik reguł go znajduje.

Dokumenty są sprawdzane względem checklisty. Dla każdego poziomu partycypacji i każdego typu akcji istnieje zdefiniowana lista: jakie informacje musi otrzymać Rada Zakładowa? Czy dane społeczne dotkniętej osoby są kompletne? Czy rodzaj wypowiedzenia jest prawidłowo wskazany? Czy powody są sformułowane, a nie tylko wymienione hasłowo? Sprawdzenie odbywa się przed przekazaniem do Rady Zakładowej, nie po.

Terminy są śledzone od momentu przekazania. Każdy termin biegnie z udokumentowanym momentem startu i automatyczną eskalacją przy upływie. Rada Zakładowa nie dotrzymała terminu? System dokumentuje fikcję zgody. Rada Zakładowa sprzeciwiła się? Odpowiedzialny pracownik HR jest natychmiast informowany, z następnymi krokami i relewantnymi terminami dla ewentualnych działań prawnych.

Cała procedura jest audytowalnie dokumentowana. Każdy krok, każdy dokument, każdy termin, każda opinia, każda decyzja. Gdy pracownik sześć miesięcy później zakwestionuje wypowiedzenie, a jego adwokat kwestionuje prawidłową konsultację, dostępny jest pełny dowód procedury. Nie jako zrekonstruowana chronologia z korespondencji e-mail, lecz jako audit trail zawierający każdy pojedynczy krok ze znacznikiem czasu i dowodem.

## Agent służący obu stronom

Większość agentów w obszarze HR pracuje dla jednej strony. Works Council Coordination Agent jest inny. Profesjonalizuje formalny framework - a z tego korzystają obie strony.

HR korzysta, bo żadne procedury nie upadają już z powodu wad formalnych. Bo przygotowanie dokumentów trwa godziny zamiast dni. Bo ryzyko wadliwej konsultacji spada do zera.

Rada Zakładowa korzysta, bo otrzymuje kompletne dokumenty. Bo jej terminy są obliczane poprawnie, a nie jednostronnie interpretowane przez pracodawcę. Bo dokumentacja tworzy transparentność, którą wcześniej musiała egzekwować.

Silnik sprawdzania partycypacji - który przepis przy jakiej akcji, które dokumenty, jaki termin - nie jest przy tym izolowaną funkcją. Każdy agent w Decision Layer uruchamiający akcję z istotnością dla Rady Zakładowej - Onboarding Agent przy zatrudnieniach, Payroll Agent przy przegrupowaniach, Workforce Planning Agent przy transferach - używa tej samej logiki sprawdzania. Kalendarz terminów, checklisty i audit trail stają się wspólną infrastrukturą. Kto rozumie Works Council Coordination jako rozwiązanie izolowane, nie docenia dźwigni. Kto rozumie to jako infrastrukturę, buduje podstawę dla każdego kolejnego agenta z istotnością dla prawa partycypacji.

--- Kontakt ---
> Porozmawiaj z nami o konkretnym procesie. Formularz kontaktowy i rezerwacja spotkania.

<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">

<div id="hq" class="scroll-mt-24">
<h2 class="text-h2 font-bold text-gosign-dark">Siedziba główna i Governance</h2>
<p class="text-body-lg text-gosign-text-light mt-2">Zarząd, architektura governance, projekty klientów DACH.</p>
<div class="mt-6 grid grid-cols-1 sm:grid-cols-2 gap-6">
<div>
<h3 class="text-body font-bold text-gosign-dark">Hamburg</h3>
<div class="text-body text-gosign-text-light mt-1 space-y-0.5">
<p>Gosign GmbH</p>
<p>Hallerstraße 8</p>
<p>20146 Hamburg, Niemcy</p>
</div>
</div>
<div>
<h3 class="text-body font-bold text-gosign-dark">Centrum Szkoleniowe Hamburg</h3>
<div class="text-body text-gosign-text-light mt-1 space-y-0.5">
<p>Grindelberg 77</p>
<p>20144 Hamburg</p>
</div>
</div>
</div>
</div>

<div id="market" class="mt-12 pt-8 border-t border-gosign-border scroll-mt-24">
<h2 class="text-h2 font-bold text-gosign-dark">Zarządzanie projektami i obecność rynkowa</h2>
<p class="text-body-lg text-gosign-text-light mt-2">Kierownicy projektów w Twojej strefie czasowej, w Twoim języku.</p>
<div class="mt-6 grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-3 gap-6">
<div>
<h3 class="text-body font-bold text-gosign-dark">Kraków</h3>
<div class="text-body text-gosign-text-light mt-1 space-y-0.5">
<p>Gosign - Biuro Kraków</p>
<p><a href="https://www.gosign.pl" target="_blank" rel="noopener noreferrer" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">gosign.pl</a></p>
</div>
</div>
<div>
<h3 class="text-body font-bold text-gosign-dark">Berlin</h3>
<div class="text-body text-gosign-text-light mt-1 space-y-0.5">
<p>Gosign GmbH - Biuro Berlin</p>
<p>Nogatstraße 46</p>
<p>12051 Berlin, Niemcy</p>
</div>
</div>
<div>
<h3 class="text-body font-bold text-gosign-dark">Barcelona</h3>
<div class="text-body text-gosign-text-light mt-1 space-y-0.5">
<p>Gosign - Biuro Barcelona</p>
<p><a href="https://www.gosign.es" target="_blank" rel="noopener noreferrer" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">gosign.es</a></p>
</div>
</div>
<div>
<h3 class="text-body font-bold text-gosign-dark">Lizbona</h3>
<div class="text-body text-gosign-text-light mt-1 space-y-0.5">
<p>Gosign - Biuro Lizbona</p>
<p><a href="https://www.gosign.pt" target="_blank" rel="noopener noreferrer" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">gosign.pt</a></p>
</div>
</div>
<div>
<h3 class="text-body font-bold text-gosign-dark">São Paulo <span class="text-gosign-text-light font-normal">(Biuro LATAM)</span></h3>
<div class="text-body text-gosign-text-light mt-1 space-y-0.5">
<p>Gosign - Biuro São Paulo</p>
<p><a href="https://www.gosign.pt" target="_blank" rel="noopener noreferrer" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">gosign.pt</a></p>
</div>
</div>
</div>
</div>

<div id="engineering" class="mt-12 pt-8 border-t border-gosign-border scroll-mt-24">
<h2 class="text-h2 font-bold text-gosign-dark">Inżynieria i Badania</h2>
<p class="text-body-lg text-gosign-text-light mt-2">Ponad 60 inżynierów. Partnerstwa uniwersyteckie w zakresie badań i rozwoju talentów.</p>
<div class="mt-6">
<h3 class="text-body font-bold text-gosign-dark">Lahore · Islamabad, Pakistan</h3>
<div class="text-body text-gosign-text-light mt-1 space-y-0.5">
<p>Centra rozwoju z partnerstwami uniwersyteckimi:</p>
<p><a href="https://pu.edu.pk/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-text-light transition-colors underline decoration-dotted">University of the Punjab</a> · <a href="https://www.comsats.edu.pk/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-text-light transition-colors underline decoration-dotted">COMSATS University</a></p>
<p><a href="https://www.gosign.pk" target="_blank" rel="noopener noreferrer" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">gosign.pk</a></p>
</div>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark">O Czym Rozmawiamy na Pierwszym Spotkaniu</h2>
<ul class="mt-4 space-y-2 text-body-lg text-gosign-text-light list-disc list-inside">
<li>Jaki proces ma być zautomatyzowany?</li>
<li>Jakie systemy są zaangażowane?</li>
<li>Jakie wymagania governance obowiązują?</li>
<li>Chmura, self-hosted czy hybryda?</li>
<li>Harmonogram i następne kroki</li>
</ul>
</div>
</section>

--- Od chatbotów do agentów AI: MCP, A2A i systemy Multi-Agent ---
> Co odróżnia agentów AI od chatbotów. Protokoły MCP i A2A, architektura agentów, orkiestracja Multi-Agent dla firm.

## Chatbot odpowiada. Agent działa.

Ta różnica określa wartość AI w firmach w 2026 roku. Chatbot odpowiada na pytania: „Ile dni urlopu mi zostało?". Agent realizuje procesy. Różnica nie jest stopniowa - jest fundamentalna.

Konkretny przykład: Pracownik zgłasza się na zwolnienie chorobowe. Agent HR przyjmuje zgłoszenie, sprawdza formularz pod kątem kompletności, porównuje okres z harmonogramem pracy, informuje kierownika zespołu, aktualizuje planowanie zasobów i dokumentuje zdarzenie w aktach osobowych. Cztery systemy, jeden agent, zero ręcznych operacji. Każdy krok możliwy do prześledzenia, każdy krok w Audit Trail.

To nie jest scenariusz przyszłości. To stan techniki w 2026 roku. I to jest powód, dla którego architektura agentów AI jest decyzją strategiczną, a nie zadaniem wyłącznie dla działu IT.

Ten artykuł opisuje architekturę agentów dla środowisk korporacyjnych, wyjaśnia nowe standardy MCP i A2A, przedstawia pięć konkretnych przypadków biznesowych z potencjałem oszczędności i definiuje wymagania Governance, bez których żaden agent nie powinien trafić na produkcję.

Gartner (2024) prognozuje, że do 2028 roku 33% aplikacji oprogramowania korporacyjnego będzie zawierać agentyczną AI - w porównaniu z mniej niż 1% w 2024 roku. Architektura, którą wybierzesz dziś, określi, czy ci agenci dostarczą wartość, czy stworzą ryzyko.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">W skrócie - Agenci AI dla firm</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Agenci AI realizują procesy, nie tylko odpowiadają na pytania. Różnica między chatbotem a agentem jest architektoniczna, nie stopniowa.</li>
<li>Architektura korporacyjnego agenta ma pięć warstw: interfejs użytkownika, orkiestracja, model AI, integracja narzędzi (MCP) i Governance.</li>
<li>MCP standaryzuje dostęp do narzędzi (agent-system), A2A standaryzuje komunikację między agentami (agent-agent). Oba redukują nakład integracyjny o rząd wielkości.</li>
<li>Cztery wymagania Governance są nienegocjowalne przed produkcją: Decision Layer, Human-in-the-Loop, Audit Trail i Rollback.</li>
<li>Zacznij od jednego agenta dla jednego procesu. Infrastruktura zbudowana dla pierwszego agenta jest platformą dla każdego kolejnego.</li>
</ul>
</div>

## Architektura agenta: pięć warstw

Agent AI nie jest systemem monolitycznym. Architektura korporacyjna składa się z pięciu warstw, z których każda ma jasno zdefiniowaną odpowiedzialność:

```
┌─────────────────────────────────────────┐
│          Interfejs użytkownika           │
│    (very-ai / Teams / Custom)            │
├─────────────────────────────────────────┤
│         Warstwa orkiestracji             │
│   (Routing, silnik reguł, eskalacja)     │
├─────────────────────────────────────────┤
│          Warstwa modelu AI               │
│  (Claude / GPT / Llama / gpt-oss -        │
│   zadania)                               │
├─────────────────────────────────────────┤
│       Integracja narzędzi (MCP)          │
│  (ERP, CRM, DMS, e-mail, kalendarz...)   │
├─────────────────────────────────────────┤
│      Governance & Audit Layer            │
│  (Logowanie, polityki, Human-in-the-Loop)│
└─────────────────────────────────────────┘
```

**Interfejs użytkownika.** Warstwa, przez którą pracownicy wchodzą w interakcję z agentem. Może to być dedykowany portal AI (jak opisano w artykule [Portal Enterprise AI: Więcej niż interfejs czatu](/pl/magazyn/enterprise-ai-chat-interface/)), integracja z Microsoft Teams lub dedykowany interfejs dla konkretnych działów.

**Warstwa orkiestracji.** Tu zapada decyzja, który agent przejmuje zadanie, który model zostanie użyty i kiedy nastąpi eskalacja. Warstwa orkiestracji zna zestawy reguł, zakresy odpowiedzialności i ścieżki eskalacji. To centrum dowodzenia.

**Warstwa modelu AI.** Model językowy wykonujący właściwe przetwarzanie: rozumienie tekstu, rozpoznawanie zależności, generowanie odpowiedzi. W architekturze niezależnej od modelu warstwa ta jest wymienna. Tańszy model do standardowych zapytań, wydajniejszy do złożonych analiz. Routing odbywa się automatycznie.

**Integracja narzędzi (MCP).** Połączenie z istniejącymi systemami: ERP, CRM, zarządzanie dokumentami, e-mail, kalendarz, system ticketowy. Przez Model Context Protocol (MCP) agenci uzyskują standaryzowany dostęp do tych systemów.

**Governance & Audit Layer.** Każda akcja agenta jest rejestrowana. Polityki definiują, co agent może, a czego nie może robić. Human-in-the-Loop jest wymuszany tam, gdzie jest wymagany. Ta warstwa nie jest opcjonalna. Jest warunkiem wstępnym wdrożenia produkcyjnego. [Decision Layer](/pl/decision-layer/) stanowi architektoniczny fundament tego Governance.

## MCP i A2A: nowe standardy

Dwa protokoły zmieniły w latach 2025/2026 sposób komunikacji agentów AI ze światem zewnętrznym i między sobą: MCP (Model Context Protocol) i A2A (Agent-to-Agent).

### MCP: Port USB dla AI

MCP to otwarty standard umożliwiający modelom AI dostęp do zewnętrznych źródeł danych i narzędzi. Analogia jest trafna: tak jak USB stworzył uniwersalny interfejs dla sprzętu, MCP tworzy uniwersalny interfejs dla integracji AI.

Przed MCP dla każdej kombinacji modelu AI i systemu docelowego trzeba było budować osobny konektor. Agent A łączy się z SAP - jeden konektor. Agent B łączy się z DMS - kolejny konektor. Agent C łączy się z kalendarzem - jeszcze jeden konektor. Przy dziesięciu systemach i trzech modelach daje to trzydzieści indywidualnych integracji.

Z MCP każdy system definiuje swoje możliwości raz, w standaryzowanym formacie: Jakie dane może dostarczyć? Jakie akcje może wykonać? Jakie parametry są wymagane? Każdy model kompatybilny z MCP może korzystać z tych możliwości bez kodu specyficznego dla systemu.

Dla firm oznacza to: nowe systemy można podłączać szybciej. Modele można wymieniać bez przebudowy integracji. Zależność od pojedynczych dostawców modeli maleje.

### A2A: Agenci rozmawiają ze sobą

A2A (Agent-to-Agent) jest odpowiednikiem MCP dla komunikacji między agentami. Podczas gdy MCP reguluje połączenie agent-system, A2A reguluje połączenie agent-agent.

Dlaczego to istotne? Ponieważ złożone procesy biznesowe rzadko są obsługiwane przez jednego agenta. Zgłoszenie chorobowe dotyczy HR, planowania zasobów, listy płac i potencjalnie zarządzania projektami. Każdy obszar ma wyspecjalizowanego agenta. A2A umożliwia tym agentom delegowanie zadań i wymianę wyników - z zdefiniowanymi uprawnieniami.

Co kluczowe: A2A nie oznacza współdzielonego dostępu do danych. Agent HR przekazuje agentowi Finance informację „Pracownik X jest nieobecny od daty Y", a nie pełne akta osobowe. Każdy agent widzi tylko to, czego potrzebuje do swojego zadania. Granice uprawnień pozostają nienaruszone.

## 5 przypadków biznesowych z konkretnym potencjałem oszczędności

Pytanie, które zadają decydenci, to nie „Co potrafi agent?" lecz „Co daje agent?". Oto pięć przypadków użycia z mierzalnym potencjałem oszczędności:

| Obszar | Przypadek użycia | Co robi agent | Potencjał oszczędności |
|---|---|---|---|
| HR | Onboarding | Zakładanie kont, przydzielanie szkoleń, planowanie spotkań wprowadzających, wysyłka maila powitalnego | 4-6 godz. na zatrudnienie |
| Finanse | Weryfikacja faktur | Odczyt faktury, weryfikacja z zamówieniem, kontrola kontowania, uruchomienie workflow zatwierdzenia | 70-80% mniej czasu przetwarzania |
| Dział prawny | Analiza umów | Ekstrakcja klauzul, porównanie ze standardowymi umowami, oznaczanie odchyleń | Godziny zamiast dni |
| IT | Triażowanie incydentów | Analiza zgłoszenia błędu, porównanie z known issues, tworzenie ticketu z priorytetem | Szybsza pierwsza reakcja |
| Operacje | Monitoring dostawców | Śledzenie terminów dostaw, porównanie z planem produkcji, proaktywne powiadomienie o opóźnieniu | Wczesne ostrzeganie zamiast naprawy |

Każdy z tych przypadków użycia podąża za tym samym wzorcem: agent przejmuje strukturalną, opartą na regułach część procesu. Człowiek zajmuje się wyjątkami, decyzjami wymagającymi oceny i zatwierdzeniami. Oszczędność czasu wynika nie z eliminacji pracy ludzkiej, lecz z eliminacji ręcznych czynności rutynowych.

**Onboarding HR w szczegółach.** Dziś pracownik kadr przy każdym nowym zatrudnieniu ręcznie koordynuje: zakładanie kont IT, konfigurację praw dostępu, przydzielanie obowiązkowych szkoleń, tworzenie planu wdrożenia, redagowanie maila powitalnego, konfigurację listy płac. Każdy krok to osobny system, każdy krok to ręczna operacja. Agent onboardingowy orkiestruje te kroki automatycznie: czyta umowę o pracę, rozpoznaje stanowisko, lokalizację i dział, i wykonuje kroki w odpowiednich systemach. Pracownik kadr zatwierdza cały proces, nie każdy pojedynczy krok.

**Weryfikacja faktur w szczegółach.** Faktura przychodząca jest odczytywana przez Document Agent. Agent wyodrębnia wystawcę, kwotę, pozycje, numer zamówienia. Automatycznie weryfikuje: Czy istnieje powiązane zamówienie? Czy pozycje i kwoty się zgadzają? Czy kontowanie jest prawidłowe? Czy kwota mieści się w granicach zatwierdzenia? Przy wyniku pozytywnym księgowanie jest przygotowywane. Przy odchyleniach sprawa jest eskalowana do odpowiedzialnego pracownika - z konkretnym powodem odchylenia, nie z generycznym komunikatem „Proszę sprawdzić".

## Wymagania Governance dla agentów

Agent bez Governance to ryzyko. Cztery wymagania muszą być spełnione przed wdrożeniem produkcyjnym:

**1. Decision Layer.** Każda decyzja agenta przechodzi przez [Decision Layer](/pl/decision-layer/). Dla każdej mikrodecyzji zdefiniowano: Czy agent może działać autonomicznie, czy obowiązuje zestaw reguł, czy musi zatwierdzić człowiek? Te reguły są wersjonowane, możliwe do prześledzenia i nie mogą być modyfikowane przez samego agenta.

**2. Human-in-the-Loop.** Przy zdefiniowanych typach decyzji architektura wymusza ludzką weryfikację. To nie jest funkcja, którą można aktywować. To zasada architektoniczna. Agent nie może obejść wymagania Human-in-the-Loop, ponieważ jest ono wymuszone technicznie, nie uzgodnione organizacyjnie.

**3. Audit Trail.** Każda akcja agenta generuje niezmienny wpis w dzienniku: Co było inputem? Który model został użyty? Która reguła została zastosowana? Jaki był wynik? Kiedy akcja została wykonana? Audit Trail jest podstawą audytu finansowego, rewizji wewnętrznej i kontroli Rady Zakładowej.

**4. Rollback.** Każda akcja agenta musi być odwracalna. Jeśli agent wygeneruje błędne księgowanie lub wyśle nieprawidłowe powiadomienie, proces musi dać się skorygować - technicznie, nie tylko organizacyjnie. Zdolność do rollbacku jest wymaganiem architektonicznym, nie późniejszym dodatkiem.

Te cztery wymagania są nienegocjowalne. Bez nich żadna Rada Zakładowa nie wyda pozytywnej opinii w procesie konsultacji, żaden biegły rewident nie zatwierdzi i żaden CIO nie przyjmie odpowiedzialności. Więcej o architekturze Governance w następnym artykule: [Decision Layer & Shadow AI](/pl/magazyn/decision-layer-shadow-ai/).

## Systemy Multi-Agent: specjalizacja zamiast uniwersalnego agenta

Następny poziom po pojedynczym agencie: wielu wyspecjalizowanych agentów współpracujących ze sobą. Nie jeden uniwersalny agent, który potrafi wszystko, lecz specjaliści, z których każdy opanował jedną domenę.

Przykład zgłoszenia chorobowego jako system Multi-Agent:

```
Zgłoszenie chorobowe otrzymane
│
Document Agent  →  Odczytuje i klasyfikuje zgłoszenie chorobowe
│
HR Agent      →  Sprawdza reguły: wynagrodzenie chorobowe, reintegracja, terminy
│
Workflow Agent  →  Informuje kierownika, aktualizuje harmonogram
│
Finance Agent   →  Aktualizuje listę płac
```

Każdy agent ma własne uprawnienia. Document Agent może czytać dokumenty, ale nie może tworzyć księgowań. Finance Agent może aktualizować listę płac, ale nie ma dostępu do akt osobowych. Granice uprawnień są wymuszone architektonicznie. Przez protokół A2A agenci komunikują tylko informacje, których agent odbierający potrzebuje do swojego zadania.

Agent orkiestrator koordynuje cały przebieg. Wie, który agent wykonuje który krok, w jakiej kolejności i co dzieje się w przypadku błędów. Orkiestrator ma przegląd, ale nie ma uprawnień operacyjnych. Deleguje, ale sam nie wykonuje.

Systemy Multi-Agent są wydajne, ale złożone. Liczba interakcji rośnie kwadratowo wraz z liczbą agentów. Debugowanie staje się bardziej pracochłonne. Wymagania Governance rosną.

## Zalecenie praktyczne: zacznij od małego

Pokusa, by od razu zacząć od systemu Multi-Agent, jest duża. Zalecenie jest jasne: zacznij od jednego agenta dla jasno zdefiniowanego procesu.

**Krok 1:** Zidentyfikuj proces, który jest strukturalny, oparty na regułach i wystarczająco częsty, by uzasadnić nakład pracy. Weryfikacja faktur, onboarding, analiza umów - wybierz jeden.

**Krok 2:** Wdróż jednego [agenta AI](/pl/uslugi/ai-agents/) dla tego procesu. Z Decision Layer, z Human-in-the-Loop, z Audit Trail. Nie jako prototyp, lecz jako system produkcyjny.

**Krok 3:** Mierz. Czas przetwarzania przed i po. Wskaźnik błędów. Koszt na transakcję. Satysfakcja pracowników operacyjnych.

**Krok 4:** Dopiero gdy pierwszy agent działa stabilnie, planuj drugiego. I dopiero gdy wielu agentów działa stabilnie, myśl o orkiestracji Multi-Agent.

To podejście nie jest zachowawcze. Jest pragmatyczne. Działający agent z udowodnioną wartością jest więcej wart niż ambitna koncepcja Multi-Agent, która utknęła w fazie pilotażu.

[Infrastruktura](/pl/uslugi/infrastruktura/) - hosting modeli, wektorowe bazy danych, silnik orkiestracji, API gateway - jest budowana przy pierwszym agencie i jest dostępna dla każdego kolejnego. Inwestycja w pierwszego agenta jest jednocześnie inwestycją w platformę.

Konkretny przykład: W portalu Enterprise AI [very-ai](/pl/magazyn/enterprise-ai-chat-interface/) użytkownicy mogą bezpośrednio z czatu uruchamiać przepływy Trigger.dev. Agent staje się wyzwalaczem łańcucha procesów - nie tylko rozmówcą. Platforma orkiestracji (→ [Artykuł 10](/pl/magazyn/orkiestracja-agentow-platformy/)) przejmuje realizację.

Gdzie te agenty faktycznie działają, na jakiej platformie, pokazuje [Artykuł 10: Orkiestracja agentów](/pl/magazyn/orkiestracja-agentow-platformy/).

---

**Enterprise AI-Infrastruktur Blueprint 2026 - Seria artykułów**

| ← Poprzedni | Przegląd | Następny → |
|:---|:---:|---:|
| [RAG i Document Intelligence: Jak AI rozumie Twoje dokumenty](/pl/magazyn/rag-document-intelligence-enterprise/) | [Przegląd](/pl/magazyn/infrastruktura-ai-blueprint-2026/) | [Decision Layer & Shadow AI: Kontrola zamiast chaosu](/pl/magazyn/decision-layer-shadow-ai/) |

*Wszystkie artykuły w tej serii: [Enterprise AI-Infrastruktur Blueprint 2026](/pl/magazyn/infrastruktura-ai-blueprint-2026/)*

---

**Chcesz wdrożyć pierwszego agenta AI dla konkretnego procesu biznesowego?** Gosign wspiera klientów korporacyjnych od analizy procesu do produkcyjnego agenta - niezależnie od modelu, z Decision Layer i pełnym Audit Trail.

<a href="/pl/kontakt/" target="_blank" rel="noopener noreferrer">Umów spotkanie</a>. 30 minut, w których zidentyfikujemy właściwy pierwszy przypadek użycia dla Twojej firmy.

--- Agent Governance w HR - Dlaczego CHRO musi prowadzić ---
> Agent Governance to nie temat IT. HR decyduje o regułach, definicji bias, progach eskalacji. CHRO musi prowadzić - nie delegować.

## Agent Governance to nie projekt IT

Gdy firmy wdrażają agentów AI w procesach HR, governance jest zwykle przypisywany do IT. IT ma zapewnić, że agent działa "poprawnie". IT ma wdrożyć kontrole, ustawić monitoring i zagwarantować compliance.

To błąd.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">W skrócie - Agent Governance dla HR</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Agent Governance określa, jakie decyzje agenci mogą podejmować, jak dokumentowane są działania i jak wersjonowane są reguły.</li>
<li>HR musi prowadzić governance - nie IT - ponieważ progi eskalacji, definicje bias i własność reguł wymagają ekspertyzy merytorycznej.</li>
<li>ISACA (2024) informuje, że 73% organizacji nie posiada formalnego frameworku governance AI - krytyczne procesy HR pozostają bez kontroli.</li>
<li>EU AI Act klasyfikuje systemy AI wpływające na decyzje zatrudnieniowe jako wysokiego ryzyka, wymagając nadzoru ludzkiego i monitoringu bias.</li>
<li>Zacznij teraz: zinwentaryzuj istniejące użycie AI, przypisz własność governance do HR, zaangażuj Radę Zakładową przed uruchomieniem pierwszego agenta.</li>
</ul>
</div>

IT może dostarczyć infrastrukturę techniczną - Audit Trail, monitoring, kontrole, portal audytora. Ale merytoryczne decyzje definiujące governance może podjąć tylko HR:

Jakie decyzje agent może podejmować autonomicznie? Jaka jest definicja "niskiego ryzyka" przy decyzji wynagrodzeniowej? W którym momencie musi interweniować człowiek? Jaki jest akceptowalny wskaźnik błędów? Jaka jest definicja bias w ocenie wyników? Które grupy pracowników zasługują na dodatkowe środki ochronne?

To nie są pytania techniczne. To są pytania HR.

## Trzy poziomy governance

Agent Governance ma trzy poziomy, a każdy wymaga ekspertyzy HR:

| Element | Cel | Odpowiedzialny |
|---------|-----|----------------|
| Matryca decyzji | Określa, co agent może decydować, a co pozostaje przy człowieku | HR + Dział prawny |
| Audit Trail | Każda akcja protokołowana, wersjonowana, odtwarzalna | IT (technicznie), HR (przegląd) |
| Koncepcja ról | Kto monitoruje, kto zatwierdza, kto eskaluje | HR |
| Szablony dla Rady Zakładowej | Gotowa dokumentacja do porozumienia zakładowego | HR + Rada Zakładowa |
| Ścieżka eskalacji | Co się dzieje przy niepewności lub niskiej pewności agenta | HR (progi), IT (routing) |

**Definicja reguł:** Jakie reguły stosuje agent? Układy zbiorowe, porozumienia zakładowe, wewnętrzne polityki. HR definiuje reguły, IT implementuje je w [Decision Layer](/pl/decision-layer/).

**Reguły eskalacji:** Kiedy musi interweniować człowiek? HR definiuje progi eskalacji: przy jakich typach decyzji, od jakich kwot, dla jakich grup pracowników. IT implementuje techniczną eskalację.

**Monitoring bias:** Co jest monitorowane i jak reaguje się na anomalie? HR definiuje metryki bias: Jakie grupy są porównywane? Co stanowi istotne odchylenie? Jakie są konsekwencje? IT implementuje monitoring statystyczny.

## Co się dzieje gdy HR nie prowadzi tego tematu

Gdy CHRO deleguje Agent Governance do IT, powstają luki w governance:

IT ustawia progi eskalacji według kryteriów technicznych - wartości pewności, wskaźniki błędów, czasy odpowiedzi. Kryteria merytoryczne - grupy pracowników, typy decyzji, limity wynagrodzeniowe - brakują.

Monitoring bias opiera się na metrykach statystycznych bez kontekstu HR. Statystyczne odchylenie 3% w zatwierdzaniu wniosków szkoleniowych - czy to problem? Bez ekspertyzy HR nikt nie jest w stanie tego ocenić.

Zestawy reguł są traktowane jako konfiguracja techniczna, nie jako merytoryczny governance. Zmiany w regułach są wdrażane bez zatwierdzenia HR. Efekt: agent działa według reguł, których nikt z działu merytorycznego nie zwalidował.

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Bezpłatny eBook: AI w HR</p>
<p class="text-body text-gosign-text mb-4">Checklista EU AI Act, framework decyzyjny, perspektywa rady zakładowej i ocena gotowości - poradnik governance dla liderów HR.</p>
<a href="/pl/ebook/ai-hr-poradnik-governance/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Pobierz bezpłatnie</a>
</div>

## Rola CHRO

CHRO musi prowadzić Agent Governance jako temat strategiczny. To nie oznacza, że CHRO pisze prompty lub konfiguruje modele. To oznacza:

**Własność reguł:** HR odpowiada za poprawność i aktualność reguł w Decision Layer. Każda zmiana reguł jest zatwierdzana przez HR.

**Polityka eskalacji:** HR definiuje matrycę eskalacji. Które decyzje autonomicznie, które z ludzką weryfikacją, które ręcznie.

**Strategia bias:** HR definiuje metryki bias i procesy reagowania na anomalie.

**Raportowanie:** HR otrzymuje regularne raporty governance z portalu audytora i je analizuje.

**Współpraca z Radą Zakładową:** HR prowadzi uzgodnienia z Radą Zakładową (lub związkami zawodowymi) dotyczące porozumienia zakładowego ws. AI i zapewnia, że wymagania Rady są wdrożone jako kontrole. W polskim kontekście dotyczy to również konsultacji ze związkami zawodowymi i radami pracowników zgodnie z Ustawą o radach pracowników.

Więcej informacji: [HR AI Agents](/pl/hr-ai-agents/)

<a href="/pl/kontakt/" target="_blank" rel="noopener noreferrer">Umów konsultację</a> - Pokażemy, jak zbudować Agent Governance dla HR.

--- AI Governance Dashboard: monitoring agentów w firmie ---
> Jak AI governance dashboard zapewnia przejrzystość działań agentów - dla IT, Rady Zakładowej i audytu wewnętrznego. Audit Trail, protokoły decyzji.

## Dlaczego dashboard nie wystarczy - ale bez dashboardu nic nie działa

AI governance to nie problem dashboardu. Governance to zasada architektoniczna. Ale bez warstwy prezentacji, która zapewnia przejrzystość działań agentów, governance pozostaje abstrakcyjna. Nikt w organizacji - ani IT, ani Rada Zakładowa, ani audyt wewnętrzny - nie jest w stanie ocenić, co agenci faktycznie robią.

AI governance dashboard to interfejs między techniczną architekturą governance a ludźmi, którzy ponoszą odpowiedzialność. Uwidacznia to, co [Decision Layer](/pl/decision-layer/) dokumentuje w tle.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">W skrócie - AI Governance Dashboard</p>
<ul class="text-body text-gosign-text space-y-2">
<li>AI governance dashboard to warstwa prezentacji danych Decision Layer - nie samodzielne narzędzie monitoringu.</li>
<li>Pokazuje działania agentów, ścieżki audytu, wydajność modeli i wersje reguł w czasie rzeczywistym.</li>
<li>Trzy widoki oparte na rolach (IT, zarząd, Rada Zakładowa) są warunkiem koniecznym skutecznej governance w praktyce.</li>
<li>Gartner (2024) prognozuje, że do 2026 roku organizacje stosujące frameworki AI governance odnotują o 40% mniej incydentów compliance związanych z AI.</li>
<li>Bez dashboardu nikt w organizacji nie jest w stanie zweryfikować, co agenci AI faktycznie robią.</li>
</ul>
</div>


## Co musi pokazywać AI governance dashboard

### Działania agentów: kto robi co

Każdy agent przy każdej akcji generuje wpis w protokole: znacznik czasu, dane wejściowe, zastosowana reguła, dane wyjściowe, status (przetworzone automatycznie, przekazane do zatwierdzenia, eskalowane). Dashboard agreguje te wpisy i umożliwia filtrowanie po okresie, dziale, typie agenta i statusie.

To nie jest klasyczny monitoring IT. To protokół decyzji - zbudowany dla ludzi, którzy muszą rozumieć, co agenci robią w ich obszarze odpowiedzialności.

### Audit Trail: pełna identyfikowalność

Dla każdej decyzji agenta istnieje kompletny zbiór danych: jaki dokument został przedstawiony? Jakie dane wyekstrahowano? Według jakiej reguły (w jakiej wersji) dokonano weryfikacji? Jaką rekomendację wydał agent? Kto zatwierdził lub eskalował?

Dashboard umożliwia przeszukiwanie i eksport tego [Audit Trail](/pl/governance/) - na potrzeby audytu wewnętrznego, biegłych rewidentów lub kontroli podatkowej.

### Monitoring modeli: który LLM dostarcza jakie wyniki

W [architekturze agnostycznej wobec modeli](/pl/uslugi/infrastruktura/) różne modele pracują równolegle. Dashboard pokazuje dla każdego modelu: czasy odpowiedzi, zużycie tokenów, koszty, wskaźniki błędów. Na tej podstawie podejmowane są świadome decyzje o wyborze i routingu modeli - nie na podstawie przeczuć, lecz rzeczywistych danych operacyjnych.

### Wersje reguł: co się zmieniło

Agenci działają na podstawie reguł decyzyjnych. Gdy reguła się zmienia - na przykład w wyniku aktualizacji układu zbiorowego pracy lub wejścia w życie nowego porozumienia zakładowego - musi być identyfikowalne: jaka była stara reguła? Jaka jest nowa? Od kiedy obowiązuje? Kto ją zatwierdził?

Dashboard pokazuje wersje reguł w formie osi czasu. Każda zmiana jest przypisana do osoby odpowiedzialnej i powiązana z Audit Trail.

<table class="w-full text-left text-sm">
<thead><tr class="border-b border-gosign-border">
<th class="py-2 pr-4 font-semibold">Komponent</th>
<th class="py-2 pr-4 font-semibold">Cel</th>
<th class="py-2 pr-4 font-semibold">Źródło danych</th>
</tr></thead>
<tbody>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Dziennik aktywności agentów</td><td class="py-2 pr-4">Śledzenie każdej akcji agenta w czasie rzeczywistym</td><td class="py-2 pr-4">Wpisy protokołu Decision Layer</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Przeglądarka Audit Trail</td><td class="py-2 pr-4">Przeszukiwalne, eksportowalne rekordy decyzji</td><td class="py-2 pr-4">Rekordy audytowe Decision Layer</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Monitor modeli</td><td class="py-2 pr-4">Porównanie wydajności i kosztów LLM</td><td class="py-2 pr-4">Metryki inferencji na model</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Oś czasu wersji reguł</td><td class="py-2 pr-4">Śledzenie zmian reguł z przypisaniem odpowiedzialności</td><td class="py-2 pr-4">Wersjonowane repozytorium reguł</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Dashboard eskalacji</td><td class="py-2 pr-4">Monitorowanie wskaźników Human-in-the-Loop</td><td class="py-2 pr-4">Zdarzenia eskalacji HITL</td></tr>
</tbody>
</table>

## Trzy widoki dla trzech grup odbiorców

Jeden dashboard, ale różne poziomy dostępu w zależności od roli.

Widok IT pokazuje wydajność techniczną: uptime agentów, opóźnienia modeli, wskaźniki błędów API, wykorzystanie zasobów. Służy operacyjnemu zarządzaniu i planowaniu pojemności.

Widok zarządu pokazuje wskaźniki biznesowe: przetworzone sprawy dziennie, wskaźnik automatyzacji, wskaźnik eskalacji, czasy przetwarzania. Służy ocenie ROI i raportowaniu do kierownictwa.

Widok Rady Zakładowej pokazuje zagregowane dane o użyciu: w jakich działach wdrożono agentów? Jak często decyzje są automatyzowane vs. przekazywane do ludzkiego zatwierdzenia? Jakie zmiany reguł zostały wprowadzone? Ten widok celowo nie zawiera danych osobowych na poziomie indywidualnym - zapewnia przejrzystość wdrożenia AI jako całości.

Ten trójpodział to nie opcja. To warunek konieczny, aby AI governance działała w praktyce. Bez widoku IT - brak stabilnej eksploatacji. Bez widoku zarządu - brak budżetu. Bez widoku Rady Zakładowej - brak [porozumienia zakładowego](/pl/governance/co-determination/).


## Governance dashboard jako komponent architektury

Dashboard to nie osobne narzędzie dokładane do infrastruktury AI po fakcie. To warstwa prezentacji, która operuje bezpośrednio na danych [Decision Layer](/pl/decision-layer/).

Każdy wpis Audit Trail, każda wersja reguły, każda metryka modelu jest generowana automatycznie przez Decision Layer - jako produkt uboczny normalnej eksploatacji, nie jako dodatkowy nakład pracy. Dashboard udostępnia te dane, umożliwia filtrowanie i eksport.

To jest [Governance by Design](/pl/governance/): przejrzystość nie wynika z retrospektywnego raportowania, lecz jest integralną częścią architektury.

W Gosign budujemy [infrastrukturę AI](/pl/uslugi/infrastruktura/) ze zintegrowaną warstwą governance. Dashboard nie jest opcją - jest częścią każdej infrastruktury agentów, którą dostarczamy.

--- Akt decyzyjny: dlaczego każda decyzja AI musi być podważalna ---
> Art. 86 EU AI Act daje osobie prawo do wyjaśnienia pojedynczej decyzji. Logi czatu i karty modelu tego nie spełniają. Akt decyzyjny tak.

Kandydat zostaje odrzucony. Wniosek o premię specjalną zostaje odrzucony. Zaszeregowanie wypada niżej, niż oczekiwano. W każdym z tych trzech przypadków brał udział agent AI - i w każdym z nich osoba, której to dotyczy, będzie mogła wkrótce wypowiedzieć słowa zarezerwowane dotąd dla prawników: "Proszę wyjaśnić mi rolę systemu AI i najważniejsze elementy tej decyzji."

To nie jest scenariusz hipotetyczny. To dosłowny rdzeń artykułu 86 [Rozporządzenia (UE) 2024/1689](https://artificialintelligenceact.eu/article/86/) - najbardziej niedocenianego artykułu EU AI Act. Branża dyskutuje o dokumentacji modeli, klasach ryzyka i terminach. Artykuł 86 stawia inne pytanie: Czy potrafisz wyjaśnić jedną konkretną decyzję? Nie swój system. Tę jedną decyzję.

Większość firm nie potrafi. Nie dlatego, że ich AI jest słaba - lecz dlatego, że ich architektura dokumentuje niewłaściwą jednostkę. Protokołują rozmowy, tokeny i zachowanie systemu. Podważalne jest jednak tylko to, co zostało utrwalone jako decyzja. Ten artykuł opisuje brakujący artefakt: akt decyzyjny.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">W skrócie - Akt decyzyjny</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Podważyć można tylko to, co zostało utrwalone jako decyzja. Akt decyzyjny to atomowy, niezmienny dowód pojedynczej mikrodecyzji: input, zastosowana reguła fachowa z wersją i źródłem, wynik, pewność, wersja modelu, znacznik czasu, ścieżka podważenia. Logi odpowiadają na "Co się stało?" - akt decyzyjny odpowiada na "Dlaczego zdecydowano w ten sposób?".</li>
<li>Art. 86 EU AI Act daje osobie prawo do wyjaśnienia pojedynczej decyzji - a TSUE już dziś wymaga takiego samego uzasadnienia pojedynczego przypadku na gruncie RODO. Opis systemu nie wystarczy.</li>
<li>Logi czatu, trace observability i karty modelu dokumentują interakcję, infrastrukturę i system - ale nie uzasadnienie merytoryczne. Własna dokumentacja Microsoftu potwierdza: log audytowy Copilota nie rejestruje ani treści promptów, ani wersji modelu. A teksty rozumowania modeli językowych - według badań Anthropic - tylko w jednej czwartej przypadków oddają faktyczną podstawę decyzji.</li>
<li>Agent AI nigdy nie podejmuje "jednej decyzji" - na jedną sprawę podejmuje dziesiątki mikrodecyzji. Każda z nich może być prawnie istotna: TSUE traktuje już zautomatyzowany scoring jako decyzję, a nie dopiero wynik końcowy.</li>
<li>Podważalności nie da się dobudować po fakcie: decyzja, która nigdy nie została zamodelowana jako decyzja, nie może zostać uzasadniona później. Dlatego akt decyzyjny jest zasadą architektoniczną Decision Layer - nie funkcją compliance.</li>
</ul>
</div>

## Agentyczna AI oznacza: przeniesienie praw decyzyjnych

Dane wielkich firm doradczych układają się w 2026 roku w spójny obraz. [McKinsey](https://www.mckinsey.com/capabilities/quantumblack/our-insights/seizing-the-agentic-ai-advantage) nazywa to paradoksem gen AI: prawie osiem na dziesięć firm stosuje generatywną AI, a niemal równie duży odsetek nie odnotowuje mierzalnego przełożenia na wynik finansowy - ponieważ horyzontalne asystenty wdraża się szeroko, podczas gdy wartościotwórcze, wertykalne przypadki użycia grzęzną na etapie pilotażu. [Gartner](https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027) prognozuje, że ponad 40 procent projektów agentycznej AI zostanie zaniechanych do końca 2027 roku - wyraźnie również z powodu niewystarczających kontroli ryzyka. Ta sama prognoza zakłada, że do 2028 roku co najmniej 15 procent codziennych decyzji w pracy będzie podejmowanych autonomicznie przez agentów AI.

Oba stwierdzenia razem ujawniają zasadnicze napięcie: firmy przenoszą prawa decyzyjne na maszyny, nie dysponując infrastrukturą, która pozwala za te decyzje odpowiadać. Dokładnie tak McKinsey opisuje erę agentyczną w swoim badaniu zaufania z 2026 roku - pytanie przewodnie przesuwa się z "Czy model jest dokładny?" na "Kto odpowiada, gdy system działa?" ([State of AI trust in 2026](https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/tech-forward/state-of-ai-trust-in-2026-shifting-to-the-agentic-era)).

Luka governance jest skwantyfikowana we wszystkich źródłach:

| Ustalenie | Liczba | Źródło |
|---|---|---|
| Projekty agentycznej AI zaniechane do końca 2027 - m.in. z powodu niewystarczających kontroli ryzyka | ponad 40% | [Gartner, 2025](https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027) |
| Przedsiębiorstwa z dojrzałym governance dla autonomicznych agentów | tylko 21% | [Deloitte, 2025](https://www.deloitte.com/us/en/insights/topics/emerging-technologies/ai-agents-scaling-faster.html) |
| Kadra kierownicza ds. technologii, której adopcja AI już wyprzedziła własną zdolność governance | 77% | [IBM IBV, 2026](https://www.cio.com/article/4182288/cios-are-being-held-accountable-for-ai-they-dont-fully-control-ibm-study-finds.html) |
| CIO/CTO pociągani do odpowiedzialności za systemy AI, których nie kontrolują w pełni | około dwie trzecie | [IBM IBV, 2026](https://www.cio.com/article/4182288/cios-are-being-held-accountable-for-ai-they-dont-fully-control-ibm-study-finds.html) |
| Zgłoszone incydenty AI w 2024 - rekordowy poziom, +56,4% rok do roku | 233 | [Stanford HAI AI Index, 2025](https://hai.stanford.edu/ai-index/2025-ai-index-report/responsible-ai) |
| Mniej incydentów AI, gdy governance jest wbudowane bezpośrednio w system, zamiast nadzoru ręcznego | 25% | [IBM IBV, 2026](https://www.ibm.com/thought-leadership/institute-business-value/en-us/report/ai-governance-trends) |

Ostatni wiersz jest najważniejszy: wbudowane governance działa mierzalnie lepiej niż kontrola następcza. Dokładnie w tym miejscu pytanie staje się konkretne - co "wbudowane" oznacza technicznie. Odpowiedź Najostrzej widać to w HR: przekazanie agentom prawa do decydowania zmienia model operacyjny - a każda z tych decyzji dotyka konkretnej osoby: jej zwolnienia lekarskiego, jej wynagrodzenia, jej zaszeregowania. zaczyna się od prawa.

## Czego wymaga artykuł 86 - i dlaczego dokumentacja systemu tego nie spełnia

EU AI Act zna dwa zasadniczo różne poziomy przejrzystości, które w dyskusji o compliance są nieustannie mylone:

| Poziom | Podstawa prawna | Adresat | Moment | Odpowiada na pytanie |
|---|---|---|---|---|
| Przejrzystość systemu | Art. 11 (dokumentacja techniczna), art. 13 (instrukcja obsługi dla podmiotu stosującego) | organ, podmiot stosujący | przed uruchomieniem | "Jak działa system w ogóle?" |
| Wyjaśnienie pojedynczego przypadku | Art. 86 AI Act, art. 15 ust. 1 lit. h i art. 22 RODO | osoba, której dotyczy | po decyzji | "Dlaczego ta jedna decyzja wypadła w ten sposób?" |

[Artykuł 86](https://artificialintelligenceact.eu/article/86/) daje każdej osobie, która podlega decyzji opartej na systemie AI wysokiego ryzyka z Załącznika III i jest przez nią dotknięta prawnie lub w podobnie istotny sposób, roszczenie wobec podmiotu stosującego: do jasnych i merytorycznych wyjaśnień dotyczących roli systemu AI w procedurze podejmowania decyzji oraz głównych elementów podjętej decyzji. To sformułowanie odnoszące się do przypadku, nie do systemu. Karta modelu opisuje model. Artykuł 86 pyta o przypadek.

Trybunał Sprawiedliwości UE wyłożył tę samą zasadę dla RODO już wcześniej - w dwóch wyrokach, które powinien znać każdy, kto odpowiada za decyzje AI:

**[SCHUFA, C-634/21](https://eur-lex.europa.eu/legal-content/PL/TXT/PDF/?uri=CELEX:62021CJ0634) (grudzień 2023):** Już zautomatyzowane utworzenie wartości scoringowej jest zautomatyzowaną decyzją w indywidualnym przypadku w rozumieniu art. 22 RODO, gdy tylko podmiot trzeci przypisuje jej rozstrzygające znaczenie. Konsekwencja sięga daleko poza scoring zdolności kredytowej: obowiązek prześledzenia odnosi się do samej oceny maszynowej - nie dopiero do następczej decyzji końcowej, którą podpisuje człowiek.

**[Dun & Bradstreet Austria, C-203/22](https://www.dpcuria.eu/case?reference=C-203%2F22) (luty 2025):** Administrator musi wyjaśnić faktycznie zastosowaną procedurę tak, by osoba mogła prześledzić, które z jej danych w jaki sposób wpłynęły na decyzję. Wyjaśnienie kontrfaktyczne może wystarczyć - na przykład: przy jakiej zmianie danych wejściowych wynik wypadłby inaczej? Oraz: tajemnice handlowe nie uzasadniają blankietowej odmowy; w razie konfliktu informacje należy ujawnić właściwemu organowi lub sądowi, które wówczas dokonają wyważenia.

Wyjaśnienie kontrfaktyczne dla pojedynczego przypadku wymaga, by dla każdej decyzji faktycznie użyte dane wejściowe oraz zastosowana reguła były zapisane w ustrukturyzowanej formie. Z ogólnego opisu systemu nie da się tego odtworzyć.

Do tego dochodzi pointa, która w dyskusji o compliance regularnie umyka: [art. 12](https://artificialintelligenceact.eu/article/12/) zobowiązuje systemy wysokiego ryzyka do automatycznej rejestracji przez cały okres eksploatacji, a [art. 26 ust. 6](https://artificialintelligenceact.eu/article/26/) zobowiązuje podmioty stosujące do przechowywania tych logów co najmniej sześć miesięcy. Jakie treści mają zawierać logi, ustawa definiuje jednak tylko dla systemów biometrycznych. Dla systemów HR i finansowych AI Act nakazuje zdolność rejestracji - schemat treści pozostawia jednak otwarty. To, co zostaje utrwalone przy każdej decyzji, jest zadaniem projektowym podmiotu stosującego. Kto rejestruje tu tylko zużycie tokenów i znaczniki czasu, spełnia literę art. 12, ale nie sprosta art. 86.

Dla uporządkowania terminów: zgodnie z obowiązującym prawem obowiązki wysokiego ryzyka mają zastosowanie od 2 sierpnia 2026 r., a wstępnie uzgodnione w Digital Omnibus z 7 maja 2026 r. przesunięcie tego terminu na 2 grudnia 2027 r. nie zostało jeszcze formalnie przyjęte. Nie zmienia to klasyfikacji procesów HR jako wysokiego ryzyka ([Załącznik III nr 4](https://artificialintelligenceact.eu/annex/3/)) ani cywilnoprawnego obowiązku wyjaśnialności, który [obowiązuje na całym świecie już od dawna](/pl/magazyn/eu-ai-act-obowiazuje-na-calym-swiecie/). Szczegóły terminów i obowiązków omawia [EU AI Act 2026: status, terminy, potrzeba działania](/pl/magazyn/eu-ai-act-2026-przedsiebiorstwa/).

## "Decyzja AI" nie istnieje - istnieją dziesiątki mikrodecyzji

Kto traktuje artykuł 86 operacyjnie poważnie, natychmiast napotyka problem granularności: Czym dokładnie jest "ta decyzja"?

<div class="not-prose my-10 grid grid-cols-1 md:grid-cols-2 gap-4">
  <div class="border border-base rounded-soft overflow-hidden bg-surface-dim opacity-90">
    <div class="px-4 py-2.5 border-b border-base font-code text-xs uppercase tracking-wider text-muted">JEDNA &#8222;DECYZJA AI&#8220;</div>
    <div class="p-5">
      <div class="font-code text-xs text-muted mb-3">input: wniosek MA-4711</div>
      <div class="flex items-center justify-center h-20 rounded bg-[#2e2e3e] border border-[#555]">
        <span class="font-display text-3xl text-white/40">?</span>
      </div>
      <div class="mt-3 font-code text-xs text-primary">wynik: odrzucono</div>
      <div class="mt-4 pt-3 border-t border-base font-code text-xs text-muted">1 wynik &#183; 0 uzasadnie&#324; &#183; bez mo&#380;liwo&#347;ci podwa&#380;enia <span aria-hidden="true">&#10007;</span></div>
    </div>
  </div>
  <div class="border-2 rounded-soft overflow-hidden bg-surface-raised" style="border-color: var(--accent-primary);">
    <div class="px-4 py-2.5 border-b border-base font-code text-xs uppercase tracking-wider text-accent">13 MIKRODECYZJI</div>
    <div class="p-5">
      <div class="font-code text-xs text-muted mb-3">input: wniosek MA-4711</div>
      <div class="flex flex-wrap gap-1.5">
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #0369A1;">01</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #0369A1;">02</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #0369A1;">03</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #0369A1;">04</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #0369A1;">05</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #0369A1;">06</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #0369A1;">07</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #0369A1;">08</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #6D4ED8;">09</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #0369A1;">10</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #0369A1;">11</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #B45309;">12</span>
          <span class="inline-flex w-7 h-7 rounded-full items-center justify-center font-code text-[10px] font-bold text-white" style="background: #B45309;">13</span>
      </div>
      <div class="mt-3 flex flex-wrap gap-3 font-code text-[11px] text-muted">
        <span><span class="inline-block w-2.5 h-2.5 rounded-full align-middle mr-1" style="background:#0369A1;"></span>Regu&#322;a (10)</span>
        <span><span class="inline-block w-2.5 h-2.5 rounded-full align-middle mr-1" style="background:#6D4ED8;"></span>AI (1)</span>
        <span><span class="inline-block w-2.5 h-2.5 rounded-full align-middle mr-1" style="background:#B45309;"></span>Cz&#322;owiek (2)</span>
      </div>
      <div class="mt-4 pt-3 border-t border-base font-code text-xs text-primary">13 akt&#243;w &#183; 13 uzasadnie&#324; &#183; ka&#380;da do podwa&#380;enia <span class="text-accent" aria-hidden="true">&#10003;</span></div>
    </div>
  </div>
</div>

Ta dekompozycja nie jest związana z żadną jurysdykcją. Decyzja kredytowa rozkłada się według tej samej mechaniki: weryfikacja tożsamości (zestaw reguł), ekstrakcja dochodu z dokumentów (AI, z wartością pewności), wyliczenie scoringu (zestaw reguł, wersjonowany), routing progowy (zestaw reguł), głos człowieka w przypadku granicznym (człowiek). Które prawo wiąże pojedynczą mikrodecyzję - RODO art. 22, UK GDPR, LGPD art. 20 czy amerykański Equal Credit Opportunity Act - zależy od rynku. Sama dekompozycja jest wszędzie taka sama. Jak głęboko sięga w regulowanym procesie, pokazuje przykład, którym europejskie działy HR zajmują się codziennie:

Przetworzyć zwolnienie lekarskie - to brzmi jak jeden proces. W rzeczywistości kryje się w nim kilkanaście pojedynczych decyzji: Czy elektroniczne zwolnienie e-ZLA zostało poprawnie pobrane z profilu płatnika w PUE ZUS (eZUS) do systemu kadrowo-płacowego? Czy przysługuje wynagrodzenie chorobowe wg art. 92 Kodeksu pracy - i w jakiej wysokości (80 czy 100 procent)? Czy chodzi o zwykłą chorobę, czy o niezdolność przypadającą na okres ciąży albo powstałą wskutek wypadku w drodze do pracy lub z pracy (art. 92 § 1 pkt 2 KP), gdzie obowiązuje 100 procent? Czy wyczerpano roczny limit 33 dni (lub 14 dni dla pracowników 50+), po którym następuje przejście na zasiłek chorobowy ZUS z ustawy zasiłkowej (ustawa z 25.06.1999 r. o świadczeniach pieniężnych z ubezpieczenia społecznego w razie choroby i macierzyństwa)? Czy osiągnięto próg 182 dni nieprzerwanej niezdolności, który uruchamia orzecznictwo lekarskie ZUS? Kto zostaje o czym poinformowany - i o czym wyraźnie nie, by nie ujawnić danych zdrowotnych z RODO art. 9?

[Decision Layer](/pl/decision-layer/) rozkłada każdy proces biznesowy dokładnie na te mikrodecyzje i z góry przypisuje każdą z nich jednemu z [trzech typów decydentów](/pl/magazyn/trzy-rodzaje-decyzji/) - człowiek, zestaw reguł lub AI:

| Mikrodecyzja (zwolnienie lekarskie) | Decydent | Dlaczego |
|---|---|---|
| Pobranie e-ZLA z profilu płatnika w PUE ZUS (eZUS) | Zestaw reguł | deterministyczne, brak miejsca na interpretację |
| Wyliczenie wynagrodzenia chorobowego wg art. 92 KP (80 / 100%) | Zestaw reguł | stałe wyliczenie limitu i kwoty z podstawy 12 miesięcy |
| Routing do zasiłku chorobowego ZUS po wyczerpaniu 33 / 14 dni | Zestaw reguł | deterministyczna reguła limitu rocznego |
| Wykrycie progu 182 / 270 dni i routing do orzecznictwa ZUS | Zestaw reguł | ustawowy próg długoterminowej niezdolności |
| Statystyczne oznaczenie nietypowych wzorców nieobecności | AI (wskaźnik) | wykrywanie anomalii, wynik jest sygnałem do przeglądu, nie decyzją kadrową |
| Rozmowa o powrocie do pracy i adaptacji stanowiska | Człowiek | relacja zaufania, ocena uznaniowa |
| Rozwiązanie umowy z powodu choroby (art. 53 KP) | Człowiek | przesłanki art. 53 KP, odwrócony ciężar dowodu wg art. 18³ᵇ § 1 Kodeksu pracy |

To rozłożenie nie jest ćwiczeniem akademickim - jest warunkiem podważalności. Bo logika SCHUFA z TSUE obowiązuje na każdym poziomie: skoro już zautomatyzowany scoring jest decyzją w sensie prawnym, to także maszynowe sprawdzenie terminu, maszynowa klasyfikacja dokumentu, maszynowa rekomendacja zaszeregowania jest każdorazowo potencjalnie podważalnym aktem - nie dopiero wynik końcowy. Firma, która dokumentuje tylko wynik końcowy, na pytanie "Dlaczego mój wniosek został odrzucony?" może odpowiedzieć jedynie: "Tak wyszło z procesu." To dokładnie ta odpowiedź czarnej skrzynki, której nie akceptuje żaden sąd pracy.

Jak głęboko sięga ten podział w praktyce, pokazuje [katalog agentów HR](/pl/katalog-agentow-hr/): każdy agent z pełną tabelą mikrodecyzji - dla każdego kroku typ decydenta, uzasadnienie, podstawa prawna i ścieżka podważenia.

## Dlaczego logi, trace i karty modelu nie odpowiadają na to pytanie

Branża odpowiedziała na potrzebę dokumentacji - ale na trzech poziomach, które wszystkie omijają pojedynczą decyzję:

| Poziom | Narzędzia | Dokumentuje | NIE odpowiada na |
|---|---|---|---|
| Interakcja | Logi czatu, historia konwersacji, zdarzenia audytowe Copilota | kto kiedy rozmawiał z systemem, jakie zasoby zostały dotknięte | która reguła fachowa była podstawą decyzji |
| Infrastruktura | Observability LLM (trace, spany), OpenTelemetry GenAI | prompty, wywołania narzędzi, tokeny, opóźnienia wzdłuż wykonania | dlaczego wynik wypadł merytorycznie tak - i czy jest poprawny |
| System | Karty modelu, dokumentacja techniczna, platformy governance (inwentarz modeli, rejestr ryzyk) | jak model działa ogólnie, jakie ryzyka ma system | jakikolwiek konkretny pojedynczy przypadek |

To nie retoryczna przesada - tak wynika z dokumentacji producentów. [Dokumentacja Purview Microsoftu](https://learn.microsoft.com/en-us/purview/audit-copilot) podaje dla logu audytowego Copilota, że nie rejestruje on faktycznych promptów i odpowiedzi, a nazwa i wersja modelu nie są dostępne w scenariuszach Microsoft 365 Copilot. W ekosystemie Salesforce luka nazwana jest wprost: klasyczne ślady audytowe zbudowano dla ludzi klikających przyciski - widać, że coś się zmieniło, [ale nie dlaczego](https://www.sweep.io/blog/the-audit-trail-of-an-ai-agent). A platformy governance jak IBM watsonx.governance czy Credo AI odpowiadają na pytanie "Czy ten system jest zinwentaryzowany, oceniony pod kątem ryzyka i zgodny z politykami?" - ważne pytanie, ale inne niż "Na czym opierało się zaszeregowanie pani M. 14 maja o 10:42?".

Pozostaje pozornie najbliższe wyjście: po prostu pozwolić, by model sam uzasadnił własną decyzję. Modele rozumujące generują łańcuchy uzasadnień - czemu nie zarchiwizować ich jako dowodu? Bo - jak pokazują badania - nie oddają wiernie tego, na czym decyzja faktycznie się opierała. [Badania Anthropic](https://www.anthropic.com/research/reasoning-models-dont-say-think) nad wiernością łańcucha rozumowania pokazują: nawet w sprzyjających warunkach modele rozumujące ujawniają faktycznie użyte czynniki decyzyjne tylko w około jednej czwartej przypadków - istotne czynniki wpływu pozostają ukryte nawet wtedy, gdy czyta się kompletny łańcuch uzasadnienia. Wygenerowane uzasadnienie to tekst o decyzji. Nie jest podstawą decyzji.

Badania nad podważalnością wyciągają z tego rozstrzygający wniosek: wyjaśnialność i podważalność to dwa środki do tego samego celu - samo wyjaśnienie, bez ścieżki podważenia, tego celu nie osiąga ([Schmude i in., 2025](https://arxiv.org/abs/2504.18236)). Podważalność liczy się z tym, że decyzja może być błędna, i wymaga dowodów, by ją obalić. Metody wyjaśniania post-hoc pokazują w najlepszym razie, że gdzieś w sąsiedztwie decyzji mogą leżeć błędy; dowodu, że ta jedna decyzja była wadliwa, nie dostarczają. A [Moreira i in. (2025)](https://arxiv.org/html/2506.01662v1) przesuwają miarę z samego zrozumienia na zdolność działania: wyjaśnienie musi umożliwić osobom i kontrolerom aktywne zakwestionowanie, podważenie i wpłynięcie na wynik - nie tylko prześledzenie, dlaczego tak zdecydowano.

Z trace tokenów nikt tego nie zrobi. Z aktem decyzyjnym - tak.

## Akt decyzyjny: dowód na każdą decyzję

Akt decyzyjny to atomowy, niezmienny, ustrukturyzowany dowód pojedynczej merytorycznej mikrodecyzji. Powstaje w momencie decyzji - nie jako następcza rekonstrukcja - i zawiera wszystko, czego art. 86, art. 12 i orzecznictwo TSUE wymagają dla pojedynczego przypadku:

| Pole | Treść | Czemu służy prawnie |
|---|---|---|
| Input | jakie dane, jaki dokument, jaki hash | C-203/22: "które dane w jaki sposób wpłynęły" |
| Reguła fachowa + wersja + źródło | np. regulamin premiowania § 12 ust. 3, wersja 2024-Q3, obowiązuje od 01.07.2024 | uzasadnienie, które się obroni - pole, którego nie mają logi ani trace |
| Typ decydenta | człowiek, zestaw reguł lub AI - z uzasadnieniem routingu | art. 14: dowód skutecznego nadzoru ludzkiego |
| Pewność | wartość pewności i próg w momencie decyzji | dowód zarządzania ryzykiem (art. 9), prześledzenie eskalacji |
| Wersja modelu i promptu | który model językowy, który szablon promptu, która wersja | odtwarzalność; pole brakujące w logu audytowym Copilota |
| Wynik + znacznik czasu | co zostało zdecydowane, kiedy (UTC) | przechowywanie wg art. 26 ust. 6, niezmienność wpisu wg ustawy o rachunkowości |
| Adnotacja Human-in-the-Loop | kto sprawdził, czy zatwierdził, czy odstąpił | art. 14 ust. 4: pominięcie, unieważnienie lub odwrócenie wyniku, przerwanie działania systemu - udokumentowane |
| Ścieżka podważenia | kto może podważyć tę decyzję i gdzie | roszczenie z art. 86 możliwe do spełnienia w praktyce |

Tak wygląda akt rzeczywistej sprawy - cztery z 13 mikrodecyzji przetwarzania zwolnienia lekarskiego:

<div class="not-prose my-10 bg-surface-raised border border-base rounded-soft overflow-hidden shadow-sm">
  <div class="px-5 py-4 border-b border-base bg-surface-dim">
    <div class="flex items-center gap-3 mb-2">
      <div class="flex gap-1.5" aria-hidden="true">
        <span class="w-2.5 h-2.5 rounded-full bg-[#FF5F56]"></span>
        <span class="w-2.5 h-2.5 rounded-full bg-[#FFBD2E]"></span>
        <span class="w-2.5 h-2.5 rounded-full bg-[#27C93F]"></span>
      </div>
      <span class="font-code text-xs text-muted">decision-record / zwolnienie-lekarskie / 2026-05-14 / EMP_0x52a8</span>
    </div>
    <p class="text-small text-primary">Wpływ e-ZLA 14.05.2026, godz. 07:12. Sprawa przetworzona w 54 sekundy - rozłożona na 13 udokumentowanych mikrodecyzji.</p>
    <div class="mt-3 flex h-7 rounded overflow-hidden text-xs font-bold text-white" aria-label="Rozkład decydentów: 10 reguły, 1 AI, 2 człowiek">
      <div class="flex items-center justify-center" style="width: 77%; background: #0369A1;">10 Reguła</div>
      <div class="flex items-center justify-center" style="width: 8%; background: #6D4ED8;">1</div>
      <div class="flex items-center justify-center" style="width: 15%; background: #B45309;">2 Człowiek</div>
    </div>
  </div>
  <ol class="divide-y divide-base">
    <li class="p-5">
      <div class="flex items-start gap-4">
        <div class="flex-shrink-0 w-9 h-9 rounded-full flex items-center justify-center font-code text-xs font-bold border" style="background: rgba(3,105,161,0.08); border-color: rgba(3,105,161,0.3); color: #0369A1;">02</div>
        <div class="flex-1 min-w-0">
          <div class="flex flex-wrap items-center gap-2 mb-1.5">
            <span class="text-body font-semibold text-primary">Wyliczenie wynagrodzenia chorobowego wg art. 92 KP</span>
            <span class="inline-flex items-center gap-1 px-2 py-0.5 text-xs font-bold uppercase tracking-wider rounded text-white" style="background: #0369A1;">Reguła</span>
          </div>
          <p class="text-small text-primary font-medium mb-2">80% podstawy od 14.05.2026</p>
          <div class="px-3 py-2 bg-surface border border-base rounded font-code text-xs text-primary/80"><span class="text-muted">input:</span> okres e-ZLA 14-27.05 · dane kadrowe EMP_0x52a8</div>
          <div class="mt-2 font-code text-xs text-muted"><span>rule:</span> <span class="text-primary">art. 92 KP · v2026-01</span></div>
        </div>
      </div>
    </li>
    <li class="p-5">
      <div class="flex items-start gap-4">
        <div class="flex-shrink-0 w-9 h-9 rounded-full flex items-center justify-center font-code text-xs font-bold border" style="background: rgba(3,105,161,0.08); border-color: rgba(3,105,161,0.3); color: #0369A1;">06</div>
        <div class="flex-1 min-w-0">
          <div class="flex flex-wrap items-center gap-2 mb-1.5">
            <span class="text-body font-semibold text-primary">Kontrola progu 182 dni zasiłkowych</span>
            <span class="inline-flex items-center gap-1 px-2 py-0.5 text-xs font-bold uppercase tracking-wider rounded text-white" style="background: #0369A1;">Reguła</span>
          </div>
          <p class="text-small text-primary font-medium mb-2">Limit niewyczerpany - kontynuacja wynagrodzenia chorobowego</p>
          <div class="px-3 py-2 bg-surface border border-base rounded font-code text-xs text-primary/80"><span class="text-muted">input:</span> historia absencji, 12 miesięcy (3 okresy)</div>
          <div class="mt-2 font-code text-xs text-muted"><span>rule:</span> <span class="text-primary">ustawa zasiłkowa z 25.06.1999 · v2025-07</span></div>
        </div>
      </div>
    </li>
    <li class="p-5">
      <div class="flex items-start gap-4">
        <div class="flex-shrink-0 w-9 h-9 rounded-full flex items-center justify-center font-code text-xs font-bold border" style="background: rgba(109,78,216,0.08); border-color: rgba(109,78,216,0.3); color: #6D4ED8;">09</div>
        <div class="flex-1 min-w-0">
          <div class="flex flex-wrap items-center gap-2 mb-1.5">
            <span class="text-body font-semibold text-primary">Oznaczenie wzorca absencji</span>
            <span class="inline-flex items-center gap-1 px-2 py-0.5 text-xs font-bold uppercase tracking-wider rounded text-white" style="background: #6D4ED8;">AI <span class="font-mono opacity-90">91%</span></span>
          </div>
          <p class="text-small text-primary font-medium mb-2">Sygnał dla HR: trzecia krótka absencja w ciągu sześciu miesięcy</p>
          <div class="px-3 py-2 bg-surface border border-base rounded font-code text-xs text-primary/80"><span class="text-muted">input:</span> zanonimizowane metadane absencji - bez diagnozy (RODO art. 9)</div>
          <div class="mt-2 font-code text-xs text-muted"><span>model-reason:</span> <span class="text-primary">dopasowanie wzorca powtarzających się krótkich absencji · wskaźnik, nie decyzja kadrowa</span></div>
          <div class="mt-3"><span class="inline-flex items-center px-3 py-1.5 text-xs font-semibold rounded border-2" style="border-color: #6D4ED8; color: #6D4ED8; background: rgba(109,78,216,0.08);">formalnie podważalna · art. 14 EU AI Act</span></div>
        </div>
      </div>
    </li>
    <li class="p-5">
      <div class="flex items-start gap-4">
        <div class="flex-shrink-0 w-9 h-9 rounded-full flex items-center justify-center font-code text-xs font-bold border" style="background: rgba(180,83,9,0.08); border-color: rgba(180,83,9,0.3); color: #B45309;">13</div>
        <div class="flex-1 min-w-0">
          <div class="flex flex-wrap items-center gap-2 mb-1.5">
            <span class="text-body font-semibold text-primary">Rozmowa o powrocie do pracy</span>
            <span class="inline-flex items-center gap-1 px-2 py-0.5 text-xs font-bold uppercase tracking-wider rounded text-white" style="background: #B45309;">Człowiek</span>
          </div>
          <p class="text-small text-primary font-medium mb-2">Uzgodniony plan powrotu po długotrwałej nieobecności</p>
          <div class="mt-2 font-code text-xs text-muted"><span>decided-by:</span> <span class="text-primary">specjalistka HR</span> <span class="text-muted">- 17.05.2026, 14:10</span></div>
        </div>
      </div>
    </li>
  </ol>
</div>

Polskie prawo administracyjne ma dla tego artefaktu precyzyjną analogię: akt administracyjny - decyzję administracyjną w rozumieniu Kodeksu postępowania administracyjnego. Organ, który rozstrzyga o obywatelu, nie wydaje "outputu" - wydaje akt: indywidualnie adresowany, uzasadniony, z podstawą prawną i pouczeniem o środkach odwoławczych, pojedynczo zaskarżalny. Nikt nie zaakceptowałby, by urząd odpowiadał na odwołanie: "Niestety mamy tylko log serwera." Dokładnie ten wymóg formy akt decyzyjny przenosi na decyzje maszynowe. Trail to ślad, który się zostawia. Akt to dokument, który się wydaje - i od którego przysługuje odwołanie.

Tę samą logikę rachunkowość zna od stuleci: żaden biegły rewident nie zaakceptuje sumy bez zapisów księgowych i dowodów źródłowych. Ustawa o rachunkowości wymaga zapisu pojedynczego, niezmienności i możliwości prześledzenia każdej operacji gospodarczej - z okresami przechowywania ksiąg i dowodów księgowych przez 5 lat wg art. 74 ustawy o rachunkowości oraz dokumentacji podatkowej do upływu przedawnienia zobowiązania, czyli znacznie dłużej niż sześć miesięcy z art. 26 ust. 6. Akt decyzyjny to nic innego niż podwójna księgowość dla decyzji: jeden dowód na operację, jeden akt na decyzję.

O tym, że ta jednostka nie ma jeszcze ustalonej nazwy, najlepiej świadczy sam rynek: krążą "decision trail", "decision provenance", "decision trace", "accountability record" - [TechTarget](https://www.techtarget.com/searcherp/feature/AI-decision-trails-are-the-new-audit-trail) ogłasza ścieżki decyzyjne AI nowym śladem audytowym, [FINOS AI Governance Framework](https://air-governance-framework.finos.org/mitigations/mi-21_agent-decision-audit-and-explainability.html) żąda "Agent Decision Audit and Explainability". Wymaganie dotarło do dyskursu. Artefakt wciąż nie ma nazwy. My nazywamy go od początku w Decision Layer: akt decyzyjny.

Gdzie powstaje akt, widać na siedmiu warstwach produkcyjnego stosu agentowego - akt decyzyjny jest artefaktem warstwy 04:

<div class="not-prose my-10 border-y border-base">
  <ol class="divide-y divide-base">
    <li class="grid grid-cols-[3rem_1fr] gap-4 items-start py-4">
      <span class="font-display text-h2 leading-none text-muted">01</span>
      <div><span class="text-body font-semibold text-primary">Presentation Layer</span><p class="mt-1 text-small text-primary/80">Interfejsy użytkownika, bramki promptów, portale dostępowe dla działów i rady pracowników.</p></div>
    </li>
    <li class="grid grid-cols-[3rem_1fr] gap-4 items-start py-4">
      <span class="font-display text-h2 leading-none text-muted">02</span>
      <div><span class="text-body font-semibold text-primary">Orchestration Layer</span><p class="mt-1 text-small text-primary/80">Koordynacja wielu agentów, routing zdarzeń, zarządzanie stanem ponad granicami procesów.</p></div>
    </li>
    <li class="grid grid-cols-[3rem_1fr] gap-4 items-start py-4 bg-[color:var(--accent-primary)]/5">
      <span class="font-display text-h2 leading-none text-accent">03</span>
      <div><span class="text-body font-semibold text-primary">Agent Layer <span class="ml-2 font-code text-xs uppercase tracking-wider text-accent">rdzeń Gosign</span></span><p class="mt-1 text-small text-primary/80">Agenci Document, Workflow i Knowledge - warstwa wykonawcza z osądem AI.</p></div>
    </li>
    <li class="grid grid-cols-[3rem_1fr] gap-4 items-start py-4 bg-[color:var(--accent-primary)]/5">
      <span class="font-display text-h2 leading-none text-accent">04</span>
      <div><span class="text-body font-semibold text-primary">Decision Layer <span class="ml-2 font-code text-xs uppercase tracking-wider text-accent">rdzeń Gosign</span></span><p class="mt-1 text-small text-primary/80">Tu powstaje akt decyzyjny: jeden akt na mikrodecyzję, wersjonowane zestawy reguł, routing human-in-the-loop przy uznaniowości, podważalność wg art. 14.</p></div>
    </li>
    <li class="grid grid-cols-[3rem_1fr] gap-4 items-start py-4">
      <span class="font-display text-h2 leading-none text-muted">05</span>
      <div><span class="text-body font-semibold text-primary">Governance Layer</span><p class="mt-1 text-small text-primary/80">Audit trail, podpisane rekordy, kontrole cert-ready dla EU AI Act art. 9/12/13/14, ISO 27001.</p></div>
    </li>
    <li class="grid grid-cols-[3rem_1fr] gap-4 items-start py-4">
      <span class="font-display text-h2 leading-none text-muted">06</span>
      <div><span class="text-body font-semibold text-primary">Model Layer</span><p class="mt-1 text-small text-primary/80">Rejestr modeli, wersjonowanie, kalibracja pewności - niezależnie od modelu.</p></div>
    </li>
    <li class="grid grid-cols-[3rem_1fr] gap-4 items-start py-4">
      <span class="font-display text-h2 leading-none text-muted">07</span>
      <div><span class="text-body font-semibold text-primary">Integration Layer</span><p class="mt-1 text-small text-primary/80">Konektory do SAP, Workday, systemów ERP - wyniki gotowe do zaksięgowania.</p></div>
    </li>
  </ol>
</div>

## Podważalność to decyzja architektoniczna - nie funkcja

Niewygodna konsekwencja tego wszystkiego: podważalności nie da się dobudować po fakcie. Trzy powody, dla których następcze narzędzie compliance strukturalnie zawodzi:

**Po pierwsze: czego nigdy nie zamodelowano jako decyzji, nie da się jako decyzji uzasadnić.** Agent, który przetwarza sprawę "za jednym zamachem", produkuje wynik bez struktury. Podział na mikrodecyzje musi nastąpić przed wykonaniem - to on definiuje, w których miejscach powstaje akt, która reguła tam obowiązuje i kto tam decyduje. Po fakcie nie da się wyodrębnić struktury decyzyjnej z logu konwersacji, tak samo jak z wyciągu bankowego nie da się wyprowadzić rachunku kosztów.

**Po drugie: skuteczny nadzór ludzki potrzebuje kontekstu decyzji - dla każdej sprawy.** [Art. 14 ust. 4](https://artificialintelligenceact.eu/article/14/) wymaga, by osoba nadzorująca mogła poprawnie zinterpretować wynik, zignorować go, unieważnić lub odwrócić oraz przerwać działanie systemu - i pozostawała świadoma skłonności do automatycznego polegania na wyniku maszyny. Ustawodawca wprost nazywa to automation bias. Amerykański NIST ostrzega w tym samym duchu przed ceremonialnym Human-in-the-Loop: przycisk zatwierdzenia bez kontekstu, uprawnień i czasu nikogo nie chroni. Osoba, która ma odwrócić decyzję, musi mieć przed sobą dane wejściowe, zastosowaną regułę, pewność i powód eskalacji - czyli dokładnie pola aktu decyzyjnego. Dlatego [Human-in-the-Loop w Decision Layer to wymuszony routing](/pl/magazyn/human-in-the-loop-architektura/), a nie opcjonalne kliknięcie: przy zdefiniowanych typach decyzji workflow się zatrzymuje, system docelowy pozostaje nietknięty, a sama decyzja człowieka jest dokumentowana jako akt - łącznie z informacją, czy poszedł za rekomendacją, czy od niej odstąpił.

**Po trzecie: korekta potrzebuje odniesienia do reguły.** Podważenie nie jest celem samym w sobie - ma usuwać błędy. Gdy decyzja zostaje skutecznie podważona, natychmiast pojawia się pytanie: czy to był błąd jednostkowy, czy błąd reguły? Akt decyzyjny, który zawiera zastosowaną wersję reguły, odpowiada na to jednym zapytaniem: wszystkie akty oparte na tej samej wersji reguły są identyfikowalne, reguła zostaje skorygowana w nowej wersji, a objęte nią sprawy są punktowo rozstrzygane ponownie. W ten sposób podważenie jednego przypadku prowadzi do wyeliminowania całej klasy błędów. Bez odniesienia do reguły pozostaje tylko ręczny przegląd wszystkich spraw - przeciwieństwo skalowania.

Badania nazywają tę zasadę [Contestability by Design](https://research.tudelft.nl/en/publications/contestable-ai-by-design-towards-a-framework/) (Alfrink i in., 2022): systemy muszą przez cały cykl życia pozostawać otwarte na interwencję człowieka - jako proceduralna relacja między osobami dotkniętymi decyzją a odpowiedzialnymi za system, wbudowana, a nie dobudowana. A [Deloitte (2025)](https://www.deloitte.com/us/en/insights/topics/emerging-technologies/ai-agents-scaling-faster.html) nazywa trzy elementy governance, których przedsiębiorstwom brakuje dla agentów, niemal słowo w słowo zgodnie z tą architekturą: jasne granice, które decyzje agenci mogą podejmować samodzielnie, a które wymagają ludzkiego zatwierdzenia; monitoring w czasie rzeczywistym z wykrywaniem anomalii; oraz ślady audytowe, które utrwalają pełny łańcuch działań agenta na potrzeby rozliczalności. Framework trzech typów decyzji, Confidence Routing i akt decyzyjny są techniczną odpowiedzią dokładnie na tę listę - jako zasada projektowa, [a nie jako następcza warstwa compliance](/pl/governance/eu-ai-act/).

## Kto podważa - i co dzieje się potem

Podważalność brzmi abstrakcyjnie, ma jednak cztery bardzo konkretne oblicza. Decision Layer definiuje dla każdej mikrodecyzji, przed kim musi się ona obronić:

| Kto podważa | Podstawa prawna | Co widzi | Co z tego wynika |
|---|---|---|---|
| Osoba, której dotyczy | Art. 86 AI Act, art. 15, 22 RODO | wyjaśnienie własnej decyzji: rola systemu AI, istotne elementy, na żądanie kontrfaktyczne | korekta pojedynczego przypadku; przy błędzie reguły ponowne rozstrzygnięcie wszystkich dotkniętych spraw |
| Rada pracowników / związki zawodowe | ustawa z 7 kwietnia 2006 r. o informowaniu pracowników i przeprowadzaniu z nimi konsultacji, art. 28 ustawy o związkach zawodowych (obowiązek informacyjny pracodawcy) | akty decyzji istotnych kadrowo, dowód technicznego egzekwowania reguł porozumienia | informacja i konsultacja oparte na dowodach, a nie na nieufności |
| Biegły rewident | ustawa o rachunkowości, Krajowe Standardy Badania, ISA | kompletne akty na każdy zapis: dowód, reguła, wersja, pewność, zatwierdzenie | badanie systemu zamiast odtwarzania pojedynczych przypadków; próba wprost udowodniona |
| Organ nadzoru | Art. 26 ust. 6, art. 12 AI Act; nadzór rynku (UODO dla RODO, PIP dla prawa pracy) | eksportowalne, maszynowo czytelne logi za wymagany okres przechowywania | zdolność udzielenia informacji w ciągu dni zamiast projektu forensycznego |

Godne uwagi jest to, co ta tabela robi z organizacją: odwraca rozkład ciężaru dowodu. Bez aktów decyzyjnych każde podważenie to projekt forensyczny o otwartym wyniku - a wg art. 18³ᵇ § 1 Kodeksu pracy (a poza stosunkiem pracy art. 14 ustawy z 3.12.2010 r.) w przypadku dyskryminacji pracownik jedynie uprawdopodabnia nierówne traktowanie, a ciężar dowodu spoczywa na pracodawcy. Z aktami decyzyjnymi odpowiedź sprowadza się do zapytania. Rada pracowników, która dziś odnosi się do projektów AI z nieufnością i eskaluje brak rzetelnych informacji, staje się beneficjentem tej samej infrastruktury, z której korzysta audytor. Inni obiecują przejrzystość. Akt decyzyjny wymusza ją technicznie.

Ta tabela ma cichą drugą stronę: kto może podważyć, regulują ustawa i porozumienia - ale żadna norma sama z siebie nie zapewnia, że akty decyzyjne w ogóle powstają, są kompletne i trwałe. Ta odpowiedzialność potrzebuje jednoznacznego właściciela w organizacji; nie powstaje jako produkt uboczny bieżącej działalności.

## Uporządkowanie: zasada toruje sobie drogę

Uczciwe spojrzenie na rynek 2026: wniosek, że decyzje agentów muszą dać się pojedynczo udowodnić, nie jest odosobniony. Gartner stworzył z [Guardian Agents](https://www.gartner.com/en/newsroom/press-releases/2025-06-11-gartner-predicts-that-guardian-agents-will-capture-10-15-percent-of-the-agentic-ai-market-by-2030) własną kategorię rynkową dla warstw kontroli, które monitorują i blokują działania agentów, i prognozuje im do 2030 r. 10-15 procent rynku agentycznej AI. [Pole decision intelligence](https://www.gartner.com/en/information-technology/glossary/decision-intelligence) - jawne modelowanie, ocenianie i ulepszanie decyzji - dostało w styczniu 2026 swój pierwszy Magic Quadrant. WEF żąda [progresywnego governance](https://www.weforum.org/publications/ai-agents-in-action-foundations-for-evaluation-and-governance/): intensywność nadzoru sprzężona ze stopniem autonomii agenta. Badania pracują nad decision provenance. Kierunek jest jednoznaczny - i jest dokładnie kierunkiem Decision Layer.

Te podejścia nie zapewniają jednak powiązania z warstwą merytoryczną. Guardian Agent blokuje w czasie wykonania; nie zostawia aktu, który trzy lata później obroni się przed sądem pracy. Observability zachowuje łańcuch wykonania; nie rozkłada decyzji na pojedynczo uzasadnione, związane regułą artefakty. Decydująca różnica aktu decyzyjnego leży w trzech właściwościach: w przypisaniu każdej mikrodecyzji do wersjonowanej reguły fachowej wraz z jej źródłem - zakładowy układ zbiorowy pracy, regulamin wynagradzania, prawo podatkowe - zamiast do wygenerowanego łańcucha uzasadnienia; w architektonicznie wymuszonym Human-in-the-Loop dla każdego typu decyzji zamiast wyłączalnej konfiguracji; oraz w odwzorowaniu aktów na standardy badania, z którymi biegli rewidenci i audyt wewnętrzny faktycznie pracują - ISA, Krajowe Standardy Badania, ustawa o rachunkowości. Pierwszego z tych pól, wedle naszej wiedzy, nie dokumentuje żaden dostawca horyzontalny; a to właśnie pole, od którego zależy podważalność.

Dla precyzji trzeba też dokonać rozgraniczenia: akt decyzyjny to wypowiedź architektoniczna, nie certyfikat zgodności. To, czy konkretny system spełnia wymagania prawne, pozostaje oceną pojedynczego przypadku dokonaną przez podmiot stosujący i jego doradców prawnych. To, co dostarcza architektura, jest czymś innym - i cenniejszym: czyni wymagania spełnialnymi. Firma z aktami decyzyjnymi potrafi odpowiedzieć na pytanie z art. 86. Firma z logami czatu nie potrafi, niezależnie od tego, jak dobrze udokumentowane są jej intencje.

## Właściwe pytanie

EU AI Act nie wymyślił wyjaśnialności pojedynczych decyzji - skodyfikował ją dla systemów AI i wzmocnił prawem osoby, której decyzja dotyczy. Orzecznictwo TSUE wyznaczyło miarę, zanim w ogóle zaczął obowiązywać pierwszy termin wysokiego ryzyka. A firmy doradcze skwantyfikowały, co się dzieje, gdy firmy przenoszą prawa decyzyjne, nie potrafiąc udowodnić decyzji: zaniechane projekty, zablokowane wdrożenia, osobiście odpowiadający CIO.

Pytanie do każdej firmy, która stosuje lub wprowadza agentów AI, nie brzmi więc "Czy jesteśmy compliant?". Brzmi: Jeśli jutro pracownik, rada pracowników, biegły rewident lub organ podważy jedną pojedynczą dzisiejszą decyzję - czy potrafisz przedłożyć akt? Input, reguła, wersja, pewność, wynik, zatwierdzenie?

Kto potrafi odpowiedzieć na to pytanie "tak", nie ma już problemu z ryzykiem AI. Ma infrastrukturę decyzyjną.

→ [Decision Layer - przegląd i przykłady](/pl/decision-layer/)

→ [Decision Layer - wyjaśnienie dla osób odpowiedzialnych za procesy](/pl/magazyn/decision-layer-wyjasnienie/)

→ [EU AI Act: AI w HR pozostaje wysokiego ryzyka - termin 2026/2027](/pl/magazyn/eu-ai-act-hr-wysokie-ryzyko/)

<a href="/pl/kontakt/" target="_blank" rel="noopener noreferrer">Umów spotkanie</a> - Pokażemy na jednym z Twoich procesów, jak konkretnie wyglądają mikrodecyzje, akty decyzyjne i ścieżki podważenia.

--- Bezpieczeństwo danych w AI: Data Residency, RODO i EU AI Act ---
> Jak zapewnić bezpieczeństwo danych w enterprise AI? Data Residency, przetwarzanie wyłącznie w UE, Row-Level Security, izolacja mandantów.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">W skrócie - Bezpieczeństwo danych w enterprise AI</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Pierwsze pytanie dla każdego CISO i IOD: gdzie dane są przetwarzane, kto ma dostęp, jak długo są przechowywane? Przy publicznych narzędziach AI odpowiedź jest nieakceptowalna dla firm regulowanych.</li>
<li>Trzy modele wdrożenia: self-hosted (żadne dane nie opuszczają sieci), chmura tylko UE (przetwarzanie w centrach danych UE) lub hybrydowy (dane wrażliwe self-hosted, niekrytyczne przez chmurę).</li>
<li>IBM Cost of a Data Breach Report (2024) wykazał, że średni koszt naruszenia danych osiągnął 4,88 mln USD - najwyższy w historii.</li>
<li>Izolacja mandantów przez Row-Level Security, separację workspace'ów i izolację promptów jest kluczowa dla kancelarii audytorskich, doradztwa podatkowego i centrów usług wspólnych.</li>
<li>Bezpieczeństwo danych w enterprise AI to decyzja architektoniczna, nie kwestia polityki - właściwa infrastruktura czyni zgodność weryfikowalną zamiast deklaratywną.</li>
</ul>
</div>

## Kluczowe pytanie: Gdzie są dane?

Gdy agent AI czyta fakturę, przetwarza zwolnienie lekarskie lub odpowiada na pytanie o compliance, przetwarza dane firmowe. Dane faktur, dane osobowe, tajemnice handlowe. Pierwsze pytanie każdego CISO i Inspektora Ochrony Danych (IOD): Gdzie te dane są przetwarzane? Kto ma do nich dostęp? Jak długo są przechowywane?

Przy korzystaniu z ChatGPT, Gemini czy CoPilot odpowiedź brzmi: dane są przesyłane na serwery zewnętrzne, przetwarzane przez podmiot trzeci i mogą być wykorzystywane do celów treningowych. Dla firm podlegających regulacjom to odpowiedź nie do zaakceptowania.

## Trzy modele wdrożenia

[Architektura Gosign](/pl/governance/) obsługuje trzy modele wdrożenia. Wybór zależy od poziomu ochrony danych.

**Self-Hosted:** Wszystkie komponenty - modele, agenci, bazy danych - działają w infrastrukturze klienta. Żadne dane nie opuszczają sieci firmowej. Dotyczy to również modeli językowych: modele open source, takie jak [Llama](https://llama.meta.com/), [Mistral](https://mistral.ai/), [DeepSeek](https://www.deepseek.com/) czy gpt-oss, mogą być uruchamiane lokalnie.

**Chmura (tylko UE):** Przetwarzanie w centrach danych UE w Azure, GCP lub AWS. Data Processing Agreement, Standard Contractual Clauses. Modele są chmurowe (Claude, ChatGPT, Gemini), ale przetwarzanie pozostaje w UE.

**Hybrydowy:** Wrażliwe dane (dane osobowe, dane finansowe) są przetwarzane self-hosted. Dane niekrytyczne mogą być przetwarzane przez modele chmurowe. Routing między self-hosted a chmurą jest oparty na regułach i automatyczny.

## Data Residency w szczegółach

Data Residency wykracza poza lokalizację serwerów. Obejmuje:

**Miejsce przetwarzania:** Gdzie jest uruchamiany model językowy? W przypadku self-hosted: we własnym centrum danych. W przypadku chmury: w zdefiniowanym centrum danych UE.

**Miejsce przechowywania:** Gdzie przechowywane są przetworzone dane? Audit Trail, zbiory decyzji, dokumenty. Wszystko w tym samym regionie co przetwarzanie.

**Trasa przesyłu:** Jak dane trafiają do modelu i z powrotem? W przypadku self-hosted: sieć wewnętrzna. W przypadku chmury: szyfrowane połączenie do centrum danych UE. Bez tranzytu przez państwa trzecie.

**Kopie zapasowe:** Gdzie przechowywane są kopie zapasowe? Kopie zapasowe muszą spełniać te same wymagania Data Residency co dane podstawowe.

## Izolacja mandantów

Dla kancelarii audytorskich i doradztwa podatkowego oraz centrów usług wspólnych izolacja mandantów jest kluczowa dla biznesu. Dane jednego mandanta nie mogą być widoczne dla innych mandantów - również nie dla systemu AI.

Izolacja jest realizowana wielowarstwowo:

**Separacja workspace'ów:** Każdy mandant ma własny workspace z oddzielnymi kluczami API, oddzielnym magazynem dokumentów i oddzielnymi konfiguracjami modeli.

**Row-Level Security:** Na poziomie bazy danych Row-Level Security zapewnia, że zapytania zwracają wyłącznie dane bieżącego mandanta. Nawet jeśli agent omyłkowo wykona zapytanie międzymandantowe, baza danych zwraca tylko wyniki uprawnionego mandanta.

**Izolacja promptów:** Prompty i reguły są specyficzne dla mandanta. Agent jednego mandanta nie ma dostępu do promptów ani reguł innych mandantów.

## Zgodność z RODO

RODO stawia wymagania dotyczące przetwarzania danych osobowych. W kontekście AI:

**Podstawa prawna:** Przetwarzanie danych osobowych przez agentów AI wymaga podstawy prawnej. W kontekście zatrudnienia typowo: wykonanie umowy (art. 6 ust. 1 lit. b RODO) lub uzasadniony interes (art. 6 ust. 1 lit. f RODO). UODO jako polski organ nadzorczy wymaga szczególnie starannej dokumentacji tych podstaw.

**Minimalizacja danych:** Agent przetwarza wyłącznie dane niezbędne do konkretnego celu. Bez trwałego przechowywania dokumentów w modelu. Bez wykorzystywania danych klientów do celów treningowych.

**Prawo dostępu:** Osoby, których dane dotyczą, mogą żądać informacji o przetworzonych danych. Audit Trail dokumentuje każde przetwarzanie danych osobowych.

**Usuwanie:** Dane są usuwane po upływie okresu przechowywania. Usuwanie obejmuje również Audit Trail po upływie ustawowych okresów przechowywania.

## Lista kontrolna bezpieczeństwa danych wg modelu wdrożenia

| Wymaganie bezpieczeństwa | Self-Hosted | Chmura tylko UE | Hybrydowy |
|---|---|---|---|
| Dane opuszczają sieć firmową | Nie | Tak (do centrum danych UE) | Wrażliwe: Nie / Niekrytyczne: Tak |
| Trening modelu na danych firmowych | Niemożliwy | Wykluczony przez DPA | Wykluczony przez DPA |
| Mechanizm zgodności z RODO | Pełna kontrola by design | DPA + SCCs + strefy przetwarzania UE | Routing wg klasy danych |
| Izolacja mandantów | Workspace + RLS + izolacja promptów | Workspace + RLS + izolacja promptów | Workspace + RLS + izolacja promptów |
| Lokalizacja Audit Trail | On-Premises | Centrum danych UE | Podział: on-prem + chmura UE |
| Residency kopii zapasowych | Jak dane podstawowe | Ten sam region UE | Wg klasyfikacji danych |
| Opóźnienie | Najniższe (sieć lokalna) | Opóźnienie sieci UE | Zależy od klasy danych |

Więcej informacji: [Data Residency](/pl/governance/data-residency/)

<a href="/pl/kontakt/" target="_blank" rel="noopener noreferrer">Umów spotkanie</a> - Pokażemy opcje Data Residency dostosowane do Twoich wymagań.

--- Cert-Ready by Design - AI gotowe do audytu od startu ---
> Cert-Ready by Design: kontrole to obiekty danych, dowody generowane automatycznie, audytorzy widzą status na żywo. Architektura dla ISA, KSR, MSSF.

## Problem: gotowość do audytu jako projekt

W większości polskich firm przygotowanie do audytu - badania sprawozdania finansowego, kontroli skarbowej, audytu SOC 2 - to projekt. Na tygodnie przed kontrolą zbierane są dokumenty, tworzone zrzuty ekranów, dowody eksportowane z różnych systemów i sortowane w foldery.

To podejście ma trzy problemy: jest pracochłonne, podatne na błędy i pokazuje migawkę zamiast stanu faktycznego. Audytor widzi, jak system wyglądał w momencie dokumentacji, a nie jak faktycznie działa.

Gdy agenci AI podejmują decyzje krytyczne dla biznesu, problem się zaostrza. Każda pojedyncza decyzja agenta musi być możliwa do prześledzenia. Przy tysiącach decyzji miesięcznie ręczna dokumentacja nie jest już możliwa.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">W skrócie - Cert-Ready by Design</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Cert-Ready by Design oznacza, że gotowość do audytu jest zasadą architektoniczną, a nie retrospektywnym projektem dokumentacyjnym.</li>
<li>Kontrole są obiektami danych pierwszej klasy z automatycznym generowaniem dowodów, wersjonowaniem reguł i statusem na żywo dla audytorów.</li>
<li>ISACA (2023) informuje, że organizacje z ciągłym monitoringiem kontroli redukują czas przygotowania do audytu nawet o 65%.</li>
<li>Mapowanie frameworków obejmuje ISA, KSR, MSSF/MSR - dowody mówią językiem zrozumiałym dla audytorów.</li>
<li>Rezultat: audyt przetwarzania wspomaganego przez AI trwa godziny zamiast tygodni, z kompletnymi, odpornymi na manipulację dowodami.</li>
</ul>
</div>

## Co oznacza Cert-Ready by Design

Cert-Ready by Design odwraca podejście: gotowość do audytu nie jest procesem po fakcie, lecz zasadą architektoniczną. Kontrole są technicznymi obiektami danych w systemie. Dowody są generowane automatycznie. Audytorzy widzą status na żywo, nie migawkę.

### Kontrole jako obiekty danych pierwszej klasy

W architekturze Cert-Ready każda kontrola jest technicznym obiektem danych ze zdefiniowanymi atrybutami:

| Element | Funkcja |
|---------|---------|
| Control_ID | Unikalna identyfikacja kontroli |
| Technical_Implementation | Konkretna implementacja techniczna (np. polityka RLS, kontrola API, próg pewności) |
| Rule_Version | Wersja bazowej logiki decyzyjnej |
| Evidence_Generator | Automatyczny mechanizm weryfikacji generujący dowody |
| Evidence_History | Historyzowane wyniki weryfikacji ze znacznikami czasu |
| Auditor_View | Widok z możliwością drill-down aż do implementacji |

Kontrole to nie dokumenty Word w folderze SharePoint. To techniczne obiekty żyjące w systemie, automatycznie weryfikowane i odzwierciedlające swój status w czasie rzeczywistym.

### Automatyczne generowanie dowodów

Dowody nie są kompilowane po fakcie. Są generowane automatycznie - przy każdej decyzji agenta, przy każdej zmianie reguły, przy każdym zdarzeniu systemowym.

Przykład: agent przetwarza fakturę przychodzącą. Decision Layer stosuje regułę w wersji 4.2. Pewność: 97%. Wynik: propozycja księgowania na konto 4400, centrum kosztów 1200. Brak eskalacji (pewność powyżej progu, kwota poniżej limitu wartości).

Dowody dla tej operacji są generowane automatycznie: dane wejściowe, zastosowana reguła z wersją, wartość pewności, decyzja routingowa, wynik, znacznik czasu. Te dowody są niezmienne i powiązane z dokumentem księgowym.

### Portal Audytora

Audytorzy widzą w Portalu Audytora status na żywo wszystkich kontroli. Żadnego eksportu PDF, żadnej migawki - aktualny stan systemu.

Portal Audytora oferuje drill-down: od przeglądu kontroli (dashboard sygnalizacyjny: zielony/żółty/czerwony) przez pojedynczą kontrolę aż do konkretnej implementacji technicznej i historii dowodów.

### Mapowanie na frameworki

Kontrole są mapowane na uznane standardy audytowe:

**ISA (Międzynarodowe Standardy Rewizji Finansowej):** Dla badań rocznych sprawozdań finansowych. Kontrole odwzorowują kontrole wewnętrzne, które biegły rewident ocenia w ramach badania.

**KSR (Krajowe Standardy Rachunkowości):** Dla polskich wymagań rachunkowości. Wersjonowanie zestawów reguł, niezmienność Audit Trail i prześledzalność każdej decyzji księgowej spełniają wymagania polskich standardów.

**MSSF/MSR:** Dla międzynarodowej sprawozdawczości finansowej. Kontrole mapowane na wymogi Międzynarodowych Standardów Sprawozdawczości Finansowej.

To mapowanie frameworku zapewnia, że automatycznie generowane dowody mówią językiem zrozumiałym dla audytorów - zarówno polskich biegłych rewidentów, jak i międzynarodowych firm audytorskich.

## Cert-Ready w praktyce

Firma audytorska przeprowadza badanie rocznego sprawozdania finansowego u klienta. Klient stosuje agentów AI do przetwarzania dokumentów.

Audytor otwiera Portal Audytora. Widzi: 12 kontroli dla przetwarzania dokumentów, wszystkie zielone. Klika na kontrolę "BV-003: Kompletność dokumentów księgowych". Widzi: implementację techniczną (kontrola API względem danych wejściowych), aktualną wersję reguły, dowody z ostatnich 12 miesięcy (wszystkie automatyczne weryfikacje zakończone pozytywnie), średnią wartość pewności i wskaźnik eskalacji.

Może wykonać drill-down: sprawdzić losowo pojedyncze dokumenty, prześledzić ścieżkę decyzyjną, przejrzeć zastosowaną regułę w wersji obowiązującej w momencie podjęcia decyzji.

Wynik: audyt przetwarzania wspomaganego przez IT trwa godziny zamiast tygodni. Dowody są kompletne, automatycznie wygenerowane i odporne na manipulacje.

Więcej na ten temat: [Cert-Ready by Design w szczegółach](/pl/governance/cert-ready/)

Więcej o [architekturze governance](/pl/governance/) i jej zastosowaniu w polskich firmach.

<a href="/pl/kontakt/" target="_blank" rel="noopener noreferrer">Umów spotkanie</a> - Pokażemy Portal Audytora na żywo.

--- ChatGPT bez logowania w firmie: Od ryzyka do infrastruktury ---
> Niekontrolowane korzystanie z ChatGPT zagraża firmom. Jak infrastruktura czatu zgodna z RODO i niezależna od modeli rozwiązuje problem.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">W skrócie - ChatGPT bez logowania: ryzyko korporacyjne</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Pracownicy korzystający z publicznych narzędzi AI bez nadzoru IT tworzą Shadow AI - prompty są przetwarzane na niekontrolowanych serwerach, potencjalnie używane do treningu modeli, bez Audit Trail.</li>
<li>Zakaz AI nie działa. Rozwiązaniem jest infrastruktura czatu niezależna od modeli pod kontrolą firmy, lepsza niż publiczna alternatywa.</li>
<li>Verizon DBIR (2024) wykazał, że 74% naruszeń danych wiąże się z czynnikiem ludzkim - niekontrolowane korzystanie z AI tworzy zupełnie nową kategorię ekspozycji danych.</li>
<li>Prawdziwa wartość pojawia się, gdy interfejs czatu ewoluuje w platformę agentów - przetwarzanie dokumentów, orkiestracja workflow, odpowiedzi na pytania wiedzowe.</li>
<li>Trzy decyzje architektoniczne czekają teraz: model hostingu, strategia modelowa i roadmapa agentów. Każdy dzień zwłoki oznacza więcej ekspozycji Shadow AI.</li>
</ul>
</div>

## Problem to nie ChatGPT. Problem to utrata kontroli.

W niemal każdej firmie pracownicy potajemnie korzystają z publicznych narzędzi AI. Z prywatnych kont ChatGPT, przez podejrzane strony obiecujące „ChatGPT bez logowania", kopiując dane do Claude.ai czy Gemini - bez wiedzy działu IT, bez zgody, bez jakiejkolwiek kontroli. Bariera wejścia jest zerowa, wzrost produktywności natychmiastowy. Rezultat: Shadow IT na masową skalę.

Ryzyko nie jest teoretyczne. Prompty przesyłane do publicznych usług AI są przetwarzane na serwerach poza kontrolą firmy. Bez umowy enterprise dane mogą być wykorzystywane do trenowania modeli. Szczególnie niebezpieczne są liczne strony oferujące „ChatGPT za darmo i bez logowania" - brakuje tam nawet minimalnej ochrony, jaką zapewnia bezpośrednie konto OpenAI. Poufne informacje - dane płacowe, projekty umów, dokumenty strategiczne - trafiają do systemów, do których firma nie ma dostępu, prawa do usunięcia danych ani możliwości audytu. W kontekście polskiego rynku oznacza to potencjalne naruszenie RODO, za które UODO może nałożyć surowe kary.

Działy IT stoją przed dylematem: zakaz nie działa, bo korzyści są zbyt oczywiste i pracownicy znajdują obejścia. Tolerowanie nie wchodzi w grę, bo Inspektor Ochrony Danych (IOD), Rada Zakładowa i audyt wewnętrzny prędzej czy później zadadzą pytania.

Odpowiedzią nie jest ani zakaz, ani tolerancja. Odpowiedzią jest infrastruktura.


## Czego naprawdę potrzebują pracownicy - i dlaczego potajemnie korzystają z ChatGPT

Gdy pracownicy sięgają po ChatGPT mimo zakazu, świadczy to przede wszystkim o jednym: firma nie oferuje alternatywy. Pracownicy szukają prostego interfejsu, który działa natychmiast, rozumie naturalny język i pomaga w codziennej pracy. Streszczanie dokumentów, redagowanie e-maili, analiza plików, odpowiadanie na pytania o wewnętrzne regulaminy.

Ta potrzeba jest uzasadniona. Musi jednak zostać zaspokojona w środowisku kontrolowanym przez firmę - nie na serwerach podmiotów trzecich reklamujących się hasłem „ChatGPT bez logowania", których modelem biznesowym jest zbieranie danych.

Firmowa infrastruktura czatu daje każdemu pracownikowi dokładnie taki interfejs - z jedną kluczową różnicą: dane pozostają w infrastrukturze firmy. Prompty nie są przesyłane na zewnątrz. Korzystanie jest logowane i podlega audytowi. Uprawnienia dostępu opierają się na istniejącym modelu ról. A co najważniejsze: pracownicy nie muszą już potajemnie korzystać z zewnętrznych narzędzi, bo mają lepszą, oficjalną alternatywę.


## Dlaczego podejście niezależne od modeli to jedyny sensowny wybór

Najczęstszy błąd przy wdrażaniu AI w firmie: wybranie jednego modelu od jednego dostawcy jako standard. ChatGPT Enterprise dla wszystkich, Copilot na szeroką skalę albo stały kontrakt na Claude.

Problem: LLM-y rozwijają się szybciej niż jakiekolwiek zamówienia korporacyjne. To, co dziś jest najlepszym modelem do analizy tekstu, za pół roku może zostać wyparte przez tańszy lub wydajniejszy model. Kto buduje całą infrastrukturę na jednym dostawcy, ma vendor lock-in w najbardziej krytycznej decyzji technologicznej nadchodzących lat.

Architektura niezależna od modeli rozwiązuje ten problem: jednolity interfejs czatu dla wszystkich pracowników, a za nim warstwa orkiestracji routująca między modelami - Claude, ChatGPT, Gemini, Llama, Mistral, DeepSeek, gpt-oss. W zależności od przypadku użycia, kosztów lub wymogów ochrony danych odpowiedni model jest wybierany automatycznie. Zmiana modelu następuje bez modyfikacji interfejsu i bez konieczności ponownego szkolenia pracowników.

Gosign buduje tę [infrastrukturę AI](/pl/uslugi/infrastruktura/) jako niezależną od modeli i otwartą platformowo - jako wdrożenie chmurowe na Azure lub GCP albo w pełni self-hosted w infrastrukturze klienta.


## Od interfejsu czatu do platformy agentów

Interfejs czatu zgodny z RODO to punkt wejścia. Ale prawdziwa wartość pojawia się, gdy interfejs nie tylko odpowiada na pytania, lecz uruchamia procesy.

To przejście od czatu do infrastruktury agentów.

Konkretnie: pracownik przesyła w czacie zwolnienie lekarskie. [Document Agent](/pl/uslugi/ai-agents/) odczytuje dokument, wyodrębnia istotne dane, sprawdza terminy na podstawie regulaminu pracy i przygotowuje zapis w SAP. [Workflow Agent](/pl/uslugi/ai-agents/) orkiestruje dalszy proces: powiadomienie przełożonego, weryfikacja zastępstwa, kalkulacja wynagrodzenia za czas choroby. Knowledge Agent odpowiada na pytania pracownika na podstawie aktualnych polityk firmowych.

Interfejs czatu staje się jednolitym punktem wejścia dla wszystkich trzech typów agentów. Pracownik widzi prostą rozmowę. W tle infrastruktura orkiestruje agentów dokumentowych, procesowych i wiedzowych - z pełnym Audit Trail i [Human-in-the-Loop](/pl/governance/) przy krytycznych decyzjach.


## Governance to nie funkcja. Governance to architektura.

Każde niekontrolowane użycie ChatGPT tworzy martwy punkt: jakie dane zostały wprowadzone? Jakie odpowiedzi posłużyły do podejmowania decyzji? Kto, kiedy i o co pytał?

W firmowej infrastrukturze czatu z [Governance by Design](/pl/governance/) takie martwe punkty nie istnieją.

Każda interakcja jest logowana - prompt, odpowiedź, użyty model, znacznik czasu, rola użytkownika. Działania mające wpływ na decyzje przechodzą przez [Decision Layer](/pl/decision-layer/), który oddziela analizę od podejmowania decyzji. Krytyczne procesy wymagają zatwierdzenia przez człowieka, wbudowanego architektonicznie jako Human-in-the-Loop.

Dla Rady Zakładowej oznacza to: przejrzystość wykorzystania AI w firmie, udokumentowaną i weryfikowalną w każdej chwili. Dla audytu wewnętrznego: kompletny Audit Trail. Dla Inspektora Ochrony Danych (IOD): przetwarzanie danych w kontrolowanym środowisku, bez przesyłania do podmiotów trzecich, udokumentowane zgodnie z RODO.


## Ocena ryzyka: publiczna AI vs. infrastruktura korporacyjna

| Kategoria ryzyka | Publiczny ChatGPT / strony trzecie | Firmowa infrastruktura czatu |
|---|---|---|
| Suwerenność danych | Brak kontroli - dane na zewnętrznych serwerach | Pełna kontrola - self-hosted lub chmura UE |
| Trening modelu | Dane mogą być używane do treningu | Brak treningu na danych firmowych |
| Audit Trail | Brak | Kompletny - prompt, odpowiedź, użytkownik, model |
| Zgodność z RODO | Nie zagwarantowana | Wymuszona przez architekturę |
| Kontrola dostępu | Konta osobiste, brak RBAC | SSO z dostępem opartym na rolach |
| Integracja agentów | Niemożliwa | Document, Workflow, Knowledge Agents |
| Vendor lock-in | Przywiązanie do jednego dostawcy | Niezależność od modelu - zamiana bez przeszkolenia |

## Co dział IT musi teraz zdecydować

Pytanie nie brzmi już, czy pracownicy korzystają z AI. Pytanie brzmi, czy robią to w środowisku kontrolowanym, czy niekontrolowanym.

Trzy decyzje architektoniczne czekają na podjęcie.

Po pierwsze: hosting. Czy infrastruktura czatu powinna działać na Azure, GCP czy w pełni self-hosted? Odpowiedź zależy od istniejącego krajobrazu IT i wymogów ochrony danych. Wszystkie trzy opcje są technicznie równoważne - self-hosting nie wiąże się z żadnymi kompromisami architektonicznymi.

Po drugie: strategia modelowa. Jakie modele powinny być dostępne i jak sterowane jest routowanie? Architektura niezależna od modeli zachowuje wszystkie opcje i zapobiega vendor lock-in.

Po trzecie: roadmapa agentów. Czy interfejs czatu powinien docelowo łączyć się z agentami przetwarzającymi dokumenty i orkiestrującymi procesy? Jeśli tak - a odpowiedź brzmi niemal zawsze tak - to infrastruktura musi być na to zaprojektowana od samego początku.

W Gosign budujemy dokładnie taką infrastrukturę: niezależną od modeli, zgodną z RODO, z integracją agentów i Governance by Design. Od koncepcji do działającego interfejsu czatu w 4 - 6 tygodni. W [infrastrukturze klienta](/pl/uslugi/infrastruktura/), pod pełną kontrolą klienta. Bez SaaS, bez vendor lock-in.

--- Claude Code jako kontrola bezpieczeństwa w workflow DevOps ---
> Runbook DevOps dla automatycznych przeglądów bezpieczeństwa z Claude Code: instalacja, Custom Commands, skrypty audytowe i integracja CI.

Nowoczesne self-hosted stacki aplikacyjne składają się z wielu komponentów: Supabase Platform, warstwa Next.js, Edge Functions, Background Jobs i zewnętrzne API. Z każdym komponentem rośnie prawdopodobieństwo błędów konfiguracyjnych, wycieków sekretów, brakujących policies i niezabezpieczonych endpointów.

Tradycyjne skanery bezpieczeństwa sprawdzają statyczne reguły. Znajdują `service_role` w pliku `.env`, ale nie rozpoznają, że nowa Server Action nie ma tego samego sprawdzenia ownership, które jest obecne we wszystkich pozostałych Server Actions. Zgłaszają otwarte porty, ale nie rozpoznają, że zmiana firewalla w zeszłym tygodniu razem z nowym kontenerem otworzyła niezamierzoną ścieżkę dostępu.

**Claude Code wypełnia tę lukę jako kontekstowa warstwa analityczna nad całym stackiem.**

Claude Code nie zastępuje deterministycznych kontroli. Uzupełnia je, interpretując wyniki, rozpoznając powiązania i priorytetyzując rekomendacje.

Ten runbook opisuje, jak Claude Code jest konkretnie instalowany, konfigurowany i integrowany w workflow DevOps.


<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">W skrócie - Artykuł 5 z 6 serii DevOps Runbook</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Claude Code tylko na serwerze audytowym</li>
<li>Model trójwarstwowy</li>
<li>Custom Commands definiują zakres przeglądu</li>
<li>Tryb headless ograniczony do Read/Grep/Glob</li>
<li>Cotygodniowy audyt cron plus przeglądy PR</li>
</ul>
</div>

## Spis treści serii

Ten przewodnik jest częścią naszej serii runbooków DevOps dla self-hosted stacków aplikacyjnych.

1. [Supabase Self-Hosting Runbook](/pl/magazyn/supabase-self-hosting/)
2. [Next.js nad Supabase - bezpieczna eksploatacja](/pl/magazyn/nextjs-supabase-bezpieczna-konfiguracja/)
3. [Supabase Edge Functions - bezpieczne wdrożenie](/pl/magazyn/supabase-edge-functions-bezpieczenstwo/)
4. [Trigger.dev Background Jobs - bezpieczna eksploatacja](/pl/magazyn/trigger-dev-background-jobs/)
5. [Claude Code jako kontrola bezpieczeństwa w workflow DevOps](/pl/magazyn/claude-code-security-devops/) - ten artykuł
6. [Security Baseline dla całego stacku](/pl/magazyn/security-baseline-stack/)

Pierwsze cztery artykuły opisują poszczególne komponenty. Ten artykuł opisuje **warstwę kontroli bezpieczeństwa nad nimi**.

## Przegląd architektury

Claude Code działa **nie na serwerze produkcyjnym**, lecz na serwerze audytowym (patrz [Artykuł 1](/pl/magazyn/supabase-self-hosting/)). Ma dostęp tylko do odczytu danych, które analizuje.

```
Serwer produkcyjny (supabase-prod)
   |
   +-- Supabase Stack
   +-- Next.js App
   +-- Edge Functions
   +-- Trigger.dev
   |
   +---- SSH (read-only) ----> Serwer audytowy (audit-runner)
                                   |
                                   +-- Kontrole deterministyczne
                                   |   +-- Port Scans (nmap)
                                   |   +-- Firewall Diff (iptables-save)
                                   |   +-- Wersje kontenerów (docker images)
                                   |   +-- Status RLS (psql)
                                   |   +-- npm audit
                                   |   +-- Kontrole kodu oparte na grep
                                   |
                                   +-- Claude Code (headless)
                                   |   +-- Analizuje wyniki kontroli
                                   |   +-- Czyta Git Diffy
                                   |   +-- Sprawdza konfiguracje względem runbooków
                                   |   +-- Tworzy priorytetyzowany raport
                                   |
                                   +-- Raport -> Zespół DevOps (człowiek decyduje)
```

**Claude Code nie wykonuje żadnych zmian na systemie produkcyjnym. Żadnych deploymentów, żadnej rotacji sekretów, żadnych zatrzymań kontenerów.**


### Porównanie trzech warstw

| Właściwość | Kontrole deterministyczne | Reguły runbooków | Analiza Claude |
|---|---|---|---|
| Wejście | Polecenia systemowe (nmap, grep) | Pliki Markdown | Output z warstw 1+2 |
| Wyjście | Fakty (otwarty/zamknięty, obecny/brak) | Stan docelowy (POWINIEN) | Priorytetyzowany raport |
| Częstotliwość | Codziennie (cron) | Statyczna (aktualizacja przy zmianach) | Cotygodniowo + przy PR |
| Fałszywe pozytywy | Brak (obiektywne) | Brak (zdefiniowane reguły) | Możliwe (interpretacja) |
| Wykrywanie dryftu | Znane wzorce | Brak (referencja) | Nieznane wzorce |

## Podstawowa zasada: Trzy poziomy kontroli bezpieczeństwa

```
Poziom 1: Kontrole deterministyczne (skrypty)
   -> Obiektywne, powtarzalne wyniki
   -> Przykład: "Port 5432 jest dostępny z zewnątrz" = fakt

Poziom 2: Reguły runbooków (pliki Markdown)
   -> Zdefiniowany stan docelowy stacku
   -> Przykład: "Postgres może nasłuchiwać tylko na 10.0.1.10"

Poziom 3: Analiza kontekstowa Claude Code (headless)
   -> Interpretuje wyniki, rozpoznaje powiązania
   -> Przykład: "Port 5432 jest otwarty I nowy kontener
     ma bezpośrednie połączenie z DB. To jest problem."
```

Poziomy budują na sobie wzajemnie. Claude otrzymuje wyniki z poziomu 1 i reguły z poziomu 2 jako input i tworzy z nich swój kontekstowy przegląd.

## Część A - Konfiguracja Claude Code

## A1 - Instalacja i konfiguracja na serwerze audytowym

### Implementacja

Claude Code jest instalowany na serwerze audytowym, nie na serwerze produkcyjnym.

```bash
# Na serwerze audit-runner

# Instalacja Node.js (jeśli nie jest zainstalowany)
curl -fsSL https://deb.nodesource.com/setup_20.x | sudo bash -
apt-get install -y nodejs

# Instalacja Claude Code
npm install -g @anthropic-ai/claude-code

# Konfiguracja API Key
# Osobny API Key z limitem budżetowym dla CI/CD
export ANTHROPIC_API_KEY="sk-ant-..."

# Utrwalenie w .bashrc lub .env dla użytkownika audit
echo 'export ANTHROPIC_API_KEY="sk-ant-..."' >> /home/audit/.bashrc
```

**Test trybu headless:**

```bash
# Prosty test: czy Claude Code działa nieinteraktywnie?
echo "Hello" | claude -p "Antworte mit OK wenn du das lesen kannst" \
  --output-format text

# Oczekiwanie: "OK" lub podobne potwierdzenie
```

### Sprawdzalny warunek

```bash
# Claude Code zainstalowany?
claude --version
# Oczekiwanie: numer wersji

# API Key ustawiony?
test -n "$ANTHROPIC_API_KEY" && echo "OK" || echo "BRAK"

# Tryb headless działa?
claude -p "Sage nur: OK" --output-format text --max-turns 1 2>/dev/null
# Oczekiwanie: "OK"
```

### Scenariusz awarii

Jeśli Claude Code działa na serwerze produkcyjnym i ma tam dostęp do Bash, błędny prompt mógłby teoretycznie wykonać polecenia na systemie produkcyjnym. Na serwerze audytowym Claude Code ma dostęp tylko do zebranych raportów i kopii konfiguracji, nie do systemu live.

## A2 - Konfiguracja Custom Security Review Command

### Implementacja

Claude Code obsługuje Custom Commands przez pliki Markdown w `.claude/commands/`. Te Commands definiują kontekst i reguły kontroli dla przeglądu bezpieczeństwa.

```bash
# W repozytorium infrastruktury
mkdir -p .claude/commands
```

```markdown
# .claude/commands/security-review.md

Du bist Security Reviewer für einen self-hosted Stack bestehend aus:
- Supabase (PostgreSQL, PostgREST, GoTrue, Kong, Edge Functions)
- Next.js (App-Schicht, Server Actions, Route Handler)
- Trigger.dev v3 (Background Jobs, self-hosted)
- Wszystko na infrastrukturze w UE (np. Hetzner, OVH)

Du erhältst den Output der deterministischen Security Checks und die
aktuellen Konfigurationsdateien.

Prüfe folgendes:

## Infrastruktur (Artikel 1)
- Sind unerwartete Ports von aussen erreichbar?
- Hat sich die Firewall gegenüber der Baseline geändert?
- Sind Container-Versionen gepinnt und aktuell?
- Ist das TLS-Zertifikat noch mindestens 14 Tage gültig?
- Liegt das letzte Backup weniger als 26 Stunden zurück?

## Next.js (Artikel 2)
- Taucht service_role in NEXT_PUBLIC Variablen oder im Client-Bundle auf?
- Haben alle Server Actions einen getUser() Auth Check?
- Haben alle Route Handler einen getUser() Auth Check?
- Existiert middleware.ts mit getUser() (nicht getSession())?
- Sind Security Headers in next.config.js gesetzt?

## Edge Functions (Artikel 3)
- Haben alle Webhook-Functions eine Signaturprüfung?
- Gibt es Functions mit Business-Logik statt Integrations-Logik?
- Ist CORS korrekt konfiguriert (kein Wildcard in Produktion)?
- Gibt es hardcoded Secrets im Function-Code?

## Trigger.dev (Artikel 4)
- Haben alle Tasks maxDuration und concurrencyLimit?
- Haben Tasks mit externen API-Calls Idempotency Keys?
- Nutzen Tasks nur die DB-Felder die sie brauchen (kein SELECT *)?
- Gibt es console.log statt dem Trigger.dev logger?

## Stackübergreifend
- Gibt es Architektur-Drift? (Business-Logik in Edge Functions,
  Langläufer in Server Actions, etc.)
- Sind die Änderungen der letzten Woche konsistent mit der
  bestehenden Architektur?
- Gibt es neue Tabellen ohne RLS?
- Gibt es Muster die auf systematische Probleme hindeuten?

Erstelle einen priorisierten Bericht:
- KRITISCH: sofort handeln (Daten-Leak möglich, Port offen, Secret exponiert)
- WARNUNG: diese Woche lösen (fehlende Checks, Drift, veraltete Packages)
- INFO: bei Gelegenheit verbessern (Code-Qualität, fehlende Tests)

Für jedes Finding: Was ist das Problem, warum ist es ein Risiko,
was ist die konkrete Lösung.
```

### Sprawdzalny warunek

```bash
# Custom Command istnieje?
test -f .claude/commands/security-review.md && echo "OK" || echo "BRAK"

# Command jest rozpoznawany przez Claude Code?
claude -p "/security-review" --max-turns 1 2>/dev/null | head -5
# Oczekiwanie: Claude rozpoczyna analizę
```

## A3 - CLAUDE.md jako kontekst projektu

### Implementacja

Claude Code automatycznie czyta plik `CLAUDE.md` w katalogu projektu. Ten plik zapewnia Claude stały kontekst dotyczący stacku.

```markdown
# CLAUDE.md (w katalogu głównym repozytorium infrastruktury)

## Stack-Überblick
Self-hosted Supabase + Next.js + Edge Functions + Trigger.dev v3
na infrastrukturze w UE (np. Hetzner, OVH).

## Server
- supabase-prod: 10.0.1.10 (Supabase, Next.js, Edge Functions)
- audit-runner: 10.0.1.11 (Security Checks, Claude Code, Monitoring)
- trigger-server: separater Docker-Stack für Trigger.dev v3

## Sicherheitsregeln
- service_role Key darf NUR in: lib/supabase/admin.ts und trigger/lib/supabase.ts
- NEXT_PUBLIC_* darf NUR enthalten: SUPABASE_URL und SUPABASE_ANON_KEY
- Alle public-Tabellen müssen RLS aktiviert haben
- Alle Server Actions und Route Handler müssen getUser() aufrufen
- Alle Webhook Edge Functions müssen Signaturen prüfen
- Alle Trigger.dev Tasks müssen maxDuration und concurrencyLimit haben
- PostgreSQL nur auf 10.0.1.10:5432 (internes Interface)
- Supabase Studio nicht von aussen erreichbar
- Trigger.dev Dashboard nicht von aussen erreichbar

## Deployment
- Infrastruktur wird nur über Git deployed (kein manuelles SSH-Editing)
- Edge Functions werden als Dateien in volumes/functions/ abgelegt
- Trigger.dev Tasks werden über npx trigger.dev deploy --self-hosted deployed

## Verzeichnisstruktur
- app/ = Next.js App (Server Actions, Route Handler, Pages)
- lib/supabase/ = Supabase Client Konfiguration
- middleware.ts = Auth Middleware
- volumes/functions/ = Supabase Edge Functions
- trigger/tasks/ = Trigger.dev Tasks
- infra/ = docker-compose, nginx/caddy, Firewall Configs
- scripts/ = Audit Scripts, Backup, Restore
- runbooks/ = Sicherheits-Runbooks
```

Kto łączy [podejście CLAUDE.md z regułami bezpieczeństwa z artykułu 2](/pl/magazyn/nextjs-supabase-bezpieczna-konfiguracja/), uzyskuje kompletną bazę kontekstową dla automatycznych przeglądów.

## Część B - Kompletny workflow audytu

Tutaj łączy się to, co przygotowały [artykuły 1 do 4](/pl/magazyn/supabase-self-hosting/). Każdy artykuł ma własne skrypty kontrolne. Artykuł 5 scala je i przekazuje output do Claude Code.

## B1 - Kompletny skrypt audytowy

### Implementacja

Ten skrypt zbiera wszystkie wyniki kontroli deterministycznych i przekazuje je do Claude Code w trybie headless.

```bash
#!/bin/bash
# scripts/full-security-audit.sh
# Działa na serwerze audit-runner

set -euo pipefail

PROD_HOST="10.0.1.10"
REPORT_DIR="/opt/audit/reports"
DATE=$(date +%Y-%m-%d)
REPORT_FILE="${REPORT_DIR}/audit-input-${DATE}.md"

mkdir -p "$REPORT_DIR"

echo "=== Gesamt-Security-Audit ${DATE} ===" | tee "$REPORT_FILE"

# -------------------------------------------
# POZIOM 1: Kontrole deterministyczne
# -------------------------------------------

echo -e "\n# Deterministische Check-Ergebnisse\n" >> "$REPORT_FILE"

# --- Infrastruktura (Artykuł 1) ---
echo "## Infrastruktur" >> "$REPORT_FILE"

echo "### Offene Ports (extern)" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
nmap -p 22,80,443,3000,3040,5432,5433,8000,9000 app.example.com \
  --open -oG - 2>/dev/null >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"

echo "### Firewall Diff gegen Baseline" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "iptables-save" | \
  diff /opt/baselines/firewall-baseline.txt - >> "$REPORT_FILE" 2>&1 || true
echo '```' >> "$REPORT_FILE"

echo "### Container Status" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "docker compose ps --format 'table {{.Name}}\t{{.Status}}\t{{.Image}}'" \
  >> "$REPORT_FILE" 2>&1
echo '```' >> "$REPORT_FILE"

echo "### TLS Zertifikat" >> "$REPORT_FILE"
CERT_EXPIRY=$(echo | openssl s_client -connect app.example.com:443 2>/dev/null | \
  openssl x509 -noout -enddate 2>/dev/null | cut -d= -f2)
CERT_EPOCH=$(date -d "$CERT_EXPIRY" +%s 2>/dev/null || echo 0)
NOW_EPOCH=$(date +%s)
DAYS_LEFT=$(( (CERT_EPOCH - NOW_EPOCH) / 86400 ))
echo "Ablauf: ${CERT_EXPIRY} (${DAYS_LEFT} Tage)" >> "$REPORT_FILE"

echo "### Backup Status" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "ls -lh /opt/backups/*.gpg 2>/dev/null | tail -3" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"

echo "### RLS Status" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "docker compose exec -T postgres psql -U postgres -c \
  \"SELECT tablename, rowsecurity FROM pg_tables WHERE schemaname = 'public' ORDER BY tablename;\"" \
  >> "$REPORT_FILE" 2>&1
echo '```' >> "$REPORT_FILE"

echo "### Disk Usage" >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "df -h / | tail -1" >> "$REPORT_FILE"

# --- Next.js (Artykuł 2) ---
echo -e "\n## Next.js App-Schicht" >> "$REPORT_FILE"

echo "### service_role im Client Code" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "cd /opt/app && grep -rn 'SERVICE_ROLE\|service_role' app/ \
  --include='*.ts' --include='*.tsx' | grep -v 'lib/supabase/admin.ts' | grep -v node_modules" \
  >> "$REPORT_FILE" 2>&1 || echo "Keine Treffer" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"

echo "### NEXT_PUBLIC mit Secrets" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "cd /opt/app && grep 'NEXT_PUBLIC_' .env* 2>/dev/null | \
  grep -iE 'service_role|secret|private|database'" \
  >> "$REPORT_FILE" 2>&1 || echo "Keine Treffer" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"

echo "### Server Actions ohne Auth" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "cd /opt/app && for file in \$(grep -rl \"'use server'\" app/ --include='*.ts'); do
  if ! grep -q 'getUser' \"\$file\"; then
    echo \"WARNUNG: \$file\"
  fi
done" >> "$REPORT_FILE" 2>&1 || echo "Keine Treffer" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"

echo "### Route Handler ohne Auth" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "cd /opt/app && for file in \$(find app/api -name 'route.ts' 2>/dev/null); do
  if ! grep -q 'getUser' \"\$file\"; then
    echo \"WARNUNG: \$file\"
  fi
done" >> "$REPORT_FILE" 2>&1 || echo "Keine Treffer" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"

echo "### npm audit" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "cd /opt/app && npm audit --audit-level=high 2>&1 | tail -20" \
  >> "$REPORT_FILE" 2>&1
echo '```' >> "$REPORT_FILE"

# --- Edge Functions (Artykuł 3) ---
echo -e "\n## Edge Functions" >> "$REPORT_FILE"

echo "### Webhook Functions ohne Signaturprüfung" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "for dir in /opt/supabase/volumes/functions/*-webhook/; do
  [ -d \"\$dir\" ] || continue
  name=\$(basename \"\$dir\")
  if ! grep -qE 'signature|verify|hmac|crypto' \"\$dir/index.ts\" 2>/dev/null; then
    echo \"KRITISCH: \$name hat keine Signaturprüfung\"
  else
    echo \"OK: \$name\"
  fi
done" >> "$REPORT_FILE" 2>&1
echo '```' >> "$REPORT_FILE"

echo "### Hardcoded Secrets in Functions" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "grep -rn 'sk_live\|sk_test\|whsec_\|Bearer ey' \
  /opt/supabase/volumes/functions/ --include='*.ts' 2>/dev/null" \
  >> "$REPORT_FILE" 2>&1 || echo "Keine Treffer" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"

# --- Trigger.dev (Artykuł 4) ---
echo -e "\n## Trigger.dev Tasks" >> "$REPORT_FILE"

echo "### Tasks ohne maxDuration" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "cd /opt/app && for file in trigger/tasks/*.ts; do
  name=\$(basename \"\$file\" .ts)
  if ! grep -q 'maxDuration' \"\$file\" 2>/dev/null; then
    echo \"WARNUNG: \$name\"
  fi
done" >> "$REPORT_FILE" 2>&1
echo '```' >> "$REPORT_FILE"

echo "### Tasks ohne Concurrency Limit" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "cd /opt/app && for file in trigger/tasks/*.ts; do
  name=\$(basename \"\$file\" .ts)
  if ! grep -qE 'concurrencyLimit|queue:' \"\$file\" 2>/dev/null; then
    echo \"WARNUNG: \$name\"
  fi
done" >> "$REPORT_FILE" 2>&1
echo '```' >> "$REPORT_FILE"

# --- Zmiany w kodzie ---
echo -e "\n## Code-Änderungen (letzte 7 Tage)" >> "$REPORT_FILE"
echo '```' >> "$REPORT_FILE"
ssh deploy@${PROD_HOST} "cd /opt/app && git log --oneline --since='7 days ago'" \
  >> "$REPORT_FILE" 2>&1
ssh deploy@${PROD_HOST} "cd /opt/app && git diff HEAD~10 --stat 2>/dev/null" \
  >> "$REPORT_FILE" 2>&1
echo '```' >> "$REPORT_FILE"

# -------------------------------------------
# POZIOM 2: Reguły runbooków (jako kontekst)
# -------------------------------------------

echo -e "\n# Aktive Runbook-Regeln\n" >> "$REPORT_FILE"
cat runbooks/security-baseline.md >> "$REPORT_FILE" 2>/dev/null || \
  echo "security-baseline.md nicht gefunden" >> "$REPORT_FILE"

# -------------------------------------------
# POZIOM 3: Analiza Claude Code
# -------------------------------------------

echo ""
echo "=== Deterministische Checks abgeschlossen ==="
echo "=== Starte Claude Code Analyse ==="
echo ""

# Wywołanie Claude Code w trybie headless
# --allowedTools ograniczone: tylko odczyt, bez Bash, bez zapisu
CLAUDE_OUTPUT=$(cat "$REPORT_FILE" | claude -p \
  "Du erhältst den vollständigen Security-Audit-Report unseres self-hosted Stacks.
Analysiere ihn gemäss den Regeln in .claude/commands/security-review.md.
Erstelle einen priorisierten Bericht mit KRITISCH / WARNUNG / INFO.
Für jedes Finding: Problem, Risiko, konkrete Lösung." \
  --allowedTools "Read,Grep,Glob" \
  --append-system-prompt "Du bist ein Senior Security Engineer. Antworte auf Deutsch. Sei konkret und priorisiere strikt." \
  --output-format text \
  --max-turns 5 \
  2>/dev/null)

# Zapis raportu
CLAUDE_REPORT="${REPORT_DIR}/claude-review-${DATE}.md"
echo "$CLAUDE_OUTPUT" > "$CLAUDE_REPORT"

echo ""
echo "=== Claude Code Review abgeschlossen ==="
echo "Report: $CLAUDE_REPORT"

# Przy krytycznych findings: alert
if echo "$CLAUDE_OUTPUT" | grep -qi "KRITISCH"; then
  echo "$CLAUDE_OUTPUT" | mail -s "KRITISCH: Security Review ${DATE}" ops@example.com
  echo "Alert gesendet an ops@example.com"
fi
```

### Sprawdzalny warunek

```bash
# Skrypt jest wykonywalny?
test -x scripts/full-security-audit.sh && echo "OK" || echo "NIE WYKONYWALNY"

# Ostatni raport audytowy istnieje?
ls -la /opt/audit/reports/claude-review-$(date +%Y-%m-%d).md 2>/dev/null
# Oczekiwanie: plik z dzisiejszą datą

# Raport zawiera oczekiwane sekcje?
grep -c "KRITISCH\|WARNUNG\|INFO" /opt/audit/reports/claude-review-$(date +%Y-%m-%d).md
# Oczekiwanie: co najmniej 1
```

## B2 - Kiedy audyt jest uruchamiany

### Trzy punkty wyzwalania

```
1. Cotygodniowy Cron (niedziela 6:00)
   -> Pełny audyt całego stacku
   -> Wynik: priorytetyzowany raport na tydzień

2. Przy Pull Requestach (CI/CD)
   -> Tylko zmienione pliki
   -> Wynik: komentarz review do PR

3. Ad-hoc (ręcznie)
   -> Po incydentach, dużych deploymentach, zmianach infrastruktury
   -> Wynik: natychmiastowa analiza
```

**Cotygodniowy Cron:**

```bash
# crontab na serwerze audit-runner
0 6 * * 0 /opt/audit/scripts/full-security-audit.sh >> /var/log/security-audit.log 2>&1
```

**PR Review (Git Diff przekierowany do Claude):**

```bash
#!/bin/bash
# scripts/pr-security-review.sh
# Wywoływany przez CI przy każdym PR

DIFF=$(git diff origin/main...HEAD)

if [ -z "$DIFF" ]; then
  echo "Brak diffa, review nie jest potrzebny"
  exit 0
fi

echo "$DIFF" | claude -p \
  "Review diesen Git Diff auf Sicherheitsprobleme.
Prüfe insbesondere:
- service_role Nutzung in Client-Code
- Server Actions ohne Auth Check
- Edge Functions ohne Signaturprüfung
- Trigger.dev Tasks ohne maxDuration
- Hardcoded Secrets
- Neue API Endpoints ohne Rate Limiting

Antworte NUR wenn du ein konkretes Problem findest.
Wenn alles in Ordnung ist, sage: Keine Sicherheitsprobleme gefunden." \
  --allowedTools "Read,Grep,Glob" \
  --output-format text \
  --max-turns 3
```

**Ad-hoc Review:**

```bash
# Ręcznie po incydencie
cd /opt/infra-repo
claude -p "Prüfe den aktuellen Zustand des Repositories auf Sicherheitsprobleme. \
Fokus auf die letzten 5 Commits." \
  --allowedTools "Read,Grep,Glob,Bash(git log*),Bash(git diff*)" \
  --max-turns 10
```

### Sprawdzalny warunek

```bash
# Cron Job aktywny?
crontab -l | grep "full-security-audit"
# Oczekiwanie: wpis obecny

# Ostatni audyt mniej niż 8 dni temu?
LAST_REPORT=$(ls -t /opt/audit/reports/claude-review-*.md 2>/dev/null | head -1)
if [ -n "$LAST_REPORT" ]; then
  AGE=$(( ($(date +%s) - $(stat -c %Y "$LAST_REPORT")) / 86400 ))
  echo "Ostatni raport: $AGE dni temu"
  [ "$AGE" -gt 8 ] && echo "OSTRZEŻENIE: Audyt zaległy"
fi
```

## Część C - Co Claude potrafi, a czego nie

## C1 - Gdzie Claude Code jest szczególnie skuteczny

Claude rozpoznaje powiązania, których kontrole deterministyczne nie są w stanie wykryć:

**Rozpoznawanie dryftu architektury:**
Kontrole deterministyczne znajdują nową Edge Function. Claude rozpoznaje, że ta funkcja zawiera logikę biznesową, która powinna znajdować się w [Next.js](/pl/magazyn/nextjs-supabase-bezpieczna-konfiguracja/), ponieważ przetwarza dane wejściowe użytkownika i transformuje dane zamiast odbierać zewnętrzne zdarzenie.

**Wzorce wykraczające poza granice plików:**
`grep` znajduje brak `getUser()` w jednej Server Action. Claude rozpoznaje, że ta Action jest jedyną z 15 Actions, w której brakuje tego sprawdzenia, i że została dodana w zeszłym tygodniu w commicie, który zmienił również trzy inne pliki - wszystkie poprawnie. To wskazuje na przeoczenie, nie na problem systemowy.

**Priorytetyzacja:**
Kontrole deterministyczne tworzą płaską listę 30 findings. Claude grupuje je: "5 findings dotyczących service_role jest w bibliotece Admin i jest poprawnych. 2 brakujące kontrole Auth w Route Handlerach to rzeczywiste ryzyko, ponieważ dotyczą publicznych endpointów API."

**Kontekst konfiguracyjny:**
Skan portów pokazuje, że port 8000 jest otwarty. Claude wie z kontekstu stacku (CLAUDE.md), że port 8000 to wewnętrzny port Kong, i sprawdza, czy powinien nasłuchiwać tylko na localhost.

## C2 - Czego Claude Code nie potrafi i czego nie wolno mu robić

**Claude nie potrafi aktywnie skanować.** Nie jest w stanie przeprowadzać skanów sieciowych, sprawdzać działających procesów ani testować portów z zewnątrz. To robią narzędzia deterministyczne (nmap, ss, docker ps). Claude analizuje ich output.

**Claude nie wolno zapisywać na produkcji.** Ograniczenie `--allowedTools` w trybie headless zapewnia, że Claude może tylko czytać:

```bash
# POPRAWNIE: dozwolone tylko narzędzia do odczytu
claude -p "..." --allowedTools "Read,Grep,Glob"

# ŹŁLE: Bash dozwolony = Claude może wykonywać dowolne polecenia
claude -p "..." --allowedTools "Read,Grep,Glob,Bash"
```

Jeśli Bash jest potrzebny (np. dla `git log`), dozwalaj tylko konkretne polecenia:

```bash
--allowedTools "Read,Grep,Glob,Bash(git log*),Bash(git diff*)"
```

**Claude nie jest deterministyczny.** Ten sam input może prowadzić do nieco różnych raportów. Dlatego Claude nie zastępuje deterministycznych kontroli. Interpretuje ich wyniki.

> **Statystyka:** Zgodnie z raportem OWASP z 2024 roku ponad 34% naruszeń bezpieczeństwa wynika z błędów konfiguracyjnych, a nie z luk w kodzie - dokładnie ten typ problemów, do którego wykrywania przeznaczona jest kontekstowa analiza.


**Claude nie zna danych w czasie rzeczywistym.** Pracuje z migawkami, które zostały mu przekazane w momencie audytu. Między audytem a lekturą raportu stan mógł się zmienić.

## C3 - Reguły bezpieczeństwa dla Claude Code w CI

```bash
# Na serwerze audytowym: konfiguracja Claude Code

# 1. Osobny API Key z limitem budżetowym
#    Odrębny klucz, nie klucz dewelopera
#    Budżet: maks. 50 USD/miesiąc na przeglądy CI

# 2. --allowedTools zawsze ograniczaj
#    Nigdy nieograniczonego dostępu do Bash w zautomatyzowanych skryptach

# 3. --max-turns ogranicz
#    Zapobiega nieskończonym pętlom przy mylących inputach
#    Rekomendacja: 3-5 dla przeglądów PR, 5-10 dla pełnych audytów

# 4. Output zawsze zapisuj do pliku
#    Nie tylko na stdout, aby raport pozostał udokumentowany

# 5. Claude Code nie ma dostępu SSH do produkcji
#    Skrypty deterministyczne zbierają dane
#    Claude otrzymuje tylko tekstowy output do analizy
```

## Lista kontrolna deploymentu

```
Instalacja
  [ ] Claude Code zainstalowany na audit-runner
  [ ] API Key skonfigurowany (osobny klucz CI z limitem budżetowym)
  [ ] Tryb headless działa (test z claude -p)

Konfiguracja
  [ ] .claude/commands/security-review.md utworzony
  [ ] CLAUDE.md w repozytorium infrastruktury obecny
  [ ] --allowedTools ograniczone do Read,Grep,Glob
  [ ] --max-turns ograniczone do 5-10

Automatyzacja
  [ ] Kompletny skrypt audytowy obecny i wykonywalny
  [ ] Cotygodniowy Cron Job aktywny
  [ ] Skrypt PR Review zintegrowany w CI
  [ ] Alert przy krytycznych findings skonfigurowany

Bezpieczeństwo
  [ ] Claude Code działa TYLKO na audit-runner
  [ ] Claude Code NIE MA dostępu SSH do produkcji
  [ ] Brak nieograniczonego dostępu Bash w --allowedTools
  [ ] Raporty są zapisywane i archiwizowane
  [ ] Limit budżetowy na API Key ustawiony
```

## Podsumowanie

Claude Code nie jest automatycznym skanerem bezpieczeństwa i nie zastępuje deterministycznych kontroli. Jest **kontekstowym analitykiem**, który interpretuje wyniki skanerów i kontroli grep, rozpoznaje powiązania i priorytetyzuje rekomendacje.

Workflow jest zawsze taki sam: narzędzia deterministyczne zbierają fakty, Claude Code je interpretuje, człowiek decyduje. Działa to, ponieważ każdy poziom robi to, w czym jest najlepszy. Skrypty są niezawodne przy znanych wzorcach. Claude rozpoznaje nieznane wzorce. Ludzie podejmują decyzje.

Połączenie skryptów kontrolnych z artykułów 1-4, Custom Security Review Command i cotygodniowego Cron audytu daje kontrolę bezpieczeństwa, która wykrywa zarówno znane, jak i nieoczekiwane ryzyka.

Kto stosuje te zasady razem z architekturą [Cert-Ready by Design](/pl/magazyn/cert-ready-by-design/), buduje weryfikowalne bezpieczeństwo zamiast audytów po fakcie.

<div class="not-prose my-12 border border-gosign-border bg-gosign-light rounded-card p-6 lg:p-8">
<div class="flex items-start gap-4">
<div class="flex-shrink-0 w-12 h-12 bg-gosign-dark rounded-card flex items-center justify-center">
<svg width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="white" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 15v4a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2v-4"/><polyline points="7 10 12 15 17 10"/><line x1="12" y1="15" x2="12" y2="3"/></svg>
</div>
<div>
<h2 class="text-h3 font-bold text-gosign-dark mb-2" id="listy-kontrolne-audytu-serii">Listy kontrolne audytu serii</h2>
<p class="text-body text-gosign-text mb-4">Przygotowane prompty dla Claude Code. Każda lista kontrolna automatycznie weryfikuje punkty bezpieczeństwa danego runbooka i zgłasza ZALICZONY, OSTRZEŻENIE lub KRYTYCZNY.</p>
<div class="flex flex-wrap gap-3">
<a href="/downloads/claude-check-artikel-1-supabase-pl.md" download class="inline-flex items-center px-4 py-2 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-sm">Supabase Infrastructure</a>
<a href="/downloads/claude-check-artikel-2-nextjs-pl.md" download class="inline-flex items-center px-4 py-2 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-sm">Next.js Security</a>
<a href="/downloads/claude-check-artikel-3-edge-functions-pl.md" download class="inline-flex items-center px-4 py-2 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-sm">Edge Functions</a>
<a href="/downloads/claude-check-artikel-4-trigger-dev-pl.md" download class="inline-flex items-center px-4 py-2 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-sm">Trigger.dev</a>
</div>
</div>
</div>
</div>

## Spis treści serii

1. [Supabase Self-Hosting Runbook](/pl/magazyn/supabase-self-hosting/)
2. [Next.js nad Supabase - bezpieczna eksploatacja](/pl/magazyn/nextjs-supabase-bezpieczna-konfiguracja/)
3. [Supabase Edge Functions - bezpieczne wdrożenie](/pl/magazyn/supabase-edge-functions-bezpieczenstwo/)
4. [Trigger.dev Background Jobs - bezpieczna eksploatacja](/pl/magazyn/trigger-dev-background-jobs/)
5. [Claude Code jako kontrola bezpieczeństwa w workflow DevOps](/pl/magazyn/claude-code-security-devops/) - ten artykuł
6. [Security Baseline dla całego stacku](/pl/magazyn/security-baseline-stack/)

Kolejny i ostatni artykuł opisuje **Security Baseline dla całego stacku**, która scala wszystkie reguły z artykułów 1-5 w jednym weryfikowalnym pliku.

--- Czym są agenci AI? Trzy typy dla przedsiębiorstw ---
> Agenci AI to wyspecjalizowane komponenty, które autonomicznie realizują zadania biznesowe. Trzy typy, różnice wobec chatbotów i RPA.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">W skrócie - Agenci AI w przedsiębiorstwie</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Agenci AI to wyspecjalizowane komponenty programowe realizujące zadania biznesowe autonomicznie - w odróżnieniu od chatbotów (tylko odpowiedzi) czy RPA (tylko reguły).</li>
<li>Trzy typy: Document Agents (odczyt i przetwarzanie dokumentów), Workflow Agents (orkiestracja procesów między systemami), Knowledge Agents (odpowiedzi kontekstowe z wiedzy firmowej).</li>
<li>McKinsey (2024) szacuje, że agenci AI mogą zautomatyzować do 30% godzin pracy w większości zawodów do 2030 roku.</li>
<li>Agent to nie model - model językowy jest wymienny, agent dostarcza logikę biznesową, integrację systemową i governance.</li>
<li>Wdrożenie w organizacji wymaga Decision Layer między agentem a systemem docelowym - aby każda zautomatyzowana decyzja była przejrzysta, audytowalna i zgodna z regulacjami.</li>
</ul>
</div>

## Czym jest agent AI?

Agent AI to wyspecjalizowany komponent programowy, który na bazie dużych modeli językowych (LLM) autonomicznie realizuje zadania biznesowe. W odróżnieniu od chatbota, który odpowiada na pytania, agent wykonuje działania: odczytuje dokument, ocenia jego zawartość, podejmuje decyzje i uruchamia akcje w systemie docelowym.

Agenci AI w kontekście korporacyjnym nie działają dowolnie. Operują w ramach zdefiniowanych granic: zestawów reguł, zakresów obowiązywania, progów pewności, reguł eskalacji. Każda decyzja agenta jest przejrzysta i audytowalna.

Podstawą agenta AI jest model językowy - Claude, ChatGPT, Gemini, Llama, Mistral, DeepSeek lub gpt-oss. Model dostarcza rozumienie języka. Agent dostarcza logikę biznesową, integrację systemową i governance.

## Rozgraniczenie: Agent AI vs. chatbot vs. RPA

Te trzy koncepcje są często mylone. Rozwiązują różne problemy.

**Chatbot:** Chatbot odpowiada na pytania w języku naturalnym. Nie ma zdolności do działania. Gdy pracownik pyta "Ile dni urlopu mi jeszcze zostało?", chatbot odpowiada. Nie rezerwuje urlopu, nie sprawdza reguł, nie tworzy Audit Trail.

**RPA (Robotic Process Automation):** RPA automatyzuje powtarzalne zadania oparte na regułach poprzez interfejsy użytkownika. Bot RPA klika przez SAP, kopiuje dane z A do B, wypełnia formularze. RPA nie rozumie języka. Gdy formularz się zmienia, bot przestaje działać.

**Agent AI:** Agent AI rozumie kontekst, interpretuje nieustrukturyzowane dane i podejmuje decyzje. Odczytuje fakturę - niezależnie od formatu - rozumie jej zawartość, stosuje zestawy reguł i generuje propozycje księgowania. Gdy format faktury się zmienia, agent działa dalej, bo rozumie treść, a nie rozpoznaje układ strony.

| Właściwość | Chatbot | RPA | Agent AI |
|------------|---------|-----|----------|
| Rozumienie języka | Tak | Nie | Tak |
| Zdolność do działania | Nie | Tak (oparta na regułach) | Tak (oparta na kontekście) |
| Nieustrukturyzowane dane | Tak | Nie | Tak |
| Governance/Audyt | Nie | Częściowo | Tak (przez Decision Layer) |
| Integracja systemowa | Powierzchowna | Przez UI | Przez API/Integration Layer |
| Adaptacja do zmian | Zmiana promptu | Przeprogramowanie bota | Agent uczy się kontekstu |

## Trzy typy agentów AI w organizacji

W architekturze Gosign wyróżniamy trzy typy agentów. Każdy typ ma zdefiniowany zakres zadań i operuje w granicach, które wyznacza Decision Layer.

### Document Agents

Document Agents odczytują, rozumieją i przetwarzają dokumenty. Faktury, zwolnienia lekarskie, umowy, zaświadczenia, dowody księgowe, korekty.

Kluczowa różnica wobec OCR lub rozpoznawania szablonów: Document Agents mają prawdziwe rozumienie języka. Nie rozpoznają pól na określonych pozycjach strony, lecz rozumieją treść dokumentu. Faktura w formacie PDF, jako zeskanowany obraz lub jako załącznik e-mail - Document Agent rozumie wszystkie trzy.

Document Agent do przetwarzania dokumentów księgowych odczytuje fakturę przychodzącą i wyodrębnia: wystawcę, kwotę, opis usługi, datę, stawkę podatkową, dane bankowe. Generuje ustrukturyzowany zestaw danych, który przekazywany jest do Decision Layer.

Document Agents nie działają w izolacji. Są punktem wejściowym workflow - po odczytaniu dokumentu przejmuje Workflow Agent.

### Workflow Agents

Workflow Agents orkiestrują procesy między systemami. Koordynują przebieg między Document Agent, Decision Layer i systemem docelowym.

Workflow Agent do przetwarzania faktur koordynuje: Document Agent odczytuje fakturę -> Decision Layer sprawdza propozycję księgowania -> przy wysokiej pewności księgowanie trafia do systemu docelowego -> przy niskiej pewności eskalacja do referenta -> po zatwierdzeniu księgowanie jest finalizowane -> cały proces jest dokumentowany w Audit Trail.

Workflow Agents obsługują także wyjątki: Co się dzieje, gdy system docelowy jest niedostępny? Co się dzieje przy timeout? Co się dzieje, gdy referent nie reaguje? Workflow Agent ma reguły eskalacji, mechanizmy ponownych prób i logikę timeout.

Orkiestracja workflow odbywa się przez [Trigger.dev](https://trigger.dev/) lub [Camunda](https://camunda.com/) - w zależności od złożoności i wymagań compliance klienta. Workflow są wizualizowane, wersjonowane i możliwe do dostosowania bez programowania.

### Knowledge Agents

Knowledge Agents dostarczają odpowiedzi oparte na kontekście z wiedzy firmowej. Porozumienia zakładowe, regulaminy, układy zbiorowe, reguły compliance, wewnętrzne polityki.

Różnica wobec funkcji wyszukiwania: Knowledge Agent rozumie pytanie, szuka w odpowiednim kontekście i dostarcza odpowiedź ze źródłem i wersją regulaminu. Gdy referent pyta "Czy dodatek za pracę nocną obowiązuje również dla pracowników na pół etatu w regionie zachodnim?", Knowledge Agent dostarcza odpowiedź z odwołaniem do obowiązującego porozumienia zakładowego w aktualnej wersji.

Knowledge Agents wykorzystują RAG (Retrieval Augmented Generation): Wiedza firmowa jest indeksowana w wektorowej bazie danych. Agent wyszukuje odpowiednie fragmenty i generuje odpowiedź na podstawie tych źródeł - nie na podstawie swojego treningu.

Każda odpowiedź zawiera: źródło, wersję regulaminu, datę obowiązywania. Żadnych halucynacji, żadnych zmyślonych odniesień do regulaminów.

## Jak agenci AI współdziałają w architekturze korporacyjnej

Trzy typy agentów nie działają w izolacji. W typowej implementacji korporacyjnej Workflow Agent orkiestruje cały proces i deleguje do wyspecjalizowanych Document i Knowledge Agents.

Przykład z obsługi kadrowej: Wpływa zwolnienie lekarskie (e-mail z załącznikiem PDF). Document Agent odczytuje zwolnienie i wyodrębnia: pracownika, okres, zaświadczenie lekarskie, zaświadczenie kontynuacyjne. Knowledge Agent sprawdza: Jakie reguły obowiązują dla tego pracownika? Układ zbiorowy, porozumienie zakładowe, indywidualne uzgodnienia dodatkowe. Decision Layer ocenia: Czy kontynuacja wynagrodzenia jest prawidłowo obliczona? Czy terminy się zgadzają? Workflow Agent koordynuje cały przebieg i zapewnia aktualizację wszystkich systemów.

Każdy agent ma swój zdefiniowany zakres zadań. Żaden agent nie "decyduje" samodzielnie o krytycznych procesach biznesowych. [Decision Layer](/pl/decision-layer/) znajduje się między agentem a systemem docelowym i zapewnia governance.

## Agnostyczność modelowa: Agent to nie model

Częste nieporozumienie: Agent to nie model językowy. Model (Claude, ChatGPT, Llama) dostarcza rozumienie języka. Agent dostarcza logikę biznesową, integrację systemową, governance.

W architekturze Gosign warstwa modelowa jest wymienna. Gdy pojawia się nowy model - wydajniejszy, tańszy, z lepszą licencją - może zostać zintegrowany bez zmian w warstwach wyższych. Logika biznesowa w Decision Layer, workflow, zestawy reguł pozostają niezmienione.

Agent może też korzystać z wielu modeli: Tańszy model open-source do wstępnej klasyfikacji i wydajniejszy model do złożonych decyzji. Routing między modelami jest konfigurowalny.

Ta agnostyczność modelowa zapobiega uzależnieniu od dostawcy (vendor lock-in). Żadna firma nie jest uzależniona od jednego dostawcy modeli.

## Wymagania dla agentów AI w organizacjach

Agenci AI w środowiskach korporacyjnych wymagają więcej niż modelu językowego:

**Governance:** Każda decyzja agenta musi być przejrzysta i audytowalna. Decision Layer to zapewnia.

**Integracja:** Agenci muszą być zintegrowani z istniejącymi systemami - SAP, [Comarch](https://www.comarch.pl/), [Workday](https://www.workday.com/), [SuccessFactors](https://www.sap.com/products/hcm.html), SharePoint. Integration Layer oddziela logikę agenta od systemu docelowego.

**Infrastruktura:** Agenci wymagają środowiska uruchomieniowego: hosting LLM, wektorowe bazy danych dla RAG, silnik workflow, API Gateway. Ta infrastruktura może działać w chmurze, self-hosted lub hybrydowo.

**Współdziałanie z pracownikami:** W Polsce Rada Zakładowa lub przedstawiciele pracowników mają prawo do informacji i konsultacji przy wdrażaniu systemów AI. Architektura musi to uwzględniać od początku.

Więcej na ten temat: [AI Agents - szczegóły](/pl/uslugi/ai-agents/)

<a href="/pl/kontakt/" target="_blank" rel="noopener noreferrer">Umów spotkanie</a> - Pokażemy, który typ agenta pasuje do Twojego procesu.

--- Eliminacja błędów płacowych u źródła - Decision Layer ---
> Korekty księgowe wynikają z niespójnego stosowania reguł. Decision Layer sprawia, że logika decyzyjna jest jawna, wersjonowana i audytowalna.

## Problem: ukryta logika fachowa

W przetwarzaniu dokumentów księgowych ludzie codziennie podejmują setki mikro-decyzji. Konto, centrum kosztów, początek amortyzacji, naliczony VAT, klasyfikacja wydatków. Każda decyzja opiera się na zestawie regulacji: przepisy podatkowe (PIT, CIT, VAT), standardy rachunkowości, wewnętrzne wytyczne, specyfika poszczególnych podmiotów.

Problem nie polega na braku wiedzy fachowej. Problem to niespójność. Różni pracownicy stosują ten sam zestaw przepisów w różny sposób. Nie dlatego, że są niekompetentni, lecz dlatego, że regulacje są złożone, a ich interpretacja dopuszcza margines swobody.

Więcej podmiotów oznacza więcej wariantów regulacji. Więcej lokalizacji oznacza więcej osób z odmiennymi interpretacjami. Więcej personelu oznacza więcej wdrożeń, więcej wiedzy ukrytej, więcej zmienności.

Konsekwencje są mierzalne: korekty księgowe, ustalenia pokontrolne, pętle uzgadniania, wydłużone zamknięcia miesięczne. Zestawy regulacji często istnieją wyłącznie w głowach poszczególnych pracowników. Gdy ci pracownicy zachorują, idą na urlop lub odchodzą z firmy, wiedza przepada.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">W skrócie - Decision Layer dla Payroll</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Błędy płacowe wynikają z ukrytej wiedzy fachowej - reguły istnieją w głowach, nie w systemach. Gdy pracownicy odchodzą, wiedza znika.</li>
<li>Według Hackett Group (2024) firmy ze jawnymi, wersjonowanymi regułami płacowymi redukują korekty księgowe o 60 do 80% w pierwszym roku.</li>
<li>Decision Layer czyni stosowanie reguł jawnym, wersjonowanym i audytowalnym - każda decyzja księgowa jest identyfikowalna do zdefiniowanej reguły.</li>
<li>Przypadki rutynowe są przetwarzane autonomicznie; wyjątki eskalowane do specjalistów z pełnym kontekstem i wskaźnikiem pewności.</li>
<li>Gotowość audytowa staje się strukturalna: każda ścieżka decyzyjna jest automatycznie udokumentowana od dokumentu źródłowego do zastosowanej reguły.</li>
</ul>
</div>

## Decision Layer dla przetwarzania dokumentów

[Decision Layer](/pl/decision-layer/) rozwiązuje ten problem, czyniąc zestawy reguł jawnymi, wersjonowanymi i czytelnymi maszynowo. Każda decyzja księgowa opiera się na zdefiniowanej regule w określonej wersji. Nie ma marginesu interpretacji.

Przebieg: wpływa dokument. Document Agent odczytuje i rozumie dokument - niezależnie od formatu. Tworzy propozycję księgowania. Decision Layer sprawdza tę propozycję na tle wersjonowanych zestawów reguł:

Czy konto jest prawidłowe? Czy centrum kosztów się zgadza? Czy naliczony VAT jest dopuszczalny przy tym typie faktury? Czy początek amortyzacji jest poprawny? Czy klasyfikacja wydatków jest spójna z wytycznymi danego podmiotu?

Przy wysokiej pewności i jasnej regule: autonomiczne przetwarzanie. Propozycja księgowania trafia do systemu docelowego (SAP FI/CO, Comarch ERP lub inny system). Generowany jest kompletny Audit Trail.

Przy niskiej pewności lub wyjątku: eskalacja do pracownika. Workflow się zatrzymuje. Pracownik widzi propozycję, zastosowaną regułę, wartość pewności i powód eskalacji.

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Darmowy eBook: AI w Finance</p>
<p class="text-body text-gosign-text mb-4">Compliance, biegły rewident i Decision Layer - poradnik governance dla liderów finansów.</p>
<a href="/pl/ebook/ai-finance-poradnik-governance/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Pobierz za darmo</a>
</div>

## Wersjonowane zestawy reguł

Każda zmiana reguły tworzy nową wersję. Stara wersja pozostaje w systemie. Przy kontroli skarbowej lub audycie można prześledzić, jaka reguła w jakiej wersji obowiązywała w momencie podjęcia decyzji.

Przykład: 1 lipca zmienia się stawka VAT dla określonej grupy towarowej. W Decision Layer powstaje nowa wersja reguły, obowiązująca od 1 lipca. Dokumenty sprzed 1 lipca są przetwarzane starą wersją reguły. Dokumenty od 1 lipca nową wersją. Przejście jest automatyczne, przejrzyste i audytowalne.

## Parametryzacja dla poszczególnych podmiotów

Dla biur rachunkowych i kancelarii podatkowych obsługujących setki klientów: zestawy reguł są parametryzowane per podmiot. Ten sam agent stosuje dla każdego klienta prawidłowe reguły w aktualnej wersji.

Klient A stosuje Pełny Plan Kont, klient B stosuje Uproszczony Plan Kont. Klient C ma indywidualny plan kont. Decision Layer zapewnia, że agent dla każdego klienta stosuje właściwe reguły - spójnie, niezależnie od tego, który pracownik prowadzi sprawę.

## Przygotowanie do audytu

Przy kontroli skarbowej lub badaniu sprawozdania finansowego biegły rewident może w Auditor Portal prześledzić każdą pojedynczą decyzję księgową. Podstawą jest akt decyzyjny na każde księgowanie - niezmienny dowód z inputem/dokumentem źródłowym, zastosowaną regułą merytoryczną wraz z wersją, pewnością, wynikiem, znacznikiem czasu i ścieżką podważenia. Od dokumentu źródłowego po zastosowaną regułę z wersją, od wartości pewności po routing (autonomiczny lub eskalowany).

To znacząco redukuje pracochłonność audytu. Zamiast pobierać ręczne próbki i dla każdego przypadku rekonstruować logikę księgowania, audytor widzi kompletną ścieżkę decyzyjną automatycznie udokumentowaną.

<div class="overflow-x-auto">

| Aspekt | Bez Decision Layer | Z Decision Layer |
|--------|-------------------|-----------------|
| Stosowanie reguł | Ukryte, zależne od osoby | Jawne, wersjonowane |
| Spójność między lokalizacjami | Zmienna | Identyczna |
| Korekty księgowe | 3 - 8% wszystkich księgowań | < 1% |
| Przygotowanie do audytu | Ręczna rekonstrukcja | Automatyczna dokumentacja |
| Transfer wiedzy | Miesiące wdrożenia | Zestawy reguł są samodokumentujące |
| Dowód compliance | Na podstawie próbek | Pełna ścieżka decyzyjna |

</div>

Więcej: [Finance AI Agents](/pl/uslugi/ai-agents/)

→ [Akt decyzyjny: dlaczego każda decyzja AI musi być podważalna](/pl/magazyn/akt-decyzyjny-podwazalne-decyzje-ai/)

<a href="/pl/kontakt/" target="_blank" rel="noopener noreferrer">Umów spotkanie</a> - Pokażemy Ci, jak Decision Layer wygląda dla Twojego procesu przetwarzania dokumentów.

--- Decision Layer i Shadow AI: kontrola zamiast chaosu ---
> Jak Decision Layer oddziela analizę od decyzji - i dlaczego to rozwiązuje Shadow AI, przekonuje Radę Zakładową i umożliwia skalowanie.

## Dwa problemy. Jedna architektura.

Shadow AI i brak governance to dwie największe przeszkody w skalowaniu AI w przedsiębiorstwach w 2026 roku. Pierwszy problem: pracownicy korzystają z publicznych narzędzi AI bez kontroli, bo firma nie oferuje alternatywy. Drugi problem: nawet gdy firma udostępnia AI, brakuje architektury oddzielającej analizę od decyzji.

Decision Layer rozwiązuje oba problemy. Jest warstwą governance definiującą, kto co może decydować: człowiek, zestaw reguł czy AI. Jednocześnie stanowi fundament do zaoferowania pracownikom kontrolowanego narzędzia AI, które jest lepsze od publicznych alternatyw.

Ten artykuł opisuje, dlaczego Shadow AI jest ryzykiem numer jeden, jak działa Decision Layer, jaką rolę odgrywa klasyfikacja danych i dlaczego bez tej architektury ani Rada Zakładowa, ani audytorzy, ani zarząd nie zgodzi się na skalowanie AI.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">W skrócie - Shadow AI i Decision Layer</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Shadow AI - niekontrolowane korzystanie z publicznych narzędzi AI przez pracowników - to Shadow IT roku 2026: wyciek danych, ryzyko RODO, brak przejrzystości.</li>
<li>Zakazy AI nie działają w praktyce. Rozwiązaniem jest zarządzany wewnętrzny portal AI, który przewyższa publiczne alternatywy funkcjonalnością i bezpieczeństwem.</li>
<li>Decision Layer oddziela analizę od decyzji: AI może analizować, ale kto działa, jest zdefiniowane na poziomie mikro-decyzji (człowiek, reguły lub AI).</li>
<li>Czterostopniowy schemat klasyfikacji danych steruje routingiem modeli - dane poufne nigdy nie trafią do publicznego modelu.</li>
<li>Bez architektury governance-first ani Rada Zakładowa, ani audytorzy, ani zarząd nie zaakceptują skalowania AI.</li>
</ul>
</div>

## Shadow AI: niedoceniane ryzyko

Shadow AI to Shadow IT roku 2026. Termin opisuje niekontrolowane korzystanie z publicznych usług AI przez pracowników - bez wiedzy działu IT, bez governance, bez Audit Trail.

Rzeczywistość w większości firm: pracownicy używają publicznych narzędzi AI do codziennej pracy. Redagują e-maile, streszczają raporty, analizują umowy, tworzą prezentacje. Nie ze złej woli, lecz dlatego, że te narzędzia czynią ich bardziej produktywnymi. I dlatego, że firma nie oferuje równorzędnej alternatywy.

Problemem nie jest samo korzystanie. Problemem jest to, co przy tym zachodzi:

**Wyciek danych.** Każde zapytanie w publicznym narzędziu AI opuszcza sieć firmową. Treści umów, dane finansowe, informacje personalne, plany strategiczne. Wszystko, co trafia do prompta, jest poza Twoją kontrolą.

**Brak przejrzystości.** Który pracownik przekazał jakie dane jakiemu narzędziu? Nikt nie wie. Nie ma Audit Trail, nie ma logowania, nie ma możliwości retrospektywnej weryfikacji.

**Brak kontroli jakości.** Wyniki publicznych narzędzi AI wpływają na decyzje biznesowe, ale nie wiadomo, na jakiej podstawie powstały. Projekt umowy częściowo stworzony przez AI. Kto weryfikuje klauzule?

**Ryzyko RODO.** Dane osobowe przesyłane do publicznych usług AI mogą stanowić incydent ochrony danych podlegający zgłoszeniu. Nie teoretycznie, lecz według aktualnej wykładni prawa.

Rozwiązaniem nie jest zakaz. Zakazy w praktyce nie działają. Są obchodzone, ignorowane lub podważane. Rozwiązaniem jest lepsza oferta: wewnętrzny portal AI, który funkcjonalnie jest co najmniej równoważny, ale wyposażony w governance, ochronę danych i Audit Trail. Jak taki portal wygląda, opisuje artykuł [Enterprise-AI-Portal: więcej niż tylko chat](/pl/magazyn/enterprise-ai-chat-interface/).

## Decision Layer: analiza to nie decyzja

Decision Layer to zasada architektoniczna oddzielająca analizę od decyzji. Model AI może analizować: podsumowywać dane, rozpoznawać wzorce, obliczać prawdopodobieństwa, formułować rekomendacje. Ale decyzja, czy i jak zareagować na tę analizę, to oddzielne pytanie. Na to pytanie odpowiada Decision Layer.

Zasada: każdy proces biznesowy jest rozkładany na mikro-decyzje. Dla każdej pojedynczej mikro-decyzji z góry definiuje się, kto decyduje:

```
Przychodzace zdarzenie
|
+----------+
| Decision  |
|  Layer    |
+----------+
+----+------------+
v    v            v
REGULA  AI        CZLOWIEK
```

**REGUŁA:** Decyzje deterministyczne, które zawsze dają ten sam wynik. Sprawdzanie terminów, stosowanie układów zbiorowych, logika księgowania, progi wartości. Zestaw reguł jest wersjonowany. Każda zmiana generuje nową wersję, poprzednia pozostaje przejrzysta.

**AI:** Decyzje, w których model może działać autonomicznie w zdefiniowanych granicach. Standardowe klasyfikacje, rutynowa komunikacja z zatwierdzonych szablonów, jednoznaczne przypisania. Tylko przy wysokiej pewności i niskim ryzyku.

**CZŁOWIEK:** Decyzje uznaniowe, wyjątki, przypadki z potencjałem dyskryminacji, decyzje powyżej zdefiniowanych progów wartości, wszystkie przypadki wymagające konsultacji z Radą Zakładową.

Cztery zasady czynią Decision Layer skutecznym:

**Jawne, wersjonowane reguły.** Każda reguła decyzyjna ma identyfikator, wersję, datę ważności i zakres obowiązywania. Gdy zmienia się porozumienie zakładowe, powstaje nowa wersja reguły. Przy audycie jest jasne, jaka reguła obowiązywała w momencie decyzji.

**Architektonicznie wymuszony Human-in-the-Loop.** Przy zdefiniowanych typach decyzji system nie może kontynuować bez ludzkiego zatwierdzenia. To jest wymuszone technicznie, nie uzgodnione organizacyjnie. Agent nie może ominąć tej weryfikacji, bo architektura na to nie pozwala, nie dlatego że polityka tego zabrania.

**Audit Trail na mikrodecyzję - akt decyzyjny.** Każda pojedyncza mikrodecyzja generuje niezmienny akt decyzyjny: input, zastosowana reguła merytoryczna wraz z wersją, wartość pewności, wersja modelu, decyzja routingowa, wynik, znacznik czasu i ścieżka podważenia. To nie retrospektywna dokumentacja. To techniczny zapis procesu decyzyjnego - dzięki któremu da się spełnić wyjaśnienie pojedynczej decyzji wg art. 86 EU AI Act.

**Porozumienia zakładowe jako ograniczenia systemowe.** Wymogi Rady Zakładowej są implementowane nie jako wytyczne organizacyjne, lecz jako reguły techniczne w Decision Layer. System nie może ominąć porozumienia zakładowego, bo jest ono częścią logiki systemu. Rada Zakładowa może prześledzić każdą decyzję w Audit Trail.

## Klasyfikacja danych jako fundament

Zanim Decision Layer może zacząć działać, trzeba odpowiedzieć na fundamentalne pytanie: Jakie dane mogą być przetwarzane przez jaki model AI? Odpowiedź daje czterostopniowy schemat klasyfikacji:

| Poziom | Oznaczenie | Przykłady | Dozwolone przetwarzanie AI |
|---|---|---|---|
| 1 | Publiczne | Komunikaty prasowe, treści stron www | Wszystkie modele, włącznie z publicznymi API |
| 2 | Wewnętrzne | Prezentacje, dokumenty procesowe, wewnętrzne wytyczne | Chmura EU lub modele self-hosted |
| 3 | Poufne | Dane HR, dane finansowe, umowy, dane klientów | Tylko self-hosted lub z anonimizacją PII |
| 4 | Ściśle poufne | Dokumenty M&A, patenty, komunikacja zarządu | Tylko On-Premises, żadnego modelu chmurowego |

Klasyfikacja automatycznie określa routing modelu. Gdy pracownik zadaje pytanie dotyczące umowy (poziom 3), system automatycznie kieruje zapytanie do modelu self-hosted lub anonimizuje dane przed przekazaniem. Model publiczny dla danych poziomu 3 nie wchodzi w grę. Architektura zapewnia, że jest to technicznie niemożliwe, a nie tylko organizacyjnie zabronione.

Klasyfikacja danych nie jest jednorazowym zadaniem. Musi być zintegrowana z istniejącymi procesami: każdy nowy dokument, każde nowe źródło danych, każdy nowy proces otrzymuje klasyfikację. Idealnie odbywa się to automatycznie, na podstawie typu dokumentu, rozpoznawania treści i przynależności organizacyjnej.

Bez klasyfikacji danych brakuje fundamentu dla każdego kolejnego środka governance. To pierwsza decyzja, którą należy podjąć - jeszcze przed wyborem modelu, jeszcze przed budową [infrastruktury](/pl/uslugi/infrastruktura/).

## Pięć filarów AI Governance

Klasyfikacja danych to fundament. Na nim opiera się pięć filarów tworzących kompletne AI Governance:

**1. Kontrola dostępu.** Kto może używać jakich funkcji AI? Jakie asystenty, jakie bazy wiedzy, jacy agenci są dostępni dla jakich ról? Kontrola dostępu odwzorowuje istniejącą strukturę organizacyjną: HR widzi asystentów HR, Finanse widzą asystentów Finansów. Integracja SSO zapewnia, że nie trzeba zarządzać oddzielnymi kontami.

**2. Audyt i logowanie.** Każda interakcja z systemem AI jest protokołowana. Nie w celu monitorowania pracowników, lecz w celu przejrzystości decyzji biznesowych. Kto kiedy zadał jakie pytanie? Jaki model odpowiedział? Na podstawie jakich źródeł? Audit Trail to fundament audytu wewnętrznego, rewizji finansowej i dowodów compliance. [Referencyjna architektura governance](/pl/governance/reference-architecture/) opisuje implementację techniczną w szczegółach.

**3. Human Oversight.** Architektura definiuje, gdzie wymagana jest ludzka weryfikacja. To nie generalne wymaganie. To zróżnicowana decyzja na poziomie każdej mikro-decyzji. Rutynowe klasyfikacje nie potrzebują ludzkiego sprawdzającego. Decyzje personalne z potencjałem dyskryminacji - zawsze. Granularność tego rozróżnienia odróżnia skuteczne governance od biurokratycznego.

**4. Zapewnienie jakości.** Wyniki AI muszą być weryfikowane - nie każdy pojedynczy, ale systematycznie. Próbki losowe, feedback użytkowników, automatyczna ewaluacja. Czy model halucynuje? Czy odwołania do źródeł są poprawne? Czy zastosowanie reguł jest prawidłowe? Zapewnienie jakości to ciągły proces, nie jednorazowy test.

**5. Compliance i raportowanie.** [EU AI Act](/pl/magazyn/eu-ai-act-2026-przedsiebiorstwa/) wymaga - zgodnie z obowiązującym prawem od 2 sierpnia 2026 r., z wstępnie uzgodnionym przesunięciem na 2 grudnia 2027 r. (Digital Omnibus, maj 2026, przyjęcie w toku) - dokumentacji technicznej, klasyfikacji ryzyka i Conformity Assessment dla systemów AI wysokiego ryzyka. AI Governance musi uwzględniać te wymagania od początku, nie dokładać ich później. Regularne raporty dotyczące użytkowania, wydajności modeli, jakości decyzji i statusu compliance stanowią podstawę zarządzania przez kierownictwo.

## Dlaczego Decision Layer jest kluczem do skalowania

Przedsiębiorstwa, które chcą skalować AI - od jednego projektu pilotażowego do dziesięciu agentów produkcyjnych, z jednego działu na całą organizację - bez Decision Layer natrafiają na twardą granicę. Nie techniczną, lecz organizacyjną.

**Rada Zakładowa wyda negatywną opinię.** W wielu krajach UE organy przedstawicielskie pracowników mają prawa informacyjne i konsultacyjne przy wdrażaniu systemów AI monitorujących lub podejmujących decyzje dotyczące pracowników. W Polsce Rada Zakładowa nie ma prawa weta wobec wdrożeń technologicznych, ale pracodawca ma obowiązek konsultacji. Bez przejrzystej logiki decyzyjnej, bez udokumentowanego Human-in-the-Loop, bez porozumień zakładowych jako ograniczeń systemowych konsultacja z Radą Zakładową nie przyniesie pozytywnego wyniku. Decision Layer dostarcza dokładnie tę przejrzystość i sterowalność, której Rada wymaga.

**Audyt wewnętrzny nie da zielonego światła.** Audytorzy i rewizja wewnętrzna potrzebują przejrzystości. Gdy agent AI generuje księgowania, ocenia umowy lub przygotowuje decyzje personalne, ścieżka decyzyjna musi być audytowalna. Bez Audit Trail każda decyzja agenta to ryzyko audytowe. Decision Layer automatycznie generuje dowody, których potrzebują audytorzy.

**Zarząd nie przyzna budżetu.** Projekty pilotażowe finansuje się z budżetów innowacyjnych. Skalowanie wymaga budżetów inwestycyjnych, a te wymagają business case z rzetelnymi liczbami. Decision Layer dostarcza dane: czasy przebiegu, wskaźniki błędów, koszty na zdarzenie, wskaźniki eskalacji. Bez tych danych AI pozostaje pozycją kosztową bez wymiernego zwrotu.

Kolejność jest nienegocjowalna: najpierw governance, potem skalowanie. Nie odwrotnie.

## Cookieless i Privacy by Design

Enterprise-AI-Portal powinien chronić nie tylko dane zapytań użytkowników, ale także samo korzystanie. Oznacza to: żadnego śledzenia, żadnych ciasteczek analitycznych, żadnej analizy zachowań.

**SSO zamiast oddzielnych kont.** Pracownicy uwierzytelniają się przez istniejące zarządzanie tożsamością w firmie. Żadnych oddzielnych haseł, żadnych oddzielnych profili użytkowników u zewnętrznego dostawcy.

**Brak ciasteczek śledzących.** Wewnętrzny portal AI nie używa ciasteczek do analizy zachowań. Dane użytkowania są zbierane wyłącznie na potrzeby Audit Trail - nie do marketingu, nie do optymalizacji produktu przez osoby trzecie, nie do profilowania.

**Dane użytkowania tylko do audytu.** To, który pracownik zadał jakie zapytanie, jest protokołowane, ale wyłącznie do celów governance: przejrzystość, compliance, zapewnienie jakości. Dostęp do tych danych jest ograniczony do uprawnionych ról (bezpieczeństwo IT, Inspektor Ochrony Danych (IOD), rewizja). Przełożony nie widzi indywidualnych zapytań swoich pracowników.

**Privacy by Design.** Wymagania ochrony danych są wbudowane w architekturę, nie dodane później. Anonimizacja PII, klasyfikacja danych, routing modeli - wszystkie te mechanizmy działają automatycznie, na podstawie klasyfikacji danych, nie na podstawie dyscypliny użytkowników.

To podejście przekonuje nie tylko Inspektora Ochrony Danych, ale także Radę Zakładową: system nie monitoruje pracowników. Dokumentuje decyzje biznesowe.

---

[Decision Layer](/pl/decision-layer/) to centralny komponent governance Gosign. Niezależny od modelu, zgodny z wymogami Rady Zakładowej, z kompletnym Audit Trail i jednym aktem decyzyjnym na każdą mikrodecyzję - podważalnym wg [art. 86 EU AI Act](/pl/magazyn/akt-decyzyjny-podwazalne-decyzje-ai/). Więcej o [architekturze governance](/pl/governance/).

<a href="/pl/kontakt/" target="_blank" rel="noopener noreferrer">Umów spotkanie</a>. 30 minut, w których wyjaśnimy, jak Decision Layer wygląda dla Twoich procesów i jak Shadow AI w Twojej firmie może być kontrolowanie zaadresowane.

--- Decision Layer vs. SAP Joule vs. Microsoft Copilot ---
> SAP Joule i Microsoft Copilot to agenci AI. Decision Layer to warstwa governance nad nimi. Dlaczego firmy w UE potrzebują obu rozwiązań.

## Zamęt informacyjny

Decydenci w firmach słyszą o SAP Joule, Microsoft Copilot, Google Gemini, wewnętrznych wdrożeniach GPT i zadają sobie pytanie: Co z tego potrzebuję i gdzie w tym obrazie mieści się Decision Layer?

Odpowiedź jest prostsza niż się wydaje: Joule, Copilot i inne to agenci AI - wykonują zadania. [Decision Layer](/pl/decision-layer/) nie jest alternatywą dla tych agentów. To warstwa governance, która znajduje się nad nimi i steruje tym, co ci agenci mogą robić.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">W skrócie - Decision Layer vs. agenci enterprise</p>
<ul class="text-body text-gosign-text space-y-2">
<li>SAP Joule i Microsoft Copilot to agenci AI wykonujący zadania. Decision Layer to warstwa governance nad nimi, sterująca tym, co mogą robić.</li>
<li>Ani Joule, ani Copilot nie oferują wbudowanych mechanizmów dla porozumień zakładowych, zgodności z AI Act czy audytowalnych ścieżek decyzyjnych.</li>
<li>Decision Layer jest niezależny od modelu i agenta - współpracuje z każdym agentem, również modelami open source.</li>
<li>Firmy w regulowanych środowiskach potrzebują obu: agenta do wykonania i Decision Layer do governance.</li>
<li>Agenci są wymienni. Governance to infrastruktura.</li>
</ul>
</div>

## Agent vs. warstwa governance

Agent AI potrafi wykonać zadanie: podsumować dokument, utworzyć propozycję księgowania, odpowiedzieć na pytanie dotyczące polityki firmy. Czego agent nie potrafi: zdecydować, czy może to zadanie wykonać autonomicznie, czy musi interweniować człowiek.

SAP Joule może w SuccessFactors zaproponować korektę wynagrodzenia. Ale Joule nie decyduje, czy ta propozycja może automatycznie trafić do systemu, czy wymaga konsultacji z Radą Zakładową. Joule nie zna porozumień zakładowych. A audit logging Joule'a rejestruje działania i cytaty źródeł - ale nie akt decyzyjny na poziomie reguł merytorycznych, który utrwala, która klauzula układu zbiorowego pracy w której wersji stanowiła podstawę decyzji.

Microsoft Copilot może utworzyć dokument onboardingowy. Ale Copilot nie decyduje, jakie zaszeregowanie przewiduje układ zbiorowy pracy, czy konieczna jest konsultacja z Radą Zakładową, ani czy spełnione są wymogi RODO właściwe dla danej lokalizacji.

Decision Layer przejmuje dokładnie to sterowanie.

## Jak Decision Layer i agenci enterprise współpracują

Decision Layer rozkłada każdy proces biznesowy na pojedyncze kroki decyzyjne i definiuje z góry dla każdego z nich: Czy decyduje człowiek, zestaw reguł, czy AI samodzielnie? Tam, gdzie w grę wchodzi swoboda oceny, architektura wymusza weryfikację przez człowieka. Tam, gdzie decyzja jest deterministyczna, agent stosuje zestaw reguł konsekwentnie. A tam, gdzie agent jest wystarczająco pewny: decyduje samodzielnie - interpretuje, klasyfikuje, ocenia kontekst. To nie jest if-then-else - to zdolność oceny w ramach zdefiniowanych ram. Gdy SAP Joule tworzy propozycję księgowania, ta propozycja przechodzi przez Decision Layer zanim stanie się skuteczna w systemie docelowym.

Decision Layer sprawdza: Czy propozycja jest spójna z wersjonowanymi zestawami reguł? Czy pewność przekracza próg? Czy decyzja dotyczy obszaru wymagającego konsultacji z radą pracowników? Czy wymagany jest Human-in-the-Loop?

Jeśli wszystko się zgadza: propozycja trafia do systemu docelowego. Audit Trail dokumentuje decyzję.

Jeśli nie: workflow się zatrzymuje. Człowiek otrzymuje propozycję, zastosowaną regułę, wartość pewności i powód eskalacji. Podejmuje decyzję. Również jego decyzja jest dokumentowana.

## Dlaczego firmy w Polsce i UE potrzebują obu rozwiązań

SAP Joule i Microsoft Copilot są coraz szerzej wdrażane w polskich i europejskich firmach. Ale wdrożenie napotyka trzy bariery, których sam agent nie rozwiąże:

Po pierwsze: Rady Zakładowe i przedstawiciele pracowników wymagają przejrzystości i konsultacji przy decyzjach AI. Ani Joule, ani Copilot nie oferują wbudowanych mechanizmów dla porozumień zakładowych jako ograniczeń technicznych. W Polsce, gdzie Ustawa o radach pracowników reguluje prawa do informacji i konsultacji, jest to szczególnie istotne.

Po drugie: AI Act wymaga - zgodnie z obowiązującym prawem od 2 sierpnia 2026 r., z wstępnie uzgodnionym przesunięciem na 2 grudnia 2027 r. (Digital Omnibus, maj 2026, przyjęcie w toku) - udokumentowanego governance dla systemów AI wysokiego ryzyka - a procesy HR należą do tej kategorii. Obowiązki obejmują analizę ryzyka, dokumentację, przejrzystość i nadzór ludzki - a wraz z art. 86 prawo osób, których decyzja dotyczy, do wyjaśnienia pojedynczej decyzji, na które da się odpowiedzieć wyłącznie aktem decyzyjnym na każdą mikrodecyzję. Sami agenci enterprise tego nie zapewniają. Dla polskich firm działających na rynku UE to wymóg bezwzględny.

Po trzecie: biegli rewidenci i audyt wewnętrzny potrzebują przejrzystych ścieżek decyzyjnych. Agent, który "składa propozycję" bez udokumentowanej ścieżki decyzyjnej, stanowi ryzyko audytowe w świetle krajowych standardów rewizji finansowej.

Decision Layer uzupełnia SAP Joule i Microsoft Copilot o dokładnie te trzy wymiary: gotowość na konsultację z radą pracowników, zgodność z AI Act i gotowość audytową.

## Rozgraniczenie na pierwszy rzut oka

| Zdolność | SAP Joule | Microsoft Copilot | Decision Layer |
|---|---|---|---|
| Wykonywanie zadań | Tak | Tak | Nie (tylko governance) |
| Porozumienia zakładowe jako ograniczenia techniczne | Nie | Nie | Tak |
| Dokumentacja zgodności z AI Act | Nie | Nie | Tak |
| Audytowalna ścieżka decyzyjna | Nie | Nie | Tak |
| Akt decyzyjny na mikrodecyzję (reguła merytoryczna + wersja) | Nie | Nie | Tak |
| Confidence Routing z eskalacją | Nie | Nie | Tak |
| Human-in-the-Loop (wymuszony architektonicznie) | Nie | Nie | Tak |
| Niezależność od modelu | Nie (ekosystem SAP) | Nie (ekosystem Microsoft) | Tak |

SAP Joule to agent w ekosystemie SAP. Microsoft Copilot to agent w ekosystemie Microsoft. Decision Layer to niezależna od modelu i agenta warstwa governance, która znajduje się nad oboma.

Agenci są wymienni. Governance to infrastruktura.

> [Decision Layer w szczegółach](/pl/magazyn/decision-layer-wyjasnienie/)

> [Akt decyzyjny: dlaczego każda decyzja AI musi być podważalna](/pl/magazyn/akt-decyzyjny-podwazalne-decyzje-ai/)

> [Architektura referencyjna](/pl/governance/reference-architecture/)

<a href="/pl/kontakt/" target="_blank" rel="noopener noreferrer">Umów spotkanie</a> - Pokażemy Ci, jak Decision Layer działa w Twojej istniejącej infrastrukturze systemowej.

--- Decision Layer: governance dla agentów AI ---
> Decision Layer to komponent governance między agentem AI a systemem docelowym. Rules Engine, Confidence Routing, Human-in-the-Loop, Audit Trail.

## Problem: decyzje AI bez przejrzystości

Gdy agent AI księguje fakturę, przetwarza zwolnienie lekarskie lub odpowiada na pytanie dotyczące compliance, podejmuje decyzję. Ta decyzja opiera się na modelu językowym, który działa na zasadzie prawdopodobieństwa - nie na deterministycznych regułach.

Dla wewnętrznego chatbota to akceptowalne. Dla procesów krytycznych biznesowo - nie. Gdy agent proponuje księgowanie, musi być jasne: Jaka reguła została zastosowana? W jakiej wersji? Z jaką pewnością? Czy uczestniczył w tym człowiek?

Bez tej przejrzystości decyzje AI w regulowanych środowiskach nie nadają się do wdrożenia. Biegli rewidenci nie mogą ich zweryfikować. Rady Zakładowe nie mogą ich ocenić. Audytorzy wewnętrzni nie mogą ich prześledzić.

Decision Layer rozwiązuje ten problem.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">W skrócie - Decision Layer</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Decision Layer to komponent governance między agentem AI a systemem docelowym - każda decyzja agenta przechodzi przez niego, zanim stanie się skuteczna.</li>
<li>Rozkłada procesy na mikro-decyzje i dla każdej definiuje: decyduje człowiek, stosowany jest zestaw reguł lub AI decyduje autonomicznie.</li>
<li>Cztery komponenty - Rules Engine, Confidence Routing, Human-in-the-Loop, Audit Trail - zapewniają przejrzystość, compliance i gotowość audytową.</li>
<li>W decyzjach regułowych i powtarzalnych AI udowodnialnie przewyższa człowieka w spójności, odporności na zmęczenie i kompletności.</li>
<li>Bez Decision Layer agenci AI w przedsiębiorstwach nie przejdą audytu, nie spełnią wymogów Rady Zakładowej i nie wyjdą poza projekty pilotażowe.</li>
</ul>
</div>

[Gartner (2026)](https://www.gartner.com/en/newsroom/press-releases/2026-05-26-gartner-says-applying-uniform-governance-across-ai-agents-will-lead-to-enterprise-ai-agent-failure) prognozuje, że do 2027 roku 40 procent organizacji zdegraduje lub wycofa z użycia autonomicznych agentów AI z powodu luk w governance.

## Czym jest Decision Layer?

Decision Layer to centralny komponent governance między agentem AI a systemem docelowym. Architektonicznie znajduje się między agentem, który formułuje rekomendację, a systemem, w którym decyzja staje się skuteczna - na przykład SAP, [Comarch](https://www.comarch.pl/) lub [Workday](https://www.workday.com/).

Decision Layer nie jest dodatkowym modułem compliance. To zasada architektoniczna. Każda decyzja agenta przechodzi przez Decision Layer, zanim dotrze do systemu docelowego.

## Decision Layer - wyjaśnienie dla osób odpowiedzialnych za procesy

Powyższy opis techniczny jest precyzyjny. Ale w codziennej praktyce istnieje prostsze wyjaśnienie:

Decision Layer działa jak standardowy opis procesu z jasnymi poziomami decyzyjnymi - z tą różnicą, że jest egzekwowany technicznie, a nie tylko na papierze.

Konkretnie: Każdy proces biznesowy, który ma wykonywać agent AI, jest rozkładany na poszczególne mikro-decyzje. Dla każdej pojedynczej decyzji z góry definiują ludzie, nie AI:

Czy tutaj musi zdecydować człowiek? Na przykład dlatego, że wymaga tego obowiązek konsultacji z Radą Zakładową, istnieje ryzyko dyskryminacji lub chodzi o decyzję uznaniową.

Czy to reguła stosowana zawsze tak samo? Na przykład sprawdzenie terminu, układ zbiorowy pracy, logika księgowania. Wtedy agent stosuje regułę konsekwentnie - w każdym oddziale, przy każdym pracowniku, o każdej porze. Zestawy reguł są wersjonowane: każda zmiana tworzy nową wersję, poprzednie pozostają identyfikowalne. Agent jest tu wykonawcą - nie dlatego, że nie potrafi więcej, ale dlatego, że nie ma czego interpretować.

Czy AI może tu zdecydować samodzielnie? Na przykład agent interpretuje dokumenty, klasyfikuje sytuacje, ocenia kontekst i rozpoznaje wzorce. To nie jest if-then-else - to zdolność oceny w ramach zdefiniowanych ram. Confidence Routing steruje: wysoka pewność i niskie ryzyko oznacza decyzję autonomiczną; niska pewność lub wysokie ryzyko oznacza eskalację do człowieka. Ten mechanizm odróżnia Decision Layer od RPA.

Każdy z tych kroków jest dokumentowany: Kto zdecydował, na jakiej podstawie, z jakim wynikiem. To jest Audit Trail - dowód, którego potrzebują biegli rewidenci, Rada Zakładowa i audyt wewnętrzny.

Efekt: procesy stają się szybsze i bardziej spójne, bez utraty kontroli. A gdy ktoś pyta "Jak została podjęta ta decyzja?" - jest odpowiedź.

<table class="w-full text-left text-sm">
<thead><tr class="border-b border-gosign-border">
<th class="py-2 pr-4 font-semibold">Typ decyzji</th>
<th class="py-2 pr-4 font-semibold">Szybkość</th>
<th class="py-2 pr-4 font-semibold">Audytowalność</th>
<th class="py-2 pr-4 font-semibold">Poziom ryzyka</th>
<th class="py-2 pr-4 font-semibold">Przykład</th>
</tr></thead>
<tbody>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Decyzja człowieka</td><td class="py-2 pr-4">Niska (minuty do dni)</td><td class="py-2 pr-4">Wysoka (udokumentowana weryfikacja)</td><td class="py-2 pr-4">Niski (ludzka ocena)</td><td class="py-2 pr-4">Planowanie reintegracji</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Oparta na regułach</td><td class="py-2 pr-4">Wysoka (natychmiast)</td><td class="py-2 pr-4">Wysoka (wersjonowane reguły)</td><td class="py-2 pr-4">Niski (deterministyczna)</td><td class="py-2 pr-4">Klasyfikacja zaszeregowania</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">AI autonomiczna</td><td class="py-2 pr-4">Wysoka (natychmiast)</td><td class="py-2 pr-4">Wysoka (Audit Trail)</td><td class="py-2 pr-4">Średni (Confidence Routing)</td><td class="py-2 pr-4">Klasyfikacja dokumentów</td></tr>
</tbody>
</table>

Techniczna realizacja tej logiki składa się z czterech komponentów:

### Cztery komponenty

**1. Rules Engine**

Fachowe zestawy reguł, wersjonowane i przejrzyste. Układy zbiorowe pracy, porozumienia zakładowe, logika księgowania, przepisy podatkowe, reguły compliance. Każda reguła ma wersję, datę ważności i zakres obowiązywania.

Gdy reguła się zmienia - na przykład nowy układ zbiorowy lub zmieniona polityka księgowa - powstaje nowa wersja reguły. Stara wersja pozostaje w systemie. Przy audycie jest jasne, jaka reguła w jakiej wersji obowiązywała w momencie decyzji.

**2. Confidence Routing**

Nie każda decyzja agenta ma taką samą pewność. Decision Layer automatycznie ocenia każdą decyzję:

- Wysoka pewność + niskie ryzyko = autonomiczne przetwarzanie. Agent decyduje, wynik trafia do systemu docelowego.
- Niska pewność lub wysokie ryzyko = eskalacja do człowieka. Workflow się zatrzymuje, pracownik sprawdza i decyduje.
- Przypadek wyjątkowy lub nieznany wzorzec = blokada. Brak wyniku, wymagane wyjaśnienie przez człowieka.

Progi pewności i ryzyka są konfigurowalne i dostosowane do klienta. Firma audytorska ustawi inne progi niż wewnętrzne centrum usług wspólnych.

**3. Human-in-the-Loop**

Human-in-the-Loop w Decision Layer to zasada architektoniczna, a nie opcjonalny checkbox. Przy zdefiniowanych typach decyzji architektura wymusza ludzką weryfikację:

- Decyzje z potencjałem dyskryminacji
- Decyzje dotyczące kwestii wymagających konsultacji z Radą Zakładową
- Decyzje powyżej zdefiniowanych progów wartości
- Pierwsze zastosowanie nowej reguły

Wymóg Human-in-the-Loop jest egzekwowany technicznie, nie organizacyjnie. Agent nie może ominąć tej weryfikacji.

**4. Audit Trail - akt decyzyjny**

Każda decyzja generuje kompletny, niezmienny akt decyzyjny:

- Input: Co zostało przekazane agentowi?
- Model: Jaki model językowy w jakiej wersji został użyty (np. `claude-opus-4-7-2026-04-12`, `gpt-5.5-2026-03-pro`, `mistral-medium-3.1-eu`, `deepseek-v4-pro-on-prem`)?
- Zestaw reguł: Jaka reguła w jakiej wersji została zastosowana?
- Pewność: Jak pewny był agent?
- Routing: Czy zdecydowano autonomicznie czy eskalowano?
- Wynik: Jaka była decyzja?
- Znacznik czasu: Kiedy podjęto decyzję?
- Ścieżka podważenia: Kto może podważyć tę decyzję - osoba, której dotyczy, Rada Zakładowa, biegły rewident?

Ten akt decyzyjny jest tym, co audytorzy widzą w Auditor Portal. Nie retrospektywna dokumentacja, lecz techniczny dowód procesu decyzyjnego. A zarazem architektoniczna odpowiedź na art. 86 EU AI Act - prawo osób, których decyzja dotyczy, do wyjaśnienia pojedynczej decyzji.

## Jak Decision Layer działa w praktyce

Konkretny przykład z przetwarzania dokumentów:

Wpływa dokument - faktura zakupowa. Document Agent odczytuje dokument, wyodrębnia istotne informacje: wystawca, kwota, opis usługi, data.

Agent tworzy propozycję księgowania: konto, centrum kosztów, naliczony VAT, początek amortyzacji. Ta propozycja trafia do Decision Layer.

Decision Layer sprawdza: Czy propozycja księgowania jest spójna z wersjonowanymi zestawami reguł? Czy centrum kosztów się zgadza? Czy naliczony VAT jest poprawny dla tego typu faktury? Czy kwota mieści się w granicach autonomicznego przetwarzania?

Jeśli tak: propozycja księgowania trafia do systemu docelowego (SAP lub inny system ERP). Kompletna ścieżka decyzyjna jest zapisywana w Audit Trail.

Jeśli nie: zapytanie do pracownika. Workflow się zatrzymuje. Pracownik widzi propozycję, zastosowaną regułę, wartość pewności i powód eskalacji. Decyduje. Również ta ludzka decyzja jest dokumentowana w Audit Trail.

## Jakie modele Decision Layer obecnie routuje

Decision Layer jest model-agnostyczny - każda mikro-decyzja kierowana jest przez warstwę routingu do modelu najlepiej dopasowanego pod kątem merytorycznym i kosztowym. Stan na maj 2026 - w produkcji routuje między innymi na:

- **Claude Opus 4.7** i **Claude Sonnet 4.6** (Anthropic, Cloud API) - dla jakości uzasadnień przy eskalacjach compliance, długich aktach sprawy i syntezie Decision Record
- **GPT-5.5** (OpenAI, Cloud API lub Azure OpenAI z rezydencją danych w UE) - dla ekstrakcji strukturalnej i tool use
- **Gemini 3.1 Pro** (Google, Cloud API) - dla multimodalnego przetwarzania dokumentów (PDF + skan + tabela)
- **Mistral Small 3.2** (Apache 2.0, self-host lub La Plateforme) - dla klasyfikacji wysokowolumenowej i wrażliwej kosztowo
- **Mistral Medium 3.1** (La Plateforme, region UE) - gdy rezydencja danych w UE musi być umownie zagwarantowana, a własny klaster nie jest dostępny
- **DeepSeek V4-Pro** i **V4-Flash** (licencja MIT, self-host lub API) - dla pogłębionych analiz i ścieżek decyzyjnych wymagających rygoru matematyczno-logicznego
- **Llama 4 Scout** (licencja Meta, self-host, kontekst 10M tokenów) - dla długich akt i pełnego kontekstu akt osobowych
- **gpt-oss-120b** (OpenAI, Apache 2.0, self-host) - gdy potrzebny jest model OpenAI bez zależności od chmury
- **Qwen 3 Coder 110B**, **DeepSeek Coder V4**, **Codestral Mamba 32B** - dla mikro-decyzji kodowych i ABAP/SQL po stronie backendu

To, który model jest wybierany dla każdej mikro-decyzji (kryteria wyboru, aktualne benchmarki, porównanie TCO dla WIG20 i większego sektora mid-market), opisuje artykuł główny [Modele AI 2026 - który model językowy do jakiego zadania](/pl/magazyn/modele-ai-porownanie-2026/). To, co z powyższego da się hostować on-prem - łącznie z sizingiem GPU, warunkami licencyjnymi i stosem self-hostingowym - opisuje spinoff [Samohostowana open-source AI 2026](/pl/magazyn/samohostowana-open-source-ai-2026/).

## Dlaczego AI podejmuje niektóre decyzje lepiej niż człowiek

W dyskusji o agentach AI pomija się jedno pytanie: Czy istnieją decyzje, w których AI jest nie tylko szybsza, ale dowodnie lepsza? Odpowiedź brzmi: tak. I Decision Layer pozwala precyzyjnie zidentyfikować te przypadki.

Istnieją trzy kategorie, w których autonomiczne decyzje AI przewyższają ludzkie - nie dlatego, że AI jest mądrzejsza, lecz dlatego, że nie ma strukturalnych słabości człowieka:

**Spójność między lokalizacjami i osobami.** 50 pracowników w 12 oddziałach stosuje ten sam układ zbiorowy. Każdy nieco inaczej interpretuje przypadki graniczne. W oddziale A przyznawana jest premia specjalna, w oddziale B ten sam przypadek jest odrzucany. To nie problem szkoleniowy - to naturalna zmienność ludzkich decyzji. AI pracująca na wersjonowanym zestawie reguł decyduje identycznie. Za każdym razem, w każdym oddziale.

**Odporność na zmęczenie przy powtarzalnych decyzjach.** Rekruter w poniedziałek rano ocenia inaczej niż w piątek po południu. Po 50. aplikacji spada uwaga. Poprzedni kandydat był silny - następny wydaje się słabszy w porównaniu (efekt zakotwiczenia). AI ocenia aplikację numer 1 z taką samą starannością jak aplikację numer 200. Nie ma złego dnia.

**Kompletność weryfikacji reguł.** Pracownik HR sprawdza zwolnienie lekarskie pod kątem trzech-czterech kryteriów, które przychodzą mu na myśl: czas choroby, okres kontynuacji wynagrodzenia, może próg procedury reintegracji. Ale czy sprawdza też okres wyczekiwania? Regułę specjalną dla pracowników na część etatu w zakładowym układzie zbiorowym? Obowiązek zgłoszenia do ZUS przy określonych schorzeniach? Za każdym razem? Również w piątek o 16:00? AI sprawdza wszystkie obowiązujące reguły, w aktualnej wersji, kompletnie i z dokumentacją. Nie dlatego, że jest mądrzejsza - lecz dlatego, że nie zapomina.

To nie oznacza, że AI jest wszędzie lepsza. Decyzje uznaniowe, oceny indywidualne, dopasowanie kulturowe, rozważania etyczne - to są i pozostaną domenami ludzkimi. Ale przy decyzjach opartych na regułach, powtarzalnych i wymagających wysokiej spójności, autonomiczna AI nie jest kompromisem. Jest lepszym rozwiązaniem.

Decision Layer operacjonalizuje to rozróżnienie: Dla każdej mikro-decyzji określa, czy decyduje człowiek, zestaw reguł czy AI - a przy decyzjach AI dokumentuje, *dlaczego* AI jest tu właściwym wyborem.

## Dlaczego żaden agent nie powinien trafić do produkcji bez Decision Layer

Bez Decision Layer agent AI to czarna skrzynka. Generuje wyniki, ale nikt nie jest w stanie prześledzić, jak do nich doszedł. Ma to konkretne konsekwencje:

**Audyt:** Biegli rewidenci i audyt wewnętrzny potrzebują przejrzystości. Bez Audit Trail każda decyzja agenta stanowi ryzyko audytowe. Audytor musi ręcznie weryfikować każdy pojedynczy przypadek - to bardziej pracochłonne niż praca bez agenta.

**Konsultacja z Radą Zakładową:** Rady Zakładowe mają prawo do informacji i konsultacji przy wdrażaniu systemów AI. Bez przejrzystej logiki decyzyjnej nie mogą pełnić swojej roli. Decision Layer przekształca porozumienia zakładowe w ograniczenia techniczne systemu.

**Odpowiedzialność:** Gdy agent generuje błędne księgowanie i nie ma ścieżki decyzyjnej, nie wiadomo, kto ponosi odpowiedzialność. Decision Layer dokumentuje łańcuch odpowiedzialności.

**Skalowanie:** Agent, który działa w projekcie pilotażowym, niekoniecznie sprawdzi się w produkcji. Bez infrastruktury governance każdy agent pozostaje przypadkiem indywidualnym. Decision Layer umożliwia spójne governance dla wszystkich agentów.

## Decision Layer i Cert-Ready by Design

Decision Layer stanowi techniczną podstawę Cert-Ready by Design. Kontrole w Decision Layer są obiektami danych pierwszej klasy ze zdefiniowanymi atrybutami: Control_ID, Technical_Implementation, Rule_Version, Evidence_Generator, Evidence_History, Auditor_View.

Dowody (Evidence) są generowane automatycznie - nie kompletowane retrospektywnie. Audytorzy widzą w Auditor Portal aktualny status wszystkich kontroli, z możliwością drążenia do konkretnej implementacji reguły.

Mapowanie na standardy odwzorowuje kontrole na uznane standardy audytowe: ISA, krajowe standardy rewizji finansowej oraz Ustawę o rachunkowości. Badanie sprawozdania finansowego może być przeprowadzone na podstawie automatycznie generowanych dowodów.

Więcej: [Cert-Ready by Design](/pl/governance/cert-ready/)

> [Decision Layer - przegląd i przykłady](/pl/decision-layer/)

> [Akt decyzyjny: dlaczego każda decyzja AI musi być podważalna](/pl/magazyn/akt-decyzyjny-podwazalne-decyzje-ai/)

<a href="/pl/kontakt/" target="_blank" rel="noopener noreferrer">Umów spotkanie</a> - Pokażemy Ci, jak Decision Layer wygląda dla Twojego konkretnego procesu.

--- Hosting DeepSeek we własnej infrastrukturze ---
> Jak firmy wdrażają rodzinę DeepSeek (R1, V4-Flash, V4-Pro) i inne LLM zgodnie z RODO na Azure, GCP lub Self-Hosted. Architektura, suwerenność danych, routing decyzji zamiast jednego modelu-mistrza.

## Dlaczego DeepSeek jest istotny dla firm

[DeepSeek](https://www.deepseek.com/) udowodnił swoimi modelami open source, że wydajne LLM nie muszą pochodzić wyłącznie od OpenAI czy Google. Rodzina DeepSeek obejmuje **R1 (styczeń 2025, licencja MIT)**, **V4-Flash (kwiecień 2026, 284B/13B aktywnych MoE, MIT)** oraz **V4-Pro (1,6T/49B aktywnych, kontekst 1M, MIT)** i w benchmarkach osiąga **poziom GPT-5.5 / Claude Opus 4.7** - V4-Pro zbliża się do wydajności zamkniętych modeli frontier pod licencją MIT, przy znacznie niższych kosztach operacyjnych i z pełną przejrzystością kodu modelu.

**Aktualizacja maj 2026:** DeepSeek V4-Pro (1.6T/49B aktywnych MoE) oraz V4-Flash (284B/13B aktywnych) zostały wydane 24 kwietnia 2026 jako preview na licencji MIT. Dla nowych wdrożeń V4-Flash jest typowym koniem roboczym, V4-Pro dla setupów klasy hyperscaler lub przez API/hosted dla mniejszych wdrożeń. Architektura R1 pozostaje dojrzała i production-ready, ale jest wypierana przez V4-Flash przy nowych wdrożeniach. Szczegóły w artykule [Samohostowana open-source AI 2026](/pl/magazyn/samohostowana-open-source-ai-2026/).

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">W skrócie - DeepSeek w zastosowaniu enterprise</p>
<ul class="text-body text-gosign-text space-y-2">
<li>DeepSeek R1 jest open source (licencja MIT) i może działać w pełni self-hosted na Azure, GCP lub on-premise - bez wycieku danych.</li>
<li>Self-hosting eliminuje ryzyko RODO związane z użyciem API, przy którym dane płyną do Chin. Sam model nie stanowi ryzyka - API stanowi.</li>
<li>Trzy opcje hostingu (Azure, GCP, self-hosted) są technicznie równoważne; wybór zależy od krajobrazu IT i wymagań compliance.</li>
<li>Architektura agnostyczna wobec modeli zapobiega vendor lock-in: gdy pojawi się lepszy model, zostaje zintegrowany bez przebudowy.</li>
<li>IDC (2024) szacuje, że 42% dużych europejskich przedsiębiorstw planuje uruchomić co najmniej jeden open-weight LLM na prywatnej infrastrukturze do końca 2026.</li>
</ul>
</div>

Dla firm jest to istotne, ponieważ tworzy realną możliwość wyboru: zamiast wiązać się z jednym dostawcą LLM, organizacje mogą uruchamiać różne modele równolegle, porównywać je i dla każdego przypadku użycia stosować najlepiej dopasowany model.

Zasadnicze pytanie nie brzmi, czy DeepSeek jest wystarczająco dobry. Pytanie brzmi, jak firma eksploatuje LLM tak, aby suwerenność danych, compliance i przyszłościowość były zagwarantowane - niezależnie od tego, który model jest aktualnie wiodący.


## Trzy opcje hostingu w porównaniu

### Azure: integracja enterprise jako mocna strona

Azure AI Foundry oferuje DeepSeek jako zarządzane wdrożenie. Zaleta dla firm z istniejącym środowiskiem Microsoft: integracja z Azure Entra ID (dawniej Azure AD), istniejące konfiguracje sieciowe i bezpieczeństwa oraz wybór regionu dla rezydencji danych w UE. Instancje GPU (A100, H100) są dostępne w modelu pay-as-you-go lub Provisioned Throughput.

Wada: vendor lock-in na poziomie Azure. Późniejsze przejście do GCP lub Self-Hosted wymaga przebudowy warstwy wdrożeniowej - chyba że architektura jest od początku zaprojektowana jako agnostyczna wobec modeli i platform.

### GCP: elastyczność i natywny Kubernetes

Google Cloud Platform oferuje przez Vertex AI zarządzane wdrożenia modeli open source. Mocna strona leży w architekturze natywnej dla Kubernetes: firmy już korzystające z GKE (Google Kubernetes Engine) mogą uruchamiać LLM jako kontenery obok istniejących usług. Opcje TPU stanowią alternatywę dla GPU NVIDIA.

### Self-Hosted: maksymalna kontrola

Dla firm z najsurowszymi wymogami ochrony danych - na przykład w sektorze finansowym lub ochronie zdrowia - Self-Hosting to konsekwentny wybór. Modele DeepSeek działają na własnych serwerach lub w prywatnym centrum danych, bez jakiejkolwiek zależności od chmury. Kompromis: wyższe nakłady operacyjne na zarządzanie sprzętem, aktualizacje i skalowanie.

| Kryterium | Azure | GCP | Self-Hosted |
|---|---|---|---|
| Setup | Zarządzany (AI Foundry) | Zarządzany (Vertex AI) | Ręczny (bare-metal/VM) |
| Rezydencja danych UE | Germany West Central | europe-west3 | Własne centrum danych |
| Dostępność GPU | A100, H100 (pay-as-you-go) | A100, H100, TPU | A100, H100 (zakup/leasing) |
| Ryzyko vendor lock-in | Wysokie (specyficzne dla Azure) | Średnie (przenośne Kubernetes) | Brak |
| Nakład operacyjny | Niski | Niski-Średni | Wysoki |
| Najlepsze dla | Organizacji Microsoft-centrycznych | Organizacji Kubernetes-natywnych | Maksymalnej suwerenności danych |

Wszystkie trzy opcje są technicznie równoważne. Nie ma kompromisów architektonicznych przy Self-Hosting. Decyzja zależy od istniejącego krajobrazu IT, wymogów compliance i wewnętrznego modelu operacyjnego.


## Dlaczego decyzja o hostingu nie jest najważniejsza

Większość artykułów o hostingu LLM kończy się na decyzji o hostingu. Ale dla firm hosting to tylko fundament - prawdziwe pytania pojawiają się potem.

Jak sterować tym, który model jest używany do jakiego przypadku użycia? Jak logować prompty i odpowiedzi bez naruszania danych pracowników? Jak zapewnić Radzie Zakładowej przejrzystość nad wdrożeniem AI? Jak przeprowadzić zmianę modelu bez zmiany interfejsu dla 5000 pracowników?

To nie są pytania o hosting. To pytania o architekturę i governance. I dokładnie tutaj infrastruktura AI klasy enterprise różni się od hostowanego modelu.


## Architektura agnostyczna wobec modeli jako strategia

Krajobraz LLM zmienia się szybciej niż jakikolwiek cykl zakupowy w korporacji. To, co dziś jest state-of-the-art, może za sześć miesięcy zostać wyparte przez nowy model. Kto buduje całą infrastrukturę na jednym modelu frontier - obojętnie czy na DeepSeek V4-Pro, GPT-5.5 czy Claude Opus 4.7 - ponosi ryzyko strategiczne. Agnostyczna wobec modeli warstwa routingu decyzji (zobacz [Który model kiedy?](/pl/magazyn/modele-ai-porownanie-2026/)) absorbuje kolejną zmianę generacji jako zmianę konfiguracji, a nie jako przebudowę.

[Architektura agnostyczna wobec modeli](/pl/uslugi/infrastruktura/) oddziela warstwę użytkową od warstwy modeli. Pracownicy korzystają z ujednoliconego interfejsu czatu. Za nim warstwa orkiestracji routuje na poziomie pojedynczej mikro-decyzji, a nie polegając na jednym modelu-mistrzu: **Mistral Small 3.2** (24B, Apache 2.0, RTX 4090) jako wolumenowy koń roboczy dla 50-70 % decyzji (klasyfikacja, ekstrakcja); **DeepSeek V4-Flash / V4-Pro** (MIT) lub **gpt-oss-120b** (Apache 2.0) do rozumowania on-prem; **Claude Opus 4.7 / GPT-5.5** (chmura) do rozumowania frontier i workflowów agentowych; **Gemini 3.1 Pro** (chmura) do zastosowań multimodalnych; **Qwen 3 Coder / DeepSeek Coder V4** do generowania kodu on-prem. [Llama](https://llama.meta.com/) i [Mistral](https://mistral.ai/) uzupełniają stos w wyspecjalizowanych domenach.

Zmiany modeli, porównania i testy A/B odbywają się w warstwie orkiestracji - przejrzyście dla użytkowników, audytowalnie dla IT, identyfikowalnie dla Rady Zakładowej.


## DeepSeek jako komponent, nie platforma

DeepSeek to wydajny model. Ale żaden model sam w sobie nie rozwiązuje problemu enterprise. Firmy potrzebują nie hostowanego LLM, lecz infrastruktury, w której LLM pracują jako komponenty - osadzone w [Governance by Design](/pl/governance/), zintegrowane z istniejącymi systemami, rozszerzalne o [agentów AI](/pl/uslugi/ai-agents/), którzy przetwarzają dokumenty i orkiestrują przepływy pracy.

[Decision Layer](/pl/decision-layer/) oddziela analizę LLM od decyzji biznesowej. Model przygotowuje, człowiek decyduje - z kompletnym Audit Trail.

W Gosign budujemy tę [infrastrukturę AI](/pl/uslugi/infrastruktura/): agnostyczną wobec modeli, zgodną z RODO, na Azure, GCP lub Self-Hosted. DeepSeek to jeden z wielu komponentów. Architektura robi różnicę.

--- Dlaczego nie trenujemy już agentów AI ---
> 92% dokładności bez trenowania. EU AI Act wymaga od systemów wysokiego ryzyka wytłumaczalnych decyzji jednostkowych (obowiązki od 2 sierpnia 2026 r., przesunięcie na grudzień 2027 wstępnie uzgodnione). Trenowane modele tego nie potrafią.

## Trenowanie to nowy faks

W 2019 roku musieliśmy trenować modele AI. Były zbyt ograniczone na cokolwiek innego. GPT-2 nie potrafił napisać spójnego akapitu. BERT do każdego zadania potrzebował tysięcy oznaczonych przykładów i klastra GPU na wiele dni.

To było sześć lat temu. Sześć lat, w których możliwości modeli językowych poprawiły się o rzędy wielkości. Ale branża wciąż zachowuje się tak, jakby "trenowanie" było naturalnym pierwszym krokiem.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Na pierwszy rzut oka - Dlaczego trenowanie to błędna architektura</p>
<ul class="text-body text-gosign-text space-y-2">
<li>LLM osiąga 92% poprawnych decyzji przy weryfikacji faktur - bez jednego przykładu treningowego. Doświadczeni prawnicy osiągają 72%.<sup>[1]</sup></li>
<li>EU AI Act (Art. 13, 14, 86) wymaga od systemów wysokiego ryzyka wytłumaczalnych decyzji jednostkowych - obowiązki od 2 sierpnia 2026 r. (przesunięcie na grudzień 2027 wstępnie uzgodnione - Digital Omnibus, maj 2026). Trenowane modele tego nie potrafią.<sup>[10]</sup></li>
<li>Alternatywa: zestaw reguł (wersjonowany), kontekst (per decyzja), Decision Layer (człowiek/reguła/AI per Micro-Decision).</li>
<li>Skonfigurowane agenty są model-agnostyczne: zmiana modelu Foundation bez zmiany zestawu reguł. Brak lock-in, brak ponownego trenowania.</li>
<li>Ponad 40% projektów Agentic AI zawodzi do 2027 roku - głównie z powodu brakującej governance, nie brakującej wydajności modelu.<sup>[9]</sup></li>
</ul>
</div>

Jeśli ktoś w 2026 roku mówi "Trenujemy nasze agenty AI", to tak jak powiedzieć w 2010 "Faksujemy nasze zamówienia". Działa. Ale pokazuje, że nie zrozumiał architektury.

<!-- Timeline: Od trenowania do konfiguracji -->
<div class="not-prose my-12">
<div class="bg-gosign-dark rounded-card p-6 sm:p-8">
<p class="text-h3 font-bold text-white mb-6">Od trenowania do konfiguracji</p>
<div class="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-4 gap-4">

<div class="border border-white/10 rounded-lg p-4 bg-white/5">
<p class="text-gosign-text-on-dark text-xs uppercase tracking-wider mb-1">2018 - 2020</p>
<p class="text-white font-bold text-lg mb-2">Trenowanie jest obowiązkowe</p>
<p class="text-gosign-text-on-dark text-sm mb-3">BERT, GPT-2. 110M - 1,5B parametrów.</p>
<div class="space-y-1 text-xs text-gosign-text-on-dark">
<p>Czas: tygodnie</p>
<p>Koszty: $10 000 - $100 000</p>
<p>Wymóg: klaster GPU</p>
</div>
</div>

<div class="border border-white/10 rounded-lg p-4 bg-white/5">
<p class="text-gosign-text-on-dark text-xs uppercase tracking-wider mb-1">2021 - 2023</p>
<p class="text-white font-bold text-lg mb-2">Trenowanie staje się opcjonalne</p>
<p class="text-gosign-text-on-dark text-sm mb-3">GPT-3/3.5. 175B parametrów.</p>
<div class="space-y-1 text-xs text-gosign-text-on-dark">
<p>Czas: dni</p>
<p>Koszty: $1000 - $10 000</p>
<p>Wymóg: GPU potrzebne</p>
</div>
</div>

<div class="border border-white/10 rounded-lg p-4 bg-white/5">
<p class="text-gosign-text-on-dark text-xs uppercase tracking-wider mb-1">2024</p>
<p class="text-white font-bold text-lg mb-2">Trenowanie czy prompting?</p>
<p class="text-gosign-text-on-dark text-sm mb-3">GPT-4o, Claude 3.5. Multimodal.</p>
<div class="space-y-1 text-xs text-gosign-text-on-dark">
<p>Czas: godziny</p>
<p>Koszty: $10 - $100</p>
<p>Wymóg: API-Call</p>
</div>
</div>

<div class="border border-gosign-accent rounded-lg p-4 bg-gosign-accent/10">
<p class="text-gosign-accent-on-dark text-xs uppercase tracking-wider mb-1">2025 - 2026</p>
<p class="text-white font-bold text-lg mb-2">Konfiguracja wystarczy</p>
<p class="text-gosign-text-on-dark text-sm mb-3">GPT-5.5, Claude Opus 4.7. Reasoning.</p>
<div class="space-y-1 text-xs text-gosign-text-on-dark">
<p>Czas: minuty</p>
<p>Koszty: $10 - $100</p>
<p>Wymóg: API-Call</p>
</div>
</div>

</div>
</div>
</div>

Kumar Gauraw ujmuje to trafnie: "Większość sięga po Fine-Tuning zbyt wcześnie."<sup>[5]</sup> Nie dlatego, że Fine-Tuning jest zły. Lecz dlatego, że w 2026 roku dla większości zadań enterprise nie jest już konieczny.

## Czego trenowany model nie potrafi: wytłumaczyć pojedynczej decyzji

Kandydat zostaje odrzucony przez Twojego agenta rekrutacyjnego. Pyta: dlaczego?

Dwie odpowiedzi. Dwie architektury.

**Trenowany model:** "Nasz model na podstawie 50 000 historycznych decyzji o zatrudnieniu nauczył się, że Twój profil ma prawdopodobieństwo sukcesu 34%."

**Skonfigurowany agent:** "Twoje kwalifikacje w zakresie inżynierii mechanicznej nie spełniają wymagania 3 (elektrotechnika lub porównywalne). Reguła: profil stanowiska v2026-03. Zaskarżalne: tak. Proces: dział merytoryczny sprawdza, czy inżynieria mechaniczna kwalifikuje się jako 'porównywalna'."

Pierwsza odpowiedź nie spełnia wymagań EU AI Act dla systemów wysokiego ryzyka - obowiązków, które zgodnie z obowiązującym prawem mają zastosowanie od 2 sierpnia 2026 r. (z wstępnie uzgodnionym przesunięciem na 2 grudnia 2027 r. - Digital Omnibus, maj 2026, przyjęcie w toku).

EU AI Act, Art. 13 (przejrzystość), Art. 14 (nadzór ludzki), Art. 86 (prawo do wyjaśnienia).<sup>[10]</sup> Dla systemów wysokiego ryzyka - a rekrutacja jest wysokim ryzykiem, Annex III(4) - każda decyzja jednostkowa musi być zrozumiała, wytłumaczalna i zaskarżalna.

Nie model. Pojedyncza decyzja. Dla tego kandydata. Z tym uzasadnieniem.

Trenowany model tego nie potrafi. Nie ma akta decyzji. Ma wagi. A wagi nie tłumaczą nic radzie zakładowej.

### Test compliance: trenowany vs. skonfigurowany

<!-- Porównanie dwukolumnowe: Trenowany vs. Skonfigurowany -->
<div class="not-prose my-10">
<div class="bg-gosign-dark rounded-card overflow-hidden">
<div class="grid grid-cols-1 md:grid-cols-2">

<!-- Lewa kolumna: Trenowany -->
<div class="p-6 sm:p-8 border-b md:border-b-0 md:border-r border-white/10">
<p class="text-gosign-text-on-dark text-xs uppercase tracking-wider mb-1">Architektura A</p>
<p class="text-white font-bold text-xl mb-6">Trenowany model</p>

<div class="space-y-5">
<div>
<p class="text-gosign-text-on-dark text-sm mb-1">"Dlaczego ta decyzja?"</p>
<p class="text-white text-sm">"Model się nauczył" - Black Box</p>
<p class="text-red-400 text-xs mt-1">Niewytłumaczalne</p>
</div>

<div>
<p class="text-gosign-text-on-dark text-sm mb-1">"Zmiana przepisów?"</p>
<p class="text-white text-sm">Ponowne trenowanie. 2 - 4 tygodnie, $5000 - $20 000</p>
<p class="text-red-400 text-xs mt-1">Drogie i powolne</p>
</div>

<div>
<p class="text-gosign-text-on-dark text-sm mb-1">"Czy osoba dotknięta może zaskarżyć?"</p>
<p class="text-white text-sm">Przeciw czemu? Przeciw wagom?</p>
<p class="text-red-400 text-xs mt-1">Niezaskarżalne</p>
</div>

<div>
<p class="text-gosign-text-on-dark text-sm mb-1">"Nowy model LLM dostępny?"</p>
<p class="text-white text-sm">Nowe trenowanie konieczne. Tygodnie, lock-in.</p>
<p class="text-red-400 text-xs mt-1">Zależność od dostawcy</p>
</div>

<div>
<p class="text-gosign-text-on-dark text-sm mb-1">"Zgodność z EU AI Act?"</p>
<p class="text-white text-sm">Art. 13: brak przejrzystości. Art. 14: ingerencja = wymiana modelu. Art. 86: wyjaśnienie niemożliwe.</p>
<p class="text-red-400 text-xs mt-1">Problematyczne</p>
</div>

<div class="pt-4 border-t border-white/10">
<p class="text-red-400 font-bold text-sm">Lock-in: tak | Audyt: trudny | EU AI Act: problematyczne</p>
</div>
</div>
</div>

<!-- Prawa kolumna: Skonfigurowany -->
<div class="p-6 sm:p-8">
<p class="text-gosign-accent-on-dark text-xs uppercase tracking-wider mb-1">Architektura B</p>
<p class="text-white font-bold text-xl mb-6">Skonfigurowany agent</p>

<div class="space-y-5">
<div>
<p class="text-gosign-text-on-dark text-sm mb-1">"Dlaczego ta decyzja?"</p>
<p class="text-white text-sm">"§9 EStG v2026-01, nieobecność 14h15min" (niemiecki przepis podatkowy - analogiczne reguły w każdej jurysdykcji)</p>
<p class="text-green-400 text-xs mt-1">Reguła, wersja, kontekst udokumentowane</p>
</div>

<div>
<p class="text-gosign-text-on-dark text-sm mb-1">"Zmiana przepisów?"</p>
<p class="text-white text-sm">Aktualizacja reguły. Natychmiast skuteczna, $0.</p>
<p class="text-green-400 text-xs mt-1">Wersjonowane i audytowalne</p>
</div>

<div>
<p class="text-gosign-text-on-dark text-sm mb-1">"Czy osoba dotknięta może zaskarżyć?"</p>
<p class="text-white text-sm">"Śniadanie nie było wliczone." Referent sprawdza.</p>
<p class="text-green-400 text-xs mt-1">Zaskarżalne z aktami decyzji</p>
</div>

<div>
<p class="text-gosign-text-on-dark text-sm mb-1">"Nowy model LLM dostępny?"</p>
<p class="text-white text-sm">Zestaw reguł pozostaje. 0 nakładu, brak lock-in.</p>
<p class="text-green-400 text-xs mt-1">Model-agnostyczny</p>
</div>

<div>
<p class="text-gosign-text-on-dark text-sm mb-1">"Zgodność z EU AI Act?"</p>
<p class="text-white text-sm">Akta decyzji per Micro-Decision. Nadpisywanie reguły, nie wymiana modelu.</p>
<p class="text-green-400 text-xs mt-1">Zgodne by Design</p>
</div>

<div class="pt-4 border-t border-white/10">
<p class="text-green-400 font-bold text-sm">Lock-in: nie | Audyt: by Design | EU AI Act: zgodne</p>
</div>
</div>
</div>

</div>
</div>
</div>

Problem compliance to jednak tylko powierzchnia. Pod nią kryje się problem architektoniczny.

## 92% vs. 72%

Badacze przetestowali w 2025 roku, jak dobrze LLM potrafi weryfikować faktury prawnicze względem Billing Guidelines.<sup>[1]</sup> Bez Fine-Tuning. Bez trenowania. Tylko zestaw reguł jako kontekst.

Wynik:

<!-- 92% vs. 72% porównanie słupkowe -->
<div class="not-prose my-10">
<div class="bg-gosign-dark rounded-card p-6 sm:p-8 text-white">
<p class="text-h3 font-bold mb-6">Faktura prawnicza: zgodna z regułami czy nie?</p>
<p class="text-gosign-text-on-dark text-sm mb-8">Better Bill GPT, Whitehouse et al. (kwiecień 2025). Peer-reviewed. LLM otrzymał zestaw reguł jako kontekst, bez Fine-Tuning.<sup>[1]</sup></p>

<!-- Dokładność ogólna -->
<div class="mb-8">
<p class="text-gosign-text-on-dark text-xs uppercase tracking-wider mb-3">Dokładność ogólna</p>

<div class="mb-4">
<div class="flex justify-between items-center mb-1">
<p class="text-sm font-medium">LLM (bez trenowania)</p>
<p class="text-gosign-accent-on-dark font-bold text-lg">92%</p>
</div>
<div class="w-full bg-white/10 rounded-full h-4">
<div class="bg-gosign-accent rounded-full h-4" style="width: 92%"></div>
</div>
</div>

<div class="mb-4">
<div class="flex justify-between items-center mb-1">
<p class="text-sm font-medium">Doświadczeni prawnicy</p>
<p class="text-gosign-text-on-dark font-bold text-lg">72%</p>
</div>
<div class="w-full bg-white/10 rounded-full h-4">
<div class="bg-white/30 rounded-full h-4" style="width: 72%"></div>
</div>
</div>
</div>

<!-- F-Score pozycje pojedyncze -->
<div class="mb-8">
<p class="text-gosign-text-on-dark text-xs uppercase tracking-wider mb-3">Klasyfikacja pozycji pojedynczych (F-Score)</p>

<div class="mb-4">
<div class="flex justify-between items-center mb-1">
<p class="text-sm font-medium">LLM (bez trenowania)</p>
<p class="text-gosign-accent-on-dark font-bold text-lg">81%</p>
</div>
<div class="w-full bg-white/10 rounded-full h-4">
<div class="bg-gosign-accent rounded-full h-4" style="width: 81%"></div>
</div>
</div>

<div class="mb-4">
<div class="flex justify-between items-center mb-1">
<p class="text-sm font-medium">Najlepsza grupa ludzka</p>
<p class="text-gosign-text-on-dark font-bold text-lg">43%</p>
</div>
<div class="w-full bg-white/10 rounded-full h-4">
<div class="bg-white/30 rounded-full h-4" style="width: 43%"></div>
</div>
</div>
</div>

<!-- Czas i koszty -->
<div class="grid grid-cols-1 sm:grid-cols-2 gap-6">

<div>
<p class="text-gosign-text-on-dark text-xs uppercase tracking-wider mb-3">Czas na fakturę</p>
<div class="mb-3">
<div class="flex justify-between items-center mb-1">
<p class="text-sm font-medium">LLM</p>
<p class="text-gosign-accent-on-dark font-bold">3,6 sek.</p>
</div>
<div class="w-full bg-white/10 rounded-full h-3">
<div class="bg-gosign-accent rounded-full h-3" style="width: 1.4%"></div>
</div>
</div>
<div>
<div class="flex justify-between items-center mb-1">
<p class="text-sm font-medium">Prawnicy</p>
<p class="text-gosign-text-on-dark font-bold">~250 sek.</p>
</div>
<div class="w-full bg-white/10 rounded-full h-3">
<div class="bg-white/30 rounded-full h-3" style="width: 100%"></div>
</div>
</div>
</div>

<div>
<p class="text-gosign-text-on-dark text-xs uppercase tracking-wider mb-3">Koszt na fakturę</p>
<div class="mb-3">
<div class="flex justify-between items-center mb-1">
<p class="text-sm font-medium">LLM</p>
<p class="text-gosign-accent-on-dark font-bold">&lt; $0,01</p>
</div>
<div class="w-full bg-white/10 rounded-full h-3">
<div class="bg-gosign-accent rounded-full h-3" style="width: 0.2%"></div>
</div>
</div>
<div>
<div class="flex justify-between items-center mb-1">
<p class="text-sm font-medium">Prawnicy</p>
<p class="text-gosign-text-on-dark font-bold">$4,27</p>
</div>
<div class="w-full bg-white/10 rounded-full h-3">
<div class="bg-white/30 rounded-full h-3" style="width: 100%"></div>
</div>
</div>
</div>

</div>

<p class="text-gosign-text-on-dark text-xs mt-6 border-t border-white/10 pt-4">Redukcja kosztów: 99,97%.<sup>[4]</sup> Mechanizm przenośny na każde zadanie compliance oparte na regułach.</p>
</div>
</div>

LLM nie został wytrenowany na fakturach. Otrzymał Billing Guidelines jako kontekst. I natychmiast zdecydował.

### Dlaczego LLM był lepszy

Nie dlatego, że jest mądrzejszy. Lecz dlatego, że o 15:00 stosuje tę samą regułę tak samo jak o 9:00. Niespójność to problem człowieka, nie niekompetencja.<sup>[1]</sup>

Doświadczeni prawnicy podejmują 72% poprawnych decyzji - ale każdy prawnik popełnia inne błędne decyzje. Błędy nie są systematyczne, lecz losowe. Zmęczenie, presja czasu, osobista interpretacja. LLM nie zna zmęczenia.

### Przenośny mechanizm

Czy zestaw reguł nazywa się "Billing Guideline", "§14 UStG" czy "Ryczałty BMF 2026": sprawdzenie dokumentu względem reguły, identyfikacja odchylenia, udokumentowanie decyzji. Mechanizm jest identyczny.

<!-- Tabela podsumowująca: zastosowanie zestawu reguł -->
<div class="not-prose my-8">
<div class="overflow-x-auto">
<table class="w-full border-collapse text-sm">
<thead>
<tr class="bg-gosign-dark text-white">
<th class="p-3 text-left font-bold">Wymiar</th>
<th class="p-3 text-left font-bold">Trenowany model</th>
<th class="p-3 text-left font-bold">Skonfigurowany agent</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border bg-gosign-white">
<td class="p-3 font-medium text-gosign-dark">Zmiana reguł</td>
<td class="p-3 text-gosign-text">Ponowne trenowanie (tygodnie, $5k - $20k)</td>
<td class="p-3 text-gosign-text">Aktualizacja zestawu reguł (minuty, $0)</td>
</tr>
<tr class="border-b border-gosign-border bg-gosign-light">
<td class="p-3 font-medium text-gosign-dark">Wytłumaczalność</td>
<td class="p-3 text-gosign-text">"Model się nauczył" (Black Box)</td>
<td class="p-3 text-gosign-text">Reguła + wersja + kontekst (akta decyzji)</td>
</tr>
<tr class="border-b border-gosign-border bg-gosign-white">
<td class="p-3 font-medium text-gosign-dark">Zaskarżalność</td>
<td class="p-3 text-gosign-text">Niemożliwe (brak akt decyzji)</td>
<td class="p-3 text-gosign-text">Tak (osoba dotknięta widzi regułę i może sprzeciwić się)</td>
</tr>
<tr class="border-b border-gosign-border bg-gosign-light">
<td class="p-3 font-medium text-gosign-dark">Zmiana modelu</td>
<td class="p-3 text-gosign-text">Nowe trenowanie konieczne (lock-in)</td>
<td class="p-3 text-gosign-text">0 nakładu (model-agnostyczny)</td>
</tr>
<tr class="border-b border-gosign-border bg-gosign-white">
<td class="p-3 font-medium text-gosign-dark">Audit Trail</td>
<td class="p-3 text-gosign-text">Wejście + wyjście (brak uzasadnienia)</td>
<td class="p-3 text-gosign-text">Wejście + reguła + wersja + pewność + wynik</td>
</tr>
<tr class="border-b border-gosign-border bg-gosign-light">
<td class="p-3 font-medium text-gosign-dark">EU AI Act (sie. 2026)</td>
<td class="p-3 text-gosign-text">Art. 13, 14, 86: problematyczne</td>
<td class="p-3 text-gosign-text">Art. 13, 14, 86: zgodne by Design</td>
</tr>
<tr class="bg-gosign-white">
<td class="p-3 font-medium text-gosign-dark">Break-Even Fine-Tuning</td>
<td class="p-3 text-gosign-text">Od ~35 000 zapytań/miesiąc<sup>[6]</sup></td>
<td class="p-3 text-gosign-text">Natychmiastowa opłacalność</td>
</tr>
</tbody>
</table>
</div>
</div>

Badanie Chauhan et al. (2025) określa punkt Break-Even Fine-Tuning względem promptingu na około 35 000 zapytań miesięcznie.<sup>[6]</sup> Większość procesów HR i Finance w przedsiębiorstwach jest daleko poniżej tego poziomu.

## Trzy rzeczy zamiast trenowania

Jeśli nie trenowanie, to co? Trzy komponenty zastępują to, co Fine-Tuning obiecuje, ale strukturalnie nie jest w stanie dotrzymać.

### 1. Zestaw reguł

Wszystko, co agent musi wiedzieć, znajduje się w przepisie, rozporządzeniu, układzie zbiorowym lub porozumieniu ramowym. Te reguły się zmieniają. Prawo podatkowe zmienia się corocznie. Ryczałty i stawki zmieniają się corocznie. Rozporządzenia UE zmieniają się.

Trenowany model musi być ponownie trenowany przy każdej zmianie. Zestaw reguł jest aktualizowany. Natychmiastowo skuteczny, wersjonowany, audytowalny. Brak klastra GPU, brak cyklu ewaluacji, brak ryzyka regresji.

RAG (Retrieval Augmented Generation) redukuje błędy faktyczne o do 50%.<sup>[11]</sup> Nie dlatego, że model staje się mądrzejszy. Lecz dlatego, że widzi aktualną regułę zamiast wywoływać przestarzałą wagę.

### 2. Kontekst

Agent nie potrzebuje 10 000 historycznych rozliczeń podróżnych. Potrzebuje tego jednego rozliczenia: data podróży, wyjazd, powrót, hotel, śniadanie wliczone czy nie. To jest kontekst tej decyzji.

Jest dostarczany przez strukturalne dane wejściowe lub RAG, nie wbudowany przez trenowanie. Gdy kontekst się zmienia - inna podróż, inny pracownik - zmienia się decyzja. Nie model.

Konkretny przykład: [Travel Decision Layer](/pl/uslugi/travel-decision-layer/) weryfikuje diety podróżne względem §9 EStG (niemieckie prawo podatkowe dot. kosztów podróży). Kontekstem jest pojedyncza podróż. Zestawem reguł jest aktualne prawo podatkowe. Model Foundation jest wymienialny.

### 3. Ramowy układ decyzyjny

Kto decyduje o czym? Nie każda decyzja w procesie jest taka sama.

Dieta podróżna to zestaw reguł: §9 EStG, deterministyczna, 100% pewności. Pytanie, czy wydatek na reprezentację jest "stosowny", to ocena: człowiek. Klasyfikacja nieczytelnego paragonu to AI: ekstrakcja LLM, probabilistyczna.

To rozłożenie na Micro-Decisions z przyporządkowaniem człowiek/reguła/AI jest właściwą pracą architektoniczną. Nie trenowanie. [Decision Layer](/pl/decision-layer/) formalizuje dokładnie ten podział. Szczegóły architektury: [Decision Layer - wyjaśnienie](/pl/magazyn/decision-layer-wyjasnienie/).

<!-- Demo Micro-Decision -->
<div class="not-prose my-10">
<div class="bg-gosign-light border border-gosign-border rounded-card overflow-hidden">
<div class="p-6 sm:p-8">
<p class="text-h3 font-bold text-gosign-dark mb-2">Micro-Decision w praktyce</p>
<p class="text-gosign-text text-sm mb-6">Rozliczenie podróży: 8-godzinny dzień, podróż krajowa, hotel ze śniadaniem</p>

<div class="space-y-3">

<div class="bg-gosign-white border border-gosign-border rounded-lg p-4">
<div class="flex flex-wrap items-center gap-3">
<span class="text-xs font-mono bg-gosign-dark text-white px-2 py-0.5 rounded">#1</span>
<span class="font-medium text-gosign-dark text-sm">Data podróży i czas nieobecności</span>
<span class="text-xs px-2 py-0.5 rounded bg-blue-100 text-blue-800 font-medium">Kontekst</span>
<span class="text-xs text-gosign-text-light ml-auto">Input: dokumenty</span>
</div>
</div>

<div class="bg-gosign-white border border-gosign-border rounded-lg p-4">
<div class="flex flex-wrap items-center gap-3">
<span class="text-xs font-mono bg-gosign-dark text-white px-2 py-0.5 rounded">#2</span>
<span class="font-medium text-gosign-dark text-sm">Obliczenie diety podróżnej</span>
<span class="text-xs px-2 py-0.5 rounded bg-green-100 text-green-800 font-medium">Zestaw reguł</span>
<span class="text-xs text-gosign-text-light ml-auto">§9 EStG v2026-01</span>
</div>
</div>

<div class="bg-gosign-white border border-gosign-border rounded-lg p-4">
<div class="flex flex-wrap items-center gap-3">
<span class="text-xs font-mono bg-gosign-dark text-white px-2 py-0.5 rounded">#3</span>
<span class="font-medium text-gosign-dark text-sm">Zastosowanie potrącenia za śniadanie</span>
<span class="text-xs px-2 py-0.5 rounded bg-green-100 text-green-800 font-medium">Zestaw reguł</span>
<span class="text-xs text-gosign-text-light ml-auto">§9 ust. 4a zd. 8 EStG</span>
</div>
</div>

<div class="bg-gosign-white border border-gosign-border rounded-lg p-4">
<div class="flex flex-wrap items-center gap-3">
<span class="text-xs font-mono bg-gosign-dark text-white px-2 py-0.5 rounded">#4</span>
<span class="font-medium text-gosign-dark text-sm">Klasyfikacja paragonu kasowego</span>
<span class="text-xs px-2 py-0.5 rounded bg-gosign-accent/10 text-gosign-accent font-medium">AI</span>
<span class="text-xs text-gosign-text-light ml-auto">Ekstrakcja LLM, Confidence: 87%</span>
</div>
</div>

<div class="bg-gosign-white border border-gosign-border rounded-lg p-4">
<div class="flex flex-wrap items-center gap-3">
<span class="text-xs font-mono bg-gosign-dark text-white px-2 py-0.5 rounded">#5</span>
<span class="font-medium text-gosign-dark text-sm">Czy wydatek na reprezentację jest "stosowny"?</span>
<span class="text-xs px-2 py-0.5 rounded bg-yellow-100 text-yellow-800 font-medium">Człowiek</span>
<span class="text-xs text-gosign-text-light ml-auto">Ocena, referent sprawdza</span>
</div>
</div>

<div class="bg-gosign-white border border-gosign-border rounded-lg p-4">
<div class="flex flex-wrap items-center gap-3">
<span class="text-xs font-mono bg-gosign-dark text-white px-2 py-0.5 rounded">#6</span>
<span class="font-medium text-gosign-dark text-sm">Utworzenie księgowania zgodnego z przepisami</span>
<span class="text-xs px-2 py-0.5 rounded bg-green-100 text-green-800 font-medium">Zestaw reguł</span>
<span class="text-xs text-gosign-text-light ml-auto">Przepisy rachunkowe, wersjonowane</span>
</div>
</div>

</div>

<div class="mt-6 p-4 bg-gosign-dark rounded-lg">
<p class="text-gosign-text-on-dark text-sm">Każdy z tych kroków ma stały typ: <span class="text-green-400">zestaw reguł</span> (deterministyczny), <span class="text-gosign-accent-on-dark">AI</span> (probabilistyczne, z progiem pewności) lub <span class="text-yellow-400">człowiek</span> (ocena). Gdy §9 EStG się zmieni, reguła zostaje zaktualizowana. Brak ponownego trenowania. Brak nowego modelu.</p>
</div>
</div>
</div>
</div>

## Trzy warstwy: architektura zamiast trenowania

Architektura skonfigurowanego agenta składa się z trzech warstw. Każda warstwa jest niezależnie wymienialna.

<!-- Diagram trzech warstw -->
<div class="not-prose my-10">
<div class="max-w-2xl mx-auto">

<div class="bg-gosign-dark border-2 border-gosign-accent rounded-t-card p-6">
<div class="flex items-center gap-3 mb-3">
<span class="text-gosign-accent-on-dark text-xs uppercase tracking-wider font-bold">Warstwa 3</span>
<span class="text-white font-bold text-lg">Decision Layer</span>
</div>
<div class="flex flex-wrap gap-2">
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Micro-Decisions</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Człowiek / Reguły / AI</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Akta decyzji</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Audit Trail</span>
</div>
</div>

<div class="bg-gosign-dark border-x-2 border-gosign-accent p-6 border-t border-white/10">
<div class="flex items-center gap-3 mb-3">
<span class="text-gosign-accent-on-dark text-xs uppercase tracking-wider font-bold">Warstwa 2</span>
<span class="text-white font-bold text-lg">Zestaw reguł (wersjonowany, wymienialny)</span>
</div>
<div class="flex flex-wrap gap-2">
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Prawo podatkowe</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Rozporządzenia</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Przepisy rachunkowe</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Układ zbiorowy</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Porozumienie ramowe</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">EU AI Act</span>
</div>
</div>

<div class="bg-gosign-darker border-2 border-white/20 rounded-b-card p-6">
<div class="flex items-center gap-3 mb-3">
<span class="text-gosign-text-on-dark text-xs uppercase tracking-wider font-bold">Warstwa 1</span>
<span class="text-white font-bold text-lg">Foundation Model (wymienialny)</span>
</div>
<div class="flex flex-wrap gap-2">
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Claude</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">GPT</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Llama</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Mistral</span>
<span class="text-xs bg-white/10 text-gosign-text-on-dark px-2 py-1 rounded">Gemini</span>
</div>
</div>

<div class="mt-4 flex items-start gap-3 p-4 bg-gosign-light border border-gosign-border rounded-card">
<span class="text-gosign-accent text-lg mt-0.5">&#x2191;</span>
<p class="text-gosign-text text-sm">Wszystko powyżej warstwy 1 pozostaje, gdy model się zmieni. Zestaw reguł, Decision Layer, akta decyzji, Audit Trail - wszystko model-agnostyczne. Brak ponownego trenowania. Brak lock-in.</p>
</div>

</div>
</div>

Dlaczego trzy warstwy? Ponieważ każda ma inną odpowiedzialność.

Foundation Model dostarcza rozumienie języka i reasoning. Rozumie kontekst, wyodrębnia informacje z dokumentów, klasyfikuje dane wejściowe. Nie musi wiedzieć, co mówi §9 EStG. Musi rozumieć, czym jest tekst prawny.

Zestaw reguł zawiera logikę biznesową. Przepisy, rozporządzenia, układy zbiorowe, porozumienia ramowe. Każda reguła ma wersję. Każda wersja ma datę obowiązywania. Gdy przepis się zmieni, reguła zostaje zaktualizowana. Nie model.

[Decision Layer](/pl/decision-layer/) steruje, kto co może decydować. Rozkłada procesy na kroki decyzyjne. Definiuje dla każdego: człowiek, zestaw reguł lub AI. Dokumentuje każdą decyzję z regułą, wersją, kontekstem i wynikiem.

## Co trenowanie naprawdę kosztuje

Nie w dolarach. W zależnościach.

### Lock-in

Fine-tuned model wiąże Cię z tym dostawcą. Zbiór treningowy, wagi, pipeline ewaluacji: wszystko własnościowe. Zmiana modelu = nowe trenowanie = nowe koszty = nowa strata czasu.

Skonfigurowany agent zmienia Foundation Model bez zmiany choćby jednej reguły. Claude dziś, GPT jutro, model open-source w przyszłym tygodniu. Zestaw reguł pozostaje. Decision Layer pozostaje. Akta decyzji pozostają.

### Utrzymanie

Każda zmiana przepisów wymaga ponownego trenowania. W Finance prawo podatkowe, wytyczne ministerialne i składki na ubezpieczenia społeczne zmieniają się corocznie. W HR zmieniają się układy zbiorowe, porozumienia ramowe i regulacje UE.

Trenowany agent wymaga ciągłej pielęgnacji, która wygląda jak projekt softwarowy. Skonfigurowany agent potrzebuje edytora zestawu reguł.

MIT i Stanford (Choi & Xie, 2025) pokazują: AI redukuje zamknięcie miesiąca o 7,5 dnia.<sup>[7]</sup> Ale 62% księgowych obawia się błędów AI.<sup>[8]</sup> Obawa jest uzasadniona - przy trenowanych modelach. Przy skonfigurowanych agentach z aktami decyzji i możliwością zaskarżenia każdy błąd jest identyfikowalny i korygowalny.

### Wytłumaczalność

Trenowany model może powiedzieć, co zdecydował. Nie może powiedzieć, dlaczego.

"Model się nauczył" to nie uzasadnienie, które zaakceptuje kontroler. Żadna rada zakładowa tego nie zaakceptuje. Żaden odrzucony kandydat tego nie zaakceptuje.

"Reguła §9 EStG v2026-01, zastosowana do nieobecności 14h15min" jest uzasadnieniem.

Jeśli nie potrafisz wytłumaczyć decyzji, nie możesz pozwolić jej zaskarżyć. A jeśli nie możesz pozwolić jej zaskarżyć, nie spełnia ona wymagań EU AI Act dla systemów wysokiego ryzyka - obowiązków, które mają zastosowanie od 2 sierpnia 2026 r. (przesunięcie na 2 grudnia 2027 r. wstępnie uzgodnione - Digital Omnibus, maj 2026, przyjęcie w toku).<sup>[10]</sup>

### Czy Fine-Tuning ma swoje miejsce?

Tak. Od około 35 000 zapytań miesięcznie przy stabilnym zestawie reguł Fine-Tuning staje się opłacalny.<sup>[6]</sup> Adaptacja językowa, żargon domenowy, optymalizacja latencji: do tego istnieją dobre powody.

Ale tam, gdzie branża go dziś sprzedaje - Enterprise HR i Finance z corocznie zmieniającymi się przepisami - jest to błędna decyzja architektoniczna. Gartner prognozuje, że ponad 40% projektów Agentic AI zawiedzie do 2027 roku.<sup>[9]</sup> Nie z powodu wydajności modeli. Z powodu governance.

## Pytanie, które powinien zadać Twój zarząd

Nie: "Na jakich danych został wytrenowany wasz agent?"

Lecz:

**1. Jaki zestaw reguł leży u podstaw decyzji? Jaka wersja obowiązywała w momencie decyzji?**

Jeśli odpowiedź brzmi "To jest w modelu", nie ma wersji. Nie ma historii zmian. Nie ma Audit Trail.

**2. Co się dzieje, gdy reguła się zmieni? Ponowne trenowanie czy aktualizacja?**

Jeśli odpowiedź brzmi "Trenujemy ponownie", płacisz za utrzymanie, które jest niepotrzebne.

**3. Czy osoba dotknięta może zobaczyć decyzję jednostkową i ją zaskarżyć?**

Jeśli brak odpowiedzi, masz przed sobą problem compliance pod EU AI Act - obowiązki dla systemów wysokiego ryzyka mają zastosowanie od 2 sierpnia 2026 r. (przesunięcie na grudzień 2027 wstępnie uzgodnione - Digital Omnibus, maj 2026, przyjęcie w toku). Art. 86 EU AI Act: prawo do wyjaśnienia. Nieobowiązkowe to nie jest.<sup>[10]</sup>

## Podejście Gosign

Decision Layer Gosign to implementacja tej architektury. Rozkłada procesy na kroki decyzyjne. Definiuje dla każdego: człowiek, zestaw reguł lub AI. Zestawy reguł są wersjonowane. Decyzje są audytowalne. Wyniki są zaskarżalne.

[48 agentów HR](/pl/katalog-agentow-hr/) i [49 agentów Finance](/pl/katalog-agentow-finance/), każdy z tabelą Micro-Decision. Brak Fine-Tuning. Brak lock-in. Brak ponownego trenowania przy zmianach przepisów.

---

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">Źródła</p>
<ol class="text-sm text-gosign-text space-y-2 list-decimal list-inside">
<li id="fn1">Better Bill GPT, Whitehouse et al. (kwiecień 2025). Legal Invoice Review: LLM osiąga 92% dokładności przy weryfikacji honorariów prawniczych względem Billing Guidelines. Peer-reviewed.</li>
<li id="fn2">Better Bill GPT, Whitehouse et al. (kwiecień 2025). F-Score przy klasyfikacji pozycji pojedynczych: LLM 81% vs. najlepsza grupa ludzka 43%.</li>
<li id="fn3">Better Bill GPT, Whitehouse et al. (kwiecień 2025). Czas przetwarzania na fakturę: LLM 3,6 sekundy vs. doświadczeni prawnicy 194 do 316 sekund.</li>
<li id="fn4">Better Bill GPT, Whitehouse et al. (kwiecień 2025). Redukcja kosztów przy Legal Invoice Review: 99,97% ($4,27 vs. &lt;$0,01 na fakturę).</li>
<li id="fn5">Kumar Gauraw (marzec 2026). "Większość sięga po Fine-Tuning zbyt wcześnie."</li>
<li id="fn6">Chauhan et al., Journal of Information Systems Engineering (2025). Break-Even Fine-Tuning vs. Prompting: ~35 000 zapytań miesięcznie.</li>
<li id="fn7">MIT/Stanford, Choi & Xie (sierpień 2025). AI redukuje zamknięcie miesiąca średnio o 7,5 dnia.</li>
<li id="fn8">MIT/Stanford, Choi & Xie (sierpień 2025). 62% księgowych wyraża obawy dotyczące błędów AI w procesach finansowych.</li>
<li id="fn9">Gartner (czerwiec 2025). Prognoza: ponad 40% projektów Agentic AI zawiedzie do 2027 roku.</li>
<li id="fn10">EU AI Act (VO 2024/1689), Crowell & Moring (luty 2026). Obowiązki dla systemów wysokiego ryzyka mają zastosowanie od 2 sierpnia 2026 r.; na mocy wstępnego porozumienia Digital Omnibus z 7 maja 2026 r. mają zostać przesunięte na 2 grudnia 2027 r. (formalne przyjęcie wciąż w toku, stan na czerwiec 2026 r.). Art. 13 (przejrzystość), Art. 14 (nadzór ludzki), Art. 86 (prawo do wyjaśnienia). Annex III(4): rekrutacja jako system wysokiego ryzyka.</li>
<li id="fn11">IBM (2024). RAG redukuje błędy faktyczne w wyjściach LLM o do 50%.</li>
</ol>
</div>

--- Dlaczego projekty AI w HR nie udają się ---
> Projekty AI nie zawodzą z powodu technologii, lecz brakujących reguł gry. Dlaczego model operacyjny jest ważniejszy niż model językowy.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">W skrócie - Dlaczego projekty AI nie udają się</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Większość projektów AI nie zawodzi z powodu technologii. Zawodzą, bo nikt nie zdefiniował, jakie decyzje AI może podejmować, a jakie muszą pozostać przy człowieku.</li>
<li>AI-Paradox: firmy szeroko wdrażają AI, ale tylko ułamek osiąga mierzalne rezultaty - brakuje architektury decyzyjnej.</li>
<li>MIT Sloan Management Review (2024) wykazał, że 70% inicjatyw enterprise AI nie przechodzi z fazy pilotażowej do produkcji.</li>
<li>Proporcja inwestycji: na każde euro w technologię firmy potrzebują czterech do pięciu euro w procesy, governance i zarządzanie zmianą. Sama technologia adresuje około 20% problemu.</li>
<li>Decision Layer rozkłada procesy biznesowe na udokumentowane kroki decyzyjne - człowiek, reguły lub AI - zamieniając eksperymenty AI w systemy produkcyjne.</li>
</ul>
</div>

## Projekt pilotażowy, który zadziałał - i potem zniknął

Dział HR uruchamia projekt AI. Agent przetwarza zwolnienia lekarskie: czyta dokument, wyodrębnia dane, sprawdza wobec układu zbiorowego, tworzy propozycję dla SAP SuccessFactors. W pilocie wszystko działa. Trafność wynosi 94%. Czas przetwarzania spada z 45 minut do 5 minut.

Sześć miesięcy później: Agent nadal działa w pilocie. Nie dlatego, że technologia zawiodła. Lecz dlatego, że nikt nie odpowiedział na pytania, które pojawiają się po pilocie:

Kto zatwierdza księgowanie proponowane przez agenta? Co się dzieje, gdy agent się myli - kto ponosi odpowiedzialność? Czy logika obowiązuje również dla oddziału w Monachium, gdzie obowiązuje inny układ zbiorowy? Czy agent może automatycznie zainicjować procedurę BEM przy chorobie długoterminowej, czy o tym musi zdecydować człowiek? Co mówi Rada Zakładowa?

To nie są pytania techniczne. To pytania decyzyjne. I dopóki nie zostaną na nie udzielone odpowiedzi, każdy agent pozostaje eksperymentem.

## AI-Paradox: Wysokie nakłady, niski zwrot

To, co tu się dzieje, nie jest przypadkiem jednostkowym. To wzorzec, który przewija się przez firmy każdej wielkości.

Większość firm już stosuje AI - przynajmniej w formie chatbotów, licencji Copilot lub pierwszych pilotów. Ale nieliczne raportują, że AI wnosi mierzalny wkład w wyniki.

To jest AI-Paradox: Technologia działa. Ale korzyści nie przychodzą.

Typowe wyjaśnienia nie trafiają w sedno. „Dane nie są wystarczająco dobre" - czasem to prawda, ale jakość danych to rozwiązywalny problem. „Model nie jest wystarczająco dobry" - mało prawdopodobne, gdy widzi się, co potrafią aktualne modele językowe. „Pracownicy boją się AI" - zarządzanie zmianą jest ważne, ale nie wyjaśnia, dlaczego nawet dobrze prowadzone projekty utykają.

Rzeczywista przyczyna jest inna: brakuje architektury decyzyjnej.

## Czego brakuje: Nie lepszej technologii - lecz jasnych reguł gry

Agent AI przetwarzający zwolnienia lekarskie podejmuje przy każdym dokumencie pięć do dziesięciu pojedynczych decyzji: Czy dokument jest kompletny? Który układ zbiorowy obowiązuje? Czy występuje choroba długoterminowa? Czy należy zainicjować procedurę BEM? Do jakiego systemu księgować?

Dla każdej z tych decyzji musi być z góry zdefiniowane:

**Decyduje człowiek?** Na przykład przy chorobach długoterminowych, ponieważ procedura reintegracji wymaga uznaniowości i Rada Zakładowa ma prawo do konsultacji.

**Decyduje zestaw reguł?** Na przykład przy weryfikacji układu zbiorowego - układ jest jednoznaczny, reguła jest stosowana konsekwentnie.

**Decyduje AI samodzielnie?** Na przykład przy rozpoznawaniu dokumentów - czy to zwolnienie lekarskie czy zaświadczenie o niezdolności do pracy? Standardowy przypadek, wysokie prawdopodobieństwo.

Bez tego przyporządkowania agent pozostaje czarną skrzynką. Produkuje wyniki, ale nikt nie może prześledzić na jakiej podstawie. Żaden biegły rewident tego nie zaakceptuje. Żadna Rada Zakładowa się na to nie zgodzi. Żaden dział compliance tego nie zwolni.

## Proporcja inwestycji: Dlaczego sama technologia nie wystarczy

Doświadczenie branżowe pokazuje zasadę, która wielu zaskakuje: na każde euro w technologię firmy potrzebują cztery do pięciu euro w procesy, governance i zarządzanie zmianą.

To oznacza: kto ma budżet na AI w wysokości 500 000 EUR i wszystko inwestuje w licencje i modele, adresuje około 20% problemu. Pozostałe 80% - projektowanie procesów, reguły decyzyjne, porozumienia zakładowe, szkolenia, struktury governance - pozostają nieopracowane.

To wyjaśnia AI-Paradox. To nie jest problem technologiczny. To problem inwestycyjny. Lub dokładniej: problem dystrybucji inwestycji.

## Co to oznacza dla HR

Procesy HR są szczególnie podatne na AI-Paradox. Z trzech powodów:

**Po pierwsze: Wysoka złożoność regulacyjna.** Układy zbiorowe, porozumienia zakładowe, przepisy krajowe, wewnętrzne wytyczne. Jeden proces jak przetwarzanie zwolnień lekarskich może dotyczyć pięciu różnych zestawów reguł.

**Po drugie: Obowiązek konsultacji.** W polskich firmach Rada Zakładowa ma prawo do informacji i konsultacji przy wdrażaniu systemów AI przetwarzających dane pracowników. Bez przejrzystej logiki decyzyjnej Rada Zakładowa nie może zweryfikować, co robi agent.

**Po trzecie: Odpowiedzialność.** Gdy agent wygeneruje błędne rozliczenie wynagrodzenia, odpowiedzialność nie spoczywa na agencie. Odpowiada firma. Bez udokumentowanej ścieżki decyzyjnej nie wiadomo, gdzie powstał błąd.

## Najpierw uwidocznić decyzje, potem automatyzować

Rozwiązaniem nie jest mniej AI. Rozwiązaniem jest więcej struktury.

Zanim agent zautomatyzuje proces, proces musi zostać rozłożony na pojedyncze kroki decyzyjne. Dla każdego kroku definiuje się: człowiek, zestaw reguł lub AI. To przyporządkowanie nie jest statyczne - może się zmieniać, gdy zmienia się zestaw reguł lub gdy agent zbiera więcej doświadczenia.

[Decision Layer](/pl/decision-layer/) implementuje dokładnie to. Siedzi między AI Agent a systemem docelowym i rozkłada każdy proces biznesowy na udokumentowane kroki decyzyjne. Każdy krok ma jasne przyporządkowanie, wersjonowany zestaw reguł i kompletny Audit Trail.

Wynik: Z eksperymentu AI staje się system produkcyjny. Taki, który Rada Zakładowa może zweryfikować, który biegły rewident zaakceptuje i który konsekwentnie funkcjonuje we wszystkich oddziałach.

## Wzorce porażek projektów AI

| Wzorzec porażki | Przyczyna | Rozwiązanie |
|---|---|---|
| Pilot działa, ale nigdy nie skaluje się | Reguły decyzyjne niezdefiniowane - nikt nie odpowiada na pytania po pilocie | Decision Layer: zdefiniować przyporządkowanie człowiek/reguły/AI na krok przed skalowaniem |
| Wysoka adopcja, ale brak mierzalnego wpływu | Inwestycje skoncentrowane na technologii, procesy i governance pominięte | Przealokować: 20% technologia, 80% procesy, governance, zarządzanie zmianą |
| Rada Zakładowa blokuje wdrożenie | Decyzje AI nieprześledzone, brak Audit Trail | Przejrzystość na poziomie architektury: wersjonowane reguły, kompletny Audit Trail |
| Agent generuje błędy, których nikt nie potrafi wyjaśnić | Decyzje czarnej skrzynki bez udokumentowanej ścieżki | Confidence Routing: progi eskalacji, Human-in-the-Loop w przypadkach granicznych |
| Różne wyniki w różnych lokalizacjach | Zestawy reguł się różnią, ale logika agenta jest jednolita | Silnik reguł uwzględniający lokalizację z wersjonowanymi, testowalnymi zestawami reguł |

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Bezpłatny eBook: AI w HR</p>
<p class="text-body text-gosign-text mb-4">Checklista EU AI Act, framework decyzyjny, perspektywa rady zakładowej i ocena gotowości - poradnik governance dla liderów HR.</p>
<a href="/pl/ebook/ai-hr-poradnik-governance/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Pobierz bezpłatnie</a>
</div>

## Podsumowanie

AI-Paradox nie jest nieuniknionym losem. Jest konsekwencją błędnej alokacji: za dużo inwestycji w technologię, za mało w reguły gry, które określają, co technologia może robić.

Firmy, które to rozumieją, nie inwestują w kolejny model językowy - inwestują w swoją architekturę decyzyjną. I dokładnie tu leży różnica między pilotem AI, który trafia do szuflady, a systemem, który działa w produkcji.

> [Decision Layer - przegląd i przykłady](/pl/decision-layer/)

> [Trzy rodzaje decyzji: Kiedy człowiek, kiedy AI](/pl/magazyn/trzy-rodzaje-decyzji/)

--- Portale Enterprise AI: pięć interfejsów w porównaniu ---
> LobeChat, OpenWebUI, LibreChat, chatbot-ui i very-ai - pięć portali enterprise AI w porównaniu. Funkcje, SSO, ochrona PII, governance, self-hosting.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">W skrócie - Portale Enterprise AI</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Sam interfejs czatu nie wystarczy - firmy potrzebują portali z SSO, Audit Trail, udostępnianiem asystentów i integracją agentów, aby zapobiec Shadow AI.</li>
<li>Pięć opcji open source do wyboru: LobeChat, OpenWebUI, LibreChat, chatbot-ui i very-ai - każda dostosowana do innych wymagań governance.</li>
<li>Wykrywanie i anonimizacja PII to kluczowy wyróżnik dla środowisk regulowanych, w których dane pracowników trafiają do promptów AI.</li>
<li>Gartner (2024) podaje, że 55% organizacji korzystających z generatywnej AI nie posiada ram governance dla jej wykorzystania.</li>
<li>Decydującym czynnikiem adopcji nie jest technologia, lecz doświadczenie użytkownika - portal wewnętrzny musi od pierwszego dnia dorównywać publicznym usługom AI lub je przewyższać.</li>
</ul>
</div>

## Problem: model bez interfejsu

Model AI bez kontrolowanego interfejsu jest jak serwer bez frontendu. Technologia jest dostępna, ale nikt nie może z niej korzystać w uporządkowany sposób. Co się potem dzieje, jest przewidywalne: pracownicy sięgają po publiczne usługi AI - ChatGPT, Gemini, Claude.ai - ze swoimi prywatnymi kontami. Wprowadzają dane firmowe do systemów poza kontrolą działu IT. Nie ma Audit Trail, nie ma klasyfikacji danych, nie ma kontroli dostępu.

To jest Shadow AI. I pytanie nie brzmi, czy to się dzieje w Twojej firmie. Pytanie brzmi, jak bardzo.

Rozwiązaniem nie jest zakaz korzystania z AI. Rozwiązaniem jest udostępnienie wewnętrznego systemu, który działa lepiej niż publiczne alternatywy - a jednocześnie pozostaje pod kontrolą firmy. Prosty interfejs czatu do tego nie wystarczy. Potrzebny jest portal enterprise AI.

## Co musi umieć portal enterprise AI

Portal enterprise AI to więcej niż okno czatu. To centralna platforma, przez którą wszyscy pracownicy wchodzą w interakcje z AI - kontrolowanie, protokołowanie i z integracją w istniejący krajobraz systemowy. Sześć wymagań odróżnia portal enterprise od czatu konsumenckiego:

### 1. Multi-Model Routing

Portal musi jednocześnie podłączać wiele modeli - własne API chmurowe i modele self-hosted. Logika routingu automatycznie decyduje, który model obsługuje które zapytanie: według typu zadania, wrażliwości danych i parametrów kosztowych. Pracownicy widzą jednolity interfejs. Który model działa w tle, jest dla nich przejrzyste, ale możliwe do prześledzenia.

### 2. Udostępnianie asystentów

Działy tworzą specjalistycznych asystentów - z własnym system promptem, własnymi dokumentami i własnym zestawem reguł. Asystent dla działu prawnego przygotowujący analizę umów. Asystent dla HR streszczający dokumenty aplikacyjne. Asystent dla zakupów porównujący oferty dostawców. Ci asystenci są udostępniani w ramach działu, wersjonowani i centralnie zarządzani.

To kluczowa różnica wobec zwykłego interfejsu czatu: nie każdy pracownik musi pisać prompty od zera. Zamiast tego korzysta z asystenta skonfigurowanego i zoptymalizowanego przez kolegów z branży. To obniża próg wejścia i podnosi jakość wyników.

### 3. Integracja agentów

Portal enterprise musi wykraczać poza czat. Musi integrować [agentów AI](/pl/uslugi/ai-agents/) - wyspecjalizowane workflow, które przetwarzają dokumenty, wydobywają dane, przygotowują decyzje lub komunikują się z zewnętrznymi systemami. Agent jest uruchamiany przez portal, jego postęp jest wyświetlany, a wynik dokumentowany w portalu.

### 4. SSO i kontrola dostępu oparta na rolach (RBAC)

Pracownicy logują się przez istniejący system zarządzania tożsamością - Azure AD, Okta, Google Workspace. Żadnych oddzielnych kont, żadnych oddzielnych haseł. Kontrola dostępu opiera się na rolach: kto może używać jakich modeli? Kto może tworzyć asystentów? Kto ma dostęp do jakich źródeł dokumentów? Kto ma dostęp do workflow agentów?

### 5. Audit Trail

Każda interakcja jest protokołowana. Kto kiedy złożył jakie zapytanie? Jaki model odpowiedział? Jakie dokumenty zostały przywołane? Jakie koszty powstały? Audit Trail jest eksportowalny - do audytu wewnętrznego, do kontroli compliance, do dokumentacji EU AI Act.

### 6. Elastyczność wdrożenia

Portal musi być wdrażalny w różnych środowiskach: jako usługa chmurowa (Supabase, Vercel), jako kontener w europejskim centrum danych lub On-Premises. Decyzja o hostingu portalu podlega tym samym kryteriom co decyzja o hostingu modeli.

## Interfejsy open source w porównaniu

Pięć projektów open source pozycjonuje się jako kandydaci na portale enterprise AI: LobeChat, OpenWebUI, LibreChat, chatbot-ui i very-ai. Wszystkie pięć są self-hosted, agnostyczne wobec modelu i oferują interfejs czatu dla modeli językowych. Różnice leżą w integracji SSO, funkcjach governance, ochronie PII i zgodności z wymogami Rady Zakładowej.

**Informacja o przejrzystości:** very-ai jest rozwijany przez Gosign GmbH - wydawcę tej serii artykułów. Przedstawiamy mocne strony i ograniczenia wszystkich pięciu portali w równym stopniu. very-ai bazuje na forku chatbot-ui (licencja MIT) i rozwinęło się w samodzielny produkt dzięki 16 rozszerzeniom enterprise.

## Porównanie: pięć portali enterprise AI

| Kryterium | LobeChat | OpenWebUI | LibreChat | chatbot-ui | very-ai |
|-----------|----------|-----------|-----------|------------|---------|
| **Licencja** | Apache 2.0 | MIT | MIT | MIT | Apache 2.0 |
| **Baza** | Projekt własny | Projekt własny | Projekt własny | Projekt własny | Fork chatbot-ui |
| **Agnostyczność modelu** | ✅ OpenAI, Anthropic, Google, Ollama | ✅ OpenAI, Ollama, LiteLLM | ✅ OpenAI, Anthropic, Google, Mistral | ✅ OpenAI, Anthropic, Google, Ollama | ✅ OpenAI, Anthropic, Google (Vertex AI), Ollama |
| **SSO** | ❌ Brak natywnego | OAuth 2.0 (brak natywnego Entra ID) | OAuth 2.0, OpenID Connect | ❌ Brak natywnego | ✅ Azure Entra ID natywnie z synchronizacją grup i uprawnień |
| **Ochrona PII** | ❌ | ❌ | ❌ | ❌ | ✅ Wykrywanie, anonimizacja i re-anonimizacja |
| **PII na asystenta/model** | - | - | - | - | ✅ Konfigurowalne na asystenta I na model |
| **Asystenci grupowi** | ❌ | Modele społecznościowe (ograniczone) | Udostępniane rozmowy | ❌ | ✅ Sterowane przez grupy Entra ID |
| **Audit Trail** | ❌ | Podstawowe logowanie | Podstawowe logowanie | ❌ | ✅ Kompletny, eksportowalny (CSV/JSON) |
| **Statystyki RODO** | ❌ | ❌ | ❌ | ❌ | ✅ Zanonimizowane statystyki użytkowania |
| **Integracja Trigger.dev** | ❌ | ❌ | ❌ | ❌ | ✅ Wyzwalanie workflow z czatu |
| **Thinking Level** | ❌ | ❌ | ❌ | ❌ | ✅ Extended Thinking / sterowanie reasoning |
| **Wyszukiwanie Web/Maps** | System pluginów | Wyszukiwanie web (RAG) | System pluginów | ❌ | ✅ Zintegrowane |
| **Docker Self-Hosted** | ✅ | ✅ | ✅ | ✅ | ✅ |
| **GitHub Stars (lut 2026)** | ~50k | ~60k | ~20k | ~28k | Nowy (premiera open source) |
| **Zgodność z Radą Zakładową** | ⚠️ Ograniczona (brak audytu, brak RBAC) | ⚠️ Podstawowe RBAC | ⚠️ Podstawowe RBAC | ❌ Brak governance | ✅ Audit Trail + RBAC + PII + Entra ID |

### LobeChat

LobeChat to wizualnie atrakcyjny interfejs czatu z architekturą pluginów. Siła leży w użyciu konsumenckim i różnorodności pluginów. Dla enterprise brakuje solidnego RBAC, eksportowalnego Audit Trail i natywnej integracji agentów. Odpowiedni jako szybki prototyp lub dla małych zespołów, za ograniczony do wdrożenia w całej organizacji.

### OpenWebUI

OpenWebUI to de facto standard dla konfiguracji self-hosted opartych na Ollama. Integracja z lokalnie działającymi modelami jest doskonała. SSO i podstawowe logowanie są dostępne. Czego brakuje: udostępniania asystentów, integracji agentów enterprise i centralnego zarządzania dla kilkuset użytkowników.

### LibreChat

LibreChat to open-source-owy klon interfejsu ChatGPT z obsługą wielu modeli. SSO i podstawowe RBAC są zaimplementowane. Dla firm, które chcą odwzorować doświadczenie ChatGPT wewnętrznie, LibreChat to solidny punkt wyjścia. Ograniczenia leżą w integracji agentów i udostępnianiu asystentów.

## very-ai - portal enterprise z ochroną PII i governance

very-ai to portal enterprise AI oparty na chatbot-ui (MIT), który dodaje 16 funkcji enterprise niedostępnych w żadnym z czterech pozostałych portali. Jest rozwijany przez Gosign GmbH i dostępny na licencji Apache 2.0 na GitHub.

**Pochodzenie i wyróżnienie:**
chatbot-ui dostarcza solidny interfejs czatu, ale nie ma integracji SSO, Audit Trail ani ochrony PII. very-ai adresuje dokładnie te braki: baza kodu została rozszerzona o funkcje enterprise niezbędne do produkcyjnego użycia w regulowanych środowiskach. Atrybucja do projektu źródłowego jest udokumentowana w pliku NOTICES.

**Wykrywanie i re-anonimizacja PII:**
Centralne wyróżnienie. very-ai rozpoznaje dane osobowe (imiona, adresy e-mail, numery telefonów, IBAN-y) w promptach użytkowników, zastępuje je symbolami zastępczymi ([PERSON_1], [EMAIL_1]), wysyła zanonimizowany tekst do modelu językowego i wstawia oryginalne dane z powrotem do odpowiedzi. Użytkownik widzi prawdziwe imiona, model językowy nigdy ich nie widział.

To zachowanie PII jest konfigurowalne na asystenta i na model: Asystent A może dopuszczać PII, Asystent B anonimizuje automatycznie. Model X otrzymuje zanonimizowane dane, Model Y (model hostowany lokalnie) otrzymuje dane surowe.

**Azure Entra ID z synchronizacją grup:**
Nie tylko uwierzytelnianie, ale automatyczna synchronizacja grup i ról Entra ID. Pracownicy w grupie Entra ID "HR" automatycznie widzą asystentów HR. Pracownicy w "Finanse" widzą asystentów Finansów. Bez ręcznego przydzielania uprawnień w portalu. Gdy zmienia się przynależność do grupy w Entra ID, zmienia się dostęp w portalu przy następnym logowaniu.

**Asystenci grupowi:**
Administratorzy tworzą asystentów i przypisują ich do grup Entra ID. Ci asystenci są widoczni i używalni tylko przez członków danej grupy. To umożliwia narzędzia AI specyficzne dla działu bez oddzielnego zarządzania uprawnieniami.

**Audit Trail i statystyki RODO:**
Każda interakcja jest protokołowana: użytkownik, model, asystent, prompt, odpowiedź, znacznik czasu, zużycie tokenów, tryb PII. Audit Trail jest eksportowalny (CSV, JSON) i filtrowalny według okresu i użytkownika. Statystyki użytkowania są zanonimizowane zgodnie z RODO - pokazują użycie modeli i asystentów, ale nie dane identyfikujące użytkowników.

**Integracja workflow Trigger.dev:**
Użytkownicy mogą z czatu wyzwalać workflow Trigger.dev. To łączy portal AI z warstwą automatyzacji.

**Ograniczenia (uczciwie):**
very-ai to nowy projekt open source. Społeczność jest mała w porównaniu z LobeChat (50k gwiazdek) czy OpenWebUI (60k gwiazdek). Ekosystemy pluginów ustalonych portali są obszerniejsze. Kto szuka portalu z maksymalnym wsparciem społeczności i różnorodnością pluginów, będzie lepiej obsłużony przez LobeChat lub OpenWebUI. Kto potrzebuje ochrony PII, synchronizacji grup Entra ID i logowania zgodnego z wymogami Rady Zakładowej, znajdzie tę kombinację obecnie tylko w very-ai.

Demo na żywo: [veryai.de](https://www.veryai.de/)

### Który portal do jakiego zastosowania?

**Maksymalna różnorodność modeli i ekosystem pluginów:** LobeChat - największy system pluginów, najaktywniejsza społeczność, szeroka obsługa modeli. Idealny dla zespołów priorytetyzujących elastyczność i szybką innowację.

**Najłatwiejszy start z Ollama:** OpenWebUI - natywna integracja Ollama, szybka instalacja, intuicyjny interfejs. Idealny do lokalnego hostingu LLM i zespołów rozpoczynających od modeli open source.

**Maksymalna konfigurowalność:** LibreChat - najdokładniejsza kontrola nad endpointami i parametrami modeli. Idealny dla zespołów technicznych obsługujących wielu dostawców z różnymi konfiguracjami.

**Enterprise governance z ochroną PII:** very-ai - jedyna opcja z natywną anonimizacją PII, synchronizacją grup Entra ID i kompletnym Audit Trail. Idealny dla środowisk regulowanych, w których Rada Zakładowa, ochrona danych i compliance wymagają przejrzystości.

**Projekt ewaluacyjny i rozwój:** chatbot-ui - czysta baza kodu, dobry punkt wyjścia do własnych rozwinięć. Uwaga: chatbot-ui nie ma aktywnego rozwoju enterprise; very-ai jest wersją enterprise tej bazy kodu.

*Większość firm ewaluuje 2-3 portale równolegle w kontenerach Docker - to możliwe w jedno popołudnie. Decydujące nie jest interface, lecz zdolność governance: SSO, Audit Trail, ochrona PII i zgodność z Radą Zakładową określają, który portal trafia do produkcji.*

## Dlaczego "tylko czat" nie wystarczy

Różnica między interfejsem czatu a portalem enterprise AI staje się widoczna w eksploatacji. Porównanie:

| Aspekt | Interfejs czatu | Portal enterprise AI |
|---|---|---|
| Użycie | Indywidualne pytanie-odpowiedź | Narzędzie ogólnoorganizacyjne |
| Wiedza | Każdy użytkownik zaczyna od zera | Asystenci skupiają wiedzę fachową |
| Kontrola | Użytkownik decyduje, co wpisuje | Routing i RBAC sterują przepływem danych |
| Przejrzystość | Brak lub ograniczona | Kompletny Audit Trail |
| Integracja | Samodzielny | Połączony z SSO, agentami, systemami dokumentów |
| Skalowanie | Na użytkownika | Na organizację |
| Ryzyko Shadow AI | Wysokie (niewystarczająca oferta wewnętrzna) | Niskie (lepsza oferta wewnętrzna) |

Centralne spostrzeżenie: Shadow AI nie powstaje dlatego, że pracownicy mają złe intencje. Powstaje dlatego, że oferta wewnętrzna jest gorsza od publicznej alternatywy. Gdy portal wewnętrzny jest tak intuicyjny jak ChatGPT, ale dodatkowo oferuje specjalistycznych asystentów, dostęp do dokumentów firmowych i workflow agentów, nie ma powodu, by sięgać po usługi zewnętrzne.

## Praktyka: firma średniej wielkości z 2000 pracowników

Konkretny przykład pokazuje efekt. Firma produkcyjna z 2000 pracowników miała następującą sytuację wyjściową:

**Przed portalem:** Wewnętrzna ankieta wykazała, że 340 pracowników regularnie korzystało z publicznych usług AI do zadań służbowych. Z tego 180 z darmowymi kontami (bez umowy o powierzenie przetwarzania danych), 120 z prywatnymi kontami Pro (dane firmowe na prywatnych kontach) i 40 z kontami udostępnionymi przez firmę (ale bez Audit Trail czy kontroli dostępu). Dział IT nie miał wglądu w to, jakie dane trafiają do jakich systemów.

**Wdrożenie portalu enterprise AI:** W cztery tygodnie wdrożono very-ai - z podłączeniem do Azure AD jako SSO, trzema początkowymi asystentami (dział prawny, HR, zakupy) i endpointem gpt-oss-120b dla danych poufnych.

**Po 90 dniach:**

- 15 specjalistycznych asystentów stworzonych przez działy
- 1200 aktywnych użytkowników miesięcznie (z 2000 pracowników)
- Wykorzystanie Shadow AI spadło o 85% (ankieta kontrolna)
- Kompletny Audit Trail: 47 000 zaprotokołowanych interakcji
- Identyfikacja trzech procesów, dla których dedykowane workflow agentów miały sens
- Całkowite koszty (portal + hosting + API chmurowe): ok. 4800 EUR miesięcznie

Decydującym czynnikiem nie była technologia, lecz adopcja. Portal został przyjęty, bo był lepszy od alternatywy - nie dlatego, że został nakazany.

## Pięć czynników sukcesu przy wdrażaniu

Z praktyki można wyprowadzić pięć czynników decydujących o sukcesie lub porażce portalu enterprise AI:

**1. Pierwsze wrażenie się liczy.** Jeśli portal wewnętrzny jest wolniejszy, bardziej uciążliwy lub mniej wydajny niż ChatGPT, pracownicy nie użyją go ponownie po pierwszej próbie. Jakość odpowiedzi musi od pierwszego dnia odpowiadać poziomowi publicznych usług.

**2. Asystenci zamiast promptów.** Większość pracowników nie jest inżynierami promptów. Chcą używać narzędzia, nie konfigurować go. Specjalistyczni asystenci przygotowani przez kolegów z branży znacząco obniżają próg wejścia.

**3. Widoczna wartość dodana.** Portal musi oferować coś, czego publiczne usługi nie potrafią: dostęp do wewnętrznych dokumentów (przez RAG), specjalistyczni asystenci do zadań specyficznych dla firmy, integracja z istniejącymi workflow.

**4. Własność IT, nie kontrola IT.** Dział IT obsługuje portal i ustala reguły governance. Ale działy tworzą swoich asystentów samodzielnie. Ten podział - infrastruktura centralnie, treści decentralnie - okazał się najskuteczniejszym modelem.

**5. Mierzyć i komunikować.** Liczby użytkowania, zaoszczędzony czas, zredukowane Shadow AI - te wskaźniki muszą być zbierane i komunikowane do zarządu. Bez mierzalnych wyników brakuje podstawy do następnego etapu rozwoju.

## Następny krok: od portalu do agenta

Portal enterprise AI to fundament. Daje pracownikom dostęp do AI - kontrolowany i protokołowany. Następny krok to integracja agentów - wyspecjalizowanych workflow wykraczających poza proste interakcje pytanie-odpowiedź.

---

Dalsze lektury: [Infrastruktura AI](/pl/uslugi/infrastruktura/) | [Decision Layer i Shadow AI](/pl/magazyn/decision-layer-shadow-ai/)

---

very-ai to portal enterprise AI open source od Gosign. [Dowiedz się więcej](/pl/uslugi/infrastruktura/) - lub porozmawiaj z nami, jaka konfiguracja pasuje do Twojej organizacji.

<a href="/pl/kontakt/" target="_blank" rel="noopener noreferrer">Umów spotkanie</a> - Pokażemy Ci very-ai w demonstracji na żywo i omówimy Twój plan wdrożenia.

--- EU AI Act 2026: Status, terminy, co zrobić teraz ---
> EU AI Act 2026: zakazy aktywne, obowiązek AI Literacy, obowiązujący deadline High-Risk 2 sierpnia 2026 (wstępnie uzgodnione przesunięcie na grudzień 2027 - Digital Omnibus, maj 2026). Harmonogram, obowiązki i rekomendacje.

EU AI Act obowiązuje. Dwa terminy już upłynęły, krytyczny deadline High-Risk nadchodzi za sześć miesięcy. Oto aktualny stan, obowiązki i co firmy muszą zrobić teraz.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">W skrócie - EU AI Act 2026: status dla firm</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Zakazane praktyki AI (Social Scoring, manipulacja, rozpoznawanie emocji w pracy) oraz obowiązek AI Literacy są prawnie wiążące od lutego 2025.</li>
<li>Obowiązki transparentności i dokumentacji GPAI dla operatorów modeli General-Purpose AI obowiązują od sierpnia 2025.</li>
<li>Krytyczny termin: wszystkie systemy AI wysokiego ryzyka (w tym niemal cała AI w HR) muszą być w pełni zgodne do 2 sierpnia 2026. Kary: do 15 mln euro lub 3% globalnego obrotu.</li>
<li>Klasyfikacja wysokiego ryzyka pozostaje w mocy. Zgodnie z obowiązującym prawem deadline High-Risk to 2 sierpnia 2026, ale na mocy wstępnego porozumienia politycznego pakietu Digital Omnibus z 7 maja 2026 r. ma zostać przesunięty na 2 grudnia 2027 r. Formalne przyjęcie i publikacja w Dzienniku Urzędowym UE są jeszcze w toku (stan na czerwiec 2026) - czas warto wykorzystać na przygotowanie.</li>
<li>Pierwszy krok dla każdej firmy: pełna inwentaryzacja systemów AI obejmująca wszystkie oficjalnie wdrożone i Shadow AI w ciągu czterech do ośmiu tygodni.</li>
</ul>
</div>

Według Gartner (2025), mniej niż 10% organizacji objętych EU AI Act ukończyło inwentaryzację systemów AI - podstawowy krok do zgodności. Komisja Europejska szacuje, że ponad 300 000 przedsiębiorstw w UE wdraża systemy AI, które mogą podlegać zakresowi regulacji.

<table>
<thead>
<tr><th>Kamień milowy</th><th>Data</th><th>Status</th><th>Główne obowiązki</th></tr>
</thead>
<tbody>
<tr><td>Wejście w życie</td><td>Sierpień 2024</td><td>Aktywne</td><td>Ustanowienie ram prawnych</td></tr>
<tr><td>Zakazane praktyki + AI Literacy</td><td>Luty 2025</td><td>Aktywne</td><td>Zakaz Social Scoring, manipulacji; obowiązek szkoleniowy</td></tr>
<tr><td>Obowiązki GPAI</td><td>Sierpień 2025</td><td>Aktywne</td><td>Transparentność, oznaczanie, inwentaryzacja governance</td></tr>
<tr><td>Systemy High-Risk</td><td>Sierpień 2026</td><td>Za 6 miesięcy</td><td>Pełna zgodność: zarządzanie ryzykiem, governance danych, Human Oversight</td></tr>
<tr><td>Pozostałe przepisy</td><td>Sierpień 2027</td><td>2027</td><td>Reguły branżowe, pozostałe kategorie</td></tr>
</tbody>
</table>

## Pierwsze kompleksowe prawo o AI na świecie

EU AI Act obowiązuje od sierpnia 2024. To pierwsze na świecie kompleksowe prawo regulujące sztuczną inteligencję i dotyczy każdej firmy, która rozwija, wdraża lub udostępnia systemy AI. W lutym 2026 jesteśmy w środku fazy wdrażania: dwa terminy już upłynęły, następny nadchodzi za sześć miesięcy. Kto się nie przygotował, ma problem. Kto zaczyna przygotowania teraz, jeszcze ma czas.

Dla polskich firm jest to szczególnie istotne: w przeciwieństwie do RODO, które było wdrażane stopniowo, EU AI Act wprowadza precyzyjne kategorie ryzyka i konkretne terminy. Ten artykuł daje rzeczowy przegląd aktualnego stanu: co już obowiązuje, co nadchodzi i kiedy, jakie obowiązki dotyczą Twojej firmy i co powinieneś zrobić w ciągu najbliższych 90 dni.

## Harmonogram: Pięć kamieni milowych

Stopniowe wdrażanie EU AI Act rozciąga się na trzy lata. Każdy kamień milowy aktywuje inne obowiązki.

```
Sierpień 2024        Luty 2025            Sierpień 2025       Sierpień 2026        Sierpień 2027
|                    |                    |                   |                    |
v                    v                    v                   v                    v
Wejście w życie    Zakazane praktyki    Obowiązki GPAI      Systemy High-Risk    Pozostałe
AI + AI Literacy     obowiązują          muszą być            przepisy
zgodne
AKTYWNE              AKTYWNE             ZA 6 MIESIĘCY        2027
```

Dla firm oznacza to: Dwa etapy są już prawnie wiążące. Trzeci, dla wielu firm najkrytyczniejszy, etap wchodzi w życie za sześć miesięcy. Przygotowanie do niego wymaga typowo od czterech do sześciu miesięcy. Czasu jest mało.

## Co już obowiązuje

### Zakazane praktyki AI (od lutego 2025)

Od 2 lutego 2025 określone zastosowania AI są w UE całkowicie zakazane. Dotyczy to:

- **Social Scoring:** Systemy AI oceniające osoby na podstawie ich zachowań społecznych i wyciągające z tego niekorzystne konsekwencje w niezwiązanych kontekstach.
- **Manipulacyjna AI:** Systemy manipulujące zachowaniem ludzkim przez techniki podprogowe, takie jak dark patterns wymuszające decyzje zakupowe lub zgody.
- **Biometria w czasie rzeczywistym w przestrzeni publicznej:** Identyfikacja biometryczna w czasie rzeczywistym jest zasadniczo zakazana. Wąskie wyjątki istnieją dla organów ścigania przy ciężkich przestępstwach, zwalczaniu terroryzmu i poszukiwaniu osób zaginionych, każdy z autoryzacją sądową.
- **Rozpoznawanie emocji w miejscu pracy i placówkach edukacyjnych:** Systemy AI rozpoznające emocje pracowników lub uczniów są niedopuszczalne.
- **Predictive Policing na podstawie cech indywidualnych:** Oceny ryzyka przestępczości oparte wyłącznie na cechach osobistych.

**Sankcje:** Naruszenia zakazów są karane grzywną do 35 milionów euro lub 7 procent globalnego rocznego obrotu, w zależności od tego, która kwota jest wyższa.

Dla większości polskich firm te zakazy nie wymagają bezpośrednich działań, ponieważ opisane zastosowania rzadko występują w kontekście biznesowym. Ale weryfikacja jest obowiązkowa: upewnij się, że żaden z Twoich systemów AI nie podlega tym kategoriom.

### AI Literacy (od lutego 2025)

Równolegle z zakazami od lutego 2025 obowiązuje obowiązek AI Literacy zgodnie z Artykułem 4: Wszystkie osoby, które obsługują, wdrażają lub korzystają z systemów AI, muszą dysponować odpowiednim poziomem kompetencji AI. Kompetencja musi być adekwatna do kontekstu - programista potrzebuje głębszej wiedzy niż użytkownik końcowy korzystający z chatbota.

Co to oznacza konkretnie:

- **Obowiązek szkoleniowy:** Firmy muszą być w stanie udowodnić, że ich pracownicy zostali przeszkoleni.
- **Obowiązek dokumentacyjny:** Treści szkoleniowe, listy uczestników i interwały odświeżania muszą być udokumentowane.
- **Adekwatność kontekstowa:** Szkolenie musi odpowiadać roli. Ogólny e-learning nie wystarczy dla decydentów, którzy wybierają i odpowiadają za systemy AI.

Obowiązek AI Literacy jest często niedoceniany, bo nie stawia wysokich wymagań technicznych. Ale już jest egzekwowalny. I dotyczy każdej firmy korzystającej z AI, niezależnie od klasy ryzyka systemu.

### Obowiązki GPAI (od sierpnia 2025)

Od sierpnia 2025 obowiązują obowiązki przejrzystości i dokumentacji dla modeli General-Purpose AI (GPAI). Dotyczą one przede wszystkim dostawców modeli językowych, nie firm, które z nich korzystają. Ale jako deployer - firma stosująca model GPAI we własnych aplikacjach - masz obowiązki:

- **Oznaczenia użycia:** Jeśli Twoja aplikacja generuje treści, które mogą być mylnie uznane za stworzone przez człowieka, musisz to oznaczyć.
- **Przejrzystość wobec użytkowników:** Osoby wchodzące w interakcje z systemem AI muszą być o tym informowane.
- **Infrastruktura governance:** Musisz być w stanie udokumentować, jakie modele GPAI stosujesz, w jakim kontekście i z jakimi środkami ochrony.

Obowiązki GPAI wymagają rzetelnej inwentaryzacji: Jakie modele AI stosujesz? Od jakiego dostawcy? W jakiej aplikacji? Z jaką klasyfikacją ryzyka? Te informacje stanowią fundament pod zgodność High-Risk, która wchodzi w życie za sześć miesięcy.

## Co nadchodzi za sześć miesięcy: Systemy High-Risk (sierpień 2026)

Obowiązujący deadline High-Risk to 2 sierpnia 2026 r. - dla większości firm najkrytyczniejszy termin EU AI Act. Od tej daty wszystkie systemy AI podlegające Załącznikowi III muszą być w pełni zgodne (z zastrzeżeniem wstępnie uzgodnionego przesunięcia na 2 grudnia 2027 r. - Digital Omnibus, maj 2026, przyjęcie w toku). Wymagania są rozległe i niezależne od daty granicznej.

### Jakie systemy podlegają High Risk?

Załącznik III EU AI Act definiuje osiem obszarów, w których systemy AI są klasyfikowane jako wysokiego ryzyka. Najistotniejsze dla firm:

- **Zatrudnienie, zarządzanie personelem i dostęp do samozatrudnienia:** Systemy AI do ogłoszeń o pracę, selekcji kandydatów, oceny wydajności, decyzji o awansach i zwolnieniach.
- **Zdolność kredytowa i ubezpieczenia:** Automatyczna ocena wiarygodności kredytowej, scoring ryzyka.
- **Identyfikacja biometryczna:** Rozpoznawanie twarzy, identyfikacja głosu, również w przestrzeni niepublicznej.
- **Infrastruktura krytyczna:** Systemy AI w energetyce, gospodarce wodnej, transporcie, telekomunikacji.
- **Edukacja i szkolenia zawodowe:** Automatyczna ocena egzaminów, kontrola dostępu do placówek edukacyjnych.

### Wymagania wobec systemów High-Risk

Jeśli jeden z Twoich systemów AI został zaklasyfikowany jako High Risk, musisz do sierpnia 2026 spełnić następujące wymagania:

1. **System zarządzania ryzykiem:** Udokumentowany system identyfikacji, analizy i minimalizacji ryzyk w całym cyklu życia systemu AI.
2. **Governance danych:** Wymagania dotyczące jakości, reprezentatywności i bezbłędności danych treningowych. Przy użyciu modeli pretrenowanych: dokumentacja pochodzenia danych i dostrojenia.
3. **Dokumentacja techniczna:** Kompleksowa dokumentacja systemu przed wdrożeniem: architektura, procedury treningowe, metryki wydajności, procedury testowe, ograniczenia.
4. **Obowiązki rejestrowania:** Automatyczne protokołowanie wszystkich istotnych zdarzeń (logging), aby zapewnić odtwarzalność decyzji.
5. **Przejrzystość:** Instrukcje użytkowania dla deployerów umożliwiające prawidłowe użycie.
6. **Nadzór ludzki (Human Oversight):** Środki techniczne umożliwiające skuteczny nadzór przez człowieka. [Decision Layer](/pl/decision-layer/) to architektura, która technicznie realizuje właśnie to wymaganie.
7. **Dokładność, odporność, cyberbezpieczeństwo:** System musi niezawodnie osiągać zadeklarowaną wydajność i być chroniony przed manipulacją.
8. **Ocena zgodności:** Dla określonych kategorii wymagana jest ocena przez jednostkę notyfikowaną (Conformity Assessment Body). Dla innych wystarcza samoocena.

**Sankcje:** Naruszenia obowiązków High-Risk są karane grzywną do 15 milionów euro lub 3 procent globalnego rocznego obrotu.

## Szczególne znaczenie dla HR

Obszar HR to dział firmy, w którym aplikacje AI najczęściej podlegają kategorii High-Risk. Wynika to z Załącznika III, pkt 4 - Zatrudnienie i zarządzanie personelem. Klasyfikacja obejmuje:

**Automatyczne screenowanie aplikacji: High Risk.** Każdy system AI, który wstępnie sortuje, ocenia lub filtruje aplikacje o pracę, podlega kategorii High-Risk. Niezależnie od tego, czy finalną decyzję podejmuje człowiek. Już sama preselekcja jest regulowana.

**Oceny wydajności wspierane przez AI: High Risk.** Gdy systemy AI analizują dane o wydajności i na ich podstawie wystawiają oceny lub przygotowują oceny, to jest High Risk. Dotyczy to także systemów, które wydają jedynie rekomendacje.

**Predictive Attrition: High Risk.** Systemy AI przewidujące, którzy pracownicy prawdopodobnie odejdą z firmy, przetwarzają dane osobowe w celu podejmowania decyzji zatrudnieniowych. To jest High Risk.

**Automatyczna optymalizacja grafiku: potencjalnie High Risk.** Jeśli system AI tworzy grafiki zmian i przy tym przetwarza indywidualne preferencje, dane o wydajności lub informacje zdrowotne, może podlegać High Risk. Klasyfikacja zależy od konkretnego zakresu danych.

Dla działów HR oznacza to: Zinwentaryzuj wszystkie systemy AI stosowane w kontekstach zatrudnieniowych. Sprawdź klasyfikację. Rozpocznij przygotowania do zgodności. Obowiązującym terminem jest 2 sierpnia 2026 r.; nawet jeśli wstępnie uzgodnione przesunięcie na grudzień 2027 r. (Digital Omnibus) wejdzie w życie, budowa pełnej zgodności High-Risk trwa miesiącami - dodatkowy czas to margines na rzetelną pracę, nie na zwłokę. Więcej informacji o współdziałaniu AI i HR znajdziesz pod adresem [HR & AI Agents](/pl/hr-ai-agents/).

## Digital Omnibus: Przesunięcie wstępnie uzgodnione

Komisja Europejska zaproponowała pod koniec 2025 pakiet Digital Omnibus, który może między innymi przesunąć terminy High-Risk EU AI Act na maksymalnie grudzień 2027. Pakiet adresuje również uproszczenie obowiązków sprawozdawczych i podniesienie progów dla MŚP. Przesunięcie jest warunkowe: wchodzi w życie dopiero po udostępnieniu norm zharmonizowanych. Następnie obowiązuje sześć miesięcy okresu przejściowego dla systemów z Załącznika III i dwanaście miesięcy dla systemów z Załącznika I. Ostateczny termin graniczny to 2 grudnia 2027.

**Aktualny stan (czerwiec 2026):** 7 maja 2026 r. Rada i Parlament Europejski osiągnęły wstępne porozumienie polityczne o przesunięciu deadline'u High-Risk z 2 sierpnia 2026 r. na 2 grudnia 2027 r. To wstępne porozumienie - nie ostateczne prawo. Formalne przyjęcie przez obie instytucje i publikacja w Dzienniku Urzędowym UE są jeszcze w toku; oczekuje się ich przed 2 sierpnia 2026 r. Dopóki publikacja nie nastąpi, obowiązującym terminem prawnym pozostaje 2 sierpnia 2026 r.

**Rekomendacja:** Klasyfikacja wysokiego ryzyka pozostaje w mocy niezależnie od terminu - to się nie zmienia. Obowiązującym prawem jest deadline 2 sierpnia 2026 r., a wstępnie uzgodnione przesunięcie na 2 grudnia 2027 r. najprawdopodobniej da firmom dodatkowy czas. Potraktuj go jako realny zysk czasowy na rzetelne przygotowanie, a nie jako pretekst do zwłoki: decyzje architektoniczne (governance, nadzór człowieka, audit trail) i tak trzeba podjąć teraz, bo ich wdrożenie trwa miesiącami niezależnie od daty granicznej.

## Praktyczna rekomendacja: Rozpocznij inwentaryzację systemów AI

Niezależnie od tego, czy Twoje systemy AI podlegają High Risk, czy nie: pierwszy krok jest zawsze taki sam. Potrzebujesz kompletnej inwentaryzacji wszystkich systemów AI w firmie.

### Co należy udokumentować

Dla każdego systemu AI dokumentujesz:

- **Nazwa i opis systemu:** Co robi system? Jaki proces wspiera?
- **Dostawca i model:** Jaki model AI jest stosowany? Od jakiego dostawcy? Cloud API czy self-hosted?
- **Rola Twojej firmy:** Jesteś dostawcą (provider), operatorem (deployer) czy jednym i drugim?
- **Klasyfikacja ryzyka:** Czy system podlega jednej z kategorii Załącznika III (High Risk)? Zakazom z Artykułu 5? Czy jest to system o ograniczonym ryzyku?
- **Osoby, których dotyczy:** Na jakie osoby wpływają decyzje lub wyniki systemu?
- **Przetwarzanie danych:** Jakie dane przetwarza system? Dane osobowe? Tajemnice handlowe?
- **Środki ochrony:** Jakie środki techniczne i organizacyjne są wdrożone? Human Oversight? Audit Trail?

### Harmonogram

Inwentaryzację systemów AI dla średniej firmy można wykonać w cztery do ośmiu tygodni. Nakład pracy zależy od liczby systemów, stanu dokumentacji i koordynacji wewnętrznej. Zacznij od oczywistych systemów - oficjalnie zakupionych narzędzi AI - a następnie rozszerz na [Shadow AI](/pl/magazyn/decision-layer-shadow-ai/): systemy AI, które pracownicy używają samodzielnie, bez wiedzy działu IT.

Inwentaryzacja to nie zadanie jednorazowe. Musi być aktualizowana na bieżąco, ponieważ pojawiają się nowe systemy, istniejące systemy są modyfikowane, a ocena regulacyjna ewoluuje. [Infrastruktura governance](/pl/governance/) musi być zbudowana tak, aby inwentaryzacja pozostawała żywym dokumentem.

## Podsumowanie: Co powinieneś zrobić teraz

1. **Sprawdź zakazy.** Upewnij się, że żaden z Twoich systemów AI nie podlega praktykom zakazanym od lutego 2025.
2. **Spełnij obowiązek AI Literacy.** Udokumentuj szkolenia dla wszystkich użytkowników AI w firmie. Obowiązek obowiązuje już teraz.
3. **Stwórz inwentaryzację systemów AI.** Zarejestruj wszystkie systemy AI, ich dostawców, kontekst zastosowania i klasyfikację ryzyka. Ramy czasowe: cztery do ośmiu tygodni.
4. **Zidentyfikuj systemy High-Risk.** Sprawdź szczególnie obszar HR, decyzje kredytowe i zautomatyzowane procesy bezpośrednio wpływające na osoby.
5. **Rozpocznij zgodność High-Risk.** Dla systemów podlegających Załącznikowi III: zbuduj system zarządzania ryzykiem, governance danych, dokumentację techniczną i Human Oversight. Obowiązujący deadline: 2 sierpnia 2026 r. (z zastrzeżeniem wstępnie uzgodnionego przesunięcia na grudzień 2027 r.).
6. **Zaplanuj z myślą o obu terminach.** Obowiązującym prawem jest deadline 2 sierpnia 2026 r.; przesunięcie na 2 grudnia 2027 r. zostało wstępnie uzgodnione 7 maja 2026 r. (Digital Omnibus), a jego formalne przyjęcie jest w toku. Klasyfikacja wysokiego ryzyka nie zmienia się w żadnym wariancie - wykorzystaj prawdopodobny dodatkowy czas na rzetelne przygotowanie, nie na zwłokę.

---

Gosign towarzyszy firmom w drodze do zgodności z EU AI Act - od inwentaryzacji systemów po ocenę zgodności. Jeśli chcesz wiedzieć, gdzie stoi Twoja firma, porozmawiaj z nami.

<a href="/pl/kontakt/" target="_blank" rel="noopener noreferrer">Umów spotkanie</a>. 30 minut, w których ocenimy Twój status zgodności.

--- EU AI Act i HR: Co od sierpnia 2026 obowiązuje dla AI w HR ---
> AI w HR to system wysokiego ryzyka wg EU AI Act. Co to oznacza, jakie obowiązki obowiązują i jak Decision Layer spełnia wymagania architektonicznie.

EU AI Act klasyfikuje niemal każdy system AI stosowany w procesach HR jako system wysokiego ryzyka. Zgodnie z obowiązującym prawem od 2 sierpnia 2026 r. systemy te muszą spełniać rygorystyczne wymagania dotyczące zarządzania ryzykiem, transparentności i nadzoru ludzkiego (wstępnie uzgodnione przesunięcie na grudzień 2027 r. - Digital Omnibus, maj 2026, przyjęcie w toku).

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">W skrócie - AI w HR to system wysokiego ryzyka wg EU AI Act</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Systemy AI do rekrutacji, ocen pracowniczych, awansów i zwolnień są klasyfikowane jako wysokiego ryzyka zgodnie z Załącznikiem III, nr 4 EU AI Act.</li>
<li>Zakazane praktyki AI (Social Scoring, manipulacja) obowiązują od 2 lutego 2025 r. Obowiązujący termin pełnych obowiązków dla systemów wysokiego ryzyka to 2 sierpnia 2026 r.; na mocy wstępnego porozumienia Digital Omnibus z maja 2026 r. ma zostać przesunięty na 2 grudnia 2027 r. (przyjęcie w toku).</li>
<li>Sześć obowiązkowych wymagań: zarządzanie ryzykiem, governance danych, obowiązki rejestrowania, transparentność, nadzór ludzki oraz dokładność/odporność.</li>
<li>Decision Layer odwzorowuje każde wymaganie architektonicznie: Confidence Routing dla ryzyka, wersjonowane zestawy reguł dla governance danych, Audit Trail dla rejestracji, Human-in-the-Loop dla nadzoru.</li>
<li>Kary do 15 milionów euro lub 3% globalnego rocznego obrotu za naruszenia obowiązków dotyczących systemów wysokiego ryzyka (art. 99 ust. 4) - do 35 milionów euro lub 7% za zakazane praktyki AI (art. 5).</li>
</ul>
</div>

Według badania PwC (2024), tylko 24% przedsiębiorstw stosujących AI w procesach HR rozpoczęło formalne przygotowania do zgodności z EU AI Act - mimo obowiązującego deadline'u 2 sierpnia 2026 r. dla systemów wysokiego ryzyka (wstępnie uzgodnione przesunięcie na grudzień 2027 r. - Digital Omnibus, maj 2026).

<table>
<thead>
<tr><th>Artykuł EU AI Act</th><th>Wymaganie</th><th>Implementacja w Decision Layer</th></tr>
</thead>
<tbody>
<tr><td>Art. 9</td><td>System zarządzania ryzykiem</td><td>Confidence Routing z konfigurowalnymi progami</td></tr>
<tr><td>Art. 10</td><td>Governance danych</td><td>Wersjonowane zestawy reguł z datami ważności</td></tr>
<tr><td>Art. 12</td><td>Obowiązki rejestrowania</td><td>Niezmienny Audit Trail na decyzję</td></tr>
<tr><td>Art. 13</td><td>Transparentność</td><td>Portal Audytora z pełną ścieżką decyzyjną</td></tr>
<tr><td>Art. 14</td><td>Nadzór ludzki</td><td>Wymuszony Human-in-the-Loop dla określonych typów</td></tr>
<tr><td>Art. 15</td><td>Dokładność i odporność</td><td>Monitoring biasu i design model-agnostyczny</td></tr>
<tr><td>Art. 86</td><td>Prawo do wyjaśnienia pojedynczej decyzji</td><td>Akt decyzyjny na każdą mikrodecyzję ze ścieżką podważenia</td></tr>
</tbody>
</table>

## Klasyfikacja: AI w HR to system wysokiego ryzyka

EU AI Act klasyfikuje systemy AI stosowane w zatrudnieniu, zarządzaniu pracownikami i dostępie do samozatrudnienia jako systemy wysokiego ryzyka (Załącznik III, nr 4). Dotyczy to konkretnie:

Systemów AI do rekrutacji i selekcji kandydatów. Systemów AI wpływających na awanse, zwolnienia, przydzielanie zadań lub monitorowanie wydajności. Systemów AI wpływających na warunki pracy, w tym dostosowania wynagrodzeń, zaszeregowania i planowanie zmian.

Krótko: niemal każdy agent AI, który przygotowuje, wspiera lub podejmuje decyzje w procesach HR, podlega kategorii wysokiego ryzyka.

## Terminy

Od 2 lutego 2025 r. obowiązują zakazy niedopuszczalnych praktyk AI, w tym social scoringu i technik manipulacyjnych. Zgodnie z obowiązującym prawem pełne obowiązki dla systemów AI wysokiego ryzyka wchodzą w życie 2 sierpnia 2026 r., jednak na mocy wstępnego porozumienia Digital Omnibus z 7 maja 2026 r. mają zostać przesunięte na 2 grudnia 2027 r. (formalne przyjęcie wciąż w toku, stan na czerwiec 2026 r.). Klasyfikacja wysokiego ryzyka pozostaje w mocy niezależnie od terminu, a budowa struktur governance trwa miesiącami - prawdopodobny dodatkowy czas warto wykorzystać na rzetelne przygotowanie, nie na zwłokę.

## Co konkretnie jest wymagane i jak Decision Layer to realizuje

Poniższe wymagania obowiązują każdego operatora systemu AI wysokiego ryzyka w obszarze HR:

**Artykuł 9 - System zarządzania ryzykiem:**
EU AI Act wymaga ciągłego systemu zarządzania ryzykiem, który identyfikuje, ocenia i łagodzi ryzyka. W Decision Layer realizowane jest to przez Confidence Routing: każda decyzja agenta jest automatycznie oceniana pod kątem pewności i kategorii ryzyka. Wysokie ryzyko lub niska pewność prowadzi do eskalacji do człowieka. Progi są konfigurowalne i udokumentowane.

**Artykuł 10 - Governance danych:**
Wersjonowane zestawy reguł w Decision Layer zapewniają, że podstawa danych każdej decyzji jest możliwa do prześledzenia. Układy zbiorowe, porozumienia zakładowe i reguły compliance mają wersje, daty ważności i zakresy stosowania. Podczas kontroli można prześledzić, jaki zestaw reguł w jakiej wersji obowiązywał w momencie podjęcia decyzji.

**Artykuł 12 - Obowiązki rejestrowania:**
Audit Trail w Decision Layer generuje dla każdej decyzji kompletny, niezmienny rekord danych: dane wejściowe, model, zestaw reguł, pewność, decyzja routingu, wynik, znacznik czasu. Automatycznie, nie skompilowany po fakcie.

**Artykuł 13 - Transparentność:**
Każda decyzja agenta jest możliwa do prześledzenia w Portalu Audytora. Rady zakładowe, Inspektorzy Ochrony Danych (IOD) i audytorzy mogą przeglądać ścieżkę decyzyjną. Żadnej czarnej skrzynki.

**Artykuł 14 - Nadzór ludzki:**
Human-in-the-Loop jest w Decision Layer zasadą architektoniczną, a nie opcjonalnym ustawieniem. Dla określonych typów decyzji, potencjał dyskryminacji, kwestie współdecydowania, progi wartościowe, architektura wymusza przegląd przez człowieka. Agent nie może ominąć tej kontroli.

**Artykuł 15 - Dokładność, odporność i cyberbezpieczeństwo:**
Monitoring biasu systematycznie sprawdza wzorce dyskryminacyjne. Progi pewności zapewniają, że agent podejmuje decyzje autonomicznie tylko przy wystarczającej pewności. Model-agnostyczny design umożliwia zmianę modelu językowego bez zmiany logiki governance.

**Artykuł 86 - Prawo do wyjaśnienia:**
Ponad sześć obowiązków podmiotu stosującego art. 86 daje każdej osobie, której decyzja dotyczy, roszczenie o wyjaśnienie pojedynczej decyzji - nie systemu w ogóle, lecz tego jednego przypadku. Na to pytanie da się odpowiedzieć wyłącznie aktem decyzyjnym na każdą mikrodecyzję: input, zastosowana reguła merytoryczna wraz z wersją, pewność, wynik i ścieżka podważenia. Decision Layer tworzy ten akt w momencie decyzji, dzięki czemu roszczenie z art. 86 staje się spełnialne w każdym pojedynczym przypadku.

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Bezpłatny eBook: AI w HR</p>
<p class="text-body text-gosign-text mb-4">Checklista EU AI Act, framework decyzyjny, perspektywa rady zakładowej i ocena gotowości - poradnik governance dla liderów HR.</p>
<a href="/pl/ebook/ai-hr-poradnik-governance/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Pobierz bezpłatnie</a>
</div>

## Co to oznacza dla działów HR

Firmy, które dziś stosują lub planują stosować AI w procesach HR, muszą zbudować struktury governance - obowiązującym terminem jest 2 sierpnia 2026 r., a nawet przy wstępnie uzgodnionym przesunięciu na grudzień 2027 r. (Digital Omnibus) wdrożenie trwa miesiącami. Oznacza to konkretnie:

Udokumentowaną logikę decyzyjną dla każdego procesu HR wspomaganego przez AI. Technicznie wymuszone mechanizmy Human-in-the-Loop dla decyzji dotyczących personelu. Audytowalne Audit Trails umożliwiające prześledzenie, jak każda decyzja została podjęta. Monitoring biasu wykrywający i raportujący wzorce dyskryminacyjne.

W Polsce dodatkowym wymiarem są uprawnienia konsultacyjne rad pracowników oraz związki zawodowe, które mogą negocjować warunki wdrożenia systemów AI w miejscu pracy. Ustawa o radach pracowników daje prawo do informacji i konsultacji w sprawach dotyczących warunków pracy, co obejmuje wdrażanie nowych technologii.

Decision Layer adresuje oba bloki wymagań, EU AI Act oraz lokalne przepisy dotyczące współdecydowania, w jednej architekturze.

-> [Decision Layer w szczegółach](/pl/magazyn/decision-layer-wyjasnienie/)

-> [Akt decyzyjny: dlaczego każda decyzja AI musi być podważalna](/pl/magazyn/akt-decyzyjny-podwazalne-decyzje-ai/)

-> [Współdecydowanie i AI](/pl/governance/co-determination/)

-> [HR Agent](/pl/hr-ai-agents/)

<a href="/pl/kontakt/" target="_blank" rel="noopener noreferrer">Umów spotkanie</a> - Pokażemy, które z Twoich procesów HR podlegają kategorii wysokiego ryzyka i jak Decision Layer spełnia wymagania.

--- EU AI Act i HR - co jest teraz obowiązkowe ---
> EU AI Act klasyfikuje procesy HR jako wysokie ryzyko. Monitoring biasu, Human Oversight, transparentność - co teraz jest obowiązkowe.

EU AI Act klasyfikuje AI stosowaną w decyzjach personalnych jako system wysokiego ryzyka. Od klasyfikacji ryzyka przez monitoring biasu po nadzór ludzki - to teraz wymagania prawne, nie opcjonalne funkcje.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">W skrócie - Obowiązki EU AI Act dla HR</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Każdy system AI wpływający na decyzje HR - rekrutacja, ocena wyników, wynagrodzenia, awanse - to system wysokiego ryzyka wg Załącznika III EU AI Act.</li>
<li>Cztery kluczowe wymagania: klasyfikacja ryzyka każdego systemu AI, obowiązkowy monitoring biasu, wymuszony nadzór ludzki oraz pełna transparentność z dokumentacją.</li>
<li>Typowe błędy: retroaktywna zgodność zamiast Governance by Design, deklarowanie narzędzi AI jako "jedynie wspierających" i zbyt późne informowanie rady pracowników.</li>
<li>Właściwe podejście to Architecture-First: Decision Layer rozkłada każdy proces HR na pojedyncze kroki decyzyjne z logowaniem, wersjonowaniem i Human-in-the-Loop od pierwszego dnia.</li>
<li>Kary do 35 milionów euro lub 7% globalnego rocznego obrotu. Obowiązujący termin obowiązków dla systemów wysokiego ryzyka to 2 sierpnia 2026 r.; na mocy wstępnego porozumienia Digital Omnibus z maja 2026 r. ma zostać przesunięty na 2 grudnia 2027 r. (przyjęcie w toku).</li>
</ul>
</div>

Parlament Europejski (2024) szacuje, że HR i zatrudnienie stanowią największą pojedynczą kategorię zastosowań AI wysokiego ryzyka w ramach EU AI Act, dotykając szacunkowo 85% dużych przedsiębiorstw stosujących AI w rekrutacji lub zarządzaniu personelem.

<table>
<thead>
<tr><th>Proces HR</th><th>Klasyfikacja EU AI Act</th><th>Kluczowe wymaganie</th></tr>
</thead>
<tbody>
<tr><td>Screening CV / Rekrutacja</td><td>Wysokie ryzyko (Załącznik III)</td><td>Monitoring biasu, Audit Trail</td></tr>
<tr><td>Ocena wyników</td><td>Wysokie ryzyko (Załącznik III)</td><td>Nadzór ludzki, transparentność</td></tr>
<tr><td>Decyzje o awansach</td><td>Wysokie ryzyko (Załącznik III)</td><td>Wyjaśnialność, Human-in-the-Loop</td></tr>
<tr><td>Planowanie zmian (z danymi personalnymi)</td><td>Potencjalnie wysokie ryzyko</td><td>Ocena ryzyka, governance danych</td></tr>
<tr><td>Compliance Knowledge Agent</td><td>Ograniczone ryzyko</td><td>Obowiązek transparentności</td></tr>
</tbody>
</table>

## EU AI Act i HR: dlaczego to jest istotne

EU AI Act (Rozporządzenie (UE) 2024/1689) obowiązuje od sierpnia 2024. Reguluje systemy AI według ich ryzyka. Dla działów HR klasyfikacja jest jednoznaczna: systemy AI stosowane do podejmowania decyzji dotyczących osób fizycznych w kontekście zatrudnienia są systemami wysokiego ryzyka (Załącznik III, punkt 4).

Dotyczy to nie tylko automatycznego oprogramowania rekrutacyjnego. Dotyczy każdego zastosowania AI mającego wpływ na decyzje personalne: screening kandydatów, ocena wyników, propozycje wynagrodzeń, rekomendacje awansów, planowanie zmian z optymalizacją AI, automatyczne generowanie referencji.

Zgodnie z obowiązującym prawem obowiązki dla systemów wysokiego ryzyka mają zastosowanie od [2 sierpnia 2026 r.](/pl/magazyn/eu-ai-act-2026-przedsiebiorstwa/), jednak na mocy wstępnego porozumienia Digital Omnibus z 7 maja 2026 r. mają zostać przesunięte na 2 grudnia 2027 r. (przyjęcie wciąż w toku). To daje firmom najprawdopodobniej dodatkowy czas na przygotowanie, ale klasyfikacja wysokiego ryzyka pozostaje w mocy, a decyzje architektoniczne muszą być podejmowane teraz.

## Czego EU AI Act konkretnie wymaga

Dla systemów AI wysokiego ryzyka w obszarze HR EU AI Act wymaga:

**System zarządzania ryzykiem (Art. 9):** Ciągłe zarządzanie ryzykiem przez cały cykl życia systemu AI. Identyfikacja ryzyk, ocena, środki zaradcze, przegląd. To nie jest jednorazowa analiza, lecz ciągły proces.

**Jakość danych (Art. 10):** Dane treningowe, walidacyjne i testowe muszą być istotne, reprezentatywne, wolne od błędów i kompletne. Dla HR oznacza to: jeśli agent jest trenowany na historycznych decyzjach personalnych, dane te muszą być sprawdzone pod kątem biasu. Historyczna dyskryminacja w danych będzie inaczej reprodukowana przez system AI.

**Dokumentacja techniczna (Art. 11):** Pełna dokumentacja systemu AI przed uruchomieniem. Cel, sposób działania, wskaźniki wydajności, ograniczenia, ryzyka. Dokumentacja musi być aktualizowana.

**Przechowywanie logów (Art. 12):** Automatyczne protokołowanie wszystkich zdarzeń przez cały okres życia systemu. W kontekście HR: każda decyzja, każda rekomendacja, każda eskalacja.

**Human Oversight (Art. 14):** Nadzór ludzki musi być zagwarantowany. Człowiek musi rozumieć możliwości i ograniczenia systemu, być w stanie interpretować wyniki i mieć możliwość interwencji lub wyłączenia systemu.

**Monitoring biasu:** EU AI Act wymaga, aby systemy wysokiego ryzyka były monitorowane pod kątem uprzedzeń. Dla decyzji HR oznacza to: analiza statystyczna wszystkich decyzji agentów. Czy określone grupy są systematycznie traktowane inaczej?

**Transparentność (Art. 13):** Osoby, których decyzje dotyczą, muszą być informowane o stosowaniu systemów AI.

## Co to oznacza dla architektury

Wymagania EU AI Act to nie środki organizacyjne. To wymagania architektoniczne. System AI, który ma spełnić te wymagania po fakcie, musi być gruntownie przebudowany.

**Decision Layer:** Decision Layer rozkłada każdy proces HR na pojedyncze kroki decyzyjne i definiuje dla każdego kroku: człowiek, zestaw reguł lub AI. Rules Engine implementuje wersjonowane zestawy reguł. Confidence Routing zapewnia ocenę ryzyka. Mechanizm Human-in-the-Loop gwarantuje nadzór ludzki. Audit Trail spełnia obowiązek przechowywania logów.

**Monitoring biasu:** Przez Decision Layer wszystkie decyzje agentów są analizowane statystycznie. Odchylenia od oczekiwanych rozkładów są wykrywane i eskalowane. To nie jest ręczny proces przeglądu, lecz automatyczny monitoring.

**Portal Audytora:** Dokumentacja techniczna i dowody są dostępne w Portalu Audytora w każdej chwili. Audytorzy - wewnętrzni i zewnętrzni - widzą status na żywo wszystkich kontroli.

## Harmonogram: co musi się teraz wydarzyć

**Natychmiast:** Inwentaryzacja wszystkich systemów AI w obszarze HR. Również tych, które nie są oznaczone jako "AI": algorytmy scoringowe w oprogramowaniu rekrutacyjnym, planowanie zmian oparte na AI, automatyczne generowanie tekstów.

**Do Q3 2026:** Wdrożenie systemu zarządzania ryzykiem. Podjęcie decyzji architektonicznych. Implementacja infrastruktury governance.

**Od 2 sierpnia 2026 r.:** Systemy wysokiego ryzyka muszą w pełni spełniać wymagania EU AI Act (obowiązujący termin; wstępnie uzgodnione przesunięcie na 2 grudnia 2027 r. - Digital Omnibus, maj 2026, przyjęcie w toku).

W Polsce EU AI Act obowiązuje bezpośrednio jako rozporządzenie UE, bez potrzeby implementacji do prawa krajowego. Dodatkowo Kodeks Pracy i Ustawa o radach pracowników (2006) dają Radzie Zakładowej prawo do informacji i konsultacji przy wdrażaniu systemów technicznych wpływających na warunki pracy. Związki zawodowe mogą negocjować warunki wdrożenia AI w porozumieniach zakładowych. Decision Layer adresuje oba bloki wymagań - EU AI Act i polskie prawo do konsultacji - w jednej architekturze.

Firmy, które teraz wdrażają agentów AI do procesów HR, powinny od początku projektować architekturę zgodną z EU AI Act. Retrospektywna zgodność jest technicznie możliwa, ale znacznie bardziej pracochłonna i kosztowna.

Więcej na ten temat: [EU AI Act Readiness](/pl/governance/eu-ai-act/)

Więcej o [agentach AI w HR](/pl/hr-ai-agents/) i ich zgodności z polskimi przepisami.

<a href="/pl/kontakt/" target="_blank" rel="noopener noreferrer">Umów spotkanie</a> - Pokażemy, jak Twoje systemy AI w HR mogą być zgodne z EU AI Act.

--- EU AI Act obowiązuje na całym świecie. ---
> EU AI Act to nie europejska nadregulacja. Po prostu zapisuje to, czego każdy system prawny już wymaga: Wyjaśnij swoją decyzję.

*Somalia. Sudan Południowy. Jemen. Libia. Syria. - To jedyne wyjątki.*

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">W skrócie - Accountability AI jest uniwersalne</p>
<ul class="text-body text-gosign-text space-y-2">
<li>EU AI Act nie wymyślił wyjaśnialnych decyzji AI - jako pierwszy skodyfikował tę zasadę specjalnie dla systemów AI. Obowiązek wyjaśniania decyzji istnieje w praktycznie każdym systemie prawnym na świecie.</li>
<li>HR to obszar najwyższego ryzyka, ponieważ decyzje AI dotyczące ludzi tworzą największą powierzchnię ataku prawnego - od biasu w screeningu CV po zautomatyzowane oceny pracownicze.</li>
<li>Stronniczy algorytm skaluje dyskryminację do 50 000 decyzji jednocześnie - w porównaniu z około 50 rocznie stronniczego menedżera.</li>
<li>Każda firma używająca AI do decyzji dotyczących ludzi potrzebuje dwóch warstw: Decision Layer (ślad dowodowy każdej decyzji) i Governance Layer (zasady gry).</li>
<li>Shadow AI - pracownicy korzystający z ChatGPT, Copilot i innych narzędzi bez governance - to najpilniejsze i najbardziej niedoceniane ryzyko dla większości organizacji.</li>
</ul>
</div>

Według Komisji Europejskiej (2024), systemy AI sklasyfikowane jako wysokiego ryzyka w ramach EU AI Act bezpośrednio wpłyną na decyzje personalne w ponad 6000 organizacji w państwach członkowskich UE. HR został zidentyfikowany jako najczęściej dotknięty obszar biznesowy zgodnie z Załącznikiem III.

## Pytanie za 3 miliony złotych

Polska firma używa narzędzia AI do rekrutacji. 500 aplikacji na wejściu, 20 na wyjściu. Jeden z 480 odrzuconych kandydatów idzie do sądu pracy. Nie powołuje się na EU AI Act. Powołuje się na Kodeks Pracy - artykuł 183a zakazujący dyskryminacji w zatrudnieniu. Przepis obowiązujący od 2004 roku.

Pytanie sądu: "Proszę wyjaśnić, jak ta decyzja została podjęta."

Cisza.

Nie dlatego, że firma działała w złej wierze. Dlatego, że nikt w firmie nie potrafi wyjaśnić, jak narzędzie AI wygenerowało te 480 odmów. HR kupił narzędzie. IT je zainstalowało. A logika decyzyjna tkwi w czarnej skrzynce, której nikt nie potrafi otworzyć.

To nie jest scenariusz hipotetyczny. To dzieje się teraz. I nie tylko w Polsce.

## Accountability to nie wynalazek europejski

Większość menedżerów schowała EU AI Act do szuflady z napisem "europejska biurokracja". To kosztowny błąd. EU AI Act nie wymyślił zasady wyjaśnialnych decyzji. Po prostu jako pierwszy skodyfikował ją specjalnie dla systemów AI.

Sama zasada obowiązuje wszędzie.

**Polska:** Kodeks Pracy art. 183a-183e zakazuje dyskryminacji bezpośredniej i pośredniej. Ustawa o ochronie danych osobowych (implementacja RODO) wymaga transparentności przetwarzania. Państwowa Inspekcja Pracy może kontrolować, jak firma podejmuje decyzje kadrowe. A jako członek UE, EU AI Act obowiązuje bezpośrednio - z pełną mocą prawa europejskiego.

**USA:** Title VII Civil Rights Act zabrania dyskryminacji w decyzjach personalnych - od 1964 roku. EEOC może w każdej chwili zażądać wyjaśnienia, dlaczego kandydat został odrzucony. W Nowym Jorku Local Law 144 wymaga obowiązkowych audytów bias w narzędziach AI do rekrutacji od 2023 roku.

**Brazylia:** LGPD artykuł 20 daje wyraźne prawo do wyjaśnienia decyzji automatycznych. Brazylijskie sądy pracy to najaktywniejsze sądy pracy na świecie - ponad 3,5 miliona nowych spraw rocznie.

**Chiny:** Algorithmic Recommendation Management Provisions obowiązują od 2022 roku. Nawet Chiny wymagają transparentności decyzji algorytmicznych.

Spośród 193 państw członkowskich ONZ, dokładnie w 5 firma nie może zostać pociągnięta do odpowiedzialności za niewytłumaczalną decyzję AI. Nie dlatego, że te kraje na to pozwalają - ale dlatego, że nie mają funkcjonującego systemu sądowniczego.

EU AI Act to nie europejska nadregulacja. To pierwsza uczciwa odpowiedź na uniwersalne pytanie.

<table class="w-full text-left text-sm">
<thead><tr class="border-b border-gosign-border">
<th class="py-2 pr-4 font-semibold">Region</th>
<th class="py-2 pr-4 font-semibold">Ustawodawstwo</th>
<th class="py-2 pr-4 font-semibold">Wymagana wyjaśnialność</th>
<th class="py-2 pr-4 font-semibold">Decyzje HR objęte</th>
</tr></thead>
<tbody>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">UE / Polska</td><td class="py-2 pr-4">EU AI Act, RODO Art. 22, Kodeks Pracy</td><td class="py-2 pr-4">Tak (prawnie wiążące)</td><td class="py-2 pr-4">Tak (Załącznik III wysokie ryzyko)</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">USA</td><td class="py-2 pr-4">Title VII, NYC Local Law 144</td><td class="py-2 pr-4">Tak (antydyskryminacja)</td><td class="py-2 pr-4">Tak (decyzje o zatrudnieniu)</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Brazylia</td><td class="py-2 pr-4">LGPD Art. 20, CLT</td><td class="py-2 pr-4">Tak (prawo do wyjaśnienia)</td><td class="py-2 pr-4">Tak (aktywne sądy pracy)</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Chiny</td><td class="py-2 pr-4">Algorithmic Provisions 2022</td><td class="py-2 pr-4">Tak (wymagana transparentność)</td><td class="py-2 pr-4">Tak (decyzje algorytmiczne)</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">UK</td><td class="py-2 pr-4">UK GDPR, Equality Act 2010</td><td class="py-2 pr-4">Tak (wytyczne ICO)</td><td class="py-2 pr-4">Tak (decyzje automatyczne)</td></tr>
</tbody>
</table>

## Dlaczego HR jest na pierwszej linii frontu

<img src="/images/magazin/risk-pyramid-pl.svg" alt="Piramida ryzyka: decyzje HR o ludziach niosą najwyższe ryzyko" width="800" height="480" loading="lazy" />

Błędne decyzje AI o produktach są irytujące. Błędne decyzje AI o procesach są kosztowne. Błędne decyzje AI o ludziach są egzystencjalne - dla poszkodowanych i dla firmy.

HR to obszar, w którym decyzje AI tworzą największą powierzchnię ataku. Trzy scenariusze, które dzieją się już dziś:

Screening CV oparty na AI systematycznie odrzuca kandydatów z przerwami w karierze. Dotknięci: rodzice, osoby przewlekle chore, osoby zmieniające ścieżkę kariery. W polskim prawie pracy to dyskryminacja pośrednia.

Analiza sentymentu w rozmowach wideo błędnie interpretuje kulturowe różnice w mimice i gestach jako negatywne sygnały. Dotknięci: kandydaci z innym tłem kulturowym. To potencjalnie dyskryminacja etniczna.

Narzędzie do przewidywania wyników trenowane na historycznych danych o awansach reprodukuje wzorce z przeszłości. Jeśli w przeszłości mężczyźni byli awansowani częściej, narzędzie powiela ten schemat. To systematyczna dyskryminacja ze względu na płeć - zautomatyzowana i skalowalna.

Każdy z tych scenariuszy jest już dziś zaskarżalny w większości krajów. Nie dopiero z terminem obowiązków wysokiego ryzyka EU AI Act - obowiązującym 2 sierpnia 2026 r., wstępnie uzgodnionym do przesunięcia na 2 grudnia 2027 r. (Digital Omnibus, maj 2026, przyjęcie w toku). Teraz. Różnica: EU AI Act zmienia to z reaktywnej odpowiedzialności w proaktywny obowiązek.

A prawdziwy problem z dyskryminacją AI w porównaniu z ludzką dyskryminacją: stronniczy menedżer podejmuje może 50 wątpliwych decyzji rocznie. Stronniczy algorytm podejmuje 50 000. Jednocześnie. Konsekwentnie. Udowadnialnie.

## Dwie warstwy, których potrzebuje każda firma

<img src="/images/magazin/decision-governance-layers-pl.svg" alt="Governance Layer i Decision Layer: dwuwarstwowa architektura" width="800" height="440" loading="lazy" />

Rozwiązanie nie jest skomplikowane - ale wymaga architektonicznego myślenia. Każda firma, która używa AI do decyzji dotyczących ludzi, potrzebuje dwóch warstw.

**[Decision Layer](/pl/magazyn/decision-layer-shadow-ai/) - dowody.** Decision Layer rozkłada każdy proces na pojedyncze kroki decyzyjne i dla każdego kroku definiuje: człowiek, zestaw reguł czy AI. Każda decyzja wspomagana przez AI odpowiada na pytania: Jakie dane weszły? Który model zdecydował, w jakiej wersji? Jaki był wynik i z jakim poziomem pewności? Czy człowiek przejrzał wynik, zanim zaczął obowiązywać? Czy decyzja jest powtarzalna?

To nie jest techniczny dodatek. To cyfrowy odpowiednik księgowości. I tak jak żadna firma nie może działać bez księgowości, wkrótce żadna firma nie będzie mogła działać bez Decision Layer.

**Governance Layer - zasady gry.** Zanim zapadnie pierwsza decyzja AI: Jakie aplikacje AI w ogóle istnieją w firmie? Większość firm tego nie wie. Jak ryzykowna jest każda aplikacja - nie według kategorii regulacyjnych, ale według realnego wpływu na ludzi? Kto ponosi odpowiedzialność? Spoiler: "IT" to nie odpowiedź. Kiedy musi interweniować człowiek? I jak to wszystko jest audytowane?

W Polsce istotna jest dodatkowa rola Społecznego Inspektora Pracy oraz potencjalna rola związków zawodowych w procesie wdrażania systemów AI, które wpływają na decyzje kadrowe. Transparentność i udokumentowana logika decyzyjna to warunek konieczny dla akceptacji przez pracowników i ich przedstawicieli.

## Słoń w pokoju: Shadow AI

<img src="/images/magazin/shadow-ai-eisberg-pl.svg" alt="Shadow AI góra lodowa: nad wodą oficjalne narzędzia AI, pod wodą niekontrolowane użycie bez śladu audytu" width="800" height="600" loading="lazy" />

I teraz najbardziej niewygodny punkt. Większość firm dyskutuje o governance dla narzędzi AI, które oficjalnie wdrożyła. W międzyczasie ich pracownicy już dawno korzystają z ChatGPT, Claude, Copilot i innych narzędzi do przygotowywania decyzji - bez wiedzy kogokolwiek.

Rekruterzy używają ChatGPT do podsumowywania aplikacji. Kierownicy zespołów zlecają Copilotowi pisanie rekomendacji awansowych. Dział L&D tworzy z AI oceny pracownicze.

To wszystko dzieje się. Teraz. Bez Decision Layer. Bez Governance Layer. Bez jakiejkolwiek śladowości.

A kiedy ktoś pozwie firmę, odpowiedź nie będzie "AI zdecydowała" - będzie gorsza: "Nie wiedzieliśmy nawet, że AI decydowała."

## Prawdziwe pytanie

Pytanie nie brzmi: "Czy jesteśmy [zgodni z EU AI Act](/pl/magazyn/eu-ai-act-hr-wysokie-ryzyko/)?"

Pytanie brzmi: Czy jutro - w każdym kraju, w którym działamy - potrafimy wyjaśnić, dlaczego dzisiaj podjęliśmy taką decyzję?

Kto potrafi odpowiedzieć "tak", jest automatycznie zgodny. Z EU AI Act. Z RODO. Z Kodeksem Pracy. Ze wszystkim, co jeszcze nadejdzie.

Kto nie potrafi, nie ma problemu z regulacjami. Ma problem z governance.

--- Hosting AI: EU SaaS, centrum danych czy Self-Hosted? ---
> Trzy strategie hostingu dla enterprise AI. Matryca decyzyjna wg wrażliwości danych, kosztów i kontroli.

## "Gdzie to działa?" - Decydujące pytanie

Zanim wybierzesz model, zanim zbudujesz agentów, zanim wdrożysz interfejs, stoi jedno pytanie: Gdzie działają Twoje modele AI? Ta decyzja określa, jakie gwarancje ochrony danych możesz dać, jakie wymagania regulacyjne spełniasz, jak wysokie są Twoje bieżące koszty i jak bardzo uzależniasz się od zewnętrznych dostawców.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">W skrócie - Strategia hostingu AI dla enterprise</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Trzy poziomy: EU SaaS (Cloud API), europejskie IaaS (Self-Hosted GPU) i on-premises (własny sprzęt) - plus kombinacja hybrydowa.</li>
<li>Architektura hybrydowa kieruje zapytania według wrażliwości danych: 60-70% chmura, 25-35% europejskie IaaS, 5-10% on-premises.</li>
<li>Gartner (2025) szacuje, że 40% dużych firm będzie prowadzić hybrydowe architektury hostingu AI do 2027, w porównaniu z poniżej 10% w 2024.</li>
<li>Modele open source self-hosted (gpt-oss-120b) działają na jednym GPU za ok. 1200 EUR miesięcznie u europejskich dostawców.</li>
<li>Całkowite koszty ze strategią hybrydową są o 30-40% niższe niż przy strategii opartej wyłącznie na Cloud API, przy wyższej suwerenności danych.</li>
</ul>
</div>

Istnieją trzy podstawowe strategie - i czwarta, która w praktyce stała się standardem: architektura hybrydowa, która łączy wszystkie trzy.

## Poziom 1: EU SaaS - Cloud API z rezydencją danych w UE

Najprostsza i najszybsza opcja: korzystasz z API dostawców modeli bezpośrednio. Claude przez Anthropic API (region UE), GPT-5.5 przez Azure OpenAI (centrum danych UE), Gemini przez Google Cloud Platform (region UE). Dane opuszczają Twoją sieć, ale są przetwarzane w centrach danych UE.

### Zalety

**Najszybszy start:** Bez budowania infrastruktury, bez provisioningu serwerów GPU, bez potrzeby ekspertyzy ML-Ops. Konfiguracja klucza API, podpisanie umowy powierzenia, produktywność w kilka godzin.

**Automatyczne aktualizacje:** Aktualizacje modeli, łatki bezpieczeństwa i usprawnienia wydajności wdrażane przez dostawcę. Bez własnego nakładu na utrzymanie.

**Skalowalność:** Bez zarządzania pojemnością. Przy skokach obciążenia dostawca chmury skaluje automatycznie. Bez nadplanowania, bez niedoboru.

**Różnorodność modeli:** Dostęp do wszystkich wariantów modeli dostawcy - flagowy, cena-jakość i budżetowy - przez to samo API.

### Ryzyka i ograniczenia

**Dane opuszczają sieć firmową.** Nawet przy rezydencji danych w UE Twoje zapytania są przetwarzane na infrastrukturze, której nie kontrolujesz. Dostawca ma techniczny dostęp do danych podczas przetwarzania.

**CLOUD Act.** Dostawcy amerykańscy - w tym Anthropic, OpenAI i Google - podlegają amerykańskiej ustawie CLOUD Act. W określonych warunkach władze USA mogą żądać dostępu do danych, nawet jeśli są przechowywane w centrach danych UE. Dla większości danych firmowych ryzyko to jest ocenialne i akceptowalne. Dla tajemnic handlowych, danych niejawnych czy informacji dotyczących infrastruktury krytycznej - nie.

**Zależność od dostawcy.** Przy strategii jednego dostawcy jesteś zależny od polityki cenowej, zmian API i dostępności jednego dostawcy. Architektura model-agnostic (zob. [Porównanie modeli AI 2026](/pl/magazyn/modele-ai-porownanie-2026/)) redukuje to ryzyko.

**Wymagana umowa powierzenia.** Do korzystania zgodnego z RODO wymagana jest umowa powierzenia przetwarzania danych z dostawcą. Wszyscy trzej wielcy dostawcy oferują standardowe umowy - zweryfikuj je z działem prawnym. Uwaga: Standardowe umowy powierzenia SaaS nie obejmują tematów specyficznych dla AI, takich jak logowanie promptów, separacja środowisk i łańcuchy dostawców modeli. Nasz [katalog wymagań dla umów powierzenia AI](/pl/magazyn/umowa-powierzenia-ai-lista-kontrolna/) identyfikuje dziesięć luk i zawiera 25 pytań weryfikacyjnych.

### Odpowiednie dla

- Standardowych zadań z danymi niewrażliwymi: podsumowania, tłumaczenia, ogólne odpowiadanie na pytania
- Proof of Concept i projektów pilotażowych
- Zadań o zmiennym wolumenie, gdzie dedykowana infrastruktura GPU byłaby nieekonomiczna
- Organizacji bez ekspertyzy ML-Ops, które chcą szybko zacząć produkcyjnie

## Poziom 2: Europejskie IaaS - hosting GPU u europejskich dostawców

Środkowa opcja: wynajmujesz serwery GPU u europejskiego dostawcy Infrastructure-as-a-Service - np. Hetzner, IONOS lub specjalistycznego dostawcy chmury GPU. Na tych serwerach samodzielnie uruchamiasz modele open source, takie jak gpt-oss, Llama 4 czy Mistral Medium 3.1.

### Konkretne wymagania sprzętowe i koszty

| Model | Wymaganie GPU | Szacunkowy koszt/miesiąc |
|---|---|---|
| gpt-oss-120b | 1x A100/H100 (80 GB) | ok. 1200 EUR |
| gpt-oss-20b | CPU/16 GB RAM (lub mały GPU) | ok. 200-400 EUR |
| Llama 4 Scout | 1x A100 (80 GB) | ok. 1200 EUR |
| Llama 4 Maverick | 4x A100 (80 GB) | ok. 3500 EUR |
| Mistral Medium 3.1 | 4x A100 (80 GB) | ok. 3500 EUR |

### Zalety

**Dane pozostają w Europie.** Serwer stoi w europejskim centrum danych, obsługiwany przez europejskiego dostawcę. Bez CLOUD Act, bez transatlantyckiego transferu danych. Dla zgodności z RODO to najbezpieczniejsza opcja chmurowa.

**Brak vendor lock-in.** Obsługujesz modele open source na licencji Apache 2.0 lub Meta Llama License. Gdy chcesz zmienić dostawcę hostingu, migrujesz model - bez pytań o licencje, bez negocjacji kontraktowych.

**Pełna kontrola nad modelem.** Decydujesz, który model w jakiej wersji działa. Możesz modele dostrajać, kwantyzować lub zastępować nowszymi wersjami - bez czekania na dostawcę.

**Przewidywalne koszty.** Serwery GPU mają stałe koszty miesięczne. Bez zmiennych kosztów tokenów, bez niespodzianek przy skokach obciążenia. Dla organizacji z wysokim, stałym wolumenem często bardziej ekonomiczne niż Cloud API.

### Wymagania

**Kompetencje ML-Ops.** Potrzebujesz kogoś, kto wdroży, monitoruje, aktualizuje i interweniuje w razie problemów. Może to być wewnętrzny inżynier ML lub zewnętrzny usługodawca - ale to nie jest zerowy nakład pracy.

**Planowanie pojemności.** Serwer GPU ma zdefiniowaną pojemność. Jeśli masz 500 równoczesnych zapytań, jeden GPU nie wystarczy. Musisz rozumieć profile obciążenia i planować pojemności.

**Brak automatycznych aktualizacji.** Gdy pojawia się nowy model, wdrażasz go sam. Gdy wystąpi problem bezpieczeństwa, łatasz sam.

### Odpowiednie dla

- Poufnych danych firmowych (poziom wrażliwości 2-3)
- Organizacji, które muszą wyeliminować ryzyko CLOUD Act
- Zastosowań ze stałym, wysokim wolumenem (przewaga kosztowa nad Cloud API)
- Organizacji z istniejącą kompetencją DevOps/ML-Ops

## Poziom 3: On-Premises - AI na własnym sprzęcie

Opcja maksymalnej kontroli: obsługujesz serwery GPU we własnym centrum danych lub w kolokacji. Żadne dane nie opuszczają Twojej sieci - pod żadnym warunkiem.

### Zalety

**Maksymalna suwerenność danych.** Brak dostępu zewnętrznego, brak zewnętrznego dostawcy, brak zewnętrznej zależności. Sprzęt należy do Ciebie, model należy do Ciebie, dane nigdy nie opuszczają Twojej sieci.

**Pewność regulacyjna.** Dla operatorów infrastruktury krytycznej, instytucji państwowych, sektora obronnego i organizacji z danymi niejawnymi on-premises to często jedyna opcja spełniająca wymagania compliance.

**Brak bieżących kosztów licencji czy API.** Po początkowej inwestycji pozostają tylko koszty prądu, chłodzenia i utrzymania. Przy długookresowej eksploatacji i wysokim wolumenie on-premises może być najtańszą opcją.

### Wyzwania

**Wysoka inwestycja początkowa.** Produkcyjny serwer GPU z NVIDIA H100 (80 GB) kosztuje 25 000-40 000 EUR. Dla bardziej wydajnych setupów (multi-GPU, redundancja) koszty sięgają 60 000-120 000 EUR lub więcej.

**Wymagany zespół ML-Ops.** On-premises oznacza: jesteś odpowiedzialny za wszystko. Utrzymanie sprzętu, deployment modeli, monitoring, aktualizacje, bezpieczeństwo. To wymaga dedykowanego zespołu lub doświadczonego usługodawcy.

**Skalowanie nie jest trywialne.** Gdy obciążenie rośnie, nie możesz dodać kolejnego GPU jednym kliknięciem. Zakup sprzętu trwa tygodnie do miesięcy.

### Odpowiednie dla

- Operatorów infrastruktury krytycznej i instytucji państwowych
- Danych niejawnych i najwyższych poziomów poufności
- Organizacji z własnym centrum danych i kompetencją ML-Ops
- Długookresowej gotowości inwestycyjnej przy bardzo wysokim wolumenie

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Darmowy eBook: Infrastruktura AI</p>
<p class="text-body text-gosign-text mb-4">Build, Buy, Hybrid - infrastruktura zgodna z EU AI Act z B/B/H-Framework i 7-Layer Reference Architecture.</p>
<a href="/pl/ebook/ai-infrastructure-poradnik-governance/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Pobierz za darmo</a>
</div>

## Drzewo decyzyjne

Następująca logika decyzyjna pomaga w przypisaniu:

```
Czy Twoje dane zawieraja PII lub tajemnice handlowe?
+-- NIE -> EU SaaS (Poziom 1)
+-- TAK -> Infrastruktura krytyczna lub dane niejawne?
+-- TAK -> On-Premises (Poziom 3)
+-- NIE -> Europejskie IaaS (Poziom 2) lub Hybrid
```

W praktyce odpowiedzią rzadko jest jeden poziom. Większość organizacji ma dane o różnej wrażliwości - i dlatego potrzebuje architektury obejmującej wszystkie poziomy.

## Hybrid jako standard: Architektura routingu

Strategia hybrydowa łączy wszystkie trzy poziomy w jednej architekturze. Warstwa routingu automatycznie decyduje, które zapytanie przechodzi jakim kanałem - na podstawie wrażliwości danych, nie na podstawie decyzji poszczególnych pracowników.

### Jak działa routing

**Poziom wrażliwości 1-2 (publiczne, wewnętrzne):** Zapytania idą przez Cloud API. Szybko, tanio, skalowalnie. Przykład: podsumowanie publicznego whitepapera, tłumaczenie komunikatu prasowego, szkic ogólnego maila.

**Poziom wrażliwości 3 (poufne):** Zapytania są kierowane do modeli self-hosted w europejskim centrum danych. Brak wycieku danych, brak CLOUD Act. Przykład: analiza wewnętrznych umów, przetwarzanie danych personalnych, analiza poufnych danych finansowych.

**Poziom wrażliwości 4 (ściśle poufne / regulowane):** Zapytania przechodzą wyłącznie przez infrastrukturę on-premises. Przykład: dokumenty niejawne, systemy infrastruktury krytycznej, dane pod szczególną ochroną.

### Warunek: Klasyfikacja danych

Aby routing działał, organizacja musi sklasyfikować swoje dane. Brzmi to pracochłonnie, ale w wielu organizacjach już istnieje - np. w ramach istniejących Systemów Zarządzania Bezpieczeństwem Informacji (SZBI) lub krajowych ram klasyfikacji bezpieczeństwa. Reguły routingu odwzorowują tę istniejącą klasyfikację na infrastrukturę AI.

### Implementacja techniczna

Warstwa routingu siedzi między [Enterprise AI Portal](/pl/magazyn/enterprise-ai-chat-interface/) (interfejsem, którego używają pracownicy) a endpointami modeli. Składa się z trzech komponentów:

1. **Klasyfikator:** Automatycznie rozpoznaje wrażliwość danych zapytania - na podstawie słów kluczowych, systemu źródłowego lub jawnego oznaczenia przez użytkownika.
2. **Silnik routingu:** Przypisuje zapytanie do odpowiedniego endpointu modelu - Cloud API, europejskie IaaS lub on-premises.
3. **Audit Log:** Rejestruje każdą decyzję routingową - jakie zapytanie, jaki poziom wrażliwości, jaki endpoint. Śledzalne i eksportowalne.

### Efekt kosztowy

Architektura hybrydowa optymalizuje nie tylko bezpieczeństwo danych, ale też koszty. Cloud API są tanie za zapytanie, ale zmienne. Modele self-hosted mają koszty stałe, które amortyzują się przy wysokim wolumenie. Połączenie wykorzystuje oba: tanie Cloud API do grosu niekrytycznych zapytań, modele self-hosted z optymalizacją kosztów stałych do wolumenu poufnego.

W praktyce widzimy u organizacji z 1000+ pracownikami typowo następujący rozkład: 60-70% zapytań przechodzi przez Cloud API (poziom 1-2), 25-35% przez europejskie IaaS (poziom 3) i 5-10% przez on-premises (poziom 4). Całkowite koszty są o 30-40% niższe niż przy strategii opartej wyłącznie na Cloud API, przy jednocześnie wyższej suwerenności danych.

## Podsumowanie: Trzy poziomy w skrócie

| Kryterium | EU SaaS (Poziom 1) | Europejskie IaaS (Poziom 2) | On-Premises (Poziom 3) |
|---|---|---|---|
| Suwerenność danych | Region UE, umowa powierzenia | Europa, brak CLOUD Act | Maksymalna |
| Koszty początkowe | Brak | Niskie (wynajem) | Wysokie (60-120 tys. EUR+) |
| Koszty bieżące | Zmienne (tokeny) | Stałe (wynajem GPU) | Stałe (prąd, utrzymanie) |
| Nakład ML-Ops | Brak | Średni | Wysoki |
| Skalowalność | Automatyczna | Ręczna | Ręczna, wolna |
| Odpowiednie dla | Dane poziomu 1-2 | Dane poziomu 2-3 | Dane poziomu 3-4 |

Właściwa strategia to prawie zawsze kombinacja. Gosign implementuje warstwę routingu, która łączy wszystkie trzy poziomy - tak że Twoi pracownicy korzystają z jednego interfejsu, a system automatycznie wybiera właściwą ścieżkę.

Dalej: [Infrastruktura AI](/pl/uslugi/infrastruktura/) | [Decision Layer & Shadow AI](/pl/magazyn/decision-layer-shadow-ai/)

---

**Enterprise AI Infrastructure Blueprint 2026 - Seria artykułów**

| Poprzedni | Przegląd | Następny |
|:---|:---:|---:|
| [Modele AI 2026: Który model do jakiego zastosowania?](/pl/magazyn/modele-ai-porownanie-2026/) | [Przegląd](/pl/magazyn/infrastruktura-ai-blueprint-2026/) | [Enterprise AI Portal: Cztery interfejsy open source w porównaniu](/pl/magazyn/enterprise-ai-chat-interface/) |

*Wszystkie artykuły z tej serii: [Enterprise AI Infrastructure Blueprint 2026](/pl/magazyn/infrastruktura-ai-blueprint-2026/)*

---

**Chcesz wiedzieć, która strategia hostingu jest odpowiednia dla Twoich danych?** Gosign analizuje Twoją klasyfikację danych i projektuje odpowiednią architekturę hybrydową.

<a href="/pl/kontakt/" target="_blank" rel="noopener noreferrer">Umów rozmowę</a> - W 30 minut wyjaśnimy, jakie poziomy hostingu potrzebujesz.

--- Human-in-the-Loop - zasada architektury, nie checkbox ---
> Human-in-the-Loop dla agentów AI: architektonicznie wymuszona kontrola ludzka. Confidence Routing, reguły eskalacji, kontrole biasu.

## Problem: HITL jako twierdzenie marketingowe

Niemal każdy dostawca AI twierdzi, że jego rozwiązanie posiada "Human-in-the-Loop". W praktyce często oznacza to: gdzieś w procesie jest przycisk zatwierdzania. Człowiek może go kliknąć. Ale nie musi.

To nie jest Human-in-the-Loop. To opcjonalne zatwierdzenie, które pod presją czasu zostaje pominięte. Gdy pracownik przetwarza 200 dokumentów dziennie i 195 z nich jest poprawnych, w końcu zacznie zatwierdzać wszystkie bez przeglądu.

Prawdziwy Human-in-the-Loop to zasada architektoniczna. Oznacza: przy zdefiniowanych typach decyzji agent fizycznie nie może działać autonomicznie. Workflow się zatrzymuje. System docelowy nie jest wywoływany. Dopiero po ludzkiej weryfikacji i udokumentowanym zatwierdzeniu proces jest kontynuowany.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">W skrócie - Architektura Human-in-the-Loop</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Prawdziwy HITL to zasada architektoniczna, nie opcjonalny przycisk zatwierdzenia - agent fizycznie nie może ominąć weryfikacji ludzkiej przy zdefiniowanych typach decyzji.</li>
<li>Trzy wyzwalacze: niska wartość pewności, klasyfikacja wysokiego ryzyka (dyskryminacja, konsultacja) i pierwsze zastosowanie nowych reguł.</li>
<li>EU AI Act wymaga efektywnego nadzoru ludzkiego dla systemów AI wysokiego ryzyka - procesy HR wyraźnie podlegają tej kategorii.</li>
<li>Porozumienia zakładowe stają się ograniczeniami technicznymi w Decision Layer, których system nie może ominąć.</li>
<li>HITL nie rozwiązuje problemu biasu w danych treningowych i nie skaluje się liniowo - to jeden element obok Audit Trail, monitoringu biasu i kontroli Cert-Ready.</li>
</ul>
</div>

Według Komisji Europejskiej (2024), nadzór ludzki jest wymagany dla wszystkich systemów AI wysokiego ryzyka zgodnie z EU AI Act, a procesy HR są wyraźnie wymienione w Załączniku III - co czyni architektonicznie wymuszone Human-in-the-Loop koniecznością prawną, a nie wyborem projektowym.

| Wyzwalacz HITL | Opis | Konfigurowalny |
|---|---|---|
| Niska wartość pewności | Niepewność agenta poniżej zdefiniowanego progu | Tak, per klient |
| Ryzyko dyskryminacji | Decyzje z potencjałem dyskryminacyjnym | Zawsze eskalowane |
| Kwestie konsultacyjne | Decyzje wymagające konsultacji z Radą Zakładową | Zawsze eskalowane |
| Przekroczenie progu wartości | Kwota powyżej limitu autonomicznego przetwarzania | Tak, per klient |
| Wprowadzenie nowej reguły | Pierwsze zastosowanie nowego zestawu reguł | W fazie uczenia |

## HITL jako techniczne zasada architektoniczna

W architekturze Gosign Human-in-the-Loop jest zaimplementowany w Decision Layer. Decyzja o tym, kiedy człowiek jest włączany, opiera się na trzech kryteriach:

**Confidence Routing:** Każda decyzja agenta ma wartość pewności. Jeśli pewność spada poniżej zdefiniowanego progu, następuje automatyczna eskalacja. Próg jest konfigurowalny dla każdego klienta.

**Klasyfikacja ryzyka:** Określone typy decyzji są zawsze eskalowane niezależnie od pewności. Decyzje z potencjałem dyskryminacyjnym, kwestie wymagające konsultacji, przekroczenia progów wartości.

**Regularna obowiązkowa eskalacja:** Nowe zestawy reguł stosowane po raz pierwszy zawsze przechodzą przez ludzką weryfikację w fazie wdrożeniowej. Dopiero po zwalidowanej fazie uczenia agent przechodzi w tryb autonomiczny - dla tej konkretnej reguły.

Wymaganie Human-in-the-Loop jest technicznie wymuszone. Nie ma obejścia, nie ma skrótu, nie ma nadpisania przez administratora. Agent nie może ominąć eskalacji.

## Jak HITL wyglada w praktyce

Agent HR przetwarza wniosek o premię. Document Agent odczytuje wniosek. Knowledge Agent sprawdza obowiązujące porozumienie zakładowe. Decision Layer ocenia:

Wynik: premia kwalifikuje się do zatwierdzenia zgodnie z porozumieniem zakładowym, paragraf 12, ust. 3. Pewność: 94%. Ryzyko: niskie.

Ale: decyzja dotyczy komponentu wynagrodzenia. W konfiguracji HITL zdefiniowano: decyzje o wynagrodzeniach są zawsze eskalowane, niezależnie od pewności. Workflow się zatrzymuje.

Odpowiedzialny pracownik widzi w dashboardzie: wniosek, propozycję agenta, zastosowaną regułę w aktualnej wersji, wartość pewności, powód eskalacji. Weryfikuje, potwierdza lub koryguje. Jego decyzja jest dokumentowana w Audit Trail, łącznie z informacją, że to była decyzja Human-in-the-Loop.

## HITL i Rada Zakladowa

Human-in-the-Loop to techniczna odpowiedź na wymóg organizacyjny: prawo do konsultacji. W Polsce Rada Zakładowa, działająca na podstawie Ustawy o radach pracowników (2006), ma prawo do informacji i konsultacji przy wdrażaniu systemów technicznych wpływających na warunki pracy. Związki zawodowe mogą negocjować szczegółowe warunki w porozumieniach zakładowych.

Decision Layer przekształca porozumienia zakładowe w techniczne constrainty. Jeśli porozumienie zakładowe stanowi: "Decyzje o ocenach pracowniczych nie mogą być podejmowane w pełni automatycznie" - to jest to implementowane jako reguła HITL w Decision Layer. Agent nie może ominąć tej reguły.

Wynik: Rada Zakładowa może zweryfikować, że jej wymagania są technicznie egzekwowane - nie tylko organizacyjnie obiecane. W przeciwieństwie do niemieckiego modelu, gdzie Rada ma prawo weta, w Polsce prawo do konsultacji nie blokuje wdrożenia, ale pracodawca musi wykazać, że uwzględnił stanowisko Rady. Decision Layer dokumentuje ten proces automatycznie.

## HITL i EU AI Act

EU AI Act wymaga nadzoru ludzkiego (Human Oversight, Art. 14) dla systemów AI wysokiego ryzyka. Procesy HR wyraźnie podlegają kategorii wysokiego ryzyka: rekrutacja, oceny wyników, awanse, wynagrodzenia, zwolnienia.

Human-in-the-Loop jako zasada architektoniczna spełnia wymagania EU AI Act dotyczące Human Oversight. Nie wystarczy mieć człowieka w procesie, który teoretycznie może interweniować. EU AI Act wymaga efektywnego nadzoru ludzkiego - to oznacza: człowiek musi być w stanie zrozumieć decyzję, musi móc ją zatrzymać, a jego interwencja musi być udokumentowana.

Decision Layer dokumentuje przy każdej decyzji HITL: kto weryfikował, kiedy, jaka była propozycja agenta, jaka była ludzka decyzja, czy się zgadzają czy różnią.

## Granice: czego HITL nie rozwiazuje

Human-in-the-Loop nie jest rozwiązaniem wszystkich problemów governance. Konkretnie:

HITL nie rozwiązuje problemu biasu w danych treningowych. Jeśli model językowy jest systematycznie uprzedzony, pracownik nie wykryje tego na podstawie pojedynczych przypadków. Do tego potrzebny jest statystyczny monitoring biasu obejmujący wszystkie decyzje agentów.

HITL nie skaluje się liniowo. Jeśli agent podejmuje 10 000 decyzji dziennie i 20% jest eskalowanych, potrzebujesz zasobów na 2000 ręcznych weryfikacji. Progi HITL muszą być skalibrowane tak, aby wskaźnik eskalacji pozostał zarządzalny bez kompromisów w governance.

HITL to jeden element architektury governance - obok [Audit Trail](/pl/magazyn/decision-layer-wyjasnienie/), monitoringu biasu, wersjonowania zestawów reguł i kontroli Cert-Ready.

Więcej na ten temat: [Konsultacja i AI](/pl/governance/co-determination/)

<a href="/pl/kontakt/" target="_blank" rel="noopener noreferrer">Umów spotkanie</a> - Pokażemy, jak Human-in-the-Loop wygląda w Twojej architekturze.

--- Enterprise AI-Infrastruktura Blueprint 2026 ---
> Osiem kluczowych decyzji dotyczących infrastruktury AI. Modele, hosting, interfejsy, agenci, orkiestracja, governance, koszty, regulacje.

## Dlaczego ten Blueprint

Integracja AI w procesach biznesowych przestała być projektem innowacyjnym i stała się koniecznością operacyjną. Kto w 2026 roku nie ma konkretnego planu, nie tylko traci przewagę nad konkurencją - wypada z rynku. Jednocześnie krajobraz decyzyjny znacznie się skomplikował: więcej modeli, więcej opcji hostingu, więcej regulacji, więcej platform orkiestracyjnych.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">W skrócie - Infrastruktura AI Enterprise 2026</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Osiem strategicznych decyzji, które każdy CTO lub CIO musi podjąć w ciągu 90 dni, aby wdrożyć AI na skalę enterprise.</li>
<li>Wybór modelu, poziom hostingu, portal AI, RAG, agenci, Decision Layer, compliance i orkiestracja tworzą kompletny stack.</li>
<li>Hybrydowa architektura hostingu - routing zapytań według wrażliwości danych przez chmurę, europejskie IaaS i on-premises - stała się standardem.</li>
<li>IDC (2025) prognozuje światowe wydatki na infrastrukturę AI na poziomie 154 miliardów USD do 2027 roku, w porównaniu z 76 miliardami w 2024.</li>
<li>Konkretny 90-dniowy plan działania przekształca projekty pilotażowe w produktywną infrastrukturę z wbudowaną governance od samego początku.</li>
</ul>
</div>

Ten Blueprint redukuje tę złożoność do ośmiu konkretnych decyzji, które każdy lider techniczny musi podjąć w ciągu najbliższych 90 dni.

Każda z tych decyzji jest szczegółowo omówiona w osobnym artykule - z tabelami porównawczymi, drzewami decyzyjnymi i konkretnymi rekomendacjami. Bez marketingu, bez buzzwordów. Fakty, architektura, wskazówki do działania.

## Osiem decyzji

### Decyzja 1: Który model AI pasuje do Twojego przypadku użycia?

Krajobraz modeli zmienił się fundamentalnie od 2024 roku. Claude, GPT-5, Gemini 3, Llama 4, gpt-oss, DeepSeek - różnice nie leżą już w jakości, lecz w specjalizacji, ochronie danych i strukturze kosztów. Właściwa odpowiedź to nie jeden model, lecz architektura agnostyczna wobec modeli, która routuje zadania do odpowiedniego modelu.

**[Czytaj dalej: Modele AI 2026 - Który model do jakiego zastosowania?](/pl/magazyn/modele-ai-porownanie-2026/)**

### Decyzja 2: Gdzie działają Twoje modele AI?

EU-SaaS, europejskie centrum danych czy Self-Hosted - ta decyzja determinuje Twoje gwarancje ochrony danych, strukturę kosztów i zależność od dostawców zewnętrznych. Strategia hybrydowa, w której warstwa routingu automatycznie rozdziela zapytania według wrażliwości danych, stała się standardem.

**[Czytaj dalej: Hosting AI - EU-SaaS, centrum danych w UE czy Self-Hosted?](/pl/magazyn/hosting-ai-strategie-enterprise/)**

Po podjęciu decyzji o hostingu następuje zabezpieczenie umowne. Standardowa umowa powierzenia nie wystarczy dla infrastruktury AI - [nasz katalog wymagań](/pl/magazyn/umowa-powierzenia-ai-lista-kontrolna/) identyfikuje dziesięć luk i zawiera 25 pytań weryfikacyjnych dla działu prawnego i compliance.

### Decyzja 3: Jak udostępnić AI wszystkim pracownikom bez utraty kontroli?

Model językowy bez kontrolowanego interfejsu to jak serwer bez frontendu. Pracownicy korzystają wtedy z publicznych narzędzi AI - bez kontroli, bez logowania, bez zgodności z RODO. Enterprise AI Portal oferuje lepszą alternatywę: Multi-Model-Routing, współdzielenie asystentów, integracja agentów, SSO i pełny Audit Trail.

> **Artykuł 3: Enterprise AI Portale** - Pięć open-source'owych interfejsów w porównaniu: LobeChat, OpenWebUI, LibreChat, chatbot-ui i very-ai. Który portal ma SSO, ochronę PII i Audit Trail? (Informacja o przejrzystości: very-ai jest rozwijany przez Gosign.)

**[Czytaj dalej: Enterprise AI Portale - Pięć open-source'owych interfejsów w porównaniu](/pl/magazyn/enterprise-ai-chat-interface/)**

### Decyzja 4: Jak udostępnić wiedzę firmową dla AI?

RAG (Retrieval Augmented Generation) umożliwia przeszukiwanie dokumentów bez przekazywania danych dostawcom modeli. Document Intelligence idzie dalej: anonimizacja PII, maskowanie umów, automatyczna weryfikacja compliance.

**[Czytaj dalej: RAG i Document Intelligence - Jak AI rozumie Twoje dokumenty](/pl/magazyn/rag-document-intelligence-enterprise/)**

### Decyzja 5: Jak zamienić chatboty w prawdziwych agentów?

Przejście od interfejsu czatu do autonomicznych procesów, które przetwarzają dokumenty, obsługują systemy i przygotowują decyzje, wymaga innej architektury. Protokoły MCP i A2A, systemy multi-agentowe i jasne wymagania governance decydują o powodzeniu.

**[Czytaj dalej: Od chatbotów do AI-agentów - MCP, A2A i systemy multi-agentowe](/pl/magazyn/agenci-ai-enterprise-przewodnik/)**

### Decyzja 6: Jak oddzielić analizę od decyzji?

Decision Layer rozkłada procesy biznesowe na mikro-decyzje i definiuje z góry dla każdej z nich: Czy decyduje człowiek, zestaw reguł, czy AI samodzielnie? Tam, gdzie decyzja jest deterministyczna, agent stosuje reguły konsekwentnie. Tam, gdzie agent jest wystarczająco pewny: decyduje samodzielnie - to nie jest if-then-else, to zdolność oceny w ramach zdefiniowanych ram. To architektura, która przekonuje Radę Zakładową, zadowala audytorów i umożliwia skalowanie.

**[Czytaj dalej: Decision Layer i Shadow AI - kontrola zamiast utraty kontroli](/pl/magazyn/decision-layer-shadow-ai/)**

### Decyzja 7: Czego wymaga EU AI Act - teraz, nie kiedyś?

Okres przejściowy się skończył. Od lutego 2025 obowiązują pierwsze zakazy i wymóg AI-Literacy. Zgodnie z obowiązującym prawem przepisy dotyczące systemów wysokiego ryzyka zaczną obowiązywać 2 sierpnia 2026 r., jednak na mocy wstępnego porozumienia Digital Omnibus z 7 maja 2026 r. mają zostać przesunięte na 2 grudnia 2027 r. (formalne przyjęcie wciąż w toku, stan na czerwiec 2026 r.). Klasyfikacja wysokiego ryzyka pozostaje w mocy, a kary sięgają 35 milionów euro lub 7% rocznego obrotu - prawdopodobny dodatkowy czas warto wykorzystać na rzetelne przygotowanie. Dla polskich firm, jako członków UE, te regulacje obowiązują bezpośrednio.

**[Czytaj dalej: EU AI Act 2026 - Co obowiązuje, co nadchodzi, co musisz zrobić](/pl/magazyn/eu-ai-act-2026-przedsiebiorstwa/)**

### Decyzja 8: Na jakiej platformie orkiestrowujesz swoich agentów?

n8n do szybkich prototypów, Camunda do procesów wymagających compliance, Temporal do złożonych długoterminowych workflowów - platforma orkiestracyjna decyduje, czy Twoja architektura agentów skaluje się, czy utknęła na etapie PoC.

**[Czytaj dalej: Orkiestracja agentów - n8n, Camunda i alternatywy](/pl/magazyn/orkiestracja-agentow-platformy/)**

## Osiem decyzji w skrócie

<table>
<thead>
<tr><th>Decyzja</th><th>Temat</th><th>Kluczowe pytanie</th></tr>
</thead>
<tbody>
<tr><td>1</td><td>Wybór modelu AI</td><td>Który model do jakiego zadania? Model-agnostyczny routing.</td></tr>
<tr><td>2</td><td>Strategia hostingu</td><td>EU SaaS, europejskie centrum danych czy Self-Hosted?</td></tr>
<tr><td>3</td><td>Enterprise AI Portal</td><td>Kontrolowany interfejs z SSO, Audit Trail, ochroną PII.</td></tr>
<tr><td>4</td><td>RAG & Document Intelligence</td><td>Jak udostępnić wiedzę firmową dla AI?</td></tr>
<tr><td>5</td><td>AI Agents</td><td>Od chatbota do autonomicznego agenta wielokrokowego.</td></tr>
<tr><td>6</td><td>Decision Layer</td><td>Oddzielenie analizy AI od decyzji biznesowych.</td></tr>
<tr><td>7</td><td>Koszty i EU AI Act</td><td>TCO i obowiązki regulacyjne od sierpnia 2025.</td></tr>
<tr><td>8</td><td>Orkiestracja agentów</td><td>n8n, Camunda lub Temporal dla produkcyjnych workflow.</td></tr>
</tbody>
</table>

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Darmowy eBook: Infrastruktura AI</p>
<p class="text-body text-gosign-text mb-4">Build, Buy, Hybrid - infrastruktura zgodna z EU AI Act z B/B/H-Framework i 7-Layer Reference Architecture.</p>
<a href="/pl/ebook/ai-infrastructure-poradnik-governance/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Pobierz za darmo</a>
</div>

## Dla kogo ten Blueprint jest napisany

Ten Blueprint jest skierowany do decydentów technicznych w firmach powyżej 500 pracowników:

- **CTO i VP Engineering**, którzy muszą zbudować lub skonsolidować architekturę AI
- **CIO**, którzy muszą pogodzić strategię AI z governance IT i istniejącym krajobrazem systemowym
- **Dyrektorzy HR i COO**, którzy integrują AI w procesy operacyjne - od przetwarzania dokumentów po zarządzanie wiedzą
- **Techniczni liderzy C-Level**, którzy chcą podejmować świadome decyzje, zamiast kolekcjonować projekty pilotażowe

Blueprint zakłada, że faza eksperymentowania jest za Tobą. Nie chodzi o to, czy wdrożyć AI, lecz jak - z jaką architekturą, jaką [governance](/pl/governance/) i jaką strategią operacyjną.

## 90-dniowy plan działania

Blueprint kończy się konkretnym planem działania w trzech fazach:

### Faza 1: Fundament (Tygodnie 1--4)

- Sporządzenie inwentaryzacji systemów AI (co jest już w użyciu?)
- Przeprowadzenie klasyfikacji danych
- Identyfikacja jednego przypadku użycia (najwyższy ROI przy najniższym ryzyku)
- Podjęcie decyzji o hostingu (poziom 1, 2 lub 3)
- Wdrożenie wewnętrznego portalu AI (LobeChat, OpenWebUI, very-ai lub LibreChat)

Warstwa prezentacji - Enterprise AI Portal - ma w 2026 roku pięć opcji open-source. Gosign opracował very-ai, portal który dodaje ochronę PII i synchronizację grup Entra ID jako funkcje enterprise (-> Artykuł 3). Jak przy wszystkich rekomendacjach w tej serii: oceń kilka opcji w kontekście Twojej organizacji.

Rezultat: Twoi pracownicy mają kontrolowane narzędzie AI zamiast Shadow AI.

### Faza 2: Pierwszy agent (Tygodnie 5--8)

- Implementacja przypadku użycia jako agenta
- Połączenie MCP z 1--2 istniejącymi systemami
- Zdefiniowanie reguł decyzyjnych
- Wdrożenie Human-in-the-Loop dla krytycznych kroków
- Wyznaczenie grupy pilotażowej 10--20 użytkowników

Rezultat: Działający agent, który usprawnia realny proces biznesowy.

### Faza 3: Governance i skalowanie (Tygodnie 9--12)

- Walidacja Audit Trail i logowania
- Rozpoczęcie dokumentacji EU AI Act (ocena ryzyka, dokumentacja techniczna)
- Pomiar wyników pilotażu (oszczędność czasu, wskaźnik błędów, satysfakcja użytkowników)
- Stworzenie planu skalowania: które 3--5 przypadków użycia jako następne?

Rezultat: Zwalidowany business case i jasna ścieżka do skalowania.

Plan jest celowo kompaktowy. W 90 dni nie osiągniesz pełnej transformacji AI, ale będziesz mieć produktywną infrastrukturę, działającego agenta i podstawy governance, by bezpiecznie skalować.

---

**Dalsze informacje:** [Infrastruktura AI - przegląd usług](/pl/uslugi/infrastruktura/) | [Decision Layer - wyjaśnienie](/pl/decision-layer/) | [AI Agents](/pl/uslugi/ai-agents/)

---

**Enterprise AI-Infrastruktura Blueprint 2026 - Seria artykułów**

| Poprzedni | Przegląd | Następny |
|:---|:---:|---:|
| - | Jesteś na stronie przeglądu | [Modele AI 2026: Który model do jakiego zastosowania?](/pl/magazyn/modele-ai-porownanie-2026/) |

*Wszystkie artykuły z tej serii: [Enterprise AI-Infrastruktura Blueprint 2026](/pl/magazyn/infrastruktura-ai-blueprint-2026/)*

---

**Nie chcesz podejmować tych ośmiu decyzji sam?** Gosign wspiera klientów enterprise od architektury po produktywne wdrożenie - agnostycznie wobec modeli, neutralnie wobec dostawców, z pełnym dostępem do kodu źródłowego.

<a href="/pl/kontakt/" target="_blank" rel="noopener noreferrer">Umów konsultację</a>. 30 minut, w których wyjaśnimy Twoje konkretne potrzeby.

--- Integracja infrastruktury AI z istniejącym krajobrazem IT ---
> Jak agenci AI i LLM integrują się z SAP, Workday i środowiskami chmurowymi - bez greenfield, bez Shadow IT, bez migracji platform.

## Problem integracji

Większość firm nie ma pustego krajobrazu IT. Mają SAP, [Workday](https://www.workday.com/), [SuccessFactors](https://www.sap.com/products/hcm.html), SharePoint, systemy branżowe, historycznie narosłe middleware i ugruntowane architektury bezpieczeństwa. To nie jest przeszkoda dla AI - to rzeczywistość, do której AI musi się dopasować.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">W skrócie - Integracja AI z istniejącą infrastrukturą IT</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Infrastruktura AI to warstwa integracyjna na istniejących systemach - SAP, Workday i środowiska chmurowe pozostają niezmienione.</li>
<li>Cztery warstwy architektoniczne: łączność z systemami, orkiestracja, Decision Layer i interfejs użytkownika.</li>
<li>Agenci komunikują się przez standardowe API (RFC, OData, REST) - bez bezpośredniego dostępu do baz danych, bez proprietarnych interfejsów.</li>
<li>McKinsey (2024) podaje, że 74% projektów AI w enterprise nie przechodzi poza fazę pilotażową - głównie z powodu luk integracyjnych.</li>
<li>Istniejące polityki bezpieczeństwa, autentykacja i procesy audytowe pozostają w pełni obowiązujące - agent jest dodatkowym uczestnikiem, nie systemem równoległym.</li>
</ul>
</div>

Najczęstszą przyczyną porażek projektów AI w firmach nie jest technologia. Przyczyną jest to, że AI jest wdrażane jako izolowany system - obok istniejącego IT, a nie w nim. To generuje Shadow IT, silosy danych i luki w governance.

Właściwe podejście: infrastruktura AI jako warstwa integracyjna, która łączy istniejące systemy zamiast je zastępować.


## Zasada architektoniczna: warstwa integracyjna, nie migracja platform

Korporacyjna infrastruktura AI składa się z czterech warstw, które wpasowują się w każdy istniejący krajobraz IT.

Najniższa warstwa to łączność z systemami. Konektory do SAP (przez RFC, OData, BAPIs), do Workday (przez REST API), do SharePoint, systemów pocztowych i aplikacji branżowych. Te konektory odczytują i zapisują dane - systemy źródłowe pozostają niezmienione.

Nad nią znajduje się warstwa orkiestracji. Tu działają [agenci AI](/pl/uslugi/ai-agents/): Document Agents, którzy czytają i klasyfikują przychodzące dokumenty. Workflow Agents, którzy sterują procesami międzysystemowymi. Knowledge Agents, którzy odpowiadają na pytania na podstawie wiedzy korporacyjnej.

Trzecia warstwa to [Decision Layer](/pl/decision-layer/). Oddziela analizę AI od decyzji biznesowej. Model rekomenduje, człowiek decyduje. Każda decyzja jest dokumentowana, wersjonowana i podlega audytowi.

Najwyższa warstwa to interfejs: ujednolicony interfejs czatu dla pracowników lub bezpośrednia integracja system-system bez interakcji człowieka.


## Konkretnie: jak agent AI jest integrowany z krajobrazem SAP

Przykład z praktyki: przetwarzanie zwolnień lekarskich.

Pracownik przesyła zwolnienie lekarskie mailem lub przez portal. Document Agent rozpoznaje typ dokumentu, wyodrębnia istotne pola (imię, okres, grupa diagnozy) i waliduje dane z porozumieniem zakładowym. Przez konektor SAP sprawdza dane kadrowe, oblicza wynagrodzenie za czas choroby i przygotowuje księgowanie.

W tym momencie włącza się Decision Layer: jeśli przypadek mieści się w automatyzowalnych regułach (przypadek standardowy, brak anomalii), księgowanie jest przedstawiane odpowiedzialnemu specjaliście do zatwierdzenia. Jeśli wykryta zostanie anomalia (powtarzalność, przekroczenie terminu, brak danych), sprawa jest eskalowana.

Instancja SAP nie została w żadnym momencie zmodyfikowana. Agent działa jako zewnętrzna warstwa integracyjna komunikująca się przez standardowe API. Istniejące koncepcje uprawnień, strefy sieciowe i procesy audytowe pozostają bez zmian.


## Co musi zapewniać architektura IT

Dla czystej integracji infrastruktura AI wymaga czterech właściwości.

Po pierwsze: API-first. Cała komunikacja między agentem a systemem źródłowym odbywa się przez udokumentowane API. Żadnych bezpośrednich dostępów do baz danych, żadnych proprietarnych interfejsów.

Po drugie: wielomandantowość. W strukturach koncernowych agenci muszą być konfigurowalni per spółka - różne reguły, różne systemy, różne wymogi compliance dla każdej jednostki.

Po trzecie: logowanie i audyt. Każda interakcja między agentem a systemem źródłowym jest logowana - kto co i kiedy odczytał, zapisał, zdecydował. To nie jest opcjonalne, to fundament [Governance by Design](/pl/governance/).

Po czwarte: możliwość cofnięcia. Jeśli agent popełni błąd, każda akcja musi być odwracalna. To wymaga komunikacji transakcyjnej z systemami źródłowymi.


## Przegląd warstw integracji

<table>
<thead>
<tr><th>Warstwa</th><th>Funkcja</th><th>Technologia</th></tr>
</thead>
<tbody>
<tr><td>Łączność z systemami</td><td>Odczyt/zapis w systemach źródłowych</td><td>SAP RFC/OData, Workday REST, Microsoft Graph</td></tr>
<tr><td>Orkiestracja</td><td>Koordynacja agentów i workflow</td><td>Trigger.dev, Camunda, n8n</td></tr>
<tr><td>Decision Layer</td><td>Oddzielenie analizy AI od decyzji biznesowych</td><td>Rules Engine, Confidence Routing, Human-in-the-Loop</td></tr>
<tr><td>Interfejs</td><td>Dostęp pracowników lub system-system</td><td>Enterprise AI Portal, REST API</td></tr>
</tbody>
</table>

## Żadnego greenfield, żadnej migracji platform

Najczęstszy zarzut CIO: "Nie możemy wprowadzić kolejnego systemu." I ten zarzut jest uzasadniony.

Dlatego infrastruktura AI nie jest nowym systemem w tradycyjnym sensie. Jest warstwą, która wpasowuje się w istniejącą architekturę. SAP pozostaje SAP. Workday pozostaje Workday. Architektura sieciowa pozostaje na miejscu. Polityki bezpieczeństwa pozostają obowiązujące. Agent jest dodatkowym uczestnikiem w istniejącym ekosystemie - podlegającym tym samym regułom, tym samym kontrolom, tym samym wymogom audytowym.

W Gosign budujemy [infrastrukturę AI](/pl/uslugi/infrastruktura/) jako warstwę integracyjną: na Azure, GCP lub Self-Hosted, połączoną z systemami, które już istnieją. Żadnego Shadow IT. Agenci stają się częścią istniejącego [IT governance](/pl/governance/) - nie nowym równoległym światem.

--- Infrastruktura AI zamiast hype: Enterprise Stack ---
> Narzędzia AI vs. infrastruktura AI: orkiestracja, governance, model-agnostyk, Audit Trail. Dlaczego firmy potrzebują własnej warstwy.

## Narzędzie vs. infrastruktura

ChatGPT, Microsoft CoPilot, Google Gemini - to są narzędzia AI. Wpisujesz pytanie, dostajesz odpowiedź. Dla indywidualnej produktywności to działa. Dla procesów enterprise - nie.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">W skrócie - Infrastruktura AI zamiast narzędziowego hype</p>
<ul class="text-body text-gosign-text space-y-2">
<li>ChatGPT, CoPilot i Gemini to narzędzia AI - nie infrastruktura enterprise. Brakuje Audit Trail, izolacji klientów i integracji systemowej.</li>
<li>Infrastruktura AI enterprise składa się z siedmiu warstw: Presentation, Orchestration, Agent, Decision, Model, Integration i Infrastructure.</li>
<li>Gartner (2024) podaje, że ponad 55% organizacji, które wdrożyły narzędzia AI bez governance, musiało przebudować swoje podejście w ciągu 18 miesięcy.</li>
<li>Architektura model-agnostyczna zapobiega vendor lock-in i utrzymuje wymienność modeli - Claude, GPT, Gemini, Llama, Mistral.</li>
<li>Po 12 do 18 miesiącach klient samodzielnie obsługuje infrastrukturę z pełnym dostępem do kodu źródłowego i bez powtarzającej się zależności od dostawcy.</li>
</ul>
</div>

Różnica między narzędziem AI a infrastrukturą AI jest porównywalna z różnicą między arkuszem kalkulacyjnym a systemem ERP. Arkusz kalkulacyjny rozwiązuje konkretny problem dla pojedynczego użytkownika. System ERP to infrastruktura, na której działają procesy biznesowe całej firmy.

Infrastruktura AI to warstwa architektoniczna między modelem językowym a systemem enterprise. Obejmuje: hosting modeli, orkiestrację, Decision Layer, governance, integrację z istniejącymi systemami. Model językowy to jeden element tej infrastruktury - nie sama infrastruktura.

## Czego brakuje narzędziu AI

Gdy firma używa ChatGPT do przetwarzania dokumentów, brakuje:

**Audit Trail:** Brak dokumentacji, jaka decyzja została podjęta na jakiej podstawie. Przy kontroli nic nie jest możliwe do prześledzenia.

**Wersjonowane zestawy reguł:** ChatGPT nie zna specyficznych dla klienta reguł księgowych w wersji 4.2. Ma ogólną wiedzę o rachunkowości, ale nie ma konkretnych zestawów reguł klienta.

**Izolacja klientów:** Dane wszystkich klientów płyną do tego samego systemu. Brak Row-Level Security, brak separacji workspace.

**Integracja:** ChatGPT nie może utworzyć księgowania w SAP, wyzwolić workflow w [Trigger.dev](https://trigger.dev/), ani przekazać eskalacji do pracownika.

**Human-in-the-Loop:** Brak architektonicznie wymuszonej ludzkiej weryfikacji. Brak reguł eskalacji. Brak progów pewności.

**Model-agnostyk:** Kto buduje na ChatGPT, jest związany z OpenAI. Jeśli OpenAI podniesie ceny, zmieni API lub zakończy usługę, firma nie ma alternatywy.

## Siedem warstw infrastruktury AI enterprise

Architektura referencyjna Gosign opisuje siedem warstw:

**Presentation Layer:** Interfejs czatu, dashboard, Portal Audytora, REST API. Interfejs między systemem a użytkownikiem.

**Orchestration Layer:** Silnik workflow (Trigger.dev lub [Camunda](https://camunda.com/)), API gateway, zarządzanie kolejkami. Koordynuje przepływ danych między wszystkimi komponentami.

**Agent Layer:** Wyspecjalizowani agenci - Document Agents, Workflow Agents, Knowledge Agents. Każdy agent ma zdefiniowany zakres odpowiedzialności.

**Decision Layer:** Rozkłada każdy proces na kroki decyzyjne. Dla każdego kroku definiuje: człowiek, zestaw reguł lub AI. Zawiera Rules Engine (wersjonowane zestawy reguł), Confidence Routing (automatyczna ocena ryzyka), Human-in-the-Loop (technicznie wymuszony) i Audit Trail (niezmienny protokół decyzji).

**Model Layer:** Modele językowe. Wymienne, model-agnostyczne. Claude, ChatGPT, Gemini, Llama, Mistral, DeepSeek, gpt-oss.

**Integration Layer:** Połączenie z istniejącymi systemami. SAP, [Comarch](https://www.comarch.pl/), [Workday](https://www.workday.com/), [SuccessFactors](https://www.sap.com/products/hcm.html), SharePoint.

**Infrastructure Layer:** Deployment. Azure, GCP, Self-Hosted, Hybrid.

Warstwa Governance przebiega jako przekrój przez wszystkie siedem warstw.

## Narzędzie AI vs. infrastruktura AI

<table>
<thead>
<tr><th>Zdolność</th><th>Narzędzie AI (ChatGPT)</th><th>Infrastruktura AI</th></tr>
</thead>
<tbody>
<tr><td>Audit Trail</td><td>Nie</td><td>Niezmienny protokół decyzji</td></tr>
<tr><td>Izolacja klientów</td><td>Nie</td><td>Row-Level Security, separacja workspace</td></tr>
<tr><td>Integracja ERP</td><td>Nie</td><td>SAP, Comarch, Workday przez API</td></tr>
<tr><td>Wersjonowane zestawy reguł</td><td>Nie</td><td>Specyficzne dla klienta, wersjonowane</td></tr>
<tr><td>Human-in-the-Loop</td><td>Nie</td><td>Architektonicznie wymuszone</td></tr>
<tr><td>Niezależność od modeli</td><td>Przywiązanie do jednego dostawcy</td><td>Model-agnostyczny routing</td></tr>
<tr><td>Warstwa governance</td><td>Niedostępna</td><td>Przekrój przez wszystkie warstwy</td></tr>
</tbody>
</table>

## Przewaga infrastruktury

Z własną infrastrukturą AI firma zyskuje:

**Kontrolę:** Dane pozostają we własnej infrastrukturze. Modele są wymienne. Pełny dostęp do zestawów reguł i konfiguracji.

**Skalowalność:** Jeden agent dla jednego procesu to PoC. Infrastruktura umożliwia wdrażanie kolejnych agentów dla kolejnych procesów - z tą samą governance.

**Niezależność:** Po 12-18 miesiącach klient samodzielnie obsługuje infrastrukturę. Pełny dostęp do kodu źródłowego, wszystkich promptów i zestawów reguł. Brak vendor lock-in.

Więcej na ten temat: [Infrastruktura AI](/pl/uslugi/infrastruktura/)

Więcej o [agentach AI w kontekście enterprise](/pl/magazyn/agenci-ai-enterprise-przewodnik/).

<a href="/pl/kontakt/" target="_blank" rel="noopener noreferrer">Umów spotkanie</a> - Pokażemy, jak wygląda infrastruktura AI dla Twojej firmy.

--- Integracja AI z krajobrazem IT: SAP, Comarch, Workday ---
> Agenci AI w SAP, Comarch, Workday: Integration Layer, separacja API, logika księgowa oddzielona od warstwy eksportu.

## Zasada: rozszerzać, nie zastępować

Agenci AI nie zastępują istniejących systemów. Rozszerzają je. SAP pozostaje SAP. Comarch pozostaje Comarch. Workday pozostaje Workday. Agent siedzi pomiędzy: odczytuje dane, podejmuje decyzje i zapisuje wyniki z powrotem.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">W skrócie - Integracja AI z systemami enterprise</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Agenci AI rozszerzają istniejące systemy (SAP, Comarch, Workday) zamiast je zastępować - agent jest zewnętrzną warstwą integracyjną.</li>
<li>Integration Layer oddziela logikę agenta od systemu docelowego: gdy ERP się zmienia, zmienia się tylko warstwa eksportu.</li>
<li>Logika księgowa (Decision Layer) jest architektonicznie oddzielona od formatu eksportu (Integration Layer), co redukuje nakład migracji.</li>
<li>Forrester (2024) stwierdza, że firmy ze strategią integracji API-first wdrażają AI 2,4 razy szybciej niż te polegające na niestandardowych konektorach.</li>
<li>Agenci korzystają z istniejącej autentykacji, środowiska chmurowego, polityk bezpieczeństwa i monitoringu - bez systemu równoległego.</li>
</ul>
</div>

Ta zasada jest kluczowa dla akceptacji w środowiskach enterprise. Dyrektorzy IT nie inwestują w równoległy świat. Inwestują w warstwę, która czyni ich istniejący krajobraz IT inteligentniejszym.

## Integration Layer

Integration Layer w architekturze referencyjnej Gosign oddziela logikę agenta od systemu docelowego. To ma konkretną zaletę: gdy system docelowy się zmienia, zmienia się tylko warstwa eksportu - nie agent.

**[SAP FI/CO i S/4HANA](https://www.sap.com/products/erp/s4hana.html):** Propozycje księgowań w formacie SAP. Logika centrów kosztów i centrów zysku. Integracja przez RFC, REST API lub SAP BTP.

**[Comarch ERP](https://www.comarch.pl/erp/):** Propozycje księgowań w formacie Comarch. Plany kont zgodne z polską Ustawą o rachunkowości. Eksport przez interfejs Comarch. Dla polskich firm Comarch jest często pierwszym wyborem jako system ERP.

**[Workday](https://www.workday.com/):** Dane HR, informacje płatnicze, struktura organizacyjna. Integracja przez Workday REST API.

**[SuccessFactors](https://www.sap.com/products/hcm.html):** Dane pracowników, dane o wynikach, wynagrodzenia. Integracja przez SAP SuccessFactors API.

**[Microsoft Graph](https://learn.microsoft.com/en-us/graph/overview):** SharePoint, Teams, Outlook. Dla Knowledge Agents uzyskujących dostęp do dokumentów firmowych.

## Separacja: logika ksiegowa vs. warstwa eksportu

Oddzielenie logiki księgowej od warstwy eksportu to centralna zasada architektoniczna. Logika księgowa - jakie konto, jakie centrum kosztów, jaka stawka podatkowa - jest zaimplementowana w Decision Layer. Warstwa eksportu - jak wynik jest przekazywany do Comarch lub SAP - jest w Integration Layer.

Gdy klient przechodzi z Comarch na SAP, zmienia się warstwa eksportu. Logika księgowa, zestawy reguł, agent - wszystko pozostaje bez zmian. To znacząco redukuje nakład pracy przy migracji.

W kontekście polskim ta separacja jest szczególnie istotna: polskie wymogi rachunkowości (Ustawa o rachunkowości, KSR) są implementowane w Decision Layer jako zestawy reguł, niezależnie od tego, czy system docelowy to SAP, Comarch czy inny system ERP.

## Integration Layer według systemu docelowego

<table>
<thead>
<tr><th>System docelowy</th><th>Metoda integracji</th><th>Zakres danych</th></tr>
</thead>
<tbody>
<tr><td>SAP FI/CO, S/4HANA</td><td>RFC, REST API, SAP BTP</td><td>Propozycje księgowań, logika centrów kosztów</td></tr>
<tr><td>Comarch ERP</td><td>Interfejs Comarch</td><td>Propozycje księgowań, plany kont</td></tr>
<tr><td>Workday</td><td>Workday REST API</td><td>Dane HR, płace, struktura organizacyjna</td></tr>
<tr><td>SuccessFactors</td><td>SAP SuccessFactors API</td><td>Dane pracowników, wyniki, wynagrodzenia</td></tr>
<tr><td>Microsoft Graph</td><td>Graph API</td><td>SharePoint, Teams, Outlook</td></tr>
</tbody>
</table>

## Bez systemu równoległego

Agenci stają się częścią istniejącego zarządzania IT - nie nowym równoległym światem. To oznacza:

- Agenci korzystają z istniejącej autentykacji (Azure Entra ID, LDAP)
- Agenci działają w istniejącym środowisku chmurowym (Azure, GCP)
- Agenci podlegają istniejącym politykom bezpieczeństwa
- Agenci są integrowani z istniejącymi systemami monitoringu

Dla dyrektora IT agent AI to kolejny komponent w istniejącej architekturze - nie oddzielny system z własnymi regułami.

Więcej na ten temat: [Architektura referencyjna](/pl/governance/reference-architecture/)

Więcej o [infrastrukturze AI](/pl/uslugi/infrastruktura/) i opcjach integracji.

<a href="/pl/kontakt/" target="_blank" rel="noopener noreferrer">Umów spotkanie</a> - Pokażemy integrację z Twoim istniejącym krajobrazem IT.

--- Ile naprawdę kosztuje AI: porównanie TCO dla firm ---
> Ceny tokenów są mylące. Cztery kategorie kosztów enterprise AI - z trzema scenariuszami od 120 000 do 1 900 000 PLN.

## Ceny tokenów to nie Twoje koszty AI

Gdy firmy rozmawiają o kosztach AI, dyskusja niemal zawsze zaczyna się od cen tokenów. To zrozumiałe: dostawcy reklamują swoje modele cenami za milion tokenów na wejściu i wyjściu, a te liczby łatwo porównać. Model flagowy kosztuje 5 dolarów za milion tokenów wejściowych, model budżetowy 0,25 dolara - różnica wygląda dramatycznie.

Ale ceny tokenów stanowią w praktyce tylko 20 do 35 procent rzeczywistych kosztów. Kto redukuje planowanie budżetu AI do cen tokenów, niedoszacowuje całkowite koszty trzy- do pięciokrotnie. Właściwe pytanie nie brzmi: "Ile kosztuje token?" Pytanie brzmi: "Ile kosztuje produktywne, bezpieczne i zgodne z przepisami wykorzystanie AI w mojej firmie?"

Ten artykuł pokazuje cztery kategorie kosztów, które obejmuje każde wdrożenie enterprise AI, porównuje trzy scenariusze od 120 000 do 1 900 000 PLN w pierwszym roku i wyjaśnia, jak Model Switching może zaoszczędzić 40 do 60 procent kosztów tokenów.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">W skrócie - Prawdziwe koszty enterprise AI</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Ceny tokenów stanowią tylko 20 do 35% rzeczywistych kosztów. Infrastruktura, governance i personel to pozostałe 65 do 80%.</li>
<li>Trzy scenariusze: wstępny ~120 000 PLN (1 chatbot, 50 użytkowników), standardowy ~680 000 PLN (3 agenty, hybrid), enterprise ~1 900 000 PLN (10+ agentów, własne GPU).</li>
<li>Według Deloitte (2024) firmy planujące budżety AI wyłącznie na cenach tokenów niedoszacowują całkowite koszty średnio 3 do 5 razy.</li>
<li>Model Switching redukuje koszty tokenów o 40 do 60%, kierując proste zapytania do modeli budżetowych, a złożone do modeli flagowych.</li>
<li>Koszty infrastruktury koncentrują się w miesiącach 1 do 6; od drugiego roku dominują koszty modeli i personelu.</li>
</ul>
</div>

## Cztery kategorie kosztów

Każde wdrożenie AI w kontekście enterprise rozkłada się na cztery kategorie kosztów. Względne proporcje różnią się w zależności od scenariusza, ale struktura pozostaje taka sama.

### 1. Koszty modeli: tokeny i hosting (20-35%)

Najbardziej widoczna kategoria: opłaty za API chmurowe lub koszty hostingu dla modeli self-hosted. Przy API chmurowych płacisz za token - wejście i wyjście oddzielnie. Przy self-hostingu płacisz za wynajem GPU, prąd i utrzymanie. Koszty zależą bezpośrednio od wolumenu użycia: chatbot z 50 użytkownikami generuje inne wolumeny tokenów niż dziesięciu wyspecjalizowanych agentów z 1000 użytkowników.

Co często pomijane: self-hosting jest od pewnego wolumenu tańszy niż API chmurowe, ale koszty wejścia są wyższe. Pojedynczy GPU z 80 GB VRAM kosztuje u europejskiego dostawcy hostingowego ok. 5 500 PLN miesięcznie - niezależnie od tego, czy jest w pełni obciążony. Szczegóły dotyczące decyzji hostingowej opisuje artykuł o [strategiach hostingu AI](/pl/magazyn/hosting-ai-strategie-enterprise/).

### 2. Infrastruktura i integracja (25-35%)

Największa i najczęściej niedoszacowywana kategoria. Obejmuje wszystko, co jest potrzebne do wbudowania modelu językowego w istniejący krajobraz IT:

- **API Gateway i warstwa routingu:** Centralny punkt kierujący zapytania do odpowiedniego modelu, wymuszający limity i śledzący koszty.
- **Pipeline RAG:** Jeśli AI ma korzystać z wewnętrznej wiedzy, potrzebujesz pipeline Retrieval-Augmented Generation: baza wektorowa, model embeddingowy, strategia chunkowania, indeksowanie.
- **Integracja systemowa:** Połączenie z istniejącymi systemami - ERP, CRM, zarządzanie dokumentami, ticketing. Każdy interfejs wymaga nakładu rozwojowego.
- **Portal Enterprise AI:** Interfejs, przez który pracownicy faktycznie korzystają z AI - z SSO, zarządzaniem uprawnieniami i Audit Trail.

Te koszty są w dużej mierze jednorazowe. Powstają głównie w pierwszych trzech do sześciu miesiącach i amortyzują się w czasie. Ale muszą być zaplanowane i zabudżetowane - inaczej powstają ukryte koszty przez prowizorki i poprawki.

### 3. Governance i compliance (15-20%)

Od czasu [EU AI Act](/pl/magazyn/eu-ai-act-2026-przedsiebiorstwa/) governance nie jest już opcjonalnym luksusem. Koszty w tej kategorii obejmują:

- **Klasyfikacja ryzyka:** Ocena wszystkich systemów AI według kategorii EU AI Act. Dla systemów wysokiego ryzyka wymagana jest formalna ocena zgodności.
- **Dokumentacja techniczna:** EU AI Act wymaga obszernej dokumentacji pochodzenia danych, procedur treningowych, wskaźników wydajności i środków redukcji ryzyka.
- **Audit Trail i monitoring:** Bieżące protokołowanie wszystkich decyzji AI, szczególnie przy automatycznych procesach decyzyjnych.
- **Ochrona danych:** Przetwarzanie danych zgodne z RODO, umowy powierzenia przetwarzania, ocena skutków dla ochrony danych przy przetwarzaniu danych osobowych.
- **Doradztwo zewnętrzne:** Porady prawne w kwestiach regulacyjnych, Inspektor Ochrony Danych (IOD), ew. Conformity Assessment Body.

Udział governance rośnie z złożonością zastosowania AI. Pojedynczy chatbot do ogólnych pytań wiedzy ma niższe wymagania governance niż system AI wstępnie selekcjonujący aplikacje.

### 4. Personel i budowanie kompetencji (20-30%)

Systemy AI muszą być obsługiwane, utrzymywane i rozwijane. Jednocześnie pracownicy muszą być w stanie z nich korzystać. Ta kategoria obejmuje:

- **ML-Ops / AI Engineering:** Co najmniej jedna osoba odpowiedzialna za zarządzanie modelami, optymalizację promptów, monitoring i rozwiązywanie problemów. W scenariuszu enterprise dedykowany zespół.
- **AI Literacy:** Szkolenia dla wszystkich użytkowników - od lutego 2025 wymagane prawnie. Obejmuje szkolenia początkowe i regularne odświeżenia.
- **Change Management:** Towarzyszenie organizacji w procesie zmiany. Nowe procesy, nowe role, nowe odpowiedzialności.

W kontekście polskim warto uwzględnić, że koszty personelu są istotnie niższe niż w Europie Zachodniej, co obniża współczynnik TCO w kategorii personalnej. Jednocześnie popyt na specjalistów AI w Polsce dynamicznie rośnie.

### Rozkład kosztów w pigułce

```
Koszty modeli (tokeny/hosting)         ████████░░░░░░░░░░░░  20-35%
Infrastruktura i integracja            ██████████░░░░░░░░░░  25-35%
Governance i compliance                ██████░░░░░░░░░░░░░░  15-20%
Personel i budowanie kompetencji       ████████░░░░░░░░░░░░  20-30%
```

Rozkład przesuwa się w czasie: w pierwszym roku dominują infrastruktura i integracja. Od drugiego roku rosną względne udziały kosztów modeli i personelu, podczas gdy jednorazowe koszty integracji odpadają.

## Trzy scenariusze w porównaniu

Poniższe trzy scenariusze przedstawiają typowe punkty wejścia. Liczby są wartościami orientacyjnymi w PLN, opartymi na doświadczeniu projektowym z firmami różnej wielkości. Rzeczywiste koszty zależą od istniejącej [infrastruktury IT](/pl/uslugi/infrastruktura/), wymagań integracyjnych i wybranego modelu operacyjnego.

| Scenariusz | Model-Setup | Miesięczne tokeny/hosting | Integracja | Governance | Personel | Razem 12 mies. |
|---|---|---|---|---|---|---|
| **Wstępny:** 1 chatbot, 50 użytkowników | Sonnet API | ok. 2 300 PLN | 70 000 PLN | 23 000 PLN | 0 (wewnętrznie) | **ok. 120 000 PLN** |
| **Standardowy:** 3 agenty, 200 użytkowników | Sonnet + Llama self-hosted | ok. 18 000 PLN | 280 000 PLN | 92 000 PLN | 1 ML-Ops (częściowo) | **ok. 680 000 PLN** |
| **Enterprise:** 10+ agentów, 1000+ użytkowników | Multi-model, własne GPU | ok. 55 000 PLN | 690 000 PLN | 230 000 PLN | 2 FTE | **ok. 1 900 000 PLN** |

### Scenariusz 1: Wstępny (ok. 120 000 PLN / 12 miesięcy)

Jasno zdefiniowany przypadek użycia: wewnętrzny chatbot wiedzy dla jednego działu, oparty na API chmurowym. 50 użytkowników, umiarkowany wolumen zapytań, brak integracji systemowej poza uploadem dokumentów. Governance ogranicza się do przetwarzania danych zgodnego z RODO i podstawowej dokumentacji. Koszty personelu odpadają, bo wewnętrzny dział IT przejmuje obsługę obok bieżących zadań.

Ten scenariusz to typowy Proof of Concept. Dowodzi przydatności, waliduje technologię i dostarcza wartości doświadczalnych do skalowania. Prawidłowy PoC z jasno zdefiniowanym przypadkiem użycia to typowo 70 000 do 140 000 PLN i jest możliwy do realizacji w cztery do sześciu tygodni.

### Scenariusz 2: Standardowy (ok. 680 000 PLN / 12 miesięcy)

Trzech wyspecjalizowanych agentów do różnych procesów - przykładowo analiza dokumentów, komunikacja z klientami i wewnętrzne zarządzanie wiedzą. 200 użytkowników, hosting hybrydowy: niekrytyczne zapytania przez API chmurowe, wrażliwe dane przez model self-hosted. Integracja z co najmniej jednym istniejącym systemem. Governance obejmuje klasyfikację ryzyka EU AI Act i formalną dokumentację. Jeden ML-Ops Engineer zajmuje się częściowo zarządzaniem modelami i monitoringiem.

Ten scenariusz to produktywny start. Organizacja zakończyła PoC i skaluje na wiele działów. Infrastruktura jest przygotowana na wzrost.

### Scenariusz 3: Enterprise (ok. 1 900 000 PLN / 12 miesięcy)

Dziesięciu lub więcej wyspecjalizowanych agentów w wielu obszarach biznesowych. Ponad 1000 użytkowników. Architektura multi-model z własnymi GPU. Głęboka integracja z ERP, CRM, systemami HR i zarządzaniem dokumentami. Governance na poziomie enterprise: formalna ocena zgodności dla systemów wysokiego ryzyka, Audit Trail, dashboard governance. Dwóch pełnoetatowych ML-Ops Engineers do obsługi i rozwoju.

Ten scenariusz zakłada, że organizacja zakończyła fazę eksperymentalną i traktuje AI jako strategiczną infrastrukturę. 1 900 000 PLN brzmi jak znacząca inwestycja - i jest nią. Ale rozkłada się na system, który przyspiesza setki procesów, obniża wskaźniki błędów i poprawia podstawy decyzyjne.

### Kontekst: ile kosztują alternatywy?

Koszty systemu AI nigdy nie są oceniane w izolacji. Istotna wielkość porównawcza to: ile kosztują procesy bez AI? Jeśli trzech pracowników spędza po dwie godziny dziennie na klasyfikacji dokumentów, to przy pełnym rachunku kosztów ok. 350 000 PLN rocznie - za zadanie, które wytrenowany agent wykonuje w sekundy. ROI rzadko jest pytaniem. Pytanie brzmi, jak szybko się realizuje.

## Optymalizacja kosztow przez Model Switching

Najskuteczniejsza dźwignia przy kosztach modeli to nie wybór tańszego modelu, lecz zróżnicowane wykorzystanie wielu modeli. Ta zasada nosi nazwę Model Switching lub Model Routing.

### Zasada

Nie każde zapytanie wymaga modelu flagowego. Większość zapytań enterprise - standardowe odpowiedzi, prosta klasyfikacja, ekstrakcja danych ze strukturyzowanych dokumentów - może być obsługiwana przez modele budżetowe na wystarczającym poziomie jakości. Tylko do złożonych zadań - wieloetapowe wnioskowanie, analiza umów, przygotowanie decyzji - potrzebny jest model flagowy.

Logika routingu automatycznie decyduje, który model obsługuje zapytanie. Kryteria są konfigurowalne:

- **Złożoność:** Proste zapytania do modeli budżetowych, złożone do modeli flagowych.
- **Wrażliwość danych:** Zapytania z danymi osobowymi do modeli self-hosted, niekrytyczne zapytania do API chmurowych.
- **Wymagania opóźnienia:** Aplikacje czasu rzeczywistego do szybkich, małych modeli. Przetwarzanie wsadowe do wydajnych modeli bez presji czasu.
- **Limit kosztów:** Automatyczne ograniczanie, gdy budżet zespołu lub działu zostanie osiągnięty.

### Potencjał oszczędności

W praktyce zapytania enterprise rozkładają się typowo następująco:

- **60-70% zapytań standardowych:** Prosta klasyfikacja, FAQ, ekstrakcja danych. Modele budżetowe wystarczają.
- **20-30% średniej złożoności:** Podsumowania, analiza strukturyzowana, projekty. Modele o dobrym stosunku ceny do wydajności.
- **5-15% wysokiej złożoności:** Wieloetapowe wnioskowanie, analiza umów, dokumenty strategiczne. Modele flagowe.

Jeśli 65 procent zapytań zamiast modelu flagowego korzysta z modelu budżetowego, który kosztuje dwudziestą część, koszty tokenów spadają o 40 do 60 procent - przy niezmiennej jakości wyników dla całościowego użycia. Szczegóły dotyczące [doboru modeli i profili wydajności aktualnych modeli](/pl/magazyn/modele-ai-porownanie-2026/) są opisane w odpowiednim artykule.

### Wdrożenie

Model Switching wymaga trzech komponentów:

1. **Routing Engine:** Centralna logika analizująca przychodzące zapytania i kierująca je do odpowiedniego modelu. Może być zaimplementowana regułowo (rozpoznawanie słów kluczowych, rola użytkownika, klasyfikacja danych) lub modelem (mały model klasyfikacyjny ocenia złożoność).
2. **Model Registry:** Centralne repozytorium wszystkich dostępnych modeli z ich profilami wydajności, kosztami i dostępnością.
3. **Monitoring kosztów:** Dashboard, który transparentnie przedstawia zużycie tokenów na model, na zespół i na przypadek użycia. Bez transparentności nie ma optymalizacji.

Nakład wdrożeniowy Model Switching jest zarządzalny - typowo dwa do czterech tygodni. Oszczędności zaczynają się natychmiast.

## Planowanie budżetu: trzy rekomendacje

**Po pierwsze: planuj z TCO, nie z cenami tokenów.** Jeśli dostawca wylicza Ci koszty tokenów, brakuje co najmniej 65 procent budżetu. Wymagaj kalkulacji TCO obejmującej wszystkie cztery kategorie.

**Po drugie: zacznij od PoC, ale planuj skalowanie.** PoC za 70 000-140 000 PLN dowodzi przydatności. Ale architektura PoC musi być zbudowana tak, by można ją skalować bez przebudowy. Inaczej płacisz koszty integracji dwa razy.

**Po trzecie: wdroż Model Switching od początku.** Warstwa routingu kosztuje jednorazowo niewiele i oszczędza trwale dużo. Kto od początku routuje zróżnicowanie, unika lock-in na pojedynczy model i zachowuje kontrolę kosztów.

---

Gosign buduje infrastrukturę AI z przejrzystą strukturą kosztów, od analizy TCO do produktywnej eksploatacji. Jeśli chcesz wiedzieć, ile AI kosztuje w Twoim konkretnym setup, porozmawiaj z nami.

<a href="/pl/kontakt/" target="_blank" rel="noopener noreferrer">Umów spotkanie</a>. 30 minut, w których realistycznie skalkulujemy Twoje koszty.

--- LLM Self-Hosting dla enterprise - Azure, GCP, On-Premise ---
> Jak hostować modele językowe we własnej infrastrukturze? DeepSeek, Llama, Mistral self-hosted. Azure, GCP, On-Premise, Hybrid.

## Dlaczego self-hosting?

Dla wielu polskich firm pytanie nie brzmi, czy AI zostanie wdrożone, ale gdzie dane są przetwarzane. Przy korzystaniu z API chmurowych (OpenAI, Anthropic, Google) dane opuszczają własną infrastrukturę. Dla regulowanych branż - finansów, ochrony zdrowia, sektora publicznego - może to być kryterium dyskwalifikujące.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">W skrócie - LLM Self-Hosting dla Enterprise</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Self-hosting utrzymuje wszystkie dane w sieci firmowej - brak przetwarzania przez strony trzecie, pełna kontrola nad modelem, danymi i inferencją.</li>
<li>Modele open source (Llama, Mistral, DeepSeek, gpt-oss) mogą działać na Azure ML, GCP Vertex AI, własnych serwerach GPU lub w konfiguracji hybrydowej.</li>
<li>Wymiarowanie GPU to główny czynnik kosztowy: model 7B działa na jednym GPU, model 70B wymaga wielu GPU lub kwantyzacji.</li>
<li>Routing model-agnostic pozwala agentom używać modeli self-hosted dla wrażliwych danych i Cloud API dla zadań niekrytycznych.</li>
<li>Gartner (2024) prognozuje, że 45% wdrożeń AI w regulowanych branżach będzie działać na prywatnej infrastrukturze do 2027 roku - wobec 20% w 2023.</li>
</ul>
</div>

Self-hosting oznacza: model językowy działa w infrastrukturze klienta. Żadne dane nie opuszczają sieci firmowej. Żaden dostawca zewnętrzny nie przetwarza zapytań. Pełna kontrola nad modelem, danymi i przetwarzaniem.

W Polsce, gdzie RODO obowiązuje bezpośrednio jako rozporządzenie UE, a Urząd Ochrony Danych Osobowych (UODO) aktywnie monitoruje przetwarzanie danych osobowych, self-hosting może stanowić najlepszą opcję zapewnienia zgodności z przepisami dla wrażliwych procesów biznesowych.

## Jakie modele można hostować samodzielnie?

Modele open-source mogą być uruchamiane we własnej infrastrukturze:

**Workhorse wolumenowy - [Mistral](https://mistral.ai/) Small 3.2 (24B, Apache 2.0, EU-built):** Model europejski, działa na pojedynczej RTX 4090 z kwantyzacją 4-bit. Idealny do batch-inferencji na niekrytycznych workloadach. Mixtral 8x22B oraz Codestral Mamba 32B (specjalizacja kodowa) uzupełniają portfolio Mistral.

**Reasoning OSS - gpt-oss-120b (OpenAI, Apache 2.0):** 117B parametrów, architektura MoE, działa na pojedynczej H100 (80 GB). Pierwszy model open source OpenAI; gpt-oss-20b do zastosowań brzegowych.

**Frontier OSS - [DeepSeek](https://www.deepseek.com/) V4-Flash i V4-Pro (MIT):** DeepSeek V4-Flash (kwiecień 2026, 284B/13B aktywne MoE) działa na pojedynczej H100 z kwantyzacją. V4-Pro (1.6T/49B) wymaga klastra 8x H100 i dostarcza wnioskowanie klasy frontier. DeepSeek R1 (styczeń 2025) pozostaje gotowy produkcyjnie dla dojrzałych deploymentów - V4 nie wycofuje R1 z dnia na dzień.

**Długi kontekst - [Llama](https://llama.meta.com/) 4 Scout (Meta License):** Okno kontekstu 10M tokenów do analizy dokumentów obejmującej całe zbiory akt. Llama 4 Maverick obsługuje krótsze konteksty z wyższą przepustowością tokenów.

**Coding OSS - Qwen 3 Coder 110B (Apache 2.0, Alibaba) i DeepSeek Coder V4 (MIT):** Specjalizacja w generowaniu kodu i zrozumieniu repozytoriów. Codestral Mamba 32B (Mistral, EU-built) jako alternatywa europejska.

Modele własnościowe (Claude Opus 4.7, GPT-5.5, Gemini 3.1 Pro) nie są dostępne do self-hostingu, ale mogą być używane przez API z przetwarzaniem w UE.

W architekturze model-agnostycznej agent może korzystać z wielu modeli: self-hosted dla wrażliwych danych, API chmurowe dla niekrytycznych zadań. Routing jest oparty na regułach i konfigurowany w Decision Layer.

## Opcje deploymentu

**Azure:** LLM mogą być deployowane na Azure ML lub uruchamiane na dedykowanych VM z GPU (seria NC, seria ND). Integracja z Azure Entra ID do autentykacji i kontroli dostępu. Przetwarzanie w centrach danych UE (West Europe, North Europe). Dla polskich firm Azure oferuje również region Poland Central.

**GCP:** Deployment przez Vertex AI lub na dedykowanych VM z GPU (A2, G2). Integracja z Google Cloud IAM. Przetwarzanie w centrach danych UE (europe-west1, europe-west4).

**On-Premise:** Własne serwery z GPU NVIDIA (A100, H100, RTX 4000 Ada). Eksploatacja w certyfikowanych centrach danych. W Polsce dostępne są centra danych spełniające normy ISO 27001 i Tier III+. Maksymalna kontrola, brak zależności od chmury.

**Hybrid:** Połączenie self-hosted i chmury. Wrażliwe workloady lokalnie, niekrytyczne w chmurze. Jednolite governance w obu środowiskach.

<table class="w-full text-left text-sm">
<thead><tr class="border-b border-gosign-border">
<th class="py-2 pr-4 font-semibold">Kryterium</th>
<th class="py-2 pr-4 font-semibold">Self-Hosted</th>
<th class="py-2 pr-4 font-semibold">Cloud API</th>
</tr></thead>
<tbody>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Data Residency</td><td class="py-2 pr-4">Pełna kontrola, dane pozostają on-premise</td><td class="py-2 pr-4">Zależne od dostawcy, regiony UE dostępne</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Wybór modelu</td><td class="py-2 pr-4">Tylko open source (Llama, Mistral, DeepSeek)</td><td class="py-2 pr-4">Własnościowe + open source przez API</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Koszty przy skalowaniu</td><td class="py-2 pr-4">Niższe (stałe koszty GPU, brak opłat za tokeny)</td><td class="py-2 pr-4">Wyższe (ceny za tokeny rosną liniowo)</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Nakład operacyjny</td><td class="py-2 pr-4">Wysoki (zarządzanie GPU, aktualizacje, HA)</td><td class="py-2 pr-4">Niski (zarządzane przez dostawcę)</td></tr>
<tr class="border-b border-gosign-border/50"><td class="py-2 pr-4">Opóźnienie</td><td class="py-2 pr-4">Niskie (sieć lokalna)</td><td class="py-2 pr-4">Zmienne (zależne od sieci)</td></tr>
</tbody>
</table>

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Darmowy eBook: Infrastruktura AI</p>
<p class="text-body text-gosign-text mb-4">Build, Buy, Hybrid - infrastruktura zgodna z EU AI Act z B/B/H-Framework i 7-Layer Reference Architecture.</p>
<a href="/pl/ebook/ai-infrastructure-poradnik-governance/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Pobierz za darmo</a>
</div>

## Kwestie architektoniczne

**Wymiarowanie GPU:** Wielkość modelu determinuje zapotrzebowanie na GPU. Model 7B działa na pojedynczym GPU. Model 70B wymaga wielu GPU lub kwantyzacji. Prawidłowe wymiarowanie zależy od przypadku użycia.

**Optymalizacja inferencji:** Techniki takie jak kwantyzacja (4-bit, 8-bit), batching i optymalizacja KV-cache redukują zapotrzebowanie na zasoby przy akceptowalnej utracie jakości.

**Wysoka dostępność:** Dla systemów produkcyjnych: redundantne serwery GPU, load balancing, automatyczny failover. Brak pojedynczego punktu awarii.

**Aktualizacje modeli:** Nowe wersje modeli muszą być przetestowane przed wdrożeniem produkcyjnym. Środowisko staging do testowania modeli jest częścią infrastruktury.

**Punkt rentowności TCO - self-host vs Cloud API:** Próg leży w okolicy 50-100M tokenów/miesiąc w sposób ciągły. Poniżej tego progu Cloud API jest tańsze, powyżej dedykowana H100 amortyzuje się w 12-18 miesięcy. Zobacz [Samohostowana Open-Source AI 2026](/pl/magazyn/samohostowana-open-source-ai-2026/) dla pełnej macierzy modeli i kalkulacji kosztów.

Więcej na ten temat: [Infrastruktura AI](/pl/uslugi/infrastruktura/)

Szczegóły dotyczące kosztów self-hostingu w [porównaniu TCO](/pl/magazyn/koszty-ai-tco-porownanie/).

<a href="/pl/kontakt/" target="_blank" rel="noopener noreferrer">Umów spotkanie</a> - Pokażemy optymalną strategię hostingu dla Twoich wymagań.

--- Model-agnostyk: unikanie vendor lock-in LLM ---
> Logika biznesowa oddzielona od modelu językowego. Agenci, Decision Layer i zestawy reguł pozostają bez zmian przy zmianie modelu.

## Ryzyko: jeden model, jeden dostawca

Wiele firm buduje swoją strategię AI na jednym modelu. "Używamy ChatGPT" albo "Stawiamy na Claude". Prompty są optymalizowane pod ten model. Integracje budowane pod API tego dostawcy. Workflow dostosowane do specyfiki tego modelu.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">W skrócie - Architektura model-agnostyczna</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Budowanie na jednym dostawcy LLM tworzy niebezpieczną zależność: ceny się zmieniają, API zostają przebudowane, modele są wycofywane w krótkim terminie.</li>
<li>Architektura model-agnostyczna oddziela logikę biznesową od modelu językowego - agenci, Decision Layer i workflows pozostają nietknięte przy zmianach modelu.</li>
<li>Routing multi-model przypisuje tanie modele do prostych zadań, a flagowe do złożonego rozumowania - oszczędzając 40-60% kosztów tokenów.</li>
<li>Modele self-hosted przetwarzają wrażliwe dane, a Cloud API obsługują zapytania niekrytyczne - sterowane przez Decision Layer.</li>
<li>Forrester (2024) podaje, że organizacje z architekturą model-agnostyczną redukują koszty migracji LLM o nawet 70% w porównaniu z konfiguracjami jednovendorowymi.</li>
</ul>
</div>

Następnie wydarza się jedno z trzech: dostawca podnosi ceny. Dostawca zmienia API. Pojawia się nowy model, który jest wyraźnie lepszy lub tańszy. W każdym przypadku: cała implementacja musi być dostosowana.

Na rynku LLM to wydarza się szybko. W ciągu ostatnich 18 miesięcy ceny się społawiły, pojawili się nowi dostawcy, modele open-source prześcignęły modele zamknięte w benchmarkach. Kto jest związany z jednym dostawcą, nie może wykorzystać tych możliwości.

Dla polskich firm, które często działają w międzynarodowym środowisku z różnorodnymi wymaganiami regulacyjnymi, elastyczność w doborze modeli jest szczególnie istotna. Wymagania RODO, lokalne przepisy i rynkowe warunki cenowe mogą wymagać szybkiej zmiany dostawcy modelu.

## Model-agnostyk jako zasada architektoniczna

W architekturze referencyjnej Gosign Model Layer jest wymienną warstwa. Logika biznesowa - zestawy regul, logika decyzyjna, workflow - jest zaimplementowana w Decision Layer i Agent Layer, nie w modelu.

Gdy pojawia sie nowy model, może być zintegrowany bez zmian w warstwach powyżej. Agent nie wie, jakiego modelu uzywa. Wysyla zapytanie do Model Layer i otrzymuje odpowiedz. Ktory model dostarcza odpowiedz, jest dla agenta nieistotne.

## Routing multi-model

Agent może korzystać z wielu modeli jednocześnie. Routing jest oparty na regulach:

**Optymalizacja kosztów:** Proste zadania (klasyfikacja dokumentów, ekstrakcja danych) obsługuje tani model. Złożone zadania (wsparcie decyzji, interpretacja reguł) obsługuje wydajniejszy model.

**Rezydencja danych:** Wrażliwe dane trafiają do modeli self-hosted ([Llama](https://llama.meta.com/), [Mistral](https://mistral.ai/), [DeepSeek](https://www.deepseek.com/)). Niekrytyczne dane mogą być kierowane przez API chmurowe.

**Failover:** Jeśli dostawca modelu ulegnie awarii, system może automatycznie przełączać się na alternatywny model.

Reguły routingu są konfigurowane w Decision Layer i w pełni prośledalne.

## Obsługiwane modele

Architektura Gosign obsługuje aktualnie (stan na 2026):
- Claude Opus 4.7 / Sonnet 4.6 / Haiku 4.5 (Anthropic) - API chmurowe
- GPT-5.5 / GPT-5.5-mini (OpenAI) - API chmurowe
- Gemini 3.1 Pro / 3.1 Flash (Google) - API chmurowe
- Llama 4 Scout / Llama 4 Maverick (Meta) - Self-Hosted lub chmura
- Mistral Small 3.2 / Mistral Large (Mistral AI) - Self-Hosted lub chmura
- DeepSeek V4-Pro / V4-Flash / R1 (DeepSeek) - Self-Hosted lub chmura
- gpt-oss (OpenAI) - Self-Hosted lub chmura

Nowe modele mogą być integrowane, gdy tylko będą dostępne przez standardowe API. Który z tych modeli jest właściwy dla której mikro-decyzji, szczegółowo analizujemy w towarzyszącym artykule: [Który model kiedy? Decision Routing dla workflow agentowych](/pl/magazyn/modele-ai-porownanie-2026/).

| Aspekt | Konfiguracja jednovendorowa | Architektura model-agnostyczna |
|---|---|---|
| Zmiana modelu | Pełna przebudowa promptów, integracji, workflows | Zmiana reguł routingu, bez przebudowy |
| Kontrola kosztów | Jeden model cenowy | Tanie modele do prostych, flagowe do złożonych zadań |
| Suwerenność danych | Zależy od dostawcy | Self-hosted dla wrażliwych, chmura dla niekrytycznych |
| Failover | Brak alternatywy przy awarii dostawcy | Automatyczne przełączenie na alternatywny model |
| Koszt migracji | Wysoki (Forrester: do 70% wyższy) | Niski (tylko zmiana konfiguracji) |
| Przyszłościowość | Ryzyko wycofania modelu | Nowe modele integrowane bez zmian |

Więcej na ten temat: [Infrastruktura AI](/pl/uslugi/infrastruktura/)

## Model-agnostyk plus Decision Routing

Architektura model-agnostyczna to warunek wstępny, a Decision Routing dla każdej mikro-decyzji to praktyczne zastosowanie. Kto raz zbuduje warstwę routingu, ten zamienia wybór modelu w konfigurację, a aktualizację modelu w diff konfiguracji - zamiast w re-engineering. Który model pasuje do którego typu decyzji - klasyfikacja, tool-use, rozumowanie, long-context - opisuje porównanie referencyjne: [Który model kiedy? Decision Routing dla workflow agentowych](/pl/magazyn/modele-ai-porownanie-2026/).

<a href="/pl/kontakt/" target="_blank" rel="noopener noreferrer">Umów spotkanie</a> - Pokażemy architekturę model-agnostyczną w szczegółach.

--- Kiedy Mistral, kiedy Claude Opus? Routing decyzji dla agentów AI w polskim enterprise 2026 ---
> Rozłożone decyzje agentów: Mistral Small na on-prem w UE wykonuje 70 procent. Claude Opus zostaje dla 10 procent z prawdziwym ciężarem rozumowania. Akta decyzyjne gotowe zgodnie z EU AI Act art. 13.

Rynek modeli dojrzał szybciej niż większość architektur enterprise. Claude Opus 4.7, GPT-5.5 i Gemini 3.1 Pro zbiegają się jakościowo. Mistral La Plateforme działa z francuskiego centrum danych pod jurysdykcją UE. OpenAI w sierpniu 2025 wypuściło gpt-oss na licencji Apache 2.0. Meta i Mistral dostarczają modele open-weight, które działają na jednym GPU i osiągają jakość produkcyjną.

A mimo to większość polskich projektów AI nadal wybiera jeden model i kieruje przez niego każde obciążenie. Ta decyzja po cichu określa trzy kolejne rzeczy: pozycję suwerenności chmury, koszt audytu zgodnie z EU AI Act i przestrzeń na optymalizację kosztów. Wybór modelu nie jest decyzją modelową. To decyzja architektoniczna.

<div class="not-prose my-12 border border-gosign-border bg-gosign-light rounded-card p-6 lg:p-8">
<p class="text-h3 font-bold text-gosign-dark mb-3">W skrócie - Stack agentów AI dla polskiego enterprise 2026</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Około 70 procent decyzji agenta w dobrze rozłożonym procesie enterprise to stosowanie reguł albo ekstrakcja strukturalna. W typowym setupie hostingowym w UE Mistral Small 3.2 na pojedynczym GPU obsługuje je za mniej więcej 1/30 ceny listowej Claude Opus.</li>
<li>Mistral ma dwie odrębne powierzchnie wdrożeniowe: La Plateforme (API hostowane w UE, infrastruktura francuska, własne centrum danych Bruyères-le-Châtel od II kw. 2026) i Mistral Small 3.2 (Apache 2.0, w pełni self-hosted, 24 mld parametrów).</li>
<li>Pozostałe 8-10 procent decyzji - złożone rozumowanie, analiza wielojurysdykcyjna, eskalacja przypadków granicznych - uzasadnia użycie Claude Opus 4.7 lub GPT-5.5. To tam token spend jest zarobiony, a nie zmarnowany.</li>
<li>Ekspozycja na US CLOUD Act obejmuje również wdrożenia US-providerów w regionach UE. Schrems II + CLOUD Act sprawiają, że self-hosting jest najczystszą opcją pod kątem ekspozycji na obcego providera. Alternatywnie SCC (Klauzule Standardowe Komisji 2021/914) + Tabela Suplementarna (Transfer Impact Assessment zgodnie z Zaleceniami EDPB 01/2020) pozostają prawnie ważną ścieżką, wymagają jednak rygorystycznej oceny równoważności ochrony i dodatkowych środków technicznych. Self-hosted Mistral Small, gpt-oss-120b albo DeepSeek V4-Flash (preview kwiecień 2026, MIT, 284B/13B aktywnych MoE) to architektury z zerową powierzchnią CLOUD Act.</li>
<li>Zgodnie z EU AI Act art. 13 systemy wysokiego ryzyka muszą działać przejrzyście. Warstwa routingu decyzji produkuje artefakt audytowy: rekord per decyzja z wejściem, wersją reguły, modelem, pewnością i osobą zatwierdzającą tam, gdzie eskalowano.</li>
</ul>
</div>

## Oceniasz Mistral - to, co faktycznie oceniasz, to twoja strategia chmurowa w UE

Typowy ślad poszukiwań w 2026 wygląda tak. Compliance prosi o europejską alternatywę dla OpenAI. Zakupy zbierają oferty dostawców. Architektura zaczyna oceniać Mistral. W ciągu tygodnia rozmowa przesuwa się z "który model" na "jaka jest nasza pozycja wobec ekspozycji na US CLOUD Act" i "jak operacjonalizujemy art. 13 EU AI Act dla systemów wysokiego ryzyka zgodnie z wymogami przejrzystości".

CLOUD Act podąża za kontrolą providera, nie za lokalizacją danych. US-provider z centrami danych w UE - Azure OpenAI EU, AWS Bedrock Frankfurt, GCP Vertex europe-west - nadal może zostać zmuszony do wydania danych na podstawie amerykańskiego nakazu. Komisja Europejska ma w II kwartale 2026 wydać [Tech Sovereignty Package](https://www.kiteworks.com/cybersecurity-risk-management/eu-tech-sovereignty-package-cloud-act/), który ograniczy stosowanie US-providerów w sektorze publicznym dla wrażliwych obciążeń w ochronie zdrowia, finansach i sądownictwie. Zakupy w sektorze prywatnym czytają te sygnały.

Mistral jest interesujący nie dlatego, że pokonuje Claude w rankingu. Jest interesujący, ponieważ zajmuje pozycję, której żaden US-provider nie może zająć: frontowy provider europejski z [dedykowaną infrastrukturą w UE](https://help.mistral.ai/en/articles/347629-where-do-you-store-my-data-or-my-organization-s-data) i w pełni open-weight linią modeli pod Apache 2.0. Od II kwartału 2026 firma prowadzi własne centrum danych pod Paryżem z [13 800 procesorami NVIDIA GB300](https://ioplus.nl/en/posts/why-mistrals-830m-raise-is-a-win-for-european-autonomy) i mocą 44 megawatów. Czyni to Mistral jedynym frontowym dostawcą, który może zaoferować pełną rezydencję w UE na infrastrukturze pod jurysdykcją UE.

Ale to źle stawia pytanie. Prawdziwe pytanie nie brzmi "Mistral czy OpenAI". Brzmi "które decyzje idą gdzie i jak to udowodnisz audytorowi".

## Mistral to dwa światy: La Plateforme we Francji albo Mistral Small na Apache 2.0

Zamieszanie zaczyna się od traktowania "Mistral" jako jednego produktu. To dwie rodziny produktów z różnymi powierzchniami wdrożenia i różnymi implikacjami compliance.

| Produkt Mistral | Wdrożenie | Licencja / koszt | Suwerenny UE |
|---|---|---|---|
| Mistral Medium 3.1 | La Plateforme (API hostowane we Francji) lub Azure AI Foundry | Token-based, własnościowy | Tak przez La Plateforme |
| Mistral Small 3.2 | Self-hosted on-prem | Apache 2.0, tylko koszt GPU | Tak przy sprzęcie w UE |
| Mixtral 8x22B | Self-hosted on-prem | Apache 2.0, tylko koszt GPU | Tak przy sprzęcie w UE |
| Codestral | La Plateforme | Token-based, własnościowy | Tak przez La Plateforme |

*"Suwerenny UE" oznacza: poza zasięgiem US CLOUD Act. Zarówno La Plateforme (jurysdykcja francuska) jak i self-hosted na sprzęcie w UE spełniają ten warunek. Azure AI Foundry nie, nawet z rezydencją danych w UE, ponieważ Microsoft pozostaje podmiotem podlegającym nakazom CLOUD Act.*

Mistral Medium 3.1 to własnościowy flagowiec klasy frontowej. Działa na własnej francuskiej infrastrukturze Mistral, dostępny przez API. Rozliczany tokenowo. Domyślnie suwerenny w UE. Od II kwartału 2026 dedykowane centrum Bruyères-le-Châtel obsługuje inferencję dla klientów wymagających gwarantowanej rezydencji we Francji.

[Mistral Small 3.2](https://mistral.ai/news/mistral-small-3-1) to koń roboczy open-weight. 24 miliardy parametrów. Kontekst 128K tokenów. Rozumienie wizualne wbudowane. Wydany w czerwcu 2025 jako aktualizacja 3.1, na licencji Apache 2.0. Działa na pojedynczym NVIDIA RTX 4090 albo Macu z 32 GB RAM. Przepustowość około 150 tokenów na sekundę na sprzęcie konsumenckim.

Te dwa nie są redundantne. La Plateforme ma sens, gdy chcesz suwerenności UE bez prowadzenia infrastruktury GPU. Mistral Small 3.2 ma sens, gdy decyzja jest tak wysokowolumenowa, że rozliczenie tokenowe staje się sterownikiem kosztu, albo gdy dane są tak wrażliwe, że nawet ruch API w UE to za duża powierzchnia.

Pytanie architektoniczne brzmi: która powierzchnia wdrożeniowa dla której decyzji, nie który dostawca dla którego rankingu.

<figure class="not-prose my-12">
<svg viewBox="0 0 800 600" xmlns="http://www.w3.org/2000/svg" role="img" aria-labelledby="radar-title-pl radar-desc-pl" class="w-full h-auto max-w-3xl mx-auto">
<title id="radar-title-pl">Porównanie profili modeli na sześciu wymiarach enterprise (maj 2026)</title>
<desc id="radar-desc-pl">Spider-chart porównanie czterech reprezentatywnych modeli na sześciu wymiarach enterprise, każdy w skali 0 do 10. Claude Opus 4.7 (chmura, Anthropic): Rozumowanie 10, Kodowanie 10, Multimodalność 7, Efektywność kosztowa 3, Latencja 6, Suwerenność UE 4. GPT-5.5 (chmura, OpenAI/Azure): Rozumowanie 10, Kodowanie 10, Multimodalność 9, Efektywność 3, Latencja 7, Suwerenność 4. Mistral Small 3.2 (self-host, Apache 2.0): Rozumowanie 6, Kodowanie 7, Multimodalność 8, Efektywność 10, Latencja 9, Suwerenność 10. DeepSeek V4-Pro (self-host, MIT): Rozumowanie 9, Kodowanie 8, Multimodalność 5, Efektywność 7, Latencja 7, Suwerenność 9. Flagowce chmurowe dominują w Rozumowaniu, Kodowaniu i Multimodalności, ale tracą przy Efektywności kosztowej i Suwerenności. Modele self-host odwracają ten kształt. Warstwa decision-routingu łączy oba kształty per mikro-decyzja zamiast wybierać jednego mistrza.</desc>
<defs>
<style>
.axis-pl { stroke: #d4d0cb; stroke-width: 1; fill: none; }
.grid-pl { stroke: #d4d0cb; stroke-width: 0.5; fill: none; opacity: 0.5; }
.label-pl { font-family: -apple-system, system-ui, sans-serif; font-size: 12px; fill: #1a2e4d; text-anchor: middle; font-weight: 600; }
.scale-pl { font-family: -apple-system, system-ui, sans-serif; font-size: 9px; fill: #94a3b8; text-anchor: middle; }
.legend-pl { font-family: -apple-system, system-ui, sans-serif; font-size: 12px; fill: #1a2e4d; font-weight: 500; }
.legend-sub-pl { font-family: -apple-system, system-ui, sans-serif; font-size: 10px; fill: #64748b; }
</style>
</defs>
<circle cx="400" cy="300" r="50" class="grid-pl"/><circle cx="400" cy="300" r="100" class="grid-pl"/><circle cx="400" cy="300" r="150" class="grid-pl"/><circle cx="400" cy="300" r="200" class="grid-pl"/><circle cx="400" cy="300" r="250" class="grid-pl"/>
<text x="408" y="100" class="scale-pl">10</text><text x="408" y="150" class="scale-pl">8</text><text x="408" y="200" class="scale-pl">6</text><text x="408" y="250" class="scale-pl">4</text><text x="408" y="300" class="scale-pl">2</text>
<line x1="400" y1="300" x2="400" y2="50" class="axis-pl"/><line x1="400" y1="300" x2="616.5" y2="175" class="axis-pl"/><line x1="400" y1="300" x2="616.5" y2="425" class="axis-pl"/><line x1="400" y1="300" x2="400" y2="550" class="axis-pl"/><line x1="400" y1="300" x2="183.5" y2="425" class="axis-pl"/><line x1="400" y1="300" x2="183.5" y2="175" class="axis-pl"/>
<text x="400" y="38" class="label-pl">Rozumowanie</text>
<text x="630" y="165" class="label-pl">Kodowanie</text>
<text x="630" y="438" class="label-pl">Multimodalność</text>
<text x="400" y="572" class="label-pl">Efektywność kosztowa</text>
<text x="170" y="438" class="label-pl">Latencja inferencji</text>
<text x="170" y="165" class="label-pl">Suwerenność UE</text>
<polygon points="400,50 616.5,175 562,387 400,375 335,338 313,225" fill="#fcd34d" fill-opacity="0.25" stroke="#b8941f" stroke-width="2"/>
<polygon points="400,50 616.5,175 595,413 400,375 313,363 313,225" fill="#3a6090" fill-opacity="0.20" stroke="#3a6090" stroke-width="2" stroke-dasharray="6 3"/>
<polygon points="400,150 551.5,213 579,400 400,550 205,425 183.5,175" fill="#1a2e4d" fill-opacity="0.20" stroke="#1a2e4d" stroke-width="2"/>
<polygon points="400,75 595,188 508,363 400,475 248,400 205,200" fill="#9a5a5a" fill-opacity="0.18" stroke="#9a5a5a" stroke-width="2" stroke-dasharray="3 3"/>
<g transform="translate(40, 590)"><rect x="0" y="-15" width="15" height="3" fill="#b8941f"/><text x="22" y="-9" class="legend-pl">Claude Opus 4.7</text><text x="22" y="3" class="legend-sub-pl">chmura, Anthropic</text></g>
<g transform="translate(195, 590)"><rect x="0" y="-15" width="15" height="3" fill="#3a6090"/><text x="22" y="-9" class="legend-pl">GPT-5.5</text><text x="22" y="3" class="legend-sub-pl">chmura, OpenAI/Azure</text></g>
<g transform="translate(370, 590)"><rect x="0" y="-15" width="15" height="3" fill="#1a2e4d"/><text x="22" y="-9" class="legend-pl">Mistral Small 3.2</text><text x="22" y="3" class="legend-sub-pl">self-host, Apache 2.0</text></g>
<g transform="translate(560, 590)"><rect x="0" y="-15" width="15" height="3" fill="#9a5a5a"/><text x="22" y="-9" class="legend-pl">DeepSeek V4-Pro</text><text x="22" y="3" class="legend-sub-pl">self-host, MIT</text></g>
</svg>
<figcaption class="text-sm text-gosign-text-light text-center mt-4 max-w-2xl mx-auto">
<strong>Profil modelu na sześciu wymiarach enterprise</strong> - widok porównawczy w stylu c't, w skali 0 do 10. Flagowce chmurowe (Claude Opus 4.7, GPT-5.5) dominują w Rozumowaniu, Kodowaniu, Multimodalności, ale tracą przy Efektywności kosztowej i Suwerenności UE. Modele self-host (Mistral Small 3.2, DeepSeek V4-Pro) odwracają ten kształt. Nie istnieje "najlepszy" model - warstwa routingu wybiera właściwy kształt per mikro-decyzja.
</figcaption>
</figure>

## Dlaczego Mistral Small jako domyślny, a nie gpt-oss czy DeepSeek

Słuszne pytanie, kiedy decydujesz się na self-hosting: dlaczego Mistral Small 3.2 wygrywa rolę konia roboczego nad [gpt-oss-120b](https://openai.com/index/introducing-gpt-oss/) (Apache 2.0, 117B parametrów MoE, 5 sierpnia 2025) lub [DeepSeek V4](https://api-docs.deepseek.com/news/news260424) (MIT, preview z 24 kwietnia 2026; V4-Flash 284B/13B aktywnych, V4-Pro 1.6T/49B aktywnych, kontekst 1M)? Wszystkie trzy są legalnie self-hostowalne w jakiejś konfiguracji. Różnicują się progiem sprzętowym, pokryciem językowym i modalnością.

| Model open-source | Sprzęt CAPEX / OPEX hostowany | Mocna strona | Słabość | Idealne zastosowanie |
|---|---|---|---|---|
| Mistral Small 3.2 (24B, Apache 2.0) | 1x RTX 4090 ~1 500 EUR (kwantyzacja) lub 1x H100 80GB ~30k EUR / OPEX ~1 500-2 500 EUR/miesiąc hostowany | Volume, wielojęzyczność (PL/DE/EN/ES/BR), zdolność wizualna, ~150 tok/s | Nie najwyższa półka rozumowania | **Domyślny koń roboczy dla 70 procent wolumenu** |
| gpt-oss-120b (117B MoE, Apache 2.0) | 1x H100/A100 80GB ~30k EUR / OPEX ~1 200-2 500 EUR/miesiąc hostowany | Rozumowanie na poziomie o4-mini, MoE-efektywny | Brak wizji, sprzęt klasy data center | **Alternatywa dla Claude Opus przy ciężkim rozumowaniu, gdy nawet to musi pozostać on-prem** |
| DeepSeek V4-Flash (MIT, preview kwiecień 2026) | 1-4x H100 ~30-120k EUR / OPEX ~1 500-5 000 EUR/miesiąc hostowany | Rozumowanie klasy frontowej przy umiarkowanym sprzęcie, kontekst 1M, natywny multimodal | Status preview - benchmarki należy potwierdzić przed produkcją | **Specjalista matematyka/logika + analiza portfeli z kontekstem 1M** |
| DeepSeek V4-Pro (MIT, preview kwiecień 2026) | 8x H100 ~240 000 EUR CAPEX / OPEX ~10-12k EUR/miesiąc hostowany | Zbliża się do wydajności GPT-5.5/Gemini 3.1 Pro, zoptymalizowany pod agentów | Próg sprzętowy realny dla dużych korporacji; MSP via API/hosted | **Frontowe rozumowanie pod otwartą licencją - korporacje on-prem, MSP via API** |
| DeepSeek R1 (MIT, dojrzały) | 4-8x H100 ~120-240k EUR / OPEX ~5-10k EUR/miesiąc hostowany | Specjalista matematyka/logika, szerokie wsparcie frameworków | Zastąpiony przez V4-Flash w nowych wdrożeniach | **Mature mathematics/logic workloads, sustained reasoning at scale** |
| Llama 4 Scout (Meta Llama License) | 1x H100 ~30k EUR / OPEX ~1 500 EUR/miesiąc hostowany | Kontekst 10M tokenów | Ograniczenie licencyjne przy >700M MAU | **Ultra-długi kontekst dla całych portfeli kontraktów** |

Trzy konkretne powody, dla których Mistral Small zdobywa rolę domyślną:

**Próg sprzętowy.** Mistral Small działa na sprzęcie konsumenckim. gpt-oss-120b wymaga GPU klasy data center. Dla pipeline enterprise z pięcioma do dziesięciu worker node'ami różnica per-node sprzętowa jest znacząca. Gdy 70 procent decyzji to klasyfikacja albo ekstrakcja, moc rozumowania klasy gpt-oss jest przerostem do wolumenu.

**Wielojęzyczny korpus treningowy.** Mistral od początku był trenowany na danych francuskich, niemieckich, hiszpańskich i włoskich. gpt-oss jest US-centric z dominacją angielskiego w treningu. Dla pipeline polskiego enterprise przetwarzającego dokumenty po polsku, niemiecku, hiszpańsku czy portugalsku Mistral Small jest lepszym koniem roboczym od pierwszego dnia.

**Wizja w zestawie.** Mistral Small 3.2 ma natywną zdolność wizualną. gpt-oss nie. Dla onboardingu HR (skany dowodów, certyfikaty, formularze podatkowe) albo AP (faktury PDF z layoutem) to twardy nokaut.

gpt-oss-120b albo DeepSeek V4-Flash wchodzą do stacku jako on-prem opcje ciężkiego rozumowania, gdy Claude Opus 4.7 API nie może być użyty z powodów compliance. DeepSeek V4-Pro zbliża się do wydajności zamkniętych modeli frontowych pod otwartą licencją MIT - waga modelu jest swobodnie dostępna na Hugging Face. Pytanie nie brzmi "czy licencja pozwala", tylko "czy rozmiar przedsiębiorstwa uzasadnia 240 000 EUR CAPEX (8x H100) plus 10-12 000 EUR OPEX miesięcznie". Dla korporacji WIG20, gospodarki regulowanej i większych Mittelstand (>2000 prac.) ten próg mieści się w standardowym budżecie infrastruktury IT - V4-Pro on-prem jest realny i atrakcyjny pod kątem suwerenności. Dla MSP poniżej 500 pracowników racjonalna ścieżka prowadzi przez API albo hostowane warianty (Together.ai, Fireworks, DeepSeek API) - ta sama jakość rozumowania bez CAPEX. Żaden z tych modeli nie zastępuje Mistral Small jako konia roboczego volumenowego - uzupełniają go dla trudniejszych decyzji. Szczegółowe porównanie self-hosted opisuje [Open Source AI na własnym hostingu 2026: Mistral, gpt-oss, DeepSeek V4, Llama 4 w stacku enterprise](/pl/magazyn/samohostowana-open-source-ai-2026/) (osobny artykuł).

## Który model do czego? Rozkład złożoności decyzji agenta

Typowy agent enterprise rozkłada się na 14 do 50 mikro-decyzji. Złożoność nie jest rozłożona równo. W dobrze oprzyrządowanym pipeline HR albo finansowym wygląda to tak:

| Typ decyzji | Udział decyzji | Złożoność | Najlepszy model | Realny koszt na 1M tokenów |
|---|---|---|---|---|
| Stosowanie reguł (klasa podatkowa z danych podstawowych, klasyfikacja typu umowy, sprawdzenie progów) | 50% | Niska | Często bez LLM; w innym razie Mistral Small 3.2, Llama 4 Scout, gpt-oss-20b | ~0 do ~0,50 USD |
| Ekstrakcja strukturalna (pola z PDF, normalizacja tabel, pozycje z OCR) | 25% | Średnia | Mistral Small 3.2, Mistral Medium 3.1, gpt-oss-120b | ~0,50 do ~2 USD |
| Klasyfikacja kontekstowa (analiza klauzul pod kątem prawa pracy, wykrywanie anomalii w raportach kosztów, flagowanie ryzyka dostawcy) | 15% | Średnio-wysoka | Mistral Medium 3.1, Claude Haiku 4.5, GPT-5 mini | ~1 do ~5 USD |
| Złożone rozumowanie (analiza antydyskryminacyjna międzykrajowa, wieloetapowa synteza argumentu, redakcja eskalacji) | 8% | Wysoka | Claude Opus 4.7, GPT-5.5 | ~15 do ~25 USD |
| Multimodal (korelacja obraz plus tekst, segmenty wideo, przegląd rysunku technicznego) | 2% | Wysoka | Gemini 3.1 Pro | ~5 do ~10 USD |

Implikacja jest prosta. Jeśli kierujesz każdą decyzję przez Claude Opus, płacisz stawki flagowe za 75 procent pracy, która nie potrzebuje flagowego rozumowania. Jeśli kierujesz wszystko przez Mistral Small, oszczędzasz koszt tokenów, ale poniesiesz porażkę na tych 8 procentach, gdzie rozumowanie klasy Opus naprawdę ma znaczenie - i zapłacisz za to ustaleniami audytora, nie tokenami.

[Stanford HAI 2025 AI Index](https://hai.stanford.edu/ai-index/2025-ai-index-report) odnotowuje, że 65,7 procent nowo wydanych modeli bazowych w 2023 było open-source, w porównaniu z 33,3 procent w 2021. Adopcja AI w przedsiębiorstwach przekroczyła 78 procent. Rynek już nie wybiera między własnościowym a otwartym. Wybiera, jak je komponować.

## Mistral Small jako koń roboczy: agent onboardingu HR z 14 mikro-decyzjami

Konkretny przykład. Agent onboardingu HR przyjmuje podpisaną umowę nowego pracownika plus dokumenty wspierające (skan dowodu osobistego, oświadczenie PIT-2, dane do przelewu, certyfikaty kwalifikacji). Jego zadanie: utworzyć kartotekę pracownika, przeprowadzić sprawdzenia compliance pre-employment, zaplanować onboarding, zarejestrować ZUS ZUA. Czternaście mikro-decyzji łącznie, od walidacji regex po analizę antydyskryminacyjną zgodnie z Kodeksem Pracy art. 18(3a).

Naiwna implementacja wysyła każdy krok do Claude Opus 4.7. Implementacja rozłożona kieruje per krok. Decision Layer trzyma reguły routingu: każdy krok jest klasyfikowany jako REGUŁY, SI AUTONOMICZNE albo CZŁOWIEK przed wykonaniem.

**REGUŁY:** Decyzja jest deterministyczna. Format numeru PESEL podlega regule sumy kontrolnej, IBAN podlega ISO 13616. Bez interpretacji, bez modelu. Tu agent jest wykonawcą, nie rozumującym.

**SI AUTONOMICZNE:** Decyzja jest klasyfikacją albo ekstrakcją z wystarczającą pewnością. Wykrycie typu dokumentu, klasyfikacja typu umowy, ekstrakcja pól strukturalnych. Mały model z czystym schematem pokonuje flagowca z mglistym promptem.

**CZŁOWIEK:** Decyzja dotyka swobody uznania, ryzyka dyskryminacji, zakresu konsultacji rady pracowników albo przekroczenia progów. Analiza zgodnie z Kodeksem Pracy art. 18(3a) ff., zakres informowania rady pracowników, anomalia wynagrodzenia powyżej uzgodnionego limitu. Model przygotowuje sprawę; człowiek podpisuje decyzję.

Poniższe osiem kroków to reprezentatywny wzorzec routingu z typowego pipeline 14-krokowego. Pełna tabela reguł routingu dla 14 kroków żyje w konfiguracji Decision Layer klienta.

| Krok | Decyzja | Warstwa | Cel routingu |
|---|---|---|---|
| 1 | Wykryj typy dokumentów w upload | SI AUTONOMICZNE | Mistral Small 3.2 on-prem |
| 2 | Wyciągnij dane osobowe (imię, adres, data urodzenia, NIP/PESEL) | SI AUTONOMICZNE | Mistral Small 3.2 on-prem |
| 3 | Waliduj format PESEL i IBAN (PL ISO 13616) | REGUŁY | Silnik reguł, bez LLM |
| 4 | Klasyfikuj typ umowy (czas określony, nieokreślony, próbny - zgodnie z Kodeksem Pracy art. 25 ff.) | SI AUTONOMICZNE | Mistral Small 3.2 |
| 5 | Sprawdź klauzule umowy względem ramy rady pracowników v2024-3 | SI AUTONOMICZNE | Mistral Medium 3.1 (La Plateforme) |
| 6 | Oflaguj klauzule potencjalnie dyskryminacyjne (zgodnie z Kodeksem Pracy art. 18(3a)-(3e)) | CZŁOWIEK (przygotowane przez AI) | Claude Opus 4.7 przygotowuje analizę, Specjalista HR podpisuje |
| 7 | Wykryj anomalie płacowe względem roli, lokalizacji, stażu | SI AUTONOMICZNE | Mistral Medium 3.1 |
| 8 | Zdecyduj, czy informowanie rady pracowników jest wymagane (zgodnie z Ustawą o radach pracowników, art. 13-15) | CZŁOWIEK (przygotowane przez AI) | Mistral Medium 3.1 wstępnie klasyfikuje, łącznik rady pracowników podpisuje |

Z pełnych 14 kroków sześć to REGUŁY (bez LLM: sprawdzenie IBAN, kompletność dokumentów, zgłoszenie ZUS ZUA, NFZ-OW, deterministyczne pliki rejestracyjne). Sześć to SI AUTONOMICZNE (Mistral Small albo Medium). Dwa to CZŁOWIEK z przygotowaniem AI (Claude Opus dla pytania o dyskryminację, Mistral Medium dla wstępnej klasyfikacji informowania rady pracowników).

W typowym setupie hostingowym w UE ten rozkład przekłada się na około 1 do 3 USD na onboarding na inferencji. Architektura wyłącznie flagowa (każdy krok przez Claude Opus) ląduje bliżej 25 do 40 USD na onboarding - i przetwarza krok 1 i 2 na infrastrukturze USA pod ekspozycją CLOUD Act. Ten sam efekt biznesowy. Inny audit trail. Inna krzywa kosztu. Inna pozycja suwerenności.

## Co widzi audytor: akta decyzyjne zgodnie z EU AI Act art. 13

[EU AI Act art. 13](https://artificialintelligenceact.eu/article/13/) wymaga, by systemy AI wysokiego ryzyka działały na tyle przejrzyście, by użytkownicy mogli interpretować wyniki i używać ich właściwie. System musi przyjść z instrukcjami określającymi metryki dokładności, odporność, przetestowane poziomy cyberbezpieczeństwa, środki nadzoru człowieka zgodnie z art. 14 oraz wymagane zasoby sprzętowe.

Pytanie audytora w dniu kontroli nie brzmi "którego modelu użyłeś", tylko "pokaż mi rekord decyzji dla sprawy kadrowej 2026-01-1873, krok 8".

Akt decyzyjny produkowany przez warstwę routingu zawiera per mikro-decyzję:

- **Snapshot wejścia** (istotne pola z kontekstu poprzedzającego, z zastosowaną obsługą PII zgodnie z RODO art. 28)
- **Wersja reguły** (która wersja ramy rady pracowników została użyta; v2024-3)
- **Typ decyzji** (stosowanie reguły, klasyfikacja AI, rozumowanie AI, akceptacja człowieka)
- **Użyty model** (jeśli AI: Mistral-Small-3.2-Instruct-2503, wdrożony na klastrze A04, region eu-de-fra)
- **Ocena pewności** (jeśli AI: 0,94)
- **Łańcuch rozumowania** (jeśli dotyczy: pośrednie rozumowanie modelu, dosłownie utrwalone)
- **Wynik** (etykieta klasyfikacji, wyekstrahowana wartość albo flaga eskalacji)
- **Osoba zatwierdzająca** (jeśli eskalowano: imię, rola, znacznik czasu)
- **Przycisk zaskarżenia** dla decyzji AI (osoba, której to dotyczy, może zakwestionować automatyczną decyzję, co uruchamia ponowną decyzję pod nadzorem człowieka - mechanizm wymagany przez RODO art. 22)

Pipeline, który produkuje takie rekordy, zamienia pytanie modelowe w pytanie routingowe. Audytor nie pyta "czy Mistral jest tak dobry jak Claude". Audytor pyta "czy decyzja jest udokumentowana od początku do końca i czy da się ją odtworzyć". Pytanie zarządu idzie o krok dalej: kto podpisuje decyzję, gdy zgodnie z Kodeksem Pracy art. 18(3a) wymóg został naruszony przez cel routingu, który powinien był eskalować do człowieka? Warstwa routingu czyni ten podpis śledzonym.

## Sektor regulowany: KNF, DORA, KSeF, NIS2, URE, UODO

Dla branż regulowanych dyskusja "który model" jest pod-pytaniem do "który regulator nadzoruje twoje wdrożenie AI i jakie artefakty kontroluje". Cztery sektory dominują w polskim enterprise AI 2026: usługi finansowe (KNF + DORA + EBA), administracja podatkowa (KSeF + EU AI Act Annex III), infrastruktura krytyczna (NIS2 + KSC + URE) oraz ochrona danych horyzontalna (UODO + RODO DPIA).

**Dla instytucji finansowych zgodnie z KNF.** KNF Rekomendacja D (zarządzanie obszarem IT) wraz z DORA art. 28-30 (zarządzanie ryzykiem zewnętrznym ICT) od 17 stycznia 2025 wymaga rejestru dostawców ICT. EBA Wytyczne o outsourcingu (EBA/GL/2019/02) uzupełniają te wymogi. KSeF (Krajowy System e-Faktur, obowiązkowy od kwietnia 2026) traktuje klasyfikację faktur przez AI jako system wysokiego ryzyka zgodnie z EU AI Act art. 6 Annex III ust. 8 (administracja sprawiedliwości i procesy demokratyczne / podatki). UKNF (Urząd KNF) bezpośrednio nadzoruje banki, ubezpieczycieli, fundusze inwestycyjne i SKOK-i w zakresie tych wymogów.

**Dla podmiotów krytycznych zgodnie z NIS2 + Krajowym Systemem Cyberbezpieczeństwa.** KSC (transpozycja NIS2 do prawa polskiego) operacjonalizuje obowiązki Critical Entity. URE (Urząd Regulacji Energetyki) nadzoruje użycie AI w sektorze energii. Resolucja URE wymaga 24h/72h raportowania incydentów cybernetycznych. Predictive maintenance, SCADA-AI i grid anomaly detection są workloadami wysokiego ryzyka. Chmura Krajowa (OChK, joint venture PKO + PFR + Google Cloud Polska) oferuje sovereign cloud dla podmiotów publicznych i krytycznej infrastruktury.

**Dla IOD i Inspektorów Ochrony Danych.** Art. 35 RODO Ocena Skutków dla Ochrony Danych (DPIA) jest obowiązkowa dla systemów AI klasyfikowanych jako wysokiego ryzyka. Art. 11 RODO (dane wrażliwe) dotyczy danych zdrowotnych w ATS admisyjnym. Art. 6 ust. 1 lit. f (legitymny interes) z testem proporcjonalności jako podstawa prawna dla AI bez zgody. Urząd Ochrony Danych Osobowych (UODO) jest bezpośrednim regulatorem RODO w PL. Inspekcja UODO sprawdza: politykę prywatności, mapowane podstawy prawne, RIPD (Rejestr Czynności Przetwarzania, art. 30 RODO), wyznaczonego IOD, plan reakcji na incydent (art. 33 ust. 1 + art. 34 RODO).

**Dla branży farmaceutycznej.** GMP Annex 11 + Eudralex Vol. 4 dla walidacji systemów IT z AI. URPL (Urząd Rejestracji Produktów Leczniczych) guidance na użycie AI w pharmacovigilance. Prawo Farmaceutyczne art. 38a wymaga pseudonimizacji danych pacjentów w Clinical Trial AI Pipelines.

Decyzja routingu modelu wpada w te ramy. Mistral Small 3.2 on-prem na sprzęcie w UE eliminuje pytanie ekspozycji CLOUD Act dla większości wymienionych regulatorów. Claude Opus 4.7 albo GPT-5.5 dla 8-10 procent ciężkiego rozumowania wymaga oddzielnej oceny DPIA i klasyfikacji w rejestrze dostawców ICT zgodnie z DORA art. 28.

## Pytanie architektoniczne: Decision Layer albo vendor lock-in

Decision Layer agnostyczny modelowo to nie feature. To warunek wstępny niemal wszystkiego, co opisaliśmy. Bez niego wzorce routingu powyżej pozostają abstrakcją.

| Bez Decision Layer | Z Decision Layer |
|---|---|
| Wybór modelu jest lepki. Zmiana dostawcy oznacza ponowną implementację całego agenta. | Przełączenie dostawcy to jedna zmiana konfiguracji. Modele są wymienne per krok decyzji. |
| Optymalizacja kosztu dzieje się ex post, w renegocjacji z jednym dostawcą. | Optymalizacja kosztu jest wbudowana: decyzje o niskiej złożoności automatycznie trafiają do najtańszego sensownego modelu. |
| Suwerenność jest binarna: albo akceptujesz ekspozycję US CLOUD Act, albo self-hostujesz wszystko. | Suwerenność jest per decyzja: wrażliwe kroki działają on-prem w UE, niewrażliwe mogą używać API w chmurze. |
| Audit trail istnieje w rozproszonych logach i jest rekonstruowany na żądanie. | Audit trail jest logiem routingu. Zgodność z EU AI Act art. 13 to zapytanie, nie projekt. |
| Dodanie nowego modelu to nowa integracja. | Dodanie nowego modelu to dodanie go do routera. Reguły routingu już istnieją. |

*Ta tabela pokazuje różnice architektoniczne, nie oceny jakości.*

Decision Layer to miejsce, w którym wybór modelu staje się operacyjny. Rynek modeli zmienia się miesięcznie. Ceny spadają. Wypływają nowe flagowce. Open-weight dogania. Architektura Decision Layer wchłania tę zmianę. Architektura związana z dostawcą płaci koszt migracji za każdym razem.

## Dla kogo jest Decision Layer w polskim enterprise?

**Dyrektor IT / CIO**: ocenia oferty Mistral, OpenAI, Anthropic. Ma trzy pitche w tym tygodniu. Wie, że wybór dostawcy to za pięć lat dług architektoniczny. Pyta o exit-strategy, nie o demo.

**Compliance Officer / Inspektor Ochrony Danych**: ma na biurku ekspozycję na US CLOUD Act, art. 22 i 28 RODO oraz nadchodzący art. 13 EU AI Act. Wie, że obietnice handlowe nie przejdą kontroli UODO ani Prezesa UODO.

**Dyrektor HR**: po polskim post-merger (PKN ORLEN + Lotos + PGNiG, Allegro + Mall, Bank Pekao + Alior) wie, że trzy systemy IT to trzy ramy compliance. Pyta, czy Decision Layer skaluje się przy fuzji, nie czy ma ładny dashboard.

**Rada Pracowników**: w polskim enterprise rada nie ma prawa weta jak niemiecki Betriebsrat, ale ma prawo informacji i konsultacji (zgodnie z Ustawą o radach pracowników, art. 13-15). Pyta, jak ramy konsultacji są udokumentowane i jak działa zaskarżenie zgodnie z RODO art. 22.

## Hosting w Polsce i UE: Atman, Polcom, Scaleway, OVHcloud

Pytanie suwerenności w polskim kontekście ma dwie warstwy. Pierwsza: lokalizacja danych. Druga: jurysdykcja providera.

**Atman** (Warszawa). Największy polski operator data center, oferuje colocation oraz GPU-cloud z RTX i A100. Polska jurysdykcja, jasny kontekst RODO. Wybór, gdy zakupy wymagają polskiego operatora.

**Polcom** (Kraków). Polski operator chmury z naciskiem na sektor regulowany. Dobre dopasowanie pod sektor bankowy i ubezpieczeniowy z wymogami KNF Rekomendacja D i DORA.

**Chmura Krajowa / OChK** (Polska, joint venture PKO + PFR + Google Cloud Polska). Sovereign cloud dla podmiotów publicznych i krytycznej infrastruktury zgodnie z NIS2 + KSC. Preferowany dla zakupów wymagających polskiej jurysdykcji i certyfikacji suwerennej dla Critical Entity Operations.

**Scaleway** (Francja). H100 SXM za ok. 3,50 EUR/h, A100 za ok. 2,50 EUR/h, pełne RODO. Jurysdykcja francuska, brak ekspozycji CLOUD Act.

**OVHcloud** (Francja). Największy europejski provider chmury, ze "Sovereign Cloud" dla sektora publicznego i regulowanego. Portfolio: H100, RTX 5000, A10 plus "AI Deploy" do notebooków i inferencji.

**Hetzner** (Niemcy). Lider cenowy w dedykowanych serwerach GPU. Aktualne opcje GPU obejmują RTX 4000 SFF Ada i RTX 6000 Ada w parze z nowoczesnymi CPU. Ścieżka dla Mistral Small 3.2 z kwantyzacją albo dla środowisk deweloperskich.

**T-Systems** (Niemcy). Subsidiary Deutsche Telekom. Sovereign cloud jawnie zaprojektowany dla sektora publicznego i krytycznej infrastruktury. Wybór wygodny dla zakupów, gdy zarząd wymaga certyfikacji suwerennej.

## Wniosek

Ciekawe pytanie dla CTO polskiego enterprise w 2026 nie brzmi "Mistral czy OpenAI". Brzmi "jaki procent moich decyzji agenta wymaga flagowego rozumowania i jak udowodnię to audytorowi".

W dobrze rozłożonym agencie Mistral Small 3.2 na jednym GPU w UE wykonuje większość pracy za znikomy koszt per token. Mistral Medium 3.1 na La Plateforme obsługuje pas środkowy z zachowaną suwerennością UE. Claude Opus 4.7 albo GPT-5.5 obsługują naprawdę trudne przypadki. Routing jest architekturą. Audit trail jest artefaktem compliance. Decision Layer jest miejscem, w którym to wszystko jest doprecyzowane.

Inni publikują tabele porównawcze modeli. My budujemy warstwę routingu, która je operacjonalizuje. Rynek modeli zmienia się miesięcznie; architektura routingu przetrwa pięć generacji modeli. Kod źródłowy zostaje u klienta. Modele pozostają wymienne. Zgodność z EU AI Act art. 13 jest właściwością architektury, nie projektem na końcu.

Jeśli chcesz wiedzieć, jak naprawdę wygląda rozkład złożoności twojego agenta, [umów konsultację](/pl/kontakt/).

--- Next.js nad Supabase - bezpieczna eksploatacja ---
> Runbook DevOps dla Next.js na Supabase: architektura, middleware, wzorce uwierzytelniania, rate limiting i integracja z Claude Code.

Po tym jak Supabase jako platforma backendowa [działa stabilnie](/pl/magazyn/supabase-self-hosting/), na niej budowany jest właściwy stack aplikacyjny.

W wielu nowoczesnych projektach **Next.js** pełni rolę warstwy aplikacyjnej:

- Frontend Rendering
- Server Side Rendering
- Server Actions
- Route Handlers
- API Proxy
- Session Handling

Tym samym Next.js staje się faktycznie **bramą backendową między przeglądarką a Supabase**.

Najczęstszym błędem jest traktowanie tej warstwy jako "frontendu", podczas gdy w rzeczywistości zawiera ona **logikę serwerową z wysokimi uprawnieniami**.

Ten runbook opisuje, jak bezpiecznie eksploatować Next.js nad self-hosted platformą Supabase.

Każda sekcja zawiera:

- Implementację
- warunek weryfikowalny
- Failure Scenario


<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">W skrócie - Artykuł 2 z 6 serii DevOps Runbook</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Next.js jako osobny kontener odizolowany od Supabase</li>
<li>Klucz service_role tylko w jednym pliku</li>
<li>Middleware z getUser() przy każdym żądaniu</li>
<li>Sprawdzenie ownership przed każdą mutacją</li>
<li>Rate limiting na endpointach uwierzytelniania</li>
</ul>
</div>

## Spis treści serii

Ta instrukcja jest częścią naszej serii runbooków DevOps dla self-hosted stacków aplikacyjnych.

1. [Supabase Self-Hosting Runbook](/pl/magazyn/supabase-self-hosting/)
2. [Next.js nad Supabase - bezpieczna eksploatacja](/pl/magazyn/nextjs-supabase-bezpieczna-konfiguracja/) ← ten artykuł
3. [Supabase Edge Functions - bezpieczne wdrożenie](/pl/magazyn/supabase-edge-functions-bezpieczenstwo/)
4. [Bezpieczna obsługa Trigger.dev Background Jobs](/pl/magazyn/trigger-dev-background-jobs/)
5. [Claude Code jako kontrola bezpieczeństwa w DevOps](/pl/magazyn/claude-code-security-devops/)
6. [Security Baseline dla całego stacku](/pl/magazyn/security-baseline-stack/)

Artykuł 1 opisuje bazę platformową. Ten artykuł opisuje **warstwę aplikacyjną powyżej**.

## Przegląd architektury

```
Browser (Client)
     |
     | HTTPS
     |
Next.js App Layer
     |
     +-- @supabase/ssr
     |
     +-- service_role client
           (tylko izolowane konteksty administracyjne)
     |
Supabase Platform Layer
     |
     +-- Kong API Gateway
     +-- GoTrue Auth
     +-- PostgREST API
     +-- Realtime
     |
PostgreSQL Data Layer
     |
     +-- Row Level Security
```

Zasady podstawowe:

```
Browser    -> komunikuje się tylko z Next.js
Next.js    -> komunikuje się z Supabase
Supabase   -> kontroluje dostęp przez RLS
```

Gdy przeglądarka komunikuje się bezpośrednio z wieloma usługami backendowymi, powstają niekontrolowalne granice bezpieczeństwa.

## Część A - Decyzje architektoniczne

Te decyzje są rzadko zmieniane i stanowią fundament.

## A1 - Next.js jako osobna usługa

### Implementacja

Next.js działa jako osobny kontener.

```
services

nextjs-app
supabase-stack
postgres
```

Przykład docker-compose:

```yaml
services:

  nextjs-app:
    build: ./app
    ports:
      - "3000:3000"
    environment:
      - NEXT_PUBLIC_SUPABASE_URL=http://kong:8000
      - NEXT_PUBLIC_SUPABASE_ANON_KEY=${ANON_KEY}
      - SUPABASE_SERVICE_ROLE_KEY=${SERVICE_ROLE_KEY}
    networks:
      - internal
```

Next.js **nie może działać wewnątrz stacku Supabase**.

### Warunek weryfikowalny

```
docker ps --format '{{.Names}}'
```

Oczekiwanie:

```
nextjs-app
supabase-kong
supabase-postgres
supabase-auth
```

### Failure Scenario

Gdy Next.js działa w tym samym kontenerze co Supabase:

- przestrzeń procesów jest współdzielona
- sekrety znajdują się w tym samym środowisku
- skompromitowany serwer Next.js ma bezpośredni dostęp do wszystkich usług backendowych

## A2 - Przeglądarka komunikuje się tylko z Next.js

### Implementacja

Przeglądarka może widzieć tylko jeden publiczny URL.

```
https://app.example.com
```

Niedozwolone:

```
https://app.example.com:8000
https://app.example.com:5432
https://app.example.com:9000
```

Przykład firewalla:

```
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -p tcp --dport 8000 -j DROP
iptables -A INPUT -p tcp --dport 5432 -j DROP
iptables -A INPUT -p tcp --dport 9000 -j DROP
```

### Warunek weryfikowalny

```
nmap -p 443,3000,5432,8000,9000 app.example.com
```

Oczekiwanie:

```
443 open
wszystkie inne filtered
```

### Failure Scenario

Gdy Supabase Studio jest publicznie dostępne:

- pełny dostęp do bazy danych
- manipulacja schematem
- dostęp do bucketów Storage

## A3 - Ustawienie Security Headers

Next.js pełni rolę bramy i musi ustawiać nagłówki HTTP Security.

### Implementacja

```
next.config.js
```

```javascript
const securityHeaders = [
  { key: "X-Frame-Options", value: "DENY" },
  { key: "X-Content-Type-Options", value: "nosniff" },
  { key: "Referrer-Policy", value: "strict-origin-when-cross-origin" },
  { key: "Permissions-Policy", value: "camera=(), microphone=()" },
  { key: "Strict-Transport-Security", value: "max-age=63072000; includeSubDomains" },
  {
    key: "Content-Security-Policy",
    value: "default-src 'self'; img-src 'self' data: blob:; frame-ancestors 'none'"
  }
]
```

### Warunek weryfikowalny

```
curl -I https://app.example.com
```

Oczekiwane nagłówki:

```
X-Frame-Options
Content-Security-Policy
Strict-Transport-Security
```

### Failure Scenario

Bez CSP:

- ataki XSS ładują zewnętrzne skrypty
- tokeny mogą być wykradzione


### Zmienne środowiskowe

| Zmienna | Widoczność | Dozwolona lokalizacja | Ryzyko wycieku |
|---|---|---|---|
| NEXT_PUBLIC_SUPABASE_URL | Klient | .env, kod klienta | Niskie (publiczny URL) |
| NEXT_PUBLIC_SUPABASE_ANON_KEY | Klient | .env, kod klienta | Średnie (ograniczony przez RLS) |
| SUPABASE_SERVICE_ROLE_KEY | Tylko serwer | lib/supabase/admin.ts | Krytyczne (omija RLS) |
| DATABASE_URL | Tylko serwer | .env (serwer) | Krytyczne (bezpośredni dostęp do DB) |
| TRIGGER_API_KEY | Tylko serwer | .env (serwer) | Wysokie (dostęp do kolejki zadań) |

## Część B - Kontrole implementacji

Te zasady obowiązują przy każdej zmianie kodu.

## B1 - Separacja zmiennych środowiskowych

Widoczne dla klienta:

```
NEXT_PUBLIC_SUPABASE_URL
NEXT_PUBLIC_SUPABASE_ANON_KEY
```

Tylko serwer:

```
SUPABASE_SERVICE_ROLE_KEY
DATABASE_URL
TRIGGER_API_KEY
```

### Warunek weryfikowalny

```
grep -r "NEXT_PUBLIC_" .env*
```

Sekrety nie mogą tam występować.

### Build Leak Check

```
grep -r "SERVICE_ROLE" .next/
```

Oczekiwanie:

```
brak wyników
```

### Failure Scenario

`service_role` w bundlu klienta oznacza:

- pełny dostęp do bazy danych
- RLS całkowicie nieskuteczny

Kto zna [podstawy zarządzania sekretami](/pl/magazyn/bezpieczenstwo-danych-ai-enterprise/), rozumie dlaczego ta separacja jest niezbędna.

## B2 - Prawidłowa konfiguracja Supabase SSR Client

Server Client:

```typescript
import { createServerClient } from "@supabase/ssr"
```

Serwer używa **anon key**, nie service_role.

Admin Client:

```typescript
createClient(url, SERVICE_ROLE_KEY)
```

Tylko do zadań administracyjnych.

### Warunek weryfikowalny

```
grep -rn "SERVICE_ROLE" app/
```

Oczekiwanie: tylko w

```
lib/supabase/admin.ts
```

### Failure Scenario

Server Client z service_role:

- RLS jest całkowicie omijany
- wszystkie żądania mają uprawnienia administratora

## B3 - Middleware dla Auth i Token Refresh

Middleware działa **przed każdym żądaniem**.

```
middleware.ts
```

### Implementacja

```typescript
const { data: { user } } = await supabase.auth.getUser()
```

Nie:

```
getSession()
```

### Warunek weryfikowalny

```
grep getUser middleware.ts
```

### Failure Scenario

Bez middleware:

- Token Refresh nie działa
- sesja wygasa po 1 godzinie

## B4 - Wzorzec mutacji

Wszystkie mutacje przebiegają według tego samego schematu.

```
Auth
Input Validation
Ownership Check
Mutation
Logging
```

### Przykład

```typescript
const { user } = await supabase.auth.getUser()

if (!user) return

const post = await supabase
  .from("posts")
  .select("user_id")
  .eq("id", postId)

if (post.user_id !== user.id)
  throw new Error("forbidden")
```

### Failure Scenario

Bez Ownership Check:

> **Statystyka:** Zgodnie z badaniami GitHuba z 2024 roku ponad 23% wycieków sekretów w projektach webowych dotyczy kluczy service_role lub równoważnych tokenów backendowych.


```
deletePost(id)
```

Użytkownik może usunąć cudze dane.

## B5 - Rate Limiting

Next.js nie ma wbudowanego Rate Limitingu.

Zalecane rozwiązanie:

```
Upstash Redis
```

### Przykład

```
10 requests / minute / IP
```

### Warunek weryfikowalny

```
for i in {1..20}
do curl -X POST /api/login
done
```

Oczekiwanie:

```
HTTP 429
```

## B6 - Logowanie bez sekretów

Logi nie mogą zawierać:

```
JWT Tokens
service_role keys
emails
passwords
```

### Warunek weryfikowalny

```
grep console.log app/
```

## Część C - Eksploatacja

## C1 - Aktualizacje zależności

Wydania Next.js są częste.

Cotygodniowa weryfikacja:

```
npm audit
npm outdated
```

Zalecane:

```
Renovate / Dependabot
```

## C2 - Integracja Claude Code

Architektura:

```
Git Push
   |
Kontrole deterministyczne
   |
Raport bezpieczeństwa
   |
Analiza Claude
   |
Decyzja DevOps
```

### Kontrole deterministyczne

```
grep service_role
grep NEXT_PUBLIC
npm audit
```

### Analiza Claude

Claude weryfikuje:

- nowe Server Actions
- nowe API Routes
- wzorce Ownership
- Input Validation
- dryft architektury

Claude **nie wykonuje żadnych zmian na produkcji**.

## Lista kontrolna wdrożenia

Przed każdym wdrożeniem sprawdzić:

```
[ ] Next.js działa jako osobna usługa
[ ] porty Supabase zamknięte zewnętrznie
[ ] Security Headers aktywne

[ ] brak service_role w bundlu klienta
[ ] service_role tylko w Admin Client

[ ] middleware.ts obecny
[ ] Server Actions weryfikują Auth
[ ] Ownership Checks zaimplementowane

[ ] Rate Limit logowania aktywny

[ ] npm audit bez krytycznych wyników
```

## Podsumowanie

Next.js w nowoczesnym stacku nie jest frontendem, lecz uprzywilejowaną warstwą serwerową.

Bezpieczeństwo powstaje na trzech poziomach:

```
Architektura
Kontrole implementacji
bieżące audyty
```

Kombinacja kontroli bezpieczeństwa CI i analizy Claude Code wykrywa zarówno znane wzorce, jak i nowe zagrożenia.

Kto stosuje te zasady razem z architekturą [Cert-Ready by Design](/pl/magazyn/cert-ready-by-design/), buduje weryfikowalne bezpieczeństwo zamiast audytów po fakcie.

<div class="not-prose my-12 border border-gosign-border bg-gosign-light rounded-card p-6 lg:p-8">
<div class="flex items-start gap-4">
<div class="flex-shrink-0 w-12 h-12 bg-gosign-dark rounded-card flex items-center justify-center">
<svg width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="white" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 15v4a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2v-4"/><polyline points="7 10 12 15 17 10"/><line x1="12" y1="15" x2="12" y2="3"/></svg>
</div>
<div>
<h2 class="text-h3 font-bold text-gosign-dark mb-2" id="pobierz-liste-kontrolna-audytu">Pobierz listę kontrolną audytu</h2>
<p class="text-body text-gosign-text mb-2">Przygotowany prompt dla Claude Code. Prześlij plik na swój serwer i uruchom Claude Code w katalogu projektu aplikacji Next.js. Claude Code automatycznie sprawdzi wszystkie punkty bezpieczeństwa z tego runbooka i zgłosi ZALICZONY, OSTRZEŻENIE lub KRYTYCZNY.</p>
<p class="text-sm text-gosign-text mb-4 font-mono">claude -p "$(cat claude-check-artikel-2-nextjs-pl.md)" --allowedTools Read,Grep,Glob,Bash</p>
<a href="/downloads/claude-check-artikel-2-nextjs-pl.md" download class="inline-flex items-center px-6 py-3 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-small uppercase tracking-wider">Pobierz listę kontrolną</a>
</div>
</div>
</div>

## Spis treści serii

1. [Supabase Self-Hosting Runbook](/pl/magazyn/supabase-self-hosting/)
2. [Next.js nad Supabase - bezpieczna eksploatacja](/pl/magazyn/nextjs-supabase-bezpieczna-konfiguracja/) ← ten artykuł
3. [Supabase Edge Functions - bezpieczne wdrożenie](/pl/magazyn/supabase-edge-functions-bezpieczenstwo/)
4. [Bezpieczna obsługa Trigger.dev Background Jobs](/pl/magazyn/trigger-dev-background-jobs/)
5. [Claude Code jako kontrola bezpieczeństwa w DevOps](/pl/magazyn/claude-code-security-devops/)
6. [Security Baseline dla całego stacku](/pl/magazyn/security-baseline-stack/)

Następny artykuł opisuje, jak **bezpiecznie wdrożyć Supabase Edge Functions** - bez budowania drugiej architektury backendowej.

--- Orkiestracja agentów: platformy w porównaniu 2026 ---
> Gdzie działają Twoi agenci AI? Trigger.dev, n8n, Camunda, Temporal, Make i Activepieces w porównaniu dla firm. Z logiką rekomendacji.

## Wiesz, czym są agenci. Teraz: Gdzie działają?

Wiesz już, czym są [agenci AI](/pl/magazyn/czym-sa-agenci-ai/), jak komunikują się z Twoimi systemami (MCP, A2A) i jak kontrolujesz decyzje ([Decision Layer](/pl/magazyn/decision-layer-shadow-ai/)). Następne pytanie jest konkretne: Na jakiej platformie orkiestrujesz tych agentów? Gdzie definiujesz workflow, które łączą model językowy z Twoimi procesami biznesowymi?

Odpowiedź zależy od tego, gdzie stoi Twoja firma: Potrzebujesz szybkich rezultatów z wizualną automatyzacją workflow, czy masz złożone, długotrwałe procesy biznesowe wymagające sterowania zgodnego z BPMN i dokumentacji gotowej do audytu?

Ten artykuł porównuje sześć najistotniejszych platform, wyjaśnia dwa zasadniczo różne podejścia i daje jasną rekomendację, kiedy która platforma jest właściwym wyborem. Ponieważ platforma orkiestracji decyduje o tym, czy Twoja architektura agentów się skaluje, czy utknie na etapie Proof of Concept.

Gartner (2024) prognozuje, że do 2028 roku 33% aplikacji enterprise będzie zawierać Agentic AI - w porównaniu z mniej niż 1% w 2024. Wybór platformy orkiestracji dziś determinuje, czy Twoja organizacja będzie na to gotowa.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">W skrócie - Orkiestracja agentów</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Rynek dzieli się na wizualne narzędzia workflow (n8n, Make, Activepieces) do szybkiego prototypowania i silniki orkiestracji procesów (Camunda, Temporal, Trigger.dev) do produkcyjnego wykonania.</li>
<li>Trigger.dev jest zalecaną opcją domyślną: natywny TypeScript, Durable Execution, licencja Apache 2.0, możliwość self-hostingu, produktywny w dwa tygodnie.</li>
<li>Camunda uzupełnia, gdy formalne diagramy BPMN są wymagane przez Radę Zakładową lub audytorów.</li>
<li>Pięć z sześciu platform obsługuje self-hosting - Make (tylko SaaS) jest wyjątkiem.</li>
<li>Wybór platformy to decyzja architektoniczna wpływająca na governance, compliance i czas do produkcji.</li>
</ul>
</div>

## Dwa światy orkiestracji

Rynek orkiestracji workflow w 2026 roku dzieli się na dwie kategorie rozwiązujące różne problemy. Zrozumienie tej różnicy jest kluczowe dla właściwego wyboru platformy.

### Visual Workflow Automation

Platformy takie jak n8n, Make i Activepieces realizują tę samą zasadę: workflow są tworzone wizualnie przez klikanie. Trigger - nowy e-mail, przychodzący dokument, webhook - uruchamia łańcuch akcji. Każda akcja to węzeł w workflow: odczyt danych, wywołanie modelu AI, wysłanie e-maila, zapis rekordu w systemie ERP. Łańcuch jest składany w edytorze wizualnym, testowany i aktywowany.

Zaleta: Szybkie rezultaty, niski próg wejścia, możliwość obsługi nawet przez osoby nietechniczne. Działający workflow agenta może stać w dni zamiast tygodni. Modele AI są włączane do workflow jak każdy inny serwis - jako jeden węzeł wśród wielu.

Wada: Przy złożonych, długotrwałych procesach z dziesiątkami punktów decyzyjnych i ludzkimi zatwierdzeniami narzędzia wizualne natrafiają na granice. Równoległe ścieżki, wielopoziomowe rozgałęzienia warunkowe, procesy trwające tygodniami i oczekujące na ludzkie dane wejściowe - to nie jest mocna strona edytorów wizualnych.

### Process Orchestration Engines

Platformy takie jak Camunda i Temporal realizują inne podejście. W Camundzie procesy są modelowane jako formalne diagramy BPMN 2.0 - międzynarodowy standard, który mogą czytać także Rady Zakładowe, biegli rewidenci i działy merytoryczne. W Temporal workflow są pisane jako kod w Go, Java, TypeScript lub Python.

Wspólna zaleta: Każdy krok jest wersjonowany i audytowalny. Ludzkie zatwierdzenia (Human Tasks) są kluczowym elementem architektury, nie obejściem. Procesy mogą trwać tygodniami lub miesiącami bez utraty integralności technicznej. Compliance na poziomie korporacyjnym jest wbudowany natywnie.

Wada: Wyższy próg wejścia. Camunda wymaga znajomości BPMN i doświadczenia z silnikami procesów. Temporal wymaga programistów piszących workflow w kodzie. Do szybkiego prototypu to często zbyt duży nakład.

Decyzja między tymi dwoma światami to nie kwestia lepszego czy gorszego. To kwestia dojrzałości, wymagań compliance i gotowości organizacyjnej.

## Platformy w porównaniu

Poniższa tabela zestawia sześć najistotniejszych platform. Uwzględnia typ, możliwość self-hostingu, integrację AI, kluczową siłę, dopasowanie korporacyjne i model licencji.

| Platforma | Typ | Self-Hosted | Integracja AI/LLM | Sila | Dopasowanie korporacyjne | Licencja |
|---|---|---|---|---|---|---|
| **n8n** | Visual Workflow | Tak (Docker, k8s) | Natywne węzły AI, integracja LangChain | 400+ integracji, edytor wizualny, szybkie prototypy, aktywna społeczność | Średnie-Wysokie | Fair Source (darmowe <3 instancji) |
| **Camunda** | BPMN Process Engine | Tak (Self-Managed) lub Camunda Cloud | Konektory do API LLM, Custom Worker dla logiki agenta | BPMN 2.0, Human Tasks, Audit Trail, Compliance-ready, procesy długoterminowe | Bardzo wysokie | Community Edition (Apache 2.0) + Enterprise Edition |
| **Make** (ex Integromat) | Visual Workflow | Nie (tylko SaaS) | Moduły AI | Najłatwiejsze wejście, intuicyjny wizualnie, dobry support | Niskie-Średnie | Własnościowa (SaaS) |
| **Temporal** | Code-first Orchestration | Tak (Docker, k8s) | Dowolna integracja LLM w kodzie Worker | Durable Execution, Retry/Timeout natywnie, ekstremalnie niezawodny | Wysokie | MIT (Core) + Commercial (Cloud) |
| **Activepieces** | Visual Workflow | Tak (Docker) | AI-Pieces | Alternatywa open-source dla n8n/Make, licencja MIT | Średnie | MIT |
| **Trigger.dev** | Code-first (TypeScript) | Tak (Docker, k8s) | Dowolna integracja LLM w kodzie tasków | TypeScript-native, Durable Execution, Retry natywny, Developer-first | Wysoki | Apache 2.0 |

Trzy obserwacje z tabeli:

**Self-hosting jest możliwy na pięciu z sześciu platform.** Make jest wyjątkiem: jako czysty serwis SaaS Twoje dane workflow opuszczają Twoją sieć. Dla firm, które mają wymaganie suwerenności danych, Make odpada dla produktywnych workflow agentów z danymi wrażliwymi.

**Integracja AI jest możliwa na wszystkich platformach**, ale różni się głębokością. n8n oferuje natywne węzły AI włączające modele językowe bezpośrednio w edytorze wizualnym. Camunda i Temporal wymagają więcej pracy deweloperskiej, oferują za to pełną kontrolę nad interakcją z modelem.

**Modele licencji różnią się znacznie.** Activepieces (MIT) i Camunda Community Edition (Apache 2.0) oferują największą swobodę. n8n (Fair Source) jest darmowy dla małych setupów, przy skalowaniu staje się płatny. Temporal (MIT Core) jest w jądrze darmowy, wariant chmurowy płatny.

## Kiedy która platforma?

### n8n: gdy chcesz szybko wystartować

Potrzebujesz w dwa tygodnie działającego agenta, który wyciąga faktury ze skrzynki e-mail, klasyfikuje je przez model językowy i księguje w Twoim systemie ERP? n8n to Twój wybór.

Edytor wizualny umożliwia tworzenie workflow bez klasycznego programowania. Węzły AI są natywnie zintegrowane - możesz włączyć model językowy do workflow jak każdy inny serwis. Self-hosting z Docker oznacza: Twoje dane nie opuszczają Twojej sieci. Społeczność udostępnia ponad 400 integracji - od e-maila i kalendarza przez systemy CRM po bazy danych.

Do pierwszego [agenta AI](/pl/uslugi/ai-agents/) n8n jest w wielu przypadkach właściwą platformą startową. Workflow stoi w dni, rezultaty są natychmiast widoczne, a dział merytoryczny może śledzić workflow w edytorze.

**Kompromis:** Workflow n8n sprawdzają się dobrze przy sekwencyjnych automatyzacjach i prostych rozgałęzieniach. Przy procesach z równoległymi ścieżkami, ludzkimi pętlami zatwierdzania trwającymi kilka dni lub wymaganiami compliance wobec wersjonowania i kompletnego audytu robi się ciasno. n8n protokołuje wykonania, ale nie oferuje natywnego modelowania BPMN, wersjonowanych definicji procesów ani Human Tasks jako koncepcji architektonicznej.

### Camunda: gdy compliance jest nienaruszalny

Twoja Rada Zakładowa chce prześledzić, który agent podjął jaką decyzję? Twoi biegli rewidenci potrzebują kompletnego Audit Trail? Proces trwa tygodniami - na przykład onboarding, zatwierdzanie umów, zatwierdzanie zamówień? Wtedy potrzebujesz silnika BPMN.

Camunda modeluje procesy jako formalne diagramy (BPMN 2.0), które każdy partner biznesowy może przeczytać - również Rada Zakładowa. Human Tasks są kluczowym konceptem: w zdefiniowanych miejscach proces czeka na ludzkie zatwierdzenie. Każda decyzja jest wersjonowana i odtwarzalna. Agenci AI są włączani jako Service Tasks - model językowy staje się krokiem w procesie biznesowym, nie czarną skrzynką.

Community Edition na licencji Apache 2.0 jest w pełni samohostawalna. Enterprise Edition oferuje dodatkowo clustering, rozszerzone funkcje monitorowania i profesjonalny support. Dla firm stosujących [Decision Layer](/pl/magazyn/decision-layer-shadow-ai/) jako architekturę governance, Camunda jest naturalnym wyborem dla warstwy wykonawczej: procesy BPMN odwzorowują mikro-decyzje, Human Tasks wymuszają ludzkie zatwierdzenia, a Audit Trail powstaje automatycznie.

### Temporal: gdy Twoi programiści potrzebują pełnej kontroli

Temporal jest code-first: workflow są pisane w Go, Java, TypeScript lub Python. Brak edytora wizualnego, za to maksymalna kontrola nad logiką ponownych prób, timeoutami i obsługą błędów.

Dla agentów AI wykonujących złożone, wieloetapowe zadania o nieprzewidywalnych czasach trwania - analiza dokumentów z pytaniami zwrotnymi, wieloetapowe walidacje lub przetwarzanie wsadowe dużych zbiorów danych - Temporal jest najbardziej niezawodnym wyborem. Koncept "Durable Execution" zapewnia, że workflow są kontynuowane nawet przy awariach serwerów, przerwach sieciowych lub timeoutach modelu.

**Kompromis:** Temporal wymaga programistów opanowujących workflow-as-code. Działy merytoryczne nie mogą dostosowywać workflow Temporal w edytorze. Dla firm bez silnego zespołu programistycznego Temporal nie wchodzi w grę. Dla firm z doświadczonymi programistami, które potrzebują maksymalnej niezawodności przy złożonych workflow agentów, to najlepszy wybór.

### Trigger.dev: rosnący standard orkiestracji agentów

Trigger.dev ugruntował swoją pozycję w 2025/2026 jako jedna z najszybciej rosnących platform orkiestracji. Powód: workflow są pisane w TypeScript - języku, który już dominuje większość nowoczesnego web developmentu. Bez edytora wizualnego, bez dodatkowego języka. Kto już ma TypeScript w stacku, orkiestruje agentów w tym samym języku, tym samym IDE, tym samym systemie CI/CD.

Platforma jest wykorzystywana przez rosnącą liczbę organizacji - od startupów AI przez firmy SaaS po zespoły enterprise prowadzące produktywne workflow agentów. Aktywna społeczność open-source na GitHubie, regularne wydania i developer experience na poziomie nowoczesnych standardów czynią Trigger.dev naturalnym wyborem dla zespołów już pracujących w TypeScript.

Durable Execution jest wbudowane: każdy task przetrwa awarie serwerów, problemy sieciowe i timeouty modeli. Logika retry, timeouty i obsługa błędów są definiowane w kodzie, nie konfigurowane w UI. Pełna historia wykonania jest dostępna do inspekcji, każdy krok jest śledzony. To czyni Trigger.dev odpowiednim nie tylko do prototypów, ale do produktywnych workflow - od klasyfikacji e-maili przez przetwarzanie dokumentów po wieloetapowe łańcuchy agentów.

Self-hosting z Docker lub Kubernetes jest w pełni wspierany. Licencja Apache 2.0 zapewnia brak limitów użytkowania. Bez zależności Java (jak Temporal), bez narzutu BPMN (jak Camunda), bez edytora wizualnego, który spowalnia przy złożoności (jak n8n).

**Kompromis:** Trigger.dev wymaga programistów TypeScript. Użytkownicy biznesowi nie mogą modyfikować workflow w edytorze. Dla zespołów Go lub Java lepszym wyborem jest Temporal. Gdy formalne diagramy BPMN są wymagane przez Radę Zakładową lub audytorów, Camunda uzupełnia architekturę.

## Praktyczna rekomendacja: Trigger.dev jako standard, Camunda przy wymogach BPMN

Trigger.dev nadaje się jako podstawowa platforma orkiestracji - od pierwszego agenta po produktywną eksploatację. Workflow oparte na TypeScript pasują bezpośrednio do istniejącego procesu deweloperskiego: wersjonowane w Git, testowalne w CI, wdrażane tymi samymi narzędziami co reszta stacku. Działający agent w dwa tygodnie przekonuje zarząd bardziej niż koncepcja architektury w dwa miesiące.

Trigger.dev skaluje się ponad pierwszy use case. Durable Execution, kompletne historie wykonań i licencja Apache 2.0 bez limitów instancji czynią platformę odpowiednią także dla produktywnych workflow enterprise. Wiele organizacji prowadzi całą orkiestrację agentów na Trigger.dev - od klasyfikacji e-maili przez przetwarzanie dokumentów po wieloetapowe łańcuchy agentów z dziesiątkami tasków.

Camunda wchodzi do gry, gdy wymagane są formalne diagramy BPMN - typowo przy procesach, które muszą być czytelne dla Rady Zakładowej, biegłych rewidentów lub zewnętrznych audytorów. Nie dlatego, że Trigger.dev nie jest gotowy na produkcję, ale dlatego, że BPMN jest formatem komunikacji, który rozumieją także osoby nietechniczne.

Kluczowe rozróżnienie: zdolność do compliance nie jest kwestią platformy, lecz implementacji. Audit Trail, [Decision Layer](/pl/magazyn/decision-layer-shadow-ai/), Human-in-the-Loop i pełna odtwarzalność mogą być zbudowane bezpośrednio w workflow Trigger.dev - jako wersjonowany, testowalny kod TypeScript. Gosign wbudowuje tę warstwę governance standardowo w każdą implementację agenta: każda decyzja jest protokołowana, każde ludzkie zatwierdzenie udokumentowane, każdy krok procesu jest śledzony w Audit Trail. Jedyny powód dla Camundy to nie techniczne compliance - to dostarcza Trigger.dev - ale organizacyjna czytelność: Rada Zakładowa lub biegły rewident może przeczytać diagram BPMN, ale nie kod TypeScript. Gdy Twój zespół deweloperski lub wyspecjalizowany partner jak Gosign buduje warstwę compliance w kodzie, Trigger.dev pokrywa wszystkie wymagania.

Oba narzędzia mogą współistnieć: Trigger.dev jako standard dla wszystkich typów workflow agentów - klasyfikacja e-maili, ekstrakcja danych, wieloetapowe łańcuchy agentów, wewnętrzne automatyzacje. Camunda do modelowanych w BPMN procesów kluczowych, gdzie formalne diagramy są wymogiem compliance: onboarding, zatwierdzanie umów, zatwierdzanie zamówień. Podział wynika z pytania: Czy ten proces musi istnieć jako formalny diagram BPMN? Jeśli tak, Camunda uzupełnia. Jeśli nie, Trigger.dev.

Dla firm stawiających na alternatywy z licencją MIT, Activepieces jest dobrym wyborem w obszarze wizualnych workflow. Platforma oferuje mniej integracji niż n8n, ale otwarta licencja eliminuje kwestie kosztów przy skalowaniu.

## Integracja z architekturą agentów

Platforma orkiestracji nie jest izolowana. Jest warstwą wykonawczą w [architekturze agentów](/pl/magazyn/czym-sa-agenci-ai/), która łączy wszystkie komponenty. Poniższy diagram pokazuje współdziałanie warstw:

```
+-----------------------------------------+
|         Enterprise-AI-Portal            |
|  (LobeChat / OpenWebUI / LibreChat /    |
|   chatbot-ui / very-ai)                 |
+------------------+----------------------+
|
+------------------v----------------------+
|     Platforma orkiestracji              |
|  (Trigger.dev / Camunda / Temporal)     |
|                                         |
|  +-----+  +---------+  +------------+  |
|  |Krok |->| LLM     |->| Decision   |->|
|  |  1  |  | Analiza |  | Layer      |  |
|  +-----+  +---------+  +------------+  |
+------------------+----------------------+
|
+--------------+---------------+
v              v               v
+--------+  +----------+  +----------+
|  RAG / |  |   ERP /  |  | E-Mail / |
| Wektor |  |   CRM    |  | Kalendarz|
|   DB   |  |          |  |          |
+--------+  +----------+  +----------+
```

Każda warstwa ma zdefiniowane zadanie:

- **[Enterprise-AI-Portal](/pl/magazyn/enterprise-ai-chat-interface/)** to interfejs, przez który użytkownicy uruchamiają agentów i przeglądają wyniki. Pracownicy nie wchodzą bezpośrednio w interakcje z platformą orkiestracji - korzystają z portalu. Połączenie jest szczególnie płynne, gdy portal posiada natywną integrację workflow. very-ai może uruchamiać workflow Trigger.dev bezpośrednio z czatu - użytkownik wpisuje zapytanie, agent analizuje, a Trigger.dev wykonuje proces kontynuacji. Przy innych portalach to połączenie wymaga webhooków lub middleware API.
- **Platforma orkiestracji** (ten artykuł) definiuje workflow: jakie kroki w jakiej kolejności, jakie warunki obowiązują i co się dzieje przy błędach. Jest centralą wykonania agentów.
- **Model AI** przeprowadza analizę: rozumienie tekstu, ekstrakcja dokumentów, przygotowanie decyzji. W architekturze agnostycznej modelowo odpowiedni model jest wybierany na każdy krok.
- **[Decision Layer](/pl/magazyn/decision-layer-shadow-ai/)** kontroluje w każdym punkcie decyzyjnym, czy AI może działać autonomicznie, czy obowiązuje zestaw reguł, czy człowiek musi zatwierdzić.
- **RAG** dostarcza modelowi kontekst z dokumentów firmowych: umowy, regulaminy, podręczniki.

Platforma orkiestracji łączy te komponenty w działający workflow. Bez niej poszczególne komponenty pozostają izolowane: Model językowy, który potrafi analizować dokumenty, ale nikt nie zdefiniował, co dzieje się potem. Pipeline RAG, który znajduje odpowiednie fragmenty, ale żaden workflow nie prowadzi dalej wyników. Decision Layer definiujący reguły, ale żaden system ich nie wykonuje.

Wybór platformy determinuje, jak dobrze ta integracja się udaje. Trigger.dev sprawia, że integracja jest dostępna jako kod: workflow to pliki TypeScript w Twoim repozytorium. Camunda czyni integrację formalnie odtwarzalną: widzisz proces jako diagram BPMN. n8n czyni integrację wizualnie przystępną dla osób nietechnicznych.

## Modele licencji szczegółowo

Dla decydentów korporacyjnych kwestia licencji nie jest trywialna. Różnice mają bezpośredni wpływ na koszty, skalowalność i uzależnienie od dostawcy.

**n8n (Fair Source):** Kod źródłowy jest dostępny do wglądu i samodzielnego hostowania. Dla maks. trzech instancji użytkowanie jest darmowe. Od czwartej instancji wymagana jest licencja Enterprise. Dla firm zaczynających z jednym setupem n8n to nie przeszkoda. Przy skalowaniu na wiele zespołów lub lokalizacji powstają koszty licencji.

**Camunda (Apache 2.0 + Enterprise):** Community Edition jest w pełni open source na licencji Apache 2.0, bez ograniczeń. Enterprise Edition oferuje clustering, rozszerzoną obserwowalność i profesjonalny support. Na start wystarczy Community Edition. Do produktywnego wdrożenia korporacyjnego z wysoką dostępnością zalecana jest Enterprise Edition.

**Temporal (MIT + Commercial):** Serwer Core jest licencjonowany na MIT, w pełni darmowy. Wariant chmurowy (Temporal Cloud) to komercyjny serwis. Do self-hostingu nie jest potrzebna umowa licencyjna. Dla firm, które nie chcą samodzielnie prowadzić infrastruktury, Temporal Cloud oferuje zarządzaną alternatywę.

**Activepieces (MIT):** W pełni open source na licencji MIT. Brak ograniczeń, brak limitów używania. Najmniej restrykcyjna opcja. Za to mniejszy ekosystem i mniej integracji niż n8n.

**Trigger.dev (Apache 2.0):** W pełni open source na licencji Apache 2.0. Self-hosting bez ograniczeń, brak limitów użytkowania, brak limitów instancji. Najbardziej otwarta licencja obok Activepieces, z aktywną społecznością deweloperów i regularnymi wydaniami.

**Make (własnościowa):** Czysty model SaaS. Brak self-hostingu, brak wglądu w kod. Dla środowisk korporacyjnych z wymaganiami suwerenności danych nie nadaje się. Dla szybkich, niewrażliwych automatyzacji opcja do rozważenia, jeśli dane mogą opuścić sieć firmową.

## Checklista: Która platforma pasuje do Twojego scenariusza?

Poniższa logika decyzyjna pomaga w pierwszym przyporządkowaniu:

**Scenariusz 1: Workflow agentów w TypeScript, od pierwszego use case po produkcję**
Rekomendacja: Trigger.dev. Workflow oparte na TypeScript, Durable Execution, produktywne w dwa tygodnie. Self-hosting z Docker. Kod w Git, testowalny w CI. Skaluje się od pierwszego agenta po dziesiątki produktywnych workflow.

**Scenariusz 2: Procesy wymagające compliance, Rada Zakładowa, wymagania audytu**
Rekomendacja: Camunda. BPMN 2.0, Human Tasks, wersjonowane procesy, kompletny Audit Trail. Community Edition na Apache 2.0 na start, Enterprise Edition do produkcji.

**Scenariusz 3: Złożone, długotrwałe workflow o nieprzewidywalnych czasach trwania**
Rekomendacja: Temporal. Code-first, maksymalna kontrola, Durable Execution. Wymaga wiedzy deweloperskiej.

**Scenariusz 4: Jedno i drugie - szybkie automatyzacje i audytowane procesy kluczowe**
Rekomendacja: Trigger.dev i Camunda równolegle. Trigger.dev do wewnętrznych automatyzacji, Camunda do procesów wymagających compliance. Komunikacja przez API i webhooki.

**Scenariusz 5: Licencja MIT bez kompromisów**
Rekomendacja: Activepieces do wizualnych workflow, Temporal Core do workflow code-first.

## Następne kroki

Platforma orkiestracji jest środkiem, nie celem. Sama właściwa platforma nie tworzy jeszcze działającego agenta. Do tego potrzebujesz kompletnej [infrastruktury](/pl/uslugi/infrastruktura/): modeli AI, hostingu, portalu Enterprise-AI jako interfejsu i architektury governance zapewniającej compliance.

Gosign stosuje Trigger.dev jako podstawową platformę orkiestracji i wspiera w wyborze oraz wdrożeniu odpowiedniej architektury - od ewaluacji przez pierwszy PoC po produktywną eksploatację. Agnostycznie wobec modeli, z pełnym dostępem do kodu źródłowego.

---

**Który proces powinien przejąć Twój pierwszy agent?**

<a href="/pl/kontakt/" target="_blank" rel="noopener noreferrer">Umów spotkanie</a>. 30 minut, w których zidentyfikujemy właściwy pierwszy use case i odpowiednią platformę orkiestracji dla Twojej firmy.

--- Anonimizacja PII dla Enterprise AI ---
> Jak przetwarzać dokumenty z danymi osobowymi zgodnie z RODO przy pomocy AI? Pseudonimizacja roundtrip, Decision Layer, Audit Trail.

## Dlaczego dane osobowe stanowią problem przy przetwarzaniu przez AI

Gdy agent AI analizuje umowę o pracę, sprawdza listę płac lub przetwarza zwolnienie lekarskie, operuje na danych osobowych. Imię i nazwisko, adres, data urodzenia, numer PESEL, wynagrodzenie, diagnoza.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">W skrócie - Anonimizacja PII dla Enterprise AI</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Pseudonimizacja roundtrip zastępuje PII spójnymi pseudonimami przed przetwarzaniem przez LLM, a następnie przywraca prawdziwe dane w wynikach.</li>
<li>Decision Layer steruje, które kategorie PII są wykrywane w danym procesie (HR, finanse, compliance) - poprzez wersjonowane zestawy reguł.</li>
<li>Pseudonimizacja zachowuje strukturę i kontekst dokumentu - w przeciwieństwie do zamazywania, które czyni dokumenty bezużytecznymi dla analizy AI.</li>
<li>Confidence Routing eskaluje niejednoznaczne encje do człowieka; ukryte identyfikatory wymagają reguł kontekstowych w zestawie reguł.</li>
<li>IAPP (2024) stwierdza, że 58% organizacji przetwarzających dokumenty z AI nie posiada systematycznego wykrywania PII - narażając się na egzekwowanie RODO.</li>
</ul>
</div>

Przesyłanie tych danych do modelu językowego, nawet hostowanego lokalnie, jest problematyczne z punktu widzenia ochrony danych. RODO wymaga [minimalizacji danych](/pl/governance/data-residency/) (art. 5 ust. 1 lit. c): przetwarzane mogą być wyłącznie dane niezbędne do realizacji celu. Do klasyfikacji typu dokumentu model nie potrzebuje nazwiska pracownika. Do weryfikacji zgodności z siatką płac nie potrzebuje daty urodzenia.

Jednocześnie model potrzebuje kontekstu. Umowa pozbawiona wszelkich informacji o osobach jest bezwartościowa dla analizy AI, brakuje w niej odniesień, relacji i powiązań.

Rozwiązaniem nie jest zamazywanie, lecz pseudonimizacja.

## Pseudonimizacja roundtrip: zasada działania

Pseudonimizacja roundtrip to proces trzyetapowy:

**Krok 1: Rozpoznanie i zastąpienie.** Warstwa pre-processingu rozpoznaje wszystkie dane osobowe w dokumencie. Każda instancja PII jest zastępowana spójnym pseudonimem: "Jan Kowalski" staje się "Osoba_A", "12 000 PLN" staje się "Wynagrodzenie_A", "ul. Marszałkowska 8" staje się "Adres_A". Kluczowe: pseudonimy są spójne. Jeśli "Jan Kowalski" pojawia się ponownie na stronie 3, nadal jest "Osoba_A". To zachowuje strukturę dokumentu.

**Krok 2: Przetworzenie.** Spseudominizowany dokument trafia do modelu językowego. Model widzi: "Osoba_A ma Wynagrodzenie_A pod Adres_A. Umowa obowiązuje do 2027 roku." Może przeprowadzić analizę umowy, weryfikację siatki płac, klasyfikację klauzul, nie widząc nigdy prawdziwego nazwiska ani wynagrodzenia.

**Krok 3: Re-anonimizacja.** Wynik modelu zawiera pseudonimy: "Osoba_A mieści się w grupie zaszeregowania E3." Warstwa re-anonimizacji zastępuje pseudonimy prawdziwymi danymi: "Jan Kowalski mieści się w grupie zaszeregowania E3." Tabela przyporządkowań jest usuwana po zakończeniu przetwarzania.

## Co steruje Decision Layer

Nie każde pole danych wymaga pseudonimizacji. Decision Layer definiuje, które kategorie PII są rozpoznawane i zastępowane, na podstawie wersjonowanego zestawu reguł:

W procesie HR: pseudonimizacja imion i nazwisk, wynagrodzeń, adresów, numerów PESEL. Stanowiska i działy mogą pozostać, są istotne dla analizy i nie stanowią danych osobowych.

W procesie finansowym: nazwy firm pozostają, dane kontaktowe osób są pseudonimizowane, kwoty pozostają (są istotne dla decyzji księgowych), dane bankowe są pseudonimizowane.

W procesie compliance: pseudonimizacja wszystkiego, łącznie z nazwami firm, jeśli analiza ma być międzydziałowa.

Te reguły są specyficzne dla danego mandanta i wersjonowane. Gdy zmienia się porozumienie zakładowe, powstaje nowa wersja reguł. Podczas kontroli można prześledzić, jaka reguła PII w jakiej wersji obowiązywała w momencie przetwarzania.

## Ograniczenia i uczciwa ocena

Rozpoznawanie PII nie jest perfekcyjne. Named Entity Recognition (NER) popełnia błędy, szczególnie w przypadku:

Niejednoznacznych nazw: "Kowalski" może być nazwiskiem lub nazwą firmy. "Warszawa" może być miastem lub częścią nazwy własnej. Decision Layer adresuje to poprzez Confidence Routing: przy wysokim poziomie pewności pseudonimizacja następuje automatycznie. Przy niskim poziomie pewności sprawa jest eskalowana do człowieka.

Ukrytych identyfikatorów: "Jedyna programistka w oddziale w Krakowie" nie zawiera jawnych danych PII, ale umożliwia identyfikację osoby. Takie pośrednie identyfikatory są trudne do automatycznego wykrycia. Podejście: reguły kontekstowe w zestawie reguł definiują kombinacje cech umożliwiające identyfikację.

Nowych typów dokumentów: gdy pojawia się nowy typ dokumentu, zestaw reguł PII musi być zweryfikowany i ewentualnie rozszerzony. To nie jest jednorazowa konfiguracja, lecz ciągły proces.

| Kategoria PII | Proces HR | Proces finansowy | Proces compliance |
|---|---|---|---|
| Imiona i nazwiska | Pseudonimizowane | Osoby kontaktowe pseudonimizowane | Wszystko pseudonimizowane |
| Wynagrodzenia / Kwoty | Pseudonimizowane | Pozostają (decyzje księgowe) | Pseudonimizowane |
| Adresy | Pseudonimizowane | Pozostają | Pseudonimizowane |
| Numery identyfikacyjne (PESEL) | Pseudonimizowane | Pseudonimizowane | Pseudonimizowane |
| Nazwy firm | Pozostają | Pozostają | Pseudonimizowane |
| Stanowiska | Pozostają | Pozostają | Kontekstowo |
| Dane bankowe | Pseudonimizowane | Pseudonimizowane | Pseudonimizowane |

Więcej o Document Intelligence: [Document Intelligence - PII, redakcja umów, rozpoznawanie podpisów](/pl/uslugi/document-intelligence/)

<a href="/pl/kontakt/" target="_blank" rel="noopener noreferrer">Umów spotkanie</a> - Pokażemy pseudonimizację roundtrip na Twoich dokumentach.

--- Rada Zakładowa & AI Literacy: Pytania organizacyjne ---
> Dlaczego projekty AI zawodzą na organizacji, nie na technologii. Współdecydowanie jako wymaganie projektowe i obowiązek szkoleniowy od 2025.

## Technika rzadko jest problemem

Gdy projekty AI w firmach zawodzą, w najrzadszych przypadkach wynika to z technologii. Modele działają. API są stabilne. Infrastruktura jest dostępna. To, co zawodzi, to organizacja: Rada Zakładowa wydaje negatywną opinię o wdrożeniu, bo została poinformowana za późno. Pracownicy nie korzystają z nowych narzędzi, bo nie zostali przeszkoleni.

Ten artykuł omawia dwa pytania organizacyjne, które towarzyszą każdemu wdrożeniu AI: Jak pozyskać Radę Zakładową jako wspierającego partnera? I jak spełnić ustawowy obowiązek AI Literacy?

EU AI Act (Artykuł 4) nakłada obowiązek AI Literacy na wszystkich użytkowników systemów AI od lutego 2025. Kary za naruszenia: do 35 mln EUR lub 7% rocznego obrotu.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">W skrócie - Rada Zakładowa & AI Literacy</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Projekty AI zawodzą na organizacji, nie na technologii. Rada Zakładowa i AI Literacy to dwa decydujące czynniki.</li>
<li>Zaangażuj Radę Zakładową na etapie architektury, nie przy prezentacji wyników. Decision Layer czyni AI transparentną i audytowalną z założenia.</li>
<li>AI Literacy jest prawnie wymagana od lutego 2025 (EU AI Act, Artykuł 4). Kary za naruszenia: do 35 mln EUR lub 7% obrotu.</li>
<li>Porozumienie zakładowe staje się egzekwowalne, gdy jego reguły są zaimplementowane jako ograniczenia techniczne w Decision Layer.</li>
<li>Programy szkoleniowe dostosowane do ról zamieniają obowiązki compliance w przewagi konkurencyjne: świadomi pracownicy używają AI efektywniej.</li>
</ul>
</div>

## Rada Zakładowa i konsultacja - od blokera do enablera

### Dlaczego Rada Zakładowa musi być konsultowana

W polskich firmach z reprezentacją pracowniczą Rada Zakładowa (rada pracowników) ma prawo do informacji i konsultacji przy wdrażaniu systemów technicznych, które mogą wpływać na warunki pracy. Systemy AI prawie zawsze pod to podlegają: przetwarzają dane użytkowe, protokołują interakcje, a ich decyzje dotyczą bezpośrednio lub pośrednio warunków pracy. W odróżnieniu od niemieckiej rady zakładowej, która posiada rzeczywiste prawo weta wobec wdrożeń technologicznych, polska rada pracowników ma tylko prawo konsultacji - pracodawca musi konsultować, ale ostateczna decyzja leży po jego stronie.

To nie jest przeszkoda, lecz ramy projektowe. Rada Zakładowa ma prawo do informacji i konsultacji w sprawach dotyczących zmian technologicznych. To różnica, która w praktyce jest często pomijana.

Problem powstaje nie przez sam obowiązek konsultacji, lecz przez moment, w którym Rada Zakładowa jest włączana. W większości nieudanych projektów AI Rada Zakładowa jest informowana dopiero, gdy decyzja techniczna już zapadła. Otrzymuje prezentację z gotowymi wynikami, nie ma możliwości wpływu na architekturę i reaguje negatywną opinią.

### Architektura jako odpowiedź

Pytania Rady Zakładowej są uzasadnione i przewidywalne: Jakie dane przetwarza system AI? Kto ma dostęp? Czy zbierane są dane o wydajności? Kto podejmuje finalną decyzję - AI czy człowiek? Czy decyzje można prześledzić?

[Decision Layer](/pl/decision-layer/) odpowiada na te pytania technicznie, nie tylko w porozumieniu zakładowym na papierze. Warstwa architektoniczna definiuje:

**Granice decyzyjne:** Co AI może przygotować, co decyduje zestaw reguł, co musi zatwierdzić człowiek.

**Human-in-the-Loop:** Technicznie wymuszone zatwierdzenie przez człowieka przy zdefiniowanych klasach decyzji. Żaden człowiek nie może być pominięty, ponieważ architektura na to nie pozwala.

**Audit Trail:** Każda decyzja AI jest protokołowana - który model, jakie dane wejściowe, jakie dane wyjściowe, jaka reguła zastosowana, czy człowiek był zaangażowany.

**Kontrola dostępu (RBAC):** Uprawnienia dostępu oparte na rolach zapobiegają nieautoryzowanemu dostępowi do wrażliwych danych lub funkcji.

### Porozumienia zakładowe jako System-Constraints

Kluczowa zaleta przemyślanej architektury AI: Porozumienia zakładowe są nie tylko zapisane na papierze, ale implementowane jako reguły techniczne w systemie.

**Po pierwsze: Porozumienia jako konfigurowalne zestawy reguł.** To, co stoi w porozumieniu zakładowym - np. „Dane o wydajności nie mogą być analizowane bez zgody pracownika" - jest implementowane jako Constraint w Decision Layer. System nie może obejść porozumienia, ponieważ reguła jest egzekwowana technicznie.

**Po drugie: Transparencja przez kompletny Audit Trail.** Rada Zakładowa może w każdej chwili prześledzić, jakie decyzje podjął system AI, na jakiej podstawie i czy udzielono ludzkich zatwierdzeń. Żadna czarna skrzynka, żadne pytanie o zaufanie.

**Po trzecie: RBAC zapobiega niekontrolowanemu dostępowi.** Tylko zdefiniowane role mają dostęp do określonych funkcji AI. Kierownik zespołu może korzystać z chatbota, ale nie z analizy wydajności. Manager HR może przeglądać analizę wydajności, ale nie eksportować surowych danych. Uprawnienia są granularnie konfigurowalne.

**Po czwarte: Brak profilowania bez wyraźnej zgody.** Architektura technicznie zapewnia, że analizy dotyczące osób mogą być przeprowadzane wyłącznie z wyraźną zgodą - skonfigurowaną w zestawie reguł.

### Rekomendacja praktyczna: Warsztat architektoniczny

Zaproście Radę Zakładową na warsztat architektoniczny - nie na spotkanie z wynikami. Pół dnia, podczas którego Rada Zakładowa rozumie, jak działa Decision Layer, jakie dane są przetwarzane i jak porozumienia zakładowe są technicznie realizowane, oszczędza miesiące negocjacji.

Doświadczenie pokazuje: Gdy Rada Zakładowa rozumie architekturę i widzi, że jej postulaty są nie tylko wysłuchane, ale technicznie wdrożone, przechodzi od potencjalnego blokera do aktywnego wspierającego partnera. Rada Zakładowa nie chce zapobiegać AI. Chce zapewnić, że prawa pracowników są chronione. Transparentna architektura daje jej dokładnie tę pewność.

## AI Literacy - obowiązek ustawowy od lutego 2025

### Podstawa prawna

Artykuł 4 [EU AI Act](/pl/magazyn/eu-ai-act-2026-przedsiebiorstwa/) zobowiązuje wszystkich dostawców i operatorów systemów AI do zapewnienia, że ich pracownicy posiadają wystarczający poziom kompetencji AI. Obowiązek obowiązuje od 2 lutego 2025 i dotyczy każdej firmy stosującej AI - niezależnie od wielkości i niezależnie od klasy ryzyka systemu AI.

Sformułowanie „wystarczający poziom kompetencji AI" jest celowo otwarte. Musi być interpretowane adekwatnie do kontekstu: Członek zarządu podejmujący decyzję o wdrożeniu systemu AI potrzebuje innych kompetencji niż referent korzystający z chatbota. Ale obaj potrzebują kompetencji. I obie kompetencje muszą być udokumentowane.

**Sankcje:** Naruszenia obowiązku AI Literacy podlegają ogólnym przepisom karnym EU AI Act. Maksymalne kary wynoszą do 35 milionów euro lub 7 procent światowego obrotu rocznego.

### Kto musi być przeszkolony?

Wszystkie osoby, które w jakiejkolwiek formie korzystają, obsługują lub decydują o systemach AI. Obejmuje to:

- Zarząd i dyrekcję (odpowiedzialność decyzyjna)
- Kierowników działów i team leadów (odpowiedzialność za użytkowanie)
- Specjalistów i referentów (operacyjne użytkowanie)
- IT i rozwój (obsługa techniczna)
- Radę Zakładową (odpowiedzialność za konsultację i nadzór)

### Co musi być szkolone?

Treści muszą być adekwatne do kontekstu. Minimum to cztery obszary kompetencji:

1. **Podstawowe rozumienie działania AI:** Jak działa model językowy? Jaka jest różnica między analizą a decyzją? Co AI potrafi, czego nie potrafi?
2. **Rozpoznawanie halucynacji:** Modele językowe generują wiarygodnie brzmiące, ale merytorycznie fałszywe wypowiedzi. Użytkownicy muszą być w stanie krytycznie weryfikować wyniki.
3. **Odpowiedzialne korzystanie:** Jakie dane mogą być wprowadzane? Jakie nie? Co dzieje się z danymi wejściowymi? Gdzie leżą granice użytkowania?
4. **Ochrona danych:** Jakie dane osobowe mogą być przetwarzane? Jakie zgody są wymagane? Jakie dane opuszczają sieć firmową?

### Jak udowodnić compliance?

EU AI Act wymaga udowodnienia, że szkolenia się odbyły. To oznacza:

- Dokumentację treści i materiałów szkoleniowych
- Listy uczestników z datą i podpisem
- Regularne odświeżanie (zalecane: corocznie, przy istotnych zmianach systemu doraźnie)
- Różnicowanie według ról i odpowiedzialności

Standardowy 30-minutowy webinar nie spełnia wymagań. Szkolenie musi być dostosowane do roli, adresować konkretne systemy AI firmy i zawierać elementy interaktywne, które czynią zrozumienie weryfikowalnym.

## Rekomendacja praktyczna: Enterprise-AI-Portal jako budowanie kompetencji

[Enterprise-AI-Portal](/pl/magazyn/enterprise-ai-chat-interface/) to nie tylko narzędzie produktywności - to również najskuteczniejszy instrument budowania kompetencji. Pracownicy, którzy codziennie pracują z kontrolowanym systemem AI, rozwijają kompetencje wymagane przez obowiązek AI Literacy w praktyce: Uczą się krytycznie weryfikować wyniki. Rozumieją, jakie dane wejściowe dają dobre wyniki, a jakie nie. Rozwijają wyczucie granic technologii.

To nie zastępuje formalnego szkolenia. Ale uzupełnia je o najważniejszy czynnik: codzienne zastosowanie. Firma, która udostępnia swoim pracownikom dobre wewnętrzne AI-Portal, inwestuje jednocześnie w compliance (obowiązek AI Literacy) i produktywność.

## Podsumowanie: Organizacja decyduje

Dwa pytania organizacyjne - konsultacja z radą pracowników i kompetencja - nie są drugorzędnymi aspektami wdrażania AI. Są głównymi aspektami. Technologia jest dostępna, przystępna cenowo i wydajna. Pytanie brzmi, czy Wasza organizacja jest w stanie z niej korzystać.

Rada Zakładowa, która rozumie architekturę, staje się wspierającym partnerem. Przeszkoleni pracownicy korzystają z narzędzi produktywnie. A organizacja, która proaktywnie odpowiada na oba pytania, zyskuje przewagę konkurencyjną, której żaden upgrade modelu nie zastąpi.

Dalej: [Decision Layer](/pl/decision-layer/) | [Governance](/pl/governance/) | [HR & AI Agents](/pl/hr-ai-agents/)

---

**Enterprise AI-Infrastructure Blueprint 2026, Seria artykulow**

| ← Poprzedni | Przegląd | Następny → |
|:---|:---:|---:|
| [EU AI Act 2026: Co obowiązuje, co nadchodzi, co musisz zrobić](/pl/magazyn/eu-ai-act-2026-przedsiebiorstwa/) | [Do przeglądu](/pl/magazyn/infrastruktura-ai-blueprint-2026/) | [Orkiestracja agentów: n8n, Camunda i alternatywy](/pl/magazyn/orkiestracja-agentow-platformy/) |

---

<a href="/pl/kontakt/" target="_blank" rel="noopener noreferrer">Umów spotkanie</a> - 30 minut, w których wyjaśnimy Wasze pytania organizacyjne.

--- Rada Zakładowa a AI: konsultacja by Design ---
> Porozumienia zakładowe jako techniczne constrainty w Decision Layer. Nie przekonywać Radę Zakładową, implementować jej wymagania jako reguły.

Rady Zakładowe mają prawo do konsultacji, gdy systemy AI podejmują decyzje dotyczące pracowników. Właściwe podejście: implementować ich wymagania jako techniczne constrainty w Decision Layer, a nie jako kompromisy negocjowane na papierze.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">W skrócie - Konsultacja jako Constraint architektury</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Rady Zakładowe mają prawo do konsultacji przy wdrażaniu AI zgodnie z Ustawą o radach pracowników. Agenci AI wspierający decyzje personalne podlegają temu obowiązkowi.</li>
<li>Standardowe podejście "przekonywania" traktuje Radę Zakładową jako przeszkodę zamiast źródła wymagań - produkując nieegzekwowalne papierowe kompromisy.</li>
<li>Podejście architektoniczne: porozumienia zakładowe stają się regułami technicznymi w Decision Layer. Jeśli porozumienie mówi "bez pełnej automatyzacji ocen pracowniczych", system wymusza Human-in-the-Loop.</li>
<li>Portal Audytora daje Radzie Zakładowej weryfikowalną transparentność - każda reguła ma Control_ID, implementację techniczną i historię dowodów do wglądu.</li>
<li>Czteroetapowy proces: analiza istniejących porozumień, stworzenie katalogu wymagań, implementacja jako kontrole w Decision Layer, nadanie dostępu do Portalu Audytora.</li>
</ul>
</div>

Według Instytutu Pracy i Spraw Socjalnych (2024), w Polsce zaledwie 22% firm z radami pracowników posiada formalne porozumienia dotyczące wdrażania nowych technologii - mimo że Ustawa o radach pracowników z 2006 roku daje im prawo do informacji i konsultacji w tych sprawach.

<table>
<thead>
<tr><th>Wymaganie porozumienia zakładowego</th><th>Implementacja w Decision Layer</th><th>Weryfikacja</th></tr>
</thead>
<tbody>
<tr><td>Brak pełnej automatyzacji ocen pracowniczych</td><td>Reguła Human-in-the-Loop (wymuszona)</td><td>Logi eskalacji w Portalu Audytora</td></tr>
<tr><td>Kwartalny raport o decyzjach wspartych przez AI</td><td>Automatyczne generowanie raportu</td><td>Dashboard portalu z danymi na żywo</td></tr>
<tr><td>Zatrzymanie AI przy podejrzeniu dyskryminacji</td><td>Trigger monitoringu biasu</td><td>Log alertów i historia incydentów</td></tr>
<tr><td>Wszystkie kontrole aktywne i funkcjonalne</td><td>Control_ID na wymaganie</td><td>Historia dowodów na kontrolę</td></tr>
</tbody>
</table>

## Typowe podejście: przekonywanie Rady Zakładowej

W większości przedsiębiorstw wdrożenie AI traktowane jest jako projekt zarządzania zmianą. Rada Zakładowa jest informowana, przekonywana, włączana w proces. Cel: uzyskanie zgody na porozumienie zakładowe.

To podejście ma problem: traktuje Radę Zakładową jako przeszkodę, a nie jako źródło wymagań. Porozumienie zakładowe jest formułowane jako kompromis, zapisywane w języku prawniczym i odkładane do segregatora. Techniczna realizacja często pozostaje niejasna.

## Lepsze podejście: konsultacja jako Constraint architektury

W architekturze Gosign porozumienia zakładowe są implementowane jako techniczne constrainty w [Decision Layer](/pl/decision-layer/). Wymagania Rady Zakładowej nie są negocjowane jako kompromisy, lecz implementowane jako reguły w systemie.

Jeśli porozumienie zakładowe stanowi: „Decyzje o ocenach pracowniczych nie mogą być podejmowane w pełni automatycznie", to jest to implementowane jako reguła Human-in-the-Loop w Decision Layer. Agent fizycznie nie może obejść tej reguły.

Jeśli porozumienie zakładowe stanowi: „Rada Zakładowa otrzymuje kwartalny raport o wszystkich decyzjach personalnych wspartych przez AI", to Portal Audytora generuje ten raport automatycznie.

Jeśli porozumienie zakładowe stanowi: „W przypadku podejrzenia wzorców dyskryminacyjnych wykorzystanie AI dla danego procesu musi zostać natychmiast wstrzymane", to staje się to triggerem monitoringu bias w Decision Layer.

## Co może zobaczyć Rada Zakładowa

Rada Zakładowa otrzymuje dostęp do Portalu Audytora, z dedykowanym dostępem tylko do odczytu, ograniczonym do kontroli dla niej istotnych.

Może prześledzić: które reguły z porozumienia zakładowego są zaimplementowane jako kontrole, czy wszystkie kontrole są aktywne i funkcjonalne, jak często wyzwalane są eskalacje Human-in-the-Loop oraz czy występują anomalie w monitoringu bias.

Ta transparentność buduje zaufanie, nie przez obietnice, lecz przez weryfikowalną technikę.

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Bezpłatny eBook: AI w HR</p>
<p class="text-body text-gosign-text mb-4">Checklista EU AI Act, framework decyzyjny, perspektywa rady zakładowej i ocena gotowości - poradnik governance dla liderów HR.</p>
<a href="/pl/ebook/ai-hr-poradnik-governance/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Pobierz bezpłatnie</a>
</div>

## Praktyczne wdrożenie

**Krok 1:** Analiza istniejących porozumień zakładowych. Które regulacje dotyczą zastosowania AI bezpośrednio lub pośrednio?

**Krok 2:** Sformułowanie nowego porozumienia zakładowego dla zastosowania AI. Nie jako dokument prozatorski, lecz jako katalog wymagań z konkretnymi, technicznie implementowalnymi regułami.

**Krok 3:** Implementacja wymagań jako kontrole w Decision Layer. Każde wymaganie otrzymuje Control_ID, implementację techniczną i generator dowodów.

**Krok 4:** Rada Zakładowa otrzymuje dostęp do Portalu Audytora. Może w każdej chwili zweryfikować, czy jej wymagania są technicznie zaimplementowane.

Więcej na ten temat: [Konsultacja i AI](/pl/governance/co-determination/)

<a href="/pl/kontakt/" target="_blank" rel="noopener noreferrer">Umów spotkanie</a>. Pokażemy, jak obowiązek konsultacji jest wdrażany technicznie.

--- RAG i Document Intelligence: Jak AI rozumie Twoje dokumenty ---
> RAG udostępnia dokumenty firmowe dla AI - bez trenowania, bez wycieku danych. Plus: anonimizacja PII i redakcja umów.

## Kluczowe pytanie: Czy AI może zrozumieć nasze własne dokumenty?

„Czy możemy pozwolić AI odpowiadać na podstawie naszych dokumentów?" To pytanie pojawia się w praktycznie każdej firmie. Odpowiedź brzmi: tak, dzięki RAG (Retrieval Augmented Generation). Zasada jest prosta: Twoje dokumenty pozostają w Twojej infrastrukturze. Model językowy nie jest trenowany na Twoich danych. Zamiast tego istotne fragmenty dokumentów są przekazywane modelowi jako kontekst przy każdym zapytaniu. Model odpowiada na podstawie tych fragmentów, ze wskazaniem źródeł.

Żaden wyciek danych do podmiotów trzecich. Żadne dotrenowywanie. Żadna utrata kontroli. A mimo to odpowiedzi w języku naturalnym oparte bezpośrednio na wiedzy Twojej organizacji.

RAG jest dziś standardowym podejściem do łączenia modeli językowych z wiedzą specyficzną dla organizacji. Ten artykuł wyjaśnia, jak działa RAG, kiedy jest właściwym wyborem i dlaczego Document Intelligence wykracza daleko poza lepsze wyszukiwanie - obejmując anonimizację PII, redakcję umów i wykrywanie podpisów.

IDC (2025) szacuje, że 90% wszystkich nowych danych korporacyjnych jest nieustrukturyzowanych - dokumenty, e-maile, umowy, notatki ze spotkań. RAG jest standardową metodą udostępniania tych danych dla AI bez ponownego trenowania modelu.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">W skrócie - RAG & Document Intelligence</p>
<ul class="text-body text-gosign-text space-y-2">
<li>RAG łączy modele językowe z dokumentami firmowymi - bez trenowania, bez wycieku danych. Dokumenty pozostają w Twojej infrastrukturze.</li>
<li>Dla 90% przypadków zastosowań w firmach RAG przewyższa Fine-Tuning: niższe koszty, natychmiastowa aktualizacja przez re-indeksację, wbudowane wskazania źródeł.</li>
<li>Document Intelligence wykracza poza wyszukiwanie: anonimizacja PII, redakcja umów i wykrywanie podpisów to gotowe do produkcji funkcjonalności.</li>
<li>Jakość indeksowania determinuje jakość odpowiedzi. Strategia chunkingu, wzbogacanie metadanymi i kontrola dostępu są niezbędne.</li>
<li>RAG integruje się z portalem Enterprise AI, dzięki czemu każdy dział ma dostęp wyłącznie do swojej autoryzowanej bazy wiedzy.</li>
</ul>
</div>

## Jak działa RAG

RAG składa się z dwóch faz: indeksowania dokumentów i odpowiadania na zapytania. Przepływ można zilustrować schematem:

```
Dokumenty → Chunking → Embedding → Wektorowa baza danych
│
Zapytanie użytkownika → Query Embedding → Wyszukiwanie podobieństw
│
Istotne fragmenty + Zapytanie → LLM → Odpowiedź ze źródłem
```

**Faza 1: Indeksowanie.** Twoje dokumenty - pliki PDF, dokumenty Word, strony HTML, zeskanowane materiały - są dzielone na sensowne fragmenty (chunking). Każdy fragment jest przekształcany przez model embeddingowy w wektor matematyczny. Te wektory są przechowywane w wektorowej bazie danych. Wektor reprezentuje znaczenie fragmentu, nie jego dosłowne brzmienie. „Regulamin pracy zdalnej" i „Zasady telepracy" znajdują się blisko siebie w przestrzeni wektorowej, mimo że używają różnych słów.

**Faza 2: Zapytanie.** Gdy użytkownik zadaje pytanie, jest ono również przekształcane w wektor. Wektorowa baza danych znajduje fragmenty semantycznie najbliższe pytaniu - nie na podstawie słów kluczowych, lecz przez obliczenie podobieństwa. Te istotne fragmenty są przekazywane modelowi językowemu razem z oryginalnym pytaniem. Model generuje odpowiedź na podstawie tych konkretnych źródeł.

Rezultat: odpowiedź w języku naturalnym oparta na Twoich dokumentach, z odniesieniami do fragmentów źródłowych, z których pochodzi informacja.

Decydująca jest jakość indeksowania. Zbyt duże chunki rozmywają trafność. Zbyt małe chunki tracą kontekst. Strategia chunkingu - rozmiar, nakładanie się, wzbogacanie metadanymi - w dużej mierze determinuje jakość odpowiedzi. Dobry potok RAG to nie sama technologia, lecz jej konfiguracja pod kątem Twojego specyficznego krajobrazu dokumentów.

## RAG vs. Fine-Tuning vs. Prompting

RAG nie jest jedynym sposobem przekazania modelowi wiedzy dziedzinowej. Istnieją trzy podstawowe podejścia, różniące się nakładem pracy, kosztami i przydatnością:

| Podejście | Co się dzieje | Kiedy stosować | Koszt | Aktualność |
|---|---|---|---|---|
| Prompting | Kontekst podawany bezpośrednio w prompcie | Małe zbiory danych | Niski | Natychmiast |
| RAG | Istotne dokumenty znajdowane automatycznie | Duże bazy wiedzy | Średni | Re-indeksacja |
| Fine-Tuning | Model dotrenowywany | Język specjalistyczny/domena | Wysoki | Tylko przez re-trening |

**Prompting** działa, gdy istotny kontekst mieści się w oknie kontekstowym modelu - zazwyczaj kilkadziesiąt stron. Dla pojedynczego porozumienia zakładowego to wystarczające. Dla bazy wiedzy z setkami dokumentów - nie.

**RAG** skaluje się na duże zbiory dokumentów. Wektorowa baza danych może zawierać setki tysięcy fragmentów. Przy każdym zapytaniu znajdowane i przekazywane modelowi są tylko istotne fragmenty. Dokumenty można aktualizować w dowolnym momencie - wystarczy re-indeksacja. Model nie musi być ponownie trenowany.

**Fine-Tuning** zmienia wagi samego modelu. Jest zasadny, gdy model musi nauczyć się zupełnie nowego słownictwa branżowego - np. terminologii medycznej lub własnej nomenklatury - albo gdy wymagany jest bardzo specyficzny format odpowiedzi. Fine-Tuning jest kosztowny, pracochłonny i wymaga ponownego trenowania przy każdej aktualizacji.

Dla 90% przypadków zastosowań w firmach RAG jest właściwym podejściem. Kombinacja dużych baz wiedzy, częstych aktualizacji i potrzeby wskazywania źródeł czyni RAG standardem dla wiedzy korporacyjnej.

## Document Intelligence: więcej niż wyszukiwanie

RAG odpowiada na pytania na podstawie dokumentów. Document Intelligence idzie dalej: obejmuje wszystkie metody, dzięki którym AI nie tylko czyta dokumenty, ale je rozumie, klasyfikuje i przetwarza - włącznie z ochroną informacji wrażliwych.

Trzy najważniejsze obszary zastosowań w kontekście korporacyjnym: anonimizacja PII, redakcja umów i wykrywanie podpisów.

### Anonimizacja PII: pseudonimizacja z pełnym obiegiem

Dane osobowe (PII, Personally Identifiable Information) w wielu przypadkach nie mogą być przekazywane do modelu językowego. Wynagrodzenia, prawdziwe nazwiska, numery pracownicze, dane zdrowotne. RODO i wewnętrzne polityki ochrony danych wyznaczają jasne granice.

Rozwiązaniem jest pseudonimizacja z pełnym obiegiem (roundtrip). Konkretny przykład:

**Dokument oryginalny:**
„Jan Kowalski, Dział Finansów, wynagrodzenie 18 000 zł, przystępuje do porozumienia zakładowego dotyczącego elastycznego czasu pracy."

**Po pseudonimizacji (dane wejściowe dla modelu):**
„Osoba_A, Dział_X, Wynagrodzenie_Y, przystępuje do porozumienia zakładowego dotyczącego elastycznego czasu pracy."

Model językowy przetwarza zapytanie z pseudonimizowanymi danymi. W żadnym momencie nie widzi prawdziwego nazwiska, działu ani wynagrodzenia.

**Po re-identyfikacji (dane wyjściowe dla użytkownika):**
Symbole zastępcze w wyniku są zastępowane oryginalnymi danymi. Użytkownik widzi pełną odpowiedź. Model jej nigdy nie widział.

Ten obieg odbywa się automatycznie. Dla użytkownika proces jest przezroczysty. Dla modelu dane są w każdym momencie niedostępne. Dla [infrastruktury](/pl/uslugi/infrastruktura/) oznacza to: warstwa pseudonimizacji znajduje się między użytkownikiem a modelem i jest wymuszona technicznie - nie opcjonalnie.

Anonimizacja PII jest szczególnie istotna dla zastosowań HR, gdzie akta osobowe, listy płac czy oceny pracownicze mają być przetwarzane z wykorzystaniem AI. Bez anonimizacji takie zastosowania nie są zgodne z RODO w UE.

### Redakcja umów (Redaction)

Redakcja umów wykracza poza pseudonimizację. Podczas gdy pseudonimizacja zastępuje dane i przywraca je na końcu, redakcja fizycznie usuwa treść z dokumentu - nieodwracalnie dla danego odbiorcy.

Przypadek użycia: różne działy potrzebują różnych widoków tego samego kontraktu. Dział prawny widzi pełny kontrakt. Dział zakupów widzi wersję bez klauzul odpowiedzialności. Zarząd widzi podsumowanie bez szczegółów operacyjnych.

Redakcja działa na podstawie reguł. Dla każdej kategorii dokumentu i każdej grupy odbiorców zdefiniowane jest, które sekcje są widoczne, a które zredagowane. Reguły są konfigurowane i wersjonowane w [Decision Layer](/pl/decision-layer/) - nie stosowane ręcznie.

Rezultat: każda rola widzi dokładnie te informacje, które są dla niej istotne i autoryzowane. Żadna ręczna redakcja. Żadne pominięte fragmenty. Żadne wersje przypadkowo przesłane w całości.

### Wykrywanie podpisów

Archiwa umów w firmach często zawierają tysiące dokumentów. Pytanie, czy dany kontrakt jest w pełni podpisany, wymaga dziś często ręcznego przeglądania strona po stronie. Przy setkach umów jest to niepraktyczne.

Document Intelligence rozwiązuje ten problem poprzez automatyczne wykrywanie podpisów. System sprawdza zeskanowane kontrakty pod kątem obecności podpisów w wyznaczonych miejscach. Brakujące podpisy są automatycznie oznaczane. Rezultat: przegląd wszystkich umów w archiwum, które nie zostały jeszcze w pełni podpisane - w minutach zamiast tygodni.

Zastosowanie wykracza poza samą detekcję. W połączeniu z potokiem RAG system może również odpowiadać na pytania takie jak: „Które umowy ramowe z okresem obowiązywania powyżej 3 lat zostały przedłużone w ostatnim kwartale bez podpisu zarządu?"

## Przykład z praktyki: Asystent porozumień zakładowych

Konkretny scenariusz z praktyki HR. Dział kadr średniej wielkości firmy zarządza ponad 100 aktywnymi porozumieniami zakładowymi: czas pracy, praca zdalna, podróże służbowe, szkolenia, programy emerytalne, zarządzanie reintegracją, ochrona danych, korzystanie z IT i wiele innych. Każde porozumienie ma aneksy, załączniki i odniesienia do innych porozumień.

Gdy pracownik kadr musi odpowiedzieć na pytanie: „Jaka regulacja obowiązuje w zakresie pracy zdalnej dla pracowników na część etatu w produkcji?", oznacza to dziś: znaleźć właściwe porozumienie zakładowe, zlokalizować odpowiedni fragment, sprawdzić czy istnieje aneks, porównać z układem zbiorowym, uwzględnić regulacje specyficzne dla lokalizacji. Rezultat: 30 do 45 minut poszukiwań. W razie wątpliwości zapytanie do działu prawnego. Kolejne dni oczekiwania.

Z asystentem porozumień zakładowych opartym na RAG: wszystkie porozumienia zakładowe są indeksowane, wraz z aneksami, załącznikami i odniesieniami krzyżowymi. Pracownik kadr zadaje pytanie w języku naturalnym. System znajduje istotne fragmenty z właściwych dokumentów, uwzględnia aneks z marca 2025, wskazuje na regulację specjalną dla pracowników produkcji i dostarcza odpowiedź w 10 sekund. Ze wskazaniem źródła. Z wersją regulacji.

To nie jest scenariusz teoretyczny. To standardowy przypadek użycia, od którego firmy zaczynają budowanie pierwszego potoku RAG. Nakład pracy jest umiarkowany: dostarczyć dokumenty, skonfigurować strategię chunkingu, zdefiniować prawa dostępu, przetestować. [Infrastruktura](/pl/uslugi/infrastruktura/) - wektorowa baza danych, model embeddingowy, model językowy, potok retrieval - jest budowana raz i dostępna dla kolejnych zastosowań.

## Zapewnienie jakości: Dlaczego wyniki RAG są tak dobre, jak indeksowanie

RAG nie działa sam. Najczęstsze źródła błędów w praktyce:

**Zła strategia chunkingu.** Zbyt duże chunki (całe rozdziały) dostarczają zbyt dużo nieistotnego kontekstu. Zbyt małe chunki (pojedyncze akapity) tracą spójność. Właściwy rozmiar chunka zależy od typu dokumentu - specyfikacja techniczna wymaga innego chunkingu niż porozumienie zakładowe.

**Brakujące metadane.** Bez metadanych (typ dokumentu, data obowiązywania, wersja, zakres stosowania) potok retrieval nie jest w stanie rozróżnić aktualnej i nieaktualnej regulacji. Wzbogacanie metadanymi podczas indeksowania nie jest opcjonalne - jest konieczne.

**Brak kontroli dostępu.** W środowisku korporacyjnym nie każdy użytkownik powinien mieć dostęp do wszystkich dokumentów. Potok RAG musi odzwierciedlać istniejącą strukturę uprawnień: dokumenty HR tylko dla HR, dane finansowe tylko dla działu finansów, komunikacja zarządu tylko dla uprawnionych osób.

**Brak weryfikacji źródeł.** RAG dostarcza odniesienia do źródeł. Ale czy są poprawne? Zapewnienie jakości - wyrywkowa kontrola odniesień, mechanizm zwrotny dla użytkowników, regularna ewaluacja - jest niezbędne, by wykrywać halucynacje i doskonalić potok.

To zapewnienie jakości jest częścią bieżącej eksploatacji, nie jednorazowego uruchomienia. Dokumenty się zmieniają. Nowe dochodzą. Stare tracą ważność. Potok RAG musi ewoluować - poprzez regularną re-indeksację, aktualizację metadanych i informacje zwrotne od użytkowników.

## Integracja z portalem Enterprise AI

RAG nie jest systemem izolowanym. W przemyślanej architekturze potok RAG jest zintegrowany z [portalem Enterprise AI](/pl/magazyn/enterprise-ai-chat-interface/). Pracownicy zadają pytania przez zunifikowany interfejs - ten sam, przez który korzystają z [agentów AI](/pl/uslugi/ai-agents/).

Portal zarządza prawami dostępu: kto może odpytywać którą bazę wiedzy? Pracownicy HR widzą asystenta porozumień zakładowych. Dział prawny widzi asystenta kontraktowego. Dział zakupów widzi asystenta wytycznych dla dostawców. Każdy widzi tylko to, do czego jest uprawniony.

Połączenie RAG i agentów AI otwiera rozszerzone możliwości: agent może nie tylko odpowiedzieć na pytanie, ale na podstawie wyników RAG uruchomić działanie - na przykład wygenerować ostrzeżenie o terminie, gdy kontrakt dobiega końca, lub stworzyć listę kontrolną, gdy nowe porozumienie zakładowe wchodzi w życie.

---

**Enterprise AI-Infrastruktur Blueprint 2026 - Seria artykułów**

| ← Poprzedni | Przegląd | Następny → |
|:---|:---:|---:|
| [Portal Enterprise AI: Cztery interfejsy Open Source w porównaniu](/pl/magazyn/enterprise-ai-chat-interface/) | [Przegląd](/pl/magazyn/infrastruktura-ai-blueprint-2026/) | [Od chatbotów do agentów AI: MCP, A2A i systemy Multi-Agent](/pl/magazyn/agenci-ai-enterprise-przewodnik/) |

*Wszystkie artykuły w tej serii: [Enterprise AI-Infrastruktur Blueprint 2026](/pl/magazyn/infrastruktura-ai-blueprint-2026/)*

---

**Chcesz udostępnić wiedzę firmową dla AI?** Gosign buduje potoki RAG i rozwiązania Document Intelligence dla klientów korporacyjnych - niezależnie od modelu, z anonimizacją PII i pełną kontrolą dostępu.

<a href="/pl/kontakt/" target="_blank" rel="noopener noreferrer">Umów spotkanie</a>. 30 minut, w których określimy, które dokumenty powinny stać się dostępne dla AI w pierwszej kolejności.

--- Jak mierzyć ROI z inwestycji w AI ---
> Jak CFO oceniają ROI enterprise AI. Koszty procesów, wskaźniki błędów i pracochłonność audytu jako mierzalne KPI zamiast mglistych obietnic.

## Problem z ROI z AI

Większość kalkulacji ROI dla inwestycji w AI nie wytrzymuje weryfikacji z powodu nieostrości. "30% wyższa produktywność" brzmi przekonująco w prezentacji, ale nie da się tego udowodnić, gdy nikt nie zdefiniował, co "wyższa produktywność" oznacza w konkretnym procesie.

CFO znają ten problem. Widzą projekty pilotażowe, które dostarczają imponujące dema, ale nie dają obronnych liczb dla zarządu. Widzą budżety AI zatwierdzane jako projekty innowacyjne bez uzasadnionego business case.

Nie dlatego, że AI nie ma ROI. Ale dlatego, że AI jest mierzony w niewłaściwym punkcie.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">W skrócie - Pomiar ROI z enterprise AI</p>
<ul class="text-body text-gosign-text space-y-2">
<li>ROI z AI powstaje przez efektywność procesową, nie indywidualną produktywność. Jeden zautomatyzowany proces dokumentowy oszczędza ponad 200 godzin miesięcznie.</li>
<li>Pięć KPI czyni ROI mierzalnym: koszt procesu na sprawę, wskaźnik błędów, czas realizacji, pracochłonność audytu i koszty skalowania.</li>
<li>Według McKinsey (2024) firmy stosujące AI w operacjach finansowych osiągają 30 do 50% redukcji kosztów w procesach dokumentowych w pierwszym roku.</li>
<li>Decision Layer oddziela analizę AI od decyzji biznesowej i tworzy automatyczny Audit Trail - wskaźniki ROI powstają jako produkt uboczny.</li>
<li>Zacznij od jednego procesu, jednego agenta i zmierz KPI po 4 do 6 tygodniach. Różnica to ROI.</li>
</ul>
</div>

## Gdzie naprawdę powstaje ROI

ROI enterprise AI nie powstaje przy produktywności poszczególnych pracowników. Powstaje przy efektywności procesowej całych przebiegów.

Przykład: w organizacji HR Shared Services zespół 8 pracowników przetwarza miesięcznie 1200 zwolnień lekarskich. Każda sprawa zajmuje średnio 12 minut: otworzyć dokument, zweryfikować dane, obliczyć terminy, zaksięgować w systemie ERP, poinformować przełożonego. To 240 godzin miesięcznie na jeden typ dokumentu.

[Document Agent](/pl/uslugi/ai-agents/) redukuje ręczny czas przetwarzania na sprawę do poniżej 2 minut - w przypadkach standardowych do zera, ponieważ agent automatyzuje cały proces aż do etapu zatwierdzenia. Pracownicy sprawdzają tylko wyjątki i eskalacje.

To nie mglista obietnica produktywności. To mierzalna redukcja z 240 do 40 godzin miesięcznie - dla jednego procesu. Pomnożone przez 5-10 procesów powstaje business case, który rozumie każdy CFO.


## Właściwe KPI

Pięć KPI czyni ROI agentów AI mierzalnym i komunikowalnym wewnętrznie.

Po pierwsze: koszt procesu na sprawę. Ile kosztuje przetworzenie zwolnienia lekarskiego, faktury, umowy dzisiaj? Ile kosztuje po wdrożeniu agenta? Różnica to bezpośredni ROI.

Po drugie: wskaźnik błędów. Procesy manualne mają typowe wskaźniki błędów 2-5%. Agent oparty na regułach popełnia błędy tylko przy błędach w regułach - a te są wersjonowane i korygowalne. Każdy uniknięty błąd ma wyliczalną wartość kosztów następczych.

Po trzecie: czas realizacji. Ile trwa sprawa od wpłynięcia do zakończenia? Agenci redukują czas przestoju do niemal zera - sprawa jest przetwarzana natychmiast po wpłynięciu, a nie gdy pracownik ją podejmie.

Po czwarte: pracochłonność audytu. W regulowanych procesach (rozliczenia ZUS, kontrole skarbowe, audyty zgodne z Ustawą o rachunkowości) znaczny wysiłek generuje ręczna dokumentacja i dowodzenie. Agent z [Decision Layer](/pl/decision-layer/) dokumentuje automatycznie: jaką regułę zastosowano, jakie dane były dostępne, jaką decyzję podjęto, kto zatwierdził. Audit Trail powstaje jako produkt uboczny procesu.

Po piąte: koszty skalowania. Ile kosztuje zwiększenie obecnego wolumenu o 50%? Przy procesach manualnych: więcej personelu. Przy infrastrukturze agentowej: więcej mocy obliczeniowej. Krzywe kosztów rozbiegają się radykalnie.

<div class="overflow-x-auto">

| KPI | Proces ręczny | Z agentem AI | Metoda pomiaru |
|-----|--------------|-------------|---------------|
| Koszt procesu na sprawę | 15 - 60 USD | 2 - 8 USD | Porównanie przed/po |
| Wskaźnik błędów | 2 - 5% | < 0,5% | Audyt próbek |
| Czas realizacji | 1 - 5 dni | Minuty | Delta znaczników czasu |
| Pracochłonność audytu | 40 - 80 h/miesiąc | < 5 h/miesiąc | Rejestracja godzin |
| Skalowanie (+50% wolumenu) | +50% personelu | +10% mocy obliczeniowej | Śledzenie kosztów |

</div>

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Darmowy eBook: AI w Finance</p>
<p class="text-body text-gosign-text mb-4">Compliance, biegły rewident i Decision Layer - poradnik governance dla liderów finansów.</p>
<a href="/pl/ebook/ai-finance-poradnik-governance/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Pobierz za darmo</a>
</div>

## Decision Layer jako dźwignia ROI

[Decision Layer](/pl/decision-layer/) to punkt, w którym ROI staje się mierzalny. Oddziela analizę AI od decyzji biznesowej i dokumentuje obie jako audytowalne akty.

Oznacza to: dla każdej sprawy istnieje kompletny zestaw danych - dane wejściowe, zastosowana reguła, rekomendacja agenta, decyzja człowieka, znacznik czasu. Z tych zestawów danych wskaźniki ROI można automatycznie wyprowadzać, bez ręcznego zbierania.

Wynika z tego również: ROI poprawia się z czasem. Ponieważ korekty reguł są wersjonowane, a ich wpływ na wskaźniki błędów i czasy realizacji jest mierzalny, powstaje ciągły cykl optymalizacji - udokumentowany i przejrzysty.


## Jak firmy powinny zacząć

Nie od strategii AI. Lecz od konkretnego procesu.

Zidentyfikować proces o najwyższym wolumenie i najwyższych kosztach manualnych. Zmierzyć stan wyjściowy: obecne koszty procesu, wskaźnik błędów, czas realizacji. Zbudować na to agenta i po 4-6 tygodniach zmierzyć te same KPI.

Różnica to ROI. Żadna prezentacja, żadne szacunki - twarde liczby z produktywnego procesu.

W Gosign budujemy [agentów AI](/pl/uslugi/ai-agents/) dokładnie z takim podejściem: jeden proces, jeden agent, mierzalne KPI po 4-6 tygodniach. [Decision Layer](/pl/decision-layer/) automatycznie dostarcza bazę danych dla business case.

--- Open Source AI na własnym hostingu 2026 ---
> Open-source LLM na własnym hostingu w 2026: Mistral, gpt-oss, DeepSeek, Llama 4. Próg sprzętowy, TCO, dostawcy GPU UE, macierz decyzji per obciążenie.

Rynek modeli dał polskim zakupom enterprise wybór, którego wcześniej nie miały. Modele open-weight dorównują własnościowym w większości obciążeń enterprise. Trzy frontowe modele open-source wyszły pod Apache 2.0 tylko w samym 2025. Polscy i unijni dostawcy hostingu GPU oferują pojemność H100 w przewidywalnych stawkach godzinowych z centrów danych w Warszawie, Poznaniu, Paryżu i Frankfurcie. Schrems II + CLOUD Act sprawiają, że self-hosting jest najczystszą architekturą pod kątem ekspozycji na obcego providera. Alternatywnie SCC (Klauzule Standardowe Komisji 2021/914) + Tabela Suplementarna (Transfer Impact Assessment zgodnie z Zaleceniami EDPB 01/2020) pozostają prawnie ważną ścieżką, wymagają jednak rygorystycznej oceny równoważności ochrony i dodatkowych środków technicznych.

A mimo to rozmowa w zakupach nadal traktuje "AI open-source na własnym hostingu" jako jeden produkt. To nim nie jest. To decyzja stackowa z czterema wiarygodnymi modelami, trzema wzorcami wdrożenia i realnym problemem matematycznym total cost of ownership. Ten artykuł jest szczegółowym uzupełnieniem [Kiedy Mistral, kiedy Claude Opus? Routing decyzji dla agentów AI w polskim enterprise 2026](/pl/magazyn/modele-ai-porownanie-2026/) - jeśli zdecydowałeś się na self-hosting, oto jak selekcja modeli rozgrywa się w praktyce.

<div class="not-prose my-12 border border-gosign-border bg-gosign-light rounded-card p-6 lg:p-8">
<p class="text-h3 font-bold text-gosign-dark mb-3">W skrócie - AI open-source na własnym hostingu dla polskiego enterprise 2026</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Pięć wiarygodnych modeli self-hostable w 2026: Mistral Small 3.2 (Apache 2.0, 24B, pojedynczy GPU konsumencki), gpt-oss-120b (Apache 2.0, MoE, pojedynczy H100), DeepSeek V4-Flash (MIT, 284B/13B aktywnych, preview kwiecień 2026), DeepSeek V4-Pro (MIT, 1.6T/49B aktywnych, preview, klaster), Llama 4 Scout (Meta License, kontekst 10M).</li>
<li>Mistral Small 3.2 wygrywa rolę konia roboczego, bo działa na sprzęcie konsumenckim (pojedynczy RTX 4090), przychodzi z treningiem wielojęzycznym i ma natywną zdolność wizualną dla obciążeń dokumentowych.</li>
<li>DeepSeek V4-Pro (preview, 24 kwietnia 2026) zbliża się do wydajności zamkniętych modeli frontowych pod licencją MIT, ale wymaga klastra wielo-GPU - realny self-hosting dla większości firm zaczyna się od V4-Flash.</li>
<li>Hosting GPU w UE nie jest już wąskim gardłem: Atman i Polcom w Polsce, Scaleway oferuje H100 SXM za ~3,50 EUR/h, OVHcloud ma poziom sovereign, Hetzner dedykowane serwery RTX, IONOS i T-Systems obsługują branże regulowane.</li>
<li>Przecięcie TCO z API chmurowego do self-hosted: zwykle ok. 50-100 mln tokenów miesięcznie sustained. Poniżej tego API w chmurze UE wygrywa. Powyżej dedykowany sprzęt amortyzuje się w 12-18 miesięcy.</li>
<li>Architektura jest wielomodelowa, nie jednomodelowa: Mistral Small do wolumenu, gpt-oss-120b albo DeepSeek V4-Flash do ciężkiego rozumowania on-prem, V4-Pro albo R1 jako specjalista matematyki i logiki, Llama 4 Scout do ultra-długiego kontekstu. Routing decyduje, który model obsługuje którą decyzję.</li>
</ul>
</div>

## Zdecydowałeś się na self-hosting - pytanie modelowe zaczyna się tutaj

Wybór self-hostingu stacku LLM rzadko jest decyzją modelową. To decyzja compliance: dane sklasyfikowane powyżej pewnego progu nie mogą opuścić sieci firmy. To decyzja architektoniczna: warstwa inferencji musi być kontrolowaną zależnością, nie zewnętrznym API. To decyzja zakupowa: capex na sprzęt vs opex na hostowane instancje GPU.

Gdy ta decyzja jest podjęta, otwiera się pytanie modelowe. Który model open-source na którym progu sprzętowym dla którego miksu obciążeń? Pięć modeli ma wiarygodną gotowość produkcyjną w II kwartale 2026: Mistral Small 3.2, gpt-oss-120b, DeepSeek V4-Flash, DeepSeek V4-Pro (preview) i Llama 4 Scout. DeepSeek R1 ze stycznia 2025 wciąż jest gotowy produkcyjnie, ale w dużej mierze zastąpiony linią V4 dla nowych wdrożeń. Każdy ma inną krzywą koszt-jakość i inny profil operacyjny.

Ten artykuł pomija dyskusję rankingową. Wyniki benchmarków zbliżają się na tyle, że dopasowanie do obciążenia waży więcej niż nominalne punkty na MMLU czy HumanEval. Pytanie brzmi: który model przetrwa 18 miesięcy w twoim stacku, który zarobi na swój sprzęt i która kombinacja produkuje audit trail, którego wymaga EU AI Act.

## Wiarygodne modele self-hosted obok siebie

| Model | Parametry / Architektura | Licencja | Sprzęt CAPEX / OPEX hostowany | Kluczowa mocna strona | Kluczowa słabość |
|---|---|---|---|---|---|
| Mistral Small 3.2 | 24B dense, GQA (32Q/8KV) | Apache 2.0 | 1x RTX 4090 ~1 500 EUR (kwantyzacja) lub 1x H100 80GB ~30k EUR / OPEX ~1 500-2 500 EUR/miesiąc | Wielojęzyczny, wizja, szybki (~150 tok/s na konsumenckim GPU), volumenowy | Nie najwyższa półka rozumowania |
| gpt-oss-120b | 117B total / 5,1B aktywnych (MoE) | Apache 2.0 | 1x H100/A100 80GB ~30k EUR / OPEX ~1 200-2 500 EUR/miesiąc | Rozumowanie na poziomie o4-mini, MoE-efektywny | Brak wizji, sprzęt klasy data center |
| DeepSeek V4-Flash *(preview, kw. 2026)* | 284B total / 13B aktywnych (MoE), kontekst 1M | MIT | 1-4x H100 ~30-120k EUR CAPEX / OPEX ~1 500-5 000 EUR/miesiąc | Rozumowanie klasy frontowej przy umiarkowanym koszcie sprzętu, natywny multimodal, zoptymalizowany pod agentów | Status preview - benchmarki potwierdzić przed produkcją |
| DeepSeek V4-Pro *(preview, kw. 2026)* | 1,6T total / 49B aktywnych (MoE), kontekst 1M | MIT | 8x H100 ~240 000 EUR CAPEX / OPEX ~10-12k EUR/miesiąc hostowany | Zbliża się do GPT-5.5 i Gemini 3.1 Pro pod otwartą licencją, agent-tool optimized (Claude Code, OpenClaw) | CAPEX realny dla dużych korporacji; MSP via API/hosted |
| DeepSeek R1 *(sty 2025, mature)* | 671B total / 37B aktywnych (MoE) | MIT | 4-8x H100 ~120-240k EUR CAPEX / OPEX ~5-10k EUR/miesiąc | Dojrzały specjalista matematyki/logiki, szerokie wsparcie frameworków | W dużej mierze zastąpiony przez V4-Flash w nowych wdrożeniach |
| Llama 4 Scout | 17B aktywnych (MoE) | Meta Llama Community License | 1x H100 ~30k EUR / OPEX ~1 500 EUR/miesiąc | Kontekst 10 mln tokenów | Ograniczenie licencyjne przy >700M MAU; wymaga przeglądu licencji |

Trzy doprecyzowania mają znaczenie.

**Próg sprzętowy Mistral Small 3.2.** Oficjalna dokumentacja Mistral wymienia ~55 GB GPU RAM dla inferencji bf16/fp16, co plasuje go na H100 albo A100 80GB w produkcji. Z kwantyzacją 4-bit (GPTQ, AWQ) działa na pojedynczym 24 GB RTX 4090 przy niewielkim koszcie jakości. Dla wdrożeń pilotażowych albo single-tenant inferencji ścieżka RTX 4090 jest realna. Dla produkcji multi-tenant ze współbieżnymi requestami ścieżka H100 jest poprawnym sizingiem.

**Status preview DeepSeek V4.** DeepSeek-V4-Pro i V4-Flash wystartowały jako preview 24 kwietnia 2026 pod licencją MIT, oba z kontekstem 1 mln tokenów dzięki nowej architekturze Hybrid Attention (Compressed Sparse Attention + Heavily Compressed Attention). W ustawieniu kontekstu 1M tokenów V4-Pro wymaga raportowo tylko 27 procent FLOPs inferencji pojedynczego tokenu i 10 procent KV cache w porównaniu z V3.2 - znaczące zyski efektywności dla obciążeń długokontekstowych. Oba warianty są zoptymalizowane pod tooling agentów (integracja Claude Code, OpenClaw). Jednak: preview oznacza, że deklaracje benchmarków nie są jeszcze niezależnie zweryfikowane na skalę. Dla decyzji produkcyjnych w branżach regulowanych czekaj na general-availability albo uruchom własne reprezentatywne benchmarki przed commitmentem.

**V4-Pro: licencja MIT nie jest barierą - rozmiar przedsiębiorstwa jest.** Pełna waga modelu V4-Pro jest swobodnie dostępna na Hugging Face pod licencją MIT - każde przedsiębiorstwo może legalnie pobrać i uruchomić model. Pytanie "czy V4-Pro jest dla mojej firmy" nie dotyczy licencji, tylko ekonomii infrastruktury. Klaster 8x H100 to ok. 240 000 EUR CAPEX (zakup) albo ok. 10-12 000 EUR OPEX miesięcznie (hostowany u Scaleway, OVHcloud, T-Systems). Dla korporacji WIG20, większego gospodarstwa regulowanego (banki, ubezpieczyciele, energetyka) i większych firm Mittelstand (>2000 prac.) ten próg mieści się w standardowych liniach budżetowych infrastruktury IT - V4-Pro on-prem jest realny i atrakcyjny pod kątem suwerenności i kontroli kosztów per token przy sustained workload. Dla MSP poniżej 500 pracowników racjonalna ścieżka prowadzi przez API albo hostowane warianty: DeepSeek API bezpośrednio od dostawcy, Together.ai, Fireworks i inni hosting-providerzy serwują tę samą wagę modelu w modelu pay-per-token. Identyczna jakość rozumowania, bez CAPEX, bez utrzymania klastra. Pułapka komunikacyjna, której należy unikać: "V4-Pro to model dla korporacji" jest myląca - poprawne sformułowanie brzmi "V4-Pro on-prem to wybór dla korporacji, V4-Pro przez API to wybór dla każdej firmy".

**Przegląd licencji dla Llama 4 Scout.** Meta Llama Community License pozwala na użycie komercyjne, ale zawiera dwa ograniczenia, które zakupy enterprise powinny przejrzeć: próg 700-milionów-MAU, powyżej którego wymagana jest osobna licencja Meta, oraz ograniczenie używania wyjść modelu do trenowania konkurencyjnych modeli. Dla większości firm oba są w praktyce nieistotne, ale notatka zakupowa powinna być wyraźna.

## TCO: kiedy self-hosted pokonuje API w chmurze?

Ekonomia odwraca się przy progu wolumenu tokenów. Poniżej niego hostowane API wygrywają, bo dominuje czas bezczynności sprzętu. Powyżej dedykowane GPU wygrywają, bo inkrementalny koszt tokenu zbliża się do kosztu prądu plus amortyzacji.

Reprezentatywna kalkulacja dla Mistral Small 3.2 w hostingu UE:

| Element kosztu | Wartość (hosting UE) |
|---|---|
| Instancja H100 80GB, provider UE (klasy Scaleway) | ~2 500 EUR/miesiąc dedykowane, albo ~3,50 EUR/h on-demand |
| Przepustowość Mistral Small 3.2 (pojedynczy H100) | ~150 tokenów/s sustained, ~390M tokenów/miesiąc przy 100% utilization |
| Efektywny koszt na 1M tokenów przy 60% utilization | ~10-12 EUR na 1M tokenów |
| Mistral La Plateforme API odpowiednik (Mistral Small przez API) | ~0,40 USD za 1M tokenów wejściowych; volume-dependent |
| Claude Sonnet 4.6 API odpowiednik | ~3 USD za 1M tokenów wejściowych; ~15 USD wyjściowych |
| Claude Opus 4.7 API odpowiednik | ~5 USD za 1M tokenów wejściowych; ~25 USD wyjściowych |

Przecięcie dla Mistral Small ląduje między 50 a 100 milionów tokenów miesięcznie sustained, w zależności czy obciążenie jest input-heavy czy output-heavy. Pipeline enterprise 24/7 z 5-10 worker node'ami zwykle przekracza ten próg w pierwszym kwartale.

Dla gpt-oss-120b matematyka jest podobna, ale startuje wyżej: pojedynczy H100 wspiera niższą przepustowość niż Mistral Small przy tym samym koszcie sprzętu, więc amortyzacja per token wynosi grubsza 2x Mistral Small. Przecięcie vs Claude Opus 4.7 plasuje się przy 30-50 mln tokenów miesięcznie - dokładnie w zakresie, w którym lądują obciążenia ciężkiego rozumowania w systemach AI enterprise.

Architektura DeepSeek V4-Pro 1,6T/49B aktywnych to sprzęt klasy hyperscaler. Realny self-hosting startuje od V4-Flash (284B/13B aktywnych), który mieści się na 1-2 H100 z kwantyzacją albo 4 H100 w pełnej precyzji. TCO self-hosted dla V4-Flash jest uzasadnione, gdy rozumowanie klasy frontowej jest sustained workload przy klasyfikacjach danych krytycznych dla suwerenności; dla okazjonalnego rozumowania API V4-Flash albo Mistral La Plateforme są tańsze. V4-Pro on-prem jest realny tylko dla firm klasy hyperscaler (usługi finansowe z infrastrukturą HFT, duże administracje rządowe i obronne). Reszta używa V4-Pro przez API albo hostowany wariant.

Te liczby opierają się na publicznym cenniku hostingowym z Scaleway i OVHcloud oraz publicznych danych przepustowości modeli. Są ilustracyjne, nie kontraktowe.

<figure class="not-prose my-12">
<svg viewBox="0 0 800 480" xmlns="http://www.w3.org/2000/svg" role="img" aria-labelledby="tco-title-pl tco-desc-pl" class="w-full h-auto max-w-3xl mx-auto">
<title id="tco-title-pl">Punkt przecięcia TCO: self-hosted vs API chmurowe według miesięcznego wolumenu tokenów (maj 2026)</title>
<desc id="tco-desc-pl">Porównanie kosztów: miesięczne wydatki USD na osi Y (skala log 100 do 100 000 USD) względem miesięcznego wolumenu tokenów na osi X (skala log 1M do 10B tokenów). Cztery krzywe: Claude Opus 4.7 API 15 USD na 1M tokenów (liniowa), Mistral La Plateforme API 0,40 USD na 1M tokenów (liniowa), Mistral Small 3.2 self-host pojedyncza H100 ~2700 USD/miesiąc plus marginalna energia, gpt-oss-120b self-host pojedyncza H100 ~3200 USD/miesiąc. Punkty przecięcia: Mistral Small 3.2 self-hosted bije Claude Opus 4.7 API przy około 180 milionach tokenów miesięcznie. Poniżej 50M tokenów/miesiąc dominuje ekonomia chmurowych API. Powyżej 500M tokenów/miesiąc dominuje self-host niezależnie od modelu.</desc>
<defs><style>
.axis-line-pl { stroke: #1a2e4d; stroke-width: 1.5; }
.grid-line-pl { stroke: #d4d0cb; stroke-width: 0.5; stroke-dasharray: 2 3; }
.axis-label-pl { font-family: -apple-system, system-ui, sans-serif; font-size: 11px; fill: #4a5568; }
.title-text-pl { font-family: -apple-system, system-ui, sans-serif; font-size: 13px; fill: #1a2e4d; font-weight: 700; }
.legend-text-pl { font-family: -apple-system, system-ui, sans-serif; font-size: 11px; fill: #1a2e4d; font-weight: 500; }
.annotation-pl { font-family: -apple-system, system-ui, sans-serif; font-size: 10px; fill: #1a2e4d; font-style: italic; }
.crossover-marker-pl { fill: #fcd34d; stroke: #b8941f; stroke-width: 1.5; }
</style></defs>
<text x="400" y="25" class="title-text-pl" text-anchor="middle">Koszty miesięczne (USD, skala log)</text>
<line x1="80" y1="380" x2="740" y2="380" class="grid-line-pl"/><line x1="80" y1="300" x2="740" y2="300" class="grid-line-pl"/><line x1="80" y1="220" x2="740" y2="220" class="grid-line-pl"/><line x1="80" y1="140" x2="740" y2="140" class="grid-line-pl"/><line x1="80" y1="60" x2="740" y2="60" class="grid-line-pl"/>
<line x1="212" y1="60" x2="212" y2="380" class="grid-line-pl"/><line x1="344" y1="60" x2="344" y2="380" class="grid-line-pl"/><line x1="476" y1="60" x2="476" y2="380" class="grid-line-pl"/><line x1="608" y1="60" x2="608" y2="380" class="grid-line-pl"/>
<text x="72" y="384" class="axis-label-pl" text-anchor="end">$100</text>
<text x="72" y="304" class="axis-label-pl" text-anchor="end">$1 000</text>
<text x="72" y="224" class="axis-label-pl" text-anchor="end">$10 000</text>
<text x="72" y="144" class="axis-label-pl" text-anchor="end">$100 000</text>
<text x="72" y="64" class="axis-label-pl" text-anchor="end">$1 000 000</text>
<text x="80" y="400" class="axis-label-pl" text-anchor="middle">1M</text><text x="212" y="400" class="axis-label-pl" text-anchor="middle">10M</text><text x="344" y="400" class="axis-label-pl" text-anchor="middle">100M</text><text x="476" y="400" class="axis-label-pl" text-anchor="middle">1B</text><text x="608" y="400" class="axis-label-pl" text-anchor="middle">10B</text>
<text x="400" y="420" class="title-text-pl" text-anchor="middle">Miesięczny wolumen tokenów (skala log)</text>
<line x1="80" y1="60" x2="80" y2="380" class="axis-line-pl"/><line x1="80" y1="380" x2="740" y2="380" class="axis-line-pl"/>
<polyline points="80,420 212,366 344,286 476,206 608,126" fill="none" stroke="#b8941f" stroke-width="2.5"/>
<text x="615" y="120" class="legend-text-pl" fill="#b8941f">Claude Opus 4.7 API</text>
<text x="615" y="132" class="annotation-pl" fill="#b8941f">$15 za 1M tokenów</text>
<polyline points="80,572 212,508 344,412 476,332 608,252" fill="none" stroke="#3a6090" stroke-width="2.5" stroke-dasharray="4 3"/>
<text x="615" y="246" class="legend-text-pl" fill="#3a6090">Mistral La Plateforme API</text>
<text x="615" y="258" class="annotation-pl" fill="#3a6090">$0,40 za 1M tokenów</text>
<polyline points="80,266 740,266" fill="none" stroke="#1a2e4d" stroke-width="2.5"/>
<text x="86" y="258" class="legend-text-pl" fill="#1a2e4d">Mistral Small 3.2 self-host (~$2 700/mies. flat)</text>
<polyline points="80,256 740,256" fill="none" stroke="#5a8a5a" stroke-width="2.5" stroke-dasharray="6 4"/>
<text x="86" y="248" class="legend-text-pl" fill="#5a8a5a">gpt-oss-120b self-host (~$3 200/mies. flat)</text>
<circle cx="377" cy="266" r="6" class="crossover-marker-pl"/>
<text x="377" y="248" class="annotation-pl" text-anchor="middle">Przecięcie ~180M tok/mies.</text>
<text x="377" y="284" class="annotation-pl" text-anchor="middle">Mistral OSS vs Opus API</text>
<text x="400" y="455" class="annotation-pl" text-anchor="middle">Hosting: dostawcy GPU UE (Scaleway, OVHcloud) - wartości ilustracyjne, nie kontraktowe</text>
</svg>
<figcaption class="text-sm text-gosign-text-light text-center mt-4 max-w-2xl mx-auto">
<strong>Punkt przecięcia TCO: self-hosted vs API chmurowe</strong> - liniowe krzywe chmurowych API (pricing per token) wobec płaskich krzywych self-hostowych (CAPEX amortyzowany). Mistral La Plateforme API pozostaje najtańsze poniżej ~10B tokenów/miesiąc - istotna decyzja to Mistral OSS self-host vs Claude Opus 4.7 API, przecinające się dla obciążeń krytycznych pod kątem suwerenności przy ~180 mln tokenów miesięcznie. Poniżej 50M tokenów/miesiąc dominuje ekonomia chmurowa. Powyżej 500M tokenów/miesiąc dominuje self-host niezależnie od modelu.
</figcaption>
</figure>

## Hosting GPU w Polsce i UE w 2026: kto faktycznie ma pojemność H100?

Polski i unijny rynek hostingu GPU znacząco dojrzał w 2025-2026. Sześciu providerów pokrywa większość przypadków self-hostingu enterprise.

**Atman** (Polska, Warszawa). Największy polski operator data center, oferuje colocation i GPU-cloud z RTX i A100. Polska jurysdykcja, jasny kontekst RODO. Wybór, gdy zakupy wymagają polskiego operatora albo gdy umowy z polskimi organami publicznymi wymagają fizycznej obecności w PL.

**Polcom** (Polska, Kraków). Polski operator chmury z naciskiem na sektor regulowany. Dobre dopasowanie pod sektor bankowy i ubezpieczeniowy z wymogami KNF Rekomendacja D oraz DORA art. 28-30 (rejestr dostawców ICT od 17 stycznia 2025). UKNF (Urząd Komisji Nadzoru Finansowego) bezpośrednio nadzoruje wdrożenia AI w bankach, ubezpieczycielach i SKOK-ach.

**Beyond.pl** (Polska, Poznań). Jedyny Tier IV data center w Polsce. Preferowany dla NIS2 Critical Entity wymogów i KSC Tier-1 Operator istotnej usługi (Krajowy System Cyberbezpieczeństwa). Wybór dla podmiotów krytycznych w sektorze energii, telekomunikacji i administracji publicznej.

**Chmura Krajowa / OChK** (Polska, joint venture PKO + PFR + Google Cloud Polska). Sovereign cloud dla podmiotów publicznych i krytycznej infrastruktury. Dopasowanie zakupowe dla URE (Urząd Regulacji Energetyki), administracji centralnej i podmiotów objętych NIS2.

**Scaleway** (Francja, RODO-native). Najbardziej agresywny w price-performance dla obciążeń AI. H100 SXM za ~3,50 EUR/h, A100 za ~2,50 EUR/h, plus nowsza NVIDIA Blackwell B300-SXM (288 GB VRAM) dla obciążeń frontowych. Francuskie centra danych, pełne RODO, brak ekspozycji CLOUD Act. Dostępne reserved-instance dla przewidywalnych obciążeń.

**OVHcloud** (Francja, poziom sovereign). Największy europejski provider chmury, ze "Sovereign Cloud" jawnie zbudowanym dla sektora publicznego i regulowanego. Portfolio obejmuje H100, RTX 5000, A10 plus usługę "AI Deploy" do notebooków pay-as-you-go i inferencji. Dobre dopasowanie, gdy zakupy wymagają sign-off sovereign-cloud.

**Hetzner** (Niemcy). Lider cenowy dla dedykowanych serwerów GPU, nie instancji on-demand. Aktualne opcje GPU: RTX 4000 SFF Ada i RTX 6000 Ada w parze z nowoczesnymi CPU. Ścieżka dla Mistral Small 3.2 z kwantyzacją albo dla środowisk deweloperskich. Mniej nadaje się do elastycznego skalowania szczytów.

Dla branż regulowanych (usługi finansowe, ochrona zdrowia, sektor publiczny) z surowymi wymogami suwerenności:

**IONOS** (Niemcy). Hosting klasy sovereign-cloud z instancjami GPU. Dopasowanie compliance dla obciążeń regulowanych przez UKNF (Urząd Komisji Nadzoru Finansowego) w polskich oddziałach niemieckich grup bankowych oraz dla niemieckich oddziałów polskich korporacji.

**T-Systems** (Niemcy). Subsidiary Deutsche Telekom. Sovereign cloud zaprojektowany jawnie dla sektora publicznego i krytycznej infrastruktury. Wybór wygodny zakupowo, gdy zarząd wymaga certyfikacji suwerennej.

Dla enterprise decydującego o stacku self-hosted praktyczna sekwencja: pilotaż na Atman, Scaleway albo Hetzner dla taniej walidacji, przejście do OVHcloud albo T-Systems w produkcji, jeśli regulacyjny sign-off wymaga certyfikacji sovereign-cloud, utrzymanie kontraktów reserved-instance dla kontroli przewidywalności kosztu.

## Wzorce wdrożenia: pojedynczy worker, klaster, hybryda

Trzy wzorce wdrożenia pokrywają niemal wszystkie scenariusze self-hosted enterprise.

**Wzorzec pojedynczego workera.** Jeden model, jedna instancja GPU, wdrożona za load balancerem z health checkami. Pasuje do: Mistral Small 3.2 na RTX 4090 albo H100 dla 70 procent obciążenia volumenowego. Llama 4 Scout na pojedynczym GPU dla analizy dokumentów długokontekstowych. Złożoność operacyjna: niska. Tryb awarii: pojedynczy punkt awarii, chyba że replikowany.

**Wzorzec klastra wielomodelowego.** Wiele modeli na wielu GPU za warstwą routingu. Pasuje do: Mistral Small dla volumenu + gpt-oss-120b albo DeepSeek V4-Flash dla ciężkiego rozumowania + (opcjonalnie) DeepSeek V4-Pro na dedykowanym klastrze dla obciążeń klasy matematycznej, wszystko za jedną warstwą routingu. Warstwa routingu decyduje per request, który model go obsługuje. Złożoność operacyjna: średnia. Wymaga model servera (vLLM, TGI, llama.cpp-server) i silnika reguł routingu. To typowy wzorzec produkcyjny dla obciążeń agentów z mieszaną złożonością decyzji.

**Wzorzec hybrydowy edge-cloud.** Wrażliwe obciążenia (onboarding HR, przegląd kontraktów, ekstrakcja danych klienta) na modelach self-hosted; niewrażliwe obciążenia (generacja copy marketingowego, Q&A na bazie wiedzy o informacjach publicznych) na API w chmurze UE jak Mistral La Plateforme. Warstwa routingu wymusza klasyfikację danych przed selekcją modelu. Złożoność operacyjna: wysoka (dwa stacki do utrzymania), ale najniższa ekspozycja suwerenności i najlepszy stosunek kosztu do decyzji.

Wybór wzorca zależy od taksonomii klasyfikacji danych, nie od selekcji modelu. Jeśli wszystko jest sklasyfikowane jako "wewnętrzne" albo wyżej, dominuje wzorzec klastra wielomodelowego. Jeśli znacząca część pracy jest na danych publicznych albo niewrażliwych, wzorzec hybrydowy jest tańszy.

## Macierz decyzji: który model do którego obciążenia

| Kategoria obciążenia | Rekomendowany model | Dlaczego |
|---|---|---|
| Klasyfikacja dokumentów, ekstrakcja strukturalna, parsowanie pól z OCR | Mistral Small 3.2 (self-hosted) | Zdolność wizualna, szybki na konsumenckim GPU, pokrycie wielojęzyczne |
| Standardowa generacja tekstu (maile, powiadomienia, przypomnienia NDA) | Mistral Small 3.2 (self-hosted) | Wysoka przepustowość, przyjazny szablonom |
| Klasyfikacja klauzul kontraktowych, flagowanie ryzyka dostawcy, wykrywanie anomalii | Mistral Small 3.2 albo Mistral Medium 3.1 (La Plateforme) | Średnie rozumowanie przy niskim koszcie |
| Analiza antydyskryminacyjna zgodnie z Kodeksem Pracy art. 18(3a), złożone rozumowanie wielostatutowe | gpt-oss-120b on-prem (albo Claude Opus 4.7 cloud) | Rozumowanie poziomu o4-mini na licencji Apache 2.0 |
| Modelowanie ryzyka finansowego, stress testing, problemy optymalizacyjne | DeepSeek V4-Flash (bieżący) albo V4-Pro przez API/hostowany (jeśli sprzęt pozwala); R1 wciąż żywy w mature wdrożeniach | Topowe benchmarki matematyka/logika, linia V4 dodaje kontekst 1M do analizy cross-portfelowej |
| Analiza dokumentów dużych korpusów (całe portfele kontraktów, pełne raporty roczne) | Llama 4 Scout (self-hosted) | Okno kontekstu 10 mln tokenów |
| Multimodal (korelacja obraz plus tekst, przegląd rysunku technicznego) | Gemini 3.1 Pro (tylko chmura - brak odpowiednika self-hosted) | Natywny trening multimodalny |
| Generacja kodu, code review, workflow agentów (cloud flagships) | Claude Opus 4.7 albo GPT-5.5 | Oba liderzy benchmarków kodu; Claude Opus 4.7 mocniejszy w długich loopach agentowych (Claude Code), GPT-5.5 mocniejszy w integracji z IDE (Cursor, Copilot) |
| Generacja kodu, code review, workflow agentów (self-hosted) | Qwen 3 Coder 110B (Apache 2.0, Alibaba), DeepSeek Coder V4 (MIT), albo Codestral Mamba 32B (Mistral, EU-built) | Top-tier coding benchmarks on-prem; Qwen 3 Coder lider HumanEval/SWE-Bench wśród OSS, DeepSeek Coder V4 najmocniejszy przy agentowych Multi-File-Tasks, Codestral Mamba najniższa latencja na konsumenckim GPU |
| Microsoft 365 integration, Copilot extensibility, Azure-native workloads | GPT-5.5 via Azure OpenAI | Natywny stack, najniższy wysiłek integracyjny dla organizacji na Microsoft data plane |
| Agentic workflows, orkiestracja narzędzi, structured outputs | GPT-5.5 albo Claude Opus 4.7 | Oba top-tier w strukturyzowanych wyjściach i orkiestracji narzędzi; GPT-5.5 z szerszym ekosystemem pre-built tools |
| SaaS feature gating (tier-based AI access dla customer-facing produktów) | Hybrid pattern: Mistral Small + Claude Opus 4.7 / GPT-5.5 | Wrażliwe dane klienta self-hosted, premium features na cloud flagship |
| Conversational AI / chatboty obsługi klienta | Mistral Small 3.2 (self-hosted) dla wolumenu; GPT-5.5 (Azure) gdy stack MS-natywny | Jakość produkcyjna przy najniższym koszcie sprzętu; cloud-fallback dla MS-shops |

Macierz nie jest receptą. To punkt wyjścia doprecyzowany per organizacja. Enterprise zorientowane na finanse waży DeepSeek V4 wyżej. Operacja multimedialna może potrzebować chmurowego skoku do Gemini. Pipeline HR z dużym wolumenem dokumentów ustawia Mistral Small na 80 procent decyzji, nie 70.

Warstwa routingu czyni macierz operacyjną. Bez niej każde obciążenie biegnie przeciwko temu, co jest skonfigurowane jako domyślne, a macierz staje się artefaktem prezentacji.

## Budowa warstwy routingu: gdzie pasuje Decision Layer

Architektury wielomodelowe self-hosted rozpadają się bez warstwy routingu z prostego powodu: żaden operator nie chce pamiętać 14 mapowań decyzja-model jednocześnie z pisaniem logiki biznesowej agenta. Routing musi być konfiguracją, nie kodem.

Decision Layer trzyma:

- Taksonomię klasyfikacji danych (które typy danych wymagają self-hosted? Które mogą iść do API w chmurze UE? Które do API w chmurze USA?)
- Reguły routingu decyzja-model per krok workflow
- Łańcuch fallback (jeśli Mistral Small awarii albo saturuje, do której alternatywy routować?)
- Audit log: każda decyzja zapisana ze snapshotem wejścia, wersją reguły, użytym modelem, oceną pewności, łańcuchem rozumowania, wynikiem i osobą zatwierdzającą tam, gdzie dotyczy
- Przycisk zaskarżenia: osoba, której decyzja dotyczy, może zakwestionować zautomatyzowaną decyzję, uruchamiając ponowną decyzję pod nadzorem człowieka - mechanizm wymagany przez RODO art. 22

To jest artefakt, który audytor EU AI Act art. 13 kontroluje. To jest artefakt, który Rada Pracowników przegląda, klasyfikując, którzy agenci wpadają w zakres konsultacji zgodnie z Ustawą o radach pracowników, art. 13-15. To jest artefakt, który satysfakcjonuje pytanie zakupów: "co się stanie, gdy twój dostawca AI zmieni model" - bo zmienia się reguła routingu, nie logika biznesowa.

Budowa tej warstwy in-house jest wykonalna, ale rzadko szybsza niż 6-9 miesięcy dla zespołu enterprise startującego od zera. Kupno jako framework konfiguracyjny zwykle skraca ścieżkę do 4-6 tygodni dla pierwszego agenta produkcyjnego.

## Wniosek

AI open-source na własnym hostingu jest wiarygodnym wyborem produkcyjnym dla polskiego enterprise w 2026 - ale wyłącznie jako architektura wielomodelowa z warstwą routingu, nie jako zakład na pojedynczy model. Mistral Small 3.2 pokrywa pas wolumenu. gpt-oss-120b albo DeepSeek V4-Flash pokrywa ciężkie rozumowanie on-prem. DeepSeek V4-Pro (obecnie w preview) zbliża się do terytorium Claude Opus, jeśli masz sprzęt klasy hyperscaler - albo czekasz na release GA i używasz go przez API w międzyczasie. Llama 4 Scout pokrywa ultra-długi kontekst. Poziom API w chmurze (Claude Opus 4.7, GPT-5.5, Gemini 3.1 Pro) pozostaje dostępny dla obciążeń, gdzie ramy regulacyjne to dopuszczają.

Decyzja routingu jest architekturą. Przecięcie TCO (ok. 50-100 mln tokenów miesięcznie sustained) wyznacza ekonomiczny próg dla self-hostingu. Taksonomia compliance (która klasyfikacja danych nie może opuścić sieci) wyznacza próg suwerenności. Oba progi kształtują reguły routingu.

Inni publikują rankingi. My budujemy warstwę routingu, która je operacjonalizuje. Rynek modeli zmienia się miesięcznie; architektura routingu przetrwa pięć generacji modeli. Kod źródłowy zostaje u klienta. Modele pozostają wymienne. Zgodność z EU AI Act art. 13 jest właściwością architektury, nie projektem na końcu.

Jeśli chcesz wiedzieć, jak powinien wyglądać twój stack self-hosted na podstawie twojego rzeczywistego miksu obciążeń i klasyfikacji danych, [umów konsultację](/pl/kontakt/).

--- Security Baseline dla całego stacku ---
> Bazowa linia bezpieczeństwa YAML dla Supabase, Next.js, Edge Functions i Trigger.dev z automatycznymi kontrolami.

Poprzednie runbooki opisały poszczególne komponenty: [Supabase Platform](/pl/magazyn/supabase-self-hosting/) (artykuł 1), [warstwa Next.js](/pl/magazyn/nextjs-supabase-bezpieczna-konfiguracja/) (artykuł 2), [Edge Functions](/pl/magazyn/supabase-edge-functions-bezpieczenstwo/) (artykuł 3), [Trigger.dev Jobs](/pl/magazyn/trigger-dev-background-jobs/) (artykuł 4) i [Claude Code jako kontrola bezpieczeństwa](/pl/magazyn/claude-code-security-devops/) (artykuł 5).

Ten ostatni artykuł scala wszystkie reguły w **jednym, maszynowo odczytywalnym pliku**: `security-baseline.yml`. Ten plik definiuje stan docelowy całego stacku. Wszystkie deploymenty, przeglądy i audyty są weryfikowane względem tej Baseline - zarówno przez deterministyczne skrypty, jak i przez Claude Code.

Artykuł dostarcza trzy rzeczy:
1. Kompletny plik `security-baseline.yml`
2. Skrypt, który automatycznie go weryfikuje
3. Integrację z audytem Claude Code z artykułu 5


<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">W skrócie - Artykuł 6 z 6 serii DevOps Runbook</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Jeden plik YAML definiuje stan docelowy stacku</li>
<li>Codzienne zautomatyzowane kontrole</li>
<li>Cotygodniowa analiza Claude</li>
<li>Bramka deploymentu blokuje przy krytycznych naruszeniach</li>
<li>Żywy dokument aktualizowany wraz ze zmianami stacku</li>
</ul>
</div>

## Spis treści serii

Ten przewodnik jest częścią naszej serii runbooków DevOps dla self-hosted stacków aplikacyjnych.

1. [Supabase Self-Hosting Runbook](/pl/magazyn/supabase-self-hosting/)
2. [Next.js nad Supabase - bezpieczna eksploatacja](/pl/magazyn/nextjs-supabase-bezpieczna-konfiguracja/)
3. [Supabase Edge Functions - bezpieczne wdrożenie](/pl/magazyn/supabase-edge-functions-bezpieczenstwo/)
4. [Trigger.dev Background Jobs - bezpieczna eksploatacja](/pl/magazyn/trigger-dev-background-jobs/)
5. [Claude Code jako kontrola bezpieczeństwa w workflow DevOps](/pl/magazyn/claude-code-security-devops/)
6. [Security Baseline dla całego stacku](/pl/magazyn/security-baseline-stack/) - ten artykuł

Ten artykuł łączy wszystkie poprzednie runbooki w **weryfikowalną strategię bezpieczeństwa**.

## Przegląd architektury

```
security-baseline.yml
   |
   +---> scripts/check-baseline.sh     (deterministyczny, codziennie)
   |       |
   |       +---> baseline-report.md    (fakty: zaliczony/niezaliczony)
   |
   +---> Claude Code Audit             (kontekstowy, cotygodniowo)
   |       |
   |       +---> claude-review.md      (interpretacja + priorytety)
   |
   +---> Deployment Gate               (CI/CD, przy każdym deployu)
           |
           +---> Deploy zablokowany gdy krytyczne reguły naruszone
```

Baseline jest **Single Source of Truth** dla stanu bezpieczeństwa. Wszystko inne - skrypty kontrolne, Claude Code, listy kontrolne deploymentu z artykułów 1-5 - wywodzi się z niej.


### Kategorie Baseline

| Kategoria | Liczba reguł | Częstotliwość kontroli | Eskalacja |
|---|---|---|---|
| Infrastruktura (artykuł 1) | 8 | Codziennie | KRYTYCZNE: natychmiast, OSTRZEŻENIE: ten tydzień |
| Supabase Platform (artykuł 1) | 6 | Codziennie | KRYTYCZNE: natychmiast |
| Next.js (artykuł 2) | 7 | Codziennie + przy PR | KRYTYCZNE: blokada deployu |
| Edge Functions (artykuł 3) | 4 | Codziennie | KRYTYCZNE: natychmiast |
| Trigger.dev (artykuł 4) | 5 | Codziennie | OSTRZEŻENIE: ten tydzień |
| Compliance | 3 | Cotygodniowo | KRYTYCZNE: natychmiast |

## Plik security-baseline.yml

Ten plik należy umieścić w katalogu głównym repozytorium infrastruktury. Jest maszynowo odczytywalny (YAML), czytelny dla człowieka (komentarze) i interpretowalny przez Claude Code (kontekst).

```yaml
# security-baseline.yml
# Security Baseline für den self-hosted Stack
# Letzte Aktualisierung: 2026-03-12
# Verantwortlich: DevOps Team
#
# Diese Datei definiert den Soll-Zustand des gesamten Stacks.
# Sie wird täglich automatisch geprüft (scripts/check-baseline.sh)
# und wöchentlich von Claude Code kontextuell analysiert.

version: "1.0"
stack: "supabase-nextjs-trigger"
last_reviewed: "2026-03-12"

# =============================================
# INFRASTRUKTUR (Artikel 1)
# =============================================

infrastructure:
  servers:
    production:
      host: "10.0.1.10"
      external_hostname: "app.example.com"
      provider: "hetzner"    # CLOUD-Act-frei
    audit:
      host: "10.0.1.11"
      purpose: "security checks, monitoring, claude code"

  network:
    private_subnet: "10.0.1.0/24"
    # Nur diese Ports dürfen von aussen erreichbar sein
    allowed_external_ports:
      - 443    # HTTPS (über Reverse Proxy)
    # Diese Ports dürfen NUR intern erreichbar sein
    internal_only_ports:
      - 5432   # PostgreSQL (Supabase)
      - 5433   # PostgreSQL (Trigger.dev)
      - 8000   # Kong API Gateway
      - 3000   # Next.js (hinter Reverse Proxy)
      - 3040   # Trigger.dev Dashboard
      - 9000   # Supabase Studio

  firewall:
    layers: 2    # Cloud Firewall + Host Firewall
    baseline_file: "/opt/baselines/firewall-baseline.txt"
    drift_check: "daily"

  tls:
    provider: "letsencrypt"
    min_days_before_expiry: 14
    headers_required:
      - "Strict-Transport-Security"
      - "X-Frame-Options"
      - "X-Content-Type-Options"
      - "Content-Security-Policy"

  ssh:
    password_auth: false
    root_login: false
    pubkey_only: true
    allowed_users: ["deploy"]

  backups:
    frequency: "daily"
    max_age_hours: 26
    encryption: "gpg"
    external_storage: true    # auf audit-runner, nicht nur lokal
    restore_test: "monthly"

# =============================================
# SUPABASE PLATFORM (Artikel 1)
# =============================================

supabase:
  images:
    pinned: true              # kein :latest
    # Erwartete Images und Versionen (aktualisieren bei Updates)
    postgres: "supabase/postgres:15.6.1.143"
    kong: "kong:2.8.1"
    gotrue: "supabase/gotrue:v2.164.0"

  postgres:
    listen_address: "10.0.1.10"    # NUR internes Interface
    rls:
      required_on_all_public_tables: true
      # Tabellen die bewusst ohne RLS sind (mit Begründung)
      exceptions: []

  gotrue:
    jwt_exp: 3600               # max. 1 Stunde
    mailer_autoconfirm: false
    refresh_token_rotation: true

  studio:
    external_access: false      # nur über SSH Tunnel oder VPN

  secrets:
    env_file: ".env"
    env_file_permissions: "600"
    in_git: false
    min_length: 16
    # Erwartete Secrets (ohne Werte)
    required:
      - "JWT_SECRET"
      - "ANON_KEY"
      - "SERVICE_ROLE_KEY"
      - "POSTGRES_PASSWORD"
      - "DASHBOARD_USERNAME"
      - "DASHBOARD_PASSWORD"

# =============================================
# NEXT.JS APP LAYER (Artikel 2)
# =============================================

nextjs:
  service_role:
    # Dateien in denen service_role erlaubt ist
    allowed_files:
      - "lib/supabase/admin.ts"
    # Darf NIEMALS erscheinen in:
    forbidden_patterns:
      - "NEXT_PUBLIC_*"
      - "app/**/*.tsx"           # Client Components
      - ".next/static/**"        # Client Bundle

  auth:
    middleware_required: true
    middleware_file: "middleware.ts"
    middleware_uses: "getUser"     # NICHT getSession
    server_actions_require_auth: true
    route_handlers_require_auth: true

  security_headers:
    required:
      - "Strict-Transport-Security"
      - "X-Frame-Options"
      - "Content-Security-Policy"
      - "X-Content-Type-Options"

  env_vars:
    # Nur diese dürfen NEXT_PUBLIC sein
    allowed_public:
      - "NEXT_PUBLIC_SUPABASE_URL"
      - "NEXT_PUBLIC_SUPABASE_ANON_KEY"

  rate_limiting:
    required_endpoints:
      - "/api/auth/login"
      - "/api/auth/signup"
      - "/api/auth/reset"

# =============================================
# EDGE FUNCTIONS (Artikel 3)
# =============================================

edge_functions:
  purpose: "integrations_only"     # NICHT für Business-Logik
  runtime: "deno"

  requirements:
    webhook_signature_check: true
    input_validation: true
    cors_no_wildcard_in_production: true
    no_hardcoded_secrets: true
    max_duration_seconds: 60

  secrets:
    env_file: ".env.functions"
    in_git: false

  deployment:
    method: "volume_copy"          # Dateien ins Volume, Container restart

# =============================================
# TRIGGER.DEV (Artikel 4)
# =============================================

trigger_dev:
  version: "v3"
  hosting: "self-hosted"
  separate_database: true           # eigene PostgreSQL, nicht Supabase DB

  dashboard:
    external_access: false          # nur SSH Tunnel oder VPN

  task_requirements:
    max_duration_required: true
    concurrency_limit_required: true
    retry_config_required: true
    idempotency_on_external_calls: true
    exported: true                  # alle Tasks müssen exportiert sein

  logging:
    use_trigger_logger: true        # nicht console.log
    no_sensitive_data: true

  db_access:
    # Dateien in denen service_role / DATABASE_URL erlaubt ist
    allowed_files:
      - "trigger/lib/supabase.ts"
      - "trigger/lib/db.ts"
    connection_pool_max: 10

# =============================================
# CLAUDE CODE AUDIT (Artikel 5)
# =============================================

claude_code:
  runs_on: "audit-runner"           # NICHT auf Produktion
  allowed_tools: "Read,Grep,Glob"   # kein Bash
  max_turns: 10
  schedule: "weekly"                # Sonntag 06:00
  alert_on: "KRITISCH"

  api_key:
    separate_ci_key: true
    budget_limit_monthly_usd: 50

# =============================================
# COMPLIANCE
# =============================================

compliance:
  cloud_act:
    us_providers_allowed: false
    reason: "CLOUD Act Risiko: US-Behörden können Datenzugriff erzwingen"
    allowed_jurisdictions:
      - "EU"
      - "BR"

  data_residency:
    required: true
    allowed_countries:
      - "DE"     # Deutschland (Hetzner)
      - "BR"     # Brasilien

  git:
    no_secrets_in_repo: true
    infrastructure_as_code: true
    no_manual_server_changes: true
```

## Skrypt kontroli Baseline

Ten skrypt odczytuje plik `security-baseline.yml` i automatycznie weryfikuje każdy punkt. Działa codziennie na serwerze audytowym.

```bash
#!/bin/bash
# scripts/check-baseline.sh
# Prüft den Produktionsserver gegen die security-baseline.yml
# Läuft auf dem audit-runner (10.0.1.11)

set -euo pipefail

PROD_HOST="10.0.1.10"
EXTERNAL_HOST="app.example.com"
REPORT=""
CRITICAL=0
WARNING=0
PASS=0

check() {
  local level="$1"    # KRITISCH, WARNUNG, INFO
  local name="$2"
  local result="$3"   # PASS oder FAIL
  local detail="$4"

  if [ "$result" = "PASS" ]; then
    REPORT+="  OK ${name}\n"
    ((PASS++))
  else
    REPORT+="  FAIL [${level}] ${name}: ${detail}\n"
    [ "$level" = "KRITISCH" ] && ((CRITICAL++))
    [ "$level" = "WARNUNG" ] && ((WARNING++))
  fi
}

echo "=== Security Baseline Check $(date +%Y-%m-%d) ==="

# -------------------------------------------
# INFRASTRUKTUR
# -------------------------------------------
REPORT+="\n## Infrastruktur\n\n"

# Ports von aussen
OPEN_PORTS=$(nmap -p 22,80,443,3000,3040,5432,5433,8000,9000 "$EXTERNAL_HOST" \
  -oG - 2>/dev/null | grep -oP '\d+/open' | grep -v "443" || true)
if [ -z "$OPEN_PORTS" ]; then
  check "KRITISCH" "Nur Port 443 extern offen" "PASS" ""
else
  check "KRITISCH" "Nur Port 443 extern offen" "FAIL" "Offen: $OPEN_PORTS"
fi

# Firewall Drift
FW_DIFF=$(ssh deploy@${PROD_HOST} "iptables-save" 2>/dev/null | \
  diff /opt/baselines/firewall-baseline.txt - 2>&1 || true)
if [ -z "$FW_DIFF" ]; then
  check "WARNUNG" "Firewall unverändert" "PASS" ""
else
  check "WARNUNG" "Firewall unverändert" "FAIL" "Firewall hat sich geändert"
fi

# SSH Konfiguration
SSH_PW=$(ssh deploy@${PROD_HOST} "sshd -T 2>/dev/null | grep passwordauthentication" || true)
if echo "$SSH_PW" | grep -q "no"; then
  check "KRITISCH" "SSH Passwort-Login deaktiviert" "PASS" ""
else
  check "KRITISCH" "SSH Passwort-Login deaktiviert" "FAIL" "Passwort-Auth noch aktiv"
fi

SSH_ROOT=$(ssh deploy@${PROD_HOST} "sshd -T 2>/dev/null | grep permitrootlogin" || true)
if echo "$SSH_ROOT" | grep -q "no"; then
  check "KRITISCH" "SSH Root-Login deaktiviert" "PASS" ""
else
  check "KRITISCH" "SSH Root-Login deaktiviert" "FAIL" "Root-Login noch möglich"
fi

# TLS Zertifikat
CERT_DAYS=$(echo | openssl s_client -connect ${EXTERNAL_HOST}:443 2>/dev/null | \
  openssl x509 -noout -enddate 2>/dev/null | cut -d= -f2)
if [ -n "$CERT_DAYS" ]; then
  EPOCH_CERT=$(date -d "$CERT_DAYS" +%s 2>/dev/null || echo 0)
  EPOCH_NOW=$(date +%s)
  DAYS_LEFT=$(( (EPOCH_CERT - EPOCH_NOW) / 86400 ))
  if [ "$DAYS_LEFT" -ge 14 ]; then
    check "WARNUNG" "TLS Zertifikat gültig (${DAYS_LEFT} Tage)" "PASS" ""
  else
    check "WARNUNG" "TLS Zertifikat gültig" "FAIL" "Nur noch ${DAYS_LEFT} Tage"
  fi
fi

# Security Headers
for HEADER in "Strict-Transport-Security" "X-Frame-Options" "X-Content-Type-Options"; do
  if curl -sI "https://${EXTERNAL_HOST}" | grep -qi "$HEADER"; then
    check "WARNUNG" "Header: ${HEADER}" "PASS" ""
  else
    check "WARNUNG" "Header: ${HEADER}" "FAIL" "Header fehlt"
  fi
done

# Backup
LAST_BACKUP=$(ssh deploy@${PROD_HOST} "ls -t /opt/backups/*.gpg 2>/dev/null | head -1" || true)
if [ -n "$LAST_BACKUP" ]; then
  BACKUP_AGE=$(ssh deploy@${PROD_HOST} \
    "echo \$(( (\$(date +%s) - \$(stat -c %Y ${LAST_BACKUP})) / 3600 ))" 2>/dev/null || echo 999)
  if [ "$BACKUP_AGE" -le 26 ]; then
    check "KRITISCH" "Backup aktuell (${BACKUP_AGE}h alt)" "PASS" ""
  else
    check "KRITISCH" "Backup aktuell" "FAIL" "${BACKUP_AGE} Stunden alt"
  fi
else
  check "KRITISCH" "Backup aktuell" "FAIL" "Kein Backup gefunden"
fi

# Disk Space
DISK=$(ssh deploy@${PROD_HOST} "df -h / | tail -1 | awk '{print \$5}' | tr -d '%'" 2>/dev/null || echo 99)
if [ "$DISK" -le 85 ]; then
  check "WARNUNG" "Disk Usage (${DISK}%)" "PASS" ""
else
  check "WARNUNG" "Disk Usage" "FAIL" "${DISK}% belegt"
fi

# -------------------------------------------
# SUPABASE
# -------------------------------------------
REPORT+="\n## Supabase\n\n"

# Container laufen
STOPPED=$(ssh deploy@${PROD_HOST} "cd /opt/supabase && docker compose ps --format json 2>/dev/null" | \
  jq -r 'select(.State != "running") | .Name' 2>/dev/null || true)
if [ -z "$STOPPED" ]; then
  check "KRITISCH" "Alle Supabase Container running" "PASS" ""
else
  check "KRITISCH" "Alle Supabase Container running" "FAIL" "Gestoppt: $STOPPED"
fi

# Images gepinnt (kein :latest)
LATEST_IMAGES=$(ssh deploy@${PROD_HOST} "cd /opt/supabase && grep 'image:' docker-compose.yml | grep 'latest'" 2>/dev/null || true)
if [ -z "$LATEST_IMAGES" ]; then
  check "WARNUNG" "Alle Images versioniert (kein :latest)" "PASS" ""
else
  check "WARNUNG" "Alle Images versioniert" "FAIL" "latest gefunden"
fi

# RLS auf allen public-Tabellen
UNPROTECTED=$(ssh deploy@${PROD_HOST} "cd /opt/supabase && docker compose exec -T postgres psql -U postgres -t -c \
  \"SELECT count(*) FROM pg_tables WHERE schemaname = 'public' AND rowsecurity = false;\"" 2>/dev/null | tr -d ' ' || echo "?")
if [ "$UNPROTECTED" = "0" ]; then
  check "KRITISCH" "RLS auf allen public-Tabellen aktiv" "PASS" ""
elif [ "$UNPROTECTED" != "?" ]; then
  check "KRITISCH" "RLS auf allen public-Tabellen aktiv" "FAIL" "${UNPROTECTED} Tabellen ohne RLS"
fi

# Postgres nur intern
PG_LISTEN=$(ssh deploy@${PROD_HOST} "ss -tlnp | grep 5432" 2>/dev/null || true)
if echo "$PG_LISTEN" | grep -q "0.0.0.0:5432"; then
  check "KRITISCH" "Postgres nur auf internem Interface" "FAIL" "Lauscht auf 0.0.0.0"
else
  check "KRITISCH" "Postgres nur auf internem Interface" "PASS" ""
fi

# Studio nicht extern erreichbar
STUDIO=$(curl -s -o /dev/null -w "%{http_code}" --connect-timeout 3 "https://${EXTERNAL_HOST}:9000" 2>/dev/null || echo "000")
if [ "$STUDIO" = "000" ]; then
  check "KRITISCH" "Supabase Studio nicht extern erreichbar" "PASS" ""
else
  check "KRITISCH" "Supabase Studio nicht extern erreichbar" "FAIL" "Status: $STUDIO"
fi

# -------------------------------------------
# NEXT.JS
# -------------------------------------------
REPORT+="\n## Next.js\n\n"

# service_role im Client Code
SR_LEAK=$(ssh deploy@${PROD_HOST} "cd /opt/app && grep -rn 'SERVICE_ROLE\|service_role' app/ \
  --include='*.ts' --include='*.tsx' 2>/dev/null | grep -v 'lib/supabase/admin.ts' | grep -v node_modules" 2>/dev/null || true)
if [ -z "$SR_LEAK" ]; then
  check "KRITISCH" "service_role nicht im Client Code" "PASS" ""
else
  check "KRITISCH" "service_role nicht im Client Code" "FAIL" "Gefunden in: $(echo "$SR_LEAK" | head -3)"
fi

# NEXT_PUBLIC mit Secrets
PUB_SECRET=$(ssh deploy@${PROD_HOST} "cd /opt/app && grep 'NEXT_PUBLIC_' .env* 2>/dev/null | \
  grep -iE 'service_role|secret|private|database'" 2>/dev/null || true)
if [ -z "$PUB_SECRET" ]; then
  check "KRITISCH" "Keine Secrets in NEXT_PUBLIC Variablen" "PASS" ""
else
  check "KRITISCH" "Keine Secrets in NEXT_PUBLIC Variablen" "FAIL" "$PUB_SECRET"
fi

# middleware.ts existiert und nutzt getUser
MW_EXISTS=$(ssh deploy@${PROD_HOST} "test -f /opt/app/middleware.ts && echo yes || echo no" 2>/dev/null || echo "no")
if [ "$MW_EXISTS" = "yes" ]; then
  MW_GETUSER=$(ssh deploy@${PROD_HOST} "grep -c 'getUser' /opt/app/middleware.ts" 2>/dev/null || echo "0")
  if [ "$MW_GETUSER" -gt 0 ]; then
    check "KRITISCH" "middleware.ts existiert mit getUser()" "PASS" ""
  else
    check "KRITISCH" "middleware.ts mit getUser()" "FAIL" "getUser() fehlt"
  fi
else
  check "KRITISCH" "middleware.ts existiert" "FAIL" "Datei fehlt"
fi

# Server Actions ohne Auth
SA_NO_AUTH=$(ssh deploy@${PROD_HOST} "cd /opt/app && for file in \$(grep -rl \"'use server'\" app/ --include='*.ts' 2>/dev/null); do
  if ! grep -q 'getUser' \"\$file\"; then echo \"\$file\"; fi
done" 2>/dev/null || true)
if [ -z "$SA_NO_AUTH" ]; then
  check "WARNUNG" "Alle Server Actions haben Auth Check" "PASS" ""
else
  check "WARNUNG" "Server Actions ohne Auth" "FAIL" "$SA_NO_AUTH"
fi

# npm audit
NPM_HIGH=$(ssh deploy@${PROD_HOST} "cd /opt/app && npm audit --audit-level=high 2>&1 | \
  grep -c 'high\|critical'" 2>/dev/null || echo "0")
if [ "$NPM_HIGH" = "0" ]; then
  check "WARNUNG" "npm audit: keine high/critical" "PASS" ""
else
  check "WARNUNG" "npm audit" "FAIL" "${NPM_HIGH} high/critical Findings"
fi

# -------------------------------------------
# EDGE FUNCTIONS
# -------------------------------------------
REPORT+="\n## Edge Functions\n\n"

# Webhook Functions ohne Signaturprüfung
WH_NO_SIG=$(ssh deploy@${PROD_HOST} "for dir in /opt/supabase/volumes/functions/*-webhook/; do
  [ -d \"\$dir\" ] || continue
  name=\$(basename \"\$dir\")
  if ! grep -qE 'signature|verify|hmac|crypto' \"\$dir/index.ts\" 2>/dev/null; then
    echo \"\$name\"
  fi
done" 2>/dev/null || true)
if [ -z "$WH_NO_SIG" ]; then
  check "KRITISCH" "Alle Webhooks prüfen Signaturen" "PASS" ""
else
  check "KRITISCH" "Webhooks ohne Signaturprüfung" "FAIL" "$WH_NO_SIG"
fi

# Hardcoded Secrets
FN_SECRETS=$(ssh deploy@${PROD_HOST} "grep -rn 'sk_live\|sk_test\|whsec_\|Bearer ey' \
  /opt/supabase/volumes/functions/ --include='*.ts' 2>/dev/null" || true)
if [ -z "$FN_SECRETS" ]; then
  check "KRITISCH" "Keine hardcoded Secrets in Functions" "PASS" ""
else
  check "KRITISCH" "Hardcoded Secrets in Functions" "FAIL" "$FN_SECRETS"
fi

# -------------------------------------------
# TRIGGER.DEV
# -------------------------------------------
REPORT+="\n## Trigger.dev\n\n"

# Tasks ohne maxDuration
TD_NO_DUR=$(ssh deploy@${PROD_HOST} "cd /opt/app && for file in trigger/tasks/*.ts 2>/dev/null; do
  [ -f \"\$file\" ] || continue
  name=\$(basename \"\$file\" .ts)
  if ! grep -q 'maxDuration' \"\$file\"; then echo \"\$name\"; fi
done" 2>/dev/null || true)
if [ -z "$TD_NO_DUR" ]; then
  check "WARNUNG" "Alle Tasks haben maxDuration" "PASS" ""
else
  check "WARNUNG" "Tasks ohne maxDuration" "FAIL" "$TD_NO_DUR"
fi

# Tasks ohne Concurrency
TD_NO_CC=$(ssh deploy@${PROD_HOST} "cd /opt/app && for file in trigger/tasks/*.ts 2>/dev/null; do
  [ -f \"\$file\" ] || continue
  name=\$(basename \"\$file\" .ts)
  if ! grep -qE 'concurrencyLimit|queue:' \"\$file\"; then echo \"\$name\"; fi
done" 2>/dev/null || true)
if [ -z "$TD_NO_CC" ]; then
  check "WARNUNG" "Alle Tasks haben Concurrency Limit" "PASS" ""
else
  check "WARNUNG" "Tasks ohne Concurrency" "FAIL" "$TD_NO_CC"
fi

# Hardcoded Secrets in Tasks
TD_SECRETS=$(ssh deploy@${PROD_HOST} "grep -rn 'sk_live\|sk_test\|SG\.\|sk-' \
  /opt/app/trigger/ --include='*.ts' 2>/dev/null" || true)
if [ -z "$TD_SECRETS" ]; then
  check "KRITISCH" "Keine hardcoded Secrets in Tasks" "PASS" ""
else
  check "KRITISCH" "Hardcoded Secrets in Tasks" "FAIL" "$TD_SECRETS"
fi

# Trigger.dev Dashboard nicht extern
TD_DASH=$(curl -s -o /dev/null -w "%{http_code}" --connect-timeout 3 "https://${EXTERNAL_HOST}:3040" 2>/dev/null || echo "000")
if [ "$TD_DASH" = "000" ]; then
  check "KRITISCH" "Trigger.dev Dashboard nicht extern" "PASS" ""
else
  check "KRITISCH" "Trigger.dev Dashboard nicht extern" "FAIL" "Status: $TD_DASH"
fi

# -------------------------------------------
# COMPLIANCE
# -------------------------------------------
REPORT+="\n## Compliance\n\n"

# Git: keine Secrets im Repo
GIT_SECRETS=$(ssh deploy@${PROD_HOST} "cd /opt/app && git ls-files .env .env.functions .env.trigger 2>/dev/null" || true)
if [ -z "$GIT_SECRETS" ]; then
  check "KRITISCH" ".env Dateien nicht im Git" "PASS" ""
else
  check "KRITISCH" ".env Dateien im Git" "FAIL" "Committed: $GIT_SECRETS"
fi

# Git: keine uncommitted Changes auf dem Server
GIT_DIRTY=$(ssh deploy@${PROD_HOST} "cd /opt/app && git status --porcelain 2>/dev/null" || true)
if [ -z "$GIT_DIRTY" ]; then
  check "WARNUNG" "Keine manuellen Änderungen auf Server" "PASS" ""
else
  check "WARNUNG" "Manuelle Änderungen auf Server" "FAIL" "$(echo "$GIT_DIRTY" | wc -l) Dateien"
fi

# -------------------------------------------
# ZUSAMMENFASSUNG
# -------------------------------------------

SUMMARY="\n## Zusammenfassung\n\n"
SUMMARY+="Bestanden: ${PASS}\n"
SUMMARY+="Warnungen: ${WARNING}\n"
SUMMARY+="Kritisch:  ${CRITICAL}\n"

TOTAL_REPORT="${SUMMARY}\n${REPORT}"

# Report speichern
REPORT_FILE="/opt/audit/reports/baseline-$(date +%Y-%m-%d).md"
echo -e "# Security Baseline Check $(date +%Y-%m-%d)\n${TOTAL_REPORT}" > "$REPORT_FILE"

echo -e "$TOTAL_REPORT"

# Alert bei kritischen Findings
if [ "$CRITICAL" -gt 0 ]; then
  echo ""
  echo "!!! ${CRITICAL} KRITISCHE FINDINGS !!!"
  echo -e "$TOTAL_REPORT" | mail -s "KRITISCH: Baseline Check $(date)" ops@example.com
  exit 1
fi

exit 0
```

## Integracja z Claude Code (artykuł 5)

Skrypt kontroli Baseline dostarcza fakty. Claude Code je interpretuje. Cotygodniowy audyt z [artykułu 5](/pl/magazyn/claude-code-security-devops/) wykorzystuje raport Baseline jako input:

```bash
# Im Gesamt-Audit-Script (scripts/full-security-audit.sh aus Artikel 5)
# Nach den deterministischen Checks:

# Baseline-Report des heutigen Tages einlesen
BASELINE_REPORT=$(cat /opt/audit/reports/baseline-$(date +%Y-%m-%d).md 2>/dev/null || echo "Kein Baseline-Report vorhanden")

# An Claude Code übergeben
echo "$BASELINE_REPORT" | claude -p \
  "Du erhältst den Baseline-Check-Report unseres self-hosted Stacks.
Die Baseline ist definiert in security-baseline.yml.

Analysiere:
1. Welche KRITISCHEN Findings brauchen sofortige Aufmerksamkeit?
2. Gibt es Muster in den WARNUNGEN die auf systematische Probleme hindeuten?
3. Haben sich Findings gegenüber der Vorwoche verändert? (Vergleiche mit letztem Report)
4. Welche Prioritäten empfiehlst du für diese Woche?

Antworte auf Deutsch. Sei konkret." \
  --allowedTools "Read,Grep,Glob" \
  --output-format text \
  --max-turns 5
```

## Utrzymanie Baseline

Plik `security-baseline.yml` nie jest dokumentem statycznym. Rozwija się wraz ze stackiem.

**Kiedy aktualizować:**

```
Nowa tabela w Supabase             -> rls.exceptions sprawdzić
Nowy serwis w Docker Stack         -> internal_only_ports rozszerzyć
Nowa zmienna NEXT_PUBLIC           -> allowed_public rozszerzyć
Nowy sekret                        -> required Secrets rozszerzyć
Nowa Edge Function                 -> reguły kontroli obowiązują automatycznie
Nowy task Trigger.dev              -> reguły kontroli obowiązują automatycznie
Zmiana hostingu                    -> server/provider dostosować
```

**Workflow dla zmian w Baseline:**

```
1. Zmiana w security-baseline.yml w Git
2. PR Review (z uzasadnieniem dlaczego reguła się zmienia)
3. Claude Code sprawdza diff samej Baseline:
   "Czy to poluzowanie reguł jest uzasadnione?"
4. Merge po zatwierdzeniu
5. Następna kontrola Baseline korzysta z nowych reguł
```

## Konfiguracja Cron

```bash
# crontab auf dem audit-runner

# Täglicher Baseline-Check (06:00 Uhr)
0 6 * * * /opt/audit/scripts/check-baseline.sh >> /var/log/baseline-check.log 2>&1

# Wöchentlicher Claude Code Audit (Sonntag 07:00 Uhr, nach dem Baseline-Check)
0 7 * * 0 /opt/audit/scripts/full-security-audit.sh >> /var/log/security-audit.log 2>&1
```

## Lista kontrolna deploymentu

```
Plik Baseline
  [ ] security-baseline.yml obecny w repozytorium
  [ ] Wszystkie adresy IP i nazwy hostów aktualne
  [ ] Wszystkie oczekiwane sekrety wymienione (bez wartości)
  [ ] Wszystkie dozwolone zmienne NEXT_PUBLIC wymienione
  [ ] Wszystkie pliki z dozwolonym service_role wymienione
  [ ] Wyjątki RLS udokumentowane (z uzasadnieniem)
  [ ] Reguły compliance (CLOUD Act, Data Residency) zdefiniowane

Skrypt kontrolny
  [ ] check-baseline.sh wykonywalny na audit-runner
  [ ] Klucz SSH z audit-runner do serwera produkcyjnego skonfigurowany
  [ ] Baseline firewalla zapisana (/opt/baselines/)
  [ ] Codzienny Cron Job aktywny
  [ ] Wysyłanie alertów skonfigurowane (e-mail przy KRYTYCZNYCH)

Integracja
  [ ] Claude Code zainstalowany na audit-runner
  [ ] Cotygodniowy Cron audytu aktywny
  [ ] CLAUDE.md obecny w repozytorium (artykuł 5)
  [ ] .claude/commands/security-review.md obecny (artykuł 5)
  [ ] Raporty są archiwizowane (/opt/audit/reports/)
```

## Podsumowanie

Security Baseline jest elementem łączącym całą serię runbooków. Artykuły 1-4 definiują, co musi być bezpiecznie skonfigurowane. Artykuł 5 definiuje, jak Claude Code weryfikuje te reguły. Artykuł 6 scala wszystko w jednym pliku YAML, który jest odczytywalny zarówno przez skrypty, jak i przez Claude Code.

Codzienna kontrola Baseline dostarcza fakty: zaliczony lub niezaliczony. Cotygodniowy audyt Claude Code interpretuje te fakty w kontekście. Człowiek decyduje, co priorytetyzować. Ten trójwarstwowy model pokrywa zarówno znane, jak i nieoczekiwane ryzyka, bez obciążania jednej warstwy wyłączną odpowiedzialnością za bezpieczeństwo.

> **Statystyka:** Organizacje stosujące automatyczne kontrole baseline wykrywają dryft konfiguracji średnio 11 razy szybciej niż te polegające na audytach ręcznych (raport Puppet State of DevOps 2024).


Kto stosuje tę Baseline razem z architekturą [Cert-Ready by Design](/pl/magazyn/cert-ready-by-design/), buduje weryfikowalne bezpieczeństwo zamiast audytów po fakcie.

Tym samym **seria runbooków DevOps jest kompletna**.

<div class="not-prose my-12 border border-gosign-border bg-gosign-light rounded-card p-6 lg:p-8">
<div class="flex items-start gap-4">
<div class="flex-shrink-0 w-12 h-12 bg-gosign-dark rounded-card flex items-center justify-center">
<svg width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="white" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 15v4a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2v-4"/><polyline points="7 10 12 15 17 10"/><line x1="12" y1="15" x2="12" y2="3"/></svg>
</div>
<div>
<h2 class="text-h3 font-bold text-gosign-dark mb-2" id="listy-kontrolne-audytu-serii">Listy kontrolne audytu serii</h2>
<p class="text-body text-gosign-text mb-4">Przygotowane prompty dla Claude Code. Każda lista kontrolna automatycznie weryfikuje punkty bezpieczeństwa danego runbooka i zgłasza ZALICZONY, OSTRZEŻENIE lub KRYTYCZNY.</p>
<div class="flex flex-wrap gap-3">
<a href="/downloads/claude-check-artikel-1-supabase-pl.md" download class="inline-flex items-center px-4 py-2 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-sm">Supabase Infrastructure</a>
<a href="/downloads/claude-check-artikel-2-nextjs-pl.md" download class="inline-flex items-center px-4 py-2 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-sm">Next.js Security</a>
<a href="/downloads/claude-check-artikel-3-edge-functions-pl.md" download class="inline-flex items-center px-4 py-2 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-sm">Edge Functions</a>
<a href="/downloads/claude-check-artikel-4-trigger-dev-pl.md" download class="inline-flex items-center px-4 py-2 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-sm">Trigger.dev</a>
</div>
</div>
</div>
</div>

## Spis treści serii

1. [Supabase Self-Hosting Runbook](/pl/magazyn/supabase-self-hosting/)
2. [Next.js nad Supabase - bezpieczna eksploatacja](/pl/magazyn/nextjs-supabase-bezpieczna-konfiguracja/)
3. [Supabase Edge Functions - bezpieczne wdrożenie](/pl/magazyn/supabase-edge-functions-bezpieczenstwo/)
4. [Trigger.dev Background Jobs - bezpieczna eksploatacja](/pl/magazyn/trigger-dev-background-jobs/)
5. [Claude Code jako kontrola bezpieczeństwa w workflow DevOps](/pl/magazyn/claude-code-security-devops/)
6. [Security Baseline dla całego stacku](/pl/magazyn/security-baseline-stack/) - ten artykuł

--- Seria DevOps Runbook: bezpieczeństwo self-hosted stacku ---
> Sześcioczęściowa seria DevOps Runbook: Supabase, Next.js, Edge Functions, Trigger.dev, audyty Claude Code i Security Baseline.

Ta seria dostarcza sześć praktycznych runbooków do bezpiecznej eksploatacji self-hosted stacku aplikacyjnego. Jest skierowana do zespołów DevOps, które eksploatują Supabase, Next.js i pokrewne technologie w produkcji i chcą systematycznie zabezpieczyć swoją infrastrukturę.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">W skrócie - Seria DevOps Runbook</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Sześć runbooków obejmuje kompletny self-hosted stack: Supabase, Next.js, Edge Functions, Trigger.dev, audyty Claude Code i Security Baseline.</li>
<li>Każdy artykuł zawiera konkretne implementacje z prawdziwym kodem, weryfikowalne warunki i listy kontrolne Claude Code do pobrania.</li>
<li>Seria buduje się warstwa po warstwie - od fundamentu platformy (Supabase) po maszynowo czytelną YAML-ową baseline dla całego stacku.</li>
<li>Grupa docelowa: inżynierowie DevOps, CTO, inżynierowie bezpieczeństwa i deweloperzy budujący na Supabase i Next.js.</li>
<li>Według SANS Institute (2024), organizacje z maszynowo czytelną Security Baseline wykrywają dryft konfiguracji 14 razy szybciej.</li>
</ul>
</div>

## Dlaczego systematyczne podejście ma znaczenie

Self-hosting daje kontrolę nad danymi i infrastrukturą. Ta kontrola wiąże się z odpowiedzialnością: każdy komponent ma własne wymagania bezpieczeństwa, a zależności między warstwami pozostają niewidoczne przy izolowanym przeglądzie.

Systematyczne, maszynowo czytelne podejście do bezpieczeństwa na wszystkich warstwach robi różnicę. Według SANS Institute (2024), organizacje z maszynowo czytelną Security Baseline wykrywają dryft konfiguracji średnio **14 razy szybciej** niż zespoły bez baseline.

Ta seria prowadzi przez stack warstwa po warstwie i kończy się YAML-ową baseline, która konsoliduje wszystkie reguły z poszczególnych runbooków.

## Przegląd serii

| Część | Artykuł | Obszar | Główny rezultat |
|-------|---------|--------|-----------------|
| 1 | [Supabase Self-Hosting Runbook](/pl/magazyn/supabase-self-hosting/) | Fundament platformy | Architektura serwerów, Docker Compose, RLS |
| 2 | [Next.js nad Supabase - bezpieczna eksploatacja](/pl/magazyn/nextjs-supabase-bezpieczna-konfiguracja/) | Warstwa aplikacji | Auth, Middleware, separacja środowisk |
| 3 | [Supabase Edge Functions - bezpieczne wdrożenie](/pl/magazyn/supabase-edge-functions-bezpieczenstwo/) | Integracje | Webhooki, sygnatury, CORS |
| 4 | [Bezpieczna obsługa Trigger.dev Background Jobs](/pl/magazyn/trigger-dev-background-jobs/) | Przetwarzanie async | Taski, idempotencja, concurrency |
| 5 | [Claude Code jako kontrola bezpieczeństwa w DevOps](/pl/magazyn/claude-code-security-devops/) | Automatyczne audyty | Custom commands, tryb headless |
| 6 | [Security Baseline dla całego stacku](/pl/magazyn/security-baseline-stack/) | Baseline pełnego stacku | YAML, automatyczne kontrole |

## Artykuły w szczegółach

**Część 1 - Supabase Self-Hosting Runbook.** Opisuje architekturę dwuserwerową (produkcja i audyt), Docker Compose z wersjonowanymi obrazami, konfigurację siedmiu usług oraz Row Level Security jako wymóg na wszystkich publicznych tabelach.

**Część 2 - Next.js nad Supabase.** Obejmuje warstwę aplikacji na Supabase: flow autoryzacji z PKCE, middleware do ochrony tras, ścisłą separację środowisk między serwerem a klientem oraz bezpieczne wzorce API route.

**Część 3 - Edge Functions.** Skupia się na przetwarzaniu webhooków z weryfikacją sygnatur, konfiguracji CORS, walidacji danych wejściowych w runtime Deno oraz bezpiecznym zarządzaniu sekretami dla integracji z zewnętrznymi usługami.

**Część 4 - Trigger.dev Background Jobs.** Opisuje self-hosted setup Trigger.dev v3, idempotentną definicję tasków, kontrolę concurrency, strategie ponownych prób oraz izolację sekretów między taskami.

**Część 5 - Claude Code jako kontrola bezpieczeństwa.** Pokazuje, jak używać Claude Code jako automatycznego narzędzia audytowego w workflow DevOps: custom commands, headless audit runs i integracja z CI.

**Część 6 - Security Baseline.** Konsoliduje wszystkie reguły z artykułów 1 do 5 w maszynowo czytelnym pliku `security-baseline.yml`. Zawiera deterministyczne skrypty kontrolne i integrację z audytem Claude Code.

## Dla kogo jest ta seria

- Inżynierowie DevOps eksploatujący self-hosted infrastrukturę
- CTO i liderzy techniczni oceniający self-hosting vs. usługi zarządzane
- Inżynierowie bezpieczeństwa audytujący stacki aplikacyjne
- Deweloperzy budujący na Supabase i Next.js

## Jak korzystać z serii

- Czytaj artykuły po kolei od 1 do 6, ponieważ bazują na sobie nawzajem
- Pobierz listy kontrolne Claude Code na końcu każdego artykułu
- Implementuj zalecenia warstwa po warstwie w swoim środowisku
- Używaj Security Baseline z artykułu 6 jako codziennej bramki monitoringowej

--- Shadow AI w firmie - governance zamiast zakazu ---
> Niekontrolowane korzystanie z AI (Shadow AI) to problem governance. Rozwiązaniem jest kontrolowana infrastruktura z Audit Trail i Model Routing.

## Czym jest Shadow AI?

Shadow AI to odpowiednik Shadow IT w świecie AI. Pracownicy używają ChatGPT, Google Gemini, Microsoft CoPilot lub innych narzędzi AI do pracy - bez wiedzy, zgody czy kontroli działu IT.

Pracownik, który wpisuje reklamację klienta w ChatGPT, żeby sformułować odpowiedź. Specjalistka HR, która tworzy referencje przez CoPilot. Kontroler, który analizuje wyniki kwartalne w Gemini. Każde takie użycie wysyła dane firmowe do zewnętrznego serwisu.

Shadow AI nie jest złośliwe. Pracownicy używają narzędzi AI, bo stają się bardziej produktywni. Ale bez governance organizacja nie ma kontroli nad tym, jakie dane opuszczają firmę, jakie modele są używane i czy wyniki są możliwe do prześledzenia.

W Polsce ten problem jest szczególnie istotny, ponieważ RODO (które obowiązuje bezpośrednio) i Ustawa o ochronie danych osobowych nakładają na pracodawców obowiązek zapewnienia bezpieczeństwa przetwarzania danych. UODO (Urząd Ochrony Danych Osobowych) może nakładać kary za naruszenia związane z niekontrolowanym przetwarzaniem danych osobowych w zewnętrznych systemach AI.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">W skrócie - Shadow AI Governance</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Shadow AI oznacza, że pracownicy korzystają z zewnętrznych narzędzi AI bez wiedzy IT - dane firmowe trafiają do niekontrolowanych systemów.</li>
<li>Zakazy nie działają - pracownicy korzystają z prywatnych urządzeń i alternatywnych narzędzi. Zakaz tworzy niekontrolowane obejście.</li>
<li>PwC (2024) stwierdził, że w 54% firm pracownicy korzystają z generatywnych narzędzi AI bez formalnej zgody organizacji.</li>
<li>Rozwiązaniem jest kontrolowana infrastruktura: firmowy interfejs AI, Model Routing, protokół użycia i Audit Trail.</li>
<li>Trzy fazy: inwentaryzacja bieżącego użycia, wdrożenie kontrolowanej infrastruktury, następnie wyspecjalizowani agenci dla częstych przypadków użycia.</li>
</ul>
</div>

## Dlaczego zakazy nie działają

Naturalna reakcja na Shadow AI to zakaz. Wiele firm zablokowało ChatGPT i podobne narzędzia - przez reguły firewall, polityki, porozumienia zakładowe.

Problem: zakazy nie działają. Pracownicy korzystają z prywatnych smartfonów. Używają rozszerzeń przeglądarki. Korzystają z alternatywnych narzędzi, które jeszcze nie są na liście blokad. Zakaz nie tworzy zgodności - tworzy niekontrolowane obejście.

Jednocześnie firma traci korzyść produktywności, którą AI może zaoferować. Podczas gdy pracownicy ukrywają korzystanie z AI, dział IT nie może ani wspierać, ani sterować, ani optymalizować.

## Alternatywa: kontrolowana infrastruktura AI

Rozwiązaniem nie jest zakaz, lecz infrastruktura. Własna infrastruktura AI daje pracownikom wydajne narzędzia AI - pod kontrolą organizacji.

**Własny interfejs AI firmy:** Zamiast ChatGPT pracownicy korzystają z wewnętrznego interfejsu czatu podłączonego do firmowych modeli. Doświadczenie użytkownika jest identyczne. Różnica: wszystkie dane pozostają we własnej infrastrukturze.

**Model Routing:** Dział IT decyduje, jakie modele są stosowane do jakich przypadków użycia. Wrażliwe dane trafiają do modeli self-hosted. Niekrytyczne zapytania mogą być kierowane do modeli chmurowych. Decyzja jest oparta na regułach i prześledzalna.

**Protokół użycia:** Każda interakcja z AI jest protokołowana - nie po to, by monitorować pracowników, lecz by sterować wykorzystaniem AI. Które działy korzystają z AI najczęściej? Do jakich zadań? Z jakimi modelami? Te dane stanowią podstawę następnego kroku: wyspecjalizowani agenci dla najczęstszych przypadków użycia.

**Audit Trail:** W regulowanych obszarach - finanse, HR, compliance - każda decyzja wspierana przez AI jest dokumentowana w Audit Trail. Decision Layer zapewnia, że procesy krytyczne dla biznesu nie opierają się na niekontrolowanych wynikach AI.

## Od Shadow AI do Governance by Design

Shadow AI to symptom. Przyczyna to brak infrastruktury. Gdy pracownicy nie mają kontrolowanych narzędzi AI, korzystają z niekontrolowanych.

| Faza | Zakres | Kluczowe rezultaty |
|------|--------|-------------------|
| 1 - Inwentaryzacja | Mapowanie bieżącego użycia AI we wszystkich działach | Inwentarz narzędzi, analiza przepływu danych, klasyfikacja ryzyka |
| 2 - Kontrolowana infrastruktura | Firmowa platforma AI z governance | Hosting LLM, interfejs czatu, Model Routing, protokół użycia |
| 3 - Wyspecjalizowani agenci | Dedykowani agenci dla częstych przypadków użycia | Document Agent, Knowledge Agent, Workflow Agent - każdy z Decision Layer |

Ścieżka od Shadow AI do Governance by Design:

**Faza 1: Inwentaryzacja.** Jakie narzędzia AI są używane w firmie? Do jakich zadań? Z jakimi danymi? Ta inwentaryzacja jest często otrzeźwiająca - rzeczywiste korzystanie z AI znacznie przewyższa oficjalne.

**Faza 2: Kontrolowana infrastruktura.** Budowa własnej infrastruktury AI. Hosting LLM, interfejs czatu, Model Routing, protokół użycia. Pracownicy otrzymują narzędzie co najmniej tak wydajne jak ChatGPT - ale pod kontrolą IT.

**Faza 3: Wyspecjalizowani agenci.** Z najczęstszych przypadków użycia tworzą się wyspecjalizowanych agentów. Zamiast generycznego czatu jest Document Agent do przetwarzania dokumentów, Knowledge Agent do pytań HR, Workflow Agent do przetwarzania faktur. Każdy agent z Decision Layer i governance.

## Ryzyko braku działania

Shadow AI nie zniknie. Narzędzia AI stają się lepsze, łatwiej dostępne, głębiej zintegrowane z istniejącym oprogramowaniem. Każda aktualizacja Office przynosi nowe funkcje AI. Każda przeglądarka ma funkcje AI.

Firmy, które nie budują kontrolowanej infrastruktury AI, stwierdzą, że ich pracownicy już dawno korzystają z AI - bez governance, bez Audit Trail, bez analizy RODO. Pytanie nie brzmi, czy to stanie się problemem, ale kiedy. Przy następnej kontroli skarbowej. Przy następnym zapytaniu RODO od UODO. Przy następnym wycieku danych.

Więcej na ten temat: [Infrastruktura AI](/pl/uslugi/infrastruktura/)

Szczegóły dotyczące [Decision Layer i Shadow AI](/pl/magazyn/decision-layer-shadow-ai/).

<a href="/pl/kontakt/" target="_blank" rel="noopener noreferrer">Umów spotkanie</a> - Pokażemy, jak Shadow AI przekształcić w kontrolowaną infrastrukturę AI.

--- Supabase Edge Functions - bezpieczne wdrożenie ---
> Runbook DevOps dla Supabase Edge Functions: webhooki, sygnatury, CORS, Deno runtime, walidacja danych i integracja z Claude Code.

Supabase Edge Functions to serwerowe funkcje TypeScript działające w runtime Deno, dostępne przez Kong API Gateway.

Szczególnie dobrze nadają się do obsługi webhooków, integracji z zewnętrznymi API, sygnowanych endpointów zdarzeń i lekkiej logiki serwerowej.

Najczęstszym błędem jest wykorzystywanie Edge Functions jako **drugiego systemu backendowego**. Prowadzi to do podwójnej logiki biznesowej, niejasnych granic bezpieczeństwa i architektur trudnych do debugowania.

Ten runbook opisuje, jak bezpiecznie wdrażać Edge Functions w [setup self-hosted](/pl/magazyn/supabase-self-hosting/). Każdy krok zawiera konkretną implementację z rzeczywistym kodem Deno, sprawdzalny warunek i scenariusz awarii.

> **Uwaga dotycząca runtime:** Supabase Edge Functions bazują na **Deno**, a nie na Node.js. Dotyczy to składni importów, systemu modułów i dostępnych API. Wszystkie przykłady kodu w tym artykule są kompatybilne z Deno. Self-hosted Edge Functions działają w kontenerze `supabase/edge-runtime` i są obecnie oznaczone jako wersja beta.


<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">W skrócie - Artykuł 3 z 6 serii DevOps Runbook</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Edge Functions tylko jako punkty integracyjne (webhooki), nie drugi backend</li>
<li>Obowiązkowa weryfikacja sygnatur webhooków</li>
<li>CORS skonfigurowany jawnie (bez wildcard)</li>
<li>Walidacja danych wejściowych z Zod</li>
<li>Zadania długotrwałe delegowane do Trigger.dev</li>
</ul>
</div>

## Spis treści serii

Ten przewodnik jest częścią naszej serii runbooków DevOps dla self-hosted stacków aplikacyjnych.

1. [Supabase Self-Hosting Runbook](/pl/magazyn/supabase-self-hosting/)
2. [Next.js nad Supabase - bezpieczna eksploatacja](/pl/magazyn/nextjs-supabase-bezpieczna-konfiguracja/)
3. [Supabase Edge Functions - bezpieczne wdrożenie](/pl/magazyn/supabase-edge-functions-bezpieczenstwo/) ← ten artykuł
4. [Bezpieczna obsługa Trigger.dev Background Jobs](/pl/magazyn/trigger-dev-background-jobs/)
5. [Claude Code jako kontrola bezpieczeństwa w DevOps](/pl/magazyn/claude-code-security-devops/)
6. [Security Baseline dla całego stacku](/pl/magazyn/security-baseline-stack/)

Artykuł 1 opisuje platformę.
Artykuł 2 opisuje warstwę aplikacyjną Next.js.
Ten artykuł opisuje **integracje i webhooki**.

## Przegląd architektury

```
Browser
   |
Next.js (warstwa aplikacyjna)
   |
   +-- Supabase Client (anon key)     -> dla żądań użytkowników
   |
Kong API Gateway
   |
   +-- PostgREST                       -> REST API z RLS
   +-- GoTrue                          -> Auth
   +-- Edge Runtime                    -> Edge Functions
   |     |
   |     +-- stripe-webhook
   |     +-- github-webhook
   |     +-- trigger-webhook
   |
PostgreSQL + RLS Policies

Usługi zewnętrzne
   |
   +-- Stripe / GitHub / Trigger.dev   -> wywołują webhooki
```

Podstawowa zasada:

```
Edge Functions to punkty integracyjne dla zewnętrznych zdarzeń.
Logika biznesowa należy do [Next.js](/pl/magazyn/nextjs-supabase-bezpieczna-konfiguracja/) (Server Actions / Route Handler).
Zadania długotrwałe należą do Trigger.dev.
```


### Tabela decyzyjna

| Kryterium | Edge Function | Server Action | Trigger.dev Task |
|---|---|---|---|
| Źródło | Zewnętrzne zdarzenie (webhook) | Dane wejściowe użytkownika | Zadanie wewnętrzne |
| Czas wykonania | < 30 sekund | < 10 sekund | Do 5 minut+ |
| Uwierzytelnianie | Sygnatura HMAC | Sesja użytkownika (JWT) | Klucz API / service_role |
| RLS | Omijany (service_role) | Aktywny (anon key) | Omijany (service_role) |
| Retry | Dostawca webhook | Brak (synchronicznie) | Wbudowany (Trigger.dev) |
| Przykład | Stripe checkout webhook | Formularz profilu | Generowanie PDF |

### Kryterium decyzyjne

Jeśli funkcja reaguje na **zewnętrzne zdarzenie** (płatność Stripe, push GitHub, callback Trigger.dev), jest Edge Function. Jeśli reaguje na **dane wejściowe użytkownika** i transformuje dane, należy do Next.js. Jeśli **trwa dłużej niż 30 sekund**, należy do Trigger.dev.

## Jak działają Edge Functions w setup self-hosted

W self-hosted stacku Docker Compose konfiguracja Edge Functions wygląda następująco:

```yaml
# docker-compose.yml (fragment)
functions:
  container_name: supabase-edge-functions
  image: supabase/edge-runtime:v1.66.4    # wersja przypięta
  restart: unless-stopped
  depends_on:
    - analytics
  environment:
    JWT_SECRET: ${JWT_SECRET}
    SUPABASE_URL: http://kong:8000                    # wewnętrzny hostname Docker
    SUPABASE_ANON_KEY: ${ANON_KEY}
    SUPABASE_SERVICE_ROLE_KEY: ${SERVICE_ROLE_KEY}
    SUPABASE_DB_URL: postgresql://postgres:${POSTGRES_PASSWORD}@${POSTGRES_HOST}:${POSTGRES_PORT}/${POSTGRES_DB}
    VERIFY_JWT: "${FUNCTIONS_VERIFY_JWT}"
  volumes:
    - ./volumes/functions:/home/deno/functions:Z
  command:
    - start
    - --main-service
    - /home/deno/functions/main
```

Edge Functions to pliki TypeScript w wolumenie:

```
volumes/functions/
  main/
    index.ts              <- Router / Main Service
  _shared/
    cors.ts               <- CORS Headers (shared)
    supabase-client.ts    <- Supabase Client Factory (shared)
  stripe-webhook/
    index.ts
  github-webhook/
    index.ts
```

**Deployment w setup self-hosted:** Funkcje umieszcza się jako pliki w wolumenie i restartuje kontener:

```bash
# Kopiowanie funkcji do wolumenu
cp -r supabase/functions/* /opt/supabase/volumes/functions/

# Restart kontenera
docker compose restart functions --no-deps
```

## Część A - Decyzje architektoniczne

Te decyzje podejmowane są raz i rzadko ulegają zmianom.

## A1 - Edge Functions tylko do integracji, nie jako drugi backend

### Implementacja

Jasne przypisanie, jaka logika trafia gdzie:

```
Edge Functions (Deno):
  Odbiór webhooków (Stripe, GitHub, zewnętrzne API)
  Synchronizacja oparta na zdarzeniach (DB Webhook -> usługa zewnętrzna)
  Weryfikacja sygnatur przychodzących zdarzeń
  Lekkie transformacje (< 30 sekund)

Next.js (Server Actions / Route Handler):
  Mutacje skierowane do użytkownika (CRUD)
  Operacje oparte na sesji
  Logika biznesowa
  Walidacja danych z kontekstem użytkownika

Trigger.dev (Background Jobs):
  Generowanie PDF
  Zadania AI
  Masowa wysyłka e-mail
  Wszystko powyżej 30 sekund czasu wykonania
```

### Sprawdzalny warunek

```bash
# Ile jest Edge Functions?
ls -d volumes/functions/*/ | grep -v "main\|_shared" | wc -l

# Dla każdej funkcji sprawdź: czy to integracja?
for dir in volumes/functions/*/; do
  name=$(basename "$dir")
  [[ "$name" == "main" || "$name" == "_shared" ]] && continue
  echo "--- $name ---"
  # Czy zawiera wzorce Webhook/Integration?
  grep -l "signature\|webhook\|stripe\|github\|trigger" "$dir"*.ts 2>/dev/null || \
    echo "OSTRZEŻENIE: nie znaleziono wzorców Webhook/Integration"
done
```

### Scenariusz awarii

Jeśli logika biznesowa zostanie zaimplementowana w Edge Functions, powstaje architektura-cień: ta sama walidacja istnieje w Next.js Server Actions ORAZ w Edge Functions, z subtelnymi różnicami. Błędy stają się trudne do odtworzenia, ponieważ nie jest jasne, która ścieżka kodu była aktywna. Logika autentykacji musi być utrzymywana w dwóch miejscach.

## A2 - Izolowanie endpointów webhookowych: jedna funkcja na webhook

### Implementacja

Każdy dostawca webhooków otrzymuje własną funkcję w osobnym katalogu:

```
volumes/functions/
  stripe-webhook/
    index.ts
  github-webhook/
    index.ts
  trigger-webhook/
    index.ts
```

**Nie tak:**

```
volumes/functions/
  webhooks/
    index.ts     <- obsługuje Stripe, GitHub i Trigger w jednym pliku
```

### Sprawdzalny warunek

```bash
# Każda funkcja webhookowa powinna obsługiwać dokładnie jednego dostawcę
for dir in volumes/functions/*-webhook/; do
  name=$(basename "$dir")
  providers=$(grep -ciE "stripe|github|trigger|slack|sendgrid" "$dir/index.ts")
  if [ "$providers" -gt 1 ]; then
    echo "OSTRZEŻENIE: $name obsługuje wielu dostawców ($providers)"
  fi
done
```

### Scenariusz awarii

Gdy wiele webhooków jest przetwarzanych w jednej funkcji, współdzielą ten sam Error Handler. Wadliwy payload Stripe może zablokować webhook GitHub. Strategie ponawiania różnią się w zależności od dostawcy (Stripe ponawia z exponential backoff, GitHub tylko 3x), co trudno czysto zaimplementować we wspólnej funkcji.

## A3 - Poprawna konfiguracja CORS

### Implementacja

Edge Functions wywoływane z przeglądarki (także pośrednio) potrzebują nagłówków CORS. Supabase nie zapewnia automatycznej konfiguracji CORS dla Edge Functions.

Wspólna konfiguracja CORS:

```typescript
// volumes/functions/_shared/cors.ts

const allowedOrigins = [
  'https://app.example.com',
  ...(Deno.env.get('ENVIRONMENT') === 'development'
    ? ['http://localhost:3000']
    : [])
]

export function getCorsHeaders(req: Request) {
  const origin = req.headers.get('origin') ?? ''
  const corsOrigin = allowedOrigins.includes(origin) ? origin : ''

  return {
    'Access-Control-Allow-Origin': corsOrigin,
    'Access-Control-Allow-Headers':
      'authorization, x-client-info, apikey, content-type',
    'Access-Control-Allow-Methods': 'POST, GET, OPTIONS',
  }
}
```

**Każda Edge Function** musi obsługiwać CORS na początku:

```typescript
import { getCorsHeaders } from '../_shared/cors.ts'

Deno.serve(async (req) => {
  const corsHeaders = getCorsHeaders(req)

  // CORS Preflight musi być PIERWSZYM sprawdzeniem
  if (req.method === 'OPTIONS') {
    return new Response('ok', { headers: corsHeaders })
  }

  // ... właściwa logika

  return new Response(JSON.stringify(data), {
    headers: { ...corsHeaders, 'Content-Type': 'application/json' },
  })
})
```

### Sprawdzalny warunek

```bash
# Wszystkie funkcje muszą obsługiwać CORS
for dir in volumes/functions/*/; do
  name=$(basename "$dir")
  [[ "$name" == "main" || "$name" == "_shared" ]] && continue
  if ! grep -q "OPTIONS" "$dir/index.ts" 2>/dev/null; then
    echo "OSTRZEŻENIE: $name nie ma handlera OPTIONS"
  fi
done

# Brak wildcard CORS w produkcji
grep -r "'\\*'" volumes/functions/ --include="*.ts" | grep -i "allow-origin"
# Oczekiwanie: brak wyników (chyba że w branchach developerskich)
```

### Scenariusz awarii

Bez nagłówków CORS wszystkie żądania z przeglądarki do Edge Functions zawiodą. Przeglądarka zablokuje odpowiedź, nawet jeśli funkcja odpowiedziała poprawnie. Objawia się to jako kryptyczny błąd CORS w konsoli. Z wildcard CORS (`'*'`) w produkcji dowolna strona może wysyłać żądania do Edge Functions i odczytywać odpowiedzi.

## Część B - Kontrole implementacyjne

Te kontrole obowiązują dla każdej Edge Function i muszą być weryfikowane przy każdym deploymencie.

## B1 - Weryfikacja sygnatur webhooków

### Implementacja

Każdy endpoint webhookowy musi weryfikować sygnaturę usługi wysyłającej. Bez weryfikacji sygnatury dowolna osoba może wysyłać dowolne payloady do funkcji.

**Kompletny przykład Stripe Webhook:**

```typescript
// volumes/functions/stripe-webhook/index.ts

import { getCorsHeaders } from '../_shared/cors.ts'

const STRIPE_WEBHOOK_SECRET = Deno.env.get('STRIPE_WEBHOOK_SECRET')

Deno.serve(async (req) => {
  const corsHeaders = getCorsHeaders(req)

  if (req.method === 'OPTIONS') {
    return new Response('ok', { headers: corsHeaders })
  }

  // 1. Tylko POST dozwolony
  if (req.method !== 'POST') {
    return new Response(
      JSON.stringify({ error: 'Method not allowed' }),
      { status: 405, headers: { ...corsHeaders, 'Content-Type': 'application/json' } }
    )
  }

  // 2. Weryfikacja sygnatury
  const signature = req.headers.get('stripe-signature')
  if (!signature) {
    return new Response(
      JSON.stringify({ error: 'Missing signature' }),
      { status: 401, headers: { ...corsHeaders, 'Content-Type': 'application/json' } }
    )
  }

  const body = await req.text()

  const isValid = await verifyStripeSignature(body, signature, STRIPE_WEBHOOK_SECRET!)
  if (!isValid) {
    return new Response(
      JSON.stringify({ error: 'Invalid signature' }),
      { status: 401, headers: { ...corsHeaders, 'Content-Type': 'application/json' } }
    )
  }

  // 3. Przetwarzanie zdarzenia
  const event = JSON.parse(body)

  switch (event.type) {
    case 'checkout.session.completed':
      await handleCheckoutCompleted(event.data.object)
      break
    case 'invoice.payment_failed':
      await handlePaymentFailed(event.data.object)
      break
    default:
      // Nieznane zdarzenia ignorujemy, nie powodujemy błędu
      console.log(`Unhandled event type: ${event.type}`)
  }

  // 4. Zawsze zwracamy 200 (Stripe ponawia w przeciwnym razie)
  return new Response(
    JSON.stringify({ received: true }),
    { status: 200, headers: { ...corsHeaders, 'Content-Type': 'application/json' } }
  )
})

// Weryfikacja sygnatury Stripe za pomocą Deno Crypto API
async function verifyStripeSignature(
  payload: string,
  header: string,
  secret: string
): Promise<boolean> {
  const parts = header.split(',')
  const timestamp = parts.find(p => p.startsWith('t='))?.split('=')[1]
  const signature = parts.find(p => p.startsWith('v1='))?.split('=')[1]

  if (!timestamp || !signature) return false

  // Sprawdzenie czasu: odrzucamy zdarzenia starsze niż 5 minut
  const now = Math.floor(Date.now() / 1000)
  if (now - parseInt(timestamp) > 300) return false

  const signedPayload = `${timestamp}.${payload}`
  const key = await crypto.subtle.importKey(
    'raw',
    new TextEncoder().encode(secret),
    { name: 'HMAC', hash: 'SHA-256' },
    false,
    ['sign']
  )

  const sig = await crypto.subtle.sign(
    'HMAC',
    key,
    new TextEncoder().encode(signedPayload)
  )

  const expectedSig = Array.from(new Uint8Array(sig))
    .map(b => b.toString(16).padStart(2, '0'))
    .join('')

  return expectedSig === signature
}

async function handleCheckoutCompleted(session: Record<string, unknown>) {
  console.log(`Checkout completed: ${session.id}`)
}

async function handlePaymentFailed(invoice: Record<string, unknown>) {
  console.log(`Payment failed: ${invoice.id}`)
}
```

**Weryfikacja sygnatury GitHub Webhook (inny mechanizm):**

```typescript
// volumes/functions/github-webhook/index.ts

const GITHUB_WEBHOOK_SECRET = Deno.env.get('GITHUB_WEBHOOK_SECRET')

async function verifyGitHubSignature(
  payload: string,
  signatureHeader: string,
  secret: string
): Promise<boolean> {
  // GitHub używa sha256=<hex>
  const expected = signatureHeader.replace('sha256=', '')

  const key = await crypto.subtle.importKey(
    'raw',
    new TextEncoder().encode(secret),
    { name: 'HMAC', hash: 'SHA-256' },
    false,
    ['sign']
  )

  const sig = await crypto.subtle.sign(
    'HMAC',
    key,
    new TextEncoder().encode(payload)
  )

  const computed = Array.from(new Uint8Array(sig))
    .map(b => b.toString(16).padStart(2, '0'))
    .join('')

  return computed === expected
}
```

### Sprawdzalny warunek

```bash
# Każda funkcja webhookowa musi mieć weryfikację sygnatury
for dir in volumes/functions/*-webhook/; do
  name=$(basename "$dir")
  if ! grep -qE "signature|verify|hmac" "$dir/index.ts" 2>/dev/null; then
    echo "KRYTYCZNE: $name nie ma weryfikacji sygnatury"
  else
    echo "OK: $name weryfikuje sygnatury"
  fi
done

# Sprawdzenie ustawienia VERIFY_JWT
# Webhooki potrzebują VERIFY_JWT=false, ponieważ zewnętrzne usługi nie wysyłają JWT Supabase
grep "VERIFY_JWT" .env
```

### Scenariusz awarii

Bez weryfikacji sygnatury atakujący może wysyłać dowolne zdarzenia do webhooka:

> **Statystyka:** Zgodnie z danymi Stripe ponad 12% integracji webhookowych nie weryfikuje sygnatur - co czyni je podatnymi na sfałszowane zdarzenia.


```bash
curl -X POST https://app.example.com/functions/v1/stripe-webhook \
  -H "Content-Type: application/json" \
  -d '{"type":"checkout.session.completed","data":{"object":{"customer":"cus_fake"}}}'
```

To żądanie spowodowałoby sfałszowane potwierdzenie płatności. Funkcja zaktualizowałaby status użytkownika, mimo że faktycznie nie doszło do zapłaty.

## B2 - Poprawna inicjalizacja klienta Supabase (anon vs. service_role)

### Implementacja

Edge Functions mają dostęp do wszystkich zmiennych środowiskowych Supabase. Wybór między kluczem `anon` a kluczem `service_role` to najważniejsza decyzja bezpieczeństwa dla każdej funkcji.

**Współdzielona fabryka klientów:**

```typescript
// volumes/functions/_shared/supabase-client.ts

import { createClient, SupabaseClient } from 'npm:@supabase/supabase-js@2'

// Klient Z RLS (dla operacji w kontekście użytkownika)
export function createAnonClient(authHeader?: string): SupabaseClient {
  const client = createClient(
    Deno.env.get('SUPABASE_URL')!,
    Deno.env.get('SUPABASE_ANON_KEY')!,
    {
      global: {
        headers: authHeader ? { Authorization: authHeader } : {},
      },
    }
  )
  return client
}

// Klient BEZ RLS (dla przetwarzania webhooków, zadań administracyjnych)
// UWAGA: Omija wszystkie Row Level Security Policies
export function createAdminClient(): SupabaseClient {
  return createClient(
    Deno.env.get('SUPABASE_URL')!,
    Deno.env.get('SUPABASE_SERVICE_ROLE_KEY')!
  )
}
```

**Kiedy jaki klient:**

```
createAnonClient(authHeader):
  Funkcje skierowane do użytkownika (rzadko, zwykle należą do Next.js)
  Gdy RLS powinien kontrolować dostęp

createAdminClient():
  Przetwarzanie webhooków (Stripe, GitHub)
  Wewnętrzne zadania synchronizacji
  Gdy funkcja NIE ma kontekstu użytkownika

Zasada: Webhooki nie mają kontekstu użytkownika,
więc potrzebują service_role.
Ale: Wykonujemy tylko minimalne niezbędne operacje.
```

### Sprawdzalny warunek

```bash
# Gdzie używany jest service_role / Admin Client?
grep -rn "SERVICE_ROLE\|createAdminClient\|service_role" \
  volumes/functions/ --include="*.ts" | grep -v "_shared/"

# Oczekiwanie: tylko w funkcjach webhookowych, nie w funkcjach skierowanych do użytkownika

# Czy Admin Client otrzymuje niezweryfikowane dane użytkownika?
# Ręczny przegląd: w każdej funkcji używającej createAdminClient
# sprawdzić czy dane wejściowe są walidowane przed operacją na bazie danych
```

### Scenariusz awarii

Jeśli Edge Function działa z `service_role` i przekazuje dane wejściowe użytkownika bezpośrednio do zapytań, całkowicie omija RLS. Zmanipulowany payload webhooka mógłby wtedy odczytywać lub zapisywać dowolne dane w dowolnych tabelach, ponieważ klucz `service_role` nie zna żadnych ograniczeń.

## B3 - Walidacja danych wejściowych

### Implementacja

Każda Edge Function musi walidować przychodzące dane przed ich przetworzeniem. W Deno Zod działa przez import npm:

```typescript
// volumes/functions/stripe-webhook/index.ts (fragment)

import { z } from 'npm:zod@3'

// Schemat dla oczekiwanego zdarzenia Stripe
const stripeEventSchema = z.object({
  id: z.string().startsWith('evt_'),
  type: z.string(),
  data: z.object({
    object: z.record(z.unknown()),
  }),
})

// W głównej funkcji po weryfikacji sygnatury:
const parsed = stripeEventSchema.safeParse(JSON.parse(body))

if (!parsed.success) {
  return new Response(
    JSON.stringify({ error: 'Invalid payload structure' }),
    { status: 400, headers: { ...corsHeaders, 'Content-Type': 'application/json' } }
  )
}

// Od tego momentu pracujemy z parsed.data (typowanie bezpieczne)
const event = parsed.data
```

### Sprawdzalny warunek

```bash
# Każda funkcja powinna mieć walidację danych wejściowych
for dir in volumes/functions/*/; do
  name=$(basename "$dir")
  [[ "$name" == "main" || "$name" == "_shared" ]] && continue
  if grep -qE "zod|safeParse|z\.object|z\.string" "$dir/index.ts" 2>/dev/null; then
    echo "OK: $name ma walidację schematu"
  elif grep -qE "JSON\.parse" "$dir/index.ts" 2>/dev/null; then
    echo "OSTRZEŻENIE: $name parsuje JSON bez walidacji schematu"
  fi
done
```

### Scenariusz awarii

Bez walidacji danych wejściowych funkcja akceptuje każdy payload z prawidłową sygnaturą. Skompromitowany klucz API u dostawcy webhooków mógłby wtedy wysyłać nieoczekiwane struktury danych, które prowadzą do niezdefiniowanych operacji bazodanowych, np. `undefined` jako ID użytkownika w operacji insert.

## B4 - Sekrety w zmiennych środowiskowych, nigdy w kodzie

### Implementacja

W setup self-hosted sekrety przekazywane są do Edge Functions przez konfigurację Docker Compose:

```yaml
# docker-compose.yml (fragment)
functions:
  environment:
    JWT_SECRET: ${JWT_SECRET}
    SUPABASE_URL: http://kong:8000
    SUPABASE_ANON_KEY: ${ANON_KEY}
    SUPABASE_SERVICE_ROLE_KEY: ${SERVICE_ROLE_KEY}
  env_file:
    - .env.functions    # dodatkowe sekrety dla Functions
```

```bash
# .env.functions (tylko na serwerze, nie w Git)
STRIPE_WEBHOOK_SECRET=whsec_...
STRIPE_SECRET_KEY=sk_live_...
GITHUB_WEBHOOK_SECRET=ghsec_...
TRIGGER_DEV_API_KEY=tr_...
```

Dostęp w kodzie:

```typescript
// Tak: zmienna środowiskowa
const secret = Deno.env.get('STRIPE_WEBHOOK_SECRET')

// NIGDY tak: na stałe w kodzie
const secret = 'whsec_abc123...'
```

Ogólne podstawy zarządzania sekretami opisano w artykule [Bezpieczeństwo danych w infrastrukturze AI dla przedsiębiorstw](/pl/magazyn/bezpieczenstwo-danych-ai-enterprise/).

### Sprawdzalny warunek

```bash
# Sekrety na stałe w kodzie?
grep -rn "sk_live\|sk_test\|whsec_\|ghsec_\|Bearer ey" \
  volumes/functions/ --include="*.ts"
# Oczekiwanie: brak wyników

# .env.functions nie jest w Git?
git ls-files .env.functions
# Oczekiwanie: pusty wynik

# Uprawnienia pliku poprawne?
stat -c "%a" .env.functions
# Oczekiwanie: 600
```

### Scenariusz awarii

Sekrety na stałe w kodzie źródłowym trafiają do repozytorium Git. Nawet jeśli repozytorium jest prywatne, wszyscy deweloperzy z dostępem do repo mają również dostęp do sekretów produkcyjnych. Przy przypadkowym upublicznieniu repozytorium sekrety są natychmiast skompromitowane.

## B5 - Unikanie timeoutów i zadań długotrwałych

### Implementacja

Edge Functions są zaprojektowane do krótkich, idempotentnych operacji. Self-hosted Edge Runtime ma domyślny timeout (konfigurowalny, typowo 60 sekund dla self-hosted). Zadania długotrwałe blokują sloty workerów.

```
Odpowiednie (< 30 sekund):
  Odbiór webhooka i aktualizacja bazy danych
  Weryfikacja sygnatury i przekazanie zdarzenia
  Krótkie wywołania API do usług zewnętrznych

NIEODPOWIEDNIE (użyj Trigger.dev):
  Generowanie PDF
  Inferecja AI (wywołania LLM)
  Przetwarzanie wideo/obrazów
  Masowe operacje bazodanowe
  Wysyłka e-mail do wielu odbiorców
```

**Wzorzec dla zadań długotrwałych: Edge Function jako trigger, zadanie w Trigger.dev:**

```typescript
// volumes/functions/process-document/index.ts

// POPRAWNIE: Edge Function tylko triggeruje zadanie
Deno.serve(async (req) => {
  // ... weryfikacja sygnatury, walidacja danych ...

  // Delegowanie zadania długotrwałego do Trigger.dev
  const triggerResponse = await fetch(
    `${Deno.env.get('TRIGGER_DEV_URL')}/api/v1/tasks/process-document/trigger`,
    {
      method: 'POST',
      headers: {
        'Authorization': `Bearer ${Deno.env.get('TRIGGER_DEV_API_KEY')}`,
        'Content-Type': 'application/json',
      },
      body: JSON.stringify({
        payload: { documentId: parsed.data.documentId },
      }),
    }
  )

  // Natychmiastowa odpowiedź, zadanie działa w tle
  return new Response(
    JSON.stringify({ queued: true }),
    { status: 202, headers: { 'Content-Type': 'application/json' } }
  )
})
```

### Sprawdzalny warunek

```bash
# Szukanie wzorców wskazujących na zadania długotrwałe
grep -rn "await.*fetch.*openai\|pdf\|sharp\|ffmpeg\|sleep\|setTimeout" \
  volumes/functions/ --include="*.ts" | grep -v "trigger"
# Oczekiwanie: brak wyników (z wyjątkiem krótkich wywołań API)

# Czy w kodzie są timeouty?
grep -rn "AbortSignal.timeout\|setTimeout" \
  volumes/functions/ --include="*.ts"
# Każde zewnętrzne wywołanie fetch powinno mieć timeout
```

### Scenariusz awarii

Edge Function czekająca 2 minuty na odpowiedź AI API blokuje slot workera w kontenerze Edge Runtime. Przy wielu jednoczesnych żądaniach workery się zapełniają, a kolejne wywołania webhooków (np. od Stripe) kończą się timeoutem. Stripe interpretuje to jako błąd i ponawia, co pogarsza sytuację.

## B6 - Obsługa błędów i bezpieczne odpowiedzi

### Implementacja

Edge Functions nie mogą ujawniać wewnętrznych szczegółów w odpowiedziach na błędy.

```typescript
// Wzorzec bezpiecznej obsługi błędów

Deno.serve(async (req) => {
  const corsHeaders = getCorsHeaders(req)

  if (req.method === 'OPTIONS') {
    return new Response('ok', { headers: corsHeaders })
  }

  try {
    // ... właściwa logika ...

    return new Response(
      JSON.stringify({ success: true }),
      { status: 200, headers: { ...corsHeaders, 'Content-Type': 'application/json' } }
    )

  } catch (error) {
    // Logowanie wewnętrzne (szczegóły)
    console.error(`Function error: ${error.message}`, {
      stack: error.stack,
      // NIE logujemy sekretów ani danych użytkownika
    })

    // Odpowiedź zewnętrzna (ogólna)
    return new Response(
      JSON.stringify({ error: 'Internal server error' }),
      { status: 500, headers: { ...corsHeaders, 'Content-Type': 'application/json' } }
    )
  }
})
```

**Czego NIE powinno być w odpowiedziach ani logach:**

```typescript
// ŹLE: Stack trace wysyłany do klienta
return new Response(JSON.stringify({ error: error.stack }), { status: 500 })

// ŹLE: Logowanie sekretów
console.log(`Connecting with key: ${Deno.env.get('SERVICE_ROLE_KEY')}`)

// ŹLE: Logowanie pełnych danych użytkownika
console.log(`Processing user: ${JSON.stringify(user)}`)
```

### Sprawdzalny warunek

```bash
# Czy szczegóły błędów są wysyłane do klienta?
grep -rn "error\.stack\|error\.message" volumes/functions/ --include="*.ts" | \
  grep "Response"
# Oczekiwanie: brak wyników (stack/message tylko w console.error)

# Czy sekrety są logowane?
grep -rn "console\.log.*KEY\|console\.log.*SECRET\|console\.log.*token" \
  volumes/functions/ --include="*.ts"
# Oczekiwanie: brak wyników
```

### Scenariusz awarii

Jeśli stack trace błędu zostanie wysłany do klienta, atakujący widzi wewnętrzne ścieżki, nazwy modułów i szczegóły połączenia z bazą danych. To znacznie ułatwia ukierunkowane ataki. Jeśli sekrety trafiają do logów, są widoczne dla każdego z dostępem do monitoringu.

## Część C - Eksploatacja i monitoring

## C1 - Workflow deploymentu

### Implementacja

W setup self-hosted nie ma polecenia `supabase functions deploy`. Workflow jest oparty na plikach:

```bash
#!/bin/bash
# scripts/deploy-functions.sh

set -euo pipefail

FUNCTIONS_DIR="/opt/supabase/volumes/functions"
SOURCE_DIR="./supabase/functions"

echo "Deploying Edge Functions..."

# 1. Sprawdzenie składni (Deno)
for file in $(find "$SOURCE_DIR" -name "*.ts" -not -path "*/_shared/*"); do
  deno check "$file" 2>/dev/null || {
    echo "BŁĄD: Błąd składni w $file"
    exit 1
  }
done

# 2. Kopiowanie funkcji
rsync -av --delete \
  --exclude='*.test.ts' \
  "$SOURCE_DIR/" "$FUNCTIONS_DIR/"

# 3. Restart kontenera
docker compose restart functions --no-deps

# 4. Health Check
sleep 5
HEALTH=$(curl -s -o /dev/null -w "%{http_code}" \
  http://localhost:8000/functions/v1/hello 2>/dev/null || echo "000")

if [ "$HEALTH" = "200" ] || [ "$HEALTH" = "401" ]; then
  echo "Deployment Edge Functions zakończony pomyślnie"
else
  echo "OSTRZEŻENIE: Status Health Check $HEALTH"
fi
```

### Sprawdzalny warunek

```bash
# Kontener Edge Runtime działa?
docker compose ps functions --format '{{.State}}'
# Oczekiwanie: running

# Funkcje są osiągalne?
curl -s -o /dev/null -w "%{http_code}" \
  -H "Authorization: Bearer ${ANON_KEY}" \
  http://localhost:8000/functions/v1/stripe-webhook
# Oczekiwanie: 200 lub 405 (Method Not Allowed, ponieważ GET zamiast POST)
```

## C2 - Integracja z Claude Code

Claude Code weryfikuje Edge Functions kontekstowo jako uzupełnienie kontroli deterministycznych.

### Architektura

```
Git Push / PR
   |
   +-- Kontrole deterministyczne (CI/CD)
   |   +-- grep po hardcoded secrets
   |   +-- grep po brakującej weryfikacji sygnatury
   |   +-- grep po brakującej walidacji danych
   |   +-- grep po szczegółach błędów w odpowiedziach
   |   +-- Deno Type Check
   |
   +-- Analiza Claude Code (cotygodniowo lub przy PR)
       +-- Nowe funkcje bez weryfikacji sygnatury?
       +-- Użycie service_role uzasadnione?
       +-- Wykryte wzorce zadań długotrwałych?
       +-- Dryft architektoniczny (logika biznesowa w Functions)?
       +-- CORS poprawny dla nowych funkcji?
```

### Konkretny skrypt CI

```bash
#!/bin/bash
# scripts/check-edge-functions.sh

REPORT=""
FUNCTIONS_DIR="volumes/functions"

# 1. Hardcoded Secrets
SECRETS=$(grep -rn "sk_live\|sk_test\|whsec_\|Bearer ey" \
  "$FUNCTIONS_DIR" --include="*.ts" 2>/dev/null)
if [ -n "$SECRETS" ]; then
  REPORT+="KRYTYCZNE: Znaleziono hardcoded secrets:\n$SECRETS\n\n"
fi

# 2. Funkcje webhookowe bez weryfikacji sygnatury
for dir in "$FUNCTIONS_DIR"/*-webhook/; do
  [ -d "$dir" ] || continue
  name=$(basename "$dir")
  if ! grep -qE "signature|verify|hmac|crypto" "$dir/index.ts" 2>/dev/null; then
    REPORT+="KRYTYCZNE: $name nie ma weryfikacji sygnatury\n"
  fi
done

# 3. Funkcje bez walidacji danych
for dir in "$FUNCTIONS_DIR"/*/; do
  name=$(basename "$dir")
  [[ "$name" == "main" || "$name" == "_shared" ]] && continue
  if grep -q "JSON.parse" "$dir/index.ts" 2>/dev/null && \
     ! grep -qE "zod|safeParse|z\." "$dir/index.ts" 2>/dev/null; then
    REPORT+="OSTRZEŻENIE: $name parsuje JSON bez walidacji schematu\n"
  fi
done

# 4. Szczegóły błędów w odpowiedziach
LEAKS=$(grep -rn "error\.stack\|error\.message" "$FUNCTIONS_DIR" --include="*.ts" | \
  grep "Response" 2>/dev/null)
if [ -n "$LEAKS" ]; then
  REPORT+="OSTRZEŻENIE: Szczegóły błędów w odpowiedziach:\n$LEAKS\n\n"
fi

# 5. CORS Wildcards
WILDCARDS=$(grep -rn "'\\*'" "$FUNCTIONS_DIR" --include="*.ts" | grep -i "origin" 2>/dev/null)
if [ -n "$WILDCARDS" ]; then
  REPORT+="OSTRZEŻENIE: Znaleziono CORS Wildcard:\n$WILDCARDS\n\n"
fi

# 6. Wzorce zadań długotrwałych
LONG=$(grep -rn "openai\|sharp\|ffmpeg\|puppeteer" "$FUNCTIONS_DIR" --include="*.ts" 2>/dev/null)
if [ -n "$LONG" ]; then
  REPORT+="OSTRZEŻENIE: Możliwe wzorce zadań długotrwałych:\n$LONG\n\n"
fi

# Wynik
if [ -n "$REPORT" ]; then
  echo -e "=== Edge Function Security Check ===\n"
  echo -e "$REPORT"
else
  echo "Wszystkie kontrole Edge Function przeszły pomyślnie."
fi
```

Claude nie wykonuje **żadnych automatycznych zmian na produkcji**.

## Lista kontrolna deploymentu

Przed każdym deploymentem Edge Functions sprawdź:

```
Architektura
  [ ] Funkcja to integracja (Webhook/Event), nie logika biznesowa
  [ ] Jeden dostawca webhooków na funkcję
  [ ] Zadania długotrwałe delegowane do Trigger.dev

Bezpieczeństwo
  [ ] Sygnatura webhooka jest weryfikowana
  [ ] Dane wejściowe walidowane schematem (np. Zod)
  [ ] Poprawny wybór klienta (anon vs. service_role)
  [ ] service_role tylko gdy brak kontekstu użytkownika

Sekrety
  [ ] Brak hardcoded secrets w kodzie
  [ ] Sekrety w .env.functions (nie w Git)
  [ ] .env.functions z uprawnieniami 600

CORS
  [ ] Handler OPTIONS obecny
  [ ] Brak wildcard origin w produkcji
  [ ] Nagłówki CORS we WSZYSTKICH odpowiedziach (także błędach)

Obsługa błędów
  [ ] Try/Catch wokół całej logiki
  [ ] Ogólne komunikaty błędów do klienta
  [ ] Szczegóły tylko w console.error (bez sekretów)

Deployment
  [ ] Deno Type Check przeszedł
  [ ] Kontener zrestartowany po deploymencie
  [ ] Health Check po deploymencie pomyślny
```

## Podsumowanie

Supabase Edge Functions stanowią wydajny punkt integracyjny, gdy wykorzystywane są jako taki: odbiór webhooków, weryfikacja sygnatur, przetwarzanie zdarzeń i ich przekazywanie.

Kluczowym aspektem jest rozgraniczenie. Edge Functions nie są drugim backendem obok Next.js ani runnerem zadań obok Trigger.dev. Kto wyraźnie wytycza tę granicę i wdraża podstawy bezpieczeństwa (sygnatury, walidacja danych, poprawny klient, CORS), może bezpiecznie eksploatować Edge Functions w setup self-hosted.

Połączenie kontroli deterministycznych w CI i kontekstowej analizy Claude Code pokrywa zarówno znane wzorce, jak i nowe, nieoczekiwane zagrożenia. Kto od początku stawia na [Cert-Ready-by-Design](/pl/magazyn/cert-ready-by-design/), oszczędza sobie dodatkowych rund audytowych.

<div class="not-prose my-12 border border-gosign-border bg-gosign-light rounded-card p-6 lg:p-8">
<div class="flex items-start gap-4">
<div class="flex-shrink-0 w-12 h-12 bg-gosign-dark rounded-card flex items-center justify-center">
<svg width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="white" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 15v4a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2v-4"/><polyline points="7 10 12 15 17 10"/><line x1="12" y1="15" x2="12" y2="3"/></svg>
</div>
<div>
<h2 class="text-h3 font-bold text-gosign-dark mb-2" id="pobierz-liste-kontrolna-audytu">Pobierz listę kontrolną audytu</h2>
<p class="text-body text-gosign-text mb-2">Przygotowany prompt dla Claude Code. Prześlij plik na swój serwer i uruchom Claude Code w katalogu projektu Edge Functions. Claude Code automatycznie sprawdzi wszystkie punkty bezpieczeństwa z tego runbooka i zgłosi ZALICZONY, OSTRZEŻENIE lub KRYTYCZNY.</p>
<p class="text-sm text-gosign-text mb-4 font-mono">claude -p "$(cat claude-check-artikel-3-edge-functions-pl.md)" --allowedTools Read,Grep,Glob,Bash</p>
<a href="/downloads/claude-check-artikel-3-edge-functions-pl.md" download class="inline-flex items-center px-6 py-3 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-small uppercase tracking-wider">Pobierz listę kontrolną</a>
</div>
</div>
</div>

## Spis treści serii

Ten artykuł jest częścią naszej serii DevOps dla self-hosted stacków aplikacyjnych.

1. [Supabase Self-Hosting Runbook](/pl/magazyn/supabase-self-hosting/)
2. [Next.js nad Supabase - bezpieczna eksploatacja](/pl/magazyn/nextjs-supabase-bezpieczna-konfiguracja/)
3. [Supabase Edge Functions - bezpieczne wdrożenie](/pl/magazyn/supabase-edge-functions-bezpieczenstwo/) ← ten artykuł
4. [Bezpieczna obsługa Trigger.dev Background Jobs](/pl/magazyn/trigger-dev-background-jobs/)
5. [Claude Code jako kontrola bezpieczeństwa w DevOps](/pl/magazyn/claude-code-security-devops/)
6. [Security Baseline dla całego stacku](/pl/magazyn/security-baseline-stack/)

W kolejnym artykule pokażemy, jak **bezpiecznie eksploatować Trigger.dev Background Jobs**, bez wprowadzania nowych zagrożeń bezpieczeństwa w stacku.

--- Supabase Self-Hosting Runbook: bezpieczna architektura ---
> Supabase Self-Hosting Runbook: konfiguracja Hetzner, Docker Compose, architektura usług, sekrety, RLS i backupy.

Samodzielne hostowanie Supabase jest technicznie stosunkowo proste. **Bezpieczna i stabilna eksploatacja** Supabase jest znacznie bardziej wymagająca.

Powód: Supabase to nie pojedyncza baza danych, lecz kompletna platforma backendowa. Self-hosted stack Supabase składa się zwykle z kilku komponentów: PostgreSQL, PostgREST API, GoTrue Auth, Realtime Server, Storage, Kong API Gateway, Supabase Studio i opcjonalnie Edge Functions.

> **Statystyka:** Zgodnie z raportem Supabase z 2025 roku ponad 68% instancji self-hosted nie ma aktywnego RLS na wszystkich tabelach publicznych - co czyni tę kontrolę najczęściej pomijaną.


Oznacza to, że faktycznie eksploatujemy **platformę backendową**, a nie tylko bazę danych. Podobne rozważania dotyczą również [self-hostingu modeli językowych](/pl/magazyn/llm-self-hosting-enterprise/).

Ten runbook opisuje minimalne setup produkcyjne, które można bezpiecznie eksploatować i które jednocześnie pozostaje zautomatyzowane. Każdy krok zawiera konkretną implementację, sprawdzalny warunek i scenariusz awarii.

> **Uwaga dotycząca hostingu:** Ten runbook wykorzystuje **Hetzner Cloud** jako przykład infrastruktury, ponieważ Hetzner jest szeroko rozpowszechniony w regionie DACH, oferuje niemieckie centra danych i ma dobry stosunek ceny do wydajności. Zasady architektoniczne obowiązują jednak **niezależnie od hostingu**. Elementy specyficzne dla Hetzner (vSwitch, Cloud Firewall API, Robot Panel) można bezpośrednio przenieść na innych dostawców: OVH vRack (PL - datacenter Warszawa), Oktawave (PL), IONOS Cloud Network (EU). Tam, gdzie krok jest specyficzny dla Hetzner, wyraźnie to zaznaczamy.


<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">W skrócie - Artykuł 1 z 6 serii DevOps Runbook</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Architektura dwuserwerowa rozdziela produkcję i audyt</li>
<li>Docker Compose z przypiętymi wersjami obrazów</li>
<li>Siedem usług (PostgreSQL, PostgREST, GoTrue, Kong, Realtime, Storage, Studio)</li>
<li>RLS na wszystkich publicznych tabelach</li>
<li>Codzienne szyfrowane backupy przechowywane zewnętrznie</li>
</ul>
</div>

## Spis treści serii

Ten przewodnik jest częścią naszej serii runbooków DevOps dla nowoczesnych self-hosted stacków aplikacyjnych.

1. [Supabase Self-Hosting Runbook](/pl/magazyn/supabase-self-hosting/) ← ten artykuł
2. [Next.js nad Supabase - bezpieczna eksploatacja](/pl/magazyn/nextjs-supabase-bezpieczna-konfiguracja/)
3. [Supabase Edge Functions - bezpieczne wdrożenie](/pl/magazyn/supabase-edge-functions-bezpieczenstwo/)
4. [Bezpieczna obsługa Trigger.dev Background Jobs](/pl/magazyn/trigger-dev-background-jobs/)
5. [Claude Code jako kontrola bezpieczeństwa w DevOps](/pl/magazyn/claude-code-security-devops/)
6. [Security Baseline dla całego stacku](/pl/magazyn/security-baseline-stack/)

Artykuł 1 obejmuje **infrastrukturę, usługi i konfigurację stacku**. Kolejne artykuły budują na niej.

### Przegląd usług

| Usługa | Port | Funkcja | Krytyczna konfiguracja bezpieczeństwa |
|---|---|---|---|
| PostgreSQL | 5432 | Przechowywanie danych | RLS na wszystkich tabelach, listen_address tylko wewnętrzny |
| PostgREST | 3000 | REST API | Automatyczne wymuszanie RLS, role-based access |
| GoTrue | 9999 | Uwierzytelnianie | JWT expiry, email confirmation, refresh token rotation |
| Kong | 8000 | API Gateway | Rate limiting, routing, JWT validation |
| Realtime | 4000 | WebSocket | Autoryzacja kanałów, limity połączeń |
| Storage | 5000 | Object Storage | Bucket policies, limity rozmiaru plików |
| Studio | 3000 | Panel administracyjny | Dostęp tylko wewnętrzny (SSH Tunnel/VPN) |

## Architektura docelowa

Stabilne setup rozdziela co najmniej dwa obszary odpowiedzialności.

```
Internet
   |
   |  HTTPS (443)
   |
Reverse Proxy (Caddy / Nginx / Traefik)
   |
   |  TLS terminowany
   |
Kong API Gateway
   |
   +-- GoTrue         (Auth)
   +-- PostgREST       (API)
   +-- Realtime        (WebSocket)
   +-- Storage         (S3-kompatybilny Object Store)
   |
PostgreSQL
   |
   +-- RLS Policies
```

Równolegle działa drugi, oddzielny system:

```
Audit Server
   |
   +-- Security Checks    (Lynis, Trivy, Port Scans)
   +-- Drift Detection     (Config Diffs wobec Baseline)
   +-- Claude Code Review  (kontekstowa analiza)
   +-- Monitoring          (metryki, alerty)
   +-- Backup Verification (testy przywracania)
```

Dlaczego to rozdzielenie jest konieczne: jeśli system produkcyjny i audytowy są identyczne, skompromitowany serwer może jednocześnie manipulować własnymi kontrolami bezpieczeństwa.

## Część A - Decyzje infrastrukturalne

Te decyzje podejmuje się raz i stanowią one fundament dla wszystkiego dalszego.

## A1 - Rozdzielenie infrastruktury: dwa serwery

### Realizacja

Eksploatacja co najmniej dwóch serwerów, fizycznych lub jako oddzielne maszyny wirtualne:

```
supabase-prod     (Hetzner Cloud CX32 lub wyższy)
audit-runner      (Hetzner Cloud CX22 wystarczy)
```

> **Specyficzne dla Hetzner:** W konsoli Hetzner Cloud w sekcji "Servers" utworzyć dwie oddzielne instancje, obie w tym samym projekcie i tej samej lokalizacji (np. fsn1). U innych dostawców: dwie maszyny wirtualne w tym samym regionie/strefie.

**supabase-prod** obsługuje cały stack Supabase i PostgreSQL.
**audit-runner** obsługuje kontrole bezpieczeństwa, monitoring, Drift Detection i analizę Claude Code.

### Sprawdzalny warunek

```bash
# Oba serwery muszą być oddzielnymi hostami
ssh supabase-prod hostname
ssh audit-runner hostname

# Oczekiwanie: różne nazwy hostów i adresy IP
```

### Scenariusz awarii

Jeśli audyt i produkcja działają na tym samym serwerze i atakujący uzyska dostęp root, może usuwać logi, manipulować wynikami kontroli bezpieczeństwa i blokować alerty. Kompromitacja pozostaje niewykryta.

## A2 - Konfiguracja sieci prywatnej

### Realizacja

Oba serwery komunikują się wewnętrznie przez sieć prywatną. Usługi Supabase są dostępne wyłącznie przez te wewnętrzne adresy IP.

> **Specyficzne dla Hetzner:** W sekcji "Networks" utworzyć vSwitch lub Cloud Network z podsiecią `10.0.1.0/24`. Oba serwery przypisać do sieci. Hetzner automatycznie tworzy interfejs (typowo `ens10`). W OVH (PL): vRack. W Oktawave (PL): Prywatna sieć. W IONOS (EU): Cloud Network.

```bash
# Na obu serwerach skonfigurować prywatny interfejs
# /etc/network/interfaces.d/60-private.cfg (specyficzne dla Hetzner)

auto ens10
iface ens10 inet static
  address 10.0.1.10/24    # supabase-prod
  # address 10.0.1.11/24  # audit-runner
```

```bash
# Aktywacja sieci
systemctl restart networking

# Sprawdzenie
ip addr show ens10
ping 10.0.1.11   # z serwera prod
```

### Sprawdzalny warunek

```bash
# Z audit-runner: wewnętrzny interfejs aktywny?
ssh audit-runner "ip addr show ens10 | grep 10.0.1.11"

# PostgreSQL może nasłuchiwać tylko wewnętrznie
ssh supabase-prod "ss -tlnp | grep 5432"

# Oczekiwanie: 10.0.1.10:5432, NIE 0.0.0.0:5432
```

### Scenariusz awarii

Jeśli PostgreSQL nasłuchuje na `0.0.0.0:5432` i firewall ma błąd, baza danych jest bezpośrednio dostępna z internetu. Z kluczem `service_role` lub słabym hasłem Postgres cała baza danych jest skompromitowana.

## A3 - Reverse Proxy z TLS

### Realizacja

Przed Kongiem stoi reverse proxy, który terminuje TLS i jest jedyną usługą dostępną z zewnątrz. Caddy jest tu użyty jako przykład, ponieważ ma wbudowane automatyczne Let's Encrypt.

```
# Caddyfile

app.example.com {
    reverse_proxy localhost:8000 {
        header_up X-Forwarded-Proto {scheme}
        header_up X-Real-IP {remote_host}
    }

    header {
        X-Frame-Options "DENY"
        X-Content-Type-Options "nosniff"
        Referrer-Policy "strict-origin-when-cross-origin"
        Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
        -Server
    }
}
```

Alternatywnie z Nginx:

```nginx
server {
    listen 443 ssl http2;
    server_name app.example.com;

    ssl_certificate /etc/letsencrypt/live/app.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/app.example.com/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;

    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # Obsługa WebSocket dla Realtime
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}
```

### Sprawdzalny warunek

```bash
# TLS aktywny i poprawnie skonfigurowany?
curl -I https://app.example.com

# Oczekiwanie: HTTP/2 200, nagłówek Strict-Transport-Security obecny

# Sprawdzenie wersji TLS
openssl s_client -connect app.example.com:443 -tls1_2 </dev/null 2>&1 | grep "Protocol"

# Data wygaśnięcia certyfikatu
echo | openssl s_client -connect app.example.com:443 2>/dev/null | \
  openssl x509 -noout -enddate

# Oczekiwanie: notAfter co najmniej 14 dni w przyszłości

# Nagłówki bezpieczeństwa obecne?
curl -sI https://app.example.com | grep -E \
  "X-Frame-Options|Strict-Transport-Security|X-Content-Type-Options"
```

### Scenariusz awarii

Bez TLS tokeny uwierzytelniania przesyłane są przez sieć w postaci jawnej. Każdy w tym samym segmencie sieci może je przechwycić (Man-in-the-Middle). Bez automatycznego odnawiania certyfikatów certyfikat wygasa po 90 dniach i aplikacja staje się niedostępna.

## A4 - Podwójny firewall

### Realizacja

Dwie warstwy, które wzajemnie się zabezpieczają:

**Warstwa 1: Cloud Firewall (przed serwerem)**

> **Specyficzne dla Hetzner:** W sekcji "Firewalls" utworzyć nowy firewall i przypisać go do obu serwerów. W OVH (PL): Security Groups. W Oktawave (PL): Firewall. W IONOS (EU): Cloud Firewall.

```
# Reguły Hetzner Cloud Firewall dla supabase-prod

Inbound:
  TCP 443    z 0.0.0.0/0        (HTTPS)
  TCP 22     z ADMIN_IP/32       (SSH tylko z IP administratora)
  TCP ALL    z 10.0.1.0/24       (sieć wewnętrzna)

Outbound:
  ALL        do 0.0.0.0/0        (aktualizacje, DNS, Let's Encrypt)
```

**Warstwa 2: Host Firewall (na serwerze)**

```bash
# /etc/iptables/rules.v4

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]

# Loopback
-A INPUT -i lo -j ACCEPT

# Established Connections
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# SSH tylko z IP administratora
-A INPUT -p tcp --dport 22 -s ADMIN_IP -j ACCEPT

# HTTPS
-A INPUT -p tcp --dport 443 -j ACCEPT

# Sieć wewnętrzna (wszystkie porty)
-A INPUT -s 10.0.1.0/24 -j ACCEPT

# Wszystko inne odrzucane (Default Policy)
COMMIT
```

```bash
# Aktywacja firewalla
apt install iptables-persistent
iptables-restore < /etc/iptables/rules.v4

# Zapisanie baseliny do Drift Detection
iptables-save > /root/firewall-baseline.txt
```

### Sprawdzalny warunek

```bash
# Z zewnątrz: tylko 443 otwarty
nmap -p 22,80,443,5432,8000,9000 app.example.com

# Oczekiwanie: tylko 443 open (22 tylko z IP administratora)

# Na serwerze: reguły aktywne?
iptables -L -n | grep -c "DROP"

# Oczekiwanie: co najmniej 1 (Default DROP Policy)

# Drift Detection: czy firewall się zmienił?
iptables-save | diff /root/firewall-baseline.txt -

# Oczekiwanie: brak odchyleń
```

### Scenariusz awarii

Pojedynczy firewall może być błędnie skonfigurowany. Polecenie `iptables -F` (flush) na serwerze otwiera wszystkie porty, jeśli nie ma Cloud Firewalla. Z drugiej strony Cloud Firewall nie chroni przed procesami, które na samym serwerze otwierają nowe porty, jeśli nie jest aktywny Host Firewall.

## A5 - Zabezpieczenie dostępu SSH

### Realizacja

```bash
# /etc/ssh/sshd_config

PasswordAuthentication no
 PermitRootLogin no
PubkeyAuthentication yes
MaxAuthTries 3
LoginGraceTime 30
AllowUsers deploy
```

```bash
# Umieszczenie klucza SSH na serwerze
mkdir -p /home/deploy/.ssh
echo "ssh-ed25519 AAAA... admin@workstation" > /home/deploy/.ssh/authorized_keys
chmod 700 /home/deploy/.ssh
chmod 600 /home/deploy/.ssh/authorized_keys
chown -R deploy:deploy /home/deploy/.ssh

# Przeładowanie SSHD
systemctl reload sshd
```

### Sprawdzalny warunek

```bash
# Logowanie hasłem musi się nie powieść
ssh -o PasswordAuthentication=yes -o PubkeyAuthentication=no deploy@app.example.com

# Oczekiwanie: Permission denied

# Logowanie jako root musi się nie powieść
ssh root@app.example.com

# Oczekiwanie: Permission denied

# Sprawdzenie konfiguracji
sshd -T | grep -E "passwordauthentication|permitrootlogin"

# Oczekiwanie: passwordauthentication no, permitrootlogin no
```

### Scenariusz awarii

Dostęp SSH oparty na hasłach jest stale atakowany z internetu (Brute Force). Słabe hasło jest typowo łamane w ciągu godzin. Logowanie jako root oznacza, że atakujący natychmiast uzyskuje pełną kontrolę nad serwerem.

## Część B - Konfiguracja i zabezpieczanie usług Supabase

Self-hosted stack Supabase składa się z ponad 10 usług. Każda z nich ma własne zmienne środowiskowe, własne role bazodanowe i własne wymagania bezpieczeństwa. Oficjalny `docker-compose.yml` Supabase ma ponad 400 linii i zawiera wiele ustawień, które nie wyglądają na istotne z punktu widzenia bezpieczeństwa, ale mimo to takimi są.

Ten rozdział wyjaśnia każdą usługę, jej rolę, konfigurację istotną dla bezpieczeństwa oraz typowe błędy przy konfiguracji.

### Przegląd usług

```
Internet
   │
   │  HTTPS (443)
   │
Reverse Proxy (Caddy/Nginx)     ← Część A3
   │
Kong (API Gateway)               ← routuje do wszystkich usług
   │
   ├── GoTrue (Auth)              ← /auth/v1/*
   ├── PostgREST (REST API)       ← /rest/v1/*
   ├── Realtime                   ← /realtime/v1/*
   ├── Storage API                ← /storage/v1/*
   ├── Edge Functions             ← /functions/v1/*
   ├── Studio (Dashboard)         ← / (chronione Basic Auth)
   │
   ├── Meta (Postgres-Meta)       ← wewnętrzne, dla Studio
   ├── ImgProxy                   ← wewnętrzne, dla Storage
   ├── Analytics (Logflare)       ← wewnętrzne, dla logów
   ├── Vector                     ← wewnętrzne, pipeline logów
   └── Supavisor (Pooler)         ← Connection Pooling
   │
PostgreSQL                        ← baza danych ze skryptami Init
   │
   └── Role: anon, authenticated, service_role,
       authenticator, supabase_admin, supabase_auth_admin,
       supabase_storage_admin
```

## B0 - Generowanie sekretów (przed pierwszym uruchomieniem)

**To musi nastąpić PRZED uruchomieniem wszystkich usług.** Oficjalny `.env.example` zawiera placeholdery. Muszą one zostać zastąpione wygenerowanymi wartościami.

```bash
# JWT Secret (współdzielony przez GoTrue, PostgREST, Realtime, Kong)
JWT_SECRET=$(openssl rand -base64 32)

# Hasło Postgres
POSTGRES_PASSWORD=$(openssl rand -base64 24)

# Hasło dashboardu (Basic Auth przez Kong)
DASHBOARD_PASSWORD=$(openssl rand -base64 16)

# Tokeny Logflare
LOGFLARE_PUBLIC_ACCESS_TOKEN=$(openssl rand -hex 16)
LOGFLARE_PRIVATE_ACCESS_TOKEN=$(openssl rand -hex 16)

# Hasło root MinIO (jeśli używany S3 Storage)
MINIO_ROOT_PASSWORD=$(openssl rand -hex 16)

# Realtime Secret Key Base (min. 64 znaki)
SECRET_KEY_BASE=$(openssl rand -base64 48)

# Supavisor Vault Encryption Key
VAULT_ENC_KEY=$(openssl rand -base64 24)

# PG Meta Crypto Key
PG_META_CRYPTO_KEY=$(openssl rand -base64 24)

# Anon Key i Service Role Key (JWT, generowane z JWT_SECRET)
# Użyj https://supabase.com/docs/guides/self-hosting/docker#generate-api-keys
# lub wygeneruj ręcznie za pomocą jwt.io i JWT_SECRET
```

**Reguła bezpieczeństwa:** Wszystkie sekrety trafiają do pliku `.env` na serwerze (uprawnienia 600, nie w Git). Supabase używa jednego `JWT_SECRET` dla wszystkich usług. Jeśli ten sekret zostanie skompromitowany, GoTrue, PostgREST i Realtime są jednocześnie dotknięte.

### Warunek weryfikowalny

```bash
# Wszystkie wymagane sekrety ustawione?
for var in JWT_SECRET POSTGRES_PASSWORD ANON_KEY SERVICE_ROLE_KEY \
  DASHBOARD_PASSWORD LOGFLARE_PUBLIC_ACCESS_TOKEN SECRET_KEY_BASE \
  VAULT_ENC_KEY PG_META_CRYPTO_KEY; do
  if grep -q "^${var}=$\|^${var}=your-\|^${var}=change" .env 2>/dev/null; then
    echo "KRYTYCZNE: $var nie jest ustawiony lub ma wartość domyślną"
  fi
done

# Brak identycznych haseł?
PASSWORDS=$(grep -E "PASSWORD|SECRET|KEY" .env | cut -d= -f2 | sort)
UNIQUE=$(echo "$PASSWORDS" | sort -u)
if [ "$(echo "$PASSWORDS" | wc -l)" != "$(echo "$UNIQUE" | wc -l)" ]; then
  echo "OSTRZEŻENIE: Niektóre sekrety mają identyczne wartości"
fi
```

### Scenariusz awarii

Domyślne sekrety z `.env.example` są publicznie znane. Atakujący może z domyślnym `JWT_SECRET` wygenerować ważne tokeny i uzyskać pełny dostęp do API. Z domyślnym `SERVICE_ROLE_KEY` dodatkowo omija wszystkie polityki RLS.

## B1 - PostgreSQL: baza danych i role

### Co robi ta usługa

PostgreSQL to centralna baza danych. W kontekście Supabase pełni szczególną rolę: przechowuje nie tylko dane aplikacyjne, ale także dane uwierzytelniania (GoTrue), konfigurację Realtime, metadane Storage i logi Analytics. Skrypty Init tworzą specjalne schematy i role.

### Konfiguracja istotna dla bezpieczeństwa

```yaml
db:
  image: supabase/postgres:15.8.1.085    # Własny obraz Supabase, wersja przypięta
  restart: unless-stopped
  ports:
    - "10.0.1.10:5432:5432"              # TYLKO wewnętrzny interfejs
  volumes:
    # Skrypty Init (tworzą schematy, role, rozszerzenia)
    - ./volumes/db/realtime.sql:/docker-entrypoint-initdb.d/migrations/99-realtime.sql:Z
    - ./volumes/db/webhooks.sql:/docker-entrypoint-initdb.d/init-scripts/98-webhooks.sql:Z
    - ./volumes/db/roles.sql:/docker-entrypoint-initdb.d/init-scripts/99-roles.sql:Z
    - ./volumes/db/jwt.sql:/docker-entrypoint-initdb.d/init-scripts/99-jwt.sql:Z
    - ./volumes/db/_supabase.sql:/docker-entrypoint-initdb.d/migrations/97-_supabase.sql:Z
    - ./volumes/db/logs.sql:/docker-entrypoint-initdb.d/migrations/99-logs.sql:Z
    - ./volumes/db/pooler.sql:/docker-entrypoint-initdb.d/migrations/99-pooler.sql:Z
    # Dane trwałe
    - ./volumes/db/data:/var/lib/postgresql/data:Z
    - db-config:/etc/postgresql-custom
  healthcheck:
    test: ["CMD", "pg_isready", "-U", "postgres", "-h", "localhost"]
    interval: 5s
    timeout: 5s
    retries: 10
  environment:
    POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    POSTGRES_DB: ${POSTGRES_DB}
    JWT_SECRET: ${JWT_SECRET}
    JWT_EXP: ${JWT_EXPIRY}
```

**Skrypty Init tworzą następujące role:**

```
postgres              → Superuser (tylko do administracji, nigdy dla usług)
anon                  → Nieuwierzytelnione zapytania (przez PostgREST)
authenticated         → Uwierzytelnione zapytania (przez PostgREST)
service_role          → Omija RLS (do operacji administracyjnych)
authenticator         → PostgREST używa tej roli do łączenia się
supabase_admin        → Wewnętrzna rola administracyjna (Realtime, Analytics)
supabase_auth_admin   → Specyficzna dla GoTrue (schemat auth)
supabase_storage_admin → Specyficzna dla Storage (schemat storage)
```

### Co może pójść nie tak

Plik `roles.sql` definiuje granty dla każdej roli. Jeśli ten plik zostanie zmodyfikowany (np. aby szybko rozwiązać problem), role mogą uzyskać zbyt wiele uprawnień. Rola `anon` powinna mieć tylko te uprawnienia, które polityki RLS jawnie zezwalają.

### Warunek weryfikowalny

```bash
# Sprawdzenie ról i ich uprawnień
docker compose exec -T db psql -U postgres -c \
  "SELECT rolname, rolsuper, rolcreaterole, rolcreatedb, rolcanlogin
   FROM pg_roles
   WHERE rolname IN ('anon','authenticated','service_role','authenticator',
     'supabase_admin','supabase_auth_admin','supabase_storage_admin')
   ORDER BY rolname;"

# anon NIE może być superuserem
docker compose exec -T db psql -U postgres -c \
  "SELECT rolname, rolsuper FROM pg_roles WHERE rolname = 'anon' AND rolsuper = true;"
# Oczekiwanie: brak wierszy

# Postgres nasłuchuje TYLKO wewnętrznie
ss -tlnp | grep 5432
# Oczekiwanie: 10.0.1.10:5432, NIE 0.0.0.0:5432
```

## B2 - Kong: API Gateway i routing

### Co robi ta usługa

Kong jest centralnym punktem wejścia dla wszystkich zapytań API. Routuje na podstawie ścieżki URL do odpowiednich usług, obsługuje walidację JWT i chroni dashboard Studio za pomocą Basic Auth.

### Konfiguracja istotna dla bezpieczeństwa

```yaml
kong:
  image: kong:2.8.1                       # Wersja przypięta
  restart: unless-stopped
  ports:
    - "127.0.0.1:8000:8000"              # TYLKO localhost (Reverse Proxy przed nim)
    - "127.0.0.1:8443:8443"              # HTTPS wewnętrznie
  volumes:
    - ./volumes/api/kong.yml:/home/kong/temp.yml:ro,z
  environment:
    KONG_DATABASE: "off"                   # Konfiguracja deklaratywna, bez bazy danych
    KONG_DECLARATIVE_CONFIG: /home/kong/kong.yml
    KONG_DNS_ORDER: LAST,A,CNAME
    KONG_PLUGINS: request-transformer,cors,key-auth,acl,basic-auth,request-termination,ip-restriction
    SUPABASE_ANON_KEY: ${ANON_KEY}
    SUPABASE_SERVICE_KEY: ${SERVICE_ROLE_KEY}
    DASHBOARD_USERNAME: ${DASHBOARD_USERNAME}
    DASHBOARD_PASSWORD: ${DASHBOARD_PASSWORD}
  entrypoint: bash -c 'eval "echo \"$$(cat ~/temp.yml)\"" > ~/kong.yml && /docker-entrypoint.sh kong docker-start'
```

**Plik `kong.yml` definiuje routing:**

```
/rest/v1/*        → PostgREST (port 3000)    + JWT Validation
/auth/v1/*        → GoTrue (port 9999)       + JWT Validation
/realtime/v1/*    → Realtime (port 4000)      + JWT Validation
/storage/v1/*     → Storage (port 5000)       + JWT Validation
/functions/v1/*   → Edge Functions (port 54321) + JWT Validation (opcjonalnie)
/                 → Studio (port 3000)        + Basic Auth
```

### Co może pójść nie tak

Kong na `0.0.0.0:8000` zamiast `127.0.0.1:8000` oznacza, że API jest bezpośrednio dostępne bez Reverse Proxy (bez TLS). Słabe hasło dashboardu daje przez Basic Auth dostęp do Studio, a tym samym do całej bazy danych. Plik `kong.yml` może być skonfigurowany tak, że walidacja JWT jest wyłączona dla niektórych tras.

### Warunek weryfikowalny

```bash
# Kong tylko na localhost?
ss -tlnp | grep 8000
# Oczekiwanie: 127.0.0.1:8000

# Hasło dashboardu wystarczająco silne?
DASH_PW_LEN=$(grep "DASHBOARD_PASSWORD" .env | cut -d= -f2 | wc -c)
[ "$DASH_PW_LEN" -lt 16 ] && echo "OSTRZEŻENIE: Hasło dashboardu za krótkie"

# kong.yml: JWT Validation aktywna na wszystkich trasach API?
grep -A5 "key-auth" volumes/api/kong.yml | head -20
```

## B3 - GoTrue: uwierzytelnianie

### Co robi ta usługa

GoTrue obsługuje rejestrację użytkowników, logowanie, Magic Links, OAuth, MFA i wydawanie tokenów. Jest jedyną usługą wystawiającą JWT i ma własnego użytkownika DB (`supabase_auth_admin`) z dostępem do schematu `auth`.

### Konfiguracja istotna dla bezpieczeństwa

```yaml
auth:
  image: supabase/gotrue:v2.184.0       # Wersja przypięta
  restart: unless-stopped
  environment:
    GOTRUE_API_HOST: 0.0.0.0
    GOTRUE_API_PORT: 9999
    API_EXTERNAL_URL: ${API_EXTERNAL_URL}    # https://app.example.com

    # Baza danych (własny użytkownik administracyjny)
    GOTRUE_DB_DATABASE_URL: postgres://supabase_auth_admin:${POSTGRES_PASSWORD}@${POSTGRES_HOST}:${POSTGRES_PORT}/${POSTGRES_DB}

    # JWT
    GOTRUE_JWT_SECRET: ${JWT_SECRET}
    GOTRUE_JWT_EXP: ${JWT_EXPIRY}            # MAKSYMALNIE 3600 (1 godzina)
    GOTRUE_JWT_AUD: authenticated
    GOTRUE_JWT_ADMIN_ROLES: service_role
    GOTRUE_JWT_DEFAULT_GROUP_NAME: authenticated

    # Rejestracja
    GOTRUE_DISABLE_SIGNUP: ${DISABLE_SIGNUP}  # true jeśli zamknięta aplikacja
    GOTRUE_EXTERNAL_EMAIL_ENABLED: ${ENABLE_EMAIL_SIGNUP}
    GOTRUE_MAILER_AUTOCONFIRM: false          # ZAWSZE false w produkcji

    # SMTP (dla Magic Links, potwierdzenia e-mail)
    GOTRUE_SMTP_HOST: ${SMTP_HOST}
    GOTRUE_SMTP_PORT: ${SMTP_PORT}
    GOTRUE_SMTP_USER: ${SMTP_USER}
    GOTRUE_SMTP_PASS: ${SMTP_PASS}
    GOTRUE_SMTP_ADMIN_EMAIL: ${SMTP_ADMIN_EMAIL}
    GOTRUE_SMTP_SENDER_NAME: ${SMTP_SENDER_NAME}

    # Ścieżki URL Mailera (muszą pasować do routingu Kong)
    GOTRUE_MAILER_URLPATHS_CONFIRMATION: "/auth/v1/verify"
    GOTRUE_MAILER_URLPATHS_INVITE: "/auth/v1/verify"
    GOTRUE_MAILER_URLPATHS_RECOVERY: "/auth/v1/verify"
    GOTRUE_MAILER_URLPATHS_EMAIL_CHANGE: "/auth/v1/verify"

    # Site URL (Redirect po Auth)
    GOTRUE_SITE_URL: ${SITE_URL}              # URL waszej aplikacji Next.js
    GOTRUE_URI_ALLOW_LIST: ${ADDITIONAL_REDIRECT_URLS}

    # Rotacja Refresh Token (zapobiega ponownemu użyciu tokena)
    GOTRUE_SECURITY_REFRESH_TOKEN_ROTATION_ENABLED: true
    GOTRUE_SECURITY_REFRESH_TOKEN_REUSE_INTERVAL: 10
```

### Konfiguracja SMTP: dlaczego jest istotna dla bezpieczeństwa

Bez działającego serwera SMTP nie można wysyłać e-maili potwierdzających. Jeśli ustawiono `GOTRUE_MAILER_AUTOCONFIRM: true`, aby to obejść, każdy może się zarejestrować z dowolnym adresem e-mail. Oznacza to: brak weryfikacji tożsamości.

### Warunek weryfikowalny

```bash
# GoTrue Health Check
docker compose exec -T auth wget --no-verbose --tries=1 --spider http://localhost:9999/health

# JWT Expiry nie wyższy niż 3600?
grep "JWT_EXPIRY\|JWT_EXP" .env | head -1
# Oczekiwanie: 3600 lub mniej

# Autoconfirm wyłączony?
grep "AUTOCONFIRM" .env
# Oczekiwanie: false

# SMTP skonfigurowany (nie pusty)?
for var in SMTP_HOST SMTP_PORT SMTP_USER SMTP_PASS; do
  VAL=$(grep "^${var}=" .env | cut -d= -f2)
  [ -z "$VAL" ] && echo "OSTRZEŻENIE: $var jest pusty"
done

# Rotacja Refresh Token aktywna?
grep "REFRESH_TOKEN_ROTATION" .env docker-compose.yml 2>/dev/null
# Oczekiwanie: true
```

### Scenariusz awarii

Z `AUTOCONFIRM=true` i `DISABLE_SIGNUP=false` każdy może utworzyć konto i natychmiast z niego korzystać bez potwierdzenia adresu e-mail. Atakujący może się zarejestrować z dowolnymi adresami i natychmiast uzyskuje rolę `authenticated` w bazie danych. Bez rotacji Refresh Token skradziony Refresh Token może być używany na stałe.

## B4 - PostgREST: REST API

### Co robi ta usługa

PostgREST automatycznie generuje REST API ze schematu PostgreSQL. Jest głównym punktem dostępu do danych. Bezpieczeństwo leży przede wszystkim w rolach PostgreSQL i politykach RLS, a nie w samym PostgREST.

### Konfiguracja istotna dla bezpieczeństwa

```yaml
rest:
  image: postgrest/postgrest:v14.1       # Wersja przypięta
  restart: unless-stopped
  environment:
    PGRST_DB_URI: postgres://authenticator:${POSTGRES_PASSWORD}@${POSTGRES_HOST}:${POSTGRES_PORT}/${POSTGRES_DB}
    PGRST_DB_SCHEMAS: ${PGRST_DB_SCHEMAS}   # public,storage,graphql_public
    PGRST_DB_ANON_ROLE: anon
    PGRST_JWT_SECRET: ${JWT_SECRET}
    PGRST_DB_USE_LEGACY_GUCS: "false"
    PGRST_APP_SETTINGS_JWT_SECRET: ${JWT_SECRET}
    PGRST_APP_SETTINGS_JWT_EXP: ${JWT_EXPIRY}
```

**Jak PostgREST pracuje z rolami:**

```
Zapytanie bez JWT     → PostgREST używa roli "anon"
Zapytanie z JWT       → PostgREST przełącza się na rolę z JWT (np. "authenticated")
Zapytanie z service_role JWT → PostgREST używa "service_role" (omija RLS)
```

Użytkownik `authenticator` łączy się z bazą danych i przełącza się przez `SET ROLE` na odpowiednią rolę. Oznacza to: granty na rolach `anon` i `authenticated` są właściwą warstwą bezpieczeństwa.

### Warunek weryfikowalny

```bash
# PostgREST używa roli authenticator (nie postgres)?
grep "PGRST_DB_URI" docker-compose.yml | grep "authenticator"
# Oczekiwanie: tak

# Schematy jawnie zdefiniowane (nie wszystkie)?
grep "PGRST_DB_SCHEMAS" .env
# Oczekiwanie: public,storage,graphql_public (nie puste = wszystkie schematy)
```

### Scenariusz awarii

Jeśli `PGRST_DB_URI` używa superusera `postgres` zamiast `authenticator`, każde zapytanie ma uprawnienia superusera, RLS jest nieskuteczne. Jeśli `PGRST_DB_SCHEMAS` jest puste, PostgREST eksponuje wszystkie schematy, łącznie z wewnętrznymi schematami Supabase (`auth`, `_realtime`, `_analytics`).

## B5 - Realtime: subskrypcje WebSocket

### Co robi ta usługa

Realtime umożliwia subskrypcje oparte na WebSocket na zmiany w bazie danych. Używa użytkownika `supabase_admin` i schematu `_realtime`.

### Konfiguracja istotna dla bezpieczeństwa

```yaml
realtime:
  container_name: realtime-dev.supabase-realtime   # Nazwa jest istotna dla Tenant-ID
  image: supabase/realtime:v2.68.0
  restart: unless-stopped
  environment:
    PORT: 4000
    DB_HOST: ${POSTGRES_HOST}
    DB_PORT: ${POSTGRES_PORT}
    DB_USER: supabase_admin
    DB_PASSWORD: ${POSTGRES_PASSWORD}
    DB_NAME: ${POSTGRES_DB}
    DB_AFTER_CONNECT_QUERY: 'SET search_path TO _realtime'
    DB_ENC_KEY: supabaserealtime          # ZMIENIĆ w produkcji
    API_JWT_SECRET: ${JWT_SECRET}
    SECRET_KEY_BASE: ${SECRET_KEY_BASE}   # min. 64 znaki
    SEED_SELF_HOST: "true"
    RUN_JANITOR: "true"
```

### Co może pójść nie tak

`DB_ENC_KEY: supabaserealtime` to wartość domyślna. W produkcji musi zostać zmieniony. `SECRET_KEY_BASE` musi mieć co najmniej 64 znaki, w przeciwnym razie usługa nie uruchomi się lub będzie niebezpieczna. Realtime używa `supabase_admin`, co oznacza, że wewnętrznie ma pełny dostęp do bazy danych. Bezpieczeństwo leży w walidacji JWT: tylko uwierzytelnieni użytkownicy mogą otwierać subskrypcje, a RLS określa, które wiersze widzą.

### Warunek weryfikowalny

```bash
# DB_ENC_KEY nie na wartości domyślnej?
grep "DB_ENC_KEY" docker-compose.yml
# NIE "supabaserealtime"

# SECRET_KEY_BASE wystarczająco długi?
SKB_LEN=$(grep "SECRET_KEY_BASE" .env | cut -d= -f2 | wc -c)
[ "$SKB_LEN" -lt 64 ] && echo "KRYTYCZNE: SECRET_KEY_BASE za krótki ($SKB_LEN znaków)"

# Realtime Health Check
docker compose exec -T realtime-dev.supabase-realtime \
  curl -sSf -H "Authorization: Bearer ${ANON_KEY}" \
  http://localhost:4000/api/tenants/realtime-dev/health
```

## B6 - Storage API i MinIO (S3)

### Co robi ta usługa

Storage zarządza przesyłaniem i pobieraniem plików. Domyślnie przechowuje pliki lokalnie w wolumenie. W produkcji zalecany jest backend kompatybilny z S3 (MinIO self-hosted lub usługa S3 wolna od Cloud Act).

### Lokalne Storage (domyślne)

```yaml
storage:
  image: supabase/storage-api:v1.33.0
  restart: unless-stopped
  volumes:
    - ./volumes/storage:/var/lib/storage:z
  environment:
    ANON_KEY: ${ANON_KEY}
    SERVICE_KEY: ${SERVICE_ROLE_KEY}
    POSTGREST_URL: http://rest:3000
    PGRST_JWT_SECRET: ${JWT_SECRET}
    DATABASE_URL: postgres://supabase_storage_admin:${POSTGRES_PASSWORD}@${POSTGRES_HOST}:${POSTGRES_PORT}/${POSTGRES_DB}
    STORAGE_BACKEND: file
    FILE_STORAGE_BACKEND_PATH: /var/lib/storage
    FILE_SIZE_LIMIT: 52428800              # 50MB, dostosować
    ENABLE_IMAGE_TRANSFORMATION: "true"
    IMGPROXY_URL: http://imgproxy:5001
```

### MinIO jako backend S3 (produkcja)

Jeśli używasz MinIO, dochodzi dodatkowa usługa:

```yaml
# docker-compose.s3.yml (dodatkowo do głównego Compose)
minio:
  image: minio/minio:latest              # W produkcji przypiąć wersję
  restart: unless-stopped
  ports:
    - "127.0.0.1:9000:9000"              # API, TYLKO localhost
    - "127.0.0.1:9001:9001"              # Konsola, TYLKO localhost
  volumes:
    - minio-data:/data
  environment:
    MINIO_ROOT_USER: ${MINIO_ROOT_USER}
    MINIO_ROOT_PASSWORD: ${MINIO_ROOT_PASSWORD}   # min. 8 znaków
  command: server /data --console-address ":9001"
```

Następnie w konfiguracji Storage:

```yaml
storage:
  environment:
    STORAGE_BACKEND: s3
    GLOBAL_S3_BUCKET: supabase-storage
    GLOBAL_S3_ENDPOINT: http://minio:9000
    GLOBAL_S3_FORCE_PATH_STYLE: "true"
    AWS_ACCESS_KEY_ID: ${MINIO_ACCESS_KEY}
    AWS_SECRET_ACCESS_KEY: ${MINIO_SECRET_KEY}
    REGION: eu-central-1
```

### Warunek weryfikowalny

```bash
# Storage Health Check
docker compose exec -T storage wget --no-verbose --tries=1 --spider http://localhost:5000/status

# MinIO niedostępne z zewnątrz (jeśli używane)?
ss -tlnp | grep 9000
# Oczekiwanie: 127.0.0.1:9000 (nie 0.0.0.0)

# MinIO domyślne poświadczenia?
grep "MINIO_ROOT" .env | grep -iE "minioadmin\|minio123\|admin"
# Oczekiwanie: brak trafień

# Wolumen Storage istnieje i ma dane?
ls -la volumes/storage/ 2>/dev/null | head -5

# Polityki bucketów Storage (przez MinIO Client)
# mc alias set local http://localhost:9000 $MINIO_ROOT_USER $MINIO_ROOT_PASSWORD
# mc admin policy ls local
```

### Scenariusz awarii

MinIO z domyślnymi poświadczeniami (`minioadmin:minioadmin`) na `0.0.0.0:9000` oznacza: każdy w internecie może czytać i zapisywać wszystkie pliki. Konsola MinIO na porcie 9001 daje dodatkowo interfejs webowy do pełnej administracji. Polityki bucketów Storage mogą być ustawione na "public", co oznacza, że pliki są dostępne bez uwierzytelniania.

## B7 - Analytics, Vector i Supavisor (usługi wewnętrzne)

### Co robią te usługi

Te usługi nie są bezpośrednio dostępne z zewnątrz, ale są istotne z punktu widzenia bezpieczeństwa, ponieważ mają uprzywilejowany dostęp do bazy danych.

**Analytics (Logflare):** Zbiera i przechowuje logi wszystkich usług. Używa `supabase_admin` i schematu `_analytics`.

**Vector:** Pipeline logów przekierowujący logi Docker do Logflare. Ma dostęp do Docker Socket.

**Supavisor:** Connection Pooler dla PostgreSQL. Zarządza pulą połączeń i ma dostęp `supabase_admin`.

### Konfiguracja istotna dla bezpieczeństwa

```yaml
analytics:
  image: supabase/logflare:1.27.0
  ports:
    - "127.0.0.1:4000:4000"             # TYLKO localhost
  environment:
    DB_USERNAME: supabase_admin
    DB_PASSWORD: ${POSTGRES_PASSWORD}
    LOGFLARE_PUBLIC_ACCESS_TOKEN: ${LOGFLARE_PUBLIC_ACCESS_TOKEN}
    LOGFLARE_PRIVATE_ACCESS_TOKEN: ${LOGFLARE_PRIVATE_ACCESS_TOKEN}

vector:
  image: timberio/vector:0.28.1-alpine
  volumes:
    - ${DOCKER_SOCKET_LOCATION}:/var/run/docker.sock:ro,z   # Read-Only!
  security_opt:
    - "label=disable"

supavisor:
  image: supabase/supavisor:2.7.4
  ports:
    - "10.0.1.10:5432:5432"             # Pooler eksponuje port Postgres
    - "127.0.0.1:6543:6543"             # Transaction Mode
  environment:
    DATABASE_URL: ecto://supabase_admin:${POSTGRES_PASSWORD}@${POSTGRES_HOST}:${POSTGRES_PORT}/_supabase
    SECRET_KEY_BASE: ${SECRET_KEY_BASE}
    VAULT_ENC_KEY: ${VAULT_ENC_KEY}
    POOLER_DEFAULT_POOL_SIZE: ${POOLER_DEFAULT_POOL_SIZE}
    POOLER_MAX_CLIENT_CONN: ${POOLER_MAX_CLIENT_CONN}
```

### Co może pójść nie tak

Vector z dostępem do Docker Socket (`/var/run/docker.sock`) może czytać logi kontenerów. Socket powinien być zamontowany **Read-Only** (`:ro`). Analytics na porcie 4000 z domyślnymi tokenami eksponuje logi wszystkich usług. Supavisor na `0.0.0.0:5432` zamiast wewnętrznego interfejsu czyni Connection Pooler (a tym samym PostgreSQL) dostępnym z zewnątrz.

### Warunek weryfikowalny

```bash
# Analytics tylko wewnętrznie?
ss -tlnp | grep 4000
# Oczekiwanie: 127.0.0.1:4000

# Vector Docker Socket Read-Only?
grep "docker.sock" docker-compose.yml | grep ":ro"
# Oczekiwanie: :ro obecne

# Supavisor port tylko wewnętrznie?
ss -tlnp | grep 5432
# Oczekiwanie: 10.0.1.10:5432 (wewnętrzny interfejs)

# Tokeny Logflare nie na wartości domyślnej?
grep "LOGFLARE.*TOKEN" .env | grep -iE "your-\|change\|example"
# Oczekiwanie: brak trafień
```

## B8 - Studio: zabezpieczanie dashboardu

### Co robi ta usługa

Studio to interfejs webowy do zarządzania bazą danych, administracji użytkownikami i zapytań SQL. Poprzez `SERVICE_ROLE_KEY` i bezpośredni dostęp do Postgres ma **pełny dostęp do wszystkiego**.

### Konfiguracja istotna dla bezpieczeństwa

Studio jest chronione przez Kong za pomocą Basic Auth (DASHBOARD_USERNAME/DASHBOARD_PASSWORD). Dodatkowo Studio w produkcji nie powinno w ogóle działać lub być dostępne tylko przez tunel SSH.

**Opcja 1: Studio nie uruchamiać w produkcji (zalecane)**

```yaml
# W docker-compose.override.yml lub usunąć Studio z Compose
# Studio używać tylko lokalnie z supabase start do developmentu
```

**Opcja 2: Studio tylko przez tunel SSH**

```bash
# Ze stacji roboczej:
ssh -L 3000:localhost:3000 deploy@supabase-prod

# Następnie w przeglądarce: http://localhost:3000
```

### Warunek weryfikowalny

```bash
# Kontener Studio działa? (W produkcji nie powinien działać)
docker compose ps | grep studio
# Zalecenie: nie running w produkcji

# Jeśli Studio działa: niedostępne z zewnątrz?
curl -s -o /dev/null -w "%{http_code}" --connect-timeout 3 \
  "https://app.example.com:3000" 2>/dev/null
# Oczekiwanie: Timeout lub Connection Refused

# Hasło dashboardu silne?
DASH_LEN=$(grep "DASHBOARD_PASSWORD" .env | cut -d= -f2 | wc -c)
[ "$DASH_LEN" -lt 16 ] && echo "OSTRZEŻENIE: Hasło dashboardu za krótkie"
```

### Scenariusz awarii

Studio ze słabym hasłem dashboardu i publicznym dostępem daje atakującemu kompletny interfejs administracyjny bazy danych. Może wykonywać zapytania SQL, usuwać użytkowników, dezaktywować RLS i eksportować dane. To najgorszy scenariusz dla self-hosted stacku.

### Lista kontrolna usług

Po konfiguracji wszystkich usług, przed pierwszym użyciem produkcyjnym sprawdzić:

```
Sekrety
  [ ] Wszystkie sekrety wygenerowane (brak wartości domyślnych)
  [ ] JWT_SECRET co najmniej 32 znaki
  [ ] POSTGRES_PASSWORD co najmniej 24 znaki
  [ ] DASHBOARD_PASSWORD co najmniej 16 znaków
  [ ] SECRET_KEY_BASE co najmniej 64 znaki
  [ ] MINIO_ROOT_PASSWORD co najmniej 8 znaków (jeśli MinIO)
  [ ] DB_ENC_KEY zmieniony (nie "supabaserealtime")

PostgreSQL
  [ ] Port tylko na wewnętrznym interfejsie (10.0.1.10:5432)
  [ ] Skrypty Init niezmienione (roles.sql, jwt.sql itd.)
  [ ] Role poprawnie utworzone (anon nie jest superuserem)

Kong
  [ ] Port tylko na localhost (127.0.0.1:8000)
  [ ] JWT Validation aktywna na wszystkich trasach API
  [ ] Hasło dashboardu silne

GoTrue (Auth)
  [ ] JWT_EXP maksymalnie 3600
  [ ] AUTOCONFIRM false
  [ ] SMTP skonfigurowany i przetestowany
  [ ] SITE_URL i API_EXTERNAL_URL poprawne
  [ ] Rotacja Refresh Token aktywna
  [ ] DISABLE_SIGNUP ustawiony jeśli zamknięta aplikacja

PostgREST
  [ ] Używa roli authenticator (nie postgres)
  [ ] DB_SCHEMAS jawnie zdefiniowane

Realtime
  [ ] DB_ENC_KEY zmieniony
  [ ] SECRET_KEY_BASE co najmniej 64 znaki

Storage / MinIO
  [ ] MinIO niedostępne z zewnątrz
  [ ] Domyślne poświadczenia MinIO zmienione
  [ ] Uprawnienia wolumenu Storage poprawne

Usługi wewnętrzne
  [ ] Port Analytics tylko localhost
  [ ] Vector Docker Socket Read-Only
  [ ] Port Supavisor tylko wewnętrznie
  [ ] Tokeny Logflare nie na wartości domyślnej

Studio
  [ ] W produkcji dezaktywowane LUB tylko przez tunel SSH
  [ ] Hasło dashboardu silne
```

## Część C - Konfiguracja stacku Supabase

Te kroki dotyczą właściwej instalacji Supabase i jej ustawień istotnych z punktu widzenia bezpieczeństwa.

## C1 - Wersjonowanie deploymentu Supabase

### Realizacja

Wszystkie pliki infrastrukturalne należą do repozytorium Git. Deploymenty odbywają się wyłącznie przez to repozytorium, nigdy przez ręczne zmiany na serwerze.

```
infra/
  docker-compose.yml
  .env.example            (szablon, bez prawdziwych sekretów)
  caddy/
    Caddyfile
  postgres/
    migrations/
  scripts/
    backup.sh
    restore.sh
    health-check.sh
    security-check.sh
  runbooks/
    supabase-production.md
    security-baseline.md
```

### Workflow deploymentu

```bash
# Na serwerze
cd /opt/supabase
git pull origin main

# Załadowanie zmiennych środowiskowych (plik leży tylko na serwerze)
source .env

# Uruchomienie/aktualizacja stacku
docker compose up -d

# Health Check
./scripts/health-check.sh
```

### Sprawdzalny warunek

```bash
# Czy na serwerze są uncommitted zmiany?
cd /opt/supabase && git status --porcelain

# Oczekiwanie: puste (brak lokalnych zmian)

# Czy serwer jest na aktualnym stanie?
git log --oneline -1
# Porównanie z Remote
git fetch origin && git diff HEAD origin/main --stat

# Oczekiwanie: brak różnic
```

### Scenariusz awarii

Ręczne zmiany w `docker-compose.yml` na serwerze zostaną nadpisane przy następnym `git pull` lub spowodują konflikty merge. Co gorsza: nikt nie wie, jaka zmiana została dokonana kiedy i przez kogo. Po utracie serwera konfiguracja nie jest odtwarzalna.

## C2 - docker-compose.yml: minimalny stack produkcyjny

### Realizacja

Supabase dostarcza referencyjny plik Compose z ponad 400 liniami i ok. 15 serwisami. Nie wszystkie są potrzebne w produkcji. Oto decyzje istotne z punktu widzenia bezpieczeństwa:

**Minimalny stack (te serwisy są potrzebne):**

```
postgres          Baza danych
kong              API Gateway
gotrue            Auth
postgrest         REST API
realtime          WebSocket (jeśli potrzebny)
storage           File Storage (jeśli potrzebny)
meta              Metadane dla PostgREST
```

**Nie w produkcji (pominąć lub tylko wewnętrznie):**

```
studio            Admin UI, tylko przez tunel SSH lub VPN
imgproxy          tylko jeśli potrzebne transformacje obrazów
inbucket          tylko do lokalnych testów e-mail
```

Fragment konfiguracji istotnej z punktu widzenia bezpieczeństwa:

```yaml
# docker-compose.yml (fragment, części istotne dla bezpieczeństwa)

services:
  postgres:
    image: supabase/postgres:15.6.1.143    # Wersja przypięta
    restart: unless-stopped
    ports:
      - "10.0.1.10:5432:5432"              # TYLKO wewnętrzny interfejs
    environment:
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    volumes:
      - postgres-data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 30s
      timeout: 10s
      retries: 3

  kong:
    image: kong:2.8.1                       # Wersja przypięta
    restart: unless-stopped
    ports:
      - "127.0.0.1:8000:8000"              # TYLKO localhost (Reverse Proxy przed nim)
    environment:
      KONG_DNS_ORDER: LAST,A,CNAME
      KONG_PLUGINS: request-transformer,cors,key-auth,acl
      KONG_NGINX_PROXY_PROXY_BUFFER_SIZE: 160k
      KONG_NGINX_PROXY_PROXY_BUFFERS: 64 160k

  gotrue:
    image: supabase/gotrue:v2.164.0         # Wersja przypięta
    restart: unless-stopped
    environment:
      GOTRUE_JWT_SECRET: ${JWT_SECRET}
      GOTRUE_JWT_EXP: 3600                  # 1 godzina, nie więcej
      GOTRUE_EXTERNAL_EMAIL_ENABLED: true
      GOTRUE_MAILER_AUTOCONFIRM: false      # Wymuszenie potwierdzenia e-mail
      GOTRUE_DISABLE_SIGNUP: false           # ustawić na true jeśli rejestracja zamknięta
      GOTRUE_RATE_LIMIT_HEADER: X-Real-IP
      GOTRUE_SECURITY_REFRESH_TOKEN_ROTATION_ENABLED: true
      GOTRUE_SECURITY_REFRESH_TOKEN_REUSE_INTERVAL: 10
      API_EXTERNAL_URL: https://app.example.com

  postgrest:
    image: postgrest/postgrest:v12.2.3      # Wersja przypięta
    restart: unless-stopped
    environment:
      PGRST_DB_URI: postgres://authenticator:${POSTGRES_PASSWORD}@postgres:5432/postgres
      PGRST_DB_ANON_ROLE: anon
      PGRST_JWT_SECRET: ${JWT_SECRET}

volumes:
  postgres-data:

networks:
  default:
    driver: bridge
```

**Krytyczne punkty konfiguracji:**

```
GOTRUE_JWT_EXP: 3600         nie wyżej niż 3600 (1 godz.)
GOTRUE_MAILER_AUTOCONFIRM    false w produkcji
GOTRUE_DISABLE_SIGNUP         true jeśli brak otwartej rejestracji
REFRESH_TOKEN_ROTATION        true (zapobiega ponownemu użyciu tokena)
Wersje obrazów                zawsze przypiąć, nigdy :latest
Port Postgres                 tylko na wewnętrznym interfejsie
Port Kong                     tylko na localhost (Reverse Proxy przed nim)
```

### Sprawdzalny warunek

```bash
# Obrazy przypięte (żaden :latest)?
grep "image:" docker-compose.yml | grep -c "latest"
# Oczekiwanie: 0

# Postgres dostępny tylko wewnętrznie?
docker compose exec postgres ss -tlnp | grep 5432
# Oczekiwanie: tylko 10.0.1.10:5432 lub 0.0.0.0:5432 (wtedy sprawdzić firewall)

# Postgres niedostępny z zewnątrz?
nmap -p 5432 app.example.com
# Oczekiwanie: filtered lub closed

# JWT Expiry poprawny?
grep "GOTRUE_JWT_EXP" .env
# Oczekiwanie: 3600 lub mniej

# Supabase Studio niedostępne z zewnątrz?
curl -s -o /dev/null -w "%{http_code}" https://app.example.com:3000
# Oczekiwanie: Timeout lub Connection Refused
```

### Scenariusz awarii

Nieprzypięte obrazy (`image: supabase/gotrue:latest`) mogą przy `docker compose pull` niepostrzeżenie wprowadzić nową wersję zawierającą breaking changes lub znaną podatność. Jeśli Postgres nasłuchuje na `0.0.0.0:5432` i firewall tymczasowo przestanie działać, cała baza danych jest dostępna w internecie. Jeśli `GOTRUE_JWT_EXP` jest ustawiony na 86400 (24 godz.), skradziony token jest ważny przez cały dzień.

## C3 - Kompletne i bezpieczne zarządzanie sekretami

### Realizacja

Stack Supabase ma co najmniej te sekrety:

```bash
# .env (tylko na serwerze, nigdy w Git)

# Sekrety podstawowe
JWT_SECRET=                    # min. 32 znaki, wygenerowane przez openssl rand -base64 32
ANON_KEY=                      # Token JWT z rolą anon
SERVICE_ROLE_KEY=              # Token JWT z rolą service_role, omija RLS
POSTGRES_PASSWORD=             # min. 24 znaki, wygenerowane

# Dashboard
DASHBOARD_USERNAME=            # Login do Supabase Studio
DASHBOARD_PASSWORD=            # min. 16 znaków

# E-mail (GoTrue)
SMTP_HOST=
SMTP_PORT=
SMTP_USER=
SMTP_PASS=
SMTP_SENDER_NAME=

# Storage (jeśli backend S3)
S3_ACCESS_KEY=
S3_SECRET_KEY=
```

**Generowanie sekretów:**

```bash
# JWT Secret
openssl rand -base64 32

# Hasło Postgres
openssl rand -base64 24

# Klucze Anon i Service Role (Supabase CLI)
# Lub ręczne tworzenie JWT z JWT_SECRET
```

**Zarządzanie sekretami na serwerze:**

```bash
# Plik .env z restrykcyjnymi uprawnieniami
chmod 600 /opt/supabase/.env
chown deploy:deploy /opt/supabase/.env

# Sprawdzenie, czy .env nie jest w Git
cat /opt/supabase/.gitignore | grep ".env"
```

**W repozytorium leży tylko szablon:**

```bash
# .env.example (w Git)
JWT_SECRET=generate-with-openssl-rand-base64-32
ANON_KEY=generate-jwt-with-anon-role
SERVICE_ROLE_KEY=generate-jwt-with-service-role
POSTGRES_PASSWORD=generate-with-openssl-rand-base64-24
DASHBOARD_USERNAME=admin
DASHBOARD_PASSWORD=generate-min-16-chars
SMTP_HOST=
SMTP_PORT=587
SMTP_USER=
SMTP_PASS=
SMTP_SENDER_NAME=
```

Ta sama zasada obowiązuje przy każdym aspekcie [bezpieczeństwa danych w infrastrukturze AI dla przedsiębiorstw](/pl/magazyn/bezpieczenstwo-danych-ai-enterprise/).

### Sprawdzalny warunek

```bash
# .env nie jest w Git?
cd /opt/supabase && git ls-files .env
# Oczekiwanie: puste

# .env w .gitignore?
grep "^\.env$" .gitignore
# Oczekiwanie: .env

# Uprawnienia pliku poprawne?
stat -c "%a %U" .env
# Oczekiwanie: 600 deploy

# Sekrety mają wystarczającą długość?
awk -F= '{if (length($2) < 16 && $2 != "" && $1 !~ /PORT|HOST|NAME/) print "ZA KROTKIE: "$1}' .env
# Oczekiwanie: brak wyjścia

# Brak domyślnych haseł?
grep -iE "password|secret" .env | grep -iE "change.me|default|example|your.*here"
# Oczekiwanie: brak trafień
```

### Scenariusz awarii

Najczęstszym problemem bezpieczeństwa przy Supabase Self-Hosting nie jest exploit serwerowy, lecz wyciek sekretu. Jeśli `.env` zostanie commitnięty do Git, a repozytorium jest publiczne (lub stanie się publiczne), wszystkie sekrety leżą otwarte. Z kluczem `SERVICE_ROLE_KEY` można odczytywać i zapisywać całą bazę danych bez RLS.

## C4 - Sprawdzenie polityk bazodanowych

### Realizacja

W Supabase duża część bezpieczeństwa leży w PostgreSQL Row Level Security (RLS), a nie w serwerze aplikacyjnym. Każda tabela w schemacie `public` musi mieć aktywne RLS.

**Wyszukiwanie tabel bez RLS:**

```sql
-- Wszystkie tabele public bez RLS
SELECT schemaname, tablename, rowsecurity
FROM pg_tables
WHERE schemaname = 'public'
  AND rowsecurity = false;
```

**Wyszukiwanie tabel z RLS ale bez polityk:**

```sql
-- RLS aktywne, ale brak zdefiniowanej polityki = brak dostępu
-- (może być zamierzone, ale należy sprawdzić)
SELECT t.tablename
FROM pg_tables t
LEFT JOIN pg_policies p ON t.tablename = p.tablename
WHERE t.schemaname = 'public'
  AND t.rowsecurity = true
  AND p.policyname IS NULL;
```

**Wyszukiwanie zbyt otwartych polityk:**

```sql
-- Polityki dające wszystkim rolom pełny dostęp
SELECT tablename, policyname, permissive, roles, cmd, qual
FROM pg_policies
WHERE schemaname = 'public'
  AND (roles = '{public}' OR qual = 'true');
```

**Sprawdzenie użycia Service Role:**

```sql
-- Jakie role istnieją i jakie mają uprawnienia?
SELECT rolname, rolsuper, rolcreaterole, rolcreatedb
FROM pg_roles
WHERE rolname IN ('anon', 'authenticated', 'service_role', 'authenticator');
```

### Sprawdzalny warunek

```bash
# Jako zautomatyzowany skrypt z audit-runner
ssh supabase-prod "docker compose exec -T postgres psql -U postgres -c \"
  SELECT tablename FROM pg_tables
  WHERE schemaname = 'public' AND rowsecurity = false;
\""

# Oczekiwanie: brak tabel (lub tylko świadomie wyłączone)
```

### Scenariusz awarii

Tabela `users` z `rowsecurity = false` jest przez PostgREST API w pełni odczytywalna dla każdego z kluczem `anon`. Dotyczy to wszystkich kolumn, w tym adresów e-mail, numerów telefonów i innych danych osobowych. Wystarczy proste polecenie `curl` z publicznym kluczem `anon`.

## Część D - Eksploatacja i monitoring

Te kroki działają regularnie i zautomatyzowanie.

## D1 - Automatyzacja kopii zapasowych

### Realizacja

Codzienne dumpy PostgreSQL, zaszyfrowane i przechowywane zewnętrznie.

```bash
#!/bin/bash
# scripts/backup.sh

set -euo pipefail

BACKUP_DIR="/opt/backups"
DATE=$(date +%Y-%m-%d_%H%M)
RETENTION_DAYS=30
GPG_RECIPIENT="backup@example.com"   # GPG Key ID

# Dump PostgreSQL
docker compose exec -T postgres pg_dump \
  -U postgres \
  --format=custom \
  --compress=9 \
  postgres > "${BACKUP_DIR}/db_${DATE}.dump"

# Kopia zapasowa bucketów Storage (jeśli Supabase Storage jest używany)
docker compose exec -T storage tar -czf - /var/lib/storage \
  > "${BACKUP_DIR}/storage_${DATE}.tar.gz"

# Szyfrowanie
for file in "${BACKUP_DIR}"/*_${DATE}.*; do
  gpg --encrypt --recipient "${GPG_RECIPIENT}" "$file"
  rm "$file"   # Usunięcie niezaszyfrowanej wersji
done

# Kopiowanie na zewnętrzny serwer (audit-runner lub S3)
rsync -az "${BACKUP_DIR}/"*_${DATE}*.gpg \
  deploy@10.0.1.11:/opt/backup-archive/

# Usuwanie starych kopii zapasowych (lokalnie)
find "${BACKUP_DIR}" -name "*.gpg" -mtime +${RETENTION_DAYS} -delete

# Na serwerze backupowym również porządkowanie
ssh deploy@10.0.1.11 \
  "find /opt/backup-archive -name '*.gpg' -mtime +${RETENTION_DAYS} -delete"

echo "Kopia zapasowa ${DATE} zakończona"
```

```bash
# Konfiguracja zadania Cron
# crontab -e
0 3 * * * /opt/supabase/scripts/backup.sh >> /var/log/backup.log 2>&1
```

### Sprawdzalny warunek

```bash
# Kopia zapasowa z dzisiaj istnieje?
ls -la /opt/backups/*_$(date +%Y-%m-%d)*.gpg

# Kopia zapasowa dotarła na zewnętrzny serwer?
ssh deploy@10.0.1.11 "ls -la /opt/backup-archive/*_$(date +%Y-%m-%d)*.gpg"

# Rozmiar kopii zapasowej wiarygodny (nie 0 bajtów)?
find /opt/backups -name "*.gpg" -size 0 -print
# Oczekiwanie: brak trafień
```

### Scenariusz awarii

Przechowywanie kopii zapasowych tylko na tym samym serwerze oznacza: jeśli serwer ulegnie awarii lub zostanie zaszyfrowany (ransomware), kopie zapasowe również przepadają. Niezaszyfrowane kopie zapasowe na zewnętrznym serwerze stanowią wyciek danych, ponieważ dump zawiera wszystkie dane tabel w postaci jawnej.

## D2 - Regularne testowanie przywracania

### Realizacja

Raz w miesiącu przywrócić kopię zapasową na systemie testowym.

```bash
#!/bin/bash
# scripts/restore-test.sh

set -euo pipefail

BACKUP_FILE=$1   # np. /opt/backup-archive/db_2026-03-01_0300.dump.gpg

# Odszyfrowanie
gpg --decrypt "$BACKUP_FILE" > /tmp/restore-test.dump

# Uruchomienie kontenera testowego
docker run -d --name restore-test \
  -e POSTGRES_PASSWORD=testpassword \
  supabase/postgres:15.6.1.143

sleep 10

# Przywrócenie
docker exec -i restore-test pg_restore \
  -U postgres \
  --dbname=postgres \
  --clean \
  --if-exists \
  < /tmp/restore-test.dump

# Sprawdzenie tabel
docker exec restore-test psql -U postgres -c \
  "SELECT schemaname, tablename FROM pg_tables WHERE schemaname = 'public';"

# Sprawdzenie liczby wierszy
docker exec restore-test psql -U postgres -c \
  "SELECT relname, n_live_tup FROM pg_stat_user_tables ORDER BY n_live_tup DESC LIMIT 10;"

# Porządkowanie
docker rm -f restore-test
rm /tmp/restore-test.dump

echo "Test przywracania zakończony"
```

### Sprawdzalny warunek

```bash
# Uruchomienie skryptu testu przywracania i sprawdzenie kodu wyjścia
./scripts/restore-test.sh /opt/backup-archive/db_latest.dump.gpg
echo $?
# Oczekiwanie: 0

# Sprawdzenie logu ostatniego testu przywracania
cat /var/log/restore-test.log | tail -20
```

### Scenariusz awarii

Wiele zespołów ma kopie zapasowe, które działają od miesięcy, ale nigdy nie testowało przywracania. Typowe problemy: niewłaściwy format `pg_dump` (Plain Text zamiast Custom), brakujące uprawnienia przy przywracaniu, niekompatybilne wersje PostgreSQL między kopią zapasową a przywróceniem. Wszystko to ujawnia się dopiero wtedy, gdy przywrócenie jest naprawdę potrzebne.

## D3 - Codzienne kontrole infrastruktury

### Realizacja

Skrypt na audit-runner sprawdza codziennie stan systemu produkcyjnego.

```bash
#!/bin/bash
# scripts/security-check.sh (działa na audit-runner)

set -euo pipefail

PROD_HOST="10.0.1.10"
REPORT=""
CRITICAL=0

# 1. Status kontenerów
STOPPED=$(ssh deploy@${PROD_HOST} "docker compose ps --format json" | \
  jq -r 'select(.State != "running") | .Name')
if [ -n "$STOPPED" ]; then
  REPORT+="KRYTYCZNE: Kontenery nie działają: ${STOPPED}\n"
  CRITICAL=1
fi

# 2. Otwarte porty z zewnątrz
OPEN_PORTS=$(nmap -p 22,80,443,3000,5432,8000,9000 app.example.com \
  --open -oG - | grep "/open/" | grep -v "443/open")
if [ -n "$OPEN_PORTS" ]; then
  REPORT+="KRYTYCZNE: Nieoczekiwane otwarte porty: ${OPEN_PORTS}\n"
  CRITICAL=1
fi

# 3. Data wygaśnięcia certyfikatu
CERT_EXPIRY=$(echo | openssl s_client -connect app.example.com:443 2>/dev/null | \
  openssl x509 -noout -enddate | cut -d= -f2)
CERT_EPOCH=$(date -d "$CERT_EXPIRY" +%s)
NOW_EPOCH=$(date +%s)
DAYS_LEFT=$(( (CERT_EPOCH - NOW_EPOCH) / 86400 ))
if [ "$DAYS_LEFT" -lt 14 ]; then
  REPORT+="OSTRZEŻENIE: Certyfikat TLS wygasa za ${DAYS_LEFT} dni\n"
fi

# 4. Dryft firewalla
FIREWALL_DIFF=$(ssh deploy@${PROD_HOST} "iptables-save" | \
  diff /opt/baselines/firewall-baseline.txt - || true)
if [ -n "$FIREWALL_DIFF" ]; then
  REPORT+="OSTRZEŻENIE: Firewall uległ zmianie:\n${FIREWALL_DIFF}\n"
fi

# 5. Wersje obrazów Docker (dryft wobec baseliny)
IMAGE_DIFF=$(ssh deploy@${PROD_HOST} \
  "docker compose images --format '{{.Repository}}:{{.Tag}}'" | \
  diff /opt/baselines/image-versions.txt - || true)
if [ -n "$IMAGE_DIFF" ]; then
  REPORT+="OSTRZEŻENIE: Wersje kontenerów uległy zmianie:\n${IMAGE_DIFF}\n"
fi

# 6. Przestrzeń dyskowa
DISK_USAGE=$(ssh deploy@${PROD_HOST} "df -h / | tail -1 | awk '{print \$5}' | tr -d '%'")
if [ "$DISK_USAGE" -gt 85 ]; then
  REPORT+="OSTRZEŻENIE: Użycie dysku na poziomie ${DISK_USAGE}%\n"
fi

# 7. Status kopii zapasowej
LAST_BACKUP=$(ssh deploy@${PROD_HOST} "ls -t /opt/backups/*.gpg 2>/dev/null | head -1")
if [ -z "$LAST_BACKUP" ]; then
  REPORT+="KRYTYCZNE: Nie znaleziono kopii zapasowej\n"
  CRITICAL=1
else
  BACKUP_AGE=$(ssh deploy@${PROD_HOST} \
    "echo \$(( (\$(date +%s) - \$(stat -c %Y ${LAST_BACKUP})) / 3600 ))")
  if [ "$BACKUP_AGE" -gt 26 ]; then
    REPORT+="OSTRZEŻENIE: Ostatnia kopia zapasowa ma ${BACKUP_AGE} godzin\n"
  fi
fi

# 8. Sprawdzenie RLS
UNPROTECTED=$(ssh deploy@${PROD_HOST} "docker compose exec -T postgres psql -U postgres -t -c \
  \"SELECT count(*) FROM pg_tables WHERE schemaname = 'public' AND rowsecurity = false;\"" | tr -d ' ')
if [ "$UNPROTECTED" -gt 0 ]; then
  REPORT+="OSTRZEŻENIE: ${UNPROTECTED} tabel bez RLS\n"
fi

# Wynik
echo "=== Kontrola bezpieczeństwa $(date) ==="
if [ -n "$REPORT" ]; then
  echo -e "$REPORT"
else
  echo "Wszystkie kontrole zaliczone"
fi

# Przy krytycznych ustaleniach: wysłanie alertu
if [ "$CRITICAL" -eq 1 ]; then
  echo -e "$REPORT" | mail -s "KRYTYCZNE: Kontrola bezpieczeństwa $(date)" ops@example.com
fi
```

```bash
# Cron na audit-runner
0 7 * * * /opt/audit/scripts/security-check.sh >> /var/log/security-check.log 2>&1
```

### Sprawdzalny warunek

```bash
# Czy skrypt kontroli działał dzisiaj?
grep "$(date +%Y-%m-%d)" /var/log/security-check.log | tail -1
# Oczekiwanie: wpis z dzisiaj

# Wynik?
grep "Wszystkie kontrole zaliczone\|KRYTYCZNE\|OSTRZEŻENIE" /var/log/security-check.log | tail -5
```

## D4 - Claude Code jako kontekstowa warstwa analizy

Claude Code analizuje wyniki deterministycznych kontroli i rozpoznaje związki, których skrypty nie widzą.

### Architektura

```
Codzienne kontrole (D3)
     |
     +-- Deterministyczne ustalenia
     |   (otwarte porty, dryft firewalla, brakujące kopie zapasowe)
     |
     +---> Cotygodniowy przegląd Claude Code
          |
          +-- Pliki konfiguracyjne (docker-compose.yml, Caddyfile, .env.example)
          +-- Logi kontroli bezpieczeństwa z ostatnich 7 dni
          +-- Git Diff zmian infrastrukturalnych
          +-- Eksport polityk RLS
          |
          +---> Priorytetyzowany raport
               |
               +---> Decyzja DevOps (człowiek)
```

### Konkretny skrypt

```bash
#!/bin/bash
# scripts/claude-review-prep.sh (działa na audit-runner)

REPORT_DIR="/opt/audit/weekly-reports"
DATE=$(date +%Y-%m-%d)
OUTPUT="${REPORT_DIR}/review-input-${DATE}.md"

mkdir -p "$REPORT_DIR"

cat > "$OUTPUT" << 'HEADER'
# Cotygodniowy przegląd bezpieczeństwa - dane wejściowe

## Kontekst
Self-hosted stack Supabase na Hetzner Cloud.
Architektura: Reverse Proxy -> Kong -> Supabase Services -> PostgreSQL
System audytowy na oddzielnym serwerze.
HEADER

# Logi kontroli bezpieczeństwa z ostatnich 7 dni
echo -e "\n## Wyniki kontroli bezpieczeństwa (ostatnie 7 dni)\n" >> "$OUTPUT"
echo '```' >> "$OUTPUT"
grep -A 20 "Security Check" /var/log/security-check.log | \
  tail -100 >> "$OUTPUT"
echo '```' >> "$OUTPUT"

# Aktualna konfiguracja Docker Compose (bez sekretów)
echo -e "\n## Aktualna docker-compose.yml\n" >> "$OUTPUT"
echo '```yaml' >> "$OUTPUT"
ssh deploy@10.0.1.10 "cat /opt/supabase/docker-compose.yml" >> "$OUTPUT"
echo '```' >> "$OUTPUT"

# Git Diff z ostatniego tygodnia
echo -e "\n## Zmiany infrastrukturalne (ostatnie 7 dni)\n" >> "$OUTPUT"
echo '```' >> "$OUTPUT"
ssh deploy@10.0.1.10 "cd /opt/supabase && git log --oneline --since='7 days ago'" >> "$OUTPUT"
ssh deploy@10.0.1.10 "cd /opt/supabase && git diff HEAD~5 --stat" >> "$OUTPUT" 2>/dev/null
echo '```' >> "$OUTPUT"

# Status RLS
echo -e "\n## Status RLS\n" >> "$OUTPUT"
echo '```' >> "$OUTPUT"
ssh deploy@10.0.1.10 "docker compose exec -T postgres psql -U postgres -c \"
  SELECT tablename, rowsecurity FROM pg_tables WHERE schemaname = 'public' ORDER BY tablename;
\"" >> "$OUTPUT"
echo '```' >> "$OUTPUT"

# Wersje kontenerów
echo -e "\n## Wersje kontenerów\n" >> "$OUTPUT"
echo '```' >> "$OUTPUT"
ssh deploy@10.0.1.10 "docker compose images --format '{{.Repository}}:{{.Tag}}'" >> "$OUTPUT"
echo '```' >> "$OUTPUT"

echo "Dane wejściowe do przeglądu utworzone: $OUTPUT"
```

### Czego Claude Code nie robi

```
Claude NIE wykonuje automatycznych zmian na produkcji.
Claude NIE deployuje.
Claude NIE rotuje sekretów.
Claude NIE ma bezpośredniego dostępu do serwera produkcyjnego.

Claude analizuje dane, które mu przekazano,
i tworzy raporty do decyzji podejmowanych przez ludzi.
```

## Lista kontrolna deploymentu

Przed pierwszym uruchomieniem i po większych zmianach:

```
Część A - Infrastruktura
  [ ] Dwa oddzielne serwery (prod + audit)
  [ ] Sieć prywatna skonfigurowana i przetestowana
  [ ] Cloud Firewall aktywny (tylko 443, SSH z IP administratora)
  [ ] Host Firewall aktywny (iptables)
  [ ] Baselina firewalla zapisana
  [ ] SSH: tylko klucze, bez root, bez hasła
  [ ] Reverse Proxy skonfigurowany (Caddy/Nginx)
  [ ] TLS aktywny z automatycznym odnawianiem
  [ ] Nagłówki bezpieczeństwa ustawione (HSTS, CSP, X-Frame-Options)
  [ ] Proxy WebSocket dla Realtime skonfigurowane

Część B - Usługi Supabase
  Sekrety (B0)
    [ ] Wszystkie sekrety wygenerowane (brak wartości domyślnych)
    [ ] JWT_SECRET co najmniej 32 znaki
    [ ] POSTGRES_PASSWORD co najmniej 24 znaki
    [ ] DASHBOARD_PASSWORD co najmniej 16 znaków
    [ ] SECRET_KEY_BASE co najmniej 64 znaki
    [ ] MINIO_ROOT_PASSWORD co najmniej 8 znaków (jeśli MinIO)
    [ ] DB_ENC_KEY zmieniony (nie "supabaserealtime")
  PostgreSQL (B1)
    [ ] Port tylko na wewnętrznym interfejsie (10.0.1.10:5432)
    [ ] Skrypty Init niezmienione (roles.sql, jwt.sql itd.)
    [ ] Role poprawnie utworzone (anon nie jest superuserem)
  Kong (B2)
    [ ] Port tylko na localhost (127.0.0.1:8000)
    [ ] JWT Validation aktywna na wszystkich trasach API
    [ ] Hasło dashboardu silne
  GoTrue (B3)
    [ ] JWT_EXP maksymalnie 3600
    [ ] AUTOCONFIRM false
    [ ] SMTP skonfigurowany i przetestowany
    [ ] SITE_URL i API_EXTERNAL_URL poprawne
    [ ] Rotacja Refresh Token aktywna
    [ ] DISABLE_SIGNUP ustawiony jeśli zamknięta aplikacja
  PostgREST (B4)
    [ ] Używa roli authenticator (nie postgres)
    [ ] DB_SCHEMAS jawnie zdefiniowane
  Realtime (B5)
    [ ] DB_ENC_KEY zmieniony
    [ ] SECRET_KEY_BASE co najmniej 64 znaki
  Storage / MinIO (B6)
    [ ] MinIO niedostępne z zewnątrz
    [ ] Domyślne poświadczenia MinIO zmienione
    [ ] Uprawnienia wolumenu Storage poprawne
  Usługi wewnętrzne (B7)
    [ ] Port Analytics tylko localhost
    [ ] Vector Docker Socket Read-Only
    [ ] Port Supavisor tylko wewnętrznie
    [ ] Tokeny Logflare nie na wartości domyślnej
  Studio (B8)
    [ ] W produkcji dezaktywowane LUB tylko przez tunel SSH
    [ ] Hasło dashboardu silne

Część C - Konfiguracja stacku
  [ ] docker-compose.yml wersjonowany w Git
  [ ] Wszystkie wersje obrazów przypięte (żaden :latest)
  [ ] .env nie jest w Git
  [ ] Uprawnienia pliku .env 600
  [ ] .env.example w Git jako szablon
  [ ] Brak domyślnych haseł
  [ ] RLS aktywne na wszystkich tabelach public
  [ ] Brak tabel bez polityk (chyba że świadomie)
  [ ] Brak zbyt otwartych polityk (qual = 'true')

Część D - Eksploatacja i monitoring
  [ ] Codzienny job kopii zapasowej aktywny
  [ ] Kopie zapasowe zaszyfrowane
  [ ] Kopie zapasowe przechowywane zewnętrznie (audit-runner lub S3)
  [ ] Test przywracania przeprowadzony co najmniej raz
  [ ] Strategia retencji skonfigurowana
  [ ] Codzienny job kontroli bezpieczeństwa na audit-runner
  [ ] Alerting przy krytycznych ustaleniach
  [ ] Cotygodniowy przegląd Claude Code skonfigurowany

Część E - Aktualizacje i konserwacja
  [ ] Unattended Upgrades zainstalowane i aktywne
  [ ] Interwał automatycznych aktualizacji ustawiony na codziennie
  [ ] Obrazy Supabase przypięte (bez :latest)
  [ ] Żaden obraz Supabase nie starszy niż 90 dni
  [ ] Commit aktualizacji w ciągu ostatnich 45 dni
  [ ] Skrypt auto-patch dla PostgreSQL minor patches aktywny
  [ ] Cron auto-patch PO cron backup (03:00 po 02:00)
  [ ] Monitor wydań bezpieczeństwa na audit-runner aktywny (codziennie)
  [ ] Trivy zainstalowane na audit-runner
  [ ] Cron sprawdzania konserwacji na audit-runner (cotygodniowo poniedziałek)
  [ ] Certyfikat TLS ważny co najmniej 14 dni
  [ ] Wykorzystanie dysku poniżej 85%
```

## Część E - Aktualizacje i konserwacja

Stack self-hosted, który nie jest regularnie aktualizowany, gromadzi luki bezpieczeństwa. Niezałatane CVE w PostgreSQL, Kong lub GoTrue to realne wektory ataku. Jednocześnie aktualizacje mogą wprowadzać Breaking Changes, które unieruchamiają stack.

Dlatego proces aktualizacji potrzebuje jasnych reguł: co jest aktualizowane kiedy, jak jest testowane i jak zapewnić, że nic nie zostanie pominięte.

### E1 - Trzy warstwy aktualizacji

Stack ma trzy niezależne warstwy aktualizacji o różnych rytmach i ryzykach.

```
Warstwa 1: Poziom OS (Ubuntu)
   │  Co: Kernel, pakiety systemowe, OpenSSL, Docker Engine
   │  Rytm: Cotygodniowe łatki bezpieczeństwa, comiesięczna pełna aktualizacja
   │  Ryzyko: Niskie (apt upgrade jest stabilne)
   │  Metoda: apt update && apt upgrade
   │
Warstwa 2: Usługi Supabase (obrazy Docker)
   │  Co: PostgreSQL, Kong, GoTrue, PostgREST, Realtime, Storage, etc.
   │  Rytm: Comiesięcznie (cykl wydań Supabase)
   │  Ryzyko: Średnie do wysokiego (Breaking Changes między wersjami)
   │  Metoda: Zmiana tagów obrazów w docker-compose.yml, pull, restart
   │
Warstwa 3: Reverse Proxy i narzędzia
   │  Co: Caddy, iptables, GPG, nmap, jq
   │  Rytm: Przy Security Advisories lub kwartalnie
   │  Ryzyko: Niskie
   │  Metoda: apt upgrade (Caddy przez własne repo)
```

**Sprawdzalny warunek:**

```bash
# OS: Wann war das letzte apt upgrade?
stat -c %y /var/cache/apt/pkgcache.bin
# Erwartung: weniger als 7 Tage alt

# Supabase: Welche Image-Versionen laufen?
cd /opt/supabase && docker compose images --format '{{.Repository}}:{{.Tag}}'

# Caddy Version
caddy version
```

**Scenariusz awarii:** Niezałatany PostgreSQL ze znaną podatnością Remote Code Execution (jak CVE-2023-5869) może zostać wykorzystany przez atakującego, nawet jeśli RLS jest poprawnie skonfigurowany. Przestarzały Kong ze znaną podatnością Auth-Bypass może obejść walidację JWT.

### E2 - Aktualizacje na poziomie OS

**Cotygodniowo: łatki bezpieczeństwa (automatycznie)**

```bash
# Unattended Upgrades installieren und konfigurieren
sudo apt install -y unattended-upgrades

# Konfiguration: nur Security Updates automatisch
sudo tee /etc/apt/apt.conf.d/50unattended-upgrades > /dev/null << 'EOF'
Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
};

// Automatischer Reboot wenn nötig (z.B. Kernel Update)
// Nur aktivieren wenn ihr damit leben könnt dass der Server
// um 4:00 Uhr nachts kurz neustartet
Unattended-Upgrade::Automatic-Reboot "false";

// E-Mail Benachrichtigung bei Updates
Unattended-Upgrade::Mail "ops@example.com";
Unattended-Upgrade::MailReport "on-change";
EOF

# Automatische Updates aktivieren
sudo tee /etc/apt/apt.conf.d/20auto-upgrades > /dev/null << 'EOF'
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::AutocleanInterval "7";
EOF

sudo systemctl enable unattended-upgrades
sudo systemctl start unattended-upgrades
```

**Comiesięcznie: pełna aktualizacja systemu (ręcznie, ze sprawdzeniem)**

```bash
# Zuerst prüfen was aktualisiert wird
apt list --upgradable

# Dann updaten
sudo apt update && sudo apt upgrade -y

# Docker Engine Update (separat, über Docker Repo)
sudo apt install --only-upgrade docker-ce docker-ce-cli containerd.io

# Nach Kernel-Updates: Reboot nötig?
if [ -f /var/run/reboot-required ]; then
  echo "REBOOT ERFORDERLICH"
fi
```

**Sprawdzalny warunek:**

```bash
# Unattended Upgrades aktiv?
systemctl is-active unattended-upgrades

# Letzte automatische Updates
cat /var/log/unattended-upgrades/unattended-upgrades.log | tail -20

# Ausstehende Security Updates?
apt list --upgradable 2>/dev/null | grep -i security | wc -l
# Erwartung: 0
```

### E3 - Aktualizacje usług Supabase

Supabase publikuje mniej więcej co miesiąc nowe obrazy Docker. Proces aktualizacji musi przebiegać w sposób kontrolowany, ponieważ Breaking Changes między wersjami są możliwe.

**Workflow:**

```
1. Release Notes lesen (github.com/supabase/supabase/releases)
2. Neue Image Tags in docker-compose.yml eintragen
3. Auf Staging/Test testen (oder: Backup + Rollback-Plan)
4. Backup erstellen
5. docker compose pull
6. docker compose down && docker compose up -d
7. Health Checks prüfen
8. Baselines aktualisieren
```

**Sprawdzenie aktualnych wersji vs. dostępnych:**

```bash
cd /opt/supabase

echo "=== Aktuelle Versionen ==="
docker compose images --format '{{.Repository}}:{{.Tag}}'

echo ""
echo "=== Verfügbare Updates ==="
# Die offiziellen Releases prüfen
echo "Supabase Releases: https://github.com/supabase/supabase/releases"
echo "GoTrue: https://github.com/supabase/gotrue/releases"
echo "PostgREST: https://github.com/PostgREST/postgrest/releases"
echo "Realtime: https://github.com/supabase/realtime/releases"
echo ""
echo "Oder den offiziellen docker-compose.yml vergleichen:"
echo "https://raw.githubusercontent.com/supabase/supabase/master/docker/docker-compose.yml"
```

**Bezpieczna procedura aktualizacji:**

```bash
cd /opt/supabase

# 1. Backup VOR dem Update
./scripts/backup.sh

# 2. Aktuelle Versionen dokumentieren
docker compose images --format '{{.Repository}}:{{.Tag}}' > /opt/baselines/pre-update-versions.txt

# 3. Neue Versionen in docker-compose.yml eintragen
# MANUELL: Image Tags auf die neue Version ändern
# z.B. supabase/gotrue:v2.164.0 → supabase/gotrue:v2.184.0

# 4. Pull neue Images
docker compose pull

# 5. Stack neu starten
docker compose down
docker compose up -d

# 6. Warten und Health Checks
sleep 30
docker compose ps --format "table {{.Name}}\t{{.Status}}"

# 7. Alle Services prüfen
docker compose exec -T auth wget --no-verbose --tries=1 --spider http://localhost:9999/health
docker compose exec -T db pg_isready -U postgres -h localhost
curl -s -o /dev/null -w "Kong: %{http_code}\n" http://localhost:8000
curl -s -o /dev/null -w "Storage: %{http_code}\n" http://localhost:8000/storage/v1/

# 8. Baselines aktualisieren
docker compose images --format '{{.Repository}}:{{.Tag}}' > /opt/baselines/image-versions.txt

# 9. Git Commit
git add docker-compose.yml
git commit -m "Update Supabase images to [VERSION]"
```

**Rollback w przypadku problemów:**

```bash
cd /opt/supabase

# Alte Versionen wiederherstellen
git checkout HEAD~1 -- docker-compose.yml
docker compose pull
docker compose down
docker compose up -d

# Wenn Datenbank-Migration das Problem ist:
./scripts/restore.sh /opt/backups/[LETZTES_BACKUP].gpg
```

**Sprawdzalny warunek:**

```bash
# Image-Versionen älter als 3 Monate?
cd /opt/supabase
docker compose images --format '{{.Repository}}:{{.Tag}}' | while read image; do
  CREATED=$(docker inspect --format='{{.Created}}' "$image" 2>/dev/null | cut -dT -f1)
  if [ -n "$CREATED" ]; then
    AGE_DAYS=$(( ($(date +%s) - $(date -d "$CREATED" +%s)) / 86400 ))
    [ "$AGE_DAYS" -gt 90 ] && echo "WARNUNG: $image ist $AGE_DAYS Tage alt"
  fi
done
```

**Scenariusz awarii:** Supabase GoTrue v2.170.0 miał zmianę w obsłudze Refresh Token, która złamała starsze klienty. Bez wcześniejszego przeczytania Release Notes i bez kopii zapasowej oznaczałoby to awarię. Aktualizacje Major Version PostgreSQL (np. 15 -> 16) wymagają cyklu `pg_dump/pg_restore`, sama zmiana tagu obrazu nie wystarczy.

### E3b - Automatyczne łatanie (Warstwa 1)

Nie wszystkie aktualizacje wymagają człowieka. Drobne łatki PostgreSQL i aktualizacje Caddy są niskoryzyczne i mogą być wdrażane automatycznie w nocy.

**Model dwuwarstwowy:**

```
WARSTWA 1 - AUTOMATYCZNIE (auto-patch.sh, codziennie 03:00):
  OS Security Patches (unattended-upgrades)
  PostgreSQL Minor Patches (15.8.1.x -> 15.8.1.y)
  Caddy Updates
  -> Info-Mail nach erfolgreichem Patch
  -> Alarm-Mail bei Health Check Fehler
  -> Automatischer Rollback bei Fehler

WARSTWA 2 - RĘCZNIE (/supabase-update, w ciągu 24h po alercie):
  GoTrue/Auth (Breaking Changes möglich)
  PostgREST (Query-Verhalten kann sich ändern)
  Kong (Routing kann sich ändern)
  Realtime, Storage, Supavisor
  PostgreSQL MAJOR (15 -> 16, braucht pg_dump/pg_restore)
```

Skrypt `auto-patch.sh` działa codziennie o 03:00 (po kopii zapasowej o 02:00) i:

1. Sprawdza, czy istnieje aktualna kopia zapasowa (przerwanie, jeśli nie)
2. Zabezpiecza bieżący stan (docker-compose.yml, wersje obrazów)
3. Sprawdza, czy dostępny jest nowy obraz PostgreSQL Minor
4. Wdraża go i wykonuje Health Check
5. W przypadku błędu: automatyczny rollback do poprzedniej wersji
6. Wysyła Info-Mail (sukces) lub Alarm-Mail (błąd)

**Sprawdzalny warunek:**

```bash
# Auto-Patch Cron aktiv?
crontab -l | grep auto-patch
# Erwartung: 0 3 * * * /opt/supabase/scripts/auto-patch.sh

# Letzter Auto-Patch Lauf?
tail -20 /var/log/auto-patch.log

# Hat Auto-Patch jemals gepatcht?
grep "Patches eingespielt\|Keine Patches" /var/log/auto-patch.log | tail -5
```

**Harmonogram Cron (serwer prod):**

```
02:00 codziennie  -> Backup (DB + Storage + zewnętrznie)
03:00 codziennie  -> Auto-Patch (PostgreSQL Minor + Caddy)
04:00 miesięcznie -> Test przywracania
```

### E4 - Harmonogram aktualizacji i odpowiedzialności

```
Cotygodniowo (automatycznie):
  [ ] OS Security Patches (unattended-upgrades)
  [ ] Audit-Runner sprawdza, czy łatki zostały zastosowane

Comiesięcznie (ręcznie, zaplanowane):
  [ ] Sprawdzenie Supabase Release Notes
  [ ] Ocena nowych tagów obrazów
  [ ] Utworzenie kopii zapasowej
  [ ] Przeprowadzenie aktualizacji
  [ ] Health Checks
  [ ] Aktualizacja baselines

Kwartalnie (przegląd):
  [ ] Sprawdzenie wersji Caddy
  [ ] Sprawdzenie wersji Docker Engine
  [ ] Sprawdzenie wersji Node.js (dla Claude Code na audit-runner)
  [ ] Ocena Major Version PostgreSQL
  [ ] Czy cały toolchain jest aktualny?

Przy Security Advisories (natychmiast):
  [ ] Czy CVE dotyczy naszego stacku?
  [ ] Identyfikacja dotkniętego obrazu/pakietu
  [ ] Czy łatka jest dostępna?
  [ ] Przeprowadzenie awaryjnej aktualizacji
```

**Sprawdzalny warunek:**

```bash
# Wann war das letzte Supabase Update?
cd /opt/supabase
git log --oneline --grep="Update\|update\|upgrade" | head -5

# Wie alt ist der letzte Update-Commit?
LAST_UPDATE=$(git log --format="%ai" --grep="Update\|update" -1 2>/dev/null | cut -d' ' -f1)
if [ -n "$LAST_UPDATE" ]; then
  AGE=$(( ($(date +%s) - $(date -d "$LAST_UPDATE" +%s)) / 86400 ))
  echo "Letztes Update: $LAST_UPDATE ($AGE Tage her)"
  [ "$AGE" -gt 45 ] && echo "WARNUNG: Letztes Update über 45 Tage her"
fi
```

### E5 - Monitor wydań bezpieczeństwa (codziennie)

Największym martwym punktem w self-hostingu nie jest konfiguracja początkowa, lecz przeoczenie łatek bezpieczeństwa. Gdy Supabase GoTrue publikuje poprawkę Auth-Bypass, zespół musi zareagować w ciągu 24 godzin, a nie po tygodniu.

Na audit-runner działa **codziennie** skrypt, który sprawdza wydania GitHub wszystkich komponentów Supabase i przy wydaniach bezpieczeństwa natychmiast alarmuje e-mailem.

**Sprawdzane komponenty:**

```
supabase/auth (GoTrue)          -> häufige Security Patches
PostgREST/postgrest             -> API-Layer
supabase/realtime               -> WebSocket
supabase/storage-api            -> File Storage
Kong/kong                       -> API Gateway
supabase/edge-runtime           -> Edge Functions
supabase/postgres               -> Datenbank Image
supabase/supavisor              -> Connection Pooler
moby/moby (Docker Engine)       -> Container Runtime
```

**Trzy warstwy sprawdzania:**

```
Warstwa 1: GitHub Releases
  -> Czy jest nowa wersja?
  -> Czy Release Notes zawierają "security"/"CVE"?

Warstwa 2: Trivy Container Scan
  -> Skanuje każdy działający obraz Docker przeciwko NVD/GitHub Advisories
  -> Znajduje CVE we wszystkich zależnościach (pakiety OS, biblioteki)

Warstwa 3: OSV API
  -> Sprawdza podatności na poziomie aplikacji dla GoTrue, PostgREST etc.
  -> Uzupełnia Trivy o CVE specyficzne dla pakietów
```

**Jak to działa:**

```
Codziennie 07:00 (audit-runner Cron)
   │
   ├── Pobranie aktualnych wersji z serwera prod
   ├── GitHub API: Sprawdzenie najnowszych wydań dla każdego komponentu
   ├── Skanowanie Release Notes pod kątem "security", "CVE", "vulnerability"
   │
   ├── Znaleziono wydanie bezpieczeństwa?
   │     -> NATYCHMIAST e-mail do ops@
   │     -> "Wymagane działanie w ciągu 24h"
   │
   └── Znaleziono normalne wydanie?
         -> Cotygodniowe podsumowanie (poniedziałek)
```

**Mechanizm cache:** Skrypt zapamiętuje zgłoszone wydania, dzięki czemu ten sam e-mail nie przychodzi codziennie. Dopiero przy NOWYM wydaniu następuje ponowny alarm.

**Sprawdzalny warunek:**

```bash
# Security Release Monitor aktiv auf audit-runner?
ssh deploy@10.0.1.11 "crontab -l | grep security-release"
# Erwartung: täglicher Cron Job

# Letzter Check-Log
ssh deploy@10.0.1.11 "tail -5 /var/log/security-releases.log"
# Erwartung: Eintrag von heute

# Cache vorhanden (Script hat schon gelaufen)?
ssh deploy@10.0.1.11 "ls /opt/audit/cache/*-last-seen.txt 2>/dev/null | wc -l"
```

**Scenariusz awarii:** W styczniu 2024 opublikowano CVE-2023-5869 dla PostgreSQL (Remote Code Execution). Kto nie miał monitora wydań i sprawdzał aktualizacje tylko co miesiąc, był podatny przez 3-4 tygodnie. Z codziennym monitorem e-mail przyszedłby dzień po wydaniu.

### E6 - Audit-Runner jako strażnik aktualizacji

Audit-Runner monitoruje, czy aktualizacje są przeprowadzane, i informuje zespół, gdy coś jest zaległe.

Na audit-runner działa cotygodniowy skrypt, który sprawdza:

```bash
#!/bin/bash
# scripts/check-maintenance.sh (läuft auf audit-runner)

PROD_HOST="10.0.1.10"
REPORT=""

echo "=== Maintenance Check $(date) ==="

# 1. OS Updates überfällig?
LAST_APT=$(ssh deploy@${PROD_HOST} "stat -c %Y /var/cache/apt/pkgcache.bin")
APT_AGE=$(( ($(date +%s) - $LAST_APT) / 86400 ))
if [ "$APT_AGE" -gt 7 ]; then
  REPORT+="WARNUNG: apt update ist ${APT_AGE} Tage her (max. 7)\n"
fi

# 2. Unattended Upgrades aktiv?
UA_STATUS=$(ssh deploy@${PROD_HOST} "systemctl is-active unattended-upgrades 2>/dev/null")
if [ "$UA_STATUS" != "active" ]; then
  REPORT+="KRITISCH: Unattended Upgrades nicht aktiv\n"
fi

# 3. Ausstehende Security Updates?
SEC_UPDATES=$(ssh deploy@${PROD_HOST} "apt list --upgradable 2>/dev/null | grep -ci security")
if [ "$SEC_UPDATES" -gt 0 ]; then
  REPORT+="WARNUNG: ${SEC_UPDATES} ausstehende Security Updates\n"
fi

# 4. Reboot erforderlich?
REBOOT=$(ssh deploy@${PROD_HOST} "test -f /var/run/reboot-required && echo ja || echo nein")
if [ "$REBOOT" = "ja" ]; then
  REPORT+="WARNUNG: Server-Reboot erforderlich (Kernel Update)\n"
fi

# 5. Supabase Image Alter
ssh deploy@${PROD_HOST} "cd /opt/supabase && docker compose images --format '{{.Repository}}:{{.Tag}}'" | \
while read image; do
  CREATED=$(ssh deploy@${PROD_HOST} "docker inspect --format='{{.Created}}' '$image' 2>/dev/null" | cut -dT -f1)
  if [ -n "$CREATED" ]; then
    AGE_DAYS=$(( ($(date +%s) - $(date -d "$CREATED" +%s 2>/dev/null || echo 0)) / 86400 ))
    if [ "$AGE_DAYS" -gt 90 ]; then
      REPORT+="WARNUNG: $image ist ${AGE_DAYS} Tage alt (max. 90)\n"
    fi
  fi
done

# 6. Letztes Supabase Update?
LAST_UPDATE=$(ssh deploy@${PROD_HOST} "cd /opt/supabase && git log --format='%ai' --grep='Update\|update' -1 2>/dev/null" | cut -d' ' -f1)
if [ -n "$LAST_UPDATE" ]; then
  UPDATE_AGE=$(( ($(date +%s) - $(date -d "$LAST_UPDATE" +%s)) / 86400 ))
  if [ "$UPDATE_AGE" -gt 45 ]; then
    REPORT+="WARNUNG: Letztes Supabase Update vor ${UPDATE_AGE} Tagen (max. 45)\n"
  fi
else
  REPORT+="WARNUNG: Kein Update-Commit in Git gefunden\n"
fi

# 7. Docker Engine Version
DOCKER_VERSION=$(ssh deploy@${PROD_HOST} "docker version --format '{{.Server.Version}}' 2>/dev/null")
echo "Docker Engine: $DOCKER_VERSION"

# 8. Caddy Version
CADDY_VERSION=$(ssh deploy@${PROD_HOST} "caddy version 2>/dev/null")
echo "Caddy: $CADDY_VERSION"

# 9. TLS Zertifikat Restlaufzeit
CERT_DAYS=$(ssh deploy@${PROD_HOST} "echo | openssl s_client -connect localhost:443 2>/dev/null | openssl x509 -noout -enddate 2>/dev/null | cut -d= -f2")
if [ -n "$CERT_DAYS" ]; then
  DAYS_LEFT=$(( ($(date -d "$CERT_DAYS" +%s) - $(date +%s)) / 86400 ))
  [ "$DAYS_LEFT" -lt 14 ] && REPORT+="KRITISCH: TLS Zertifikat läuft in ${DAYS_LEFT} Tagen ab\n"
fi

# Ergebnis
if [ -n "$REPORT" ]; then
  echo -e "\n$REPORT"
  echo -e "$REPORT" | mail -s "Maintenance Check: Handlung nötig" ops@example.com
else
  echo "Alle Maintenance Checks bestanden"
fi
```

**Cron na audit-runner:**

```bash
# Wöchentlich Montag 08:00 (nach dem Sonntag-Audit)
0 8 * * 1 /opt/audit/scripts/check-maintenance.sh >> /var/log/maintenance-check.log 2>&1
```

**Kiedy Claude informuje:**

Claude Code na audit-runner wysyła powiadomienia w trzech przypadkach:

```
NATYCHMIAST (e-mail do ops@):
  - Unattended Upgrades nieaktywne
  - Certyfikat TLS < 14 dni
  - Aktualizacja bezpieczeństwa zaległa > 3 dni

COTYGODNIOWO (raport konserwacji):
  - Wymagany restart
  - apt update zaległy
  - Obrazy Supabase > 60 dni

COMIESIĘCZNIE (przypomnienie o aktualizacji):
  - Supabase Release Notes niesprawdzone (brak commitu aktualizacji > 45 dni)
  - Przegląd kwartalny wymagany
```

## Podsumowanie

Samodzielne hostowanie Supabase jest stosunkowo proste. **Bezpieczna eksploatacja** Supabase wymaga jasnych reguł architektonicznych i zautomatyzowanej kontroli.

Ten runbook rozdziela decyzje infrastrukturalne (Część A), architekturę i zabezpieczanie usług (Część B), konfigurację stacku (Część C), bieżący monitoring (Część D) i procesów aktualizacji (Część E). Połączenie deterministycznych kontroli i kontekstowej analizy Claude Code obejmuje zarówno znane wzorce, jak i nieoczekiwane ryzyka.

Kto te zasady stosuje od początku, buduje [architekturę Cert-Ready by Design](/pl/magazyn/cert-ready-by-design/) i oszczędza sobie późniejszych rund audytowych.

> **Przypomnienie:** Konfiguracje specyficzne dla Hetzner (vSwitch, Cloud Firewall, nazwy interfejsów) można bezpośrednio przenieść na innych dostawców: OVH (PL), Oktawave (PL), IONOS (EU). Zasady architektoniczne obowiązują niezależnie od dostawcy.

<div class="not-prose my-12 border border-gosign-border bg-gosign-light rounded-card p-6 lg:p-8">
<div class="flex items-start gap-4">
<div class="flex-shrink-0 w-12 h-12 bg-gosign-dark rounded-card flex items-center justify-center">
<svg width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="white" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 15v4a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2v-4"/><polyline points="7 10 12 15 17 10"/><line x1="12" y1="15" x2="12" y2="3"/></svg>
</div>
<div>
<h2 class="text-h3 font-bold text-gosign-dark mb-2" id="pobierz-liste-kontrolna-audytu">Pobierz listę kontrolną audytu</h2>
<p class="text-body text-gosign-text mb-2">Przygotowany prompt dla Claude Code. Prześlij plik na swój serwer i uruchom Claude Code w katalogu projektu stacku Supabase. Claude Code automatycznie sprawdzi wszystkie punkty bezpieczeństwa z tego runbooka i zgłosi ZALICZONY, OSTRZEŻENIE lub KRYTYCZNY.</p>
<p class="text-sm text-gosign-text mb-4 font-mono">claude -p "$(cat claude-check-artikel-1-supabase-pl.md)" --allowedTools Read,Grep,Glob,Bash</p>
<a href="/downloads/claude-check-artikel-1-supabase-pl.md" download class="inline-flex items-center px-6 py-3 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-small uppercase tracking-wider">Pobierz listę kontrolną</a>
</div>
</div>
</div>

## Spis treści serii

Ten artykuł jest częścią naszej serii DevOps dla self-hosted stacków aplikacyjnych.

1. [Supabase Self-Hosting Runbook](/pl/magazyn/supabase-self-hosting/) ← ten artykuł
2. [Next.js nad Supabase - bezpieczna eksploatacja](/pl/magazyn/nextjs-supabase-bezpieczna-konfiguracja/)
3. [Supabase Edge Functions - bezpieczne wdrożenie](/pl/magazyn/supabase-edge-functions-bezpieczenstwo/)
4. [Bezpieczna obsługa Trigger.dev Background Jobs](/pl/magazyn/trigger-dev-background-jobs/)
5. [Claude Code jako kontrola bezpieczeństwa w DevOps](/pl/magazyn/claude-code-security-devops/)
6. [Security Baseline dla całego stacku](/pl/magazyn/security-baseline-stack/)

W następnym artykule pokażemy, jak **bezpiecznie eksploatować Next.js nad Supabase**, unikając typowych błędów przy Server Actions, obsłudze uwierzytelniania i dostępie do API.

--- Automatyzacja rozliczeń podróży: Koszt rachunku ---
> 58 USD za rachunek, 19% błędów, 52 USD za korektę. Dane GBTA pokazują: ręczne rozliczenia kosztują korporacje miliony - i można tego uniknąć.

## 58 USD za rachunek - liczba, której nikt nie śledzi

Większość działów finansowych zna swoje koszty podróży. Wiedzą, ile firma rocznie wydaje na loty, hotele i diety. Czego rzadko wiedzą: ile kosztuje przetworzenie pojedynczego rachunku podróżnego?

Odpowiedź daje GBTA Foundation we współpracy z HRS: 58 USD za transakcję przy ręcznym przetwarzaniu. Wskaźnik błędów: 19 procent. Koszt korekty per błąd: 52 USD (Źródło: GBTA Foundation / HRS, "Expense Reporting: Global Practices and Pain Points", 2015).

Te trzy liczby zmieniają perspektywę. Koszty podróży to nie tylko pozycja wydatkowa - to problem kosztów procesowych. A w korporacjach z dziesiątkami lub setkami tysięcy transakcji rocznie ten problem sumuje się do milionowych kwot.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">W skrócie - ROI automatyzacji rozliczeń podróży</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Ręczne przetwarzanie kosztuje 58 USD za rachunek przy 19% wskaźniku błędów i 52 USD za korektę (GBTA Foundation).</li>
<li>Przy 100 000 transakcji rocznie samo przetwarzanie generuje prawie 7 milionów USD - przed właściwymi kosztami podróży.</li>
<li>OCR i workflow zatwierdzania rozwiązują rejestrację, nie 40 do 120 mikro-decyzji na transakcję (diety, układy zbiorowe, opodatkowanie).</li>
<li>Podejście Decision Layer osiąga 85 do 95% Zero-Touch przez wersjonowane, audytowalne reguły dla każdej mikro-decyzji.</li>
<li>Zwrot inwestycji zaczyna się od 10 000 transakcji rocznie; największe oszczędności wynikają z eliminacji pętli korekt.</li>
</ul>
</div>

## Anatomia 58 dolarów

### Koszty widoczne: rejestracja i zatwierdzenie

Pracownik fotografuje rachunek, wprowadza dane do SAP Concur lub porównywalnego narzędzia, przypisuje centrum kosztów i składa. Przełożony sprawdza, zatwierdza lub odrzuca. Pracownik Shared Service Center sprawdza ponownie, weryfikuje zgodność z polityką i księguje.

Trzy osoby, trzy kroki robocze, jeden rachunek. To widoczna część 58 dolarów.

### Koszty ukryte: korekty i wyjaśnienia

19 procent wskaźnika błędów oznacza: prawie co piąta transakcja wymaga korekty. Zastosowano niewłaściwą stawkę diety, zapomniano o redukcji za posiłki, użyto niewłaściwej stawki z układu zbiorowego, pomylono centrum kosztów. Każda korekta kosztuje 52 USD - transakcja przechodzi cały proces po raz drugi.

Dochodzą wyjaśnienia: pracownik SSC zwraca się do pracownika, bo brakuje danych. Pracownik szuka rachunku sprzed trzech tygodni. Przełożony jest proszony o ponowne zatwierdzenie. Te pętle kosztują czas, który nie pojawia się w żadnym rachunku kosztów.

### Koszty systemowe: ryzyko audytowe i compliance

Gdy 19 procent transakcji jest błędnych, a kontrolowane są tylko próbki, w systemie drzemią systematyczne błędy. Ryzyko materializuje się przy kontroli skarbowej: kontroler nie pyta o pojedyncze rachunki, lecz o systematykę. Czy istnieje udokumentowane stosowanie reguł? Czy można prześledzić, dlaczego ta dieta została obliczona według tej stawki?

W większości korporacji odpowiedź brzmi: nie. Logika decyzyjna tkwi w głowie pracownika SSC, nie w systemie. To nie jest dokumentacja proceduralna zgodna z wymogami audytowymi - to ryzyko audytowe.

## Przeliczenie: ile naprawdę kosztują rozliczenia podróży w korporacji

### Scenariusz A: 10 000 transakcji rocznie (duża firma średniej wielkości)

<div class="overflow-x-auto">

| Pozycja | Kalkulacja | Koszt roczny |
|---------|-----------|-------------|
| Przetwarzanie | 10 000 x 58 USD | 580 000 USD |
| Korekty | 10 000 x 19 % x 52 USD | 98 800 USD |
| **Razem** | | **678 800 USD** |

</div>

Przy 10 000 transakcji przetwarzanie kosztów podróży angażuje rachunkowo 3 do 4 pełnych etatów w Shared Service Center. Same koszty korekt odpowiadają połowie etatu.

### Scenariusz B: 100 000 transakcji rocznie (korporacja)

<div class="overflow-x-auto">

| Pozycja | Kalkulacja | Koszt roczny |
|---------|-----------|-------------|
| Przetwarzanie | 100 000 x 58 USD | 5 800 000 USD |
| Korekty | 100 000 x 19 % x 52 USD | 988 000 USD |
| **Razem** | | **6 788 000 USD** |

</div>

Blisko 7 milionów USD rocznie - wyłącznie za przetwarzanie, nie za same koszty podróży. Do tego: przy 100 000 transakcjach i 19 procentach wskaźnika błędów 19 000 transakcji jest błędnych. To nie jest ryzyko resztkowe, to problem systemowy.

### Scenariusz C: 500 000+ transakcji rocznie (logistyka, lotnictwo)

<div class="overflow-x-auto">

| Pozycja | Kalkulacja | Koszt roczny |
|---------|-----------|-------------|
| Przetwarzanie | 500 000 x 58 USD | 29 000 000 USD |
| Korekty | 500 000 x 19 % x 52 USD | 4 940 000 USD |
| **Razem** | | **33 940 000 USD** |

</div>

34 miliony USD kosztów przetwarzania rocznie. W liniach lotniczych i koncernach logistycznych, gdzie każdy pracownik z konieczności podróżuje (załoga lata, kierowca jedzie), to nie jest opcjonalne - te transakcje powstają jako produkt uboczny podstawowej działalności.

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Darmowy eBook: AI w Finance</p>
<p class="text-body text-gosign-text mb-4">Compliance, biegły rewident i Decision Layer - poradnik governance dla liderów finansów.</p>
<a href="/pl/ebook/ai-finance-poradnik-governance/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Pobierz za darmo</a>
</div>

## Dlaczego OCR i workflow zatwierdzania nie wystarczają

Oczywista odpowiedź na problem kosztowy: digitalizacja. OCR do rejestracji rachunków, workflow do zatwierdzania, aplikacje do składania. To redukuje nakład ręczny przy rejestracji - ale nie przy decyzji.

OCR rejestruje rachunek. Workflow przekierowuje go do właściwej osoby. Ale kto decyduje:

- Jaka stawka diety obowiązuje, gdy pracownik był w trzech krajach?
- Czy układ zbiorowy nadpisuje stawkę ustawową - a jeśli tak, to który układ?
- Jak naliczyć redukcję za posiłki, gdy hotel zapewnia śniadanie, ale pracownik z niego nie skorzystał?
- Czy koszty reprezentacji podlegają odliczeniu w 100 procentach (Polska) czy w innej proporcji (Austria)?

To nie są problemy rejestracji. To problemy stosowania reguł. I żaden system OCR ani workflow zatwierdzania nie rozwiązuje problemów stosowania reguł.

## Różnica między rejestracją a governance

Brakuje warstwy między rejestracją rachunku a księgowaniem: warstwy governance, która dla każdej transakcji dokumentuje, jaka reguła została zastosowana i dlaczego.

[Decision Layer](/pl/magazyn/decision-layer-wyjasnienie/) rozkłada każdą transakcję kosztów podróży na mikro-decyzje i definiuje dla każdego kroku: zestaw reguł, hierarchię (prawo przed układem zbiorowym przed polityką firmy) i dokumentację. Decyzja nie jest podejmowana przez człowieka działającego na podstawie doświadczenia, lecz przez wersjonowany zestaw reguł, który jest identyfikowalny, reprodukowalny i [audytowalny](/pl/magazyn/cert-ready-by-design/).

To zmienia również model pracy: zamiast składania, zatwierdzania, księgowania (trzy ręczne kroki) transakcja jest przetwarzana automatycznie. Pracownik widzi wynik i ma prawo sprzeciwu - podejście weto. Zamiast ręcznego sprawdzania każdej transakcji, obsługiwane są tylko wyjątki. To jest różnica między 0 procent a 85 do 95 procent Zero-Touch.

## Cztery branże, cztery profile ROI

[Travel Decision Layer](/pl/uslugi/travel-decision-layer/) jest stosowalny międzybranżowo. Wskaźnik automatyzacji różni się w zależności od branży, ponieważ dane wejściowe mają różną strukturę:

<div class="overflow-x-auto">

| Branża | Transakcje rocznie | Zero-Touch | Koszt przed | Koszt po | Oszczędność |
|--------|-------------------|------------|------------|---------|------------|
| [Lotnictwo](/pl/uslugi/travel-decision-layer/lotnictwo/) | 100k - 1M+ | 95 % | 58+ USD | < 10 USD | > 80 % |
| [Logistyka](/pl/uslugi/travel-decision-layer/logistyka/) | 500k - 2M+ | 95 % | 58+ USD | < 5 USD | > 90 % |
| [Sprzedaż](/pl/uslugi/travel-decision-layer/sprzedaz/) | 120k+ | 90 % | 58+ USD | < 8 USD | > 85 % |
| [Doradztwo](/pl/uslugi/travel-decision-layer/doradztwo/) | 50k - 250k+ | 85 % | 58+ USD | < 10 USD | > 80 % |

</div>

Najwyższe Zero-Touch-Quote osiągają branże z maszynowo czytelnymi danymi wejściowymi: GPS-Tracks w logistyce, rotacje załogowe w lotnictwie. Doradztwo plasuje się na 85 procentach, ponieważ tygodnie z wieloma mandatami mogą wymagać ręcznego przyporządkowania.

Decydujący dla [ROI](/pl/magazyn/roi-inwestycje-ai/) jest nie tylko redukcja kosztów na transakcję, ale eliminacja pętli korekt: z 19 procent wskaźnika błędów poniżej 2 procent oznacza, że 52-dolarowe koszty korekt praktycznie zanikają.

## Podejście weto: automatyzacja bez utraty kontroli

Częsty zarzut wobec automatyzacji: "Tracimy kontrolę." Podejście weto odwraca logikę.

Dzisiaj: pracownik składa. Przełożony zatwierdza. Pracownik SSC księguje. Trzy ręczne kroki, każdy podatny na błędy.

Z Decision Layer: system oblicza transakcję automatycznie na podstawie zapisanych reguł. Pracownik widzi wynik i może zgłosić sprzeciw - w zdefiniowanym terminie. Bez sprzeciwu transakcja jest automatycznie księgowana.

To nie jest mniej kontroli. To więcej kontroli - udokumentowanej, identyfikowalnej, reprodukowalnej. Zamiast subiektywnego zatwierdzenia przez przełożonego, który nie zna szczegółów układu zbiorowego, decyduje zestaw reguł, który może być zweryfikowany przez [radę zakładową](/pl/magazyn/rada-zakladowa-ai-mitbestimmung/) i zbadany przez biegłego rewidenta.

## Kiedy się opłaca - a kiedy nie

Nie każda korporacja potrzebuje w pełni zautomatyzowanego przetwarzania kosztów podróży. Inwestycja się opłaca, gdy spełnione są co najmniej dwa z poniższych kryteriów:

- **Wolumen**: Ponad 10 000 transakcji kosztów podróży rocznie
- **Złożoność reguł**: Układy zbiorowe, multi-jurysdykcja lub branżowe reguły specjalne
- **Wymogi audytowe**: Dokumentacja proceduralna zgodna z wymogami kontroli skarbowej, gotowość do audytu
- **Shared Service Center**: Scentralizowane przetwarzanie z udokumentowaną jakością procesów

Gdy do przetworzenia są wyłącznie podróże krajowe bez układów zbiorowych, wystarczy SAP Concur lub porównywalne narzędzie. Warstwa governance staje się istotna tam, gdzie reguły są na tyle złożone, że pracownik popełnia błędy - czyli tam, gdzie dane GBTA ujawniają swoją pełną siłę.

Gosign implementuje [Travel Decision Layer](/pl/uslugi/travel-decision-layer/) branżowo - od ewaluacji przez 3-miesięczny pilot po produkcyjne wdrożenie. Na Twojej [infrastrukturze](/pl/uslugi/infrastruktura/), bez zewnętrznej zależności od SaaS, z pełnym dostępem do kodu źródłowego.

--- Koszty podróży w korporacji: Limity SAP Concur ---
> SAP Concur rejestruje rachunki - ale kto decyduje o układach zbiorowych, dietach i IROP? Dlaczego korporacje potrzebują więcej niż narzędzia do rozliczeń.

## SAP Concur jest dobry - w tym, do czego został zbudowany

SAP Concur to najczęściej wdrażane oprogramowanie do rozliczania kosztów podróży na świecie. Rejestracja rachunków przez aplikację, workflow zatwierdzania, integracja z SAP - dla firm ze standardowymi podróżami krajowymi działa niezawodnie.

Problem zaczyna się tam, gdzie kończą się standardowe procesy. W korporacjach z układami zbiorowymi pracy, podróżami wielojurysdykcyjnymi i branżową złożonością każde czysto rejestracyjne narzędzie trafia na swoje granice - nie tylko Concur, ale również Circula, Rydoo czy HR Works.

Powód: te narzędzia rozwiązują problem rejestracji. Nie problem decyzyjny.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">W skrócie - Limity SAP Concur w korporacyjnych kosztach podróży</p>
<ul class="text-body text-gosign-text space-y-2">
<li>SAP Concur rozwiązuje rejestrację rachunków, nie 40 do 120 mikro-decyzji za każdą transakcją (układy zbiorowe, diety wielojurysdykcyjne, przeliczenia IROP).</li>
<li>Ręczne przetwarzanie kosztuje 58 USD za transakcję przy 19% błędów i 52 USD za korektę (GBTA Foundation) - przy 100 000 transakcji załogowych to 6,8 mln USD rocznie.</li>
<li>Układy zbiorowe, wielokrajowe przekroczenia granic i operacje nieregularne leżą poza modelem danych każdego standardowego narzędzia do kosztów podróży.</li>
<li>Decision Layer działa jako warstwa governance nad SAP Concur - wersjonowane reguły, deterministyczna kalkulacja, kompletny Audit Trail.</li>
<li>Wynik: 95% Zero-Touch, wskaźnik błędów poniżej 1%, koszt na transakcję poniżej 10 USD - bez wymiany istniejących systemów.</li>
</ul>
</div>

## Problem decyzyjny: 40 do 120 mikro-decyzji na transakcję

Rozliczenie kosztów podróży to nie rejestracja rachunków. Za każdą transakcją stoi 40 do 120 mikro-decyzji:

- Jaka dieta obowiązuje (stawki krajowe, stan na dzień podróży)?
- Czy układ zbiorowy pracy nadpisuje stawkę ustawową?
- Jak naliczana jest redukcja z tytułu zapewnionych posiłków (śniadanie, obiad, kolacja)?
- Jakie centrum kosztów pokrywa transakcję?
- Jaki jest sposób opodatkowania (zwolnione, ryczałtowe, opodatkowane)?
- Co się dzieje przy zmianie planu w trakcie podróży?

SAP Concur rejestruje rachunek. Ale kto podejmuje te decyzje? W większości korporacji: pracownik Shared Service Center, ręcznie, per transakcja, bez udokumentowanej logiki decyzyjnej.

To jest kosztowne. GBTA Foundation szacuje średni koszt ręcznej obsługi jednej transakcji kosztów podróży na 58 USD - przy wskaźniku błędów 19 procent i koszcie korekty 52 USD za błąd (Źródło: GBTA Foundation / HRS, "Expense Reporting: Global Practices and Pain Points", 2015).

## Gdzie standardowe narzędzia do kosztów podróży trafiają na granice

### Układ zbiorowy nadpisuje prawo

Stawki diet krajowych to minimalny standard ustawowy. W Polsce Rozporządzenie Ministra Pracy i Polityki Społecznej definiuje podstawowe stawki: 45 PLN za pełną dobę podróży krajowej (stan 2024). Wiele układów zbiorowych pracy definiuje wyższe stawki - czasem znacząco.

Koncern energetyczny z 35 000 pracowników po fuzji ma typowo 2 do 5 równoległych układów zbiorowych: produkcja, przesył, dystrybucja, biuro, kadra zarządzająca. Każdy układ definiuje własne stawki diet, własne zasady redukcji za posiłki, własne wyjątki.

SAP Concur nie zna układów zbiorowych. Oprogramowanie kalkuluje na podstawie stawek ustawowych - albo jednej stawki ogólnofirmowej. Kalkulacja diet zgodna z układem zbiorowym odbywa się poza narzędziem: ręcznie, w arkuszach kalkulacyjnych, albo przez pracowników Shared Service Center, którzy wynik ręcznie wprowadzają z powrotem do systemu.

To nie tylko nieefektywne. To podatne na błędy. Kiedy pracownik SSC zastosuje niewłaściwy układ zbiorowy dla grupy pracowniczej 3, powstają systematyczne błędy, które przy tysiącach transakcji pozostają niezauważone - aż do kontroli skarbowej.

### Multi-jurysdykcja w jednej transakcji

Członek załogi lotniczej na locie europejskim jest w ciągu jednego dnia w 3 do 5 krajach. Dieta zależy od kraju, w którym kończy się dzień podróży, lub od zasady północy przy podróżach wielodniowych. Standardowe narzędzia do kosztów podróży kalkulują jedną podróż z jednym krajem. Multi-jurysdykcja wewnątrz jednej transakcji - z co do minuty dokładnym przekroczeniem granicy - leży poza ich modelem danych.

To nie dotyczy wyłącznie linii lotniczych:

- **Logistyka**: Kierowcy przekraczają codziennie kilka granic. Dieta zmienia się na każdej granicy, kalkulacja musi być co do minuty precyzyjna - szczególnie przy przekroczeniach północy. Do tego dochodzą wymogi dokumentacyjne [Pakietu Mobilności UE](/pl/uslugi/travel-decision-layer/logistyka/) (Dyrektywa 2020/1057).
- **Sprzedaż**: Przedstawiciele terenowi odwiedzają klientów w wielu krajach w ciągu tygodnia. Poniedziałek Wiedeń, środa Zurych, piątek Monachium - trzy jurysdykcje, trzy stawki diet, jedna transakcja.
- **Doradztwo**: Konsultanci pracują w zmieniających się mandatach. Tygodniowy rytm z trzema klientami w dwóch krajach generuje wymagania podziału, których żadne standardowe narzędzie nie odwzorowuje.

### Nieregularne operacje i nieplanowane zmiany

10 do 20 procent wszystkich lotów jest dotkniętych nieregularnościami - opóźnienia, przekierowania, repozycje załogi (Źródło: EUROCONTROL / US DOT BTS, 2024). Każda nieregularność zmienia kalkulację kosztów podróży: inna dieta z powodu innego kraju docelowego, inny wymóg noclegu, inne centrum kosztów.

Żadne standardowe narzędzie do kosztów podróży nie przetwarza operacji nieregularnych (IROP) automatycznie. Korekta następuje ręcznie - jeśli w ogóle zostanie rozpoznana. Przy 100 000 transakcji załogowych rocznie i wskaźniku IROP na poziomie 15 procent to 15 000 transakcji wymagających ręcznej korekty. Każda z ryzykiem, że sama korekta jest błędna.

### Luka governance

SAP Concur dokumentuje, co zostało złożone. Nie dokumentuje, dlaczego tak zdecydowano. To jest różnica między narzędziem rejestracyjnym a warstwą governance.

Gdy kontroler skarbowy pyta: "Na podstawie jakiej reguły obliczono tę dietę?" - Concur nie ma odpowiedzi. Kwota jest w systemie, logika decyzyjna nie. Gdy [rada zakładowa](/pl/governance/co-determination/) pyta: "Jak podejmowane są decyzje o kosztach podróży?" - uczciwa odpowiedź w większości korporacji brzmi: pracownik SSC decyduje na podstawie doświadczenia.

To nie jest Audit Trail. To zależność od jednej osoby.

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Darmowy eBook: AI w Finance</p>
<p class="text-body text-gosign-text mb-4">Compliance, biegły rewident i Decision Layer - poradnik governance dla liderów finansów.</p>
<a href="/pl/ebook/ai-finance-poradnik-governance/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Pobierz za darmo</a>
</div>

## Symulacja: 100 000 transakcji załogowych rocznie

### Punkt wyjścia

Dla koncernu lotniczego ze 100 000 transakcjami załogowymi rocznie na podstawie danych GBTA wynika:

<div class="overflow-x-auto">

| Pozycja | Kalkulacja | Koszt roczny |
|---------|-----------|-------------|
| Przetwarzanie | 100 000 x 58 USD | 5 800 000 USD |
| Korekty | 100 000 x 19 % x 52 USD | 988 000 USD |
| **Razem** | | **6 788 000 USD** |

</div>

Nie uwzględniono: kosztów czasu zatwierdzających (kadra kierownicza sprawdzająca rachunki zamiast zarządzać), zatorów na koniec miesiąca w księgowości, ryzyka audytowego przy kontroli skarbowej i frustracji pracowników wynikającej z opóźnionych zwrotów.

### Podejście Decision Layer

[Travel Decision Layer](/pl/uslugi/travel-decision-layer/) rozkłada każdą transakcję kosztów podróży na mikro-decyzje i stosuje do każdej decyzji udokumentowane reguły: prawo, układ zbiorowy, polityka firmy - w tej hierarchii, wersjonowane, identyfikowalne.

Stosowanie reguł jest deterministyczne. Żaden stochastyczny model językowy nie decyduje o kwotach ani opodatkowaniu. AI jest wykorzystywana do klasyfikacji - rozpoznanie typu rachunku, kategoryzacja IROP, klasyfikacja celu spotkania biznesowego - ale kalkulacja podlega ścisłym regułom.

Dla [symulacji lotniczej](/pl/uslugi/travel-decision-layer/lotnictwo/) wynika:

<div class="overflow-x-auto">

| Metryka | Ręcznie | Z Decision Layer |
|---------|---------|-----------------|
| Koszt na transakcję | 58+ USD | < 10 USD |
| Wskaźnik błędów | 19 % | < 1 % |
| Czas przetwarzania | 5 - 12 dni roboczych | Minuty |
| Zero-Touch-Quote | 0 % | 95 % |
| Gotowość audytowa | Ręczna rekonstrukcja | Automatycznie generowana |
| Zmiana układu zbiorowego | Tygodnie | < 24 godziny |

</div>

Przeliczenie przy 100 000 transakcji: z 6,8 mln USD do poniżej 1 mln USD rocznie. Oszczędność nie wynika z tańszych pracowników SSC, lecz z eliminacji ręcznych decyzji.

### Przebieg decyzyjny w szczegółach

Pojedyncza transakcja załogowa przechodzi w Decision Layer następujące kroki:

1. Wczytanie danych rotacyjnych z systemu planowania załóg
2. Ustalenie sekwencji krajów z danych rotacyjnych
3. Określenie diety na kraj i dzień (stawki krajowe, obowiązujące w dniu podróży)
4. Sprawdzenie nadpisania układem zbiorowym (grupa pracownicza, okres obowiązywania)
5. Obliczenie redukcji za posiłki (śniadanie, obiad, kolacja - na dzień)
6. Klasyfikacja typu IROP (wspomagana AI) i ponowna kalkulacja diety
7. Sprawdzenie kosztów hotelu wobec polityki (limit na miasto)
8. Przypisanie centrum kosztów (rotacja, flota, grupa załogowa)
9. Ustalenie sposobu opodatkowania (zwolnione, ryczałtowe, opodatkowane)
10. Wygenerowanie rekordu audytowego (podpisany SHA-256, append-only)

Każdy z tych kroków to udokumentowana decyzja z identyfikowalną podstawą prawną. To jest różnica w porównaniu z workflow zatwierdzania, w którym człowiek klika "Zatwierdzone" bez zapisanej logiki decyzyjnej w systemie.

## Cztery branże, cztery poziomy złożoności

Travel Decision Layer nie jest ograniczony do lotnictwa. Podstawowa architektura - deterministyczny zestaw reguł nad mikro-decyzjami - działa międzybranżowo z branżową konfiguracją:

<div class="overflow-x-auto">

| Branża | Transakcje rocznie | Zero-Touch | Kluczowa złożoność |
|--------|-------------------|------------|-------------------|
| [Lotnictwo](/pl/uslugi/travel-decision-layer/lotnictwo/) | 100k - 1M+ | 95 % | IROP + wielokrotne układy zbiorowe |
| [Logistyka](/pl/uslugi/travel-decision-layer/logistyka/) | 500k - 2M+ | 95 % | Precyzja GPS + Pakiet Mobilności UE |
| [Sprzedaż](/pl/uslugi/travel-decision-layer/sprzedaz/) | 120k+ | 90 % | Integracja CRM + koszty reprezentacji |
| [Doradztwo](/pl/uslugi/travel-decision-layer/doradztwo/) | 50k - 250k+ | 85 % | Split 3-stronny (podatek / klient / wewnętrzne) |

</div>

Wszystkie cztery symulacje opierają się na tych samych wartościach wyjściowych GBTA (58 USD na transakcję, 19 % wskaźnik błędów) i pokazują branżowe potencjały optymalizacji. Różne Zero-Touch-Quote odzwierciedlają złożoność branżową: logistyka i lotnictwo osiągają 95 procent, ponieważ dane wejściowe (GPS-Tracks, rotacje załogowe) są maszynowo czytelne. Doradztwo plasuje się na 85 procentach, ponieważ tygodnie z wieloma mandatami mogą wymagać ręcznego przyporządkowania.

## Czego potrzebuje rozwiązanie uzupełniające SAP Concur

SAP Concur nie musi być zastępowany. Brakuje warstwy powyżej - warstwy governance, która decyduje zanim rachunek trafi do systemu:

1. **Silnik reguł natywny dla układów zbiorowych** - Układy zbiorowe nie jako obejście, lecz jako koncepcja pierwszej klasy. Konfigurowalny per grupa pracownicza, z okresem obowiązywania i hierarchią nadpisywania.
2. **Wersjonowane tabele decyzyjne** - Każda reguła datowana, każda zmiana identyfikowalna. Stawki diet, siatki z układów zbiorowych i polityki firmowe jako datowane zestawy zmian.
3. **Kompletny Audit Trail** - Każda mikro-decyzja podpisana (SHA-256), zapisana w trybie append-only. Bez nadpisywania, bez usuwania, w pełni reprodukowalna.
4. **Przejrzystość [zgodna z wymogami rady zakładowej](/pl/governance/co-determination/)** - Zestaw reguł jest dostępny do wglądu, logika decyzyjna jest identyfikowalna. Żadna czarna skrzynka AI nie decyduje o kwotach.
5. **Integracja z ERP** - Żaden zamiennik systemu, lecz zasilanie istniejących systemów ERP i payroll. Decision Layer znajduje się między źródłem danych a systemem księgowym.
6. **Multi-jurysdykcja per transakcja** - Nie per podróż, lecz per dzień, z co do minuty dokładnym przekroczeniem granicy.

Gosign implementuje tę warstwę governance jako [Travel Decision Layer](/pl/uslugi/travel-decision-layer/) - branżowo skonfigurowany, na Twojej [infrastrukturze](/pl/uslugi/infrastruktura/), bez zewnętrznej zależności od SaaS.

--- Trigger.dev Background Jobs - bezpieczna eksploatacja ---
> Runbook DevOps dla Trigger.dev v3: setup self-hosted, definicja tasków, idempotencja, concurrency, sekrety i integracja z Claude Code.

Gdy aplikacja wykracza poza proste operacje CRUD, pojawiają się zadania, które **nie powinny działać synchronicznie w cyklu request-response**: wysyłka e-mail, przetwarzanie webhooków, zadania importu/eksportu, taski AI, generowanie PDF, migracja danych i zadania periodyczne.

Te zadania **nie należą do Next.js Server Actions** (blokują serwer webowy), **nie należą do Supabase Edge Functions** (limit timeout, brak obsługi zadań długotrwałych) ani do cron jobów na serwerze (brak logiki retry, brak monitoringu).

Należą do **dedykowanej warstwy zadań**. W naszym stacku tę rolę pełni **Trigger.dev**.

Ten runbook opisuje, jak bezpiecznie eksploatować Trigger.dev w stacku. Każdy krok zawiera konkretną implementację z aktualnym API Trigger.dev v3, sprawdzalny warunek i scenariusz awarii.

> **Uwaga dotycząca architektury:** Trigger.dev składa się z dwóch części: **Platform** (webapp, dashboard, zarządzanie kolejką) i **Worker** (wykonuje taski). Obie części eksploatujemy self-hosted na własnej infrastrukturze. Ten runbook opisuje wyłącznie setup self-hosted z Trigger.dev v3.


<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">W skrócie - Artykuł 4 z 6 serii DevOps Runbook</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Trigger.dev jako osobny stack Docker z własnym PostgreSQL</li>
<li>Każdy task potrzebuje maxDuration, concurrencyLimit i konfiguracji retry</li>
<li>Klucze idempotencji przy zewnętrznych wywołaniach API</li>
<li>Dostęp do bazy danych ograniczony do potrzebnych pól</li>
<li>Logger Trigger.dev zamiast console.log</li>
</ul>
</div>

## Spis treści serii

Ten przewodnik jest częścią naszej serii runbooków DevOps dla self-hosted stacków aplikacyjnych.

1. [Supabase Self-Hosting Runbook](/pl/magazyn/supabase-self-hosting/)
2. [Next.js nad Supabase - bezpieczna eksploatacja](/pl/magazyn/nextjs-supabase-bezpieczna-konfiguracja/)
3. [Supabase Edge Functions - bezpieczne wdrożenie](/pl/magazyn/supabase-edge-functions-bezpieczenstwo/)
4. [Trigger.dev Background Jobs - bezpieczna eksploatacja](/pl/magazyn/trigger-dev-background-jobs/) - ten artykuł
5. [Claude Code jako kontrola bezpieczeństwa w DevOps](/pl/magazyn/claude-code-security-devops/)
6. [Security Baseline dla całego stacku](/pl/magazyn/security-baseline-stack/)

Artykuł 1 opisuje platformę. Artykuł 2 opisuje warstwę aplikacyjną. Artykuł 3 opisuje integracje. Ten artykuł opisuje **asynchroniczne przetwarzanie zadań**.

## Przegląd architektury

```
Browser
   |
Next.js (warstwa aplikacyjna)
   |
   +-- tasks.trigger("send-email", payload)    <- uruchomienie zadania
   |
Trigger.dev Platform
   |
   +-- Queue Management
   +-- Retry Logic
   +-- Dashboard / Monitoring
   |
Trigger.dev Worker
   |
   +-- send-email.ts           -> SMTP API
   +-- generate-report.ts      -> PDF + Supabase Storage
   +-- process-webhook.ts      -> Supabase DB (service_role)
   +-- sync-crm.ts             -> zewnętrzne CRM API
   |
   +-- Supabase (via service_role lub bezpośrednie połączenie DB)
       |
       PostgreSQL
```

Podstawowe zasady:

```
User Request       -> Next.js Server Action / Route Handler
Krótkie zdarzenie  -> Supabase Edge Function
Zadanie długotrwałe -> Trigger.dev Task
Periodyczne        -> Trigger.dev Scheduled Task
```


### Przewodnik konfiguracji tasków

| Typ taska | maxDuration | concurrencyLimit | Strategia Retry |
|---|---|---|---|
| Wysyłka e-mail | 30s | 5-10 | 3 próby, exponential backoff |
| Generowanie PDF | 120s | 2-3 | 2 próby, stały interwał |
| Inferencja AI (LLM) | 300s | 1-3 | 2 próby, exponential backoff |
| Migracja danych | 600s | 1 | 1 próba, manualna obsługa |
| Przetwarzanie webhooków | 30s | 10 | 3 próby, exponential backoff |

### Krytyczny punkt bezpieczeństwa

Trigger.dev Tasks mają typowo **pełny dostęp do bazy danych bez RLS**. Łączą się albo przez klucz `service_role` (via Supabase Client), albo przez bezpośrednie połączenie PostgreSQL (via `DATABASE_URL`). W obu przypadkach Row Level Security Policies nie działają. To najważniejsza różnica w porównaniu z żądaniami przechodzącymi przez PostgREST z kluczem `anon`.

Kto zna [podstawy zarządzania sekretami](/pl/magazyn/bezpieczenstwo-danych-ai-enterprise/), rozumie dlaczego ta separacja jest niezbędna.

## Część A - Decyzje architektoniczne

## A1 - Trigger.dev v3 self-hosted jako osobna usługa

### Implementacja

Trigger.dev działa oddzielnie od Next.js i Supabase jako osobny stack Docker. Architektura self-hosted v3 składa się z trzech komponentów:

```
Next.js App (Wasz serwer Hetzner / OVH)
   |
   +-- Trigger.dev Platform (webapp + kolejka + dashboard)
           |
           +-- Trigger.dev Worker (wykonuje wasze taski)
           |
           +-- Trigger.dev PostgreSQL (własna instancja DB)
```

```yaml
# docker-compose.trigger.yml
services:
  trigger-platform:
    image: ghcr.io/triggerdotdev/trigger.dev:v3    # wersja przypięta
    restart: unless-stopped
    ports:
      - "127.0.0.1:3040:3040"        # TYLKO localhost, Reverse Proxy przed nim
    environment:
      DATABASE_URL: postgresql://postgres:${TRIGGER_DB_PASSWORD}@trigger-db:5433/trigger
      DIRECT_URL: postgresql://postgres:${TRIGGER_DB_PASSWORD}@trigger-db:5433/trigger
      LOGIN_ORIGIN: https://trigger.example.com
      APP_ORIGIN: https://trigger.example.com
      MAGIC_LINK_SECRET: ${MAGIC_LINK_SECRET}
      SESSION_SECRET: ${SESSION_SECRET}
      ENCRYPTION_KEY: ${ENCRYPTION_KEY}
      RUNTIME_PLATFORM: docker-compose
      # Konfiguracja Workera
      DOCKER_SOCKET_LOCATION: /var/run/docker.sock
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock   # Worker-Management
    depends_on:
      trigger-db:
        condition: service_healthy
    networks:
      - trigger-internal

  trigger-db:
    image: postgres:15
    restart: unless-stopped
    ports:
      - "127.0.0.1:5433:5432"        # Port 5433, NIE 5432 (Supabase używa 5432)
    environment:
      POSTGRES_PASSWORD: ${TRIGGER_DB_PASSWORD}
      POSTGRES_DB: trigger
    volumes:
      - trigger-db-data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 10s
      timeout: 5s
      retries: 5
    networks:
      - trigger-internal

volumes:
  trigger-db-data:

networks:
  trigger-internal:
    driver: bridge
```

**Ważne:** Trigger.dev potrzebuje **własnej instancji PostgreSQL** na porcie 5433. Nie współdziel bazy danych Supabase (port 5432). Trigger.dev przechowuje status kolejki, historię uruchomień, stan workerów i metadane w swojej bazie. To inne dane niż dane aplikacyjne.

**Konfiguracja SDK w projekcie Next.js:**

```bash
# Instalacja Trigger.dev SDK
npm install @trigger.dev/sdk@3

# .env (Next.js)
TRIGGER_SECRET_KEY=tr_dev_...              # z self-hosted dashboardu
TRIGGER_API_URL=http://localhost:3040      # lokalny URL platformy
```

**Deployment Workera:**

W setup self-hosted v3 taski deployujecie przez CLI, które komunikuje się z lokalną platformą:

```bash
# Deploy tasków (wskazuje na waszą self-hosted platformę)
npx trigger.dev@latest deploy --self-hosted

# Lokalne środowisko deweloperskie
npx trigger.dev@latest dev
```

> **Uwaga:** Worker v3 Docker korzysta z Docker-in-Docker (montowanie socketu). Oznacza to, że platforma Trigger.dev potrzebuje dostępu do Docker Socket (`/var/run/docker.sock`). Ma to implikacje bezpieczeństwa: skompromitowany kontener Trigger.dev mógłby uruchamiać dowolne kontenery Docker. Dlatego Trigger.dev powinien działać na osobnym serwerze lub w izolowanej sieci Docker.

### Sprawdzalny warunek

```bash
# Kontenery działają?
docker compose -f docker-compose.trigger.yml ps
# Oczekiwanie: trigger-platform i trigger-db running

# Platforma dostępna (wewnętrznie)?
curl -s -o /dev/null -w "%{http_code}" http://localhost:3040
# Oczekiwanie: 200 lub 302 (redirect do logowania)

# Platforma NIE jest dostępna bezpośrednio z zewnątrz?
curl -s -o /dev/null -w "%{http_code}" https://trigger.example.com:3040
# Oczekiwanie: Connection refused (tylko przez Reverse Proxy)

# Trigger.dev DB na własnym porcie?
ss -tlnp | grep 5433
# Oczekiwanie: Listening na 127.0.0.1:5433

# Supabase DB na innym porcie?
ss -tlnp | grep 5432
# Oczekiwanie: Listening na 10.0.1.10:5432 (wewnętrzny interfejs)

# Docker Socket zamontowany?
docker compose -f docker-compose.trigger.yml exec trigger-platform ls -la /var/run/docker.sock
# Oczekiwanie: Socket obecny
```

### Scenariusz awarii

Jeśli Trigger.dev działa w tym samym procesie co Next.js, długotrwałe taski blokują serwer webowy. Task AI trwający 5 minut zajmuje wątek workera Next.js. Przy niewielkiej liczbie wątków workerów (domyślnie: 1 na CPU) cała aplikacja staje się nieresponsywna dla użytkowników. Jeśli Trigger.dev współdzieli bazę Supabase, zapytania kolejki zadań konkurują z żądaniami użytkowników o połączenia z bazą danych. Jeśli Docker Socket jest zamontowany bez izolacji sieci, skompromitowany task może uruchamiać kontenery z dostępem do sieci hosta.

## A2 - Kontrolowanie dostępu do bazy danych z tasków

### Implementacja

Taski potrzebują dostępu do danych aplikacyjnych w Supabase. Są dwa sposoby:

**Sposób 1: Supabase Client z service_role (zalecany)**

```typescript
// trigger/lib/supabase.ts
import { createClient } from '@supabase/supabase-js'

export function createTaskClient() {
  return createClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.SUPABASE_SERVICE_ROLE_KEY!
  )
}
```

Zaleta: Przechodzi przez PostgREST, korzysta z warstwy API Supabase.
Wada: Omija RLS (service_role).

**Sposób 2: Bezpośrednie połączenie DB (dla złożonych zapytań)**

```typescript
// trigger/lib/db.ts
import postgres from 'postgres'

const sql = postgres(process.env.DATABASE_URL!, {
  max: 5,                    // Limit puli połączeń
  idle_timeout: 20,
  connect_timeout: 10,
})

export { sql }
```

Wada: Omija zarówno RLS, jak i PostgREST. Pełny dostęp do bazy danych.

**Zasada:** Niezależnie od wybranego sposobu, task ma więcej uprawnień niż normalne żądanie użytkownika. Dlatego każdy task musi jasno definiować swój własny zakres.

```typescript
// POPRAWNIE: Task pobiera tylko to, czego potrzebuje
const { data } = await supabase
  .from('invoices')
  .select('id, amount, user_id')
  .eq('id', payload.invoiceId)
  .single()

// ŹŁLE: Task odczytuje wszystkie dane z tabeli
const { data } = await supabase
  .from('invoices')
  .select('*')
```

Kto zna [wzorce RLS z runbooka Supabase Self-Hosting](/pl/magazyn/supabase-self-hosting/), rozumie dlaczego różnica w zakresie jest krytyczna.

### Sprawdzalny warunek

```bash
# Które taski używają service_role lub DATABASE_URL?
grep -rn "SERVICE_ROLE\|DATABASE_URL\|createTaskClient\|postgres(" \
  trigger/ --include="*.ts"

# Dla każdego wyniku sprawdź ręcznie:
# - Czy task pobiera tylko dane, których potrzebuje?
# - Czy dane wejściowe są walidowane przed użyciem w zapytaniu?
# - Czy jest uzasadnienie dla bezpośredniego dostępu do DB zamiast Supabase Client?
```

### Scenariusz awarii

Task z bezpośrednim dostępem do bazy danych i niewalidowanymi danymi wejściowymi może prowadzić do SQL Injection. Task wykonujący `SELECT *` na dużych tabelach może obniżyć wydajność bazy danych dla wszystkich użytkowników. Niekontrolowana pula połączeń (brak limitu `max`) może zająć wszystkie dostępne połączenia PostgreSQL i sparaliżować całą aplikację.

## Część B - Kontrole implementacyjne

Te zasady obowiązują dla każdego taska i muszą być weryfikowane przy każdym deploymencie.

## B1 - Poprawna definicja tasków (API v3)

### Implementacja

Trigger.dev v3 używa funkcji `task()` z `@trigger.dev/sdk/v3`. Każdy task jest eksportowany i ma unikalne ID.

```typescript
// trigger/tasks/send-welcome-email.ts
import { task } from '@trigger.dev/sdk/v3'
import { z } from 'zod'
import { createTaskClient } from '../lib/supabase'

// 1. Definicja schematu payloadu
const payloadSchema = z.object({
  userId: z.string().uuid(),
  email: z.string().email(),
})

export const sendWelcomeEmail = task({
  id: 'send-welcome-email',

  // 2. Strategia retry
  retry: {
    maxAttempts: 3,
    factor: 2,
    minTimeoutInMs: 1_000,
    maxTimeoutInMs: 30_000,
  },

  // 3. Ograniczenie concurrency
  queue: {
    concurrencyLimit: 5,
  },

  // 4. Maksymalny czas wykonania
  maxDuration: 60,   // 60 sekund

  // 5. Funkcja run
  run: async (payload) => {
    // Walidacja danych wejściowych
    const parsed = payloadSchema.safeParse(payload)
    if (!parsed.success) {
      throw new Error(`Invalid payload: ${parsed.error.message}`)
    }

    const { userId, email } = parsed.data
    const supabase = createTaskClient()

    // Pobranie danych użytkownika (tylko niezbędnych)
    const { data: user } = await supabase
      .from('profiles')
      .select('full_name, locale')
      .eq('id', userId)
      .single()

    if (!user) {
      throw new Error(`User not found: ${userId}`)
    }

    // Wysłanie e-maila
    const response = await fetch('https://api.sendgrid.com/v3/mail/send', {
      method: 'POST',
      headers: {
        'Authorization': `Bearer ${process.env.SENDGRID_API_KEY}`,
        'Content-Type': 'application/json',
      },
      body: JSON.stringify({
        personalizations: [{ to: [{ email }] }],
        from: { email: 'hello@example.com' },
        subject: `Willkommen, ${user.full_name}!`,
        content: [{ type: 'text/plain', value: `...` }],
      }),
    })

    if (!response.ok) {
      // Rzucenie błędu, aby zadziałał retry
      throw new Error(`SendGrid error: ${response.status}`)
    }

    // Aktualizacja statusu w bazie danych
    await supabase
      .from('profiles')
      .update({ welcome_email_sent: true })
      .eq('id', userId)

    return { success: true, userId }
  },
})
```

### Triggerowanie taska z Next.js

```typescript
// app/actions/auth.ts
'use server'

import { tasks } from '@trigger.dev/sdk/v3'
import type { sendWelcomeEmail } from '@/trigger/tasks/send-welcome-email'

export async function onUserSignup(userId: string, email: string) {
  // Triggerowanie taska (wraca natychmiast)
  const handle = await tasks.trigger<typeof sendWelcomeEmail>(
    'send-welcome-email',
    { userId, email }
  )

  // handle.id zawiera Run-ID do śledzenia
  return { triggered: true, runId: handle.id }
}
```

### Sprawdzalny warunek

```bash
# Wszystkie taski muszą być wyeksportowane
for file in trigger/tasks/*.ts; do
  if ! grep -q "export const" "$file"; then
    echo "OSTRZEŻENIE: $file nie ma wyeksportowanego taska"
  fi
done

# Wszystkie taski muszą mieć ID
grep -rn "id:" trigger/tasks/ --include="*.ts" | grep "task({" -A1

# Taski NIE MOGĄ być triggerowane z kodu klienta
grep -rn "tasks.trigger\|\.trigger(" app/ --include="*.tsx" | grep -v "use server"
# Oczekiwanie: brak wyników (tylko w kontekście serwerowym)
```

### Scenariusz awarii

Task bez `export` nie zostanie rozpoznany przez Trigger.dev i zniknie podczas deploymentu bez komunikatu o błędzie. Task bez konfiguracji `retry` używa wartości domyślnej (brak retry), więc tymczasowy błąd API (np. timeout SendGrid) prowadzi do trwałej utraty e-maila.

## B2 - Zapewnienie idempotencji

### Implementacja

Trigger.dev ma wbudowany system idempotencji oparty na `idempotencyKey`. Jest to lepsze rozwiązanie niż własnoręcznie napisane sprawdzanie `findUnique`.

**Przy triggerowaniu (zapobiega podwójnemu uruchomieniu):**

```typescript
// Gdy ten sam użytkownik dwukrotnie szybko kliknie "Signup",
// task zostanie wykonany tylko raz
await tasks.trigger<typeof sendWelcomeEmail>(
  'send-welcome-email',
  { userId, email },
  {
    idempotencyKey: `welcome-email-${userId}`,
    idempotencyKeyTTL: '24h',     // Klucz ważny 24 godziny
  }
)
```

**Wewnątrz taska (zapobiega podwójnym efektom ubocznym przy retry):**

```typescript
import { task, idempotencyKeys } from '@trigger.dev/sdk/v3'

export const processPayment = task({
  id: 'process-payment',
  retry: { maxAttempts: 3 },

  run: async (payload: { orderId: string; amount: number }) => {
    // Idempotency Key dla wywołania Stripe
    // Przy retry wywołanie Stripe NIE zostanie powtórzone
    const stripeKey = await idempotencyKeys.create(
      `stripe-charge-${payload.orderId}`
    )

    const charge = await stripe.charges.create(
      {
        amount: payload.amount,
        currency: 'eur',
        source: 'tok_...',
      },
      { idempotencyKey: stripeKey }
    )

    // Aktualizacja DB jest idempotentna (upsert zamiast insert)
    await supabase
      .from('payments')
      .upsert({
        order_id: payload.orderId,
        stripe_charge_id: charge.id,
        status: 'completed',
      }, { onConflict: 'order_id' })

    return { chargeId: charge.id }
  },
})
```

### Sprawdzalny warunek

```bash
# Taski z zewnętrznymi wywołaniami API powinny mieć Idempotency Keys
for file in trigger/tasks/*.ts; do
  if grep -qE "fetch\(|stripe\.|sendgrid\.|resend\." "$file"; then
    if ! grep -qE "idempotencyKey|idempotencyKeys" "$file"; then
      echo "OSTRZEŻENIE: $file ma zewnętrzne wywołania API bez Idempotency Key"
    fi
  fi
done
```

### Scenariusz awarii

Bez ochrony idempotencji przy triggerowaniu podwójny webhook (Stripe ponawia przy timeout) może uruchomić ten sam task dwukrotnie. Bez idempotencji wewnątrz taska retry po częściowym błędzie może spowodować podwójne płatności lub podwójne wysłanie e-maili.

## B3 - Poprawna konfiguracja timeoutów i concurrency

### Implementacja

Trigger.dev v3 oferuje `maxDuration` (limit czasu wykonania na task) i `concurrencyLimit` (równoległe wykonania). Oba muszą być ustawiane świadomie dla każdego taska.

```typescript
import { task, queue } from '@trigger.dev/sdk/v3'

// Współdzielona kolejka dla tasków e-mailowych (zapobiega SMTP Rate Limiting)
const emailQueue = queue({
  name: 'email-processing',
  concurrencyLimit: 5,       // maks. 5 równoległych tasków e-mailowych
})

export const sendEmail = task({
  id: 'send-email',
  queue: emailQueue,
  maxDuration: 30,            // maks. 30 sekund

  run: async (payload) => {
    // ...
  },
})

// Taski AI potrzebują więcej czasu, ale mniej równoległości
export const analyzeDocument = task({
  id: 'analyze-document',
  queue: { concurrencyLimit: 2 },   // maks. 2 równoległe wywołania AI
  maxDuration: 300,                  // maks. 5 minut

  run: async (payload) => {
    // ...
  },
})

// Krytyczne taski wymagające sekwencyjnego wykonania
export const processInvoice = task({
  id: 'process-invoice',
  queue: { concurrencyLimit: 1 },    // ściśle sekwencyjnie
  maxDuration: 60,

  run: async (payload) => {
    // ...
  },
})
```

**Wartości orientacyjne:**

```
Wysyłka e-maila:          maxDuration 30s,    concurrency 5-10
Generowanie PDF:          maxDuration 120s,   concurrency 2-3
Inferecja AI (LLM):       maxDuration 300s,   concurrency 1-3
Migracja bazy danych:     maxDuration 600s,   concurrency 1
Przetwarzanie webhooków:  maxDuration 30s,    concurrency 10
```

### Sprawdzalny warunek

```bash
# Wszystkie taski muszą mieć maxDuration
for file in trigger/tasks/*.ts; do
  if ! grep -q "maxDuration" "$file"; then
    echo "OSTRZEŻENIE: $file nie ma maxDuration"
  fi
done

# Wszystkie taski muszą mieć concurrencyLimit (lub używać współdzielonej kolejki)
for file in trigger/tasks/*.ts; do
  if ! grep -qE "concurrencyLimit|queue:" "$file"; then
    echo "OSTRZEŻENIE: $file nie ma limitu concurrency"
  fi
done
```

### Scenariusz awarii

Bez `maxDuration` task z zawieszonym wywołaniem API może działać w nieskończoność i trwale blokować slot workera. Bez `concurrencyLimit` 100 jednocześnie wyzwolonych tasków e-mailowych może przeciążyć dostawcę SMTP i doprowadzić do Rate Limiting. Bez limitu concurrency na taskach intensywnie korzystających z bazy danych wszystkie połączenia PostgreSQL mogą zostać zajęte jednocześnie.

> **Statystyka:** Zgodnie z danymi Trigger.dev ponad 40% samodzielnie hostowanych instancji produkcyjnych ma taski bez skonfigurowanego maxDuration - co prowadzi do cichego blokowania workerów.


## B4 - Sekrety i zmienne środowiskowe

### Implementacja

Taski Trigger.dev działają w osobnym środowisku. Sekrety muszą być przekazywane jawnie przez konfigurację Docker Compose.

```bash
# .env.trigger (tylko na serwerze, nie w Git)
TRIGGER_DB_PASSWORD=...
MAGIC_LINK_SECRET=...
SESSION_SECRET=...
ENCRYPTION_KEY=...

# Sekrety dla waszych tasków (przekazywane do Workera)
SUPABASE_SERVICE_ROLE_KEY=eyJ...
DATABASE_URL=postgresql://...
SENDGRID_API_KEY=SG.xxx
OPENAI_API_KEY=sk-xxx
STRIPE_SECRET_KEY=sk_live_xxx
```

Sekrety tasków w setup self-hosted przekazywane są do kontenerów workerów przez dashboard Trigger.dev (Environment Variables) lub przez środowisko Docker.

W kodzie:

```typescript
// POPRAWNIE: zmienna środowiskowa
const apiKey = process.env.SENDGRID_API_KEY

// ŹŁLE: na stałe w kodzie
const apiKey = 'SG.xxx...'
```

### Sprawdzalny warunek

```bash
# Sekrety na stałe w kodzie?
grep -rn "sk_live\|sk_test\|SG\.\|sk-\|Bearer ey" \
  trigger/ --include="*.ts"
# Oczekiwanie: brak wyników

# .env.trigger nie jest w Git?
git ls-files .env.trigger
# Oczekiwanie: pusty wynik

# Wszystkie wymagane zmienne środowiskowe ustawione?
for var in SUPABASE_SERVICE_ROLE_KEY SENDGRID_API_KEY; do
  if [ -z "${!var}" ]; then
    echo "BRAK: $var"
  fi
done
```

### Scenariusz awarii

Sekrety w plikach tasków trafiają do repozytorium Git i do artefaktu build (obraz Worker). W setup self-hosted obrazy workerów budowane są i przechowywane lokalnie. Sekrety zakodowane na stałe w tych obrazach są widoczne dla każdego z dostępem do hosta Docker lub rejestru.

## B5 - Obsługa błędów i logowanie

### Implementacja

Taski muszą poprawnie obsługiwać błędy i nie logować wrażliwych danych.

```typescript
import { task, logger } from '@trigger.dev/sdk/v3'

export const processOrder = task({
  id: 'process-order',

  retry: {
    maxAttempts: 3,
    factor: 2,
    minTimeoutInMs: 1_000,
    maxTimeoutInMs: 30_000,
  },

  run: async (payload: { orderId: string }) => {
    // Logger Trigger.dev (strukturalny, widoczny w dashboardzie)
    logger.info('Processing order', { orderId: payload.orderId })

    try {
      const result = await processOrderInternal(payload.orderId)

      logger.info('Order processed', {
        orderId: payload.orderId,
        status: result.status,
      })

      return result

    } catch (error) {
      // Strukturalne logowanie (bez wrażliwych szczegółów)
      logger.error('Order processing failed', {
        orderId: payload.orderId,
        errorMessage: error instanceof Error ? error.message : 'Unknown error',
        // NIE: error.stack, szczegóły payloadu, dane użytkownika
      })

      // Przekazanie błędu, aby zadziałał retry
      throw error
    }
  },

  // Hook onFailure: wywoływany po wyczerpaniu wszystkich retry
  onFailure: async (payload, error, params) => {
    logger.error('Order permanently failed after all retries', {
      orderId: payload.orderId,
      attemptNumber: params.run.attemptNumber,
    })

    // Wysłanie alertu (np. powiadomienie Slack)
    await sendAlertToOps({
      task: 'process-order',
      orderId: payload.orderId,
      error: error.message,
    })
  },
})
```

**Czego NIE wolno logować:**

```typescript
// ŹŁLE
logger.info('Processing user', { user })             // pełny obiekt użytkownika
logger.info('API call', { headers: req.headers })     // nagłówek Auth z tokenem
logger.info('DB query', { connectionString })         // URL bazy danych
console.log(process.env.SUPABASE_SERVICE_ROLE_KEY)    // sekret
```

### Sprawdzalny warunek

```bash
# console.log zamiast loggera?
grep -rn "console\.log\|console\.error" trigger/tasks/ --include="*.ts"
# Oczekiwanie: brak wyników (zawsze używaj loggera z @trigger.dev/sdk)

# Wrażliwe dane w logach?
grep -rn "logger\.\(info\|error\|warn\)" trigger/ --include="*.ts" | \
  grep -iE "password|secret|key|token|email.*:" | \
  grep -v "orderId\|taskId\|runId"
# Oczekiwanie: brak wyników
```

### Scenariusz awarii

Trigger.dev przechowuje wszystkie logi i wyświetla je w dashboardzie. Jeśli `console.log(user)` zaloguje pełny obiekt użytkownika z adresem e-mail i metadanymi, dane te będą widoczne w dashboardzie Trigger.dev dla każdego z dostępem do dashboardu, nawet miesiące później, ponieważ historia uruchomień jest przechowywana na stałe.

## Część C - Eksploatacja i monitoring

## C1 - Monitoring i alerting

### Implementacja

Trigger.dev ma wbudowany dashboard z historią uruchomień, logami i traces. Dodatkowo te metryki powinny być aktywnie monitorowane:

```
Krytyczne metryki:
  - Failed Runs (ostatnie 24h)         -> Alert gdy > 5
  - Queue Length                       -> Alert gdy > 100
  - Average Run Duration               -> Alert gdy > 2x Baseline
  - Runs w stanie WAITING              -> Info, brak natychmiastowego alertu
```

**Zabezpieczenie dashboardu self-hosted:**

```
# Dashboard Trigger.dev NIE MOŻE być publicznie dostępny
# Dostęp tylko przez:
# - Reverse Proxy z Basic Auth
# - VPN / WireGuard
# - SSH Tunnel

# Przykład: SSH Tunnel do dashboardu
ssh -L 3040:localhost:3040 deploy@trigger-server

# Następnie w przeglądarce: http://localhost:3040
```

**Zautomatyzowany Health Check:**

```bash
#!/bin/bash
# scripts/check-trigger-health.sh

# Platforma Trigger.dev dostępna?
HEALTH=$(curl -s -o /dev/null -w "%{http_code}" http://localhost:3040/healthcheck)
if [ "$HEALTH" != "200" ]; then
  echo "KRYTYCZNE: Platforma Trigger.dev niedostępna"
fi

# Kontener Workera działa?
WORKER_STATUS=$(docker compose -f docker-compose.trigger.yml ps trigger-worker --format '{{.State}}')
if [ "$WORKER_STATUS" != "running" ]; then
  echo "KRYTYCZNE: Worker Trigger.dev nie działa ($WORKER_STATUS)"
fi

# Failed Runs z ostatnich 24h (przez bazę Trigger.dev)
FAILED=$(docker compose -f docker-compose.trigger.yml exec -T trigger-db \
  psql -U postgres -d trigger -t -c \
  "SELECT count(*) FROM task_runs WHERE status = 'FAILED' AND created_at > now() - interval '24 hours';" 2>/dev/null)

if [ "${FAILED:-0}" -gt 5 ]; then
  echo "OSTRZEŻENIE: $FAILED nieudanych uruchomień w ciągu ostatnich 24h"
fi
```

### Sprawdzalny warunek

```bash
# Dashboard dostępny tylko wewnętrznie?
curl -s -o /dev/null -w "%{http_code}" https://trigger.example.com:3040
# Oczekiwanie: Connection refused lub 401

# Skrypt Health Check uruchamiany codziennie?
crontab -l | grep "check-trigger-health"
# Oczekiwanie: wpis obecny
```

## C2 - Obsługa Dead Letter

### Implementacja

Taski, które zawiodą po wyczerpaniu wszystkich retry, trafiają do statusu `FAILED`. Muszą być aktywnie obsługiwane.

```typescript
import { task, logger } from '@trigger.dev/sdk/v3'
import { createTaskClient } from '../lib/supabase'

export const criticalTask = task({
  id: 'critical-task',

  retry: {
    maxAttempts: 5,
    factor: 2,
    minTimeoutInMs: 2_000,
    maxTimeoutInMs: 60_000,
  },

  run: async (payload: { orderId: string }) => {
    // ... logika taska
  },

  onFailure: async (payload, error, params) => {
    const supabase = createTaskClient()

    // Zapis nieudanego zadania do osobnej tabeli
    await supabase
      .from('failed_jobs')
      .insert({
        task_id: 'critical-task',
        payload: JSON.stringify(payload),
        error_message: error.message,
        attempts: params.run.attemptNumber,
        failed_at: new Date().toISOString(),
        resolved: false,
      })

    // Alert
    logger.error('Critical task permanently failed', {
      orderId: payload.orderId,
      attempts: params.run.attemptNumber,
    })
  },
})
```

```sql
-- Migracja: tabela failed_jobs
CREATE TABLE IF NOT EXISTS failed_jobs (
  id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
  task_id TEXT NOT NULL,
  payload JSONB NOT NULL,
  error_message TEXT,
  attempts INTEGER,
  failed_at TIMESTAMPTZ NOT NULL,
  resolved BOOLEAN DEFAULT false,
  resolved_at TIMESTAMPTZ,
  resolved_by TEXT
);

-- RLS: dostęp tylko dla service_role
ALTER TABLE failed_jobs ENABLE ROW LEVEL SECURITY;
-- Brak Policy dla anon/authenticated = brak dostępu przez PostgREST
```

### Sprawdzalny warunek

```bash
# Czy istnieją nierozwiązane Failed Jobs?
# Przez Supabase Client lub bezpośrednie zapytanie DB
psql -c "SELECT count(*) FROM failed_jobs WHERE resolved = false;"
# Oczekiwanie: 0 (lub aktywnie w trakcie obsługi)

# Czy wszystkie krytyczne taski mają hook onFailure?
grep -L "onFailure" trigger/tasks/*.ts
# Oczekiwanie: tylko niekrytyczne taski bez onFailure
```

## C3 - Integracja z Claude Code

### Architektura

```
Git Push / PR
   |
   +-- Kontrole deterministyczne (CI/CD)
   |   +-- Wszystkie taski mają maxDuration?
   |   +-- Wszystkie taski mają concurrencyLimit?
   |   +-- Zewnętrzne wywołania API mają Idempotency Keys?
   |   +-- Brak hardcoded secrets?
   |   +-- Brak console.log (tylko logger)?
   |
   +-- Analiza Claude Code (cotygodniowo lub przy PR)
       +-- Nowe taski bez strategii retry?
       +-- Dostęp do DB poprawnie ograniczony?
       +-- Wzorce idempotencji spójne?
       +-- onFailure dla krytycznych tasków obecny?
       +-- Limity concurrency odpowiednie?
```

### Skrypt CI

```bash
#!/bin/bash
# scripts/check-trigger-tasks.sh

REPORT=""

# 1. Taski bez maxDuration
for file in trigger/tasks/*.ts; do
  name=$(basename "$file" .ts)
  if ! grep -q "maxDuration" "$file"; then
    REPORT+="OSTRZEŻENIE: $name nie ma maxDuration\n"
  fi
done

# 2. Taski bez Concurrency
for file in trigger/tasks/*.ts; do
  name=$(basename "$file" .ts)
  if ! grep -qE "concurrencyLimit|queue:" "$file"; then
    REPORT+="OSTRZEŻENIE: $name nie ma limitu concurrency\n"
  fi
done

# 3. Zewnętrzne wywołania API bez Idempotency
for file in trigger/tasks/*.ts; do
  name=$(basename "$file" .ts)
  if grep -qE "fetch\(|stripe\.|resend\." "$file"; then
    if ! grep -qE "idempotencyKey|idempotencyKeys" "$file"; then
      REPORT+="OSTRZEŻENIE: $name ma zewnętrzne wywołania API bez Idempotency\n"
    fi
  fi
done

# 4. Hardcoded Secrets
SECRETS=$(grep -rn "sk_live\|sk_test\|SG\.\|sk-" trigger/ --include="*.ts" 2>/dev/null)
if [ -n "$SECRETS" ]; then
  REPORT+="KRYTYCZNE: Hardcoded Secrets:\n$SECRETS\n\n"
fi

# 5. console.log zamiast loggera
CONSOLE=$(grep -rn "console\.\(log\|error\|warn\)" trigger/tasks/ --include="*.ts" 2>/dev/null)
if [ -n "$CONSOLE" ]; then
  REPORT+="OSTRZEŻENIE: console.log zamiast loggera Trigger.dev:\n$CONSOLE\n\n"
fi

# 6. Niewyeksportowane taski
for file in trigger/tasks/*.ts; do
  name=$(basename "$file" .ts)
  if ! grep -q "export const" "$file"; then
    REPORT+="KRYTYCZNE: Task $name nie jest wyeksportowany\n"
  fi
done

if [ -n "$REPORT" ]; then
  echo -e "=== Trigger.dev Task Security Check ===\n$REPORT"
else
  echo "Wszystkie kontrole Trigger.dev przeszły pomyślnie."
fi
```

Claude nie wykonuje **żadnych automatycznych zmian na produkcji**.

## Lista kontrolna deploymentu

Przed każdym deploymentem tasków Trigger.dev sprawdź:

```
Architektura
  [ ] Trigger.dev działa jako osobna usługa (nie w procesie Next.js)
  [ ] Własna instancja PostgreSQL (nie baza Supabase)
  [ ] Dashboard dostępny tylko wewnętrznie

Definicja tasków
  [ ] Każdy task jest wyeksportowany
  [ ] Każdy task ma unikalne ID
  [ ] Każdy task ma maxDuration
  [ ] Każdy task ma concurrencyLimit lub współdzieloną kolejkę
  [ ] Każdy task ma konfigurację retry

Idempotencja
  [ ] Wywołania trigger mają idempotencyKey tam, gdzie to konieczne
  [ ] Zewnętrzne wywołania API wewnątrz tasków mają Idempotency
  [ ] Operacje bazodanowe są idempotentne (upsert zamiast insert, gdzie to możliwe)

Dostęp do bazy danych
  [ ] service_role tylko przez createTaskClient()
  [ ] Zapytania pobierają tylko potrzebne dane (brak SELECT *)
  [ ] Pula połączeń ograniczona (max: 5-10)

Sekrety
  [ ] Brak hardcoded secrets w kodzie
  [ ] Sekrety przez zmienne środowiskowe / dashboard
  [ ] .env.trigger nie jest w Git

Logowanie
  [ ] Logger Trigger.dev zamiast console.log
  [ ] Brak wrażliwych danych w logach (obiekty użytkowników, tokeny, klucze)

Obsługa błędów
  [ ] Krytyczne taski mają hook onFailure
  [ ] Failed Jobs zapisywane w tabeli failed_jobs
  [ ] Alerting przy trwałych błędach skonfigurowany
```

## Podsumowanie

Trigger.dev stanowi warstwę przetwarzania zadań w tle w stacku. Prawidłowo wdrożony przetwarza asynchroniczne zadania niezawodnie, z retry, idempotencją i monitoringiem.

Najkrytyczniejszym punktem bezpieczeństwa jest dostęp do bazy danych: taski mają typowo więcej uprawnień niż normalne żądania użytkowników, ponieważ działają z `service_role` lub bezpośrednim połączeniem DB. Dlatego walidacja danych wejściowych, ograniczenie zakresu i idempotencja muszą być świadomie implementowane przy każdym tasku.

Połączenie wbudowanej logiki retry Trigger.dev, świadomych limitów concurrency i kontekstowej analizy Claude Code prowadzi do stabilnych workflow przetwarzania w tle, które działają poprawnie nawet przy częściowych awariach.

Kto stosuje te zasady razem z architekturą [Cert-Ready by Design](/pl/magazyn/cert-ready-by-design/), buduje weryfikowalne bezpieczeństwo zamiast audytów po fakcie.

<div class="not-prose my-12 border border-gosign-border bg-gosign-light rounded-card p-6 lg:p-8">
<div class="flex items-start gap-4">
<div class="flex-shrink-0 w-12 h-12 bg-gosign-dark rounded-card flex items-center justify-center">
<svg width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="white" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 15v4a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2v-4"/><polyline points="7 10 12 15 17 10"/><line x1="12" y1="15" x2="12" y2="3"/></svg>
</div>
<div>
<h2 class="text-h3 font-bold text-gosign-dark mb-2" id="pobierz-liste-kontrolna-audytu">Pobierz listę kontrolną audytu</h2>
<p class="text-body text-gosign-text mb-2">Przygotowany prompt dla Claude Code. Prześlij plik na swój serwer i uruchom Claude Code w katalogu projektu konfiguracji Trigger.dev. Claude Code automatycznie sprawdzi wszystkie punkty bezpieczeństwa z tego runbooka i zgłosi ZALICZONY, OSTRZEŻENIE lub KRYTYCZNY.</p>
<p class="text-sm text-gosign-text mb-4 font-mono">claude -p "$(cat claude-check-artikel-4-trigger-dev-pl.md)" --allowedTools Read,Grep,Glob,Bash</p>
<a href="/downloads/claude-check-artikel-4-trigger-dev-pl.md" download class="inline-flex items-center px-6 py-3 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors text-small uppercase tracking-wider">Pobierz listę kontrolną</a>
</div>
</div>
</div>

## Spis treści serii

Ten artykuł jest częścią naszej serii DevOps dla self-hosted stacków aplikacyjnych.

1. [Supabase Self-Hosting Runbook](/pl/magazyn/supabase-self-hosting/)
2. [Next.js nad Supabase - bezpieczna eksploatacja](/pl/magazyn/nextjs-supabase-bezpieczna-konfiguracja/)
3. [Supabase Edge Functions - bezpieczne wdrożenie](/pl/magazyn/supabase-edge-functions-bezpieczenstwo/)
4. [Trigger.dev Background Jobs - bezpieczna eksploatacja](/pl/magazyn/trigger-dev-background-jobs/) - ten artykuł
5. [Claude Code jako kontrola bezpieczeństwa w DevOps](/pl/magazyn/claude-code-security-devops/)
6. [Security Baseline dla całego stacku](/pl/magazyn/security-baseline-stack/)

W kolejnym artykule pokażemy, jak **Claude Code jest wykorzystywany jako kontrola bezpieczeństwa w workflow DevOps** - jako nadrzędna warstwa analityczna obejmująca wszystkie dotychczasowe artykuły.

--- Trzy rodzaje decyzji: Kiedy człowiek, kiedy AI ---
> Nie każda decyzja wymaga człowieka. I nie każda powinna być pozostawiona AI. Framework przyporządkowania - z konkretnymi przykładami z HR.

## Pytanie, które zadaje każdy dział HR

„Jakie decyzje AI może podejmować samodzielnie - a jakie muszą pozostać przy człowieku?"

To pytanie pojawia się w każdej rozmowie o AI w procesach HR. Od Rady Zakładowej, od zarządu, od działu compliance. A typowa odpowiedź - „AI wspiera, człowiek decyduje" - jest zbyt nieprecyzyjna do zastosowania produkcyjnego.

W praktyce bowiem pojedynczy proces HR składa się z dziesiątek pojedynczych decyzji. Przy przetwarzaniu zwolnień lekarskich na przykład: Czy dokument jest kompletny? Który układ zbiorowy obowiązuje? Czy czas choroby przekracza granicę kontynuacji wynagrodzenia? Czy należy wszcząć procedurę reintegracji (BEM)? Kto zostaje poinformowany?

Niektóre z tych decyzji wymagają człowieka. Niektóre nie. A niektóre świadomie NIE powinny leżeć przy człowieku - ponieważ AI podejmuje je udowodnialnie lepiej.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">W skrócie - Trzy rodzaje decyzji</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Każdy proces biznesowy rozkłada się na mikro-decyzje trzech typów: decyduje człowiek, stosowany jest zestaw reguł lub AI decyduje samodzielnie.</li>
<li>AI samodzielnie to nie kategoria dla trywialnych zadań - to kategoria dla decyzji, w których spójność, odporność na zmęczenie i kompletność przeważają nad uznaniowością.</li>
<li>AI przewyższa człowieka strukturalnie na trzech płaszczyznach: identyczne wyniki między oddziałami, brak spadku jakości z powodu zmęczenia, kompletna weryfikacja reguł za każdym razem.</li>
<li>Pojedynczy proces HR, jak przetwarzanie zwolnień, zawiera wszystkie trzy typy - Decision Layer wymusza właściwe przyporządkowanie na każdym etapie.</li>
<li>Ten framework czyni argumentację wobec Rady Zakładowej transparentną: AI decyduje, gdzie wymaga tego jakość. Człowiek decyduje, gdzie wymaga tego uznaniowość.</li>
</ul>
</div>

[McKinsey Global Institute (2023)](https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/the-economic-potential-of-generative-ai-the-next-productivity-frontier) szacuje, że od 60 do 70 procent dzisiejszego czasu pracy przypada na czynności, które mogłyby być zautomatyzowane obecną technologią AI - ale tylko decyzje z jasnymi regułami i niskim zakresem uznaniowości nadają się do pełnej automatyzacji.

## Trzy rodzaje decyzji

### Rodzaj 1: Decyduje człowiek

Tutaj człowiek musi podjąć finalną decyzję. Agent może przygotować, zaproponować, zebrać materiały - ale sama decyzja leży przy człowieku.

**Kiedy:** Margines uznaniowości, ryzyko dyskryminacji, obowiązek konsultacji z Radą Zakładową, indywidualne sytuacje.

**Przykład: Reintegracja po długotrwałej chorobie.** Agent ma wszystkie dane: czas choroby, historia reintegracji, zalecenia lekarza medycyny pracy, dostępne stanowiska. Ale decyzja, który model reintegracji pasuje do tego konkretnego człowieka, wymaga osoby. Chodzi o indywidualną sytuację, o empatię, o rozmowę z daną osobą. Rada Zakładowa ma prawo do konsultacji w tej sprawie. A gdy decyzja jest błędna, ma realne konsekwencje dla prawdziwego człowieka.

**Co robi Decision Layer:** Wymusza Human-in-the-Loop. Technicznie, nie organizacyjnie. Agent nie może podjąć tej decyzji autonomicznie - nawet jeśli jego confidence jest wysoki.

### Rodzaj 2: Decyduje zestaw reguł

Logika deterministyczna. Jeśli warunek X, to wynik Y. Brak marginesu interpretacji.

**Kiedy:** Układ zbiorowy, porozumienie zakładowe, prawo podatkowe, zaszeregowanie, kalkulacja terminów.

**Przykład: Zaszeregowanie do przedziału wynagrodzeniowego.** Nowy pracownik, profil stanowiska jest dostępny, układ zbiorowy jest jednoznaczny. Zaszeregowanie wynika z kryteriów w układzie zbiorowym. To nie jest decyzja wymagająca interpretacji - to zastosowanie reguły. Decision Layer stosuje aktualną wersję reguły i dokumentuje wynik.

**Co robi Decision Layer:** Zapewnia stosowanie aktualnej wersji reguły. Gdy układ zbiorowy się zmienia, od dnia wejścia w życie obowiązuje nowa wersja - automatycznie, bez konieczności informowania 50 referentów w 12 oddziałach.

### Rodzaj 3: AI decyduje samodzielnie

I tu robi się interesująco. Bo ta kategoria jest najczęściej źle opowiadana. Typowe przedstawienie: „W prostych standardowych przypadkach AI też może zdecydować samodzielnie." Brzmi jak pozwolenie na trywialne rzeczy.

Rzeczywistość jest inna. Istnieją decyzje, w których AI jest nie tylko szybsza, ale **udowodnialnie lepsza** niż człowiek. Nie dlatego, że AI jest mądrzejsza - lecz dlatego, że nie ma trzech strukturalnych słabości człowieka.

#### Przewaga 1: Konsekwencja w oddziałach i między osobami

50 referentów w 12 oddziałach stosuje ten sam układ zbiorowy. Każdy interpretuje przypadki graniczne nieco inaczej. W Hamburgu wniosek o świadczenie specjalne zostaje zatwierdzony, w Monachium ten sam przypadek jest odrzucany. To nie jest problem wyszkolenia - to naturalna wariancja ludzkich decyzji przy niejednoznacznych regułach.

AI pracująca na wersjonowanym zestawie reguł decyduje identycznie. Za każdym razem. W każdym oddziale. O 9 rano i o 16 po południu.

**Konkretnie:** Weryfikacja terminu kontynuacji wynagrodzenia. Ten sam przypadek, ta sama reguła, ten sam wynik. Niezależnie od tego, który referent w którym oddziale obsługuje sprawę.

#### Przewaga 2: Odporność na zmęczenie

Rekruter ocenia w poniedziałek rano inaczej niż w piątek po południu. Po 50. aplikacji uwaga spada. Poprzedni kandydat był szczególnie silny - następny wydaje się słabszy w porównaniu, choć obiektywnie spełnia wymagania (Anchoring-Bias). Rekruter właśnie dostał złe wiadomości - następne trzy oceny wypadają surowiej (Affect Heuristic).

To nie są osobiste słabości. To ludzka kognicja. Dobrze zbadana, wielokrotnie udowodniona i mierzalna w każdym powtarzalnym procesie decyzyjnym.

AI ocenia aplikację numer 1 z taką samą starannością jak aplikację numer 200. Nie ma złego dnia.

**Konkretnie:** Dopasowanie wymagań w rekrutacji. Każda aplikacja jest weryfikowana wobec tego samego profilu kryteriów. Nie pod wpływem kolejności aplikacji, nie pory dnia, nie stanu emocjonalnego rekrutera.

#### Przewaga 3: Kompletność przy weryfikacji reguł

To przewaga, która jest najbardziej niedoceniana.

Referent HR sprawdza zwolnienie lekarskie wobec trzech-czterech kryteriów, które akurat przychodzą mu na myśl: czas choroby, termin kontynuacji wynagrodzenia, może jeszcze próg BEM. Ale czy sprawdza też regulację okresu oczekiwania? Regułę specjalną dla pracowników niepełnoetatowych w układzie zakładowym? Obowiązek zgłoszenia wobec stowarzyszenia branżowego przy określonych schorzeniach? Przypadek specjalny przy wypadkach przy pracy? Regulację dla umów na czas określony?

Za każdym razem? Także w piątek o 16? Także gdy równolegle obsługuje pięć innych spraw?

AI sprawdza wobec wszystkich obowiązujących reguł, w aktualnej wersji, kompletnie i udokumentowanie. Nie dlatego, że jest mądrzejsza - lecz dlatego, że nie zapomina. I dlatego, że jej zestaw reguł nie tkwi w głowach, lecz w wersjonowanym systemie.

**Konkretnie:** Przetwarzanie zwolnień lekarskich. Agent sprawdza każde eAU wobec wszystkich 12 istotnych kryteriów z układu zbiorowego, porozumienia zakładowego i prawa. Za każdym razem. Wynik: Mniej błędów, które wychodzą na jaw dopiero przy następnej kontroli.

## Dlaczego pojedynczy proces zawiera wszystkie trzy rodzaje

Framework staje się praktycznie użyteczny dopiero wtedy, gdy zrozumie się: Pojedynczy proces HR prawie zawsze zawiera WSZYSTKIE trzy typy decyzji.

Weźmy przetwarzanie zwolnień lekarskich jako ciągły przykład:

| Krok | Rodzaj decyzji | Dlaczego |
|---|---|---|
| Odbiór i walidacja danych eAU | **AI samodzielnie** | Klasyfikacja dokumentów, wysoka trafność, dane wejściowe ustrukturyzowane |
| Porównanie z danymi kadrowymi | Zestaw reguł | Deterministyczne, brak interpretacji |
| Sprawdzenie terminu kontynuacji wynagrodzenia | **AI samodzielnie** | Sprawdza wobec WSZYSTKICH kryteriów układu zbiorowego, bardziej konsekwentna niż jakikolwiek referent |
| Sprawdzenie obowiązku reintegracji (> 6 tygodni w 12 miesiącach) | Człowiek | Ryzyko dyskryminacji przy danych zdrowotnych, obowiązek konsultacji z Radą Zakładową |
| Poinformowanie przełożonego | **AI samodzielnie** | Konsekwentna informacja, brak zapominania, brak marginesu interpretacji przy pytaniu CO jest komunikowane (tylko nieobecność i czas trwania, bez diagnozy) |
| Wdrożenie środków reintegracyjnych | Człowiek | Indywidualna sytuacja, margines uznaniowości, konsultacja z Radą Zakładową |

Zwróćcie uwagę na trzeci wiersz: „Sprawdzenie terminu kontynuacji wynagrodzenia" jest przy „AI samodzielnie", nie przy „Zestaw reguł". Dlaczego? Ponieważ AI nie stosuje tu prostej logiki jeżeli-to, lecz przeprowadza weryfikację KOMPLETNIE wobec wszystkich obowiązujących zestawów reguł - coś, czego człowiek w praktyce nigdy nie robi kompletnie, bo nie ma wszystkich regulacji specjalnych w głowie.

To jest kluczowy punkt: „AI samodzielnie" to nie kategoria dla trywialnych rzeczy. To kategoria dla decyzji, w których konsekwencja, odporność na zmęczenie i kompletność są ważniejsze niż margines uznaniowości.

## Co to oznacza dla Rady Zakładowej

Rada Zakładowa jest często sceptyczna wobec autonomii AI. Słusznie - gdy nie jest jasne, DLACZEGO AI decyduje samodzielnie.

Z frameworkiem trzech rodzajów argumentacja staje się transparentna:

„AI decyduje samodzielnie przy weryfikacji terminów. Nie dlatego, że chcemy oszczędzać etaty. Lecz dlatego, że wiemy, iż 50 referentów w 12 oddziałach oblicza ten sam termin w różny sposób. AI liczy zawsze poprawnie. A gdy nie jest pewna, eskaluje do człowieka. To jest przejrzyste, udokumentowane i w każdej chwili widoczne w portalu audytora."

To argument, który Rada Zakładowa rozumie. Nie chodzi o zastępowanie, lecz o zapewnienie jakości.

## Decision Layer sprawia, że przyporządkowanie staje się operacyjne

Framework pozostaje teorią, jeśli nie jest technicznie egzekwowany. [Decision Layer](/pl/decision-layer/) implementuje przyporządkowanie trzech rodzajów dla każdego kroku procesu:

Dla każdej mikrodecyzji jest zdefiniowane: człowiek, zestaw reguł lub AI. Przy decyzjach AI jest udokumentowane, dlaczego AI jest tu właściwym wyborem. Przy decyzjach ludzkich Human-in-the-Loop jest wymuszony technicznie. Przy decyzjach regułowych jest zdeponowana aktualna wersja reguły. Każda decyzja - niezależnie od rodzaju - generuje akt decyzyjny: input, reguła wraz z wersją, pewność, wynik, ścieżka podważenia. To podstawa podważalności wg art. 86 EU AI Act.

> [Decision Layer - przegląd i przykłady](/pl/decision-layer/)

> [Akt decyzyjny: dlaczego każda decyzja AI musi być podważalna](/pl/magazyn/akt-decyzyjny-podwazalne-decyzje-ai/)

> [Dlaczego projekty AI w HR nie udają się](/pl/magazyn/dlaczego-projekty-ai-w-hr-nie-udaja-sie/)

<a href="/pl/kontakt/" target="_blank" rel="noopener noreferrer">Umów spotkanie</a> - Pokażemy Wam na Waszym konkretnym procesie, które decyzje pozostają przy człowieku, a które AI podejmuje lepiej.

--- Umowa powierzenia dla AI: Luki w standardowej umowie ---
> Dlaczego standardowe umowy powierzenia nie wystarczą dla enterprise AI. Lista kontrolna wymagań dla HR i compliance.

Umowa powierzenia przetwarzania danych dla infrastruktury AI musi obejmować dziesięć obszarów, których standardowe umowy SaaS nie regulują: polityki logowania promptów, separacja środowisk (dev/staging/prod), łańcuchy dostawców modeli, przetwarzanie in-flight vs. at-rest, ochrona danych embeddingów RAG, dostęp z krajów trzecich do danych produkcyjnych, zgodność z tajemnicą zawodową, tokenizacja PII, ścieżki audytu Decision Layer i weryfikowalność środków technicznych.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">W skrócie - Umowa powierzenia dla infrastruktury AI</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Standardowe umowy SaaS nie obejmują logowania promptów, łańcuchów dostawców modeli, separacji środowisk ani tokenizacji PII wymaganych przez infrastrukturę AI.</li>
<li>Dziesięć konkretnych luk istnieje między standardowymi umowami a rzeczywistością AI - od nowych kategorii danych po ścieżki audytu Decision Layer.</li>
<li>BSI (2024) odnotowuje, że 68% organizacji korzystających z generatywnej AI nie zaktualizowało swoich umów powierzenia pod kątem specyficznych przepływów danych AI.</li>
<li>Lista kontrolna 25 pytań pomaga odpowiedzialnym za HR i compliance zweryfikować gotowość dostawcy AI w siedmiu kategoriach.</li>
<li>To nie jest porada prawna - to kompas architektoniczny, który ujawnia luki infrastrukturalne kryjące się za lukami umownymi.</li>
</ul>
</div>

## Dlaczego standardowe umowy powierzenia nie wystarczą dla infrastruktury AI

Standardowa umowa powierzenia przetwarzania danych osobowych reguluje sposób, w jaki podmiot przetwarzający obsługuje dane osobowe w imieniu administratora. Definiuje cel, kategorie danych, środki techniczne i organizacyjne, podwykonawców przetwarzania oraz okresy przechowywania. Dla systemu CRM czy oprogramowania HR to wystarczy.

Infrastruktura enterprise AI tworzy konstelacje, których żadna standardowa umowa nie przewiduje. Model językowy przetwarza prompty  - wprowadzenia tekstowe, które mogą zawierać wszystko: dane kadrowe, informacje klientów, tajemnice przedsiębiorstwa, a nawet szczególne kategorie danych z art. 9 RODO, gdy pracownik zada pytanie dotyczące zdrowia. Dane przepływają przez łańcuch systemów: od interfejsu przez warstwę orkiestracji do dostawcy modelu, z powrotem do bazy danych, potencjalnie przez pipeline RAG z wektorami embedding. Na każdym etapie pojawiają się inne pytania o przechowywanie, dostęp i usuwanie.

Gdy pytasz swojego dostawcę AI o umowę powierzenia i otrzymujesz standardowy dokument, powinno to wzbudzić czujność. Nie dlatego, że dostawca jest niewiarygodny, lecz dlatego, że specyficzne ryzyka infrastruktury AI wymagają innych regulacji niż klasyczna aplikacja SaaS.

## Dziesięć luk między standardową umową a rzeczywistością AI

### 1. Treść promptów jako nowa kategoria danych

Standardowe umowy wymieniają kategorie danych: imię, email, numer pracownika. Przy agentach AI pojawia się kategoria, której nie da się z góry zdefiniować  - prompt. Prompt może być nieszkodliwym pytaniem o regulamin urlopowy albo kompletnym pismem klienckim z danymi osobowymi. Umowa musi regulować, że odpowiedzialność za klasyfikację treści leży po stronie organizacji, a dostawca AI nie dokonuje wstępnej weryfikacji treści. Jednocześnie dostawca musi wykazać środki techniczne chroniące wszystkie wprowadzone treści  - niezależnie od ich wrażliwości.

### 2. Polityka logowania: Co może znaleźć się w logach?

Przy klasycznym oprogramowaniu logowane jest to, co technicznie konieczne. Przy infrastrukturze AI logowanie ma inny wymiar: Czy treści promptów są logowane? Czy odpowiedzi modelu są zapisywane? Czy przesłane dokumenty trafiają do logów błędów?

Solidna umowa powierzenia dla infrastruktury AI musi jednoznacznie ustalić, że w środowisku produkcyjnym logowanie treści żądań/odpowiedzi jest wyłączone, że rejestrowane są wyłącznie metadane techniczne, że logowanie debugowe w produkcji jest dezaktywowane i że ślady stosu nie zawierają treści promptów ani dokumentów.

### 3. Separacja środowisk: Dev, Staging, Prod

Każde wdrożenie enterprise posiada środowiska deweloperskie, testowe i produkcyjne. Przy infrastrukturze AI separacja jest krytyczna dla bezpieczeństwa, ponieważ prawdziwe dane mogą być wykorzystane jako dane testowe. Umowa specyficzna dla AI musi ustalić, że środowiska dev i staging wykorzystują wyłącznie dane syntetyczne lub zanonimizowane, że dostęp produkcyjny jest ograniczony do zdefiniowanych ról w UE/EOG i że przypadki wsparcia są obsługiwane wyłącznie z danymi testowymi zatwierdzonymi przez organizację.

### 4. Łańcuch dostawców modeli zamiast klasycznych podwykonawców

Przy klasycznym oprogramowaniu dostawca ma podwykonawców przetwarzania: dostawcę hostingu, może usługę email. Przy infrastrukturze AI powstaje łańcuch trzywarstwowy: dostawca infrastruktury AI obsługuje platformę, dostawcy modeli (Azure OpenAI, Google Vertex AI, Anthropic) przetwarzają prompty, dostawcy platformy (Supabase, Vercel) hostują bazę danych i frontend.

Kluczowy punkt: Kto jest partnerem umownym dostawców modeli? Czy modele działają w tenancie dostawcy AI czy w tenancie organizacji? Ta różnica decyduje o tym, czy dostawca modelu jest podwykonawcą przetwarzania dostawcy, czy organizacja samodzielnie zarządza relacjami z dostawcami.

| Komponent | W tenancie klienta | W tenancie dostawcy |
|---|---|---|
| Azure Entra ID (SSO) | ✓ Klient | - |
| Azure OpenAI / Vertex AI | ✓ Klient | - |
| Supabase (Baza danych) | ✓ Klient | - |
| Vercel (Hosting) | ✓ Klient | - |
| Plane (System zgłoszeń) | - | ✓ Dostawca |
| GitHub (Hosting kodu) | - | ✓ Dostawca |
| Google Workspace (Komunikacja) | - | ✓ Dostawca |

*Komponenty w tenancie klienta są zarządzane przez klienta w jego własnej ewidencji dostawców. Komponenty w tenancie dostawcy podlegają liście podwykonawców przetwarzania w umowie.*

### 5. In-flight vs. at-rest: Gdzie pozostają dane?

Przy klasycznym oprogramowaniu pytanie jest proste: dane leżą w bazie danych. Przy infrastrukturze AI istnieją dwa tryby przetwarzania. Przetwarzanie in-flight: prompt jest wysyłany do dostawcy modelu, przetwarzany i odpowiedź zwracana  - brak trwałego przechowywania u dostawcy. Przechowywanie at-rest: czaty, przesłane pliki i embeddingi są przechowywane w bazie danych  - trwale i przypisane do użytkownika.

Umowa musi ustanowić odrębne regulacje dla obu trybów.

### 6. RAG i embeddingi: Dane wektorowe jako nowe wyzwanie

RAG (Retrieval Augmented Generation) umożliwia przeszukiwanie dokumentów firmowych przez AI. Dokumenty są konwertowane na wektory embedding i przechowywane w bazie wektorowej. Wektory te stanowią nową kategorię danych: nie zawierają czytelnych tekstów, ale w określonych okolicznościach mogą pozwalać na wnioskowanie o treści oryginalnej. Umowa musi traktować embeddingi jako dane osobowe, gdy są generowane z dokumentów zawierających dane osobowe.

### 7. Dostęp z krajów trzecich do danych produkcyjnych

Wielu dostawców AI pracuje z rozproszonymi zespołami. Gdy deweloper z kraju trzeciego ma dostęp do środowiska produkcyjnego, stanowi to transfer danych w rozumieniu RODO. Umowa musi definiować, że dostęp produkcyjny jest ograniczony do UE/EOG, że dostęp dev/staging z krajów trzecich jest dopuszczalny (ponieważ obecne są tylko dane syntetyczne), że RBAC przewiduje oddzielne grupy adminów dla produkcji i dev/staging i że istnieje procedura wyjątkowa wymagająca pisemnej zgody administratora.

**Uwaga dla rynku polskiego:** UODO (Urząd Ochrony Danych Osobowych) stosuje rygorystyczne podejście do transferów danych do państw trzecich. Organizacje powinny szczególnie zweryfikować, czy standardowe klauzule umowne (SCC) są wystarczające, czy potrzebne są dodatkowe zabezpieczenia.

### 8. Tajemnica zawodowa na platformie AI

Dla regulowanych branż  - kancelarii prawnych, doradców podatkowych, biegłych rewidentów, placówek medycznych  - przetwarzanie na platformie AI wymaga jednoznacznych regulacji umownych. Polskie prawo przewiduje ochronę tajemnicy zawodowej (art. 266 Kodeksu karnego, przepisy branżowe). Dostawca musi zobowiązać wszystkie osoby mające dostęp pisemnie do zachowania poufności. Standardowe klauzule poufności nie wystarczają.

### 9. Tokenizacja PII jako moduł opcjonalny

Filtry wejściowe i wyjściowe wykrywające dane osobowe i pseudonimizujące je przed przekazaniem do dostawcy modelu dodają dodatkową warstwę ochrony. Tokenizacja PII nie jest konieczna w każdym wdrożeniu, ale umowa powinna przewidywać ją jako moduł opcjonalny. Ważne: jeśli możliwa jest odwracalna re-identyfikacja, umowa musi regulować, kto ma dostęp do tabeli mapowania, jak klucze mapowania są przechowywane i szyfrowane oraz że re-identyfikacja następuje wyłącznie celowo po udokumentowanej autoryzacji.

### 10. Ścieżka audytu i Decision Layer

Agenci AI podejmują lub przygotowują decyzje. Każda z tych decyzji musi być możliwa do prześledzenia  - nie tylko ze względu na ochronę danych, ale także dla audytu wewnętrznego, biegłych rewidentów i przedstawicieli pracowników. [Decision Layer](/pl/decision-layer/) rozkłada każdy proces na poszczególne kroki decyzyjne i definiuje dla każdego kroku: człowiek, silnik reguł lub AI. Umowa musi zakotwiczać ścieżkę audytu jako element umowny: Jakie dane są rejestrowane przy każdej decyzji? Jak długo są przechowywane? Kto ma dostęp?

## Lista kontrolna: 25 pytań do dostawcy AI

Poniższa lista kontrolna przekształca dziesięć luk w konkretne pytania weryfikacyjne.

**[Lista kontrolna: 25 pytań weryfikacyjnych dla umów powierzenia AI →](/pl/governance/lista-kontrolna-avv/)**

### A  - Kategorie danych i cele przetwarzania

1. Czy treści promptów i odpowiedzi modeli są wymienione jako odrębne kategorie danych w umowie?
2. Czy ustalono, że odpowiedzialność za klasyfikację treści leży po stronie organizacji, a nie dostawcy?
3. Czy embeddingi/wektory są sklasyfikowane jako potencjalnie dane osobowe?
4. Czy umowa przewiduje regulację dla szczególnych kategorii danych z art. 9 RODO, które mogą powstać przez wprowadzenia użytkowników?

### B  - Logowanie i monitoring

5. Czy logowanie treści żądań/odpowiedzi w środowisku produkcyjnym jest wyłączone?
6. Jakie metadane są rejestrowane (kody statusu, czasy odpowiedzi, identyfikatory żądań)?
7. Czy logowanie debugowe w produkcji jest weryfikowalnie wyłączone?
8. Czy ślady stosu i komunikaty błędów są skonfigurowane tak, aby dane treściowe nie trafiały do logów?
9. Czy weryfikacja ustawień logowania jest częścią procesu wydawniczego?

### C  - Separacja środowisk i dostęp

10. Czy istnieją oddzielne środowiska (dev, staging, prod) z odrębnymi politykami danych?
11. Czy środowiska dev/staging zawierają wyłącznie dane syntetyczne lub zanonimizowane?
12. Czy dostęp produkcyjny jest ograniczony do autoryzowanych ról w UE/EOG?
13. Czy istnieje udokumentowana procedura wyjątkowa dla przypadków wsparcia z dostępem do danych?

### D  - Dostawcy modeli i podwykonawcy

14. Czy rozgraniczenie jest jasne: Którzy dostawcy są podwykonawcami przetwarzania dostawcy, a którzy działają w tenancie organizacji?
15. Czy przechowywanie treści u dostawców modeli jest wyłączone?
16. Czy wykluczenie wykorzystania do celów treningowych jest udokumentowane umownie?
17. Gdzie znajdują się endpointy modeli (region UE, US, inne)?

### E  - Przechowywanie i usuwanie danych

18. Czy ustalono, gdzie przechowywane są trwałe dane treściowe (baza danych, region, dostawca)?
19. Jaka retencja kopii zapasowych obowiązuje i jak traktowane są usunięte dane w kopiach zapasowych?
20. Czy pojedynczy użytkownik może samodzielnie usunąć swoje dane w aplikacji?

### F  - Branże regulowane

21. Czy umowa zawiera regulację zgodności z tajemnicą zawodową (art. 266 KK lub odpowiednik branżowy)?
22. Czy zobowiązania do poufności obejmują wszystkie osoby mające dostęp?
23. Czy tokenizacja PII jest dostępna jako moduł opcjonalny?

### G  - Governance i weryfikowalność

24. Czy ścieżka audytu dla decyzji agentów jest zakotwiczona jako element umowy?
25. Czy środki techniczne i organizacyjne mogą być wykazane na żądanie (dokumentacja konfiguracji, zanonimizowane wyciągi z logów)?

## Od listy kontrolnej do architektury

Te 25 pytań to nie narzędzie prawne. To kompas architektoniczny. Każde pytanie, na które Twój dostawca AI nie potrafi odpowiedzieć, ujawnia lukę w jego infrastrukturze  - nie tylko w jego umowie.

W Gosign wbudowaliśmy te wymagania w architekturę: [separacja środowisk z blokadą produkcji](/pl/magazyn/hosting-ai-strategie-enterprise/), logowanie bez danych treściowych, dostawcy modeli w tenancie klienta, [Decision Layer](/pl/decision-layer/) z pełną ścieżką audytu. Nie dlatego, że klient tego wymagał, ale dlatego, że enterprise AI bez tych podstaw nie jest auditowalny.

Jeśli chcesz ocenić, jak Twoja obecna infrastruktura AI wypada w porównaniu z tymi 25 punktami  - lub oceniasz nową platformę  - chętnie porozmawiamy.

**[Umów rozmowę →](/pl/kontakt/)**

--- Dlaczego Pair Programming to konieczność ---
> 15% więcej nakładu, 60% mniej defektów, 40% szybszy onboarding. Naukowe dowody za Pair Programming - z KPI i źródłami.

Dwóch programistów, jeden ekran, jeden problem. To co brzmi jak marnotrawstwo, jest najlepiej udokumentowaną metodą w inżynierii oprogramowania - a mimo to większość organizacji ją ignoruje. W tym artykule zebraliśmy 25 lat danych badawczych: od pionierskich badań Williams na University of Utah, przez eksperymenty polowe Cockburna, po kontrolowane badania Arisholma w Simula Research. Wniosek jest jednoznaczny. Pair Programming kosztuje 15% więcej czasu - i oszczędza wielokrotność tego dzięki mniejszej liczbie błędów, szybszemu onboardingowi i kodowi, który rozumie więcej niż jedna osoba. Kto po przeczytaniu tego nadal pozwala programistom pracować solo, robi to z przyzwyczajenia, nie z przekonania.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">W skrócie - 25 lat badań nad Pair Programming</p>
<ul class="text-body text-gosign-text space-y-2">
<li>Pary potrzebują tylko 15% więcej czasu - nie podwójnie - produkując jednocześnie 15-60% mniej defektów (Williams & Kessler, 2000; Arisholm i in., 2007).</li>
<li>Złożone zadania kończą się 29% szybciej w parach, a onboarding przyspiesza o 30-50% dzięki transferowi wiedzy.</li>
<li>Obciążenie poznawcze rozkłada się na dwie pamięci robocze, wychwytując 40% więcej przypadków brzegowych i osiągając 99% wykrywalność krytycznych błędów.</li>
<li>W erze AI Pair Programming przeciwdziała izolacji zawodowej - 68% programistów raportuje dni bez jakiejkolwiek interakcji z zespołem (Microsoft, 2024).</li>
<li>Kalkulacja modelowa dla enterprise: projekt z 10 programistami oszczędza netto około 345 000 EUR rocznie dzięki redukcji kosztów defektów i wiedzy.</li>
</ul>
</div>

## Mit samotnego geniusza

Romantyczny obraz utrzymuje się uparcie: genialny programista siedzi sam przed ekranem, intensywnie myśli i produkuje elegancki kod. Linus Torvalds napisał Git w weekend. John Carmack budował silniki Doom w pojedynkę.

Te historie są prawdziwe. Są też nieistotne.

Oprogramowanie enterprise to nie projekt weekendowy. Składa się z setek integracji, wymogów regulacyjnych, przekazań między zespołami i systemów, które rosły przez lata. W tym kontekście praca w pojedynkę nie jest oznaką produktywności. Jest czynnikiem ryzyka.

Badania z ostatnich 25 lat są zadziwiająco jednoznaczne. Liczby:

- **15%** więcej całkowitego czasu rozwoju - nie 100% <sup>[1]</sup>
- **15-60%** mniej defektów w kodzie <sup>[1][4]</sup>
- **29%** szybsze ukończenie złożonych zadań <sup>[2]</sup>
- **30-50%** szybszy onboarding nowych członków zespołu <sup>[1]</sup>
- **95%** uczestników parowania raportuje wyższą satysfakcję <sup>[2]</sup>
- **48%** mniej linii kodu przy tej samej funkcjonalności <sup>[1]</sup>
- **30x** wyższe koszty gdy błędy są wykrywane na produkcji <sup>[6]</sup>

To nie intuicja. To replikowane wyniki badań z kontrolowanych eksperymentów z udziałem setek profesjonalnych programistów.

## Kolekcja KPI: 25 lat badań w liczbach

### Gęstość defektów i jakość kodu

<table>
<thead><tr><th>Badanie</th><th>n</th><th>KPI</th><th>Wynik</th></tr></thead>
<tbody>
<tr><td>Williams & Kessler (2000) <sup>[1]</sup></td><td>41</td><td>Testy zaliczone za pierwszym razem</td><td><strong>+15%</strong> vs. solo</td></tr>
<tr><td>Williams & Kessler (2000) <sup>[1]</sup></td><td>41</td><td>Gęstość defektów</td><td><strong>istotnie niższa</strong></td></tr>
<tr><td>Nosek (1998) <sup>[2]</sup></td><td>15</td><td>Poprawność funkcjonalna</td><td><strong>wyższa</strong> u par</td></tr>
<tr><td>Nosek (1998) <sup>[2]</sup></td><td>15</td><td>Czytelność kodu</td><td><strong>wyższa</strong> u par</td></tr>
<tr><td>Arisholm i in. (2007) <sup>[4]</sup></td><td>295</td><td>Wskaźnik błędów (złożone zadania)</td><td><strong>-60%</strong> vs. solo</td></tr>
<tr><td>Arisholm i in. (2007) <sup>[4]</sup></td><td>295</td><td>Wskaźnik błędów (proste zadania)</td><td><strong>marginalny</strong></td></tr>
<tr><td>Dyba i in. (2007) <sup>[5]</sup></td><td>18 badań</td><td>Ogólna jakość kodu</td><td><strong>statystycznie istotna poprawa</strong></td></tr>
<tr><td>Jensen (2003) <sup>[16]</sup></td><td>120</td><td>Defekty po odbiorze</td><td><strong>-40%</strong></td></tr>
<tr><td>Padberg & Mueller (2003) <sup>[17]</sup></td><td>Symulacja</td><td>Defekty po wydaniu</td><td><strong>-20 do -40%</strong></td></tr>
</tbody>
</table>

### Nakład czasu i produktywność

| Badanie | n | KPI | Wynik |
|---------|---|-----|-------|
| Williams & Kessler (2000) <sup>[1]</sup> | 41 | Całkowity czas rozwoju | **+15%** (nie +100%) |
| Nosek (1998) <sup>[2]</sup> | 15 | Czas realizacji (złożone zadanie) | **-29%** szybciej |
| Arisholm i in. (2007) <sup>[4]</sup> | 295 | Nakład (proste zadania) | **+84%** |
| Arisholm i in. (2007) <sup>[4]</sup> | 295 | Nakład (złożone zadania) | **+18%** |
| Cockburn & Williams (2001) <sup>[3]</sup> | Przegląd | Próg rentowności przy redukcji defektów | **od 3-5%** |
| Lui & Chan (2006) <sup>[18]</sup> | 40 | Przepustowość zadań | **+43%** vs. solo |

### Satysfakcja i dynamika zespołowa

| Badanie | n | KPI | Wynik |
|---------|---|-----|-------|
| Nosek (1998) <sup>[2]</sup> | 15 | Satysfakcja z wyniku | **+95%** u par |
| Williams i in. (2000) <sup>[1]</sup> | 41 | Polecenie kolegom | **96%** parowałoby ponownie |
| Begel & Nagappan (2008) <sup>[19]</sup> | 106 | Satysfakcja z parowania (Microsoft) | **65%** zadowolonych |
| Begel & Nagappan (2008) <sup>[19]</sup> | 106 | Widzą poprawę jakości (Microsoft) | **74%** |

### Efektywność kodu

| Badanie | KPI | Wynik |
|---------|-----|-------|
| Williams & Kessler (2000) <sup>[1]</sup> | Linie kodu (ta sama funkcjonalność) | **-48%** mniej linii |
| Mueller (2004) <sup>[20]</sup> | Złożoność cyklomatyczna | **niższa** u par |

Główny wniosek ze wszystkich badań: Pair Programming kosztuje nieco więcej czasu. Produkuje mniej kodu, który ma mniej błędów, jest łatwiejszy w utrzymaniu i jest rozumiany przez więcej osób.

## "Ale jestem szybszy sam" - co naprawdę przeszkadza programistom

Porozmawiajmy o słoniu w pokoju. Większość programistów odrzucających Pair Programming nie ma liczb przeciwko niemu. Mają uczucie. I to uczucie nie jest irracjonalne - jest po prostu niekompletne.

### "Nie mogę się skoncentrować, gdy ktoś mi się przygląda"

To prawda. Badania nad Social Facilitation <sup>[10]</sup> pokazują jednak: obecność obserwatora zakłóca wykonanie tylko przy **nowych, nieprzećwiczonych zadaniach**. Przy zadaniach, które opanowałeś - czyli przy właściwym programowaniu - obecność **poprawia** wydajność o 15-20%.

To, co odczuwasz jako "zakłócenie", to twój mózg przełączający się z System 1 (autopilot) na System 2 (myślenie analityczne) <sup>[9]</sup>. To jest bardziej męczące. Ale produkuje lepszy kod. Każdy programista zna uczucie napisania "genialnego" rozwiązania o 23:00 w samotności - które rano wygląda żenująco. Partner zapobiega decyzjom z 23:00 w czasie rzeczywistym.

### "Muszę najpierw sam pomyśleć, zanim zacznę kodować"

Zgadza się. I właśnie dlatego Pair Programming nie oznacza, że dwie osoby siedzą obok siebie przez 8 godzin. Najefektywniejsza praktyka według badania Chonga i Hurlbutta (2007) <sup>[21]</sup>: **sesje 2-4 godzinne** z przerwami na samodzielną eksplorację.

Model: samodzielne myślenie, parowanie do budowania, samodzielne myślenie, parowanie do przeglądu. Badania mierzące 15% dodatkowego nakładu przy 60% mniej defektów opierają się na tym rytmie - nie na 8-godzinnym ciągłym parowaniu.

### "Mój partner jest za wolny / za szybki"

Niedopasowanie umiejętności to najczęstszy problem w praktyce <sup>[19]</sup>. Begel i Nagappan (2008) odkryli w swoim badaniu Microsoft: **73% programistów** odrzucających parowanie podawało niedopasowanie umiejętności jako powód. Nie samo parowanie.

Rozwiązaniem nie jest brak parowania. Rozwiązaniem jest lepsze dopasowanie. Ich dane pokazały również: przy dobrze dopasowanych parach satysfakcja wynosiła **90%** - a postrzegana produktywność nawet przewyższała pracę solo <sup>[19]</sup>.

I tutaj punkt, którego nikt nie lubi słyszeć: jeśli zawsze jesteś tym "szybszym", jesteś też monopolistą wiedzy. Jesteś bus factorem 1. Twój zespół jest od ciebie zależny. Parowanie z kimś "wolniejszym" to nie hamulec - to transfer wiedzy. To najtańsze ubezpieczenie, jakie twój zespół może kupić.

### "Tracę swój flow state"

Teoria flow Csikszentmihalyiego <sup>[22]</sup> opisuje stan pełnej absorpcji w zadaniu. Samodzielne programowanie może generować flow. Ale flow ma problem: tłumi krytyczne myślenie. W stanie flow sygnały ostrzegawcze są ignorowane, przypadki brzegowe pomijane, skróty podejmowane, które "wydają się słuszne" <sup>[9]</sup>.

To, co programiści doświadczają jako "flow", to często System 1 na pełnych obrotach - szybki, intuicyjny i ślepy na własne błędy. Pair Programming zastępuje niekontrolowany flow **produktywnym skupieniem**: wysoką koncentracją z jednoczesną kontrolą jakości.

Badania pokazują: pary raportują **równą lub wyższą satysfakcję z pracy** w porównaniu z programistami solo <sup>[2]</sup>. Flow nie jest jedynym przepisem na dobrą pracę. Shared Focus to bardziej zrównoważony wariant.

### "Code review wystarczą"

Fagan (1976) <sup>[14]</sup> pokazał: formalne code review wykrywają **60-70% defektów**. Brzmi dobrze. Pair Programming wykrywa **85-95%** <sup>[1]</sup>. Ale decydującą różnicą nie jest wskaźnik - jest moment wykrycia.

Code review znajduje błędy godziny lub dni po ich napisaniu. Kontekst zniknął. Recenzent musi zrekonstruować proces myślowy - i robi to niepoprawnie w **60% przypadków** (Bacchelli & Bird, 2013) <sup>[23]</sup>. Zatwierdza kod, którego nie w pełni rozumie, ponieważ presja społeczna jest zbyt duża, by kazać koledze czekać godzinami na zatwierdzenie.

Pair Programming nie ma tego problemu. Nawigator był obecny podczas całego procesu myślowego. Brak utraty kontekstu. Brak presji społecznej. I brak kolejki w PR review, która spowalnia cały zespół.

### "To jest społecznie wyczerpujące"

Tak. Dla introwertycznych programistów ciągłe parowanie jest wyczerpujące. To nie argument przeciwko parowaniu - to argument za **dawkowanym parowaniem**. Badania <sup>[21]</sup> zalecają 50-70% czasu parowania, nie 100%. Krytyczne zadania (architektura, integracja, bezpieczeństwo) w parach. Rutynowa praca (konfiguracja, proste błędy) solo.

Kluczowe odkrycie: programiści, którzy "nigdy" nie chcieli parować, zmienili zdanie po **2 tygodniach konsekwentnego parowania** - 96% poleciłoby je dalej <sup>[1]</sup>. Początkowa odmowa to prawie zawsze obrona strefy komfortu, nie stanowisko oparte na dowodach.

## Wyjaśnienie poznawcze: dlaczego dwa mózgi osiągają więcej niż jeden

### Cognitive Load Theory (Sweller, 1988) <sup>[7]</sup>

Każdy człowiek ma ograniczoną pojemność jednoczesnego przetwarzania informacji w pamięci roboczej. Miller (1956) <sup>[8]</sup> określił tę pojemność na **7 plus/minus 2 elementy**. Podczas programowania do **12-15 równoległych wymagań** rywalizuje o tę pojemność: składnia, logika, architektura systemu, przypadki brzegowe, konwencje nazewnictwa, wymagania testowe, kontrakty API, implikacje wydajnościowe.

W Pair Programming obciążenie rozkłada się na dwie pamięci robocze. Driver koncentruje się na poziomie taktycznym: składnia, nazwy zmiennych, bieżąca funkcja. Nawigator obserwuje poziom strategiczny: czy rozwiązanie pasuje do ogólnej architektury? Czy brakuje przypadku brzegowego? Czy istnieje prostsza wersja?

Mierzalne: pary uwzględniają **40% więcej przypadków brzegowych** niż programiści solo przy tym samym zadaniu <sup>[17]</sup>. Nie dlatego, że są mądrzejsi. Ale dlatego, że ich łączna pojemność poznawcza jest wyższa.

### Efekt werbalizacji (Chi i in., 1989) <sup>[11]</sup>

Jednym z najpotężniejszych narzędzi debugowania jest Rubber Duck Debugging: wyjaśnianie problemu na głos, nawet jeśli słucha tylko gumowa kaczka. Chi i in. wykazali Self-Explanation Effect: studenci, którzy wyjaśniali swoje kroki rozwiązywania na głos, osiągnęli w testach rozwiązywania problemów **wyniki 2,5x wyższe** niż cisi rozwiązujący. Wskaźnik błędów spadł o **30%** <sup>[11]</sup>.

Pair Programming instytucjonalizuje ten efekt. Każda decyzja musi zostać wyjaśniona partnerowi. "Używam tutaj HashMap zamiast ArrayList, ponieważ..." - zdanie zmusza do uzasadnienia. A uzasadnienia, które nie przekonują, są kwestionowane. Przed napisaniem kodu, nie tygodnie później w code review.

### Dual Process Theory (Kahneman, 2011) <sup>[9]</sup>

Teoria podwójnego procesu Daniela Kahnemana rozróżnia dwa tryby myślenia: System 1 (szybki, intuicyjny, podatny na błędy) i System 2 (wolny, analityczny, precyzyjny). W programowaniu solo dominuje System 1 - programiści kopiują znane wzorce, pomijają sprawdzenia, bo "to zawsze działało".

Partner aktywuje System 2. Nie przez kontrolę, ale przez samą obecność. Psychologia społeczna nazywa to Social Facilitation <sup>[10]</sup>: obecność kompetentnego obserwatora poprawia wydajność przy dobrze opanowanych zadaniach o **15-20%**.

### Working Memory Complement (Flor & Hutchins, 1991) <sup>[24]</sup>

Dwóch programistów nie dzieli po prostu pracy. Uzupełniają swoje pamięci robocze. Co osoba A przeoczy, zauważa osoba B - nie dlatego, że B jest bardziej uważna, ale dlatego, że uwaga rozprasza się statystycznie.

Matematyczna konsekwencja: jeśli programista solo wykrywa określoną klasę błędów z **90% prawdopodobieństwem**, dwóch niezależnych programistów wykrywa tę samą klasę z **99% prawdopodobieństwem** (1 - 0,1 x 0,1). Przy wskaźniku wykrywalności 80% wskaźnik pary rośnie do **96%**. Sam ten efekt statystyczny wyjaśnia znaczną część obserwowanej redukcji defektów.

## Wymiar psychologiczny: bezpieczeństwo, wiedza, przynależność

### Psychological Safety (Edmondson, 1999) <sup>[12]</sup>

Amy Edmondson ukuła termin Psychological Safety: przekonanie, że w zespole można przyznawać się do błędów, zadawać pytania i podejmować ryzyko bez bycia karanym.

- **Google Project Aristotle (2015)** <sup>[13]</sup>: Psychological Safety była **predyktorem nr 1** wydajności zespołu - ważniejszym niż struktura, jasność, znaczenie czy niezawodność
- **Edmondson (1999)** <sup>[12]</sup>: zespoły z wysokim Psychological Safety **zgłaszały o 70% więcej błędów** i dzięki temu mogły je szybciej naprawiać
- **Rozovsky (2015)** <sup>[13]</sup>: zespoły w górnym kwartylu Psychological Safety miały **17% wyższą produktywność** i **40% niższą rotację**

Pair Programming tworzy naturalny kontekst dla tego zjawiska. "Nie rozumiem, co ta API zwraca" to normalna wypowiedź podczas sesji parowania. W pracy solo ta sama niepewność często pozostaje niewypowiedziana - i staje się błędem.

### Dystrybucja wiedzy i bus factor

Koszt utraty wiedzy w liczbach:

- **Bus factor 1** (tylko jedna osoba zna kod): ryzyko **całkowitej awarii projektu** przy zmianie personelu
- **Utrata wiedzy przez rotację**: przy każdym odejściu tracone jest **42% wiedzy procesowej** - z czego **70% jest milczące**, czyli nieudokumentowane <sup>[15]</sup>
- **Koszt ponownego onboardingu**: **6-12 miesięcy** zanim nowy programista jest produktywny w projekcie enterprise, **3-6 miesięcy** z parowaniem onboardingowym <sup>[1]</sup>
- **Koszty rotacji**: 50-200% rocznego wynagrodzenia na odejście (SHRM, 2019)

Pair Programming jest najbardziej niezawodnym mechanizmem, jaki znamy, do [dystrybucji milczącej wiedzy z indywidualnych głów do zespołu](/pl/magazyn/dlaczego-projekty-ai-w-hr-nie-udaja-sie/).

### Przyspieszenie onboardingu

- **30-50% szybsza produktywność** przy parowaniu onboardingowym vs. samodzielna nauka <sup>[1]</sup>
- **75% par onboardingowych** czuje się "gotowych do samodzielnej pracy" po 2 tygodniach vs. **25% przy onboardingu solo** <sup>[21]</sup>
- **Cognitive Apprenticeship** (Collins, Brown & Newman, 1989) <sup>[25]</sup>: nauka przez obserwację i stopniowe przejmowanie jest **2-3x efektywniejsza** niż nauka instrukcyjna przy złożonych zadaniach

## Business case: pełna kalkulacja

### Błąd 1: Założenie 100%

Pary nie potrzebują dwa razy więcej czasu:

- Proste zadania: **+84% nakładu** <sup>[4]</sup> - tu parowanie rzadko się opłaca
- Średnie zadania: **+15% nakładu** <sup>[1]</sup>
- Złożone zadania: **+18% nakładu** przy jednoczesnych **-60% defektach** <sup>[4]</sup>
- Czas realizacji (złożone zadanie): **-29%** szybciej <sup>[2]</sup>

Pary odrzucają złe podejścia **4x szybciej**, ponieważ nawigator wcześniej rozpoznaje błąd myślowy <sup>[18]</sup>.

### Błąd 2: Koszty defektów są ignorowane

Krzywa eskalacji kosztów według Boehma i Basili (2001) <sup>[6]</sup>:

| Faza | Koszt naprawy (relatywny) | Przykład (przy 500 EUR kosztu bazowego) |
|------|---------------------------|------------------------------------------|
| Kodowanie | 1x | 500 EUR |
| Code review | 2x | 1 000 EUR |
| Integracja/testy | 5x | 2 500 EUR |
| Testy systemowe | 10x | 5 000 EUR |
| Produkcja | 30x | 15 000 EUR |
| Po wydaniu (klient dotknięty) | 100x | 50 000 EUR |

**National Institute of Standards and Technology (NIST)** <sup>[26]</sup> oszacował roczne koszty defektów oprogramowania w USA na **59,5 miliarda USD**. Z tego **22,2 miliarda USD** (37%) można było uniknąć dzięki wcześniejszemu wykrywaniu błędów.

### Błąd 3: Koszty wiedzy są ignorowane

Gdy programista odchodzi i nikt nie zna jego kodu:

- **Inżynieria wsteczna**: 2-6 miesięcy nakładu
- **Podwyższony wskaźnik błędów** w okresie przejściowym: +200-300%
- **Opóźniona dostawa funkcjonalności**: 3-9 miesięcy do stanu normalnego
- **Całkowity koszt rotacji**: 50-200% rocznego wynagrodzenia (SHRM, 2019)

### Pełna kalkulacja (projekt modelowy)

Dla projektu enterprise z 10 programistami, 12 miesięcy trwania:

| Pozycja | Solo | Parowanie | Delta |
|---------|------|-----------|-------|
| Nakład na rozwój | Bazowy | +15% | +105 000 EUR |
| Naprawa defektów (testy) | Bazowy | -40% | -120 000 EUR |
| Naprawa defektów (produkcja) | Bazowy | -50% | -225 000 EUR |
| Transfer wiedzy/onboarding | Bazowy | -40% | -80 000 EUR |
| Nakład na dokumentację | Bazowy | -30% | -25 000 EUR |
| **Oszczędności netto** | | | **-345 000 EUR** |

Liczby różnią się w zależności od projektu. Kierunek nie. W rozwoju enterprise - gdzie błąd produkcyjny w [systemie payroll](/pl/uslugi/hr-agent/payroll-decision-layer/) lub interfejsie do SAP dotyka tysięcy pracowników - rozwój solo jest droższym modelem.

## Real-Time Review vs. Post-Hoc Review

| KPI | Post-hoc code review | Pair Programming | Źródło |
|-----|---------------------|-----------------|--------|
| Wykrywanie defektów | 60-70% | 85-95% | <sup>[14]</sup> <sup>[1]</sup> |
| Czas do wykrycia | Godziny do dni | Sekundy | Strukturalny |
| Utrata kontekstu | Wysoka | Zero | <sup>[23]</sup> |
| Nieporozumienia w review | 60% (recenzent źle rozumie intencję) | 0% | <sup>[23]</sup> |
| Czas oczekiwania na PR | 4-24 godziny (bloker zespołu) | 0 | Strukturalny |
| Transfer wiedzy | Niski (widoczny tylko kod) | Wysoki (widoczny proces decyzyjny) | <sup>[24]</sup> |

Bacchelli i Bird (2013) <sup>[23]</sup> przeanalizowali code review w Microsoft i stwierdzili: w **60% przypadków** recenzent nie rozumiał poprawnie intencji autora. Review, które miały znaleźć błędy, degenerowały się do dyskusji o stylu. Główna przyczyna: brakujący kontekst.

## Czynnik ludzki: dlaczego Pair Programming jest ważniejsze w erze AI, nie mniej

Jest argument za Pair Programming, który nie pojawia się w żadnym badaniu z lat 2000-nych - ponieważ problem wtedy nie istniał.

W 2026 roku programiści spędzają rosnącą część dnia pracy w dialogu z asystentami AI. Kod generowany jest z Copilot, pytania architektoniczne kierowane do Claude, debugowanie przeprowadzane z ChatGPT. Zyski produktywności są realne. Ale pojawia się efekt uboczny, którego nikt nie planował: **izolacja zawodowa**.

Liczby są alarmujące:

- **Gallup State of the Global Workplace (2024)**: tylko **23% pracowników** na świecie czuje się zaangażowanych w pracę. Wśród zdalnych pracowników wiedzy wartość wynosi **18%**
- **Microsoft Work Trend Index (2024)**: **68% programistów** raportuje, że w niektóre dni **nie rozmawia z nikim ze swojego zespołu** o pracy
- **Buffer State of Remote Work (2024)**: **23% pracowników zdalnych** wymienia **samotność** jako największe wyzwanie - przed "rozproszeniem" i "motywacją"
- **Murthy (2023)**: US Surgeon General ogłosił samotność w miejscu pracy **kryzysem zdrowia publicznego** z mierzalnym wpływem na produktywność, kreatywność i wskaźnik błędów

Programista, który 8 godzin dziennie rozmawia z LLM i z nikim ze swojego zespołu, podejmuje decyzje w próżni. LLM nie sprzeciwia się na podstawie doświadczenia. Nie zna dynamiki zespołu. Nie wie, że ostatni programista, który "szybko" zmienił strukturę bazy danych, spowodował trzy tygodnie sprzątania. Nie ma opinii opartej na bliznach.

### Social Cognition vs. Tool Cognition

Neuroscience rozróżnia dwie sieci w mózgu <sup>[27]</sup>: **Task-Positive Network** (aktywowana podczas rozwiązywania problemów, używania narzędzi, skupionej pracy) i **Default Mode Network** (aktywowana podczas poznania społecznego, zmiany perspektywy, empatii). Podczas samodzielnego programowania z asystentami AI aktywna jest prawie wyłącznie Task-Positive Network. Default Mode Network - odpowiedzialna za "Jak kolega by to widział?" - pozostaje cicha.

Pair Programming aktywuje **obie sieci jednocześnie**: rozwiązywanie problemów i poznanie społeczne. Wynikiem są decyzje, które są nie tylko technicznie poprawne, ale uwzględniają kontekst zespołu.

### Zaufanie buduje się przez wspólną pracę, nie przez wiadomości na Slack

Dutton i Heaphy (2003) <sup>[28]</sup> badali "High-Quality Connections" w miejscu pracy: krótkie, intensywne interakcje generujące zaufanie, energię i wzajemny szacunek. Ich badania pokazują:

- **Jeden dzień intensywnej współpracy** generuje więcej zaufania niż **tygodnie komunikacji asynchronicznej**
- Zespoły z regularnymi High-Quality Connections mają **25% niższą rotację** i **30% wyższe zaangażowanie** <sup>[28]</sup>
- Zaufanie budowane przez wspólne rozwiązywanie problemów jest **3x bardziej stabilne** niż zaufanie budowane przez wydarzenia towarzyskie <sup>[12]</sup>

Pair Programming to najgęstsza forma profesjonalnej interakcji, jaka istnieje. Dwóch ludzi wspólnie rozwiązuje problem, dzieli frustrację i sukces, poznaje sposób myślenia drugiego. To nie bonus z zakresu umiejętności miękkich. To spoiwo, które trzyma funkcjonujące zespoły razem.

### Przeciwkalkulacja: co się dzieje, gdy zespoły przestają ze sobą rozmawiać

- **Tworzenie silosów**: bez regularnej wymiany fachowej powstają wyspy wiedzy. Każdy programista buduje własny model mentalny systemu - a te modele z czasem się rozbiegają <sup>[15]</sup>
- **Podwójna praca**: bez widoczności w pracę innych, **15-25% funkcjonalności jest implementowanych redundantnie** (Herbsleb & Grinter, 1999) <sup>[29]</sup>
- **Spadek jakości**: programiści czujący się społecznie odizolowani wykazują **33% więcej defektów** niż zaangażowani członkowie zespołu (Begel & Nagappan, 2008) <sup>[19]</sup>
- **Wypalenie**: izolacja zawodowa jest jednym z najsilniejszych predyktorów wypalenia wśród pracowników wiedzy (Maslach & Leiter, 2016) <sup>[30]</sup>

Ironia: asystenci AI czynią indywidualnych programistów bardziej produktywnymi. Ale czynią zespoły bardziej kruchymi - gdy brakuje parowania jako przeciwwagi. Rozwiązaniem nie jest mniej AI. Rozwiązaniem jest świadoma interakcja międzyludzka jako standardowy proces. Pair Programming to najprostsza i najefektywniejsza droga do tego celu.

## Co to oznacza dla rozwoju enterprise

W [rozwoju oprogramowania enterprise](/pl/uslugi/software-engineering/) wszystkie wymienione efekty się potęgują:

**Złożoność integracji.** Gdy agent musi połączyć się z SAP, Microsoft Graph i systemami lokalnymi, obciążenie poznawcze na zadanie rośnie do **15+ równoległych kontekstów**. Dokładnie sytuacja, w której Pair Programming pokazuje największą przewagę: +18% nakładu przy -60% defektach <sup>[4]</sup>.

**Wymogi regulacyjne.** Kod związany z compliance wymaga poprawności. **99% wskaźnik wykrywalności** (vs. 90% solo) dla krytycznych klas błędów to nie nice-to-have. To wymóg biznesowy.

**Zasada czterech oczu.** W regulowanych branżach compliance wymaga zasady czterech oczu (ISO 27001). Pair Programming spełnia ten wymóg natywnie - **zero dodatkowego nakładu** na przegląd compliance.

**Co-Build jako model.** W Gosign pracujemy w [modelu Co-Build](/pl/uslugi/ai-agents/): zespoły klientów rozwijają z nami, nie obok nas. To Pair Programming na poziomie organizacyjnym - **100% transferu wiedzy** do zespołu klienta, brak vendor lock-in.

## Podsumowanie w liczbach

| KPI | Solo | Pair Programming | Źródło |
|-----|------|-----------------|--------|
| Czas rozwoju | Bazowy | +15% | <sup>[1]</sup> |
| Czas realizacji (złożone) | Bazowy | -29% | <sup>[2]</sup> |
| Gęstość defektów | Bazowy | -15 do -60% | <sup>[1]</sup> <sup>[4]</sup> |
| Linie kodu (ta sama funkcja) | Bazowy | -48% | <sup>[1]</sup> |
| Testy zaliczone za pierwszym razem | Bazowy | +15% | <sup>[1]</sup> |
| Czas onboardingu | 3-6 miesięcy | 1,5-3 miesiące | <sup>[1]</sup> |
| Satysfakcja | Bazowy | +95% | <sup>[2]</sup> |
| Parowałoby ponownie | brak | 96% | <sup>[1]</sup> |
| Bus factor | 1 | Minimum 2 | Strukturalny |
| Defekty po wydaniu | Bazowy | -20 do -40% | <sup>[17]</sup> |
| Wykrywanie defektów (krytyczne) | 90% | 99% | Statystyczny |
| Koszt na defekt (produkcja) | 30x kodowania | Uniknięty | <sup>[6]</sup> |
| Czas oczekiwania na PR review | 4-24h | 0 | Strukturalny |
| Nieporozumienia code review | 60% | 0% | <sup>[23]</sup> |

## Podsumowanie

Pytanie nie brzmi, czy organizacja może sobie pozwolić na Pair Programming. Pytanie brzmi, czy może sobie pozwolić na rezygnację z niego.

**15% więcej czasu rozwoju. 60% mniej defektów. 40% szybszy onboarding. 48% mniej kodu. 99% wykrywalność krytycznych błędów. 345 000 EUR netto oszczędności rocznie w projekcie modelowym.**

A do programistów, którym parowanie przeszkadza: 96% waszych kolegów zmieniło zdanie po dwóch tygodniach konsekwentnego parowania <sup>[1]</sup>. Dowody nie mówią, że parowanie jest wygodne. Mówią, że działa lepiej. Dla kodu, dla zespołu i dla was.

Pair Programming to nie preferencja. To decyzja inżynierska z mierzalnym ROI.

> [Software Engineering w Gosign - Co-Build zamiast Black Box](/pl/uslugi/software-engineering/)

> [Dlaczego projekty AI nie udają się - i jaki ma z tym związek architektura decyzji](/pl/magazyn/dlaczego-projekty-ai-w-hr-nie-udaja-sie/)

> [AI Agents - indywidualne rozwiązania w modelu Co-Build](/pl/uslugi/ai-agents/)

---

## Bibliografia

<small>

**[1]** Williams, L. & Kessler, R. (2000). "All I Really Need to Know About Pair Programming I Learned in Kindergarten." *Communications of the ACM*, 43(5), 108-114. University of Utah.

**[2]** Nosek, J.T. (1998). "The Case for Collaborative Programming." *Communications of the ACM*, 41(3), 105-108.

**[3]** Cockburn, A. & Williams, L. (2001). "The Costs and Benefits of Pair Programming." *Proceedings of the First International Conference on Extreme Programming and Flexible Processes in Software Engineering (XP2000)*, 223-243.

**[4]** Arisholm, E., Gallis, H., Dyba, T. & Sjoberg, D.I.K. (2007). "Evaluating Pair Programming with Respect to System Complexity and Programmer Expertise." *IEEE Transactions on Software Engineering*, 33(2), 65-86.

**[5]** Dyba, T., Arisholm, E., Sjoberg, D.I.K., Hannay, J.E. & Shull, F. (2007). "Are Two Heads Better than One? On the Effectiveness of Pair Programming." *IEEE Software*, 24(6), 12-15.

**[6]** Boehm, B. & Basili, V. (2001). "Software Defect Reduction Top 10 List." *IEEE Computer*, 34(1), 135-137.

**[7]** Sweller, J. (1988). "Cognitive Load During Problem Solving: Effects on Learning." *Cognitive Science*, 12(2), 257-285.

**[8]** Miller, G.A. (1956). "The Magical Number Seven, Plus or Minus Two." *Psychological Review*, 63(2), 81-97.

**[9]** Kahneman, D. (2011). *Thinking, Fast and Slow.* Farrar, Straus and Giroux. New York.

**[10]** Zajonc, R.B. (1965). "Social Facilitation." *Science*, 149(3681), 269-274.

**[11]** Chi, M.T.H., Bassok, M., Lewis, M.W., Reimann, P. & Glaser, R. (1989). "Self-Explanations: How Students Study and Use Examples in Learning to Solve Problems." *Cognitive Science*, 13(2), 145-182.

**[12]** Edmondson, A. (1999). "Psychological Safety and Learning Behavior in Work Teams." *Administrative Science Quarterly*, 44(2), 350-383.

**[13]** Rozovsky, J. (2015). "The Five Keys to a Successful Google Team." *re:Work*, Google.

**[14]** Fagan, M.E. (1976). "Design and Code Inspections to Reduce Errors in Program Development." *IBM Systems Journal*, 15(3), 182-211.

**[15]** DeLong, D.W. (2004). *Lost Knowledge: Confronting the Threat of an Aging Workforce.* Oxford University Press.

**[16]** Jensen, R.W. (2003). "A Pair Programming Experience." *CrossTalk: The Journal of Defense Software Engineering*, 16(3), 22-24.

**[17]** Padberg, F. & Mueller, M. (2003). "Analyzing the Cost and Benefit of Pair Programming." *Proceedings of the 9th International Software Metrics Symposium (METRICS 2003)*, IEEE, 166-177.

**[18]** Lui, K.M. & Chan, K.C.C. (2006). "Pair Programming Productivity: Novice-Novice vs. Expert-Expert." *International Journal of Human-Computer Studies*, 64(9), 915-925.

**[19]** Begel, A. & Nagappan, N. (2008). "Pair Programming: What's in it for Me?" *Proceedings of the Second ACM-IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM)*, 120-128.

**[20]** Mueller, M. (2004). "Are Reviews an Alternative to Pair Programming?" *Empirical Software Engineering*, 9(4), 335-351.

**[21]** Chong, J. & Hurlbutt, T. (2007). "The Social Dynamics of Pair Programming." *Proceedings of the 29th International Conference on Software Engineering (ICSE)*, 354-363.

**[22]** Csikszentmihalyi, M. (1990). *Flow: The Psychology of Optimal Experience.* Harper & Row. New York.

**[23]** Bacchelli, A. & Bird, C. (2013). "Expectations, Outcomes, and Challenges of Modern Code Review." *Proceedings of the 35th International Conference on Software Engineering (ICSE)*, 712-721.

**[24]** Flor, N.V. & Hutchins, E.L. (1991). "Analyzing Distributed Cognition in Software Teams: A Case Study of Team Programming During Perfective Software Maintenance." *Proceedings of the Fourth Annual Workshop on Empirical Studies of Programmers*, 36-64. Ablex Publishing.

**[25]** Collins, A., Brown, J.S. & Newman, S.E. (1989). "Cognitive Apprenticeship: Teaching the Crafts of Reading, Writing, and Mathematics." In L.B. Resnick (Ed.), *Knowing, Learning, and Instruction: Essays in Honor of Robert Glaser*, 453-494. Lawrence Erlbaum Associates.

**[26]** National Institute of Standards and Technology (2002). "The Economic Impacts of Inadequate Infrastructure for Software Testing." *NIST Planning Report 02-3.*

**[27]** Fox, M.D. et al. (2005). "The Human Brain Is Intrinsically Organized into Dynamic, Anticorrelated Functional Networks." *Proceedings of the National Academy of Sciences*, 102(27), 9673-9678.

**[28]** Dutton, J.E. & Heaphy, E.D. (2003). "The Power of High-Quality Connections." In K.S. Cameron, J.E. Dutton & R.E. Quinn (Eds.), *Positive Organizational Scholarship*, 263-278. Berrett-Koehler Publishers.

**[29]** Herbsleb, J.D. & Grinter, R.E. (1999). "Architectures, Coordination, and Distance: Conway's Law and Beyond." *IEEE Software*, 16(5), 63-70.

**[30]** Maslach, C. & Leiter, M.P. (2016). "Understanding the Burnout Experience: Recent Research and Its Implications for Psychiatry." *World Psychiatry*, 15(2), 103-111.

</small>

--- Workflow Audit dla Agent Readiness: Metodyka krok po kroku ---
> Jak rozłożyć proces HR na punkty decyzyjne, sklasyfikować każdy dla człowieka/reguły/AI - i przełożyć wynik na specyfikację Decision Layer spełniającą wymóg zaskarżalności EU AI Act.

## "Które procesy HR nadają się do AI?" to złe pytanie

Szefowa HR siedzi na komitecie sterującym swojego programu AI. Na slajdzie: "Faza 1 - automatyzacja obsługi zwolnień lekarskich". Sześć tygodni później pilotaż jest wstrzymany. Powód: "Nie działa wystarczająco niezawodnie". Co się stało? Projekt potraktował proces jako jedną jednostkę. Ale obsługa zwolnień lekarskich nie jest jednostką. To sekwencja dwunastu punktów decyzyjnych - i dwa z nich powinny były pozostać przy człowieku.

To nie jest anegdota. To wzorzec. Projekty AI w HR rzadko upadają na jakości modelu, a niemal zawsze na granularności pytania. Kto pyta "Które procesy automatyzujemy?", dostaje bezużyteczne odpowiedzi. Kto pyta "W których punktach decyzyjnych w obrębie procesu?", dostaje wykonalną architekturę.

Ta metodyka opisuje, jak zadać właściwe pytanie. Jest niezależna od technologii - bez preferencji modelu, dostawcy, stosu. Z jednego audytu produkuje cztery artefakty: projekt agenta, szablon porozumienia zakładowego, specyfikację Decision Layer i [dokumentację EU AI Act, której obowiązki mają zastosowanie od 2 sierpnia 2026 r.](/pl/magazyn/eu-ai-act-obowiazuje-na-calym-swiecie/) (przesunięcie na grudzień 2027 r. wstępnie uzgodnione - Digital Omnibus, maj 2026).

McKinsey [szacuje](https://www.mckinsey.com/capabilities/people-and-organizational-performance/our-insights/generative-ai-and-the-future-of-hr), że 60 - 70 % administracyjnych czynności HR jest automatyzowalne istniejącą technologią. Adopcja sięga 3 %. Luka nie wynika ze sceptycyzmu. Wynika z braku metody, która rozkłada poziom procesu na poziom punktów decyzyjnych.

<div class="not-prose my-8 border border-gosign-border bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-3">W skrócie</p>
<ul class="text-body text-gosign-text space-y-2">
<li>"Automatyzacja procesu" upada. Klasyfikacja pojedynczych punktów decyzyjnych buduje audytowalną architekturę.</li>
<li>Typowy proces HR ma 10 - 30 punktów decyzyjnych. Doświadczeni pracownicy podejmują większość nieświadomie - dlatego brakuje ich w specyfikacji.</li>
<li>Każdy punkt decyzyjny to człowiek, reguła lub AI - z trzema jasnymi testami, nie z przeczuciem. Wieloznaczność to najczęstsza pułapka audytu.</li>
<li>Wynik audytu to jednocześnie projekt agenta, szablon porozumienia zakładowego, specyfikacja Decision Layer i dokumentacja EU AI Act. Czterech interesariuszy, jeden dokument.</li>
<li>Zaskarżalność to architektura, nie załącznik compliance. Kto dołącza ją później, nie ma audytowalnej AI - niezależnie od jakości modelu.</li>
</ul>
</div>

## Typowy proces HR ma dwanaście punktów decyzyjnych, nie jeden

Mapowanie poprzedza klasyfikację. Upada na osobliwości doświadczonych pracowników: podejmują wiele decyzji nieświadomie. "Sprawdzić, czy zwolnienie ma datę początkową" nie postrzegają jako decyzji. Po prostu to robią. Dla agenta każda taka kontrola to jawna decyzja, która musi zostać wyspecyfikowana.

Metoda, która ujawnia te ukryte decyzje, to technika "co może pójść nie tak": dla każdego kroku pytać, co tu może zawieść lub wymagać innej akcji. Każda odpowiedź odsłania punkt decyzyjny.

Przed mapowaniem wyznacz granice procesu. Proces ma wyzwalacz, sekwencję kroków przetwarzania i jeden lub więcej punktów końcowych. Częsty błąd: zbyt szeroka granica. "Onboarding" to nie jeden proces - to zbiór pięciu do ośmiu pod-procesów (umowa, IT-provisioning, dokumentacja compliance, stanowisko pracy, zapis na szkolenia, przydział buddy, monitorowanie okresu próbnego). Audytować każdy pod-proces oddzielnie.

Na przykładzie obsługi zwolnień lekarskich - wyzwalacz: pracownik składa zwolnienie. Punkty końcowe: wpis do SAP, przełożony poinformowany, lista płac dostosowana, akcja powrotu do pracy zaplanowana jeśli próg przekroczony. To, co większość organizacji opisuje jako jeden krok, jest łańcuchem dwunastu:

| # | Punkt decyzyjny | Pytanie które proces odpowiada |
|---|-----------------|-------------------------------|
| 1 | Wpływ dokumentu | Zwolnienie, zaświadczenie lekarskie, rehabilitacja czy coś innego? |
| 2 | Sprawdzenie kompletności | Imię pracownika, okres diagnozy, lekarz, podpis lekarza? |
| 3 | Identyfikacja pracownika | Do którego pracownika należy ten dokument? |
| 4 | Przyporządkowanie spółki | W której spółce jest pracownik? |
| 5 | Wybór układu zbiorowego | Który układ zbiorowy obowiązuje? |
| 6 | Prawo do wynagrodzenia | 6-tygodniowy okres ([§ 3 EFZG, DE](https://www.gesetze-im-internet.de/entgfg/__3.html)) spełniony? Okres karencji? |
| 7 | Ocena czasu trwania | Pojedynczy dzień, krótka czy długa absencja? |
| 8 | Wykrywanie wzorców | Próg [BEM (DE)](https://www.gesetze-im-internet.de/sgb_9_2018/__167.html) przekroczony? |
| 9 | Wpływ na listę płac | Anulowanie nadgodzin, dodatek zmianowy, proporcjonalne premie? |
| 10 | Aktualizacja systemu | Co się zmienia w SAP/SuccessFactors? |
| 11 | Routing powiadomień | Kto jest informowany (przełożony, HRBP, lista płac, Rada Zakładowa)? |
| 12 | Planowanie działań | Data powrotu, zaproszenie BEM, skierowanie do lekarza zakładowego? |

Dwanaście punktów decyzyjnych w procesie, który większość organizacji opisuje jako "pracownik składa zwolnienie, my je przetwarzamy". Różnica między postrzeganą prostotą a faktyczną złożonością jest typowa - i jest powodem, dlaczego "automatyzujemy zwolnienia" jako cel projektu nie produkuje architektury.

## Trzy typy decyzji, trzy testy, jedna klasyfikacja

Każdy punkt decyzyjny należy do dokładnie jednego z trzech typów. Klasyfikacja jest binarna. Wieloznaczność wskazuje na błąd audytu, nie na przypadek specjalny.

**Typ H - człowiek decyduje.** Empatia, indywidualne uznanie, ryzyko prawne przy automatyzacji, mandat współdecyzji Rady Zakładowej lub wrażliwość etyczna. Pytanie testowe: "Czy dwóch różnych doświadczonych ekspertów doszłoby do tej samej decyzji w tym samym przypadku?" Jeśli nie - Typ H. Człowiek pozostaje tam, gdzie wymaga tego prawo. Nie dlatego, że robi to lepiej.

**Typ R - regułowy, deterministyczny.** Reguła istnieje na piśmie (ustawa, układ zbiorowy, porozumienie zakładowe, udokumentowana procedura). Inputy są strukturyzowane. Wynik jest deterministyczny. Wyjątki są same regułowe - albo są oddzielnymi punktami Typu H. Pytanie testowe: "Czy mogę zapisać tę decyzję jako formułę w arkuszu kalkulacyjnym?" Jeśli tak - Typ R.

**Typ A - kwalifikujący się do AI, probabilistyczny w granicach.** Zadaniem jest klasyfikacja, ekstrakcja lub dopasowanie - nie generowanie, ocena czy wartościowanie. Zbiór wyników jest znany i skończony. Wynik jest weryfikowalny. Można ustawić próg pewności; przypadki niepewne eskalują. Pytanie testowe: "Czy interpretuję informacje względem znanych kategorii, czy oceniam unikalną sytuację?" Jeśli kategorie - Typ A.

Tabela zwolnień po klasyfikacji:

| # | Punkt decyzyjny | Typ | Uzasadnienie |
|---|-----------------|-----|---------------|
| 1 | Klasyfikacja dokumentu | A | Niestrukturyzowany input, klasyfikacja w znane kategorie, ocena pewności |
| 2 | Sprawdzenie kompletności | A | Ekstrakcja pól z dokumentu, wymagane pola, weryfikowalna |
| 3 | Identyfikacja pracownika | A | Dopasowanie nazwiska z fuzzy matching, ocena pewności |
| 4 | Przyporządkowanie spółki | R | Numer pracownika → spółka, deterministyczny lookup |
| 5 | Wybór układu zbiorowego | R | Spółka + kategoria → układ, deterministyczny |
| 6 | Prawo do wynagrodzenia | R | Data początkowa + historia + § 3 EFZG, czysty rachunek |
| 7 | Ocena czasu trwania | R | Arytmetyka kalendarzowa |
| 8 | Wykrywanie wzorców | R | Obliczenia progowe (reakcja na próg to oddzielny H) |
| 9 | Wpływ na listę płac | R | Typ absencji + reguły wynagradzania |
| 10 | Aktualizacja systemu | R | Krok wykonawczy z 4 - 9 |
| 11 | Routing powiadomień | R | Reguły routingu ze spółki, typu, progu |
| 12 | Planowanie działań | R | Regułowe (rozmowa sama jest H, oddzielny proces) |

Osiem Typu R, trzy Typu A, żaden Typu H. Akcje następcze wymagające ludzkiej oceny (rozmowa BEM, planowanie powrotu) są oddzielnymi procesami z własną klasyfikacją - leżą poza obsługą zwolnień.

## Score nie mówi "czy", tylko "gdzie zostaje człowiek"

Z klasyfikacji wynika prosty stosunek: (Typ R + Typ A) ÷ suma × 100. Zwolnienia osiągają 91,7 %. To wysoko. Nie znaczy "mniej człowieka". Znaczy, że 91,7 % pojedynczych decyzji może zostać przejęte architektonicznie - podczas gdy nadzór ludzki koncentruje się na tym, czego prawo i empatia faktycznie wymagają.

Progi Score to logika wdrożeniowa, nie skala:

| Score | Co mówi | Co robić |
|-------|---------|----------|
| > 80 % | Wysoka Agent Readiness | Wdrażać teraz. Governance fokusuje się na nielicznych przekazaniach H. |
| 60 - 80 % | Umiarkowana | Etapowo. R i A najpierw, H pozostaje manualne. Znaczący human-in-the-loop. |
| 40 - 60 % | Mieszana | Automatyzować tylko regułowe pod-procesy. Pełny agent jeszcze się nie opłaca. |
| < 40 % | Niska | Niezalecane. Najpierw dokumentacja procesowa i standaryzacja. |

Typowe Score według domeny HR: lista płac i wynagrodzenia 85 - 95 %, czas pracy 80 - 90 %, faktury i wydatki 75 - 85 %, administracja onboardingu 60 - 75 %, benefity 65 - 80 %, screening rekrutacyjny 40 - 55 %, zarządzanie wydajnością 20 - 35 %, relacje pracownicze 15 - 30 %. Rekrutacja i wydajność spadają nie dlatego, że są technicznie niemożliwe, ale dlatego, że są [systemami wysokiego ryzyka według Aneksu III EU AI Act](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689#anx_3) i nadzór ludzki ma większą wagę.

## Jeden wynik audytu, czterech interesariuszy

Per punkt decyzyjny powstaje strukturyzowany rekord: ID i opis, klasyfikacja z uzasadnieniem, źródło reguły (dla R) z wersją i okresem obowiązywania, próg pewności (dla A), ścieżka eskalacji z terminem, specyfikacja audit-trail, ścieżka zaskarżenia. Ten rekord ma czterech odbiorców:

**Zespół inżynieryjny** czyta klasyfikację jako spec architektury. Gdzie R - ruleset engine; gdzie A - wywołanie modelu z confidence-capture; gdzie H - zadanie w kolejce ludzkiej. Rekord bezpośrednio specyfikuje [Decision Layer](/pl/magazyn/decision-layer-wyjasnienie/) - warstwę między agentem a systemem docelowym, która orkiestruje decyzje regułowe i AI, generuje audit-trail i kieruje eskalacje.

**Rada Zakładowa** czyta te same dane jako szablon współdecyzji. Widzi, które decyzje są zautomatyzowane, z jakim uzasadnieniem, z jaką eskalacją. Ramowe porozumienie zakładowe można wyprowadzić bezpośrednio z audytu, często szybciej niż negocjacje porozumień specyficznych dla domeny pojedynczo.

**Audytor** czyta wersje reguł i specyfikacje audit-trail jako dowód integralności. Jaka reguła obowiązywała kiedy, na jakich danych, kto decydował. Odpowiedź jest w rekordzie, nie w oddzielnym dokumencie compliance.

**Organ ochrony danych** czyta te same dane jako dokumentację EU AI Act i RODO. [Art. 11 (dokumentacja techniczna)](https://eur-lex.europa.eu/legal-content/PL/TXT/?uri=CELEX:32024R1689#art_11), [Art. 12 (rejestracja)](https://eur-lex.europa.eu/legal-content/PL/TXT/?uri=CELEX:32024R1689#art_12), [Art. 86 (prawo do wyjaśnienia)](https://eur-lex.europa.eu/legal-content/PL/TXT/?uri=CELEX:32024R1689#art_86) i [Art. 22 RODO](https://eur-lex.europa.eu/legal-content/PL/TXT/?uri=CELEX:32016R0679#art_22) wymagają dokładnie tych informacji.

Cztery funkcje z jednego dokumentu. Audit nie produkuje ich jako produkt uboczny - jest na to skonstruowany.

## Zaskarżalność to architektura, nie załącznik compliance

Zautomatyzowana decyzja wobec człowieka jest dopuszczalna pod EU AI Act i RODO tylko wtedy, gdy osoba dotknięta może ją zaskarżyć. Zaskarżalność nie jest obowiązkiem dołączonym później - jest wymogiem architektonicznym planowanym od pierwszego audytu.

Per punkt decyzyjny audit dostarcza cztery odpowiedzi, które razem umożliwiają zaskarżenie. Która reguła lub model zdecydował w której wersji? Bez wersjonowania późniejsza reprodukcja jest niemożliwa. Jakie dane stanowiły podstawę decyzji - dokładne inputy z momentu decyzji, nie dzisiejsze? Kto zdecydował - człowiek, reguła czy AI - z jaką pewnością? Jak osoba może złożyć sprzeciw - z konkretnym adresem, terminem, instancją?

Konsekwencja architektury: agent sam nie podejmuje "decyzji" w sensie prawnym. Wykonuje operacje, które Decision Layer dopuścił. To nie jest wybredna semantyka. To podstawa, dzięki której decyzje pozostają audytowalne, gdy model AI zostanie wymieniony, dostawca zmieniony lub wykryty zostanie błąd w modelu.

Klasyfikacja wysokiego ryzyka EU AI Act dotyczy bezpośrednio wielu procesów HR: screening rekrutacyjny, zarządzanie wydajnością, decyzje awansowe i przeniesienia, routing zmian gdy wpływa na korzyści personalne (Aneks III nr 4 lit. a i b). [Art. 26 ust. 7](https://eur-lex.europa.eu/legal-content/PL/TXT/?uri=CELEX:32024R1689#art_26) zobowiązuje dodatkowo do informowania przedstawicieli pracowników i pracowników dotkniętych **przed** wdrożeniem - nie później. Audit musi więc dodatkowo per proces odpowiedzieć: czy ten proces podlega Aneksowi III? Tak → dołączają obowiązki z art. 11, art. 14, art. 15 i art. 26, a obowiązek wcześniejszej informacji jest warunkiem uruchomienia.

Dla organizacji spoza UE: wymagania, które EU AI Act wprost wymienia, są już egzekwowalne w niemal każdym systemie prawnym jako wykładnia ogólnych obowiązków staranności - tylko bez jasnej listy obowiązków. [Kto buduje Decision Layer zgodny z EU AI Act](/pl/magazyn/eu-ai-act-obowiazuje-na-calym-swiecie/), spełnia tym samym to, czego brytyjskie, brazylijskie i kalifornijskie organy ochrony danych będą wymagać w razie kontroli.

## Cztery błędy klasyfikacji zniekształcają każdy audit

**Reguła z wyjątkami wymagającymi oceny klasyfikowana jako Typ R.** "Nadgodziny po 150 %" brzmi regułowo. Ale: święto po 200 %? Zmiana przez północ w święto? Indywidualna umowa nadrzędna nad układem? Gdy wyjątki wymagają oceny, ścieżka wyjątków jest Typu H - nawet gdy przypadek standardowy jest Typu R. Czyste rozwiązanie: standardowy jako R, oddzielny punkt dla obsługi wyjątków jako H lub A.

**Niewerifikowalny wynik AI klasyfikowany jako Typ A.** "AI ocenia, czy kandydat pasuje kulturowo." To nie jest Typ A - nie ma weryfikowalnej poprawnej odpowiedzi. Dopasowanie kulturowe jest subiektywne. Typ A wymaga weryfikowalności: "AI sklasyfikowało ten dokument jako zwolnienie" można zwerifikować przez dwóch ludzi na tym samym dokumencie. Subiektywne oceny są Typu H - zawsze.

**Decyzja wyzwalająca mylona z działaniem następczym.** "Wykrywanie wzorców wyzwala BEM" - wykrywanie jest Typu R (próg), ale BEM zawiera decyzje Typu H (planowanie powrotu). Audit musi oddzielić wyzwalacz od wyzwolonego procesu.

**Ukryte decyzje ignorowane.** "Sprawdzamy zwolnienie" brzmi jak jeden krok. Zawiera co najmniej trzy decyzje: ważny dokument, kompletny, pasuje do pracownika. Audit musi dekomponować, aż każdy punkt ma dokładnie jedno pytanie i jedną klasyfikację.

## Czego ta metodyka nie rozwiązuje

Audit dostarcza Agent Readiness na poziomie punktów decyzyjnych i specyfikację Decision Layer. Nie dostarcza: sekwencjonowania między procesami (zależy od wolumenu transakcji, złożoności governance, gotowości organizacyjnej; patrz [logika H1-H4 w katalogu agentów HR](/pl/katalog-agentow-hr/#sequencing-matrix)), wyboru technologii, zmiany organizacyjnej ani strategii negocjacji z Radą Zakładową. Konkretna implementacja Decision Layer - rules engine, confidence capture, endpoint zaskarżenia - to oddzielny temat.

Audit dostarcza podstawę faktyczną. Strategia i implementacja na niej budują. Kto zaczyna od strategii i podstawę faktyczną ogląda później, buduje piramidę na czubku.

## Dalsze artykuły

- [EU AI Act obowiązuje na całym świecie](/pl/magazyn/eu-ai-act-obowiazuje-na-calym-swiecie/) - dlaczego obowiązek zaskarżalności nie powstaje dopiero z terminem sierpnia 2026
- [Trzy rodzaje decyzji: Kiedy człowiek, kiedy AI](/pl/magazyn/trzy-rodzaje-decyzji/) - koncepcyjna podstawa klasyfikacji H/R/A
- [Decision Layer jako wzorzec architektoniczny](/pl/magazyn/decision-layer-wyjasnienie/) - jak klasyfikacja zostaje przeniesiona w wykonalną warstwę
- [EU AI Act i HR: klasyfikacja wysokiego ryzyka](/pl/magazyn/eu-ai-act-hr-wysokie-ryzyko/) - które procesy HR podlegają Aneksowi III

--- Metodologia Decision Layer ---
> Jak Gosign klasyfikuje decyzje agentów, oblicza oszczędności i weryfikuje źródła - przejrzyście i weryfikowalnie.

## Czym jest Decision Layer?

[Decision Layer](/pl/decision-layer/) to warstwa governance między agentem AI a systemem docelowym. Każda decyzja, którą agent podejmuje lub przygotowuje, jest dokumentowana jako akt decyzyjny: która reguła w jakiej wersji została zastosowana, jakie dane stanowiły podstawę, kto (człowiek, silnik reguł czy AI) podjął decyzję - i jak osoba, której decyzja dotyczy, może złożyć sprzeciw. Ten akt decyzyjny na każdą mikrodecyzję jest architektoniczną odpowiedzią na prawo do wyjaśnienia pojedynczej decyzji wg art. 86 EU AI Act.

Ta strona wyjaśnia metodykę stojącą za liczbami widocznymi na każdej stronie szczegółowej agenta.

## Klasyfikacja decydentów: R / A / H

Każdy krok decyzyjny jest przypisany do dokładnie jednego z trzech typów decydentów:

```
R  Silnik reguł   Deterministyczny. Wejście, wyjście.
                   Brak modelu, brak swobody, brak uznaniowości.
                   Przykład: macierz uprawnień, kontrola terminów.

A  Agent AI        Oparty na modelu z progiem Confidence.
                   Wynik jest probabilistyczny. Gdy Confidence
                   spada poniżej progu: fallback na R lub H.
                   Przykład: rozpoznawanie Intent, wykrywanie anomalii.

H  Człowiek        Jawnie przypisany. Agent przygotowuje,
                   człowiek decyduje. Udokumentowane w akcie
                   decyzyjnym.
                   Przykład: zatwierdzenie zwolnienia, ocena przypadku losowego.
```

Rozgraniczenie opiera się na dwóch kryteriach:

1. **Determinizm**: Czy wynik jest identyczny przy tym samym wejściu za każdym razem? Tak = R. Nie (z powodu modelu) = A. Nie (z powodu uznaniowości) = H.
2. **Przypisanie odpowiedzialności**: Kto odpowiada za wynik? Silnik reguł (skonfigurowany przez HR/Finance) = R. Model (wytrenowany, ze ścieżką audytu) = A. Osoba fizyczna (z imienia i nazwiska) = H.

### Umiejscowienie w ramach regulacyjnych

Klasyfikacja R/A/H nie istnieje w izolacji. Mapuje się na ustalone taksonomie governance:

| Gosign R/A/H | Taksonomia Human-in-the-Loop | EU AI Act Art. 14 | Analogia poziomów SAE |
|---|---|---|---|
| R (Silnik reguł) | Human-out-of-the-Loop | Brak wymaganego nadzoru ludzkiego | Poziom 4-5 (w pełni zautomatyzowany) |
| A (Agent AI) | Human-on-the-Loop | Nadzór ludzki przy wysokim ryzyku (Art. 14) | Poziom 2-3 (asystowany/warunkowy) |
| H (Człowiek) | Human-in-the-Loop | Człowiek jako decydent | Poziom 0-1 (ręczny/asystowany) |

Analogia poziomów SAE (z sektora motoryzacyjnego, SAE J3016) służy jako intuicyjne odniesienie, nie jako bezpośrednie przeniesienie. W kontekście motoryzacyjnym poziom odnosi się do automatyzacji jazdy; tutaj odnosi się do automatyzacji decyzji w procesach HR i finansowych.

## Jak liczymy kroki decyzyjne

Krok decyzyjny to punkt w procesie, w którym agent dokonuje wyboru ścieżki. Nie każda operacja na danych jest krokiem - tylko punkty, w których wynik może się różnić w zależności od danych wejściowych.

Kryteria kroku decyzyjnego:
- **Dane wejściowe się różnią**: Nie każdy przypadek podąża tą samą ścieżką
- **Wynik ma konsekwencje**: Rezultat wpływa na dalszy proces lub system docelowy
- **Decydent jest przypisywalny**: Jasne jest, czy decyduje R, A czy H

Przykład: Agent Employee Self-Service ma 6 zidentyfikowanych kroków decyzyjnych - od rozpoznawania Intent (A) przez kontrolę uprawnień (R) po eskalację do komórki specjalistycznej (R). Proste zapytanie do bazy danych ("pobierz pozostały urlop") nie jest krokiem decyzyjnym.

## Obliczanie wyników

Każdy agent jest oceniany w pięciu wymiarach:

| Wynik | Co mierzy | Skala |
|---|---|---|
| **Readiness** | Jak gotowa jest typowa organizacja na tego agenta? | 0-100 |
| **Governance** | Jak duże jest obciążenie regulacyjne (EU AI Act, Rada Zakładowa (tylko konsultacja, bez weta), RODO)? | 0-100 (wyżej = bardziej wymagający) |
| **Economic** | Jak silna jest dźwignia ekonomiczna (ROI, oszczędność FTE)? | 0-100 |
| **Lighthouse** | Jak silny jest efekt sygnałowy wewnętrznie i na zewnątrz? | 0-100 |
| **Complexity** | Jak złożona jest implementacja techniczna? | 0-100 (wyżej = bardziej złożony) |

Każdy wynik jest podany jako zakres [n, n+7] - rozpiętość odzwierciedla wariancję między branżami i wielkościami organizacji. Dolna wartość to scenariusz konserwatywny (średnie przedsiębiorstwo bez prac przygotowawczych), górna to scenariusz optymistyczny (enterprise z istniejącą infrastrukturą).

Wyniki bazują na kombinacji:
- **Porównanie branżowe**: Jak porównywalne są procesy między organizacjami? (wyższa standaryzacja = wyższy wynik Readiness)
- **Analiza regulacyjna**: EU AI Act Annex III, RODO Art. 22, uprawnienia konsultacyjne Rady Zakładowej (wynik Governance)
- **Dane benchmarkowe**: Zewnętrzne badania nad potencjałem automatyzacji (wynik Economic)
- **Doświadczenie projektowe**: Gosign Decision Layer Assessments z udokumentowanych projektów klienckich

## Zakresy oszczędności w oświadczeniu o wpływie

Każdy agent ma oświadczenie o wpływie (pyramidOpener.impact), które zawiera ilościowe twierdzenie o korzyściach. Twierdzenia te dzielą się na trzy kategorie źródeł:

### CAT-EXT - Zewnętrzne źródło pierwotne

Liczba pochodzi ze zweryfikowanego badania branżowego lub raportu benchmarkowego. Wydawca, tytuł, rok i URL są udokumentowane w CITATION-CATALOG. Liczba została sprawdzona z pierwotnym źródłem (weryfikacja WebFetch adresu URL plus porównanie treści).

Przykład: *"Według Ardent Partners State of ePayables 2024 koszt na fakturę spada z 12,88 do 2,78 USD"* - Ardent Partners to wydawca, liczby znajdują się w raporcie.

### CAT-LEGAL - Ustawodawstwo lub oficjalne statystyki

Liczba pochodzi z ustawodawstwa, oficjalnych statystyk lub orzeczenia sądowego. URL prowadzi do oficjalnego źródła (np. eur-lex.europa.eu, krajowe bazy prawne).

Przykład: *"EU AI Act Annex III system wysokiego ryzyka od sierpnia 2026"* - Rozporządzenie (UE) 2024/1689.

### CAT-INT - Gosign Decision Layer Assessment

Liczba bazuje na udokumentowanych projektach klienckich. Typowe wskaźniki: czasy realizacji (przed/po), wskaźniki automatycznego dopasowania, redukcja błędów. Są to wartości mediany z co najmniej 3 porównywalnych projektów w okresie 2024-2026.

Gdy wartość wpływu jest klasyfikowana jako CAT-INT, oznacza to: liczba pochodzi z doświadczenia Gosign, a nie z zewnętrznego benchmarku. Jest wiarygodna w kontekście naszych danych projektowych, ale nie została niezależnie zweryfikowana zewnętrznie.

## Weryfikacja źródeł

Każde zewnętrzne źródło w CITATION-CATALOG zostało zweryfikowane w następującym procesie:

1. **Kontrola URL**: Adres URL źródła odpowiada kodem HTTP 200 (lub przekierowaniem na stronę docelową)
2. **Porównanie liczb**: Liczba cytowana w oświadczeniu o wpływie rzeczywiście znajduje się w źródle (nie tylko "w przybliżeniu" lub "w duchu")
3. **Kontrola kontekstu**: Liczba jest używana w tym samym kontekście co w źródle (np. "Value Erosion" nie jest przeinterpretowana jako "koszty zarządzania")

Jeśli liczba nie przejdzie tego potrójnego testu, jest albo:
- Skorygowana do prawidłowej wartości ze źródła
- Przeklasyfikowana na CAT-INT (jeśli źródło nie potwierdza liczby)
- Usunięta z oświadczenia o wpływie (jeśli nie jest możliwa do zweryfikowania ani zewnętrznie, ani wewnętrznie)

## Dane ustrukturyzowane dla LLM-ów

Każda strona szczegółowa agenta zawiera schemat JSON-LD (Schema.org SoftwareApplication) z:

- **Rozkład R/A/H** jako `additionalProperty` (rulesEngineShare, aiAgentShare, humanDecisionShare w procentach)
- **Liczba kroków decyzyjnych** (totalDecisionSteps)
- **Flaga wysokiego ryzyka EU AI Act** (euAiActHighRisk: true/false)
- **Oświadczenie o wpływie** jako właściwość tekstowa
- **citation[]** z rozwiązanymi adresami URL źródeł z CITATION-CATALOG

LLM-y mogą te dane bezpośrednio wyodrębniać z kodu źródłowego HTML i cytować je z kanonicznym adresem URL strony agenta.

## Wersjonowanie

| Data | Zmiana |
|---|---|
| 2026-04-16 | Pierwsza publikacja: klasyfikacja R/A/H, metodyka wyników, weryfikacja źródeł, schemat JSON-LD |

--- Darmowe narzędzia AI - interaktywne wsparcie decyzji ---
> 8 darmowych narzędzi AI w przeglądarce: Board Deck Generator, EU AI Act Risk Classifier, kalkulator ROI, planer TCO i więcej. Bez logowania.

<section class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-12">

<p class="text-body text-gosign-text mb-10">Wszystkie narzędzia działają bezpośrednio w przeglądarce. Bez rejestracji, bez udostępniania danych, bez ukrytych kosztów. Wyniki oparte na publicznych frameworkach i benchmarkach.</p>

<div class="grid grid-cols-1 md:grid-cols-2 gap-6">

<div class="bg-gosign-dark rounded-card p-6 flex flex-col">
<span class="inline-block text-small font-medium text-gosign-accent-on-dark bg-white/10 rounded-full px-3 py-1 mb-4 w-fit">Darmowe, w przeglądarce, bez logowania</span>
<h2 class="text-h3 font-bold text-white mb-2">Board Deck Generator</h2>
<p class="text-body text-white/70 mb-4 flex-1">9-slajdowa wstępna ocena z analizą ROI, oceną ryzyka i porównaniem 3 scenariuszy. 7 pól, gotowa prezentacja zarządowa jako wynik.</p>
<a href="/pl/katalog-agentow-hr/" class="inline-flex items-center gap-2 text-gosign-accent-on-dark hover:text-white font-medium">Przejdź do katalogu HR &rarr;</a>
</div>

<div class="bg-gosign-dark rounded-card p-6 flex flex-col">
<span class="inline-block text-small font-medium text-gosign-accent-on-dark bg-white/10 rounded-full px-3 py-1 mb-4 w-fit">Darmowe, w przeglądarce, bez logowania</span>
<h2 class="text-h3 font-bold text-white mb-2">EU AI Act Risk Classifier</h2>
<p class="text-body text-white/70 mb-4 flex-1">Klasyfikacja ryzyka zgodnie z rozporządzeniem (UE) 2024/1689. 7 pytań, jasne przypisanie do kategorii Minimal, Limited, High lub Unacceptable Risk.</p>
<a href="/pl/governance/eu-ai-act/" class="inline-flex items-center gap-2 text-gosign-accent-on-dark hover:text-white font-medium">Przejdź do Risk Classifier &rarr;</a>
</div>

<div class="bg-gosign-dark rounded-card p-6 flex flex-col">
<span class="inline-block text-small font-medium text-gosign-accent-on-dark bg-white/10 rounded-full px-3 py-1 mb-4 w-fit">Darmowe, w przeglądarce, bez logowania</span>
<h2 class="text-h3 font-bold text-white mb-2">Kontrola współdecydowania</h2>
<p class="text-body text-white/70 mb-4 flex-1">Czy rada zakładowa musi wyrazić zgodę? 5 pytań na podstawie obowiązujących przepisów o współdecydowaniu z jasną rekomendacją.</p>
<a href="/pl/governance/co-determination/" class="inline-flex items-center gap-2 text-gosign-accent-on-dark hover:text-white font-medium">Przejdź do kontroli współdecydowania &rarr;</a>
</div>

<div class="bg-gosign-dark rounded-card p-6 flex flex-col">
<span class="inline-block text-small font-medium text-gosign-accent-on-dark bg-white/10 rounded-full px-3 py-1 mb-4 w-fit">Darmowe, w przeglądarce, bez logowania</span>
<h2 class="text-h3 font-bold text-white mb-2">Narzędzie porównywania agentów</h2>
<p class="text-body text-white/70 mb-4 flex-1">Porównaj 2-3 agentów AI obok siebie. Koszty, poziom automatyzacji, wymagania governance i nakład wdrożenia na pierwszy rzut oka.</p>
<a href="/pl/katalog-agentow-hr/" class="inline-flex items-center gap-2 text-gosign-accent-on-dark hover:text-white font-medium">Przejdź do katalogu HR &rarr;</a>
</div>

<div class="bg-gosign-dark rounded-card p-6 flex flex-col">
<span class="inline-block text-small font-medium text-gosign-accent-on-dark bg-white/10 rounded-full px-3 py-1 mb-4 w-fit">Darmowe, w przeglądarce, bez logowania</span>
<h2 class="text-h3 font-bold text-white mb-2">Workforce Planner</h2>
<p class="text-body text-white/70 mb-4 flex-1">Planowanie zatrudnienia z agentami AI vs. bez nich. Na podstawie benchmarków SHRM i Hackett. Pokazuje oszczędności FTE i wzrost produktywności.</p>
<a href="/pl/katalog-agentow-hr/" class="inline-flex items-center gap-2 text-gosign-accent-on-dark hover:text-white font-medium">Przejdź do katalogu HR &rarr;</a>
</div>

<div class="bg-gosign-dark rounded-card p-6 flex flex-col">
<span class="inline-block text-small font-medium text-gosign-accent-on-dark bg-white/10 rounded-full px-3 py-1 mb-4 w-fit">Darmowe, w przeglądarce, bez logowania</span>
<h2 class="text-h3 font-bold text-white mb-2">Kalkulator TCO</h2>
<p class="text-body text-white/70 mb-4 flex-1">3-letnia projekcja kosztów infrastruktury AI. Build vs. Buy vs. Hybrid. Koszty licencji, wdrożenia, bieżącej eksploatacji.</p>
<a href="/pl/uslugi/infrastruktura/" class="inline-flex items-center gap-2 text-gosign-accent-on-dark hover:text-white font-medium">Przejdź do usługi infrastruktury &rarr;</a>
</div>

<div class="bg-gosign-dark rounded-card p-6 flex flex-col">
<span class="inline-block text-small font-medium text-gosign-accent-on-dark bg-white/10 rounded-full px-3 py-1 mb-4 w-fit">Darmowe, w przeglądarce, bez logowania</span>
<h2 class="text-h3 font-bold text-white mb-2">Kalkulator ROI</h2>
<p class="text-body text-white/70 mb-4 flex-1">Szybka kalkulacja oszczędności dla procesów HR, Finance i Travel. Dane wejściowe: wolumen spraw, czas na sprawę, stawka godzinowa. Wynik: roczny potencjał oszczędności.</p>
<a href="/pl/katalog-agentow-hr/" class="inline-flex items-center gap-2 text-gosign-accent-on-dark hover:text-white font-medium">Przejdź do katalogu HR &rarr;</a>
</div>

<div class="bg-gosign-dark rounded-card p-6 flex flex-col">
<span class="inline-block text-small font-medium text-gosign-accent-on-dark bg-white/10 rounded-full px-3 py-1 mb-4 w-fit">Darmowe, w przeglądarce, bez logowania</span>
<h2 class="text-h3 font-bold text-white mb-2">Readiness Assessment</h2>
<p class="text-body text-white/70 mb-4 flex-1">7-pytaniowy test online z wykresem radarowym. Oceń swoją organizację w wymiarach dojrzałości procesów, danych, governance, IT i zarządzania zmianą.</p>
<a href="/pl/hr-agent-readiness/" class="inline-flex items-center gap-2 text-gosign-accent-on-dark hover:text-white font-medium">Przejdź do Readiness Assessment &rarr;</a>
</div>

</div>
</section>

--- Newsletter potwierdzony - Gosign GmbH ---
> Twoja subskrypcja AI Governance Briefing została potwierdzona.

<h1>Subskrypcja potwierdzona</h1>

<p class="text-lg text-gosign-text-light">
Dziękujemy - Twoja subskrypcja <strong>AI Governance Briefing</strong> jest teraz aktywna.
</p>

<p>Briefing otrzymasz raz w miesiącu z najnowszymi informacjami o AI Governance, Decision Layer i infrastrukturze Enterprise AI.</p>

<p class="mt-6">
<a href="/pl/magazyn/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Przejdź do magazynu</a>
<span class="mx-2 text-gosign-text-light">|</span>
<a href="/pl/kontakt/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-medium" target="_blank" rel="noopener noreferrer">Umów rozmowę</a>
</p>

--- Link wygasł - Gosign GmbH ---
> Twój link potwierdzający dla AI Governance Briefing wygasł.

<h1>Link potwierdzający wygasł</h1>

<p class="text-lg text-gosign-text-light">
Twój link potwierdzający dla <strong>AI Governance Briefing</strong> wygasł. Ze względów bezpieczeństwa linki są ważne przez 7 dni.
</p>

<p>Nie ma problemu - po prostu zapisz się ponownie poniżej. Natychmiast otrzymasz nowy e-mail z potwierdzeniem.</p>

--- Wypisano z newslettera - Gosign GmbH ---
> Zostałeś wypisany z AI Governance Briefing.

<h1>Wypisano z newslettera</h1>

<p class="text-lg text-gosign-text-light">
Zostałeś pomyślnie wypisany z <strong>AI Governance Briefing</strong> i nie będziesz otrzymywać dalszych wiadomości.
</p>

<p>Jeśli chcesz ponownie się zapisać, możesz to zrobić w każdej chwili na naszej stronie.</p>

<p class="mt-6">
<a href="/pl/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Strona główna</a>
</p>

--- Nota prawna - Gosign GmbH ---
> Nota prawna Gosign GmbH, Hamburg. Zarząd, kontakt, wpis do rejestru handlowego i informacje prawne.

<h1>Nota prawna</h1>

<h2>Informacje zgodnie z § 5 DDG (niemiecka ustawa o usługach cyfrowych)</h2>
<p>
Gosign GmbH<br/>
Hallerstraße 8<br/>
20146 Hamburg, Niemcy
</p>

<h2>Reprezentowana przez</h2>

<div class="grid grid-cols-1 sm:grid-cols-2 gap-8 not-prose my-8">
<div class="flex items-start gap-4">
<img
src="/images/team/bert-gogolin.webp"
alt="Bert Gogolin, Dyrektor Zarządzający Gosign GmbH"
width="80"
height="80"
class="rounded-full w-20 h-20 object-cover flex-shrink-0"
loading="lazy"
/>
<div>
<p class="font-semibold text-gosign-dark text-body">Bert Gogolin</p>
<p class="text-small text-gosign-text-light">Dyrektor Zarządzający</p>
<a
href="https://www.linkedin.com/in/bertgogolin/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center gap-1 text-small text-gosign-text-light hover:text-gosign-accent transition-colors mt-1"
aria-label="Bert Gogolin na LinkedIn"
>
<svg class="w-4 h-4" fill="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path d="M20.447 20.452h-3.554v-5.569c0-1.328-.027-3.037-1.852-3.037-1.853 0-2.136 1.445-2.136 2.939v5.667H9.351V9h3.414v1.561h.046c.477-.9 1.637-1.85 3.37-1.85 3.601 0 4.267 2.37 4.267 5.455v6.286zM5.337 7.433a2.062 2.062 0 01-2.063-2.065 2.064 2.064 0 112.063 2.065zm1.782 13.019H3.555V9h3.564v11.452zM22.225 0H1.771C.792 0 0 .774 0 1.729v20.542C0 23.227.792 24 1.771 24h20.451C23.2 24 24 23.227 24 22.271V1.729C24 .774 23.2 0 22.222 0h.003z"/>
</svg>
LinkedIn
</a>
</div>
</div>

<div class="flex items-start gap-4">
<img
src="/images/team/dieter-gogolin.webp"
alt="Dieter Gogolin, Dyrektor Zarządzający Gosign GmbH"
width="80"
height="80"
class="rounded-full w-20 h-20 object-cover flex-shrink-0"
loading="lazy"
/>
<div>
<p class="font-semibold text-gosign-dark text-body">Dieter Gogolin</p>
<p class="text-small text-gosign-text-light">Dyrektor Zarządzający</p>
</div>
</div>
</div>

<h2>Kontakt</h2>
<p>
E-mail: web26 [at] gosign.de<br/>
Kontakt: Przez nasz <a href="/pl/kontakt/" class="text-gosign-accent-text hover:text-gosign-accent-hover">formularz kontaktowy</a> lub <a href="/pl/kontakt/#booking" class="text-gosign-accent-text hover:text-gosign-accent-hover">rezerwację terminu</a>
</p>

<h2>Wpis do rejestru handlowego</h2>
<p>
Sąd rejestrowy: Sąd Rejonowy w Hamburgu (Amtsgericht Hamburg)<br/>
Numer rejestrowy: HRB 112197
</p>

<h2>Numer identyfikacji podatkowej</h2>
<p>
Numer identyfikacji podatkowej VAT zgodnie z § 27a niemieckiej ustawy o podatku obrotowym:<br/>
DE215891388
</p>

<h2>Odpowiedzialny za treść zgodnie z § 18 ust. 2 MStV</h2>
<p>
Gosign GmbH<br/>
Bert Gogolin<br/>
Hallerstraße 8<br/>
20146 Hamburg, Niemcy
</p>

<h2>Odpowiedzialność za treści</h2>
<p>
Jako dostawca usług jesteśmy odpowiedzialni za własne treści na tych stronach zgodnie z § 7 ust. 1 DDG i ogólnymi przepisami prawa. Zgodnie z §§ 8 do 10 DDG nie jesteśmy jednak zobowiązani do monitorowania przesyłanych lub przechowywanych informacji osób trzecich ani do badania okoliczności wskazujących na działalność niezgodną z prawem.
</p>
<p>
Zobowiązania do usunięcia lub zablokowania wykorzystania informacji zgodnie z ogólnymi przepisami prawa pozostają nienaruszone. Odpowiedzialność w tym zakresie jest jednak możliwa dopiero od momentu uzyskania wiedzy o konkretnym naruszeniu prawa. Po uzyskaniu informacji o naruszeniach niezwłocznie usuniemy odpowiednie treści.
</p>

<h2>Odpowiedzialność za linki</h2>
<p>
Nasza strona internetowa zawiera linki do zewnętrznych stron internetowych osób trzecich, na których treść nie mamy wpływu. Dlatego nie możemy ponosić odpowiedzialności za te zewnętrzne treści. Za treść linkowanych stron zawsze odpowiada ich dostawca lub operator. Linkowane strony zostały sprawdzone pod kątem ewentualnych naruszeń prawa w momencie linkowania. Treści niezgodne z prawem nie były rozpoznawalne w momencie linkowania.
</p>
<p>
Stała kontrola treści linkowanych stron jest nieuzasadniona bez konkretnych wskazań naruszenia prawa. Po uzyskaniu informacji o naruszeniach prawa niezwłocznie usuniemy takie linki.
</p>

<h2>Prawo autorskie</h2>
<p>
Treści i dzieła stworzone przez operatorów strony na tych stronach podlegają niemieckiemu prawu autorskiemu. Powielanie, edycja, rozpowszechnianie i wszelkiego rodzaju wykorzystanie wykraczające poza granice prawa autorskiego wymagają pisemnej zgody odpowiedniego autora lub twórcy. Pobieranie i kopiowanie tej strony jest dozwolone wyłącznie do użytku prywatnego, niekomercyjnego.
</p>
<p>
W przypadku treści na tej stronie, które nie zostały stworzone przez operatora, prawa autorskie osób trzecich są respektowane. W szczególności treści osób trzecich są odpowiednio oznaczone. Jeśli mimo to zauważysz naruszenie praw autorskich, prosimy o odpowiednią informację. Po uzyskaniu informacji o naruszeniach prawa niezwłocznie usuniemy takie treści.
</p>

<h2>Źródła zdjęć</h2>
<p>
Portrety zarządu: © Gosign GmbH.<br/>
Grafiki i diagramy: Opracowane przez Gosign GmbH, częściowo z wykorzystaniem narzędzi wspieranych przez AI.<br/>
O ile nie zaznaczono inaczej: © Gosign GmbH. Wszelkie prawa zastrzeżone.
</p>

<h2>Rozstrzyganie sporów</h2>
<p>
Komisja Europejska udostępnia platformę do internetowego rozstrzygania sporów (ODR):
<a href="https://ec.europa.eu/consumers/odr/" target="_blank" rel="noopener noreferrer" class="text-gosign-accent-text hover:text-gosign-accent-hover">https://ec.europa.eu/consumers/odr/</a>
</p>
<p>
Nie jesteśmy zobowiązani ani skłonni do udziału w postępowaniach rozstrzygania sporów przed komisją arbitrażową ds. konsumentów.
</p>

<h2>Informacje o znakach towarowych</h2>
<p>
<a href="https://www.sap.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text hover:text-gosign-accent transition-colors">SAP</a>, SAP S/4HANA, SAP SuccessFactors, SAP Business Technology Platform i SAP Joule są zarejestrowanymi znakami towarowymi lub znakami towarowymi SAP SE, Walldorf, Niemcy.
</p>
<p>
<a href="https://www.microsoft.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text hover:text-gosign-accent transition-colors">Microsoft</a>, Microsoft Azure, Microsoft Copilot, Microsoft Teams, SharePoint, Active Directory i Microsoft Graph są zarejestrowanymi znakami towarowymi lub znakami towarowymi Microsoft Corporation, Redmond, USA.
</p>
<p>
<a href="https://www.comarch.pl/" target="_blank" rel="noopener noreferrer" class="text-gosign-text hover:text-gosign-accent transition-colors">Comarch</a> jest zarejestrowanym znakiem towarowym Comarch S.A., Kraków, Polska.
</p>
<p>
<a href="https://www.workday.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text hover:text-gosign-accent transition-colors">Workday</a> jest zarejestrowanym znakiem towarowym Workday, Inc., Pleasanton, USA.
</p>
<p>
<a href="https://www.personio.de/" target="_blank" rel="noopener noreferrer" class="text-gosign-text hover:text-gosign-accent transition-colors">Personio</a> jest znakiem towarowym Personio SE & Co. KG, Monachium, Niemcy.
</p>
<p>
<a href="https://about.google/" target="_blank" rel="noopener noreferrer" class="text-gosign-text hover:text-gosign-accent transition-colors">Google</a> i Google Calendar są znakami towarowymi Google LLC, Mountain View, USA.
</p>
<p>
Wszystkie inne wymienione nazwy produktów i firm są znakami towarowymi lub zarejestrowanymi znakami towarowymi ich odpowiednich właścicieli.
</p>
<p>
Użycie znaków towarowych na tej stronie internetowej służy wyłącznie celom identyfikacji produktów i nie oznacza przynależności, certyfikacji ani poparcia ze strony odpowiednich właścicieli znaków towarowych.
</p>

--- O nas - Enterprise AI Infrastructure od 2001 ---
> Od 2001. Ponad 5 000 projektów dla Airbus, Volkswagen, Shell. Dziś Enterprise AI Infrastructure & Agent Engineering.

<article class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<div class="prose prose-lg prose-headings:text-gosign-dark prose-headings:font-bold prose-h2:text-h2 prose-h2:mt-12 prose-h2:mb-4 prose-h3:text-h3 prose-h3:mt-8 prose-h3:mb-3 prose-p:text-gosign-text prose-p:leading-relaxed prose-a:text-gosign-accent-text prose-a:underline prose-a:decoration-gosign-accent-text/30 hover:prose-a:decoration-gosign-accent-text prose-strong:text-gosign-dark prose-ul:text-gosign-text prose-ol:text-gosign-text">

## Od projektów software'owych do architektury decyzji

Gosign została założona w Hamburgu w 2001 roku. Od ponad 25 lat tworzymy złożone systemy dla średnich i dużych przedsiębiorstw - w ponad 5 000 projektów dla firm takich jak Airbus, Volkswagen, Shell.

Nasze korzenie leżą w klasycznym oprogramowaniu enterprise: integracja systemów, indywidualne platformy, rozwój bliski ERP i architektury bezpieczeństwa. Wraz z pojawieniem się generatywnej AI zaczęliśmy testować workflow oparte na LLM w rzeczywistych środowiskach korporacyjnych - najpierw eksperymentalnie, potem produkcyjnie w konfiguracjach enterprise opartych na Azure.

Dziś budujemy Enterprise AI Agents i infrastrukturę, która czyni je odpowiedzialnymi: [Decision Layer](/pl/decision-layer/), który rozkłada każdy proces na pojedyncze kroki decyzyjne i definiuje dla każdego kroku: człowiek, zestaw reguł lub AI.


## Za czym stoimy

### Jakość decyzji przed automatyzacją

Przedsiębiorstwa rzadko upadają z powodu brakujących narzędzi. Upadają z powodu niespójnej logiki decyzyjnej. Decyzje HR i finansowe w wielu organizacjach nie są wersjonowane, nie są odtwarzalne i zależą od wiedzy pojedynczych osób. Nasza architektura czyni logikę decyzyjną jawną, przejrzystą i audytowalną - jako warstwę techniczną, nie jako doradztwo organizacyjne.

### Governance by Design

Compliance nie jest u nas procesem następczym. Nasi agenci budowani są tak, że logika decyzyjna jest wersjonowana, [Human-in-the-Loop](/pl/governance/) jest architektonicznie zakotwiczony, Audit Trails powstają automatycznie, a kontrole istnieją jako obiekty danych. Gdy wymagana jest certyfikacja, system jest strukturalnie na to przygotowany.

Więcej na naszych [stronach Governance](/pl/governance/).

### Integracja zamiast zastępowania

Nie zastępujemy istniejących systemów. SAP pozostaje ERP. Workday pozostaje platformą HR. SuccessFactors pozostaje wiodący. Uzupełniamy te systemy o warstwę decyzyjną i governance - Decision Layer, który czyni agentów audytowalnymi i sterowalnymi.


## Jak pracujemy

### Co-Build z działami specjalistycznymi

Każde przedsiębiorstwo ma własną logikę wynagrodzeń, własne układy zbiorowe, własne wymogi governance i własne struktury ERP. Dlatego rozwijamy [AI Agents](/pl/uslugi/ai-agents/) w Co-Build z HR, Finance i IT - nie jako gotowy produkt, lecz konfigurowane pod specyficzne procesy i reguły przedsiębiorstwa.

### Pełny dostęp do kodu źródłowego

Nasze rozwiązania działają w [infrastrukturze klienta](/pl/uslugi/infrastruktura/) - w Azure, GCP, AWS lub Self-Hosted. Żaden własnościowy model SaaS, żaden vendor lock-in. Pełny dostęp do kodu źródłowego, konfiguracji i zestawów reguł. Przekazanie do samodzielnej eksploatacji po 12-18 miesiącach jest częścią modelu.

Gosign celowo nie jest modelem zależności.


## Technologie

<div class="not-prose text-body text-gosign-text leading-relaxed">
<a href="https://www.python.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Python</a>, <a href="https://www.typescriptlang.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">TypeScript</a>/<a href="https://nodejs.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Node.js</a>, <a href="https://go.dev/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Go (Golang)</a> - Frontend: <a href="https://react.dev/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">React</a>, <a href="https://nextjs.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Next.js</a>, <a href="https://vuejs.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Vue</a> - Baza danych: <a href="https://www.postgresql.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">PostgreSQL</a>, <a href="https://supabase.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Supabase</a> - Orkiestracja: <a href="https://trigger.dev" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Trigger.dev</a>, <a href="https://camunda.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Camunda</a>, <a href="https://airflow.apache.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Airflow</a> - Kontenery: <a href="https://www.docker.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Docker</a>, <a href="https://kubernetes.io/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Kubernetes</a> - Chmura: <a href="https://azure.microsoft.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Azure</a>, <a href="https://cloud.google.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">GCP</a>, <a href="https://aws.amazon.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">AWS</a> - On-Premise: <a href="https://github.com/vllm-project/vllm" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">vLLM</a>, <a href="https://ollama.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light hover:text-gosign-accent transition-colors">Ollama</a>
</div>


## Certyfikaty i kompetencje

Nasz zespół łączy ponad 25 lat doświadczenia enterprise z aktualnymi certyfikatami cloud i AI. Nasi inżynierowie AI posiadają certyfikaty Microsoft Azure AI i codziennie pracują z API LLM, frameworkami orkiestracji i systemami integracji enterprise.

<a href="https://www.bvdw.org/en/committees/artificial-intelligence/" target="_blank" rel="noopener noreferrer" class="not-prose flex items-center gap-4 group mt-6">
<img src="/images/badges/bvdw-mitglied.png" alt="Członek BVDW" width="349" height="428" class="w-16 h-16 object-contain opacity-60 group-hover:opacity-100 transition-opacity" loading="lazy" />
<span class="text-body text-gosign-text-light group-hover:text-gosign-accent transition-colors">Członek Federalnego Stowarzyszenia Gospodarki Cyfrowej (BVDW)</span>
</a>



## Kim jesteśmy

Gosign jest firmą właścicielską. 108 pracowników w biurach w Hamburgu, Berlinie, Krakowie, Barcelonie, Lizbonie i São Paulo. Nasze największe centrum deweloperskie działa w Pakistanie od 2002 roku - założone jako szkoła programowania, dziś uznany hub inżynierski z bliskimi powiązaniami z wydziałami informatyki na uniwersytetach w Karaczi, Lahore i Islamabadzie.

<div class="flex flex-col md:flex-row gap-12 not-prose my-8">
<div class="flex-1 text-center">
<img src="/images/team/bert-gogolin.webp" alt="Bert Gogolin, Dyrektor Zarządzający Gosign GmbH" width="400" height="400" class="w-48 h-48 lg:w-56 lg:h-56 rounded-full object-cover mx-auto mb-6 border-4 border-gosign-light" />
<h3 class="text-h3 font-bold text-gosign-dark">Bert Gogolin</h3>
<p class="text-body text-gosign-text-light">Dyrektor Zarządzający</p>
<a href="https://www.linkedin.com/in/bert-gogolin/" class="inline-flex items-center gap-1 text-small text-gosign-text-light hover:text-gosign-accent mt-2 transition-colors" target="_blank" rel="noopener noreferrer">
<svg class="w-4 h-4" fill="currentColor" viewBox="0 0 24 24"><path d="M20.447 20.452h-3.554v-5.569c0-1.328-.027-3.037-1.852-3.037-1.853 0-2.136 1.445-2.136 2.939v5.667H9.351V9h3.414v1.561h.046c.477-.9 1.637-1.85 3.37-1.85 3.601 0 4.267 2.37 4.267 5.455v6.286zM5.337 7.433a2.062 2.062 0 01-2.063-2.065 2.064 2.064 0 112.063 2.065zm1.782 13.019H3.555V9h3.564v11.452zM22.225 0H1.771C.792 0 0 .774 0 1.729v20.542C0 23.227.792 24 1.771 24h20.451C23.2 24 24 23.227 24 22.271V1.729C24 .774 23.2 0 22.222 0h.003z"/></svg>
LinkedIn
</a>
</div>
<div class="flex-1 text-center">
<img src="/images/team/dieter-gogolin.webp" alt="Dieter Gogolin, Dyrektor Zarządzający Gosign GmbH" width="400" height="400" class="w-48 h-48 lg:w-56 lg:h-56 rounded-full object-cover mx-auto mb-6 border-4 border-gosign-light" />
<h3 class="text-h3 font-bold text-gosign-dark">Dieter Gogolin</h3>
<p class="text-body text-gosign-text-light">Dyrektor Zarządzający</p>
</div>
</div>

Bert kieruje współpracą z klientami: od pierwszej analizy przez mapowanie procesów po decyzje architektoniczne. Dieter odpowiada za operacyjny i strategiczny rozwój firmy - od infrastruktury przez międzynarodowe zespoły deweloperskie po strategię partnerską.


## Dlaczego to robimy

Generatywna AI zmienia sposób przygotowywania, dokumentowania i rozliczania decyzji. Jesteśmy przekonani, że agenty AI skalują się produktywnie tylko wtedy, gdy governance jest strukturalnie zintegrowany, logika decyzyjna staje się jawna, a ludzie pozostają świadomie zaangażowani.

Do tego budujemy [infrastrukturę](/pl/uslugi/infrastruktura/).

Wszystkie dane firmowe w jednym miejscu: [Fakty i liczby](/pl/fakty/)

</div>
</div>
</article>

--- Polityka Prywatności - Gosign GmbH ---
> Polityka prywatności Gosign GmbH. Strona bez cookies i bez trackerów po stronie klienta; pomiar zasięgu i konwersji po stronie serwera, bez cookies.

<h1>Polityka Prywatności</h1>

<h2>1. Administrator danych</h2>
<p>
Gosign GmbH<br/>
Hallerstraße 8<br/>
20146 Hamburg, Niemcy
</p>
<p>E-mail: web26 [at] gosign.de</p>

<h3>Inspektor ochrony danych</h3>
<p>
Inspektor ochrony danych nie został powołany. Mniej niż 20 pracowników jest stale zaangażowanych w automatyczne przetwarzanie danych osobowych (§&nbsp;38 ust.&nbsp;1 BDSG). W przypadku pytań dotyczących ochrony danych prosimy o kontakt na powyższy adres.
</p>

<h2>2. Przegląd</h2>
<p>
Ta strona internetowa nie ustawia żadnych plików cookie. Ani first-party, ani third-party. Nie są ładowane żadne zewnętrzne trackery działające po stronie klienta - ani Google Analytics, ani Matomo, ani Facebook Pixel, ani LinkedIn Insight Tag, ani Google Tag Manager. Do pomiaru zasięgu i konwersji stosujemy własny, bezcookie'owy system działający po stronie serwera (zob. sekcja&nbsp;4).
</p>
<p>
Baner cookies nie jest wymagany, ponieważ w Państwa urządzeniu końcowym nie są przechowywane ani odczytywane żadne pliki cookie lub porównywalne technologie (§&nbsp;25 TTDSG).
</p>

<h2>3. Hosting i dostarczanie treści</h2>
<p>
Ta strona internetowa jest udostępniana za pośrednictwem Cloudflare Pages. Cloudflare działa jako podmiot przetwarzający zgodnie z art.&nbsp;28 RODO. Zawarto umowę Data Processing Addendum (DPA) ze Standard Contractual Clauses (SCCs).
</p>
<p>
Podczas dostarczania stron internetowych Cloudflare z przyczyn technicznych przetwarza adres IP urządzenia wysyłającego zapytanie. Przetwarzanie to może, w zależności od usługi, odbywać się również poza UE i jest zabezpieczone poprzez EU-US Data Privacy Framework oraz DPA/SCCs.
</p>
<p>
Podstawa prawna: art.&nbsp;6 ust.&nbsp;1 lit.&nbsp;f RODO (uzasadniony interes w bezpiecznym i wydajnym udostępnianiu strony internetowej).
</p>

<h2>4. Pomiar zasięgu i konwersji</h2>
<p>
Do analizy korzystania ze strony oraz skuteczności naszych reklam stosujemy własny, bezcookie'owy system pomiarowy (wewnętrznie „Lyftyfy"), prowadzony przez Gosign GmbH. Nie są ustawiane żadne pliki cookie ani ładowane żadne zewnętrzne trackery po stronie klienta (brak Google Analytics, Google Tag Manager, Facebook Pixel, LinkedIn Insight Tag). Pomiar odbywa się po stronie serwera i bez trwałego rozpoznawania Państwa urządzenia:
</p>
<ul>
<li>W Państwa urządzeniu nie jest przechowywany żaden trwały identyfikator. W celu zgrupowania odsłon z jednego dnia tworzony jest codziennie zmieniający się hash sesji z adresu IP, sygnatury przeglądarki i daty; sam adres IP nie jest przechowywany.</li>
<li>Gromadzone są odsłony stron, głębokość przewijania, czas spędzony na stronie, kliknięcia oraz zdarzenia formularzy i konwersji - w formie zagregowanej i pseudonimowej.</li>
</ul>
<p>
Podstawa prawna: art.&nbsp;6 ust.&nbsp;1 lit.&nbsp;f RODO (uzasadniony interes w analizie korzystania ze strony oraz skuteczności naszych reklam).
</p>

<h3>Pomiar konwersji dla kampanii reklamowych (Google Ads)</h3>
<p>
Jeśli trafią Państwo na naszą stronę przez reklamę Google Ads, wywoływany adres zawiera parametr kliknięcia (gclid). Jeśli następnie wykonają Państwo działanie (np. zapytanie przez formularz), przesyłamy po stronie serwera zdarzenie konwersji do Google, aby zmierzyć skuteczność naszych kampanii. Przesyłane są: parametr kliknięcia, kryptograficznie zahaszowana (nieczytelna) wartość Państwa adresu e-mail lub numeru telefonu oraz wartość konwersji. W Państwa przeglądarce nie jest ustawiany żaden plik cookie ani znacznik reklamowy. Odbiorcą jest Google Ireland Ltd. lub Google LLC (USA); przekazanie jest zabezpieczone umową powierzenia przetwarzania (art.&nbsp;28 RODO), ramami EU-US Data Privacy Framework oraz standardowymi klauzulami umownymi (zob. sekcja „Umowy powierzenia przetwarzania").
</p>
<p>
Podstawa prawna: art.&nbsp;6 ust.&nbsp;1 lit.&nbsp;f RODO (uzasadniony interes w pomiarze i optymalizacji naszych reklam).
</p>
<p>
Mogą Państwo w każdej chwili wnieść sprzeciw wobec tego pomiaru ze skutkiem na przyszłość (art.&nbsp;21 RODO). Wystarczy nieformalna wiadomość na adres podany w punkcie „Administrator danych"; wówczas zaprzestaniemy przetwarzania.
</p>

<h2>5. Formularz kontaktowy i kontakt e-mailowy</h2>
<p>
Jeśli skontaktujesz się z nami za pośrednictwem formularza kontaktowego lub e-maila, Twoje dane (np. imię i nazwisko, adres e-mail, treść wiadomości) zostaną przetworzone w celu obsługi zapytania oraz na wypadek pytań uzupełniających. Przetwarzanie tych danych odbywa się na podstawie art.&nbsp;6 ust.&nbsp;1 lit.&nbsp;b RODO, jeśli Twoje zapytanie jest związane z realizacją umowy lub jest niezbędne do podjęcia działań przedumownych. We wszystkich pozostałych przypadkach przetwarzanie opiera się na naszym uzasadnionym interesie w skutecznej obsłudze kierowanych do nas zapytań (art.&nbsp;6 ust.&nbsp;1 lit.&nbsp;f RODO).
</p>

<h3>Przetwarzanie techniczne przez Cloudflare (bez przechowywania pośredniego)</h3>
<p>
Aby zapewnić bezpieczne i szybkie przesyłanie danych z formularza, wykorzystujemy do routingu technologię "Cloudflare Workers" dostawcy Cloudflare, Inc., 101 Townsend St, San Francisco, CA 94107, USA. Cloudflare działa w tym przypadku wyłącznie jako pośrednik techniczny. Dane wprowadzone w formularzu nie są przez Cloudflare przechowywane w bazie danych, lecz przetwarzane w pamięci operacyjnej i przekazywane w czasie rzeczywistym przez szyfrowane połączenie (TCP Socket) do naszego serwera e-mail. Po przekazaniu danych nie pozostają one na serwerach Cloudflare.
</p>

<h3>Hosting e-mail za pośrednictwem Google Workspace (hosting w UE)</h3>
<p>
Do odbierania, przechowywania i wysyłania naszych e-maili korzystamy z usługi "Google Workspace" dostawcy Google Cloud EMEA Limited, 70 Sir John Rogerson's Quay, Dublin 2, Irlandia. Skonfigurowaliśmy Google Workspace w taki sposób, aby nasze dane e-mailowe były fizycznie przechowywane na serwerach w Unii Europejskiej (UE).
</p>

<h3>Umowy powierzenia przetwarzania danych (AVV) i transfer do państw trzecich</h3>
<p>
Zawarliśmy umowy powierzenia przetwarzania danych (AVV) zgodnie z art.&nbsp;28 RODO zarówno z Cloudflare, jak i z Google. Ponieważ obaj dostawcy należą do amerykańskich koncernów, przy pracach konserwacyjnych, routingu (Cloudflare) lub przypadkach wsparcia nie można w 100&nbsp;% wykluczyć teoretycznego transferu danych do USA. W takich przypadkach dostawcy opierają się na decyzji Komisji Europejskiej o adekwatności (EU-US Data Privacy Framework) oraz na Standardowych Klauzulach Umownych w celu zapewnienia odpowiedniego poziomu ochrony danych.
</p>

<h3>Okres przechowywania</h3>
<p>
Dane wprowadzone przez Ciebie w formularzu kontaktowym pozostają w naszej skrzynce e-mailowej do momentu, gdy poprosisz o ich usunięcie, cofniesz zgodę na przechowywanie lub cel przechowywania danych przestanie obowiązywać (np. po zakończeniu obsługi Twojego zapytania). Bezwzględnie obowiązujące przepisy prawne, w szczególności handlowe i podatkowe okresy przechowywania (do 10 lat zgodnie z §&nbsp;257 HGB i §&nbsp;147 AO), pozostają nienaruszone.
</p>

<h2>6. Newsletter</h2>
<p>
W przypadku zapisania się na nasz newsletter przetwarzamy Twój adres e-mail w celu regularnego wysyłania informacji o naszych usługach, artykułach i wydarzeniach.
</p>
<h3>Procedura Double Opt-In</h3>
<p>
Rejestracja odbywa się za pomocą procedury double opt-in: po wpisaniu adresu e-mail otrzymasz wiadomość potwierdzającą z unikalnym linkiem. Twój adres zostanie dodany do listy mailingowej dopiero po kliknięciu tego linku. Link potwierdzający jest ważny przez 7 dni.
</p>
<h3>Wykorzystywane usługi</h3>
<p>
Newsletter jest wysyłany za pośrednictwem Cloudflare Worker (dostawca: Cloudflare, Inc., 101 Townsend St, San Francisco, CA 94107, USA). Twój adres e-mail jest przechowywany w Cloudflare KV (magazyn klucz-wartość). Zawarliśmy z Cloudflare umowę o przetwarzanie danych (AVV) zgodnie z art.&nbsp;28 RODO. Wysyłka e-maili odbywa się przez SMTP (obecnie za pośrednictwem zewnętrznego serwera pocztowego).
</p>
<h3>Podstawa prawna</h3>
<p>
Art.&nbsp;6 ust.&nbsp;1 lit.&nbsp;a RODO (zgoda). Zgodę możesz cofnąć w każdym momencie, klikając link rezygnacji w każdym e-mailu newsletterowym lub kontaktując się z nami pod adresem datenschutz@gosign.de.
</p>
<h3>Okres przechowywania</h3>
<p>
Twój adres e-mail jest przechowywany do momentu rezygnacji z newslettera. Po rezygnacji adres zostanie niezwłocznie usunięty, chyba że obowiązują ustawowe obowiązki przechowywania.
</p>

<h2>7. 203-Readiness-Check</h2>
<p>
Na naszych stronach w języku niemieckim oferujemy 203-Readiness-Check - dobrowolną samoocenę dotyczącą wykorzystania AI, przeznaczoną dla osób zobowiązanych do zachowania tajemnicy zawodowej zgodnie z §&nbsp;203 niemieckiego kodeksu karnego (StGB). Twoje odpowiedzi w samoocenie nie są ani zapisywane, ani przesyłane - ocena odbywa się w całości w Twojej przeglądarce, a wynik pojawia się bezpośrednio na stronie, bez podawania adresu e-mail.
</p>
<h3>Raport z wynikami e-mailem (opcjonalnie)</h3>
<p>
Tylko jeśli dobrowolnie zamówisz szczegółowy raport z wynikami e-mailem, przetwarzamy Twój adres e-mail, Twoją grupę zawodową oraz rekomendowany dla Ciebie poziom - ale nie Twoje odpowiedzi. Zamówienie jest potwierdzane w procedurze double opt-in, tak jak w przypadku newslettera (sekcja&nbsp;6): otrzymasz wiadomość potwierdzającą z unikalnym linkiem, a raport zostanie wysłany dopiero po kliknięciu tego linku. Wysyłka odbywa się za pośrednictwem naszego dostawcy usług mailingowych Brevo, z którym zawarliśmy umowę powierzenia przetwarzania danych zgodnie z art.&nbsp;28 RODO.
</p>
<h3>Podstawa prawna</h3>
<p>
Art.&nbsp;6 ust.&nbsp;1 lit.&nbsp;a RODO (zgoda). Zgodę możesz cofnąć w każdej chwili ze skutkiem na przyszłość, np. wysyłając e-mail na adres datenschutz@gosign.de.
</p>
<h3>Okres przechowywania</h3>
<p>
Potwierdzone zamówienia raportu są usuwane po 6 miesiącach. Niepotwierdzone zapytania w procedurze double opt-in wygasają automatycznie po 7 dniach.
</p>

<h2>8. Rezerwacja terminów</h2>
<p>
W celu rezerwacji terminów korzystamy z Google Calendar Appointment Scheduling (dostawca: Google Ireland Limited, Gordon House, Barrow Street, Dublin 4, Irlandia). Po kliknięciu linku rezerwacji następuje przekierowanie na calendar.google.com. Na naszej stronie internetowej przez link rezerwacji nie jest ładowany żaden skrypt ani ustawiany żaden plik cookie.
</p>
<p>
Podczas korzystania z usługi rezerwacji Twoje dane (imię i nazwisko, adres e-mail, wybrany termin) są przetwarzane przez Google. Obowiązuje <a href="https://policies.google.com/privacy" target="_blank" rel="noopener noreferrer" class="text-gosign-accent-text hover:text-gosign-accent-hover">Polityka prywatności Google</a>.
</p>
<p>
Podstawa prawna: art.&nbsp;6 ust.&nbsp;1 lit.&nbsp;b RODO (realizacja działań przedumownych na Twoje żądanie). Rezerwacja terminu konsultacji służy nawiązaniu relacji biznesowej.
</p>

<h2>9. Czcionki</h2>
<p>
Wszystkie czcionki używane na tej stronie internetowej są osadzone lokalnie (self-hosted). Nie są ładowane żadne zewnętrzne usługi czcionek (np. Google Fonts). Podczas ładowania czcionek nie dochodzi do nawiązania połączenia z podmiotami trzecimi.
</p>

<h2>10. Mapy i wideo</h2>
<p>
Ta strona internetowa nie osadza zewnętrznych usług mapowych (np. Google Maps) ani zewnętrznych usług wideo (np. YouTube). Tam, gdzie wyświetlane są mapy lub filmy, odbywa się to za pomocą statycznych obrazów lub treści hostowanych na własnym serwerze.
</p>

<h2>11. Brak dodatkowych podmiotów trzecich</h2>
<p>
Ta strona internetowa nie ładuje żadnych zasobów od podmiotów trzecich, które nie zostały wymienione w niniejszej polityce prywatności. W szczególności nie są stosowane:
</p>
<ul>
<li>Google Tag Manager</li>
<li>Facebook Pixel</li>
<li>LinkedIn Insight Tag</li>
<li>HubSpot, Salesforce ani inne trackery CRM</li>
<li>Hotjar, Mouseflow ani inne narzędzia do nagrywania sesji</li>
<li>Matomo ani inne samodzielnie hostowane narzędzia analityczne</li>
</ul>

<h2>12. Szyfrowanie SSL/TLS</h2>
<p>
Ta strona internetowa wykorzystuje z przyczyn bezpieczeństwa szyfrowanie SSL/TLS. Połączenie szyfrowane rozpoznasz po "https://" na pasku adresu przeglądarki.
</p>

<h2>13. Pliki dziennika serwera</h2>
<p>
Dostawca hostingu (Cloudflare) z przyczyn technicznych gromadzi dane dostępowe w plikach dziennika serwera. Mogą one zawierać: odwiedzoną stronę, czas, ilość danych, adres URL referrera, adres IP, przeglądarkę i system operacyjny. Pliki dziennika są przechowywane przez Cloudflare przez maksymalnie 72 godziny i nie są łączone z innymi danymi.
</p>
<p>
Podstawa prawna: art.&nbsp;6 ust.&nbsp;1 lit.&nbsp;f RODO (uzasadniony interes w zapewnieniu technicznego funkcjonowania i wykrywaniu ataków).
</p>

<h2>14. Sztuczna inteligencja i zautomatyzowane podejmowanie decyzji</h2>
<p>
Nie odbywa się zautomatyzowane podejmowanie decyzji, w tym profilowanie, zgodnie z art.&nbsp;22 RODO. Na tej stronie internetowej nie są wykorzystywane żadne systemy AI do automatycznego przetwarzania danych osobowych odwiedzających stronę.
</p>

<h3>Tworzenie treści wspierane przez AI</h3>
<p>
Gosign wykorzystuje narzędzia wspierane przez AI (duże modele językowe, generowanie obrazów) do tworzenia i edycji treści strony internetowej, grafik i diagramów. Narzędzia te nie przetwarzają danych osobowych odwiedzających stronę. Wszystkie wyniki podlegają weryfikacji redakcyjnej i zatwierdzeniu.
</p>

<h3>AI w projektach klientów</h3>
<p>
Gosign rozwija i obsługuje infrastrukturę AI dla klientów korporacyjnych (AI Agents, Document Intelligence, automatyzacja procesów). Przetwarzanie danych osobowych w projektach klientów odbywa się na podstawie odrębnych umów powierzenia przetwarzania danych (AVV) zgodnie z art.&nbsp;28 RODO i nie jest przedmiotem niniejszej polityki prywatności.
</p>

<h2>15. Międzynarodowe standardy ochrony danych</h2>
<p>
Gosign obsługuje klientów na całym świecie i uznaje prawa do ochrony danych wynikające z odpowiednich lokalnych przepisów. RODO pozostaje głównym prawem ochrony danych, ponieważ Gosign GmbH ma siedzibę w Niemczech, a przetwarzanie danych odbywa się w UE. Poniżej znajdują się uzupełniające informacje dla użytkowników z poszczególnych jurysdykcji.
</p>

<h3>Wielka Brytania</h3>
<p>
Dla użytkowników w Wielkiej Brytanii obowiązuje UK GDPR w powiązaniu z Data Protection Act 2018. Prawa odpowiadają w dużej mierze prawom wynikającym z unijnego RODO. Właściwy organ nadzorczy: Information Commissioner's Office (ICO), Wilmslow, Cheshire, UK.
</p>

<h3>Stany Zjednoczone</h3>
<p>
Dla użytkowników zamieszkałych w Kalifornii dodatkowo obowiązują California Consumer Privacy Act (CCPA) oraz California Privacy Rights Act (CPRA). Obejmuje to prawo do informacji o gromadzonych kategoriach danych, prawo do usunięcia oraz prawo do sprzeciwu wobec sprzedaży danych osobowych. Gosign nie sprzedaje danych osobowych i nie udostępnia ich osobom trzecim w celach reklamowych. Dla użytkowników w innych stanach USA posiadających własne przepisy o ochronie danych (Kolorado, Connecticut, Wirginia, Utah, Teksas, Oregon i inne) uznawane są porównywalne prawa.
</p>

<h3>Szwajcaria</h3>
<p>
Dla użytkowników w Szwajcarii obowiązuje znowelizowana federalna ustawa o ochronie danych (revDSG/nDSG), obowiązująca od 1&nbsp;września 2023 r. Przyznaje ona prawa porównywalne z RODO. Właściwy organ nadzorczy: Federalny Komisarz ds. Ochrony Danych i Informacji (ED&Ouml;B), Berno.
</p>

<h3>Kanada</h3>
<p>
Dla użytkowników w Kanadzie obowiązuje Personal Information Protection and Electronic Documents Act (PIPEDA). Gosign uznaje zasady PIPEDA, w szczególności zgody, ograniczenia celu, dostępu i sprostowania. Właściwy organ nadzorczy: Office of the Privacy Commissioner of Canada (OPC), Gatineau, QC.
</p>

<h3>Brazylia</h3>
<p>
Dla użytkowników w Brazylii dodatkowo obowiązuje Lei Geral de Proteção de Dados (LGPD, Lei n.º&nbsp;13.709/2018). LGPD przyznaje brazylijskim użytkownikom kompleksowe prawa, w tym dostęp, sprostowanie, anonimizację, usunięcie, przenoszenie danych i sprzeciw. Prawa te są przez nas w pełni uznawane. Właściwy organ nadzorczy: Autoridade Nacional de Proteção de Dados (ANPD), Brasília, DF.
</p>

<h3>Indie</h3>
<p>
Dla użytkowników w Indiach obowiązuje Digital Personal Data Protection Act (DPDP Act, 2023). Gosign uznaje prawa indyjskich użytkowników, w szczególności prawo dostępu, sprostowania, usunięcia i wniesienia skargi. Właściwy organ nadzorczy: Data Protection Board of India (DPBI), Nowe Delhi.
</p>

<h3>Japonia</h3>
<p>
Dla użytkowników w Japonii obowiązuje Act on the Protection of Personal Information (APPI). Komisja Europejska przyznała Japonii odpowiedni poziom ochrony danych. Gosign uznaje prawa wynikające z APPI, w szczególności prawo dostępu, sprostowania, usunięcia i zaprzestania wykorzystywania. Właściwy organ nadzorczy: Personal Information Protection Commission (PPC), Tokio.
</p>

<h3>Republika Południowej Afryki</h3>
<p>
Dla użytkowników w Republice Południowej Afryki obowiązuje Protection of Personal Information Act (POPIA). Gosign uznaje prawa wynikające z POPIA, w szczególności prawo dostępu, sprostowania, usunięcia i sprzeciwu wobec marketingu bezpośredniego. Właściwy organ nadzorczy: Information Regulator, Johannesburg.
</p>

<h3>Wszystkie pozostałe jurysdykcje</h3>
<p>
Dla użytkowników w krajach posiadających własne przepisy o ochronie danych, które nie zostały tu wyraźnie wymienione, Gosign uznaje odpowiednio obowiązujące lokalne prawa ochrony danych, o ile dotyczą one przetwarzania za pośrednictwem tej strony internetowej. Twoje prawa do dostępu, sprostowania i usunięcia są gwarantowane w każdym przypadku.
</p>

<h2>16. Twoje prawa</h2>
<p>
Przysługują Ci następujące prawa dotyczące Twoich danych osobowych:
</p>
<ul>
<li><strong>Dostęp</strong> (art.&nbsp;15 RODO): Możesz żądać informacji o przetwarzanych przez nas danych.</li>
<li><strong>Sprostowanie</strong> (art.&nbsp;16 RODO): Możesz żądać poprawienia nieprawidłowych danych.</li>
<li><strong>Usunięcie</strong> (art.&nbsp;17 RODO): Możesz żądać usunięcia swoich danych, o ile nie stoją temu na przeszkodzie ustawowe obowiązki przechowywania.</li>
<li><strong>Ograniczenie przetwarzania</strong> (art.&nbsp;18 RODO): Możesz żądać ograniczenia przetwarzania.</li>
<li><strong>Przenoszenie danych</strong> (art.&nbsp;20 RODO): Możesz żądać wydania swoich danych w formacie nadającym się do odczytu maszynowego.</li>
<li><strong>Sprzeciw</strong> (art.&nbsp;21 RODO): Możesz w każdej chwili sprzeciwić się przetwarzaniu na podstawie art.&nbsp;6 ust.&nbsp;1 lit.&nbsp;f RODO.</li>
<li><strong>Cofnięcie zgody</strong> (art.&nbsp;7 ust.&nbsp;3 RODO): Jeśli przetwarzanie opiera się na Twojej zgodzie, możesz ją w każdej chwili cofnąć ze skutkiem na przyszłość. Zgodność z prawem przetwarzania dokonanego do momentu cofnięcia zgody pozostaje nienaruszona.</li>
</ul>
<p>
W celu skorzystania ze swoich praw wystarczy nieformalna wiadomość na powyższy adres.
</p>

<h2>17. Prawo do skargi</h2>
<p>
Masz prawo złożyć skargę do organu nadzorczego ochrony danych. Właściwy jest organ nadzorczy kraju związkowego, w którym mieszkasz, lub organ właściwy dla administratora:
</p>
<p>
Hamburski Pełnomocnik ds. Ochrony Danych i Wolności Informacji<br/>
Ludwig-Erhard-Str. 22<br/>
20459 Hamburg, Niemcy
</p>

<h2>18. Aktualność</h2>
<p>
Niniejsza polityka prywatności jest aktualnie obowiązująca. Stan: luty 2026.
</p>
<p>
Zastrzegamy sobie prawo do dostosowania niniejszej polityki prywatności w celu uwzględnienia zmian stanu prawnego lub zmian w usłudze.
</p>

--- Recruiting Agent - Dopasowywanie Wymagań Wspierane przez AI ---
> Recruiting Agent dla spójnego, audytowalnego screeningu kandydatów. Dopasowywanie wymagań bez uprzedzeń z zmęczenia. Decision Layer z Human-in-the-Loop.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/pl/dlaczego-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Każda decyzja możliwa do prześledzenia</p>
</div>
</a>
<a href="/pl/dlaczego-gosign/#infrastruktura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Twoja infrastruktura</p>
<p class="text-xs text-gosign-text-light">Bez SaaS. Bez vendor-lock-in.</p>
</div>
</a>
<a href="/pl/dlaczego-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Bez ryzyka US-cloud</p>
</div>
</a>
</div>
</div>
</div>



<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Problem: Niespójny Screening, Nieudokumentowane Decyzje</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Screening CV w skali korporacyjnej zależy od indywidualnych rekruterów. 50. CV dnia jest oceniane inaczej niż 5. Kryteria różnią się między menedżerami rekrutacji. Odrzucenia są rzadko dokumentowane z identyfikowalnym uzasadnieniem.
</p>
</div>
</section>

<!-- Prozess-Diagramm -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-6">Proces rekrutacji z Decision Layer</h2>
<img src="/images/diagrams/recruiting-decision-flow-pl.svg" alt="Proces rekrutacji w 5 fazach z Decision Layer" class="w-full" width="1200" height="400" loading="lazy" />
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Jak Działa Recruiting Agent</h2>
<pre class="bg-gosign-dark text-white p-6 rounded-card overflow-x-auto text-small font-mono leading-relaxed mt-4"><code>Aplikacja   →  Document Agent     →  Decision Layer
(CV + List      czyta i               dopasowuje do
motywacyjny)   wyodrębnia            profilu wymagań
│
┌────────────┴────────────┐
│                         │
Silne dopasowanie         Częściowe dopasowanie
Wszystkie kryteria        lub luki w kryteriach
│                         │
Shortlista z              Przegląd przez rekrutera
dokumentacją              z kontekstem i lukami
│                         │
Audit Trail               Audit Trail</code></pre>
</div>
</section>

<!-- Micro-Decision Table -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Kto decyduje o czym? Micro-Decisions w rekrutacji</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
<a href="/pl/decision-layer/" class="text-gosign-accent-text hover:underline">Decision Layer</a> rozkłada proces rekrutacyjny na pojedyncze kroki decyzyjne. Dla każdego kroku z góry określono: człowiek, zestaw reguł czy AI.
</p>
</div>
<div class="mt-8 overflow-x-auto">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-dark/20">
<th class="py-3 pr-4 text-body font-bold text-gosign-dark">Krok decyzyjny</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Kto decyduje</th>
<th class="py-3 pl-4 text-body font-bold text-gosign-dark">Dlaczego</th>
</tr>
</thead>
<tbody class="text-body text-gosign-text-light">
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Utworzenie profilu wymagań</td>
<td class="py-3 px-4"><span class="inline-block px-2 py-0.5 text-xs font-bold rounded bg-amber-100 text-amber-800">Człowiek weryfikuje</span></td>
<td class="py-3 pl-4">AI tworzy propozycję na podstawie opisu stanowiska i profilu zespołu. Kierownik weryfikuje i uzupełnia.</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Redakcja ogłoszenia o pracę</td>
<td class="py-3 px-4"><span class="inline-block px-2 py-0.5 text-xs font-bold rounded bg-blue-100 text-blue-800">Automatycznie</span></td>
<td class="py-3 pl-4">Agent generuje tekst na podstawie profilu wymagań. Sprawdzenie pod kątem dyskryminujących sformułowań.</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Parsowanie CV i ekstrakcja danych</td>
<td class="py-3 px-4"><span class="inline-block px-2 py-0.5 text-xs font-bold rounded bg-blue-100 text-blue-800">Automatycznie</span></td>
<td class="py-3 pl-4">Wyodrębnianie ustrukturyzowanych danych z CV. Przypadek standardowy, wysoka pewność.</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Dopasowanie do wymagań (screening)</td>
<td class="py-3 px-4"><span class="inline-block px-2 py-0.5 text-xs font-bold rounded bg-emerald-100 text-emerald-800">Zestaw reguł</span></td>
<td class="py-3 pl-4">Porównanie z określonymi kryteriami obowiązkowymi. Oparte na regułach, nie na ocenie AI.</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Ocena jakościowa (shortlista)</td>
<td class="py-3 px-4"><span class="inline-block px-2 py-0.5 text-xs font-bold rounded bg-amber-100 text-amber-800">Człowiek weryfikuje</span></td>
<td class="py-3 pl-4">Agent tworzy shortlistę z uzasadnieniem. Rekruter weryfikuje i decyduje o zaproszeniach.</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Koordynacja terminów rozmów</td>
<td class="py-3 px-4"><span class="inline-block px-2 py-0.5 text-xs font-bold rounded bg-blue-100 text-blue-800">Automatycznie</span></td>
<td class="py-3 pl-4">Synchronizacja kalendarzy, zaproszenia, przypomnienia. Standardowy proces.</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Przeprowadzenie rozmowy kwalifikacyjnej</td>
<td class="py-3 px-4"><span class="inline-block px-2 py-0.5 text-xs font-bold rounded bg-red-100 text-red-800">Człowiek decyduje</span></td>
<td class="py-3 pl-4">Rozmowa osobista. Nie do zautomatyzowania.</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Decyzja o zatrudnieniu</td>
<td class="py-3 px-4"><span class="inline-block px-2 py-0.5 text-xs font-bold rounded bg-red-100 text-red-800">Człowiek decyduje</span></td>
<td class="py-3 pl-4">Decyzja kadrowa. Rada Zakładowa posiada prawo do informacji i konsultacji. Margines ocenny.</td>
</tr>
<tr class="border-b border-gosign-dark/10">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Przygotowanie oferty zatrudnienia</td>
<td class="py-3 px-4"><span class="inline-block px-2 py-0.5 text-xs font-bold rounded bg-emerald-100 text-emerald-800">Zestaw reguł</span></td>
<td class="py-3 pl-4">Klasyfikacja według siatki wynagrodzeń. Logika deterministyczna.</td>
</tr>
<tr>
<td class="py-3 pr-4 font-semibold text-gosign-dark">Sformułowanie odmowy</td>
<td class="py-3 px-4"><span class="inline-block px-2 py-0.5 text-xs font-bold rounded bg-blue-100 text-blue-800">Automatycznie</span></td>
<td class="py-3 pl-4">Standardowa odmowa przy jednoznacznym niespełnieniu kryteriów obowiązkowych. Przypadki graniczne są eskalowane.</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- EU AI Act High Risk -->
<section class="py-section bg-gosign-dark text-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold">Dlaczego AI w rekrutacji to kategoria wysokiego ryzyka</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4">
EU AI Act klasyfikuje systemy AI w rekrutacji jako systemy wysokiego ryzyka (Załącznik III, Nr 4). Zgodnie z obowiązującym prawem obowiązki mają zastosowanie od 2 sierpnia 2026 r., jednak na mocy wstępnego porozumienia <a href="/pl/magazyn/eu-ai-act-2026-przedsiebiorstwa/" class="text-gosign-accent-on-dark hover:underline">Digital Omnibus</a> z 7 maja 2026 r. mają zostać przesunięte na 2 grudnia 2027 r. (formalne przyjęcie wciąż w toku, stan na czerwiec 2026 r.). Dotyczy to każdej organizacji, która wykorzystuje AI do screeningu aplikacji, oceny kandydatów lub decyzji o zatrudnieniu.
</p>
<div class="mt-8 space-y-6">
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-body-lg font-semibold text-white">Bias Monitoring jest obowiązkowy</p>
<p class="text-body text-gosign-text-on-dark/70 mt-1">Czy określone grupy są systematycznie oceniane inaczej? Decision Layer monitoruje statystycznie wszystkie decyzje screeningowe i sygnalizuje anomalie.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-body-lg font-semibold text-white">Nadzór ludzki wymuszony architektonicznie</p>
<p class="text-body text-gosign-text-on-dark/70 mt-1">Decyzje o zatrudnieniu nie mogą być w pełni zautomatyzowane. Decision Layer wymusza Human-in-the-Loop przy wszystkich decyzjach kadrowych na poziomie architektury.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-body-lg font-semibold text-white">Transparentność dla kandydatów</p>
<p class="text-body text-gosign-text-on-dark/70 mt-1">Kandydaci muszą być poinformowani o wykorzystaniu AI. Audit Trail dokumentuje pełną ścieżkę decyzyjną dla każdego kandydata.</p>
</div>
<div class="border-l-4 border-gosign-accent pl-6">
<p class="text-body-lg font-semibold text-white">Audit Trail dla każdej decyzji</p>
<p class="text-body text-gosign-text-on-dark/70 mt-1">Każda decyzja screeningowa: dane wejściowe, zastosowany zestaw reguł, wynik pewności, rezultat, znacznik czasu. Nie tworzone retrospektywnie, ale generowane automatycznie.</p>
</div>
</div>
<p class="text-body text-gosign-text-on-dark/60 mt-8">
→ <a href="/pl/governance/eu-ai-act/" class="text-gosign-accent-on-dark hover:underline">EU AI Act Compliance w szczegółach</a>
</p>
</div>
</div>
</section>

<!-- Rada Zakładowa -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Jak Rada Zakładowa nadzoruje AI w rekrutacji?</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Rada Zakładowa posiada prawo do informacji i konsultacji w zakresie wprowadzania nowych technologii w miejscu pracy (Ustawa o radach pracowników, Kodeks pracy). Gdy AI uczestniczy w preselekcji, przedstawiciele pracowników chcą wiedzieć: jakie kryteria są stosowane do filtrowania? Kto zdefiniował kryteria? Kto ponosi odpowiedzialność?
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Decision Layer zapewnia Radzie Zakładowej dokładnie tę transparentność:
</p>
<div class="mt-6 space-y-4">
<div class="flex items-start gap-3">
<span class="flex-shrink-0 w-6 h-6 rounded-full bg-gosign-accent text-white flex items-center justify-center text-sm font-bold">✓</span>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Kryteria są jawne:</strong> Reguły screeningowe to wersjonowane, udokumentowane zestawy reguł - nie czarna skrzynka.</p>
</div>
<div class="flex items-start gap-3">
<span class="flex-shrink-0 w-6 h-6 rounded-full bg-gosign-accent text-white flex items-center justify-center text-sm font-bold">✓</span>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Decyzje o zatrudnieniu pozostają przy człowieku:</strong> Agent proponuje, człowiek decyduje. Wymuszone architektonicznie, nie opcjonalnie.</p>
</div>
<div class="flex items-start gap-3">
<span class="flex-shrink-0 w-6 h-6 rounded-full bg-gosign-accent text-white flex items-center justify-center text-sm font-bold">✓</span>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Audit Trail dla każdej aplikacji:</strong> Które kryterium doprowadziło do zaproszenia lub odmowy? Możliwe do śledzenia w portalu audytorskim.</p>
</div>
<div class="flex items-start gap-3">
<span class="flex-shrink-0 w-6 h-6 rounded-full bg-gosign-accent text-white flex items-center justify-center text-sm font-bold">✓</span>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Raport bias dla Rady Zakładowej:</strong> Analiza statystyczna wszystkich decyzji rekrutacyjnych. Czy określone grupy są systematycznie traktowane inaczej?</p>
</div>
</div>
<p class="text-body text-gosign-text-light mt-6">
→ <a href="/pl/governance/co-determination/" class="text-gosign-accent-text hover:underline">Prawo do konsultacji i AI Agents w szczegółach</a>
</p>
</div>
</div>
</section>

<!-- Potencjał -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Co daje Recruiting Agent?</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Badania branżowe szacują potencjał automatyzacji w rekrutacji na 70-75%. To nie oznacza 75% mniej rekruterów. To oznacza: 75% kroków procesu może być przyspieszonych przez agentów - parsowanie CV, dopasowywanie wymagań, planowanie terminów, standardowa komunikacja.
</p>
<div class="mt-6 space-y-4">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark">Skrócenie czasu obsadzenia stanowiska</p>
<p class="text-body-lg text-gosign-text-light mt-2">Z 90 do 30-45 dni. Nie przez szybsze decyzje, ale przez eliminację przestojów: screening w godzinach zamiast tygodni, automatyczna koordynacja terminów, natychmiastowa standardowa komunikacja.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark">Spójna ocena</p>
<p class="text-body-lg text-gosign-text-light mt-2">Każdy kandydat jest oceniany według tego samego zestawu reguł. Niezależnie od tego, który rekruter prowadzi stanowisko czy jest poniedziałek rano czy piątek po południu.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark">Więcej czasu na kandydatów</p>
<p class="text-body-lg text-gosign-text-light mt-2">Rekruterzy poświęcają czas na rozmowy zamiast na wprowadzanie danych. Jakość doświadczenia kandydata rośnie, bo człowiek koncentruje się na tym, co tylko człowiek potrafi.</p>
</div>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">Przypadki Użycia</h2>
<div class="grid grid-cols-1 gap-6 lg:gap-8 lg:grid-cols-3">
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<h3 class="text-h3 font-bold text-gosign-dark">Dopasowywanie Wymagań</h3>
<p class="text-body text-gosign-text-light mt-3">CV wobec profilu wymagań. Każde kryterium sprawdzone, każda luka udokumentowana. Spójnie na wszystkich stanowiskach.</p>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<h3 class="text-h3 font-bold text-gosign-dark">Screening Wolumenowy</h3>
<p class="text-body text-gosign-text-light mt-3">Setki aplikacji, ten sam standard jakości. Bez uprzedzeń z zmęczenia, bez niespójności między oceną poranną a wieczorną.</p>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<h3 class="text-h3 font-bold text-gosign-dark">Dokumentacja Compliance</h3>
<p class="text-body text-gosign-text-light mt-3">Każde odrzucenie identyfikowalne. Każda ocena udokumentowana z referencją do kryterium. Gotowe na przegląd Rady Zakładowej.</p>
</article>
</div>
</div>
</section>

<section class="bg-gosign-dark text-white py-section">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold">Governance & Compliance</h2>
<div class="mt-8 space-y-4">
<p class="text-body-lg text-gosign-text-on-dark/80 flex items-start gap-3">
<svg class="w-5 h-5 mt-1 flex-shrink-0 text-gosign-accent" fill="currentColor" viewBox="0 0 20 20"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span>Decyzja Ludzka: Decyzja o zatrudnieniu jest zawsze ludzka. Agent sprawdza i dokumentuje.</span>
</p>
<p class="text-body-lg text-gosign-text-on-dark/80 flex items-start gap-3">
<svg class="w-5 h-5 mt-1 flex-shrink-0 text-gosign-accent" fill="currentColor" viewBox="0 0 20 20"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span>Zapobieganie Uprzedzeniom: Ocena według zdefiniowanych kryteriów. Dane demograficzne architektonicznie wykluczalne.</span>
</p>
<p class="text-body-lg text-gosign-text-on-dark/80 flex items-start gap-3">
<svg class="w-5 h-5 mt-1 flex-shrink-0 text-gosign-accent" fill="currentColor" viewBox="0 0 20 20"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span>EU AI Act: Kategoria wysokiego ryzyka. Transparentność, nadzór ludzki i rejestracja spełnione by design.</span>
</p>
<p class="text-body-lg text-gosign-text-on-dark/80 flex items-start gap-3">
<svg class="w-5 h-5 mt-1 flex-shrink-0 text-gosign-accent" fill="currentColor" viewBox="0 0 20 20"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span>Audit Trail: Każda decyzja screeningowa udokumentowana, wersjonowana, eksportowalna.</span>
</p>
</div>
</div>
</div>
</section>

<!-- Ten agent w katalogu -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark">Kiedy zacząć? Priorytetyzacja i gotowość governance</h2>
<p class="text-body text-gosign-text mt-4">Katalog agentów HR pokazuje wyniki, złożoność governance, klasyfikację EU AI Act oraz pełną tabelę mikrodecyzji dla tego agenta - umieszczonego w 3 kwadrantach priorytetyzacji z 47 innymi agentami HR.</p>
<a href="/pl/katalog-agentow-hr/candidate-screening-agent/" class="inline-flex items-center gap-2 mt-4 text-body font-semibold text-gosign-accent hover:underline">Zobacz sekwencję i wyniki &rarr;</a>
</div>
</section>

<!-- Pogłębienie w Agent Briefing -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">Pogłębienie w Agent Briefing (Magazyn Gosign)</h2>
<div class="grid md:grid-cols-3 gap-6">
<a href="/pl/magazyn/eu-ai-act-hr/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<h3 class="text-h3 font-bold text-gosign-dark">EU AI Act i HR</h3>
</a>
<a href="/pl/magazyn/rada-zakladowa-ai-mitbestimmung/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<h3 class="text-h3 font-bold text-gosign-dark">Rada Zakładowa i AI - Współzarządzanie</h3>
</a>
<a href="/pl/magazyn/agent-governance-hr/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR</p>
<h3 class="text-h3 font-bold text-gosign-dark">Agent Governance dla HR</h3>
</a>
</div>
</div>
</section>

--- Case Study: Pilot Gruppe - Infrastruktura AI w Azure ---
> Jak Gosign wdrozyl zgodna z RODO, model-agnostyczna infrastrukture AI z kontrola dostepu i Human-in-the-Loop w srodowisku Azure Pilot Gruppe.

<!-- Sytuacja wyjsciowa -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Sytuacja wyjsciowa</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Pilot Gruppe potrzebowal infrastruktury AI opartej na istniejacym srodowisku Microsoft Azure. Kluczowe wymagania:
</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light">Suwerennosc danych musi pozostac w organizacji</li>
<li class="text-body-lg text-gosign-text-light">Uwierzytelnianie przez istniejace Azure Entra ID (SSO)</li>
<li class="text-body-lg text-gosign-text-light">Departamentowa kontrola dostepu - dane HR tylko dla HR</li>
<li class="text-body-lg text-gosign-text-light">Wiele modeli AI uzywalnych rownolegle</li>
<li class="text-body-lg text-gosign-text-light">Zgodnosc z RODO potwierdzona niezalezna ekspertyza przed uruchomieniem</li>
</ul>
</div>
</section>

<!-- Realizacja -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Realizacja</h2>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">Architektura wielu modeli</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Zamiast uzależnienia od jednego dostawcy: architektura model-agnostyczna z wyborem modelu per use case. Wdrożone modele: GPT-5.5, Gemini 3.1 Pro, Claude Opus 4.7 i Mistral Small 3.2 do tekstu/rozumowania, Flux do generowania obrazów. Pracownicy sami wybierają kombinację modeli - w zależności od zadania. Architektura model-agnostyczna umożliwiła płynny upgrade z GPT-4o na GPT-5.5 bez zmian w kodzie interfejsu czatu.
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">Kontrola dostepu przez Azure Entra ID</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Istniejace grupy uprawnien w Azure Entra ID zostaly bezposrednio polaczone z interfejsem AI. Bez nowego zarzadzania uzytkownikami, bez dodatkowego uwierzytelniania.
</p>
<p class="text-body-lg text-gosign-text-light mt-2">
Rezultat: Dzial marketingu widzi inne modele AI i agentow niz dzial HR. Wrazliwe dane takie jak wynagrodzenia pozostaja w grupie uprawnien HR - niewidoczne dla innych dzialow.
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">Progressive Web App (PWA)</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Interfejs zostal zbudowany jako PWA - dziala na Windows i macOS bez instalacji. Skroty klawiszowe dla zaawansowanych uzytkownikow. Drag & drop do przesylania plikow.
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">Ekspertyza RODO przed uruchomieniem</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Cala architektura zostala przeanalizowana przed uruchomieniem przez inspektora ochrony danych Pilot Gruppe oraz przez Dr. Franka Eickmeiera (unverzagt.law). Pozytywna ekspertyza RODO potwierdza zgodnosc.
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">Agenci AI na platformie n8n</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Na platformie n8n skonfigurowanej w infrastrukturze Pilot dzialaja agenci AI dostepni przez wiele kanalow: interfejs, Microsoft Teams i inne kanaly wspolpracy. Human-in-the-Loop jest zaimplementowany: agenci wchodza w interakcje bezposrednio z odpowiednimi dzialami, gdy potrzebne jest wyjasnienie.
</p>
</div>
</section>

<!-- Rezultat -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Rezultat</h2>
<ul class="mt-6 space-y-3">
<li class="text-body-lg text-gosign-text-light">Wszystkie dane pozostaja w srodowisku Azure Pilot Gruppe - zgodne z RODO</li>
<li class="text-body-lg text-gosign-text-light">Istniejaca infrastruktura IT i uwierzytelnianie sa ponownie wykorzystywane</li>
<li class="text-body-lg text-gosign-text-light">Model-agnostyczna: nowe modele mozna integrowac bez zmian w architekturze</li>
<li class="text-body-lg text-gosign-text-light">Departamentowe workspace'y z Role-Based Access Control</li>
<li class="text-body-lg text-gosign-text-light">Pracownicy samodzielnie tworza asystentow AI i agentow</li>
<li class="text-body-lg text-gosign-text-light">Miedzydzialowe udostepnianie agentow kontrolowane przez IT</li>
<li class="text-body-lg text-gosign-text-light">Niezalezna ekspertyza RODO przed uruchomieniem</li>
</ul>
</div>
</section>

<!-- Technologia -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Technologia</h2>
<ul class="mt-6 space-y-2">
<li class="text-body-lg text-gosign-text-light">Microsoft Azure (srodowisko klienta)</li>
<li class="text-body-lg text-gosign-text-light">Azure Entra ID (SSO, RBAC)</li>
<li class="text-body-lg text-gosign-text-light">n8n (orkiestracja agentow)</li>
<li class="text-body-lg text-gosign-text-light">Wiele LLM (GPT-5.5, Gemini 3.1 Pro, Claude Opus 4.7, Mistral Small 3.2, Flux)</li>
<li class="text-body-lg text-gosign-text-light">PWA (Progressive Web App)</li>
</ul>
</div>
</section>

<!-- Zakres uslug Gosign -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Zakres uslug Gosign</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Koncepcja, implementacja, deployment, szkolenia, bieżące wsparcie. Oprócz infrastruktury AI, Gosign zbudował kompletną platformę agentową: pracownicy samodzielnie tworzą asystentów AI i agentów, a dział IT kontroluje międzydziałowe udostępnianie agentów. Dział IT Pilot Gruppe zarządza całą platformą z istniejącymi kompetencjami Azure - bez nowego toolingu.
</p>
</div>
</section>

--- pilot Agency Group: infrastruktura AI zgodna z RODO dla 1000 pracowników ---
> Jak druga co do wielkości niezależna agencja mediowa w Niemczech zbudowała infrastrukturę AI z pełną rezydencją danych w UE.

## Punkt wyjścia

pilot to jedna z największych niezależnych agencji mediowych w Niemczech, zarządzana przez właścicieli. Z ponad 1000 pracowników w siedmiu lokalizacjach pilot obsługuje klientów takich jak Dr. Oetker, OBI, Techniker Krankenkasse i GetYourGuide. Jako agencja mediowa pilot codziennie przetwarza duże ilości danych kampanijnych, danych klientów i dokumentów strategii mediowej.

Wyzwanie: pilot chciał wdrożyć narzędzia AI w całej firmie - do badań, analizy dokumentów, planowania kampanii i wewnętrznej bazy wiedzy. Wymóg Bossego Küllenberga, Dyrektora Zarządzającego ds. Technologii i Operacji, był jednoznaczny: żadne dane nie mogą opuścić UE. Żadnych kompromisów w kwestii RODO. I żadnego uzależnienia od dostawcy.

W tamtym czasie większość dostawców AI nie oferowała gwarantowanej rezydencji danych w UE. ChatGPT Enterprise nie był jeszcze dostępny, a istniejące alternatywy nie spełniały wymagań agencji mediowej obsługującej wrażliwe dane klientów.


## Wymagania

Bosse Küllenberg zdefiniował cztery niepodlegające negocjacjom wymagania dla infrastruktury AI.

Po pierwsze: pełna rezydencja danych w UE. Wszystkie dane - prompty, odpowiedzi, przesłane dokumenty - muszą pozostać w UE. Żadnych serwerów w USA, żadnych transatlantyckich transferów danych, żadnych wyjątków.

Po drugie: separacja mandantów. pilot obsługuje klientów z różnych branż. Dane jednego klienta nie mogą w żadnym wypadku trafić do kontekstu innego klienta. Wymaga to ścisłej izolacji danych na poziomie infrastruktury.

Po trzecie: niezależność od modelu. Infrastruktura nie może być przywiązana do jednego LLM. Gdy pojawi się lepszy model, zmiana musi być możliwa bez przebudowy architektury.

Po czwarte: identyfikowalność. Dla wewnętrznej zgodności i wobec klientów musi być udokumentowane, jakie dane są przetwarzane i jaki model jest używany.


## Rozwiązanie

Gosign wdrożył [infrastrukturę AI](/pl/uslugi/infrastruktura/) o następujących właściwościach.

Infrastruktura działa w całości w regionie UE (Germany West Central w Azure). Żaden prompt, żaden dokument, żadna odpowiedź nie opuszcza UE. Rezydencja danych jest nie tylko zapewniona umownie, ale wymuszona architektonicznie: po prostu nie istnieje ścieżka, którą dane mogłyby opuścić UE.

Separacja mandantów działa na poziomie infrastruktury. Każdy zespół pracuje w izolowanym kontekście. Przesłane dokumenty, historie rozmów i wygenerowane treści są ściśle oddzielone.

Architektura jest [agnostyczna wobec modeli](/pl/uslugi/infrastruktura/). Warstwa orkiestracji kieruje zapytania do optymalnego modelu - obecnie kilka modeli działa równolegle. Zmiana modelu wymaga zmiany konfiguracji, nie przebudowy architektury.

Każda interakcja jest rejestrowana: znacznik czasu, użyty model, przypisanie kontekstu. Nie treść promptów jest przechowywana, lecz metadane - wystarczające do dowodów zgodności bez naruszania poufności.


## Wynik

pilot dysponuje infrastrukturą AI, która traktuje zgodność z RODO nie jako kompromis, lecz jako zasadę projektową. Ponad 1000 pracowników korzysta z infrastruktury codziennie - do badań, analizy dokumentów i pracy kampanijnej.

Rezydencja danych w UE jest w pełni zagwarantowana. Separacja mandantów zapobiega jakiejkolwiek formie wycieku danych między zespołami klientów. Architektura agnostyczna wobec modeli umożliwiła już dwie zmiany modelu bez przerwy operacyjnej.

Bosse Küllenberg od początku miał jasną wizję tego, jak powinna wyglądać infrastruktura AI w regulowanym środowisku. Gosign przełożył tę wizję na technologię - czysto, audytowalnie i przyszłościowo.


## Wskaźniki

| Wskaźnik | Wartość |
|----------|---------|
| Pracownicy z dostępem | 1 000+ |
| Podłączone lokalizacje | 7 |
| Rezydencja danych w UE | 100% |
| Zmiany modelu bez przebudowy | 2 przeprowadzone |
| Uzależnienie od dostawcy | Brak |

--- Referencje: przemysł maszynowy ---
> Referencje Gosign w przemyśle maszynowym: strony B2B, konfiguratory produktów, cyfrowe narzędzia sprzedażowe.

<!-- Gosign w przemyśle maszynowym -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Gosign w przemyśle maszynowym</h2>
<p class="text-body text-gosign-text leading-relaxed">
Gosign tworzy rozwiązania cyfrowe dla firm z sektora maszynowego i produkcyjnego: strony B2B, konfiguratory produktów, portale dla dystrybutorów, platformy dokumentacji technicznej i cyfrowe narzędzia sprzedażowe. Branża stawia szczególne wymagania: złożone dane produktowe, wielojęzyczne katalogi, integracja z systemami PIM/ERP, długie cykle decyzyjne. Polska, z silnym sektorem motoryzacyjnym i maszynowym, jest kluczowym rynkiem dla tych rozwiązań.
</p>
</div>
</section>

<!-- Co Gosign buduje -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Co Gosign buduje dla klientów z sektora maszynowego</h2>
<ul class="space-y-4">
<li class="flex items-start gap-3">
<span class="flex-shrink-0 mt-1.5 w-2 h-2 bg-gosign-accent rounded-full"></span>
<div>
<span class="font-bold text-gosign-dark">Strony B2B</span>
<span class="text-body text-gosign-text">: responsywne, wydajne, z wyszukiwarką produktów i przekierowaniem kontaktów do odpowiedniego partnera handlowego</span>
</div>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 mt-1.5 w-2 h-2 bg-gosign-accent rounded-full"></span>
<div>
<span class="font-bold text-gosign-dark">Konfiguratory produktów</span>
<span class="text-body text-gosign-text">: interaktywne konfiguratory, które pobierają parametry techniczne i rekomendują odpowiednie produkty</span>
</div>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 mt-1.5 w-2 h-2 bg-gosign-accent rounded-full"></span>
<div>
<span class="font-bold text-gosign-dark">Portale dla dystrybutorów</span>
<span class="text-body text-gosign-text">: chronione strefy logowania dla partnerów handlowych: cenniki, dokumentacja techniczna, narzędzia zamówień</span>
</div>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 mt-1.5 w-2 h-2 bg-gosign-accent rounded-full"></span>
<div>
<span class="font-bold text-gosign-dark">Wielojęzyczne katalogi</span>
<span class="text-body text-gosign-text">: katalogi produktowe oparte na TYPO3 z połączeniem PIM, automatycznym tłumaczeniem i wariantami regionalnymi</span>
</div>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 mt-1.5 w-2 h-2 bg-gosign-accent rounded-full"></span>
<div>
<span class="font-bold text-gosign-dark">Cyfrowe narzędzia sprzedażowe</span>
<span class="text-body text-gosign-text">: prezentacje produktów na tablety, katalogi offline, generatory ofert</span>
</div>
</li>
</ul>
</div>
</section>

<!-- Tabela technologii -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Technologie w środowisku przemysłowym</h2>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Wymaganie</th>
<th class="py-3 text-small font-bold text-gosign-dark">Rozwiązanie Gosign</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">CMS</td>
<td class="py-3 text-body text-gosign-text">TYPO3 (Enterprise) lub WordPress (nastawiony na treść)</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Integracja PIM</td>
<td class="py-3 text-body text-gosign-text">Akeneo, Pimcore, połączenie własne</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Połączenie ERP</td>
<td class="py-3 text-body text-gosign-text">SAP, Microsoft Dynamics, Custom API</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Wielojęzyczność</td>
<td class="py-3 text-body text-gosign-text">TYPO3 natywnie, do 30+ języków</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Wydajność</td>
<td class="py-3 text-body text-gosign-text">Cloudflare CDN, Edge Caching, generowanie statyczne</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Porozmawiaj o projekcie dla sektora maszynowego - 30&nbsp;minut, bezpłatnie.</h3>
<p class="text-body text-gosign-text mb-6">Przeanalizujemy Twój projekt, oszacujemy nakład pracy i harmonogram, bez zobowiązań.</p>
<a
href="/pl/kontakt/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Umów spotkanie
</a>
<p class="text-small text-gosign-text-light mt-4">25 lat doświadczenia · 800+ rozszerzeń · rozwój wspomagany AI</p>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
Gosign to hamburska agencja cyfrowa z 25-letnim doświadczeniem w tworzeniu stron, TYPO3 i integracji AI.
Obsługujemy europejskie i polskie przedsiębiorstwa z naszej siedziby w Hamburgu.
Przeanalizowaliśmy ponad 800 rozszerzeń TYPO3 i dzięki wsparciu AI realizujemy projekty
do 70&nbsp;% szybciej niż tradycyjnymi metodami.
</p>
<p class="text-small text-gosign-text-light mt-2">Stan na: luty 2026</p>
</div>
</section>

--- Referencje - Gosign Enterprise AI Infrastructure ---
> Przedsiębiorstwa, które polegają na infrastrukturze Gosign. Case studies z mediów, usług profesjonalnych i logistyki.

<!-- Referencja 1: pilot -->
<section class="py-16 lg:py-24 bg-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid lg:grid-cols-2 gap-12 items-start">
<div>
<span class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider">Agencja mediowa · 1000 pracowników</span>
<h2 class="text-h2 font-bold text-gosign-dark mt-2 mb-4">pilot Agency Group</h2>
<p class="text-body text-gosign-text leading-relaxed mb-4">
Druga co do wielkości niezależna agencja mediowa w Niemczech potrzebowała infrastruktury AI, która traktuje zgodność z RODO nie jako ograniczenie, lecz jako zasadę architektoniczną - dla ponad 1000 pracowników w siedmiu lokalizacjach.
</p>
<p class="text-body text-gosign-text leading-relaxed mb-6">
Gosign dostarczył infrastrukturę self-hosted z pełną rezydencją danych w UE, zanim inni dostawcy w ogóle nadali temu tematowi priorytet.
</p>
<blockquote class="border-l-4 border-gosign-accent pl-4 italic text-gosign-text mb-6">
<div class="flex items-start gap-4 not-italic mb-3">
<img src="/images/logos/pilot-v2.svg" alt="pilot Agency Group Logo" class="w-24 h-auto opacity-80" width="91" height="45" loading="lazy" />
</div>
&bdquo;Dla mnie od początku było jasne: żadnych danych poza UE, żadnych kompromisów w kwestii RODO. Gosign dostarczył dokładnie to - technicznie solidnie, bez żadnych zastrzeżeń.&rdquo;
<footer class="mt-4 flex items-center gap-4 text-small not-italic text-gosign-dark">
<img src="/images/testimonials/t1.webp" alt="" class="w-14 h-14 rounded-full object-cover ring-2 ring-gray-100" width="56" height="56" loading="lazy" />
<div>
<p class="font-semibold leading-tight"><img src="/images/testimonials/t1-n.svg" alt="" width="140" height="17" style="height:1.15em;width:auto;max-width:none;display:block" loading="lazy" /></p>
<p class="font-normal text-gosign-text-light mt-0.5">Dyrektor Zarządzający Technology &amp; Operations, pilot</p>
</div>
</footer>
</blockquote>
<a href="/pl/referencje/pilot-ai/" class="text-gosign-accent-text font-semibold hover:underline">
Przeczytaj studium przypadku →
</a>
</div>
<div class="bg-gosign-light rounded-card p-8">
<dl class="space-y-4 text-body">
<div><dt class="font-semibold text-gosign-dark">Branża</dt><dd class="text-gosign-text">Media i komunikacja</dd></div>
<div><dt class="font-semibold text-gosign-dark">Pracownicy</dt><dd class="text-gosign-text">1000+</dd></div>
<div><dt class="font-semibold text-gosign-dark">Lokalizacje</dt><dd class="text-gosign-text">Hamburg, Berlin, Monachium, Stuttgart, Norymberga, Moguncja, Zurych</dd></div>
<div><dt class="font-semibold text-gosign-dark">Zakres</dt><dd class="text-gosign-text">Infrastruktura AI zgodna z RODO, rezydencja danych w UE</dd></div>
<div><dt class="font-semibold text-gosign-dark">Usługi</dt><dd class="text-gosign-text"><a href="/pl/uslugi/infrastruktura/" class="text-gosign-accent-text hover:underline">Infrastruktura AI</a>, <a href="/pl/uslugi/ai-agents/" class="text-gosign-accent-text hover:underline">Platforma agentowa</a></dd></div>
</dl>
</div>
</div>
</div>
</section>

<!-- Referencja 2: Roser -->
<section class="py-16 lg:py-24 bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid lg:grid-cols-2 gap-12 items-start">
<div>
<span class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider">Kancelaria prawna · Doradztwo podatkowe · Audyt · 100 pracowników</span>
<h2 class="text-h2 font-bold text-gosign-dark mt-2 mb-4">Roser Rechtsanwälte Wirtschaftsprüfer (niemiecki biegły rewident) (niemiecki biegły rewident) Steuerberater</h2>
<p class="text-body text-gosign-text leading-relaxed mb-4">
Multidyscyplinarna kancelaria z 38 licencjonowanymi specjalistami, która audytuje innych pod kątem compliance - i dlatego stawia najwyższe wymagania wobec własnej infrastruktury AI: tajemnica zawodowa zgodna z niemieckimi regulacjami (§ 203 StGB, BRAO, StBerG, WPO - niemieckie regulacje tajemnicy zawodowej dla prawników, doradców podatkowych i biegłych rewidentów).
</p>
<p class="text-body text-gosign-text leading-relaxed mb-6">
Gosign dostarczył infrastrukturę self-hosted z kryptograficzną separacją mandantów, Decision Layer i kompletną ścieżką audytu - udokumentowaną na poziomie wymaganym przez izby zawodowe.
</p>
<blockquote class="border-l-4 border-gosign-accent pl-4 italic text-gosign-text mb-6">
<div class="flex items-start gap-4 not-italic mb-3">
<img src="/images/logos/roser.svg" alt="Roser Rechtsanwälte Wirtschaftsprüfer Steuerberater Logo" class="h-12 w-auto opacity-80" width="947" height="138" loading="lazy" />
</div>
&bdquo;Jako doradcy podatkowi i biegli rewidenci audytujemy innych pod kątem compliance - dlatego nasze własne systemy muszą być bez zarzutu. Architektura governance Gosign spełnia dokładnie te standardy, które stosujemy u naszych klientów.&rdquo;
<footer class="mt-4 flex items-center gap-4 text-small not-italic text-gosign-dark">
<img src="/images/testimonials/t2.webp" alt="" class="w-14 h-14 rounded-full object-cover ring-2 ring-gray-100" width="56" height="56" loading="lazy" />
<div>
<p class="font-semibold leading-tight"><img src="/images/testimonials/t2-n.svg" alt="" width="105" height="17" style="height:1.15em;width:auto;max-width:none;display:block" loading="lazy" /></p>
<p class="font-normal text-gosign-text-light mt-0.5">Dyrektor Zarządzający, Roser Rechtsanwaltsgesellschaft mbH</p>
</div>
</footer>
</blockquote>
</div>
<div class="bg-white rounded-card p-8">
<dl class="space-y-4 text-body">
<div><dt class="font-semibold text-gosign-dark">Branża</dt><dd class="text-gosign-text">Kancelaria prawna, doradztwo podatkowe, audyt</dd></div>
<div><dt class="font-semibold text-gosign-dark">Pracownicy</dt><dd class="text-gosign-text">100 (w tym 38 licencjonowanych specjalistów)</dd></div>
<div><dt class="font-semibold text-gosign-dark">Lokalizacje</dt><dd class="text-gosign-text">Hamburg, Lipsk</dd></div>
<div><dt class="font-semibold text-gosign-dark">Zakres</dt><dd class="text-gosign-text">AI zgodna z tajemnicą zawodową, Decision Layer, ścieżka audytu</dd></div>
<div><dt class="font-semibold text-gosign-dark">Usługi</dt><dd class="text-gosign-text"><a href="/pl/finance-ai-agents/" class="text-gosign-accent-text hover:underline">Finance Agent</a>, <a href="/pl/uslugi/infrastruktura/" class="text-gosign-accent-text hover:underline">Infrastruktura AI</a></dd></div>
</dl>
</div>
</div>
</div>
</section>

<!-- Referencja 3: Zanonimizowana (Logistyka handlowa) -->
<section class="py-16 lg:py-24 bg-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid lg:grid-cols-2 gap-12 items-start">
<div>
<span class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider">Logistyka handlowa · 500+ pracowników</span>
<h2 class="text-h2 font-bold text-gosign-dark mt-2 mb-4">Północnoniemiecki logistyk handlowy</h2>
<p class="text-body text-gosign-text leading-relaxed mb-4">
Uznany logistyk handlowy z ponad 500 pracownikami i jedną z najbardziej efektywnych infrastruktur IT i logistycznych w swojej branży polega na Gosign jako strategicznym partnerze doradczym w zakresie integracji AI.
</p>
<p class="text-body text-gosign-text leading-relaxed mb-6">
W centrum uwagi: doradztwo strategiczne w zakresie integracji AI Agents do obsługi klienta. Współpraca koncentruje się na tym, jak wsparcie oparte na AI może zostać osadzone w złożonym, historycznie ukształtowanym krajobrazie IT - bez zakłócania bieżącej działalności.
</p>
</div>
<div class="bg-gosign-light rounded-card p-8">
<dl class="space-y-4 text-body">
<div><dt class="font-semibold text-gosign-dark">Branża</dt><dd class="text-gosign-text">Logistyka handlowa</dd></div>
<div><dt class="font-semibold text-gosign-dark">Pracownicy</dt><dd class="text-gosign-text">500+</dd></div>
<div><dt class="font-semibold text-gosign-dark">Lokalizacja</dt><dd class="text-gosign-text">Północne Niemcy</dd></div>
<div><dt class="font-semibold text-gosign-dark">Zakres</dt><dd class="text-gosign-text">Doradztwo strategiczne, obsługa klienta z AI</dd></div>
<div><dt class="font-semibold text-gosign-dark">Usługi</dt><dd class="text-gosign-text"><a href="/pl/uslugi/ai-agents/" class="text-gosign-accent-text hover:underline">AI Agents</a>, <a href="/pl/uslugi/infrastruktura/" class="text-gosign-accent-text hover:underline">Infrastruktura AI</a></dd></div>
</dl>
</div>
</div>
</div>
</section>

--- Ogólne Warunki Handlowe - Gosign GmbH ---
> OWH Gosign GmbH dla infrastruktury AI, rozwoju agentów i tworzenia oprogramowania. Wersja 3.1.

<h1>Ogólne Warunki Handlowe</h1>
<p class="text-sm bg-gosign-light border border-gosign-border rounded-card p-3 mt-2">
<strong>Uwaga:</strong> Niniejszy dokument stanowi tłumaczenie informacyjne. Wersja niemiecka jest prawnie wiążąca. W przypadku rozbieżności obowiązuje wersja niemiecka.
<a href="/de/agb/" class="text-gosign-accent-text hover:text-gosign-accent-hover ml-1">→ Deutsche Fassung (wersja niemiecka)</a>
</p>
<p class="text-lg text-gosign-text-light">
Gosign GmbH - Infrastruktura AI, rozwój agentów i tworzenie oprogramowania<br/>
Wersja 3.1 - Stan: marzec 2026
</p>
<p class="text-sm text-gosign-text-light mt-2">
<a href="/documents/gosign-agb-v3.1.pdf" target="_blank" rel="noopener noreferrer"
class="text-gosign-accent-text hover:text-gosign-accent-hover">↓ Pobierz jako PDF (niemiecki oryginał)</a>
</p>

<h2>§ 1 Zakres obowiązywania i przedmiot umowy</h2>
<p>Niniejsze Ogólne Warunki Handlowe (OWH) obowiązują dla wszystkich umów pomiędzy Gosign GmbH (dalej "Gosign") a jej Klientami w następujących obszarach usług:</p>
<p><strong>Infrastruktura AI dla przedsiębiorstw i rozwój agentów:</strong> Usługi związane ze sztuczną inteligencją w środowisku korporacyjnym, obejmujące planowanie i wdrażanie infrastruktury AI, rozwój agentów AI, integrację modeli AI, rozwiązania self-hosting, strategie FinOps optymalizujące koszty obciążeń AI oraz powiązane usługi doradcze i rozwojowe.</p>
<p><strong>Decision Layer i architektura Governance:</strong> Opracowanie i wdrożenie warstwy sterowania i nadzoru (Decision Layer) pomiędzy agentami AI a docelowymi systemami przedsiębiorstwa, obejmujące sterowanie decyzjami oparte na regułach, dokumentację Audit Trail, architekturę Human-in-the-Loop oraz automatyczne generowanie dowodów zgodności (Cert-Ready).</p>
<p><strong>Tworzenie oprogramowania:</strong> Tworzenie indywidualnych rozwiązań programistycznych, aplikacji webowych i integracji, również z wykorzystaniem frameworków i bibliotek open source. Obejmuje to koncepcję, projektowanie, rozwój, dostosowanie, integrację i dokumentację.</p>
<p><strong>Hosting i usługi operacyjne (opcjonalnie):</strong> Opcjonalne usługi hostingowe i wsparcie operacyjne oferowane przez Gosign. Regularna eksploatacja rozwiązań opracowanych przez Gosign odbywa się zasadniczo w infrastrukturze Klienta. Hosting przez Gosign jest usługą dodatkową, uzgadnianą odrębnie.</p>
<p><strong>Enablement i transfer wiedzy:</strong> Celem Gosign jest umożliwienie Klientowi samodzielnej eksploatacji i dalszego rozwoju dostarczonych rozwiązań. W uzgodnionym zakresie usługi obejmują szkolenia, dokumentację i ustrukturyzowany transfer wiedzy, mający na celu planowe zmniejszanie zależności Klienta od Gosign.</p>
<p><strong>Rozgraniczenie:</strong> Gosign świadczy usługi techniczne. Rozwiązania opracowane przez Gosign nie zastępują doradztwa prawnego, podatkowego ani kadrowego. Końcowe decyzje merytoryczne pozostają po stronie Klienta. Systemy Klienta (np. SAP, Workday, SuccessFactors, DATEV) pozostają systemem wiodącym (System of Record); rozwiązania Gosign integrują się z tymi systemami, ale ich nie zastępują.</p>
<p><strong>Krąg Klientów:</strong> Niniejsze OWH skierowane są wyłącznie do przedsiębiorców w rozumieniu § 14 BGB (niemieckiego Kodeksu Cywilnego). Dla Klientów z siedzibą w UE/EOG obowiązują bezpośrednio. Dla Klientów spoza UE/EOG obowiązują pod warunkiem uzgodnienia stosowania prawa niemieckiego. Gosign nie zawiera umów z konsumentami.</p>
<p>Indywidualne uzgodnienia i SLA mają pierwszeństwo przed niniejszymi OWH. Odmienne warunki Klienta nie obowiązują, chyba że Gosign wyraził na to wyraźną pisemną zgodę.</p>

<h2>§ 2 Definicje</h2>
<p>Poniższe pojęcia stosowane są w niniejszych OWH w następującym znaczeniu:</p>
<p><strong>"Agent"</strong> oznacza komponent oprogramowania, który na podstawie modeli AI i zestawów reguł automatycznie wykonuje lub przygotowuje zadania w imieniu Klienta (np. Document Agent, Workflow Agent, Knowledge Agent).</p>
<p><strong>"Audit Trail"</strong> oznacza kompletny, chronologiczny zapis wszystkich Decision Records i zdarzeń w systemie.</p>
<p><strong>"Auditor Portal"</strong> oznacza interfejs webowy, za pośrednictwem którego upoważnieni audytorzy (wewnętrzni lub zewnętrzni) mogą przeglądać aktualny status wszystkich Controls i Evidence.</p>
<p><strong>"Cert-Ready"</strong> oznacza właściwość architektury systemu spełniającą techniczne wymagania wstępne dla branżowych certyfikacji (np. ISO 27001, SOC 2, IDW PS 951) - bez zobowiązania do uzyskania samej certyfikacji ani jej gwarancji.</p>
<p><strong>"Component Manifest"</strong> oznacza załączoną do oferty specyfikację, która przyporządkowuje każdy istotny komponent oprogramowania albo jako indywidualny rezultat pracy (§ 7.1), albo jako Komponent Platformy (§ 7.2). Szczegóły reguluje § 7.2 ust. 4.</p>
<p><strong>"Control"</strong> oznacza technicznie zaimplementowaną regułę weryfikacyjną zapewniającą spełnienie określonego standardu zgodności lub nadzoru (np. "Żadna decyzja płacowa bez zasady czterech oczu").</p>
<p><strong>"Decision Layer"</strong> oznacza opracowaną przez Gosign warstwę sterowania i nadzoru, która rozkłada procesy biznesowe na jednostkowe decyzje i dla każdego kroku określa, czy decyduje człowiek, stosowany jest zestaw reguł, czy AI działa autonomicznie.</p>
<p><strong>"Decision Record"</strong> oznacza automatyczną, niezmienialną dokumentację pojedynczej decyzji w Decision Layer, obejmującą dane wejściowe, zastosowaną regułę/wersję modelu, wskaźnik pewności, ścieżkę decyzyjną i wynik.</p>
<p><strong>"Evidence"</strong> oznacza automatycznie generowany dowód spełnienia danego Control w określonym momencie.</p>
<p><strong>"Human-in-the-Loop"</strong> oznacza zasadę architektoniczną, zgodnie z którą określone decyzje wymagają zatwierdzenia przez człowieka przed ich wykonaniem. Klasyfikacja decyzji wymagających zatwierdzenia ludzkiego jest ustalana wspólnie z Klientem w ramach projektu.</p>
<p><strong>"Maintenance"</strong> oznacza opcjonalną roczną umowę serwisową dotyczącą Komponentów Platformy, obejmującą bieżące utrzymanie, aktualizacje bezpieczeństwa i dalszy rozwój. Szczegóły reguluje § 7.7.</p>
<p><strong>"Perpetual License"</strong> oznacza trwałe prawo użytkowania Klienta do danej dostarczonej wersji Komponentów Platformy zgodnie z § 7.2 ust. 2. Prawo użytkowania istnieje niezależnie od obowiązywania umowy serwisowej.</p>
<p><strong>"Komponenty Platformy" (Plattform-Komponenten)</strong> oznaczają wielokrotnie wykorzystywany rdzeń techniczny rozwiązań Gosign, w szczególności Decision Engine, framework Rule Engine, architekturę Audit Trail oraz moduły orkiestracji. Szczegóły reguluje § 7.2 ust. 1.</p>
<p><strong>"Transfer kodu źródłowego" (Quellcode-Transfer)</strong> oznacza przeniesienie wyłącznego prawa użytkowania indywidualnie opracowanych dla Klienta komponentów oprogramowania, obejmujących kod źródłowy, prompty, zestawy reguł, konfiguracje i dokumentację.</p>
<p><strong>"Software Bill of Materials (SBOM)"</strong> oznacza zestawienie wszystkich komponentów open source wykorzystanych w rozwiązaniu wraz z ich licencjami zgodnie z § 7.4.</p>
<p><strong>"System of Record"</strong> oznacza wiodący system Klienta dla danych podstawowych i transakcyjnych (np. SAP, Workday, SuccessFactors, DATEV). Rozwiązania Gosign integrują się z System of Record, ale go nie zastępują.</p>
<p><strong>"Dopuszczalni Odbiorcy Zewnętrzni" (Zulässige Dritte)</strong> oznaczają podmioty wymienione wyczerpująco w § 7.1 ust. 3, którym Klient może przekazywać rezultaty pracy i Komponenty Platformy bez odrębnej zgody Gosign.</p>

<h2>§ 3 Zawarcie umowy</h2>
<p><strong>Oferta i zamówienie:</strong> Prezentacja usług przez Gosign zasadniczo nie stanowi wiążącej oferty zawarcia umowy. Umowa zostaje zawarta poprzez zlecenie Klienta i przyjęcie przez Gosign w ciągu 14 dni kalendarzowych.</p>
<p>Umowa zostaje zawarta dopiero po potwierdzeniu zamówienia przez Gosign w formie tekstowej lub rozpoczęciu realizacji.</p>
<p><strong>Umowa ramowa i fazy projektu:</strong> Umowa może być zawarta jako umowa ramowa z oddzielnie zlecanymi fazami. Każda faza może być zlecona oddzielnie, bez zobowiązania do zlecenia kolejnych faz.</p>
<p><strong>Rodzaje umów na fazę:</strong> Fazy Discovery (analiza, doradztwo, mapowanie procesów) realizowane są jako umowy o świadczenie usług (Dienstvertrag); zobowiązaniem jest usługa doradcza, nie określony rezultat. Fazy Build (rozwój, wdrożenie, Proof of Concept) realizowane są jako umowy o dzieło (Werkvertrag) z odbiorem, chyba że uzgodniono inaczej. Fazy Scale i Support realizowane są jako umowy o świadczenie usług; opcjonalnie obowiązują SLA.</p>
<p>Umowy mogą być zawierane pisemnie, elektronicznie lub w formie tekstowej. Gosign przechowuje tekst umowy i niniejsze OWH.</p>

<h2>§ 4 Usługi Gosign</h2>
<p>Gosign realizuje uzgodnione umownie usługi fachowo i z należytą starannością (Sorgfalt eines ordentlichen Kaufmanns). Gosign jest uprawniony do zatrudniania wykwalifikowanych pracowników, podwykonawców lub pomocników.</p>
<p><strong>Miejsce realizacji:</strong> Usługi realizowane są zasadniczo zdalnie. Gosign angażuje pracowników w różnych lokalizacjach i zapewnia przestrzeganie uzgodnionych standardów bezpieczeństwa i ochrony danych niezależnie od lokalizacji. Prace na miejscu uzgadniane są odrębnie.</p>
<p><strong>Koordynacja projektu:</strong> Obie strony wyznaczają osoby kontaktowe. Gosign regularnie informuje o postępie projektu.</p>
<p><strong>Terminy:</strong> Terminy są wiążące tylko wtedy, gdy wyraźnie tak uzgodniono. W przypadku opóźnień niezawinionych przez Gosign terminy ulegają odpowiedniemu przedłużeniu.</p>
<p><strong>Zmiany zakresu (Change Requests):</strong> Zmiany zakresu usług wymagają pisemnego uzgodnienia dodatkowych kosztów i terminów.</p>
<p><strong>Proof of Concept (PoC):</strong> Jeśli uzgodniono PoC, obowiązują kryteria sukcesu zdefiniowane w ofercie. PoC służy walidacji wykonalności technicznej. Rezultaty prac z PoC przechodzą na własność Klienta po pełnej zapłacie, chyba że uzgodniono inaczej.</p>
<p><strong>Dostawy częściowe:</strong> Gosign jest uprawniony do realizacji uzasadnionych dostaw częściowych.</p>
<h3>4.1 Odbiór dzieła</h3>
<p>Klient sprawdza dostarczone dzieło w ciągu 14 dni kalendarzowych i dokonuje odbioru lub zgłasza wady. Brak reakcji oznacza odbiór, pod warunkiem wcześniejszego poinformowania Klienta o tym skutku. Nieistotne wady nie uprawniają do odmowy odbioru.</p>

<h2>§ 5 Obowiązki współpracy Klienta</h2>
<p>Klient dostarcza terminowo wszystkie wymagane dokumenty, informacje, dane i dostępy.</p>
<p>Klient wyznacza wykwalifikowaną osobę kontaktową z uprawnieniami decyzyjnymi.</p>
<p><strong>Infrastruktura techniczna:</strong> Jeśli usługi realizowane są w systemach Klienta, Klient zapewnia infrastrukturę. Gosign informuje o wymaganiach systemowych.</p>
<p><strong>Testy i odbiory:</strong> Klient aktywnie współpracuje, dokumentuje błędy i nie opóźnia bezzasadnie zatwierdzeń.</p>
<p><strong>Utrzymanie i kopie zapasowe:</strong> Klient samodzielnie i terminowo instaluje aktualizacje bezpieczeństwa, chyba że posiada umowę serwisową z Gosign. Regularne kopie zapasowe leżą po stronie Klienta.</p>
<p><strong>Zgodność z prawem:</strong> Klient odpowiada za zgodność z prawem wszystkich przekazanych treści i danych oraz zwalnia Gosign z roszczeń osób trzecich.</p>
<p>Opóźnienia i dodatkowe koszty wynikające z naruszenia obowiązków współpracy obciążają Klienta.</p>

<h2>§ 6 Postanowienia szczególne dotyczące infrastruktury AI i rozwoju agentów</h2>
<h3>6.1 Zakres usług</h3>
<p>Zakres usług określa oferta i może obejmować: integrację i dostosowanie modeli AI, tworzenie agentów AI, budowę Decision Layer, doradztwo w zakresie infrastruktury AI, FinOps, koncepcje bezpieczeństwa i zgodności, szkolenia.</p>
<p>Oferta wskazuje, które Komponenty Platformy (§ 7.2) są wykorzystywane i zawiera Component Manifest jako załącznik.</p>
<h3>6.2 Trójstopniowa architektura i odpowiedzialności</h3>
<p>Rozwiązania AI opracowane przez Gosign wyróżniają trzy warstwy przetwarzania o różnych odpowiedzialnościach:</p>
<p>(a) <strong>Analiza (model AI):</strong> Model językowy analizuje dane i generuje propozycje. Modele AI dostarczają wyniki probabilistyczne; Gosign odpowiada za prawidłową integrację i konfigurację modelu, nie za merytoryczną poprawność każdego pojedynczego wyniku.</p>
<p>(b) <strong>Decyzja (Decision Layer):</strong> Decision Layer stosuje zdefiniowane zestawy reguł, progi i procesy zatwierdzania do wyników analizy. Gosign odpowiada za prawidłową implementację uzgodnionej logiki decyzyjnej. Błędy w implementacji reguł stanowią wady oprogramowania objęte rękojmią.</p>
<p>(c) <strong>Wykonanie (integracja/narzędzie):</strong> Wyniki przekazywane są do systemów docelowych Klienta (np. SAP, DATEV, Workday). Gosign odpowiada za prawidłową integrację techniczną. Błędy w systemie docelowym Klienta leżą po stronie Klienta.</p>
<h3>6.3 Human-in-the-Loop</h3>
<p>Dla decyzji zaklasyfikowanych jako wysokiego ryzyka (w szczególności decyzje personalne, decyzje płacowe, decyzje podlegające współdecydowaniu - Mitbestimmung), Human-in-the-Loop jest standardem, chyba że wyraźnie uzgodniono inaczej. Klasyfikacja decyzji wymagających zatwierdzenia ludzkiego jest ustalana wspólnie i konfigurowana w Decision Layer. Klient pozostaje odpowiedzialny za końcowe decyzje merytoryczne.</p>
<h3>6.4 Podejście model-agnostyczne</h3>
<p>Gosign wykorzystuje modele AI różnych dostawców (podejście model-agnostyczne). Wybór następuje w uzgodnieniu z Klientem. Gosign informuje o planowanych zmianach modelu. W przypadku zaprzestania świadczenia usług przez dostawcę, Gosign niezwłocznie zaproponuje równoważny model alternatywny. Gosign nie ponosi odpowiedzialności za dostępność lub zaprzestanie usług stron trzecich.</p>
<h3>6.5 Bias Monitoring</h3>
<p>W uzgodnionym zakresie Gosign implementuje mechanizmy wykrywania i dokumentowania systematycznych odchyleń (Bias Monitoring). Bieżąca weryfikacja w trakcie eksploatacji leży po stronie Klienta, chyba że obowiązuje umowa serwisowa.</p>
<h3>6.6 Wykorzystanie danych do celów AI</h3>
<p>Klient pozostaje właścicielem i administratorem wszystkich danych udostępnionych Gosign. Gosign wykorzystuje je wyłącznie do realizacji umowy. Klient zapewnia, że posiada wymagane uprawnienia. Jeśli wykorzystywane są zewnętrzne modele lub interfejsy API, odbywa się to wyłącznie na warunkach wykluczających wykorzystanie danych Klienta do trenowania modeli, chyba że Klient wyraźnie wyrazi na to zgodę.</p>
<h3>6.7 FinOps i koszty zależne od zużycia</h3>
<p>Koszty zależne od zużycia stron trzecich (opłaty za API, czas obliczeniowy GPU) ponosi Klient, chyba że uzgodniono inaczej. Gosign z wyprzedzeniem informuje o strukturze kosztów i dostarcza przejrzyste raporty zużycia.</p>
<h3>6.8 Wymogi regulacyjne</h3>
<p>Gosign adresuje wymogi Rozporządzenia (UE) 2024/1689 (EU AI Act) jako techniczne zasady architektoniczne (Readiness). Prawna ocena zgodności dla konkretnego kontekstu wdrożenia leży po stronie Klienta i jego doradców prawnych. Gosign wspiera Klienta we wdrażaniu wymogów regulacyjnych na zlecenie.</p>
<h3>6.9 Zwolnienie z odpowiedzialności (Indemnität)</h3>
<p>Korzystanie z systemów AI leży w wyłącznej odpowiedzialności Klienta. Klient zwalnia Gosign z roszczeń osób trzecich wynikających z niewłaściwego lub niezgodnego z prawem użytkowania.</p>

<h2>§ 7 Prawa użytkowania, własność intelektualna i dostęp do kodu źródłowego</h2>
<h3>7.1 Prawa użytkowania do indywidualnych rezultatów pracy</h3>
<p>Klient otrzymuje z chwilą pełnej zapłaty trwałe, nieograniczone terytorialnie, niewyłączne prawo użytkowania następujących indywidualnych rezultatów pracy:</p>
<p>(a) Konfiguracje indywidualne (zestawy reguł, Decision Tables, polityki, reguły routingu, modele danych specyficzne dla Klienta, tabele decyzyjne)</p>
<p>(b) Prompty i szablony promptów opracowane dla Klienta i oznaczone w Component Manifest jako indywidualne</p>
<p>(c) Integracje i adaptery indywidualne zgodnie z Component Manifest (np. indywidualne połączenia SAP, konektory API, teksty interfejsu użytkownika)</p>
<p>(d) Dokumentacja techniczna rozwiązania indywidualnego</p>
<p>(e) Dane i konfiguracje Klienta we wszystkich formatach</p>
<p>Przyporządkowanie do § 7.1 lub § 7.2 wynika z Component Manifest zgodnie z § 7.2 ust. 4.</p>
<p>Prawo użytkowania obejmuje prawo do modyfikacji i dalszego rozwoju na potrzeby własnej działalności gospodarczej Klienta.</p>
<p>Przekazanie osobom trzecim lub sublicencjonowanie wymaga uprzedniej pisemnej zgody Gosign. <strong>Zgody nie wymaga przekazanie Dopuszczalnym Odbiorcom Zewnętrznym.</strong> Dopuszczalnymi Odbiorcami Zewnętrznymi są:</p>
<p>(i) Przedsiębiorstwa powiązane z Klientem w rozumieniu §§ 15 i nast. AktG (niemieckiej ustawy o spółkach akcyjnych) lub porównywalnego zagranicznego prawa koncernowego (spółki koncernowe, spółki zależne, jednostki shared services)</p>
<p>(ii) Dostawcy usług IT i podmioty przetwarzające dane Klienta, działający na podstawie zobowiązania do zachowania poufności i ograniczenia celu przetwarzania</p>
<p>(iii) Biegli rewidenci, audyt wewnętrzny i organy regulacyjne w ramach ustawowych lub umownych obowiązków kontrolnych</p>
<p>(iv) Następcy prawni Klienta w przypadku restrukturyzacji, połączenia lub transakcji zbycia aktywów (Asset Deal), pod warunkiem że przekazanie następuje w ramach przeniesienia tej części działalności, w której rozwiązanie jest wykorzystywane, a następca prawny przejmuje obowiązki wynikające z § 7; wykluczone jest przekazanie bezpośrednim konkurentom Gosign</p>
<p>Klient zapewnia, że Dopuszczalni Odbiorcy Zewnętrzni przestrzegają co najmniej równoważnych obowiązków ochrony i zachowania poufności.</p>
<p>§ 7.1 ma pierwszeństwo przed ogólną regulacją cesji w § 19 w zakresie przekazywania Dopuszczalnym Odbiorcom Zewnętrznym lub następcom prawnym.</p>
<p>Klient ma najpóźniej od momentu wdrożenia rozwiązania w jego infrastrukturze, a w przeciwnym razie najpóźniej z chwilą odbioru lub pełnej zapłaty, pełny dostęp do kodu źródłowego wszystkich komponentów eksploatowanych w jego środowisku - w tym Komponentów Platformy zgodnie z § 7.2. Dostęp oznacza czytelny, celowo niezaciemniony kod źródłowy w repozytorium prowadzonym w środowisku Klienta lub jako eksport kodu (co najmniej po każdym wydaniu produkcyjnym oraz na żądanie w ciągu 10 dni roboczych), wraz z instrukcją kompilacji i plikami zależności (Dependency Lockfiles). Dodatkowe eksporty kodu poza regularnymi wydaniami realizowane są bezpłatnie do dwóch razy na kwartał; dalsze eksporty rozliczane są według nakładu pracy.</p>

<h3>7.2 Komponenty Platformy Gosign</h3>
<p>Gosign wykorzystuje przy tworzeniu rozwiązań własne Komponenty Platformy. Komponenty Platformy stanowią wielokrotnie wykorzystywany rdzeń techniczny, w szczególności Decision Engine, framework Rule Engine, architekturę Audit Trail oraz moduły orkiestracji (dalej "Komponenty Platformy"). Wyłączna własność intelektualna i prawo użytkowania Komponentów Platformy pozostają przy Gosign.</p>
<p>Klient otrzymuje <strong>trwałe prawo użytkowania danej dostarczonej wersji</strong> Komponentów Platformy (Perpetual License). Prawo użytkowania jest niewyłączne i obejmuje eksploatację, konfigurację i integrację z systemami Klienta na potrzeby własnej działalności gospodarczej. Prawo użytkowania istnieje niezależnie od obowiązywania umowy serwisowej. Zasady przekazywania z § 7.1 (w tym Dopuszczalni Odbiorcy Zewnętrzni i obowiązek przenoszenia zobowiązań - flow-down) stosuje się odpowiednio.</p>
<p>Klient ma od momentu wdrożenia (lub z chwilą odbioru/zapłaty zgodnie z § 7.1) pełny dostęp do kodu źródłowego wszystkich Komponentów Platformy eksploatowanych w jego infrastrukturze. Gosign udostępnia kompletną dokumentację techniczną wraz z instrukcją kompilacji. Kod źródłowy nie jest celowo zaciemniany (brak obfuskacji, brak celowego utrudniania czytelności). Szyfrowanie kodu źródłowego w stanie spoczynku i podczas transmisji w celu ochrony integralności pozostaje bez zmian.</p>
<p>Komponenty Platformy są w ofercie oznaczone w <strong>Component Manifest</strong>. Component Manifest <strong>wymienia co najmniej wszystkie istotne Komponenty Platformy</strong> i przyporządkowuje każdy komponent albo do § 7.1 (indywidualny), albo do § 7.2 (platformowy). Component Manifest jest miarodajny dla przyporządkowania. <strong>Zmiany w Component Manifest wymagają formy tekstowej i są uzgadniane jako aneks do oferty lub w ramach Change Request.</strong> Komponenty niewymienione w Manifest uznaje się za indywidualne w rozumieniu § 7.1, chyba że są komponentami open source lub stron trzecich albo są już wykorzystywane jako Komponenty Platformy w innych projektach klientów; doprecyzowanie w formie aneksu pozostaje możliwe.</p>
<p>Kod źródłowy Komponentów Platformy stanowi <strong>informację poufną i tajemnicę przedsiębiorstwa Gosign</strong> w rozumieniu § 14. Klient może przeglądać kod źródłowy, wykorzystywać go do celów umownych i przekazywać Dopuszczalnym Odbiorcom Zewnętrznym zgodnie z § 7.1 z zachowaniem obowiązku przenoszenia zobowiązań (flow-down). Dalsze wykorzystanie, przekazanie lub komercjalizacja jest niedopuszczalna. Klient chroni kod źródłowy Komponentów Platformy co najmniej z taką samą starannością jak własne tajemnice przedsiębiorstwa.</p>
<p>Klient nie może wykorzystywać Komponentów Platformy, w tym kodu źródłowego i wiedzy z niego pozyskanej, do tworzenia, wprowadzania na rynek lub świadczenia produktu lub usługi konkurującej z Gosign ani do komercjalizacji na rzecz osób trzecich.</p>

<h3>7.3 Source Code Escrow</h3>
<p>Na życzenie Klienta Gosign deponuje kompletny kod źródłowy wszystkich Komponentów Platformy, wraz z instrukcją kompilacji, plikami zależności (Dependency Lockfiles) i dokumentacją wdrożeniową, u niezależnego depozytariusza (Escrow-Dienstleister). Koszty depozytu ponosi Klient, chyba że w ofercie uzgodniono inaczej.</p>
<p>Gosign przyznaje Klientowi już przy zawarciu umowy, pod warunkiem zawieszającym wystąpienia danego zdarzenia, wszelkie prawa użytkowania do Komponentów Platformy, w tym prawo do modyfikacji, dalszego rozwoju i samodzielnej eksploatacji. Warunek zawieszający spełnia się w następujących przypadkach:</p>
<p>(a) Wniosek o ogłoszenie upadłości Gosign (otwarcie postępowania lub oddalenie z powodu braku masy upadłościowej)</p>
<p>(b) <strong>Zaprzestanie wsparcia produktowego:</strong> Gosign nie udostępnia dla wykorzystywanych Komponentów Platformy aktualizacji bezpieczeństwa w ciągu 90 dni kalendarzowych od ujawnienia krytycznej luki, nie oferując w tym czasie równoważnego rozwiązania zastępczego, lub oficjalnie ogłasza zakończenie cyklu życia komponentu (End-of-Life). Za krytyczną lukę w rozumieniu niniejszej klauzuli uznaje się lukę bezpieczeństwa sklasyfikowaną jako wysoka lub krytyczna według międzynarodowo uznanych standardów (w szczególności CVSS). Szczegółowe kryteria mogą zostać ustalone w umowie depozytowej. Równoważne rozwiązanie zastępcze obejmuje co najmniej podstawowe funkcje zastępowanego komponentu i zapewnia porównywalny poziom bezpieczeństwa. Szczegółowe wymagania mogą zostać ustalone w umowie depozytowej.</p>
<p>(c) Istotne naruszenie umowy przez Gosign, które nie zostało usunięte pomimo pisemnego wyznaczenia terminu 60 dni kalendarzowych.</p>
<p>Szczegóły techniczne deponowania, aktualizacji i wydania reguluje odrębna umowa depozytowa pomiędzy Gosign, Klientem i depozytariuszem. Obejmuje ona w szczególności: zakres depozytu (repozytorium, klucze, łańcuch kompilacji, dokumentacja, zależności), częstotliwość aktualizacji, warunki wydania, prawo Klienta do weryfikacji oraz mechanikę wydania.</p>

<h3>7.4 Komponenty open source</h3>
<p>Gosign w miarę możliwości stosuje oprogramowanie open source. Prawa Klienta do komponentów open source podlegają odpowiednim warunkom licencyjnym (np. MIT, Apache, GPL). Gosign dostarcza Klientowi zestawienie wykorzystanych komponentów open source i ich licencji (Software Bill of Materials). Klient zobowiązuje się do przestrzegania tych warunków licencyjnych. Jeśli indywidualny kod bazuje na komponentach open source i może przez to podlegać ich warunkom licencyjnym, Gosign poinformuje o tym Klienta.</p>
<p>Gosign nie stosuje komponentów objętych licencjami copyleft (w szczególności GPL, AGPL), chyba że są one wyraźnie wskazane w ofercie i zaakceptowane przez Klienta.</p>

<h3>7.5 Komponenty wielokrotnego użytku i izolacja mandantów</h3>
<p>Gosign stale rozwija Komponenty Platformy i wykorzystuje je w projektach dla różnych Klientów. Konfiguracje indywidualne, tajemnice przedsiębiorstwa i dane Klienta nie są przenoszone do innych projektów.</p>
<p>Architektura techniczna zapewnia zgodnie z aktualnym stanem techniki, poprzez izolację mandantów, ścisłą separację danych Klientów. Obejmuje to w szczególności separację na poziomie danych, logów, historii promptów, pamięci masowej i kluczy specyficznych dla mandanta. Gosign dokumentuje architekturę izolacji na żądanie.</p>

<h3>7.6 Ograniczone prawo użytkowania (alternatywa dla projektów czysto programistycznych)</h3>
<p>Jeśli w ofercie nie przewidziano ani Komponentów Platformy, ani Component Manifest (w szczególności przy projektach czysto programistycznych bez wykorzystania Decision Layer), Klient otrzymuje trwałe, nieograniczone terytorialnie, niewyłączne prawo użytkowania do indywidualnych opracowań. Prawo użytkowania obejmuje prawo do modyfikacji i dalszego rozwoju na potrzeby własnej działalności gospodarczej. Zasady przekazywania zgodnie z § 7.1 ust. 3 (w tym Dopuszczalni Odbiorcy Zewnętrzni i obowiązek przenoszenia zobowiązań - flow-down) stosuje się odpowiednio.</p>

<h3>7.7 Opłaty licencyjne i utrzymanie</h3>
<p>Za indywidualne rezultaty pracy (§ 7.1) nie są naliczane bieżące opłaty licencyjne.</p>
<p>Dla Komponentów Platformy Gosign (§ 7.2) obowiązuje: Prawo użytkowania dostarczonej wersji (Perpetual License) jest <strong>objęte wynagrodzeniem uzgodnionym w ofercie</strong>. Dalsze bieżące opłaty powstają wyłącznie, gdy zostały wyraźnie wskazane w ofercie.</p>
<p>Dla <strong>bieżącego utrzymania, aktualizacji bezpieczeństwa i dalszego rozwoju</strong> Komponentów Platformy może zostać zawarta roczna umowa serwisowa (Maintenance). Rodzaj, zakres, czasy reakcji i wysokość opłat serwisowych są przejrzyście wykazane w danej ofercie.</p>
<p><strong>W przypadku wypowiedzenia umowy serwisowej przez Klienta, prawo użytkowania ostatniej dostarczonej wersji pozostaje w pełni zachowane.</strong> Klient nie otrzymuje wówczas dalszych aktualizacji, poprawek bezpieczeństwa ani wsparcia technicznego dla Komponentów Platformy. Gosign zaleca w takim przypadku zawarcie umowy depozytowej kodu źródłowego (Source Code Escrow) zgodnie z § 7.3.</p>
<p>Bez wyraźnego uzgodnienia w ofercie nie powstają żadne bieżące opłaty.</p>

<h3>7.8 Modyfikacje Klienta w Komponentach Platformy</h3>
<p>Klient ma prawo modyfikować Komponenty Platformy na potrzeby własnej działalności gospodarczej. Gosign w miarę możliwości udostępnia udokumentowane punkty rozszerzenia (Extension Points), umożliwiające zmiany bez ingerencji w rdzeń platformy.</p>
<p>Jeśli Klient dokona zmian w Komponentach Platformy <strong>poza udokumentowanymi punktami rozszerzenia (Extension Points)</strong>, rękojmia i prawo do wsparcia technicznego dla dotkniętych części wygasają do momentu, gdy (a) zmiany zostaną cofnięte lub (b) Gosign przeprowadzi płatną analizę i potwierdzi kompatybilność.</p>
<p><strong>Klient współpracuje w rozsądnym zakresie w celu zapewnienia, że aktualizacje bezpieczeństwa Gosign mogą być wdrażane również przy istniejących modyfikacjach Klienta.</strong> Jeśli Klient odmówi wymaganej współpracy lub jego modyfikacje uniemożliwią wdrożenie aktualizacji bezpieczeństwa, Gosign jest uprawniony do zawieszenia wsparcia dla dotkniętych komponentów do czasu usunięcia blokady. Blokada ma miejsce, gdy aktualizacja nie może zostać wdrożona przy rozsądnym nakładzie pracy, ponieważ zmiany Klienta dokonane poza Extension Points naruszają kompatybilność.</p>
<p>Obowiązki Klienta w zakresie bezpieczeństwa zgodnie z § 9 pozostają nienaruszone przez modyfikacje.</p>

<h3>7.9 Wkład Klienta w Komponenty Platformy</h3>
<p>Jeśli przewidziano to w ofercie lub w odrębnym uzgodnieniu, Klient może zgłaszać poprawki błędów, propozycje ulepszeń lub rozszerzenia dla Komponentów Platformy ("Wkłady").</p>
<p>Klient udziela Gosign prostego, niewyłącznego, nieograniczonego czasowo i terytorialnie prawa użytkowania takich Wkładów, o ile dotyczą one Komponentów Platformy i nie zawierają tajemnic przedsiębiorstwa ani konfiguracji indywidualnych Klienta. Gosign może włączyć te Wkłady do Komponentów Platformy i udostępnić je wszystkim Klientom.</p>
<p>Niniejsza klauzula nie ustanawia obowiązku Klienta do zgłaszania Wkładów.</p>

<h3>7.10 Termin przekazania</h3>
<p>Przekazanie rezultatów pracy (w tym repozytorium kodu źródłowego, dokumentacji, Component Manifest, konfiguracji i Software Bill of Materials) następuje najpóźniej z odbiorem ostatniej fazy projektu i pełną zapłatą. Gosign aktywnie wesprze przekazanie i zapewni Klientowi pełny dostęp.</p>

<h2>§ 8 Hosting i usługi operacyjne</h2>
<p>Regularna eksploatacja rozwiązań opracowanych przez Gosign odbywa się w infrastrukturze Klienta. Hosting przez Gosign jest opcjonalną usługą dodatkową. Jeśli Klient korzysta z hostingu, obowiązują następujące warunki:</p>
<p><strong>Managed Services w infrastrukturze Klienta:</strong> Jeśli Gosign eksploatuje rozwiązanie w środowisku chmurowym Klienta, postanowienia dotyczące hostingu stosuje się odpowiednio. Odpowiedzialność za infrastrukturę bazową pozostaje po stronie Klienta. Gosign odpowiada za warstwę aplikacyjną.</p>
<p><strong>Centrum danych:</strong> Hosting odbywa się w Niemczech lub UE, chyba że uzgodniono inaczej. Preferencje Klienta należy zgłosić przy zawieraniu umowy.</p>
<p><strong>Dostępność:</strong> Bez SLA brak gwarancji minimalnej dostępności. Gosign dąży do wysokiej dostępności.</p>
<p><strong>Okna serwisowe:</strong> Planowane prace serwisowe poza godzinami pracy z wcześniejszym powiadomieniem.</p>
<p><strong>Kopie zapasowe:</strong> Codzienne kopie zapasowe, 7-dniowa retencja rotacyjna, chyba że uzgodniono inaczej.</p>
<p><strong>Transition i exit:</strong> Po zakończeniu usług hostingowych Gosign wspiera Klienta przez do 90 dni przy migracji (Transition). Transition rozliczana jest według nakładu pracy. Wszystkie dane Klienta są w pełni eksportowalne w standardowych formatach.</p>

<h2>§ 9 Bezpieczeństwo, utrzymanie i aktualizacje</h2>
<p><strong>Obowiązkowe aktualizacje bezpieczeństwa:</strong> Gosign może instalować aktualizacje bezpieczeństwa bez uprzedniej zgody Klienta, jeśli zwłoka zagrażałaby bezpieczeństwu. Klient jest informowany po fakcie.</p>
<p><strong>Obowiązek tolerancji:</strong> Klient nie może odmówić aktualizacji bezpieczeństwa. Bezpieczeństwo i integralność systemu mają pierwszeństwo.</p>
<p><strong>Odmowa:</strong> W przypadku odmowy wdrożenia środka bezpieczeństwa Gosign może zawiesić świadczenie usług. Roszczenia Klienta z tytułu wynikłych szkód są wyłączone.</p>
<p><strong>Aktualizacje opcjonalne:</strong> Aktualizacje niezwiązane z bezpieczeństwem tylko po uzgodnieniu.</p>
<p><strong>Testy penetracyjne:</strong> Klient może przeprowadzać audyty bezpieczeństwa lub testy penetracyjne z wyprzedzeniem co najmniej 14 dni kalendarzowych, pod warunkiem zachowania poufności. Szczegóły mogą być regulowane w SLA.</p>
<p><strong>Reakcja na incydenty (Incident Response):</strong> W przypadku incydentu bezpieczeństwa zagrażającego dostępności, integralności lub poufności danych lub systemów Klienta, Gosign informuje Klienta niezwłocznie, najpóźniej w ciągu 24 godzin od powzięcia wiadomości, i podejmuje natychmiastowe działania zaradcze. Pierwsze powiadomienie i działania natychmiastowe stanowią część usługi umownej. Dalsze usługi (w szczególności analiza kryminalistyczna, ustalenie przyczyny źródłowej i przygotowanie szczegółowego raportu o incydencie) rozliczane są według nakładu pracy, chyba że incydent wynika z winy Gosign. Jeśli Gosign ponosi odpowiedzialność za incydent, wszystkie działania analityczne i naprawcze realizowane są dla Klienta bezpłatnie.</p>

<h2>§ 10 Wynagrodzenie i warunki płatności</h2>
<p>Ceny wynikają z oferty, powiększone o podatek VAT.</p>
<p>Rozliczenie według nakładu pracy lub ryczałtu zgodnie z uzgodnieniem.</p>
<p>Koszty dodatkowe i podróży tylko po wcześniejszym uzgodnieniu.</p>
<p><strong>Termin płatności:</strong> 14 dni kalendarzowych, chyba że uzgodniono inaczej. Indywidualne terminy płatności mogą być uzgodnione. Odsetki za zwłokę: 9 punktów procentowych powyżej stopy bazowej (§ 288 ust. 2 BGB).</p>
<p>Zaliczki przy dłuższych projektach zgodnie z planem kamieni milowych.</p>
<p>Potrącenie tylko z niespornymi lub prawomocnie stwierdzonymi wierzytelnościami wzajemnymi.</p>

<h2>§ 11 Odpowiedzialność</h2>
<p><strong>Nieograniczona:</strong> W przypadku winy umyślnej, rażącego niedbalstwa, naruszenia życia/ciała/zdrowia, gwarancji, odpowiedzialności za produkt.</p>
<p><strong>Obowiązki kardynalne (wesentliche Vertragspflichten):</strong> W przypadku lekkiego niedbalstwa ograniczona do typowo przewidywalnej szkody.</p>
<p><strong>Górna granica odpowiedzialności:</strong> Odpowiedzialność Gosign za szkody z naruszenia obowiązków kardynalnych jest ograniczona na incydent do wysokości wynagrodzenia netto uzgodnionego w danej umowie jednostkowej. Łączna odpowiedzialność Gosign ze stosunku umownego jest ograniczona do dwukrotności rocznego wynagrodzenia netto. Odmienne górne granice odpowiedzialności mogą być uzgodnione w umowach jednostkowych.</p>
<p><strong>Szkody pośrednie, następcze i utracone korzyści:</strong> Wyłączone, z wyjątkiem winy umyślnej, rażącego niedbalstwa lub naruszenia obowiązków kardynalnych.</p>
<p><strong>Utrata danych:</strong> Odpowiedzialność wyłącznie za koszty odtworzenia z prawidłowych kopii zapasowych Klienta.</p>
<p><strong>Wyniki AI:</strong> Brak odpowiedzialności za decyzje oparte na wynikach AI, o ile Gosign nie naruszył obowiązków kardynalnych (patrz § 6.2).</p>
<p><strong>Ubezpieczenie:</strong> Gosign utrzymuje rynkowe ubezpieczenie odpowiedzialności cywilnej działalności gospodarczej i zawodowej. Dowód na żądanie.</p>
<p><strong>Przedawnienie:</strong> Dwa lata; nie dotyczy winy umyślnej, rażącego niedbalstwa lub szkód osobowych.</p>

<h2>§ 12 Roszczenia z tytułu wad (rękojmia - Gewährleistung)</h2>
<p><strong>Okres rękojmi:</strong> 12 miesięcy od odbioru za wady fizyczne i prawne.</p>
<p>Wady należy niezwłocznie zgłosić w formie tekstowej. Usunięcie wad poprzez naprawę lub dostarczenie zamiennika.</p>
<p>Niepowodzenie po dwóch próbach: Obniżenie ceny lub odstąpienie od umowy.</p>
<p>Brak rękojmi za nieistotne odchylenia lub zakłócenia spowodowane przez Klienta.</p>
<p>Błędy w oprogramowaniu open source lub stron trzecich nie stanowią wady usługi Gosign, o ile prawidłowo zintegrowane.</p>
<p>Rękojmia za Komponenty Platformy podlega ograniczeniom zgodnie z § 7.8 (modyfikacje Klienta).</p>
<p>W przypadku umów o charakterze ciągłym: Obowiązują przepisy ustawowe dotyczące umów o świadczenie usług/najmu.</p>

<h2>§ 13 Ochrona danych i przetwarzanie danych</h2>
<p>Obie strony przestrzegają RODO, niemieckiej ustawy o ochronie danych (BDSG) i innych mających zastosowanie przepisów o ochronie danych.</p>
<p>Jeśli Klient przetwarza dane podlegające brazylijskiej LGPD lub innym międzynarodowym przepisom o ochronie danych, Gosign wspiera w zapewnieniu zgodności.</p>
<p>Gosign działa jako podmiot przetwarzający (Art. 28 RODO). Strony zawrą umowę o powierzeniu przetwarzania danych (Auftragsverarbeitungsvertrag - AVV).</p>
<p>Gosign akceptuje również umowy o przetwarzaniu danych dostarczone przez Klienta, pod warunkiem ich zgodności z RODO.</p>
<p>Gosign wdraża odpowiednie środki techniczne i organizacyjne (Art. 32 RODO).</p>
<p>Podprzetwarzający za ogólną zgodą, pod warunkiem umownego zobowiązania do równoważnego poziomu ochrony danych.</p>
<p><strong>Data Residency:</strong> Na życzenie umowne zapewnienie, że przetwarzanie danych odbywa się wyłącznie w Niemczech lub określonym państwie UE/EOG. W przypadku wywołań API AI do państw trzecich - wcześniejsza informacja i, o ile technicznie wykonalne, europejskie punkty końcowe.</p>
<p>W przypadku naruszeń ochrony danych: Niezwłoczna informacja i współpraca przy obowiązkach zgłoszeniowych.</p>

<h2>§ 14 Poufność</h2>
<p>Obie strony traktują informacje poufne jako ściśle poufne.</p>
<p><strong>Wyjątki:</strong> Publicznie znane, wcześniej znane, niezależnie opracowane, obowiązek ustawowy.</p>
<p><strong>Ujawnianie:</strong> Wyłącznie na zasadzie need-to-know, pracownikom zobowiązanym do zachowania poufności.</p>
<p><strong>Standard ochrony:</strong> Obie strony chronią informacje poufne co najmniej tak jak własne tajemnice przedsiębiorstwa, jednak co najmniej poprzez odpowiednie środki techniczne i organizacyjne zgodne z aktualnym stanem techniki.</p>
<p><strong>Okres obowiązywania:</strong> 5 lat po zakończeniu umowy. Dla informacji oznaczonych jako tajemnice przedsiębiorstwa (w szczególności zgodnie z § 7.2 ust. 5) obowiązek zachowania poufności trwa po zakończeniu umowy bezterminowo.</p>
<p><strong>Zwrot i zniszczenie:</strong> Na żądanie, najpóźniej przy zakończeniu umowy.</p>
<p><strong>Referencje:</strong> Gosign może wykorzystywać nazwę i logo Klienta jako referencję wyłącznie za uprzednią pisemną zgodą Klienta.</p>

<h2>§ 15 Czas trwania umowy i wypowiedzenie</h2>
<p>15.1 Umowy projektowe kończą się wraz z odbiorem ostatniego świadczenia i pełną zapłatą.</p>
<p>15.2 Umowy o charakterze ciągłym: Minimalny okres obowiązywania 12 miesięcy. Następnie automatyczne przedłużenie o kolejne 12 miesięcy, z możliwością wypowiedzenia z 3-miesięcznym wyprzedzeniem na koniec bieżącego okresu.</p>
<p>15.2a Dla umów serwisowych zgodnie z § 7.7 (Maintenance) stosuje się odpowiednio regulacje dotyczące umów o charakterze ciągłym zgodnie z ust. 2, chyba że w umowie serwisowej uzgodniono odmienne okresy obowiązywania i terminy wypowiedzenia.</p>
<p>15.3 Wypowiedzenie nadzwyczajne w przypadku: (a) istotnego naruszenia obowiązku po 30-dniowym okresie naprawczym; (b) upadłości; (c) trwałej odmowy aktualizacji (§ 9); (d) niezgodnego z prawem korzystania z systemu.</p>
<p>15.4 Skutki zakończenia: Zwrot/usunięcie wszystkich danych Klienta. Transition zgodnie z § 8. Nabyte prawa użytkowania pozostają w mocy po pełnej zapłacie.</p>

<h2>§ 16 Zgodność, certyfikacje i współdecydowanie</h2>
<p><strong>16.1 Cert-Ready:</strong> Gosign projektuje swoje rozwiązania tak, aby spełniały techniczne wymagania wstępne dla branżowych certyfikacji (Cert-Ready by Design). Konkretnie oznacza to: Controls są zaimplementowane jako obiekty danych pierwszej klasy w systemie, Evidence generowane jest automatycznie, Audit Trail jest kompletny i eksportowalny, a dostęp przez Auditor Portal jest przewidziany. Uzyskanie konkretnego certyfikatu nie jest zobowiązanym rezultatem i wymaga odrębnego uzgodnienia między Klientem, audytorem i Gosign.</p>
<p><strong>16.2 Rada zakładowa i współdecydowanie:</strong> Jeśli rozwiązania AI wdrażane są w obszarach podlegających współdecydowaniu (§ 87 ust. 1 nr 6 BetrVG), Gosign wspiera w przygotowaniu dokumentacji i materiałów informacyjnych dla rady zakładowej. Formalne włączenie rady zakładowej i zawarcie porozumień zakładowych leżą w odpowiedzialności Klienta. Architektura Decision Layer jest zaprojektowana tak, aby odwzorowywać porozumienia zakładowe jako konfigurowalne, technicznie egzekwowalne reguły.</p>
<p><strong>16.3 Zgodność z sankcjami:</strong> Gosign oświadcza, że nie utrzymuje relacji biznesowych z osobami, podmiotami lub państwami objętymi sankcjami.</p>
<p><strong>16.4 Zrównoważony rozwój:</strong> Gosign uwzględnia aspekty efektywności energetycznej przy wyborze infrastruktury. Informacje na żądanie.</p>

<h2>§ 17 Kontrola eksportu</h2>
<p>Klient przestrzega przepisów eksportowych i sankcyjnych. Gosign wskazuje komponenty podlegające kontroli eksportu. Realizacja zastrzeżona jest brakiem przeszkód prawnych.</p>

<h2>§ 18 Siła wyższa</h2>
<p>Brak odpowiedzialności za niewykonanie z powodu siły wyższej (klęski żywiołowe, wojna, pandemie, strajki, działania władz, awarie infrastruktury na dużą skalę). Niezwłoczne powiadomienie. Terminy ulegają odpowiedniemu przedłużeniu. Prawo odstąpienia po 3 miesiącach.</p>

<h2>§ 19 Postanowienia końcowe</h2>
<p><strong>Prawo właściwe:</strong> Prawo niemieckie z wyłączeniem Konwencji Narodów Zjednoczonych o umowach międzynarodowej sprzedaży towarów (CISG).</p>
<p><strong>Właściwość sądowa:</strong> Hamburg (dla kupców i osób prawnych).</p>
<p><strong>Język umowy:</strong> Niemiecki. Wersje w innych językach służą międzynarodowej współpracy; w razie wątpliwości obowiązuje wersja niemiecka.</p>
<p><strong>Wersjonowanie:</strong> Niniejsze OWH posiadają numer wersji i datę. Aktualna wersja dostępna pod adresem gosign.de/de/agb/.</p>
<p>Zmiany w formie tekstowej. Zmiany OWH z 6-tygodniowym wyprzedzeniem; okres sprzeciwu 4 tygodnie.</p>
<p><strong>Cesja:</strong> Cesja tylko za pisemną zgodą. Przekazywanie Dopuszczalnym Odbiorcom Zewnętrznym i następcom prawnym zgodnie z § 7.1 ust. 3 pozostaje nienaruszone.</p>
<p>Klauzula salwatoryjna (salvatorische Klausel). Pierwszeństwo indywidualnych uzgodnień.</p>

--- Strona zhakowana? 10 przyczyn i pomoc ---
> Dlaczego strony są hakowane: 10 najczęstszych przyczyn i co możesz natychmiast zrobić. Pomoc awaryjna od Gosign.

<!-- Co robić? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Co robić, gdy strona została zhakowana?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Gdy Twoja strona została zhakowana, liczy się szybkość: usunąć malware, znaleźć punkt wejścia, zamknąć lukę, poinformować Google o naprawie. Gosign oferuje wsparcie awaryjne dla zhakowanych stron - WordPress, TYPO3 i inne systemy CMS. Ten artykuł wyjaśnia 10 najczęstszych przyczyn włamań na strony i jak się przed nimi chronić.
</p>
</div>
</section>

<!-- 10 przyczyn -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">10 najczęstszych przyczyn, dlaczego strony są hakowane</h2>

<div class="space-y-8">
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">1. Przestarzała wersja CMS</h3>
<p class="text-body text-gosign-text leading-relaxed">
WordPress 5.x, TYPO3 v9, Joomla 3: stare wersje CMS mają znane, udokumentowane luki bezpieczeństwa. Atakujący automatycznie skanują w poszukiwaniu przestarzałych instalacji. Rozwiązanie: zawsze aktualna wersja LTS, automatyczne aktualizacje bezpieczeństwa.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">2. Niebezpieczne wtyczki/rozszerzenia</h3>
<p class="text-body text-gosign-text leading-relaxed">
Wystarczy jedna przestarzała wtyczka. Gosign monitoruje ponad 800 rozszerzeń TYPO3 i zna kandydatów wysokiego ryzyka. W przypadku WordPress: tylko wtyczki z zaufanych źródeł, regularne aktualizacje, nieużywane wtyczki usuwać (nie tylko dezaktywować).
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">3. Słabe hasła</h3>
<p class="text-body text-gosign-text leading-relaxed">
"admin/admin123" wciąż jest zaskakująco częste. Ataki brute-force próbują tysięcy kombinacji na minutę. Rozwiązanie: silne hasła + uwierzytelnianie dwuskładnikowe + ograniczenie prób logowania.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">4. Brak SSL/HTTPS</h3>
<p class="text-body text-gosign-text leading-relaxed">
Bez HTTPS dane logowania są przesyłane tekstem jawnym. Każda strona potrzebuje certyfikatu SSL. W 2026 roku nie ma na to wymówek.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">5. Niebezpieczny hosting</h3>
<p class="text-body text-gosign-text leading-relaxed">
Hosting współdzielony z setkami stron na jednym serwerze: zhakowanie jednej zagraża wszystkim. Rozwiązanie: hosting zarządzany z izolacją, automatycznymi kopiami zapasowymi i Web Application Firewall.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">6. Brak Web Application Firewall (WAF)</h3>
<p class="text-body text-gosign-text leading-relaxed">
WAF blokuje znane wzorce ataków (SQL Injection, XSS, File Inclusion), zanim dotrą do Twojej aplikacji. Cloudflare WAF, ModSecurity lub rozwiązania komercyjne.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">7. Brak kopii zapasowych</h3>
<p class="text-body text-gosign-text leading-relaxed">
Brak kopii zapasowej = brak koła ratunkowego. Codzienne kopie zapasowe, przechowywane oddzielnie od serwera, regularnie testowane. Kopia zapasowa, której nie da się przywrócić, nie jest kopią zapasową.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">8. Niebezpieczne przesyłanie plików</h3>
<p class="text-body text-gosign-text leading-relaxed">
Formularze uploadu bez walidacji pozwalają atakującym wgrywać powłoki PHP. Rozwiązanie: ścisła kontrola typów plików, przechowywanie uploadów poza katalogiem webroot, losowe nazwy plików.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">9. SQL Injection</h3>
<p class="text-body text-gosign-text leading-relaxed">
Niefiltrowane dane użytkowników w zapytaniach do bazy danych pozwalają atakującym odczytać lub manipulować całą bazę. Rozwiązanie: Prepared Statements, walidacja danych wejściowych, użycie ORM.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">10. Brak monitoringu</h3>
<p class="text-body text-gosign-text leading-relaxed">
Jeśli nikt nie patrzy, nikt nie zauważy włamania. Niektóre włamania pozostają niewykryte przez miesiące (spam injection, kopanie kryptowalut, przekierowania). Rozwiązanie: monitoring dostępności, monitoring integralności plików, regularne skanowanie malware.
</p>
</div>
</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Strona zhakowana? Gosign pomoże. Konsultacja awaryjna dostępna.</h3>
<p class="text-body text-gosign-text mb-6">Szybka analiza, naprawa i zabezpieczenie Twojej strony.</p>
<a
href="/pl/kontakt/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Zgłoś potrzebę pomocy
</a>
<p class="text-small text-gosign-text-light mt-4">25 lat doświadczenia · 800+ rozszerzeń · rozwój wspomagany AI</p>
</div>
</section>

<!-- Lista kontrolna -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Lista kontrolna: natychmiastowe działania po włamaniu</h2>
<ol class="space-y-3">
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 flex items-center justify-center bg-gosign-accent text-white font-bold rounded-full text-small">1</span>
<span class="text-body text-gosign-text pt-1">Wyłączyć stronę (tryb konserwacji)</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 flex items-center justify-center bg-gosign-accent text-white font-bold rounded-full text-small">2</span>
<span class="text-body text-gosign-text pt-1">Zmienić hasła (CMS, FTP, baza danych, hosting)</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 flex items-center justify-center bg-gosign-accent text-white font-bold rounded-full text-small">3</span>
<span class="text-body text-gosign-text pt-1">Zabezpieczyć kopię zapasową (aktualny stan do analizy)</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 flex items-center justify-center bg-gosign-accent text-white font-bold rounded-full text-small">4</span>
<span class="text-body text-gosign-text pt-1">Zidentyfikować ostatnią czystą kopię zapasową</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 flex items-center justify-center bg-gosign-accent text-white font-bold rounded-full text-small">5</span>
<span class="text-body text-gosign-text pt-1">Przeprowadzić skanowanie malware</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 flex items-center justify-center bg-gosign-accent text-white font-bold rounded-full text-small">6</span>
<span class="text-body text-gosign-text pt-1">Zidentyfikować punkt wejścia (sprawdzić logi)</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 flex items-center justify-center bg-gosign-accent text-white font-bold rounded-full text-small">7</span>
<span class="text-body text-gosign-text pt-1">Naprawić i zamknąć lukę</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 flex items-center justify-center bg-gosign-accent text-white font-bold rounded-full text-small">8</span>
<span class="text-body text-gosign-text pt-1">Przywrócić stronę do działania</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 flex items-center justify-center bg-gosign-accent text-white font-bold rounded-full text-small">9</span>
<span class="text-body text-gosign-text pt-1">Google Search Console: wniosek o ponowną weryfikację</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 flex items-center justify-center bg-gosign-accent text-white font-bold rounded-full text-small">10</span>
<span class="text-body text-gosign-text pt-1">Wdrożyć monitoring, aby zapobiec kolejnym włamaniom</span>
</li>
</ol>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
Gosign to hamburska agencja cyfrowa z 25-letnim doświadczeniem w tworzeniu stron, TYPO3 i integracji AI.
Obsługujemy europejskie i polskie przedsiębiorstwa z naszej siedziby w Hamburgu.
Przeanalizowaliśmy ponad 800 rozszerzeń TYPO3 i dzięki wsparciu AI realizujemy projekty
do 70&nbsp;% szybciej niż tradycyjnymi metodami.
</p>
<p class="text-small text-gosign-text-light mt-2">Stan na: luty 2026</p>
</div>
</section>

<!-- Powiązane tematy -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Powiązane tematy</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/pl/bezpieczenstwo-stron-standardy/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Bezpieczeństwo</p>
<p class="text-body font-semibold text-gosign-dark">Bezpieczeństwo stron - standardy NIS2</p>
</a>
<a href="/pl/typo3-monitor-bezpieczenstwa/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Monitoring</p>
<p class="text-body font-semibold text-gosign-dark">Monitor bezpieczeństwa TYPO3</p>
</a>
<a href="/pl/agencja-wordpress/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Tworzenie stron</p>
<p class="text-body font-semibold text-gosign-dark">Agencja WordPress Hamburg</p>
</a>
</div>
</div>
</section>

--- a21glossary TYPO3 - Słownik fachowy | Gosign ---
> Rozszerzenie słownika dla TYPO3: Definiowanie terminów, automatyczne linkowanie w treści, wyświetlanie jako tooltip.

## Kto potrzebuje słownika, ten zwykle ma problem z SEO

Wyjaśnianie terminów fachowych na stronie internetowej brzmi jak serwis dla użytkownika. W rzeczywistości a21glossary rozwiązuje konkretny problem techniczny: strony TYPO3 z treściami wymagającymi objaśnień osiągają lepsze pozycje w wynikach wyszukiwania, gdy pojęcia są wewnętrznie linkowane, indeksowane jako osobne strony i natychmiast dostępne przez tooltip. Rozszerzenie automatycznie tworzy powiązania w treści na podstawie centralnej bazy pojęć, bez konieczności ręcznego ustawiania każdego linku przez redaktorów.

Dla przedsiębiorstw z portalami fachowymi, platformami wiedzy lub produktami wymagającymi objaśnień a21glossary tworzy dokładnie tę strukturę linkowania wewnętrznego, którą Google interpretuje jako autorytet tematyczny. Zamiast ukrywać 50 pojęć w jednym FAQ, powstaje 50 samodzielnych, indeksowalnych stron z potencjałem Schema Markup.

## Typowe scenariusze zastosowania

**Portale fachowe z ponad 100 pojęciami.** Stowarzyszenia branżowe, uczelnie wyższe i wydawnictwa specjalistyczne utrzymują słowniki z setkami wpisów. a21glossary automatycznie linkuje każdy termin przy pierwszym wystąpieniu w tekście. U jednego klienta z 340 wpisami słownikowymi gęstość linkowania wewnętrznego wzrosła o 28%, co było mierzalne w Google Search Console.

**Strony produktowe z technicznym słownictwem.** Producenci maszyn, firmy chemiczne i producenci sprzętu medycznego używają fachowego języka, którego kupujący i decydenci nie zawsze znają. Tooltip z 2-3 zdaniami wyjaśnienia utrzymuje czytelnika na stronie, zamiast odsyłać go do Google. Czas spędzony na stronie rośnie, współczynnik odrzuceń spada.

**Wielojęzyczne platformy wiedzy.** W połączeniu z obsługą języków TYPO3 słowniki można prowadzić osobno dla każdego języka. Polskie pojęcia linkują do polskich objaśnień, angielskie do angielskich. Działa to poprawnie, pod warunkiem że konfiguracja językowa w TYPO3 jest prawidłowo ustawiona.

## Architektura techniczna

a21glossary działa jako post-procesor treści. Po wyrenderowaniu strony TYPO3 rozszerzenie przeszukuje wyjście HTML w poszukiwaniu zdefiniowanych pojęć i zastępuje je wersjami z linkami. Same pojęcia są przechowywane w osobnej tabeli bazy danych i zarządzane przez moduł backendu.

Rozszerzenie rejestruje się przez Content Object Post User Func Hook w procesie renderowania TypoScript. Oznacza to, że ingeruje dopiero po pełnym wyrenderowaniu treści przez TYPO3. Dzięki temu działa niezależnie od typu elementu treści - czy to Textmedia, News czy Custom Content Elements.

Wyświetlanie tooltipów odbywa się przez niewielki fragment JavaScript i CSS. Oba są konfigurowalne. W nowoczesnych instalacjach TYPO3 zaleca się zastąpienie standardowego JavaScriptu rozwiązaniem opartym wyłącznie na CSS, aby nie obciążać Core Web Vitals. Za pomocą atrybutu `title` i selektora `:hover` można zrealizować proste tooltipy bez ani jednej linii JavaScriptu.

Wpisy słownika są konfigurowalne przez TypoScript: które strony mają być przeszukiwane, ile razy termin może być linkowany na stronie (zalecenie: jeden raz) oraz które obszary HTML są wykluczone (nawigacja, stopka, inne wpisy słownika).

## Częste problemy i rozwiązania

**Spadek wydajności przy dużych słownikach.** Od około 500 pojęć krok post-processingu może być odczuwalny, szczególnie na stronach z dużą ilością tekstu. Rozwiązanie: aktywacja cachowania. Cache stron TYPO3 przechowuje wynik po pierwszym renderowaniu. Ponowne przetwarzanie następuje tylko przy czyszczeniu cache. Dodatkowo pomaga ograniczenie listy pojęć do faktycznie używanego słownictwa. 200 precyzyjnych pojęć jest lepsze niż 800 z wariantami.

**Błędne linkowanie w nagłówkach i linkach.** a21glossary domyślnie linkuje wszędzie, również wewnątrz tagów H2 lub istniejących hiperłączy. Prowadzi to do zagnieżdżonych linków, które są nieprawidłowe w HTML. Przez konfigurację TypoScript można wykluczyć tagi: `excludeTags = h1,h2,h3,a,script`. To ustawienie powinno znaleźć się w każdej instalacji.

**Konflikty z RealURL i routingiem.** W starszych wersjach TYPO3 (przed v9) pojawiały się problemy, gdy strony szczegółów słownika były routowane przez RealURL. Z TYPO3 v10+ i natywnym Site Routing ten problem nie występuje. Kto nadal używa RealURL, powinien i tak przeprowadzić migrację.

## Migracja i kompatybilność wersji

a21glossary został pierwotnie opracowany dla TYPO3 v4.x i aktualizowany na przestrzeni lat. Ostatnia aktywnie utrzymywana wersja w TER obsługuje TYPO3 v10 i v11. Dla TYPO3 v12 istnieje fork społecznościowy na GitHubie, który portuje rozszerzenie na nową strukturę TCA i zmieniony system hooków. Dla TYPO3 v13 na chwilę obecną nie jest dostępna oficjalna wersja.

Migracja z v11 na v12 wymaga trzech dostosowań: po pierwsze przejścia z `$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']` na nowy system Event Dispatcher, po drugie aktualizacji definicji TCA (konfiguracja wizardów) i po trzecie dostosowania konfiguracji TypoScript do nowej konfiguracji Site.

Kto planuje przejście na TYPO3 v13, stoi przed wyborem: rozwijać fork społecznościowy lub przejść na alternatywne rozwiązanie. Jako alternatywę można zaimplementować funkcjonalność słownika bezpośrednio jako Custom Content Element z DataProcessor. Nakład pracy wynosi około 2-3 dni developerskich, a wynik jest przyszłościowy i niezależny od utrzymania przez osoby trzecie. Gosign przeprowadził tę migrację w wielu projektach i może realistycznie oszacować rzeczywisty nakład pracy na podstawie analizy istniejących danych słownikowych.

--- aimeos TYPO3 - Sklep E-Commerce | Gosign ---
> aimeos: Profesjonalny sklep online w TYPO3. Konfiguracja, customizacja i migracja, rozwój z wykorzystaniem AI.

## Kto potrzebuje sklepu w TYPO3, praktycznie nie ominie aimeos

Firmy, które już prowadzą witrynę TYPO3 i chcą uzupełnić ją o e-commerce, stają przed zasadniczym pytaniem: oddzielny system sklepowy (Shopware, Magento, WooCommerce) z interfejsem do CMS, czy natywny framework e-commerce wewnątrz TYPO3? aimeos to ta druga opcja i od ponad 10 lat najbardziej ugruntowany framework sklepowy TYPO3. Ponad 200 000 instalacji na całym świecie (stan: Packagist, 2026), aktywny rozwój i wsparcie dla TYPO3 v12 i v13 świadczą o stabilności.

Decydująca przewaga: treść i handel działają w tym samym systemie. Strony produktowe korzystają z elementów treści TYPO3, landing page mogą osadzać komponenty sklepowe, redaktorzy pracują w jednym interfejsie. Przy rozdzielonych systemach pojawiają się problemy z synchronizacją, podwójna pielęgnacja i niespójny design.

## Typowe scenariusze zastosowań

**Sklepy B2B ze złożoną logiką cenową.** Firmy przemysłowe z cenami indywidualnymi dla klientów, rabatami ilościowymi, minimalnymi ilościami zamówień i workflow zatwierdzania. aimeos natywnie wspiera ceny grup klientów, pluginy cenowe i systemy reguł. Dystrybutor chemiczny z 8000 artykułami i 400 grupami klientów da się odwzorować bez hardkodowania każdej reguły cenowej.

**Marketplace i scenariusze multi-vendor.** aimeos może służyć jako backend marketplace, w którym wielu dostawców umieszcza swoje produkty. Każdy vendor zarządza swoim asortymentem, platforma przejmuje checkout, płatności i routing wysyłki. Framework wspiera konfiguracje multi-shop, w których różne storefronty korzystają z tego samego katalogu, ale pokazują różne asortymenty i ceny.

**Internacjonalizacja od pierwszego dnia.** Firmy z witrynami w ponad 5 językach i wieloma walutami korzystają z tego, że aimeos natywnie obsługuje multi-language i multi-currency. Nazwy produktów, opisy i metadane SEO można pielęgnować per język. Ceny można definiować per waluta lub przeliczać automatycznie.

## Architektura techniczna

aimeos opiera się na własnej architekturze MVC (Manager, Controller, Client), która jest zintegrowana w TYPO3 jako rozszerzenie. Rdzeń jest niezależny od frameworka i działa również pod Laravel i Slim. Warstwa adapterów TYPO3 zapewnia, że pluginy aimeos są osadzane jako elementy treści TYPO3.

Katalog produktów wykorzystuje strukturę drzewiastą z dowolną głębokością zagnieżdżenia. Atrybuty (kolor, rozmiar, materiał) są zarządzane jako oddzielne encje i wyświetlane przez filtry fasetowe. Funkcja wyszukiwania domyślnie opiera się na pełnotekstowym wyszukiwaniu SQL, ale można ją przełączyć na Elasticsearch lub Solr.

Integracje płatności działają przez providerów usług: Stripe, PayPal, Mollie, Amazon Pay, Klarna i inne są dostępne jako pluginy. Każdy provider płatności jest obsługiwany przez ujednolicone API. Proces checkout jest zaimplementowany jako pipeline kroków i można go rozszerzać o własne etapy (np. weryfikacja wieku, zatwierdzenie B2B).

Cachowanie odbywa się na kilku poziomach: TYPO3 Page Cache dla statycznych stron, wewnętrzne cachowanie aimeos dla zapytań katalogowych i opcjonalnie Varnish lub Cloudflare jako reverse proxy. Przy katalogach z ponad 100 000 artykułami kluczowe jest zarządzanie indeksami: aimeos tworzy indeksy wyszukiwania i cenowe, które są aktualizowane inkrementalnie przy aktualizacjach produktów.

## Częste problemy i rozwiązania

**Spadki wydajności przy dużych katalogach.** Sklepy z ponad 50 000 artykułami stają się wolne, gdy indeksy nie są aktualne lub cache katalogu został dezaktywowany. Rozwiązanie: `php typo3/sysext/core/bin/typo3 aimeos:jobs` jako cronjob (co 5 minut dla aktualizacji indeksów, co godzinę dla zadań porządkowych). Cache admin aimeos należy wyczyścić ręcznie po masowych importach.

**Porzucenia w checkout z powodu błędów płatności.** Częsta przyczyna: nieaktualne klucze API lub nieprawidłowe adresy URL webhook po zmianie domeny. Każdy provider płatności potrzebuje prawidłowego Notify-URL, przez który potwierdzenia płatności trafiają asynchronicznie. Rozwiązanie: sprawdzenie adresów URL webhook w panelu providera po każdej zmianie, przeprowadzenie zamówień testowych w trybie sandbox.

**Konflikty z cachowaniem TYPO3.** Strony aimeos z koszykiem lub loginem nie mogą trafiać do TYPO3 Page Cache. Rozwiązanie: oznaczenie odpowiednich stron jako USER_INT lub uruchomienie aimeos w trybie SPA (opartym na AJAX). Od aimeos 2024.x tryb SPA jest rekomendowany jako standard.

## Migracja i kompatybilność wersji

aimeos w pełni wspiera TYPO3 v12 LTS, a TYPO3 v13 od aimeos 2024.x. Dla TYPO3 v11 dostępne są wydania maintenance, ale bez nowych funkcji.

Migracja z innych systemów sklepowych jest realistycznym scenariuszem. Ze Shopware, WooCommerce lub tt_products można przenieść produkty, kategorie, konta klientów i historię zamówień do aimeos. Gosign wykorzystuje do tego pipeline importu CSV/XML, w którym dane produktowe są transformowane i mapowane na strukturę aimeos. W zależności od jakości danych migracja sklepu z 5000 produktami trwa od 3 do 10 dni.

Kto przechodzi z tt_products, powinien zaplanować zmianę wraz z następną główną wersją TYPO3: tt_products jest od lat utrzymywany jedynie minimalnie i nie ma oficjalnej kompatybilności z TYPO3 v13.

Kolejna ścieżka migracji dotyczy firm, które dotychczas prowadziły oddzielny sklep Shopware lub Magento równolegle z witryną TYPO3. Połączenie w jeden system eliminuje złożoność interfejsów: brak synchronizacji REST-API dla danych produktowych, brak podwójnego zarządzania szablonami, brak oddzielnych wdrożeń. Wadą jest to, że aimeos nie pokrywa wszystkich funkcji dedykowanego systemu sklepowego (np. Shopware Flow Builder, Magento Page Builder). Kalkulacja opłaca się jednak dla firm, w których treść i handel są równoważne - nie tylko sklep się liczy, ale też magazyn, baza wiedzy i strony serwisowe.

Gosign doradza w każdym projekcie indywidualnie, czy aimeos to właściwy wybór, czy oddzielny system sklepowy z headless connection do TYPO3 stanowi lepszą architekturę. Decyzja zależy od trzech czynników: złożoności katalogu (warianty, konfiguratory, zestawy), wolumenu transakcji (poniżej lub powyżej 1000 zamówień dziennie) i istniejącej infrastruktury TYPO3 (rozszerzenia, szablony, workflow redakcyjne).

--- Amazon Pay TYPO3 - Płatności | Gosign ---
> Amazon Pay w TYPO3: Checkout z kontem Amazon. Integracja API, certyfikacja, z wykorzystaniem AI.

## Amazon Pay redukuje porzucenia zakupów, bo klienci nie muszą zakładać nowego konta

Znaczna część kupujących online posiada konto Amazon. Gdy ci użytkownicy w sklepie TYPO3 klikają "Kup" i widzą formularz rejestracyjny z 12 obowiązkowymi polami, wielu rezygnuje. Amazon Pay rozwiązuje ten problem: klient uwierzytelnia się kontem Amazon, adres dostawy i metoda płatności są przejmowane automatycznie. Żadnego formularza, żadnego numeru karty kredytowej, żadnego nowego hasła. Według case studies samego Amazona współczynnik konwersji rośnie o 15 do 30%, w zależności od branży i obecnej jakości checkout.

Dla operatorów sklepów TYPO3 integracja nie jest plug-and-play. Amazon Pay wymaga połączenia API (Login with Amazon, Amazon Pay API v2), certyfikowanej implementacji i regularnych aktualizacji bezpieczeństwa. Amazon weryfikuje każdą integrację przed uruchomieniem.

## Typowe scenariusze zastosowań

**Średnie sklepy B2C z aimeos.** Sklepy internetowe z modą, elektroniką, artykułami gospodarstwa domowego, które obok PayPal i karty kredytowej chcą zaoferować trzecią metodę płatności. Amazon Pay sprawdza się szczególnie dobrze przy impulsywnych zakupach poniżej 200 EUR, gdzie każda przeszkoda w checkout bezpośrednio kosztuje obrót. Integracja z aimeos odbywa się przez własny Service-Provider, który jest wpinany w pipeline płatności.

**Platformy darowizn i składki członkowskie.** Stowarzyszenia i organizacje pozarządowe, które za pośrednictwem swojej witryny TYPO3 zbierają darowizny lub składki członkowskie, korzystają z niskiego progu wejścia. Darczyńca klika "Zapłać przez Amazon", potwierdza kwotę i gotowe. Żadnego wpisywania IBAN, żadnego ustawiania polecenia zapłaty. Dla płatności cyklicznych Amazon Pay wspiera Recurring Payments.

**Produkty cyfrowe i pliki do pobrania.** Licencje oprogramowania, e-booki, kursy online - produkty bez fizycznej wysyłki korzystają szczególnie, ponieważ cały proces zakupowy zamyka się w mniej niż 30 sekund. Nie potrzeba adresu wysyłki, tylko uwierzytelnienie i płatność.

## Architektura techniczna

Amazon Pay v2 opiera się na REST-API z payload JSON. Przebieg w sklepie TYPO3: klient klika przycisk Amazon Pay, jest przekierowywany do Amazon (lub otwiera się popup), loguje się i potwierdza adres oraz metodę płatności. Amazon zwraca Access Token do sklepu. Sklep tworzy Checkout Session przez Amazon Pay API, w której są zdeponowane dane koszyka i szczegóły zamówienia. Po potwierdzeniu przez klienta płatność jest inicjowana.

Integracja w TYPO3 wymaga trzech komponentów: klienta API (żądania HTTP do Amazon Pay API z podpisem RSA), komponentu frontendowego (przycisk Amazon Pay jako widget JavaScript) oraz handlera webhook dla asynchronicznych powiadomień (potwierdzenie płatności, zwrot, obciążenie zwrotne).

Dla aimeos istnieje plugin społecznościowy pokrywający podstawowe funkcje. Dla tt_products lub sklepów niestandardowych potrzebna jest własna integracja. W obu przypadkach sklep TYPO3 musi używać HTTPS (obowiązek od Amazon Pay v2), a URL webhook musi być dostępny z zewnątrz.

Amazon udostępnia środowisko sandbox, w którym wszystkie przepływy płatności można testować bez prawdziwych pieniędzy. Sandbox korzysta z własnych endpointów API i kont testowych.

## Częste problemy i rozwiązania

**Certyfikacja nie udaje się za pierwszym podejściem.** Amazon sprawdza przed uruchomieniem, czy integracja funkcjonuje poprawnie: umiejscowienie przycisku, obsługa błędów przy odrzuconych płatnościach, wyświetlanie na urządzeniach mobilnych, prawidłowe anulowanie. Częste błędy: przycisk Amazon Pay nie pojawia się na stronie produktu (tylko w koszyku), komunikaty o błędach przy odrzuceniu płatności brakują. Rozwiązanie: kompletne przejście Integration Checklist Amazona przed złożeniem wniosku o weryfikację.

**Powiadomienia IPN (Instant Payment Notifications) giną.** Amazon wysyła potwierdzenia płatności asynchronicznie przez POST na zdeponowany URL. Jeśli TYPO3 blokuje te żądania przez cachowanie, reguły przekierowań lub brak wyjątków CSRF, zamówienie pozostaje w statusie "oczekujące". Rozwiązanie: skonfigurowanie dedykowanej trasy eID lub middleware dla webhook, która działa poza normalnym przetwarzaniem żądań TYPO3.

**Recurring Payments i modele abonamentowe.** Amazon Pay wspiera płatności cykliczne, ale konfiguracja jest bardziej złożona niż przy Stripe Subscriptions. Klient musi jawnie zaakceptować Billing Agreement, a sklep musi regularnie wysyłać żądania Authorize. Rozwiązanie: zarządzanie Billing Agreements jako oddzielna encja bazodanowa i skonfigurowanie cronjoba, który inicjuje należne płatności.

## Migracja i kompatybilność wersji

Amazon Pay v2 to aktualna wersja API (od 2021). Wersja 1 nie jest już akceptowana dla nowych integracji od końca 2023. Istniejące implementacje v1 nadal działają, ale nie otrzymują aktualizacji ani nowych funkcji. Migracja z v1 na v2 dotyczy kompletnego klienta API: inne endpointy, inny mechanizm podpisu (RSA zamiast HMAC), inne zarządzanie sesjami.

Dla TYPO3 nie ma oficjalnego rozszerzenia Amazon Pay w TER z aktywnym wsparciem v12/v13. Integracja odbywa się jako kod niestandardowy lub przez pluginy społecznościowe dla aimeos. Gosign implementuje Amazon Pay jako samodzielny pakiet Composer, który można wpiąć w dowolną konfigurację sklepu TYPO3. Ten pakiet enkapsuluje klienta API, przycisk i handler webhook, dzięki czemu aktualizacja główna TYPO3 dotyczy jedynie warstwy adapterów specyficznych dla TYPO3.

Całkowity koszt integracji Amazon Pay w istniejącym sklepie TYPO3 wynosi od 3 do 8 dni deweloperskich, w zależności od tego, czy można wykorzystać plugin aimeos, czy potrzebna jest integracja niestandardowa. Certyfikacja Amazon wymaga dodatkowo 1 do 2 dni na przygotowanie i rundy korekt.

--- Angular i TYPO3 - Headless CMS | Gosign ---
> Frontend Angular z TYPO3: Headless CMS, JSON-API, integracja SPA. Rozwój z wykorzystaniem AI.

## Dlaczego Angular z TYPO3 działa, ale większość konfiguracji kończy się niepowodzeniem

Koncepcja brzmi przekonująco: TYPO3 dostarcza treści jako JSON, Angular renderuje frontend jako Single Page Application. Redaktorzy pracują w znanym backendzie TYPO3, developerzy budują nowoczesny frontend bez ograniczeń TypoScript. W praktyce wiele projektów Angular-TYPO3 rozbija się o granicę architektoniczną między CMS a SPA. Oficjalne rozszerzenie TYPO3 Headless (EXT:headless) rozwiązuje problem dostarczania treści. Ale routing, podgląd, SEO i caching wymagają przemyślanych rozwiązań wykraczających poza proste `ng serve`.

Angular jako frontend dla TYPO3 nadaje się dla przedsiębiorstw potrzebujących treści wielokanałowych: strona internetowa, aplikacja, portal intranetowy i Digital Signage z jednego źródła treści. Inwestycja zwraca się od drugiego kanału. Dla stron internetowych bez ambicji aplikacyjnych klasyczne TYPO3-Fluid-Setup jest prawie zawsze wydajniejsze.

## Typowe scenariusze zastosowania

**Platformy wielokanałowe z aplikacją i stroną.** Dostawca motoryzacyjny zarządza danymi produktów, informacjami serwisowymi i aktualnościami w TYPO3. Strona działa jako Angular-SPA, aplikacja serwisowa dla techników korzysta z tego samego JSON-API. Zmiany w TYPO3 pojawiają się na obu kanałach jednocześnie. Treść jest utrzymywana raz, dostarczana dwukrotnie.

**Portale intranetowe ze złożoną interakcją.** Dashboardy HR, platformy zarządzania wiedzą i narzędzia wewnętrzne korzystają z komponentowego podejścia Angulara. TYPO3 dostarcza ustrukturyzowaną treść (polityki, podręczniki, organigramy), Angular renderuje interaktywne widoki z filtrami, wyszukiwaniem i aktualizacjami w czasie rzeczywistym. Autoryzacja odbywa się przez istniejące LDAP/SSO, TYPO3 sprawdza uprawnienia przez fe_group.

**Konfiguratory i interaktywne strony produktowe.** Producenci konfigurowalnych produktów używają Angulara do widoku 3D lub konfiguratora. Dane podstawowe produktu pochodzą z TYPO3, logika konfiguracji żyje w frontendzie Angular. U klienta z 1200 konfigurowalnymi wariantami podejście to skróciło czas ładowania strony konfiguratora z 4,2 do 1,1 sekundy.

## Architektura techniczna

Rozszerzenie TYPO3 Headless transformuje standardowe wyjście z HTML na JSON. Każdy element treści, każda nawigacja, każdy poziom breadcrumb jest dostarczany jako obiekt JSON. Angular konsumuje to API przez serwisy HttpClient.

Architektura składa się z trzech warstw. TYPO3 jako backend dostarcza treści przez Headless-API pod `/api/`. Angular jako aplikacja frontendowa jest kompilowana jako osobny proces budowania (`ng build --prod`) i typowo dostarczana przez CDN lub osobny serwer WWW. Pomiędzy nimi znajduje się serwer SSR oparty na Node.js (Angular Universal), który obsługuje Server-Side Rendering dla SEO i sieci społecznościowych.

Routing jest dwudzielny: Angular Router obsługuje nawigację po stronie klienta, TYPO3 definiuje strukturę URL przez Site Configuration. Oba muszą być zsynchronizowane. W praktyce oznacza to: gdy redaktor tworzy nową stronę w TYPO3, Angular musi znać ten URL. Rozwiązaniem jest dynamiczny routing w frontendzie Angular, który przy każdym buildzie pobiera strukturę stron z API TYPO3.

Serwisy TypeScript są generowane z typów treści TYPO3. Dla każdego Content Element istnieje Angular Component z typingiem. Te typy można generować skryptem z API TYPO3, co zapewnia synchronizację między backendem a frontendem.

## Częste problemy i rozwiązania

**Deficyty SEO przez rendering wyłącznie po stronie klienta.** Google renderuje JavaScript, ale nie niezawodnie i nie natychmiastowo. Bez Server-Side Rendering (Angular Universal lub Angular SSR od v17) strony są indeksowane późno lub wcale. Rozwiązanie: wdrożenie Angular Universal jako warstwy SSR. Początkowa odpowiedź HTML musi być w pełni wyrenderowana, zanim proces hydracji po stronie klienta przejmie kontrolę.

**Podgląd treści w backendzie TYPO3 nie działa.** Redaktorzy klikają "Podgląd" i widzą JSON zamiast wyrenderowanej strony. Rozwiązanie: konfiguracja proxy podglądu, który przekierowuje odpowiedź JSON do dedykowanej instancji podglądu Angular. EXT:headless oferuje tryb podglądu, który dostarcza wersje robocze treści przez parametr tokena.

**Problemy CORS między API TYPO3 a frontendem Angular.** Gdy TYPO3 i Angular działają na różnych domenach, przeglądarka blokuje żądania API. Rozszerzenie EXT:cors lub serwerowy reverse proxy rozwiązuje ten problem. Zalecenie: oba pod tą samą domeną (TYPO3 pod `/api/`, Angular pod `/`).

## Migracja i kompatybilność wersji

EXT:headless jest oficjalnie kompatybilne z TYPO3 v11, v12 i v13. Rozszerzenie jest aktywnie utrzymywane i podąża za cyklem wydań TYPO3. Sam Angular ma własny rytm wydań: co 6 miesięcy nowa wersja major. Od Angular v17 SSR jest natywnie zintegrowany (nie jest potrzebny oddzielny pakiet Angular Universal).

Dla istniejących projektów Angular-TYPO3 na TYPO3 v10 lub starszym zaleca się migrację etapową: najpierw aktualizacja TYPO3 do v12 lub v13, potem Angular do aktualnej wersji LTS (v18). Interfejs API EXT:headless zmienił się między v2 a v4 w kilku miejscach, szczególnie w obsłudze nakładek językowych i podglądów Workspace.

Nakład pracy dla projektu Angular-TYPO3 jest typowo o 30-50% wyższy niż dla czystego projektu Fluid. Tę dodatkową inwestycję odzyskuje się dzięki drugiemu kanałowi (aplikacja, intranet). Gosign doradza przed rozpoczęciem projektu, czy Headless jest właściwym podejściem, czy może klasyczne rozwiązanie z celowymi wyspami JavaScript spełni ten sam cel.

--- Amazon S3 TYPO3 - Cloud Storage FAL | Gosign ---
> Amazon S3 jako sterownik FAL dla TYPO3. Przechowywanie plików w chmurze zamiast na serwerze.

## aus_driver_amazon_s3 to standardowe rozwiązanie, gdy zasoby TYPO3 nie mogą już leżeć na serwerze WWW, rozszerzenie wprowadza buckety S3 jako pełnoprawny sterownik FAL do stosu TYPO3

Klasyczna konfiguracja TYPO3 przechowuje wszystkie dane medialne pod fileadmin na serwerze WWW. To działa, dopóki projekt działa na jednej maszynie i pamięć wystarcza. Gdy jednak w grę wchodzą konfiguracje multi-serwerowe, klastry kontenerów, auto-scaling lub Content Delivery Networks, ten model się załamuje. Każda instancja potrzebowałaby identycznej kopii wszystkich plików, synchronizacja staje się stałym problemem, a wdrożenia są wolne. aus_driver_amazon_s3 rozwiązuje to, osadzając Amazon S3 jako zewnętrzny storage FAL. Pliki leżą w bucket, TYPO3 czyta i pisze przez API S3, a każda instancja serwera ma dostęp do tego samego spójnego zbioru danych. Dla projektów z wymaganiami wysokiej dostępności to standardowa droga.

Obok technicznej konieczności dla konfiguracji multi-serwerowych istnieje drugi ważny driver: backup i redundancja. S3 zapisuje każdy plik automatycznie wielokrotnie, rozłożony po różnych centrach danych, i osiąga tym samym poziom przechowywania danych, którego klasyczny serwer WWW nie może zagwarantować. Dla firm, których dane medialne są krytyczne dla biznesu, to już samo w sobie powód, aby przejść na S3.

## Typowe scenariusze zastosowania

Pierwszym przypadkiem są wdrożenia Cloud-Native na AWS, Kubernetes lub Docker Swarm. TYPO3 działa w kilku kontenerach za load-balancerem, każdy kontener jest bezstanowy. fileadmin jako katalog lokalny oznaczałoby, że uploady lądują tylko w jednym kontenerze, a inne ich nie widzą. aus_driver_amazon_s3 trzyma zbiór zasobów centralnie i czyni scale-out w ogóle praktykowalnym.

Drugim przypadkiem są projekty z bardzo dużymi wolumenami danych. Platforma medialna, archiwum zdjęć lub portal pobrań szybko rośnie do kilkuset gigabajtów lub terabajtów. Lokalna pamięć serwera staje się droga i nieelastyczna, S3 skaluje transparentnie i kosztuje tylko to, co jest rzeczywiście zajęte. Podłączenie przez FAL pozwala przy tym przejść na nowy storage bez zmian w kodzie TYPO3.

Trzecie zastosowanie: integracja CDN. Kto chce dostarczać obrazy i pobrania przez Cloudfront, Cloudflare lub własne CDN, używa S3 jako origin. aus_driver_amazon_s3 czyni pliki bezpośrednio dostępnymi w bucket, TYPO3 generuje poprawne URL-e, a CDN cache'uje je globalnie. To mierzalnie poprawia czasy ładowania dla odwiedzających międzynarodowych.

## Architektura techniczna

aus_driver_amazon_s3 implementuje interfejs FAL-Driver TYPO3 i używa oficjalnego AWS SDK for PHP do komunikacji z S3. Każdy bucket jest konfigurowany jako własny "File Storage" w backendzie TYPO3, z podaniem nazwy bucket, regionu, Access Key i Secret Key. Alternatywnie można użyć ról IAM, gdy TYPO3 działa na instancji EC2 lub w task ECS, to jest czystsze, bo w konfiguracji nie stoją statyczne credentials.

Rozszerzenie wspiera zarówno Amazon S3, jak i usługi kompatybilne z S3 jak MinIO, Backblaze B2, DigitalOcean Spaces lub Scaleway Object Storage. Dla projektów, które z powodów ochrony danych nie mogą leżeć u AWS, ta elastyczność jest ważna, europejski provider kompatybilny z S3 zachowuje się z punktu widzenia TYPO3 tak samo jak usługa AWS.

W bieżącym działaniu TYPO3 czyta i pisze bezpośrednio wobec S3. Processed Files (czyli przycięte i zoptymalizowane warianty obrazów) są domyślnie również zapisywane w bucket. Alternatywnie można skonfigurować lokalny katalog dla Processed Files, co przyspiesza przetwarzanie obrazów, bo GIFBUILDER nie musi ciągnąć każdego obrazu źródłowego z S3.

Konfiguracja odbywa się przez moduł backendowy "File Storages" i uzupełniające ustawienia TypoScript dla URL bucket i prefiksów CDN. Deweloperzy muszą dodatkowo zainstalować zależność AWS-SDK przez Composer i ustawić prawidłowe uprawnienia w bucket.

## Częste problemy i rozwiązania

Pierwszym problemem jest wydajność przy dużych listach obrazów. Gdy strona musi jednocześnie przycinać dziesiątki obrazów, a pliki źródłowe są ciągnięte z S3, budowa strony trwa zauważalnie dłużej. Rozwiązanie leży w lokalnym cache dla Processed Files, ewentualnie w połączeniu z skryptem pre-warming, który po nowych uploadach tworzy wcześniej najpopularniejsze warianty.

Drugi problem: błędy uprawnień przy uploadzie. Gdy TYPO3 chce pisać do bucket, ale polityka IAM dopuszcza tylko odczyt, upload zawiesza się z tajemniczym komunikatem błędu. Rozwiązaniem jest precyzyjna polityka z s3:GetObject, s3:PutObject, s3:DeleteObject i s3:ListBucket dla dokładnie tego bucket TYPO3, idealnie ograniczona do prefiksu, żeby inne aplikacje na tym samym bucket nie były przypadkowo dotknięte.

Trzeci problem: ochrona danych i wybór regionu. Projekty, które muszą pracować zgodnie z RODO, powinny wybrać regiony AWS w UE, zazwyczaj eu-central-1 we Frankfurcie lub eu-west-1 w Irlandii. Dla wyższych wymagań lub klientów, którzy wykluczają AWS z zasady, europejski provider kompatybilny z S3 jak Hetzner, IONOS lub Scaleway jest właściwą drogą. Rozszerzenie pracuje ze wszystkimi tymi providerami.

## Migracja i kompatybilność wersji

aus_driver_amazon_s3 jest kompatybilne z TYPO3 v11, v12 i v13 i jest aktywnie rozwijane. Przy upgrade należy uważać na wersję AWS SDK, nowsze wersje TYPO3 często wymagają aktualnych wersji SDK, które z kolei wymagają PHP 8.1 lub wyższego.

Migracja z lokalnego fileadmin do S3 to wyraźnie wydzielalny projekt: pliki początkowo skopiować do bucket przez aws s3 sync, w backendzie TYPO3 skonfigurować nową File Storage, istniejące rekordy sys_file przez skrypt przekierować na nowy storage, lokalne pliki po pomyślnym teście usunąć. Rozszerzenie nie przynosi gotowej rutyny migracji, bo dokładna procedura jest specyficzna dla projektu.

W zasobie przed migracją obowiązuje obowiązek inwentaryzacji. Ile plików leży w fileadmin, jak duży jest zasób danych, które z nich są osierocone, a które rzeczywiście jeszcze zlinkowane? Często przy takich audytach okazuje się, że większość starych danych nigdy więcej nie jest wywoływana i migracja może ograniczyć się do aktywnie używanych plików. To redukuje ryzyko, nakład i koszty bucket.

Gosign towarzyszy migracjom S3 dla projektów TYPO3 i projektuje architektury multi-cloud, które jednocześnie spełniają wymagania ochrony danych i cele wydajnościowe.

--- Azure Storage TYPO3 - Cloud FAL | Gosign ---
> Azure Blob Storage jako sterownik TYPO3 FAL. Przechowywanie plików w chmurze Microsoft. Odpowiednik aus_driver_amazon_s3 dla infrastruktur Azure.

## Przedsiębiorstwa ze stosem Microsoft potrzebują Azure Storage zamiast lokalnych systemów plików

Gdy infrastruktura IT działa na Azure, Active Directory zarządza użytkownikami, a SharePoint przechowuje dokumenty, system plików TYPO3 również powinien znajdować się w chmurze Azure. EXT:azurestorage integruje Azure Blob Storage jako sterownik FAL (File Abstraction Layer) w TYPO3. Redaktorzy nie zauważają różnicy, ale pliki zamiast na serwerze WWW znajdują się w infrastrukturze chmurowej Microsoft z CDN, georedundancją i praktycznie nieograniczoną przestrzenią dyskową.

To rozszerzenie jest odpowiednikiem Azure dla EXT:aus_driver_amazon_s3. Wybór między nimi rzadko zapada na podstawie kryteriów technicznych, lecz wzdłuż istniejącej strategii chmurowej. Kto już korzysta z Azure, oszczędza złożoność, kontrakty i koszty sieciowe przez pozostanie w ekosystemie Microsoft.

## Typowe scenariusze zastosowania

**Witryny korporacyjne z konfiguracją wieloserwerową.** Duże instalacje TYPO3 działają na wielu serwerach za load balancerem. Bez chmurowego przechowywania pliki muszą być synchronizowane między serwerami - przez rsync, NFS lub GlusterFS. Każde z tych rozwiązań niesie własne problemy. Azure Blob Storage jako sterownik FAL eliminuje potrzebę synchronizacji plików: wszystkie serwery sięgają do tego samego kontenera Blob. U klienta z 4 serwerami WWW i 180 000 plików migracja na Azure wyeliminowała całą infrastrukturę NFS.

**Portale z dużą ilością mediów i globalną publicznością.** Przedsiębiorstwa z klientami w Europie, Azji i Ameryce Północnej potrzebują szybkich czasów ładowania na całym świecie. Azure CDN dostarcza obrazy i pliki do pobrania przez serwery Edge w ponad 130 miastach. Integracja odbywa się przez konfigurację endpointu CDN w portalu Azure, TYPO3 automatycznie generuje odpowiednie adresy URL CDN.

**Wymagania compliance dotyczące przechowywania danych.** Niektóre branże wymagają, aby pliki były przechowywane w określonym kraju. Azure oferuje centra danych we Frankfurcie, Zurychu i Wiedniu. Przez konfigurację Storage Account można dokładnie określić, gdzie dane fizycznie się znajdują. Jest to przewaga nad generycznymi dostawcami kompatybilnymi z S3, gdzie geokonfiguracja jest często nieprzejrzysta.

## Architektura techniczna

EXT:azurestorage implementuje interfejs sterownika TYPO3 FAL. Oznacza to, że rozszerzenie rejestruje się jako sterownik w File Abstraction Layer i nadpisuje standardowe operacje systemu plików (odczyt, zapis, usuwanie, listowanie) wywołaniami API Azure Blob Storage.

Konfiguracja odbywa się przez ustawienia File Storage TYPO3 w backendzie. Tworzy się nowy obiekt Storage ze sterownikiem "Azure Blob Storage". Dane dostępowe (nazwa Storage Account, Access Key lub SAS Token) są podawane w konfiguracji Storage. Zalecenie: SAS Token z ograniczoną ważnością i uprawnieniami odczytu/zapisu zamiast głównego Access Key.

Komunikacja między TYPO3 a Azure odbywa się przez Azure Storage REST API. Przesyłane pliki są zapisywane jako Block Blobs, duże pliki (powyżej 256 MB) są automatycznie dzielone na bloki. Do integracji po stronie PHP rozszerzenie wykorzystuje Azure SDK for PHP lub lekką implementację klienta REST.

Obrazy są przetwarzane w razie potrzeby przez Image Processing TYPO3 (GraphicsMagick/ImageMagick). Przetworzone warianty są również przechowywane w Azure, zazwyczaj w oddzielnym kontenerze (_processed_). Cachowanie przetworzonych plików skraca czas obróbki przy powtórnych żądaniach.

## Częste problemy i rozwiązania

**Wolna wydajność backendu przy przeglądaniu dużych katalogów.** Azure Blob Storage nie ma prawdziwej struktury katalogów, lecz emuluje ją przez prefiksy ścieżek. Listowanie 10 000 plików w "folderze" wymaga paginacji API i trwa zauważalnie dłużej niż na lokalnym systemie plików. Rozwiązanie: poprawna konfiguracja indeksera FAL TYPO3 i regularna aktualizacja indeksu, zamiast sprawdzania na żywo w Azure przy każdym dostępie do backendu.

**Przetwarzanie obrazów kończy się niepowodzeniem.** TYPO3 musi pobrać obrazy do przetworzenia, przetworzyć je i ponownie przesłać. Przy niestabilnym połączeniu lub dużych obrazach (pliki TIFF o rozmiarze 200 MB) proces się przerywa. Rozwiązanie: przetwarzanie na serwerze z lokalnym katalogiem tymczasowym i przesyłanie tylko wyniku. Konfiguracja `processingFolder` powinna wskazywać na ścieżkę lokalną.

**Eksplozja kosztów przez niepotrzebne wywołania API.** Każdy dostęp do pliku to wywołanie API, a Azure rozlicza się za każde 10 000 transakcji. Źle skonfigurowany indekser TYPO3 może generować tysiące wywołań na minutę. Należy skonfigurować monitoring przez Azure Cost Management i przestawić indekser FAL na interwały oparte na Schedulerze (zamiast czasu rzeczywistego).

## Migracja i kompatybilność wersji

EXT:azurestorage jest produktem niszowym z ograniczoną społecznością. Dostępne wersje w TER i na Packagist obsługują TYPO3 v10 i v11. Dla v12 istnieją forki na GitHubie o różnym stopniu dojrzałości. Dla TYPO3 v13 nie ma aktualnie gotowego rozwiązania.

Alternatywa dla v12/v13: EXT:aus_driver_amazon_s3 z kompatybilnym z S3 endpointem Azure. Azure Blob Storage oferuje od 2020 roku warstwę API kompatybilną z S3. Dzięki temu lepiej utrzymywane rozszerzenie S3 można używać również z Azure. Konfiguracja wymaga Storage Account Azure z aktywowaną funkcją "S3-Compatible API" i skonfigurowania rozszerzenia S3 z endpointem Azure.

Kto migruje z lokalnego systemu plików na Azure, powinien zaplanować przeprowadzkę w trzech fazach: po pierwsze przesłanie istniejących plików przez AzCopy lub Storage Explorer do kontenera Blob, po drugie przełączenie konfiguracji File Storage TYPO3 i po trzecie odbudowa indeksu FAL. Przy 50 000 plików cały proces trwa zazwyczaj jeden dzień roboczy. Gosign przeprowadził migracje Azure dla projektów TYPO3 z maksymalnie 400 000 plików i doradza zarówno w zakresie natywnego rozszerzenia, jak i obejścia kompatybilnego z S3.

--- be_acl TYPO3 - Uprawnienia backendu | Gosign ---
> Backend Access Control Lists dla TYPO3. Granularne uprawnienia dla użytkowników i grup backendu.

## Gdy pracuje więcej niż trzech redaktorów, standardowe uprawnienia TYPO3 nie wystarczają

TYPO3 posiada wbudowany system uprawnień: grupy backendowe, dostęp do stron, uprawnienia do tabel. Dla małych zespołów z garstką redaktorów to wystarcza. Ale gdy witrynę korporacyjną utrzymuje 15 redaktorów z 4 działów, standardowy system osiąga swoje granice. be_acl rozszerza TYPO3 o granularne Access Control Lists, które regulują kto na jakiej stronie może widzieć, edytować lub usuwać jakie treści - aż do poziomu pól.

Rozszerzenie nie jest miłym dodatkiem, lecz warunkiem koniecznym dla każdej konfiguracji z wieloma redakcjami i więcej niż jedną strefą odpowiedzialności. Bez be_acl koncepcje uprawnień w TYPO3 regularnie kończą się siecią dziesiątek grup, nad którymi nikt nie panuje.

## Typowe scenariusze zastosowania

**Witryny korporacyjne z odpowiedzialnością działową.** Marketing zarządza stroną główną i stronami kampanii, HR stroną kariery, działy fachowe swoimi stronami produktowymi. Każdy dział powinien widzieć i edytować tylko swoje strony. Standardowy system TYPO3 pozwala na dostęp do stron przez Mount Points i uprawnienia grup, ale konfiguracja przy 10+ działach staje się nieprzejrzysta. be_acl upraszcza to przez ACL oparte na stronach: na każdej stronie w drzewie stron można bezpośrednio zdefiniować, która grupa ma jakie uprawnienia.

**Wielomandatowe instalacje TYPO3.** Agencje i korporacje prowadzą wiele stron w jednej instancji TYPO3. Mandant A nie powinien widzieć Mandanta B, nawet w drzewie stron. be_acl wymusza tę separację bez konieczności prowadzenia osobnej instalacji TYPO3 dla każdego mandanta. W agencji z 12 mandantami w jednej instancji TYPO3 be_acl zredukował czas administracji uprawnieniami o około 60%.

**Przepływy zatwierdzania z ograniczoną głębokością edycji.** Zewnętrzni usługodawcy lub stażyści powinni edytować teksty, ale nie przesyłać obrazów, nie przesuwać stron i nie konfigurować wtyczek. be_acl pozwala na uprawnienia na poziomie pól: użytkownik widzi pole tekstowe, ale nie ustawienia układu ani konfigurację wtyczki.

## Architektura techniczna

be_acl rozszerza system uprawnień backendu TYPO3 o warstwę ACL, która siedzi między podstawowym systemem uprawnień a interakcją użytkownika. Rozszerzenie przechowuje reguły uprawnień w tabeli `tx_beacl_acl`, która definiuje per strona i per grupa, jakie operacje są dozwolone.

System operuje na trzech poziomach uprawnień: odczyt (show), edycja (edit) i usuwanie (delete). Te uprawnienia są przyznawane per strona lub rekurencyjnie dla drzewa stron. Konfiguracja odbywa się przez osobną zakładkę w dialogu właściwości strony: tam administrator wybiera grupę użytkowników i ustawia żądane uprawnienia checkboxami.

Wewnętrznie be_acl ingeruje w `BackendUserAuthentication` TYPO3 i rozszerza sprawdzanie `doesUserHaveAccess`. Przy każdym dostępie do strony w backendzie TYPO3 najpierw sprawdza standardowe uprawnienia, a następnie reguły ACL. Reguły ACL mogą rozszerzać standardowe uprawnienia, ale nie mogą ich ograniczać. To ważny szczegół architektoniczny: jeśli grupa ma już dostęp przez standardowe uprawnienia, be_acl nie może go odebrać.

Rozstrzyganie uprawnień następuje kaskadowo: uprawnienia użytkownika przeważają nad uprawnieniami grup, uprawnienia grup nad uprawnieniami podgrup, a ACL specyficzne dla strony nad rekurencyjnie dziedziczonymi ACL. Ta kaskada działa niezawodnie, dopóki struktura grup pozostaje płaska. Od 4 zagnieżdżonych poziomów grup zachowanie staje się trudne do przewidzenia.

## Częste problemy i rozwiązania

**Uprawnienia nie działają zgodnie z oczekiwaniami.** Najczęstsza przyczyna: użytkownik jest członkiem wielu grup, a uprawnienia jednej grupy nadpisują ograniczenie ACL innej. System uprawnień TYPO3 działa addytywnie, co oznacza, że użytkownik otrzymuje sumę wszystkich uprawnień swoich grup. Rozwiązanie: stworzenie macierzy uprawnień, udokumentowanie wszystkich grup użytkownika i wyeliminowanie nakładających się uprawnień.

**Problemy wydajnościowe przy dużych drzewach stron.** W instalacjach TYPO3 z ponad 5000 stronami i 20+ grupami użytkowników sprawdzanie ACL może zauważalnie spowolnić drzewo stron w backendzie. Rozszerzenie sprawdza tabelę ACL przy każdym wyświetleniu strony. Rozwiązanie: aktywacja cachowania sprawdzeń ACL i ograniczenie drzewa stron przez `options.pageTree.excludeDoktypes` do odpowiednich typów stron.

**Debugowanie uprawnień jest trudne.** TYPO3 nie oferuje wbudowanego narzędzia pokazującego, dlaczego użytkownik ma lub nie ma dostępu do danej strony. Obszar administracyjny "Backend User" pokazuje symulowany widok, ale nie kaskadę uprawnień. Rozwiązanie: analiza TYPO3 System Log (przy aktywnym trybie debugowania TYPO3 loguje próby dostępu) lub bezpośrednie zapytanie do tabeli SQL `tx_beacl_acl`.

## Migracja i kompatybilność wersji

be_acl jest jednym z najdłużej utrzymywanych rozszerzeń TYPO3. Aktualna wersja obsługuje TYPO3 v11 i v12. Dla TYPO3 v13 istnieje wersja beta oparta na nowym systemie modułów backendowych. Rozszerzenie jest aktywnie rozwijane na GitHubie, maintainerzy reagują na zgłoszenia.

Przy migracji z TYPO3 v11 na v12 reguły ACL nie muszą być ręcznie migrowane - tabela bazy danych pozostaje kompatybilna. Jednak rejestracja modułów backendowych zmieniła się w v12, dlatego moduł konfiguracji be_acl wymaga aktualizacji wersji rozszerzenia.

Dla przedsiębiorstw migrujących na TYPO3 v13 zaleca się eksport istniejących reguł ACL przed aktualizacją. TYPO3 v13 wprowadza przebudowany system uprawnień, który przejmuje część funkcji be_acl do rdzenia. Czy rozszerzenie będzie długoterminowo potrzebne, zależy od złożoności koncepcji uprawnień. Gosign analizuje przy aktualizacjach TYPO3 istniejącą konfigurację ACL i rekomenduje optymalne rozwiązanie - czy to be_acl, natywne uprawnienia rdzenia czy kombinacja obu.

--- bernetshop TYPO3 - Prosty sklep | Gosign ---
> Prostsze rozszerzenie E-Commerce dla TYPO3 niż aimeos. Dla mniejszych sklepów z podstawowymi wymaganiami: lista produktów, koszyk, prosta płatność.

## Nie każdy sklep TYPO3 potrzebuje pełnego frameworka e-commerce

Aimeos to standard e-commerce w TYPO3. Ale Aimeos jest też złożony: własna warstwa abstrakcji bazy danych, własny system szablonów, ponad 30 tabel konfiguracyjnych. Dla stowarzyszenia sprzedającego 8 artykułów reklamowych lub średniej firmy z 50 częściami zamiennymi to przesada. bernetshop oferuje lekką alternatywę: lista produktów, koszyk, płatność - gotowe. Bez zarządzania magazynem, bez logistyki, bez obsługi wielu sklepów, ale też bez wielomiesięcznego wdrożenia.

Rozszerzenie jest skierowane do organizacji, które chcą sprzedawać niewiele produktów przez istniejącą stronę TYPO3, bez prowadzenia oddzielnego systemu sklepowego. Typowe zastosowanie: 10-200 produktów, proste warianty (rozmiar, kolor), płatność przelewem, PayPal lub Stripe.

## Typowe scenariusze zastosowania

**Stowarzyszenia i organizacje non-profit.** Kluby sportowe sprzedają koszulki i bilety wstępu, instytucje kulturalne oferują karnety roczne i publikacje. Sklep musi być łatwy w utrzymaniu, ponieważ zarządzają nim wolontariusze. bernetshop można konfigurować przez standardowe elementy treści TYPO3: produkt to rekord z obrazem, ceną, opisem i wariantami. Nie wymaga szkoleń poza standardową redakcją TYPO3.

**Sprzedaż części zamiennych i akcesoriów.** Producenci maszyn i urządzeń sprzedają części zużywalne, akcesoria i materiały eksploatacyjne przez stronę firmową. Dane produktowe już istnieją w TYPO3 (strony produktów, karty katalogowe), bernetshop dodaje koszyk i funkcję płatności. Zarządzanie produktami pozostaje tam, gdzie dane techniczne i tak się znajdują: w CMS.

**Wewnętrzne portale zamówień.** Większe przedsiębiorstwa wykorzystują proste systemy zamówień na materiały biurowe, materiały reklamowe lub akcesoria IT. bernetshop z logowaniem TYPO3 Frontend tworzy chroniony hasłem portal zamówień bez zewnętrznego oprogramowania. Zamówienia są przesyłane mailowo do odpowiedniego działu - integracja z ERP nie jest przewidziana i w tym kontekście nie jest potrzebna.

## Architektura techniczna

bernetshop opiera się na Extbase/Fluid, standardowym frameworku dla rozszerzeń TYPO3. Dane produktowe są przechowywane w osobnej tabeli `tx_bernetshop_domain_model_product`. Warianty (rozmiary, kolory) są modelowane jako relacje inline. Koszyk jest przechowywany w sesji PHP, a dla zarejestrowanych użytkowników opcjonalnie w bazie danych.

Logika sklepu jest przejrzysta: istnieją kontrolery dla listy produktów, szczegółów produktu, koszyka i finalizacji zamówienia. Szablony to standardowy Fluid i można je dostosować jak każdy inny szablon TYPO3. Obsługa płatności odbywa się przez adapter dostawcy płatności: PayPal, Stripe i przelew są zaimplementowane standardowo. Dodatkowych dostawców można dodać przez interfejs PHP.

Zamówienia są zapisywane w tabeli bazy danych i wyzwalają e-mail potwierdzający dla klienta i operatora sklepu. Moduł backendowy pokazuje wszystkie zamówienia ze statusem (otwarte, opłacone, wysłane). Eksport CSV jest zintegrowany, bezpośredni interfejs ERP nie.

Rozszerzenie wykorzystuje standardowe cachowanie TYPO3 dla list produktów. Koszyk i strefa finalizacji są uncacheable (USER_INT). Oznacza to, że strony list produktów korzystają z cache TYPO3, a finalizacja działa bez cache, co ma znaczenie przy dużym obciążeniu.

## Częste problemy i rozwiązania

**Limity skalowania od 200 produktów.** Lista produktów staje się wolna przy rosnącej liczbie produktów, gdy nie skonfigurowano paginacji. bernetshop dostarcza prostą paginację, ale nie wyszukiwanie fasetowe ani filtry kategorii. Rozwiązanie: od 200 produktów tworzyć strony kategorii i ograniczać listę produktów per kategoria. Od 500 produktów warto poważnie rozważyć Aimeos lub zewnętrzny sklep.

**Integracja płatności jest przestarzała.** Dołączone adaptery płatności częściowo korzystają ze starszych wersji API dostawców płatności. Classic API PayPal jest wycofane, Stripe wielokrotnie aktualizował swoje API. Rozwiązanie: sprawdzenie adapterów płatności i aktualizacja do bieżących wersji API. Nakład pracy per adapter wynosi 1-2 dni developerskie.

**Wymagania prawne nie są w pełni pokryte.** Prawo odstąpienia od umowy, podawanie cen jednostkowych, rozporządzenie o opakowaniach i zaostrzone od 2024 roku obowiązki informacyjne w e-commerce wymagają dostosowań, których bernetshop nie dostarcza od razu. Rozwiązanie: uzupełnienie szablonów finalizacji o prawnie wymagane informacje. To praca na szablonach, nie rozwój rozszerzenia.

## Migracja i kompatybilność wersji

bernetshop to niszowe rozszerzenie z ograniczonym utrzymaniem. Ostatnia stabilna wersja obsługuje TYPO3 v10 i v11. Dla TYPO3 v12 nie ma oficjalnej aktualizacji - nakład portowania jest przejrzysty (zmiany API Extbase, dostosowania TCA), ale musi być wykonany ręcznie. Dla TYPO3 v13 nie ma planów.

Przedsiębiorstwa migrujące na TYPO3 v12 lub v13 stoją przed wyborem: portować bernetshop lub przejść na alternatywę. Opcje to Aimeos (pełnowartościowy framework e-commerce, znacznie wyższy nakład), cart (sklep oparty na Extbase z aktywnym utrzymaniem i kompatybilnością v12) lub zewnętrzny sklep (Shopify, WooCommerce) z integracją TYPO3 przez API.

Migracja danych produktowych jest w każdym przypadku prosta: tabela ma jasną strukturę, którą można przenieść do dowolnego systemu docelowego skryptem SQL. U klienta z 85 produktami kompletna migracja z bernetshop na EXT:cart wraz z dostosowaniem szablonów zajęła 4 dni robocze. Gosign doradza w kwestii najbardziej ekonomicznej opcji i w razie potrzeby przejmuje portowanie lub migrację.

--- Baza obrazów TYPO3 - Zarządzanie zasobami | Gosign ---
> Baza obrazów w TYPO3: Digital Asset Management, auto-tagowanie, wyszukiwanie. Rozszerzenie FAL lub zewnętrzne połączenie DAM.

## Od 5000 obrazów FAL TYPO3 staje się wąskim gardłem

File Abstraction Layer TYPO3 zarządza plikami niezawodnie, dopóki ich ilość pozostaje przejrzysta. Przy 500 obrazach FAL działa bez zarzutu. Przy 5000 wyszukiwanie staje się wolne. Przy 20 000 lista plików w backendzie jest praktycznie nieużywalna. Przedsiębiorstwa z dużymi zasobami obrazów potrzebują czegoś więcej niż systemu plików: potrzebują Digital Asset Management. Pytanie brzmi, czy rozbudować FAL TYPO3 do DAM, czy podłączyć system zewnętrzny.

Oba podejścia działają. Wewnętrzna rozbudowa przez rozszerzenia FAL kosztuje mniej i pozostaje w ekosystemie TYPO3. Zewnętrzna integracja (Celum, Canto, Cloudinary, Bynder) oferuje więcej funkcji, ale wymaga licencji, utrzymania interfejsów i podwójnej logiki przechowywania danych.

## Typowe scenariusze zastosowania

**Przedsiębiorstwa produkcyjne z fotografią produktową.** Producent maszyn ma 8000 zdjęć produktów w różnych rozdzielczościach, do tego renderingi CAD, zdjęcia zastosowań i karty katalogowe. Każdy produkt istnieje w 5-10 wariantach obrazu. Bez systematycznego tagowania redaktorzy nie znajdują właściwego obrazu - lub co gorsza, używają przestarzałego. Auto-tagowanie przez AI analizuje zawartość obrazów i automatycznie przypisuje tagi. U klienta z 12 000 zdjęć produktów auto-tagowanie oparte na AI skróciło czas opisywania z 3 tygodni do 2 dni.

**Przedsiębiorstwa mediowe i wydawnictwa.** Portale informacyjne, magazyny i działy wydawnictw korporacyjnych codziennie produkują nowy materiał graficzny. Wymagania: szybkie wyszukiwanie, zarządzanie prawami (wygasanie licencji, prawa użytkowania per kanał), automatyczna konwersja formatów i dziedziczenie metadanych. Rozszerzone FAL z polami niestandardowymi pokrywa podstawowe funkcje. Dla zarządzania prawami i sterowania przepływem pracy potrzebny jest zewnętrzny DAM.

**Uczelnie wyższe i instytucje badawcze.** Uniwersytety zarządzają zdjęciami kampusu, fotografiami z wydarzeń, grafikami badawczymi i portretami pracowników. Wyzwanie: zdecentralizowane dostarczanie z 30+ wydziałów do jednego centralnego systemu. TYPO3 FAL ze strukturą folderów opartą na kategoriach i prawami dostępu per grupa użytkowników rozwiązuje to. Zewnętrzne systemy DAM są tutaj rzadko ekonomicznie uzasadnione.

## Architektura techniczna

FAL TYPO3 składa się z trzech warstw: sterownika Storage (lokalny system plików, S3, Azure), indeksu plików (tabela bazy danych `sys_file` z metadanymi) i systemu referencji plików (powiązanie między plikami a elementami treści). Baza obrazów w TYPO3 rozszerza głównie środkową warstwę - indeks plików.

Najprostsza rozbudowa: pola niestandardowe w tabeli `sys_file_metadata`. TYPO3 standardowo oferuje pola takie jak `title`, `description`, `alternative` i `copyright`. Przez TCA można dodać dowolne kolejne pola: `photographer`, `license_type`, `expiry_date`, `usage_rights`, `location`, `keywords_auto`. Te pola pojawiają się w dialogu metadanych pliku w backendzie.

Dla wyszukiwania TYPO3 oferuje standardowo tylko wyszukiwanie po nazwie pliku w module File List. Prawdziwe wyszukiwanie pełnotekstowe po wszystkich metadanych wymaga integracji Solr (przez EXT:solrfal) lub niestandardowego modułu backendowego z połączeniem Elasticsearch. Solr przeszukuje wtedy nie tylko nazwy plików, ale wszystkie pola metadanych, włącznie z automatycznie generowanymi tagami.

Auto-tagowanie przez AI działa przez zadanie Schedulera, które wysyła nowe pliki do serwisu rozpoznawania obrazów (Google Cloud Vision, AWS Rekognition lub model hostowany na własnym serwerze) i zapisuje rozpoznane tagi w polach metadanych. Proces jest asynchroniczny i nie obciąża backendu. Przy pierwszym imporcie dużych zasobów należy liczyć z około 1 sekundą per obraz na analizę API.

## Częste problemy i rozwiązania

**Indeks FAL i system plików rozchodzą się.** Gdy pliki są przesyłane przez FTP lub ręcznie usuwane, indeks FAL nie zgadza się z systemem plików. TYPO3 wyświetla pliki, które nie istnieją, lub nie zna istniejących plików. Rozwiązanie: regularne uruchamianie indeksera FAL przez Scheduler (zalecenie: codziennie w nocy). Indekser synchronizuje system plików z bazą danych. Przy 50 000 plików synchronizacja trwa około 10-15 minut.

**Metadane giną przy aktualizacjach TYPO3.** Pola niestandardowe w `sys_file_metadata` przeżywają aktualizacje TYPO3, gdy są zdefiniowane przez własne rozszerzenie. Jeśli są zdefiniowane bezpośrednio w pliku TCA-Override sitepackage, mogą zostać utracone przy zmianach strukturalnych tabeli metadanych. Rozwiązanie: pola bazy obrazów zawsze kapsułkować we własnym małym rozszerzeniu, nie w sitepackage.

**Wydajność backendu przy dużych drzewach plików.** Moduł File List staje się powolny od 1000 plików per folder, ponieważ generuje miniatury dla każdego obrazu. Rozwiązanie: struktura folderów z maksymalnie 500 plikami per katalog i przełączenie generowania miniatur w File List na "on demand".

## Migracja i kompatybilność wersji

FAL TYPO3 jest częścią rdzenia od wersji 6.0 (2012) i jest rozwijany z każdą wersją major. API FAL jest stabilne - pola niestandardowe i indeksery działają od TYPO3 v10 do v13 bez modyfikacji. Rozszerzenie Solr-FAL (EXT:solrfal) obsługuje TYPO3 v12, dla v13 zapowiedziano kompatybilność.

Kto migruje z zewnętrznego systemu DAM na TYPO3 FAL, musi zmapować metadane. Każdy system DAM ma własny model danych. Sama migracja to zadanie bazodanowe: eksport z DAM jako CSV/JSON, mapowanie pól na `sys_file_metadata`, import przez TYPO3 DataHandler lub bezpośredni SQL.

Decyzja "rozbudowa FAL vs. zewnętrzny DAM" zależy od dwóch czynników: wielkości zasobów i złożoności przepływów pracy. Do około 10 000 zasobów i bez przepływów zatwierdzania wystarczy rozszerzone FAL. Powyżej tego lub przy wymaganiach takich jak automatyczne zarządzanie licencjami i dystrybucja wielokanałowa opłaca się wyspecjalizowany DAM z konektorem TYPO3. Gosign doradza w obu wariantach i implementuje zarówno rozszerzenia FAL, jak i integracje DAM.

--- Booking TYPO3 - System rezerwacji | Gosign ---
> System rezerwacji dla TYPO3: Rezerwacja terminów, dostępność, płatności. Rozwój niestandardowy, z wykorzystaniem AI.

## Rezerwacja terminów na stronie internetowej w TYPO3 często zawodzi z powodu niedojrzałości rozszerzeń

Firmy oferujące konsultacje, wynajem sal czy kursy chcą zintegrować rezerwację online bezpośrednio w swojej witrynie TYPO3. Oczekiwanie: kalendarz, sprawdzanie dostępności, płatność, e-mail potwierdzający - wszystko w jednym. Rzeczywistość: w TYPO3 Extension Repository (TER) nie ma pojedynczego rozszerzenia rezerwacyjnego, które pokrywałoby wszystkie te wymagania na poziomie produkcyjnym. Dostępne rozwiązania (jcc_appointment, cab_single_booking, różne własne rozwiązania) obsługują przypadki niszowe lub nie są aktywnie utrzymywane.

Dlatego system rezerwacji TYPO3 to prawie zawsze hybryda: bazowe rozszerzenie lub rozwój niestandardowy dla logiki podstawowej, w połączeniu z providerami płatności (Stripe, PayPal, Mollie) i interfejsami kalendarza (iCal, Google Calendar API). Gosign wdrożył to podejście w ponad 15 projektach.

## Typowe scenariusze zastosowań

**Firmy doradcze z rezerwacją terminów.** Doradcy podatkowi, prawnicy, konsultanci biznesowi potrzebują systemu, w którym klienci widzą i rezerwują wolne sloty. Kalendarz synchronizuje się z Outlook lub Google Calendar doradcy. Płatność jest opcjonalna (często rozliczenie następuje po konsultacji), ale muszą być odwzorowywalne terminy anulowania i opłaty za niestawiennictwo. Typowa konfiguracja: 3 doradców, 4 rodzaje usług, sloty 30-minutowe, 2 lokalizacje.

**Organizatorzy szkoleń i kursów.** Ośrodki edukacyjne, szkoły policealne, kluby sportowe oferują kursy z ograniczoną liczbą miejsc. System rezerwacji potrzebuje list uczestników, list oczekujących, cen grupowych, zniżek za wczesną rezerwację i terminów seryjnych (np. 10 lekcji jogi jako pakiet). Płatność następuje przy rezerwacji, anulowanie z częściowym zwrotem musi być zautomatyzowane.

**Wynajem pomieszczeń i zarządzanie zasobami.** Przestrzenie coworkingowe, hotele konferencyjne, obiekty sportowe wynajmują sale lub miejsca godzinowo. Tu liczy się wyświetlanie dostępności w czasie rzeczywistym: żadne pomieszczenie nie może być podwójnie zarezerwowane, nawet gdy dwóch użytkowników jednocześnie kliknie "Rezerwuj". Ochrona przed race conditions na poziomie bazy danych to nie nice-to-have, lecz wymóg.

## Architektura techniczna

Produkcyjny system rezerwacji w TYPO3 składa się z czterech warstw. Warstwa bazy danych zarządza zasobami (sale, osoby, urządzenia), dostępnościami (okna czasowe, blokady, święta) i rezerwacjami (ze statusem: zapytanie, potwierdzona, anulowana, zakończona). Warstwa logiki sprawdza dostępność, zapobiega podwójnym rezerwacjom i oblicza ceny. Warstwa płatności komunikuje się z zewnętrznymi dostawcami płatności przez ich API. Warstwa powiadomień wysyła potwierdzenia, przypomnienia i e-maile o anulowaniu.

Do zapobiegania podwójnym rezerwacjom istnieją trzy podejścia: blokowanie pesymistyczne (SELECT ... FOR UPDATE), blokowanie optymistyczne (numer wersji w tabeli rezerwacji) lub oparte na kolejce (żądania rezerwacji przetwarzane sekwencyjnie). Wybór zależy od oczekiwanego obciążenia. Przy mniej niż 100 rezerwacjach dziennie wystarczy blokowanie optymistyczne, przy eventach z 1000 jednoczesnych dostępów kolejka jest bardziej niezawodna.

Eksport iCal jest standardem: każda potwierdzona rezerwacja generuje plik .ics, który jest wysyłany jako załącznik w e-mailu potwierdzającym. Do dwukierunkowej synchronizacji (rezerwacja w TYPO3 pojawia się w Google Calendar i odwrotnie) potrzebne jest Google Calendar API lub CalDAV.

## Częste problemy i rozwiązania

**Podwójne rezerwacje mimo sprawdzania dostępności.** Najczęstsza przyczyna: sprawdzenie "Czy slot jest wolny?" i wstawienie rezerwacji nie odbywają się w tej samej transakcji bazodanowej. Między sprawdzeniem a insertem mogą upłynąć milisekundy, w których drugi użytkownik zarezerwuje ten sam slot. Rozwiązanie: zamknięcie sprawdzenia i insertu w jednej transakcji z blokadą wiersza.

**Callbacki płatności nie docierają.** Stripe i PayPal wysyłają potwierdzenia płatności przez webhook. Jeśli witryna TYPO3 jest za reverse proxy lub firewallem, callbacki nie docierają do serwera. Rozwiązanie: udostępnienie URL webhook przez dedykowaną trasę (np. `/api/payment/webhook`), która nie jest blokowana przez cachowanie TYPO3 czy reguły .htaccess.

**Chaos stref czasowych przy rezerwacjach międzynarodowych.** Gdy rezerwujący i zasób są w różnych strefach czasowych, pojawiają się błędy. Rozwiązanie: przechowywanie wszystkich czasów wewnętrznie jako UTC, wyświetlanie w frontendzie dostosowane do lokalnej strefy czasowej użytkownika przez JavaScript.

## Migracja i kompatybilność wersji

Nie istnieje jednolite rozszerzenie rezerwacyjne z oficjalnym wsparciem TYPO3 v12/v13. Większość dostępnych rozszerzeń zatrzymała się na v10 lub v11. Kto migruje istniejący system rezerwacji na TYPO3 v12+, ma dwie opcje: portowanie logiki niestandardowej na Extbase/Doctrine (kompatybilne z v12) lub wydzielenie logiki rezerwacyjnej jako mikroserwisu API z renderowaniem tylko frontendu w TYPO3.

Dla nowych projektów zalecane jest podejście API-first: silnik rezerwacji jako REST-API (w TYPO3 lub jako oddzielny serwis), frontend jako komponent webowy osadzany w każdym szablonie TYPO3. Dzięki temu system rezerwacji pozostaje niezależny od głównych aktualizacji TYPO3. Gosign stosuje to podejście jako standard od 2024 roku.

Gosign kalkuluje typowy projekt systemu rezerwacji (3 typy zasobów, płatność Stripe, workflow e-mail, eksport iCal) na 15 do 25 dni deweloperskich. Z tego około 40% przypada na logikę rezerwacyjną ze sprawdzaniem dostępności, 25% na integrację płatności, 20% na szablony e-mail i powiadomienia oraz 15% na prezentację frontendową i testy.

--- bootstrap_grids TYPO3 - Layouty Grid | Gosign ---
> Bootstrap Grid-Layouty jako elementy treści TYPO3. Layouty kolumnowe bez overhead Gridelements.

## bootstrap_grids długo było najszybszym skrótem do wielokolumnowych layoutów w TYPO3 i dziś jest kandydatem do migracji

Przez lata bootstrap_grids było w projektach TYPO3 pragmatyczną odpowiedzią na powracające wymaganie redakcyjne: chcę na stronie ustawiać kolumny obok siebie, bez konieczności budowania przez deweloperki za każdym razem własnych elementów treści. Rozszerzenie przynosi do backendu kolekcję predefiniowanych layoutów Bootstrap Grid jako elementów treści, dzięki czemu redaktorzy mogą zakładać dwu-, trzy- lub czterokolumnowe bezpośrednio w treści strony. Dla agencji, które w krótkim czasie dostarczają wiele stron opartych na Bootstrap, przez długi czas to było najbardziej efektywne rozwiązanie.

Dziś sytuacja jest bardziej zróżnicowana. Z core-rozszerzeniem EXT:container i wyraźnie ulepszonymi layoutami backendowymi w TYPO3 v11 do v13 istnieją natywne alternatywy, które wymagają mniej konfiguracji i ściślej łączą się ze standardem TYPO3. bootstrap_grids pozostaje istotne w istniejących projektach, ale nowe projekty powinny używać go świadomie lub wcale.

## Typowe scenariusze zastosowania

Pierwszym scenariuszem jest szybka inwentaryzacja. Średniej wielkości strona z około 200 stronami, która już opiera się na Bootstrap, używa bootstrap_grids, aby bez własnej konfiguracji Site Package udostępnić wielokolumnowe layouty. Redaktorzy wybierają z dropdown layouty kolumnowe i wypełniają kontenery standardowymi elementami treści.

Drugim scenariuszem jest poprawa starszych relaunchy. Strona stowarzyszenia z 2018 roku została pierwotnie zbudowana z bootstrap_grids i z czasem zgromadziła 600 elementów treści, które leżą w kontenerach grid. Przy upgrade z TYPO3 v9 na v11 pojawia się pytanie: migrować czy kontynuować. Z reguły bootstrap_grids jest najpierw kontynuowane, żeby nie blokować upgrade, a przejście na EXT:container następuje w drugim kroku.

Trzecim scenariuszem jest faza przejściowa do nowoczesnej architektury frontendowej. Koncern migruje swoją obecność web z Bootstrap na system designu oparty na Tailwind. Dopóki zespół redakcyjny nie przeszedł jeszcze na nowy interfejs edytora, bootstrap_grids pozostaje w użyciu jako pomost, z jasną datą końcową.

Czwartym scenariuszem jest rozwiązanie awaryjne w audycie. Gdy istniejąca strona obywa się bez layoutów kolumnowych, a pojedyncze strony mają być nadrzędnie prezentowane wielokolumnowo, bootstrap_grids jest najszybszą odpowiedzią: instalacja, aktywacja, pierwsza strona z dwukolumnowym obszarem treści w mniej niż godzinę. Dla dłuższego użycia ten skrót rzadko jest jednak właściwym wyborem.

## Architektura techniczna

bootstrap_grids rejestruje własne elementy treści przez TCA-Overrides i dostarcza szablony Fluid dla wyjścia grid. W rdzeniu elementy są cienkim wrapperem wokół klas Bootstrap `container`, `row` i `col-*`. Rozszerzenie pielęgnuje własne kontenery kolumnowe, które są widoczne per Colpos w layoucie backendowym, i w razie potrzeby osadza Bootstrap-CSS.

Instalacja odbywa się klasycznie przez Composer. W kombinacji z własnymi Site Packages obowiązuje: bootstrap_grids przynosi kompletne Bootstrap-5-CSS i należące do niego JavaScript, co w projektach z własnym systemem designu szybko prowadzi do konfliktów i podwójnego ładowania CSS. W takich przypadkach zasoby bootstrap_grids są dezaktywowane i używana jest tylko integracja backendowa.

Konfiguracja odbywa się przez TsConfig: tu zespoły ustalają, które warianty grid są oferowane redaktorom, jakie liczby kolumn są dozwolone i jakie breakpointy Bootstrap są odwzorowywane. Porządne ograniczenie do kilku, wyraźnie nazwanych wariantów znacznie redukuje zamieszanie backendowe.

## Częste problemy i rozwiązania

Pierwszym problemem jest pułapka copy-paste w redakcji. Bez surowej governance z bootstrap_grids szybko powstają strony z ośmioma zagnieżdżonymi kontenerami, których nikt już nie utrzymuje. Rozwiązaniem jest ograniczenie dopuszczalnych wariantów i wytyczne redakcyjne, które wiążą używanie layoutów kolumnowych z wyraźnymi typami treści.

Drugim problemem jest podwójne ładowanie Bootstrap-CSS. Projekty, które obok bootstrap_grids pielęgnują własny build Bootstrap, w najgorszym razie ładują Bootstrap dwa razy. Rozwiązaniem jest całkowite dezaktywowanie zasobów dostarczonych przez rozszerzenie przez TsConfig i używanie wyłącznie własnego builda projektowego.

Trzecim problemem jest migracja przy upgrade TYPO3. Kto przechodzi z v9 na v11 lub z v11 na v12, stwierdza, że niektóre warianty grid w starszych wersjach Bootstrap nazywają się inaczej. Rozwiązaniem jest audyt używanych typów grid przed upgrade i celowy przebieg migracji SQL, który przepisuje stare warianty na nowe nazwy.

Czwartym problemem jest niespójna prezentacja w podglądzie edytora. Backend często pokazuje kontenery grid pusto lub w formie zredukowanej, dzięki czemu redaktorki nie rozpoznają, co we frontendzie rzeczywiście jest wyświetlane. Rozwiązaniem są renderowania podglądu bezpośrednio w module backendowym, które odwzorowują klasy Bootstrap i wizualnie pokazują szerokości kolumn. Nakład pracy na to nie jest trywialny, ale opłaca się szybko przy dużych zespołach redakcyjnych.

## Migracja i kompatybilność wersji

bootstrap_grids istnieje dla TYPO3 v9 do v12 i jest dalej pielęgnowane, oficjalny stan dla TYPO3 v13 został nadrobiony w 2025. Ważniejsze niż czysta kompatybilność wersji jest jednak strategiczne pytanie, czy bootstrap_grids jest w projekcie w ogóle jeszcze właściwą odpowiedzią. Dla nowych projektów zaleca się EXT:container: lżejszy, bliższy core, prostszy w pielęgnacji. Dla projektów istniejących stopniowe przejście jest często sensowne, zwłaszcza gdy system designu i tak jest przebudowywany.

Gosign migruje istniejące projekty bootstrap_grids na EXT:container lub na natywne layouty backendowe z Colpos. Migracja przebiega z wsparciem skryptu: istniejące kontenery grid są przez SQL i upgrade wizard przepisywane na struktury container, dzięki czemu redaktorki po upgrade nie muszą dotykać żadnej strony na nowo. To najszybsza droga do przeniesienia historycznego Site Package do nowoczesnego standardu TYPO3, bez utraty treści.

--- cHash TYPO3 - Konfiguracja cache | Gosign ---
> Konfiguracja cHash dla TYPO3: Kontroluje, które parametry URL wpływają na cache stron.

## Większość błędów "Page not found" w TYPO3 to problemy z cHash

Redaktor tworzy wiadomość z paginacją, strona działa. Odwiedzający klika na stronę 2 i widzi "Page not found". Developer sprawdza routing, konfigurację stron, .htaccess. Wszystko poprawne. Problem leży głębiej: mechanizm cHash TYPO3 nie oczekiwał parametru URL paginacji i odmawia dostarczenia strony. Problem na 5 minut, jeśli wiesz gdzie szukać - problem na 2 dni, jeśli nie.

cHash (Cache Hash) to mechanizm TYPO3 zabezpieczający cache stron. Oblicza hash ze wszystkich parametrów URL i porównuje go z zapisanym wpisem cache. Gdy pojawia się nieznany parametr, którego TYPO3 nie oczekuje, strona nie jest dostarczana. Chroni to przed cache poisoning, ale powoduje problemy przy prawie każdym nowym rozszerzeniu lub niestandardowym filtrze.

## Typowe scenariusze zastosowania

**Filtry i wyszukiwanie fasetowe w katalogach produktów.** Katalog produktów z 6 kryteriami filtrowania (kategoria, cena, kolor, materiał, dostępność, ocena) generuje parametry URL jak `&tx_catalog[color]=red&tx_catalog[price]=100-200`. Bez konfiguracji cHash TYPO3 pokazuje przy każdej kombinacji filtrów "Page not found". Konfiguracja cHash musi znać każdy z tych parametrów - albo jako "required" (wpływa na klucz cache), albo jako "excluded" (jest ignorowany i nie hashowany).

**Paginacja w listach aktualności i wydarzeń.** EXT:news i EXT:sf_event_mgt używają własnych parametrów URL dla numerów stron (`&tx_news_pi1[@widget_0][currentPage]=2`). Te parametry muszą znajdować się w konfiguracji cHash, aby strona 2 otrzymała własny wpis cache. Brak konfiguracji powoduje albo dostarczanie zawsze strony 1 z cache (zanieczyszczenie cache), albo błąd 404 paginacji.

**Parametry śledzenia i tagi UTM.** Kampanie marketingowe dodają parametry UTM do URL: `?utm_source=newsletter&utm_medium=email`. Bez wykluczenia tych parametrów każdy link kampanii tworzy nowy wpis cache. Przy stronie z 500 stronami i 10 kampaniami zamiast 500 powstaje nagle 5000 wpisów cache, obciążających serwer i spowalniających rozgrzewanie cache. Parametry UTM należy umieścić na liście wykluczeń.

## Architektura techniczna

Obliczanie cHash odbywa się w klasie rdzeniowej TYPO3 `CacheHashCalculator`. Algorytm pobiera wszystkie parametry URL, sortuje je alfabetycznie, serializuje i oblicza hash MD5. Ten hash jest dołączany do URL jako parametr `cHash`. Przy wywoływaniu strony TYPO3 sprawdza, czy dostarczony cHash zgadza się z obliczonym.

Konfiguracja odbywa się w `$GLOBALS['TYPO3_CONF_VARS']['FE']['cacheHash']` z czterema listami:

`cachedParametersWhiteList`: parametry włączane do hasha, tworzące własne wpisy cache. Typowe: parametry pluginów (`tx_news_pi1`, `tx_solr`).

`excludedParameters`: parametry całkowicie ignorowane. Typowe: parametry śledzenia (`utm_source`, `utm_medium`, `utm_campaign`, `utm_content`, `utm_term`, `gclid`, `fbclid`).

`requireCacheHashPresenceParameters`: parametry wymagające obowiązkowo cHash. Gdy taki parametr pojawia się w URL bez cHash, TYPO3 wyświetla błąd 404. To najbardziej restrykcyjny tryb.

`excludedParametersIfEmpty`: parametry ignorowane tylko gdy są puste.

Od TYPO3 v12 konfigurację cHash można również sterować przez Site Configuration (config.yaml), co upraszcza zarządzanie w konfiguracjach Multi-Site.

## Częste problemy i rozwiązania

**"Page not found" po instalacji rozszerzenia.** Nowe rozszerzenia wprowadzają własne parametry URL. Gdy nie ma ich w konfiguracji cHash, TYPO3 blokuje stronę. Rozwiązanie: sprawdzenie dokumentacji rozszerzenia (dobre rozszerzenia dostarczają konfigurację cHash w `ext_localconf.php`). Jeśli nie - ręczne dodanie parametrów do cachedParametersWhiteList lub excludedParameters. W narzędziu Install Tool TYPO3 w sekcji "Presets" tryb debugowania cHash oferuje pomoc.

**Zanieczyszczenie cache przez niekontrolowane parametry.** Boty i crawlery spamowe dołączają losowe parametry do URL. Bez ochrony każde takie wywołanie tworzy wpis cache. Cache rośnie do milionów wpisów, baza danych staje się wolna. Rozwiązanie: ustawienie `excludeAllEmptyParameters = true` i dodanie do WhiteList tylko jawnie znanych parametrów. Dodatkowo skrócenie interwałów garbage collectora cache (domyślnie: 86 400 sekund = 24 godziny).

**Błędy cHash trudne do debugowania.** TYPO3 pokazuje tylko "Page not found", nie dlaczego. W trybie produkcyjnym nie ma komunikatu błędu wskazującego na cHash. Rozwiązanie: tymczasowe ustawienie w `LocalConfiguration.php` `$GLOBALS['TYPO3_CONF_VARS']['FE']['pageNotFoundOnCHashError'] = false`. Wtedy TYPO3 wyświetla stronę mimo błędu cHash i loguje błąd. Po diagnozie ponowne ustawienie na true.

## Migracja i kompatybilność wersji

cHash to funkcjonalność rdzeniowa, nie rozszerzenie, i istnieje od TYPO3 v4. Konfiguracja zmieniała się w kolejnych wersjach: w TYPO3 v8 i wcześniejszych sterowana przez TypoScript, od v9 przez tablice PHP w LocalConfiguration, od v12 dodatkowo przez Site Configuration.

Przy migracji z TYPO3 v9/v10 na v12/v13 istniejące konfiguracje cHash muszą być sprawdzone. Nazwy parametrów rozszerzeń mogły się zmienić (np. zmiany namespace pluginów Extbase). Najbezpieczniejsza droga: po aktualizacji systematyczne testowanie wszystkich stron z parametrami (paginacja, filtry, wyszukiwanie) i sprawdzenie TYPO3 Error Log pod kątem wpisów cHash.

TYPO3 v13 dodatkowo zaostrza sprawdzanie cHash: nieznane parametry domyślnie prowadzą do 404, tryb debugowania musi być jawnie aktywowany. Gosign przy każdym projekcie aktualizacji TYPO3 sprawdza konfigurację cHash jako część procesu zapewnienia jakości.

--- calendarize_news TYPO3 - Kalendarz | Gosign ---
> Widok kalendarza dla GeorgRinger/news: Powtarzające się wydarzenia, filtr dat, widok miesiąca/tygodnia/dnia.

## Wydarzenia w tx_news należą do kalendarza, nie do chronologicznej listy

Większość witryn TYPO3 wykorzystuje tx_news Georga Ringera do wszystkiego: aktualności, wpisów blogowych, komunikatów prasowych i wydarzeń. Dla pierwszych trzech typów chronologiczna lista działa. Dla wydarzeń nie. Odwiedzający oczekują widoku kalendarza z prezentacją miesięczną, tygodniową i dzienną. Chcą kliknąć na datę i zobaczyć, co się tego dnia odbywa. calendarize_news buduje dokładnie ten most: pobiera istniejące rekordy News z polami daty i renderuje je jako kalendarz.

Rozszerzenie oszczędza przejście na samodzielny system wydarzeń. Kto już korzysta z tx_news, zachowuje swoją strukturę danych, swoje szablony i swoje procesy redakcyjne. Zamiast drugiego rozszerzenia z oddzielnym przechowywaniem danych jest widok kalendarza na istniejących danych.

## Typowe scenariusze zastosowania

**Kalendarze wydarzeń na stronach firmowych.** Placówka edukacyjna publikuje 150 seminariów rocznie przez tx_news. Każde seminarium ma datę początkową, datę końcową i godzinę. Bez calendarize_news odwiedzający widzą długą listę posortowaną po dacie. Z calendarize_news widzą kalendarz miesięczny, klikają na 15 maja i znajdują trzy seminaria. Konwersja z widoku kalendarza na stronę szczegółową u jednego klienta była o 40% wyższa niż z widoku listy.

**Powtarzające się wydarzenia bez duplikacji danych.** Cotygodniowe spotkanie, comiesięczny webinar, doroczna uroczystość firmowa: bez funkcjonalności powtarzania redaktor musi utworzyć 52 rekordy dla spotkania. calendarize_news obsługuje reguły powtarzania (dziennie, tygodniowo, miesięcznie, rocznie) z wyjątkami. Jeden rekord generuje 52 wpisy kalendarza. Gdy termin odpada, jest oznaczany jako wyjątek, nie usuwany.

**Połączone strony aktualności i wydarzeń.** Wiele organizacji na stronie głównej pokazuje "Aktualności" - mieszankę wiadomości i nadchodzących wydarzeń. calendarize_news umożliwia wyświetlanie tych samych rekordów na liście News chronologicznie i w kalendarzu według daty. Dwa widoki, jedno źródło danych, żadnego nakładu synchronizacji.

## Architektura techniczna

calendarize_news rozszerza tx_news o dodatkowe pola bazy danych w tabeli `tx_news_domain_model_news`: data początkowa, data końcowa, flaga całodniowa, reguła powtarzania i daty wyjątków. Logika powtarzania jest zaimplementowana w rozszerzeniu i generuje wirtualne terminy w czasie działania, bez tworzenia osobnego rekordu w bazie danych dla każdego pojedynczego terminu.

Prezentacja kalendarza odbywa się przez szablony Fluid renderujące siatkę miesięczną. Każda komórka (dzień) zawiera wydarzenia tego dnia. Szablony są w pełni konfigurowalne. Domyślnie rozszerzenie dostarcza szablony dla widoku miesięcznego, tygodniowego i dziennego. Nawigacja między miesiącami odbywa się przez AJAX lub klasyczne wywołanie strony, konfigurowalne przez TypoScript.

Integracja z tx_news jest głęboka: calendarize_news rejestruje się jako dodatkowy plugin (list type) i wykorzystuje wzorzec Repository tx_news. Kategorie, tagi i ograniczenia dostępu z tx_news są przejmowane. Wydarzenie przypisane do kategorii "Wewnętrzne" i widoczne tylko dla zalogowanych użytkowników pojawia się w kalendarzu również tylko po zalogowaniu.

Funkcja eksportu iCal generuje pliki .ics dla pojedynczych wydarzeń lub całego kalendarza. Odwiedzający mogą importować wydarzenia bezpośrednio do Outlook, Apple Calendar lub Google Calendar. Eksport korzysta z formatu iCalendar (RFC 5545) i uwzględnia reguły powtarzania.

## Częste problemy i rozwiązania

**Kalendarz nie pokazuje wydarzeń, mimo że News istnieją.** Najczęstsza przyczyna: pola daty rekordów News nie są wypełnione. tx_news ma pole `datetime`, ale calendarize_news używa własnych pól dla daty początkowej i końcowej. Po instalacji istniejące rekordy News muszą być uzupełnione o pola calendarize. Rozwiązanie: skrypt migracji kopiujący `datetime` do pól calendarize - 30 minut pracy developerskiej.

**Problemy wydajnościowe przy wielu powtarzających się wydarzeniach.** Gdy 50 powtarzających się wydarzeń generuje po 52 wirtualne terminy, rozszerzenie musi filtrować 2600 wpisów dla widoku miesięcznego. To jest odczuwalne przy każdym niecachowanym wywołaniu strony. Rozwiązanie: cachowanie obliczania powtórzeń (calendarize_news obsługuje Caching Framework TYPO3) i ograniczenie zakresu czasowego. Wydarzenia odległe o więcej niż 12 miesięcy w przyszłość nie muszą być obliczane przy każdym żądaniu.

**Responsywne wyświetlanie siatki kalendarza.** Siatka 7-kolumnowa dla dni tygodnia działa na desktopie, ale nie na smartfonach. Standardowe szablony calendarize_news nie są zoptymalizowane pod urządzenia mobilne. Rozwiązanie: dostosowanie szablonów Fluid i renderowanie na urządzeniach mobilnych widoku listy zamiast siatki. Breakpoint CSS przy 768px wystarczy do przełączania między siatką a listą.

## Migracja i kompatybilność wersji

calendarize_news zależy bezpośrednio od tx_news i podąża za jego cyklem wersji z opóźnieniem. Aktualna stabilna wersja obsługuje TYPO3 v11 i v12 z tx_news v10/v11. Dla TYPO3 v13 istnieje wersja beta na GitHubie.

Alternatywa calendarize (bez sufiksu _news) od lochmullera to samodzielne rozszerzenie kalendarza, które nie opiera się na tx_news, lecz posiada własny model danych. Jest aktywniej utrzymywane i oficjalnie obsługuje TYPO3 v12 i v13. Przejście z calendarize_news na calendarize wymaga migracji danych: dane wydarzeń muszą być przeniesione z tabeli tx_news do tabel calendarize.

Dla projektów migrujących na TYPO3 v13 z zachowaniem tx_news najpragmatyczniejszą drogą jest: użycie bety calendarize_news lub zbudowanie prezentacji kalendarza jako niestandardowego szablonu Fluid bezpośrednio w tx_news. Nakład pracy na niestandardowy szablon to 2-3 dni, a wynik jest niezależny od utrzymania osób trzecich. Gosign wdrożył obie drogi i rekomenduje odpowiedni wariant w zależności od złożoności reguł powtarzania.

--- camaliga TYPO3 - Elastyczne listy | Gosign ---
> Elastyczny plugin list dla TYPO3: Produkty, pracownicy, referencje - wszystko konfigurowalne przez jedno rozszerzenie.

## Do większości list w TYPO3 nie potrzeba własnego rozszerzenia

Firma chce pokazać referencje na stronie: logo, nazwa klienta, branża, krótki opis. Inna chce wylistować pracowników: zdjęcie, imię i nazwisko, dział, telefon. Trzecia potrzebuje przeglądu produktów: obraz, tytuł, cena, link do strony szczegółowej. Trzy różne wymagania, jeden wspólny wzorzec: ustrukturyzowane listy z konfigurowalnymi polami. camaliga rozwiązuje ten wzorzec jako generyczne rozszerzenie listowe, zamiast rozwijać osobne rozszerzenie dla każdego typu listy.

Rozszerzenie autorstwa quizpalme jest od lat dostępne w TYPO3 Extension Repository i aktywnie utrzymywane. Jego zaleta: jeden typ rekordu z elastycznymi polami pokrywa 80% wszystkich wymagań listowych. Wada: kto potrzebuje bardzo specyficznych modeli danych (zagnieżdżone relacje, wielojęzyczność na poziomie pól, złożona walidacja), natrafia na ograniczenia.

## Typowe scenariusze zastosowania

**Listy referencji i klientów.** Najczęstsze zastosowanie: loga i opisy klientów lub projektów w prezentacji gridowej. camaliga dostarcza gotowe layouty: grid, karuzela, akordeon, prezentacja zakładkowa. Dane są utrzymywane w backendzie TYPO3 jako rekordy, prezentacja sterowana przez szablony Fluid. U klienta ze 120 referencjami strona referencji oparta na camaliga była gotowa w 3 dni, włącznie z filtrowaniem po branży.

**Strony zespołu i pracowników.** Zdjęcie, imię i nazwisko, stanowisko, dane kontaktowe, opcjonalnie krótki tekst. camaliga odwzorowuje to przez swoje standardowe pola: tytuł, podtytuł, obraz, opis, link. Dla dodatkowych pól (numer telefonu, dział) można dodać pola niestandardowe przez TCA-Override. Alternatywą byłby EXT:tt_address, który jednak jest wyspecjalizowany w danych adresowych i dla stron zespołu często oferuje jednocześnie za dużo i za mało.

**Proste przeglądy produktów bez funkcji sklepu.** Przedsiębiorstwa, które chcą prezentować produkty, ale nie sprzedawać, nie potrzebują sklepu. camaliga dostarcza listę produktów z obrazem, tytułem, polem ceny i linkiem do karty katalogowej. Filtrowanie po kategorii jest możliwe przez zintegrowane przypisanie kategorii. Dla 50-200 produktów bez koszyka to wydajniejsze niż Aimeos czy bernetshop.

## Architektura techniczna

camaliga opiera się na Extbase/Fluid i podąża za wzorcem MVC. Centralny typ rekordu nosi nazwę `tx_camaliga_domain_model_content` i zawiera pola dla tytułu, podtytułu, opisu, krótkiego opisu, obrazu, linku, kategorii i kilku pól niestandardowych. Pola są zdefiniowane w TCA i mogą być rozszerzane lub redukowane przez TCA-Override w sitepackage.

Prezentacja odbywa się przez plugin frontendowy z konfigurowalnym layoutem. W FlexForm pluginu redaktor wybiera: którą kategorię wyświetlić, jaki layout zastosować, ile wpisów na stronę, czy paginacja jest aktywna. Layouty to szablony Fluid nadpisywane w sitepackage. camaliga dostarcza około 15 gotowych layoutów, od prostej listy po filtrowany grid z animacją Isotope.

Filtrowanie po kategorii wykorzystuje kategorie systemowe TYPO3. Każdy rekord camaliga może być przypisany do jednej lub wielu kategorii. Na frontendzie generowane jest menu filtrów, które filtruje przez JavaScript (Isotope lub filtry CSS) lub przez wywołanie strony. Wariant JavaScript jest szybszy, wariant z wywołaniem strony bardziej przyjazny dla SEO.

Do sortowania camaliga oferuje kilka opcji: po tytule, po dacie utworzenia, po ręcznym sortowaniu (Drag-and-Drop w backendzie). Ręczne sortowanie wykorzystuje pole `sorting` bazy danych i działa przez standardowy mechanizm sortowania TYPO3 w module List.

## Częste problemy i rozwiązania

**Layouty wyglądają inaczej niż oczekiwano.** Dołączone layouty camaliga opierają się na określonych frameworkach CSS (Bootstrap 3/4) lub bibliotekach JavaScript (Isotope, Masonry). Gdy strona używa innego frameworka, style kolidują. Rozwiązanie: nigdy nie używać standardowych szablonów, lecz tworzyć własne szablony Fluid w sitepackage. Nakład pracy na własny szablon to 1-2 godziny, po czym prezentacja jest w pełni kontrolowalna.

**Wydajność przy ponad 500 rekordach.** camaliga domyślnie ładuje wszystkie rekordy kategorii i filtruje na frontendzie przez JavaScript. Przy 500+ wpisach początkowy czas ładowania staje się odczuwalny (3-5 sekund przy 1000 rekordach z obrazami). Rozwiązanie: aktywacja paginacji i ograniczenie liczby stron do 20-50 wpisów. Dla filtrowania opartego na JavaScript: aktywacja lazy loading obrazów i doładowywanie danych przez AJAX.

**Wielojęzyczność wymaga obejścia.** camaliga obsługuje obsługę języków TYPO3, ale tłumaczenie każdego pojedynczego rekordu przy 200+ wpisach jest pracochłonne. Rozwiązanie: dla list czysto wizualnych (loga bez tekstu) wystarczy jeden rekord per język. Dla list z dużą ilością tekstu - przyspieszenie tłumaczenia przez przepływ pracy Inline-Translation TYPO3 lub napisanie skryptu migracji importującego tłumaczenia DeepL-API do wersji językowych.

## Migracja i kompatybilność wersji

camaliga jest aktywnie utrzymywane i obsługuje TYPO3 v11, v12 oraz według aktualnej mapy drogowej również v13. Rozszerzenie podąża za cyklem wydań TYPO3 z krótkim opóźnieniem. Instalacja przez Composer z Packagist jest możliwa, instalacja z TER również.

Kto migruje z niestandardowego rozszerzenia na camaliga, musi przenieść dane z niestandardowej tabeli do `tx_camaliga_domain_model_content`. To zadanie SQL, które w większości przypadków da się wykonać w mniej niż jeden dzień. W drugą stronę: kto przechodzi z camaliga na własne rozszerzenie Extbase, może wykorzystać strukturę danych jako wzór.

Dla bardziej złożonych wymagań (zagnieżdżone rekordy, relacje między listami, sterowanie przepływem pracy) zamiast camaliga zaleca się własne rozszerzenie Extbase lub EXT:mask. Gosign doradza w kwestii odpowiedniego rozwiązania i implementuje zarówno szybkie rozwiązania oparte na camaliga, jak i indywidualne rozszerzenia.

--- CAPTCHA TYPO3 - Ochrona antyspamowa | Gosign ---
> Ochrona antyspamowa dla formularzy TYPO3. Gosign doradza między widocznymi CAPTCHA (sr_freecap, hCaptcha).

## Dlaczego decyzja o CAPTCHA nie jest pytaniem technicznym, tylko pytaniem o ochronę danych

CAPTCHA brzmi jak trywialna decyzja: zabezpieczyć formularz przed botami, zainstalować rozszerzenie, gotowe. W praktyce jest to pytanie, którą usługę się osadza, jaką zgodę się generuje i jaki współczynnik konwersji się akceptuje. Dla TYPO3 istnieje kilkanaście podejść, które dzielą się na trzy grupy: widoczne CAPTCHA z zadaniem wizualnym, niewidoczne analizy zachowań jak reCAPTCHA v3 i czysto serwerowe metody bez interakcji użytkownika jak honeypoty lub rate-limiting. Właściwy wybór zależy mniej od siły botów, a bardziej od sytuacji regulacyjnej i grupy docelowej formularza.

## Typowe scenariusze zastosowania

Dostawca oprogramowania B2B prowadzi formularz kontaktowy z około 300 prawdziwymi zapytaniami miesięcznie i około 8 000 zgłoszeń od botów. Dostawca już używa Google Analytics, ma działające rozwiązanie zgody i nie traci podstawy prawnej, gdy wbuduje reCAPTCHA v3. W tym przypadku rozwiązanie niewidoczne jest skuteczne: boty są blokowane za kulisami, prawdziwi użytkownicy niczego nie widzą, współczynnik konwersji pozostaje stabilny. Zgoda i tak przychodzi przez istniejący baner zgody.

Administracja gminna z formularzami online dla spraw obywateli ma sytuację odwrotną: Google nie może być osadzone, baner zgody ma być minimalny, a formularz musi działać również bez JavaScript. Tu reCAPTCHA od razu odpada. Kombinacja honeypot plus rate-limiting na reverse proxy plus prosty test arytmetyczny w formularzu wyłapuje 95 procent botów, nie wymaga zewnętrznego zasobu i nie generuje obowiązku zgody.

Trzecim przypadkiem jest instytucja edukacyjna z silnie zróżnicowaną grupą użytkowników: studenci, wykładowcy, kandydaci zewnętrzni, w części z niepełnosprawnością wzrokową. Tu dostępność jest ważniejsza niż jakikolwiek zysk bezpieczeństwa, a czysto wizualne CAPTCHA jest problematyczne. Rozwiązaniem jest konfiguracja hCaptcha z aktywnym trybem dostępności lub instancja sr_freecap z alternatywą audio, uzupełniona o pełne opisy zgodne ze standardem WCAG.

## Architektura techniczna: trzy kategorie, trzy wzorce integracji

Widoczne CAPTCHA jak sr_freecap lub hCaptcha pracują według mechanizmu request-response: rozszerzenie generuje lub pobiera zadanie, pokazuje je użytkownikowi, a przy wysłaniu wprowadzenie jest walidowane po stronie serwera. W TYPO3 osadzenie odbywa się przez walidator w Form Framework, przez rozszerzenie ViewHelper Fluid lub przy Powermail przez plugin pola CAPTCHA. Wyzwaniem technicznym jest synchronizacja sesji i integracja w istniejące szablony Fluid.

Niewidoczne CAPTCHA jak reCAPTCHA v3 obliczają score między 0 a 1, który opisuje prawdopodobieństwo, że żądanie jest ludzkie. Score przychodzi jako dodatkowe pole z submit formularza, a rozszerzenie na podstawie konfigurowalnego progu decyduje, czy zgłoszenie zostanie zaakceptowane czy odrzucone. Dużą zaletą jest, że użytkownik niczego nie zauważa, wadą jest nieuniknione przesłanie danych do Google.

Rozwiązania oparte na honeypot pracują bez logiki klienckiej: niewidoczne pole wprowadzania jest dodawane do formularza HTML, ukryte przez CSS lub tabindex=-1. Ludzie go nie wypełniają, boty robią to bardzo często, a po stronie serwera każde zgłoszenie z wypełnionym honeypotem jest odrzucane. Uzupełnione o rate-limiting na bazie IP i weryfikowalny odstęp czasu między załadowaniem strony a submit, blokuje to większość prostych botów bez denerwowania choćby jednego użytkownika.

## Częste problemy i rozwiązania

Pierwszy problem to sam wybór: zespoły odruchowo sięgają po reCAPTCHA, bo jest znane i darmowe, i przeoczają obowiązek zgody. Porządna decyzja wymaga krótkiej oceny: jaka infrastruktura zgody istnieje? Jaki krąg użytkowników ma obsługiwać formularz? Jak duże jest faktyczne obciążenie botami? Gosign przeprowadza tę ocenę w ramach krótkiego audytu i rekomenduje dla każdego formularza właściwą metodę, zamiast forsować jednolite rozwiązanie.

Drugi problem to kombinacja kilku mechanizmów ochrony. Kto stosuje równolegle honeypot, CAPTCHA i rate-limiting, tworzy redundancję, ale też źródła błędów: legalny użytkownik zawodzi przy jednym z trzech kroków i traci zaufanie do formularza. Pragmatyczna odpowiedź to stopniowanie metod i aktywowanie najbardziej kosztownej ochrony tylko przy podejrzanym zachowaniu, na przykład pokazanie CAPTCHA dopiero wtedy, gdy rozpoznanie honeypot już zareagowało lub gdy w krótkim czasie wpłynęło kilka zgłoszeń z tego samego IP.

Trzeci temat to monitoring. Zespoły instalują ochronę i zapominają, że skuteczność spada, gdy tylko boty rozwiną dopasowane wzorce zachowań. Skuteczna konfiguracja CAPTCHA loguje współczynnik spamu i współczynnik fałszywych pozytywów oraz aktualizuje progi, gdy liczby się zmieniają. Gosign konfiguruje ten monitoring w ramach integracji rozszerzenia i dostarcza comiesięczną analizę, dzięki czemu widać, kiedy zmiana dostawcy lub dopasowanie staje się konieczne.

## Migracja i kompatybilność wersji

W TYPO3 v12 i v13 Form Framework jest centralnym punktem integracji dla rozwiązań CAPTCHA. Rozszerzenia, które jeszcze opierają się na starym FormBuilderze lub typie mailform z czasów core, muszą przy upgrade zostać przebudowane na nowy framework, co z reguły wymusza również ponowny wybór podejścia CAPTCHA. Powermail pozostaje popularną alternatywą i dostarcza własne typy pól CAPTCHA, które są utrzymywane równolegle.

Kto migruje z reCAPTCHA na rozwiązanie przyjazne RODO, oszczędza nie tylko obowiązek zgody, ale często też zyskuje czas ładowania: skrypt reCAPTCHA ma kilkaset kilobajtów i jest doładowywany przez każdą stronę zawierającą formularz. Konfiguracja honeypot radzi sobie bez zewnętrznego skryptu. Gosign wielokrotnie towarzyszył takim migracjom i dostarcza w zależności od modelu operacyjnego albo czystą konfigurację honeypot, albo kombinację z lokalnym zadaniem arytmetycznym, które dla ludzi jest trywialne, a dla botów stanowi zauważalną przeszkodę.

--- Cloudinary TYPO3 - CDN i obrazy | Gosign ---
> Cloudinary jako sterownik TYPO3 FAL. Automatyczna optymalizacja obrazów (WebP/AVIF), transformacje (Crop, Resize) i dostarczanie przez CDN na całym świecie.

## Obrazy to największy zabójca wydajności na stronach TYPO3, a Cloudinary rozwiązuje to automatycznie

W 90% witryn TYPO3, które osiągają słabe wyniki Core Web Vitals, problemem są obrazy. Za duże, zły format, brak wariantów responsywnych, brak CDN. Wewnętrzne przetwarzanie obrazów TYPO3 (GraphicsMagick/ImageMagick) tworzy wprawdzie miniatury, ale nie optymalizuje formatów (WebP/AVIF), nie rozpoznaje inteligentnie kadrowania i nie dostarcza automatycznie przez globalne CDN. Cloudinary jako sterownik TYPO3 FAL rozwiązuje wszystkie trzy problemy w jednym kroku.

Cloudinary przechowuje oryginalne obrazy w swojej chmurze, generuje zoptymalizowane warianty on-the-fly i dostarcza je przez ponad 300 lokalizacji Edge na całym świecie. Obraz przesłany jako 4 MB JPEG dociera do odwiedzającego jako 120 KB AVIF - automatycznie, bez konieczności działania ze strony redaktora.

## Typowe scenariusze zastosowania

**Korporacyjne strony z dużą ilością mediów.** Dostawca motoryzacyjny z 3000 zdjęć produktów, każde w 5 wariantach (miniatura, obraz listy, obraz szczegółowy, zoom, pobieranie), ma bez Cloudinary 15 000 plików na serwerze. Z Cloudinary przechowywanych jest 3000 oryginałów, 15 000 wariantów Cloudinary generuje na żądanie. Przestrzeń na serwerze spada o 80%, czasy ładowania o 60%. Largest Contentful Paint (LCP) u jednego klienta poprawił się z 4,1 do 1,3 sekundy.

**Międzynarodowe strony z globalną publicznością.** Gdy odwiedzający z Brazylii, Japonii i Niemiec wywołują tę samą stronę, Cloudinary dostarcza obrazy z najbliższego serwera Edge. Bez CDN ładowanie obrazu 500 KB z serwera we Frankfurcie dla odwiedzającego w Tokio trwa 2-3 sekundy. Z Cloudinary poniżej 200 milisekund.

**Portale redakcyjne z dużym wolumenem obrazów.** Portale informacyjne i magazyny codziennie przesyłają nowe obrazy. Cloudinary odciąża proces przesyłania: obrazy są wysyłane bezpośrednio do Cloudinary (Upload Widget lub API), przetwarzane, a w TYPO3 zapisywana jest tylko ścieżka referencyjna. Oszczędza to obciążenie serwera i przyspiesza przepływ pracy redakcyjnej.

## Architektura techniczna

Integracja Cloudinary z TYPO3 odbywa się przez sterownik FAL (File Abstraction Layer Driver). Rozszerzenie rejestruje się jako sterownik Storage i nadpisuje standardowe operacje plikowe: przesyłanie, pobieranie, usuwanie, listowanie. Redaktorzy pracują w znanym backendzie TYPO3, widzą obrazy w Filelist i dodają je jak zwykle do elementów treści.

Generowanie URL to rdzeń integracji. Zamiast lokalnego URL pliku (`/fileadmin/images/produkt.jpg`) sterownik generuje URL Cloudinary z parametrami transformacji: `https://res.cloudinary.com/[cloud-name]/image/upload/f_auto,q_auto,w_800/produkt.jpg`. Parametry `f_auto` (automatyczne rozpoznawanie formatu: WebP dla Chrome, AVIF dla Firefox, JPEG dla starszych przeglądarek) i `q_auto` (automatyczne dostosowanie jakości) są standardem.

Transformacje są sterowane przez parametry URL: szerokość (`w_`), wysokość (`h_`), tryb kadrowania (`c_fill`, `c_fit`, `c_thumb`), rozpoznawanie punktu fokusowego (`g_auto` rozpoznaje twarze i ważne obszary obrazu), overlay i znaki wodne. Każda kombinacja generuje osobny wariant, który Cloudinary tworzy przy pierwszym wywołaniu i następnie cachuje.

Generowanie responsywnych breakpointów jest szczególnie wartościowe: Cloudinary analizuje obraz i oblicza optymalne breakpointy na podstawie faktycznej zmiany wizualnej między rozmiarami. Zamiast stałych breakpointów przy 320, 768 i 1024 pikselach Cloudinary dostarcza np. 347, 691, 1024 - bo tam leżą największe różnice wizualne. Oszczędza to przepustowość bez widocznej utraty jakości.

## Częste problemy i rozwiązania

**Kontrola kosztów przy dużym ruchu.** Cloudinary rozlicza się w kredytach: transformacje, przechowywanie i przepustowość zużywają kredyty. Darmowy plan wystarcza na około 25 000 transformacji miesięcznie. Witryna TYPO3 z 500 stronami i 3000 obrazami może to przekroczyć w pierwszym miesiącu, gdy cache jest pusty. Rozwiązanie: inwalidacja cache Cloudinary tylko przy rzeczywistych zmianach obrazów, nie przy każdym deployu. Ustawienie formatu pobierania na `auto`, aby Cloudinary generowało tylko potrzebne formaty.

**Wyszukiwanie obrazów w backendzie TYPO3 jest wolne.** Sterownik FAL musi przy każdym wyszukiwaniu odpytywać API Cloudinary. Przy 10 000+ obrazach to jest odczuwalne. Rozwiązanie: indeks FAL TYPO3 jako główne źródło wyszukiwania i synchronizacja z Cloudinary tylko w razie potrzeby. Scheduler indeksera powinien działać w nocy, nie przy każdym dostępie do backendu.

**Istniejące adresy URL obrazów się zmieniają.** Po migracji z lokalnego przechowywania na Cloudinary zmieniają się wszystkie adresy URL obrazów. Dotyczy to SEO (Google Image Search), linkowania zewnętrznego i stron w cache. Rozwiązanie: generowanie adresów URL Cloudinary i jednoczesne ustawienie przekierowań 301 ze starych ścieżek na nowe adresy URL. EXT:redirects TYPO3 może to zautomatyzować.

## Migracja i kompatybilność wersji

Oficjalne rozszerzenie TYPO3-Cloudinary na GitHubie obsługuje TYPO3 v11 i v12. Dla v13 trwają prace nad kompatybilnością. Rozszerzenie jest utrzymywane przez społeczność TYPO3, nie przez Cloudinary.

Migracja z lokalnego przechowywania na Cloudinary odbywa się w czterech krokach: po pierwsze utworzenie konta Cloudinary i konfiguracja klucza API, po drugie przesłanie istniejących plików przez Bulk-Upload (Cloudinary CLI lub API), po trzecie przełączenie konfiguracji File Storage TYPO3 na sterownik Cloudinary i po czwarte odbudowa indeksu FAL. Przy 5000 plików cały proces trwa około jednego dnia roboczego.

Cloudinary oferuje darmowy plan (25 kredytów/miesiąc), który wystarcza dla małych stron. Dla witryn korporacyjnych z 10 000+ obrazami i dużym ruchem plan Plus kosztuje około 89 USD/miesiąc. Gosign wdrożył integracje Cloudinary dla projektów TYPO3 z maksymalnie 100 000 obrazami i doradza w kwestii optymalizacji kosztów i strategii transformacji.

--- CORS TYPO3 - Nagłówki Cross-Origin | Gosign ---
> Konfiguracja nagłówków Cross-Origin Resource Sharing dla TYPO3. Wymagane dla dostępu API, Headless-TYPO3 lub architektur mikroserwisowych.

## Dlaczego projekty Headless-TYPO3 bez prawidłowej konfiguracji CORS natychmiast zawodzą

Gdy system TYPO3 przestaje renderować tylko HTML i zaczyna dostarczać JSON-API do klientów JavaScript na innych domenach, przeglądarka napotyka Same-Origin-Policy. Bez wyraźnych nagłówków Cross-Origin-Resource-Sharing (CORS) blokuje każde wywołanie fetch, które pochodzi z innej origin niż samo API. Dla każdego podejścia Headless-TYPO3, każdej integracji mikroserwisowej i każdej konfiguracji, w której frontend na app.example.com rozmawia z backendem na cms.example.com, porządna konfiguracja CORS jest podstawowym warunkiem. Nie mieści się w pojedynczym rozszerzeniu, lecz jest współdziałaniem middleware TYPO3, konfiguracji serwera i konfiguracji reverse proxy.

## Typowe scenariusze zastosowania

Sprzedaż wysyłkowa z 40 000 zamówień miesięcznie prowadzi katalog produktów w TYPO3 i storefront oparty na React na osobnej domenie. Storefront pobiera dane produktów, stany magazynowe i informacje cenowe przez JSON-API, które jest zaimplementowane jako middleware TYPO3. Bez prawidłowych nagłówków CORS przeglądarka blokuje każde wywołanie AJAX z komunikatem "has been blocked by CORS policy" i storefront pozostaje pusty. Rozwiązaniem jest middleware, która precyzyjnie ustawia Access-Control-Allow-Origin na znane domeny frontendowe i prawidłowo odpowiada na preflight OPTIONS-Requests.

Drugim przypadkiem jest firma, która prowadzi TYPO3 jako hub treści dla wielu stron marek. Każda marka ma własną domenę, ale renderuje pewne moduły jak listy newsów lub obrazy produktów po stronie klienta z centralnej instancji TYPO3. CORS musi być tu skonfigurowane tak, żeby wszystkie domeny marek były dozwolone, ale obce już nie. Dynamiczna weryfikacja origin wobec whitelisty w konfiguracji Site TYPO3 jest właściwym podejściem, zamiast ogólnego wildcardu.

Trzeci kontekst to konsorcja naukowe, które pielęgnują bazę danych badawczą w TYPO3 i udostępniają przez otwarte API dostęp dla instytucji badawczych na całym świecie. Polityka CORS jest tu świadomie otwarta, ale musi być połączona z warstwą uwierzytelniania, dzięki czemu wprawdzie każda origin może wywołać API, ale dane wracają tylko z ważnym tokenem.

## Architektura techniczna: middleware, PSR-15 i preflight

W TYPO3 v12 i v13 właściwym miejscem dla nagłówków CORS jest middleware PSR-15, która jest wpięta w pipeline request. Sprawdza nagłówek Origin nadchodzącego requestu, porównuje go z skonfigurowaną whitelistą i ustawia odpowiednie nagłówki Access-Control-Allow-Origin, Access-Control-Allow-Methods i Access-Control-Allow-Headers w response. Dla requestów POST, PUT lub DELETE z niestandardowymi nagłówkami przeglądarka najpierw wysyła preflight OPTIONS-Request, na który middleware musi odpowiedzieć bez uwierzytelniania, inaczej właściwe zapytanie zawodzi.

Konfigurację można pielęgnować przez konfigurację Site jako tablicę YAML, alternatywnie bezpośrednio w ext_localconf.php własnego rozszerzenia. Ważne jest, że obsługa credentials (cookies, nagłówek Authorization) działa tylko wtedy, gdy Access-Control-Allow-Credentials jest ustawione na true, a Access-Control-Allow-Origin wskazuje na konkretną origin, a nie na wildcard. Ta kombinacja jest standardem CORS i częstym źródłem błędów przy zespołach, które najpierw testują z wildcardem, a potem chcą doposażyć credentials.

## Częste problemy i rozwiązania

Pierwszy problem to podwójne ustawienie nagłówków. Gdy TYPO3 ustawia nagłówek, a Apache lub Nginx dodatkowo ustawia ten sam nagłówek w konfiguracji serwera, do przeglądarki trafiają dwie wartości, a przeglądarka odrzuca request jako błędny. Rozwiązaniem jest zdefiniowanie CORS dokładnie w jednym miejscu, albo w middleware TYPO3, albo na serwerze, i świadome pozostawienie drugiego miejsca pustym. Przy reverse proxies jak Traefik lub Cloudflare dochodzi jeszcze trzecia warstwa, która również może manipulować nagłówkami.

Drugi problem to preflight OPTIONS-Requests. Przeglądarka wysyła OPTIONS-Request, aby sprawdzić przed właściwym wywołaniem, czy metoda jest dozwolona. Middleware TYPO3, które najpierw wykonują uwierzytelnianie, a potem ustawiają nagłówki CORS, odrzucają OPTIONS-Request, bo nie przynosi on nagłówka Authorization. Rozwiązaniem jest wczesne przechwycenie preflight-requests w łańcuchu middleware i odpowiedzenie bez autoryzacji.

Trzeci temat to kombinacja CORS i cache'owania. Reverse proxy jak Varnish cache'uje response z określonymi nagłówkami CORS, a przy następnym wywołaniu z innej origin ten otrzymuje stare nagłówki. Konsekwencją jest, że legalni użytkownicy nagle widzą błędy CORS, bo otrzymują cache'owaną odpowiedź dla innej origin. Nagłówek Vary na Origin rozwiązuje problem, ale zmusza cache do wielu wariantów per zasób.

## Migracja i kompatybilność wersji

TYPO3 v11 nie oferowało jeszcze porządnego middleware-API dla wszystkich kontekstów, dzięki czemu konfiguracja CORS była często załatwiana przez hooki lub bezpośrednio na serwerze. Od v12 middleware PSR-15 jest zaplanowanym sposobem, a ścieżka migracji ze starszych instalacji polega na przeniesieniu istniejących manipulacji nagłówków z konfiguracji Apache lub Nginx do middleware TYPO3.

Dla konfiguracji headless w TYPO3 v13 w połączeniu z EXT:headless od Macopedia CORS jest elementarnym budulcem i jest wyraźnie omówione w dokumentacji rozszerzenia. Gosign zrealizował kilka takich projektów headless i w razie potrzeby opiekuje się też uzgadnianiem między zespołami deweloperskimi, które odpowiadają oddzielnie za frontend i backend, dzięki czemu reguły CORS są jednoznacznie udokumentowane i synchronizowane przy każdej zmianie deploymentu. Zła reguła otwiera wektor ataku, w którym złośliwe strony mogą wykonywać akcje w imieniu zalogowanego użytkownika, dlatego porządna whitelista nie jest kwestią komfortu, lecz wymogiem bezpieczeństwa.

Warto też zauważyć, że CORS nie jest substytutem uwierzytelniania. Wiele zespołów deweloperskich konfiguruje hojne reguły CORS w przekonaniu, że dzięki temu API jest bezpieczne, i zapomina, że każda origin, którą przeglądarka zezwala, ma ten sam dostęp co bezpośrednio wywoływany klient. Uwierzytelnianie musi odbywać się niezależnie od CORS przez tokeny, API-keys lub session-cookies, a CORS tylko dba o to, aby przeglądarki w ogóle dopuszczały legalne wywołania do tych uwierzytelnionych endpointów. Kto rozumie to rozdzielenie, konfiguruje reguły CORS znacznie bardziej restrykcyjnie i zamyka wiele niezamierzonych luk.

--- Countdown TYPO3 - Timer | Gosign ---
> Rozszerzenie TYPO3 do odliczania: Odliczanie do wydarzeń, premier produktów, terminów ofert.

## Rozszerzenia countdown rozwiązują problem komunikacyjny, którego same teksty nie potrafią

Gdy targi zaczynają się za 23 dni, gdy oferta early-bird wygasa o północy lub gdy nowy sklep rusza 1 maja, zdanie "tylko kilka dni" nie wystarcza. Użytkownicy reagują na tykające zegary zdecydowanie silniej niż na statyczne daty, a na stronie TYPO3 najprostszym wariantem jest wbudowanie widocznego licznika odliczającego. Kilka rozszerzeń TYPO3 z TER oferuje tę funkcjonalność, najbardziej znane nazywa się po prostu "countdown". Dla każdej strony firmowej z ogłoszeniami wydarzeń, premierami produktów lub akcjami czasowymi jest to powracające wymaganie, które bez rozszerzenia zazwyczaj ląduje w indywidualnym JavaScript. Wybór między rozszerzeniem a własnym rozwiązaniem rzadko zależy od techniki, tylko od pytania, kto w redakcji ma móc pielęgnować countdown.

## Typowe scenariusze zastosowania sięgają od targów po akcje e-commerce

Pierwszym scenariuszem są targi i konferencje. Stowarzyszenie ogłasza swoje doroczne spotkanie sześć miesięcy wcześniej i chce uwidocznić pozostały czas, idealnie z dniami, godzinami, minutami i sekundami. Countdown działa na landing page, przełącza się w ciągu ostatnich 24 godzin i automatycznie znika po zakończeniu wydarzenia, bez konieczności dostosowywania strony przez redaktora. To oszczędza nie tylko nakład pielęgnacji, ale też zapobiega żenującym sytuacjom, jak licznik pokazujący po wydarzeniu wartość ujemną.

Drugim scenariuszem są premiery produktów i okna pre-order. Projekty e-commerce oparte na aimeos lub zewnętrznych sklepach używają countdownów na landing page, aby związać klientów z datą startu. Przy pre-orderach countdown służy jako sygnał pilności i wykazalnie zwiększa konwersję.

Trzecim scenariuszem są terminy rekrutacji i wniosków. Uczelnie pokazują na stronie rekrutacyjnej countdown do końca terminu, stowarzyszenia używają go przy cenach early-bird, instytucje publiczne przy terminach składania ofert w przetargach publicznych. Nie chodzi tu o marketing, tylko o serwis: odwiedzający powinni na pierwszy rzut oka rozpoznać, ile czasu im pozostało. Dla portali wnioskowych w nauce to praktycznie standard, bo wnioski o granty pracują ze stałym deadline i twardym cut-off.

## Architektura techniczna przebiega przez kombinację szablonu Fluid i minimalnego JavaScript

Klasyczne rozszerzenia countdown w TYPO3 składają się z dwóch części. Część backendowa to element treści lub plugin, w którym redaktor pielęgnuje datę docelową, czas docelowy, strefę czasową, etykietę i opcjonalnie komunikat końcowy. Część frontendowa renderuje te dane w szablon Fluid i dodaje małe JavaScript, które oblicza różnicę do aktualnego momentu i aktualizuje w DOM.

Większość rozszerzeń przynosi dodatkowo konfigurację renderowania: liczba pozycji (dni, godziny, minuty, sekundy), wyświetlanie jako grafika kołowa lub flip-clock, kolory i animacja. JavaScript działa zazwyczaj z setInterval 1000 ms i oblicza po stronie klienta, dzięki czemu cache serwera pozostaje niezmieniony. Ważne, żeby timer nie kończył się przy wartości ujemnej, lecz przez zdarzenie pokazywał komunikat "Wydarzenie rozpoczęte" lub "Oferta wygasła".

Dla projektów krytycznych pod kątem ochrony danych opłaca się spojrzeć na zależności JavaScript. Niektóre rozszerzenia doładowują jQuery lub MomentJS, co powoduje dodatkową ścieżkę renderowania. Nowoczesne warianty wystarczają kilkoma liniami vanilla-JS i CSS-Grid, które działa również bez rozszerzenia.

## Częste problemy dotyczą stref czasowych, cache'owania i SEO

Najczęstszym tematem wsparcia jest strefa czasowa. Redaktor wprowadza datę w backendzie, serwer stoi na UTC, odwiedzający żyje w CET, a countdown pokazuje godzinę za dużo. Rozszerzenie musi porządnie rozróżniać między czasem serwera, czasem redakcji backendowej a czasem przeglądarki. Zalecamy zawsze przekazywać datę docelową w ISO-8601 z wyraźną strefą czasową ("2026-05-01T12:00:00+02:00") do JavaScript.

Drugim problemem jest Page-Cache. Gdy wyrenderowana strona HTML jest cache'owana na godzinę, countdown nie może zawierać obliczonego po stronie serwera "23 dni 7 godzin", bo cache-hit zamraża tę wartość. Rozwiązanie: część Fluid renderuje tylko datę docelową jako data-atrybut, a obliczanie różnicy odbywa się wyłącznie w przeglądarce.

Po trzecie, SEO to ważny punkt. Czysto JavaScriptowy countdown nie pokazuje Google ani daty docelowej, ani okazji. Dla wyszukiwarek do strony należy JSON-LD schema:Event z startDate, endDate i name, żeby wyniki Google mogły prezentować wydarzenie jako Rich Snippet. Kto wbudowuje rozszerzenie, powinien więc nie tylko przekazywać datę docelową do timera, ale dodatkowo zapisywać jako dane strukturalne w nagłówku strony. Bez tego oznaczenia countdown pozostaje dla Google niewidoczny i traci swoją skuteczność marketingową już w wyniku wyszukiwania.

## TYPO3 v12 i v13: rozszerzenie lub smukłe alternatywne rozwiązanie

Czy rozszerzenie countdown ma sens na TYPO3 v12 i v13, zależy od rozmiaru projektu. Przy pojedynczej stronie wydarzenia wystarcza mały element treści z data-atrybutem i 30 liniami JavaScript, całkowicie bez overhead rozszerzenia. Dla redakcji z wieloma wydarzeniami, które chcą regularnie pielęgnować timer samodzielnie, rozszerzenie jest uzasadnione, bo redaktorzy potrzebują znanego elementu UI w backendzie.

Gosign buduje w praktyce jedno i drugie: dla jednorazowych launchy dostarczamy smukły element treści bez rozszerzenia, który składa się tylko z szablonu Fluid i mini-JS. Dla powtarzających się use cases integrujemy utrzymywane rozszerzenie i nadpisujemy szablon Fluid, żeby dopasować design do reszty projektu. Przy upgrade starych rozszerzeń countdown prawie zawsze ma sens przejście na wariant vanilla, bo oparte na jQuery stare wersje nie dotrzymują kroku ani w TYPO3 v12, ani w nowoczesnych budżetach wydajności.

--- DCE TYPO3 - Dynamiczne elementy treści | Gosign ---
> DCE: Custom Content Elements bez PHP. Konfiguracja, migracja na Mask/Container. Rozwój z wykorzystaniem AI.

## DCE przez lata było pierwszym wyborem dla Custom Content Elements - teraz czas na migrację

Między 2013 a 2020 rokiem DCE (Dynamic Content Elements) obok Mask było najpopularniejszą metodą tworzenia własnych elementów treści w TYPO3. Redaktorzy dostawali formularze backendowe z dokładnie takimi polami, jakich potrzebowali, programiści definiowali wszystko przez GUI - bez jednej linii PHP czy TCA. Tysiące witryn TYPO3 nadal działają na DCE. Problem: dalszy rozwój znacznie spowolnił. Mask prześcignął DCE pod względem użycia, a od TYPO3 v13 dostępna jest z natywnym Content Block API trzecia alternatywa, która nie wymaga już żadnego dodatkowego rozszerzenia.

Kto ma DCE w użyciu, nie musi migrować natychmiast. Ale kto planuje aktualizację TYPO3 do v12 lub v13, powinien uwzględnić ablację, ponieważ długoterminowe wsparcie jest niepewne.

## Typowe scenariusze zastosowań

**Istniejące projekty z 10 do 50 elementami DCE.** Witryny firm średniej wielkości, budowane między 2014 a 2020 na TYPO3 v7 do v10, używają DCE do wszystkiego: boksów teaserowych, zakładek, akordeonów, galerii, bloków cytatów, kart zespołu. Elementy działają, ale są związane z DCE. Przy aktualizacji TYPO3 trzeba sprawdzić, czy DCE jeszcze działa w docelowej wersji.

**Agencje z wieloma projektami TYPO3.** Agencje, które standardowo stosowały DCE w swoich projektach, stoją przed pytaniem: migrujemy wszystkie projekty naraz (duży nakład, czyste cięcie) czy projekt po projekcie przy następnej aktualizacji (mniejsze kroki, dłuższy okres)? Odpowiedź zależy od liczby dotkniętych projektów i planowanej docelowej wersji TYPO3.

**Rapid Prototyping elementów treści.** DCE nadaje się do szybkich prototypów: nowy element treści jest skonfigurowany w 15 minut, włącznie z formularzem backendowym i szablonem Fluid. Do proof-of-concept czy prezentacji klienckich to może wystarczyć. Dla produktywnych projektów Gosign zaleca jednak Mask, ponieważ workflow eksportowy (mask_export) i aktywna pielęgnacja oferują długoterminowe korzyści.

## Architektura techniczna

DCE przechowuje definicje elementów treści w bazie danych (tabela tx_dce_domain_model_dce), nie w plikach. Każdy element DCE składa się z konfiguracji (pola, typy, walidacja), szablonu Fluid (bezpośrednio w backendzie lub jako odwołanie do pliku) i opcjonalnych layoutów backendowych. Pola są definiowane w GUI DCE: Text, RichText, Integer, Float, Date, File (FAL), Select, Checkbox, Group (IRRE), Section (powtarzalne fieldsets).

Przy zapisie DCE generuje potrzebną konfigurację TCA i rejestruje element w Content Element Wizard. Dane elementów treści leżą w tabeli tt_content, rozszerzonej o specyficzne pola FlexForm DCE. Ta architektura FlexForm jest jedną z głównych różnic wobec Mask, który tworzy własne kolumny bazy danych w tt_content.

## Częste problemy i rozwiązania

**Dane FlexForm są trudne do migracji.** Ponieważ DCE przechowuje dane jako XML FlexForm w tt_content, migracja na Mask (który używa własnych kolumn) nie jest trywialna. XML FlexForm musi być sparsowany, a wartości przeniesione do nowych kolumn Mask. Rozwiązanie: skrypt migracyjny, który per element DCE odczytuje pola FlexForm i zapisuje je w odpowiednich polach Mask. Gosign ma do tego wielokrotnego użytku CLI-Command, który automatyzuje proces per element.

**Kontenery DCE i zagnieżdżone elementy.** DCE oferuje własną logikę kontenerową, która zagnieżdża elementy treści w sobie. Ta logika jest propriatarna i nie jest rozumiana przez żaden inny system. Rozwiązanie przy migracji: przejście struktur kontenerowych na b13/container i odtworzenie elementów podrzędnych jako elementów Mask.

**Wydajność przy wielu definicjach DCE.** Witryny z ponad 40 elementami DCE mają odczuwalne czasy ładowania backendu, ponieważ wszystkie konfiguracje FlexForm są odczytywane z bazy danych i parsowane przy każdym wywołaniu. Rozwiązanie: aktywacja cachowania DCE (ustawienie TypoScript `plugin.tx_dce.enableCache = 1`) lub przejście na konfigurację opartą na plikach (funkcja eksportu DCE).

## Migracja i kompatybilność wersji

DCE wspiera TYPO3 v11 i v12. Kompatybilność z TYPO3 v13 jest ograniczona: istnieje gałąź deweloperska, ale brak oficjalnie oznaczonego jako stabilny wydania (stan kwiecień 2026). Pielęgnacja społecznościowa jest mniej aktywna niż przy Mask, gdzie in2code jako główny deweloper prowadzi jasny cykl wydań.

Do migracji z DCE na Mask Gosign ma zestandaryzowany proces: inwentaryzacja elementów DCE (pola, typy, szablony), odtworzenie elementów Mask 1:1, migracja danych przez skrypt SQL (FlexForm-XML do kolumn Mask), dostosowanie szablonów Fluid (wywołania ViewHelper i nazwy zmiennych częściowo się zmieniają), testy i deinstalacja DCE. Nakład to od 0,5 do 2 godzin per element, w zależności od złożoności. Projekt z 25 elementami DCE jest zmigrowany w 3 do 5 dni.

Gosign zaleca przy decyzji migracyjnej pragmatyczny rachunek kosztów i korzyści. Jeśli następna aktualizacja TYPO3 jest planowana w ciągu 12 miesięcy i DCE nie działa stabilnie w docelowej wersji, migracja jest bezalternatywna. Jeśli projekt ma zostać na TYPO3 v11 lub v12 jeszcze 2 do 3 lat i DCE tam stabilnie funkcjonuje, migrację można przesunąć na następny relaunch. W każdym przypadku już teraz należy ustalić, czy Mask czy Content Block API jest celem, aby nowe elementy treści były tworzone bezpośrednio w systemie docelowym i nie powstawały dalsze zależności DCE.

--- Szablony i Sitepackages TYPO3 | Gosign ---
> Pakiet szablonów dla TYPO3. Gosign zaleca zamiast gotowych szablonów zawsze Custom Sitepackages - dokładnie dopasowane do Twoich wymagań, łatwe w utrzymaniu.

## Gotowe szablony TYPO3 oszczędzają czas na krótką metę i kosztują więcej na dłuższą

Pokusa jest duża: kupić gotowy szablon TYPO3 za 79 euro, zainstalować, wymienić logo - gotowe. W rzeczywistości zaczyna się tym cykl obejść, nadpisań i konfliktów wersji, który utrudnia każdą aktualizację i hamuje dalszy rozwój. dmpr_template reprezentuje tę kategorię. Gosign zaleca zamiast tego Custom Sitepackages: indywidualne pakiety szablonów, dokładnie dopasowane do wymagań, łatwe w utrzymaniu i wersjonowalne.

Sitepackage to rozszerzenie TYPO3 zawierające kompletną konfigurację frontendu: TypoScript, szablony Fluid, Partials, Layouts, CSS/SCSS, JavaScript i Backend-Layouts. To oficjalna best practice TYPO3 od wersji 8, zastępująca starą metodę konfigurowania szablonów w systemie plików.

## Typowe scenariusze zastosowania

**Relaunch korporacyjny z indywidualnymi wymaganiami.** Przedsiębiorstwo rozpoczyna relaunch strony. Projekt istnieje jako plik Figma, architektura informacji jako mapa strony, typy treści są zdefiniowane. Custom Sitepackage tłumaczy te wymagania 1:1 na TYPO3: każdy typ treści jest odwzorowany jako Backend-Layout lub Custom Content Element, szablony Fluid odpowiadają projektowi z dokładnością do piksela. Żaden framework szablonów nie stoi pomiędzy, wymuszając kompromisy.

**Konfiguracja Multi-Site ze współdzielonymi komponentami.** Korporacja prowadzi 5 witryn marek w jednej instancji TYPO3. Wszystkie współdzielą bazowy Sitepackage z systemem gridów, typografią i komponentami bazowymi. Każda marka ma własny Sitepackage rozszerzający bazowe rozszerzenie: kolory, logo, układy specyficzne dla marki. Zmiany w bazie wpływają na wszystkie 5 stron bez utrzymywania 5 osobnych baz kodu.

**Migracja ze starych konfiguracji szablonów.** Instalacje TYPO3 z wersji 6 lub 7 często używają TemplaVoila, Fluid Styled Content z rozbudowanymi nadpisaniami TypoScript, a nawet szablonów opartych na markerach. Migracja na czysty Sitepackage modernizuje cały stos frontendowy w jednym kroku: z dala od globalnych konfiguracji TypoScript, ku wersjonowalnemu rozszerzeniu z jasną strukturą katalogów.

## Architektura techniczna

Sitepackage to regularne rozszerzenie TYPO3 ze zdefiniowaną strukturą katalogów:

`Configuration/TypoScript/` zawiera konfigurację TypoScript: Constants, Setup, Page-TSconfig. Tu definiuje się, które szablony obowiązują dla których typów stron, jakie elementy treści są dostępne i jak są renderowane.

`Resources/Private/Templates/` zawiera szablony Fluid dla typów stron (Page), elementów treści (ContentElements) i Partials (wielokrotnie używalne fragmenty szablonów). Podział na Templates, Partials i Layouts podąża za konwencją Fluid TYPO3.

`Resources/Public/` zawiera CSS/SCSS, JavaScript, obrazy i fonty. Wszystko, co przeglądarka dostarcza bezpośrednio. W nowoczesnych konfiguracjach SCSS jest kompilowane narzędziem budowania (Vite, Webpack), a wygenerowane pliki umieszczane w `Resources/Public/Build/`.

`Configuration/TCA/` definiuje Backend-Layouts i Custom Content Elements. Backend-Layouts sterują, jakie kolumny i obszary są dostępne na stronie w backendzie. Custom Content Elements są definiowane przez TCA, TypoScript i szablony Fluid.

Sitepackage jest instalowane przez Composer i przypisywane do odpowiedniej strony TYPO3 przez Site Configuration (config.yaml). Wiele stron może używać tego samego Sitepackage (Multi-Site) lub mieć własne.

## Częste problemy i rozwiązania

**Gotowe szablony kolidują z aktualizacjami TYPO3.** Kupione szablony często nadpisują konfiguracje rdzenia i definicje TCA w sposób, który psuje się przy aktualizacjach TYPO3. Szablon opracowany dla TYPO3 v10 często nie działa po aktualizacji do v12, ponieważ wizardy TCA, rejestracja Backend-Layout i ViewHelpery Fluid się zmieniły. Z Custom Sitepackage samodzielnie kontrolujesz, które funkcje rdzenia są używane, i możesz przeprowadzać aktualizacje stopniowo.

**Struktura Sitepackage rozrasta się niekontrolowanie.** Z biegiem lat w Sitepackage gromadzą się dziesiątki Partials, osierocone szablony i fragmenty TypoScript. Rozwiązanie: regularne refaktoryzowanie. Czysty Sitepackage ma maksymalnie 20-30 Partials, jasne konwencje nazewnictwa (PascalCase dla szablonów, foldery według funkcji) i żadnych nieużywanych plików. Nakład pracy na refaktoryzację to 2-5 dni, w zależności od rozmiaru.

**Konflikty specyficzności CSS z Fluid Styled Content.** Fluid Styled Content TYPO3 dostarcza własne klasy CSS (`ce-`, `frame-`). Gdy Sitepackage używa własnych klas, powstają konflikty specyficzności. Rozwiązanie: albo całkowite zastąpienie Fluid Styled Content własnymi definicjami elementów treści (czystsze, ale bardziej pracochłonne), albo nadpisanie szablonów Fluid Styled Content i dostosowanie klas.

## Migracja i kompatybilność wersji

Koncepcja Sitepackage jest standardem od TYPO3 v8 i jest rozwijana z każdą nową wersją TYPO3. Podstawowa struktura (rozszerzenie z TypoScript, szablonami Fluid, TCA) pozostaje stabilna. Dostosowania przy aktualizacjach major dotyczą typowo składni TCA (wizardy, renderTypes), warunków TypoScript (nowe: Symfony Expression Language) i rejestracji modułów backendowych.

Migracja z gotowego szablonu (dmpr_template, j77_template, in2template) na Custom Sitepackage to przepisanie, nie portowanie. Analizuje się istniejące szablony, ekstrahuje pożądaną funkcjonalność i buduje ją na nowo w czystej strukturze Sitepackage. Przy typowym projekcie z 10 typami stron i 15 elementami treści nakład pracy to 2-3 tygodnie.

TYPO3 v13 wprowadza Content Blocks jako nową koncepcję definicji elementów treści. Content Blocks znacznie upraszczają tworzenie Custom Content Elements i redukują kod boilerplate. Sitepackages pozostają tym nienaruszone - mogą dodatkowo korzystać z Content Blocks. Gosign od lat buduje wyłącznie Custom Sitepackages i ma doświadczenie w efektywnej migracji istniejących konfiguracji szablonów na nowoczesne struktury.

--- Alternatywa Doodle TYPO3 | Gosign ---
> Uzgadnianie terminów bezpośrednio w TYPO3 - jak Doodle, ale bez zewnętrznej usługi. Przyjazne dla prywatności, zintegrowane z własną stroną.

## Uzgadnianie terminów powinno odbywać się na własnej stronie, nie u amerykańskiego dostawcy

Doodle jest praktyczne: wysyłasz link, uczestnicy wybierają swoje sloty czasowe, termin ustalony. Ale Doodle to zewnętrzny dostawca z serwerami w USA, ze śledzeniem, z reklamami w wersji bezpłatnej. Dla przedsiębiorstw świadomych RODO, dla instytucji publicznych i dla każdej organizacji, która nie chce przekazywać danych użytkowników zewnętrznym usługom, to jest problem. Alternatywa Doodle bezpośrednio w TYPO3 rozwiązuje ten problem: uzgadnianie terminów na własnej infrastrukturze, bez ciasteczek zewnętrznych dostawców, bez wypływu danych.

Grupa docelowa jest jasna: organizacje, które regularnie uzgadniają terminy z zewnętrznymi uczestnikami (zebrania rodziców, posiedzenia gremiów, warsztaty, szkolenia) i chcą zachować kontrolę nad danymi.

## Typowe scenariusze zastosowania

**Placówki edukacyjne z koordynacją zebrań rodziców.** Szkoły i przedszkola kilka razy w roku uzgadniają zebrania rodziców. 30 rodzin ma wybrać najlepszy z 5 możliwych terminów. Przez plugin TYPO3 na stronie szkoły głosowanie odbywa się bez konieczności zakładania konta i bez zewnętrznych usług. Wyniki pozostają na serwerze szkoły. U jednego organu prowadzącego z 12 szkołami i łącznie 6000 rodzin dzięki integracji TYPO3 zrezygnowano z abonamentu Doodle Premium (480 EUR/rok).

**Urzędy i instytucje publiczne.** Administracja samorządowa i urzędy wojewódzkie często nie mogą korzystać z usług chmurowych przetwarzających dane poza UE. Uzgadnianie terminów oparte na TYPO3 spełnia wytyczne IT urzędowe, ponieważ dane pozostają na własnym serwerze lub w samorządowym centrum danych.

**Wewnętrzne planowanie warsztatów.** Warsztaty międzydziałowe, spotkania strategiczne lub szkolenia wymagają uzgadniania terminów z 10-50 uczestnikami. Przez intranet (oparte na TYPO3) głosowanie można osadzić bezpośrednio, bez wysyłania zewnętrznego linku, który może być blokowany przez firmowy proxy.

## Architektura techniczna

Alternatywa Doodle w TYPO3 opiera się na pluginie Extbase z trzema tabelami bazy danych: ankiety (Polls), opcje terminów (Options) i głosy (Votes). Głosowanie jest umieszczane jako element treści na stronie TYPO3. Uczestnicy otwierają stronę, widzą opcje terminów i wybierają swoje dostępne przedziały czasowe.

Wprowadzanie danych odbywa się przez formularz oparty na Fluid. Każda opcja terminu jest wyświetlana jako wiersz, uczestnik zaznacza checkboxy (tak/nie/może). Opcjonalnie pytanie o imię uczestnika. Dla uwierzytelnionych użytkowników (logowanie Frontend) rozszerzenie może automatycznie wypełnić imię i zapobiec podwójnemu głosowaniu.

Prezentacja wyników pokazuje macierz: kolumny dla uczestników, wiersze dla opcji terminów, komórki oznaczone kolorami. Termin z największą liczbą potwierdzeń jest wyróżniony. Widok administracyjny w backendzie TYPO3 pokazuje wszystkie ankiety z wynikami i pozwala zamykać lub archiwizować zakończone głosowania.

Powiadomienia e-mail są opcjonalnie integrowalne: nowa ankieta utworzona, nowy uczestnik zagłosował, ankieta zamknięta. E-maile korzystają z Mail-API TYPO3 i można je dostosować przez szablony Fluid.

Zgodność z RODO (w Polsce: UODO) wymaga: automatycznego usuwania danych ankiety po konfigurowalnym okresie (np. 30 dni po zakończeniu ankiety), braku ciasteczek do udziału w głosowaniu (oparte na sesji) i polityki prywatności określającej cel i okres przechowywania.

## Częste problemy i rozwiązania

**Spamowe głosy.** Bez ochrony boty lub trolle mogą oddać setki fałszywych głosów. Rozwiązanie: pole honeypot (niewidoczne pole formularza, które wypełniają tylko boty), rate-limiting (maksymalnie 3 głosy per IP na godzinę) i opcjonalnie proste CAPTCHA. Logowanie Frontend jako wymóg całkowicie eliminuje spam, ale ogranicza użyteczność dla zewnętrznych uczestników.

**Brak integracji z kalendarzem.** Uczestnicy chcą od razu dodać ustalony termin do swojego kalendarza. Większość alternatyw Doodle TYPO3 nie oferuje eksportu iCal. Rozwiązanie: po zakończeniu głosowania wyświetlenie przycisku "Pobierz termin" generującego plik .ics. Nakład pracy na generowanie iCal to około 2 godziny developerskie.

**Mobilne wyświetlanie macierzy głosowania.** Macierz z 10 opcjami terminów i 20 uczestnikami jest nieczytelna na smartfonie. Rozwiązanie: na urządzeniach mobilnych przekształcenie macierzy w widok listowy, gdzie każdy termin jest wyświetlany osobno z przyciskami Tak/Nie. Przegląd wyników jest również wyświetlany jako lista pionowa zamiast tabeli poziomej.

## Migracja i kompatybilność wersji

W TYPO3 Extension Repository istnieje kilka rozszerzeń podobnych do Doodle o różnym zakresie funkcji i statusie utrzymania. Żadne z nich nie stało się standardem. Dla TYPO3 v12 i v13 zaleca się zatem rozwój niestandardowy na bazie Extbase, który pokrywa dokładnie potrzebne funkcje i pozostaje długoterminowo łatwy w utrzymaniu.

Nakład pracy na wersję podstawową (tworzenie ankiety, wybór terminów, wyświetlanie wyników) to 3-5 dni. Z powiadomieniami e-mail, eksportem iCal i backendem administracyjnym 7-10 dni. To mniej niż roczny abonament Doodle Premium dla 15+ użytkowników (od 6,95 EUR/użytkownik/miesiąc = około 1250 EUR/rok).

Dla przedsiębiorstw już korzystających z Microsoft 365 lub Google Workspace rozwiązanie TYPO3 jest istotne głównie dla zewnętrznych uczestników. Wewnętrzne uzgadnianie terminów przebiega efektywniej przez Outlook lub Google Calendar. Rozwiązanie TYPO3 uzupełnia je tam, gdzie zewnętrzni uczestnicy mają brać udział bez konta. Gosign rozwija takie niestandardowe rozwiązania na bazie Extbase i integruje je w istniejące instalacje TYPO3.

--- downloadmanager TYPO3 - Pobieranie plików | Gosign ---
> downloadmanager: Organizowanie, kategoryzowanie i śledzenie pobierania plików w TYPO3. Realizacja z wykorzystaniem AI.

## downloadmanager wprowadza porządek do obszarów pobrań TYPO3, gdy zagnieżdżony katalog plików już nie wystarcza, z kategoriami, tagami, wyszukiwaniem i licznikiem pobrań działającym bez cookies

Gdy projekt TYPO3 zarządza więcej niż dwudziestoma pobieraniami plików, ręczna pielęgnacja się załamuje. Redaktorzy linkują PDF-y przez Link-Browser, katalog rośnie chaotycznie, istniejące dokumenty są przypadkowo nadpisywane, a odwiedzający przez wyszukiwanie nic już nie znajdują. downloadmanager rozwiązuje dokładnie ten problem: przedstawia zbiór plików jako strukturalne repozytorium, z własnymi rekordami, kategoriami, tagami, metadanymi i interfejsem, który użytkownicy mogą celowo przeszukiwać. Dla firm z kartami produktów, stowarzyszeń ze zbiorami formularzy i gmin z centrami pobrań to standardowe rozwiązanie.

Różnica w stosunku do zarządzania przez czyste foldery FAL jest fundamentalna. Podczas gdy fileadmin odwzorowuje system plików, downloadmanager wprowadza nad nim warstwę redakcyjną: dokument może pojawiać się jednocześnie w kilku kategoriach, mieć tytuł wyświetlania niezależny od nazwy pliku i być sterowany przez planowanie publikacji. Dla redakcji z wymaganiami compliance to często warunek wstępny.

## Typowe scenariusze zastosowania

Klasycznym przypadkiem jest techniczny katalog produktów. Producent maszyn do każdej maszyny pielęgnuje kartę danych, instrukcję obsługi, certyfikat CE i listę części zamiennych. Każde pobranie otrzymuje kategorię produktu, przypisanie typu i opcjonalnie tag językowy. Odwiedzający filtrują po serii produktu i typie dokumentu, natychmiast otrzymują pasujące pliki, a sklep nie musi linkować każdego PDF pojedynczo. Sama strona produktu może pokazywać mini-obszar pobrań, który automatycznie listuje wszystkie dokumenty związane z maszyną, całkowicie bez redakcyjnej podwójnej pielęgnacji.

Drugim przypadkiem są obszary formularzy w gminach, urzędach i izbach. Formularze wniosków, ulotki informacyjne i statuty są grupowane tematycznie, często wielojęzycznie, okazjonalnie z ograniczeniem dostępu dla wewnętrznych obszarów członkowskich. downloadmanager umożliwia dokładnie tę segmentację przez fe_groups i kategoryzuje dokumenty według dziedziny. Dla administracji publicznej ważne jest ponadto, że daty publikacji i terminy obowiązywania mogą być zarządzane per dokument.

Trzecie zastosowanie: obszary prasowe i relacji inwestorskich. Raporty biznesowe, komunikaty prasowe i materiały graficzne są centralnie składowane, kategoryzowane po roku i opatrzone datą publikacji. Redakcja musi pielęgnować każdy dokument tylko raz, listy frontendowe są generowane automatycznie.

## Architektura techniczna

downloadmanager to rozszerzenie Extbase i pielęgnuje własne rekordy w tx_downloadmanager_domain_model_download. Każde pobranie odwołuje się do jednego lub kilku plików FAL i nosi pola meta jak tytuł, opis, kategoria, tagi, data publikacji, język i grupy dostępu. Moduł backendowy pozwala na import masowy, bulk-edit i workflow publikacji.

We frontendzie rozszerzenie dostarcza gotowe widoki listy i detalu jako szablony Fluid. Listy można filtrować po kategorii, tagu, wyszukiwanym hasłe lub kryterium sortowania, parametry są przekazywane przez parametr GET i uwzględniane w cache. Do wyszukiwania rozszerzenie używa pełnotekstowego wyszukiwania MySQL lub, na życzenie, podłączonej instalacji Solr.

Konfiguracja odbywa się przez TypoScript i FlexForm. Typowe ustawienia to standardowa kategoria, liczba wpisów na stronę, kolejność sortowania i integracja w własnym szablonie sitepackage. Przez EventListenery deweloperzy mogą wpinać własną logikę, na przykład powiadomienie e-mailowe przy nowych uploadach lub eksport do innych systemów.

Śledzenie pobrań jest centralną funkcją. Zamiast zewnętrznej analityki z cookies downloadmanager przy każdym kliknięciu zwiększa licznik serwerowy, który leży jako prosta kolumna integer w rekordzie. To jest przyjazne dla RODO, nie obciąża banera cookies i dostarcza wiarygodną informację, które dokumenty są rzeczywiście poszukiwane.

## Częste problemy i rozwiązania

Pierwszym problemem jest migracja z zasobu starego. Kto przez lata pielęgnował pobrania w Link-Browser, musi najpierw przenieść je do rekordów downloadmanager. Rozwiązaniem jest skrypt, który przechodzi przez istniejące struktury fileadmin, wyciąga metadane z nazw plików i tworzy rekordy. Gosign używa do tego pipeline wspieranego przez AI, który proponuje kategorie i tagi z zawartości plików i metadanych PDF, a redakcja musi je tylko potwierdzić.

Drugi problem: cache'owanie. Filtrowane listy z parametrami URL tworzą wiele wariantów cache, co nadyma cache TYPO3. Rozwiązanie leży w obsłudze cHash i w porządnej definicji, które parametry są istotne dla cache. Dla stron z wieloma filtrami edge-caching przez Cloudflare lub Varnish z regułą świadomą parametrów może być sensowniejszy niż cache'owanie serwerowe.

Trzeci problem: wielojęzyczność. Dokument istnieje w pięciu językach, ale ma być prowadzony jako jeden logiczny wpis, żeby metadane pozostawały zsynchronizowane. downloadmanager używa tu mechanizmu językowego TYPO3 z rekordami tłumaczeń. Ważne, aby redakcja rozumiała, które pola są pielęgnowane per język, a które obowiązują globalnie.

## Migracja i kompatybilność wersji

downloadmanager jest aktywnie utrzymywane i kompatybilne z TYPO3 v11, v12 i v13. Przy upgrade ze starszych wersji TYPO3 trzeba uważać przede wszystkim na zmiany w Extbase: metody repozytoriów i warstwa persystencji zmieniły się między v9 a v12 wielokrotnie, co może łamać własne rozszerzenia. Typowy projekt upgrade obejmuje zatem również dostosowanie własnych kontrolerów i szablonów.

Dla projektów startujących dziś opłaca się wcześniej decyzja, czy downloadmanager czy rozwiązanie przez własne rekordy Extbase jest właściwą drogą. Jeśli redakcja potrzebuje wyłącznie standardowych pobrań z kategoriami i tagami, rozszerzenie jest pragmatycznym wyborem. Jeśli potrzebne są ponadto złożone workflow (zatwierdzanie, wieloetapowa publikacja, wersjonowanie), rozwiązanie na miarę może być długoterminowo łatwiejsze w pielęgnacji.

Gosign migruje downloadmanager na nowe wersje TYPO3, towarzyszy migracjom starych zasobów i integruje rozszerzenie w istniejące sitepackages. Wspierana przez AI analiza pomaga automatycznie proponować kategorie i tagi z istniejących nazw plików i struktur katalogów, dzięki czemu ręczna praca pielęgnacyjna kurczy się do minimum.

--- dp_cookieconsent TYPO3 - Zgoda na cookies | Gosign ---
> dp_cookieconsent dla TYPO3: Zarządzanie cookies zgodne z RODO. Konfiguracja, audyt i optymalizacja, analiza z wykorzystaniem AI.

## Dlaczego sam baner cookies nie zapewnia zgodności z RODO

Każda instalacja TYPO3, która osadza Google Analytics, filmy YouTube, wtyczki social media lub zewnętrzne czcionki, stoi od wejścia w życie RODO i ustawy Prawo komunikacji elektronicznej przed tym samym zadaniem: przed załadowaniem skryptu firmy trzeciej musi istnieć aktywna, świadoma zgoda użytkownika. dp_cookieconsent to najpowszechniejsze w polskiej społeczności TYPO3 rozszerzenie, które wypełnia dokładnie to zadanie. Jest adresowane do firm, które chcą prowadzić stronę zgodnie z RODO bez zewnętrznego narzędzia zarządzania zgodą, i kierowane tym samym do średnich przedsiębiorstw, urzędów i instytucji edukacyjnych, które nie chcą ponosić bieżących kosztów komercyjnych CMP.

## Typowe scenariusze zastosowania

Firma przemysłowa z katalogiem produktów i 45 landing page'ami używa Google Analytics, filmu instruktażowego z YouTube, formularzy HubSpot i Google Fonts. Bez dp_cookieconsent wszystkie te usługi ustawiałyby cookies już przy otwarciu strony przez użytkownika, co groziłoby postępowaniem UODO za naruszenie Prawa komunikacji elektronicznej. Rozszerzenie grupuje usługi według kategorii, doładowuje kod HubSpot dopiero po zgodzie marketingowej i alternatywnie ładuje Google Fonts self-hosted, dzięki czemu zapytanie o zgodę tam całkowicie odpada.

Drugi typowy obraz dostarcza uniwersytet z głównym portalem i kilkoma zdecentralizowanymi stronami wydziałowymi. Każdy wydział prowadzi własne treści i osadza własne usługi, czasem mapkę z OpenStreetMap, czasem film YouTube, czasem tracking Piwik. dp_cookieconsent centralizuje zarządzanie zgodą w głównej instalacji, dostarcza baner przez partials Fluid do wszystkich sub-site'ów i zapisuje zgodę międzydomenowo, dzięki czemu użytkownik nie musi wyrażać zgody ponownie na każdej stronie wydziałowej.

Trzeci przypadek to administracje gminne z formularzami online i aplikacjami mapowymi. Dochodzi tu fakt, że inspektorzy ochrony danych regularnie przeprowadzają audyty i wymagają pełnej dokumentacji stosowanych usług. dp_cookieconsent dostarcza kategoryzację i tekst polityki prywatności bezpośrednio z TypoScript, co umożliwia redakcji pielęgnację bez ingerencji deweloperów.

## Architektura techniczna: blokowanie skryptów na poziomie szablonu

dp_cookieconsent działa według zasady "type-attribute swapping": wszystkie skrypty firm trzecich w kodzie źródłowym nie są dostarczane z type="text/javascript", tylko z neutralnym typem jak type="text/plain" i dodatkowym atrybutem data-cookieconsent. Przeglądarka ignoruje takie tagi i ich nie wykonuje. Dopiero gdy użytkownik wyrazi zgodę w banerze, mały runner JavaScript podmienia atrybuty typu i uruchamia odroczone wykonanie. Ten sam mechanizm działa dla iframe'ów, które do zgody są wyświetlane jako placeholder.

Konfiguracja rozszerzenia odbywa się w całości przez stałe i setup TypoScript, uzupełnione o plik YAML dla definicji usług. Każda usługa jest tam opisana nazwą, opisem, kategorią, nazwami cookies i czasem życia cookies, co znacznie upraszcza późniejszą dokumentację dla inspektora ochrony danych. Partials Fluid definiują wygląd banera i modala ustawień, dzięki czemu design można dostosować do identyfikacji korporacyjnej bez zmian w rozszerzeniu.

## Częste problemy i rozwiązania

Pierwszy i najczęstszy problem: pomimo aktywnego banera skrypty firm trzecich i tak się ładują, bo są osadzone przez ścieżki include, które nie przechodzą przez TypoScript. Typowe są statyczne bloki HTML, elementy Fluid z zakodowanymi tagami script albo include'y stopki ze starszych szablonów. Porządne rozwiązanie wymaga pełnego crawla strony z Browser Devtools lub zautomatyzowanym narzędziem, które loguje wszystkie wychodzące requesty i porównuje, które z nich są wyzwalane przed zgodą.

Drugi problem to zapisywanie zgody. dp_cookieconsent zapisuje zgodę w lokalnym cookie, co przy użytkownikach z restrykcyjną konfiguracją przeglądarki albo w trybie incognito prowadzi do powtarzających się wyświetleń banera. Kto chce mierzyć kwoty zgód, musi dodatkowo aktywować logowanie serwerowe, które zapisuje zgody wraz ze znacznikiem czasu i hashem IP w tabeli bazy danych i tym samym dostarcza wiarygodną dokumentację do audytów.

Trzeci temat dotyczy wydajności. Baner ładuje bundle JavaScript, który w zależności od zakresu skonfigurowanych usług może stać się zauważalnie duży i opóźniać First Contentful Paint. Gosign optymalizuje dostarczanie przez deferred loading, redukuje zbędne partials Fluid i tam, gdzie to możliwe, stawia na kombinację cookieless analytics i self-hosted assets, dzięki czemu baner jest potrzebny już tylko dla nielicznych usług.

Czwarty problem pojawia się przy zmianach zgody: użytkownik wyraża zgodę, korzysta ze strony, później zmienia zdanie i wycofuje zgodę. dp_cookieconsent resetuje flagę cookie, ale już załadowane skrypty działają dalej w tle, aż do przeładowania strony przez użytkownika. Porządne rozwiązanie wymaga triggera przeładowania albo celowego usunięcia już ustawionych cookies przy wycofaniu, tak aby cofnięcie zgody rzeczywiście stało się skuteczne, a nie było tylko formalnie udokumentowane.

## Migracja i kompatybilność wersji

dp_cookieconsent jest dostępne dla TYPO3 v11, v12 i v13, przy czym kompatybilność z v13 jest regularnie aktualizowana i obecnie uznawana za gotową do produkcji. Skok z v11 na v12 z reguły wymaga re-mapowania stałych TypoScript, ponieważ kilka nazw stałych zostało zmienionych. Dla użytkowników starszych wersji rozszerzenia warto wiedzieć, że definicje usług wcześniej były pielęgnowane wyłącznie przez formularze backendu, podczas gdy nowsze wersje pracują w oparciu o YAML i są tym samym znacznie łatwiejsze do osadzenia w workflow'ach Git.

Kto migruje z innego narzędzia zgody jak Cookiebot, OneTrust lub Usercentrics, oszczędza na bieżących kosztach licencyjnych, ale musi od nowa zbudować konfigurację usług. Gosign przeprowadza takie migracje wraz z analizą kwoty zgód, dzięki czemu przejście mierzalnie nie powoduje spadku akceptacji.

Dodatkowo warto strategicznie spojrzeć na pytanie, czy baner cookies jest w ogóle właściwą odpowiedzią. Kto konsekwentnie używa self-hosted fontów, przechodzi na cookieless analytics jak Matomo z wyłączonymi cookies lub Plausible i zastępuje embedy wideo statycznymi podglądami z doładowaniem po kliknięciu, może całkowicie usunąć baner dla wielu stron. Korzyść prawna jest znaczna, bo każda unikana zgoda to też unikane ryzyko postępowania UODO i jednocześnie współczynnik konwersji nie jest hamowany przez dialog banera.

--- dpn_glossary TYPO3 - Słownik fachowy | Gosign ---
> Rozszerzenie słownika dla TYPO3. Definiowanie terminów, automatyczne linkowanie w treści, wyświetlanie jako tooltip. Nawigacja alfabetyczna.

## Słownik przynosi wartość SEO, gdy wewnętrzne linkowanie działa automatycznie

Ręczne linkowanie terminów fachowych na stronie to syzyfowa praca. Firma z 200 podstronami i 80 terminami fachowymi musiałaby teoretycznie przeglądnąć każdą stronę i połączyć odpowiednie pojęcia ze stroną słownika. W praktyce to nigdy nie jest realizowane kompletnie, a przy nowych treściach zapomina się o tym. dpn_glossary automatyzuje ten proces: rozszerzenie rozpoznaje zdefiniowane terminy w treści i automatycznie linkuje je z odpowiednią stroną słownika lub wyświetla definicję jako tooltip.

Efekt SEO jest mierzalny. Każdy termin słownikowy tworzy własny indeksowalny URL. Automatyczne linkowanie z treści buduje gęstą wewnętrzną sieć linków, która pomaga Google ocenić autorytet tematyczny strony. Witryny z ponad 50 terminami słownikowymi generują typowo od 5 do 15% dodatkowego ruchu organicznego przez słowa kluczowe long-tail.

## Typowe scenariusze zastosowań

**Portale branżowe i strony sektorowe.** Ubezpieczalnie, instytucje finansowe, kancelarie prawne, firmy techniczne - wszędzie tam, gdzie fachowy język to codzienność, odwiedzający korzystają ze zrozumiałych definicji. Ubezpieczyciel z terminami takimi jak "suma ubezpieczenia", "udział własny", "roszczenie regresowe" może wyświetlać je w tekście płynnym jako tooltip, nie zakłócając czytelności. Jednocześnie istnieje alfabetyczna strona słownika jako leksykon.

**Dokumentacja techniczna i bazy wiedzy.** Firmy programistyczne prowadzące swoją dokumentację w TYPO3 używają dpn_glossary do konsystentnego wyjaśniania terminów technicznych (API, SDK, Webhook, OAuth). Nowi pracownicy i klienci znajdują definicje bezpośrednio w kontekście, bez konieczności szukania w oddzielnym dokumencie.

**Wielojęzyczne strony z terminami specyficznymi dla języka.** dpn_glossary wspiera mechanizmy tłumaczeniowe TYPO3. Terminy można definiować per język, włącznie z różnymi definicjami i skrótami. Termin taki jak "rada zakładowa" jest rozpoznawany i linkowany prawidłowo we wszystkich wersjach językowych treści.

## Architektura techniczna

dpn_glossary przechowuje terminy w własnej tabeli (tx_dpnglossary_domain_model_term). Każdy termin ma nazwę, definicję (RichText), opcjonalnie skrót, synonimy, media (obrazy, pliki) i URL szczegółów. Synonimy są ważne: termin "AI" może być zdefiniowany jako synonim "Sztucznej Inteligencji", dzięki czemu obie pisownie są automatycznie rozpoznawane w treści.

Automatyczne linkowanie działa jako Content-Post-Processor: po wyrenderowaniu przez TYPO3 treści strony, dpn_glossary przeszukuje output HTML pod kątem znanych terminów i zastępuje je linkami lub znacznikami tooltip. Przy tym pomijane są tagi HTML, atrybuty i istniejące linki, by uniknąć błędnych zagnieżdżeń. Zamiana jest konfigurowalna: tylko pierwsze wystąpienie na stronie, wszystkie wystąpienia lub brak zamiany (tylko tooltip).

Strona słownika jest konfigurowana jako strona pluginu TYPO3. Widok standardowy pokazuje nawigację alfabetyczną (A-Z) ze wszystkimi terminami. Każdy termin ma stronę szczegółową z definicją, powiązanymi terminami i opcjonalnie osadzonymi mediami.

## Częste problemy i rozwiązania

**Terminy są linkowane w nagłówkach, menu lub formularzach.** Automatyczne linkowanie czasem obejmuje obszary HTML, które nie powinny być linkowane. Rozwiązanie: rozszerzenie oferuje konfigurację Excluded Tags (np. h1, h2, h3, nav, form, a). Domyślnie nagłówki i linki są wykluczone, ale lista musi być dostosowana do każdego projektu.

**Wyświetlanie tooltipów koliduje z layoutem.** Tooltipy (popupy hover z definicją) mogą wychodzić poza krawędź strony lub zasłaniać inne elementy. Rozwiązanie: dostosowanie CSS tooltipa (max-width, z-index, pozycja). dpn_glossary dostarcza standardowy CSS, który można nadpisać przez TypoScript.

**Problemy z wydajnością przy wielu terminach.** Witryny z ponad 500 terminami odczuwają linkowanie przy niecachowanych stronach. Rozwiązanie: ograniczenie listy terminów do aktywnych (dezaktywacja przestarzałych), ograniczenie linkowania do określonych obszarów strony (tylko treść główna, nie stopka czy sidebar) i konsekwentne korzystanie z cache strony TYPO3.

## Migracja i kompatybilność wersji

dpn_glossary wspiera TYPO3 v11 i v12 w aktualnej stabilnej wersji. Kompatybilność z TYPO3 v13 jest w fazie rozwoju (stan kwiecień 2026). Rozszerzenie jest aktywnie utrzymywane, z regularnymi wydaniami i jasną ścieżką aktualizacji.

Dla projektów migrujących z innego rozwiązania słownikowego (np. samodzielnie zbudowanego pluginu lub migracji z WordPress), migracja danych jest prosta: eksport terminów jako CSV i załadowanie do tabeli dpn_glossary przez skrypt importowy. Gosign ma do tego narzędzie CLI obsługujące źródła CSV, JSON i XML.

Długoterminowo Gosign zaleca dodatkowo generowanie danych słownikowych jako Schema.org DefinedTerm Markup. dpn_glossary nie oferuje do tego natywnego wsparcia, ale nadpisanie szablonu Fluid może uzupełnić markup per termin. Poprawia to widoczność w Knowledge Panels i odpowiedziach generowanych przez AI.

Gosign kalkuluje pierwszą konfigurację projektu dpn_glossary (instalacja, konfiguracja, dostosowanie szablonu, import 50 terminów) na 1 do 2 dni deweloperskich. Bieżącą pielęgnację terminów przejmuje redakcja przez backend TYPO3.

--- Walidator linków TYPO3 - SEO | Gosign ---
> Sprawdzanie uszkodzonych linków dla TYPO3: Weryfikacja linków wewnętrznych i zewnętrznych, znajdowanie uszkodzonych połączeń.

## Uszkodzone linki kosztują pozycje w rankingu i zaufanie - a większość witryn TYPO3 ma ich więcej niż się spodziewano

Witryna TYPO3 z 500 stronami ma średnio 3000-5000 linków. Z nich z doświadczenia 2-5% jest uszkodzonych: usunięte strony, zmienione adresy URL zewnętrznych witryn, literówki w ręcznie wpisanych linkach. To 60-250 uszkodzonych linków, które kierują odwiedzających na strony 404 i sygnalizują Google, że witryna jest źle utrzymana. dreipc_linkvalidator sprawdza wszystkie linki wewnętrzne i zewnętrzne automatycznie i zgłasza problemy, zanim wpłyną na ranking i doświadczenie użytkownika.

TYPO3 posiada własny walidator linków w rdzeniu (EXT:linkvalidator). dreipc_linkvalidator rozszerza go o dodatkowe sprawdzenia, lepsze raporty i bardziej intuicyjny interfejs backendu. Dla witryn z ponad 200 stronami automatyczne sprawdzanie linków nie jest luksusem, lecz obowiązkiem.

## Typowe scenariusze zastosowania

**Witryny korporacyjne z linkami zewnętrznymi.** Strony firmowe linkują do partnerów, dostawców, stowarzyszeń branżowych, tekstów prawnych i artykułów prasowych. Zewnętrzne adresy URL zmieniają się bez ostrzeżenia. Link do rozporządzenia UE działa dziś, ale w przyszłym tygodniu zostanie przeniesiony. dreipc_linkvalidator sprawdza zewnętrzne linki przez żądanie HTTP i zgłasza 404, łańcuchy 301 (więcej niż 2 przekierowania) i timeouty.

**Uczelnie i placówki edukacyjne.** Witryny uczelni należą do najbardziej intensywnych pod względem linków: regulaminy studiów, formularze, spisy wykładów, katalogi pracowników, uczelnie partnerskie. Na witrynie uczelni z 12 000 stronami sprawdzanie linków znalazło 1400 uszkodzonych linków - z czego 800 wewnętrznych (usunięte strony, zrestrukturyzowane obszary) i 600 zewnętrznych.

**Portale redakcyjne z treściami archiwalnymi.** Portale informacyjne i magazyny z tysiącami artykułów linkują między sobą i do zewnętrznych źródeł. Przez lata uszkodzone linki się kumulują, szczególnie w starszych artykułach. Miesięczne sprawdzanie linków identyfikuje nowe problemy, zanim się nawarstwiają.

## Architektura techniczna

dreipc_linkvalidator rozszerza walidator linków rdzeniowy TYPO3 o dodatkowe mechanizmy sprawdzania. Walidator rdzeniowy sprawdza linki na poziomie bazy danych: analizuje pola `bodytext`, `header_link` i inne skonfigurowane pola w tabeli treści i identyfikuje linki do usuniętych stron lub plików. dreipc_linkvalidator uzupełnia to o sprawdzenia HTTP dla zewnętrznych adresów URL.

Sprawdzanie działa jako zadanie TYPO3 Scheduler. Typowa konfiguracja: raz na tydzień w nocy. Zadanie przeszukuje wszystkie skonfigurowane tabele i pola pod kątem linków, rozróżnia linki wewnętrzne (t3://page?uid=123), linki do plików (t3://file?uid=456) i linki zewnętrzne (https://...) i sprawdza dostępność każdego linku.

Linki wewnętrzne są sprawdzane w bazie danych TYPO3: czy linkowana strona nadal istnieje? Czy nie jest ukryta, usunięta, wygasła czasowo? Linki do plików sprawdzają, czy referencyjny plik nadal istnieje w FAL. Linki zewnętrzne są sprawdzane przez żądanie HTTP HEAD (szybsze niż GET, ponieważ nie jest przesyłane ciało). Przy błędzie HEAD następuje GET jako fallback.

Wyniki są prezentowane w widoku backendu: tabelarycznie, filtrowalne po typie błędu (404, 301, timeout, błąd SSL), po stronie i po redaktorze. Każdy wpis zawiera link, przyczynę błędu, stronę na której się znajduje i bezpośredni link do edytora TYPO3 Backend.

## Częste problemy i rozwiązania

**Fałszywe alarmy przy linkach zewnętrznych.** Niektóre witryny blokują zautomatyzowane żądania (ochrona przed botami, wyzwanie Cloudflare). Link działa w przeglądarce, ale walidator linków zgłasza 403 lub timeout. Rozwiązanie: ustawienie realistycznego nagłówka User-Agent, zwiększenie timeoutów do 15 sekund i umieszczenie znanych domen fałszywie alarmujących na białej liście. U klienta te dostosowania zredukowały wskaźnik fałszywych alarmów z 12% do poniżej 2%.

**Sprawdzanie trwa zbyt długo przy dużych witrynach.** Sprawdzenie 10 000 linków zewnętrznych sekwencyjnie trwa kilka godzin. Rozwiązanie: konfiguracja równoległego sprawdzania (5-10 jednoczesnych żądań), ograniczenie sprawdzania do linków zewnętrznych (linki wewnętrzne są szybko sprawdzalne zapytaniem do bazy danych) i dostosowanie częstotliwości sprawdzania (linki zewnętrzne co tydzień, wewnętrzne codziennie).

**Redaktorzy ignorują raporty.** Najczęstsza przyczyna rosnących list uszkodzonych linków: nikt nie czuje się odpowiedzialny. Rozwiązanie: aktywacja powiadomień e-mail do odpowiedzialnych redaktorów. dreipc_linkvalidator może wysyłać raporty e-mailem, rozdzielone według obszarów drzewa stron. Redaktor otrzymuje tylko uszkodzone linki w "swoim" obszarze.

## Migracja i kompatybilność wersji

Walidator linków rdzeniowy TYPO3 (EXT:linkvalidator) jest częścią rdzenia od v7 i jest ciągle rozwijany. W TYPO3 v12 i v13 walidator rdzeniowy jest znacznie ulepszony: lepsza wydajność, nowy interfejs w backendzie, przebudowana integracja Schedulera. dreipc_linkvalidator jako rozszerzenie obsługuje TYPO3 v10 i v11. Dla v12 i v13 nie istnieje oficjalna wersja.

Dla projektów na TYPO3 v12/v13 powstaje pytanie, czy dreipc_linkvalidator jest jeszcze potrzebny. Walidator rdzeniowy w v12 pokrywa wiele funkcji, które wcześniej były dostępne tylko przez dreipc: sprawdzanie HTTP linków zewnętrznych, integracja Schedulera, widok backendu z filtrowaniem. Co brakuje: raporty e-mail i funkcja białej listy dla fałszywych alarmów.

Alternatywa: uzupełnienie walidatora rdzeniowego o Custom Command generujący raporty e-mail. Nakład pracy to około jeden dzień developerski. Alternatywnie istnieją narzędzia zewnętrzne (Screaming Frog, Ahrefs, Semrush), które sprawdzają uszkodzone linki jako część audytu SEO, ale nie są zintegrowane z TYPO3. Gosign zaleca walidator rdzeniowy w połączeniu z comiesięcznym zewnętrznym crawlem dla maksymalnego pokrycia.

--- dreipc_pdf TYPO3 - Eksport PDF | Gosign ---
> Generowanie PDF od dreipc: Eksport stron TYPO3 jako PDF z Custom-Layout. Alternatywa dla web2pdf z własnym podejściem do renderowania.

## Gdy odwiedzający chcą pobrać strony TYPO3 jako PDF, wynik potrzebuje własnego układu

Odwiedzający klikają "Zapisz jako PDF" i oczekują schludnego dokumentu: identyfikacja wizualna firmy, logo, numery stron, bez nawigacji. To, co dostarcza funkcja drukowania przeglądarki, jest przeciwieństwem: obcięte kolumny, zbędne nagłówki i stopki, brakujące obrazy. dreipc_pdf rozwiązuje ten problem własnym podejściem do renderowania: rozszerzenie generuje pliki PDF z treści stron TYPO3 z dedykowanym układem druku, niezależnym od prezentacji w przeglądarce.

W przeciwieństwie do EXT:web2pdf, który konwertuje wyrenderowaną stronę HTML jako zrzut ekranu do PDF, dreipc_pdf pracuje w oparciu o dane. Renderuje elementy treści strony TYPO3 przez własne szablony i tworzy z nich sformatowany plik PDF. Pozwala to na pełną kontrolę nad marginesami stron, nagłówkami i stopkami, rozmiarami czcionek i podziałami stron.

## Typowe scenariusze zastosowania

**Karty katalogowe produktów z CMS.** Producenci maszyn, firmy chemiczne i producenci sprzętu medycznego zarządzają danymi produktów w TYPO3. Handlowcy potrzebują tych danych jako drukowalnego PDF na spotkania z klientami. dreipc_pdf tworzy ze strony produktu TYPO3 plik PDF z korporacyjnym układem: logo na górze, dane techniczne w tabelach, zdjęcie produktu, dane kontaktowe na dole. U klienta z 400 stronami produktów pliki PDF są automatycznie dostępne przyciskiem na każdej stronie, bez ręcznego tworzenia.

**Komunikaty prasowe i raporty biznesowe.** Działy komunikacji publikują komunikaty prasowe na stronie i jednocześnie oferują je do pobrania jako PDF. dreipc_pdf generuje PDF przy kliknięciu przycisku pobierania, zawsze na podstawie aktualnej treści. Bez ręcznego tworzenia PDF, bez ryzyka przestarzałych wersji do pobrania.

**Urzędowe materiały informacyjne.** Instytucje publiczne udostępniają formularze, broszury i pisma informacyjne jako PDF. Treści są zarządzane w TYPO3 i przy zmianach automatycznie dostarczane jako zaktualizowany PDF. Wersja PDF ma oficjalny układ z nagłówkiem urzędowym i sygnaturą.

## Architektura techniczna

dreipc_pdf wykorzystuje bibliotekę PHP PDF (typowo mPDF lub TCPDF) do generowania. Rozszerzenie rejestruje się jako Page-Type w TYPO3. Przy wywołaniu strony z parametrem PDF-Type (`?type=123`) zamiast wyjścia HTML generowany jest plik PDF i oferowany do pobrania.

Pipeline renderowania działa w trzech krokach. Po pierwsze rozszerzenie odczytuje elementy treści żądanej strony TYPO3 z bazy danych. Po drugie renderuje każdy element przez dedykowany szablon PDF Fluid (nie standardowy szablon webowy). Po trzecie przekazuje wyrenderowany ciąg HTML do mPDF/TCPDF, który tworzy z niego PDF ze skonfigurowanymi ustawieniami stron.

Szablony PDF to szablony Fluid z HTML/CSS, który rozumie mPDF. mPDF obsługuje podzbiór CSS2 i CSS3: marginesy stron (`@page`), nagłówki/stopki, tabele, obrazy, czcionki (osadzalne fonty TTF) i podziały stron (`page-break-before`, `page-break-after`). Flexbox i Grid nie są obsługiwane - praca nad układem odbywa się przez tabele lub Float.

Konfiguracja obejmuje: format strony (A4, Letter, niestandardowy), orientację strony (pionowa/pozioma), marginesy stron, domyślną czcionkę, szablony nagłówków/stopek i przypisanie typów elementów treści do szablonów PDF. Każdy element treści może mieć własny szablon PDF, różniący się od prezentacji webowej.

## Częste problemy i rozwiązania

**Obrazy brakują w PDF.** mPDF ładuje obrazy przez HTTP. Gdy serwer działa za reverse proxy lub w środowisku Docker, mPDF nie może rozwiązać własnych adresów URL obrazów. Rozwiązanie: osadzanie obrazów przez lokalną ścieżkę pliku zamiast URL. W szablonach PDF Fluid używanie absolutnej ścieżki serwera (`/var/www/html/fileadmin/...`) zamiast adresu webowego.

**Generowanie PDF wolne przy złożonych stronach.** Strona z 30 elementami treści i 15 obrazami może potrzebować 5-10 sekund na generowanie PDF. Przy jednoczesnych żądaniach obciąża to serwer. Rozwiązanie: cachowanie wygenerowanych PDF. Przy pierwszym wywołaniu PDF jest generowany i zapisywany w systemie plików. Kolejne wywołania dostarczają wersję z cache. Cache jest unieważniany przy zmianach treści.

**Podziały stron w niewłaściwych miejscach.** mPDF dzieli strony tam, gdzie treść przekracza wysokość strony - nawet w środku tabeli lub akapitu. Rozwiązanie: w szablonach PDF ustawianie jawnych podziałów stron (`<div style="page-break-before: always;">`) i ochrona tabel przed dzieleniem (`<table style="page-break-inside: avoid;">`).

## Migracja i kompatybilność wersji

dreipc_pdf to niszowe rozszerzenie z ograniczoną społecznością. Ostatnia stabilna wersja obsługuje TYPO3 v10 i v11. Dla v12 nie ma oficjalnej aktualizacji - nakład portowania jest umiarkowany (dostosowania Extbase, aktualizacje TCA).

Alternatywy dla TYPO3 v12/v13: EXT:web2pdf (oparte na zrzutach ekranu, prostsze, mniejsza kontrola nad układem), EXT:pdfviewhelpers (oparte na ViewHelperach, współpracuje z TCPDF), EXT:fluid_fpdf (szablony Fluid z backendem FPDF) lub niestandardowe rozwiązanie z mPDF jako pakietem Composer. Niestandardowe rozwiązanie ma zaletę pełnej kontroli i niezależności od rozszerzeń zewnętrznych.

Kto migruje z dreipc_pdf na niestandardowe rozwiązanie, może przejąć istniejące szablony PDF Fluid, o ile używają HTML/CSS kompatybilnego z mPDF. Wrapper renderowania musi być przepisany, ale szablony pozostają. Przy typowym projekcie z 5 szablonami PDF nakład migracji to 2-3 dni. Gosign wdrożył generowanie PDF w TYPO3 z różnymi bibliotekami i rekomenduje odpowiednie rozwiązanie w zależności od wymagań.

--- E-Paper TYPO3 - Magazyn online | Gosign ---
> Prezentacja magazynu online w TYPO3. Oparta na PDF lub HTML. Gosign doradza w kwestii nowoczesnych, wydajnych rozwiązań zamiast przestarzałych następców Flasha.

## Większość rozwiązań E-Paper w TYPO3 to następcy Flasha - i dokładnie tak się prezentują

Rozszerzenia E-Paper dla TYPO3 wywodzą się koncepcyjnie z ery Flasha: PDF jest przesyłany, biblioteka JavaScript symuluje przewracanie stron z animacją 3D. Na pierwszy rzut oka wygląda to imponująco. Na drugi: nie jest indeksowalne (Google nie może odczytać treści), nie jest responsywne (na smartfonie katastrofa), nie jest dostępne i z czasami ładowania przekraczającymi 5 sekund. Istnieją lepsze sposoby prezentowania magazynów i katalogów w TYPO3.

Kluczowe pytanie to nie "Który plugin E-Paper?", ale "Czy w ogóle potrzebujemy E-Paperu?". W większości przypadków odpowiedź brzmi: nie. Treść powinna znajdować się jako HTML na stronie, a nie jako PDF w katalogu do przeglądania.

## Typowe scenariusze zastosowania

**Magazyny firmowe i czasopisma dla klientów.** Działy marketingu produkują kwartalnie magazyny w druku i chcą udostępnić wersję cyfrową na stronie. Klasyczne podejście: przesłanie PDF, osadzenie widgetu katalogu. Lepsze podejście: opublikowanie artykułów jako pojedynczych stron TYPO3 (przez tx_news) z magazynową stroną przeglądową jako hubem. Każdy artykuł jest osobno indeksowalny, linkowalny i udostępnialny. PDF pozostaje jako opcja pobierania dla czytelników offline.

**Katalogi produktowe dla partnerów handlowych.** Hurtownie i przedsiębiorstwa B2B udostępniają swoim dealerom katalogi produktowe. Dane katalogowe istnieją często jako eksport z InDesign (PDF). Widget E-Paper czyni katalog przeglądalnym, ale nie przeszukiwalnym. Lepsza droga: ustrukturyzowane zarządzanie danymi produktowymi w TYPO3 i prezentacja katalogu jako filtrowalnej, przeszukiwalnej strony HTML. PDF służy jako wersja do druku do pobrania.

**Raporty roczne i raporty zrównoważonego rozwoju.** Spółki giełdowe publikują raporty roczne, które muszą optycznie odpowiadać układowi druku. Tutaj przeglądarka oparta na PDF jest uzasadniona, ponieważ układ jest wiążący i poszczególne strony wymagają dokładnych podziałów. Ale i tu obowiązuje: dane kluczowe (wskaźniki finansowe, oświadczenia zarządu) powinny być dodatkowo dostępne jako HTML.

## Architektura techniczna

Rozwiązania E-Paper w TYPO3 można podzielić na trzy kategorie:

**Katalogi do przeglądania oparte na PDF.** PDF jest przesyłany, biblioteka JavaScript (Turn.js, FlipBook.js, pdf.js) renderuje strony w przeglądarce. Biblioteka dzieli PDF na pojedyncze strony i wyświetla je jako elementy Canvas. Zalety: szybka konfiguracja, układ odpowiada 1:1 drukowi. Wady: brak wartości SEO (treść ukryta w PDF), słaba wydajność przy dużych PDF (50+ stron), brak responsywności.

**Układy magazynowe oparte na HTML.** Artykuły są zarządzane jako normalne elementy treści TYPO3 i prezentowane przez szablon magazynowy. Układ symuluje estetykę magazynu (wielkoformatowe obrazy, kolumny tekstowe, wyróżnione cytaty) przez CSS Grid i Tailwind. Zalety: pełna indeksacja SEO, responsywność, wydajność, dostępność. Wady: wyższy nakład początkowy, układ odbiega od druku.

**Podejście hybrydowe.** Artykuły istnieją jako HTML, dodatkowo dostępne jest pobieranie PDF. Na stronie przeglądowej odwiedzający widzi zajawki artykułów, w pasku bocznym pobieranie PDF całego magazynu. To podejście łączy wartość SEO z wiernością druku.

Do prezentacji PDF w TYPO3 nadaje się pdf.js (Mozilla), biblioteka open-source renderująca PDF natywnie w przeglądarce. pdf.js jest wydajniejszy niż katalogi oparte na Turn.js, rezygnuje z animacji przewracania i oferuje zamiast tego czystą, przewijalną prezentację z zoomem i wyszukiwaniem tekstu.

## Częste problemy i rozwiązania

**Czas ładowania PDF powyżej 5 sekund.** 40-stronicowy magazyn jako PDF waży 20-40 MB. Bez optymalizacji przeglądarka ładuje cały PDF, zanim wyświetli pierwszą stronę. Rozwiązanie: pdf.js obsługuje Byte-Range-Requests, przy których ładowana jest tylko żądana strona. Serwer musi obsługiwać `Accept-Ranges: bytes`. Dodatkowo optymalizacja PDF Ghostscriptem lub qpdf dla webu (`linearize`), aby pierwsza strona wyświetlała się natychmiast.

**Treść nie jest indeksowana przez Google.** Google crawluje PDF i indeksuje ich tekst, ale nie wewnątrz przeglądarki JavaScript. Gdy PDF jest wyświetlany tylko przez element Canvas w przeglądarce, Google nie widzi treści. Rozwiązanie: umieszczenie treści PDF dodatkowo jako ukrytego tekstu (aria-hidden, dostępnego dla czytników ekranu) na stronie HTML lub, lepiej, prezentacja treści jako natywnych elementów HTML i oferowanie PDF tylko do pobrania.

**Przestarzałe biblioteki katalogów.** Wiele rozszerzeń E-Paper korzysta z bibliotek, które nie były aktualizowane od lat. Turn.js (ostatnia aktualizacja 2013), FlipBook jQuery (zależność od jQuery) lub komercyjne biblioteki z wygasającymi licencjami. Rozwiązanie: migracja na pdf.js lub prezentację opartą na HTML. Oba są przyszłościowe i niezależne od licencji zewnętrznych.

## Migracja i kompatybilność wersji

Rozszerzenia E-Paper w TER są przeważnie przestarzałe. Większość obsługuje maksymalnie TYPO3 v10 lub v11. Dla v12 i v13 nie ma utrzymywanych rozszerzeń katalogów do przeglądania.

Zalecana droga dla TYPO3 v12/v13: osadzenie pdf.js jako samodzielnej biblioteki (bez potrzeby rozszerzenia) dla prezentacji opartych na PDF. Dla magazynów opartych na HTML: tx_news z szablonem magazynowym i własną kategorią "Wydania". Nakład pracy na niestandardowy układ magazynowy na bazie tx_news to 3-5 dni.

Kto migruje z istniejącego rozszerzenia E-Paper, ma trzy opcje: integracja pdf.js (1-2 dni, zachowuje model oparty na PDF), migracja HTML (5-10 dni, przenosi treść do artykułów tx_news) lub usługa zewnętrzna (Issuu, Yumpu) z osadzeniem TYPO3. Gosign rekomenduje podejście HTML dla maksymalnej wartości SEO i doradza przy decyzji między wariantami.

--- Extension Builder TYPO3 - Tworzenie | Gosign ---
> Standardowe narzędzie do tworzenia nowych rozszerzeń TYPO3. Wizualny edytor dla Extbase Models, Repositories i Controller.

## Extension Builder to narzędzie scaffoldingu, bez którego żaden deweloper TYPO3 nie jest naprawdę produktywny

Extension Builder od ponad dziesięciu lat jest oficjalnym narzędziem, którym deweloperzy tworzą w TYPO3 nowe rozszerzenia z niczego. Kto potrzebuje rozszerzenia Extbase z Domain-Model, Repository, Controller i modułem backendowym, otrzymuje przez Extension Builder wizualny edytor, który z diagramu domeny podobnego do UML generuje kompletny kod boilerplate: konfigurację TCA, schemat SQL, ext_localconf, stuby kontrolerów, szablony Fluid, pliki językowe. Dla agencji i zespołów produktowych, które regularnie dostarczają własne rozszerzenia, narzędzie pozostaje najszybszą drogą od koncepcji do pierwszego działającego prototypu.

Grupą docelową są zespoły deweloperskie TYPO3 w agencjach i w obszarze inhouse, które poza Site Packages odwzorowują w TYPO3 własną logikę biznesową. Typowe są rozszerzenia dla katalogów produktów, zarządzania wydarzeniami, portali pracy, portali klientów lub branżowych struktur danych. Bez Extension Builder każde z tych rozszerzeń musiałoby rosnąć ręcznie z pustego katalogu, z ryzykiem, że struktura odchyli się od schematu core TYPO3 i pęknie przy następnym upgrade.

## Typowe scenariusze zastosowania

Pierwszym scenariuszem jest prototyp portalu klienta. Producent maszyn z 2000 części zamiennych potrzebuje rozszerzenia, które udostępnia w backendzie rodziny produktów, produkty i dokumentacje jako własne struktury danych. Extension Builder tworzy w mniej niż 30 minutach kompletne rusztowanie: TCA, repozytoria, kontrolery, widok listy i detalu. Zespół natychmiast rozpoczyna logikę biznesową zamiast boilerplate.

Drugim scenariuszem jest sytuacja szkoleniowa i wdrożeniowa. Deweloper, który po raz pierwszy buduje rozszerzenie TYPO3, uczy się przez wygenerowany scaffold konwencji frameworka, bez gubienia się w dokumentacjach. Wygenerowany kod nie jest doskonały, ale jest idiomatyczny i pokazuje, jak jest pomyślany Extbase.

Trzecim scenariuszem jest migracja istniejących struktur danych. Kto musi postawić z starego eksportu CSV nowe rozszerzenie TYPO3 z dziesięcioma entytami, może wyklikać model domeny w Extension Builder, wyeksportować i następnie wypełnić wygenerowany kod komendą importu. To oszczędza kilka dni osobowych w stosunku do ręcznej budowy.

Czwartym scenariuszem jest standaryzacja w puli agencyjnej. Usługodawca z 15 deweloperami TYPO3 chce zapewnić, że każde nowe rozszerzenie ma ten sam podstawowy układ. Extension Builder wymusza ten układ przez generowanie, a własne szablony dla generatora kodu dbają o to, aby styl kodu, nagłówki licencyjne i struktura katalogów pozostawały identyczne między projektami.

## Architektura techniczna

Extension Builder to klasyczne rozszerzenie backendowe TYPO3 z własnym interfejsem użytkownika. W backendzie pojawia się moduł, w którym model domeny jest tworzony przez interfejs drag-and-drop: entyty jako skrzynki, properties jako pola, relacje jako linie. Przy eksporcie jest persistowany schemat JSON, z którego generator zapisuje kompletny kod rozszerzenia.

Instalacja odbywa się klasycznie przez Composer (`friendsoftypo3/extension-builder`). Rozszerzenie nie ma znaczenia produkcyjnego, należy do środowiska deweloperskiego i nie powinno być w ogóle aktywne w produkcji. Przy generowaniu Builder sięga do szablonów podobnych do Twig, które można w razie potrzeby dostosować projektowo, na przykład aby wymuszać własne style kodu lub odmienne nagłówki licencyjne.

Ważne, że Extension Builder nie opanowuje roundtripu: kto raz generuje, a potem rozszerza kod ręcznie, może wprawdzie otworzyć rozszerzenie w Builderze, ale w żadnym wypadku nie powinien generować ponownie, inaczej Builder nadpisze części ręcznie uzupełnionej logiki. W praktyce Builder jest używany jako jednorazowy krok scaffoldu, a potem rozszerzenie żyje w repozytorium Git.

## Częste problemy i rozwiązania

Pierwszym problemem jest pułapka nadpisywania po pierwszym uruchomieniu generatora. Zespoły, które uruchamiają Buildera po raz drugi, aby dociągnąć pole, tracą własne zmiany kodu. Rozwiązaniem jest jasna reguła w zespole: Extension Builder jest używany raz, reszta to praca ręczna. Późniejsze zmiany pól odbywają się ręcznie w TCA, SQL i modelu.

Drugim problemem jest kompatybilność z nowoczesnymi konwencjami PHP. Generator nadal tworzy kod, który opiera się na starszych wersjach PHP i starszych konwencjach Extbase. Rozwiązaniem jest pass cleanup bezpośrednio po generowaniu: uzupełnianie deklaracji typów, ustawianie return-types, wprowadzanie readonly-properties, zastępowanie przestarzałych komentarzy adnotacji natywnymi atrybutami.

Trzecim problemem jest nierefleksyjne używanie jako cudu kodu. Niektóre zespoły oczekują, że Extension Builder dostarczy aplikację gotową do produkcji. Tego nie robi, dostarcza rusztowanie. Każda logika biznesowa, każda walidacja, każda koncepcja bezpieczeństwa pozostaje zadaniem deweloperki.

Czwartym problemem są przestarzałe wzorce backendowe w wygenerowanym kodzie. Dostarczone kontrolery używają czasem jeszcze deprecated wzorców Extbase, które w aktualnym TYPO3 generują deprecation-warnings. Rozwiązaniem jest krok lint bezpośrednio po generowaniu, który sprawdza kod wobec aktualnych standardów kodowania i oznacza brakujące deklaracje typów lub przestarzałe adnotacje. Nowoczesne pipeline'y łączą ten krok z automatycznym przepisywaniem kodu przez Rector, aby nakład cleanupu był możliwie mały.

## Migracja i kompatybilność wersji

Extension Builder jest oficjalnie dostępny dla TYPO3 v11 i v12 i jest dalej utrzymywany przez Friends of TYPO3. Dla TYPO3 v13 istnieje zaktualizowana wersja, która podąża za nowymi konwencjami Extbase. Zespoły, które aktualizują istniejące rozszerzenia, z reguły nie potrzebują już Buildera, upgrade przebiega przez Upgrade Wizards w Install Tool i ręczne dostosowania.

Ciekawsze jest strategiczne spojrzenie: w czasach, gdy generatywna AI potrafi tworzyć kompletne szkielety rozszerzeń wraz z logiką biznesową z jednego promptu, wizualny Builder traci część swojej pierwotnej przewagi. Gosign łączy oba światy: dla standardowych scaffoldów z wieloma entytami Builder pozostaje efektywny, dla wymagających rozszerzeń z logiką specyficzną dla domeny generujemy kod bezpośrednio z briefingu merytorycznego ze wsparciem AI i oszczędzamy w porównaniu do klasycznej budowy ręcznej do 80 procent czasu rozwoju przy jednocześnie wyższej jakości kodu.

--- FFH TYPO3 - Custom rozszerzenie | Gosign ---
> Branżowe rozszerzenie TYPO3. Gosign oferuje Custom-rozwój i wsparcie dla specjalnych rozszerzeń, które nie są dostępne w TER lub nie są już utrzymywane.

## Branżowe rozszerzenia TYPO3 nie zawalają się na technice, ale na utrzymaniu

FFH reprezentuje kategorię rozszerzeń TYPO3 opracowanych dla konkretnego klienta lub konkretnej branży: specyficzne branżowo, funkcjonalne, ale nie powszechnie utrzymywane. W TER znajdują się setki takich rozszerzeń. Niektóre mają 5 pobrań rocznie, brak dokumentacji i ostatni commit sprzed 3 lat. To nie znaczy, że są złe. Znaczy, że potrzebują utrzymania, którego pierwotny developer już nie zapewnia.

Dla przedsiębiorstw zależnych od takich rozszerzeń powstaje praktyczne pytanie: dalej używać i samodzielnie utrzymywać, migrować na alternatywę, czy rozwijać od nowa. Wszystkie trzy drogi są możliwe. Decyzja zależy od złożoności rozszerzenia, dostępności alternatyw i presji wersjonowania TYPO3.

## Typowe scenariusze zastosowania

**Stowarzyszenia branżowe ze specjalnymi wymaganiami.** Izby rzemieślnicze, związki sportowe i zakłady ubezpieczeń społecznych prowadzą witryny TYPO3 z funkcjami, których żaden standardowy plugin nie pokrywa: katalogi członków z promieniem wyszukiwania, zarządzanie wydarzeniami z punktami kwalifikacyjnymi, rejestry branżowe ze statusem certyfikacji. Dla tego istnieją niestandardowe rozszerzenia opracowane 5-8 lat temu i od tego czasu minimalnie aktualizowane. Funkcja działa, ale aktualizacje TYPO3 stają się ryzykiem.

**Przedsiębiorstwa mediowe z przepływami redakcyjnymi.** Stacje radiowe, wydawnictwa i domy mediowe używają TYPO3 z rozszerzeniami dla playlist, planowania programu, archiwów medialnych lub syndykacji treści. Te rozszerzenia często zostały opracowane wewnętrznie lub przez agencję, która już nie obsługuje projektu. Kod działa na TYPO3 v9, ale migracja na v12 nie udaje się z powodu przestarzałych API.

**Instytucje publiczne z wymaganiami prawnymi.** Szkoły, muzea i biblioteki używają rozszerzeń do zarządzania godzinami otwarcia, wyszukiwania w katalogach lub rezerwacji wydarzeń. Wymagania są specyficzne (np. integracja z oprogramowaniem bibliotecznym jak Koha lub Alma), rozszerzenie zostało zbudowane raz i od tego czasu nie aktualizowane.

## Architektura techniczna

Branżowe rozszerzenia TYPO3 typowo podążają za wzorcem Extbase/Fluid: model domeny (klasy PHP), repozytorium (dostęp do bazy danych), kontroler (logika biznesowa) i szablony Fluid (prezentacja). Dane znajdują się we własnych tabelach bazy danych z prefiksem `tx_extensionname_`.

Najczęstsze wzorce architektoniczne: rozszerzenia oparte na pluginach z wyjściem frontendowym (prezentacja listowa, widok szczegółowy, filtrowanie), moduły backendowe do zarządzania danymi i zadania Schedulera do importu/eksportu. Wiele branżowych rozszerzeń integruje zewnętrzne systemy przez REST-API lub import CSV.

Jakość kodu różni się znacznie. Rozszerzenia od profesjonalnych agencji podążają za standardami kodowania TYPO3, korzystają z Dependency Injection i mają Unit Testy. Wewnętrznie opracowane rozszerzenia lub szybko zbudowane prace zlecone często mają hardkodowane konfiguracje, brak typowania i brak testów. Oba można utrzymywać, ale nakład pracy różni się o czynnik 3-5.

Typowy wzorzec analizy branżowych rozszerzeń: pomiar zakresu (linie kodu, liczba klas, liczba tabel bazy danych), sprawdzenie zależności (jakie API TYPO3 są używane, które są deprecated w v12/v13), ocena testowalności (czy istnieją Unit Testy, czy kod jest strukturalnie testowalny) i oszacowanie nakładu migracji.

## Częste problemy i rozwiązania

**Przestarzałe API blokują aktualizację TYPO3.** Rozszerzenie używa `$GLOBALS['TSFE']`, `GeneralUtility::_GP()` lub `ObjectManager::get()` - API, które w TYPO3 v12 są deprecated lub usunięte. Rozwiązanie: systematyczne refaktoryzowanie. Każde deprecated API ma udokumentowany zamiennik w TYPO3 Changelog. Przy rozszerzeniu z 5000 liniami kodu nakład refaktoryzacji to 3-7 dni, w zależności od liczby deprecjacji.

**Brak maintainera.** Pierwotny developer opuścił firmę, agencja już nie istnieje, pakiet TER jest porzucony. Rozwiązanie: fork kodu na GitHubie, włączenie rozszerzenia do własnego repozytorium Composer i samodzielne utrzymywanie. Lub zlecenie zewnętrznemu dostawcy. Fork jest prawnie bezproblemowy, gdy rozszerzenie jest na licencji GPL (standard dla rozszerzeń TYPO3).

**Brak dokumentacji.** Ani komentarze inline, ani zewnętrzna dokumentacja. Nowi developerzy muszą czytać kod, żeby zrozumieć funkcjonalność. Rozwiązanie: przed refaktoryzacją sporządzenie dokumentacji technicznej. 2-4 godziny analizy wystarczą dla rozszerzenia z 3000-5000 liniami kodu, aby udokumentować architekturę, model danych i logikę biznesową.

## Migracja i kompatybilność wersji

Branżowe rozszerzenia z natury rzeczy nie mają oficjalnego wsparcia v12/v13. Migracja musi być przeprowadzona indywidualnie. Nakład pracy zależy od trzech czynników:

Po pierwsze: jaka wersja TYPO3 jest punktem wyjścia? Z v9 na v12 to znacznie więcej pracy niż z v11 na v12, ponieważ v10 wprowadziło stos Middleware, a v11 zmieniło rejestrację modułów backendowych.

Po drugie: ile deprecated API jest używanych? Scanner rozszerzeń TYPO3 (w Install Tool) pokazuje to automatycznie. Rozszerzenie z 5 deprecjacjami wymaga jednego dnia, z 50 jednego tygodnia.

Po trzecie: jak dobrze ustrukturyzowany jest kod? Czysty kod Extbase można migrować mechanicznie. Kod proceduralny z bezpośrednimi zapytaniami do bazy danych wymaga przepisania.

Trzy opcje: portowanie (dostosowanie rozszerzenia do nowej wersji TYPO3, 3-10 dni), nowy rozwój (ta sama funkcja, czysta architektura, 2-4 tygodnie) lub znalezienie alternatywy (standardowe rozszerzenie pokrywające 80% funkcji plus niestandardowe dostosowanie). Gosign przeanalizował, sportował i rozwinął od nowa setki branżowych rozszerzeń TYPO3 i doradza w kwestii najbardziej ekonomicznej opcji.

--- filefill TYPO3 - Ładowanie brakujących plików | Gosign ---
> filefill: Automatyczne pobieranie brakujących plików z serwera produkcyjnego. Dla środowisk dev i staging. Z wykorzystaniem AI.

## filefill oszczędza deweloperom i agencjom dni nakładu synchronizacji, rozszerzenie automatycznie pobiera brakujące pliki z fileadmin z serwera produkcyjnego, gdy są rzeczywiście potrzebne

Kto pracuje przy istniejącym projekcie TYPO3, zna rytuał: lokalna konfiguracja stoi, dump bazy danych jest wczytany, ale na co drugiej stronie pojawiają się placeholdery zamiast obrazów. Powód jest banalny: katalog fileadmin systemu live zawiera gigabajty zasobów, których brakuje lokalnie. Klasycznym rozwiązaniem był rsync lub scp przez godziny. filefill wycina ten krok całkowicie. Zamiast kopiować wszystkie pliki wcześniej, rozszerzenie przy pierwszym dostępie pobiera dokładnie potrzebny plik z skonfigurowanego zdalnego serwera, on demand, transparentnie, z cache. Dla agencji, które stale pracują przy kilku projektach, oszczędza to nie tylko pamięć, ale też godziny per setup.

Zysk produktywności jest większy, niż wygląda na pierwszy rzut oka. Nowy deweloper nie jest gotowy do pracy dopiero po godzinie czekania na download, tylko po kilku minutach. Code review na zapomnianym feature-branch nie potrzebuje aktualnej synchronizacji plików. Krótkie odtworzenie raportu błędu nie ciągnie się przez pół dnia. Małe rozszerzenie adresuje tym samym prawdziwe wąskie gardło w codziennej pracy deweloperskiej.

## Typowe scenariusze zastosowania

Najczęstszym przypadkiem jest lokalna konfiguracja deweloperska. Deweloper klonuje projekt TYPO3, konfiguruje DDEV lub Docker i wczytuje aktualny dump bazy danych. Zamiast dodatkowo pobierać 30 GB danych fileadmin, konfiguruje filefill z URL bazy systemu live. Przy każdym wywołaniu strony, które żąda obrazu lub dokumentu, rozszerzenie sprawdza, czy plik istnieje lokalnie, i pobiera go w razie potrzeby. Po kilku dniach pracy lokalnie są tylko rzeczywiście potrzebne pliki, reszta pozostaje na serwerze.

Drugim przypadkiem są środowiska staging. Agencja pielęgnuje dla każdego projektu system staging, na którym redaktorzy testują treści przed go-live. Te systemy staging nie muszą mieć wszystkich obrazów, tylko te z aktualnych wydań. filefill dba o to, żeby starsze treści mimo to działały, bo pliki są w razie potrzeby ściągane z systemu live.

Trzecie zastosowanie: scenariusze disaster recovery i hotfix. Gdy system TYPO3 musi być szybko uruchomiony na nowej maszynie (na przykład po awarii serwera lub przy pilnej migracji środowiska), filefill może w pierwszych godzinach pomostować pozyskiwanie zasobów, aż pełny restore backup jest zakończony.

## Architektura techniczna

filefill wpina się w system FAL TYPO3, dokładniej w mechanizm Resource-Retrieval. Gdy tylko TYPO3 żąda pliku z lokalnego storage i stwierdza, że nie istnieje, działa event-listener filefill. Rozszerzenie sprawdza listę skonfigurowanych "sources" w kolejności ich priorytetów i próbuje pobrać plik stamtąd. Pomyślnie załadowane pliki są zapisywane lokalnie, dzięki czemu następny dostęp obywa się bez zdalnego requestu.

Konfiguracja odbywa się przez ustawienia rozszerzenia w Install-Tool. Zazwyczaj dodawane jest zdalne źródło z bazowym URL, opcjonalnie z credentials HTTP-Basic-Auth. Dla konfiguracji z CDN lub S3 ta ścieżka może również służyć jako źródło. Rozszerzenie wspiera kilka sources, co jest pomocne dla bardziej złożonych scenariuszy z oddzielnymi serwerami zasobów.

Ważne, że filefill działa tylko pasywnie. Rozszerzenie nie ładuje nic wcześniej, lecz reaguje wyłącznie na konkretne żądania plików. To czyni go oszczędnym w zużyciu zasobów i niepozornym w działaniu. Integracja z DDEV, Docker Compose lub Lando jest trywialna, bo rozszerzenie nie potrzebuje dodatkowych usług.

## Częste problemy i rozwiązania

Pierwszym problemem są ograniczenia dostępu. Gdy serwer live dostarcza obrazy tylko dla zalogowanych użytkowników lub chroni określone ścieżki przez htaccess, filefill nie może ich łatwo pobierać. Rozwiązanie leży w prawidłowej konfiguracji uwierzytelniania HTTP i ewentualnie w regule whitelist na serwerze live, która daje środowisku deweloperskiemu dostęp do ścieżki fileadmin.

Drugi problem: przypadkowe użycie w produkcji. Gdy filefill jest aktywne w środowisku live, a zdalne źródło jest tym samym środowiskiem, powstaje niebezpieczna rekursja. Rozszerzenie nigdy nie powinno działać w produkcji. Pragmatyczne rozwiązanie to prowadzenie filefill tylko w bloku composer "require-dev" i aktywowanie przez zmienne środowiskowe, nie przez Install-Tool.

Trzeci problem: niespójne stany plików. Gdy system live wymienia plik, ale lokalna kopia jest już cache'owana, deweloper widzi starą wersję. Rozwiązaniem jest okazjonalne czyszczenie lokalnego fileadmin lub cache-busting przez zdalne źródło. Dla codziennej pracy to rzadko problem, bo nazwy plików przy wymianie zazwyczaj są nowe.

## Migracja i kompatybilność wersji

filefill jest kompatybilne z TYPO3 v11, v12 i v13 i jest aktywnie rozwijane. Przy upgrade wersja rozszerzenia powinna pasować do wersji TYPO3, bo system zdarzeń FAL doświadczył mniejszych zmian między v11 a v12. Kto używa rozszerzenia w istniejących procesach deweloperskich, musi przy większych upgrade krótko przetestować, czy wszystkie sources są nadal poprawnie osiągalne.

Pokrewnym rozwiązaniem jest EXT:aus_driver_amazon_s3, które trzyma fileadmin bezpośrednio w bucket S3. Różnica: aus_driver_amazon_s3 to rozwiązanie produkcyjne, filefill to pomoc deweloperska. Oba się uzupełniają, projekt ze storage S3 w produkcji może lokalnie używać filefill, żeby pobierać z bucket tylko aktualnie edytowane pliki.

Dla agencji, które używają filefill standardowo, opłaca się dokumentacja w wiki projektu, która wyjaśnia, jak rozszerzenie jest aktywowane, jakie credentials są potrzebne i jak postępować przy problemach. To redukuje nakład wsparcia w zespole i czyni onboarding nowych deweloperów niezawodnym. Uzupełniająco opłaca się krótki skrypt, który przy konfiguracji nowego środowiska lokalnego automatycznie wpisuje prawidłową konfigurację.

Gosign instaluje i konfiguruje filefill w środowiskach deweloperskich i integruje rozszerzenie w setupy DDEV i Docker, dzięki czemu nowi członkowie projektu są gotowi do pracy w ciągu kilku minut.

--- Find TYPO3 - Wyszukiwanie Solr | Gosign ---
> Rozszerzenie wyszukiwania Solr dla TYPO3. Alternatywa dla standardowego stosu EXT:solr. Elastyczna konfiguracja wyszukiwania, Faceted Search, Autocomplete.

## Wbudowane wyszukiwanie TYPO3 wystarcza do 500 stron, potem potrzebny jest Solr

Standardowe wyszukiwanie w TYPO3 (EXT:indexed_search) przeszukuje wyrenderowany HTML i przechowuje go w tabeli bazy danych. Dla małych witryn z 50-500 stronami to działa. Od 1000 stron wyszukiwanie staje sie wolne (czasy odpowiedzi powyżej 2 sekund), od 5000 stron nieużywalne. EXT:find to oparte na Solr rozszerzenie wyszukiwania, oferujące alternatywę dla ugruntowanego stosu EXT:solr: bardziej elastyczna konfiguracja, własny Query-Builder i inne podejście do wyszukiwania fasetowego.

Wybór między EXT:find a EXT:solr to nie kwestia jakości, lecz architektury. EXT:solr ma większą społeczność i więcej funkcji od razu. EXT:find oferuje większą elastyczność w konfiguracji zapytań i nadaje się dla projektów z nietypowymi wymaganiami wyszukiwania.

## Typowe scenariusze zastosowania

**Portale fachowe z wyszukiwaniem domenowym.** Portal prawniczy z 15 000 dokumentów potrzebuje jednoczesnego wyszukiwania paragrafów, sygnatur i słów kluczowych. EXT:find pozwala definiować różne typy zapytań per pole: dokładne wyszukiwanie dla sygnatur, fuzzy dla tekstu swobodnego, filtry zakresowe dla pól daty. U wydawcy fachowego z 22 000 dokumentów EXT:find dostarczał wyniki wyszukiwania w poniżej 100 milisekund, niezależnie od złożoności filtrowania.

**Wyszukiwanie e-commerce z atrybutami produktów.** Produkty mają atrybuty (kolor, rozmiar, waga, cena), które służą jako facety w wyszukiwaniu. Odwiedzający szuka "śruba M8", filtruje po materiale "stal nierdzewna" i cenie "poniżej 5 EUR". EXT:find mapuje te facety bezpośrednio na pola Solr i automatycznie generuje nawigację filtrów z konfiguracji Solr.

**Wielojęzyczne wyszukiwanie pełnotekstowe.** Międzynarodowe witryny potrzebują wyszukiwania uwzględniającego specyfikę językową: niemieckie złożenia, polską deklinację, hiszpańskie akcenty. Solr dostarcza analizatory językowe dla 30+ języków. EXT:find konfiguruje per język odpowiedni analizator i tworzy specyficzne rdzenie Solr dla każdego języka.

## Architektura techniczna

EXT:find komunikuje się z serwerem Apache Solr przez HTTP/JSON. Architektura składa się z trzech komponentów: serwera Solr (indeksowanie i wyszukiwanie), indeksera (zapisuje treści TYPO3 do Solr) i pluginu frontendowego (pole wyszukiwania, wyniki, facety).

Indekser przechodzi przez strukturę stron TYPO3 i wysyła treść każdej strony jako dokument JSON do Solr. Indeksowane są nie tylko widoczne treści, ale też metadane: tytuł strony, opis, kategorie, słowa kluczowe i pola niestandardowe. Indeksowanie działa jako zadanie Schedulera (zalecenie: po każdej zmianie treści lub w nocy jako pełny indeks).

EXT:find różni się od EXT:solr na poziomie zapytań. Zamiast stałej struktury zapytania, find oferuje konfigurowalny Query-Builder: przez TypoScript lub FlexForm można definiować, które pola Solr są przeszukiwane, z jaką wagą (Boosting), jakie filtry są automatycznie stosowane i jak wyniki są sortowane.

Konfiguracja facetów odbywa się przez definicje pól Solr. Każde pole, które ma służyć jako facet, musi być zdefiniowane w konfiguracji schematu Solr jako pole facet. EXT:find odczytuje dostępne facety z konfiguracji Solr i renderuje je jako menu filtrów na frontendzie. Filtry działają przez parametry GET, co umożliwia przyjazne SEO adresy URL dla filtrowanych stron wyników.

## Częste problemy i rozwiązania

**Konfiguracja i utrzymanie serwera Solr.** Solr to serwer oparty na Javie, który musi być prowadzony oddzielnie. Dla agencji TYPO3 bez doświadczenia z Javą konfiguracja jest barierą: konfiguracja JVM, zarządzanie rdzeniami Solr, aktualizacja schematu, monitoring. Rozwiązanie: użycie Managed Solr (np. Websolr, SearchStax) lub uruchomienie Solr jako kontenera Docker. Oficjalny obraz Docker Solr redukuje konfigurację do 3 poleceń.

**Jakość wyszukiwania jest słaba.** Odwiedzający szukają "kontakt" i znajdują 200 wyników, bo słowo pojawia się na każdej stronie w stopce. Rozwiązanie: konfiguracja wag pól. Trafienia w tytule są ważone 10x wyżej niż w treści, trafienia H2 5x wyżej niż tekst ciągły. EXT:find pozwala na tę wagę przez TypoScript: `plugin.tx_find.settings.boostFields.title = 10`.

**Indeks nie jest aktualizowany.** Redaktorzy zmieniają treści, ale wyszukiwanie pokazuje stare wyniki. Przyczyna: zadanie Schedulera indeksera nie działa lub zakończyło się błędem. Rozwiązanie: ustawienie zadania Schedulera na krótkie interwały (co 15 minut dla indeksu delta, w nocy dla pełnego indeksu) i konfiguracja alertu monitoringu powiadamiającego o błędach indeksu.

## Migracja i kompatybilność wersji

EXT:find obsługuje TYPO3 v10 i v11 z Solr 8 i 9. Dla TYPO3 v12 istnieje wersja beta na GitHubie. Rozszerzenie jest utrzymywane przez dział badań i rozwoju SUB Getynga i ma akademicką bazę użytkowników.

EXT:solr jest popularniejszą alternatywą z oficjalnym wsparciem v12 i komercyjnymi opcjami wsparcia (dkd Internet Service GmbH). Dla większości projektów TYPO3 EXT:solr jest bezpiecznym wyborem. EXT:find jest zalecany dla projektów ze specjalnymi wymaganiami zapytań (wyszukiwanie akademickie, bazy fachowe, scenariusze multi-indeksowe).

Migracja z EXT:indexed_search na Solr (niezależnie czy find czy solr) wymaga: konfiguracji serwera Solr, konfiguracji schematu, indeksowania treści i dostosowania szablonów frontendowych. Nakład pracy to 3-5 dni dla standardowej strony i 1-2 tygodnie dla złożonych portali. Gosign doradza w kwestii odpowiedniego stosu wyszukiwania i przejmuje konfigurację, setup i dostrajanie jakości wyszukiwania.

--- FlexSlider TYPO3 - Migracja | Gosign ---
> Legacy rozszerzenie slider dla TYPO3. Gosign migruje na Swiper lub Splide: bez jQuery, lepsza wydajność, natywne zdarzenia dotykowe, lepsze Core Web Vitals.

## FlexSlider jest przestarzały od 2015, ale nadal aktywny na tysiącach witryn TYPO3

FlexSlider był między 2012 a 2015 jednym z najpopularniejszych sliderów: oparty na jQuery, responsywny, z opcjami animacji. Biblioteka jQuery FlexSlider.js miała na GitHubie ponad 10 000 gwiazdek. Ostatnia aktualizacja ukazała się w 2015. Od tego czasu rozwój webowy zmienił się fundamentalnie: jQuery nie jest już potrzebny, Core Web Vitals karzą ciężkie biblioteki JavaScript, a zdarzenia dotykowe działają natywnie. Mimo to FlexSlider działa na tysiącach witryn TYPO3, bo migracja nigdy nie miała priorytetu.

Rozszerzenie TYPO3 EXT:flexslider osadza bibliotekę FlexSlider.js i oferuje plugin backendowy do konfiguracji slajdów. Samo rozszerzenie nie jest już utrzymywane i obsługuje maksymalnie TYPO3 v10. Każda witryna TYPO3 z FlexSlider ma temat migracji.

## Typowe scenariusze zastosowania

**Slider strony głównej z obrazami kampanii.** Klasyczne zastosowanie: 3-5 wielkoformatowych obrazów na stronie głównej, automatycznie rotujących. Te slidery typowo ładują 3-5 obrazów jednocześnie (15-25 MB danych), plus jQuery (90 KB) i FlexSlider.js (30 KB). Wynik: ponad 4 sekundy czasu ładowania widocznego obszaru (LCP). Nowoczesna alternatywa: pojedynczy obraz hero zamiast slidera (wyższa konwersja wg testów A/B) lub slider oparty wyłącznie na CSS bez JavaScript.

**Galerie produktowe z miniaturami.** FlexSlider był często używany jako galeria miniatur na stronach produktów: duży obraz główny na górze, pasek miniatur na dole. Tę funkcję można dziś zrealizować w 30 liniach CSS i 10 liniach Vanilla JavaScript, bez zewnętrznej biblioteki.

**Karuzele z opiniami.** Głosy klientów jako rotujące cytaty, często z animacją autoplay. FlexSlider oferował tryb "Carousel". Nowoczesna alternatywa: CSS Scroll Snap z `scroll-behavior: smooth`. Bez JavaScript, pełne wsparcie dotyku, poniżej 1 KB kodu.

## Architektura techniczna

EXT:flexslider składa się z trzech części: pluginu Content Element (FlexForm z konfiguracją slajdów), szablonów Fluid do prezentacji frontendowej i biblioteki FlexSlider.js z jQuery jako zależnością.

W backendzie redaktor konfiguruje: liczbę slajdów, obraz, nagłówek, tekst, link, efekt animacji (slide, fade), autoplay (tak/nie), prędkość autoplay, nawigację (strzałki, kropki, miniatury) i responsywne breakpointy. Dane są przechowywane w strukturze FlexForm-XML elementu treści.

Na frontendzie TYPO3 ładuje jQuery (jeśli nie jest dostępne), flexslider.js i flexslider.css. Skrypt inicjalizacyjny aktywuje slider ze skonfigurowanymi opcjami. Problemy wydajnościowe są uwarunkowane architekturą: FlexSlider ładuje wszystkie slajdy przy wywołaniu strony (brak lazy loading), jQuery blokuje renderowanie, silnik animacji używa JavaScript zamiast przejść CSS.

## Częste problemy i rozwiązania

**Słabe Core Web Vitals.** LCP powyżej 4 sekund, CLS powyżej 0.25, TBT powyżej 300ms. To nie jest problem tuningu, to jest problem architektury. Rozwiązanie: zastąpienie FlexSlider nowoczesną alternatywą. Swiper (bez jQuery, Lazy Loading, przejścia CSS) lub Splide (lżejszy, 29 KB zamiast 140 KB). Jeszcze lepiej: nie używać slidera i zastąpić statycznym elementem hero.

**Konflikty jQuery.** TYPO3 v12 nie dostarcza już jQuery w rdzeniu. FlexSlider potrzebuje jQuery. Kto osadza jQuery tylko dla FlexSlider, ładuje 90 KB na bibliotekę nieużywaną nigdzie indziej. Rozwiązanie: przy migracji slidera całkowite usunięcie jQuery i jednoczesna migracja wszystkich komponentów zależnych od jQuery.

**Responsywne obrazy nie działają.** FlexSlider nie zna elementu `<picture>` ani `srcset`. Każde urządzenie ładuje ten sam obraz. Rozwiązanie: Swiper i Splide obsługują `srcset` i `<picture>` natywnie.

## Migracja i kompatybilność wersji

FlexSlider nie ma kompatybilności z TYPO3 v12 lub v13. Biblioteka jQuery jest End-of-Life. Każdy projekt TYPO3 migrujący na v12/v13 musi zastąpić FlexSlider.

Migracja odbywa się w czterech krokach: eksport istniejących danych slidera z FlexForm, stworzenie nowego Content Element z Swiper lub Splide, import danych do nowej struktury i migracja starych referencji FlexSlider (aktualizacja SQL tabeli tt_content).

Nakład migracji to 1-2 dni na przebudowę techniczną i 0,5-1 dzień na migrację danych przy 10-20 sliderach. Gosign rekomenduje przy każdej migracji FlexSlider zasadnicze pytanie: czy naprawdę potrzebujesz slidera? Testy A/B konsekwentnie pokazują, że statyczne elementy hero osiągają wyższe wskaźniki konwersji niż rotujące slidery.

--- Flipbook TYPO3 - Flipbook PDF | Gosign ---
> Alternatywne rozszerzenie flipbook dla TYPO3 (obok rflipbook). Prezentacja PDF jako flipbook z efektem przewracania stron.

## Flipbooki wyglądały imponująco w 2012, dziś kosztują wydajność i dostępność

Efekt przewracania stron był jedną z najpopularniejszych form prezentacji katalogów, raportów rocznych i magazynów na stronach firmowych. PDF jest rozkładany na pojedyncze strony, wyświetlany w przeglądarce jako książka i przewracany kliknięciem myszy lub gestem przesunięcia. Technika pochodzi z ery Flash. Od zakończenia Flash (2020) rozwiązania flipbook opierają się na JavaScript i Canvas. Idea podstawowa się nie zmieniła: chodzi o wizualną symulację fizycznego dokumentu.

Problem: flipbooki to zabójcy wydajności. 40-stronicowy PDF jest konwertowany na 40 pojedynczych obrazów (po 200 do 500 KB każdy), plus biblioteka JavaScript (100 do 300 KB zminimalizowana). Wynik: od 10 do 20 MB payload dla jednego elementu treści. Na urządzeniach mobilnych flipbooki są praktycznie nieużywalne, czytniki ekranowe nie mogą odczytać treści, a Google nie indeksuje tekstu, bo jest ukryty w obrazach.

## Typowe scenariusze zastosowań

**Raporty korporacyjne i sprawozdania roczne.** Zarządy chcą pokazać raport biznesowy "jak wydrukowany" na stronie. Agencja drukarska dostarcza PDF, zespół marketingowy chce go umieścić 1:1 online. Flipbook wydaje się najprostszym rozwiązaniem. Gosign zaleca tu alternatywę: przygotowanie raportu jako strony HTML (przeszukiwalnej, dostępnej, responsywnej) i umieszczenie PDF jako linku do pobrania obok.

**Katalogi produktowe z wieloma stronami.** Firmy przemysłowe z 200-stronicowymi katalogami używają flipbooków jako "katalogu do przeglądania" na stronie. Rzeczywistość: użytkownicy przewracają maksymalnie 5 do 10 stron, zanim rezygnują. Przeszukiwalny katalog HTML z filtrem i stronami szczegółowymi produktów konwertuje lepiej.

**Ekspoze nieruchomości i broszury.** Biura pośrednictwa pokazują ekspoze jako flipbook, by zainteresowani mieli wrażenie drukowanego dokumentu. Tu często wystarczy wbudowany PDF-Viewer (pdf.js) bez efektu przewracania, który działa na wszystkich urządzeniach i pozostawia tekst przeszukiwalnym.

## Architektura techniczna

Rozszerzenie Flipbook dla TYPO3 (jak również rflipbook, popularna alternatywa) działa w trzech krokach. Najpierw PDF jest konwertowany po stronie serwera na pojedyncze obrazy (przez ImageMagick, Ghostscript lub zewnętrzną usługę). Potem obrazy są renderowane w bibliotece JavaScript opartej na Canvas (turn.js, StPageFlip lub rozwiązanie komercyjne). Efekt przewracania jest tworzony przez CSS3-Transform i animacje JavaScript.

Integracja z TYPO3 odbywa się jako element treści: redaktor przesyła PDF, wybiera opcje (zakres stron, rozmiar miniatury, prędkość efektu), frontend renderuje flipbook. Skonwertowane obrazy są zapisywane w fileadmin lub katalogu cache.

Zależności: ImageMagick lub Ghostscript muszą być zainstalowane na serwerze (do konwersji PDF). Biblioteka JavaScript jest dołączana jako zasób. Przy turn.js (najznaczniejszej bibliotece) trzeba załadować jQuery, co na nowoczesnych stronach stanowi dodatkowy problem wydajnościowy.

## Częste problemy i rozwiązania

**Obrazy nie są generowane.** Konwersja PDF nie udaje się, gdy Ghostscript nie jest zainstalowany, działa w złej wersji lub brakuje uprawnień do katalogu wyjściowego. Rozwiązanie: sprawdzenie `gs --version` na serwerze (minimum 9.50), nadanie uprawnień do zapisu dla użytkownika serwera, przy shared hosting kontakt z dostawcą.

**Czas ładowania powyżej 5 sekund.** 80-stronicowy PDF generuje dziesiątki obrazów w wysokiej rozdzielczości. Rozwiązanie: zmniejszenie jakości obrazu (72 dpi zamiast 150 dpi dla prezentacji webowej), implementacja lazy loading dla stron poza widocznym obszarem, użycie WebP zamiast PNG/JPEG. Albo fundamentalne pytanie: czy flipbook naprawdę jest potrzebny?

**Urządzenia mobilne wyświetlają błędy.** Efekt przewracania działa na urządzeniach dotykowych tylko ograniczenie. Efekt 3D page-turn na małych ekranach jest ledwie widoczny, a gest przesunięcia koliduje ze scrollowaniem przeglądarki. Rozwiązanie: na urządzeniach mobilnych automatyczne przejście na prosty slider lub natywny PDF-Viewer.

## Migracja i kompatybilność wersji

Rozszerzenie Flipbook ma ograniczone wsparcie dla aktualnych wersji TYPO3. Ostatnia stabilna wersja wspiera TYPO3 v10 i v11. Dla v12 i v13 nie ma oficjalnego wydania (stan kwiecień 2026). rflipbook, alternatywne rozszerzenie, jest w podobnej sytuacji.

Gosign zaleca przy aktualizacji TYPO3 zastąpienie flipbooka jedną z następujących alternatyw: PDF-Viewer na bazie pdf.js (open source, bez konwersji, tekst pozostaje przeszukiwalny), przygotowanie treści jako HTML (maksymalny efekt SEO, pełna dostępność) lub slider lightbox z wybranymi stronami jako obrazami (kompromis wizualny, dobra wydajność). Migracja jest z reguły zakończona w 1 do 2 dni.

Kolejnym aspektem jest dostępność. Flipbooki są dla użytkowników czytników ekranowych całkowicie niedostępne, ponieważ tekst jest ukryty w obrazach. Europejski Akt o Dostępności, który obowiązuje od czerwca 2025, dotyczy również publikacji cyfrowych na stronach firmowych. Przejście na prezentacje oparte na HTML lub pdf.js (który renderuje oryginalny tekst) to zatem nie tylko kwestia wydajności, ale również wymóg prawny.

--- FlowFact TYPO3 - CRM nieruchomości | Gosign ---
> FlowFact w TYPO3: Oferty nieruchomości, synchronizacja obiektów, ekspoze. Integracja OpenImmo. Z wykorzystaniem AI.

## Pośrednicy nieruchomości tracą leady, gdy obiekty są ręcznie przenoszone na stronę

Pośrednik zarządza swoim portfolio obiektów w FlowFact: zdjęcia, rzuty, ceny, wyposażenie, teksty ekspoze. Te same dane mają pojawić się na własnej stronie internetowej, na portalach nieruchomości i w drukowanych ekspoze. Bez automatycznej synchronizacji ktoś wpisuje dane podwójnie, zapomina o aktualizacji po zmianie ceny lub publikuje już sprzedany obiekt. Konsekwencja: fałszywe ogłoszenia, zirytowani klienci, utracone leady.

FlowFact (od 2019 roku część grupy Hypoport) to jeden z najczęściej używanych systemów CRM w branży nieruchomości. Ponad 10 000 pośredników z niego korzysta. Integracja z TYPO3 automatycznie synchronizuje obiekty z FlowFact na stronę pośrednika, bez ręcznej interwencji. Gosign wdrożył tę integrację dla biur z 50 do 2000 aktywnych obiektów.

## Typowe scenariusze zastosowań

**Regionalne biura nieruchomości z własną stroną.** Biuro z 3 do 10 pośrednikami zarządza 200 do 500 aktywnymi obiektami w FlowFact. Strona wyświetla listy z funkcją wyszukiwania (kod pocztowy, liczba pokoi, zakres cenowy, typ obiektu), strony szczegółowe z galerią zdjęć i rzutem, pobieranie ekspoze PDF oraz formularz kontaktowy, który kieruje zapytanie bezpośrednio do właściwego pośrednika w FlowFact. Nowe obiekty pojawiają się na stronie w ciągu 15 minut, zmiany statusu (sprzedany, zarezerwowany) są przejmowane automatycznie.

**Deweloperzy i firmy budowlane.** Firmy marketingujące projekty nowobudowlane potrzebują oprócz wyszukiwarki obiektów także stron landing z opisem budowy, planem lokalizacji i przeglądem mieszkań jako interaktywną tabelę. FlowFact dostarcza dane obiektów, TYPO3 środowisko redakcyjne dla tekstów projektowych i treści marketingowych. Oba światy są połączone przez API.

**Zarządy nieruchomości z portalem dla najemców.** Zarządcy wykorzystują FlowFact do administrowania obiektami na wynajem. Strona TYPO3 wyświetla wolne mieszkania, zbiera aplikacje przez formularz i przekazuje je jako kontakt do FlowFact. Szczególność: lista obiektów filtruje automatycznie "do wynajęcia", a nie "na sprzedaż".

## Architektura techniczna

Połączenie między FlowFact a TYPO3 odbywa się przez dwa możliwe interfejsy. Klasyczny sposób to OpenImmo - oparty na XML standard branżowy wymiany danych nieruchomości. FlowFact eksportuje obiekty jako OpenImmo-XML (ręcznie lub przez scheduler), importer TYPO3 wczytuje pliki i tworzy rekordy. Rozszerzenia takie jak openimmo (od justimmo) lub niestandardowe importery przetwarzają strukturę XML.

Nowocześniejszy sposób to FlowFact REST-API (od FlowFact v3). Serwer TYPO3 pobiera dane obiektów, obrazy i kontakty przez żądania HTTP i synchronizuje je z lokalną bazą danych. Zalety wobec OpenImmo: zdolność do działania w czasie rzeczywistym (polling co 5 minut zamiast codziennego eksportu), granularne aktualizacje (tylko zmienione pola) i dostęp do danych specyficznych dla FlowFact, których nie ma w standardzie OpenImmo (np. wewnętrzne notatki, status leada).

Po stronie TYPO3 obiekty są przechowywane jako rekordy we własnej tabeli (nie jako strony TYPO3). Strony z listami wykorzystują repozytoria Extbase z funkcjami filtrowania. Strony szczegółowe są renderowane przez akcję Show, która ładuje obrazy z FAL (File Abstraction Layer) i wyświetla rzuty jako overlay. Integracja map odbywa się przez Leaflet lub Google Maps, przy czym współrzędne geograficzne są przejmowane z FlowFact.

## Częste problemy i rozwiązania

**Brak obrazów po imporcie.** Eksporty OpenImmo odwołują się do obrazów jako nazwy plików, ale nie zawsze dostarczają same pliki. Rozwiązanie: konfiguracja eksportu tak, aby obrazy były osadzone jako Base64 w XML lub przesyłane równolegle do XML przez FTP. Przy REST-API obrazy są pobierane przez oddzielne endpointy i muszą być importowane jako referencje FAL w TYPO3.

**Obiekty znikają po synchronizacji.** Gdy FlowFact dezaktywuje lub usuwa obiekt, importer TYPO3 musi zdecydować: usunąć rekord, ukryć czy oznaczyć jako "sprzedany"? Standardowe importery często usuwają radykalnie. Rozwiązanie: implementacja soft-delete, które najpierw oznacza obiekty jako "nieaktywne" i dopiero po 30 dniach fizycznie je usuwa. Dzięki temu URL istotne dla SEO są zachowane i mogą wskazywać przez 301-Redirect na stronę przeglądu.

**Zapytania z formularza kontaktowego trafiają w pustkę.** Formularz kontaktowy wysyła e-mail, ale lead nie jest tworzony w FlowFact jako kontakt. Rozwiązanie: tworzenie zapytań formularza przez FlowFact-API jako kontakt z odniesieniem do obiektu. Odpowiedzialny pośrednik widzi lead bezpośrednio w swoim dashboardzie. Do tego formularz potrzebuje FlowFact-Objekt-ID jako ukryte pole.

## Migracja i kompatybilność wersji

FlowFact wprowadził w 2019 roku zupełnie nową platformę (FlowFact v3). Stara wersja (FlowFact Classic) jest nadal obsługiwana, ale nie otrzymuje nowych funkcji. REST-API jest dostępne tylko w v3. Istniejące integracje OpenImmo działają z obiema wersjami, ale podejście oparte na API jest możliwe tylko z v3.

Po stronie TYPO3 nie ma oficjalnego rozszerzenia FlowFact ze wsparciem v12/v13 w TER. Większość instalacji korzysta z niestandardowych importerów lub rozszerzenia openimmo (z modyfikacjami). Gosign zaleca przy aktualizacjach TYPO3 na v12+ jednoczesne przejście integracji nieruchomości na FlowFact-REST-API, zamiast portowania workflow OpenImmo-XML. Podejście oparte na API jest mniej wymagające w utrzymaniu i umożliwia funkcje takie jak dostępność w czasie rzeczywistym, które nie są realizowalne z eksportem XML.

Typowy projekt integracji FlowFact-TYPO3 (import obiektów, wyszukiwarka, strony szczegółowe, formularz kontaktowy z routingiem leadów) Gosign kalkuluje na 10 do 15 dni deweloperskich. Bieżące utrzymanie ogranicza się do aktualizacji API i sporadycznych dostosowań przy zmianach pól w schemacie FlowFact.

--- fluid_fpdf TYPO3 - PDF z szablonów | Gosign ---
> fluid_fpdf: Generowanie PDF z Fluid Templates. Faktury, certyfikaty, raporty. Realizacja z wykorzystaniem AI.

## Kiedy PDF powstaje z danych, a nie ze zrzutów ekranu, potrzebujesz fluid_fpdf

Istnieją dwa zasadniczo różne podejścia do generowania PDF w TYPO3. Podejście zrzutowe (web2pdf) polega na tym, że wyrenderowana strona jest zapisywana jako obraz i pakowana w PDF. Jest to proste, ale rezultat wygląda jak wydrukowana strona internetowa z nawigacją, stopką i responsywnymi artefaktami. Podejście oparte na danych (fluid_fpdf) działa inaczej: szablon Fluid definiuje układ PDF, dane z TYPO3 wypełniają miejsca zarezerwowane, a rezultatem jest czysty dokument w identyfikacji wizualnej firmy. Faktury, certyfikaty, oferty, raporty, wszystko, co musi istnieć jako dokument, wymaga podejścia opartego na danych.

fluid_fpdf korzysta z biblioteki FPDF (lekkiej klasy PHP do tworzenia PDF) i łączy ją z silnikiem szablonów Fluid w TYPO3. Efekt: programiści piszą układy PDF w tym samym języku szablonów, którego używają do szablonów HTML.

## Typowe scenariusze zastosowań

**Automatyczne tworzenie faktur.** Sklep internetowy lub system rezerwacji w TYPO3 generuje fakturę przy każdym zamówieniu. Dane faktury (pozycje, ceny, dane klienta, podatki) pochodzą z bazy danych, a układ z szablonu Fluid. U organizatora wydarzeń fluid_fpdf generuje 200-300 faktur miesięcznie bez ingerencji ręcznej. Każda faktura zawiera numer, logo firmy, dane bankowe oraz obowiązkowe informacje wymagane przepisami.

**Certyfikaty uczestnictwa i potwierdzenia.** Placówki edukacyjne, stowarzyszenia i firmy wydają certyfikaty po szkoleniach, warsztatach lub egzaminach. Imię uczestnika, data, nazwa kursu i podpis prowadzącego są automatycznie pobierane z danych TYPO3. W ośrodku szkoleniowym obsługującym 5.000 uczestników rocznie automatyzacja oszczędza około 250 godzin pracy, które wcześniej były potrzebne na ręczne tworzenie PDF w InDesign.

**Oferty i prezentacje.** Pośrednicy nieruchomości, firmy doradcze i agencje tworzą oferty z różną zawartością: dane klienta, wybrane usługi, indywidualne ceny. Układ PDF jest stały (zgodny z identyfikacją wizualną), a treść się zmienia. fluid_fpdf wypełnia szablon danymi z formularza TYPO3 lub modułu backendowego.

## Architektura techniczna

fluid_fpdf łączy dwa systemy: silnik szablonów Fluid w TYPO3 i bibliotekę FPDF. Architektura działa w trzech krokach.

Po pierwsze: szablon Fluid definiuje strukturę PDF. Zamiast znaczników HTML szablon używa specjalnych ViewHelperów dla elementów PDF: `<fpdf:page>` dla nowej strony, `<fpdf:cell>` dla komórki tekstowej, `<fpdf:image>` dla obrazu, `<fpdf:line>` dla linii. Składnia jest fluidowa, ale wynikiem nie jest HTML, lecz polecenia FPDF.

Po drugie: TYPO3 dostarcza dane. Przez kontroler lub DataProcessor niezbędne dane (pozycje faktury, dane klienta, informacje o produktach) są przekazywane do szablonu. Działa to identycznie jak obsługa danych w szablonach Fluid HTML: `{invoice.items}`, `{customer.name}`, `{order.total}`.

Po trzecie: FPDF renderuje PDF. ViewHelpery tłumaczą logikę Fluid na wywołania metod FPDF (SetFont, Cell, Image, Ln). FPDF tworzy PDF jako plik binarny, który jest albo wysyłany bezpośrednio do przeglądarki (pobieranie), albo zapisywany w systemie plików (np. do wysyłki e-mailem).

Obsługa czcionek to ważny szczegół: FPDF domyślnie obsługuje tylko 14 czcionek (Helvetica, Times, Courier i warianty). Dla czcionek firmowych pliki TTF trzeba przekonwertować na pliki czcionek FPDF. Narzędzie `MakeFont` z FPDF zajmuje się konwersją.

Wyświetlanie tabel wymaga ręcznego pozycjonowania. FPDF nie ma modelu tabel HTML. Każda komórka jest pozycjonowana absolutnie (współrzędne X/Y) lub względem poprzedniej. Przy złożonych tabelach z dynamiczną wysokością wierszy programista musi sam zaimplementować obliczanie wysokości.

## Częste problemy i rozwiązania

**Znaki UTF-8 nie są poprawnie wyświetlane.** FPDF wewnętrznie używa kodowania Latin-1. Polskie znaki (ą, ę, ł, ś, ż, ź, ć, ń, ó), niemieckie umlauty (ä, ö, ü) lub cyrylica wymagają obsługi UTF-8. Rozwiązanie: zamiast FPDF użyć tFPDF (wariantu FPDF obsługującego UTF-8). fluid_fpdf obsługuje tFPDF jako backend. Alternatywnie: mPDF, który natywnie obsługuje UTF-8.

**Podziały stron przy dynamicznej zawartości.** Faktura z 5 pozycjami mieści się na jednej stronie, ta z 50 pozycjami potrzebuje 3 stron. FPDF nie łamie stron automatycznie, gdy zawartość wykracza poza krawędź strony. Rozwiązanie: sprawdzać pozostałą wysokość strony przed każdą pozycją (GetY() + wysokość wiersza > koniec strony) i w razie potrzeby wstawiać nową stronę. Nagłówki i stopki są automatycznie powtarzane na każdej stronie przez metody Header()/Footer().

**Rozwój układu jest pracochłonny.** Bez podglądu wizualnego programista musi po każdej zmianie generować PDF, żeby zobaczyć efekt. Rozwiązanie: skonfigurować ścieżkę podglądu, która wyświetla PDF w przeglądarce (tryb wyjścia "Inline" zamiast "Download"). Przy każdym odświeżeniu PDF jest generowany od nowa. Znacznie przyspiesza to cykl rozwoju.

## Migracja i kompatybilność wersji

fluid_fpdf obsługuje TYPO3 v10 i v11. Dla v12 nie istnieje oficjalna wersja, nakład pracy na przeniesienie jest umiarkowany (dostosowania Extbase, rejestracja ViewHelperów).

Alternatywy dla TYPO3 v12/v13: EXT:pdfviewhelpers (używa TCPDF zamiast FPDF, więcej funkcji, aktywnie utrzymywany, kompatybilny z v12), własne rozwiązanie z mPDF jako pakietem Composer (HTML/CSS jako wejście, prostszy układ niż z FPDF) lub rozwiązanie headless z zewnętrzną usługą PDF (Gotenberg, wkhtmltopdf jako kontener Docker).

Migracja z fluid_fpdf na EXT:pdfviewhelpers jest zarządzalna: struktura szablonu jest podobna (oparta na ViewHelperach), ale nazwy i parametry ViewHelperów się różnią. W projekcie z 5 szablonami PDF nakład pracy wynosi 2-4 dni. Gosign wdrożył generowanie PDF w TYPO3 ze wszystkimi popularnymi bibliotekami i doradza w wyborze odpowiedniego rozwiązania w oparciu o konkretne wymagania.

--- focuspoint TYPO3 - Inteligentne przycinanie | Gosign ---
> focuspoint dla TYPO3: Automatyczne przycinanie obrazów z inteligentnym punktem fokusu. Optymalizacja responsywna, z wykorzystaniem AI.

## focuspoint zapobiega temu, aby obrazy przy responsywnym przycinaniu traciły ważne obszary motywu, rozszerzenie ustawia punkt fokusu, na którym crop pozostaje wyśrodkowany przy każdych proporcjach

Kto używa obrazów na responsywnej stronie, zna problem: portret pionowy, wyświetlany w teaserze tylko 200 pikseli wysokości, nagle pokazuje tylko szyję lub czoło. Zdjęcie krajobrazu, które pojawia się w obszarze hero jako wąski pasek, pokazuje niebo zamiast gór. Samo wyśrodkowywanie prowadzi do tego, że główne motywy są obcinane, bo matematyczne centrum rzadko pokrywa się z rzeczywistym centrum motywu. focuspoint rozwiązuje to, pozwalając redaktorom w backendzie ustawić punkt na obrazie, który musi pozostać widoczny przy każdym cropie. Wyjście dostosowuje się do wszystkich proporcji, bez konieczności tworzenia własnego wariantu obrazu dla każdego formatu.

Różnica w stosunku do klasycznego pipeline'u przetwarzania obrazów ze stałymi cropami jest duża. Zamiast dla desktop, tabletu i mobile pielęgnować osobno przyciętą wersję, istnieje jeden obraz oryginalny z jednym punktem fokusu i dowolną liczbę formatów wyjściowych, które system automatycznie oblicza. Dla redakcji z wieloma obrazami to dramatycznie redukuje czas pielęgnacji, a dla marketingu otwiera możliwość wprowadzania nowych proporcji obrazów bez dodatkowej pracy.

## Typowe scenariusze zastosowania

Pierwszym klasycznym przypadkiem są strony osób i zespołów. Strona firmowa pokazuje portrety pracowników w różnych layoutach, jako okrągły avatar w nagłówku, jako kwadratową kafelkę na liście zespołu, jako szeroki format na stronie detalu. Bez punktu fokusu fotograf musi robić zdjęcia dokładnie wyśrodkowane lub redakcja zakłada dla każdego layoutu własny wariant. Z focuspoint redakcja ustawia raz punkt na twarzy i obraz działa we wszystkich kontekstach.

Drugim przypadkiem są zdjęcia produktów i pomieszczeń. Pośrednicy nieruchomości, hotelarze i handlowcy mebli pracują ze zdjęciami, w których właściwy motyw (sofa, widok z pokoju, detal produktu) nie leży w centrum obrazu. focuspoint pozwala wybrać dokładnie ten motyw i dba o to, żeby również na urządzeniach mobilnych nie został utracony.

Trzecie zastosowanie: teasery magazynowe i artykułowe. Redakcyjne obrazy artykułów mają często wyraźny punkt zainteresowania, na przykład prelegenta na scenie lub produkt w scenie. Przy listach teaserowych z miniaturami pionowymi ten punkt bez fokusu często byłby poza kadrem.

## Architektura techniczna

focuspoint uzupełnia system TYPO3-FAL o dwa dodatkowe pola metadanych: focus_point_x i focus_point_y. Oba są pielęgnowane w backendzie przez element formularza, który pokazuje oryginalny obraz jako obszar wyboru. Redaktor klika na istotny punkt, a względna pozycja jest zapisywana. Technicznie to dwie wartości zmiennoprzecinkowe między zero a jeden, które opisują udział szerokości lub wysokości obrazu.

Przy renderowaniu we frontendzie punkt fokusu jest wartościowany przez ViewHelper Fluid. Zamiast zwykłego "f:image" ViewHelpera rozszerzenie używa własnego ViewHelpera, który wykonuje obliczanie cropu z uwzględnieniem punktu fokusu i tworzy obraz przez pipeline TYPO3-GIFBUILDER w żądanym rozmiarze docelowym. Wynik jest cache'owany i ponownie tworzony tylko przy zmianach.

Rozszerzenie współpracuje ze wszystkimi popularnymi formatami obrazów (JPEG, PNG, WebP, AVIF) i używa do właściwego przetwarzania obrazów ImageMagick lub GraphicsMagick, czyli tego samego stosu, na którym i tak buduje TYPO3. Dla Lazy Loading i integracji srcset nie ma konfliktów: ViewHelper może być zagnieżdżony w elementach picture z wieloma sources i dostarcza dla każdego breakpointu pasujący kadr.

## Częste problemy i rozwiązania

Pierwszym problemem jest kolejność ViewHelperów. Kto wbudowuje focuspoint w istniejące szablony, które już pracują z "f:image" i ręcznymi argumentami cropu, musi umieścić ViewHelper focuspoint w miejscu standardu, a nie wokół niego. Inaczej obie logiki będą działać przeciwko sobie, a wynik zignoruje punkt fokusu. Rozwiązaniem jest porządna migracja wszystkich odniesień do obrazów w sitepackage na nowy ViewHelper.

Drugi problem: unieważnianie cache. Gdy redaktorzy zmieniają punkt fokusu, cache obrazów musi być unieważniony, inaczej nadal widzą stary kadr. TYPO3 normalnie czyści cache obrazów przy zmianach oryginalnego obrazu, a nie przy zmianach metadanych. Rozwiązaniem jest EventListener, który przy zmianach pól punktu fokusu celowo kasuje dotknięte Processed-Files.

Trzeci problem: niespójne wyniki między podglądem backendowym a frontendem. Podgląd w backendzie używa innej ścieżki renderowania niż frontend, co może prowadzić do małych odchyleń. Pragmatyczne rozwiązanie: w backendzie pokazywać tylko przybliżony podgląd i odsyłać redaktorów do frontendu jako referencji wiążącej.

## Migracja i kompatybilność wersji

TYPO3 od wersji 9 przynosi natywny edytor przycinania w backendzie, który pozwala na pojedyncze warianty per obraz. Dla prostych przypadków to wystarcza. focuspoint różni się tym, że punkt fokusu jest ustawiany raz i automatycznie przepływa do wszystkich wariantów cropu, zamiast edytować każdy wariant pojedynczo. Kto ma wiele obrazów i mało czasu redakcyjnego, długoterminowo wychodzi lepiej z focuspoint.

Rozszerzenie jest kompatybilne z TYPO3 v11, v12 i v13. Przy upgrade ze starszych wersji struktura metadanych FAL i używane ViewHelpery powinny być doprowadzone do aktualnej składni.

Nową klasą alternatyw są wspierane przez AI rozpoznawania saliency, które automatycznie wyprowadzają punkt fokusu z treści obrazu. Te podejścia dodatkowo redukują pracę redakcyjną, bo redaktorzy nie muszą już sami ustawiać punktu, lecz tylko w wyjątkowych przypadkach korygować. Dla TYPO3 istnieją pierwsze integracje tej techniki, ale nie są jeszcze standardem i powinny być oceniane w zależności od projektu.

Gosign konfiguruje focuspoint i integruje go w architektury szablonów Fluid. Wspierana przez AI analiza layoutów designu proponuje optymalne presety cropu dla wszystkich breakpointów, dzięki czemu redaktorzy przy pielęgnacji obrazów nie muszą każdego formatu pojedynczo przetestowywać.

--- Linked Checkbox TYPO3 - Element formularza | Gosign ---
> Custom element checkbox dla TYPO3 Form Framework z linkowaną etykietą. Niezbędny do formularzy zgodnych z prawem: zgody RODO.

## form_element_linked_checkbox czyni zgody RODO naprawdę klikalnymi

TYPO3-Core-Form-Framework zna checkbox, ale nie checkbox z linkowaną etykietą. Kto pracuje ze standardowym elementem, nie może w etykiecie umieścić linku do polityki prywatności lub regulaminu, a dokładnie to jest w praktyce wymaganiem pojawiającym się w każdym formularzu. Rozszerzenie form_element_linked_checkbox wypełnia tę lukę porządnym własnym elementem formularza, który czysto łączy tekst i link. Dla każdej instalacji TYPO3, która pracuje z natywnym Form-Framework, to rozszerzenie jest praktycznie obowiązkowe. Bez rozszerzenia pozostaje tylko workaround z rozszerzeniem tekstu etykiety o sąsiedni blok tekstowy, co nie tylko wygląda nieczysto, ale też jest problematyczne dla screen-readerów i dostępności cyfrowej.

## Typowe scenariusze zastosowania leżą w obszarze compliance każdej strony firmowej

Pierwszym i najczęstszym scenariuszem są zgody RODO pod formularzami kontaktowymi, newsletterowymi i rekrutacyjnymi. Tekst "Zapoznałem się z polityką prywatności i zgadzam się na przetwarzanie moich danych" musi zawierać klikalny link do /polityka-prywatnosci, bez konieczności zaznaczania checkboxa przez odwiedzającego przed otwarciem. form_element_linked_checkbox dokładnie odwzorowuje ten przypadek.

Drugim scenariuszem są akceptacje regulaminów przy formularzach rejestracji i zakupu. Uczelnie stosują to przy zapisach na kursy, stowarzyszenia przy wnioskach członkowskich, projekty e-commerce z TYPO3-Form-Framework przy checkoutach. Często nie wystarczy tu tylko jeden link, tylko kilka (regulamin, pouczenie o prawie odstąpienia, polityka prywatności), które muszą być umieszczone w tej samej etykiecie.

Trzeci scenariusz dotyczy newsletterów z Double-Opt-In. Przed zapisem odbiorca musi jawnie potwierdzić, że subskrybuje newsletter, z linkiem do konkretnych informacji o ochronie danych newslettera. form_element_linked_checkbox pozwala używać w tym samym formularzu kilku checkboxów z własnym linkiem, dzięki czemu obok zgody RODO można osobno zapytać o wyraźną zgodę newsletterową. To ważne, bo RODO wymaga oddzielnych zgód, a ogólna checkbox "Zgadzam się ze wszystkim" nie wystarcza prawnie.

## Architektura techniczna tkwi w systemie pluginów Form Framework

TYPO3-Form-Framework jest świadomie rozszerzalny: każde rozszerzenie może rejestrować własne elementy formularzy, które pojawiają się w edytorze YAML i są używalne w backendzie przez drag-and-drop. form_element_linked_checkbox wykorzystuje ten mechanizm i rejestruje nowy element "LinkedCheckbox" przez YAML Form-Setup i obszar definicji elementów formularzy. Redaktorzy przeciągają element do swojego formularza, dokładnie tak jak robiliby to ze standardowym checkboxem, i konfigurują etykietę, tekst linku i cel w szczegółowym panelu.

Wewnętrznie rozszerzenie rozszerza klasę Checkbox i dodaje properties dla linkTarget, linkText i wrapLabel. Renderowanie odbywa się przez własny partial Fluid, który dzieli tekst etykiety na "before", "linkText" i "after" i rozpina klikalny obszar tylko nad częścią linku. Kliknięcie linku otwiera stronę docelową, bez przełączania checkboxa. Dla dostępności cyfrowej to ważne, bo screen-readery czytają link jako oddzielny element, a checkbox może być obsługiwany niezależnie od tego.

Konfiguracja odbywa się bezpośrednio w edytorze YAML Form-Framework: po przeciągnięciu elementu do formularza pojawiają się pola "Etykieta przed linkiem", "Tekst linku", "Etykieta po linku" i "Cel linku" w prawej szczegółowej kolumnie. Cel może być wewnętrzną stroną, linkiem do pliku lub zewnętrznym URL. Walidacja obowiązkowa jest ustawiana jak przy standardowym elemencie przez zakładkę Validators.

## Częste problemy dotyczą wielojęzyczności, stylizacji i komunikatów walidacji

Pierwszy temat wsparcia to tłumaczenie. Etykieta składa się z trzech części, a każda część musi być oddzielnie pielęgnowana w każdym języku. W praktyce oznacza to: dla dwujęzycznej instalacji (PL/EN) pielęgnacja się podwaja. Kto pracuje z ext:l10nmgr, powinien wyraźnie referencjonować klucze LLL w definicji formularza, żeby import/eksport działał porządnie. Trick z większych projektów: trzy części etykiety przechowywać w jednym kluczu LLL z placeholderami i przy wyjściu składać po stronie serwera. To wyraźnie redukuje liczbę stringów do tłumaczenia.

Drugim tematem jest stylizacja. Wiele systemów designu pracuje z niestandardowymi checkboxami, które są odtwarzane przez CSS z konstruktu span lub label. Domyślny szablon rozszerzenia dostarcza prosty wrapper, który koliduje z niektórymi frameworkami CSS. Zalecamy nadpisać partial w pakiecie overlay i dopasować konstrukcję do reszty stylizacji formularza.

Po trzecie, komunikaty walidacji są częstą pułapką. Gdy użytkownik nie zaznaczy checkboxa, powinno pojawić się "Proszę zgodzić się z polityką prywatności", a nie domyślny komunikat "Pole wymagane". Rozszerzenie wspiera niestandardowe komunikaty błędów przez formElementsDefinition w YAML Form; komunikat można dostosować per element. Dla dostępności cyfrowej to ważne, bo screen-readery bezpośrednio odczytują komunikat błędu, a nieprecyzyjne komunikaty nie dają pomocy. Zalecamy formułować każdy komunikat błędu tak, aby był zrozumiały niezależnie od kontekstu.

## TYPO3 v12 i v13 są w pełni wspierane, migracja v10 wymaga dostosowania YAML

form_element_linked_checkbox jest dostępne dla TYPO3 v11, v12 i v13. Struktura YAML Form-Framework zmieniła się między v10 a v12 w szczegółach, przede wszystkim przy rejestracji elementów custom. Przy upgrade instalacji v10 definicje formularzy, które używają elementu, muszą być przestawione na nową składnię YAML.

W projektach Gosign migrujemy rozszerzenie jako część refactoringu Form-Framework, nie pojedynczo. Nakład pracy jest zazwyczaj minimalny, bo element w każdym formularzu jest referencjonowany tylko przez swój identyfikator typu. Przy migracji sprawdzamy dodatkowo, czy teksty zgody RODO po upgrade TYPO3 są poprawnie renderowane w każdym języku, i aktualizujemy linki polityki prywatności, jeśli zostały zmienione w strukturze URL lub zawartości tekstowej.

--- Formlog TYPO3 - Logowanie formularzy | Gosign ---
> Rozszerzenie do logowania formularzy TYPO3: Protokołowanie wszystkich danych formularzy w backendzie.

## Dlaczego co trzecie zapytanie kontaktowe w TYPO3 bez logowania ginie

Formularze kontaktowe to najważniejszy kanał leadów na stronach firmowych. Ale TYPO3 Form Framework domyślnie nie zapisuje danych w bazie - wysyła tylko e-maile. Gdy serwer pocztowy ulegnie awarii, rekord SPF jest źle skonfigurowany lub timeout SMTP zadziała, zapytanie jest stracone. Żadnego backupu, żadnego śledzenia, żadnej analizy. Formlog zamyka tę lukę, protokołując każde wprowadzenie formularza w bazie danych TYPO3 - niezależnie od tego, czy dostarczenie e-maila się powiodło.

W praktyce dotyczy to więcej firm niż się przypuszcza: wskaźniki dostarczalności e-maili z serwerów webowych wynoszą według badań między 85% a 95%. Przy 100 zapytaniach kontaktowych miesięcznie oznacza to 5 do 15 utraconych leadów.

## Typowe scenariusze zastosowań

**Zabezpieczenie przed awariami e-maili.** Średnia firma prowadzi 3 formularze kontaktowe na swojej witrynie TYPO3. Serwer SMTP hostera ma w weekend 6-godzinny timeout. Bez Formlog wszystkie zapytania w tym okresie są stracone. Z Formlog zespół marketingowy w poniedziałek znajduje wszystkie wprowadzenia w backendzie TYPO3 i może ręcznie się skontaktować.

**Dowód zgodności z RODO/UODO i ISO 27001.** Firmy muszą móc wykazać, kiedy jakie dane osobowe wpłynęły i kiedy zostały usunięte. Formlog przechowuje wprowadzenia z timestampem i oferuje konfigurowalne automatyczne usuwanie po X dniach. Dla audytów ISO 27001 daje to kompletną dokumentację przetwarzania danych.

**Analiza zachowania przy wypełnianiu.** Które pola są często pozostawiane puste? Na którym kroku formularza użytkownicy rezygnują? Formlog udostępnia te dane w backendzie. Integrator TYPO3 może z tego wyciągnąć optymalizacje bez zewnętrznego narzędzia analitycznego.

## Architektura techniczna

Formlog integruje się jako Finisher w TYPO3 Form Framework (EXT:form). Każdy formularz z skonfigurowanym Formlog-Finisher zapisuje swoje wprowadzenia po wysłaniu we własnej tabeli bazodanowej (`tx_formlog_entries`). Każde wprowadzenie jest przechowywane jako zserializowana tablica JSON wraz z metadanymi (timestamp, identyfikator formularza, język, strona).

Moduł backendowy udostępnia redaktorom i administratorom możliwość filtrowania, przeszukiwania i eksportowania protokołowanych wprowadzeń jako CSV. Przez zadanie Scheduler wpisy są automatycznie usuwane po konfigurowalnej liczbie dni (domyślnie: 90 dni).

## Częste problemy i rozwiązania

**Formlog nie protokołuje wszystkich pól formularza.** Przyczyna: Formlog-Finisher musi być skonfigurowany po kroku walidacji, ale przed Redirect-Finisher. Jeśli redirect zadziała pierwszy, Formlog-Finisher nie jest już wykonywany. Rozwiązanie: sprawdzenie kolejności finisherów w konfiguracji YAML - Formlog powinien być na pozycji 1, przed e-mailem i redirect.

**Moduł backendowy nie wyświetla wpisów.** Często problem z uprawnieniami: użytkownik backend lub grupa backend nie ma dostępu do modułu Formlog. Rozwiązanie: aktywacja modułu `formlog` w ustawieniach grup backendowych pod "Dozwolone moduły".

**Automatyczne usuwanie nie działa.** TYPO3 Scheduler musi być prawidłowo skonfigurowany i regularnie uruchamiany (cronjob co 5 do 15 minut). Bez działającego Schedulera zadanie usuwania nigdy nie jest wyzwalane.

## Migracja i kompatybilność wersji

Formlog zostało opracowane przez Pagemachine i jest dostępne jako pakiet Composer (`pagemachine/typo3-formlog`). Rozszerzenie wspiera TYPO3 v10 do v12 LTS. Dla TYPO3 v13 nie ma jeszcze oficjalnego wydania, ale codebase opiera się na stabilnych API TYPO3, więc kompatybilność jest osiągalna z niewielkim nakładem.

Kto migruje z Powermail na TYPO3 Form Framework, traci przy tym logowanie zintegrowane w Powermail. Formlog jest zalecanym zamiennikiem. Gosign migruje formularze włącznie z konfiguracją logowania.

Aspekt, który wiele zespołów projektowych pomija: Formlog to nie tylko narzędzie backupowe, ale też narzędzie audytowe. Gdy klient twierdzi, że 3 tygodnie temu wysłał zapytanie, które nigdy nie zostało obsłużone, Formlog dostarcza dowód - albo zapytanie istnieje z timestampem, albo nigdy nie zostało wysłane. Dla firm z umowami SLA i zarządzaniem reklamacjami to mierzalna korzyść uzasadniająca instalację w 10 minut.

--- gb_events TYPO3 - Wydarzenia | Gosign ---
> Rozszerzenie wydarzeń dla TYPO3: Prosta prezentacja wydarzeń i widok kalendarza. Lżejsze niż sf_event_mgt, dla wydarzeń bez funkcji rejestracji.

## Nie każde wydarzenie wymaga rejestracji, ale każde wymaga przyzwoitej prezentacji

sf_event_mgt to standard zarządzania wydarzeniami w TYPO3: rejestracja, lista oczekujących, płatność, zarządzanie uczestnikami. Jednak wiele organizacji jedynie pokazuje wydarzenia, bez rejestracji online. Kalendarz koncertów, program wydarzeń gminy, terminy uniwersytetu ludowego - we wszystkich tych scenariuszach sf_event_mgt byłoby przesadą. gb_events wypełnia tę lukę: prostą prezentację wydarzeń z widokiem kalendarza, bez obciążenia pełnego systemu zarządzania wydarzeniami.

Rozszerzenie jest przeznaczone dla organizacji, które chcą publikować terminy, a nie nimi zarządzać. Brak formularza rejestracji, brak listy uczestników, brak obsługi płatności. Za to czysta prezentacja listowa, widok kalendarza i strona szczegółów dla każdego wydarzenia.

## Typowe scenariusze zastosowań

**Strony gmin i parafii.** Nabożeństwa, koncerty, festyny gminne, spotkania seniorów - typowy kalendarz gminy ma 20-40 wydarzeń miesięcznie. Odwiedzający chcą zobaczyć, co i kiedy się odbywa, i może przenieść terminy do własnego kalendarza. Rejestracja nie jest potrzebna, wydarzenia są publiczne. gb_events obsługuje to przy minimalnej konfiguracji.

**Uniwersytety ludowe i placówki edukacyjne (przegląd programu).** Zapisy na kursy odbywają się przez zewnętrzny system (Kufer, WebOpac), ale program ma być przeszukiwalny na stronie TYPO3. gb_events pokazuje kursy jako listę wydarzeń, filtrowaną według kategorii (języki, kreatywność, IT, zdrowie) i okresu. Strona szczegółów zawiera link do zewnętrznego systemu rejestracji.

**Cykle wydarzeń z powtarzającymi się terminami.** Klub sportowy ma treningi w poniedziałki i środy, spotkania towarzyskie w każdy pierwszy czwartek. gb_events prezentuje powtarzające się terminy bez konieczności ręcznego zakładania każdego pojedynczo. Powtarzanie jest konfigurowane, a gb_events generuje terminy automatycznie.

## Architektura techniczna

gb_events opiera się na Extbase/Fluid i używa własnej tabeli `tx_gbevents_domain_model_event`. Każde wydarzenie ma pola: tytuł, opis, data rozpoczęcia, data zakończenia, miejsce, obraz, kategoria i opcjonalnie regułę powtarzania. Kategorie korzystają z systemowych kategorii TYPO3, co upraszcza integrację z innymi rozszerzeniami.

Frontend składa się z trzech widoków: listowego (chronologicznego, filtrowanego według kategorii i okresu), kalendarzowego (widok miesięczny z klikalnymi dniami) i szczegółowego (pełne informacje o wydarzeniu). Wszystkie widoki to szablony Fluid i można je nadpisać w sitepackage.

Widok kalendarza renderuje siatkę HTML-tabeli z 7 kolumnami (dni tygodnia) i 4-6 wierszami (tygodnie). Każda komórka zawiera wydarzenia danego dnia jako linkowane tytuły. Nawigacja między miesiącami odbywa się przez parametr linku (GET), a nie przez AJAX. Jest to przyjazne SEO, ponieważ każdy miesiąc ma własny URL, który może zostać zaindeksowany przez Google.

Logika powtarzania działa podobnie jak w calendarize: rekord z regułą powtarzania generuje wirtualne wydarzenia. Są one obliczane w czasie uruchomienia, a nie materializowane w bazie danych. Oszczędza to pamięć, ale wymaga czasu obliczeniowego przy każdym żądaniu strony. Framework cache TYPO3 neutralizuje tę wadę w przypadku stron cachowanych.

## Częste problemy i rozwiązania

**Wydarzenia nie pojawiają się w widoku listy.** Częsta przyczyna: folder przechowywania (Storage PID) w pluginie nie odpowiada folderowi, w którym założono wydarzenia. gb_events filtruje wydarzenia według Storage PID. Rozwiązanie: w FlexForm pluginu wybrać poprawny folder lub zdjąć ograniczenie przez TypoScript (`persistence.storagePid = 0` pokazuje wydarzenia ze wszystkich folderów).

**Przeszłe wydarzenia znikają natychmiast.** gb_events domyślnie ukrywa wydarzenia, gdy tylko data zakończenia zostanie przekroczona. W niektórych przypadkach (archiwum wydarzeń, referencje) przeszłe wydarzenia powinny pozostać widoczne. Rozwiązanie: dostosować zapytanie Repository w kontrolerze (włączyć przeszłe wydarzenia) lub skonfigurować osobny tryb widoku listy "Archiwum".

**Brak funkcji eksportu iCal.** Odwiedzający chcą przenieść wydarzenia do swojego kalendarza. gb_events domyślnie nie oferuje pobierania .ics. Rozwiązanie: utworzyć własny typ strony dla eksportu iCal. Szablon Fluid generuje wynik zgodny z iCalendar (VCALENDAR, VEVENT, DTSTART, DTEND, SUMMARY, LOCATION). Nakład pracy to około 3 godzin rozwoju.

## Migracja i kompatybilność wersji

gb_events obsługuje TYPO3 v10 i v11. Dla v12 istnieje wersja społecznościowa na GitHubie, ale kompatybilność nie jest w pełni zweryfikowana. Dla v13 na razie nie ma planów.

Alternatywą dla TYPO3 v12/v13 jest sf_event_mgt - znacznie obszerniejsze i lepiej utrzymywane rozszerzenie wydarzeń. sf_event_mgt oficjalnie obsługuje v12 i v13. Kto nie potrzebuje funkcji rejestracji, może skonfigurować sf_event_mgt bez rejestracji i nadal używać prezentacji wydarzeń i widoku kalendarza. Zakres funkcji jest większy, ale też złożoność.

Migracja z gb_events na sf_event_mgt wymaga migracji danych: przeniesienia wydarzeń z `tx_gbevents_domain_model_event` do `tx_sfeventmgt_domain_model_event`. Pola są podobne (tytuł, opis, data, miejsce), ale nie identyczne. Skrypt migracyjny oparty na SQL załatwia to w 1-2 godziny. Szablony Fluid trzeba dostosować, ponieważ sf_event_mgt używa innych ViewHelperów i zmiennych.

Dla projektów z kilkoma wydarzeniami (poniżej 50 rocznie) możliwe jest również własne rozwiązanie oparte na tx_news: wydarzenia jako rekordy news z polami daty i widok kalendarza w szablonie. Gosign doradza w wyborze najbardziej ekonomicznego rozwiązania i w razie potrzeby przeprowadza migrację.

--- Geocoding TYPO3 - Współrzędne | Gosign ---
> Rozszerzenie geocodingu dla TYPO3: Automatyczna konwersja adresów na współrzędne GPS.

## Dlaczego każda wyszukiwarka oddziałów TYPO3 bez geocodingu nie daje rady z jakością danych

Wyszukiwarki oddziałów, wyszukiwanie dealerów i wyszukiwanie w okolicy mają tę samą podstawę: współrzędne GPS. Ale firmy przechowują dane lokalizacji jako adresy - ulica, numer, kod pocztowy, miasto. Przeliczenie adresu na współrzędne (geocoding) nie dzieje się samo. geocoordinates rozwiązuje ten problem automatycznie: rozszerzenie monitoruje pola adresowe w rekordach TYPO3 i przy każdej zmianie oblicza odpowiednie współrzędne GPS przez serwis geocodingowy.

Bez rozszerzenia geocodingowego redaktorzy musieliby dla każdej lokalizacji ręcznie kopiować szerokość i długość geograficzną z Google Maps. Przy 50 lokalizacjach to godzina pracy. Przy 500 lokalizacjach cały dzień roboczy - i przy każdej zmianie adresu proces zaczyna się od nowa.

## Typowe scenariusze zastosowań

**Automatyczne geocodowanie rekordów tt_address.** Firma ze 120 lokalizacjami w Polsce, Niemczech i Czechach zarządza wszystkimi adresami w rozszerzeniu TYPO3 tt_address. geocoordinates rejestruje DataHandler-Hook na tabelę tt_address. Gdy redaktor zmieni adres lub utworzy nową lokalizację, w tle wywoływany jest serwis geocodingowy. Współrzędne są zapisywane w polach bazy danych `latitude` i `longitude`. Rozszerzenie map maps2 odczytuje te pola i umieszcza marker we właściwym miejscu.

**Batch-Geocoding przy migracjach danych.** Firma migruje 2000 adresów ze starego systemu do TYPO3. Zaimportowane rekordy mają ulicę i kod pocztowy, ale nie współrzędne. geocoordinates oferuje komendę CLI, która geokoduje wszystkie rekordy bez współrzędnych w jednym przebiegu batchowym.

**Wyszukiwanie w okolicy na podstawie kodów pocztowych.** Firma rzemieślnicza oferuje wyszukiwanie w okolicy: "Znajdź najbliższego partnera w swojej okolicy." Odwiedzający wpisuje kod pocztowy, geocoordinates konwertuje kod na współrzędne i obliczenie odległości SQL (formuła Haversine) dostarcza wszystkie lokalizacje w promieniu 25, 50 lub 100 km, posortowane według odległości.

## Architektura techniczna

geocoordinates integruje się jako DataHandler-Hook w TYPO3 Core. Rozszerzenie monitoruje konfigurowalne tabele i pola. Gdy monitorowane pole adresowe się zmieni, asynchronicznie wyzwalane jest żądanie geocodingu.

Rozszerzenie wspiera dwóch dostawców geocodingu: Google Geocoding API (wysoka dokładność, dostępne globalnie, wymaga klucza API z aktywnym rozliczeniem, 5 USD za 1000 żądań) oraz OpenStreetMap Nominatim (bezpłatne, bez rejestracji, ale ograniczenie do 1 żądania/sekundę i nieco niższa dokładność w obszarach wiejskich).

Współrzędne są przechowywane w konfigurowalnych polach bazodanowych. Dla wyszukiwania w okolicy geocoordinates udostępnia funkcję odległości Haversine, którą można wbudować w repozytoria Extbase lub bezpośrednie zapytania QueryBuilder. Obliczenie odbywa się na poziomie bazy danych (MySQL/MariaDB), nie w PHP - to krytyczne dla wydajności.

## Częste problemy i rozwiązania

**Geocoding dostarcza błędne współrzędne dla polskich adresów.** Polskie adresy ze znakami diakrytycznymi (ą, ę, ł, ś, ż) mogą powodować problemy, gdy API nie przetwarza prawidłowo kodowania znaków. Rozwiązanie: upewnienie się, że dane adresowe są wysyłane do API w UTF-8. geocoordinates koduje domyślnie w UTF-8, ale pola bazy danych z kodowaniem Latin1 mogą tu przeszkadzać.

**Google Geocoding API zwraca "OVER_QUERY_LIMIT".** Przy batch-geocodingu z ponad 50 żądaniami na sekundę Google ogranicza API. Rozwiązanie: aktywacja rate-limiting w komendzie batchowej (maks. 40 żądań/sekundę dla kont standardowych).

**Nominatim przy tym samym adresie zwraca różne wyniki.** Dane OpenStreetMap są pielęgnowane przez społeczność i mogą się zmieniać. Rozwiązanie: oznaczenie raz geokodowanych współrzędnych jako "zweryfikowane" i ponowne geokodowanie tylko przy ręcznej zmianie adresu.

## Migracja i kompatybilność wersji

geocoordinates jest dostępne jako pakiet Composer dla TYPO3 v10 do v12. Rozszerzenie jest utrzymywane przez Stefana Froemkena, który również rozwija maps2. Oba rozszerzenia są ze sobą zestrojone, ale mogą być używane niezależnie od siebie.

Gosign standardowo łączy geocoordinates z maps2, by dostarczyć kompletny stos wyszukiwarki oddziałów: wprowadzanie adresu przez redaktora, automatyczne geokodowanie w tle, wyświetlanie mapy z markerem i popupem we frontendzie, wyszukiwanie w okolicy z kodem pocztowym dla odwiedzającego. Stos jest konfigurowany w 2 do 3 dni i pokrywa wymagania 90% wszystkich projektów wyszukiwarek oddziałów.

--- Gewinnspiel TYPO3 - Konkursy online | Gosign ---
> Konkursy w TYPO3: Losowania, uczestnictwo, automatyczne losowanie. Zgodne z RODO, rozwój z wykorzystaniem AI.

## Konkursy online w TYPO3 rzadko zawodzą przez technikę, prawie zawsze przez prawo

Zaprogramowanie konkursu zajmuje 3-5 dni: formularz, walidacja, losowanie, e-mail do zwycięzcy. Zrobienie tego zgodnie z prawem trwa dłużej, ponieważ wymagania prawne przewyższają nakład techniczny. Regulamin uczestnictwa, osobna zgoda marketingowa, zakaz wiązania, automatyczne usuwanie danych po zakończeniu konkursu, weryfikacja wieku, wykluczenie pracowników - to nie opcjonalne dodatki, lecz obowiązki ustawowe. Konkurs TYPO3 bez tych zabezpieczeń ryzykuje wezwania przedsądowe i kary. W Polsce RODO oraz ustawa o świadczeniu usług drogą elektroniczną stawiają podobne wymagania jak niemieckie DSGVO, a UODO regularnie kontroluje, czy zgody marketingowe są oddzielone od uczestnictwa.

TYPO3 nie oferuje standardowego rozszerzenia do konkursów. Rozwiązaniem zawsze jest własny rozwój, który dokładnie odwzorowuje wymagania konkretnego konkursu. Gosign tworzy takie moduły jako rozszerzenia TYPO3 oparte na Extbase z pełną warstwą zgodności z RODO.

## Typowe scenariusze zastosowań

**Kampanie marketingowe z losowaniem produktów.** Producent dóbr konsumpcyjnych rozlosowuje 10 produktów wśród wszystkich uczestników, którzy wypełnią formularz. Konkurs trwa 4 tygodnie, po czym zwycięzcy są wybierani przez generator losowy i informowani e-mailem. Wymagania techniczne: formularz z polami obowiązkowymi (imię, e-mail, wiek), jednorazowy udział na adres e-mail (Double-Opt-In), checkbox regulaminu (niezaznaczony domyślnie), osobny checkbox zgody na newsletter (opcjonalny, nie powiązany z uczestnictwem), automatyczne usuwanie danych 30 dni po zakończeniu.

**Konkursy powiązane z social media.** Uczestnicy są kierowani z Instagrama lub Facebooka na stronę TYPO3, tam wypełniają formularz. Platforma social media nie może służyć jako mechanizm uczestnictwa (regulaminy platform tego zabraniają), a jedynie jako źródło ruchu. Strona TYPO3 jest oficjalną stroną uczestnictwa. U klienta z 50.000 obserwujących na Instagramie trzy konkursy w ciągu roku wygenerowały 12.000 kwalifikowanych kontaktów, z czego 4.800 z opt-in do newslettera.

**Powtarzające się konkursy adwentowe lub miesięczne.** Kalendarz adwentowy z 24 okienkami, każde z osobną nagrodą. Technicznie bardziej wymagające: 24 konkursy w jednym rozszerzeniu, czasowe odblokowywanie, osobne losowanie na każdy dzień, śledzenie ogólnego uczestnictwa (bez podwójnej wygranej). U firmy handlowej kalendarz adwentowy zwiększył ruch w grudniu o 300% w porównaniu z rokiem poprzednim.

## Architektura techniczna

Moduł konkursowy TYPO3 składa się z pięciu komponentów:

**Formularz uczestnictwa.** Kontroler Extbase z szablonem Fluid. Pola formularza są konfigurowalne: pola obowiązkowe (imię, e-mail), pola opcjonalne (telefon, adres), checkboxy (regulamin, zgoda marketingowa). Formularz korzysta z ochrony CSRF TYPO3 (FormToken) i waliduje po stronie serwera. Walidacja po stronie klienta jest uzupełnieniem, ale nie wystarcza samodzielnie.

**Sprawdzanie duplikatów.** Każdy adres e-mail może uczestniczyć tylko raz. Sprawdzenie odbywa się na poziomie bazy danych (unique constraint na e-mail + ID konkursu). Dodatkowo: Double-Opt-In przez e-mail potwierdzający. Dopiero po kliknięciu linku potwierdzającego uczestnictwo jest ważne.

**Losowanie.** Zadanie Scheduler lub ręczny trigger z backendu wybiera zwycięzców za pomocą kryptograficznego generatora losowego (`random_int()` w PHP, a nie `rand()` czy `mt_rand()`). Losowanie jest protokołowane w bazie danych: czas, seed, ID zwycięzców. W przypadku zapytań regulacyjnych losowanie można odtworzyć.

**Powiadomienie zwycięzców.** Automatyczny e-mail do zwycięzców z gratulacjami i następnymi krokami (np. podanie adresu do wysyłki). Automatyczny e-mail do niewygranych (opcjonalny, zalecany dla budowania relacji z klientami). Wszystkie e-maile przez Mail-API TYPO3 z szablonami Fluid.

**Cykl życia danych.** Automatyczne usuwanie wszystkich danych uczestników po konfigurowalnym okresie (domyślnie: 30 dni po zakończeniu konkursu). Zadanie Scheduler sprawdza codziennie, czy konkursy wygasły, i usuwa powiązane rekordy. Dane zwycięzców (imię, adres) są obsługiwane osobno, ponieważ muszą być przechowywane dłużej do celów wysyłki i dokumentacji podatkowej.

## Częste problemy i rozwiązania

**Boty zakłamują wyniki.** Bez ochrony boty rejestrują tysiące fałszywych uczestnictw. Rozwiązanie: pole honeypot, rate-limiting (maksymalnie 3 wysyłki z jednego IP na minutę) i Double-Opt-In jako potrójne zabezpieczenie. Double-Opt-In to najskuteczniejsza ochrona: boty mogą wypełniać formularze, ale nie mogą kliknąć w e-mail potwierdzający.

**Naruszenie zakazu wiązania.** Udział w konkursie nie może być uzależniony od zgody marketingowej. Jeśli checkbox newslettera jest polem obowiązkowym, to naruszenie. Rozwiązanie: zgodę marketingową zawsze wdrażać jako opcjonalny, niezaznaczony checkbox. W walidatorze formularza sprawdzić, że uczestnictwo działa również bez zaznaczenia marketingowego. UODO w Polsce traktuje to tak samo restrykcyjnie jak niemiecki organ nadzorczy.

**Wydajność przy wysokim jednoczesnym obciążeniu.** Wirusowy konkurs z 10.000 uczestnictwami w ciągu godziny obciąża serwer. Rozwiązanie: skonfigurować przesłanie formularza jako stronę bez cache (USER_INT), ale samą stronę konkursu cachować (USER). Dla ekstremalnego obciążenia: osobny proces workera dla zapisów do bazy danych i obsługiwanie formularza przez kolejkę.

## Migracja i kompatybilność wersji

Moduły konkursowe to rozwiązania własne i nie mają standardowej ścieżki migracji. Przy upgrade'ach TYPO3 trzeba dostosować API Extbase: v9-v10 (Middleware-Stack), v10-v11 (zmiany Extbase), v11-v12 (refactoring TCA, moduły backendu). Nakład pracy na każdy major-upgrade wynosi 1-2 dni dla typowego modułu konkursowego.

Dla powtarzających się konkursów opłaca się generyczne rozszerzenie, konfigurowane przez moduł backendu: nazwa konkursu, okres, nagrody, pola formularza, szablony e-maili. Ta jednorazowa inwestycja (5-8 dni programisty) oszczędza 80% nakładu przy każdym kolejnym konkursie. Gosign tworzy takie moduły jako wielokrotnego użytku rozszerzenia TYPO3 i w razie potrzeby przejmuje przygotowanie projektu regulaminu, którego prawne zatwierdzenie pozostaje po stronie klienta.

--- Hero-Slider TYPO3 - Wydajność | Gosign ---
> Rozszerzenie Hero-Slider dla TYPO3. Często zabójca wydajności: duże obrazy, ciężkie biblioteki JS.

## Hero-slider to najdroższa sekcja strony TYPO3, mierzona w czasie ładowania

Sekcja hero to pierwsze, co widzą odwiedzający. Przy sliderze jest to również najwolniejsze, co widzą. Typowy hero-slider w TYPO3 ładuje 3-5 wielkoformatowych obrazów (po 500 KB-2 MB każdy), bibliotekę JavaScript (jQuery + plugin slidera: 120-200 KB), animacje CSS i skrypty inicjalizacyjne. W sumie to 3-12 MB danych, zanim odwiedzający może gdziekolwiek kliknąć. Largest Contentful Paint (LCP) w takich konfiguracjach rutynowo przekracza 4 sekundy, co Google klasyfikuje jako "zły" wynik i co kosztuje pozycje w rankingu.

Rozwiązaniem nie jest lepszy slider, lecz albo żaden slider, albo radykalnie lekki. Rozwiązania CSS-only i nowoczesne biblioteki slidera jak Swiper osiągają ten sam efekt wizualny przy ułamku czasu ładowania.

## Typowe scenariusze zastosowań

**Strony główne ze zmieniającymi się kampaniami.** Marketing chce umieścić 3-5 komunikatów w widocznym miejscu: kampania sezonowa, nowy produkt, zapowiedź wydarzenia, informacja o nagrodzie. Slider obraca się automatycznie, każdy slajd ma obraz, nagłówek i przycisk CTA. Problem: badania konsekwentnie pokazują, że tylko 1-2% odwiedzających wchodzi w interakcję poza pierwszym slajdem. Pozostałe 4 slajdy są ładowane, ale nieoglądane. Statyczny obraz hero z jednym jasnym komunikatem regularnie wypada lepiej w testach A/B niż slider.

**Galerie obrazów w sekcji nagłówka.** Hotele, restauracje i miejsca wydarzeń pokazują wrażenia jako hero-slider: widok zewnętrzny, wnętrze, taras, dania. Tu slider ma sens merytorycznie, ponieważ odwiedzający oczekują wielu wrażeń. Optymalizacja wydajności: ładować natychmiast tylko pierwszy obraz, a pozostałe doładowywać przez lazy loading. Z Intersection Observer i `loading="lazy"` jest to możliwe bez biblioteki slidera.

**Produkty highlight z animacją.** Strony e-commerce pokazują produkty highlight jako animowane slajdy. Animacja ma przyciągać uwagę. W praktyce: przejścia CSS (`transform`, `opacity`) są wydajniejsze niż animacje JavaScript i obciążają GPU zamiast CPU. Slider CSS-only z `scroll-snap-type` i `transition` osiąga 60 fps na każdym urządzeniu.

## Architektura techniczna

Hero-slidery w TYPO3 są zwykle implementowane jako Content Element: FlexForm z konfiguracją slajdów (obraz, tekst, link, kolejność) i szablon Fluid, który renderuje slajdy. Logikę slidera obsługuje biblioteka JavaScript.

Popularne biblioteki w projektach TYPO3: FlexSlider (przestarzały, jQuery), Slick (przestarzały, jQuery), Owl Carousel (przestarzały, jQuery), Swiper (nowoczesny, bez jQuery, 139 KB) i Splide (nowoczesny, bez jQuery, 29 KB). Wybór biblioteki determinuje charakterystykę wydajności całej sekcji hero.

Optymalna architektura dla hero-slidera w 2026 roku:

**Opcja 1: CSS-only (0 KB JavaScript).** `scroll-snap-type: x mandatory` na kontenerze, `scroll-snap-align: start` na slajdach. Nawigacja przez `scroll-behavior: smooth` i kotwice. Autoplay przez animację CSS (`@keyframes`). Nie potrzebny JavaScript. Działa we wszystkich nowoczesnych przeglądarkach. Wady: brak programowego autoplay z pauzą po najechaniu, brak animacji swipe.

**Opcja 2: Swiper/Splide (29-139 KB JavaScript).** Pełna funkcjonalność slidera z touch, swipe, autoplay, paginacją, lazy loading. Tree-shakeable - ładowane są tylko używane moduły. Integracja w TYPO3 przez własny Content Element z FlexForm.

**Opcja 3: Statyczny hero (0 KB JavaScript, 1 obraz).** Jeden obraz, jeden nagłówek, jeden CTA. Najszybsza i najbardziej konwertująca konfiguracja. Obraz jest dostarczany jako `<picture>` z `srcset`: 375px dla mobile, 768px dla tableta, 1440px dla desktopa. W formacie AVIF/WebP poniżej 100 KB na wariant.

## Częste problemy i rozwiązania

**LCP powyżej 4 sekund.** Obraz hero to element LCP. Jeśli ładuje się za późno, wynik LCP jest zły. Rozwiązanie: pierwszy obraz slidera ładować z `fetchpriority="high"` i `loading="eager"` (nie lazy). Pozostałe slajdy z `loading="lazy"`. Przełączyć format obrazu na WebP/AVIF. Ograniczyć rozmiar obrazu do rzeczywistej wielkości wyświetlania (bez obrazu 4000px dla viewportu 1440px).

**Cumulative Layout Shift (CLS) przez doładowujące się slidery.** Kontener slidera początkowo nie ma wysokości, po inicjalizacji JavaScript layout skacze. Rozwiązanie: ustalić wysokość kontenera slidera przez CSS (np. `aspect-ratio: 16/9` lub `min-height: 60vh`). Dzięki temu przeglądarka rezerwuje miejsce zanim JavaScript zostanie załadowany.

**Autoplay na urządzeniach mobilnych nie działa.** iOS Safari blokuje autoplay wideo i niektóre animacje CSS ze względu na oszczędzanie energii. Rozwiązanie: wyłączyć autoplay na urządzeniach mobilnych i zamiast tego zaoferować nawigację swipe. Odwiedzający na smartfonach wiedzą, że mogą przesuwać palcem. Statyczna wskazówka ("Przesuń, aby zobaczyć więcej") jest zbędna.

## Migracja i kompatybilność wersji

Większość rozszerzeń hero-slider w TER jest przestarzała i obsługuje maksymalnie TYPO3 v10 lub v11. Dla v12/v13 bezwzględnie zalecany jest własny Content Element w sitepackage, który podpina nowoczesną bibliotekę lub całkowicie opiera się na CSS.

Migracja istniejących sliderów odbywa się w trzech krokach: eksport danych slajdów (obrazy, teksty, linki z FlexForm lub bazy danych), założenie nowego Content Element (FlexForm z tymi samymi polami, ale nowoczesnym szablonem) i przełączenie istniejących content-elementów przez SQL na nowy CType. Nakład pracy: 1-2 dni na konfigurację techniczną plus 0,5 dnia na każde 10 istniejących sliderów dla migracji danych.

Gosign przy każdym projekcie hero-slidera zadaje najpierw pytanie: czy strona naprawdę potrzebuje slidera? W 70% przypadków statyczny element hero wypada lepiej. Dla pozostałych 30% Gosign dostarcza rozwiązanie Swiper lub CSS-only, które pozostaje poniżej 1,5 sekundy LCP.

--- Highcharts TYPO3 - Wizualizacja danych | Gosign ---
> Interaktywne wykresy Highcharts osadzone w TYPO3. Wykresy, grafiki i wizualizacje danych zarządzane bezpośrednio w CMS.

## Highcharts wprowadza interaktywną wizualizację danych do backendu TYPO3, gdy redaktorzy mają pielęgnować wykresy bez konieczności pracy w Excelu lub zewnętrznych narzędziach

Liczby, wskaźniki i trendy należą do stron firmowych jako dane finansowe w obszarze relacji inwestorskich, jako dane rynkowe w content-marketingu, jako wyniki ewaluacji w stowarzyszeniach i urzędach. Klasycznym rozwiązaniem są statyczne grafiki, tworzone gdzieś w Excelu, eksportowane jako PNG i ładowane ręcznie. To jest uciążliwe i podatne na błędy: gdy zmienia się jedna liczba, cała grafika musi być tworzona od nowa. Highcharts rozwiązuje ten problem, tworząc wykresy bezpośrednio ze strukturalnych danych, interaktywnie w przeglądarce, z tooltipami, efektami hover i funkcjami zoom. Integracja TYPO3 czyni proces redakcyjny w pełni wspieranym backendowo: redaktorzy pielęgnują serie danych w masce wprowadzania, a rozszerzenie generuje wykres.

Właściwa dźwignia produktywności powstaje, gdy serie danych nie są pielęgnowane ręcznie, lecz ciągnięte ze źródeł zewnętrznych. CSV z kontrolingu, eksport z hurtowni danych lub wywołanie API do wewnętrznego dashboardu dostarcza liczby, a TYPO3 renderuje z tego publiczną grafikę. To rozdzielenie między źródłem danych a prezentacją czyni pielęgnację wskaźników procesem commit, a nie wymianą zrzutów ekranu.

## Typowe scenariusze zastosowania

Klasycznym przypadkiem są strony relacji inwestorskich i danych finansowych. Spółka giełdowa pokazuje rozwój obrotu, liczby pracowników i udziały rynkowe jako interaktywne wykresy. Przy raportach kwartalnych zespół IR aktualizuje po prostu serię danych, wykres odświeża się automatycznie, a odwiedzający mogą przez mouse-over odczytać dokładne wartości per rok.

Drugim przypadkiem są wyniki ewaluacji i badań w stowarzyszeniach, fundacjach i urzędach. Ankieta członkowska, badanie środowiskowe lub badanie koniunktury są prezentowane jako wykres słupkowy, liniowy lub kołowy. Highcharts pozwala przejrzyście prezentować złożone zbiory danych z wieloma kategoriami i oferuje funkcje eksportu, dzięki którym odwiedzający mogą zabierać wykresy jako obraz lub PDF.

Trzecie zastosowanie: content-marketing i dziennikarstwo danych. Blogi firmowe i magazyny branżowe używają interaktywnych grafik, aby wyjaśniać złożone zależności, rozwój cen, udziały rynkowe, statystyki użytkowania. Interaktywność zwiększa czas spędzony na stronie i czyni treści cytowalnymi dla innych mediów.

## Architektura techniczna

Highcharts jako biblioteka JavaScript to ugruntowany produkt norweskiej firmy Highsoft, dystrybuowany na licencji komercyjnej, ale bezpłatny do użytku niekomercyjnego. Integracja TYPO3 dodaje do CMS maski backendowe do pielęgnacji serii danych i renderuje we frontendzie pasujący kod JavaScript, który inicjalizuje Highcharts.

Zazwyczaj rozszerzenie składa się z elementu treści, w którym redaktorzy konfigurują typ wykresu (linia, słupki, koło, area), podpisy osi, kolory i serie danych. Każda seria danych może być albo ręcznie pielęgnowana jako tabela, albo pobierana ze źródeł zewnętrznych jak pliki CSV, zapytania bazodanowe lub API REST. We frontendzie rozszerzenie wyświetla kontener div z konfiguracją JSON, a blok skryptu inicjalizuje Highcharts i renderuje wykres po stronie klienta.

Pytanie licencyjne jest centralne. Dla komercyjnych projektów TYPO3 musi być nabyta licencja Highcharts, w zależności od zakresu między kilkaset a kilka tysięcy euro rocznie. Kto chce tego uniknąć, znajdzie w Chart.js, ApexCharts lub Plotly dobre alternatywy, które są licencjonowane MIT lub Apache. Decyzja zależy od funkcji: Highcharts oferuje najszerszą paletę typów wykresów i najlepszą dokumentację, ale alternatywy niezawodnie pokrywają przypadki standardowe.

## Częste problemy i rozwiązania

Pierwszym problemem jest niejasność licencyjna. Projekty są startowane z założeniem, że Highcharts jest bezpłatny, a przy komercyjnym użyciu przychodzi rachunek. Rozwiązanie leży we wczesnym sprawdzeniu licencji: jeśli projekt jest komercyjny, albo budżetuje się licencję Highcharts, albo od początku stawia na darmową alternatywę. Gosign wyjaśnia tę kwestię przy kickoffie.

Drugi problem: wydajność przy wielu seriach danych. Wykres z tysiącami punktów danych blokuje przeglądarkę przy renderowaniu. Rozwiązaniem jest albo redukcja danych przez serwerową agregację, albo użycie modułów Highcharts jak Boost, które renderują duże zbiory danych na WebGL. Dla przypadków standardowych wystarcza skompresowanie surowych danych do sensownej granularności, zanim dotrą do przeglądarki.

Trzeci problem: dostępność cyfrowa. Interaktywne wykresy są często niedostępne dla screen-readerów. Highcharts oferuje moduł Accessibility, który udostępnia dane jako strukturalną tabelę równolegle do wizualnego wykresu. Pragmatycznym uzupełnieniem jest wyświetlanie pod każdym wykresem regularnej tabeli HTML z tymi samymi danymi, która jest wizualnie ukryta przez CSS, ale pozostaje dostępna dla screen-readerów.

## Migracja i kompatybilność wersji

Integracje TYPO3 dla Highcharts istnieją w kilku wariantach o różnej jakości i aktualności. Dla TYPO3 v11 istnieją aktywnie utrzymywane rozszerzenia, dla v12 i v13 wybór jest mniejszy, często potrzebne są dostosowania w ext_emconf i konfiguracjach usług. Kto dziś zaczyna od zera, powinien trzeźwo sprawdzić, czy istniejące rozszerzenie jeszcze pasuje, czy integracja sitepackage z darmową biblioteką jak Chart.js jest bezpieczniejszą na przyszłość drogą.

W scenariuszu upgrade wersja Highcharts jest wielkością krytyczną. Nowe wersje Highcharts okazjonalnie łamią API, szczególnie przy złożonych typach wykresów. Migracja powinna zatem zawsze być testowana w systemie staging, zanim dotkną live-dashboards.

Pragmatyczne postępowanie dla projektów istniejących: zinwentaryzować aktualne wykresy, wymienić rzeczywiście używane funkcje użytej biblioteki wykresów i sprawdzić, czy alternatywa pokrywa to samo. W wielu przypadkach wymagania są przejrzyste (wykresy liniowe i słupkowe z kilkoma seriami danych), a darmowa biblioteka obsługuje je bez utraty jakości. Zaoszczędzony budżet licencyjny może zamiast tego płynąć w lepsze zarządzanie contentem serii danych.

Gosign integruje Highcharts w TYPO3, towarzyszy wyjaśnianiu licencji i projektom migracji i w razie potrzeby wdraża lekkie alternatywy jak Chart.js lub ApexCharts jako komponent sitepackage. Właściwy wybór zależy od tego, jakie typy wykresów są rzeczywiście potrzebne i jaki budżet jest dostępny na licencje.

--- Hotspot TYPO3 - Interaktywne obrazy | Gosign ---
> Rozszerzenie TYPO3 do interaktywnych hotspotów na obrazach: klikalne obszary z podpowiedzią lub overlay. Zdjęcia produktów, plany budynków, infografiki.

## Interaktywne obrazy wyjaśniają złożone produkty lepiej niż 1.000 słów tekstu

Plan budynku z 12 oznaczonymi pomieszczeniami, przekrój maszyny z 8 podpisanymi elementami, mapa Europy z 15 lokalizacjami - wszystkie te przypadki potrzebują klikalnych obszarów na obrazie. Odwiedzający klika na element i widzi jego specyfikację. Klika na lokalizację i widzi adres oraz kontakt. Rozszerzenia Hotspot dla TYPO3 sprawiają, że obrazy stają się interaktywne, łącząc zdefiniowane obszary z podpowiedziami, nakładkami lub linkami.

Ciekawszym pytaniem jest, czy w ogóle potrzebne jest do tego rozszerzenie. Hotspoty oparte na SVG działają bez rozszerzenia, są lżejsze, bardziej dostępne i w pełni kontrolowalne w sitepackage. Dla prostych zastosowań SVG to lepsza droga. Dla złożonych konfiguracji z wieloma hotspotami i pielęgnacją w backendzie przez redaktorów rozszerzenie uzasadnia swoje użycie.

## Typowe scenariusze zastosowań

**Zdjęcia produktów z klikalnymi elementami.** Producenci maszyn, urządzeń i produktów technicznych używają hotspotów, aby opisać elementy na zdjęciu produktu. Kompresor przemysłowy z 8 zespołami: kliknięcie w silnik pokazuje dane wydajności, kliknięcie w filtr pokazuje interwały wymiany. Zamiast długiego opisu tekstowego informacje są udostępniane wizualnie. U producenta maszyn interaktywne zdjęcia produktów zwiększyły czas spędzony na stronach produktowych o 45%.

**Plany budynków i kampusów.** Uczelnie, szpitale i duże firmy pokazują interaktywne plany sytuacyjne: klikanie w budynki, wybór piętra, podgląd informacji o pomieszczeniach. TYPO3 dostarcza dane pomieszczeń z źródła Extbase, a hotspoty są pozycjonowane na rzucie. W szpitalu z 14 budynkami interaktywne plany całkowicie zastąpiły drukowany przewodnik.

**Infografiki z informacjami szczegółowymi.** Działy marketingu tworzą infografiki procesów, łańcuchów wartości lub struktur organizacyjnych. Zamiast statycznego pliku PNG elementy infografiki są klikalne: kliknięcie w etap procesu otwiera opis szczegółowy. Działa to szczególnie dobrze przy złożonych tematach, których nie da się wyjaśnić liniowo.

## Architektura techniczna

Rozszerzenia Hotspot w TYPO3 składają się z trzech części: edytora backendowego do pozycjonowania hotspotów, struktury danych dla treści hotspotów i renderera frontendowego, który wyświetla hotspoty na obrazie.

Edytor backendowy to zwykle wizualny edytor umieszczania punktów: redaktor widzi obraz w backendzie TYPO3 i klika w miejsca, gdzie mają się pojawić hotspoty. Współrzędne są zapisywane jako wartości procentowe (względem wielkości obrazu), a nie jako piksele. Wartości procentowe zapewniają, że hotspoty pozostają we właściwym miejscu przy responsywnym wyświetlaniu obrazu.

Struktura danych na każdy hotspot: pozycja X (%), pozycja Y (%), tekst podpowiedzi, treść szczegółowa (HTML/Fluid), typ ikony i opcjonalnie link do strony szczegółów. Dane są zapisywane jako relacje inline (IRRE) do elementu treści: jeden element treści ma 1:n hotspotów.

Na frontendzie hotspoty są renderowane jako absolutnie pozycjonowane elementy HTML nad obrazem. Obraz leży w kontenerze z `position: relative`, a hotspoty mają `position: absolute` z `left` i `top` w procentach. Po kliknięciu lub najechaniu pojawia się podpowiedź jako nakładka, pozycjonowana względem hotspotu.

Alternatywa SVG działa bez rozszerzenia: obraz jest tworzony jako SVG (lub obraz jest osadzony jako `<image>` w SVG), hotspoty to elementy SVG (`<circle>`, `<rect>`, `<polygon>`) z atrybutami `data-` i handlerami zdarzeń. Treści podpowiedzi są odczytywane przez JavaScript z bloku `<script type="application/json">`.

## Częste problemy i rozwiązania

**Pozycje hotspotów przesuwają się na urządzeniach mobilnych.** Obraz jest wyświetlany mniejszy na smartfonie, ale hotspoty pozostają w pozycji desktopowej. Przyczyna: hotspoty są pozycjonowane w pikselach zamiast procentach lub kontener nie ma responsywnego dostosowania rozmiaru. Rozwiązanie: wszystkie pozycje zapisywać w procentach, a kontener uczynić responsywnym przez `max-width: 100%` i `height: auto`. Dodatkowo: hotspoty na urządzeniach mobilnych wyświetlać jako listę pod obrazem, ponieważ dotyk palcem w małe punkty hotspot jest trudny.

**Brak dostępności.** Czysto wizualne hotspoty bez nawigacji klawiaturą i bez tekstu dla czytnika ekranu nie są dostępne. Rozwiązanie: każdy hotspot implementować jako `<button>` (a nie `<div>`), z `aria-label` dla czytnika ekranu i `tabindex` dla nawigacji klawiaturą. Treść podpowiedzi musi być powiązana przez `aria-describedby`.

**Wydajność przy wielu hotspotach.** 20+ hotspotów na obrazie generuje 20+ elementów DOM z listenerami zdarzeń. Na starszych urządzeniach mobilnych może to powodować zacięcia. Rozwiązanie: event delegation zamiast indywidualnych listenerów. Jeden listener na kontenerze zamiast 20 na hotspotach. Przy hotspotach SVG wydajność jest generalnie lepsza, ponieważ elementy SVG są natywnie renderowane przez przeglądarkę.

## Migracja i kompatybilność wersji

Rozszerzenia Hotspot w TER obsługują TYPO3 v10 i v11. Dla v12 i v13 nie istnieją szeroko utrzymywane rozszerzenia Hotspot. Trend zmierza do rozwiązań opartych na SVG, implementowanych jako własny Content Element w sitepackage i niewymagających zewnętrznych rozszerzeń.

Migracja z rozszerzenia Hotspot na rozwiązanie oparte na SVG wymaga: eksportu danych hotspotów (współrzędne, teksty), utworzenia szablonu SVG, który renderuje punkty jako elementy SVG, oraz skonfigurowania własnego Content Element, który zarządza danymi przez relację IRRE. Nakład pracy wynosi 3-5 dni, w zależności od liczby obrazów z hotspotami.

Najbardziej przyszłościowe rozwiązanie: hotspoty oparte na CSS z `<map>` i `<area>` dla prostych scenariuszy, SVG z JavaScript dla złożonych interakcji. Gosign implementuje interaktywne obrazy jako własne Content Element i doradza w wyborze odpowiedniej technologii w oparciu o złożoność, wymagania dostępności i liczbę obrazów z hotspotami.

--- Lista stowarzyszeń TYPO3 - Komunalne | Gosign ---
> Plugin listy stowarzyszeń dla TYPO3: Prezentacja, filtrowanie, sortowanie stowarzyszeń. Typowe dla stron komunalnych i organizacji parasolowych.

## Gminy i organizacje parasolowe potrzebują ustrukturyzowanej bazy stowarzyszeń, a nie statycznych list

Kto szuka lokalnego klubu szachowego na stronie gminy lub portalu wojewódzkiego związku sportowego, oczekuje maski filtrującej, a nie 15-stronicowego pliku PDF. Dokładnie ten problem rozwiązuje hwvereinsliste: rozszerzenie odwzorowuje stowarzyszenia jako rekordy TYPO3 i udostępnia je poprzez filtr kategorii, wyszukiwanie pełnotekstowe i widoki szczegółów. Dla komunalnych serwisów internetowych, organizacji parasolowych i powiatowych związków sportowych wtyczka jest od lat sprawdzonym narzędziem, które pozwala redakcjom na pielęgnację bez ingerencji programistów.

Rzeczywistość w polskich gminach wygląda często tak, że rejestry stowarzyszeń krążą jeszcze jako dokumenty Word w biurach urzędów. hwvereinsliste zastępuje ten workflow centralną bazą danych w backendzie TYPO3, sterowaną przez pluginy frontendowe. Mieszkańcy znajdują swoje stowarzyszenie w sekundach, a redaktorzy aktualizują dane kontaktowe bez dostępu FTP.

## Typowe scenariusze zastosowań obejmują portale gminne i bazy powiatowych związków sportowych

Najczęstszy scenariusz to klasyczna lista stowarzyszeń na stronie gminy. Gmina z 80 do 120 zarejestrowanymi stowarzyszeniami pielęgnuje wszystkie wpisy centralnie w backendzie TYPO3. Mieszkańcy filtrują we frontendzie według kategorii takich jak sport, kultura, sprawy społeczne lub młodzież. Widok szczegółowy pokazuje osoby kontaktowe, godziny treningów i dane kontaktowe. Redakcja strony gminy samodzielnie aktualizuje wpisy, bez pomocy technicznej.

Drugi scenariusz dotyczy organizacji parasolowych i wojewódzkich związków sportowych. Wojewódzki związek sportowy zarządza często 500 do 2.000 klubami członkowskimi w kilkudziesięciu dyscyplinach. Tutaj funkcja filtrowania staje się kluczową: użytkownicy kombinują dyscyplinę sportową, miejscowość i grupę wiekową, aby znaleźć odpowiedni klub w swojej okolicy. hwvereinsliste natywnie obsługuje takie wielokrotne filtrowanie.

Trzeci scenariusz to portale katalogowe z obszaru wolontariatu. Ośrodki wolontariatu używają rozszerzenia do wyświetlania organizacji, które szukają wsparcia wolontariuszy. Kategoryzacja odbywa się przez systemowe kategorie TYPO3, co pozwala na przecięcia z innymi elementami treści na tej samej stronie. W niektórych przypadkach rozszerzenie jest również używane jako katalog branżowy dla lokalnego wsparcia gospodarczego, gdzie zamiast stowarzyszeń wyświetlane są firmy.

## Architektura techniczna oparta jest na rekordach Extbase i szablonach Fluid

hwvereinsliste używa frameworku Extbase/Fluid w TYPO3. Stowarzyszenia są zapisywane jako własne rekordy domenowe w dedykowanej tabeli. Każdy rekord zawiera pola nazwy, opisu, adresu, danych kontaktowych, URL strony, logo i kategorii. Kategoryzacja wykorzystuje systemowe kategorie TYPO3, co upraszcza integrację z innymi rozszerzeniami.

W frontendzie dostępne są dwa pluginy: widok listy z funkcją filtrowania i wyszukiwania oraz widok szczegółowy dla pojedynczych stowarzyszeń. Szablony są oparte na Fluid i można je nadpisać przez ścieżki TypoScript lub sitepackage. Kto chce dostosować układ, kopiuje szablony Fluid do własnego pakietu i dostosowuje strukturę HTML i klasy CSS, nie modyfikując samego rozszerzenia.

Filtrowanie działa standardowo po stronie klienta przy małych ilościach danych, a po stronie serwera przy większych zasobach. Dla instalacji z ponad 500 stowarzyszeniami zalecana jest kombinacja z rozwiązaniem indeksującym jak ke_search, aby poprawić wydajność wyszukiwania pełnotekstowego.

Aspekt, który w projektach komunalnych często jest zapominany: dostępność. Zgodnie z polską ustawą o dostępności cyfrowej (implementującą dyrektywę UE 2016/2102) oraz Europejskim Aktem o Dostępności, podmioty publiczne muszą zapewnić dostępność swoich stron internetowych. Dotyczy to również listy stowarzyszeń: elementy filtrów muszą być obsługiwane z klawiatury, listy wyników potrzebują etykiet ARIA, a funkcja wyszukiwania musi współpracować z czytnikami ekranu. Standardowe szablony rozszerzenia nie spełniają tych wymagań w pełni i muszą być dostosowane.

## Częste problemy dotyczą importu, kategoryzacji i responsywnej prezentacji

Najczęstszy problem przy pierwszej konfiguracji to import danych. Gminy mają dane stowarzyszeń zazwyczaj w plikach Excel z niespójnymi formatami. Nazwy kolumn się różnią, kategorie są zapisane jako tekst zamiast znormalizowanej taksonomii, a dane kontaktowe zawierają przestarzałe wpisy. Gosign rozwiązuje to przez workflow importu wspierany przez AI: plik Excel jest automatycznie analizowany, kolumny mapowane, kategorie normalizowane, a duplikaty rozpoznawane. To, co wcześniej kosztowało pół dnia ręcznej pracy, trwa teraz mniej niż godzinę.

Drugi problem dotyczy struktury kategorii. Gdy kategorie nie są wcześniej starannie zdefiniowane, powstają redundancje jak "Piłka nożna", "Klub piłki nożnej" i "Klub piłkarski" jako trzy osobne wpisy. Zalecamy przed go-live ustalenie taksonomii kategorii z maksymalnie 15 do 20 kategoriami nadrzędnymi i założenie ich w backendzie TYPO3 jako kategorii systemowych.

Trzeci problem: responsywna prezentacja widoku listy. Na urządzeniach mobilnych prezentacja tabelowa szybko staje się nieczytelna. Szablony Fluid powinny dla mobilnych viewportów renderować prezentację kartową zamiast tabeli, co można zrealizować przez prostą adaptację szablonu w sitepackage. Gosign standardowo dostarcza responsywne szablony dla list stowarzyszeń, które na smartfonach są wyświetlane jako karty, a na desktopach jako tabela.

## Migracja na v12 wymaga dostosowań Extbase, v13 nie jest jeszcze oficjalnie wspierane

hwvereinsliste zostało opracowane głównie dla TYPO3 v9 i v10. Dla TYPO3 v12 potrzebne jest dostosowanie persystencji Extbase, ponieważ interfejs zapytań się zmienił. Konkretnie dotyczy to klas Repository i konfiguracji persystencji opartej na TypoScript, która od v12 jest rozwiązywana przez Classes.php. Ścieżki szablonów również muszą zostać przestawione na nową strukturę SiteSet.

Dla TYPO3 v13 obecnie nie ma oficjalnego wsparcia ze strony autora rozszerzenia. Kto migruje na v13, musi albo samodzielnie dostosować rozszerzenie, albo ocenić alternatywne rozwiązanie. Gosign w takich przypadkach sprawdza, czy migracja rozszerzenia czy przebudowa na bazie Extbase z aktualnym API jest bardziej ekonomiczna. Dla małych baz stowarzyszeń z poniżej 200 wpisów własny plugin jest często lepszym wyborem, ponieważ jest dokładnie dopasowany do wymagań gminy i nie niesie ze sobą legacy zależności.

--- imagemap TYPO3 - Interaktywne grafiki | Gosign ---
> imagemap dla TYPO3: Interaktywne grafiki z klikalnymi obszarami. Responsywne, dostępne, alternatywy SVG.

## imagemap czyni obrazy klikalnymi bez konieczności dotykania przez redaktorów HTML, właściwy wybór dla planów budynków, organigramów i grafik produktowych z wieloma hotspotami

Niektórych treści nie da się tak efektywnie wyjaśnić słowami jak obrazem, na którym różne obszary można kliknąć. Plan budynku, na którym każdy dział prowadzi do odpowiedniej strony zespołu. Organigram z linkami do poszczególnych profili osób. Zdjęcie produktu, w którym kliknięcie na koło, silnik lub kokpit pokazuje szczegóły techniczne. HTML od lat dziewięćdziesiątych przynosi do tego funkcjonalność Image-Map, ale żaden redaktor nie chce ręcznie wpisywać koordynat do pola tekstowego. imagemap dorabia tę funkcję w TYPO3 z wizualnym edytorem: redaktorzy klikają w backendzie na obraz, zaznaczają obszar i linkują go do strony docelowej.

Właściwą obietnicą rozszerzenia jest to, że orientacja przestrzenna i nawigacja są łączone. Zamiast kazać odwiedzającym skakać między widokiem graficznym a oddzielną listą linków, sama grafika staje się elementem nawigacyjnym. Dla contentu, który jest strukturalizowany geograficznie, hierarchicznie lub technicznie, oferuje to zdecydowanie bardziej intuicyjny dostęp.

## Typowe scenariusze zastosowania

Pierwszym przypadkiem są plany sytuacyjne i przeglądy kampusu. Kliniki, uczelnie, tereny targowe i parki przemysłowe pracują z mapami przeglądowymi, na których poszczególne budynki lub obszary bezpośrednio linkują do stron informacyjnych. Klasyczną alternatywą byłaby lista z linkami, ale ta traci odniesienie przestrzenne. imagemap łączy orientację graficzną ze strukturą linków.

Drugim zastosowaniem są organigramy i hierarchie. Firma pokazuje strukturę swoich działów jako grafikę, każdy węzeł prowadzi do profilu danej kadry kierowniczej lub do strony działu. Dla redakcji to prostsze do pielęgnowania niż złożony layout tabelaryczny z linkowanymi komórkami.

Trzeci przypadek: grafiki produktowe z hotspotami funkcji. Produkty techniczne (maszyny, pojazdy, urządzenia) są pokazywane na rysunku rozstrzałowym lub przekroju, na którym najważniejsze komponenty są wyjaśniane przez kliknięcie. To zastępuje długą listę tekstu i prowadzi odwiedzających dokładnie tam, gdzie leży ich zainteresowanie.

## Architektura techniczna

Klasyczne rozszerzenie imagemap dla TYPO3 pielęgnuje koordynaty jako strukturalne rekordy w bazie danych i renderuje we frontendzie element HTML-Map z pasującymi tagami area. W backendzie dostępny jest wizualny edytor, który pokazuje oryginalny obraz jako obszar wyboru i pozwala redaktorom rysować na nim prostokąty, okręgi lub wielokąty. Każdy obszar otrzymuje URL docelowy, tekst alternatywny i opcjonalnie tooltip.

Wyzwaniem technicznym jest responsywność. Klasyczna HTML-Map pracuje z absolutnymi koordynatami pikselowymi, które przy skalowanych obrazach już nie pasują. Rozszerzenia imagemap rozwiązują to przez JavaScript, który przy resize względnie przelicza koordynaty, lub używając SVG jako formatu wyjściowego. SVG jest przy tym czystym rozwiązaniem: koordynaty wektorowe skalują się naturalnie, obsługa zdarzeń i stylizacja przez CSS działają natywnie, a screen-readery mogą odczytywać elementy strukturalne.

Integracja odbywa się przez element treści w module strony. Redaktorzy wybierają obraz źródłowy z FAL, definiują hotspoty i opcjonalnie konfigurują globalne ustawienia jak standardowy kolor obszarów, efekty hover i zachowanie tooltipów. Wyjście można dostosować przez szablon Fluid w sitepackage, aby zapewnić zgodność z CI.

## Częste problemy i rozwiązania

Pierwszym problemem jest dostępność. HTML-Image-Maps są dla screen-readerów sensownie czytelne tylko wtedy, gdy każdy tag area ma znaczący tekst alternatywny, a sama mapa jest rozpoznawana jako nawigacja strukturalna. Wielu redaktorów wypełnia alt-text bezmyślnie lub pusto, co czyni mapę bezużyteczną dla niewidomych użytkowników. Rozwiązaniem jest obowiązek redakcyjny opatrywania każdego hotspotu opisowym alt-textem i techniczna kontrola w sitepackage, która blokuje zapisywanie pustych tekstów.

Drugi problem: obsługiwalność na urządzeniach mobilnych. Hotspot, który w rozmiarze desktopowym mierzy 30 na 30 pikseli, jest na smartfonie malutki. Pragmatycznym rozwiązaniem jest alternatywa mobilna, która poniżej określonego breakpointu zastępuje obraz listą z tymi samymi celami. To wymaga logiki Fluid, która dostarcza dwie prezentacje i przełącza je przez CSS.

Trzeci problem: nakład pielęgnacji przy zmianach obrazu. Gdy obraz podstawowy (na przykład plan sytuacyjny lub zdjęcie produktu) zostaje wymieniony, wszystkie koordynaty muszą być ustawione na nowo, bo motywy się przesunęły. Pragmatyczne rozwiązanie: redaktorzy pracują ze stałym, wersjonowanym formatem obrazu i dokumentują siatkę koordynat, dzięki czemu przy aktualizacjach potrzebne są tylko minimalne korekty. Alternatywnie rozwiązanie oparte na SVG może od początku pracować względnie.

## Migracja i kompatybilność wersji

Dla TYPO3 v11, v12 i v13 istnieje kilka rozszerzeń imagemap, które są aktywnie utrzymywane, często pod nieco innymi nazwami. Przy upgrade opłaca się spojrzeć, czy pierwotnie użyte rozszerzenie jest jeszcze rozwijane, czy sensowniejsza jest zmiana na bardziej nowoczesną alternatywę. Podejścia oparte na SVG średnioterminowo wyprą klasyczne HTML-Maps, bo działają lepiej zarówno responsywnie, jak i dostępnościowo.

Praktyczna wskazówka dla migracji: jeśli projekt istniejący zawiera dziesiątki imagemaps, opłaca się skrypt, który odczytuje istniejące rekordy koordynat i konwertuje je na ścieżki SVG. Przestawienie może wtedy nastąpić w jednym deploymencie, a rozszerzenie można wyłączyć. To redukuje dług techniczny i czyni grafiki przyszłościowymi.

Kto zaczyna dziś od zera, powinien preferować podejście SVG, albo przez rozszerzenie z wyjściem SVG, albo przez własny wzorzec sitepackage, który oferuje redaktorom wizualny edytor i wyświetla SVG we frontendzie. Gosign wdraża oba sposoby i doradza przy wyborze odpowiedniej architektury dla danego projektu.

--- in2publish TYPO3 - Content Staging | Gosign ---
> in2publish: Publikowanie treści ze Staging na Live. Konfiguracja Multi-Server i przepływy pracy, z wykorzystaniem AI.

## Dlaczego in2publish definiuje workflow treści w projektach Enterprise TYPO3

W profesjonalnych instalacjach TYPO3 redaktorzy nie pracują bezpośrednio na systemie live. Pielęgnują treści na środowisku staging, uzgadniają zmiany wewnętrznie i publikują dopiero po zatwierdzeniu. Ale jak dane trafiają ze staging na live? Bez in2publish oznacza to: dump bazy danych na staging, wgranie na live, synchronizacja plików przez FTP. Proces podatny na błędy, trwający 30 do 60 minut, przy którym jedno złe kliknięcie może nadpisać całą bazę danych live.

in2publish od in2code eliminuje ten proces. Redaktorzy klikają w backendzie TYPO3 "Publish" i rozszerzenie synchronizuje dokładnie te zmienione rekordy i pliki na system live. Żadnych dostępów FTP, żadnych dumpów bazy danych, żadnego przestoju. Standard branżowy dla Content-Staging w TYPO3.

## Typowe scenariusze zastosowań

**Redakcyjny workflow zatwierdzania.** Koncern prowadzi stronę korporacyjną na TYPO3 z 12 redaktorami w 3 działach. Każdy dział pielęgnuje swój obszar na staging. Kierownictwo zespołu sprawdza zmiany i zatwierdza je. Redaktor klika "Publish" i tylko jego zatwierdzone strony trafiają na live. Inne obszary strony pozostają nietknięte. in2publish wyświetla przy tym widok różnic: które pola się zmieniły, które obrazy są nowe, które rekordy zostaną nadpisane.

**Publikowanie wielojęzyczne.** Firma prowadzi swoją stronę w 5 językach. Polska redakcja publikuje gotowe teksty, podczas gdy tłumaczenie angielskie jest jeszcze w toku. in2publish umożliwia selektywne publikowanie per język: polska treść idzie na live, angielska pozostaje na staging, aż tłumaczenie jest zakończone.

**Premiery kampanii z określonymi terminami.** Zespół marketingowy przygotowuje stronę premiery produktu, która ma być opublikowana 15 października o 8:00. Wszystkie treści - teksty, obrazy, wideo, landing page - są przygotowywane i testowane na staging. W dniu premiery odpowiedzialny redaktor publikuje wszystko jednym krokiem. Przy problemach in2publish może cofnąć zmiany.

## Architektura techniczna

in2publish pracuje na poziomie bazy danych i systemu plików. Rozszerzenie porównuje stan bazy danych staging z bazą danych live i przenosi różnice. Architektura składa się z czterech komponentów rdzeniowych: porównanie rekordów (identyfikacja zmienionych, nowych i usuniętych rekordów z rozwiązywaniem relacji), synchronizacja FAL (transfer obrazów i dokumentów przez SSH/SFTP z porównaniem hashów), warstwa transportowa (komunikacja przez SSH z uwierzytelnianiem kluczem publicznym) oraz konfiguracja (definicja YAML, które tabele są publikowane, a które wykluczone).

Zależności: TYPO3 Core, dostęp SSH między serwerem staging i live, rozszerzenie PHP-SSH2 lub binaria ssh2 na serwerze.

## Częste problemy i rozwiązania

**Publikowanie przerywa się z "SSH Connection Failed".** Najczęstsza przyczyna: klucz SSH serwera staging nie jest zdeponowany na serwerze live lub konfiguracja SSH w in2publish wskazuje na złego hosta/port. Rozwiązanie: ręczne przetestowanie połączenia SSH, potem sprawdzenie poświadczeń w konfiguracji in2publish.

**Rekordy na live nie są aktualizowane.** Tabela nie jest w białej liście konfiguracji in2publish. To zdarza się często przy niestandardowych tabelach z własnych rozszerzeń. Rozwiązanie: dodanie tabeli w konfiguracji i zdefiniowanie relacji.

**Pliki FAL brakują po opublikowaniu na live.** FAL-Storage na systemie live ma inną ścieżkę niż na staging lub uprawnienia na serwerze live nie pozwalają na zapis w folderze uploadu. Rozwiązanie: upewnienie się, że bazowa ścieżka FAL-Storage jest identyczna na obu systemach i użytkownik SSH ma uprawnienia do zapisu.

## Migracja i kompatybilność wersji

in2publish jest aktywnie utrzymywane przez in2code i dostępne jako pakiet Composer dla TYPO3 v11 i v12 LTS. Wersja Enterprise oferuje dodatkowe funkcje (transport HTTP, rozszerzone logowanie, wsparcie Multi-Environment) i jest licencjonowana odpłatnie.

Przy aktualizacji TYPO3 konfiguracja in2publish musi być sprawdzona: nowe tabele systemowe, zmienione definicje TCA i nowe typy elementów treści wymagają dostosowania białej listy. Gosign zaleca po każdej aktualizacji Core testowe opublikowanie pojedynczej strony, by zwalidować konfigurację, zanim pełna operacja redakcyjna zostanie wznowiona. Test powinien obejmować stronę ze wszystkimi istotnymi typami treści: elementy tekstowe, obrazy, pliki do pobrania i co najmniej jedną relację.

--- in2studyfinder TYPO3 - Kierunki studiów | Gosign ---
> Wyszukiwarka kierunków studiów dla stron TYPO3 uczelni wyższych. Filtrowanie według wydziału, stopnia, lokalizacji, formy studiów.

## Kandydaci na studia oczekują wyszukiwarki, a nie broszury PDF

Uczelnie z 50 do 300 kierunkami studiów stają przed konkretnym problemem: kandydaci chcą filtrować, a nie przewijać. Szukają według rodzaju dyplomu, wydziału, formy studiów i lokalizacji, jednocześnie. in2studyfinder od in2code rozwiązuje dokładnie to w obrębie TYPO3. Rozszerzenie zostało opracowane specjalnie dla środowiska uczelnianego i odwzorowuje złożoną strukturę licencjat, magisterium, studia dzienne, zaoczne, dualne i dokształcające w jednej masce filtrującej. Ponad 20 niemieckojęzycznych uczelni używa rozszerzenia produkcyjnie.

Dla zespołów webowych uczelni, które dotychczas pielęgnowały informacje o kierunkach studiów przez statyczne strony lub własne rozwiązania, przejście na in2studyfinder jest znacznym zyskiem efektywności. Zamiast tworzyć osobną podstronę dla każdego nowego kierunku, redaktorzy pielęgnują rekord w backendzie, a rozszerzenie automatycznie generuje widok listy, stronę szczegółową i funkcję filtrowania. Na uczelni zawodowej z 80 kierunkami oszczędza to szacunkowo 40 godzin pierwszej konfiguracji w porównaniu z ręczną strukturą stron.

## Typowe scenariusze zastosowań sięgają od katalogu kierunków do przeglądu akredytacji

Standardowy scenariusz to centralna wyszukiwarka kierunków na stronie głównej uczelni. Kandydaci trafiają na stronę, wybierają wydział, dyplom i formę studiów i natychmiast otrzymują przefiltrowaną listę. Kliknięcie prowadzi do strony szczegółowej z planem modułów, warunkami przyjęcia, terminami rekrutacji i osobami kontaktowymi. Na uczelni zawodowej z 80 kierunkami zmniejsza to liczbę odsłon do uzyskania żądanej informacji z średnio 6 do 2.

Drugi scenariusz: wyszukiwanie ponad lokalizacjami u uczelni z wieloma kampusami. Uniwersytet z lokalizacjami w trzech miastach pokazuje wszystkie kierunki w jednym widoku i pozwala filtrować według kampusu. Informacja o lokalizacji jest pielęgnowana jako własna relacja, a nie jako tekst, co gwarantuje spójne filtrowanie.

Trzeci scenariusz: przeglądy akredytacji dla zapewnienia jakości. Polskie uczelnie podlegają kontroli Polskiej Komisji Akredytacyjnej i muszą wykazać, które kierunki są akredytowane i do kiedy. in2studyfinder może odwzorować te metadane jako pola niestandardowe i wyświetlać je w widoku listy, co dział akredytacji wykorzystuje jako podstawę pracy. Eksport danych kierunków jako CSV lub PDF dodatkowo umożliwia przekazanie do PKA lub innych zewnętrznych instytucji.

## Architektura techniczna opiera się na rekordach Extbase z konfigurowalnymi relacjami

in2studyfinder to rozszerzenie Extbase/Fluid od in2code, niemieckiego dostawcy usług TYPO3 stojącego za powermail i in2publish. Kierunki studiów są zapisywane jako rekordy domenowe we własnej tabeli. Każdy rekord zawiera pola obowiązkowe jak tytuł, rodzaj dyplomu, regulaminowy czas studiów, punkty ECTS i wydział oraz pola opcjonalne dla progu punktowego, opłat za studia, statusu akredytacji i linku rekrutacyjnego.

Filtrowanie w frontendzie działa przez żądania AJAX, dzięki czemu strona nie jest przeładowywana przy filtrowaniu. Znacznie poprawia to doświadczenie użytkownika, szczególnie na urządzeniach mobilnych. Konfiguracja filtrów jest sterowana przez TypoScript: które pola są wyświetlane jako filtry, jakie sortowanie obowiązuje i ile wyników pokazuje się na stronę.

Szablony są oparte na Fluid i można je nadpisać w sitepackage. Rozszerzenie dostarcza standardowe szablony, które dla większości uczelni działają jako punkt startowy. Dla uczelni z własnym corporate designem Gosign dostosowuje szablony i integruje je w istniejący sitepackage, dzięki czemu strony kierunków pasują wizualnie bez przerw do całego serwisu.

## Częste problemy dotyczą jakości danych, wydajności i wielojęzyczności

Największy problem przy wdrożeniu to jakość danych. Informacje o kierunkach studiów istnieją na uczelniach często w trzech do pięciu różnych systemach: USOS, własne bazy danych wydziałów, broszury PDF i ręcznie pielęgnowane teksty strony. Zanim in2studyfinder będzie mógł działać produkcyjnie, te źródła muszą zostać skonsolidowane. Gosign wspiera ten proces strukturalnym szablonem importu, który wydziały wypełniają, a my automatycznie importujemy do TYPO3.

Drugi problem: wydajność przy dużych ilościach danych. Uczelnie z ponad 200 kierunkami i złożonymi relacjami (wydział, lokalizacja, forma studiów, język) mogą doświadczać opóźnień w filtrowaniu AJAX, jeśli zapytania do bazy danych nie są zoptymalizowane. Indeksy na relacjach i poprawnie skonfigurowany cache w TypoScript rozwiązują problem zwykle w pełni. Dodatkowo pomaga rozgrzewanie cache po każdej zmianie danych, aby pierwszy odwiedzający po aktualizacji nie zobaczył wolnej strony.

Trzeci problem: wielojęzyczność. Międzynarodowe uczelnie z anglojęzycznymi kierunkami potrzebują spójnego tłumaczenia masek filtrów, kategorii i stron szczegółowych. in2studyfinder wykorzystuje framework tłumaczeń TYPO3, ale konfiguracja języków fallback i nakładek tłumaczeń musi być starannie dostosowana do wymagań uczelni. Szczególnie przy kierunkach oferowanych tylko w jednym języku (np. polski licencjat, ale anglojęzyczne magisterium) zachowanie fallbacku musi być tak skonfigurowane, żeby filtrowanie działało specyficznie językowo i nie dawało mylących wyników.

Czwarty problem, który Gosign regularnie widzi w projektach uczelnianych: nazwy kierunków zmieniające się z biegiem lat. "Informatyka stosowana" staje się "inżynierią danych", ale zachowuje ten sam URL szczegółowy. Rozszerzenie musi być skonfigurowane tak, aby zmiany nazw nie tworzyły broken linków, a stare URL-e były przekierowywane na aktualną stronę.

## TYPO3 v12 jest wspierane, kompatybilność z v13 zależy od planu wydań in2code

in2code aktywnie pielęgnuje in2studyfinder i regularnie dostarcza aktualizacje. Aktualna wersja obsługuje TYPO3 v11 i v12. Ponieważ in2code to komercyjny dostawca usług TYPO3 z długoterminową strategią produktową, kompatybilność z v13 jest oczekiwana, ale jeszcze nie oficjalnie wydana. Przy upgrade z v10 lub v11 na v12 breaking changes dotyczą przede wszystkim konfiguracji TypoScript (nowa składnia SiteSet) i ewentualnych własnych ViewHelperów w szablonach. Struktura bazy danych pozostaje stabilna, dzięki czemu migracja danych zwykle nie jest potrzebna.

--- in2template TYPO3 - Zarządzanie szablonami | Gosign ---
> Rozszerzenie do zarządzania szablonami TYPO3 od in2code. Upraszcza zarządzanie Fluid Templates i Site Packages.

## in2template wprowadza strukturę do Site Packages, zanim staną się piekłem utrzymania

Kto w TYPO3 stawia Site Package dla dużej strony, staje za każdym razem przed tym samym pytaniem: jak zorganizować szablony, partiale, layouty i elementy treści tak, żeby za dwa lata wciąż były utrzymywalne? Rozszerzenie in2template z domu in2code jest próbą odpowiedzi na to pytanie w sposób strukturalny. Dostarcza podstawowe rusztowanie dla nowoczesnych Site Packages: jasną strukturę katalogów, predefiniowane elementy treści, przygotowaną konfigurację dla TypoScript, Fluid Styled Content i layoutów backendowych. Dla zespołów TYPO3, które regularnie rozpoczynają nowe projekty, in2template zastępuje starą praktykę copy-paste z poprzedniego projektu klienta udokumentowanym wzorcem.

Grupą docelową są agencje z kilkoma równoległymi projektami TYPO3 i zespoły inhouse, które pielęgnują corporate-templates dla stron koncernowych lub akademickich. Szczególnie tam, gdzie deweloperki i redaktorki dzielą Site Package, spójna konwencja folderów i nazw jest niezbędna do przetrwania. in2template adresuje dokładnie tę lukę.

## Typowe scenariusze zastosowania

Pierwszym scenariuszem jest porządny start projektu. Agencja z ośmioma deweloperami i trzema działającymi projektami TYPO3 wprowadza in2template jako wewnętrzny standard dla Site Packages. Każdy nowy projekt zaczyna się tym samym szkieletem: identyczna struktura katalogów, identyczne konwencje nazw, identyczna baza TypoScript. Wynik: deweloper może przechodzić między projektami bez konieczności każdorazowej reorientacji.

Drugim scenariuszem jest modernizacja starego Site Package. Portal uczelniany z 800 stronami i katalogiem szablonów, który rósł od TYPO3 v7, jest w ramach upgrade z v11 na v12 na nowo strukturyzowany. Zamiast dalej przenosić stary chaos, zespół buduje Site Package na bazie in2template od nowa i stopniowo migruje treści.

Trzecim scenariuszem jest onboarding nowych redaktorów. Wydawnictwo z 30 redaktorami wyjaśnia na bazie szkieletu in2template, które elementy treści są przeznaczone do czego. Spójność w nazewnictwie i strukturze skraca szkolenie, współczynnik błędów backendowych spada.

Czwartym scenariuszem jest wewnętrzny szablon refactoringu. Firma z pięcioma instalacjami TYPO3 z różnych lat chce długoterminowo przenieść Site Packages do jednolitej struktury. in2template służy przy tym jako szkielet referencyjny, wobec którego każdy stary projekt jest stopniowo przebudowywany, bez konieczności omawiania przez zespół każdorazowo nowej struktury docelowej.

## Architektura techniczna

in2template nie jest klasycznym add-onem, lecz raczej szablonem dla własnego Site Package. Rozszerzenie przynosi strukturę katalogów: Resources/Private/Templates, Resources/Private/Partials, Resources/Private/Layouts, Configuration/TypoScript, Configuration/TsConfig, Configuration/TCA/Overrides. Rusztowanie jest uzupełnione o przygotowane elementy treści (tekst, tekst z obrazem, akordeon, teaser-grid) i konfigurację dla layoutów backendowych.

Instalacja odbywa się jako klasyczne pobieranie Composer pakietu, który następnie jest kopiowany do własnego repozytorium Site Package i zmieniana jest mu nazwa. W praktyce zespoły rzadziej używają in2template jako bezpośredniej zależności, typowe jest początkowe klonowanie, które następnie rośnie projektowo. To czyni rozszerzenie starter-kitem, a nie frameworkiem, który musiałby być aktualizowany między wersjami.

Dla integracji z Fluid Styled Content istnieją własne mechanizmy override, które zapewniają, że dostarczone elementy treści koegzystują z elementami core. Ścieżki TypoScript są konsekwentnie namespaced, żeby kilka Site Packages mogło działać równolegle na tej samej instalacji.

## Częste problemy i rozwiązania

Pierwszym problemem jest pomylenie z frameworkiem. Zespoły, które osadzają in2template jak Bootstrap lub Tailwind i liczą na aktualizacje, doznają rozczarowania: rozszerzenie to szablon do skopiowania, a nie stos upstream. Rozwiązaniem jest traktowanie in2template jako jednorazowego wzorca i wyraźne wersjonowanie powstającego z niego własnego Site Package.

Drugim problemem jest przeładowanie niewykorzystanymi elementami treści. Starter-kit przynosi więcej elementów, niż większość projektów potrzebuje. Kto ich nie używa, mimo to wlecze je przez utrzymanie. Rozwiązaniem jest cleanup bezpośrednio po początkowym imporcie: kasowanie niewykorzystanych elementów treści, usuwanie nieużywanych layoutów backendowych, skreślanie nieużywanych bloków TypoScript.

Trzecim problemem jest dostosowanie do indywidualnych systemów designu. in2template dostarcza CSS zbliżone do Tailwind z własnymi klasami utility. Kto używa istniejącego systemu designu z własnymi nazwami tokenów, musi konsekwentnie przekładać dostarczoną stylizację, inaczej powstaje dublowanie stylów i sprzeczna kaskada.

Czwartym problemem są konflikty z innymi starter-kitami. Kto częściowo przejmuje in2template i równolegle integruje elementy z innego szkieletu, otrzymuje sprzeczne ścieżki TypoScript i nakładające się namespace'y Fluid. Rozwiązaniem jest na początku projektu decyzja dokładnie o jednym szkielecie i trzymanie niespójnych komponentów dodatkowych w jasno nazwanej warstwie projektowej.

## Migracja i kompatybilność wersji

in2template jest utrzymywane przez in2code dla TYPO3 v11 i v12, kompatybilność z TYPO3 v13 jest aktualizowana wzdłuż cykli wydań samego TYPO3. Ponieważ rozszerzenie w projektach prawie zawsze jest klonowane i dostosowywane, kwestia wersji jest mniej kwestią ścieżek update, a bardziej kwestią dyscypliny kodu: zespoły powinny przy upgrade swojego Site Package rzucić okiem na aktualne repozytorium in2template, aby dociągnąć strukturalne ulepszenia (nowe konwencje layoutów backendowych, nowe wzorce Fluid).

Ważny przy upgrade Site Package opartego na in2template jest spojrzenie na zmienione konwencje TYPO3: TCA-Overrides, definicje layoutów backendowych, rejestracja elementów treści i renderowanie Fluid zmieniały się między v11 a v13 wielokrotnie. Kto nie dociąga tych zmian we własnym Site Package, ryzykuje, że treści w backendzie nagle wyglądają pusto lub wizardy elementów treści już się nie pojawiają.

Gosign przejmuje w projektach TYPO3 analizę, które części istniejącego Site Package można uporządkować według wzorca zbliżonego do in2template, a które lepiej zmigrować na własny, minimalistyczny szkielet. Wynikiem jest Site Package, które przechodzi przez code review bez szmerów i przy następnym upgrade TYPO3 nie produkuje niespodzianek.

--- Social Share Buttons TYPO3 | Gosign ---
> Rozszerzenie Social Share Buttons dla TYPO3. Gosign zaleca zamiast tego lekkie Custom Share Links - bez overhead rozszerzenia, zgodne z RODO.

## Social Share Buttons jako rozszerzenie są w większości projektów TYPO3 zbędne

Pomysł jest prosty: odwiedzający powinni móc jednym kliknięciem udostępnić treści na LinkedIn, X lub Facebooku. insign_share_buttons dostarcza dokładnie to jako rozszerzenie TYPO3 - przyciski dla różnych sieci, konfigurowalne w backendzie. Jednak rzeczywistość pokazuje: dla funkcji, która w istocie składa się z pięciu linków HTML, pełne rozszerzenie z własną konfiguracją, setupem TypoScript i obowiązkiem aktualizacji jest w większości przypadków nadmiarowe. Gosign zamiast tego zaleca natywne linki share, które wdraża się w 15 minut i nie tworzą zależności.

Jest to szczególnie istotne od czasu RODO: wiele rozszerzeń social share doładowuje w tle JavaScript z sieci, co bez zapytania o zgodę jest sprzeczne z ochroną danych. Czysto URL-owe linki share całkowicie omijają ten problem, ponieważ nawiązują połączenie z siecią dopiero po kliknięciu. Urząd Ochrony Danych Osobowych (UODO) regularnie sprawdza przyciski share podczas audytów stron, a rozszerzenie, które bez pytania ładuje zewnętrzne skrypty, jest wykrywane jako naruszenie.

## Typowe scenariusze zastosowań ograniczają się do treści pielęgnowanych redakcyjnie

Standardowy scenariusz to firmowa strona z blogiem lub magazynem. Redaktorzy chcą pod każdym artykułem wyświetlać przyciski dla LinkedIn, X, Facebook i e-mail. insign_share_buttons umożliwia to przez element treści, który jest wbudowany w szablon strony. Rozszerzenie odczytuje tytuł i URL aktualnej strony i generuje z nich URL-e share.

Drugi scenariusz dotyczy portali intranetowych, w których pracownicy mają udostępniać wewnętrzne newsy przez Teams lub Slack. Tutaj rozszerzenie jest rzeczywiście bardziej użyteczne niż na stronach publicznych, ponieważ problematyka RODO jest oceniana inaczej wewnątrz firmy, a konfiguracja celów share może być pielęgnowana w backendzie.

Trzeci scenariusz: strony z naciskiem na employer branding, na których ogłoszenia o pracę mają być rozpowszechniane przez social media. Przyciski share są celowo umieszczane na stronach karier, aby pracownicy mogli udostępniać otwarte stanowiska w swojej sieci. Współczynnik konwersji tych przycisków według doświadczeń wynosi 0,5 do 2% odwiedzających stronę. Na LinkedIn współczynniki kliknięć w udostępnione ogłoszenia o pracę są dwa razy wyższe niż w ogólne newsy firmowe, co czyni ten scenariusz najbardziej efektywnym zastosowaniem Social Share Buttons.

## Architektura techniczna to prosty element treści z konfiguracją TypoScript

insign_share_buttons rejestruje element treści w TYPO3, wstawiany przez szablon strony lub jako plugin. Konfiguracja definiuje, które sieci są wyświetlane, czy używane są ikony czy etykiety tekstowe i czy mają być pokazywane liczniki. Renderowanie odbywa się przez szablony Fluid, które można nadpisać w sitepackage.

URL-e share są generowane po stronie serwera i podążają za standardowym schematem odpowiednich sieci: `https://www.linkedin.com/sharing/share-offsite/?url=` plus zakodowany URL strony dla LinkedIn, `https://twitter.com/intent/tweet?url=` dla X. Metadane takie jak tytuł i opis są odczytywane z właściwości strony lub tagów OpenGraph.

Rozszerzenie nie ma znaczących zależności poza rdzeniem TYPO3. Nie ma ładowania JavaScript z zewnętrznych domen, dopóki funkcja licznika pozostaje wyłączona. Po włączeniu licznika są wyzwalane wywołania API do sieci, co z kolei wymaga zapytania o zgodę.

Szczegół techniczny, który często jest pomijany: URL share musi być kodowany URL-owo, aby znaki specjalne w tytułach stron (polskie znaki, ampersand, cudzysłowy) były poprawnie przekazywane do sieci. Rozszerzenie automatycznie zajmuje się tym kodowaniem, co przy ręcznych linkach share jest częstym błędem.

## Częste problemy to naruszenia RODO, brakujące tagi OpenGraph i konflikty stylistyczne

Problem pierwszy: ochrona danych. Wiele instalacji ma aktywną funkcję licznika, która bez zgody cookie przesyła dane osobowe na serwery w USA. Rozwiązanie: wyłączyć liczniki i używać wyłącznie linków share opartych na URL, które nawiązują połączenie dopiero po kliknięciu. Jeszcze lepiej: całkowicie zastąpić rozszerzenie natywnymi linkami share, które leżą jako partial Fluid w sitepackage.

Problem drugi: brakujące lub błędne tagi OpenGraph. Gdy strona TYPO3 nie dostarcza meta-tagów og:title i og:description, LinkedIn i Facebook przy udostępnianiu pokazują pusty podgląd lub ciągną losowe fragmenty tekstu. Rozwiązanie nie leży w rozszerzeniu share, lecz w konfiguracji SEO strony: tagi OpenGraph muszą być poprawnie ustawione w szablonie strony.

Problem trzeci: konflikty stylistyczne między dostarczanymi stylami CSS rozszerzenia a corporate designem. Rozszerzenie przynosi własne arkusze stylów, które mogą kolidować z istniejącymi stylami przycisków. Czyste rozwiązanie: wyłączyć CSS rozszerzenia i stylować przyciski przez własny arkusz stylów sitepackage.

Kolejny problem, który często jest zauważany późno: brak wsparcia share dla WhatsApp. Na urządzeniach mobilnych WhatsApp to najczęściej używany kanał share, ale nie każde rozszerzenie natywnie obsługuje link share do WhatsAppa. Ręczne dodanie jest trywialne (https://api.whatsapp.com/send?text={url}), ale musi być jawnie wbudowane.

## Rozszerzenie działa pod TYPO3 v12, ale przebudowa jest bardziej ekonomiczna

insign_share_buttons jest kompatybilny z TYPO3 v12. Dla TYPO3 v13 dostępność zależy od maintainera. Gosign zaleca przy migracji na v12 lub v13 zastąpienie rozszerzenia prostym partialem Fluid. Pięć linii HTML na sieć, żadnej zależności od rozszerzenia, żadnego obowiązku aktualizacji, pełna zgodność z RODO. Nakład pracy na tę zmianę wynosi jedną do dwóch godzin wraz ze stylizacją i testowaniem wszystkich linków sieci. W Gosign stosujemy to podejście standardowo we wszystkich nowych projektach TYPO3 i pielęgnujemy zestaw szablonów partial dla LinkedIn, X, Facebook, WhatsApp i e-mail, który można zintegrować w każdym sitepackage.

--- Inxmail TYPO3 - Enterprise Newsletter | Gosign ---
> Inxmail Professional to system newsletter enterprise z Niemiec. Integracja z TYPO3: synchronizacja subskrybentów, synchronizacja szablonów, maile transakcyjne.

## Inxmail to platforma newslettera enterprise, która natywnie integruje się z redakcjami TYPO3

Firmy z ponad 50.000 odbiorców newslettera, ścisłymi wymaganiami zgodności i istniejącym serwisem TYPO3 stają przed konkretną decyzją: Mailchimp z przetwarzaniem danych w USA i ryzykiem RODO, czy europejskie rozwiązanie integrujące się bezpośrednio z istniejącą infrastrukturą treści. Inxmail Professional to to rozwiązanie. Serwery w Niemczech, certyfikowane przetwarzanie danych i rozszerzenie TYPO3, które steruje listami subskrybentów, szablonami i kampaniami bezpośrednio z CMS. Dla polskich firm oznacza to zgodność z RODO i przetwarzanie danych na terenie UE, zgodne z wymaganiami UODO.

Rozszerzenie TYPO3 synchronizuje zapisy dwukierunkowo: nowi subskrybenci z formularzy TYPO3 automatycznie lądują w listach Inxmail, a wypisania w Inxmail są odzwierciedlane z powrotem do TYPO3. Dla zespołów marketingu oznacza to: jedno źródło danych, żadnych ręcznych eksportów, żadnego ryzyka przestarzałych list. W praktyce eliminuje to najczęstszy błąd przy wysyłce newslettera: wysyłkę do przestarzałej listy odbiorców zawierającej już wypisane kontakty.

## Typowe scenariusze zastosowań obejmują B2B newsletter, maile transakcyjne i komunikację wydarzeń

Głównym scenariuszem jest klasyczny newsletter B2B dla firm z 10.000 do 500.000 odbiorców. Redakcja pielęgnuje treści w TYPO3, rozszerzenie automatycznie przenosi teasery i linki do szablonów Inxmail. Osoby odpowiedzialne za marketing segmentują odbiorców według branży, regionu lub zainteresowań i wysyłają warianty docelowe dla grup. Współczynniki otwarć i dane kliknięć wracają przez API do backendu TYPO3, dzięki czemu redakcja widzi wydajność poszczególnych artykułów.

Drugi scenariusz: maile transakcyjne wyzwalane przez akcje użytkownika na stronie. Potwierdzenie rejestracji, link do pobrania lub potwierdzenie zamówienia nie są wysyłane przez lokalny serwer pocztowy, lecz przez infrastrukturę Inxmail z gwarantowaną dostarczalnością. SPF, DKIM i DMARC są w Inxmail skonfigurowane z góry, co znacznie poprawia dostarczalność w porównaniu do standardowego PHP-Mailera.

Trzeci scenariusz: komunikacja wydarzeń dla firm regularnie organizujących targi, webinary lub konferencje. Zaproszenia, przypomnienia i follow-up są konfigurowane jako kampanie oparte na triggerach w Inxmail i wyzwalane przez zdarzenia w TYPO3, na przykład przez rejestrację w formularzu powermail. Logika triggerów pozwala też na bardziej złożone sekwencje: zaproszenie cztery tygodnie wcześniej, przypomnienie tydzień wcześniej, potwierdzenie uczestnictwa dzień przed i prośba o feedback dwa dni po.

## Architektura techniczna łączy formularze TYPO3 frontendowe z REST-API Inxmail

Rozszerzenie wykorzystuje REST-API Inxmail do komunikacji między TYPO3 a Inxmail Professional. W rdzeniu integracja składa się z trzech modułów: usługi Subscriber-Sync, modułu Template-Sync i triggera kampanii.

Subscriber-Sync działa przez zadanie Scheduler, które w konfigurowalnych interwałach (typowo: co 5 do 15 minut) uzgadnia nowe zapisy, zmiany i wypisania między TYPO3 a Inxmail. Kierunek synchronizacji jest konfigurowalny: jednokierunkowy (TYPO3 do Inxmail) lub dwukierunkowy. Przy synchronizacji dwukierunkowej konflikty są rozwiązywane przez znaczniki czasu, gdzie zwycięża nowszy rekord.

Moduł Template-Sync przenosi obszary stron TYPO3 jako treści newslettera. Redaktorzy oznaczają elementy treści w backendzie TYPO3 jako "Newsletter-ready", a rozszerzenie renderuje te elementy w szablonie HTML kompatybilnym z Inxmail. Oszczędza to podwójnej pielęgnacji treści strony i treści newslettera.

Autentykacja odbywa się przez klucze API konfigurowane w Extension Manager TYPO3. Wszystkie wywołania API idą przez HTTPS, a rozszerzenie loguje każdą operację synchronizacji w dedykowanej tabeli logów, co jest istotne dla audytów zgodności. Dane logu zawierają znaczniki czasu, liczbę zsynchronizowanych rekordów, błędy i ostrzeżenia, dzięki czemu podczas audytu można wykazać, kiedy i jakie dane zostały przeniesione.

## Częste problemy dotyczą konfliktów sync, renderowania szablonów i limitów API

Dominującym tematem supportu jest konflikt synchronizacji przy sync dwukierunkowym. Gdy subskrybent jest jednocześnie zmieniany zarówno w TYPO3, jak i w Inxmail, mogą wystąpić niespójności danych. Rozwiązanie: jasno zdefiniować kierunek sync. W 90% przypadków TYPO3 jest wiodącym źródłem danych podstawowych, a Inxmail jest wiodącym źródłem danych zaangażowania (otwarcia, kliknięcia, bounces).

Drugi problem: różnice w renderowaniu HTML między frontendem TYPO3 a klientem e-mail. Element treści, który na stronie wyświetla się poprawnie, w Outlooku lub Gmailu może wyglądać inaczej. Rozszerzenie tłumaczy wprawdzie HTML TYPO3 na inline-CSS dla kompatybilności e-mail, ale złożone układy z Flexbox lub Grid muszą być uproszczone dla klientów e-mail. Zalecamy testowanie szablonów newslettera osobno, idealnie narzędziem takim jak Litmus lub Email on Acid.

Trzeci problem: limity API przy dużych operacjach sync. Kto synchronizuje 100.000 subskrybentów jednocześnie, może osiągnąć limit API Inxmail. Rozwiązanie: batch-based sync z konfigurowalną wielkością paczki (zalecane: 500 rekordów na wywołanie API) i wykładnicze backoff przy odpowiedziach rate-limit.

## TYPO3 v12 jest wspierane przez oficjalne rozszerzenie, v13 wymaga weryfikacji

Inxmail aktywnie pielęgnuje rozszerzenie TYPO3, ponieważ rynek TYPO3 jest istotnym kanałem sprzedaży Inxmail Professional. Aktualna wersja obsługuje TYPO3 v11 i v12. Przy upgrade z v10 na v12 trzeba przede wszystkim dostosować konfiguracje zadań Scheduler, ponieważ TYPO3 v12 zmienił API Schedulera. Autentykacja API i Subscriber-Sync pozostają stabilne.

Dla TYPO3 v13 jeszcze nie ma oficjalnego wydania. Firmy planujące upgrade na v13 powinny wcześnie skonsultować dostępność z Inxmail, ponieważ integracje newslettera enterprise należą do najbardziej krytycznych zależności przy upgrade CMS. Jako rozwiązanie przejściowe integracja może być zrealizowana przez własną warstwę Middleware, która bezpośrednio odwołuje się do API Inxmail bez używania rozszerzenia. Gosign wdrożył to rozwiązanie dla klientów, którzy chcieli migrować na v13 zanim oficjalne rozszerzenie było dostępne. Własna warstwa jest też tańsza w utrzymaniu, ponieważ odwołuje się tylko do faktycznie używanych endpointów API i nie wlecze nieużywanych funkcji.

--- iSpider TYPO3 - Web-Crawler | Gosign ---
> Web-Crawler/Spider dla TYPO3: Crawlowanie stron wewnętrznych, znajdowanie uszkodzonych linków, generowanie sitemapy.

## Uszkodzone linki kosztują pozycje w rankingu i zaufanie, ale prawie nikt ich regularnie nie sprawdza

Każda strona TYPO3 z więcej niż 200 podstron ma uszkodzone linki. Redaktorzy usuwają strony, przenoszą treści lub zmieniają sluggi URL bez sprawdzania wszystkich wewnętrznych linków. Rezultat: błędy 404, które Google traktuje jako sygnał jakości i które frustrują odwiedzających. iSpider to wewnętrzny web-crawler dla TYPO3, który crawluje własny frontend, identyfikuje uszkodzone linki i generuje sitemapę. Narzędzie wypełnia lukę między ręczną kontrolą a zewnętrznymi narzędziami SEO, które nie mają dostępu do obszarów chronionych.

Dla redakcji i kierowników projektów technicznych iSpider to instrument QA, który radzi sobie bez zewnętrznych zależności. Crawler działa w backendzie TYPO3, zna strukturę strony i może też sprawdzać obszary chronione hasłem, do których nie docierają zewnętrzne narzędzia jak Screaming Frog. Wyniki są dostępne bezpośrednio w backendzie TYPO3, co przyspiesza poprawianie uszkodzonych linków przez redaktorów, ponieważ nie muszą przełączać się między różnymi narzędziami.

## Typowe scenariusze zastosowań sięgają od kontroli pre-launch do bieżącego monitoringu

Najczęstszy scenariusz to kontrola pre-launch przed relaunchem lub upgrade TYPO3. Zanim nowa wersja pójdzie live, iSpider crawluje środowisko stagingowe i dostarcza pełną listę wszystkich uszkodzonych linków, brakujących obrazów i łańcuchów przekierowań. Typowy relaunch średniej wielkości strony (500 do 1.000 podstron) z doświadczenia produkuje 30 do 80 uszkodzonych linków, które bez systematycznego crawlowania trafiłyby niezauważone na produkcję.

Drugi scenariusz: bieżący monitoring w codziennej pracy redakcji. Tygodniowe zadanie Scheduler crawluje stronę i wysyła raport do redakcji ze wszystkimi nowymi błędami 404 od ostatniego przebiegu. W ten sposób problemy są wykrywane i naprawiane w ciągu dni, a nie miesięcy.

Trzeci scenariusz: analiza SEO struktury wewnętrznych linków. iSpider pokazuje, które strony nie mają przychodzących linków wewnętrznych (strony osierocone) i które strony mają szczególnie wiele linków przychodzących. Te dane pomagają w strategii treści i optymalizacji wewnętrznego linkowania. Typowa analiza ujawnia, że 10 do 15% wszystkich stron jest osieroconych i w konsekwencji rzadko lub nigdy nie są crawlowane przez Google.

## Architektura techniczna działa jako moduł backendu z integracją Schedulera

iSpider rejestruje się jako moduł backendu w TYPO3 i wykorzystuje Scheduler TYPO3 do automatycznych przebiegów crawlowania. Crawler startuje od konfigurowalnej strony wejściowej (zwykle root-page) i podąża rekurencyjnie za wszystkimi linkami wewnętrznymi do ustawialnej głębokości. Linki zewnętrzne są sprawdzane pod kątem dostępności, ale nie są dalej śledzone.

Wyniki są zapisywane w dedykowanej tabeli bazy danych: URL, kod statusu HTTP, czas odpowiedzi, strona referencyjna i znacznik czasu. Moduł backendu pokazuje wyniki jako filtrowaną listę z sortowaniem według kodu statusu, co ułatwia priorytetyzację napraw.

Prędkość crawlowania jest sterowana przez konfigurację: jednoczesne żądania, czas oczekiwania między żądaniami i maksymalna głębokość crawlowania. Dla dużych instalacji z ponad 5.000 podstron zalecany jest nocny crawl przez Scheduler, aby nie obciążać serwera w ciągu dnia. Wyniki pozostają zapisane w bazie danych i są dostępne przez moduł backendu w każdej chwili, również między przebiegami crawlowania. Pozwala to na historyczne porównanie rozwoju uszkodzonych linków przez tygodnie i miesiące.

## Częste problemy to timeouty serwera, niepełne crawle i false positives

Najczęstszy problem: crawl przerywa się przy dużych stronach, ponieważ osiągany jest limit pamięci PHP lub max_execution_time. Rozwiązanie: podzielić crawl przez Scheduler na batche i zwiększyć limity PHP dla kontekstu CLI (zalecane: memory_limit 512M, max_execution_time 0 dla CLI).

Drugi problem: niepełne crawle przy treściach renderowanych w JavaScript. iSpider to crawler po stronie serwera, który nie wykonuje JavaScript. Single-Page-Applications lub treści doładowywane przez AJAX nie są wykrywane przez crawlera. Rozwiązanie: dla obszarów intensywnie używających JavaScript wdrożyć dodatkowo zewnętrzny crawler jak Screaming Frog.

Trzeci problem: false positives przy linkach zewnętrznych. Niektóre strony blokują crawlery przez wykrywanie User-Agent i dostarczają kod statusu 403, mimo że URL jest osiągalny dla przeglądarek. iSpider zgłasza to jako błąd. Rozwiązanie: skonfigurować listę wyjątków dla znanych false positives i ustawić String User-Agent na wartość typową dla przeglądarki. LinkedIn, Facebook i niektóre strony chronione CDN to typowe kandydaty na false positives.

Kolejny problem: łańcuchy przekierowań. iSpider podąża za przekierowaniami (301, 302), ale nie raportuje, ile hopów było potrzebnych. Potrójne lub poczwórne przekierowania to problem SEO, który bez szczegółowej analizy przekierowań pozostaje niewidoczny. Zewnętrzne crawlery jak Screaming Frog pokazują pełny łańcuch przekierowań włącznie z punktami pośrednimi, czego iSpider nie potrafi.

## iSpider to narzędzie legacy, zewnętrzne alternatywy crawlerów są wydajniejsze

iSpider został opracowany dla TYPO3 v7 i v8 i nie ma oficjalnego wsparcia dla v12 lub v13. Kto migruje na aktualne wersje TYPO3, powinien ocenić zewnętrzne alternatywy. Screaming Frog (narzędzie desktopowe, do 500 URL bezpłatnie), Sitebulb lub zintegrowany TYPO3-Linkvalidator pokrywają funkcje rdzenia. Gosign w własnych projektach używa kombinacji TYPO3 Core-Linkvalidator do kontroli wewnętrznych i zautomatyzowanych crawlów Screaming Frog dla obszernych analiz SEO. Przy migracji z iSpider sprawdzamy, które konfiguracje i raporty w istniejącym setupie są krytyczne, i odwzorowujemy je w nowym rozwiązaniu.

--- iubenda TYPO3 - Ochrona danych | Gosign ---
> iubenda oferuje baner zgody na cookies i automatycznie generowane polityki prywatności. Integracja z TYPO3 osadza oba elementy.

## Cookie-Consent i Privacy Policy z jednej ręki brzmi praktycznie, ale ma zależności

Od czasu RODO i polskiej ustawy Prawo komunikacji elektronicznej każda strona potrzebuje banera zgody cookies i aktualnej polityki prywatności. iubenda oferuje obie rzeczy jako rozwiązanie SaaS: widget JavaScript do banera zgody i generator polityk prywatności i cookies, które automatycznie aktualizują się przy zmianach prawa. Rozszerzenie TYPO3 osadza obie rzeczy w kodzie źródłowym strony. Dla firm, które nie chcą zatrudniać ani inspektora ochrony danych, ani kancelarii do bieżącej pielęgnacji, iubenda to pragmatyczne rozwiązanie.

Trade-off jest jasny: wygoda kontra zależność. Baner zgody i polityka prywatności są ładowane z serwerów iubenda. Gdy usługa nie działa lub zmienia się API, strona jest dotknięta. Alternatywy jak dp_cookieconsent lub Usercentrics działają na tej samej zasadzie, ale z różnymi punktami ciężkości w konfigurowalności i cenie. UODO w Polsce również akceptuje zewnętrzne rozwiązania consent, o ile spełniają one wymogi RODO.

## Typowe scenariusze zastosowań dotyczą stron MŚP, portali i międzynarodowych serwisów

Standardowy scenariusz to średnia firmowa strona z 20 do 100 podstronami, używająca Google Analytics, formularza kontaktowego i osadzonych filmów YouTube. iubenda skanuje stronę, automatycznie wykrywa używane usługi i generuje pasującą politykę cookies. Baner zgody blokuje wykryte cookies, dopóki odwiedzający nie wyrazi zgody. Nakład pracy na konfigurację tego scenariusza wynosi jedną do dwóch godzin.

Drugi scenariusz: wielojęzyczne portale działające w różnych obszarach prawnych. iubenda obok RODO obsługuje też kalifornijskie CCPA i brazylijskie LGPD. Polityka prywatności jest automatycznie wyświetlana w języku odwiedzającego i zawiera istotne podstawy prawne dla danej lokalizacji. Dla firm z grupami docelowymi w Europie, USA i Ameryce Południowej oszczędza to osobne tworzenie trzech do czterech różnych polityk.

Trzeci scenariusz: strony z często zmieniającymi się integracjami third-party. Gdy działy marketingu regularnie wbudowują nowe piksele tracking, widgety czatu lub embeddy social media, iubenda automatycznie aktualizuje politykę cookies przy następnym skanie strony. Zmniejsza to ryzyko, że nowe usługi działają bez zapytania o zgodę. W praktyce jest to szczególnie istotne dla firm używających narzędzi marketing automation, które miesięcznie wbudowują nowe testy A/B, heatmapy lub piksele konwersji bez informowania działu IT.

## Architektura techniczna osadza zewnętrzny widget JavaScript w TYPO3

Rozszerzenie TYPO3 integruje iubenda przez dwa fragmenty kodu: tag JavaScript dla banera zgody i kod embed dla polityki prywatności. Oba fragmenty są konfigurowane w Extension Manager TYPO3 i automatycznie wyprowadzane w nagłówku HTML lub na stronie polityki prywatności. Samo rozszerzenie jest minimalne i zawiera prawie żadnej własnej logiki.

Baner zgody działa zgodnie ze standardem TCF-2.0 (Transparency and Consent Framework) i blokuje cookies przez technikę proxy: zewnętrzne skrypty są ładowane dopiero po udzieleniu zgody przez odwiedzającego. Blokowanie działa przez przepisanie tagów script (type="text/plain" zamiast type="text/javascript") i doładowanie przez JavaScript po zgodzie.

Automatyczne generowanie polityki opiera się na skanerze strony, który crawluje domenę i rozpoznaje używane usługi. Wygenerowane teksty są sprawdzone prawnie i są aktualizowane przez zespół prawników iubenda przy zmianach prawa. Polityka jest osadzana albo jako iFrame, albo jako bezpośredni embed HTML na stronie polityki prywatności.

## Częste problemy to błędy blokowania skryptów, spadki wydajności i przesuwanie treści

Najczęstszy problem: nie wszystkie skrypty third-party są poprawnie blokowane. Gdy skrypt nie jest ładowany przez standardowy tag HTML, lecz dynamicznie przez JavaScript, technika proxy może go nie wykryć. Rozwiązanie: ręczna kontrola wszystkich osadzonych usług i jawna konfiguracja w dashboardzie iubenda. Plugin przeglądarki jak "CookieMetrix" pomaga w weryfikacji.

Drugi problem: spadki wydajności przez dodatkowy JavaScript. Widget iubenda ma 40 do 80 KB (skompresowanych) i jest ładowany z zewnętrznych serwerów. Może to pogorszyć Largest Contentful Paint o 200 do 400 ms. Rozwiązanie: ładować widget asynchronicznie i zapewnić, że nie jest render-blokujący.

Trzeci problem: Content Layout Shift przez nakładkowo wyświetlany baner. Gdy baner pojawia się nad treścią strony, przesuwa widoczny obszar. Google mierzy to jako Cumulative Layout Shift (CLS) i ocenia negatywnie. Rozwiązanie: skonfigurować baner jako overlay (a nie jako element wsuwany) lub zarezerwować stały placeholder w CSS. Wartość CLS poniżej 0,1 to cel, a źle skonfigurowany baner zgody może sam podbić tę wartość do 0,3 lub wyżej.

Dodatkowo niektórzy administratorzy zgłaszają, że dashboard iubenda jest złożony w konfiguracji. Rozróżnienie między "Cookie Solution" (baner zgody), "Privacy Controls and Cookie Solution" (rozszerzony) i "Consent Database" (do dokumentacji zgodności) wymaga zrozumienia własnych wymagań prawnych, którego wielu webmasterów nie posiada. Gosign konfiguruje iubenda w ramach projektów TYPO3 wspólnie z inspektorem ochrony danych klienta, aby konfiguracja techniczna pasowała do oceny prawnej.

## iubenda działa niezależnie od wersji TYPO3, ponieważ integracja jest minimalna

Ponieważ rozszerzenie w rdzeniu osadza tylko dwa fragmenty JavaScript, nie ma głębokiej zależności od API TYPO3. Integracja działa z TYPO3 v10, v11, v12 i prawdopodobnie też v13 bez dostosowań. Przy upgrade trzeba tylko sprawdzić, czy osadzanie fragmentów w nagłówku HTML nadal poprawnie działa, co zwykle jest spełnione. Gosign mimo to zaleca przy każdym upgrade TYPO3 przeprowadzenie testu cookie consent, aby upewnić się, że wszystkie reguły blokowania nadal działają.

--- j77 Template TYPO3 | Gosign ---
> Pakiet szablonów dla TYPO3. Gotowy layout jako punkt startowy. Gosign zaleca Custom Sitepackages zamiast gotowych szablonów dla profesjonalnych projektów - .

## Gotowe szablony TYPO3 przyspieszają start, ale hamują dalszy rozwój

j77_template to wstępnie skonfigurowany pakiet szablonów dla TYPO3, który dostarcza gotowy układ jako punkt startowy. Zawiera nagłówek, stopkę, nawigację, obszary treści i podstawowe definicje stylistyczne. Dla agencji chcących szybko postawić prototyp TYPO3 lub dla wewnętrznych działów IT bez programistów frontendowych jest to kuszące: instalacja, aktywacja, gotowe. Rzeczywistość pokazuje jednak, że gotowe szablony w profesjonalnych projektach po 3 do 6 miesiącach powodują więcej pracy, niż oszczędzają.

Powód: każdy pakiet szablonów przynosi własną strukturę HTML, klasy CSS i konfigurację TypoScript. Gdy design ma odbiegać od standardu, walczy się z logiką szablonu zamiast z nią pracować. Własny sitepackage, od początku dopasowany do wymagań, kosztuje więcej na start, ale oszczędza czas przy każdej późniejszej zmianie.

## Typowe scenariusze zastosowań to prototypy, portale wewnętrzne i strony stowarzyszeń

Najczęstszy scenariusz to szybki start dla prototypów i proof-of-concepts. Agencja chce w ciągu dwóch dni pokazać klientowi, jak jego treści mogłyby wyglądać w TYPO3. j77_template dostarcza prezentacyjny układ bez rozwoju frontendu. Prototyp po akceptacji jest zastępowany szytym na miarę sitepackage.

Drugi scenariusz: portale wewnętrzne i aplikacje intranetowe, gdzie design jest drugorzędny. Dział IT buduje wewnętrzny portal wiedzy na TYPO3 i potrzebuje funkcjonalnego interfejsu, nie corporate designu. j77_template dostarcza nawigację, breadcrumb i renderowanie treści od razu.

Trzeci scenariusz: strony stowarzyszeń i małe serwisy non-profit z ograniczonym budżetem. Gdy cały projekt internetowy musi zmieścić się poniżej 20.000 złotych, gotowy pakiet szablonów może wyeliminować koszty rozwoju frontendu i zarezerwować budżet na treść i funkcjonalność. W praktyce dotyczy to klubów sportowych, szkół muzycznych, inicjatyw wolontariackich i stowarzyszeń rodziców, które potrzebują prostej, funkcjonalnej strony i nie mają szczególnych wymagań designowych.

## Architektura techniczna to standardowy sitepackage z wstępnie skonfigurowanym TypoScript

j77_template jest technicznie sitepackagem TYPO3 instalowanym przez Extension Manager. Przynosi szablony Fluid dla układów strony, szablony partial dla nagłówka, stopki i nawigacji oraz konfiguracje TypoScript dla renderowania treści. Pliki CSS opierają się na Bootstrap lub porównywalnej bazie frameworka.

Struktura szablonu podąża za standardem TYPO3: Resources/Private/Templates dla układów strony, Resources/Private/Partials dla ponownie używanych obszarów i Resources/Private/Layouts dla szablonów ramowych Fluid. Konfiguracja TypoScript ustawia ścieżki szablonów, konfiguruje renderowanie treści przez FLUIDTEMPLATE i definiuje strukturę nawigacji.

Dostosowania są możliwe przez przekierowanie ścieżek szablonów przez TypoScript na własne pliki. Działa to dla pojedynczych szablonów, ale przy obszernych zmianach prowadzi do tego, że de facto pielęgnuje się równoległy sitepackage, co niweczy zaletę gotowego szablonu.

Typowy problem przy pakietach szablonów to zależność od Bootstrap. j77_template opiera się na określonej wersji Bootstrap. Gdy projekt potrzebuje innej wersji frameworka CSS lub chce całkowicie przejść na Tailwind lub własne CSS, koliduje to z setupem szablonu. Dostarczane pliki CSS nie są zbudowane modułowo, lecz są dostarczane jako monolityczny bundle, który trudno częściowo nadpisać.

## Częste problemy to konflikty upgrade, CSS-overrides i brakująca dokumentacja

Problem pierwszy: konflikty upgrade przy aktualizacji TYPO3. Pakiety szablonów są ściśle związane z wersją TYPO3. Gdy upgrade wprowadza breaking changes w Fluid lub TypoScript, pakiet szablonów musi zostać zaktualizowany. Gdy maintainer nie zrobi tego na czas, szablon blokuje cały upgrade TYPO3. Przy własnych sitepackage ma się tę kontrolę.

Problem drugi: CSS-overrides, które wzajemnie się nadpisują. Szablon przynosi własne style, corporate design wymaga odchyleń, a dodatkowe rozszerzenia też mają CSS. Rezultat to kaskada override'ów, która przy każdej zmianie produkuje nieprzewidywalne efekty uboczne. Rozwiązaniem jest dedykowany arkusz stylów, który całkowicie nadpisuje style szablonu, co jednak podważa cel szablonu.

Problem trzeci: brakująca lub przestarzała dokumentacja. Szablony społecznościowe jak j77_template są często utrzymywane przez pojedyncze osoby i nie mają profesjonalnej dokumentacji. Które stałe TypoScript są dostępne, które zmienne Fluid istnieją w szablonach i jak konfigurowane jest zachowanie responsywne - trzeba to znaleźć przez analizę kodu. Bez dokumentacji każda zmiana programisty to ryzyko, ponieważ wiedza projektowa jest związana z osobą, która dogłębnie przeanalizowała szablon.

## Dla v12 i v13 Gosign zaleca przejście na własny sitepackage

j77_template nie ma gwarantowanego wsparcia dla TYPO3 v12 lub v13. Przy migracji to idealny moment, aby zastąpić pakiet szablonów własnym sitepackage. Koszty własnego sitepackage amortyzują się już przy pierwszej większej zmianie designu, która przy obcym szablonie oznaczałaby godziny lub dni pracy nad override'ami.

Gosign tworzy sitepackages dokładnie dopasowane do corporate designu i funkcjonalnych wymagań projektu. Początkowy nakład pracy na prosty sitepackage wynosi 2 do 5 dni roboczych, w zależności od złożoności designu. Generowanie szablonów wspierane przez AI przyspiesza proces: z mockupu designu nasze tooling generuje szablony Fluid, konfigurację TypoScript i bazową strukturę CSS, które starsi programiści następnie finalizują. Sitepackage dostarczany przez Gosign zawiera oprócz szablonów również dokumentację dostępnych elementów treści, stałych TypoScript i układów strony, dzięki czemu również programiści przejmujący projekt mogą natychmiast produktywnie pracować.

--- jumpurl TYPO3 - Śledzenie pobrań | Gosign ---
> jumpurl: Legacy śledzenie pobrań w TYPO3. Migracja na nowoczesne rozwiązania śledzenia. Z wykorzystaniem AI.

## jumpurl od TYPO3 v9 został usunięty z Core i nie powinien być już używany

jumpurl był przez lata stałym elementem Core TYPO3 i wykonywał prostą rzecz: kierował pobierania i linki zewnętrzne przez URL przekierowujący, aby umożliwić zliczanie kliknięć. Pobieranie PDF nie szło bezpośrednio do przeglądarki, lecz przez adres jumpurl, który protokołował kliknięcie w bazie danych i następnie przekierowywał do właściwego pobierania. W okresie szczytowym rozszerzenie było używane przez szacunkowo 40% wszystkich instalacji TYPO3 do śledzenia pobrań. Od TYPO3 v9 jumpurl nie jest już częścią Core. Jako samodzielne rozszerzenie wprawdzie istnieje dalej, ale architektura jest przestarzała, a nowoczesne alternatywy są pod każdym względem lepsze.

Kto nadal używa jumpurl, pracuje z techniką z ery TYPO3 v4. Rozszerzenie generuje kryptyczne URL-e z parametrami hash, które nie są ani czytelne dla ludzi, ani przyjazne SEO. Śledzenie opiera się na wpisach w bazie danych, których żadne nowoczesne narzędzie analityczne nie potrafi natywnie przeanalizować. Dla funkcji, która dziś każdy standardowy setup analityki odwzorowuje przez zdarzenia, własne rozszerzenie z obciążeniem bazy danych nie jest już adekwatne do czasów.

## Typowe scenariusze zastosowań to śledzenie pobrań i monitoring linków

Głównym scenariuszem było i jest śledzenie pobrań: ile razy pobrano whitepaper, cennik, katalog produktów? jumpurl protokołuje każde kliknięcie w tabeli bazy danych ze znacznikiem czasu, adresem IP i referrerem. Firmy z 50 do 200 pobraniami dziennie używają tych danych do strategii treści i kwalifikacji leadów.

Drugi scenariusz: śledzenie linków zewnętrznych. Gdy firmowa strona linkuje do partnerów, dostawców lub zasobów, jumpurl pokazuje, które cele zewnętrzne otrzymują najwięcej kliknięć. Jest to istotne dla programów afiliacyjnych, raportowania partnerów i analizy zachowania użytkowników.

Trzeci scenariusz: bezpieczne pobierania z kontrolą dostępu. jumpurl może powiązać pobieranie z logowaniem użytkownika, dzięki czemu tylko zalogowani użytkownicy mogą pobierać pliki. System tokenów zapewnia, że bezpośrednie URL-e do chronionych plików nie działają. Dla firm, które chcą udostępniać whitepapers, dokumentacje techniczne lub cenniki tylko po logowaniu, było to w erze TYPO3 v6 i v7 standardowym rozwiązaniem.

## Architektura techniczna opiera się na przepisywaniu URL i logowaniu w bazie danych

jumpurl rejestruje handler eID w Core TYPO3, który przechwytuje przychodzące żądania z parametrem jumpurl. Parametr zawiera hash, który wskazuje na docelowy URL lub ścieżkę pliku. Handler loguje dostęp w tabeli bazy danych (tx_jumpurl_tracking), waliduje hash i kieruje przeglądarkę przez przekierowanie 302 do właściwego celu.

Konfiguracja odbywa się przez stałe TypoScript: które typy plików są śledzone (typowo: PDF, DOCX, XLSX, ZIP), czy są śledzone linki zewnętrzne i czy śledzenie jest aktywne. Rozszerzenie automatycznie modyfikuje generowane linki w frontendzie, dzięki czemu redaktorzy niczego nie muszą ręcznie dostosowywać. Integracja jest przezroczysta: redaktorzy linkują pliki jak zwykle, a jumpurl automatycznie wsuwa warstwę śledzenia.

Log śledzenia zawiera: znacznik czasu, adres IP (istotne dla RODO), docelowy URL, referrer HTTP i User-Agent. Do analizy jest minimalny moduł backendu, który pokazuje liczby kliknięć na URL. Bardziej złożone analizy wymagają bezpośredniego dostępu do bazy danych lub eksportu.

## Częste problemy dotyczą SEO, RODO i kompatybilności z przepisywaniem URL

Problem pierwszy: szkody SEO przez łańcuchy przekierowań. URL-e jumpurl nie są prawdziwymi URL-ami stron, lecz pośrednikami przekierowania. Gdy Google indeksuje link jumpurl (co przy błędnej konfiguracji się zdarza), powstaje łańcuch przekierowań, który marnuje crawl-budget i rozcieńcza link juice. Rozwiązanie: zapewnić, że URL-e jumpurl mają tag noindex lub robots-disallow.

Problem drugi: zgodność z RODO. jumpurl zapisuje adresy IP w formie jawnej. Bez pseudonimizacji lub koncepcji usuwania to naruszenie RODO. W Polsce UODO traktuje to tak samo restrykcyjnie. Tabela bazy danych musi być regularnie czyszczona lub adresy IP muszą być anonimizowane przed zapisem.

Problem trzeci: kompatybilność z nowoczesnym routingiem URL. TYPO3 v12 używa Site-Handling i routingu opartego na Symfony. Architektura jumpurl oparta na eID koliduje w niektórych konfiguracjach z nowym routingiem i produkuje błędy 404. Rozwiązaniem jest migracja na nowoczesną alternatywę. Dodatkowo kryptyczne parametry jumpurl w pasku adresu przeglądarki przeszkadzają w doświadczeniu użytkownika: użytkownicy widzą URL z wartościami hash zamiast czytelnej ścieżki pliku, co może budzić nieufność.

## Migracja na śledzenie oparte na zdarzeniach jest zalecaną drogą przy każdym upgrade TYPO3

jumpurl nie ma oficjalnego wsparcia dla TYPO3 v12 lub v13. Przy migracji Gosign zaleca przejście na śledzenie pobrań oparte na zdarzeniach. Konkretnie oznacza to: atrybut data na linkach pobierania (np. data-track="download") i listener zdarzeń JavaScript, który wysyła kliknięcia do Matomo, Google Analytics 4 lub własnego endpointa. Dla bezpiecznych pobrań nowoczesną alternatywą jest kombinacja dostępu do plików opartego na FAL i systemu tokenów.

Nakład pracy na migrację zależy od ilości istniejących linków jumpurl. Gdy zewnętrzne źródła (newsletter, social media, druk) wskazują na URL-e jumpurl, trzeba skonfigurować przekierowania. Gosign analizuje istniejące dane śledzenia jumpurl, identyfikuje najczęściej używane pobierania i konfiguruje nowe rozwiązanie śledzenia tak, aby zapewnić historyczną porównywalność. Typowo 80% istniejących linków jumpurl to linki wewnętrzne, które można zautomatyzowano przepisać. Pozostałe 20% to referencje zewnętrzne, dla których trzeba skonfigurować stałe przekierowania 301, aby nie stracić link juice.

--- k3n_dvemoji TYPO3 - Emoji i UTF-8mb4 | Gosign ---
> k3n_dvemoji: Obsługa Emoji UTF-8mb4 w TYPO3. Migracja zestawu znaków i konfiguracja bazy danych, z wykorzystaniem AI.

## Emoji jako znaki zapytania to nie problem wyświetlania, lecz błąd konfiguracji bazy danych

Gdy w backendzie TYPO3 redaktor wpisuje emoji, a w frontendzie zamiast tego pojawia się znak zapytania lub puste pole, problem nie leży w przeglądarce ani w TYPO3. Leży w bazie danych MySQL lub MariaDB skonfigurowanej z zestawem znaków utf8 zamiast utf8mb4. Różnica: utf8 zapisuje maksymalnie 3 bajty na znak, emoji potrzebują 4 bajtów. k3n_dvemoji to rozszerzenie TYPO3, które adresuje ten problem, rozszerzając konfigurację bazy danych o obsługę UTF-8mb4. Od TYPO3 v10 Core jest jednak sam przygotowany na utf8mb4, dzięki czemu rozszerzenie jest potrzebne tylko przy starszych lub źle skonfigurowanych instalacjach.

Dla administratorów TYPO3 i agencji opiekujących się starszymi instalacjami k3n_dvemoji to narzędzie diagnostyczne i fix jednocześnie. Rozszerzenie identyfikuje tabele z błędnym zestawem znaków i konwertuje je, co ręcznie jest procesem podatnym na błędy.

## Typowe scenariusze zastosowań dotyczą starszych instalacji, migracji i treści międzynarodowych

Najczęstszy scenariusz to instalacja TYPO3 v8 lub v9 działająca od lat, której baza danych jest nadal skonfigurowana na utf8 (nie utf8mb4). Szacunkowo 30% wszystkich instalacji TYPO3 założonych przed 2018 ma ten problem, ponieważ rutyna instalacyjna wówczas ustawiała utf8 jako domyślny. Dopóki redaktorzy używają tylko znaków łacińskich, nie rzuca się to w oczy. Gdy tylko na stronie zostanie osadzony post social media z emoji lub redaktor wstawi emoji w nagłówek, wyświetlanie się łamie. k3n_dvemoji konwertuje dotknięte tabele i kolumny na utf8mb4.

Drugi scenariusz: migracje bazy danych między serwerami. Przy przeprowadzaniu bazy danych TYPO3 ze starego serwera na nowy zestaw znaków może zostać utracony przez błędne polecenie mysqldump. Dump z --default-character-set=utf8 zamiast utf8mb4 obcina wszystkie znaki 4-bajtowe. k3n_dvemoji pomaga w późniejszej naprawie.

Trzeci scenariusz: międzynarodowe strony z językami azjatyckimi. Chińskie, japońskie i koreańskie znaki potrzebują częściowo 4 bajtów. Bez utf8mb4 pojedyncze znaki są wyświetlane okaleczone, co przy stronach z treściami CJK prowadzi do nieczytelnego tekstu. Również symbole matematyczne, nuty i różne znaki specjalne z obszaru Unicode powyżej U+FFFF są dotknięte, co jest istotne dla stron uczelni i portali naukowych.

## Architektura techniczna analizuje i konwertuje tabele bazy danych na poziomie kolumny

k3n_dvemoji pracuje na dwóch poziomach: analizy i konwersji. W trybie analizy rozszerzenie skanuje wszystkie tabele TYPO3 i sprawdza zestaw znaków każdej kolumny. Wynikiem jest raport pokazujący, które tabele i kolumny nadal są na utf8 (3 bajty) zamiast utf8mb4 (4 bajty). Typowy system TYPO3 ma 100 do 300 tabel, z których często 20 do 50 ma błędny zestaw znaków.

W trybie konwersji rozszerzenie generuje polecenia ALTER TABLE dla każdej dotkniętej kolumny i wykonuje je. Brzmi to trywialnie, ale ma pułapki: indeksy na kolumnach varchar z utf8mb4 mogą przekroczyć maksymalną długość indeksu MySQL (767 bajtów przy InnoDB z antique format). Rozszerzenie sprawdza te limity i dostosowuje definicje indeksów.

Dodatkowo konfiguracja TYPO3 w LocalConfiguration.php musi deklarować zestaw znaków utf8mb4: `['DB']['Connections']['Default']['charset'] = 'utf8mb4'` i `['DB']['Connections']['Default']['tableoptions']['collate'] = 'utf8mb4_unicode_ci'`. Bez tej konfiguracji TYPO3 nadal używa utf8 dla nowych tabel.

## Częste problemy to ograniczenia długości indeksu, błędy backupu i niespójne kolumny

Problem pierwszy: ograniczenie długości indeksu MySQL. Przy InnoDB ze starym formatem Compact (standard do MySQL 5.6) maksymalna długość indeksu to 767 bajtów. varchar(255) z utf8mb4 potrzebuje 1.020 bajtów miejsca indeksu. Konwersja zawodzi z "Specified key was too long". Rozwiązanie: przełączyć ROW_FORMAT na DYNAMIC (standard od MySQL 5.7) lub zmniejszyć długość varchar w dotkniętych kolumnach.

Problem drugi: backup przed konwersją. ALTER TABLE na dużych tabelach (100.000+ wierszy) blokuje tabelę i może prowadzić do przestojów w bazach produkcyjnych. Rozwiązanie: wykonywać konwersję poza godzinami pracy i wcześniej utworzyć pełny backup. Dla dużych tabel zalecany jest pt-online-schema-change od Percona dla bezblokowej konwersji.

Problem trzeci: niespójne kolumny po częściowej konwersji. Gdy skonwertowano tylko części bazy danych, JOIN-y między kolumnami utf8 i utf8mb4 mogą prowadzić do problemów wydajności, ponieważ MySQL wykonuje niejawną konwersję zestawu znaków. Gosign po każdej konwersji sprawdza wszystkie tabele pod kątem spójności.

## Od TYPO3 v10 rozszerzenie jest zbędne, jeśli baza danych jest poprawnie skonfigurowana

TYPO3 v10 i wszystkie kolejne wersje oczekują utf8mb4 jako domyślnego zestawu znaków. Przy nowej instalacji v10 lub wyższej baza danych jest automatycznie poprawnie konfigurowana, a k3n_dvemoji nie jest potrzebne. Rozszerzenie pozostaje istotne dla instalacji migrowanych z v7, v8 lub v9 na v12 lub v13, których baza danych nigdy nie była konwertowana. Gosign rozwiązuje to automatycznie w ramach każdej migracji TYPO3: wspierany przez AI skan bazy danych, pełna konwersja i kontrola spójności jako część standardowego procesu upgrade. Skan analizuje wszystkie tabele i kolumny w mniej niż 5 minut, generuje niezbędne polecenia ALTER TABLE i wykonuje je w transakcji, dzięki czemu w razie błędu poprzedni stan może zostać przywrócony. Rezultatem jest baza danych, która konsekwentnie obsługuje utf8mb4 bez konieczności działania rozszerzenia w trybie pracy.

--- ke_search Premium TYPO3 - Wyszukiwanie | Gosign ---
> Premium wersja ke_search: Autocomplete, indeksowanie plików (PDF, DOCX), Custom Indexer.

## Wyszukiwanie enterprise bez serwera Solr jest możliwe w TYPO3 dzięki ke_search Premium

Wewnętrzna wyszukiwarka strony to funkcja używana najczęściej i najmniej pielęgnowana. Odwiedzający oczekują autocomplete, tolerancji błędów literowych i zdolności przeszukiwania nie tylko stron, ale też PDF-ów i dokumentów Office. ke_search Premium dostarcza dokładnie to dla TYPO3, bez konieczności prowadzenia zewnętrznego serwera Solr lub Elasticsearch. Wszystkie dane leżą w bazie danych TYPO3, indeks jest aktualizowany przez Scheduler, a administracja pozostaje w backendzie TYPO3.

Dla stron średniej wielkości z 500 do 5.000 podstron i garścią pobrań plików ke_search Premium to najbardziej ekonomiczne rozwiązanie wyszukiwania w ekosystemie TYPO3. Dopiero od 10.000+ zaindeksowanych dokumentów lub przy wymaganiach czasu odpowiedzi poniżej sekundy Solr staje się lepszym wyborem.

## Typowe scenariusze zastosowań sięgają od stron firmowych do portali wiedzy

Standardowy scenariusz to firmowa strona z katalogiem produktów, magazynem, FAQ i obszarem pobrań. Odwiedzający szukają nazw produktów, terminów fachowych lub dokumentów i oczekują wyników ze wszystkich obszarów w jednej liście trafień. ke_search Premium indeksuje treści stron, artykuły news, pobrania (PDF, DOCX, XLSX) i rekordy custom jak produkty czy profile pracowników. Funkcja autocomplete pokazuje sugestie już podczas pisania i redukuje współczynnik porzucenia wyszukiwania o szacunkowo 15 do 25%.

Drugi scenariusz: portale wiedzy i zbiory dokumentów. Uczelnie, stowarzyszenia i instytucje publiczne często udostępniają setki PDF-ów do pobrania: raporty badawcze, statuty, formularze, protokoły. Bez indeksowania plików wyszukiwarka TYPO3 przeszukuje tylko teksty stron, a nie zawartość PDF-ów. ke_search Premium wyciąga tekst z PDF, DOCX i innych formatów i czyni go przeszukiwalnym.

Trzeci scenariusz: Custom Indexer dla systemów zewnętrznych. Firmy z PIM, DAM lub zewnętrznym katalogiem produktów mogą przez API Custom Indexer włączyć dowolne źródła danych do indeksu wyszukiwania. Zadanie indeksera pobiera dane przez API, przekształca je w rekordy ke_search i zapisuje w indeksie. Jest to szczególnie istotne dla scenariuszy e-commerce, gdzie dane produktów nie leżą w TYPO3.

## Architektura techniczna wykorzystuje bazę danych TYPO3 jako indeks wyszukiwania

ke_search zapisuje indeks w dedykowanej tabeli (tx_kesearch_index) w bazie danych TYPO3. Każdy wpis indeksu zawiera tytuł, treść, tagi, typ i informacje sortowania. Indeksowanie działa przez zadania Scheduler, które w konfigurowalnych interwałach (typowo: nocnie) na nowo indeksują treść. Wersja Premium rozszerza bazowy indekser o indeksowanie plików, autocomplete i Custom Indexer.

Indeksowanie plików wykorzystuje Apache Tika lub pdftotext do wyciągania tekstu z PDF-ów i catdoc dla dokumentów Office. Te narzędzia muszą być zainstalowane na serwerze, co w środowiskach shared hosting może stanowić problem. Na serwerach dedykowanych i w kontenerach Docker instalacja jest trywialna.

Zapytanie wyszukiwania w frontendzie pracuje przez wyszukiwanie w bazie danych oparte na LIKE z opcjonalnym indeksem fulltext. Przy mniejszych ilościach danych wydajność jest wystarczająca, przy większych indeksach (5.000+ wpisów) zalecany jest indeks fulltext MySQL na istotnych kolumnach, aby utrzymać czas wyszukiwania poniżej 200 ms.

Autocomplete jest realizowany przez endpoint AJAX, który przy każdym naciśnięciu klawisza wykonuje wyszukiwanie PREFIX na indeksie. Wyniki są dostarczane jako JSON i wyświetlane w frontendzie przez JavaScript jako dropdown. Konfiguracja pozwala ustawić minimalną liczbę znaków (zalecane: 3) i maksymalną liczbę sugestii (zalecane: 8).

## Częste problemy dotyczą czasu indeksowania, brakującej instalacji Tika i sortowania relewancji

Problem pierwszy: długie czasy indeksowania przy dużych ilościach danych. Strona z 3.000 podstron i 500 PDF-ami może potrzebować 30 do 60 minut na pełne ponowne zaindeksowanie. Rozwiązanie: aktywować indeksowanie inkrementalne, które na nowo indeksuje tylko zmienione treści. W ke_search Premium jest to konfigurowane przez Scheduler.

Problem drugi: brakująca instalacja Tika lub pdftotext. Bez tych narzędzi indeksowanie plików cicho zawodzi, bez komunikatu o błędzie. Redaktorzy wgrywają PDF-y, które nigdy nie trafiają do indeksu wyszukiwania. Rozwiązanie: po instalacji uruchomić testowy przebieg indeksowania i sprawdzić, czy treści PDF pojawiają się w indeksie. Proste polecenie CLI sprawdza dostępność: `which pdftotext` lub `java -jar tika-app.jar --version`.

Problem trzeci: sortowanie relewancji. Standardowe sortowanie opiera się na prostym algorytmie scoringu, który waży trafienia w tytułach wyżej niż trafienia w treści. Dla złożonych wymagań (boosting według aktualności, według typu strony lub według pól custom) scoring musi być dostosowany przez TypoScript. Wersja Premium oferuje więcej parametrów scoringu niż darmowa wersja bazowa.

## TYPO3 v12 jest w pełni wspierane, kompatybilność z v13 jest w pracy

ke_search jest pielęgnowane przez dedykowany zespół programistów i jest kompatybilne z każdym wydaniem TYPO3 LTS na czas. Aktualna wersja Premium obsługuje TYPO3 v11 i v12. Dla v13 kompatybilność jest w trakcie rozwoju. Przy upgrade ze starszych wersji TYPO3 breaking changes dotyczą głównie konfiguracji TypoScript indekserów i rejestracji zadań Scheduler. Sam indeks wyszukiwania musi być kompletnie odbudowany po upgrade, co w zależności od ilości danych może trwać godzinę lub więcej.

Gosign wdraża ke_search Premium w projektach TYPO3, które potrzebują wewnętrznego wyszukiwania, ale nie uzasadniają prowadzenia serwera Solr. Dla większości stron średniej wielkości z poniżej 5.000 zaindeksowanych dokumentów ke_search Premium to najbardziej ekonomicznie sensowne rozwiązanie. Dopiero gdy dochodzą wymagania takie jak facettowanie, fuzzy matching lub czasy odpowiedzi poniżej sekundy przy dużych ilościach danych, zalecamy przejście na Apache Solr z rozszerzeniem TYPO3-Solr.

--- Kleinanzeigen TYPO3 - Ogłoszenia | Gosign ---
> Funkcjonalność ogłoszeń drobnych dla TYPO3: Zamieszczanie ogłoszeń, kategorie, wyszukiwanie, self-service użytkowników.

## Ogłoszenia drobne na własnej stronie są alternatywą dla platform marketplace

Stowarzyszenia, portale regionalne i strony społecznościowe czasem potrzebują funkcji ogłoszeń drobnych: członkowie wystawiają używane rzeczy, sąsiedzi oferują usługi, organizacje pośredniczą w darach rzeczowych. Rozszerzenie kleinanzeigen wnosi tę funkcjonalność bezpośrednio do TYPO3, bez konieczności uciekania się do platform zewnętrznych takich jak OLX czy Allegro Lokalnie. Użytkownicy tworzą ogłoszenia we frontendzie, inni użytkownicy znajdują je przez kategorie i wyszukiwarkę, a redakcja zachowuje kontrolę nad akceptacją i moderacją.

Zakres zastosowania jest wąski: kto potrzebuje pełnej platformy marketplace z funkcją płatności, systemem ocen i ochroną kupujących, będzie lepiej obsłużony wyspecjalizowanym rozwiązaniem. Dla portali społecznościowych z 50 do 500 aktywnych ogłoszeń jednocześnie rozszerzenie jest jednak solidnym narzędziem, które zatrzymuje użytkowników na własnej platformie.

## Typowe scenariusze wdrożenia to portale stowarzyszeń, platformy regionalne i wewnętrzne giełdy

Najczęstszym scenariuszem jest portal stowarzyszenia. Klub sportowy, parafia lub inicjatywa obywatelska oferuje członkom możliwość sprzedaży, oddania lub wymiany używanych rzeczy. Funkcja ogłoszeń drobnych jest elementem społecznościowym, który regularnie sprowadza odwiedzających z powrotem na stronę. Kategorie są przejrzyste: sprzęt sportowy, odzież, meble, różne.

Drugi scenariusz: platformy regionalne i portale miejskie. Strona gminy lub lokalny portal informacyjny oferuje sekcję ogłoszeń drobnych dla regionu. Mieszkańcy zamieszczają oferty mieszkań do wynajęcia, opiekunek do dzieci lub usług rzemieślniczych. Moderacja leży po stronie redakcji, która zatwierdza ogłoszenia przed publikacją.

Trzeci scenariusz: wewnętrzne giełdy w firmach lub uczelniach. W intranecie pracownicy oferują meble biurowe, rowery lub mieszkania na podnajem. Rozszerzenie kleinanzeigen działa na wewnętrznej instancji TYPO3 i jest widoczne tylko dla zalogowanych użytkowników. Uczelnie wykorzystują tę funkcję także do giełd książek, na których studenci sprzedają lub wymieniają między sobą literaturę fachową.

## Architektura techniczna opiera się na rekordach Extbase z wprowadzaniem we frontendzie

Rozszerzenie korzysta z frameworka Extbase/Fluid w TYPO3. Ogłoszenia są zapisywane jako osobne rekordy domenowe w dedykowanej tabeli. Każdy rekord zawiera tytuł, opis, cenę (opcjonalnie), kategorię, dane kontaktowe i zdjęcia. Kategoryzacja odbywa się przez sys_category TYPO3 lub własne pole kategorii.

We frontendzie dostępne są trzy pluginy: widok listy z filtrem i wyszukiwarką, widok szczegółowy pojedynczego ogłoszenia i formularz wprowadzania nowych ogłoszeń. Formularz wprowadzania wymaga zalogowania użytkownika frontendu (fe_users), dzięki czemu tylko zarejestrowani użytkownicy mogą tworzyć ogłoszenia. Zdjęcia są ładowane przez FAL (File Abstraction Layer) i walidowane po stronie serwera pod kątem rozmiaru i typu pliku.

Moderacja odbywa się przez flagę akceptacji w backendzie: nowe ogłoszenia są domyślnie niewidoczne, dopóki redaktor ich nie odblokuje. Alternatywnie można aktywować automatyczną akceptację, co może być sensowne dla zaufanych społeczności.

Wyszukiwarka działa poprzez proste zapytanie bazodanowe oparte na LIKE na tytule i opisie. Dla portali z ponad 500 aktywnymi ogłoszeniami zaleca się rozszerzenie o ke_search lub własny indeks wyszukiwania, aby poprawić wydajność i trafność wyszukiwania. Sortowanie można konfigurować według daty (najnowsze pierwsze) i ceny (rosnąco lub malejąco).

## Częste problemy to spam, optymalizacja zdjęć i zarządzanie wygasaniem

Problem pierwszy: spam w ogłoszeniach. Każdy publiczny formularz wprowadzania przyciąga spam. Bez mechanizmów ochronnych baza ogłoszeń zapełnia się nieistotnymi wpisami w ciągu kilku tygodni. Rozwiązanie: obowiązek logowania we frontendzie, pola honeypot w formularzu, opcjonalne CAPTCHA i moderacja akceptacji. Ta kombinacja redukuje spam niemal do zera.

Problem drugi: optymalizacja zdjęć. Użytkownicy wgrywają zdjęcia bezpośrednio ze smartfona, często po 4 do 8 MB na zdjęcie. Bez kompresji i dostosowania rozmiaru po stronie serwera strona staje się wolna, a miejsce na dysku szybko się kończy. Rozwiązanie: w konfiguracji rozszerzenia zdefiniować maksymalny rozmiar obrazu (zalecane: 1200 pikseli szerokości, 80% jakości JPEG) i ograniczyć upload w konfiguracji PHP do 5 MB.

Problem trzeci: zarządzanie wygasaniem. Przestarzałe ogłoszenia, które wiszą online od miesięcy, czynią całą bazę bezużyteczną. Rozwiązanie: automatyczna data wygaśnięcia (zalecane: 30 do 90 dni) i mail przypominający do twórcy przed archiwizacją ogłoszenia. Wymaga to konfiguracji zadania Scheduler.

Kolejny temat, który regularnie się pojawia: nawiązywanie kontaktu między ogłoszeniodawcą a zainteresowanym. Najprostsze rozwiązanie pokazuje adres e-mail ogłoszeniodawcy na stronie szczegółów. To działa, ale adres e-mail jest wtedy widoczny dla robotów spamowych. Lepszym rozwiązaniem jest formularz kontaktowy na stronie szczegółów, który przekazuje wiadomość do ogłoszeniodawcy bez ujawniania jego adresu e-mail.

## Rozszerzenie nie ma zagwarantowanej obsługi aktualnych wersji TYPO3

kleinanzeigen zostało opracowane dla starszych wersji TYPO3 i nie ma oficjalnego wsparcia dla v12 lub v13. Przy migracji pojawia się pytanie, czy rozszerzenie dostosować, czy zastąpić dopasowanym rozwiązaniem. Dla portali z aktywnym zasobem ogłoszeń Gosign zaleca nowe wdrożenie oparte na aktualnym API Extbase, które migruje istniejące dane i dostosowuje funkcjonalność do specyficznych wymagań portalu. Nakład pracy wynosi zwykle od 5 do 10 dni roboczych dla podstawowej funkcjonalności z widokiem listy, widokiem szczegółów, wprowadzaniem we frontendzie i moderacją.

Zaletą nowego wdrożenia w porównaniu z łataniem starego rozszerzenia jest to, że strukturę bazy danych można zoptymalizować pod faktyczne wymagania, szablony frontendu wykorzystują aktualne funkcje Fluid, a zachowanie responsywne jest uwzględnione od początku. Gosign migruje istniejące dane ogłoszeń automatycznie do nowej struktury, dzięki czemu żadne aktywne treści nie giną.

--- Mailchimp Signup TYPO3 | Gosign ---
> Formularz rejestracji Mailchimp dla TYPO3. Synchronizacja subskrybentów, Double-Opt-In, Audience-Segmenty.

## Formularze rejestracji Mailchimp w TYPO3 wymagają zabezpieczenia RODO, a nie tylko pluginu

Zapisy do newslettera należą do najważniejszych celów konwersji na firmowych stronach internetowych. koning_mailchimp_signup łączy formularze frontendowe TYPO3 bezpośrednio z API Mailchimp: odwiedzający wpisuje swój adres e-mail, rozszerzenie przekazuje go do skonfigurowanego Audience w Mailchimp, a Mailchimp wysyła mail Double-Opt-In. Technicznie działa to w 15 minut. Prawdziwe wyzwanie leży jednak nie w technice, lecz w RODO: Mailchimp przetwarza dane osobowe na serwerach w USA, co wymaga umowy powierzenia przetwarzania (DPA) i udokumentowanego mechanizmu transferu (obecnie: EU-US Data Privacy Framework).

Dla zespołów marketingowych, które już korzystają z Mailchimp jako platformy newsletterowej i chcą podłączyć swoją witrynę TYPO3, rozszerzenie jest najkrótszą drogą. Kto jednak nie wybrał jeszcze platformy, powinien rozważyć europejskie alternatywy takie jak Brevo, FreshMail, GetResponse czy mailingwork.

## Typowe scenariusze to newslettery blogów, lead magnets i rejestracje na wydarzenia

Scenariuszem standardowym jest newsletter bloga lub magazynu. Pod każdym artykułem pojawia się kompaktowy formularz rejestracji z polem e-mail i checkboxem zgody. Rozszerzenie przekazuje adres do Audience w Mailchimp i taguje subskrybenta źródłem (np. "blog-sidebar" lub "article-footer"). Marketing może dzięki temu wysyłać wiadomości segmentowo.

Drugi scenariusz: lead magnets z automatycznym pobieraniem. Odwiedzający zapisuje się i automatycznie otrzymuje whitepaper, checklistę lub kod rabatowy przez Mailchimp Welcome Automation. Rozszerzenie dostarcza subskrybenta, Mailchimp przejmuje automatyzację. Współczynnik konwersji tego wzorca na stronach B2B wynosi z doświadczenia 2 do 5 procent odwiedzających.

Trzeci scenariusz: rejestracje na wydarzenia. Firma zaprasza na webinarium lub konferencję. Zapis odbywa się przez rozszerzony formularz z imieniem, adresem e-mail i nazwą firmy. Rozszerzenie przekazuje dane do dedykowanego Audience Mailchimp, który jest skonfigurowany do komunikacji eventowej (zaproszenie, przypomnienie, follow-up). Po wydarzeniu Audience może być wykorzystywany do kampanii follow-up, co maksymalizuje wartość Customer Lifetime Value rejestracji.

## Architektura techniczna łączy formularz Fluid z API Mailchimp v3

Rozszerzenie rejestruje element treści w TYPO3, który renderuje formularz rejestracji. Formularz zawiera co najmniej pole e-mail i checkbox zgody. Opcjonalne pola takie jak imię, nazwisko i firma można aktywować w konfiguracji backendu. Szablony Fluid można nadpisać przez Site-Package.

Po wysłaniu rozszerzenie wysyła żądanie POST do API Mailchimp v3. Klucz API i ID Audience są konfigurowane w Extension Manager TYPO3. Rozszerzenie obsługuje tagi (do segmentacji), Merge Fields (dla danych niestandardowych) oraz sterowanie zachowaniem Double-Opt-In (włączone lub wyłączone, przy czym RODO w Europie wymaga Double-Opt-In).

Obsługa błędów: gdy API Mailchimp zwraca błąd (już zapisany, nieprawidłowy e-mail, limit zapytań), rozszerzenie wyświetla konfigurowalny komunikat błędu we frontendzie. Błędy są dodatkowo zapisywane do logu TYPO3, co jest istotne przy analizie problemów synchronizacji. Najczęstszym komunikatem w produkcji jest "Member Exists" (subskrybent już jest w Audience), co nie jest błędem technicznym, lecz komunikatem informacyjnym, który powinien być wyświetlony odwiedzającemu jako "Jesteś już zapisany".

## Częste problemy dotyczą dokumentacji RODO, Double-Opt-In i stylizacji formularza

Problem pierwszy: brak dokumentacji RODO. Rozszerzenie przekazuje dane osobowe do amerykańskiego dostawcy. Bez umowy powierzenia z Mailchimp (Intuit), dokumentacji mechanizmu transferu w polityce prywatności i checkboxa zgody w formularzu integracja jest niezgodna z prawem. Rozwiązanie: zawrzeć DPA z Mailchimp (dostępne w koncie Mailchimp w Account > Legal), wskazać mechanizm transferu w polityce prywatności i skonfigurować checkbox zgody jako pole wymagane.

Problem drugi: konfiguracja Double-Opt-In. Mailchimp pozwala dodawać subskrybentów bezpośrednio do listy bez maila potwierdzającego (Single-Opt-In). W Polsce, zgodnie z ustawą o świadczeniu usług drogą elektroniczną i RODO, jest to problematyczne. Rozszerzenie musi być skonfigurowane tak, aby Mailchimp wysyłał mail potwierdzający i aktywował subskrybenta dopiero po kliknięciu linku potwierdzającego.

Problem trzeci: stylizacja formularza nie pasuje do identyfikacji wizualnej. Rozszerzenie dostarcza minimalne standardowe style, które w większości projektów nie pasują do designu. Rozwiązanie: nadpisać szablon Fluid w Site-Package i dostosować klasy CSS do istniejącego systemu projektowego. Nakład pracy wynosi 1 do 2 godzin.

Czwarty problem, który pojawia się szczególnie w wielojęzycznych witrynach: teksty zgód i komunikatów o błędach w rozszerzeniu nie są prekonfigurowane dla wszystkich języków. Dla projektów TYPO3 z 5 wersjami językowymi etykiety muszą być tłumaczone ręcznie w plikach XLF lub przez nadpisania TypoScript, co przy 10 do 15 fragmentach tekstu na język jest nakładem możliwym do opanowania, ale niezaniedbywalnym.

## Rozszerzenie działa z TYPO3 v12, dla v13 stabilniejszą drogą jest bezpośrednie API Mailchimp

koning_mailchimp_signup obsługuje TYPO3 v11 i v12. Dla TYPO3 v13 dostępność zależy od opiekuna społecznościowego. Ponieważ API Mailchimp v3 jest stabilne i rzadko się zmienia, bezpośrednia integracja z API bez rozszerzenia jest alternatywą wymagającą mniejszego nakładu utrzymaniowego dla projektów v13. Gosign w nowych projektach preferuje implementację Custom Finisher dla TYPO3 Form Framework lub dla powermail, który komunikuje się bezpośrednio z API Mailchimp. Eliminuje to zależność od rozszerzenia i daje pełną kontrolę nad obsługą błędów, logowaniem i dokumentacją RODO.

Podejście Custom Finisher ma jeszcze jedną zaletę: pozwala z niewielkim nakładem przełączyć się na inną platformę newsletterową. Gdy firma zmienia Mailchimpa na Brevo, FreshMail lub mailingwork, trzeba wymienić tylko klienta API w finisherze, a nie całą konfigurację formularza. Ta elastyczność uzasadnia początkowy dodatkowy nakład 2 do 4 godzin w porównaniu z instalacją rozszerzenia.

--- kuferweb TYPO3 - Zarządzanie kursami Kufer | Gosign ---
> kuferweb: Integracja systemu zarządzania kursami Kufer z TYPO3. Katalog kursów, rejestracja, synchronizacja. Z wykorzystaniem AI.

## kuferweb to most między branżowym systemem Kufer a publiczną stroną TYPO3

Uniwersytety ludowe, instytucje edukacyjne i akademie zarządzają swoją działalnością kursową od dekad w specjalistycznym oprogramowaniu, a w wielu domach to oprogramowanie nazywa się Kufer. Kufer odwzorowuje pełny cykl życia kursu: zarządzanie wykładowcami, planowanie kursów, rezerwacja sal, uczestnicy, rozliczenia, certyfikaty. Dla strony internetowej oznacza to standardowe zadanie: katalog kursów pielęgnowany w backoffice ma być widoczny na stronie TYPO3 w trybie dziennej aktualności, wraz z wyszukiwaniem z filtrami, widokami szczegółowymi i rejestracją online.

Grupa docelowa jest wyraźnie zarysowana: instytucje dokształcania z istniejącym mandantem Kufer, które prowadzą swoją stronę na TYPO3. Typowy jest uniwersytet ludowy z około 2500 kursami na semestr i pół tuzinem wykładowców, którzy sami pielęgnują swoje kursy w Kufer. Bez porządnej integracji katalog strony pozostaje przestarzały, podwójna pielęgnacja staje się stałym stanem, a zgłoszenia lądują w oddzielnym systemie, którego nikt nie lubi.

## Typowe scenariusze zastosowania

Pierwszym scenariuszem jest automatycznie aktualizowany katalog kursów. Uniwersytet ludowy z 2500 kursami na semestr chce, żeby każde założenie kursu, każda zmiana ceny i każda zmiana wykładowcy była widoczna na stronie bez ręcznej ingerencji. Cogodzinne zadanie sync pobiera aktualne dane kursów z Kufer, zapisuje je w tabeli TYPO3 i aktualizuje wyszukiwanie. Redaktor nie pielęgnuje już kursów w backendzie TYPO3.

Drugim scenariuszem jest bezpośrednia rejestracja online. Instytucja edukacyjna z programami wsparcia chce prowadzić zainteresowanych bezpośrednio ze strony szczegółu kursu do procesu rejestracji, który w tle wywołuje API Kufer i rejestruje uczestnika w Kufer. TYPO3 służy jako frontend, Kufer pozostaje źródłem prawdy, a redakcja widzi nowy status rejestracji w swoim zwykłym interfejsie.

Trzecim scenariuszem jest wyszukiwanie z filtrami z branżowymi fasetami. Akademia z 40 dziedzinami i kilkoma tysiącami kursów chce pozwolić zainteresowanym na wyszukiwanie po kategoriach, miejscach, terminach, wykładowcach i klasach cenowych. Wyszukiwanie działa na stronie TYPO3 wobec lokalnego indeksu, który jest budowany z eksportu Kufer, wydajnie i niezależnie od dostępności aplikacji branżowej.

Czwartym scenariuszem jest wielojęzyczne wyjście kursów. Szkoła językowa z lokalizacjami w Polsce, Niemczech i Czechach pielęgnuje kursy w Kufer tylko po niemiecku i chce oferować na stronie wielojęzyczną prezentację dla zainteresowanych. Integracja przejmuje mapowanie na warianty językowe TYPO3, uzupełnia niemieckie pola Kufer o ręczne tłumaczenia w redakcji CMS i zapewnia, że zmiany w Kufer nie nadpisują lokalnych tłumaczeń.

## Architektura techniczna

Integracje kuferweb w TYPO3 są prawie zawsze rozwojem niestandardowym, bo struktury danych wariują per mandant Kufer, a wersje API zmieniały się przez lata wielokrotnie. Standardowym podejściem jest smukłe rozszerzenie Extbase z trzema filarami: warstwą usługi, która enkapsuluje API Kufer, warstwą persystencji, która odzwierciedla kursy w tabelach TYPO3, i warstwą prezentacji, która udostępnia szablony Fluid dla listy, filtra i detalu.

Synchronizacja odbywa się przez zadanie TYPO3-Scheduler. Dla dużych katalogów zaleca się import delta, który przekazuje tylko kursy zmienione od ostatniego przebiegu. API Kufer zazwyczaj dostarcza znacznik czasu lub identyfikator zmiany per kurs, który jest używany do wykrywania delty.

Rejestracja online wymaga dodatkowej ścieżki API i porządnej obsługi błędów. API Kufer może przy wysokim obciążeniu odpowiadać wolno, dlatego rejestracje typowo działają asynchronicznie: formularz kładzie żądanie rejestracji w kolejce, proces worker przekazuje je do Kufer, a uczestnik otrzymuje mail potwierdzający, gdy tylko Kufer pokwituje rejestrację.

## Częste problemy i rozwiązania

Pierwszym problemem jest rozbieżność pól między mandantami Kufer. Co w mandancie A nazywa się "Numer wydarzenia", w mandancie B jest "Kodem kursu", a w mandancie C "Numerem rezerwacji". Rozwiązaniem jest konfigurowalne mapowanie pól w rozszerzeniu TYPO3, które jest dostosowywane per instalację i nie stoi twardo w kodzie.

Drugim problemem jest jakość danych w katalogu kursów. Redaktorki nie zawsze pielęgnują w Kufer pełne teksty, brakują krótkie opisy, obrazy nie są dołączone, grupy docelowe nie są zdefiniowane. Na stronie te luki pojawiają się jako puste pola. Rozwiązaniem jest warstwa walidacji przy synchronizacji, która oznacza niekompletne kursy w backendzie i wzywa redakcję do uzupełnienia.

Trzecim problemem jest logika anulowania i odwołań. Gdy kursy są anulowane w Kufer, mają zniknąć ze strony lub przynajmniej być oznaczone jako odwołane. Rozwiązaniem jest, aby anulowane kursy w sync wyraźnie ustawiać na status, który jest ukrywany na liście, i zaopatrywać stronę szczegółu w redirect do widoku kategorii.

Czwartym problemem jest wyświetlanie obłożenia w czasie rzeczywistym. Zainteresowani widzą na stronie "jeszcze 3 wolne miejsca", mimo że rezerwacja w tle już przeszła na listę oczekujących. Rozwiązaniem jest, żeby wyświetlanie obłożenia nie czytać z cache sync, lecz przy każdym wywołaniu strony szczegółu wysłać mały live-call do Kufer, z agresywnym cache'owaniem (30-60 sekund) i fallbackiem na ostatnią znaną wartość cache, jeśli API nie odpowiada.

## Migracja i kompatybilność wersji

Integracje kuferweb działają w TYPO3 v11, v12 i v13, o ile podłączenie API jest nowocześnie zbudowane. Najczęstszym punktem bólu nie jest wersja TYPO3, tylko wersja Kufer: gdy uniwersytet ludowy migruje swój mandant Kufer na nową wersję, okazjonalnie zmieniają się endpointy API i struktury danych, co wymaga justowania integracji TYPO3.

Gosign buduje integracje kuferweb na bazie aktualnego API Kufer, sprawdza przed rozpoczęciem projektu kompatybilność z mandantem klienta i ustawia integrację tak modułowo, żeby przyszłe upgrade API działały bez wielkoobszarowej przebudowy. Wspierane przez AI powstaje kod klienta API w godzinach zamiast dni, dzięki czemu wprowadzenie na większości projektów staje się realistyczne w dwóch do trzech sprintach.

--- LayerSlider TYPO3 - Migracja slidera | Gosign ---
> Premium plugin slider/animacji dla TYPO3. Krytyczny dla wydajności: duże bundli JS, wiele żądań HTTP.

## LayerSlider ładuje 400 KB JavaScript dla czegoś, co da się rozwiązać 20 KB CSS

LayerSlider był między 2012 a 2018 jednym z najpopularniejszych premium sliderów dla TYPO3 i WordPress. Animowane banery z efektami paralaksy, wstawianiem tekstu, przejściami i tłem wideo. Wynik wyglądał na stronie głównej imponująco. Problem: LayerSlider ładuje bibliotekę JavaScript o rozmiarze 300 do 400 KB (zminimalizowana), wymaga jQuery jako zależności (kolejne 90 KB) i generuje od 15 do 30 żądań HTTP dla obrazów, fontów i plików konfiguracyjnych. Na zoptymalizowanej stronie LayerSlider podwaja czas ładowania strony głównej.

Google PageSpeed Insights karze to bezlitośnie. Largest Contentful Paint (LCP) powyżej 4 sekund spowodowany samym sliderem oznacza utratę 20 do 40 punktów score. Odkąd Google używa Core Web Vitals jako czynnika rankingowego (2021), słabe LCP to mierzalna wada SEO.

## Typowe scenariusze zastosowań

**Istniejące strony z animowanymi banerami hero.** Strony firmowe z lat 2014 do 2019, na których slider strony głównej pokazuje 3 do 5 animowanych slajdów. Typowa treść: zdjęcia produktów z animowanym tekstem overlay ("Odkryj teraz"), efekty przewijania paralaksy, autoplay z przejściem fade. Slider został skonfigurowany raz i od tego czasu prawie nie zmieniany, ale przy każdym wywołaniu strony generuje pełny overhead wydajnościowy.

**Landing page z prezentacjami produktów.** Zespoły marketingowe używają LayerSlider do prezentacji produktów: wiele obrazów z tekstem overlay i przyciskami CTA w automatycznie przesuwanej prezentacji. Dane konwersji typowo pokazują, że 80% użytkowników widzi tylko pierwszy slajd. Slider to więc kosztowna prezentacja dla jednego obrazu.

**Strony eventowe z animacjami odliczania.** LayerSlider może wyświetlać timery, popupy i animacje wyzwalane przez scroll. Dziś istnieją do tego lekkie rozwiązania CSS bez overhead JavaScript.

## Architektura techniczna

LayerSlider to komercyjny plugin (licencja ok. 25 USD jednorazowo dla WordPress, wariant TYPO3 przez CodeCanyon lub dostawców trzecich). Integracja TYPO3 działa jako rozszerzenie z własną tabelą dla konfiguracji sliderów. Każdy slider składa się ze slajdów, każdy slajd z warstw (tekst, obraz, wideo, kształt, przycisk), a każda warstwa ma ustawienia animacji.

Wyjście frontendowe ładuje bibliotekę rdzeniową LayerSlider (kreaturamedia.js), jQuery (jeśli nie jest dostępne globalnie), opcjonalne pluginy (Parallax, Popup, Timeline) i konfigurację slidera jako JSON. Silnik animacji korzysta z RequestAnimationFrame i CSS3-Transforms. Na nowoczesnych przeglądarkach prezentacja jest płynna, ale czas parsowania dużego bundla JavaScript pozostaje. Na urządzeniach mobilnych (smartfony średniej klasy) samo parsowanie trwa 200 do 500 ms.

## Częste problemy i rozwiązania

**Core Web Vitals spadają po wbudowaniu slidera.** LCP rośnie z 1,5 do ponad 4 sekund, bo slider jest największym widocznym elementem i może renderować dopiero po sparsowaniu JavaScript. Rozwiązanie: zastąpienie LayerSlider statycznym hero z animacją CSS. Obraz hero ładuje się jako normalny tag img (od razu w HTML, bez JavaScript), tekst overlay jest pozycjonowany przez CSS. Wynik: LCP poniżej 2 sekund.

**Licencja LayerSlider wygasa, brak aktualizacji.** Wariant TYPO3 LayerSlider nie jest dystrybuowany przez TER i nie ma automatycznego mechanizmu aktualizacji. Poprawki bezpieczeństwa muszą być instalowane ręcznie. LayerSlider miał w przeszłości krytyczne luki bezpieczeństwa. Rozwiązanie: nie łatać, lecz migrować.

**Treści slidera nie są indeksowalne.** Tekst w warstwach LayerSlider jest wstawiany jako atrybut data lub przez JavaScript. Google może odczytać tekst (renderowanie JavaScript), ale przypisanie do kontekstu strony jest słabe. Rozwiązanie: umieszczenie istotnego tekstu i CTA bezpośrednio w HTML strony, nie w sliderze.

## Migracja i kompatybilność wersji

LayerSlider nie ma oficjalnej kompatybilności z TYPO3 v12 ani v13. Ostatnia kompatybilna wersja TYPO3 wspiera v10, z poprawkami społecznościowymi częściowo v11. Dla v12+ nie ma ścieżki aktualizacji. Dla wielu projektów to jest impuls do ostatecznego zastąpienia slidera.

Gosign migruje LayerSlider na jedną z trzech alternatyw, w zależności od wymagań. Swiper (open source, 40 KB zminimalizowany, bez jQuery, natywny dotyk) do sliderów obrazów z prostymi przejściami. Splide (open source, 30 KB zminimalizowany, bez jQuery, pełne wsparcie ARIA) do dostępnych sliderów. Lub czysty CSS/HTML hero bez biblioteki slidera, gdy potrzebny jest tylko jeden obraz z tekstem overlay.

Mierzalny efekt migracji slidera: strona przełączona z LayerSlider na statyczny hero z animacją CSS poprawia swój Google PageSpeed Score typowo o 15 do 35 punktów. LCP spada z 3 do 5 sekund na poniżej 2 sekund. Total Blocking Time (TBT) maleje o 200 do 500 ms, bo duży bundle JavaScript odpada.

--- Leaflet TYPO3 - Mapy OpenStreetMap | Gosign ---
> Mapy Leaflet w TYPO3: OpenStreetMap bez kosztów Google. Wyszukiwarka lokalizacji, clustering, routing. Z wykorzystaniem AI.

## Mapy OpenStreetMap przez Leaflet zastępują Google Maps bez kosztów licencji i ryzyka RODO

Google Maps od 28 000 wyświetleń mapy miesięcznie kosztuje pieniądze i przesyła dane użytkowników na serwery w USA. Dla firm ze wyszukiwarką oddziałów, Store Locatorem lub mapą lokalizacji na stronie to dwa problemy naraz: budżet i ochrona danych. Leaflet rozwiązuje oba. Otwartoźródłowa biblioteka JavaScript renderuje interaktywne mapy oparte na danych OpenStreetMap, działa w całości po stronie klienta i nie ma kosztów licencji. Rozszerzenie TYPO3 integruje Leaflet jako element treści: redaktorzy zarządzają lokalizacjami w backendzie, rozszerzenie generuje mapę we frontendzie.

Dla firm z 5 do 500 lokalizacjami Leaflet jest standardową rekomendacją. Dopiero gdy potrzebne są funkcje specyficzne dla Google, takie jak Street View, budynki 3D lub dane o ruchu drogowym na żywo, Google Maps jest lepszym wyborem. We wszystkich pozostałych przypadkach Leaflet dostarcza tę samą funkcjonalność przy zerowych kosztach licencji i bez dyskusji o ochronie danych.

## Typowe scenariusze to wyszukiwarki oddziałów, mapy nieruchomości i lokalizacje wydarzeń

Najczęstszym scenariuszem jest wyszukiwarka oddziałów lub lokalizacji. Firma z 20 do 200 oddziałami pokazuje wszystkie lokalizacje na interaktywnej mapie. Użytkownicy mogą przybliżać, szukać po kodzie pocztowym i klikać markery, aby zobaczyć adres, godziny otwarcia i dane kontaktowe. Przy gęstym rozmieszczeniu markerów clustering grupuje pobliskie lokalizacje w marker zbiorczy, który przy przybliżaniu rozkłada się na pojedyncze markery. Typowa wyszukiwarka oddziałów ze 100 lokalizacjami i clusteringiem ładuje się w czasie poniżej 500 ms.

Drugi scenariusz: mapy nieruchomości i obiektów. Pośrednicy, zarządcy nieruchomości i spółki mieszkaniowe pokazują dostępne obiekty na mapie. Markery zawierają podstawowe informacje (cena, liczba pokoi, powierzchnia) jako popup i linkują do strony szczegółów. Rozszerzenie TYPO3 może renderować rekordy obiektów z tabeli Extbase jako markery.

Trzeci scenariusz: lokalizacje wydarzeń i turystyka. Organizatorzy, organizacje turystyczne i miasta pokazują POI (Points of Interest), trasy i miejsca wydarzeń na mapie. Leaflet obsługuje oprócz markerów punktowych także linie (dla szlaków turystycznych) i wielokąty (dla obszarów), co czyni go elastycznym narzędziem dla zastosowań turystycznych.

## Architektura techniczna czysto oddziela backend danych od renderowania mapy

Rozszerzenie TYPO3 przechowuje dane lokalizacji jako rekordy Extbase w dedykowanej tabeli. Każdy rekord zawiera nazwę, adres, współrzędne (szerokość/długość geograficzna), opis i opcjonalne pola takie jak godziny otwarcia, numer telefonu i zdjęcie. Współrzędne można wprowadzać ręcznie lub automatycznie określać z adresu przez usługę geocodingu.

We frontendzie rozszerzenie renderuje kontener mapy i inicjalizuje Leaflet przez JavaScript. Kafelki mapy są ładowane z konfigurowalnego serwera kafelków. Standardem jest OpenStreetMap, ale także Mapbox, Stamen i inni dostawcy kafelków są przełączalni przez TypoScript. Markery są przekazywane do JavaScriptu jako tablica JSON, co pozostaje wydajne także przy 500 i więcej lokalizacjach.

Clustering realizowany jest przez plugin Leaflet.markercluster, który łączy markery przy niskim poziomie zoomu i rozdziela je przy przybliżaniu. Progi clusteringu są konfigurowalne. Wyszukiwanie po kodzie pocztowym lub miejscowości odbywa się po stronie klienta, co działa do 1000 markerów bez wsparcia serwerowego.

Style map można w pełni dostosować: kolory, kroje pisma, szerokości ulic i szczegóły mapy można kontrolować przez konfigurację Tile-Layer i niestandardowy CSS. W porównaniu z Google Maps, którego stylizacja jest ograniczona, Leaflet daje pełną kontrolę nad wyglądem.

## Częste problemy dotyczą geocodingu, dostępności serwera kafelków i widoku responsywnego

Problem pierwszy: błędy geocodingu przy nieprecyzyjnych adresach. Nie każdy adres jest poprawnie rozpoznawany przez usługę geocodingu. Szczególnie tereny przemysłowe, nowe osiedla i adresy na obszarach wiejskich dostarczają nieprecyzyjne lub błędne współrzędne. Rozwiązanie: używać automatycznego geocodingu jako pierwszego wypełnienia i sprawdzać współrzędne ręcznie. Rozszerzenie powinno pokazywać okno mapy w backendzie, przez które redaktor może poprawić marker metodą drag-and-drop.

Problem drugi: dostępność serwera kafelków. Standardowy serwer kafelków OpenStreetMap ma politykę Fair Use i przy dużym ruchu może zastosować ograniczanie zapytań (rate limiting). Dla witryn produkcyjnych z ponad 50 000 wyświetleń mapy miesięcznie zaleca się własny serwer kafelków lub komercyjnego dostawcę takiego jak Mapbox czy Maptiler. Koszty wynoszą od 5 do 50 euro miesięcznie, wciąż znacznie poniżej Google Maps.

Problem trzeci: widok responsywny na urządzeniach mobilnych. Mapy na małych ekranach są trudne w obsłudze, ponieważ przybliżanie koliduje z przewijaniem strony. Rozwiązanie: ograniczyć gesty dotykowe na mapie do dwóch palców (wyłączyć scrollWheelZoom i dragging na urządzeniach mobilnych) i udostępnić przycisk "powiększ mapę", który otwiera mapę w trybie pełnoekranowym.

## Leaflet jest przyszłościowy, rozszerzenie TYPO3 trzeba sprawdzić przy v13

Leaflet jako biblioteka JavaScript jest niezależny od wersji TYPO3 i jest aktywnie rozwijany. Rozszerzenie TYPO3, które obejmuje integrację backendową i renderowanie, trzeba sprawdzić przy aktualizacji do v12 lub v13. Zmiany API Extbase w v12 dotyczą klas repozytoriów i konfiguracji persystencji. W Gosign integracje Leaflet migrujemy zwykle przez plugin własny we własnym sitepackage, który bezpośrednio wczytuje bibliotekę Leaflet i pobiera dane lokalizacji z tabeli Extbase lub endpointu JSON. Eliminuje to zależność od rozszerzenia i daje pełną kontrolę nad aktualizacjami. Sama biblioteka Leaflet jest wczytywana przez npm lub CDN i z rozmiarem 39 KB (skompresowane) jest znacznie lżejsza niż Google Maps JavaScript API (ponad 185 KB), co pozytywnie wpływa na czas ładowania stron z mapami.

--- LimeSurvey TYPO3 - Integracja ankiet | Gosign ---
> LimeSurvey w TYPO3: Osadzanie ankiet, SSO, dashboard wyników. Integracja z wykorzystaniem AI.

## LimeSurvey to zgodna z RODO odpowiedź na ankiety enterprise, które nie mogą kończyć w Google Forms

Kto w Polsce przeprowadza profesjonalne ankiety (badania pracownicze, badania rynku, badania ewaluacyjne, naukowe zbieranie danych) i potrzebuje przy tym zgodności z RODO, pełnej suwerenności danych i porządnego śladu audytowego, niemal z konieczności trafia na LimeSurvey. Oprogramowanie open source działa na własnym serwerze, przechowuje dane odpowiedzi wyłącznie we własnej bazie danych i oferuje wszystkie typy pytań, których wymaga poważne badanie. Dla operatorów TYPO3 nie stoi pytanie, czy używają LimeSurvey, tylko jak integrują go ze swoją istniejącą stroną.

Grupą docelową są zazwyczaj uczelnie, instytucje badawcze, administracje publiczne, szpitale, koncerny z mandatem rady pracowniczej i NGO z wrażliwymi badaniami grup docelowych. Przykład: Uniwersytet Warszawski z 18 000 studentów przeprowadza co semestr ewaluację nauczania i chce odtworzyć wyniki na własnej stronie TYPO3, bez konieczności przełączania się przez studentów między dwoma systemami.

## Typowe scenariusze zastosowania

Pierwszym scenariuszem jest płynne uczestnictwo w ankiecie na stronie TYPO3. Zamiast wysyłać studentów na oddzielną domenę LimeSurvey, kwestionariusz jest pokazywany bezpośrednio na stronie witryny. Odpowiedzi przepływają przez API do LimeSurvey, a studenci widzą znajomą nawigację strony. To znacząco obniża współczynnik porzuceń.

Drugim scenariuszem jest identyfikacja uczestników oparta na SSO. Sieć szpitali z 8000 pracownikami przeprowadza badanie pracownicze. Uczestnicy logują się w intranecie TYPO3, klikają link ankietowy i lądują w LimeSurvey bez konieczności ponownego logowania. SSO-Bridge gwarantuje, że każdy pracownik bierze udział tylko raz i że dane osobowe z TYPO3 nie przepływają do odpowiedzi ankiety.

Trzecim scenariuszem jest prezentacja wyników bezpośrednio na stronie. Administracja gminna przeprowadza ankietę wśród mieszkańców na temat inwestycji budowlanej i chce pokazywać codzienne stany pośrednie jako wykres słupkowy na stronie projektu. Zadanie sync pobiera anonimowe agregaty przez API i renderuje je w elemencie treści TYPO3, bez konieczności dotykania przez surowe dane instalacji TYPO3.

Czwartym scenariuszem jest studium longitudinalne w badaniach naukowych. Projekt badawczy dotyczący obciążenia pracą w sektorze opiekuńczym bada tę samą kohortę cztery razy rocznie przez dwa lata. Strona TYPO3 służy jako punkt informacji i wejścia, LimeSurvey trzyma badania, a integracja dba o to, żeby każdy uczestnik przez spersonalizowany link docierał do swoich kolejnych ankiet, bez konieczności pielęgnowania danych kontaktowych w LimeSurvey przez badaczy.

## Architektura techniczna

LimeSurvey udostępnia dwa dostępy API: klasyczny interfejs RemoteControl2 na bazie JSON-RPC i nowsze REST-API w aktualnych wersjach. Dla integracji TYPO3 RemoteControl2 pozostaje kotwicą stabilności, bo jest dostępne w starszych instalacjach LimeSurvey i pokrywa pełne uwierzytelnianie, zarządzanie uczestnikami i zapytania o odpowiedzi.

Integracja TYPO3 działa z reguły jako własne rozszerzenie. Warstwa usługi enkapsuluje wywołania API, plugin dostarcza elementy treści dla osadzania ankiet, a middleware implementuje logikę SSO. Dla osadzania istnieją dwa warianty: ankieta jest wywoływana przez podpisany token i osadzana przez iFrame, lub pytania są czytane przez API i bezpośrednio renderowane jako szablon Fluid. To drugie oferuje najlepsze doświadczenie użytkownika, ale wymaga większego nakładu rozwoju.

SSO-Bridge opiera się na podpisanym tokenie, który TYPO3 generuje, a LimeSurvey waliduje. W LimeSurvey konfigurowany jest do tego plugin, który odczytuje token z URL i zakłada uczestnika jako anonimowy token w tabeli uczestników ankiety. Ważne, żeby token był ograniczony czasowo i ważny tylko jednorazowo per uczestnik.

## Częste problemy i rozwiązania

Pierwszym problemem jest obsługa sesji między TYPO3 a LimeSurvey. Oba systemy mają własne sesje, a gdy wybrane jest podejście iFrame, powstają problemy z cookies third-party w nowoczesnych przeglądarkach. Rozwiązaniem jest prowadzenie LimeSurvey pod subdomeną instalacji TYPO3, żeby cookies były akceptowane jako first-party, lub użycie wariantu API z serwerowym renderowaniem.

Drugim problemem jest kryzys wydajności przy prezentacji wyników. Kto przy każdym wywołaniu strony pyta API o agregaty, niepotrzebnie obciąża serwer LimeSurvey. Rozwiązaniem jest zadanie sync, które w regularnych interwałach (np. cogodzinnych) zapisuje agregaty w tabeli TYPO3, a element treści renderuje z tej tabeli cache.

Trzecim problemem jest zgodne z RODO obchodzenie się z danymi osobowymi. Przy ankietach pracowniczych pracodawca z reguły nie może rozpoznać, kto udzielił jakiej odpowiedzi. Rozwiązaniem jest porządna koncepcja rozdzielenia: TYPO3 udostępnia tylko anonimowe tokeny, LimeSurvey zapisuje odpowiedzi bez odniesienia zwrotnego, a agregacja odbywa się wyłącznie przez wskaźniki, które nie pozwalają na wnioskowanie o pojedynczych osobach.

Czwartym problemem są słabości wyświetlania mobilnego w trybie iFrame. Ankiety LimeSurvey są wprawdzie responsywne, ale w iFrame TYPO3 dochodzi do podwójnych pasków przewijania i ucinanych przycisków na małych ekranach. Rozwiązaniem jest, aby dla użycia mobilnego przechodzić na serwerowe renderowanie lub dynamicznie dostosowywać iFrame do treści, żeby kontener layoutu strony przejmował pełną wysokość.

## Migracja i kompatybilność wersji

Integracje LimeSurvey działają na TYPO3 v11, v12 i v13. Większym wyzwaniem jest strona LimeSurvey: między LimeSurvey 3.x, 5.x i 6.x zmieniły się szczegóły API i procedury uwierzytelniania. Kto podnosi istniejącą integrację na nową wersję LimeSurvey, powinien weryfikować wywołania API wobec odpowiedniej dokumentacji wersji i najlepiej uruchamiać zautomatyzowany test integracyjny wobec instancji staging LimeSurvey.

Gosign wdraża integracje LimeSurvey dla uczelni, szpitali i instytucji publicznych. Klient API powstaje ze wsparciem AI z dokumentacji RemoteControl2, SSO-Bridge jest indywidualnie dopasowywana do istniejącego zarządzania tożsamością, a wdrożenie odbywa się wzdłuż jasnej dokumentacji RODO, która zdejmuje pracę z inspektora ochrony danych.

--- linkhandler TYPO3 - Custom Record Links | Gosign ---
> linkhandler: Custom Record Links w TYPO3 RTE. Bezpośrednie linkowanie do News, Events, produktów. Konfiguracja i migracja.

## linkhandler zapobiega martwym linkom, gdy URL-e się zmieniają

W TYPO3 typolink odnosi się bezpośrednio do strony, pliku lub URL, a nie do rekordu. Gdy redakcja chce w tekście głównym linkować do wydarzeń, artykułów news, produktów lub adresów, musi albo wpisać URL na sztywno, albo włączyć między siebie rozszerzenie, które z ID rekordu generuje stabilny URL. Dokładnie to jest zadaniem linkhandler. Rozszerzenie od Cobwebsters rejestruje nowe typy linków w TYPO3-RTE i w Link-Browser i łączy je z dowolnymi tabelami bazy danych. Przy projekcie redakcyjnym z ponad setką wewnętrznych odsyłaczy to różnica między działającą architekturą contentu a cmentarzem pełnym linków 404.

## Typowe scenariusze zastosowania występują w każdej redakcji z więcej niż jedną domeną treści

Gdy news, wydarzenia i produkty istnieją w tym samym projekcie, redaktorzy potrzebują porządnego systemu linkowania. Uczelnia w artykule magazynowym linkuje do wydarzenia w sf_event_mgt, w tekście wydarzenia do zaangażowanego autora z md_news_author, a w profilu autora z powrotem do wszystkich jego wpisów w GeorgRinger/news. Trzy rozszerzenia, trzy typy rekordów, i bez linkhandler każdy z tych odsyłaczy byłby twardym URL-em, który łamie się przy następnym refactoringu slugów. W codzienności oznacza to: jedno refactoring URL może wtedy wygenerować dziesiątki lub setki zepsutych linków, które dopiero kilka tygodni później pojawiają się w raporcie Google Search Console.

Drugim scenariuszem są teksty e-commerce: opisy produktów, które odnoszą się do akcesoriów, lub artykuły bloga, które linkują do produktów z aimeos. linkhandler automatycznie generuje URL-e z konfiguracji routingu produktów, a przy refactoringu kategorii wszystkie linki wędrują razem.

Po trzecie, potrzeba pojawia się przy listach lokalizacji. Kto pielęgnuje strukturę oddziałów lub katalogi osób kontaktowych z tt_address lub własnym modelem, chce z artykułów linkować do danej strony detalu. Link linkhandler pozostaje stabilny, nawet gdy lokalizacja zostanie przemianowana.

## Architektura techniczna rejestruje typy linków przez YAML i klasę handlera

linkhandler wykorzystuje mechanizm TYPO3-LinkHandler z core, który jest dostępny od v8. Każdy typ linku jest rejestrowany przez plik YAML w katalogu Config. YAML definiuje identyfikator handlera, tabelę, model Extbase i konfigurację routingu. W RTE i w Link-Browser typ linku pojawia się jako nowa zakładka: "News", "Event", "Produkt", "Adres". Każda zakładka pokazuje listę dostępnych rekordów z funkcją wyszukiwania i filtrowania, dzięki czemu redaktorzy nawet przy tysiącach wpisów news mogą celowo znaleźć pożądany wpis.

Właściwy resolver to klasa PHP, która dziedziczy po AbstractLinkHandler i implementuje metody modifyLinkField i generateRelativeUrl. Metody tworzą z ID rekordu znaczący URL przez Site-Config i router danego rozszerzenia. We frontend typolink jest wywoływany z parametrem t3://record i rozwiązywany przez renderowanie strony do finalnego URL. Oznacza to: nawet jeśli dziesiątki tysięcy artykułów linkują do tego samego rekordu news, przy zmianie slugu musi być zaktualizowany tylko sam rekord artykułu, a wszystkie linki automatycznie rozwiążą się na nowy URL.

Konfiguracja sięga głęboko w system linkowania TYPO3, ale pozostaje deklaratywna: po rejestracji YAML i wyczyszczeniu cache nowy typ linku jest dostępny w całym projekcie, włącznie z szablonami Fluid i komponentami menu. Kto nie używa linkhandler wyraźnie, otrzymuje mechanizm również przez TYPO3-Core-Linking, ale bez warstwy abstrakcji YAML i komfortowego backendowego UI pickera z rozszerzenia.

## Częste problemy dotyczą cache, wariantów językowych i handlera plików

Najczęstszym tematem wsparcia są niespójności cache po aktualizacji rekordu. Gdy slug artykułu news zostaje dostosowany, musi zostać wyczyszczony również page-cache artykułu źródłowego, w którym znajduje się link linkhandler, inaczej stary URL pozostaje w wyjściu. Rozwiązaniem jest cache-tag, który jest ustawiany przy renderowaniu typolinku. Wiele instalacji tego nie aktywuje i walczy potem z pozornie uszkodzonymi linkami.

Drugim problemem są warianty językowe. Artykuł news w PL odwołuje się przez linkhandler do wydarzenia. Angielskie tłumaczenie artykułu ma odwoływać się do tego samego ID wydarzenia, ale generować URL w języku angielskim. linkhandler oferuje to rozwiązywanie przez Language-Aspect, ale konfiguracja YAML musi wyraźnie wskazywać na warianty routingu stron docelowych. Kto używa języków zapasowych, musi dodatkowo sprawdzić, jak handler zachowuje się przy brakujących tłumaczeniach, powinien rozwiązywać w języku zapasowym, nie wracać do języka głównego.

Po trzecie, handler plików jest przypadkiem szczególnym. Kto obok linków rekordów chce również linkować do plików TYPO3-FAL, musi oddzielnie skonfigurować handler plików linkhandler lub sięgnąć do natywnego TYPO3-File-Linkera. Kombinacja jest możliwa, ale kolejność handlerów w YAML decyduje, która zakładka pojawi się jako pierwsza.

## TYPO3 v12 i v13 używają core LinkHandler, migracja się opłaca

Od TYPO3 v11 core LinkHandler jest gotowy do produkcji i może przejmować wiele zadań linkhandler sam. Mimo to rozszerzenie Cobwebsters jest nadal utrzymywane, bo przynosi dodatkowe funkcje komfortu jak edytor YAML, ulepszony record-picker i przyjazne schema wyjście. Dla TYPO3 v12 i v13 istnieje aktualna wersja w TER i na Packagist.

Przy przeglądzie migracji Gosign sprawdza, ile wywołań linkhandler znajduje się w treściach RTE. Przy mniej niż 50 wystąpieniach opłaca się często przejście na core-LinkHandler, przy więcej niż 100 wystąpieniach lub silnie zindywidualizowanych handlerach linkhandler pozostaje bardziej pragmatycznym wyborem. Migracja na nową wersję major przebiega z reguły bez zmian treści, bo składnia t3://record w contencie pozostaje stabilna. Do analizy używamy skanu przez pola tt_content, który rozkłada wszystkie typy linków i generuje rekomendację per instalację.

--- Liveticker TYPO3 - Aktualizacje w czasie rzeczywistym | Gosign ---
> Live-Ticker dla wydarzeń w czasie rzeczywistym: sport, wybory, konferencje. Oparty na WebSocket lub Polling, z automatycznym doładowywaniem nowych wpisów.

## Aktualizacje na żywo na stronach TYPO3 wymagają więcej niż pluginu News z auto-refresh

Kluby sportowe, portale informacyjne, gminy przy wynikach wyborów i organizatorzy konferencji potrzebują funkcji, której w rdzeniu TYPO3 po prostu nie ma: chronologicznych, krótkich komunikatów, które pojawiają się na stronie w czasie rzeczywistym, bez konieczności przeładowywania strony przez odwiedzającego. Rozszerzenie liveticker rozwiązuje to pluginem frontendowym, który automatycznie doładowuje nowe wpisy przez AJAX-polling lub WebSocket i wstawia je na górę osi czasu. Redaktorzy wpisują komunikat w backendzie, klikają "zapisz" i komunikat pojawia się na stronie kilka sekund później.

Dla organizacji, które dwa lub trzy razy w roku towarzyszą wydarzeniom na żywo na swojej stronie, rozszerzenie jest pragmatycznym rozwiązaniem. Kto relacjonuje codziennie, powinien rozważyć wyspecjalizowane platformy takie jak Tickaroo, które lepiej pokrywają treści multimedialne, integrację z social media i przepływy pracy wielu autorów.

## Typowe scenariusze wdrożenia to wydarzenia sportowe, wybory samorządowe i konferencje

Najczęstszym scenariuszem jest liveticker sportowy. Amatorski klub sportowy towarzyszy meczom domowym tickerem na stronie klubu. Redaktor przy boisku wpisuje bramki, kartki i zmiany w backendzie TYPO3 (najlepiej przez mobilny backend), a wpisy pojawiają się chronologicznie na stronie. Przy meczu IV-ligowym z 500 do 2000 jednoczesnych odwiedzających ticker musi działać stabilnie, nie obciążając serwera.

Drugi scenariusz: wieczory wyborcze w gminach i powiatach. W niedzielę wyborczą gminy publikują wyniki cząstkowe przez liveticker. Komunikaty zawierają udziały głosów, prognozy i komentarze komisarza wyborczego. Wyzwanie: wszyscy odwiedzający oczekują tego samego wyniku jednocześnie, co generuje szczytowy ruch.

Trzeci scenariusz: konferencje i walne zgromadzenia. Stowarzyszenia i związki relacjonują na żywo walne zgromadzenia, aby członkowie, którzy nie są na miejscu, mogli śledzić przebieg. Wpisy zawierają wyniki głosowań, wystąpienia i uchwały. Dla stowarzyszeń zawodowych z 5000 do 50 000 członkami, z których nie wszyscy mogą uczestniczyć w zgromadzeniu stacjonarnym, liveticker jest najprostszą formą cyfrowego uczestnictwa, która nie wymaga infrastruktury do transmisji wideo.

## Architektura techniczna opiera się na rekordach TYPO3 z AJAX-pollingiem we frontendzie

Rozszerzenie przechowuje wpisy tickera jako rekordy TYPO3 w dedykowanej tabeli. Każdy wpis zawiera znacznik czasu, tekst, opcjonalny obraz i kategoryzację (np. "gol", "żółta kartka", "wynik"). Rekordy należą do kontenera tickera, który jest przypisany do wydarzenia. Redaktor może prowadzić kilka tickerów równolegle, na przykład dla różnych meczów lub wydarzeń w tym samym dniu.

We frontendzie plugin renderuje istniejące wpisy jako chronologiczną listę (najnowsze na górze) i uruchamia JavaScript timer, który w konfigurowalnych odstępach (zwykle: 10 do 30 sekund) wysyła żądanie AJAX do endpointu TYPO3. Endpoint zwraca wszystkie wpisy, które dodano od ostatniego pobrania. JavaScript wstawia te wpisy z animacją na górę listy.

Zaawansowane implementacje wykorzystują WebSockets zamiast pollingu, co redukuje opóźnienie z 10 do 30 sekund do poniżej 1 sekundy. Wymaga to jednak serwera WebSocket (np. Node.js z Socket.io) działającego równolegle do serwera WWW TYPO3. Dla większości stron klubów i gmin to przesada, a AJAX-polling z interwałem 15-sekundowym dostarcza wystarczająco zbliżone do czasu rzeczywistego doświadczenie. Rozwiązaniem pośrednim są Server-Sent Events (SSE), które używają trwałego połączenia HTTP i są prostsze w implementacji niż WebSockets, ale również wymagają wsparcia po stronie serwera.

## Częste problemy to obciążenie serwera przy ruchu szczytowym, brak wprowadzania mobilnego i konflikty z cache

Problem pierwszy: obciążenie serwera przy ruchu szczytowym. Gdy 2000 odwiedzających co 15 sekund wysyła żądanie AJAX, daje to 8000 żądań na minutę. Bez strategii cache zwykły serwer na shared hostingu się załamuje. Rozwiązanie: umieścić reverse proxy (np. Varnish lub Cloudflare) przed endpointem AJAX, który cache'uje odpowiedź na 5 sekund. Redukuje to faktyczne odwołania do serwera aplikacji do 12 na minutę zamiast 8000.

Problem drugi: wprowadzanie mobilne dla redaktorów. Backend TYPO3 na urządzeniach mobilnych jest użyteczny tylko w ograniczonym zakresie. Redaktor przy boisku, który w deszczu stuka na smartfonie, potrzebuje uproszczonej maski wprowadzania. Rozwiązanie: własny endpoint ze zredukowanym formularzem (pole tekstowe, dropdown kategorii, przycisk wyślij), zoptymalizowany dla przeglądarek mobilnych.

Problem trzeci: konflikty z cache stron TYPO3. Gdy strona, na której osadzony jest ticker, jest serwowana z cache TYPO3, odwiedzający widzą przestarzałe wpisy. Rozwiązanie: wyłączyć stronę tickera z page cache (USER_INT) lub lepiej: cache'ować stronę i doładowywać tylko obszar tickera przez AJAX, co umożliwia kombinację stron z cache i treści dynamicznej.

## Rozszerzenie jest zbudowane dla starszych wersji TYPO3, własne rozwiązania są przyszłościowe

liveticker nie ma oficjalnego wsparcia dla TYPO3 v12 lub v13. Podstawowa funkcjonalność jest jednak na tyle prosta, że nowa budowa jako własny plugin jest w wielu przypadkach bardziej ekonomiczna niż migracja rozszerzenia. Gosign buduje funkcje liveticker jako smukłe pluginy Extbase z endpointem JSON API, z którego korzysta prosty klient JavaScript we frontendzie. Nakład pracy na podstawową implementację (wprowadzanie w backendzie, wyświetlanie we frontendzie, AJAX-polling) wynosi od 3 do 5 dni roboczych.

Zaletą własnego rozwiązania jest to, że wprowadzanie mobilne można zrealizować jako Progressive Web App, dzięki czemu redaktor przy boisku ma zoptymalizowany interfejs wprowadzania. Dodatkowo można umieścić warstwę cache (np. Redis lub Cloudflare Workers) między frontendem a TYPO3, co redukuje obciążenie serwera przy ruchu szczytowym do minimum. Ta architektura skaluje się dla ponad 10 000 jednoczesnych odwiedzających bez problemów z wydajnością.

--- Mailchimp TYPO3 - Newsletter | Gosign ---
> Synchronizacja subskrybentów między TYPO3 i Mailchimp. Statystyki kampanii, synchronizacja szablonów, maile transakcyjne.

## Integracja Mailchimp z TYPO3 wykracza poza formularze i dwukierunkowo synchronizuje Audiences

Podczas gdy koning_mailchimp_signup pokrywa tylko formularze rejestracji, rozszerzenie mailchimp idzie o krok dalej: dwukierunkowo synchronizuje kompletne listy subskrybentów między TYPO3 a Mailchimpem, przesyła statystyki kampanii do backendu i potrafi generować szablony newsletterowe z elementów treści TYPO3. Dla firm, które używają Mailchimpa nie tylko do wysyłki newslettera, lecz jako centralnej platformy Marketing Automation, rozszerzenie zamyka lukę między CMS a e-mail marketingiem.

Aspekt RODO jest przy tej głębszej integracji jeszcze istotniejszy: nie tylko adresy e-mail, lecz także dane o zaangażowaniu (otwarcia, kliknięcia, bounces), tagi i pola niestandardowe są przesyłane między systemami. Bez umowy powierzenia z Mailchimpem i udokumentowanego mechanizmu transferu do USA nie jest to dopuszczalne z punktu widzenia ochrony danych.

## Typowe scenariusze to automatyzacja marketingu, synchronizacja szablonów i raportowanie

Głównym scenariuszem jest dwukierunkowa synchronizacja subskrybentów dla zespołów marketingowych. TYPO3 jest źródłem nowych zapisów (przez formularze na stronie), Mailchimp jest źródłem danych o zaangażowaniu. Rozszerzenie regularnie synchronizuje oba systemy, dzięki czemu marketing widzi w Mailchimpie, którzy subskrybenci zapisali się przez którą stronę, a w TYPO3 widać, którzy subskrybenci są aktywni, a którzy zostali oznaczeni jako nieaktywni.

Drugi scenariusz: synchronizacja szablonów. Redakcja zarządza treściami newslettera w TYPO3, a rozszerzenie przenosi elementy treści (teasery, obrazy, linki) do szablonów Mailchimp. W ten sposób odpada podwójne utrzymanie: teaser na stronie i teaser w newsletterze pochodzą z tego samego rekordu danych.

Trzeci scenariusz: raportowanie kampanii w backendzie TYPO3. Osoby odpowiedzialne za marketing, które nie mają bezpośredniego dostępu do dashboardu Mailchimp, widzą wskaźniki otwarć, kliknięć i bounces bezpośrednio w backendzie TYPO3. Jest to istotne dla firm z rygorystycznym zarządzaniem uprawnieniami, gdzie tylko wybrane osoby mają dostęp do Mailchimpa. Dane pomagają redakcji zrozumieć, które treści strony działają w newsletterze, a które nie, co z kolei wpływa na strategię treści strony.

## Architektura techniczna wykorzystuje API Mailchimp v3 z synchronizacją opartą na Scheduler

Rozszerzenie komunikuje się przez Mailchimp Marketing API v3. Uwierzytelnianie odbywa się przez klucz API, który jest zapisany w Extension Manager TYPO3. Synchronizacja uruchamia się przez zadania Scheduler TYPO3 w konfigurowalnych odstępach.

Synchronizacja subskrybentów działa w dwóch kierunkach: TYPO3-do-Mailchimp przesyła nowe zapisy i zmiany profilu. Mailchimp-do-TYPO3 importuje dane o zaangażowaniu, wypisania i status bounce. Logika synchronizacji używa identyfikatorów członka Mailchimp (hash MD5 adresu e-mail) jako unikalnego klucza do porównywania.

Synchronizacja szablonów renderuje elementy treści TYPO3 przez szablony Fluid do formatu HTML zgodnego z e-mailem. Szablon jest przesyłany do Mailchimpa przez wywołanie API i jest tam dostępny jako szablon kampanii. Rozszerzenie zajmuje się konwersją klas CSS do stylów inline, co jest konieczne dla kompatybilności z klientami pocztowymi.

Dane kampanii są pobierane przez żądanie GET z API Mailchimp i zapisywane w tabeli bazy danych TYPO3. Moduł backendowy wyświetla dane jako dashboard z podstawowymi KPI: odbiorcy, wskaźnik otwarć, wskaźnik kliknięć, wypisania na kampanię.

## Częste problemy to konflikty synchronizacji, limity API i różnice w renderowaniu szablonów

Problem pierwszy: konflikty synchronizacji przy jednoczesnych zmianach. Gdy subskrybent wypisuje się w Mailchimpie, a jednocześnie redaktor w TYPO3 zmienia jego profil, powstaje konflikt. Rozwiązanie: jasno zdefiniować właściciela danych. W praktyce Mailchimp jest źródłem wiodącym dla danych o zaangażowaniu i wypisań, TYPO3 dla danych głównych i nowych zapisów.

Problem drugi: limity API. API Mailchimp pozwala na maksymalnie 10 jednoczesnych połączeń i ma limity przepustowości, które aktywują się przy dużych operacjach synchronizacji. Kto synchronizuje 50 000 subskrybentów, musi podzielić synchronizację na partie (zalecane: 500 rekordów na żądanie) i zaimplementować logikę backoff.

Problem trzeci: różnice w renderowaniu szablonów między stroną a mailem. Element treści, który na stronie wygląda poprawnie, może być inaczej wyświetlany w Outlooku lub Gmailu. Szczególnie układy Flexbox, webfonty i obrazy SVG nie działają w mailach. Rozwiązanie: osobne szablony mailowe z układem opartym na tabelach i fontach systemowych. Gosign utrzymuje dla takich przypadków dedykowany zestaw szablonów e-mail, który renderuje najczęstsze elementy treści w sposób kompatybilny z e-mailem.

Czwarty problem dotyczy higieny listy. Mailchimp nalicza opłaty według wielkości Audience, a gdy synchronizacja TYPO3 nie usuwa nieaktywnych subskrybentów, lista rośnie o adresy, które nigdy nie otwierają wiadomości lub są dawno nieaktywne. Rozszerzenie powinno być skonfigurowane tak, aby status bounce i zdarzenia unsubscribe z Mailchimpa były odzwierciedlane z powrotem w TYPO3, dzięki czemu nieaktywne adresy są wykluczane z synchronizacji. Oszczędza to koszty Mailchimp i poprawia dostarczalność dla pozostałych odbiorców.

## TYPO3 v12 jest wspierane, dla v13 zaleca się bezpośrednią integrację z API

Rozszerzenie mailchimp obsługuje TYPO3 v11 i v12. Przy aktualizacji należy dostosować przede wszystkim konfiguracje zadań Scheduler, ponieważ Scheduler API zmieniło się w TYPO3 v12. Konfigurację rozszerzenia należy przy tej okazji przełączyć na ustawienia oparte na SiteSet, aby była przyszłościowa. Dla TYPO3 v13 nie ma jeszcze oficjalnego wydania. Ponieważ API Mailchimp v3 jest stabilne i dobrze udokumentowane, Gosign zaleca dla projektów v13 bezpośrednią integrację z API bez zależności od rozszerzenia. Klasa własnego serwisu we własnym pakiecie TYPO3, która bezpośrednio komunikuje się z API Mailchimp, jest bardziej przyjazna dla utrzymania niż rozszerzenie społecznościowe i daje się dokładnie dopasować do wymagań projektu.

Firmy, które chcą pozostać długoterminowo przy Mailchimpie, powinny dodatkowo rozważyć funkcję Mailchimp Webhook: zamiast regularnie odpytywać o dane, Mailchimp aktywnie wysyła zdarzenia (zapis, wypis, bounce) do endpointu TYPO3. Redukuje to opóźnienie synchronizacji z minut do sekund i eliminuje obciążenie cyklicznymi zapytaniami API.

--- mailingwork TYPO3 - Newsletter | Gosign ---
> mailingwork to niemiecki system e-mail marketingu. Integracja z TYPO3 synchronizuje subskrybentów, Double-Opt-In i segmentację.

## mailingwork to zgodna z RODO alternatywa newsletterowa dla Mailchimpa w projektach TYPO3

Firmy, które chcą wysyłać profesjonalny newsletter, ale nie chcą przesyłać danych do USA, niemal nieuchronnie trafiają na niemieckiego dostawcę. mailingwork należy do uznanych niemieckich platform e-mail marketingu z serwerami w Niemczech, niemiecką formą prawną i zespołem wsparcia, który potrafi odpowiadać na pytania dotyczące RODO po niemiecku. Rozszerzenie TYPO3 synchronizuje listy subskrybentów, steruje Double-Opt-In i przesyła dane segmentacyjne między CMS a systemem newsletterowym. Dla projektów TYPO3, które potrzebują prawnie nieskomplikowanego rozwiązania newsletterowego, kombinacja mailingwork i TYPO3 jest jedną z najmniej wymagających utrzymaniowo opcji na rynku niemieckojęzycznym.

Porównanie z Mailchimpem pokazuje różnicę: brak DPA z firmą amerykańską, brak mechanizmu transferu do udokumentowania, brak ryzyka przy zmianach transatlantyckich umów o ochronie danych. Drugą stroną medalu jest to, że mailingwork ma mniejszy zestaw funkcji niż Mailchimp i nie ma porównywalnego ekosystemu integracji zewnętrznych. Kto potrzebuje zaawansowanej automatyzacji marketingu (wyzwalacze behawioralne, lead scoring, Customer Journey Mapping), u mailingwork szybciej napotka ograniczenia niż u Mailchimpa czy HubSpota.

## Typowe scenariusze to newslettery firmowe, komunikacja z członkami i lead nurturing

Scenariuszem standardowym jest comiesięczny newsletter firmowy dla 5000 do 50 000 odbiorców. Redakcja zarządza treściami w TYPO3, tworzy newsletter w mailingwork i wysyła go do posegmentowanych list. Rozszerzenie TYPO3 dba o to, aby nowe zapisy ze strony automatycznie trafiały do mailingwork i aby wypisania były synchronizowane w obie strony.

Drugi scenariusz: komunikacja z członkami w organizacjach i stowarzyszeniach. Stowarzyszenie zawodowe z 10 000 członkami wysyła okólniki, zaproszenia i sprawozdania roczne. Dane członków znajdują się w TYPO3 (przez fe_users lub niestandardową tabelę), a mailingwork przejmuje wysyłkę. Segmentacja według rodzaju członkostwa, regionu lub grupy branżowej sterowana jest tagami, które rozszerzenie generuje z kategorii TYPO3.

Trzeci scenariusz: lead nurturing dla firm B2B. Producent maszyn zbiera leady przez pobrania whitepaperów i formularze kontaktowe na stronie TYPO3. Rozszerzenie przekazuje leady wraz z informacją o źródle (który formularz, która strona) do mailingwork, który uruchamia zautomatyzowaną sekwencję maili: welcome mail po 1 dniu, case study po 7 dniach, zaproszenie ofertowe po 14 dniach.

## Architektura techniczna łączy formularze TYPO3 przez REST API mailingwork

Rozszerzenie wykorzystuje REST API mailingwork do wymiany danych. Konfiguracja w Extension Manager TYPO3 obejmuje endpoint API, klucz API i przypisanie pól TYPO3 do pól kontaktowych mailingwork. Synchronizacja uruchamia się przez zadania Scheduler w konfigurowalnych odstępach.

Import subskrybentów przebiega jasnym schematem: odwiedzający wypełnia formularz zapisu na stronie. TYPO3 zapisuje dane lokalnie i przesyła je przez wywołanie API do mailingwork. mailingwork wysyła mail Double-Opt-In. Dopiero po potwierdzeniu subskrybent jest prowadzony na aktywnej liście. Rozszerzenie protokołuje każdy krok w tabeli logów, co jest istotne dla audytów RODO.

Segmentacja działa przez tagi i pola niestandardowe. Rozszerzenie może automatycznie przekazywać kategorie TYPO3 (sys_category) do mailingwork jako tagi. Dzięki temu segmenty specyficzne dla strony (np. "zainteresowany produktem X") mogą być bezpośrednio wykorzystywane do wysyłki newslettera.

Szablony w mailingwork są zarządzane niezależnie od TYPO3. Kto chce automatycznie przenosić treści z TYPO3 do szablonów newslettera, musi rozwiązać to przez API mailingwork i własny kod, ponieważ standardowe rozszerzenie nie pokrywa tej funkcji.

## Częste problemy dotyczą mapowania pól, czasu Double-Opt-In i obsługi błędów

Problem pierwszy: błędne mapowanie pól. Pola w formularzach TYPO3 rzadko zgadzają się 1:1 z polami kontaktowymi w mailingwork. Formularz ma "Firma", mailingwork oczekuje "company". Bez prawidłowego mapowania dane trafiają do niewłaściwych pól lub giną. Rozwiązanie: przed integracją stworzyć dokument mapowania pól, który przypisuje wszystkie pola TYPO3 do pól mailingwork i zapisać to przypisanie w konfiguracji rozszerzenia.

Problem drugi: czas Double-Opt-In. Między zapisem na stronie a kliknięciem w link potwierdzający często upływają godziny lub dni. Gdy zadanie synchronizacji uruchomi się w międzyczasie i oznaczy jeszcze niepotwierdzonego subskrybenta jako "aktywnego" z powrotem w TYPO3, powstają niespójności. Rozwiązanie: ustawiać status subskrybenta w TYPO3 na "aktywny" dopiero wtedy, gdy mailingwork zwróci status "confirmed".

Problem trzeci: obsługa błędów przy awariach API. Gdy API mailingwork jest niedostępne, rozszerzenie musi buforować zapis i spróbować ponownie przy następnym uruchomieniu synchronizacji. Bez tej logiki ponawiania zapisy giną. Rozszerzenie oferuje funkcję kolejki, która zapisuje nieudane wywołania API i automatycznie je ponawia.

Czwarty problem, który pojawia się przy większych instalacjach: szczegółowość raportowania. mailingwork dostarcza statystyki kampanii na poziomie odbiorcy, ale rozszerzenie TYPO3 nie odwzorowuje wszystkich metryk w backendzie. Do szczegółowych analiz (heatmapy kliknięć, momenty otwarć, rozkład urządzeń) trzeba przejść do dashboardu mailingwork. Gosign zaleca używanie modułu backendowego TYPO3 do danych ogólnych, a do głębokich analiz pracować bezpośrednio w mailingwork.

## mailingwork aktywnie utrzymuje rozszerzenie TYPO3, v12 jest obsługiwane

mailingwork jako komercyjny dostawca ma biznesowy interes w utrzymywaniu integracji TYPO3 w stanie aktualnym, ponieważ rynek TYPO3 jest istotnym kanałem sprzedaży. Aktualne rozszerzenie obsługuje TYPO3 v11 i v12. Dla v13 można oczekiwać kompatybilności, ale nie jest jeszcze oficjalnie potwierdzona. Przy aktualizacji z v10 do v12 zmiany dotyczą przede wszystkim rejestracji zadań Scheduler i konfiguracji rozszerzenia, która powinna zostać przełączona z ustawień Extension Manager na konfigurację SiteSet. Synchronizacja subskrybentów i komunikacja z API pozostają stabilne.

--- maps2 TYPO3 - Rozszerzenie map | Gosign ---
> Standardowe rozszerzenie map dla TYPO3. Obsługa Google Maps, OpenStreetMap i Mapbox. Markery z rekordów TYPO3, clustering, routing, Custom-Popupy.

## Dlaczego maps2 stało się standardowym rozwiązaniem mapowym w TYPO3

Co druga strona firmowa potrzebuje wyświetlania mapy - dla lokalizacji, oddziałów, miejsc wydarzeń czy obszarów dostawy. W TYPO3 maps2 ugruntowało się jako najbardziej rozpowszechnione rozszerzenie mapowe, ponieważ jednocześnie wspiera trzech dostawców map: Google Maps, OpenStreetMap i Mapbox. Dla firm oznacza to prawdziwą wolność wyboru. Kto chce uniknąć Google Maps ze względu na ochronę danych, przełącza się na OpenStreetMap bez konieczności zmiany rozszerzenia.

maps2 wykracza daleko poza proste osadzanie mapy. Rozszerzenie generuje markery bezpośrednio z rekordów TYPO3, wspiera clustering przy dużych ilościach markerów i oferuje funkcje routingu. Dla redaktorów tworzenie nowych lokalizacji jest tak proste jak tworzenie normalnego elementu treści TYPO3.

## Typowe scenariusze zastosowań

**Wyszukiwarka oddziałów dla firm z 10 do 500 lokalizacjami.** Firma handlowa chce zaoferować na swojej stronie interaktywną wyszukiwarkę oddziałów. Każdy oddział jest przechowywany jako rekord tt_address w TYPO3. maps2 odczytuje adresy, geokoduje je (w połączeniu z rozszerzeniem geocoordinates) i wyświetla jako markery na mapie. Przy kliknięciu na marker otwiera się popup z adresem, godzinami otwarcia i danymi kontaktowymi. Przy więcej niż 50 markerach maps2 automatycznie aktywuje clustering.

**Strony nieruchomości z mapami obiektów.** Strony pośredników na bazie TYPO3 korzystają z maps2 razem z rozszerzeniem OpenImmo. Każdy zaimportowany obiekt nieruchomości jest automatycznie wyświetlany na mapie.

**Strony eventowe i wydarzeń.** Instytucje kulturalne, targi czy gminy wyświetlają miejsca wydarzeń na mapie. maps2 można powiązać z każdym rozszerzeniem Extbase zawierającym dane adresowe.

## Architektura techniczna

maps2 jest zbudowane jako rozszerzenie Extbase. Centralna decyzja architektoniczna to abstrakcja dostawcy: rozszerzenie definiuje jednolity interfejs renderowania map, implementowany przez trzech providerów. Google Maps Provider korzysta z Google Maps JavaScript API v3 (wymaga klucza API, ok. 7 USD za 1000 wywołań po darmowym limicie). OpenStreetMap Provider korzysta z Leaflet.js z kafelkami OSM (bez kosztów API). Mapbox Provider to opcja premium z własnymi stylami map.

Rozszerzenie przechowuje konfiguracje map we własnych tabelach bazodanowych. Markery są generowane przez relacje do dowolnych rekordów TYPO3 - maps2 nie jest ograniczone do określonego typu rekordu.

## Częste problemy i rozwiązania

**Mapa nie wyświetla się, tylko szary obszar.** Przy Google Maps w 90% przypadków problem dotyczy klucza API. Albo go brakuje, rozliczenie nie jest aktywowane, albo dozwolone domeny w kluczu API nie zgadzają się z witryną. Rozwiązanie: sprawdzenie w Google Cloud Console, czy Maps JavaScript API jest aktywowane i klucz jest odblokowany dla właściwej domeny.

**Markery pojawiają się w złej pozycji.** Przyczyną jest często błędne lub brakujące geokodowanie. Rozwiązanie: jednorazowa korekta współrzędnych przez batch geocoding i zapisanie w rekordzie jako stałe wartości.

**Problemy wydajnościowe przy ponad 200 markerach.** Biblioteka JavaScript renderuje każdy marker osobno w DOM. Od 200 markerów na urządzeniach mobilnych staje się to odczuwalnie wolne. Rozwiązanie: aktywacja Marker-Clustering i w razie potrzeby implementacja serwerowego filtrowania.

## Migracja i kompatybilność wersji

maps2 jest aktywnie utrzymywane przez Stefana Froemkena i jest dostępne dla TYPO3 v11 i v12 LTS. Kompatybilność z TYPO3 v13 jest z reguły zapewniana wkrótce po wydaniu LTS. Rozszerzenie ma stabilne API i prawie żadnych zmian łamiących między głównymi wersjami.

Przy przejściu z Google Maps na OpenStreetMap (często z motywacji RODO/UODO) wystarczy zmienić konfigurację dostawcy w maps2. Szablony i dane markerów pozostają identyczne. Gosign zrealizował tę zmianę u kilku klientów w mniej niż jeden dzień. Motywacja ochrony danych: Google Maps przesyła dane osobowe (adres IP, fingerprint przeglądarki) do serwerów Google w USA. Z OpenStreetMap dane pozostają w Europie, a baner zgody na usługi mapowe staje się zbędny.

Gosign standardowo łączy maps2 z geocoordinates, by dostarczyć kompletny stos wyszukiwarki oddziałów: wprowadzanie adresu przez redaktora, automatyczne geokodowanie w tle, wyświetlanie mapy z markerem i popupem we frontendzie, wyszukiwanie w okolicy z wprowadzaniem kodu pocztowego dla odwiedzającego. Stos jest konfigurowany w 2 do 3 dni i pokrywa wymagania 90% wszystkich projektów wyszukiwarek oddziałów.

--- Marquee TYPO3 - Tekst przewijany/ticker | Gosign ---
> Tekst przewijany/ticker: News-ticker, banery informacyjne, ogłoszenia. Gosign wdraża marquee oparte na CSS bez rozszerzenia, lżejsze, wydajniejsze.

## Teksty przewijane i tickery nie potrzebują rozszerzenia, CSS rozwiązuje to w 20 liniach

Element marquee zna każdy z początków internetu: przewijający się tekst, który przesuwa się od prawej do lewej po stronie. Tag HTML `<marquee>` od lat jest deprecated, ale efekt pozostaje pożądany. News-tickery, banery informacyjne ("prace konserwacyjne w sobotę") i zapowiedzi wydarzeń wykorzystują teksty przewijane jako mechanizm przyciągania uwagi. Rozszerzenie marquee dla TYPO3 dostarcza element treści, który renderuje ten efekt przez JavaScript. Gosign zaleca zamiast tego czyste rozwiązanie CSS, które obywa się bez rozszerzenia, bez JavaScriptu i bez obowiązku aktualizacji.

Różnica jest mierzalna: rozszerzenie ładuje JavaScript, rejestruje element treści w TCA i wymaga szablonów Fluid. Alternatywa CSS to pojedyncza animacja CSS (20 linii) na zwykłym elemencie treści tekstowej. Wydajność, dostępność i nakład utrzymania jednoznacznie przemawiają za podejściem CSS.

## Typowe scenariusze to informacje o przerwach technicznych, banery akcji i wyniki sportowe

Najczęstszym scenariuszem jest baner informacyjny na firmowej stronie. "Nasze biuro jest nieczynne od 24.12 do 02.01" lub "Zapisz się teraz: webinarium 15 marca". Przewijający się tekst zwraca uwagę, nie będąc popupem. Redaktorzy zarządzają tekstem w backendzie TYPO3 i aktywują lub dezaktywują baner przez datę początkową i końcową.

Drugi scenariusz: News-ticker na portalach informacyjnych i stronach startowych intranetu. Ostatnie trzy do pięciu nagłówków przewija się jako ticker w górnej części strony. Każdy nagłówek jest linkiem do pełnego artykułu. Szybkość jest tak ustawiona, aby tekst pozostawał czytelny (zalecane: 30 do 50 pikseli na sekundę).

Trzeci scenariusz: wyniki sportowe na stronach klubów. W dniu meczowym ticker pokazuje aktualne wyniki wszystkich drużyn. Dane pochodzą z tabeli TYPO3 lub zewnętrznego feedu i są prezentowane jako przewijany tekst. Kombinacja tekstu przewijanego i automatycznej aktualizacji (przez AJAX co 60 sekund) czyni ticker kanałem informacyjnym w czasie rzeczywistym bez złożoności pełnego rozszerzenia liveticker.

## Architektura techniczna rozszerzenia to element treści sterowany JavaScriptem

Rozszerzenie marquee rejestruje element treści w TCA TYPO3, który zawiera pola dla tekstu, szybkości, kierunku i powtarzania. Szablon Fluid renderuje element kontenerowy, a plik JavaScript inicjalizuje animację. Konfiguracja (szybkość, pauza przy najechaniu, nieskończone powtarzanie) jest przekazywana do JavaScriptu przez atrybuty data na elemencie kontenera.

Alternatywa CSS działa tak: zwykły element treści tekstowej otrzymuje klasę CSS (np. "marquee"), a animacja CSS @keyframes scroll przesuwa tekst od prawej do lewej. Animacja jest nieskończona, zatrzymuje się przy najechaniu (przez :hover) i respektuje ustawienie prefers-reduced-motion systemu operacyjnego, co jest istotne dla dostępności. Cały kod:

```css
.marquee { overflow: hidden; white-space: nowrap; }
.marquee span { display: inline-block; animation: scroll 20s linear infinite; }
.marquee:hover span { animation-play-state: paused; }
@media (prefers-reduced-motion: reduce) { .marquee span { animation: none; } }
@keyframes scroll { from { transform: translateX(100%); } to { transform: translateX(-100%); } }
```

## Częste problemy to dostępność, widok mobilny i znaczenie SEO

Problem pierwszy: dostępność. Ruchome treści są problematyczne dla osób z ograniczeniami poznawczymi lub padaczką. WCAG 2.1 wymaga, aby animacje można było zatrzymać, wstrzymać lub ukryć. Rozszerzenie oferuje funkcję pauzy przy najechaniu, ale brak przycisku stop. Rozwiązanie CSS automatycznie respektuje ustawienie prefers-reduced-motion, czego rozszerzenie nie robi.

Problem drugi: widok mobilny. Na smartfonach dostępne miejsce na przewijany tekst jest minimalne. Ticker, który na pulpicie jest dobrze czytelny, na telefonie przelatuje tak szybko, że nikt nie zdąży przeczytać. Rozwiązanie: na urządzeniach mobilnych zastąpić ticker statycznym banerem, który pokazuje najważniejszy komunikat bez animacji.

Problem trzeci: znaczenie SEO. Przewijany tekst jest indeksowany przez wyszukiwarki, ale sygnały UX (krótki czas na tickerze, brak kliknięć) mogą negatywnie wpłynąć na jakość strony. Treści tickera powinny być zawsze dostępne także jako zwykłe treści strony, nie tylko w tickerze.

Czwarty problem: zgodność z dostępnością w instytucjach publicznych. Ustawa o dostępności cyfrowej i norma EN 301 549 wymagają, aby animacje można było zatrzymać. Marquee bez przycisku stop lub mechanizmu pauzy narusza WCAG 2.2.2 (Pause, Stop, Hide). Rozwiązanie CSS z prefers-reduced-motion i pauzą na :hover spełnia to wymaganie częściowo, dla pełnej zgodności potrzebny byłby wyraźny przycisk pauzy.

## Rozszerzenie jest zbędne dla aktualnych wersji TYPO3

Rozszerzenie marquee nie ma oficjalnego wsparcia dla TYPO3 v12 lub v13. Ponieważ alternatywa CSS jest wdrażana w 15 minut i nie generuje zależności od rozszerzenia, Gosign zaleca przy każdej migracji zmianę. Redaktor używa zwykłego elementu treści tekstowej ze specjalną klasą CSS, zdefiniowaną w Site-Package. Jest to bezobsługowe, wydajne i dostępne.

Dla projektów, które chcą rotować kilka komunikatów w tickerze, wystarcza rozszerzona animacja CSS przechodząca przez kilka bloków tekstowych po kolei. Alternatywnie minimalny JavaScript (poniżej 20 linii) może doładowywać teksty ze źródła JSON i sterować animacją. Oba rozwiązania są architektonicznie czystsze niż rozszerzenie, które dla jednego efektu dostarcza kompletne pole TCA, szablon Fluid i plik JavaScript. W Gosign stosujemy podejście CSS we wszystkich projektach, które potrzebują tickera lub tekstu przewijanego.

--- Mask TYPO3 - Custom elementy treści | Gosign ---
> Mask to standardowe narzędzie do Custom Content Elements w TYPO3. Tworzenie masek backendu bez PHP: definiowanie pól, przypisanie Fluid Template, gotowe.

## Redaktorzy potrzebują własnych elementów treści, a nie kolejnych obejść z polami tekstowymi

Każda witryna TYPO3 dochodzi do punktu, w którym wbudowane elementy treści przestają wystarczać. Karuzela zespołu, tabela cenowa z przełącznikami, teaser produktu z obrazem, tekstem i przyciskiem CTA - takie wymagania lądują w edytorze RTE jako bałagan HTML albo w przepełnionym kontenerze Flexform. Mask rozwiązuje ten problem fundamentalnie: redaktorzy otrzymują własne maski backendowe z dokładnie takimi polami, jakich potrzebują. Bez klas PHP, bez ręcznego TCA, bez ext_tables.sql.

Mask jest od 2016 roku najczęściej używanym frameworkiem do Custom Content Elements w TYPO3. Ponad 1500 aktywnych instalacji (stan: packagist, kwiecień 2026) i włączenie do oficjalnej dokumentacji TYPO3 jako rekomendowany sposób tworzenia indywidualnych elementów treści potwierdzają status de facto standardu.

## Typowe scenariusze zastosowań

**Witryny korporacyjne ze złożonymi strukturami stron.** Zespoły marketingowe potrzebują od 15 do 30 różnych elementów treści: banery hero, referencje, akordeony, zakładki, pliki do pobrania z miniaturą, karty kontaktowe. Mask odwzorowuje każdy z nich jako osobny formularz backendowy. Redaktorzy widzą tylko pola dotyczące danego elementu - żadnego zamieszania z powodu nieistotnych opcji.

**Projekty wielojęzyczne z konsystentną strukturą.** Elementy Mask w pełni wspierają mechanizmy tłumaczeniowe TYPO3. Pola można konfigurować jako l10n_mode exclude (nietłumaczalne) lub prefixLangTitle (tłumaczalne z podpowiedzią). W witrynach z ponad 5 językami oszczędza to czas redakcji, ponieważ struktura pozostaje identyczna - tłumaczony jest jedynie kontekst.

**Projekty relaunch z istniejącymi danymi.** Kto migruje ze starego systemu (WordPress, TYPO3 z Gridelements lub TemplaVoila), potrzebuje czystych struktur treści. Elementy Mask można eksportować jako samodzielne rozszerzenie za pomocą mask_export. Dzięki temu definicje treści stają się wersjonowalne i wdrażalne przez pipeline CI/CD.

## Architektura techniczna

Mask przechowuje konfigurację wszystkich elementów treści w jednym pliku JSON (`mask.json` lub `config/mask.json` od Mask 8). Ten plik opisuje pola, typy, palety i przypisania do szablonów Fluid. Przy aktywacji lub aktualizacji Mask automatycznie generuje z niego niezbędne konfiguracje TCA i pola bazy danych.

Typy pól obejmują pełny standard TYPO3: String, Integer, Float, RichText, Date, DateTime, File (FAL), Inline (IRRE do zagnieżdżonych struktur), Select, Checkbox, Radio, Link, Slug, Color Picker, Tab, Palette. Od Mask 8 dochodzą pola natywne JSON i ulepszone API.

Szablony Fluid znajdują się standardowo w `fileadmin/templates/mask/` lub w konfigurowalnej ścieżce. Każdy element treści ma własny szablon, opcjonalnie z Partials i Layouts. Mask rejestruje elementy w New Content Element Wizard, włącznie z ikoną i opisem.

Zależności są minimalne: Mask wymaga jedynie TYPO3 Core (v11, v12, v13 są aktywnie wspierane). Żadne dodatkowe rozszerzenia nie są potrzebne. Do workflow eksportowego dochodzi mask_export jako opcjonalne uzupełnienie.

## Częste problemy i rozwiązania

**Zmiany pól na systemach produkcyjnych.** Gdy pole Mask zostanie zmienione na systemie staging (typ, nazwa pola), ale baza danych na produkcji nie zostanie zaktualizowana, pojawiają się błędy. Rozwiązanie: korzystać z mask_export, aby zmiany konfiguracji przechodzily przez Git i pipeline wdrożeniowe. Alternatywnie: Database Compare w Install Tool po każdym wdrożeniu.

**Wydajność przy wielu elementach treści.** Witryny z ponad 40 różnymi elementami Mask generują dużą konfigurację TCA. TYPO3 ładuje ją przy każdym wywołaniu backendu. Rozwiązanie: sensowne grupowanie elementów, dezaktywacja nieużywanych, utrzymywanie aktywnego cache backendu. Od Mask 8 generowanie TCA jest znacznie wydajniejsze niż w poprzednich wersjach.

**Zagnieżdżone elementy (IRRE) i sortowanie.** Relacje inline (np. slajdy slidera wewnątrz elementu slidera) przy kopiowaniu/wklejaniu czasem tracą kolejność. Rozwiązanie: jawne zdefiniowanie pola sortowania i zabezpieczenie w szablonie Fluid `<f:for>` za pomocą `sortBy`. W Mask 8.x to zachowanie jest stabilniejsze niż w 7.x.

## Migracja i kompatybilność wersji

Mask aktywnie wspiera TYPO3 v12 i v13. Aktualna stabilna wersja (Mask 8.x) działa na obu wydaniach LTS. TYPO3 v11 jest obsługiwane przez Mask 7.x, ale nie otrzymuje już nowych funkcji.

Dla projektów, które nadal korzystają z TemplaVoila lub DCE, Mask oferuje klarowną ścieżkę migracji. Elementy DCE można ręcznie przenieść do Mask: odtworzyć pola w GUI Mask, dostosować szablony Fluid, zmigrować dane przez skrypt SQL. Gosign przeprowadził ten proces w projektach z ponad 20 elementami DCE, szacując nakład na 2 do 5 dni w zależności od złożoności.

Od TYPO3 v13 dostępne jest dodatkowo natywne Content Block API. Dla istniejących projektów Mask nie oznacza to pośpiechu: Mask i Content Blocks współistnieją bez problemów. Nowe projekty na czystym TYPO3 v13 mogą rozważyć, czy natywne podejście wystarczy, czy Mask dzięki swojemu GUI i workflow eksportowemu oferuje przewagę. Gosign doradza w każdym projekcie indywidualnie, które podejście generuje najmniejszy nakład utrzymania w perspektywie długoterminowej.

Często niedocenianym aspektem jest dokumentacja. Elementy Mask są zrozumiałe dla programistów (pola, typy, szablony), ale redaktorzy potrzebują wskazówek: Które pola są obowiązkowe? Jaki rozmiar obrazu jest optymalny? Co się stanie, gdy pole opisu pozostanie puste? Mask od wersji 7 wspiera teksty opisowe na pole, które pojawiają się w backendzie jako tooltip. Gosign dodatkowo tworzy wewnętrzny podręcznik redakcyjny dla każdego projektu, w którym każdy element Mask jest udokumentowany ze zrzutem ekranu, opisem pól i najlepszymi praktykami. Nakład to pół godziny na element, ale oszczędza pytania zwrotne w trakcie eksploatacji.

Do początkowej konfiguracji projektu Mask z 15 do 20 elementami treści Gosign kalkuluje 3 do 5 dni deweloperskich, włącznie z szablonami Fluid, podglądem backendowym i konfiguracją mask_export. Pojedyncze nowe elementy w trakcie eksploatacji realizowane są w 1 do 4 godzin, w zależności od złożoności zagnieżdżenia i projektu szablonu.

--- mask_export TYPO3 - Mask Deployment | Gosign ---
> Rozszerzenie eksportujące konfiguracje Mask Content Elements jako samodzielne rozszerzenie TYPO3.

## Bez mask_export elementy Mask nie są wersjonowalne i każde wdrożenie to ryzyko

Mask to standard dla Custom Content Elements w TYPO3. Ale Mask przechowuje swoją konfigurację w pliku JSON i generuje pola bazy danych w czasie wykonywania. W profesjonalnym procesie deweloperskim z wieloma środowiskami (lokalne, staging, produkcja) rodzi to problem: jak przenieść nowe elementy treści z komputera deweloperskiego na serwer produkcyjny? Ręcznie klikać w backendzie? Kopiować mask.json przez FTP i uruchamiać Database Compare? Oba podejścia są podatne na błędy i niepowtarzalne.

mask_export rozwiązuje ten problem. Rozszerzenie eksportuje wszystkie definicje Mask jako samodzielne rozszerzenie TYPO3 z własnym ext_tables.sql, konfiguracjami TCA i szablonami Fluid. To rozszerzenie jest instalowane przez Composer, wersjonowane przez Git i wdrażane przez CI/CD - dokładnie jak każde inne rozszerzenie TYPO3. Dzięki temu Mask staje się gotowe na enterprise.

## Typowe scenariusze zastosowań

**Agencje z pipeline CI/CD.** Agencje wdrażające projekty TYPO3 przez GitLab CI, GitHub Actions lub Deployer potrzebują wersjonowalnych artefaktów. mask_export generuje rozszerzenie instalowane przez `composer require`. Każda zmiana elementu treści tworzy nowy commit przechodzący przez pipeline: lint, testy, deploy staging, deploy produkcja. Żadna ręczna interwencja w backendzie nie jest potrzebna.

**Projekty Multi-Site ze wspólnymi elementami.** Koncerny z 5 do 20 instancjami TYPO3 (spółki krajowe, marki, spółki zależne) chcą stosować jednolite elementy treści we wszystkich witrynach. mask_export tworzy centralne rozszerzenie wbudowywane we wszystkie instancje. Zmiany są dokonywane raz i dystrybuowane do wszystkich witryn. Bez mask_export elementy Mask musialyby być ręcznie odtwarzane na każdej instancji.

**Przekazanie między programistami a redakcją.** Programiści definiują elementy treści na systemie lokalnym, eksportują je przez mask_export i commitują wynik. Redaktorzy pracują na systemie staging lub produkcji i korzystają z elementów bez potrzeby dostępu do GUI Mask. Rozszerzenie Mask może być nawet odinstalowane na systemach produkcyjnych, jeśli potrzebne jest tylko wyeksportowane rozszerzenie.

## Architektura techniczna

mask_export odczytuje mask.json (lub config/mask.json od Mask 8) i generuje z niej kompletne rozszerzenie TYPO3. Wygenerowana struktura zawiera: ext_emconf.php (metadane rozszerzenia), ext_tables.sql (definicje bazy danych dla wszystkich pól Mask), Configuration/TCA/Overrides/tt_content.php (konfiguracja TCA), Resources/Private/Templates/ (szablony Fluid, skopiowane z konfigurowanej ścieżki szablonów Mask) i opcjonalnie konfigurację TypoScript dla renderingu frontendowego.

Proces eksportu działa jako komenda TYPO3 CLI: `php typo3/sysext/core/bin/typo3 mask:export`. Wynikiem jest katalog, który może być wbudowany jako pakiet Composer lub jako lokalne rozszerzenie w typo3conf/ext/. Rozszerzenie Mask po eksporcie nie jest już potrzebne, dopóki nie są tworzone nowe elementy ani zmieniane istniejące.

## Częste problemy i rozwiązania

**Zapomniany eksport po zmianie.** Programista zmienia pole Mask na systemie lokalnym, ale commituje tylko mask.json, nie nowy eksport. Na staging brakuje wtedy konfiguracji TCA. Rozwiązanie: zintegrowanie komendy mask_export w Git-hook (pre-commit) lub w pipeline CI. Gosign stosuje sprawdzenie w pipeline wdrożeniowym, które porównuje, czy mask.json i ostatni eksport są zsynchronizowane.

**Szablony Fluid nie są eksportowane.** mask_export domyślnie kopiuje szablony z konfigurowanej ścieżki. Jeśli szablony leżą poza tą ścieżką (np. we własnym pakiecie motywu), nie są uwzględniane. Rozwiązanie: umieszczenie wszystkich szablonów Mask w jednolitym katalogu i odwołanie do niego w konfiguracji Mask.

**Konflikty przy jednoczesnym używaniu Mask i wyeksportowanego rozszerzenia.** Jeśli na systemie produkcyjnym zainstalowane są zarówno Mask, jak i wyeksportowane rozszerzenie, mogą wystąpić podwójne rejestracje TCA. Rozwiązanie: na systemach, gdzie redaktorzy nie tworzą nowych elementów, instalacja tylko wyeksportowanego rozszerzenia i deinstalacja Mask. Na systemach deweloperskich oba działają równolegle, eksport nadpisuje poprzednią wersję.

## Migracja i kompatybilność wersji

mask_export podąża za cyklem wydań Mask: gdy Mask wspiera nową wersję TYPO3, mask_export jest aktualizowane w krótkim czasie. Obecnie wspierane są TYPO3 v11, v12 i v13. Wyeksportowane rozszerzenie jest kompatybilne z tą samą wersją TYPO3 co wersja Mask, z której zostało wygenerowane.

Dla projektów chcących przejść na TYPO3 v13 z natywnym Content Block API, mask_export może służyć jako krok pośredni: najpierw eksport elementów Mask (czysta struktura oparta na plikach), potem przetłumaczenie wyeksportowanych konfiguracji TCA na definicje Content Block. Nakład per element jest niewielki (30 do 60 minut), gdy wyeksportowane rozszerzenie służy jako referencja.

Często pomijaną zaletą mask_export jest testowalność. Gdy elementy treści istnieją jako samodzielne rozszerzenie, można pisać automatyczne testy: sprawdzanie konfiguracji TCA, testowanie renderingu szablonów i walidacja schematu bazy danych. W pipeline CI takie testy wychwytują błędy, zanim trafią na staging lub produkcję.

Dla projektów z ponad 20 elementami Mask Gosign zaleca wbudowanie procesu eksportu w workflow deweloperski od samego początku. Początkowy nakład (integracja komendy CLI w pipeline CI, założenie repozytorium Git dla wyeksportowanego rozszerzenia, dostosowanie konfiguracji Composer) wynosi około 2 do 4 godzin. Potem workflow jest w pełni zautomatyzowany i każda zmiana Mask trafia do wdrożenia bez ręcznego kroku.

--- Mask Twig TYPO3 - Szablony | Gosign ---
> Szablony Twig lub Nunjucks zamiast Fluid dla Mask Content Elements. Dla programistów frontend preferujących składnię Twig lub chcących ponownie wykorzystać.

## Dlaczego programiści frontend preferują Twig nad Fluid i jak Mask to umożliwia

TYPO3 z Fluid korzysta z silnika szablonów, który jest unikalny w świecie PHP. To jednocześnie jego siła i największy problem: programiści frontend przychodzący ze środowiska Symfony, Laravel lub Node.js znają Twig lub Nunjucks. Fluid nie znają. mask_twig_nunjucks_connector zamyka tę lukę, pozwalając renderować Mask Content Elements szablonami Twig lub Nunjucks zamiast szablonów Fluid.

Dla agencji, których zespół frontendowy pracuje z Twig i nie chce uczyć się nowego języka szablonów dla każdego projektu TYPO3, connector to pragmatyczne rozwiązanie. Istniejące parcjale Twig z projektów Symfony lub komponenty Nunjucks z Pattern Libraries można bezpośrednio ponownie wykorzystać.

## Typowe scenariusze zastosowań

**Agencje z backendem Symfony i frontendem TYPO3.** Agencja rozwija swoje aplikacje webowe w Symfony i używa TYPO3 tylko do zarządzania treścią. Zespół frontend zbudował obszerną bibliotekę komponentów Twig. Zamiast przepisywać wszystkie komponenty na Fluid, connector wbudowuje istniejące szablony Twig bezpośrednio w Mask Content Elements.

**Integracja Pattern Library z Nunjucks.** Zespół projektowy zarządza Pattern Library (np. na bazie Fractal lub Storybook) używającą Nunjucks jako języka szablonów. Connector pozwala używać tych samych szablonów Nunjucks zarówno w Pattern Library, jak i w TYPO3.

**Onboarding programistów frontend w projektach TYPO3.** Nowy programista frontend zaczyna w projekcie TYPO3. Zamiast najpierw uczyć się Fluid (składnia, przestrzenie nazw, koncepcja ViewHelper), pisze szablony Twig, które już zna. Krzywa uczenia się dla projektu skraca się z 2 do 3 dni do kilku godzin.

## Architektura techniczna

mask_twig_nunjucks_connector działa jako most renderujący między rozszerzeniem Mask a alternatywnym silnikiem szablonów. Mask definiuje Custom Content Elements z polami backendowymi. Standardowo Mask renderuje te elementy szablonami Fluid. Connector zastępuje ten krok renderujący.

Integracja Twig korzysta z biblioteki PHP `twig/twig` (tej samej, której używa Symfony). Szablony Twig leżą w systemie plików, typowo pod `Resources/Private/Twig/`. Pola Mask są dostępne jako zmienne szablonu (`{{ data.header }}`, `{{ data.bodytext }}`). Integracja Nunjucks może renderować szablony po stronie serwera przez most Node.js lub dostarczać je po stronie klienta jako szablony JavaScript.

Zależności: TYPO3 Core, rozszerzenie Mask, pakiet Composer `twig/twig` (dla Twig) lub Node.js (dla serwerowego Nunjucks). W praktyce ponad 90% instalacji connectora używa Twig, nie Nunjucks, ponieważ Twig natywnie działa w PHP i nie wymaga zewnętrznego procesu.

## Częste problemy i rozwiązania

**Szablon Twig nie ma dostępu do danych specyficznych dla TYPO3.** Fluid-ViewHelper takie jak `f:uri.page`, `f:translate` czy `f:cObject` nie istnieją w Twig. Rozwiązanie: wszystkie potrzebne dane muszą być dostarczane przez mapowanie zmiennych. Connector może przez konfigurację wstrzykiwać dodatkowe dane (aktualny język, URL strony, globalne ustawienia) do kontekstu szablonu.

**Renderowanie Nunjucks jest wolne.** Most Node.js do serwerowego renderowania Nunjucks uruchamia dla każdego żądania proces Node. Rozwiązanie: użycie trwałego procesu workera Node.js lub przejście na Twig, który renderuje natywnie w PHP.

**Aktualizacja Mask łamie nazwy zmiennych szablonu.** Gdy Mask zmieni nazwę pola lub typ pola, zmieniają się zmienne szablonu. Szablony Fluid wtedy pokazują puste miejsca, szablony Twig rzucają błąd. Rozwiązanie: uruchomienie Twig w trybie strict (`strict_variables: true`) i testowanie szablonów po każdej aktualizacji Mask.

## Migracja i kompatybilność wersji

mask_twig_nunjucks_connector to projekt społecznościowy o ograniczonym zasięgu. Kompatybilność zależy od rozszerzenia Mask: Mask jest aktywnie utrzymywane i wspiera TYPO3 v11 i v12. Connector musi być sprawdzany pod kątem kompatybilności przy każdej aktualizacji Mask.

Gosign zaleca connector dla projektów, w których zespół frontend pracuje wyłącznie z Twig i posiada istniejącą bibliotekę komponentów. Dla czystych projektów TYPO3 bez zewnętrznych wymagań szablonowych Fluid pozostaje lepszym wyborem, ponieważ jest natywnie wspierane, nie ma dodatkowych zależności i może korzystać z całej biblioteki ViewHelper TYPO3. Zysk produktywności przez ponowne użycie Twig musi przekraczać nakład utrzymania connectora - kalkulacja, którą należy konkretnie przeprowadzić przy każdym starcie projektu.

--- mathguard TYPO3 - CAPTCHA matematyczny | Gosign ---
> Matematyczny CAPTCHA dla TYPO3: Proste zadania rachunkowe zamiast CAPTCHA graficznych.

## CAPTCHA matematyczny to dostępna ochrona antyspamowa, której większość stron nie zna

Spam w formularzach kontaktowych jest tematem ciągłym. Najpopularniejszym rozwiązaniem jest Google reCAPTCHA, które jednak przesyła dane użytkownika do Google i komplikuje zgodność z RODO. CAPTCHA oparte na obrazach ("kliknij wszystkie sygnalizatory") frustrują użytkowników i są niedostępne dla czytników ekranu. mathguard idzie inną drogą: rozszerzenie pokazuje w formularzu proste zadanie rachunkowe ("ile to jest 3 + 7?"). Ludzie rozwiązują to w kilka sekund, automatyczne boty w większości zawodzą. Żadnego zewnętrznego JavaScriptu, żadnych ciasteczek, żadnego przesyłania danych do stron trzecich, w pełni zgodne z czytnikami ekranu.

Dla instytucji publicznych, uczelni i firm z wymaganiami dostępności (WCAG 2.1, ustawa o zapewnianiu dostępności cyfrowej) mathguard jest jednym z niewielu rozwiązań CAPTCHA, które gwarantuje zarówno ochronę antyspamową, jak i dostępność. Redukcja spamu wynosi od 85 do 95 procent przychodzącego ruchu botów. Dla porównania: Google reCAPTCHA v3 osiąga podobne wartości, ale przesyła dane do serwerów Google przy każdym załadowaniu strony, nawet bez interakcji z formularzem.

## Typowe scenariusze to formularze kontaktowe, komentarze i rejestracje

Scenariuszem standardowym jest formularz kontaktowy na firmowej stronie. Bez ochrony antyspamowej codziennie w skrzynce redakcji ląduje od 20 do 200 zgłoszeń od botów. mathguard dodaje pole rachunkowe, które jest umieszczane w formularzu między polem e-mail a przyciskiem wysyłki. Zadanie rachunkowe jest generowane losowo przy każdym załadowaniu strony, dzięki czemu boty nie mogą wstępnie obliczyć rozwiązania.

Drugi scenariusz: funkcje komentarzy na blogach i stronach informacyjnych. Gdy odwiedzający mogą zostawiać komentarze pod artykułami, spam jest nieunikniony. mathguard chroni formularz komentarzy bez konieczności posiadania przez odwiedzających konta Google lub specjalnej aplikacji.

Trzeci scenariusz: rejestracje użytkowników. Gdy strona oferuje konta frontendowe (np. dla portalu klienta lub chronionego obszaru pobrań), mathguard chroni formularz rejestracji przed zautomatyzowanym tworzeniem kont. Zadanie rachunkowe to ostatnia przeszkoda przed wysłaniem, dodatkowo do Double-Opt-In.

## Architektura techniczna generuje zadania rachunkowe po stronie serwera z walidacją sesji

mathguard działa całkowicie po stronie serwera. Przy każdym wywołaniu formularza rozszerzenie generuje losowe zadanie rachunkowe (dodawanie, odejmowanie lub mnożenie z liczbami jednocyfrowymi). Poprawne rozwiązanie jest zapisywane w sesji PHP, a nie w kodzie HTML. To kluczowe: gdyby rozwiązanie było ukrytym polem w formularzu, każdy bot mógłby je odczytać.

Integracja z formularzami TYPO3 odbywa się przez ViewHelper lub partial Fluid, który jest wstawiany do istniejących szablonów formularza. Dla powermail i TYPO3 Form Framework istnieją przykłady konfiguracji, które umożliwiają włączenie w 10 do 15 minut.

Zadanie rachunkowe jest prezentowane jako tekst ("ile to jest 5 + 3?"), a nie jako obraz. Dzięki temu jest automatycznie zgodne z czytnikami ekranu: oprogramowanie czytające może przeczytać zadanie, a użytkownik wpisuje rozwiązanie do zwykłego pola tekstowego. Nie ma żadnych zniekształceń wizualnych, żadnych problemów z kontrastem kolorów ani ograniczeń czasowych.

Dla dodatkowego bezpieczeństwa mathguard można połączyć z polem honeypot: niewidocznym polem formularza, które boty wypełniają, ale prawdziwi użytkownicy ignorują. Uzupełniająco można zastosować walidację znacznika czasu: gdy formularz jest wypełniany w czasie poniżej 3 sekund, z dużym prawdopodobieństwem jest to bot. Kombinacja CAPTCHA matematycznego, honeypota i sprawdzania znacznika czasu osiąga redukcję spamu powyżej 99 procent.

## Częste problemy to sprytne boty, utrata sesji i irytacja UX

Problem pierwszy: zaawansowane boty rozwiązujące zadania rachunkowe. Proste boty parsujące tekst mogą zinterpretować "ile to jest 3 + 7?" i podać właściwą odpowiedź "10". Rozwiązanie: prezentować zadanie jako lekko zaciemniony tekst ("trzy plus siedem to?") lub rozszerzyć zadanie o kontekst ("ile nóg ma krzesło minus jedna?"). mathguard w standardowej konfiguracji używa zadań numerycznych, co wystarcza na 85 do 95 procent botów.

Problem drugi: utrata sesji. Gdy sesja PHP zostanie utracona między wywołaniem formularza a wysłaniem (np. przez load balancer bez session stickiness), walidacja zawodzi, chociaż użytkownik wprowadził poprawną odpowiedź. Rozwiązanie: skonfigurować session stickiness w load balancerze lub zapisywać dane sesji w bazie danych zamiast w systemie plików.

Problem trzeci: irytacja UX u użytkowników. Niektórzy odwiedzający odbierają zadanie rachunkowe jako protekcjonalne ("czy muszę udowadniać, że umiem liczyć?"). Rozwiązanie: umieścić przyjazną wskazówkę nad polem ("ochrona antyspamowa: prosimy rozwiązać to krótkie zadanie") i dyskretnie wkomponować zadanie w projekt formularza.

## mathguard działa ze wszystkimi wersjami TYPO3, ponieważ technika jest minimalna

Rozszerzenie nie ma głębokich zależności API od rdzenia TYPO3. Obsługa sesji, renderowanie formularza i walidacja wykorzystują standardowe funkcje PHP i TYPO3, które zmieniają się w niewielkim stopniu między wersjami. mathguard jest kompatybilny z TYPO3 v10, v11 i v12 i prawdopodobnie będzie działać także pod v13, ewentualnie z minimalnymi dostosowaniami w ViewHelperze. Dla projektów, które chcą obyć się zupełnie bez rozszerzenia, tę samą logikę można odtworzyć jako własny walidator w TYPO3 Form Framework lub jako finisher powermail w czasie poniżej godziny. Gosign we własnych projektach wdraża kombinację honeypota, walidacji znacznika czasu i opcjonalnego CAPTCHA matematycznego jako trzystopniową ochronę antyspamową, która obywa się bez usług zewnętrznych i jest skuteczna przeciwko ponad 99 procentom zautomatyzowanych ataków. Decyzję, czy CAPTCHA matematyczne jest widoczne, czy działa tylko jako niewidoczny fallback, podejmujemy projektowo na podstawie oczekiwanej ilości spamu i wymagań dostępności.

--- md_news_author TYPO3 - Autorzy newsów | Gosign ---
> Rozszerzenie autorów dla GeorgRinger/news. Profile autorów, archiwa autorów i Schema.org Person-Markup. Dla stron newsowych z wieloma redaktorami.

## md_news_author daje redaktorom twarz, a wyszukiwarkom schema

GeorgRinger/news to de facto standardowe rozszerzenie systemów redakcyjnych w TYPO3, ale zna tylko proste tekstowe pole autora. Dla stron newsowych z wieloma autorami to nie wystarcza: kto prowadzi poważny magazyn, potrzebuje stron profilowych autorów, strukturalnych biografii i oznaczenia Schema.org/Person dla E-E-A-T. Dokładnie tę lukę wypełnia md_news_author od Mehrwert-Digital i dokładnie dlatego rozszerzenie ląduje prawie w każdym średnim projekcie redakcyjnym TYPO3 w composer.json. Odkąd Google w 2022 zaostrzyło wytyczne E-E-A-T i ocenia profile autorów jako sygnał rankingowy, rozszerzenie nie jest już tylko funkcją komfortu, lecz mierzalnym czynnikiem SEO dla każdej redakcji z więcej niż trzema autorami.

## Typowe scenariusze zastosowania to magazyny online, wydawnictwa fachowe i newsroomy akademickie

Wydawnictwa fachowe są klasyczną grupą docelową. Wydawnictwo prawnicze z 40 autorami chce dla każdego autora własną stronę detalu ze zdjęciem, krótką biografią, obszarami specjalizacji, profilem LinkedIn i listą wszystkich artykułów autora, z powodów SEO i dlatego, że Google nagradza E-E-A-T. md_news_author dostarcza to z jednego rekordu. Dodatkowo rozszerzenie pozwala filtrować autorów po obszarach specjalizacji, dzięki czemu redaktorzy przy badaniach tematycznych bezpośrednio znajdują pasujących ekspertów.

Newsroomy akademickie używają rozszerzenia, aby przypisywać komunikaty z biura prasowego rzeczywistym badaczom. Komunikat prasowy pojawia się pod nazwiskiem danego kierownika katedry, linkuje do jego strony instytutowej i jest sygnalizowany Google przez Person-Schema. Dla cytowań i Google Scholar to nie tylko kosmetyka, lecz czynnik rankingowy. Wdrożyliśmy md_news_author na przykład w instytucie medycznym z 18 zespołami badawczymi, gdzie każdy komunikat prasowy jest przypisywany zaangażowanej grupie roboczej i jej członkom. Rozszerzenie łączy treści newsowe z profilami badaczy i tworzy tym samym strukturalną podstawę dla reputacji naukowej w sieci.

Trzecim scenariuszem są corporate-blogi i formaty thought-leadership, w których zarządy i kadra kierownicza występują jako autorzy. Rozszerzenie czysto rozdziela fe-usera (login) i autora (profil), dzięki czemu biografie mogą być pielęgnowane również dla autorów gościnnych bez konta TYPO3. Dla newsroomów korporacyjnych z konfiguracją ghostwritera to rozdzielenie jest kluczowe: redaktor komunikacji pisze tekst, ale publikuje go pod nazwiskiem kadry kierowniczej, bez konieczności posiadania przez nią loginu backendowego.

## Architektura techniczna rozszerza GeorgRinger/news przez TCA-Overrides

md_news_author jest czystym uzupełnieniem ext:news. Nie przynosi własnej logiki wyjścia, lecz rejestruje przez TCA-Override pole "authors" jako relację do nowej tabeli tx_mdnewsauthor_domain_model_author. Każdy autor to samodzielny rekord z imieniem, nazwiskiem, tytułem, slugiem, biografią, zdjęciem, LinkedIn, X, e-mailem i notatkami wewnętrznymi. Relacja jest typu MM, dzięki czemu artykuł może mieć wielu autorów, a autor może uczestniczyć w dowolnej liczbie artykułów.

Integracja z szablonami Fluid odbywa się przez ViewHelpery: {author.fullName}, {author.jobTitle}, {author.image} i {author.url}. Dla widoków listy i detalu rozszerzenie dostarcza gotowe partiale, które można nadpisać przez system pakietów TypoScript. Slug jest automatycznie generowany z imienia i nazwiska i jest edytowalny. Routing dla stron detalu autorów odbywa się przez wzorzec Enhancer w Site-Config, który umożliwia URL-e jak /autor/jan-kowalski/ bez dodatkowej struktury stron.

Schema.org/Person-Markup jest generowane przez JSON-LD-ViewHelper i może być osadzone w Schema News-Article. Dzięki temu Google-Search rozpoznaje autora, łączy go przez wiele artykułów i dodaje go do otoczenia Knowledge-Graph magazynu. Wyjście ViewHelpera jest kompatybilne z Google Structured Data Testing Tool i pokrywa najważniejsze atrybuty Person: name, jobTitle, image, url, sameAs i worksFor.

## Częste problemy leżą przy storage-pages i konfliktach slugów

Klasyczną pułapką jest konfiguracja Storage-Page. md_news_author oczekuje, że rekordy autorów leżą na wyraźnej stronie typu Sysfolder, która jest wpisana w TypoScript pluginu News. Jeśli brakuje wpisu, plugin nie pokazuje autorów, a redaktorzy się dziwią. Przy konfiguracji zakładamy Sysfolder pod /Konfiguracja/News-Autorzy i odwołujemy się do niego w Plugin-Flex-Form. Przy instalacjach multi-site Sysfolder musi być pielęgnowany oddzielnie dla każdego site, żeby autorzy danej marki pozostawali przypisani.

Drugim częstym błędem są kolizje slugów z innymi tabelami. Gdy obok md_news_author używany jest również ext:sf_register lub własny model osoby, oba często dzielą tę samą strukturę URL. Zalecamy świadomie ustawić prefiks routingu na /autor/ i wpisać generowanie slugów w YAML Site-Config. Alternatywnie Routing-Enhancer może być konfigurowany oddzielnie per język, co jest szczególnie ważne w wielojęzycznych instalacjach z różnymi prefiksami ścieżek ("/author/" EN, "/autor/" PL).

Po trzecie, zdjęcia potrzebują zdefiniowanego rozmiaru obrazu. md_news_author dostarcza wprawdzie referencję FAL, ale warianty croppingu muszą być pielęgnowane w TSconfig pod TCEFORM.tx_mdnewsauthor_domain_model_author.image. Bez tego w szablonie detalu cropping-ViewHelper zawodzi i pokazuje nieobrobione oryginały. Zalecamy zdefiniować co najmniej trzy warianty croppingu (square, portrait, landscape) i dostarczać je responsywnie w szablonie Fluid.

## Migracja na TYPO3 v12 wymaga update Fluid

Dla TYPO3 v11 i v12 md_news_author jest stabilnie dostępne. Przy skoku na v12 własne szablony Fluid muszą być przestawione na nowy namespace ({namespace md=Mehrwert\\MdNewsAuthor\\ViewHelpers}) i przebudowany system ViewHelperów. Kto pochodzi ze starej wersji 2.x, powinien dodatkowo sprawdzić TCA-Overrides, bo niektóre nazwy pól zostały zmienione. Szczególnie pole biografii i linki social-media w nowszych wersjach otrzymały dodatkowe properties, które w starych szablonach byłyby ignorowane.

W trwających projektach Gosign migruje md_news_author zazwyczaj w tym samym kroku co upgrade core News i oznaczenie Schema.org. Dzięki temu strona artykułu pozostaje spójna podczas przejścia, a oznaczenie Person zostaje jednocześnie podniesione do aktualnej specyfikacji Schema.org. W tym samym kroku sprawdzamy, czy profile autorów zawierają pełną listę sameAs ze zweryfikowanymi kontami social-media, bo Google wykorzystuje to połączenie do matchingu Knowledge-Graph.

--- Mega-Menu TYPO3 - Nawigacja | Gosign ---
> Wielokolumnowa nawigacja dropdown z obrazami, teaserami i CTA. Nawigacja enterprise dla złożonych struktur stron.

## Złożone struktury stron z 200 i więcej podstronami potrzebują nawigacji pokazującej więcej niż listy tekstowe

Witryny z trzema lub więcej poziomami nawigacji i ponad 200 podstronami osiągają granice standardowego menu dropdown. Odwiedzający klikają przez zagnieżdżone listy, tracą orientację i rezygnują. Mega-Menu rozwiązuje ten problem: po najechaniu lub kliknięciu głównego punktu otwiera się wielopoziomowy panel z kolumnami, obrazami, teaserami i bezpośrednimi CTA. Rozszerzenie megamenu wnosi tę koncepcję nawigacyjną do TYPO3 jako konfigurowalny element treści. Redaktorzy zarządzają treścią menu (obrazy, teksty teaserów, linki) w backendzie, rozszerzenie renderuje Mega-Menu we frontendzie.

Dla witryn enterprise ze złożonym portfolio produktów, portali branżowych z regionalnymi podsekcjami lub uczelni ze strukturami wydziałów Mega-Menu nie jest opcjonalne, lecz warunkiem użytecznej nawigacji. Wyzwanie leży nie w wyświetlaniu, lecz w dostępności, zachowaniu responsywnym i wydajności.

## Typowe scenariusze to witryny firmowe, e-commerce i portale uczelni

Scenariuszem standardowym jest witryna firmowa z 5 do 8 głównymi kategoriami i 10 do 30 podpunktami w każdej. Producent maszyn pokazuje pod "Produkty" pięć linii produktowych z sześcioma grupami produktów każda, uzupełnione Keyvisualem i linkiem do konfiguratora produktu. Pod "Branże" pojawia się osiem stron branżowych z krótkim tekstem i ikoną. Mega-Menu czyni tę strukturę uchwytną na pierwszy rzut oka, bez konieczności klikania przez podlisty.

Drugi scenariusz: witryny e-commerce z szerokim asortymentem. Sklep internetowy z ponad 500 produktami w 20 kategoriach pokazuje w Mega-Menu główne kategorie z podkategoriami, bestsellerami i linkami akcyjnymi. Prezentacja wizualna ze zdjęciami produktów w menu zwiększa wskaźnik klikalności na strony kategorii szacunkowo o 10 do 20 procent w porównaniu z czystymi listami tekstowymi.

Trzeci scenariusz: portale uczelni ze strukturą wydziałów i instytutów. Uniwersytet z 12 wydziałami i dziesiątkami instytutów potrzebuje nawigacji, która odwzorowuje zarówno strukturę organizacyjną, jak i obszary funkcjonalne (studia, badania, kariera). Mega-Menu pokazuje pod "Studia" wyszukiwarkę kierunków, informacje rekrutacyjne i terminy, pod "Wydziały" instytuty z bezpośrednimi linkami do pracowników i projektów badawczych.

## Architektura techniczna łączy drzewo stron TYPO3 z dodatkowymi elementami treści

Rozszerzenie megamenu rozszerza nawigację TYPO3 o element treści, który jest zakładany w drzewie stron jako konfiguracja menu. Każdy główny punkt menu może otrzymać przypisany panel Mega-Menu składający się z kolumn. Każda kolumna zawiera linki, obrazy, bloki Rich-Text lub niestandardowe elementy treści.

Logika renderowania generuje konstrukcję HTML z zagnieżdżonych list i kontenerów div, która jest stylizowana przez CSS jako wielopoziomowy panel. Komponent JavaScript steruje otwieraniem i zamykaniem (hover na desktopie, klik na urządzeniach dotykowych) oraz nawigacją klawiaturową (Tab, Enter, Escape, strzałki). Atrybuty ARIA (aria-expanded, aria-haspopup, role="menu") czynią menu nawigowalnym dla czytników ekranu.

Implikacja wydajnościowa jest istotna: Mega-Menu z obrazami i teaserami dla 8 głównych punktów generuje znacznie więcej HTML niż standardowe menu. Lazy Loading dla obrazów w Mega-Menu jest obowiązkowy, aby początkowy czas ładowania strony nie ucierpiał. Gosign zaleca doładowywanie treści Mega-Menu dopiero przy najechaniu przez AJAX, gdy panel zawiera więcej niż 5 obrazów na punkt główny.

## Częste problemy dotyczą dostępności, zachowania mobilnego i złożoności redakcyjnej

Problem pierwszy: braki w dostępności. Wiele implementacji Mega-Menu nie jest nawigowalnych klawiaturą. Tab przeskakuje przez cały panel zamiast iterować po punktach menu. Escape nie zamyka panelu. Brakuje stylów fokusu. Rozwiązanie: stosować WAI-ARIA Authoring Practices dla Navigation Menus, wyraźnie zaimplementować obsługę klawiatury i przetestować logikę zarządzania fokusem z czytnikiem ekranu (NVDA, VoiceOver).

Problem drugi: zachowanie mobilne. Na smartfonach Mega-Menu staje się przeszkodą, ponieważ panel zajmuje cały ekran, a odwiedzający nie może już wrócić do treści strony. Rozwiązanie: na urządzeniach mobilnych zastąpić Mega-Menu nawigacją akordeonową, która przedstawia te same treści w strukturze pionowej. Przełączanie odbywa się przez CSS Media Queries i osobną logikę JavaScript dla urządzeń dotykowych.

Problem trzeci: złożoność redakcyjna. Redaktorzy muszą zarządzać obrazami, tekstami i linkami dla każdego panelu Mega-Menu. Bez jasnych wytycznych powstają niespójne panele: jeden ma cztery kolumny z obrazami, następny jedną kolumnę z 30 linkami. Rozwiązanie: wytyczne treści, które definiują maksymalną liczbę kolumn, formaty obrazów i długości tekstów na panel. Gosign dostarcza te wytyczne jako część projektu Mega-Menu i konfiguruje pola backendu tak, aby redaktorzy pracowali w zdefiniowanych granicach (np. maksymalnie 4 kolumny, maksymalnie 8 linków na kolumnę, format obrazu 16:9).

Kolejnym tematem są implikacje SEO: Mega-Menu z wieloma linkami zwiększa łączną liczbę linków wewnętrznych na stronie. Gdy każda strona ma 200 i więcej linków w Mega-Menu, rozwadnia to Link-Juice płynący do poszczególnych stron docelowych. Rozwiązanie: wybiórczo ładować treści Mega-Menu i nie renderować wszystkich paneli jednocześnie w HTML lub strategicznie wykluczać mniej istotne linki z nawigacji crawlera przez tabindex="-1".

## TYPO3 v12 wymaga dostosowań, własne implementacje są długoterminowo łatwiejsze w utrzymaniu

Rozszerzenie megamenu trzeba dostosować przy aktualizacji do TYPO3 v12, ponieważ zmieniła się konfiguracja TCA i obsługa elementów treści. Dla v13 nie ma jeszcze oficjalnego wsparcia. Gosign w nowych projektach buduje Mega-Menu jako własny komponent w Site-Package, który wykorzystuje drzewo stron TYPO3 jako źródło danych i steruje konfiguracją menu przez Page Properties lub Backend Layouts. Eliminuje to zależność od rozszerzenia i daje pełną kontrolę nad strukturą HTML, dostępnością i wydajnością.

--- Microtemplate TYPO3 | Gosign ---
> Mikro-silnik szablonów dla TYPO3: Małe bloki tekstowe z podstawianiem zmiennych. Prostsze niż Fluid dla prostych zadań string-templating.

## Fluid bywa przesadą, gdy chcemy tylko wypełnić łańcuch znaków zmiennymi

Nie każdy problem szablonowy wymaga pełnego silnika Fluid. Gdy temat wiadomości e-mail ma brzmieć "Witaj {imie}, Twoje zamówienie #{orderNumber}" lub snippet w stopce ma wyświetlać "Ostatnia aktualizacja: {date}", Fluid z ViewHelperami, layoutami i partialami jest nadmiarem architektonicznym. microtemplate dostarcza minimalny silnik szablonów dla TYPO3, który zastępuje zmienne w blokach tekstowych. Żadnego Fluid, żadnej ścieżki obiektu TypoScript, żadnego pliku szablonu. Łańcuch znaków z placeholderami, tablica z wartościami, gotowe.

Rozszerzenie jest niszowym narzędziem dla programistów, którzy w rozszerzeniach lub konfiguracjach TypoScript potrzebują prostych podstawień łańcuchów znaków bez uruchamiania pipeline'u renderowania Fluid. Dla redaktorów microtemplate nie jest bezpośrednio widoczny, działa w tle jako narzędzie pomocnicze. Zakres zastosowania jest celowo wąski: tam gdzie Fluid jest właściwym wyborem dla złożonych szablonów z pętlami, warunkami i dziedziczeniem, microtemplate pokrywa prosty przypadek, w którym gotowy łańcuch znaków w trzech miejscach potrzebuje wartości dynamicznej.

## Typowe scenariusze to teksty mailowe, dynamiczne snippety i szablony konfiguracyjne

Najczęstszym scenariuszem jest generowanie tekstów e-mail w rozszerzeniach. Własne rozszerzenie wysyła maile potwierdzające, a temat i treść mają być konfigurowalne bez konieczności zakładania przez programistę szablonów Fluid. microtemplate odczytuje tekst ze stałej TypoScript ("Zamówienie #{orderNumber} potwierdzone") i zastępuje placeholdery aktualnymi wartościami.

Drugi scenariusz: dynamiczne snippety tekstowe w konfiguracjach TypoScript. Wzorzec tytułu strony taki jak "{siteName} - {pageTitle} | {category}" jest rozwiązywany przez microtemplate. Jest to prostsze niż COA z kilkoma obiektami TEXT i funkcjami stdWrap.

Trzeci scenariusz: szablony konfiguracyjne dla integracji zewnętrznych. Gdy rozszerzenie czyni endpoint API konfigurowalnym ("https://api.example.com/{version}/users/{userId}"), microtemplate może zastąpić placeholdery przed wywołaniem API. Jest to szczególnie przydatne dla rozszerzeń, które obsługują kilka środowisk API (staging, produkcja) i chcą zarządzać strukturą endpointu nie w kodzie, lecz w konfiguracji TypoScript.

Czwarty scenariusz, który pojawia się w praktyce: komunikaty logów w ustrukturyzowanym formacie. Rozszerzenie zapisuje "Import {count} rekordów z {source} zakończony o {time}" do loga TYPO3. microtemplate czyni tekst loga konfigurowalnym, bez konieczności utrzymywania przez programistę wywołań sprintf z argumentami opartymi na pozycji.

## Architektura techniczna to jedna klasa PHP z zastępowaniem łańcuchów znaków

microtemplate w rdzeniu składa się z jednej klasy PHP, która wykonuje str_replace lub preg_replace na łańcuchu szablonu. Placeholdery stosują definiowalną składnię (standard: {variableName}). Tablica asocjacyjna dostarcza wartości. Klasa nie ma zależności poza obsługą łańcuchów znaków PHP.

Integracja z TYPO3 odbywa się przez serwis lub metodę statyczną, która jest wywoływana w innych rozszerzeniach lub konfiguracjach TypoScript. Nie ma pluginu frontendowego, modułu backendowego ani elementu treści. microtemplate to czysta infrastruktura dla programistów.

Wydajność jest pomijalna: str_replace na łańcuchu 500 znaków z 5 zmiennymi trwa poniżej 0,01 ms. Dla porównania: silnik Fluid dla tego samego wyniku uruchamia pełny cykl renderowania z parsowaniem szablonu, instancjonowaniem ViewHelperów i cache, co zajmuje 1 do 5 ms. W typowym procesie renderowania strony ta różnica jest niezauważalna, ale w pętlach generujących 1000 maili lub 500 wpisów loga przewaga wydajnościowa staje się mierzalna.

Rozszerzenie nie ma tabel bazy danych, modułów backendowych ani pluginów frontendowych. Instaluje się je przez Composer lub Extension Manager i jest od razu gotowe do użycia. To czyni microtemplate jednym z najlżejszych rozszerzeń w całym TER (TYPO3 Extension Repository).

## Częste problemy to brak logiki escaping, konflikty składni i niewystarczająca dokumentacja

Problem pierwszy: brak automatycznego HTML-escaping. microtemplate zastępuje placeholdery 1:1, bez escape'owania wstawianej wartości. Gdy nazwa użytkownika zawiera znaczniki HTML ("<script>alert('XSS')</script>"), zostaje to bezpośrednio zapisane w wyjściu. Rozwiązanie: escape'ować wartości ręcznie przed wstawieniem (htmlspecialchars) lub używać microtemplate tylko dla wewnętrznych, niegenerowanych przez użytkownika danych.

Problem drugi: konflikty składni z Fluid. Gdy placeholdery microtemplate ({variable}) są używane w kontekście, w którym renderuje także Fluid, Fluid próbuje rozwiązać placeholdery i zgłasza błąd. Rozwiązanie: używać innej składni placeholderów (np. {{variable}} lub %variable%) lub zapewnić, aby microtemplate był wykonywany przed Fluid.

Problem trzeci: niedostateczna dokumentacja i wsparcie społecznościowe. microtemplate to niszowe rozszerzenie z minimalną bazą użytkowników. Przy problemach nie ma aktywnej społeczności, śledzenia zgłoszeń ani odpowiedzi na Stack Overflow. Programiści muszą czytać kod źródłowy, aby zrozumieć zachowanie. W praktyce prowadzi to do tego, że każdy programista w zespole używa rozszerzenia inaczej, ponieważ nie są udokumentowane żadne konwencje.

Kolejny temat: debugowanie. Gdy placeholder nie jest zastępowany, ponieważ klucz w tablicy nie zgadza się dokładnie z nazwą placeholdera (wielkość liter, spacje), microtemplate nie wyświetla ostrzeżenia. Placeholder po prostu pozostaje, a programista szuka błędu w niewłaściwym miejscu. Tryb debug, który logowałby nierozwiązane placeholdery, byłby pomocny, ale go brakuje.

## Rozszerzenie jest niezależne od wersji TYPO3, ale dla nowoczesnych projektów są lepsze alternatywy

Ponieważ microtemplate używa tylko standardowych funkcji PHP, rozszerzenie zasadniczo działa z każdą wersją TYPO3 od v7 do v13. Pytanie brzmi raczej, czy jest jeszcze potrzebne: od PHP 8.0 Named Arguments w kombinacji z sprintf lub str_replace oferują tę samą funkcjonalność bez rozszerzenia. Dla bardziej złożonych szablonów Fluid mimo nadmiaru jest lepszym wyborem, ponieważ wnosi cache, escape'owanie i dziedziczenie szablonów. Gosign nie stosuje aktywnie microtemplate w projektach istniejących i zaleca przy nowych implementacjach odwzorowanie funkcjonalności bezpośrednio we własnym rozszerzeniu lub w TypoScript przez stdWrap.

--- news TYPO3 - Blog i aktualności | Gosign ---
> tx_news Georga Ringera: Najpopularniejsze rozszerzenie TYPO3. Aktualności, blog, komunikaty prasowe. Aktualizacja, migracja, szablony. Wspomagane AI.

## tx_news to rozszerzenie, bez którego nie obywa się żaden projekt TYPO3

Ponad 80 procent wszystkich instalacji TYPO3 korzysta z tx_news autorstwa Georga Ringera. Sama ta liczba byłaby już imponująca, ale nie oddaje znaczenia rozszerzenia: tx_news nie jest tylko pluginem newsowym, lecz fundamentem dla blogów, magazynów, sekcji prasowych, list wydarzeń, katalogów pracowników i każdego innego rodzaju ustrukturyzowanej, chronologicznej treści w TYPO3. Rozszerzenie dostarcza kategorie, tagi, zasoby multimedialne, pola SEO (canonical, OpenGraph, Schema.org), paginację oraz import/eksport z jednej aktywnie utrzymywanej bazy kodu. Kto publikuje treści redakcyjne w TYPO3, nie ominie tx_news.

Gosign skonfigurował, rozszerzył i zmigrował tx_news w setkach projektów. Od szablonów Fluid przez własne ViewHelpery po pełną migrację z tt_news. Rozszerzenie jest stałym elementem każdego setupu TYPO3, który dostarczamy.

## Typowe scenariusze sięgają od firmowego bloga po bazę danych prasy

Najczęstszym scenariuszem jest blog firmowy lub magazyn online. Redaktorzy zarządzają artykułami w backendzie TYPO3 z tytułem, teaserem, treścią, kategoriami, tagami i mediami. Widok listy pokazuje teasery z obrazem, widok szczegółowy pełny artykuł. Istotne dla SEO pola takie jak meta-opis, canonical URL i obraz OpenGraph są uzupełniane dla każdego artykułu. Typowa instalacja ma od 100 do 5000 artykułów i rośnie o 2 do 10 artykułów tygodniowo.

Drugi scenariusz: komunikaty prasowe dla Investor Relations i komunikacji korporacyjnej. Spółki giełdowe i koncerny publikują obowiązkowe komunikaty przez sekcję prasową swojej strony. tx_news dostarcza chronologię, kategoryzację (raport bieżący, raport kwartalny, komunikat personalny) i funkcję pobierania dla załączonych PDF-ów. Funkcja archiwum zapewnia, że także komunikaty sprzed dziesięciu lat są nadal dostępne do wyszukania.

Trzeci scenariusz: listy wydarzeń i kalendarze. tx_news potrafi zarządzać datami początkowymi i końcowymi wpisów, co czyni go prostym kalendarzem wydarzeń. Dla stowarzyszeń, instytucji kulturalnych i placówek edukacyjnych często to wystarcza, bez konieczności stosowania wyspecjalizowanego rozszerzenia eventowego takiego jak sf_event_mgt. Dopiero gdy potrzebne są funkcje zapisu, zarządzania uczestnikami czy sprzedaży biletów, tx_news osiąga swoje granice.

## Architektura techniczna konsekwentnie oddziela dane, konfigurację i prezentację

tx_news przechowuje artykuły jako rekordy Extbase w tabeli tx_news_domain_model_news. Każdy rekord zawiera pola obowiązkowe (tytuł, datetime, typ) i opcjonalne (teaser, treść, autor, tagi, kategorie, media, powiązane news). Relacje z kategoriami i tagami biegną przez tabele MM, co umożliwia wydajne filtrowanie.

Konfiguracja odbywa się przez TypoScript: ścieżki szablonów, sortowanie, paginacja, filtry kategorii, PID strony szczegółów i ustawienia SEO. Rozszerzenie dostarcza rozbudowany zestaw stałych TypoScript, który pokrywa większość konfiguracji bez własnego kodu. Dla wymagań niestandardowych (np. slider na stronie startowej pokazujący trzy najnowsze newsy) istnieją ViewHelpery, których można używać w szablonach Fluid.

Szablony Fluid dla list, szczegółów, kategorii i menu dat są nadpisywalne przez ścieżki TypoScript. W praktyce kopiuje się standardowe szablony do własnego Site-Package i dostosowuje strukturę HTML i klasy CSS do identyfikacji wizualnej. To oddzielenie umożliwia aktualizację rozszerzenia bez nadpisywania własnych modyfikacji.

Wydajność przy prawidłowej konfiguracji jest dobra: widok listy korzysta z page cache TYPO3, widok szczegółów cache'uje się dla każdego UID artykułu. Dopiero przy zasobach news powyżej 10 000 artykułów ze złożonymi filtrami kategorii i wyszukiwaniem pełnotekstowym wydajność staje się tematem. W takich przypadkach zaleca się indeks wyszukiwania przez ke_search lub Solr.

## Częste problemy dotyczą konfiguracji SEO, wydajności i migracji z tt_news

Problem pierwszy: brakujące lub błędne canonical URL. Bez prawidłowej konfiguracji ten sam artykuł jest osiągalny przez kilka URL-i: przez ścieżkę kategorii, ścieżkę archiwum i link bezpośredni. Google indeksuje wszystkie warianty jako osobne strony, co prowadzi do Duplicate Content. Rozwiązanie: wyraźnie ustawić PID strony szczegółów i skonfigurować canonical URL w ustawieniach TypoScript na stronę szczegółów. Rozszerzenie newscanonical dodatkowo adresuje ten problem.

Problem drugi: spadki wydajności przy dużych zasobach news. Gdy widok listy musi przeszukać ponad 5000 artykułów, rosną czasy zapytań do bazy danych. Rozwiązanie: ograniczenia oparte na kategoriach w konfiguracji TypoScript, paginacja z maksymalnie 20 artykułami na stronę i indeksy bazy danych na relacjach kategorii.

Problem trzeci: migracja z tt_news. Legacy rozszerzenie tt_news nie jest kompatybilne od TYPO3 v8. Migracja danych do tx_news wymaga mapowania pól (tt_news_cat do sys_category, szablony Marker do szablonów Fluid) i strategii przekierowań URL, aby zachować istniejące rankingi Google. Gosign używa do tego analizy szablonów wspieranej AI: nasze narzędzia czytają stare szablony Marker, identyfikują używane pola i generują szablony Fluid, które produkują ten sam wynik.

## tx_news w pełni obsługuje TYPO3 v12 i v13

Georg Ringer aktywnie utrzymuje tx_news i przy każdym wydaniu TYPO3 LTS szybko dostarcza kompatybilną wersję. Aktualna seria obsługuje TYPO3 v11, v12 i v13 równolegle. Przy aktualizacji z v10 lub v11 do v12 Breaking Changes dotyczą przede wszystkim własnych ViewHelperów, które muszą zostać przełączone na aktualne API Fluid, oraz konfiguracji TypoScript, które powinny zostać zmigrowane do nowej składni SiteSet. Struktura rekordów pozostaje stabilna, migracja danych nie jest konieczna. Gosign wykonuje aktualizacje tx_news zwykle w ramach aktualizacji rdzenia TYPO3 i sprawdza przy tym własne szablony, ViewHelpery i nadpisania TypoScript pod kątem kompatybilności. Dla projektów z rozbudowanymi dostosowaniami (pola własne, własne ViewHelpery, integracja z systemami trzecimi) przed aktualizacją tworzymy macierz kompatybilności, która dokumentuje wszystkie zależności i realistycznie szacuje nakład migracji. Analiza kodu wspierana AI znacząco przyspiesza ten proces, identyfikując wszystkie miejsca w projekcie dotknięte zmianami API.

--- news_podcast TYPO3 - Plugin podcastowy | Gosign ---
> Funkcjonalność podcastowa dla GeorgRinger/news. Feed RSS z tagami kompatybilnymi z iTunes, integracja odtwarzacza audio, zarządzanie odcinkami.

## news_podcast czyni z systemu news hosta podcastów

Kto pielęgnuje w TYPO3 wpisy news i równolegle produkuje podcast, stoi przed decyzją: albo używa zewnętrznego hosta podcastów (Podigee, Podcaster, Anchor) i linkuje do strony, albo dostarcza feed podcastu bezpośrednio z TYPO3. news_podcast umożliwia drugą opcję: rozszerzenie rozszerza GeorgRinger/news o pola i szablony Fluid dla plików audio i generuje kompatybilny z iTunes feed RSS, który Apple Podcasts, Spotify i Google Podcasts importują bez objazdów. Dla firm, które chcą zachować suwerenność nad contentem i plikami audio, to istotna opcja architektoniczna. Unika zależności od platformy, zachowuje statystyki użytkowania we własnym domu i dostarcza content w tym samym kontekście CMS, w którym żyją wpisy news i magazyn.

## Typowe scenariusze zastosowania leżą przy corporate-podcastach i ofertach edukacyjnych

Podcasty firmowe są najczęstszym scenariuszem. Średnia firma przemysłowa produkuje co dwa tygodnie odcinek z gośćmi z branży i chce osadzać odcinki w corporate-blogu, zgłaszać do Apple Podcasts i jednocześnie publikować skuteczne SEO-wo wpisy news z transkryptem i shownotes. news_podcast pokrywa te trzy potrzeby w jednym rekordzie, bez konieczności pielęgnowania przez redakcję w trzech różnych systemach. Dobrze pielęgnowany rekord podcastu automatycznie tworzy wpis news, wpis feed RSS i oznaczenie Schema.org/PodcastEpisode.

Drugim scenariuszem są uczelnie i dostawcy edukacji. Wykłady są nagrywane jako pliki audio i przechowywane na serwerze kampusu. Przez news_podcast pojawiają się jako odcinki serii wykładów, z rozdziałami, transkryptem i odnośnikami literaturowymi. Feed jest zgłaszany do Apple Podcasts i Spotify, a dostęp odbywa się bezpośrednio przez stronę TYPO3, bez konieczności używania przez studentów dodatkowego portalu. Szczególnie w czasach z wysokim udziałem e-learningu to zauważalna przewaga nad platformami stron trzecich, które przynoszą dodatkowe konta i tracking.

Trzecim scenariuszem są stowarzyszenia i organizacje polityczne, które oferują cotygodniowe wywiady lub spotkania prasowe jako podcast. Chodzi tu przede wszystkim o suwerenność: wszystkie dane leżą we własnej infrastrukturze, a statystyka grupy docelowej pochodzi z własnego logu serwera, a nie z dashboardu strony trzeciej. Dla organizacji z wysoką wrażliwością wobec usług trackingowych to często czynnik decydujący przeciwko zewnętrznym hostom podcastów.

## Architektura techniczna rozszerza model news o atrybuty podcastu

news_podcast rejestruje nowy zestaw pól przez TCA-Override dla tx_news_domain_model_news. Dla artykułu dostępne są dodatkowe pola: plik audio (referencja FAL), czas trwania, odcinek, sezon, typ (Full, Trailer, Bonus), flaga explicit i transkrypt. Przez kolejny override kategoria news jest uzupełniana o pole Podcast-Channel, z iTunes-Category, Cover-Art, autorem, Owner-Email i językiem.

Feed RSS jest dostarczany przez własny kontroler TYPO3. Ścieżka jest konfigurowalna i tworzy RSS 2.0 z rozszerzeniami iTunes-Namespace. Każdy odcinek zawiera tagi obowiązkowe dla enclosure, duration, episode, episodeType i explicit. Walidacja odbywa się przy Apple-Podcasts-Feed-Validator i castfeedvalidator.com. Bez ważnej walidacji Apple Podcasts odmawia przyjęcia feedu, a Spotify nie pokazuje kanału w wynikach wyszukiwania.

Wyjście frontendowe wykorzystuje partiale Fluid, które można nadpisać przez package-overlay. Standardowe wyjście osadza odtwarzacz audio HTML5 i renderuje shownotes w tekście głównym szablonu detalu news. Dla wyjścia transkryptu używany jest oddzielny obszar partial, który jest udostępniany przez system zakładek lub akordeon. Kto chce z powodów SEO mieć transkrypty jako pełny widok w DOM, nadpisuje partial i renderuje cały tekst inline.

## Częste problemy dotyczą walidacji feedu, enclosures i streamingu

Najczęstszym tematem wsparcia jest walidacja iTunes Feed. Apple Podcasts odrzuca feedy, gdy Cover-Art nie spełnia wymagań (co najmniej 1400x1400px, maksymalnie 3000x3000px, JPEG lub PNG, sRGB) lub gdy tag <enclosure> nie zawiera podania MIME-Type. W praktyce pierwsze zgłoszenie często zawodzi na proporcjach Cover-Art, a nie na samym rozszerzeniu.

Drugim tematem są rozmiary plików i streaming. Pliki audio w jakości podcastowej (128 kbit MP3) mają per odcinek 30 do 60 MB. Kto dostarcza te pliki bezpośrednio ze storage TYPO3, przenosi całe obciążenie na serwer WWW, co przy tysiącach słuchaczy na odcinek staje się hamulcem. Zalecamy wyprowadzić pliki audio na oddzielny storage (kompatybilny z S3, CDN) i osadzić przez FAL-Remote-Storage. Dzięki temu serwer TYPO3 pozostaje odpowiedzialny za dostarczanie contentu, podczas gdy obciążenie audio ląduje na tańszej warstwie storage.

Po trzecie, Google Podcasts wymaga znaczącego, trwałego URL per odcinek. Rozszerzenie generuje to automatycznie ze slugu news, ale routing musi być zwolniony w Site-Config dla kontrolera podcast, inaczej TYPO3 tworzy URL-e typolink z querystringiem, których Google Podcasts nie akceptuje.

## Migracja na TYPO3 v12 wymaga synchronicznego upgrade News-Core

news_podcast jest dostępne dla TYPO3 v11, v12 i v13, wymaga jednak kompatybilnej wersji GeorgRinger/news. Przy skoku na TYPO3 v12 oba rozszerzenia muszą być synchronicznie aktualizowane: news na serię v12 i news_podcast na pasującą wersję major. Struktura bazy danych pozostaje stabilna, referencje FAL audio wędrują bez objazdów.

Gosign migruje news_podcast zazwyczaj jako część refactoringu content-hub. W tym samym kroku sprawdzamy, czy transkrypty mogą być rozszerzone o dane strukturalne, czy Cover-Art odpowiada aktualnym wytycznym Apple i czy kontroler feedu jest zabezpieczony rate-limitem. Dla większych podcastów rozszerzamy rozszerzenie o własny model hostów, dzięki czemu można zarządzać gośćmi ze stroną profilową i backlinkiem. W kombinacji z md_news_author można w ten sposób pielęgnować podcasterów i gości równolegle jako profile autorów, co wyraźnie poprawia oznaczenie Schema.org i wewnętrzne linkowanie.

--- tt_news Migracja TYPO3 | Gosign ---
> Rozszerzenie migracyjne z tt_news na GeorgRinger/news. Przenosi dane, kategorie, obrazy i relacje. Standardowa ścieżka migracji przy aktualizacjach TYPO3.

## Kto jeszcze używa tt_news, blokuje każdą aktualizację TYPO3 od wersji 10

tt_news był przez ponad dekadę standardowym rozszerzeniem do aktualności, komunikatów prasowych i wpisów blogowych w TYPO3. Tysiące stron zostało z nim zbudowanych, niektóre z setkami lub tysiącami artykułów. Problem: tt_news było ostatnio oficjalnie wspierane dla TYPO3 v7. Od TYPO3 v8 (2017) nie ma kompatybilnego wydania. Kto nadal ma tt_news w użyciu, siedzi na przestarzałej wersji TYPO3 i nie może korzystać ani z aktualizacji bezpieczeństwa, ani z nowych funkcji.

Oficjalnym następcą jest GeorgRinger/news (w skrócie: EXT:news), rozwijane od 2012 roku. news to najczęściej instalowane rozszerzenie TYPO3 (ponad 250 000 aktywnych instalacji, stan 2026), wspierające TYPO3 v11, v12 i v13. news_ttnewsimport to rozszerzenie migracyjne automatyzujące przejście: artykuły, kategorie, obrazy, Related News i odwołania do stron są przenoszone z tt_news do EXT:news.

## Typowe scenariusze zastosowań

**Aktualizacja TYPO3 z v7/v8/v9 na v12 lub v13.** Najczęstszy przypadek: firma prowadzi stronę TYPO3 na v7 lub v9, z 500 do 5000 artykułami w tt_news. Planowana aktualizacja do v12 LTS nie udaje się z powodu tt_news, bo rozszerzenie nie jest kompatybilne. news_ttnewsimport przenosi wszystkie dane do struktury EXT:news, dzięki czemu aktualizacja może być kontynuowana.

**Relaunch z istniejącymi danymi.** Przy relaunchu strony design ma być zupełnie nowy, ale istniejące artykuły mają być zachowane. Artykuły przez lata zbudowały wartość SEO (backlinki, indeksacja, pozycje). Nowy start bez migracji zniszczyłby tę wartość. news_ttnewsimport zachowuje treści, EXT:news dostarcza nowoczesną technikę.

**Środowiska Multi-Site ze wspólną bazą aktualności.** Koncerny z 5 do 20 instancjami TYPO3 pielęgnujące aktualności centralnie i wyświetlające je na wszystkich witrynach. Migracja musi przebiegać skoordynowanie: najpierw migracja centralnej bazy danych, potem dostosowanie szablonów na wszystkich witrynach.

## Architektura techniczna

news_ttnewsimport to rozszerzenie oparte na CLI, działające przez TYPO3 Command Controller. Proces migracji przebiega w pięciu krokach. Najpierw kategorie tt_news (tt_news_cat) są przekształcane w wpisy sys_category. Hierarchia kategorii (Parent-Child) jest zachowywana. Następnie migrowane są same rekordy aktualności: tytuł, teaser, bodytext, autor, data, typ, data archiwum i status Hidden/Deleted. W trzecim kroku obrazy i media są konwertowane ze starej struktury przechowywania na referencje FAL. Czwarty krok migruje Related News jako relacje. W ostatnim kroku aktualizowane są elementy treści na stronach aktualności: pluginy tt_news są zastępowane pluginami EXT:news.

## Częste problemy i rozwiązania

**Brak obrazów po migracji.** tt_news przechowywało obrazy jako nazwy plików w polu tekstowym (np. "obraz1.jpg,obraz2.jpg"), pliki leżały w uploads/pics/. EXT:news używa FAL. Jeśli fizyczne pliki nie znajdują się już w oczekiwanym katalogu, migracja obrazów nie udaje się. Rozwiązanie: przed migracją sprawdzić, czy wszystkie odwołane obrazy fizycznie istnieją.

**Przypisania kategorii giną.** tt_news korzystało z własnych tabel kategorii (tt_news_cat), EXT:news używa sys_category. Jeśli migracja nie mapuje prawidłowo identyfikatorów kategorii, artykuły tracą przypisania. Rozwiązanie: news_ttnewsimport tworzy mapowanie (stary ID na nowy ID) i aktualizuje wszystkie odwołania.

**Struktura URL zmienia się, pozycje SEO spadają.** Artykuły tt_news miały URL jak `/news/detail/tytuł-artykulu/`. EXT:news domyślnie generuje `/news/tytuł-artykulu/`. Rozwiązanie: skonfigurowanie przekierowań 301 ze starych na nowe URL. Przy 1000 artykułach to ręcznie niemożliwe. Gosign automatycznie generuje mapę przekierowań ze starych i nowych struktur URL.

## Migracja i kompatybilność wersji

news_ttnewsimport wspiera migrację do EXT:news na TYPO3 v11 i v12. Zalecany przebieg: najpierw aktualizacja TYPO3 do v11 (jeśli z v7/v8/v9, stopniowo), potem uruchomienie news_ttnewsimport, potem aktualizacja do v12 lub v13.

Dla bardzo dużych zbiorów danych (ponad 10 000 artykułów) Gosign zaleca przeprowadzenie migracji na systemie staging i sprawdzenie wyniku, zanim produkcja zostanie przełączona. Sama migracja trwa od 30 minut (500 artykułów) do 4 godzin (10 000 artykułów z obrazami). Dostosowanie szablonów (szablony Fluid dla nowego wyjścia EXT:news) to oddzielny nakład, typowo 2 do 5 dni.

Często niedocenianym aspektem migracji tt_news jest komunikacja z wyszukiwarkami. Google zaindeksowało stare URL i je ocenia. Jeśli po migracji 500 URL prowadzi donikąd (404), strona traci pozycje rankingowe. Gosign dlatego po każdej migracji konfiguruje monitoring przekierowań: tydzień po uruchomieniu dane Google Search Console są sprawdzane pod kątem błędów 404, brakujące przekierowania są uzupełniane.

--- newscanonical TYPO3 - Canonical dla newsów | Gosign ---
> newscanonical: Prawidłowe tagi Canonical dla TYPO3 News. Unikanie Duplicate Content. Optymalizacja SEO.

## Duplicate Content przez brakujące tagi Canonical kosztuje strony TYPO3 z newsami rankingi

Artykuł tx_news jest często dostępny przez trzy lub więcej URL-i: przez ścieżkę kategorii (/news/marketing/tytul-artykulu), przez archiwum (/news/2025/03/tytul-artykulu) i przez bezpośredni link (/news/tytul-artykulu). Dla odwiedzających nie robi to różnicy, dla Google jest to problem. Google widzi trzy osobne strony z identyczną treścią i musi zdecydować, która jest "właściwa". Bez tagu Canonical wskazującego preferowany URL Google rozdziela sygnały rankingowe na wszystkie warianty i osłabia każdy z nich. newscanonical rozwiązuje ten problem dla tx_news, generując na każdej stronie szczegółowej news tag Canonical wskazujący na definitywny URL.

Rozszerzenie jest skupionym narzędziem SEO, które wykonuje dokładnie jedno zadanie: zapobiega Duplicate Content w tx_news. Dla witryn z ponad 100 artykułami news może to oznaczać różnicę między stroną 1 a stroną 3 w Google.

## Typowe scenariusze dotyczą stron informacyjnych, magazynów i sekcji prasowych

Scenariuszem standardowym jest firmowa strona z sekcją news lub blog. Firma publikuje co tydzień artykuły uporządkowane w kategoriach (produkty, branże, wydarzenia). Każdy artykuł pojawia się na liście kategorii i w ogólnym archiwum. Bez newscanonical Google indeksuje każdy wariant URL osobno, co przy 500 artykułach może prowadzić do 1500 zaindeksowanych stron z Duplicate Content. Google Search Console pokazuje to jako "Strona zduplikowana, wybrany przez Google kanoniczny URL odbiega od wskazanego przez użytkownika".

Drugi scenariusz: magazyny online z widokami list opartymi na tagach i kategoriach. Magazyn ma 20 kategorii i 50 tagów. Każdy artykuł ma co najmniej jedną kategorię i dwa do trzech tagów. Kombinatoryka generuje dziesiątki możliwych ścieżek URL na artykuł. newscanonical konsoliduje wszystkie warianty do jednego canonical URL.

Trzeci scenariusz: sekcje prasowe spółek giełdowych. Obowiązkowe komunikaty muszą być dostępne trwale i nie mogą wypadać z wyników wyszukiwania Google przez problemy z Duplicate Content. Prawidłowy tag Canonical zapewnia, że Google indeksuje definitywną wersję.

## Architektura techniczna umieszcza tag link w nagłówku HTML każdej strony szczegółowej news

newscanonical rejestruje się w pipeline'ie renderowania tx_news i wstawia w nagłówku HTML strony szczegółowej tag `<link rel="canonical" href="...">`. Canonical URL jest obliczany z skonfigurowanego PID strony szczegółów i UID newsa, niezależnie od tego, którą ścieżką odwiedzający dotarł do strony.

Konfiguracja odbywa się przez TypoScript: PID strony szczegółów ustawiany jest jako baza dla canonical URL. Opcjonalne parametry takie jak struktura URL (RealURL lub TYPO3 Site Handling) i włączenie segmentów kategorii do canonical URL są sterowane przez stałe.

Rozszerzenie działa jako hook w pipeline'ie renderowania tx_news, a nie jako samodzielny plugin. Oznacza to: nie ma własnego wyjścia frontendowego ani własnego elementu treści. Jedynym widocznym efektem jest tag Canonical w źródle HTML, który czytają wyszukiwarki, ale odwiedzający nigdy nie widzą.

Dla prawidłowego działania PID strony szczegółów w konfiguracji tx_news i w konfiguracji newscanonical muszą się zgadzać. Gdy tx_news używa kilku stron szczegółów (np. po jednej dla kategorii), newscanonical musi być odpowiednio skonfigurowany, aby canonical URL wskazywał właściwą stronę szczegółów.

## Częste problemy to błędna konfiguracja PID, konflikty z Core-Canonical i pętle przekierowań

Problem pierwszy: błędny PID strony szczegółów. Gdy PID w konfiguracji newscanonical nie zgadza się z konfiguracją tx_news, tag Canonical wskazuje na stronę, która w ogóle nie potrafi wyświetlić artykułu. Google ignoruje wtedy tag Canonical i sam wybiera wariant. Rozwiązanie: sprawdzić spójność PID i w Google Search Console porównać zaindeksowane canonical URL ze skonfigurowanymi.

Problem drugi: konflikty z Core-Canonical TYPO3. Od TYPO3 v10 Core ma własne generowanie canonical URL przez rozszerzenie systemowe seo. Gdy oba są aktywne, w nagłówku HTML mogą pojawić się dwa konkurujące tagi Canonical. Rozwiązanie: sprawdzić, czy Core-Canonical działa poprawnie dla stron szczegółowych news. Jeśli tak, newscanonical jest zbędny i można go wyłączyć. Gdy Core-Canonical nie włącza poprawnie parametrów newsów do URL, newscanonical pozostaje konieczny.

Problem trzeci: pętle przekierowań przy błędnej konfiguracji URL. Gdy canonical URL wskazuje na stronę, która sama zawiera przekierowanie na inny URL, powstaje pętla. Dzieje się to zwykle po restrukturyzacji URL, gdy stare przekierowania nie zostały uporządkowane. Rozwiązanie: sprawdzić wszystkie przekierowania dla URL-i news i usunąć niespójne wpisy.

## Od TYPO3 v12 Gosign sprawdza, czy Core-Canonical wystarcza

TYPO3 v12 znacząco poprawił wsparcie Canonical w Core. Rozszerzenie systemowe seo generuje canonical URL na podstawie Site Handling i uwzględnia parametry query. Dla wielu konfiguracji tx_news od v12 Core-Canonical wystarcza, dzięki czemu newscanonical nie jest już potrzebny. Gosign przy każdej aktualizacji TYPO3 sprawdza, czy rozwiązanie Core generuje canonical URL dla newsów poprawnie. Jeśli tak, zalecamy dezaktywację newscanonical, aby wyeliminować potencjalny punkt konfliktu. Gdy URL-e newsów zawierają złożone parametry lub ścieżki kategorii, których Core nie rozwiązuje, rozszerzenie pozostaje rozwiązaniem ważnym. W każdym przypadku zalecamy po aktualizacji systematyczny crawl ze Screaming Frog lub porównywalnym narzędziem, aby sprawdzić wszystkie strony szczegółowe news pod kątem prawidłowego zachowania Canonical. Jeden źle skonfigurowany tag Canonical może wyrzucić dziesiątki stron z indeksu Google, co przy stronach prasowych lub istotnych dla SEO artykułach blogowych oznacza bezpośrednią utratę ruchu.

--- News-Sync TYPO3 | Gosign ---
> Synchronizacja newsów między instancjami TYPO3 lub źródłami zewnętrznymi. Import RSS, synchronizacja treści oparta na API z wykrywaniem duplikatów.

## Gdy treść news ma pojawiać się na wielu instancjach TYPO3, kopiuj-wklej nie wystarcza

Organizacje z wieloma witrynami stoją przed konkretnym problemem: centralny związek publikuje komunikat prasowy, a 15 związków regionalnych ma go wyświetlać na swoich własnych instalacjach TYPO3. Albo koncern prowadzi witrynę korporacyjną i pięć witryn markowych, a określone newsy mają pojawić się na wszystkich sześciu stronach. Ręczne kopiowanie jest podatne na błędy, czasochłonne i generuje niespójności. newssync rozwiązuje problem, automatycznie synchronizując artykuły news między instancjami TYPO3 lub ze źródeł zewnętrznych. Import RSS, synchronizacja oparta na API i wykrywanie duplikatów to funkcje kluczowe.

Dla organizacji ze strategią multi-site syndykacja treści nie jest opcją, lecz koniecznością operacyjną. Bez zautomatyzowanej synchronizacji powstają silosy treści, których redakcja w centrali nie może kontrolować.

## Typowe scenariusze to sieci związków, witryny koncernów i agregacja newsów

Najczęstszym scenariuszem jest sieć związków. Związek krajowy publikuje na swojej witrynie TYPO3 newsy branżowe, aktualizacje regulacyjne i komunikaty prasowe. 16 związków regionalnych prowadzi własne instalacje TYPO3 i chce automatycznie przejmować wybrane artykuły. newssync importuje zaznaczone artykuły przez kanał RSS lub API, tworzy lokalne rekordy tx_news i pozwala związkom regionalnym dostosowywać lokalnie teasery i kategorie.

Drugi scenariusz: witryny koncernów ze strategią content-hub. Centrala koncernu prowadzi hub newsowy, z którego witryny markowe i krajowe wybiórczo pobierają treści. Synchronizacja biegnie według kategorii: witryna markowa subskrybuje tylko artykuły kategorii "Produkt X" i "Innowacja", a nie cały kanał news.

Trzeci scenariusz: agregacja newsów ze źródeł zewnętrznych. Portal branżowy automatycznie importuje komunikaty prasowe firm członkowskich przez ich kanały RSS. newssync sprawdza kanały w konfigurowalnych odstępach, importuje nowe artykuły i rozpoznaje duplikaty na podstawie tytułu i daty publikacji.

## Architektura techniczna wykorzystuje parsowanie RSS i pipeline Scheduler TYPO3

newssync pracuje w dwóch trybach importu: import kanałów RSS/Atom i synchronizacja oparta na API. W trybie RSS administrator konfiguruje URL kanału, a zadanie Scheduler parsuje kanał, wyodrębnia tytuł, teaser, treść, datę i URL-e mediów i tworzy rekordy tx_news w lokalnej bazie danych. Obrazy są pobierane i zapisywane lokalnie jako pliki FAL, aby źródło nie musiało być trwale dostępne.

W trybie API newssync komunikuje się z endpointem REST w instancji źródłowej. Umożliwia to bardziej selektywny import: zamiast importować cały kanał, artykuły można filtrować według kategorii, tagów lub daty. Tryb API przenosi także pola niestandardowe, które nie są odwzorowalne w formacie RSS.

Wykrywanie duplikatów opiera się na konfigurowalnym kluczu: standardowo hash z tytułu i daty publikacji. Gdy artykuł z tym samym kluczem już istnieje, jest pomijany lub aktualizowany w zależności od konfiguracji. Zapobiega to wielokrotnemu importowi tego samego artykułu, gdy zadanie synchronizacji uruchamia się częściej niż kanał się aktualizuje.

Synchronizacja uruchamia się jako zadanie Scheduler TYPO3, zwykle co 15 do 60 minut. Wyniki każdego uruchomienia są protokołowane: liczba zaimportowanych, zaktualizowanych i pominiętych artykułów. Przy błędach (kanał niedostępny, błąd parsera) zapisywane jest ostrzeżenie do loga TYPO3.

## Częste problemy to import mediów, czyszczenie HTML i mapowanie kategorii

Problem pierwszy: import mediów zawodzi. Obrazy i dokumenty referencjonowane w kanale źródłowym nie zawsze są bezpośrednio możliwe do pobrania. Ochrona przed hotlinkowaniem, uwierzytelnianie lub URL-e oparte na CDN mogą blokować pobieranie. Rozwiązanie: testować URL-e mediów przed importem i wdrożyć mechanizm fallback, który zastępuje brakujące obrazy obrazem zastępczym.

Problem drugi: nieczysty HTML w importowanej treści. Kanały RSS często zawierają HTML niezgodny ze standardem systemu docelowego: style inline, przestarzałe tagi, brakujące akapity. Rozwiązanie: czyszczenie HTML (sanityzacja) po imporcie, które usuwa zbędne tagi i style i sprowadza treść do oczekiwanego formatu. TYPO3 oferuje do tego klasę RteHtmlParser.

Problem trzeci: mapowanie kategorii między systemem źródłowym i docelowym. Kategorie w kanale źródłowym nie pokrywają się z lokalnymi kategoriami. "Komunikat prasowy" w centrali nazywa się "Prasa" w związku regionalnym. Rozwiązanie: tablica mapująca w konfiguracji newssync, która odwzorowuje kategorie źródłowe na lokalne sys_category TYPO3.

Czwarty problem dotyczy suwerenności treści: gdy związek regionalny lokalnie zmodyfikuje zsynchronizowany artykuł, a centrala zaktualizuje także artykuł oryginalny, kolejna synchronizacja nadpisuje lokalną zmianę. Rozwiązanie: oznaczać zsynchronizowane artykuły jako "read-only" i dopuszczać lokalne dostosowania tylko w dedykowanych polach (np. lokalny teaser, uzupełnienie regionalne), których synchronizacja nie dotyczy.

## Rozszerzenie nie ma pewnego wsparcia dla v12, własne rozwiązania są solidniejsze

newssync zostało opracowane dla starszych wersji TYPO3 i nie ma oficjalnego wsparcia dla v12 lub v13. Dla organizacji, które potrzebują syndykacji treści jako funkcji podstawowej, Gosign zaleca dopasowane rozwiązanie: własny importer jako zadanie Scheduler, które konsumuje kanały RSS lub API REST i tworzy rekordy tx_news. Nakład pracy na podstawową implementację z importem kanału, wykrywaniem duplikatów i pobieraniem mediów wynosi od 3 do 5 dni roboczych. Generowanie kodu wspierane AI znacząco przyspiesza rozwój parsera kanału i warstwy mapowania.

Zaletą własnego rozwiązania jest to, że mapowanie między kategoriami źródłowymi i docelowymi, przetwarzanie mediów i obsługa błędów mogą zostać dokładnie dopasowane do wymagań organizacji. Związek federalny z 16 oddziałami regionalnymi ma inne wymagania synchronizacji niż koncern z 5 witrynami markowymi. Gosign wdraża rozwiązania syndykacji treści oparte na nowoczesnych API TYPO3 (zdarzenia PSR-14, Symfony Messenger do przetwarzania opartego na kolejkach), które pozostają kompatybilne także przy aktualizacjach v13.

--- Audio Player TYPO3 - HTML5 | Gosign ---
> Odtwarzacz audio HTML5 dla TYPO3. Podcasty, audioguide, streaming muzyki. Custom Player z obsługą playlist, paskiem postępu, kontrolą prędkości.

## Podcasty i audioguide potrzebują odtwarzacza, który obywa się bez usług zewnętrznych

Kto chce udostępniać treści audio na stronie TYPO3, staje przed nieprzyjemnym wyborem: albo usługa zewnętrzna taka jak SoundCloud czy Spotify, która wysyła dane użytkowników na serwery zewnętrzne i dyktuje wygląd, albo natywny odtwarzacz HTML5, który w domyślnym ustawieniu przeglądarki jest ledwie użyteczny. nim_html5audioplayer zamyka tę lukę. Rozszerzenie dostarcza w pełni zintegrowany z TYPO3 odtwarzacz audio z obsługą playlist, paskiem postępu i kontrolą prędkości. Wszystkie pliki audio pozostają na własnym serwerze, żadne zewnętrzne żądanie nie opuszcza strony.

Dla muzeów, placówek edukacyjnych i wydawnictw z formatami podcastowymi to twarde wymaganie: audioguide nie mogą ustawiać ciasteczek trackingowych, treści szkoleniowe muszą działać bez połączenia z internetem w intranecie, a podcasty korporacyjne mają pojawiać się w identyfikacji wizualnej organizacji. nim_html5audioplayer spełnia wszystkie trzy scenariusze jednym elementem treści.

## Typowe scenariusze sięgają od muzeum po wewnętrzny portal szkoleniowy

Najczęstszym scenariuszem są audioguide w muzeach i na wystawach. Zwiedzający skanują kod QR, trafiają na stronę TYPO3 i słuchają komentarza do eksponatu. Odtwarzacz uruchamia się bez autoplay, pokazuje pasek postępu i pozwala na dostosowanie prędkości między 0,5x a 2x. Przy typowej wystawie z 30 do 50 stanowiskami funkcja playlisty dostarcza ciągły tour bez konieczności ręcznej nawigacji między stronami.

Drugie duże pole zastosowania to podcasty korporacyjne. Firmy, które przetwarzają swoją wewnętrzną wiedzę jako serię audio, potrzebują odtwarzacza osadzonego w istniejącej witrynie TYPO3, a nie żyjącego na platformie zewnętrznej. nim_html5audioplayer dostarcza do tego odtwarzacz w identyfikacji wizualnej z listą odcinków, markerami rozdziałów i opcją pobrania. Redakcja zarządza odcinkami jak zwykłymi treściami TYPO3 przez backend.

Trzecim scenariuszem są portale do nauki języków i platformy e-learning. Tutaj szczególne znaczenie ma kontrola prędkości: uczący się mogą zwolnić dialogi lub odtwarzać powtórzenia w przyspieszonym tempie. W połączeniu z fe_login treści audio premium można chronić za logowaniem.

## Architektura techniczna opiera się na natywnym API HTML5 bez frameworka JavaScript

nim_html5audioplayer wykorzystuje HTML5 Audio API przeglądarki i renderuje interfejs odtwarzacza przez szablony Fluid. Nie ma zależności od jQuery, Reacta ani innego frameworka. Dzięki temu czas ładowania pozostaje minimalny: sam odtwarzacz waży poniżej 15 KB (CSS + JS), a pliki audio są zarządzane przez FAL (File Abstraction Layer) i dostarczane przez streaming.

Rozszerzenie rejestruje własny element treści w backendzie TYPO3. Redaktorzy wybierają pliki audio z mediateki FAL, ustawiają tytuł, opis i opcjonalny obraz podglądu. Funkcja playlisty grupuje kilka wpisów audio w sortowalnej liście. Renderowanie przejmują szablony Fluid, które można nadpisać przez SiteSet lub własny sitepackage.

Dla paska postępu odtwarzacz zapisuje aktualny stan odtwarzania w LocalStorage przeglądarki. Gdy odwiedzający wraca, odtwarzacz skacze do ostatniej pozycji. Działa to bez ciasteczek i bez sesji serwerowej.

## Częste problemy dotyczą formatów audio i przeglądarek mobilnych

Dominującym tematem wsparcia jest kompatybilność formatów audio. MP3 działa we wszystkich przeglądarkach, OGG Vorbis tylko w Firefoksie i Chromie, AAC tylko w Safari i Chromie. Kto chce maksymalnej kompatybilności, przechowuje każdy plik jako MP3. Kto potrzebuje lepszej jakości przy mniejszym rozmiarze pliku, dostarcza MP3 jako fallback i Opus jako format podstawowy.

Drugi problem: blokowanie autoplay na urządzeniach mobilnych. iOS i Android od 2018 roku blokują automatyczne odtwarzanie audio bez interakcji użytkownika. nim_html5audioplayer respektuje tę politykę przeglądarki i uruchamia audio wyłącznie po jawnym kliknięciu. Kto mimo to skonfiguruje autoplay dla muzyki w tle, na urządzeniach mobilnych otrzyma ciszę bez komunikatu o błędzie.

Trzeci temat to wydajność przy dużych playlistach. Od 100 wpisów na pojedynczej playliście czas renderowania DOM staje się zauważalny. Rozwiązanie: dzielić playlisty na bloki tematyczne po 20 do 30 wpisów i organizować je przez kategorie w backendzie.

## Rozszerzenie działa pod TYPO3 v11 i v12, status v13 zależy od opiekuna

nim_html5audioplayer zostało pierwotnie opracowane dla TYPO3 v8 i v9. Podstawowa funkcjonalność (HTML5 Audio API, integracja FAL) jest technicznie stabilna i działa pod v11 i v12 bez większych dostosowań. Dla TYPO3 v13 obecnie nie istnieje oficjalna deklaracja kompatybilności opiekuna. Rozszerzenie nie używa jednak żadnych API usuniętych w v13, dzięki czemu migracja jest w większości przypadków możliwa przy niewielkim nakładzie.

Gosign przy aktualizacjach TYPO3 sprawdza, czy używane rozszerzenia audio są nadal kompatybilne, i w razie potrzeby zaleca alternatywy. Gdy rozszerzenie nie jest już rozwijane, tę samą funkcjonalność można odtworzyć przez własny element treści z natywnym HTML5 Audio API i szablonami Fluid, zwykle w ciągu dwóch do trzech dni roboczych programisty.

--- nimcore TYPO3 - Core Framework | Gosign ---
> NIM Core Framework: Bazowa biblioteka dla Custom rozszerzeń TYPO3 z rodziny NIM. Klasy abstrakcyjne, funkcje narzędziowe, wspólna konfiguracja.

## Bez centralnej biblioteki bazowej rodziny rozszerzeń generują zduplikowany kod i zduplikowane błędy

Agencje TYPO3, które tworzą kilka powiązanych ze sobą rozszerzeń, stają przed problemem architektonicznym: każde rozszerzenie reimplementuje funkcje pomocnicze takie jak odczyt konfiguracji, rejestracja modułów backendowych, obsługa FAL i logowanie. Przy pięciu rozszerzeniach oznacza to pięć kopii tych samych funkcji pomocniczych, pięć miejsc na ten sam błąd. nimcore rozwiązuje ten problem jako centralna biblioteka bazowa rodziny rozszerzeń NIM. Klasy abstrakcyjne, funkcje narzędziowe i wspólna konfiguracja znajdują się w jednym miejscu. Wszystkie zależne rozszerzenia NIM dziedziczą z nimcore i muszą implementować tylko swoją logikę biznesową.

Ten wzorzec jest rzadki w ekosystemie TYPO3, ale dobrze znany w architekturze oprogramowania: Shared Kernel, który hermetyzuje horyzontalne aspekty (logowanie, konfigurację, modele bazowe), podczas gdy rozszerzenia pionowe (odtwarzacz audio, galeria, slider) przejmują logikę biznesową.

## Typowe scenariusze dotyczą agencji z własnymi portfoliami rozszerzeń

Scenariuszem głównym jest agencja utrzymująca zestaw czterech do dziesięciu własnych rozszerzeń TYPO3. Bez wspólnej biblioteki bazowej rozszerzenia rozchodzą się: jedno używa GeneralUtility::makeInstance, drugie kontenera DI, trzecie ma własną konfigurację loggera. nimcore wymusza jednolity standard. Wszystkie rozszerzenia NIM używają tych samych abstrakcyjnych klas kontrolerów, tej samej obsługi wyjątków i tej samej struktury konfiguracji.

Drugim scenariuszem są wewnętrzne zespoły deweloperskie, które rozszerzają swoją instancję TYPO3 kilkoma własnymi rozszerzeniami. Zamiast traktować każde rozszerzenie jako izolowany pakiet, zespoły mogą zbudować własną bibliotekę Core według wzorca nimcore: wspólne modele bazowe, wspólne klasy modułów backendowych, wspólne fixture testowe. Redukuje to nakład utrzymania i obniża próg wejścia dla nowych programistów, którzy muszą nauczyć się tylko jednej architektury.

Trzeci scenariusz to wersjonowanie przy aktualizacjach. Gdy rdzeń TYPO3 zmienia API używane w pięciu rozszerzeniach, wystarczy pojedyncza aktualizacja w nimcore. Wszystkie zależne rozszerzenia korzystają z tego natychmiast, bez konieczności dostosowywania każdego osobno. Przy aktualizacji do TYPO3 v12 z siedmioma rozszerzeniami NIM oszczędza to zwykle dwa do trzech dni roboczych programisty.

## Architektura techniczna podąża za zasadą Shared Kernel

nimcore rejestruje się jako zwykłe rozszerzenie TYPO3 i jest deklarowane przez Composer jako zależność w zależnych rozszerzeniach. Plik ext_emconf.php rozszerzeń NIM wymienia nimcore jako required constraint. Przy instalacji rozszerzenia NIM nimcore jest automatycznie dociągane.

Wewnętrznie nimcore dostarcza klasy abstrakcyjne dla kontrolerów, repozytoriów i modeli, które poprawnie inicjalizują framework Extbase TYPO3. Klasy narzędziowe hermetyzują powtarzające się zadania: odczyt konfiguracji TypoScript, rozwiązywanie referencji FAL, rejestracja toolbarów backendowych, standaryzowane wyświetlanie Flash-Messages. Centralny rejestr konfiguracji umożliwia definiowanie ustawień specyficznych dla rozszerzenia w jednolitym formacie, dostępnym w backendzie TYPO3 przez moduł ustawień.

Infrastruktura testowa jest również zgrupowana w nimcore: klasy bazowe TestCase, loader fixture i narzędzia mockingu, które ułatwiają pisanie testów funkcjonalnych dla rozszerzeń Extbase. Obniża to próg pisania testów, ponieważ setup nie musi być konfigurowany od nowa w każdym rozszerzeniu.

## Częste problemy powstają przy konfliktach wersji i zależnościach cyklicznych

Największym ryzykiem architektury Shared Kernel jest przymus wydania w lockstep: gdy nimcore wprowadza Breaking Change, wszystkie zależne rozszerzenia muszą zostać jednocześnie zaktualizowane. W praktyce oznacza to, że nimcore musi ściśle przestrzegać semantic versioning. Wersje minor nie mogą zmieniać publicznych interfejsów, a wydania major wymagają instrukcji migracji.

Drugi problem: cykliczne zależności. Gdy rozszerzenie A zależy od nimcore, a nimcore używa serwisu zdefiniowanego właściwie w rozszerzeniu A, powstaje cykl. Rozwiązaniem jest czysta zasada Dependency Inversion: nimcore definiuje interfejsy, które zależne rozszerzenia implementują. nimcore sam nie zna konkretnych implementacji.

Trzeci temat to kolejność autoload w Composer. Przy dużych instalacjach z 30 lub więcej rozszerzeniami kolejność autoloadingu może prowadzić do tego, że klasy nimcore nie są jeszcze dostępne, gdy ładowane jest zależne rozszerzenie. Rozwiązanie: w composer.json instalacji root zdefiniować nimcore jako pierwsze w install-order.

## TYPO3 v12 działa, kompatybilność v13 zależy od warstwy abstrakcji Extbase

nimcore opiera się na frameworku Extbase i jest tym samym ściśle związany z jego stabilnością API. Pod TYPO3 v12 aktualna wersja działa stabilnie. Dla v13 potrzebne są dostosowania, gdy rdzeń TYPO3 zmienia interfejsy Extbase lub restrukturyzuje konfigurację Dependency Injection.

Ponieważ nimcore jest produktem niszowym dla rodziny rozszerzeń NIM, dalszy rozwój zależy bezpośrednio od opiekuna. Zespoły stawiające na nimcore powinny sforkować kod źródłowy i utrzymywać go we własnym repozytorium, aby nie być zależnym od zewnętrznych cykli wydań. Gosign przy portfoliach własnych rozszerzeń generalnie zaleca budowanie architektury Shared Kernel wewnętrznie i utrzymywanie jej pod własną kontrolą, zamiast polegać na zewnętrznych bibliotekach Core.

--- OIDC TYPO3 - OpenID Connect SSO | Gosign ---
> OpenID Connect dla TYPO3: Azure AD, Keycloak, Okta SSO. Konfiguracja, Claim-Mapping i rozwiązywanie problemów. Z wykorzystaniem AI.

## Jak projekty TYPO3 bez własnego stosu tożsamości podłączają się do Azure AD, Keycloak lub Okta

W każdej firmie, która prowadzi Microsoft 365, Google Workspace lub centralny Keycloak, zarządzanie użytkownikami jest już dawno rozstrzygnięte: wszystkie konta pracownicze żyją w IdP, a każda nowa aplikacja ma się tam podłączać, a nie zarządzać własnymi hasłami. Rozszerzenie OIDC dla TYPO3 obsługuje dokładnie ten wzorzec, osadzając OpenID Connect jako protokół uwierzytelniania w TYPO3 i tym samym udostępniając Azure AD, Keycloak, Okta, Google Workspace lub Auth0 jako IdP, bez konieczności prowadzenia własnego Shibboleth SP. Grupą docelową są portale firmowe, intranety, obszary logowania klienta i wszystkie instalacje TYPO3, które mają się wpasować w istniejące enterprise'owe krajobrazy tożsamości.

## Typowe scenariusze zastosowania

Koncern maszynowy z 14 000 pracowników prowadzi swój intranet pracowniczy na TYPO3. Dział IT już dawno zdecydował, że każda nowa aplikacja uwierzytelnia się przez Azure AD i wymusza tam Multi-Factor-Authentication. Rozszerzenie OIDC pobiera ID-Tokens z Azure AD, odczytuje przypisania grup zawarte w claimie i tworzy z tego grupy fe_user. Intranet otrzymuje Single Sign-On, MFA i Conditional Access bez dodatkowej infrastruktury, wyłącznie przez porządną konfigurację.

Drugi scenariusz pochodzi z sektora MSP: dostawca oprogramowania z portalem klienta na TYPO3 używa Keycloak jako centralnego brokera, bo jego klienci przychodzą z loginami użytkowników albo z social-loginami jak Google czy GitHub. Keycloak ujednolica to i mówi na zewnątrz OIDC. TYPO3 używa rozszerzenia OIDC i otrzymuje dostęp do wszystkich wariantów logowania, samo nie wiedząc, że w tle działa social-login.

Trzeci przypadek to urzędy i administracje wojewódzkie, które przechodzą na konta obywatelskie oparte na Keycloak. Portal TYPO3, przez który obywatele składają wnioski, może przez rozszerzenie OIDC podłączyć się do wojewódzkiego Keycloak. Atrybut eID z brokera ląduje bezpośrednio w fe_user, a poziom uwierzytelnienia można ocenić przez claim acr.

## Architektura techniczna: Authorization-Code-Flow w TYPO3

OpenID Connect to warstwa uwierzytelniania na OAuth 2.0, a rozszerzenie OIDC implementuje dokładnie Authorization-Code-Flow. Przebieg jest prostszy niż SAML: TYPO3 przekierowuje użytkownika z Authorization Request do IdP, po pomyślnym zalogowaniu otrzymuje z powrotem kod, wymienia go po stronie serwera na ID-Token i waliduje podpis przez JSON Web Key Set (JWKS) providera. Claimy z ID-Tokena, zazwyczaj sub, email, name, groups i roles, są mapowane na pola użytkownika TYPO3.

Konfiguracja rozszerzenia odbywa się przez konfigurację rozszerzenia TYPO3 i Discovery-Endpoint, który każdy provider zgodny z OIDC udostępnia pod /.well-known/openid-configuration. Rozszerzenie odczytuje z tego URL-a endpointy tokena, URL JWKS i wspierane flows automatycznie, co redukuje manualne błędy. Claim-mapping odbywa się przez konfigurację YAML lub TypoScript, która odwzorowuje lokalne nazwy pól na ścieżki claim.

## Częste problemy i rozwiązania

Pierwszy problem dotyczy formatów claim: Azure AD dostarcza grupy jako ID obiektów (GUID), a nie jako czytelne nazwy. Kto oczekuje claimu group_ids, a otrzymuje group_names, widzi puste grupy użytkowników w TYPO3. Porządne rozwiązanie leży w samej aplikacji Azure-AD: w bloku Token-Configuration można ustalić, które atrybuty są zwracane jako claimy, a dodatkowo regułowy zestaw Claim-Transformation może przekładać GUID na czytelne nazwy.

Drugi problem to Redirect-URI. Każdy klient OIDC musi zarejestrować w IdP dokładnie ten Redirect-URI, do którego jest odsyłany po zalogowaniu. Różnice w wielkości liter, zapomniane slashe końcowe albo przejście z HTTP na HTTPS powodują natychmiastowe błędy logowania, które nie są widoczne w logu TYPO3, bo błąd występuje w IdP. Gosign konfiguruje oddzielnych klientów dla staging i production z czystymi Redirect-URI i dokumentuje każdą zmianę w procesie deploymentu.

Trzeci temat to odświeżanie tokenów. Kto chce dłuższych sesji, potrzebuje Refresh-Tokens, które IdP wystawia tylko wtedy, gdy scope offline_access został zażądany przy logowaniu. Bez tego scope sesja TYPO3 kończy się, gdy tylko wygasa ID-Token, zwykle po godzinie. Konfiguracja w backendzie rozszerzenia musi zatem przekazywać scope offline_access i aktywować logikę odświeżania tokenów.

Czwarty problem dotyczy wylogowania. OIDC zna Front-Channel i Back-Channel-Logout i oba nie zawsze są aktywne w rozszerzeniu. Kto oczekuje prawdziwego Single Logout na wielu aplikacjach, musi skonfigurować odpowiedni End-Session-Endpoint providera i zapewnić, że TYPO3 wywołuje URL wylogowania IdP przy końcu sesji. Bez tej konfiguracji użytkownik pozostaje zalogowany w IdP, mimo że wylogował się z TYPO3.

## Migracja i kompatybilność wersji

Rozszerzenie OIDC jest obecnie zalecanym standardem dla TYPO3 v12 i v13, podczas gdy starsze projekty v11 często jeszcze używają samoróbek OAuth lub shibboleth_auth. Ścieżka migracji z Shibboleth na OIDC jest dobrze ugruntowana, o ile IdP mówi oboma protokołami: Keycloak, ADFS i Azure AD potrafią obsługiwać SAML i OIDC równolegle, dzięki czemu przejście bez big-bang jest możliwe.

Kto migruje z czysto bazodanowego zarządzania fe_user, musi odwzorować istniejące konta na claimy OIDC za pomocą strategii matchingu. Adres e-mail jest typowym kotwicznym identyfikatorem, ale nie zawsze wystarcza, bo adresy mailowe mogą się zmieniać. Claim sub, zapisany jako trwały unikalny identyfikator w fe_user, jest bardziej solidnym rozwiązaniem. Gosign przejmuje takie migracje wraz z dopasowaniem istniejących kont i okresem przejściowym, w którym oba ścieżki uwierzytelniania działają równolegle.

Dla zespołów, które właśnie uruchamiają nowy projekt TYPO3, OIDC jest w zdecydowanej większości przypadków pierwszym wyborem. Konfiguracja jest smuklejsza niż przy SAML, nakład pracy klienta mniejszy, a każdy nowoczesny IdP natywnie wspiera protokół. Wyjątki są uzasadnione tylko tam, gdzie wymagania regulacyjne lub federacyjne wyraźnie wymagają SAML, jak we wspomnianych federacjach akademickich. We wszystkich innych scenariuszach, zwłaszcza przy chmurowych IdP i integracjach enterprise, OIDC dostarcza lepszy kompromis między prostotą, bezpieczeństwem i utrzymywalnością.

--- OpenImmo TYPO3 - Import nieruchomości | Gosign ---
> OpenImmo w TYPO3: Import XML nieruchomości, prezentacja, filtrowanie. Strony dla pośredników, z wykorzystaniem AI.

## Dlaczego strony pośredników bez integracji OpenImmo powodują podwójną pracę

Pośrednicy nieruchomości zarządzają swoimi obiektami w oprogramowaniu takim jak FlowFact, onOffice, ImmoTool czy JustImmo. Każdy obiekt ze zdjęciami, cenami, powierzchniami i opisami lokalizacji. Te dane mają pojawiać się też na stronie - ale bez ręcznego podwójnego wprowadzania. OpenImmo to standard XML, który dokładnie ten most buduje: oprogramowanie pośrednika eksportuje obiekty jako XML, TYPO3 automatycznie je importuje i wyświetla na stronie.

Bez integracji OpenImmo biuro z 40 aktywnymi obiektami pielęgnuje każde ekspoze podwójnie - raz w oprogramowaniu zarządzającym i raz na stronie. Przy średnim czasie obróbki 15 minut na obiekt to 10 godzin miesięcznie samej pielęgnacji danych, które zautomatyzowany pipeline całkowicie eliminuje.

## Typowe scenariusze zastosowań

**Automatyczny import dla stron pośredników.** Biuro z 30 do 100 aktywnymi obiektami prowadzi swoją stronę na TYPO3. Co noc onOffice eksportuje wszystkie obiekty jako OpenImmo-XML na serwer FTP. Zadanie Scheduler TYPO3 pobiera plik XML, parsuje go i aktualizuje obiekty w bazie danych - nowe obiekty są tworzone, zmienione aktualizowane, sprzedane archiwizowane. Rano strona jest automatycznie aktualna.

**Portale nieruchomości z agregacją wielu dostawców.** Regionalna platforma nieruchomości agreguje obiekty od 10 do 30 pośredników. Każdy pośrednik dostarcza swoje obiekty w formacie OpenImmo. TYPO3 importuje wszystkie feedy, przypisuje obiekty do odpowiednich dostawców i wyświetla je na wspólnej platformie z jednolitym wyszukiwaniem i filtrowaniem.

**Strony deweloperów z przeglądem mieszkań.** Deweloper sprzedaje 50 jednostek mieszkalnych w projekcie nowobudowlanym. Dostępności i ceny są pielęgnowane w oprogramowaniu zarządzającym. Przez import OpenImmo strona TYPO3 automatycznie aktualizuje status każdej jednostki: dostępna, zarezerwowana lub sprzedana.

## Architektura techniczna

Integracja OpenImmo w TYPO3 składa się z czterech komponentów: parser XML (odczytuje plik OpenImmo-XML i konwertuje go na obiekty PHP - schemat OpenImmo definiuje ponad 200 pól per obiekt), pipeline importu (zadanie Scheduler lub komenda CLI regularne wykonywanie importu z pobieraniem plików, walidacją XML, mapowaniem obiektów i importem obrazów), prezentacja frontendowa (plugin Extbase z filtrowaniem i widokiem szczegółów z galerią obrazów, mapą lokalizacji i formularzem kontaktowym) oraz opcjonalna generacja ekspoze (strony szczegółowe obiektów jako PDF do pobrania).

## Częste problemy i rozwiązania

**Import przerywa się z błędami parsowania XML.** Oprogramowanie pośredników czasem eksportuje XML niezgodne ze schematem. Brakujące pola obowiązkowe, niewłaściwe kodowanie znaków (ISO-8859-1 zamiast UTF-8) lub niezamknięte tagi prowadzą do przerwania. Rozwiązanie: wbudowanie kroku preprocessingu XML, który waliduje plik przed importem, koryguje problemy z kodowaniem i wypełnia brakujące pola obowiązkowe wartościami domyślnymi.

**Obrazy nie są prawidłowo importowane.** OpenImmo-XML odwołuje się do obrazów przez relatywne ścieżki lub URL. Jeśli upload FTP umieszcza obrazy w innym katalogu niż oczekuje XML, referencje obrazów pozostają puste. Rozwiązanie: konfiguracja importu tak, by obrazy były wyszukiwane relatywnie do katalogu XML.

**Usunięte obiekty pozostają widoczne na stronie.** OpenImmo zna dwa sposoby oznaczania obiektów jako sprzedane/usunięte: przez pole statusu w XML lub przez pominięcie obiektu w następnym eksporcie. Rozwiązanie: konfiguracja importu na pełne uzgadnianie - obiekty nieobecne w aktualnym eksporcie XML są automatycznie oznaczane jako "sprzedane" lub archiwizowane.

## Migracja i kompatybilność wersji

Dla OpenImmo w TYPO3 istnieje kilka rozszerzeń. Większość jest dostępna dla TYPO3 v10 i v11. Dla TYPO3 v12 i v13 wybór jest bardziej ograniczony, ponieważ niektóre rozszerzenia nie są już aktywnie utrzymywane.

Sam format OpenImmo jest stabilny. Wersja 1.2.7 jest od lat standardem de facto i wszystkie istotne pakiety oprogramowania pośredników go wspierają.

Gosign zaleca przy aktualizacji TYPO3 z v10/v11 na v12 ewaluację istniejącego rozszerzenia OpenImmo. Jeśli maintainer nie jest już aktywny, opłaca się przejście na własny pipeline importu z nowoczesnym PHP. Początkowy nakład wynosi 5 do 8 dni, ale pipeline jest niezależny od rozszerzeń firm trzecich i długoterminowo łatwy w utrzymaniu. Pipeline można też łatwo rozszerzyć o dodatkowe źródła danych: interfejs IS24, API Immowelt czy propriatarne formaty XML deweloperów.

--- Paywall TYPO3 - Monetyzacja treści | Gosign ---
> Paywall dla TYPO3: Płatne treści, modele subskrypcji, kontrola dostępu. Custom-rozwój z AI, klasa Enterprise.

## Paywall w TYPO3 nie jest tematem pluginu, tylko decyzją architektoniczną

Paid content w TYPO3 wydaje się na pierwszy rzut oka banalnym pytaniem: kilka stron za loginem, dostawca płatności przed, gotowe. W praktyce zadanie okazuje się jednym z najbardziej wymagających w otoczeniu TYPO3. Core nie zna natywnego pojęcia paid content, a nieliczne darmowo dostępne rozszerzenia w najlepszym razie pokrywają proste scenariusze logowania. Kto poważnie chce monetyzować treści (Metered Paywall, Hard Paywall, Freemium, subskrypcje warstwowe) ląduje przy rozwoju dopasowanym na miarę.

Grupą docelową są zazwyczaj wydawnictwa, portale branżowe i dostawcy treści B2B. Wydawnictwo fachowe z 4000 artykułów premium rocznie potrzebuje nie tylko kontroli dostępu, ale też cyklu życia subskrypcji, procesu wypowiedzenia, prawnie pewnego pokazywania praw do odstąpienia, interfejsu do księgowości i raportowania dla redakcji. Wszystko to ma być odwzorowane w istniejącej instalacji TYPO3, bez konieczności uczenia się przez redakcję nowego interfejsu CMS.

## Typowe scenariusze zastosowania

Pierwszym scenariuszem jest Metered Paywall regionalnego wydawnictwa. Dom publikuje 500 płatnych artykułów miesięcznie i chce oferować anonimowym czytelnikom trzy artykuły na miesiąc kalendarzowy za darmo, zanim paywall zadziała. Liczenie odbywa się przez podpisany cookie, który działa też bez loginu, a odblokowanie przebiega przez istniejący sklep z miesięczną subskrypcją.

Drugim scenariuszem jest Hard Paywall w wydawnictwie fachowym B2B. Tu nie ma darmowych artykułów, każdy dostęp wymaga aktywnej umowy. Wyzwanie leży w kombinacji subskrypcji indywidualnej, firmowej i dostępu kampusowego opartego na IP. Integracja TYPO3 musi w czasie rzeczywistym sprawdzać, czy czytelniczka dysponuje ważną umową, i wydajnie udostępniać wyniki dla nawigacji, wyszukiwania i feedów RSS.

Trzecim scenariuszem jest model freemium portalu branżowego. Rejestracja jest bezpłatna, określone narzędzia premium (pobieranie whitepaper, raport benchmarkowy, interaktywny kalkulator) wymagają płatnej subskrypcji. Paywall musi per element treści decydować, czy jest dostęp, i podpinać obsługę płatności wraz z tworzeniem faktur.

Czwartym scenariuszem jest strona klientów reklamowych domu medialnego. Tu chodzi mniej o klientów końcowych niż o agencje, które chcą wglądu w obszar mediadanych. Dostęp jest typowo sterowany przez jednorazową rejestrację plus ręczne zwolnienie przez dział reklamy. TYPO3 odwzorowuje status zwolnienia w profilu użytkownika i odblokowuje chroniony obszar, gdy tylko status jest ustawiony na "zwolnione".

## Architektura techniczna

Gotowy do produkcji paywall w TYPO3 składa się z kilku warstw. Na froncie stoi middleware, które sprawdza każde zapytanie treści pod kątem tego, czy dostęp jest dozwolony. Ta middleware sięga do polityki dostępu, która łączy subskrypcje, zakupy pojedyncze i kontyngenty darmowe. Pod nią leży warstwa persystencji z danymi podstawowymi subskrypcji, historią płatności i statusem umowy, która jest synchronizowana z zewnętrznym dostawcą płatności (Stripe, PayPal, Mollie, Adyen).

Dla strony treści są dwa warianty: albo treść jest przycinana po stronie serwera i renderowany jest tylko dopuszczalny dla czytelniczki udział, albo dostarczany jest pełny tekst, a warstwa overlay paywall jest kontrolowana przez markup po stronie serwera. Drugi wariant jest niebezpieczny, bo narzędzia przeglądarki mogą obejść overlay. Profesjonalne paywalle zawsze działają po stronie serwera.

Integracja TYPO3 odbywa się przez rozszerzenia Extbase z własnymi middleware frontendowymi, TCA-Overrides dla statusu paywall per element treści i endpointami REST dla webhooków płatności. Middleware PSR-15 od TYPO3 v9 są porządnym miejscem dla interception requestu.

## Częste problemy i rozwiązania

Pierwszym problemem jest obchodzalność przez cache'owanie. Kto pauszalnie aktywuje page-cache, dostarcza pełny tekst płatnego artykułu do proxy, a od tej chwili do każdego nieupoważnionego czytelnika. Rozwiązaniem jest jasno rozdzielone cache'owanie per rola użytkownika lub wyjątek treści paywall z page-cache.

Drugim problemem są race conditions w cyklu życia subskrypcji. Przy jednoczesnym wypowiedzeniu i przebiegu rozliczeniowym powstają niespójne stany, gdy kolejność zapisów między TYPO3 a dostawcą płatności nie jest porządnie zserializowana. Rozwiązaniem jest event-store dla zdarzeń subskrypcji z określonym źródłem prawdy (zazwyczaj dostawca płatności) i idempotentnym procesem importu.

Trzecim problemem jest spadek konwersji przez wolne sprawdzenia paywall. Każda milisekunda opóźnienia kosztuje zamknięcia. Rozwiązaniem są asynchroniczne sprawdzenia dostępu z podpisanym tokenem sesji, które unikają kosztownych zapytań bazodanowych.

Czwartym problemem są podatkowe i prawne uwarunkowania brzegowe. Przychody z subskrypcji podlegają VAT, pouczenia o odstąpieniu muszą być prawidłowo sformułowane przy zobowiązaniach ciągłych, a przy subskrypcjach transgranicznych działają różne reżimy VAT. Rozwiązaniem jest uzgadnianie architektury paywall od początku z księgowością i działem prawnym oraz opieranie obsługi płatności na dostawcy, który przejmuje tworzenie faktur i podatków.

## Migracja i kompatybilność wersji

Ponieważ paywalle w TYPO3 powstają jako rozwój niestandardowy, kompatybilność wersji zależy całkowicie od zespołu deweloperskiego. Porządnie zbudowane rozszerzenie paywall działa na TYPO3 v11 do v13, jeśli opiera się na middleware PSR, Dependency Injection i nowoczesnych konwencjach Extbase. Problemy powstają przy starych obciążeniach, które jeszcze opierają się na integracjach opartych na hookach z TYPO3 v7/v8.

Przy upgrade istniejącego paywall zaleca się dwuetapowa migracja. W pierwszym kroku klienty API płatności i middleware kontroli dostępu są podnoszone do nowoczesnych konwencji TYPO3, bez zmiany logiki biznesowej. W drugim kroku następują zmiany merytoryczne jak nowe modele subskrypcji, zmienione liczenie metered lub dodatkowi dostawcy płatności. To rozdzielenie znacząco redukuje ryzyko złamania regresji i umożliwia porządne testowanie każdego kroku w środowisku staging.

Gosign buduje i modernizuje systemy paywall dla wydawnictw i dostawców treści. Kombinacja generowania kodu wspieranego przez AI dla integracji API płatności i senior-review dla bezpieczeństwa, zgodności PCI i unikania race conditions zauważalnie skraca time-to-market, bez utraty jakości architektury.

--- PDF.js TYPO3 - Przeglądarka PDF | Gosign ---
> Integracja przeglądarki PDF.js dla TYPO3. Wyświetlanie PDF w przeglądarce bez pluginów, bez pobierania.

## PDF.js osadza sprawdzony renderer PDF od Mozilli bezpośrednio w stronach TYPO3, lekkie rozwiązanie, gdy redaktorzy chcą pokazywać PDF-y w przeglądarce, bez przymusu pobierania i bez ciężkiego otoczenia flipbooka

Gdy odwiedzający klika PDF, przeglądarka albo otwiera go w nowej zakładce, pobiera lub przekazuje do zewnętrznego viewera. Żaden z tych wariantów nie jest zadowalający dla redaktorów, którzy chcą prezentować dokument w kontekście strony. PDF.js rozwiązuje to, wbudowując viewer, którego wewnętrznie używają Firefox i Chrome, jako samodzielny moduł JavaScript bezpośrednio w stronę TYPO3. Wynikiem jest spójna prezentacja na wszystkich przeglądarkach i urządzeniach, bez konieczności instalowania przez użytkowników pluginu lub opuszczania dokumentu.

Często pomijaną zaletą jest: użytkownik nie opuszcza strony. Podczas gdy otwarty PDF w nowej zakładce zazwyczaj oznacza koniec sesji, w przypadku wbudowanego viewera połączenie analityczne pozostaje zachowane. Kto mierzy, jak długo odwiedzający faktycznie oglądają dokument, może przypisać czas bezpośrednio stronie contentowej i zobaczyć, które dokumenty są rzeczywiście czytane.

## Typowe scenariusze zastosowania

Najczęstszym zastosowaniem jest osadzanie pojedynczych dokumentów na stronach contentowych, na przykład whitepaper na stronie produktu, formularz wniosku na stronie serwisowej lub program wydarzenia obok opisu wydarzenia. Redakcja ładuje PDF do FAL i odwołuje się do niego przez element treści, PDF.js renderuje go inline. Przy tym zachowana jest stylistyka CI strony, bo ramki, cienie i elementy sterujące są stylizowane przez własny szablon sitepackage.

Drugim przypadkiem są centra pobrań, w których kilka PDF-ów jest prezentowanych przez podgląd. Zamiast ślepych ikon plików użytkownicy widzą pierwszą stronę dokumentu i jednym kliknięciem decydują, czy chcą czytać dalej czy rozpocząć pełne pobieranie. Dla katalogów, formularzy i ulotek informacyjnych ten podgląd jest często decydującym czynnikiem, dlaczego dokument jest w ogóle klikany.

Po trzecie: dostępne udostępnianie dokumentów urzędowych i akademickich. PDF.js udostępnia warstwę tekstową PDF, dzięki czemu screen-readery mogą odczytywać treść, pod warunkiem że PDF został poprawnie wyeksportowany jako "Tagged PDF".

## Architektura techniczna

Dla TYPO3 PDF.js istnieje w dwóch wariantach: jako klasyczne rozszerzenie TYPO3, które dostarcza bibliotekę JavaScript i dodaje element treści w backendzie, lub jako czysta integracja sitepackage, w której assety PDF.js lądują bezpośrednio we własnym frontendowym build. Wariant rozszerzenia jest bardziej komfortowy dla redaktorów, bo mogą konfigurować wybór, standardowy zoom i parametry podglądu przez backend TYPO3. Wariant sitepackage jest czystszy dla deweloperów, bo kontroluje wersję i integruje się w istniejący proces build.

Technicznie PDF.js składa się z dwóch części: parsera, który ładuje plik PDF i rozkłada go na wewnętrzny graf obiektów, oraz viewera, który renderuje te obiekty w elemencie Canvas. Obie części działają kompletnie po stronie klienta. Podejście worker zapewnia, że parsowanie odbywa się w oddzielnym wątku i nie blokuje main-thread, ważne dla płynnego scrollowania w obszernych dokumentach.

Integracja odbywa się przez blok TypoScript i partial Fluid, który osadza iframe lub kontener z viewerem. URL PDF jest przekazywany jako parametr query, konfiguracja elementów UI (przyciski zoom, nawigacja stron, link pobierania) odbywa się przez blok konfiguracji viewera PDF.js.

## Częste problemy i rozwiązania

Pierwszym problemem jest Cross-Origin. Gdy PDF jest ładowany z innej domeny lub z S3, przeglądarka blokuje dostęp ze względów bezpieczeństwa. Rozwiązaniem jest albo prawidłowa konfiguracja CORS na serwerze plików, albo serwerowe proxy przez middleware TYPO3, które dostarcza PDF pod tą samą domeną.

Drugi problem: wydajność przy dużych dokumentach. 200-stronicowy podręcznik ładuje się szybko, viewer pokazuje również tylko widoczne strony. Problematyczne staje się, gdy sam PDF nie jest zoptymalizowany pod web i każdy pojedynczy obraz został osadzony w pełnej rozdzielczości druku. Pomaga tylko przeliczenie dokumentu źródłowego wcześniej za pomocą Ghostscript lub podobnego narzędzia, zanim trafi do FAL.

Trzeci problem: dostępność bez warstwy tekstowej. Gdy PDF jest czystym skanem bez OCR, screen-readery nie otrzymują tekstu. Wtedy sam PDF.js nic nie daje, PDF musi najpierw przejść przez OCR. Dla urzędów i instytucji publicznych to nie jest opcja, tylko obowiązek zgodnie z ustawą o dostępności cyfrowej i EN 301 549.

## Migracja i kompatybilność wersji

PDF.js jako biblioteka jest ciągle utrzymywane przez Mozillę i jest zasadniczo niezależne od wersji TYPO3. Powłoki rozszerzeń TYPO3, które integrują PDF.js, często jednak opóźniają się za wersją biblioteki. Kto aktualizuje na TYPO3 v12 lub v13, powinien sprawdzić, czy używane rozszerzenie ma kompatybilną wersję lub czy przejście na integrację sitepackage jest lepszą drogą.

W bezpośrednim porównaniu do pdfviewhelpers (serwerowe generowanie PDF) i rflipbook (efekt flipbooka) PDF.js jest opcją z najmniejszym overhead i najwyższą kompatybilnością przeglądarek. Dla pojedynczych osadzeń PDF to prawie zawsze lepszy wybór niż ciężkie rozwiązanie flipbook.

Kto sam wbudowuje PDF.js w sitepackage, powinien ustalić jasną strategię wersji. Biblioteka otrzymuje regularne aktualizacje bezpieczeństwa, bo parsery PDF są historycznie popularnym celem ataków. Roczny rytm update to minimum, dla urzędów i krytycznej infrastruktury raczej kwartalny. Integracja przez npm i frontendowy proces build czyni to zdecydowanie prostszym niż klasyczne kopiowanie do katalogu projektu.

Gosign integruje PDF.js jako komponent sitepackage lub jako rozszerzenie TYPO3, w zależności od tego, ile kontroli potrzebują redaktorzy. Przy projektach istniejących z viewerami legacy Gosign towarzyszy migracji i dba o to, aby dostępność cyfrowa i czas ładowania nie były poświęcane na rzecz komfortu.

--- pdfviewhelpers TYPO3 - PDF w przeglądarce | Gosign ---
> pdfviewhelpers: Wyświetlanie PDF bezpośrednio w przeglądarce. Konfiguracja, wydajność i alternatywy, z wykorzystaniem AI.

## pdfviewhelpers to standardowa odpowiedź, gdy TYPO3 ma generować PDF-y serwerowo z szablonów Fluid, od faktur przez bilety po kompletne raporty

Za nazwą "pdfviewhelpers" stoi częste nieporozumienie. Rozszerzenie nie renderuje PDF-ów w przeglądarce, lecz tworzy je serwerowo z szablonów Fluid. Redaktorzy i deweloperzy, którzy szukają rozwiązania do dynamicznego generowania PDF w TYPO3, trafiają tu właściwie: faktury, bilety, potwierdzenia, certyfikaty lub raporty są budowane przez te same ViewHelpery Fluid, które dostarczają też frontend. Celem jest utrzymanie generowania PDF bez zewnętrznego toolingu i bez osobnego workflow layoutu w stosie TYPO3.

Fakt, że rozszerzenie rozwiązuje zupełnie inny problem niż PDF.js czy rflipbook, w praktyce często staje się jasny dopiero późno. Kto szuka "TYPO3 PDF", szybko ląduje przy pdfviewhelpers i powinien wcześnie zadać sobie pytanie, czy potrzebna jest prezentacja czy generowanie. Do generowania rozszerzenie jest technicznie najsolidniejszym rozwiązaniem w otoczeniu TYPO3, bo buduje na paradygmacie Fluid, który deweloperzy i tak znają.

## Typowe scenariusze zastosowania

Klasycznym przypadkiem są potwierdzenia formularzy. Klient wypełnia na stronie TYPO3 formularz kontaktowy, zgłoszenie na wydarzenie lub formularz ofertowy, pdfviewhelpers generuje z wprowadzonych danych spersonalizowany PDF, który jest wysyłany e-mailem lub oferowany do pobrania. Szablon leży jako szablon Fluid w sitepackage, redaktorzy dostosowują tekst i placeholdery, bez konieczności dotykania kodu. Zaletą w stosunku do zewnętrznej usługi PDF jest to, że wszystkie dane nigdy nie opuszczają środowiska TYPO3, istotne dla ochrony danych i zgodności z RODO.

Drugim typowym zastosowaniem są automatycznie generowane zaświadczenia. Dostawcy szkoleń, izby i stowarzyszenia generują zaświadczenia uczestnictwa, certyfikaty lub legitymacje członkowskie z zawartości baz danych. Rozszerzenie łączy dane Extbase z szablonami layoutu i dostarcza gotowy dokument. Dużą zaletą jest, że szablon jest wersjonowany, zrozumiały w git i nie zależy od jednej osoby, która posiada ostatni szablon Word.

Trzeci przypadek: raporty i listy. Działy kontrolingu eksportują z bazy danych pielęgnowanej w TYPO3 miesięczny raport, na przykład jako eksport wewnętrznego dashboardu, listy produktów lub listy magazynowej, i otrzymują sformatowany PDF z nagłówkiem, stopką i paginacją.

## Architektura techniczna

pdfviewhelpers bazuje na TCPDF, ugruntowanej bibliotece PHP do generowania PDF, i przekłada jej funkcje na ViewHelpery Fluid. Deweloperzy zamiast kodu PHP TCPDF piszą szablon, w którym elementy jak "pdf:document", "pdf:page", "pdf:text" i "pdf:image" pojawiają się jako tagi. To odpowiada dokładnie sposobowi myślenia, który deweloperzy Fluid znają z frontendu.

Rozszerzenie jest instalowane przez Composer, TCPDF jest wciągane jako zależność. Szablony leżą w sitepackage pod Resources/Private/Templates/Pdf i są wywoływane przez własny kontroler lub bezpośrednio z akcji Extbase. Dla wstrzykiwania zmiennych pdfviewhelpers używa tych samych mechanizmów co regularne widoki Fluid, dzięki czemu źródła danych i logika biznesowa mogą być czysto rozdzielone.

Konfiguracja odbywa się przez TypoScript i konfigurację rozszerzenia w Install-Tool, gdzie są zapisywane defaults dla formatu papieru, czcionek i marginesów. Kto chce używać własnych czcionek TrueType, musi je przekonwertować zgodnie z procedurą TCPDF i umieścić w Resources/Private/Fonts/.

## Częste problemy i rozwiązania

Najczęstszym problemem jest prezentacja czcionek. TCPDF nie obsługuje każdego pliku czcionek out-of-the-box, szczególnie nie aktualnych Variable Fonts ani Web Fonts w formacie WOFF2. Polskie znaki ą, ę, ł, ś, ż, ź, ć, ń, ó są wtedy zastępowane pytajnikami lub prostokątami. Rozwiązanie: wcześniej przekonwertować czcionkę za pomocą narzędzia TCPDF "tcpdf_addfont.php" i sprawdzić zakres Unicode. Dla dokumentów wielojęzycznych z cyrylicą lub znakami azjatyckimi opłaca się użycie rodziny czcionek z szerokim pokryciem glifów jak Noto Sans.

Drugi problem: złożone layouty. Gdy dokument potrzebuje treści wielokolumnowych, pływających grafik lub dynamicznych podziałów, TCPDF napotyka granice. Paginacja i footer mogą nie działać w pełni synchronicznie. Pragmatyczne rozwiązanie: zredukować layout do prostego, raportowego układu i osadzać złożone grafiki jako gotowe obrazy. Jeśli wymagania są naprawdę typograficznie wysokie, alternatywa jak Headless Chrome z konwersją HTML-do-PDF jest często lepszym wyborem.

Trzeci problem: wydajność przy dużych dokumentach. 100-stronicowy raport z wieloma obrazami może blokować proces PHP przez kilka sekund. Rozwiązanie leży w przetwarzaniu kolejkowym: generowanie PDF wyłączyć z cyklu życia requestu, uruchamiać jako background-job z EXT:scheduler lub rozszerzeniem kolejki i wysyłać użytkownikowi link do pobrania e-mailem.

## Migracja i kompatybilność wersji

pdfviewhelpers jest ciągle utrzymywane i jest kompatybilne z TYPO3 v11, v12 i v13. Przy upgrade należy uważać przede wszystkim na skok wersji PHP: starsze wersje TCPDF mają z PHP 8.2 i 8.3 problemy kompatybilności, szczególnie przy deprecated-warnings. Rozwiązaniem jest zazwyczaj update wersji pdfviewhelpers, która podciąga kompatybilną wersję TCPDF.

Kto prowadzi jeszcze samodzielnie napisaną konfigurację TCPDF z czasów TYPO3 przed v9, ma przy migracji na pdfviewhelpers szansę na przeniesienie layoutów PDF z kodu PHP do utrzymywalnych szablonów Fluid. To się średnioterminowo opłaca, bo redaktorzy mogą sami robić proste dostosowania, zamiast zawsze blokować czas dewelopera.

Dla startów od zera opłaca się spojrzenie na kombinację pdfviewhelpers i alternatyw Headless Chrome jak wkhtmltopdf lub Gotenberg. Dla czysto formularzowych PDF i prostych raportów pdfviewhelpers jest najszybszym i najbardziej stabilnym wyborem. Gdy jednak w grę wchodzą typograficznie wymagające layouty z web-fonts, kolumnami i grafikami tła, pipeline oparty na HTML pokazuje swoje mocne strony. Decyzja powinna zapaść wcześnie w projekcie, bo późniejsza zmiana pipeline'u wymaga kompletnej przebudowy szablonów.

Gosign wdraża pdfviewhelpers, migruje legacy setupy TCPDF i doradza w kwestii alternatyw dla złożonych layoutów. Kombinacja doświadczenia TYPO3 i wspieranego przez AI generowania szablonów skraca wdrożenie zazwyczaj o ponad połowę.

--- personnel TYPO3 - Katalog pracowników | Gosign ---
> Rozszerzenie TYPO3 do katalogów pracowników. Zespoły, działy, dane kontaktowe, zdjęcia profilowe.

## personnel organizuje katalogi pracowników jako własny model danych

Strony zespołu, listy osób kontaktowych i katalogi działów są na stronach firmowych standardem, ale nie da się ich sensownie pielęgnować jako element treści. Kto zarządza 50 pracownikami z imieniem, funkcją, zdjęciem, telefonem, e-mailem, LinkedIn, działem i lokalizacją, potrzebuje własnego modelu danych. Rozszerzenie personnel przynosi dokładnie to: porządną tabelę dla osób, połączoną z działami i lokalizacjami, dostarczaną przez konfigurowalne szablony Fluid. W każdym średnim projekcie TYPO3 z obecnością firmową to wymaganie powraca wielokrotnie, a personnel jest jednym z ugruntowanych rozwiązań. Alternatywy jak tt_address często są niewystarczające, bo brakuje im struktury działów, logiki filtra i porządnej integracji FE.

## Typowe scenariusze zastosowania to kancelarie, agencje i uczelnie

Kancelarie prawnicze są klasycznym use case. Kancelaria z 30 prawnikami i 10 paralegalami potrzebuje strony zespołu z filtrowaniem po specjalizacjach (prawo pracy, prawo podatkowe, prawo spadkowe), po lokalizacjach (Warszawa, Kraków, Wrocław) i po funkcji (partner, associate, aplikant). personnel dostarcza model danych, a rozszerzenie można z kilkoma dostosowaniami Fluid rozbudować do pełnego katalogu kancelarii. Każdy profil prawnika zawiera dodatkowo uprawnienia, członkostwa i opublikowane artykuły branżowe, dzięki czemu klienci na pierwszy rzut oka znajdują odpowiednią osobę kontaktową.

Agencje i firmy doradcze używają personnel na strony zespołu z krótkimi biografiami, specjalizacjami i linkami kontaktowymi. Tu mniej ważne jest filtrowanie, a bardziej prezentacja: duże portrety, cytaty, przyciski LinkedIn i wewnętrzne linki do case studies, w których osoba była zaangażowana. Strona zespołu staje się witryną, a personnel dostarcza model danych, bez konieczności tworzenia dla każdego pracownika własnego elementu treści.

Uczelnie i instytucje badawcze mają inne wymaganie: pracownicy są często powiązani z instytutami, katedrami i projektami badawczymi. personnel staje się wtedy bazowym modelem danych, który jest referencjonowany przez artykuły news, listy publikacji i wydarzenia. Osoba pojawia się nie tylko na stronie zespołu, ale również jako autor w publikacjach i jako osoba kontaktowa przy projektach badawczych. Rozszerzenie staje się tym samym centralną bazą danych osób, z której równolegle korzysta kilka sub-rozszerzeń i która przez lata dostarcza spójne profile.

## Architektura techniczna jest oparta na Extbase z relacjami do działu i lokalizacji

personnel definiuje trzy centralne tabele: tx_personnel_domain_model_personnel, tx_personnel_domain_model_department i tx_personnel_domain_model_location. Osoba jest przez foreign_field lub relację MM połączona z jednym lub kilkoma działami, dodatkowo z lokalizacją. Schemat bazy danych odwzorowuje tym samym typową organizację macierzową.

Pola osoby pokrywają standardowe atrybuty: tytuł, imię, nazwisko, funkcja, krótki opis, telefon, komórka, faks, e-mail, adres, zdjęcie profilowe (FAL), linki social-media. Przez TCA-Overrides można uzupełniać dodatkowe pola jak specjalizacje, certyfikaty czy języki, bez forkowania rozszerzenia.

Plugin renderuje przez szablony Fluid z katalogu EXT. Standardowe warianty to lista, detal i widok filtra. Kto buduje na systemach grid jak CSS-Grid lub Flexbox, nadpisuje szablon listy we własnym pakiecie. Do filtrowania i wyszukiwania rozszerzenie używa Extbase-Repositories z filtrami querybuilder, które można konfigurować w TypoScript. Typowa implementacja Gosign oferuje we frontendzie wyszukiwanie pełnotekstowe po nazwie i funkcji w połączeniu z filtrami select dla działu i lokalizacji, dzięki czemu użytkownicy z 200 pracowników znajdują właściwą osobę kontaktową w kilku kliknięciach.

## Częste problemy dotyczą RODO, praw do zdjęć i wielojęzyczności

Pierwszym i najważniejszym tematem wsparcia jest RODO. Dane pracowników są danymi osobowymi, a publikacja wymaga albo zgody, albo prawnie uzasadnionego interesu. Kto pracuje ze zdjęciami, numerami wewnętrznymi i prywatnymi numerami komórkowymi, potrzebuje porządnego procesu: dokumentacja zgody, przełącznik on-off per osoba, automatyczne usuwanie po odejściu. personnel nie dostarcza w standardzie auditlogu, ale workflow można odwzorować własnymi formularzami i dodatkowym polem consent. Przy odejściu z firmy rekord nie powinien być po prostu usuwany, lecz pozostawać wyłączony przez mechanizm soft-delete, aby stare wpisy news nadal poprawnie się rozwiązywały.

Drugim tematem są prawa do zdjęć. Zdjęcia profilowe leżą w FAL i są dostarczane przez warianty per prezentacja. Ważne, żeby copyright i zgoda pracownika były udokumentowane, szczególnie gdy zdjęcie jest używane również jako teaser w news lub w social media. Zalecamy konsekwentnie pielęgnować pola FAL "Fotograf" i "Licencja".

Po trzecie, wielojęzyczność to praktyczny problem. Osoba ma jedno imię, ale jej funkcja i krótka biografia różnią się w polskim i angielskim. personnel wspiera standard TYPO3 dla tłumaczeń, ale wiele projektów zapomina również zlokalizować rekordy działów i lokalizacji, co prowadzi do mieszanych wyjść językowych.

## Migracja na TYPO3 v12 wymaga update Extbase i przeglądu TCA

personnel jest dostępne dla różnych wersji TYPO3 w TER. Przy upgrade instalacji v10 lub v11 repozytoria Extbase muszą być przestawione na aktualne Persistence-API, a struktura TCA powinna być sprawdzona pod kątem niekompatybilności typów (szczególnie przy polach "passthrough" i "none", które w v12 są surowiej walidowane).

Gosign migruje instalacje personnel często przy okazji refactoringu stron zespołu. W tym samym kroku sprawdzamy, czy zbiór danych można podnieść do bardziej nowoczesnego schematu Person (z oznaczeniem JSON-LD), czy filtry i wyszukiwanie wydajnie radzą sobie z dużymi zbiorami danych, i czy strona zespołu jest responsywna i dostępna. Dla projektów z ekstremalnie dużymi zbiorami (kilka tysięcy osób) opłaca się dodatkowo spojrzenie na indeksowanie i lazy-loading, żeby widok listy nie był hamulcem na urządzeniach mobilnych. Przy szczególnie złożonych strukturach zespołu okazjonalnie zastępujemy personnel własnym modelem Extbase, gdy standardowa struktura pól nie wystarcza lub wymagane jest podłączenie do zewnętrznego systemu HR.

--- PhotoSwipe TYPO3 - Lightbox | Gosign ---
> PhotoSwipe to zoptymalizowana pod kątem dotyku biblioteka Lightbox. Rozszerzenie TYPO3 integruje PhotoSwipe jako galerię obrazów: zoom, gesty swipe.

## Galerie obrazów na urządzeniach mobilnych działają tylko ze zoptymalizowanymi pod kątem dotyku Lightboxami

Większość witryn TYPO3 wykorzystuje Lightboxy zaprojektowane dla przeglądarek desktopowych: Fancybox, Colorbox, Magnific Popup. Na smartfonach i tabletach takie rozwiązania sprawiają wrażenie obcych, ponieważ zoom i nawigacja nie reagują na gesty dotykowe, lecz na kliknięcia myszy. PhotoSwipe to biblioteka JavaScript zbudowana od podstaw z myślą o dotyku. Rozszerzenie TYPO3 integruje PhotoSwipe jako pełnoprawną galerię obrazów z funkcjami pinch-to-zoom, nawigacji gestem swipe, deep-linkingu i responsywnego układu. Przy rozmiarze poniżej 30 KB (minified + gzip) PhotoSwipe jest zarazem jednym z najlżejszych rozwiązań Lightbox na rynku.

Dla witryn z dużym udziałem ruchu mobilnego, czyli praktycznie wszystkich dzisiejszych serwisów, nie jest to opcjonalne usprawnienie, lecz funkcjonalny wymóg. Odwiedzający oczekują tych samych gestów, które znają z natywnej aplikacji Zdjęcia w swoim smartfonie.

## Typowe scenariusze zastosowania obejmują galerie portfolio, zdjęcia produktów i archiwa medialne

Najczęstszym scenariuszem są galerie portfolio na stronach agencji, biur architektonicznych i fotografów. Fotograf prezentuje od 20 do 40 zdjęć na projekt. Odwiedzający klikają miniaturę, widzą obraz w pełnej rozdzielczości, powiększają go gestem pinch i przesuwają się do kolejnego. Deep-linking oznacza, że każdy obraz ma własny adres URL, który można udostępnić lub podlinkować. Ma to znaczenie dla SEO, ponieważ Google indeksuje zdjęcia za pośrednictwem tych adresów.

Drugim scenariuszem są strony szczegółów produktów w instalacjach TYPO3 zbliżonych do e-commerce. Producent mebli pokazuje pięć perspektyw na produkt. PhotoSwipe renderuje je jako galerię z zoomem o wysokiej rozdzielczości, aktywowanym kółkiem myszy na desktopie i podwójnym kliknięciem na ekranach dotykowych. Jakość zoomu zależy bezpośrednio od rozdzielczości pliku źródłowego. Zalecamy minimum 2000 pikseli szerokości dla zdjęć produktowych przeznaczonych do oglądania w powiększeniu.

Trzeci scenariusz: archiwa medialne i sekcje prasowe. Uczelnia udostępnia 500 zdjęć z wydarzeń. PhotoSwipe renderuje galerię wydajnie, ponieważ obrazy ładowane są dopiero podczas przeglądania (lazy loading). Widok miniatur prezentuje 50 zdjęć na stronę bez zauważalnego czasu ładowania.

## Architektura techniczna integruje PhotoSwipe jako element treści TYPO3

Rozszerzenie rejestruje własny element treści w backendzie TYPO3. Redaktorzy wybierają obrazy z mediateki FAL, definiują kolejność i ustawiają opcjonalne podpisy. Renderowanie odbywa się przez szablony Fluid, które inicjalizują bibliotekę JavaScript PhotoSwipe i przekazują adresy URL obrazów jako tablicę JSON.

Sam PhotoSwipe nie ma zależności, nie wymaga jQuery ani frameworka. Biblioteka składa się z jednego pliku CSS i jednego pliku JS. Rozszerzenie TYPO3 ładuje oba przez TypoScript-AssetCollector, dzięki czemu są one dołączane wyłącznie na stronach faktycznie zawierających galerię. Pozwala to uniknąć zbędnych żądań na stronach bez galerii.

Dla obrazów responsywnych rozszerzenie obsługuje atrybut srcset: przeglądarka pobiera odpowiedni rozmiar obrazu w zależności od viewportu. Image-Processing TYPO3 generuje warianty automatycznie. W połączeniu z konwersją WebP (zob. rozszerzenie webp) galerie PhotoSwipe osiągają optymalne czasy ładowania.

## Częste problemy dotyczą konfliktów z innymi rozszerzeniami Lightbox i brakujących wymiarów obrazów

Najczęstszym problemem jest konflikt z już zainstalowanym rozszerzeniem Lightbox. Gdy Fancybox i PhotoSwipe są aktywne jednocześnie, oba reagują na kliknięcia obrazów i tworzą podwójne nakładki. Rozwiązanie: dezaktywować stare rozszerzenie Lightbox i usunąć jego wpisy CSS/JS z konfiguracji TypoScript. Komenda grep po słowach "fancybox" lub "colorbox" w plikach TypoScript pokazuje, czy pozostałości starej biblioteki są nadal ładowane.

Drugi problem: brakujące wymiary obrazów. PhotoSwipe potrzebuje rzeczywistych wymiarów w pikselach do prawidłowego działania zoomu. Jeśli rozszerzenie nie może ich odczytać z metadanych FAL, zoom nie działa lub przeskakuje na nieprawidłowy rozmiar. Rozwiązanie: sprawdzić metadane FAL wszystkich obrazów w galerii. TYPO3 odczytuje width i height automatycznie podczas wgrywania, ale obrazy importowane lub dodane przez CLI mają niekiedy puste metadane.

## PhotoSwipe v5 działa pod TYPO3 v12, kompatybilność z v13 wymaga aktualizacji szablonów

Aktualna biblioteka PhotoSwipe ma wersję 5. Rozszerzenie TYPO3 było dostosowywane do różnych wersji TYPO3 i działa stabilnie pod v12. Dla TYPO3 v13 konieczna jest aktualizacja szablonów Fluid i konfiguracji TypoScript, ponieważ v13 nieznacznie zmieniło przepływ pracy AssetCollector. Gosign aktualizuje przy upgrade'ach TYPO3 wszystkie rozszerzenia frontendu wraz z Lightbox i sprawdza, czy gesty dotykowe poprawnie działają na aktualnych wersjach iOS i Android.

--- powermail TYPO3 - Formularze i CRM | Gosign ---
> Najpopularniejszy plugin formularzy dla TYPO3. Formularze kontaktowe, wieloetapowe, logika warunkowa, eksport PDF, integracja CRM.

## powermail to produkcyjnie gotowy system formularzy dla TYPO3

Między TYPO3-Core-Form-Framework a kompletnymi narzędziami marketing-automation istnieje w praktyce luka: redakcje chcą budować formularze bez kodu, z logiką warunkową, uploadem plików, zgodą RODO, przekazywaniem do CRM i porządnym eksportem PDF. Dokładnie do tego zbudowano powermail. Rozszerzenie od in2code jest najczęściej instalowanym pluginem formularzy w ekosystemie TYPO3 i działa w większości średnich i dużych projektów TYPO3, którymi opiekuje się Gosign. Od pierwszej wersji ponad dekadę temu powermail rozwinął się w szwajcarski scyzoryk tworzenia formularzy TYPO3 i jest również ważnym wyborem, gdy TYPO3-Core-Form-Framework teoretycznie by wystarczył.

## Typowe scenariusze zastosowania sięgają od formularzy kontaktowych po portale rekrutacyjne

Najczęstszy scenariusz jest trywialny, ale nieunikniony: formularze kontaktowe na stronach firmowych, które wysyłają e-maile do różnych działów. powermail pozwala na to przez warunkowe trasy odbiorców, bez konieczności ingerencji dewelopera. Redaktorzy pielęgnują pola w backendzie jak zawartość strony, wraz z kolejnością, polami obowiązkowymi i walidacją. Typowa instalacja firmowa ma trzy do pięciu wariantów formularza: ogólne zapytanie kontaktowe, kontakt prasowy, kariera, support i doradztwo produktowe. Każdy wariant trafia przez własny filtr odbiorcy do właściwej skrzynki działowej.

Znacznie bardziej wymagające są wieloetapowe formularze rekrutacyjne, jak są stosowane w instytucjach publicznych i uczelniach. Portal rekrutacyjny pyta w kroku 1 o dane podstawowe, w kroku 2 o wybrany kierunek studiów, w kroku 3 o świadectwa przez upload, a w kroku 4 o zgodę RODO z linkiem do polityki prywatności. powermail renderuje wszystkie cztery kroki z jednego rekordu formularza i zapisuje postęp między krokami w sesji, dzięki czemu kandydat może w razie potrzeby wrócić. Warunki pokazują lub ukrywają pola w zależności od wcześniejszych odpowiedzi, co przy złożonych formularzach jak wnioski stypendialne lub zgłoszenia habilitacyjne czyni przejrzystą trzycyfrową liczbę kombinacji pól.

Trzeci scenariusz, który odróżnia powermail od prostszych rozszerzeń, to integracja z narzędziami CRM i marketingowymi. Architektura finisherów pozwala na równoległe wysyłanie danych do HubSpot, Salesforce, Brevo lub własnego webhooka, zanim mail potwierdzający trafi do nadawcy. W Gosign powermail jest dlatego również standardowym narzędziem dla formularzy lead, które bezpośrednio wprowadzają dane do procesu sprzedaży. W projekcie enterprise podłączyliśmy powermail do Salesforce Marketing Cloud i jednocześnie przekazywaliśmy przez webhook do wewnętrznego systemu ticketowego, dzięki czemu zespoły sprzedaży i wsparcia mogą równolegle uzyskiwać dostęp do zapytania.

## Architektura techniczna rozdziela definicję formularza, finisher i szablon

powermail składa się z trzech warstw koncepcyjnych: definicji formularza w backendzie, finisherów, które są wykonywane po wysłaniu, i szablonów Fluid, które przejmują renderowanie. Każda warstwa jest rozszerzalna, bez forkowania rozszerzenia. To czyste rozdzielenie czyni powermail solidnym narzędziem dla długowiecznych projektów TYPO3, w których formularze są pielęgnowane i rozszerzane przez lata.

Formularze są zakładane jako rekordy w tx_powermail_domain_model_form. Każdy formularz zawiera Pages (kroki), każda Page zawiera pola. Typy pól sięgają od tekstu, e-maila, select, radio, file-upload po HTML-Content i checkboxy zgody. Logika warunkowa jest pielęgnowana przez moduł Conditions: "Pokaż pole B tylko wtedy, gdy pole A ma wartość X".

Finisher są właściwą siłą rozszerzenia. Standardowy finisher wysyła e-maile, zapisuje wpisy w bazie danych i tworzy eksporty PDF. Kolejne finishery można implementować przez FinisherInterface: wysłanie webhooka, synchronizacja z CRM, Salesforce, przekazanie do SAP. Kolejność finisherów jest konfigurowalna, a każdy finisher może przerwać proces w razie błędu.

Szablony leżą jako pliki Fluid w ścieżce EXT i są zazwyczaj nadpisywane przez SiteSet lub własny pakiet. Oznacza to: jeden globalny template-overlay wystarcza, żeby ujednolicić wszystkie formularze strony. Kto zamiast tego potrzebuje własnych szablonów per formularz, może przekonfigurować ścieżki szablonów przez TypoScript i pielęgnować template-set per typ formularza.

## Częste problemy dotyczą spamu, RODO i dostarczalności e-maili

Dominującym tematem wsparcia przy publicznych formularzach powermail jest spam. Out of the box rozszerzenie przynosi pola honeypot, sprawdzanie znacznika czasu i opcjonalne ReCaptcha v3 przez ext:powermailrecaptcha. Mimo to spam trafia do backendu, gdy administracja nie aktywowała mechanizmów sprawdzania. Zalecamy w każdym formularzu łączyć honeypot ORAZ ReCaptcha i dodatkowo używać finisher rate-limit oparty na IP.

Drugim problemem jest zgodność z RODO. Zgody formularzowe muszą być dokumentowane w sposób rewizyjnie bezpieczny: data, wersja polityki prywatności, IP i User-Agent. Rozszerzenie oferuje do tego Consent-Storage, który oddzielnie protokołuje zgody i czyni je eksportowalnymi do audytów.

Po trzecie, dostarczalność e-maili to stały temat. Maile potwierdzające trafiają do spamu, bo nadawca nie jest uwierzytelniony. SPF, DKIM i DMARC muszą być prawidłowo skonfigurowane na poziomie serwera poczty, a konfiguracja powermail powinna ustawić Return-Path i ważny Reply-To. Przy dużych instalacjach zalecamy dodatkowo dedykowaną usługę maili transakcyjnych jak Brevo, Mailgun lub Amazon SES, żeby współczynnik dostarczalności nie cierpiał pod ogólną reputacją serwera.

## TYPO3 v12 i v13 są w pełni wspierane

powermail jest przy każdym wydaniu LTS TYPO3 szybko dostępny, bo in2code aktywnie utrzymuje rozszerzenie. Aktualna seria wspiera TYPO3 v11, v12 i v13 równolegle. Przy upgrade starszych instalacji breaking changes dotyczą przede wszystkim własnych klas finisherów, które muszą być przestawione na aktualną sygnaturę interfejsu, oraz szablonów Fluid, które reagują na zmiany ViewHelperów.

Gosign migruje instalacje powermail zazwyczaj wraz z upgrade core TYPO3. Przy tym sprawdzamy przed skokiem, które własne finishery i szablony istnieją, które integracje stron trzecich są podłączone i czy przestarzałe warianty pluginu są jeszcze w użyciu. Migracja zazwyczaj przebiega bez migracji danych, bo struktura rekordów definicji formularzy pozostaje stabilna.

--- powermailrecaptcha TYPO3 - reCAPTCHA | Gosign ---
> Integracja Google reCAPTCHA dla Powermail. Ochrona antyspamowa dla najpopularniejszego pluginu formularzy TYPO3.

## Powermail bez ochrony antyspamowej w ciągu tygodni zmienia się w wysypisko

Powermail to zdecydowanie najczęściej używane rozszerzenie formularzy dla TYPO3. Ponad 150 000 aktywnych instalacji (stan: TER, 2026) - od formularzy kontaktowych przez formularze rekrutacyjne po złożone wieloetapowe ścieżki zapytań. Problem: każdy publicznie dostępny formularz bez CAPTCHA prędzej czy później zostaje odnaleziony przez boty. Typowa konsekwencja: od 200 do 500 wpisów spamowych dziennie, przepełnione skrzynki pocztowe, zaszumione statystyki i formularze, które pracownicy w końcu ignorują - łącznie z prawdziwymi zapytaniami.

powermailrecaptcha to oficjalne uzupełnienie Powermail, które integruje Google reCAPTCHA v2 lub v3 z formularzami Powermail. Rozszerzenie jest utrzymywane przez in2code (twórcę Powermail), co gwarantuje krótkie cykle aktualizacji i wysoką kompatybilność.

## Typowe scenariusze zastosowań

**Formularze kontaktowe na stronach firmowych.** Standardowy scenariusz: formularz z imieniem, e-mailem, wiadomością i przyciskiem wysyłania. Bez CAPTCHA codziennie wpada od 50 do 300 wiadomości spam, głównie z linkami do stron farmaceutycznych czy kasynowych. reCAPTCHA v3 (niewidoczne, oparte na score) jest tu idealne: brak dodatkowego kliknięcia dla użytkownika, boty są rozpoznawane w tle. Score poniżej 0,5 (na skali od 0 do 1) jest klasyfikowany jako bot i wysyłka jest blokowana.

**Formularze aplikacyjne z uploadem plików.** Strony karierowe, na których kandydaci przesyłają CV i list motywacyjny, są szczególnie podatne na spam, ponieważ boty rozpowszechniają malware przez funkcję uploadu. reCAPTCHA filtruje automatyczne zapytania. Dodatkowo powinna być aktywna serwerowa weryfikacja typu pliku (tylko PDF, DOCX) i ograniczenie rozmiaru (maks. 10 MB).

**Wieloetapowe formularze z logiką warunkową.** Powermail może budować formularze z warunkami: gdy wybrano "Branża = Nieruchomości", pojawiają się dodatkowe pola. Przy takich formularzach wystarczy CAPTCHA na ostatniej stronie przed wysłaniem. powermailrecaptcha domyślnie wiąże sprawdzenie z przyciskiem Submit, więc działa również przy formularzach Multi-Step.

## Architektura techniczna

powermailrecaptcha rozszerza Powermail przez TYPO3 Signal/Slot (v11) lub PSR-14 Event (v12+). Przy renderowaniu formularza jest dołączany JavaScript reCAPTCHA (z google.com/recaptcha/api.js). Przy wysyłaniu token reCAPTCHA jest walidowany po stronie serwera: TYPO3 wysyła żądanie POST do `https://www.google.com/recaptcha/api/siteverify` z tokenem i Secret Key. Google odpowiada score (v3) lub potwierdzeniem (v2).

Konfiguracja odbywa się przez stałe TypoScript: Site Key i Secret Key (z Google reCAPTCHA Admin Console), próg score dla v3 (domyślnie: 0,5), wersja reCAPTCHA (v2 Checkbox, v2 Invisible lub v3). Klucze są zarządzane w backendzie TYPO3 pod Constants, idealnie przez zmienne środowiskowe, aby nie trafiały do repozytorium Git.

## Częste problemy i rozwiązania

**Obawy dotyczące UODO/RODO z powodu połączenia z Google.** reCAPTCHA ładuje JavaScript z serwerów Google i przesyła adres IP użytkownika do Google. Od wyroku Schrems II i coraz bardziej rygorystycznej interpretacji przez organy ochrony danych to realne ryzyko. Rozwiązanie: ładowanie reCAPTCHA tylko po zgodzie użytkownika przez baner cookie (integracja consent). Lub całkowite przejście na europejskie alternatywy: Friendly Captcha (serwery w UE, bez śledzenia), hCaptcha (bardziej zgodne z RODO niż reCAPTCHA, ale serwery w USA) lub czysta strategia honeypot bez zewnętrznych usług.

**reCAPTCHA v3 blokuje prawdziwych użytkowników.** Algorytm score to czarna skrzynka. Niektórzy prawdziwi użytkownicy (np. za VPN, z adblockerem, na starszych urządzeniach) otrzymują niskie score i są fałszywie blokowani. Rozwiązanie: ustawienie progu nie na 0,5, lecz na 0,3, i dodanie pola honeypot. Alternatywnie: przy niskim score wyświetlenie fallbacku na reCAPTCHA v2 Checkbox, zamiast bezpośredniego blokowania.

**Konflikt rozszerzenia z Content Security Policy.** Od TYPO3 v12 Core wspiera Content Security Policies (CSP). JavaScript reCAPTCHA z google.com musi być dozwolone w CSP, inaczej jest blokowane. Rozwiązanie: uzupełnienie w konfiguracji CSP `script-src` i `frame-src` o `https://www.google.com/recaptcha/` i `https://www.gstatic.com/recaptcha/`.

## Migracja i kompatybilność wersji

powermailrecaptcha wspiera TYPO3 v11, v12 i v13 (ostatnie od Q1 2026). Rozszerzenie podąża za cyklem wydań Powermail: gdy Powermail wspiera nową wersję TYPO3, powermailrecaptcha nadąża w ciągu kilku tygodni.

Dla projektów, które chcą przejść z reCAPTCHA na alternatywę przyjazną RODO/UODO, przebudowa jest przejrzysta. Friendly Captcha oferuje własny plugin Powermail (powermail_friendlycaptcha), który działa jako drop-in zamiennik: instalacja rozszerzenia, wpisanie kluczy, dezaktywacja powermailrecaptcha. Konfiguracja formularzy w Powermail pozostaje niezmieniona. Gosign zaleca Friendly Captcha jako standard dla nowych projektów.

Często pomijanym aspektem jest zapobieganie spamowi poza CAPTCHA. Powermail natywnie oferuje pole honeypot (niewidoczne pole formularza, które wypełniają tylko boty). W połączeniu ze sprawdzaniem czasu (formularz musi być otwarty przez co najmniej 3 sekundy przed wysłaniem) można odfiltrować większość automatycznego spamu bez zewnętrznych usług. Gosign stosuje w projektach, gdzie zgodność z RODO/UODO jest priorytetem, trzystopniową strategię: honeypot i sprawdzanie czasu jako pierwsza warstwa (0 zewnętrznych żądań), Friendly Captcha jako druga warstwa (serwery UE) i serwerowa analiza treści jako trzecia warstwa (gęstość linków, język, znane wzorce spamu). Ta kombinacja osiąga wskaźnik wykrywania spamu powyżej 99% bez usług Google.

--- Kalkulator TYPO3 - Kalkulator cen | Gosign ---
> Konfiguratory, kalkulatory kosztów, generatory ofert bezpośrednio w TYPO3. Custom-rozwój dla specyficznej logiki kalkulacji z interaktywnym frontendem.

## Kalkulatory cen w sieci generują kwalifikowane leady, ale tylko gdy kalkulacja jest poprawna

Odwiedzający, którzy obliczają cenę na stronie internetowej, są najbardziej wartościowymi leadami w sprzedaży B2B. Mają konkretny zamiar, znają swoje wymagania i oczekują wiarygodnej liczby. Mimo to większość witryn TYPO3 pracuje ze statycznymi tabelami cenowymi lub przyciskiem "Cena na zapytanie", który wysyła odwiedzającego do ogólnego formularza kontaktowego. pricecal wypełnia tę lukę: rozszerzenie umożliwia tworzenie konfiguratorów, kalkulatorów kosztów i generatorów ofert bezpośrednio w TYPO3, ze specyficzną logiką kalkulacji i interaktywnym frontendem reagującym w czasie rzeczywistym.

Różnica wobec narzędzi zewnętrznych typu Calconic czy Outgrow polega na tym, że dane pozostają na własnym serwerze, kalkulacja jest pod pełną kontrolą, a design wpisuje się płynnie w istniejącą witrynę. Dla polskich firm e-commerce oznacza to także swobodne posługiwanie się walutą PLN i możliwość integracji z porównywarkami cen Allegro czy Ceneo.

## Typowe scenariusze sięgają od kalkulatora przeprowadzkowego po konfigurator przemysłowy

Najbardziej dostępnym scenariuszem jest kalkulator kosztów dla usług. Firma przeprowadzkowa pyta o metraż mieszkania, piętro, odległość i wymagania specjalne (pianino, akwarium) i pokazuje cenę orientacyjną. Odwiedzający od razu wie, czy usługa mieści się w jego budżecie, i może bezpośrednio zamówić wiążącą ofertę. W praktyce takie kalkulatory zwiększają wskaźnik zapytań o 40 do 70 procent w porównaniu do statycznego formularza kontaktowego, ponieważ odwiedzający ma już oczekiwania cenowe.

Drugim scenariuszem są konfiguratory produktów w przemyśle wytwórczym. Producent okien oferuje 12 typów ram, 8 rodzajów szyb, 4 warianty okuć i 20 kolorów. pricecal oblicza cenę z kombinacji i pokazuje ją na żywo podczas konfiguracji. Przy 12 x 8 x 4 x 20 = 7 680 możliwych kombinacji statyczny cennik jest niemożliwy. Konfigurator zastępuje go dynamicznym obliczeniem, które redaktor utrzymuje w backendzie poprzez macierze cenowe.

Trzeci scenariusz: kalkulatory ROI dla produktów software'owych. Dostawca SaaS pozwala odwiedzającym wprowadzić liczbę pracowników, obecny czas pracy i stawkę godzinową. Kalkulator pokazuje roczne oszczędności wynikające z zastosowania produktu. Nie jest to chwyt sprzedażowy, lecz narzędzie pomagające odwiedzającemu uzasadnić inwestycję wewnątrz organizacji.

## Architektura techniczna oddziela logikę kalkulacji, pola wprowadzania i prezentację wyników

pricecal zaimplementowano jako Custom Content Element w TYPO3. W backendzie administrator definiuje pola wprowadzania (suwak, lista rozwijana, pole liczbowe, checkbox), formułę obliczeniową i sposób prezentacji wyniku. Formuła może odwzorować prostą arytmetykę (cena = ilość x cena jednostkowa x współczynnik) lub bardziej złożoną logikę z warunkami (jeśli piętro > 3, dodatek 15%).

Frontend renderuje pola wprowadzania przez szablony Fluid i oblicza cenę przez JavaScript w przeglądarce. Brak kolejnych zapytań do serwera przy każdym ruchu suwaka, wynik aktualizuje się w czasie rzeczywistym. Dla bardziej złożonych kalkulacji, na przykład gdy konieczne jest wpięcie macierzy cenowych lub zewnętrznych źródeł danych (ERP, dostępność magazynowa), obliczenie można delegować na serwer przez endpoint AJAX.

Wyniki można opcjonalnie generować jako PDF i wysyłać mailem. W połączeniu z powermail wynik kalkulacji można przekazać jako pole ukryte do formularza kontaktowego, dzięki czemu sprzedaż widzi dokładną konfigurację potencjalnego klienta.

## Częste problemy dotyczą błędów zaokrągleń i utrzymania złożonych logik cenowych

Najczęstszym problemem przy kalkulatorach cen jest poprawne zaokrąglanie. Arytmetyka zmiennoprzecinkowa JavaScript dla 0,1 + 0,2 zwraca wartość 0,30000000000000004. Przy cenach z dwoma miejscami po przecinku prowadzi to do widocznych błędów. Rozwiązanie: wszystkie obliczenia wykonywać wewnętrznie w groszach (liczby całkowite) i dopiero przy wyświetlaniu przeliczać na złote.

Drugi problem: utrzymanie logiki kalkulacji. Gdy product manager kwartalnie aktualizuje ceny, musi rozumieć formuły w backendzie. Dla prostych kalkulacji (ilość x cena) jest to trywialne. Przy konfiguratorach z 50 parametrami i progowymi rabatami utrzymanie staje się ryzykiem. Zalecamy przenoszenie złożonej logiki cenowej do konfiguracji TypoScript lub pliku YAML i utrzymywanie jej z wersjonowaniem w Git, zamiast edytować w backendzie.

Trzeci temat: obsługa mobilna. Suwaki na ekranach dotykowych są nieprecyzyjne, ponieważ palec pokrywa większy obszar niż wskaźnik myszy. Przy kalkulatorach cen z drobną granulacją (np. metry kwadratowe od 10 do 500) suwaki należy zastąpić polami wprowadzania z przyciskami plus/minus.

## pricecal jest custom-rozwojem i przez to niezależny od wersji

Ponieważ pricecal nie jest rozszerzeniem społecznościowym z TER, lecz custom-rozwojem, nie ma zewnętrznego cyklu wydawniczego. Kompatybilność z TYPO3 zależy od tego, jak rozszerzenie jest zaimplementowane wewnętrznie. Instalacje oparte na Extbase i Fluid działają pod TYPO3 v12 i v13 po dostosowaniu deklaracji namespace i rejestracji elementów treści. Gosign w nowych projektach kalkulatorów cen stawia na architekturę niezależną od frameworka: logika kalkulacji działa jako samodzielny moduł JavaScript, który TYPO3 osadza tylko jako element treści, bez zależności od Extbase.

--- Social Feed TYPO3 - Instagram i inne | Gosign ---
> Osadzanie feedów mediów społecznościowych (Instagram, Facebook, Twitter/X) w TYPO3. Oparte na API, cachowane, wyświetlane zgodnie z RODO bez pikseli śledzących.

## Feedy social media na stronie wyglądają dobrze, ale regularnie padają przez zmiany API

Zespoły marketingowe chcą wyświetlać posty z Instagrama, Facebooka czy Twittera/X na firmowej stronie. Pomysł jest zrozumiały: aktualne treści bez nakładu redakcyjnego, social proof przez prawdziwe posty, wizualne wzbogacenie materiałem graficznym. Praktyka wygląda inaczej. Meta, Twitter/X i TikTok regularnie zmieniają swoje API, ograniczają prawa dostępu lub całkowicie likwidują bezpłatne endpointy. Twitter/X w 2023 zlikwidował darmowy dostęp do API i od tego czasu żąda minimum 100 USD/miesiąc za prawa odczytu. Instagram Basic Display API zostało w 2024 zastąpione przez Instagram Graph API. Kto prowadzi integrację feedów społecznościowych, musi nadążać za tymi zmianami - inaczej feed pozostaje pusty.

pxa_social_feed (opracowane przez Pixelant) to najbardziej znane rozszerzenie TYPO3 dla feedów społecznościowych. Wspiera Instagram, Facebook i Twitter/X, przechowuje dane feedów lokalnie (cachowane) i renderuje je jako element treści TYPO3. Rozszerzenie jest open source i utrzymywane przez społeczność.

## Typowe scenariusze zastosowań

**Witryny korporacyjne z feedem Instagram na stronie głównej.** Firma publikuje 3 do 5 razy tygodniowo na Instagramie i chce wyświetlić najnowsze 6 do 12 postów jako galerię na stronie głównej. pxa_social_feed pobiera posty przez zadanie cron (np. co 30 minut), zapisuje obrazy, podpisy i linki lokalnie i renderuje je w konfigurowalnym gridzie. Zaleta wobec embeda (iframe): brak zewnętrznych żądań przy wywołaniu strony, brak pikseli śledzących, szybszy czas ładowania.

**Strony eventowe z feedem na żywo.** Konferencje, targi czy imprezy firmowe korzystają z hashtagu (np. #GosignSummit2026). Feed wyświetla wszystkie publiczne posty z tym hashtagiem w czasie rzeczywistym (lub prawie w czasie rzeczywistym z cachowaniem 5-minutowym). Moderacja odbywa się w backendzie TYPO3: poszczególne posty można ukryć, zanim pojawią się na stronie.

**Strony employer branding.** Działy HR wyświetlają na stronie karierowej wglądy z codziennego życia firmy, które pracownicy publikują na Instagramie lub LinkedIn. Integracja zbiera posty z jednego lub kilku kont i kuruje je redakcyjnie. Szczególność: LinkedIn nie oferuje otwartego API do integracji feedów, dlatego automatyzacja ogranicza się do Instagrama i Facebooka.

## Architektura techniczna

pxa_social_feed wykorzystuje API odpowiednich platform: Instagram Graph API (przez token Facebook-App), Facebook Graph API i Twitter/X API v2. Każda platforma wymaga własnego uwierzytelniania: Facebook i Instagram potrzebują Long-Lived User Token (ważny 60 dni, musi być regularnie odnawiany), Twitter/X potrzebuje Bearer Token (Application-only Auth).

Rozszerzenie przechowuje dane feedów w lokalnej tabeli TYPO3 (tx_pxasocialfeed_domain_model_feed). Obrazy są pobierane i zapisywane jako referencje FAL. Przy wywołaniu strony renderowane są tylko lokalne dane, bez zewnętrznych wywołań API. Zadanie Scheduler pobiera nowe posty i usuwa stare (konfigurowalne: zachowaj ostatnie 50 postów, usuń starsze).

Dla zgodności z UODO/RODO kluczowy jest lokalny cache: ponieważ obrazy i teksty leżą na własnym serwerze, przy wywołaniu strony żadne dane nie są przesyłane do Meta czy Twitter/X. Brak pikseli śledzących, brak potrzeby zgody na pliki cookie dla samego feedu. Wyjątek: gdy wbudowany jest link "Do oryginalnego postu", przy kliknięciu następuje przekierowanie.

## Częste problemy i rozwiązania

**Token Instagram wygasa, feed pozostaje pusty.** Long-Lived Token ma żywotność 60 dni. Jeśli nikt go nie odnowi, import się zatrzymuje. Rozwiązanie: skonfigurowanie cronjoba, który automatycznie przedłuża token przez wywołanie API (endpoint `GET /oauth/access_token?grant_type=fb_exchange_token` zwraca nowy token). pxa_social_feed od wersji 4.x oferuje funkcję odświeżania tokena w backendzie.

**Feed Twitter/X nie działa po zmianie API.** Od 2023 roku API Twitter/X jest płatne. Tarifa Basic (100 USD/miesiąc) pozwala na odczyt 10 000 tweetów/miesiąc. Dla większości firmowych stron to wystarczy, ale rachunek kosztów i korzyści musi się zgadzać. Rozwiązanie: sprawdzenie, czy feed Twitter/X rzeczywiście generuje ruch lub zaangażowanie. Jeśli nie - usunięcie kanału i pozostawienie tylko Instagrama/Facebooka.

**Obrazy nie ładują się lub są rozmyte.** Instagram Graph API dostarcza obrazy w różnych rozmiarach. pxa_social_feed domyślnie zapisuje wersję dostarczoną przez API. Rozwiązanie: ustawienie rozmiaru obrazu na "original" w konfiguracji rozszerzenia i generowanie responsywnych wariantów w szablonie Fluid przez `<f:image>`.

## Migracja i kompatybilność wersji

pxa_social_feed wspiera TYPO3 v11 i v12. Kompatybilność z TYPO3 v13 jest w fazie rozwoju społecznościowego (stan kwiecień 2026), ale nie jest jeszcze oficjalnie zatwierdzona. Dla projektów na TYPO3 v13 są dwie opcje: poczekać na oficjalną aktualizację lub zbudować własną integrację feedów jako middleware działającą niezależnie od wersji TYPO3.

Zasadniczo Gosign zaleca traktowanie integracji feedów społecznościowych jako oddzielnego komponentu: mikroserwis lub Cloudflare Worker pobiera feedy, zapisuje je jako JSON, TYPO3 odczytuje JSON i renderuje. Dzięki temu odpada zależność od rozszerzenia TYPO3 i każda zmiana API jest naprawiana w jednym miejscu, niezależnie od CMS.

Całkowity nakład dla integracji feedów społecznościowych (Instagram, cachowany, zgodny z UODO/RODO, z moderacją w backendzie) wynosi od 2 do 5 dni deweloperskich, w zależności od tego, czy pxa_social_feed wystarczy, czy potrzebne jest rozwiązanie niestandardowe.

--- RaiseNow TYPO3 - Darowizny | Gosign ---
> RaiseNow to szwajcarska platforma darowizn. Integracja z TYPO3 umożliwia darowizny online, cykliczne darowizny i kampanie. Dla NGO, stowarzyszeń i fundacji.

## Organizacje non-profit tracą darowizny, gdy proces wpłaty opuszcza witrynę

Każde przerwanie ścieżki kosztuje konwersję. Gdy odwiedzający kliknie "Wesprzyj teraz" i zostaje przekierowany na zewnętrzną platformę, według różnych badań od 30 do 50 procent użytkowników rezygnuje. RaiseNow to szwajcarska platforma darowizn rozwiązująca dokładnie ten problem: integracja z TYPO3 osadza cały proces wpłaty bezpośrednio w witrynie. Kwota, metoda płatności, dane adresowe i potwierdzenie przebiegają w osadzonym widżecie, bez konieczności opuszczania strony. Dla organizacji pożytku publicznego, stowarzyszeń i fundacji opartych o TYPO3 jest to najczystsza integracja między CMS-em a platformą darowizn.

RaiseNow przetwarza rocznie ponad 300 milionów franków w darowiznach i jest w Szwajcarii liderem cyfrowego fundraisingu. Rozszerzenie TYPO3 wprowadza ten ekosystem bezpośrednio do backendu - również dla polskich fundacji i organizacji pożytku publicznego (OPP) zbierających środki w międzynarodowym kontekście.

## Typowe scenariusze sięgają od jednorazowych wpłat po kampanie stałych darczyńców

Bazowym scenariuszem jest jednorazowa wpłata na stronie głównej lub stronie kampanijnej. Organizacja pomocowa uruchamia zbiórkę po katastrofie naturalnej. Strona docelowa pokazuje pasek postępu (zebrano / cel) i formularz wpłaty z proponowanymi kwotami (25, 50, 100, dowolna). Odwiedzający wpłaca kartą kredytową, BLIK-iem, przez PayPal lub Przelewy24, otrzymuje natychmiastowe potwierdzenie i pokwitowanie darowizny mailem. Cała transakcja trwa poniżej 60 sekund.

Drugim, ekonomicznie ważniejszym scenariuszem są darowizny cykliczne. Organizacja ochrony zwierząt oferuje miesięczne patronaty: 60 złotych miesięcznie na utrzymanie zwierzęcia. RaiseNow zarządza powtarzającymi się płatnościami, powiadamia o nieudanych obciążeniach i udostępnia darczyńcy portal samoobsługowy do edycji. Darowizny cykliczne stanowią u skutecznych fundacji 40 do 60 procent całego wolumenu, ponieważ generują przewidywalne wpływy.

Trzeci scenariusz: peer-to-peer fundraising. Klub sportowy organizuje bieg charytatywny. Każdy zawodnik tworzy osobistą stronę zbiórki, udostępnia ją w mediach społecznościowych i zbiera środki dla klubu. RaiseNow agreguje kwoty, przypisuje je do biegaczy i pokazuje ranking na żywo. Rozszerzenie TYPO3 udostępnia widok kampanii i osobiste profile zbiórek jako elementy treści.

## Architektura techniczna wykorzystuje widżety RaiseNow przez iFrame i webhook API

Rozszerzenie TYPO3 integruje RaiseNow przez widżet JavaScript osadzony w stronie jako iFrame. Konfigurację (klucz API, ID kampanii, metody płatności, kwoty proponowane) ustawia się w backendzie TYPO3 jako konfigurację pluginu i przekazuje do widżetu przez TypoScript.

Po udanej darowiźnie RaiseNow wysyła webhook na konfigurowalny endpoint. Webhook ten można przetwarzać w TYPO3, by logować darowizny w lokalnej bazie, aktualizować paski postępu lub uruchamiać maile z podziękowaniem przez wbudowany system mailowy TYPO3. Sama obsługa płatności działa w pełni na infrastrukturze RaiseNow, co umożliwia zgodność z PCI-DSS bez własnej certyfikacji.

Pokwitowanie darowizny generuje RaiseNow i zawiera ono wszystkie istotne informacje podatkowe. Dla organizacji uznanych w Polsce za organizacje pożytku publicznego (OPP) pokwitowanie można uzupełnić o numer KRS i informację o statusie OPP, niezbędną do odliczenia od podatku.

## Częste problemy dotyczą zgodności z RODO i stylizacji widżetu

Największym tematem dla polskich organizacji jest zgodność z RODO. RaiseNow to firma szwajcarska i przetwarza dane płatnicze na szwajcarskich serwerach. Od decyzji wykonawczej Komisji Europejskiej Szwajcaria uznawana jest za bezpieczny kraj trzeci, ale polityka prywatności musi mimo to przejrzyście wskazywać, jakie dane przekazywane są RaiseNow. Organizacje, które chcą działać z maksymalną ostrożnością, pozyskują wyraźną zgodę przez warstwę zgód, zanim widżet RaiseNow zostanie załadowany. UODO konsekwentnie wymaga takiej transparentności w zbiórkach online.

Drugi problem: stylizacja widżetu. Widżety RaiseNow mają własne CSS, którego nie da się w pełni nadpisać z zewnątrz. Kolory, czcionki i style przycisków można dostosować przez konfigurację RaiseNow, ale układ formularza jest stały. Dla organizacji z surowymi wytycznymi CI może to być kompromis. Alternatywą jest własny formularz darowizn odwołujący się bezpośrednio do API RaiseNow, co stawia jednak wymagania PCI-DSS względem własnej infrastruktury.

## RaiseNow jest aktywnie rozwijany, rozszerzenie TYPO3 wymaga ręcznego utrzymania

Sam RaiseNow jest stale rozwijany. Nowe metody płatności (Apple Pay, Google Pay) i funkcje (faktury QR) dodawane są regularnie. Rozszerzenie TYPO3 jest jednak projektem społecznościowym i nie jest oficjalnie utrzymywane przez RaiseNow. Oznacza to, że jeśli TYPO3 v13 wprowadzi zmianę w rejestracji pluginów, rozszerzenie trzeba będzie ręcznie dostosować. Organizacje wykorzystujące RaiseNow w TYPO3 długoterminowo powinny forknąć rozszerzenie do własnego repozytorium i utrzymywać je przy upgrade'ach TYPO3. Gosign przejmuje takie utrzymanie w ramach umów serwisowych i przy każdej aktualizacji TYPO3 sprawdza kompatybilność z RaiseNow.

--- rapidmail TYPO3 - Integracja newslettera | Gosign ---
> Integracja rapidmail z TYPO3: Synchronizacja subskrybentów, Double-Opt-In, segmentacja. Z wykorzystaniem AI, zgodne z RODO.

## rapidmail to pragmatyczna odpowiedź newsletterowa dla projektów TYPO3 wrażliwych na RODO

Kto w Polsce i Niemczech prowadzi newsletter w sposób prawnie pewny, prędzej czy później ląduje u niemieckich dostawców. rapidmail jest jednym z najczęściej używanych: niemieckie lokalizacje serwerów, niemiecki support, jasne modele cenowe, solidne API. Dla stron TYPO3, które zbierają zapisy na newsletter bezpośrednio we frontendzie, a odbiorcy mają automatycznie lądować w listach i segmentach, integracja tej usługi jest standardowym zadaniem. Wyniki są jednak często rozczarowujące, bo oficjalne rozszerzenie TYPO3 pokrywa tylko podstawowe funkcje, a projekty z prawdziwymi wymaganiami szybko napotykają granice.

Grupą docelową są średnie firmy, stowarzyszenia, przedsiębiorstwa komunalne, uczelnie, NGO i wydawnictwa, które chcą budować komunikację z istniejącymi klientami na platformie zgodnej z RODO. Typowy przypadek: regionalne przedsiębiorstwo energetyczne z 80 000 klientów domowych chce z czterema segmentami (klienci prywatni, klienci biznesowi, klienci programów wsparcia, kontakty prasowe) wysyłać ukierunkowane newslettery i automatycznie pobierać segmentację z grup użytkowników TYPO3.

## Typowe scenariusze zastosowania

Pierwszym scenariuszem jest prosta ścieżka zapisu przez Powermail. Stowarzyszenie chce dodawać odwiedzających swoją stronę TYPO3 do newslettera. Finisher Powermail przekazuje imię, e-mail i oznaczenie segmentu do API rapidmail, rapidmail wysyła mail potwierdzający, a po kliknięciu w link potwierdzający kontakt jest aktywowany na pasującej liście odbiorców.

Drugim scenariuszem jest synchronizacja grup użytkowników z TYPO3 do segmentów rapidmail. Uczelnia pielęgnuje w intranecie TYPO3 role jak studenci, absolwenci, pracownicy. Każda zmiana roli ma automatycznie dociągnąć przypisanie segmentu w rapidmail, żeby wysyłki trafiały do dokładnie właściwej grupy docelowej, bez podwójnej pielęgnacji danych.

Trzecim scenariuszem jest pielęgnacja uczestników wydarzeń. Wydawnictwo organizuje dziesięć konferencji branżowych rocznie i chce automatycznie przekazywać uczestników do kolejnej ścieżki komunikacji. Rejestracja odbywa się w formularzu TYPO3, API zapisuje uczestnika na liście wydarzenia, rapidmail wyzwala automatyczną kampanię drip z trzema mailami.

Czwartym scenariuszem jest synchronizacja wypisów. Gdy czytelnik wypisze się przez link newsletterowy w rapidmail, centrum profilu TYPO3 musi przejąć status, żeby użytkownik przy następnym logowaniu nie widział ponownie "newsletter aktywny". To wymaga kanału zwrotnego: rapidmail zgłasza wypisanie przez webhook, TYPO3 kwituje i aktualizuje grupę użytkowników.

## Architektura techniczna

rapidmail udostępnia REST-API z uwierzytelnianiem OAuth. Integracja TYPO3 odbywa się albo przez finisher Powermail, rozszerzenie Form Framework, albo własną usługę Extbase, która sięga do API. Gosign zazwyczaj stawia na smukłą klasę usługi, która enkapsuluje wywołania API i jest dostępna przez Dependency Injection w kontrolerach, finisherach i zadaniach schedulera.

Dla stałej synchronizacji grup użytkowników typowo konfigurowane jest zadanie schedulera, które co 15 minut przekazuje delta-updates do rapidmail. Wykrywanie delty przebiega przez wewnętrzne pole audit TYPO3 (ostatnia zmiana per użytkownik) lub przez porównanie hashy na bazie odpowiedzi API. Ważne, aby każda transmisja była zaprojektowana idempotentnie, aby ponowny przebieg po błędzie nie tworzył duplikatów.

Double-Opt-In jest w pełni obsługiwane po stronie rapidmail: TYPO3 zgłasza kontakt, rapidmail wysyła mail potwierdzający, czytelnik potwierdza, rapidmail aktywuje kontakt. TYPO3 nie musi do tego nic własnego dostarczać, ważne tylko, aby strona TYPO3 pokazała użytkownikowi zrozumiałą stronę pośrednią ("Proszę potwierdzić zapis w skrzynce odbiorczej").

## Częste problemy i rozwiązania

Pierwszym problemem jest brakująca obsługa zwrotów. Kto nie analizuje odpowiedzi API, nie zauważa, że rapidmail trwale odrzuca określone adresy e-mail. Rozwiązaniem jest logowanie odpowiedzi API we własnej tabeli TYPO3 plus okresowy abgleich list zwrotów, które rapidmail udostępnia przez API.

Drugim problemem są błędne przypisania segmentacji. Gdy kontakt wpada do kilku grup użytkowników, które wskazują na różne listy rapidmail, powstają niespójne stany. Rozwiązaniem jest jasna logika mapowania 1:1 lub 1:n, która jest porządnie zdefiniowana przed implementacją i twardo zakodowana w warstwie usługi.

Trzecim problemem jest naruszenie rate-limit API. rapidmail ogranicza użycie API. Przy początkowej migracji 20 000 kontaktów w jednym przebiegu schedulera zadanie nieuchronnie trafia w blokadę. Rozwiązaniem jest import oparty na chunkach ze 100 kontaktami per batch i sterowaniem pauzami między batchami.

Czwartym problemem jest nieostrość abgleichu przy podwójnych profilach. Gdy użytkownik zapisuje się wielokrotnie z różnymi zapisami e-maila (z/bez kropki, duże/małe litery), powstają duplikaty w rapidmail i niespójne stany między TYPO3 a systemem newslettera. Rozwiązaniem jest normalizacja adresu e-mail przed każdym wywołaniem API (lowercase, whitespace-trim, reguła kropki dla adresów Gmail świadomie ignorować lub konsekwentnie stosować).

## Migracja i kompatybilność wersji

Integracja jako Custom-rozszerzenie jest w dużej mierze niezależna od wersji TYPO3: działa czysto na TYPO3 v11, v12 i v13, jeśli kod klienta API stawia na nowoczesne klienty HTTP (Guzzle) i Dependency Injection. Przy upgrade istniejącej integracji najczęstszym punktem bólu jest migracja z hooków TYPO3 na middleware PSR-15, nakład, który Gosign z reguły z wsparciem AI w analizie kodu załatwia w kilka dni.

Po stronie rapidmail API zmienia się powoli, ale nie bez łamania: między wersjami major pojedyncze endpointy były przemianowywane, pola restrukturyzowane lub procedury uwierzytelniania modernizowane. Kto aktualizuje starszą integrację z 2018 lub 2020 roku do aktualnego stanu, powinien liczyć z połową sprintu na aktualizację API i uruchamiać testy wobec listy staging w rapidmail, zanim produkcja jest dotykana. Gosign pielęgnuje dla tych zadań odświeżania standardowy katalog kontrolny, który pokrywa typowe pułapki (uwierzytelnianie, paginacja, format odpowiedzi błędu) i czyni migrację odtwarzalną.

--- Plugin przepisów TYPO3 | Gosign ---
> Rozszerzenie przepisów dla TYPO3: Składniki, kroki przygotowania, wartości odżywcze, porcje.

## Przepisy bez Schema.org-Markup tracą najcenniejsze pozycje w wynikach wyszukiwania Google

Zapytania o przepisy należą do nielicznych obszarów, w których Google wyświetla Rich Snippets ze zdjęciem, oceną, czasem gotowania i kalorycznością. Witryny bez prawidłowego markup Schema.org/Recipe pojawiają się jako zwykłe niebieskie linki pod dominującymi wizualnie wynikami Rich Results. Rozszerzenie Recipe dla TYPO3 strukturyzuje przepisy ze wszystkimi polami, których Google oczekuje dla Rich Snippets: składniki, kroki przygotowania, wartości odżywcze, porcje, czas przygotowania, poziom trudności. Markup Schema.org generowany jest automatycznie w formacie JSON-LD, bez konieczności edycji HTML przez redaktorów.

Dla blogów kulinarnych, wydawnictw z rubrykami przepisów oraz producentów żywności z bazami przepisów to różnica między widocznością a niewidocznością w wyszukiwarce Google.

## Typowe scenariusze obejmują blogi kulinarne, witryny produktowe i portale zdrowotne

Najczęstszym scenariuszem jest blog kulinarny lub magazyn online z rubryką przepisów. Wydawca publikuje co tydzień pięć nowych przepisów. Każdy przepis tworzony jest w backendzie TYPO3 jako ustrukturyzowany rekord: tytuł, opis, lista składników z ilościami, kroki przygotowania jako numerowana lista, czasy (przygotowanie, gotowanie, łącznie), wartości odżywcze na porcję i zdjęcie tytułowe. Rozszerzenie generuje z tego stronę szczegółową z poprawnym markupem Schema.org. Google pokazuje w wynikach wyszukiwania zdjęcie, ocenę gwiazdkową, czas łączny i liczbę kalorii.

Drugim scenariuszem są witryny produktowe producentów żywności. Producent oliwy z oliwek pokazuje przy każdym produkcie pasujące przepisy. Przepisy linkują do produktu, produkt linkuje do przepisów. To dwukierunkowe powiązanie wzmacnia zarówno stronę produktu, jak i stronę przepisu w ocenie Google.

Trzeci scenariusz: portale zdrowotne i poradnie dietetyczne. Tutaj na pierwszy plan wysuwają się wartości odżywcze. Portal dla diabetyków pokazuje przepisy z wymiennikami węglowodanowymi, indeksem glikemicznym i zawartością węglowodanów na porcję. Rozszerzenie umożliwia Custom Fields, dzięki czemu te istotne medycznie wartości można rejestrować jako dane strukturalne i prominentnie wyświetlać we frontendzie.

## Architektura techniczna wykorzystuje rekordy Extbase z automatycznym wyjściem JSON-LD

Rozszerzenie rejestruje własny typ rekordu dla przepisów w bazie TYPO3. Każdy rekord zawiera pola dla tytułu, opisu, składników (jako Inline-Relational-Records), kroków (jako sortowalna lista), czasów (prepTime, cookTime, totalTime w formacie ISO-8601), wartości odżywczych (kalorie, tłuszcz, węglowodany, białko) i obrazów przez FAL.

Renderowanie frontendowe odbywa się przez szablony Fluid, które prezentują przepis jako stronę HTML, jednocześnie wpisując znacznik script JSON-LD z markupem Schema.org/Recipe do nagłówka strony. Markup zgodny jest ze specyfikacją Google: name, image, author, datePublished, description, prepTime, cookTime, totalTime, recipeYield, recipeIngredient, recipeInstructions oraz nutrition.

Widok listy pokazuje przepisy jako kafelki ze zdjęciem, tytułem, czasem łącznym i oceną. Filtry według kategorii (przystawka, danie główne, deser), sposobu odżywiania (wegetariańskie, wegańskie, bezglutenowe) i czasu przygotowania można konfigurować przez TypoScript.

## Częste problemy dotyczą brakujących pól obowiązkowych i nieprawidłowych formatów czasu

Największym problemem dla wyświetlania Rich Snippet są brakujące pola obowiązkowe. Google wymaga przynajmniej name, image i recipeInstructions. Gdy redaktor utworzy przepis bez zdjęcia lub bez kroków przygotowania, markup Schema.org wprawdzie zostaje wygenerowany, ale Google go ignoruje i nie wyświetla Rich Snippet. Rozwiązanie: w backendzie TYPO3 włączyć walidację pól obowiązkowych, tak aby przepisów bez zdjęcia i bez przynajmniej jednego kroku przygotowania nie dało się zapisać.

Drugi problem: nieprawidłowe formaty czasu. Schema.org oczekuje ISO-8601 Duration (PT30M dla 30 minut, PT1H15M dla 1 godziny i 15 minut). Jeśli rozszerzenie nie konwertuje wpisu redaktora "30 min" poprawnie na PT30M, walidacja w Google Rich Results Test się nie powiedzie. Większość rozszerzeń Recipe oferuje w tym celu osobne pola wprowadzania dla godzin i minut, które wewnętrznie są konwertowane do ISO-8601.

Trzeci temat: duplicate content przy przepisach osadzanych na wielu stronach. Gdy ten sam przepis jest w pełni wyświetlany na stronie kategorii i na stronie szczegółowej, powstają dwie strony z identycznym markupem Schema.org. Google ocenia to jako duplikat. Rozwiązanie: na stronach kategorii pokazywać tylko zajawki i pełny markup Schema.org generować wyłącznie na stronie szczegółowej.

## Rozszerzenie działa pod TYPO3 v11 i v12, dla v13 konieczna jest aktualizacja Extbase

Rozszerzenia Recipe w ekosystemie TYPO3 utrzymywane są przez różnych dostawców. Kompatybilność z TYPO3 v12 jest zapewniona przy aktywnie rozwijanych rozszerzeniach. Dla TYPO3 v13 zazwyczaj konieczne są dostosowania w konfiguracji modeli Extbase i definicjach TCA, ponieważ v13 usunął niektóre przestarzałe typy TCA. Gosign zaleca, by przy witrynach kulinarnych po każdej aktualizacji TYPO3 walidować wyjście Schema.org za pomocą Google Rich Results Test, aby zapewnić utrzymanie jakości markupu.

--- registeraddress TYPO3 - Subskrypcja newslettera | Gosign ---
> Rejestracja newslettera przez tt_address w TYPO3. Zarządzanie subskrybentami bezpośrednio w CMS bez zewnętrznego serwisu newsletter.

## Rejestracja newslettera bez zewnętrznych usług oszczędza koszty i zachowuje dane pod własną kontrolą

Mailchimp, Brevo, GetResponse: za każdą rejestrację newslettera organizacje płacą za subskrybenta i za wysłanego maila. Przy 10 000 subskrybentów daje to od 400 do 1 200 złotych miesięcznie, samej tylko za zarządzanie adresami. registeraddress oferuje alternatywę: rejestrację newslettera bezpośrednio w TYPO3 przez sprawdzoną tabelę tt_address. Zarządzanie subskrybentami, double opt-in, link wypisania i dokumentacja zgody zgodna z RODO przebiegają w pełni w CMS, bez dostępu zewnętrznej usługi do danych subskrybentów.

Dla stowarzyszeń, mniejszych wydawnictw i instytucji publicznych z ograniczonym budżetem to rozwiązanie sensowne, zwłaszcza jeśli wysyłka odbywa się przez tani relay SMTP (Amazon SES kosztuje ok. 0,40 zł za 1 000 maili) lub własny serwer pocztowy.

## Typowe scenariusze obejmują newslettery stowarzyszeń, dystrybucję intranetową i zapisy na wydarzenia

Najczęstszym scenariuszem jest klasyczny newsletter stowarzyszenia. Klub sportowy z 2 000 członków oferuje formularz zapisu na swojej witrynie TYPO3. Odwiedzający wpisują adres mailowy, otrzymują maila double opt-in, potwierdzają i są wpisywani do tabeli tt_address. Klub wysyła miesięczny newsletter przez rozszerzenie direct_mail lub zewnętrzny serwis wysyłkowy importujący adresy z tt_address. registeraddress odpowiada wyłącznie za rejestrację i wypisywanie, nie za samą wysyłkę.

Drugim scenariuszem są dystrybucje intranetowe w firmach. Pracownicy zapisują się na wewnętrzne newslettery informacyjne, np. "Lokalizacja Warszawa - menu w stołówce" lub "okna serwisowe IT". Ponieważ dane nie mogą opuszczać sieci firmowej, zewnętrzny serwis newslettera jest wykluczony. registeraddress zarządza zapisami lokalnie w bazie TYPO3.

Trzeci scenariusz: zapisy na wydarzenia z potwierdzeniem mailowym. Biblioteka oferuje wydarzenia i wykorzystuje registeraddress jako lekki formularz zapisów. Mail potwierdzający po double opt-in zawiera datę, godzinę i miejsce wydarzenia. Nie jest to pełnoprawne rozwiązanie do zarządzania wydarzeniami, ale dla instytucji z pięcioma do dziesięcioma wydarzeniami miesięcznie wystarczające.

## Architektura techniczna opiera się na tt_address i przepływie double opt-in

registeraddress jest zaimplementowany jako plugin Extbase i wykorzystuje tabelę tt_address jako bazę danych. Każda rejestracja przebiega trzyetapowo: wypełnienie formularza, mail double opt-in z linkiem potwierdzającym, aktywacja wpisu po kliknięciu linku. Link potwierdzający zawiera kryptograficznie podpisany token, który wygasa po konfigurowalnym okresie (domyślnie 48 godzin).

Rozszerzenie rejestruje plugin frontendowy konfigurowany przez TypoScript: pola obowiązkowe, pola opcjonalne (imię, firma, forma grzecznościowa), tekst potwierdzenia, szablony maili dla double opt-in i wiadomości powitalnej. Szablony Fluid można nadpisać przez SiteSet, by formularz pasował do designu witryny.

Dla zgodności z RODO registeraddress zapisuje moment zgody, adres IP, User-Agent oraz wersję polityki prywatności linkowanej w formularzu. W razie kontroli ze strony UODO można udowodnić, kiedy i pod jakimi warunkami subskrybent wyraził zgodę.

Wypisania odbywają się przez link w stopce newslettera, który dezaktywuje wpis tt_address (nie usuwa), aby historia zgód została zachowana. Ostateczne usunięcia zgodnie z art. 17 RODO (prawo do usunięcia) można realizować przez osobny formularz lub ręcznie w backendzie.

## Częste problemy dotyczą maili double opt-in trafiających do spamu i nieaktualnych wersji tt_address

Dominującym problemem jest dostarczalność maila double opt-in. Gdy mail potwierdzający trafia do folderu spam, subskrybent nigdy nie kończy rejestracji. Przyczyny niemal zawsze leżą po stronie serwera: brak rekordu SPF, brak podpisu DKIM, brak polityki DMARC. Sam registeraddress nie poprawi dostarczalności, bo to temat serwera mailowego. Zalecamy, by przed uruchomieniem formularza newslettera sprawdzić uwierzytelnianie maila przez mail-tester.com.

Drugi problem: niekompatybilność ze starszymi wersjami tt_address. registeraddress polega na określonych polach w tabeli tt_address. Gdy tt_address publikuje aktualizację major i przemianowuje lub usuwa pola, registeraddress nie zapisuje już wpisów poprawnie. Rozwiązanie: tt_address i registeraddress aktualizować zawsze razem, a po aktualizacji wykonać przebieg testowy całego procesu rejestracji.

Trzeci temat: rejestracje botów. Bez mechanizmu ochrony boty wypełniają formularz fałszywymi adresami i generują tysiące maili double opt-in obciążających serwer pocztowy i niszczących reputację nadawcy. registeraddress wspiera pola honeypot i można go łączyć z sr_freecap lub hcaptcha, by odpierać boty.

## TYPO3 v12 jest wspierany, kompatybilność z v13 wymaga zgrania z tt_address

registeraddress działa stabilnie pod TYPO3 v11 i v12, pod warunkiem że tt_address jest zainstalowany w kompatybilnej wersji. Dla TYPO3 v13 kompatybilność zależy zarówno od registeraddress, jak i od tt_address, ponieważ oba rozszerzenia są utrzymywane niezależnie. Gosign przy upgrade'ach TYPO3 sprawdza cały łańcuch newslettera (rejestracja, zarządzanie adresami, wysyłka) pod kątem kompatybilności i w razie potrzeby zaleca przejście na zewnętrzny serwis newslettera z integracją API, gdy natywne rozwiązanie TYPO3 nie jest już utrzymywane.

--- rflipbook TYPO3 - Cyfrowy flipbook | Gosign ---
> rflipbook dla TYPO3: PDF jako interaktywne flipbooki. Konfiguracja, optymalizacja wydajności i nowoczesne alternatywy.

## rflipbook zamienia katalogi i broszury w przeżycie flipbooka i jest dla zespołów contentowych najbardziej pragmatycznym rozwiązaniem, gdy PDF-y mają być nie tylko linkowane, lecz doświadczalne w kontekście strony

Kto pielęgnuje wielostronicowy katalog, raport roczny lub magazyn klientów jako PDF, stoi przed dylematem: jako download dokument leży w ślepej uliczce, użytkownik opuszcza stronę i rzadko wraca. rflipbook rozwiązuje to, renderując każdą stronę PDF jako Canvas i odwzorowując w przeglądarce klasyczny efekt przewracania stron ze świata druku. Rozszerzenie adresuje konkretny problem publikacyjny: zespoły marketingu, PR i relacji inwestorskich chcą wtórnie wykorzystywać istniejące assety drukowane cyfrowo, bez tłumaczenia ich na HTML. rflipbook czyni ten objazd zbędnym.

Warto zauważyć, że rflipbook to nie tylko technika prezentacji, ale też sygnał contentowy. Strona, która prowadzi aktualne katalogi i raporty jako flipbook, wydaje się potencjalnym klientom zadbana, w przeciwieństwie do osieroconych katalogów pobrań z dokumentami z różnych lat. Redakcyjnie do wprowadzenia należy zatem również wyjaśnienie, kto i kiedy aktualizuje które PDF.

## Typowe scenariusze zastosowania

Najczęstszym przypadkiem jest katalog produktów B2B. Producent maszyn pielęgnuje swój katalog główny w InDesignie, eksportuje 80-stronicowy PDF i osadza go przez rflipbook na stronie produktu. Dla redakcji nic się nie zmienia, a dla odwiedzającego z suchego pobrania powstaje doświadczenie przewracania stron z podglądem i funkcją wyszukiwania.

Drugim zastosowaniem są raporty biznesowe i raporty zrównoważonego rozwoju. Spółki giełdowe, fundacje i stowarzyszenia publikują corocznie obszerne raporty, które nie są redagowane na nowo. rflipbook osadza gotowy PDF bezpośrednio na stronie IR i tworzy most między klasyczną redakcją a zespołem web.

Trzeci przypadek: magazyny klienta i magazyny pracownicze. Uczelnie, gminy lub firmy średnie używają rflipbook, aby udostępniać swój magazyn drukowany jako wydanie cyfrowe, często z funkcją archiwum i wielojęzycznymi wydaniami per rocznik.

## Architektura techniczna

rflipbook integruje się jako klasyczne rozszerzenie TYPO3 przez element treści w module strony. Redaktorzy ładują PDF do FAL, łączą go z elementem treści i ustawiają w backendzie parametry jak kolor tła, strona startowa i przycisk pobierania. We frontendzie biblioteka JavaScript jak Turn.js lub podobna biblioteka renderowania Canvas przejmuje samą prezentację. PDF.js jest przy tym często używane jako parser, aby rozbijać strony PDF na poszczególne bitmapy.

Łańcuch zależności jest przejrzysty: rflipbook dostarcza biblioteki JavaScript w pakiecie rozszerzenia, samo rozszerzenie nie wymaga dodatkowych pakietów PHP. Konfiguracja odbywa się przez TypoScript dla globalnych defaults i przez flexform elementu treści dla dostosowań per strona. Kto pracuje z EXT:fluid_styled_content, może przenieść szablon przez Fluid-Overrides do własnego sitepackage i dopasować do CI.

Krytyczne jest współdziałanie z obsługą zasobów. Duże PDF-y powinny być po stronie serwera pre-renderowane na pojedyncze JPG, inaczej przeglądarka przy pierwszym wywołaniu ładuje wszystko synchronicznie. Lazy Page Loading nie jest standardową funkcją, ale można ją dobudować przez własny pipeline renderowania.

## Częste problemy i rozwiązania

Najczęstszym problemem jest czas ładowania. 40-stronicowy katalog ze zdjęciami w wysokiej rozdzielczości łatwo generuje initial-payload rzędu kilku megabajtów, co oznacza Lighthouse-scores w strefie czerwonej i złe Core Web Vitals. Rozwiązanie nie leży w samym rozszerzeniu, lecz przed nim: PDF-y przed uploadem przeliczyć do rzeczywistej potrzebnej rozdzielczości ekranu, idealnie przez Ghostscript lub serwerowy pipeline build, i ładować przy pierwszym wywołaniu tylko pierwsze dwie do trzech stron.

Drugi problem: wyświetlanie na urządzeniach mobilnych. Efekt przewracania stron działa źle na touchscreenach poniżej 400 pikseli szerokości, redaktorzy skarżą się na nieczytelne strony. Pragmatyczne rozwiązanie: przez CSS-media-query na urządzeniach mobilnych przełączać z flipbooka na prosty PDF.js Viewer z pionowym scrollem. User experience staje się przez to bardziej uczciwe, a czas ładowania lepszy.

Trzeci problem: dostępność cyfrowa. Screen-readery nie potrafią odczytywać PDF-ów renderowanych jako Canvas, co w urzędach i instytucjach publicznych staje się problemem compliance. Pomaga tu tylko dwutorowe podejście, flipbook jako uzupełnienie wizualne, obok obowiązkowo bezpośredni link do oryginalnego PDF i najlepiej wersja HTML treści kluczowych. Ustawa o dostępności cyfrowej i EN 301 549 wymagają tego wyraźnie.

## Migracja i kompatybilność wersji

rflipbook to ugruntowane, ale już nie aktywnie rozwijane rozszerzenie. Dla TYPO3 v11 istnieje działająca wersja, pod v12 i v13 działa tylko z ręcznymi dostosowaniami w ext_emconf.php i schemacie konfiguracji usług. Kto dziś zaczyna od zera, powinien zadać sobie pytanie, czy lżejsza alternatywa nie jest lepszym wyborem: smukły PDF.js Viewer, statyczne strony HTML z zawartości PDF lub headless flipbook service, który jest osadzany jako iframe. Decyzja zależy od tego, jak często dokument się zmienia i jak ważny jest wizualny efekt przewracania stron dla marki.

Kto pozostaje na TYPO3 v11, nie powinien traktować rflipbook jako trwałego rozwiązania. Najpóźniej przy upgrade na v12 konieczna jest decyzja, a czas na to powinien być zaplanowany wcześnie. Typowy projekt migracji obejmuje analizę wszystkich zastosowań flipbook w zbiorze, decyzję per przypadek (statyczna wersja HTML, lekki PDF viewer lub zachowanie jako flipbook), wdrożenie i szkolenie redakcyjne. Kto podchodzi do projektu strategicznie, wykorzystuje migrację jednocześnie do uporządkowania zasobów: przestarzałe katalogi są archiwizowane, dokumenty w aktualnych wersjach ponownie osadzane i metadane ujednolicane.

Gosign towarzyszy obu drogom, dalszemu prowadzeniu rflipbook na nowoczesnych wersjach TYPO3 i migracji do wydajniejszych alternatyw. Wspierana przez AI analiza pomaga znaleźć właściwą architekturę dla konkretnego case contentowego, zamiast dawać odpowiedź standardową.

--- FontAwesome CKEditor TYPO3 | Gosign ---
> Ikony FontAwesome bezpośrednio w edytorze CKEditor. Gosign doradza również w sprawie systemów ikon SVG jako wydajniejszej alternatywy - bez pliku fontów 300KB.

## Dlaczego FontAwesome w CKEditor pomaga redaktorom, ale kosztuje 300 KB wydajności

Redaktorzy chcą umieszczać ikony obok nagłówków, w tabelach i między akapitami tekstu. Bez pomocy technicznej kopiują obrazy ikon jako inline-images do RTE - z rozbitym layoutem i niespójnymi rozmiarami jako wynik. rte_ckeditor_fontawesome rozwiązuje ten problem czysto: redaktorzy wybierają ikony z katalogu FontAwesome bezpośrednio w CKEditor przez przycisk dialogowy i wstawiają je jako tag `<i>` w richtext. Ikony automatycznie skalują się z rozmiarem tekstu, są konfigurowalne kolorystycznie i działają w każdym elemencie treści.

Cena za to: cała biblioteka FontAwesome (ok. 300 KB jako webfont lub 180 KB jako SVG-sprite) jest ładowana na każdej stronie, nawet gdy używane są tylko 3 ikony. Dla stron krytycznych pod kątem wydajności to odczuwalny overhead.

## Typowe scenariusze zastosowań

**Listy ikon w opisach usług.** Usługodawca opisuje swoje świadczenia listami ikon: haczyk przed każdą zaletą, koło zębate przed każdym krokiem procesu, ikona telefonu przed numerem kontaktowym. Redaktor wstawia ikony bezpośrednio w CKEditor, bez konieczności proszenia programisty.

**Tabele porównawcze funkcji.** Menedżerowie produktu zarządzają tabelami porównawczymi w CKEditor. Zamiast "Tak" i "Nie" używają zielonych haczyków i czerwonych krzyżyków. rte_ckeditor_fontawesome udostępnia te ikony z katalogu FontAwesome. Tabela staje się wizualnie natychmiast zrozumiała.

**Szablony newsletterów z ikonami.** Firmy pielęgnujące treści newsletterów w backendzie TYPO3 i wysyłające je przez rozszerzenie newsletterowe używają ikon FontAwesome do wizualnego wzbogacenia. Ponieważ ikony są wstawiane jako tagi `<i>`, działają w klientach e-mail wspierających webfonty.

## Architektura techniczna

rte_ckeditor_fontawesome rozszerza CKEditor w backendzie TYPO3 o dodatkowy plugin. Plugin rejestruje przycisk w pasku narzędzi CKEditor, który otwiera dialog wyboru z funkcją wyszukiwania i filtrem kategorii.

Integracja działa na trzech poziomach: plugin CKEditor (plugin JavaScript dla CKEditor 4 w TYPO3 v10/v11 lub CKEditor 5 w TYPO3 v12+), wyjście HTML (przy wstawieniu tag `<i>` z odpowiednimi klasami CSS jest zapisywany w richtext) i renderowanie frontendowe (by ikony były widoczne we frontendzie, biblioteka CSS FontAwesome musi być załadowana na stronie - rozszerzenie nie dostarcza zasobów frontendowych).

Ważna uwaga dotycząca wersji CKEditor: TYPO3 v12 przechodzi z CKEditor 4 na CKEditor 5. Architektura pluginów zmieniła się fundamentalnie. Pluginy rte_ckeditor_fontawesome dla CKEditor 4 nie działają w CKEditor 5.

## Częste problemy i rozwiązania

**Ikony nie wyświetlają się we frontendzie.** Najczęstsza przyczyna: CSS FontAwesome nie jest wbudowane w szablonie frontendowym. Rozszerzenie zajmuje się tylko częścią backendową (wybór ikon w CKEditor). Prezentacja frontendowa wymaga załadowania `fontawesome.min.css` i odpowiednich plików fontów w szablonie.

**Ikony pojawiają się jako puste kwadraciki.** Pliki fontów (woff2, woff) nie są prawidłowo ładowane. Często ścieżka w pliku CSS jest źle skonfigurowana lub serwer blokuje pliki fontów. Rozwiązanie: lokalne hostowanie FontAwesome zamiast przez CDN. To unika problemów CORS i jest bardziej zgodne z RODO.

**Wpływ na wydajność przez FontAwesome.** Kompletna instalacja FontAwesome ładuje ponad 300 KB (wszystkie kategorie ikon). Gdy strona używa tylko 10 ikon, 290 KB jest zmarnowane. Rozwiązanie: subsetting FontAwesome - kompilacja tylko używanych ikon w niestandardowy plik fontów. Alternatywnie: przejście na system ikon SVG osadzający tylko faktycznie używane ikony jako inline-SVG.

## Migracja i kompatybilność wersji

rte_ckeditor_fontawesome jest dostępne dla TYPO3 v10 i v11 (CKEditor 4) jako stabilne rozszerzenie. Dla TYPO3 v12 (CKEditor 5) istnieją adaptacje, ponieważ architektura pluginów jest zupełnie nowa.

Dla TYPO3 v13 i dalszych Gosign zaleca fundamentalną ponowną ocenę podejścia. Zamiast ładować FontAwesome jako webfont, nowoczesne strony stawiają na systemy ikon SVG: każda ikona jest osadzana jako inline-SVG, ładowane są tylko używane ikony, rozmiar pliku spada z 300 KB na poniżej 10 KB.

Nakład migracji z FontAwesome na ikony SVG to typowo 2 do 3 dni: utworzenie SVG-sprite, dostosowanie widgetu CKEditor, zamiana istniejących tagów `<i>` w treści przez referencje `<svg>`. Gosign automatyzuje ostatni krok przez skrypt migracyjny identyfikujący i przepisujący wszystkie tagi `<i class="fa-*">` w bazie danych. Dopasowany SVG-sprite z 30 ikonami waży 8 do 15 KB - pięćdziesiąta część kompletnej biblioteki FontAwesome.

--- rte_ckeditor_image TYPO3 - Obrazy w RTE | Gosign ---
> rte_ckeditor_image: Wstawianie i edycja obrazów w CKEditor. Responsywne wyświetlanie, rozwiązywanie problemów, alternatywy.

## rte_ckeditor_image wprowadza profesjonalne zarządzanie obrazami do Rich Text Editor

TYPO3-CKEditor dopuszcza tylko proste osadzanie obrazów przez tag img, bez powiązania z File Abstraction Layer i bez responsywnych wariantów. Dla redakcji, które regularnie wstawiają obrazy w artykuły, wpisy news lub teksty magazynowe, to nie wystarcza: potrzebują one przycinania, skalowania, tekstu alt, copyright, celu linku i przede wszystkim wyjścia srcset. rte_ckeditor_image od Netresearch uzupełnia CKEditor o dokładnie te funkcje i porządnie integruje go z FAL. W każdym projekcie TYPO3 z redakcyjnie pielęgnowanymi obrazami w tekście głównym rozszerzenie od lat jest standardowym narzędziem i należy do najczęściej instalowanych pomocników redakcji w ekosystemie.

## Typowe scenariusze zastosowania leżą w redakcjach z wysokim wolumenem obrazów

Magazyny online i korporacyjne strony news są klasyczną grupą docelową. Magazyn z 200 artykułami rocznie osadza w każdym wpisie dwa do pięciu obrazów w tekście głównym, dodatkowo do obrazów teaserowych i nagłówkowych. Bez rte_ckeditor_image redakcja musiałaby dla każdego obrazu inline akceptować zmianę elementu contentu i przerywać płynność tekstu. Z rozszerzeniem wstawia obraz bezpośrednio przez przycisk na toolbarze, wybiera referencję FAL, ustawia tekst alt i podpis i wraca bez zmiany kontekstu do pisania. Zysk efektywności można mierzyć w praktyce: przy redakcji z 200 wpisami rocznie i średnio czterema obrazami na wpis oszczędzamy na artykule około dwóch minut czasu setup, co w skali roku daje prawie 30 godzin pracy.

Drugim scenariuszem są katalogi produktów i dokumentacja techniczna. Kto w katalogu TYPO3 pielęgnuje instrukcje krok po kroku ze zrzutami ekranu inline, potrzebuje obrazów bezpośrednio w tekście. rte_ckeditor_image pozwala na to z tymi samymi referencjami FAL, które są używane w reszcie projektu, aktualizacje obrazów odbywają się w jednym miejscu i działają wszędzie.

Trzecim scenariuszem jest migracja instalacji TYPO3 z ery htmlArea. Kto do tej pory używał RTEhtmlArea, znalazł tam podobne zarządzanie obrazami. Przy przejściu na CKEditor rte_ckeditor_image jest bezpośrednim rozszerzeniem zastępczym, żeby redaktorzy mogli kontynuować zwykły workflow. Bez rozszerzenia redakcja traci przy upgrade nie tylko jedną funkcję, ale cały krok pracy, który trudno zastąpić dodatkowymi elementami contentu.

## Architektura techniczna rozszerza toolbar CKEditora przez plugin

Rozszerzenie składa się z pluginu CKEditora, który rejestruje przycisk Image i dialog Image, oraz serwerowego renderowania, które tłumaczy marker w zapisanym HTML na wyjście Fluid. Plugin komunikuje się z endpointem AJAX, który przetwarza referencję FAL, przycinanie i teksty alt.

W contencie bazy danych obraz stoi jako oznaczenie HTML z atrybutami data data-htmlarea-file-uid i data-htmlarea-file-table, towarzyszonymi przez dalsze atrybuty dla przycinania, zoomu i wysokości. Przy renderowaniu pre-processor zastępuje tag oznaczenia pełnym wywołaniem ViewHelpera Image, które tworzy srcset, warianty webp i atrybuty lazy-loading. Dostępne szerokości obrazów są definiowane przez YAML w konfiguracji RTE. Typowa konfiguracja magazynowa pracuje z trzema do pięciu szerokościami obrazów (480, 768, 1024, 1440, 2048) i automatycznie tworzy z tego responsywne srcset, które na urządzeniach mobilnych ładuje tylko najmniejszy wariant.

Przycinanie wykorzystuje TYPO3-Core-Cropping-Werkzeug: w dialogu obrazu pojawia się edytor crop z backendu, z tymi samymi presetami wariantów co przy regularnym elemencie treści obraz. Przycinanie jest zapisywane per instancja obrazu, dzięki czemu ten sam obraz FAL może być w różnych artykułach inaczej przycięty. Jest to szczególnie ważne, gdy obraz jest używany zarówno w teaserze magazynu (kwadratowy) jak i w tekście głównym (landscape), bez konieczności pielęgnowania przez redakcję dwóch oddzielnych plików.

## Częste problemy dotyczą responsywnego wyjścia, WebP i kompatybilności z CKEditor 5

Najczęstszym tematem wsparcia jest brakujące wyjście srcset. Domyślna ścieżka renderowania nie tworzy srcset, gdy YAML RTE nie zawiera definicji szerokości obrazów. Wiele instalacji skopiowało YAML z TYPO3-Core i przy tym pominęło sekcję "proc.entryHTMLparser_db.allowedAttribs" lub "config.additionalAttributes". Rozwiązaniem jest pełny YAML z wyraźnie zdefiniowanymi szerokościami srcset.

Drugim problemem jest WebP. Kto chce dostarczać nowoczesne formaty obrazów, musi skonfigurować TYPO3-ImageMagick-Provider lub konfigurację GraphicsMagick z obsługą WebP. rte_ckeditor_image sam nie tworzy konwersji WebP, lecz sięga do core-Image-Processora. Bez prawidłowej konfiguracji providera obrazy pozostają w wyjściu jako JPEG.

Po trzecie, CKEditor 5 stanowi zmianę architektury. TYPO3 v12 przynosi CKEditor 5, który używa innego modelu pluginów. Wersje 10.x i 11.x rte_ckeditor_image są przeniesione na CKEditor 5 i działają w v12 out of the box. Własne dostosowania oparte na CKEditor 4 muszą być dostosowane przy upgrade. Kto zbudował własne pluginy lub własne przyciski toolbaru, powinien na migrację zaplanować co najmniej jeden do dwóch dni deweloperskich.

## Migracja na TYPO3 v12 i v13 wymaga skoku wersji rozszerzenia

rte_ckeditor_image jest aktywnie utrzymywane przez Netresearch i dostępne dla TYPO3 v11, v12 i v13. Większy skok leży między wersjami rozszerzenia 9.x (CKEditor 4) i 10.x/11.x (CKEditor 5). Kto podnosi instalację TYPO3 v10 lub v11 z rozszerzeniem 9.x na TYPO3 v12, musi jednocześnie przejść na serię 10.x rozszerzenia. Reprezentacja bazy danych obrazów inline pozostaje przy tym kompatybilna, dzięki czemu istniejące artykuły działają bez migracji treści.

W Gosign sprawdzamy przed każdym upgrade TYPO3, czy YAML RTE projektu musi być dostosowany do wersji rozszerzenia i czy istnieją własne dostosowania pluginu lub nadpisane ViewHelpery. W wielu projektach z TYPO3 v12 można dodatkowo sprawdzić, czy natywne funkcje obrazów CKEditor 5 wystarczają i rozszerzenie można średnioterminowo wycofać. Dla redakcji z potrzebą przycinania i srcset rte_ckeditor_image pozostaje jednak najbardziej pragmatyczną opcją. Alternatywą byłby własny przycisk toolbaru obrazu z custom pluginem CKEditor, co jest wyraźnie bardziej kosztowne i trwale przenosi pielęgnację do odpowiedzialności projektu.

--- rx_shariff TYPO3 - Udostępnianie z ochroną prywatności | Gosign ---
> rx_shariff: Udostępnianie społecznościowe bez śledzenia. Przyciski zgodne z RODO dla TYPO3. Konfiguracja i alternatywy.

## Dlaczego standardowe przyciski społecznościowe to problem z RODO i rx_shariff było rozwiązaniem

Każdy przycisk Like na Facebooku, każdy widget Twitter Share i każdy embed LinkedIn przesyła dane osobowe do platformy - i to przy ładowaniu strony, nie dopiero przy kliknięciu. Adres IP, fingerprint przeglądarki i referrer trafiają do Facebooka, zanim odwiedzający w ogóle miał możliwość wyrażenia zgody. Od wejścia w życie RODO w 2018 jest to prawnie problematyczne.

rx_shariff implementuje zasadę Shariff, którą wydawnictwo Heise opracowało w 2014 roku jako odpowiedź na ten problem: zamiast osadzania oryginalnych widgetów platform, rx_shariff renderuje własne, zgodne z ochroną danych przyciski. Dopiero gdy odwiedzający kliknie przycisk, nawiązywane jest połączenie z platformą. Żadnego śledzenia, żadnych żądań do stron trzecich, żadnych ciasteczek bez interakcji.

## Typowe scenariusze zastosowań

**Strony firmowe z wymogiem zgodności RODO/UODO.** Firma chce na swoich artykułach blogowych oferować przyciski udostępniania w mediach społecznościowych, nie naruszając RODO. Inspektor ochrony danych (IOD) zakazał standardowych widgetów Facebooka i Twittera. rx_shariff dostarcza przyciski nawiązujące połączenie dopiero przy kliknięciu. Polityka prywatności może być prawidłowo sformułowana: "Dopiero przy aktywnym użyciu przycisków udostępniania dane są przesyłane do stron trzecich."

**Strony mediowe z licznikami udostępnień.** Wydawnictwo fachowe chce pod każdym artykułem wyświetlać, ile razy został udostępniony na Facebooku i LinkedIn. rx_shariff oferuje tę funkcję przez opcjonalny proxy backendowy: serwer TYPO3 regularnie odpytuje liczniki udostępnień na platformach i cachuje wyniki. Platformy widzą tylko serwer, nigdy pojedynczego odwiedzającego.

**Portale intranetowe z kontrolowanym udostępnianiem.** Firma prowadzi intranet TYPO3 i chce określone artykuły udostępniać na LinkedIn, ale wykluczyć Facebook i Twitter. rx_shariff można konfigurować tak, by pojawiały się tylko wybrane platformy. W kontekście intranetu jest to szczególnie istotne, by zapobiec przypadkowemu udostępnianiu informacji wewnętrznych na platformach publicznych.

## Architektura techniczna

rx_shariff składa się z dwóch komponentów: widgetu frontendowego i opcjonalnego serwisu backendowego. Widget frontendowy renderuje dla każdej skonfigurowanej platformy przycisk HTML jako prosty link kotwicy (`<a href="...">`). Przy kliknięciu otwiera się strona dialogu udostępniania platformy w nowym oknie. Żaden JavaScript nie jest ładowany przy wywołaniu strony, żadne ciasteczka nie są ustawiane, żadne zewnętrzne zasoby nie są żądane.

Opcjonalny serwis backendowy: dla liczników udostępnień rx_shariff prowadzi serwerowy proxy. Skrypt PHP odpytuje API platform i cachuje wyniki w tabeli bazodanowej. Frontend wyświetla cachowany licznik. Proxy aktualizuje liczniki przez zadanie Scheduler co 15 do 60 minut.

## Częste problemy i rozwiązania

**Liczniki udostępnień zawsze pokazują 0.** API platform wymagają uwierzytelniania. Bez ważnego klucza API Facebook i LinkedIn nie dostarczają liczników. Twitter/X całkowicie wyłączył swoje API liczników udostępnień w 2015. Rozwiązanie: utworzenie aplikacji Facebook w Meta Developer Portal i konfiguracja tokena aplikacji w rx_shariff. Dla Twittera dezaktywacja licznika.

**Przyciski nie są widoczne po aktualizacji TYPO3.** rx_shariff korzysta z pluginu TYPO3 z własnym elementem treści. Jeśli plugin po aktualizacji nie jest już zarejestrowany, element treści znika z frontendu. Rozwiązanie: sprawdzenie rozszerzenia w Extension Manager, aktualizacja zależności Composer.

**Udostępnianie WhatsApp działa tylko na urządzeniach mobilnych.** WhatsApp Web i aplikacja desktopowa nie wspierają jednolicie schematu URL `whatsapp://`. Rozwiązanie: na desktopie użycie URL webowego `https://api.whatsapp.com/send?text=...`, na urządzeniach mobilnych schematu aplikacji. rx_shariff automatycznie rozpoznaje User-Agent i wybiera właściwy link.

## Migracja i kompatybilność wersji

rx_shariff jest dostępne dla TYPO3 v10 i v11 jako stabilny pakiet Composer. Dla TYPO3 v12 istnieją forki społecznościowe. Sam projekt JavaScript Shariff od Heise został w 2022 przeniesiony do trybu maintenance.

Dla nowych projektów od TYPO3 v12 Gosign zaleca ponowną ocenę: proste linki udostępniania (`href="https://www.facebook.com/sharer/sharer.php?u=..."`) są lżejsze niż rx_shariff, zgodne z RODO i nie wymagają rozszerzenia. Wadą jest brak licznika udostępnień.

Migracja z rx_shariff na proste linki udostępniania to typowo pół dnia: usunięcie starego pluginu, utworzenie nowych parcjali Fluid dla linków udostępniania, dostosowanie CSS. Proste podejście z linkami pokrywa popularne platformy: Facebook, LinkedIn, X/Twitter, e-mail i WhatsApp. Wszystkie linki są zgodne z ochroną danych, bo żaden JavaScript nie jest ładowany i żadne ciasteczka stron trzecich nie są ustawiane.

--- SAML2 TYPO3 - Integracja SSO | Gosign ---
> SAML 2.0 Single Sign-On bezpośrednio w TYPO3 - bez Shibboleth SP na serwerze. Alternatywa dla shibboleth_auth dla IdP nie obsługujących OIDC.

## SAML 2.0 umożliwia Single Sign-On w TYPO3 bez instalacji Shibboleth na serwerze

Uczelnie, urzędy i koncerny prowadzą Identity Providers (IdP) oparte o SAML 2.0: Microsoft ADFS, Okta, Keycloak, PingFederate. Kto chciał wykorzystać te tożsamości w TYPO3, dotąd potrzebował Shibboleth Service Provider na serwerze WWW, czyli dodatkowej warstwy oprogramowania z własną konfiguracją, własnymi certyfikatami i osobnym utrzymaniem. Rozszerzenie TYPO3 saml2 sprawia, że Shibboleth SP jest zbędny. Implementuje ono SAML 2.0 SP bezpośrednio w PHP i komunikuje się z IdP bez middleware. Znacząco upraszcza to architekturę serwera, zwłaszcza w środowiskach shared hosting lub w deploymentach kontenerowych, gdzie Shibboleth SP trudno zainstalować.

Dla organizacji, których IdP nie wspiera OIDC (OpenID Connect), SAML 2.0 jest jedyną ustandaryzowaną drogą do Single Sign-On. Rozszerzenie wypełnia dokładnie tę lukę w ekosystemie TYPO3.

## Typowe scenariusze dotyczą uczelnianych intranetów, portali urzędów i ekstranetów koncernów

Najczęstszym scenariuszem jest intranet uczelniany. Uniwersytet prowadzi Shibboleth IdP w federacji PIONIER.Id lub w ramach federacji USOS, łączącej polskie szkoły wyższe. Studenci i pracownicy logują się swoim identyfikatorem uczelnianym i otrzymują dostęp do chronionych stron TYPO3: skryptów, wewnętrznych komunikatów, wyników egzaminów. Rozszerzenie saml2 sprawdza token SAML-Assertion, w razie potrzeby zakłada użytkownika frontendu TYPO3 i przypisuje grupy na podstawie atrybutów IdP (np. studenci -> grupa "student", wykładowcy -> grupa "staff").

Drugim scenariuszem są portale urzędowe z integracją profilu zaufanego. Profil Zaufany ePUAP udostępnia interfejs SAML, który gminy i urzędy mogą podłączyć do swojej witryny TYPO3 przez saml2. Obywatele logują się Profilem Zaufanym i uzyskują dostęp do spersonalizowanych usług elektronicznych, np. wniosków, harmonogramów posiedzeń rady gminy czy dokumentów do pobrania.

Trzeci scenariusz: ekstranety koncernów. Producent samochodów prowadzi portal dla dilerów na TYPO3. Dilerzy logują się przez IdP koncernu (Microsoft ADFS) i widzą cenniki, materiały szkoleniowe oraz formularze zamówień przypisane do ich grupy. Rozszerzenie saml2 mapuje grupy ADFS na grupy frontendu TYPO3 i steruje w ten sposób dostępem do chronionych obszarów treści.

## Architektura techniczna implementuje SAML 2.0 SP jako bibliotekę PHP w TYPO3

saml2 opiera się na bibliotece PHP onelogin/php-saml (lub jej odpowiedniku), która w pełni pokrywa profil SAML 2.0 Web Browser SSO: AuthnRequest, walidacja Response, parsowanie Assertion, weryfikacja podpisu, logout. Biblioteka jest dołączana jako zależność Composera i rejestrowana przez rozszerzenie jako Authentication Service TYPO3.

Konfiguracja odbywa się w backendzie TYPO3 lub przez TypoScript: URL metadanych IdP (lub ręcznie: Entity ID, SSO-URL, SLO-URL, certyfikat), Entity ID SP, mapowanie atrybutów (który atrybut IdP odpowiada któremu polu TYPO3: email, username, firstname, lastname, groups). Rozszerzenie wspiera zarówno SP-initiated SSO (użytkownik klika "Login" na stronie TYPO3), jak i IdP-initiated SSO (użytkownik trafia bezpośrednio z portalu IdP).

Użytkownicy frontendu są zakładani automatycznie przy pierwszym logowaniu i aktualizowani przy każdym kolejnym. Przypisywanie grup można konfigurować statycznie (wszyscy użytkownicy SAML w grupie X) lub dynamicznie (atrybut IdP "role" = "admin" staje się grupą TYPO3 "admin").

Dla logowania backendu (BE-User) SAML również jest konfigurowalny, jednak z większym ryzykiem: gdy IdP padnie, dostęp do backendu jest niemożliwy. Zalecamy zachowanie przynajmniej jednego lokalnego konta administratora jako fallback.

## Częste problemy dotyczą certyfikatów, odchyleń czasu i mapowania atrybutów

Najczęstszym problemem przy integracjach SAML są wygasłe lub błędnie skonfigurowane certyfikaty. IdP podpisuje SAML-Response swoim certyfikatem. Gdy certyfikat na SP nie zostanie zaktualizowany po jego rotacji w IdP, weryfikacja podpisu się nie powiedzie i logowanie zakończy się kryptycznym błędem. Rozwiązanie: rotację certyfikatów wpisać do kalendarza utrzymania. Większość IdP daje 30 dni wyprzedzenia przed rotacją.

Drugi problem: odchylenia czasu między IdP a SP. Assercje SAML mają okno czasowe (NotBefore / NotOnOrAfter). Gdy zegary systemowe serwera IdP i serwera TYPO3 rozjeżdżają się o więcej niż 120 sekund, asercja jest odrzucana jako nieważna. Rozwiązanie: skonfigurować NTP na obu serwerach.

Trzeci temat: błędne mapowanie atrybutów. Każdy IdP nazywa atrybuty inaczej. Microsoft ADFS dostarcza "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", Keycloak dostarcza "email", Shibboleth dostarcza "urn:oid:0.9.2342.19200300.100.1.3". Rozszerzenie musi wiedzieć, pod jaką nazwą atrybut email znajduje się w tokenie SAML. Błędne mapowanie prowadzi do pustych pól w profilu użytkownika TYPO3. Logowanie debug otrzymywanych atrybutów pomaga zidentyfikować właściwe klucze mapowania.

## TYPO3 v12 jest wspierany, kompatybilność z v13 zależy od API Authentication Service

Rozszerzenie saml2 rejestruje się jako Authentication Service TYPO3. To API w core TYPO3 jest stabilne od lat, ale w v12 i v13 zostało w pojedynczych miejscach dostosowane. Aktualna wersja rozszerzenia działa stabilnie pod v12. Dla v13 rejestracja Authentication Service musi być dostosowana do nowej konfiguracji service'ów. Gosign przy projektach SSO sprawdza, czy biblioteka PHP-SAML jest aktualna (łatki bezpieczeństwa) i czy rozszerzenie jest kompatybilne z używaną wersją TYPO3. Gdy rozszerzenie społecznościowe nie jest już utrzymywane, jako alternatywę polecamy rozszerzenie oidc, jeśli IdP wspiera OpenID Connect.

--- Schemaker TYPO3 - Schemat ViewHelper | Gosign ---
> Generator schematów ViewHelper dla Fluid. Generuje dokumentację i autouzupełnianie dla własnych ViewHelper.

## Dlaczego brak dokumentacji ViewHelper spowalnia projekty TYPO3

Fluid ViewHelper to kręgosłup każdego rozwoju szablonów TYPO3. Ale gdy projekt zawiera własne ViewHelper, zaczyna się problem: żaden programista nie zna wszystkich parametrów, żadne IDE nie oferuje autouzupełniania, a dokumentacja istnieje co najwyżej jako komentarz w kodzie PHP. Schemaker rozwiązuje ten problem, automatycznie generując z klas PHP pliki schematu XSD. Te schematy dostarczają IDE informacji potrzebnych do autouzupełniania, walidacji i dokumentacji inline bezpośrednio w szablonie Fluid.

Dla zespołów z więcej niż jednym programistą TYPO3 to nie kwestia komfortu, lecz produktywności. Bez plików schematu każdy programista spędza dziennie 15 do 30 minut na szukaniu parametrów ViewHelper w kodzie źródłowym.

## Typowe scenariusze zastosowań

**Projekty enterprise z ponad 20 własnymi ViewHelperami.** Duże instalacje TYPO3 często zawierają specjalistyczne ViewHelper - do formatowania cen, sprawdzania uprawnień, wywołań API czy logiki branżowej. Bez Schemaker każdy nowy programista musi czytać kod źródłowy. Z Schemaker otwiera szablon Fluid w PhpStorm lub VS Code i od razu dostaje podpowiedzi.

**Rozwój rozszerzeń dla TER.** Kto publikuje rozszerzenia zawierające własne ViewHelper, może z Schemaker dostarczać pliki XSD. To redukuje zapytania supportowe i poprawia Developer Experience dla każdego użytkownika rozszerzenia.

**Onboarding nowych programistów.** W agencji TYPO3 programiści regularnie przełączają się między projektami. Schematy generowane przez Schemaker funkcjonują jak żywa dokumentacja: są zawsze aktualne, bo generowane bezpośrednio z kodu. Zamiast 2 dni wdrożenia - 2 godziny.

## Architektura techniczna

Schemaker analizuje klasy PHP dziedziczące po `AbstractViewHelper`. Odczytuje adnotacje `@param`, wywołania `registerArgument()` i DocBlocks klas. Z tego generuje pliki schematu XSD (XML Schema Definition) przypisane do przestrzeni nazw Fluid.

Integracja działa przez TYPO3 CLI: `vendor/bin/typo3 schemaker:generate` tworzy pliki XSD dla wszystkich zarejestrowanych przestrzeni nazw ViewHelper. Wygenerowane pliki XSD są umieszczane w projekcie (typowo: `Resources/Private/Schemas/`). IDE (PhpStorm, VS Code z odpowiednim rozszerzeniem) odczytuje XSD i oferuje autouzupełnianie.

Schemaker nie ma wpływu na wydajność strony live - generowanie schematu działa wyłącznie na CLI w kontekście deweloperskim. W środowiskach produkcyjnych Schemaker nie musi być nawet zainstalowany; wygenerowane pliki XSD są dystrybuowane przez system kontroli wersji (Git).

## Częste problemy i rozwiązania

**IDE mimo XSD nie pokazuje autouzupełniania.** Najczęstsza przyczyna: przestrzeń nazw w szablonie Fluid nie zgadza się z przestrzenią nazw XSD. Schemaker generuje schematy na podstawie przestrzeni nazw PHP klas ViewHelper. Rozwiązanie: `xmlns:custom` musi dokładnie odpowiadać wygenerowanemu schematowi.

**Wygenerowane XSD nie zawiera wszystkich ViewHelper.** Schemaker znajduje tylko ViewHelper dostępne przez Composer Autoloading. Rozszerzenia zainstalowane tylko w trybie Classic (bez Composer) nie są kompletnie skanowane. Rozwiązanie: przejście na instalację opartą na Composer.

**Schemat przestarzały po zmianach kodu.** Pliki XSD nie aktualizują się automatycznie przy zmianach parametrów ViewHelper. Rozwiązanie: zintegrowanie generowania schematu w pipeline CI/CD. Hook `composer post-install-cmd` lub krok budowania w GitLab CI zapewnia, że schematy są generowane po każdej aktualizacji zależności.

## Migracja i kompatybilność wersji

Schemaker został pierwotnie opracowany przez Claus Due (zespół FluidTYPO3) i był aktywnie utrzymywany do TYPO3 v9. Dla TYPO3 v10 i v11 istnieją forki społecznościowe z ograniczoną funkcjonalnością.

Dla TYPO3 v12 i v13 jako alternatywę zaleca się wbudowane wsparcie TYPO3-Plugin w PhpStorm, które odczytuje informacje ViewHelper bezpośrednio z kodu PHP, bez oddzielnych plików XSD. Zespół TYPO3 Core udostępnia ponadto oficjalne schematy XSD dla Core-ViewHelper.

Gosign wspiera przy ewaluacji i migruje istniejące workflow schematów na nowoczesne toolchainy. Typowy nakład migracji: 4 do 8 godzin per projekt, włącznie z konfiguracją IDE dla wszystkich programistów w zespole i dokumentacją dostępnych przestrzeni nazw ViewHelper.

--- sf_event_mgt TYPO3 - Zarządzanie wydarzeniami | Gosign ---
> sf_event_mgt: Zarządzanie wydarzeniami, rejestracja, płatności. Konfiguracja i Custom-rozwój, z wykorzystaniem AI.

## sf_event_mgt rozwiązuje problem, że wydarzenie bez rejestracji nie jest wydarzeniem

Gdy strona TYPO3 zarządza więcej niż dwoma terminami rocznie i musi przyjmować uczestników, każde improwizowane rozwiązanie złożone z list stron, wtyczek kalendarza i formularzy powermail napotyka swoje granice. sf_event_mgt to rozszerzenie, które łączy te klocki w prawdziwy system wydarzeń: zarządzanie uczestnikami z przejściami statusów, listy oczekujących z automatycznym awansem, płatności przez kilku providerów i zautomatyzowana komunikacja e-mailowa przez cały cykl życia uczestnictwa. Kto w TYPO3 regularnie organizuje wydarzenia ze stałymi miejscami, praktycznie nie ominie tego rozszerzenia. Torben Hansen zbudował sf_event_mgt od początku jako narzędzie natywne dla Extbase, które płynnie wpasowuje się w istniejące instalacje TYPO3 i można je nadpisywać w każdym miejscu bez forkowania rozszerzenia core.

## Typowe scenariusze zastosowania sięgają od targów po programy akademickie

Uczelnie wykorzystują sf_event_mgt na dni informacyjne, wykłady próbne i programy dokształcające. W praktyce oznacza to często: 30 równoległych kursów z własną pojemnością, rozstawem cenowym i łańcuchem e-mailowym do zainteresowanego, uczestnika i organizatora. Rozszerzenie zarządza tym przez jedną strukturę danych, wraz z wielojęzycznością dla studentów międzynarodowych. Na typowej uczelni wdrożyliśmy sf_event_mgt z około 400 pojedynczymi wydarzeniami rocznie, w tym kursami przygotowawczymi, dniami otwartych laboratoriów i spotkaniami absolwentów.

Stowarzyszenia i izby organizują w ten sposób konferencje branżowe i seminaria, w których uczestnicy płacą różne ceny w zależności od statusu członkowskiego. Typowa instalacja izby gospodarczej pracuje z 40 do 80 wydarzeniami rocznie, wiele z nich płatnych i z kilkoma klasami cenowymi. Członkowie płacą cenę regularną, niezrzeszeni dopłatę, a early-bird rabat. Rozszerzenie obsługuje to przez kategorie cenowe, które można konfigurować per wydarzenie, bez konieczności ingerencji dewelopera.

Firmy z kolei używają sf_event_mgt do wewnętrznych szkoleń, eventów dla klientów i webinarów. Szczególnie w obszarze B2B ważna jest funkcja eksportu CSV: lista uczestników następnie trafia do CRM albo do drukarki identyfikatorów na miejscu. W koncernie przemysłowym z 12 000 pracowników podłączyliśmy rozszerzenie do wewnętrznego systemu Learning-Management, dzięki czemu zapisy szkoleniowe automatycznie lądują w systemie kadrowym, a uczestnictwo jest dokumentowane jako dowód dokształcania.

## Architektura techniczna oparta jest na Extbase i FAL

sf_event_mgt to klasyczne rozszerzenie Extbase i podąża za wzorcem MVC TYPO3. Centralne modele to Event, Registration, Location i Organisator, konfiguracja odbywa się przez TypoScript i szablony Fluid. Prawie wszystko można dostosować przez constants.typoscript lub TSconfig, bez forkowania rozszerzenia. Wariant plugin oferuje ponad tuzin akcji kontrolera, od widoku listy i widoku szczegółowego przez flow rejestracji po filtr wyszukiwania i kategorii.

Dla płatności rozszerzenie przynosi abstrakcję Payment, która wspiera Stripe, PayPal, Invoice i Klarna przez klasy handlerów. Własnych providerów płatności można podłączyć, implementując klasę PaymentServiceInterface. Rozliczenia trafiają do własnego logu płatności i mogą być przetwarzane przez TYPO3-Scheduler. Nieudane płatności są dokumentowane i można je śledzić przez backend, bez konieczności przechodzenia redaktorów do konsoli providera płatności.

System e-mailowy opiera się na szablonach Fluid w katalogu EXT. Dla każdej rejestracji wyzwalanych jest kilka wiadomości: potwierdzenie do uczestnika, powiadomienie do organizatora, przypomnienia przed wydarzeniem, e-mail po wydarzeniu. Każda z tych wiadomości to szablon Fluid, który można nadpisać przez SiteSet lub PageTS. Maile są wysyłane przez TYPO3-Mailer i respektują globalne ustawienia SMTP wraz z SPF i DKIM. Dla uczestników z zarezerwowanymi miejscami na liście oczekujących są oddzielne szablony, które są wyzwalane przy awansie.

## Częste problemy dotyczą list oczekujących, eksportu iCal i ReCaptcha

Najczęstszym tematem wsparcia jest logika listy oczekujących. Gdy uczestnik odwołuje, pierwszy wpis z listy oczekujących awansuje, ale tylko wtedy, gdy admin aktywował kontroler polecenia "moveUpWaitlistRegistrations" przez Scheduler. Wiele instalacji o tym zapomniało i dziwi się, dlaczego miejsca pozostają puste. Konfiguracja trwa pięć minut, ale bez zadania Schedulera rozszerzenie pozostaje w trybie ręcznym.

Drugim stałym tematem jest eksport iCal. Uczestnicy chcą kliknięcia "Dodaj do kalendarza", które działa w Outlooku, Apple Calendar i Google Kalendarz. sf_event_mgt dostarcza plik ICS, ale poprawne strefy czasowe i bloki VTIMEZONE muszą być ustawione przez konfigurację. Inaczej wydarzenie pojawia się w Outlooku z godzinnym przesunięciem, szczególnie krytycznie przy zmianie na czas letni. Zalecamy, aby przy międzynarodowych wydarzeniach przechowywać w ICS zarówno lokalną strefę czasową, jak i UTC.

Trzeci temat to ochrona antyspamowa. Publiczne formularze rejestracji przyciągają boty, które zalewają listy oczekujących. sf_event_mgt wspiera pola honeypot i można go połączyć z ext:kestura_recaptcha lub natywnym TYPO3-Captcha. W produkcyjnych instalacjach zalecamy łączyć oba mechanizmy i dodatkowo wbudować rate-limit per adres IP, żeby pojedyncze boty nie mogły zakładać setek fałszywych rejestracji.

## Migracja na TYPO3 v12 i v13 nie jest krytyczna

sf_event_mgt jest ciągle utrzymywane przez Torbena Hansena i dostępne dla TYPO3 v11, v12 i v13. Skok z v10 na v12 nie przynosi breaking changes w strukturze bazy danych, wszystkie pola pozostają kompatybilne. Własne ViewHelpery rozszerzenia zostały przeniesione na nową wersję Fluid, własne szablony po update wymagają krótkiego przeglądu. Szczególnie finisher rejestracji i szablony e-maili muszą być sprawdzone, bo TYPO3 v12 wprowadziło surowsze reguły obsługi błędów.

Przy starszych wersjach (sf_event_mgt 4.x i wcześniejsze) warto spojrzeć na konfigurację płatności, bo Stripe-API przeskoczyło kilka generacji. Aktualne rozszerzenie wspiera Stripe Elements i 3D Secure 2, starsze wersje pracowały jeszcze ze Stripe Sources, które są już deprecated. Gosign migruje istniejące instalacje sf_event_mgt zazwyczaj w jednym kroku wraz z upgrade core TYPO3. Szablony Fluid są przy tym ujednolicane na spójne identyfikatory, a przestarzałe wywołania ViewHelperów są automatycznie wykrywane i zastępowane. W tym samym kroku sprawdzamy, czy oznaczenie Schema.org/Event w JSON-LD jest aktualne i czy szablon detalu wydarzenia zawiera wszystkie pola dla Google Event Rich Snippets.

--- Gallery TYPO3 - Galeria obrazów | Gosign ---
> Rozszerzenie galerii obrazów oparte na TYPO3 File Collections. Lightbox, układ Masonry, Lazy Loading.

## Dlaczego sf_filecollection_gallery prawidłowo rozwiązuje galerie obrazów w TYPO3

Galerie obrazów należą do najczęstszych wymagań na stronach firmowych - zdjęcia produktowe, zdjęcia zespołu, dokumentacja eventów, projekty referencyjne. TYPO3 sam nie posiada natywnego elementu galerii. Standardowy element treści "Obrazy" wyświetla obrazy pod sobą lub w kolumnach, ale bez lightbox, bez filtrowania i bez elastycznych opcji layoutu. sf_filecollection_gallery zamyka tę lukę, wykorzystując TYPO3 File Collections jako źródło danych dla galerii, dostarczając jednocześnie integrację lightbox, różne layouty i lazy loading.

Decydująca zaleta wobec innych rozszerzeń galerii: redaktorzy pracują z systemem FAL, który już znają. Obrazy są organizowane w File Collections, a galeria automatycznie wyświetla wszystkie obrazy przypisanej kolekcji.

## Typowe scenariusze zastosowań

**Projekty referencyjne i portfolio.** Agencja architektoniczna wyświetla na każdej stronie projektu od 15 do 40 obrazów w galerii. Redaktor zarządza jedną File Collection per projekt. sf_filecollection_gallery renderuje galerię jako grid z lightbox. Przy kliknięciu na obraz otwiera się widok pełnoekranowy z nawigacją do następnego i poprzedniego obrazu.

**Dokumentacja eventów i fotografia prasowa.** Organizator targów dokumentuje każdy event 50 do 200 zdjęciami. Obrazy są przesyłane masowo do File Collection. sf_filecollection_gallery automatycznie generuje miniatury, optymalizuje czas ładowania przez lazy loading i wyświetla galerię w layoutzie Masonry.

**Katalogi produktowe z prezentacją wizualną.** Producent mebli wyświetla per kategoria produktu galerię ze zdjęciami aranżacyjnymi. Przez wiele File Collections i plugin frontendowy z filtrem kategorii odwiedzający mogą przełączać się między galeriami bez przeładowania strony.

## Architektura techniczna

sf_filecollection_gallery to rozszerzenie Extbase wbudowywane jako plugin TYPO3 w elementy treści. Źródłem danych są TYPO3 File Collections z File Abstraction Layer (FAL). Rozszerzenie dostarcza szablony dla layoutu Grid, layoutu Masonry i prostych list. Wszystkie szablony są nadpisywalne przez standardowe mechanizmy TYPO3.

Integracja lightbox wspiera kilka bibliotek: Fancybox, PhotoSwipe i Lightcase. Gosign zaleca PhotoSwipe ze względu na lepsze wsparcie dotykowe i brak zależności od jQuery. Lazy Loading jest natywnie zintegrowane przez atrybut `loading="lazy"`.

## Częste problemy i rozwiązania

**Galeria nie wyświetla obrazów, choć File Collection jest wypełniona.** Przyczyną jest często błędna konfiguracja Storage. File Collection odwołuje się do Storage, do którego frontend nie ma dostępu. Rozwiązanie: sprawdzenie w backendzie TYPO3, czy obrazy leżą we właściwym Storage i czy Storage jest skonfigurowany jako "public".

**Lightbox nie działa, obrazy otwierają się jako nowa strona.** Biblioteka JavaScript lightbox nie jest ładowana. Rozwiązanie: sprawdzenie w narzędziach deweloperskich przeglądarki, czy plik JS lightbox jest ładowany i czy w konsoli pojawiają się błędy JavaScript.

**Czas ładowania za długi przy dużych galeriach.** Galeria z ponad 100 obrazami w wysokiej rozdzielczości może ładować się wolno mimo lazy loading, bo miniatury nie są wystarczająco skompresowane. Rozwiązanie: konfiguracja TYPO3 Image Processing do generowania miniatur w stałym rozmiarze i aktywacja formatu WebP.

## Migracja i kompatybilność wersji

sf_filecollection_gallery jest aktywnie utrzymywane i dostępne dla TYPO3 v11 i v12 LTS. Rozszerzenie ma stabilne API i prawie żadnych zmian łamiących między wersjami.

Kto migruje ze starszego rozszerzenia galerii, musi jedynie zmienić źródło danych: zorganizować obrazy w File Collections i umieścić plugin sf_filecollection_gallery na stronach. Same obrazy pozostają w FAL i nie muszą być przenoszone.

Przy aktualizacji TYPO3 z v10 na v12 powinna być sprawdzona konfiguracja lightbox. Fancybox 2 nie jest już kompatybilne z aktualnymi wersjami jQuery. Gosign zaleca przejście na PhotoSwipe, które działa bez jQuery i dostarcza lepszą wydajność na urządzeniach mobilnych. Migracja z Fancybox na PhotoSwipe wymaga typowo 4 do 8 godzin.

--- sf_register TYPO3 - Rejestracja frontendowa | Gosign ---
> sf_register: Rejestracja użytkowników frontend w TYPO3. Zarządzanie profilem, Double-Opt-In. Z wykorzystaniem AI.

## Dlaczego TYPO3 bez rozszerzenia rejestracji nie stanie się portalem użytkowników

Rdzeń TYPO3 zna fe_users jako tabelę bazy danych i standardową maskę logowania, ale nie zna sposobu, w jaki nowy użytkownik mógłby samodzielnie się zarejestrować, zarządzać swoimi danymi czy zresetować hasło. Każda strona, która jest czymś więcej niż tylko organem publikacyjnym, potrzebuje tej funkcji: społeczności, obszary członkowskie, chronione pobieranie plików, spersonalizowane newslettery, płatne treści. sf_register wypełnia tę lukę smukłym podejściem opartym na Extbase, które koncentruje się dokładnie na rejestracji, profilu i resecie hasła, świadomie rezygnując z funkcji dostarczanych w kompleksowym rozwiązaniu femanager.

## Typowe scenariusze zastosowania

Wydawnictwo fachowe z 3 500 abonentów oferuje dostęp online do artykułów branżowych i opracowań. Każdy abonent otrzymuje konto powiązane z jego numerem abonamentu. sf_register przejmuje początkową rejestrację z potwierdzeniem Double-Opt-In przez e-mail, automatycznie tworzy użytkownika w grupie "Abonent" i aktywuje dostęp do chronionych stron. Gdy abonament wygasa, zadanie Schedulera TYPO3 usuwa przynależność do grupy bez kasowania konta, dzięki czemu użytkownik po odnowieniu umowy ma ponownie dostęp.

Drugim przypadkiem jest zrzeszenie branżowe z około 7 000 firm członkowskich, które prowadzi chroniony portal członkowski z dokumentacją konferencyjną, podglądami norm i forami dyskusyjnymi. sf_register umożliwia pierwszą rejestrację, ale jednocześnie wyzwala ręczny proces aktywacji, w którym pracownik zrzeszenia weryfikuje przynależność do firmy członkowskiej, zanim konto zostanie aktywowane. Workflow łączy Double-Opt-In z zatwierdzeniem administratora i wykorzystuje do tego hooki zdarzeń rozszerzenia.

Trzeci kontekst to instytucje publiczne jak domy kultury albo biblioteki miejskie, które chcą powiązać zgłoszenia na kursy lub listy ulubionych w katalogu z kontem użytkownika. Liczy się tu przede wszystkim prosta konfiguracja i niska złożoność: rozszerzenie nie musi zarządzać dwudziestoma polami profilu, a jedynie imieniem, e-mailem, hasłem i numerem karty bibliotecznej, więcej nie potrzeba, a sf_register dostarcza dokładnie to.

## Architektura techniczna: Extbase, TCA i finisher

sf_register jest porządnie zbudowany według modelu Extbase. Własny model FrontendUser rozszerza użytkownika core, akcje kontrolera obsługują Create, Edit, Confirm i ResetPassword, a szablonowanie odbywa się przez layouty Fluid. Pola obowiązkowe są sterowane konfiguracją TCA i można je rozszerzyć przez własny plik konfiguracyjny rozszerzenia. Pola custom jak firma, stanowisko czy numer członkowski wymagają małego wpisu TCA, właściwości modelu i uzupełnienia w szablonie Fluid, co daje deweloperom jasną strukturę, ale oznacza też, że każda adaptacja to praca kodowa.

Proces Double-Opt-In opiera się na linkach potwierdzających opartych na hashu, które są zapisywane w tabeli fe_users jako tymczasowy token i po kliknięciu resetują flagę disable. E-maile rozszerzenie wysyła przez interfejs mailera TYPO3, który wewnętrznie opiera się na Symfony Mailer, dzięki czemu również bardziej złożone konfiguracje z proxies SMTP lub usługami mailingowymi jak SendGrid działają bez problemów. Hashowanie haseł wykorzystuje własne usługi password-hash TYPO3 i jest tym samym automatycznie synchronizowane z każdym update'em core.

## Częste problemy i rozwiązania

Pierwszy problem to spam-rejestracje. Każda publiczna strona rejestracji przyciąga boty, które automatycznie zakładają konta, aby przez formularz resetu hasła wysyłać e-maile do osób trzecich lub umieszczać trackback-spam w funkcjach społecznościowych. Porządne rozwiązanie łączy sf_register z rozszerzeniem CAPTCHA jak sr_freecap lub polem honeypot, uzupełnione o rate-limiting na URL rejestracji w reverse proxy.

Drugi problem dotyczy dostarczania e-maili. E-maile potwierdzające regularnie lądują w folderze spam, gdy serwer TYPO3 pracuje bez rekordu SPF, podpisu DKIM lub Reverse-DNS. Rozszerzenie wysyła maila prawidłowo, ale serwer odbiorcy cicho go odrzuca. Rozwiązanie nie leży w sf_register, lecz w infrastrukturze mailowej: dedykowana usługa wysyłkowa z ustaloną reputacją domeny zauważalnie obniża współczynnik bounce.

Trzeci temat to ochrona danych. Zarejestrowani użytkownicy muszą w każdej chwili móc przeglądać, poprawiać i usuwać swoje dane, a usunięcie musi faktycznie działać kaskadowo, czyli obejmować również zamówienia, pobrania i inne powiązane rekordy. sf_register dostarcza formularze edycji, ale nie zapewnia procesu usunięcia zgodnego z RODO. Ten musi być uzupełniony jako oddzielny workflow, w którym usunięcie konta albo natychmiast, albo po okresie przejściowym, anonimizuje zależne dane.

Czwarty typowy problem dotyczy zasad haseł. sf_register domyślnie akceptuje również słabe hasła, a użytkownicy mają skłonność do używania krótkich lub trywialnych kombinacji. Password-Policies TYPO3 można aktywować przez konfigurację systemową, dzięki czemu sf_register automatycznie stosuje minimalną długość, klasy znaków i sprawdzanie blacklist, bez konieczności dostosowania samego rozszerzenia.

## Migracja i kompatybilność wersji

sf_register jest stabilne dla TYPO3 v11 i v12 i ma w społeczności reputację solidnej, utrzymywalnej alternatywy dla femanager. Wsparcie dla v13 jest z reguły dostępne krótko po wydaniu nowego core TYPO3, ale przy rozszerzeniach custom wymaga przeglądu składni adnotacji Extbase, która między wersjami doświadczyła drobnych zmian.

Kto migruje z femanager na sf_register, oszczędza na złożoności, ale musi sprawdzić, które funkcje były faktycznie używane: femanager oferuje out-of-the-box zatwierdzenie admina, upload zdjęcia profilowego i moderację backendową, podczas gdy sf_register replikuje te funkcje tylko przez dodatkowy kod lub event-listenery. Z drugiej strony ścieżka migracji z sf_register na femanager jest prostsza, bo struktura danych jest w dużej mierze kompatybilna. Gosign przejmuje takie migracje wraz z portowaniem szablonów mailowych i wyrównaniem grup użytkowników, dzięki czemu istniejący użytkownicy logują się bez problemu również po zmianie.

Kto uruchamia nowy projekt, powinien przed wyborem przemyśleć realne wymagania portalu: czy operator potrzebuje ręcznych aktywacji, zdjęć profilowych, złożonych przypisań ról? Wtedy femanager jest szybszą drogą. Czy wystarczy smukła self-service rejestracja z porządnym fundamentem Extbase i niewielkim narzutem? Wtedy sf_register jest właściwym wyborem. Decyzja rzadko jest trudna, gdy raz przejdzie się przez katalog potrzebnych funkcji, i oszczędza później znaczny nakład pracy przy dobudowywaniu.

--- sg_forms TYPO3 - Formularze | Gosign ---
> Rozszerzenie formularzy od SGalinski. Alternatywa dla Powermail i natywnego TYPO3 Form Framework.

## Trzy systemy formularzy w TYPO3 powodują więcej zamętu niż wyboru

Projekty TYPO3 stoją przy implementacji formularzy przed nietypowym luksusem: są trzy poważnie traktowane opcje. Natywny TYPO3 Form Framework (ext:form), powermail od in2code i sg_forms od SGalinski. Każde rozwiązanie ma własne mocne strony i własne ograniczenia. sg_forms pozycjonuje się jako droga środka: lżejszy niż powermail, ale z większym komfortem backendu niż ext:form. Rozszerzenie pochodzi od dostawcy usług TYPO3, firmy SGalinski, i jest aktywnie wykorzystywane w jej projektach klientowskich.

Kto już używa rozszerzeń SGalinski (sgalinski_base, sg_cookie_optin), znajdzie w sg_forms rozwiązanie wpasowujące się płynnie w ekosystem SGalinski.

## Typowe scenariusze to formularze kontaktowe, zapytania i proste formularze rekrutacyjne

Standardowym scenariuszem jest formularz kontaktowy na witrynie firmowej. Imię, e-mail, temat, wiadomość, checkbox RODO, wyślij. sg_forms dostarcza ten setup jako prekonfigurowany szablon, który redaktorzy mogą włączyć i dostosować w backendzie. Pola można dodawać, usuwać i sortować, oznaczać jako obowiązkowe, ustawiać walidacje. E-mail trafia do jednego lub kilku konfigurowalnych adresów odbiorców.

Drugim scenariuszem są wieloetapowe formularze zapytań. Firma rzemieślnicza pyta na stronie 1 o dane kontaktowe, na stronie 2 o rodzaj usługi (lista rozwijana), a na stronie 3 prosi o zdjęcia obiektu (upload pliku). sg_forms wspiera wieloetapowe formularze ze wskaźnikiem postępu i nawigacją wstecz. Dane są po wysłaniu zapisywane jako e-mail i opcjonalnie jako wpis w bazie.

Trzeci scenariusz: proste formularze rekrutacyjne. MŚP z trzema otwartymi stanowiskami nie potrzebuje systemu zarządzania kandydatami, lecz formularza, który przyjmuje CV i list motywacyjny jako PDF i przekazuje je do działu HR. sg_forms oferuje upload plików z walidacją typu i rozmiaru, połączony z mailem potwierdzającym dla kandydata. Z perspektywy RODO każdy taki proces wymaga klauzuli informacyjnej i precyzyjnie opisanej podstawy prawnej w polu zgody.

## Architektura techniczna opiera się na Extbase z definicją formularzy w YAML

sg_forms rejestruje plugin Extbase, który renderuje formularze z konfiguracji. Definicja formularza jest tworzona w backendzie przez interfejs graficzny lub alternatywnie definiowana jako plik YAML. Każde pole ma typ (Text, E-Mail, Textarea, Select, Radio, Checkbox, File, Hidden), reguły walidacji i opcjonalne warunki.

Architektura Finisherów podąża za tym samym wzorcem co w powermail: po wysłaniu uruchamiane są kolejno akcje. Standardowe Finishery to wysyłka maila, zapis do bazy danych i przekierowanie na stronę z podziękowaniem. Custom Finishery można implementować jako klasy PHP, np. dla integracji z CRM lub wywołań webhook.

Renderowanie frontendowe odbywa się przez szablony Fluid, które można nadpisać przez SiteSet lub TypoScript. Rozszerzenie dostarcza domyślny szablon, który działa bez modyfikacji, ale dla produkcyjnych witryn jest zazwyczaj dostosowywany do CI. Ochrona przed spamem jest dostępna przez pola honeypot i opcjonalną integrację CAPTCHA.

## Częste problemy dotyczą rozróżnienia względem powermail i licencji SGalinski

Najczęstsze pytanie brzmi: sg_forms czy powermail? Odpowiedź zależy od skali projektu. powermail ma większą społeczność, więcej dokumentacji, więcej finisherów stron trzecich i szerszy zakres funkcji (eksport PDF, wieloetapowa logika dowolnej złożoności). sg_forms jest szczuplejszy, ma mniejszy narzut i jest standardem w projektach SGalinski. Dla większości witryn firmowych powermail jest wyborem bezpieczniejszym. Dla klientów SGalinski już osadzonych w ekosystemie sg_forms jest bardziej spójny.

Drugi temat: licencjonowanie. sg_forms nie jest dostępny w TER (TYPO3 Extension Repository) jako darmowe rozszerzenie, lecz dostarczany jest poprzez projekty SGalinski. Oznacza to, że zespoły chcące używać rozszerzenia bez relacji z SGalinski muszą wyjaśnić dostępność i warunki licencji bezpośrednio z SGalinski.

Trzeci problem: migracja. Kto przechodzi z powermail na sg_forms (lub odwrotnie), musi utworzyć wszystkie istniejące definicje formularzy od nowa, ponieważ struktury danych są niekompatybilne. Istniejących wpisów formularzy w bazie nie da się migrować automatycznie.

## TYPO3 v12 jest wspierany, v13 podąża za cyklem wydawniczym SGalinski

SGalinski utrzymuje sg_forms we własnym cyklu wydawniczym powiązanym z wersjami LTS TYPO3. TYPO3 v12 jest aktywnie wspierany. Dla v13 należy spodziewać się aktualizacji, gdy SGalinski zaktualizuje własny pakiet rozszerzeń. Gosign zaleca, by przy wyborze systemu formularzy ważyć długoterminowe utrzymanie i wielkość społeczności jako czynniki decyzyjne: powermail z ponad 500 000 instalacji ma szerszą bazę niż sg_forms, co przy upgrade'ach TYPO3 oznacza krótsze oczekiwanie na kompatybilne wersje.

--- Shibboleth TYPO3 - SSO podstawa | Gosign ---
> Bazowe rozszerzenie Shibboleth dla TYPO3 (siostrzane do shibboleth_auth). Integracja Service Provider dla backendu i frontendu.

## Uczelnie i instytucje badawcze potrzebują SSO Shibboleth bezpośrednio w TYPO3

W sektorze akademickim Shibboleth jest faktycznym standardem Single Sign-On. Ponad 3 000 instytucji na świecie zorganizowanych jest w federacjach Shibboleth, w Polsce m.in. przez federację PIONIER.Id i federację USOS, łączącą uczelnie wyższe. Rozszerzenie Shibboleth dla TYPO3 integruje Service Provider bezpośrednio z CMS-em. Studenci, wykładowcy i pracownicy logują się swoimi danymi uczelnianymi i otrzymują dostęp do chronionych obszarów frontendu, a w razie potrzeby do backendu TYPO3. Rozszerzenie jest siostrzane wobec shibboleth_auth i dostarcza bazowej integracji dla Shibboleth SP, który musi być zainstalowany na serwerze WWW.

W odróżnieniu od rozszerzenia saml2, implementującego własny SP w PHP, rozszerzenie shibboleth opiera się na natywnym Shibboleth Service Provider (C++ lub Java), działającym jako moduł Apache lub filtr ISAPI. To bardziej odporna architektura w środowiskach o wysokiej dostępności.

## Typowe scenariusze dotyczą PIONIER.Id, systemów bibliotecznych i portali badawczych

Podstawowym scenariuszem jest integracja PIONIER.Id na polskich uczelniach. Uniwersytet prowadzi swój portal w TYPO3. Studenci klikają "Login", są przekierowywani do IdP uczelni, uwierzytelniają się i wracają na stronę TYPO3 z aktywną sesją. Rozszerzenie odczytuje atrybuty Shibboleth ze zmiennych środowiskowych serwera (REMOTE_USER, eppn, mail, affiliation) i tworzy lub aktualizuje użytkownika frontendu TYPO3.

Drugim scenariuszem są dostępy biblioteczne. Biblioteki uczelniane oferują bazy online, e-czasopisma i dokumenty badawcze przez swoje strony TYPO3. Dostęp ograniczony jest do osób związanych z uczelnią. Rozszerzenie Shibboleth sprawdza atrybut "eduPersonEntitlement" i przyznaje wstęp do licencjonowanych treści tylko użytkownikom z wartością "urn:mace:dir:entitlement:common-lib-terms".

Trzeci scenariusz: zfederowane portale badawcze. Konsorcjum naukowe z partnerami z pięciu uczelni prowadzi wspólny portal w TYPO3. Każdy partner ma własny IdP. Dzięki federacji PIONIER.Id wszyscy pracownicy partnerów mogą się logować, a portal nie musi prowadzić własnych kont. Rozszerzenie przypisuje użytkowników do właściwej grupy partnera na podstawie atrybutu "schacHomeOrganization".

## Architektura techniczna wymaga zainstalowanego Shibboleth SP na serwerze WWW

Samo rozszerzenie nie zawiera stosu SAML. Odczytuje atrybuty, które Shibboleth SP po pomyślnym uwierzytelnieniu udostępnia jako zmienne środowiskowe serwera lub nagłówki HTTP. SP musi być skonfigurowany jako moduł Apache (mod_shib) lub jako autoryzator FastCGI. Dla setupów nginx potrzebny jest Shibboleth SP jako backend FastCGI lub proxy oparte na Lua.

Rozszerzenie TYPO3 rejestruje Authentication Service, który przy każdym logowaniu frontendu lub backendu sprawdza, czy obecne są atrybuty Shibboleth. Jeśli tak, atrybuty są mapowane na pola użytkownika TYPO3: REMOTE_USER na username, mail na email, givenName i sn na first_name i last_name. Przypisanie do grupy odbywa się przez atrybut "eduPersonAffiliation": student, faculty, staff, employee są mapowane na grupy frontendu TYPO3.

Zarządzanie sesją podąża za cyklem życia Shibboleth: gdy sesja Shibboleth wygasa, użytkownik TYPO3 jest automatycznie wylogowywany. Single Logout (SLO) jest obsługiwane przez Shibboleth SP, rozszerzenie TYPO3 reaguje na zdarzenie wylogowania i niszczy sesję TYPO3.

## Częste problemy dotyczą konfiguracji Apache i brakujących atrybutów

Największym problemem jest poprawna konfiguracja Apache. Shibboleth SP musi wiedzieć, które URL-e ma chronić. Błędna dyrektywa Location prowadzi do tego, że SP albo chroni wszystkie strony (również publiczne), albo żadnej. Standardowa konfiguracja chroni /Shibboleth.sso/* dla samego SP i /typo3/ dla backendu. Obszary frontendu chronione są przez Lazy Session: SP ustawia atrybuty, gdy sesja Shibboleth istnieje, ale nie wymusza uwierzytelnienia. Rozszerzenie sprawdza wtedy w frontendzie TYPO3, czy atrybuty są obecne, i pokazuje chronione treści tylko zalogowanym użytkownikom.

Drugi problem: brakujące lub puste atrybuty. Nie każdy IdP dostarcza wszystkich atrybutów. Gdy IdP nie udostępnia atrybutu "mail", rozszerzenie nie może wpisać adresu mailowego do użytkownika TYPO3. Rozwiązanie: ustalić z operatorem IdP (centrum obliczeniowym uczelni), które atrybuty są zwolnione dla SP, i odpowiednio skonfigurować mapowanie atrybutów w rozszerzeniu.

Trzeci temat: wdrożenia kontenerowe. Instalacje TYPO3 w Dockerze często nie mają Apache z mod_shib. Alternatywą jest Shibboleth SP jako reverse proxy przed kontenerem TYPO3, przekazujący atrybuty jako nagłówki HTTP. Rozszerzenie musi wtedy być skonfigurowane tak, aby odczytywało atrybuty z nagłówków, a nie ze zmiennych środowiskowych. Ważne: nagłówki muszą być chronione przed spoofingiem - reverse proxy musi usuwać przychodzące nagłówki o nazwach atrybutów Shibboleth.

## TYPO3 v12 działa, kompatybilność z v13 wymaga sprawdzenia API Authentication Service

Rozszerzenie shibboleth wykorzystuje API Authentication Service TYPO3, które od lat jest stabilne, ale w v13 zostało dostosowane. Pod TYPO3 v12 aktualna wersja działa bez problemów. Dla v13 konieczna jest aktualizacja rejestracji service'u i konfiguracji middleware. Uczelnie planujące upgrade TYPO3 powinny włączyć integrację SSO jako osobny blok testowy do planu upgrade'u. Gosign zaleca, by równolegle z rozszerzeniem shibboleth ewaluować rozszerzenie oidc, ponieważ wiele IdP wspiera obecnie zarówno SAML, jak i OIDC, a OIDC umożliwia prostszą architekturę bez Shibboleth SP na serwerze.

--- shibboleth_auth TYPO3 - Integracja SSO | Gosign ---
> Shibboleth SSO w TYPO3: Konfiguracja, mapowanie atrybutów i rozwiązywanie problemów. Uwierzytelnianie enterprise z wykorzystaniem AI.

## Jak polskie uczelnie podłączają swoje portale TYPO3 do centralnego zarządzania tożsamością

Kto prowadzi portal TYPO3 na polskiej uczelni, prędzej czy później natrafi na Shibboleth. PIONIER-Id i federacja eduGAIN tworzą największą infrastrukturę Identity-Federation w polskim środowisku akademickim, a każda uczelnia, która chce udostępnić dane badawcze, materiały dydaktyczne lub usługi administracyjne na zewnątrz, musi uwierzytelniać swoich użytkowników wobec Shibboleth Identity Provider. shibboleth_auth to rozszerzenie, które wpasowuje TYPO3 w ten krajobraz: odczytuje asercje SAML poprzedzonego Shibboleth Service Providera i na tej podstawie tworzy fe_users oraz be_users.

## Typowe scenariusze zastosowania

Wydział lekarski z 8 000 studentów prowadzi portal TYPO3 z programami klinicznymi. Studenci mają widzieć swoje materiały dydaktyczne po zalogowaniu, a wykładowcy dodatkowo interfejs redakcyjny. Centralny Shibboleth-IdP uniwersytetu dostarcza atrybuty eduPersonAffiliation, schacHomeOrganization oraz unikalny identyfikator. shibboleth_auth przejmuje mapowanie tych atrybutów na grupy TYPO3 i pilnuje, żeby student nigdy nie trafił do backendu, podczas gdy wykładowca automatycznie ląduje w grupie redaktorskiej.

Drugim typowym przypadkiem są instytuty badawcze jak oddziały Polskiej Akademii Nauk albo sieci Łukasiewicza. Ich pracownicy pochodzą z kilkunastu uczelni partnerskich i każdy powinien móc logować się swoim kontem macierzystym do centralnych portali projektowych. shibboleth_auth w połączeniu z Service Providerem podłączonym do eduGAIN umożliwia dokładnie to: gościnny badacz z Uniwersytetu Warszawskiego loguje się swoim kontem AGH do portalu prowadzonego przez Politechnikę Wrocławską, bez konieczności istnienia lokalnego konta.

Trzeci kontekst to administracja publiczna, gdzie instytucje wojewódzkie coraz częściej prowadzą wojewódzkie IdP, aby połączyć konta obywatelskie i dostępy pracowników. Urząd wojewódzki z kilkoma portalami TYPO3 dla różnych departamentów może przez shibboleth_auth podłączyć wszystkie portale do centralnego IdP urzędu i zaoszczędzić sobie odrębnego zarządzania użytkownikami per portal.

## Architektura techniczna między SP, SAML i fe_user

shibboleth_auth jest zbudowany inaczej niż klasyczne usługi autoryzacyjne TYPO3: rozszerzenie nie mówi bezpośrednio SAML, lecz deleguje cały protokół do lokalnie zainstalowanego Shibboleth Service Providera. SP, zazwyczaj demon shibd z mod_shib w Apache lub odpowiednim modułem Nginx, przetwarza asercję SAML, waliduje podpisy i certyfikaty oraz udostępnia wyodrębnione atrybuty jako zmienne środowiskowe HTTP. shibboleth_auth odczytuje te zmienne, tworzy lub aktualizuje fe_user i loguje go do sesji TYPO3.

Konfiguracja rozszerzenia odbywa się przez konfigurację rozszerzenia TYPO3 i wzorzec Extbase-Service dla dostawców uwierzytelniania. Mapowanie atrybutów leży w pliku TypoScript albo bezpośrednio w backendzie rozszerzenia: zmienna HTTP po lewej, nazwa pola TYPO3 po prawej, opcjonalnie z transformacjami dla ID grup. Ważna jest kolejność w konfiguracji $TYPO3_CONF_VARS['SVCONF']['auth']['setup'], żeby shibboleth_auth zadziałał przed standardową usługą logowania.

## Częste problemy i rozwiązania

Najczęstszym błędem jest pętla przekierowań: użytkownik zostaje odesłany do IdP, wraca, jest ponownie odsyłany do IdP i tak dalej. Przyczyną jest prawie zawsze rozbieżność między domeną sesji SP i domeną TYPO3 albo brakujące ciasteczko, ponieważ SP zapisuje swoją sesję pod innym path, niż oczekuje TYPO3. Rozwiązaniem jest czyste rozdzielenie: sesja SP pod path /Shibboleth.sso, sesja TYPO3 pod / i obie pod tą samą domeną najwyższego poziomu.

Drugi problem dotyczy atrybutów: IdP dostarcza inną nazwę atrybutu, niż oczekuje rozszerzenie. Szczególnie przy federacjach akademickich przestrzenie nazw atrybutów zmieniają się między notacjami OID i URN. Bez czystej normalizacji użytkownik nie trafia do żadnej grupy albo otrzymuje pusty wpis w profilu. Plik attribute-map w SP, który sprowadza stare i nowe nazwy do jednej jednolitej lokalnej nazwy, trwale rozwiązuje ten problem.

Trzeci temat to rotacja certyfikatów. Każdy IdP regularnie wymienia swoje certyfikaty podpisujące i szyfrujące, zazwyczaj co dwa lata. SP musi pobierać nowe certyfikaty przez metadata-feed, inaczej walidacja asercji nagle się psuje. Konfiguracja metadata-providera w shibboleth2.xml powinna zatem zawsze działać z automatycznym interwałem odświeżania rzędu kilku godzin i weryfikacją podpisu wobec federation-signera.

Czwarty obszar problemów to czasy życia sesji. Shibboleth i TYPO3 mają niezależne timeouty: jeśli sesja SP wygaśnie, podczas gdy sesja TYPO3 jest wciąż aktywna, użytkownik widzi wprawdzie swoje chronione treści, ale ponowne logowanie się nie udaje, bo SP nie ma już ważnej asercji. Porządnym rozwiązaniem jest ustawienie obu czasów sesji na tę samą wartość i skonfigurowanie równoległego zachowania wylogowania, tak aby Single Logout faktycznie kończył obie sesje.

## Migracja i kompatybilność wersji

shibboleth_auth długo towarzyszył wersjom TYPO3 v9, v10 i v11 przez forki społeczności, sytuacja w v12 i v13 jest jednak różna w zależności od gałęzi forków. Niektóre forki dokonały skoku na usługi autoryzacji oparte na Symfony, inne pozostały na v11. Kto obecnie migruje na v12, powinien przed upgrade'em sprawdzić, czy własny zwój rozszerzenia jest jeszcze utrzymywany, czy lepszym wyborem będzie przejście na rozszerzenie OIDC.

Ścieżka migracji z Shibboleth na OIDC stała się aktualna dla wielu uczelni, odkąd Keycloak i porównywalne brokery tożsamości potrafią obsługiwać klientów SAML i OIDC równolegle. Gosign wielokrotnie towarzyszył takim przejściom i w okresie przejściowym z reguły prowadzi oba ścieżki uwierzytelniania równolegle, tak aby systemy legacy nadal logowały się przez Shibboleth, podczas gdy nowe portale mówią bezpośrednio OIDC.

Kto pozostaje na stałe przy shibboleth_auth, powinien realistycznie oszacować nakład pracy utrzymaniowej. Samo rozszerzenie zmienia się rzadko, ale otaczająca infrastruktura regularnie: Shibboleth SP publikuje aktualizacje bezpieczeństwa, federacje aktualizują metadane i certyfikaty, wersje Apache lub Nginx są wymieniane, a każda z tych zmian może złamać proces logowania. Porządny monitoring pipeline uwierzytelniania z syntetycznymi logowaniami i alertami przy nieudanych asercjach nie jest zatem nice-to-have, tylko częścią koncepcji operacyjnej stabilnej integracji SSO.

--- Slick Carousel TYPO3 - Slider | Gosign ---
> Integracja Slick Slider dla TYPO3. Oparty na jQuery. Gosign migruje na Swiper lub Splide: bez jQuery, lepsza wydajność, natywne zdarzenia dotykowe.

## Slick Carousel zmusza strony TYPO3 do ładowania jQuery, choć od lat istnieją alternatywy bez niego

Slick (autorstwa Ken Wheeler) był między 2014 a 2020 najpopularniejszym sliderem JavaScript. "The last carousel you'll ever need" obiecywała dokumentacja. Responsywny, dotykowy, Lazy Loading, Autoplay, Infinite Scroll, Variable Width. Dla TYPO3 istnieje rozszerzenie slickcarousel wbudowujące Slick jako element treści. Problem w 2026: Slick zależy od jQuery. Ostatnie wydanie Slick pochodzi z 2017 roku (v1.8.1). Żadnych aktualizacji od ponad 8 lat, żadnych poprawek błędów, żadnych łatek bezpieczeństwa.

jQuery samo jest potrzebne coraz mniejszej liczbie projektów TYPO3. TYPO3 v12 i v13 nie dostarczają jQuery standardowo. Kto korzysta ze Slick Carousel, musi ładować jQuery (90 KB zminimalizowane) jako dodatkową zależność - tylko dla slidera. To dług techniczny kosztujący wydajność przy każdym wywołaniu strony.

## Typowe scenariusze zastosowań

**Karuzele obrazów na podstronach.** Strony produktowe, strony referencji lub galerie z 5 do 20 obrazami wyświetlanymi jako poziomy slider. Slick renderuje obrazy ze strzałkami nawigacji i opcjonalnymi kropkami. W praktyce dane analityczne pokazują, że użytkownicy rzadko klikają dalej niż trzeci obraz.

**Slidery referencji.** Cytaty klientów rotujące w karuzeli. Każdy slajd pokazuje cytat, nazwisko i opcjonalnie zdjęcie. Slick jest tu często konfigurowany z centerMode i adaptiveHeight.

**Slidery logo dla referencji klienckich.** Poziomy pasek z 10 do 30 logami klientów automatycznie się przewijający. To scenariusz szczególnie łatwy do zastąpienia przez rozwiązanie wyłącznie CSS (animacja CSS z @keyframes), zupełnie bez JavaScript.

## Architektura techniczna

Rozszerzenie slickcarousel dla TYPO3 dołącza bibliotekę Slick (slick.min.js, 43 KB) i odpowiedni CSS (slick.css + slick-theme.css, 8 KB). jQuery (90 KB) jest ładowane jako zależność. Element treści pozwala redaktorom przesyłać obrazy i konfigurować opcje slidera: Slides to Show, Autoplay, Speed, Dots, Arrows, Fade, Responsive Breakpoints.

## Częste problemy i rozwiązania

**Slider skacze przy ładowaniu (Layout Shift).** Slick inicjalizuje slider przez JavaScript. Do załadowania i wykonania skryptu wszystkie obrazy wyświetlane są jeden pod drugim. Potem layout skacze, gdy Slick układa obrazy poziomo. To generuje mierzalny Cumulative Layout Shift (CLS) - Core Web Vital. Rozwiązanie krótkoterminowe: zdefiniowanie reguł CSS wymiarujących kontener slidera przed inicjalizacją JavaScript. Rozwiązanie długoterminowe: przejście na bibliotekę natywnie unikającą CLS.

**Zdarzenia dotykowe nie działają konsystentnie.** Obsługa dotyku Slick opiera się na własnej implementacji zdarzeń, która na aktualnych wersjach iOS i Android częściowo nie działa prawidłowo. Nie ma poprawki, bo Slick nie jest utrzymywany. Migracja to jedyna opcja.

**Braki dostępności.** Slick generuje markup niezgodny z WCAG: brakujące etykiety ARIA, brak nawigacji klawiaturą dla kropek, autoplay bez przycisku pauzy. Rozwiązanie: Splide jako alternatywa (pełne wsparcie ARIA, nawigacja klawiaturą, natywna pauza autoplay).

## Migracja i kompatybilność wersji

Rozszerzenie slickcarousel wspiera TYPO3 v10 i v11. Dla TYPO3 v12 i v13 nie ma oficjalnego wydania (stan kwiecień 2026). Sama biblioteka Slick jest od 2017 zamrożona na v1.8.1.

Gosign migruje slidery oparte na Slick na Swiper (ponad 175 funkcji, natywny dotyk, bez jQuery, 40 KB) lub Splide (zgodny z WCAG, bez jQuery, 30 KB). Migracja obejmuje trzy kroki: inwentaryzacja konfiguracji sliderów, wbudowanie i konfiguracja nowej biblioteki, dostosowanie szablonów Fluid. Per slider migracja trwa 2 do 4 godzin.

Dla sliderów logo Gosign zaleca czyste rozwiązanie CSS bez JavaScript: animacja CSS (`@keyframes scroll`) przesuwa loga poziomo, `animation-play-state: paused` przy hover zatrzymuje ruch. Wynik to 0 KB overhead JavaScript i działa na wszystkich przeglądarkach.

Dla sliderów referencji i treści Gosign zaleca Splide, ponieważ rozszerzenie oferuje pełne wsparcie ARIA i nawigację klawiaturą. Od europejskiego Aktu o Dostępności (od czerwca 2025) nowe strony muszą spełniać WCAG 2.1 AA. Slick Carousel nie zdaje tego testu - Splide tak. Migracja ze Slick na Splide opłaca się więc nie tylko dla wydajności, ale też dla zgodności.

--- Godziny otwarcia TYPO3 | Gosign ---
> Zarządzanie godzinami otwarcia dla TYPO3: Regularne godziny, święta, specjalne godziny otwarcia. Wyświetla aktualny status (Otwarte/Zamknięte).

## Odwiedzający chcą wiedzieć, czy instytucja jest właśnie otwarta, a nie sprawdzać regulaminowe godziny

Najczęstszym pytaniem, jakie odwiedzający zadają na stronie biblioteki, muzeum lub urzędu, jest proste: czy jesteście teraz otwarci? Mimo to większość witryn TYPO3 pokazuje statyczną tabelę regularnych godzin otwarcia, która w święta, dni okołoświąteczne i dni okolicznościowych zamknięć jest po prostu błędna. slub_web_openhours rozwiązuje dokładnie ten problem. Rozszerzenie zarządza regularnymi godzinami otwarcia, świętami i specjalnymi godzinami otwarcia w jednej strukturze danych i wyświetla we frontendzie aktualny status w czasie rzeczywistym: Otwarte (zielony) lub Zamknięte (czerwony), wraz z najbliższym terminem otwarcia. Rozszerzenie zostało zbudowane przez SLUB Drezno (Saksońska Biblioteka Krajowa, Państwowa i Uniwersytecka), która zna ten problem z praktyki.

## Typowe scenariusze dotyczą bibliotek, muzeów i instytucji samorządowych

Podstawowym scenariuszem są biblioteki uczelniane z wieloma lokalizacjami. Biblioteka Uniwersytecka prowadzi cztery oddziały o różnych godzinach otwarcia. Główny gmach ma inne godziny niż filia, a w okresie wakacyjnym obowiązują skrócone godziny otwarcia. slub_web_openhours zarządza każdą lokalizacją jako osobnym rekordem z własnymi godzinami. Na stronie student od razu widzi, która lokalizacja jest właśnie otwarta i do której godziny.

Drugim scenariuszem są muzea i galerie. Muzeum Sztuki ma regularne godziny otwarcia (wt-nd 10-18, pn zamknięte), ale wydłużone godziny w trakcie wystawy specjalnej (codziennie do 21) i zamknięcia w święta. Rozszerzenie pozwala wprowadzać te wyjątki dla zdefiniowanych okresów bez zmiany regularnych godzin. Po upływie okresu specjalnego automatycznie obowiązują znów godziny standardowe.

Trzeci scenariusz: instytucje samorządowe takie jak biura obsługi mieszkańców, baseny i domy kultury. Miasto z 20 obiektami publicznymi prowadzi godziny otwarcia centralnie w backendzie TYPO3. Na każdej stronie obiektu widżet pokazuje aktualny status. Latem basen zewnętrzny ma inne godziny niż zimą, a w długie weekendy biuro obsługi mieszkańców jest zamknięte. Wszystko to można odwzorować przez rozszerzenie.

## Architektura techniczna przechowuje reguły i wyjątki w kalendarycznej strukturze danych

Rozszerzenie definiuje trzy poziomy danych: regularne godziny (poniedziałek do niedzieli, godzina:minuta do godzina:minuta), wyjątki cykliczne (święta powtarzające się co roku) i wyjątki jednorazowe (zamknięcie 15 marca, wydłużone otwarcie 24 grudnia). Regularne godziny stanowią bazę, wyjątki je nadpisują. Logika jest prosta: czy dla bieżącej daty istnieje wyjątek? Jeśli tak, obowiązują godziny wyjątkowe. Jeśli nie, obowiązują regularne godziny dla danego dnia tygodnia.

Plugin frontendowy renderuje status przez szablony Fluid. Aktualny stan (otwarte/zamknięte) jest obliczany po stronie serwera i emitowany jako klasa CSS, dzięki czemu kolorystyką można sterować przez Tailwind lub własne CSS. Opcjonalnie widżet pokazuje najbliższy termin otwarcia: "Aktualnie zamknięte. Najbliższe otwarcie: poniedziałek, 08:00".

Dla integracji ze Schema.org rozszerzenie może emitować OpeningHoursSpecification jako JSON-LD, co Google wyświetla we wpisach Knowledge Panel organizacji. Jest to szczególnie istotne dla instytucji widocznych w Google Maps, które chcą tam pokazywać poprawne godziny otwarcia.

## Częste problemy dotyczą stref czasowych, brakujących świąt i cache'owania

Najczęstszym problemem jest cache. Gdy TYPO3 cache'uje stronę, a cache wygasa dopiero po dwóch godzinach, widżet przez nawet dwie godziny pokazuje błędny status. Rozwiązanie: osadzić widżet godzin otwarcia jako uncached plugin przez USER_INT. Kosztuje to minimalnie wydajności (jedno zapytanie do bazy na request), ale gwarantuje poprawny status.

Drugi problem: brakujące święta. Rozszerzenie nie dostarcza prekonfigurowanej listy świąt. Każda instytucja musi wprowadzić swoje święta ręcznie lub uzupełnić je przez import. W Polsce ważne jest uwzględnienie świąt państwowych takich jak 1 i 3 maja, 11 listopada, Boże Ciało, jak również odmiennych dat ruchomych. Można je importować skryptem z publicznych źródeł kalendarzowych.

Trzeci temat: strefy czasowe w instytucjach międzynarodowych. Rozszerzenie pracuje ze strefą czasową serwera. Gdy serwer TYPO3 działa w UTC, a instytucja w czasie środkowoeuropejskim, wyświetlane godziny się nie zgadzają. Rozwiązanie: ustawić strefę czasową PHP w konfiguracji TYPO3 na strefę instytucji, a w przypadku instytucji w wielu strefach dostosować obliczenie przez UTC+offset w szablonie Fluid.

## Rozszerzenie działa pod TYPO3 v11 i v12, wsparcie dla v13 zależy od zespołu SLUB

slub_web_openhours jest utrzymywane przez SLUB Drezno jako projekt open source. Aktualizacje podążają za wewnętrznym cyklem wydawniczym biblioteki. TYPO3 v12 jest wspierany. Dla v13 kompatybilność zależy od tego, czy zespół deweloperski SLUB zaktualizuje rozszerzenie. Ponieważ technicznie jest ono szczupłe (brak skomplikowanych zależności API), migracja na v13 wymaga niewielkiego nakładu pracy. Gosign zaleca przy projektach godzin otwarcia walidować równolegle wyjście Schema.org po stronie Google, aby godziny otwarcia poprawnie pojawiały się w Google Maps i Knowledge Panel.

--- solrfal TYPO3 - Indeksowanie plików Solr | Gosign ---
> solrfal dla TYPO3: Indeksowanie plików w Apache Solr. Konfiguracja, optymalizacja i migracja, z wykorzystaniem AI. 25 lat doświadczenia.

## Dlaczego standardowe wyszukiwanie TYPO3 zawodzi przy dużych zbiorach dokumentów

Gdy instalacja TYPO3 zarządza więcej niż kilkuset plikami PDF, wbudowane wyszukiwanie napotyka dwie granice: znajduje treści tylko w polach bazodanowych, nie w plikach, a jego logika rankingu ignoruje sygnały trafności, których potrzebują redaktorzy. solrfal wypełnia dokładnie tę lukę, łącząc File Abstraction Layer (FAL) z TYPO3 bezpośrednio z Apache Solr i udostępniając do wyszukiwania każdy plik wraz z jego metadanymi. Rozszerzenie kierowane jest do organizacji, które traktują dokumenty jako rdzeń swojej pracy wiedzy: urzędów z formularzami, wydawnictw z literaturą fachową, uczelni z materiałami dydaktycznymi.

## Typowe scenariusze zastosowania

W politechnice z około 40 000 studentów regulamin studiów leży w 180 plikach PDF, rozproszonych po dwunastu wydziałach. Bez solrfal student znajduje przepis dotyczący zgłoszenia na egzamin tylko wtedy, gdy redaktor dodatkowo zapisał ten tekst jako opis meta. Z solrfal Apache Tika indeksuje każdą stronę, a zapytanie wyszukiwania zwraca właściwy akapit wraz z cytatem.

Drugi scenariusz znają urzędy centralne, które dostarczają teksty ustaw, dyrektyw i formularzy przez TYPO3-CMS. Dokumenty często się zmieniają, a uprawnienia dostępu są powiązane z jednostkami organizacyjnymi. solrfal automatycznie synchronizuje przynależność fe_groups plików z indeksem Solr, dzięki czemu pracownik z wydziału V widzi tylko te trafienia, do których ma uprawnienia odczytu.

Trzeci przypadek występuje w wydawnictwach fachowych: wydawnictwo z 12 000 artykułów czasopism w formacie PDF chce udostępnić archiwum do przeszukiwania fasetowego według rocznika, autora i rubryki. solrfal wyodrębnia metadane, wypełnia pola Solr i dostarcza bazę danych dla faset, której klasyczne rozszerzenia TYPO3 takie jak ke_search w tej skali nie są już w stanie obsłużyć.

## Architektura techniczna oparta na Apache Tika i EXT:solr

solrfal jest rozszerzeniem kluczowego rozszerzenia EXT:solr od dkd Internet Service i wymaga obowiązkowo działającego serwera Apache Solr, zazwyczaj w wersji 8 lub 9. Samą ekstrakcję tekstu przejmuje Apache Tika, albo jako wbudowana usługa w kontenerze Solr, albo jako samodzielny serwer Tika. solrfal wpina się przez TYPO3-Event-API w cykl życia FAL: każdy wgrany, przeniesiony lub usunięty plik uruchamia zadanie indeksowania, które jest asynchronicznie przetwarzane w TYPO3-Scheduler.

Konfiguracja solrfal odbywa się przez TypoScript i konfigurację rozszerzenia. Schemat Solr można dostosować przez Managed Schema API, dzięki czemu dodatkowe pola jak typ dokumentu, wydział czy język można dodać bez restartu Solr. Tuning trafności odbywa się przez Boosting-Queries i Function Queries, które są definiowane w konfiguracji zapytań EXT:solr. solrfal dziedziczy przy tym wszystkie funkcje językowe EXT:solr, w tym wielojęzyczne analyzery dla niemieckiego, angielskiego, francuskiego i innych standardowych języków.

## Częste problemy i rozwiązania

Pierwszy problem pojawia się zwykle przy pierwszym indeksowaniu: Apache Tika zawiesza się przy uszkodzonych lub zaszyfrowanych plikach PDF z błędem OutOfMemoryError i zrywa cały indekser. Rozszerzenie oznacza wtedy plik jako błędny, ale przy kolejnym przebiegu nie pomija go automatycznie. Analizujemy logi Tika, oddzielamy zaszyfrowane od rzeczywiście uszkodzonych plików i ustawiamy pre-check, który sortuje problematyczne pliki, zanim dotrą do indeksera.

Drugi powracający temat to trafność. Zespoły zgłaszają, że wyszukiwanie wprawdzie znajduje wszystkie dokumenty, ale nierelewantne trafienia są na samej górze. Powód leży niemal zawsze w domyślnej wadze pól: solrfal indeksuje całą zawartość pliku w jedno pole, bez rozróżnienia między tytułem, nagłówkami a tekstem głównym. Porządne rozwiązanie wymaga dostosowanego schematu z oddzielnymi polami dla tytułu, metadanych i body oraz regułami boostingu, które wyżej oceniają trafienia w tytułach.

Trzeci problem dotyczy wydajności przy dużych zbiorach. Powyżej około 50 000 zindeksowanych plików scheduler staje się wąskim gardłem, ponieważ solrfal przetwarza każde zadanie pojedynczo. Rozwiązaniem jest indeksowanie wsadowe w połączeniu z dedykowanym procesem workera, który działa równolegle do normalnych zadań schedulera i priorytetowo obsługuje zadania solrfal. Dodatkowo opłaca się indeksowanie różnicowe, które przy każdym przebiegu przetwarza tylko nowe lub zmienione pliki, co znacząco zmniejsza nakład pracy przy stabilnych zbiorach dokumentów.

Czwarty, rzadszy temat pojawia się przy instalacjach wielojęzycznych: solrfal indeksuje pliki niezależnie od języka do wspólnego indeksu, dzięki czemu francuskie opracowanie pojawia się w niemieckiej liście trafień, jeśli słowo kluczowe jest międzynarodowo rozpowszechnione. Czyste rozdzielenie językowe wymaga kilku Solr-Cores lub dodatkowej fasety językowej, którą można sterować przez konfigurację EXT:solr oddzielnie dla każdego site-root.

## Migracja i kompatybilność wersji

solrfal podąża za cyklem wydawniczym EXT:solr, który obecnie wspiera TYPO3 v12 i v13. Skok z TYPO3 v9 na v12 to najczęstsza ścieżka migracji i niemal zawsze oznacza też skok z Solr 6 na Solr 9. Przy tym zmienia się format schematu, Managed-Schema-API i niektóre klasy analyzerów, co wymaga pełnego reindeksu. Istniejące reguły boostingu muszą być zwalidowane pod kątem nowego zachowania parsera zapytań, ponieważ Solr 9 inaczej ocenia niektóre domyślne operatory niż Solr 6.

Kto migruje z ke_search lub z wyszukiwania wyłącznie opartego na bazie danych, musi uwzględnić, że solrfal wymaga własnego serwera Solr i tym samym rozszerza wymagania hostingowe. Gosign od lat towarzyszy takim migracjom i w razie potrzeby przejmuje też przejście na konfigurację Solr opartą na kontenerach, która wpasowuje się w istniejące pipeline'y deploymentu.

Warto też zauważyć, że obciążenie utrzymaniem solrfal nie jest do niedocenienia: sam Solr otrzymuje regularne aktualizacje bezpieczeństwa, a schemat musi być sprawdzany przy każdym większym upgrade pod kątem nowych klas analyzerów. Projekt, który raz zdecyduje się na solrfal, przejmuje tym samym odpowiedzialność za własny stos wyszukiwania i powinien to uwzględnić przy początkowym sizingu oraz planowaniu zasobów operacyjnych.

--- sr_freecap TYPO3 - Self-hosted CAPTCHA | Gosign ---
> Rozszerzenie TYPO3 CAPTCHA bez usług zewnętrznych. Self-hosted ochrona antyspamowa, zgodna z RODO, brak danych do Google.

## Dlaczego polskie urzędy i szpitale są zdane na self-hosted ochronę CAPTCHA

reCAPTCHA od Google jest technicznie skuteczne, ale dla wielu operatorów w Polsce prawnie problematyczne: każde osadzenie prowadzi do przekazania danych osobowych do Google w USA, wymaga aktywnej zgody zgodnie z Prawem komunikacji elektronicznej i jest krytycznie oceniane przez UODO. sr_freecap to odpowiedź na ten problem: w pełni self-hosted rozszerzenie CAPTCHA dla TYPO3, które nie wyzwala żadnych zewnętrznych żądań, nie przesyła danych użytkownika stronom trzecim i tym samym działa bez blokady banera zgody. Grupą docelową są urzędy, szpitale, uczelnie i firmy dbające o prywatność, które muszą chronić formularze przed spamem botów bez wchodzenia w nową zależność od amerykańskiej usługi.

## Typowe scenariusze zastosowania

Szpital kliniczny prowadzi formularz kontaktowy dla zapytań pacjentów, formularz rekrutacyjny dla personelu pielęgniarskiego i formularz zapytań prasowych. Wszystkie trzy są regularnie atakowane przez boty, które wysyłają ogólne wiadomości reklamowe lub próby phishingu. IT kliniki zdecydowało, żeby nie osadzać usług Google, bo inspektor ochrony danych chce uniknąć obowiązku zgody. sr_freecap generuje grafiki po stronie serwera z kombinacjami liter, sprawdza wprowadzenie na własnym serwerze i w żadnym momencie nie wysyła informacji na zewnątrz.

Drugim przypadkiem jest administracja miejska z około 15 formularzami online dla spraw obywateli, od zgłoszenia przeprowadzki po wniosek o kartę parkingową dla mieszkańców. UODO przy audycie wyraźnie zalecił, aby nie stosować zewnętrznych CAPTCHA. sr_freecap integruje się z TYPO3 Form API (Powermail lub Form Framework) i tym samym chroni wszystkie formularze bez dodatkowej zgody.

Trzeci kontekst to izby i stowarzyszenia, które zarządzają listami członków, adresami lub rejestrami publicznymi. Każda z tych organizacji prowadzi formularz wyszukiwania lub kontaktowy, który musi być chroniony przed botami, ale jednocześnie zachowuje podstawową postawę ochrony danych. sr_freecap dostarcza prosty test wizualny, który dla ludzi jest rozwiązywalny, a dla prostych botów OCR stanowi zauważalną przeszkodę.

## Architektura techniczna: GD-Library, sesja i Form API

sr_freecap generuje obrazy CAPTCHA po stronie serwera z biblioteką GD lub ImageMagick, przy czym GD jest opcją standardową i dostępną praktycznie w każdej instalacji PHP bez dodatkowego nakładu pracy. Litery są losowo wybierane z konfigurowalnego alfabetu, rysowane w obrazie z szumem tła i zniekształceniem oraz dostarczane do przeglądarki. Oczekiwany tekst jest zapisywany w sesji TYPO3 i przy wysłaniu formularza porównywany z wprowadzeniem użytkownika.

Integracja w formularze odbywa się przez walidator dla TYPO3 Form Framework oraz przez Powermail-API, gdzie pole jest osadzone jako dodatkowy element w definicji formularza. Audio-CAPTCHA jako alternatywa dostępności są w rozszerzeniu dostępne, ale domyślnie wyłączone, i powinny być aktywowane przy formularzach z szeroką grupą docelową, aby nie wykluczać użytkowników niedowidzących. Konfiguracja sr_freecap odbywa się przez TypoScript, który steruje długością stringu CAPTCHA, używanymi czcionkami i poziomem szumu.

## Częste problemy i rozwiązania

Pierwszy problem to czytelność kontra bezpieczeństwo. Jeśli CAPTCHA jest zbyt zaszumiony, również ludzcy użytkownicy zawodzą i porzucają formularz, co zauważalnie obniża współczynnik konwersji. Jeśli jest zbyt słabo zaszumiony, nowoczesne silniki OCR odczytują tekst w sekundach. Praktyczne rozwiązanie leży w umiarkowanym zniekształceniu w połączeniu z polem honeypot, które jest niewidocznym polem wprowadzania w formularzu. Ludzie go nie wypełniają, boty często tak, a te zgłoszenia są cicho odrzucane.

Drugi problem dotyczy dostępności. Czysto wizualne CAPTCHA wyklucza niewidomych i niedowidzących użytkowników, co w instytucjach publicznych może być naruszeniem ustawy o dostępności cyfrowej oraz standardu WCAG. Aktywacja trybu audio i dodatkowo prosty test arytmetyczny jako alternatywa tworzą dostępne drogi spełnienia wymagania bez rezygnacji z ochrony.

Trzeci temat to obsługa sesji. sr_freecap zapisuje oczekiwane rozwiązanie w sesji PHP, co przy load-balancerach bez session-affinity lub przy bezstanowo hostowanych instalacjach TYPO3 prowadzi do błędów. Rozwiązaniem są albo sticky sessions na load-balancerze, albo wspólne session-backend jak Redis, z którego korzystają wszystkie nody.

Czwarty problem to skuteczność wobec nowoczesnych frameworków botów. Proste headless-browsery jak Puppeteer wprawdzie same nie potrafią rozwiązać wizualnych CAPTCHA, ale mogą przekazać zadanie zewnętrznej usłudze rozwiązywania, która w ciągu sekund dostarczy poprawną odpowiedź. Przeciwko takim atakom sam rozpoznawanie obrazów CAPTCHA nie wystarcza, a kombinacja z checkami opartymi na zachowaniu jak analiza ruchu myszy lub wspomnianym honeypotem jest bardziej skuteczną obroną.

## Migracja i kompatybilność wersji

sr_freecap jest jednym z najstarszych rozszerzeń CAPTCHA dla TYPO3 i ma burzliwą historię wersji: dla TYPO3 v11 i v12 istnieją utrzymywane forki społeczności, kompatybilność z v13 jest różna między forkami. Kto obecnie migruje na v12 lub v13, powinien przed upgrade'em sprawdzić, czy własny zwój rozszerzenia jest aktywnie utrzymywany, a w razie wątpliwości przejść na inne podejście CAPTCHA.

Alternatywy dla sr_freecap w spektrum przyjaznym dla prywatności to hCaptcha (możliwa wersja self-hosted), Friendly Captcha z niemieckiej produkcji i pola honeypot w połączeniu z serwerowym rate-limiting. Gosign doradza przy wyborze w zależności od wolumenu formularzy, grupy użytkowników i wymagań regulacyjnych i w razie potrzeby buduje rozwiązanie hybrydowe, które najpierw filtruje ruch botów honeypotem, a tylko podejrzane zgłoszenia kieruje do kroku CAPTCHA.

Dla instytucji, które z powodów regulacyjnych nie mogą osadzać zewnętrznych usług, self-hosted rozwiązanie jak sr_freecap często pozostaje jedynym praktycznym wyborem, a nakład utrzymania jest do ogarnięcia. Ważne jest, aby regularnie dopasowywać ochronę CAPTCHA do aktualnych wzorców spamu i analizować statystyki nieudanych prób, aby rozpoznać, kiedy upgrade zniekształcenia lub kombinacja z innymi środkami ochrony staje się sensowna.

--- Storytelling TYPO3 - Scrollytelling | Gosign ---
> Rozszerzenie scrollytelling dla TYPO3: Parallax-Scrolling, animowane bloki treści, animacje wyzwalane przewijaniem.

## Raporty roczne i prezentacje produktów potrzebują czegoś więcej niż tekstu i obrazu

Statyczne strony z długimi blokami tekstu sprawdzają się przy dokumentacji i artykułach blogowych. Ale raporty roczne, premiery produktów i historie firm potrzebują formatu prowadzącego odwiedzającego przez narrację. Scrollytelling, czyli storytelling oparty na interakcji przewijania, ugruntował się jako format znajdujący się między statycznym tekstem a kosztownym wideo. Rozszerzenie Storytelling dla TYPO3 wprowadza Parallax-Scrolling, animowane bloki treści i animacje wyzwalane przewijaniem bezpośrednio do CMS, bez konieczności zlecania zewnętrznej usłudze lub agencji programowania unikatu na każdą stronę.

Przewaga nad custom-rozwojem: redaktorzy mogą utrzymywać treści w backendzie TYPO3, sortować bloki i konfigurować animacje, bez angażowania programisty.

## Typowe scenariusze to raporty roczne, premiery produktów i strony kampanijne

Najbardziej widocznym scenariuszem są cyfrowe raporty roczne. Firmy, fundacje i organizacje pozarządowe coraz częściej publikują swoje wyniki finansowe jako interaktywną historię webową zamiast PDF. Scrollytelling-raport roczny pokazuje w pierwszej sekcji liczbę nagłówkową (przychody, wolumen darowizn, liczba członków), która animacyjnie odlicza się przy przewijaniu. W drugiej sekcji pojawiają się wykresy z porównaniem do roku poprzedniego. W trzeciej zdjęcia portretowe i cytaty opowiadają historię stojącą za liczbami. Cała opowieść mieści się na jednej stronie, którą odwiedzający przewija.

Drugim scenariuszem są prezentacje produktów w sektorze B2B. Producent maszyn przedstawia nową linię produkcyjną. Przy przewijaniu obraca się rendering 3D maszyny, pojawiają się dane techniczne, animacje pokazują proces produkcji. Nie jest to wideo (brak ładowania, brak buforowania), lecz animacja sterowana przewijaniem, którą odwiedzający przechodzi we własnym tempie.

Trzeci scenariusz: strony kampanijne. Organizacja pomocowa pokazuje drogę darowizny: od kliknięcia przycisku "Wesprzyj", przez wybór projektu, po raport z kraju docelowego. Każda sekcja przewijania zawiera zdjęcie, krótki tekst i animację wizualizującą postęp.

## Architektura techniczna renderuje sekcje jako bloki treści sterowane przewijaniem

Rozszerzenie definiuje własny typ elementu treści "Storytelling", składający się z sekcji. Każda sekcja jest rekordem backendu z polami dla nagłówka, tekstu, obrazu/wideo (FAL), koloru tła, typu animacji i wyzwalacza przewijania. Sekcje sortuje się w backendzie i razem tworzą one historię scrollową.

We frontendzie każda sekcja renderuje własny obszar wypełniający viewport. Animacje wyzwalane są przez przejścia CSS i IntersectionObserver: gdy sekcja wjeżdża w obszar widoczny, startuje skonfigurowana animacja (Fade-In, Slide-Left, Zoom, Counter). Efekty parallax przesuwają obrazy tła wolniej niż pierwszy plan, co tworzy wrażenie głębi.

Rozszerzenie dostarcza zestaw predefiniowanych animacji. Własne animacje można dodawać przez klasy CSS wybierane jako typ animacji w backendzie. Bazą JavaScript jest minimum: brak frameworka, tylko natywny IntersectionObserver i requestAnimationFrame. Utrzymuje to rozmiar bundle'a poniżej 20 KB.

Dla wydajności kluczowe jest, aby obrazy ładowały się leniwie. Scrollytelling-raport z 15 sekcjami i jednym obrazem wysokiej rozdzielczości na sekcję bez lazy loadingu generuje od 30 do 50 MB zapytań. Z lazy loadingiem przeglądarka pobiera tylko aktualnie widoczną i kolejną sekcję.

## Częste problemy dotyczą wydajności mobilnej i dostępności

Największym problemem przy scrollytellingu na urządzeniach mobilnych jest wydajność. Efekty parallax, które na desktopie działają płynnie, na starszych smartfonach przycinają. Powód: mobilne przeglądarki renderują zdarzenia przewijania inaczej niż desktopowe i ograniczają requestAnimationFrame w tle. Rozwiązanie: wyłączyć parallax na viewportach mobilnych i zastąpić go prostymi animacjami fade-in. Rozszerzenie powinno być konfigurowalne przez TypoScript - które animacje są aktywne na których breakpointach.

Drugi problem: dostępność (WCAG 2.1). Animacje sterowane przewijaniem są problematyczne dla użytkowników z zaburzeniami przedsionkowymi (zawroty głowy, mdłości przy ruchu). CSS prefers-reduced-motion musi być respektowany. Rozszerzenie powinno przy włączonym ustawieniu Reduce Motion wyłączać wszystkie animacje i pokazywać treści jako statyczne bloki. Nie wszystkie rozszerzenia storytelling implementują to poprawnie.

Trzeci temat: SEO. Google potrafi crawlować animacje JavaScript, ale treść musi być dostępna również bez JavaScript. Sekcje muszą być renderowane jako zwykłe bloki HTML, a nie puste kontenery wypełniane dopiero przez JavaScript. Rozszerzenie powinno podążać za zasadą Progressive Enhancement: najpierw treść, potem animacja.

## TYPO3 v12 jest wspierany, v13 wymaga aktualizacji rejestracji elementów treści

Rozszerzenia scrollytelling dla TYPO3 dostępne są w różnych wariantach od różnych dostawców. Kompatybilność z v12 zapewnia większość aktywnie utrzymywanych rozszerzeń. Dla v13 konieczna jest aktualizacja rejestracji elementów treści (NewContentElementWizard) i konfiguracji TCA, ponieważ v13 dostosował konfigurację elementów treści opartą na FlexForm. Gosign w nowych projektach scrollytelling stawia na architekturę oddzielającą logikę animacji jako samodzielny moduł JavaScript od integracji TYPO3, dzięki czemu przy przyszłych upgrade'ach konieczne jest dostosowanie tylko warstwy TYPO3.

--- Plan lekcji TYPO3 - Szkoły | Gosign ---
> Tabelaryczna prezentacja planu lekcji dla szkół i instytucji edukacyjnych. Widok dzienny/tygodniowy, filtrowanie według przedmiotu/nauczyciela/klasy.

## Polskie szkoły publikują plany lekcji jako PDF, choć rozwiązanie cyfrowe oszczędza czas wszystkim

Większość polskich szkół tworzy plan lekcji w programach typu Vulcan UONET, eDziennik Librus lub aSc Plan Lekcji, eksportuje go jako PDF i wgrywa na stronę. Rodzice, uczniowie i nauczyciele przewijają nieczytelną tabelę, która nie skaluje się na smartfonie. Zmiany (zastępstwa, zamiana sali, odwołanie zajęć) wymagają nowego uploadu PDF. Rozszerzenie Plan lekcji dla TYPO3 zastępuje ten przepływ pracy cyfrową prezentacją bezpośrednio na stronie: widok dzienny i tygodniowy, filtrowanie po przedmiocie, nauczycielu i klasie, responsywna prezentacja na wszystkich urządzeniach, widok do druku dla pokoju nauczycielskiego.

Dla organów prowadzących, które utrzymują strony swoich szkół centralnie w TYPO3, jest to skalowalne rozwiązanie dla dziesięciu, dwudziestu czy pięćdziesięciu szkół jednocześnie - szkoły podstawowe, licea, technika, zespoły szkół.

## Typowe scenariusze sięgają od pojedynczej szkoły podstawowej po zespół szkół

Bazowym scenariuszem jest pojedyncza szkoła z 20 klasami, 40 nauczycielami i planem lekcji zmieniającym się co tydzień. Sekretariat utrzymuje plan w backendzie TYPO3 lub importuje go z aSc Plan Lekcji. Na stronie rodzice widzą widok tygodniowy klasy swojego dziecka. Filtr ogranicza widok do jednej klasy, jednego przedmiotu lub jednego nauczyciela. Zastępstwa wyświetlane są jako kolorystycznie wyróżnione zmiany, dzięki czemu rodzice rano od razu widzą, czy lekcje odbywają się normalnie.

Drugim scenariuszem są zespoły szkół i organy prowadzące z centralną instalacją TYPO3. Miasto prowadzi 15 stron szkolnych na jednej multi-site instancji TYPO3. Każda szkoła ma własne plany lekcji, ale prezentacja jest jednolita. Rozszerzenie konfiguruje się raz i przez dziedziczenie TypoScript wprowadza na wszystkie strony szkół. Nowe szkoły uruchamia się z tą samą konfiguracją.

Trzeci scenariusz: uniwersytety ludowe i instytucje doszkalające. Centrum kształcenia ustawicznego oferuje 200 kursów na semestr. Plan pokazuje, który kurs odbywa się którego dnia tygodnia i w której sali. Uczestnicy filtrują po obszarach (języki, IT, zdrowie) i widzą swój osobisty widok tygodniowy. W połączeniu z logowaniem zarejestrowani uczestnicy widzą tylko swoje zarezerwowane kursy.

## Architektura techniczna przechowuje dane planu lekcji jako ustrukturyzowane rekordy

Rozszerzenie definiuje kilka tabel: klasy, nauczyciele, przedmioty, sale i lekcje. Każda lekcja to rekord z powiązaniami do klasy, nauczyciela, przedmiotu, sali, dnia tygodnia i przedziału czasowego. Dane utrzymywane są ręcznie w backendzie lub importowane przez CSV/XML z programów typu Vulcan czy aSc Plan Lekcji.

Plugin frontendowy renderuje dane jako tabelę HTML z macierzą dzień tygodnia - przedział czasowy. Filtry (klasa, nauczyciel, przedmiot) przekazywane są jako parametry GET i przetwarzane po stronie serwera. Tabela jest responsywna przez CSS: na desktopie pokazuje pełny widok tygodniowy, na urządzeniach mobilnych przełącza się na widok dzienny lub jest przewijalna poziomo.

Widok do druku tworzy zoptymalizowaną prezentację bez nawigacji i stopki, z podziałami stron między dniami tygodnia. Print-CSS optymalizuje tabelę pod A4 w orientacji poziomej.

Dla importu z aSc Plan Lekcji istnieją rozwiązania społecznościowe parsujące eksport XML do struktury bazy TYPO3. Import można skonfigurować jako zadanie Schedulera, dzięki czemu zmiany w programie planującym automatycznie pojawiają się na stronie.

## Częste problemy dotyczą utrzymania danych i prezentacji mobilnej

Największym problemem jest bieżące utrzymanie danych. Plany lekcji zmieniają się co tydzień, zastępstwa codziennie. Gdy dane utrzymywane są ręcznie w backendzie TYPO3, nakład pracy przy 20 klasach po 30 godzin tygodniowo jest znaczny. Rozwiązanie: skonfigurować zautomatyzowany import z programu planującego. Bez tego importu rozszerzenie jest praktyczne tylko dla małych placówek z niewieloma klasami.

Drugi problem: prezentacja mobilna. Tabela planu lekcji z pięcioma kolumnami (pn-pt) i dziesięcioma wierszami (lekcje) nie mieści się na ekranie smartfona o szerokości 375 pikseli. Przewijanie poziome jest pragmatycznym rozwiązaniem, ale rodzice uważają je za nieintuicyjne. Lepiej: na viewportach mobilnych automatycznie przełączać na widok dzienny (tylko bieżący dzień) z gestami swipe do zmiany dnia.

Trzeci temat: ochrona danych. Gdy nauczyciele pojawiają się z imienia i nazwiska w publicznym planie lekcji, może to być problematyczne z punktu widzenia RODO. Niektóre szkoły pokazują dlatego tylko przedmiot i klasę, bez nazwiska nauczyciela. Rozszerzenie powinno przez konfigurację sterować, które pola wyświetlane są we frontendzie. UODO konsekwentnie egzekwuje minimalizację danych również w sektorze edukacji.

## Rozszerzenie jest rozwiązaniem niszowym bez aktywnego wsparcia społeczności

Rozszerzenia plan lekcji dla TYPO3 to produkty niszowe z małą społecznością. Kompatybilność z TYPO3 v12 zapewniają nowsze wersje, ale aktywny rozwój dla v13 nie jest gwarantowany. Szkoły i organy prowadzące planujące długoterminowo powinny ocenić, czy własny rozwój oparty na standardowych elementach treści TYPO3 (Extbase-Records + szablony Fluid) nie jest bardziej zrównoważony niż rozszerzenie społecznościowe o niepewnym horyzoncie utrzymania. Gosign doradza placówkom edukacyjnym i organom prowadzącym przy wyborze między rozszerzeniem społecznościowym, custom-rozwojem a dedykowanymi rozwiązaniami SaaS dla planów lekcji z integracją TYPO3.

--- Styleguide TYPO3 - Rozszerzenie QA | Gosign ---
> Rozszerzenie Core TYPO3, które wizualizuje wszystkie elementy treści na jednej stronie.

## Dlaczego Styleguide to najważniejsze rozszerzenie QA dla programistów szablonów TYPO3

Rozwój szablonów w TYPO3 ma systematyczny problem z jakością: programiści testują swoje szablony Fluid z danymi, które aktualnie istnieją na stronie. Ale elementy treści mają dziesiątki wariantów - nagłówki z podtytułem i bez, bloki tekstowe z 3 słowami lub 3 akapitami, obrazy w pionie i poziomie, tabele z 2 lub 20 kolumnami. Kto sprawdza tylko aktualną stronę, pomija skrajne przypadki, które ujawniają się dopiero po uruchomieniu.

Rozszerzenie Styleguide rozwiązuje ten problem, automatycznie wyświetlając wszystkie elementy treści systemu TYPO3 w każdej dostępnej konfiguracji na jednej stronie. Dzięki temu programista od razu widzi, czy jego CSS i szablony prawidłowo obsługują wszystkie warianty.

## Typowe scenariusze zastosowań

**Rozwój szablonów przy projektach relaunch.** Firma zleca relaunch TYPO3 z nowym Corporate Design. Programista frontend tworzy szablony Fluid dla wszystkich elementów treści. Bez Styleguide musi dla każdego elementu tworzyć dane testowe w backendzie - proces trwający godziny przy ponad 30 elementach. Styleguide automatycznie generuje wszystkie dane testowe: elementy tekstowe o różnych długościach, obrazy o różnych proporcjach, listy, tabele, formularze. Programista otwiera URL i widzi wszystko na pierwszy rzut oka.

**Testy regresji po aktualizacjach TYPO3.** Aktualizacja TYPO3 z v11 na v12 subtelnie zmienia renderowanie poszczególnych elementów treści. Element Textmedia nagle renderuje dodatkowy wrapper-div, który łamie layout CSS. Bez Styleguide to wychodzi dopiero, gdy redaktor zgłosi błąd na stronie live. Z Styleguide programista po aktualizacji od razu widzi, które elementy się zmieniły.

**Uzgadnianie między zespołem projektowym a deweloperskim.** Designerzy dostarczają makiety Figma dla 10 elementów treści. Ale jak wyglądają pozostałe 25 standardowych elementów w nowym designie? Styleguide czyni tę lukę widoczną.

## Architektura techniczna

Styleguide to oficjalne rozszerzenie TYPO3 Core System Extension, dostarczane z kodem źródłowym TYPO3. Musi tylko zostać aktywowane w Extension Manager. Rozszerzenie działa na dwóch poziomach: generator TCA analizuje definicje Table Configuration Array wszystkich zarejestrowanych elementów treści i generuje z nich rekordy testowe. Moduł backendowy pozwala administratorowi generować, aktualizować i usuwać dane testowe. Strona frontendowa wyświetla wszystkie wygenerowane elementy treści w layoucie frontendowym.

Styleguide nie ma zewnętrznych zależności. Jako rozszerzenie Core jest automatycznie aktualizowane z każdą aktualizacją TYPO3 i zawsze kompatybilne z daną wersją.

## Częste problemy i rozwiązania

**Strona Styleguide wyświetla puste obszary.** Dane testowe zostały wygenerowane, ale strona frontendowa nie pokazuje wszystkich elementów. Przyczyna: SysFolder z danymi testowymi nie jest prawidłowo skonfigurowany jako punkt startowy lub brakuje konfiguracji TypoScript. Rozwiązanie: sprawdzenie w module backendowym, czy drzewo stron jest prawidłowo założone.

**Brak obrazów w wygenerowanych danych testowych.** Styleguide próbuje dołączyć obrazy testowe przez FAL. Jeśli folder Fileadmin jest pusty, pola obrazów pozostają puste. Rozwiązanie: ręczne przesłanie co najmniej jednego obrazu do Fileadmin przed generowaniem danych testowych.

**Problemy z wydajnością strony Styleguide.** Gdy wszystkie elementy treści są renderowane na jednej stronie, czas ładowania przy złożonych szablonach może wynosić 10 do 15 sekund. Rozwiązanie: aktywacja Styleguide tylko na środowisku deweloperskim lub staging, nigdy na systemie live.

## Migracja i kompatybilność wersji

Styleguide jest dostępne jako Core System Extension od TYPO3 v8 i jest automatycznie aktualizowane z każdą wersją TYPO3. Nie ma oddzielnych numerów wersji ani problemów z kompatybilnością.

Przy aktualizacji TYPO3 dane testowe Styleguide powinny być wygenerowane na nowo. Stare dane testowe mogą być niespójne na nowym systemie, ponieważ definicje TCA zmieniają się między wersjami TYPO3.

Gosign integruje Styleguide w każdy relaunch TYPO3 jako stały element procesu QA. Strona Styleguide jest tworzona na środowisku staging jako permanentna referencja i służy zespołowi projektowemu jako URL akceptacji. Zmiany w szablonach Fluid lub CSS stają się tam natychmiast widoczne, bez konieczności tworzenia treści testowej na poszczególnych stronach.

--- t3skin TYPO3 - Stylizacja backendu | Gosign ---
> Legacy Backend Skin dla starszych wersji TYPO3. Od TYPO3 v7+ nie jest już istotny. Nowoczesne wersje TYPO3 mają własną stylizację backendu.

## t3skin jest przestarzały od TYPO3 v7, ale wiele instalacji wciąż działa na wersjach, które go potrzebują

t3skin był pakietem stylizacji backendu dla TYPO3 v4 i v6. Definiował ikony, kolory, odstępy i całe wrażenie wizualne backendu TYPO3. Od TYPO3 v7 stylizacja backendu została zintegrowana z core'em, t3skin jako osobne rozszerzenie stał się zbędny. Mimo to t3skin regularnie pojawia się w analizach stanu istniejącego, ponieważ jest zainstalowany w starych wdrożeniach i przy upgrade'ach do aktualnych wersji TYPO3 powoduje błędy. Kto znajduje t3skin na liście rozszerzeń, ma jasny sygnał: ta instalacja jest albo przestarzała, albo nie została w pełni uporządkowana przy poprzednim upgrade.

## Typowe scenariusze dotyczą wyłącznie instalacji legacy

Jedynym uprawnionym scenariuszem dla t3skin jest instalacja TYPO3 w wersji od 4.5 do 6.2, której z przyczyn technicznych lub organizacyjnych nie można zaktualizować. W takich instalacjach t3skin dostarcza design backendu. Bez t3skin backend byłby wizualnie bezużyteczny: brakujące ikony, zepsute układy, nieczytelne formularze.

Drugim scenariuszem jest faza przejściowa podczas migracji. Gdy agencja migruje instalację TYPO3 v6 do v12, t3skin podczas procesu upgrade'u wciąż istnieje na liście rozszerzeń, ale po upgrade jest dezaktywowany i usuwany. W tej fazie t3skin może powodować konflikty z nową stylizacją backendu, jeśli nie zostanie odinstalowany na czas.

Trzeci (anty-)scenariusz: niektórzy administratorzy ręcznie instalowali t3skin w TYPO3 v7 lub v8, ponieważ preferowali stary design backendu. Działało to krótkoterminowo, ale generowało błędy wyświetlania, bo CSS t3skin i CSS core'a wzajemnie się nadpisywały. Najpóźniej od TYPO3 v9 nie jest to już opcja.

## Architektura techniczna była pakietem CSS/ikon bez logiki biznesowej

t3skin nie był rozszerzeniem w klasycznym sensie (brak kontrolera, brak modelu, brak repozytorium). Składał się z plików CSS, sprite'ów ikon, kilku snippetów JavaScript dla interfejsu backendu i ext_emconf.php, które rejestrowało go jako rozszerzenie systemowe. Cała logika była wizualna: kolory, czcionki, odstępy, ikony. Core TYPO3 renderował moduły backendu, t3skin decydował tylko, jak one wyglądają.

Od TYPO3 v7 core sam przejął to zadanie. Stylizacja backendu została zintegrowana z pakietem rozszerzeń systemowych "backend". Ikony przeniesiono na system oparty na SVG (IconFactory), CSS przemigrowano na Less, a później na SCSS. t3skin nie był w stanie odwzorować tych zmian, ponieważ opierał się na starym systemie ikon opartym na sprite'ach.

## Częste problemy powstają, gdy t3skin nie jest usuwany przy upgrade

Najczęstszym problemem jest biały lub zepsuty backend po upgrade TYPO3. Gdy t3skin jest wciąż zainstalowany w instalacji v12, nadpisuje pliki CSS core'a przestarzałymi regułami. Rezultat: przyciski bez tła, ikony, które się nie ładują, nawigacja modułów, której nie da się klikać. Rozwiązanie: odinstalować t3skin przez Extension Manager i wyczyścić wpisy w sys_registry. Gdy backend jest tak zepsuty, że Extension Manager nie jest dostępny, pomaga dezaktywacja przez wiersz poleceń: typo3/sysext/core/bin/typo3 extension:deactivate t3skin.

Drugi problem: osierocone pliki CSS. Również po deinstalacji t3skin pliki CSS w fileadmin/ lub typo3temp/ mogą pozostać i być cache'owane przez przeglądarkę. Po usunięciu konieczne jest pełne wyczyszczenie cache (cache przeglądarki, cache TYPO3, cache CDN).

Trzeci temat: dostosowania backendu oparte na t3skin. Niektóre agencje pisały w TYPO3 v6 własny CSS backendu wykorzystujący klasy t3skin jako bazę. Po usunięciu t3skin takie dostosowania się rozpadają. Rozwiązanie: zmigrować własny CSS backendu na aktualne klasy CSS core'a.

## t3skin nie ma ścieżki upgrade'u, migracja oznacza usunięcie

Nie istnieje aktualizacja t3skin do nowej wersji, ponieważ rozszerzenie nie ma następcy. Następcą jest sam core TYPO3. Migracja oznacza: odinstalować t3skin, usunąć wszystkie referencje do klas CSS t3skin w niestandardowych modułach backendu i wykorzystywać IconFactory dla własnych ikon. Gosign przeprowadza to porządkowanie w ramach każdej migracji TYPO3 i sprawdza przy okazji, czy w instalacji nie pozostały inne rozszerzenia legacy (css_styled_content, rtehtmlarea, adodb), które również trzeba usunąć.

--- Prawa autorskie obrazów TYPO3 | Gosign ---
> Automatyczne dodawanie informacji o prawach autorskich do obrazów. Odczytywanie metadanych IPTC/EXIF, wyświetlanie jako overlay lub stopka.

## Brakujące oznaczenia praw autorskich kosztują firmy każdego roku tysiące złotych w wezwaniach prawnych

Agencje fotograficzne typu Getty Images, Adobe Stock i Shutterstock systematycznie wykorzystują webcrawlery, które przeszukują internet w poszukiwaniu nielicencjonowanych lub błędnie oznaczonych zdjęć. Brakujące informacje o prawach autorskich są najczęstszym powodem wezwań prawnych. W zależności od agencji i zdjęcia roszczenia oscylują między 2 000 a 20 000 złotych za jedno zdjęcie. W przypadku witryny z 200 zdjęciami stockowymi pojedynczy audyt agencji może wygenerować pięcio- lub sześciocyfrowe dopłaty. tgm_copyright automatyzuje oznaczanie praw autorskich w TYPO3: rozszerzenie odczytuje metadane IPTC i EXIF z plików obrazów i automatycznie wyświetla informację o prawach jako overlay lub stopkę. Każde zdjęcie zarządzane przez FAL (File Abstraction Layer) otrzymuje swoją informację o prawach bez ręcznej interwencji redaktorów.

W polskim prawie autorskim obowiązuje art. 34 ustawy o prawie autorskim wymagający wymienienia twórcy i źródła; brak takiej informacji to klasyczna podstawa roszczeń odszkodowawczych.

## Typowe scenariusze obejmują witryny korporacyjne, wydawnictwa i instytucje publiczne

Najczęstszym scenariuszem jest witryna korporacyjna ze 100-500 zdjęciami z różnych źródeł: zdjęcia własne, fotografie stockowe z Adobe Stock, zdjęcia prasowe od klientów, ilustracje od freelancerów. Każde zdjęcie ma inne wymagania licencyjne. Niektóre wymagają wymienienia nazwiska ("Foto: Jan Kowalski"), inne podania źródła ("Źródło: Adobe Stock"), jeszcze inne tylko znaku copyright. tgm_copyright odczytuje informacje z pól IPTC (Creator, Copyright Notice, Source) i wyświetla je w skonfigurowanym formacie.

Drugim scenariuszem są wydawnictwa i domy medialne. Lokalna gazeta publikuje codziennie 30 do 50 zdjęć. Fotografowie dostarczają zdjęcia z osadzonymi danymi IPTC. Rozszerzenie automatycznie wyświetla "Foto: [nazwisko fotografa]" pod każdym zdjęciem. Oszczędza to redakcji od pięciu do dziesięciu minut na artykuł, ponieważ informacji o prawach nie trzeba wpisywać ręcznie.

Trzeci scenariusz: instytucje publiczne korzystające ze zdjęć Creative Commons. Licencje CC wymagają poprawnej atrybucji (autor, typ licencji, link do licencji). tgm_copyright potrafi odczytać te informacje z metadanych i wyświetlić jako sformatowaną stopkę z linkiem do licencji.

## Architektura techniczna wykorzystuje metadane FAL i system Fluid-ViewHelper

tgm_copyright rejestruje się jako rozszerzenie TYPO3 i sięga do tabeli sys_file_metadata. Gdy zdjęcie zostaje wgrane do TYPO3 przez FAL, rozszerzenie automatycznie ekstrahuje pola IPTC i EXIF i zapisuje je w polach metadanych tabeli FAL. Istotne pola IPTC to: Creator (fotograf), Copyright Notice (właściciel praw), Source (źródło), Description (podpis) i Credit (agencja).

We frontendzie rozszerzenie udostępnia ViewHelper Fluid renderujący informację o prawach do każdego zdjęcia. ViewHelper można skonfigurować jako overlay (półprzezroczysty pasek u dołu zdjęcia), stopkę (tekst pod zdjęciem) lub tooltip (efekt po najechaniu). Stylizacja sterowana jest przez klasy CSS, dzięki czemu informacja o prawach pasuje do designu witryny.

Dla zdjęć bez osadzonych metadanych rozszerzenie oferuje fallback: redaktorzy mogą wpisać informację o prawach ręcznie w dialogu metadanych FAL. Rozszerzenie priorytetuje wpisy ręczne nad metadanymi automatycznymi, dzięki czemu błędne dane IPTC można nadpisać.

## Częste problemy dotyczą brakujących metadanych i umiejscowienia overlay

Dominującym problemem są zdjęcia bez osadzonych danych IPTC. Wiele pobranych zdjęć stockowych jest przed uploadem przetwarzanych w Photoshopie, przy czym metadane giną. Gdy brak pola IPTC Creator, rozszerzenie nie potrafi wygenerować informacji o prawach. Rozwiązanie: ustanowić workflow, w którym zdjęcia przed uploadem są sprawdzane pod kątem obecności metadanych. Alternatywa: moduł backendu TYPO3 listujący wszystkie zdjęcia bez wpisu copyright i wzywający do ręcznego uzupełnienia.

Drugi problem: overlay zasłania ważne elementy zdjęcia. Przy portretach overlay z prawami u dołu zdjęcia może zasłonić twarz lub nazwę produktu. Rozwiązanie: umożliwić konfigurację per zdjęcie, czy prawa wyświetlane są jako overlay czy stopka. Domyślnie stopka jest wyborem bezpieczniejszym.

Trzeci temat: wydajność przy dużych zbiorach zdjęć. Gdy rozszerzenie przy każdym żądaniu zdjęcia odczytuje dane IPTC z pliku zamiast z bazy danych, na stronach z 20 zdjęciami staje się to zauważalne. Rozwiązanie: dane IPTC odczytywać jednorazowo przy uploadzie i cache'ować w bazie, a nie przy każdym żądaniu frontendu.

## TYPO3 v12 jest wspierany, v13 wymaga aktualizacji rejestracji ViewHelper

tgm_copyright wykorzystuje API FAL, które w core TYPO3 jest stabilne. Rozszerzenie działa pod v12 bez problemów. Dla v13 konieczne są dostosowania w rejestracji namespace ViewHelper i konfiguracjach TCA, ponieważ v13 zmienił konwencje namespace dla ViewHelper. Gosign zaleca wykonywanie audytu zdjęć przy każdym upgrade TYPO3: sprawdzić wszystkie zdjęcia witryny pod kątem poprawnego wyświetlania informacji o prawach i uzupełnić brakujące przypisania.

--- Ticketshop TYPO3 - Bilety online | Gosign ---
> Sprzedaż biletów online na wydarzenia: Wybór miejsc, kontyngenty, płatności, generowanie E-biletów, walidacja QR-Code.

## Organizatorzy płacą 5 do 15 procent prowizji platformom biletowym, choć ich własna witryna byłaby lepszym kanałem sprzedaży

eBilet, Going., Ticketmaster i Eventbrite pobierają opłaty od biletu: między 5 a 15 procent ceny biletu plus stałą kwotę. Dla teatru z 50 000 sprzedanych biletów rocznie i średnią ceną 120 złotych daje to 300 000 do 900 000 złotych prowizji rocznie. Ticketshop bezpośrednio na witrynie TYPO3 eliminuje tę prowizję. Rozszerzenie umożliwia sprzedaż biletów online z wyborem miejsca, zarządzaniem kontyngentami, płatnością przez popularne bramki płatnicze, generowaniem e-biletów jako PDF i walidacją QR-Code przy wejściu. Dla teatrów, filharmonii, konferencji i samorządowych domów kultury, które sprzedają bilety głównie znanej publiczności abonamentowej, to ekonomicznie atrakcyjna alternatywa.

## Typowe scenariusze sięgają od teatru miejskiego po konferencję branżową

Najbardziej widocznym scenariuszem jest teatr lub filharmonia ze stałym planem sali. 400 numerowanych miejsc, w tym 50 w kategorii Premium, 200 na parterze i 150 na balkonie. Odwiedzający wybiera miejsce na interaktywnym planie sali, widzi cenę i dodaje bilet do koszyka. Po opłaceniu otrzymuje e-bilet jako PDF z kodem QR mailem. Wieczorem przedstawienia obsługa skanuje kod QR smartfonem. Cały proces przebiega przez witrynę TYPO3, bez pośredników.

Drugim scenariuszem są konferencje i targi. Konferencja branżowa oferuje trzy kategorie biletów: Early Bird (do 8 tygodni przed wydarzeniem), Regular i VIP. Kontyngenty ograniczają każdą kategorię do stałej liczby. Ticketshop pokazuje dostępność w czasie rzeczywistym: "Early Bird: 12 ze 100 dostępnych". Po upływie okresu Early Bird kategoria jest automatycznie dezaktywowana.

Trzeci scenariusz: wydarzenia samorządowe. Biblioteka miejska oferuje spotkania autorskie, warsztaty i wydarzenia dla dzieci. Bilety są bezpłatne, ale liczba miejsc ograniczona. Ticketshop pełni tu rolę systemu rezerwacji. Odwiedzający rezerwują online, otrzymują potwierdzenie, a w przypadku przekroczenia liczby miejsc trafiają na listę oczekujących.

## Architektura techniczna łączy rekordy wydarzeń, plan sali i bramkę płatności

Ticketshop składa się z czterech komponentów: zarządzanie wydarzeniami, edytor planu sali, checkout z integracją płatności i generowanie biletów. Wydarzenia tworzy się jako rekordy Extbase w backendzie TYPO3: tytuł, data, godzina, miejsce, kategorie, ceny, kontyngenty. Plan sali zapisany jest jako interaktywna grafika SVG, w której każde miejsce ma unikalny identyfikator powiązany z systemem kontyngentów.

Proces checkoutu zbiera wybrane bilety, pyta o dane kontaktowe i przekierowuje do bramki płatności. Popularne integracje to Stripe, PayU, Przelewy24, Mollie i PayPal - dla polskiego rynku PayU i Przelewy24 są standardem, ponieważ obsługują BLIK i wszystkie polskie banki. Po pomyślnej płatności rozszerzenie generuje PDF biletu z kodem QR (na podstawie unikalnego ID biletu) i wysyła go mailem. Kod QR zawiera URL lub hash walidowany przy wejściu.

Walidację kodu QR przy wejściu można realizować przez prostą aplikację webową sprawdzającą ID biletu w bazie TYPO3 i ustawiającą status na "wykorzystany". Bilet można wykorzystać tylko raz, duplikaty są odrzucane.

## Częste problemy dotyczą płatności, anulowań i edytora planu sali

Największym problemem jest obsługa płatności. Zgodność z PCI-DSS wymaga, aby dane kart kredytowych nigdy nie dotykały własnego serwera. Dlatego płatność musi przebiegać przez certyfikowanego dostawcę płatności udostępniającego Hosted Payment Form. Rozszerzenie przekierowuje użytkownika do płatności u dostawcy i odbiera wynik przez callback. Gdy callback się nie powiedzie (timeout, restart serwera), bilet jest opłacony, ale nieoznaczony jako opłacony. Rozwiązanie: zadanie reconciliation sprawdzające otwarte transakcje u dostawcy płatności.

Drugi problem: anulowania i zwroty. Gdy odwiedzający anuluje bilet, płatność musi zostać zwrócona, a miejsce ponownie zwolnione. Wymaga to zarówno żądania refundu u dostawcy płatności, jak i zmiany statusu w bazie TYPO3. Bez zautomatyzowanego workflow anulowań jest to proces manualny. Polska ustawa o prawach konsumenta wymaga sprawnego zwrotu w przypadku anulowania wydarzenia.

Trzeci temat: edytor planu sali. Interaktywne plany sal SVG z 400 lub więcej miejscami są pracochłonne w tworzeniu. Każde miejsce wymaga ID, kategorii i współrzędnych. Zmiany w planie sali (nowy sektor, zmiana kolejności) wymagają aktualizacji pliku SVG i powiązań w bazie.

## Rozszerzenia Ticketshop są custom-rozwojami bez standardu w TER

Nie istnieje standardowe rozszerzenie Ticketshop w TER TYPO3 obejmujące wszystkie opisane funkcje. Ticketshopy to niemal zawsze custom-rozwoje skrojone pod konkretne wymagania obiektu. Kompatybilność z TYPO3 zależy zatem od wykonawcy, a nie od cyklu wydawniczego społeczności. Gosign zaleca przy nowych projektach Ticketshop ocenić, czy headless'owa architektura TYPO3 z wyspecjalizowanym frontendem (React, Vue) nie jest długoterminowo bardziej utrzymywalna niż monolityczne rozwiązanie Extbase.

--- Tournament TYPO3 - Turnieje | Gosign ---
> Zarządzanie turniejami/zawodami dla TYPO3: Grupy, pary meczowe, wyniki, tabele. Kluby sportowe, E-Sport, wewnętrzne zawody firmowe.

## Kluby sportowe zarządzają turniejami w Excelu, choć ich strona byłaby logicznym miejscem dla wyników i tabel

W każdy weekend w Polsce odbywają się tysiące turniejów klubowych. Wyniki są wpisywane w arkuszach Excela, ładowane na stronę jako PDF lub w najlepszym razie ręcznie przepisywane do tabeli HTML. Odwiedzający stronę klubu widzą nieaktualne dane, bo nikt nie aktualizuje strony. Rozszerzenie Tournament dla TYPO3 zastępuje ten przepływ pracy: grupy, pary meczowe, wyniki i tabele zarządza się bezpośrednio w CMS-ie. Wyniki są wprowadzane, tabela aktualizuje się automatycznie. Dla klubów sportowych, organizacji e-sportowych i firm organizujących wewnętrzne zawody to profesjonalna prezentacja bez wysiłku programistycznego.

## Typowe scenariusze obejmują turnieje piłkarskie, ligi e-sportowe i zawody firmowe

Najczęstszym scenariuszem jest turniej piłkarski klubu sportowego. 16 drużyn rywalizuje w 4 grupach. Każda grupa rozgrywa fazę grupową (każdy z każdym), najlepsze dwie drużyny awansują do fazy pucharowej. Rozszerzenie odwzorowuje ten tryb w pełni: faza grupowa z punktami, różnicą bramek i bezpośrednim porównaniem, faza pucharowa z ćwierćfinałami, półfinałami i finałem. Wyniki wprowadza się w backendzie, tabele i drabinka turniejowa we frontendzie aktualizują się automatycznie.

Drugim scenariuszem są ligi e-sportowe. Klub gamingowy organizuje ligę Counter-Strike z 12 drużynami i sezonem na 20 kolejek. Rozszerzenie zarządza tabelą ligi, terminarzem i historią wyników. Każda drużyna ma stronę profilową ze składem, statystykami i wcześniejszymi wynikami. Prezentacja dostosowana jest do CI klubu, a nie do układu zewnętrznej platformy.

Trzeci scenariusz: wewnętrzne zawody firmowe. Firma z pięcioma lokalizacjami organizuje doroczny turniej szachowy. Pracownicy zapisują się przez intranetową stronę TYPO3, rozszerzenie losuje pary, a postęp turnieju widać na żywo. To zastosowanie niszowe, ale dla firm chcących wspierać zaangażowanie i wymianę między lokalizacjami realny przypadek użycia.

## Architektura techniczna modeluje turnieje jako zagnieżdżoną strukturę rekordów

Rozszerzenie definiuje kilka modeli Extbase: Tournament (turniej), Team (drużyna), Group (grupa), Match (mecz), Result (wynik). Turniej zawiera grupy, każda grupa zawiera drużyny. Mecze są generowane automatycznie (każdy z każdym) lub definiowane ręcznie (faza pucharowa). Wyniki zapisywane są jako rekordy Result powiązane z meczem.

Obliczanie tabeli odbywa się po stronie serwera: punkty (3-1-0 lub konfigurowalnie), różnica bramek, zdobyte bramki, bezpośrednie porównanie. Logikę sortowania można konfigurować przez TypoScript, ponieważ różne dyscypliny sportowe priorytetyzują różne kryteria (piłka nożna: różnica bramek przed bramkami zdobytymi; piłka ręczna: stosunek bramek).

Frontend renderuje dwa główne widoki: fazę grupową jako tabelę (drużyny, punkty, wygrane, przegrane, różnica bramek) i drabinkę pucharową jako zagnieżdżoną strukturę bracket. Drabinka pucharowa zaimplementowana jest przez CSS jako struktura drzewiasta - na desktopie biegnie poziomo, na urządzeniach mobilnych pionowo.

Dla większych turniejów z integracją livestreamu rozszerzenie można rozszerzyć przez AJAX: wyniki wprowadzane są w backendzie, a frontend aktualizuje stan meczu przez polling co 30 sekund, bez przeładowywania strony.

## Częste problemy dotyczą logiki trybu turniejowego i prezentacji drabinki

Największym problemem jest różnorodność trybów turniejowych. Prosty turniej pucharowy z 8 drużynami jest trywialny. Ale turniej w systemie szwajcarskim z 40 drużynami, format double elimination czy liga z barażami o awans i spadek wymagają złożonej logiki, której nie odwzoruje każde rozszerzenie. Przed wyborem rozszerzenia tryb turniejowy musi być jasno zdefiniowany. Gdy rozszerzenie nie wspiera oczekiwanego trybu, konieczne jest własne rozszerzenie.

Drugi problem: prezentacja drabinki na urządzeniach mobilnych. Drabinka pucharowa z 16 drużynami ma cztery rundy (1/8 do finału). Ta struktura drzewiasta nie mieści się na ekranie szerokim na 375 pikseli. Przewijanie poziome lub uproszczony widok listy są pragmatycznymi rozwiązaniami.

Trzeci temat: zdjęcia drużyn i herby. Kluby chcą widzieć logo obok nazwy drużyny w tabeli. Rozszerzenie musi oferować integrację FAL dla obrazów drużyn, w przeciwnym razie redaktorzy muszą wpisywać ścieżki obrazów ręcznie.

## Rozszerzenia Tournament są produktami niszowymi z ograniczoną społecznością

Rozszerzenia turniejowe dla TYPO3 to rozwiązania niszowe z małą społecznością. Pod TYPO3 v12 aktualne wersje działają stabilnie. Dla v13 dalszy rozwój nie jest gwarantowany, ponieważ nakład utrzymania dla maintainera niszowego rozszerzenia jest ekonomicznie trudny do uzasadnienia. Kluby planujące długoterminowo powinny ocenić, czy specjalistyczna platforma turniejowa (Challengermode, Toornament) z integracją API z witryną TYPO3 nie jest bardziej zrównoważona niż monolityczne rozszerzenie. Gosign doradza klubom i organizacjom przy wyborze między rozszerzeniem społecznościowym, custom-rozwojem a integracją SaaS.

--- tt_address TYPO3 - Zarządzanie adresami | Gosign ---
> Klasyk zarządzania adresami w TYPO3. Zarządzanie i wyświetlanie kontaktów, pracowników, lokalizacji.

## Katalogi pracowników, wyszukiwarki oddziałów i listy kontaktów w TYPO3 od 20 lat działają przez tt_address

Każda firma z wieloma lokalizacjami, działami lub osobami kontaktowymi potrzebuje strukturalnej prezentacji na stronie. Kto jest odpowiedzialny za jaki region? Gdzie jest najbliższy oddział? Jakie dane kontaktowe ma dział kadr? Ręczne zarządzanie takimi informacjami jako bloki tekstowe w CMS prowadzi do niespójności: różne formaty, zapomniane aktualizacje, brak możliwości filtrowania.

tt_address to najstarsza i najbardziej rozpowszechniona rozszerzenie zarządzania adresami dla TYPO3. W użyciu od TYPO3 v4 (2006), ponad 50 000 aktywnych instalacji (TER, 2026), aktywnie utrzymywane przez społeczność TYPO3. Rozszerzenie przechowuje kontakty, osoby i lokalizacje jako strukturalne rekordy i wyświetla je przez szablony Fluid jako listy, mapy lub strony szczegółowe.

## Typowe scenariusze zastosowań

**Katalogi pracowników dla stron firmowych.** Firma z 50 do 500 pracownikami chce pokazać na stronie, kto jest odpowiedzialny za jaki temat. tt_address przechowuje per osobę: imię, tytuł, dział, zdjęcie, e-mail, telefon, lokalizację. Wyświetlanie odbywa się jako filtrowalna lista (po dziale, lokalizacji) lub strona szczegółowa z pobieraniem vCard.

**Wyszukiwarki oddziałów i przeglądy lokalizacji.** Firmy z 10 do 500 lokalizacjami (filie, oddziały, partnerzy) wykorzystują tt_address jako bazę danych dla wyszukiwarki lokalizacji. Każda lokalizacja ma adres, współrzędne geograficzne, godziny otwarcia i dane kontaktowe. Integracja map odbywa się przez oddzielne rozszerzenie (maps2 lub Leaflet), które odczytuje współrzędne z tt_address.

**Listy kontaktów dla urzędów i stowarzyszeń.** Gminy, izby i stowarzyszenia wymieniają osoby kontaktowe według kompetencji. tt_address odwzorowuje strukturę organizacyjną przez kategorie lub SysFolder. Wyświetlanie można filtrować po kategoriach i sortować alfabetycznie lub według stanowiska.

## Architektura techniczna

tt_address przechowuje rekordy w tabeli `tt_address`. Pola obejmują: zwrot grzecznościowy, tytuł, imię, nazwisko, firmę, dział, ulicę, kod pocztowy, miasto, kraj, telefon, fax, komórkę, e-mail, stronę www, współrzędne geograficzne (Latitude, Longitude), obraz (referencja FAL), kategorie i pole opisu (RichText).

Wyświetlanie odbywa się przez plugin Extbase z akcjami List i Detail. Szablony Fluid są w pełni konfigurowalne. Standardowo tt_address dostarcza cztery layouty: prosta lista, lista grupowana (po kategorii lub miejscu), widok szczegółowy i pobieranie vCard (RFC 6350).

tt_address integruje się z innymi rozszerzeniami: maps2 i ext:leaflet do integracji map, direct_mail i mail do wysyłki newsletterów (tt_address jako lista odbiorców), ke_search i indexed_search do pełnotekstowego wyszukiwania danych adresowych.

## Częste problemy i rozwiązania

**Obrazy nie są wyświetlane.** Od TYPO3 v10 tt_address używa FAL (File Abstraction Layer) dla obrazów. Starsze instalacje przechowywały obrazy jako nazwy plików w polu (nie jako referencje FAL). Rozwiązanie: uruchomienie skryptu aktualizacji tt_address, który konwertuje stare odwołania do obrazów na referencje FAL.

**Brak współrzędnych geograficznych dla wyszukiwarki lokalizacji.** Adresy bez Latitude/Longitude nie pojawiają się na mapie. Ręczne wprowadzanie dla 200 lokalizacji jest niepraktyczne. Rozwiązanie: automatyzacja geocodingu przez zadanie Scheduler. Gosign stosuje cronjob korzystający z API Nominatim (OpenStreetMap, bezpłatny, zgodny z RODO), który uzupełnia brakujące współrzędne.

**Import danych z zewnętrznych systemów.** Działy HR pielęgnują dane pracowników w SAP, Personio lub innym systemie HR. Dane mają automatycznie pojawiać się na stronie. Rozwiązanie: budowa mechanizmu synchronizacji importującego CSV lub JSON z systemu HR i tworzącego lub aktualizującego rekordy tt_address.

## Migracja i kompatybilność wersji

tt_address aktywnie wspiera TYPO3 v11, v12 i v13. Rozszerzenie jest współutrzymywane przez Georga Ringera (twórcę rozszerzenia News) i podąża za jasnym cyklem wydań. Aktualizacje na nowe główne wersje TYPO3 pojawiają się z reguły w ciągu kilku tygodni po wydaniu LTS.

Dla firm niemających istniejącego zarządzania adresami, Gosign zaleca tt_address jako punkt wyjścia dla wszystkich scenariuszy poniżej 5000 rekordów. Rozszerzenie jest stabilne, dobrze udokumentowane, ma dużą społeczność i integruje się bezszwowo z innymi rozszerzeniami TYPO3. Dla większych wolumenów danych lub złożonych wymagań synchronizacji Gosign buduje niestandardową warstwę synchronizacyjną, która wykorzystuje tt_address do wyświetlania frontendowego, ale pozostawia suwerenność danych przy systemie źródłowym.

Pierwsza konfiguracja projektu tt_address (instalacja, dostosowanie szablonu, struktura kategorii, konfiguracja geocodingu) to 2 do 4 dni deweloperskich. Wyszukiwarka oddziałów z integracją map i wyszukiwaniem po kodzie pocztowym to 5 do 8 dni, włącznie z integracją Leaflet lub maps2.

--- typo3db_legacy TYPO3 - Migracja DB | Gosign ---
> Warstwa kompatybilności dla starego TYPO3 Database API (`$GLOBALS['TYPO3_DB']`). Pomost dla rozszerzeń, które nie zostały jeszcze zmigrowane na Doctrine DBAL.

## Dlaczego typo3db_legacy od TYPO3 v12 stanowi ryzyko bezpieczeństwa dla każdego rozszerzenia

TYPO3 w wersji 8 całkowicie przestawił abstrakcję bazy danych na Doctrine DBAL. Stare API przez `$GLOBALS['TYPO3_DB']` zostało od v9 oznaczone jako deprecated i od v12 jest całkowicie usunięte. Mimo to w praktyce tysiące instalacji TYPO3 działają z rozszerzeniami nadal opartymi na legacy API. typo3db_legacy utrzymuje te rozszerzenia przy życiu, odtwarzając stare API jako warstwę kompatybilności.

Problem: rozszerzenie nie jest rozwiązaniem trwałym, lecz mostem. Każda kolejna wersja TYPO3 zwiększa ryzyko, że sama warstwa kompatybilności ulegnie awarii. Kto dziś jeszcze korzysta z typo3db_legacy, stoi przed jasną decyzją - migrować albo ryzykować aktualizację do v13.

## Typowe scenariusze zastosowań

**Własne rozszerzenia z bezpośrednimi dostępami do bazy danych.** Wiele agencji pisało między 2012 a 2018 rozszerzenia bezpośrednio wywołujące `$GLOBALS['TYPO3_DB']->exec_SELECTquery()`. W typowej instalacji średniej firmy znajduje się od 3 do 8 takich rozszerzeń. Bez typo3db_legacy po aktualizacji do v10+ natychmiast wypadłyby z Fatal Errors.

**Rozszerzenia firm trzecich bez aktywnego maintainera.** Rozszerzenia takie jak starsze wersje dodatków tt_address, katalogi branżowe czy specjalistyczne narzędzia importowe były często utrzymywane przez solo-deweloperów. Jeśli maintainer nie jest już aktywny, typo3db_legacy pozostaje jedyną opcją zachowania funkcjonalności przy aktualizacji.

**Stopniowa migracja dużych instalacji.** Firmy z ponad 50 rozszerzeniami nie mogą migrować wszystkiego jednocześnie. typo3db_legacy pozwala na stopniowe podejście: najpierw aktualizacja Core, potem rozszerzenie po rozszerzeniu na Doctrine DBAL.

## Architektura techniczna

typo3db_legacy rejestruje się jako rozszerzenie TYPO3 i udostępnia klasę `DatabaseConnection` implementującą te same metody co stara klasa z TYPO3 Core: `exec_SELECTquery()`, `exec_INSERTquery()`, `exec_UPDATEquery()`, `exec_DELETEquery()` i warianty Prepared Statement.

Wewnętrznie warstwa przekierowuje wszystkie wywołania do Doctrine DBAL. To działa niezawodnie dla standardowych zapytań. Problematyczne staje się przy bezpośrednich funkcjach MySQL w zapytaniach, Prepared Statements w starym formacie i obsłudze transakcji przez stare API. Ponadto każde zapytanie przechodzi przez dodatkową warstwę abstrakcji z 5-15% overhead wydajnościowym.

Rozszerzenie zostało zaprojektowane jako tymczasowy środek. Kod celowo nie zawiera optymalizacji, które uczyniłyby je trwalszym. Brak cachowania zapytań na warstwie kompatybilności, brak integracji connection-pooling i brak wsparcia dla zaawansowanych funkcji Doctrine DBAL.

## Częste problemy i rozwiązania

**Rozszerzenie nie działa mimo typo3db_legacy po aktualizacji.** Przyczyną jest zazwyczaj to, że rozszerzenie nie tylko używa `$GLOBALS['TYPO3_DB']`, ale też innych usuniętych API. Rozwiązanie wymaga kompletnej analizy kodu rozszerzenia, nie tylko wywołań bazy danych. Skan TYPO3 Extension Scannerem dostarcza priorytetyzowaną listę wszystkich miejsc.

**Zapytania zwracają inne wyniki niż przed aktualizacją.** Doctrine DBAL traktuje typy ściślej niż stare API oparte na `mysqli`. `WHERE uid = '5'` (String zamiast Integer) może w skrajnych przypadkach prowadzić do niespodziewanego zachowania. Rozwiązanie: sprawdzenie wszystkich zapytań pod kątem prawidłowych typów PHP i jawne ustawienie rzutowań.

**Spadek wydajności po instalacji.** Instalacje z ponad 100 000 rekordami i częstymi zapytaniami odczuwają overhead podwójnej abstrakcji. Tu pomaga tylko kompletna migracja na Doctrine DBAL z QueryBuilder, która czyni warstwę zbędną.

## Migracja i kompatybilność wersji

typo3db_legacy było oficjalnym elementem TYPO3 Core do wersji 9.5 LTS. Dla TYPO3 v10 i v11 istniało jako oddzielny pakiet Composer. Dla TYPO3 v12 LTS nie ma już oficjalnie wspieranego wydania. Dla TYPO3 v13 nie jest planowana żadna warstwa kompatybilności.

Zalecana ścieżka migracji: każde miejsce `exec_SELECTquery()` jest przepisywane na Doctrine DBAL QueryBuilder. Typowe rozszerzenie z 10 do 20 wywołaniami zapytań daje się zmigrować w 4 do 8 godzin. Gosign korzysta przy tym z automatycznej analizy kodu identyfikującej wszystkie wywołania legacy API i proponującej kod migracyjny. Przy złożonych rozszerzeniach z dynamicznie budowanymi zapytaniami nakład rośnie do 2 do 3 dni per rozszerzenie.

Najczęstsze przepisania w szczegółach: `exec_SELECTquery()` zmienia się w `$queryBuilder->select()->from()->where()->executeQuery()`. `exec_INSERTquery()` zmienia się w `$connection->insert()`. Wzorzec jest konsystentny, ale każde zapytanie musi być indywidualnie sprawdzone, ponieważ stary kod często łączy stringi, które QueryBuilder oczekuje jako oddzielne parametry.

--- RODO iFrame TYPO3 - Zgoda | Gosign ---
> Osadzanie iFrame zgodne z RODO dla TYPO3: Filmy, mapy, media społecznościowe ładowane dopiero po zgodzie. Rozwiązanie dwóch kliknięć.

## Osadzanie filmów YouTube i Google Maps bez zgody to naruszenie RODO z ryzykiem skargi do UODO

Każde osadzenie iFrame zewnętrznej usługi przekazuje adres IP odwiedzającego dostawcy usługi, jeszcze zanim odwiedzający w cokolwiek kliknie. Film YouTube na stronie głównej wysyła przy załadowaniu strony IP do Google, mapa Google Maps - również do Google, widżet Facebook do Meta. Bez wcześniejszej zgody odwiedzającego jest to naruszenie RODO (art. 6 ust. 1 lit. a). Po wyroku TSUE Planet49 (2019) i wytycznych UODO sytuacja prawna jest jasna: technicznie niekonieczne przekazywanie danych podmiotom trzecim wymaga świadomej zgody. udg_gdpr_iframe implementuje rozwiązanie dwóch kliknięć dla TYPO3: iFrame'y ładują się dopiero po wyraźnym kliknięciu odwiedzającego. Placeholder pokazuje, jaka usługa zostanie załadowana i jakie dane są przekazywane.

UODO konsekwentnie nakłada kary za pasywne osadzanie iFrame'ów podmiotów trzecich bez wyraźnej, świadomej zgody.

## Typowe scenariusze dotyczą YouTube, Google Maps i osadzeń mediów społecznościowych

Najczęstszym scenariuszem są filmy YouTube na witrynach firmowych. Firma pokazuje na stronie kariery film rekrutacyjny. Bez rozwiązania consentu strona przy każdym wywołaniu wysyła IP odwiedzającego do Google. Z udg_gdpr_iframe odwiedzający zamiast filmu widzi placeholder z miniaturą, informacją "Ten film dostarcza YouTube. Przy odtwarzaniu dane będą przekazywane do Google" i przyciskiem "Załaduj film". Dopiero po kliknięciu iFrame jest ładowany i film odtwarzany.

Drugim scenariuszem jest mapa Google Maps na stronie kontaktowej. Mapka dojazdowa to standardowy element, ale ryzyko z punktu widzenia ochrony danych. udg_gdpr_iframe pokazuje zamiast tego statyczny obraz mapy (zrzut ekranu) jako placeholder. Odwiedzający potrzebujący interaktywnej mapy klikają "Załaduj mapę" i tym samym akceptują przekazywanie danych do Google.

Trzeci scenariusz: osadzenia z mediów społecznościowych. Artykuł blogowy cytuje tweeta lub post z Instagrama. Również te osadzenia ładują zewnętrzne zasoby i przekazują dane użytkowników. udg_gdpr_iframe blokuje osadzenie i pokazuje placeholder nazywający usługę i prezentujący tekst zapowiedzi.

## Architektura techniczna zastępuje iFrame'y placeholderami z loaderem JavaScript

Rozszerzenie rejestruje element treści lub modyfikuje istniejące elementy treści TYPO3 zawierające iFrame'y. W HTML atrybut src iFrame'u zostaje zastąpiony atrybutem data-src. Przeglądarka nie ładuje iFrame'u, ponieważ brakuje atrybutu src. Zamiast tego placeholder div pokazuje nazwę usługi, informację o ochronie danych i przycisk aktywacyjny.

Po kliknięciu przycisku snippet JavaScript kopiuje data-src do atrybutu src i przeglądarka ładuje iFrame. Opcjonalnie odwiedzający może aktywować checkbox "Zawsze ładuj", który zapisze decyzję w LocalStorage. Przy późniejszych odwiedzinach iFrame będzie ładowany bez ponownej interakcji.

Prezentacja placeholdera jest konfigurowalna przez szablon Fluid: miniatura (np. thumbnail YouTube), tekst, etykieta przycisku, link do polityki prywatności. Dla filmów YouTube rozszerzenie potrafi automatycznie pobierać miniaturę z API YouTube (bez iFrame, tylko jeden request o obraz).

Integracja z istniejącymi platformami zarządzania zgodami (CookieBot, OneTrust, Borlabs Cookie) jest możliwa przez API JavaScript: gdy odwiedzający w banerze cookie wyraził zgodę na kategorię "Marketing", wszystkie iFrame'y marketingowe są automatycznie ładowane bez dwóch kliknięć.

## Częste problemy dotyczą wykrycia wszystkich iFrame'ów i integracji z CMP

Największym problemem jest pełne wykrycie wszystkich iFrame'ów na witrynie. Redaktorzy osadzają iFrame'y nie tylko przez elementy treści, lecz także bezpośrednio w RTE (Rich Text Editor), w szablonach Fluid i w TypoScript. Rozszerzenie musi pokrywać wszystkie źródła. Częsty błąd: elementy treści są chronione, ale iFrame YouTube w szablonie stopki nadal ładuje się bez zgody. Rozwiązanie: po instalacji wykonać pełny crawl witryny i zidentyfikować wszystkie źródła iFrame.

Drugi problem: integracja z zarządzaniem zgodami. Gdy witryna już wykorzystuje Borlabs Cookie lub CookieBot, mogą wystąpić konflikty: CMP blokuje iFrame własnym mechanizmem, a udg_gdpr_iframe blokuje go ponownie. Rezultat: podwójne placeholdery lub iFrame, który mimo zgody w CMP się nie ładuje. Rozwiązanie: korzystać z udg_gdpr_iframe lub CMP do blokowania iFrame'ów, ale nie z obu naraz.

Trzeci temat: dostępność. Placeholder musi być dostępny dla czytników ekranu: przycisk wymaga aria-label, informacja o ochronie danych musi być tekstem (nie obrazem), a nawigacja klawiaturą musi działać.

## TYPO3 v12 jest wspierany, rozszerzenie pozostaje istotne dopóki istnieją iFrame'y

udg_gdpr_iframe rozwiązuje problem, który z każdą nową interpretacją RODO staje się bardziej istotny. Rozszerzenie działa stabilnie pod TYPO3 v12. Dla v13 konieczna jest aktualizacja rejestracji elementów treści i loadera JavaScript. Ponieważ podstawowa funkcjonalność (zastąpienie src iFrame'u przez data-src) jest technicznie trywialna, rozszerzenie można w razie potrzeby przenieść na każdą wersję TYPO3 niewielkim nakładem pracy. Gosign w audytach ochrony danych sprawdza pełne pokrycie iFrame'ów i rekomenduje rozwiązanie pasujące do istniejącego zarządzania zgodami na witrynie.

--- Ankieta TYPO3 - Plugin ankietowy | Gosign ---
> Proste rozszerzenie ankiet/poll dla TYPO3. Quick Polls bezpośrednio w CMS. Dla bardziej złożonych ankiet: integracja LimeSurvey.

## Szybkie sondaże opinii bezpośrednio na stronie generują zaangażowanie, którego nie zapewniają pola komentarzy

Artykuły blogowe z funkcją komentarzy generują w praktyce mniej niż 1 procent interakcji. Ankieta ("Czy się zgadzasz?", "Którą opcję preferujesz?") tworzy 5 do 15 procent, ponieważ próg jest niższy: jedno kliknięcie zamiast wpisywania tekstu. Polskie narzędzie ankietowe TYPO3 wprowadza proste sondaże bezpośrednio do CMS-u. Redaktorzy tworzą ankiety w backendzie (pytanie, opcje odpowiedzi, wybór wielokrotny tak/nie, prezentacja wyników), osadzają je jako element treści i widzą wyniki w czasie rzeczywistym. Dla szybkich obrazów opinii to wystarczające. Dla badań naukowych lub złożonych ankiet zalecamy integrację LimeSurvey, oferującą znacznie bogatsze typy pytań i analizy.

## Typowe scenariusze obejmują sondaże czytelnicze, feedback z wydarzeń i głosowania

Najczęstszym scenariuszem jest sondaż czytelniczy na stronie news lub blog. Magazyn branżowy pyta: "Której funkcji najbardziej oczekujesz w TYPO3 v14?" z pięcioma opcjami odpowiedzi. Czytelnicy klikają swój wybór i od razu widzą rozkład procentowy. Generuje to zaangażowanie, dostarcza redakcji obrazu nastrojów i daje artykułowi interaktywny komponent zwiększający czas spędzony na stronie.

Drugim scenariuszem jest feedback po wydarzeniu. Po konferencji lub webinarium uczestnicy widzą na witrynie TYPO3 ankietę: "Jak ocenia Pan/Pani wydarzenie?" (bardzo dobrze / dobrze / dostatecznie / źle). To nie zastąpi szczegółowego kwestionariusza zwrotnego, ale jest szybkim pomiarem satysfakcji wypełnianym przez znacznie więcej uczestników niż mailowa ankieta.

Trzeci scenariusz: głosowania w stowarzyszeniach i gremiach. Stowarzyszenie branżowe poddaje pod głosowanie nowy projekt logo. Trzy projekty do wyboru, każdy członek ma jeden głos. W połączeniu z fe_login mamy pewność, że głosują tylko zarejestrowani członkowie i każdy oddaje głos tylko raz.

## Architektura techniczna przechowuje ankiety jako rekordy Extbase z licznikiem wyników

Narzędzie ankietowe definiuje dwa modele Extbase: Poll (pytanie, opis, data początku/końca, flaga wyboru wielokrotnego) i Option (tekst odpowiedzi, liczba głosów). Poll zawiera kilka opcji. Głosy zapisywane są jako licznik (inkrementacja Integer) w Option, a nie jako pojedyncze rekordy na uczestnika. Utrzymuje to bazę szczupłą, a wydajność wysoką, ale oznacza również, że indywidualnych odpowiedzi nie da się prześledzić.

We frontendzie rozszerzenie renderuje formularz z radio buttonami (wybór pojedynczy) lub checkboxami (wybór wielokrotny). Po wysłaniu licznik wybranej opcji jest inkrementowany, a prezentacja wyników wyświetlana jako poziomy wykres słupkowy z wartościami procentowymi.

Przeciwko wielokrotnemu głosowaniu rozszerzenie stosuje wykrywanie duplikatów oparte na cookies: po udziale ustawiany jest cookie blokujący ponowne oddanie głosu. Nie jest to bezpieczna ochrona (cookies można usunąć), ale dla sondaży opinii bez wymagań formalnych wystarczająca. Dla wiążących głosowań konieczne jest połączenie z fe_login, umożliwiające weryfikację względem tabeli fe_users. Z perspektywy RODO oznaczać to może też konieczność opracowania klauzuli informacyjnej dla uczestników.

## Częste problemy dotyczą zabezpieczenia przed manipulacją i braku funkcji analitycznych

Największym problemem otwartych sondaży jest ich podatność na manipulację. Bez logowania odwiedzający może usunąć cookie i zagłosować ponownie. W trybie incognito blokada cookie w ogóle nie działa. Kto potrzebuje wiarygodnych wyników, musi powiązać ankietę z fe_login. Dla niskoprogowych obrazów opinii ("Co Cię interesuje?") rozwiązanie cookie jest natomiast akceptowalne.

Drugi problem: brak funkcji analitycznych. Narzędzie ankietowe zapisuje tylko sumy zbiorcze, brak przebiegów czasowych, brak segmentacji według grup użytkowników, brak krzyżówek. Gdy analiza ma wykraczać poza "63% wybrało opcję A", LimeSurvey lub dedykowane narzędzie ankietowe są lepszym wyborem.

Trzeci temat: dostosowanie designu. Dostarczone szablony są funkcjonalne, ale nie zaprojektowane pod nowoczesne wymagania UI. Kto chce prezentować ankiety w uporządkowanym designie z animacjami (paski wypełniają się, procenty odliczają), musi nadpisać szablony Fluid i dodać własne CSS/JS.

## TYPO3 v12 jest wspierany, dla bardziej złożonych ankiet LimeSurvey jest lepszym wyborem

Narzędzie ankietowe działa stabilnie pod TYPO3 v12. Dla v13 konieczna jest aktualizacja rejestracji pluginu. Ponieważ rozszerzenie jest technicznie szczupłe (dwa modele Extbase, jeden kontroler, jeden szablon Fluid), migracja jest nieskomplikowana. Gosign rekomenduje rozszerzenie dla prostych sondaży z trzema do pięciu opcjami odpowiedzi. Gdy potrzebne są typy pytań takie jak skale Likerta, otwarte pola tekstowe, pytania macierzowe lub logika warunkowa, integracja LimeSurvey jest profesjonalniejszym rozwiązaniem.

--- VHS Development TYPO3 | Gosign ---
> Wersja deweloperska kolekcji ViewHelper VHS. Testowanie najnowszych funkcji przed oficjalnym wydaniem. Dla programistów TYPO3 pracujących na bleeding edge.

## Dlaczego wersja deweloperska VHS dla agencji TYPO3 to miecz obosieczny

VHS (ViewHelpers Supplementary) z ponad 300 ViewHelperami to najobszerniejsze rozszerzenie Fluid dla TYPO3. Wersja deweloperska dostarcza nowe ViewHelper i poprawki błędów, zanim trafią do stabilnego wydania. Dla programistów pracujących nad aktualnymi projektami i czekających na konkretną poprawkę lub nową funkcję, to zaleta. Dla witryn produkcyjnych to ryzyko: wersje deweloperskie nie są w pełni przetestowane i mogą się niekompatybilnie zmieniać między commitami.

Decyzja o zastosowaniu VHS Development w projekcie nie jest techniczna, lecz organizacyjna: czy zespół ma zdolność, by terminowo testować zmiany w bibliotece i reagować, gdy coś się zepsuje?

## Typowe scenariusze zastosowań

**Dostęp do poprawek przed następnym stabilnym wydaniem.** Projekt korzysta z ViewHelper VHS `v:format.trim`, który w stabilnej wersji ma błąd. Poprawka istnieje już w gałęzi deweloperskiej, ale następne stabilne wydanie jest planowane dopiero za 4 tygodnie. Zespół tymczasowo przechodzi na VHS Development i wraca po stabilnym wydaniu.

**Ewaluacja nowych ViewHelper dla projektu relaunch.** Relaunch TYPO3 zaczyna się za 3 miesiące. Zespół deweloperski ocenia, czy nowe ViewHelper VHS mogą uprościć kod szablonów. Wersja deweloperska jest instalowana w lokalnym środowisku, testowana, a wyniki wpływają na decyzje architektoniczne.

**Wkład w rozwój VHS.** Agencje wnoszące własne ViewHelper do VHS lub zgłaszające błędy pracują z wersją deweloperską, by testować swoje poprawki wobec aktualnego stanu kodu. Bez wersji deweloperskiej sensowne contributing nie jest możliwe.

## Architektura techniczna

VHS Development to nie oddzielne rozszerzenie, lecz aktualny stan deweloperski repozytorium VHS na GitHub (FluidTYPO3/vhs). Instalacja odbywa się przez Composer z `dev-main` lub konkretną gałęzią. Ustawienie `minimum-stability` w `composer.json` musi być na `dev`, co wpływa na wszystkie pakiety.

VHS obejmuje ponad 300 ViewHelper w obszarach: Content (renderowanie elementów treści, dostęp FAL), Format (manipulacja stringami, daty, JSON), Iterator (operacje na tablicach, sortowanie, filtrowanie), Page (nawigacja drzewem stron, breadcrumb), Media (manipulacja obrazami, osadzanie wideo) i Security (sprawdzanie dostępu, status logowania).

Wersja deweloperska może zawierać ViewHelper, których API jeszcze się zmienia. Między dwoma stabilnymi wydaniami w gałęzi deweloperskiej zmienia się sygnatura 5 do 15 ViewHelper.

## Częste problemy i rozwiązania

**Aktualizacja Composer łamie istniejące szablony.** `composer update` pobiera najnowszą wersję deweloperską, w której parametr ViewHelper został przemianowany. Rozwiązanie: konsekwentne commitowanie pliku Composer-Lock i instalacja VHS Development ze stałą referencją commitu: `composer require fluidtypo3/vhs:dev-main#abc1234`.

**minimum-stability dev wpływa na inne pakiety.** Rozwiązanie: utrzymanie `"minimum-stability": "stable"` i jawne zdefiniowanie VHS Development jako wyjątku: `"fluidtypo3/vhs": "dev-main as 6.99.0"`. Wzorzec aliasu pozwala na instalację bez globalnej zmiany stabilności.

**Pipeline CI/CD nie udaje się z wersją deweloperską.** Automatyczne testy i wdrożenia mogą nie udać się, gdy GitHub jest tymczasowo nieosiągalny lub gałąź została force-pushowana. Rozwiązanie: użycie lokalnego mirrora Composer (Satis) dla pipeline CI/CD.

## Migracja i kompatybilność wersji

Stabilne wydania VHS podążają za cyklami TYPO3 LTS: VHS 6.x wspiera TYPO3 v11, VHS 7.x wspiera TYPO3 v12. Gałąź deweloperska celuje w następną główną wersję.

Przejście z VHS Development z powrotem na Stable jest z reguły bezproblemowe, o ile nie są używane ViewHelper istniejące tylko w wersji deweloperskiej. Gosign zaleca przed przejściem na Stable sprawdzenie wszystkich używanych ViewHelper VHS wobec dokumentacji Stable.

Gosign zaleca następującą strategię: na środowiskach deweloperskich i w gałęziach funkcji korzystać z wersji deweloperskiej do ewaluacji nowych ViewHelper. Na staging i produkcji wyłącznie stabilne wydania. Jeśli krytyczna poprawka jest dostępna tylko w Development - przypiąć konkretny commit jako referencję Composer i zostawić w kodzie komentarz TODO widoczny przy następnym sprawdzeniu stabilnego wydania.

--- VHS TYPO3 - Fluid ViewHelper | Gosign ---
> Kolekcja ViewHelper dla TYPO3 Fluid Templates od FluidTYPO3. Setki dodatkowych ViewHelper dla Media, Content, Page, Iterator, Math, String.

## EXT:vhs to niewidzialna skrzynka narzędziowa każdego profesjonalnego szablonu TYPO3

Kto pracuje w TYPO3 z Fluid i wychodzi poza zwykłe wyświetlanie treści, prędzej czy później trafia przy EXT:vhs. Rozszerzenie z ekosystemu FluidTYPO3 dostarcza kilkaset dodatkowych ViewHelperów dla zadań, których core świadomie nie pokrywa: manipulacja obrazami, logika iteratorów, operacje matematyczne, obsługa stringów, zapytania treści, nawigacja stron. Dla deweloperów frontendowych w agencjach i zespołach inhouse vhs to nie opcjonalny nice-to-have, tylko baza, na której powstają złożone struktury szablonów bez objazdów PHP.

Grupą docelową są zazwyczaj zespoły, które pielęgnują rozbudowane Site Packages: wydawnictwa z heterogenicznymi typami treści, uczelnie z zagnieżdżonymi nawigacjami, koncerny z wielojęzycznymi portalami. Bez vhs co drugie specjalne wymaganie musiałoby być wyniesione do własnego ViewHelpera lub do TypoScript. Z vhs logika pozostaje tam, gdzie powinna być: w szablonie.

## Typowe scenariusze zastosowania

Pierwszym scenariuszem jest zapytanie o treści z obcych drzew stron. Portal kliencki producenta maszyn z 3000 stron produktów potrzebuje na każdej stronie bloku teaserowego z aktualnymi newsami z oddzielnej gałęzi rootline newsów. ViewHelper `v:content.get` pobiera treści z dowolnych stron i umożliwia tym samym modułowe kompozycje stron, bez konieczności budowania obiektów TypoScript-CONTENT.

Drugim scenariuszem jest przetwarzanie iteracyjne. Wydawnictwo pielęgnuje artykuły z kategoriami, tagami i autorami jako ObjectStorage. Samym Fluid filtrowanie, grupowanie i sortowanie przez zagnieżdżone obiekty jest uciążliwe. Z `v:iterator.filter`, `v:iterator.sort` lub `v:iterator.groupBy` takie operacje można bezpośrednio czytać i utrzymywać w szablonie.

Trzecim scenariuszem jest przetwarzanie obrazów. Sklep e-commerce z 500 produktami na sezon potrzebuje responsywnych wariantów obrazów z tagiem picture, fallbackiem WebP i placeholderem LQIP. Z ViewHelperami media vhs ten blok jest raz definiowany w partialu, a następnie wszędzie ponownie używany.

Czwartym scenariuszem jest matematyczne przygotowanie wskaźników na stronach raportowych. Kto chce wyświetlać ceny z sumami częściowymi, udziałami procentowymi lub średnimi ważonymi, sięga po `v:math.sum`, `v:math.percentage` lub `v:math.division`, bez konieczności budowania dla każdej kalkulacji własnego kontrolera.

## Architektura techniczna

EXT:vhs to czysta biblioteka-rozszerzenie bez modułów backendowych i bez tabel bazy danych. Rejestruje przestrzenie nazw w Fluid (`{namespace v=FluidTYPO3\Vhs\ViewHelpers}`) i udostępnia tym samym ViewHelpery przez prefiks `v:`. Rozszerzenie nie ma twardych zależności od reszty stosu FluidTYPO3 (Flux, Fluidcontent), nawet gdy jest często używane razem z nimi.

Instalacja odbywa się przez Composer z `fluidtypo3/vhs`. W Site Package vhs jest zazwyczaj prowadzone jako zależność własnego rozszerzenia providera, dzięki czemu rejestracja przestrzeni nazw odbywa się w szablonie layoutu lub globalnie przez tablicę konfiguracyjną TypoScript. Kto musi deklarować przestrzenie nazw w każdym szablonie pojedynczo, zazwyczaj pominął ścieżkę rejestracji globalnej.

Dla wydajności istotne jest, że vhs nie cache'uje własnych zapytań bazodanowych. Kto używa `v:content.get` lub `v:page.menu` bez cache'owania Fluid, w najgorszym razie generuje to samo zapytanie przy każdym wywołaniu strony. Rozwiązanie leży w porządnie skonfigurowanym cache'owaniu Fluid przez page- i content-cache oraz świadomym używaniu mechanizmu CacheStatic w core TYPO3.

Pakiet rozszerzenia jest zbudowany modularnie. Pojedyncze grupy ViewHelperów (Asset, Condition, Format, Iterator, Math, Media, Page, Resource, System, Variable) mogą być celowo używane, bez konieczności wprowadzania całego stosu do projektu. W praktyce jednak cała kolekcja jest instalowana, bo zależności między grupami trudno enkapsulować, a footprint rozszerzenia w całości pozostaje akceptowalny.

## Częste problemy i rozwiązania

Pierwszym problemem jest notoryczna kolizja przestrzeni nazw. Kto używa EXT:vhs równolegle do własnych ViewHelperów pod prefiksem `v:`, otrzymuje nieprzewidywalne nakładania się. Rozwiązaniem jest konsekwentne rejestrowanie własnych ViewHelperów pod własnym prefiksem (np. `my:`) i przestawianie wywołań vhs na ViewHelpery core, gdzie core TYPO3 oferuje już alternatywę (`f:format.padding` zastępuje `v:format.padding`).

Drugim problemem jest kompatybilność wersji z nowszymi wersjami Fluid. W TYPO3 v12 i v13 Fluid był wielokrotnie przebudowany, co przy niektórych ViewHelperach vhs prowadzi do deprecation-warnings lub błędów typu. Rozwiązaniem jest audyt używanych ViewHelperów wobec Compatibility-Matrix w repozytorium GitHub i selektywne zastępowanie alternatywami core lub własnymi, smukłymi implementacjami.

Trzecim problemem jest wydajność pod obciążeniem. `v:iterator.filter` i `v:iterator.sort` są wygodne, ale wymagające obliczeniowo przy dużych zbiorach danych. Kto renderuje szablon z 10 000 produktów na stronę, powinien przenieść logikę filtra do repozytorium i przekazywać szablonowi tylko już przefiltrowany wynik.

Czwartym, często pomijanym problemem są nieudokumentowane zmiany zachowań między wersjami vhs. ViewHelper, który w wersji 6.x zwracał string, w wersji 7.x nagle dostarcza tablicę lub odwrotnie. Rozwiązaniem jest zafiksowanie wersji vhs w composer-lock-file i przy każdym upgrade staranne sprawdzenie changelog wobec własnego zasobu szablonów, idealnie z krokiem lint w pipeline CI, który natychmiast zgłasza nieznane sygnatury ViewHelperów.

## Migracja i kompatybilność wersji

EXT:vhs jest oficjalnie zwolnione dla TYPO3 v11 i v12. Dla v13 istnieje gałąź rozwojowa, która jest aktywnie utrzymywana, ale jeszcze nie we wszystkich ViewHelperach jest gotowa do produkcji. Zespoły, które obecnie planują upgrade z v11 na v12, mogą z reguły wziąć vhs ze sobą bez większych ingerencji. Ścieżka upgrade do v13 jest dla projektów intensywnie wykorzystujących szablony punktem krytycznym: tu opłaca się porównanie kosztów i korzyści między zachowaniem vhs a stopniową przebudową na core-Fluid plus własne ViewHelpery.

Strategiczna odpowiedź zależy od skali użycia vhs. Projekty, które używają tylko garści ViewHelperów vhs, powinny zastąpić je przy następnym upgrade celowo konstruktami core lub projektowymi ViewHelperami. Projekty z setkami wywołań vhs w szablonach natomiast korzystają z dalszego prowadzenia vhs i przeprowadzania przy każdym upgrade celowego testu kompatybilności. Zastąpienie opłaca się tylko tam, gdzie dług obciąża pielęgnację bardziej niż kontrolowane dalsze prowadzenie.

Gosign towarzyszy upgrade TYPO3 z długiem vhs i decyduje wspólnie z zespołem, które ViewHelpery vhs zostają zastąpione konstruktami core, a które powstają na nowo jako smukłe projektowe ViewHelpery. W ten sposób spuścizna szablonów pozostaje utrzymywalna, bez wiązania się na kolejne lata z zewnętrznym stosem bibliotek.

--- Cache Warmup TYPO3 - Wydajność | Gosign ---
> Cache Warmup dla TYPO3: Rozgrzewanie cache stron po deployment. Integracja CI/CD. Z wykorzystaniem AI.

## Dlaczego pierwsze 5 minut po wdrożeniu TYPO3 decyduje o doświadczeniu użytkownika

Po każdym wdrożeniu cache TYPO3 jest czyszczony. To technicznie konieczne, ale ma odczuwalną konsekwencję: pierwsi odwiedzający po wdrożeniu widzą niecachowane strony. Zamiast 200 ms czasu ładowania czekają 2 do 5 sekund, przy złożonych stronach jeszcze dłużej. Przy wdrożeniu o 9:00 rano dotyczy to dokładnie odwiedzających o najwyższym prawdopodobieństwie konwersji.

warmup rozwiązuje ten problem, proaktywnie wypełniając cache, zanim pierwszy prawdziwy odwiedzający wywoła stronę. Rozszerzenie crawluje wszystkie strony witryny w tle, na podstawie sitemapy, priorytetyzując najczęściej odwiedzane strony. Po 2 do 10 minutach (w zależności od liczby stron) cały cache jest wypełniony i każdy odwiedzający dostaje pełną wydajność.

## Typowe scenariusze zastosowań

**Automatyczne rozgrzewanie cache po wdrożeniach CI/CD.** Firma wdraża swoją witrynę TYPO3 2 do 3 razy tygodniowo przez pipeline CI/CD. Po każdym wdrożeniu Deployer czyści cache. warmup jest wywoływane jako ostatni krok w pipeline i wypełnia cache, zanim wdrożenie zostanie uznane za "udane".

**Odbudowa cache po ręcznych zmianach.** Redaktorzy czasem czyszczą cały cache przez backend TYPO3, bo pojedyncza strona nie wyświetla się aktualnie. To dotyczy wtedy wszystkich stron. warmup rejestruje się jako hook na zdarzenie czyszczenia cache i automatycznie uruchamia proces rozgrzewania.

**Planowane rozgrzewanie dla okien o dużym ruchu.** Sklep online na TYPO3 ma szczyty ruchu między 10:00 a 12:00. Zadanie Scheduler uruchamia warmup codziennie o 9:30, by cache był kompletnie wypełniony na czas szczytu ruchu.

## Architektura techniczna

warmup działa jako komenda TYPO3 CLI i zadanie Scheduler. Proces rozgrzewania przebiega w trzech fazach: zbieranie URL (warmup odczytuje sitemapę strony i wyciąga wszystkie URL), priorytetyzacja (URL są sortowane według priorytetu z sitemapy, danych Matomo/Analytics lub ręcznej konfiguracji) i crawling (warmup wywołuje każdy URL przez żądanie HTTP, a TYPO3 Caching Framework zapisuje wynik renderingu).

Komenda CLI brzmi `vendor/bin/typo3 warmup:execute`. Dla integracji CI/CD jest wywoływana typowo jako Post-Deploy-Hook. warmup współpracuje z każdym backendem cache - system plików, Redis, Memcached, APCu. W połączeniu ze staticfilecache warmup generuje z góry statyczne pliki HTML serwowane bezpośrednio przez serwer webowy.

## Częste problemy i rozwiązania

**Proces warmup trwa ponad 30 minut.** Przy witrynach z ponad 5000 stronami i ustawieniu wielojęzycznym proces może trwać długo. Rozwiązanie: zwiększenie równoległości, wykluczenie nieistotnych stron (strony paginacji, archiwa tagów) i ograniczenie procesu do Top-500 stron.

**Obciążenie serwera rośnie do 100% podczas warmup.** warmup generuje prawdziwe żądania HTTP wobec własnego serwera. Bez rate-limiting może to doprowadzić obciążenie serwera do poziomu spowalniającego prawdziwych odwiedzających. Rozwiązanie: zmniejszenie równoległości i konfiguracja opóźnienia między żądaniami.

**Cachowane strony po warmup nie są aktualne.** warmup cachuje stronę taką, jaka istnieje w momencie wywołania. Jeśli redaktorzy zmieniają treść podczas procesu warmup, cache nie zgadza się z aktualnym stanem. Rozwiązanie: uruchomienie warmup dopiero po zakończeniu wszystkich zmian treści.

## Migracja i kompatybilność wersji

Rozszerzenie warmup (eliashaeussler/typo3-warming) jest dostępne dla TYPO3 v11 i v12 LTS i jest aktywnie utrzymywane. Kompatybilność z TYPO3 v13 jest oczekiwana wkrótce po wydaniu.

Kombinacja warmup + staticfilecache + Redis to stos wydajnościowy, który Gosign zaleca dla instalacji TYPO3 klasy enterprise. warmup wypełnia cache, staticfilecache serwuje statyczne pliki HTML bez PHP, Redis przechowuje zapytania bazodanowe. Razem witryny TYPO3 osiągają czasy ładowania poniżej 100 ms. Dla witryn z mniej niż 500 stronami i umiarkowanym ruchem wystarczy sam warmup. Prosty TYPO3 Page Cache dostarcza już czasy ładowania poniżej 300 ms, gdy jest prawidłowo wypełniony. warmup zapewnia, że ten poziom jest utrzymywany od pierwszej sekundy po wdrożeniu.

--- Widget pogodowy TYPO3 | Gosign ---
> Widget pogodowy dla TYPO3: Aktualne dane pogodowe z OpenWeatherMap lub innych API. Strony turystyczne, eventy plenerowe, portale regionalne.

## Witryny turystyczne, które nie pokazują aktualnej pogody, marnują jedną z najczęściej szukanych informacji

Gdy ktoś wpisuje w Google "pogoda Zakopane" lub "Mazury aktualnie", oczekuje na stronie destynacji widoku pogody. Gdy go brakuje, odwiedzający opuszcza stronę i sięga po aplikację pogodową. To zmarnowana szansa, ponieważ odwiedzający był już na właściwej stronie. weather2 integruje aktualne dane pogodowe w TYPO3: temperaturę, stan pogody, opady, wiatr, wilgotność i prognozę kilkudniową. Dane pochodzą z OpenWeatherMap lub porównywalnych API i aktualizowane są w konfigurowalnym interwale. Dla witryn turystycznych, portali wydarzeń plenerowych i regionalnych portali informacyjnych to standardowa funkcja, której odwiedzający oczekują.

## Typowe scenariusze obejmują portale destynacji, kempingi i ośrodki narciarskie

Najczęstszym scenariuszem jest portal turystyczny regionu. Stowarzyszenie turystyczne miejscowości nad Bałtykiem pokazuje na stronie głównej aktualną pogodę: 22 stopnie, słonecznie, temperatura wody 19 stopni. Obok prognoza pięciodniowa. Odwiedzający planujący wyjazd jednodniowy od razu otrzymują istotną informację i pozostają na stronie, by zarezerwować atrakcje. Temperatura wody pochodzi z osobnego endpointu API lub jest utrzymywana ręcznie.

Drugim scenariuszem są kempingi i parki wakacyjne. Kemping w Bieszczadach pokazuje na stronie rezerwacji pogodę na najbliższy tydzień. Odwiedzający wahający się między dwoma tygodniami urlopu mogą wykorzystać prognozę jako pomoc w decyzji. Dla operatora kempingu jest to argument konwersyjny: "Słońce świeci, zarezerwuj teraz".

Trzeci scenariusz: ośrodki narciarskie i wydarzenia plenerowe. Ośrodek narciarski pokazuje temperaturę na szczycie i w dolinie, wysokość pokrywy śnieżnej (z osobnego źródła) i prędkość wiatru. Festiwal plenerowy pokazuje prognozę pogody na weekend festiwalowy. W obu przypadkach widok pogody dostarcza konkretnej wartości dodanej, która zatrzymuje odwiedzających na stronie.

## Architektura techniczna pobiera dane pogodowe przez API i cache'uje je lokalnie

weather2 komunikuje się z API OpenWeatherMap (lub alternatywnie z dostawcami WeatherAPI, Visual Crossing, Meteostat). Konfiguracja w backendzie TYPO3 definiuje: klucz API, lokalizację (współrzędne lub nazwę miejscowości), jednostki (metryczne/imperialne), język i interwał aktualizacji. Standardowy interwał to 30 minut, czyli co 30 minut wysyłane jest żądanie do OpenWeatherMap, a odpowiedź cache'owana w bazie TYPO3.

Plugin frontendowy renderuje dane pogodowe przez szablony Fluid: aktualną temperaturę, ikonę pogody (słońce, chmury, deszcz), opis tekstowy, wiatr, wilgotność. Prognoza wielodniowa pokazuje minimum i maksimum dzienne dla trzech do siedmiu dni. Ikony dostarczane są jako SVG, a nie jako zewnętrzne URL-e obrazów, by nie generować dodatkowych żądań do serwerów stron trzecich.

Dla klucza API OpenWeatherMap oferuje plan bezpłatny z 1 000 wywołań dziennie, co przy 30-minutowym interwale (48 wywołań dziennie) z naddatkiem wystarcza. Dla witryn z wieloma lokalizacjami (np. stowarzyszenie turystyczne z 10 miejscowościami) potrzeba 480 wywołań dziennie - wciąż w ramach Free-Tier. Plany Pro (od ok. 160 zł miesięcznie) oferują aktualizacje godzinowe i rozszerzone dane, takie jak indeks UV i pyłki.

## Częste problemy dotyczą limitów API, cache i nieaktualnych danych

Najczęstszym problemem jest przekroczenie limitu API. Gdy cache TYPO3 nie jest poprawnie skonfigurowany, a każde żądanie strony wyzwala wywołanie API, limit Free-Tier 1 000 wywołań jest osiągany w ciągu kilku godzin. Rozszerzenie pokazuje wtedy brak danych lub błąd. Rozwiązanie: zapewnić, że dane pogodowe są zapisywane w cache TYPO3, a nie pobierane na nowo przy każdym żądaniu frontendu. Cache musi działać niezależnie od cache strony (zadanie Schedulera lub własny wpis cache).

Drugi problem: nieaktualne dane pogodowe. Gdy zadanie Schedulera nie działa (cron wyłączony, migracja serwera), witryna pokazuje dane pogodowe sprzed kilku dni lub tygodni. To gorsze niż brak widoku. Rozwiązanie: w szablonie Fluid wbudować fallback sprawdzający, czy zcache'owane dane są starsze niż dwie godziny, i przy nieaktualnych ukryć widżet, zamiast pokazywać błędne dane.

Trzeci temat: ochrona danych. Gdy dane pogodowe pobierane są przez JavaScript bezpośrednio od klienta do API, przeglądarka przekazuje IP odwiedzającego dostawcy API. To przekazywanie danych podmiotowi trzeciemu, istotne z punktu widzenia RODO. Rozwiązanie po stronie serwera (serwer TYPO3 wywołuje API, a nie przeglądarka) eliminuje ten problem i jest preferowane przez UODO.

## TYPO3 v12 jest wspierany, integracja API pozostaje stabilna niezależnie od wersji

weather2 wykorzystuje bibliotekę HTTP-Client TYPO3 dla zapytań API i szablony Fluid do renderowania. Oba elementy są stabilne w core TYPO3. Pod v12 rozszerzenie działa bez problemów. Dla v13 konieczne są minimalne dostosowania (rejestracja zadań Schedulera, konfiguracja pluginu). Ponieważ logika podstawowa (żądanie HTTP, parsowanie JSON, zapis do bazy) jest standardowa, rozszerzenie pozostaje niskonakładowe w utrzymaniu przy upgrade'ach TYPO3. Gosign konfiguruje widżety pogodowe jako część projektów witryn turystycznych i zapewnia, że cache API, fallback i ochrona danych są poprawnie zaimplementowane.

--- web2pdf TYPO3 - Strony jako PDF | Gosign ---
> web2pdf: Eksport stron TYPO3 jako PDF. Konfiguracja, wydajność i nowoczesne alternatywy (Puppeteer). Z wykorzystaniem AI.

## Dlaczego web2pdf jest niezastąpione dla witryn TYPO3 z cennikami i stronami produktowymi

Zespoły sprzedaży potrzebują drukowalnych PDF. Klienci oczekują na stronach produktowych przycisku "Zapisz jako PDF". A kupcy w przemyśle pobierają cenniki, by przekazać je wewnętrznie. web2pdf rozwiązuje dokładnie ten problem: rozszerzenie renderuje dowolne strony TYPO3 jako PDF - z prawidłowym layoutem, osadzonymi obrazami i czystą typografią. Zamiast ręcznie tworzyć każdą stronę jako PDF i aktualizować przy zmianach, web2pdf generuje PDF na żywo z aktualnej treści strony.

To oszczędza nie tylko czas redakcji, ale też zapobiega przestarzałym wersjom PDF. Gdy cena produktu zmieni się w CMS, web2pdf przy następnym pobraniu automatycznie dostarcza aktualną wersję.

## Typowe scenariusze zastosowań

**Katalogi produktowe i cenniki w B2B.** Firma z branży maszynowej zarządza 200 stronami produktowymi w TYPO3. Dział handlowy potrzebuje do każdego produktu drukowalnej karty danych. web2pdf generuje z każdej strony produktowej PDF z logo, danymi technicznymi i informacjami kontaktowymi w Corporate Design.

**Artykuły i whitepapers do pobrania.** Firmy mediowe i wydawnictwa fachowe oferują artykuły magazynowe jako PDF do pobrania. web2pdf konwertuje artykuł włącznie z obrazami i formatowaniem w PDF zoptymalizowany pod druk. Print-CSS steruje, które elementy pojawiają się w PDF (treść) a które nie (nawigacja, stopka, baner cookie).

**Oferty i konfiguracje.** Wyniki konfiguratora, podsumowania ofert czy przeglądy koszyka można eksportować przez web2pdf jako PDF. Użytkownik klika "Oferta jako PDF" i otrzymuje gotowy do druku dokument ze wszystkimi wybranymi opcjami.

## Architektura techniczna

web2pdf działa jako rozszerzenie TYPO3 z pluginem frontendowym wyświetlającym przycisk pobierania PDF na każdej stronie. Przy kliknięciu rozszerzenie wewnętrznie wywołuje aktualną stronę i przekazuje output HTML do backendu renderującego PDF.

Rozszerzenie wspiera dwa silniki renderujące: wkhtmltopdf (klasyczne rozwiązanie oparte na starszej wersji WebKit - proste, ale nie wspiera CSS Flexbox i Grid) oraz Puppeteer/Chromium (nowoczesna alternatywa z pełnym wsparciem CSS, prawidłowym osadzaniem webfontów i wykonywaniem JavaScript - ale wyższym zużyciem zasobów).

Oddzielny Print-CSS (`@media print`) steruje, które elementy są widoczne w PDF. Gosign zaleca ukrywanie nawigacji, stopki, banera cookie i elementów interaktywnych w Print-CSS i wstawianie zamiast nich logo, danych kontaktowych i wskazania URL.

## Częste problemy i rozwiązania

**PDF wyświetla zły layout, brakujące obrazy lub czcionki.** Najczęstsza przyczyna: wkhtmltopdf nie może renderować nowoczesnego CSS. Strony korzystające z Flexbox lub CSS Grid wyglądają w PDF zupełnie inaczej niż w przeglądarce. Rozwiązanie: przejście na Puppeteer jako silnik renderujący.

**Generowanie PDF trwa ponad 10 sekund.** Puppeteer uruchamia dla każdego PDF proces Chromium. Przy jednoczesnych zapytaniach obciążenie serwera mnoży się. Rozwiązanie: implementacja cachowania PDF. Wygenerowany PDF jest cachowany przez zdefiniowany czas (np. 60 minut).

**Strony za loginem dostarczają pusty PDF.** web2pdf wywołuje stronę wewnętrznie przez HTTP. Jeśli strona jest za loginem, brakuje ciasteczek sesji i proces renderujący widzi tylko stronę logowania. Rozwiązanie: konfiguracja specjalnego endpointu renderowania PDF rozwiązującego uwierzytelnianie przez token zamiast ciasteczek sesji.

## Migracja i kompatybilność wersji

web2pdf jest stabilnie dostępne dla TYPO3 v10 i v11. Dla TYPO3 v12 LTS istnieją forki społecznościowe zapewniające kompatybilność. Oryginalny pakiet nie jest już aktywnie utrzymywany.

Dla TYPO3 v13 i dalszych Gosign zaleca zmianę architektoniczną: zamiast prowadzić web2pdf jako rozszerzenie TYPO3, generowanie PDF jest implementowane jako oddzielny mikroserwis. Serwis Node.js z Puppeteer przyjmuje URL i zwraca PDF. To oddziela generowanie PDF od serwera TYPO3 i czyni rozwiązanie niezależnym od wersji TYPO3.

Nakład migracji z web2pdf na rozwiązanie oparte na Puppeteer wynosi typowo 2 do 4 dni. Istniejące pliki Print-CSS można przejąć 1:1. Tylko mechanizm wywołania (kliknięcie przycisku, obsługa URL) musi być dostosowany.

--- Webflow do TYPO3 - Migracja | Gosign ---
> Migracja stron Webflow na TYPO3: Większa kontrola, brak zależności od platformy, funkcje Enterprise.

## Strony Webflow napotykają twarde granice przy wymaganiach Enterprise

Webflow świetnie sprawdza się przy prototypach, stronach docelowych i startupach z trzema do pięciu osób w zespole. Ale od pewnego momentu platforma staje się problemem: brak wsparcia dla wielu języków na poziomie Enterprise, brak drobnoziarnistego zarządzania uprawnieniami, brak własnych przepływów backendowych, brak opcji on-premise, a hosting wyłącznie na serwerach Webflow w USA. Dla firm, które muszą być hostowane w UE (RODO, Schrems II), zarządzających kilkuset stronami i potrzebujących CMS-u z procesem redakcyjnym, TYPO3 jest logiczną kontynuacją. Polskie agencje cyfrowe coraz częściej obsługują migracje Webflow do TYPO3, ponieważ klienci z sektora finansowego i przemysłu zderzają się z tymi ograniczeniami pierwsi. Gosign migruje strony Webflow na TYPO3: istniejący design (HTML/CSS) konwertowany jest na szablony Fluid, treści przejmowane są w sposób strukturalny, a funkcjonalność uzupełniana rozszerzeniami TYPO3.

## Typowe scenariusze dotyczą rosnących firm, branż regulowanych i międzynarodowych roll-outów

Najczęstszym scenariuszem jest szybko rosnący startup, który nie skaluje już swojej strony Webflow. Z 20 osobami i witryną w jednym języku Webflow działa. Z 200 osobami, pięcioma językami i blogiem z 500 artykułami już nie. Struktura cenowa Webflow nie skaluje się: plany CMS ograniczone są do 10 000 elementów, custom code jest limitowany, dostęp API ograniczany. Przejście na TYPO3 daje firmie pełną kontrolę nad hostingiem, wydajnością i rozszerzalnością.

Drugim scenariuszem są branże regulowane. Polski dostawca usług finansowych zbudował swoją witrynę marketingową na Webflow, ale dział compliance wymaga hostingu w UE, logów audytowych zmian treści i przepływu zatwierdzania, w którym cztery oczy akceptują każdą zawartość strony. Webflow nie oferuje żadnego z tych punktów natywnie. TYPO3 - tak: workspace'y dla stagingu i akceptacji, ext:belog dla logów audytowych i hosting na serwerze we Frankfurcie lub w polskich data center.

Trzeci scenariusz: roll-out międzynarodowy. Polska firma przemysłowa ma stronę główną na Webflow w języku angielskim. Teraz mają powstać strony krajowe w 12 językach. Webflow Localization jest drogie i ograniczone. TYPO3 oferuje natywne wsparcie multi-site i multi-language, w którym każdy język może mieć własną strukturę stron, łącznie z lokalnymi treściami nieistniejącymi we wszystkich językach.

## Architektura techniczna konwertuje eksport Webflow na szablony Fluid TYPO3

Migracja podąża za zdefiniowanym procesem: eksport projektu Webflow jako HTML/CSS/JS, analiza struktury stron i wykorzystanych interakcji, konwersja HTML na szablony Fluid, import treści do elementów treści TYPO3. Eksport Webflow dostarcza czystego, semantycznego HTML, który dobrze przekłada się na Fluid. CSS przejmowany jest jako plik Sass/SCSS lub przepisywany na klasy utility Tailwind, w zależności od setupu TYPO3.

Interakcje Webflow (animacje przewijania, efekty hover, modale) opierają się na zastrzeżonej silniku JavaScript. Przejęcie ich 1:1 nie jest możliwe. Zamiast tego interakcje odtwarza się natywnym CSS (transitions, animations) lub lekkim JavaScript (IntersectionObserver, element Dialog). W większości przypadków redukuje to rozmiar pliku JavaScript z 200-300 KB (Webflow Runtime) do poniżej 20 KB.

Import treści odbywa się przez API Webflow lub eksport HTML. Każda kolekcja Webflow mapowana jest na element treści TYPO3 lub rekord Extbase. Artykuły blogowe importowane są do tx_news, członkowie zespołu jako rekordy custom, opinie do istniejącej struktury danych TYPO3.

## Częste problemy dotyczą funkcji specyficznych dla Webflow i przekierowań URL

Największym problemem migracji są funkcje Webflow bez odpowiednika w TYPO3. Webflow Forms działają przez wbudowany handler formularzy. W TYPO3 trzeba skonfigurować system formularzy (powermail, Form Framework). Webflow E-Commerce działa na platformie. W TYPO3 trzeba uruchomić system sklepowy (natywny TYPO3 lub integracja Shopware/Magento). Te luki funkcjonalne trzeba zidentyfikować przed migracją i zaplanować w projekcie TYPO3.

Drugi problem: przekierowania URL. URL-e Webflow podążają za własnym schematem. Po migracji wszystkie stare URL-e muszą być przekierowane na nowe URL-e TYPO3, aby Google nie indeksował stron jako 404 i istniejące backlinki zostały zachowane. Przy 200 stronach to 200 przekierowań konfigurowanych w tabeli redirect TYPO3 lub przez .htaccess.

Trzeci temat: różnice w designie. Webflow renderuje układy CSS własnym silnikiem, który może odbiegać od standardowego zachowania przeglądarek. Układ wyglądający w Webflow piksel po pikselu może w TYPO3 renderować się minimalnie inaczej, ponieważ CSS-reset lub osadzenie czcionki różnią się. Wizualny przebieg QA po migracji jest dlatego obowiązkowy.

## Migracja nie jest upgrade'em, lecz zmianą platformy

Nie istnieje zautomatyzowana ścieżka migracji z Webflow do TYPO3. Każda migracja to projekt z analizą, konwersją, importem i QA. Czas trwania zależy od złożoności: prosta witryna z 20 stronami i blogiem migrowana jest w dwa do trzech tygodni. Złożona witryna z 500 stronami, e-commerce i pięcioma językami wymaga dwóch do trzech miesięcy. Gosign realizował migracje Webflow dla firm od 50 do 2 000 stron i wykorzystuje wspomaganą AI konwersję szablonów, generującą kod Fluid z HTML Webflow i redukującą ręczne dostosowania do minimum.

--- WebP TYPO3 - Optymalizacja obrazów | Gosign ---
> Automatyczna konwersja JPG/PNG do WebP. 25–35% mniejsze pliki graficzne, szybsze ładowanie.

## Obrazy stanowią od 50 do 70 procent wagi strony, a WebP redukuje je o jedną trzecią

Przeciętna witryna TYPO3 ładuje na stronę 2 do 5 MB danych obrazów. To największy pojedynczy czynnik czasu ładowania, a tym samym wyniku Google PageSpeed. WebP to format obrazów opracowany przez Google, który przy porównywalnej jakości jest o 25 do 35 procent mniejszy od JPEG i nawet o 80 procent mniejszy od PNG. Rozszerzenie WebP dla TYPO3 konwertuje istniejące obrazy JPG i PNG automatycznie do WebP, bez konieczności zmiany zachowań redaktorów. Obrazy są wgrywane jak dotąd w backendzie FAL, rozszerzenie generuje wariant WebP w tle i serwuje go przeglądarkom obsługującym ten format. Wszystkie nowoczesne przeglądarki wspierają WebP od 2020 roku: Chrome, Firefox, Safari, Edge.

Dla witryn już zoptymalizowanych pod PageSpeed konwersja WebP jest często ostatnim krokiem podnoszącym wynik z 85 do 95 lub wyżej.

## Typowe scenariusze dotyczą witryn nasyconych obrazami, e-commerce i projektów mobile-first

Najczęstszym scenariuszem są witryny firmowe nasycone obrazami. Portal nieruchomości pokazuje przy każdym obiekcie 15 do 25 zdjęć. Przy 500 obiektach to 10 000 obrazów. Bez WebP zdjęcia ważą średnio 250 KB (JPEG), z WebP 170 KB. Na widoku listy z 20 obiektami i jednym zdjęciem tytułowym każdego WebP oszczędza 1,6 MB na każde wywołanie strony. Przy 50 000 wywołań stron miesięcznie to 80 GB mniej ruchu, co bezpośrednio przekłada się na koszty hostingu.

Drugim scenariuszem są integracje e-commerce. System sklepowy pokazuje zdjęcia produktów w różnych rozmiarach: miniatura, widok listy, widok szczegółowy, zoom. Każdy rozmiar generowany jest jako wariant WebP. Przy sklepie z 2 000 produktami i pięcioma wariantami obrazu na produkt powstaje 10 000 plików WebP, mierzalnie przyspieszających budowanie strony w widoku listy.

Trzeci scenariusz: witryny mobile-first dla grup docelowych ze słabym łączem. Portal NGO wykorzystywany w regionach z sieciami 3G nieproporcjonalnie zyskuje na mniejszych plikach obrazów. Różnica między 5 sekundami a 15 sekundami ładowania decyduje, czy odwiedzający zobaczy stronę, czy zrezygnuje.

## Architektura techniczna konwertuje obrazy w pipeline'ie processingu TYPO3

Rozszerzenie wpina się w pipeline image processingu TYPO3. Gdy TYPO3 przetwarza obraz (resize, crop), rozszerzenie dodatkowo generuje wariant WebP w tym samym katalogu. Dostarczanie odbywa się przez Content Negotiation: serwer sprawdza nagłówek Accept przeglądarki. Gdy przeglądarka akceptuje "image/webp", serwer dostarcza plik WebP. W przeciwnym razie oryginalny JPEG/PNG.

Technicznie istnieją dwa warianty implementacji: pierwszy wykorzystuje reguły mod_rewrite w Apache lub nginx, przekierowujące zapytania o obrazy na wariant WebP, gdy istnieje. Drugi wykorzystuje middleware TYPO3 manipulujące nagłówek odpowiedzi. Wariant mod_rewrite jest wydajniejszy, ponieważ wykonywany jest przed PHP.

Sama konwersja działa przez libwebp (narzędzie wiersza poleceń cwebp), ImageMagick z obsługą WebP lub rozszerzenie PHP GD (gdy skompilowane z obsługą WebP). Jakość jest konfigurowalna: standard 80 (na 100), co stanowi dobry kompromis między rozmiarem pliku a jakością wizualną. Dla treści fotograficznych zalecamy 82 do 85, dla zrzutów ekranu i ilustracji 75 do 78.

Dla jeszcze lepszej kompresji nowsze wersje rozszerzenia wspierają format AVIF, oferujący kolejne 20 do 30 procent oszczędności względem WebP. Wsparcie AVIF jest dostępne w Chrome i Firefox, w Safari od wersji 16.

## Częste problemy dotyczą brakujących bibliotek serwerowych i konfiguracji CDN

Najczęstszym problemem jest brakujący plik binarny cwebp na serwerze. Środowiska shared hosting często nie mają zainstalowanego libwebp, a hostingodawca nie zezwala na instalację plików binarnych. Rozwiązanie: wykorzystać PHP GD z obsługą WebP (dostępne w większości wersji PHP od 7.1) lub wybrać dostawcę hostingu udostępniającego cwebp. Na serwerach zarządzanych i w kontenerach Docker instalacja jest trywialna: apt-get install webp.

Drugi problem: konfiguracja CDN. Gdy CDN (Cloudflare, Fastly, AWS CloudFront) stoi przed witryną, musi poprawnie obsługiwać WebP. Dwa podejścia: CDN zna Content Negotiation i cache'uje WebP oraz JPEG jako osobne warianty (Vary: Accept). Albo witryna TYPO3 dostarcza bezpośrednio URL-e WebP (bez Content Negotiation), a CDN cache'uje tylko jedną wersję. Cloudflare oferuje automatyczną konwersję WebP przez Polish, co częściowo czyni rozszerzenie TYPO3 zbędnym.

Trzeci temat: kontrola jakości. Przy zbyt niskim ustawieniu jakości (poniżej 70) widoczne stają się artefakty, szczególnie przy gradientach kolorów i drobnych teksturach. Po konfiguracji należy przeprowadzić porównanie A/B (oryginał vs. WebP), aby upewnić się, że jakość jest akceptowalna dla danego zastosowania.

## TYPO3 v12 i v13 są wspierane, rozszerzenie należy do najstabilniejszych w ekosystemie

Rozszerzenie WebP należy do najczęściej instalowanych rozszerzeń wydajnościowych w ekosystemie TYPO3. Jest aktywnie utrzymywane i kompatybilne z TYPO3 v12 oraz v13. Ponieważ funkcjonalność podstawowa (hook image processingu, konwersja plików) opiera się na stabilnych API TYPO3, breaking changes przy upgrade'ach zdarzają się rzadko. Gosign konfiguruje WebP jako standard w każdym nowym projekcie TYPO3 i dodatkowo, gdy dostępne, włącza AVIF dla maksymalnej kompresji.

--- Bootstrap TYPO3 - T3Bootstrap | Gosign ---
> Framework Bootstrap jako Sitepackage TYPO3. Responsywne szablony, system Grid, komponenty Bootstrap jako elementy treści.

## Projekty TYPO3 oparte na Bootstrap potrzebują Sitepackage budującego most między frameworkiem a CMS-em

Bootstrap to najczęściej wykorzystywany framework CSS na świecie. Ponad 25 procent wszystkich witryn używa Bootstrapa. Dla projektów TYPO3 oznacza to: projektanci dostarczają makiety w Bootstrapie, programiści znają jego klasy i komponenty, a klienci oczekują responsywnych układów na nim opartych. ws_t3bootstrap wprowadza Bootstrap jako Sitepackage bezpośrednio do TYPO3: responsywne szablony, system Grid, komponenty Bootstrap (Accordion, Cards, Carousel, Tabs, Alerts) jako elementy treści i prekonfigurowaną bazę TypoScript. Zamiast ręcznie integrować Bootstrap w pustym projekcie TYPO3, ws_t3bootstrap dostarcza działający punkt startowy gotowy do produkcji od pierwszej chwili.

## Typowe scenariusze to witryny firmowe, portale i prototypowanie

Najczęstszym scenariuszem jest witryna średniej firmy. Firma z 50 do 500 pracownikami potrzebuje strony z 30 do 80 podstronami: strona główna, o nas, usługi, referencje, kariera, kontakt. Projektant tworzy mockup w oparciu o Bootstrap 5. ws_t3bootstrap dostarcza szablony, system Grid i elementy treści, dzięki czemu programista musi tylko dodać własne CSS (kolory, czcionki, odstępy) i komponenty specyficzne dla projektu. Typowy czas rozwoju: dwa do trzech tygodni od mockupu do gotowej strony zamiast czterech do sześciu tygodni przy custom-setupie.

Drugim scenariuszem są portale intranetowe. Firma prowadzi intranet TYPO3 dla 2 000 pracowników. Design nie musi być unikatowy, ale spójny i responsywny. ws_t3bootstrap dostarcza profesjonalny standardowy układ, który można wdrożyć bez dużego nakładu projektowego. Elementy treści takie jak akordeony do FAQ, taby dla informacji działowych i karty dla zajawek news są dostępne natychmiast.

Trzeci scenariusz: szybkie prototypowanie. Agencja buduje w dwa dni działający prototyp witryny, który klient może zaakceptować. ws_t3bootstrap redukuje czas setupu z dni do godzin, ponieważ struktura podstawowa (header, footer, nawigacja, grid) już istnieje.

## Architektura techniczna rejestruje komponenty Bootstrap jako elementy treści TYPO3

ws_t3bootstrap instaluje się jako Sitepackage TYPO3 i konfiguruje: setup TypoScript z dołączeniem CSS/JS Bootstrap, szablony Fluid dla nagłówka, stopki i układów stron, układy backendu (1-kolumnowy, 2-kolumnowy, 3-kolumnowy z sidebarem) oraz elementy treści odwzorowujące komponenty Bootstrap.

Elementy treści definiowane są przez konfiguracje TCA i szablony Fluid. Element Accordion tworzy na przykład akordeon Bootstrap z n panelami, gdzie każdy panel ma tytuł i tekst. Element Card generuje kartę Bootstrap z obrazem, tytułem, tekstem i linkiem. Element Grid umożliwia zagnieżdżone układy kolumn wewnątrz strony.

CSS Bootstrap dołączany jest jako skompilowany plik CSS (szybki, bez konieczności narzędzi build) lub jako kod źródłowy Sass kompilowany przez system build (Webpack, Vite). Wariant Sass pozwala nadpisać zmienne Bootstrap (kolory, breakpointy, rozmiary czcionek) i dołączać tylko potrzebne moduły Bootstrap, co redukuje rozmiar pliku CSS z 230 KB do 80-120 KB.

Komponenty JavaScript (Accordion, Collapse, Dropdown, Modal, Tab, Toast) dołączane są przez Bootstrap 5, który nie wymaga jQuery. Zmniejsza to rozmiar pliku JavaScript względem Bootstrap 4 o około 85 KB (brak jQuery).

## Częste problemy dotyczą konfliktów wersji Bootstrap i walki o specyficzność CSS

Największym problemem przy Sitepackage'ach Bootstrap jest konflikt wersji. Gdy ws_t3bootstrap dołącza Bootstrap 5.2, ale inne rozszerzenie (np. plugin slidera) wnosi Bootstrap 4.6 lub 3.x, klasy CSS się zderzają. Bootstrap 4 używa "col-md-4", Bootstrap 5 również, ale z odmiennym zachowaniem przy określonych utility'ach. Rozwiązanie: ujednolicić wszystkie rozszerzenia do tej samej wersji Bootstrap lub izolować wbudowany Bootstrap rozszerzenia przez scoping CSS.

Drugi problem: specyficzność CSS. Gdy własny CSS musi nadpisać klasy Bootstrap, powstaje wyścig specyficzności: deklaracje !important mnożą się, ponieważ utility'e Bootstrap mają wysoką specyficzność. Rozwiązanie: korzystać ze zmiennych Bootstrap zamiast nadpisywać CSS i ładować własny arkusz po CSS Bootstrapa.

Trzeci temat: wydajność. Bootstrap jako framework ładuje wszystkie komponenty, nawet gdy witryna używa tylko pięciu z nich. Przy witrynie potrzebującej tylko Grid, Cards i Navbar 80 procent CSS Bootstrap nigdy nie jest wykorzystywane. PurgeCSS lub selektywny import Sass redukuje rozmiar pliku CSS do koniecznego minimum.

## TYPO3 v12 i v13 są wspierane, Bootstrap 5 jest aktualnym standardem

ws_t3bootstrap jest aktywnie utrzymywany i wspiera TYPO3 v12 oraz v13. Aktualna wersja oparta jest na Bootstrap 5.3. Przy upgrade z Bootstrap 4 do 5 należy uwzględnić breaking changes: zależność od jQuery znika, niektóre klasy CSS zostały przemianowane (np. ml-/mr- na ms-/me-) i zmieniło się API JavaScript. Gosign przeprowadza upgrade'y Bootstrap razem z upgrade'ami TYPO3 i sprawdza przy tym wszystkie elementy treści pod kątem poprawnej prezentacji. W nowych projektach rekomendujemy ws_t3bootstrap jako punkt startowy i uzupełniamy Sitepackage o komponenty specyficzne dla projektu, zamiast integrować Bootstrap w TYPO3 od podstaw.

--- wwt3_encryption TYPO3 - Ochrona e-mail | Gosign ---
> Rozszerzenie TYPO3 do automatycznego szyfrowania adresów e-mail na stronie. Chroni adresy e-mail przed harvesterami i spam-botami przez zaciemnianie JavaScript.

## Dlaczego ukrywanie adresów e-mail nadal jest obowiązkowe dla każdej publicznej strony

Każda strona firmowa, każda strona uczelni i każdy portal urzędowy publikuje adresy e-mail: osoby kontaktowe w stopce, osoby kontaktowe w zespołach, kontakty prasowe w newsroomach, dział prawny w polityce prywatności. Bez ochrony boty-harvester zbierają te adresy w ciągu kilku dni po publikacji i sprzedają je spamerom. wwt3_encryption to klasyczne rozszerzenie TYPO3 dla tego problemu i szyfruje adresy e-mail po stronie serwera, dzięki czemu boty przy parsowaniu HTML widzą tylko bezużyteczny kod, podczas gdy prawdziwi użytkownicy mogą kliknąć na poprawny adres. Rozszerzenie kierowane jest do operatorów, którzy z powodów prawnych muszą prominentnie pokazywać dane kontaktowe, ale nie chcą godzić się na wynikający z tego potop spamu.

## Typowe scenariusze zastosowania

Kancelaria prawnicza z 60 partnerami i associate'ami publikuje wszystkie profile prawników wraz z bezpośrednimi adresami e-mail, bo kodeks etyki zawodowej wymaga osiągalnych danych kontaktowych. Bez ukrywania wszystkie 60 adresów w ciągu tygodni otrzymuje maile phishingowe, reklamy i częściowo ukierunkowane ataki. wwt3_encryption renderuje adresy tak, że kod źródłowy nie zawiera czytelnego stringu z @, podczas gdy przeglądarka u użytkownika wyświetla poprawny adres linku mailto.

Drugim scenariuszem jest uczelnia, która pielęgnuje strony wydziałów z kontaktami katedr. Każda katedra ma stronę internetową z danymi telefonicznymi i e-mailowymi, które są pielęgnowane redakcyjnie przez zarządzanie treścią TYPO3. Redaktorzy wpisują adresy jako normalny tekst w elementy RichText lub pola kontaktowe, bez konieczności zajmowania się ukrywaniem. wwt3_encryption automatycznie wpina się w proces renderowania i chroni wszystkie linki mailto bez dodatkowej pracy redakcyjnej.

Trzecim przypadkiem są administracje publiczne ze stopką, formularzami kontaktowymi i listami wydziałów merytorycznych. Wymaganie jest tu często jeszcze surowsze, bo istnieje obowiązek dostępności cyfrowej: chroniony adres musi być poprawnie odczytywany przez screen-readery, a kliknięcie musi otwierać klienta pocztowego, dokładnie jak przy nieukrywanym adresie. Kombinacja dekodowania JavaScript i semantycznie czystych atrybutów href to jedyny sposób, aby spełnić oba wymagania.

## Architektura techniczna: post-processing w renderowaniu TYPO3

wwt3_encryption wpina się w proces renderowania TYPO3, zazwyczaj przez hook Content-Post-Processor lub userfunc TypoScript. Po złożeniu wyjścia HTML przez Page-Renderer rozszerzenie przechodzi przez gotowy markup, znajduje wszystkie linki mailto i wszystkie proste adresy e-mail w tekście za pomocą regex i zastępuje je ukrytymi wariantami. Ukrywanie może odbywać się przez różne metody: kodowanie ROT13 celu linku z dekodowaniem JavaScript, kodowanie Base64, fragmentację znakową z pseudo-elementami CSS lub kombinację.

Zaletą wariantu post-processingowego jest to, że działa bez zmian w elementach treści czy szablonach. Redaktorzy pracują dalej ze zwykłymi linkami mailto w RichText, a rozszerzenie automatycznie przejmuje zabezpieczenie. Konfiguracja rozszerzenia odbywa się przez stałe TypoScript, które wybierają między różnymi metodami ukrywania i pozwalają definiować wyjątki dla określonych stron lub obszarów treści.

## Częste problemy i rozwiązania

Pierwszym problemem jest dostępność cyfrowa. Czysto JavaScriptowe rozwiązania zawodzą u użytkowników z wyłączonym JavaScript, a niektóre screen-readery mają problemy z fragmentacją znaków opartą na CSS. Pragmatyczne podejście łączy łatwo łamalne ukrywanie kliencie z dodatkowym semantycznym aria-label na linku, dzięki czemu screen-readery poprawnie odczytują adres, podczas gdy harvester zawodzi na syntaktycznej odmienności. Absolutne bezpieczeństwo przy publicznie dostępnych adresach nie jest osiągalne, ale już umiarkowane przeszkody mierzalnie redukują obciążenie spamem.

Drugim problemem są warstwy cache'owania. Gdy ukrywanie post-processingowe jest wykonywane przed Page-Cache, cache dostarcza ukryte dane i wszystko działa. Jeśli jest za cache, każda cache'owana strona przy każdym zapytaniu jest ponownie przepuszczana przez post-processor, co znacząco obciąża wydajność. Prawidłowa kolejność w łańcuchu renderowania TypoScript jest zatem krytyczna i powinna być sprawdzana przy każdej większej zmianie zachowania cache'owania.

Trzeci temat dotyczy treści dynamicznych. Adresy e-mail, które są doładowywane przez AJAX lub pochodzą z zewnętrznych API, nie przechodzą przez renderer TYPO3 i tym samym nie przez wwt3_encryption. Takie miejsca muszą być chronione oddzielnie, albo przez dostarczanie przez samo API ukrytych wariantów, albo przez klienckie JavaScript, które obrabia doładowaną treść.

## Migracja i kompatybilność wersji

wwt3_encryption ma jak wiele starszych rozszerzeń TYPO3 niespójną historię wersji: dla v9 i v10 istniały utrzymywane wydania, dla v11 i v12 istnieją forki społeczności, których aktywność jest różna. Kto migruje na TYPO3 v13, powinien przed upgrade sprawdzić, czy własny fork jeszcze działa, czy zmiana na alternatywną metodę ukrywania staje się konieczna.

Sam rdzeń TYPO3 przynosi proste ukrywanie e-maili, które jest aktywowane przez config.spamProtectEmailAddresses w TypoScript i stosuje ROT13 w rdzeniowym rendererze. Dla prostych konfiguracji ten wariant core wystarcza i czyni własne rozszerzenie zbędnym. Kto potrzebuje silniejszego lub bardziej elastycznego ukrywania, na przykład z kilkoma równoległymi metodami lub wyjątkami per element treści, sięga po rozszerzenie takie jak wwt3_encryption. Gosign ocenia w każdym pojedynczym przypadku, czy funkcja core wystarcza, czy dedykowane rozszerzenie ma sens, i w razie potrzeby wspiera też przebudowę na własną, smukłą implementację post-processingową, która dopasowuje się bezpośrednio do danego projektu.

Skuteczność każdego ukrywania e-maili spada z czasem, bo techniki harvesterów się rozwijają. ROT13 jest dziś uważany za prawie bezużyteczny przeciwko wyspecjalizowanym botom, podczas gdy fragmentacja znakowa z CSS lub trickami Unicode nadal buduje umiarkowane przeszkody. Naprawdę solidna obrona to zatem kombinacja: ukrywanie w wyjściu HTML, uzupełnione o dobry filtr spamowy po stronie odbiorcy i najlepiej opcję kontaktu przez formularz zamiast bezpośrednio publikowanego adresu. Kto musi spełnić wymagania prawne, nie uniknie publikacji, ale powinien zaoferować formularz kontaktowy jako podstawową drogę, a adres pokazywać tylko drugorzędnie.

Dla operatorów TYPO3 v13 zaleca się dodatkowo regularne sprawdzanie pipeline'u Content-Rendering pod kątem Breaking Changes w core. Niektóre punkty hooków, które były dostępne we wcześniejszych wersjach do post-processingu, zostały w v13 deprecated lub zastąpione przez zdarzenia PSR-14. Rozszerzenia, które nadal polegają na starych hookach, działają po upgrade technicznie, ale nie obrabiają już treści. Krótkie sprawdzenie wpisów logu po upgrade pokazuje takie ciche awarie wcześnie i zapobiega temu, aby przez tygodnie niezauważenie były dostarczane nieukryte adresy.

--- TYPO3 Extensions | Tworzenie i monitoring ---
> 800+ rozszerzeń TYPO3 monitorowanych. Tworzenie, audyt i monitoring bezpieczeństwa. Wszystkie rozszerzenia w jednym miejscu.

<!-- Co oferuje Gosign? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Co oferuje Gosign w zakresie rozszerzeń TYPO3?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Gosign monitoruje ponad 800 rozszerzeń TYPO3 pod kątem luk bezpieczeństwa, kompatybilności i wydajności. Dla każdego rozszerzenia Gosign oferuje: tworzenie od zera, aktualizacje i migracje, audyt kodu oraz utrzymanie. Od 25&nbsp;lat w świecie TYPO3, od 2023 z rozwojem wspomaganym AI: 60-80&nbsp;% szybciej niż tradycyjnymi metodami.
</p>
</div>
</section>

<!-- Kategorie rozszerzeń -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">Kategorie rozszerzeń</h2>
<div class="space-y-8">

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Wyszukiwanie i indeksowanie</h3>
<p class="text-body text-gosign-text mb-4">Apache Solr, ke_search, Faceted Search. Wyszukiwanie Enterprise w tysiącach dokumentów i plików.</p>
<div class="flex flex-wrap gap-2">
<a href="/pl/typo3/solrfal/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">solrfal</a>
<a href="/pl/typo3/ke_search_premium/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">ke_search_premium</a>
<a href="/pl/typo3/find/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">find</a>
<a href="/pl/typo3/in2studyfinder/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">in2studyfinder</a>
</div>
</div>

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Bezpieczeństwo i uwierzytelnianie</h3>
<p class="text-body text-gosign-text mb-4">SSO, SAML, OIDC, Cookie-Consent, CAPTCHA, CORS. Bezpieczeństwo Enterprise dla TYPO3.</p>
<div class="flex flex-wrap gap-2">
<a href="/pl/typo3/shibboleth_auth/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">shibboleth_auth</a>
<a href="/pl/typo3/oidc/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">oidc</a>
<a href="/pl/typo3/dp_cookieconsent/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">dp_cookieconsent</a>
<a href="/pl/typo3/saml2/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">saml2</a>
<a href="/pl/typo3/be_acl/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">be_acl</a>
</div>
</div>

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Formularze i wydarzenia</h3>
<p class="text-body text-gosign-text mb-4">Powermail, zarządzanie wydarzeniami, systemy rezerwacji, ankiety, integracja z newsletterami.</p>
<div class="flex flex-wrap gap-2">
<a href="/pl/typo3/powermail/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">powermail</a>
<a href="/pl/typo3/sf_event_mgt/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">sf_event_mgt</a>
<a href="/pl/typo3/booking/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">booking</a>
<a href="/pl/typo3/rapidmail/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">rapidmail</a>
</div>
</div>

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Treści i szablony</h3>
<p class="text-body text-gosign-text mb-4">Mask, DCE, VHS ViewHelper, Bootstrap Grids. Własne elementy treści i tworzenie szablonów.</p>
<div class="flex flex-wrap gap-2">
<a href="/pl/typo3/mask/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">mask</a>
<a href="/pl/typo3/dce/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">dce</a>
<a href="/pl/typo3/vhs/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">vhs</a>
<a href="/pl/typo3/bootstrap_grids/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">bootstrap_grids</a>
</div>
</div>

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">PDF i dokumenty</h3>
<p class="text-body text-gosign-text mb-4">Generowanie PDF, przeglądarki PDF, flipbooki, zarządzanie pobieraniem.</p>
<div class="flex flex-wrap gap-2">
<a href="/pl/typo3/pdfviewhelpers/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">pdfviewhelpers</a>
<a href="/pl/typo3/web2pdf/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">web2pdf</a>
<a href="/pl/typo3/rflipbook/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">rflipbook</a>
<a href="/pl/typo3/downloadmanager/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">downloadmanager</a>
</div>
</div>

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Media i obrazy</h3>
<p class="text-body text-gosign-text mb-4">Edycja obrazów, galerie, slidery, focuspoint, Cloudinary CDN.</p>
<div class="flex flex-wrap gap-2">
<a href="/pl/typo3/focuspoint/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">focuspoint</a>
<a href="/pl/typo3/imagemap/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">imagemap</a>
<a href="/pl/typo3/sf_filecollection_gallery/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">sf_filecollection_gallery</a>
</div>
</div>

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Mapy i lokalizacje</h3>
<p class="text-body text-gosign-text mb-4">Leaflet, Google Maps, OpenStreetMap. Wyszukiwarki oddziałów i wyszukiwanie w obrębie promienia.</p>
<div class="flex flex-wrap gap-2">
<a href="/pl/typo3/leaflet/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">leaflet</a>
<a href="/pl/typo3/maps2/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">maps2</a>
<a href="/pl/typo3/geocoordinates/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">geocoordinates</a>
</div>
</div>

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">E-commerce</h3>
<p class="text-body text-gosign-text mb-4">aimeos, integracja płatności, paywall, kalkulator cen.</p>
<div class="flex flex-wrap gap-2">
<a href="/pl/typo3/aimeos/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">aimeos</a>
<a href="/pl/typo3/amazon_payment/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">amazon_payment</a>
<a href="/pl/typo3/paywall/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">paywall</a>
</div>
</div>

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Wydajność i SEO</h3>
<p class="text-body text-gosign-text mb-4">Cache Warmup, staticfilecache, konwersja WebP, zarządzanie canonical.</p>
<div class="flex flex-wrap gap-2">
<a href="/pl/typo3/warmup/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">warmup</a>
<a href="/pl/typo3/webp/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">webp</a>
<a href="/pl/typo3/newscanonical/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">newscanonical</a>
<a href="/pl/typo3/cache_hash/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">cache_hash</a>
</div>
</div>

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Narzędzia deweloperskie i deployment</h3>
<p class="text-body text-gosign-text mb-4">Extension Builder, in2publish, Styleguide, Deployer.</p>
<div class="flex flex-wrap gap-2">
<a href="/pl/typo3/extension_builder/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">extension_builder</a>
<a href="/pl/typo3/in2publish/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">in2publish</a>
<a href="/pl/typo3/styleguide/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">styleguide</a>
</div>
</div>

<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Rozwiązania branżowe</h3>
<p class="text-body text-gosign-text mb-4">Nieruchomości (OpenImmo, FlowFact), uczelnie (in2studyfinder), stowarzyszenia (hwvereinsliste), edukacja (kuferweb).</p>
<div class="flex flex-wrap gap-2">
<a href="/pl/typo3/openimmo/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">openimmo</a>
<a href="/pl/typo3/flowfact/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">flowfact</a>
<a href="/pl/typo3/kuferweb/" class="inline-flex items-center px-3 py-1.5 border border-gosign-border rounded-card text-small text-gosign-text hover:border-gosign-accent hover:text-gosign-accent transition-colors">kuferweb</a>
</div>
</div>

</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Szukasz wsparcia dla rozszerzenia TYPO3?</h3>
<p class="text-body text-gosign-text mb-6">30&nbsp;minut pierwszej konsultacji, bezpłatnie i bez zobowiązań.</p>
<a
href="/pl/kontakt/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Konsultacja dot. rozszerzeń
</a>
<p class="text-small text-gosign-text-light mt-4">25 lat doświadczenia · 800+ rozszerzeń · rozwój wspomagany AI</p>
</div>
</section>

<!-- KI Table -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Tworzenie rozszerzeń wspomagane AI</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
Od 2023 Gosign wykorzystuje rozwój wspomagany AI. Oto co to oznacza w praktyce:
</p>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Zadanie</th>
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Klasycznie</th>
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Z AI</th>
<th class="py-3 text-small font-bold text-gosign-dark">Oszczędność</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Nowe rozszerzenie (Extbase)</td>
<td class="py-3 pr-4 text-body text-gosign-text">2-4 tygodnie</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">4-8 dni</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">70&nbsp;%</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Aktualizacja rozszerzenia (v9 &rarr; v12)</td>
<td class="py-3 pr-4 text-body text-gosign-text">1-2 tygodnie</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">2-4 dni</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">65&nbsp;%</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Audyt bezpieczeństwa</td>
<td class="py-3 pr-4 text-body text-gosign-text">3-5 dni</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">1 dzień</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">75&nbsp;%</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Przegląd kodu i refactoring</td>
<td class="py-3 pr-4 text-body text-gosign-text">1 tydzień</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">2 dni</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">60&nbsp;%</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- TYPO3 Update -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Aktualizacja TYPO3 do aktualnej wersji</h2>
<p class="text-body text-gosign-text leading-relaxed mb-8">
Aktualizujemy Twoją instalację TYPO3 w atrakcyjnej cenie do aktualnej wersji LTS - w tym wszystkie rozszerzenia, nawet przestarzałe i nieutrzymywane.
</p>
<div class="grid md:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<div class="flex items-start gap-4">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-1" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75M21 12a9 9 0 1 1-18 0 9 9 0 0 1 18 0Z" /></svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Wszystkie rozszerzenia zmigrowane</h3>
<p class="text-body text-gosign-text">Również przestarzałe, nieutrzymywane lub autorskie.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-6">
<div class="flex items-start gap-4">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-1" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 18.75a60.07 60.07 0 0 1 15.797 2.101c.727.198 1.453-.342 1.453-1.096V18.75M3.75 4.5v.75A.75.75 0 0 1 3 6h-.75m0 0v-.375c0-.621.504-1.125 1.125-1.125H20.25M2.25 6v9m18-10.5v.75c0 .414.336.75.75.75h.75m-1.5-1.5h.375c.621 0 1.125.504 1.125 1.125v9.75c0 .621-.504 1.125-1.125 1.125h-.375m1.5-1.5H21a.75.75 0 0 0-.75.75v.75m0 0H3.75m0 0h-.375a1.125 1.125 0 0 1-1.125-1.125V15m1.5 1.5v-.75A.75.75 0 0 0 3 15h-.75M15 10.5a3 3 0 1 1-6 0 3 3 0 0 1 6 0Zm3 0h.008v.008H18V10.5Zm-12 0h.008v.008H6V10.5Z" /></svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Oferta ryczałtowa</h3>
<p class="text-body text-gosign-text">Transparentne koszty, brak ukrytych dodatkowych prac.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-6">
<div class="flex items-start gap-4">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-1" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M3.75 13.5l10.5-11.25L12 10.5h8.25L9.75 21.75 12 13.5H3.75Z" /></svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Przyspieszone przez AI</h3>
<p class="text-body text-gosign-text">30-50 % taniej niż ceny rynkowe dzięki analizie kodu wspomaganej AI.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-6">
<div class="flex items-start gap-4">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-1" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M20.25 6.375c0 2.278-3.694 4.125-8.25 4.125S3.75 8.653 3.75 6.375m16.5 0c0-2.278-3.694-4.125-8.25-4.125S3.75 4.097 3.75 6.375m16.5 0v11.25c0 2.278-3.694 4.125-8.25 4.125s-8.25-1.847-8.25-4.125V6.375m16.5 0v3.75m-16.5-3.75v3.75m16.5 0v3.75C20.25 16.153 16.556 18 12 18s-8.25-1.847-8.25-4.125v-3.75m16.5 0c0 2.278-3.694 4.125-8.25 4.125s-8.25-1.847-8.25-4.125" /></svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Zero utraty danych</h3>
<p class="text-body text-gosign-text">Kompletna migracja danych z zabezpieczeniem rollback.</p>
</div>
</div>
</div>
</div>
<div class="mt-8 text-center">
<a
href="/pl/kontakt/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Zamów aktualizację TYPO3
</a>
</div>
</div>
</section>

<!-- RODO Audit -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">TYPO3 Audyt RODO &amp; Zgodność</h2>
<p class="text-body text-gosign-text leading-relaxed mb-8">
Sprawdzamy Twoją instalację TYPO3 pod kątem zgodności z RODO i wdrażamy wszystkie niezbędne środki w atrakcyjnej cenie.
</p>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse bg-white rounded-card">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Obszar audytu</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Co jest sprawdzane</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Wynik</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Cookie-Consent</td>
<td class="py-3 px-4 text-body text-gosign-text">Baner, opt-in/opt-out, protokołowanie zgody</td>
<td class="py-3 px-4 text-body text-gosign-text">Zgodny z prawem flow zgody</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Śledzenie i analityka</td>
<td class="py-3 px-4 text-body text-gosign-text">Google Analytics, Matomo, Tag Manager, piksele stron trzecich</td>
<td class="py-3 px-4 text-body text-gosign-text">Konfiguracja zgodna z ochroną danych</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Rozszerzenia</td>
<td class="py-3 px-4 text-body text-gosign-text">Przekazywanie danych podmiotom trzecim, zewnętrzne zapytania, integracje CDN</td>
<td class="py-3 px-4 text-body text-gosign-text">Naprawa lub alternatywy zgodne z RODO</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Formularze</td>
<td class="py-3 px-4 text-body text-gosign-text">Rejestr przetwarzania, zgody, okresy przechowywania</td>
<td class="py-3 px-4 text-body text-gosign-text">Kompletna dokumentacja</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Hosting i SSL</td>
<td class="py-3 px-4 text-body text-gosign-text">Lokalizacja serwera, umowa powierzenia, szyfrowanie</td>
<td class="py-3 px-4 text-body text-gosign-text">Hosting zgodny z UE</td>
</tr>
</tbody>
</table>
</div>
<div class="mt-8 text-center">
<a
href="/pl/kontakt/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Zamów audyt RODO
</a>
</div>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
Gosign to hamburska agencja cyfrowa z 25-letnim doświadczeniem w tworzeniu stron, TYPO3 i integracji AI.
Obsługujemy europejskie i polskie przedsiębiorstwa z naszej siedziby w Hamburgu.
Przeanalizowaliśmy ponad 800 rozszerzeń TYPO3 i dzięki wsparciu AI realizujemy projekty
do 70&nbsp;% szybciej niż tradycyjnymi metodami.
</p>
<p class="text-small text-gosign-text-light mt-2">Stan na: luty 2026</p>
</div>
</section>

<!-- Powiązane tematy -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Powiązane tematy</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/pl/typo3-monitor-bezpieczenstwa/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Monitoring</p>
<p class="text-body font-semibold text-gosign-dark">Monitor bezpieczeństwa TYPO3</p>
</a>
<a href="/pl/agencja-cyfrowa-hamburg/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Tworzenie stron</p>
<p class="text-body font-semibold text-gosign-dark">Agencja cyfrowa Hamburg</p>
</a>
<a href="/pl/bezpieczenstwo-stron-standardy/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Bezpieczeństwo</p>
<p class="text-body font-semibold text-gosign-dark">Bezpieczeństwo stron - standardy NIS2</p>
</a>
</div>
</div>
</section>

--- Monitor bezpieczeństwa TYPO3 ---
> Monitor bezpieczeństwa TYPO3: 800+ rozszerzeń monitorowanych, wykrywanie luk bezpieczeństwa. Bezpłatny audyt dostępny.

<!-- Czym jest monitor? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Czym jest monitor bezpieczeństwa TYPO3?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Monitor bezpieczeństwa TYPO3 od Gosign automatycznie nadzoruje ponad 800 rozszerzeń TYPO3 pod kątem luk bezpieczeństwa, przestarzałych wersji i znanych podatności. Gdy rozszerzenie otrzymuje ostrzeżenie bezpieczeństwa, klienci Gosign dowiadują się o tym natychmiast - nie dopiero przy następnym ręcznym sprawdzeniu. Monitor to własne narzędzie Gosign, które w sposób ciągły analizuje biuletyny bezpieczeństwa TYPO3, changelogi rozszerzeń i bazy danych CVE.
</p>
</div>
</section>

<!-- Dlaczego monitoring bezpieczeństwa? -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Dlaczego operatorzy TYPO3 potrzebują monitoringu bezpieczeństwa?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Instalacje TYPO3 korzystają średnio z 30-50 rozszerzeń. Każde z nich to potencjalny punkt wejścia. Zespół bezpieczeństwa TYPO3 regularnie publikuje ostrzeżenia, ale kto je wszystkie czyta? Monitor Gosign robi dokładnie to. Automatycznie i w czasie rzeczywistym.
</p>
</div>
</section>

<!-- Tabela monitoringu -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Co monitoruje monitor</h2>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Obszar</th>
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Co jest sprawdzane</th>
<th class="py-3 text-small font-bold text-gosign-dark">Częstotliwość</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Wersje rozszerzeń</td>
<td class="py-3 pr-4 text-body text-gosign-text">Zainstalowana vs. aktualna wersja</td>
<td class="py-3 text-body text-gosign-text">Codziennie</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Ostrzeżenia bezpieczeństwa</td>
<td class="py-3 pr-4 text-body text-gosign-text">Biuletyny TYPO3, bazy CVE</td>
<td class="py-3 text-body text-gosign-accent-text font-semibold">W czasie rzeczywistym</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">End-of-Life</td>
<td class="py-3 pr-4 text-body text-gosign-text">Rozszerzenia bez opiekuna lub aktualizacji</td>
<td class="py-3 text-body text-gosign-text">Co tydzień</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">TYPO3 Core</td>
<td class="py-3 pr-4 text-body text-gosign-text">Wersja Core vs. aktualna Stable/LTS</td>
<td class="py-3 text-body text-gosign-text">Codziennie</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body font-semibold text-gosign-dark">Wersja PHP</td>
<td class="py-3 pr-4 text-body text-gosign-text">Kompatybilność i status bezpieczeństwa</td>
<td class="py-3 text-body text-gosign-text">Co tydzień</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Usługi -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">Usługi w zakresie bezpieczeństwa TYPO3</h2>
<div class="grid md:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Monitoring bezpieczeństwa</h3>
<p class="text-body text-gosign-text">
Ciągły nadzór nad wszystkimi rozszerzeniami i rdzeniem TYPO3. Natychmiastowe powiadomienie o krytycznych podatnościach.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Audyt bezpieczeństwa</h3>
<p class="text-body text-gosign-text">
Jednorazowa dogłębna analiza: inwentaryzacja rozszerzeń, stan wersji, znane podatności, jakość kodu. Analiza wspomagana AI w godzinach zamiast dni.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Reakcja na incydenty</h3>
<p class="text-body text-gosign-text">
Strona zhakowana? Gosign analizuje wektor ataku, oczyszcza instalację i zamyka lukę. Wsparcie awaryjne dostępne.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Utrzymanie i aktualizacje</h3>
<p class="text-body text-gosign-text">
Regularne aktualizacje bezpieczeństwa, aktualizacje rozszerzeń, zarządzanie wersjami PHP. Proaktywnie, nie reaktywnie.
</p>
</div>
</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Zamów audyt bezpieczeństwa TYPO3 - 30&nbsp;minut, bezpłatnie.</h3>
<p class="text-body text-gosign-text mb-6">Sprawdzimy Twoją instalację TYPO3 pod kątem znanych podatności, bez zobowiązań.</p>
<a
href="/pl/kontakt/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Umów spotkanie
</a>
<p class="text-small text-gosign-text-light mt-4">25 lat doświadczenia · 800+ rozszerzeń · rozwój wspomagany AI</p>
</div>
</section>

<!-- KI Table -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Analiza bezpieczeństwa wspomagana AI: 75&nbsp;% szybciej</h2>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Zadanie</th>
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Klasycznie</th>
<th class="py-3 pr-4 text-small font-bold text-gosign-dark">Z AI</th>
<th class="py-3 text-small font-bold text-gosign-dark">Oszczędność</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Inwentaryzacja rozszerzeń + porównanie wersji</td>
<td class="py-3 pr-4 text-body text-gosign-text">1 dzień</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">30 minut</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">90&nbsp;%</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Analiza podatności (50 rozszerzeń)</td>
<td class="py-3 pr-4 text-body text-gosign-text">2 dni</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">4 godziny</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">75&nbsp;%</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Audyt kodu rozszerzenia</td>
<td class="py-3 pr-4 text-body text-gosign-text">1 tydzień</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">2 dni</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">60&nbsp;%</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 text-body text-gosign-text">Analiza incydentu po włamaniu</td>
<td class="py-3 pr-4 text-body text-gosign-text">2 dni</td>
<td class="py-3 pr-4 text-body text-gosign-accent-text font-semibold">6 godzin</td>
<td class="py-3 text-body text-gosign-accent-text font-bold">65&nbsp;%</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- TYPO3 Update -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Aktualizacja TYPO3 do aktualnej wersji</h2>
<p class="text-body text-gosign-text leading-relaxed mb-8">
Aktualizujemy Twoją instalację TYPO3 w atrakcyjnej cenie do aktualnej wersji LTS - w tym wszystkie rozszerzenia, nawet przestarzałe i nieutrzymywane.
</p>
<div class="grid md:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<div class="flex items-start gap-4">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-1" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75M21 12a9 9 0 1 1-18 0 9 9 0 0 1 18 0Z" /></svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Wszystkie rozszerzenia zmigrowane</h3>
<p class="text-body text-gosign-text">Również przestarzałe, nieutrzymywane lub autorskie.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-6">
<div class="flex items-start gap-4">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-1" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 18.75a60.07 60.07 0 0 1 15.797 2.101c.727.198 1.453-.342 1.453-1.096V18.75M3.75 4.5v.75A.75.75 0 0 1 3 6h-.75m0 0v-.375c0-.621.504-1.125 1.125-1.125H20.25M2.25 6v9m18-10.5v.75c0 .414.336.75.75.75h.75m-1.5-1.5h.375c.621 0 1.125.504 1.125 1.125v9.75c0 .621-.504 1.125-1.125 1.125h-.375m1.5-1.5H21a.75.75 0 0 0-.75.75v.75m0 0H3.75m0 0h-.375a1.125 1.125 0 0 1-1.125-1.125V15m1.5 1.5v-.75A.75.75 0 0 0 3 15h-.75M15 10.5a3 3 0 1 1-6 0 3 3 0 0 1 6 0Zm3 0h.008v.008H18V10.5Zm-12 0h.008v.008H6V10.5Z" /></svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Oferta ryczałtowa</h3>
<p class="text-body text-gosign-text">Transparentne koszty, brak ukrytych dodatkowych prac.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-6">
<div class="flex items-start gap-4">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-1" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M3.75 13.5l10.5-11.25L12 10.5h8.25L9.75 21.75 12 13.5H3.75Z" /></svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Przyspieszone przez AI</h3>
<p class="text-body text-gosign-text">30-50 % taniej niż ceny rynkowe dzięki analizie kodu wspomaganej AI.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-6">
<div class="flex items-start gap-4">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-1" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M20.25 6.375c0 2.278-3.694 4.125-8.25 4.125S3.75 8.653 3.75 6.375m16.5 0c0-2.278-3.694-4.125-8.25-4.125S3.75 4.097 3.75 6.375m16.5 0v11.25c0 2.278-3.694 4.125-8.25 4.125s-8.25-1.847-8.25-4.125V6.375m16.5 0v3.75m-16.5-3.75v3.75m16.5 0v3.75C20.25 16.153 16.556 18 12 18s-8.25-1.847-8.25-4.125v-3.75m16.5 0c0 2.278-3.694 4.125-8.25 4.125s-8.25-1.847-8.25-4.125" /></svg>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Zero utraty danych</h3>
<p class="text-body text-gosign-text">Kompletna migracja danych z zabezpieczeniem rollback.</p>
</div>
</div>
</div>
</div>
<div class="mt-8 text-center">
<a
href="/pl/kontakt/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Zamów aktualizację TYPO3
</a>
</div>
</div>
</section>

<!-- RODO Audit -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">TYPO3 Audyt RODO &amp; Zgodność</h2>
<p class="text-body text-gosign-text leading-relaxed mb-8">
Sprawdzamy Twoją instalację TYPO3 pod kątem zgodności z RODO i wdrażamy wszystkie niezbędne środki w atrakcyjnej cenie.
</p>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse bg-white rounded-card">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Obszar audytu</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Co jest sprawdzane</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Wynik</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Cookie-Consent</td>
<td class="py-3 px-4 text-body text-gosign-text">Baner, opt-in/opt-out, protokołowanie zgody</td>
<td class="py-3 px-4 text-body text-gosign-text">Zgodny z prawem flow zgody</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Śledzenie i analityka</td>
<td class="py-3 px-4 text-body text-gosign-text">Google Analytics, Matomo, Tag Manager, piksele stron trzecich</td>
<td class="py-3 px-4 text-body text-gosign-text">Konfiguracja zgodna z ochroną danych</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Rozszerzenia</td>
<td class="py-3 px-4 text-body text-gosign-text">Przekazywanie danych podmiotom trzecim, zewnętrzne zapytania, integracje CDN</td>
<td class="py-3 px-4 text-body text-gosign-text">Naprawa lub alternatywy zgodne z RODO</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Formularze</td>
<td class="py-3 px-4 text-body text-gosign-text">Rejestr przetwarzania, zgody, okresy przechowywania</td>
<td class="py-3 px-4 text-body text-gosign-text">Kompletna dokumentacja</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Hosting i SSL</td>
<td class="py-3 px-4 text-body text-gosign-text">Lokalizacja serwera, umowa powierzenia, szyfrowanie</td>
<td class="py-3 px-4 text-body text-gosign-text">Hosting zgodny z UE</td>
</tr>
</tbody>
</table>
</div>
<div class="mt-8 text-center">
<a
href="/pl/kontakt/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Zamów audyt RODO
</a>
</div>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
Gosign to hamburska agencja cyfrowa z 25-letnim doświadczeniem w tworzeniu stron, TYPO3 i integracji AI.
Obsługujemy europejskie i polskie przedsiębiorstwa z naszej siedziby w Hamburgu.
Przeanalizowaliśmy ponad 800 rozszerzeń TYPO3 i dzięki wsparciu AI realizujemy projekty
do 70&nbsp;% szybciej niż tradycyjnymi metodami.
</p>
<p class="text-small text-gosign-text-light mt-2">Stan na: luty 2026</p>
</div>
</section>

<!-- Powiązane tematy -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Powiązane tematy</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/pl/typo3-extensions/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">CMS</p>
<p class="text-body font-semibold text-gosign-dark">TYPO3 Extensions</p>
</a>
<a href="/pl/strona-zhakowana-10-przyczyn/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Bezpieczeństwo</p>
<p class="text-body font-semibold text-gosign-dark">Strona zhakowana - 10 przyczyn</p>
</a>
<a href="/pl/bezpieczenstwo-stron-standardy/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Bezpieczeństwo</p>
<p class="text-body font-semibold text-gosign-dark">Bezpieczeństwo stron - standardy NIS2</p>
</a>
</div>
</div>
</section>

--- Co-Build - Indywidualni agenci AI dla Twojego procesu ---
> Co-Build: Twój proces, Twój agent. W 4-6 tygodni od analizy do produkcyjnego agenta AI z dostępem do kodu źródłowego, Decision Layer i strategią wyjścia.

<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Nawigacja AI Agents">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/pl/uslugi/ai-agents/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
AI Agents
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/pl/uslugi/ai-agents/document-agents/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Document</a>
<a href="/pl/uslugi/ai-agents/workflow-agents/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Workflow</a>
<a href="/pl/uslugi/ai-agents/knowledge-agents/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Knowledge</a>
<a href="/pl/uslugi/ai-agents/co-build/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Co-Build</a>
</div>
</div>
</nav>

<!-- W skrócie -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h2 font-bold text-gosign-dark">W skrócie</h2>
<div class="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-3 gap-4 mt-6">
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">4-6 tygodni</p>
<p class="text-body text-gosign-text-light mt-1">Od analizy do produkcyjnego agenta w Twojej infrastrukturze</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Pełny kod źródłowy</p>
<p class="text-body text-gosign-text-light mt-1">Kod, prompty, zestawy reguł, dokumentacja - pełny dostęp i bezterminowe prawo użytkowania</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Bez SaaS</p>
<p class="text-body text-gosign-text-light mt-1">Bez miesięcznych opłat. Bez vendor lock-in. Możliwa samodzielna obsługa.</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Decision Layer</p>
<p class="text-body text-gosign-text-light mt-1">Każdy agent z audit trail, Human-in-the-Loop i wersjonowaniem zestawów reguł</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Agnostyczny wobec modeli</p>
<p class="text-body text-gosign-text-light mt-1">Claude, ChatGPT, Gemini, Llama - wymienialne bez zmiany kodu</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Strategia wyjścia</p>
<p class="text-body text-gosign-text-light mt-1">Szkolenie, dokumentacja, przekazanie. Pełna samodzielność po 12-18 miesiącach.</p>
</div>
</div>
</div>
</div>
</section>

<!-- Trzy fazy -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Trzy fazy do produkcyjnego agenta</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Każdy Co-Build przebiega według ustrukturyzowanego procesu. Na końcu powstaje produkcyjny agent w Twojej infrastrukturze - z kodem źródłowym, dokumentacją i strategią wyjścia.
</p>
</div>
<div class="grid grid-cols-1 md:grid-cols-3 gap-6 mt-8 max-w-content">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Faza 1 - Tydzień 1</p>
<p class="text-h3 font-bold text-gosign-dark">Discover</p>
<ul class="mt-4 space-y-2 text-body text-gosign-text-light">
<li>Analiza procesu z Twoim zespołem merytorycznym</li>
<li>Identyfikacja i formalizacja zestawów reguł</li>
<li>Mapowanie punktów decyzyjnych</li>
<li>Projektowanie Decision Layer</li>
<li>Wyjaśnienie krajobrazu systemowego i integracji</li>
</ul>
<p class="text-body text-gosign-text-light mt-4 font-semibold">Rezultat: Blueprint procesu z matrycą decyzyjną</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Faza 2 - Tygodnie 2-5</p>
<p class="text-h3 font-bold text-gosign-dark">Build</p>
<ul class="mt-4 space-y-2 text-body text-gosign-text-light">
<li>Rozwój agenta z Twoim zespołem</li>
<li>Implementacja Decision Layer</li>
<li>Zestawy reguł jako wersjonowana konfiguracja</li>
<li>Integracja systemowa (SAP, Comarch itp.)</li>
<li>Testy na rzeczywistych danych</li>
</ul>
<p class="text-body text-gosign-text-light mt-4 font-semibold">Rezultat: Produkcyjny agent w Twojej infrastrukturze</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Faza 3 - Tygodnie 5-6</p>
<p class="text-h3 font-bold text-gosign-dark">Transfer</p>
<ul class="mt-4 space-y-2 text-body text-gosign-text-light">
<li>Przekazanie kodu źródłowego</li>
<li>Szkolenie zespołu do samodzielnej obsługi</li>
<li>Dokumentacja kodu, promptów, zestawów reguł</li>
<li>Konfiguracja monitoringu i alertów</li>
<li>Dokumentacja strategii wyjścia</li>
</ul>
<p class="text-body text-gosign-text-light mt-4 font-semibold">Rezultat: Twój zespół obsługuje agenta samodzielnie</p>
</div>
</div>
</div>
</section>

<!-- Dla jakich obszarów -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Dla jakich obszarów</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Co-Build nadaje się do każdego procesu opartego na zestawach reguł, który jest obecnie obsługiwany ręcznie przez ludzi. Typowe obszary:
</p>
<div class="grid grid-cols-1 sm:grid-cols-2 gap-4 mt-6">
<div class="bg-gosign-light border border-gosign-border rounded-card p-4">
<p class="font-semibold text-gosign-dark text-body">Compliance i prawo</p>
<p class="text-body text-gosign-text-light mt-1">Przeglądy regulacyjne, analiza umów, ekstrakcja klauzul, monitorowanie terminów.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-4">
<p class="font-semibold text-gosign-dark text-body">Operacje i łańcuch dostaw</p>
<p class="text-body text-gosign-text-light mt-1">Procesy zamówień, zarządzanie dostawcami, kontrola jakości, obsługa reklamacji.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-4">
<p class="font-semibold text-gosign-dark text-body">Shared Services</p>
<p class="text-body text-gosign-text-light mt-1">Routing zgłoszeń, klasyfikacja zapytań, wewnętrzne udostępnianie wiedzy, automatyzacja service desk.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-4">
<p class="font-semibold text-gosign-dark text-body">Branżowe</p>
<p class="text-body text-gosign-text-light mt-1">Kontrola eksportu, obsługa celna, szkody ubezpieczeniowe, ocena kredytowa - każdy proces oparty na regułach.</p>
</div>
</div>
</div>
</div>
</section>

<!-- Co otrzymujesz -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Co otrzymujesz</h2>
<ul class="mt-6 space-y-3">
<li class="text-body-lg text-gosign-text-light"><strong>Kod źródłowy:</strong> Kompletny kod agenta w Twoim repozytorium</li>
<li class="text-body-lg text-gosign-text-light"><strong>Prompty:</strong> Wszystkie łańcuchy promptów i system prompts, udokumentowane i wersjonowane</li>
<li class="text-body-lg text-gosign-text-light"><strong>Zestawy reguł:</strong> Reguły biznesowe jako wersjonowana konfiguracja, nie jako hardcoding</li>
<li class="text-body-lg text-gosign-text-light"><strong>Decision Layer:</strong> Audit trail, Human-in-the-Loop, ograniczenia Rady Zakładowej</li>
<li class="text-body-lg text-gosign-text-light"><strong>Dokumentacja:</strong> Architektura, logika decyzyjna, przypadki testowe, instrukcja wdrożenia</li>
<li class="text-body-lg text-gosign-text-light"><strong>Strategia wyjścia:</strong> Szkolenie, protokół przekazania, okres wsparcia</li>
</ul>
</div>
</div>
</section>

<!-- Porównanie: Co-Build vs. SaaS vs. Inhouse -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Co-Build vs. SaaS vs. Inhouse</h2>
<div class="overflow-x-auto mt-6">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-dark">
<th class="py-3 pr-4 text-body font-bold text-gosign-dark"></th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Co-Build</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Platforma SaaS</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Inhouse</th>
</tr>
</thead>
<tbody class="text-body text-gosign-text-light">
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Time-to-Value</td>
<td class="py-3 px-4">4-6 tygodni</td>
<td class="py-3 px-4">2-4 tygodnie</td>
<td class="py-3 px-4">6-12 miesięcy</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Dostęp do kodu źródłowego</td>
<td class="py-3 px-4">Pełny</td>
<td class="py-3 px-4">Brak dostępu</td>
<td class="py-3 px-4">Pełny</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Vendor Lock-in</td>
<td class="py-3 px-4">Brak</td>
<td class="py-3 px-4">Wysoki</td>
<td class="py-3 px-4">Brak</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Governance / Audyt</td>
<td class="py-3 px-4">Decision Layer w zestawie</td>
<td class="py-3 px-4">Zależne od platformy</td>
<td class="py-3 px-4">Trzeba zbudować</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Koszty bieżące</td>
<td class="py-3 px-4">Infrastruktura + opcjonalna konserwacja</td>
<td class="py-3 px-4">Miesięczna licencja</td>
<td class="py-3 px-4">Koszty osobowe</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Możliwość dostosowania</td>
<td class="py-3 px-4">Nieograniczona</td>
<td class="py-3 px-4">W ramach platformy</td>
<td class="py-3 px-4">Nieograniczona</td>
</tr>
</tbody>
</table>
</div>
</div>
</div>
</section>

<!-- Przykład praktyczny -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h2 font-bold text-gosign-dark">Przykład praktyczny: Przegląd zgodności w Shared Service Center</h2>
<p class="text-body-lg text-gosign-text-light mt-4">Shared Service Center sprawdza miesięcznie 120 umów z dostawcami pod kątem zgodności - ręcznie, z listami kontrolnymi w Excelu.</p>
<div class="grid grid-cols-1 sm:grid-cols-2 gap-6 mt-8">
<div class="bg-gosign-white rounded-card p-6">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-3">Przed - ręcznie</p>
<ul class="space-y-2 text-body text-gosign-text-light">
<li><strong>45 min</strong> na umowę (czytanie, lista kontrolna, dokumentacja)</li>
<li><strong>~90 godzin/miesiąc</strong> dla zespołu</li>
<li><strong>12% błędów</strong> w wykrywaniu klauzul</li>
<li><strong>Brak wersjonowania</strong> logiki przeglądu</li>
</ul>
</div>
<div class="bg-gosign-white rounded-card p-6 border-2 border-gosign-accent">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-3">Po - Co-Build Agent</p>
<ul class="space-y-2 text-body text-gosign-text-light">
<li><strong>82% autonomicznie</strong> sprawdzonych (standardowe umowy)</li>
<li><strong>~19 godzin/miesiąc</strong> (tylko wyjątki + kontrole wyrywkowe)</li>
<li><strong>&lt;2% błędów</strong> dzięki przeglądom opartym na regułach</li>
<li><strong>Decision Layer</strong> z pełnym Audit Trail</li>
</ul>
</div>
</div>
<div class="bg-gosign-white rounded-card p-4 mt-6">
<p class="text-body text-gosign-text-light"><strong>Wynik:</strong> 71 godzin zaoszczędzonych miesięcznie. Agent produktywny w 5 tygodni. Kod źródłowy, zestaw reguł i prompty u klienta. Po 14 miesiącach samodzielna eksploatacja bez wsparcia zewnętrznego.</p>
</div>
</div>
</div>
</section>

<!-- Pogłębienie w Agent Briefing -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Pogłębienie w Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nasza seria artykułów dla decydentów wdrażających AI Agents w przedsiębiorstwie.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/pl/magazyn/koszty-ai-tco-porownanie/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Koszty</p>
<p class="text-body font-semibold text-gosign-dark">Co naprawdę kosztuje AI: porównanie TCO dla przedsiębiorstw</p>
</a>
<a href="/pl/magazyn/model-agnostyk-vendor-lock-in/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Architektura</p>
<p class="text-body font-semibold text-gosign-dark">Architektura model-agnostyczna - dlaczego Vendor Lock-in przy LLM jest niebezpieczny</p>
</a>
<a href="/pl/magazyn/decision-layer-wyjasnienie/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - co to jest i dlaczego każdy Enterprise AI Agent go potrzebuje?</p>
</a>
</div>
</div>
</section>

<!-- Inne typy agentów -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Inne typy agentów</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/pl/uslugi/ai-agents/document-agents/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Specjalista</p>
<p class="text-body font-semibold text-gosign-dark">Document Agents</p>
<p class="text-body text-gosign-text-light mt-2">Czytanie, rozumienie i klasyfikacja dokumentów - z prawdziwym rozumieniem języka.</p>
</a>
<a href="/pl/uslugi/ai-agents/workflow-agents/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Koordynator</p>
<p class="text-body font-semibold text-gosign-dark">Workflow Agents</p>
<p class="text-body text-gosign-text-light mt-2">Orkiestracja procesów w wielu systemach - SAP, Comarch, SharePoint.</p>
</a>
<a href="/pl/uslugi/ai-agents/knowledge-agents/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Nosiciel wiedzy</p>
<p class="text-body font-semibold text-gosign-dark">Knowledge Agents</p>
<p class="text-body text-gosign-text-light mt-2">Odpowiadanie na pytania z zestawów reguł - ze wskazaniem źródeł i wersji reguł.</p>
</a>
</div>
</div>
</section>

--- Document Agents - Przetwarzanie Dokumentów z Decision Layer ---
> Document Agents czytają, rozumieją i przetwarzają dokumenty korporacyjne. Faktury, zwolnienia, umowy - audytowalnie, z Audit Trail.

<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="AI Agents Nawigacja">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/pl/uslugi/ai-agents/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
AI Agents
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/pl/uslugi/ai-agents/document-agents/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Document</a>
<a href="/pl/uslugi/ai-agents/workflow-agents/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Workflow</a>
<a href="/pl/uslugi/ai-agents/knowledge-agents/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Knowledge</a>
<a href="/pl/uslugi/ai-agents/co-build/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Co-Build</a>
</div>
</div>
</nav>

<!-- W skrócie -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h2 font-bold text-gosign-dark">W skrócie</h2>
<div class="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-3 gap-4 mt-6">
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">99,1% Zero-Touch</p>
<p class="text-body text-gosign-text-light mt-1">Dokumenty rutynowe przetwarzane autonomicznie - bez ręcznej korekty</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">20+ typów dokumentów</p>
<p class="text-body text-gosign-text-light mt-1">Faktury, umowy, zwolnienia lekarskie, decyzje, paragony i więcej</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Prawdziwe rozumienie</p>
<p class="text-body text-gosign-text-light mt-1">Kontekstowe rozumienie językowe zamiast dopasowywania szablonów OCR</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Decision Layer</p>
<p class="text-body text-gosign-text-light mt-1">Każda ekstrakcja z Confidence Score, wersją reguły i Audit Trail</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Agnostyczny modelowo</p>
<p class="text-body text-gosign-text-light mt-1">Claude, ChatGPT, Gemini, Llama - model wymienny w dowolnym momencie</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">SAP, Comarch, Workday</p>
<p class="text-body text-gosign-text-light mt-1">Integracja przez API - logika agenta oddzielona od systemu docelowego</p>
</div>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Definicja: Document Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Document Agent to wyspecjalizowany AI Agent do automatycznego przetwarzania dokumentów korporacyjnych. Wykorzystuje Large Language Models (LLM) do kontekstowego rozumienia językowego - nie dopasowywanie szablonów, nie sztywne reguły OCR.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Document Agent czyta dokument, rozumie jego treść i dokonuje oceny fachowej. Ta ocena jest weryfikowana przez <a href="/pl/decision-layer/" class="text-gosign-accent-text hover:underline">Decision Layer</a>, dokumentowana i zapisywana w Audit Trail.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Jak Działa Document Agent</h2>
<pre class="bg-gosign-dark text-white p-6 rounded-card overflow-x-auto text-small font-mono leading-relaxed mt-4"><code>Dokument    →  Agent czyta     →  Decision Layer sprawdza
(Faktura)      i rozumie          Kompletność, Wiarygodność,
Klasyfikacja podatkowa
│
┌────────────┴────────────┐
│                         │
Wysoka pewność           Niska pewność
Reguła jednoznaczna     lub przypadek wyjątkowy
│                         │
Propozycja               Eskalacja do
księgowania              pracownika
│                         │
Audit Trail              Audit Trail
dokumentuje              dokumentuje</code></pre>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Jakie Dokumenty Przetwarza Document Agent</h2>
<div class="mt-6 space-y-4">
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Finance:</strong> Faktury przychodzące, noty korygujące, paragony, potwierdzenia płatności, wyciągi bankowe.</p>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">HR:</strong> Zwolnienia lekarskie, umowy o pracę, aneksy do umów, zaświadczenia, świadectwa pracy.</p>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Compliance:</strong> Dokumenty podatkowe, certyfikaty, deklaracje, dokumenty audytowe.</p>
</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Decision Layer dla Dokumentów</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Każde przetwarzanie dokumentu generuje kompletny rekord decyzyjny:
</p>
<ul class="mt-6 space-y-3">
<li class="text-body-lg text-gosign-text-light"><strong>Wejście:</strong> Hash dokumentu, typ dokumentu, wyodrębnione pola</li>
<li class="text-body-lg text-gosign-text-light"><strong>Zestaw reguł:</strong> Zastosowana reguła, wersja, znacznik czasu</li>
<li class="text-body-lg text-gosign-text-light"><strong>Ocena:</strong> Confidence Score, wskaźnik ryzyka</li>
<li class="text-body-lg text-gosign-text-light"><strong>Wynik:</strong> Propozycja księgowania lub eskalacja</li>
<li class="text-body-lg text-gosign-text-light"><strong>Routing:</strong> Decyzja autonomiczna lub Human-in-the-Loop</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-4">
Document Agent nie zastępuje pracowników. Przetwarza przypadki rutynowe autonomicznie i eskaluje wyjątki do ludzi - z pełną dokumentacją. Więcej o <a href="/pl/decision-layer/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">architekturze Decision Layer</a>.
</p>
</div>
</section>

<!-- Porównanie: Document Agent vs. klasyczne rozwiązanie -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Document Agent vs. OCR vs. ręczna obsługa</h2>
<div class="overflow-x-auto mt-6">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-dark">
<th class="py-3 pr-4 text-body font-bold text-gosign-dark"></th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Document Agent</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">System OCR</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Ręczna obsługa</th>
</tr>
</thead>
<tbody class="text-body text-gosign-text-light">
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Rozumienie</td>
<td class="py-3 px-4">Kontekstowe - rozumie treść i znaczenie</td>
<td class="py-3 px-4">Rozpoznawanie znaków + dopasowywanie szablonów</td>
<td class="py-3 px-4">Pełna zdolność kognitywna</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Tekst swobodny / pismo ręczne</td>
<td class="py-3 px-4">Tak - prawdziwe rozumienie językowe</td>
<td class="py-3 px-4">Ograniczone - zawodzi przy odchyleniach</td>
<td class="py-3 px-4">Tak</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Szybkość</td>
<td class="py-3 px-4">Sekundy na dokument</td>
<td class="py-3 px-4">Sekundy, ale często wymaga korekty</td>
<td class="py-3 px-4">5-10 minut na dokument</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Skalowalność</td>
<td class="py-3 px-4">Liniowa z wolumenem</td>
<td class="py-3 px-4">Liniowa, ale ręczna przy błędach</td>
<td class="py-3 px-4">Tylko z większą liczbą pracowników</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Audit Trail</td>
<td class="py-3 px-4">Automatyczny na każdą decyzję</td>
<td class="py-3 px-4">Ograniczony</td>
<td class="py-3 px-4">Ręczny, często niekompletny</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Scenariusz praktyczny -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Praktyka: Faktury przychodzące</h2>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6 mt-6">
<p class="font-semibold text-gosign-dark text-body">Scenariusz: 500 faktur przychodzących miesięcznie</p>
<div class="grid grid-cols-1 sm:grid-cols-2 gap-6 mt-4">
<div>
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-text-light mb-2">Przed (ręcznie)</p>
<ul class="space-y-1 text-body text-gosign-text-light">
<li>8 minut na fakturę (weryfikacja, kontowanie, sprawdzanie)</li>
<li>~67 godzin miesięcznie</li>
<li>Wskaźnik błędów kontowania: 4-6%</li>
<li>Audit Trail: arkusz Excel, prowadzony ręcznie</li>
</ul>
</div>
<div>
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Po (Document Agent)</p>
<ul class="space-y-1 text-body text-gosign-text-light">
<li>99,1% przetworzonych autonomicznie (495 z 500 faktur)</li>
<li>&lt;1% eskalowanych do pracownika (~5 faktur/miesiąc)</li>
<li>98% wszystkich zapytań z nadawcą dokumentu rozwiązanych samodzielnie</li>
<li>&lt;0,5h nakładu ręcznego miesięcznie</li>
<li>Wskaźnik błędów: poniżej 0,3% (kontowanie oparte na regułach)</li>
</ul>
</div>
</div>
<p class="text-body text-gosign-text-light mt-4">
<strong>Wynik:</strong> Z 67 godzin do poniżej 30 minut miesięcznie. Agent kontuje, weryfikuje i księguje autonomicznie. Przy brakujących danych (np. numer zamówienia, centrum kosztów) agent samodzielnie kontaktuje nadawcę dokumentu - 98% tych zapytań jest rozwiązywanych bez interwencji człowieka. Tylko prawdziwe wyjątki trafiają do pracownika.
</p>
<div class="mt-4 bg-gosign-light border-l-4 border-gosign-accent rounded-card p-4">
<p class="text-small font-semibold text-gosign-dark">Human-in-the-Loop</p>
<p class="text-small text-gosign-text-light mt-1"><strong>Agent decyduje:</strong> Kontowanie, propozycja księgowania, warunki płatności, zapytania do nadawcy dokumentu.<br/><strong>Człowiek decyduje:</strong> Pierwsza akceptacja dostawcy, faktury powyżej progu zatwierdzenia, odchylenia od wartości zamówienia &gt;5%.</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Obszary Zastosowań</h2>
<div class="mt-6 space-y-6">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Finance i Księgowość</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Przetwarzanie faktur, księgowanie, weryfikacja dokumentów. Integracja z Comarch ERP i SAP FI/CO. Prekonfigurowane rozwiązanie: <a href="/pl/finance-ai-agents/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Finance AI Agents</a>.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">HR i People Operations</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Zwolnienia lekarskie, dokumenty umowne, zaświadczenia. Integracja z SAP SuccessFactors i Workday. Prekonfigurowane rozwiązanie: <a href="/pl/hr-ai-agents/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">HR AI Agents</a>.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Compliance i Audyt</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Automatyczna weryfikacja dokumentów przychodzących wobec wewnętrznych polityk i zewnętrznych regulacji (RODO). <a href="/pl/decision-layer/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Decision Layer</a> dokumentuje każdą decyzję weryfikacyjną.
</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Integracja</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Document Agents łączą się z istniejącymi systemami przez standardowe interfejsy:
</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light">SAP FI/CO, SAP S/4HANA</li>
<li class="text-body-lg text-gosign-text-light">Comarch ERP</li>
<li class="text-body-lg text-gosign-text-light">SAP SuccessFactors, Workday</li>
<li class="text-body-lg text-gosign-text-light">SharePoint, Microsoft Teams</li>
<li class="text-body-lg text-gosign-text-light">Skrzynki e-mail (IMAP/Exchange)</li>
<li class="text-body-lg text-gosign-text-light">Inne przez REST/SOAP</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-4">
Logika agenta jest oddzielona od systemu docelowego. Zmiana systemu ERP zmienia warstwę eksportu - nie agenta. Potrzebujesz agenta do procesu, którego nie obejmują trzy standardowe typy? <a href="/pl/uslugi/ai-agents/co-build/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Co-Build</a> dostarcza indywidualne agenty w 4-6 tygodni.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Inne typy agentów</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/pl/uslugi/ai-agents/workflow-agents/" class="group block border border-gosign-border rounded-card bg-gosign-white p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Koordynator</p>
<p class="text-body font-semibold text-gosign-dark">Workflow Agents</p>
<p class="text-small text-gosign-text-light mt-2">Orkiestracja procesów między systemami - SAP, Comarch, SharePoint.</p>
<span class="inline-flex items-center gap-1 mt-4 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Szczegóły <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
<a href="/pl/uslugi/ai-agents/knowledge-agents/" class="group block border border-gosign-border rounded-card bg-gosign-white p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Nośnik wiedzy</p>
<p class="text-body font-semibold text-gosign-dark">Knowledge Agents</p>
<p class="text-small text-gosign-text-light mt-2">Odpowiedzi na pytania z bazy reguł - ze źródłem i wersją reguły.</p>
<span class="inline-flex items-center gap-1 mt-4 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Szczegóły <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
<a href="/pl/uslugi/ai-agents/co-build/" class="group block border border-gosign-border rounded-card bg-gosign-white p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Indywidualne agenty</p>
<p class="text-body font-semibold text-gosign-dark">Co-Build</p>
<p class="text-small text-gosign-text-light mt-2">Twój proces, Twój agent. 4-6 tygodni do produktywnego agenta.</p>
<span class="inline-flex items-center gap-1 mt-4 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Szczegóły <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Pogłębienie w Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nasza seria artykułów fachowych dla decydentów wdrażających agentów AI.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/pl/magazyn/rag-document-intelligence-enterprise/" class="group block border border-gosign-border rounded-card bg-gosign-white p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">RAG i Document Intelligence: Jak AI rozumie Twoje dokumenty</p>
<span class="inline-flex items-center gap-1 mt-3 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Czytaj <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
<a href="/pl/magazyn/pii-anonimizacja-llm-enterprise/" class="group block border border-gosign-border rounded-card bg-gosign-white p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Anonimizacja PII dla Enterprise AI</p>
<span class="inline-flex items-center gap-1 mt-3 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Czytaj <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
<a href="/pl/magazyn/decision-layer-wyjasnienie/" class="group block border border-gosign-border rounded-card bg-gosign-white p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - czym jest i dlaczego każdy agent AI go potrzebuje?</p>
<span class="inline-flex items-center gap-1 mt-3 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Czytaj <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
</div>
</div>
</section>

--- Knowledge Agents - Odpowiedzi z Wiedzy Korporacyjnej ---
> Knowledge Agents dostarczają kontekstowe odpowiedzi z porozumień zakładowych, polityk i układów zbiorowych. Ze źródłem, wersją reguły i Audit Trail.

<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="AI Agents Nawigacja">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/pl/uslugi/ai-agents/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
AI Agents
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/pl/uslugi/ai-agents/document-agents/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Document</a>
<a href="/pl/uslugi/ai-agents/workflow-agents/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Workflow</a>
<a href="/pl/uslugi/ai-agents/knowledge-agents/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Knowledge</a>
<a href="/pl/uslugi/ai-agents/co-build/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Co-Build</a>
</div>
</div>
</nav>

<!-- W skrócie -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h2 font-bold text-gosign-dark">W skrócie</h2>
<div class="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-3 gap-4 mt-6">
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Zweryfikowane źródła</p>
<p class="text-body text-gosign-text-light mt-1">Każda odpowiedź ze źródłem, wersją reguły i datą ważności</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">5 zabezpieczeń anty-halucynacja</p>
<p class="text-body text-gosign-text-light mt-1">Retrieval-First, weryfikacja źródła, Confidence, bez spekulacji, Audit Trail</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">4 kanały</p>
<p class="text-body text-gosign-text-light mt-1">Teams Bot, SharePoint, interfejs webowy, API - tam gdzie pracują Twoi pracownicy</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">RAG Pipeline</p>
<p class="text-body text-gosign-text-light mt-1">Wersjonowana indeksacja wszystkich źródeł wiedzy z automatyczną aktualizacją</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Decision Layer</p>
<p class="text-body text-gosign-text-light mt-1">Confidence Scoring i routing - przy niepewności przekierowanie zamiast odpowiedzi</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Natychmiastowa odpowiedź</p>
<p class="text-body text-gosign-text-light mt-1">Sekundy zamiast godzin - spójnie we wszystkich lokalizacjach i strefach czasowych</p>
</div>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Definicja: Knowledge Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Knowledge Agent to wyspecjalizowany AI Agent, który dostarcza kontekstowe odpowiedzi z wiedzy korporacyjnej. Wykorzystuje pipeline RAG (Retrieval-Augmented Generation), aby znaleźć istotne informacje w zdeponowanych dokumentach i odpowiedzieć we właściwym kontekście.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Kluczowa zasada: każda odpowiedź zawiera źródło i wersję reguły. Knowledge Agent nie odpowiada na żadne pytanie bez referencji źródłowej.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Zasada: Bez Źródła Brak Odpowiedzi</h2>
<pre class="bg-gosign-dark text-white p-6 rounded-card overflow-x-auto text-small font-mono leading-relaxed mt-4"><code>Pytanie     →  Knowledge Agent    →  Decision Layer
(pracownik)    przeszukuje bazę      weryfikuje źródło
wiedzy (RAG)          i confidence
│
┌────────────┴────────────┐
│                         │
Źródło znalezione         Brak źródła lub
Confidence wysoki         sprzeczne regulacje
│                         │
Odpowiedź ze źródłem      Kieruje do
i wersją reguły           odpowiedzialnej komórki
│                         │
Audit Trail               Audit Trail</code></pre>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Wspierane Źródła Wiedzy</h2>
<div class="mt-6 space-y-4">
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">HR:</strong> Porozumienia zakładowe (Rada Zakładowa), układy zbiorowe, polityki urlopowe, regulaminy pracy.</p>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Finance:</strong> Zasady księgowania, zasady podróży służbowych, procedury zatwierdzania.</p>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Compliance:</strong> Podręczniki compliance, wytyczne ochrony danych, procesy audytowe.</p>
</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Architektoniczne Zabezpieczenie przed Halucynacją</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Knowledge Agents są skonstruowane tak, aby ryzyko halucynacji było minimalizowane architektonicznie:
</p>
<ol class="mt-6 space-y-3 list-decimal list-inside">
<li class="text-body-lg text-gosign-text-light"><strong>Retrieval-First:</strong> Agent najpierw wyszukuje odpowiednie dokumenty, zanim odpowie</li>
<li class="text-body-lg text-gosign-text-light"><strong>Weryfikacja źródła:</strong> Każde stwierdzenie musi być identyfikowalne do konkretnego źródła</li>
<li class="text-body-lg text-gosign-text-light"><strong>Confidence Score:</strong> Przy niskim confidence agent nie odpowiada, lecz kieruje do odpowiedzialnej komórki</li>
<li class="text-body-lg text-gosign-text-light"><strong>Bez spekulacji:</strong> Przy brakujących lub sprzecznych regulacjach agent kieruje do odpowiedzialnej komórki</li>
<li class="text-body-lg text-gosign-text-light"><strong>Audit Trail:</strong> Każda odpowiedź jest dokumentowana ze źródłem, wersją i confidence</li>
</ol>
</div>
</section>

<!-- Porównanie: Knowledge Agent vs. klasyczne rozwiązanie -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Knowledge Agent vs. wyszukiwarka vs. chatbot</h2>
<div class="overflow-x-auto mt-6">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-dark">
<th class="py-3 pr-4 text-body font-bold text-gosign-dark"></th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Knowledge Agent</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Wyszukiwarka korporacyjna</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Standardowy chatbot</th>
</tr>
</thead>
<tbody class="text-body text-gosign-text-light">
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Wynik</td>
<td class="py-3 px-4">Konkretna odpowiedź ze źródłem</td>
<td class="py-3 px-4">Lista dokumentów</td>
<td class="py-3 px-4">Wygenerowana odpowiedź bez gwarancji źródła</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Źródło</td>
<td class="py-3 px-4">Zawsze - z wersją i datą ważności</td>
<td class="py-3 px-4">Link do dokumentu</td>
<td class="py-3 px-4">Brak lub niewiarygodne</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Halucynacja</td>
<td class="py-3 px-4">Zablokowana architektonicznie (5 zabezpieczeń)</td>
<td class="py-3 px-4">Nie dotyczy</td>
<td class="py-3 px-4">Częsta - brak kontroli</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Przy niepewności</td>
<td class="py-3 px-4">Kieruje do odpowiedzialnej komórki</td>
<td class="py-3 px-4">Pokazuje więcej wyników</td>
<td class="py-3 px-4">Odpowiada mimo to</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Audit Trail</td>
<td class="py-3 px-4">Kompletny na każdą odpowiedź</td>
<td class="py-3 px-4">Protokół wyszukiwania</td>
<td class="py-3 px-4">Historia czatu</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Scenariusz praktyczny -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Praktyka: Zapytania HR</h2>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6 mt-6">
<p class="font-semibold text-gosign-dark text-body">Scenariusz: 200 zapytań HR miesięcznie (uprawnienia urlopowe, regulacje specjalne, porozumienia zakładowe)</p>
<div class="grid grid-cols-1 sm:grid-cols-2 gap-6 mt-4">
<div>
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-text-light mb-2">Przed (ręcznie)</p>
<ul class="space-y-1 text-body text-gosign-text-light">
<li>15 minut na zapytanie (HR wyszukuje, sprawdza regulamin, odpowiada)</li>
<li>~50 godzin miesięcznie</li>
<li>Niespójne odpowiedzi w zależności od pracownika</li>
<li>Czas oczekiwania dla pracowników: godziny do dni</li>
</ul>
</div>
<div>
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Po (Knowledge Agent)</p>
<ul class="space-y-1 text-body text-gosign-text-light">
<li>78% odpowiedzi natychmiast (156 zapytań) - sekundy zamiast godzin</li>
<li>22% eskalowanych do HR (44 złożone przypadki) - z kontekstem</li>
<li>~11 godzin miesięcznie (tylko eskalacje)</li>
<li>100% spójna interpretacja reguł</li>
</ul>
</div>
</div>
<p class="text-body text-gosign-text-light mt-4">
<strong>Wynik:</strong> 39 godzin miesięcznie zaoszczędzone. Pracownicy natychmiast otrzymują zweryfikowaną odpowiedź. HR koncentruje się na złożonych przypadkach wymagających prawdziwej oceny.
</p>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Obszary Zastosowań</h2>
<div class="mt-6 space-y-6">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">HR i People Operations</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Pytania o porozumienia zakładowe (Rada Zakładowa), uprawnienia urlopowe, regulacje specjalne, urlopy rodzicielskie, budżety szkoleniowe. Koniec z zasadą "zapytaj kogokolwiek z biura".
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Compliance i Regulacje</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Pytania o polityki wewnętrzne, wymogi regulacyjne, kontrolę eksportu, ochronę danych (RODO). Spójne odpowiedzi zamiast indywidualnej interpretacji.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Onboarding</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Nowi pracownicy natychmiast uzyskują dostęp do istotnej wiedzy korporacyjnej, bez czekania na dostępnych kolegów.
</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Integracja</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Knowledge Agents są dostępne przez następujące kanały:
</p>
<ul class="mt-4 space-y-3">
<li class="text-body-lg text-gosign-text-light"><strong>Microsoft Teams Bot</strong> - bezpośrednio w codziennej pracy</li>
<li class="text-body-lg text-gosign-text-light"><strong>Integracja z SharePoint</strong> - osadzone w intranecie</li>
<li class="text-body-lg text-gosign-text-light"><strong>Interfejs webowy</strong> - samodzielny, do złożonych zapytań</li>
<li class="text-body-lg text-gosign-text-light"><strong>API</strong> - do integracji z własnymi aplikacjami</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-4">
Baza wiedzy jest utrzymywana przez SharePoint, Confluence lub bezpośredni upload dokumentów.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Inne typy agentów</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/pl/uslugi/ai-agents/document-agents/" class="block border border-gosign-border rounded-card bg-gosign-white p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Specjalista</p>
<p class="text-body font-semibold text-gosign-dark">Document Agents</p>
<p class="text-small text-gosign-text-light mt-2">Czytanie, rozumienie i klasyfikacja dokumentów - z prawdziwym rozumieniem językowym.</p>
</a>
<a href="/pl/uslugi/ai-agents/workflow-agents/" class="block border border-gosign-border rounded-card bg-gosign-white p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Koordynator</p>
<p class="text-body font-semibold text-gosign-dark">Workflow Agents</p>
<p class="text-small text-gosign-text-light mt-2">Orkiestracja procesów między systemami - SAP, Comarch, SharePoint.</p>
</a>
<a href="/pl/uslugi/ai-agents/co-build/" class="block border border-gosign-border rounded-card bg-gosign-white p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Indywidualne agenty</p>
<p class="text-body font-semibold text-gosign-dark">Co-Build</p>
<p class="text-small text-gosign-text-light mt-2">Twój proces, Twój agent. 4-6 tygodni do produktywnego agenta.</p>
</a>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Pogłębienie w Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nasza seria artykułów fachowych dla decydentów wdrażających agentów AI.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/pl/magazyn/rag-document-intelligence-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">RAG i Document Intelligence: Jak AI rozumie Twoje dokumenty</p>
</a>
<a href="/pl/magazyn/human-in-the-loop-architektura/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Human-in-the-Loop - zasada architektury, nie checkbox</p>
</a>
<a href="/pl/magazyn/decision-layer-wyjasnienie/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - czym jest i dlaczego każdy agent AI go potrzebuje?</p>
</a>
</div>
</div>
</section>

--- Workflow Agents - Międzysystemowa Orkiestracja Procesów ---
> Workflow Agents orkiestrują procesy korporacyjne międzysystemowo. SAP, Comarch, Workday - jeden agent koordynuje. Audit Trail w zestawie.

<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="AI Agents Nawigacja">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/pl/uslugi/ai-agents/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
AI Agents
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/pl/uslugi/ai-agents/document-agents/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Document</a>
<a href="/pl/uslugi/ai-agents/workflow-agents/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Workflow</a>
<a href="/pl/uslugi/ai-agents/knowledge-agents/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Knowledge</a>
<a href="/pl/uslugi/ai-agents/co-build/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Co-Build</a>
</div>
</div>
</nav>

<!-- W skrócie -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h2 font-bold text-gosign-dark">W skrócie</h2>
<div class="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-3 gap-4 mt-6">
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">5+ systemów</p>
<p class="text-body text-gosign-text-light mt-1">SAP, Comarch, Workday, SharePoint, AD - jeden agent koordynuje wszystko</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Wstrzymywalny</p>
<p class="text-body text-gosign-text-light mt-1">Workflow zatrzymuje się gdy człowiek musi podjąć decyzję - i kontynuuje po niej</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Idempotentny</p>
<p class="text-body text-gosign-text-light mt-1">Każdy krok powtarzalny bez efektów ubocznych - bez podwójnego księgowania</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Decision Layer</p>
<p class="text-body text-gosign-text-light mt-1">W każdym punkcie decyzyjnym: autonomicznie lub Human-in-the-Loop</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Oparty na API</p>
<p class="text-body text-gosign-text-light mt-1">Bez automatyzacji GUI - stabilna integracja przez interfejsy</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Audit Trail</p>
<p class="text-body text-gosign-text-light mt-1">Każdy krok ze znacznikiem czasu, regułą, wersją i decyzją routingu</p>
</div>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Definicja: Workflow Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Workflow Agent to wyspecjalizowany AI Agent do międzysystemowej orkiestracji procesów korporacyjnych. Koordynuje zadania między wieloma systemami - włączając eskalację, logikę zatwierdzania i obsługę wyjątków.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
W odróżnieniu od RPA (Robotic Process Automation), Workflow Agent nie pracuje na interfejsach aplikacji, lecz przez API i rozumie kontekst fachowy decyzji, które koordynuje.
</p>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Przykład: Workflow Zwolnienia Lekarskiego</h2>
<pre class="bg-gosign-dark text-white p-6 rounded-card overflow-x-auto text-small font-mono leading-relaxed mt-4"><code>Wpływ           →  Document Agent     →  Decision Layer
(E-mail z          czyta zwolnienie      sprawdza Kodeks pracy
załącznikiem)     i wyodrębnia dane     art. 92 i zasady wewn.
│
┌──────────┴──────────┐
│                     │
Zgodne z regułami       Potrzebne wyjaśnienie
│                     │
Oblicz ciągłość         Pracownik HR
wynagrodzenia           jest informowany
│                     │
Propozycja              Czeka na
księgowania SAP          decyzję
│                     │
Audit Trail              Audit Trail</code></pre>
<p class="text-body-lg text-gosign-text-light mt-4">
Każdy krok jest logowany. Każda decyzja jest identyfikowalna. Przy zapytaniach lub brakujących informacjach workflow jest wstrzymywany - nie przerywany.
</p>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Zasady Orkiestracji</h2>
<ul class="mt-6 space-y-4">
<li class="text-body-lg text-gosign-text-light"><strong>Międzysystemowo:</strong> Jeden workflow może koordynować SAP, Comarch, SharePoint, e-mail i inne systemy w jednym przepływie</li>
<li class="text-body-lg text-gosign-text-light"><strong>Decyzyjnie:</strong> Workflow Agent podejmuje decyzje fachowe, nie tylko reguły jeżeli-to</li>
<li class="text-body-lg text-gosign-text-light"><strong>Wstrzymywalnie:</strong> Przy brakujących informacjach lub koniecznych decyzjach ludzkich workflow jest wstrzymywany, dokumentowany i kontynuowany po wyjaśnieniu</li>
<li class="text-body-lg text-gosign-text-light"><strong>Audytowalnie:</strong> Każdy krok tworzy wpis w Audit Trail, włącznie z czasami oczekiwania i eskalacjami</li>
<li class="text-body-lg text-gosign-text-light"><strong>Idempotentnie:</strong> Każdy krok może być ponownie wykonany bez efektów ubocznych</li>
</ul>
</div>
</section>

<!-- Porównanie: Workflow Agent vs. klasyczne rozwiązanie -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Workflow Agent vs. RPA vs. ręczna koordynacja</h2>
<div class="overflow-x-auto mt-6">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-dark">
<th class="py-3 pr-4 text-body font-bold text-gosign-dark"></th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Workflow Agent</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Bot RPA</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Ręczna koordynacja</th>
</tr>
</thead>
<tbody class="text-body text-gosign-text-light">
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Sterowanie</td>
<td class="py-3 px-4">API + decyzje fachowe</td>
<td class="py-3 px-4">Kliknięcia GUI na interfejsach</td>
<td class="py-3 px-4">E-mail, telefon, tickety</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Stabilność</td>
<td class="py-3 px-4">Kontrakty API - niezależne od zmian UI</td>
<td class="py-3 px-4">Zawodzi przy zmianach UI</td>
<td class="py-3 px-4">Zależna od osób</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Zdolność decyzyjna</td>
<td class="py-3 px-4">Decyzje fachowe na podstawie zestawów reguł</td>
<td class="py-3 px-4">Tylko reguły jeżeli-to</td>
<td class="py-3 px-4">Pełna zdolność decyzyjna</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Przerwanie</td>
<td class="py-3 px-4">Wstrzymuje, czeka, kontynuuje</td>
<td class="py-3 px-4">Przerywa - konieczny restart</td>
<td class="py-3 px-4">Czeka - często bez dokumentacji</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Audit Trail</td>
<td class="py-3 px-4">Automatyczny na każdy krok</td>
<td class="py-3 px-4">Oparty na zrzutach ekranu</td>
<td class="py-3 px-4">Ręczny, niekompletny</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Scenariusz praktyczny -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Praktyka: Proces onboardingu</h2>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6 mt-6">
<p class="font-semibold text-gosign-dark text-body">Scenariusz: 20 nowych pracowników miesięcznie</p>
<div class="grid grid-cols-1 sm:grid-cols-2 gap-6 mt-4">
<div>
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-text-light mb-2">Przed (ręcznie)</p>
<ul class="space-y-1 text-body text-gosign-text-light">
<li>3 dni robocze na onboarding</li>
<li>5 systemów aktualizowanych ręcznie (SAP, AD, e-mail, czas pracy, kontrola dostępu)</li>
<li>Wskaźnik błędów: 12% (brakujące uprawnienia, błędne centrum kosztów)</li>
<li>Nakład HR: 60 godzin miesięcznie</li>
</ul>
</div>
<div>
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Po (Workflow Agent)</p>
<ul class="space-y-1 text-body text-gosign-text-light">
<li>4 godziny na onboarding (włącznie z ręcznymi zatwierdzeniami)</li>
<li>5 systemów provisionowanych automatycznie przez API</li>
<li>Wskaźnik błędów: poniżej 2% (przypisanie oparte na regułach)</li>
<li>Nakład HR: 15 godzin miesięcznie</li>
</ul>
</div>
</div>
<p class="text-body text-gosign-text-light mt-4">
<strong>Wynik:</strong> 75% mniej nakładu pracy, 85% mniej błędów. Workflow Agent koordynuje wszystkie systemy i wstrzymuje się tylko tam, gdzie konieczne jest ludzkie zatwierdzenie - z pełnym Audit Trail.
</p>
</div>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Obszary Zastosowań</h2>
<div class="mt-6 space-y-6">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Procesy HR</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Onboarding (umowa, provisionowanie IT, wdrożenie), zwolnienia lekarskie, zmiany umów, procesy odejścia. Orkiestracja przez SAP SuccessFactors, Workday, Active Directory i e-mail.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Procesy Finance</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Wpływ faktur, weryfikacja, księgowanie, zatwierdzanie, realizacja. Orkiestracja przez Comarch ERP, SAP FI/CO i interfejsy bankowe.
</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Procesy Compliance</h3>
<p class="text-body-lg text-gosign-text-light mt-2">
Automatyczna weryfikacja wobec polityk, eskalacja przy odchyleniach, dokumentacja w Audit Trail. Zgodność z RODO zapewniona architektonicznie.
</p>
</div>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Decision Layer w Workflow</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Każdy krok workflow, który zawiera decyzję, jest routowany przez Decision Layer:
</p>
<ul class="mt-6 space-y-3">
<li class="text-body-lg text-gosign-text-light"><strong>Sprawdzenie fachowe:</strong> Sprawdzenie zestawu reguł na każdym kroku decyzyjnym</li>
<li class="text-body-lg text-gosign-text-light"><strong>Routing:</strong> Autonomiczna kontynuacja lub eskalacja do człowieka</li>
<li class="text-body-lg text-gosign-text-light"><strong>Dokumentacja:</strong> Kompletny rekord decyzyjny na każdym kroku</li>
<li class="text-body-lg text-gosign-text-light"><strong>Wersjonowanie:</strong> Każda zastosowana reguła z wersją i znacznikiem czasu</li>
</ul>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Integracja</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Workflow Agents łączą istniejące systemy przez standardowe interfejsy:
</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light">SAP FI/CO, SAP S/4HANA, SAP SuccessFactors</li>
<li class="text-body-lg text-gosign-text-light">Workday</li>
<li class="text-body-lg text-gosign-text-light">Comarch ERP</li>
<li class="text-body-lg text-gosign-text-light">SharePoint, Microsoft Teams (via Microsoft Graph)</li>
<li class="text-body-lg text-gosign-text-light">Active Directory / Azure AD</li>
<li class="text-body-lg text-gosign-text-light">E-mail (IMAP/Exchange)</li>
<li class="text-body-lg text-gosign-text-light">Inne przez REST/SOAP</li>
</ul>
</div>
</section>

<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Inne typy agentów</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/pl/uslugi/ai-agents/document-agents/" class="block border border-gosign-border rounded-card bg-gosign-white p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Specjalista</p>
<p class="text-body font-semibold text-gosign-dark">Document Agents</p>
<p class="text-small text-gosign-text-light mt-2">Czytanie, rozumienie i klasyfikacja dokumentów - z prawdziwym rozumieniem językowym.</p>
</a>
<a href="/pl/uslugi/ai-agents/knowledge-agents/" class="block border border-gosign-border rounded-card bg-gosign-white p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Nośnik wiedzy</p>
<p class="text-body font-semibold text-gosign-dark">Knowledge Agents</p>
<p class="text-small text-gosign-text-light mt-2">Odpowiedzi na pytania z bazy reguł - ze źródłem i wersją reguły.</p>
</a>
<a href="/pl/uslugi/ai-agents/co-build/" class="block border border-gosign-border rounded-card bg-gosign-white p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Indywidualne agenty</p>
<p class="text-body font-semibold text-gosign-dark">Co-Build</p>
<p class="text-small text-gosign-text-light mt-2">Twój proces, Twój agent. 4-6 tygodni do produktywnego agenta.</p>
</a>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Pogłębienie w Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nasza seria artykułów fachowych dla decydentów wdrażających agentów AI.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/pl/magazyn/orkiestracja-agentow-platformy/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">Orkiestracja agentow: Trigger.dev, n8n, Camunda</p>
</a>
<a href="/pl/magazyn/integracja-ai-krajobraz-it/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">Integracja AI z istniejacym krajobrazem IT - SAP, Comarch, Workday</p>
</a>
<a href="/pl/magazyn/decision-layer-wyjasnienie/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - czym jest i dlaczego każdy agent AI go potrzebuje?</p>
</a>
</div>
</div>
</section>

--- AI Agents dla Procesów Korporacyjnych ---
> Document Agents, Workflow Agents i Knowledge Agents. Wyspecjalizowane AI Agents z Decision Layer, Audit Trail i Human-in-the-Loop.

<!-- W skrócie -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h2 font-bold text-gosign-dark">W skrócie</h2>
<div class="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-3 gap-4 mt-6">
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">3 typy agentów</p>
<p class="text-body text-gosign-text-light mt-1">Document, Workflow, Knowledge - każdy z własnym Decision Layer</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">4-6 tygodni</p>
<p class="text-body text-gosign-text-light mt-1">Od Discover do produkcyjnego PoC w infrastrukturze klienta</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">85-92% Zero-Touch</p>
<p class="text-body text-gosign-text-light mt-1">Przypadki rutynowe przetwarzane autonomicznie - wyjątki eskalowane do ludzi</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">7+ LLM</p>
<p class="text-body text-gosign-text-light mt-1">Agnostycyzm modelowy: Claude, ChatGPT, Gemini, Llama, Mistral, DeepSeek</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">Pełny kod źródłowy</p>
<p class="text-body text-gosign-text-light mt-1">Bez SaaS, bez vendor lock-in - klient posiada kod, prompty, zestawy reguł</p>
</div>
<div class="bg-gosign-light rounded-card p-4">
<p class="text-h3 font-bold text-gosign-dark">EU AI Act ready</p>
<p class="text-body text-gosign-text-light mt-1">Audit Trail, Human-in-the-Loop, ograniczenia z porozumień zakładowych</p>
</div>
</div>
</div>
</div>
</section>

<!-- Governance-First Intro -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Zbudować agenta jest łatwo. Uczynić go Enterprise-ready - nie.</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Workflow Agents można prototypować w kilka dni. Prawdziwy problem zaczyna się potem: Czy decyzja agenta jest audytowalna? Czy spełnia wymagania EU AI Act? Czy Rada Zakładowa może prześledzić, według jakich reguł agent podejmuje decyzje?
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Dokładnie tu zaczynamy. Nie od budowy agenta - lecz od warstwy governance, która czyni go produkcyjnym, weryfikowalnym i certyfikowalnym. Procesy korporacyjne opierają się na wiedzy ukrytej: układy zbiorowe, porozumienia zakładowe, logika księgowa. AI Agent strukturyzuje te decyzje, dokumentuje je i czyni odtwarzalnymi - we wszystkich lokalizacjach i u wszystkich operatorów.
</p>
</div>
</div>
</section>

<!-- Trzy typy agentów: Przegląd + Tabela porównawcza -->
<section id="typy-agentow" class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Trzy typy agentów</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Każdy proces biznesowy można rozłożyć na trzy zadania: zrozumienie dokumentów, koordynacja procesów i udostępnianie wiedzy. Do tego służą trzy wyspecjalizowane typy agentów - każdy z własnym Decision Layer i własnym Audit Trail.
</p>
</div>
<img src="/images/diagrams/agent-types-overview-pl.svg" alt="Trzy typy agentów: Document Agent (Specjalista), Workflow Agent (Koordynator), Knowledge Agent (Ekspert wiedzy)" class="w-full max-w-3xl mx-auto mt-8 mb-8" width="1200" height="400" loading="lazy" />
<div class="max-w-narrow">
<div class="overflow-x-auto mt-4">
<table class="w-full text-left border-collapse">
<thead>
<tr class="border-b-2 border-gosign-dark">
<th class="py-3 pr-4 text-body font-bold text-gosign-dark"></th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Document Agent</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Workflow Agent</th>
<th class="py-3 px-4 text-body font-bold text-gosign-dark">Knowledge Agent</th>
</tr>
</thead>
<tbody class="text-body text-gosign-text-light">
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Rola</td>
<td class="py-3 px-4">Specjalista</td>
<td class="py-3 px-4">Koordynator</td>
<td class="py-3 px-4">Ekspert wiedzy</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Zadanie</td>
<td class="py-3 px-4">Czytanie, rozumienie, klasyfikacja dokumentów</td>
<td class="py-3 px-4">Orkiestracja procesów ponad granicami systemów</td>
<td class="py-3 px-4">Odpowiadanie na pytania z zestawów reguł</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Zastępuje</td>
<td class="py-3 px-4">OCR + dopasowanie szablonów</td>
<td class="py-3 px-4">RPA + ręczne workflow</td>
<td class="py-3 px-4">Wyszukiwarka + chatbot</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-semibold text-gosign-dark">Przykład</td>
<td class="py-3 px-4">Zwolnienie lekarskie - ekstrakcja i klasyfikacja</td>
<td class="py-3 px-4">Onboarding przez SAP, AD i e-mail</td>
<td class="py-3 px-4">Uprawnienia urlopowe z podaniem źródła</td>
</tr>
</tbody>
</table>
</div>
</div>

<!-- Typ agenta 1: Document Agents -->
<div class="max-w-narrow mt-12">
<div class="flex items-start gap-4">
<span class="text-5xl font-bold text-gosign-accent/20 leading-none before:content-['01']" aria-hidden="true"></span>
<div>
<h3 class="text-h2 font-bold text-gosign-dark">Document Agents</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Specjalista: rozumie dokumenty z prawdziwym rozumieniem językowym. Bez rozpoznawania szablonów - kontekstowe zrozumienie faktur, zwolnień lekarskich, umów. Decision Layer ocenia każdą ekstrakcję i przy niskiej pewności przekierowuje do specjalisty.</p>
<div class="mt-4 bg-gosign-light border-l-4 border-gosign-accent rounded-card p-4">
<p class="text-small font-semibold text-gosign-dark">Human-in-the-Loop</p>
<p class="text-small text-gosign-text-light mt-1"><strong>Agent decyduje:</strong> Standardowe dokumenty z wysoką pewnością (faktury z jednoznaczną kontacją, zwolnienia z wyraźnym okresem).<br/><strong>Człowiek decyduje:</strong> Niejednoznaczne dokumenty, odbiegające kwoty, nowi dostawcy, dokumenty z klauzulami swobodnymi. Agent przygotowuje i rekomenduje - ostateczna decyzja należy do pracownika.</p>
</div>
</div>
</div>
<p class="mt-4">
<a href="/pl/uslugi/ai-agents/document-agents/" class="inline-flex items-center text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">
Document Agents w szczegółach
<svg class="w-5 h-5 ml-2" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg>
</a>
</p>
</div>

<!-- Typ agenta 2: Workflow Agents -->
<div class="max-w-narrow mt-10">
<div class="flex items-start gap-4">
<span class="text-5xl font-bold text-gosign-accent/20 leading-none before:content-['02']" aria-hidden="true"></span>
<div>
<h3 class="text-h2 font-bold text-gosign-dark">Workflow Agents</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Koordynator: orkiestruje procesy międzysystemowo. SAP, Comarch, SharePoint, Active Directory - jeden agent koordynuje cały przebieg przez API. Przy pytaniach workflow się zatrzymuje, człowiek decyduje, a agent wznawia dokładnie w tym miejscu.</p>
<div class="mt-4 bg-gosign-light border-l-4 border-gosign-accent rounded-card p-4">
<p class="text-small font-semibold text-gosign-dark">Human-in-the-Loop</p>
<p class="text-small text-gosign-text-light mt-1"><strong>Agent decyduje:</strong> Routing, księgowania systemowe, aktualizacje statusów, powiadomienia - wszystko według zdefiniowanych reguł w Decision Layer.<br/><strong>Człowiek decyduje:</strong> Decyzje personalne (zatrudnienie, zwolnienie, przeniesienie), zatwierdzenia budżetowe powyżej progów, wyjątki od porozumień zakładowych. Workflow wstrzymuje się do momentu podjęcia decyzji przez człowieka.</p>
</div>
</div>
</div>
<p class="mt-4">
<a href="/pl/uslugi/ai-agents/workflow-agents/" class="inline-flex items-center text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">
Workflow Agents w szczegółach
<svg class="w-5 h-5 ml-2" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg>
</a>
</p>
</div>

<!-- Typ agenta 3: Knowledge Agents -->
<div class="max-w-narrow mt-10">
<div class="flex items-start gap-4">
<span class="text-5xl font-bold text-gosign-accent/20 leading-none before:content-['03']" aria-hidden="true"></span>
<div>
<h3 class="text-h2 font-bold text-gosign-dark">Knowledge Agents</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Ekspert wiedzy: odpowiada na pytania z wiedzy korporacyjnej - porozumienia zakładowe, układy zbiorowe, polityki. Każda odpowiedź ze źródłem i wersją reguły. Bez zweryfikowanego źródła brak odpowiedzi - architektura zapobiega halucynacji.</p>
<div class="mt-4 bg-gosign-light border-l-4 border-gosign-accent rounded-card p-4">
<p class="text-small font-semibold text-gosign-dark">Human-in-the-Loop</p>
<p class="text-small text-gosign-text-light mt-1"><strong>Agent decyduje:</strong> Standardowe zapytania z jednoznaczną bazą źródłową (wymiar urlopu, okres wypowiedzenia, kompetencje).<br/><strong>Człowiek decyduje:</strong> Pytania interpretacyjne przy sprzecznych zestawach reguł, oceny indywidualnych przypadków, pytania dotyczące toczących się negocjacji. W razie niepewności agent nie odpowiada, lecz eskaluje z kontekstem do odpowiedzialnego eksperta.</p>
</div>
</div>
</div>
<p class="mt-4">
<a href="/pl/uslugi/ai-agents/knowledge-agents/" class="inline-flex items-center text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">
Knowledge Agents w szczegółach
<svg class="w-5 h-5 ml-2" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg>
</a>
</p>
</div>
</div>
</section>

<!-- Współdziałanie: System Multi-Agent -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Współdziałanie: trzej agenci, jeden proces</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
W praktyce trzy typy agentów współpracują ze sobą. Workflow Agent orkiestruje cały proces i wywołuje Document Agents oraz Knowledge Agents jako specjalistów.
</p>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6 mt-6">
<p class="font-semibold text-gosign-dark text-body">Przykład: Zwolnienie lekarskie End-to-End</p>
<ol class="mt-3 space-y-2 text-body text-gosign-text-light list-decimal list-inside">
<li><strong>Document Agent</strong> rozpoznaje zwolnienie lekarskie w skrzynce e-mail, wyodrębnia imię, okres i kod diagnozy.</li>
<li><strong>Workflow Agent</strong> sprawdza w systemie HR: Czy to trzecie zgłoszenie w ciągu sześciu miesięcy?</li>
<li><strong>Knowledge Agent</strong> zostaje wywołany: "Od jakiego progu obowiązuje procedura reintegracji zawodowej zgodnie z aktualnym układem zbiorowym?"</li>
<li><strong>Workflow Agent</strong> ocenia odpowiedzi: próg nie został osiągnięty - proces standardowy.</li>
<li><strong>Decision Layer</strong> weryfikuje ograniczenia z porozumienia zakładowego i układu zbiorowego - obliczenie wynagrodzenia chorobowego.</li>
<li><strong>Workflow Agent</strong> tworzy propozycję księgowania w SAP, informuje menedżera HR, dokumentuje w Audit Trail.</li>
</ol>
<p class="text-body text-gosign-text-light mt-3">
Sześć kroków, trzy typy agentów, trzy systemy - jeden ciągły Audit Trail.
</p>
</div>
</div>
</div>
</section>

<!-- Mid-Page CTA -->
<section class="py-12 bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 text-center">
<p class="text-h2 font-bold text-white">Który typ agenta pasuje do Twojego procesu?</p>
<p class="text-body-lg text-white/80 mt-2">30 minut. Twój proces. Konkretna rekomendacja.</p>
<a href="/pl/kontakt/" class="inline-block mt-6 px-8 py-3 bg-gosign-accent-btn text-white font-semibold rounded-card hover:bg-gosign-accent-btn-hover transition-colors">Umów spotkanie</a>
</div>
</section>

<!-- Specjalistyczne rozwiązania agentowe -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Specjalistyczne rozwiązania agentowe</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Document, Workflow i Knowledge Agents to elementy składowe. Dla HR i Finance oferujemy prekonfigurowane rozwiązania z branżowymi zestawami reguł. Dla innych obszarów rozwijamy indywidualnych agentów w modelu Co-Build.
</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-4 gap-6 mt-8 max-w-content">
<a href="/pl/hr-ai-agents/" class="group block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">HR & People Operations</p>
<p class="text-body font-semibold text-gosign-dark">HR AI Agents</p>
<p class="text-body text-gosign-text-light mt-2">6 produktów agentowych: Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Zgodność z Radą Zakładową i układami zbiorowymi.</p>
<p class="text-small text-gosign-accent-text mt-2">Oceń 48 agentów w Assessment &rarr;</p>
<span class="inline-flex items-center gap-1 mt-2 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Przegląd <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
<a href="/pl/finance-ai-agents/" class="group block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Finance & Accounting</p>
<p class="text-body font-semibold text-gosign-dark">Finance AI Agents</p>
<p class="text-body text-gosign-text-light mt-2">Przetwarzanie dokumentów, kontowanie, logika amortyzacji, korekty księgowe. Integracja z SAP i systemami księgowymi.</p>
<p class="text-small text-gosign-accent-text mt-2">Oceń 49 agentów w Assessment &rarr;</p>
<span class="inline-flex items-center gap-1 mt-2 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Przegląd <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
<a href="/pl/uslugi/ai-agents/co-build/" class="group block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Indywidualni agenci</p>
<p class="text-body font-semibold text-gosign-dark">Co-Build</p>
<p class="text-body text-gosign-text-light mt-2">Twój proces, Twój agent. 4-6 tygodni od Discover do produkcyjnego agenta z dostępem do kodu źródłowego.</p>
<span class="inline-flex items-center gap-1 mt-4 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Szczegóły <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
<a href="/pl/kontakt/" class="group block bg-gosign-dark rounded-card p-6 hover:bg-gosign-dark/90 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-white/60 mb-2">Następny krok</p>
<p class="text-body font-semibold text-white">Umów spotkanie</p>
<p class="text-body text-white/80 mt-2">30 minut. Twój przypadek użycia. Konkretna rekomendacja, który typ agenta pasuje.</p>
<span class="inline-flex items-center gap-1 mt-4 text-small font-semibold text-white/60 group-hover:text-white transition-colors">Umów spotkanie <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
</div>
</div>
</section>

<!-- Dla kogo -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Dla kogo</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
AI Agents dotyczą różnych interesariuszy. Każdy ma inne pytania.
</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-4 gap-6 mt-8 max-w-content">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">CHRO / VP HR</p>
<p class="text-body text-gosign-text-light mt-2">Automatyzacja procesów HR zgodna z Radą Zakładową - Payroll, Leave, Recruiting - z pełnym Audit Trail i zgodnością z układami zbiorowymi.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">CFO / Finance Lead</p>
<p class="text-body text-gosign-text-light mt-2">Automatyczne przetwarzanie dokumentów, kontowanie i uzgadnianie kont - spójnie we wszystkich lokalizacjach, audytowalne dla biegłych rewidentów.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Rada Zakładowa</p>
<p class="text-body text-gosign-text-light mt-2">Transparentność każdej decyzji agenta. Decision Layer mapuje porozumienia zakładowe jako jawne ograniczenia. Rada Zakładowa posiada prawa konsultacyjne. Human-in-the-Loop tam, gdzie to istotne.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">CTO / IT Lead</p>
<p class="text-body text-gosign-text-light mt-2">Architektura agnostyczna modelowo. Integracja API z SAP, Comarch, Workday. Bez vendor lock-in, pełny dostęp do kodu źródłowego.</p>
</div>
</div>
</div>
</section>

<!-- Decision Layer -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Decision Layer</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Decision Layer rozkłada każdy proces biznesowy na pojedyncze kroki decyzyjne i definiuje dla każdego kroku: człowiek, zestaw reguł lub AI. Każda decyzja jest dokumentowana - możliwa do prześledzenia dla audytorów, Rady Zakładowej i wewnętrznej rewizji.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Dla każdego typu agenta inaczej: przy Document Agents weryfikuje jakość ekstrakcji. Przy Workflow Agents steruje routingiem. Przy Knowledge Agents zapobiega halucynacji.
</p>
<p class="mt-4">
<a href="/pl/decision-layer/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Decision Layer w szczegółach</a>
</p>
</div>
</div>
</section>

<!-- Integracja + Agnostycyzm modelowy -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Integracja i agnostycyzm modelowy</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
AI Agents nie zastępują istniejących systemów. SAP pozostaje ERP. Workday pozostaje HCM. Comarch pozostaje systemem księgowym. Logika agenta jest oddzielona od systemu docelowego.
</p>
<div class="grid grid-cols-2 sm:grid-cols-3 gap-3 mt-6">
<div class="bg-gosign-white rounded-card px-4 py-3 text-body text-gosign-text-light">SAP FI/CO, S/4HANA</div>
<div class="bg-gosign-white rounded-card px-4 py-3 text-body text-gosign-text-light">SAP SuccessFactors</div>
<div class="bg-gosign-white rounded-card px-4 py-3 text-body text-gosign-text-light">Workday</div>
<div class="bg-gosign-white rounded-card px-4 py-3 text-body text-gosign-text-light">Comarch</div>
<div class="bg-gosign-white rounded-card px-4 py-3 text-body text-gosign-text-light">SharePoint, Teams</div>
<div class="bg-gosign-white rounded-card px-4 py-3 text-body text-gosign-text-light">Active Directory</div>
</div>
<p class="text-body-lg text-gosign-text-light mt-6">
Architektura nie jest powiązana z jednym LLM: Claude, ChatGPT, Gemini, Llama, Mistral, DeepSeek - modele są wymienne bez zmiany logiki biznesowej. Bez vendor lock-in.
</p>
</div>
</div>
</section>

<!-- Wpływ biznesowy + Własność -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Wpływ biznesowy</h2>
<ul class="mt-6 space-y-3">
<li class="text-body-lg text-gosign-text-light">Przypadki rutynowe przetwarzane autonomicznie - z kompletną dokumentacją</li>
<li class="text-body-lg text-gosign-text-light">Spójna interpretacja reguł we wszystkich lokalizacjach</li>
<li class="text-body-lg text-gosign-text-light">Każda decyzja identyfikowalna dla audytorów i Rady Zakładowej</li>
<li class="text-body-lg text-gosign-text-light">Skalowalne bez proporcjonalnego wzrostu personelu</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-6">
Pełny dostęp do kodu źródłowego, wszystkich promptów i zestawów reguł. Po 12-18 miesiącach klient operuje samodzielnie. Bez abonamentu SaaS, bez platform lock-in.
</p>
</div>
</div>
</section>

<!-- Pogłębienie -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Pogłębienie w Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nasza seria artykułów fachowych dla decydentów wdrażających agentów AI.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/pl/magazyn/agenci-ai-enterprise-przewodnik/" class="group block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors bg-gosign-white">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">AI Agents</p>
<p class="text-body font-semibold text-gosign-dark">Od chatbotów do agentów AI: MCP, A2A i systemy Multi-Agent</p>
<span class="inline-flex items-center gap-1 mt-3 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Czytaj <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
<a href="/pl/magazyn/orkiestracja-agentow-platformy/" class="group block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors bg-gosign-white">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">Orkiestracja agentów: Trigger.dev, n8n, Camunda i alternatywy</p>
<span class="inline-flex items-center gap-1 mt-3 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Czytaj <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
<a href="/pl/magazyn/decision-layer-wyjasnienie/" class="group block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors bg-gosign-white">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - czym jest i dlaczego każdy agent AI go potrzebuje?</p>
<span class="inline-flex items-center gap-1 mt-3 text-small font-semibold text-gosign-accent-text group-hover:text-gosign-accent-hover transition-colors">Czytaj <svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7"/></svg></span>
</a>
</div>
</div>
</section>

--- Document Intelligence - PII, Zaciemnianie Umów, Rozpoznawanie Podpisów ---
> Przetwarzanie dokumentów z AI zgodnie z RODO. Anonimizacja PII, zaciemnianie umów, rozpoznawanie podpisów - sterowane przez Decision Layer.

<!-- Problem -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Problem: Dane osobowe w każdym dokumencie</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Firmy chcą przetwarzać dokumenty z AI - analizować umowy, klasyfikować faktury, odpytywać polityki. Ale każdy dokument zawiera dane osobowe: nazwiska, wynagrodzenia, numery PESEL, adresy, numery rachunków bankowych, podpisy.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Przesyłanie tych danych do modelu językowego - nawet hostowanego lokalnie - bez ochrony narusza zasadę minimalizacji danych wymaganą przez RODO. Porozumienia zakładowe ograniczają przetwarzanie danych pracowniczych. Tajemnice handlowe w umowach nie mogą trafić do osób trzecich.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Dotychczasowe rozwiązania są niewystarczające: ręczne zaciemnianie w Adobe Acrobat jest czasochłonne, podatne na błędy i często tylko kosmetyczne - tekst pozostaje dostępny pod czarnymi paskami. Alternatywą jest rezygnacja z przetwarzania AI dokumentów wrażliwych, co eliminuje większość korzyści produktywności.
</p>
</div>
</div>
</section>

<!-- Trzy Capabilities -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">Trzy Capabilities</h2>
<div class="grid grid-cols-1 md:grid-cols-3 gap-6">
<div class="bg-white rounded-card p-6 border border-gosign-border">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Anonimizacja PII</h3>
<p class="text-body text-gosign-text-light">Automatyczne rozpoznawanie i pseudonimizacja danych osobowych. Nazwiska, adresy, IBAN-y, numery podatkowe, daty urodzenia. Roundtrip: pseudonimizacja przed LLM, re-anonimizacja po przetworzeniu. RODO by Design.</p>
</div>
<div class="bg-white rounded-card p-6 border border-gosign-border">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Zaciemnianie Umów</h3>
<p class="text-body text-gosign-text-light">Inteligentne zaciemnianie umów - zależne od odbiorcy. Klient widzi inne pola niż audytor. Matryca zaciemniania konfigurowana na odbiorcę. Fizycznie bezpieczne: dokument jest renderowany od nowa.</p>
</div>
<div class="bg-white rounded-card p-6 border border-gosign-border">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Rozpoznawanie Podpisów</h3>
<p class="text-body text-gosign-text-light">Automatyczne wykrywanie podpisów i porównanie z podpisami referencyjnymi. Nie tylko obecność, ale również jakość dopasowania. Anomalie są eskalowane do człowieka - system nigdy nie twierdzi, że podpis jest autentyczny.</p>
</div>
</div>
</div>
</section>

<!-- Anonimizacja PII Szczegóły -->
<section id="pii-anonimizacja" class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Anonimizacja PII: Roundtrip-Pseudonimizacja dla LLM-Input</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Większość narzędzi PII na rynku to jednokierunkowe zaciemnianie - usuwają dane. Do przetwarzania modelami językowymi to nie wystarcza. Gdy agent ma analizować umowę, potrzebuje kontekstu: "Pracownik X ma wynagrodzenie Y w lokalizacji Z." Bez tego kontekstu model nie może dostarczyć sensownej oceny.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Rozwiązanie Gosign to roundtrip-pseudonimizacja: dane są pseudonimizowane przed modelem, przetwarzane przez model i re-anonimizowane w wyniku. Model widzi tylko pseudonimy. Wynik zawiera prawdziwe dane.
</p>

<pre class="bg-gosign-dark text-white p-6 rounded-card overflow-x-auto text-small font-mono leading-relaxed mt-6"><code>┌─────────────┐     ┌──────────────────┐     ┌─────────────┐     ┌──────────────────┐     ┌─────────────┐
│  Dokument   │     │  Wykrywanie PII  │     │  Pseudo-     │     │  Model językowy  │     │  Re-Mapping │
│  (Oryginał) │────▶│  i klasyfi-      │────▶│  nimizacja   │────▶│  przetwarza      │────▶│  Pseudonimy │
│             │     │  kacja           │     │              │     │  tylko pseudonimy │     │  → dane     │
└─────────────┘     └──────────────────┘     └──────────────┘     └──────────────────┘     └─────────────┘
│                        │                                            │
▼                        ▼                                            ▼
┌──────────────┐         ┌──────────────┐                              ┌──────────────┐
│  Decision    │         │  Tabela      │                              │  Wynik       │
│  Layer:      │         │  mapowania   │◀─────────────────────────────│  z prawdzi-  │
│  Co jest     │         │  (pozostaje  │   Odwrotne mapowanie         │  wymi danymi │
│  anonimiz.   │         │  lokalnie)   │                              └──────────────┘
└──────────────┘         └──────────────┘</code></pre>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">Kroki decyzyjne w procesie PII</h3>
<div class="mt-4 overflow-x-auto">
<table class="w-full text-body text-gosign-text-light border-collapse">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="text-left py-2 pr-4 font-bold text-gosign-dark">Mikro-decyzja</th>
<th class="text-left py-2 pr-4 font-bold text-gosign-dark">Kto decyduje</th>
<th class="text-left py-2 font-bold text-gosign-dark">Dlaczego</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Zdefiniować kategorie PII</td><td class="py-2 pr-4">Człowiek + Zestaw reguł</td><td class="py-2">Wymagania RODO, porozumienie zakładowe, reguły klienta</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Wykryć PII w dokumencie</td><td class="py-2 pr-4">AI (NER + wzorce)</td><td class="py-2">Named Entity Recognition + wzorce regułowe</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Zweryfikować fałszywe pozytywy</td><td class="py-2 pr-4">AI, przy niepewności Człowiek</td><td class="py-2">Confidence Routing - "Kowalski" jako nazwisko czy firma?</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Przypisać pseudonimy</td><td class="py-2 pr-4">Automatycznie</td><td class="py-2">Spójne mapowanie, "Osoba_A" zamiast "Jan Kowalski"</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Wysłać pseudonimizowany dokument do modelu</td><td class="py-2 pr-4">Automatycznie</td><td class="py-2">Brak decyzji, czyste przekazanie</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Re-anonimizować wynik</td><td class="py-2 pr-4">Automatycznie</td><td class="py-2">Odwrotne zastosowanie tabeli mapowania</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Audyt: co zostało zanonimizowane</td><td class="py-2 pr-4">Automatycznie</td><td class="py-2">Dowód RODO w Audit Trail</td></tr>
</tbody>
</table>
</div>
<p class="text-body-lg text-gosign-text-light mt-4">
Tabela mapowania (pseudonim → prawdziwe dane) nigdy nie opuszcza warstwy pre-processingu. Jest usuwana po zakończeniu przetwarzania - lub przechowywana przez zdefiniowany okres, w zależności od konfiguracji. Model językowy w żadnym momencie nie widzi danych osobowych.
</p>
</div>
</div>
</section>

<!-- Zaciemnianie Umów Szczegóły -->
<section id="zaciemnianie-umow" class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Zaciemnianie Umów: Na Podstawie Reguł, Zależne od Odbiorcy, Fizyczne</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Umowy regularnie muszą być udostępniane w zaciemnionej formie - biegłym rewidentom, potencjalnym nabywcom przy due diligence, Radzie Zakładowej, zewnętrznym doradcom. Dziś robi to ktoś ręcznie. To zajmuje godziny na umowę, jest podatne na błędy, a zaciemnianie jest często tylko kosmetyczne: tekst pozostaje dostępny pod czarnymi paskami. Często niedoceniany wyciek danych.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Rozwiązanie Gosign: Document Agent rozpoznaje strukturę umowy - strony, kwoty, terminy, klauzule, podpisy. Decision Layer definiuje zaciemnianie zależne od odbiorcy:
</p>

<div class="mt-6 overflow-x-auto">
<table class="w-full text-body text-gosign-text-light border-collapse">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="text-left py-2 pr-4 font-bold text-gosign-dark">Element umowy</th>
<th class="text-left py-2 pr-4 font-bold text-gosign-dark">Rada Zakładowa</th>
<th class="text-left py-2 pr-4 font-bold text-gosign-dark">Due Diligence</th>
<th class="text-left py-2 pr-4 font-bold text-gosign-dark">Zewnętrzny doradca</th>
<th class="text-left py-2 font-bold text-gosign-dark">Biegły rewident</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Strony umowy (nazwiska)</td><td class="py-2 pr-4">✓ Widoczne</td><td class="py-2 pr-4">✗ Zaciemnione</td><td class="py-2 pr-4">✗ Zaciemnione</td><td class="py-2">✓ Widoczne</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Wartości umowy / kwoty</td><td class="py-2 pr-4">✓ Widoczne</td><td class="py-2 pr-4">✓ Widoczne</td><td class="py-2 pr-4">✗ Zaciemnione</td><td class="py-2">✓ Widoczne</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Wynagrodzenia</td><td class="py-2 pr-4">✓ Widoczne</td><td class="py-2 pr-4">Zagregowane</td><td class="py-2 pr-4">✗ Zaciemnione</td><td class="py-2">✓ Widoczne</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Klauzule umowne</td><td class="py-2 pr-4">✓ Widoczne</td><td class="py-2 pr-4">✓ Widoczne</td><td class="py-2 pr-4">Tylko typy klauzul</td><td class="py-2">✓ Widoczne</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Tajemnice handlowe</td><td class="py-2 pr-4">✗ Zaciemnione</td><td class="py-2 pr-4">✓ Widoczne</td><td class="py-2 pr-4">✗ Zaciemnione</td><td class="py-2">✓ Widoczne</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4">Podpisy</td><td class="py-2 pr-4">✗ Zaciemnione</td><td class="py-2 pr-4">✗ Zaciemnione</td><td class="py-2 pr-4">✗ Zaciemnione</td><td class="py-2">✓ Widoczne</td></tr>
</tbody>
</table>
</div>

<p class="text-body-lg text-gosign-text-light mt-4">
Reguły zaciemniania są wersjonowane w Decision Layer. Gdy wymagania się zmieniają - nowy krąg odbiorców, zaktualizowane porozumienie zakładowe, zmieniona reguła compliance - powstaje nowa wersja reguł. Poprzednia wersja pozostaje identyfikowalna.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong>Fizyczne zaciemnianie:</strong> PDF jest renderowany od nowa. Oryginalne dane nie są fizycznie obecne w dokumencie - ani jako tekst, ani jako metadane, ani jako niewidoczna warstwa. Żadne kopiuj-wklej pod czarnymi paskami, żadne edytowanie PDF aby odsłonić treść. To nie jest kosmetyka - jest to kryptograficznie bezpieczne.
</p>
</div>
</div>
</section>

<!-- Rozpoznawanie Podpisów Szczegóły -->
<section id="rozpoznawanie-podpisow" class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Rozpoznawanie Podpisów: Znajdź, Zweryfikuj, Udokumentuj</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Zarządzanie umowami, przygotowanie do audytu, przegląd compliance - wszędzie wymaga się regularnej weryfikacji: Czy dokument jest podpisany? Gdzie jest podpis? Czy brakuje kontrasygnaty? Przy 5000 umów w archiwum ręczne sprawdzanie nie jest wykonalne.
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">Wykrywanie podpisów</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Document Agent wykrywa pola podpisów i obecne podpisy w zeskanowanych dokumentach i PDF-ach. Computer Vision, nie model językowy - wyspecjalizowane modele ML do analizy obrazu. Wynik jest ustrukturyzowany: strona, pozycja, konfidencja że podpis jest obecny.
</p>

<p class="text-body-lg text-gosign-text-light mt-6">
<strong>Masowa weryfikacja archiwum:</strong> "W których z 5000 umów brakuje kontrasygnaty?" - wynik w minutach zamiast tygodni.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong>Kontrola jakości onboardingu:</strong> "Czy wszystkie obowiązkowe dokumenty nowego pracownika są podpisane?" - automatyczna checklista, brakujące podpisy eskalowane jako zadania workflow.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
<strong>Przygotowanie do audytu:</strong> "Pokaż wszystkie dokumenty bez podpisu z Q3 2025." - ustrukturyzowana lista eksportowa dla biegłego rewidenta.
</p>

<pre class="bg-gosign-dark text-white p-6 rounded-card overflow-x-auto text-small font-mono leading-relaxed mt-6"><code>┌─────────────┐     ┌──────────────────┐     ┌──────────────────┐
│  Dokument   │     │  Wykrywanie      │     │  Porównanie      │
│  z pod-     │────▶│  podpisu         │────▶│  z podpisem      │
│  pisem      │     │  (pozycja,       │     │  referencyjnym   │
│             │     │   konfidencja)   │     │                  │
└─────────────┘     └──────────────────┘     └──────────────────┘
│
┌───────────┼───────────┐
▼           ▼           ▼
┌────────────┐ ┌────────┐ ┌────────────┐
│  Wysoka    │ │Średnia │ │  Niska     │
│  zgodność  │ │zgodność│ │  zgodność  │
└────────────┘ └────────┘ └────────────┘
│              │           │
▼              ▼           ▼
Automatycznie  Eskalacja   Blokada
zaakcep-       do czło-    Weryfikacja
towane,        wieka z     przez
udoku-         widokiem    człowieka
mentowane      porównaw.   obowiązkowa</code></pre>

<p class="text-body-lg text-gosign-text-light mt-4">
<strong>Ważne:</strong> Porównanie podpisów to detektor anomalii, nie detektor fałszerstw. Podpisy naturalnie się różnią - zależy od dnia, długopisu i podłoża. System identyfikuje anomalie i eskaluje je do człowieka. Nigdy nie twierdzi "ten podpis jest sfałszowany" lub "ten podpis jest autentyczny". To byłoby nieodpowiedzialne.
</p>
</div>
</div>
</section>

<!-- Decision Layer Matryca -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Decision Layer: Kto Decyduje o Czym</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Każda capability ma własny Decision Layer z zdefiniowanymi punktami decyzyjnymi.
</p>
<div class="mt-6 overflow-x-auto">
<table class="w-full text-left text-small">
<thead>
<tr class="border-b-2 border-gosign-dark">
<th class="py-2 pr-4 font-bold">Capability</th>
<th class="py-2 pr-4 font-bold">Decyzja</th>
<th class="py-2 pr-4 font-bold">Decyduje</th>
<th class="py-2 font-bold">Dlaczego</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-bold">PII</td><td class="py-2 pr-4">Które kategorie PII rozpoznawać?</td><td class="py-2 pr-4">Człowiek</td><td class="py-2">Decyzja organizacyjna, art. 4 RODO, porozumienie zakładowe</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-bold">PII</td><td class="py-2 pr-4">Czy "Müller" to nazwisko czy firma?</td><td class="py-2 pr-4">AI, przy &lt;80% konfidencji: Człowiek</td><td class="py-2">Ambiguiczność NER - unikanie fałszywych pozytywów</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-bold">PII</td><td class="py-2 pr-4">Wybrać metodę pseudonimizacji</td><td class="py-2 pr-4">Zestaw reguł</td><td class="py-2">Spójne pseudonimy vs. wartości losowe</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-bold">Zaciemnianie</td><td class="py-2 pr-4">Jaki krąg odbiorców?</td><td class="py-2 pr-4">Człowiek</td><td class="py-2">Decyzja fachowa, nie automatyzowalna</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-bold">Zaciemnianie</td><td class="py-2 pr-4">Które pola są zaciemniane?</td><td class="py-2 pr-4">Zestaw reguł</td><td class="py-2">Matryca zaciemniania zależna od odbiorcy</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-bold">Zaciemnianie</td><td class="py-2 pr-4">Rozpoznano nieznany typ klauzuli</td><td class="py-2 pr-4">Człowiek</td><td class="py-2">Nowe typy klauzul muszą być sklasyfikowane</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-bold">Podpis</td><td class="py-2 pr-4">Podpis obecny?</td><td class="py-2 pr-4">AI</td><td class="py-2">Computer Vision z wartością konfidencji</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-bold">Podpis</td><td class="py-2 pr-4">Podpis zgodny z referencją?</td><td class="py-2 pr-4">AI + Człowiek przy anomalii</td><td class="py-2">Wysoka zgodność: zaakceptowany. Anomalia: eskalowany</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-bold">Podpis</td><td class="py-2 pr-4">Brak referencji</td><td class="py-2 pr-4">Człowiek</td><td class="py-2">Nowy podpis referencyjny musi być zarejestrowany</td></tr>
<tr class="border-b border-gosign-border"><td class="py-2 pr-4 font-bold">Wszystkie</td><td class="py-2 pr-4">Dokumentuj Audit Trail</td><td class="py-2 pr-4">Automatycznie</td><td class="py-2">Każda decyzja niezmiennie protokołowana</td></tr>
</tbody>
</table>
</div>
</div>
</div>
</section>

<!-- Integracja -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Integracja</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Document Intelligence to capability istniejącego Document Agent - nie osobne oprogramowanie. Integracja przez te same interfejsy:
</p>
<ul class="mt-4 space-y-2 text-body-lg text-gosign-text-light list-disc pl-6">
<li>SAP DMS, SAP ArchiveLink - umowy i dokumenty z archiwów SAP</li>
<li>SharePoint, OneDrive - zarządzanie dokumentami via Microsoft Graph</li>
<li>Skrzynki e-mail (IMAP/Exchange) - załączniki przetwarzane automatycznie</li>
<li>File System Watcher - monitorowanie lokalnych katalogów</li>
<li>REST API - dla niestandardowych systemów DMS</li>
</ul>
</div>
</section>

<!-- Business Impact -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Business Impact</h2>
<p class="text-body-lg text-gosign-text-light mt-4"><strong class="text-gosign-dark">Przetwarzanie LLM zgodne z RODO:</strong> Dokumenty z danymi osobowymi mogą być po raz pierwszy bezpiecznie przetwarzane modelami językowymi - bez ryzyka ochrony danych.</p>
<p class="text-body-lg text-gosign-text-light mt-4"><strong class="text-gosign-dark">Zaciemnianie umów w minutach zamiast godzin:</strong> Na podstawie reguł, zależne od odbiorcy, fizycznie bezpieczne.</p>
<p class="text-body-lg text-gosign-text-light mt-4"><strong class="text-gosign-dark">Proaktywne wykrywanie luk w podpisach:</strong> Brakujące podpisy wykrywane zanim audytor zapyta.</p>
<p class="text-body-lg text-gosign-text-light mt-4"><strong class="text-gosign-dark">Dowód audytu ochrony danych:</strong> Audit Trail dokumentuje każdą anonimizację, każde zaciemnienie, każdą weryfikację podpisu.</p>
<p class="text-body-lg text-gosign-text-light mt-4"><strong class="text-gosign-dark">Żadne nowe narzędzie:</strong> Document Intelligence to część istniejącej architektury agentowej. Bez dodatkowego dostawcy, bez dodatkowej licencji.</p>
</div>
</section>

<!-- Pogłębienie -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Pogłębienie w Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nasza seria artykułów fachowych dla decydentów wdrażających agentów AI.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/pl/magazyn/rag-document-intelligence-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">RAG i Document Intelligence: Jak AI rozumie Twoje dokumenty</p>
</a>
<a href="/pl/magazyn/pii-anonimizacja-llm-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Anonimizacja PII dla Enterprise AI</p>
</a>
<a href="/pl/magazyn/bezpieczenstwo-danych-ai-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Bezpieczeństwo danych w AI: Data Residency, RODO i EU AI Act</p>
</a>
</div>
</div>
</section>

--- Podpisy Cyfrowe Zgodne z eIDAS ---
> Rozwiązania podpisu cyfrowego według rozporządzenia eIDAS. Podpisy elektroniczne proste, zaawansowane i kwalifikowane dla korporacyjnych procesów dokumentowych.

<!-- Rozporządzenie eIDAS -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Rozporządzenie eIDAS</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Rozporządzenie eIDAS (Rozporządzenie (UE) Nr 910/2014) tworzy europejskie ramy prawne dla identyfikacji elektronicznej i usług zaufania.
</p>
</div>
</section>

<!-- Trzy Poziomy Podpisu -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">Trzy Poziomy Podpisu</h2>
<div class="grid grid-cols-1 md:grid-cols-3 gap-6">
<div class="bg-white rounded-card p-6 border border-gosign-border">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Prosty Podpis Elektroniczny (PSE)</h3>
<p class="text-body text-gosign-text-light">Bez specjalnych wymagań technicznych. Przykłady: zeskanowany podpis, imię pod emailem, kliknięcie 'Akceptuję'.</p>
</div>
<div class="bg-white rounded-card p-6 border border-gosign-border">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Zaawansowany Podpis Elektroniczny (ZPE)</h3>
<p class="text-body text-gosign-text-light">Jednoznacznie powiązany z podpisującym. Umożliwia identyfikację. Pod wyłączną kontrolą podpisującego. Wykrywa późniejsze zmiany w dokumencie.</p>
</div>
<div class="bg-white rounded-card p-6 border border-gosign-border">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Kwalifikowany Podpis Elektroniczny (KPE)</h3>
<p class="text-body text-gosign-text-light">Najwyższy poziom. Skutek prawny podpisu odręcznego (Art. 25 Ust. 2 eIDAS). Tworzony z kwalifikowanym certyfikatem od autoryzowanego dostawcy.</p>
</div>
</div>
</div>
</section>

<!-- Integracja Korporacyjna -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Integracja Korporacyjna</h2>
<div class="mt-6 space-y-6">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">W workflow <a href="/pl/uslugi/document-intelligence/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Document Agent</a></h3>
<p class="text-body-lg text-gosign-text-light mt-2">Podpis cyfrowy jako krok zamykający po automatycznym przetwarzaniu.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">W procesach zatwierdzania</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Wieloetapowe zatwierdzenia z podpisami cyfrowymi udokumentowanymi w <a href="/pl/decision-layer/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Audit Trail Decision Layer</a>.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Integracja API</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Połączenie z istniejącymi systemami via REST API.</p>
</div>
</div>
</div>
</section>

<!-- Partnerzy -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Partnerzy Certyfikowani ETSI</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Gosign nie jest dostawcą usług zaufania. Wdrażamy rozwiązania we współpracy z dostawcami certyfikowanymi według ETSI EN 319 401.
</p>
</div>
</section>

<!-- Zgodność -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Zgodność</h2>
<div class="mt-6 space-y-4">
<p class="text-body-lg text-gosign-text-light">Ważność prawna w całej UE według eIDAS.</p>
<p class="text-body-lg text-gosign-text-light">Zgodne z RODO (<a href="/pl/governance/data-residency/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Data Residency</a> w UE).</p>
<p class="text-body-lg text-gosign-text-light">Audit Trail dla wszystkich operacji podpisu.</p>
<p class="text-body-lg text-gosign-text-light">Walidacja długoterminowa (LTV) dla podpisów kwalifikowanych.</p>
</div>
</div>
</section>

<!-- Pogłębienie w Agent Briefing -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Pogłębienie w Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nasza seria artykułów fachowych dla decydentów zabezpieczających cyfrowe procesy w przedsiębiorstwie.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/pl/magazyn/cert-ready-by-design/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Cert-Ready by Design: Dlaczego certyfikacja post factum nie działa</p>
</a>
<a href="/pl/magazyn/rag-document-intelligence-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">AI Agents</p>
<p class="text-body font-semibold text-gosign-dark">RAG i Document Intelligence w zastosowaniach korporacyjnych</p>
</a>
<a href="/pl/magazyn/bezpieczenstwo-danych-ai-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">Bezpieczeństwo danych w systemach AI Enterprise</p>
</a>
</div>
</div>
</section>

--- Finance Agent - Decision Automation dla Przetwarzania Dokumentów ---
> Automatyczne przetwarzanie dokumentów z dokumentacją decyzji odporną na audyt. Deterministyczne zestawy reguł, Audit Trail, integracja Comarch i SAP.

<!-- Problem -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Problem</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
W przetwarzaniu dokumentów ludzie podejmują codziennie setki mikro-decyzji: konto, centrum kosztów, rozpoczęcie amortyzacji, odliczenie VAT. Każda decyzja opiera się na regułach - przepisach podatkowych, standardach księgowych, wytycznych wewnętrznych.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Problem to nie brak wiedzy. To niespójność: różni specjaliści stosują te same reguły różnie. Więcej klientów, więcej lokalizacji - większa wariancja.
</p>
</div>
</section>

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Darmowy eBook: AI w Finance</p>
<p class="text-body text-gosign-text mb-4">Compliance, biegły rewident i Decision Layer - poradnik governance dla liderów finansów.</p>
<a href="/pl/ebook/ai-finance-poradnik-governance/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Pobierz za darmo</a>
</div>

<!-- Decision Automation -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Decision Automation</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Finance Agent to nie narzędzie OCR. To system Decision Automation decydujący na podstawie wersjonowanych zestawów reguł.
</p>
<div class="mt-6 space-y-4">
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">1. Czytanie i rozumienie</strong> - z rzeczywistym rozumieniem językowym</p>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">2. Ocena ekspercka</strong> - konto, centrum kosztów, klasyfikacja podatkowa</p>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">3. Decyzja</strong> - <a href="/pl/decision-layer/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Decision Layer</a> routuje: autonomicznie lub do człowieka</p>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">4. Dokumentacja</strong> - Kompletny zapis każdej mikro-decyzji</p>
</div>
</div>
</section>

<!-- Flow Diagram -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<pre class="bg-gosign-dark text-white p-6 rounded-card overflow-x-auto text-small font-mono leading-relaxed"><code>Dokument      →  Agent czyta    →  Decision Layer
przychodzący     i rozumie         weryfikuje reguły
│
┌────────────┴────────────┐
│                         │
Wysoka pewność           Niska pewność
│                         │
Propozycja              Zapytanie do
księgowania             specjalisty
│                         │
Eksport do              Workflow pauza
Comarch / SAP
│                         │
Audit Trail             Audit Trail</code></pre>
</div>
</section>

<!-- Zestawy Reguł -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Zestawy Reguł</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Każdy zestaw to niezależny obiekt danych z wersją, datą ważności i zakresem. Zmiany tworzą nowe wersje. Podczas audytu identyfikowalne, która reguła w jakiej wersji obowiązywała.
</p>
</div>
</section>

<!-- Cert-Ready -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Cert-Ready by Design</h2>
<div class="mt-6 space-y-4">
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Portal Audytora:</strong> Status na żywo z drill-down. Szczegóły architektury: <a href="/pl/governance/cert-ready/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Cert-Ready by Design</a>.</p>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Zapis per dokument:</strong> Kompletna ścieżka decyzji.</p>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Mapowanie frameworków:</strong> ISA, PS 951, IDW, GoB/GoBD (niemiecki standard dokumentacji) (niemiecki standard dokumentacji). Więcej o naszym podejściu: <a href="/pl/governance/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Governance by Design</a>.</p>
</div>
</div>
</section>

<!-- Integracja -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">Integracja</h2>
<div class="grid grid-cols-1 md:grid-cols-2 gap-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Comarch ERP</h3>
<p class="text-body text-gosign-text-light mt-2">Propozycje w formacie Comarch ERP, zgodnie z polską Ustawą o rachunkowości.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">SAP FI/CO</h3>
<p class="text-body text-gosign-text-light mt-2">Propozycje w formacie SAP, centra kosztów i zysku.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">finAPI / Banking</h3>
<p class="text-body text-gosign-text-light mt-2">Automatyczne przetwarzanie wyciągów.</p>
</div>
</div>
<p class="text-body-lg text-gosign-text-light mt-6">
Logika księgowa oddzielona od eksportu. Zmiana systemu docelowego zmienia eksport - nie agenta.
</p>
</div>
</section>

<!-- Grupy Docelowe -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Grupy Docelowe</h2>
<div class="mt-6 space-y-4">
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Firmy audytorskie i księgowe:</strong> Spójność między setkami klientów.</p>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Centra Usług Wspólnych:</strong> Reguły per klient stosowane spójnie.</p>
<p class="text-body-lg text-gosign-text-light"><strong class="text-gosign-dark">Firmy z księgowością wewnętrzną:</strong> Mniej korekt, kompletna dokumentacja.</p>
</div>
</div>
</section>

<!-- Pogłębienie w Agent Briefing -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Pogłębienie w Agent Briefing (Magazyn Gosign)</h2>
<p class="text-body text-gosign-text-light mb-6">Nasza seria artykułów fachowych dla decydentów automatyzujących procesy finansowe z AI Agents.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/pl/magazyn/koszty-ai-tco-porownanie/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Finance</p>
<p class="text-body font-semibold text-gosign-dark">Koszty AI w porównaniu: Analiza TCO dla Enterprise</p>
</a>
<a href="/pl/magazyn/decision-layer-shadow-ai/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer vs. Shadow AI: Dlaczego Governance jest ważniejsze od szybkości</p>
</a>
<a href="/pl/magazyn/deepseek-enterprise-hosting/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">Hosting AI: EU SaaS, niemieckie centrum danych czy Self-Hosted?</p>
</a>
</div>
</div>
</section>

--- AI Leave Agent Lotnictwo - zarządzanie nieobecnościami ---
> Leave Decision Layer dla lotnictwa. Wiele związków zawodowych, EASA FTL, Medical Grounding, Crew-Pairing. 78% Zero-Touch.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/pl/dlaczego-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Każda decyzja możliwa do prześledzenia</p>
</div>
</a>
<a href="/pl/dlaczego-gosign/#infrastruktura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Twoja infrastruktura</p>
<p class="text-xs text-gosign-text-light">Bez SaaS. Bez vendor-lock-in.</p>
</div>
</a>
<a href="/pl/dlaczego-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Bez ryzyka US-cloud</p>
</div>
</a>
</div>
</div>
</div>


<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Leave Decision Layer - branże">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/pl/uslugi/hr-agent/leave-absence-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Leave Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/pl/uslugi/hr-agent/leave-absence-decision-layer/chemicals/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Chemia</a>
<a href="/pl/uslugi/hr-agent/leave-absence-decision-layer/aviation/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Lotnictwo</a>
<a href="/pl/uslugi/hr-agent/leave-absence-decision-layer/financial-services/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Finanse</a>
<a href="/pl/uslugi/hr-agent/leave-absence-decision-layer/retail/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Handel</a>
</div>
</div>
</nav>

<!-- Złożoność -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div><span class="text-h1 font-bold text-gosign-accent-text">3+</span><p class="text-small text-gosign-text-light mt-1">Związki zawodowe</p></div>
<div><span class="text-h1 font-bold text-gosign-accent-text">78%</span><p class="text-small text-gosign-text-light mt-1">Zero-Touch-Quote</p></div>
<div><span class="text-h1 font-bold text-gosign-accent-text">EASA</span><p class="text-small text-gosign-text-light mt-1">FTL-Compliance</p></div>
<div><div class="flex gap-1 mt-2"><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span></div><p class="text-small text-gosign-text-light mt-1">Najwyższa złożoność reguł</p></div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">Układy zbiorowe pilotów (ZZKRL), kabiny, obsługi naziemnej (Solidarność). LOT Polish Airlines. Zero-Touch: model symulacyjny Gosign.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Co klasyfikuje Agent</p>
<h2 class="text-h1 font-bold text-gosign-dark">Pięć wymiarów, jeden Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Wiele związków zawodowych z własnymi układami zbiorowymi, regulacyjne obowiązkowe odpoczynki, Medical Grounding, Crew-Pairing jako ograniczenie operacyjne i sezonowe blokady urlopowe. Znacie tę złożoność. Tak AI Agent ją rozwiązuje:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div><h3 class="text-h3 font-bold text-gosign-dark">Wiele układów zbiorowych równolegle</h3><p class="text-body text-gosign-text mt-2">Piloci (ZZKRL), kabina (związek personelu pokładowego), obsługa naziemna (Solidarność) - każdy układ zbiorowy ma własne regulacje urlopowe, urlopy okolicznościowe i wyrównania czasu wolnego. AI Agent rozpoznaje grupę personalną i stosuje prawidłowy system reguł. Żadnego pomieszania między urlopem pilota a urlopem obsługi naziemnej.</p></div>
<div><h3 class="text-h3 font-bold text-gosign-dark">Obowiązkowe odpoczynki EASA FTL</h3><p class="text-body text-gosign-text mt-2">Flight Time Limitations to regulacyjne obowiązkowe odpoczynki, które nie mogą być traktowane jako urlop. AI Agent rozdziela czysto: odpoczynki FTL przebiegają w oddzielnym śledzeniu, uprawnienia urlopowe nie są redukowane przez obowiązkowe odpoczynki. Przy planowaniu urlopów Agent sprawdza compliance FTL wobec planu operacyjnego.</p></div>
<div><h3 class="text-h3 font-bold text-gosign-dark">Medical Grounding</h3><p class="text-body text-gosign-text mt-2">Cofnięcie Medical Certificate (Class 1 kokpit, Class 2 kabina) to nie regularna choroba, lecz regulacyjna nieobecność. AI Agent klasyfikuje Medical Grounding jako odrębny typ nieobecności z konsekwencjami specyficznymi dla układu zbiorowego. Dane zdrowotne pozostają architektonicznie odseparowane - Agent widzi tylko status, nie diagnozę.</p></div>
<div><h3 class="text-h3 font-bold text-gosign-dark">Crew-Pairing jako ograniczenie</h3><p class="text-body text-gosign-text mt-2">Kokpit i kabina muszą być obsadzone wspólnie na każdy lot. AI Agent sprawdza przy każdym wniosku urlopowym dostępność załogi wobec planu lotów i minimalną obsadę na stanowisko. Przy naruszeniu: automatyczna eskalacja z propozycją alternatywnego terminu i kontekstem dla schedulera.</p></div>
<div><h3 class="text-h3 font-bold text-gosign-dark">Sezonowe blokady urlopowe</h3><p class="text-body text-gosign-text mt-2">Program letni i ruch świąteczny oznaczają blokady urlopowe dla personelu latającego. AI Agent zna okresy blokad z porozumienia zakładowego i sprawdza każdy wniosek wobec nich. Wyjątki wymagają decyzji przełożonego - Agent dokumentuje wyjątek w Audit Trail.</p></div>
</div>
</div>
</section>

<!-- Decision Flow -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Jeden wniosek urlopowy w lotnictwie. 10 kroków decyzyjnych.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Pilot składa wniosek urlopowy. Leave Decision Layer rozkłada proces na pojedyncze kroki decyzyjne:</p>
<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead><tr class="border-b-2 border-gosign-border"><th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Krok</th><th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decyzja</th><th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decydent</th><th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Uzasadnienie</th></tr></thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Rozpoznanie grupy personalnej i układu zbiorowego</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent rozpoznaje: piloci (ZZKRL), kabina lub obsługa naziemna (Solidarność) z danych kadrowych</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Klasyfikacja typu nieobecności</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent rozpoznaje: urlop wypoczynkowy, urlop okolicznościowy, odpoczynek FTL lub Medical Grounding</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Obliczenie uprawnienia urlopowego</td><td class="py-3 px-4">System reguł</td><td class="py-3 px-4">Urlop podstawowy wg układu zbiorowego + urlop dodatkowy (długi dystans, senioryt)</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Sprawdzenie compliance EASA FTL</td><td class="py-3 px-4">System reguł</td><td class="py-3 px-4">Minimalne odpoczynki między dyżurami, kumulacja godzin lotu, limity Duty-Period</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Sprawdzenie Crew-Pairing i obsady minimalnej</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent sprawdza dostępność załogi wobec planu lotów i minimalną obsadę na stanowisko</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Sprawdzenie blokady urlopowej</td><td class="py-3 px-4">System reguł</td><td class="py-3 px-4">Program letni, ruch świąteczny, okresy blokad z porozumienia zakładowego</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Wygenerowanie rekomendacji zatwierdzenia</td><td class="py-3 px-4">AI rekomenduje, człowiek decyduje</td><td class="py-3 px-4">Wszystkie reguły spełnione: rekomendacja zatwierdzenia. Konflikt: eskalacja z kontekstem</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">Sprawdzenie progu procedury powrotu</td><td class="py-3 px-4">System reguł</td><td class="py-3 px-4">Ponad 30 dni niezdolności w 12 miesiącach krocząco. Medical Grounding jako przypadek specjalny oddzielnie śledzony</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Obliczenie wynagrodzenia chorobowego</td><td class="py-3 px-4">System reguł</td><td class="py-3 px-4">33 dni pracodawca, od kolejnego dnia zasiłek ZUS, sprawdzenie uzupełnienia wg układu zbiorowego</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Wygenerowanie wpisu audytowego</td><td class="py-3 px-4">System reguł</td><td class="py-3 px-4">Kompletny akt decyzyjny: typ nieobecności, układ zbiorowy, status FTL, sprawdzenie załogi, wynik</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Symulacja -->
<section id="simulation" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Symulacja</p>
<h2 class="text-h1 font-bold text-white">Przeliczone dla wolumenów lotniczych</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Skonfigurowaliśmy Leave Decision Layer z realistycznymi parametrami lotnictwa. Wiele związków zawodowych, EASA FTL, Medical Grounding, Crew-Pairing.</p>
<h3 class="text-h3 font-bold text-white mt-10 mb-4">Parametry symulacji</h3>
<div class="overflow-x-auto"><table class="w-full text-small"><tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Pracownicy</td><td class="py-3 px-4">5 000 do 80 000+ (kokpit, kabina, obsługa naziemna)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Układy zbiorowe</td><td class="py-3 px-4">ZZKRL (piloci), związek personelu pokładowego (kabina), Solidarność (obsługa naziemna)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Regulacja</td><td class="py-3 px-4">EASA FTL (EU-OPS), Medical Certificates Class 1 i Class 2</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Typy nieobecności</td><td class="py-3 px-4">Urlop wypoczynkowy, odpoczynek FTL, Medical Grounding, Standby, urlop okolicznościowy</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Ograniczenia</td><td class="py-3 px-4">Crew-Pairing, sezonowe blokady, porty bazowe (WAW, KRK, zagraniczne)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Absencja chorobowa</td><td class="py-3 px-4">Średnia branżowa lotnictwo, Medical Grounding oddzielnie</td></tr>
</tbody></table></div>
<h3 class="text-h3 font-bold text-white mt-10 mb-4">Przed / po</h3>
<div class="overflow-x-auto"><table class="w-full text-small"><thead><tr class="border-b-2 border-white/20"><th scope="col" class="text-left py-3 px-4 font-semibold text-white">Wymiar</th><th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manualnie</th><th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th></tr></thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Czas przetwarzania wniosku urlopowego</td><td class="py-3 px-4">2-5 dni (sprawdzanie załogi)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 2 minuty</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Zero-Touch-Quote</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">78%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Wykryte konflikty FTL</td><td class="py-3 px-4">Manualnie przez schedulera</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatycznie w czasie rzeczywistym</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Medical Grounding prawidłowo sklasyfikowany</td><td class="py-3 px-4">Podatne na błędy</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">100% prawidłowo (odrębny typ)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Przekroczenia terminu procedury powrotu</td><td class="py-3 px-4">12-18%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">0% (automatyczny trigger)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Gotowość audytowa</td><td class="py-3 px-4">Manualnie rekonstruowana</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatycznie generowana</td></tr>
</tbody></table></div>
<p class="text-xs text-gosign-text-on-dark/70 mt-4">EASA FTL: rozporządzenie UE 965/2012 Subpart FTL. Absencja chorobowa: ZUS / GUS. Wyniki symulacji: model obliczeniowy Gosign.</p>
<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">W symulacji Decision Layer osiąga Zero-Touch-Quote 78%. Niższy wskaźnik odzwierciedla wysoką gęstość regulacyjną: konflikty Crew-Pairing, klasyfikacja Medical-Grounding i graniczne przypadki FTL wymagają częściej ludzkich decyzji. Dla 78% dostępny jest kompletny, audytowalny akt decyzyjny.</p>
</div>
</section>

<!-- Architektura -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Architektura i implementacja</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">Leave Decision Layer działa w pełni w Państwa infrastrukturze. Dla lotnictwa oznacza to: połączenie z systemami Crew-Management, śledzenie FTL, bazą Medical i ciągły Audit Trail. Typowe projekty pilotażowe startują z jedną grupą personalną (np. obsługa naziemna) i rozszerzają na kokpit i kabinę.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/pl/uslugi/hr-agent/leave-absence-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Leave Decision Layer przegląd &rarr;</a>
<a href="/pl/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Architektura Decision Layer &rarr;</a>
<a href="/pl/uslugi/infrastruktura/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infrastruktura szczegółowo &rarr;</a>
<a href="/pl/governance/co-determination/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Współdecydowanie i Rada Zakładowa &rarr;</a>
<a href="/pl/uslugi/hr-agent/payroll-decision-layer/aviation/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Payroll Decision Layer Lotnictwo &rarr;</a>
</div>
</div>
</section>


<!-- Weitere Agent-Lösungen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Więcej rozwiązań agentowych</h2>
<p class="text-body-lg text-gosign-text-light mt-4">HR Agents to część naszego portfolio agentów. Dla finansów i innych obszarów oferujemy wyspecjalizowane rozwiązania.</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8 max-w-content">
<a href="/pl/hr-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR & People Operations</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Wszystkie HR Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Zgodność z radą zakładową.</p>
</a>
<a href="/pl/finance-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Finance & Accounting</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Finance AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Przetwarzanie dokumentów, księgowanie, amortyzacja, korekty. Integracja z systemami ERP.</p>
</a>
<a href="/pl/kontakt/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Indywidualnie</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Co-Build dla Twojego procesu</h3>
<p class="text-body text-gosign-text-light mt-2">Compliance, operacje, shared services - rozwijamy agentów w modelu co-build.</p>
</a>
</div>
</div>
</section>

<!-- Pogłębienie -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Pogłębienie w Agent Briefing (Magazyn Gosign)</h2>
<p class="text-body text-gosign-text-light mb-6">Nasza seria artykułów eksperckich dla decydentów wdrażających AI Agents w przedsiębiorstwie.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/pl/magazyn/rada-zakladowa-ai-mitbestimmung/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors"><p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Współdecydowanie</p><p class="text-body font-semibold text-gosign-dark">Rada Zakładowa i AI - współdecydowanie jako ograniczenie architektury</p></a>
<a href="/pl/magazyn/agent-governance-hr/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors"><p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p><p class="text-body font-semibold text-gosign-dark">Agent Governance dla HR - dlaczego systemy reguł są ważniejsze niż modele</p></a>
<a href="/pl/magazyn/decision-layer-wyjasnienie/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors"><p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Podstawy</p><p class="text-body font-semibold text-gosign-dark">Decision Layer - czym jest i dlaczego każdy AI Agent w przedsiębiorstwie go potrzebuje?</p></a>
</div>
</div>
</section>

<!-- Inne branże -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Leave Decision Layer w innych branżach</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Każda branża ma własne układy zbiorowe, własne typy nieobecności i własne czynniki złożoności. Decision Layer jest ten sam. Konfiguracja jest specyficzna dla branży.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/pl/uslugi/hr-agent/leave-absence-decision-layer/chemicals/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3"><h3 class="text-h3 font-bold text-gosign-dark">Chemia</h3><div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div></div>
<p class="text-small text-gosign-text-light">Układy ponadzakładowe, dodatek urlopowy ZFŚS, urlop dodatkowy zmianowy, procedura powrotu przy substancjach szkodliwych</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between"><span class="text-body font-bold text-gosign-accent-text">83% Zero-Touch</span><span class="text-small text-gosign-accent-text font-semibold">Szczegóły &rarr;</span></div>
</a>
<a href="/pl/uslugi/hr-agent/leave-absence-decision-layer/financial-services/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3"><h3 class="text-h3 font-bold text-gosign-dark">Finanse</h3><div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div></div>
<p class="text-small text-gosign-text-light">Obowiązkowe zwolnienie, bloki urlopowe KNF, dni wolne od sesji giełdowej, programy emerytalne</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between"><span class="text-body font-bold text-gosign-accent-text">85% Zero-Touch</span><span class="text-small text-gosign-accent-text font-semibold">Szczegóły &rarr;</span></div>
</a>
<a href="/pl/uslugi/hr-agent/leave-absence-decision-layer/retail/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3"><h3 class="text-h3 font-bold text-gosign-dark">Handel</h3><div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div></div>
<p class="text-small text-gosign-text-light">Praca 6 dni w tygodniu, 64% niepełny etat, blokady urlopowe sezon, uprawnienia pracowników na zleceniu</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between"><span class="text-body font-bold text-gosign-accent-text">87% Zero-Touch</span><span class="text-small text-gosign-accent-text font-semibold">Szczegóły &rarr;</span></div>
</a>
</div>
</div>
</section>

--- AI Leave Agent Chemia - zarządzanie nieobecnościami ---
> Leave Decision Layer dla przemysłu chemicznego. Układy ponadzakładowe, urlop zmianowy, procedura powrotu. 83% Zero-Touch.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/pl/dlaczego-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Każda decyzja możliwa do prześledzenia</p>
</div>
</a>
<a href="/pl/dlaczego-gosign/#infrastruktura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Twoja infrastruktura</p>
<p class="text-xs text-gosign-text-light">Bez SaaS. Bez vendor-lock-in.</p>
</div>
</a>
<a href="/pl/dlaczego-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Bez ryzyka US-cloud</p>
</div>
</a>
</div>
</div>
</div>



<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Leave Decision Layer - branże">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/pl/uslugi/hr-agent/leave-absence-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Leave Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/pl/uslugi/hr-agent/leave-absence-decision-layer/chemicals/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Chemia</a>
<a href="/pl/uslugi/hr-agent/leave-absence-decision-layer/aviation/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Lotnictwo</a>
<a href="/pl/uslugi/hr-agent/leave-absence-decision-layer/financial-services/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Finanse</a>
<a href="/pl/uslugi/hr-agent/leave-absence-decision-layer/retail/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Handel</a>
</div>
</div>
</nav>

<!-- Złożoność -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">30+</span>
<p class="text-small text-gosign-text-light mt-1">Typów nieobecności</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">83%</span>
<p class="text-small text-gosign-text-light mt-1">Zero-Touch-Quote</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">ZFŚS</span>
<p class="text-small text-gosign-text-light mt-1">Dodatek urlopowy</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">Najwyższa złożoność reguł</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">Układy ponadzakładowe Solidarność Chemia / OPZZ. ORLEN, Grupa Azoty, Tauron. Zero-Touch: model symulacyjny Gosign.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Co klasyfikuje Agent</p>
<h2 class="text-h1 font-bold text-gosign-dark">Pięć wymiarów, jeden Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">26 dni urlopu podstawowego, urlop dodatkowy zmianowy do 5 dni, dodatek urlopowy z ZFŚS, procedura powrotu przy ekspozycji na substancje szkodliwe, obsada minimalna w produkcji ciągłej. Znacie tę złożoność. Tak AI Agent ją rozwiązuje:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Urlop dodatkowy zmianowy wg modelu</h3>
<p class="text-body text-gosign-text mt-2">Zmiana w pełni ciągła 5 dni, częściowo ciągła 3 dni, rotacyjna 2 dni. AI Agent rozpoznaje model zmianowy z planu zmian i przypisuje prawidłowy urlop dodatkowy. Przy zmianie modelu zmianowego system reguł automatycznie oblicza proporcjonalne uprawnienie - żadnego manualnego przeliczania przy 5 000 pracownikach zmianowych.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Dodatek urlopowy z ZFŚS</h3>
<p class="text-body text-gosign-text mt-2">Zakładowy Fundusz Świadczeń Socjalnych finansuje dodatek urlopowy uzależniony od sytuacji socjalnej pracownika. AI Agent zarządza indywidualnym uprawnieniem, weryfikuje kryteria dochodowe i dokumentuje przyznanie. Przy zmianie sytuacji rodzinnej: automatyczne przeliczenie od następnego okresu.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Procedura powrotu przy substancjach szkodliwych</h3>
<p class="text-body text-gosign-text mt-2">Przy długotrwałej nieobecności pracowników z ekspozycją na substancje szkodliwe szczególne znaczenie ma badanie medycyny pracy. AI Agent rozpoznaje ekspozycję z oceny ryzyka zawodowego i oznacza flagą przypadki wymagające badania lekarza medycyny pracy. Dane zdrowotne pozostają architektonicznie odseparowane.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Obsada minimalna w produkcji ciągłej</h3>
<p class="text-body text-gosign-text mt-2">W produkcji chemicznej proces działa przez całą dobę. AI Agent sprawdza przy każdym wniosku urlopowym obsadę zmianową wobec reguł minimalnej obsady na zmianę i kwalifikację. Przy naruszeniu: automatyczna eskalacja z propozycją alternatywnego terminu zamiast ogólnej odmowy.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Urlop za staż pracy wg układu</h3>
<p class="text-body text-gosign-text mt-2">Od 10 lat stażu dodatkowe dni urlopowe - zależne od układu z różnymi progami i stopniami. AI Agent automatycznie oblicza urlop stażowy z danych kadrowych i układu zbiorowego. Przy osiągnięciu progu w trakcie roku: proporcjonalne obliczenie od odpowiedniego dnia.</p>
</div>
</div>
</div>
</section>

<!-- Decision Flow -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Jeden wniosek urlopowy w chemii. 10 kroków decyzyjnych.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Pracownik zmianowy w przemyśle chemicznym składa wniosek urlopowy. Leave Decision Layer rozkłada proces na pojedyncze kroki decyzyjne:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Krok</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decyzja</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decydent</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Uzasadnienie</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Klasyfikacja typu nieobecności</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent rozpoznaje: urlop wypoczynkowy, urlop dodatkowy zmianowy, urlop na żądanie, urlop okolicznościowy lub dzień wolny</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Rozpoznanie układu zbiorowego i modelu zmianowego</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent rozpoznaje lokalizację, układ zbiorowy i model zmianowy z danych kadrowych i planu zmian</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Obliczenie całkowitego uprawnienia</td><td class="py-3 px-4">System reguł</td><td class="py-3 px-4">20/26 dni podstawowych + urlop dodatkowy zmianowy (2-5) + urlop stażowy + urlop dodatkowy za niepełnosprawność</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Obliczenie pozostałego uprawnienia</td><td class="py-3 px-4">System reguł</td><td class="py-3 px-4">Całkowite uprawnienie minus wykorzystane i zatwierdzone dni, w tym urlop zaległy</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Sprawdzenie minimalnej obsady zmiany</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent sprawdza obsadę zmianową wobec reguł minimalnej obsady na kwalifikację</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Rozpoznanie konfliktu zespołowego</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent sprawdza: blokady kolegów, równoległe wnioski, maksymalny odsetek jednoczesnych nieobecności</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Wygenerowanie rekomendacji zatwierdzenia</td><td class="py-3 px-4">AI rekomenduje, człowiek decyduje</td><td class="py-3 px-4">Wszystkie reguły spełnione: rekomendacja zatwierdzenia. Konflikt: eskalacja z kontekstem do przełożonego</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">Sprawdzenie progu procedury powrotu</td><td class="py-3 px-4">System reguł</td><td class="py-3 px-4">Ponad 30 dni niezdolności w 12 miesiącach krocząco. Przy ekspozycji na substancje: dodatkowa flaga dla badania medycyny pracy</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Obliczenie wynagrodzenia chorobowego</td><td class="py-3 px-4">System reguł</td><td class="py-3 px-4">33 dni pracodawca (14 dni dla 50+), od kolejnego dnia zasiłek ZUS. 4 tygodnie karencji przy nowym zatrudnieniu</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Wygenerowanie wpisu audytowego</td><td class="py-3 px-4">System reguł</td><td class="py-3 px-4">Kompletny akt decyzyjny: typ nieobecności, uprawnienie, kroki sprawdzające, wynik, znacznik czasu</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Symulacja -->
<section id="simulation" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Symulacja</p>
<h2 class="text-h1 font-bold text-white">Przeliczone dla wolumenów chemicznych</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Skonfigurowaliśmy Leave Decision Layer z realistycznymi parametrami polskiego przemysłu chemicznego. Układy ponadzakładowe, modele zmianowe, ZFŚS, procedura powrotu przy substancjach szkodliwych.</p>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Parametry symulacji</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Pracownicy</td><td class="py-3 px-4">5 000 do 50 000+ (produkcja, laboratorium, administracja)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Układ zbiorowy</td><td class="py-3 px-4">Solidarność Chemia / OPZZ, układy ponadzakładowe</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Urlop podstawowy</td><td class="py-3 px-4">20/26 dni + urlop dodatkowy zmianowy (2-5 dni) + urlop stażowy</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Modele zmianowe</td><td class="py-3 px-4">Zmiana w pełni ciągła, częściowo ciągła, rotacyjna, normalna</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">ZFŚS</td><td class="py-3 px-4">Dodatek urlopowy uzależniony od sytuacji socjalnej</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Absencja chorobowa</td><td class="py-3 px-4">Średnia branżowa chemia, w tym ekspozycja na substancje szkodliwe</td></tr>
</tbody>
</table>
</div>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Przed / po</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th scope="col" class="text-left py-3 px-4 font-semibold text-white">Wymiar</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manualnie</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Czas przetwarzania wniosku urlopowego</td><td class="py-3 px-4">1-3 dni</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 30 sekund</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Zero-Touch-Quote</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">83%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Przekroczenia terminu procedury powrotu</td><td class="py-3 px-4">12-18% (manualne śledzenie)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">0% (automatyczny trigger)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Ostrzeżenia o wygaśnięciu urlopu</td><td class="py-3 px-4">Często zapominane</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatycznie, terminowo, indywidualnie</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Obliczanie urlopu dodatkowego zmianowego</td><td class="py-3 px-4">Manualnie, podatne na błędy</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Oparte na regułach, konsekwentne</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Gotowość audytowa</td><td class="py-3 px-4">Manualnie rekonstruowana</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatycznie generowana</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">Układy ponadzakładowe Solidarność Chemia / OPZZ. Absencja chorobowa: ZUS / GUS. Wyniki symulacji: model obliczeniowy Gosign.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">W symulacji Decision Layer osiąga Zero-Touch-Quote 83%. Pozostałe 17% to rzeczywiste wyjątki: konflikty urlopowe przy obsadzie minimalnej, procedury powrotu, zmiany uprawnień do dodatku urlopowego ZFŚS. Dla 83% dostępny jest kompletny, audytowalny akt decyzyjny.</p>
</div>
</section>

<!-- Architektura -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Architektura i implementacja</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">Leave Decision Layer działa w pełni w Państwa infrastrukturze. Dla przemysłu chemicznego oznacza to: połączenie z systemami planowania zmian, przetwarzanie mapowania substancji szkodliwych, systemy reguł specyficzne dla układów zbiorowych i ciągły Audit Trail do SAP HCM. Typowe projekty pilotażowe startują w ciągu 3 miesięcy z jednym układem i jedną grupą pracowniczą.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/pl/uslugi/hr-agent/leave-absence-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Leave Decision Layer przegląd &rarr;</a>
<a href="/pl/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Architektura Decision Layer &rarr;</a>
<a href="/pl/uslugi/infrastruktura/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infrastruktura szczegółowo &rarr;</a>
<a href="/pl/governance/co-determination/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Współdecydowanie i Rada Zakładowa &rarr;</a>
<a href="/pl/uslugi/hr-agent/payroll-decision-layer/chemicals/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Payroll Decision Layer Chemia &rarr;</a>
</div>
</div>
</section>


<!-- Weitere Agent-Lösungen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Więcej rozwiązań agentowych</h2>
<p class="text-body-lg text-gosign-text-light mt-4">HR Agents to część naszego portfolio agentów. Dla finansów i innych obszarów oferujemy wyspecjalizowane rozwiązania.</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8 max-w-content">
<a href="/pl/hr-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR & People Operations</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Wszystkie HR Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Zgodność z radą zakładową.</p>
</a>
<a href="/pl/finance-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Finance & Accounting</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Finance AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Przetwarzanie dokumentów, księgowanie, amortyzacja, korekty. Integracja z systemami ERP.</p>
</a>
<a href="/pl/kontakt/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Indywidualnie</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Co-Build dla Twojego procesu</h3>
<p class="text-body text-gosign-text-light mt-2">Compliance, operacje, shared services - rozwijamy agentów w modelu co-build.</p>
</a>
</div>
</div>
</section>

<!-- Pogłębienie -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Pogłębienie w Agent Briefing (Magazyn Gosign)</h2>
<p class="text-body text-gosign-text-light mb-6">Nasza seria artykułów eksperckich dla decydentów wdrażających AI Agents w przedsiębiorstwie.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/pl/magazyn/rada-zakladowa-ai-mitbestimmung/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Współdecydowanie</p>
<p class="text-body font-semibold text-gosign-dark">Rada Zakładowa i AI - współdecydowanie jako ograniczenie architektury</p>
</a>
<a href="/pl/magazyn/agent-governance-hr/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Agent Governance dla HR - dlaczego systemy reguł są ważniejsze niż modele</p>
</a>
<a href="/pl/magazyn/decision-layer-wyjasnienie/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Podstawy</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - czym jest i dlaczego każdy AI Agent w przedsiębiorstwie go potrzebuje?</p>
</a>
</div>
</div>
</section>

<!-- Inne branże -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Leave Decision Layer w innych branżach</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Każda branża ma własne układy zbiorowe, własne typy nieobecności i własne czynniki złożoności. Decision Layer jest ten sam. Konfiguracja jest specyficzna dla branży.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/pl/uslugi/hr-agent/leave-absence-decision-layer/aviation/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Lotnictwo</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">Wiele związków zawodowych, EASA FTL obowiązkowe odpoczynki, Medical Grounding, Crew-Pairing</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">78% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Szczegóły &rarr;</span>
</div>
</a>
<a href="/pl/uslugi/hr-agent/leave-absence-decision-layer/financial-services/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Finanse</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">Obowiązkowe zwolnienie, bloki urlopowe KNF, dni wolne od sesji giełdowej, programy emerytalne</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">85% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Szczegóły &rarr;</span>
</div>
</a>
<a href="/pl/uslugi/hr-agent/leave-absence-decision-layer/retail/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Handel</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">Praca 6 dni w tygodniu, 64% niepełny etat, blokady urlopowe sezon, uprawnienia pracowników na zleceniu</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">87% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Szczegóły &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- AI Leave Agent Finanse - zarządzanie nieobecnościami ---
> Leave Decision Layer dla banków i ubezpieczeń. Obowiązkowe zwolnienie, bloki urlopowe KNF, dni wolne od sesji. 85% Zero-Touch.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/pl/dlaczego-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Każda decyzja możliwa do prześledzenia</p>
</div>
</a>
<a href="/pl/dlaczego-gosign/#infrastruktura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Twoja infrastruktura</p>
<p class="text-xs text-gosign-text-light">Bez SaaS. Bez vendor-lock-in.</p>
</div>
</a>
<a href="/pl/dlaczego-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Bez ryzyka US-cloud</p>
</div>
</a>
</div>
</div>
</div>
<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Leave Decision Layer - branże">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/pl/uslugi/hr-agent/leave-absence-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Leave Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/pl/uslugi/hr-agent/leave-absence-decision-layer/chemicals/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Chemia</a>
<a href="/pl/uslugi/hr-agent/leave-absence-decision-layer/aviation/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Lotnictwo</a>
<a href="/pl/uslugi/hr-agent/leave-absence-decision-layer/financial-services/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Finanse</a>
<a href="/pl/uslugi/hr-agent/leave-absence-decision-layer/retail/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Handel</a>
</div>
</div>
</nav>

<!-- Złożoność -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">5</span>
<p class="text-small text-gosign-text-light mt-1">Systemów wynagradzania</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">85%</span>
<p class="text-small text-gosign-text-light mt-1">Zero-Touch-Quote</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">KNF</span>
<p class="text-small text-gosign-text-light mt-1">Obowiązkowe bloki urlopowe</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
<span class="w-4 h-2 rounded-sm bg-gosign-border"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">Wysoka złożoność reguł</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">Układ zbiorowy banków (ZBP), układ zbiorowy ubezpieczeń. Wymogi KNF. Zero-Touch: model symulacyjny Gosign.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Co klasyfikuje Agent</p>
<h2 class="text-h1 font-bold text-gosign-dark">Pięć wymiarów, jeden Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Obowiązkowe zwolnienie według zasady czterech oczu, obowiązkowe bloki urlopowe KNF, dni wolne od sesji giełdowej, emerytury pomostowe i 5 równoległych systemów wynagradzania. Znacie tę złożoność. Tak AI Agent ją rozwiązuje:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Obowiązkowe zwolnienie (zasada czterech oczu)</h3>
<p class="text-body text-gosign-text mt-2">Pracownicy na stanowiskach związanych z handlem muszą przynajmniej raz w roku być ciągle zwolnieni z obowiązków. AI Agent rozpoznaje stanowiska objęte obowiązkowym zwolnieniem z danych kadrowych, sprawdza czy wnioskowany urlop spełnia minimalny czas trwania bloku i śledzi, czy obowiązkowe zwolnienie w bieżącym roku już się odbyło.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Obowiązkowe bloki urlopowe KNF</h3>
<p class="text-body text-gosign-text mt-2">Regulacje KNF wymagają ciągłych bloków urlopowych dla pracowników na stanowiskach istotnych dla ryzyka. AI Agent śledzi termin, ostrzega w odpowiednim czasie przy brakującym obowiązkowym bloku i dokumentuje zgodność w Audit Trail. Przy kontroli KNF: eksport kompletnego statusu compliance na pracownika.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Dni wolne od sesji giełdowej i kalendarz handlowy</h3>
<p class="text-body text-gosign-text mt-2">Dni wolne od sesji giełdowej nie we wszystkich województwach są ustawowo wolne, ale dla działów handlowych są operacyjnie istotne. AI Agent zna kalendarz na lokalizację i giełdę i uwzględnia dni wolne od sesji przy planowaniu obsady automatycznie - bez ręcznego uzgadniania kalendarzy.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Emerytury pomostowe w modelu blokowym</h3>
<p class="text-body text-gosign-text mt-2">Emerytury pomostowe są w sektorze finansowym powszechne. AI Agent oblicza uprawnienie urlopowe prawidłowo według fazy: pełne uprawnienie w fazie pracy, brak uprawnienia w fazie wolnej (model blokowy). Przy modelu częściowym: proporcjonalne uprawnienie przez cały okres trwania. Skutki dla ZUS są zgłaszane do systemu płacowego.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Pięć systemów wynagradzania równolegle</h3>
<p class="text-body text-gosign-text mt-2">Układ zbiorowy banków, układ zbiorowy ubezpieczeń, umowy pozataryfowe, kadra kierownicza, zarząd - każdy system ma własne regulacje urlopowe i urlopy specjalne. AI Agent rozpoznaje system z danych kadrowych i stosuje prawidłowy zestaw reguł. Jeden Agent dla wszystkich pięciu systemów.</p>
</div>
</div>
</div>
</section>

<!-- Decision Flow -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Jeden wniosek urlopowy w sektorze finansowym. 10 kroków decyzyjnych.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Trader składa wniosek urlopowy. Leave Decision Layer rozkłada proces na pojedyncze kroki decyzyjne:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Krok</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decyzja</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decydent</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Uzasadnienie</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Klasyfikacja typu nieobecności</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent rozpoznaje: urlop wypoczynkowy, obowiązkowe zwolnienie, faza emerytury pomostowej lub urlop specjalny</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Rozpoznanie systemu wynagradzania</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent rozpoznaje: układ banki, układ ubezpieczenia, pozataryfowy, kadra kierownicza lub zarząd</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Obliczenie uprawnienia urlopowego</td><td class="py-3 px-4">System reguł</td><td class="py-3 px-4">26 dni podstawa (Kodeks Pracy) lub indywidualne uprawnienie (pozataryfowy/zarząd) + korekta emerytur pomostowych</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Sprawdzenie obowiązkowego zwolnienia</td><td class="py-3 px-4">System reguł</td><td class="py-3 px-4">Stanowisko handlowe? Minimalny czas bloku osiągnięty? Obowiązkowe zwolnienie w bieżącym roku już zrealizowane?</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Sprawdzenie obowiązkowych bloków KNF</td><td class="py-3 px-4">System reguł</td><td class="py-3 px-4">Stanowisko istotne dla ryzyka? Ciągły blok obowiązkowy już zaplanowany?</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Sprawdzenie dni sesji giełdowej i obsady</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent sprawdza kalendarz handlowy, minimalną obsadę działu handlowego, regulację zastępstw</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Wygenerowanie rekomendacji zatwierdzenia</td><td class="py-3 px-4">AI rekomenduje, człowiek decyduje</td><td class="py-3 px-4">Wszystkie reguły i sprawdzenia compliance spełnione: rekomendacja zatwierdzenia. Konflikt compliance: eskalacja</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">Sprawdzenie progu procedury powrotu</td><td class="py-3 px-4">System reguł</td><td class="py-3 px-4">Ponad 30 dni niezdolności w 12 miesiącach krocząco. Automatyczny trigger do HR i Rady Zakładowej</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Obliczenie wynagrodzenia chorobowego</td><td class="py-3 px-4">System reguł</td><td class="py-3 px-4">33 dni pracodawca, od kolejnego dnia zasiłek ZUS, sprawdzenie uzupełnienia wg układu zbiorowego</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Wygenerowanie wpisu audytowego</td><td class="py-3 px-4">System reguł</td><td class="py-3 px-4">Kompletny akt decyzyjny: typ nieobecności, system wynagradzania, status compliance, sprawdzenie KNF, wynik</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Symulacja -->
<section id="simulation" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Symulacja</p>
<h2 class="text-h1 font-bold text-white">Przeliczone dla wolumenów sektora finansowego</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Skonfigurowaliśmy Leave Decision Layer z realistycznymi parametrami sektora finansowego. Obowiązkowe zwolnienie, obowiązkowe bloki KNF, dni wolne od sesji, emerytury pomostowe.</p>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Parametry symulacji</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Pracownicy</td><td class="py-3 px-4">5 000 do 80 000+ (handel, operacje, administracja)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Układy zbiorowe</td><td class="py-3 px-4">ZBP banki, ZUP ubezpieczenia, umowy pozataryfowe, kadra kierownicza</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Regulacje</td><td class="py-3 px-4">Wymogi KNF, obowiązkowe zwolnienie, zasada czterech oczu</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Typy nieobecności</td><td class="py-3 px-4">Urlop wypoczynkowy, obowiązkowe zwolnienie, emerytura pomostowa, urlop szkoleniowy, urlop specjalny</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Ograniczenia</td><td class="py-3 px-4">Zasada czterech oczu, dni wolne od sesji, minimalna obsada handlu</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Absencja chorobowa</td><td class="py-3 px-4">Średnia branżowa usługi finansowe (ZUS/GUS)</td></tr>
</tbody>
</table>
</div>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Przed / po</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th scope="col" class="text-left py-3 px-4 font-semibold text-white">Wymiar</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manualnie</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Czas przetwarzania wniosku urlopowego</td><td class="py-3 px-4">1-3 dni</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 30 sekund</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Zero-Touch-Quote</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">85%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Pominięty obowiązkowy blok KNF</td><td class="py-3 px-4">8-15% (ręczne śledzenie)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">0% (automatyczny monitoring terminów)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Obowiązkowe zwolnienie bez luk</td><td class="py-3 px-4">Ręcznie sprawdzane</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatycznie, gotowe na kontrolę KNF</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Przekroczenia terminu procedury powrotu</td><td class="py-3 px-4">12-18%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">0% (automatyczny trigger)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Gotowość audytowa</td><td class="py-3 px-4">Manualnie rekonstruowana</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatycznie generowana</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">Wymogi KNF. ZBP banki / ZUP ubezpieczenia. Absencja chorobowa: ZUS/GUS. Wyniki symulacji: model obliczeniowy Gosign.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">W symulacji Decision Layer osiąga Zero-Touch-Quote 85%. Pozostałe 15% to wyjątki istotne dla compliance: konflikty obowiązkowego zwolnienia, przejścia faz emerytur pomostowych, indywidualne umowy pozataryfowe. Dla 85% dostępny jest kompletny, gotowy na kontrolę KNF akt decyzyjny.</p>
</div>
</section>

<!-- Architektura -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Architektura i implementacja</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">Leave Decision Layer działa w pełni w Państwa infrastrukturze. Dla sektora finansowego oznacza to: połączenie z kalendarzem handlowym, śledzenie compliance KNF, monitoring obowiązkowego zwolnienia i ciągły Audit Trail. Typowe projekty pilotażowe startują z jednym systemem wynagradzania i rozszerzają na wszystkie grupy pracownicze.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/pl/uslugi/hr-agent/leave-absence-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Leave Decision Layer przegląd &rarr;</a>
<a href="/pl/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Architektura Decision Layer &rarr;</a>
<a href="/pl/uslugi/infrastruktura/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infrastruktura szczegółowo &rarr;</a>
<a href="/pl/governance/co-determination/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Współdecydowanie i Rada Zakładowa &rarr;</a>
<a href="/pl/uslugi/hr-agent/payroll-decision-layer/financial-services/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Payroll Decision Layer Finanse &rarr;</a>
</div>
</div>
</section>


<!-- Weitere Agent-Lösungen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Więcej rozwiązań agentowych</h2>
<p class="text-body-lg text-gosign-text-light mt-4">HR Agents to część naszego portfolio agentów. Dla finansów i innych obszarów oferujemy wyspecjalizowane rozwiązania.</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8 max-w-content">
<a href="/pl/hr-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR & People Operations</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Wszystkie HR Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Zgodność z radą zakładową.</p>
</a>
<a href="/pl/finance-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Finance & Accounting</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Finance AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Przetwarzanie dokumentów, księgowanie, amortyzacja, korekty. Integracja z systemami ERP.</p>
</a>
<a href="/pl/kontakt/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Indywidualnie</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Co-Build dla Twojego procesu</h3>
<p class="text-body text-gosign-text-light mt-2">Compliance, operacje, shared services - rozwijamy agentów w modelu co-build.</p>
</a>
</div>
</div>
</section>

<!-- Pogłębienie -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Pogłębienie w Agent Briefing (Magazyn Gosign)</h2>
<p class="text-body text-gosign-text-light mb-6">Nasza seria artykułów eksperckich dla decydentów wdrażających AI Agents w przedsiębiorstwie.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/pl/magazyn/rada-zakladowa-ai-mitbestimmung/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Współdecydowanie</p>
<p class="text-body font-semibold text-gosign-dark">Rada Zakładowa i AI - współdecydowanie jako ograniczenie architektury</p>
</a>
<a href="/pl/magazyn/agent-governance-hr/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Agent Governance dla HR - dlaczego systemy reguł są ważniejsze niż modele</p>
</a>
<a href="/pl/magazyn/decision-layer-wyjasnienie/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Podstawy</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - czym jest i dlaczego każdy AI Agent w przedsiębiorstwie go potrzebuje?</p>
</a>
</div>
</div>
</section>

<!-- Inne branże -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Leave Decision Layer w innych branżach</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Każda branża ma własne układy zbiorowe, własne typy nieobecności i własne czynniki złożoności. Decision Layer jest ten sam. Konfiguracja jest specyficzna dla branży.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/pl/uslugi/hr-agent/leave-absence-decision-layer/chemicals/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Chemia</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">Układy ponadzakładowe, dodatek urlopowy ZFŚS, urlop dodatkowy zmianowy, procedura powrotu przy substancjach szkodliwych</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">83% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Szczegóły &rarr;</span>
</div>
</a>
<a href="/pl/uslugi/hr-agent/leave-absence-decision-layer/aviation/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Lotnictwo</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">Wiele związków zawodowych, EASA FTL obowiązkowe odpoczynki, Medical Grounding, Crew-Pairing</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">78% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Szczegóły &rarr;</span>
</div>
</a>
<a href="/pl/uslugi/hr-agent/leave-absence-decision-layer/retail/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Handel</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">Praca 6 dni w tygodniu, 64% niepełny etat, blokady urlopowe sezon, uprawnienia pracowników na zleceniu</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">87% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Szczegóły &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- AI Leave Agent Handel - zarządzanie nieobecnościami ---
> Leave Decision Layer dla handlu detalicznego. 6 dni w tygodniu, 64% niepełny etat, blokady sezonowe, regionalne układy. 87% Zero-Touch.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/pl/dlaczego-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Każda decyzja możliwa do prześledzenia</p>
</div>
</a>
<a href="/pl/dlaczego-gosign/#infrastruktura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Twoja infrastruktura</p>
<p class="text-xs text-gosign-text-light">Bez SaaS. Bez vendor-lock-in.</p>
</div>
</a>
<a href="/pl/dlaczego-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Bez ryzyka US-cloud</p>
</div>
</a>
</div>
</div>
</div>
<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Leave Decision Layer - branże">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/pl/uslugi/hr-agent/leave-absence-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Leave Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/pl/uslugi/hr-agent/leave-absence-decision-layer/chemicals/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Chemia</a>
<a href="/pl/uslugi/hr-agent/leave-absence-decision-layer/aviation/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Lotnictwo</a>
<a href="/pl/uslugi/hr-agent/leave-absence-decision-layer/financial-services/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Finanse</a>
<a href="/pl/uslugi/hr-agent/leave-absence-decision-layer/retail/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Handel</a>
</div>
</div>
</nav>

<!-- Złożoność -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">16</span>
<p class="text-small text-gosign-text-light mt-1">Regionalnych układów zbiorowych</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">87%</span>
<p class="text-small text-gosign-text-light mt-1">Zero-Touch-Quote</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">64%</span>
<p class="text-small text-gosign-text-light mt-1">Udział niepełnego etatu</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
<span class="w-4 h-2 rounded-sm bg-gosign-border"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">Wysoka złożoność reguł</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">Regionalne układy zbiorowe handlu (Solidarność / NSZZ Pracowników Handlu), 16 województw. Zero-Touch: model symulacyjny Gosign.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Co klasyfikuje Agent</p>
<h2 class="text-h1 font-bold text-gosign-dark">Pięć wymiarów, jeden Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Praca 6-dniowa z sobotami, 64% niepełnego etatu, sezonowe blokady urlopowe, zmienne modele zatrudnienia (umowa o pracę, zlecenie, praca tymczasowa) i regionalne układy zbiorowe. Tak AI Agent ją rozwiązuje:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Praca 6-dniowa i przeliczenie na dni robocze</h3>
<p class="text-body text-gosign-text mt-2">W handlu detalicznym sobota jest regularnym dniem pracy. Kodeks Pracy Art. 154 przyznaje 26 dni urlopu przy stażu powyżej 10 lat. AI Agent rozpoznaje model czasu pracy z danych kadrowych i przelicza uprawnienie automatycznie na dni robocze. Przy zmianie między tygodniem 5- a 6-dniowym: proporcjonalne przeliczenie od daty zmiany.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Obliczenie urlopu niepełnoetatowego dla 64% załogi</h3>
<p class="text-body text-gosign-text mt-2">Ponad połowa wszystkich pracowników w handlu pracuje na niepełny etat - z różnymi modelami. AI Agent oblicza proporcjonalne uprawnienie urlopowe na model: 3-dniowy tydzień, 4-dniowy tydzień, godzinowy niepełny etat, elastyczny niepełny etat. System reguł stosuje prawidłową formułę, spójnie w całej sieci placówek.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Sezonowe blokady urlopowe</h3>
<p class="text-body text-gosign-text mt-2">Okres świąteczny (listopad do grudnia), wyprzedaże, inwentaryzacja - handel zna jasne okresy blokad. AI Agent zna okresy blokad na placówkę (nie wszystkie placówki mają te same blokady) i sprawdza każdy wniosek wobec nich. Wyjątki są możliwe, ale wymagają decyzji przełożonego.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Zmienne modele zatrudnienia</h3>
<p class="text-body text-gosign-text mt-2">W handlu współistnieją umowy o pracę (pełne uprawnienia urlopowe wg Kodeksu Pracy), umowy zlecenie (brak ustawowego urlopu, ale często regulamin wewnętrzny) i praca tymczasowa. AI Agent rozróżnia typ umowy z danych kadrowych i stosuje właściwe reguły. Dla planowania obsady oblicza średnią godzinową z ostatnich 3 miesięcy - niezależnie od typu umowy.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Regionalne układy zbiorowe</h3>
<p class="text-body text-gosign-text mt-2">Każde województwo może mieć własny układ zbiorowy handlu, czasem z różnicami regionalnymi. AI Agent rozpoznaje lokalizację placówki i stosuje prawidłowy regionalny układ zbiorowy. Przy przeniesieniu między placówkami w różnych województwach: automatyczna zmiana układu z przeliczeniem uprawnień.</p>
</div>
</div>
</div>
</section>

<!-- Decision Flow -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Jeden wniosek urlopowy w handlu. 10 kroków decyzyjnych.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Pracownik niepełnoetatowy w placówce składa wniosek urlopowy. Leave Decision Layer rozkłada proces na pojedyncze kroki decyzyjne:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Krok</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decyzja</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decydent</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Uzasadnienie</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Klasyfikacja typu nieobecności</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent rozpoznaje: urlop wypoczynkowy, urlop szkoleniowy, urlop specjalny lub dzień wyrównawczy</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Rozpoznanie regionalnego układu zbiorowego</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent rozpoznaje lokalizację placówki i stosuje prawidłowy regionalny układ zbiorowy</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Obliczenie uprawnienia urlopowego</td><td class="py-3 px-4">System reguł</td><td class="py-3 px-4">Uprawnienie wg układu przeliczone na dni robocze (tydzień 5- lub 6-dniowy), współczynnik niepełnego etatu, rozróżnienie typu umowy</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Sprawdzenie blokady urlopowej</td><td class="py-3 px-4">System reguł</td><td class="py-3 px-4">Okres świąteczny, wyprzedaże, inwentaryzacja - blokady specyficzne dla placówki</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Sprawdzenie minimalnej obsady placówki</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent sprawdza plan obsady: często tylko 2-3 osoby na placówkę, każda nieobecność się liczy</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Rozpoznanie konfliktu zespołowego</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent sprawdza równoległe wnioski, podział wakacji szkolnych (aspekty socjalne)</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Wygenerowanie rekomendacji zatwierdzenia</td><td class="py-3 px-4">AI rekomenduje, człowiek decyduje</td><td class="py-3 px-4">Wszystkie reguły spełnione: rekomendacja zatwierdzenia. Blokada lub minimalna obsada naruszona: eskalacja</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">Sprawdzenie progu procedury powrotu</td><td class="py-3 px-4">System reguł</td><td class="py-3 px-4">Ponad 30 dni niezdolności w 12 miesiącach krocząco. Automatyczny trigger do HR i Rady Zakładowej</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Obliczenie wynagrodzenia chorobowego</td><td class="py-3 px-4">System reguł</td><td class="py-3 px-4">33 dni pracodawca, od kolejnego dnia zasiłek ZUS, reguły specjalne dla umów cywilnoprawnych</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Wygenerowanie wpisu audytowego</td><td class="py-3 px-4">System reguł</td><td class="py-3 px-4">Kompletny akt decyzyjny: typ nieobecności, układ zbiorowy, współczynnik niepełnego etatu, sprawdzenie blokady, wynik</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Symulacja -->
<section id="simulation" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Symulacja</p>
<h2 class="text-h1 font-bold text-white">Przeliczone dla wolumenów handlowych</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Skonfigurowaliśmy Leave Decision Layer z realistycznymi parametrami handlu. Regionalne układy zbiorowe, praca 6-dniowa, 64% niepełny etat, sezonowe blokady urlopowe.</p>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Parametry symulacji</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Pracownicy</td><td class="py-3 px-4">5 000 do 100 000+ (placówki, magazyny, administracja)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Układy zbiorowe</td><td class="py-3 px-4">Regionalne układy zbiorowe handlu (Solidarność / NSZZ Pracowników Handlu)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Modele czasu pracy</td><td class="py-3 px-4">Tydzień 5-dniowy, 6-dniowy, niepełny etat (3/4 dni), umowa zlecenie, praca tymczasowa</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Udział niepełnego etatu</td><td class="py-3 px-4">64% załogi</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Blokady urlopowe</td><td class="py-3 px-4">Okres świąteczny, wyprzedaże, inwentaryzacja (specyficzne dla placówki)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Absencja chorobowa</td><td class="py-3 px-4">Średnia branżowa handel detaliczny (ZUS/GUS)</td></tr>
</tbody>
</table>
</div>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Przed / po</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th scope="col" class="text-left py-3 px-4 font-semibold text-white">Wymiar</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manualnie</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Czas przetwarzania wniosku urlopowego</td><td class="py-3 px-4">1-3 dni</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 30 sekund</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Zero-Touch-Quote</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">87%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Błędy obliczenia niepełnego etatu</td><td class="py-3 px-4">5-12% (ręczne przeliczenia)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 0,1% (oparte na regułach)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Ostrzeżenia o przepadku urlopu</td><td class="py-3 px-4">Często zapominane przy niepełnym etacie</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatycznie, terminowo, indywidualnie</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Przekroczenia terminu procedury powrotu</td><td class="py-3 px-4">12-18%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">0% (automatyczny trigger)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Gotowość audytowa</td><td class="py-3 px-4">Manualnie rekonstruowana</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatycznie generowana</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">Regionalne układy zbiorowe handlu (Solidarność / NSZZ). Absencja chorobowa: ZUS/GUS. Udział niepełnego etatu: PIH Polska Izba Handlu. Wyniki symulacji: model obliczeniowy Gosign.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">W symulacji Decision Layer osiąga Zero-Touch-Quote 87%. Najwyższy wskaźnik ze wszystkich czterech branż - ponieważ handel jest wprawdzie wolumenowo silny (dużo wniosków), ale pojedyncze decyzje są rozwiązywalne na podstawie reguł. Pozostałe 13% to rzeczywiste wyjątki: konflikty wakacji szkolnych, wyjątki od blokad, procedury powrotu. Dla 87% dostępny jest kompletny, weryfikowalny akt decyzyjny.</p>
</div>
</section>

<!-- Architektura -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Architektura i implementacja</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">Leave Decision Layer działa w pełni w Państwa infrastrukturze. Dla handlu oznacza to: połączenie z planowaniem obsady placówek, przetwarzanie regionalnych układów zbiorowych, rozpoznawanie modeli niepełnego etatu i ciągły Audit Trail. Typowe projekty pilotażowe startują z jednym regionem i grupą placówek.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/pl/uslugi/hr-agent/leave-absence-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Leave Decision Layer przegląd &rarr;</a>
<a href="/pl/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Architektura Decision Layer &rarr;</a>
<a href="/pl/uslugi/infrastruktura/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infrastruktura szczegółowo &rarr;</a>
<a href="/pl/governance/co-determination/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Współdecydowanie i Rada Zakładowa &rarr;</a>
<a href="/pl/uslugi/hr-agent/payroll-decision-layer/retail/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Payroll Decision Layer Handel &rarr;</a>
</div>
</div>
</section>


<!-- Weitere Agent-Lösungen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Więcej rozwiązań agentowych</h2>
<p class="text-body-lg text-gosign-text-light mt-4">HR Agents to część naszego portfolio agentów. Dla finansów i innych obszarów oferujemy wyspecjalizowane rozwiązania.</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8 max-w-content">
<a href="/pl/hr-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR & People Operations</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Wszystkie HR Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Zgodność z radą zakładową.</p>
</a>
<a href="/pl/finance-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Finance & Accounting</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Finance AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Przetwarzanie dokumentów, księgowanie, amortyzacja, korekty. Integracja z systemami ERP.</p>
</a>
<a href="/pl/kontakt/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Indywidualnie</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Co-Build dla Twojego procesu</h3>
<p class="text-body text-gosign-text-light mt-2">Compliance, operacje, shared services - rozwijamy agentów w modelu co-build.</p>
</a>
</div>
</div>
</section>

<!-- Pogłębienie -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Pogłębienie w Agent Briefing (Magazyn Gosign)</h2>
<p class="text-body text-gosign-text-light mb-6">Nasza seria artykułów eksperckich dla decydentów wdrażających AI Agents w przedsiębiorstwie.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/pl/magazyn/rada-zakladowa-ai-mitbestimmung/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Współdecydowanie</p>
<p class="text-body font-semibold text-gosign-dark">Rada Zakładowa i AI - współdecydowanie jako ograniczenie architektury</p>
</a>
<a href="/pl/magazyn/agent-governance-hr/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Agent Governance dla HR - dlaczego systemy reguł są ważniejsze niż modele</p>
</a>
<a href="/pl/magazyn/decision-layer-wyjasnienie/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Podstawy</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - czym jest i dlaczego każdy AI Agent w przedsiębiorstwie go potrzebuje?</p>
</a>
</div>
</div>
</section>

<!-- Inne branże -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Leave Decision Layer w innych branżach</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Każda branża ma własne układy zbiorowe, własne typy nieobecności i własne czynniki złożoności. Decision Layer jest ten sam. Konfiguracja jest specyficzna dla branży.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/pl/uslugi/hr-agent/leave-absence-decision-layer/chemicals/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Chemia</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">Układy ponadzakładowe, dodatek urlopowy ZFŚS, urlop dodatkowy zmianowy, procedura powrotu przy substancjach szkodliwych</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">83% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Szczegóły &rarr;</span>
</div>
</a>
<a href="/pl/uslugi/hr-agent/leave-absence-decision-layer/aviation/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Lotnictwo</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">Wiele związków zawodowych, EASA FTL obowiązkowe odpoczynki, Medical Grounding, Crew-Pairing</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">78% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Szczegóły &rarr;</span>
</div>
</a>
<a href="/pl/uslugi/hr-agent/leave-absence-decision-layer/financial-services/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Finanse</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">Obowiązkowe zwolnienie, bloki urlopowe KNF, dni wolne od sesji giełdowej, emerytury pomostowe</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">85% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Szczegóły &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- AI Leave & Absence Decision Layer ---
> Decision Layer rozkłada każdy proces nieobecności na kroki decyzyjne. Oparty na regułach, audytowalny, 78-87% Zero-Touch.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/pl/dlaczego-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Każda decyzja możliwa do prześledzenia</p>
</div>
</a>
<a href="/pl/dlaczego-gosign/#infrastruktura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Twoja infrastruktura</p>
<p class="text-xs text-gosign-text-light">Bez SaaS. Bez vendor-lock-in.</p>
</div>
</a>
<a href="/pl/dlaczego-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Bez ryzyka US-cloud</p>
</div>
</a>
</div>
</div>
</div>
<!-- Problem -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">12,5</span>
<p class="text-small text-gosign-text-light mt-1">Dni chorobowych na pracownika (2024)</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">20+</span>
<p class="text-small text-gosign-text-light mt-1">Typów nieobecności (ustawowe, zbiorowe, zakładowe)</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">5-15</span>
<p class="text-small text-gosign-text-light mt-1">Mikro-decyzji na proces</p>
</div>
<p class="sm:col-span-3 text-xs text-gosign-text-light">Absencja chorobowa 2024: ZUS / GUS. Typy nieobecności: Kodeks Pracy Art. 152-173, ustawa o świadczeniach pieniężnych z ubezpieczenia społecznego, układy zbiorowe + porozumienia zakładowe.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Problem</p>
<h2 class="text-h1 font-bold text-gosign-dark">Dlaczego systemy Absence zawodzą w złożonych organizacjach</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">SAP SuccessFactors Time Off rejestruje nieobecności. Workday Absence oblicza salda. Każdy HRIS potrafi obsłużyć workflow zatwierdzania. Ale w organizacjach z wieloma układami zbiorowymi, 16 województwami, modelami niepełnego etatu i obowiązkami procedury powrotu po długotrwałej nieobecności - rejestracja nie jest problemem. Problem stanowi decyzja przed nią: jakie uprawnienie obowiązuje? Jaka polityka ma pierwszeństwo? Czy należy uruchomić procedurę powrotu?</p>
<div class="mt-10">
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">20+ typów nieobecności</h3>
<p class="text-small text-gosign-text-light mt-2">Urlop wypoczynkowy, urlop na żądanie, urlop okolicznościowy, urlop szkoleniowy, urlop macierzyński, urlop rodzicielski, urlop opiekuńczy, opieka nad dzieckiem (Art. 188 KP), zwolnienie lekarskie, urlop bezpłatny. Każdy typ ma własne podstawy prawne, własne terminy, własne reguły obliczania. 16 województw ze specyficznymi świętami regionalnymi. Żaden specjalista nie zna wszystkich reguł we wszystkich układach zbiorowych.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">Każde e-ZLA uruchamia 5 procesów następczych</h3>
<p class="text-small text-gosign-text-light mt-2">Przetworzenie elektronicznego zwolnienia lekarskiego z ZUS, sprawdzenie okresu wynagrodzenia chorobowego (33 dni pracodawca, od 34 dnia ZUS), monitorowanie progu długotrwałej nieobecności, informowanie planowania zmian, zapis zwrotny do payroll. Manualnie: przerwy między pięcioma systemami. Zapomniane procedury powrotu. Błędne granice wynagrodzenia chorobowego.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">Zero przejrzystości decyzji</h3>
<p class="text-small text-gosign-text-light mt-2">Gdy Rada Zakładowa pyta: dlaczego wniosek urlopowy pracownika X został odrzucony? Jaka reguła obowiązywała? Kto podjął decyzję? Brakuje dowodu. Systemy Absence dokumentują wyniki - zatwierdzony lub odrzucony wniosek. Nie dokumentują decyzji, które do nich prowadziły.</p>
</div>
</div>
</div>
</div>
</section>

<!-- Decision Layer Zasada -->
<section id="decision-layer" class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Decision Layer</p>
<h2 class="text-h1 font-bold text-gosign-dark">Każdy proces nieobecności. Rozłożony na kroki decyzyjne.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Leave & Absence Decision Layer rozkłada każdy proces nieobecności na pojedyncze kroki decyzyjne. Dla każdego kroku jest zdefiniowane, kto decyduje: AI Agent klasyfikuje typy nieobecności, rozpoznaje konflikty i monitoruje progi - niezawodniej i szybciej niż jakikolwiek specjalista. System reguł oblicza uprawnienia, terminy i przeliczenia - deterministycznie i reprodukowalnie. Człowiek pozostaje tam, gdzie Rada Zakładowa (prawo do konsultacji), Kodeks Pracy lub ochrona danych zdrowotnych wymagają ludzkiej decyzji.</p>

<div class="mt-10 overflow-x-auto">
<table class="w-full text-left text-body">
<thead>
<tr class="border-b-2 border-gosign-dark">
<th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Krok</th>
<th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Decyzja</th>
<th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Decydent</th>
<th scope="col" class="py-3 font-bold text-gosign-dark">Uzasadnienie</th>
</tr>
</thead>
<tbody class="text-gosign-text-light">
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-medium text-gosign-dark">1</td>
<td class="py-3 pr-4">Klasyfikacja typu nieobecności</td>
<td class="py-3 pr-4 font-medium">AI Agent</td>
<td class="py-3">Agent rozpoznaje z wniosku: urlop wypoczynkowy, urlop na żądanie, urlop okolicznościowy, urlop szkoleniowy, opieka nad dzieckiem? Przypisuje prawidłową podstawę prawną</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-medium text-gosign-dark">2</td>
<td class="py-3 pr-4">Obliczenie uprawnienia (hierarchia)</td>
<td class="py-3 pr-4 font-medium">System reguł</td>
<td class="py-3">Kodeks Pracy + układ zbiorowy + porozumienie zakładowe + umowa o pracę = całkowite uprawnienie. Zastosowanie zasady korzystności</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-medium text-gosign-dark">3</td>
<td class="py-3 pr-4">Ustalenie pozostałego uprawnienia</td>
<td class="py-3 pr-4 font-medium">System reguł</td>
<td class="py-3">Uprawnienie - wykorzystane - zaplanowane = dostępne. Przy zmianie wymiaru etatu: proporcjonalne przeliczenie wg orzecznictwa Sądu Najwyższego</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-medium text-gosign-dark">4</td>
<td class="py-3 pr-4">Sprawdzenie konfliktu zespołowego i obsady minimalnej</td>
<td class="py-3 pr-4 font-medium">AI Agent</td>
<td class="py-3">Agent sprawdza kalendarz zespołu, urlopy zakładowe, minimalną obsadę. Rozpoznaje nakładanie się i oblicza dostępną wydajność</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-medium text-gosign-dark">5</td>
<td class="py-3 pr-4">Wygenerowanie rekomendacji zatwierdzenia</td>
<td class="py-3 pr-4 font-medium">AI Agent + System reguł</td>
<td class="py-3">Wszystkie reguły spełnione - "Rekomendacja zatwierdzenia" do przełożonego. Przekazanie z kontekstem i rekomendacją</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-medium text-gosign-dark">6</td>
<td class="py-3 pr-4">Eskalacja konfliktu urlopowego</td>
<td class="py-3 pr-4 font-medium">Człowiek</td>
<td class="py-3">Dwóch pracowników, ten sam tydzień, obsada minimalna zagrożona. Względy społeczne (dzieci szkolne, samotni rodzice) wymagają ludzkiego uznania</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-medium text-gosign-dark">7</td>
<td class="py-3 pr-4">Obliczenie okresu wynagrodzenia chorobowego</td>
<td class="py-3 pr-4 font-medium">System reguł</td>
<td class="py-3">33 dni pracodawca (14 dni dla pracowników 50+), od kolejnego dnia zasiłek ZUS. Przy ponownym zachorowaniu: reguła kontynuacji</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-medium text-gosign-dark">8</td>
<td class="py-3 pr-4">Sprawdzenie progu procedury powrotu</td>
<td class="py-3 pr-4 font-medium">System reguł</td>
<td class="py-3">Ponad 30 dni niezdolności w 12 miesiącach (krocząco). Automatyczne powiadomienie HR. Dane zdrowotne odseparowane</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-medium text-gosign-dark">9</td>
<td class="py-3 pr-4">Przetworzenie e-ZLA i zapis zwrotny</td>
<td class="py-3 pr-4 font-medium">System reguł</td>
<td class="py-3">Elektroniczne zwolnienie lekarskie z ZUS - zaksięgowanie nieobecności - informacja do payroll i planowania zmian - aktualizacja kalendarza</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 pr-4 font-medium text-gosign-dark">10</td>
<td class="py-3 pr-4">Wygenerowanie wpisu audytowego</td>
<td class="py-3 pr-4 font-medium">System reguł</td>
<td class="py-3">Decyzja, podstawa prawna, decydent, znacznik czasu, hash danych wejściowych - append-only, podpis SHA-256</td>
</tr>
</tbody>
</table>
</div>

<p class="text-body text-gosign-text mt-8 max-w-narrow font-semibold">5 do 15 kroków na proces nieobecności. AI Agent każdy z nich realizuje lepiej i szybciej niż specjalista. Mimo to człowiek pozostaje w zdefiniowanych miejscach procesu - nie dlatego, że potrafi to lepiej, ale dlatego, że Rada Zakładowa, Kodeks Pracy lub ochrona danych zdrowotnych tego wymagają. Przy 10 000 pracownikach to ponad 50 000 udokumentowanych mikro-decyzji miesięcznie.</p>

<div class="mt-10">
<div class="grid grid-cols-1 sm:grid-cols-2 gap-6">
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">AI klasyfikuje. System reguł oblicza.</h3>
<p class="text-small text-gosign-text-light mt-2">AI Agent rozpoznaje: jaki typ nieobecności? Jaka podstawa prawna? Czy istnieje konflikt zespołowy? Czy pracownik osiągnął próg długotrwałej nieobecności? Tę klasyfikację realizuje niezawodniej niż jakikolwiek specjalista. Obliczanie uprawnień, terminów i przeliczeń przebiega przez wersjonowane Decision Tables - deterministycznie, reprodukowalnie, audytowalnie.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">Dane zdrowotne architektonicznie odseparowane</h3>
<p class="text-small text-gosign-text-light mt-2">Dane zdrowotne to szczególna kategoria (RODO Art. 9). Żadnego mieszania danych urlopowych i diagnoz. Moduł procedury powrotu ma osobną bazę danych, osobny krąg dostępu, osobne terminy usuwania. Agent nieobecnościowy widzi tylko: obowiązek procedury Tak/Nie. Żadnych diagnoz.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">AI Agent, system reguł lub człowiek</h3>
<p class="text-small text-gosign-text-light mt-2">AI Agent klasyfikuje stany faktyczne i rozpoznaje wzorce - niezawodniej niż jakikolwiek specjalista. System reguł oblicza uprawnienia i terminy. Człowiek pozostaje tam, gdzie Rada Zakładowa (prawo do konsultacji), Kodeks Pracy lub ochrona danych zdrowotnych wymagają ludzkiej decyzji.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">Ostrzeżenie o wygaśnięciu urlopu - automatyczne</h3>
<p class="text-small text-gosign-text-light mt-2">Orzecznictwo Sądu Najwyższego wymaga indywidualnego, terminowego ostrzeżenia o grożącym wygaśnięciu urlopu. Bez dowodu ostrzeżenia urlop nie wygasa. Decision Layer generuje ostrzeżenia automatycznie, dokumentuje doręczenie i eskaluje w przypadku braku dowodu.</p>
</div>
</div>
</div>
</div>
</section>

<!-- Governance & Audit -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<h2 class="text-h1 font-bold text-gosign-dark">Nie dokumentowane wstecz. Powstające w procesie.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Gdy Rada Zakładowa pyta "Dlaczego wniosek urlopowy został odrzucony?" - odpowiedź "obsada minimalna" nie wystarczy. Jaka reguła obsady? Jaki okres? Kto już miał zatwierdzenie? Leave Decision Layer generuje na każdą mikrodecyzję akt decyzyjny, który odpowiada na te pytania: input, zastosowana reguła merytoryczna wraz z wersją, wynik, znacznik czasu i ścieżka podważenia. Ten sam akt sprawia, że da się też spełnić wyjaśnienie pojedynczej decyzji wg art. 86 EU AI Act - dla osoby, której decyzja dotyczy, Rady Zakładowej i biegłego rewidenta.</p>

<!-- Audit Trail Card -->
<div class="mt-10 bg-gosign-dark rounded-card p-6 sm:p-8">
<div class="flex items-start gap-4 mb-6">
<svg class="w-8 h-8 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12h6m-6 4h6m2 5H7a2 2 0 01-2-2V5a2 2 0 012-2h5.586a1 1 0 01.707.293l5.414 5.414a1 1 0 01.293.707V19a2 2 0 01-2 2z" />
</svg>
<div>
<h3 class="text-h3 font-bold text-white">Każda mikro-decyzja generuje wpis audytowy</h3>
<p class="text-small text-gosign-text-on-dark/70 mt-1">Append-only. Nic nie jest nadpisywane, nic usuwane. Przy korektach powstają wpisy stornujące i korygujące. Podpis SHA-256, w każdej chwili eksportowalny.</p>
</div>
</div>
<div class="grid grid-cols-2 sm:grid-cols-3 gap-3 sm:gap-4">
<div class="flex items-center gap-2.5">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span class="text-small text-gosign-text-on-dark/80">ID reguły + wersja</span>
</div>
<div class="flex items-center gap-2.5">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span class="text-small text-gosign-text-on-dark/80">Podstawa prawna (KP, układ, porozumienie)</span>
</div>
<div class="flex items-center gap-2.5">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span class="text-small text-gosign-text-on-dark/80">Dane wejściowe (wniosek, okres, zespół)</span>
</div>
<div class="flex items-center gap-2.5">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span class="text-small text-gosign-text-on-dark/80">Wynik (zatwierdzenie, odmowa, eskalacja)</span>
</div>
<div class="flex items-center gap-2.5">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span class="text-small text-gosign-text-on-dark/80">Decydent (system reguł / Agent / człowiek)</span>
</div>
<div class="flex items-center gap-2.5">
<svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg>
<span class="text-small text-gosign-text-on-dark/80">Hash danych wejściowych (reprodukowalny)</span>
</div>
</div>
</div>

<!-- Three Governance Pillars -->
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8">
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-3">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M15 12a3 3 0 11-6 0 3 3 0 016 0z" />
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M2.458 12C3.732 7.943 7.523 5 12 5c4.478 0 8.268 2.943 9.542 7-1.274 4.057-5.064 7-9.542 7-4.477 0-8.268-2.943-9.542-7z" />
</svg>
<div>
<h3 class="text-body font-semibold text-gosign-dark">Przejrzystość dla Rady Zakładowej</h3>
<p class="text-small text-gosign-text-light mt-2">Ustawa o radach pracowników: prawo do konsultacji w zakresie zasad urlopowych. System reguł jest przejrzysty, powody odmowy udokumentowane, raporty pseudonimizowane.</p>
<a href="/pl/governance/co-determination/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Współdecydowanie &rarr;</a>
</div>
</div>
</div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-3">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12l2 2 4-4m5.618-4.016A11.955 11.955 0 0112 2.944a11.955 11.955 0 01-8.618 3.04A12.02 12.02 0 003 9c0 5.591 3.824 10.29 9 11.622 5.176-1.332 9-6.03 9-11.622 0-1.042-.133-2.052-.382-3.016z" />
</svg>
<div>
<h3 class="text-body font-semibold text-gosign-dark">RODO Art. 9: dane zdrowotne odseparowane</h3>
<p class="text-small text-gosign-text-light mt-2">Moduł procedury powrotu architektonicznie oddzielony. Osobna baza danych, osobny krąg dostępu. Żadnych diagnoz w module nieobecności. Terminy usuwania konfigurowalne.</p>
<a href="/pl/governance/data-residency/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Rezydencja danych &rarr;</a>
</div>
</div>
</div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-3">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 5H7a2 2 0 00-2 2v12a2 2 0 002 2h10a2 2 0 002-2V7a2 2 0 00-2-2h-2M9 5a2 2 0 002 2h2a2 2 0 002-2M9 5a2 2 0 012-2h2a2 2 0 012 2m-6 9l2 2 4-4" />
</svg>
<div>
<h3 class="text-body font-semibold text-gosign-dark">Ostrzeżenie o wygaśnięciu urlopu - automatyczne</h3>
<p class="text-small text-gosign-text-light mt-2">Orzecznictwo Sądu Najwyższego: uprawnienie urlopowe nie wygasa bez indywidualnego ostrzeżenia. Decision Layer generuje ostrzeżenia automatycznie, dokumentuje doręczenie i eskaluje w przypadku braku dowodu.</p>
</div>
</div>
</div>
</div>
</div>
</section>

<!-- Integracja -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Integracja</p>
<h2 class="text-h1 font-bold text-gosign-dark">Łączy się z Państwa istniejącym krajobrazem systemowym</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Państwa systemy pozostają. Manualna praca decyzyjna przed nimi znika. Leave Decision Layer znajduje się pomiędzy systemami źródłowymi a HRIS - podejmuje decyzje, które dziś podejmują specjaliści.</p>

<div class="grid grid-cols-1 md:grid-cols-3 gap-6 mt-10">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<div class="flex items-center gap-3 mb-4">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M20 7l-8-4-8 4m16 0l-8 4m8-4v10l-8 4m0-10L4 7m8 4v10M4 7v10l8 4" />
</svg>
<h3 class="text-body font-semibold text-gosign-dark">Źródła danych</h3>
</div>
<ul class="space-y-2 text-small text-gosign-text-light">
<li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Dane kadrowe (SAP HCM, Workday, Comarch)</span></li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Ewidencja czasu pracy (ATOSS, Interflex)</span></li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>e-ZLA (elektroniczne zwolnienie lekarskie ZUS)</span></li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Planowanie zmian (ATOSS, SAP)</span></li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Baza układów zbiorowych i porozumień zakładowych</span></li>
</ul>
</div>
<div class="bg-gosign-dark border border-gosign-dark rounded-card p-6">
<div class="flex items-center gap-3 mb-4">
<svg class="w-6 h-6 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9.75 3.104v5.714a2.25 2.25 0 01-.659 1.591L5 14.5M9.75 3.104c-.251.023-.501.05-.75.082m.75-.082a24.301 24.301 0 014.5 0m0 0v5.714c0 .597.237 1.17.659 1.591L19.8 15.3M14.25 3.104c.251.023.501.05.75.082M19.8 15.3l-1.57.393A9.065 9.065 0 0112 15a9.065 9.065 0 00-6.23.693L5 14.5m14.8.8l1.402 1.402c1.232 1.232.65 3.318-1.067 3.611A48.309 48.309 0 0112 21c-2.773 0-5.491-.235-8.135-.687-1.718-.293-2.3-2.379-1.067-3.61L5 14.5" />
</svg>
<h3 class="text-body font-semibold text-white">Leave Decision Layer</h3>
</div>
<ul class="space-y-2 text-small text-gosign-text-on-dark/80">
<li>Klasyfikacja typu nieobecności</li>
<li>Obliczanie uprawnień (układ + porozumienie + prawo)</li>
<li>Sprawdzanie konfliktu zespołowego i obsady</li>
<li>Obliczanie okresu wynagrodzenia chorobowego</li>
<li>Monitorowanie progu długotrwałej nieobecności</li>
<li>Ostrzeżenie o wygaśnięciu urlopu</li>
<li>Przetworzenie e-ZLA + zapis zwrotny</li>
</ul>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<div class="flex items-center gap-3 mb-4">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M5.25 14.25h13.5m-13.5 0a3 3 0 01-3-3m3 3a3 3 0 100 6h13.5a3 3 0 100-6m-16.5-3a3 3 0 013-3h13.5a3 3 0 013 3m-19.5 0a4.5 4.5 0 01.9-2.7L5.737 5.1a3.375 3.375 0 012.7-1.35h7.126c1.062 0 2.062.5 2.7 1.35l2.587 3.45a4.5 4.5 0 01.9 2.7m0 0a3 3 0 01-3 3m0 3h.008v.008h-.008v-.008zm0-6h.008v.008h-.008v-.008zm-3 6h.008v.008h-.008v-.008zm0-6h.008v.008h-.008v-.008z" />
</svg>
<h3 class="text-body font-semibold text-gosign-dark">Systemy docelowe</h3>
</div>
<ul class="space-y-2 text-small text-gosign-text-light">
<li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>SAP SuccessFactors Time Off</span></li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Workday Absence Management</span></li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Payroll (Comarch Optima, SAP HCM)</span></li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Kalendarz (Microsoft 365, Google)</span></li>
<li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>DMS / Cyfrowa teczka personalna</span></li>
</ul>
</div>
</div>
</div>
</section>

<!-- Symulacje branżowe -->
<section id="symulacje" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Symulowane dla wolumenów Enterprise</p>
<h2 class="text-h1 font-bold text-white">Cztery branże. Przeliczone.</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Skonfigurowaliśmy Leave & Absence Decision Layer dla czterech branż z realistycznymi układami zbiorowymi, regulacjami nieobecnościowymi i strukturami personalnymi. Każda karta pokazuje parametry symulacji i wynik.</p>

<div class="grid grid-cols-1 md:grid-cols-2 gap-6 mt-10">
<a href="/pl/uslugi/hr-agent/leave-absence-decision-layer/chemicals/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors">
<div class="flex items-center justify-between mb-4">
<h3 class="text-h3 font-bold text-white">Chemia</h3>
<div class="flex gap-1">
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>

</div>
</div>
<ul class="space-y-1.5 text-small text-gosign-text-on-dark/70">
<li>Układy ponadzakładowe, dodatek urlopowy z ZFŚS</li>
<li>Urlop dodatkowy za pracę zmianową 2-5 dni</li>
<li>Procedura powrotu przy ekspozycji na substancje szkodliwe</li>
<li>Porozumienia zakładowe specyficzne dla lokalizacji</li>
</ul>
<div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between">
<span class="text-h3 font-bold text-gosign-accent-on-dark">83% Zero-Touch</span>
<span class="text-small text-gosign-accent-on-dark font-semibold">Chemia szczegółowo &rarr;</span>
</div>
</a>

<a href="/pl/uslugi/hr-agent/leave-absence-decision-layer/aviation/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors">
<div class="flex items-center justify-between mb-4">
<h3 class="text-h3 font-bold text-white">Lotnictwo</h3>
<div class="flex gap-1">
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>

</div>
</div>
<ul class="space-y-1.5 text-small text-gosign-text-on-dark/70">
<li>Wiele związków zawodowych (piloci, kabina, obsługa naziemna)</li>
<li>EASA FTL: obowiązkowe okresy odpoczynku, limity Duty-Period</li>
<li>Medical Grounding (utrata zdolności do latania)</li>
<li>Planowanie rotacji między portami bazowymi</li>
</ul>
<div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between">
<span class="text-h3 font-bold text-gosign-accent-on-dark">78% Zero-Touch</span>
<span class="text-small text-gosign-accent-on-dark font-semibold">Lotnictwo szczegółowo &rarr;</span>
</div>
</a>

<a href="/pl/uslugi/hr-agent/leave-absence-decision-layer/financial-services/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors">
<div class="flex items-center justify-between mb-4">
<h3 class="text-h3 font-bold text-white">Finanse</h3>
<div class="flex gap-1">
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>

<span class="w-3 h-1.5 rounded-sm bg-white/20"></span>
</div>
</div>
<ul class="space-y-1.5 text-small text-gosign-text-on-dark/70">
<li>Obowiązkowe zwolnienie (zasada czterech oczu, fraud)</li>
<li>Obowiązkowe bloki urlopowe KNF dla traderów</li>
<li>Dni wolne od sesji giełdowej oprócz ustawowych</li>
<li>Programy emerytalne i obniżony wymiar etatu</li>
</ul>
<div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between">
<span class="text-h3 font-bold text-gosign-accent-on-dark">85% Zero-Touch</span>
<span class="text-small text-gosign-accent-on-dark font-semibold">Finanse szczegółowo &rarr;</span>
</div>
</a>

<a href="/pl/uslugi/hr-agent/leave-absence-decision-layer/retail/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors">
<div class="flex items-center justify-between mb-4">
<h3 class="text-h3 font-bold text-white">Handel</h3>
<div class="flex gap-1">
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>
<span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span>

<span class="w-3 h-1.5 rounded-sm bg-white/20"></span>
</div>
</div>
<ul class="space-y-1.5 text-small text-gosign-text-on-dark/70">
<li>Praca 6 dni w tygodniu: przeliczanie dni roboczych</li>
<li>64% pracowników na niepełnym etacie, z pełnym uprawnieniem proporcjonalnym</li>
<li>Blokady urlopowe Boże Narodzenie, Wielkanoc, szczyty sezonowe</li>
<li>16 województw x różne układy regionalne</li>
</ul>
<div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between">
<span class="text-h3 font-bold text-gosign-accent-on-dark">87% Zero-Touch</span>
<span class="text-small text-gosign-accent-on-dark font-semibold">Handel szczegółowo &rarr;</span>
</div>
</a>
</div>
</div>
</section>

<!-- Implementacja -->
<section id="implementacja" class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Implementacja</p>
<h2 class="text-h1 font-bold text-gosign-dark">Od pilotażu do działającego systemu.</h2>

<div class="grid grid-cols-1 lg:grid-cols-2 gap-10 mt-10">
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Architektura techniczna</h3>
<p class="text-body text-gosign-text">Leave & Absence Decision Layer działa w pełni w Państwa infrastrukturze: Państwa centrum danych, Państwa sieć, Państwa kontrola. Brak zależności od SaaS, brak odpływu danych, brak zewnętrznego śledzenia telemetrii. Dane zdrowotne i akta procedury powrotu nie opuszczają Państwa sieci. Skonteneryzowany, wielomandantowy, gotowy do wdrożenia w Państwa Private Cloud.</p>
<div class="flex flex-wrap gap-4 mt-3">
<a href="/pl/uslugi/infrastruktura/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infrastruktura szczegółowo &rarr;</a>
<a href="/pl/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Architektura Decision Layer &rarr;</a>
<a href="/pl/magazyn/akt-decyzyjny-podwazalne-decyzje-ai/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Akt decyzyjny &rarr;</a>
<a href="/pl/uslugi/hr-agent/payroll-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Payroll Decision Layer &rarr;</a>
</div>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Implementacja</h3>
<p class="text-body text-gosign-text">Decision Layer nie jest instalowany, lecz konfigurowany: Państwa układy zbiorowe, Państwa porozumienia zakładowe, Państwa typy nieobecności. Typowe projekty pilotażowe startują w ciągu 3 miesięcy z jedną lokalizacją i najczęstszymi typami nieobecności. Rozszerzenia na kolejne lokalizacje, układy zbiorowe i przypadki specjalne realizowane są równolegle do pilotażu.</p>
</div>
</div>

<h3 class="text-h3 font-bold text-gosign-dark mt-12 mb-6">Dźwignia ekonomiczna</h3>
<div class="grid grid-cols-1 sm:grid-cols-2 gap-6">
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-4">
<svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12l2 2 4-4m5.618-4.016A11.955 11.955 0 0112 2.944a11.955 11.955 0 01-8.618 3.04A12.02 12.02 0 003 9c0 5.591 3.824 10.29 9 11.622 5.176-1.332 9-6.03 9-11.622 0-1.042-.133-2.052-.382-3.016z" />
</svg>
<div>
<p class="text-body font-semibold text-gosign-dark">Eliminacja przekroczeń terminów procedury powrotu</p>
<p class="text-small text-gosign-text-light mt-2">Bez prawidłowej procedury powrotu po długotrwałej nieobecności, rozwiązanie umowy z powodu choroby jest prawnie ryzykowne. Decision Layer automatycznie rozpoznaje próg, uruchamia proces i dokumentuje zaproszenie. Żadnych zapomnianych obowiązków.</p>
</div>
</div>
</div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-4">
<svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M13 10V3L4 14h7v7l9-11h-7z" />
</svg>
<div>
<p class="text-body font-semibold text-gosign-dark">Przetwarzanie e-ZLA w czasie rzeczywistym</p>
<p class="text-small text-gosign-text-light mt-2">Od 2019 ZUS dostarcza elektroniczne zwolnienia lekarskie (e-ZLA). Decision Layer przetwarza e-ZLA automatycznie: zaksięgowanie nieobecności, obliczenie okresu wynagrodzenia chorobowego, informacja do payroll, aktualizacja planowania zmian. Żadnego manualnego wprowadzania.</p>
</div>
</div>
</div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-4">
<svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M12 6v6h4.5m4.5 0a9 9 0 11-18 0 9 9 0 0118 0z" />
</svg>
<div>
<p class="text-body font-semibold text-gosign-dark">78-87% Zero-Touch. Człowiek tylko gdzie prawnie wymagany.</p>
<p class="text-small text-gosign-text-light mt-2">Standardowe wnioski urlopowe, obliczanie pozostałego urlopu, urlop okolicznościowy, przetwarzanie e-ZLA, kontyngenty opieki nad dzieckiem: wszystko automatyzowalne. Interwencje ludzkie pozostają przy konfliktach urlopowych, procedurach powrotu i weryfikacji treści urlopu szkoleniowego.</p>
</div>
</div>
</div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-4">
<svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12h6m-6 4h6m2 5H7a2 2 0 01-2-2V5a2 2 0 012-2h5.586a1 1 0 01.707.293l5.414 5.414a1 1 0 01.293.707V19a2 2 0 01-2 2z" />
</svg>
<div>
<p class="text-body font-semibold text-gosign-dark">Eliminacja ryzyka wygaśnięcia urlopu</p>
<p class="text-small text-gosign-text-light mt-2">Orzecznictwo Sądu Najwyższego: bez indywidualnego, terminowego dowodu ostrzeżenia urlop nie wygasa. Przedawnienie rozpoczyna się dopiero po spełnieniu obowiązku ostrzeżenia. Decision Layer automatyzuje ostrzeżenia i dokumentuje doręczenie.</p>
</div>
</div>
</div>
</div>
</div>
</section>

<!-- Bezpieczeństwo -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Bezpieczeństwo</p>
<h2 class="text-h1 font-bold text-gosign-dark">Enterprise-Security. Od pierwszego dnia.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Dane nieobecnościowe zawierają informacje zdrowotne, akta procedury powrotu i wrażliwe decyzje personalne. Leave Decision Layer jest zaprojektowany dla regulowanych środowisk, w których ochrona danych, gotowość audytowa i weryfikowalność nie są opcjonalnymi dodatkami.</p>
<div class="mt-10">
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">100% infrastruktura klienta</h3>
<p class="text-small text-gosign-text-light mt-2">Decision Layer działa w pełni w Państwa sieci. Brak zależności od SaaS, brak odpływu danych, brak zewnętrznego śledzenia telemetrii. Dane zdrowotne i akta procedury powrotu nie opuszczają Państwa sieci.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">RODO Art. 9 by Design</h3>
<p class="text-small text-gosign-text-light mt-2">Dane zdrowotne architektonicznie odseparowane. Moduł procedury powrotu z osobną bazą danych, osobnym kręgiem dostępu, osobnymi terminami usuwania. Kompatybilny z RODO Art. 17 i terminami przechowywania.</p>
<a href="/pl/governance/data-residency/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Rezydencja danych szczegółowo &rarr;</a>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">Zgodność z AI Act</h3>
<p class="text-small text-gosign-text-light mt-2">Jasna separacja architektoniczna: AI Agent klasyfikuje typy nieobecności i rozpoznaje konflikty. Obliczanie uprawnień i terminów przebiega deterministycznie przez systemy reguł. Żadnej czarnej skrzynki przy decyzjach.</p>
<a href="/pl/governance/eu-ai-act/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">EU AI Act Readiness &rarr;</a>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">Audit Trail (append-only)</h3>
<p class="text-small text-gosign-text-light mt-2">Podpisane akta decyzyjne. Hash danych wejściowych plus wersja reguły daje reprodukowalny wynik. Zapieczętowane pakiety audytowe (JSON + PDF, SHA-256). Rada Zakładowa może prześledzić każdą decyzję.</p>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">ISO 27001 / PS 951 cert-ready</h3>
<p class="text-small text-gosign-text-light mt-2">Zintegrowany rejestr kontroli, zautomatyzowane przebiegi dowodowe, wersjonowane polityki. Compliance w bieżącej eksploatacji, nie dokumentowana wstecz.</p>
<a href="/pl/governance/cert-ready/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready by Design &rarr;</a>
</div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6">
<h3 class="text-body font-semibold text-gosign-dark">SSO i separacja mandantów</h3>
<p class="text-small text-gosign-text-light mt-2">Integracja z istniejącymi dostawcami tożsamości. Separacja mandantów na poziomie bazy danych (Row Level Security). Krąg dostępu do procedury powrotu oddzielony od modułu nieobecności. Spółki czysto rozdzielone.</p>
</div>
</div>
</div>
</div>
</section>


<!-- Weitere Agent-Lösungen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Więcej rozwiązań agentowych</h2>
<p class="text-body-lg text-gosign-text-light mt-4">HR Agents to część naszego portfolio agentów. Dla finansów i innych obszarów oferujemy wyspecjalizowane rozwiązania.</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8 max-w-content">
<a href="/pl/hr-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR & People Operations</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Wszystkie HR Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Zgodność z radą zakładową.</p>
</a>
<a href="/pl/finance-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Finance & Accounting</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Finance AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Przetwarzanie dokumentów, księgowanie, amortyzacja, korekty. Integracja z systemami ERP.</p>
</a>
<a href="/pl/kontakt/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Indywidualnie</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Co-Build dla Twojego procesu</h3>
<p class="text-body text-gosign-text-light mt-2">Compliance, operacje, shared services - rozwijamy agentów w modelu co-build.</p>
</a>
</div>
</div>
</section>

<!-- Ten agent w katalogu -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark">Kiedy zacząć? Priorytetyzacja i gotowość governance</h2>
<p class="text-body text-gosign-text mt-4">Katalog agentów HR pokazuje wyniki, złożoność governance, klasyfikację EU AI Act oraz pełną tabelę mikrodecyzji dla tego agenta - umieszczonego w 3 kwadrantach priorytetyzacji z 47 innymi agentami HR.</p>
<a href="/pl/katalog-agentow-hr/leave-of-absence-agent/" class="inline-flex items-center gap-2 mt-4 text-body font-semibold text-gosign-accent hover:underline">Zobacz sekwencję i wyniki &rarr;</a>
</div>
</section>

<!-- Pogłębienie -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Pogłębienie w Agent Briefing (Magazyn Gosign)</h2>
<p class="text-body text-gosign-text-light mb-6">Nasza seria artykułów eksperckich dla decydentów wdrażających AI Agents w przedsiębiorstwie.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/pl/magazyn/rada-zakladowa-ai-mitbestimmung/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Współdecydowanie</p>
<p class="text-body font-semibold text-gosign-dark">Rada Zakładowa i AI - współdecydowanie jako ograniczenie architektury</p>
</a>
<a href="/pl/magazyn/decision-layer-wyjasnienie/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Podstawy</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - czym jest i dlaczego każdy AI Agent w przedsiębiorstwie go potrzebuje?</p>
</a>
<a href="/pl/magazyn/eu-ai-act-hr/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">EU AI Act i HR - co osoby odpowiedzialne za personel muszą teraz wiedzieć</p>
</a>
</div>
</div>
</section>

--- AI Payroll Agent Aviation - rozliczenia ---
> Payroll Decision Layer dla lotnictwa. ZZLP, ZZPLiA, EASA FTL, diety zagraniczne. 82% Zero-Touch.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/pl/dlaczego-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Każda decyzja możliwa do prześledzenia</p>
</div>
</a>
<a href="/pl/dlaczego-gosign/#infrastruktura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Twoja infrastruktura</p>
<p class="text-xs text-gosign-text-light">Bez SaaS. Bez vendor-lock-in.</p>
</div>
</a>
<a href="/pl/dlaczego-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Bez ryzyka US-cloud</p>
</div>
</a>
</div>
</div>
</div>

<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Payroll Decision Layer - branże">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/pl/uslugi/hr-agent/payroll-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Payroll Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/pl/uslugi/hr-agent/payroll-decision-layer/chemicals/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Chemia</a>
<a href="/pl/uslugi/hr-agent/payroll-decision-layer/aviation/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Aviation</a>
<a href="/pl/uslugi/hr-agent/payroll-decision-layer/financial-services/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Finanse</a>
<a href="/pl/uslugi/hr-agent/payroll-decision-layer/retail/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Handel</a>
</div>
</div>
</nav>

<!-- Złożoność -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">14-18</span>
<p class="text-small text-gosign-text-light mt-1">Równoległych układów zbiorowych</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">82%</span>
<p class="text-small text-gosign-text-light mt-1">Zero-Touch-Quote</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">180+</span>
<p class="text-small text-gosign-text-light mt-1">Stawek diet wg krajów</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">Najwyższa złożoność reguł</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">ZZLP, ZZPLiA, związki obsługi naziemnej - układy zbiorowe 2024. Rozporządzenie MF ws. diet zagranicznych. EASA FTL (rozp. UE 83/2014), ULC. Zero-Touch: model symulacyjny Gosign.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Co klasyfikuje Agent</p>
<h2 class="text-h1 font-bold text-gosign-dark">Trzy związki zawodowe, jeden Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">W Polsce lotnicze rozliczenia obejmują ZZLP dla pilotów, ZZPLiA dla personelu kabinowego i związki obsługi naziemnej, limity EASA nadzorowane przez ULC oraz międzynarodowe diety. Znacie tę złożoność. Tak AI Agent ją rozwiązuje:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Cockpit (ZZLP): stopnie seniorytalne i skale płac</h3>
<p class="text-body text-gosign-text mt-2">Układy zbiorowe ZZLP obejmują wiele stopni seniorytalnych, stawki zależne od typu samolotu i składki emerytalne. AI Agent rozpoznaje aktualny stopień seniorytalny i przydział floty z danych kadrowych i przypisuje prawidłową klasę wynagrodzeniową - od Second Officer do Captain Senior. Dotyczy to załóg LOT Polish Airlines oraz Wizz Air w bazie polskiej.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Kabina (ZZPLiA): dodatki zmianowe i za latanie</h3>
<p class="text-body text-gosign-text mt-2">Wynagrodzenie zasadnicze plus dodatki zmianowe, dodatki Purser, diety wg planu rotacji. AI Agent rozpoznaje trasy krótkiego i dalekiego zasięgu i oblicza prawidłowe diety oraz wzorce zmianowe na rotację. Przy zmianie trasy: automatyczne przeliczenie.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Obsługa naziemna: umowy handlingowe</h3>
<p class="text-body text-gosign-text mt-2">Wiele systemów wynagradzania obejmujących check-in, płytę, bagaż i cargo z dodatkami nocnymi, świątecznymi i zmianowymi. AI Agent klasyfikuje grupę wynagrodzeniową i stopień doświadczenia z danych kadrowych i profilu stanowiska - również przy zmianie między check-in, płytą i obsługą bagażu.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">EASA FTL / ULC: limity czasu lotu jako granica payrollu</h3>
<p class="text-body text-gosign-text mt-2">ULC (Urząd Lotnictwa Cywilnego) bezpośrednio nadzoruje przepisy EASA: maksymalnie 900 godzin lotu/rok, Flight Duty Period maksymalnie 13 godzin. AI Agent sprawdza każdy cykl rozliczeniowy wobec tych limitów i eskaluje przy zbliżaniu się. Przy przekroczeniu grozi cofnięcie licencji i kara - to już nie jest kwestia payrollu, lecz kwestia prawna.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Diety: 180+ stawek krajowych wg rozporządzenia MF</h3>
<p class="text-body text-gosign-text mt-2">Rotacja Londyn-Dubaj-Singapur: trzy stawki krajowe w jednym Duty Period. AI Agent oblicza ryczałt za wyżywienie na odcinek rotacji wg rozporządzenia Ministra Finansów, włącznie z potrąceniami za posiłki i minimalnym czasem pobytu. Przy zmianach rotacji z powodu IROPs: automatyczne przeliczenie. Ta sama logika steruje również <a href="/pl/uslugi/travel-decision-layer/lotnictwo/" class="text-gosign-accent-text font-semibold hover:text-gosign-accent-hover transition-colors">rozliczeniem kosztów podróży w Travel Decision Layer</a>.</p>
</div>
</div>
</div>
</section>

<!-- Decision Flow -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Jedno rozliczenie lotnicze. 50 do 120 mikro-decyzji.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Captain na trasie dalekiego zasięgu. Payroll Decision Layer rozkłada jego rozliczenie na pojedyncze kroki decyzyjne:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Krok</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decyzja</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decydent</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Uzasadnienie</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Klasyfikacja grupy personalnej</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent rozpoznaje: cockpit, kabina, obsługa naziemna lub technika z danych kadrowych i klucza stanowiskowego</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Przypisanie układu zbiorowego</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent przypisuje: ZZLP, ZZPLiA lub związek obsługi naziemnej. Dodatkowo: która linia lotnicza (spółki grupy mają własne systemy taryfowe)</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Obliczenie wynagrodzenia zasadniczego</td><td class="py-3 px-4">Układ zbiorowy</td><td class="py-3 px-4">Wyszukanie w wersjonowanej tabeli: stopień seniorytalny, flota, stopień doświadczenia</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Obliczenie dodatków zmianowych</td><td class="py-3 px-4">Układ zbiorowy</td><td class="py-3 px-4">Kabina: dodatki zmianowe i za latanie. Obsługa naziemna: dodatki wg modelu zmianowego. Cockpit: zintegrowane w wynagrodzeniu zasadniczym</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Weryfikacja FTL-Compliance</td><td class="py-3 px-4">System reguł</td><td class="py-3 px-4">Kontrola EASA/ULC: roczny limit 900 godz., FDP maks. 13 godz., limity skumulowane. Przy zbliżaniu się: eskalacja</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Klasyfikacja diety</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent klasyfikuje rotację: jakie kraje, jaki czas pobytu, jakie stawki wg rozporządzenia MF obowiązują</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Obliczenie diety</td><td class="py-3 px-4">System reguł</td><td class="py-3 px-4">Stawki krajowe wg rozporządzenia MF, potrącenia za posiłki, minimalny czas pobytu. Przy zmianach IROP: automatyczne przeliczenie</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">Obliczenie składek emerytalnych</td><td class="py-3 px-4">System reguł</td><td class="py-3 px-4">Składki ZUS, PPK, dodatkowe programy emerytalne. Deterministycznie wg układu zbiorowego</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Kontrola odchyleń</td><td class="py-3 px-4">AI rozpoznaje, człowiek decyduje</td><td class="py-3 px-4">AI rozpoznaje odchylenia niezawodniej. Ale ocena pozostaje przy człowieku - Kodeks Pracy chroni uprawnienia konsultacyjne Rady Zakładowej</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Generowanie zapisów księgowych</td><td class="py-3 px-4">System reguł</td><td class="py-3 px-4">Dekretacja FI/CO, multi-spółka (spółki grupy), centrum kosztów - deterministycznie</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Symulacja -->
<section id="simulation" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Symulacja</p>
<h2 class="text-h1 font-bold text-white">Przeliczone dla wolumenów lotniczych</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Skonfigurowaliśmy Payroll Decision Layer z realistycznymi parametrami lotniczymi. Układy zbiorowe ZZLP, ZZPLiA i związków obsługi naziemnej, EASA FTL wg ULC, międzynarodowe diety wg rozporządzenia MF, stopnie seniorytalne cockpit.</p>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Parametry symulacji</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Liczebność załogi</td><td class="py-3 px-4">10 000 do 50 000+ (cockpit, kabina, obsługa naziemna, technika)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Równoległe układy zbiorowe</td><td class="py-3 px-4">2 do 5 (ZZLP, ZZPLiA, związki obsługi naziemnej, ew. spółki zależne)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Jurysdykcje</td><td class="py-3 px-4">Multi-jurysdykcja (baza macierzysta PL, stacje UE/globalnie)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Wskaźnik IROP</td><td class="py-3 px-4">10-20% (nieprawidłowości z wpływem na payroll)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Kraje diet</td><td class="py-3 px-4">180+ stawek krajowych wg rozporządzenia MF</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Stopnie seniorytalności cockpit</td><td class="py-3 px-4">Wiele stopni (Second Officer do Captain Senior), składki emerytalne</td></tr>
</tbody>
</table>
</div>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Przed / po</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th scope="col" class="text-left py-3 px-4 font-semibold text-white">Wymiar</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manualnie</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Wskaźnik błędów</td><td class="py-3 px-4">3-12% (APA, narzut lotniczy)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 0,3%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Zero-Touch-Quote</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">82%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Obliczanie diet</td><td class="py-3 px-4">Manualnie na rotację, podatne na błędy</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatycznie, 180+ krajów</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">FTL-Compliance</td><td class="py-3 px-4">Osobna kontrola, z opóźnieniem</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Zintegrowana, limity w czasie rzeczywistym</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Zmiana taryfowa (3 związki)</td><td class="py-3 px-4">Tygodnie na związek</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 24 godz. (wszystkie równolegle)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Gotowość audytowa</td><td class="py-3 px-4">Manualnie rekonstruowana</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatycznie generowana</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">APA: American Payroll Association. ZZLP, ZZPLiA, związki obsługi naziemnej - układy zbiorowe 2024. EASA rozp. UE 83/2014, ULC. Rozporządzenie MF ws. diet 2024. Wyniki symulacji: model obliczeniowy Gosign.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">W symulacji Decision Layer osiąga Zero-Touch-Quote 82%. Pozostałe 18% to rzeczywiste wyjątki: zmiany rotacji z powodu IROPs, zmiana związku zawodowego przy przeniesieniach między spółkami grupy, przypadki graniczne FTL z eskalacją, awanse cockpit przekraczające granice taryfowe. Dla 82% dostępne są kompletne, audytowalne akta decyzyjne.</p>
</div>
</section>

<!-- Architektura -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Architektura i implementacja</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">Payroll Decision Layer działa w pełni w Państwa infrastrukturze. Dla lotnictwa oznacza to: połączenie z systemami zarządzania załogą, przetwarzanie planów rotacji i danych FTL, układy zbiorowe ZZLP, ZZPLiA i związków naziemnych oraz ciągły Audit Trail do SAP HCM. Typowe projekty pilotażowe startują w ciągu 3 miesięcy z jedną grupą personalną i jednym układem zbiorowym.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/pl/uslugi/hr-agent/payroll-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Payroll Decision Layer przegląd &rarr;</a>
<a href="/pl/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Architektura Decision Layer &rarr;</a>
<a href="/pl/uslugi/infrastruktura/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infrastruktura szczegółowo &rarr;</a>
<a href="/pl/governance/co-determination/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Współdecydowanie i Rada Zakładowa &rarr;</a>
<a href="/pl/governance/cert-ready/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready by Design &rarr;</a>
<a href="/pl/uslugi/travel-decision-layer/lotnictwo/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Travel Decision Layer Aviation &rarr;</a>
</div>
</div>
</section>


<!-- Weitere Agent-Lösungen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Więcej rozwiązań agentowych</h2>
<p class="text-body-lg text-gosign-text-light mt-4">HR Agents to część naszego portfolio agentów. Dla finansów i innych obszarów oferujemy wyspecjalizowane rozwiązania.</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8 max-w-content">
<a href="/pl/hr-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR & People Operations</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Wszystkie HR Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Zgodność z radą zakładową.</p>
</a>
<a href="/pl/finance-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Finance & Accounting</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Finance AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Przetwarzanie dokumentów, księgowanie, amortyzacja, korekty. Integracja z systemami ERP.</p>
</a>
<a href="/pl/kontakt/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Indywidualnie</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Co-Build dla Twojego procesu</h3>
<p class="text-body text-gosign-text-light mt-2">Compliance, operacje, shared services - rozwijamy agentów w modelu co-build.</p>
</a>
</div>
</div>
</section>

<!-- Pogłębienie -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Pogłębienie w Agent Briefing (Magazyn Gosign)</h2>
<p class="text-body text-gosign-text-light mb-6">Nasza seria artykułów eksperckich dla decydentów wdrażających AI Agents w przedsiębiorstwie.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/pl/magazyn/decision-layer-payroll/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Finanse</p>
<p class="text-body font-semibold text-gosign-dark">Strukturalne eliminowanie błędów płacowych - Decision Layer dla finansów</p>
</a>
<a href="/pl/magazyn/rada-zakladowa-ai-mitbestimmung/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Współdecydowanie</p>
<p class="text-body font-semibold text-gosign-dark">Rada Zakładowa i AI - współdecydowanie jako ograniczenie architektury</p>
</a>
<a href="/pl/magazyn/decision-layer-wyjasnienie/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Podstawy</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - czym jest i dlaczego każdy AI Agent w przedsiębiorstwie go potrzebuje?</p>
</a>
</div>
</div>
</section>

<!-- Inne branże -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Payroll Decision Layer w innych branżach</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Każda branża ma własne układy zbiorowe, własne reguły dodatków i własne czynniki złożoności. Decision Layer jest ten sam. Konfiguracja jest specyficzna dla branży.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/pl/uslugi/hr-agent/payroll-decision-layer/chemicals/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Chemia</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">169 stawek bazowych, 13 okręgów taryfowych, dodatki zmianowe z kumulacją, dodatek przyszłościowy</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">88% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Szczegóły &rarr;</span>
</div>
</a>
<a href="/pl/uslugi/hr-agent/payroll-decision-layer/financial-services/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Finanse</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">5 reżimów wynagradzania, Bonus-Deferral, Malus/Clawback, wymogi KNF</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">85% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Szczegóły &rarr;</span>
</div>
</a>
<a href="/pl/uslugi/hr-agent/payroll-decision-layer/retail/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Handel</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">Układy regionalne, umowy zlecenia, 64% niepełny wymiar, szczyty sezonowe</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">92% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Szczegóły &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- AI Payroll Agent Chemia - rozliczenia płac ---
> Payroll Decision Layer dla przemysłu chemicznego. Układy ponadzakładowe, dodatki zmianowe, Trzynastka + ZFŚS. 88% Zero-Touch.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/pl/dlaczego-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Każda decyzja możliwa do prześledzenia</p>
</div>
</a>
<a href="/pl/dlaczego-gosign/#infrastruktura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Twoja infrastruktura</p>
<p class="text-xs text-gosign-text-light">Bez SaaS. Bez vendor-lock-in.</p>
</div>
</a>
<a href="/pl/dlaczego-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Bez ryzyka US-cloud</p>
</div>
</a>
</div>
</div>
</div>

<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Payroll Decision Layer - branże">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/pl/uslugi/hr-agent/payroll-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Payroll Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/pl/uslugi/hr-agent/payroll-decision-layer/chemicals/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Chemia</a>
<a href="/pl/uslugi/hr-agent/payroll-decision-layer/aviation/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Aviation</a>
<a href="/pl/uslugi/hr-agent/payroll-decision-layer/financial-services/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Finanse</a>
<a href="/pl/uslugi/hr-agent/payroll-decision-layer/retail/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Handel</a>
</div>
</div>
</nav>

<!-- Złożoność -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">169</span>
<p class="text-small text-gosign-text-light mt-1">Stawki wynagrodzenia bazowego</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">88%</span>
<p class="text-small text-gosign-text-light mt-1">Zero-Touch-Quote</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">13.</span>
<p class="text-small text-gosign-text-light mt-1">Trzynastka + ZFŚS</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">Najwyższa złożoność reguł</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">Układy ponadzakładowe Solidarność Chemia / OPZZ. Grupa Azoty, ORLEN Chemia. Zero-Touch: model symulacyjny Gosign.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Co klasyfikuje Agent</p>
<h2 class="text-h1 font-bold text-gosign-dark">Pięć wymiarów, jeden Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">W polskim przemyśle chemicznym układy ponadzakładowe Solidarność Chemia i OPZZ definiują grupy zaszeregowania, dodatki zmianowe z regułami kumulacji oraz Trzynastkę i odpisy na ZFŚS. Znacie tę złożoność. Tak AI Agent ją rozwiązuje:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">169 stawek wynagrodzenia bazowego</h3>
<p class="text-body text-gosign-text mt-2">Układy ponadzakładowe tworzą setki kombinacji stawek w polskiej branży chemicznej. AI Agent rozpoznaje prawidłową kombinację z danych kadrowych i danych lokalizacji - również przy przeniesieniach między zakładami. Żadnego manualnego wyszukiwania w tabelach, żadnych pomyłek w zaszeregowaniu.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Dodatki zmianowe z logiką kumulacji</h3>
<p class="text-body text-gosign-text mt-2">System zmianowy częściowo ciągły 6%, w pełni ciągły 10%, nocny 15-20%, niedzielny 60%, świąteczny 150%. AI Agent stosuje regułę kumulacji: obowiązuje najwyższy dodatek, dodatek nocny zawsze addytywny. Przy modelach zmian rotacyjnych system reguł automatycznie oblicza prawidłową kombinację na plan zmianowy.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Trzynastka + ZFŚS</h3>
<p class="text-body text-gosign-text mt-2">Dodatkowe wynagrodzenie roczne (Trzynastka) oraz odpisy na Zakładowy Fundusz Świadczeń Socjalnych (ZFŚS) tworzą złożone konfiguracje. AI Agent zarządza tysiącami indywidualnych konfiguracji z odpowiednim traktowaniem podatkowym i składkowym. Przy zmianie uprawnień socjalnych: automatyczne przeliczenie od następnego miesiąca.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Dodatki BHP za warunki szkodliwe</h3>
<p class="text-body text-gosign-text mt-2">Przepisy BHP określają dodatki za pracę w warunkach szkodliwych w branży chemicznej. AI Agent klasyfikuje ocenę ryzyka zawodowego dla stanowiska i przypisuje prawidłowy dodatek. Przy zmianie stanowiska: automatyczne przeliczenie.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Wypłaty specjalne wg kalendarza</h3>
<p class="text-body text-gosign-text mt-2">Trzynastka, odpisy ZFŚS, nagroda jubileuszowa. AI Agent zna termin wymagalności, traktowanie podatkowe i obliczenie składek ZUS każdej wypłaty specjalnej. Przy rozpoczęciu lub zakończeniu pracy w ciągu roku: automatyczne obliczenie proporcjonalne.</p>
</div>
</div>
</div>
</section>

<!-- Decision Flow -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Jedno rozliczenie w chemii. 40 do 80 mikro-decyzji.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Pracownik zmianowy w przemyśle chemicznym. Payroll Decision Layer rozkłada jego rozliczenie na pojedyncze kroki decyzyjne:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Krok</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decyzja</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decydent</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Uzasadnienie</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Klasyfikacja układu zbiorowego i grupy zaszeregowania</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent rozpoznaje lokalizację, układ i weryfikuje zaszeregowanie wobec danych kadrowych</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Obliczenie wynagrodzenia zasadniczego</td><td class="py-3 px-4">Układ zbiorowy</td><td class="py-3 px-4">Wyszukanie w wersjonowanej tabeli: układ + grupa + stopień</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Klasyfikacja modelu zmianowego</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent rozpoznaje: zmiana częściowo ciągła (6%), w pełni ciągła (10%) lub stała nocna z planu zmianowego</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Obliczenie i kumulacja dodatków</td><td class="py-3 px-4">Układ zbiorowy</td><td class="py-3 px-4">Najwyższy dodatek obowiązuje, nocny zawsze addytywny. Niedzielny 60%, świąteczny 150%</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Obliczenie składników zwolnionych z podatku</td><td class="py-3 px-4">System reguł</td><td class="py-3 px-4">Dodatki nocne i za warunki szkodliwe wg ustawy o PIT, zwolnienia z opodatkowania i oskładkowania</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Klasyfikacja dodatku BHP za warunki szkodliwe</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent klasyfikuje stanowisko wg oceny ryzyka: temperatura, chłód, chemikalia, hałas</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Obliczenie Trzynastki i odpisów ZFŚS</td><td class="py-3 px-4">System reguł</td><td class="py-3 px-4">Dodatkowe wynagrodzenie roczne + odpisy socjalne, traktowanie podatkowe wg przepisów</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">Obliczenie składek na ubezpieczenia społeczne</td><td class="py-3 px-4">System reguł</td><td class="py-3 px-4">ZUS z weryfikacją progów składkowych, PPK (Pracownicze Plany Kapitałowe)</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Kontrola odchyleń od poprzedniego miesiąca</td><td class="py-3 px-4">AI rozpoznaje, człowiek decyduje</td><td class="py-3 px-4">AI rozpoznaje odchylenia niezawodniej. Ale reakcja (awans, błąd, przeniesienie?) pozostaje przy człowieku - Kodeks Pracy wymaga konsultacji z Radą Zakładową</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Generowanie zapisów księgowych</td><td class="py-3 px-4">System reguł</td><td class="py-3 px-4">Dekretacja FI/CO, centrum kosztów, okres księgowy - deterministycznie</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Symulacja -->
<section id="simulation" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Symulacja</p>
<h2 class="text-h1 font-bold text-white">Przeliczone dla wolumenów chemicznych</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Skonfigurowaliśmy Payroll Decision Layer z realistycznymi parametrami polskiego przemysłu chemicznego. Układy ponadzakładowe Solidarność Chemia / OPZZ, modele zmianowe, dodatki BHP za warunki szkodliwe, Trzynastka + ZFŚS.</p>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Parametry symulacji</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Pracownicy</td><td class="py-3 px-4">5 000 do 50 000+ (produkcja, laboratorium, administracja)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Układ zbiorowy</td><td class="py-3 px-4">Solidarność Chemia / OPZZ, układy ponadzakładowe, grupy zaszeregowania</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Stawki wynagrodzenia bazowego</td><td class="py-3 px-4">169 (układy x grupy) + automatyka stopniowania</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Modele zmianowe</td><td class="py-3 px-4">Zmiana częściowo ciągła, w pełni ciągła, stała nocna</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Wypłaty specjalne</td><td class="py-3 px-4">Trzynastka, ZFŚS, nagroda jubileuszowa, PPK</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Dodatki BHP za warunki szkodliwe</td><td class="py-3 px-4">5-15% wg klasyfikacji stanowiska</td></tr>
</tbody>
</table>
</div>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Przed / po</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th scope="col" class="text-left py-3 px-4 font-semibold text-white">Wymiar</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manualnie</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Wskaźnik błędów</td><td class="py-3 px-4">1-8% (APA)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 0,1%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Zero-Touch-Quote</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">88%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Zmiana układu zbiorowego</td><td class="py-3 px-4">Tygodnie (wiele zakładów manualnie)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 24 godz. (wszystkie zakłady)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Obliczanie dodatków</td><td class="py-3 px-4">Manualnie, podatne na błędy</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Oparte na regułach, konsekwentne</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Gotowość audytowa</td><td class="py-3 px-4">Manualnie rekonstruowana</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatycznie generowana</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Zarządzanie Trzynastką i ZFŚS</td><td class="py-3 px-4">Arkusze Excel wg lokalizacji</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Centralnie, wersjonowane</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">APA: American Payroll Association. Układy ponadzakładowe Solidarność Chemia / OPZZ. Grupa Azoty, ORLEN Chemia. Wyniki symulacji: model obliczeniowy Gosign.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">W symulacji Decision Layer osiąga Zero-Touch-Quote 88%. Pozostałe 12% to rzeczywiste wyjątki: ponowna ocena warunków szkodliwych, zmiany uprawnień socjalnych, przeniesienia między zakładami. Dla 88% dostępne są kompletne, audytowalne akta decyzyjne.</p>
</div>
</section>

<!-- Architektura -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Architektura i implementacja</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">Payroll Decision Layer działa w pełni w Państwa infrastrukturze. Dla przemysłu chemicznego oznacza to: połączenie z systemami planowania zmian, przetwarzanie mapowania warunków szkodliwych BHP, systemy reguł specyficzne dla układów zbiorowych i ciągły Audit Trail do SAP HCM. Typowe projekty pilotażowe startują w ciągu 3 miesięcy z jednym układem i jedną grupą pracowniczą.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/pl/uslugi/hr-agent/payroll-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Payroll Decision Layer przegląd &rarr;</a>
<a href="/pl/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Architektura Decision Layer &rarr;</a>
<a href="/pl/uslugi/infrastruktura/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infrastruktura szczegółowo &rarr;</a>
<a href="/pl/governance/co-determination/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Współdecydowanie i Rada Zakładowa &rarr;</a>
<a href="/pl/governance/cert-ready/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready by Design &rarr;</a>
<a href="/pl/uslugi/travel-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Travel Decision Layer &rarr;</a>
</div>
</div>
</section>


<!-- Weitere Agent-Lösungen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Więcej rozwiązań agentowych</h2>
<p class="text-body-lg text-gosign-text-light mt-4">HR Agents to część naszego portfolio agentów. Dla finansów i innych obszarów oferujemy wyspecjalizowane rozwiązania.</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8 max-w-content">
<a href="/pl/hr-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR & People Operations</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Wszystkie HR Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Zgodność z radą zakładową.</p>
</a>
<a href="/pl/finance-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Finance & Accounting</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Finance AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Przetwarzanie dokumentów, księgowanie, amortyzacja, korekty. Integracja z systemami ERP.</p>
</a>
<a href="/pl/kontakt/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Indywidualnie</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Co-Build dla Twojego procesu</h3>
<p class="text-body text-gosign-text-light mt-2">Compliance, operacje, shared services - rozwijamy agentów w modelu co-build.</p>
</a>
</div>
</div>
</section>

<!-- Pogłębienie -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Pogłębienie w Agent Briefing (Magazyn Gosign)</h2>
<p class="text-body text-gosign-text-light mb-6">Nasza seria artykułów eksperckich dla decydentów wdrażających AI Agents w przedsiębiorstwie.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/pl/magazyn/decision-layer-payroll/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Finanse</p>
<p class="text-body font-semibold text-gosign-dark">Strukturalne eliminowanie błędów płacowych - Decision Layer dla finansów</p>
</a>
<a href="/pl/magazyn/rada-zakladowa-ai-mitbestimmung/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Współdecydowanie</p>
<p class="text-body font-semibold text-gosign-dark">Rada Zakładowa i AI - współdecydowanie jako ograniczenie architektury</p>
</a>
<a href="/pl/magazyn/decision-layer-wyjasnienie/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Podstawy</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - czym jest i dlaczego każdy AI Agent w przedsiębiorstwie go potrzebuje?</p>
</a>
</div>
</div>
</section>

<!-- Inne branże -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Payroll Decision Layer w innych branżach</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Każda branża ma własne układy zbiorowe, własne reguły dodatków i własne czynniki złożoności. Decision Layer jest ten sam. Konfiguracja jest specyficzna dla branży.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/pl/uslugi/hr-agent/payroll-decision-layer/aviation/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Aviation</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">3 związki zawodowe, 14-18 układów zbiorowych, EASA FTL, senioryteta cockpit do stopnia 23</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">82% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Szczegóły &rarr;</span>
</div>
</a>
<a href="/pl/uslugi/hr-agent/payroll-decision-layer/financial-services/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Finanse</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">5 reżimów wynagradzania, Bonus-Deferral, Malus/Clawback, obowiązki regulacyjne</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">85% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Szczegóły &rarr;</span>
</div>
</a>
<a href="/pl/uslugi/hr-agent/payroll-decision-layer/retail/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Handel</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">Układy regionalne, 64% niepełny wymiar, szczyty sezonowe</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">92% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Szczegóły &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- AI Payroll Agent Finanse - wynagrodzenia ---
> Payroll Decision Layer dla banków i instytucji finansowych. 5 reżimów wynagradzania, Deferral wg KNF/CRD V, Malus/Clawback. 85% Zero-Touch.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/pl/dlaczego-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Każda decyzja możliwa do prześledzenia</p>
</div>
</a>
<a href="/pl/dlaczego-gosign/#infrastruktura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Twoja infrastruktura</p>
<p class="text-xs text-gosign-text-light">Bez SaaS. Bez vendor-lock-in.</p>
</div>
</a>
<a href="/pl/dlaczego-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Bez ryzyka US-cloud</p>
</div>
</a>
</div>
</div>
</div>
<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Payroll Decision Layer - branże">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/pl/uslugi/hr-agent/payroll-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Payroll Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/pl/uslugi/hr-agent/payroll-decision-layer/chemicals/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Chemia</a>
<a href="/pl/uslugi/hr-agent/payroll-decision-layer/aviation/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Aviation</a>
<a href="/pl/uslugi/hr-agent/payroll-decision-layer/financial-services/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Finanse</a>
<a href="/pl/uslugi/hr-agent/payroll-decision-layer/retail/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Handel</a>
</div>
</div>
</nav>

<!-- Złożoność -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">5</span>
<p class="text-small text-gosign-text-light mt-1">Równoległych reżimów wynagradzania</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">85%</span>
<p class="text-small text-gosign-text-light mt-1">Zero-Touch-Quote</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">4-5 lat</span>
<p class="text-small text-gosign-text-light mt-1">Okres Bonus-Deferral</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
<span class="w-4 h-2 rounded-sm bg-gosign-border"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">Wysoka złożoność reguł</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">Wymogi KNF, CRD V/CRR (EU-direct), MiFID II. Instytucje referencyjne: PKO BP, mBank. Zero-Touch: model symulacyjny Gosign.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Co klasyfikuje Agent</p>
<h2 class="text-h1 font-bold text-gosign-dark">Pięć reżimów, jeden Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Pięć reżimów wynagradzania, Bonus-Caps, Deferral przez lata, Malus/Clawback retroaktywny, obowiązek sprawozdawczy wobec KNF. Znacie tę złożoność. Tak AI Agent ją rozwiązuje:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">5 reżimów wynagradzania równolegle</h3>
<p class="text-body text-gosign-text mt-2">Układ zbiorowy, pozaukładowy, Risk Taker, Trading, Sales/Advisory - każdy reżim z własną logiką obliczeniową. AI Agent rozpoznaje prawidłowe przypisanie z danych umownych, funkcji i wynagrodzenia całkowitego. Przy zmianie reżimu w trakcie kariery: automatyczna aktualizacja wszystkich parametrów obliczeniowych.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Bonus-Deferral przez 4-5 lat</h3>
<p class="text-body text-gosign-text mt-2">40-60% wynagrodzenia zmiennego rozłożone, podzielone na składniki akcyjne i gotówkowe, do 20 równoległych transz. AI Agent zarządza każdą transzą z własną datą vestingu i sprawdza Bonus-Cap (100% wynagrodzenia stałego, 200% z uchwałą walnego zgromadzenia) automatycznie wobec wymogów KNF i CRD V/CRR.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Malus/Clawback retroaktywny</h3>
<p class="text-body text-gosign-text mt-2">Dochodzenie zwrotu przez 5-7 lat przy naruszeniach zgodności lub zdarzeniach ryzyka. AI Agent rozpoznaje istotne zdarzenia z wewnętrznych zgłoszeń i przygotowuje sprawę. Decyzja należy zawsze do człowieka - KNF (Komisja Nadzoru Finansowego) przewiduje osobistą odpowiedzialność osób odpowiedzialnych za wynagrodzenia.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Obowiązki ostrożnościowe KNF dla tradingu</h3>
<p class="text-body text-gosign-text mt-2">10 kolejnych obowiązkowych dni urlopu rocznie, bez dzielenia. AI Agent automatycznie sprawdza, czy blok urlopowy został zachowany i eskaluje do HR w odpowiednim terminie. Żadnej manualnej kontroli kalendarza, żadnego przeoczenia terminów obowiązkowych.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Obowiązki sprawozdawcze wobec KNF</h3>
<p class="text-body text-gosign-text mt-2">Roczne sprawozdanie o wynagrodzeniach z danymi Risk Takerów, stanami Deferral, zdarzeniami Malus/Clawback. System reguł automatycznie generuje dane sprawozdawcze z danych rozliczeniowych. Dodatkowo kontrola MiFID II: składniki zmienne wykazalnie powiązane z jakością obsługi klienta. Sprawozdanie trafia do KNF w ramach sprawozdawczości ostrożnościowej.</p>
</div>
</div>
</div>
</section>

<!-- Decision Flow -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Jedno rozliczenie finansowe. 30 do 60 mikro-decyzji.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Risk Taker w banku uniwersalnym. Payroll Decision Layer rozkłada jego rozliczenie na pojedyncze kroki decyzyjne:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Krok</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decyzja</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decydent</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Uzasadnienie</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Klasyfikacja reżimu wynagradzania</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Agent rozpoznaje: układ zbiorowy (grupy 1-9), pozaukładowy, Risk Taker, Trading lub Sales/Advisory z danych umownych</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Weryfikacja statusu Risk Takera</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Sprawdzenie progu PLN (równowartość EUR 500 000), identyfikacja EBA wobec katalogu funkcji</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Obliczenie wynagrodzenia stałego</td><td class="py-3 px-4">Układ zbiorowy/umowa</td><td class="py-3 px-4">Układ zbiorowy: wyszukanie grupy z tabeli. Pozaukładowy: indywidualna umowa z danych kontraktowych</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Obliczenie wynagrodzenia zmiennego</td><td class="py-3 px-4">System reguł</td><td class="py-3 px-4">Ocena performance, Bonus-Cap 100% wynagrodzenia stałego (200% z uchwałą walnego)</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Obliczenie podziału Deferral</td><td class="py-3 px-4">System reguł</td><td class="py-3 px-4">40-60% przez 4-5 lat, podział na składniki akcyjne i gotówkowe, terminy vestingu</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Kontrola Malus</td><td class="py-3 px-4">AI rozpoznaje, człowiek decyduje</td><td class="py-3 px-4">AI rozpoznaje naruszenia zgodności niezawodniej. Ale decyzje Malus mają osobiste konsekwencje odpowiedzialności - Kodeks Pracy i KNF wymagają ludzkiej odpowiedzialności</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Kontrola bloku urlopowego wg wymogów KNF</td><td class="py-3 px-4">System reguł</td><td class="py-3 px-4">10 kolejnych dni urlopu rocznie, regulacja zastępstwa, eskalacja przy niespełnieniu</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">Obliczenie składek ubezpieczeniowych</td><td class="py-3 px-4">System reguł</td><td class="py-3 px-4">Weryfikacja progów ZUS, dodatkowe zabezpieczenie emerytalne, pracowniczy program emerytalny</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Generowanie danych sprawozdawczych KNF</td><td class="py-3 px-4">System reguł</td><td class="py-3 px-4">Roczne sprawozdanie o wynagrodzeniach: dane Risk Takerów, stany Deferral, zdarzenia Clawback do KNF</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Generowanie zapisów księgowych</td><td class="py-3 px-4">System reguł</td><td class="py-3 px-4">Dekretacja FI/CO, księgowanie multi-entity, rezerwy Deferral - deterministycznie</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Symulacja -->
<section id="simulation" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Symulacja</p>
<h2 class="text-h1 font-bold text-white">Przeliczone dla wolumenów finansowych</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Skonfigurowaliśmy Payroll Decision Layer z realistycznymi parametrami sektora finansowego. Wymogi KNF, CRD V/CRR, MiFID II, pięć reżimów wynagradzania, okresy Deferral przez lata.</p>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Parametry symulacji</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Pracownicy</td><td class="py-3 px-4">2 000 do 30 000+ (Front Office, Middle Office, Back Office)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Reżimy wynagradzania</td><td class="py-3 px-4">5 równolegle: układ zbiorowy (grupy 1-9), pozaukładowy, Risk Taker, Trading, Sales/Advisory</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Próg Risk Takera</td><td class="py-3 px-4">Równowartość EUR 500 000 w PLN, identyfikacja EBA</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Bonus-Cap</td><td class="py-3 px-4">100% wynagrodzenia stałego (200% z uchwałą walnego zgromadzenia)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Deferral</td><td class="py-3 px-4">40-60% przez 4-5 lat, podział akcje/gotówka</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Malus/Clawback</td><td class="py-3 px-4">5-7 lat okres dochodzenia zwrotu</td></tr>
</tbody>
</table>
</div>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Przed / po</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th scope="col" class="text-left py-3 px-4 font-semibold text-white">Wymiar</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manualnie</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Wskaźnik błędów</td><td class="py-3 px-4">1-8% (APA)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 0,1%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Zero-Touch-Quote</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">85%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Zarządzanie Deferral</td><td class="py-3 px-4">Excel, podatne na błędy</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Zautomatyzowane, wersjonowane</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Identyfikacja Risk Takera</td><td class="py-3 px-4">Rocznie manualnie</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Ciągle, automatycznie</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Sprawozdanie KNF</td><td class="py-3 px-4">Tygodnie (manualne przygotowanie)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 24 godz. (automatycznie generowane)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Gotowość audytowa</td><td class="py-3 px-4">Manualnie rekonstruowana</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatycznie generowana</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">APA: American Payroll Association. Wymogi KNF, CRD V/CRR, MiFID II. Instytucje referencyjne: PKO BP, mBank. Wyniki symulacji: model obliczeniowy Gosign.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">W symulacji Decision Layer osiąga Zero-Touch-Quote 85%. Pozostałe 15% to rzeczywiste wyjątki: przypadki graniczne Risk Takera, decyzje Malus, zmiany reżimu przy zmianie funkcji. Dla 85% dostępne są kompletne, audytowalne akta decyzyjne.</p>
</div>
</section>

<!-- Architektura -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Architektura i implementacja</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">Payroll Decision Layer działa w pełni w Państwa infrastrukturze. Dla sektora finansowego oznacza to: połączenie z systemami core banking, przetwarzanie identyfikacji Risk Takerów, regulacyjne systemy reguł dla wymogów KNF i CRD V/CRR oraz ciągły Audit Trail do SAP HCM. Typowe projekty pilotażowe startują w ciągu 3 miesięcy z jednym reżimem wynagradzania i jedną grupą pracowniczą.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/pl/uslugi/hr-agent/payroll-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Payroll Decision Layer przegląd &rarr;</a>
<a href="/pl/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Architektura Decision Layer &rarr;</a>
<a href="/pl/uslugi/infrastruktura/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infrastruktura szczegółowo &rarr;</a>
<a href="/pl/governance/co-determination/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Współdecydowanie i Rada Zakładowa &rarr;</a>
<a href="/pl/governance/cert-ready/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready by Design &rarr;</a>
<a href="/pl/uslugi/travel-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Travel Decision Layer &rarr;</a>
</div>
</div>
</section>


<!-- Weitere Agent-Lösungen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Więcej rozwiązań agentowych</h2>
<p class="text-body-lg text-gosign-text-light mt-4">HR Agents to część naszego portfolio agentów. Dla finansów i innych obszarów oferujemy wyspecjalizowane rozwiązania.</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8 max-w-content">
<a href="/pl/hr-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR & People Operations</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Wszystkie HR Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Zgodność z radą zakładową.</p>
</a>
<a href="/pl/finance-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Finance & Accounting</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Finance AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Przetwarzanie dokumentów, księgowanie, amortyzacja, korekty. Integracja z systemami ERP.</p>
</a>
<a href="/pl/kontakt/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Indywidualnie</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Co-Build dla Twojego procesu</h3>
<p class="text-body text-gosign-text-light mt-2">Compliance, operacje, shared services - rozwijamy agentów w modelu co-build.</p>
</a>
</div>
</div>
</section>

<!-- Pogłębienie -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Pogłębienie w Agent Briefing (Magazyn Gosign)</h2>
<p class="text-body text-gosign-text-light mb-6">Nasza seria artykułów eksperckich dla decydentów wdrażających AI Agents w przedsiębiorstwie.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/pl/magazyn/decision-layer-payroll/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Finanse</p>
<p class="text-body font-semibold text-gosign-dark">Strukturalne eliminowanie błędów płacowych - Decision Layer dla finansów</p>
</a>
<a href="/pl/magazyn/rada-zakladowa-ai-mitbestimmung/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Współdecydowanie</p>
<p class="text-body font-semibold text-gosign-dark">Rada Zakładowa i AI - współdecydowanie jako ograniczenie architektury</p>
</a>
<a href="/pl/magazyn/decision-layer-wyjasnienie/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Podstawy</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - czym jest i dlaczego każdy AI Agent w przedsiębiorstwie go potrzebuje?</p>
</a>
</div>
</div>
</section>

<!-- Inne branże -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Payroll Decision Layer w innych branżach</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Każda branża ma własne układy zbiorowe, własne reguły dodatków i własne czynniki złożoności. Decision Layer jest ten sam. Konfiguracja jest specyficzna dla branży.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/pl/uslugi/hr-agent/payroll-decision-layer/chemicals/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Chemia</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">169 stawek bazowych (13 okręgów x 13 grup), dodatki zmianowe, dodatek przyszłościowy</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">88% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Szczegóły &rarr;</span>
</div>
</a>
<a href="/pl/uslugi/hr-agent/payroll-decision-layer/aviation/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Aviation</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">3 związki zawodowe, 14-18 układów zbiorowych, EASA FTL, senioryteta Cockpit do stopnia 23</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">82% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Szczegóły &rarr;</span>
</div>
</a>
<a href="/pl/uslugi/hr-agent/payroll-decision-layer/retail/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Handel</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">576 stawek (16 landów x 6 grup x 6 stopni), 64% niepełny wymiar, szczyty sezonowe</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">92% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Szczegóły &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- AI Payroll Agent Handel - rozliczenia ---
> Payroll Decision Layer dla handlu detalicznego. Układy regionalne, umowy zlecenia/o dzieło, pracownicy sezonowi, kumulacja dodatków. 92% Zero-Touch.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/pl/dlaczego-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Każda decyzja możliwa do prześledzenia</p>
</div>
</a>
<a href="/pl/dlaczego-gosign/#infrastruktura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Twoja infrastruktura</p>
<p class="text-xs text-gosign-text-light">Bez SaaS. Bez vendor-lock-in.</p>
</div>
</a>
<a href="/pl/dlaczego-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Bez ryzyka US-cloud</p>
</div>
</a>
</div>
</div>
</div>
<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Payroll Decision Layer - branże">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/pl/uslugi/hr-agent/payroll-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Payroll Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/pl/uslugi/hr-agent/payroll-decision-layer/chemicals/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Chemia</a>
<a href="/pl/uslugi/hr-agent/payroll-decision-layer/aviation/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Aviation</a>
<a href="/pl/uslugi/hr-agent/payroll-decision-layer/financial-services/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Finanse</a>
<a href="/pl/uslugi/hr-agent/payroll-decision-layer/retail/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Handel</a>
</div>
</div>
</nav>

<!-- Złożoność -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">576</span>
<p class="text-small text-gosign-text-light mt-1">Stawki wynagrodzenia bazowego</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">92%</span>
<p class="text-small text-gosign-text-light mt-1">Zero-Touch-Quote</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">64%</span>
<p class="text-small text-gosign-text-light mt-1">Udział pracy w niepełnym wymiarze</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
<span class="w-4 h-2 rounded-sm bg-gosign-border"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">Wysoka złożoność reguł</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">Układy regionalne handel detaliczny 2024-2026. Zero-Touch: model symulacyjny Gosign. Referencje: Biedronka (Jerónimo Martins), Żabka.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Co klasyfikuje Agent</p>
<h2 class="text-h1 font-bold text-gosign-dark">Układy regionalne, jeden Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Polski handel detaliczny: układy regionalne negocjowane przez Solidarność Handel / NSZZ, 64% niepełny wymiar, 100 000 pracowników sezonowych, 25,7% rotacja. Znacie tę złożoność. Tak AI Agent ją rozwiązuje:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">576 stawek wynagrodzenia bazowego (układy regionalne)</h3>
<p class="text-body text-gosign-text mt-2">Układy regionalne negocjowane przez Solidarność Handel definiują stawki dla sieci takich jak Biedronka czy Żabka. AI Agent rozpoznaje prawidłową kombinację z lokalizacji placówki, rodzaju czynności i stażu pracy. Przy zmianie placówki między regionami: automatyczne przełączenie całej struktury wynagrodzeniowej.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">64% niepełny wymiar (umowy zlecenia / umowy o dzieło)</h3>
<p class="text-body text-gosign-text mt-2">Umowy zlecenia podlegają składkom ZUS, umowy o dzieło nie. AI Agent sprawdza przy każdym rozliczeniu typ umowy i klasyfikuje prawidłowy status ubezpieczeniowy. Studenci do 26. roku życia mają odrębne zasady oskładkowania umów zlecenia. Przy zmianie typu umowy: automatyczna reklasyfikacja wszystkich składek.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">100 000 pracowników sezonowych (praca sezonowa - Kodeks Pracy)</h3>
<p class="text-body text-gosign-text mt-2">Umowy na czas określony w polskim handlu podlegają limitom Kodeksu Pracy. AI Agent prowadzi dokładny licznik dni na pracownika sezonowego i rok kalendarzowy - we wszystkich placówkach. Przy zbliżaniu się do limitu: automatyczna eskalacja. Przy przekroczeniu: automatyczne przekształcenie na umowę na czas nieokreślony.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Kumulacja dodatków (tylko najwyższy, nocny addytywny)</h3>
<p class="text-body text-gosign-text mt-2">Praca wieczorna 20-40%, niedzielna 120%, świąteczna 200%, nocna 55%. AI Agent stosuje regułę kumulacji: obowiązuje najwyższy dodatek, dodatek nocny zawsze addytywny. Niedzielny wieczór z pracą nocną: 120% plus 55%, nie 200%. Żadnego manualnego przeliczania na zmianę.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">25,7% rotacja (stały strumień przyjęć i odejść)</h3>
<p class="text-body text-gosign-text mt-2">Ponad 2 500 przyjęć i odejść rocznie przy 10 000 zatrudnionych. AI Agent oblicza wynagrodzenie pro rata, ekwiwalent za urlop i wyrejestrowania z ZUS automatycznie - każdy przypadek indywidualnie, bez manualnego obliczania proporcji.</p>
</div>
</div>
</div>
</section>

<!-- Decision Flow -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Jedno rozliczenie handlowe. 30 do 60 mikro-decyzji.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Pracownik w niepełnym wymiarze w handlu detalicznym ze zmianami wieczornymi i niedzielami. Payroll Decision Layer rozkłada rozliczenie na pojedyncze kroki decyzyjne:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Krok</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decyzja</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Decydent</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-dark">Uzasadnienie</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Klasyfikacja regionu i układu zbiorowego</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Lokalizacja placówki, prawidłowy układ regionalny negocjowany przez Solidarność Handel</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Przypisanie grupy wynagrodzeniowej i stopnia</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Czynność, grupa wynagrodzeniowa, staż pracy, stopień doświadczenia</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Obliczenie wynagrodzenia zasadniczego</td><td class="py-3 px-4">Układ zbiorowy</td><td class="py-3 px-4">Wyszukanie w tabeli regionalnej: grupa wynagrodzeniowa + stopień = wynagrodzenie zasadnicze</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Przeliczenie na niepełny wymiar</td><td class="py-3 px-4">System reguł</td><td class="py-3 px-4">Proporcjonalne obliczenie wg godzin umownych, ustalenie stawki godzinowej dla dodatków</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Weryfikacja typu umowy</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Umowa o pracę, zlecenie czy o dzieło; odpowiednie składki ZUS wg typu</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Klasyfikacja i kumulacja dodatków</td><td class="py-3 px-4">AI Agent + układ zbiorowy</td><td class="py-3 px-4">Wieczorny 20-40%, nocny 55%, niedzielny 120%, świąteczny 200% - tylko najwyższy, nocny addytywny</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Obliczenie składek ZUS</td><td class="py-3 px-4">System reguł</td><td class="py-3 px-4">Składki standardowe, zlecenie z ZUS, o dzieło bez ZUS, wyjątek studenci do 26 lat</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">Weryfikacja statusu pracownika sezonowego</td><td class="py-3 px-4">AI Agent</td><td class="py-3 px-4">Licznik dni umowy na czas określony, limity Kodeksu Pracy, obowiązek przekształcenia</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Kontrola odchyleń</td><td class="py-3 px-4">AI rozpoznaje, człowiek decyduje</td><td class="py-3 px-4">AI rozpoznaje odchylenia niezawodniej. Ale ocena (zmiana statusu, błąd, zmiana placówki?) pozostaje przy człowieku - Kodeks Pracy wymaga konsultacji z Radą Zakładową</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Generowanie zapisów księgowych</td><td class="py-3 px-4">System reguł</td><td class="py-3 px-4">Dekretacja FI/CO, multi-placówka, przypisanie centrum kosztów - deterministycznie</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Symulacja -->
<section id="simulation" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Symulacja</p>
<h2 class="text-h1 font-bold text-white">Przeliczone dla wolumenów handlowych</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Skonfigurowaliśmy Payroll Decision Layer z realistycznymi parametrami polskiego handlu. Układy regionalne Solidarność Handel, umowy zlecenia / o dzieło, pracownicy sezonowi, kumulacja dodatków, wysoka rotacja.</p>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Parametry symulacji</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Pracownicy</td><td class="py-3 px-4">5 000 do 50 000+ (sprzedaż, kasa, magazyn, administracja)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Układ zbiorowy</td><td class="py-3 px-4">Handel detaliczny, układy regionalne Solidarność Handel / NSZZ</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Stawki wynagrodzenia bazowego</td><td class="py-3 px-4">576 (regiony x grupy x stopnie)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Udział niepełnego wymiaru</td><td class="py-3 px-4">64% (umowy zlecenia, umowy o dzieło, regularny niepełny wymiar)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Pracownicy sezonowi</td><td class="py-3 px-4">Ok. 100 000 (praca sezonowa, Kodeks Pracy, umowy na czas określony)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Dodatki</td><td class="py-3 px-4">Wieczorny 20-40%, nocny 55%, niedzielny 120%, świąteczny 200%</td></tr>
</tbody>
</table>
</div>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Przed / po</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th scope="col" class="text-left py-3 px-4 font-semibold text-white">Wymiar</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manualnie</th>
<th scope="col" class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Wskaźnik błędów</td><td class="py-3 px-4">1-8% (APA)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 0,1%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Zero-Touch-Quote</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">92%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Zmiana układu zbiorowego</td><td class="py-3 px-4">Tygodnie (regiony manualnie)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 24 godz. (wszystkie regiony)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Rozpoznawanie typu umowy</td><td class="py-3 px-4">Manualnie, z opóźnieniem</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">W czasie rzeczywistym, na rozliczenie</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Śledzenie pracowników sezonowych</td><td class="py-3 px-4">Excel, luki między placówkami</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatycznie, wszystkie placówki</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Gotowość audytowa</td><td class="py-3 px-4">Manualnie rekonstruowana</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatycznie generowana</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">APA: American Payroll Association. Układy regionalne handel detaliczny 2024-2026. Referencje: Biedronka, Żabka. Wyniki symulacji: model obliczeniowy Gosign.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">W symulacji Decision Layer osiąga Zero-Touch-Quote 92%. Pozostałe 8% to rzeczywiste wyjątki: przypadki graniczne pracowników sezonowych, zmiany typu umowy między zleceniem a umową o pracę, przeniesienia między placówkami w różnych regionach. Dla 92% dostępne są kompletne, audytowalne akta decyzyjne.</p>
</div>
</section>

<!-- Architektura -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Architektura i implementacja</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">Payroll Decision Layer działa w pełni w Państwa infrastrukturze. Dla polskiego handlu detalicznego oznacza to: połączenie z ewidencją czasu pracy w placówkach, przetwarzanie zmian typu umowy (zlecenie/o dzieło/o pracę), układy regionalne Solidarność Handel, śledzenie pracowników sezonowych we wszystkich lokalizacjach i ciągły Audit Trail do SAP HCM. Typowe projekty pilotażowe startują w ciągu 3 miesięcy z jednym regionem i jedną grupą placówek.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/pl/uslugi/hr-agent/payroll-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Payroll Decision Layer przegląd &rarr;</a>
<a href="/pl/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Architektura Decision Layer &rarr;</a>
<a href="/pl/uslugi/infrastruktura/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infrastruktura szczegółowo &rarr;</a>
<a href="/pl/governance/co-determination/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Współdecydowanie i Rada Zakładowa &rarr;</a>
<a href="/pl/governance/cert-ready/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready by Design &rarr;</a>
<a href="/pl/uslugi/travel-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Travel Decision Layer &rarr;</a>
</div>
</div>
</section>


<!-- Weitere Agent-Lösungen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Więcej rozwiązań agentowych</h2>
<p class="text-body-lg text-gosign-text-light mt-4">HR Agents to część naszego portfolio agentów. Dla finansów i innych obszarów oferujemy wyspecjalizowane rozwiązania.</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8 max-w-content">
<a href="/pl/hr-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR & People Operations</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Wszystkie HR Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Zgodność z radą zakładową.</p>
</a>
<a href="/pl/finance-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Finance & Accounting</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Finance AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Przetwarzanie dokumentów, księgowanie, amortyzacja, korekty. Integracja z systemami ERP.</p>
</a>
<a href="/pl/kontakt/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Indywidualnie</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Co-Build dla Twojego procesu</h3>
<p class="text-body text-gosign-text-light mt-2">Compliance, operacje, shared services - rozwijamy agentów w modelu co-build.</p>
</a>
</div>
</div>
</section>

<!-- Pogłębienie -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Pogłębienie w Agent Briefing (Magazyn Gosign)</h2>
<p class="text-body text-gosign-text-light mb-6">Nasza seria artykułów eksperckich dla decydentów wdrażających AI Agents w przedsiębiorstwie.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/pl/magazyn/decision-layer-payroll/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Finanse</p>
<p class="text-body font-semibold text-gosign-dark">Strukturalne eliminowanie błędów płacowych - Decision Layer dla finansów</p>
</a>
<a href="/pl/magazyn/rada-zakladowa-ai-mitbestimmung/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Współdecydowanie</p>
<p class="text-body font-semibold text-gosign-dark">Rada Zakładowa i AI - współdecydowanie jako ograniczenie architektury</p>
</a>
<a href="/pl/magazyn/decision-layer-wyjasnienie/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Podstawy</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - czym jest i dlaczego każdy AI Agent w przedsiębiorstwie go potrzebuje?</p>
</a>
</div>
</div>
</section>

<!-- Inne branże -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Payroll Decision Layer w innych branżach</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Każda branża ma własne układy zbiorowe, własne reguły dodatków i własne czynniki złożoności. Decision Layer jest ten sam. Konfiguracja jest specyficzna dla branży.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/pl/uslugi/hr-agent/payroll-decision-layer/chemicals/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Chemia</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">169 stawek bazowych, 13 okręgów taryfowych, dodatki zmianowe z kumulacją, dodatek przyszłościowy</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">88% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Szczegóły &rarr;</span>
</div>
</a>
<a href="/pl/uslugi/hr-agent/payroll-decision-layer/aviation/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Aviation</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">3 związki zawodowe, 14-18 układów zbiorowych, EASA FTL, senioryteta Cockpit do stopnia 23</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">82% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Szczegóły &rarr;</span>
</div>
</a>
<a href="/pl/uslugi/hr-agent/payroll-decision-layer/financial-services/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Finanse</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">5 reżimów wynagradzania, Bonus-Deferral, Malus/Clawback, obowiązki regulacyjne</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">85% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Szczegóły &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- Payroll Decision Layer - rozliczenia wynagrodzeń ---
> Decision Layer rozkłada każde rozliczenie wynagrodzeń na kroki decyzyjne. Oparty na regułach, auditowalny, 82-92% Zero-Touch.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/pl/dlaczego-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Każda decyzja możliwa do prześledzenia</p>
</div>
</a>
<a href="/pl/dlaczego-gosign/#infrastruktura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Twoja infrastruktura</p>
<p class="text-xs text-gosign-text-light">Bez SaaS. Bez vendor-lock-in.</p>
</div>
</a>
<a href="/pl/dlaczego-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Bez ryzyka US-cloud</p>
</div>
</a>
</div>
</div>
</div>

<!-- Problem -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div><span class="text-h1 font-bold text-gosign-accent-text">1-8%</span><p class="text-small text-gosign-text-light mt-1">Wskaźnik błędów w rozliczeniach wynagrodzeń</p></div>
<div><span class="text-h1 font-bold text-gosign-accent-text">EUR 260</span><p class="text-small text-gosign-text-light mt-1">Całkowity koszt jednego incydentu błędu</p></div>
<div><span class="text-h1 font-bold text-gosign-accent-text">10</span><p class="text-small text-gosign-text-light mt-1">Kroków decyzyjnych na rozliczenie</p></div>
<p class="sm:col-span-3 text-xs text-gosign-text-light">American Payroll Association (APA); EY / HR Dive, "The True Cost of Payroll" (USD 281 na incydent, przeliczone po kursie średnim)</p>
</div>
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Problem</p>
<h2 class="text-h1 font-bold text-gosign-dark">Dlaczego systemy płacowe zawodzą w złożonych organizacjach</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">SAP HCM liczy poprawnie. Comarch Optima liczy poprawnie. Każdy silnik płacowy liczy poprawnie - gdy dane wejściowe są prawidłowe. Ale w organizacjach z wieloma układami zbiorowymi, modelami zmianowymi, regionalnymi odchyleniami i dziesiątkami reguł dodatkowych sama kalkulacja nie jest problemem. Problemem jest decyzja przed nią: która tabela obowiązuje? Jaki dodatek? Czy kumulacja jest dozwolona?</p>
<div class="mt-10 grid grid-cols-1 sm:grid-cols-3 gap-6">
<div class="bg-gosign-light border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">1-8% błędów</h3><p class="text-small text-gosign-text-light mt-2">13 grup wynagrodzeniowych, 13 okręgów taryfowych (w modelu niemieckim), 6 klas podatkowych, 4 gałęzie ubezpieczeń społecznych, progi składkowe, zamiana wynagrodzenia na oszczędności emerytalne, egzekucja z wynagrodzenia, dodatki z regułami kumulacji. Żaden specjalista ds. płac nie zna wszystkich reguł we wszystkich obszarach taryfowych. 1-8% wszystkich rozliczeń zawiera błędy (APA) - im bardziej złożony krajobraz taryfowy, tym wyższy wskaźnik.</p></div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">EUR 260 za błąd</h3><p class="text-small text-gosign-text-light mt-2">Jeden błąd w rozliczeniu pociąga za sobą cztery procesy następcze: storno oryginalnego rozliczenia, ponowne obliczenie, korekta zgłoszenia ubezpieczeniowego, skorygowana deklaracja podatkowa. W sumie jeden incydent kosztuje średnio EUR 260 (EY; badanie oryginalne: USD 281). Przy 2 000 pracowników i 1-8% błędów to 20-160 incydentów miesięcznie.</p></div>
<div class="bg-gosign-light border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">Zero przejrzystości reguł</h3><p class="text-small text-gosign-text-light mt-2">Gdy kontrola podatkowa pyta: dlaczego naliczono 25% dodatku nocnego zamiast 20%? Jaki układ zbiorowy obowiązywał w tym momencie? Czy grupa wynagrodzeniowa była prawidłowa? Brakuje dowodu. Systemy płacowe dokumentują wyniki. Nie decyzje, które do nich doprowadziły.</p></div>
</div>
</div>
</section>

<!-- Decision Layer -->
<section id="decision-layer" class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Decision Layer</p>
<h2 class="text-h1 font-bold text-gosign-dark">Każde rozliczenie. Rozłożone na kroki decyzyjne.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Payroll Decision Layer rozkłada każde rozliczenie na pojedyncze kroki decyzyjne. Dla każdego kroku jest zdefiniowane, kto decyduje: AI Agent klasyfikuje stany faktyczne i rozpoznaje odchylenia - niezawodniej i szybciej niż jakikolwiek specjalista ds. płac. System reguł oblicza kwoty - deterministycznie i powtarzalnie. Człowiek pozostaje w procesie tam, gdzie Rada Zakładowa, prawo pracy (Kodeks Pracy) lub ryzyko dyskryminacji wymagają ludzkiej decyzji.</p>
<div class="mt-10 overflow-x-auto">
<table class="w-full text-left text-body">
<thead><tr class="border-b-2 border-gosign-dark"><th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Krok</th><th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Decyzja</th><th scope="col" class="py-3 pr-4 font-bold text-gosign-dark">Decydent</th><th scope="col" class="py-3 font-bold text-gosign-dark">Uzasadnienie</th></tr></thead>
<tbody class="text-gosign-text-light">
<tr class="border-b border-gosign-border"><td class="py-3 pr-4 font-medium text-gosign-dark">1</td><td class="py-3 pr-4">Walidacja klasy podatkowej, ulg, cech ubezpieczeniowych</td><td class="py-3 pr-4 font-medium">System reguł</td><td class="py-3">Porównanie z danymi US/e-Deklaracje, deterministyczne</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4 font-medium text-gosign-dark">2</td><td class="py-3 pr-4">Sprawdzenie zaszeregowania taryfowego</td><td class="py-3 pr-4 font-medium">AI Agent</td><td class="py-3">Agent klasyfikuje: jaki układ zbiorowy, jaka grupa wynagrodzeniowa, jaki stopień? Porównuje z danymi kadrowymi i wykrywa niespójności</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4 font-medium text-gosign-dark">3</td><td class="py-3 pr-4">Obliczenie wynagrodzenia zasadniczego</td><td class="py-3 pr-4 font-medium">Układ zbiorowy</td><td class="py-3">Wyszukanie w wersjonowanej tabeli taryfowej: region + grupa + stopień</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4 font-medium text-gosign-dark">4</td><td class="py-3 pr-4">Obliczenie dodatków (nocny/niedzielny/świąteczny)</td><td class="py-3 pr-4 font-medium">AI Agent + układ zbiorowy</td><td class="py-3">Agent klasyfikuje rodzaj dodatku z danych zmianowych. Układ zbiorowy definiuje stawki + reguły kumulacji (najwyższy obowiązuje, nocny zawsze addytywny)</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4 font-medium text-gosign-dark">5</td><td class="py-3 pr-4">Identyfikacja składników zwolnionych z podatku</td><td class="py-3 pr-4 font-medium">System reguł</td><td class="py-3">Zgodnie z przepisami podatkowymi: nocny 25%, niedzielny 50%, świąteczny 125% wynagrodzenia zasadniczego zwolnione z podatku (art. 21 ustawy o PIT)</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4 font-medium text-gosign-dark">6</td><td class="py-3 pr-4">Obliczenie zamiany wynagrodzenia / PPK / PPE</td><td class="py-3 pr-4 font-medium">System reguł</td><td class="py-3">Składka pracownika + dopłata pracodawcy, sprawdzenie ulg podatkowych i składkowych</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4 font-medium text-gosign-dark">7</td><td class="py-3 pr-4">Obliczenie składek na ubezpieczenia społeczne</td><td class="py-3 pr-4 font-medium">System reguł</td><td class="py-3">ZUS: emerytalne/rentowe/chorobowe/wypadkowe z weryfikacją progów składkowych</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4 font-medium text-gosign-dark">8</td><td class="py-3 pr-4">Zastosowanie egzekucji z wynagrodzenia</td><td class="py-3 pr-4 font-medium">System reguł + człowiek</td><td class="py-3">Tabela egzekucyjna deterministyczna, przy konflikcie kolejności: Human-in-the-Loop</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4 font-medium text-gosign-dark">9</td><td class="py-3 pr-4">Sprawdzenie odchyleń od poprzedniego miesiąca</td><td class="py-3 pr-4 font-medium">AI rozpoznaje, człowiek decyduje</td><td class="py-3">AI rozpoznaje odchylenia niezawodniej niż jakikolwiek specjalista ds. płac. Ale decyzja, co z odchyleniem zrobić, musi pozostać przy człowieku: awans, błąd w danych czy faktyczny błąd w rozliczeniu? Bez tego rozdzielenia kontrola zgodności staje się monitoringiem wydajności - a do tego polskie prawo pracy (Kodeks Pracy) wymaga konsultacji z Radą Zakładową.</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 pr-4 font-medium text-gosign-dark">10</td><td class="py-3 pr-4">Generowanie zapisów księgowych</td><td class="py-3 pr-4 font-medium">System reguł</td><td class="py-3">Dekretacja FI/CO, centrum kosztów, okres księgowy - deterministycznie</td></tr>
</tbody>
</table>
</div>
<p class="text-body text-gosign-text mt-8 max-w-narrow font-semibold">10 kroków na rozliczenie. AI Agent może każdy z nich wykonać lepiej i szybciej niż specjalista ds. wynagrodzeń. Mimo to człowiek pozostaje w zdefiniowanych miejscach procesu - nie dlatego, że potrafi to lepiej, ale dlatego, że Rada Zakładowa, prawo pracy lub ryzyko dyskryminacji tego wymagają. Przy 10 000 pracowników to 100 000 udokumentowanych mikro-decyzji miesięcznie.</p>
<div class="mt-10 grid grid-cols-1 sm:grid-cols-2 gap-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">AI klasyfikuje. System reguł liczy.</h3><p class="text-small text-gosign-text-light mt-2">AI Agent rozpoznaje: jaki układ zbiorowy obowiązuje? Jaki rodzaj dodatku? Czy zaszeregowanie jest prawidłowe? Tę klasyfikację wykonuje niezawodniej niż jakikolwiek specjalista ds. płac. Obliczenie kwoty przebiega następnie przez wersjonowane Decision Tables - deterministycznie, powtarzalnie, auditowalnie.</p></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">40 do 80 mikro-decyzji na rozliczenie</h3><p class="text-small text-gosign-text-light mt-2">10 głównych kroków rozkłada się na dziesiątki podkroków: każdy dodatek ma własne reguły kumulacji, każda gałąź ubezpieczeń społecznych ma własną weryfikację progów, każda egzekucja ma własną kolejność. Każdy pojedynczo udokumentowany.</p></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">AI Agent, system reguł lub człowiek</h3><p class="text-small text-gosign-text-light mt-2">AI Agent klasyfikuje stany faktyczne i podejmuje decyzje - niezawodniej niż jakikolwiek specjalista ds. płac. System reguł oblicza kwotę. Człowiek pozostaje w procesie tam, gdzie Rada Zakładowa, prawo pracy (Kodeks Pracy) lub ryzyko dyskryminacji wymagają ludzkiej decyzji - nie dlatego, że potrafi to lepiej, ale dlatego, że musi.</p></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">Człowiek w pętli: nie ekspertyza, lecz odpowiedzialność</h3><p class="text-small text-gosign-text-light mt-2">Tradycyjny payroll wymaga manualnego sprawdzenia wszędzie. AI Agents potrafią to lepiej. Ale przy kolejności egzekucji, ocenie odchyleń i decyzjach o zaszeregowaniu ustawodawca lub Rada Zakładowa wymagają ludzkiej decyzji. Decision Layer wie, gdzie - i eskaluje tylko tam.</p></div>
</div>
</div>
</section>

<!-- Governance & Audyt -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<h2 class="text-h1 font-bold text-gosign-dark">Nie dokumentowane po fakcie. Powstające w procesie.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Gdy kontrola podatkowa pyta "dlaczego naliczono 25% dodatku nocnego?" - odpowiedź "to jest w układzie zbiorowym" nie wystarczy. Jaki układ zbiorowy? Jaka wersja? Czy obowiązywała reguła kumulacji? Payroll Decision Layer tworzy na każdą mikrodecyzję akt decyzyjny, który odpowiada dokładnie na te pytania: input, zastosowana reguła merytoryczna wraz z wersją, pewność, wynik, znacznik czasu i ścieżka podważenia. Ten sam akt sprawia, że da się też spełnić wyjaśnienie pojedynczej decyzji wg art. 86 EU AI Act.</p>
<div class="mt-10 bg-gosign-dark rounded-card p-6 sm:p-8">
<div class="flex items-start gap-4 mb-6"><svg class="w-8 h-8 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12h6m-6 4h6m2 5H7a2 2 0 01-2-2V5a2 2 0 012-2h5.586a1 1 0 01.707.293l5.414 5.414a1 1 0 01.293.707V19a2 2 0 01-2 2z" /></svg><div><h3 class="text-h3 font-bold text-white">Każda mikro-decyzja generuje wpis audytowy</h3><p class="text-small text-gosign-text-on-dark/70 mt-1">Append-only. Nic nie jest nadpisywane, nic usuwane. Przy korektach powstają zapisy stornujące i korygujące. Podpisane SHA-256, w każdej chwili eksportowalne.</p></div></div>
<div class="grid grid-cols-2 sm:grid-cols-3 gap-3 sm:gap-4">
<div class="flex items-center gap-2.5"><svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg><span class="text-small text-gosign-text-on-dark/80">ID reguły + wersja</span></div>
<div class="flex items-center gap-2.5"><svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg><span class="text-small text-gosign-text-on-dark/80">Układ zbiorowy + okres obowiązywania</span></div>
<div class="flex items-center gap-2.5"><svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg><span class="text-small text-gosign-text-on-dark/80">Dane wejściowe (godziny, rodzaj dodatku)</span></div>
<div class="flex items-center gap-2.5"><svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg><span class="text-small text-gosign-text-on-dark/80">Wynik (kwota, kwalifikacja podatkowa)</span></div>
<div class="flex items-center gap-2.5"><svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg><span class="text-small text-gosign-text-on-dark/80">Decydent (system reguł / tarif / człowiek)</span></div>
<div class="flex items-center gap-2.5"><svg class="w-4 h-4 text-gosign-accent flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg><span class="text-small text-gosign-text-on-dark/80">Hash danych wejściowych (powtarzalny)</span></div>
</div>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8">
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6"><div class="flex items-start gap-3"><svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M15 12a3 3 0 11-6 0 3 3 0 016 0z" /><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M2.458 12C3.732 7.943 7.523 5 12 5c4.478 0 8.268 2.943 9.542 7-1.274 4.057-5.064 7-9.542 7-4.477 0-8.268-2.943-9.542-7z" /></svg><div><h3 class="text-body font-semibold text-gosign-dark">Transparentność dla Rady Zakładowej</h3><p class="text-small text-gosign-text-light mt-2">Polskie prawo pracy (Kodeks Pracy) przyznaje Radzie Zakładowej uprawnienia konsultacyjne w zakresie zasad wynagradzania. System reguł jest dostępny do wglądu, decyzje są weryfikowalne, raporty pseudonimizowane. Wykrywanie anomalii sterowalne za pomocą Feature Flag.</p><a href="/pl/governance/co-determination/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Współdecydowanie &rarr;</a></div></div></div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6"><div class="flex items-start gap-3"><svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12l2 2 4-4m5.618-4.016A11.955 11.955 0 0112 2.944a11.955 11.955 0 01-8.618 3.04A12.02 12.02 0 003 9c0 5.591 3.824 10.29 9 11.622 5.176-1.332 9-6.03 9-11.622 0-1.042-.133-2.052-.382-3.016z" /></svg><div><h3 class="text-body font-semibold text-gosign-dark">Gotowość do kontroli</h3><p class="text-small text-gosign-text-light mt-2">Obsługa okresów przechowywania (10 lat). Anonimizacja zamiast usuwania dla zgodności z RODO. Każde rozliczenie powtarzalne na podstawie hasha danych wejściowych.</p><a href="/pl/governance/cert-ready/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready &rarr;</a></div></div></div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6"><div class="flex items-start gap-3"><svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 5H7a2 2 0 00-2 2v12a2 2 0 002 2h10a2 2 0 002-2V7a2 2 0 00-2-2h-2M9 5a2 2 0 002 2h2a2 2 0 002-2M9 5a2 2 0 012-2h2a2 2 0 012 2m-6 9l2 2 4-4" /></svg><div><h3 class="text-body font-semibold text-gosign-dark">Systematyczna zgodność</h3><p class="text-small text-gosign-text-light mt-2">Każde rozliczenie jest weryfikowane wobec kompletnego systemu reguł - nie wyrywkowo, lecz systematycznie. Odchylenia są wykrywane i dokumentowane, a nie dopiero podczas kontroli podatkowej.</p></div></div></div>
</div>
</div>
</section>

<!-- Integracja -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Integracja</p>
<h2 class="text-h1 font-bold text-gosign-dark">Integracja z Państwa istniejącym krajobrazem systemowym</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Państwa systemy pozostają. Manualna praca decyzyjna przed nimi znika. Payroll Decision Layer znajduje się pomiędzy Państwa systemami źródłowymi a silnikiem płacowym - podejmuje decyzje, które dziś podejmują specjaliści ds. wynagrodzeń.</p>
<div class="grid grid-cols-1 md:grid-cols-3 gap-6 mt-10">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><div class="flex items-center gap-3 mb-4"><svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M20 7l-8-4-8 4m16 0l-8 4m8-4v10l-8 4m0-10L4 7m8 4v10M4 7v10l8 4" /></svg><h3 class="text-body font-semibold text-gosign-dark">Źródła danych</h3></div><ul class="space-y-2 text-small text-gosign-text-light"><li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Ewidencja czasu pracy (SAP CATS, Atoss, Interflex)</span></li><li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Planowanie zmian (ATOSS, SP Expert)</span></li><li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Dane kadrowe (SAP HCM, Workday)</span></li><li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>e-Deklaracje (interfejs urzędu skarbowego)</span></li><li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Baza układów zbiorowych (wersjonowana)</span></li></ul></div>
<div class="bg-gosign-dark border border-gosign-dark rounded-card p-6"><div class="flex items-center gap-3 mb-4"><svg class="w-6 h-6 text-gosign-accent flex-shrink-0" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9.75 3.104v5.714a2.25 2.25 0 01-.659 1.591L5 14.5M9.75 3.104c-.251.023-.501.05-.75.082m.75-.082a24.301 24.301 0 014.5 0m0 0v5.714c0 .597.237 1.17.659 1.591L19.8 15.3M14.25 3.104c.251.023.501.05.75.082M19.8 15.3l-1.57.393A9.065 9.065 0 0112 15a9.065 9.065 0 00-6.23.693L5 14.5m14.8.8l1.402 1.402c1.232 1.232.65 3.318-1.067 3.611A48.309 48.309 0 0112 21c-2.773 0-5.491-.235-8.135-.687-1.718-.293-2.3-2.379-1.067-3.61L5 14.5" /></svg><h3 class="text-body font-semibold text-white">Payroll Decision Layer</h3></div><ul class="space-y-2 text-small text-gosign-text-on-dark/80"><li>Zaszeregowanie taryfowe</li><li>Obliczenie i kumulacja dodatków</li><li>Składniki zwolnione z podatku</li><li>Składki ZUS + weryfikacja progów</li><li>Obliczenie egzekucji z wynagrodzenia</li><li>Zamiana wynagrodzenia / PPK / PPE</li><li>Kontrola odchyleń + eskalacja</li></ul></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><div class="flex items-center gap-3 mb-4"><svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M5.25 14.25h13.5m-13.5 0a3 3 0 01-3-3m3 3a3 3 0 100 6h13.5a3 3 0 100-6m-16.5-3a3 3 0 013-3h13.5a3 3 0 013 3m-19.5 0a4.5 4.5 0 01.9-2.7L5.737 5.1a3.375 3.375 0 012.7-1.35h7.126c1.062 0 2.062.5 2.7 1.35l2.587 3.45a4.5 4.5 0 01.9 2.7m0 0a3 3 0 01-3 3m0 3h.008v.008h-.008v-.008zm0-6h.008v.008h-.008v-.008zm-3 6h.008v.008h-.008v-.008zm0-6h.008v.008h-.008v-.008z" /></svg><h3 class="text-body font-semibold text-gosign-dark">Systemy docelowe</h3></div><ul class="space-y-2 text-small text-gosign-text-light"><li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>SAP HCM / SuccessFactors (rozliczenie)</span></li><li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Comarch Optima / Płatnik</span></li><li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>SAP FI/CO (księgowanie, dekretacja)</span></li><li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>System zgłoszeń ubezpieczeniowych (ZUS PUE)</span></li><li class="flex items-start gap-2"><span class="text-gosign-accent-text mt-0.5">&#8594;</span><span>Urząd skarbowy (e-Deklaracje, PIT)</span></li></ul></div>
</div>
</div>
</section>

<!-- Symulacje branżowe -->
<section id="simulationen" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Symulowane dla wolumenów Enterprise</p>
<h2 class="text-h1 font-bold text-white">Cztery branże. Przeliczone.</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Skonfigurowaliśmy Payroll Decision Layer dla czterech branż z realistycznymi układami zbiorowymi, regułami dodatków i strukturami kadrowymi. Każda karta pokazuje parametry symulacji i wynik.</p>
<div class="grid grid-cols-1 md:grid-cols-2 gap-6 mt-10">
<a href="/pl/uslugi/hr-agent/payroll-decision-layer/chemicals/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors"><div class="flex items-center justify-between mb-4"><h3 class="text-h3 font-bold text-white">Chemia</h3><div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div></div><ul class="space-y-1.5 text-small text-gosign-text-on-dark/70"><li>13 grup wynagrodzeniowych x 16 województw = 208 stawek bazowych</li><li>Dodatki zmianowe 6-10%, dodatki za uciążliwość</li><li>Składka dodatkowa 23% (prawo wyboru: gotówka/czas wolny/PPK)</li><li>PPK, 13. pensja + dodatek urlopowy</li></ul><div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between"><span class="text-h3 font-bold text-gosign-accent-on-dark">88% Zero-Touch</span><span class="text-small text-gosign-accent-on-dark font-semibold">Chemia szczegółowo &rarr;</span></div></a>
<a href="/pl/uslugi/hr-agent/payroll-decision-layer/aviation/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors"><div class="flex items-center justify-between mb-4"><h3 class="text-h3 font-bold text-white">Aviation</h3><div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div></div><ul class="space-y-1.5 text-small text-gosign-text-on-dark/70"><li>3 związki zawodowe, 14-18 odrębnych układów zbiorowych</li><li>EASA FTL: limit 900 godzin, limity Flight Duty Period</li><li>180+ stawek Per Diem wg krajów (MF)</li><li>Senioryteta Cockpit do stopnia 23</li></ul><div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between"><span class="text-h3 font-bold text-gosign-accent-on-dark">82% Zero-Touch</span><span class="text-small text-gosign-accent-on-dark font-semibold">Aviation szczegółowo &rarr;</span></div></a>
<a href="/pl/uslugi/hr-agent/payroll-decision-layer/financial-services/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors"><div class="flex items-center justify-between mb-4"><h3 class="text-h3 font-bold text-white">Finanse</h3><div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-white/20"></span></div></div><ul class="space-y-1.5 text-small text-gosign-text-on-dark/70"><li>5 równoległych reżimów wynagradzania (tarif do Risk Taker)</li><li>KNF/CRD V: Bonus-Deferral 40-60% przez 4-5 lat</li><li>Malus/Clawback: 5-7 lat okres dochodzenia zwrotu</li><li>Wymogi KNF: obowiązkowe bloki urlopowe dla traderów</li></ul><div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between"><span class="text-h3 font-bold text-gosign-accent-on-dark">85% Zero-Touch</span><span class="text-small text-gosign-accent-on-dark font-semibold">Finanse szczegółowo &rarr;</span></div></a>
<a href="/pl/uslugi/hr-agent/payroll-decision-layer/retail/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors"><div class="flex items-center justify-between mb-4"><h3 class="text-h3 font-bold text-white">Handel</h3><div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-white/20"></span></div></div><ul class="space-y-1.5 text-small text-gosign-text-on-dark/70"><li>16 województw x 6 grup x 6 stopni = 576 stawek</li><li>64% praca w niepełnym wymiarze, umowy zlecenia/o dzieło</li><li>100 000 pracowników sezonowych, 25,7% rotacja</li><li>Kumulacja dodatków: tylko najwyższy, nocny addytywny</li></ul><div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between"><span class="text-h3 font-bold text-gosign-accent-on-dark">92% Zero-Touch</span><span class="text-small text-gosign-accent-on-dark font-semibold">Handel szczegółowo &rarr;</span></div></a>
</div>
</div>
</section>

<!-- Implementacja -->
<section id="implementation" class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Implementacja</p>
<h2 class="text-h1 font-bold text-gosign-dark">Od pilotażu do działającego systemu.</h2>
<div class="grid grid-cols-1 lg:grid-cols-2 gap-10 mt-10">
<div><h3 class="text-h3 font-bold text-gosign-dark mb-3">Architektura techniczna</h3><p class="text-body text-gosign-text">Payroll Decision Layer działa w pełni w Państwa infrastrukturze: Państwa centrum danych, Państwa sieć, Państwa kontrola. Bez zależności od SaaS, bez odpływu danych, bez zewnętrznego śledzenia telemetrycznego. Konteneryzowany, wielomandantowy, gotowy do wdrożenia w Państwa Private Cloud lub jako Managed Deployment w centrach danych UE.</p><div class="flex flex-wrap gap-4 mt-3"><a href="/pl/uslugi/infrastruktura/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infrastruktura szczegółowo &rarr;</a><a href="/pl/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Architektura Decision Layer &rarr;</a><a href="/pl/magazyn/akt-decyzyjny-podwazalne-decyzje-ai/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Akt decyzyjny &rarr;</a><a href="/pl/uslugi/travel-decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Travel Decision Layer &rarr;</a></div></div>
<div><h3 class="text-h3 font-bold text-gosign-dark mb-3">Implementacja</h3><p class="text-body text-gosign-text">Decision Layer nie jest instalowany, lecz konfigurowany: Państwa układy zbiorowe, Państwa reguły dodatków, Państwa krajobraz systemowy. Typowe projekty pilotażowe startują w ciągu 3 miesięcy z jedną grupą pracowniczą i jednym układem zbiorowym. Rozszerzenia na kolejne grupy lub spółki realizowane są równolegle z pilotażem.</p></div>
</div>
<h3 class="text-h3 font-bold text-gosign-dark mt-12 mb-6">Dźwignia ekonomiczna</h3>
<div class="grid grid-cols-1 sm:grid-cols-2 gap-6">
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6"><div class="flex items-start gap-4"><svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12l2 2 4-4m5.618-4.016A11.955 11.955 0 0112 2.944a11.955 11.955 0 01-8.618 3.04A12.02 12.02 0 003 9c0 5.591 3.824 10.29 9 11.622 5.176-1.332 9-6.03 9-11.622 0-1.042-.133-2.052-.382-3.016z" /></svg><div><p class="text-body font-semibold text-gosign-dark">Eliminacja korekt, zanim powstaną</p><p class="text-small text-gosign-text-light mt-2">Każde rozliczenie przechodzi przez ten sam system reguł. Wskaźnik błędów 1-8% (APA) wynika z manualnej interpretacji reguł. Decision Layer stosuje reguły konsekwentnie - we wszystkich obszarach taryfowych, wszystkich grupach pracowniczych, co miesiąc tak samo.</p></div></div></div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6"><div class="flex items-start gap-4"><svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M13 10V3L4 14h7v7l9-11h-7z" /></svg><div><p class="text-body font-semibold text-gosign-dark">Zmiana układu zbiorowego w godzinach zamiast tygodni</p><p class="text-small text-gosign-text-light mt-2">Nową tabelę taryfową wdrożyć, okres obowiązywania ustawić, retroaktywne przeliczenie automatycznie. Żadnej manualnej aktualizacji w 13 okręgach taryfowych. Żadnych zapomnianych lokalizacji.</p></div></div></div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6"><div class="flex items-start gap-4"><svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M12 6v6h4.5m4.5 0a9 9 0 11-18 0 9 9 0 0118 0z" /></svg><div><p class="text-body font-semibold text-gosign-dark">82-92% Zero-Touch. Człowiek tylko gdzie prawnie wymagany.</p><p class="text-small text-gosign-text-light mt-2">AI Agent może każde rozliczenie przetworzyć lepiej niż specjalista ds. wynagrodzeń. Interwencje ludzkie pozostają tam, gdzie Rada Zakładowa, prawo pracy lub ryzyko dyskryminacji ich wymagają - nie z powodów merytorycznych.</p></div></div></div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6"><div class="flex items-start gap-4"><svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12h6m-6 4h6m2 5H7a2 2 0 01-2-2V5a2 2 0 012-2h5.586a1 1 0 01.707.293l5.414 5.414a1 1 0 01.293.707V19a2 2 0 01-2 2z" /></svg><div><p class="text-body font-semibold text-gosign-dark">Kontrola podatkowa to eksport, nie projekt</p><p class="text-small text-gosign-text-light mt-2">Zapieczętowane akta decyzyjne na rozliczenie. Jaka reguła, jakie dane wejściowe, jaki wynik. Tygodnie przygotowań stają się minutami.</p></div></div></div>
</div>
</div>
</section>

<!-- Bezpieczeństwo -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Bezpieczeństwo</p>
<h2 class="text-h1 font-bold text-gosign-dark">Enterprise-Security. Od pierwszego dnia.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Dane wynagrodzeń należą do najbardziej wrażliwych danych w przedsiębiorstwie. Payroll Decision Layer jest zaprojektowany dla regulowanych środowisk, w których ochrona danych, gotowość audytowa i weryfikowalność nie są opcjonalnymi dodatkami.</p>
<div class="mt-10 grid grid-cols-1 sm:grid-cols-3 gap-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">100% infrastruktura klienta</h3><p class="text-small text-gosign-text-light mt-2">Decision Layer działa w pełni w Państwa sieci. Bez zależności od SaaS, bez odpływu danych, bez zewnętrznego śledzenia telemetrycznego. Dane wynagrodzeń nie opuszczają Państwa sieci.</p></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">RODO by Design</h3><p class="text-small text-gosign-text-light mt-2">Anonimizacja zamiast usuwania. Zgodność z podatkowymi okresami przechowywania (10 lat) i RODO art. 17. Brak sprzeczności między prawem podatkowym a ochroną danych.</p><a href="/pl/governance/data-residency/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Rezydencja danych szczegółowo</a></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">Zgodność z AI Act</h3><p class="text-small text-gosign-text-light mt-2">Jasny podział architektoniczny: AI Agent klasyfikuje i rozpoznaje wzorce. Obliczanie wynagrodzeń, dodatków i podatków przebiega deterministycznie przez systemy reguł. Żadnej czarnej skrzynki przy kwotach, pełna weryfikowalność klasyfikacji.</p><a href="/pl/governance/eu-ai-act/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">EU AI Act Readiness</a></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">Audit Trail (append-only)</h3><p class="text-small text-gosign-text-light mt-2">Podpisane akta decyzyjne. Hash danych wejściowych plus wersja reguły daje powtarzalny wynik. Zapieczętowane pakiety audytowe (JSON + PDF, SHA-256). Kontrola w każdej chwili.</p></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">ISO 27001 / PS 951 cert-ready</h3><p class="text-small text-gosign-text-light mt-2">Zintegrowany Controls Registry, zautomatyzowane Evidence Runs, wersjonowane polityki. Zgodność w bieżącej eksploatacji, nie dokumentowana po fakcie.</p><a href="/pl/governance/cert-ready/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready by Design</a></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-body font-bold text-gosign-dark">SSO i separacja mandantów</h3><p class="text-small text-gosign-text-light mt-2">Integracja z istniejącym dostawcą tożsamości. Separacja mandantów na poziomie bazy danych (Row Level Security). Model ról granularnie konfigurowalny. Spółki czysto rozdzielone.</p></div>
</div>
</div>
</section>


<!-- Weitere Agent-Lösungen -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Więcej rozwiązań agentowych</h2>
<p class="text-body-lg text-gosign-text-light mt-4">HR Agents to część naszego portfolio agentów. Dla finansów i innych obszarów oferujemy wyspecjalizowane rozwiązania.</p>
</div>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8 max-w-content">
<a href="/pl/hr-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">HR & People Operations</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Wszystkie HR Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Payroll, Travel, Recruiting, Leave, Lifecycle, Screening. Zgodność z radą zakładową.</p>
</a>
<a href="/pl/finance-ai-agents/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Finance & Accounting</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Finance AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Przetwarzanie dokumentów, księgowanie, amortyzacja, korekty. Integracja z systemami ERP.</p>
</a>
<a href="/pl/kontakt/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent transition-colors group bg-gosign-white">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Indywidualnie</p>
<h3 class="text-h3 font-bold text-gosign-dark group-hover:text-gosign-accent-text transition-colors">Co-Build dla Twojego procesu</h3>
<p class="text-body text-gosign-text-light mt-2">Compliance, operacje, shared services - rozwijamy agentów w modelu co-build.</p>
</a>
</div>
</div>
</section>

<!-- Ten agent w katalogu -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark">Kiedy zacząć? Priorytetyzacja i gotowość governance</h2>
<p class="text-body text-gosign-text mt-4">Katalog agentów HR pokazuje wyniki, złożoność governance, klasyfikację EU AI Act oraz pełną tabelę mikrodecyzji dla tego agenta - umieszczonego w 3 kwadrantach priorytetyzacji z 47 innymi agentami HR.</p>
<a href="/pl/katalog-agentow-hr/payroll-processing-agent/" class="inline-flex items-center gap-2 mt-4 text-body font-semibold text-gosign-accent hover:underline">Zobacz sekwencję i wyniki &rarr;</a>
</div>
</section>

<!-- Pogłębienie -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Pogłębienie w Agent Briefing (Magazyn Gosign)</h2>
<p class="text-body text-gosign-text-light mb-6">Nasza seria artykułów eksperckich dla decydentów wdrażających AI Agents w przedsiębiorstwie.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/pl/magazyn/decision-layer-payroll/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors"><p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Finanse</p><p class="text-body font-semibold text-gosign-dark">Strukturalne eliminowanie błędów płacowych - Decision Layer dla finansów</p></a>
<a href="/pl/magazyn/rada-zakladowa-ai-mitbestimmung/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors"><p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Współdecydowanie</p><p class="text-body font-semibold text-gosign-dark">Rada Zakładowa i AI - współdecydowanie jako ograniczenie architektury</p></a>
<a href="/pl/magazyn/decision-layer-wyjasnienie/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors"><p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Podstawy</p><p class="text-body font-semibold text-gosign-dark">Decision Layer - czym jest i dlaczego każdy AI Agent w przedsiębiorstwie go potrzebuje?</p></a>
</div>
</div>
</section>

--- AI Infrastructure Engineering ---
> LLM Hosting, pipeline RAG, orkiestracja i wdrożenie. Agnostyczna wobec modeli, Self-Hosted lub Cloud. Platforma produkcyjna dla AI Agents.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/pl/dlaczego-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Każda decyzja możliwa do prześledzenia</p>
</div>
</a>
<a href="/pl/dlaczego-gosign/#infrastruktura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Twoja infrastruktura</p>
<p class="text-xs text-gosign-text-light">Bez SaaS. Bez vendor-lock-in.</p>
</div>
</a>
<a href="/pl/dlaczego-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Bez ryzyka US-cloud</p>
</div>
</a>
</div>
</div>
</div>

<!-- Dlaczego infrastruktura jest wąskim gardłem -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Dlaczego infrastruktura jest wąskim gardłem</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Większość firm pilotujących AI Agents nie zawodzi z powodu modelu. Modele działają. Zawodzą z powodu infrastruktury: brak framework governance, brak Audit Trail, brak izolacji tenantów, brak koncepcji wdrożenia, brak integracji z istniejącymi systemami.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Pilot na laptopie to nie architektura produkcyjna. Ta strona opisuje konkretne technologie i konfiguracje, które zamieniają eksperyment LLM w system działający w produkcji.
</p>
<p class="text-body text-gosign-text-light mt-4">
Jak poszczególne komponenty infrastruktury współdziałają architektonicznie, opisuje <a href="/pl/governance/reference-architecture/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">7-warstwowa architektura referencyjna</a>.
</p>
</div>
</div>
</section>

<div class="not-prose my-8 border-2 border-gosign-accent/20 bg-gosign-light rounded-card p-6">
<p class="text-h3 font-bold text-gosign-dark mb-2">Darmowy eBook: Infrastruktura AI</p>
<p class="text-body text-gosign-text mb-4">Build, Buy, Hybrid - infrastruktura zgodna z EU AI Act z B/B/H-Framework i 7-Layer Reference Architecture.</p>
<a href="/pl/ebook/ai-infrastructure-poradnik-governance/" class="inline-flex items-center gap-2 text-gosign-accent-text hover:text-gosign-accent-hover font-medium">Pobierz za darmo</a>
</div>

<!-- 1. LLM Hosting -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Cztery komponenty infrastruktury</h2>

<h3 class="text-h3 font-bold text-gosign-dark mt-8">1. LLM Hosting</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Warstwa modelu. Gdzie odbywa się rozumienie języka.
</p>
<p class="text-body-lg text-gosign-text-light mt-4"><strong>Cloud LLM:</strong></p>
<ul class="mt-2 space-y-2">
<li class="text-body-lg text-gosign-text-light">Azure OpenAI (ChatGPT, Claude) - regiony UE, DPA Microsoftu</li>
<li class="text-body-lg text-gosign-text-light">Amazon Bedrock (Claude, Llama, Mistral) - regiony UE, DPA AWS</li>
<li class="text-body-lg text-gosign-text-light">Google Vertex AI (Gemini) - regiony UE, DPA Google</li>
<li class="text-body-lg text-gosign-text-light">Anthropic API (Claude) - z EU Data Processing</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-4"><strong>Self-Hosted LLM:</strong></p>
<ul class="mt-2 space-y-2">
<li class="text-body-lg text-gosign-text-light">Llama (Meta) - open source, na własnym hardware</li>
<li class="text-body-lg text-gosign-text-light">Mistral - open source, firma z UE</li>
<li class="text-body-lg text-gosign-text-light">DeepSeek - open source, efektywny kosztowo</li>
<li class="text-body-lg text-gosign-text-light"><a href="https://openai.com/open-models/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">gpt-oss</a> (OpenAI) - open weight, Apache 2.0, w pełni self-hostowany. 120B na pojedynczym H100, 20B na 16 GB hardware konsumenckim.</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-4"><strong>Frameworki inferencji dla Self-Hosted:</strong></p>
<ul class="mt-2 space-y-2">
<li class="text-body-lg text-gosign-text-light"><a href="https://ollama.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Ollama</a> - proste wejście, lokalne środowisko deweloperskie, edge deployment</li>
<li class="text-body-lg text-gosign-text-light"><a href="https://docs.vllm.ai/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">vLLM</a> - production-grade, optymalizacja GPU, wysoki throughput</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-4"><strong>Hybryda:</strong></p>
<ul class="mt-2 space-y-2">
<li class="text-body-lg text-gosign-text-light">Self-Hosted dla danych wrażliwych (HR, finanse)</li>
<li class="text-body-lg text-gosign-text-light">Cloud LLM dla mniej krytycznych obciążeń (klasyfikacja dokumentów)</li>
<li class="text-body-lg text-gosign-text-light">Automatyczny routing według klasyfikacji danych</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-4">
Wybór modelu to kompromis między wydajnością, kosztami, ochroną danych i latencją. Doradzamy przy wyborze i implementujemy agnostycznie wobec modeli - zmiana modelu nie wpływa na logikę biznesową.
</p>
<p class="text-body text-gosign-text-light mt-4">
Więcej: <a href="/pl/magazyn/modele-ai-porownanie-2026/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Porównanie modeli AI 2026</a> · <a href="/pl/magazyn/llm-self-hosting-enterprise/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">LLM Self-Hosting dla Enterprise</a>
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Nasi inżynierowie AI posiadają certyfikaty Microsoft Azure AI Services. Opcje wdrożenia obejmują <a href="https://azure.microsoft.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Microsoft Azure</a>, <a href="https://cloud.google.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">GCP</a> oraz w pełni samodzielnie hostowaną infrastrukturę - decyzja architektoniczna należy do klienta, nie do dostawcy.
</p>
</div>
</div>
</section>

<!-- 2. RAG-Pipeline -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h3 class="text-h3 font-bold text-gosign-dark">2. Pipeline RAG</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Retrieval Augmented Generation - jak agenci uzyskują dostęp do wiedzy korporacyjnej.
</p>
</div>
<img src="/images/diagrams/rag-pipeline-pl.svg" alt="Pipeline RAG: dokumenty są dzielone na chunki, przechowywane jako embeddingi w Vector Store, podczas zapytań pobierane semantycznie i przekazywane do LLM jako kontekst" class="w-full mt-6" width="1200" height="400" loading="lazy" />
<div class="max-w-narrow mt-6">
<p class="text-body-lg text-gosign-text-light"><strong>Cechy jakościowe:</strong></p>
<ul class="mt-2 space-y-2">
<li class="text-body-lg text-gosign-text-light">Semantyczny chunking (nie według numeru strony, lecz według treści)</li>
<li class="text-body-lg text-gosign-text-light">Wzbogacanie metadanymi (typ dokumentu, wersja, zakres obowiązywania)</li>
<li class="text-body-lg text-gosign-text-light">Wyszukiwanie hybrydowe (wyszukiwanie wektorowe + wyszukiwanie słownikowe dla precyzji)</li>
<li class="text-body-lg text-gosign-text-light">Cytowanie źródła w każdej odpowiedzi (dokument, strona, akapit)</li>
<li class="text-body-lg text-gosign-text-light">Regularna reindeksacja przy zmianach dokumentów</li>
</ul>
</div>
</div>
</section>

<!-- 3. Orkiestracja -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h3 class="text-h3 font-bold text-gosign-dark">3. Orkiestracja</h3>
<p class="text-body-lg text-gosign-text-light mt-4">
Sterowanie przebiegiem. Jak agenci, systemy i ludzie współpracują.
</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light"><strong><a href="https://trigger.dev" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Trigger.dev</a> lub <a href="https://camunda.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Camunda</a>:</strong> Silnik workflow open source. Wizualne workflow, integracja API, webhooki. Self-Hosted, brak vendor lock-in.</li>
<li class="text-body-lg text-gosign-text-light"><strong>API Gateway:</strong> Jednolity punkt wejścia. Rate limiting, uwierzytelnianie, logowanie, monitoring.</li>
<li class="text-body-lg text-gosign-text-light"><strong>System kolejek:</strong> Asynchroniczne przetwarzanie dla operacji wsadowych (zamknięcie miesiąca, masowy import).</li>
<li class="text-body-lg text-gosign-text-light"><strong>System zdarzeń:</strong> Reakcja w czasie rzeczywistym na przychodzące dokumenty, zmiany statusu, eskalacje.</li>
</ul>
<p class="text-body-lg text-gosign-text-light mt-4">
Orkiestracja to różnica między "agent może coś" a "agent robi coś niezawodnie w produkcji".
</p>
<p class="text-body text-gosign-text-light mt-4">
Więcej: <a href="/pl/magazyn/orkiestracja-agentow-platformy/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Platformy orkiestracji agentów</a>
</p>
</div>
</div>
</section>

<!-- 4. Wdrożenie -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h3 class="text-h3 font-bold text-gosign-dark">4. Wdrożenie</h3>
<p class="text-body-lg text-gosign-text-light mt-4">Gdzie działa infrastruktura. Wszystkie opcje w UE.</p>

<h4 class="text-body-lg font-bold text-gosign-dark mt-6">Azure (UE)</h4>
<ul class="mt-2 space-y-1">
<li class="text-body text-gosign-text-light">Azure Kubernetes Service (AKS) do orkiestracji kontenerów</li>
<li class="text-body text-gosign-text-light">Azure SQL / PostgreSQL dla danych i Audit Trail</li>
<li class="text-body text-gosign-text-light">Azure OpenAI do hostingu LLM</li>
<li class="text-body text-gosign-text-light">Regiony: West Europe, North Europe, Poland Central</li>
</ul>

<h4 class="text-body-lg font-bold text-gosign-dark mt-6">AWS (UE)</h4>
<ul class="mt-2 space-y-1">
<li class="text-body text-gosign-text-light">Amazon EKS do orkiestracji kontenerów</li>
<li class="text-body text-gosign-text-light">Amazon RDS / Aurora PostgreSQL dla danych i Audit Trail</li>
<li class="text-body text-gosign-text-light">Amazon Bedrock do hostingu LLM (Claude, Llama, Mistral)</li>
<li class="text-body text-gosign-text-light">Regiony: eu-central-1 (Frankfurt), eu-west-1 (Irlandia), eu-west-3 (Paryż)</li>
</ul>

<h4 class="text-body-lg font-bold text-gosign-dark mt-6">GCP (UE)</h4>
<ul class="mt-2 space-y-1">
<li class="text-body text-gosign-text-light">Google Kubernetes Engine (GKE) do orkiestracji kontenerów</li>
<li class="text-body text-gosign-text-light">Cloud SQL / AlloyDB dla danych i Audit Trail</li>
<li class="text-body text-gosign-text-light">Vertex AI do hostingu LLM</li>
<li class="text-body text-gosign-text-light">Regiony: europe-central2 (Warszawa), europe-west1, europe-west3</li>
</ul>

<h4 class="text-body-lg font-bold text-gosign-dark mt-6">Vercel EU + Supabase EU</h4>
<ul class="mt-2 space-y-1">
<li class="text-body text-gosign-text-light">Vercel dla frontend i edge functions w centrach danych UE</li>
<li class="text-body text-gosign-text-light">Supabase dla bazy danych (PostgreSQL), auth i storage</li>
<li class="text-body text-gosign-text-light">Lekka opcja wdrożenia UE bez własnej infrastruktury Kubernetes</li>
<li class="text-body text-gosign-text-light">Usługi managed z EU Data Residency</li>
</ul>

<h4 class="text-body-lg font-bold text-gosign-dark mt-6">Self-Hosted</h4>
<ul class="mt-2 space-y-1">
<li class="text-body text-gosign-text-light"><a href="https://www.docker.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Docker</a> / <a href="https://kubernetes.io/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Kubernetes</a> na własnym hardware</li>
<li class="text-body text-gosign-text-light"><a href="https://www.postgresql.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">PostgreSQL</a> z <a href="https://github.com/pgvector/pgvector" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">pgvector</a> dla danych i wyszukiwania wektorowego</li>
<li class="text-body text-gosign-text-light">Modele open source na własnych GPU</li>
<li class="text-body text-gosign-text-light">Pełna niezależność od Cloud Act</li>
</ul>

<h4 class="text-body-lg font-bold text-gosign-dark mt-6">Hybryda</h4>
<ul class="mt-2 space-y-1">
<li class="text-body text-gosign-text-light">Kombinacja według klasyfikacji danych</li>
<li class="text-body text-gosign-text-light">Wrażliwe obciążenia Self-Hosted, standardowe obciążenia w chmurze</li>
<li class="text-body text-gosign-text-light">Jednolita orkiestracja we wszystkich środowiskach</li>
</ul>
</div>
</div>
</section>

<!-- Stos technologiczny -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Stos technologiczny</h2>
<div class="mt-8 overflow-x-auto">
<table class="w-full text-left text-small border-collapse">
<thead>
<tr>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Komponent</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Technologia</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Dlaczego</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Silnik workflow</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://trigger.dev" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Trigger.dev</a>, <a href="https://camunda.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Camunda</a></td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Open source, Self-Hosted, brak vendor lock-in</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Baza danych</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://www.postgresql.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">PostgreSQL</a> + <a href="https://github.com/pgvector/pgvector" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">pgvector</a></td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Enterprise-ready, RLS, zintegrowane wyszukiwanie wektorowe</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Backend</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://www.python.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Python</a>, <a href="https://www.typescriptlang.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">TypeScript</a></td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Sprawdzone dla ML i rozwoju API</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Frontend</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://react.dev/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">React</a> / <a href="https://nextjs.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Next.js</a></td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Dashboard, Chat UI, Portal Audytora</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Kontenery</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://www.docker.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Docker</a>, <a href="https://kubernetes.io/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Kubernetes</a></td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Standard dla chmury i Self-Hosted</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">API</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">REST, <a href="https://graphql.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">GraphQL</a></td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Integracja z istniejącymi systemami</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Auth</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://supabase.com/auth" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Supabase Auth</a> / OIDC</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Obsługa SSO, enterprise identity providers</td></tr>
<tr class="bg-gosign-light"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Monitoring</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://prometheus.io/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Prometheus</a>, <a href="https://grafana.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Grafana</a></td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Open source, Self-Hosted, dashboardy w czasie rzeczywistym</td></tr>
<tr class="bg-gosign-white"><td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Inferencja</td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://ollama.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Ollama</a>, <a href="https://docs.vllm.ai/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">vLLM</a></td><td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border">Self-Hosted LLM Inference, optymalizacja GPU</td></tr>
</tbody>
</table>
</div>
</div>
</div>
</section>

<!-- Governance jest wbudowany -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Governance jest wbudowany</h2>
<p class="text-body-lg text-gosign-text-light mt-4">Infrastruktura zawiera Governance by Design:</p>
<ul class="mt-4 space-y-2">
<li class="text-body-lg text-gosign-text-light"><strong>Audit Trail</strong> na poziomie infrastruktury (nie tylko aplikacji)</li>
<li class="text-body-lg text-gosign-text-light"><strong>Row-Level Security</strong> na poziomie bazy danych - <a href="/pl/governance/data-residency/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Data Residency w szczegółach</a></li>
<li class="text-body-lg text-gosign-text-light"><strong>Szyfrowanie</strong> at rest i in transit</li>
<li class="text-body-lg text-gosign-text-light"><strong>RBAC</strong> we wszystkich komponentach</li>
<li class="text-body-lg text-gosign-text-light"><a href="/pl/governance/cert-ready/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold"><strong>Cert-Ready Controls</strong></a> jako techniczne obiekty danych</li>
</ul>
<p class="mt-4">
<a href="/pl/governance/reference-architecture/" class="text-gosign-accent-text hover:text-gosign-accent-hover font-semibold">Governance w architekturze 7-warstwowej -></a>
</p>
</div>
</div>
</section>

<!-- Pełny dostęp do kodu -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Pełny dostęp do kodu źródłowego</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Infrastruktura działa u klienta - w Azure, GCP, AWS lub Self-Hosted. Bez SaaS, bez hostingu u Gosign. Pełny dostęp do kodu źródłowego, konfiguracji i zestawów reguł. Stos open source tam, gdzie to możliwe. Komponenty proprietarne tylko w samych LLM - i tam agnostycznie wobec modeli.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Po 12-18 miesiącach klient operuje infrastrukturą samodzielnie.
</p>
</div>
</div>
</section>

<!-- Pogłębienie -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Pogłębienie w Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nasza seria artykułów fachowych dla decydentów wdrażających agentów AI.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/pl/magazyn/infrastruktura-ai-blueprint-2026/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">Enterprise AI-Infrastruktura Blueprint 2026</p>
</a>
<a href="/pl/magazyn/hosting-ai-strategie-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">Hosting AI: EU SaaS, europejskie centrum danych czy Self-Hosted?</p>
</a>
<a href="/pl/magazyn/llm-self-hosting-enterprise/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">LLM Self-Hosting dla enterprise - Azure, GCP, On-Premise</p>
</a>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark mb-6">Pogłębienie</h2>
<div class="grid gap-6 sm:grid-cols-2">
<div class="border-l-4 border-gosign-dark pl-6 py-4">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Architektura</p>
<h3 class="text-h3 font-bold text-gosign-dark">7-warstwowa architektura referencyjna</h3>
<p class="text-body text-gosign-text-light mt-2">Jak komponenty infrastruktury współdziałają architektonicznie - Presentation, Orchestration, Agent, Decision Layer, Model, Integration, Infrastructure.</p>
<a href="/pl/governance/reference-architecture/" class="text-small font-semibold text-gosign-accent-text hover:text-gosign-accent-hover mt-3 inline-block whitespace-nowrap">Do architektury referencyjnej -></a>
</div>
<div class="border-l-4 border-gosign-dark pl-6 py-4">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Wiedza</p>
<h3 class="text-h3 font-bold text-gosign-dark">Blueprint 2026</h3>
<p class="text-body text-gosign-text-light mt-2">Jedenaście artykułów o decyzjach infrastrukturalnych, które mają znaczenie w 2026: modele AI, hosting, RAG, orkiestracja, koszty, EU AI Act.</p>
<div class="mt-3 flex flex-wrap gap-3">
<a href="/pl/magazyn/infrastruktura-ai-blueprint-2026/" class="text-small font-semibold text-gosign-accent-text hover:text-gosign-accent-hover whitespace-nowrap">Przegląd -></a>
<a href="/pl/magazyn/modele-ai-porownanie-2026/" class="text-small font-semibold text-gosign-accent-text hover:text-gosign-accent-hover whitespace-nowrap">Modele AI 2026 -></a>
</div>
</div>
<div class="border-l-4 border-gosign-dark pl-6 py-4">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Governance</p>
<h3 class="text-h3 font-bold text-gosign-dark">Data Residency</h3>
<p class="text-body text-gosign-text-light mt-2">Gdzie dane są przechowywane, jak zapewnić zgodność z RODO i EU Data Residency - regiony chmurowe, szyfrowanie, izolacja.</p>
<a href="/pl/governance/data-residency/" class="text-small font-semibold text-gosign-accent-text hover:text-gosign-accent-hover mt-3 inline-block whitespace-nowrap">Data Residency -></a>
</div>
<div class="border-l-4 border-gosign-dark pl-6 py-4">
<p class="text-xs font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Agenci</p>
<h3 class="text-h3 font-bold text-gosign-dark">AI Agents</h3>
<p class="text-body text-gosign-text-light mt-2">Document Agents, Workflow Agents, Knowledge Agents - trzy typy agentów dla procesów enterprise.</p>
<a href="/pl/uslugi/ai-agents/" class="text-small font-semibold text-gosign-accent-text hover:text-gosign-accent-hover mt-3 inline-block whitespace-nowrap">Do AI Agents -></a>
</div>
</div>
</div>
</div>
</section>

--- Inżynieria Oprogramowania Korporacyjnego od 2001 ---
> Ponad 5 000 projektów dla Airbus, Volkswagen, Shell. 25 lat rozwoju oprogramowania korporacyjnego - dziś fundament infrastruktury AI.

<!-- 25 Lat -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">25 Lat Oprogramowania Korporacyjnego</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Gosign rozwija oprogramowanie dla klientów korporacyjnych od 2001. Ponad 5 000 projektów dla <a href="/pl/referencje/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Airbus, Volkswagen, Shell</a> i innych. Fundament: bezpieczeństwo, skalowalność i utrzymywalność w środowiskach dużych organizacji.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
Nie jesteśmy dwuletnim startupem AI. Jesteśmy firmą inżynierską z 25 latami doświadczenia w oprogramowaniu korporacyjnym - dziś budujemy <a href="/pl/uslugi/ai-agents/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">infrastrukturę AI</a> na tym fundamencie.
</p>
</div>
</section>

<!-- Co Budujemy Dziś -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark mb-8">Co Budujemy Dziś</h2>
<div class="grid grid-cols-1 md:grid-cols-2 gap-6 lg:gap-8">
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8">
<div class="mb-4">
<svg xmlns="http://www.w3.org/2000/svg" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" class="w-8 h-8 text-gosign-accent-text" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" d="M13.19 8.688a4.5 4.5 0 0 1 1.242 7.244l-4.5 4.5a4.5 4.5 0 0 1-6.364-6.364l1.757-1.757m9.864-9.864a4.5 4.5 0 0 0-6.364 6.364l4.5 4.5a4.5 4.5 0 0 0 7.244 1.242" />
</svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Integracje niestandardowe</h3>
<p class="text-body text-gosign-text-light mt-2">Połączenie AI Agents z istniejącymi systemami. SAP, Comarch, SuccessFactors, Workday, Microsoft Graph.</p>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8">
<div class="mb-4">
<svg xmlns="http://www.w3.org/2000/svg" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" class="w-8 h-8 text-gosign-accent-text" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" d="M14.25 9.75 16.5 12l-2.25 2.25m-4.5 0L7.5 12l2.25-2.25M6 20.25h12A2.25 2.25 0 0 0 20.25 18V6A2.25 2.25 0 0 0 18 3.75H6A2.25 2.25 0 0 0 3.75 6v12A2.25 2.25 0 0 0 6 20.25Z" />
</svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Rozwój API</h3>
<p class="text-body text-gosign-text-light mt-2">REST i GraphQL. Autentykacja, rate limiting, wersjonowanie.</p>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8">
<div class="mb-4">
<svg xmlns="http://www.w3.org/2000/svg" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" class="w-8 h-8 text-gosign-accent-text" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" d="m21 7.5-9-5.25L3 7.5m18 0-9 5.25m9-5.25v9l-9 5.25M3 7.5l9 5.25M3 7.5v9l9 5.25m0-9v9" />
</svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Architektura systemów</h3>
<p class="text-body text-gosign-text-light mt-2">Model danych, strategia wdrożenia, koncepcja skalowania, architektura bezpieczeństwa.</p>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8">
<div class="mb-4">
<svg xmlns="http://www.w3.org/2000/svg" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" class="w-8 h-8 text-gosign-accent-text" aria-hidden="true">
<path stroke-linecap="round" stroke-linejoin="round" d="M9 17.25v1.007a3 3 0 0 1-.879 2.122L7.5 21h9l-.621-.621A3 3 0 0 1 15 18.257V17.25m6-12V15a2.25 2.25 0 0 1-2.25 2.25H5.25A2.25 2.25 0 0 1 3 15V5.25m18 0A2.25 2.25 0 0 0 18.75 3H5.25A2.25 2.25 0 0 0 3 5.25m18 0V12a2.25 2.25 0 0 1-2.25 2.25H5.25A2.25 2.25 0 0 1 3 12V5.25" />
</svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Platformy korporacyjne</h3>
<p class="text-body text-gosign-text-light mt-2">Dashboardy, portale audytora, interfejsy chat, narzędzia workflow.</p>
</article>
</div>
</div>
</section>

<!-- Zasady Inżynierskie -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Zasady Inżynierskie</h2>
<div class="mt-6 space-y-6">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">TDD & ciągły Pair Programming</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Każda linia kodu powstaje w pair programming. Testy przed kodem. Każda funkcja ma testy. Każdy merge wymaga zielonych testów.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">CI/CD</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Automatyczny pipeline. Każdy push testowany. Każdy merge wdrażany.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Code Review</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Zasada czterech oczu dla wszystkich zmian produkcyjnych.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Security by Design</h3>
<p class="text-body-lg text-gosign-text-light mt-2">RBAC, szyfrowanie, walidacja wejścia od dnia 1.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Audit Trail</h3>
<p class="text-body-lg text-gosign-text-light mt-2">Każda zmiana udokumentowana. Kto zmienił co kiedy.</p>
</div>
</div>
</div>
</section>

<!-- Stack Technologiczny -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Stack Technologiczny</h2>
</div>
<div class="mt-8 overflow-x-auto">
<table class="w-full text-left text-small border-collapse min-w-[36rem]">
<thead>
<tr>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Obszar</th>
<th class="bg-gosign-dark text-white px-4 py-3 font-semibold">Technologie</th>
</tr>
</thead>
<tbody>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Backend</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://www.python.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Python</a>, <a href="https://www.typescriptlang.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">TypeScript</a>, Node.js</td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Frontend</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://react.dev/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">React</a>, <a href="https://nextjs.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Next.js</a></td>
</tr>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Baza danych</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://www.postgresql.org/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">PostgreSQL</a>, Supabase</td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Workflow</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://trigger.dev" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Trigger.dev</a>, <a href="https://n8n.io/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">n8n</a>, <a href="https://camunda.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Camunda</a></td>
</tr>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Kontenery</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://www.docker.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Docker</a>, <a href="https://kubernetes.io/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Kubernetes</a></td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">CI/CD</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://github.com/features/actions" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">GitHub Actions</a>, <a href="https://docs.gitlab.com/ee/ci/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">GitLab CI</a></td>
</tr>
<tr class="bg-gosign-white">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Monitoring</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://prometheus.io/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Prometheus</a>, <a href="https://grafana.com/" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Grafana</a></td>
</tr>
<tr class="bg-gosign-light">
<td class="px-4 py-3 font-medium text-gosign-dark border-b border-gosign-border">Auth</td>
<td class="px-4 py-3 text-gosign-text-light border-b border-gosign-border"><a href="https://supabase.com/auth" target="_blank" rel="noopener noreferrer" class="text-gosign-text-light underline decoration-gosign-border hover:text-gosign-accent-text transition-colors">Supabase Auth</a>, OIDC</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Od Oprogramowania do Infrastruktury AI -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Od Oprogramowania do Infrastruktury AI</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Te same zasady inżynierskie. Różnica: AI Agent podejmuje decyzje eksperckie, które muszą być udokumentowane i identyfikowalne. To wymaga dodatkowych komponentów - <a href="/pl/decision-layer/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Decision Layer</a>, Governance by Design, kontrole <a href="/pl/governance/cert-ready/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">Cert-Ready</a>. Ale fundament to inżynieria oprogramowania.
</p>
<p class="text-body-lg text-gosign-text-light mt-4">
25 lat tego fundamentu to powód, dla którego nasza <a href="/pl/uslugi/infrastruktura/" class="text-gosign-accent-text hover:text-gosign-accent-hover transition-colors font-semibold">infrastruktura AI</a> działa.
</p>
</div>
</section>

<!-- Pogłębienie -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Pogłębienie w Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nasza seria artykułów fachowych dla decydentów wdrażających agentów AI.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/pl/magazyn/integracja-ai-krajobraz-it/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">Integracja AI z istniejacym krajobrazem IT - SAP, Comarch, Workday</p>
</a>
<a href="/pl/magazyn/agenci-ai-enterprise-przewodnik/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">AI Agents</p>
<p class="text-body font-semibold text-gosign-dark">Od chatbotów do agentów AI: MCP, A2A i systemy Multi-Agent</p>
</a>
<a href="/pl/magazyn/infrastruktura-ai-blueprint-2026/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Infrastructure</p>
<p class="text-body font-semibold text-gosign-dark">Enterprise AI-Infrastruktura Blueprint 2026</p>
</a>
</div>
</div>
</section>

--- AI Travel Agent Doradztwo - Koszty podróży ---
> Decision Layer dla podróży doradczych. Trójstronny podział kosztów: podatkowy/klient/wewnętrzny, tygodnie multi-klienckie.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/pl/dlaczego-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Każda decyzja możliwa do prześledzenia</p>
</div>
</a>
<a href="/pl/dlaczego-gosign/#infrastruktura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Twoja infrastruktura</p>
<p class="text-xs text-gosign-text-light">Bez SaaS. Bez vendor-lock-in.</p>
</div>
</a>
<a href="/pl/dlaczego-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Bez ryzyka US-cloud</p>
</div>
</a>
</div>
</div>
</div>

<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Travel Decision Layer Branże">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/pl/uslugi/travel-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Travel Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/pl/uslugi/travel-decision-layer/lotnictwo/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Lotnictwo</a>
<a href="/pl/uslugi/travel-decision-layer/doradztwo/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Doradztwo</a>
<a href="/pl/uslugi/travel-decision-layer/logistyka/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Logistyka</a>
<a href="/pl/uslugi/travel-decision-layer/sprzedaz/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Sprzedaż</a>
</div>
</div>
</nav>

<!-- Dlaczego doradztwo jest złożone -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<!-- Wskaźniki symulacyjne jako wizualne wprowadzenie -->
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">50 000+</span>
<p class="text-small text-gosign-text-light mt-1">Spraw/rok (symulacja)</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">85%</span>
<p class="text-small text-gosign-text-light mt-1">Wskaźnik Zero-Touch</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">3-stronny</span>
<p class="text-small text-gosign-text-light mt-1">Podział kosztów (podatkowy/klient/wewnętrzny)</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-border"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">Wysoka złożoność reguł</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">Sprawy i Zero-Touch: model symulacyjny Gosign. Benchmarki branżowe: GBTA Foundation, 2015.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Co Agent klasyfikuje</p>
<h2 class="text-h1 font-bold text-gosign-dark">Trzy podziały, jeden Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Podział klientów, podział kosztów, podział podatkowy - każda podróż doradcza wymaga trzech jednoczesnych decyzji. Znacie tę złożoność. Tak ją rozwiązuje AI Agent:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Trójstronny podział na transakcję</h3>
<p class="text-body text-gosign-text mt-2">Każda podróż doradcza wymaga trzech perspektyw kosztowych jednocześnie. AI Agent klasyfikuje traktowanie podatkowe, przypisanie do klienta i wewnętrzne centrum kosztów na każdą transakcję. Silnik reguł oblicza wszystkie trzy podziały deterministycznie. Rezultat: jeden input, trzy spójne wyniki.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Tygodnie wieloklientowe automatycznie podzielone</h3>
<p class="text-body text-gosign-text mt-2">Konsultant odwiedza klienta A w poniedziałek, klienta B w środę. AI Agent klasyfikuje przypisanie klienta na dzień z danych kalendarza i CRM. Silnik reguł dzieli hotel, diety i koszty transportu proporcjonalnie. Każdy podział udokumentowany w Audit Trail.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Konflikt polityk automatycznie rozwiązany</h3>
<p class="text-body text-gosign-text mt-2">Polityka wewnętrzna first-class, klient wymaga economy. AI Agent rozpoznaje konflikt i stosuje bardziej restrykcyjną regułę. Silnik reguł dokumentuje, która polityka zadziałała i dlaczego. Żadnych ręcznych eskalacji dla standardowych przypadków.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Koszty reprezentacji według jurysdykcji</h3>
<p class="text-body text-gosign-text mt-2">Kolacja z klientem w Warszawie: koszty reprezentacji nieodliczalne od CIT. Ta sama kolacja w Niemczech: 70% odliczalne. AI Agent klasyfikuje typ wydatku, jurysdykcję i okazję. Silnik reguł stosuje prawidłową stawkę odliczenia deterministycznie.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Rozliczenia klientów automatycznie udokumentowane</h3>
<p class="text-body text-gosign-text mt-2">200 konsultantów, 4 podróże miesięcznie, 800 spraw. AI Agent generuje kompletną dokumentację rozliczeniową na klienta automatycznie. Każde przypisanie kosztów gotowe na refakturę. Ryzyko błędnego obciążenia klienta eliminowane systemowo.</p>
</div>
</div>
</div>
</section>

<!-- Decision Flow -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Jeden tydzień doradczy. 20 do 60 mikro-decyzji.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Konsultant odwiedza trzech klientów w ciągu tygodnia z kolacjami biznesowymi i zmieniającymi się hotelami. Decision Layer rozkłada ten tydzień na pojedyncze kroki decyzyjne:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Krok</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Decyzja</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Decydent</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Uzasadnienie</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Przypisanie podróży do projektu klienta</td><td class="py-3 px-4">Silnik reguł</td><td class="py-3 px-4">Integracja z kalendarzem lub CRM</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Określenie diety</td><td class="py-3 px-4">Silnik reguł</td><td class="py-3 px-4">Diety krajowe i zagraniczne wg Rozporządzenia Ministra Pracy</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Podział kosztów hotelu: refakturowane vs. wewnętrzne</td><td class="py-3 px-4">Silnik reguł</td><td class="py-3 px-4">Warunki umowy z klientem określają podział</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Sprawdzenie polityki podróżnej klienta</td><td class="py-3 px-4">Silnik reguł</td><td class="py-3 px-4">Klient economy vs. wewnętrzna first-class</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Zastosowanie bardziej restrykcyjnej polityki</td><td class="py-3 px-4">Silnik reguł</td><td class="py-3 px-4">Która polityka jest bardziej restrykcyjna, ta obowiązuje</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Klasyfikacja podatkowa</td><td class="py-3 px-4">Silnik reguł</td><td class="py-3 px-4">Odliczalne, częściowo odliczalne, reprezentacja</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Podział dnia multi-klienckiego</td><td class="py-3 px-4">AI + Silnik reguł</td><td class="py-3 px-4">AI określa alokację czasu, reguły stosują podział kosztów</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">Wygenerowanie podstawy fakturowej na klienta</td><td class="py-3 px-4">Automatyczny</td><td class="py-3 px-4">Dokumentacja rozliczeń podróży gotowa na audyt per klient</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Klasyfikacja wydatków reprezentacyjnych</td><td class="py-3 px-4">AI + Silnik reguł</td><td class="py-3 px-4">AI rozpoznaje typ dokumentu, silnik reguł stosuje stawki odliczenia wg jurysdykcji</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Wygenerowanie aktu audytowego</td><td class="py-3 px-4">Automatyczny</td><td class="py-3 px-4">Zapieczętowana dokumentacja decyzyjna na tydzień doradczy</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Wynik symulacji -->
<section id="simulation" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Symulacja</p>
<h2 class="text-h1 font-bold text-white">Przeanalizowane dla wolumenów doradczych</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Skonfigurowaliśmy Travel Decision Layer z realistycznymi parametrami doradczymi i przeliczyliśmy. Wyniki pokazują, co zmienia się przy wolumenach Enterprise.</p>

<!-- Tabela parametrów -->
<h3 class="text-h3 font-bold text-white mt-10 mb-4">Parametry symulacji</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Konsultanci</td><td class="py-3 px-4">100 do 500+ (z regułami polityk specyficznymi dla klientów)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Umowy z klientami</td><td class="py-3 px-4">10 do 50+ równoległych (każda z własnymi politykami podróżnymi)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Sprawy/rok</td><td class="py-3 px-4">50 000 do 250 000+</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Jurysdykcje</td><td class="py-3 px-4">Multi-jurysdykcja (PL, DE, AT, CH, dalsze kraje UE)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Integracja systemowa</td><td class="py-3 px-4">CRM/rejestracja czasu &rarr; Decision Layer &rarr; ERP/Payroll</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Udział wydatków reprezentacyjnych</td><td class="py-3 px-4">15 - 25% wszystkich spraw zawiera dokumenty reprezentacyjne</td></tr>
</tbody>
</table>
</div>

<!-- Porównanie wyników -->
<h3 class="text-h3 font-bold text-white mt-10 mb-4">Przed / Po</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th class="text-left py-3 px-4 font-semibold text-white">Wymiar</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Ręcznie</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Koszty przetwarzania</td><td class="py-3 px-4">od EUR 53 (GBTA)*</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; EUR 9</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Wskaźnik błędów</td><td class="py-3 px-4">19% (GBTA)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 0,3%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Czas przetwarzania</td><td class="py-3 px-4">5 - 12 dni roboczych</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Minuty</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Wskaźnik Zero-Touch</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">85%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Gotowość na audyt</td><td class="py-3 px-4">Ręcznie rekonstruowana</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatycznie generowana</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Dokładność podziału</td><td class="py-3 px-4">Ręcznie szacowana</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Deterministycznie obliczana</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Rozliczenie z klientem</td><td class="py-3 px-4">Ręcznie przypisywane</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatycznie dokumentowane</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">* GBTA Foundation 2024: USD 58 za transakcję (ok. EUR 53). Sprawy doradcze z trójstronnym podziałem i logiką multi-kliencką są branżowo wyższe. Wyniki symulacji: model obliczeniowy Gosign.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">W symulacji Decision Layer osiąga wskaźnik Zero-Touch na poziomie 85% - w przypadkach standardowych z jednoznacznym przypisaniem do klienta. Pozostałe 15% dotyczy dni multi-klienckich i przypadków specjalnych wymagających oceny ludzkiej. Dla wszystkich przypadków dostępna jest kompletna, gotowa na kontrolę dokumentacja decyzyjna.</p>
</div>
</section>

<!-- Referencja architektoniczna -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Architektura i implementacja</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">Travel Decision Layer działa w pełni w Państwa infrastrukturze: Państwa centrum danych, Państwa sieć, Państwa kontrola. Bez zależności SaaS, bez odpływu danych. Dla konfiguracji doradczych oznacza to: wieloklientowość z oddzielnymi zestawami reguł polityk, integrację z systemami zarządzania projektami i rejestracji czasu pracy oraz automatyczny trójstronny podział kosztów. Typowe projekty pilotażowe rozpoczynają się w ciągu 3 miesięcy z jedną pulą klientów.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/pl/uslugi/travel-decision-layer/#implementation" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Architektura, implementacja i dźwignia szczegółowo &rarr;</a>
<a href="/pl/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Architektura Decision Layer &rarr;</a>
<a href="/pl/uslugi/infrastruktura/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infrastruktura szczegółowo &rarr;</a>
<a href="/pl/governance/co-determination/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Współdecydowanie &amp; Rada Zakładowa &rarr;</a>
<a href="/pl/governance/cert-ready/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready by Design &rarr;</a>
</div>
</div>
</section>

<!-- Pogłębienie -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Pogłębienie w Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nasza seria artykułów fachowych dla decydentów wdrażających agentów AI.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/pl/magazyn/decision-layer-wyjasnienie/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Podstawy</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - czym jest i dlaczego każdy agent AI go potrzebuje?</p>
</a>
<a href="/pl/magazyn/agent-governance-hr/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Agent Governance w HR - Dlaczego CHRO musi prowadzić ten temat</p>
</a>
<a href="/pl/magazyn/cert-ready-by-design/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Audyt</p>
<p class="text-body font-semibold text-gosign-dark">Cert-Ready by Design - AI gotowe do audytu od startu</p>
</a>
</div>
</div>
</section>

<!-- Inne branże -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Travel Decision Layer w innych branżach</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Każda branża ma własne taryfy, struktury kosztów i czynniki złożoności. Decision Layer jest ten sam. Konfiguracja jest branżowa.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/pl/uslugi/travel-decision-layer/lotnictwo/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Lotnictwo</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">Załogi, układy zbiorowe, IROP, multi-jurysdykcja</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">95% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Szczegółowo &rarr;</span>
</div>
</a>
<a href="/pl/uslugi/travel-decision-layer/logistyka/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Logistyka</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">GPS, Pakiet mobilności UE, Zero-Touch kierowca</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">95% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Szczegółowo &rarr;</span>
</div>
</a>
<a href="/pl/uslugi/travel-decision-layer/sprzedaz/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Sprzedaż</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">500 przedstawicieli, integracja CRM, reprezentacja</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">90% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Szczegółowo &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- AI Travel Agent Logistyka - Koszty transportu ---
> Decision Layer dla podróży logistycznych. Wykrywanie krajów na podstawie GPS, zgodność z Pakietem mobilności UE, tryb Zero-Touch.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/pl/dlaczego-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Każda decyzja możliwa do prześledzenia</p>
</div>
</a>
<a href="/pl/dlaczego-gosign/#infrastruktura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Twoja infrastruktura</p>
<p class="text-xs text-gosign-text-light">Bez SaaS. Bez vendor-lock-in.</p>
</div>
</a>
<a href="/pl/dlaczego-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Bez ryzyka US-cloud</p>
</div>
</a>
</div>
</div>
</div>

<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Travel Decision Layer Branże">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/pl/uslugi/travel-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Travel Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/pl/uslugi/travel-decision-layer/lotnictwo/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Lotnictwo</a>
<a href="/pl/uslugi/travel-decision-layer/doradztwo/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Doradztwo</a>
<a href="/pl/uslugi/travel-decision-layer/logistyka/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Logistyka</a>
<a href="/pl/uslugi/travel-decision-layer/sprzedaz/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Sprzedaż</a>
</div>
</div>
</nav>

<!-- Dlaczego logistyka jest unikalna -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<!-- Kluczowe wskaźniki jako wizualne wprowadzenie -->
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">500 000+</span>
<p class="text-small text-gosign-text-light mt-1">Operacji/rok (symulacja)</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">95%</span>
<p class="text-small text-gosign-text-light mt-1">Wskaźnik Zero-Touch</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">30+</span>
<p class="text-small text-gosign-text-light mt-1">Jurysdykcji EU/EFTA</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-border"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">Wysoka złożoność reguł</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">Operacje i Zero-Touch: model symulacyjny Gosign. Jurysdykcje: pokrycie EU/EFTA. Pakiet mobilności UE: Dyrektywa 2020/1057.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Co Agent klasyfikuje</p>
<h2 class="text-h1 font-bold text-gosign-dark">30+ jurysdykcji, jeden Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Przejazdy transgraniczne, Pakiet mobilności UE, diety flotowe - każda trasa generuje dziesiątki decyzji podatkowych. Znacie tę złożoność. Tak ją rozwiązuje AI Agent:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Przypisanie kraju na podstawie GPS</h3>
<p class="text-body text-gosign-text mt-2">Kierowcy wielokrotnie dziennie przekraczają granice. AI Agent czyta dane GPS z systemów telematycznych i klasyfikuje przypisanie kraju oraz czas pobytu automatycznie. Silnik reguł oblicza diety krajowe deterministycznie - bez jednego formularza, bez jednego ręcznego wpisu.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Pakiet mobilności UE automatycznie udokumentowany</h3>
<p class="text-body text-gosign-text mt-2">Dyrektywa 2020/1057 wymaga dokumentacji delegowania przy operacjach transgranicznych. AI Agent klasyfikuje kraj operacji i czas trwania z danych telematycznych. Silnik reguł generuje bazę danych dla zespołów compliance do zgłoszeń do PIP i ITD. Bez dodatkowego obciążenia kierowców.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Spójność w całej flocie</h3>
<p class="text-body text-gosign-text mt-2">500 ciężarówek dziennie pokonuje te same granice. AI Agent stosuje identyczne reguły do identycznych tras. Silnik reguł eliminuje warianty zależne od osoby. Każde obliczenie diety spójne w całej flocie, każde gotowe na audyt.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Tryb zero-touch dla kierowcy</h3>
<p class="text-body text-gosign-text mt-2">Zadaniem kierowcy jest jazda, nie administracja. AI Agent przetwarza dane GPS automatycznie: dane wchodzą, obliczenie diet wychodzi, eksport do kadr gotowy. Zapytania zwrotne tylko przy prawdziwych wyjątkach. 95% spraw bez interakcji ludzkiej.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Sekundowa precyzja przekraczania granic</h3>
<p class="text-body text-gosign-text mt-2">Ciężarówka przekracza o 23:45 granicę niemiecko-polską. Dieta zmienia się o północy. O 00:15 jedzie dalej do Czech - trzy kraje za jeden dzień pracy. AI Agent klasyfikuje każde przekroczenie granicy z precyzją do sekundy. Silnik reguł oblicza proporcjonalne diety deterministycznie.</p>
</div>
</div>
</div>
</section>

<!-- Decision Flow -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Jedna trasa kierowcy. 15 do 40 mikro-decyzji.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Kierowca jedzie trasę przez trzy kraje z noclegiem. Decision Layer rozkłada tę trasę na poszczególne kroki decyzyjne:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Krok</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Decyzja</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Decydent</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Uzasadnienie</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Odczyt śladu GPS z telematyki</td><td class="py-3 px-4">Automatyczny</td><td class="py-3 px-4">Import danych, brak decyzji</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Określenie sekwencji krajów i czasu trwania</td><td class="py-3 px-4">Silnik reguł</td><td class="py-3 px-4">Współrzędne GPS zmapowane na jurysdykcje</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Wybór diety na kraj</td><td class="py-3 px-4">Silnik reguł</td><td class="py-3 px-4">Diety krajowe i zagraniczne wg Rozporządzenia Ministra Pracy</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Obliczenie północnego przekroczenia granicy</td><td class="py-3 px-4">Silnik reguł</td><td class="py-3 px-4">Proporcjonalne obliczenie przy przekroczeniu granicy o północy</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Sprawdzenie progu długookresowego delegowania</td><td class="py-3 px-4">Silnik reguł</td><td class="py-3 px-4">Progi czasowe na jurysdykcję</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Wygenerowanie danych Pakietu mobilności UE</td><td class="py-3 px-4">Automatyczny</td><td class="py-3 px-4">Dokumentacja delegowania pracowników jako baza danych</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Przypisanie centrum kosztów floty</td><td class="py-3 px-4">Silnik reguł</td><td class="py-3 px-4">Pojazd do floty, flota do centrum kosztów</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">Wygenerowanie eksportu do kadr</td><td class="py-3 px-4">Automatyczny</td><td class="py-3 px-4">Gotowe do zaksięgowania dane o dietach</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Sprawdzenie zgodności czasu odpoczynku</td><td class="py-3 px-4">Silnik reguł</td><td class="py-3 px-4">Czas jazdy i odpoczynku wg Rozporządzenia UE 561/2006</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Wygenerowanie akta audytowego</td><td class="py-3 px-4">Automatyczny</td><td class="py-3 px-4">Zapieczętowana akta decyzyjna dla każdej trasy kierowcy</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Wyniki symulacji -->
<section id="simulation" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Symulacja</p>
<h2 class="text-h1 font-bold text-white">Przeliczone dla wolumenów logistycznych</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Skonfigurowaliśmy Travel Decision Layer z realistycznymi parametrami logistycznymi i przeliczyliśmy. Wyniki pokazują, co zmienia się przy wielkościach flot klasy Enterprise.</p>

<!-- Tabela parametrów -->
<h3 class="text-h3 font-bold text-white mt-10 mb-4">Parametry symulacji</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Flota</td><td class="py-3 px-4">200 do 2 000+ pojazdów (własnych i podwykonawczych)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Kierowcy</td><td class="py-3 px-4">300 do 3 000+ (z różnymi modelami umów)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Operacji/rok</td><td class="py-3 px-4">500 000 do 2 000 000+</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Jurysdykcje</td><td class="py-3 px-4">30+ jurysdykcji EU/EFTA</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Integracja systemowa</td><td class="py-3 px-4">Telematyka &rarr; Decision Layer &rarr; ERP/Payroll</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Przekroczenia granic/dzień</td><td class="py-3 px-4">500 do 5 000+ (zależne od floty)</td></tr>
</tbody>
</table>
</div>

<!-- Porównanie wyników -->
<h3 class="text-h3 font-bold text-white mt-10 mb-4">Przed / Po</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th class="text-left py-3 px-4 font-semibold text-white">Wymiar</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Ręcznie</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Koszt przetwarzania</td><td class="py-3 px-4">od EUR 53 (GBTA)*</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; EUR 5</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Wskaźnik błędów</td><td class="py-3 px-4">19% (GBTA)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 0,1%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Czas realizacji</td><td class="py-3 px-4">5 - 12 dni roboczych</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Minuty</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Wskaźnik Zero-Touch</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">95%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Gotowość na audyt</td><td class="py-3 px-4">Ręcznie rekonstruowane</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatycznie generowane</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Dane Pakietu mobilności UE</td><td class="py-3 px-4">Ręcznie wprowadzane</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatycznie generowane</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Zapytania zwrotne kierowców</td><td class="py-3 px-4">3 - 5 na tydzień</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 0,1 na tydzień</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">* GBTA Foundation 2024: USD 58 za transakcję (ok. EUR 53). Operacje logistyczne z wykrywaniem krajów na podstawie GPS są w trybie Zero-Touch znacząco tańsze. Pakiet mobilności UE: Dyrektywa 2020/1057. Wyniki symulacji: model obliczeniowy Gosign.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">W symulacji Decision Layer osiąga wskaźnik Zero-Touch na poziomie 95% - przy standardowych trasach z pokryciem GPS. Pozostałe 5% dotyczy luk GPS, nowych tras i przypadków specjalnych. Dla wszystkich przypadków dostępna jest kompletna, gotowa na audyt akta decyzyjna. Kierowcy nie muszą wypełniać żadnych formularzy.</p>
</div>
</section>

<!-- Referencja architektoniczna -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Architektura i implementacja</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">Travel Decision Layer działa w pełni w Twojej infrastrukturze: Twoje centrum danych, Twoja sieć, Twoja kontrola. Bez zależności od SaaS, bez odpływu danych. Dla konfiguracji logistycznych oznacza to: interfejsy telematyczne do importu danych GPS, przetwarzanie przekroczeń granic w czasie rzeczywistym oraz flotowe obliczanie diet w ponad 30 jurysdykcjach EU/EFTA. Typowe projekty pilotażowe rozpoczynają się w ciągu 3 miesięcy z jedną grupą floty i najczęściej pokonywanymi trasami.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/pl/uslugi/travel-decision-layer/#implementation" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Architektura, implementacja i dźwignia szczegółowo &rarr;</a>
<a href="/pl/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Architektura Decision Layer &rarr;</a>
<a href="/pl/uslugi/infrastruktura/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infrastruktura szczegółowo &rarr;</a>
<a href="/pl/governance/co-determination/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Konsultacja &amp; Rada Zakładowa &rarr;</a>
<a href="/pl/governance/cert-ready/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready by Design &rarr;</a>
</div>
</div>
</section>

<!-- Pogłębienie -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Pogłębienie w Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nasza seria artykułów fachowych dla decydentów wdrażających agentów AI.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/pl/magazyn/decision-layer-wyjasnienie/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Podstawy</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - czym jest i dlaczego każdy agent AI go potrzebuje?</p>
</a>
<a href="/pl/magazyn/rada-zakladowa-ai-mitbestimmung/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Konsultacja</p>
<p class="text-body font-semibold text-gosign-dark">Rada Zakładowa a AI, Konsultacja jako Constraint Architektury</p>
</a>
<a href="/pl/magazyn/cert-ready-by-design/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Audyt</p>
<p class="text-body font-semibold text-gosign-dark">Cert-Ready by Design - AI gotowe do audytu od startu</p>
</a>
</div>
</div>
</section>

<!-- Inne branże -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Travel Decision Layer w innych branżach</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Każda branża ma własne taryfy, struktury kosztów i czynniki złożoności. Decision Layer jest ten sam. Konfiguracja jest branżowa.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/pl/uslugi/travel-decision-layer/lotnictwo/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Lotnictwo</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">Załogi, układy zbiorowe, IROP, multi-jurysdykcja</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">95% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Szczegółowo &rarr;</span>
</div>
</a>
<a href="/pl/uslugi/travel-decision-layer/doradztwo/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Doradztwo</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">Podział klientów, multi-centrum kosztów, polityka</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">85% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Szczegółowo &rarr;</span>
</div>
</a>
<a href="/pl/uslugi/travel-decision-layer/sprzedaz/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Sprzedaż</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">500 przedstawicieli, integracja CRM, reprezentacja</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">90% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Szczegółowo &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- AI Travel Agent Lotnictwo - Koszty podróży załogi ---
> Decision Layer dla podróży załóg lotniczych. Rozliczanie oparte na rotacjach, diety wg układów zbiorowych, zmienne stawki krajowe.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/pl/dlaczego-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Każda decyzja możliwa do prześledzenia</p>
</div>
</a>
<a href="/pl/dlaczego-gosign/#infrastruktura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Twoja infrastruktura</p>
<p class="text-xs text-gosign-text-light">Bez SaaS. Bez vendor-lock-in.</p>
</div>
</a>
<a href="/pl/dlaczego-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Bez ryzyka US-cloud</p>
</div>
</a>
</div>
</div>
</div>

<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Travel Decision Layer Branże">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/pl/uslugi/travel-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Travel Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/pl/uslugi/travel-decision-layer/lotnictwo/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Lotnictwo</a>
<a href="/pl/uslugi/travel-decision-layer/doradztwo/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Doradztwo</a>
<a href="/pl/uslugi/travel-decision-layer/logistyka/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Logistyka</a>
<a href="/pl/uslugi/travel-decision-layer/sprzedaz/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Sprzedaż</a>
</div>
</div>
</nav>

<!-- Dlaczego lotnictwo ma najwyższą złożoność -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<!-- Wskaźniki symulacji jako wizualne wprowadzenie -->
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">100 000+</span>
<p class="text-small text-gosign-text-light mt-1">Przypadków/rok (symulacja)</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">95%</span>
<p class="text-small text-gosign-text-light mt-1">Wskaźnik Zero-Touch</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">10 - 20%</span>
<p class="text-small text-gosign-text-light mt-1">Wskaźnik IROP (standard branżowy)</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">Najwyższa złożoność reguł</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">Przypadki i Zero-Touch: model symulacyjny Gosign. Wskaźnik IROP: EUROCONTROL / US DOT BTS, 2024.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Co Agent klasyfikuje</p>
<h2 class="text-h1 font-bold text-gosign-dark">Trzy grupy personelu, jeden Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Kokpit, kabina, obsługa naziemna - każda grupa z własną taryfą, dietami, złożonością. Znacie tę złożoność. Tak ją rozwiązuje AI Agent:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Setki rotacji dziennie</h3>
<p class="text-body text-gosign-text mt-2">Każda rotacja generuje zdarzenie podatkowe. AI Agent czyta plany dyspozycji automatycznie, klasyfikuje grupę personelu i typ rotacji oraz przypisuje prawidłowy układ zbiorowy. Przy setkach rotacji dziennie Agent rozpoznaje zmiany lokalizacji i granice taryfowe niezawodniej niż jakiekolwiek ręczne wprowadzanie danych.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Trzy do pięciu krajów na dzień służbowy</h3>
<p class="text-body text-gosign-text mt-2">Rotacja obejmuje wiele jurysdykcji w jednym dniu. AI Agent klasyfikuje przypisanie kraju i czas pobytu z planu dyspozycji. Silnik reguł oblicza diety krajowe deterministycznie - pełna lub obniżona stawka, proporcjonalnie wg czasu pobytu.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Nadpisanie taryfy na grupę personelu</h3>
<p class="text-body text-gosign-text mt-2">Kokpit, kabina i obsługa naziemna mają różne układy zbiorowe, które nadpisują stawki ustawowe. AI Agent klasyfikuje grupę personelu i automatycznie wybiera prawidłowy układ taryfowy. Silnik reguł oblicza nadpisanie deterministycznie. Ta sama rotacja, trzy różne wyniki - spójnie dla wszystkich spraw.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Zmienność IROP w czasie rzeczywistym</h3>
<p class="text-body text-gosign-text mt-2">10-20% wszystkich rotacji odbiega od planu. AI Agent klasyfikuje typ IROP (opóźnienie, przekierowanie, repozycjonowanie) i przypisuje skutki podatkowe. Silnik reguł oblicza skorygowane diety na podstawie faktycznej rotacji. Audit Trail dokumentuje zarówno plan pierwotny, jak i faktyczne wykonanie.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Governance wolumenu bez próbkowania</h3>
<p class="text-body text-gosign-text mt-2">Tysiące identycznych spraw dziennie. AI Agent sprawdza 100% przypadków względem tego samego silnika reguł. Bez próbkowania, bez zmienności zależnej od osoby. Każdy błąd systematyczny jest wykrywany natychmiast, a nie dopiero przy kwartalnym uzgadnianiu.</p>
</div>
</div>
</div>
</section>

<!-- Decision Flow -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Jedna rotacja. 40 do 120 mikro-decyzji.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Członek załogi leci trzydniową rotację z layoverem. Decision Layer rozkłada ją na poszczególne kroki decyzyjne:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Krok</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Decyzja</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Decydent</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Uzasadnienie</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Odczyt rotacji z planu dyspozycji</td><td class="py-3 px-4">Automatyczny</td><td class="py-3 px-4">Import danych, brak decyzji</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Określenie sekwencji krajów</td><td class="py-3 px-4">Silnik reguł</td><td class="py-3 px-4">GPS lub plan: jakie kraje, jaki czas trwania</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Wybór diety na kraj</td><td class="py-3 px-4">Silnik reguł</td><td class="py-3 px-4">Diety krajowe i zagraniczne wg Rozporządzenia Ministra Pracy</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Sprawdzenie nadpisania z układu zbiorowego</td><td class="py-3 px-4">Silnik reguł</td><td class="py-3 px-4">Układ zbiorowy załogowy nadpisuje stawki ustawowe</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Obliczenie potrącenia za posiłki</td><td class="py-3 px-4">Silnik reguł</td><td class="py-3 px-4">Zapewnione posiłki obniżają dietę deterministycznie</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Klasyfikacja IROP</td><td class="py-3 px-4">AI</td><td class="py-3 px-4">Opóźnienie, przekierowanie, repozycjonowanie: AI klasyfikuje typ</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Przeliczenie skutków IROP</td><td class="py-3 px-4">Silnik reguł</td><td class="py-3 px-4">Zmieniony czas lub kraj: dieta obliczona ponownie</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">Weryfikacja hotelu layoverowego</td><td class="py-3 px-4">AI + Silnik reguł</td><td class="py-3 px-4">AI ekstrahuje dane hotelowe, silnik reguł sprawdza zgodność z polityką</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Przypisanie centrum kosztów</td><td class="py-3 px-4">Silnik reguł</td><td class="py-3 px-4">Rotacja do floty, flota do centrum kosztów</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Wygenerowanie akta audytowego</td><td class="py-3 px-4">Automatyczny</td><td class="py-3 px-4">Zaplombowana akta decyzyjna na rotację</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Wyniki symulacji -->
<section id="simulation" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Symulacja</p>
<h2 class="text-h1 font-bold text-white">Przeliczone dla wolumenów lotniczych</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Skonfigurowaliśmy Travel Decision Layer z realistycznymi parametrami lotniczymi i przeliczyliśmy wyniki. Rezultaty pokazują, co zmienia się przy wolumenach enterprise.</p>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Parametry symulacji</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Członkowie załogi</td><td class="py-3 px-4">10 000 do 50 000+ (wiele grup personelu z odrębnymi układami zbiorowymi)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Układy zbiorowe</td><td class="py-3 px-4">2 do 5 równolegle (na grupę personelu i przewoźnika)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Przypadki/rok</td><td class="py-3 px-4">100 000 do 1 000 000+</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Jurysdykcje</td><td class="py-3 px-4">Multi-jurysdykcja (kraje UE, w tym Polska)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Integracja systemów</td><td class="py-3 px-4">Planowanie załóg &rarr; Decision Layer &rarr; ERP/Payroll</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Wskaźnik IROP</td><td class="py-3 px-4">10 - 20% wszystkich rotacji z odchyleniem od planu (standard branżowy)</td></tr>
</tbody>
</table>
</div>

<h3 class="text-h3 font-bold text-white mt-10 mb-4">Przed / Po</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th class="text-left py-3 px-4 font-semibold text-white">Wymiar</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Ręcznie</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Koszt przetwarzania</td><td class="py-3 px-4">od EUR 53 (GBTA)*</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; EUR 9</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Wskaźnik błędów</td><td class="py-3 px-4">19% (GBTA)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 0,3%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Czas realizacji</td><td class="py-3 px-4">5 - 12 dni roboczych</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Minuty</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Wskaźnik Zero-Touch</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">95%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Gotowość na audyt</td><td class="py-3 px-4">Ręcznie rekonstruowane</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Automatycznie generowane</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Zmiana układu zbiorowego</td><td class="py-3 px-4">Tygodnie</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 24h</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Korekta wsteczna</td><td class="py-3 px-4">Ręczne nadpisanie</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Storno + korekta (append-only)</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">* GBTA Foundation 2024: USD 58 za transakcję (ok. EUR 53). Sprawy załogowe z logiką układów zbiorowych, multi-jurysdykcją i obsługą IROP leżą branżowo wyżej. Wskaźnik IROP: EUROCONTROL Annual Report, 2024. Wyniki symulacji: model obliczeniowy Gosign.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">W symulacji Decision Layer osiąga wskaźnik Zero-Touch 95% - niezależnie od tego, czy przetwarzanych jest 100 000 czy 1 000 000 spraw rocznie. Tylko 5% wymaga uwagi ludzkiej. Dla pozostałych 95% dostępna jest kompletna, gotowa na audyt akta decyzyjna. Korekty i zmiany układów zbiorowych generują zapisy stornujące i korygujące - żadnych nadpisań, pełna historia księgowań.</p>
</div>
</section>

<!-- Referencja architektoniczna -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Architektura i implementacja</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">Travel Decision Layer działa w całości w Twojej infrastrukturze: Twoje centrum danych, Twoja sieć, Twoja kontrola. Bez zależności SaaS, bez wycieku danych. Dla lotnictwa oznacza to: integrację z systemami planowania załóg, przetwarzanie danych rotacji w czasie rzeczywistym, zestawy reguł specyficzne dla układów zbiorowych poszczególnych grup personelu i ciągły Audit Trail do SAP FI/CO. Typowe projekty pilotażowe rozpoczynają się w ciągu 3 miesięcy z jedną grupą załogi i jednym układem zbiorowym.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/pl/uslugi/travel-decision-layer/#implementation" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Architektura, implementacja i dźwignia szczegółowo &rarr;</a>
<a href="/pl/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Architektura Decision Layer &rarr;</a>
<a href="/pl/uslugi/infrastruktura/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infrastruktura szczegółowo &rarr;</a>
<a href="/pl/governance/co-determination/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Konsultacja z Radą Zakładową &rarr;</a>
<a href="/pl/governance/cert-ready/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready by Design &rarr;</a>
</div>
</div>
</section>

<!-- Pogłębienie -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Pogłębienie w Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nasza seria artykułów fachowych dla decydentów wdrażających agentów AI.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/pl/magazyn/decision-layer-wyjasnienie/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Podstawy</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - czym jest i dlaczego każdy agent AI go potrzebuje?</p>
</a>
<a href="/pl/magazyn/rada-zakladowa-ai-mitbestimmung/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Konsultacja</p>
<p class="text-body font-semibold text-gosign-dark">Rada Zakładowa a AI, Konsultacja jako Constraint Architektury</p>
</a>
<a href="/pl/magazyn/eu-ai-act-hr/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Regulacja</p>
<p class="text-body font-semibold text-gosign-dark">EU AI Act i HR - co jest teraz obowiązkowe</p>
</a>
</div>
</div>
</section>

<!-- Inne branże -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Travel Decision Layer w innych branżach</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Każda branża ma własne taryfy, struktury kosztów i czynniki złożoności. Decision Layer jest ten sam. Konfiguracja jest branżowa.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/pl/uslugi/travel-decision-layer/doradztwo/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Doradztwo</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">Podział klientów, multi-centrum kosztów, polityka</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">85% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Szczegółowo &rarr;</span>
</div>
</a>
<a href="/pl/uslugi/travel-decision-layer/logistyka/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Logistyka</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">GPS, Pakiet mobilności UE, Zero-Touch kierowca</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">95% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Szczegółowo &rarr;</span>
</div>
</a>
<a href="/pl/uslugi/travel-decision-layer/sprzedaz/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Sprzedaż</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">500 przedstawicieli, integracja CRM, reprezentacja</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">90% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Szczegółowo &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- AI Travel Agent Sprzedaż - Koszty przedstawicieli ---
> Decision Layer dla podróży sprzedażowych. Integracja CRM, egzekwowanie polityk przy 10 000+ przypadkach/miesiąc, rozliczenie tygodniowe.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/pl/dlaczego-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Każda decyzja możliwa do prześledzenia</p>
</div>
</a>
<a href="/pl/dlaczego-gosign/#infrastruktura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Twoja infrastruktura</p>
<p class="text-xs text-gosign-text-light">Bez SaaS. Bez vendor-lock-in.</p>
</div>
</a>
<a href="/pl/dlaczego-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Bez ryzyka US-cloud</p>
</div>
</a>
</div>
</div>
</div>

<!-- Branch Context Bar -->
<nav class="bg-gosign-light border-b border-gosign-border" aria-label="Travel Decision Layer Branże">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="flex items-center gap-6 py-3 overflow-x-auto text-small">
<a href="/pl/uslugi/travel-decision-layer/" class="flex items-center gap-1.5 text-gosign-accent-text font-semibold whitespace-nowrap hover:text-gosign-accent-hover transition-colors">
<svg class="w-4 h-4" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M10 19l-7-7m0 0l7-7m-7 7h18" /></svg>
Travel Decision Layer
</a>
<span class="text-gosign-border" aria-hidden="true">|</span>
<a href="/pl/uslugi/travel-decision-layer/lotnictwo/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Lotnictwo</a>
<a href="/pl/uslugi/travel-decision-layer/doradztwo/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Doradztwo</a>
<a href="/pl/uslugi/travel-decision-layer/logistyka/" class="whitespace-nowrap pb-1 border-b-2 border-transparent text-gosign-text-light hover:text-gosign-accent-text transition-colors">Logistyka</a>
<a href="/pl/uslugi/travel-decision-layer/sprzedaz/" class="whitespace-nowrap pb-1 border-b-2 border-gosign-accent text-gosign-dark font-semibold" aria-current="page">Sprzedaż</a>
</div>
</div>
</nav>

<!-- Dlaczego wolumen sprzedaży wymaga governance -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<!-- Kluczowe wskaźniki jako wizualne wprowadzenie -->
<div class="grid grid-cols-2 sm:grid-cols-4 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">120 000+</span>
<p class="text-small text-gosign-text-light mt-1">Spraw/rok (symulacja)</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">90%</span>
<p class="text-small text-gosign-text-light mt-1">Wskaźnik Zero-Touch</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">100%</span>
<p class="text-small text-gosign-text-light mt-1">Weryfikacja polityk (zamiast losowej)</p>
</div>
<div>
<div class="flex gap-1 mt-2">
<span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-accent"></span><span class="w-4 h-2 rounded-sm bg-gosign-border"></span><span class="w-4 h-2 rounded-sm bg-gosign-border"></span>
</div>
<p class="text-small text-gosign-text-light mt-1">Średnia złożoność reguł, wysoki wolumen</p>
</div>
<p class="col-span-2 sm:col-span-4 text-xs text-gosign-text-light">Sprawy i Zero-Touch: model symulacyjny Gosign. Weryfikacja polityk: Decision Layer weryfikuje 100% spraw. Branżowe benchmarki: GBTA Foundation, 2015.</p>
</div>

<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Co Agent klasyfikuje</p>
<h2 class="text-h1 font-bold text-gosign-dark">10 000 transakcji/miesiąc, jeden Agent</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">500 przedstawicieli, 20 spraw miesięcznie, 10 000 transakcji. Audyt wyrywkowy sprawdza 5%. AI Agent sprawdza 100%. Tak to działa:</p>

<div class="space-y-8 mt-10 max-w-narrow">
<div>
<h3 class="text-h3 font-bold text-gosign-dark">100% kontroli polityki zamiast 5% próbki</h3>
<p class="text-body text-gosign-text mt-2">500 przedstawicieli, 20 rozliczeń miesięcznie. AI Agent sprawdza każdą pojedynczą transakcję względem kompletnego zestawu reguł polityki. Silnik reguł egzekwuje limity, kategorie i progi deterministycznie. Każde systematyczne naruszenie wykryte natychmiast, nie dopiero przy kwartalnym audycie.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Automatyczne powiązanie z CRM</h3>
<p class="text-body text-gosign-text mt-2">Każda wizyta u klienta ma cel biznesowy. AI Agent łączy dane CRM z kosztami podróży automatycznie: klient, szansa sprzedażowa, przypisanie przychodowe. Silnik reguł przypisuje centrum kosztów deterministycznie. Bez ręcznego wpisu, bez brakującego celu biznesowego.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Rozliczenie tygodniowe zamiast pojedynczych transakcji</h3>
<p class="text-body text-gosign-text mt-2">Pracownicy terenowi preferują jedno rozliczenie na tydzień. AI Agent agreguje wszystkie podróże tygodnia, klasyfikuje typy dokumentów i przypisania. Silnik reguł oblicza diety, kilometrówki i podziały kosztów. Jedno rozliczenie tygodniowe na pracownika, gotowe do zaksięgowania.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Koszty reprezentacji według jurysdykcji</h3>
<p class="text-body text-gosign-text mt-2">Posiłek biznesowy z klientem w Polsce: koszty reprezentacji nieodliczalne od CIT. W Niemczech: 70% odliczalne. W Austrii: 50%. AI Agent klasyfikuje typ wydatku, jurysdykcję i liczbę uczestników. Silnik reguł stosuje prawidłową stawkę odliczenia deterministycznie.</p>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark">Zamknięcie kwartału w minuty</h3>
<p class="text-body text-gosign-text mt-2">10 000 spraw miesięcznie, każda z kompletnym Audit Trail. AI Agent generuje zagregowane raporty na region, zespół i kategorię wydatku automatycznie. Zamknięcie kwartału to eksport, nie projekt badawczy. Kontrola skarbowa to minuta, nie tydzień.</p>
</div>
</div>
</div>
</section>

<!-- Decision Flow -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Jeden tydzień sprzedażowy. Od 30 do 80 mikro-decyzji.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Pracownik terenowy odwiedza pięciu klientów w ciągu tygodnia z noclegami w hotelach i posiłkami biznesowymi. Decision Layer rozkłada ten tydzień na pojedyncze kroki decyzyjne:</p>

<div class="overflow-x-auto mt-10">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Krok</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Decyzja</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Decydent</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Uzasadnienie</th>
</tr>
</thead>
<tbody class="text-gosign-text">
<tr class="border-b border-gosign-border"><td class="py-3 px-4">1</td><td class="py-3 px-4">Powiązanie podróży z szansą CRM</td><td class="py-3 px-4">Silnik reguł</td><td class="py-3 px-4">Dopasowanie kalendarza i danych CRM</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">2</td><td class="py-3 px-4">Określenie diety</td><td class="py-3 px-4">Silnik reguł</td><td class="py-3 px-4">Na podstawie kraju i czasu trwania</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">3</td><td class="py-3 px-4">Obliczenie kilometrówki</td><td class="py-3 px-4">Silnik reguł</td><td class="py-3 px-4">Dystans, typ pojazdu, stawka</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">4</td><td class="py-3 px-4">Sprawdzenie polityki reprezentacyjnej</td><td class="py-3 px-4">Silnik reguł</td><td class="py-3 px-4">Kwota, uczestnicy, cel</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">5</td><td class="py-3 px-4">Sprawdzenie polityki hotelowej</td><td class="py-3 px-4">Silnik reguł</td><td class="py-3 px-4">Limit cenowy wg kategorii miasta</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">6</td><td class="py-3 px-4">Agregacja do rozliczenia tygodniowego</td><td class="py-3 px-4">Automatyczny</td><td class="py-3 px-4">Wszystkie podróże tygodnia zagregowane</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">7</td><td class="py-3 px-4">Przypisanie centrum kosztów i szansy</td><td class="py-3 px-4">Silnik reguł</td><td class="py-3 px-4">Klient, projekt, przypisanie przychodowe</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">8</td><td class="py-3 px-4">Wygenerowanie eksportu do kadr</td><td class="py-3 px-4">Automatyczny</td><td class="py-3 px-4">Rozliczenie tygodniowe jako księgowanie</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">9</td><td class="py-3 px-4">Klasyfikacja wydatków reprezentacyjnych</td><td class="py-3 px-4">AI + Silnik reguł</td><td class="py-3 px-4">AI rozpoznaje typ rachunku i uczestników, silnik reguł stosuje stawki odliczeń</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4">10</td><td class="py-3 px-4">Generowanie akty audytowej</td><td class="py-3 px-4">Automatyczny</td><td class="py-3 px-4">Zapieczętowana akta decyzyjna per tydzień sprzedażowy</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Wyniki symulacji -->
<section id="simulation" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Symulacja</p>
<h2 class="text-h1 font-bold text-white">Przeliczone dla wolumenów sprzedażowych</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Skonfigurowaliśmy Travel Decision Layer z realistycznymi parametrami sprzedaży i przeliczyliśmy wyniki. Rezultaty pokazują, co zmienia się przy wolumenach Enterprise w sprzedaży terenowej.</p>

<!-- Tabela parametrów -->
<h3 class="text-h3 font-bold text-white mt-10 mb-4">Parametry symulacji</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Pracownicy terenowi</td><td class="py-3 px-4">200 do 2 000+ (wg regionu i hierarchii)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Spraw/miesiąc</td><td class="py-3 px-4">10 000 do 50 000+</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Jurysdykcje</td><td class="py-3 px-4">Multi-jurysdykcja (PL, DE, CZ, inne kraje UE)</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Integracja systemowa</td><td class="py-3 px-4">CRM &rarr; Decision Layer &rarr; ERP/Payroll</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Udział wydatków reprezentacyjnych</td><td class="py-3 px-4">20 - 30% wszystkich spraw zawiera rachunki reprezentacyjne</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 font-semibold text-white">Polityki</td><td class="py-3 px-4">3 - 10 równoległych (wg regionu, hierarchii, klasy klienta)</td></tr>
</tbody>
</table>
</div>

<!-- Porównanie wyników -->
<h3 class="text-h3 font-bold text-white mt-10 mb-4">Przed / Po</h3>
<div class="overflow-x-auto">
<table class="w-full text-small">
<thead>
<tr class="border-b-2 border-white/20">
<th class="text-left py-3 px-4 font-semibold text-white">Wymiar</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-text-on-dark/60">Manualnie</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-accent-on-dark">Decision Layer</th>
</tr>
</thead>
<tbody class="text-gosign-text-on-dark/80">
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Koszt przetwarzania</td><td class="py-3 px-4">od EUR 53 (GBTA)*</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; EUR 7</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Wskaźnik błędów</td><td class="py-3 px-4">19% (GBTA)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">&lt; 0,5%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Czas realizacji</td><td class="py-3 px-4">5 - 12 dni roboczych</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Minuty</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Wskaźnik Zero-Touch</td><td class="py-3 px-4">0%</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">90%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Gotowość audytowa</td><td class="py-3 px-4">Rekonstruowana ręcznie</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Generowana automatycznie</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Weryfikacja polityk</td><td class="py-3 px-4">5 - 10% (wyrywkowo)</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">100%</td></tr>
<tr class="border-b border-white/10"><td class="py-3 px-4 text-white">Rozliczenie tygodniowe</td><td class="py-3 px-4">Kompilowane ręcznie</td><td class="py-3 px-4 text-gosign-accent-on-dark font-semibold">Agregowane automatycznie</td></tr>
</tbody>
</table>
</div>

<p class="text-xs text-gosign-text-on-dark/70 mt-4">* GBTA Foundation 2024: USD 58 za transakcję (ok. EUR 53). Sprawy sprzedażowe z integracją CRM i agregacją tygodniową są w trybie Zero-Touch znacząco tańsze. Wyniki symulacji: model obliczeniowy Gosign.</p>

<p class="text-body-lg text-white mt-8 max-w-narrow font-semibold">W symulacji Decision Layer osiąga wskaźnik Zero-Touch na poziomie 90% - w przypadkach standardowych z jednoznacznym powiązaniem CRM. Pozostałe 10% dotyczy wyjątkowych przypadków reprezentacyjnych i brakujących wpisów CRM, wymagających oceny ludzkiej. Dla wszystkich spraw dostępna jest kompletna, gotowa do audytu akta decyzyjna. Rozliczenia tygodniowe zastępują cykl rozliczeń pojedynczych.</p>
</div>
</section>

<!-- Referencja architektoniczna -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Architektura i implementacja</h2>
<p class="text-body-lg text-gosign-text mt-4 max-w-narrow">Travel Decision Layer działa w pełni w Twojej infrastrukturze: Twoje centrum danych, Twoja sieć, Twoja kontrola. Bez zależności SaaS, bez wycieku danych. Dla konfiguracji sprzedażowych oznacza to: interfejsy CRM do automatycznego łączenia podróży z klientami, przetwarzanie wolumenowe ponad 10 000 transakcji miesięcznie oraz logikę rozliczeń tygodniowych. Typowe projekty pilotażowe rozpoczynają się w ciągu 3 miesięcy z jednym regionem sprzedażowym.</p>
<div class="flex flex-wrap gap-4 mt-6">
<a href="/pl/uslugi/travel-decision-layer/#implementation" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Architektura, implementacja i dźwignia szczegółowo &rarr;</a>
<a href="/pl/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Architektura Decision Layer &rarr;</a>
<a href="/pl/uslugi/infrastruktura/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infrastruktura szczegółowo &rarr;</a>
<a href="/pl/governance/co-determination/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Współdecydowanie &amp; Rada Zakładowa &rarr;</a>
<a href="/pl/governance/cert-ready/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready by Design &rarr;</a>
</div>
</div>
</section>

<!-- Pogłębienie -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Pogłębienie w Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nasza seria artykułów fachowych dla decydentów wdrażających agentów AI.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/pl/magazyn/decision-layer-wyjasnienie/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Podstawy</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - czym jest i dlaczego każdy agent AI go potrzebuje?</p>
</a>
<a href="/pl/magazyn/agent-governance-hr/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Agent Governance w HR - Dlaczego CHRO musi prowadzić ten temat</p>
</a>
<a href="/pl/magazyn/eu-ai-act-hr/" class="block bg-gosign-white border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Regulacja</p>
<p class="text-body font-semibold text-gosign-dark">EU AI Act i HR - co jest teraz obowiązkowe</p>
</a>
</div>
</div>
</section>

<!-- Inne branże -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark">Travel Decision Layer w innych branżach</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Każda branża ma własne taryfy, struktury kosztów i czynniki złożoności. Decision Layer jest ten sam. Konfiguracja jest branżowa.</p>

<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-10">
<a href="/pl/uslugi/travel-decision-layer/lotnictwo/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Lotnictwo</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div>
</div>
<p class="text-small text-gosign-text-light">Załogi, układy zbiorowe, IROP, multi-jurysdykcja</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">95% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Szczegółowo &rarr;</span>
</div>
</a>
<a href="/pl/uslugi/travel-decision-layer/doradztwo/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Doradztwo</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">Podział klientów, multi-centrum kosztów, polityka</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">85% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Szczegółowo &rarr;</span>
</div>
</a>
<a href="/pl/uslugi/travel-decision-layer/logistyka/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<div class="flex items-center justify-between mb-3">
<h3 class="text-h3 font-bold text-gosign-dark">Logistyka</h3>
<div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-border"></span></div>
</div>
<p class="text-small text-gosign-text-light">GPS, Pakiet mobilności UE, Zero-Touch kierowca</p>
<div class="mt-4 pt-4 border-t border-gosign-border flex items-center justify-between">
<span class="text-body font-bold text-gosign-accent-text">95% Zero-Touch</span>
<span class="text-small text-gosign-accent-text font-semibold">Szczegółowo &rarr;</span>
</div>
</a>
</div>
</div>
</section>

--- AI Travel Decision Layer - Governance kosztów podróży ---
> Decision Layer rozkłada każdą transakcję kosztów podróży na kroki decyzyjne. Oparty na regułach, audytowalny, 85-95% Zero-Touch.

<!-- USP Strip -->
<div class="bg-gosign-dark/5 border-y border-gosign-border">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8 py-4">
<div class="flex flex-col sm:flex-row sm:justify-evenly sm:items-center gap-6">
<a href="/pl/dlaczego-gosign/#eu-ai-act" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 12.75 11.25 15 15 9.75m-3-7.036A11.959 11.959 0 0 1 3.598 6 11.99 11.99 0 0 0 3 9.749c0 5.592 3.824 10.29 9 11.623 5.176-1.332 9-6.03 9-11.622 0-1.31-.21-2.571-.598-3.751h-.152c-3.196 0-6.1-1.248-8.25-3.285Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU AI Act ready</p>
<p class="text-xs text-gosign-text-light">Każda decyzja możliwa do prześledzenia</p>
</div>
</a>
<a href="/pl/dlaczego-gosign/#infrastruktura" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 21h19.5m-18-18v18m10.5-18v18m6-13.5V21M6.75 6.75h.75m-.75 3h.75m-.75 3h.75m3-6h.75m-.75 3h.75m-.75 3h.75M6.75 21v-3.375c0-.621.504-1.125 1.125-1.125h2.25c.621 0 1.125.504 1.125 1.125V21M3 3h12m-.75 4.5H21m-3.75 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Zm0 3h.008v.008h-.008v-.008Z" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">Twoja infrastruktura</p>
<p class="text-xs text-gosign-text-light">Bez SaaS. Bez vendor-lock-in.</p>
</div>
</a>
<a href="/pl/dlaczego-gosign/#eu-first" class="flex items-center gap-3 group/usp hover:opacity-80 transition-opacity">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M12 21a9.004 9.004 0 0 0 8.716-6.747M12 21a9.004 9.004 0 0 1-8.716-6.747M12 21c2.485 0 4.5-4.03 4.5-9S14.485 3 12 3m0 18c-2.485 0-4.5-4.03-4.5-9S9.515 3 12 3m0 0a8.997 8.997 0 0 1 7.843 4.582M12 3a8.997 8.997 0 0 0-7.843 4.582m15.686 0A11.953 11.953 0 0 1 12 10.5c-2.998 0-5.74-1.1-7.843-2.918m15.686 0A8.959 8.959 0 0 1 21 12c0 .778-.099 1.533-.284 2.253m0 0A17.919 17.919 0 0 1 12 16.5c-3.162 0-6.133-.815-8.716-2.247m0 0A9.015 9.015 0 0 1 3 12c0-1.605.42-3.113 1.157-4.418" /></svg>
<div>
<p class="text-sm font-semibold text-gosign-dark group-hover/usp:text-gosign-accent-on-dark transition-colors">EU-first</p>
<p class="text-xs text-gosign-text-light">Bez ryzyka US-cloud</p>
</div>
</a>
</div>
</div>
</div>

<!-- Problem -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mb-12 pb-10 border-b border-gosign-border">
<div>
<span class="text-h1 font-bold text-gosign-accent-text">EUR 53</span>
<p class="text-small text-gosign-text-light mt-1">za sprawę, ręczne przetwarzanie</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">19%</span>
<p class="text-small text-gosign-text-light mt-1">wskaźnik błędów w rozliczeniach podróży</p>
</div>
<div>
<span class="text-h1 font-bold text-gosign-accent-text">EUR 48</span>
<p class="text-small text-gosign-text-light mt-1">koszt korekty na błąd</p>
</div>
<p class="sm:col-span-3 text-xs text-gosign-text-light">GBTA Foundation 2024: USD 58 za transakcję (ok. EUR 53). Koszty korekty: USD 52 (ok. EUR 48).</p>
</div>
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Problem</p>
<h2 class="text-h1 font-bold text-gosign-dark">Dlaczego narzędzia do rozliczania wydatków zawodzą w złożonych organizacjach</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">SAP Concur, Circula, Moss, Spendesk. Wszystkie digitalizują ten sam ręczny proces: rejestracja rachunków, wypełnianie formularzy, uzyskiwanie zatwierdzeń. Przy EUR 53 za sprawę i 19% wskaźniku błędów wg GBTA to kosztowne. Ale w organizacjach z układami zbiorowymi, międzynarodowym personelem i dziesiątkami jurysdykcji podatkowych rejestracja nie jest problemem. Problemem jest decyzja.</p>
<div class="mt-10">
<div class="grid grid-cols-1 md:grid-cols-3 gap-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">EUR 53 za sprawę</h3>
<p class="text-body text-gosign-text-light mt-2">Narzędzia do wydatków digitalizują papierowe formularze. Pracownik wypełnia, przełożony zatwierdza, księgowość sprawdza. Trzy ręczne kroki, EUR 53 za sztukę (GBTA, 2024). Przy 100 000 spraw rocznie to EUR 5,3 mln samych kosztów przetwarzania.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">19% wskaźnik błędów</h3>
<p class="text-body text-gosign-text-light mt-2">Diety krajowe i zagraniczne, zasady księgowania, potrącenia za posiłki, nadpisania z układów zbiorowych, progi zwolnień podatkowych. Żaden pracownik nie zna wszystkich zasad. Żaden zatwierdzający ich nie sprawdza. Wynik: co piąta sprawa jest błędna. EUR 48 kosztów korekty na błąd (GBTA, 2024).</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Zero gotowości na audyt</h3>
<p class="text-body text-gosign-text-light mt-2">Gdy przychodzi kontrola PIP lub skarbowa, brakuje dowodu: jaka reguła została zastosowana? Dlaczego ta dieta? Czy potrącenie było prawidłowe? Narzędzia do wydatków dokumentują co zostało złożone. Nie dlaczego tak zdecydowano.</p>
</div>
</div>
</div>
</div>
</section>

<!-- Zasada Decision Layer -->
<section id="decision-layer" class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Decision Layer</p>
<h2 class="text-h1 font-bold text-gosign-dark">Każda sprawa. Rozłożona na kroki decyzyjne.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Travel Decision Layer działa jak każdy Gosign Decision Layer: rozkłada proces na poszczególne kroki decyzyjne i definiuje dla każdego kroku, kto lub co decyduje. Silnik reguł, układ zbiorowy lub człowiek. Nie wszystko naraz, lecz krok po kroku, udokumentowane i identyfikowalne.</p>
<div class="mt-10">
<img src="/images/diagrams/travel-decision-flow-v2-pl.svg" alt="Travel Decision Layer przepływ decyzyjny: dane wejściowe, ekstrakcja AI, Decision Layer, wynik" width="1000" height="280" class="w-full" />
</div>
<p class="text-body text-gosign-text mt-8 max-w-narrow font-semibold">AI ekstrahuje i klasyfikuje. Decision Layer decyduje. Ta separacja jest powodem, dla którego system jest audytowalny, zgodny z AI Act i transparentny dla rady pracowników.</p>
<div class="mt-10">
<div class="grid grid-cols-1 md:grid-cols-2 gap-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Ten sam input, ten sam wynik</h3>
<p class="text-body text-gosign-text-light mt-2">Tabele decyzyjne są wersjonowane. Każda sprawa jest sprawdzana względem zdefiniowanej wersji reguł. Brak wyników stochastycznych. Kwoty zwrotów, diety i ulgi podatkowe oblicza silnik reguł deterministycznie.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">40 do 120 pojedynczych decyzji na sprawę</h3>
<p class="text-body text-gosign-text-light mt-2">Nie jedna wielka decyzja 'zatwierdzone / odrzucone', lecz dziesiątki małych: jaka dieta? Jakie potrącenie? Jaki układ zbiorowy? Część zwolniona z podatku? Każda osobno udokumentowana.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Silnik reguł, układ zbiorowy lub człowiek</h3>
<p class="text-body text-gosign-text-light mt-2">Decision Layer nie decyduje o wszystkim sam. Wie, które kroki obejmuje silnik reguł, które definiują układy zbiorowe i gdzie musi interweniować człowiek. Rezultat: tylko prawdziwe wyjątki wymagają ludzkiej uwagi.</p>
</div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark">Pracownik nie potwierdza. Może zgłosić sprzeciw.</h3>
<p class="text-body text-gosign-text-light mt-2">Tradycyjne narzędzia proszą pracownika o potwierdzenie własnego rozliczenia. Decision Layer odwraca to: przetwarzanie następuje automatycznie. Pracownik jest informowany i ma prawo weta.</p>
</div>
</div>
</div>
</div>
</section>

<!-- Governance & Audit -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<h2 class="text-h1 font-bold text-gosign-dark">Nie dokumentowane po fakcie. Powstaje w procesie.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Gdy kontroler skarbowy pyta "Dlaczego naliczono 45 PLN zamiast 30 PLN diety?" odpowiedź "tak wyliczył system" nie wystarczy. Travel Decision Layer generuje na każdą mikrodecyzję akt decyzyjny, który dokładnie odpowiada na to pytanie: jaka reguła wraz z wersją, jaki input, jaki wynik, kiedy, przez kogo - łącznie ze ścieżką podważenia. Dzięki temu również wyjaśnienie pojedynczej decyzji wg art. 86 EU AI Act staje się zapytaniem, a nie projektem forensycznym.</p>
<!-- Audit Trail Card -->
<div class="mt-10 bg-gosign-dark rounded-card p-6 sm:p-8">
<div class="flex items-start gap-4 mb-6">
<svg class="w-8 h-8 text-gosign-accent-on-dark flex-shrink-0" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12h6m-6 4h6m2 5H7a2 2 0 01-2-2V5a2 2 0 012-2h5.586a1 1 0 01.707.293l5.414 5.414a1 1 0 01.293.707V19a2 2 0 01-2 2z" /></svg>
<div>
<h3 class="text-h3 font-bold text-white">Każda mikro-decyzja generuje wpis audytowy</h3>
<p class="text-small text-gosign-text-on-dark/70 mt-1">Append-only. Nic nie jest nadpisywane, nic usuwane. Przy korektach powstają wpisy stornujące i korygujące. Podpisane SHA-256, możliwe do eksportu w każdej chwili.</p>
</div>
</div>
<div class="grid grid-cols-2 sm:grid-cols-3 gap-3 sm:gap-4">
<div class="flex items-center gap-2.5"><svg class="w-4 h-4 text-gosign-accent-on-dark flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg><span class="text-small text-gosign-text-on-dark/80">ID reguły i wersja reguły</span></div>
<div class="flex items-center gap-2.5"><svg class="w-4 h-4 text-gosign-accent-on-dark flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg><span class="text-small text-gosign-text-on-dark/80">Dane wejściowe (co było dostępne?)</span></div>
<div class="flex items-center gap-2.5"><svg class="w-4 h-4 text-gosign-accent-on-dark flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg><span class="text-small text-gosign-text-on-dark/80">Wynik (co zdecydowano?)</span></div>
<div class="flex items-center gap-2.5"><svg class="w-4 h-4 text-gosign-accent-on-dark flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg><span class="text-small text-gosign-text-on-dark/80">Znacznik czasu</span></div>
<div class="flex items-center gap-2.5"><svg class="w-4 h-4 text-gosign-accent-on-dark flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg><span class="text-small text-gosign-text-on-dark/80">Aktor (silnik reguł / układ zbiorowy / człowiek)</span></div>
<div class="flex items-center gap-2.5"><svg class="w-4 h-4 text-gosign-accent-on-dark flex-shrink-0" fill="currentColor" viewBox="0 0 20 20" aria-hidden="true"><path fill-rule="evenodd" d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z" clip-rule="evenodd" /></svg><span class="text-small text-gosign-text-on-dark/80">Hash danych wejściowych (odtwarzalny)</span></div>
</div>
</div>
<!-- Three Governance Pillars -->
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6 mt-8">
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-3">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M15 12a3 3 0 11-6 0 3 3 0 016 0z" /><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M2.458 12C3.732 7.943 7.523 5 12 5c4.478 0 8.268 2.943 9.542 7-1.274 4.057-5.064 7-9.542 7-4.477 0-8.268-2.943-9.542-7z" /></svg>
<div>
<h3 class="text-body font-semibold text-gosign-dark">Transparentność dla rady pracowników</h3>
<p class="text-small text-gosign-text-light mt-2">Reguły dostępne do wglądu. Decyzje identyfikowalne. Ocena anomalii sterowana przez Feature Flag. Raporty pseudonimizowane. Compliance i wydajność architektonicznie rozdzielone.</p>
<a href="/pl/governance/co-determination/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Konsultacja &rarr;</a>
</div>
</div>
</div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-3">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12l2 2 4-4m5.618-4.016A11.955 11.955 0 0112 2.944a11.955 11.955 0 01-8.618 3.04A12.02 12.02 0 003 9c0 5.591 3.824 10.29 9 11.622 5.176-1.332 9-6.03 9-11.622 0-1.042-.133-2.052-.382-3.016z" /></svg>
<div>
<h3 class="text-body font-semibold text-gosign-dark">Gotowość na kontrolę skarbową</h3>
<p class="text-small text-gosign-text-light mt-2">Okresy archiwizacji wspierane (zgodnie z Ordynacją podatkową). Anonimizacja zamiast usuwania dla zgodności z RODO. Każda sprawa odtwarzalna dzięki hashowi danych wejściowych.</p>
<a href="/pl/governance/cert-ready/" class="inline-block mt-3 text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Cert-Ready &rarr;</a>
</div>
</div>
</div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6">
<div class="flex items-start gap-3">
<svg class="w-6 h-6 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 5H7a2 2 0 00-2 2v12a2 2 0 002 2h10a2 2 0 002-2V7a2 2 0 00-2-2h-2M9 5a2 2 0 002 2h2a2 2 0 002-2M9 5a2 2 0 012-2h2a2 2 0 012 2m-6 9l2 2 4-4" /></svg>
<div>
<h3 class="text-body font-semibold text-gosign-dark">Systematyczny Compliance</h3>
<p class="text-small text-gosign-text-light mt-2">Żadnych raportów kwartalnych, żadnych kontroli próbkowych. Każda pojedyncza sprawa jest weryfikowana względem reguł. Odchylenia są wykrywane natychmiast i dokumentowane.</p>
</div>
</div>
</div>
</div>
</div>
</section>

<!-- Tabela porównawcza -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="overflow-x-auto">
<table class="w-full text-small border-collapse">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Wymiar</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-dark">Tradycyjne narzędzie do wydatków</th>
<th class="text-left py-3 px-4 font-semibold text-gosign-accent-text">Travel Decision Layer</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border"><td class="py-3 px-4 font-medium text-gosign-dark">Model decyzyjny</td><td class="py-3 px-4 text-gosign-text-light">Człowiek wypełnia, przełożony zatwierdza</td><td class="py-3 px-4 text-gosign-accent-text font-semibold">Decision Layer stosuje reguły, człowiek ma weto</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4 font-medium text-gosign-dark">Złożoność reguł</td><td class="py-3 px-4 text-gosign-text-light">Podstawowe polityki, brak logiki układów zbiorowych</td><td class="py-3 px-4 text-gosign-accent-text font-semibold">Wersjonowane tabele decyzyjne: prawo podatkowe, diety, układy zbiorowe</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4 font-medium text-gosign-dark">Audit Trail</td><td class="py-3 px-4 text-gosign-text-light">Rachunek zapisany, decyzja nieudokumentowana</td><td class="py-3 px-4 text-gosign-accent-text font-semibold">Każda mikro-decyzja udokumentowana: reguła, input, wynik, znacznik czasu</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4 font-medium text-gosign-dark">Kontrola skarbowa</td><td class="py-3 px-4 text-gosign-text-light">Ręczna rekonstrukcja z akt</td><td class="py-3 px-4 text-gosign-accent-text font-semibold">Eksport: zaplombowana akta decyzyjna na sprawę, odtwarzalna przez hash</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4 font-medium text-gosign-dark">Doświadczenie pracownika</td><td class="py-3 px-4 text-gosign-text-light">Formularz, upload, czekanie na zatwierdzenie</td><td class="py-3 px-4 text-gosign-accent-text font-semibold">Automatyczne przetwarzanie, powiadomienie, opcja weta</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4 font-medium text-gosign-dark">Skalowalność</td><td class="py-3 px-4 text-gosign-text-light">Liniowa: więcej spraw = więcej kontrolerów</td><td class="py-3 px-4 text-gosign-accent-text font-semibold">Stała: 100 lub 100 000 spraw, ten sam silnik reguł</td></tr>
<tr class="border-b border-gosign-border"><td class="py-3 px-4 font-medium text-gosign-dark">Rada pracowników</td><td class="py-3 px-4 text-gosign-text-light">Nieprzejrzysty, trudny do weryfikacji</td><td class="py-3 px-4 text-gosign-accent-text font-semibold">Silnik reguł dostępny do wglądu, ocena anomalii per Feature Flag, raporty pseudonimizowane</td></tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Symulacje branżowe -->
<section id="simulationen" class="py-section bg-gosign-dark">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-on-dark mb-2">Symulowane dla wolumenów enterprise</p>
<h2 class="text-h1 font-bold text-white">Cztery branże. Policzone.</h2>
<p class="text-body-lg text-gosign-text-on-dark/80 mt-4 max-w-narrow">Skonfigurowaliśmy Travel Decision Layer dla czterech branż z realistycznymi wolumenami i policzyliśmy wyniki. Każda karta pokazuje parametry symulacji i rezultat.</p>
<div class="grid grid-cols-1 md:grid-cols-2 gap-6 mt-10">
<a href="/pl/uslugi/travel-decision-layer/lotnictwo/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors">
<div class="flex items-center justify-between mb-4"><h3 class="text-h3 font-bold text-white">Lotnictwo</h3><div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span></div></div>
<ul class="space-y-1.5 text-small text-gosign-text-on-dark/70"><li>Dziesiątki tysięcy załóg, wiele grup personalnych</li><li>Wiele równoległych układów zbiorowych per przewoźnik</li><li>100 000 do 1 000 000+ spraw/rok</li><li>Multi-carrier, multi-jurysdykcja</li></ul>
<div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between"><span class="text-h3 font-bold text-gosign-accent-on-dark">95% Zero-Touch</span><span class="text-small text-gosign-accent-on-dark font-semibold">Lotnictwo szczegółowo &rarr;</span></div>
</a>
<a href="/pl/uslugi/travel-decision-layer/doradztwo/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors">
<div class="flex items-center justify-between mb-4"><h3 class="text-h3 font-bold text-white">Doradztwo</h3><div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-white/20"></span></div></div>
<ul class="space-y-1.5 text-small text-gosign-text-on-dark/70"><li>8 000+ konsultantów, 15+ jurysdykcji</li><li>Split trójstronny: podatkowy / klient / wewnętrzny</li><li>Tygodnie wieloklienckie, codziennie zmieniające się centra kosztów</li></ul>
<div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between"><span class="text-h3 font-bold text-gosign-accent-on-dark">85% Zero-Touch</span><span class="text-small text-gosign-accent-on-dark font-semibold">Doradztwo szczegółowo &rarr;</span></div>
</a>
<a href="/pl/uslugi/travel-decision-layer/logistyka/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors">
<div class="flex items-center justify-between mb-4"><h3 class="text-h3 font-bold text-white">Logistyka</h3><div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-white/20"></span></div></div>
<ul class="space-y-1.5 text-small text-gosign-text-on-dark/70"><li>20 000+ kierowców, Pakiet mobilności UE</li><li>Rozpoznawanie krajów na podstawie GPS</li><li>Diety kierowców oparte na flocie</li></ul>
<div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between"><span class="text-h3 font-bold text-gosign-accent-on-dark">95% Zero-Touch</span><span class="text-small text-gosign-accent-on-dark font-semibold">Logistyka szczegółowo &rarr;</span></div>
</a>
<a href="/pl/uslugi/travel-decision-layer/sprzedaz/" class="block bg-white/5 border border-white/10 p-6 hover:bg-white/10 transition-colors">
<div class="flex items-center justify-between mb-4"><h3 class="text-h3 font-bold text-white">Sprzedaż</h3><div class="flex gap-1"><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-gosign-accent"></span><span class="w-3 h-1.5 rounded-sm bg-white/20"></span><span class="w-3 h-1.5 rounded-sm bg-white/20"></span></div></div>
<ul class="space-y-1.5 text-small text-gosign-text-on-dark/70"><li>5 000+ handlowców terenowych, integracja CRM</li><li>10 000+ spraw miesięcznie</li><li>Egzekwowanie polityk w wolumenie</li></ul>
<div class="mt-4 pt-4 border-t border-white/10 flex items-center justify-between"><span class="text-h3 font-bold text-gosign-accent-on-dark">90% Zero-Touch</span><span class="text-small text-gosign-accent-on-dark font-semibold">Sprzedaż szczegółowo &rarr;</span></div>
</a>
</div>
</div>
</section>

<!-- Architektura, implementacja i dźwignia -->
<section id="implementation" class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Implementacja</p>
<h2 class="text-h1 font-bold text-gosign-dark">Od pilotu do działającego systemu.</h2>
<div class="grid grid-cols-1 lg:grid-cols-2 gap-10 mt-10">
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Architektura techniczna</h3>
<p class="text-body text-gosign-text">Travel Decision Layer działa całkowicie w Twojej infrastrukturze: Twoje centrum danych, Twoja sieć, Twoja kontrola. Brak zależności od SaaS, brak wycieku danych, brak zewnętrznego śledzenia telemetrycznego. Konteneryzowany, wielomandantowy, gotowy do wdrożenia w Twojej Private Cloud lub jako Managed Deployment w centrach danych w UE.</p>
<div class="flex flex-wrap gap-4 mt-3">
<a href="/pl/uslugi/infrastruktura/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Infrastruktura szczegółowo &rarr;</a>
<a href="/pl/decision-layer/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover transition-colors whitespace-nowrap">Architektura Decision Layer &rarr;</a>
</div>
</div>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Implementacja</h3>
<p class="text-body text-gosign-text">Decision Layer nie jest instalowany, lecz konfigurowany: Twoje układy zbiorowe, Twoje polityki, Twój krajobraz systemowy. Typowe projekty pilotażowe startują w ciągu 3 miesięcy z jedną branżą i jednym układem zbiorowym. Rozszerzenia na kolejne grupy pracownicze lub integracje systemowe działają równolegle z pilotem.</p>
</div>
</div>
<h3 class="text-h3 font-bold text-gosign-dark mt-12 mb-6">Dźwignia ekonomiczna</h3>
<div class="grid grid-cols-1 sm:grid-cols-2 gap-6">
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6"><div class="flex items-start gap-4"><svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12l2 2 4-4m5.618-4.016A11.955 11.955 0 0112 2.944a11.955 11.955 0 01-8.618 3.04A12.02 12.02 0 003 9c0 5.591 3.824 10.29 9 11.622 5.176-1.332 9-6.03 9-11.622 0-1.042-.133-2.052-.382-3.016z" /></svg><div><p class="text-body font-semibold text-gosign-dark">Systematyczna weryfikacja reguł zamiast kontroli próbkowych</p><p class="text-small text-gosign-text-light mt-2">Każda sprawa przechodzi przez ten sam silnik reguł. Odchylenia są wykrywane i dokumentowane, nie dopiero przy kwartalnym uzgadnianiu.</p></div></div></div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6"><div class="flex items-start gap-4"><svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M13 10V3L4 14h7v7l9-11h-7z" /></svg><div><p class="text-body font-semibold text-gosign-dark">Brak workflow zatwierdzania dla standardowych spraw</p><p class="text-small text-gosign-text-light mt-2">Czas przetwarzania z dni na minuty. Przełożeni zatwierdzają tylko wyjątki.</p></div></div></div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6"><div class="flex items-start gap-4"><svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M4 6a2 2 0 012-2h2a2 2 0 012 2v2a2 2 0 01-2 2H6a2 2 0 01-2-2V6zm10 0a2 2 0 012-2h2a2 2 0 012 2v2a2 2 0 01-2 2h-2a2 2 0 01-2-2V6zM4 16a2 2 0 012-2h2a2 2 0 012 2v2a2 2 0 01-2 2H6a2 2 0 01-2-2v-2zm10 0a2 2 0 012-2h2a2 2 0 012 2v2a2 2 0 01-2 2h-2a2 2 0 01-2-2v-2z" /></svg><div><p class="text-body font-semibold text-gosign-dark">Automatyczne przypisanie centrów kosztów i projektów</p><p class="text-small text-gosign-text-light mt-2">Żadnego ręcznego mapowania dla tysięcy spraw. Koniec z wąskim gardłem na koniec miesiąca.</p></div></div></div>
<div class="bg-gosign-light border border-gosign-border border-l-4 border-l-gosign-accent p-6"><div class="flex items-start gap-4"><svg class="w-8 h-8 text-gosign-accent-text flex-shrink-0 mt-0.5" fill="none" stroke="currentColor" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="1.5" d="M9 12h6m-6 4h6m2 5H7a2 2 0 01-2-2V5a2 2 0 012-2h5.586a1 1 0 01.707.293l5.414 5.414a1 1 0 01.293.707V19a2 2 0 01-2 2z" /></svg><div><p class="text-body font-semibold text-gosign-dark">Akta decyzyjne gotowe na kontrolę tworzone w procesie</p><p class="text-small text-gosign-text-light mt-2">Kontrola skarbowa to eksport, nie projekt badawczy. Tygodnie stają się minutami.</p></div></div></div>
</div>
</div>
</section>

<!-- Compliance & Security -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Bezpieczeństwo</p>
<h2 class="text-h1 font-bold text-gosign-dark">Enterprise security. Od pierwszego dnia.</h2>
<p class="text-body-lg text-gosign-text-light mt-4 max-w-narrow">Nie dołożone jako feature, lecz zbudowane jako zasada architektoniczna. Travel Decision Layer jest zaprojektowany dla środowisk regulowanych, w których ochrona danych, gotowość na audyt i identyfikowalność nie są opcjonalnymi dodatkami.</p>
<div class="mt-10">
<div class="grid grid-cols-1 md:grid-cols-3 gap-6">
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-h3 font-bold text-gosign-dark">100% infrastruktura klienta</h3><p class="text-body text-gosign-text-light mt-2">Decision Layer działa całkowicie w Twojej sieci. Brak zależności od SaaS, brak wycieku danych, brak zewnętrznego śledzenia telemetrycznego. Sekrety w Twoim KMS, logi w Twoim SIEM, SSO przez Twojego dostawcę tożsamości.</p></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-h3 font-bold text-gosign-dark">RODO by Design</h3><p class="text-body text-gosign-text-light mt-2">Anonimizacja zamiast usuwania. Kompatybilność z obowiązkami archiwizacyjnymi wynikającymi z Ordynacji podatkowej i RODO art. 17. Brak sprzeczności między prawem podatkowym a ochroną danych.</p><a href="/pl/governance/data-residency/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover mt-3 inline-block whitespace-nowrap">Rezydencja danych szczegółowo</a></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-h3 font-bold text-gosign-dark">Zgodność z AI Act</h3><p class="text-body text-gosign-text-light mt-2">Jasna separacja architektoniczna: LLM do ekstrakcji danych, Decision Layer do decyzji. Żadnej czarnej skrzynki w sprawach podatkowych. Każda decyzja możliwa do odtworzenia.</p><a href="/pl/governance/eu-ai-act/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover mt-3 inline-block whitespace-nowrap">EU AI Act Readiness</a></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-h3 font-bold text-gosign-dark">Audit Trail (append-only)</h3><p class="text-body text-gosign-text-light mt-2">Podpisane akta decyzyjne. Hash danych wejściowych plus wersja reguły daje odtwarzalny wynik. Zaplombowane pakiety audytowe (JSON + PDF, SHA-256). Kontrola skarbowa w każdej chwili.</p></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-h3 font-bold text-gosign-dark">ISO 27001 / PS 951 cert-ready</h3><p class="text-body text-gosign-text-light mt-2">Zintegrowany rejestr kontroli, zautomatyzowane przebiegi dowodowe, wersjonowane polityki. Compliance w bieżącej działalności, nie dokumentowany po fakcie.</p><a href="/pl/governance/cert-ready/" class="text-gosign-accent-text font-semibold text-small hover:text-gosign-accent-hover mt-3 inline-block whitespace-nowrap">Cert-Ready by Design</a></div>
<div class="bg-gosign-white border border-gosign-border rounded-card p-6"><h3 class="text-h3 font-bold text-gosign-dark">SSO i separacja mandantów</h3><p class="text-body text-gosign-text-light mt-2">Integracja z istniejącymi dostawcami tożsamości. Separacja mandantów na poziomie bazy danych (Row Level Security). Model ról konfigurowalny granularnie.</p></div>
</div>
</div>
</div>
</section>

<!-- Pogłębienie w Agent Briefing -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Pogłębienie w Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nasza seria artykułów fachowych dla decydentów wdrażających agentów AI w przedsiębiorstwie.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/pl/magazyn/decision-layer-wyjasnienie/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors"><p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Podstawy</p><p class="text-body font-semibold text-gosign-dark">Decision Layer - czym jest i dlaczego każdy agent AI go potrzebuje?</p></a>
<a href="/pl/magazyn/rada-zakladowa-ai-mitbestimmung/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors"><p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Konsultacja</p><p class="text-body font-semibold text-gosign-dark">Rada Zakładowa a AI - Konsultacja jako Constraint Architektury</p></a>
<a href="/pl/magazyn/cert-ready-by-design/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors"><p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Audyt</p><p class="text-body font-semibold text-gosign-dark">Cert-Ready by Design - AI gotowe do audytu od startu</p></a>
</div>
</div>
</section>

--- Usługi ---
> AI Agents, Finance Agents, HR Agents, Infrastruktura AI, Document Intelligence i podpisy cyfrowe eIDAS.

<!-- Co Budujemy -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="max-w-narrow">
<h2 class="text-h1 font-bold text-gosign-dark">Co Budujemy</h2>
<p class="text-body-lg text-gosign-text-light mt-4">
Gosign rozwija i operuje infrastrukturę AI Agents dla przedsiębiorstw. Budujemy warstwę między modelem językowym a systemem korporacyjnym - włączając orkiestrację, governance i audyt.
</p>
</div>
</div>
</section>

<!-- Service Cards -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-1 lg:grid-cols-3 gap-6 lg:gap-8">
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9.813 15.904L9 18.75l-.813-2.846a4.5 4.5 0 00-3.09-3.09L2.25 12l2.846-.813a4.5 4.5 0 003.09-3.09L9 5.25l.813 2.846a4.5 4.5 0 003.09 3.09L15.75 12l-2.846.813a4.5 4.5 0 00-3.09 3.09zM18.259 8.715L18 9.75l-.259-1.035a3.375 3.375 0 00-2.455-2.456L14.25 6l1.036-.259a3.375 3.375 0 002.455-2.456L18 2.25l.259 1.035a3.375 3.375 0 002.455 2.456L21.75 6l-1.036.259a3.375 3.375 0 00-2.455 2.456zM16.894 20.567L16.5 21.75l-.394-1.183a2.25 2.25 0 00-1.423-1.423L13.5 18.75l1.183-.394a2.25 2.25 0 001.423-1.423l.394-1.183.394 1.183a2.25 2.25 0 001.423 1.423l1.183.394-1.183.394a2.25 2.25 0 00-1.423 1.423z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">AI Agents</h3>
<p class="text-body text-gosign-text-light mt-3">Document Agents, Workflow Agents, Knowledge Agents. Wyspecjalizowane AI Agents, które czytają dokumenty, orkiestrują procesy i dostarczają kontekstowe odpowiedzi. Każdy agent operuje w ramach Decision Layer.</p>
<a href="/pl/uslugi/ai-agents/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">AI Agents w szczegółach<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg></a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M2.25 18.75a60.07 60.07 0 0115.797 2.101c.727.198 1.453-.342 1.453-1.096V18.75M3.75 4.5v.75A.75.75 0 013 6h-.75m0 0v-.375c0-.621.504-1.125 1.125-1.125H20.25M2.25 6v9m18-10.5v.75c0 .414.336.75.75.75h.75m-1.5-1.5h.375c.621 0 1.125.504 1.125 1.125v9.75c0 .621-.504 1.125-1.125 1.125h-.375m1.5-1.5H21a.75.75 0 00-.75.75v.75m0 0H3.75m0 0h-.375a1.125 1.125 0 01-1.125-1.125V15m1.5 1.5v-.75A.75.75 0 003 15h-.75M15 10.5a3 3 0 11-6 0 3 3 0 016 0zm3 0h.008v.008H18V10.5zm-12 0h.008v.008H6V10.5z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Finance Agents</h3>
<p class="text-body text-gosign-text-light mt-3">Decision Automation dla przetwarzania dokumentów i księgowości. Automatyczne przetwarzanie dokumentów do zaksięgowania z dowodem audytu. Wersjonowane zestawy reguł. Cert-Ready by Design.</p>
<a href="/pl/uslugi/finance-agent/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">Finance Agents<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg></a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M15 19.128a9.38 9.38 0 002.625.372 9.337 9.337 0 004.121-.952 4.125 4.125 0 00-7.533-2.493M15 19.128v-.003c0-1.113-.285-2.16-.786-3.07M15 19.128v.106A12.318 12.318 0 018.624 21c-2.331 0-4.512-.645-6.374-1.766l-.001-.109a6.375 6.375 0 0111.964-3.07M12 6.375a3.375 3.375 0 11-6.75 0 3.375 3.375 0 016.75 0zm8.25 2.25a2.625 2.625 0 11-5.25 0 2.625 2.625 0 015.25 0z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">HR Agents</h3>
<p class="text-body text-gosign-text-light mt-3">AI Agents dla HR i People Operations. Korporacyjne AI Agents dla spójnych, identyfikowalnych decyzji HR z dowodem audytu. Zgodne z radą zakładową. Decision Layer z Human-in-the-Loop.</p>
<a href="/pl/hr-ai-agents/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">HR Agents<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg></a>
</article>
</div>
</div>
</section>

<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<div class="grid grid-cols-1 lg:grid-cols-3 gap-6 lg:gap-8">
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M5.25 14.25h13.5m-13.5 0a3 3 0 01-3-3m3 3a3 3 0 100 6h13.5a3 3 0 100-6m-16.5-3a3 3 0 013-3h13.5a3 3 0 013 3m-19.5 0a4.5 4.5 0 01.9-2.7L5.737 5.1a3.375 3.375 0 012.7-1.35h7.126c1.062 0 2.062.5 2.7 1.35l2.587 3.45a4.5 4.5 0 01.9 2.7m0 0a3 3 0 01-3 3m0 3h.008v.008h-.008v-.008zm0-6h.008v.008h-.008v-.008zm-3 6h.008v.008h-.008v-.008zm0-6h.008v.008h-.008v-.008z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">AI Infrastructure</h3>
<p class="text-body text-gosign-text-light mt-3">LLM Hosting, RAG, Orkiestracja, Self-Hosted. Infrastruktura, na której AI Agents działają w produkcji. Agnostyczna wobec modeli, elastyczna we wdrożeniu, przygotowana na governance.</p>
<a href="/pl/uslugi/infrastruktura/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">AI Infrastructure<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg></a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M19.5 14.25v-2.625a3.375 3.375 0 00-3.375-3.375h-1.5A1.125 1.125 0 0113.5 7.125v-1.5a3.375 3.375 0 00-3.375-3.375H8.25m0 12.75h7.5m-7.5 3H12M10.5 2.25H5.625c-.621 0-1.125.504-1.125 1.125v17.25c0 .621.504 1.125 1.125 1.125h12.75c.621 0 1.125-.504 1.125-1.125V11.25a9 9 0 00-9-9z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Document Intelligence</h3>
<p class="text-body text-gosign-text-light mt-3">Rozumienie dokumentów wykraczające poza OCR. Klasyfikacja, ekstrakcja, walidacja - napędzane przez LLM, kontrolowane przez Decision Layer. Dla faktur, umów, zaświadczeń i dokumentów niestrukturalnych.</p>
<a href="/pl/uslugi/document-intelligence/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">Document Intelligence<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg></a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M9 6.75V15m6-6v8.25m.503 3.498l4.875-2.437c.381-.19.622-.58.622-1.006V4.82c0-.836-.88-1.38-1.628-1.006l-3.869 1.934c-.317.159-.69.159-1.006 0L9.503 3.252a1.125 1.125 0 00-1.006 0L3.622 5.689C3.24 5.88 3 6.27 3 6.695V19.18c0 .836.88 1.38 1.628 1.006l3.869-1.934c.317-.159.69-.159 1.006 0l4.994 2.497c.317.158.69.158 1.006 0z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Travel Decision Layer</h3>
<p class="text-body text-gosign-text-light mt-3">Automatyzacja rozliczania podróży służbowych oparta na AI. Decision Layer rozkłada każde rozliczenie na kroki decyzyjne i stosuje przepisy podatkowe, diety i zasady z układów zbiorowych deterministycznie. Konfigurowalny dla lotnictwa, doradztwa, logistyki i sprzedaży.</p>
<a href="/pl/uslugi/travel-decision-layer/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">Travel Decision Layer<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg></a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M17.25 6.75L22.5 12l-5.25 5.25m-10.5 0L1.5 12l5.25-5.25m7.5-3l-4.5 16.5" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Inżynieria Oprogramowania Korporacyjnego</h3>
<p class="text-body text-gosign-text-light mt-3">Od 2001. Ponad 5 000 projektów. 25 lat rozwoju oprogramowania korporacyjnego dla Airbus, Volkswagen, Shell. Dziś infrastruktura AI - zbudowana na tym samym fundamencie.</p>
<a href="/pl/uslugi/software-engineering/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">Inżynieria Oprogramowania<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg></a>
</article>
<article class="bg-gosign-white border border-gosign-border rounded-card p-6 lg:p-8 hover:border-gosign-accent/30 transition-colors">
<div class="w-12 h-12 flex items-center justify-center mb-4">
<svg class="w-8 h-8 text-gosign-accent-text" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M16.5 10.5V6.75a4.5 4.5 0 10-9 0v3.75m-.75 11.25h10.5a2.25 2.25 0 002.25-2.25v-6.75a2.25 2.25 0 00-2.25-2.25H6.75a2.25 2.25 0 00-2.25 2.25v6.75a2.25 2.25 0 002.25 2.25z" /></svg>
</div>
<h3 class="text-h3 font-bold text-gosign-dark">Podpisy Cyfrowe eIDAS</h3>
<p class="text-body text-gosign-text-light mt-3">We współpracy z certyfikowanymi partnerami ETSI. Rozwiązania podpisu cyfrowego zgodne z eIDAS. Podpisy elektroniczne proste, zaawansowane (AES) i kwalifikowane (QES).</p>
<a href="/pl/uslugi/eidas-signatures/" class="inline-flex items-center mt-4 text-body font-semibold text-gosign-accent-text hover:text-gosign-accent-hover transition-colors">Podpisy eIDAS<svg class="w-4 h-4 ml-1" fill="none" stroke="currentColor" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 5l7 7-7 7" /></svg></a>
</article>
</div>
</div>
</section>

<!-- Jak Pracujemy -->

<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h1 font-bold text-gosign-dark text-center">Jak Pracujemy</h2>
<div class="mt-12 grid grid-cols-1 md:grid-cols-3 gap-8 relative">
<div class="text-center">
<div class="w-14 h-14 mx-auto rounded-full bg-gosign-accent flex items-center justify-center">
<span class="text-h3 font-bold text-white">1</span>
</div>
<h3 class="text-h3 font-bold text-gosign-dark mt-4">Discover</h3>
<p class="text-small font-semibold text-gosign-accent-text mt-1">1 tydzień</p>
<p class="text-body text-gosign-text-light mt-2">Analiza procesów, zrozumienie reguł, priorytetyzacja.</p>
</div>
<div class="text-center">
<div class="w-14 h-14 mx-auto rounded-full bg-gosign-accent flex items-center justify-center">
<span class="text-h3 font-bold text-white">2</span>
</div>
<h3 class="text-h3 font-bold text-gosign-dark mt-4">Build</h3>
<p class="text-small font-semibold text-gosign-accent-text mt-1">3-4 tygodnie</p>
<p class="text-body text-gosign-text-light mt-2">Produkcyjny PoC. Jeden agent, jeden proces, na żywo w infrastrukturze klienta.</p>
</div>
<div class="text-center">
<div class="w-14 h-14 mx-auto rounded-full bg-gosign-accent flex items-center justify-center">
<span class="text-h3 font-bold text-white">3</span>
</div>
<h3 class="text-h3 font-bold text-gosign-dark mt-4">Scale</h3>
<p class="text-small font-semibold text-gosign-accent-text mt-1">Ciągły</p>
<p class="text-body text-gosign-text-light mt-2">Więcej agentów, więcej procesów. Ta sama governance.</p>
</div>
</div>
<p class="text-body-lg text-center text-gosign-text-light mt-8 max-w-narrow mx-auto">Po 12-18 miesiącach klient operuje samodzielnie.</p>
</div>
</section>


<!-- Pogłębienie -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-2">Pogłębienie w Agent Briefing</h2>
<p class="text-body text-gosign-text-light mb-6">Nasza seria artykułów fachowych dla decydentów wdrażających agentów AI.</p>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/pl/magazyn/czym-sa-agenci-ai/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">AI Agents</p>
<p class="text-body font-semibold text-gosign-dark">Czym sa agenci AI? Document, Workflow i Knowledge Agents</p>
</a>
<a href="/pl/magazyn/decision-layer-wyjasnienie/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Governance</p>
<p class="text-body font-semibold text-gosign-dark">Decision Layer - czym jest i dlaczego każdy agent AI go potrzebuje?</p>
</a>
<a href="/pl/magazyn/dlaczego-projekty-ai-w-hr-nie-udaja-sie/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-xs font-semibold uppercase tracking-wider text-gosign-accent-text mb-2">Strategie</p>
<p class="text-body font-semibold text-gosign-dark">Dlaczego projekty AI w HR nie udają się</p>
</a>
</div>
</div>
</section>

--- Tworzenie strony z AI | Whitepaper ---
> Whitepaper: od projektu graficznego do działającego motywu WordPress z AI. Praktyczny przewodnik od Gosign.

<!-- O czym jest ten whitepaper? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">O czym jest ten whitepaper?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Ten whitepaper od Gosign przedstawia kompletny workflow tworzenia strony internetowej z wykorzystaniem AI: od koncepcji przez projekt graficzny do działającego motywu WordPress. To nie teoretyczny przegląd, lecz praktyczny przewodnik z konkretnymi narzędziami, promptami i wynikami z rzeczywistych projektów klienckich.
</p>
</div>
</section>

<!-- Spis treści -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">Spis treści</h2>

<div class="space-y-8">
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">1. AI w procesie projektowania stron</h3>
<p class="text-body text-gosign-text leading-relaxed">
Generowanie layoutów, tworzenie moodboardów, wireframe-to-design z narzędziami AI. Co działa, co nie, i gdzie ludzka ocena projektowa pozostaje niezastąpiona.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">2. Od projektu do kodu</h3>
<p class="text-body text-gosign-text leading-relaxed">
Realizacja projektów Figma/Sketch w HTML/CSS/PHP wspomagana AI. Jak Gosign generuje szkielety motywów z AI, a senior developerzy dopracowują wynik.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">3. Tworzenie motywów WordPress z AI</h3>
<p class="text-body text-gosign-text leading-relaxed">
Własne bloki Gutenberg, szablony Full Site Editing, logika functions.php - co AI generuje w minuty, a co wcześniej wymagało dni. Konkretne porównanie przed i po.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">4. Zapewnienie jakości</h3>
<p class="text-body text-gosign-text leading-relaxed">
AI generuje kod, ale kto sprawdza jakość? Proces QA w Gosign: automatyczne testy, kontrola dostępności, audyty wydajności, ręczny przegląd kodu.
</p>
</div>

<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-2">5. Wyniki z praktyki</h3>
<p class="text-body text-gosign-text leading-relaxed">
Dane o oszczędności czasu z rzeczywistych projektów Gosign: 60-80&nbsp;% szybciej. Dokładnie gdzie czas jest oszczędzany i gdzie nie.
</p>
</div>
</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Chcesz wykorzystać AI w swoim następnym projekcie webowym?</h3>
<p class="text-body text-gosign-text mb-6">30 minut pierwszej konsultacji, bezpłatnie i bez zobowiązań.</p>
<a
href="/pl/kontakt/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Umów konsultację
</a>
<p class="text-small text-gosign-text-light mt-4">25 lat doświadczenia · 800+ rozszerzeń · rozwój wspomagany AI</p>
</div>
</section>

<!-- Dla kogo? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Dla kogo jest ten whitepaper?</h2>
<ul class="space-y-3">
<li class="flex items-start gap-3">
<span class="flex-shrink-0 mt-1.5 w-2 h-2 bg-gosign-accent rounded-full"></span>
<span class="text-body text-gosign-text">Kierowników projektów i Product Ownerów, którzy chcą realizować projekty webowe szybciej i taniej</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 mt-1.5 w-2 h-2 bg-gosign-accent rounded-full"></span>
<span class="text-body text-gosign-text">Osoby odpowiedzialne za marketing, które ewaluują tworzenie stron z AI</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 mt-1.5 w-2 h-2 bg-gosign-accent rounded-full"></span>
<span class="text-body text-gosign-text">Developerów, którzy chcą zintegrować AI w swoim workflow</span>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 mt-1.5 w-2 h-2 bg-gosign-accent rounded-full"></span>
<span class="text-body text-gosign-text">Dyrektorów, którzy chcą zrozumieć ROI inwestycji w AI w tworzeniu stron</span>
</li>
</ul>
</div>
</section>

<!-- Entity Block -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
Gosign to hamburska agencja cyfrowa z 25-letnim doświadczeniem w tworzeniu stron, TYPO3 i integracji AI.
Obsługujemy europejskie i polskie przedsiębiorstwa z naszej siedziby w Hamburgu.
Przeanalizowaliśmy ponad 800 rozszerzeń TYPO3 i dzięki wsparciu AI realizujemy projekty
do 70&nbsp;% szybciej niż tradycyjnymi metodami.
</p>
<p class="text-small text-gosign-text-light mt-2">Stan na: luty 2026</p>
</div>
</section>

<!-- Powiązane tematy -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Powiązane tematy</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/pl/agencja-cyfrowa-hamburg/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Tworzenie stron</p>
<p class="text-body font-semibold text-gosign-dark">Agencja cyfrowa Hamburg</p>
</a>
<a href="/pl/agencja-wordpress/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">CMS</p>
<p class="text-body font-semibold text-gosign-dark">Agencja WordPress Hamburg</p>
</a>
<a href="/pl/bezpieczenstwo-stron-standardy/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Bezpieczeństwo</p>
<p class="text-body font-semibold text-gosign-dark">Bezpieczeństwo stron - standardy NIS2</p>
</a>
</div>
</div>
</section>

--- Dostępność cyfrowa i Europejski Akt o Dostępności 2025 ---
> Europejski Akt o Dostępności obowiązuje od czerwca 2025. Kogo dotyczy, co oznacza dostępna strona internetowa i jakie grożą kary? Wyjaśniamy przystępnie.

<!-- Czym jest EAA? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Czym jest Europejski Akt o Dostępności i dlaczego powstał?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Europejski Akt o Dostępności (EAA) wdraża Dyrektywę UE 2019/882 we wszystkich państwach członkowskich. UE stworzyła jednolite ramy prawne: produkty i usługi oferowane konsumentom muszą być dostępne dla osób z niepełnosprawnościami.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Dotyczy to między innymi stron internetowych i sklepów online. Cel jest prosty: każda osoba, która chce kupić, zarezerwować lub uzyskać informacje w internecie, powinna móc to zrobić niezależnie od ograniczeń wzroku, słuchu czy sprawności ruchowej. Od <strong>28 czerwca 2025 roku</strong> EAA jest obowiązującym prawem - naruszenia mogą skutkować karami finansowymi.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Dla firm oznacza to jedno: dostępność cyfrowa nie jest już dobrowolna - to obowiązek. Podobnie jak <a href="/pl/wiedza/obowiazki-rodo-strony/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">RODO w zakresie ochrony danych</a> - kto nie zna przepisów, ryzykuje kary.
</p>
</div>
</section>

<!-- Kogo dotyczy? -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Czy EAA dotyczy mojej firmy? Przewodnik według typu organizacji</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
EAA dotyczy <strong>podmiotów gospodarczych</strong> wprowadzających produkty lub usługi na rynek konsumencki. To, czy jesteś objęty przepisami, zależy mniej od formy prawnej, a bardziej od tego, co robisz.
</p>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse bg-white rounded-card">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Typ organizacji</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Obowiązek EAA?</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Wyjaśnienie</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Firma ze sklepem online</td>
<td class="py-3 px-4 text-body text-gosign-accent-text font-semibold">Tak</td>
<td class="py-3 px-4 text-body text-gosign-text">Handel elektroniczny to usługa konsumencka. Pełny obowiązek EAA.</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Firma z czysto B2B-ową stroną</td>
<td class="py-3 px-4 text-body text-gosign-text font-semibold">Nie (formalnie)</td>
<td class="py-3 px-4 text-body text-gosign-text">EAA obejmuje wyłącznie usługi konsumenckie. Czysto biznesowe portale są wyłączone - dostępność nadal jest jednak zalecana.</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Organizacja non-profit</td>
<td class="py-3 px-4 text-body text-gosign-text font-semibold">Z reguły nie</td>
<td class="py-3 px-4 text-body text-gosign-text">Organizacje non-profit z reguły nie są objęte. Jednak grantodawcy coraz częściej wymagają dostępności, a organizacje z ofertą komercyjną (bilety, sklep) mogą być objęte przepisami.</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Mikroprzedsiębiorstwo (&lt; 10 pracowników, &lt; 2 mln EUR)</td>
<td class="py-3 px-4 text-body text-gosign-text font-semibold">Możliwe zwolnienie</td>
<td class="py-3 px-4 text-body text-gosign-text">Mikroprzedsiębiorstwa zatrudniające mniej niż 10 pracowników i z rocznym obrotem poniżej 2 mln EUR są zwolnione z obowiązku w zakresie usług.</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Stowarzyszenie / Związek</td>
<td class="py-3 px-4 text-body text-gosign-text font-semibold">To zależy</td>
<td class="py-3 px-4 text-body text-gosign-text">Stowarzyszenia niekomercyjne z reguły nie są objęte. Jeśli jednak oferują płatne usługi online, EAA ma zastosowanie.</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Podmiot publiczny / Urząd</td>
<td class="py-3 px-4 text-body text-gosign-accent-text font-semibold">Tak (na mocy EN 301 549)</td>
<td class="py-3 px-4 text-body text-gosign-text">Podmioty publiczne nie podlegają EAA, lecz normie EN 301 549 i przepisom krajowym - z podobnymi wymogami, obowiązującymi już od 2019 roku.</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Zwolnienie dla mikroprzedsiębiorstw -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Zwolnienie dla mikroprzedsiębiorstw: kiedy ma zastosowanie?</h2>
<p class="text-body text-gosign-text leading-relaxed">
EAA przewiduje zwolnienie dla mikroprzedsiębiorstw: firmy zatrudniające <strong>mniej niż 10 pracowników</strong> i z <strong>rocznym obrotem lub sumą bilansową poniżej 2 milionów EUR</strong> są zwolnione z obowiązku w zakresie usług.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Uwaga: zwolnienie to dotyczy wyłącznie <em>usług</em>, nie produktów. Mikroprzedsiębiorstwo sprzedające produkty fizyczne (np. prowadzące sklep internetowy z elektroniką) nadal podlega wymogom EAA dotyczącym produktów.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Poza obowiązkami prawnymi, dostępność często ma sens biznesowy. Strona, która jest trudna w obsłudze, traci klientów - nie tylko tych z niepełnosprawnościami. Przejrzysta struktura, dobry kontrast i czytelna typografia pomagają wszystkim odwiedzającym.
</p>
</div>
</section>

<!-- Co oznacza dostępna strona? -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Co konkretnie oznacza "dostępna strona internetowa"?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Dostępność brzmi abstrakcyjnie - ale jest bardzo praktyczna. Chodzi o to, by wszyscy ludzie mogli korzystać z Twojej strony. Trzy proste przykłady:
</p>
<ul class="mt-4 space-y-3">
<li class="flex items-start gap-3">
<span class="text-gosign-accent-text font-bold mt-0.5">1.</span>
<p class="text-body text-gosign-text">
<strong>Osoba niewidoma korzysta z czytnika ekranu</strong> - programu, który odczytuje treść ekranu na głos. Jeśli Twoje obrazy nie mają tekstów alternatywnych, osoba ta słyszy tylko "grafika, grafika, grafika" - i nic nie rozumie.
</p>
</li>
<li class="flex items-start gap-3">
<span class="text-gosign-accent-text font-bold mt-0.5">2.</span>
<p class="text-body text-gosign-text">
<strong>Osoba słabowidzącą potrzebuje dobrych kontrastów.</strong> Jasnoszary tekst na białym tle jest praktycznie nieczytelny dla milionów osób z wadami wzroku. WCAG wymaga współczynnika kontrastu co najmniej 4,5:1.
</p>
</li>
<li class="flex items-start gap-3">
<span class="text-gosign-accent-text font-bold mt-0.5">3.</span>
<p class="text-body text-gosign-text">
<strong>Osoba z ograniczeniami ruchowymi nie może obsługiwać myszy.</strong> Jeśli Twoja strona działa tylko za pomocą kliknięć myszą, jest zablokowana dla tej osoby. Wszystko musi być dostępne również za pomocą klawiatury.
</p>
</li>
</ul>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Dobra dostępność jednocześnie poprawia <a href="/pl/wiedza/schema-org-seo-podstawy/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">pozycjonowanie w wyszukiwarkach</a>: teksty alternatywne, czytelne nagłówki i czysty kod pomagają Google tak samo jak czytnikowi ekranu.
</p>
</div>
</section>

<!-- WCAG 2.2 AA: Cztery zasady -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">WCAG 2.2 AA: Cztery zasady prostym językiem</h2>
<p class="text-body text-gosign-text leading-relaxed mb-8">
WCAG (Web Content Accessibility Guidelines) to międzynarodowy standard dostępności w sieci. EAA wymaga spełnienia poziomu AA. WCAG opiera się na czterech zasadach:
</p>
<div class="grid md:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Postrzegalność</h3>
<p class="text-body text-gosign-text">
Treści muszą być dostępne dla wszystkich zmysłów. Obrazy potrzebują opisów, filmy potrzebują napisów. Kontrast musi być wystarczający. Osoba, która nie widzi, musi móc usłyszeć lub wyczuć treść.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Funkcjonalność</h3>
<p class="text-body text-gosign-text">
Wszystkie funkcje muszą być dostępne za pomocą klawiatury - nie tylko za pomocą myszy. Nawigacja musi być logiczna. Użytkownicy potrzebują wystarczająco dużo czasu na czytanie i obsługę. Żadnych migających treści, które mogą wywoływać napady padaczki.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Zrozumiałość</h3>
<p class="text-body text-gosign-text">
Teksty muszą być czytelne. Formularze muszą mieć zrozumiałe etykiety. Komunikaty o błędach muszą wyjaśniać, co poszło nie tak. Strona nie może zachowywać się niespodziewanie (np. otwierać nowe okna bez ostrzeżenia).
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Solidność</h3>
<p class="text-body text-gosign-text">
Kod musi być czysty, aby różne przeglądarki i technologie wspomagające (czytniki ekranu, monitory brajlowskie, sterowanie głosowe) mogły poprawnie interpretować treść. HTML zgodny ze standardami to podstawa.
</p>
</div>
</div>
</div>
</section>

<!-- Deklaracja dostępności -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Deklaracja dostępności: co musi zawierać?</h2>
<p class="text-body text-gosign-text leading-relaxed">
EAA wymaga publicznie dostępnej deklaracji dostępności na Twojej stronie internetowej. Ta deklaracja jest porównywalna z polityką prywatności - informuje odwiedzających o aktualnym stanie dostępności. Wymagane informacje obejmują:
</p>
<ul class="mt-4 space-y-2">
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text flex-shrink-0 mt-0.5" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor">
<path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" />
</svg>
<p class="text-body text-gosign-text">Które części strony są dostępne, a które nie</p>
</li>
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text flex-shrink-0 mt-0.5" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor">
<path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" />
</svg>
<p class="text-body text-gosign-text">Uzasadnienie istniejących ograniczeń</p>
</li>
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text flex-shrink-0 mt-0.5" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor">
<path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" />
</svg>
<p class="text-body text-gosign-text">Sposób kontaktu w celu zgłoszenia uwag (e-mail, telefon lub formularz)</p>
</li>
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text flex-shrink-0 mt-0.5" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor">
<path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" />
</svg>
<p class="text-body text-gosign-text">Odniesienie do właściwego organu nadzoru rynku</p>
</li>
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text flex-shrink-0 mt-0.5" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor">
<path stroke-linecap="round" stroke-linejoin="round" d="m4.5 12.75 6 6 9-13.5" />
</svg>
<p class="text-body text-gosign-text">Data ostatniego przeglądu</p>
</li>
</ul>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Deklaracja powinna być łatwa do znalezienia - najlepiej umieszczona w stopce, podobnie jak informacje prawne i polityka prywatności.
</p>
</div>
</section>

<!-- Dlaczego dostępność się opłaca -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Dlaczego dostępność się opłaca nawet bez obowiązku prawnego</h2>
<p class="text-body text-gosign-text leading-relaxed">
Nawet jeśli Twoja organizacja formalnie nie podlega EAA, istnieją mocne argumenty za dostępną stroną:
</p>
<div class="grid md:grid-cols-2 gap-6 mt-6">
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Większy zasięg</h3>
<p class="text-body text-gosign-text">
87 milionów osób w UE żyje z niepełnosprawnością. Do tego dochodzą miliony starszych osób ze słabnącym wzrokiem lub sprawnością ruchową. Dostępne strony docierają do większej liczby ludzi.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Lepsze SEO</h3>
<p class="text-body text-gosign-text">
Google lepiej ocenia dostępne strony. Teksty alternatywne, czysta struktura nagłówków i szybkie ładowanie to zarówno czynniki dostępności, jak i SEO.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Wymogi grantodawców</h3>
<p class="text-body text-gosign-text">
Wiele programów dotacyjnych i fundacji wymaga dostępnej komunikacji. Organizacje ubiegające się o granty lub zamówienia publiczne są coraz częściej pytane o dostępność.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Wizerunek i zaufanie</h3>
<p class="text-body text-gosign-text">
Dostępność demonstruje odpowiedzialność społeczną. Dla organizacji non-profit, NGO i firm z celami ESG to autentyczny argument wobec interesariuszy i opinii publicznej.
</p>
</div>
</div>
</div>
</section>

<!-- Kary -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Kary do 100 000 EUR - jakie ryzyko grozi?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Na mocy EAA państwa członkowskie muszą ustanowić skuteczne, proporcjonalne i odstraszające kary. W Niemczech kary sięgają do <strong>100 000 EUR</strong>. Krajowe organy nadzoru rynku egzekwują przepisy. Sankcje mogą być nałożone za:
</p>
<ul class="mt-4 space-y-2">
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text flex-shrink-0 mt-0.5" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor">
<path stroke-linecap="round" stroke-linejoin="round" d="M12 9v3.75m-9.303 3.376c-.866 1.5.217 3.374 1.948 3.374h14.71c1.73 0 2.813-1.874 1.948-3.374L13.949 3.378c-.866-1.5-3.032-1.5-3.898 0L2.697 16.126ZM12 15.75h.007v.008H12v-.008Z" />
</svg>
<p class="text-body text-gosign-text">Brak lub niedostateczną dostępność usług objętych EAA</p>
</li>
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text flex-shrink-0 mt-0.5" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor">
<path stroke-linecap="round" stroke-linejoin="round" d="M12 9v3.75m-9.303 3.376c-.866 1.5.217 3.374 1.948 3.374h14.71c1.73 0 2.813-1.874 1.948-3.374L13.949 3.378c-.866-1.5-3.032-1.5-3.898 0L2.697 16.126ZM12 15.75h.007v.008H12v-.008Z" />
</svg>
<p class="text-body text-gosign-text">Brak deklaracji dostępności na stronie</p>
</li>
<li class="flex items-start gap-3">
<svg class="w-5 h-5 text-gosign-accent-text flex-shrink-0 mt-0.5" aria-hidden="true" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor">
<path stroke-linecap="round" stroke-linejoin="round" d="M12 9v3.75m-9.303 3.376c-.866 1.5.217 3.374 1.948 3.374h14.71c1.73 0 2.813-1.874 1.948-3.374L13.949 3.378c-.866-1.5-3.032-1.5-3.898 0L2.697 16.126ZM12 15.75h.007v.008H12v-.008Z" />
</svg>
<p class="text-body text-gosign-text">Niestosowanie się do nakazów organu nadzoru rynku</p>
</li>
</ul>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Ponadto organizacje ochrony konsumentów mogą wnosić pozwy o zaniechanie. Ryzyko nie ogranicza się do kar finansowych - możliwe są również wezwania do zaprzestania naruszeń i negatywny rozgłos. Podobnie jak w przypadku <a href="/pl/bezpieczenstwo-stron-standardy/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">bezpieczeństwa stron internetowych</a>, prewencja jest tańsza niż naprawianie szkód.
</p>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Audyt dostępności: 30&nbsp;minut, bezpłatnie.</h3>
<p class="text-body text-gosign-text mb-6">Sprawdzimy Twoją stronę pod kątem najważniejszych kryteriów WCAG - bez zobowiązań, zrozumiale wyjaśnione.</p>
<a
href="/pl/kontakt/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Zamów audyt dostępności
</a>
<p class="text-small text-gosign-text-light mt-4">25 lat doświadczenia - Lighthouse 100/100 - WCAG 2.2 AA</p>
</div>
</section>

<!-- Blok informacyjny -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
Gosign to hamburska agencja cyfrowa z 25-letnim doświadczeniem w tworzeniu stron internetowych i integracji AI.
Nasza własna strona osiąga wynik Lighthouse 100/100 we wszystkich czterech kategoriach - w tym Accessibility.
Pomagamy firmom średniej wielkości, fundacjom i instytucjom publicznym w tworzeniu dostępnych i zgodnych z prawem stron internetowych.
</p>
<p class="text-small text-gosign-text-light mt-2">Ostatnia aktualizacja: marzec 2026</p>
</div>
</section>

<!-- Powiązane tematy -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Powiązane tematy</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/pl/wiedza/obowiazki-rodo-strony/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Prawo</p>
<p class="text-body font-semibold text-gosign-dark">Obowiązki RODO dla stron</p>
</a>
<a href="/pl/wiedza/strona-bez-cookie-bannera/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Prywatność</p>
<p class="text-body font-semibold text-gosign-dark">Strona bez cookie bannera</p>
</a>
<a href="/pl/wiedza/typo3-aktualizacje-bezpieczenstwo/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">TYPO3</p>
<p class="text-body font-semibold text-gosign-dark">Aktualizacje TYPO3 i bezpieczeństwo</p>
</a>
</div>
</div>
</section>

--- Obowiązki RODO dla stron internetowych ---
> Co muszą spełniać strony internetowe w zakresie ochrony danych? RODO, zgoda na cookies, polityka prywatności - zrozumiale wyjaśnione dla kadry zarządzającej.

<!-- Czym jest polityka prywatności? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Czym jest polityka prywatności - i dlaczego każda strona jej potrzebuje?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Polityka prywatności informuje odwiedzających Twoją stronę o tym, jakie dane osobowe są zbierane, dlaczego to się dzieje i jakie prawa im przysługują. Brzmi abstrakcyjnie, ale jest bardzo konkretne: gdy ktoś odwiedza Twoją stronę, serwer zapisuje adres IP. To są dane osobowe. Już to samo sprawia, że każda strona podlega RODO.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Ogólne rozporządzenie o ochronie danych (RODO) obowiązuje w całej UE od maja 2018 roku. Zobowiązuje każdego operatora strony - czy to korporację, MŚP, stowarzyszenie czy fundację - do posiadania pełnej polityki prywatności. Jeśli jest brakująca lub nieaktualna, grożą upomnienia i kary finansowe.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Ważne: polityka prywatności to nie to samo co nota prawna (impressum). Nota prawna określa, kto odpowiada za stronę. Polityka prywatności reguluje sposób obchodzenia się z danymi (na mocy RODO). Oba dokumenty są obowiązkowe i muszą istnieć jako osobne strony.
</p>
</div>
</section>

<!-- Najczęstsze błędy -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Najczęstsze błędy w politykach prywatności</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
W praktyce widzimy wciąż te same problemy. Wiele z nich jest łatwo do uniknięcia - jeśli wiesz, na co zwracać uwagę.
</p>
<div class="grid md:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Nieaktualne szablony</h3>
<p class="text-body text-gosign-text">
Wiele stron nadal korzysta z polityk prywatności z 2018 roku lub wcześniejszych. Od tego czasu zmieniły się przepisy (nowe orzeczenia dotyczące Google Fonts, Analytics, zaktualizowane przepisy ePrivacy). Szablon sprzed trzech lat prawie na pewno nie jest już zgodny z prawem.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Brakujące informacje</h3>
<p class="text-body text-gosign-text">
RODO wymaga konkretnych informacji: nazwa administratora, dane kontaktowe inspektora ochrony danych (jeśli dotyczy), podstawa prawna każdego przetwarzania, okresy przechowywania i prawa osób, których dane dotyczą. Brak któregokolwiek z nich oznacza, że polityka jest niekompletna.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Kopiuj-wklej bez dostosowania</h3>
<p class="text-body text-gosign-text">
Polityka prywatności musi odpowiadać Twojej rzeczywistej stronie. Jeśli korzystasz z Google Analytics, ale wspominasz tylko Facebook Pixel, to problem. Jeśli nie korzystasz z żadnych narzędzi analitycznych, ale piszesz o nich trzy akapity, to równie źle.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Puste lub ukryte strony</h3>
<p class="text-body text-gosign-text">
Niektóre strony mają link do polityki prywatności w stopce, ale strona za nim jest pusta lub prowadzi donikąd. Organy nadzoru sprawdzają to systematycznie - a specjaliści od prawa jeszcze dokładniej.
</p>
</div>
</div>
</div>
</section>

<!-- Zgoda na cookies -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Zgoda na cookies: dlaczego prosty komunikat nie wystarcza</h2>
<p class="text-body text-gosign-text leading-relaxed">
Cookies to małe pliki tekstowe, które strony zapisują na urządzeniu odwiedzającego. Niektóre są technicznie niezbędne (np. koszyk w sklepie online). Inne służą analityce lub marketingowi - i tu staje się to prawnie istotne.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Dyrektywa ePrivacy (wdrożona w każdym państwie członkowskim UE) wymaga, aby przed ustawieniem nieistotnych plików cookie odwiedzający aktywnie wyraził zgodę. Oznacza to, że baner z tekstem "Ta strona używa cookies - OK" nie jest wystarczający. Odwiedzający musi mieć prawdziwy wybór - z możliwością odrzucenia poszczególnych kategorii.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
W praktyce potrzebujesz platformy zarządzania zgodami (CMP). To narzędzie wyświetla baner cookie przy pierwszej wizycie z co najmniej dwiema opcjami: "Zaakceptuj wszystkie" i "Tylko niezbędne". Dopiero po wyrażeniu zgody mogą być ustawiane śledzące pliki cookie. Bez działającego CMP każde śledzenie na Twojej stronie jest niezgodne z prawem.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Uwaga: osadzone filmy YouTube, Google Maps i przyciski mediów społecznościowych również ustawiają pliki cookie. Jeśli osadzasz takie treści, potrzebujesz zgody lub rozwiązania dwuklikowego, które ładuje się dopiero po zatwierdzeniu. Temat <a href="/pl/bezpieczenstwo-stron-standardy/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">bezpieczeństwa stron internetowych</a> jest bezpośrednio z tym związany - niebezpieczne integracje mogą również powodować problemy z ochroną danych.
</p>
</div>
</section>

<!-- Lepsza alternatywa -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<div class="border-2 border-gosign-accent/20 rounded-card p-6 bg-white">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Lepsze rozwiązanie: strona, która w ogóle nie potrzebuje banera cookie</h2>
<p class="text-body text-gosign-text leading-relaxed">
Istnieje alternatywa: zbuduj swoją stronę tak, aby <strong>w ogóle nie ustawiała nieistotnych plików cookie</strong>. Bez śledzenia, bez zewnętrznych czcionek, bez osadzeń firm trzecich - wtedy nie potrzebujesz ani banera, ani CMP. To oszczędza pieniądze (narzędzia CMP kosztują 50-500 EUR miesięcznie), poprawia czas ładowania i sprawia, że zgodność z RODO staje się trywialna.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Brzmi nierealistycznie? gosign.de jest dowodem: zero cookies, zero banerów, Lighthouse 100/100, pełna analityka dzięki narzędziom bez cookies. Szczegóły wyjaśniamy tutaj:
</p>
<a
href="/pl/wiedza/strona-bez-cookie-bannera/"
class="inline-flex items-center gap-2 mt-4 text-gosign-accent-text font-semibold hover:text-gosign-accent transition-colors"
>
<span>Strona bez cookie bannera - jak to zrobić</span>
<svg class="w-5 h-5" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"><path stroke-linecap="round" stroke-linejoin="round" d="M13.5 4.5 21 12m0 0-7.5 7.5M21 12H3" /></svg>
</a>
</div>
</div>
</section>

<!-- RODO vs ePrivacy -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">RODO, dyrektywa ePrivacy, Akt o usługach cyfrowych - które prawo reguluje co?</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
Trzy warstwy regulacyjne, trzy obszary odpowiedzialności. Dla operatorów stron internetowych ważne jest zrozumienie różnic - ponieważ naruszenia każdego z nich mogą być karane osobno.
</p>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse bg-white rounded-card">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Regulacja</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Reguluje</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Obowiązek strony</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">RODO</td>
<td class="py-3 px-4 text-body text-gosign-text">Przetwarzanie danych osobowych</td>
<td class="py-3 px-4 text-body text-gosign-text">Polityka prywatności, rejestr przetwarzania, prawa osób</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Dyrektywa ePrivacy</td>
<td class="py-3 px-4 text-body text-gosign-text">Dostęp do urządzeń końcowych (cookies, fingerprinting)</td>
<td class="py-3 px-4 text-body text-gosign-text">Zgoda na cookies przed ustawieniem nieistotnych plików</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">Akt o usługach cyfrowych</td>
<td class="py-3 px-4 text-body text-gosign-text">Obowiązki informacyjne usług cyfrowych</td>
<td class="py-3 px-4 text-body text-gosign-text">Nota prawna z pełnymi danymi dostawcy</td>
</tr>
</tbody>
</table>
</div>
</div>
</section>

<!-- Lista kontrolna -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Lista kontrolna: 8 punktów, które musi spełnić każda strona</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
Niezależnie od branży, wielkości czy formy prawnej - te osiem punktów to minimum dla każdej strony działającej w UE.
</p>
<div class="space-y-4">
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">1</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Polityka prywatności - obecna i aktualna</h3>
<p class="text-body text-gosign-text mt-1">Pełna polityka ze wszystkimi wymaganymi przez RODO informacjami. Przeglądaj co najmniej raz w roku i aktualizuj po zmianach prawnych.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">2</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Nota prawna - kompletna</h3>
<p class="text-body text-gosign-text mt-1">Nazwa, adres, e-mail, telefon, osoby uprawnione do reprezentacji, numer rejestrowy (jeśli dotyczy), NIP. Na osobnej stronie, dostępna w maksymalnie dwóch kliknięciach.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">3</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Baner cookie z prawdziwym opt-in</h3>
<p class="text-body text-gosign-text mt-1">Brak wstępnie zaznaczonego "Zaakceptuj wszystkie". Równoważne opcje zgody i odmowy. Nieistotne pliki cookie mogą być ustawiane dopiero po wyrażeniu zgody.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">4</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Szyfrowanie SSL/TLS aktywne</h3>
<p class="text-body text-gosign-text mt-1">Cała strona musi być dostępna przez HTTPS. Bez szyfrowania dane z formularzy przesyłane są jawnym tekstem - wyraźne naruszenie RODO.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">5</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Formularze kontaktowe z informacją o ochronie danych</h3>
<p class="text-body text-gosign-text mt-1">Każdy formularz wymaga informacji o przetwarzaniu danych i linku do polityki prywatności. W przypadku danych wrażliwych (aplikacje o pracę, zdrowie) wymagana jest osobna zgoda.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">6</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Umowy powierzenia przetwarzania danych (DPA) podpisane</h3>
<p class="text-body text-gosign-text mt-1">Dla każdego zewnętrznego dostawcy z dostępem do danych osobowych (hosting, poczta e-mail, narzędzia analityczne) musi istnieć umowa DPA. Bez DPA przetwarzanie danych jest niezgodne z prawem.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">7</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Brak niekontrolowanych integracji firm trzecich</h3>
<p class="text-body text-gosign-text mt-1">Google Fonts hostowane lokalnie. Filmy YouTube osadzane tylko z rozwiązaniem dwuklikowym. Żadnych zewnętrznych pikseli śledzących bez zgody. Każde połączenie z firmą trzecią musi być udokumentowane w polityce prywatności.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">8</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Dostępny dostęp do informacji prawnych</h3>
<p class="text-body text-gosign-text mt-1">Polityka prywatności i nota prawna muszą być dostępne dla wszystkich - w tym osób z niepełnosprawnościami. Od czerwca 2025 roku <a href="/pl/wiedza/dostepnosc-bfsg-2025/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">Europejski Akt o Dostępności</a> wymaga cyfrowej dostępności dla wielu stron.</p>
</div>
</div>
</div>
</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Sprawdź ochronę danych na swojej stronie - 30&nbsp;minut, bezpłatnie.</h3>
<p class="text-body text-gosign-text mb-6">Sprawdzimy Twoją stronę pod kątem zgodności z RODO i pokażemy, gdzie potrzebne są działania.</p>
<a
href="/pl/kontakt/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Zamów audyt prywatności
</a>
<p class="text-small text-gosign-text-light mt-4">25 lat doświadczenia - 800+ projektów - hamburska praktyka ochrony danych</p>
</div>
</section>

<!-- Blok informacyjny -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
Gosign to hamburska agencja cyfrowa z 25-letnim doświadczeniem w tworzeniu stron internetowych, TYPO3 i integracji AI.
Przeprowadzamy audyty stron pod kątem zgodności z RODO, wdrażamy rozwiązania zgodne z ochroną danych i wspieramy
firmy, fundacje i instytucje publiczne w spełnianiu wszystkich wymogów prawnych.
</p>
<p class="text-small text-gosign-text-light mt-2">Ostatnia aktualizacja: marzec 2026</p>
</div>
</section>

<!-- Powiązane tematy -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Powiązane tematy</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/pl/wiedza/dostepnosc-bfsg-2025/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Prawo</p>
<p class="text-body font-semibold text-gosign-dark">Dostępność i EAA 2025</p>
</a>
<a href="/pl/wiedza/strona-bez-cookie-bannera/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Prywatność</p>
<p class="text-body font-semibold text-gosign-dark">Strona bez cookie bannera</p>
</a>
<a href="/pl/wiedza/typo3-aktualizacje-bezpieczenstwo/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">TYPO3</p>
<p class="text-body font-semibold text-gosign-dark">Aktualizacje TYPO3 i bezpieczeństwo</p>
</a>
</div>
</div>
</section>

--- Schema.org i podstawy SEO ---
> Czym są dane strukturalne? Jak Schema.org, meta tagi i Open Graph poprawiają widoczność w Google? Podstawy SEO wyjaśnione prosto.

<!-- Czym są dane strukturalne? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Czym są "dane strukturalne"?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Wyobraź sobie, że wręczasz komuś swoją wizytówkę. Widnieje na niej Twoje imię, numer telefonu i adres. Odbiorca natychmiast rozumie, kim jesteś i jak się z Tobą skontaktować. Dokładnie to robią dane strukturalne dla wyszukiwarek.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Schema.org to ustandaryzowany język, który rozumieją Google, Bing i inne wyszukiwarki. Mówisz im: "To jest firma, to jest adres, to są godziny otwarcia, a to jest cena produktu." Bez tych oznaczeń Google musi zgadywać - a zgadywanie często prowadzi do nieprawidłowych lub niepełnych wyników wyszukiwania.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Zasada: dodajesz niewidoczne informacje uzupełniające do istniejącego kodu HTML. Odwiedzający nie widzą żadnej różnicy, ale wyszukiwarki odczytują przejrzyście ustrukturyzowaną "wizytówkę" Twojej firmy.
</p>
</div>
</section>

<!-- Przed/Po -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Przed i po: jak Schema.org zmienia wynik wyszukiwania</h2>
<div class="grid md:grid-cols-2 gap-6">
<div class="bg-white border border-gosign-border rounded-card p-6">
<p class="text-small font-semibold text-red-600 uppercase tracking-wider mb-4">Bez Schema.org</p>
<div class="border border-gosign-border rounded-card p-4 bg-gosign-light">
<p class="text-body text-blue-700 font-semibold">Przykładowa Firma Sp. z o.o. - Strona główna</p>
<p class="text-small text-green-700 mb-1">www.przykladowafirma.pl</p>
<p class="text-small text-gosign-text-light">Witamy w Przykładowej Firmie. Oferujemy usługi w zakresie...</p>
</div>
<p class="text-small text-gosign-text-light mt-3">Tylko niebieski link z ogólnym tekstem. Brak adresu, brak ocen, brak dodatkowych informacji.</p>
</div>
<div class="bg-white border border-gosign-border rounded-card p-6">
<p class="text-small font-semibold text-green-700 uppercase tracking-wider mb-4">Z Schema.org</p>
<div class="border border-gosign-border rounded-card p-4 bg-gosign-light">
<p class="text-body text-blue-700 font-semibold">Przykładowa Firma Sp. z o.o. - Usługi IT Warszawa</p>
<p class="text-small text-green-700 mb-1">www.przykladowafirma.pl</p>
<p class="text-small text-amber-700 mb-1">&#9733;&#9733;&#9733;&#9733;&#9733; 4,8 (127 opinii)</p>
<p class="text-small text-gosign-text-light mb-1">ul. Przykładowa 12, 00-001 Warszawa - Tel. 22 123 45 67</p>
<p class="text-small text-gosign-text-light">Usługi IT dla średnich firm. Serwery, chmura, wsparcie.</p>
</div>
<p class="text-small text-gosign-text-light mt-3">Rich snippet z gwiazdkami ocen, adresem i numerem telefonu. Zajmuje więcej miejsca, wygląda bardziej wiarygodnie - i jest częściej klikany.</p>
</div>
</div>
<p class="text-body text-gosign-text leading-relaxed mt-6">
Badania pokazują: rich snippets z ocenami i dodatkowymi informacjami osiągają do 30% wyższe współczynniki klikalności niż zwykłe niebieskie linki. I to bez budżetu reklamowego - wyłącznie dzięki prawidłowo wdrożonym danym.
</p>
</div>
</section>

<!-- Najważniejsze typy schema -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">Trzy najważniejsze typy schema dla firm</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">Organization</h3>
<p class="text-body text-gosign-text">
Podstawowe dane o firmie: nazwa, logo, adres, rok założenia, profile w mediach społecznościowych. Google wykorzystuje te dane do panelu wiedzy - ramki informacyjnej po prawej stronie wyników wyszukiwania.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">LocalBusiness</h3>
<p class="text-body text-gosign-text">
Rozszerza Organization o dane specyficzne dla lokalizacji: godziny otwarcia, zakres cenowy, opinie, współrzędne. Szczególnie ważne dla firm z lokalnym zasięgiem - podstawa wpisów w Google Maps.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-3">BreadcrumbList</h3>
<p class="text-body text-gosign-text">
Pokazuje Google strukturę nawigacji Twojej strony. Zamiast "www.example.pl/produkty/kategoria/artykul" Google wyświetla: "Strona główna > Produkty > Kategoria" - przejrzyście i klikalnie.
</p>
</div>
</div>
</div>
</section>

<!-- Meta description -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Meta description: 160 znaków, które decydują o kliknięciu</h2>
<p class="text-body text-gosign-text leading-relaxed">
Meta description to krótki tekst opisowy wyświetlany w wynikach wyszukiwania Google pod tytułem strony. Nie jest bezpośrednim czynnikiem rankingowym, ale decyduje o tym, czy ktoś kliknie Twój wynik - czy konkurencji.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Dobra meta description odpowiada na pytanie wyszukującego w maksymalnie 155-160 znakach. Zawiera główne słowo kluczowe, wyraźną korzyść i najlepiej wezwanie do działania. Jeśli brakuje meta description, Google sam wybiera fragment tekstu - często nie najlepszy.
</p>

<h3 class="text-h3 font-bold text-gosign-dark mt-8 mb-4">Tagi canonical i hreflang: jednoznaczne sygnały dla wyszukiwarek</h3>
<p class="text-body text-gosign-text leading-relaxed">
Jeśli Twoja strona istnieje w kilku językach lub podobne treści są dostępne pod różnymi adresami URL, wyszukiwarki potrzebują jednoznacznych sygnałów. Służą temu dwa ważne tagi:
</p>
<ul class="mt-4 space-y-3">
<li class="text-body text-gosign-text leading-relaxed">
<strong class="text-gosign-dark">Tag canonical:</strong> Mówi Google, który URL jest "oryginalną wersją" strony. Zapobiega temu, by identyczne treści pod różnymi adresami były traktowane jako duplikaty.
</li>
<li class="text-body text-gosign-text leading-relaxed">
<strong class="text-gosign-dark">Hreflang:</strong> Informuje wyszukiwarki, jakie wersje językowe strony istnieją. Dzięki temu Google pokazuje polskim użytkownikom polską wersję, a angielskim angielską. Szczególnie istotne dla <a href="/pl/wiedza/obowiazki-rodo-strony/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">wielojęzycznych stron zgodnych z RODO</a>.
</li>
</ul>
</div>
</section>

<!-- Open Graph -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Tagi Open Graph: jak linki wyglądają dobrze na WhatsApp i LinkedIn</h2>
<p class="text-body text-gosign-text leading-relaxed">
Czy zauważyłeś? Udostępniasz link na WhatsApp lub LinkedIn i pojawia się tylko goły URL - brak obrazu, brak tytułu, brak opisu. To się dzieje, gdy brakuje tagów Open Graph.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Tagi Open Graph (OG) to elementy meta w kodzie HTML, które mówią sieciom społecznościowym, jak udostępniony link powinien być wyświetlany. Cztery najważniejsze:
</p>
<ul class="mt-4 space-y-2">
<li class="text-body text-gosign-text"><strong class="text-gosign-dark">og:title</strong> - Tytuł wyświetlany w podglądzie</li>
<li class="text-body text-gosign-text"><strong class="text-gosign-dark">og:description</strong> - Opis pod tytułem</li>
<li class="text-body text-gosign-text"><strong class="text-gosign-dark">og:image</strong> - Obraz podglądu (idealnie: 1200 x 630 pikseli)</li>
<li class="text-body text-gosign-text"><strong class="text-gosign-dark">og:url</strong> - Kanoniczny URL strony</li>
</ul>
</div>
</section>

<!-- Lista kontrolna SEO -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Lista kontrolna: 6 podstaw SEO dla każdej strony firmowej</h2>
<div class="space-y-4">
<div class="bg-white border border-gosign-border rounded-card p-5">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent text-white rounded-full flex items-center justify-center font-bold text-small">1</span>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-1">Wdrożenie oznaczeń Schema.org</h3>
<p class="text-body text-gosign-text">Sprawdź, czy Twoja strona ma przynajmniej schemat Organization lub LocalBusiness. Test: wpisz swój URL w Rich Results Test (search.google.com/test/rich-results).</p>
</div>
</div>
</div>
<div class="bg-white border border-gosign-border rounded-card p-5">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent text-white rounded-full flex items-center justify-center font-bold text-small">2</span>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-1">Meta descriptions dla wszystkich kluczowych stron</h3>
<p class="text-body text-gosign-text">Sprawdź, czy każda strona ma własną meta description - niepustą, nieunikającą duplikatów, maks. 155-160 znaków.</p>
</div>
</div>
</div>
<div class="bg-white border border-gosign-border rounded-card p-5">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent text-white rounded-full flex items-center justify-center font-bold text-small">3</span>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-1">Ustawienie tagów canonical</h3>
<p class="text-body text-gosign-text">Sprawdź, czy każda strona ma tag canonical. Szczególnie ważne dla sklepów online, stron z filtrami lub stron z wariantami www i bez www.</p>
</div>
</div>
</div>
<div class="bg-white border border-gosign-border rounded-card p-5">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent text-white rounded-full flex items-center justify-center font-bold text-small">4</span>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-1">Konfiguracja tagów Open Graph</h3>
<p class="text-body text-gosign-text">Sprawdź, czy Twoje strony mają og:title, og:description i og:image. Test: udostępnij link ze swojej strony na WhatsApp - czy pojawia się atrakcyjny podgląd?</p>
</div>
</div>
</div>
<div class="bg-white border border-gosign-border rounded-card p-5">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent text-white rounded-full flex items-center justify-center font-bold text-small">5</span>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-1">Optymalizacja HTTPS i czasu ładowania</h3>
<p class="text-body text-gosign-text">Sprawdź, czy strona jest dostępna przez HTTPS i ładuje się w mniej niż 3 sekundy. Oba to bezpośrednie czynniki rankingowe Google. <a href="/pl/bezpieczenstwo-stron-standardy/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">Bezpieczna strona spełniająca standardy branżowe</a> spełnia ten wymóg.</p>
</div>
</div>
</div>
<div class="bg-white border border-gosign-border rounded-card p-5">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent text-white rounded-full flex items-center justify-center font-bold text-small">6</span>
<div>
<h3 class="text-h3 font-bold text-gosign-dark mb-1">Zapewnienie dostępności</h3>
<p class="text-body text-gosign-text">Sprawdź, czy Twoja strona jest <a href="/pl/wiedza/dostepnosc-bfsg-2025/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">dostępna zgodnie z EAA 2025</a>. Teksty alternatywne, czysta hierarchia nagłówków i obsługa klawiaturą poprawiają nie tylko dostępność, ale i widoczność w Google.</p>
</div>
</div>
</div>
</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Sprawdź potencjał SEO swojej strony - 30&nbsp;minut, bezpłatnie.</h3>
<p class="text-body text-gosign-text mb-6">Przeanalizujemy Twoją stronę pod kątem najważniejszych podstaw SEO i pokażemy konkretne ulepszenia.</p>
<a
href="/pl/kontakt/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Zamów audyt SEO
</a>
<p class="text-small text-gosign-text-light mt-4">25 lat doświadczenia - 800+ projektów - analiza wspomagana AI</p>
</div>
</section>

<!-- Blok informacyjny -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
Gosign to hamburska agencja cyfrowa z 25-letnim doświadczeniem w tworzeniu stron internetowych, TYPO3 i integracji AI.
Wspieramy strony firmowe od technicznej optymalizacji SEO po dostępność.
Nasi klienci to firmy średniej wielkości, uczelnie i instytucje publiczne w całej Europie.
</p>
<p class="text-small text-gosign-text-light mt-2">Ostatnia aktualizacja: marzec 2026</p>
</div>
</section>

<!-- Powiązane tematy -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Powiązane tematy</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/pl/wiedza/obowiazki-rodo-strony/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Prawo</p>
<p class="text-body font-semibold text-gosign-dark">Obowiązki RODO dla stron</p>
</a>
<a href="/pl/wiedza/dostepnosc-bfsg-2025/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Prawo</p>
<p class="text-body font-semibold text-gosign-dark">Dostępność i EAA 2025</p>
</a>
<a href="/pl/wiedza/typo3-aktualizacje-bezpieczenstwo/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">TYPO3</p>
<p class="text-body font-semibold text-gosign-dark">Aktualizacje TYPO3 i bezpieczeństwo</p>
</a>
</div>
</div>
</section>

--- Strona bez cookie bannera ---
> Strony bez cookie banerów są legalne, szybsze i zgodne z RODO. Dowiedz się, jak wyeliminować cookies i zaoszczędzić na kosztach CMP.

<!-- Problem -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Problem: cookie banery irytują wszystkich</h2>
<p class="text-body text-gosign-text leading-relaxed">
Około 80 procent odwiedzających strony klika "Odrzuć wszystkie" lub natychmiast zamyka cookie banner. Efekt: pierwszą rzeczą, którą potencjalny klient widzi na Twojej stronie, jest bariera. Żadnej treści, żadnego produktu, żadnej wiadomości - tylko wyskakujące okno proszące o zgodę.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Cookie banery nie tylko irytują, ale też kosztują pieniądze. Platformy zarządzania zgodami (CMP) takie jak Cookiebot, Usercentrics czy OneTrust pobierają od 50 do 500 EUR miesięcznie. Do tego: JavaScript CMP spowalnia ładowanie strony, pogarsza Core Web Vitals i może <a href="/pl/wiedza/schema-org-seo-podstawy/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">negatywnie wpływać na pozycję w wynikach wyszukiwania</a>.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Mimo to większość stron potrzebuje cookie bannera - bo ustawia cookies. Google Analytics, Facebook Pixel, osadzone filmy YouTube, Google Fonts ładowane z zewnętrznych serwerów: wszystko to ustawia pliki cookie lub przesyła dane osobowe. A <a href="/pl/wiedza/obowiazki-rodo-strony/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">dyrektywa ePrivacy wymaga</a>, aby przed ustawieniem nieistotnych plików cookie uzyskano zgodę.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
A co, jeśli strona w ogóle nie ustawia plików cookie?
</p>
</div>
</section>

<!-- Alternatywa -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Alternatywa: w ogóle nie ustawiać cookies</h2>
<p class="text-body text-gosign-text leading-relaxed">
Jeśli strona nie ustawia nieistotnych plików cookie, nie potrzebuje cookie bannera. To nie jest sztuczka ani szara strefa - to prosta logika. Dyrektywa ePrivacy wymaga zgody tylko przed ustawieniem cookies. Brak cookies, brak potrzeby zgody, brak potrzeby bannera.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Technicznie jest to całkowicie wykonalne. Wymaga świadomych decyzji w architekturze strony:
</p>
<div class="grid md:grid-cols-2 gap-6 mt-6">
<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Czcionki hostowane lokalnie</h3>
<p class="text-body text-gosign-text">
Google Fonts hostowane lokalnie zamiast ładowane z serwerów Google. Brak połączenia z Google, brak transferu IP, brak potrzeby cookies.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Analityka bez cookies</h3>
<p class="text-body text-gosign-text">
Cloudflare Web Analytics zamiast Google Analytics. Brak cookies, brak zapisywania IP, a mimo to dostępne odsłony stron, źródła ruchu i najpopularniejsze strony.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Brak osadzeń firm trzecich</h3>
<p class="text-body text-gosign-text">
Żadnego YouTube, Google Maps ani przycisków mediów społecznościowych ustawiających cookies. W razie potrzeby: zgodne z ochroną danych alternatywy lub rozwiązania dwuklikowe.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">SSG + dostarczanie z edge CDN</h3>
<p class="text-body text-gosign-text">
Statyczne generowanie stron zamiast dynamicznego dostarczania CMS. Brak serwerowych sesyjnych cookies, brak dynamicznych nagłówków śledzących.
</p>
</div>
</div>
</div>
</section>

<!-- Co zyskujesz -->
<section class="py-section bg-gosign-white">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Co zyskujesz</h2>
<div class="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-3 gap-6">
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Brak cookie bannera</h3>
<p class="text-body text-gosign-text">Czyste pierwsze wrażenie. Brak wyskakującego okna, brak dialogu "Zaakceptuj". Odwiedzający od razu widzą Twoje treści.</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Lepsza wydajność</h3>
<p class="text-body text-gosign-text">Brak JavaScript CMP, brak sprawdzania zgody przed każdym skryptem. Mniej kodu, szybsze ładowanie.</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Pełna zgodność z RODO</h3>
<p class="text-body text-gosign-text">Nie "wystarczająco zgodne", ale: nie ma czego regulować. Brak cookies, brak potrzeby zgody.</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Brak kosztów CMP</h3>
<p class="text-body text-gosign-text">Żadnego Cookiebot, Usercentrics czy OneTrust. Oszczędność 600 do 6 000 EUR rocznie.</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Lepsze SEO</h3>
<p class="text-body text-gosign-text">Google Core Web Vitals korzystają bezpośrednio z braku skryptów zgody. Szybsze strony są wyżej w rankingu.</p>
</div>
<div class="border border-gosign-border rounded-card p-6">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Przyszłościowe</h3>
<p class="text-body text-gosign-text">Regulacje dotyczące cookies stają się coraz bardziej rygorystyczne. Jeśli nie potrzebujesz cookies, po prostu Cię to nie dotyczy.</p>
</div>
</div>
</div>
</section>

<!-- Lista kontrolna -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Lista kontrolna: jak uczynić stronę wolną od cookies</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
Pięć kroków, w tej kolejności. Dopiero gdy pierwsze cztery punkty są spełnione, można usunąć baner.
</p>
<div class="space-y-4">
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">1</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Usuń lub hostuj lokalnie zewnętrzne czcionki</h3>
<p class="text-body text-gosign-text mt-1">Ładowanie Google Fonts z serwerów Google to najczęstsza przyczyna niechcianych transferów danych. Pobierz czcionki, hostuj je na własnym serwerze, gotowe.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">2</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Zamień Google Analytics na alternatywę bez cookies</h3>
<p class="text-body text-gosign-text mt-1">Cloudflare Web Analytics, Plausible lub Fathom dostarczają dane istotne dla stron firmowych - bez cookies i bez wymogu zgody. Migracja trwa zazwyczaj mniej niż godzinę.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">3</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Zamień lub zabezpiecz osadzenia firm trzecich</h3>
<p class="text-body text-gosign-text mt-1">Filmy YouTube, Google Maps i przyciski mediów społecznościowych ustawiają cookies zaraz po załadowaniu. Dwie opcje: usuń całkowicie lub zamień na rozwiązania dwuklikowe.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">4</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Usuń piksele marketingowe lub przestaw na server-side</h3>
<p class="text-body text-gosign-text mt-1">Facebook Pixel, LinkedIn Insight Tag, Google Ads Conversion - wszystkie ustawiają cookies. Usuń je lub przestaw na śledzenie po stronie serwera bez cookies na urządzeniu końcowym.</p>
</div>
</div>
</div>
<div class="border border-gosign-border rounded-card p-5 bg-white">
<div class="flex items-start gap-4">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-dark text-white rounded-full flex items-center justify-center text-small font-bold">5</span>
<div>
<h3 class="text-body font-bold text-gosign-dark">Usuń cookie banner</h3>
<p class="text-body text-gosign-text mt-1">Dopiero teraz. Gdy nie są już ustawiane nieistotne pliki cookie, CMP można odinstalować i baner usunąć. Polityka prywatności pozostaje obowiązkowa, ale będzie znacznie krótsza.</p>
</div>
</div>
</div>
</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Zamów stronę bez cookies - 30&nbsp;minut, bezpłatnie.</h3>
<p class="text-body text-gosign-text mb-6">Sprawdzimy Twoją stronę i pokażemy, które cookies możesz wyeliminować - a których nigdy nie potrzebowałeś.</p>
<a
href="/pl/kontakt/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Zamów stronę bez cookies
</a>
<p class="text-small text-gosign-text-light mt-4">25 lat doświadczenia - 800+ projektów - hamburska praktyka ochrony danych</p>
</div>
</section>

<!-- Blok informacyjny -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
Gosign to hamburska agencja cyfrowa z 25-letnim doświadczeniem w tworzeniu stron internetowych, TYPO3 i integracji AI.
Tworzymy strony bez cookies, bez zewnętrznych zależności i z pełną zgodnością z RODO -
bez kompromisów w zakresie analityki, wydajności czy funkcjonalności.
</p>
<p class="text-small text-gosign-text-light mt-2">Ostatnia aktualizacja: marzec 2026</p>
</div>
</section>

<!-- Powiązane tematy -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Powiązane tematy</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/pl/wiedza/obowiazki-rodo-strony/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Prawo</p>
<p class="text-body font-semibold text-gosign-dark">Obowiązki RODO dla stron</p>
</a>
<a href="/pl/wiedza/schema-org-seo-podstawy/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">SEO</p>
<p class="text-body font-semibold text-gosign-dark">Schema.org i podstawy SEO</p>
</a>
<a href="/pl/bezpieczenstwo-stron-standardy/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Bezpieczeństwo</p>
<p class="text-body font-semibold text-gosign-dark">Standardy bezpieczeństwa stron</p>
</a>
</div>
</div>
</section>

--- Aktualizacje TYPO3: Dlaczego są ważne ---
> Dlaczego aktualizacje TYPO3 są ważne, które wersje mają jeszcze wsparcie i co daje upgrade do v13. Wyjaśnione przystępnie.

<!-- Co oznacza LTS? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Co oznacza "LTS" - i dlaczego jest to ważne dla Ciebie?</h2>
<p class="text-body text-gosign-text leading-relaxed">
LTS to skrót od <strong>Long Term Support</strong>. Oznacza to, że producent dostarcza aktualizacje bezpieczeństwa dla tej wersji przez dłuższy okres. Gdy zostanie odkryta luka bezpieczeństwa, jest łatana - ale tylko dla wersji, które nadal mają wsparcie.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Pomyśl o tym jak o samochodzie: dopóki Twój model jest jeszcze produkowany, dostajesz części zamienne i akcje serwisowe. Gdy model zostanie wycofany, zostajesz sam. Z TYPO3 jest dokładnie tak samo: bez wsparcia nie ma poprawek bezpieczeństwa - a znane luki pozostają otwarte.
</p>
</div>
</section>

<!-- Tabela wersji -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Które wersje TYPO3 są jeszcze wspierane?</h2>
<p class="text-body text-gosign-text leading-relaxed mb-6">
TYPO3 regularnie wydaje nowe wersje. Starsze wersje z czasem przestają otrzymywać poprawki bezpieczeństwa. Poniższa tabela pokazuje aktualny status:
</p>
<div class="overflow-x-auto">
<table class="w-full text-left border-collapse bg-white rounded-card">
<thead>
<tr class="border-b-2 border-gosign-border">
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Wersja</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Wsparcie do</th>
<th class="py-3 px-4 text-small font-bold text-gosign-dark">Status</th>
</tr>
</thead>
<tbody>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">TYPO3 v13 LTS</td>
<td class="py-3 px-4 text-body text-gosign-text">Grudzień 2027</td>
<td class="py-3 px-4">
<span class="inline-flex items-center px-3 py-1 rounded-full text-small font-semibold bg-green-100 text-green-800">Aktualna - zalecana</span>
</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">TYPO3 v12 LTS</td>
<td class="py-3 px-4 text-body text-gosign-text">Październik 2025 (Extended do marca 2028)</td>
<td class="py-3 px-4">
<span class="inline-flex items-center px-3 py-1 rounded-full text-small font-semibold bg-yellow-100 text-yellow-800">Wsparcie wygasa</span>
</td>
</tr>
<tr class="border-b border-gosign-border">
<td class="py-3 px-4 text-body font-semibold text-gosign-dark">TYPO3 v11 i starsze</td>
<td class="py-3 px-4 text-body text-gosign-text">Już wygasło</td>
<td class="py-3 px-4">
<span class="inline-flex items-center px-3 py-1 rounded-full text-small font-semibold bg-red-100 text-red-800">Brak wsparcia - ryzyko bezpieczeństwa</span>
</td>
</tr>
</tbody>
</table>
</div>
<p class="text-body text-gosign-text leading-relaxed mt-6">
<strong>Wniosek:</strong> Jeśli Twoja strona działa na TYPO3 v11 lub starszej, <strong>nie otrzymujesz już poprawek bezpieczeństwa</strong>. Znane luki nie są już łatane. Aktualizacja jest zdecydowanie zalecana.
</p>
</div>
</section>

<!-- Co się dzieje z przestarzałą wersją? -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Co się dzieje, gdy używasz przestarzałej wersji?</h2>
<p class="text-body text-gosign-text leading-relaxed">
Luki bezpieczeństwa są odkrywane regularnie - to normalne i dotyczy każdego oprogramowania. Kluczowe jest to, czy producent je łata. W przypadku wersji bez wsparcia to się już nie zdarza. Luki i tak stają się publicznie znane - a właśnie to wykorzystują atakujący.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Konkretnie oznacza to: Twoja strona może być wykorzystywana do przekierowań phishingowych, rozsyłania spamu lub kradzieży danych - często bez natychmiastowego zauważenia. Konsekwencje sięgają od utraty reputacji, przez naruszenia RODO, po umieszczenie na czarnej liście wyszukiwarek. Więcej o obowiązkach ochrony danych w naszym artykule o <a href="/pl/wiedza/obowiazki-rodo-strony/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">obowiązkach RODO dla stron internetowych</a>.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Za pomocą <a href="/pl/typo3-monitor-bezpieczenstwa/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">Monitora bezpieczeństwa TYPO3 Gosign</a> sprawdzamy Twoją instalację pod kątem znanych luk - niezależnie od wersji.
</p>
</div>
</section>

<!-- Co daje v13.4? -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-8">Co konkretnie daje TYPO3 v13.4?</h2>
<p class="text-body text-gosign-text leading-relaxed mb-8">
Aktualizacja to nie tylko obowiązkowy krok w zakresie bezpieczeństwa. TYPO3 v13.4 przynosi realne ulepszenia, które odczujesz w codziennym użytkowaniu:
</p>
<div class="grid md:grid-cols-2 gap-6">
<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Szybsze ładowanie</h3>
<p class="text-body text-gosign-text">
Automatyczna kompresja obrazów z WebP i AVIF. Twoje obrazy stają się mniejsze, strony ładują się szybciej - bez konieczności zmiany czegokolwiek.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Zmodernizowany panel</h3>
<p class="text-body text-gosign-text">
Interfejs zarządzania treścią został przeprojektowany. Przejrzystsza struktura, lepszy przegląd, prostsza obsługa - również dla okazjonalnych użytkowników.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Aktualne bezpieczeństwo</h3>
<p class="text-body text-gosign-text">
Wsparcie PHP 8.2+ i regularne aktualizacje bezpieczeństwa. Twoja strona pozostaje chroniona przed aktualnymi zagrożeniami.
</p>
</div>
<div class="border border-gosign-border rounded-card p-6 bg-white">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Content Blocks</h3>
<p class="text-body text-gosign-text">
Nowe Content Blocks umożliwiają bardziej elastyczne projektowanie stron. Układy i elementy treści łatwiej się łączą - mniejsza zależność od rozszerzeń.
</p>
</div>
</div>
</div>
</section>

<!-- Mid CTA -->
<section class="py-12 bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8 text-center">
<h3 class="text-h3 font-bold text-gosign-dark mb-2">Sprawdź swoją wersję TYPO3 - 30&nbsp;minut, bezpłatnie.</h3>
<p class="text-body text-gosign-text mb-6">Sprawdzimy Twoją wersję TYPO3, zainstalowane rozszerzenia i otwarte luki bezpieczeństwa - bez zobowiązań.</p>
<a
href="/pl/kontakt/"
target="_blank"
rel="noopener noreferrer"
class="inline-flex items-center justify-center px-8 py-4 bg-gosign-accent text-white font-semibold rounded-card hover:bg-gosign-accent-hover transition-colors text-small uppercase tracking-wider"
>
Zamów audyt TYPO3
</a>
<p class="text-small text-gosign-text-light mt-4">25 lat doświadczenia - 800+ rozszerzeń - rozwój wspomagany AI</p>
</div>
</section>

<!-- Proces aktualizacji -->
<section class="py-section bg-gosign-light">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Proces aktualizacji: czego się spodziewać</h2>
<p class="text-body text-gosign-text leading-relaxed">
Aktualizacja TYPO3 nie musi być dużym projektem. Typowy przebieg:
</p>
<ol class="mt-6 space-y-4">
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent text-white rounded-full flex items-center justify-center text-small font-bold">1</span>
<div>
<p class="text-body font-semibold text-gosign-dark">Analiza</p>
<p class="text-body text-gosign-text">Jaka wersja obecnie działa? Jakie rozszerzenia są zainstalowane? Czy są indywidualne modyfikacje? Gosign tworzy inwentaryzację.</p>
</div>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent text-white rounded-full flex items-center justify-center text-small font-bold">2</span>
<div>
<p class="text-body font-semibold text-gosign-dark">Aktualizacja na stagingu</p>
<p class="text-body text-gosign-text">Aktualizacja jest przeprowadzana w środowisku testowym. Twoja strona produkcyjna działa przez cały czas normalnie.</p>
</div>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent text-white rounded-full flex items-center justify-center text-small font-bold">3</span>
<div>
<p class="text-body font-semibold text-gosign-dark">Test i zatwierdzenie</p>
<p class="text-body text-gosign-text">Sprawdzasz wersję stagingową. Wszystko działa jak oczekiwano? Dopiero po Twoim zatwierdzeniu przechodzimy dalej.</p>
</div>
</li>
<li class="flex items-start gap-3">
<span class="flex-shrink-0 w-8 h-8 bg-gosign-accent text-white rounded-full flex items-center justify-center text-small font-bold">4</span>
<div>
<p class="text-body font-semibold text-gosign-dark">Go-live</p>
<p class="text-body text-gosign-text">Zaktualizowana wersja uruchamiana jest na produkcji. Czas niedostępności to zazwyczaj mniej niż 30 minut.</p>
</div>
</li>
</ol>
<p class="text-body text-gosign-text leading-relaxed mt-6">
<strong>Czas realizacji:</strong> Mniejsza aktualizacja (np. 12.4 na 12.6) trwa kilka godzin. Duży upgrade (np. v10 na v13) może zająć kilka dni w zależności od <a href="/pl/typo3-extensions/" class="text-gosign-accent-text underline hover:text-gosign-accent transition-colors">rozszerzeń</a> i dostosowań.
</p>
</div>
</section>

<!-- Hosting i opieka nad CMS -->
<section class="py-section bg-gosign-white">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-4">Dlaczego hosting i opieka nad CMS powinny iść w parze</h2>
<p class="text-body text-gosign-text leading-relaxed">
Aktualizacje TYPO3 nie dotyczą tylko samego oprogramowania. Nowe wersje często wymagają nowszych wersji PHP, dostosowanych konfiguracji baz danych lub zaktualizowanych ustawień serwera. Gdy opieka nad CMS i hosting są u różnych dostawców, powstaje narzut koordynacyjny - a w najgorszym przypadku luka bezpieczeństwa, bo nikt nie czuje się odpowiedzialny.
</p>
<p class="text-body text-gosign-text leading-relaxed mt-4">
Gosign oferuje jedno i drugie z jednego źródła: opiekę nad CMS obejmującą aktualizacje, monitoring rozszerzeń i hosting na europejskich serwerach. Dzięki temu środowisko serwera i wersja CMS zawsze do siebie pasują.
</p>
</div>
</section>

<!-- Blok informacyjny -->
<section class="py-12 bg-gosign-light border-t border-gosign-border">
<div class="max-w-narrow mx-auto px-4 sm:px-6 lg:px-8">
<p class="text-small text-gosign-text-light leading-relaxed">
Gosign to hamburska agencja cyfrowa z 25-letnim doświadczeniem w tworzeniu stron internetowych, TYPO3 i integracji AI.
Przeanalizowaliśmy ponad 800 rozszerzeń TYPO3 i dziś rozwijamy oprogramowanie z pomocą AI
nawet o 70% szybciej niż metodami tradycyjnymi. Nasi klienci to firmy średniej wielkości,
uczelnie i instytucje publiczne w całej Europie.
</p>
<p class="text-small text-gosign-text-light mt-2">Ostatnia aktualizacja: marzec 2026</p>
</div>
</section>

<!-- Powiązane tematy -->
<section class="py-section bg-gosign-light">
<div class="max-w-content mx-auto px-4 sm:px-6 lg:px-8">
<h2 class="text-h2 font-bold text-gosign-dark mb-6">Powiązane tematy</h2>
<div class="grid grid-cols-1 sm:grid-cols-3 gap-6">
<a href="/pl/typo3-extensions/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">TYPO3</p>
<p class="text-body font-semibold text-gosign-dark">Rozszerzenia TYPO3: Rozwój i monitoring</p>
</a>
<a href="/pl/typo3-monitor-bezpieczenstwa/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Bezpieczeństwo</p>
<p class="text-body font-semibold text-gosign-dark">Monitor bezpieczeństwa TYPO3</p>
</a>
<a href="/pl/bezpieczenstwo-stron-standardy/" class="block border border-gosign-border rounded-card p-6 hover:border-gosign-accent/30 transition-colors">
<p class="text-small font-semibold text-gosign-accent-text uppercase tracking-wider mb-2">Bezpieczeństwo</p>
<p class="text-body font-semibold text-gosign-dark">Standardy bezpieczeństwa stron</p>
</a>
</div>
</div>
</section>


============================================================
STRUCTURED AGENT DATA (machine-readable)
Methodology: https://www.gosign.de/de/methodologie/
JSON API: https://www.gosign.de/data/agents/hr/index.json
============================================================

## Agent: HR-Audit-Compliance-Agent (HR)
URL: https://www.gosign.de/de/hr-agent-katalog/audit-compliance-agent/
API: https://www.gosign.de/data/agents/hr/audit-compliance-agent.json
Decision Distribution: 58% Rules / 25% AI / 17% Human (12 steps)
EU AI Act: Not high-risk
Impact: Stützt sich eine HR-Verarbeitung auf eine wackelige Rechtsgrundlage, drohen Bußgelder bis 20 Millionen Euro oder 4 Prozent des weltweiten Konzernumsatzes nach Artikel 83 DSGVO (Stand: Mai 2026). Der Agent macht vorab prüfbar, wo der Nachweis trägt und wo er fehlt.
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Benefits-Enrollment-Agent (HR)
URL: https://www.gosign.de/de/hr-agent-katalog/benefits-enrollment-agent/
API: https://www.gosign.de/data/agents/hr/benefits-enrollment-agent.json
Decision Distribution: 46% Rules / 23% AI / 31% Human (13 steps)
EU AI Act: Not high-risk
Impact: Ein vergessener 15-Prozent-Pflichtzuschuss erzeugt einen einklagbaren Nachzahlungsanspruch und eine DRV-Beanstandung, ein übergangener Betriebsrat einen Unterlassungsanspruch, ein falsch behandelter Gesundheitsdatensatz ein DSGVO-Bußgeld bis 20 Millionen Euro.
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Bewerber-Screening-Agent (HR)
URL: https://www.gosign.de/de/hr-agent-katalog/candidate-screening-agent/
API: https://www.gosign.de/data/agents/hr/candidate-screening-agent.json
Decision Distribution: 50% Rules / 25% AI / 25% Human (8 steps)
EU AI Act: High-risk (Annex III)
Impact: Eine Bewerbungsablehnung allein durch Algorithmus ist nach Artikel 22 DSGVO verboten; und legt ein abgelehnter Bewerber Indizien für Diskriminierung vor, muss nach Paragraph 22 AGG der Arbeitgeber das Gegenteil beweisen - bei einer Blackbox-KI ohne dokumentierte Begründung ist dieser Gegenbeweis praktisch unmöglich. Der Agent lässt die Begründung zur Laufzeit entstehen, statt sie nach der Klage zu rekonstruieren.
Sources: Europaeisches Parlament und Rat: Verordnung (EU) 2024/1689 (AI Act); Gosign GmbH: Decision Layer Assessment - Methodik
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Zertifikats-Tracking-Agent (HR)
URL: https://www.gosign.de/de/hr-agent-katalog/certification-tracking-agent/
API: https://www.gosign.de/data/agents/hr/certification-tracking-agent.json
Decision Distribution: 46% Rules / 23% AI / 31% Human (13 steps)
EU AI Act: Not high-risk
Impact: Bei einem Arbeitsunfall infolge versäumter, undokumentierter Unterweisung haftet der Unternehmer der Unfallversicherung für alle Aufwendungen aus dem Unfall (Paragraph 110 SGB VII) - bis zur Höhe des zivilrechtlichen Anspruchs, trotz Haftungsprivileg (Stand: Mai 2026). Das Bußgeld nach Paragraph 25 ArbSchG bis 30.000 Euro ist daneben der kleinere Posten.
Sources: Gosign GmbH: Decision Layer Assessment - Methodik
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Compensation-Benchmarking-Agent (HR)
URL: https://www.gosign.de/de/hr-agent-katalog/compensation-benchmarking-agent/
API: https://www.gosign.de/data/agents/hr/compensation-benchmarking-agent.json
Decision Distribution: 57% Rules / 21% AI / 21% Human (14 steps)
EU AI Act: Not high-risk
Impact: Trägt ein Beschäftigter Indizien für eine geschlechtsbedingte Entgeltlücke vor, kehrt sich nach Paragraph 22 AGG die Beweislast um - dann muss der Arbeitgeber belegen, dass nicht das Geschlecht den Unterschied erklärt. Wer das nicht zeilengenau dokumentiert hat, verliert (Stand: Mai 2026). Der Agent lässt diesen Nachweis zur Laufzeit entstehen, statt ihn im Streitfall rekonstruieren zu müssen.
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Compliance-Monitoring-Agent (HR)
URL: https://www.gosign.de/de/hr-agent-katalog/compliance-monitoring-agent/
API: https://www.gosign.de/data/agents/hr/compliance-monitoring-agent.json
Decision Distribution: 50% Rules / 25% AI / 25% Human (12 steps)
EU AI Act: Not high-risk
Impact: Fehlt dieser Nachweis, greift bei einer Diskriminierungsklage die Beweislast-Umkehr nach Paragraph 22 AGG gegen das Unternehmen, und ein Monitoring-Tool ohne Betriebsvereinbarung löst nach Paragraph 87 Absatz 1 Nummer 6 BetrVG ein Beweisverwertungsverbot aus.
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Compliance-Training-Agent (HR)
URL: https://www.gosign.de/de/hr-agent-katalog/compliance-training-agent/
API: https://www.gosign.de/data/agents/hr/compliance-training-agent.json
Decision Distribution: 67% Rules / 8% AI / 25% Human (12 steps)
EU AI Act: Not high-risk
Impact: Fehlt der dokumentierte Nachweis, kippt bei einer AGG-Klage nach Paragraph 22 die Beweislast zum Arbeitgeber, und bei Arbeitsschutz, Geldwäsche oder KI-Kompetenz wird die fehlende Schulung als Organisationsverschulden gewertet (Stand: Mai 2026). Der Agent lässt diesen Nachweis zur Laufzeit entstehen, statt ihn nachträglich zu rekonstruieren.
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Arbeitsvertrags- und Angebots-Agent (HR)
URL: https://www.gosign.de/de/hr-agent-katalog/contract-offer-generation-agent/
API: https://www.gosign.de/data/agents/hr/contract-offer-generation-agent.json
Decision Distribution: 69% Rules / 15% AI / 15% Human (13 steps)
EU AI Act: Not high-risk
Impact: Bei einer Befristungsquote von 25 Prozent bei Neueinstellungen (Stand: 2024) ist das kein Randfall, sondern ein systematisches Haftungsrisiko in jedem vierten neuen Vertrag.
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Employee-Data-Management-Agent (HR)
URL: https://www.gosign.de/de/hr-agent-katalog/employee-data-management-agent/
API: https://www.gosign.de/data/agents/hr/employee-data-management-agent.json
Decision Distribution: 87% Rules / 7% AI / 7% Human (15 steps)
EU AI Act: Not high-risk
Impact: In fragmentierten HR-Systemen bleibt unsichtbar, welche Rechtsgrundlage fehlt, welche Frist abgelaufen ist und wo Stammdaten zwischen Systemen auseinanderlaufen. Genau das macht die Verstöße teuer: Die DSGVO-Beschäftigtendaten-Pflichten sind mit bis zu 4 Prozent Konzernumsatz oder 20 Mio Euro bewehrt (Art. 83 Abs. 5), ein versäumter Auskunfts- oder Löschungsantrag kostet nach EuGH C-579/21 typisch 1.000 bis 5.000 Euro pro Betroffenen, und die Aufsichtsbehörden haben das Thema im Fokus - Hessen verhängte 2024 gegen Vodafone 9,55 Mio Euro, Bayern gegen Personio 1,2 Mio Euro. Eine zentrale Plattform macht die Lücken sichtbar, bevor eine Behörde oder eine Klage sie findet.
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Employee-Relations-Case-Agent (HR)
URL: https://www.gosign.de/de/hr-agent-katalog/employee-relations-case-agent/
API: https://www.gosign.de/data/agents/hr/employee-relations-case-agent.json
Decision Distribution: 71% Rules / 7% AI / 21% Human (14 steps)
EU AI Act: Not high-risk
Impact: Anhörungsmängel sind der häufigste Grund, aus dem eine Kündigung scheitert - 30 bis 40 Prozent der Verfahren, unabhängig von der Sache. Ein deterministischer Anhörungs-Workflow nach BetrVG §102 mit Fristenüberwachung und revisionssicherer Dokumentation schließt diese Lücke. Das Kostenrisiko dahinter ist erheblich: Schadensersatz nach AGG §15 von typisch 5.000 bis 25.000 Euro pro Diskriminierungsfall, ein gerichtlicher Vergleich bei einer Führungskraft schnell im Bereich von 48.000 bis 96.000 Euro, DSGVO-Bußgelder bis 4 Prozent Konzernumsatz oder 20 Mio Euro, ein HinSchG-Bußgeld bis 50.000 Euro. Eine lückenlose Verfahrensführung verhindert, dass sich diese Risiken summieren.
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Employee-Self-Service-Agent (HR)
URL: https://www.gosign.de/de/hr-agent-katalog/employee-self-service-agent/
API: https://www.gosign.de/data/agents/hr/employee-self-service-agent.json
Decision Distribution: 87% Rules / 13% AI / 0% Human (15 steps)
EU AI Act: Not high-risk
Impact: Ein Self-Service-Portal beantwortet 60 bis 80 Prozent der Standardanfragen ohne HR-Ticket und entlastet pro Fall im Schnitt 12 bis 18 Minuten. Entscheidender ist die Frist: Statt der typischen 25 bis 40 Prozent Fristverfehlung in HR-Service-Centern hält der Agent die 30-Tage-Frist nach Art. 12 Abs. 3 DSGVO zuverlässig ein. Das senkt das teuerste Risiko, denn jede Fristverfehlung begründet nach EuGH C-579/21 einen Schadensersatzanspruch von typisch 1.000 bis 5.000 Euro pro Betroffenen, bei einer Sammelklage entsprechend mehr. Hinzu kommen DSGVO-Bußgelder bis 4 Prozent Konzernumsatz oder 20 Mio Euro, ein HinSchG-Bußgeld bis 50.000 Euro und das EntgTranspG-Risiko nach AGG §15.
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Equipment-Provisioning-Agent (HR)
URL: https://www.gosign.de/de/hr-agent-katalog/equipment-provisioning-agent/
API: https://www.gosign.de/data/agents/hr/equipment-provisioning-agent.json
Decision Distribution: 79% Rules / 7% AI / 14% Human (14 steps)
EU AI Act: Not high-risk
Impact: In einem manuellen Excel-Setup bleibt unsichtbar, welches Gerät unverschlüsselt ist, welche Tracking-Funktion ohne Betriebsvereinbarung läuft und welcher Arbeitsplatz die Ergonomie verfehlt. Genau das macht Verstöße teuer: Die NIS2-Pflichten sind mit bis zu 10 Mio Euro oder 2 Prozent des weltweiten Jahresumsatzes bewehrt, die DSGVO mit bis zu 4 Prozent Konzernumsatz oder 20 Mio Euro, hinzu kommen BSI-Sanktionen nach IT-SiG 2.0. Bei kapitalmarktorientierten Konzernen droht zudem ein Reputationsschaden mit spürbarer Kursreaktion nach einer BSI-Veröffentlichung. Eine durchgängige Pipeline macht Verschlüsselungs-, Mitbestimmungs- und Ergonomie-Lücken sichtbar, bevor ein Vorfall oder eine Prüfung sie aufdeckt.
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Executive-Recruiting-Agent (HR)
URL: https://www.gosign.de/de/hr-agent-katalog/executive-recruiting-agent/
API: https://www.gosign.de/data/agents/hr/executive-recruiting-agent.json
Decision Distribution: 40% Rules / 20% AI / 40% Human (15 steps)
EU AI Act: High-risk (Annex III)
Impact: Das Risiko einer Diskriminierungs-Klage sinkt von typisch 25 Prozent bei diffusem Headhunter-Mandat (ADS-Statistik 2024) deutlich, weil jede Auswahl einen AGG-konformen Audit-Trail samt Bias-Audit, Vergütungs-Cap-Prüfung und FüPoG-Nachweis trägt. Das ist der entscheidende Hebel, denn die Bußgelder summieren sich: bis 4 Prozent Konzernumsatz nach DSGVO, bis 7 Prozent globaler Jahresumsatz nach EU AI Act, dazu AGG-Entschädigung bis 3 Bruttomonatsgehälter und BaFin-Sanktionen. Hinzu kommt der Aktienkurs-Effekt von typisch 3 bis 7 Prozent Rückgang, wenn eine vertrauliche Suche vorzeitig bekannt wird.
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Auslagen-Agent (HR)
URL: https://www.gosign.de/de/hr-agent-katalog/expense-processing-agent/
API: https://www.gosign.de/data/agents/hr/expense-processing-agent.json
Decision Distribution: 62% Rules / 23% AI / 15% Human (13 steps)
EU AI Act: Not high-risk
Impact: Fehlt eine einzige Pflichtangabe auf einem Bewirtungsbeleg, entfällt der Betriebsausgabenabzug nicht anteilig, sondern komplett - und eine ohne Rechtsgrundlage zu hohe Erstattung wird rückwirkend zu lohnsteuer- und sozialversicherungspflichtigem Arbeitslohn, den bei der Außenprüfung der Arbeitgeber nachzahlt.
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: HR-Dokumentenmanagement-Agent (HR)
URL: https://www.gosign.de/de/hr-agent-katalog/hr-document-management-agent/
API: https://www.gosign.de/data/agents/hr/hr-document-management-agent.json
Decision Distribution: 64% Rules / 18% AI / 18% Human (11 steps)
EU AI Act: Not high-risk
Impact: Wer Fristen pauschal in Prosa pflegt, pflegt keine einzige korrekt: Buchungsbelege sind seit dem 1.1.2025 nur noch acht Jahre aufzubewahren, nicht zehn (Paragraph 147 AO). Eine zu lang gehaltene Akte ist ebenso ein Datenschutz-Verstoß wie eine zu früh gelöschte - beides mit Bußgeld- oder Schätzungsfolge. Der Agent setzt Fristen aus einem zentral gepflegten Katalog, der solche Änderungen an einer Stelle nachzieht.
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Interview-Scheduling-Agent (HR)
URL: https://www.gosign.de/de/hr-agent-katalog/interview-scheduling-agent/
API: https://www.gosign.de/data/agents/hr/interview-scheduling-agent.json
Decision Distribution: 50% Rules / 29% AI / 21% Human (14 steps)
EU AI Act: High-risk (Annex III)
Impact: Wer voll automatisiert, riskiert nicht nur empfindliche Bußgelder - bis zu 15 Mio. Euro oder 3 Prozent des weltweiten Jahresumsatzes bei Verstößen gegen die Hochrisiko-Pflichten des EU AI Act, bis zu 20 Mio. Euro oder 4 Prozent bei Verstößen gegen Artikel 22 DSGVO -, sondern den Stopp des Projekts durch den Betriebsrat. Wer die Grenze der Automatisierung prüfbar zieht, macht aus dem größten Rechtsrisiko ein betriebsratsfähiges Verkaufsargument.
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: HR-Vendor-Rechnungen-Agent (HR)
URL: https://www.gosign.de/de/hr-agent-katalog/invoice-processing-agent/
API: https://www.gosign.de/data/agents/hr/invoice-processing-agent.json
Decision Distribution: 63% Rules / 38% AI / 0% Human (8 steps)
EU AI Act: Not high-risk
Impact: Laut Ardent Partners State of ePayables 2024 sinken die Kosten pro Rechnung von 12,88 auf 2,78 USD (Best-in-Class) und die Cycle-Time von 17,4 auf 3,1 Tage - bei XRechnung-Pflicht für B2B ab Januar 2025 und typischen Rechnungsvolumina von 500 bis 5.000 pro Monat im Mittelstand.
Sources: Ardent Partners: State of ePayables 2024
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Stellenanzeigen-Agent (HR)
URL: https://www.gosign.de/de/hr-agent-katalog/job-posting-agent/
API: https://www.gosign.de/data/agents/hr/job-posting-agent.json
Decision Distribution: 38% Rules / 50% AI / 13% Human (8 steps)
EU AI Act: High-risk (Annex III)
Impact: Bei 30 Prozent der Bewerber, die diskriminierende Formulierungen als Ausschluss erleben, und typischen AGG-Klagerisiken von 3 Monatsgehältern liegt der Hebel in der konsistenten Sprachprüfung vor Veröffentlichung.
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Lernveranstaltungs-Management Agent (HR)
URL: https://www.gosign.de/de/hr-agent-katalog/learning-event-management-agent/
API: https://www.gosign.de/data/agents/hr/learning-event-management-agent.json
Decision Distribution: 78% Rules / 22% AI / 0% Human (9 steps)
EU AI Act: Not high-risk
Impact: Koordinationsaufwand pro Event signifikant reduziert, bei typischerweise 150 bis 400 Trainings pro Jahr in einem 2.000er-Unternehmen und 6 bis 10 Stunden manueller Orga pro Event.
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Lernpfad-Empfehlungs-Agent (HR)
URL: https://www.gosign.de/de/hr-agent-katalog/learning-path-recommendation-agent/
API: https://www.gosign.de/data/agents/hr/learning-path-recommendation-agent.json
Decision Distribution: 22% Rules / 67% AI / 11% Human (9 steps)
EU AI Act: Not high-risk
Impact: Klassische LMS-Kataloge erreichen Abschlussquoten von 20-30 %, weil generische Zuweisung die Relevanz verfehlt - strukturierte Kompetenzanalyse mit individueller Pfadempfehlung hebt die Abschlussrate auf 65-80 %.
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Abwesenheits-Agent (HR)
URL: https://www.gosign.de/de/hr-agent-katalog/leave-of-absence-agent/
API: https://www.gosign.de/data/agents/hr/leave-of-absence-agent.json
Decision Distribution: 70% Rules / 10% AI / 20% Human (10 steps)
EU AI Act: Not high-risk
Impact: BEEG-Anträge mit 7-Wochen-Frist vor Elternzeit-Start, MuSchG mit 6 Wochen vor Entbindung, Sonderurlaubs-Kataloge mit dutzenden Anlassgründen - ohne Regelwerk scheitert die Fristberechnung regelmäßig in mittelständischen HR-Abteilungen.
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Vertragsanalyse-Agent (HR)
URL: https://www.gosign.de/de/hr-agent-katalog/legal-contract-review-agent/
API: https://www.gosign.de/data/agents/hr/legal-contract-review-agent.json
Decision Distribution: 0% Rules / 67% AI / 33% Human (9 steps)
EU AI Act: Not high-risk
Impact: Laut World Commerce and Contracting verlieren Unternehmen durchschnittlich 8,6 Prozent ihres Vertragswerts durch mangelhafte Vertragsverwaltung (Value Erosion), bei typischen Prüfzeiten von 2 bis 4 Stunden pro Standardvertrag (LegalOn 2025) schrumpft die Erstprüfung auf Minuten.
Sources: World Commerce and Contracting: Annual Benchmark Report (with Deloitte); LegalOn: Contract Review Efficiency Report
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Merit-Cycle-Governance-Agent (HR)
URL: https://www.gosign.de/de/hr-agent-katalog/merit-cycle-governance-agent/
API: https://www.gosign.de/data/agents/hr/merit-cycle-governance-agent.json
Decision Distribution: 64% Rules / 7% AI / 29% Human (14 steps)
EU AI Act: High-risk (Annex III)
Impact: Ab Juni 2026 verlangt die EU-Entgelttransparenz für jede Anpassung eine dokumentierbare Grundlage. Bleibt ein Gender-Pay-Gap von 5 Prozent unerklärt, greifen Joint-Pay-Assessment und eine Abhilfepflicht binnen sechs Monaten (Art. 9 und 10), dazu das betriebliche Prüfverfahren nach EntgTranspG ab 500 Mitarbeitenden und AGG-Entschädigungen bis 3 Bruttomonatsgehälter. Die US-Sammelklage Mobley v. Workday zeigt das Haftungsrisiko KI-gestützter HR-Software. Der Agent liefert die auditierbare Kette, die diese Begründung trägt.
Sources: Europaeisches Parlament und Rat: Richtlinie (EU) 2023/970 Entgelttransparenz
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Offboarding-Agent (HR)
URL: https://www.gosign.de/de/hr-agent-katalog/offboarding-agent/
API: https://www.gosign.de/data/agents/hr/offboarding-agent.json
Decision Distribution: 60% Rules / 10% AI / 30% Human (10 steps)
EU AI Act: Not high-risk
Impact: Laut Gartner verliert rund 20 Prozent der Unternehmen ausgetretenen Mitarbeitenden den vollständigen System-Zugriffsentzug innerhalb von 30 Tagen, bei durchschnittlich 8 bis 15 Systemzugängen pro Mitarbeitendem ein messbares Sicherheitsrisiko.
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Onboarding-Workflow Agent (HR)
URL: https://www.gosign.de/de/hr-agent-katalog/onboarding-workflow-agent/
API: https://www.gosign.de/data/agents/hr/onboarding-workflow-agent.json
Decision Distribution: 57% Rules / 29% AI / 14% Human (14 steps)
EU AI Act: Not high-risk
Impact: Laut Gallup berichten nur 12 Prozent der Neueinstellungen von einem herausragenden Onboarding, strukturiertes Onboarding erhöht die Drei-Jahres-Verbleibquote um bis zu 69 Prozent (O.C. Tanner 2018) und die Produktivität um 50 Prozent (Aberdeen Group).
Sources: Gallup: Why the Onboarding Experience Is Key for Retention; O.C. Tanner Institute: Onboarding and the New Hire Experience; Aberdeen Group: Onboarding Benchmark Report
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Lohnbuchhaltungs-Agent (HR)
URL: https://www.gosign.de/de/hr-agent-katalog/payroll-accounting-agent/
API: https://www.gosign.de/data/agents/hr/payroll-accounting-agent.json
Decision Distribution: 56% Rules / 22% AI / 22% Human (9 steps)
EU AI Act: Not high-risk
Impact: Fehlt eine nachvollziehbare Verfahrensdokumentation, darf das Finanzamt die Buchführung verwerfen und nach Paragraph 162 AO schätzen - selbst wenn jede Buchung sachlich korrekt war. Der Agent lässt diese Dokumentation zur Laufzeit entstehen, statt sie nachträglich zu schreiben.
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Lohnprozess-Agent (HR)
URL: https://www.gosign.de/de/hr-agent-katalog/payroll-processing-agent/
API: https://www.gosign.de/data/agents/hr/payroll-processing-agent.json
Decision Distribution: 67% Rules / 13% AI / 20% Human (15 steps)
EU AI Act: Not high-risk
Impact: Ohne dokumentierte Zustimmung drohen Einigungsstelle, ein Beschlussverfahren vor dem Arbeitsgericht und ein faktisches Nutzungsverbot für ein bereits eingeführtes System.
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: HR-Reporting-Agent (HR)
URL: https://www.gosign.de/de/hr-agent-katalog/payroll-reporting-agent/
API: https://www.gosign.de/data/agents/hr/payroll-reporting-agent.json
Decision Distribution: 60% Rules / 13% AI / 27% Human (15 steps)
EU AI Act: Not high-risk
Impact: Eine nicht belastbare CSRD-Sozialkennzahl führt zum Mängelbericht des Wirtschaftsprüfers nach IDW PS 350 n.F. (international ISSA 5000) und zu einem eingeschränkten Testat, das für Kapitalmarkt und Aufsichtsrat sichtbar bleibt.
Sources: Europaeisches Parlament und Rat: Richtlinie (EU) 2023/970 Entgelttransparenz
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: People-Analytics Agent (HR)
URL: https://www.gosign.de/de/hr-agent-katalog/people-analytics-agent/
API: https://www.gosign.de/data/agents/hr/people-analytics-agent.json
Decision Distribution: 38% Rules / 38% AI / 25% Human (8 steps)
EU AI Act: High-risk (Annex III)
Impact: Laut Deloitte Global Human Capital Trends nutzen 71 Prozent der Unternehmen People Analytics aktiv, aber nur 31 Prozent haben eine dokumentierte Governance - der Agent ist Hochrisiko nach EU AI Act und erfordert Art. 9-13-Dokumentation. Geltende Frist: 2. August 2026, voraussichtlich verschoben auf Dezember 2027 (Digital Omnibus, Mai 2026).
Sources: Deloitte: Global Human Capital Trends
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Performance-Review-Dokumentations-Agent (HR)
URL: https://www.gosign.de/de/hr-agent-katalog/performance-review-documentation-agent/
API: https://www.gosign.de/data/agents/hr/performance-review-documentation-agent.json
Decision Distribution: 55% Rules / 36% AI / 9% Human (11 steps)
EU AI Act: High-risk (Annex III)
Impact: Hochrisiko-System nach EU AI Act Annex III (Frist 2. August 2026, voraussichtlich verschoben auf Dezember 2027), Art. 12 bis 14 erfordern vollständige Entscheidungsakten je Bewertung - bei durchschnittlich 8 bis 15 Beurteilungen pro Führungskraft und Jahr wird lückenlose Dokumentation ohne Tooling unrealistisch.
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Richtlinien-Agent (HR)
URL: https://www.gosign.de/de/hr-agent-katalog/policy-document-agent/
API: https://www.gosign.de/data/agents/hr/policy-document-agent.json
Decision Distribution: 73% Rules / 9% AI / 18% Human (11 steps)
EU AI Act: Not high-risk
Impact: Fällt eine Richtlinie unter ein erzwingbares Mitbestimmungsrecht nach Paragraph 87 BetrVG und fehlt die Zustimmung des Betriebsrats, ist sie gegenüber den Beschäftigten unwirksam und der Betriebsrat kann Unterlassung verlangen - die Richtlinie ist faktisch wertlos, egal wie gut sie formuliert war.
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Pre-Hire-Due-Diligence-Agent (HR)
URL: https://www.gosign.de/de/hr-agent-katalog/pre-hire-due-diligence-agent/
API: https://www.gosign.de/data/agents/hr/pre-hire-due-diligence-agent.json
Decision Distribution: 79% Rules / 7% AI / 14% Human (14 steps)
EU AI Act: High-risk (Annex III)
Impact: Die Sanktionen treffen denselben Vorgang aus mehreren Richtungen: AGG-Entschädigung bis 3 Bruttomonatsgehälter je Bewerber bei Beweislast-Umkehr (§22), EU-AI-Act-Bußgelder bis 35 Mio Euro oder 7 Prozent globaler Konzernumsatz, DSGVO-Bußgelder bis 4 Prozent Konzernumsatz und Strafrecht nach BZRG bei einem unbefugten Strafregisterauszug. Die BAG-Rechtsprechung verschärft die Beweisanforderungen zusätzlich. Der Agent liefert die auditierbare Kette, die diese Risiken abdeckt.
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Probezeit-Management-Agent (HR)
URL: https://www.gosign.de/de/hr-agent-katalog/probation-management-agent/
API: https://www.gosign.de/data/agents/hr/probation-management-agent.json
Decision Distribution: 75% Rules / 8% AI / 17% Human (12 steps)
EU AI Act: Not high-risk
Impact: Wer am Tag 179 mit zwei Wochen Frist kündigt, endet am Tag 193 - nach Ablauf der sechsmonatigen Wartezeit. Damit greift das Kündigungsschutzgesetz: aus einer formfreien Trennung wird ein Kündigungsschutzprozess mit Begründungspflicht und Drei-Wochen-Klagefrist. Ein einziges verpasstes Datum dreht die Rechtslage um.
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Promotion-Process-Agent (HR)
URL: https://www.gosign.de/de/hr-agent-katalog/promotion-process-agent/
API: https://www.gosign.de/data/agents/hr/promotion-process-agent.json
Decision Distribution: 73% Rules / 7% AI / 20% Human (15 steps)
EU AI Act: High-risk (Annex III)
Impact: Ab dem 2.8.2026 fallen Beförderungs-Systeme unter die Hochrisiko-Klassifikation des EU AI Act Annex III(4)(b). Sobald Indizien für eine Diskriminierung vorliegen, trägt der Arbeitgeber die Verteidigungslast (AGG §22 Beweislast-Umkehr). Die Tesco-Rechtsprechung des EuGH (C-624/19) erweitert Equal Pay auf gleichwertige Tätigkeiten bei Beförderungen, und die US-Sammelklage Mobley v. Workday zeigt das Risiko KI-gestützter HR-Software. Der Agent liefert die auditierbare Kette aus Bandbreiten-Sprung-Validierung, Equity-Audit und Folgenabschätzung.
Sources: Europaeisches Parlament und Rat: Verordnung (EU) 2024/1689 (AI Act)
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Krankmeldungs-Agent (HR)
URL: https://www.gosign.de/de/hr-agent-katalog/sick-leave-processing-agent/
API: https://www.gosign.de/data/agents/hr/sick-leave-processing-agent.json
Decision Distribution: 77% Rules / 8% AI / 15% Human (13 steps)
EU AI Act: Not high-risk
Impact: Eine fehlende oder verspätete Lohnfortzahlung kann als Vorenthalten von Sozialversicherungsbeiträgen nach §266a StGB strafbar sein. Eine krankheitsbedingte Kündigung ohne vorheriges BEM ist nach KSchG §1 angreifbar, und nach AGG §22 trägt der Arbeitgeber die Beweislast, sobald Indizien für eine Diskriminierung vorliegen. Der Agent liefert für jeden dieser Schritte eine lückenlose, prüfbare Kette.
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Skills-Career-Profile-Agent (HR)
URL: https://www.gosign.de/de/hr-agent-katalog/skills-career-profile-agent/
API: https://www.gosign.de/data/agents/hr/skills-career-profile-agent.json
Decision Distribution: 57% Rules / 29% AI / 14% Human (14 steps)
EU AI Act: High-risk (Annex III)
Impact: Systeme zur Aufgaben-Zuweisung nach persönlichen Eigenschaften gelten als Hochrisiko nach Annex III(4)(b); die zugehörigen Pflichten greifen nach aktuellem Recht ab dem 2. August 2026, voraussichtlich verschoben auf Dezember 2027 (Digital Omnibus, Mai 2026). Kommt es zur Diskriminierungs-Klage, trägt nach AGG §22 der Arbeitgeber die Beweislast, sobald Indizien vorliegen - in einer Black-Box-Plattform praktisch nicht zu kontern. Der Agent macht stattdessen jede KI-Inferenz mit Confidence-Score und Quellen reproduzierbar und hält den Menschen in der Schleife.
Sources: Europaeisches Parlament und Rat: Verordnung (EU) 2024/1689 (AI Act)
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Strategic-HR-Analytics-Agent (HR)
URL: https://www.gosign.de/de/hr-agent-katalog/strategic-hr-analytics-agent/
API: https://www.gosign.de/data/agents/hr/strategic-hr-analytics-agent.json
Decision Distribution: 62% Rules / 15% AI / 23% Human (13 steps)
EU AI Act: Not high-risk
Impact: Eine nicht belastbare HR-Kennzahl führt zu einem eingeschränkten Wirtschaftsprüfer-Testat oder zu einer Betriebsrats-Blockade über die Einigungsstelle - beides ist für ein börsennotiertes Unternehmen ein direktes Reputations- und Kursrisiko.
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Nachfolgeplanungs-Agent (HR)
URL: https://www.gosign.de/de/hr-agent-katalog/succession-planning-agent/
API: https://www.gosign.de/data/agents/hr/succession-planning-agent.json
Decision Distribution: 64% Rules / 21% AI / 14% Human (14 steps)
EU AI Act: Not high-risk
Impact: Ohne aktuelle, nachvollziehbare Datenbasis fallen Nachfolgeentscheidungen aus dem Bauch - mit Fehlbesetzungen, einseitigen Pipelines und einer Beweislast nach dem Allgemeinen Gleichbehandlungsgesetz, die im Streit zulasten des Arbeitgebers kippt. Der Agent lässt die Begründungskette zur Laufzeit entstehen, statt sie im Konfliktfall rekonstruieren zu müssen.
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Talent-Pool-Management-Agent (HR)
URL: https://www.gosign.de/de/hr-agent-katalog/talent-pool-management-agent/
API: https://www.gosign.de/data/agents/hr/talent-pool-management-agent.json
Decision Distribution: 64% Rules / 14% AI / 21% Human (14 steps)
EU AI Act: Not high-risk
Impact: Wer ohne gültige Einwilligung in den Pool aufnimmt, riskiert ein Aufsichtsbehörden-Verfahren mit Bußgeld bis 20 Mio. Euro oder 4 Prozent des weltweiten Jahresumsatzes; wer diskriminierend auswählt, eine angemessene Entschädigung nach Paragraph 15 AGG.
Sources: Europaeisches Parlament und Rat: Verordnung (EU) 2024/1689 (AI Act)
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: HR-Steuer-SV-Stammdaten-Agent (HR)
URL: https://www.gosign.de/de/hr-agent-katalog/tax-social-insurance-agent/
API: https://www.gosign.de/data/agents/hr/tax-social-insurance-agent.json
Decision Distribution: 73% Rules / 7% AI / 20% Human (15 steps)
EU AI Act: Not high-risk
Impact: Ein Steuer- oder SV-Verstoß trifft den Arbeitgeber hart: Haftung nach §42d EStG, Lohnsteuer-Außenprüfung mit Nachforderung und Hinterziehungs-Zinsen von 6 Prozent jährlich, Beanstandung in der SV-Prüfung nach §28p SGB IV, persönliche Strafbarkeit bis zu fünf Jahren nach §266a StGB und DSGVO-Bußgelder bis 4 Prozent des Konzernumsatzes. Seit 2025 wertet die Rentenversicherung mit ihrem KI-System KIRA digitale Prüfakten vorab aus und nennt Nachforderungen im hohen dreistelligen Millionenbereich pro Jahr. Der Agent liefert dagegen die deterministische, auditierbare Melde-Kette.
Sources: Deloitte: Global Payroll Benchmarking Survey; Ernst & Young: Global Payroll Survey 2022
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Zeiterfassungs-Agent (HR)
URL: https://www.gosign.de/de/hr-agent-katalog/time-attendance-agent/
API: https://www.gosign.de/data/agents/hr/time-attendance-agent.json
Decision Distribution: 86% Rules / 7% AI / 7% Human (14 steps)
EU AI Act: Not high-risk
Impact: Seit dem EuGH-Urteil C-55/18 und dem BAG-Beschluss 1 ABR 22/21 muss der Arbeitgeber die Arbeitszeit objektiv erfassen - und trägt im Streit über Mehrarbeit oder Ruhezeiten die Beweislast. Fehlt eine belastbare Erfassung, drohen Bußgelder nach ArbZG, Nachforderungen aus Tarifverträgen und Beanstandungen in der Sozialversicherungsprüfung. Der Agent liefert die objektive, prüfbare Kette.
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Trainings-Wirksamkeits-Agent (HR)
URL: https://www.gosign.de/de/hr-agent-katalog/training-effectiveness-agent/
API: https://www.gosign.de/data/agents/hr/training-effectiveness-agent.json
Decision Distribution: 64% Rules / 14% AI / 21% Human (14 steps)
EU AI Act: Not high-risk
Impact: Ohne Betriebsvereinbarung kann der Betriebsrat die Abschaltung des Systems per einstweiliger Verfügung erzwingen, und nicht-anonymisierte Reports bewegen sich im Bußgeldrahmen von bis zu 20 Millionen Euro oder 4 Prozent des weltweiten Konzernumsatzes.
Sources: Europaeisches Parlament und Rat: Verordnung (EU) 2024/1689 (AI Act)
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Trainings-Bedarfs-Analyse-Agent (HR)
URL: https://www.gosign.de/de/hr-agent-katalog/training-needs-analysis-agent/
API: https://www.gosign.de/data/agents/hr/training-needs-analysis-agent.json
Decision Distribution: 67% Rules / 17% AI / 17% Human (12 steps)
EU AI Act: Not high-risk
Impact: Eine KI, die selbst entscheidet, wer ein Training braucht, verstößt gegen Artikel 22 DSGVO - mit einem Bußgeld-Rahmen bis 20 Mio. Euro oder 4 Prozent des weltweiten Jahresumsatzes, je nachdem welcher Betrag höher ist. Der Agent liefert nur den aggregierten Bedarf; die Entscheidung über einzelne Menschen bleibt beim Menschen mit Betriebsrat-Sichtbarkeit.
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Versetzungs- und Umzugs-Agent (HR)
URL: https://www.gosign.de/de/hr-agent-katalog/transfer-relocation-agent/
API: https://www.gosign.de/data/agents/hr/transfer-relocation-agent.json
Decision Distribution: 86% Rules / 7% AI / 7% Human (14 steps)
EU AI Act: Not high-risk
Impact: Wird die Mitbestimmung nach BetrVG §99 übergangen, kann der Betriebsrat die Versetzung per Unterlassungs-Anspruch und Beschluss-Verfahren stoppen. Eine diskriminierende Auswahl löst nach AGG §15 eine Entschädigung von bis zu drei Bruttomonatsgehältern aus, ein Datenschutz-Verstoß nach DSGVO bis zu 4 Prozent des Konzernumsatzes, und eine Beschäftigung ohne gültigen Aufenthaltstitel ist nach AsylG §95 strafbar. Der Agent liefert die durchgängig auditierbare Kette, die diese Eskalationen verhindert.
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: HR-Reise-Antrag-Agent (HR)
URL: https://www.gosign.de/de/hr-agent-katalog/travel-expense-agent/
API: https://www.gosign.de/data/agents/hr/travel-expense-agent.json
Decision Distribution: 79% Rules / 14% AI / 7% Human (14 steps)
EU AI Act: Not high-risk
Impact: Ein Verstoß gegen das Lohnsteuerrecht löst eine Nachforderung mit Säumniszuschlägen aus und macht die Reisekosten zum Prüfungsschwerpunkt einer Lohnsteuer-Außenprüfung; bei prüfungspflichtigen Gesellschaften droht zusätzlich ein Mängelbericht des Wirtschaftsprüfers. Der Agent liefert die durchgängig auditierbare Kette, die das verhindert.
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Lieferantenmanagement-Agent (HR)
URL: https://www.gosign.de/de/hr-agent-katalog/vendor-management-agent/
API: https://www.gosign.de/data/agents/hr/vendor-management-agent.json
Decision Distribution: 79% Rules / 7% AI / 14% Human (14 steps)
EU AI Act: Not high-risk
Impact: Ein Verstoß gegen das Lieferkettengesetz kann mit Bußgeldern bis zu 8 Millionen Euro oder 2 Prozent des Konzernumsatzes geahndet werden und schließt das Unternehmen bis zu drei Jahre von öffentlichen Aufträgen aus. Ein mangelhafter Auftragsverarbeitungs-Vertrag kostet nach DSGVO bis zu 4 Prozent des Konzernumsatzes, eine diskriminierende Vendor-Auswahl kehrt nach AGG §22 die Beweislast um. Der Agent liefert die durchgängig auditierbare Kette, die das verhindert.
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Workforce-Planning-Agent (HR)
URL: https://www.gosign.de/de/hr-agent-katalog/workforce-planning-agent/
API: https://www.gosign.de/data/agents/hr/workforce-planning-agent.json
Decision Distribution: 54% Rules / 23% AI / 23% Human (13 steps)
EU AI Act: Not high-risk
Impact: Eine nicht erklärbare Sozialauswahl ist nach KSchG (Paragraph 1 Abs. 3) sozial ungerechtfertigt und damit unwirksam, und eine fehlende Massenentlassungs-Anzeige macht ausgesprochene Kündigungen nach ständiger Rechtsprechung des BAG unwirksam - vom EuGH zuletzt mit Urteil vom 30.10.2025 (C-134/24) bestätigt. Der Agent lässt die nachvollziehbare Auswahl-Begründung zur Laufzeit entstehen, statt sie nach der ersten Klage zu rekonstruieren.
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Betriebsrats-Koordinations-Agent (HR)
URL: https://www.gosign.de/de/hr-agent-katalog/works-council-coordination-agent/
API: https://www.gosign.de/data/agents/hr/works-council-coordination-agent.json
Decision Distribution: 58% Rules / 17% AI / 25% Human (12 steps)
EU AI Act: Not high-risk
Impact: Ein Formfehler bei der Anhörung nach Paragraph 102 BetrVG macht die Kündigung kraft Gesetz unwirksam - nicht anfechtbar, nicht heilbar, auch wenn der Grund berechtigt war. Bei den Arbeitsgerichten gehen jährlich zwischen 200.000 und 330.000 Kündigungsschutzklagen ein, und Formfehler sind dabei der prozessual sicherste Angriffspunkt.
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Kontierungs-Agent (FINANCE)
URL: https://www.gosign.de/de/finance-agent-katalog/account-coding-agent/
API: https://www.gosign.de/data/agents/finance/account-coding-agent.json
Decision Distribution: 90% Rules / 10% AI / 0% Human (10 steps)
EU AI Act: Not high-risk
Impact: Bis 90 Prozent der Rechnungen ohne manuelle Kontierung, Durchlaufzeit von 6 auf unter 1 Minute pro Beleg und eine dokumentierte Vorsteuer-Entscheidung je Vorgang.
Sources: Gosign GmbH: Decision Layer Assessment - Methodik
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Abgrenzungs-Agent (FINANCE)
URL: https://www.gosign.de/de/finance-agent-katalog/accruals-agent/
API: https://www.gosign.de/data/agents/finance/accruals-agent.json
Decision Distribution: 80% Rules / 20% AI / 0% Human (10 steps)
EU AI Act: Not high-risk
Impact: Monatsabschluss-Abgrenzungen um 4 bis 6 Stunden schneller, Fehlerquote bei periodengerechter Zuordnung unter 0,5 Prozent und automatische Auflösung im Folgemonat.
Sources: Gosign GmbH: Decision Layer Assessment - Methodik
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Jahresabschluss-Vorbereitungs-Agent (FINANCE)
URL: https://www.gosign.de/de/finance-agent-katalog/annual-statement-agent/
API: https://www.gosign.de/data/agents/finance/annual-statement-agent.json
Decision Distribution: 60% Rules / 20% AI / 20% Human (15 steps)
EU AI Act: Not high-risk
Impact: Abschluss-Durchlaufzeit um 30 bis 40 Prozent verkürzt, 15 dokumentierte Entscheidungsschritte je Abschluss und WP-Antwortzeiten laut APQC-Benchmark um den Faktor 2 beschleunigt.
Sources: APQC: Open Standards Benchmarking
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Anlagenzugangs-Agent (FINANCE)
URL: https://www.gosign.de/de/finance-agent-katalog/asset-capitalization-agent/
API: https://www.gosign.de/data/agents/finance/asset-capitalization-agent.json
Decision Distribution: 89% Rules / 11% AI / 0% Human (9 steps)
EU AI Act: Not high-risk
Impact: 80 bis 90 Prozent der Anlagenzugänge vollautomatisch erfasst, Fehler bei GWG-Grenzen strukturell ausgeschlossen und konsistente Nutzungsdauer über alle Werke.
Sources: Gosign GmbH: Decision Layer Assessment - Methodik
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Inventur-Agent (FINANCE)
URL: https://www.gosign.de/de/finance-agent-katalog/asset-inventory-agent/
API: https://www.gosign.de/data/agents/finance/asset-inventory-agent.json
Decision Distribution: 75% Rules / 0% AI / 25% Human (8 steps)
EU AI Act: Not high-risk
Impact: Inventur-Durchlauf von 3 Wochen auf 5 Arbeitstage verkürzt, Vollständigkeitsquote der Anlagen-Erfassung über 98 Prozent und revisionsfestes Abstimmungsprotokoll.
Sources: Gosign GmbH: Decision Layer Assessment - Methodik
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Bankabstimmungs-Agent (FINANCE)
URL: https://www.gosign.de/de/finance-agent-katalog/bank-reconciliation-agent/
API: https://www.gosign.de/data/agents/finance/bank-reconciliation-agent.json
Decision Distribution: 87% Rules / 7% AI / 7% Human (15 steps)
EU AI Act: Not high-risk
Impact: 95 Prozent der Bewegungen werden automatisch abgeglichen, täglich statt wöchentlich. Die Bearbeitungszeit je Kontoauszug sinkt von 90 auf unter 10 Minuten, der Verrechnungskonten-Saldo zum Bilanzstichtag geht gegen Null. Das vermeidet die 5 bis 15 Prozent Hinzuschätzung nach §162 AO und liefert den IKS-Wirksamkeitsnachweis, der einen Walk-Through-Test des Wirtschaftsprüfers und eine IDEA-Z3-Datenträgerüberlassung in der Außenprüfung übersteht.
Sources: Gosign GmbH: Decision Layer Assessment - Methodik
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Budget-Variance-Agent (FINANCE)
URL: https://www.gosign.de/de/finance-agent-katalog/budget-variance-agent/
API: https://www.gosign.de/data/agents/finance/budget-variance-agent.json
Decision Distribution: 53% Rules / 20% AI / 27% Human (15 steps)
EU AI Act: Not high-risk
Impact: Mit manueller Excel-Analyse erreichen mittelständische Unternehmen laut Hackett Group 2024 nur 64 Prozent Genauigkeit, bei zwei bis drei Arbeitstagen je Controller und Monatsabschluss für 15 Kostenstellen - 46 Prozent der FP&A-Zeit gehen laut FP&A Trends Benchmark 2025 für die Datensammlung drauf, bevor die Analyse überhaupt beginnt. Bei kapitalmarktorientierten Unternehmen kommt das Aufsichtsrisiko hinzu: Ein DPR-Mängelbericht zur Soll-Ist-Plausibilität nach WpHG §114 löst typisch eine Kursreaktion von -3 bis -8 Prozent am Veröffentlichungstag aus, dazu eine BaFin-Folgeprüfung mit Sanktionen bis 10 Mio EUR oder 5 Prozent Jahresumsatz nach §120. Bei Falschangaben oder versäumter Berichtspflicht haftet der Vorstand persönlich nach §93 AktG mit Beweislastumkehr, der Aufsichtsrat nach §116 - verschärft durch die FISG-2021-Prüfer-Rotation und den D&O-Selbstbehalt von 10 Prozent nach VorstAG.
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Zahlungseingangszuordnungs-Agent (FINANCE)
URL: https://www.gosign.de/de/finance-agent-katalog/cash-application-agent/
API: https://www.gosign.de/data/agents/finance/cash-application-agent.json
Decision Distribution: 75% Rules / 0% AI / 25% Human (8 steps)
EU AI Act: Not high-risk
Impact: Cash-Application-Quote von 50 auf über 90 Prozent automatisiert, DSO-Verbesserung um 3 bis 5 Tage und Bearbeitungszeit pro Eingang unter 30 Sekunden.
Sources: Gosign GmbH: Decision Layer Assessment - Methodik
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Cash-Forecasting-Agent (FINANCE)
URL: https://www.gosign.de/de/finance-agent-katalog/cash-forecasting-agent/
API: https://www.gosign.de/data/agents/finance/cash-forecasting-agent.json
Decision Distribution: 63% Rules / 13% AI / 25% Human (16 steps)
EU AI Act: Not high-risk
Impact: Mittelständler ohne belastbaren 13-Wochen-Forecast verlieren laut Treasury Management International 2024 durchschnittlich 660.000 EUR pro Jahr - durch überhöhte Kontokorrent-Zinsen, verpasste Festgeld-Anlagen und ungeplante Notfinanzierung; die Agicap-Studie 2024 nennt 91 Prozent höhere Überziehungsgebühren bei Excel-Forecasts. Bei Going-Concern-relevanten Fehleinschätzungen haftet der Vorstand persönlich und unbeschränkt nach §93 AktG, wenn er die Risikofrüherkennung nach §91 Abs. 2 versäumt; die 3-Wochen-Antragsfrist nach InsO §15a ist strafbewehrt mit Freiheitsstrafe bis drei Jahre. Hinzu kommen ein DPR-Mängelbericht nach WpHG §114 mit BaFin-Bußgeld bis 10 Mio EUR oder 5 Prozent Jahresumsatz und ein Going-Concern-Hinweis des Wirtschaftsprüfers nach IDW PS 270 - mit Bilanzeid-Verweigerung, Reputationsschaden und gekürzten Hausbank-Kreditlinien.
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Close-Checklisten-Agent (FINANCE)
URL: https://www.gosign.de/de/finance-agent-katalog/close-orchestration-agent/
API: https://www.gosign.de/data/agents/finance/close-orchestration-agent.json
Decision Distribution: 100% Rules / 0% AI / 0% Human (10 steps)
EU AI Act: Not high-risk
Impact: Monatsabschluss-Durchlauf von 8 auf 4 bis 5 Arbeitstage, vollständig dokumentierte Task-Verantwortlichkeiten und strukturierte Eskalation bei drohenden Verzögerungen.
Sources: Gosign GmbH: Decision Layer Assessment - Methodik
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Consolidation-Agent (FINANCE)
URL: https://www.gosign.de/de/finance-agent-katalog/consolidation-agent/
API: https://www.gosign.de/data/agents/finance/consolidation-agent.json
Decision Distribution: 87% Rules / 7% AI / 7% Human (15 steps)
EU AI Act: Not high-risk
Impact: Die automatisierte Vollkonsolidierung mit Reciprocal-Match-Eliminierung und Goodwill-Impairment-Tests senkt das DPR-Mängelbericht-Risiko von typisch 25 bis 40 Prozent bei manueller Arbeit auf unter 1 Prozent. Das vermeidet BaFin-Sanktionen bis 10 Mio EUR oder 5 Prozent Jahresumsatz nach WpHG §120, die DPR-Pflichtveröffentlichung des Mängelberichts und das Bilanzeid-Strafrecht nach §331 HGB (Geld- oder Freiheitsstrafe bis drei Jahre). Die Vollabdeckung statt Stichprobe findet Konsolidierungs-Differenzen, Equity-Inkonsistenzen und Goodwill-Risiken, die in stichprobenbasierten Prüfungen typisch unsichtbar bleiben.
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Vertragscompliance-Agent (FINANCE)
URL: https://www.gosign.de/de/finance-agent-katalog/contract-compliance-agent/
API: https://www.gosign.de/data/agents/finance/contract-compliance-agent.json
Decision Distribution: 73% Rules / 13% AI / 13% Human (15 steps)
EU AI Act: Not high-risk
Impact: Das automatisierte Lieferanten-Screening, die Vergabe-Klassifikation, die AGB-Inhaltskontrolle und das CMS-Mapping nach IDW PS 980 senken das Bußgeld-Risiko von typisch 12 bis 25 Prozent (BAFA-Prüfberichte 2024 Q4) auf unter 1 Prozent. Das Bundeskartellamt führte 2024 über 380 Verfahren gegen Mittelständler und Konzerne mit durchschnittlichen Bußgeldern von 8 bis 24 Mio EUR, dazu ein Reputationsschaden von 5 bis 15 Prozent des Marktwerts.
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Gutschrift/Storno-Agent (FINANCE)
URL: https://www.gosign.de/de/finance-agent-katalog/credit-note-agent/
API: https://www.gosign.de/data/agents/finance/credit-note-agent.json
Decision Distribution: 88% Rules / 13% AI / 0% Human (8 steps)
EU AI Act: Not high-risk
Impact: manuelle USt-Korrekturen fehleranfällig, strukturierte Regelwerke senken die Korrekturquote messbar, Durchlaufzeit pro Gutschrift von 15 auf 3 Minuten und vollständige Revisionsspur.
Sources: Gosign GmbH: Decision Layer Assessment - Methodik
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: AfA-Agent (FINANCE)
URL: https://www.gosign.de/de/finance-agent-katalog/depreciation-agent/
API: https://www.gosign.de/data/agents/finance/depreciation-agent.json
Decision Distribution: 100% Rules / 0% AI / 0% Human (8 steps)
EU AI Act: Not high-risk
Impact: AfA-Lauf von 4 Stunden auf unter 10 Minuten, Fehler bei GWG- und Sammelposten-Grenzen strukturell ausgeschlossen und revisionsfeste Buchungssätze je Monat.
Sources: Gosign GmbH: Decision Layer Assessment - Methodik
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Mahnlauf-Agent (FINANCE)
URL: https://www.gosign.de/de/finance-agent-katalog/dunning-agent/
API: https://www.gosign.de/data/agents/finance/dunning-agent.json
Decision Distribution: 93% Rules / 0% AI / 7% Human (15 steps)
EU AI Act: Not high-risk
Impact: DSO-Reduktion um 4 bis 7 Tage, Mahnautomatisierung von 95% des wöchentlichen Pipeline-Volumens, Reduktion uneinbringlicher Forderungen um 15 bis 20% durch tagesgenaue Verzinsung und tempogerechte Schufa-Meldung sowie steuerlich anerkannte Forderungsabschreibung ohne Korrektur in der Außenprüfung (Vermeidung Hinzuschätzung 75-150% nach §162 AO).
Sources: Gosign GmbH: Decision Layer Assessment - Methodik
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Bewirtungsbeleg-Agent (FINANCE)
URL: https://www.gosign.de/de/finance-agent-katalog/entertainment-expense-agent/
API: https://www.gosign.de/data/agents/finance/entertainment-expense-agent.json
Decision Distribution: 67% Rules / 22% AI / 11% Human (9 steps)
EU AI Act: Not high-risk
Impact: Durchlaufzeit pro Bewirtungsbeleg von 8 auf unter 2 Minuten, Vorsteuer-Sicherheit durch vollständige Pflichtangabenprüfung und Betriebsprüfer-Nachfragen zur Formalität minimiert.
Sources: Gosign GmbH: Decision Layer Assessment - Methodik
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: ESG-Reporting-Agent (FINANCE)
URL: https://www.gosign.de/de/finance-agent-katalog/esg-reporting-agent/
API: https://www.gosign.de/data/agents/finance/esg-reporting-agent.json
Decision Distribution: 56% Rules / 13% AI / 31% Human (16 steps)
EU AI Act: Not high-risk
Impact: Der Erstanwendungsaufwand eines kapitalmarktorientierten Konzerns der Welle 1 liegt laut den Studien Deloitte CSRD Readiness 2024 und PwC ESG 2024 typisch bei 300 bis 500 Personentagen Datenerhebung, 80 bis 150 Personentagen Prüfer-Vorbereitung und 1,5 bis 3,5 Mio EUR Beratungs- und IT-Kosten. Die Bußgeld-Risiken kumulieren: der DPR-Mängelbericht mit Reputationsschaden, das BaFin-Bußgeld bis 10 Mio EUR oder 5 Prozent Jahresumsatz nach WpHG §120, das LkSG-BAFA-Bußgeld bis 8 Mio EUR oder 2 Prozent Konzernumsatz und das DSGVO-Bußgeld bis 4 Prozent Konzernumsatz bei Mitarbeiterdaten (S1). Die Vollabdeckung statt Cherrypicking findet die ESRS-Datenlücken, die Taxonomie-Fehlklassifikationen und die fehlende Konsistenz zum Lagebericht, die in der Limited-Assurance-Prüfung typisch zu Mängelbericht-Befunden führen.
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Financial-Forecast-Agent (FINANCE)
URL: https://www.gosign.de/de/finance-agent-katalog/financial-forecast-agent/
API: https://www.gosign.de/data/agents/finance/financial-forecast-agent.json
Decision Distribution: 75% Rules / 6% AI / 19% Human (16 steps)
EU AI Act: Not high-risk
Impact: DAX-/MDAX-Konzerne verlieren laut PwC Forecast Benchmark 2024 im Schnitt 5,2 Mio Euro pro ad-hoc-pflichtiger Prognose-Anpassung, vor allem durch Kursreaktionen von -3 bis -8 Prozent am Veröffentlichungstag. Im gehobenen Mittelstand kosten unzuverlässige Forecasts laut KPMG CFO-Survey 2024 rund 1,8 Mio Euro pro Jahr über schlechtere Bankkonditionen und verpasste Gelegenheiten. Bei Falschangaben kommt die Vorstandshaftung nach §93 AktG mit Beweislastumkehr hinzu, dazu BaFin-Bußgelder bis 10 Mio Euro oder 5 Prozent des Jahresumsatzes.
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Fraud-Detection-Agent (FINANCE)
URL: https://www.gosign.de/de/finance-agent-katalog/fraud-detection-agent/
API: https://www.gosign.de/data/agents/finance/fraud-detection-agent.json
Decision Distribution: 47% Rules / 33% AI / 20% Human (15 steps)
EU AI Act: Not high-risk
Impact: Der adressierbare Betrugsschaden liegt laut ACFE Report to the Nations 2024 (1.921 Fälle, 3,1 Mrd USD Schaden, mediane Aufdeckungszeit 12 Monate) typisch bei 1 bis 5 Prozent des Jahresumsatzes. Hinzu kommt die Vermeidung von Verbandsgeldbußen nach OWiG §30 (bis 10 Mio Euro), Kartellbußen nach GWB §81 (bis 10 Prozent des Konzernumsatzes, 2024 bis 800 Mio Euro bei DAX-Konzernen) und DSGVO-Bußen bis 4 Prozent des Umsatzes. Die Vollabdeckung deckt Schwellenwert-Splitting, Phantom-Vendor-Konstrukte und Round-Tripping auf, die in Stichproben unsichtbar bleiben.
Sources: ACFE: Report to the Nations 2024
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: GoBD-Compliance-Agent (FINANCE)
URL: https://www.gosign.de/de/finance-agent-katalog/gobd-compliance-agent/
API: https://www.gosign.de/data/agents/finance/gobd-compliance-agent.json
Decision Distribution: 70% Rules / 20% AI / 10% Human (10 steps)
EU AI Act: Not high-risk
Impact: GoBD-Konformitätsprüfung auf alle steuerrelevanten Dokumente ausgeweitet, offene Feststellungen bei der Betriebsprüfung deutlich reduziert und revisionsfeste Z1/Z2/Z3-Datenzugriffsprotokolle.
Sources: Gosign GmbH: Decision Layer Assessment - Methodik
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: IKS-Monitoring-Agent (FINANCE)
URL: https://www.gosign.de/de/finance-agent-katalog/iks-monitoring-agent/
API: https://www.gosign.de/data/agents/finance/iks-monitoring-agent.json
Decision Distribution: 73% Rules / 13% AI / 13% Human (15 steps)
EU AI Act: Not high-risk
Impact: Die Prüfungs-Mehrkosten sinken von typisch 30 bis 150 Prozent (Big-Four-Stundensätze 280 bis 580 Euro bei IKS-Mängeln) auf unter 10 Prozent - durch Vollabdeckung statt Stichprobe und eine DPR-konforme Lagebericht-Generierung. Die DPR-Bilanzkontrolle erfasste 2024 über 350 Fälle mit 18 Prozent Fehlerquote, jeweils mit Mitteilungspflicht an den Prüfungsausschuss und durchschnittlich 4 bis 6 Monaten Korrekturaufwand.
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Intercompany-Agent (FINANCE)
URL: https://www.gosign.de/de/finance-agent-katalog/intercompany-agent/
API: https://www.gosign.de/data/agents/finance/intercompany-agent.json
Decision Distribution: 57% Rules / 29% AI / 14% Human (14 steps)
EU AI Act: Not high-risk
Impact: Ein Konzern mit 30 Gesellschaften hat bis zu 435 mögliche Gesellschaftspaare, typisch 100 bis 150 aktive IC-Beziehungen mit hunderten Transaktionen pro Monat. Die manuelle Abstimmung in Excel kostet laut Hackett Group 2024 fünf bis sechs Arbeitstage pro Monatsabschluss bei Match-Quoten von nur 60 bis 70 Prozent. Bei Prüfungen kommen erhebliche Compliance-Risiken hinzu: die 60-Tage-Vorlagefrist der GAufzV, ein Strafzuschlag bis 10 Prozent des Mehrgewinns nach §162 Abs. 4 AO, die AStG-§1-Berichtigung mit Beweislastumkehr und eine drohende Doppelbesteuerung bei einseitiger Korrektur. Kapitalmarktorientierte Unternehmen riskieren zudem einen DPR-Mängelbericht mit Kursreaktionen von -3 bis -8 Prozent und BaFin-Sanktionen bis 10 Mio Euro.
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Rechnungsfreigabe-Agent (FINANCE)
URL: https://www.gosign.de/de/finance-agent-katalog/invoice-approval-agent/
API: https://www.gosign.de/data/agents/finance/invoice-approval-agent.json
Decision Distribution: 88% Rules / 0% AI / 13% Human (8 steps)
EU AI Act: Not high-risk
Impact: Freigabe-Durchlauf von 5 Tagen auf unter 24 Stunden, 86 Prozent der Rechnungen in Standardrouting und Skonto-Ausnutzung um 25 bis 35 Prozent gesteigert.
Sources: Gosign GmbH: Decision Layer Assessment - Methodik
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Eingangsrechnungs-OCR-Agent (FINANCE)
URL: https://www.gosign.de/de/finance-agent-katalog/invoice-capture-agent/
API: https://www.gosign.de/data/agents/finance/invoice-capture-agent.json
Decision Distribution: 71% Rules / 21% AI / 7% Human (14 steps)
EU AI Act: Not high-risk
Impact: Rechnungsdurchlauf von 12-18 Minuten auf unter 2 Minuten pro Beleg, 15 bis 25 Euro Prozesskostenersparnis je Rechnung laut Billentis E-Invoicing Report und Fehlerquote der manuellen Erfassung signifikant reduziert.
Sources: Ardent Partners: State of ePayables 2024; APQC: Open Standards Benchmarking
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Rechnungsausgangs-Agent (FINANCE)
URL: https://www.gosign.de/de/finance-agent-katalog/invoice-generation-agent/
API: https://www.gosign.de/data/agents/finance/invoice-generation-agent.json
Decision Distribution: 100% Rules / 0% AI / 0% Human (8 steps)
EU AI Act: Not high-risk
Impact: Fakturierungs-Durchlauf von 20 auf unter 3 Minuten je Rechnung, 0 Lücken in Nummernkreisen und GoBD-konforme Archivierung im selben Buchungslauf.
Sources: Gosign GmbH: Decision Layer Assessment - Methodik
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Buchungssatz-Agent (FINANCE)
URL: https://www.gosign.de/de/finance-agent-katalog/journal-entry-agent/
API: https://www.gosign.de/data/agents/finance/journal-entry-agent.json
Decision Distribution: 69% Rules / 8% AI / 23% Human (13 steps)
EU AI Act: Not high-risk
Impact: Bis zu 70 bis 85 Prozent weniger manuelle Routinebuchungen, ein von 8 auf 4 Werktage verkürzter Monatsabschluss und die Vermeidung der Hinzuschätzung nach §162 AO (5 bis 15 Prozent Aufschlag, bei 50 Mio Euro Bilanzsumme also 250 bis 750 TEUR Nachzahlung zuzüglich 6 Prozent AO-Zinsen). Die Buchführung hält der IDEA-Datenträgerüberlassung in Lohnsteuer-Außenprüfung und Umsatzsteuer-Sonderprüfung stand.
Sources: Gosign GmbH: Decision Layer Assessment - Methodik
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Lease-Accounting-Agent (FINANCE)
URL: https://www.gosign.de/de/finance-agent-katalog/lease-accounting-agent/
API: https://www.gosign.de/data/agents/finance/lease-accounting-agent.json
Decision Distribution: 67% Rules / 7% AI / 27% Human (15 steps)
EU AI Act: Not high-risk
Impact: Das Restatement-Risiko sinkt von typisch 12 bis 18 Prozent (IDW-PS-951-Findings im Mittelstand 2024) auf unter 1 Prozent - durch automatisierte Klassifikation, eine aus Treasury-Daten belegte IBR-Dokumentation und GoBD-konforme BFH-Memos je Vertrag. Im DPR-Schwerpunkt 2024 zeigten 38 Prozent der geprüften HDAX-Unternehmen Fehler in der Leasing-Bilanzierung.
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Management-Reporting-Agent (FINANCE)
URL: https://www.gosign.de/de/finance-agent-katalog/management-reporting-agent/
API: https://www.gosign.de/data/agents/finance/management-reporting-agent.json
Decision Distribution: 63% Rules / 25% AI / 13% Human (8 steps)
EU AI Act: Not high-risk
Impact: Dashboard-Aktualisierung von wöchentlich auf täglich, Report-Erstellung um 70 Prozent beschleunigt und 8 KPIs je Bericht mit Anomalie-Signal.
Sources: Gosign GmbH: Decision Layer Assessment - Methodik
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Zahlungslauf-Agent (FINANCE)
URL: https://www.gosign.de/de/finance-agent-katalog/payment-run-agent/
API: https://www.gosign.de/data/agents/finance/payment-run-agent.json
Decision Distribution: 93% Rules / 0% AI / 7% Human (14 steps)
EU AI Act: Not high-risk
Impact: Die Skonto-Ausnutzung steigt von 55 auf 92 Prozent - bei 100 Mio Euro Bezugsvolumen rund 740.000 Euro Mehrertrag pro Jahr. Die Vorbereitung pro Lauf sinkt von 8 Stunden auf 15 Minuten, das Doppelzahlungs-Risiko entfällt, und BaFin-Strafen bis 5 Mio Euro werden vermieden.
Sources: Gosign GmbH: Decision Layer Assessment - Methodik
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Zahlungsverkehr-Agent (FINANCE)
URL: https://www.gosign.de/de/finance-agent-katalog/payment-traffic-agent/
API: https://www.gosign.de/data/agents/finance/payment-traffic-agent.json
Decision Distribution: 90% Rules / 0% AI / 10% Human (10 steps)
EU AI Act: Not high-risk
Impact: Zahlungsverkehr-Klassifikation in unter 5 Sekunden je Zahlung, Fehlerquote bei Formatwahl unter 0,3 Prozent und automatische Rückmeldungsverarbeitung ohne manuelle Bankprotokoll-Prüfung.
Sources: Gosign GmbH: Decision Layer Assessment - Methodik
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Gehaltsabrechnungs-Agent (FINANCE)
URL: https://www.gosign.de/de/finance-agent-katalog/payroll-calculation-agent/
API: https://www.gosign.de/data/agents/finance/payroll-calculation-agent.json
Decision Distribution: 93% Rules / 7% AI / 0% Human (14 steps)
EU AI Act: Not high-risk
Impact: Der Abrechnungslauf für 5.000 Mitarbeitende sinkt von drei Personentagen auf unter vier Stunden, jede Berechnung ist für die Lohnsteuer-Außenprüfung reproduzierbar. Aufwendige Korrekturen mit DEÜV-Stornierung entfallen, ebenso das Risiko einer Strafbarkeit nach §266a StGB und eines MiLoG-Bußgelds bis 500.000 Euro durch die automatische Mindestlohn-Prüfung.
Sources: Gosign GmbH: Decision Layer Assessment - Methodik
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Lohnkorrekturbuchungs-Agent (FINANCE)
URL: https://www.gosign.de/de/finance-agent-katalog/payroll-correction-agent/
API: https://www.gosign.de/data/agents/finance/payroll-correction-agent.json
Decision Distribution: 70% Rules / 20% AI / 10% Human (10 steps)
EU AI Act: Not high-risk
Impact: Korrektur-Durchlauf von 2 Tagen auf unter 4 Stunden, durchgängig automatische SV- und LSt-Nachberechnung und revisionsfeste Korrekturbuchungen je Fall.
Sources: Gosign GmbH: Decision Layer Assessment - Methodik
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Lohnsteuer-Agent (FINANCE)
URL: https://www.gosign.de/de/finance-agent-katalog/payroll-tax-agent/
API: https://www.gosign.de/data/agents/finance/payroll-tax-agent.json
Decision Distribution: 87% Rules / 7% AI / 7% Human (15 steps)
EU AI Act: Not high-risk
Impact: Die monatliche Lohn-Compliance sinkt von fünf Personentagen auf unter vier Stunden je Lauf und deckt alle Krankenkassen ab. Sie vermeidet die Strafbarkeit nach §266a StGB, einen Haftungsbescheid nach §42d EStG, den Verspätungszuschlag bei der ELSTER-Anmeldung und die 12 Prozent Strafzinsen der Sozialversicherungs-Außenprüfung.
Sources: Gosign GmbH: Decision Layer Assessment - Methodik
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Kleinbetrags-/Barkassen-Agent (FINANCE)
URL: https://www.gosign.de/de/finance-agent-katalog/petty-cash-agent/
API: https://www.gosign.de/data/agents/finance/petty-cash-agent.json
Decision Distribution: 75% Rules / 13% AI / 13% Human (8 steps)
EU AI Act: Not high-risk
Impact: Kassenbuch-Erfassung von 10 auf 2 Minuten pro Beleg, tägliche Aufzeichnungspflicht automatisiert und dokumentationslückenfrei für die Betriebsprüfung.
Sources: Gosign GmbH: Decision Layer Assessment - Methodik
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Buchungs-QA-Agent (FINANCE)
URL: https://www.gosign.de/de/finance-agent-katalog/posting-quality-agent/
API: https://www.gosign.de/data/agents/finance/posting-quality-agent.json
Decision Distribution: 88% Rules / 13% AI / 0% Human (8 steps)
EU AI Act: Not high-risk
Impact: QA-Prüfung auf jede Buchung vor Hauptbuch-Eingang ausgedehnt, Fehlerquote im Hauptbuch signifikant reduziert und Abschluss-Nacharbeiten deutlich verringert.
Sources: Gosign GmbH: Decision Layer Assessment - Methodik
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Verfahrensdokumentations-Agent (FINANCE)
URL: https://www.gosign.de/de/finance-agent-katalog/process-documentation-agent/
API: https://www.gosign.de/data/agents/finance/process-documentation-agent.json
Decision Distribution: 38% Rules / 38% AI / 25% Human (8 steps)
EU AI Act: Not high-risk
Impact: Verfahrensdokumentation-Aktualisierung von 2 Wochen auf 2 Tage je Änderung, strukturell gesicherte Konsistenz zwischen Prozess und Dokument und revisionsfeste Änderungshistorie.
Sources: Gosign GmbH: Decision Layer Assessment - Methodik
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Rückstellungs-Agent (FINANCE)
URL: https://www.gosign.de/de/finance-agent-katalog/provisions-agent/
API: https://www.gosign.de/data/agents/finance/provisions-agent.json
Decision Distribution: 63% Rules / 13% AI / 25% Human (8 steps)
EU AI Act: Not high-risk
Impact: Rückstellungsberechnung von 3 Tagen auf 4 Stunden je Abschluss, vollständig nachvollziehbare Basis je Rückstellung und revisionsfeste Rückstellungsspiegel-Dokumentation.
Sources: Gosign GmbH: Decision Layer Assessment - Methodik
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Bestellanforderungs-Agent (FINANCE)
URL: https://www.gosign.de/de/finance-agent-katalog/purchase-requisition-agent/
API: https://www.gosign.de/data/agents/finance/purchase-requisition-agent.json
Decision Distribution: 75% Rules / 13% AI / 13% Human (8 steps)
EU AI Act: Not high-risk
Impact: Bestellanforderungs-Durchlauf von 3 Tagen auf unter 4 Stunden, Rahmenvertrags-Quote um 20 bis 30 Prozent gesteigert und lückenlose Compliance-Abdeckung bei Freigabeprozessen.
Sources: Gosign GmbH: Decision Layer Assessment - Methodik
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Forderungsmanagement-Agent (FINANCE)
URL: https://www.gosign.de/de/finance-agent-katalog/receivables-management-agent/
API: https://www.gosign.de/data/agents/finance/receivables-management-agent.json
Decision Distribution: 50% Rules / 13% AI / 38% Human (8 steps)
EU AI Act: Not high-risk
Impact: Laut Creditreform Zahlungsindikator Winter 2024/25 liegt die Forderungslaufzeit im deutschen Mittelstand bei 39,63 Tagen mit 8,41 Verzugstagen - strukturierte Regelauswertung verkürzt DSO um 5 bis 8 Tage und liefert tagesaktuelle Risiko-Sicht je Debitor.
Sources: Creditreform: Zahlungsindikator Deutschland Winter 2024/25
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Abstimmungs-Agent (FINANCE)
URL: https://www.gosign.de/de/finance-agent-katalog/reconciliation-agent/
API: https://www.gosign.de/data/agents/finance/reconciliation-agent.json
Decision Distribution: 75% Rules / 13% AI / 13% Human (8 steps)
EU AI Act: Not high-risk
Impact: Kontenabgleich kontinuierlich statt nur zum Stichtag, 75 Prozent der Abstimmungen vollautomatisch und Abschluss-Abstimmungszeit um 60 Prozent reduziert.
Sources: Gosign GmbH: Decision Layer Assessment - Methodik
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Revenue-Recognition-Agent (FINANCE)
URL: https://www.gosign.de/de/finance-agent-katalog/revenue-recognition-agent/
API: https://www.gosign.de/data/agents/finance/revenue-recognition-agent.json
Decision Distribution: 60% Rules / 20% AI / 20% Human (15 steps)
EU AI Act: Not high-risk
Impact: Die Erfassung der Leistungsverpflichtungen sinkt von 45 auf 10 Minuten je Vertrag und deckt den gesamten Konzern-Vertragsbestand mit auditierbarem Decision Log ab. Sie vermeidet eine Neuaufstellung der Bilanz durch einen Versagungsvermerk, eine Hinzuschätzung von 3 bis 8 Prozent des Konzernumsatzes, eine Fehlerfeststellung der Bilanzkontrolle mit Reputationsschaden und einen Mängelbericht des Abschlussprüfers.
Sources: Gosign GmbH: Decision Layer Assessment - Methodik
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: SV-Meldungs-Agent (FINANCE)
URL: https://www.gosign.de/de/finance-agent-katalog/sv-reporting-agent/
API: https://www.gosign.de/data/agents/finance/sv-reporting-agent.json
Decision Distribution: 100% Rules / 0% AI / 0% Human (10 steps)
EU AI Act: Not high-risk
Impact: SV-Meldungen vollständig reproduzierbar, Rückläufer durch Formatfehler strukturell minimiert und Meldedurchlauf im Sekundenbereich je Meldeanlass.
Sources: Gosign GmbH: Decision Layer Assessment - Methodik
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Betriebsprüfungs-Vorbereitungs-Agent (FINANCE)
URL: https://www.gosign.de/de/finance-agent-katalog/tax-audit-preparation-agent/
API: https://www.gosign.de/data/agents/finance/tax-audit-preparation-agent.json
Decision Distribution: 40% Rules / 30% AI / 30% Human (10 steps)
EU AI Act: Not high-risk
Impact: Betriebsprüfungs-Vorbereitung von 6 auf 2 Wochen, risikobasierte Priorisierung statt Gießkanne und Rückstellungsbedarf auf Basis von 3 Szenarien quantifiziert.
Sources: Gosign GmbH: Decision Layer Assessment - Methodik
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Three-Way-Matching Agent (FINANCE)
URL: https://www.gosign.de/de/finance-agent-katalog/three-way-matching-agent/
API: https://www.gosign.de/data/agents/finance/three-way-matching-agent.json
Decision Distribution: 100% Rules / 0% AI / 0% Human (11 steps)
EU AI Act: Not high-risk
Impact: Three-Way-Matching-Quote von 95 Prozent automatisch, Durchlaufzeit bis Rechnungsfreigabe von 3 Tagen auf unter 2 Stunden und Skonto-Verluste eliminiert.
Sources: Gosign GmbH: Decision Layer Assessment - Methodik
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Verrechnungspreis-Dokumentations-Agent (FINANCE)
URL: https://www.gosign.de/de/finance-agent-katalog/transfer-pricing-agent/
API: https://www.gosign.de/data/agents/finance/transfer-pricing-agent.json
Decision Distribution: 50% Rules / 13% AI / 38% Human (8 steps)
EU AI Act: Not high-risk
Impact: TP-Dokumentation von 8 Wochen auf 2 Wochen je Geschäftsjahr, 100-Prozent-Abdeckung aller IC-Transaktionen und revisionsfeste CbCR-Grundlage.
Sources: Gosign GmbH: Decision Layer Assessment - Methodik
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Reisekosten-Tax-Agent (FINANCE)
URL: https://www.gosign.de/de/finance-agent-katalog/travel-expense-agent/
API: https://www.gosign.de/data/agents/finance/travel-expense-agent.json
Decision Distribution: 87% Rules / 7% AI / 7% Human (15 steps)
EU AI Act: Not high-risk
Impact: Reisekostenabrechnung von 45 auf unter 8 Minuten je Reise, 87 Prozent der 15 Entscheidungsschritte vollautomatisch und 100-Prozent-Abdeckung der BMF-Pauschalen.
Sources: Gosign GmbH: Decision Layer Assessment - Methodik
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: USt-Voranmeldungs-Agent (FINANCE)
URL: https://www.gosign.de/de/finance-agent-katalog/vat-return-agent/
API: https://www.gosign.de/data/agents/finance/vat-return-agent.json
Decision Distribution: 85% Rules / 8% AI / 8% Human (13 steps)
EU AI Act: Not high-risk
Impact: Die USt-Voranmeldung sinkt von zwei Tagen auf unter vier Stunden pro Monat und geht fristgerecht ohne Verspätungszuschlag an das Finanzamt. Der vollständige Vorsteuerabzug bleibt durch die automatische Rechnungsprüfung erhalten, die qualifizierte Bestätigung der USt-IdNr. sichert die Steuerfreiheit ab, und der Konsistenz-Check verhindert Buchungsfehler.
Sources: Gosign GmbH: Decision Layer Assessment - Methodik
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Lieferanten-Onboarding-Agent (FINANCE)
URL: https://www.gosign.de/de/finance-agent-katalog/vendor-onboarding-agent/
API: https://www.gosign.de/data/agents/finance/vendor-onboarding-agent.json
Decision Distribution: 56% Rules / 33% AI / 11% Human (9 steps)
EU AI Act: Not high-risk
Impact: Onboarding-Durchlauf von 5 Tagen auf unter 4 Stunden, 100-Prozent-Abdeckung der Sanktionslisten-Prüfung und Dokumentation der Risikobewertung je Lieferant.
Sources: Gosign GmbH: Decision Layer Assessment - Methodik
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR

## Agent: Quellensteuer-Agent (FINANCE)
URL: https://www.gosign.de/de/finance-agent-katalog/withholding-tax-agent/
API: https://www.gosign.de/data/agents/finance/withholding-tax-agent.json
Decision Distribution: 71% Rules / 21% AI / 7% Human (14 steps)
EU AI Act: Not high-risk
Impact: Die Prüfung je Zahlung sinkt von 30 auf unter 5 Minuten und deckt alle über 90 Doppelbesteuerungsabkommen ab. Sie vermeidet den Haftungsbescheid für den Arbeitgeber, den Verspätungszuschlag bei der ELSTER-Anmeldung und die Versagung der DBA-Entlastung wegen Treaty-Shopping, und sie liefert den Nachweis der Sorgfaltspflicht für die Außenprüfung.
Sources: Gosign GmbH: Decision Layer Assessment - Methodik
Methodology: https://www.gosign.de/de/methodologie/
Languages: DE, EN, PL, ES, BR